feat: add latency and retry count to instrumentation #1693
Conversation
saviogl
requested review from
a team,
ahayworth,
arielvalentin,
dazuma,
ericmustin,
fbogsany,
kaylareopelle,
mwear,
plantfansam,
robbkidd,
robertlaurin,
simi and
xuan-cao-swi
as code owners
|
|
| SemanticConventions::Trace::MESSAGING_OPERATION => 'process' | ||
| } | ||
| attributes[SemanticConventions::Trace::PEER_SERVICE] = instrumentation_config[:peer_service] if instrumentation_config[:peer_service] | ||
| attributes['messaging.sidekiq.latency'] = queue_latency(enqueued_at) if enqueued_at |
There was a problem hiding this comment.
We intentionally avoid adding metric values to span attributes.
Is this something that you can derive in the collector or your own implementation of an exporter?
There was a problem hiding this comment.
What is the rationale for that? Favouring the usage of the Metrics API? Though I'd understand the motivation given the tri modal definition for Open Telemetry (Trace, Metrics & Logs) this stipulation might be too restrictive considering the shift happening in the industry where companies like Honeycomb are normalizing cost efficient storage and rich retrieval of high cardinality/dimensionality span data. Recently I came across Sentry's decision of not rolling a Metrics product 1 year in the making in favor of Span Metrics
|
👋 This pull request has been marked as stale because it has been open with no activity. You can: comment on the issue or remove the stale label to hold stale off for a while, add the |
|
Hi @saviogl, could you sign the CLA? #1693 (comment) |
|
@kaylareopelle done |
3 participants
Add
messaging.sidekiq.latencyandmessaging.sidekiq.retry.countattributes toopentelemetry-instrumentation-sidekiq. These attributes provide meaningful information which one can build monitoring and alerting from.