proposal: Prometheus internal telemetry as an OTel semantic convention registry - #86
Conversation
459e052 to
293d5de
Compare
|
I would like to assess what alternatives we have that could be built-in e.g. client_golang and would be lighter. And I would also want to better understand the scope of this: |
63633cc to
52b69ae
Compare
@roidelapluie thanks for comment, I've updated a few things in the doc aiming to cover what you raised, let me know your thoughts |
ArthurSens
left a comment
ArthurSens
left a comment
There was a problem hiding this comment.
Had some minutes in the airport to review this, it's not a complete review though 😅
| * [Required] Define Prometheus' internal telemetry as a formal OTel semantic convention registry (a single `registry.yaml`), making it the single machine-readable source of truth for every metric Prometheus exposes. | ||
| * [Required] Generate instrumentation code from the registry, eliminating hand-written metric definitions in Go. | ||
| * [Required] Generate metric documentation from the registry that cannot drift from the implementation. | ||
| * [Nice to have] Enable contract testing through `promtool`: validate that a running Prometheus exposes exactly what the registry says, with no OTel Collector and no Weaver binary in the test path. |
There was a problem hiding this comment.
why not use the tools that already exist for this? 🙃
There was a problem hiding this comment.
live-check is an explicit alternative now instead of a buried paragraph. It wants a Collector in the test path and asserts against post-translation OTLP, so a translation bug reads as a registry violation. A Go test off Describe() runs where every other test already runs.
| The primary surface is `promtool`. It already reads text exposition from stdin, already runs `promlint` over it, and already exits 3 when it finds problems: | ||
|
|
||
| ``` | ||
| curl -s http://localhost:9090/metrics | promtool check metrics --schema registry.yaml |
There was a problem hiding this comment.
By default, Prometheus does not emit all metrics it is instrumented with. For example, if Remote Write isn't configured for an instance, it won't expose any Remote Write metrics.
What would happen in that situation, should check metrics fail because the metric exists in the schema but not in the /metrics endpoint?
There was a problem hiding this comment.
It also exposes other metrics that aren't Prometheus related, like go and http metrics, what happens in these situations?
There was a problem hiding this comment.
Good catch, both cases break it. Cut the whole section and --schema, this is not related to the adoption of a registry anyway.
…n registry Define every metric the Prometheus binary exports in one OTel semantic convention registry. Generate the instrumentation code and the docs from it, check the code against it with a Go test in CI, and publish it so downstream projects can check their own metric references. Contract testing reads Collector.Describe() rather than a scrape, because a running instance emits far less than it declares and a scrape cannot show units or the const-versus-variable label split. That path also catches a metric that was defined but never registered, which code generation cannot prevent. Signed-off-by: Nicolas Takashi <nicolas.takashi@dash0.com>
9ab6b19 to
fbf87b5
Compare
3 participants
This proposal defines all metrics exported by the Prometheus binary as a formal OTel semantic convention registry. Making the schema machine-readable enables auto-generated instrumentation code, always-in-sync documentation, contract testing against live instances, and a lifecycle model for safe metric evolution across the Prometheus ecosystem.
Proof-of-concept implementation: prometheus/prometheus#17868