Tags are a way of adding dimensions to metrics, so they can be sliced, diced, aggregated, and compared on the front end. Using tags enables you to observe aggregate performance across a number of hosts and (optionally) narrow the set further based on specific elements. In a nutshell, tagging is a method to scope aggregated data.
Typically, it’s helpful to look at containers, VMs and cloud infrastructure at the “service” level in aggregate. For example, it’s more helpful to look at CPU across a collection of hosts that represents a service, rather than CPU for server A or server B separately.
Containers and cloud environments regularly churn through hosts, so it is critical to tag these to allow for aggregation of the metrics you’re getting.
A few best practices on tags:
Tags must start with a letter, and after that may contain:
Other special characters get converted to underscores.
Note: A tag cannot end with a colon (e.g.,
Tags can be up to 200 characters long and support unicode.
Tags are converted to lowercase.
A tag can have a
value or a
For optimal functionality, we recommend constructing tags that use the
key:value syntax. The key is always what precedes the first colon of the global tag definition, e.g.:
role:database:mysqlis parsed as key:
role_database:mysqlis parsed as key:
Examples of commonly used metric tag keys are
source are reserved tag keys and cannot be specified in the standard way.
Tags may be added using any (or all) of the following methods:
We store one time series per host + metric + tag combination on our backend, thus we cannot support infinitely bounded tags.
Don’t include endlessly growing tags in your metrics, like timestamps or user ids. Limit each metric to 1000 tags.
Here is an example of tags using the time-series chart editor. For the first screenshot, no tags have been applied, and we’re observing average CPU across all hosts:
In this next example, we’ve applied a tag (region:eastus) that enables us to look at CPU across the US East Region. We’ve used region as an example, but you could use any arbitrary tag, including application, service, environment, etc.
In this last example, we’ve used the second empty field labeled as “everything” by option to show an individual timeseries line for each host. Now we’re seeing server CPU for individual hosts running in the US East Region.
We can also add additional tags to narrow down our scope even further - for example, hosts in
env:production. Tags are extremely powerful, and they are ubiquitous in Datadog. They can be applied to all core elements, including alerts and host maps.