Merge pull request DataDog#7582 from DataDog/sarina/reorg-links

Updated links for Tagging reorg

Author: sarina-dd

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

@@ -140,11 +140,11 @@ 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][10].
+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
@@ -175,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
 
@@ -314,6 +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/
-[10]: /tagging/unified_service_tagging
+[8]: /getting_started/tagging/unified_service_tagging
+[9]: /integrations/http_check/
+[10]: /integrations/nginx/

content/en/agent/cluster_agent/endpointschecks.md

@@ -141,11 +141,11 @@ 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][11].
+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
@@ -188,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.
 
@@ -282,7 +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/
-[11]: /tagging/unified_service_tagging
+[8]: /getting_started/tagging/unified_service_tagging
+[9]: /integrations/http_check/
+[10]: /integrations/nginx/
+[11]: /agent/cluster_agent/troubleshooting/

content/en/agent/docker/log.md

@@ -240,7 +240,7 @@ For Kubernetes environements, refer to the [Kubernetes short lived container doc
 {{< partial name="whats-next/whats-next.html" >}}
 
 [1]: /integrations/journald/
-[2]: /tagging/unified_service_tagging
+[2]: /getting_started/tagging/unified_service_tagging
 [3]: /agent/docker/integrations/
 [4]: /agent/kubernetes/integrations/?tab=kubernetespodannotations#configuration
 [5]: /agent/logs/#custom-log-collection

content/en/agent/docker/tag.md

@@ -2,10 +2,10 @@
 title: Docker Tag Extraction
 kind: documentation
 further_reading:
-- link: "/tagging/"
+- link: "/getting_started/tagging/"
  tag: "Documentation"
  text: "Getting started with tags"
-- link: "/tagging/using_tags/"
+- link: "/getting_started/tagging/using_tags/"
  tag: "Documentation"
  text: "Using tags with Datadog"
 - link: "/agent/guide/autodiscovery-management/"
@@ -108,4 +108,4 @@ docker_env_as_tags:
 ## Further Reading
 
 {{< partial name="whats-next/whats-next.html" >}}
-[1]: /tagging/unified_service_tagging
+[1]: /getting_started/tagging/unified_service_tagging

content/en/agent/guide/ad_identifiers.md

@@ -91,4 +91,4 @@ com.datadoghq.ad.check.id: <INTEGRATION_AUTODISCOVERY_IDENTIFIER>
 
 {{< partial name="whats-next/whats-next.html" >}}
 
-[1]: /tagging/unified_service_tagging
+[1]: /getting_started/tagging/unified_service_tagging