Units in (prometheus) exported metric names.

[tcolgate]

I suspect this is too late on several levels, but is it worth considering including units in the exported metrics (at least via prometheus)? This is strongly encouraged in the prometheus best-practice guides and has been one of the most pleasant thing about working with prometheus, and applications that follow the guidelines.

For instance:

opencensus_io_http_server_latency_milliseconds_bucket

They are usually in the plural form so opencensus_io_http_server_request_count would be opencensus_io_http_server_requests_count, (actually the guidelines would normally have the suffic as _total rather than _count, but _count is probably clearer, and consistant with the histogram output).

It's a bit nit-pickey, but it makes the work of difference to have a consistant way of inferring meaning from a metric name.

[semistrict]

I don't think it's too late to have this as an opt-in option. For Go, I would suggest we add a formatter function to the exporter something like:

e := prometheus.NewExporter(..)
e.NameFormatter = func(v *view.View) string {
  return fmt.Sprintf("%s_%s", v.Name, v.Unit)
}

[brian-brazil]

I'd suggest including units everywhere by default, the problem of unclear units isn't a Prometheus-specific issue and I've run into it in basically every monitoring system I've used (and not just the metrics-based ones).

(actually the guidelines would normally have the suffic as _total rather than _count, but _count is probably clearer, and consistant with the histogram output).

This is a question of whether it's a counter or a summary/histogram. Given the metric name I'd presume that's a counter, so should be _total.

[tcolgate]

I /think/ the formatter could use View.,Aggregation.Type to switch the suffix. Obvously I'd prefer the defaults to follow the best practice.

it's not obvious to me if the name is chosen by the exporter, or should be "standard" accross exporters (the latter seems unlikely since different systems have very different representations for names). It could be that this could just be a fix to the prometheus exporter, especially if delaring units is already enouraged/mandatory.

[songy23]

it's not obvious to me if the name is chosen by the exporter, or should be "standard" accross exporters (the latter seems unlikely since different systems have very different representations for names).

Correct, in fact Stackdriver Monitoring has a clear notion of "Unit", and we set this field explicitly in our Stackdriver exporter, instead of appending the unit as part of the metric name (e.g Go). Unfortunately this is not the case for Prometheus data models.

[tcolgate]

@songy23 in that case would it be more correct to just bite the bullet and update all the prometheus exporters to include the unit in exported metrics? That seems like a big change, but if other systems already have a notion of units, prometheus exporters to reflect that too in the most idiomatic way for prom (otherwise the unit info is just being thrown away).

[songy23]

@tcolgate I'm fine with adding unit to Prometheus metric name, given that this is also described as the best practice for naming Prometheus metrics:

A metric name... ...should have a suffix describing the unit, in plural form. Note that an accumulating count has total as a suffix, in addition to the unit if applicable. http_request_duration_seconds node_memory_usage_bytes http_requests_total (for a unit-less accumulating count) process_cpu_seconds_total (for an accumulating count with unit)

[rakyll]

The canonical unit string for unit-less cases we use is "1" but this is deep down documented at http://unitsofmeasure.org/ucum.html and is not very visible. Can we provide a constant for the unit-less unit so users don't set it incorrectly to "". Or we can consider empty string as unit-less when exporting to Prometheus.