Si vous envoyez des données à plusieurs organisations Datadog, la fonctionnalité de transmission multiple peut avoir une incidence sur vos coûts. Pour en savoir plus sur les frais supplémentaires engendrés par cette configuration, contactez l'assistance Datadog.
Présentation
Ce document fournit des exemples de configurations de l’Agent pour l’envoi double de différents types de données (par exemple, APM, logs, métriques du Cluster Agent, etc.) vers plusieurs organisations Datadog.
Remarque : utilisez Observability Pipelines si vous souhaitez effectuer un envoi double de logs ou répartir le trafic de logs entre différents fournisseurs de journalisation, stockages cloud ou fournisseurs SIEM.
Pour obtenir une liste complète des destinations du trafic réseau, consultez la section Trafic réseau.
Métriques et checks de service
Vous pouvez ajouter la configuration YAML à votre datadog.yaml ou lancer l’Agent avec les variables d’environnement appropriées.
Remarque : les uploads vers des endpoints supplémentaires pour le produit Continuous Profiler sont effectués via une livraison au mieux.
L’endpoint principal a la priorité la plus élevée. Les uploads vers des endpoints supplémentaires ne sont gérés qu’après que les uploads vers l’endpoint principal ont été terminés avec succès.
Les réponses des endpoints supplémentaires ne sont pas renvoyées au profileur. Toutes les erreurs survenues lors de la livraison vers des endpoints supplémentaires sont enregistrées dans les logs d’erreur de l’Agent.
Pour garantir que l’autoscaling est résilient aux défaillances, configurez l’Agent de cluster pour exécuter vos requêtes de métriques pour le HPA sur vos plusieurs régions Datadog avec des données envoyées en double. Configurez le manifeste de l’Agent de cluster Datadog avec plusieurs endpoints :
Utilisez l’Agent si vous souhaitez effectuer un envoi double de logs vers plusieurs organisations Datadog. Utilisez Observability Pipelines si vous souhaitez envoyer des logs à Datadog et vers des destinations externes.
TCP nécessite la version >= 6.6 de l’Agent. HTTPS nécessite la version >= 6.13 de l’Agent.
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.
Transmission multiple dans Kubernetes
Si vous utilisez le chart Helm de l’Agent Datadog, vous pouvez configurer ces paramètres avec une configmap. Dans le fichier values.yaml, définissez useConfigMap: true et ajoutez les paramètres pertinents à customAgentConfig. et ajoutez les paramètres appropriés à 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/blob/main/pkg/config/config_template.yaml## Note the `agents.useConfigMap` needs to be set to `true` for this parameter to be taken into account.customAgentConfig:additional_endpoints:"https://app.datadoghq.com":- apikey2- apikey3"https://app.datadoghq.eu":- apikey4logs_config:force_use_http:trueadditional_endpoints:- api_key:"apiKey2"Host:"agent-http-intake.logs.datadoghq.com"Port:443is_reliable:true
Pour éviter d’exposer votre ou vos clés d’API en clair à l’intérieur de la ConfigMap, vous pouvez également utiliser la configuration de variable d’environnement et référencer un secret Kubernetes. Voici un exemple pour envoyer des métriques vers une région supplémentaire :
Créez un secret Kubernetes avec la valeur de configuration de votre variable d’environnement issue de ce guide :
Si vous utilisez l’opérateur de l’Agent Datadog, vous pouvez définir la clé de remplacement[key].customConfigurations.[key].configData pour définir ces paramètres. L’exemple ci-dessous remplace le fichier de configuration datadog.yaml du node Agent pour envoyer des métriques et des logs vers des régions supplémentaires.
Pour éviter d’exposer votre ou vos clés d’API en clair à l’intérieur de la ConfigMap, vous pouvez également utiliser la configuration de variable d’environnement et référencer un secret Kubernetes. Voici un exemple pour envoyer des métriques vers une région supplémentaire :
Créez un secret Kubernetes avec la valeur de configuration de votre variable d’environnement issue de ce guide :
