metric custom name, description, unit, type...

[finkr]

Prometheus best practices recommend how to name metrics. VMware's metric naming is different.

It would be nice to be able to expose metric according to those best practices.

The jmx_exporter has the same challenge of converting upstream metrics in Prometheus format so might be worth looking how they implemented that.

Let's focus on some aspects:

Prometheus recommend that metrics have a suffix describing the unit.

-> It would be nice to be able to specify the target metric name for each metric collected.

Prometheus also recommend to use base units (e.g. seconds, bytes, meters - not milliseconds, megabytes, kilometers)

-> It would be nice to be able to specify a multiplier factor for each metrics to convert Megabyte to byte or millisecond into seconds (jmx_exporter use valueFactor).

Finally it would be nice to specify the metric type (GAUGE, COUNTER) and description.

[cblomart]

I wouldn’t let everyone decide for themselves otherwise the install base might become a chaos. VSphere should have some information on metrics (units).
As for metric names I believe that there is somthing alike possible although VMware already suffixes metrics with a roll up type so metric may not be last in the name...
I still need to look at this in more details...

[finkr]

Some context...

The Prometheus exposition format is becoming a defacto standard (there are some efforts to standardize it as OpenMetrics) . It's already supported by many of monitoring/observability/APM solutions (InfuxData,InfluxDB, DatadogHQ, Google Stackdriver NewRelic is looking at providing it, etc ... and Prometheus derivative projects like Cortex, Thanos. There are also lots of applications that implement introspection... as you may know.

There are currently many projects to collect VMware/vSphere/vCenter/ESX/ESXi metrics... but none is really ahead (FYI : vmware_exporter which is Python based, vsphere-metrics-prometheus in GO but it's stalled)

A few features in vsphere-graphite would turn it in a first class citizen in the Prometheus world (leading to broader adoption).

So, back to the install base chaos risk

Externalizing the list of metrics to collect to a configuration file was a good design choice (cherry-picking metrics on large VMware infrastrcture).

I guess most people would just use the provided configuration file. There would be one file for Prometheus-compatible tools and another file for other backend.

People who decide to customize a configuration file heavily have to accept to maintain it (Freedom <-- responsibility).