brian-brazil
Repos
57
Followers
808

The Prometheus monitoring system and time series database.

45722
7394

Prometheus instrumentation library for Python applications

3115
691

Blackbox prober exporter

3289
865

Prometheus instrumentation library for JVM applications

1878
706

SNMP Exporter for Prometheus

1113
485

Prometheus documentation: content and static site generator

538
863

Events

OpenMetrics Discovery Format

The way I would suggest to handle this with OpenMetrics is to fetch the metrics. It is intended that all the useful information is in-band and all available metrics should be exported, even if the metric family is empty right now. Expecting developers to expose metrics in two different ways is a bit hopeful I suspect, there's already challenges with getting metrics exported correctly one way - and if they're exported correctly that way then the information is already in the returned metrics as a given metric family should always be exposed.

Load is down to cardinality more than anything, a list of metadata is unlikely to tell you which metrics may be problematic in that regard.

Created at 3 weeks ago
Update project status (changed on 3rd Feb 2022)

Good spot, thanks for fixing!

Created at 4 weeks ago

Update project status (changed on 3rd Feb 2022) (#257)

cf https://www.cncf.io/blog/2022/02/03/cncf-cultivated-openmetrics-becomes-an-incubating-project/

Created at 4 weeks ago
pull request closed
Update project status (changed on 3rd Feb 2022)

cf https://www.cncf.io/blog/2022/02/03/cncf-cultivated-openmetrics-becomes-an-incubating-project/

Created at 4 weeks ago
Native histogram support in proto spec

From a very quick glance this looks okay for a future OM 2.0, other than the schema being required as the old way should still work. It probably only needs a little verbiage in the comments on how to tell which way is in use.

We may wish to do the renamings of the existing fields now in 1.x, to avoid future hassle when things are harder to change. I'm okay with that in principle as it should be fairly low impact now, however it may count as a breaking change. If the current Go accessors aren't right, we should probably fix that in 1.x though.

Created at 1 month ago
UNIT and HELP must not be present

That section of the spec is about the data model, not the wire format.

We don't force empty lines.

Created at 2 months ago
UNIT and HELP must not be present

From my Slack with Julien just now: I believe it should be

The current wording is what you argued for. The text is saying that the values must always be present, but HELP and UNIT can be empty.

Created at 2 months ago