Comments (8)
It is somewhat surprising that the metric name provided to counter constructors will have _total
appended to it automatically. It would be cool if that were better documented, and ideally only happened if the provided metric name didn't already end in _total
.
from client_rust.
The
HELP
andTYPE
lines should usemy_counter_total
, notmy_counter
.
Not according to the OpenMetrics specification:
https://github.com/OpenObservability/OpenMetrics/blob/main/specification/OpenMetrics.md#counter-1
It is somewhat surprising that the metric name provided to counter constructors will have
_total
appended to it automatically. It would be cool if that were better documented, and ideally only happened if the provided metric name didn't already end in_total
.
Good idea. For the former, would you mind extending the documentation @08d2? For the latter, let's move the discussion to #52.
from client_rust.
Not according to the OpenMetrics specification
I don't know anything about OpenMetrics, really, and I don't consider it any kind of authority. I can observe that the "_created" thing described in your link is not valid for Prometheus, though.
edit: Ah, reading more carefully....
# TYPE foo counter
foo_total 17.0
AFAIK, this is not compatible with the Prometheus exposition format. For Prometheus, the identifier after e.g. TYPE
and HELP
tokens must be the actual name of the metric. And HELP
is mandatory.
# TYPE foo_total counter
# HELP foo_total Total number of foo events.
foo_total 17.0
from client_rust.
AFAIK, this is not compatible with the Prometheus exposition format.
Note that you need to set the right content type in order for Prometheus parse the output of a scrape in the Open Metrics format.
Line 37 in 69e6674
from client_rust.
We have ~100 unsuffixed metrics at work and we are trying to move away from prometheus
and to switch to prometheus-client
, this automatic suffixing is an issue, we don't want to change dozens of dashboards because a library forces counter renames on us. Would you accept a PR adding a LegacyUnsuffixedCounter<A>
type to this crate?
from client_rust.
Would you accept a PR adding a
LegacyUnsuffixedCounter<A>
type to this crate?
That sounds reasonable. I would suggest we add the above type under a feature flag (e.g. prometheus-legacy-format
).
Note that I would see this as a small helper to enable folks to migrate to the OpenMetrics format eventually. I don't see this as a long term solution for downstream users. Do you agree with that mind set @nox?
//CC @RichiH in case you have opinions.
from client_rust.
I can understand the resistance to changing names, but also note that following best current practices earlier rather than later is usually Least Bad, long term.
The proposed seems like a partial undoing of one specific thing, not a full Prometheus exposition format 0.0.4; that's arguably the worst of both worlds globally, even though it may appear to make sense locally.
All that being said, no strong opinions on if this is implemented or not.
from client_rust.
Note that I would see this as a small helper to enable folks to migrate to the OpenMetrics format eventually.
OpenMetrics remains an experiment, not a standard. Prometheus client libraries should default to the core exposition formats, and leave OpenMetrics as an opt-in alternative.
from client_rust.
Related Issues (20)
- Allow flattening of a struct through derive(EncodeLabelSet) at any position HOT 2
- Make `Descriptor::new` `const` HOT 1
- feat: derive register logic on struct of metrics
- Allow multiple labels in sub_registry_with_label method HOT 2
- Allow root registry creation with prefix AND label(s) HOT 1
- Implement native histograms HOT 1
- Escaping? HOT 3
- Public encoding functions? HOT 4
- Encoder without EOF HOT 5
- Custom Collector with `sub_registry_with_prefix` outputs name multiple times HOT 3
- Abstract key lookup into a trait for Family::get_or_create HOT 4
- Allow iterating the metrics on an registry HOT 1
- Allow construct a histogram family with a closure HOT 2
- mips: EncodeCounterValue implementation missing for u32?
- Histogram with empty family labels creates unparseable metrics output HOT 1
- text::DescriptorEncoder writes incorrect metric names HOT 2
- UTF-8: Implement support in Rust client library
- Implement Atomic for usize HOT 2
- Counter `HELP` and `TYPE` lack `_total` suffix HOT 5
- Provide a way to prevent unbounded metric growth HOT 4
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 client_rust.