Metric and label naming

• …must comply with the data model for valid characters.
• …should have a (single-word) application prefix relevant to the domain themetric belongs to. The prefix is sometimes referred to as byclient libraries. For metrics specific to an application, the prefix isusually the application name itself. Sometimes, however, metrics are moregeneric, 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.
  • httprequest_durationseconds
  • processcpuseconds_total(for an accumulating count with unit)
  • foobar_build_info(for a pseudo-metric that provides about the running binary)
• …should represent the same logical thing-being-measured across all labeldimensions.
  • request duration
  • bytes of data transfer
  • instantaneous resource usage as a percentageAs a rule of thumb, either the sum() or the avg() over all dimensions of agiven metric should be meaningful (though not necessarily useful). If it is notmeaningful, split the data up into multiple metrics. For example, having thecapacity of various queues in one metric is good, while mixing the capacity of aqueue with the current number of elements in the queue is not.

• api_request_duration_seconds - differentiate request stages: stage="extract|transform|load"Do not put the label names in the metric name, as this introduces redundancyand will cause confusion if the respective labels are aggregated away.