-
Notifications
You must be signed in to change notification settings - Fork 650
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
Refactor Metric object format #2646
Comments
fwiw other sigs have followed this approach of keeping the class/object model close to OTLP data model ex: open-telemetry/opentelemetry-js#2809 and dotnet/others appear to be doing same. |
Thanks @srikanthccv. I think the only downside to grouping is it's doing extra work, whereas the current structure is basically exactly what we have in memory. I'm OK to do the grouping in our code. The code is basically implemented already in the OTLP exporter Line 86 in a4b4c45
The only weird thing is our Aggregation interface returns instances of |
Metric
exporter format (a breaking change) before we send it to the exporter.. Originally, I was thinking the flat representation would be easy to work with but it looks like the OTLP and Prom exporters are having to duplicate a lot of grouping logic.* Refactor metric format Fixes #2646 * Do not overwrite pb2_scope_metrics * Refactor for loops * Add multiple scope test case * Fix interfaces * Fix docs * Update exporter/opentelemetry-exporter-prometheus/src/opentelemetry/exporter/prometheus/__init__.py Co-authored-by: Aaron Abbott <[email protected]> * Fix lint * Remove resource check * Remove instrumentation_scope check * Group metrics by instrumentation scopes in the SDK * Remove label_keyss * Use strings instead of mocks * Return generator instead of a list * Fix lint * Rename variables Co-authored-by: Aaron Abbott <[email protected]>
Hmm im wondering if we should implement this grouping in the
Metric
exporter format (a breaking change) before we send it to the exporter.. Originally, I was thinking the flat representation would be easy to work with but it looks like the OTLP and Prom exporters are having to duplicate a lot of grouping logic.We could make it look more like the OTLP structure
Originally posted by @aabmass in #2639 (comment)
more context
Just for clarity, this what our current structure looks like in JSON:
Notice there is a single point per entry and minimal nesting. However, instrumentation_scope, resource, and some other stuff is present on every message where it could be grouped. Compare this to OTLP where things are nested and grouped:
The Python OTLP exporter has to do this grouping to get from our current structure to the real OTLP format. Prometheus has to do something similar. The first representation is closer to how things look in-memory for the metrics SDK.
Should we do this grouping and make the structure we expose to exporters closer to OTLP?
The text was updated successfully, but these errors were encountered: