Tagging is used throughout the Datadog product to make it easier to subset and query the machines and metrics that you have to monitor. Without the ability to assign and filter based on tags, finding the problems that exist in your environment and narrowing them down enough to discover the true causes would be extremely difficult. Discover our tagging best practices before going further.
There are four primary ways to assign tags: inherited from the integration, in the configuration, in the UI, and using the API, though the UI and API only allow you to assign tags at the host level. The recommended method is to rely on the integrations or via the configuration files.
The easiest method for assigning tags is to rely on the integration. Tags assigned to your Amazon Web Services instances, Chef recipes, and more are all automatically assigned to the hosts and metrics when they are brought in to Datadog.
The following integrations sources create tags automatically in Datadog:
|Amazon EC2||AMI, Customer Gateway, DHCP Option, EBS Volume, Instance, Internet Gateway, Network ACL, Network Interface, Reserved Instance, Reserved Instance Listing, Route Table , Security Group - EC2 Classic, Security Group - VPC, Snapshot, Spot Batch, Spot Instance Request, Spot Instances, Subnet, Virtual Private Gateway, VPC, VPN Connection|
|Amazon Elastic File System||Filesystem|
|Amazon Kinesis||Stream State|
|Amazon Machine Learning||BatchPrediction, DataSource, Evaluation , MLModel|
|Amazon Route 53||Domains, Healthchecks , HostedZone|
|AWS Elastic Load Balancing||Loadbalancer, TargetGroups|
|AWS Identity and Access Management||Profile Name|
|AWS SQS||Queue Name|
|Apache||Apache Host and Port|
|Azure||Tenant Name, Status, Tags, Subscription ID and Name, Availability Zone in common with AWS tag after contacting Datadog support|
|BTRFS||Usage & Replication Type|
|Consul||Previous and Current Consul Leaders and Followers, Consul Datacenter, Service Name, Service ID|
|CouchDB||Database Name, Instance Name|
|CouchBase||CouchBase Tags, Instance Name|
|Docker||Docker, Kubernetes, ECS, Swarm, Mesos, Nomad and Rancher, collect more tag with the Docker Agent tags collection options|
|Dyn||Zone, Record Type|
|Elasticsearch||Cluster Name, Host Name, Port Number|
|Etcd||State Leader or Follower|
|Fluentd||Host Name, Port Number|
|Google App Engine||Project Name, Version ID, Task Queue|
|Google Cloud Platform||Zone, Instance Type and ID, Automatic Restart, Project Name and ID, Name, Availability Zone in common with AWS tag after contacting Datadog support|
|Go Expvar||Expvar Path|
|Gunicorn||State Idle or Working, App Name|
|HAProxy||Service Name, Availability, Backend Host, Status, Type|
|HTTP Check||URL, Instance|
|Jenkins||Job Name, Build Number, Branch, and Results|
|Kubernetes||Minion Name, Namespace, Replication Controller, Labels, Container Alias|
|Memcached||Host, Port, Request, Cache Hit or Miss|
|Mesos||Role, URL, PID, Slave or Master Role, Node, Cluster,|
|OpenStack||Network ID, Network Name, Hypervisor Name, ID, and Type, Tenant ID, Availability Zone|
|PHP FPM||Pool Name|
|Pivotal||Current State, Owner, Labels, Requester, Story Type|
|RabbitMQ||Node, Queue Name, Vhost, Policy, Host|
|Redis||Host, Port, Slave or Master|
|SNMP||Device IP Address|
|Supervisord||Server Name, Process Name|
|TeamCity||Tags, Code Deployments, Build Number|
|TokuMX||Role Primary or Secondary, Replset, Replstate, Db, Coll, Shard|
|VSphere||Host, Datacenter, Server, Instance|
|Win32 Events||Event ID|
|Windows Services||Service Name|
The Datadog integrations are all configured via the yaml configuration files located in the conf.d directory in your Agent install. For more about where to look for your configuration files, refer to this article.
Define tags in the configuration file for the overall Agent as well as for each integration. In YAML files, there is a tag dictionary with a list of tags you want assigned at that level. Any tag you assign to the Agent is applied to every integration on that Agent’s host.
Dictionaries with lists of values have two different yet functionally equivalent forms:
tags: key_first_tag:value_1, key_second_tag:value_2, key_third_tag:value_3
tags: - key_first_tag:value_1 - key_second_tag:value_2 - key_third_tag:value_3
You see both forms in the yaml configuration files, but for the
datadog.yaml init file only the first form is valid.
Each tag can be anything you like but you have the best success with tagging if your tags are
key:value pairs. Keys could represent the role, or function, or region, or application and the value is the instance of that role, function, region, or application. Here are some examples of good tags:
region:east region:nw application:database database:primary role:sobotka
The reason why you should use key value pairs instead of values becomes apparent when you start using the tags to filter and group metrics and machines. That said, you are not required to use key value pairs and simple values are valid.
You can also assign tags to hosts, but not to integration in the UI. To assign tags in the UI, start by going to the Infrastructure List page. Click on any host and then click the Update Host Tags button. In the host overlay that appears, click Edit Tags and make the changes you wish.
You can also assign tags to hosts, but not to integration using the API. The endpoints you want to work with are /tags/hosts and depending on whether you PUT, POST, or DELETE you update, add, or delete tags for the chosen host. For more details on using the Tags endpoints in the API, review this document