diff --git a/content/fr/containers/datadog_operator/advanced_install.md b/content/fr/containers/datadog_operator/advanced_install.md new file mode 100644 index 00000000000..b6ee6ace4e2 --- /dev/null +++ b/content/fr/containers/datadog_operator/advanced_install.md @@ -0,0 +1,301 @@ +--- +dependencies: +- https://github.com/DataDog/datadog-operator/blob/main/docs/installation.md +title: Installation du Datadog Operator +--- +Ce document contient des informations détaillées sur l'installation du Datadog Operator. Pour obtenir des instructions d'installation de base de l'Agent Datadog sur Kubernetes, consultez la section [Installer l'Agent Datadog sur Kubernetes][10]. + +## Prérequis + +- **Version de cluster Kubernetes >= v1.20.X** : les tests ont été effectués sur les versions Kubernetes >= `1.20.0`. Il devrait fonctionner sur les versions `>= v1.11.0`, mais pour les versions antérieures, l'opérateur peut ne pas fonctionner comme prévu en raison d'une prise en charge limitée des CRD. +- **[Helm][1]** pour le déploiement du Datadog Operator +- **[`kubectl` CLI][2]** pour l'installation de l'Agent Datadog + + +## Installer le Datadog Operator avec Helm + +Vous pouvez déployer le Datadog Operator dans votre cluster à l'aide du [chart Helm Datadog Operator][3] : + +```shell +helm repo add datadog https://helm.datadoghq.com +helm install my-datadog-operator datadog/datadog-operator +``` + +Pour personnaliser la configuration de l'opérateur, créez un fichier `values.yaml` qui peut remplacer les valeurs par défaut du chart Helm. + +Par exemple : + +```yaml +image: + tag: 1.2.0 +clusterName: my-cluster +datadogMonitor: + enabled: true +``` + +Ensuite, pour mettre à jour la version de Helm, exécutez : + +```shell +helm upgrade my-datadog-operator datadog/datadog-operator -f values.yaml +``` + +### Ajouter des informations d'identification + +1. Créez un Secret Kubernetes qui contient vos clés d'API et d'application. + + ``` + export DD_API_KEY= + export DD_APP_KEY= + + kubectl create secret generic datadog-operator-secret --from-literal api-key=$DD_API_KEY --from-literal app-key=$DD_APP_KEY + ``` + +2. Faites référence à ce Secret dans votre fichier `values.yaml`. + + ```yaml + apiKeyExistingSecret: datadog-operator-secret + appKeyExistingSecret: datadog-operator-secret + image: + tag: 1.2.0 + datadogMonitor: + enabled: true + ``` + +3. Mettez à jour la version de Helm. + + ```shell + helm upgrade my-datadog-operator datadog/datadog-operator -f values.yaml + ``` + +### Configurer le nom de cluster (facultatif) + +La définition d'un nom de cluster est facultative mais recommandée. Le nom de cluster peut être configuré de la manière suivante : + +- **Valeur `clusterName` du chart Helm** (définit la variable d'environnement `DD_CLUSTER_NAME` sur l'opérateur) : + ```yaml + clusterName: my-cluster + ``` + +- **CRD DatadogAgent `spec.global.clusterName`** : + ```yaml + apiVersion: datadoghq.com/v2alpha1 + kind: DatadogAgent + metadata: + name: datadog + spec: + global: + clusterName: my-cluster + ``` + +## Installer le Datadog Operator avec Operator Lifecycle Manager + +Les instructions pour le déploiement du Datadog Operator avec [Operator Lifecycle Manager][4] (OLM) sont disponibles sur [operatorhub.io][5]. + +### Remplacer la configuration par défaut de l'opérateur avec OLM + +Le framework [Operator Lifecycle Manager][4] permet de remplacer la configuration par défaut de l'opérateur. Consultez la section [Configuration de l'abonnement][6] pour obtenir une liste des paramètres de configuration d'installation pris en charge. + +Par exemple, l'élément `Subscription` [Operator Lifecycle Manager][4] suivant modifie les ressources de Pod de l'opérateur Datadog : + +```yaml +apiVersion: operators.coreos.com/v1alpha1 +kind: Subscription +metadata: + name: my-datadog-operator + namespace: operators +spec: + channel: stable + name: datadog-operator + source: operatorhubio-catalog + sourceNamespace: olm + config: + resources: + requests: + memory: "250Mi" + cpu: "250m" + limits: + memory: "250Mi" + cpu: "500m" +``` + +### Ajouter des informations d'identification + +1. Créez un Secret Kubernetes qui contient vos clés d'API et d'application. + + ``` + export DD_API_KEY= + export DD_APP_KEY= + + kubectl create secret generic datadog-operator-secret --from-literal api-key=$DD_API_KEY --from-literal app-key=$DD_APP_KEY + ``` + +2. Ajoutez des références au Secret dans l'instance de ressource `Subscription` du Datadog Operator. + + ```yaml + apiVersion: operators.coreos.com/v1alpha1 + kind: Subscription + metadata: + name: my-datadog-operator + namespace: operators + spec: + channel: stable + name: datadog-operator + source: operatorhubio-catalog + sourceNamespace: olm + config: + env: + - name: DD_API_KEY + valueFrom: + secretKeyRef: + key: api-key + name: datadog-operator-secret + - name: DD_APP_KEY + valueFrom: + secretKeyRef: + key: app-key + name: datadog-operator-secret + ``` + + +## Déployer la ressource personnalisée DatadogAgent gérée par l'opérateur + +Après avoir déployé le Datadog Operator, créez la ressource `DatadogAgent` qui déclenche le déploiement de l'Agent Datadog, de l'Agent de cluster et des Cluster Checks Runners (s'ils sont utilisés) dans votre cluster Kubernetes. L'Agent Datadog est déployé en tant que DaemonSet, exécutant un pod sur chaque nœud de votre cluster. + +1. Créez un Secret Kubernetes avec vos clés d'API et d'application. + + ``` + export DD_API_KEY= + export DD_APP_KEY= + + kubectl create secret generic datadog-secret --from-literal api-key= --from-literal app-key= + ``` + +1. Créez un fichier avec les spécifications de votre configuration de déploiement `DatadogAgent`. La configuration la plus simple est la suivante : + + ```yaml + apiVersion: datadoghq.com/v1alpha1 + kind: DatadogAgent + metadata: + name: datadog + spec: + credentials: + apiSecret: + secretName: datadog-secret + keyName: api-key + appSecret: + secretName: datadog-secret + keyName: app-key + ``` + +1. Déployez l'Agent Datadog avec le fichier de configuration ci-dessus : + ```shell + kubectl apply -f /path/to/your/datadog-agent.yaml + ``` + +Dans un cluster avec deux nœuds de travail, vous devriez voir les pods de l'Agent créés sur chaque nœud. + +```console +$ kubectl get daemonset +NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE +datadog-agent 2 2 2 2 2 5m30s + +$ kubectl get pod -owide +NAME READY STATUS RESTARTS AGE IP NODE +agent-datadog-operator-d897fc9b-7wbsf 1/1 Running 0 1h 10.244.2.11 kind-worker +datadog-agent-k26tp 1/1 Running 0 5m59s 10.244.2.13 kind-worker +datadog-agent-zcxx7 1/1 Running 0 5m59s 10.244.1.7 kind-worker2 +``` + +### Tolérances + +Mettez à jour votre [fichier `datadog-agent.yaml`][8] avec la configuration suivante pour ajouter des tolérances dans le `Daemonset.spec.template` de votre DaemonSet : + + ```yaml + apiVersion: datadoghq.com/v1alpha1 + kind: DatadogAgent + metadata: + name: datadog + spec: + credentials: + apiSecret: + secretName: datadog-secret + keyName: api-key + appSecret: + secretName: datadog-secret + keyName: app-key + agent: + config: + tolerations: + - operator: Exists + ``` + +Appliquez cette nouvelle configuration : + +```console +$ kubectl apply -f datadog-agent.yaml +datadogagent.datadoghq.com/datadog updated +``` + +Validez la mise à jour du DaemonSet en consultant la nouvelle valeur de pod `desired` : + +```console +$ kubectl get daemonset +NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE +datadog-agent 3 3 3 3 3 7m31s + +$ kubectl get pod +NAME READY STATUS RESTARTS AGE +agent-datadog-operator-d897fc9b-7wbsf 1/1 Running 0 15h +datadog-agent-5ctrq 1/1 Running 0 7m43s +datadog-agent-lkfqt 0/1 Running 0 15s +datadog-agent-zvdbw 1/1 Running 0 8m1s +``` + +## Configuration + +Pour obtenir une liste complète des options de configuration, consultez la section [Spécification de configuration][12]. + +## Installer le plugin kubectl + +Consultez la [documentation dédiée au plugin `kubectl`][11]. + +## Utiliser une image personnalisée du Datadog Operator + +Consultez la section [Images de conteneur personnalisées pour l'opérateur][9] pour obtenir des instructions sur la création d'une image de conteneur personnalisée du Datadog Operator basée sur une version officielle. + +### Images du Datadog Operator avec les charts Helm + +Pour installer une image personnalisée du Datadog Operator à l'aide du chart Helm, exécutez la commande suivante : + +```shell +helm install my-datadog-operator --set image.repository= --set image.tag= datadog/datadog-operator +``` + +## Nettoyage + +La commande suivante supprime toutes les ressources Kubernetes créées par le Datadog Operator et l'élément `DatadogAgent` `datadog` lié. + +```shell +kubectl delete datadogagent datadog +``` + +Cette commande affiche `datadogagent.datadoghq.com/datadog deleted`. + +Vous pouvez ensuite supprimer le Datadog Operator avec la commande `helm delete` : + +```shell +helm delete my-datadog-operator +``` + +[1]: https://helm.sh +[2]: https://kubernetes.io/docs/tasks/tools/install-kubectl/ +[3]: https://artifacthub.io/packages/helm/datadog/datadog-operator +[4]: https://olm.operatorframework.io/ +[5]: https://operatorhub.io/operator/datadog-operator +[6]: https://github.com/operator-framework/operator-lifecycle-manager/blob/master/doc/design/subscription-config.md +[7]: https://app.datadoghq.com/account/settings#api +[8]: https://github.com/DataDog/datadog-operator/blob/main/examples/datadogagent/datadog-agent-with-tolerations.yaml +[9]: https://github.com/DataDog/datadog-operator/blob/main/docs/custom-operator-image.md +[10]: https://docs.datadoghq.com/fr/containers/kubernetes/installation +[11]: https://github.com/DataDog/datadog-operator/blob/main/docs/kubectl-plugin.md +[12]: https://github.com/DataDog/datadog-operator/blob/main/docs/configuration.v2alpha1.md \ No newline at end of file diff --git a/content/fr/containers/datadog_operator/crd_dashboard.md b/content/fr/containers/datadog_operator/crd_dashboard.md new file mode 100644 index 00000000000..277c041dd49 --- /dev/null +++ b/content/fr/containers/datadog_operator/crd_dashboard.md @@ -0,0 +1,104 @@ +--- +description: Déployer et gérer les dashboards Datadog en utilisant la définition de + ressource personnalisée DatadogDashboard avec le Datadog Operator +title: CRD DatadogDashboard +--- +Pour déployer un dashboard Datadog, vous pouvez utiliser le Datadog Operator et la définition de ressource personnalisée (CRD) `DatadogDashboard`. + +### Prérequis +- [Helm][1] +- [`kubectl` CLI][2] +- [Datadog Operator][3] v0.6+ + +### Configuration + +1. Exécutez la commande d'installation en remplaçant vos clés d'API et d'application Datadog : + ```shell + helm install my-datadog-operator datadog/datadog-operator --set apiKey= --set appKey= --set datadogDashboard.enabled=true --set datadogCRDs.crds.datadogDashboards=true + ``` + +1. Créez un fichier avec les spécifications de votre configuration de déploiement `DatadogDashboard`. + + **Exemple** : + + {{< code-block lang="yaml" filename="datadog-dashboard.yaml" collapsible="true" >}} + apiVersion: datadoghq.com/v1alpha1 + kind: DatadogDashboard + metadata: + name: example-dashboard + spec: + title: Test Dashboard + layoutType: ordered + tags: + - "team:my_team" + templateVariables: + - availableValues: + - host1 + - host2 + - host3 + name: first + prefix: bar-foo + notifyList: + - foobar@example.com + widgets: '[{ + "id": 2639892738901474, + "definition": { + "title": "", + "title_size": "16", + "title_align": "left", + "show_legend": true, + "legend_layout": "auto", + "legend_columns": [ + "avg", + "min", + "max", + "value", + "sum" + ], + "type": "timeseries", + "requests": [ + { + "formulas": [ + { + "formula": "query1" + } + ], + "queries": [ + { + "name": "query1", + "data_source": "metrics", + "query": "avg:system.cpu.user{*} by {host}" + } + ], + "response_format": "timeseries", + "style": { + "palette": "dog_classic", + "order_by": "values", + "line_type": "solid", + "line_width": "normal" + }, + "display_type": "line" + } + ] + }, + "layout": { + "x": 0, + "y": 0, + "width": 4, + "height": 2 + } + }]' + {{< /code-block >}} + + Pour découvrir toutes les options de configuration disponibles, consultez la section [Référence de l'API de création d'un dashboard][4]. + +2. Déployez votre `DatadogDashboard` : + + ```shell + kubectl apply -f /path/to/your/datadog-dashboard.yaml + ``` + +[1]: https://helm.sh/ +[2]: https://kubernetes.io/docs/tasks/tools/install-kubectl/ +[3]: /fr/containers/kubernetes/installation?tab=datadogoperator#installation +[4]: /fr/api/latest/dashboards/#create-a-new-dashboard \ No newline at end of file diff --git a/content/fr/containers/datadog_operator/crd_monitor.md b/content/fr/containers/datadog_operator/crd_monitor.md new file mode 100644 index 00000000000..40b85ed1436 --- /dev/null +++ b/content/fr/containers/datadog_operator/crd_monitor.md @@ -0,0 +1,346 @@ +--- +description: Déployer et gérer les Monitors Datadog en utilisant la définition de + ressource personnalisée DatadogMonitor avec le Datadog Operator +further_reading: +- link: https://docs.datadoghq.com/api/latest/monitors/#create-a-monitor + tag: API Datadog + text: 'Référence de l''API : créer un Monitor Datadog' +- link: https://github.com/DataDog/helm-charts/blob/main/crds/datadoghq.com_datadogmonitors.yaml + tag: GitHub + text: DatadogMonitor CRD +title: CRD DatadogMonitor +--- + +Pour déployer un Monitor Datadog, vous pouvez utiliser le Datadog Operator et la définition de ressource personnalisée (CRD) `DatadogMonitor`. + +## Prérequis +- [Helm][1] +- [`kubectl` CLI][2] +- [Datadog Operator][3] v0.6+ + +## Configuration + +1. Créez un fichier avec les spécifications de votre configuration de déploiement `DatadogMonitor`. + + **Exemple** : + + La spécification suivante crée un [Monitor de métrique][4] qui envoie une alerte sur la requête `avg(last_10m):avg:system.disk.in_use{*} by {host} > 0.5`. + + {{< code-block lang="yaml" filename="datadog-metric-monitor.yaml" collapsible="true" >}} + apiVersion: datadoghq.com/v1alpha1 + kind: DatadogMonitor + metadata: + name: datadog-monitor-test + namespace: datadog + spec: + query: "avg(last_10m):avg:system.disk.in_use{*} by {host} > 0.5" + type: "metric alert" + name: "Test monitor made from DatadogMonitor" + message: "1-2-3 testing" + tags: + - "test:datadog" + priority: 5 + controllerOptions: + disableRequiredTags: false + options: + evaluationDelay: 300 + includeTags: true + locked: false + newGroupDelay: 300 + notifyNoData: true + noDataTimeframe: 30 + renotifyInterval: 1440 + thresholds: + critical: "0.5" + warning: "0.28" + {{< /code-block >}} + + Consultez la [liste complète des champs de configuration](#tous-les-champs-de-configuration-disponibles). + +2. Déployez votre `DatadogMonitor` : + + ```shell + kubectl apply -f /path/to/your/datadog-metric-monitor.yaml + ``` + +## Autres exemples + +### Monitors de métriques +- [Un pod est en CrashLoopBackOff][6] +- [Un pod est en ImagePullBackOff][8] +- [Les pods de plusieurs réplicas de déploiement sont arrêtés][7] +- [Les pods de plusieurs réplicas de StatefulSet sont arrêtés][12] +- [Plus de 20 % des nœuds d'un cluster ne peuvent pas être planifiés][9] +- [Plus de 10 pods sont en échec dans un cluster][10] +- [Les pods redémarrent plusieurs fois au cours des cinq dernières minutes][11] + + +### Autres monitors +- [Monitor d'audit][13] +- [Monitor d'événement][14] +- [Monitor d'événement V2][15] +- [Monitor de log][16] +- [Monitor de processus][17] +- [Monitor RUM][18] +- [Check de service Monitor][19] +- [Monitor de SLO][20] +- [Monitor de trace analytics][21] + +## Tous les champs de configuration disponibles + +Le tableau suivant répertorie tous les champs de configuration disponibles pour la ressource personnalisée `DatadogMonitor`. + +`message` +: **obligatoire** - _chaîne_ +
Message à inclure dans les notifications de ce Monitor. + +`name` +: **obligatoire** - _chaîne_ +
Nom du Monitor. + +`query` +: **obligatoire** - _chaîne_ +
Requête du Monitor. + +`type` +: **obligatoire** - _énumération_ +
Type du Monitor. +
Valeurs d'énumération autorisées : `metric alert`, `query alert`, `service check`, `event alert`, `log alert`, `process alert`, `rum alert`, `trace-analytics alert`, `slo alert`, `event-v2 alert`, `audit alert`, `composite` + +`controllerOptions.disableRequiredTags` +: _booléen_ +
Désactive l'ajout automatique de tags requis aux Monitors. + +`priority` +: _int64_ +
Entier de 1 (élevé) à 5 (faible) indiquant la gravité de l'alerte. + +`restrictedRoles` +: _[chaîne]_ +
Liste d'identifiants de rôle uniques définissant les rôles autorisés à modifier le Monitor. Les identifiants uniques de tous les rôles peuvent être récupérés à partir de l'[API Roles][22] et se trouvent dans le champ `data.id`. + +`tags` +: _[chaîne]_ +
Tags associés à votre Monitor. + +`options` +: _objet +
Liste des options associées à votre Monitor. Consultez la section [Options](#options). + +### Options + +Les champs suivants sont définis dans la propriété `options`. + +Exemple : + +{{< highlight yaml "hl_lines=11-15" >}} +apiVersion: datadoghq.com/v1alpha1 +kind: DatadogMonitor +metadata: + name: datadog-monitor-test + namespace: datadog +spec: + query: "avg(last_10m):avg:system.disk.in_use{*} by {host} > 0.5" + type: "metric alert" + name: "Test monitor made from DatadogMonitor" + message: "1-2-3 testing" + options: + enableLogsSample: true + thresholds: + critical: "0.5" + warning: "0.28" +{{< /highlight >}} + +`enableLogsSample` +: _booléen +
Indique si un échantillon de log doit être envoyé lorsque le Monitor de log se déclenche. + +`escalationMessage` +: _chaîne_ +
Message à inclure dans une nouvelle notification. + +`evaluationDelay` +: _int64_ +
Délai (en secondes) avant l'évaluation, sous forme d'entier non négatif. Par exemple : si la valeur est définie sur 300 (5 min), la période est définie sur `last_5m` et l'heure est 7:00, le Monitor évalue les données de 6:50 à 6:55. Cette option est utile pour AWS CloudWatch et d'autres métriques renvoyées rétroactivement afin de garantir que le Monitor dispose toujours de données lors de l'évaluation. + +`groupRetentionDuration` +: _chaîne_ +
Durée après laquelle les groupes dont les données sont manquantes sont supprimés de l'état du Monitor. La valeur minimale est d'une heure et la valeur maximale est de 72 heures. Exemples de valeurs : `60m`, `1h` et `2d`. Cette option est disponible uniquement pour les Monitors APM Trace Analytics, Audit Trail, CI, Error Tracking, Event, Logs et RUM. + +`groupbySimpleMonitor` +: booléen +
OBSOLÈTE : indique si le Monitor d'alerte de log déclenche une alerte unique ou plusieurs alertes lorsqu'un groupe dépasse un seuil. Utilisez `notifyBy` à la place. + +`includeTags` +: booléen +
Valeur booléenne indiquant si les notifications de ce Monitor insèrent automatiquement ses tags de déclenchement dans le titre. + +`locked` +: booléen +
OBSOLÈTE : indique si le Monitor est verrouillé (modifiable uniquement par le créateur et les administrateurs). Utilisez `restrictedRoles` à la place. + +`newGroupDelay` +: _int64_ +
Délai (en secondes) accordé à un host pour démarrer et aux applications pour démarrer complètement avant de commencer l'évaluation des résultats du Monitor. Doit être un entier non négatif. + +`noDataTimeframe` +: _int64_ +
Nombre de minutes avant qu'un Monitor n'envoie une notification après l'arrêt du signalement des données. Datadog recommande au moins 2 fois la période du Monitor pour les alertes de métrique ou 2 minutes pour les checks de service. En cas d'omission, 2 fois la période d'évaluation est utilisée pour les alertes de métrique et 24 heures sont utilisées pour les checks de service. + +`notificationPresetName` +: _énumération_ +
Active/désactive l'affichage du contenu supplémentaire envoyé dans la notification du Monitor. +
Valeurs d'énumération autorisées : `show_all`, `hide_query`, `hide_handles`, `hide_all` +
Par défaut : `show_all` + +`notifyAudit` +: _booléen +
Valeur booléenne indiquant si les utilisateurs tagués sont informés des modifications apportées à ce Monitor. + +`notifyBy` +: _[chaîne]_ +
Chaîne indiquant la granularité sur laquelle un Monitor envoie des alertes. Disponible uniquement pour les Monitors avec groupements. Par exemple, si vous avez un Monitor groupé par cluster, espace de nommage et pod, et que vous définissez `notifyBy` sur `["cluster"]`, votre Monitor n'envoie des notifications que pour chaque nouveau cluster enfreignant les conditions d'alerte. +
Les tags mentionnés dans `notifyBy` doivent être un sous-ensemble des tags de groupement de la requête. Par exemple, une requête groupée par cluster et espace de nommage ne peut pas notifier par région. +
La définition de `notifyBy` sur `[*]` configure le Monitor pour qu'il notifie sous forme d'alerte simple. + +`notifyNoData` +: booléen +
Valeur booléenne indiquant si ce Monitor envoie une notification lorsque les données cessent d'être signalées. +
Par défaut : `false`. + +`onMissingData` +: _énumération_ +
Contrôle la façon dont les groupes ou Monitors sont traités si une évaluation ne renvoie aucun point de données. L'option par défaut entraîne un comportement différent selon le type de requête du Monitor. Pour les Monitors utilisant des requêtes de type Count, une évaluation de Monitor vide est traitée comme 0 et est comparée aux conditions de seuil. Pour les Monitors utilisant un type de requête autre que Count, par exemple Gauge, Measure ou Rate, le Monitor affiche le dernier statut connu. Cette option est disponible uniquement pour les Monitors APM Trace Analytics, Audit Trail, CI, Error Tracking, Event, Logs et RUM. +
Valeurs d'énumération autorisées : `default`, `show_no_data`, `show_and_notify_no_data`, `resolve` + +`renotifyInterval` +: _int64_ +
Nombre de minutes après la dernière notification avant qu'un Monitor n'envoie une nouvelle notification sur le statut actuel. Il ne notifie à nouveau que s'il n'est pas résolu. + +`renotifyOccurrences` +: _int64_ +
Nombre de fois que les messages de nouvelle notification doivent être envoyés sur le statut actuel à l'intervalle de nouvelle notification fourni. + +`renotifyStatuses` +: _[chaîne]_ +
Types de statuts de Monitor pour lesquels des messages de nouvelle notification sont envoyés. +
Si `renotifyInterval` est null, la valeur par défaut est null. +
Si `renotifyInterval` n'est pas null, la valeur par défaut est `["Alert", "No Data"]` +
Valeurs pour le statut du Monitor : `Alert`, `No Data`, `Warn` + +`requireFullWindow` +: booléen +
Valeur booléenne indiquant si ce Monitor nécessite une fenêtre complète de données avant d'être évalué. Datadog recommande vivement de définir cette valeur sur `false` pour les métriques éparses, sinon certaines évaluations sont ignorées. +
Par défaut : `false`. + +`schedulingOptions` +: _objet_ +
Options de configuration pour la planification : + + `customSchedule` + : _object_ +
Options de configuration pour le site personnalisé schedule (programmer): + + `recurrence` + : _[objet]_ +
Tableau de récurrences de planification personnalisée. + + `rrule` + : _chaîne_ +
Règle de récurrence au format iCalendar. Par exemple, `FREQ=MONTHLY;BYMONTHDAY=28,29,30,31;BYSETPOS=-1`. + + `start` + : _chaîne_ +
Date de début de la règle de récurrence définie au format `YYYY-MM-DDThh:mm:ss`. En cas d'omission, l'heure de création du Monitor est utilisée. + + `timezone` + : _chaîne_ +
Fuseau horaire au format `tz database`, dans lequel la règle de récurrence est définie. Par exemple, `America/New_York` ou `UTC`. + + `evaluationWindow` + : _objet_ +
Options de configuration pour la fenêtre d'évaluation. Si `hour_starts` est défini, aucun autre champ ne peut être défini. Sinon, `day_starts` et `month_starts` doivent être définis ensemble. + + `dayStarts` + : _chaîne_ +
Heure de la journée à laquelle commence une fenêtre d'évaluation cumulative d'un jour. Doit être définie en heure UTC au format `HH:mm`. + + `hourStarts` + : _entier_ +
Minute de l'heure à laquelle commence une fenêtre d'évaluation cumulative d'une heure. + + `monthStarts` + : _entier_ +
Jour du mois auquel commence une fenêtre d'évaluation cumulative d'un mois. + +`thresholdWindows` +: _objet_ +
Options de fenêtre temporelle d'alerte : + + `recoveryWindow` + : _chaîne_ +
Décrit la durée pendant laquelle une métrique anormale doit être normale avant que l'alerte ne se rétablisse. + + `triggerWindow` + : _chaîne_ +
Décrit la durée pendant laquelle une métrique doit être anormale avant qu'une alerte ne se déclenche. + +`thresholds` +: _objet_ +
Liste des différents seuils de Monitor disponibles : + + `critical` + : _chaîne_ +
Seuil CRITICAL du Monitor. + + `criticalRecovery` + : _chaîne_ +
Seuil de rétablissement CRITICAL du Monitor. + + `ok` + : _chaîne_ +
Seuil OK du Monitor. + + `unknown` + : _chaîne_ +
Seuil UNKNOWN du Monitor. + + `warning` + : _chaîne_ +
Seuil WARNING du Monitor. + + `warningRecovery` + : _chaîne_ +
Seuil de rétablissement WARNING du Monitor. + +`timeoutH` +: _int64_ +
Nombre d'heures pendant lesquelles le Monitor ne signale pas de données avant qu'il ne se résolve automatiquement à partir d'un état déclenché. + +## Pour aller plus loin + +{{< partial name="whats-next/whats-next.html" >}} + + +[1]: https://helm.sh/ +[2]: https://kubernetes.io/docs/tasks/tools/install-kubectl/ +[3]: /fr/containers/kubernetes/installation?tab=datadogoperator#installation +[4]: /fr/monitors/types/metric/?tab=threshold +[5]: /fr/api/latest/monitors/#create-a-monitor +[6]: https://github.com/DataDog/datadog-operator/blob/main/examples/datadogmonitor/metric-monitor-crashloopbackoff.yaml +[7]: https://github.com/DataDog/datadog-operator/blob/main/examples/datadogmonitor/metric-monitor-deployment-replicas.yaml +[8]: https://github.com/DataDog/datadog-operator/blob/main/examples/datadogmonitor/metric-monitor-imagepullbackoff.yaml +[9]: https://github.com/DataDog/datadog-operator/blob/main/examples/datadogmonitor/metric-monitor-nodes-unavailable.yaml +[10]: https://github.com/DataDog/datadog-operator/blob/main/examples/datadogmonitor/metric-monitor-pods-failed-state.yaml +[11]: https://github.com/DataDog/datadog-operator/blob/main/examples/datadogmonitor/metric-monitor-pods-restarting.yaml +[12]: https://github.com/DataDog/datadog-operator/blob/main/examples/datadogmonitor/metric-monitor-statefulset-replicas.yaml +[13]: https://github.com/DataDog/datadog-operator/blob/main/examples/datadogmonitor/audit-alert-monitor-test.yaml +[14]: https://github.com/DataDog/datadog-operator/blob/main/examples/datadogmonitor/event-alert-monitor-test.yaml +[15]: https://github.com/DataDog/datadog-operator/blob/main/examples/datadogmonitor/event-v2-alert-monitor-test.yaml +[16]: https://github.com/DataDog/datadog-operator/blob/main/examples/datadogmonitor/log-alert-monitor-test.yaml +[17]: https://github.com/DataDog/datadog-operator/blob/main/examples/datadogmonitor/process-alert-monitor-test.yaml +[18]: https://github.com/DataDog/datadog-operator/blob/main/examples/datadogmonitor/rum-alert-monitor-test.yaml +[19]: https://github.com/DataDog/datadog-operator/blob/main/examples/datadogmonitor/service-check-monitor-test.yaml +[20]: https://github.com/DataDog/datadog-operator/blob/main/examples/datadogmonitor/slo-alert-monitor-test.yaml +[21]: https://github.com/DataDog/datadog-operator/blob/main/examples/datadogmonitor/trace-analytics-alert-monitor-test.yaml +[22]: /fr/api/latest/roles/#list-roles \ No newline at end of file diff --git a/content/fr/containers/datadog_operator/crd_slo.md b/content/fr/containers/datadog_operator/crd_slo.md new file mode 100644 index 00000000000..8f9d57a0862 --- /dev/null +++ b/content/fr/containers/datadog_operator/crd_slo.md @@ -0,0 +1,79 @@ +--- +description: Créer et gérer les objectifs de niveau de service (SLO) Datadog en utilisant + la définition de ressource personnalisée DatadogSLO +title: CRD DatadogSLO +--- + +Pour créer un [objectif de niveau de service][1] (SLO), vous pouvez utiliser le Datadog Operator et la définition de ressource personnalisée (CRD) `DatadogSLO`. + +### Prérequis +- [Helm][2] +- [`kubectl` CLI][3] +- [Datadog Operator][4] v0.6+ + +### Configuration + +1. Créez un fichier avec les spécifications de votre configuration de déploiement `DatadogSLO`. + + **Exemple** : SLO [basé sur un Monitor][5] + + {{< code-block lang="yaml" filename="datadog-slo.yaml" collapsible="true" >}} + apiVersion: datadoghq.com/v1alpha1 + kind: DatadogSLO + metadata: + name: example-slo-monitor3 + namespace: system + spec: + name: example-slo-monitor3 + description: "This is an example monitor SLO from datadog-operator" + monitorIDs: + - 1234 + tags: + - "service:example" + - "env:prod" + targetThreshold: "99.9" + timeframe: "7d" + type: "monitor" + {{< /code-block >}} + + **Example**: [Metric-based][6] SLO + + {{< code-block lang="yaml" filename="datadog-slo.yaml" collapsible="true" >}} + apiVersion: datadoghq.com/v1alpha1 + kind: DatadogSLO + metadata: + name: example-slo + namespace: system + spec: + name: example-slo + description: "This is an example metric SLO from datadog-operator" + query: + denominator: "sum:requests.total{service:example,env:prod}.as_count()" + numerator: "sum:requests.success{service:example,env:prod}.as_count()" + tags: + - "service:example" + - "env:prod" + targetThreshold: "99.9" + timeframe: "7d" + type: "metric" + {{< /code-block >}} + + Pour découvrir toutes les options de configuration disponibles, consultez la section [Référence de l'API de création d'un objet SLO][4]. + +2. Déployez votre `DatadogSLO` : + + ```shell + kubectl apply -f /path/to/your/datadog-slo.yaml + ``` + +### Autres exemples +[SLO basé sur une métrique avec Universal Service Monitoring][8] + +[1]: /fr/service_management/service_level_objectives/ +[2]: https://helm.sh/ +[3]: https://kubernetes.io/docs/tasks/tools/install-kubectl/ +[4]: /fr/api/latest/service-level-objectives/#create-an-slo-object +[5]: /fr/service_management/service_level_objectives/monitor/ +[6]: /fr/service_management/service_level_objectives/metric/ +[7]: /fr/api/latest/service-level-objectives/#create-an-slo-object +[8]: https://github.com/DataDog/datadog-operator/blob/main/examples/datadogslo/metric-usm-example.yaml \ No newline at end of file diff --git a/content/fr/containers/datadog_operator/custom_check.md b/content/fr/containers/datadog_operator/custom_check.md new file mode 100644 index 00000000000..4e68c441c62 --- /dev/null +++ b/content/fr/containers/datadog_operator/custom_check.md @@ -0,0 +1,168 @@ +--- +dependencies: +- 'https://github.com/DataDog/datadog-operator/blob/main/docs/custom_check.md ' +title: Checks personnalisés +--- +Pour exécuter un [check personnalisé][1], vous pouvez configurer la ressource `DatadogAgent` pour fournir des checks personnalisés `checks.d`) et leurs fichiers de configuration correspondants `conf.d`) au moment de l'initialisation. Vous devez configurer une ressource ConfigMap pour chaque fichier de script de check et son fichier de configuration. + +Cette page explique comment configurer un check personnalisé, `hello`, qui envoie une métrique `hello.world` à Datadog. + +Pour en savoir plus sur les checks dans l'écosystème Datadog, consultez la section [Présentation des intégrations][2]. Pour configurer une [intégration Datadog][3], consultez la section [Kubernetes et intégrations][4] + +## Créer les fichiers de check + +Chaque check nécessite un fichier de configuration `hello.yaml`) et un fichier de script `hello.py`). + +1. Créez `hello.yaml` avec le contenu suivant : + + ```yaml + init_config: + + instances: [{}] + ``` + +2. Créez `hello.py` avec le contenu suivant : + + ```python + from datadog_checks.base import AgentCheck + + __version__ = "1.0.0" + class HelloCheck(AgentCheck): + def check(self, instance): + self.gauge('hello.world', 1, tags=['env:dev']) + ``` + +## Créer les ConfigMaps de check + +Après avoir créé les fichiers de check `hello`, créez les ConfigMaps associées : + +1. Créez la ConfigMap pour le fichier de configuration YAML du check personnalisé `hello.yaml` : + + ```bash + $ kubectl create configmap -n $DD_NAMESPACE confd-config --from-file=hello.yaml + configmap/confd-config created + ``` + +2. Vérifiez que la ConfigMap a été correctement créée : + + ```bash + $ kubectl get configmap -n $DD_NAMESPACE confd-config -o yaml + apiVersion: v1 + data: + hello.yaml: | + init_config: + + instances: [{}] + kind: ConfigMap + metadata: + name: confd-config + namespace: datadog + ``` + +3. Créez la ConfigMap pour le fichier Python du check personnalisé `hello.py` : + + ```bash + $ kubectl create configmap -n $DD_NAMESPACE checksd-config --from-file=hello.py + configmap/checksd-config created + ``` + +4. Vérifiez que la ConfigMap a été correctement créée : + + ```bash + $ kubectl get configmap -n $DD_NAMESPACE checksd-config -o yaml + apiVersion: v1 + data: + hello.py: | + from datadog_checks.base import AgentCheck + + __version__ = "1.0.0" + class HelloCheck(AgentCheck): + def check(self, instance): + self.gauge('hello.world', 1, tags=['env:dev']) + kind: ConfigMap + metadata: + name: checksd-config + namespace: datadog + ``` + +## Configurer l'Agent Datadog + +Après avoir créé vos ConfigMaps, créez une ressource `DatadogAgent` pour les utiliser : + +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + global: + credentials: + apiKey: "" + appKey: "" + override: + nodeAgent: + extraConfd: + configMap: + name: confd-config + extraChecksd: + configMap: + name: checksd-config +``` + +**Remarque** : toutes les ConfigMaps que vous créez doivent se trouver dans le même `DD_NAMESPACE` que la ressource `DatadogAgent`. + +Cela déploie l'Agent Datadog avec votre check personnalisé. + +### ConfigMaps pour plusieurs checks + +Vous pouvez remplir les ConfigMaps avec le contenu de plusieurs checks ou de leurs fichiers de configuration respectifs. + +#### Remplir tous les fichiers de script de check + +```bash +$ kubectl create cm -n $DD_NAMESPACE checksd-config $(find ./checks.d -name "*.py" | xargs -I'{}' echo -n '--from-file={} ') +configmap/checksd-config created +``` + +#### Remplir tous les fichiers de configuration de check + +```bash +$ kubectl create cm -n $DD_NAMESPACE confd-config $(find ./conf.d -name "*.yaml" | xargs -I'{}' echo -n '--from-file={} ') +configmap/confd-config created +``` + +## Fournir des volumes supplémentaires + +Vous pouvez monter des volumes supplémentaires configurés par l'utilisateur dans les conteneurs de l'Agent de nœud ou de l'Agent de cluster en définissant les propriétés `volumes` et `volumeMounts`. + +**Exemple** : utiliser un volume pour monter un secret + +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + global: + credentials: + apiKey: "" + appKey: "" + override: + nodeAgent: + image: + name: "gcr.io/datadoghq/agent:latest" + volumes: + - name: secrets + secret: + secretName: secrets + containers: + agent: + volumeMounts: + - name: secrets + mountPath: /etc/secrets + readOnly: true +``` +[1]: https://docs.datadoghq.com/fr/developers/custom_checks/ +[2]: https://docs.datadoghq.com/fr/getting_started/integrations/ +[3]: https://docs.datadoghq.com/fr/integrations/ +[4]: https://docs.datadoghq.com/fr/containers/kubernetes/integrations/?tab=annotations \ No newline at end of file diff --git a/content/fr/containers/datadog_operator/data_collected.md b/content/fr/containers/datadog_operator/data_collected.md new file mode 100644 index 00000000000..f26f486ed8a --- /dev/null +++ b/content/fr/containers/datadog_operator/data_collected.md @@ -0,0 +1,46 @@ +--- +dependencies: +- https://github.com/DataDog/datadog-operator/blob/main/docs/data_collected.md +title: Données collectées par le Datadog Operator +--- +Le Datadog Operator envoie des métriques et des événements à Datadog pour surveiller le déploiement des composants de l'Agent Datadog dans le cluster. + +Pour obtenir une liste de toutes les métriques Kubernetes collectées par Datadog, consultez la section [Données Kubernetes collectées][1]. + +## Métriques + +| Nom de la métrique | Type de la métrique | Rôle | +| -------------------------------------------------------- | ----------- | ----------------------------------------------------------------------------------------------------------------------------------- | +| `datadog.operator.agent.deployment.success` | gauge | `1` si le nombre souhaité de réplicas de l'Agent est égal au nombre de pods de l'Agent disponibles, `0` dans le cas contraire. | +| `datadog.operator.clusteragent.deployment.success` | gauge | `1` si le nombre souhaité de réplicas de l'Agent de cluster est égal au nombre de pods de l'Agent de cluster disponibles, `0` dans le cas contraire. | +| `datadog.operator.clusterchecksrunner.deployment.success` | gauge | `1` si le nombre souhaité de réplicas de Cluster Checks Runner est égal au nombre de pods de Cluster Checks Runner disponibles, `0` dans le cas contraire. | +| `datadog.operator.reconcile.success` | gauge | `1` si la dernière erreur de réconciliation enregistrée est nulle, `0` dans le cas contraire. Le tag `reconcile_err` décrit la dernière erreur enregistrée. | + +**Remarque :** les [clés d'API et d'application Datadog][2] sont nécessaires pour transférer les métriques vers Datadog. Elles doivent être fournies dans le champ `credentials` de la définition de ressource personnalisée. + +## OpenMetrics + +Le Datadog Operator expose les métriques Golang et Controller au format OpenMetrics. Vous pouvez les collecter avec l'[intégration OpenMetrics][3]. + +Le check OpenMetrics est activé par défaut via les annotations Autodiscovery et est planifié par l'Agent s'exécutant sur le même nœud que le pod du Datadog Operator. Consultez la section [Kubernetes et intégrations][4]. + +## Événements + +- Détecter/Supprimer une ressource personnalisée +- Créer/Mettre à jour/Supprimer un Service +- Créer/Mettre à jour/Supprimer une ConfigMap +- Créer/Mettre à jour/Supprimer un DaemonSet +- Créer/Mettre à jour/Supprimer un ExtendedDaemonSet +- Créer/Mettre à jour/Supprimer un Deployment +- Créer/Mettre à jour/Supprimer un ClusterRole +- Créer/Mettre à jour/Supprimer un Role +- Créer/Mettre à jour/Supprimer un ClusterRoleBinding +- Créer/Mettre à jour/Supprimer un RoleBinding +- Créer/Mettre à jour/Supprimer un Secret +- Créer/Mettre à jour/Supprimer un PDB +- Créer/Supprimer un ServiceAccount + +[1]: https://docs.datadoghq.com/fr/containers/kubernetes/data_collected/ +[2]: https://docs.datadoghq.com/fr/account_management/api-app-keys/ +[3]: https://docs.datadoghq.com/fr/integrations/openmetrics/ +[4]: https://docs.datadoghq.com/fr/containers/kubernetes/integrations/?tab=annotations \ No newline at end of file diff --git a/content/fr/containers/datadog_operator/kubectl_plugin.md b/content/fr/containers/datadog_operator/kubectl_plugin.md new file mode 100644 index 00000000000..3c7e7493f57 --- /dev/null +++ b/content/fr/containers/datadog_operator/kubectl_plugin.md @@ -0,0 +1,82 @@ +--- +dependencies: +- https://github.com/DataDog/datadog-operator/blob/main/docs/kubectl-plugin.md +title: Plugin du Datadog Operator pour kubectl +--- +Le Datadog Operator dispose d'un plugin `kubectl`, qui fournit un ensemble d'utilitaires d'assistance offrant une visibilité sur certains composants internes. + +## Installer le plugin + +Exécutez : +```shell +kubectl krew install datadog +``` + +Cette méthode utilise le [gestionnaire de plugins Krew](https://krew.sigs.k8s.io/). + +```console +$ kubectl krew install datadog +Installing plugin: datadog +Installed plugin: datadog +\ + | Use this plugin: + | kubectl datadog + | Documentation: + | https://github.com/DataDog/datadog-operator +/ +``` + +## Commandes disponibles + +```console +$ kubectl datadog --help +Usage: + datadog [command] + +Available Commands: + agent + clusteragent + flare Collect a Datadog's Operator flare and send it to Datadog + get Get DatadogAgent deployment(s) + help Help about any command + validate + +``` + +### Sous-commandes de l'Agent + +```console +$ kubectl datadog agent --help +Usage: + datadog agent [command] + +Available Commands: + check Find check errors + find Find datadog agent pod monitoring a given pod + upgrade Upgrade the Datadog Agent version + +``` + +### Sous-commandes de l'Agent de cluster + +```console +$ kubectl datadog clusteragent --help +Usage: + datadog clusteragent [command] + +Available Commands: + leader Get Datadog Cluster Agent leader + upgrade Upgrade the Datadog Cluster Agent version +``` + +### Sous-commandes de validation + +```console +$ kubectl datadog validate ad --help +Usage: + datadog validate ad [command] + +Available Commands: + pod Validate the autodiscovery annotations for a pod + service Validate the autodiscovery annotations for a service +``` \ No newline at end of file diff --git a/content/fr/containers/datadog_operator/secret_management.md b/content/fr/containers/datadog_operator/secret_management.md new file mode 100644 index 00000000000..6bffdb3668e --- /dev/null +++ b/content/fr/containers/datadog_operator/secret_management.md @@ -0,0 +1,251 @@ +--- +dependencies: +- 'https://github.com/DataDog/datadog-operator/blob/main/docs/secret_management.md ' +title: Gestion des secrets +--- +Pour une sécurité renforcée, le Datadog Operator peut récupérer les informations d'identification Datadog (clé d'API et clé d'application) à l'aide de [Secrets][4]. + +## Configurer les Secrets + +Choisissez l'une des méthodes suivantes pour configurer les Secrets : + +### Configurer des informations d'identification en clair dans la ressource DatadogAgent + +**Cette méthode est recommandée uniquement à des fins de test.** + +Ajoutez vos clés d'API et d'application à la spécification `DatadogAgent` : + +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + global: + credentials: + apiKey: + appKey: + # ... +``` + +Les informations d'identification fournies ici sont stockées dans un Secret créé par l'opérateur. En définissant correctement le RBAC sur le CRD `DatadogAgent`, vous pouvez limiter qui peut voir ces informations d'identification. + +### Utiliser des références de Secret + +1. Créez vos Secrets : + + ```yaml + apiVersion: v1 + kind: Secret + metadata: + name: datadog-api-secret + data: + api_key: + + --- + apiVersion: v1 + kind: Secret + metadata: + name: datadog-app-secret + data: + app_key: + ``` + +2. Indiquez les noms de ces Secrets dans votre ressource `DatadogAgent` : + + ```yaml + apiVersion: datadoghq.com/v2alpha1 + kind: DatadogAgent + metadata: + name: datadog + spec: + global: + credentials: + apiSecret: + secretName: datadog-api-secret + keyName: api-key + appSecret: + secretName: datadog-app-secret + keyName: app-key + # ... + ``` + + + +**Remarque** : vous pouvez également utiliser le même Secret pour stocker les deux informations d'identification : + +```yaml +--- +apiVersion: v1 +kind: Secret +metadata: + name: datadog-secret +data: + api_key: + app_key: +``` + +Ensuite, dans votre ressource `DatadogAgent` : + +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + global: + credentials: + apiSecret: + secretName: datadog-secret + keyName: api-key + appSecret: + secretName: datadog-secret + keyName: app-key + # ... +``` +## Utiliser le secret backend + +Le Datadog Operator est compatible avec le [secret backend][1]. + +### Déployer le Datadog Operator avec le secret backend + +1. Créer une image de conteneur du Datadog Operator qui contient la commande du secret backend. + + Si vous souhaitez créer la vôtre, l'exemple de Dockerfile suivant prend l'image `latest` comme image de base et copie le fichier de script `my-secret-backend.sh` : + + ```Dockerfile + FROM gcr.io/datadoghq/operator:latest + COPY ./my-secret-backend.sh /my-secret-backend.sh + RUN chmod 755 /my-secret-backend.sh + ``` + + Exécutez ensuite : + + ```shell + docker build -t datadog-operator-with-secret-backend:latest . + ``` + +2. Installer ou mettre à jour le déploiement du Datadog Operator avec le paramètre `.Values.secretBackend.command` défini sur le chemin de la commande du secret backend (à l'intérieur du conteneur). Si vous utilisez une image personnalisée, mettez à jour l'image. + + ```shell + $ helm [install|upgrade] dd-operator --set "secretBackend.command=/my-secret-backend.sh" --set "image.repository=datadog-operator-with-secret-backend" ./chart/datadog-operator + ``` + +### Utiliser l'assistant de secret + +**Remarque** : nécessite le Datadog Operator v0.5.0+. + +Kubernetes prend en charge l'exposition de Secrets sous forme de fichiers à l'intérieur d'un pod. Datadog fournit un script d'assistance dans l'image du Datadog Operator pour lire les Secrets à partir de fichiers. + +1. Monter le Secret dans le conteneur de l'opérateur. Par exemple, vous pouvez le monter sur `/etc/secret-volume`. + +2. Installer ou mettre à jour le déploiement du Datadog Operator avec le paramètre `.Values.secretBackend.command` défini sur `/readsecret.sh` et le paramètre `.Values.secretBackend.arguments` défini sur `/etc/secret-volume` : + + ```shell + helm [install|upgrade] dd-operator --set "secretBackend.command=/readsecret.sh" --set "secretBackend.arguments=/etc/secret-volume" ./chart/datadog-operator + ``` + +### Déployer les composants de l'Agent en utilisant la fonctionnalité de secret backend avec l'Agent Datadog + +**Remarque** : nécessite le Datadog Operator v1.11+. + +#### Avec un script personnalisé + +Si vous utilisez un script personnalisé, créez une image de l'Agent Datadog (ou de l'Agent de cluster) et spécifiez les informations d'identification à l'aide de `ENC[]`, puis spécifiez la commande du secret backend dans `spec.global.secretBackend.command` : + + ```yaml + apiVersion: datadoghq.com/v2alpha1 + kind: DatadogAgent + metadata: + name: datadog + spec: + global: + credentials: + apiKey: ENC[] + appKey: ENC[] + secretBackend: + command: "/my-secret-backend.sh" + # ... + ``` + +La variable d'environnement `DD_SECRET_BACKEND_COMMAND` issue de cette configuration est automatiquement appliquée à tous les composants déployés : Agent de nœud, Agent de cluster et Cluster Checks Runners. Assurez-vous que l'image que vous utilisez pour tous les composants inclut votre commande. + +#### Avec la fonction d'assistance + +Pour plus de commodité, l'Agent Datadog et son Agent de cluster associé incluent une [fonction d'assistance][2] `readsecret_multiple_providers.sh` qui peut être utilisée pour lire à la fois les fichiers et les Secrets Kubernetes. Après avoir créé le Secret, définissez `spec.global.secretBackend.command` sur `"/readsecret_multiple_providers.sh"`. + +Par exemple, pour utiliser le secret backend pour l'Agent et l'Agent de cluster, créez un Secret appelé "test-secret" : + +`kubectl create secret generic test-secret --from-literal=api_key='' --from-literal=app_key=''` + +Ensuite, définissez la spécification DatadogAgent : + +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + global: + secretBackend: + command: "/readsecret_multiple_providers.sh" + credentials: + apiKey: ENC[k8s_secret@default/test-secret/api_key] + appKey: ENC[k8s_secret@default/test-secret/app_key] +``` + +## Remarques supplémentaires + +### Autorisations de ServiceAccount + +L'assistant `"/readsecret_multiple_providers.sh"` permet à l'Agent de lire directement les Secrets Kubernetes dans son propre espace de nommage et dans d'autres. Assurez-vous que le ServiceAccount associé dispose des autorisations nécessaires en attribuant les Roles et RoleBindings appropriés. Vous pouvez les définir manuellement ou en utilisant les options suivantes : + +- `global.secretBackend.enableGlobalPermissions` : détermine si un ClusterRole est créé pour permettre aux Agents de lire **tous** les Secrets Kubernetes. + + ```yaml + apiVersion: datadoghq.com/v2alpha1 + kind: DatadogAgent + metadata: + name: datadog + spec: + global: + secretBackend: + command: "/readsecret_multiple_providers.sh" + enableGlobalPermissions: true + # ... + ``` + +- `global.secretBackend.roles` : remplace `enableGlobalPermissions`, détaillant la liste des espaces de nommage/secrets auxquels les Agents doivent avoir accès. + + ```yaml + apiVersion: datadoghq.com/v2alpha1 + kind: DatadogAgent + metadata: + name: datadog + spec: + global: + secretBackend: + command: "/readsecret_multiple_providers.sh" + roles: + - namespace: rabbitmq-system + secrets: + - "rabbitmqcluster-sample-default-user" + # ... + ``` + + Dans cet exemple, un Role est créé accordant un accès en lecture au Secret `rabbitmqcluster-sample-default-user` dans l'espace de nommage `rabbitmq-system`. + + **Remarque** : chaque espace de nommage de la liste `roles` doit également être configuré dans la variable d'environnement `WATCH_NAMESPACE` ou `DD_AGENT_WATCH_NAMESPACE` sur le déploiement du Datadog Operator. + +### Options de configuration du secret backend + +Pour l'Agent et l'Agent de cluster, il existe d'autres options de configuration pour la commande du secret backend : + * `global.secretBackend.args` : ces arguments sont fournis à la commande lorsque l'Agent exécute la commande du secret backend. + * `global.secretBackend.timeout` : délai d'expiration de l'exécution du secret backend en secondes. La valeur par défaut est de 30 secondes. + +Pour les versions antérieures à l'opérateur 1.11, `spec.global.secretBackend` n'est pas disponible. Vous devez suivre [ces instructions][3] à la place. + +[1]: https://docs.datadoghq.com/fr/agent/guide/secrets-management +[2]: https://docs.datadoghq.com/fr/agent/guide/secrets-management/?tab=linux#script-for-reading-from-multiple-secret-providers +[3]: https://github.com/DataDog/datadog-operator/blob/2bbda7adace27de3d397b3d76d87fbd49fa304e3/docs/secret_management.md#how-to-deploy-the-agent-components-using-the-secret-backend-feature-with-datadogagent +[4]: https://kubernetes.io/docs/concepts/configuration/secret/ \ No newline at end of file diff --git a/content/fr/containers/docker/data_collected.md b/content/fr/containers/docker/data_collected.md index 2bb7575ea7f..1f71d1b0299 100644 --- a/content/fr/containers/docker/data_collected.md +++ b/content/fr/containers/docker/data_collected.md @@ -1,6 +1,8 @@ --- aliases: - /fr/agent/docker/data_collected +description: Guide de référence pour les métriques et les événements collectés par + l'Agent Datadog à partir des conteneurs de Docker title: Données Docker recueillies --- @@ -27,6 +29,8 @@ L'Agent Docker génère les événements suivants : - Restart Daemon - Mettre à jour +Pour collecter d'autres événements de Docker, adressez-vous à [l'assistance Datadog][2]. + ### Checks de service {{< get-service-checks-from-git "docker" >}} @@ -53,3 +57,4 @@ Le check Containerd peut recueillir des événements. Utilisez `filters` pour s {{< get-service-checks-from-git "containerd" >}} [1]: https://github.com/DataDog/datadog-agent/blob/master/cmd/agent/dist/conf.d/containerd.d/conf.yaml.default +[2]: https://www.datadoghq.com/support/ \ No newline at end of file diff --git a/content/fr/containers/docker/integrations.md b/content/fr/containers/docker/integrations.md index e0736fa073f..8a40cc338ad 100644 --- a/content/fr/containers/docker/integrations.md +++ b/content/fr/containers/docker/integrations.md @@ -1,6 +1,8 @@ --- aliases: - /fr/agent/docker/integrations +description: Configurer des intégrations de surveillance pour les applications s'exécutant + dans des conteneurs Docker à l'aide d'Autodiscovery further_reading: - link: /agent/docker/log/ tag: Documentation @@ -17,73 +19,99 @@ further_reading: - link: /agent/docker/tag/ tag: Documentation text: Attribuer des tags à toutes les données envoyées par un conteneur -title: Intégrations Autodiscovery avec Docker +title: Docker et intégrations --- +Cette page explique comment installer et configurer des intégrations pour votre infrastructure Docker en utilisant une fonctionnalité Datadog appelée _Autodiscovery_. Autodiscovery vous permet d'utiliser des [variables][1] comme `%%host%%` pour renseigner dynamiquement vos paramètres de configuration. + +Pour obtenir une explication détaillée du fonctionnement d'Autodiscovery, consultez la section [Débuter avec les conteneurs : Autodiscovery][2]. Pour les options avancées d'Autodiscovery, telles que l'exclusion de certains conteneurs d'Autodiscovery ou la tolérance des pods non prêts, consultez la section [Gestion de la découverte de conteneurs][3]. + +Si vous utilisez Kubernetes, consultez la section [Kubernetes et intégrations][4]. +
-Consultez la documentation Débuter avec Autodiscovery pour découvrir les concepts sous-jacents de cette fonctionnalité. +Les intégrations Datadog suivantes ne fonctionnent pas avec Autodiscovery car elles nécessitent soit des données d'arborescence de processus, soit un accès au système de fichiers : Ceph, Varnish, Postfix, Cassandra Nodetool et Gunicorn.

+Pour surveiller les intégrations qui ne sont pas compatibles avec Autodiscovery, vous pouvez utiliser un exportateur Prometheus dans le pod pour exposer un endpoint HTTP, puis utiliser l'intégration OpenMetrics (qui prend en charge Autodiscovery) pour trouver le pod et interroger l'endpoint.
-Cette page traite de la configuration des intégrations Autodiscovery avec Docker. Si vous utilisez Kubernetes, consultez la [documentation relative aux intégrations Autodiscovery avec Kubernetes][1]. +## Configurer votre intégration + +Certaines intégrations nécessitent des étapes de configuration, telles que la création d'un token d'accès ou l'octroi d'une autorisation de lecture à l'Agent Datadog. Suivez les instructions de la section **Configuration** de la documentation de votre intégration. -Autodiscovery vous permet d'appliquer une configuration d'intégration Datadog lors de l'exécution d'un check de l'Agent sur un conteneur donné. Pour obtenir davantage de contexte sur cette logique, découvrez comment [configurer les intégrations de l'Agent][2] lorsque l'Agent est exécuté sur un host. +### Intégrations de la communauté +Pour utiliser une intégration qui n'est pas fournie avec l'Agent Datadog, vous devez créer une image personnalisée contenant l'intégration souhaitée. Consultez la section [Utiliser des intégrations de la communauté][5] pour obtenir des instructions. -Utilisez les paramètres suivants afin de configurer une intégration avec Autodiscovery : +## Configuration -| Paramètre | Obligatoire | Description | -|----------------------|----------|---------------------------------------------------------------------------------------------------| -| `` | Oui | Le nom de l'intégration Datadog. | -| `` | Oui | La configuration de la section `init_config:` pour l'intégration Datadog-`` donnée. | -| `` | Oui | La configuration de la section `instances:` pour l'intégration Datadog-`` donnée. | +Certaines intégrations couramment utilisées sont fournies avec une configuration par défaut pour Autodiscovery. Consultez la section [Configuration automatique d'Autodiscovery][6] pour obtenir des détails, notamment une liste des intégrations configurées automatiquement et leurs fichiers de configuration par défaut correspondants. Si votre intégration figure dans cette liste et que la configuration par défaut est suffisante pour votre cas d'utilisation, aucune action supplémentaire n'est requise. -**Remarque** : `` n'est pas nécessaire pour Autodiscovery v2, introduit avec la version 7.36 de lʼAgent Datadog. +Sinon : -Chaque onglet des sections ci-dessous présente une façon différente d'appliquer des modèles d'intégration à un conteneur donné. Vous pouvez utiliser les éléments suivants : +1. Choisissez une méthode de configuration (labels Docker, un fichier local ou un key-value store) adaptée à votre cas d'utilisation. +2. Référencez le format de modèle pour la méthode choisie. Chaque format contient des espaces réservés, tels que ``. +3. [Fournissez des valeurs](#valeurs-des-espaces-reserves) pour ces espaces réservés. -* [Étiquettes Docker](?tab=docker#configuration) -* [Un fichier de configuration monté dans l'Agent](?tab=fichier#configuration) -* [Stockages clé-valeur](?tab=stockagecle-valeur#configuration) +{{< tabs >}} +{{% tab "Labels" %}} -**Remarque** : certaines intégrations prises en charge ne fonctionnent pas avec Autodiscovery par défaut, car elles nécessitent un accès à l'arborescence des processus ou au système de fichiers : c'est le cas de [Ceph][4], [Varnish][5], [Postfix][6], [Cassandra Nodetools][7] et [Gunicorn][8]. Pour activer Autodiscovery pour ces intégrations, utilisez l'exportateur Prometheus officiel dans le conteneur, puis faites appel à Autodiscovery dans l'Agent pour identifier le conteneur et interroger l'endpoint. +#### Dockerfile -## Configuration +Pour l'Agent Datadog 7.36+ : -{{< tabs >}} -{{% tab "Docker (AD v2)" %}} +```yaml +LABEL "com.datadoghq.ad.checks"='{"": {"instances": [], "logs": []}}' +``` -**Remarque** : les annotations AD v2 ont été ajoutées dans l'Agent Datadog 7.36 afin de simplifier la configuration de l'intégration. Pour les versions précédentes de l'Agent Datadog, utilisez les annotations AD v1. +Pour les versions antérieures de l'Agent : -Pour activer automatiquement Autodiscovery sur des conteneurs Docker, montez `/var/run/docker.sock` dans l'Agent conteneurisé. Sous Windows, montez `\\.\pipe\docker_engine`. +```yaml +LABEL "com.datadoghq.ad.check_names"='[]' +LABEL "com.datadoghq.ad.init_configs"='[]' +LABEL "com.datadoghq.ad.instances"='[]' +LABEL "com.datadoghq.ad.logs"='[]' +``` -Il est possible de stocker vos modèles d'intégration en tant qu'étiquettes Docker. Grâce à Autodiscovery, l'Agent détecte s'il est exécuté sur Docker et examine automatiquement toutes les étiquettes à la recherche de modèles d'intégration. Autodiscovery s'attend à ce que les étiquettes ressemblent à ces exemples : +#### docker-compose.yaml -**Dockerfile** : +Pour l'Agent Datadog 7.36+ : ```yaml -LABEL "com.datadoghq.ad.checks"='{"": {"instances": []}}' +labels : + com.datadoghq.ad.checks : '{"" : {"instances" : [], "logs" : []}}' ``` -**docker-compose.yaml** : +Pour les versions antérieures de l'Agent : ```yaml labels: - com.datadoghq.ad.checks: '{"": {"instances": []}}' + com.datadoghq.ad.check_names: '[]' + com.datadoghq.ad.init_configs: '[]' + com.datadoghq.ad.instances: '[]' + com.datadoghq.ad.logs: '[]' ``` -**Avec les commandes `docker run`, `nerdctl run` ou `podman run`** : +#### Utiliser docker run, nerdctl run ou podman run + +Pour l'Agent Datadog 7.36+ : ```shell --l com.datadoghq.ad.checks="{\"\": {\"instances\": []}}" +docker run -l com.datadoghq.ad.checks="{\"\": {\"instances\": [], \"logs\": []}}" +``` + +Pour les versions antérieures de l'Agent : + +```shell +docker run -l com.datadoghq.ad.check_names='[]' -l com.datadoghq.ad.init_configs='[]' -l com.datadoghq.ad.instances='[]' -l com.datadoghq.ad.logs='[]' ``` **Remarque** : vous pouvez échapper le fichier JSON lors de la configuration de ces étiquettes. Par exemple : ```shell -docker run --label "com.datadoghq.ad.checks="{\"apache\": {\"instances\": [{\"apache_status_url\":\"http://%%host%%/server-status?auto2\"}]}}" +docker run -l "com.datadoghq.ad.checks="{\"apache\": {\"instances\": [{\"apache_status_url\":\"http://%%host%%/server-status?auto2\"}]}}" ``` -**Docker Swarm** : +#### Docker Swarm +Lors de l'utilisation du mode Swarm pour Docker Cloud, les labels doivent être appliqués à l'image. -Pour utiliser le mode Swarm avec Docker Cloud, les étiquettes doivent être appliquées à l'image : +Pour l'Agent Datadog 7.36+ : ```yaml version: "1.0" @@ -92,122 +120,83 @@ services: project: image: '' labels: - com.datadoghq.ad.checks: '{"": {"instances": []}}' - -``` - -**Remarque** : lors de la configuration d'Autodiscovery, Datadog recommande l'utilisation des étiquettes Docker afin d'unifier la télémétrie au sein de votre environnement conteneurisé. Consultez la documentation relative au [tagging de service unifié][1] pour en savoir plus. - - -[1]: /fr/getting_started/tagging/unified_service_tagging/?tab=docker -{{% /tab %}} -{{% tab "Docker (AD v1)" %}} - -Pour activer automatiquement Autodiscovery sur des conteneurs Docker, montez `/var/run/docker.sock` dans l'Agent conteneurisé. Sous Windows, montez `\\.\pipe\docker_engine`. - -Il est possible de stocker vos modèles d'intégration en tant qu'étiquettes Docker. Grâce à Autodiscovery, l'Agent détecte s'il est exécuté sur Docker et examine automatiquement toutes les étiquettes à la recherche de modèles d'intégration. Autodiscovery s'attend à ce que les étiquettes ressemblent à ces exemples : - -**Dockerfile** : - -```yaml -LABEL "com.datadoghq.ad.check_names"='[]' -LABEL "com.datadoghq.ad.init_configs"='[]' -LABEL "com.datadoghq.ad.instances"='[]' -``` - -**docker-compose.yaml** : - -```yaml -labels: - com.datadoghq.ad.check_names: '[]' - com.datadoghq.ad.init_configs: '[]' - com.datadoghq.ad.instances: '[]' -``` - -**Avec les commandes `docker run`, `nerdctl run` ou `podman run`** : + com.datadoghq.ad.checks: '{"": {"instances": [], "logs": []}}' -```shell --l com.datadoghq.ad.check_names='[]' -l com.datadoghq.ad.init_configs='[]' -l com.datadoghq.ad.instances='[]' -``` - -**Remarque** : vous pouvez échapper le fichier JSON lors de la configuration de ces étiquettes. Par exemple : -```shell -docker run --label "com.datadoghq.ad.check_names=[\"redisdb\"]" --label "com.datadoghq.ad.init_configs=[{}]" --label "com.datadoghq.ad.instances=[{\"host\":\"%%host%%\",\"port\":6379}]" --label "com.datadoghq.ad.logs=[{\"source\":\"redis\"}]" --name redis redis ``` -**Docker Swarm** : - -Pour utiliser le mode Swarm avec Docker Cloud, les étiquettes doivent être appliquées à l'image : +Pour les versions antérieures de l'Agent : ```yaml version: "1.0" services: ... project: - image: '' + image: '' labels: - com.datadoghq.ad.check_names: '[]' - com.datadoghq.ad.init_configs: '[]' - com.datadoghq.ad.instances: '[]' + com.datadoghq.ad.check_names: '[]' + com.datadoghq.ad.init_configs: '[]' + com.datadoghq.ad.instances: '[]' + com.datadoghq.ad.logs: '[]' ``` -**Remarque** : lors de la configuration d'Autodiscovery, Datadog recommande l'utilisation des étiquettes Docker afin d'unifier la télémétrie au sein de votre environnement conteneurisé. Consultez la documentation relative au [tagging de service unifié][1] pour en savoir plus. - - -[1]: /fr/getting_started/tagging/unified_service_tagging/?tab=docker {{% /tab %}} -{{% tab "Fichier" %}} +{{% tab "Fichier local" %}} -Vous pouvez stocker des modèles en tant que fichiers locaux et les monter dans l'Agent conteneurisé. Cela ne nécessite aucun service externe ni aucune plateforme d'orchestration spécifique. Vous devrez cependant redémarrer les conteneurs de votre Agent à chaque fois qu'un modèle est modifié, ajouté ou supprimé. L'Agent recherche les modèles Autodiscovery dans le répertoire `/conf.d` monté. +Vous pouvez stocker les modèles Autodiscovery sous forme de fichiers locaux dans le répertoire monté `/conf.d`. Vous devez redémarrer vos conteneurs d'Agent chaque fois que vous modifiez, ajoutez ou supprimez des modèles. -À partir de la version 6.2.0 (et 5.24.0) de l'Agent, les modèles par défaut utilisent le port par défaut pour le logiciel surveillé au lieu de le détecter automatiquement. Si vous devez utiliser un port différent, spécifiez un modèle Autodiscovery personnalisé dans les [étiquettes de conteneur Docker](?tab=etiquettes-docker) +1. Créez un fichier `conf.d/.d/conf.yaml` sur votre host : + ```yaml + ad_identifiers: + - -Ces modèles d'intégration peuvent convenir dans les cas simples. Toutefois, si vous avez besoin de personnaliser les configurations de votre intégration Datadog (par exemple pour activer des options supplémentaires, pour faire appel à des identificateurs de conteneur différents ou pour utiliser les index de template variables), vous devez écrire vos propres fichiers de configuration automatique : - -1. Créez un fichier `conf.d/.d/conf.yaml` sur votre host et ajoutez votre configuration automatique personnalisée. -2. Montez le répertoire `conf.d/` de votre host dans le répertoire `conf.d/` de l'Agent conteneurisé. + init_config: + -**Exemple de fichier de configuration automatique** : + instances: + -```text -ad_identifiers: - + logs: + + ``` -init_config: - - -instances: - -``` +2. Montez le répertoire `conf.d/` de votre host dans le répertoire `conf.d/` de l'Agent conteneurisé. -Consultez la documentation sur [les identificateurs de conteneur Autodiscovery][1] pour obtenir des informations sur ``. + **docker-compose.yaml** + ```yaml + volumes: + [...] + - /conf.d:/conf.d + ``` -**Remarque** : vous n'avez pas à configurer `` ici, car l'Agent le récupère directement à partir du nom du fichier. + **docker run** + ```shell + docker run -d --name datadog-agent \ + [...] + -v /conf.d:/conf.d \ + ``` -[1]: /fr/agent/guide/ad_identifiers/ {{% /tab %}} -{{% tab "Stockage clé-valeur" %}} - -Autodiscovery peut utiliser [Consul][1], Etcd et Zookeeper comme sources de modèle d'intégration. Pour utiliser un stockage clé-valeur, vous devez le configurer dans le fichier de configuration `datadog.yaml` de l'Agent et monter ce fichier dans l'agent conteneurisé. Vous pouvez également transmettre votre stockage clé-valeur comme variables d'environnement à l'Agent conteneurisé. +{{% tab "Key-value store" %}} +Vous pouvez récupérer les modèles Autodiscovery à partir de [Consul][1], [etcd][2] ou [ZooKeeper][3]. Vous pouvez configurer votre key-value store dans le fichier de configuration `datadog.yaml` (et monter ensuite ce fichier dans le conteneur de l'Agent), ou en tant que variables d'environnement dans le conteneur de l'Agent. **Configuration dans datadog.yaml** : -Dans le fichier `datadog.yaml`, définissez l'adresse `` et le `` de votre stockage clé-valeur : +Dans `datadog.yaml`, définissez l'adresse `` et le `` de votre key-value store : ```yaml config_providers: - name: etcd polling: true template_dir: /datadog/check_configs - template_url: ':' + template_url: ':' username: password: - name: consul polling: true template_dir: datadog/check_configs - template_url: ':' + template_url: ':' ca_file: ca_path: cert_file: @@ -219,12 +208,12 @@ Dans le fichier `datadog.yaml`, définissez l'adresse ` - name: zookeeper polling: true template_dir: /datadog/check_configs - template_url: ':' + template_url: ':' username: password: ``` -[Redémarrez ensuite l'Agent][2] pour prendre en compte le changement de configuration. +[Redémarrez l'Agent Datadog][4] pour appliquer vos modifications. **Configuration dans les variables d'environnement** : @@ -233,183 +222,120 @@ Lorsque le stockage clé-valeur est activé en tant que source de modèle, l'Age ```yaml /datadog/ check_configs/ - / - - check_names: [""] - - init_configs: [""] - - instances: [""] + / + - check_names: [""] + - init_configs: [""] + - instances: [""] + - logs: [""] ... ``` -**Remarque** : pour appliquer une configuration spécifique à un conteneur donné, Autodiscovery identifie les conteneurs par **image** en cas d'utilisation de stockages clé-valeur. En d'autres termes, il cherche à faire correspondre `` à `.spec.containers[0].image`. - [1]: /fr/integrations/consul/ -[2]: /fr/agent/configuration/agent-commands/ +[2]: /fr/integrations/etcd/ +[3]: /fr/integrations/zk/ +[4]: /fr/agent/configuration/agent-commands/ + {{% /tab %}} {{< /tabs >}} -## Exemples +### Valeurs des espaces réservés -### Intégration Datadog/Redis +Fournir les valeurs des espaces réservés comme suit : -{{< tabs >}} -{{% tab "Docker" %}} +`` +: Nom de votre intégration Datadog, tel que `etcd` ou `redisdb`. -Le fichier `docker-compose.yml` suivant applique le modèle d'intégration Redis adéquat avec un paramètre `password` personnalisé : - -```yaml -labels: - com.datadoghq.ad.check_names: '["redisdb"]' - com.datadoghq.ad.init_configs: '[{}]' - com.datadoghq.ad.instances: '[{"host": "%%host%%","port":"6379","password":"%%env_REDIS_PASSWORD%%"}]' -``` +`` +: Identifiant à mettre en correspondance avec l'image de conteneur.

+Par exemple : si vous fournissez `redis` comme identifiant de conteneur, votre modèle Autodiscovery est appliqué à tous les conteneurs dont les noms d'image correspondent à `redis`. Si vous avez un conteneur exécutant `foo/redis:latest` et `bar/redis:v2`, votre modèle Autodiscovery est appliqué aux deux conteneurs.

+Le paramètre `ad_identifiers` prend une liste, vous pouvez donc fournir plusieurs identifiants de conteneur. Vous pouvez également utiliser des identifiants personnalisés. Consultez la section [Identifiants Autodiscovery personnalisés][7]. -{{% /tab %}} -{{% tab "Fichier" %}} +`` +: Paramètres de configuration répertoriés sous `init_config` dans le fichier `.d/conf.yaml.example` de votre intégration. La section `init_config` est généralement vide. -Redis est l'un des modèles Autodiscovery par défaut inclus avec l'Agent : il n'est donc pas nécessaire de monter ce fichier. Le modèle Redis suivant est inclus avec l'Agent : +`` +: Paramètres de configuration répertoriés sous `instances` dans le fichier `.d/conf.yaml.example` de votre intégration. -```yaml -ad_identifier: - - redis +`` +: Paramètres de configuration répertoriés sous `logs` dans le fichier `.d/conf.yaml.example` de votre intégration. -init_config: +## Exemples -instances: +### Intégration Redis - - host: "%%host%%" - port: "6379" -``` +Redis est l'une des technologies pour lesquelles la [configuration automatique d'Autodiscovery][6] est disponible. Les exemples suivants montrent comment remplacer cette configuration de base par une configuration personnalisée qui fournit un paramètre `password`. -Cette [configuration d'intégration Redis][1] peut sembler succincte, mais notez l'option `ad_identifier`. Cette option obligatoire vous permet de spécifier les identificateurs de conteneur. Autodiscovery applique ce modèle à tous les conteneurs sur le host qui exécute une image `redis`. Consultez la documentation relative aux [identificateurs Autodiscovery][2] pour en savoir plus. +Stockez votre mot de passe en tant que variable d'environnement nommée `REDIS_PASSWORD`, puis : -Si votre Redis requiert un `password` supplémentaire pour accéder à son endpoint stats : +{{< tabs >}} +{{% tab "Docker" %}} -1. Créez les dossiers `conf.d/` et `conf.d/redisdb.d` sur votre host. -2. Ajoutez le fichier de configuration automatique personnalisé ci-dessous à `conf.d/redisdb.d/conf.yaml` sur votre host. -3. Montez le répertoire `conf.d/` du host dans le répertoire `conf.d/` de l'Agent conteneurisé. +Pour l'Agent Datadog 7.36+ : ```yaml -ad_identifiers: - - redis - -init_config: - -instances: - - - host: "%%host%%" - port: "6379" - password: "%%env_REDIS_PASSWORD%%" -``` - -**Remarque** : la logique de template variable `"%%env_%%"` est utilisée afin d'éviter de stocker le mot de passe en clair. La variable d'environnement `REDIS_PASSWORD` doit donc être transmise à l'Agent. Consultez la [documentation relative aux template variables Autodiscovery][3]. - -[1]: https://github.com/DataDog/integrations-core/blob/master/redisdb/datadog_checks/redisdb/data/auto_conf.yaml -[2]: /fr/agent/guide/ad_identifiers/ -[3]: /fr/agent/faq/template_variables/ -{{% /tab %}} -{{% tab "Stockage clé-valeur" %}} - -Les commandes etcd suivantes permettent de créer un modèle d'intégration Redis avec un paramètre `password` personnalisé : - -```conf -etcdctl mkdir /datadog/check_configs/redis -etcdctl set /datadog/check_configs/redis/check_names '["redisdb"]' -etcdctl set /datadog/check_configs/redis/init_configs '[{}]' -etcdctl set /datadog/check_configs/redis/instances '[{"host": "%%host%%","port":"6379","password":"%%env_REDIS_PASSWORD%%"}]' +labels: + com.datadoghq.ad.checks: '{"redisdb": {"instances": [{"host": "%%host%%","port":"6379","password":"%%env_REDIS_PASSWORD%%"}], "logs": [{"type": "file", "path": "/var/log/redis_6379.log", "source": "redis", "service": "redis_service"}]}}' ``` -Notez que chacune des trois valeurs est une liste. Autodiscovery assemble les éléments de liste en fonction des index de liste partagée de manière à générer la configuration de l'intégration. Dans le cas présent, il assemble la première (et unique) configuration de check à partir de `check_names[0]`, `init_configs[0]` et `instances[0]`. - -**Remarque** : la logique de template variable `"%%env_%%"` est utilisée afin d'éviter de stocker le mot de passe en clair. La variable d'environnement `REDIS_PASSWORD` doit donc être transmise à l'Agent. Consultez la [documentation relative aux template variables Autodiscovery][1]. - -Contrairement aux fichiers de configuration automatique, **les stockages clé-valeur peuvent utiliser la version courte OU la version longue du nom d'image comme identificateur de conteneur**, par exemple : `redis` OU `redis:latest`. - -[1]: /fr/agent/faq/template_variables/ -{{% /tab %}} -{{< /tabs >}} - -### Intégrations Datadog/Apache et Datadog/Check HTTP - -Les configurations ci-dessous s'appliquent à une image de conteneur Apache avec ``: `httpd`. Les modèles Autodiscovery sont configurés pour recueillir des métriques provenant du conteneur Apache, et pour configurer un check HTTP/Datadog avec des instances afin de tester deux endpoints. - -Les noms de check sont `apache`, `http_check` et leur `` et ``. Les configurations complètes se trouvent sur les pages de documentation dédiées : [intégration Datadog/Apache][9], [intégration Datadog/check HTTP][10]. - -{{< tabs >}} -{{% tab "Docker" %}} +Pour les versions antérieures de l'Agent : ```yaml labels: - com.datadoghq.ad.check_names: '["apache", "http_check"]' - com.datadoghq.ad.init_configs: '[{},{}]' - com.datadoghq.ad.instances: '[[{"apache_status_url": "http://%%host%%/server-status?auto"}],[{"name":"","url":"http://%%host%%/website_1","timeout":1},{"name":"","url":"http://%%host%%/website_2","timeout":1}]]' + com.datadoghq.ad.check_names: '["redisdb"]' + com.datadoghq.ad.init_configs: '[{}]' + com.datadoghq.ad.instances: '[{"host": "%%host%%","port":"6379","password":"%%env_REDIS_PASSWORD%%"}]' + com.datadoghq.ad.logs: '[{"type": "file", "path": "/var/log/redis_6379.log", "source": "redis", "service": "redis_service"}]' ``` {{% /tab %}} {{% tab "Fichier" %}} +1. Créez un fichier `conf.d/redisdb.d/conf.yaml` sur votre host : + + ```yaml + ad_identifiers: + - redis + init_config: + instances: + - host: "%%host%%" + port: "6379" + username: "datadog" + password: "%%env_REDIS_PASSWORD%%" + logs: + - type: "file" + path: "/var/log/redis.log" + source: "redis" + service: "redis_service" + ``` -* Créez les dossiers `conf.d/` et `conf.d/apache.d` sur votre host. -* Ajoutez le fichier de configuration automatique personnalisé ci-dessous à `conf.d/apache.d/conf.yaml` sur votre host. - -```yaml -ad_identifiers: - - httpd - -init_config: - -instances: - - apache_status_url: http://%%host%%/server-status?auto -``` - -Remarque : cette [configuration de check Apache][1] peut sembler succincte, mais notez l'option `ad_identifier`. Cette option obligatoire vous permet de spécifier les identificateurs de conteneur. Autodiscovery applique ce modèle à tous les conteneurs sur le host qui exécute une image `httpd`. Consultez la documentation relative aux [identifiants Autodiscovery][2] pour en savoir plus. - -* Créez ensuite le dossier `conf.d/http_check.d` sur votre host. -* Ajoutez le fichier de configuration automatique personnalisé ci-dessous à `conf.d/http_check.d/conf.yaml` sur votre host. - -```yaml -ad_identifiers: - - httpd - -init_config: - -instances: - - name: "" - url: "http://%%host%%/website_1" - timeout: 1 - - - name: "" - url: "http://%%host%%/website_2" - timeout: 1 -``` - -* Enfin, montez le répertoire `conf.d/` du host dans le répertoire `conf.d/` de l'Agent conteneurisé. +2. Montez le répertoire `conf.d/` de votre host dans le répertoire `conf.d/` de l'Agent conteneurisé. -[1]: https://github.com/DataDog/integrations-core/blob/master/apache/datadog_checks/apache/data/conf.yaml.example -[2]: /fr/agent/guide/ad_identifiers/ {{% /tab %}} {{% tab "Stockage clé-valeur" %}} +Les commandes etcd suivantes permettent de créer un modèle d'intégration Redis avec un paramètre `password` personnalisé : + ```conf -etcdctl set /datadog/check_configs/httpd/check_names '["apache", "http_check"]' -etcdctl set /datadog/check_configs/httpd/init_configs '[{}, {}]' -etcdctl set /datadog/check_configs/httpd/instances '[[{"apache_status_url": "http://%%host%%/server-status?auto"}],[{"name": "", "url": "http://%%host%%/website_1", timeout: 1},{"name": "", "url": "http://%%host%%/website_2", timeout: 1}]]' +etcdctl mkdir /datadog/check_configs/redis +etcdctl set /datadog/check_configs/redis/check_names '["redisdb"]' +etcdctl set /datadog/check_configs/redis/init_configs '[{}]' +etcdctl set /datadog/check_configs/redis/instances '[{"host": "%%host%%","port":"6379","password":"%%env_REDIS_PASSWORD%%"}]' ``` -**Remarque** : l'ordre de chaque liste est important. Pour que l'Agent soit en mesure de générer la configuration du check HTTP, toutes les parties de sa configuration doivent utiliser le même index sur l'ensemble des trois listes. - +Notez que chacune des trois valeurs est une liste. Autodiscovery assemble les éléments de liste dans les configurations d'intégration en fonction des index de liste partagés. Dans ce cas, il compose la première (et seule) configuration de check à partir de `check_names[0]`, `init_configs[0]` et `instances[0]`. {{% /tab %}} {{< /tabs >}} -## Pour aller plus loin +Tous ces exemples utilisent des [variables de modèle Autodiscovery][1] : +- `%%host%%` récupère dynamiquement l'adresse IP du conteneur. +- `%%env_REDIS_PASSWORD%%` se réfère à la variable d'environnement `REDIS_PASSWORD` détectée par le processus de l'Agent. -{{< partial name="whats-next/whats-next.html" >}} +Pour plus d'exemples, notamment sur la façon de configurer plusieurs checks pour plusieurs ensembles de conteneurs, consultez la section [Autodiscovery : scénarios et exemples][8]. -[1]: /fr/agent/kubernetes/integrations/ -[2]: /fr/getting_started/integrations/#configuring-agent-integrations -[3]: /fr/integrations/#cat-autodiscovery -[4]: /fr/integrations/ceph/ -[5]: /fr/integrations/varnish/#autodiscovery -[6]: /fr/integrations/postfix/ -[7]: /fr/integrations/cassandra/#agent-check-cassandra-nodetool -[8]: /fr/integrations/gunicorn/ -[9]: /fr/integrations/apache/#setup -[10]: /fr/integrations/http_check/#setup \ No newline at end of file +[1]: /fr/containers/guide/template_variables/ +[2]: /fr/getting_started/containers/autodiscovery +[3]: /fr/containers/guide/autodiscovery-management +[4]: /fr/containers/kubernetes/integrations/ +[5]: /fr/agent/guide/use-community-integrations/ +[6]: /fr/containers/guide/auto_conf +[7]: /fr/containers/guide/ad_identifiers +[8]: /fr/containers/guide/autodiscovery-examples \ No newline at end of file diff --git a/content/fr/containers/guide/_index.md b/content/fr/containers/guide/_index.md new file mode 100644 index 00000000000..23add1fe8bc --- /dev/null +++ b/content/fr/containers/guide/_index.md @@ -0,0 +1,48 @@ +--- +description: Liste de guides pour la configuration et le paramétrage de la surveillance + des conteneurs +disable_toc: true +private: true +title: Guides sur les conteneurs +--- + +{{< whatsnext desc="Guides généraux sur les conteneurs :" >}} + {{< nextlink href="/containers/guide/kubernetes_daemonset" >}}Installer et configurer manuellement l'Agent Datadog sur Kubernetes avec DaemonSet{{< /nextlink >}} + {{< nextlink href="/containers/guide/build-container-agent" >}}Créer une image de l'Agent Datadog{{< /nextlink >}} + {{< nextlink href="/containers/guide/autodiscovery-management" >}}Gestion de la découverte de conteneurs{{< /nextlink >}} + {{< nextlink href="/containers/guide/operator-advanced" >}}Configuration avancée du Datadog Operator{{< /nextlink >}} + {{< nextlink href="/containers/guide/container-images-for-docker-environments" >}}Images de conteneur pour les environnements Docker{{< /nextlink >}} + {{< nextlink href="/containers/guide/compose-and-the-datadog-agent" >}}Compose et l'Agent Datadog{{< /nextlink >}} + {{< nextlink href="/containers/guide/docker-deprecation" >}}Abandon de Docker dans Kubernetes{{< /nextlink >}} + {{< nextlink href="/containers/guide/podman-support-with-docker-integration" >}}Utiliser l'intégration Docker avec le runtime de conteneur Podman{{< /nextlink >}} + {{< nextlink href="/containers/guide/readonly-root-filesystem" >}}Exécuter l'Agent Datadog avec un système de fichiers racine en lecture seule{{< /nextlink >}} + {{< nextlink href="/containers/guide/changing_container_registry" >}}Modifier votre registre de conteneurs{{< /nextlink >}} + {{< nextlink href="/containers/guide/sync_container_images" >}}Synchroniser les images Datadog avec un registre privé{{< /nextlink >}} + {{< nextlink href="/containers/guide/how-to-import-datadog-resources-into-terraform/" >}}Importer des ressources Datadog dans Terraform{{< /nextlink >}} + {{< nextlink href="/containers/guide/manage-datadogpodautoscaler-with-terraform/" >}}Gérer DatadogPodAutoscaler avec Terraform{{< /nextlink >}} + {{< nextlink href="/containers/guide/kubernetes-cluster-name-detection/" >}}Détection du nom de cluster Kubernetes{{< /nextlink >}} + {{< nextlink href="/containers/guide/kubernetes-legacy/" >}}Kubernetes Legacy{{< /nextlink >}} +{{< /whatsnext >}} + +{{< whatsnext desc="Guides Autodiscovery :" >}} + {{< nextlink href="/containers/guide/autodiscovery-with-jmx" >}}Autodiscovery avec JMX{{< /nextlink >}} + {{< nextlink href="/containers/guide/ad_identifiers" >}}Identifiants de conteneur : appliquer un modèle de fichier de configuration Autodiscovery à un conteneur spécifique{{< /nextlink >}} + {{< nextlink href="/containers/guide/template_variables" >}}Variables de modèle Autodiscovery : renseigner dynamiquement les paramètres de configuration{{< /nextlink >}} + {{< nextlink href="/containers/guide/auto_conf" >}}Configuration automatique d'Autodiscovery : configuration de base par défaut pour les intégrations courantes{{< /nextlink >}} + {{< nextlink href="/containers/guide/autodiscovery-examples" >}}Exemples détaillés de modèles Autodiscovery{{< /nextlink >}} +{{< /whatsnext >}} + +{{< whatsnext desc="Guides sur l'Agent de cluster :" >}} + {{< nextlink href="/containers/guide/cluster_agent_autoscaling_metrics" >}}Autoscaling avec des métriques custom et externes dans l'Agent de cluster{{< /nextlink >}} + {{< nextlink href="/containers/guide/clustercheckrunners" >}}Cluster Checks Runners{{< /nextlink >}} + {{< nextlink href="/containers/guide/cluster_agent_disable_admission_controller" >}}Désactiver le contrôleur d'admission Datadog avec l'Agent de cluster{{< /nextlink >}} +{{< /whatsnext >}} + +{{< whatsnext desc="Guides sur l'opérateur :" >}} + {{< nextlink href="/containers/guide/datadogoperator_migration" >}}Migration vers la version 1.0 du Datadog Operator{{< /nextlink >}} + {{< nextlink href="/containers/guide/operator-eks-addon" >}}Installer l'Agent Datadog sur Amazon EKS avec le module complémentaire Datadog Operator{{< /nextlink >}} +{{< /whatsnext >}} + +{{< whatsnext desc="Guides AWS :" >}} + {{< nextlink href="/containers/guide/aws-batch-ecs-fargate" >}}AWS Batch avec ECS Fargate et l'Agent Datadog{{< /nextlink >}} +{{< /whatsnext >}} \ No newline at end of file diff --git a/content/fr/containers/guide/ad_identifiers.md b/content/fr/containers/guide/ad_identifiers.md new file mode 100644 index 00000000000..0cd3b6035b4 --- /dev/null +++ b/content/fr/containers/guide/ad_identifiers.md @@ -0,0 +1,206 @@ +--- +aliases: +- /fr/agent/autodiscovery/ad_identifiers +- /fr/agent/guide/ad_identifiers +description: Configurer des modèles Autodiscovery pour cibler des containers spécifiques + à l'aide d'identifiants de conteneurs et de noms d'image +further_reading: +- link: /containers/kubernetes/integrations/ + tag: Documentation + text: Configurer des intégrations avec Autodiscovery sur Kubernetes +- link: /containers/docker/integrations/ + tag: Documentation + text: Configurer des intégrations avec Autodiscovery sur Docker +- link: /agent/guide/autodiscovery-management/ + tag: Documentation + text: Gérer les conteneurs à inclure dans Autodiscovery avec l'Agent +title: Identificateurs de conteneur Autodiscovery +--- + +Ce document explique comment appliquer un modèle de configuration [Autodiscovery][1] à un conteneur spécifique. Le paramètre `ad_identifiers` peut correspondre à un nom d'image de conteneur ou à un identifiant personnalisé. + +## Nom d'image de conteneur + +Pour appliquer le modèle de configuration Autodiscovery suivant à un conteneur donné, remplacez `` par le nom d'image de conteneur [court][2] : + +```yaml +ad_identifiers: + + +init_config: + + +instances: + +``` + +**Exemple** : le modèle de configuration Autodiscovery Apache suivant s'applique à une image de conteneur nommée `httpd` : + +```yaml +ad_identifiers: + - httpd +init_config: +instances: + - apache_status_url: http://%%host%%/server-status?auto +logs: + source: apache + service: webapp +``` + +Cela correspond à **toutes** les images de conteneur `httpd` sur votre host. Si vous avez un conteneur exécutant `foo/httpd:latest` et un autre exécutant `bar/httpd:v2`, l'Agent applique le modèle ci-dessus aux deux conteneurs. + +Lorsque vous utilisez des noms d'image courts comme identifiants de conteneur Autodiscovery, l'Agent ne peut pas faire la distinction entre des images portant le même nom provenant de sources différentes ou avec des tags différents. + +### Identificateurs multiples + +Indiquez plusieurs noms d'image en ajoutant des éléments à la liste `ad_identifiers`, par exemple : + +```yaml +ad_identifiers: + - httpd + - my-custom-httpd-image +``` + +Cela correspond à **toutes** les images de conteneur sur votre host qui correspondent à `httpd` **ou** `my-custom-httpd-image`. + +## Identificateurs de conteneur Autodiscovery personnalisés + +Si vous souhaitez appliquer différents modèles de configuration à des conteneurs exécutant la même image, utilisez des identifiants de conteneur personnalisés. + +1. Fournissez un identifiant de conteneur personnalisé à votre conteneur à l'aide d'un label Docker ou d'une annotation Kubernetes. + + **Exemple** : + Appliquez un label Docker ou une annotation Kubernetes pour identifier votre conteneur comme `foo` : + + {{< tabs >}} + {{% tab "Étiquette Docker" %}} + + ```yaml + LABEL com.datadoghq.ad.check.id="foo" + ``` + + **Remarque** **Remarque** : l'étiquette `com.datadoghq.ad.check.id` est prioritaire sur le nom d'image. + + {{% /tab %}} + {{% tab "Annotation Kubernetes" %}} + + ```text + ad.datadoghq.com/.check.id: 'foo' + ``` + + Remplacez `` par le nom du conteneur dans le pod. + + **Remarque** : pris en charge dans l'Agent Datadog v6.25+ et v7.25. L'étiquette `ad.datadoghq.com/.check.id` est prioritaire sur le nom d'image. + {{% /tab %}} + {{< /tabs >}} + +2. Référencez cette valeur personnalisée dans votre modèle de configuration Autodiscovery. + + **Exemple** : + Le modèle de configuration Autodiscovery Apache suivant désigne une image de conteneur avec le nom personnalisé `foo` : + + ```yaml + ad_identifiers: + - foo + init_config: + instances: + - apache_status_url: http://%%host%%/server-status?auto + logs: + source: apache + service: webapp + ``` + +## Identifiants de conteneur avancés + +Pour les cas d'utilisation nécessitant une granularité supplémentaire sur l'Agent v7.73.0+, vous pouvez utiliser l'option de configuration de check `cel_selector` pour cibler des conteneurs spécifiques en fonction d'attributs de conteneur supplémentaires. Ces règles sont basées sur la syntaxe [Common Expression Language][3]. + +Remarque : pour être une configuration Autodiscovery valide, la configuration de check doit inclure soit un `ad_identifier`, soit une règle de conteneur `cel_selector` avec le paramètre `container.image.reference`. + +**Exemple** : +Le modèle de configuration Autodiscovery NGINX suivant désigne une image de conteneur avec le nom `nginx` sur deux espaces de nommage sélectionnés. Les conditions répertoriées séparément sont jointes par une opération **OR**. + +```yaml +ad_identifiers: + - nginx +cel_selector: + containers: + - container.pod.namespace == "target-ns-1" + - container.pod.namespace == "target-ns-2" +``` + +| Attribut | Description | +|------------------------------|------------------------------------------------------------| +| `container.name` | Nom du conteneur. | +| `container.image.reference` | Référence complète de l'image de conteneur (registre, référentiel, tag/digest). | +| `container.pod.name` | Nom du pod exécutant le conteneur. | +| `container.pod.namespace` | Espace de nommage Kubernetes du pod. | +| `container.pod.annotations` | Annotations appliquées au pod (mappage clé-valeur). | + +Ces attributs peuvent être utilisés avec la [syntaxe CEL][4] pour définir des règles permettant de sélectionner des conteneurs spécifiques pour la planification de checks. Voici une liste d'exemples de règles pouvant être définies : + +### Exemples + +Pour sélectionner le conteneur exécutant l'image `nginx` avec une annotation de pod spécifique : + +```yaml +ad_identifiers: + - nginx +cel_selector: + containers: + - container.pod.annotations["monitoring"] == "true" +``` + +Pour sélectionner le conteneur exécutant l'image `nginx` dans des espaces de nommage sans la sous-chaîne `-dev` : + +```yaml +ad_identifiers: + - nginx +cel_selector: + containers: + - !container.pod.namespace.matches("-dev") +``` + +Pour sélectionner le conteneur exécutant l'image `nginx` avec le nom de conteneur `nginx-server` uniquement dans l'espace de nommage `prod` : + +```yaml +ad_identifiers: + - nginx +cel_selector: + containers: + - container.name == "nginx-server" && container.pod.namespace == "prod" +``` + +Pour sélectionner le conteneur exécutant une image avec la sous-chaîne `nginx` : + +```yaml +cel_selector: + containers: + - container.image.reference.matches("nginx") +``` + +Pour sélectionner des conteneurs à l'aide d'une logique groupée (par exemple, un nom de conteneur spécifique dans l'un des deux espaces de nommage) : + +```yaml +ad_identifiers: + - nginx +cel_selector: + containers: + - container.name == "my-app" && (container.pod.namespace == "production" || container.pod.namespace == "staging") +``` + +
+ +Des conditions larges peuvent cibler involontairement des conteneurs sur votre host. Par exemple, l'utilisation d'un `cel_selector` de conteneurs comme `!container.image.reference.matches("nginx")` sélectionne **tous** les conteneurs du host à l'exception de nginx, y compris les composants système et probablement des applications non liées. Cela peut entraîner une collecte de données de télémétrie supplémentaire pouvant avoir un impact sur la facturation. +
+ +Pour exclure globalement des charges de travail particulières de la collecte, quelle que soit l'intégration de check, consultez la section [Gestion de la découverte de conteneurs][5]. + +## Pour aller plus loin + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /fr/getting_started/containers/autodiscovery +[2]: /fr/glossary/#short-image +[3]: https://cel.dev/ +[4]: https://github.com/google/cel-spec/blob/master/doc/langdef.md +[5]: /fr/containers/guide/container-discovery-management \ No newline at end of file diff --git a/content/fr/containers/guide/auto_conf.md b/content/fr/containers/guide/auto_conf.md index 93451da5dce..6f4ae03713d 100644 --- a/content/fr/containers/guide/auto_conf.md +++ b/content/fr/containers/guide/auto_conf.md @@ -9,19 +9,22 @@ aliases: - /fr/agent/autodiscovery/auto_conf - /fr/agent/faq/auto_conf - /fr/agent/guide/auto_conf +description: Gérer la configuration automatique pour les services conteneurisés populaires + à l'aide de modèles de configuration automatique Autodiscovery further_reading: -- link: /agent/kubernetes/integrations/ +- link: /containers/kubernetes/integrations/ tag: Documentation - text: Créer et charger un modèle d'intégration Autodiscovery -- link: /agent/guide/autodiscovery-management/ + text: Configurer des intégrations avec Autodiscovery sur Kubernetes +- link: /containers/docker/integrations/ tag: Documentation - text: Gérer les conteneurs à inclure dans Autodiscovery avec l'Agent + text: Configurer des intégrations avec Autodiscovery sur Docker +- link: /containers/guide/container-discovery-management/ + tag: Documentation + text: Gestion de la découverte de conteneurs title: Configuration automatique d'Autodiscovery --- -Lorsque l'Agent s'exécute en tant que conteneur, il tente de découvrir les autres conteneurs environnants à l'aide des fichiers de configuration Autodiscovery par défaut intitulés `auto_conf.yaml`. Ces fichiers se trouvent dans les dossiers `conf.d/.d/` des intégrations suivantes : - -## Fichiers de configuration automatique +Lorsque l'Agent s'exécute en tant que conteneur, [Autodiscovery][49] tente de découvrir d'autres conteneurs en fonction de fichiers de configuration par défaut nommés `auto_conf.yaml`. Vous pouvez trouver ces fichiers dans les dossiers `conf.d/.d/` correspondants pour les intégrations suivantes : | Intégration | Fichier de configuration automatique | | ------ | -------- | @@ -51,32 +54,56 @@ Lorsque l'Agent s'exécute en tant que conteneur, il tente de découvrir les aut Les fichiers de configuration `auto_conf.yaml` rassemblent tous les paramètres requis pour configurer une intégration spécifique. Les [template variables Autodiscovery][43] correspondantes qui sont fournies prennent en compte l'environnement conteneurisé. -## Configuration personanalisée -La logique de configuration automatique prend uniquement en charge la configuration par défaut de chacune des intégrations ci-dessus. Si vous souhaitez personnaliser la configuration de votre intégration Datadog, consultez la section Modèles d'intégration pour découvrir comment configurer la fonctionnalité Autodiscovery de votre Agent. Toute configuration découverte par l'intermédiaire des annotations Kubernetes ou des étiquettes Docker d'un conteneur donné est prioritaire sur le fichier `auto_conf.yaml`. +## Remplacer la configuration automatique +Chaque fichier `auto_conf.yaml` fournit une configuration par défaut. Pour la remplacer, vous pouvez ajouter une configuration personnalisée dans les [annotations Kubernetes][50] ou les [étiquettes Docker][51]. -* [Utiliser le stockage key/value][44] -* [Utiliser les annotations Kubernetes][45] -* [Utiliser les étiquettes Docker][46] +Les annotations Kubernetes et les étiquettes Docker ont la priorité sur les fichiers `auto_conf.yaml`, mais les fichiers `auto_conf.yaml` ont la priorité sur la configuration Autodiscovery définie dans le Datadog Operator et les charts Helm. Pour utiliser le Datadog Operator ou Helm afin de configurer Autodiscovery pour une intégration du tableau de cette page, vous devez [désactiver la configuration automatique](#desactiver-la-configuration-automatique). ## Désactiver la configuration automatique -Pour empêcher lʼAgent d'utiliser la configuration `auto_conf.yaml`, vous pouvez ajouter lʼenvironnement de variable `DD_IGNORE_AUTOCONF` pour la ou les intégrations à désactiver. Dans les exemples suivants, lʼAgent ignorerait les fichiers [`redisdb.d/auto_conf.yaml`][38] et [`istio.d/auto_conf.yaml`][22] et éviterait de configurer automatiquement ces intégrations. +Les exemples suivants désactivent la configuration automatique pour les intégrations Redis et Istio. {{< tabs >}} +{{% tab "Operator Datadog" %}} + +Dans votre `datadog-agent.yaml`, utilisez `override.nodeAgent.containers.agent.env` pour définir la variable d'environnement `DD_IGNORE_AUTOCONF` dans le conteneur `agent`. + +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + global: + credentials: + apiKey: + + override: + nodeAgent: + containers: + agent: + env: + - name: DD_IGNORE_AUTOCONF + value: "redisdb istio" +``` + +Ensuite, appliquez la nouvelle configuration. + +{{% /tab %}} {{% tab "Helm" %}} -Pour désactiver lʼintégration de configurations automatiques avec Helm, ajoutez `datadog.ignoreAutoconfig` à votre fichier `values.yaml` : +Ajoutez `datadog.ignoreAutoconfig` à votre `datadog-values.yaml` : ```yaml datadog: - #Liste des intégrations à ignorer auto_conf.yaml. + #List of integration(s) to ignore auto_conf.yaml. ignoreAutoConfig: - redisdb - istio ``` {{% /tab %}} -{{% tab "DaemonSet" %}} -Pour désactiver lʼintégration de configurations automatiques avec votre DaemonSet, ajoutez la variable `DD_IGNORE_AUTOCONF` à votre manifeste de lʼAgent : +{{% tab "Agent conteneurisé" %}} +Pour désactiver la configuration automatique d'intégration(s) avec votre Agent conteneurisé (DaemonSet manuel, Docker, ECS), ajoutez la variable d'environnement `DD_IGNORE_AUTOCONF` : ```yaml DD_IGNORE_AUTOCONF="redisdb istio" @@ -135,4 +162,7 @@ DD_IGNORE_AUTOCONF="redisdb istio" [45]: /fr/agent/kubernetes/integrations/?tab=kubernetes#configuration [46]: /fr/agent/docker/integrations/#configuration [47]: /fr/integrations/rabbitmq/ -[48]: https://github.com/DataDog/integrations-core/blob/master/rabbitmq/datadog_checks/rabbitmq/data/auto_conf.yaml \ No newline at end of file +[48]: https://github.com/DataDog/integrations-core/blob/master/rabbitmq/datadog_checks/rabbitmq/data/auto_conf.yaml +[49]: /fr/getting_started/containers/autodiscovery +[50]: /fr/containers/kubernetes/integrations/?tab=annotations#configuration +[51]: /fr/containers/docker/integrations/ \ No newline at end of file diff --git a/content/fr/containers/guide/autodiscovery-with-jmx.md b/content/fr/containers/guide/autodiscovery-with-jmx.md index 342f42a0276..690bbce82b6 100644 --- a/content/fr/containers/guide/autodiscovery-with-jmx.md +++ b/content/fr/containers/guide/autodiscovery-with-jmx.md @@ -1,6 +1,18 @@ --- +algolia: + tags: + - JMX + - Métriques JMX + - Web Logic manquant + - Limite JMX + - Cassandra + - Kafka + - Tomcat + - Weblogic aliases: - /fr/agent/guide/autodiscovery-with-jmx +description: Configurer des intégrations basées sur JMX pour les applications Java + conteneurisées à l'aide de modèles Autodiscovery further_reading: - link: /agent/kubernetes/integrations/ tag: Documentation @@ -73,7 +85,7 @@ kind: Pod metadata: name: annotations: - ad.datadoghq.com/.checks: | + ad.datadoghq.com/.checks: | { "": { "init_config": { @@ -89,7 +101,7 @@ metadata: # (...) spec: containers: - - name: '' + - name: '' # (...) env: - name: POD_IP @@ -109,7 +121,7 @@ spec: Dans cet exemple : - `` est le nom de votre pod. -- `` correspond au conteneur souhaité dans votre pod. +- `` correspond au conteneur souhaité dans votre pod. - `` est le nom de l'intégration JMX souhaitée. Référez-vous à la liste des [intégrations JMX disponibles] (#integrations-JMX-disponibles). - Définissez `` comme vous le souhaitez, en veillant à ce quʼil y ait une correspondance entre les annotations et `JAVA_OPTS`. @@ -168,7 +180,7 @@ spec: Si vous devez collecter d'autres métriques à partir de ces intégrations, ajoutez-les à la section `init_config` : ```yaml -ad.datadoghq.com/.checks: | +ad.datadoghq.com/.checks: | { "": { "init_config": { @@ -217,7 +229,7 @@ Ce fichier de configuration doit inclure `ad_identifiers` : ```yaml ad_identifiers: - - "" + - init_config: is_jmx: true @@ -229,7 +241,7 @@ instances: port: "" ``` -Remplacez `` par le nom dʼimage court du conteneur de votre choix. Par exemple, lʼimage de conteneur `gcr.io/CompanyName/my-app:latest` a pour nom dʼimage court `my-app`. Lorsque lʼAgent Datadog découvre ce conteneur, il établit la configuration JMX comme décrit dans ce fichier. +Remplacez `` par le nom d'image court du conteneur souhaité. Par exemple, l'image de conteneur `gcr.io/CompanyName/my-app:latest` a un nom d'image court `my-app`. Lorsque l'Agent Datadog découvre ce conteneur, il configure JMX comme décrit dans ce fichier. Vous pouvez également spécifier [des identifiants personnalisés pour vos conteneurs][4] et y faire référence si vous ne souhaitez pas vous baser sur le nom court de l'image. @@ -258,7 +270,7 @@ spec: configDataMap: .yaml: |- ad_identifiers: - - "" + - init_config: is_jmx: true @@ -278,7 +290,7 @@ datadog: confd: .yaml: | ad_identifiers: - - "" + - init_config: is_jmx: true @@ -292,7 +304,7 @@ datadog: {{% tab "Custom image" %}} Si vous ne pouvez pas monter ces fichiers dans le conteneur de lʼAgent (par exemple, sur Amazon ECS), vous pouvez créer une image Docker de lʼAgent contenant les fichiers de configuration souhaités. -Par exemple : +Exemple : ```Dockerfile FROM gcr.io/datadoghq/agent:latest-jmx diff --git a/content/fr/containers/guide/aws-batch-ecs-fargate.md b/content/fr/containers/guide/aws-batch-ecs-fargate.md new file mode 100644 index 00000000000..711d4308bb2 --- /dev/null +++ b/content/fr/containers/guide/aws-batch-ecs-fargate.md @@ -0,0 +1,140 @@ +--- +aliases: +- /fr/integrations/faq/aws-batch-ecs-fargate +- /fr/agent/guide/aws-batch-ecs-fargate-datadog-agent +description: Déployer l'Agent Datadog aux côtés des tâches AWS Batch s'exécutant sur + ECS Fargate pour une surveillance complète +further_reading: +- link: integrations/ecs_fargate/?tab=webui#aws-batch-on-ecs-fargate + tag: Documentation + text: Amazon ECS sur AWS Fargate avec AWS Batch +title: AWS Batch avec ECS Fargate et l'Agent Datadog +--- + +Vous pouvez exécuter l'Agent Datadog aux côtés de vos conteneurs de tâches AWS Batch en ajoutant le conteneur à votre définition de tâche. + +## Prérequis + +* Environnement de calcul AWS Batch +* File d'attente de tâches AWS Batch associée à un environnement de calcul + +## Créer la définition de tâche + +{{< tabs >}} +{{% tab "Interface Web AWS" %}} + +1. Connectez-vous à votre [console Web AWS][1] et accédez à la section AWS Batch. +2. Cliquez sur **Job Definitions** dans le menu de gauche, puis cliquez sur le bouton **Create** ou choisissez une définition de tâche AWS Batch existante. +3. Pour les nouvelles définitions de tâche : + 1. Sélectionnez **Fargate** comme type d'orchestration. + 2. Désélectionnez l'option **Use legacy containerProperties structure**. + 3. Saisissez un **Job Definition Name**, tel que `my-app-and-datadog`. + 4. Sélectionnez un rôle IAM d'exécution. Consultez la section [Créer ou modifier votre stratégie IAM](#creer-ou-modifier-votre-strategie-iam) ci-dessous pour connaître les exigences d'autorisation. + 5. Activez **Assign public IP** pour autoriser l'accès réseau sortant, puis cliquez sur le bouton **Next**. + 6. Configurez le conteneur de l'Agent Datadog. + 1. Pour le champ **Container name**, saisissez `datadog-agent`. + 2. Pour **Image**, saisissez `public.ecr.aws/datadog/agent:latest`. + 3. Configurez les exigences de ressources **CPU** et **Memory** en fonction de vos besoins. + 4. Pour **Env Variables**, ajoutez la **Key** `DD_API_KEY` et saisissez votre [clé d'API Datadog][2] comme valeur. + 5. Ajoutez une autre variable d'environnement avec la **clé** `ECS_FARGATE` et la valeur `true`. Cliquez sur **Add** pour ajouter le conteneur. + 6. Ajoutez une autre variable d'environnement en utilisant la **clé** `DD_SITE` et la valeur {{< region-param key="dd_site" code="true" >}}. Le site `datadoghq.com` est utilisé par défaut si vous ne le définissez pas. + 7. Ajoutez vos autres conteneurs d'application à la définition de tâche. + 8. AWS Batch prend en charge [Fluent Bit et Firelens][3]. Pour activer la collecte de logs pour vos conteneurs d'application avec Datadog : + 1. Créez un conteneur de routeur de log distinct dans la définition de tâche. + 2. Configurez l'image `amazon/aws-for-fluent-bit:stable"` pour le conteneur. + 3. Dans la section Firelens Configuration : + - Configurez le **Type** sur `fluentbit`. + - Configurez les **Options** pour inclure `enable-ecs-log-metadata` défini sur `true` pour **Name** et **Value** respectivement + 4. Pour vos conteneurs d'application, dans la section Log Configuration : + - Configurez le **Log Driver** sur `awsfirelens` + - Configurez les **Options** pour inclure les **Name** et **Value** suivants de manière similaire à l'étape 2 de la section [ECS Fargate Fluent Bit et Firelens][4] + 10. Cliquez sur **Create job definition** pour créer la définition de tâche. + +[1]: https://app.datadoghq.com/organization-settings/api-keys +[2]: https://app.datadoghq.com/organization-settings/api-keys +[3]: https://aws.amazon.com/about-aws/whats-new/2025/04/aws-batch-amazon-elastic-container-service-exec-firelens-log-router/ +[4]: https://docs.datadoghq.com/fr/integrations/ecs_fargate/?tab=webui#fluent-bit-and-firelens + +{{% /tab %}} +{{% tab "AWS CLI" %}} + +1. Téléchargez [datadog-agent-aws-batch-ecs-fargate.json][1]. + + **Remarque** : si vous utilisez Internet Explorer, cela peut être téléchargé sous forme de fichier gzip, qui contient le fichier JSON mentionné ci-dessous. +2. Mettez à jour le JSON avec un `JOB_DEFINITION_NAME`, votre [clé d'API Datadog][2] et le `DD_SITE` approprié ({{< region-param key="dd_site" code="true" >}}). + + **Remarque** : la variable d'environnement `ECS_FARGATE` est déjà définie sur `"true"`. +3. Ajoutez vos autres conteneurs d'application à la définition de tâche. +4. AWS Batch prend en charge [Fluent Bit et Firelens][3]. Pour activer la collecte de logs pour vos conteneurs d'application avec Datadog : + - Dans le fichier JSON, ajoutez un conteneur `log_router` supplémentaire avec ce qui suit dans la section `containers` : + ```json + { + "name": "log_router", + "image": "amazon/aws-for-fluent-bit:stable", + "essential": true, + "firelensConfiguration": { + "type": "fluentbit", + "options": { + "enable-ecs-log-metadata": "true" + } + }, + "resourceRequirements": [ + { + "value": "0.25", + "type": "VCPU" + }, + { + "value": "512", + "type": "MEMORY" + } + ] + } + ``` + - Dans vos conteneurs d'application, ajoutez les options `logConfiguration` pertinentes de manière similaire à l'étape 2 de la section [ECS Fargate Fluent Bit et Firelens][4] +5. Exécutez la commande suivante pour enregistrer la définition de tâche : + + ```bash + aws batch register-job-definition --cli-input-json file:///datadog-agent-aws-batch-ecs-fargate.json + ``` + +[1]: https://docs.datadoghq.com/resources/json/datadog-agent-aws-batch-ecs-fargate.json +[2]: https://app.datadoghq.com/organization-settings/api-keys +[3]: https://aws.amazon.com/about-aws/whats-new/2025/04/aws-batch-amazon-elastic-container-service-exec-firelens-log-router/ +[4]: https://docs.datadoghq.com/fr/integrations/ecs_fargate/?tab=webui#fluent-bit-and-firelens +{{% /tab %}} +{{< /tabs >}} + +## Soumettre la tâche AWS Batch + +{{< tabs >}} +{{% tab "Interface Web AWS" %}} + +1. Connectez-vous à votre [console Web AWS][1] et accédez à la section AWS Batch. Si nécessaire, créez un [environnement de calcul][2] et/ou une [file d'attente de tâches][3] associée à un environnement de calcul. +2. Dans l'onglet **Jobs**, cliquez sur le bouton **Submit new job**. +3. Saisissez un **Job name**. +4. Pour **Job Definition**, sélectionnez la tâche créée dans les étapes précédentes. +5. Choisissez la file d'attente de tâches sur laquelle exécuter l'Agent Datadog. +6. Les **Container overrides** sont facultatifs selon votre préférence. +7. Cliquez sur le bouton **Next**, puis cliquez sur le bouton **Create job**. + +[1]: https://aws.amazon.com/console +[2]: https://docs.aws.amazon.com/batch/latest/userguide/create-compute-environment.html +[3]: https://docs.aws.amazon.com/batch/latest/userguide/create-job-queue-fargate.html + +{{% /tab %}} +{{% tab "AWS CLI" %}} + +1. Exécutez la commande suivante pour soumettre une tâche pour votre définition de tâche : + +```bash +aws batch submit-job --job-name \ +--job-queue \ +--job-definition :1 +``` + +{{% /tab %}} +{{< /tabs >}} + +## Pour aller plus loin + +{{< partial name="whats-next/whats-next.html" >}} \ No newline at end of file diff --git a/content/fr/containers/guide/build-container-agent.md b/content/fr/containers/guide/build-container-agent.md index 1b9dfc14317..e8c2ff618b6 100644 --- a/content/fr/containers/guide/build-container-agent.md +++ b/content/fr/containers/guide/build-container-agent.md @@ -1,10 +1,12 @@ --- aliases: - /fr/agent/guide/build-container-agent +description: Instructions pour créer des images Docker personnalisées de l'Agent Datadog + à partir du code source title: Créer l'image de l'Agent Datadog --- -Suivez les instructions ci-dessous pour créer l'image Docker de l'Agent Datadog pour une `` spécifique (à partir de la version 6.0). +Suivez les instructions ci-dessous pour créer l'image Docker de l'Agent Datadog pour une `` spécifique (à partir de la version 6.0). 1. Dupliquez le référentiel de l'Agent Datadog : @@ -12,7 +14,7 @@ Suivez les instructions ci-dessous pour créer l'image Docker de l'Agent Datadog git clone https://github.com/DataDog/datadog-agent.git ``` -2. Accédez au dossier `datadog-agent/Dockerfile/agent/` : +2. Accédez au dossier `datadog-agent/Dockerfiles/agent/` : ```shell cd datadog-agent/Dockerfiles/agent/ @@ -30,14 +32,14 @@ Suivez les instructions ci-dessous pour créer l'image Docker de l'Agent Datadog {{% tab "AMD" %}} ```shell -curl https://s3.amazonaws.com/apt.datadoghq.com/pool/d/da/datadog-agent_-1_amd64.deb -o datadog-agent_-1_amd64.deb +curl https://s3.amazonaws.com/apt.datadoghq.com/pool/d/da/datadog-agent_-1_amd64.deb -o datadog-agent_-1_amd64.deb ``` {{% /tab %}} {{% tab "ARM" %}} ```shell -curl https://s3.amazonaws.com/apt.datadoghq.com/pool/d/da/datadog-agent_-1_arm64.deb -o datadog-agent_-1_arm64.deb +curl https://s3.amazonaws.com/apt.datadoghq.com/pool/d/da/datadog-agent_-1_arm64.deb -o datadog-agent_-1_arm64.deb ``` {{% /tab %}} @@ -51,14 +53,14 @@ curl https://s3.amazonaws.com/apt.datadoghq.com/pool/d/da/datadog-agent_ --file amd64/Dockerfile --pull --tag . +docker build --build-arg --file amd64/Dockerfile --pull --tag . ``` {{% /tab %}} {{% tab "ARM" %}} ```shell -docker build --build-arg --file arm64/Dockerfile --pull --tag . +docker build --build-arg --file arm64/Dockerfile --pull --tag . ``` {{% /tab %}} @@ -70,7 +72,7 @@ docker build --build-arg --file arm64/Dockerfile --pull --tag docker build --build-arg DD_AGENT_ARTIFACT=./datadog-agent_7.17.0-1_amd64.deb --file amd64/Dockerfile --pull --tag documentation-example . ``` - Les `` acceptés sont : + Les `` acceptés sont : | Argument | Définition | Défaut | | ----------------- | --------------------------------------------------------------------------- | ------- | diff --git a/content/fr/containers/guide/changing_container_registry.md b/content/fr/containers/guide/changing_container_registry.md new file mode 100644 index 00000000000..557123dcfbb --- /dev/null +++ b/content/fr/containers/guide/changing_container_registry.md @@ -0,0 +1,181 @@ +--- +aliases: +- /fr/agent/guide/changing_container_registry +description: Passer d'un registre d'images de conteneur Datadog à un autre pour différents + environnements de déploiement et exigences +title: Modifier votre registre de conteneurs +--- + +Datadog publie des images de conteneur dans gcr.io de Google, Azure ACR, ECR d'AWS et sur Docker Hub : + +{{% container-images-table %}} + +L'extraction depuis le registre ACR, GCR ou ECR fonctionne de la même manière (sauf pour Notary) que l'extraction depuis Docker Hub. Vous pouvez utiliser la même commande (avec des paramètres différents) et obtenir la même image. + +**Remarque** : ACR, ECR et GCR ne prennent pas en charge Notary. Si vous vérifiez la signature des images extraites de Docker, cette fonctionnalité ne fonctionne pas sur GCR ou ECR. + +Pour mettre à jour votre registre, vous devez modifier les valeurs du registre en fonction du type d'environnement de conteneur sur lequel le déploiement sera effectué. + +**Remarque** : vous pouvez également utiliser un registre privé, mais vous devrez créer un secret de type pull pour pouvoir extraire les images du registre privé. +Pour plus d'informations sur la création d'un secret de type pull, consultez la [documentation Kubernetes][1]. + +## Docker + +### Mise à jour de votre registre + +Pour mettre à jour votre registre de conteneurs, exécutez la commande pull pour le nouveau registre. Pour voir les commandes Docker pull pour différents registres de conteneurs, consultez les exemples de la [page de présentation de la documentation Docker][2]. + +## Kubernetes avec le chart Helm + +Pour mettre à jour votre registre de conteneurs lorsque vous déployez l'Agent Datadog (ou l'Agent de cluster Datadog) avec le chart helm Datadog sur Kubernetes (y compris GKE, EKS, AKS et OpenShift), modifiez le registre spécifié dans le fichier `values.yaml` : + +### Chart Helm Datadog >= v2.7.0 + +1. Mettez à jour votre fichier `values.yaml` : + ```yaml + registry: gcr.io/datadoghq + ``` +2. Supprimez les éventuelles valeurs personnalisées définies pour `agents.image.repository`, `clusterAgent.image.repository` ou `clusterChecksRunner.image.repository` dans `values.yaml`. + +### Chart Helm Datadog < v2.7.0 + +Définissez le référentiel `gcr.io` : + +```yaml +agents: + image: + repository: gcr.io/datadoghq/agent + +clusterAgent: + image: + repository: gcr.io/datadoghq/cluster-agent + +clusterChecksRunner: + image: + repository: gcr.io/datadoghq/agent +``` + +Pour plus d'informations sur l'utilisation du chart Helm Datadog, consultez la [documentation Kubernetes de Datadog][3] et l'exemple de fichier [`values.yaml`][4]. + +Si vous utilisez un registre privé, vous devrez ajouter un secret de type pull au champ `[key].image.pullSecrets` pour chaque image. +```yaml +agents: + image: + pullSecrets: + - name: PrivateRegistrySecret + +clusterAgent: + image: + pullSecrets: + - name: PrivateRegistrySecret + +clusterChecksRunner: + image: + pullSecrets: + - name: PrivateRegistrySecret +``` + +## Kubernetes avec l'Operator Datadog + +Pour mettre à jour votre registre lors du déploiement de l'Agent Datadog (ou de l'Agent de cluster Datadog) avec le Datadog Operator : + +1. Mettez à jour le fichier de manifeste de l'Agent Datadog pour remplacer le registre par défaut (`gcr.io/datadoghq`). Par exemple, avec `public.ecr.aws/datadog` : +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + global: + registry: gcr.io/datadoghq + // .. +``` + +2. Supprimez toutes les substitutions pour les champs `spec.override.nodeAgent.image.name`, `spec.override.clusterAgent.image.name` et `spec.override.clusterChecksRunner.image.name`. +3. Si vous utilisez un registre privé, vous devrez ajouter un secret de type pull au champ `[key].image.pullSecrets` pour chaque image. +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + override: + nodeAgent: + image: + pullSecrets: + - name: PrivateRegistrySecret + clusterAgent: + image: + pullSecrets: + - name: PrivateRegistrySecret + clusterChecksRunner: + image: + pullSecrets: + - name: PrivateRegistrySecret + // .. +``` + +Pour plus d'informations sur le Datadog Operator, consultez la section [Déployer un Agent avec l'opérateur][5]. + + +### Utiliser un autre registre de conteneurs avec Helm + +Vous pouvez également passer du registre par défaut `gcr.io/datadoghq` à un autre registre, tel que `datadoghq.azurecr.io` lors de l'installation de l'opérateur avec le chart Helm : + +Mettez à jour [`values.yaml`][6] avec la nouvelle image : + +```yaml +image: + repository: datadoghq.azurecr.io +``` + +## ECS + +Pour mettre à jour votre registre lors du déploiement sur ECS, dans le fichier `datadog-agent-ecs.json`, modifiez la valeur de la clé `"image"` sous `containerDefinitions` en `"public.ecr.aws/datadog/agent:latest"` : + +```json +"image": "public.ecr.aws/datadog/agent:latest", +``` + +Pour plus d'informations sur le déploiement de Datadog sur ECS, consultez la [documentation ECS de Datadog][7] et l'exemple de fichier [`datadog-agent-ecs.json`][7]. + +## Fargate + +Pour mettre à jour votre registre lors d'un déploiement sur Fargate, mettez à jour l'image dans la définition de tâche Fargate pour la définir sur `public.ecr.aws` : + +```json +"image": "public.ecr.aws/datadog/agent:latest" +``` + +Au prochain démarrage de la tâche, l'image sera récupérée depuis `public.ecr.aws` au lieu de Docker Hub. Pour en savoir plus sur le déploiement de Datadog sur Fargate, consultez [Déployer l'Agent sur ECS][8] et [Déployer l'Agent sur EKS][9]. + +## Agent de cluster + +Si vous utilisez le chart Helm pour déployer l'Agent Datadog et l'Agent de cluster Datadog, suivez les instructions de la section [Kubernetes avec le chart Helm](#kubernetes-avec-le-chart-helm). Aucune autre modification n'est nécessaire. La modification du référentiel dans le fichier Helm `values.yaml` décrite précédemment s'appliquera aussi bien à l'Agent de cluster qu'à l'Agent Datadog. + +Si vous utilisez l'Operator Datadog pour déployer l'Agent de cluster Datadog, suivez les instructions de la section [Kubernetes avec l'Operator Datadog](#kubernetes-avec-l-operator-datadog). Aucune autre modification n'est nécessaire. La mise à jour du référentiel dans la configuration de l'Operator s'appliquera aussi bien à l'Agent de cluster qu'à l'Agent Datadog. + +Pour en savoir plus sur l'Agent de cluster Datadog, consultez la [documentation relative à l'Agent de cluster][10] et les [instructions de configuration][11]. + +## Kubernetes via Helm pour le worker d'emplacement privé Datadog + +Pour modifier votre registre pour le worker d'emplacement privé, mettez à jour l'image `datadog/synthetics-private-location-worker` et définissez-la sur `public.ecr.aws/datadog/synthetics-private-location-worker` ou `gcr.io/datadoghq/synthetics-private-location-worker`. + +Pour modifier le référentiel par défaut (`gcr.io/datadoghq`), mettez à jour le fichier `values.yaml` avec la nouvelle image : + +```yaml +image: + repository: gcr.io/datadoghq/synthetics-private-location-worker +``` + +[1]: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials +[2]: https://docs.datadoghq.com/fr/agent/docker/?tab=standard +[3]: https://docs.datadoghq.com/fr/agent/kubernetes/?tab=helm +[4]: https://github.com/DataDog/helm-charts/blob/dae884481c5b3c9b67fc8dbd69c944bf3ec955e9/charts/datadog/values.yaml#L19 +[5]: https://docs.datadoghq.com/fr/agent/kubernetes/?tab=operator#deploy-an-agent-with-the-operator +[6]: https://github.com/DataDog/helm-charts/blob/main/charts/datadog-operator/values.yaml#L28 +[7]: https://docs.datadoghq.com/fr/agent/amazon_ecs/?tab=awscli +[8]: https://www.datadoghq.com/blog/aws-fargate-monitoring-with-datadog/#deploy-the-agent-on-ecs +[9]: https://www.datadoghq.com/blog/aws-fargate-monitoring-with-datadog/#deploy-the-agent-on-eks +[10]: https://docs.datadoghq.com/fr/agent/cluster_agent/ +[11]: https://docs.datadoghq.com/fr/agent/cluster_agent/setup/?tab=helm \ No newline at end of file diff --git a/content/fr/containers/guide/cluster_agent_autoscaling_metrics.md b/content/fr/containers/guide/cluster_agent_autoscaling_metrics.md index 7a3967bb47c..8e64c8da729 100644 --- a/content/fr/containers/guide/cluster_agent_autoscaling_metrics.md +++ b/content/fr/containers/guide/cluster_agent_autoscaling_metrics.md @@ -3,6 +3,8 @@ aliases: - /fr/agent/guide/cluster-agent-custom-metrics-server - /fr/agent/cluster_agent/external_metrics - /fr/containers/cluster_agent/external_metrics +description: Configurer Kubernetes Horizontal Pod Autoscaler pour utiliser des métriques + Datadog custom et externes avec l'Agent de cluster further_reading: - link: https://www.datadoghq.com/blog/datadog-cluster-agent/ tag: Blog @@ -23,6 +25,8 @@ further_reading: title: Autoscaling avec les métriques externes et custom de l'Agent de cluster --- +
Cette page décrit l'utilisation de Kubernetes Horizontal Pod Autoscaler (HPA). Pour le Kubernetes Autoscaling de Datadog, consultez la section Kubernetes Autoscaling.
+ ## Présentation L'autoscaling de pods horizontaux, une fonctionnalité lancée avec la [version 1.2 de Kubernetes][1], permet d'effectuer une mise à l'échelle automatique à partir de métriques de base, comme `CPU`. Cela nécessite toutefois l'utilisation de la ressource `metrics-server`, qui doit s'exécuter en parallèle de votre application. Depuis la version 1.6 de Kubernetes, il est désormais possible d'effectuer un autoscaling à partir de [métriques custom][2]. @@ -56,8 +60,8 @@ Pour activer le serveur de métriques externes pour votre Agent de cluster gér spec: global: credentials: - apiKey: - appKey: + apiKey: + appKey: features: externalMetricsServer: @@ -76,11 +80,11 @@ Pour définir les clés, il est également possible de faire référence aux nom global: credentials: apiSecret: - secretName: - keyName: + secretName: + keyName: appSecret: - secretName: - keyName: + secretName: + keyName: features: externalMetricsServer: @@ -95,16 +99,16 @@ Pour activer le serveur de métriques externes avec votre Agent de cluster dans ```yaml datadog: - apiKey: - appKey: + apiKey: + appKey: #(...) clusterAgent: enabled: true - # Activer le metricsProvider pour pouvoir effectuer un autoscaling en fonction des métriques Datadog + # Enable the metricsProvider to be able to scale based on metrics in Datadog metricsProvider: # clusterAgent.metricsProvider.enabled - # Définir sur true pour activer le fournisseur de métriques + # Set this to true to enable Metrics Provider enabled: true ``` @@ -197,8 +201,8 @@ Pour activer l'utilisation de la CRD `DatadogMetric`, mettez à jour la ressourc spec: global: credentials: - apiKey: - appKey: + apiKey: + appKey: features: externalMetricsServer: enabled: true @@ -258,9 +262,9 @@ Vous pouvez créer un objet `DatadogMetric` à l'aide du manifeste suivant : apiVersion: datadoghq.com/v1alpha1 kind: DatadogMetric metadata: - name: + name: spec: - query: + query: ``` #### Exemple d'objet DatadogMetric @@ -276,13 +280,11 @@ spec: ``` ### Utiliser DatadogMetric dans un Autoscaler de pods horizontaux -Une fois votre Agent de cluster configuré et la ressource `DatadogMetric` créée, mettez à jour votre Autoscaler de pods horizontaux afin de faire référence à la ressource `DatadogMetric` avec son espace de nommage et son nom. Le format standard permet de spécifier la métrique pour l'Autoscaler de pods horizontaux en tant que `type: External` et de fournir le nom de la métrique en respectant le format `datadogmetric@:`. +Une fois votre Agent de cluster configuré et la ressource `DatadogMetric` créée, mettez à jour votre Autoscaler de pods horizontaux afin de faire référence à la ressource `DatadogMetric` avec son espace de nommage et son nom. Le format standard permet de spécifier la métrique pour l'Autoscaler de pods horizontaux en tant que `type: External` et de fournir le nom de la métrique en respectant le format `datadogmetric@:`. #### Exemple d'Autoscalers de pods horizontaux avec DatadogMetric L'Autoscaler de pods horizontaux ci-dessous utilise l'objet `DatadogMetric` intitulé `nginx-requests`, en partant du principe que les deux objets se trouvent dans l'espace de nommage `nginx-demo` : -Avec `apiVersion: autoscaling/v2` : - ```yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler @@ -305,28 +307,7 @@ spec: value: 9 ``` -Avec `apiVersion: autoscaling/v2beta1` : - -```yaml -apiVersion: autoscaling/v2beta1 -kind: HorizontalPodAutoscaler -metadata: - name: nginxext -spec: - minReplicas: 1 - maxReplicas: 3 - scaleTargetRef: - apiVersion: apps/v1 - kind: Deployment - name: nginx - metrics: - - type: External - external: - metricName: datadogmetric@nginx-demo:nginx-requests - targetValue: 9 -``` - -Dans ces manifestes : +Dans ce manifeste : - L'Autoscaler de pods horizontaux est configuré de façon à effectuer l'autoscaling du déploiement `nginx`. - Le nombre maximum de réplicas créés est de `3`, et le minimum est de `1`. - L'Autoscaler de pods horizontaux repose sur les `nginx-requests` de `DatadogMetric` dans l'espace de nommage `nginx-demo`. @@ -343,14 +324,14 @@ spec: metrics: - type: External external: - metricName: "" + metricName: "" metricSelector: matchLabels: - : + : ``` ### Exemple d'Autoscalers de pods horizontaux sans DatadogMetric -Le manifeste d'Autoscaler de pods horizontaux ci-dessous permet de procéder à l'autoscaling d'un déploiement NGINX en fonction de la métrique `nginx.net.request_per_s` de Datadog à l'aide de `apiVersion: autoscaling/v2` : +Le manifeste d'Autoscaler de pods horizontaux ci-dessous permet de procéder à l'autoscaling d'un déploiement NGINX en fonction de la métrique `nginx.net.request_per_s` de Datadog : ```yaml apiVersion: autoscaling/v2 @@ -374,30 +355,7 @@ spec: value: 9 ``` -L'exemple suivant reprend le manifeste ci-dessus, mais cette fois avec `apiVersion: autoscaling/v2beta1` : -```yaml -apiVersion: autoscaling/v2beta1 -kind: HorizontalPodAutoscaler -metadata: - name: nginxext -spec: - minReplicas: 1 - maxReplicas: 3 - scaleTargetRef: - apiVersion: apps/v1 - kind: Deployment - name: nginx - metrics: - - type: External - external: - metricName: nginx.net.request_per_s - metricSelector: - matchLabels: - kube_container_name: nginx - targetValue: 9 -``` - -Dans ces manifestes : +Dans ce manifeste : - L'Autoscaler de pods horizontaux est configuré de façon à effectuer l'autoscaling du déploiement `nginx`. - Le nombre maximum de réplicas créés est de `3`, et le minimum est de `1`. @@ -415,6 +373,13 @@ L'Agent de cluster Datadog crée automatiquement des ressources `DatadogMetric` Si vous choisissez de migrer un Autoscaler de pods horizontaux ultérieurement pour appeler un objet `DatadogMetric`, la ressource créée automatiquement sera nettoyée par l'Agent de cluster Datadog quelques heures plus tard. +Si vous le souhaitez, vous pouvez désactiver ce comportement en définissant `DD_EXTERNAL_METRICS_PROVIDER_ENABLE_DATADOGMETRIC_AUTOGEN` sur `false` comme suit : + +```yaml +- name: DD_EXTERNAL_METRICS_PROVIDER_ENABLE_DATADOGMETRIC_AUTOGEN + value: "false" +``` + ## Interroger l'Agent de cluster L'Agent de cluster transmet les requêtes pour les objets `DatadogMetric` toutes les 30 secondes. Il regroupe également les requêtes de métrique au sein de lots comprenant 35 requêtes. Ainsi, 35 requêtes `DatadogMetric` sont incluses dans une seule requête transmise à l'API de métriques Datadog. @@ -437,7 +402,7 @@ L'Agent de cluster interroge également les données des cinq dernières minutes L'Agent de cluster Datadog se charge de mettre à jour la sous-ressource `status` de toutes les ressources `DatadogMetric` afin de refléter les résultats des requêtes envoyées à Datadog. Ces informations sont à examiner en priorité afin de comprendre ce qui se passe en cas de dysfonctionnement. Vous pouvez exécuter la commande suivante pour récupérer ces informations générées pour vous : ```shell -kubectl describe datadogmetric +kubectl describe datadogmetric ``` #### Exemple @@ -478,7 +443,7 @@ Les quatre conditions vous permettent d'en savoir plus sur l'état actuel de vot ### Différence entre les types Value et AverageValue pour la métrique cible Les Autoscalers de pods horizontaux utilisés dans les exemples ci-dessus reposent sur le type de cible `Value`, et non `AverageValue`. Ces deux types sont acceptés. Modifiez vos requêtes de métrique Datadog en fonction du type choisi. -Lorsque vous utilisez le type `Value`, l'Autoscaler prend une décision basée sur la valeur de la métrique renvoyée telle quelle par la requête de métrique Datadog. Avec `AverageValue`, la valeur de métrique renvoyée est divisée par le nombre actuel de pods. Définissez donc votre `` en fonction du comportement à adopter vis-à-vis de la requête et de la valeur renvoyée. +Lorsque vous utilisez le type `Value`, l'Autoscaler prend une décision basée sur la valeur de la métrique renvoyée telle quelle par la requête de métrique Datadog. Avec `AverageValue`, la valeur de métrique renvoyée est divisée par le nombre actuel de pods. Définissez donc votre `` en fonction du comportement à adopter vis-à-vis de la requête et de la valeur renvoyée. Voici un exemple de configuration du type `Value` avec `apiVersion: autoscaling/v2` : ```yaml @@ -486,10 +451,10 @@ Voici un exemple de configuration du type `Value` avec `apiVersion: autoscaling/ - type: External external: metric: - name: datadogmetric@: + name: datadogmetric@: target: type: Value - value: + value: ``` Un autre exemple de configuration, avec le type `AverageValue` : @@ -498,14 +463,12 @@ Un autre exemple de configuration, avec le type `AverageValue` : - type: External external: metric: - name: datadogmetric@: + name: datadogmetric@: target: type: AverageValue - averageValue: + averageValue: ``` -Pour `apiVersion: autoscaling/v2beta1`, les options correspondantes sont `targetValue` et `targetAverageValue`. - ## Pour aller plus loin {{< partial name="whats-next/whats-next.html" >}} diff --git a/content/fr/containers/guide/cluster_agent_disable_admission_controller.md b/content/fr/containers/guide/cluster_agent_disable_admission_controller.md new file mode 100644 index 00000000000..67e19a944bb --- /dev/null +++ b/content/fr/containers/guide/cluster_agent_disable_admission_controller.md @@ -0,0 +1,85 @@ +--- +description: Désactiver et supprimer en toute sécurité le contrôleur d'admission Datadog + de votre cluster Kubernetes à l'aide de l'Agent de cluster +further_reading: +- link: https://www.datadoghq.com/blog/datadog-cluster-agent/ + tag: Blog + text: Présentation de l'Agent de cluster Datadog +- link: /containers/cluster_agent/admission_controller/ + tag: Documentation + text: Contrôleur d'admission Datadog +- link: /agent/cluster_agent/troubleshooting/ + tag: Documentation + text: Dépanner l'Agent de cluster Datadog +title: Désactiver le contrôleur d'admission Datadog avec l'Agent de cluster +--- + +## Présentation + +L'Agent de cluster Datadog gère le contrôleur d'admission Datadog en créant, mettant à jour et supprimant les contrôleurs d'admission selon les besoins. +Pour désactiver le contrôleur d'admission ou supprimer l'Agent de cluster, vous devez d'abord désactiver les fonctionnalités du contrôleur d'admission dans la configuration de l'Agent de cluster et redéployer l'Agent de cluster. +Une fois les contrôleurs d'admission supprimés, l'Agent de cluster peut être supprimé en toute sécurité si nécessaire. + +## Prérequis + +Agent de cluster Datadog v7.63+ + +## Étapes + +{{< tabs >}} +{{% tab "Datadog Operator" %}} +Pour désactiver les contrôleurs d'admission avec votre Agent de cluster géré par le Datadog Operator : +1. Définissez `features.admissionController.enabled` sur `false` dans votre configuration `DatadogAgent`. +2. Définissez `features.admissionController.validation.enabled` sur `false` dans votre configuration `DatadogAgent`. +3. Définissez `features.admissionController.mutation.enabled` sur `false` dans votre configuration `DatadogAgent`. + +```yaml + apiVersion: datadoghq.com/v2alpha1 + kind: DatadogAgent + metadata: + name: datadog + spec: + features: + admissionController: + enabled: false + validation: + enabled: false + mutation: + enabled: false +``` + + +Après avoir redéployé l'Agent de cluster avec la configuration mise à jour, les contrôleurs d'admission sont supprimés. +{{% /tab %}} +{{% tab "Helm" %}} +Pour désactiver les contrôleurs d'admission avec votre Agent de cluster géré par le chart Helm Datadog : +1. Définissez `clusterAgent.admissionController.enabled` sur `false`. +2. Définissez `clusterAgent.admissionController.validation.enabled` sur `false`. +3. Définissez `clusterAgent.admissionController.mutation.enabled` sur `false`. + +```yaml +clusterAgent: + enabled: true + admissionController: + enabled: false + validation: + enabled: false + mutation: + enabled: false +``` +{{% /tab %}} +{{% /tabs %}} + +Vous pouvez confirmer que les contrôleurs d'admission sont supprimés en vérifiant les ressources `ValidatingWebhookConfiguration` et `MutatingWebhookConfiguration` dans votre cluster. + +```shell +kubectl get validatingwebhookconfigurations.admissionregistration.k8s.io +``` + +```shell +kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io +``` + +## Pour aller plus loin + +{{< partial name="whats-next/whats-next.html" >}} \ No newline at end of file diff --git a/content/fr/containers/guide/compose-and-the-datadog-agent.md b/content/fr/containers/guide/compose-and-the-datadog-agent.md new file mode 100644 index 00000000000..958074f8e34 --- /dev/null +++ b/content/fr/containers/guide/compose-and-the-datadog-agent.md @@ -0,0 +1,176 @@ +--- +aliases: +- /fr/integrations/faq/compose-and-the-datadog-agent +- /fr/agent/guide/compose-and-the-datadog-agent +description: Configurer et déployer l'Agent Datadog aux côtés d'applications multi-conteneurs + à l'aide de Docker Compose +further_reading: +- link: https://github.com/DataDog/docker-compose-example + tag: Code source + text: Exemple dʼutilisation de Docker Composer avec Datadog +- link: /agent/docker/ + tag: Documentation + text: Documentation dédiée à l'Agent pour Docker de Datadog +- link: /agent/docker/log/ + tag: Documentation + text: Documentation dédiée à la collecte de logs Docker de Datadog +title: Compose et lʼAgent Datadog +--- + +[Compose][1] est un outil Docker qui simplifie la création d'applications sur Docker en vous permettant de définir, de créer et d'exécuter plusieurs conteneurs en tant qu'application unique. + +Bien que les [instructions pour lʼinstallation dʼun conteneur unique][2] permettent dʼexécuter le conteneur de lʼAgent Datadog, nous vous conseillons dʼactiver les intégrations pour d'autres services conteneurisés qui font partie de votre application Compose. Pour ce faire, vous devez combiner les fichiers YAML avec l'image de base de lʼAgent Datadog pour créer votre conteneur de lʼAgent Datadog. Ajoutez ensuite votre conteneur au fichier YAML de Compose. + +### Exemple Redis + +Voici un exemple de la façon dont vous pouvez surveiller un conteneur Redis en utilisant Compose. La structure du fichier est la suivante : + +```text +|- docker-compose.yml +|- datadog + |- Dockerfile + |- conf.d + |-redisdb.yaml +``` + +Le fichier `docker-compose.yml` décrit la façon dont vos conteneurs fonctionnent ensemble et définit certains détails de configuration pour les conteneurs. + +```yaml +version: '3' +services: + redis: + image: redis + datadog: + build: datadog + pid: host + environment: + - DD_API_KEY=${DD_API_KEY} + - DD_SITE={{< region-param key="dd_site" >}} + volumes: + - /var/run/docker.sock:/var/run/docker.sock + - /proc/:/host/proc/:ro + - /sys/fs/cgroup:/host/sys/fs/cgroup:ro +``` + +Le fichier `redisdb.yaml` s'inspire du [fichier redisdb.yaml.example][3]. Il indique à lʼAgent Datadog de rechercher Redis sur le host nommé `redis` (défini dans `docker-compose.yaml` ci-dessus) et d'utiliser le port Redis standard : + +```yaml +init_config: + +instances: + - host: redis + port: 6379 +``` + +Le `Dockerfile` est utilisé pour demander à Docker compose de créer une image de lʼAgent Datadog comprenant le fichier `redisdb.yaml` au bon emplacement : + +``` +FROM gcr.io/datadoghq/agent:latest +ADD conf.d/redisdb.yaml /etc/datadog-agent/conf.d/redisdb.yaml +``` + +### Collecte de traces APM + +En vous appuyant sur l'exemple Redis ci-dessus, vous pouvez également utiliser Compose pour configurer l'Agent Datadog afin de collecter des traces d'application. Ce fichier `docker-compose.yml` provient de [cet exemple Docker Compose sur GitHub][4]. + +```yaml +version: "4" +services: + web: + build: web + command: ddtrace-run python app.py + ports: + - "5000:5000" + volumes: + - ./web:/code # modified here to take into account the new app path + links: + - redis + environment: + - DATADOG_HOST=datadog # used by the web app to initialize the Datadog library + - DD_AGENT_HOST=dd-agent # points to dd-agent to send traces + redis: + image: redis + # agent section + datadog: + container_name: dd-agent + build: datadog + links: + - redis # ensures that redis is a host that the container can find + - web # ensures that the web app can send metrics + environment: + - DD_API_KEY= + - DD_DOGSTATSD_NON_LOCAL_TRAFFIC=true # enables agent to receive custom metrics from other containers + - DD_APM_ENABLED=true # enables tracing + - DD_APM_NON_LOCAL_TRAFFIC=true # enables agent to receive traces from other containers + - DD_AGENT_HOST=dd-agent # allows web container to forward traces to agent + - DD_SITE=datadoghq.com # determines datadog instance to send data to (e.g change to datadoghq.eu for EU1) + volumes: + - /var/run/docker.sock:/var/run/docker.sock + - /proc/:/host/proc/:ro + - /sys/fs/cgroup:/host/sys/fs/cgroup:ro +``` + +Remplacez `` par votre clé d'API. + +Les principaux changements dans l'exemple précédent sont la configuration de la variable d'environnement `DD_AGENT_HOST`, qui doit être identique pour votre conteneur `web` et votre conteneur d'Agent pour collecter les traces. `DD_APM_ENABLED` active l'APM et `DD_APM_NON_LOCAL_TRAFFIC` permet à l'Agent de recevoir des traces d'autres conteneurs. + +Cet exemple ajoute également la bibliothèque `ddtrace` au fichier `requirements.txt` de l'application Web Python afin que vous puissiez l'initialiser avec `ddtrace-run` pour activer l'APM. (La bibliothèque `datadog` mentionnée dans la liste suivante est utilisée pour collecter des métriques DogStatsD custom.) +``` +flask +redis +datadog +ddtrace <-- +``` + +Enfin, définissez les tags `service`, `env` et `version` pour votre application en modifiant le `Dockerfile` de l'application Web comme suit : + +```dockerfile +FROM python:2.7 +ADD . /code +WORKDIR /code +RUN pip install -r requirements.txt + +# This is where you set DD tags +ENV DD_SERVICE web <-- This sets the "service" name in Datadog +ENV DD_ENV sandbox <-- This sets the "env" name in Datadog +ENV DD_VERSION 1.0 <-- This sets the "version" number in Datadog +``` + +### Collecte de logs + +Le fichier `docker-compose.yml` peut être étendu pour permettre à lʼAgent Datadog de recueillir des logs de conteneur. + +```yaml +version: '3' +services: + redis: + image: redis + labels: + com.datadoghq.ad.logs: '[{"source": "redis", "service": "redis"}]' + datadog: + build: datadog + pid: host + environment: + - DD_API_KEY=${DD_API_KEY} + - DD_SITE={{< region-param key="dd_site" >}} + - DD_LOGS_ENABLED=true + volumes: + - /var/run/docker.sock:/var/run/docker.sock + - /proc/:/host/proc/:ro + - /sys/fs/cgroup:/host/sys/fs/cgroup:ro + - /var/lib/docker/containers:/var/lib/docker/containers:ro + - /opt/datadog-agent/run:/opt/datadog-agent/run:rw +``` + +**Remarque** : cette configuration collecte uniquement les logs du conteneur `Redis`. Vous pouvez collecter les logs de l'Agent Datadog en ajoutant une étiquette `com.datadoghq.ad.logs` similaire. Vous pouvez également activer explicitement la collecte de logs pour tous les conteneurs en définissant la variable d'environnement `DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL` sur `true`. Consultez la section [Collecte de logs Docker][5] pour plus de détails. + + +## Pour aller plus loin + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://docs.docker.com/compose/overview +[2]: /fr/agent/docker/ +[3]: https://github.com/DataDog/integrations-core/blob/master/redisdb/datadog_checks/redisdb/data/conf.yaml.example +[4]: https://github.com/DataDog/docker-compose-example +[5]: /fr/agent/logs/ \ No newline at end of file diff --git a/content/fr/containers/guide/container-discovery-management.md b/content/fr/containers/guide/container-discovery-management.md new file mode 100644 index 00000000000..e3c4cb6dfbe --- /dev/null +++ b/content/fr/containers/guide/container-discovery-management.md @@ -0,0 +1,576 @@ +--- +aliases: +- /fr/agent/autodiscovery/management +- /fr/agent/kubernetes/management +- /fr/agent/guide/autodiscovery-management +- /fr/containers/guide/autodiscovery-management +description: Contrôler les conteneurs que l'Agent Datadog surveille en configurant + des règles de découverte et des modèles d'inclusion/exclusion +further_reading: +- link: /containers/kubernetes/integrations/ + tag: Documentation + text: Configurer des intégrations avec Autodiscovery sur Kubernetes +- link: /containers/docker/integrations/ + tag: Documentation + text: Configurer des intégrations avec Autodiscovery sur Docker +title: Gestion de la découverte de conteneurs +--- + +Par défaut, l'Agent Datadog découvre automatiquement tous les conteneurs disponibles. Ce document décrit comment restreindre le périmètre de découverte de l'Agent Datadog et limiter la collecte de données à un sous-ensemble de conteneurs. + +## Modèles de découverte de conteneurs + +Dans un environnement conteneurisé, vous devez déployer l'Agent Datadog une fois par host. Chaque Agent Datadog déployé découvre et surveille automatiquement tous les conteneurs sur son host respectif. Lorsque l'option logs [`containerCollectAll`][1] est activée, l'Agent collecte les logs de tous les conteneurs découverts. + +Vous pouvez ajuster les règles de découverte de l'Agent pour restreindre la collecte de métriques et de logs. Tous les conteneurs exclus de la collecte de métriques sont également exclus pour toutes les intégrations d'Agent basées sur [Autodiscovery][2]. + +Vous pouvez définir des exceptions de deux manières : + +- Fournir des variables d'environnement au conteneur de l'Agent Datadog sous forme de liste d'autorisation/liste de blocage de conteneurs. Recommandé si vous disposez d'une liste de noms de conteneurs, d'images ou d'espaces de nommage à exclure pour l'ensemble du cluster. +- Ajouter des annotations à vos pods Kubernetes pour bloquer des pods ou des conteneurs individuels. Recommandé si vous avez besoin d'exclusions précises. + +**Remarque**: ces paramètres n'ont aucun effet sur les métriques `kubernetes.containers.running`, `kubernetes.pods.running`, `docker.containers.running`, `.stopped`, `.running.total` et `.stopped.total`, qui prennent en compte l'ensemble des conteneurs. + +## Correspondance de modèles simple + +Utilisez les variables d'environnement du tableau ci-dessous pour configurer le filtrage des conteneurs. Chaque inclusion ou exclusion est définie comme une liste de chaînes regex séparées par des espaces. Vous pouvez inclure ou exclure des conteneurs en fonction de leur : + +- nom de conteneur (`name`) +- nom d'image de conteneur (`image`) +- espace de nommage Kubernetes (`kube_namespace`) + +
+ +Le paramètre `name` s'applique uniquement aux noms de conteneurs, pas aux noms de pods, même si le conteneur s'exécute dans un pod Kubernetes. + +
+ +### Variables d'environnement + +Dans **Agent v7.20+**, utilisez les variables d'environnement suivantes pour exclure des conteneurs par nom d'image, nom de conteneur ou espace de nommage Kubernetes. Les logs et les métriques ne sont pas collectés à partir des conteneurs exclus. + +| Variable d'environnement | Description | +| ------------------------------ | --------------------------------------------------- | +| `DD_CONTAINER_EXCLUDE` | Liste de blocage des conteneurs à exclure. | +| `DD_CONTAINER_EXCLUDE_METRICS` | Liste de blocage des conteneurs dont les métriques sont exclues. | +| `DD_CONTAINER_EXCLUDE_LOGS` | Liste de blocage des conteneurs dont les logs sont exclus. | +| `DD_CONTAINER_INCLUDE` | Liste d'autorisation des conteneurs à inclure. | +| `DD_CONTAINER_INCLUDE_METRICS` | Liste d'autorisation des conteneurs dont les métriques sont incluses. | +| `DD_CONTAINER_INCLUDE_LOGS` | Liste d'autorisation des conteneurs dont les logs sont inclus. | + +{{% collapse-content title="Définir les variables d'environnement" level="h4" expanded=false id="setting-environment-variables" %}} + +{{< tabs >}} +{{% tab "Operator Datadog" %}} + +Dans le Datadog Operator, définissez ces variables d'environnement sous `spec.override.nodeAgent.env`. + +##### Exemple + +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + global: + credentials: + apiKey: + override: + nodeAgent: + env: + - name: DD_CONTAINER_EXCLUDE + value: "image:" +``` + +{{% /tab %}} +{{% tab "Helm" %}} + +Dans votre chart Helm, fournissez une chaîne séparée par des espaces à un ou plusieurs des éléments suivants : +- `datadog.containerExclude` +- `datadog.containerInclude` +- `datadog.containerExcludeLogs` +- `datadog.containerIncludeLogs` +- `datadog.containerExcludeMetrics` +- `datadog.containerIncludeMetrics` + +##### Exemple + +```yaml +datadog: + containerExclude: "image: image:" + containerInclude: "image: image:" +``` + +{{% /tab %}} +{{% tab "Agent conteneurisé" %}} + +Dans les environnements où vous n'utilisez pas le Datadog Operator ou Helm, les variables d'environnement suivantes peuvent être transmises au conteneur de l'Agent au démarrage. + +##### Exemple Docker + +```shell +docker run -e DD_CONTAINER_EXCLUDE=image: ... +``` + +##### Exemple ECS + +```json +"environment": [ + { + "name": "DD_CONTAINER_EXCLUDE", + "value": "image:" + }, + ... +] +``` + +{{% /tab %}} +{{< /tabs >}} + +{{% /collapse-content %}} + +
+ +Les filtres de nom d'image (`image`) sont mis en correspondance avec le nom d'image complet, y compris le registre et le tag ou le digest de l'image (par exemple, `dockerhub.io/nginx:1.13.1`). + +
+ +#### Exemples + +Pour exclure le conteneur portant le nom `dd-agent` : + +``` +DD_CONTAINER_EXCLUDE = "name:^dd-agent$" +``` + +Pour exclure les conteneurs utilisant l'image `dockercloud/network-daemon`, y compris tous les tags et digests : + +``` +DD_CONTAINER_EXCLUDE = "image:^dockercloud/network-daemon(@sha256)?:.* +``` + +Pour exclure les conteneurs utilisant l'image `dockercloud/network-daemon:1.13.0` : + +``` +DD_CONTAINER_EXCLUDE = "image:^dockercloud/network-daemon:1.13.0$" +``` + +Pour exclure tout conteneur dont l'image contient le mot `agent` : + +``` +DD_CONTAINER_EXCLUDE = "image:agent" +``` + +Pour exclure tout conteneur utilisant l'image `foo` quel que soit le registre : + +``` +DD_CONTAINER_EXCLUDE = "image:^.*/foo(@sha256)? :.*" +``` + +Pour exclure tous les conteneurs : + +``` +DD_CONTAINER_EXCLUDE = "name:.*" +``` + +Vous pouvez également utiliser `image:.*` ou `kube_namespace:.*`. La configuration de `.*` sans préfixe `name:`, `image:` ou `kube_namespace:` ne fonctionne pas. + +### Comportement d'inclusion et d'exclusion + +En général, l'inclusion a la priorité sur l'exclusion. Par exemple, pour surveiller uniquement les images `ubuntu` ou `debian`, excluez d'abord toutes les autres images, puis spécifiez les images à inclure : + +``` +DD_CONTAINER_EXCLUDE = "image:.*" +DD_CONTAINER_INCLUDE = "image:^docker.io/library/ubuntu(@sha256)?:.* image:^docker.io/library/debian(@sha256)?:.*" +``` + +La seule exception à cette règle concerne les annotations d'exclusion de pod comme `ad.datadoghq.com/exclude`. Lorsqu'une application a une annotation d'exclusion définie sur `true`, cela est prioritaire et le conteneur est exclu de la découverte automatique pour la surveillance. Par exemple, avoir une condition qui inclut tous les conteneurs comme `DD_CONTAINER_INCLUDE = "image:.*"` ne garantit pas qu'un conteneur est inclus s'il a une annotation d'exclusion définie. Consultez la section [Gestion de la découverte de conteneurs - Configuration d'exclusion de pod](#configuration-d-exclusion-de-pod) pour plus d'informations. + +Vous ne pouvez pas mélanger les règles d'inclusion/exclusion entre catégories. Par exemple, si vous souhaitez inclure un conteneur avec le nom d'image `foo` et exclure uniquement les métriques d'un conteneur avec le nom d'image `bar`, ce qui suit n'est **pas suffisant** : + +``` +DD_CONTAINER_EXCLUDE_METRICS = "image:^docker.io/library/bar(@sha256)?:.*" +DD_CONTAINER_INCLUDE = "image:^docker.io/library/foo(@sha256)?:.*" +``` + +Utilisez plutôt : + +``` +DD_CONTAINER_EXCLUDE_METRICS = "image:^docker.io/library/bar(@sha256)?:.*" +DD_CONTAINER_INCLUDE_METRICS = "image:^docker.io/library/foo(@sha256)?:.*" +DD_CONTAINER_INCLUDE_LOGS = "image:^docker.io/library/foo(@sha256)?:.*" +``` + +Il n'y a pas d'interaction entre les listes globales et les listes sélectives (logs et métriques). En d'autres termes, vous ne pouvez pas exclure un conteneur globalement (`DD_CONTAINER_EXCLUDE`), puis l'inclure avec `DD_CONTAINER_INCLUDE_LOGS` et `DD_CONTAINER_INCLUDE_METRICS`. + +### Conteneurs pause + +L'Agent Datadog exclut par défaut les conteneurs pause de Kubernetes et OpenShift. Cela empêche leur collecte de métriques et leur comptabilisation en tant que conteneurs facturables. Ils sont toujours comptés dans les métriques de nombre de conteneurs telles que `kubernetes.containers.running` et `docker.containers.running`. + +Pour désactiver ce comportement et inclure la surveillance des conteneurs pause : + +{{< tabs >}} +{{% tab "Operator Datadog" %}} + +Dans le Datadog Operator, définissez ces variables d'environnement sous `spec.override.nodeAgent.env`. + +##### Exemple + +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + global: + credentials: + apiKey: + override: + nodeAgent: + env: + - name: DD_EXCLUDE_PAUSE_CONTAINER + value: "false" +``` + +{{% /tab %}} +{{% tab "Helm" %}} + +Dans votre chart Helm, définissez `datadog.excludePauseContainer` sur `true` ou `false`. + +##### Exemple + +```yaml +datadog: + containerExclude: "image: image:" + containerInclude: "image: image:" + excludePauseContainer: false +``` + +{{% /tab %}} +{{% tab "Agent conteneurisé" %}} + +Dans les environnements où vous n'utilisez pas Helm ou l'opérateur, les variables d'environnement suivantes peuvent être transmises au conteneur de l'Agent au démarrage. + +Définissez `DD_EXCLUDE_PAUSE_CONTAINER` sur `false`. +{{% /tab %}} +{{< /tabs >}} + +## Exclusion CEL avancée + +Dans **Agent v7.73+**, vous pouvez utiliser l'option de configuration `cel_workload_exclude` pour filtrer les conteneurs d'Autodiscovery. Cette fonctionnalité vous permet de définir des règles [Common Expression Language][3] pour cibler les conteneurs à exclure de la collecte de données de télémétrie. + +Utilisez les attributs suivants pour représenter l'objet conteneur dans vos règles de filtrage : + +| Attribut | Description | +|-----------------------------|-------------------------------------------------------------------------| +| `container.name` | Nom du conteneur. | +| `container.image.reference` | Référence complète de l'image de conteneur (registre, référentiel, tag/digest). | +| `container.pod.name` | Nom du pod exécutant le conteneur. | +| `container.pod.namespace` | Espace de nommage Kubernetes du pod. | +| `container.pod.annotations` | Annotations appliquées au pod (mappage clé-valeur). | + +### Structure de configuration + +L'option de configuration `cel_workload_exclude` est structurée comme une liste d'ensembles de règles évalués comme des OU logiques, où un conteneur est exclu s'il correspond à une règle quelconque. Chaque ensemble de règles définit les `products` à exclure et les `rules` CEL correspondantes pour correspondre aux conteneurs. + +Le champ `products` accepte `metrics`, `logs` et `global` (exclure le conteneur de tous les produits répertoriés). + +
+Si la configuration contient des erreurs structurelles ou des problèmes de syntaxe CEL, l'Agent se ferme avec une erreur pour éviter de collecter des données de télémétrie non intentionnelles qui pourraient avoir un impact sur la facturation. +
+ +Dans l'exemple ci-dessous, les métriques et les logs sont exclus pour tout conteneur avec `nginx` dans son nom s'exécutant dans l'espace de nommage `staging`. De plus, les logs sont exclus pour tout conteneur exécutant l'image `redis`, OU tout conteneur dans un pod qui a l'annotation `low_priority: "true"`. Le [fichier de configuration de l'Agent][4] peut être directement mis à jour comme le montre cet exemple. + +```yaml +# datadog.yaml +cel_workload_exclude: +- products: [metrics, logs] + rules: + containers: + - container.name.matches("nginx") && container.pod.namespace == "staging" +- products: [logs] + rules: + containers: + - container.image.reference.matches("redis") + - container.pod.annotations["low_priority"] == "true" +``` + +L'exclusion de charge de travail basée sur CEL peut également être configurée en fournissant une valeur d'environnement au format JSON à `DD_CEL_WORKLOAD_EXCLUDE`. + +{{% collapse-content title="Définir les variables d'environnement" level="h4" expanded=false id="setting-environment-variables" %}} + +{{< tabs >}} +{{% tab "Operator Datadog" %}} + +Dans le Datadog Operator, définissez ces variables d'environnement sous `spec.override.nodeAgent.env`. + +##### Exemple + +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + global: + credentials: + apiKey: + override: + nodeAgent: + env: + - name: DD_CEL_WORKLOAD_EXCLUDE + value: > + [{"products":["global"],"rules":{"containers":["container.name == \"redis\""]}}] +``` + +{{% /tab %}} +{{% tab "Helm" %}} + +Dans votre chart Helm, utilisez l'option de configuration `datadog.celWorkloadExclude`. + +##### Exemple + +```yaml +datadog: + celWorkloadExclude: + - products: [global] + rules: + containers: + - container.name == "redis" +``` + +{{% /tab %}} +{{% tab "Agent conteneurisé" %}} + +Dans les environnements où vous n'utilisez pas Helm ou l'opérateur, les variables d'environnement suivantes peuvent être transmises au conteneur de l'Agent au démarrage. + +##### Exemple Docker + +```shell +docker run -e DD_CEL_WORKLOAD_EXCLUDE=... +``` + +##### Example ECS + +```json +"environment": [ + { + "name": "DD_CEL_WORKLOAD_EXCLUDE", + "value": "" + }, + ... +] +``` + +{{% /tab %}} +{{< /tabs >}} + +{{% /collapse-content %}} + +{{% collapse-content title="Valider l'option de configuration" level="h4" expanded=false id="validating-configuration-option" %}} + +Utilisez la commande `agent workloadfilter verify-cel` pour valider la syntaxe de votre configuration avant le déploiement. Elle accepte une entrée YAML ou JSON via stdin. L'exemple suivant montre la validation détectant une erreur de champ non défini : + +```json +### cel-config.json +[ + { + "products": ["metrics"], + "rules": + { + "containers": + [ + 'container.undefined_field == "test"', + 'container.name.startsWith("-agent")', + ], + }, + }, +] +``` + +```bash +agent workloadfilter verify-cel < cel-config.json + +-> Validating CEL Configuration + Loading YAML file... +✓ YAML loaded successfully (1 bundle(s)) + +-> Validating configuration structure... +✓ Configuration structure is valid + +-> Compiling CEL rules... + + -> metrics + Resource: container (2 rule(s)) + ✗ Compilation failed: ERROR: :1:10: undefined field 'undefined_field' + | container.undefined_field == "test" || container.name.startsWith("-agent") + | .........^ + Rule 1: container.undefined_field == "test" + Rule 2: container.name.startsWith("-agent") + +✗ Validation failed - some rules have errors +Error: CEL compilation failed +``` + +{{% /collapse-content %}} + +#### Exemples de règles + +Pour exclure le conteneur avec une annotation de pod spécifique : + +```yaml +container.pod.annotations["monitoring"] == "false" +``` + +Pour exclure le conteneur dans des espaces de nommage sans la sous-chaîne `-dev` : + +```yaml +!container.pod.namespace.matches("-dev") +``` + +Pour exclure le conteneur avec le nom `nginx-server` uniquement dans l'espace de nommage `prod` : + +```yaml +container.name == "nginx-server" && container.pod.namespace == "prod" +``` + +Pour exclure le conteneur exécutant une image avec la sous-chaîne `nginx` : + +```yaml +container.image.reference.matches("nginx") +``` + +Pour exclure le conteneur à l'aide d'une logique groupée (par exemple, un nom de conteneur spécifique dans l'un des deux espaces de nommage) : + +```yaml +container.name == "redis" && (container.pod.namespace == "production" || container.pod.namespace == "staging") +``` + +Pour exclure des conteneurs en fonction du nom du propriétaire de leur pod (par exemple, cibler tous les conteneurs créés par un Deployment ou un CronJob nommé `my-app`) : + +```yaml +container.pod.name.startsWith("my-app") +``` + +## Configuration d'exclusion de pod + +Dans **Agent v7.45+**, vous pouvez définir des annotations sur vos pods Kubernetes pour contrôler Autodiscovery. Définissez les annotations suivantes avec la valeur `"true"` pour ajouter des règles d'exclusion. + +| Annotation | Description | +| --------------------------------------------------- | -------------------------------------------------------------------------------- | +| `ad.datadoghq.com/exclude` | Exclure l'ensemble du pod | +| `ad.datadoghq.com/logs_exclude` | Exclure la collecte de logs de l'ensemble du pod | +| `ad.datadoghq.com/metrics_exclude` | Exclure la collecte de métriques de l'ensemble du pod | +| `ad.datadoghq.com/.exclude` | Exclure le conteneur avec `` dans le pod | +| `ad.datadoghq.com/.logs_exclude` | Exclure la collecte de logs du conteneur avec `` dans le pod | +| `ad.datadoghq.com/.metrics_exclude` | Exclure la collecte de métriques du conteneur avec `` dans le pod | + +L'annotation `ad.datadoghq.com/exclude` définie sur le pod d'application a la priorité la plus élevée. Cela signifie que même si un conteneur correspond à l'inclusion via `DD_CONTAINER_INCLUDE`, l'Agent ignore toujours la surveillance de ce conteneur. Il en va de même pour les configurations de filtrage respectives spécifiques aux métriques et aux logs. + +Lors de l'application d'exclusions basées sur des annotations, l'Agent vérifie toutes les annotations d'exclusion pertinentes sur le conteneur. Par exemple, lors de la configuration des logs pour un conteneur NGINX, l'Agent recherchera les annotations `ad.datadoghq.com/exclude`, `ad.datadoghq.com/logs_exclude`, `ad.datadoghq.com/nginx.exclude` ou `ad.datadoghq.com/nginx.logs_exclude` définies sur `true` sur le pod. Il en va de même pour les métriques. + +#### Exclure l'ensemble du pod + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: example +spec: + template: + metadata: + annotations: + ad.datadoghq.com/exclude: "true" + spec: + containers: + #(...) +``` + +#### Exclure la collecte de logs d'un conteneur + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: example +spec: + template: + metadata: + annotations: + ad.datadoghq.com/helper.logs_exclude: "true" + spec: + containers: + - name: app + #(...) + - name: helper + #(...) +``` + +### Tolérer les pods « unready » + +Par défaut, les pods `unready` sont ignorés lorsque l'Agent Datadog planifie des checks. Par conséquent, les métriques, les checks de service et les logs ne sont pas collectés à partir de ces pods. Pour remplacer ce comportement, définissez l'annotation `ad.datadoghq.com/tolerate-unready` sur `"true"`. Par exemple : + +```yaml +apiVersion: v1 +kind: Pod +# (...) +metadata: + name: '' + annotations: + ad.datadoghq.com/tolerate-unready: "true" + ... +``` + +## Configuration de sécurité + +Dans **Agent v7.70+**, vous pouvez restreindre la surveillance de sécurité pour des conteneurs spécifiques, de sorte que vous ne soyez facturé que pour les conteneurs que vous souhaitez surveiller. Cette fonctionnalité n'est pas prise en charge pour le Datadog Operator. + +{{< tabs >}} +{{% tab "Helm" %}} + +| Fonctionnalité | Inclure le conteneur | Exclure le conteneur | +|---------------------------------------|-----------------------------------------------------|-----------------------------------------------------| +| [Cloud Security Misconfigurations][1] | `datadog.securityAgent.compliance.containerInclude` | `datadog.securityAgent.compliance.containerExclude` | +| [Cloud Security Vulnerabilities][2] | `datadog.sbom.containerImage.containerInclude` | `datadog.sbom.containerImage.containerExclude` | +| [Workload Protection][3] | `datadog.securityAgent.runtime.containerInclude` | `datadog.securityAgent.runtime.containerExclude` | + +[1]: /fr/security/cloud_security_management/misconfigurations/ +[2]: /fr/security/cloud_security_management/vulnerabilities +[3]: /fr/security/workload_protection/ +{{% /tab %}} +{{% tab "Fichier de configuration" %}} +Pour [Cloud Security Vulnerabilities][1], vous pouvez utiliser le format suivant dans votre fichier de configuration pour inclure ou exclure des conteneurs : + +``` +--- +sbom: + container_image: + container_include: ... + container_exclude: ... +``` +[1]: /fr/security/cloud_security_management/vulnerabilities +{{% /tab %}} +{{% tab "Agent conteneurisé" %}} +Dans les environnements où vous n'utilisez pas Helm ou l'opérateur, les variables d'environnement suivantes peuvent être transmises au conteneur de l'Agent au démarrage. + +| Fonctionnalité | Inclure le conteneur | Exclure le conteneur | +|---------------------------------------|------------------------------------------------|------------------------------------------------| +| [Cloud Security Misconfigurations][1] | `DD_COMPLIANCE_CONFIG_CONTAINER_INCLUDE` | `DD_COMPLIANCE_CONFIG_CONTAINER_EXCLUDE` | +| [Cloud Security Vulnerabilities][2] | `DD_SBOM_CONTAINER_IMAGE_CONTAINER_INCLUDE` | `DD_SBOM_CONTAINER_IMAGE_CONTAINER_EXCLUDE` | +| [Workload Protection][3] | `DD_RUNTIME_SECURITY_CONFIG_CONTAINER_INCLUDE` | `DD_RUNTIME_SECURITY_CONFIG_CONTAINER_EXCLUDE` | + +[1]: /fr/security/cloud_security_management/misconfigurations/ +[2]: /fr/security/cloud_security_management/vulnerabilities +[3]: /fr/security/workload_protection/ +{{% /tab %}} +{{< /tabs >}} + +## Pour aller plus loin + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /fr/containers/kubernetes/log/?tab=helm#log-collection +[2]: /fr/getting_started/containers/autodiscovery +[3]: https://github.com/google/cel-spec/blob/master/doc/langdef.md +[4]: /fr/agent/configuration/agent-configuration-files/#agent-main-configuration-file \ No newline at end of file diff --git a/content/ja/metrics/custom_metrics/dogstatsd_metrics_submission.md b/content/ja/metrics/custom_metrics/dogstatsd_metrics_submission.md index ea856c3bd93..f72b9c2b7e8 100644 --- a/content/ja/metrics/custom_metrics/dogstatsd_metrics_submission.md +++ b/content/ja/metrics/custom_metrics/dogstatsd_metrics_submission.md @@ -32,17 +32,18 @@ StatsD がメトリクスのみを受け付けるのに対して、DogStatsD は | `` | Double | はい | メトリクスに関連付けられている値 | | `` | Double | いいえ | メトリクスに適用するサンプリングレート。`0`（全てがサンプリングされ何も送信されない）〜`1` （サンプル無し）の値を利用。詳細は、[サンプリングレートセクション](#sample-rates)をご覧ください。 | | `<タグ>` | 文字列のリスト | いいえ | メトリクスに適用するタグのリスト。詳細は、[メトリクスのタグ付け](#metric-tagging)セクションをご覧ください。 | +| `` | 列挙 | No | このメトリクスに割り当てるタグの[カーディナリティ][10] | ### COUNT -`increment(, , )` +`increment(, , , )` : COUNT メトリクスをインクリメントするために使用されます。Datadog に `RATE` タイプとして保存されます。時系列に保存される値は、StatsD フラッシュ期間全体のメトリクス値の時間正規化された差分です。 -`decrement(, , )` +`decrement(, , , )` : COUNT メトリクスをデクリメントするために使用されます。Datadog に `RATE` タイプとして保存されます。時系列に保存される値は、StatsD フラッシュ期間全体のメトリクス値の時間正規化された差分です。 -`count(, , , )` -: 任意の `Value` から COUNT メトリクスをインクリメントするために使用されます。Datadog に `RATE` タイプとして保存されます。時系列に保存される値は、StatsD フラッシュ期間全体のメトリクス値の時間正規化された差分です。 +`count(, , , , )` +: 任意の `Value` を指定して COUNT メトリクスをインクリメントするために使用されます。Datadog に `RATE` タイプとして保存されます。時系列に保存される値は、StatsD フラッシュ期間全体のメトリクス値の時間正規化された差分です。 **注**: `COUNT` タイプのメトリクスは、フラッシュ間隔で正規化され 1 秒あたりの単位数を報告するため、Datadog 内で少数を表示できます。 @@ -100,7 +101,7 @@ import ( "log" "time" - "github.com/DataDog/datadog-go/statsd" + "github.com/DataDog/datadog-go/v5/statsd" ) func main() { @@ -168,8 +169,8 @@ public class DogStatsdClient while (true) { - dogStatsdService.Increment("example_metric.increment", tags: new[] {"environment:dev"}); - dogStatsdService.Decrement("example_metric.decrement", tags: new[] {"environment:dev"}); + dogStatsdService.Increment("example_metric.increment", tags: new[] {"environment:dev"}, cardinality: Cardinality.Low); + dogStatsdService.Decrement("example_metric.decrement", tags: new[] {"environment:dev"}, cardinality: Cardinality.High); dogStatsdService.Counter("example_metric.count", 2, tags: new[] {"environment:dev"}); System.Threading.Thread.Sleep(random.Next(100000)); } @@ -194,8 +195,8 @@ $statsd = new DogStatsd( ); while (TRUE) { - $statsd->increment('example_metric.increment', 1, array('environment'=>'dev')); - $statsd->decrement('example_metric.decrement', 1, array('environment'=>'dev')); + $statsd->increment('example_metric.increment', 1, array('environment'=>'dev'), 'low'); + $statsd->decrement('example_metric.decrement', 1, array('environment'=>'dev'), 'high'); sleep(10); } ``` @@ -223,8 +224,8 @@ tracer.dogstatsd.decrement('example_metric.decrement', 1, { environment: 'dev' } ### GAUGE -`gauge(, , , )` -: Datadog に `GAUGE` タイプとして保存されます。時系列に保存される値は、StatsD フラッシュ期間の間にメトリクスに送信された最後のゲージ値です。 +`gauge(, , , , )` +: Datadog に `GAUGE` タイプとして保存されます。時系列に保存される値は、StatsD フラッシュ期間中にそのメトリクスに対して StatsD に送信された最後のゲージ値です。 #### コード例 @@ -252,7 +253,7 @@ i = 0 while(1): i += 1 - statsd.gauge('example_metric.gauge', i, tags=["environment:dev"]) + statsd.gauge('example_metric.gauge', i, tags=["environment:dev"], cardinality="low") time.sleep(10) ``` {{< /programming-lang >}} @@ -267,7 +268,7 @@ i = 0 while true do i += 1 - statsd.gauge('example_metric.gauge', i, tags: ['environment:dev']) + statsd.gauge('example_metric.gauge', i, tags: ['environment:dev'], cardinality: 'low') sleep 10 end ``` @@ -281,7 +282,7 @@ import ( "log" "time" - "github.com/DataDog/datadog-go/statsd" + "github.com/DataDog/datadog-go/v5/statsd" ) func main() { @@ -292,7 +293,7 @@ func main() { var i float64 for true { i += 1 - statsd.Gauge("example_metric.gauge", i, []string{"environment:dev"}, 1) + statsd.Gauge("example_metric.gauge", i, []string{"environment:dev"}, 1, CardinalityHigh) time.Sleep(10 * time.Second) } } @@ -346,7 +347,7 @@ public class DogStatsdClient for (int i = 0; true; i++) { - dogStatsdService.Gauge("example_metric.gauge", i, tags: new[] {"environment:dev"}); + dogStatsdService.Gauge("example_metric.gauge", i, tags: new[] {"environment:dev"}, cardinality: Cardinality.High); System.Threading.Thread.Sleep(100000); } } @@ -372,7 +373,7 @@ $statsd = new DogStatsd( $i = 0; while (TRUE) { $i++; - $statsd->gauge('example_metric.gauge', $i, array('environment'=>'dev')); + $statsd->gauge('example_metric.gauge', $i, array('environment'=>'dev'), 'low'); sleep(10); } ``` @@ -399,8 +400,8 @@ while(true) { ### SET -`set(, , , )` -: Datadog に `GAUGE` タイプとして保存されます。時系列に保存される値は、フラッシュ期間の間に StatsD に送信されたメトリクスの一意の値のカウントです。 +`set(, , , , )` +: Datadog に `GAUGE` タイプとして保存されます。時系列に保存される値は、フラッシュ期間中に StatsD に送信されたメトリクスの一意の値のカウントです。 #### コード例 @@ -455,7 +456,7 @@ import ( "math/rand" "time" - "github.com/DataDog/datadog-go/statsd" + "github.com/DataDog/datadog-go/v5/statsd" ) func main() { @@ -547,7 +548,7 @@ $i = 0; while (TRUE) { $i++; - $statsd->set('example_metric.set', $i, array('environment'=>'dev')); + $statsd->set('example_metric.set', $i, 1, array('environment'=>'dev'), 'low'); sleep(rand(0, 10)); } ``` @@ -560,10 +561,10 @@ while (TRUE) { ### HISTOGRAM -`histogram(, , , )` -: 複数のメトリクスが送信されるので、保存されるメトリクスタイプ (`GAUGE`, `RATE`) はメトリクスに依存します。詳細については、[ヒストグラムメトリクスタイプ][6]に関するドキュメントを参照してください。 +`histogram(, , , , )` +: 複数のメトリクスが送信されるため、保存されるメトリクス タイプ (`GAUGE`, `RATE`) はメトリクスによって異なります。詳細については、[HISTOGRAM メトリクス タイプ][6]のドキュメントを参照してください。 -#### 構成 +#### 設定 * Datadog に送信する集計を、[datadog.yaml 構成ファイル][7]の `histogram_aggregates` パラメーターで構成します。デフォルトでは、`max`、`median`、`avg`、`count` の各集計だけが送信されます。 * Datadog に送信するパーセンタイル集計を、[datadog.yaml 構成ファイル][7]の `histogram_percentiles` パラメーターで構成します。デフォルトでは、`95pc` のパーセンタイルだけが送信されます。 @@ -618,7 +619,7 @@ import ( "math/rand" "time" - "github.com/DataDog/datadog-go/statsd" + "github.com/DataDog/datadog-go/v5/statsd" ) func main() { @@ -682,7 +683,7 @@ public class DogStatsdClient while (true) { - dogStatsdService.Histogram("example_metric.histogram", random.Next(20), tags: new[] {"environment:dev"}); + dogStatsdService.Histogram("example_metric.histogram", random.Next(20), tags: new[] {"environment:dev"}, Cardinality: Cardinality.High); System.Threading.Thread.Sleep(2000); } } @@ -706,7 +707,7 @@ $statsd = new DogStatsd( ); while (TRUE) { - $statsd->histogram('example_metric.histogram', rand(0, 20), array('environment'=>'dev')); + $statsd->histogram('example_metric.histogram', rand(0, 20), 1, array('environment'=>'dev'), 'low'); sleep(2); } ``` @@ -716,7 +717,7 @@ while (TRUE) { 上のインスツルメンテーションは、以下のメトリクスを生成します。 -| メトリクス | 説明 | +| メトリクス | Description | |-----------------------------------------|-----------------------------------------| | `example_metric.histogram.count` | このメトリクスがサンプリングされた回数 | | `example_metric.histogram.avg` | サンプリングされた値の平均 | @@ -732,10 +733,10 @@ while (TRUE) { DogStatsD の `TIMER` メトリクスタイプは `HISTOGRAM` メトリクスタイプとして実装されています（標準 StatsD に含まれるタイマーと混同しないでください）。また、コードセクションの実行にかかる時間など、タイミングデータのみを測定します。 -`timed(, , , )` -: 複数のメトリクスが送信されるので、保存されるメトリクスタイプ (`GAUGE`, `RATE`) はメトリクスに依存します。詳細については、[ヒストグラムメトリクスタイプ][6]に関するドキュメントを参照してください。 +`timed(, , , , )` +: 複数のメトリクスが送信されるため、保存されるメトリクス タイプ (`GAUGE`, `RATE`) はメトリクスによって異なります。詳細については、[HISTOGRAM メトリクス タイプ][6]のドキュメントを参照してください。 -##### 構成 +##### 設定 `TIMER` には、`HISTOGRAM` [コンフィギュレーション](#configuration)ルールが適用されます。 @@ -821,7 +822,7 @@ while (TRUE) { DogStatsD はタイマーメトリクスデータを受け取ると、レンダリング時間の統計的分布を計算し、次のメトリクスを Datadog に送信します。 -| メトリクス | 説明 | +| メトリクス | Description | |-------------------------------------|-----------------------------------------| | `example_metric.timer.count` | このメトリクスがサンプリングされた回数 | | `example_metric.timer.avg` | サンプリングされた値の平均時間 | @@ -835,8 +836,8 @@ DogStatsD は `TIMER` を `HISTOGRAM` メトリクスとして扱います。使 ### DISTRIBUTION -`distribution(, , )` -: Datadog に `DISTRIBUTION` タイプとして保存されます。詳細は、[ディストリビューションドキュメント][8]を参照してください。 +`distribution(, , , )` +: Datadog に `DISTRIBUTION` タイプとして保存されます。詳細は、[ディストリビューションに関するドキュメント][8]を参照してください。 #### コード例 @@ -887,7 +888,7 @@ import ( "math/rand" "time" - "github.com/DataDog/datadog-go/statsd" + "github.com/DataDog/datadog-go/v5/statsd" ) func main() { @@ -975,7 +976,7 @@ $statsd = new DogStatsd( ); while (TRUE) { - $statsd->distribution('example_metric.distribution', rand(0, 20), array('environment'=>'dev')); + $statsd->distribution('example_metric.distribution', rand(0, 20), 1, array('environment'=>'dev'), 'high'); sleep(2); } ``` @@ -1104,13 +1105,13 @@ dogStatsdService.Increment("example_metric.increment", tags: new[] {"environment `tags` 引数は文字列にすることができます。 ```php -$statsd->increment('example_metric.increment', "environment:dev,account:local"); +$statsd->increment('example_metric.increment', 1.0, "environment:dev,account:local"); ``` または配列にすることができます。 ```php increment('example_metric.increment', array('environment' => 'dev', 'account' => 'local')); +$statsd->increment('example_metric.increment', 1.0, array('environment' => 'dev', 'account' => 'local')); ``` {{< /programming-lang >}} @@ -1126,7 +1127,7 @@ tracer.dogstatsd.increment('example_metric.increment', 1, { environment: 'dev', ホストタグは、メトリクスを集計する際に Datadog Agent によって自動的に割り当てられます。Agent ホスト名と一致しないホストタグ付きで送信されたメトリクスは、本来のホストを参照できなくなります。送信されたホストタグは、Agent によって収集されたホスト名や Agent で構成されたホスト名を上書きします。 -## 参考資料 +## 関連情報 {{< partial name="whats-next/whats-next.html" >}} @@ -1138,4 +1139,5 @@ tracer.dogstatsd.increment('example_metric.increment', 1, { environment: 'dev', [6]: /ja/metrics/types/?tab=histogram#definition [7]: /ja/agent/configuration/agent-configuration-files/#agent-main-configuration-file [8]: /ja/metrics/distributions/ -[9]: /ja/metrics/types/?tab=distribution#definition \ No newline at end of file +[9]: /ja/metrics/types/?tab=distribution#definition +[10]: /ja/containers/kubernetes/tag \ No newline at end of file diff --git a/content/ja/security/code_security/static_analysis/custom_rules/guide.md b/content/ja/security/code_security/static_analysis/custom_rules/guide.md new file mode 100644 index 00000000000..a02d06f6186 --- /dev/null +++ b/content/ja/security/code_security/static_analysis/custom_rules/guide.md @@ -0,0 +1,743 @@ +--- +description: Datadog 用のカスタム ルールを作成するための完全ガイド。 +title: 静的コード解析カスタム ルール ガイド +--- + +このガイドでは、[静的解析カスタム ルール チュートリアル][1]をベースに、カスタム ルールの作成方法を網羅的に説明し、ヒントやコツ、回避すべき一般的な落とし穴も紹介します。 + +## 概要 + +静的解析ツールのルールは、次の 3 つの要素で構成されます: 該当するコード構造を見つけるための Tree-sitter クエリ、コードを解析して診断結果を生成する JavaScript 関数、ルールが正しく動作することを検証するテスト。 + +静的解析を実行する際、解析ツールはコード リポジトリ内の各ファイルを取り出し、ファイル名の拡張子をチェックしてその言語を判断し、Tree Sitter でファイルを解析してから、その言語向けのルールを実行します。 + +ルールを実行するために、解析ツールは、ルールによって提供される [Tree Sitter クエリ][3]を使用して、生成された構文木をクエリします。これにより、ゼロ個以上の Tree Sitter ノードが生成されます。次に、解析ツールは各ノードに対して、ルールの JavaScript コードから `visit()` 関数を実行します。この関数は、`addError()` を呼び出して、そのルールに対する診断結果を生成することができます。 + +## Tree Sitter クエリ + +クエリにはパターンが 1 つ以上含まれており、各パターンはマッチさせるノードの形状を宣言する式となっています。クエリ エンジンは構文木を走査してパターンに一致するノードを探し、出現箇所ごとに返します。 + +### ノード パターン + +基本的なパターンは、ノード タイプが括弧で囲まれた構成になっています。このパターンは、そのタイプに属するすべてのノードにマッチします。 + +次の例は、`func-decl` タイプのノードにマッチするクエリを示しています。 + +```scheme +(func-decl) +``` + +ノード タイプの後ろ、閉じ括弧の前の部分にパターンを追加できます。そのような形で指定したパターンは、それらのパターンに一致する子を持つノードにマッチします。 + +```scheme +(func-decl (arg-list) (body)) +``` + +この例は、`arg-list` タイプのノードを含み、その後に `body` タイプのノードが続く (間に別のノードが入る場合もあり)、`func-decl` タイプのノードにマッチします。次の構文木の場合、このクエリは青で囲まれたサブ ツリーにはマッチしますが、オレンジで囲まれたサブ ツリーにはマッチしません。 + +{{< img src="/security/code_security/custom_rule_guide_parse_trees.png" alt="2 つの一致箇所がハイライト表示された構文木の例。" style="height:20em;" >}} + +子パターンは必要なだけ入れ子にすることができます。 + +```scheme +(func-decl + (arg-list + (argument) + ) + (body + (statement + (function-call) + ) + ) +) +``` + +ご覧のように、Tree Sitter クエリにはスペースや改行を追加することができます。これらを調整することで、クエリを読みやすい形にすることができます。また、セミコロンの後にコメントを追加することができ、行末までがコメントとして認識されます。 + +```scheme +; 上の例を別の形式で表現する方法 +(func-decl + (arg-list (argument)) ; arg-list に引数が 1 つ以上含まれる + (body + (statement (function-call)) ; body に関数の呼び出しが含まれる + ) +) +``` + +ピリオド (`.`) を使用すると、2 つの兄弟ノードが続けて出現しなければならないことを指定できます。ピリオドがない場合は、間に他のノードがあってもマッチします。また、ピリオドを使用して、ノードが最初または最後の子でなければならないことを指定することもできます。 + +```scheme +(func-decl (arg-list) . (body)) +; `func-decl` に `arg-list` が含まれ、その直後に `body` が続く。 + +(func-decl . (body)) +; `func-decl` の最初の子ノードは `body` である。 + +(func-decl (return-type) . ) +; `func-decl` の最後の子ノードは `return-type` である。 +``` + +一部のノードにはフィールドがあり、フィールド名、コロン、そしてフィールドの内容のパターンを指定することでマッチさせることができます。 + +```scheme +(unary-operator + operand: (identifier)) +; `operand` フィールドに `identifier` を含む +; `unary-operator` ノードにマッチします。 +``` + +また、感嘆符 (`!`) に続けてフィールド名を指定することで、フィールドを持たないノードにマッチさせることもできます。 + +```scheme +(if-statement + !else) +; `else` フィールドを持たない `if-statement` にマッチします。 +``` + +ここまで見てきたのは「名前付きノード」で、これはタイプを持つノードのことです。Tree Sitter は構文木に「匿名ノード」も追加します。匿名ノードはタイプを持たず、多くの場合、構文要素を含んでいます。たとえば、「`+`」や「`/`」などの演算子、括弧、コロンなどです。 + +二重引用符で囲んでそのテキストを指定すれば、匿名ノードにマッチさせることができます。 + +```scheme +(binary-operation + (identifier) + "+" + (binary-operation) +) +; `identifier`、`+` トークン、および別の `binary-operation` を含む +; `binary-operation` ノードにマッチします。 +``` + +### ワイルドカード + +アンダースコア (`_`) はワイルド カードとして使用できます。アンダースコア単体では、名前付きか匿名かにかかわらず、どのノードもマッチします。ノード名としてアンダースコアを指定すると、名前付きノードはマッチしますが、匿名ノードはマッチしません。 + +```scheme +(binary-operation . (_) "+" (identifier) . ) +; 最初の子ノードが任意のタイプの名前付きノードである +; `binary-operation` ノードにマッチします。 + +(binary-operation . (identifier) _ (identifier) . ) +; 中央の子ノードが匿名または名前付きの任意のノードである +; `binary-operation` ノードにマッチします。 + +(_ . (identifier) "+" (identifier) . ) +; `identifier`、`+` の匿名ノード、および別の `identifier` を含む +; 任意のタイプの名前付きノードにマッチします。 +``` + +### 代替テクノロジー + +Tree Sitter クエリの一番上の階層で複数のパターンを指定した場合、クエリはいずれかのパターンに一致するノードを検索します。 + +```scheme +(program) +(module) +; タイプが `program` または `module` のノードにマッチします +``` + +子ノードの代替一致条件を指定したい場合は、代替パターンを角括弧 (`[]`) で囲みます。代替パターンは間にカンマを挟まずに並べることに注意してください。 + +```scheme +(func-decl + [ + (func-prototype) + (func-definition) + ] +) +; タイプが `func-decl` で、子のタイプが `func-prototype` または +; `func-definition` のノードにマッチします。 +``` + +ノードが複数の代替パターンに合致する子ノードを含む場合、クエリ エンジンはマッチする代替パターンごとに 1 つの結果を返します。1 つのクエリ内で複数の階層において代替パターンが指定されている場合、クエリ エンジンはすべての代替パターンの組み合わせに対して一致する結果を返すため、組み合わせ爆発が発生する可能性があります。その結果、静的解析の実行に時間がかかり、ルールがタイムアウトする可能性があります。 + +### キャプチャ + +マッチしたノードを「キャプチャ」して、ルールの JavaScript コードで利用できるようにしたり、述語で使用したりすることができます (後述)。ノードをキャプチャするには、キャプチャしたいパターンの後にアット マーク (`@`) とキャプチャ名を付けます。 + +```scheme +(binary-operation + (identifier) @id + "+" @op + _ @operand +) @operation +; `identifier` (`id` としてキャプチャ)、`+` を含む匿名ノード (`op` としてキャプチャ)、 +; その他の任意の子ノード (`operand` としてキャプチャ) を含む +; `binary-operation` ノード (`operation` という名前でキャプチャ) にマッチします。 +``` + +### オプション一致と反復一致 + +ノードのパターンの後に疑問符 (`?`) 修飾子を指定することで、そのノードがオプションで出現する可能性があることを示すことができます。 + +```scheme +(exit-statement + (integer)? +) +; オプションの `integer` ノードを含む `exit-statement` ノードにマッチします。 +``` + +オプションのノードをキャプチャすることができます。ノードが存在しない場合、キャプチャは空になります。 + +```scheme +(exit-statement + (integer)? @retCode +) +; `integer` が存在する場合、`retCode` にはノードが格納されます。 +; それ以外の場合は空になります。 +``` + +ノードのパターンの後にアスタリスク (`*`) 修飾子を指定することで、そのノードがゼロ回以上出現する可能性があることを示すことができます。 + +```scheme +(list + _* @items +) +; ゼロ個以上の子ノードを持つ `list` ノードにマッチし、それらを `items` としてキャプチャします。 +``` + +ご覧のように、これらの修飾子はキャプチャと組み合わせると最も有用です。子ノードをキャプチャする必要がなければ、上記のクエリは単に `(list)` と書き換えられます。 + +ノードのパターンの後にプラス記号 (`+`) 修飾子を指定することで、そのノードが 1 回以上出現しなければならないことを示すことができます。 + +```scheme +(array-index + (integer)+ @indices +) +; `integer` ノードを 1 つ以上含む `array-index` ノードにマッチし、 +; それらを `indices` としてキャプチャします。 +``` + +これらの修飾子はパターンのグループにも適用できます。その場合は、グループを括弧で囲み、閉じ括弧の後に修飾子を適用します。 + +```scheme +(array-dimensions + (integer) + ("," integer)* +) +; `integer` ノードが含まれ、その後にカンマ区切りで `integer` ノードが +; ゼロ回以上続く `array-dimensions` ノードにマッチします。 +``` + +この 3 つの修飾子の違いは微妙でわかりにくいかもしれないので、別の視点からもう一度見てみましょう。 + +* 「`?`」と「`*`」の違いは、パターンに合致する反復ノードがある場合、「`*`」はすべての反復を含む単一の結果を生成する一方、「`?`」は反復ごとに 1 つの結果を生成することです。 + +たとえば、`list` ノードに 5 つの子ノードがある場合、パターン「`(list _?)`」は 5 つの結果を別々に (各子ノードに対して 1 つずつ) 生成しますが、パターン「`(list _*)`」は子ノードのリスト全体に対して 1 つの結果を生成します。 + +* 「`*`」と「`+`」の違いは、マッチするノードがない場合、「`*`」のパターンは結果を返す一方、「`+`」のパターンは結果を返さないことです。 + +たとえば、構文木に子ノードを持たない `list` ノードがあった場合、パターン「`(list _*)`」は 1 つの結果を生成し、パターン「`(list _+)`」が生成する結果はゼロになります。 + +### 述語 + +ノードがマッチするために満たすべき追加の条件を指定できます。これらの条件は、パターンの括弧内に述語の形で追加して表現します。 + +```scheme +(binary-operator + (identifier) @id + (#match? @id "[a-z]+([A-Z][a-z]*)*") +) +; `identifier` ノードを含み、その内容が指定された正規表現に一致する +; `binary-operator` ノードにマッチします。 +``` + +述語は `(#pred? arg1 arg2)` の形式を持ち、`#pred?` は述語の名前、`arg1` はキャプチャ、`arg2` は別のキャプチャまたは文字列となります。 + +```scheme +(assign-statement + left: _ @target + right: _ @source + (#eq? @target @source) +) +; `left` と `right` のフィールドが等しい `assign-statement` ノードにマッチします。 +``` + +以下は一般的な述語の例です。 + +* `#eq?`、`#not-eq?` --- キャプチャが第 2 引数と等しい／等しくない。 +* `#match?`、`#not-match?` --- キャプチャが第 2 引数で指定された正規表現に一致する／一致しない。 + +キャプチャに複数のノードが含まれる場合 (たとえば、修飾子 `*` または `?` を使用した場合)、以下の述語を使用できます。 + +* `#any-eq?`、`#any-not-eq?` --- キャプチャされたノードのいずれかが第 2 引数と等しい／等しくない。 +* `#any-match?`、`#any-not-match?` --- キャプチャされたノードのいずれかが、第 2 引数で指定された正規表現に一致する／一致しない。 + +```scheme +(array-index + (identifier)* @ids + (#any-eq? @ids "exit") +) +; 内容が "exit" である `identifier` 子ノードを含む `array-index` ノードに +; マッチします。 +``` + +引数が複数の値のいずれかと等しいかどうかをチェックしたい場合は、そのための述語も用意されています。 + +* `#any-of?`、`#not-any-of?` --- キャプチャが第 2 引数、第 3 引数、第 4 引数...のいずれかと等しい／等しくない。 + +```scheme +(function-call + name: _ @fn + (#any-of? @fn "system" "exit" "quit") +) +; `name` フィールドが "system"、"exit"、"quit" のいずれかと等しい +; `function-call` ノードにマッチします。 +``` + +## JavaScript のコード + +ルールの JavaScript コードは、通常次のような形になります。 + +```javascript +function visit(query, filename, code) { + const { cap1, cap2, cap3 } = query.captures; + const { cap4, cap5, cap6 } = query.capturesList; + /* キャプチャされたノードをチェック */ + const err = /* 診断結果についてのメッセージを生成 */; + addError(err); +} +``` + +### `visit()` 関数 + +クエリの実行後、静的解析ツールはマッチした各結果に対して `visit()` 関数を実行します。この関数は 3 つの引数を受け取ります。 + +* `query` --- 現在のマッチに関する情報。 +* `filename` --- 解析対象のファイル名。 +* `code` --- 解析対象ファイルの内容。 + +引数の `filename` と `code` は文字列ですが、`query` は以下のプロパティを含むオブジェクトです。 + +* `captures` --- クエリによってキャプチャされたノードを格納するオブジェクトで、キャプチャ名がキーになります。キャプチャに複数のノードが格納されている場合、最初のノードだけがここに表示されます。 +* `capturesList` --- `captures` に似ていますが、同じ名前でキャプチャされたすべてのノードのリストが含まれます。修飾子 `+` および `*` を使った反復ノードのキャプチャに適しています。 + +たとえば、次のようなクエリの場合 + +```scheme +(var-assignment + left: (identifier)+ @ids + right: _ @expr +) @assignment +``` + +引数 `query` には次のような情報が格納されます。 + +```javascript +query = { + captures: { + ids: /* `left` フィールドの 1 つ目の `identifier` ノード */, + expr: /* `right` フィールドのノード */ + }, + capturesList: { + ids: [ + /* `left` の 1 つ目の `identifier` ノード */, + /* `left` の 2 つ目の `identifier` ノード */, + /* 以下同様 */ + ], + expr: [ + /* `right` フィールドのノード */ + ] + } +} +``` + +### キャプチャの使い方 + +キャプチャ名は、オブジェクト `query.captures` および `query.capturesList` のキーとして使用されます。JavaScript の変数名と互換性のある名前をキャプチャに割り当てれば、キャプチャを簡単に取り出すことができます。 + +```javascript +const { id, expr, node } = query.captures; +``` + +上記のコードでは、`query.captures` からプロパティ `id`、`expr`、`node` を抽出し、同じ名前の定数に割り当てています。 + +キャプチャ名が JavaScript の変数名と互換性がない場合でも抽出することはできますが、使い勝手が少し悪くなります。 + +```javascript +const id = query.captures["id-node"]; +const expr = query.captures["20394"]; +``` + +キャプチャされたノードは、以下のプロパティを含むオブジェクトで表されます。 + +* `cstType` --- ノードのタイプ。 +* `start` --- ソース コード中のノードの開始位置を格納するオブジェクト。 +* `end` --- ノードの末尾に続く文字の位置を格納するオブジェクト。 +* `text` --- ノードの内容。 + +`start` および `end` プロパティは、`line` および `col` プロパティを含むオブジェクトです。これらのプロパティは 1 が基準になっており、ファイルの最初の行および行の最初の列が 1 番になります。`start` プロパティの位置は包含的で、ノードの最初の文字を指します。`end` プロパティの位置は排他的で、ノードの後の最初の文字を指します。 + +`start` および `end` プロパティを使用して、ノードの長さや 2 つのノードの相対位置を確認できます。たとえば、あるノードの `start` プロパティと `end` プロパティの値が同じ場合、それは空のノードです。あるノードの `end` プロパティの値と別のノードの `start` プロパティの値が同じ場合、その 2 つのノードは連続しています。 + +(古いコードに関する注意: `cstType` の代わりに `astType` プロパティを使用しているルールを見かけるかもしれません。これは古いルールで、`cstType` を使用すべきです。また、`node.text` の代わりに、`getCodeForNode(node, code)` や `getCodeForNode(node)` を使用しているルールを見かけるかもしれませんが、`node.text` を使用すべきです。) + +### 構文木のナビゲーション + +`ddsa.getParent(node)` 関数と `ddsa.getChildren(node)` 関数を使用すると、それぞれノードの親と子を取得できます。 + +```javascript +function visit(query, filename, code) { + const { funcDecl } = query.captures; + const parent = ddsa.getParent(funcDecl); + // `funcDecl` ノードの親ノードを使って何らかの処理を行う + const children = ddsa.getChildren(funcDecl); + for (let child of children) { + // `funcDecl` ノードの子ノードを使って何らかの処理を行う + } +} +``` + +これらの関数によって返されたノードに対して `ddsa.getParent(node)` と `ddsa.getChildren(node)` を呼び出し続ければ、構文木を探索できます。ルート ノードで `ddsa.getParent()` を呼び出すと `undefined` が返され、リーフ ノードで `ddsa.getChildren()` を呼び出すと空のリストが返されます。 + +```javascript +function visit(query, filename, code) { + const { funcDecl } = query.captures; + let root = getRoot(funcDecl); + // これで `root` に構文木のルートが格納されます + displayLeaves(root); +} + +function getRoot(node) { + let parent = ddsa.getParent(node); + while (parent) { + node = parent; + parent = ddsa.getParent(node); + } + return node; +} + +function displayLeaves(node) { + let children = ddsa.getChildren(root); + if (children.length == 0) console.log(node); + for (let child of children) { + displayLeaves(child); + } +} +``` + +フィールドを持つノードで `ddsa.getChildren(node)` を呼び出すと、それらのフィールドに格納されたノードは子ノードとして返され、`fieldName` プロパティが追加されます。 + +```javascript +// `if_statement` ノードの `then`、`else` フィールドの内容を取得します。 +let children = ddsa.getChildren(ifStatementNode); +let thenField = children.find(n => n.fieldName === 'then'); +let elseField = children.find(n => n.fieldName === 'else'); +``` + +`==` を使えば、2 つのノード オブジェクトを比較して、同じノードを指しているかどうかを確認できます。 + +```javascript +function visit(query, filename, code) { + const { funcDecl } = query.captures; + displaySiblings(funcDecl); +} + +// このノードのすべての兄弟を出力 (このノード自体はカウントしない) +function displaySiblings(node) { + let parent = ddsa.getParent(node); + if (!parent) return; + let allSiblings = ddsa.getChildren(parent); + for (let sibling of allSiblings) { + if (sibling != node) console.log(sibling); + } +} +``` + +### 診断結果の報告と提案 + +ユーザーに診断結果を報告するには、`addError()` 関数を使用します。`addError()` は `Violation` オブジェクトを受け取ります。この `Violation` オブジェクトは `buildError()` 関数で構築できます。`buildError()` は `startLine`、`startCol`、`endLine`、`endCol`、`message` の 5 つの引数を取ります。一般的には、ノードの `start` および `end` プロパティを使用して、最初の 4 つの引数の値を取得します。 + +```javascript +function visit(query, filename, code) { + const { funcCall } = query.captures; + addError( + buildError( + funcCall.start.line, funcCall.start.col, + funcCall.end.line, funcCall.end.col, + "Function calls are not allowed" + ) + ); +} +``` + +ただし、複数のノードの `start`、`end` の位置情報を使用したり、必要に応じて自分で計算することもできます。 + +設定した `message` はユーザーに表示されます。 + +また、エラー メッセージに修正案を添付することもできます。そのためには、`Violation` オブジェクトの `addFix()` メソッドを呼び出します。このメソッドは、`buildFix()` 関数で作成できる `Fix` オブジェクトを受け取ります。`buildFix()` は 2 つの引数を取り、1 つ目は `description`、2 つ目は編集案の配列である `edits` です。 + +編集案は、`buildEditAdd()`、`buildEditRemove()`、および `buildEditUpdate()` 関数で作成できます。 + +* `buildEditAdd()` はテキストの挿入案を生成します。`startLine`、 `startCol`、`newContent` という 3 つの引数を取ります。 +* `buildEditRemove()` はテキストの削除案を生成します。`startLine`、`startCol`、`endLine`、`endCol` という 4 つの引数を取ります。 +* `buildEditUpdate()` はテキストの修正案を生成します。`startLine`、`startCol`、`endLine`、`endCol`、`newContent` という 5 つの引数を取ります。 + +```javascript +function visit(query, filename, code) { + const { fname } = query.captures; + if (fname.text != "oldFunction") return; + addError( + buildError( + fname.start.line, fname.start.col, + fname.end.line, fname.end.col, + "This function is deprecated" + ).addFix( + buildFix( + "Use the new function instead", + [ + buildEditUpdate( + fname.start.line, fname.start.col, + fname.end.line, fname.end.col, + "newFunction") + ] + ) + ) + ); +} +``` + +## ヒントとコツ + +### 特定の子ノードを持たないノードのマッチング + +感嘆符 (`!`) を使って特定のフィールドを持たないノードにマッチさせることはできますが、特定の子ノードを持たないノードに対するクエリを書く方法はありません。たとえば、「子ノード `return_statement` を持たない `function_declaration` ノード」に対応するクエリを書くことはできません。 + +しかし、クエリと JavaScript コードを組み合わせることで、その結果を取得することができます。 + +そのためには、疑問符 (`?`) 修飾子と、除外したい子ノードのキャプチャを使って、JavaScript のコードでそのノードがキャプチャされたかどうかをチェックします。キャプチャされていない場合、そのノードは存在しないことになります。 + +```scheme +; Query: +(function_declaration + name: (identifier) @id + result: _ + body: + (block + (return_statement)? @ret ; これが除外したいノードです + ) +) +``` + +```javascript +// Code: +function visit(query, filename, code) { + const { id, ret } = query.captures; + if (ret) return; // return 文が存在するため、ここで終了します + addError( + buildError( + id.start.line, id.start.col, + id.end.line, id.end.col, + "Missing return statement" + ) + ); +} +``` + +### 構文木をたどってノードを探す + +必要なノードをすべて選択してキャプチャするクエリを書きたくなりますが、1 つのノードを見つけてから、`ddsa.getParent()` や `ddsa.getChildren()` を使って残りのノードを見つける方が簡単な場合もあります。 + +たとえば、関数呼び出しを含む関数定義を見つけたい場合、入れ子のさまざまな階層で関数呼び出しのパターンを指定しない限り、Tree Sitter クエリでは実現できません。しかし、Tree Sitter クエリで関数呼び出しを検索した後に、JavaScript コードで `ddsa.getParent()` を使って構文木を上にたどって関数定義を見つければ、非常に簡単に実現できます。 + +```scheme +; Query: +(call_expression + function: + (_ field: _ @methodName + (@eq? @methodName "DoSomething") + ) +) @fn +``` + +```javascript +// Code: +function visit(query, filename, code) { + const { fn } = query.captures; + let decl = ddsa.getParent(fn); + while (decl && decl.cstType != 'function_declaration') + decl = ddsa.getParent(decl); + // `decl` は `function_declaration` または undefined になります +} +``` + +`ddsa.getParent()` と `ddsa.getChildren()` を使えば色々なことができます。たとえば、ノードの兄弟を調べることが可能です。 + +```javascript +function getSiblings(node) { + return ddsa.getChildren(ddsa.getParent(node)).filter(n => n != node); +} + +function getSiblingsAfter(node) { + return ddsa.getChildren(ddsa.getParent(node)). + reduce((a, n) => n == node ? [] : a && a.concat([n]), undefined); +} + +function getSiblingsBefore(node) { + return ddsa.getChildren(ddsa.getParent(node)). + reduceRight((a, n) => n == node ? [] : a && [n].concat(a), undefined); +} +``` + +その後、`cstType` と `text` のプロパティをチェックすることで、興味のあるノードを検査・選択することができます。 + +## 落とし穴 + +### 述語を追加してもクエリは高速化しない + +Tree Sitter クエリが遅い場合、探索範囲を絞り込むために述語を追加して高速化しようとするかもしれません。しかし、この方法は Tree Sitter クエリ エンジンでは機能しません。このエンジンは、パターンに合致するノードを探して構文木を走査する際にはすべての述語を無視し、最後に結果のリストを絞り込むためにのみ述語を適用します。 + +したがって、述語を追加することで、`visit()` 関数の呼び出し回数は減るかもしれませんが、クエリ時に静的解析ツールが行う作業量が減ることはありません。 + +また、クエリ述語は必ずしも `visit()` 関数内でノードをフィルタリングするよりも速いわけではないことに注意してください。クエリ内に複雑な述語を書くよりも、コード内でフィルタリングを行う方が簡単な場合があります。また、コード内でできるだけ早い段階でフィルタリングを行うようにしている限り、パフォーマンスを犠牲にすることもありません。 + +### 組み合わせ爆発の可能性 + +Tree Sitter クエリ エンジンは、クエリを満たすすべてのノードの組み合わせを返そうとします。つまり、代替パターンが 2 つ以上ある複雑なクエリでは、クエリ エンジンが各代替パターンのあらゆる可能性を探索するため、組み合わせ爆発が発生する可能性があります。 + +述語のチェックはノードが選択された後にしか行われないため、述語を追加しても、問題の解決には役立たないことに注意してください。 + +いくつかの原因について以下で解説します。 + +#### 似たような子ノードのパターンが 2 つ指定されている + +ルールを作成する際に、まったく同じか非常によく似たパターンを使って、一度に 2 つのノードをマッチさせようとする人がいます。そのため、これらすべてのパターンにマッチするノードがファイルに多数存在する場合、問題が発生する可能性があります。 + +たとえば、クラス宣言内のメソッドをペアでキャプチャするために、次のようなクエリを書くこともあるでしょう。 + +```scheme +(class_declaration + (method_declaration) @method1 + (method_declaration) @method2 +) +``` + +メソッドが 2 つしかないクラスでは、このクエリが返す結果は 1 件のみです。ところが、クラスにメソッドが 10 個ある場合は 45 件、100 個ある場合は 4950 件の結果が返されてしまいます。 + +この問題を回避するには、`+` や `*` のような修飾子を使用して、メソッドのリスト全体を 1 つのクエリ結果に取り込みます。あるいは、`.` を使用して、該当の子ノードが連続する形で出現しなければならないことを示します。 + +```scheme +(class_declaration + (method_declaration)+ @methods +) + +; or + +(class_declaration + (method_declaration) @method1 + . + (method_declaration) @method2 +) +``` + +#### クエリで 2 つのノードをマッチさせようとする + +よくあるタイプのルールとして、特定の形で使用される、特定のタイプの変数を見つけようとするものがあります。このようなクエリは、「すべての変数定義を見つけて名前をキャプチャし、変数のすべての使用法を見つけ、名前をキャプチャし、その名前が一致するかチェックする」ために書かれがちです。 + +```scheme +(_ + (var_declaration + (var_spec + name: _ @varName + type: _ @typeName + ) + ) + + (_ + (call_expression + function: + (_ + operand: _ @opName + field: _ @methodName + ) + ) + ) + + (#eq? @typeName "myType") + (#eq? @methodName "DoSomething") + (#eq? @varName @opName) +) +``` + +問題は、Tree Sitter クエリ エンジンがすべての `var_declaration` ノードとすべての `call_expression` ノードを取得し、それらを総当たりでペアにしたうえで、各ペアに対して述語をチェックすることです。その結果、計算量が O(nm) になってしまいます。 + +1 つの解決法は、どちらかのノードを見つけるクエリを書き、`ddsa.getParent()` と `ddsa.getChildren()` を使ってもう 1 つのノードを見つけるようにすることです。 + +別の解決法としては、候補となるすべてのノードを集め、ペアにすることは止めて、JavaScript のコードで処理することが考えられます。 + +#### 入れ子の複数の階層でパターンにマッチさせようとする + +「パターンに合致する子ノードを持つノード」を見つけるためのパターンを書くことはできます。ただし、「入れ子の中の任意の階層で子孫ノードを持つノード」を見つけるためのパターンを書くことはできません。 + +ルールを作成する際に、いくつかの代替パターンを指定するやり方、すなわち、一致させたいパターンを入れ子内の各階層で指定することで、これを解決しようとした人たちもいました。 + +```scheme +; Query: +(function_declaration + [ + ; 入れ子の階層 1～4 において同じパターンを見つける + (_ + (call_expression + function: (_ field: _ @methodName) + ) @fn + ) + + (_ (_ + (call_expression + function: (_ field: _ @methodName) + ) @fn + )) + + (_ (_ (_ + (call_expression + function: (_ field: _ @methodName) + ) @fn + ))) + + (_ (_ (_ (_ + (call_expression + function: (_ field: _ @methodName) + ) @fn + )))) + ] + + (#eq? @methodName "DoSomething") +) @decl +``` + +```javascript +// Code: +function visit(query, filename, code) { + const { decl, fn } = query.captures; + // ... decl と fn を使って何か処理を行う +} +``` + +この方法の問題点についてはすでに述べました。まず、クエリ エンジンはパターンのマッチングを試すために構文木のあらゆる分岐をたどるため、時間がかかる可能性があります。さらに、代替パターンが 2 つ以上ある場合、クエリ エンジンは選択肢の組み合わせごとにマッチするノード セットを作り、その組み合わせごとに 1 つの結果を返します。 + +この問題の解決法は、子ノードを対象としたクエリを書き、`ddsa.getParent()` を使って祖先ノードを探すことです。これには、入れ子の階層を無制限にできるという利点もあります。 + +```scheme +; Query: +(call_expression + function: (_field: _ @methodName (#eq? @methodName "doSomething")) +) +``` + +```javascript +// Code: +function visit(query, filename, code) { + const { fn } = query.captures; + let decl = ddsa.getParent(fn); + while (decl && decl.cstType != 'function_declaration') { + decl = ddsa.getParent(decl); + } + // ... decl と fn を使って何か処理を行う +} +``` + + + +[1]: /ja/security/code_security/static_analysis/custom_rules/tutorial/ +[2]: https://tree-sitter.github.io/ +[3]: https://tree-sitter.github.io/tree-sitter/using-parsers/queries/index.html \ No newline at end of file