merge master

Author: maycmlee

config/_default/menus/main.en.yaml

@@ -2765,13 +2765,13 @@ menu:
     - name: Cloud Resources Schema
       url: infrastructure/resource_catalog/schema/
       parent: infrastructure_resource_catalog
-      identifier: infrastructure_resource_catalog_schemat
-      weight: 20001
-    - name: Governance
-      url: infrastructure/resource_catalog/governance/
+      identifier: infrastructure_resource_catalog_schema
+      weight: 10001
+    - name: Policies
+      url: infrastructure/resource_catalog/policies/
       parent: infrastructure_resource_catalog
-      identifier: infrastructure_resource_catalog_governance
-      weight: 20002
+      identifier: infrastructure_resource_catalog_policies
+      weight: 10002
     - name: Universal Service Monitoring
       url: universal_service_monitoring/
       pre: usm

content/en/actions/datastore/_index.md

@@ -13,10 +13,6 @@ further_reading:
   text: "Build Workflows"
 ---
 
-{{< callout url="https://docs.google.com/forms/d/1NvW3I0Ep-lQo4FbiSwOEjccoFsS9Ue2wYiYDmCxKDYg/viewform?edit_requested=true" btn_hidden="false" header="Try the Preview!">}}
-Datastore is in Preview. Use this form to request access today.
-{{< /callout >}}
-
 ## Overview
 
 The Actions Datastore offers a scalable, structured data storage solution within Datadog's App Builder and Workflow Automation products. It supports CRUD (Create, Read, Update, and Delete) operations and integrates seamlessly with Datadog's ecosystem to optimize persistent data storage without the need for external databases.

content/en/agent/logs/log_transport.md

@@ -107,7 +107,9 @@ When logs are sent through HTTPS, use the same [set of proxy settings][3] as the
 [2]: /agent/basic_agent_usage/#agent-overhead
 [3]: /agent/configuration/proxy/
 {{% /tab %}}
+
 {{% tab "TCP" %}}
+{{< site-region region="us,eu,us3,us5,ap1" >}}
 
 To enforce TCP transport, update the Agent's [main configuration file][1] (`datadog.yaml`) with:
 
@@ -123,6 +125,13 @@ To send logs with environment variables, configure the following:
 
 By default, the Datadog Agent sends its logs to Datadog over TLS-encrypted TCP. This requires outbound communication (on port `10516` for Datadog US site and port `443`for Datadog EU site).
 
+{{< /site-region >}}
+
+{{< site-region region="gov" >}}
+The TCP endpoint is not supported for this site.
+
+{{< /site-region >}}
+
 [1]: /agent/configuration/agent-configuration-files/
 {{% /tab %}}
 {{< /tabs >}}

content/en/continuous_delivery/deployments/argocd.md

@@ -31,9 +31,11 @@ Datadog CD Visibility integrates with Argo CD by using [Argo CD Notifications][2
 
 The setup below uses the [Webhook notification service][5] of Argo CD to send notifications to Datadog.
 
-First, add your [Datadog API Key][11] in the `argocd-notifications-secret` secret with the `dd-api-key` key. See [the Argo CD guide][2] for information on modifying the `argocd-notifications-secret`.
+First, add your [Datadog API Key][11] in the `argocd-notifications-secret` secret with the `dd-api-key` key. See [the Argo CD guide][2] for information on modifying the `argocd-notifications-secret`. For sending notifications, the setup is different depending on whether you installed Argo CD using Helm or the regular setup (using `kubectl apply`).
 
-Then, modify the `argocd-notifications-cm` ConfigMap to create the notification service, template, and trigger to send notifications to Datadog:
+{{< tabs >}}
+{{% tab "Regular setup (with kubectl apply)" %}}
+Modify the `argocd-notifications-cm` ConfigMap to create the notification service, template, and trigger to send notifications to Datadog:
 
 ```yaml
 apiVersion: v1
@@ -68,6 +70,44 @@ data:
     - when: app.status.operationState.phase == 'Running' and app.status.health.status in ['Healthy', 'Degraded']
       send: [cd-visibility-template]
 ```
+{{% /tab %}}
+{{% tab "Helm" %}}
+If you used Helm to install Argo CD, add the following configuration to your `values.yaml`:
+
+```yaml
+notifications:
+  notifiers:
+    service.webhook.cd-visibility-webhook: |
+      url: https://webhook-intake.{{< region-param key="dd_site" code="true" >}}/api/v2/webhook
+      headers:
+        - name: "DD-CD-PROVIDER-ARGOCD"
+          value: "true"
+        - name: "Content-Type"
+          value: "application/json"
+        - name: "DD-API-KEY"
+          value: $dd-api-key
+  templates:
+    template.cd-visibility-template: |
+      webhook:
+        cd-visibility-webhook:
+          method: POST
+          body: |
+            {
+              "app": {{toJson .app}},
+              "context": {{toJson .context}},
+              "service_type": {{toJson .serviceType}},
+              "recipient": {{toJson .recipient}},
+              "commit_metadata": {{toJson (call .repo.GetCommitMetadata .app.status.operationState.syncResult.revision)}}
+            }
+  triggers:
+    trigger.cd-visibility-trigger: |
+      - when: app.status.operationState.phase in ['Succeeded', 'Failed', 'Error'] and app.status.health.status in ['Healthy', 'Degraded']
+        send: [cd-visibility-template]
+      - when: app.status.operationState.phase == 'Running' and app.status.health.status in ['Healthy', 'Degraded']
+        send: [cd-visibility-template]
+```
+{{% /tab %}}
+{{< /tabs >}}
 
 The following resources have been added:
 1. The `cd-visibility-webhook` service targets the Datadog intake and configures the correct headers for the request. The `DD-API-KEY` header references the `dd-api-key` entry added previously in the `argocd-notifications-secret`.

content/en/data_jobs/airflow.md

@@ -50,6 +50,7 @@ To get started, follow the instructions below.
    ```shell
    export OPENLINEAGE_URL=<DD_DATA_OBSERVABILITY_INTAKE>
    export OPENLINEAGE_API_KEY=<DD_API_KEY>
+   # AIRFLOW__OPENLINEAGE__NAMESPACE sets the 'env' tag value in Datadog. You can hardcode this to a different value
    export AIRFLOW__OPENLINEAGE__NAMESPACE=${AIRFLOW_ENV_NAME}
    ```
    * Replace `<DD_DATA_OBSERVABILITY_INTAKE>` with `https://data-obs-intake.`{{< region-param key="dd_site" code="true" >}}.
@@ -113,6 +114,7 @@ To get started, follow the instructions below.
    #!/bin/sh
    export OPENLINEAGE_URL=<DD_DATA_OBSERVABILITY_INTAKE>
    export OPENLINEAGE_API_KEY=<DD_API_KEY>
+   # AIRFLOW__OPENLINEAGE__NAMESPACE sets the 'env' tag value in Datadog. You can hardcode this to a different value
    export AIRFLOW__OPENLINEAGE__NAMESPACE=${AIRFLOW_ENV_NAME}
    ```
 
@@ -190,7 +192,7 @@ For Astronomer customers using Astro, <a href=https://www.astronomer.io/docs/lea
     * replace `<DD_API_KEY>` with your valid [Datadog API key][7].
 
     **Optional:**
-    * Set `AIRFLOW__OPENLINEAGE__NAMESPACE` with a unique name for your Airflow deployment. This allows Datadog to logically separate this deployment's jobs from those of other Airflow deployments.
+    * Set `AIRFLOW__OPENLINEAGE__NAMESPACE` with a unique name for the `env` tag on all DAGs in the Airflow deployment. This allows Datadog to logically separate this deployment's jobs from those of other Airflow deployments.
     * Set `OPENLINEAGE_CLIENT_LOGGING` to `DEBUG` for the OpenLineage client and its child modules to log at a `DEBUG` logging level. This can be useful for troubleshooting during the configuration of an OpenLineage provider.
 
     See the [Astronomer official guide][10] for managing environment variables for a deployment. See Apache Airflow's [OpenLineage Configuration Reference][6] for other supported configurations of the OpenLineage provider.

content/en/data_jobs/databricks.md

@@ -21,12 +21,11 @@ Follow these steps to enable Data Jobs Monitoring for Databricks.
 ### Configure the Datadog-Databricks integration
 
 1. In your Databricks workspace, click on your profile in the top right corner and go to **Settings**. Select **Developer** in the left side bar. Next to **Access tokens**, click **Manage**.
-1. Click **Generate new token**, enter "Datadog Integration" in the **Comment** field, remove the default value in **Lifetime (days)**, and click **Generate**. Take note of your token.
+1. Click **Generate new token**, enter "Datadog Integration" in the **Comment** field, set the **Lifetime (days)** value to the maximum allowed (730 days), and create a reminder to update the token before it expires. Then click **Generate**. Take note of your token.
 
    **Important:**
-   * For the [Datadog managed init script install (recommended)](?tab=datadogmanagedglobalinitscriptrecommended#install-the-datadog-agent), ensure the user or service principal linked to the token is a <strong>Workspace Admin</strong>.
-   * For manual init script installation, ensure the user or service principal linked to the token has [CAN VIEW access][9] for the Databricks jobs and clusters you want to monitor.
-   * Make sure you set the **Lifetime (days)** value to the maximum allowed (730 days) so that the token doesn't expire and the integration doesn't break.
+   * For the [Datadog managed init script install (recommended)](?tab=datadogmanagedglobalinitscriptrecommended#install-the-datadog-agent), ensure the token's Principal is a <strong>Workspace Admin</strong>.
+   * For manual init script installation, ensure the token's Principal has [CAN VIEW access][9] for the Databricks jobs and clusters you want to monitor.
 
    As an alternative, follow the [official Databricks documentation][10] to generate an access token for a [service principal][11]. The service principal must have the [<strong>Workspace access</strong> entitlement][17] enabled and the <strong>Workspace Admin</strong> or [CAN VIEW access][9] permissions as described above.
 1. In Datadog, open the Databricks integration tile.
@@ -221,13 +220,6 @@ In Datadog, view the [Data Jobs Monitoring][6] page to see a list of all your Da
 
 {{% djm-install-troubleshooting %}}
 
-If the Agent is not installed, view the installation logs located in `/tmp/datadog-djm-init.log`.
-
-If you need further assistance from Datadog support, add the following environment variable to the init script. This ensures that logs are sent to Datadog when a failure occurs.
-  ```shell
-  export DD_DJM_ADD_LOGS_TO_FAILURE_REPORT=true
-  ```
-
 ## Advanced Configuration
 
 ### Tag spans at runtime

content/en/data_streams/dotnet.md

@@ -38,6 +38,8 @@ Data Streams Monitoring uses message headers to propagate context through Kafka
 ### Monitoring SQS pipelines
 Data Streams Monitoring uses one [message attribute][2] to track a message's path through an SQS queue. As Amazon SQS has a maximum limit of 10 message attributes allowed per message, all messages streamed through the data pipelines must have 9 or fewer message attributes set, allowing the remaining attribute for Data Streams Monitoring.
 
+{{% data-streams-monitoring/monitoring-rabbitmq-pipelines %}}
+
 ### Monitoring SNS-to-SQS pipelines
 To monitor a data pipeline where Amazon SNS talks directly to Amazon SQS, you must enable [Amazon SNS raw message delivery][12].
 

content/en/data_streams/go.md

@@ -30,6 +30,8 @@ To start with Data Streams Monitoring, you need recent versions of the Datadog A
 ### Monitoring Kafka Pipelines
 Data Streams Monitoring uses message headers to propagate context through Kafka streams. If `log.message.format.version` is set in the Kafka broker configuration, it must be set to `0.11.0.0` or higher. Data Streams Monitoring is not supported for versions lower than this.
 
+{{% data-streams-monitoring/monitoring-rabbitmq-pipelines %}}
+
 #### Automatic Instrumentation
 
 Automatic instrumentation uses [Orchestrion][4] to install dd-trace-go and supports both the Sarama and Confluent Kafka libraries.

content/en/data_streams/java.md

@@ -73,6 +73,8 @@ Use Datadog's Java tracer, [`dd-trace-java`][6], to collect information from you
 ### Monitoring SQS pipelines
 Data Streams Monitoring uses one [message attribute][3] to track a message's path through an SQS queue. As Amazon SQS has a maximum limit of 10 message attributes allowed per message, all messages streamed through the data pipelines must have 9 or fewer message attributes set, allowing the remaining attribute for Data Streams Monitoring.
 
+{{% data-streams-monitoring/monitoring-rabbitmq-pipelines %}}
+
 ### Monitoring SNS-to-SQS pipelines
 To monitor a data pipeline where Amazon SNS talks directly to Amazon SQS, you must perform the following additional configuration steps:
 

content/en/data_streams/nodejs.md

@@ -42,6 +42,8 @@ Data Streams Monitoring uses message headers to propagate context through Kafka
 ### Monitoring SQS pipelines
 Data Streams Monitoring uses one [message attribute][4] to track a message's path through an SQS queue. As Amazon SQS has a maximum limit of 10 message attributes allowed per message, all messages streamed through the data pipelines must have 9 or fewer message attributes set, allowing the remaining attribute for Data Streams Monitoring.
 
+{{% data-streams-monitoring/monitoring-rabbitmq-pipelines %}}
+
 ### Monitoring SNS-to-SQS pipelines
 To monitor a data pipeline where Amazon SNS talks directly to Amazon SQS, you must enable [Amazon SNS raw message delivery][8].
 
@@ -67,4 +69,4 @@ Data Streams Monitoring propagates context through message headers. If you are u
 [5]: https://www.npmjs.com/package/amqplib
 [6]: https://www.npmjs.com/package/rhea
 [7]: /data_streams/manual_instrumentation/?tab=nodejs
-[8]: https://docs.aws.amazon.com/sns/latest/dg/sns-large-payload-raw-message-delivery.html
+[8]: https://docs.aws.amazon.com/sns/latest/dg/sns-large-payload-raw-message-delivery.html

content/en/data_streams/python.md

@@ -42,6 +42,8 @@ Data Streams Monitoring uses message headers to propagate context through Kafka
 ### Monitoring SQS Pipelines
 Data Streams Monitoring uses one [message attribute][4] to track a message's path through an SQS queue. As Amazon SQS has a maximum limit of 10 message attributes allowed per message, all messages streamed through the data pipelines must have 9 or fewer message attributes set, allowing the remaining attribute for Data Streams Monitoring.
 
+{{% data-streams-monitoring/monitoring-rabbitmq-pipelines %}}
+
 ### Monitoring Kinesis pipelines
 There are no message attributes in Kinesis to propagate context and track a message's full path through a Kinesis stream. As a result, Data Streams Monitoring's end-to-end latency metrics are approximated based on summing latency on segments of a message's path, from the producing service through a Kinesis Stream, to a consumer service. Throughput metrics are based on segments from the producing service through a Kinesis Stream, to the consumer service. The full topology of data streams can still be visualized through instrumenting services.
 
@@ -66,4 +68,4 @@ Data Streams Monitoring propagates context through message headers. If you are u
 [4]: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-message-metadata.html
 [5]: https://pypi.org/project/kombu/
 [6]: /data_streams/manual_instrumentation/?tab=python
-[7]: https://docs.aws.amazon.com/sns/latest/dg/sns-large-payload-raw-message-delivery.html
+[7]: https://docs.aws.amazon.com/sns/latest/dg/sns-large-payload-raw-message-delivery.html

content/en/developers/integrations/check_references.md

@@ -127,7 +127,7 @@ You can find the complete list of mandatory and optional attributes for the `met
 | `integration`   | Mandatory          | The name of the integration that emits the metric. Must be the normalized version of the `tile.title` from the `manifest.json` file. Any character besides letters, underscores, dashes, and numbers are converted to underscores. For example: `Openstack Controller` -> `openstack_controller`, `ASP.NET` -> `asp_net`, and `CRI-o` -> `cri-o`. |
 | `short_name`    | Mandatory          | A human-readable, abbreviated version of the metric name. Do not repeat the integration name. For example, `postgresql.index_blocks_hit` should be shortened to `idx blks hit`.                                                                                                                                                                                                                                                                                                     |
 | `curated_metric`| Optional           | Marks which metrics for an integration are noteworthy for a given type (`cpu` and `memory` are both accepted). These are displayed in the UI above the other integration metrics. |
-| `sample_tags` | Optional           | List of example tags associated with the metric. |
+| `sample_tags` | Optional           | List of example tags associated with the metric, separated by commas without spaces. For example, `host,region,deployment`. |
 
 ## Further Reading
 

content/en/dora_metrics/setup/deployments.md

@@ -161,7 +161,7 @@ For deployments identified through APM Deployment Tracking, the change lead time
 
 For service deployments tracked by APM to contribute to change lead time, ensure the following:
 
-### Requirements for calculating change lead time 
+### Requirements for calculating change lead time
 - Your application telemetry is tagged with Git information. You can enable this [in APM][101] or see the [Source Code Integration documentation][102].
 - Your repository metadata is synchronized to Datadog through the [GitHub integration][103] or by the `datadog-ci git-metadata upload` command.
 
@@ -297,6 +297,7 @@ If the two metadata entries are defined for a service, only `extensions[datadogh
 
 - Change lead time stage breakdown metrics are only available for GitHub and GitLab.
 - Change lead time is not available for the first deployment of a service that includes Git information.
+- Change lead time is not available if the most recent deployment of a service was more than 60 days ago.
 - The Change Lead Time calculation includes a maximum of 5000 commits per deployment.
 - For rebased branches, *change lead time* calculations consider the new commits created during the rebase, not the original commits.
 - When using "Squash" to merge pull requests:

content/en/dynamic_instrumentation/enabling/nodejs.md

@@ -22,7 +22,7 @@ Dynamic Instrumentation is a feature of supporting Datadog tracing libraries. If
 
 1. Install or upgrade your Agent to version [7.45.0][6] or higher.
 2. If you don't already have APM enabled, in your Agent configuration, set the `DD_APM_ENABLED` environment variable to `true` and listening to the port `8126/TCP`.
-3. Install or upgrade the Node.js tracing library to version 5.39.0 or higher, by following the [relevant instructions][2].
+3. Install or upgrade the Node.js tracing library to version 5.48.0 or higher, by following the [relevant instructions][2].
 4. If your source code is transpiled during deployment (for example, if using TypeScript), ensure that source maps are published along with the deployed Node.js application.
 5. Run your service with Dynamic Instrumentation enabled by setting the `DD_DYNAMIC_INSTRUMENTATION_ENABLED` environment variable to `true`. Specify `DD_SERVICE`, `DD_ENV`, and `DD_VERSION` Unified Service Tags so you can filter and group your instrumentations and target active clients across these dimensions.
 6. After starting your service with Dynamic Instrumentation enabled, you can start using Dynamic Instrumentation on the [APM > Dynamic Instrumentation page][3].