-
Notifications
You must be signed in to change notification settings - Fork 182
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Processed/exported SDK metrics #83
Comments
Do you intend to just introduce a semantic convention for this, or would this be added to the SDK specification (in https://github.com/open-telemetry/opentelemetry-specification) as well to ensure a consistent implementation? |
+1 on semconv, also this walks into the "namespaced attributes" debate. |
I don't think that "stable" is that restrictive, but I think this would be best made optional anyway |
This is exceptionally useful. We added hooks to enable metrics capture in the Ruby SDK a couple of years ago: open-telemetry/opentelemetry-ruby#510. The metrics we defined include:
At Shopify, we find these metrics very useful for monitoring the health of our trace collection pipeline. We have added these metrics in various hacky ways to other language SDKs (e.g. Go). It would be great to standardize them across SDK implementations. |
The Ruby SDK also reports compressed and uncompressed sizes of the batch before exporting. We have found this to be a better indicator of load on our collection infrastructure than span volume alone. We often feel the pain of this missing from other SDK implementations where we have not hacked it in. |
It would be nice if BSP would export following metrics:
Then its possible to build dashboards and alerts to detect problematic applications easily because its possible to compare size and capacity also its possible to see what triggers exports most timeouts or size hits. |
Opening this issue to mainly get the ball rolling, as I have had users asking for metrics around processed/dropped/exported data (starting with traces, but following up with metrics/logs). I'd like to initially add the following metrics (some inspiration take by the current metrics in the Java SDK):
otel.exporter.exported
, counter, with attributes:success
= true|falsetype
= span|metric|logexporterType
= <exporter type, e.g.GrpcSpanExporter
>otel.processor.processed
, counter, with attributes:dropped
= true|false (buffer overflow)type
= span|metric|logprocessorType
= <processor typ, e.g.BatchSpanProcessor
>Albeit this is mostly targeted at SDKs, the Collector could use this as well - in which case we may want to add a
component
orpipeline.component
attribute (or similar), to signal whether this is a SDK or a Collector.The text was updated successfully, but these errors were encountered: