TXM - add latency tracking metrics #456
Conversation
There was a problem hiding this comment.
Pull request overview
This PR adds comprehensive latency tracking metrics for transaction lifecycle stages in the TON transaction manager. The changes introduce three new timestamp fields to track when transactions are broadcast, confirmed, and finalized, along with corresponding Prometheus and OpenTelemetry metrics to measure the time intervals between these stages.
Key changes:
- Added timestamp fields (
BroadcastAt,ConfirmedAt,FinalizedAt) to theTxstruct to track transaction lifecycle events - Implemented three new latency metrics: broadcast latency (enqueue to broadcast), confirmation latency (broadcast to confirmation), and finalization latency (confirmation to finalization)
- Integrated latency recording into the transaction broadcast and status checking logic
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| pkg/txm/tx.go | Added three timestamp fields to track broadcast, confirmation, and finalization times |
| pkg/txm/metrics.go | Defined new Prometheus and OpenTelemetry metrics for latency tracking and implemented recording methods |
| pkg/txm/txm.go | Integrated latency recording at broadcast and status transition points |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
jadepark-dev
left a comment
jadepark-dev
left a comment
There was a problem hiding this comment.
LGTM, left a few nit comments
pkg/ton/tracetracking/message.go
Outdated
| } | ||
|
|
||
| // IsConfirmed checks if the message has reached a confirmed state, which we consider Received or Cascading. | ||
| func (m *ReceivedMessage) IsConfirmed() bool { |
There was a problem hiding this comment.
ReceivedMessage is already confirmed. It has already been included in a TX where it is the inMsg: it has been received.
pkg/txm/txm.go
Outdated
| t.logger.Debugf("Msg sequence diagram:\n%s\n", debug.NewDebuggerSequenceTrace(knownAddresses, sequenceDiagram.OutputFmtURL).DumpReceived(&receivedMessage)) | ||
|
|
||
| // Track confirmation latency when first confirmed (Received or Cascading) | ||
| if tx.ConfirmedAt.IsZero() && receivedMessage.IsConfirmed() { |
There was a problem hiding this comment.
The WaitForTrace() above already waits for the confirmation of every message in the trace. I am not sure this is the metric you want to take. If you want to measure the time it takes from us calling the rpc, to the external msg being delivered to the wallet, that is done here. If you want to measure the time between a message is enqueued (internal message contract-to-contract) and it gets delivered, that's going to be more challenging. You may want to use the timestamp of TXs.
There was a problem hiding this comment.
yeaaaah, I don't think we need this ConfirmedAt metric, BroadcastAt and FinalizedAt give us what we care about most. Thanks for pointing this out, will remove
ogtownsend
force-pushed
the
ogt/add-txm-latency-metrics
branch
from
2c3724b to
d9260fa
Compare
|
@patricios-space this should be good for another pass 🙏 |
3 participants
Adds:
ton_txm_broadcast_latency_secondston_txm_confirmation_latency_secondston_txm_finalization_latency_seconds