-
Notifications
You must be signed in to change notification settings - Fork 125
SMI Metrics and OpenTelemetry #199
Comments
Do you have a desire to use OpenTelemetry to instrument SMI implementations? If so, we could absolutely talk about how to make that possible. I've been working on the OpenTelemetry specification, especially on semantic conventions for metrics. We have conventions defined already for system metrics and metrics related to HTTP operations and we're working on conventions related to database, messaging, rpc, FAAS, and generic operations. We could absolutely define some semantic conventions for SMI metrics as well. It would be worthwhile to discuss your requirements. What shape will the metrics be? What units will you need? Will our labeling system be sufficient for your needs, etc... |
Thanks a lot @justinfoote and as I said on Gitter I'm more than welcome to be the liaison for this. |
I think the ideal scenario here is where there is an SMI receiver that is available on https://github.com/open-telemetry/opentelemetry-collector-contrib so that we can easily bring SMI-compliant metrics in OpenTelemetry Collector. I already have the first use-case which is kedacore/http-add-on#354 where we want to standardize on OpenTelemetry's collector to use as a single-source of truth for traffic metrics in KEDA. Happy to join the standup to discuss if you want. |
Any thoughts on this idea to leverage an SMI receiver? |
We discussed SMI Metrics recently and the question came up how we can align with OpenTelemetry in this respect.
The text was updated successfully, but these errors were encountered: