-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Prometheus Exporter metrics with different tags should have only one HELP and TYPE comment line #5465
Comments
I cannot seem to reproduce this on 1.9.3 with this config as a test case:
Run up the container and curl the output:
|
Ah, this seems to be an issue with the Prometheus Exporter itself: it we use that with the recent Fluent Bit metrics input plugin then it generates invalid output:
Run and check then to see the incorrect output - make sure to expose the 2021 port now:
The webserver output is fine:
|
@patrick-stephens it works with default configuration, but the metrics are exported with endpoint /api/v1/metrics/prometheus instead of /metrcis. Is there a way to make it use /metrcis? |
I don't think so as those routes are part of the web server. Scrape config should handle it fine though, you just need to configure the path so it doesn't use the default on the Prometheus side |
thanks @patrick-stephens. I'll workaround it with other solution. Close the ticket for now. Thank you for help. |
I've re-opened this as it is a legitimate bug that will prevent use of the exporter. @leonardo-albertovich can you take a look? The issue seems to be the metrics are not grouped together for related things with the exporter output but they are for the web server. |
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days. Maintainers can add the |
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days. Maintainers can add the |
It seems that Prometheus and VictoriaMetrics can handle that situation well, however there are providers like Dynatrace which scrape only the first entry of every metric and drops the rest. As the new mechanism using the |
Ran into this bug today and confirmed that it is due to the It would be great if the |
I'm trying to pull in the fluentbit v2 metrics from fluentbit 3.1.3 into telegraf which uses the Go parser and am stuck because of this issue. It seems to only be with v2, which I need so that I can plot my storage buffer usages. |
I’ve encountered this issue as well, specifically with the inability to use storage metrics available exclusively in the API/v2. Resolving this would significantly improve our monitoring capabilities. I hope this issue can be prioritized in future |
👋🏽 Looks like more ppl want to use the new Prometheus endpoint, but can't, due to a broken exposition format implementation. Any updates on this, or at least pointers what are the challenges? (Not that it helps here, but I'm Prometheus maintainer here, open for feedback on our side how to make it easier for C codebases) |
I looked into this today, here's what I found. The problemWhen all the metrics are collected from each plugin, the cmt_cat function is used to append an entire cmt context into the single one that will eventually get sent down the line. This is done because each plugin gets its own separate cmt context, because each plugin has the opportunity to register its own metrics. However, each input, filter, and output plugin also sets up a set of default metrics separately in their own contexts. SolutionI began looking at this in an assistive capacity for another team; it isn't something that directly affects my work at this time. As such, it is unlikely I will be able to dedicate the time to develop and shepherd a fix myself. However, I've outlined what I think would be the two best possible ways to resolve this which someone else could take on. Proposal 1: Shared metrics context for each plugin typeOne path forward that I see is for all input plugins to share one metric context. This would be the same for filter and output plugins. In this case, the shared metrics context would be wrapped in a struct that also includes the addresses for each of the shared metrics, and when this shared context is passed into the initialization procedure of a new plugin instance, it simply records new values in the existing metrics. I wrote a proof of concept for this just for input plugins: #9231
You will see the resulting metrics being correctly grouped as the Prometheus Exposition Format specifies.
If this approach would make sense, I would hand it off to @shuaich, my coworker from the team trying to tackle this problem. I think it is a straightforward enough implementation that I could provide the guidance to do relatively simply. The only open question is thread safety; if using threaded input plugins, I'm not sure if the Proposal 2: Adjust
|
CC @edsiper @leonardo-albertovich to look over my proposals |
I've pushed a draft PR to CMetrics to fix this: fluent/cmetrics#222 For testing purposes, I created a test branch of Fluent Bit here:
folks, would you mind give it a try to the test branch ? any help is appreciated |
Hi @edsiper
I've also used the branch from #9360 to validate the fix.
Given that @shuaich already tested the Prometheus Golang scraper, I'd say the fix works. |
Bug Report
The exported Prometheus metrics with same name but different tags have duplicate HELP and TYPE comment lines.
According to https://prometheus.io/docs/instrumenting/exposition_formats/#text-format-details, it only allows one HELP/TYPE for any given metric.
To Reproduce
Expected behavior
Only one line of TYPE and HELP should be generated for fluent-bit output metrics. But there duplicate ones as in screenshot.
Screenshots
As in highlight above, there are duplicate TYPE/HELP comment lines.
Your Environment
Version used: 1.9.3
Configuration:
[OUTPUT]
Name http
Alias confiant
Match bids
...
[OUTPUT]
Name s3
Alias s3
Match bids
region {{ .Values.s3RegionForBids }}
bucket {{ .Values.s3BucketForBids }}
...
[OUTPUT]
Name prometheus_exporter
Alias exporter
match internal_metrics
...
Environment name and version (e.g. Kubernetes? What version?): K8S
Server type and version: EKS
Operating System and version: x86_64 Linux 5.4
Filters and plugins: no filters, output plugin as in configuration.
Additional context
It cause issues when we try to feed those metrics to our monitoring system, as according to https://prometheus.io/docs/instrumenting/exposition_formats/#text-format-details, it only allows one HELP/TYPE for any given metric.
The text was updated successfully, but these errors were encountered: