Use tags to filter metrics to display in a dashboard graph, or to create aggregated groups of metrics to display. To filter the metrics to display, enter the tag in the from text box. This metric displays over all sources that have that particular tag assigned (service:web-store in the example below).

Advanced tag value filtering is also available with boolean filters. The following boolean syntax is supported:

• NOT, !
• AND, ,
• OR
• key IN (tag_value1, tag_value2,...)
• key NOT IN (tag_value1, tag_value2,...)

Use AND, ORs to look at a metric across specific tags:

Use IN, NOT IN to quickly filter a metric down to specific tags:

To create an aggregated group using tags, enter the key part of the tag in the avg by text box. For example, if you have a timeseries graph showing a metric tagged with the key service, such as service:web-store, enter service in the avg by text box to show one line for each service tag value. Each line represents the average metric value across all sources that share that service tag value.

Tags can also be used to overlay events on the dashboard. This works the same way as in the Events Explorer. The matching events are overlaid as vertical bars on the graph. The example below uses service:web-store.

Use template variables to save time switching the from tag on graphs in your dashboard. In the example below, service is used to represent the service tag key. To use the template variable, add the $service template variable in the from text box of your graph query.

Here is an example of tags using the timeseries graph editor. For the first screenshot, no tags have been applied, and the average CPU usage across all hosts is displayed:

Next, the editor is updated to include a tag (region:eastus) in the from text box that enables Datadog to look at CPU usage across the US East region. The region tag is used as an example here, but you could use any arbitrary tag sent to your Datadog platform, including application, service, or environment.

Finally, the second empty field (the avg by text box) is used to show an individual timeseries line for each host. Server CPU is displayed for individual hosts running in the US East region.

If needed, add additional tags to narrow down the scope even further—for example, hosts in region:eastus and env:production. Tags can be used throughout Datadog and be applied to all core elements (metrics, traces, and logs).

Under this section, use tags to filter or group Hosts:

Or Containers:

Here are the filter and group by text boxes on the Infrastructure List page:

Here are the filter and group by text boxes on the Live Containers page:

Here are the filter and group by text boxes on the Live Processes page:

The AWS integration tile has the tag filters to hosts with tag and to Lambdas with tag.

These fields accept a comma separated list of tags (in the form <KEY>:<VALUE>) that defines a filter, which is used for collecting your EC2 or Lambda resources. You can use these <KEY>:<VALUE> to both include and exclude functions based from monitoring based on tags. To specify that tag should be excluded, add a ! before the tag key. You can also use wildcards, such as ? (for single characters) and * (for multiple characters).

The filters include resources where any inclusion tag is present by using an OR statement. The following example filter collects EC2 instances that contain the tag datadog:monitored OR env:production:

datadog:monitored,env:production

If you specified an exclusion a tag, it takes precedence and forms an AND statement. The following example filter collects EC2 instances that contain the tag datadog:monitored, OR env:production, OR an instance-type tag with a c1.* value AND NOT a region:us-east-1 tag:

datadog:monitored,env:production,instance-type:c1.*,!region:us-east-1

Read more about AWS tagging in the EC2 and Lambda documentation.

The Azure integration tile has the tag filter Optionally filter to VMs with tag.

This field accepts a comma separated list of tags (in the form <KEY>:<VALUE>) that defines a filter, which is used for collecting metrics from Azure VMs. You can also use wildcards, such as ? (for single characters) and * (for multiple characters). Only VMs that match one of the defined tags are imported into Datadog. The rest are ignored.

VMs matching a given tag can also be excluded by adding ! before the tag, for example:

datadog:monitored,env:production,!env:staging,instance-type:c1.*

The Google Cloud integration tile has the tag filter to hosts with tag.

This field accepts a comma separated list of GCP labels (in the form <KEY>:<VALUE>) that defines a filter, which is used for collecting metrics from GCP. You can also use wildcards, such as ? (for single characters) and * (for multiple characters). Only hosts that match one of the defined labels are imported into Datadog. The rest are ignored.

You can exclude hosts matching a given label by adding ! before the tag, for example:

datadog:monitored,env:production,!env:staging,instance-type:c1.*

Read more about Creating and managing labels in the Google Cloud documentation.

In the Trace Explorer, you can filter traces with tags using the search bar or facet checkboxes. The search bar format is <KEY>:<VALUE>, for example: service:coffee-house. For advanced search, see Query Syntax.

After assigning tags, use the Service Map to navigate to different areas of the application by clicking on a particular service. In the example below, view Analytics, Monitors, Logs, and the Host Map filtered by the tag service:coffee-house.

The Synthetic Tests page lists your Synthetic tests.

To filter tests by tags, use the search bar or facet checkboxes. The search bar format is <KEY>:<VALUE>. For example: tag:mini-website. For advanced search, see Search and Manage Synthetic Tests.

The Synthetic Monitoring & Continuous Testing Explorer displays your test runs and batches of runs in a CI pipeline.

To filter test runs by tags, use the search bar or facet checkboxes. The search bar format is <KEY>:<VALUE>. For example: @ci.provider.name:github. For advanced search, see Search Test Batches.

To filter SLOs by assigned tags, use the search bar or facet checkboxes. The search bar format is <KEY>:<VALUE>, for example: journey:add_item. To exclude SLOs with a specific tag from your search, use -, for example: -journey:add_item.

SLO tags are different and separate from metric or monitor tags used in the underlying metrics or monitors of an SLO.

When creating a metric-based SLO, use metric tags in the SLO’s success ratio metric queries (all metrics must use the same set of metric tags):

• from text box to limit the metric scope to only those tags.
• sum by text box to create a grouped metric-based SLO that display a status percentage and remaining error budget for both the overall SLO and for each tag value.

When creating a monitor-based SLO using a single grouped monitor, use the Calculate on selected groups toggle to select up to 20 tag values from the underlying monitor to display a status percentage and remaining error budget for both the overall SLO and for each tag value:

The CI Visibility Explorer displays your test runs run in a CI pipeline.

To filter test runs by tags, use the search bar or facet checkboxes. The search bar format is <KEY>:<VALUE>. For example: @test.status:failed. For advanced search, see Search and Manage CI Tests.

The CI Visibility Explorer displays your CI pipeline executions.

To filter pipeline executions by tags, use the search bar or facet checkboxes. The search bar format is <KEY>:<VALUE>. For example: @ci.provider.name:gitlab. For advanced search, see Search and Manage CI Pipelines.