What are best practices to name metrics and tags?

It’s important to spend some time to model out the naming convention you pick. Ideally you should start by thinking about what problem are you trying to solve.

The general guidance is that metric names explain the unit or type of the measurements and tags represent meta data of the metric or detail of the metric stream.

Here are some examples:

This metric contains information on CPU Usage and the tags indicate where the metric stream originated from:

metric: “cpu_usage”
tags:
“environment”: “production”
“role”: “web”
“unique_id”: 11

This metric contains information about how many times an application was launched and the tag set provides information about where the app was launched.

metric: “app_name.version_3.launch”
tags:
“os_version”: “android_4.2”
“device”: “samsung_s_7”

This metric contains temperature data and the tag set indicates where that data was collected.

metric: “temperature.celsius”
tags:
“region”: “EU”
“city”: “Berlin”

Naming limitations for tags and metrics

Metric and Tag names must be safe to use as part of a URL.

  1. Metric names must be 255 or fewer characters, and may only consist of A-Za-z0-9.:-_. The metric namespace is case insensitive.
  2. Tag names must match the regular expression /A[-.:_w]+z/{1,64}. Tag names are always converted to lower case.
  3. Tag values must match the regular expression /A[-.:_w ]+z/{1,255}. Tag values are always converted to lower case.

Recommendations:

  1. Avoid extremely short names. Be as descriptive as you can be.
  2. Metrics with large numbers of unique metric streams are difficult to visualize. Consider aggregating multiple streams with a common tag set into a single stream.
  3. Metrics are designed to handle numeric data. Annotations are designed to handle events that occur at a point in time or span a window of time.