feat: add latency and retry count to instrumentation #1693
Conversation
saviogl
requested review from
fbogsany,
mwear,
robertlaurin,
dazuma,
ericmustin,
arielvalentin,
ahayworth,
plantfansam,
robbkidd,
simi,
kaylareopelle,
xuan-cao-swi and
a team
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
Add
messaging.sidekiq.latencyandmessaging.sidekiq.retry.countattributes toopentelemetry-instrumentation-sidekiq. These attributes provide meaningful information which one can build monitoring and alerting from.