El envío doble puede afectar la facturación si está enviando datos a múltiples organizaciones de Datadog. Para obtener más información sobre el impacto de esta configuración, comuníquese con Soporte de Datadog.
Descripción general
Esta guía proporciona ejemplos de configuraciones del Agent para el envío doble de diferentes tipos de datos (por ejemplo, APM, registros, métricas del Clúster Agent) a múltiples organizaciones y sitios de Datadog. Para obtener más información sobre los sitios de Datadog, consulte Introducción a los sitios de Datadog.
Nota: Utilice Observability Pipelines si desea realizar un envío doble de registros o dividir el tráfico de registros entre diferentes proveedores de registro, almacenamientos en la nube o proveedores de SIEM.
Para obtener una lista completa de los destinos del tráfico de red, consulte Tráfico de red.
Métricas y comprobaciones de servicio
Puede agregar la configuración YAML a su datadog.yaml o iniciar el Agent con las variables de entorno adecuadas.
Configuración YAML
Requiere la versión del Agent >= 6.17 o 7.17.
En datadog.yaml:
additional_endpoints:"https://app.":- apikey2- apikey3"https://app.<DD_SITE>": # Replace <DD_SITE> with your Datadog site parameter (for example, datadoghq.eu).- apikey4
Configuración de variables de entorno
Requiere la versión del Agent >= 6.18 o 7.18.
DD_ADDITIONAL_ENDPOINTS='{\"https://app.\": [\"apikey2\", \"apikey3\"], \"https://app.<DD_SITE>\": [\"apikey4\"]}'# Replace <DD_SITE> with your Datadog site parameter (for example, datadoghq.eu).
APM
Configuración YAML
Requiere la versión del Agent >= 6.7.0.
En datadog.yaml:
apm_config:[...]additional_endpoints:"https://trace.agent.":- apikey2- apikey3"https://trace.agent.<DD_SITE>": # Replace <DD_SITE> with your Datadog site parameter (for example, datadoghq.eu).- apikey4
Configuración de variables de entorno
Requiere la versión del Agent >= 6.19 o 7.19.
DD_APM_ADDITIONAL_ENDPOINTS='{\"https://trace.agent.\": [\"apikey2\", \"apikey3\"], \"https://trace.agent.<DD_SITE>\": [\"apikey4\"]}'# Replace <DD_SITE> with your Datadog site parameter (for example, datadoghq.eu).
Continuous Profiler
Configuración YAML
Requiere la versión del Agent >= 6.7.0.
En datadog.yaml:
apm_config:[...]profiling_additional_endpoints:"https://intake.profile./api/v2/profile":- apikey2- apikey3"https://intake.profile.<DD_SITE>/api/v2/profile": # Replace "<DD_SITE>" with your Datadog site parameter (for example, datadoghq.eu).- apikey4
Configuración de variables de entorno
Requiere la versión del Agent >= 6.19 o 7.19.
DD_APM_PROFILING_ADDITIONAL_ENDPOINTS='{\"https://intake.profile./api/v2/profile\": [\"apikey2\", \"apikey3\"], \"https://intake.profile.<DD_SITE>/api/v2/profile\": [\"apikey4\"]}'# Replace <DD_SITE> with your Datadog site parameter (for example, datadoghq.eu).
Nota: Las cargas a puntos de conexión adicionales para el producto Continuous Profiler se realizan mediante entrega de mejor esfuerzo.
El punto de conexión principal tiene la prioridad más alta. Las cargas a puntos de conexión adicionales solo se gestionan después de que las cargas al punto de conexión principal se hayan completado correctamente.
Las respuestas de los puntos de conexión adicionales no se reenvían al profiler. Cualquier error durante la entrega a puntos de conexión adicionales se registra en los registros de errores del Agente.
Live Processes
Configuración YAML
Requiere la versión del Agent >= 6.4.0.
En datadog.yaml:
process_config:[...]additional_endpoints:"https://process.":- apikey2- apikey3"https://process.<DD_SITE>": # Replace <DD_SITE> with your Datadog site parameter (for example, datadoghq.eu).- apikey4
Configuración de variables de entorno
Requiere la versión del Agente >= 6.20 o 7.20.
DD_PROCESS_ADDITIONAL_ENDPOINTS='{\"https://process.\": [\"apikey2\", \"apikey3\"], \"https://process.<DD_SITE>\": [\"apikey4\"]}'# Replace <DD_SITE> with your Datadog site parameter (for example, datadoghq.eu).
Métricas del Cluster Agent
Configure el Agent para enviar métricas del Cluster Agent, como Kubernetes State Metrics Core, a puntos de conexión adicionales.
Para garantizar que el escalado automático sea resistente a fallos, configure el Cluster Agent para ejecutar sus consultas de métricas para el HPA en sus múltiples regiones de Datadog con datos enviados por duplicado. Configure el manifiesto del Datadog Cluster Agent con varios puntos de conexión:
agents:customAgentConfig:process_config:additional_endpoints:"https://process.":- apikey2orchestrator_explorer:orchestrator_additional_endpoints:"https://orchestrator.":- apikey3clusterAgent:...datadog_cluster_yaml:orchestrator_explorer:orchestrator_additional_endpoints:"https://orchestrator.<DD_SITE>": # Replace <DD_SITE> with your Datadog site parameter (for example, ddog-gov.com).- apikey4
Configuración de variables de entorno
DD_ORCHESTRATOR_EXPLORER_ORCHESTRATOR_ADDITIONAL_ENDPOINTS='{\"https://orchestrator.\": [\"apikey2\", \"apikey3\"], \"https://orchestrator.<DD_SITE>\": [\"apikey4\"]}'# Replace <DD_SITE> with your Datadog site parameter (for example, ddog-gov.com).
CI Visibility
Configuración YAML
Requiere el Agent >= 6.38 o 7.38.
En datadog.yaml:
evp_proxy_config:[...]additional_endpoints:"https://<VERSION>-app.agent.":- apikey2- apikey3"https://<VERSION>-app.agent.<DD_SITE>": # Replace <VERSION> and <DD_SITE> with your Agent version and Datadog site parameter (for example, 7-38-0 and datadoghq.eu).- apikey4
Configuración de variables de entorno
DD_EVP_PROXY_CONFIG_ADDITIONAL_ENDPOINTS='{\"https://<VERSION>-app.agent.\": [\"apikey2\", \"apikey3\"], \"https://<VERSION>-app.agent.<DD_SITE>\": [\"apikey4\"]}'# Replace <VERSION> and <DD_SITE> with your Agent version and Datadog site parameter (for example, 7-38-0 and datadoghq.eu).
Logs
Utilice el Agent si desea enviar registros mediante envío doble a varias organizaciones de Datadog. Utilice Observability Pipelines si desea enviar registros a Datadog y a destinos externos.
TCP requiere la versión del Agent >= 6.6. HTTPS requiere la versión del Agent >= 6.13.
When setting up additional endpoints, you must explicitly set use_http to tell the Agent which transport to use. The same transport configuration is shared among all additional endpoints.
The is_reliable setting (First available in Agent 7.34.0) tells the Agent to treat this endpoint with the same priority as the primary endpoint. The primary endpoint is always reliable. This ensures that data is not missed if a destination becomes unavailable.
For example, if you’re sending data to the main endpoint and an additional endpoint with is_reliable: true, and one endpoint becomes unavailable, data continues to flow to the other endpoint. If both endpoints become unavailable, the Agent stops reading and sending data until at least one endpoint recovers. This ensures all data makes it to at least one reliable endpoint.
The is_reliable setting defaults to true in Agent 7.37.0+. Unreliable endpoints only send data if at least one reliable endpoint is available. You may define multiple additional endpoints with a mixed usage of is_reliable values. Datadog recommends that you use the default is_reliable setting.
You can add the YAML configuration to your datadog.yaml or launch the Agent with the appropriate environment variables.
When setting up additional endpoints, you must explicitly set use_http to tell the Agent which transport to use. The same transport configuration is shared among all additional endpoints.
The is_reliable setting (First available in Agent 7.34.0) tells the Agent to treat this endpoint with the same priority as the primary endpoint. The primary endpoint is always reliable. This ensures that data is not missed if a destination becomes unavailable.
For example, if you’re sending data to the main endpoint and an additional endpoint with is_reliable: true, and one endpoint becomes unavailable, data continues to flow to the other endpoint. If both endpoints become unavailable, the Agent stops reading and sending data until at least one endpoint recovers. This ensures all data makes it to at least one reliable endpoint.
The is_reliable setting defaults to true in Agent 7.37.0+. Unreliable endpoints only send data if at least one reliable endpoint is available. You may define multiple additional endpoints with a mixed usage of is_reliable values. Datadog recommends that you use the default is_reliable setting.
You can add the YAML configuration to your datadog.yaml or launch the Agent with the appropriate environment variables.
When setting up additional endpoints, you must explicitly set use_http to tell the Agent which transport to use. The same transport configuration is shared among all additional endpoints.
The is_reliable setting (First available in Agent 7.34.0) tells the Agent to treat this endpoint with the same priority as the primary endpoint. The primary endpoint is always reliable. This ensures that data is not missed if a destination becomes unavailable.
For example, if you’re sending data to the main endpoint and an additional endpoint with is_reliable: true, and one endpoint becomes unavailable, data continues to flow to the other endpoint. If both endpoints become unavailable, the Agent stops reading and sending data until at least one endpoint recovers. This ensures all data makes it to at least one reliable endpoint.
The is_reliable setting defaults to true in Agent 7.37.0+. Unreliable endpoints only send data if at least one reliable endpoint is available. You may define multiple additional endpoints with a mixed usage of is_reliable values. Datadog recommends that you use the default is_reliable setting.
You can add the YAML configuration to your datadog.yaml or launch the Agent with the appropriate environment variables.
When setting up additional endpoints, you must explicitly set use_http to tell the Agent which transport to use. The same transport configuration is shared among all additional endpoints.
The is_reliable setting (First available in Agent 7.34.0) tells the Agent to treat this endpoint with the same priority as the primary endpoint. The primary endpoint is always reliable. This ensures that data is not missed if a destination becomes unavailable.
For example, if you’re sending data to the main endpoint and an additional endpoint with is_reliable: true, and one endpoint becomes unavailable, data continues to flow to the other endpoint. If both endpoints become unavailable, the Agent stops reading and sending data until at least one endpoint recovers. This ensures all data makes it to at least one reliable endpoint.
The is_reliable setting defaults to true in Agent 7.37.0+. Unreliable endpoints only send data if at least one reliable endpoint is available. You may define multiple additional endpoints with a mixed usage of is_reliable values. Datadog recommends that you use the default is_reliable setting.
You can add the YAML configuration to your datadog.yaml or launch the Agent with the appropriate environment variables.
When setting up additional endpoints, you must explicitly set use_http to tell the Agent which transport to use. The same transport configuration is shared among all additional endpoints.
The is_reliable setting (First available in Agent 7.34.0) tells the Agent to treat this endpoint with the same priority as the primary endpoint. The primary endpoint is always reliable. This ensures that data is not missed if a destination becomes unavailable.
For example, if you’re sending data to the main endpoint and an additional endpoint with is_reliable: true, and one endpoint becomes unavailable, data continues to flow to the other endpoint. If both endpoints become unavailable, the Agent stops reading and sending data until at least one endpoint recovers. This ensures all data makes it to at least one reliable endpoint.
The is_reliable setting defaults to true in Agent 7.37.0+. Unreliable endpoints only send data if at least one reliable endpoint is available. You may define multiple additional endpoints with a mixed usage of is_reliable values. Datadog recommends that you use the default is_reliable setting.
You can add the YAML configuration to your datadog.yaml or launch the Agent with the appropriate environment variables.
When setting up additional endpoints, you must explicitly set use_http to tell the Agent which transport to use. The same transport configuration is shared among all additional endpoints.
The is_reliable setting (First available in Agent 7.34.0) tells the Agent to treat this endpoint with the same priority as the primary endpoint. The primary endpoint is always reliable. This ensures that data is not missed if a destination becomes unavailable.
For example, if you’re sending data to the main endpoint and an additional endpoint with is_reliable: true, and one endpoint becomes unavailable, data continues to flow to the other endpoint. If both endpoints become unavailable, the Agent stops reading and sending data until at least one endpoint recovers. This ensures all data makes it to at least one reliable endpoint.
The is_reliable setting defaults to true in Agent 7.37.0+. Unreliable endpoints only send data if at least one reliable endpoint is available. You may define multiple additional endpoints with a mixed usage of is_reliable values. Datadog recommends that you use the default is_reliable setting.
You can add the YAML configuration to your datadog.yaml or launch the Agent with the appropriate environment variables.
Envío doble en Kubernetes
Si utiliza el Datadog Agent Helm chart, puede configurar estos ajustes con un configmap. En values.yaml, establezca useConfigMap: true
y agregue la configuración relevante a customAgentConfig.
# agents.useConfigMap -- Configures a configmap to provide the agent configuration. Use this in combination with the `agents.customAgentConfig` parameter.useConfigMap:true# agents.customAgentConfig -- Specify custom contents for the datadog agent config (datadog.yaml)## ref: https://docs.datadoghq.com/agent/configuration/agent-configuration-files/?tab=agentv6## ref: https://github.com/DataDog/datadog-agent/tree/main/pkg/config/example## Note the `agents.useConfigMap` needs to be set to `true` for this parameter to be taken into account.customAgentConfig:additional_endpoints:"https://app.<DD_SITE>": # Replace <DD_SITE> with your Datadog site parameter (for example, datadoghq.com).- apikey2- apikey3"https://app.<DD_SITE>": # Replace <DD_SITE> with your Datadog site parameter (for example, datadoghq.eu).- apikey4logs_config:force_use_http:trueadditional_endpoints:- api_key:"apiKey2"Host:"agent-http-intake.logs.<DD_SITE>"# Replace <DD_SITE> with your Datadog site parameter (for example, datadoghq.com).Port:443is_reliable:true
Para evitar exponer su(s) clave(s) de API en texto plano dentro del ConfigMap, también puede utilizar la configuración de variables de entorno y hacer referencia a un secreto de Kubernetes. Aquí tiene un ejemplo para enviar métricas a una región adicional:
Cree un secreto de Kubernetes con el valor de configuración de su variable de entorno de esta guía:
kubectl create -n <DATADOG AGENT NAMESPACE> secret generic dual-shipping --from-literal metrics='{"https://app.<DD_SITE>": ["apikey4"]}'# Replace <DD_SITE> with your Datadog site parameter (for example, datadoghq.eu).
Utilice los parámetros del Helm chartdatadog.env o datadog.envFrom para hacer referencia a este secreto en su configuración:
Si está utilizando el operador de Datadog Agent, puede establecer la clave [key].customConfigurations.[key].configDataoverride para configurar estos ajustes. El siguiente ejemplo reemplaza el archivo de configuración datadog.yaml del node Agent para enviar métricas y registros a regiones adicionales.
apiVersion:datadoghq.com/v2alpha1kind:DatadogAgentmetadata:name:datadogspec:override:nodeAgent:customConfigurations:datadog.yaml:## Replace <DD_SITE> with your Datadog site parameter (for example, datadoghq.com (US1) for `apikey2` and `apikey3`, and datadoghq.eu (EU) for `apikey4`).configData:|- additional_endpoints:
"https://app.<DD_SITE>":
- apikey2
- apikey3
"https://app.<DD_SITE>":
- apikey4
logs_config:
force_use_http: true
additional_endpoints:
- api_key: "apiKey2"
Host: "agent-http-intake.logs.<DD_SITE>"
Port: 443
is_reliable: true
Para evitar exponer su(s) clave(s) de API en texto plano dentro del ConfigMap, también puede utilizar la configuración de variables de entorno y hacer referencia a un secreto de Kubernetes. Aquí tiene un ejemplo para enviar métricas a una región adicional:
Cree un secreto de Kubernetes con el valor de configuración de su variable de entorno de esta guía:
kubectl create -n <DATADOG AGENT NAMESPACE> secret generic dual-shipping --from-literal metrics='{"https://app.<DD_SITE>": ["apikey4"]}'# Replace <DD_SITE> with your Datadog site parameter (for example, datadoghq.eu).
Utilice el parámetro [key].env para hacer referencia a este secreto en su configuración:
