-
Notifications
You must be signed in to change notification settings - Fork 171
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
Add a README entry on how OM relates to the wider CNCF ecosystem #137
Comments
No relation at all. If we get a bit deeper, OpenGTelemetry covers creation and propagation of spans, traces, metrics and so, but lacks a standard format for metric exposition (or atleast that I know of). This is where OpenMetrics comes in to define a standard around metrics exposition. @mtwo can you help confirm the understanding, and may be add a pointer around this on the Readme.md |
OpenTelemetry plans to expose metrics in the OpenMetrics format, but as @mardan says the scope of the projects is different. |
I will add something to the readme. |
OpenTelemetry offers a reference implementation for traces and metrics today with partial support for logs (full support coming). Otel has its own wire format called OTLP. Otel is vendor-agnostic so it supports converting OTLP into another format (e.g. Jaeger or Prometheus). Given Otel supports Prometheus and does so using Prometheus libraries it supports OM. As I understand it, OM is primarily a wire format for Prometheus today -- others could pick it up. Thus, Prometheus and OM just represent a destination for Otel to support, one of many. The only question is the feasibility of converting from OM to Otel and from Otel to OM. As it turns out, the Otel Collector and Otel Go client library both leverage
It does today when you configure a Prometheus receiver or exporter.
Probably not -- OM was a standard that came out of Prometheus while OTLP is a standard that came out of OpenCensus/OpenTelemetry. Otel offers a vendor-agnostic implementation that can be extended. It was designed to support more than one standard for scenarios like this. For example, the W3C trace-context is a standard that is not part of Otel, but Otel supports. |
README not updated yet. Please note that Datadog implemented OM support with the help of our reference implementation and no further help from us. |
Update: the notes from the OTel <> OpenMetrics meeting on 2020-12-02 are available |
Could not find any updates to ReadMe in this regard. |
How does this relate to OpenTelemetry ?
The text was updated successfully, but these errors were encountered: