Comments (7)
This has to take into account special float formatting. (An integer number that is actually typed as a float always has to end on .0
or has to contain an e
. Note that histogram buckets are types as int.)
Also, OpenMetrics suffers from name collisions (due to additional "magic" suffixes of the metric name: _created
, _total
). The generator has to detect those collisions to avoid creating invalid output.
from common.
An integer number that is actually typed as a float always has to end on .0 or has to contain an e. Note that histogram buckets are types as int.
As currently drafted this only strictly applies to le
and quantile
labels - and even that is not finalised as to whether it'll be a SHOULD or MUST. I'd hope the Go client would be a good example that others can follow though, considering it'll likely be the most used.
from common.
Hmm, I would have thought it's also quite important for sample values. Following line of thought:
- The unambiguous marking of int vs float is meant for consumers that, unlike Prometheus, distinguish between int and float as a sample value.
- Those consumers will register a newly appearing time series as one or the other, depending on the first sample. Let's say it's 1.234, i.e. float.
- If then suddenly a sample comes in that reads 1 (instead of 1.0), they will be confused.
- The other way round is probably worse: Get an int first, filing it as an int series, and then suddenly floats come in.
In contrast, I would see le and quantile labels as unproblematic because they are always floats. And since we have no proven way of unambiguous float formatting (see OpenObservability/OpenMetrics#129 ), those labels have to be sanitized be the consumer anyway before series identity is determined. (In different news, a more advanced consumer, including possibly a future version of Prometheus, will not treat the quantiles and buckets as separate series anyway, so those labels aren't really labels anymore, and the whole problem disappears.)
from common.
If then suddenly a sample comes in that reads 1 (instead of 1.0), they will be confused.
But must handle it, as while it'd be not recommended each output is still individually valid - and can happen for good reasons such as due to a new binary release.
The other way round is probably worse:
Yeah, that's more of a problem. Same considerations apply though.
I'd treat it as a compression hint more than anything. We should be nice to consumers where practical though - especially given the prominence of client_golang.
so those labels aren't really labels anymore, and the whole problem disappears
That's the dream, once we manage to get most other monitoring system vendors able to understand our style of histograms.
from common.
Basic OpenMetrics generation is implemented now.
I'll update the issue description to include the remaning TODOs. (We could break them into separate issues and close this one if that's preferred.)
from common.
This issue is fine, the OP is nicely organised.
We also need to drop _sum when there's negative buckets.
from common.
We also need to drop _sum when there's negative buckets.
It would be a pity if OM really went down that road. See OpenObservability/OpenMetrics#143 for a better solution.
from common.
Related Issues (20)
- Support environment variable for log level and format
- New release? HOT 3
- Implement changes needed to support UTF-8 metric and label names in Prometheus
- OAuth 2 client_secret should be optional
- LabelSet.String sorts incorrectly HOT 2
- Authorization credentials should be optional
- Update expfmt/text_parse.go to support the new UTF-8 syntax HOT 14
- SigV4 panics on GET requests / requests with nil body
- web: Support jwt/bearer token auth
- Breaking change in 0.48.0 HOT 10
- Version bump in prometheus/common breaks client_golang build HOT 3
- Prometheus failing to reload Probe TLS cert and key from disk HOT 2
- Prevent incompatibility issues between common and dependent repositories HOT 5
- OpenMetrics: _total suffix repeated multiple times HOT 7
- "error encoding and sending metric family" on HTTP/2 HEAD request
- Can client.key be removed as its giving security blocker in security scan? HOT 1
- Support for: INFO type
- Support for configuring ciphersuites in tls_config
- `FmtText` was removed between v0.42.0 and v0.53.0 HOT 1
- Consolidate content type and content encoding functions in prometheus/common HOT 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from common.