Tags are a way of adding dimensions to metrics, so they can be filtered, aggregated, and compared in Datadog visualizations. Using tags enables you to observe aggregate performance across a number of hosts and (optionally) narrow the set further based on specific elements. In summary, tagging is a method to observe aggregate data points.
Tagging binds different data types in Datadog, allowing for correlation and call to action between metrics, traces, and logs. This is accomplished with reserved tag keys. Here are some examples:
|Tag Key||Allows for|
||Correlation between metrics, traces, processes, and logs|
||Segregation of metrics, traces, process, and logs by device or disk|
||Event filtering and automated pipeline creation for log management|
||Correlation between metrics, traces, and logs|
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 usage across a collection of hosts that represents a service, rather than CPU usage 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.
Below are Datadog’s tagging restrictions, requirements, and suggestions:
Tags must start with a letter and after that may contain the characters listed below:
Other special characters are converted to underscores.
Note: A tag cannot end with a colon, for example
Tags can be up to 200 characters long and support Unicode.
Tags are converted to lowercase. Therefore,
CamelCase tags are not recommended. Authentication (crawler) based integrations convert camel case tags to underscores, for example
A tag can be in the format
<KEY>:<VALUE>. For optimal functionality, we recommend constructing tags in the
<KEY>:<VALUE> format. Commonly used tag keys are
name. The key always precedes the first colon of the global tag definition, for example:
Reserved tag keys
service cannot be used in the standard way.
Tags shouldn’t originate from unbounded sources, such as EPOCH timestamps, user IDs, or request IDs. Doing so may infinitely increase the number of metrics for your organization and impact your billing.
Tags may be assigned using any (or all) of the following methods. Refer to the dedicated Assigning Tags documentation to learn more:
|Configuration Files||Manually in your main agent configuration files, or in your integrations configuration file.|
|Environment Variables||Using environment variables for the containerized Agent|
|UI||In your Datadog platform|
|API||Using Datadog’s API|
|DogStatsD||When submitting metrics via DogStatsD|
|Integration Inheritance||Automatically with supported integrations after setup|
After you have assigned tags at the host and integration level, start using them to filter and group your metrics, traces, and logs. Tags are used in the following areas of your Datadog platform. Refer to the dedicated Using Tags documentation to learn more:
|Area||Use Tags to|
|Events||Filter the event stream|
|Dashboards||Filter and group metrics on graphs|
|Infrastructure||Filter and group on the host map, infrastructure list, live containers, and live processes views|
|Monitors||Manage monitors, create monitors, or manage downtime|
|Metrics||Filter and group with the metric explorer|
|Integrations||Optionally limit metrics for AWS, Google Cloud, and Azure|
|APM||Filter trace search and analytics or jump to other areas with the service map|
|Notebooks||Filter and group metrics on graphs|
|Logs||Filter logs search, analytics, patterns, live tail, and pipelines|
|Developers||Pull information or setup different areas in the UI with the API|