PoC: Add metrics to TXM#503
Conversation
f6a00d3 to
e7703ac
Compare
| description: "Count of transactions transitioning to a different status", | ||
| unit: "count", | ||
| valueType: ValueType.INT, | ||
| }) |
There was a problem hiding this comment.
Yes, because then we can track how many transactions we have in any state, as you can filter by the specific status. You can filter by status because when I add the counter, I specify the status:
transactionStatusChangeCounter.add(1, {
status: this.status,
});This actually generates a global counter for all statuses and one for each specific status
| unit: "count", | ||
| valueType: ValueType.INT, | ||
| }) | ||
|
|
There was a problem hiding this comment.
Seems to be missing more transaction metrics (processing, reverted, cancelled, successfull, and I would add failed in multiple buckets (RPC, timeout, simulation failure, ...), cf. notion doc)
There was a problem hiding this comment.
Yes, I agree with you. This was just to show what I think is a good way to implement metrics, but yes, we need to add more. I'm going to do it
| description: "Number of transactions collected", | ||
| unit: "count", | ||
| valueType: ValueType.INT, | ||
| }) |
There was a problem hiding this comment.
Numba go up type of stuff. We can keep it, it's fun.
There was a problem hiding this comment.
We might want a metric for the rate of growth over time? Like bucket into a time period (1 min? 10 min?) and see how many new txs arrive in that time and chart that.
There was a problem hiding this comment.
That was my intention, but to achieve that kind of metric, the right way to do it is to have a counter and then visualize the rate of increase of this counter over a period of time in the Grafana panel. This is the correct approach because it is more versatile and easier to implement
|
This is good, probably add a few more metrics (esp. transaction breakdown) and then we can merge this initial batch. |
7b586dc to
ee3e75d
Compare
cf5bf43 to
96a7504
Compare
1727040 to
4303d66
Compare
4365362 to
e783a93
Compare
| // biome-ignore format: tidy | ||
| console.warn( | ||
| "No signTransaction method found on the account, using signMessage instead. " + | ||
| "A viem update probably change the internal signing API."); |
|
|
||
| return ResultAsync.fromThrowable(() => { | ||
| if (client.account.signTransaction) { | ||
| return client.account.signTransaction({ |
There was a problem hiding this comment.
I think client.signTransaction should always be the correct approach. Some account types like JSON-RPC are essentially just a string as they defer signing elsewhere. client.signTransaction takes into account what type of account is configured and signs accordingly
(i think)
There was a problem hiding this comment.
That was made a couple of months ago. But I remember that we tried to use client.account.signTransaction because using that method allowed us to avoid calling getChainId. I’m not exactly sure why, but when using client.signTransaction directly—even if you specify the chainId—it still makes a call to the blockchain
There was a problem hiding this comment.
That's what I remember too. We should a comment there to explain why we're doing this though!
|
Gave this a cursory look, good to merge from my side imho. |
f9da5c8 to
16ff508
Compare

Linked Issues
Added OpenTelemetry instrumentation to monitor txm
Toggle Checklist
Checklist
Basics
norswap/build-system-caching).Correctness
Architecture & Documentation