Gauge without label should not have a default value of 0 (zero)

[thomaschaaf]

A gauge that is registered but does not have a value set is currently set to 0 (zero). I believe this behavior to be incorrect because a gauge without a label does not work like it.

const client = require('prom-client');
const gauge = new client.Gauge({ name: 'metric_name', help: 'metric_help', labelNames: ['example'] });
const gauge2 = new client.Gauge({ name: 'metric_name2', help: 'metric_help2' });

console.log(await client.register.metrics())

gauge.set({ example: 'true' }, 1)

console.log(await client.register.metrics())

gauge.reset();

console.log(await client.register.metrics())

Output 1 after initialization:

# HELP metric_name metric_help
# TYPE metric_name gauge

# HELP metric_name2 metric_help2
# TYPE metric_name2 gauge
metric_name2 0

Output 2 after setting gauge:

# HELP metric_name metric_help
# TYPE metric_name gauge
metric_name{example="true"} 1

# HELP metric_name2 metric_help2
# TYPE metric_name2 gauge
metric_name2 0

Output 3 after reset:

# HELP metric_name metric_help
# TYPE metric_name gauge

# HELP metric_name2 metric_help2
# TYPE metric_name2 gauge
metric_name2 0

I would expect the output 1 of both gauges to be the same and instead of a default of 0 having a default of undefined.

[jdmarshall]

I am very confused by this feature. I cannot imagine a situation where I'd want metrics with absolutely no labels in the first place. I'm going to have a peek at the Prometheus docs to see what if anything they have to say about it. You always want at least one tag if you have more than one machine, and probably at least 2 if you're doing CI/CD so you know if all the errors are coming from the deployment/canary.

I've already said that the benchmarks with 0 labels are providing misinformation that has encouraged several contributors to submit PRs that move us in the wrong direction.

The v0.16 release will show a performance regression for them because it makes labeled metrics much faster to do more work during the constructor, at a small but noticeable cost for metrics with no labels.

[zbjornson]

It's not unusual. Sometimes the automatically generated labels (job, instance) and/or ones created using relabeling rules during collection are the only ones used.

[jdmarshall]

It's not unusual. Sometimes the automatically generated labels (job, instance) and/or ones created using relabeling rules during collection are the only ones used.

So not at the point of recording, nor the registry defaults, but at the point of aggregation. Hmm..

[jdmarshall]

I’m inclined to believe that counters should initialize to 0. Both logically and for performance reasons as they remove conditional logic from inc().

But gauges should not. Zero could trigger alerts, particularly for situations where larger numbers are better. That is the minority of gauges, and you can probably initialize them to a useful value before a metrics call is run to keep the initial value from escaping. I wonder how expensive this will be to change.