-
Notifications
You must be signed in to change notification settings - Fork 378
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
Not all the default collectors respect the timestamps: false
configuration
#310
Comments
The README makes ref to the unit tests to see which ones support stripping timestamps, I suspect that it was just that since it took custom modification of each metric, it never happened. Perhaps that means it should be implemented differently? That the registry should itself know that the timestamps are not desired, and thus ignore the timestamp passed in from the collector? Just a suggestion, I haven't had time to look closely at that part of the code, though I've read through many of the default collectors by now. Its not completely clear to me that any timestamp support at all is needed, unless its intended for batch processing jobs? |
It's for batch and push gateways, yeah. They're generally discouraged though. Happy to take a PR disabling timestamps on a registry level, that makes sense to me. @siimon @zbjornson thoughts? |
Given this from #177
I thought we should just remove all timestamp code from this repo? |
Options are:
I think 1. is probably the right way to go, but don't want to write an unlandable PR. @SimenB @zbjornson Should I remove the timestamping? If so, I assume its supported in the low level gauges/histograms/etc. -- should it get removed from there so its not possible for anyone to do anymore, or just remove it from all the built in metrics? |
#1 is my vote, yeah, and I think we might as well remove it all the way down to the lowest level. No point in having unused/unusable code. Appreciate all your recent work! |
The workaround for #177 is
But not all metrics support this, these did not:
I think this is a known bug, its mentioned in the tests, but I couldn't find an issue for it. Sorry if its a duplicate.
prom-client/test/defaultMetricsTest.js
Lines 74 to 79 in cc9ce78
The text was updated successfully, but these errors were encountered: