Merge pull request DataDog#7516 from DataDog/sarina/containerized-tagging

Refactor of Tagging Section

Author: sarina-dd

config/_default/menus/menus.en.yaml

@@ -39,48 +39,55 @@ main:
  url: getting_started/tracing/
  parent: getting_started
  weight: 5
+ - name: Tags
+ identifier: tagging_
+ url: getting_started/tagging/
+ parent: getting_started
+ weight: 6
+ - name: Assigning Tags
+ identifier: assigning_tags
+ url: getting_started/tagging/assigning_tags
+ parent: tagging_
+ weight: 601
+ - name: Unified Service Tagging
+ identifier: unified_service_tagging
+ url: getting_started/tagging/unified_service_tagging
+ parent: tagging_
+ weight: 602
+ - name: Using Tags
+ identifier: using_tags
+ url: getting_started/tagging/using_tags
+ parent: tagging_
+ weight: 603
  - name: API
  identifier: getting_started_api
  url: getting_started/api/
  parent: getting_started
- weight: 6
+ weight: 7
  - name: Synthetics
  identifier: getting_started_synthetics
  url: getting_started/synthetics/
  parent: getting_started
- weight: 7opl
+ weight: 8
  - name: Private Location
  identifier: getting_started_private_location
  url: getting_started/synthetics/private_location
  parent: getting_started_synthetics
- weight: 701
+ weight: 801
  - name: Browser Test
  identifier: getting_started_browser_test
  url: getting_started/synthetics/browser_test
  parent: getting_started_synthetics
- weight: 702
+ weight: 802
  - name: API Test
  identifier: getting_started_api_test
  url: getting_started/synthetics/api_test
  parent: getting_started_synthetics
- weight: 703
+ weight: 803
  - name: Learning Center
  url: getting_started/learning_center/
  parent: getting_started
- weight: 8
- - name: Tagging
- url: tagging/
- pre: nav_tagging
- identifier: tagging_
- weight: 20000
- - name: Assigning tags
- url: tagging/assigning_tags/
- parent: tagging_
- weight: 1
- - name: Using tags
- url: tagging/using_tags/
- parent: tagging_
- weight: 2
+ weight: 9
  - name: Agent
  url: agent/
  pre: nav_agent

content/en/account_management/billing/alibaba.md

@@ -26,7 +26,7 @@ For technical questions, contact [Datadog support][4].
 For billing questions, contact your [Customer Success][5] Manager.
 
 [1]: https://app.datadoghq.com/account/settings#integrations/alibaba-cloud
-[2]: /tagging/using_tags/#integrations
+[2]: /getting_started/tagging/using_tags/#integrations
 [3]: /infrastructure/
 [4]: /help/
 [5]: mailto:success@datadoghq.com

content/en/account_management/billing/aws.md

@@ -30,7 +30,7 @@ For technical questions, contact [Datadog support][4].
 For billing questions, contact your [Customer Success][5] Manager.
 
 [1]: https://app.datadoghq.com/account/settings#integrations/amazon_web_services
-[2]: /tagging/using_tags/#integrations
+[2]: /getting_started/tagging/using_tags/#integrations
 [3]: /infrastructure/
 [4]: /help/
 [5]: mailto:success@datadoghq.com

content/en/account_management/billing/azure.md

@@ -7,7 +7,7 @@ kind: documentation
 
 Datadog bills for all [Azure Virtual Machines being monitored in Datadog][1]. These machines are billable regardless of whether the Datadog Agent is installed. You are not billed twice if you are running the Agent on an Azure VM picked up by the Azure integration.
 
-Additionally, Datadog also counts the nodes inside of Azure App Service Plans as billable hosts. Note that any Shared, Dynamic, or Free tier App Service Plans do not have any associated node counts and will not impact your Datadog bill. 
+Additionally, Datadog also counts the nodes inside of Azure App Service Plans as billable hosts. Note that any Shared, Dynamic, or Free tier App Service Plans do not have any associated node counts and will not impact your Datadog bill.
 The Azure integration will collect metrics for all other Azure resources (Azure SQL DB, Azure Redis Cache, Azure Load Balancer, etc.) without any impact on monthly billing.
 
 ## Azure VM exclusion
@@ -31,5 +31,5 @@ For technical questions, contact [Datadog support][2].
 For billing questions, contact your [Customer Success][3] Manager.
 
 [1]: https://app.datadoghq.com/account/settings#integrations/azure
-[2]: /tagging/using_tags/#integrations
+[2]: /getting_started/tagging/using_tags/#integrations
 [3]: /infrastructure/

content/en/account_management/billing/google_cloud.md

@@ -26,7 +26,7 @@ For technical questions, contact [Datadog support][4].
 For billing questions, contact your [Customer Success][5] Manager.
 
 [1]: https://app.datadoghq.com/account/settings#integrations/google_cloud_platform
-[2]: /tagging/using_tags/#integrations
+[2]: /getting_started/tagging/using_tags/#integrations
 [3]: /infrastructure/
 [4]: /help/
 [5]: mailto:success@datadoghq.com

content/en/account_management/billing/usage_attribution.md

@@ -83,4 +83,4 @@ The table below shows a sample daily report for Custom Metrics usage two tags: `
 When using multiple tags, both the Daily and Monthly Usage Attribution reports contain data for all possible combinations of those tags, and are suitable to use as base datasets for further data analysis tasks. For instance, you can use grouping or pivoting to produce views focused on a subset of the tags, or to perform aggregations across custom date ranges.
 
 [1]: https://docs.datadoghq.com/api/#get-daily-usage-attribution-available-files
-[2]: https://docs.datadoghq.com/tagging/#defining-tags
+[2]: https://docs.datadoghq.com/getting_started/tagging/#defining-tags

content/en/agent/cluster_agent/clusterchecks.md

@@ -131,9 +131,20 @@ ad.datadoghq.com/service.instances: '[<INSTANCE_CONFIG>]'
 
 The `%%host%%` [template variable][7] is supported and is replaced by the service's IP. The `kube_namespace` and `kube_service` tags are automatically added to the instance.
 
+### Template Source: Standard Labels
+
+```yaml
+tags.datadoghq.com/env: "<ENV>"
+tags.datadoghq.com/service: "<SERVICE>"
+tags.datadoghq.com/version: "<VERSION>"
+```
+
+The `tags.datadoghq.com` labels set the `env`, `service`, and even `version` as tags on data generated by the check.
+These standard labels are part of [Unified Service Tagging][8].
+
 #### Example: HTTP check on an NGINX-backed service
 
-The following Service definition exposes the Pods from the `my-nginx` deployment and runs an [HTTP check][8] to measure the latency of the load balanced service:
+The following Service definition exposes the Pods from the `my-nginx` deployment and runs an [HTTP check][9] to measure the latency of the load balanced service:
 
 ```yaml
 apiVersion: v1
@@ -142,6 +153,9 @@ metadata:
  name: my-nginx
  labels:
  run: my-nginx
+ tags.datadoghq.com/env: "prod"
+ tags.datadoghq.com/service: "my-nginx"
+ tags.datadoghq.com/version: "1.19.0"
  annotations:
  ad.datadoghq.com/service.check_names: '["http_check"]'
  ad.datadoghq.com/service.init_configs: '[{}]'
@@ -161,7 +175,7 @@ spec:
  run: my-nginx
 ```
 
-In addition, each pod should be monitored with the [NGINX check][9], as it enables the monitoring of each worker as well as the aggregated service.
+In addition, each pod should be monitored with the [NGINX check][10], as it enables the monitoring of each worker as well as the aggregated service.
 
 ## Troubleshooting
 
@@ -300,5 +314,6 @@ The Agent `status` command should show the check instance running and reporting
 [5]: /developers/write_agent_check/
 [6]: /integrations/mysql/
 [7]: /agent/faq/template_variables/
-[8]: /integrations/http_check/
-[9]: /integrations/nginx/
+[8]: /getting_started/tagging/unified_service_tagging
+[9]: /integrations/http_check/
+[10]: /integrations/nginx/

content/en/agent/cluster_agent/commands.md

@@ -37,6 +37,8 @@ The following environment variables are supported:
 |-----------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
 | `DD_API_KEY` | Your [Datadog API key][1]. |
 | `DD_HOSTNAME` | Hostname to use for the Datadog Cluster Agent. |
+| `DD_ENV` | Sets the `env` tag for data emitted by the Cluster Agent. Recommended only if the Cluster Agent monitors services within a single environment.
+ |
 | `DD_CLUSTER_AGENT_CMD_PORT` | Port for the Datadog Cluster Agent to serve. Defaults to `5005`. |
 | `DD_USE_METADATA_MAPPER` | Enables cluster level metadata mapping. Defaults to `true`. |
 | `DD_COLLECT_KUBERNETES_EVENTS` | Configures the Agent to collect Kubernetes events. Defaults to `false`. See the [Event collection documentation][2] for more details. |

content/en/agent/cluster_agent/endpointschecks.md

@@ -132,9 +132,20 @@ ad.datadoghq.com/endpoints.logs: '[<LOGS_CONFIG>]'
 
 The `%%host%%` [template variable][7] is supported and is replaced by the endpoints' IPs. The `kube_namespace`, `kube_service`, and `kube_endpoint_ip` tags are automatically added to the instances.
 
+### Template Source: Standard Labels
+
+```yaml
+tags.datadoghq.com/env: "<ENV>"
+tags.datadoghq.com/service: "<SERVICE>"
+tags.datadoghq.com/version: "<VERSION>"
+```
+
+The `tags.datadoghq.com` labels set the `env`, `service`, and even `version` as tags on data generated by the check.
+These standard labels are part of [Unified Service Tagging][8].
+
 #### Example: HTTP check on an NGINX-backed service with NGINX check on the service's endpoints
 
-The following service definition exposes the pods from the `my-nginx` deployment. It then runs an [HTTP check][8] to measure the latency of the load-balanced service and an [NGINX check][9] on the pod(s) that back the endpoint(s) of the service to collect `NGINX` metrics and service checks on the pod level:
+The following service definition exposes the pods from the `my-nginx` deployment. It then runs an [HTTP check][9] to measure the latency of the load-balanced service and an [NGINX check][10] on the pod(s) that back the endpoint(s) of the service to collect `NGINX` metrics and service checks on the pod level:
 
 ```yaml
 apiVersion: v1
@@ -143,6 +154,9 @@ metadata:
  name: my-nginx
  labels:
  run: my-nginx
+ tags.datadoghq.com/env: "prod"
+ tags.datadoghq.com/service: "my-nginx"
+ tags.datadoghq.com/version: "1.19.0"
  annotations:
  ad.datadoghq.com/service.check_names: '["http_check"]'
  ad.datadoghq.com/service.init_configs: '[{}]'
@@ -174,7 +188,7 @@ spec:
 
 ## Troubleshooting
 
-Troubleshooting endpoints checks is similar to [troubleshooting cluster checks][10]—the only difference is on the node-based Agents, where scheduled endpoints checks appear alongside the cluster check.
+Troubleshooting endpoints checks is similar to [troubleshooting cluster checks][11]—the only difference is on the node-based Agents, where scheduled endpoints checks appear alongside the cluster check.
 
 **Note**: Endpoints checks are scheduled by Agents that run on the same node as the pod(s) that back the endpoint(s) of the service. If an endpoint is not backed by a pod, the Cluster Agent converts the check into a cluster check. This cluster check can be run by any node Agent.
 
@@ -268,6 +282,7 @@ State: dispatched to gke-cluster-default-pool-4658d5d4-qfnt
 [5]: /agent/guide/agent-commands/
 [6]: /agent/kubernetes/integrations/?tab=kubernetes#template-source-kubernetes-pod-annotations
 [7]: /agent/kubernetes/integrations/?tab=kubernetes#supported-template-variables
-[8]: /integrations/http_check/
-[9]: /integrations/nginx/
-[10]: /agent/cluster_agent/troubleshooting/
+[8]: /getting_started/tagging/unified_service_tagging
+[9]: /integrations/http_check/
+[10]: /integrations/nginx/
+[11]: /agent/cluster_agent/troubleshooting/

content/en/agent/cluster_agent/setup.md

@@ -174,7 +174,9 @@ After having set up the Datadog Cluster Agent, configure your Datadog Agent to c
 
 5. In the `agent.yaml` manifest, add the environment variable `DD_CLUSTER_AGENT_ENABLED` and set it to `true`.
 
-6. Create the DaemonSet with this command: `kubectl apply -f agent.yaml`
+6. (Optional) If your cluster encompasses a single environment, you can also set `<DD_ENV>` in the `agent.yaml`.
+
+7. Create the DaemonSet with this command: `kubectl apply -f agent.yaml`
 
 ### Verification