-
Notifications
You must be signed in to change notification settings - Fork 2.8k
receiver/promettheusreceiver: add option to the metric adjuster to fallback to collector start time #36364
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
Comments
Pinging code owners for receiver/prometheus: @Aneurysm9 @dashpole. See Adding Labels via Comments if you do not have permissions to add labels yourself. For example, comment '/label priority:p2 -needs-triaged' to set the priority and remove the needs-triaged label. |
cc @ArthurSens |
This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
…ttime (open-telemetry#36365) #### Description This change adds an option to the metric adjuster to use an approximation of the collector starttime as a fallback for the start time of scraped cumulative metrics. This is useful when no start time is found and when the collector starts up alongside its targets (like in serverless environments or sidecar approaches). <!-- Issue number (e.g. open-telemetry#1234) or full URL to issue, if applicable. --> #### Link to tracking issue Fixes open-telemetry#36364 <!--Describe what testing was performed and which tests were added.--> #### Testing Added unit test for this config option <!--Describe the documentation added.--> #### Documentation Config option added to the README. --------- Signed-off-by: Ridwan Sharif <[email protected]>
…ttime (open-telemetry#36365) #### Description This change adds an option to the metric adjuster to use an approximation of the collector starttime as a fallback for the start time of scraped cumulative metrics. This is useful when no start time is found and when the collector starts up alongside its targets (like in serverless environments or sidecar approaches). <!-- Issue number (e.g. open-telemetry#1234) or full URL to issue, if applicable. --> #### Link to tracking issue Fixes open-telemetry#36364 <!--Describe what testing was performed and which tests were added.--> #### Testing Added unit test for this config option <!--Describe the documentation added.--> #### Documentation Config option added to the README. --------- Signed-off-by: Ridwan Sharif <[email protected]>
Uh oh!
There was an error while loading. Please reload this page.
Component(s)
receiver/prometheusreceiver
Is your feature request related to a problem? Please describe.
When scraping prometheus metrics, there often are no start times associated with the cumulative metrics.
There is a metric adjuster that allows the configurer to specify another metric name from which to pull start time for all metrics scraped but I believe its useful to have a fallback mechanism to fall back to the collector start time.
This is useful especially in serverless workloads or workloads where the collector runs as a sidecar to the target being scraped. We currently use this approach for Cloud Run observability in https://github.com/GoogleCloudPlatform/run-gmp-sidecar/ and its been very useful there.
Describe the solution you'd like
An option added to the config, something like
UseCollectorStartTimeFallback
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: