Metric and label naming

A metric name…

…must comply with the for valid characters.
…should have a (single-word) application prefix relevant to the domain the metric belongs to. The prefix is sometimes referred to as by client libraries. For metrics specific to an application, the prefix is usually the application name itself. Sometimes, however, metrics are more generic, like standardized metrics exported by client libraries. Examples:
- **prometheus**_notifications_total (specific to the Prometheus server)
- **http**_request_duration_seconds (for all HTTP requests)
…must have a single unit (i.e. do not mix seconds with milliseconds, or seconds with bytes).
…should use base units (e.g. seconds, bytes, meters - not milliseconds, megabytes, kilometers). See below for a list of base units.
…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**
- process_cpu_**seconds_total** (for an accumulating count with unit)
- foobar_build**_info** (for a pseudo-metric that provides metadata about the running binary)
…should represent the same logical thing-being-measured across all label dimensions.
- request duration
- bytes of data transfer
- instantaneous resource usage as a percentage

Use labels to differentiate the characteristics of the thing that is being measured:

api_request_duration_seconds - differentiate request stages: stage="extract|transform|load"

CAUTION: Remember that every unique combination of key-value label pairs represents a new time series, which can dramatically increase the amount of data stored. Do not use labels to store dimensions with high cardinality (many different label values), such as user IDs, email addresses, or other unbounded sets of values.