diff --git a/content/fr/containers/guide/datadogoperator_migration.md b/content/fr/containers/guide/datadogoperator_migration.md new file mode 100644 index 00000000000..5d2710ffd17 --- /dev/null +++ b/content/fr/containers/guide/datadogoperator_migration.md @@ -0,0 +1,200 @@ +--- +aliases: +- /fr/agent/guide/datadogoperator_migration +description: Guide pour effectuer la migration de v1alpha1 vers v2alpha1 de la ressource + personnalisée DatadogAgent à l'aide du webhook de conversion +title: Effectuer la migration vers la version 1.0 de l'opérateur Datadog +--- + +## Effectuer la migration vers la version 1.0 de l'opérateur Datadog + +
+La réconciliation v1alpha1 DatadogAgent dans l'opérateur est obsolète depuis la v1.2.0+ et sera supprimée dans la v1.7.0. Après sa suppression, vous ne pourrez plus configurer l'opérateur Datadog pour réconcilier la CRD v1alpha1 DatadogAgent. Toutefois, vous pourrez toujours appliquer un manifeste v1alpha1 avec le webhook de conversion activé en utilisant datadogCRDs.migration.datadogAgents.conversionWebhook.enabled. +
+ +
+DatadogAgent v1alpha1 et le webhook de conversion seront supprimés dans la v1.8.0. Après leur suppression, vous ne pourrez plus effectuer la migration sauf si vous utilisez une version antérieure de l'opérateur. +
+ + +L'opérateur Datadog v0.X utilise `v1alpha1` de la ressource personnalisée DatadogAgent. L'opérateur Datadog v1.X réconcilie `v2alpha1`. + +Ce guide décrit comment effectuer la migration vers la ressource personnalisée `v2alpha1/DatadogAgent` depuis `v1alpha1/DatadogAgent`. + +### Prérequis + +Si vous utilisez `v1alpha1` avec une version 0.X de l'opérateur Datadog et que vous souhaitez effectuer une mise à niveau, vous devez utiliser la fonctionnalité de webhook de conversion. + +Commencez par vous assurer de disposer de la version minimale requise du chart et de ses dépendances : + +``` +NAME CHART VERSION APP VERSION DESCRIPTION +datadog/datadog-crds 1.0.0 1 Datadog Kubernetes CRDs chart +``` + +Pour le chart de l'opérateur Datadog : + +``` +NAME CHART VERSION APP VERSION DESCRIPTION +datadog/datadog-operator 1.0.0 1.0.0 Datadog Operator +``` + +#### Installer cert manager +Si vous ne disposez pas déjà de cert manager, installez-le avec Helm. + +Ajoutez le chart : + +``` +helm repo add jetstack https://charts.jetstack.io +``` + +Ensuite, installez ce dernier : + +``` + helm install \ + cert-manager jetstack/cert-manager \ + --version v1.11.0 \ + --set installCRDs=true +``` + +### Migration + +Exécutez la commande suivante pour redéployer l'opérateur Datadog et configurer Kubernetes pour stocker la version `v2alpha1` de DatadogAgent : + +``` +helm upgrade \ + datadog-operator datadog/datadog-operator \ + --set image.tag=1.0.0 \ + --set datadogCRDs.migration.datadogAgents.version=v2alpha1 \ + --set datadogCRDs.migration.datadogAgents.useCertManager=true \ + --set datadogCRDs.migration.datadogAgents.conversionWebhook.enabled=true +``` + +Avec cela, le serveur de webhook de conversion (exécuté par l'opérateur Datadog) convertit les objets DatadogAgent existants. + +Si vous disposez de versions `v1alpha1` et effectuez la migration, il est recommandé d'enregistrer la version convertie et de commencer à déployer uniquement la version convertie. Une fois que vous déployez uniquement le DatadogAgent `v2alpha1`, vous pouvez désactiver le webhook de conversion. + +### Remarques + +À partir de la version 1.0.0 du chart `datadog-operator`, le champ `image.tag` possède une valeur par défaut de `1.0.0`, et `datadogCRDs.migration.datadogAgents.version` est `v2alpha1`. + +Ceux-ci sont définis dans la commande ici pour illustrer la migration depuis une version de l'opérateur Datadog < 1.0.0 avec une version stockée de `v1alpha1` vers la version GA de `1.0.0` avec une version stockée de `v2alpha1`. + +### Détails de l'implémentation + +Cela crée un certificat auto-signé (à l'aide d'un Issuer) qui est utilisé par Certificate Manager pour muter la CRD DatadogAgent afin de documenter le `caBundle` que le serveur API utilise pour contacter le webhook de conversion. + +L'opérateur Datadog exécute le réconciliateur pour l'objet `v2alpha1` et démarre un serveur de webhook de conversion, exposé sur le port 9443. Le serveur API utilise ce serveur pour convertir `v1alpha1` DatadogAgent en `v2alpha1`. + +### Cycle de vie + +Le webhook de conversion n'est pas destiné à fonctionner indéfiniment. Datadog le recommande uniquement pour migrer vos objets pendant une période de transition. + +Une fois convertis, vous pouvez stocker la nouvelle version de votre DatadogAgent, désactiver la conversion et déployer uniquement des objets `v2alpha1`. + +### Dépannage + +#### Je ne vois pas la version `v2alpha1` de la ressource DatadogAgent. + +Étant donné que `v1alpha1` et `v2alpha1` sont _servis_, vous devrez peut-être spécifier la version que vous souhaitez voir : + +``` +kubectl get datadogagents.v2alpha1.datadoghq.com datadog-agent +``` + +#### La conversion ne fonctionne pas. + +Les logs du pod de l'opérateur Datadog doivent indiquer que le webhook de conversion est activé, que le serveur est en cours d'exécution et que les certificats sont surveillés. + +``` +kubectl logs datadog-operator-XXX-YYY +[...] +{"level":"INFO","ts":"2023-02-16T16:47:07Z","logger":"controller-runtime.webhook","msg":"Registering webhook","path":"/convert"} +{"level":"INFO","ts":"2023-02-16T16:47:07Z","logger":"controller-runtime.builder","msg":"Conversion webhook enabled","GVK":"datadoghq.com/v2alpha1, Kind=DatadogAgent"} +{"level":"INFO","ts":"2023-02-16T16:47:07Z","logger":"setup","msg":"starting manager"} +{"level":"INFO","ts":"2023-02-16T16:47:07Z","logger":"controller-runtime.webhook.webhooks","msg":"Starting webhook server"} +{"level":"INFO","ts":"2023-02-16T16:47:07Z","logger":"controller-runtime.certwatcher","msg":"Updated current TLS certificate"} +{"level":"INFO","ts":"2023-02-16T16:47:07Z","logger":"controller-runtime.webhook","msg":"Serving webhook server","host":"","port":9443} +{"level":"INFO","ts":"2023-02-16T16:47:07Z","msg":"Starting server","path":"/metrics","kind":"metrics","addr":"0.0.0.0:8383"} +{"level":"INFO","ts":"2023-02-16T16:47:07Z","msg":"Starting server","kind":"health probe","addr":"0.0.0.0:8081"} +{"level":"INFO","ts":"2023-02-16T16:47:07Z","logger":"controller-runtime.certwatcher","msg":"Starting certificate watcher"} +[...] +``` + +#### Comment vérifier le service enregistré pour la conversion pour un endpoint enregistré ? + +``` +kubectl describe service datadog-operator-webhook-service +[...] +Name: datadog-operator-webhook-service +Namespace: default +[...] +Selector: app.kubernetes.io/instance=datadog-operator,app.kubernetes.io/name=datadog-operator +[...] +Port: 443/TCP +TargetPort: 9443/TCP +Endpoints: 10.88.3.28:9443 +``` + +#### Comment vérifier le service enregistré pour le webhook de conversion ? + +``` +kubectl describe crd datadogagents.datadoghq.com +[...] + Conversion: + Strategy: Webhook + Webhook: + Client Config: + Ca Bundle: LS0t[...]UtLS0tLQo= + Service: + Name: datadog-operator-webhook-service + Namespace: default + Path: /convert + Port: 443 + Conversion Review Versions: + v1 +``` + +#### La CRD ne dispose pas du `caBundle`. + +Assurez-vous que la CRD possède l'annotation correcte : `cert-manager.io/inject-ca-from: default/datadog-operator-serving-cert`. Vérifiez également les logs du pod `cert-manager-cainjector`. + +Si vous ne voyez rien de particulier, définir le niveau de log sur 5 (debug) peut être utile : + +``` +kubectl edit deploy cert-manager-cainjector -n cert-manager +[...] + spec: + containers: + - args: + - --v=5 +[...] +``` + +Vous devriez voir des logs tels que : + +``` +[...] +I0217 08:11:15.582479 1 controller.go:178] cert-manager/certificate/customresourcedefinition/generic-inject-reconciler "msg"="updated object" "resource_kind"="CustomResourceDefinition" "resource_name"="datadogagents.datadoghq.com" "resource_namespace"="" "resource_version"="v1" +I0217 08:25:24.989209 1 sources.go:98] cert-manager/certificate/customresourcedefinition/generic-inject-reconciler "msg"="Extracting CA from Certificate resource" "certificate"="default/datadog-operator-serving-cert" "resource_kind"="CustomResourceDefinition" "resource_name"="datadogagents.datadoghq.com" "resource_namespace"="" "resource_version"="v1" +[...] +``` +### Rollback + +Si vous avez effectué la migration vers la nouvelle version de l'opérateur Datadog en utilisant `v2alpha1` mais que vous souhaitez revenir à l'ancienne version, Datadog recommande de : +- Mettre à l'échelle le déploiement de l'opérateur Datadog à 0 réplicas. + ``` + kubectl scale deploy datadog-operator --replicas=0 + ``` +- Mettre à niveau le chart pour que `v1alpha1` soit stocké et pour que l'opérateur Datadog utilise l'image 0.8.X. + ``` + helm upgrade \ + datadog-operator datadog/datadog-operator \ + --set image.tag=0.8.4 \ + --set datadogCRDs.migration.datadogAgents.version=v1alpha1 \ + --set datadogCRDs.migration.datadogAgents.useCertManager=false \ + --set datadogCRDs.migration.datadogAgents.conversionWebhook.enabled=false + ``` +- Redéployez l'objet DatadogAgent `v1alpha1` précédent. + +**Remarque** : le DaemonSet des Agents Datadog est restauré dans le processus. \ No newline at end of file diff --git a/content/fr/containers/guide/kubernetes-cluster-name-detection.md b/content/fr/containers/guide/kubernetes-cluster-name-detection.md new file mode 100644 index 00000000000..67e43d2816b --- /dev/null +++ b/content/fr/containers/guide/kubernetes-cluster-name-detection.md @@ -0,0 +1,121 @@ +--- +aliases: +- /fr/agent/faq/kubernetes-cluster-name-detection +- /fr/agent/guide/kubernetes-cluster-name-detection +description: Détection automatique du nom de cluster pour les clusters Kubernetes + sur GKE, AKS et EKS afin d'améliorer l'identification des nœuds +further_reading: +- link: /agent/autodiscovery/ + tag: documentation + text: Autodiscovery avec l'Agent Docker +- link: /agent/kubernetes/host_setup/ + tag: documentation + text: Exécuter l'Agent sur un host avec Kubernetes +- link: /agent/kubernetes/integrations/ + tag: documentation + text: Intégrations personnalisées +title: Détection automatique du nom de cluster Kubernetes +--- + +À partir de la version 6.11+ de l'Agent, l'Agent Datadog peut détecter automatiquement le nom de cluster Kubernetes sur Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS) et Amazon Elastic Kubernetes Service (EKS). Le nom de cluster peut également être fourni directement ou découvert à partir des étiquettes de nœud Kubernetes. S'il est détecté, le nom de cluster est ajouté en tant que suffixe au nom de nœud pour toutes les données collectées. Cela facilite l'identification des nœuds dans les clusters Kubernetes. + +
+Ce nom de cluster doit être un nom unique et respecter les restrictions suivantes : + +
+ +## Configuration + +Vous pouvez fournir un nom de cluster directement dans votre configuration Datadog. Lorsqu'il est fourni, celui-ci est prioritaire sur toutes les autres options. + +{{< tabs >}} +{{% tab "Operator Datadog" %}} + +Dans l'opérateur Datadog, définissez la valeur sous `global.clusterName`. + +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + global: + clusterName: +``` +{{% /tab %}} +{{% tab "Helm" %}} + +Dans votre chart Helm, définissez la valeur sous `datadog.clusterName`. + +```yaml +datadog: + clusterName: +``` + +{{% /tab %}} +{{< /tabs >}} + + +## Fournisseurs de cloud +Si un nom de cluster n'est pas fourni dans la configuration, l'Agent et l'Agent de cluster contactent les services de métadonnées du fournisseur de cloud pour le récupérer. + +### GKE +Sur GKE, le nom de cluster est récupéré à partir du [serveur de métadonnées de VM][1]. L'Agent effectue une requête pour récupérer les attributs de l'instance et utilise la valeur renvoyée en cas de réussite. + +Vous pouvez tester cette requête en utilisant `kubectl exec` dans le pod de l'Agent et en exécutant une requête `curl` comme suit. + +```shell +curl -v "http://169.254.169.254/computeMetadata/v1/instance/attributes/cluster-name" -H "Metadata-Flavor: Google" +``` + +Une requête réussie renvoie une réponse 200 et le nom de cluster Kubernetes tel qu'il apparaît dans la console GKE. L'activation de certaines fonctionnalités GKE telles que Workload Identity peut restreindre cet accès. + +### AKS +Sur AKS, le nom de cluster est récupéré à partir d'[Azure Instance Metadata Service][2]. L'Agent demande le nom de groupe de ressources de la VM, puis analyse cette valeur pour déterminer le nom de cluster Kubernetes. + +Vous pouvez tester cette requête en utilisant `kubectl exec` dans le pod de l'Agent et en exécutant une requête `curl` comme suit. + +```shell +curl -v "http://169.254.169.254/metadata/instance/compute/resourceGroupName?api-version=2017-08-01&format=text" -H "Metadata: true" +``` +Une requête réussie renvoie une réponse 200 et le nom de groupe de ressources AKS qui doit être analysé. Par exemple, l'Agent analyse `example-cluster-name` à partir du `MC_MyResourceGroup_example-cluster-name_eastus` renvoyé. + +### EKS +Sur l'EKS, le site Agent récupère le nom du cluster en récupérant les balises de l'instance EC2 et en identifiant la balise `kubernetes.io/cluster/: owned` préremplie pour déterminer le nom du cluster. + +Par défaut, l'Agent utilise l'[Instance Metadata Service (IMDS)][3] pour obtenir l'identité de l'instance, qui est utilisée par l'Agent et le SDK AWS pour décrire les tags sur l'instance. Sur l'Agent `7.64.0` et versions ultérieures, il utilise IMDSv2 par défaut pour récupérer cette identité. Cela nécessite que l'instance EC2 et son rôle IAM disposent de l'autorisation `ec2:DescribeTags`. L'Agent ne prend pas en charge [EKS Pod Identity][4] pour les autorisations IAM. + +L'Agent peut également récupérer les tags EC2 directement depuis IMDS lorsque la variable d'environnement suivante est fournie. +```yaml +- name: DD_COLLECT_EC2_TAGS_USE_IMDS + value: "true" +``` +*Toutefois*, IMDS n'accorde pas l'accès aux tags EC2 par défaut. Vous devez [activer l'accès aux tags][5] et définir votre limite de sauts sur 2 (ou plus). + +## Étiquettes de nœud + +La dernière méthode de détection utilise les étiquettes de nœud Kubernetes. L'Agent inspecte son nœud Kubernetes actuel et recherche les étiquettes suivantes : + +- `alpha.eksctl.io/cluster-name` +- `kubernetes.azure.com/cluster` +- `ad.datadoghq.com/cluster-name` + +Des étiquettes supplémentaires peuvent être ajoutées avec la variable d'environnement : + +```yaml +- name: DD_KUBERNETES_NODE_LABEL_AS_CLUSTER_NAME + value: "" +``` + +Si l'étiquette de nœud est trouvée, la valeur est utilisée comme nom de cluster. + +[1]: https://cloud.google.com/compute/docs/metadata/querying-metadata +[2]: https://learn.microsoft.com/en-us/azure/virtual-machines/instance-metadata-service?tabs=linux +[3]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html +[4]: https://docs.aws.amazon.com/eks/latest/userguide/pod-id-how-it-works.html +[5]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/work-with-tags-in-IMDS.html#allow-access-to-tags-in-IMDS \ No newline at end of file diff --git a/content/fr/containers/guide/kubernetes_daemonset.md b/content/fr/containers/guide/kubernetes_daemonset.md new file mode 100644 index 00000000000..e29922988a6 --- /dev/null +++ b/content/fr/containers/guide/kubernetes_daemonset.md @@ -0,0 +1,382 @@ +--- +description: Installation et configuration manuelles de l'Agent Datadog sur Kubernetes + à l'aide du déploiement DaemonSet +further_reading: +- link: /containers/kubernetes/installation + tag: Documentation + text: Installer l'Agent Datadog sur Kubernetes +title: Installer et configurer manuellement l'Agent Datadog sur Kubernetes avec DaemonSet +--- + +
+ Datadog déconseille d'utiliser des DaemonSets pour déployer l'Agent Datadog, car le processus manuel est sujet aux erreurs. Datadog recommande d'utiliser l'opérateur Datadog ou Helm pour installer l'Agent sur Kubernetes. +
+ +## Installation +Vous pouvez utiliser des DaemonSets pour déployer l'Agent Datadog sur tous vos nœuds (ou sur des nœuds spécifiques en [utilisant des nodeSelectors][1]). + +Pour installer l'Agent Datadog sur votre cluster Kubernetes : + +1. **Configurez les autorisations de l'Agent** : si le contrôle d'accès basé sur des rôles (RBAC) est activé pour votre déploiement Kubernetes, configurez les autorisations RBAC pour le compte de service de votre Agent Datadog. Depuis la version 1.6 de Kubernetes, le RBAC est activé par défaut. Créez les ClusterRole, ServiceAccount et ClusterRoleBinding appropriés à l'aide de la commande suivante : + + ```shell + kubectl apply -f "https://raw.githubusercontent.com/DataDog/datadog-agent/master/Dockerfiles/manifests/rbac/clusterrole.yaml" + + kubectl apply -f "https://raw.githubusercontent.com/DataDog/datadog-agent/master/Dockerfiles/manifests/rbac/serviceaccount.yaml" + + kubectl apply -f "https://raw.githubusercontent.com/DataDog/datadog-agent/master/Dockerfiles/manifests/rbac/clusterrolebinding.yaml" + ``` + + **Remarque** : ces configurations RBAC sont définies pour l'espace de nommage `default`. Si vous utilisez un espace de nommage personnalisé, modifiez le paramètre `namespace` avant d'appliquer les configurations. + + +2. **Créez le manifeste de l'Agent Datadog**. Créez le manifeste `datadog-agent.yaml` à partir de l'un des modèles suivants : + + | Métriques | Logs | APM | Processus | NPM | Sécurité | Linux | Windows | + |---------------------------------|---------------------------------|---------------------------------|---------------------------------|---------------------------------|---------------------------------|-------------------------|--------------------------------------| + | | | | | | | [Modèle de manifeste][2] | [Modèle de manifeste][3] (sans sécurité) | + | | | | | | | [Modèle de manifeste][4] | [Modèle de manifeste][5] | + | | | | | | | [Modèle de manifeste][6] | [Modèle de manifeste][7] | + | | | | | | | [Modèle de manifeste][8] | [Modèle de manifeste][9] | + | | | | | | | [Modèle de manifeste][10] | aucun modèle | + | | | | | | | [Modèle de manifeste][11] | [Modèle de manifeste][12] | + + Pour activer complètement la collecte de traces, [des étapes supplémentaires sont requises sur la configuration du Pod de votre application][13]. Consultez également les pages de documentation [logs][14], [APM][15], [processus][16], [Cloud Network Monitoring][17] et [sécurité][18] pour apprendre à activer chaque fonctionnalité individuellement. + + **Remarque** : ces manifestes sont définis pour l'espace de nommage `default`. Si vous utilisez un espace de nommage personnalisé, modifiez le paramètre `metadata.namespace` avant d'appliquer les manifestes. + +3. Dans le manifeste `secret-api-key.yaml`, remplacez `PUT_YOUR_BASE64_ENCODED_API_KEY_HERE` par [votre clé d'API Datadog][19] encodée en base64. Pour obtenir la version base64 de votre clé d'API, exécutez la commande suivante : + + ```shell + echo -n '' | base64 + ``` +4. Si vous utilisez le modèle de manifeste `datadog-agent-all-features.yaml` : dans le manifeste `secret-cluster-agent-token.yaml`, remplacez `PUT_A_BASE64_ENCODED_RANDOM_STRING_HERE` par une chaîne aléatoire encodée en base64. Pour obtenir sa version en base64, vous pouvez exécuter : + + ```shell + echo -n 'Random string' | base64 + ``` + + **Remarque** : la chaîne aléatoire doit inclure au moins 32 caractères alphanumériques, afin de sécuriser les communications entre l'Agent de cluster et l'Agent. + +5. **Définissez votre site Datadog** sur {{< region-param key="dd_site" code="true" >}} en utilisant la variable d'environnement `DD_SITE` dans le manifeste `datadog-agent.yaml`. + + **Note** : Si la variable d'environnement `DD_SITE` n'est pas explicitement définie, la valeur par défaut est le site `US` `datadoghq.com` . Si vous utilisez l'un des autres sites, vous recevrez un message indiquant que votre clé API n'est pas valide. Utilisez le [sélecteur de site de documentation][20] pour consulter la documentation correspondant au site que vous utilisez. + +6. **Déployez le DaemonSet** avec cette commande : + + ```shell + kubectl apply -f datadog-agent.yaml + ``` + +7. **Vérification** : pour vérifier que l'Agent Datadog s'exécute dans votre environnement en tant que DaemonSet, exécutez ce qui suit : + + ```shell + kubectl get daemonset + ``` + + Si l'Agent est déployé, une sortie similaire au texte ci-dessous s'affiche. Les valeurs `DESIRED` et `CURRENT` correspondent au nombre de nœuds exécutés dans votre cluster. + + ```shell + NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE + datadog 2 2 2 2 2 10s + ``` + +## Configuration + +### Collecte de traces + +{{< tabs >}} +{{% tab "TCP" %}} + +Pour activer la collecte de traces APM via TCP, ouvrez le fichier de configuration DaemonSet et modifiez les éléments suivants : + +- Autorisez la réception de données sur le port `8126` (transmission du trafic du host à l'Agent) dans le conteneur `trace-agent` : + ```yaml + # (...) + containers: + - name: trace-agent + # (...) + ports: + - containerPort: 8126 + hostPort: 8126 + name: traceport + protocol: TCP + # (...) + ``` + +- **Si vous utilisez la version 7.17 ou une version antérieure de l'Agent**, en plus des étapes ci-dessus, définissez les variables `DD_APM_NON_LOCAL_TRAFFIC` et `DD_APM_ENABLED` sur `true` dans votre section `env` du manifeste de l'Agent de trace `datadog.yaml` : + + ```yaml + # (...) + containers: + - name: trace-agent + # (...) + env: + - name: DD_APM_ENABLED + value: 'true' + - name: DD_APM_NON_LOCAL_TRAFFIC + value: "true" + # (...) + ``` + +**Attention** : le paramètre `hostPort` ouvre un port sur votre host. Assurez-vous que votre pare-feu accorde uniquement un accès à vos applications ou à d'autres sources de confiance. Si votre plug-in réseau ne prend pas en charge `hostPorts`, ajoutez `hostNetwork: true` aux spécifications de pod de votre Agent afin de partager l'espace de nommage réseau de votre host avec l'Agent Datadog. Cela signifie également que tous les ports ouverts sur le conteneur sont également ouverts sur le host. Si un port est utilisé sur le host et dans votre conteneur, ces derniers peuvent entrer en conflit (puisqu'ils partagent le même espace de nommage réseau), empêchant ainsi le pod de démarrer. Cela n'est pas possible avec certaines installations Kubernetes. + + +{{% /tab %}} +{{% tab "Socket de domaine Unix (UDS)" %}} + +Pour activer la collecte de traces APM via UDS, ouvrez le fichier de configuration DaemonSet et modifiez les éléments suivants : + + ```yaml + # (...) + containers: + - name: trace-agent + # (...) + env: + - name: DD_APM_ENABLED + value: "true" + - name: DD_APM_RECEIVER_SOCKET + value: "/var/run/datadog/apm.socket" + # (...) + volumeMounts: + - name: apmsocket + mountPath: /var/run/datadog/ + volumes: + - hostPath: + path: /var/run/datadog/ + type: DirectoryOrCreate + # (...) + ``` + +Cette configuration crée un répertoire sur le host et le monte dans l'Agent. L'Agent crée ensuite un fichier de socket dans ce répertoire avec la valeur `DD_APM_RECEIVER_SOCKET` de `/var/run/datadog/apm.socket` et effectue une écoute sur ce fichier. Les pods d'application peuvent alors être montés de la même façon sur ce volume et écrire des données sur ce socket. + +{{% /tab %}} +{{< /tabs >}} + +### Collecte de logs + +**Remarque** : cette option n'est pas prise en charge sous Windows. Utilisez plutôt l'option [Helm][22]. + +Pour activer la collecte de logs avec votre DaemonSet : + +1. Définissez les variables `DD_LOGS_ENABLED` et `DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL` sur true dans la section *env* du manifeste de l'Agent `datadog.yaml` : + + ```yaml + # (...) + env: + # (...) + - name: DD_LOGS_ENABLED + value: "true" + - name: DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL + value: "true" + - name: DD_CONTAINER_EXCLUDE_LOGS + value: "name:datadog-agent" + # (...) + ``` + + **Note** : Le réglage de `DD_CONTAINER_EXCLUDE_LOGS` empêche le Datadog Agent de collecter et d'envoyer ses propres journaux. Supprimez ce paramètre si vous souhaitez collecter les Datadog Agent journaux. Voir la [variable d'environnement pour ignorer les conteneurs][21] pour en savoir plus. Lorsque vous utilisez ImageStreams dans des environnements OpenShift, définissez `DD_CONTAINER_INCLUDE_LOGS` avec le conteneur `name` pour collecter les journaux. Ces deux valeurs de paramètres Exclure/Inclure prennent en charge les expressions régulières. + +2. Montez le volume `pointerdir` pour empêcher la perte de logs de conteneur lors des redémarrages ou en cas de problèmes réseau. Montez également `/var/lib/docker/containers` pour recueillir des logs via le fichier de logs Kubernetes, car `/var/log/pods` est un lien symbolique vers ce répertoire : + + ```yaml + # (...) + volumeMounts: + # (...) + - name: pointerdir + mountPath: /opt/datadog-agent/run + - name: logpodpath + mountPath: /var/log/pods + # Docker runtime directory, replace this path + # with your container runtime logs directory, + # or remove this configuration if `/var/log/pods` + # is not a symlink to any other directory. + - name: logcontainerpath + mountPath: /var/lib/docker/containers + # (...) + volumes: + # (...) + - hostPath: + path: /opt/datadog-agent/run + name: pointerdir + - hostPath: + path: /var/log/pods + name: logpodpath + # Docker runtime directory, replace this path + # with your container runtime logs directory, + # or remove this configuration if `/var/log/pods` + # is not a symlink to any other directory. + - hostPath: + path: /var/lib/docker/containers + name: logcontainerpath + # (...) + ``` + + Le `pointerdir` est utilisé pour stocker un fichier avec un pointeur vers tous les conteneurs à partir desquels l'Agent recueille des logs. Ce volume permet de s'assurer qu'aucun log n'est perdu lorsque l'Agent est redémarré ou lors d'un problème réseau. + +### Sans privilèges + +(Facultatif) Pour exécuter une installation sans privilèges, ajoutez le bloc suivant à votre [modèle de pod][2] : + +```yaml + spec: + securityContext: + runAsUser: + supplementalGroups: + - +``` + +`` correspond à l'UID utilisé pour exécuter l'agent et `` à l'ID du groupe auquel appartient le socket containerd ou docker. + +Lorsque l'Agent s'exécute avec un utilisateur non root, il ne peut pas lire directement les fichiers de log contenus dans `/var/lib/docker/containers`. Dans la plupart des cas, il est nécessaire de monter le socket Docker sur le conteneur de l'Agent, afin de pouvoir récupérer les logs du conteneur depuis le daemon Docker. + + + +### Collecte d'événements de l'Agent de cluster + +Si vous souhaitez que les événements Kubernetes soient collectés par l'Agent de cluster de Datadog, suivez les étapes suivantes : + +1. Désactivez l'élection de leader dans votre Agent de nœud en définissant la variable `leader_election` ou la variable d'environnement `DD_LEADER_ELECTION` sur `false`. + +2. Dans le fichier de déploiement de l'Agent de cluster, définissez les variables d'environnement `DD_COLLECT_KUBERNETES_EVENTS` et `DD_LEADER_ELECTION` sur `true` : + + ```yaml + - name: DD_COLLECT_KUBERNETES_EVENTS + value: "true" + - name: DD_LEADER_ELECTION + value: "true" + ``` + +En configurant l'élection de leader conformément aux étapes ci-dessus, vous aurez l'assurance que la collecte des événements est assurée par un seul Agent de cluster. + +Pour recueillir les événements Kubernetes avec un Agent de nœud, il est également possible de définir les variables d'environnement `DD_COLLECT_KUBERNETES_EVENTS` et `DD_LEADER_ELECTION` sur `true` dans le manifeste de votre Agent. + +```yaml +- name: DD_COLLECT_KUBERNETES_EVENTS + value: "true" +- name: DD_LEADER_ELECTION + value: "true" +``` + +## Variables d'environnement + +Voici la liste des variables d'environnement disponibles pour l'Agent Datadog qui utilise un DaemonSet. + +### Options globales + +| Variable d'environnement | Rôle | +|----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| `DD_API_KEY` | Votre clé d'API Datadog (**obligatoire**). | +| `DD_ENV` | Définit le tag `env` global pour toutes les données émises. | +| `DD_HOSTNAME` | Le hostname à utiliser pour les métriques (si la détection automatique échoue). | +| `DD_TAGS` | Tags de host séparés par des espaces. Exemple : `tag-simple-0 clé-tag-1:valeur-tag-1`. | +| `DD_SITE` | Le site auquel vous transmettez vos métriques, traces et logs. Votre `DD_SITE` est {{< region-param key="dd_site" code="true">}}. Valeur par défaut : `datadoghq.com`. | +| `DD_DD_URL` | Paramètre facultatif pour remplacer l'URL utilisée pour l'envoi de métriques. | +| `DD_URL` (versions 6.36/7.36 ou ultérieures) | Alias de `DD_DD_URL`. Ignoré si la valeur `DD_DD_URL` est déjà définie. | +| `DD_CHECK_RUNNERS` | Par défaut, l'Agent exécute tous les checks simultanément (valeur par défaut : `4` runners). Pour exécuter les checks de manière séquentielle, définissez la valeur sur `1`. Si vous devez exécuter un grand nombre de checks (ou plusieurs checks lents), le composant `collector-queue` peut prendre du retard, ce qui entraîne l'échec potentiel du check de santé. Vous pouvez accroître le nombre de runners pour exécuter davantage de checks en parallèle. | +| `DD_LEADER_ELECTION` | Si vous exécutez plusieurs instances de l'Agent dans votre cluster, définissez cette variable sur `true` pour éviter de recueillir deux fois chaque événement. | + +### Paramètres de proxy + +Depuis la version 6.4.0 de l'Agent (et 6.5.0 de l'Agent de trace), vous pouvez remplacer les paramètres de proxy de l'Agent via les variables d'environnement suivantes : + +| Variable d'environnement | Rôle | +|--------------------------|------------------------------------------------------------------------| +| `DD_PROXY_HTTP` | URL HTTP à utiliser comme proxy pour les requêtes `http`. | +| `DD_PROXY_HTTPS` | URL HTTPS à utiliser comme proxy pour les requêtes `https`. | +| `DD_PROXY_NO_PROXY` | Liste d'URL, séparées par des espaces, pour lesquelles aucun proxy ne doit être utilisé. | +| `DD_SKIP_SSL_VALIDATION` | Option permettant de tester si l'Agent a des difficultés à se connecter à Datadog. | + +Pour en savoir plus sur les paramètres de proxy, consultez la [documentation sur les proxys de l'Agent v6][23]. + + + +### DogStatsD (métriques custom) + +Envoyer des métriques custom avec [le protocole StatsD][24] : + +| Variable d'environnement | Rôle | +|----------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------| +| `DD_DOGSTATSD_NON_LOCAL_TRAFFIC` | Effectue une écoute des paquets DogStatsD issus d'autres conteneurs (requis pour envoyer des métriques custom). | +| `DD_HISTOGRAM_PERCENTILES` | Les centiles à calculer pour l'histogramme (séparés par des espaces). Valeur par défaut : `0.95`. | +| `DD_HISTOGRAM_AGGREGATES` | Les agrégations à calculer pour l'histogramme (séparées par des espaces). Valeur par défaut : `"max median avg count"`. | +| `DD_DOGSTATSD_SOCKET` | Le chemin vers le socket Unix à écouter. Doit être dans le volume `rw` monté. | +| `DD_DOGSTATSD_ORIGIN_DETECTION` | Active la détection des conteneurs et le tagging pour les métriques de socket Unix. | +| `DD_DOGSTATSD_TAGS` | Les tags supplémentaires à ajouter à l'ensemble des métriques, événements et checks de service reçus par ce serveur DogStatsD. Exemple : `"env:golden group:retrievers"`. | + +En savoir plus sur [DogStatsD via les sockets de domaine Unix][25]. + +### Tags + +Datadog recueille automatiquement les tags courants à partir de Kubernetes. Pour extraire des tags supplémentaires, utilisez les options suivantes : + +| Variable d'environnement | Rôle | +|-----------------------------------------|-------------------------| +| `DD_KUBERNETES_POD_LABELS_AS_TAGS` | Permet d'extraire les étiquettes de pod. | +| `DD_KUBERNETES_POD_ANNOTATIONS_AS_TAGS` | Extrait les annotations de pod. | + +Consultez la documentation sur l'[extraction de tags Kubernetes][26] pour en savoir plus. + +### Ignorer des conteneurs + +Vous pouvez exclure des conteneurs de la collecte de logs, de la collecte de métriques et d'Autodiscovery. Par défaut, Datadog exclut les conteneurs `pause` de Kubernetes et d'OpenShift. Ces listes d'inclusion et d'exclusion s'appliquent uniquement à Autodiscovery. Elles n'ont aucun impact sur les traces ni sur DogStatsD. Il est possible d'utiliser des expressions régulières pour les valeurs de ces variables d'environnement. + +| Variable d'environnement | Rôle | +|--------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| `DD_CONTAINER_INCLUDE` | Liste des conteneurs à inclure (séparés par des espaces). Utilisez `.*` pour tous les inclure. Exemple : `"image:nom_image_1 image:nom_image_2"`, `image:.*`. | +| `DD_CONTAINER_EXCLUDE` | Liste des conteneurs à exclure (séparés par des espaces). Utilisez `.*` pour tous les exclure. Exemple : `"image:nom_image_3 image:nom_image_4"`, `image:.*`. | +| `DD_CONTAINER_INCLUDE_METRICS` | Liste des conteneurs dont vous souhaitez inclure les métriques. | +| `DD_CONTAINER_EXCLUDE_METRICS` | Liste des conteneurs dont vous souhaitez exclure les métriques. | +| `DD_CONTAINER_INCLUDE_LOGS` | Liste des conteneurs dont vous souhaitez inclure les logs. | +| `DD_CONTAINER_EXCLUDE_LOGS` | Liste des conteneurs dont vous souhaitez exclure les logs. | +| `DD_AC_INCLUDE` | **Obsolète**. Liste des conteneurs à inclure (séparés par des espaces). Utilisez `.*` pour tous les inclure. Exemple : `"image:nom_image_1 image:nom_image_2"`, `image:.*`. | +| `DD_AC_EXCLUDE` | **Obsolète**. Liste des conteneurs à exclure (séparés par des espaces). Utilisez `.*` pour tous les exclure. Exemple : `"image:nom_image_3 image:nom_image_4"` (cette variable est seulement traitée pour Autodiscovery), `image:.*`. | + +Des exemples supplémentaires sont disponibles sur la page [Gestion de la découverte de conteneurs][27]. + +**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. + +### Autodiscovery + +| Variable d'environnement | Rôle | +|------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| `DD_LISTENERS` | Écouteurs Autodiscovery à exécuter. | +| `DD_EXTRA_LISTENERS` | Les écouteurs Autodiscovery supplémentaires à exécuter. Ils s'ajoutent aux variables définies dans la section `listeners` du fichier de configuration `datadog.yaml`. | +| `DD_CONFIG_PROVIDERS` | Les fournisseurs que l'Agent doit appeler pour collecter les configurations de checks. Les fournisseurs disponibles sont :
`kubelet` - Gère les modèles intégrés dans les annotations de pod.
`docker` - Gère les modèles intégrés dans les étiquettes de conteneur.
`clusterchecks` - Récupère les configurations de checks au niveau du cluster depuis l'Agent de cluster.
`kube_services` - Surveille les services Kubernetes pour les checks de cluster. | +| `DD_EXTRA_CONFIG_PROVIDERS` | Les fournisseurs de configuration Autodiscovery supplémentaires à utiliser. Ils s'ajoutent aux variables définies dans la section `config_providers` du fichier de configuration `datadog.yaml`. | + +### Divers + +| Variable d'environnement | Rôle | +|-------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| `DD_PROCESS_AGENT_CONTAINER_SOURCE` | Remplace la détection automatique de la source de conteneur pour forcer une source unique. Exemple : `"docker"`, `"ecs_fargate"`, `"kubelet"`. Cela n'est plus nécessaire depuis l'Agent v7.35.0. | +| `DD_HEALTH_PORT` | Définissez cette variable sur `5555` pour exposer le check de santé de l'Agent sur le port `5555`. | +| `DD_CLUSTER_NAME` | Définissez un identifiant de cluster Kubernetes personnalisé pour éviter les conflits entre les alias de host. Le nom du cluster peut contenir jusqu'à 40 caractères correspondants à des lettres minuscules, des chiffres et des traits d'union. Il doit également commencer par une lettre et se terminer par un chiffre ou une lettre. | + + +[1]: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#nodeselector +[2]: /resources/yaml/datadog-agent-all-features.yaml +[3]: /resources/yaml/datadog-agent-windows-all-features.yaml +[4]: /resources/yaml/datadog-agent-logs-apm.yaml +[5]: /resources/yaml/datadog-agent-windows-logs-apm.yaml +[6]: /resources/yaml/datadog-agent-logs.yaml +[7]: /resources/yaml/datadog-agent-windows-logs.yaml +[8]: /resources/yaml/datadog-agent-apm.yaml +[9]: /resources/yaml/datadog-agent-windows-apm.yaml +[10]: /resources/yaml/datadog-agent-npm.yaml +[11]: /resources/yaml/datadog-agent-vanilla.yaml +[12]: /resources/yaml/datadog-agent-windows-vanilla.yaml +[13]: /fr/agent/kubernetes/apm/#setup +[14]: /fr/agent/kubernetes/log/ +[15]: /fr/agent/kubernetes/apm/ +[16]: /fr/infrastructure/process/?tab=kubernetes#installation +[17]: /fr/network_monitoring/cloud_network_monitoring/setup/ +[18]: /fr/data_security/agent/ +[19]: https://app.datadoghq.com/organization-settings/api-keys +[20]: /fr/getting_started/site/ +[21]: /fr/agent/docker/?tab=standard#ignore-containers +[22]: /fr/containers/kubernetes/log +[23]: /fr/agent/configuration/proxy/#agent-v6 +[24]: /fr/developers/dogstatsd/ +[25]: /fr/developers/dogstatsd/unix_socket/ +[26]: /fr/containers/kubernetes/tag/ +[27]: /fr/agent/guide/autodiscovery-management/ \ No newline at end of file diff --git a/content/fr/containers/guide/operator-advanced.md b/content/fr/containers/guide/operator-advanced.md new file mode 100644 index 00000000000..30d04da7946 --- /dev/null +++ b/content/fr/containers/guide/operator-advanced.md @@ -0,0 +1,148 @@ +--- +aliases: +- /fr/agent/guide/operator-advanced +description: Options avancées de configuration et de déploiement pour l'opérateur + Datadog sur Kubernetes et OpenShift +further_reading: +- link: agent/kubernetes/log + tag: Documentation + text: Datadog et Kubernetes +title: Configuration avancée de l'Operator Datadog +--- + +[L'Operator Datadog][1] est une fonctionnalité permettant de déployer l'Agent Datadog sur Kubernetes et OpenShift. L'Operator transmet des données sur le statut, la santé et les erreurs du déploiement dans le statut de sa ressource personnalisée. Ses paramètres de niveau supérieur permettent également de réduire les erreurs de configuration. + +## Prérequis + +L'utilisation de l'Operator Datadog nécessite les prérequis suivants : + +- **Version de cluster Kubernetes >= v1.20.X** : les tests ont été effectués sur les versions >= `1.20.0`. Néanmoins, cela devrait fonctionner sur les versions `>= v1.11.0`. Pour les versions antérieures, en raison d'une prise en charge limitée des CRD, l'opérateur peut ne pas fonctionner comme prévu. +- [`Helm`][2] pour le déploiement de `datadog-operator`. +- [Interface de ligne de commande `Kubectl`][3] pour l'installation de `datadog-agent`. + +## Déployer l'Operator Datadog + +Pour faciliter l'exécution des commandes, définir une variable d'environnement appelée `DD_NAMESPACE` dans votre shell. +Pour utiliser l'opérateur Datadog, déployer ce dernier dans votre cluster Kubernetes. Ensuite, créer une ressource Kubernetes `DatadogAgent` contenant la configuration de déploiement Datadog : + +1. Ajoutez le référentiel du Helm Datadog : + ``` + helm repo add datadog https://helm.datadoghq.com + ``` + +2. Installez l'Operator Datadog : + ``` + helm install my-datadog-operator datadog/datadog-operator -n $DD_NAMESPACE + ``` + +## Déployer les Agents Datadog avec l'Operator + +Après avoir déployé l'Operator Datadog, créez la ressource `DatadogAgent` qui déclenche le déploiement de l'Agent Datadog dans votre cluster Kubernetes. Lorsque cette ressource est créée dans l'espace de nommage `Datadog-Operator`, l'Agent est déployé en tant que `DaemonSet` sur chaque `Node` de votre cluster. + +Créez le manifeste `datadog-agent.yaml` à partir de l'un des modèles suivants : + +* [Manifeste avec activation des logs, de l'APM, des processus et de la collecte des métriques][4] +* [Manifeste avec activation des logs, de l'APM et de la collecte des métriques][5] +* [Manifeste avec activation de l'APM et de la collecte des métriques][7] +* [Manifeste avec Agent de cluster][8] +* [Manifeste avec tolérances][9] + +Remplacez `` et `` par vos [clés d'API et d'application Datadog][10], puis lancez l'installation de l'Agent avec la commande suivante : + +```shell +$ kubectl apply -n $DD_NAMESPACE -f datadog-agent.yaml +datadogagent.datadoghq.com/datadog created +``` + +Vous pouvez vérifier l'état de la ressource `DatadogAgent` avec ce qui suit : + +```shell +kubectl get -n $DD_NAMESPACE dd datadog + +NAME ACTIVE AGENT CLUSTER-AGENT CLUSTER-CHECKS-RUNNER AGE +datadog-agent True Running (2/2/2) 110m +``` + +Dans un cluster comportant 2 nœuds worker, les pods de l'Agent créés devraient s'afficher sur chaque nœud. + +```shell +$ kubectl get -n $DD_NAMESPACE daemonset +NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE +datadog-agent 2 2 2 2 2 5m30s + +$ kubectl get -n $DD_NAMESPACE 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 +``` + + +## Nettoyage + +La commande suivante permet de supprimer toutes les ressources Kubernetes créées par les instructions ci-dessus : + +```shell +kubectl delete datadogagent datadog +helm delete my-datadog-operator -n $DD_NAMESPACE +``` + +Il est important de supprimer la ressource `DatadogAgent` et de laisser l'opérateur effectuer un nettoyage. Lorsque la ressource `DatadogAgent` est créée dans un cluster, l'opérateur ajoute un finalisateur pour empêcher la suppression jusqu'à ce qu'il termine le nettoyage des ressources qu'il a créées. Si l'opérateur est désinstallé en premier, les tentatives de suppression de la ressource `DatadogAgent` sont bloquées indéfiniment ; cela bloquera également la suppression de l'espace de nommage. Une solution de contournement dans cette situation consiste à supprimer la valeur `metadata.finalizers` de la ressource `DatadogAgent`. + +### Tolérances + +Mettez à jour votre fichier `datadog-agent.yaml` avec la configuration suivante pour ajouter la tolérance dans le `Daemonset.spec.template` de votre `DaemonSet` : + +```yaml +kind: DatadogAgent +apiVersion: datadoghq.com/v2alpha1 +metadata: + name: datadog +spec: + global: + credentials: + apiKey: + appKey: + override: + nodeAgent: + image: + name: gcr.io/datadoghq/agent:latest + tolerations: + - operator: Exists +``` + +Appliquez cette nouvelle configuration : + +```shell +$ kubectl apply -f datadog-agent.yaml +datadogagent.datadoghq.com/datadog updated +``` + +La mise à jour du DaemonSet peut être validée en observant la nouvelle valeur de pod souhaitée : + +```shell +$ kubectl get -n $DD_NAMESPACE daemonset +NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE +datadog-agent 3 3 3 3 3 7m31s + +$ kubectl get -n $DD_NAMESPACE 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 +``` + +## Pour aller plus loin + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://github.com/DataDog/datadog-operator +[2]: https://helm.sh +[3]: https://kubernetes.io/docs/tasks/tools/install-kubectl/ +[4]: https://github.com/DataDog/datadog-operator/blob/main/examples/datadogagent/datadog-agent-all.yaml +[5]: https://github.com/DataDog/datadog-operator/blob/main/examples/datadogagent/datadog-agent-with-logs-apm.yaml +[7]: https://github.com/DataDog/datadog-operator/blob/main/examples/datadogagent/datadog-agent-with-apm-hostport.yaml +[8]: https://github.com/DataDog/datadog-operator/blob/main/examples/datadogagent/datadog-agent-with-clusteragent.yaml +[9]: https://github.com/DataDog/datadog-operator/blob/main/examples/datadogagent/datadog-agent-with-tolerations.yaml +[10]: https://app.datadoghq.com/organization-settings/api-keys \ No newline at end of file diff --git a/content/fr/containers/guide/operator-eks-addon.md b/content/fr/containers/guide/operator-eks-addon.md index 0e6a92ee984..cb45a4ecf84 100644 --- a/content/fr/containers/guide/operator-eks-addon.md +++ b/content/fr/containers/guide/operator-eks-addon.md @@ -1,6 +1,8 @@ --- aliases: - /fr/agent/guide/operator-eks-addon +description: Installer et configurer l'Agent Datadog sur Amazon EKS en utilisant l'opérateur + Datadog comme add-on EKS further_reading: - link: agent/kubernetes/log tag: Documentation @@ -8,6 +10,10 @@ further_reading: title: Installer l'Agent Datadog sur Amazon EKS avec l'Operator Datadog --- +
À partir de la v0.1.9, l'add-on de l'opérateur Datadog prend en charge l'injection automatique de sidecar de l'Agent dans les pods planifiés sur des instances Fargate. Consultez ce guide pour plus de détails. +
+ + Vous pouvez installer l'Agent Datadog sur un cluster Amazon EKS. Pour ce faire, installez l'[Operator Datadog](/containers/datadog_operator) en tant que [module complémentaire Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/eks-add-ons.html) et appliquez le manifeste `DatadogAgent`. Les Agents installés avec l'Operator en tant que module complémentaire recueillent uniquement les données des pods exécutés sur des instances EC2. Pour les pods exécutés sur AWS Fargate, reportez-vous à la [documentation d'Amazon EKS relative à AWS Fargate][10]. @@ -38,12 +44,12 @@ Ces restrictions sont nécessaires pour rendre l'Operator conforme aux politique Pour installer l'Operator en tant que module, exécutez : ```bash - aws eks create-addon --addon-name datadog_operator --region --cluster-name + aws eks create-addon --addon-name datadog_operator --region --cluster-name ``` Le processus d'installation est asynchrone. Pour vérifier le statut de l'installation, exécutez : ```bash - aws eks describe-addon --addon-name datadog_operator --region --cluster-name + aws eks describe-addon --addon-name datadog_operator --region --cluster-name ``` {{% /tab %}} {{< /tabs >}} @@ -79,7 +85,7 @@ Suivez les instructions pour configurer l'Agent Datadog en utilisant la ressourc global: # Required in case the Agent cannot resolve the cluster name through IMDS. See the note below. clusterName: - registry: 709825985650.dkr.ecr.us-east-1.amazonaws.com/datadog + registry: credentials: apiSecret: secretName: datadog-secret @@ -127,7 +133,7 @@ Vérifiez que toutes les ressources de l'Agent ont été supprimées et continue Pour supprimer le module, exécutez : ```bash - aws eks delete-addon --addon-name datadog_operator --region --cluster-name + aws eks delete-addon --addon-name datadog_operator --region --cluster-name ``` {{% /tab %}} diff --git a/content/fr/containers/guide/sync_container_images.md b/content/fr/containers/guide/sync_container_images.md new file mode 100644 index 00000000000..3aaa22245a2 --- /dev/null +++ b/content/fr/containers/guide/sync_container_images.md @@ -0,0 +1,58 @@ +--- +aliases: +- /fr/agent/guide/sync_container_images +description: Synchroniser les images de conteneurs Datadog depuis les registres publics + vers votre registre privé à l'aide de Crane ou d'outils similaires +title: Synchroniser les images Datadog avec un registre privé +--- + +Datadog publie des images de conteneurs dans plusieurs registres de conteneurs publics. Bien que cela soit pratique pour de nombreux utilisateurs, certaines organisations peuvent souhaiter utiliser un registre de conteneurs privé. Ce guide explique comment synchroniser les images de conteneurs Datadog vers un registre privé. + +{{% container-images-table %}} + +## Synchroniser les images vers votre registre privé + +### Utiliser Crane + +[Crane][1] est un outil créé par Google pour gérer les images et les registres de conteneurs et peut être utilisé pour synchroniser les images entre différents registres de conteneurs. Pour en savoir plus sur Crane, consultez la [documentation Crane][2]. + +#### Installer Crane + +Pour obtenir des instructions détaillées sur l'installation de Crane, consultez le [fichier README.md de Crane][1]. + +#### Copier une image vers un autre registre à l'aide de Crane + +Crane peut copier des images entre différents registres de conteneurs tout en préservant le condensé de l'image. + +Cela signifie que la copie conserve le même manifeste et fonctionne avec les images multiplateformes. + +Pour copier une image d'un registre vers un autre, utiliser la commande `crane copy`. + +```shell +crane copy /: /: +``` + +Vous pouvez utiliser le flag `-n` pour éviter d'écraser un tag existant dans le registre de destination. + +Par exemple, pour copier les images par défaut nécessaires à l'opérateur Datadog depuis Docker Hub vers un registre privé : +```shell +AGENT_VERSION= +OPERATOR_VERSION= +REGISTRY= +crane copy gcr.io/datadoghq/operator:$OPERATOR_VERSION $REGISTRY/operator:$OPERATOR_VERSION +crane copy gcr.io/datadoghq/agent:$AGENT_VERSION $REGISTRY/agent:$AGENT_VERSION +crane copy gcr.io/datadoghq/cluster-agent:$AGENT_VERSION $REGISTRY/cluster-agent:$AGENT_VERSION +``` + +## Utiliser un registre privé + +Une fois que vous avez synchronisé les images, vous pouvez utiliser ce guide pour [modifier le registre de conteneurs][3] utilisé par votre environnement. + +**Remarque** : si vous utilisez votre registre privé, vous devrez peut-être créer un pull secret pour pouvoir extraire les images. +Pour en savoir plus sur la création d'un pull secret, consultez la [documentation Kubernetes][4]. + + +[1]: https://github.com/google/go-containerregistry/tree/main/cmd/crane +[2]: https://github.com/google/go-containerregistry/blob/main/cmd/crane/doc/crane.md +[3]: https://docs.datadoghq.com/fr/containers/guide/changing_container_registry +[4]: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials \ No newline at end of file diff --git a/content/fr/containers/guide/template_variables.md b/content/fr/containers/guide/template_variables.md index ac8aaebd8cc..810c53fcf2a 100644 --- a/content/fr/containers/guide/template_variables.md +++ b/content/fr/containers/guide/template_variables.md @@ -3,10 +3,15 @@ aliases: - /fr/agent/autodiscovery/template_variables - /fr/agent/faq/template_variables - /fr/agent/guide/template_variables +description: Guide de référence pour les variables de modèle disponibles dans la configuration + d'intégration Autodiscovery pour les environnements de conteneurs dynamiques further_reading: -- link: /agent/kubernetes/integrations/ +- link: /containers/kubernetes/integrations/ tag: Documentation - text: Créer et charger un modèle d'intégration Autodiscovery + text: Configurer les intégrations avec Autodiscovery sur Kubernetes +- link: /containers/docker/integrations/ + tag: Documentation + text: Configurer les intégrations avec Autodiscovery sur Docker - link: /agent/guide/ad_identifiers/ tag: Documentation text: Associer un conteneur au modèle d'intégration correspondant @@ -16,26 +21,28 @@ further_reading: title: Template variables Autodiscovery --- -Utilisez les template variables suivantes lors de la configuration d'Autodiscovery afin d'attribuer de façon dynamique les valeurs de votre conteneur : - -| Template variable | Description | -| -------------------------- | --- | -| `"%%host%%"` | Détecte automatiquement le réseau. Dans le cas des conteneurs à réseau unique, cette template variable renvoie l'adresse IP correspondante. | -| `"%%host_%%"` | Indique le nom du réseau à utiliser, en cas d'association à plusieurs réseaux. | -| `"%%port%%"` | Utilise le port exposé le plus élevé lorsque les ports sont **triés numériquement par ordre croissant**.
Exemple : `8443` pour un conteneur qui expose les ports `80`, `443` et `8443`. | -| `"%%port_%%"` | Utilise le port `` **trié numériquement par ordre croissant**.
Exemple : si un conteneur expose les ports `80`, `443` et `8443`, `"%%port_0%%` correspond au port `80` et `"%%port_1%%"` au port `443`. | -| `"%%port_%%"` | Utilise le port associé au nom du port ``. | -| `"%%pid%%"` | Récupère l'ID du processus de conteneur renvoyé par `docker inspect --format '{{.State.Pid}}' `. | -| `"%%hostname%%"` | Récupère la valeur `hostname` à partir de la configuration du conteneur. À n'utiliser que lorsque la variable `"%%host%%"` ne parvient pas à récupérer une adresse IP fiable (par exemple : [ECS en mode AWSVPC][1]). | -| `"%%env_%%"` | Utilise le contenu de la variable d'environnement `$` **comme l'indique le processus de l'Agent**. | -| `"%%kube_namespace%%"` | Détecte automatiquement l'espace de nommage Kubernetes. | -| `"%%kube_pod_name%%"` | Détecte automatiquement le nom du pod Kubernetes. | -| `"%%kube_pod_uid%%"` | Détecte automatiquement l'UID du pod Kubernetes. | +[Autodiscovery][1] vous permet de définir des configurations statiques pour des ressources dynamiques comme les conteneurs. + +Vous pouvez utiliser les variables de modèle suivantes pour attribuer dynamiquement les valeurs de votre conteneur : + +| Template variable | Rôle | +| -------------------------- | --- | +| `"%%host%%"` | L'adresse IP réseau du conteneur. | +| `"%%host_%%"` | Lorsque le conteneur est attaché à plusieurs réseaux, renvoie le nom de réseau à utiliser. | +| `"%%port%%"` | Le port exposé le plus élevé **trié numériquement et par ordre croissant**.
Par exemple, renvoie `8443` pour un conteneur qui expose les ports `80`, `443` et `8443`. | +| `"%%port_%%"` | Le port `` **trié numériquement et par ordre croissant**.
Par exemple, si un conteneur expose les ports `80`, `443` et `8443`, `"%%port_0%%` fait référence au port `80` et `"%%port_1%%"` fait référence au port `443`. | +| `"%%port_%%"` | Le port associé au nom de port ``. | +| `"%%pid%%"` | L'ID de processus du conteneur, tel que renvoyé par `docker inspect --format '{{.State.Pid}}' `. | +| `"%%hostname%%"` | La valeur `hostname` de la configuration du conteneur. Utilisez cette variable uniquement si la variable `"%%host%%"` ne peut pas récupérer une adresse IP fiable (par exemple, en [mode ECS awsvpc][2]). | +| `"%%env_%%"` | Le contenu de la variable d'environnement `$` **tel que vu par le processus de l'Agent**. | +| `"%%kube_namespace%%"` | L'espace de nommage Kubernetes. | +| `"%%kube_pod_name%%"` | Le nom de pod Kubernetes. | +| `"%%kube_pod_uid%%"` | L'UID de pod Kubernetes. | **Alternative** : -* Pour `"%%host%%"` : si l'Agent n'est pas capable de la trouver, l'IP de réseau `bridge` est utilisée comme valeur alternative pour cette template variable. -* Pour `"%%host_%%" : si le `` spécifié n'a pas été trouvé, cette template variable se comporte comme `"%%host%%"`. +* Pour la variable de modèle `"%%host%%"` : si l'Agent n'est pas en mesure de trouver l'adresse IP, cette variable de modèle revient à l'adresse IP du réseau `bridge`. +* Pour `"%%host_%%"` : si le `` spécifié est introuvable, cette variable de modèle se comporte comme `"%%host%%"`. Les template variables ne sont pas toutes prises en charge, selon votre plateforme : @@ -49,4 +56,5 @@ Les template variables ne sont pas toutes prises en charge, selon votre platefor {{< partial name="whats-next/whats-next.html" >}} -[1]: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking.html \ No newline at end of file +[1]: /fr/getting_started/containers/autodiscovery +[2]: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking.html \ No newline at end of file diff --git a/content/fr/containers/guide/v2alpha1_migration.md b/content/fr/containers/guide/v2alpha1_migration.md new file mode 100644 index 00000000000..e4d84cef843 --- /dev/null +++ b/content/fr/containers/guide/v2alpha1_migration.md @@ -0,0 +1,76 @@ +--- +dependencies: +- https://github.com/DataDog/datadog-operator/blob/main/docs/v2alpha1_migration.md +title: Migrer les CRD DatadogAgent vers v2alpha1 +--- +Cette page explique comment convertir vos Custom Resources Definitions (CRD) DatadogAgent de `v1alpha1` vers la version `v2alpha1` utilisée par l'opérateur Datadog v1.0.0+. + +## Prérequis + +* Avoir terminé la migration du chart Helm de l'opérateur Datadog v1.0.0+. Pour plus de détails, consultez le [guide de migration][1]. +* Exécuter `cert-manager` avec `installCRDs` défini sur `true` : + ```shell + helm install \ + cert-manager jetstack/cert-manager \ + --version v1.11.0 \ + --set installCRDs=true + ``` +* Exécuter l'opérateur Datadog v1.0.0+ avec le Conversion Webhook Server activé : + ```shell + helm install \ + datadog-operator datadog/datadog-operator \ + --set image.tag=1.0.0 \ + --set datadogCRDs.migration.datadogAgents.version=v2alpha1 \ + --set datadogCRDs.migration.datadogAgents.useCertManager=true \ + --set datadogCRDs.migration.datadogAgents.conversionWebhook.enabled=true + ``` + +## Convertir DatadogAgent/v1alpha1 en DatadogAgent/v2alpha1 + +L'opérateur Datadog exécute un réconciliateur pour les objets v2alpha1 et démarre également un Conversion Webhook Server, exposé sur le port 9443. L'API Server utilise ce serveur pour convertir les CRD DatadogAgent v1alpha1 en v2alpha1. + +1. Transférer un port local vers le Conversion Webhook Server exposé sur le port 9443 : + + ```shell + kubectl port-forward 2345:9443 + ``` + +2. Enregistrez une définition DatadogAgent `v1alpha1` au format JSON. Vous pouvez utiliser un outil comme `yq`. + +3. Exécuter une commande `curl` ciblant l'endpoint `/convert` avec votre JSON DatadogAgent.v1alpha1 : + + ``` shell + curl -k https://localhost:2345/convert -X POST -d '{"request":{"uid":"123", "desiredAPIVersion":"datadoghq.com/v2alpha1", "objects":[{ + "apiVersion": "datadoghq.com/v1alpha1", + "kind": "DatadogAgent", + "metadata": { + "name": "datadog" + }, + "spec": { + "credentials": { + "apiKey": "DATADOG_API_KEY", + "appKey": "DATADOG_APP_KEY" + } + } + }]}}' + ``` + + Cela renvoie une réponse avec votre définition DatadogAgent `v2alpha1` convertie : + + ```yaml + kind: DatadogAgent + apiVersion: datadoghq.com/v2alpha1 + metadata: + name: datadog + creationTimestamp: null + spec: + features: {} + global: + credentials: + apiKey: + appKey: + status: + conditions: null + ``` + +[1]: https://github.com/DataDog/helm-charts/blob/main/charts/datadog-operator/README.md#migrating-to-the-version-10-of-the-datadog-operator \ No newline at end of file diff --git a/content/fr/containers/kubernetes/control_plane.md b/content/fr/containers/kubernetes/control_plane.md index 9a2ff2bb124..6844043ae20 100644 --- a/content/fr/containers/kubernetes/control_plane.md +++ b/content/fr/containers/kubernetes/control_plane.md @@ -1,6 +1,8 @@ --- aliases: - /fr/agent/kubernetes/control_plane +description: Surveiller les composants du plan de contrôle Kubernetes, notamment l'API + Server, etcd, le Controller Manager et le Scheduler further_reading: - link: agent/kubernetes/log tag: Documentation @@ -33,8 +35,9 @@ Grâce aux intégrations Datadog pour le [serveur d'API][1], [Etcd][2], [Control * [Kubernetes sur Amazon EKS](#EKS) * [Kubernetes sur OpenShift 4](#OpenShift4) * [Kubernetes sur OpenShift 3](#OpenShift3) +* [Kubernetes sur Talos Linux](#TalosLinux) * [Kubernetes sur Rancher Kubernetes Engine (version 2.5+)](#RKE) -* [Kubernetes sur Rancher Kubernetes Engine (version antérieure à 2.5)](#RKEAvant2_5) +* [Kubernetes on Rancher Kubernetes Engine (\}} -{{% tab "Helm" %}} - -`values.yaml` personnalisé : - -```yaml -datadog: - apiKey: - appKey: - clusterName: - kubelet: - tlsVerify: false - ignoreAutoConfig: - - etcd - confd: - etcd.yaml: |- - ad_identifiers: - - etcd - instances: - - prometheus_url: https://%%host%%:2379/metrics - tls_ca_cert: /host/etc/kubernetes/pki/etcd/ca.crt - tls_cert: /host/etc/kubernetes/pki/etcd/server.crt - tls_private_key: /host/etc/kubernetes/pki/etcd/server.key -agents: - volumes: - - hostPath: - path: /etc/kubernetes/pki/etcd - name: etcd-certs - volumeMounts: - - name: etcd-certs - mountPath: /host/etc/kubernetes/pki/etcd - readOnly: true - tolerations: - - effect: NoSchedule - key: node-role.kubernetes.io/master - operator: Exists -``` +{{% tab "Operator Datadog" %}} -{{% /tab %}} -{{% tab "Operator" %}} - -Ressource Kubernetes DatadogAgent : - -```yaml +{{< code-block lang="yaml" filename="datadog-agent.yaml" >}} kind: DatadogAgent apiVersion: datadoghq.com/v2alpha1 metadata: @@ -100,9 +63,9 @@ metadata: spec: global: credentials: - apiKey: - appKey: - clusterName: + apiKey: + appKey: + clusterName: kubelet: tlsVerify: false override: @@ -148,37 +111,20 @@ data: tls_ca_cert: /host/etc/kubernetes/pki/etcd/ca.crt tls_cert: /host/etc/kubernetes/pki/etcd/server.crt tls_private_key: /host/etc/kubernetes/pki/etcd/server.key -``` +{{< /code-block >}} {{% /tab %}} -{{< /tabs >}} - -### Controller Manager et Scheduler - -#### Ports non sécurisés - -Si les ports non sécurisés de vos instances Controller Manager et Scheduler sont activés, l'Agent Datadog découvre les intégrations et commence à recueillir des métriques sans nécessiter de configuration supplémentaire. - -#### Ports sécurisés - -Les ports sécurisés activent des processus d'authentification et d'autorisation afin de protéger les composants de votre plan de contrôle. L'Agent Datadog peut recueillir des métriques à partir de Controller Manager et Scheduler en ciblant leurs ports sécurisés. - -{{< tabs >}} {{% tab "Helm" %}} -`values.yaml` personnalisé : - -```yaml +{{< code-block lang="yaml" filename="datadog-values.yaml" >}} datadog: - apiKey: - appKey: - clusterName: + apiKey: + appKey: + clusterName: kubelet: tlsVerify: false ignoreAutoConfig: - etcd - - kube_scheduler - - kube_controller_manager confd: etcd.yaml: |- ad_identifiers: @@ -188,20 +134,6 @@ datadog: tls_ca_cert: /host/etc/kubernetes/pki/etcd/ca.crt tls_cert: /host/etc/kubernetes/pki/etcd/server.crt tls_private_key: /host/etc/kubernetes/pki/etcd/server.key - kube_scheduler.yaml: |- - ad_identifiers: - - kube-scheduler - instances: - - prometheus_url: https://%%host%%:10259/metrics - ssl_verify: false - bearer_token_auth: true - kube_controller_manager.yaml: |- - ad_identifiers: - - kube-controller-manager - instances: - - prometheus_url: https://%%host%%:10257/metrics - ssl_verify: false - bearer_token_auth: true agents: volumes: - hostPath: @@ -215,14 +147,26 @@ agents: - effect: NoSchedule key: node-role.kubernetes.io/master operator: Exists -``` +{{< /code-block >}} {{% /tab %}} -{{% tab "Operator" %}} -Ressource Kubernetes DatadogAgent : +{{< /tabs >}} + +### Controller Manager et Scheduler -```yaml +#### Ports non sécurisés + +Si les ports non sécurisés de vos instances Controller Manager et Scheduler sont activés, l'Agent Datadog découvre les intégrations et commence à collecter les métriques sans configuration supplémentaire. + +#### Ports sécurisés + +Les ports sécurisés activent des processus d'authentification et d'autorisation afin de protéger les composants de votre plan de contrôle. L'Agent Datadog peut recueillir des métriques à partir de Controller Manager et Scheduler en ciblant leurs ports sécurisés. + +{{< tabs >}} +{{% tab "Operator Datadog" %}} + +{{< code-block lang="yaml" filename="datadog-agent.yaml" >}} kind: DatadogAgent apiVersion: datadoghq.com/v2alpha1 metadata: @@ -230,9 +174,9 @@ metadata: spec: global: credentials: - apiKey: - appKey: - clusterName: + apiKey: + appKey: + clusterName: kubelet: tlsVerify: false override: @@ -300,9 +244,62 @@ data: - prometheus_url: https://%%host%%:10257/metrics ssl_verify: false bearer_token_auth: true -``` +{{< /code-block >}} + +{{% /tab %}} +{{% tab "Helm" %}} + +{{< code-block lang="yaml" filename="datadog-values.yaml" >}} +datadog: + apiKey: + appKey: + clusterName: + kubelet: + tlsVerify: false + ignoreAutoConfig: + - etcd + - kube_scheduler + - kube_controller_manager + confd: + etcd.yaml: |- + ad_identifiers: + - etcd + instances: + - prometheus_url: https://%%host%%:2379/metrics + tls_ca_cert: /host/etc/kubernetes/pki/etcd/ca.crt + tls_cert: /host/etc/kubernetes/pki/etcd/server.crt + tls_private_key: /host/etc/kubernetes/pki/etcd/server.key + kube_scheduler.yaml: |- + ad_identifiers: + - kube-scheduler + instances: + - prometheus_url: https://%%host%%:10259/metrics + ssl_verify: false + bearer_token_auth: true + kube_controller_manager.yaml: |- + ad_identifiers: + - kube-controller-manager + instances: + - prometheus_url: https://%%host%%:10257/metrics + ssl_verify: false + bearer_token_auth: true +agents: + volumes: + - hostPath: + path: /etc/kubernetes/pki/etcd + name: etcd-certs + volumeMounts: + - name: etcd-certs + mountPath: /host/etc/kubernetes/pki/etcd + readOnly: true + tolerations: + - effect: NoSchedule + key: node-role.kubernetes.io/master + operator: Exists +{{< /code-block >}} {{% /tab %}} + {{< /tabs >}} **Remarques :** @@ -323,31 +320,255 @@ scheduler: ## Kubernetes sur Amazon EKS {#EKS} -Sur Amazon Elastic Kubernetes Service (EKS), les [métriques du serveur d'API sont exposées][5]. Ainsi, l'Agent Datadog peut récupérer ces métriques à l'aide de checks d'endpoint, tel que décrit dans la [section relative aux checks de métriques du serveur d'API de Kubernetes][1]. Pour configurer le check, ajoutez les annotations suivantes au service `default/kubernetes` : +### Méthode recommandée + +
Cette fonctionnalité est en version Preview.
+ +Datadog prend en charge la surveillance des composants du plan de contrôle Kubernetes, notamment l'API Server, le Controller Manager et le Scheduler. + +{{< tabs >}} +{{% tab "Operator Datadog" %}} + +#### Prérequis + +1. Opérateur Datadog >= `v1.18.0` +1. Agent Datadog >= `v7.69` + +#### Configuration générale + +La surveillance du plan de contrôle est activée par défaut, mais nécessite l'activation de l'introspection. + +Vous pouvez activer l'introspection en utilisant le [chart Helm datadog-operator](https://github.com/DataDog/helm-charts/tree/main/charts/datadog-operator) : + +{{< code-block lang="yaml" filename="datadog-agent.yaml" >}} +introspection: + enabled: true +{{< /code-block >}} + +En utilisant la ligne de commande : +```shell +helm install datadog-operator datadog/datadog-operator --set introspection.enabled=true +``` + +Étant donné que cette fonctionnalité est activée par défaut, vous pouvez déployer une spec DatadogAgent minimale. + +{{% /tab %}} + +{{% tab "Helm" %}} + +#### Prérequis + +1. Version du chart Helm >= `3.150.0` +1. Agent Datadog >= `v7.69` + +#### Configuration générale + +Activez la surveillance du plan de contrôle en utilisant l'option `providers.eks.controlPlaneMonitoring` : + +{{< code-block lang="yaml" filename="datadog-values.yaml" >}} +datadog: + apiKey: + appKey: + clusterName: +providers: + eks: + controlPlaneMonitoring: true +{{< /code-block >}} + +{{% /tab %}} +{{< /tabs >}} + +#### Validation +Vérifier que les checks sont en cours d'exécution : +```shell +kubectl exec -- agent clusterchecks +``` + +Recherchez : +- `kube_apiserver_metrics` +- `kube_controller_manager` +- `kube_scheduler` + +Vous devriez voir les métriques du plan de contrôle dans Datadog, notamment : +- `kube_apiserver.*` +- `kube_controller_manager.*` +- `kube_scheduler.*` + +### Configuration héritée + +Amazon Elastic Kubernetes Service (EKS) prend en charge la surveillance de tous les composants du plan de contrôle à l'aide de cluster checks. + +#### Prérequis +- Un cluster EKS exécutant Kubernetes version >= 1.28 +- Déployer l'Agent en utilisant l'un des éléments suivants : + - Version du chart Helm >= `3.90.1` + - Opérateur Datadog >= `v1.13.0` +- Activez l'[Agent de cluster][6] Datadog. + +Ajouter les annotations suivantes au service `default/kubernetes` : ```yaml annotations: - ad.datadoghq.com/endpoints.check_names: '["kube_apiserver_metrics"]' - ad.datadoghq.com/endpoints.init_configs: '[{}]' - ad.datadoghq.com/endpoints.instances: - '[{ "prometheus_url": "https://%%host%%:%%port%%/metrics", "bearer_token_auth": "true" }]' + ad.datadoghq.com/endpoints.checks: |- + { + "kube_apiserver_metrics": { + "init_config": {}, + "instances": [ + { + "prometheus_url": "https://%%host%%:%%port%%/metrics", + "bearer_token_auth": "true" + } + ] + } + } + ad.datadoghq.com/service.checks: |- + { + "kube_controller_manager": { + "init_config": {}, + "instances": [ + { + "prometheus_url": "https://%%host%%:%%port%%/apis/metrics.eks.amazonaws.com/v1/kcm/container/metrics", + "extra_headers": {"accept":"*/*"}, + "bearer_token_auth": "true", + "tls_ca_cert": "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt" + } + ] + }, + "kube_scheduler": { + "init_config": {}, + "instances": [ + { + "prometheus_url": "https://%%host%%:%%port%%/apis/metrics.eks.amazonaws.com/v1/ksh/container/metrics", + "extra_headers": {"accept":"*/*"}, + "bearer_token_auth": "true", + "tls_ca_cert": "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt" + } + ] + } + } ``` -Les autres composants du plan de contrôle ne sont pas exposés dans EKS, et ne peuvent donc pas être surveillés. - +**Remarques :** +- Amazon expose les métriques `kube_controller_manager` et `kube_scheduler` sous le groupe d'API [`metrics.eks.amazonaws.com`][11]. +- L'ajout de `"extra_headers":{"accept":"*/*"}` empêche les erreurs `HTTP 406` lors de l'interrogation de l'API de métriques EKS. ## Kubernetes sur OpenShift 4 {#OpenShift4} +
Cette fonctionnalité est en version Preview.
+ +Datadog prend en charge la surveillance des composants du plan de contrôle Kubernetes, notamment l'API Server, etcd, le Controller Manager et le Scheduler. + +{{< tabs >}} +{{% tab "Operator Datadog" %}} + +#### Prérequis + +1. Opérateur Datadog >= `v1.18.0` +1. Agent Datadog >= `v7.69` + +**Remarque** : `etcd` n'est pas pris en charge sur les versions 4.0-4.13. + +#### Configuration générale + +La surveillance du plan de contrôle est activée par défaut, mais nécessite l'activation de l'introspection. + +Vous pouvez activer l'introspection en utilisant le [chart Helm datadog-operator][12] : + +{{< code-block lang="yaml" filename="datadog-agent.yaml" >}} +introspection: + enabled: true +{{< /code-block >}} + +En utilisant la ligne de commande : +```shell +helm install datadog-operator datadog/datadog-operator --set introspection.enabled=true +``` + +Ou, pour les **utilisateurs d'OpenShift** qui ont installé l'opérateur via OperatorHub/Marketplace (la [méthode recommandée](install-openshift.md)), en patchant la version de service de cluster de l'opérateur : + +```shell +oc patch csv -n \ + --type='json' \ + -p='[{"op": "add", "path": "/spec/install/spec/deployments/0/spec/template/spec/containers/0/args/-", "value": "--introspectionEnabled=true"}]' +``` + +Étant donné que cette fonctionnalité est activée par défaut, vous pouvez déployer une spec DatadogAgent minimale. + +Activer `features.clusterChecks.useClusterChecksRunners` pour planifier les checks ici ; sinon, les checks du plan de contrôle s'exécutent sur l'Agent de nœud. + +Pour OpenShift 4.14 et versions ultérieures, la surveillance etcd nécessite de copier les certificats etcd. Vérifiez les logs de l'opérateur pour obtenir la commande exacte. Consultez l'exemple suivant (ajustez l'espace de nommage si nécessaire) : + +```shell +oc get secret etcd-metric-client -n openshift-etcd-operator -o yaml | \ + sed 's/namespace: openshift-etcd-operator/namespace: datadog/' | \ + oc apply -f - +``` + +[12]: https://github.com/DataDog/helm-charts/tree/main/charts/datadog-operator + +{{% /tab %}} +{{% tab "Helm" %}} + +#### Prérequis + +1. Version du chart Helm >= `3.150.0` +1. Agent Datadog >= `v7.69` + +**Remarque** : `etcd` n'est pas pris en charge sur les versions 4.0-4.13. + +#### Configuration générale + +Activez la surveillance du plan de contrôle en utilisant l'option `providers.openshift.controlPlaneMonitoring` : + +{{< code-block lang="yaml" filename="datadog-values.yaml" >}} +datadog: + apiKey: + appKey: + clusterName: +providers: + openshift: + controlPlaneMonitoring: true +{{< /code-block >}} + +Pour OpenShift 4.14 et versions ultérieures, la surveillance etcd nécessite de copier les certificats etcd. Pour les copier dans le même espace de nommage que l'Agent Datadog : + +```shell +oc get secret etcd-metric-client -n openshift-etcd-operator -o yaml | sed 's/namespace: openshift-etcd-operator/namespace: /' | oc create -f - +``` + +{{% /tab %}} +{{< /tabs >}} + +#### Validation +Vérifiez que les checks sont en cours d'exécution : +```shell +kubectl exec -- agent clusterchecks +``` + +Cherchez : +- `kube_apiserver_metrics` +- `kube_controller_manager` +- `kube_scheduler` +- `etcd` + +Vous devriez voir les métriques du plan de contrôle dans Datadog, notamment : +- `kube_apiserver.*` +- `kube_controller_manager.*` +- `kube_scheduler.*` +- `etcd.*` + +### Configuration héritée + Sur OpenShift 4, tous les composants du plan de contrôle peuvent être surveillés à l'aide de checks d'endpoint. -### Prérequis +#### Prérequis 1. Activez l'[Agent de cluster][6] Datadog. 1. Activez les [checks de cluster][7]. 1. Activez les [checks d'endpoint][8]. 1. Vérifiez que votre compte dispose de suffisamment d'autorisations pour pouvoir modifier des services et créer des secrets. -### Serveur d'API +#### Serveur d'API Le serveur d'API s'exécute derrière le service `kubernetes` dans l'espace de nommage `default`. Annotez ce service avec la configuration `kube_apiserver_metrics` : @@ -362,16 +583,16 @@ oc annotate service kubernetes -n default 'ad.datadoghq.com/endpoints.resolve=ip La dernière annotation `ad.datadoghq.com/endpoints.resolve` est requise, car le service est exécuté devant les pods statiques. L'Agent de cluster Datadog planifie les checks en tant que checks d'endpoint et les distribue aux exécuteurs de checks de cluster. Pour identifier les nœuds sur lesquels ils s'exécutent, utilisez la commande suivante : ```shell -oc exec -it -n -- agent clusterchecks +oc exec -it -n -- agent clusterchecks ``` +#### Etcd -### Etcd - -Pour communiquer avec le service Etcd, vous devez utiliser des certificats. Vous trouverez les certificats requis dans le secret `kube-etcd-client-certs` de l'espace de nommage `openshift-monitoring`. Pour que l'Agent Datadog puisse accéder à ces certificats, commencez par les copier dans le même espace de nommage que celui dans lequel l'Agent Datadog s'exécute : +{{% collapse-content title= "Etcd OpenShift 4.0 - 4.13" level="h4" %}} +Des certificats sont nécessaires pour communiquer avec le service Etcd, qui peuvent être trouvés dans le secret `kube-etcd-client-certs` dans l'espace de nommage `openshift-monitoring`. Pour donner à l'Agent Datadog l'accès à ces certificats, copiez-les d'abord dans le même espace de nommage dans lequel l'Agent Datadog est exécuté : ```shell -oc get secret kube-etcd-client-certs -n openshift-monitoring -o yaml | sed 's/namespace: openshift-monitoring/namespace: /' | oc create -f - +oc get secret kube-etcd-client-certs -n openshift-monitoring -o yaml | sed 's/namespace: openshift-monitoring/namespace: /' | oc create -f - ``` @@ -381,9 +602,36 @@ Ces certificats doivent être montés sur les pods des exécuteurs de checks de {{< tabs >}} +{{% tab "Operator Datadog" %}} + +{{< code-block lang="yaml" filename="datadog-agent.yaml" >}} +kind: DatadogAgent +apiVersion: datadoghq.com/v2alpha1 +metadata: + name: datadog +spec: + override: + clusterChecksRunner: + containers: + agent: + volumeMounts: + - name: etcd-certs + readOnly: true + mountPath: /etc/etcd-certs + - name: disable-etcd-autoconf + mountPath: /etc/datadog-agent/conf.d/etcd.d + volumes: + - name: etcd-certs + secret: + secretName: kube-etcd-client-certs + - name: disable-etcd-autoconf + emptyDir: {} +{{< /code-block >}} + +{{% /tab %}} {{% tab "Helm" %}} -```yaml +{{< code-block lang="yaml" filename="datadog-values.yaml" >}} ... clusterChecksRunner: volumes: @@ -398,12 +646,45 @@ clusterChecksRunner: readOnly: true - name: disable-etcd-autoconf mountPath: /etc/datadog-agent/conf.d/etcd.d -``` +{{< /code-block >}} {{% /tab %}} -{{% tab "Operator" %}} -```yaml +{{< /tabs >}} + +Annotez ensuite le service s'exécutant devant Etcd : + +```shell +oc annotate service etcd -n openshift-etcd 'ad.datadoghq.com/endpoints.check_names=["etcd"]' +oc annotate service etcd -n openshift-etcd 'ad.datadoghq.com/endpoints.init_configs=[{}]' +oc annotate service etcd -n openshift-etcd 'ad.datadoghq.com/endpoints.instances=[{"prometheus_url": "https://%%host%%:%%port%%/metrics", "tls_ca_cert": "/etc/etcd-certs/etcd-client-ca.crt", "tls_cert": "/etc/etcd-certs/etcd-client.crt", + "tls_private_key": "/etc/etcd-certs/etcd-client.key"}]' +oc annotate service etcd -n openshift-etcd 'ad.datadoghq.com/endpoints.resolve=ip' + +``` + +L'Agent de cluster Datadog planifie les checks en tant que checks d'endpoint et les distribue aux exécuteurs de check de cluster. + +{{% /collapse-content %}} + + +{{% collapse-content title="Etcd OpenShift 4.14 et versions ultérieures" level="h4" %}} + +Des certificats sont nécessaires pour communiquer avec le service Etcd, qui peuvent être trouvés dans le secret `etcd-metric-client` dans l'espace de nommage `openshift-etcd-operator`. Pour donner à l'Agent Datadog l'accès à ces certificats, copiez-les dans le même espace de nommage que l'Agent Datadog : + +```shell +oc get secret etcd-metric-client -n openshift-etcd-operator -o yaml | sed 's/namespace: openshift-etcd-operator/namespace: /' | oc create -f - +``` + +Ces certificats doivent être montés sur les pods des exécuteurs de checks de cluster, en ajoutant les volumes et volumeMounts tel que décrit ci-dessous. + +**Remarque** : des montages sont également inclus pour désactiver le fichier d'autoconfiguration du check Etcd fourni avec l'Agent. + + +{{< tabs >}} +{{% tab "Operator Datadog" %}} + +{{< code-block lang="yaml" filename="datadog-agent.yaml" >}} kind: DatadogAgent apiVersion: datadoghq.com/v2alpha1 metadata: @@ -422,14 +703,35 @@ spec: volumes: - name: etcd-certs secret: - secretName: kube-etcd-client-certs + secretName: etcd-metric-client - name: disable-etcd-autoconf emptyDir: {} -``` +{{< /code-block >}} {{% /tab %}} -{{< /tabs >}} +{{% tab "Helm" %}} +{{< code-block lang="yaml" filename="datadog-values.yaml" >}} +... +clusterChecksRunner: + volumes: + - name: etcd-certs + secret: + secretName: etcd-metric-client + - name: disable-etcd-autoconf + emptyDir: {} + volumeMounts: + - name: etcd-certs + mountPath: /host/etc/etcd + readOnly: true + - name: disable-etcd-autoconf + mountPath: /etc/datadog-agent/conf.d/etcd.d + +{{< /code-block >}} + +{{% /tab %}} + +{{< /tabs >}} Annotez ensuite le service s'exécutant devant Etcd : @@ -439,13 +741,14 @@ oc annotate service etcd -n openshift-etcd 'ad.datadoghq.com/endpoints.init_conf oc annotate service etcd -n openshift-etcd 'ad.datadoghq.com/endpoints.instances=[{"prometheus_url": "https://%%host%%:%%port%%/metrics", "tls_ca_cert": "/etc/etcd-certs/etcd-client-ca.crt", "tls_cert": "/etc/etcd-certs/etcd-client.crt", "tls_private_key": "/etc/etcd-certs/etcd-client.key"}]' oc annotate service etcd -n openshift-etcd 'ad.datadoghq.com/endpoints.resolve=ip' - ``` L'Agent de cluster Datadog planifie les checks en tant que checks d'endpoint et les distribue aux exécuteurs de check de cluster. +{{% /collapse-content %}} -### Controller Manager + +#### Controller Manager Le Controller Manager s'exécute derrière le service `kube-controller-manager` dans l'espace de nommage `openshift-kube-controller-manager`. Annotez ce service avec la configuration de check : @@ -462,7 +765,7 @@ L'Agent de cluster Datadog planifie les checks en tant que checks d'endpoint et -### Scheduler +#### Scheduler Le Scheduler s'exécute derrière le service `scheduler` dans l'espace de nommage `openshift-kube-scheduler`. Annotez ce service avec la configuration de check : @@ -504,7 +807,7 @@ oc annotate service kubernetes -n default 'ad.datadoghq.com/endpoints.resolve=ip La dernière annotation `ad.datadoghq.com/endpoints.resolve` est requise, car le service est exécuté devant les pods statiques. L'Agent de cluster Datadog planifie les checks en tant que checks d'endpoint et les distribue aux exécuteurs de checks de cluster. Pour identifier les nœuds sur lesquels ils s'exécutent, utilisez la commande suivante : ```shell -oc exec -it -n -- agent clusterchecks +oc exec -it -n -- agent clusterchecks ``` @@ -515,29 +818,9 @@ Pour communiquer avec le service Etcd, vous devez utiliser des certificats. Vous **Remarque** : des montages sont également inclus pour désactiver le fichier d'autoconfiguration du check Etcd fourni avec l'Agent. {{< tabs >}} -{{% tab "Helm" %}} +{{% tab "Operator Datadog" %}} -```yaml -... -clusterChecksRunner: - volumes: - - hostPath: - path: /etc/etcd - name: etcd-certs - - name: disable-etcd-autoconf - emptyDir: {} - volumeMounts: - - name: etcd-certs - mountPath: /host/etc/etcd - readOnly: true - - name: disable-etcd-autoconf - mountPath: /etc/datadog-agent/conf.d/etcd.d -``` - -{{% /tab %}} -{{% tab "Operator" %}} - -```yaml +{{< code-block lang="yaml" filename="datadog-agent.yaml" >}} kind: DatadogAgent apiVersion: datadoghq.com/v2alpha1 metadata: @@ -559,7 +842,27 @@ spec: path: /etc/etcd - name: disable-etcd-autoconf emptyDir: {} -``` +{{< /code-block >}} + +{{% /tab %}} +{{% tab "Helm" %}} + +{{< code-block lang="yaml" filename="datadog-values.yaml" >}} +... +clusterChecksRunner: + volumes: + - hostPath: + path: /etc/etcd + name: etcd-certs + - name: disable-etcd-autoconf + emptyDir: {} + volumeMounts: + - name: etcd-certs + mountPath: /host/etc/etcd + readOnly: true + - name: disable-etcd-autoconf + mountPath: /etc/datadog-agent/conf.d/etcd.d +{{< /code-block >}} {{% /tab %}} {{< /tabs >}} @@ -608,7 +911,134 @@ oc annotate service kube-controllers-copy -n kube-system 'ad.datadoghq.com/endpo L'Agent de cluster Datadog planifie les checks en tant que checks d'endpoint et les distribue aux exécuteurs de check de cluster. +## Kubernetes sur Talos Linux {#TalosLinux} + +Helm est la méthode d'installation recommandée pour Talos Linux. Utiliser Helm en définissant le flag `providers.talos.enabled` sur `true`. + +### Serveur d'API + +L'intégration du serveur d'API est automatiquement configurée. L'Agent Datadog la découvre automatiquement. + +### Etcd + +En fournissant un accès en lecture aux certificats etcd situés sur l'hôte, le check de l'Agent Datadog peut communiquer avec etcd et commencer à collecter les métriques etcd. +{{< code-block lang="yaml" filename="datadog-values.yaml" >}} +datadog: + apiKey: + appKey: + clusterName: + kubelet: + tlsVerify: false + ignoreAutoConfig: + - etcd + confd: + etcd.yaml: |- + # Vous pouvez configurer l'Agent pour exécuter ce check uniquement sur l'hôte où etcd est en cours d'exécution + # en utilisant `ad_identifiers` pour un pod qui ne serait en cours d'exécution que sur un nœud control plane. + # Cela permet d'éviter les erreurs lorsque l'Agent est exécuté sur des nœuds worker. + # Une autre approche consiste à exécuter un pod minimal sur le nœud control plane et à l'utiliser pour `ad_identifiers`. + ad_identifiers: + - kube-scheduler + instances: + # Il s'agit de l'adresse IP du nœud où les métriques sont exposées car kube-scheduler s'exécute en mode réseau host. + # Sinon, l'adresse IP peut être codée en dur sur l'adresse IP du nœud master (également dans la variable d'environnement `DD_KUBERNETES_KUBELET_HOST`). + - prometheus_url : https://%%host%%:2379/metrics + tls_ca_cert : /host/etc/kubernetes/pki/etcd/ca.crt + tls_cert : /host/etc/kubernetes/pki/etcd/server.crt + tls_private_key : /host/etc/kubernetes/pki/etcd/server.key +agents: + # Des tolérances sont nécessaires pour être planifié sur les nœuds de plan de contrôle exécutant etcd + tolerations: + - key: node-role.kubernetes.io/control-plane + operator: Exists + effect: NoSchedule + volumes: + # Sur Talos, les certificats etcd sont stockés dans /system/secrets/etcd + - hostPath: + path: /system/secrets/etcd + name: etcd-certs + volumeMounts: + - name: etcd-certs + mountPath: /host/etc/kubernetes/pki/etcd + readOnly: true +providers: + talos: + enabled: true +{{< /code-block >}} + +### Controller Manager et Scheduler + +#### Ports sécurisés + +Les ports sécurisés activent des processus d'authentification et d'autorisation afin de protéger les composants de votre plan de contrôle. L'Agent Datadog peut recueillir des métriques à partir de Controller Manager et Scheduler en ciblant leurs ports sécurisés. + +{{< code-block lang="yaml" filename="datadog-values.yaml" >}} +datadog: + apiKey: + appKey: + clusterName: + kubelet: + tlsVerify: false + ignoreAutoConfig: + - etcd + - kube_scheduler + - kube_controller_manager + confd: + etcd.yaml: |- + ad_identifiers: + - kube-scheduler + instances: + - prometheus_url: https://%%host%%:2379/metrics + tls_ca_cert: /host/etc/kubernetes/pki/etcd/ca.crt + tls_cert: /host/etc/kubernetes/pki/etcd/server.crt + tls_private_key: /host/etc/kubernetes/pki/etcd/server.key + kube_scheduler.yaml: |- + ad_identifiers: + - kube-scheduler + instances: + - prometheus_url: https://%%host%%:10259/metrics + ssl_verify: false + bearer_token_auth: true + kube_controller_manager.yaml: |- + ad_identifiers: + - kube-controller-manager + instances: + - prometheus_url: https://%%host%%:10257/metrics + ssl_verify: false + bearer_token_auth: true +agents: + tolerations: + - key: node-role.kubernetes.io/control-plane + operator: Exists + effect: NoSchedule + volumes: + - hostPath: + path: /system/secrets/etcd + name: etcd-certs + volumeMounts: + - name: etcd-certs + mountPath: /host/etc/kubernetes/pki/etcd + readOnly: true +providers: + talos: + enabled: true +{{< /code-block >}} + +**Remarques :** + +- Si vous utilisez des certificats autosignés, le champ `ssl_verify` des configurations `kube_controller_manager` et `kube_scheduler` doit être défini sur `false`. +- Lors du ciblage de ports sécurisés, l'option `bind-address` dans votre configuration Controller Manager et Scheduler doit être accessible par l'Agent Datadog. Appliquez le patch ci-dessous aux nœuds control-plane lors de la génération du cluster ; ou, pour les nœuds Talos en cours d'exécution, exécutez `talosctl patch mc -n --patch @controlplane-datadog-monitoring-patch.yaml`. + +{{< code-block lang="yaml" filename="controlplane-datadog-monitoring-patch.yaml" >}} +cluster: + controllerManager: + extraArgs: + bind-address: 0.0.0.0 + scheduler: + extraArgs: + bind-address: 0.0.0.0 +{{< /code-block >}} ## Kubernetes sur Rancher Kubernetes Engine (version 2.5+) {#RKE} @@ -630,7 +1060,7 @@ annotations: ad.datadoghq.com/endpoints.instances: '[{ "prometheus_url": "https://%%host%%:%%port%%/metrics", "bearer_token_auth": "true" }]' ``` -### Ajouter des services Kubernetes pour configurer les checks de découverte automatique +### Ajouter des services Kubernetes pour configurer les checks Autodiscovery Si vous ajoutez des services Kubernetes headless pour définir des configuration de check, l'Agent Datadog pourra cibler les pods `pushprox` et recueillir des métriques. @@ -710,41 +1140,9 @@ spec: Déployez l'Agent Datadog avec des manifestes basés sur les configurations suivantes : {{< tabs >}} -{{% tab "Helm" %}} - -`values.yaml` personnalisé : - -```yaml -datadog: - apiKey: - appKey: - clusterName: - kubelet: - tlsVerify: false -agents: - volumes: - - hostPath: - path: /opt/rke/etc/kubernetes/ssl - name: etcd-certs - volumeMounts: - - name: etcd-certs - mountPath: /host/opt/rke/etc/kubernetes/ssl - readOnly: true - tolerations: - - effect: NoSchedule - key: node-role.kubernetes.io/controlplane - operator: Exists - - effect: NoExecute - key: node-role.kubernetes.io/etcd - operator: Exists -``` - -{{% /tab %}} -{{% tab "Operator" %}} - -Ressource Kubernetes DatadogAgent : +{{% tab "Operator Datadog" %}} -```yaml +{{< code-block lang="yaml" filename="datadog-agent.yaml" >}} kind: DatadogAgent apiVersion: datadoghq.com/v2alpha1 metadata: @@ -755,9 +1153,9 @@ spec: enabled: true global: credentials: - apiKey: - appKey: - clusterName: + apiKey: + appKey: + clusterName: kubelet: tlsVerify: false override: @@ -779,13 +1177,41 @@ spec: - key: node-role.kubernetes.io/etcd operator: Exists effect: NoExecute -``` +{{< /code-block >}} + +{{% /tab %}} +{{% tab "Helm" %}} + +{{< code-block lang="yaml" filename="datadog-values.yaml" >}} +datadog: + apiKey: + appKey: + clusterName: + kubelet: + tlsVerify: false +agents: + volumes: + - hostPath: + path: /opt/rke/etc/kubernetes/ssl + name: etcd-certs + volumeMounts: + - name: etcd-certs + mountPath: /host/opt/rke/etc/kubernetes/ssl + readOnly: true + tolerations: + - effect: NoSchedule + key: node-role.kubernetes.io/controlplane + operator: Exists + - effect: NoExecute + key: node-role.kubernetes.io/etcd + operator: Exists +{{< /code-block >}} {{% /tab %}} {{< /tabs >}} -## Kubernetes sur Rancher Kubernetes Engine (version antérieure à 2.5) {#RKEAvant2_5} +## Kubernetes sur Rancher Kubernetes Engine (avant la v2.5) {#RKEBefore2_5} ### API Server, Controller Manager et Scheduler @@ -830,41 +1256,9 @@ Vous trouverez ci-dessous des exemples de configuration de l'Agent Datadog avec {{< tabs >}} -{{% tab "Helm" %}} - -`values.yaml` personnalisé : - -```yaml -datadog: - apiKey: - appKey: - clusterName: - kubelet: - tlsVerify: false -agents: - volumes: - - hostPath: - path: /opt/rke/etc/kubernetes/ssl - name: etcd-certs - volumeMounts: - - name: etcd-certs - mountPath: /host/opt/rke/etc/kubernetes/ssl - readOnly: true - tolerations: - - effect: NoSchedule - key: node-role.kubernetes.io/controlplane - operator: Exists - - effect: NoExecute - key: node-role.kubernetes.io/etcd - operator: Exists -``` - -{{% /tab %}} -{{% tab "Operator" %}} - -Ressource Kubernetes DatadogAgent : +{{% tab "Operator Datadog" %}} -```yaml +{{< code-block lang="yaml" filename="datadog-agent.yaml" >}} kind: DatadogAgent apiVersion: datadoghq.com/v2alpha1 metadata: @@ -875,9 +1269,9 @@ spec: enabled: true global: credentials: - apiKey: - appKey: - clusterName: + apiKey: + appKey: + clusterName: kubelet: tlsVerify: false override: @@ -899,7 +1293,35 @@ spec: - key: node-role.kubernetes.io/etcd operator: Exists effect: NoExecute -``` +{{< /code-block >}} + +{{% /tab %}} +{{% tab "Helm" %}} + +{{< code-block lang="yaml" filename="datadog-values.yaml" >}} +datadog: + apiKey: + appKey: + clusterName: + kubelet: + tlsVerify: false +agents: + volumes: + - hostPath: + path: /opt/rke/etc/kubernetes/ssl + name: etcd-certs + volumeMounts: + - name: etcd-certs + mountPath: /host/opt/rke/etc/kubernetes/ssl + readOnly: true + tolerations: + - effect: NoSchedule + key: node-role.kubernetes.io/controlplane + operator: Exists + - effect: NoExecute + key: node-role.kubernetes.io/etcd + operator: Exists +{{< /code-block >}} {{% /tab %}} {{< /tabs >}} @@ -950,7 +1372,7 @@ spec: Pour déployer le DaemonSet et la configuration de check, exécutez la commande suivante : ```shell -kubectl apply -f +kubectl apply -f ``` @@ -967,5 +1389,6 @@ Sur d'autres services gérés, comme Azure Kubernetes Service (AKS) et Google [6]: https://docs.datadoghq.com/fr/agent/cluster_agent/setup [7]: https://docs.datadoghq.com/fr/agent/cluster_agent/clusterchecks/ [8]: https://docs.datadoghq.com/fr/agent/cluster_agent/endpointschecks/ -[9]: https://rancher.com/docs/rancher/v2.0-v2.4/en/cluster-admin/nodes -[10]: https://github.com/DataDog/helm-charts/blob/main/examples/datadog/agent_on_rancher_values.yaml \ No newline at end of file +[9]: https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/manage-clusters/nodes-and-node-pools +[10]: https://github.com/DataDog/helm-charts/blob/main/examples/datadog/agent_on_rancher_values.yaml +[11]: https://docs.aws.amazon.com/eks/latest/userguide/view-raw-metrics.html \ No newline at end of file diff --git a/content/fr/containers/kubernetes/distributions.md b/content/fr/containers/kubernetes/distributions.md index 8e40c828a9d..6919befaea2 100644 --- a/content/fr/containers/kubernetes/distributions.md +++ b/content/fr/containers/kubernetes/distributions.md @@ -1,6 +1,8 @@ --- aliases: - /fr/agent/kubernetes/distributions +description: Instructions d'installation et de configuration spécifiques à la plateforme + pour l'Agent Datadog sur diverses distributions Kubernetes further_reading: - link: agent/kubernetes/log tag: Documentation @@ -28,7 +30,8 @@ title: Distributions Kubernetes ## Présentation -Cette section présente les particularités des principales distributions Kubernetes et propose des modèles de configuration dont vous pouvez vous servir comme de point de départ. Chacune de ces configurations peut être personnalisée afin d'intégrer des fonctionnalités Datadog. +Cette section vise à documenter les spécificités et à fournir une bonne configuration de base pour toutes les principales distributions Kubernetes. +Ces configurations peuvent ensuite être personnalisées pour ajouter n'importe quelle fonctionnalité Datadog. * [AWS Elastic Kubernetes Service (EKS)](#EKS) * [Azure Kubernetes Service (AKS)](#AKS) @@ -42,25 +45,40 @@ Cette section présente les particularités des principales distributions Kubern Aucune configuration particulière n'est requise. -Si vous utilisez le système d'exploitation AWS Bottlerocket sur vos nœuds, ajoutez ce qui suit pour activer la surveillance des conteneurs (check `containerd`) : - {{< tabs >}} -{{% tab "Helm" %}} +{{% tab "Operator Datadog" %}} + +Dans un cluster EKS, vous pouvez installer l'opérateur en utilisant [Helm][1] ou en tant qu'[add-on EKS][2]. -`values.yaml` personnalisé : +La configuration ci-dessous est conçue pour fonctionner avec les deux configurations (Helm ou add-on EKS) lorsque l'Agent est installé dans le même espace de nommage que l'opérateur Datadog. ```yaml -datadog: - apiKey: - appKey: - criSocketPath: /run/dockershim.sock - env: - - name: DD_AUTOCONFIG_INCLUDE_FEATURES - value: "containerd" +kind: DatadogAgent +apiVersion: datadoghq.com/v2alpha1 +metadata: + name: datadog +spec: + global: + clusterName: + credentials: + apiKey: + appKey: ``` +[1]:/fr/containers/kubernetes/installation/?tab=datadogoperator +[2]: /fr/agent/guide/operator-eks-addon + {{% /tab %}} -{{% tab "Operator" %}} + +{{< /tabs >}} + +## Azure Kubernetes Service (AKS) {#AKS} + +### Contrôleur d'admission +La fonctionnalité [contrôleur d'admission][1] facultative nécessite une configuration spécifique pour éviter une erreur lors de la réconciliation du webhook. + +{{< tabs >}} +{{% tab "Operator Datadog" %}} Ressource Kubernetes DatadogAgent : @@ -70,45 +88,137 @@ apiVersion: datadoghq.com/v2alpha1 metadata: name: datadog spec: - features: - admissionController: - enabled: false - externalMetricsServer: - enabled: false - useDatadogMetrics: false global: + clusterName: + site: credentials: - apiKey: - appKey: - criSocketPath: /run/dockershim.sock + apiKey: + appKey: override: clusterAgent: - image: - name: gcr.io/datadoghq/cluster-agent:latest + containers: + cluster-agent: + env: + - name: DD_ADMISSION_CONTROLLER_ADD_AKS_SELECTORS + value: "true" ``` +Remplacez `` par votre [site Datadog][1]. Votre site est {{< region-param key="dd_site" code="true" >}}. (Assurez-vous que le SITE correct pour votre compte est sélectionné à droite de cette page). + +[1]: /fr/getting_started/site +{{% /tab %}} +{{% tab "Helm" %}} + +`datadog-values.yaml` personnalisé : + +```yaml +datadog: + clusterName: + apiKey: + appKey: + +providers: + aks: + enabled: true +``` + +L'option `providers.aks.enabled` définit la variable d'environnement nécessaire `DD_ADMISSION_CONTROLLER_ADD_AKS_SELECTORS="true"` pour vous. + {{% /tab %}} {{< /tabs >}} -## Azure Kubernetes Service (AKS) {#AKS} +### Rotation des certificats de service Kubelet +Si votre cluster **n'a pas** la [rotation des certificats de service Kubelet][13] activée, vous devez fournir une configuration supplémentaire pour permettre à l'Agent Datadog de se connecter au Kubelet. La rotation des certificats de service Kubelet est activée dans les clusters Kubernetes 1.27 et versions ultérieures sur les pools de nœuds mis à jour après juillet 2025. + +Vos nœuds disposent de cette fonctionnalité si ils possèdent l'étiquette `kubernetes.azure.com/kubelet-serving-ca=cluster`. Vérifiez si tous vos nœuds possèdent cette étiquette en exécutant : + +```shell +kubectl get nodes -L kubernetes.azure.com/kubelet-serving-ca +``` + +Assurez-vous que tous vos nœuds affichent `cluster`. -L'intégration `Kubelet` nécessite une configuration spécifique afin de prendre en charge les certificats AKS. +#### Sans rotation des certificats de service Kubelet + +Si la rotation des certificats de service Kubelet n'est pas activée, fournissez la configuration Kubelet supplémentaire suivante : {{< tabs >}} +{{% tab "Operator Datadog" %}} + +Ressource Kubernetes DatadogAgent : + +```yaml +kind: DatadogAgent +apiVersion: datadoghq.com/v2alpha1 +metadata: + name: datadog +spec: + global: + clusterName: + site: + credentials: + apiKey: + appKey: + kubelet: + host: + fieldRef: + fieldPath: spec.nodeName + hostCAPath: /etc/kubernetes/certs/kubeletserver.crt + override: + clusterAgent: + containers: + cluster-agent: + env: + - name: DD_ADMISSION_CONTROLLER_ADD_AKS_SELECTORS + value: "true" +``` +{{% /tab %}} {{% tab "Helm" %}} -`values.yaml` personnalisé : +`datadog-values.yaml` personnalisé : ```yaml datadog: - apiKey: - appKey: + clusterName: + apiKey: + appKey: kubelet: - tlsVerify: false # Obligatoire à partir de l'Agent 7.35. Voir la section Remarques. -``` + host: + valueFrom: + fieldRef: + fieldPath: spec.nodeName + hostCAPath: /etc/kubernetes/certs/kubeletserver.crt +providers: + aks: + enabled: true +``` {{% /tab %}} -{{% tab "Operator" %}} +{{< /tabs >}} + +Dans ces versions de nœud AKS, le certificat Kubelet AKS nécessite de modifier le host Kubelet sur le `spec.nodeName` et l'emplacement `hostCAPath` du certificat, comme indiqué dans les extraits précédents. Cela active la vérification TLS. Sans ces modifications, l'Agent ne peut pas se connecter au Kubelet. + +
Une fois que la rotation des certificats de service Kubelet est activée dans votre cluster, supprimez cette configuration.
+ +Lorsque vous mettez à niveau votre cluster AKS, vous pouvez voir la fonctionnalité de rotation des certificats de service Kubelet activée automatiquement pour vous, ce qui peut avoir un impact négatif sur votre Agent Datadog si vous utilisez la configuration spéciale ci-dessus pour référencer le certificat `/etc/kubernetes/certs/kubeletserver.crt`. Lorsque la rotation des certificats de service Kubelet est activée, ce certificat est supprimé, ce qui entraîne : + +- Dans l'opérateur Datadog : le conteneur de l'Agent s'arrête en `Error`, car il ne peut pas se connecter au Kubelet, et il enregistre `Error while getting hostname, exiting: unable to reliably determine the host name` +- Dans Helm : le pod de l'Agent ne parvient pas à démarrer avec l'événement d'avertissement `MountVolume.SetUp failed for volume "kubelet-ca" : hostPath type check failed: /etc/kubernetes/certs/kubeletserver.crt is not a file` + +Dans ces cas, supprimez les configurations Kubelet supplémentaires. + +En alternative, vous pouvez également [vous connecter au Kubelet sans vérification TLS](#without-tls-verification). + +### Sans vérification TLS + +Dans certains clusters, la résolution DNS pour `spec.nodeName` à l'intérieur des pods ne fonctionne pas dans AKS. Cela affecte : + - Les nœuds Windows + - Les nœuds Linux, lorsque le cluster est configuré dans un réseau virtuel utilisant un DNS personnalisé + +Dans ce cas, utilisez la configuration AKS fournie ci-dessous pour définir `tlsVerify: false` et supprimer tous les paramètres pour le chemin host Kubelet (qui est défini par défaut sur `status.hostIP`). **Ne définissez pas le chemin host Kubelet et `tlsVerify: false` dans la même configuration**. + +{{< tabs >}} +{{% tab "Operator Datadog" %}} Ressource Kubernetes DatadogAgent : @@ -118,15 +228,13 @@ apiVersion: datadoghq.com/v2alpha1 metadata: name: datadog spec: - features: - admissionController: - enabled: true global: + clusterName: credentials: - apiKey: - appKey: + apiKey: + appKey: kubelet: - tlsVerify: false # Obligatoire à partir de l'Agent 7.35. Voir la section Remarques. + tlsVerify: false override: clusterAgent: containers: @@ -137,28 +245,26 @@ spec: ``` {{% /tab %}} -{{< /tabs >}} - -**Remarques** : - -- Depuis la version 7.35 de l'Agent, `tlsVerify: false` est requis, car aucun autre nom de l'objet (Subject Alternative Name ou SAN) n'est défini pour les certificats Kubelet dans AKS. - -- Avec certaines configurations, il est possible que la résolution DNS pour `spec.nodeName` dans les nœuds ne fonctionne pas dans AKS. Ce problème a été signalé sur tous les nœuds AKS Windows, et lorsque le cluster est configuré dans un réseau virtuel avec un DNS personnalisé sur des nœuds Linux. Dans ce cas, vous devez **impérativement** supprimer le champ `agent.config.kubelet.host` (valeur par défaut : `status.hostIP`) et utiliser `tlsVerify: false`. La variable d'environnement `DD_KUBELET_TLS_VERIFY=false` résout également ce problème. Ces deux méthodes permettent de désactiver la vérification du certificat du serveur. +{{% tab "Helm" %}} - ```yaml - env: - - name: DD_KUBELET_TLS_VERIFY - value: "false" - ``` -- La fonctionnalité Contrôleur d'admission sur AKS nécessite d'ajouter des sélecteurs pour éviter une erreur lors du rapprochement du webhook : +`datadog-values.yaml` personnalisé : ```yaml -clusterAgent: - env: - - name: "DD_ADMISSION_CONTROLLER_ADD_AKS_SELECTORS" - value: "true" +datadog: + clusterName: + apiKey: + appKey: + kubelet: + tlsVerify: false + +providers: + aks: + enabled: true ``` +{{% /tab %}} +{{< /tabs >}} + ## Google Kubernetes Engine (GKE) {#GKE} Il est possible de configurer deux modes d'opération pour GKE : @@ -179,57 +285,64 @@ Depuis la version 7.26 de l'Agent, aucune spécification spécifique n'est requ Le mode Autopilot de GKE requiert une configuration précise, indiquée ci-dessous. -Datadog vous conseille de spécifier des limites de ressources pour le conteneur de l'Agent. La limite par défaut d'Autopilot est relativement basse (50 mCPU et 100 Mi pour la mémoire) et peut rapidement entraîner l'OOMKill du conteneur de l'Agent, en fonction de votre environnement. Le cas échéant, définissez d'autres limites de ressources pour les conteneurs de l'Agent de trace et de l'Agent de processus. +Datadog recommande de spécifier des limites de ressources pour le conteneur de l'Agent. Autopilot définit une limite par défaut relativement faible (50m CPU, 100Mi mémoire) qui peut amener le conteneur de l'Agent à rapidement atteindre OOMKill en fonction de votre environnement. Le cas échéant, spécifiez également les limites de ressources pour les conteneurs Trace Agent, Process Agent et System-Probe. De plus, vous pouvez souhaiter créer une classe de priorité pour l'Agent afin de garantir sa planification. + +À partir de l'Agent `7.65.0+` et de la version `3.113.0+` du chart Helm, Datadog recommande d'utiliser `datadog.kubelet.useApiServer` pour que l'Agent interroge la liste des pods depuis l'API Server. Évitez d'utiliser le [port Kubelet en lecture seule obsolète][12]. + {{< tabs >}} {{% tab "Helm" %}} -`values.yaml` personnalisé : +`datadog-values.yaml` personnalisé : ```yaml datadog: - apiKey: - appKey: - clusterName: - - # Activer le nouveau check `kubernetes_state_core`. - kubeStateMetricsCore: - enabled: true - # Éviter de déployer le chart kube-state-metrics. - # Le nouveau `kubernetes_state_core` ne nécessite plus le déploiement de kube-state-metrics. - kubeStateMetricsEnabled: false + apiKey: + appKey: + clusterName: + + # The site of the Datadog intake to send Agent data to (example: `us3.datadoghq.com`) + # Default value is `datadoghq.com' (the US1 site) + # Documentation: https://docs.datadoghq.com/getting_started/site/ + site: + + # This option uses the API server to retrieve the node-level pod list from the API server. + # This setting is necessary to migrate away from the deprecated read-only kubelet port. + # Requires Agent 7.65.0+ and Datadog Helm chart version 3.113.0+. + kubelet: + useApiServer: true agents: containers: agent: - # Ressources pour le conteneur de l'Agent + # resources for the Agent container resources: requests: cpu: 200m memory: 256Mi - limits: - cpu: 200m - memory: 256Mi traceAgent: - # Ressources pour le conteneur de l'Agent de trace + # resources for the Trace Agent container resources: requests: cpu: 100m memory: 200Mi - limits: - cpu: 100m - memory: 200Mi processAgent: - # Ressources pour le conteneur de l'Agent de processus + # resources for the Process Agent container resources: requests: cpu: 100m memory: 200Mi - limits: + + systemProbe: + # resources for the System Probe container + resources: + requests: cpu: 100m - memory: 200Mi + memory: 400Mi + + priorityClassCreate: true providers: gke: @@ -239,101 +352,103 @@ providers: {{% /tab %}} {{< /tabs >}} +### Pods Spot et classes de calcul -## Red Hat OpenShift {#Openshift} - -OpenShift est doté par défaut d'une sécurité renforcée (SELinux et SecurityContextConstraints) et nécessite donc une configuration particulière : -- Créez une SCC pour l'Agent de nœud et l'Agent de cluster. -- Indiquez le chemin du socket CRI, car OpenShift utilise le runtime de conteneur CRI-O. -- Il arrive que les certificats d'API Kubelet ne soient pas signés par l'autorité de certification du cluster. -- Vous devez définir des tolérances pour planifier l'Agent de nœud sur les nœuds `master` et `infra`. -- Le nom du cluster doit être défini et ne peut pas être récupéré automatiquement à partir du fournisseur de cloud. - -Cette configuration est disponible pour OpenShift 3.11 et 4, mais est optimisée pour OpenShift 4. +L'utilisation de [pods Spot][10] dans les clusters GKE Autopilot introduit des [taints][9] sur les nœuds GKE Spot correspondants. Lors de l'utilisation de pods Spot, une configuration supplémentaire est requise pour fournir au DaemonSet de l'Agent une tolérance correspondante. {{< tabs >}} {{% tab "Helm" %}} +```yaml +agents: + #(...) + # agents.tolerations -- Allow the DaemonSet to schedule on tainted nodes (requires Kubernetes >= 1.6) + tolerations: + - effect: NoSchedule + key: cloud.google.com/gke-spot + operator: Equal + value: "true" +``` +{{% /tab %}} +{{< /tabs >}} -`values.yaml` personnalisé : +De même, lors de l'utilisation de [classes de calcul GKE Autopilot][11] pour exécuter des workloads ayant des exigences matérielles spécifiques, prenez note des [taints][9] que GKE Autopilot applique à ces nœuds spécifiques et ajoutez des tolérances correspondantes au DaemonSet de l'Agent. Vous pouvez faire correspondre les tolérances sur vos pods correspondants. Par exemple, pour la classe de calcul `Scale-Out`, utilisez une tolérance comme : +{{< tabs >}} +{{% tab "Helm" %}} ```yaml -datadog: - apiKey: - appKey: - clusterName: - criSocketPath: /var/run/crio/crio.sock - # Selon votre configuration DNS/SSL, il n'est pas forcément possible de vérifier correctement le certificat. - # Si vous utilisez une autorité de certification adéquate, vous pouvez définir ce paramètre sur true. - kubelet: - tlsVerify: false agents: - podSecurity: - securityContextConstraints: - create: true + #(...) + # agents.tolerations -- Allow the DaemonSet to schedule on tainted nodes (requires Kubernetes >= 1.6) tolerations: - effect: NoSchedule - key: node-role.kubernetes.io/master - operator: Exists - - effect: NoSchedule - key: node-role.kubernetes.io/infra - operator: Exists -clusterAgent: - podSecurity: - securityContextConstraints: - create: true -kube-state-metrics: - securityContext: - enabled: false + key: cloud.google.com/compute-class + operator: Equal + value: Scale-Out ``` - {{% /tab %}} -{{% tab "Operator" %}} +{{< /tabs >}} + + +## Red Hat OpenShift {#Openshift} + +OpenShift est livré avec une sécurité renforcée par défaut avec SELinux et SecurityContextConstraints (SCC). Par conséquent, il nécessite certaines configurations spécifiques : +- Accès SCC élevé pour l'Agent de nœud et l'Agent de cluster +- Il arrive que les certificats d'API Kubelet ne soient pas signés par l'autorité de certification du cluster. +- Vous devez définir des tolérances pour planifier l'Agent de nœud sur les nœuds `master` et `infra`. +- Le nom du cluster doit être défini et ne peut pas être récupéré automatiquement à partir du fournisseur de cloud. +- *(Facultatif)* Définir `hostNetwork: true` dans l'Agent de nœud pour permettre à l'Agent d'effectuer des requêtes vers les services de métadonnées du fournisseur de cloud (IMDS) + +Cette configuration de base prend en charge OpenShift 3.11 et OpenShift 4, mais elle fonctionne mieux avec OpenShift 4. -Si vous utilisez l'Operator Datadog dans OpenShift, il est conseillé de l'installer par l'intermédiaire d'OperatorHub ou du Marketplace Redhat. La configuration ci-dessous a été conçue pour un environnement où l'Agent est installé dans le même espace de nommage que l'Operator Datadog (en raison des paramètres SCC/ServiceAccount). +De plus, la collecte de logs et APM ont également des exigences légèrement différentes. + +L'utilisation de Socket de domaine Unix (UDS) pour APM et DogStatsD peut fonctionner dans OpenShift. Toutefois, Datadog ne recommande pas cela, car cela nécessite des autorisations privilégiées supplémentaires et un accès SCC pour **à la fois** votre pod de l'Agent Datadog et votre pod d'application. Sans celles-ci, votre pod d'application peut ne pas parvenir à se déployer. Datadog recommande de désactiver l'option UDS pour éviter cela, permettant au contrôleur d'admission d'injecter le [paramètre TCP/IP][7] ou le [paramètre de service][8] approprié pour la connectivité APM. + +{{< tabs >}} +{{% tab "Operator Datadog" %}} + +Lors de l'utilisation de l'opérateur Datadog dans OpenShift, Datadog recommande d'utiliser l'Operator Lifecycle Manager pour déployer l'opérateur Datadog depuis OperatorHub dans la console web de votre cluster OpenShift. Consultez les [étapes d'installation de l'opérateur][1]. La configuration ci-dessous fonctionne avec cette configuration, qui crée l'[accès basé sur ClusterRole et ClusterRoleBinding au SCC][2] pour le ServiceAccount spécifié `datadog-agent-scc`. Cette configuration `DatadogAgent` doit être déployée dans le même espace de nommage que l'opérateur Datadog. ```yaml kind: DatadogAgent apiVersion: datadoghq.com/v2alpha1 metadata: name: datadog + namespace: openshift-operators # set as the same namespace where the Datadog Operator was deployed spec: features: logCollection: - enabled: false - liveProcessCollection: - enabled: false - liveContainerCollection: enabled: true + containerCollectAll: true apm: - enabled: false - cspm: - enabled: false - cws: - enabled: false - npm: - enabled: false - admissionController: - enabled: false - externalMetricsServer: - enabled: false - useDatadogMetrics: false - port: 8443 + enabled: true + hostPortConfig: + enabled: true + unixDomainSocketConfig: + enabled: false + dogstatsd: + unixDomainSocketConfig: + enabled: false global: credentials: - apiKey: - appKey: - clusterName: + apiKey: + appKey: + clusterName: kubelet: tlsVerify: false - criSocketPath: /var/run/crio/crio.sock override: clusterAgent: - image: - name: gcr.io/datadoghq/cluster-agent:latest + serviceAccountName: datadog-agent-scc nodeAgent: serviceAccountName: datadog-agent-scc - image: - name: gcr.io/datadoghq/agent:latest + hostNetwork: true + securityContext: + runAsUser: 0 + seLinuxOptions: + level: s0 + role: system_r + type: spc_t + user: system_u tolerations: - key: node-role.kubernetes.io/master operator: Exists @@ -343,39 +458,57 @@ spec: effect: NoSchedule ``` -{{% /tab %}} -{{< /tabs >}} - -## Rancher {#Rancher} - -Les installations Rancher sont semblables aux installations Kubernetes de base. Leur configuration requiert uniquement quelques ajustements : -- Vous devez définir des tolérances pour planifier l'Agent de nœud sur les nœuds `controlplane` et `etcd`. -- Le nom du cluster doit être défini et ne peut pas être récupéré automatiquement à partir du fournisseur de cloud. +**Remarque** : le remplacement `nodeAgent.securityContext.seLinuxOptions` est nécessaire pour la collecte de logs lors du déploiement avec l'opérateur. Si la collecte de logs n'est pas activée, vous pouvez omettre ce remplacement. -{{< tabs >}} +[1]: https://github.com/DataDog/datadog-operator/blob/main/docs/install-openshift.md +[2]: https://docs.openshift.com/container-platform/4.10/authentication/managing-security-context-constraints.html#role-based-access-to-ssc_configuring-internal-oauth +{{% /tab %}} {{% tab "Helm" %}} -`values.yaml` personnalisé : +La configuration ci-dessous crée des SCC personnalisés pour les ServiceAccounts de l'Agent et de l'Agent de cluster. + +`datadog-values.yaml` personnalisé : ```yaml datadog: - apiKey: - appKey: - clusterName: + apiKey: + appKey: + clusterName: kubelet: tlsVerify: false + apm: + portEnabled: true + socketEnabled: false agents: + podSecurity: + securityContextConstraints: + create: true + useHostNetwork: true tolerations: - - effect: NoSchedule - key: node-role.kubernetes.io/controlplane - operator: Exists - - effect: NoExecute - key: node-role.kubernetes.io/etcd - operator: Exists + - effect: NoSchedule + key: node-role.kubernetes.io/master + operator: Exists + - effect: NoSchedule + key: node-role.kubernetes.io/infra + operator: Exists +clusterAgent: + podSecurity: + securityContextConstraints: + create: true ``` {{% /tab %}} -{{% tab "Operator" %}} + +{{< /tabs >}} + +## Rancher {#Rancher} + +Les installations Rancher sont similaires aux installations Kubernetes standard, nécessitant seulement une configuration mineure : +- Des tolérances sont requises pour planifier l'Agent de nœud sur les nœuds `controlplane` et `etcd`. +- Le nom de cluster doit être défini car il ne peut pas être récupéré automatiquement depuis le fournisseur de cloud. + +{{< tabs >}} +{{% tab "Operator Datadog" %}} Ressource Kubernetes DatadogAgent : @@ -407,9 +540,9 @@ spec: useDatadogMetrics: false global: credentials: - apiKey: - appKey: - clusterName: + apiKey: + appKey: + clusterName: kubelet: tlsVerify: false override: @@ -429,61 +562,34 @@ spec: ``` {{% /tab %}} -{{< /tabs >}} - -## Oracle Container Engine for Kubernetes (OKE) {#OKE} - -Aucune configuration particulière n'est requise. - -Pour activer la surveillance des conteneurs, ajoutez ce qui suit (check `containerd`) : - -{{< tabs >}} {{% tab "Helm" %}} -`values.yaml` personnalisé : +`datadog-values.yaml` personnalisé : ```yaml datadog: - apiKey: - appKey: - criSocketPath: /run/dockershim.sock - env: - - name: DD_AUTOCONFIG_INCLUDE_FEATURES - value: "containerd" + apiKey: + appKey: + clusterName: + kubelet: + tlsVerify: false +agents: + tolerations: + - effect: NoSchedule + key: node-role.kubernetes.io/controlplane + operator: Exists + - effect: NoExecute + key: node-role.kubernetes.io/etcd + operator: Exists ``` {{% /tab %}} -{{% tab "Operator" %}} -Ressource Kubernetes DatadogAgent : - -```yaml -kind: DatadogAgent -apiVersion: datadoghq.com/v2alpha1 -metadata: - name: datadog -spec: - features: - admissionController: - enabled: false - externalMetricsServer: - enabled: false - useDatadogMetrics: false - global: - credentials: - apiKey: - appKey: - criSocketPath: /run/dockershim.sock - override: - clusterAgent: - image: - name: gcr.io/datadoghq/cluster-agent:latest -``` - -{{% /tab %}} {{< /tabs >}} -Le [référentiel helm-charts][1] contient d'autres exemples de fichier `values.yaml`. Le [référentiel datadog-operator][2] contient d'autres exemples de `DatadogAgent`. +## Oracle Container Engine for Kubernetes (OKE) {#OKE} + +Aucune configuration particulière n'est requise. ## vSphere Tanzu Kubernetes Grid (TKG) {#TKG} @@ -491,31 +597,7 @@ TKG nécessite quelques légères modifications de la configuration, visibles ci {{< tabs >}} -{{% tab "Helm" %}} - -`values.yaml` personnalisé : - -```yaml -datadog: - apiKey: - appKey: - kubelet: - # Définir tlsVerify sur false étant donné que les certificats Kubelet sont autosignés - tlsVerify: false - # Désactiver l'installation du chart de la dépendance `kube-state-metrics`. - kubeStateMetricsEnabled: false - # Activer le nouveau check `kubernetes_state_core`. - kubeStateMetricsCore: - enabled: true -# Ajouter une tolérance pour que l'Agent puisse être planifié sur les nœuds du plan de contrôle. -agents: - tolerations: - - key: node-role.kubernetes.io/master - effect: NoSchedule -``` - -{{% /tab %}} -{{% tab "Operator" %}} +{{% tab "Operator Datadog" %}} Ressource Kubernetes DatadogAgent : @@ -529,9 +611,9 @@ spec: eventCollection: collectKubernetesEvents: true kubeStateMetricsCore: - # Activer le nouveau check `kubernetes_state_core`. enabled: true global: + clusterName: credentials: apiSecret: secretName: datadog-secret @@ -540,21 +622,56 @@ spec: secretName: datadog-secret keyName: app-key kubelet: - # Définir tlsVerify sur false étant donné que les certificats Kubelet sont autosignés tlsVerify: false override: nodeAgent: - # Ajouter une tolérance pour que l'Agent puisse être planifié sur les nœuds du plan de contrôle. tolerations: - key: node-role.kubernetes.io/master effect: NoSchedule ``` {{% /tab %}} +{{% tab "Helm" %}} + +`datadog-values.yaml` personnalisé : + +```yaml +datadog: + clusterName: + apiKey: + appKey: + kubelet: + # Set tlsVerify to false since the Kubelet certificates are self-signed + tlsVerify: false + # Disable the `kube-state-metrics` dependency chart installation. + kubeStateMetricsEnabled: false + # Enable the new `kubernetes_state_core` check. + kubeStateMetricsCore: + enabled: true +# Add a toleration so that the agent can be scheduled on the control plane nodes. +agents: + tolerations: + - key: node-role.kubernetes.io/master + effect: NoSchedule +``` + +{{% /tab %}} + {{< /tabs >}} {{< partial name="whats-next/whats-next.html" >}} -[1]: https://github.com/DataDog/helm-charts/tree/main/examples/datadog -[2]: https://github.com/DataDog/datadog-operator/tree/main/examples/datadogagent/v2alpha1 \ No newline at end of file +[1]: /fr/containers/cluster_agent/admission_controller +[2]: https://github.com/Azure/AKS/releases/tag/2022-10-30 +[3]: https://github.com/DataDog/helm-charts/tree/main/examples/datadog +[4]: https://github.com/DataDog/datadog-operator/tree/main/examples/datadogagent/v2alpha1 +[5]: /fr/getting_started/containers/datadog_operator +[6]: /fr/agent/guide/operator-eks-addon +[7]: /fr/containers/kubernetes/apm/?tab=tcp +[8]: /fr/tracing/guide/setting_up_apm_with_kubernetes_service +[9]: https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/ +[10]: https://cloud.google.com/kubernetes-engine/docs/how-to/autopilot-spot-pods +[11]: https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-compute-classes +[12]: https://cloud.google.com/kubernetes-engine/docs/how-to/disable-kubelet-readonly-port +[13]: https://learn.microsoft.com/en-us/azure/aks/certificate-rotation#kubelet-serving-certificate-rotation \ No newline at end of file diff --git a/content/fr/containers/troubleshooting/_index.md b/content/fr/containers/troubleshooting/_index.md new file mode 100644 index 00000000000..2794249c8f1 --- /dev/null +++ b/content/fr/containers/troubleshooting/_index.md @@ -0,0 +1,181 @@ +--- +description: Dépannage des problèmes liés aux conteneurs +further_reading: +- link: /containers/troubleshooting/duplicate_hosts + tag: Documentation + text: Dupliquer des hosts avec Kubernetes sur AWS (EC2 ou EKS) +title: Dépannage des conteneurs +--- + +Cette page fournit des informations de dépannage pour la surveillance des conteneurs. + + +Il existe trois méthodes pour déployer l'Agent : +1. En tant que [**conteneur dans un runtime**][1] + +2. Dans un **environnement cloud**, tel qu'[Amazon ECS][2], [Fargate dans un environnement Amazon ECS][3] ou [Amazon EKS][4] + +3. Dans un [environnement Kubernetes][16] + +Ces différentes méthodes présentent des défis de déploiement uniques. Utilisez cette page comme point de départ pour résoudre les problèmes. Si vous continuez à rencontrer des difficultés, contactez [l'assistance Datadog][6] pour obtenir de l'aide supplémentaire. + +Pour plus de détails sur les mises à jour ou modifications des versions de l'Agent, consultez les [notes de version][7] de Datadog. + +## Problèmes généraux + +### Les variables d'environnement ne sont pas définies et les tags ne sont pas injectés + +Une méthode utile pour injecter des [variables d'environnement][8] ou pour configurer une bibliothèque DogStatsD consiste à implémenter la fonctionnalité [contrôleur d'admission][9] sur l'Agent de cluster. **Remarque** : l'Agent de cluster doit être déployé et en cours d'exécution _avant_ le déploiement de l'application. + +### Les métriques n'apparaissent pas sur la plateforme Web Datadog + +Vérifiez que les éléments suivants sont vrais : + +- L'endpoint de métriques est exposé et ouvert pour que l'Agent puisse l'atteindre. + +- Il n'y a pas de proxys ou de pare-feu susceptibles d'empêcher l'Agent d'accéder à l'endpoint. + +- L'Agent a [Autodiscovery][10] activé. + + +### Les logs ne sont pas collectés + +Il existe deux [variables d'environnement][8] qui peuvent affecter la collecte des logs et depuis quels conteneurs : + +- Définissez `DD_LOGS_ENABLED` sur `true` pour collecter les logs. +- De plus, définissez `DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL` sur `true` pour collecter tous les logs de tous les conteneurs. + +Pour exclure les logs (et autres fonctionnalités) de la collecte, consultez le [guide de gestion de la découverte de conteneurs][11]. + +### Impossible de se connecter au Kubelet + +L'erreur la plus courante qui empêche la connexion à l'API Kubelet est la vérification du certificat TLS Kubelet. + +La vérification TLS est activée par défaut et peut empêcher l'Agent de se connecter à l'API Kubelet via HTTPS. Vous pouvez désactiver la vérification TLS en utilisant des paramètres dédiés ou en définissant la variable `DD_KUBELET_TLS_VERIFY` pour tous les conteneurs dans le manifeste de l'Agent : + + - Définissez `TLS_VERIFY` sur `false`. + +### Les métriques HPA n'apparaissent pas ou ne correspondent pas à la valeur attendue + +Tout d'abord, assurez-vous que l'Agent de cluster est déployé et capable d'envoyer des données à l'Agent de nœud. + +Ensuite, examinez la requête utilisée pour mettre à l'échelle les métriques externes dans le récapitulatif des métriques. Seules les requêtes valides effectuent une mise à l'échelle automatique. S'il y a plusieurs requêtes, **toutes** les requêtes sont ignorées si **l'une** des requêtes est invalide. + +Lorsque vous contactez l'assistance pour obtenir de l'aide supplémentaire concernant les métriques HPA, fournissez les éléments suivants à [l'assistance Datadog][6] : + - Une sortie `describe` du manifeste HPA : + ``` + $ kubectl describe hpa > hpa.log + ``` + - Une sortie `describe` de la Custom Resource Definition DatadogMetric : + ``` + $ kubectl describe DatadogMetric > DatadogMetric.log + ``` + + +## Runtime + + Pour les logs, assurez-vous que la commande de déploiement de l'Agent a `DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL` et `DD_LOGS_ENABLED` activés. + +## Cloud + +Assurez-vous que votre stratégie IAM est mise à jour. + +### Les logs ne sont pas collectés dans Fargate + + - [ECS][12] : assurez-vous que le routeur de logs est attaché au conteneur depuis lequel vous souhaitez collecter les logs. + + - [EKS][13] : il existe deux méthodes courantes pour que l'Agent collecte les logs dans un environnement EKS Fargate : le transfert de logs avec les logs CloudWatch et le transfert de logs via [Amazon Data Firehose][14]. L'utilisation d'Amazon Data Firehose pour collecter les logs nécessite l'implémentation réussie du flux de distribution Amazon Data Firehose, ainsi que certains outils de ligne de commande. + + +## Kubernetes + +### Le conteneur ne se déploie pas ou ne collecte pas de métriques + +Tout d'abord, assurez-vous que votre clé API est valide. + +Ensuite, dans votre pod d'Agent de nœud, exécutez la commande `agent status` et examinez les résultats. + +### Métriques `kubeapi_server`, `kube_controller_manager` ou `etcd` non reçues + +Sur les services managés tels qu'Azure Kubernetes Service (AKS) et Google Kubernetes Engine (GKE), l'utilisateur ne peut pas accéder aux composants du control plane. Par conséquent, il n'est pas possible d'exécuter les checks `kube_apiserver`, `kube_controller_manager`, `kube_scheduler` ou `etcd` dans ces environnements. + +## ECS Fargate + +### L'Agent Windows expire lors du démarrage du service + +```text +[ENTRYPOINT][ERROR] Could not start the service: The service did not respond to the start or control request in a timely fashion. +. Error: [1053 (0x41d)] +``` + +Pour éviter cette erreur, assurez-vous d'avoir défini une réservation d'**unités CPU** d'au moins `512` pour l'Agent Datadog. + +# Données de dépannage demandées par l'assistance Datadog + +Après avoir ouvert un ticket d'assistance, il peut vous être demandé les types d'informations suivants : + +### Agent Flare + +Vous pouvez utiliser la commande [`flare`][15] pour envoyer des informations de dépannage à l'assistance Datadog. + +**Flare de l'Agent de nœud** + +``` +$ kubectl exec -it agent flare +``` + +**Flare de l'Agent de cluster** + +``` +$ kubectl exec -it agent flare +``` + + +### Sortie de describe Pod + +Cela fournit à l'équipe un aperçu de la manière dont l'Agent de nœud ou l'Agent de cluster a été déployé, quels étaient les événements les plus récents pour le pod et si certaines qualités (telles que les tags custom) ont été injectées et appliquées aux métriques de host. La section `> .yaml` de la commande crée une sortie de fichier qui peut être envoyée à l'assistance Datadog en tant que pièce jointe : + +``` +$ kubectl describe pod > .yaml +``` + +### Manifeste/déploiement + +Il s'agit du fichier utilisé pour déployer l'Agent dans votre environnement. Il informe Datadog des tags configurés, si les logs ont été activés et si certains conteneurs sont définis pour être ignorés. + +Dans le cas du déploiement de l'Agent dans un environnement runtime, envoyez à l'assistance la ligne de commande utilisée pour déployer l'Agent. + +Les trois méthodes de déploiement les plus courantes sont : chart Helm, DaemonSet et opérateur. + +### Sortie cURL + +Si vous rencontrez des métriques manquantes ou inexactes, l'assistance Datadog peut demander le résultat d'une sortie cURL de l'Agent de nœud tentant d'atteindre l'endpoint de métriques. Cela se fait en exécutant la commande depuis l'intérieur du conteneur de l'Agent et peut informer l'assistance si l'Agent a accès aux métriques. **Remarque** : cela n'est pas possible dans Fargate ou les services managés : + +``` +$ kubectl exec -it curl -k -v """" +``` + +``` +$ docker exec -it curl -k -v "" +``` + +## Pour aller plus loin + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://docs.datadoghq.com/fr/containers/docker/?tab=standard +[2]: https://docs.datadoghq.com/fr/containers/amazon_ecs/?tab=awscli +[3]: https://docs.datadoghq.com/fr/integrations/ecs_fargate/?tab=webui# +[4]: https://docs.datadoghq.com/fr/integrations/eks_fargate +[5]: https://docs.datadoghq.com/fr/containers/kubernetes/ +[6]: https://docs.datadoghq.com/fr/help/ +[7]: https://app.datadoghq.com/release-notes +[8]: https://docs.datadoghq.com/fr/agent/guide/environment-variables/#overview +[9]: https://docs.datadoghq.com/fr/containers/cluster_agent/admission_controller/?tab=operator +[10]: https://docs.datadoghq.com/fr/getting_started/containers/autodiscovery/?tab=adannotationsv2agent736 +[11]: https://docs.datadoghq.com/fr/agent/guide/autodiscovery-management/?tab=containerizedagent +[12]: https://docs.datadoghq.com/fr/integrations/ecs_fargate/?tab=webui#log-collection +[13]: https://docs.datadoghq.com/fr/integrations/eks_fargate/#log-collection +[14]: https://docs.datadoghq.com/fr/logs/guide/aws-eks-fargate-logs-with-kinesis-data-firehose/#overview +[15]: https://docs.datadoghq.com/fr/agent/troubleshooting/send_a_flare +[16]: https://docs.datadoghq.com/fr/containers/kubernetes/installation/?tab=operator \ No newline at end of file diff --git a/content/fr/containers/troubleshooting/admission-controller.md b/content/fr/containers/troubleshooting/admission-controller.md new file mode 100644 index 00000000000..c457d34988a --- /dev/null +++ b/content/fr/containers/troubleshooting/admission-controller.md @@ -0,0 +1,424 @@ +--- +description: Dépanner les problèmes courants avec le contrôleur d'admission de l'Agent + de cluster de Datadog et l'injection de bibliothèque +further_reading: +- link: https://www.datadoghq.com/blog/auto-instrument-kubernetes-tracing-with-datadog/ + tag: Blog + text: Instrumenter automatiquement le tracing Kubernetes +- link: /containers/cluster_agent/admission_controller/ + tag: Documentation + text: Contrôleur d'admission de lʼAgent de cluster +- link: /tracing/trace_collection/library_injection_local/?tab=kubernetes + tag: Documentation + text: Injection de bibliothèque Kubernetes +title: Dépannage du contrôleur d'admission +--- + +## Présentation + +Cette page fournit des informations de dépannage pour le [contrôleur d'admission][1] de l'Agent de cluster de Datadog. + +## Problèmes courants + +### Mettre à jour les pods préexistants +Le contrôleur d'admission répond à la création de nouveaux pods dans votre cluster Kubernetes : lors de la création d'un pod, l'Agent de cluster reçoit une requête de Kubernetes et répond avec les détails des modifications (le cas échéant) à apporter au pod. + +Par conséquent, **le contrôleur d'admission ne mute pas les pods existants dans votre cluster**. Si vous avez récemment activé le contrôleur d'admission ou effectué d'autres modifications environnementales, supprimez votre pod existant et laissez Kubernetes le recréer. Cela garantit que le contrôleur d'admission met à jour votre pod. + +### Étiquettes et annotations +L'Agent de cluster répond aux étiquettes et annotations sur le pod créé—**pas** la workload (Deployment, DaemonSet, CronJob, etc.) qui a créé ce pod. Assurez-vous que votre modèle de pod référence cela en conséquence. + +Par exemple, le modèle suivant définit l'[étiquette pour la configuration APM][2] et l'[annotation pour l'injection de bibliothèque][3] : + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: example-deployment +spec: + #(...) + template: + metadata: + labels: + admission.datadoghq.com/enabled: "true" + annotations: + admission.datadoghq.com/-lib.version: + spec: + containers: + #(...) +``` + +### Les pods d'application ne sont pas créés + +Le mode d'injection du contrôleur d'admission (`socket`, `hostip`, `service`) est défini par la configuration de votre Agent de cluster. Par exemple, si vous avez le mode `socket` activé dans votre Agent, le contrôleur d'admission utilise également le mode `socket`. + +Si vous utilisez GKE Autopilot ou OpenShift, vous devez utiliser un mode d'injection spécifique. + +#### GKE Autopilot + +GKE Autopilot restreint l'utilisation de tous les `volumes` avec un `hostPath`. Par conséquent, si le contrôleur d'admission utilise le mode `socket`, les pods sont bloqués de la planification par le GKE Warden. + +L'activation du mode GKE Autopilot dans le chart Helm désactive le mode `socket` pour éviter que cela ne se produise. Pour activer APM, activez le port et utilisez plutôt la méthode `hostip` ou `service`. Le contrôleur d'admission utilisera par défaut `hostip` pour correspondre. + +{{< tabs >}} +{{% tab "Helm" %}} +```yaml +datadog: + apm: + portEnabled: true + #(...) + +providers: + gke: + autopilot: true +``` +{{% /tab %}} +{{< /tabs >}} + +Consultez les [distributions Kubernetes][17] pour plus de détails de configuration concernant Autopilot. + +#### OpenShift + +OpenShift dispose de `SecurityContextConstraints` (SCC) qui sont requis pour déployer des pods avec des autorisations supplémentaires, tels qu'un `volume` avec un `hostPath`. Les composants Datadog sont déployés avec des SCC pour permettre une activité spécifique aux pods Datadog, mais Datadog ne crée pas de SCC pour d'autres pods. Le contrôleur d'admission peut ajouter la configuration basée sur socket à vos pods d'application, ce qui entraîne leur échec de déploiement. + +Si vous utilisez OpenShift, utilisez le mode `hostip`. La configuration suivante active le mode `hostip` en désactivant les options socket : + +{{< tabs >}} +{{% tab "Operator Datadog" %}} +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + features: + apm: + enabled: true + hostPortConfig: + enabled: true + unixDomainSocketConfig: + enabled: false + dogstatsd: + hostPortConfig: + enabled: true + unixDomainSocketConfig: + enabled: false +``` +En alternative, vous pouvez définir `features.admissionController.agentCommunicationMode` sur `hostip` ou `service` directement. + +{{% /tab %}} +{{% tab "Helm" %}} +```yaml +datadog: + apm: + portEnabled: true + socketEnabled: false +``` +En alternative, vous pouvez définir `clusterAgent.admissionController.configMode` sur `hostip` ou `service` directement. +{{% /tab %}} +{{< /tabs >}} + +Consultez les [distributions Kubernetes][18] pour plus de détails de configuration concernant OpenShift. + +## Afficher le statut du contrôleur d'admission + +La sortie de statut de l'Agent de cluster fournit des informations pour vérifier qu'il a créé le `datadog-webhook` pour la `MutatingWebhookConfiguration` et dispose d'un certificat valide. + +Exécutez la commande suivante : + +```bash +% kubectl exec -it -- agent status +``` + +Votre sortie ressemble à ce qui suit : + +``` +... +Admission Controller +==================== + + Webhooks info + ------------- + MutatingWebhookConfigurations name: datadog-webhook + Created at: 2023-09-25T22:32:07Z + --------- + Name: datadog.webhook.auto.instrumentation + CA bundle digest: f24b6c0c40feaad2 + Object selector: &LabelSelector{MatchLabels:map[string]string{admission.datadoghq.com/enabled: true,},MatchExpressions:[]LabelSelectorRequirement{},} + Rule 1: Operations: [CREATE] - APIGroups: [] - APIVersions: [v1] - Resources: [pods] + Service: default/datadog-admission-controller - Port: 443 - Path: /injectlib + --------- + Name: datadog.webhook.config + CA bundle digest: f24b6c0c40feaad2 + Object selector: &LabelSelector{MatchLabels:map[string]string{admission.datadoghq.com/enabled: true,},MatchExpressions:[]LabelSelectorRequirement{},} + Rule 1: Operations: [CREATE] - APIGroups: [] - APIVersions: [v1] - Resources: [pods] + Service: default/datadog-admission-controller - Port: 443 - Path: /injectconfig + --------- + Name: datadog.webhook.tags + CA bundle digest: f24b6c0c40feaad2 + Object selector: &LabelSelector{MatchLabels:map[string]string{admission.datadoghq.com/enabled: true,},MatchExpressions:[]LabelSelectorRequirement{},} + Rule 1: Operations: [CREATE] - APIGroups: [] - APIVersions: [v1] - Resources: [pods] + Service: default/datadog-admission-controller - Port: 443 - Path: /injecttags + + Secret info + ----------- + Secret name: webhook-certificate + Secret namespace: default + Created at: 2023-09-25T22:32:07Z + CA bundle digest: f24b6c0c40feaad2 + Duration before certificate expiration: 8643h34m2.557676864s +... +``` + +Cette sortie est relative à l'Agent de cluster déployé dans l'espace de nommage `default`. Le `Service` et le `Secret` doivent correspondre à l'espace de nommage utilisé. + +## Afficher les logs du contrôleur d'admission + +Les logs de debug aident à valider que vous avez configuré correctement le contrôleur d'admission. [Activez les logs de debug][3] avec la configuration suivante : + +{{< tabs >}} +{{% tab "Operator Datadog" %}} + +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + global: + credentials: + apiKey: + site: + logLevel: debug +``` + +{{% /tab %}} +{{% tab "Helm" %}} + +```yaml +datadog: + logLevel: debug +``` + +{{% /tab %}} +{{< /tabs >}} + +### Valider `datadog-webhook` + +**Exemples de logs** : + +``` + | CLUSTER | INFO | (pkg/clusteragent/admission/controllers/secret/controller.go:73 in Run) | Starting secrets controller for default/webhook-certificate + | CLUSTER | DEBUG | (pkg/clusteragent/admission/controllers/webhook/controller_base.go:148 in enqueue) | Adding object with key default/webhook-certificate to the queue + | CLUSTER | DEBUG | (pkg/clusteragent/admission/controllers/secret/controller.go:140 in enqueue) | Adding object with key default/webhook-certificate to the queue + | CLUSTER | DEBUG | (pkg/clusteragent/admission/controllers/webhook/controller_base.go:148 in enqueue) | Adding object with key datadog-webhook to the queue + | CLUSTER | DEBUG | (pkg/util/kubernetes/apiserver/util.go:47 in func1) | Sync done for informer admissionregistration.k8s.io/v1/mutatingwebhookconfigurations in 101.116625ms, last resource version: 152728 + | CLUSTER | DEBUG | (pkg/clusteragent/admission/controllers/webhook/controller_v1.go:140 in reconcile) | The Webhook datadog-webhook was found, updating it + | CLUSTER | DEBUG | (pkg/clusteragent/admission/controllers/secret/controller.go:211 in reconcile) | The certificate is up-to-date, doing nothing. Duration before expiration: 8558h17m27.909792831s + | CLUSTER | DEBUG | (pkg/clusteragent/admission/controllers/secret/controller.go:174 in processNextWorkItem) | Secret default/webhook-certificate reconciled successfully + | CLUSTER | DEBUG | (pkg/clusteragent/admission/controllers/webhook/controller_base.go:176 in processNextWorkItem) | Webhook datadog-webhook reconciled successfully +``` + +Si vous ne voyez pas que le webhook `datadog-webhook` a été réconcilié avec succès, assurez-vous d'avoir correctement activé le contrôleur d'admission conformément aux [instructions de configuration][1]. + +### Valider l'injection + +**Exemples de logs** : + +``` + | CLUSTER | DEBUG | (pkg/clusteragent/admission/controllers/secret/controller.go:140 in enqueue) | Adding object with key default/webhook-certificate to the queue + | CLUSTER | DEBUG | (pkg/clusteragent/admission/controllers/secret/controller.go:211 in reconcile) | The certificate is up-to-date, doing nothing. Duration before expiration: 8558h12m28.007769373s + | CLUSTER | DEBUG | (pkg/clusteragent/admission/controllers/secret/controller.go:174 in processNextWorkItem) | Secret default/webhook-certificate reconciled successfully + | CLUSTER | DEBUG | (pkg/clusteragent/admission/mutate/common.go:74 in injectEnv) | Injecting env var 'DD_TRACE_AGENT_URL' into pod with generate name example-pod-123456789- + | CLUSTER | DEBUG | (pkg/clusteragent/admission/mutate/common.go:74 in injectEnv) | Injecting env var 'DD_DOGSTATSD_URL' into pod with generate name example-pod-123456789- + | CLUSTER | DEBUG | (pkg/clusteragent/admission/mutate/common.go:74 in injectEnv) | Injecting env var 'DD_ENTITY_ID' into pod with generate name example-pod-123456789- + | CLUSTER | DEBUG | (pkg/clusteragent/admission/mutate/common.go:74 in injectEnv) | Injecting env var 'DD_SERVICE' into pod with generate name example-pod-123456789- + | CLUSTER | DEBUG | (pkg/clusteragent/admission/mutate/auto_instrumentation.go:336 in injectLibInitContainer) | Injecting init container named "datadog-lib-python-init" with image "gcr.io/datadoghq/dd-lib-python-init:v1.18.0" into pod with generate name example-pod-123456789- +``` + +Si vous voyez des erreurs avec l'injection pour un pod donné, contactez l'assistance Datadog avec votre configuration Datadog et votre configuration de pod. + +Si vous ne voyez pas les tentatives d'injection pour *aucun* pod, vérifiez vos paramètres `mutateUnlabelled` et assurez-vous que vos étiquettes de pod correspondent aux valeurs attendues. Si celles-ci correspondent, votre problème est probablement lié au réseau entre le control plane, le webhook et le service. Consultez [Réseau](#networking) pour plus d'informations. + +## Réseau + +### Politiques réseau + +Les [politiques réseau][5] Kubernetes vous aident à contrôler différents flux de trafic entrant (inbound) et sortant (outbound) vers vos pods. + +Si vous utilisez des politiques réseau, Datadog recommande de créer des politiques correspondantes pour l'Agent de cluster afin de garantir la connectivité au pod sur ce port. Vous pouvez le faire avec la configuration suivante : + +{{< tabs >}} +{{% tab "Operator Datadog" %}} +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + global: + #(...) + networkPolicy: + create: true + flavor: kubernetes +``` +{{% /tab %}} +{{% tab "Helm" %}} +```yaml +datadog: + #(...) + networkPolicy: + create: true + flavor: kubernetes +``` +{{% /tab %}} +{{< /tabs >}} + +Définissez `flavor` sur `kubernetes` pour créer une ressource `NetworkPolicy`. + +En alternative, pour les environnements basés sur Cilium, définissez `flavor` sur `cilium` pour créer une ressource `CiliumNetworkPolicy`. + +### Dépannage réseau pour les distributions Kubernetes + +Lorsqu'un pod est créé, le cluster Kubernetes envoie une requête depuis le control plane, vers `datadog-webhook`, via le service, et enfin vers le pod de l'Agent de cluster. Cette requête nécessite une connectivité entrante depuis le control plane vers le nœud sur lequel se trouve l'Agent de cluster, sur son port de contrôleur d'admission (`8000`). Une fois cette requête résolue, l'Agent de cluster mute votre pod pour configurer la connexion réseau pour le traceur Datadog. +Le service de contrôleur d'admission reçoit le trafic sur le port 443 et le transfère au pod de l'Agent de cluster sur le port 8000. + +Selon votre distribution Kubernetes, cela peut avoir des exigences supplémentaires pour vos règles de sécurité et paramètres de contrôleur d'admission. + +#### Amazon Elastic Kubernetes Service (EKS) + +Dans un cluster EKS, vous pouvez déployer le pod de l'Agent de cluster sur n'importe lequel de vos nœuds basés sur Linux par défaut. Ces nœuds et leurs instances EC2 nécessitent un [groupe de sécurité][6] avec la [règle entrante][7] suivante : +- **Protocole** : TCP +- **Plage de ports** : `8000`, ou une plage qui couvre `8000` +- **Source** : l'ID du groupe de sécurité du cluster _ou_ l'un des groupes de sécurité supplémentaires de votre cluster. Vous pouvez trouver ces ID dans la console EKS, sous l'onglet _Networking_ pour votre cluster EKS. + +Cette règle de groupe de sécurité permet au control plane d'accéder au nœud et à l'Agent de cluster en aval sur le port `8000`. + +Si vous disposez de plusieurs [groupes de nœuds managés][8], chacun avec des groupes de sécurité distincts, ajoutez cette règle entrante à chaque groupe de sécurité. + +##### Journalisation du control plane + +Pour valider votre configuration réseau, activez la [journalisation du control plane EKS][9] pour l'API Server. Vous pouvez afficher ces logs dans la [console CloudWatch][10]. + +Ensuite, supprimez l'un de vos pods pour redéclencher une requête via le contrôleur d'admission. Lorsque la requête échoue, vous pouvez afficher des logs ressemblant à ce qui suit : + +``` +W0908 10 dispatcher.go:202] Failed calling webhook, failing open datadog.webhook.auto.instrumentation: failed calling webhook "datadog.webhook.auto.instrumentation": failed to call webhook: Post "https://datadog-cluster-agent-admission-controller.default.svc:443/injectlib?timeout=10s": context deadline exceeded +E0908 10 dispatcher.go:206] failed calling webhook "datadog.webhook.auto.instrumentation": failed to call webhook: Post "https://datadog-cluster-agent-admission-controller.default.svc:443/injectlib?timeout=10s": context deadline exceeded +``` + +Ces échecs sont relatifs à un Agent de cluster déployé dans l'espace de nommage `default` ; le nom DNS s'ajuste en fonction de l'espace de nommage utilisé. + +Vous pouvez également voir des échecs pour les autres webhooks du contrôleur d'admission, tels que `datadog.webhook.tags` et `datadodg.webhook.config`. + +**Remarque** : EKS génère souvent deux flux de logs dans le groupe de logs CloudWatch pour le cluster. Assurez-vous de vérifier les deux pour ces types de logs. + +#### Azure Kubernetes Service (AKS) + +Pour utiliser des [webhooks de contrôleur d'admission sur AKS][11], utilisez la configuration suivante : + +{{< tabs >}} +{{% tab "Operator Datadog" %}} + +```yaml +kind: DatadogAgent +apiVersion: datadoghq.com/v2alpha1 +metadata: + name: datadog +spec: + #(...) + override: + clusterAgent: + containers: + cluster-agent: + env: + - name: DD_ADMISSION_CONTROLLER_ADD_AKS_SELECTORS + value: "true" +``` +{{% /tab %}} +{{% tab "Helm" %}} + +```yaml +datadog: + #(...) + +providers: + aks: + enabled: true +``` + +L'option `providers.aks.enabled` définit la variable d'environnement `DD_ADMISSION_CONTROLLER_ADD_AKS_SELECTORS="true"`. +{{% /tab %}} +{{< /tabs >}} + +#### Google Kubernetes Engine (GKE) + +Si vous utilisez un [cluster privé GKE][12], vous devez ajuster vos règles de pare-feu pour autoriser l'accès entrant depuis le control plane vers le port `8000`. + +[Ajoutez une règle de pare-feu][13] pour autoriser l'entrée via TCP sur le port `8000`. + +Vous pouvez également modifier une règle existante. Par défaut, le réseau de votre cluster dispose d'une règle de pare-feu nommée `gke--master`. Assurez-vous que les _filtres source_ de cette règle incluent [le bloc CIDR du control plane de votre cluster][14]. Modifiez cette règle pour autoriser l'accès via le protocole `tcp` sur le port `8000`. + +Pour plus d'informations, consultez [Ajout de règles de pare-feu pour des cas d'utilisation spécifiques][15] dans la documentation GKE. + +#### Rancher + +Si vous utilisez Rancher avec un cluster EKS ou un cluster privé GKE, une configuration supplémentaire est requise. Pour plus d'informations, consultez [Rancher Webhook - Common Issues][16] dans la documentation Rancher. + +**Remarque** : étant donné que le webhook du contrôleur d'admission de Datadog fonctionne de manière similaire au webhook Rancher, Datadog a besoin d'un accès au port `8000` au lieu du `9443` de Rancher. + +##### Rancher et EKS +Pour utiliser Rancher dans un cluster EKS, déployez le pod de l'Agent de cluster avec la configuration suivante : + +{{< tabs >}} +{{% tab "Operator Datadog" %}} +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + #(...) + override: + clusterAgent: + hostNetwork: true +``` +{{% /tab %}} +{{% tab "Helm" %}} +```yaml +datadog: + #(...) + +clusterAgent: + useHostNetwork: true +``` +{{% /tab %}} +{{< /tabs >}} + +Vous devez également ajouter une règle entrante de groupe de sécurité, comme décrit dans la section [Amazon EKS](#amazon-elastic-kubernetes-service-eks) sur cette page. + +##### Rancher et GKE +Pour utiliser Rancher dans un cluster privé GKE, modifiez vos règles de pare-feu pour autoriser l'accès entrant via TCP sur le port `8000`. Consultez la section [GKE](#google-kubernetes-engine-gke) sur cette page. + +## Pour aller plus loin + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /fr/containers/cluster_agent/admission_controller +[2]: /fr/containers/cluster_agent/admission_controller/#apm-and-dogstatsd +[3]: /fr/tracing/trace_collection/library_injection_local/?tab=kubernetes +[4]: /fr/agent/troubleshooting/debug_mode/ +[5]: https://kubernetes.io/docs/concepts/services-networking/network-policies/#networkpolicy-resource +[6]: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html +[7]: https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html#security-group-rule-components +[8]: https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html +[9]: https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html +[10]: https://console.aws.amazon.com/cloudwatch/home#logs:prefix=/aws/eks +[11]: https://docs.microsoft.com/en-us/azure/aks/faq#can-i-use-admission-controller-webhooks-on-aks +[12]: https://cloud.google.com/kubernetes-engine/docs/concepts/private-cluster-concept +[13]: https://cloud.google.com/kubernetes-engine/docs/how-to/private-clusters#step_3_add_a_firewall_rule +[14]: https://cloud.google.com/kubernetes-engine/docs/how-to/private-clusters#step_1_view_control_planes_cidr_block +[15]: https://cloud.google.com/kubernetes-engine/docs/how-to/private-clusters#add_firewall_rules +[16]: https://ranchermanager.docs.rancher.com/reference-guides/rancher-webhook#common-issues +[17]: /fr/containers/kubernetes/distributions/#autopilot +[18]: /fr/containers/kubernetes/distributions/#Openshift \ No newline at end of file diff --git a/content/fr/continuous_delivery/_index.md b/content/fr/continuous_delivery/_index.md new file mode 100644 index 00000000000..44099558fbe --- /dev/null +++ b/content/fr/continuous_delivery/_index.md @@ -0,0 +1,61 @@ +--- +cascade: + algolia: + rank: 70 + tags: + - ci/cd + - continuous delivery + - deployment visibility + - deployments + - deployment executions +disable_sidebar: true +further_reading: +- link: continuous_delivery/deployments + tag: Documentation + text: Découvrir comment configurer Deployment Visibility +- link: /continuous_delivery/explorer + tag: Documentation + text: Découvrir comment interroger et visualiser les déploiements +- link: /continuous_delivery/features + tag: Documentation + text: Découvrir les fonctionnalités de CD Visibility +- link: https://www.datadoghq.com/blog/best-practices-for-ci-cd-monitoring/ + tag: Blog + text: Meilleures pratiques pour la surveillance CI/CD +- link: https://app.datadoghq.com/release-notes?category=Software%20Delivery + tag: Notes de version + text: Découvrez les dernières versions de la livraison de logiciels (connexion à + l'application requise). +title: Continuous Delivery Visibility +--- + +{{< callout url="https://docs.google.com/forms/d/e/1FAIpQLScNhFEUOndGHwBennvUp6-XoA9luTc27XBwtSgXhycBVFM9yA/viewform?usp=sf_link" btn_hidden="false" header="Rejoignez la version Preview !" >}} +CD Visibility est en version Preview. Si cette fonctionnalité vous intéresse, remplissez le formulaire pour demander l'accès. +{{< /callout >}} + +Datadog Continuous Delivery (CD) Visibility offre une observabilité sur vos déploiements. CD Visibility intègre les métriques et données de déploiement dans Datadog afin que vous puissiez communiquer l'état de santé de vos déploiements et concentrer vos efforts sur l'amélioration de la capacité de votre équipe à fournir du code de qualité à chaque fois. + +Avec CD Visibility, vous pouvez surveiller les déploiements dans les environnements CD en suivant chaque événement de déploiement. Vous pouvez comprendre les modifications déployées et leur impact sur vos services. + +## Gagner en efficacité grâce aux intégrations directes + +Datadog s'intègre aux [fournisseurs CI][3] et aux fournisseurs CD comme [Argo CD][4] pour suivre les performances d'exécution et les résultats de vos déploiements. + +{{< partial name="continuous_delivery/cd-getting-started.html" >}} + +
+ +Utilisez les données agrégées au fil du temps pour identifier les tendances et améliorer vos stratégies de déploiement afin d'améliorer l'efficacité opérationnelle. + +## Prêt à vous lancer ? + +Consultez [Deployment Visibility][1] pour obtenir des instructions sur la configuration de CD Visibility avec vos fournisseurs CD, des informations sur les exigences de compatibilité et les étapes d'instrumentation et de configuration de la collecte de données. Consultez [Explorer les déploiements CD Visibility][2] pour comprendre comment interroger et visualiser les déploiements. + +## Pour aller plus loin + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /fr/continuous_delivery/deployments +[2]: /fr/continuous_delivery/explorer +[3]: /fr/continuous_delivery/deployments/ciproviders +[4]: /fr/continuous_delivery/deployments/argocd \ No newline at end of file diff --git a/content/ja/account_management/saml/entra.md b/content/ja/account_management/saml/entra.md index fe35ae8b76e..c64608cec93 100644 --- a/content/ja/account_management/saml/entra.md +++ b/content/ja/account_management/saml/entra.md @@ -2,6 +2,7 @@ aliases: - /ja/account_management/saml/azure/ - /ja/account_management/faq/how-do-i-configure-azure-ad-as-a-saml-idp/ +description: Datadog のシングル サインオン認証用の SAML アイデンティティ プロバイダーとして Microsoft Entra ID を構成する。 further_reading: - link: /account_management/saml/ tag: ドキュメント @@ -40,7 +41,7 @@ Datadog ボタンまたはリンクで SSO を使用している場合は、サ 2. Microsoft Entra ID で、アプリケーションの SSO Configuration セクションに移動し、**Show advanced URL settings** をチェックして、シングル サインオン URL を追加します。 -## その他の参考資料 +## 参考資料 {{< partial name="whats-next/whats-next.html" >}} diff --git a/content/ja/account_management/scim/_index.md b/content/ja/account_management/scim/_index.md index 40c2aaf687b..adbd9d858e7 100644 --- a/content/ja/account_management/scim/_index.md +++ b/content/ja/account_management/scim/_index.md @@ -4,6 +4,8 @@ algolia: - scim - アイデンティティプロバイダー - IdP +description: Microsoft Entra ID と Okta (いずれもアイデンティティ プロバイダー) との SCIM 統合を使用して、Datadog + でユーザーのプロビジョニングとデプロビジョニングを自動化します。 further_reading: - link: /account_management/scim/azure/ tag: ドキュメント @@ -21,7 +23,7 @@ SCIM は Infrastructure Pro プランおよび Infrastructure Enterprise プラ ## 概要 -SCIM (System for Cross-domain Identity Management) は、ユーザープロビジョニングの自動化を可能にするオープンスタンダードです。SCIM を使用すると、組織のアイデンティティプロバイダー (IdP) と同期して、Datadog 組織のユーザーを自動的にプロビジョニングおよびデプロビジョニングすることができます。 +[SCIM][9] (System for Cross-domain Identity Management) は、ユーザー プロビジョニングの自動化を可能にするオープン スタンダードです。SCIM を使用すると、組織のアイデンティティ プロバイダー (IdP) と同期して、Datadog 組織のユーザーを自動的にプロビジョニングおよびデプロビジョニングできます。 ### サポートされる機能 @@ -31,7 +33,9 @@ SCIM (System for Cross-domain Identity Management) は、ユーザープロビ - Datadog へのシングルサインオン (推奨) - Managed Teams: IdP のグループから Datadog チームを作成し、Datadog チームのメンバーシップを IdP のグループメンバーシップと同期させます。 -Datadog では、Microsoft Entra ID と Okta アイデンティティプロバイダーを使用した SCIM がサポートされています。SCIM を構成するには、お使いの IdP のドキュメントを参照してください。 +Datadog は SCIM サーバー プロトコルを実装しています。Datadog は Microsoft Entra ID と Okta (いずれもアイデンティティ プロバイダー) での SCIM の使用をサポートしています。その他のアイデンティティ プロバイダーでも動作する可能性はありますが、明示的にはサポートされていません。 + +サポート対象のアイデンティティ プロバイダー向けに SCIM を構成するには、お使いの IdP のドキュメントを参照してください: - [Microsoft Entra ID][2] - [Okta][3] @@ -53,11 +57,7 @@ SCIM を有効化するためにユーザーに紐付けられているアプリ データへのアクセスを失わないために、Datadog は SCIM 専用の[サービスアカウント][6]を作成することを強く推奨します。そのサービスアカウント内で、SCIM インテグレーションで使用するアプリケーションキーを作成します。 -## メール認証 - -SCIM で新規ユーザーを作成すると、そのユーザーにメールが送信されます。初めてアクセスする場合は、メールで共有された招待リンクからログインする必要があります。リンクは 2 日間有効です。有効期限が切れた場合は、[ユーザー設定ページ][7]に移動し、ユーザーを選択して招待リンクを再送信してください。 - -## その他の参考資料 +## 参考資料 {{< partial name="whats-next/whats-next.html" >}} @@ -68,4 +68,5 @@ SCIM で新規ユーザーを作成すると、そのユーザーにメールが [5]: /ja/account_management/api-app-keys [6]: /ja/account_management/org_settings/service_accounts [7]: https://app.datadoghq.com/organization-settings/users -[8]: /ja/help/ \ No newline at end of file +[8]: /ja/help/ +[9]: https://scim.cloud/ \ No newline at end of file diff --git a/content/ja/continuous_integration/explorer/search_syntax.md b/content/ja/continuous_integration/explorer/search_syntax.md index 99a6cea4a43..3f4d4c767a6 100644 --- a/content/ja/continuous_integration/explorer/search_syntax.md +++ b/content/ja/continuous_integration/explorer/search_syntax.md @@ -1,6 +1,9 @@ --- description: CI Visibility Explorer でパイプライン実行のすべてを検索する方法を説明します。 further_reading: +- link: /getting_started/search/ + tag: ドキュメント + text: Datadog で検索を始める - link: /continuous_integration/search tag: ドキュメント text: パイプラインをフィルターおよびグループ化する @@ -74,7 +77,7 @@ title: CI Visibility Explorer の検索構文 タグが[タグのベストプラクティス][5]に従わず、`key:value` 構文も使用していない場合は、`tags:` の検索クエリを使用します。 -## 参考資料 +## 関連情報 {{< partial name="whats-next/whats-next.html" >}} diff --git a/content/ja/coscreen/troubleshooting.md b/content/ja/coscreen/troubleshooting.md index 5fe34fe0ce6..0fe81afde06 100644 --- a/content/ja/coscreen/troubleshooting.md +++ b/content/ja/coscreen/troubleshooting.md @@ -1,15 +1,16 @@ --- +description: 音声品質、画面共有の最適化、ネットワーク接続、プラットフォーム固有の問題など、CoScreen の問題のトラブルシューティングを行います。 is_beta: false title: CoScreen の最適化およびトラブルシューティング --- -### Why does the audio quality degrade when using the microphone of my Bluetooth headset as input in CoScreen, Zoom, and other tools? +### CoScreen、Zoom、またはその他のツールで Bluetooth ヘッドセットのマイクを入力として使用すると、音質が低下するのはなぜですか？ -If you're using a Bluetooth headset, the playback quality may degrade when your headset's microphone is selected as an audio input device. You may notice this if you play audio (for example, play a YouTube video) while you are in a CoScreen session. This can occur because your Bluetooth headset has switched to using a different Bluetooth profile. +Bluetooth ヘッドセットを使用している場合、ヘッドセットのマイクがオーディオ入力のデバイスとして選択されていると、再生品質が低下することがあります。CoScreen セッション中にオーディオを再生 (例えば YouTube ビデオの再生) すると、この現象に気付くことがあります。これは、Bluetooth ヘッドセットが別の Bluetooth プロファイルの使用に切り替えたために起こる可能性があります。 -When only playing audio, Bluetooth headsets typically use the [A2DP profile][2], which is optimized for high audio quality but does not support using the microphone. If you choose your headset microphone as audio input (for example, during a CoScreen session or Zoom meeting) the headset switches to a different profile, usually [HFP][3] or [HSP][4], which supports microphone usage but has lower sound quality. Most Bluetooth headsets can use only one profile at a time. +オーディオ再生のみの場合、Bluetooth ヘッドセットは通常 [A2DP プロファイル][2]を使用しており、高音質に最適化されていますが、マイクの使用には対応していません。たとえば CoScreen セッションや Zoom ミーティングなどでオーディオ入力としてヘッドセットマイクを選択すると、ヘッドセットは別のプロファイル、通常だと [HFP][3] または [HSP][4] に切り替わり、マイクの使用をサポートしますが、音質は低くなります。ほとんどの Bluetooth ヘッドセットは一度に 1 つのプロファイルしか使用できません。 -To avoid this issue, you can use a different audio input—such as a laptop's built-in microphone. You may need to restart your application to regain high quality audio. +この問題を回避するために、ノートパソコンの内蔵マイクなど別の音声入力を使うことができます。高音質を取り戻すためにアプリケーションを再起動する必要がある場合があります。 ### 画面共有の品質やリモートコントロールのレイテンシーを最適化するにはどうすればよいですか？ diff --git a/content/ja/dashboards/widgets/timeseries.md b/content/ja/dashboards/widgets/timeseries.md index 67cc3523e9c..cd3bccef007 100644 --- a/content/ja/dashboards/widgets/timeseries.md +++ b/content/ja/dashboards/widgets/timeseries.md @@ -37,7 +37,9 @@ widget_type: Timeseries ## 表示オプション -グラフは、折れ線、面積、棒グラフで表示することができます。折れ線グラフには、さらにパラメーターが含まれています。 +グラフは、折れ線グラフ、面グラフ、棒グラフとして表示できます。Datadog のグラフでは、1 時間ごとの合計など、データが[一定間隔][15]で集計されます。デフォルトでは、時系列グラフで最後の時間間隔が未完了の場合、その区間は影付きで表示され、「partial data」とラベル付けされます。 + +折れ線グラフには、次の追加パラメーターがあります: | パラメーター | オプション | |-----------|--------------------------| @@ -133,17 +135,21 @@ Y 軸コントロールは、UI と JSON エディタで使用できます。Y ### 全画面 -[標準の全画面オプション][11]のほかに、前回の期間と比較する、Y 軸の目盛を調整する、変更を保存する、新しいグラフとして保存するなどの簡単な関数を適用できます。 +[標準の全画面オプション][11]に加えて、クイック関数を適用したり、Y 軸のスケールを調整したり、変更を保存したり、新しいグラフとして保存したりできます。 詳しくは、[フルスクリーングラフモードでデータを探る][12]をご覧ください。 +### メトリクス情報 + +メトリクス グラフで、コンテキスト メニュー(縦に並んだ 3 つのドット)をクリックし、**Metrics Info** オプションを選択します。このオプションを選択すると、メトリクスの説明を含むパネルが開きます。このパネル内のメトリクス名をクリックすると、メトリクス サマリー ページでメトリクスが開き、さらに分析したり編集したりできます。 + ## API このウィジェットは **[Dashboards API][13]** で使用できます。[ウィジェット JSON スキーマ定義][14]については、以下の表を参照してください。 {{< dashboards-widgets-api >}} -## その他の参考資料 +## 参考情報 {{< partial name="whats-next/whats-next.html" >}} @@ -160,4 +166,5 @@ Y 軸コントロールは、UI と JSON エディタで使用できます。Y [11]: /ja/dashboards/widgets/#full-screen [12]: https://www.datadoghq.com/blog/full-screen-graphs [13]: /ja/api/latest/dashboards/ -[14]: /ja/dashboards/graphing_json/widget_json/ \ No newline at end of file +[14]: /ja/dashboards/graphing_json/widget_json/ +[15]: /ja/dashboards/functions/rollup/ \ No newline at end of file diff --git a/content/ja/developers/authorization/oauth2_in_datadog.md b/content/ja/developers/authorization/oauth2_in_datadog.md index 5def24a210a..6fa35c67098 100644 --- a/content/ja/developers/authorization/oauth2_in_datadog.md +++ b/content/ja/developers/authorization/oauth2_in_datadog.md @@ -49,7 +49,7 @@ title: Datadog の OAuth2 `API_KEYS_WRITE` スコープがクライアントに追加されていない場合、このステップは失敗します。このエンドポイントでは、一度だけ表示される API キーを生成し、ユーザーが Datadog アカウント内で削除しない限り、再生成することはできません。**この値は安全なデータベースまたは場所に保存してください**。 -OAuth クライアントの作成、テスト、公開については、[Datadog インテグレーションのための OAuth][5] を参照してください。 +OAuth クライアントの作成、テスト、公開については、[API ベースのインテグレーションを作成する][5] を参照してください。 ### サードパーティロケーションからの認可の開始 @@ -101,7 +101,7 @@ OAuth2 プロトコルはいくつかの付与フローをサポートしてい [2]: /ja/api/latest/scopes/ [3]: /ja/developers/datadog_apps/#oauth-api-access [4]: https://datatracker.ietf.org/doc/html/rfc6749#section-3.2.1 -[5]: /ja/developers/integrations/oauth_for_integrations +[5]: /ja/developers/integrations/api_integration [6]: /ja/developers/authorization/oauth2_endpoints/?tab=authorizationendpoints#request-authorization-from-a-user [7]: /ja/developers/authorization/oauth2_endpoints/?tab=apikeycreationendpoints#create-an-api-key-on-behalf-of-a-user [8]: https://tools.ietf.org/html/rfc6749#section-4.1 diff --git a/content/ja/infrastructure/process/increase_process_retention.md b/content/ja/infrastructure/process/increase_process_retention.md index 9e0f7cb2720..483190efb61 100644 --- a/content/ja/infrastructure/process/increase_process_retention.md +++ b/content/ja/infrastructure/process/increase_process_retention.md @@ -14,6 +14,9 @@ further_reading: - link: https://www.datadoghq.com/blog/rightsize-kubernetes-workloads/ tag: ブログ text: Kubernetes のワークロードをライトサイジングするための実践的なヒント +- link: https://www.datadoghq.com/blog/process-tag-rules/ + tag: ブログ + text: プロセス タグ ルールでインフラストラクチャー上のプロセスの可視性を高める title: プロセスの保持を増やす --- @@ -36,17 +39,17 @@ title: プロセスの保持を増やす {{< img src="infrastructure/process/process2metrics_create.png" alt="プロセスベースのメトリクスを作成" style="width:80%;">}} -1. **タグを選択してクエリにフィルターを適用**: クエリ構文は[ライブプロセス][2]と同じです。フィルターのスコープに一致するプロセスのみが集計対象と認識されます。テキスト検索フィルターはライブプロセスページのみでサポートされています。 +1. **タグを選択してクエリにフィルターを適用**: 利用可能なタグは [Live Processes][2] と同じです。フィルターのスコープに一致するプロセスのみが集計対象となります。テキスト検索フィルターは Live Processes ページでのみサポートされています。 2. **追跡するメジャーを選択**: `Total CPU %` などのメジャーを入力して数値を集計し、対応する `count`、`min`、`max`、`sum`、`avg` の集計メトリクスを作成します。 3. **`group by` にタグを追加**: 選択したタグをディメンションとしてメトリクスに追加し、フィルターの適用、集計、および比較を行います。デフォルトでは、プロセスから生成されたメトリクスに (明示的に追加しない限り) タグは付与されません。ライブプロセスのクエリに対して利用可能なタグは、すべてこのフィールドで使用することができます。 4. **メトリクスに名前を付与**: メトリクスの名前を入力します。プロセスベースのメトリクスには常にプレフィックス _proc._ とサフィックス _[measure_selection]_ が付与されます。 -5. **パーセンタイル集計を追加**: _Include percentile aggregations_ チェックボックスを選択して、p50、p75、p90、p95、p99 パーセンタイルを生成します。パーセンタイルのメトリクスはカスタマーメトリクスとしても扱われ、適宜請求に追加されます。 +5. **パーセンタイル集計を追加**: _Include percentile aggregations_ チェック ボックスを選択して、p50、p75、p90、p95、p99 のパーセンタイルを生成します。パーセンタイル メトリクスもカスタム メトリクスとして扱われ、それに応じて課金されます。 メトリクス作成モーダルの一番下にある **Create Another** チェックボックスを選択することで、同じクエリを使用して複数のメトリクスを作成できます。このボックスを選択すると、モーダルはメトリクスが作成された後も開いたままの状態となり、フィルターと集計グループが事前に入力されます。 **注**: プロセスベースのメトリクスのデータポイントは 10 秒間隔で生成されます。そのため、メトリクスが作成または更新されてから最初のデータポイントが報告されるまでに最大 3 分の遅延が生じる場合があります。 -
プロセスベースのメトリクスはカスタムメトリクスと見なされ、それに応じて請求されます。請求への影響を避けるために、command や user などの無制限または非常に高いカーディナリティタグによるグループ化は避けてください。
+
プロセス ベースのメトリクスはカスタム メトリクスと見なされ、それに応じて課金されます。請求額への影響を避けるために、command や user などの無制限または非常にカーディナリティの高いタグでのグループ化は避けてください。
### プロセスベースのメトリクスを更新 @@ -64,17 +67,17 @@ title: プロセスの保持を増やす {{< img src="infrastructure/process/process2metrics_dashboard_widget.png" alt="ダッシュボードでプロセスディストリビューションメトリクスのグラフを表示" style="width:80%;">}} -作成後は、Datadog の他のメトリクスと同様に、プロセスディストリビューション集計およびパーセンタイルメトリクスを使用することができます。例は以下の通りです。 +作成後は、Datadog の他のメトリクスと同様に、プロセス ベースのメトリクスを使用することができます。例は以下の通りです。 - ダッシュボードとノートブックでプロセスベースのメトリクスをグラフ化し、重要な作業におけるリソース消費の履歴を追跡 - プロセスベースのメトリクスにしきい値または異常値ベースのモニターを作成し、CPU または RSS メモリーの予期せぬ低下や急上昇を検知 - [メトリクス相関][4]を使用して、内部およびサードパーティーソフトウェアのパフォーマンスに対してリソース消費の変化のコンテキストを取得 -## その他の参考資料 +## 参考資料 {{< partial name="whats-next/whats-next.html" >}} [1]: https://app.datadoghq.com/process?view=metrics [2]: https://app.datadoghq.com/process [3]: /ja/metrics/custom_metrics/ -[4]: /ja/dashboards/correlations/ +[4]: /ja/dashboards/correlations/ \ No newline at end of file diff --git a/content/ja/integrations/amazon_athena.md b/content/ja/integrations/amazon_athena.md index c4c54420b2c..01b2ea57266 100644 --- a/content/ja/integrations/amazon_athena.md +++ b/content/ja/integrations/amazon_athena.md @@ -1,4 +1,24 @@ --- +app_id: amazon-athena +app_uuid: 99ab7fc9-5c16-4411-b0e9-a8e8ebe55792 +assets: + integration: + auto_install: true + events: + creates_events: false + metrics: + check: aws.athena.total_execution_time + metadata_path: assets/metrics/metric-spec.yaml + prefix: aws.athena. + service_checks: + metadata_path: assets/service_checks.json + source_type_id: 239 + source_type_name: Amazon Athena +author: + homepage: https://www.datadoghq.com + name: Datadog + sales_email: info@datadoghq.com + support_email: help@datadoghq.com categories: - クラウド - aws @@ -6,22 +26,37 @@ categories: custom_kind: インテグレーション dependencies: [] description: Amazon Athena のキーメトリクスを追跡 +display_on_public_website: true doc_link: https://docs.datadoghq.com/integrations/amazon_athena/ draft: false git_integration_title: amazon_athena has_logo: true -integration_id: '' +integration_id: amazon-athena integration_title: Amazon Athena integration_version: '' is_public: true -manifest_version: '1.0' +manifest_version: 2.0.0 name: amazon_athena -public_title: Datadog-Amazon Athena インテグレーション -short_description: Amazon Athena のキーメトリクスを追跡 +public_title: Amazon Athena +short_description: 標準的な SQL を使用して Amazon S3 のデータ分析を簡素化するインタラクティブなクエリ サービス。 +supported_os: [] +tile: + changelog: CHANGELOG.md + classifier_tags: + - Category::Cloud + - Category::AWS + - Category::Log Collection + - Offering::Integration + configuration: README.md#Setup + description: 標準的な SQL を使用して Amazon S3 のデータ分析を簡素化するインタラクティブなクエリサービスです。 + media: [] + overview: README.md#Overview + support: README.md#Support + title: Amazon Athena version: '1.0' --- - + ## 概要 Amazon Athena は、標準 SQL を使用して Amazon Simple Storage Service (Amazon S3) でデータを直接、簡単に分析できるようにするインタラクティブなクエリサービスです。 @@ -42,7 +77,7 @@ Amazon Athena は、標準 SQL を使用して Amazon Simple Storage Service (Am ## 収集データ ### メトリクス -{{< get-metrics-from-git "amazon-athena" >}} +{{< get-metrics-from-git "amazon_athena" >}} ### イベント @@ -60,5 +95,5 @@ Amazon Athena インテグレーションには、サービスのチェック機 [1]: https://docs.datadoghq.com/ja/integrations/amazon_web_services/ [2]: https://app.datadoghq.com/integrations/amazon-web-services [3]: https://app.datadoghq.com/integrations/amazon-athena -[4]: https://github.com/DataDog/dogweb/blob/prod/integration/amazon_athena/amazon_athena_metadata.csv +[4]: https://github.com/DataDog/integrations-internal-core/blob/main/amazon_athena/assets/metrics/metric-spec.yaml [5]: https://docs.datadoghq.com/ja/help/ \ No newline at end of file diff --git a/content/ja/integrations/amazon_msk_cloud.md b/content/ja/integrations/amazon_msk_cloud.md new file mode 100644 index 00000000000..df1b8a724b0 --- /dev/null +++ b/content/ja/integrations/amazon_msk_cloud.md @@ -0,0 +1,130 @@ +--- +app_id: amazon-msk +app_uuid: 1d3bab8a-f99a-45ad-b1c6-69e919125029 +assets: + dashboards: + amazon_msk: assets/dashboards/amazon_msk.json + integration: + auto_install: true + events: + creates_events: false + metrics: + check: aws.kafka.zoo_keeper_request_latency_ms_mean + metadata_path: assets/metrics/metric-spec.yaml + prefix: aws.kafka. + service_checks: + metadata_path: assets/service_checks.json + source_type_id: 235 + source_type_name: Amazon MSK +author: + homepage: https://www.datadoghq.com + name: Datadog + sales_email: info@datadoghq.com (日本語対応) + support_email: help@datadoghq.com +categories: +- クラウド +- aws +- ログの収集 +custom_kind: インテグレーション +dependencies: [] +display_on_public_website: true +draft: false +git_integration_title: amazon_msk_cloud +integration_id: amazon-msk +integration_title: Amazon MSK +integration_version: '' +is_public: true +manifest_version: 2.0.0 +name: amazon_msk_cloud +public_title: Amazon MSK +short_description: ストリーミング データを処理するアプリケーションの構築と実行を簡素化します。 +supported_os: [] +tile: + changelog: CHANGELOG.md + classifier_tags: + - Category::Cloud + - Category::AWS + - Category::Log Collection + - Offering::Integration + - 製品::Data Streams Monitoring + configuration: README.md#Setup + description: ストリーミングデータを処理するアプリケーションの構築と実行を簡素化します。 + media: [] + overview: README.md#Overview + resources: + - resource_type: blog + url: https://www.datadoghq.com/blog/monitor-amazon-msk/ + support: README.md#Support + title: Amazon MSK +--- + + +## 概要 + +Amazon Managed Streaming for Apache Kafka (MSK) は、Apache Kafka を使用してストリーミングデータを処理するアプリケーションを、簡単に構築して実行できるフルマネージド型のサービスです。 + +このインテグレーションでは、CloudWatch からメトリクスを収集するクローラーを使用します。Datadog Agent による MSK の監視については、[Amazon MSK (Agent)][1] のページをお読みください。 + +## セットアップ + +Amazon MSK クローラーを有効にして、CloudWatch からの MSK メトリクスを Datadog で確認できるようにします。 + +### インストール + +[Amazon Web Services インテグレーション][2]をまだセットアップしていない場合は、最初にセットアップします。 + +### メトリクスの収集 + +1. [AWS インテグレーションページ][3]で、`Metric Collection` タブの下にある `Kafka` が有効になっていることを確認します。 + +2. [Amazon MSK インテグレーション][4]をインストールします。 + +### ログ収集 + +#### ログの有効化 + +Amazon MSK から S3 バケットまたは CloudWatch のいずれかにログを送信するよう構成します。 + +**注**: +- S3 バケットにログを送る場合は、_Target prefix_ が `amazon_msk` に設定されているかを確認してください。 +- CloudWatch のロググループにログを送る場合は、その名前に `msk` という部分文字列が含まれていることを確認してください。 + +#### ログを Datadog に送信する方法 + +1. [Datadog Forwarder Lambda 関数][5]をまだセットアップしていない場合は、セットアップします。 +2. Lambda 関数がインストールされたら、AWS コンソールから、Amazon MSK ログを含む S3 バケットまたは CloudWatch のロググループに手動でトリガーを追加します。 + + - [S3 バケットに手動トリガーを追加][6] + - [CloudWatch ロググループに手動トリガーを追加][7] + +## 収集データ + +### メトリクス +{{< get-metrics-from-git "amazon_msk_cloud" >}} + + +### イベント + +Amazon MSK クローラーには、イベントは含まれません。 + +### サービスチェック + +Amazon MSK インテグレーションには、サービスのチェック機能は含まれません。 + +## トラブルシューティング + +ご不明な点は、[Datadog のサポートチーム][9]までお問い合わせください。 + +## その他の参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://docs.datadoghq.com/ja/integrations/amazon_msk/ +[2]: https://docs.datadoghq.com/ja/integrations/amazon_web_services/ +[3]: https://app.datadoghq.com/integrations/amazon-web-services +[4]: https://app.datadoghq.com/integrations/amazon-msk +[5]: https://docs.datadoghq.com/ja/logs/guide/forwarder/ +[6]: https://docs.datadoghq.com/ja/logs/guide/send-aws-services-logs-with-the-datadog-lambda-function/#collecting-logs-from-s3-buckets +[7]: https://docs.datadoghq.com/ja/logs/guide/send-aws-services-logs-with-the-datadog-lambda-function/#collecting-logs-from-cloudwatch-log-group +[8]: https://github.com/DataDog/integrations-internal-core/blob/main/amazon_msk_cloud/assets/metrics/metric-spec.yaml +[9]: https://docs.datadoghq.com/ja/help/ \ No newline at end of file diff --git a/content/ja/integrations/azure_load_balancer.md b/content/ja/integrations/azure_load_balancer.md index 1315d796aee..534d8a06472 100644 --- a/content/ja/integrations/azure_load_balancer.md +++ b/content/ja/integrations/azure_load_balancer.md @@ -68,7 +68,7 @@ Datadog Azure インテグレーションを使用して、Azure Load Balancer ## 収集データ ### メトリクス -{{< get-metrics-from-git "azure-load-balancer" >}} +{{< get-metrics-from-git "azure_load_balancer" >}} ### イベント diff --git a/content/ja/integrations/edgecast_cdn.md b/content/ja/integrations/edgecast_cdn.md new file mode 100644 index 00000000000..1a8590763c0 --- /dev/null +++ b/content/ja/integrations/edgecast_cdn.md @@ -0,0 +1,92 @@ +--- +app_id: edgecast-cdn +app_uuid: 2b575f7f-4575-4618-8ebd-f35f7d6a5d22 +assets: + integration: + auto_install: false + events: + creates_events: false + metrics: + check: edgecast.request_count + metadata_path: metadata.csv + prefix: edgecast. + service_checks: + metadata_path: assets/service_checks.json + source_type_id: 619 + source_type_name: Edgecast +author: + homepage: https://www.datadoghq.com + name: Datadog + sales_email: info@datadoghq.com (日本語対応) + support_email: help@datadoghq.com +categories: +- キャッシュ +- モニター +custom_kind: インテグレーション +dependencies: [] +display_on_public_website: true +draft: false +git_integration_title: edgecast_cdn +integration_id: edgecast-cdn +integration_title: Edgecast +integration_version: '' +is_public: true +manifest_version: 2.0.0 +name: edgecast_cdn +public_title: Edgecast +short_description: '[非推奨] Datadog メトリクスを使用した Edgecast CDN トラフィックの監視' +supported_os: +- linux +- windows +- macos +tile: + changelog: CHANGELOG.md + classifier_tags: + - Category::Caching + - Category::Metrics + - Offering::Integration + - Supported OS::Linux + - Supported OS::Windows + - Supported OS::macOS + configuration: README.md#Setup + description: '[非推奨] Datadog メトリクスを使用した Edgecast CDN トラフィックの監視' + media: [] + overview: README.md#Overview + resources: + - resource_type: documentation + url: https://docs.datadoghq.com/integrations/edgecast_cdn/ + support: README.md#Support + title: Edgecast +--- + + +## 概要 + +**_重要なお知らせ_**: Edgecast CDN インテグレーションは、Edgecast のサービス終了に伴い非推奨です。 + +Edgecast (EdgeCast Networks, Inc.) は破産に伴い事業を停止しました。 +基盤となるサービスが終了したため、このインテグレーションは今後機能しません。 +直ちに代替の CDN プロバイダーへの移行を強く推奨します。 +一般的な代替案としては Cloudflare、Akamai、Fastly の CDN サービスなどがあります。タイルは 2025 年 7 月 7 日に削除されます。 + +## セットアップ + +### 構成 + +## 収集データ + +### メトリクス + +### イベント + +### サービスチェック + +## トラブルシューティング + +ご不明な点は、[Datadog のサポートチーム][1]までお問合せください。 + +## その他の参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://docs.datadoghq.com/ja/help \ No newline at end of file diff --git a/content/ja/integrations/gearmand.md b/content/ja/integrations/gearmand.md index 7a3925ec9f2..575ee9af880 100644 --- a/content/ja/integrations/gearmand.md +++ b/content/ja/integrations/gearmand.md @@ -26,10 +26,10 @@ assets: author: homepage: https://www.datadoghq.com name: Datadog - sales_email: info@datadoghq.com + sales_email: info@datadoghq.com (日本語対応) support_email: help@datadoghq.com categories: -- log collection +- ログの収集 custom_kind: インテグレーション dependencies: - https://github.com/DataDog/integrations-core/blob/master/gearmand/README.md @@ -43,19 +43,19 @@ is_public: true manifest_version: 2.0.0 name: gearmand public_title: Gearman -short_description: 実行中およびキューにあるジョブの合計数またはタスクごとの数を追跡。 +short_description: キューにあるジョブと実行中のジョブの合計数またはタスク別の数を追跡 supported_os: - linux - macos tile: changelog: CHANGELOG.md classifier_tags: - - Category::ログの収集 + - Category::Log Collection - Supported OS::Linux - Supported OS::macOS - Offering::Integration configuration: README.md#Setup - description: 実行中およびキューにあるジョブの合計数またはタスクごとの数を追跡。 + description: キューにあるジョブと実行中のジョブの合計数またはタスク別の数を追跡 media: [] overview: README.md#Overview support: README.md#Support @@ -150,7 +150,7 @@ Kubernetes 環境でのログ収集のための Agent の構成については ## 収集データ ### メトリクス -{{< get-metrics-from-git "gearman" >}} +{{< get-metrics-from-git "gearmand" >}} ### イベント @@ -158,7 +158,7 @@ Kubernetes 環境でのログ収集のための Agent の構成については Gearman チェックには、イベントは含まれません。 ### サービスチェック -{{< get-service-checks-from-git "gearman" >}} +{{< get-service-checks-from-git "gearmand" >}} ## トラブルシューティング @@ -171,4 +171,4 @@ Gearman チェックには、イベントは含まれません。 [3]: https://docs.datadoghq.com/ja/agent/guide/agent-commands/#start-stop-and-restart-the-agent [4]: https://docs.datadoghq.com/ja/agent/kubernetes/log/ [5]: https://docs.datadoghq.com/ja/agent/guide/agent-commands/#agent-status-and-information -[6]: https://docs.datadoghq.com/ja/help/ +[6]: https://docs.datadoghq.com/ja/help/ \ No newline at end of file diff --git a/content/ja/integrations/jumpcloud.md b/content/ja/integrations/jumpcloud.md index 3e287996f71..dd221e67b78 100644 --- a/content/ja/integrations/jumpcloud.md +++ b/content/ja/integrations/jumpcloud.md @@ -1,55 +1,16 @@ --- app_id: jumpcloud -app_uuid: 37f8026f-e2ac-4a71-9270-0b03fab814cc -assets: - integration: - auto_install: false - events: - creates_events: false - service_checks: - metadata_path: assets/service_checks.json - source_type_id: 613 - source_type_name: Jumpcloud -author: - homepage: https://www.datadoghq.com - name: Datadog - sales_email: info@datadoghq.com (日本語対応) - support_email: help@datadoghq.com categories: - event management - セキュリティ -custom_kind: integration -dependencies: [] -display_on_public_website: true -draft: false -git_integration_title: jumpcloud -integration_id: jumpcloud -integration_title: Jumpcloud -integration_version: '' -is_public: true -manifest_version: 2.0.0 -name: jumpcloud -public_title: Jumpcloud -short_description: Datadog で Jumpcloud イベントを表示する -supported_os: [] -tile: - changelog: CHANGELOG.md - classifier_tags: - - Category::Event Management - - Category::Security - - Offering::Integration - configuration: README.md#Setup - description: Datadog で Jumpcloud イベントを表示する - media: [] - overview: README.md#Overview - support: README.md#Support - title: Jumpcloud +custom_kind: インテグレーション +description: Datadog で Jumpcloud イベントを表示する +media: [] +title: Jumpcloud --- - - ## 概要 -JumpCloud は、ユーザー認証とネットワーク管理を中心とした Active Directory と LDAP サービスの統合アプローチを提供するクラウドベースのディレクトリプラットフォームです。 +JumpCloud は、ユーザー認証とネットワーク管理を中心とした Active Directory と LDAP サービスの統合アプローチを提供するクラウド ベースのディレクトリ プラットフォームです。 JumpCloud を使用すると、企業は、ソフトウェア、システム、およびネットワークへのユーザーアクセスを管理およびプロビジョニングし、監査証跡でコンプライアンスを実施し、シングルサインオン (SSO) を介して統一されたログインエクスペリエンスを提供することができます。クラウドネイティブプラットフォームである JumpCloud は、従来のディレクトリニーズにドメインレスセキュリティソリューションを提供することで、リモートで柔軟な IT 管理を可能にします。 @@ -71,7 +32,7 @@ JumpCloud インテグレーションにより、以下のアクセスが提供 - MDM イベント: MDM コマンドの結果に関するログ -詳細については、[Datadog で JumpCloud ディレクトリを監視する][1]および [Insights API リファレンス][2]を参照してください。 +詳細については、[Datadog で JumpCloud ディレクトリを監視する](https://www.datadoghq.com/blog/monitor-jumpcloud-directory/)および [Insights API リファレンス](https://docs.jumpcloud.com/api/insights/directory/1.0/index.html)を参照してください。 ## セットアップ @@ -79,15 +40,15 @@ JumpCloud インテグレーションにより、以下のアクセスが提供 インストールは必要ありません。 -### 構成 +### 設定 詳しくは、インテグレーションタイルを参照してください。JumpCloud 管理ポータルからの API キーが必要です。 ## 収集データ -### Logs +### ログ -ログは、単一の API エンドポイントから収集されます。[インサイト API][2] をご確認ください。 +ログは、単一の API エンドポイントから収集されます。[Insights API](https://docs.jumpcloud.com/api/insights/directory/1.0/index.html) を参照してください。 ### メトリクス @@ -95,8 +56,4 @@ JumpCloud インテグレーションには、メトリクスは含まれませ ## トラブルシューティング -ご不明な点は、[Datadog のサポートチーム][3]までお問合せください。 - -[1]: https://www.datadoghq.com/blog/monitor-jumpcloud-directory/ -[2]: https://docs.jumpcloud.com/api/insights/directory/1.0/index.html -[3]: https://docs.datadoghq.com/ja/help/ +お問合せは、[Datadog サポート](https://docs.datadoghq.com/help/) まで。 \ No newline at end of file diff --git a/content/ja/integrations/kube_apiserver_metrics.md b/content/ja/integrations/kube_apiserver_metrics.md index 175a0166a0b..a4f4f5f3c5a 100644 --- a/content/ja/integrations/kube_apiserver_metrics.md +++ b/content/ja/integrations/kube_apiserver_metrics.md @@ -101,7 +101,7 @@ Kubernetes クラスターにマスターノードがあり、`kube-apiserver` `default` ネームスペース内の kubernetes サービスに次のアノテーションを付加できます。 {{< tabs >}} -{{% tab "アノテーション v2 (Datadog Agent v7.36+ 用)" %}} +{{% tab "アノテーション v2 (Datadog Agent v7.36 用)" %}} ```yaml ad.datadoghq.com/endpoints.checks: | @@ -113,11 +113,12 @@ ad.datadoghq.com/endpoints.checks: | } ] } - } - + } ``` + {{% /tab %}} -{{% tab "アノテーション v1 (Datadog Agent < v7.36 用)" %}} + +{{% tab "アノテーション v1 (Datadog Agent v7.36 未満用)" %}} ```yaml annotations: @@ -126,6 +127,7 @@ annotations: ad.datadoghq.com/endpoints.instances: '[{ "prometheus_url": "https://%%host%%:%%port%%/metrics"}]' ``` + {{% /tab %}} {{< /tabs >}} @@ -139,8 +141,10 @@ annotations: クラスターチェックを設定するために、Cluster Agent に[構成][9]を提供します。 -{{< tabs >}} +{{< tabs >}} + {{% tab "Helm" %}} + ```yaml clusterAgent: confd: @@ -154,6 +158,7 @@ clusterAgent: instances: - prometheus_url: "https://%%host%%:%%port%%/metrics" ``` + {{% /tab %}} {{% tab "Operator" %}} @@ -175,7 +180,9 @@ spec: instances: - prometheus_url: "https://%%host%%:%%port%%/metrics" ``` + {{% /tab %}} + {{< /tabs >}} これらの構成により、Agent は `default` ネームスペース内の `kubernetes` サービスに、定義されたエンドポイント IP アドレスとポートでリクエストを行います。 @@ -187,7 +194,7 @@ spec: ## 収集データ ### メトリクス -{{< get-metrics-from-git "kube-apiserver-metrics" >}} +{{< get-metrics-from-git "kube_apiserver_metrics" >}} ### サービスチェック @@ -200,7 +207,8 @@ Kube_apiserver_metrics には、イベントは含まれません。 ## トラブルシューティング -ご不明な点は、[Datadog のサポートチーム][12]までお問合せください。 +ご不明な点は、[Datadog のサポートチーム][11]までお問合せください。 + [1]: https://raw.githubusercontent.com/DataDog/integrations-core/master/kube_apiserver_metrics/images/screenshot.png [2]: https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver @@ -212,5 +220,4 @@ Kube_apiserver_metrics には、イベントは含まれません。 [8]: https:docs.datadoghq.com//containers/cluster_agent/clusterchecks/?tab=datadogoperator#setting-up-check-configurations [9]: https://docs.datadoghq.com/ja/containers/cluster_agent/clusterchecks/?tab=helm#configuration-from-configuration-files [10]: https://docs.datadoghq.com/ja/agent/faq/agent-commands/#agent-status-and-information -[11]: https://github.com/DataDog/integrations-core/blob/master/kube_apiserver_metrics/metadata.csv -[12]: https://docs.datadoghq.com/ja/help/ \ No newline at end of file +[11]: https://docs.datadoghq.com/ja/help/ \ No newline at end of file diff --git a/content/ja/integrations/lambdatest.md b/content/ja/integrations/lambdatest.md index 424f06ebf50..faaa48d3dba 100644 --- a/content/ja/integrations/lambdatest.md +++ b/content/ja/integrations/lambdatest.md @@ -1,78 +1,21 @@ --- app_id: lambdatest -app_uuid: 8d4556af-b5e8-4608-a4ca-4632111931c1 -assets: - dashboards: - LambdaTest: assets/dashboards/overview.json - integration: - auto_install: true - configuration: {} - events: - creates_events: false - metrics: - check: [] - metadata_path: metadata.csv - prefix: lambdatest. - service_checks: - metadata_path: assets/service_checks.json - source_type_id: 10243 - source_type_name: LambdaTest - logs: - source: lambdatest - oauth: assets/oauth_clients.json -author: - homepage: https://github.com/DataDog/integrations-extras - name: LambdaTest - sales_email: prateeksaini@lambdatest.com - support_email: prateeksaini@lambdatest.com categories: - 自動化 - コンテナ - インシデント - 問題追跡 - テスト -custom_kind: integration -dependencies: -- https://github.com/DataDog/integrations-extras/blob/master/lambdatest/README.md -display_on_public_website: true -draft: false -git_integration_title: lambdatest -integration_id: lambdatest -integration_title: LambdaTest -integration_version: '' -is_public: true -manifest_version: 2.0.0 -name: lambdatest -public_title: LambdaTest -short_description: 最も強力な自動テストプラットフォーム +custom_kind: インテグレーション +description: 最も強力な自動テストプラットフォーム +integration_version: 1.0.0 +media: [] supported_os: - linux - windows - macos -tile: - changelog: CHANGELOG.md - classifier_tags: - - Category::Automation - - Category::Containers - - Category::Incidents - - Category::Issue Tracking - - Category::Testing - - Supported OS::Linux - - Supported OS::Windows - - Supported OS::macOS - - Offering::Integration - configuration: README.md#Setup - description: 最も強力な自動テストプラットフォーム - media: [] - overview: README.md#Overview - support: README.md#Support - title: LambdaTest - uninstallation: README.md#Uninstallation +title: LambdaTest --- - - - - ## 概要 LambdaTest と統合することで、チームのコラボレーションと効率的なテストが可能になります。LambdaTest はクラウドベースのテストプラットフォームで、2000 以上のブラウザ、ブラウザバージョン、OS に対応した Web サイトや Web アプリケーションで手動テストと自動テストを実行することが可能です。 @@ -92,23 +35,23 @@ LambdaTest でできることは以下の通りです。 ## セットアップ -構成はすべて LambdaTest ダッシュボード上で行われます。[LambdaTest-Datadog インテグレーション][1]セットアップドキュメントを参照してください。 +設定はすべて LambdaTest ダッシュボードで行われます。[LambdaTest-Datadog インテグレーション](https://www.lambdatest.com/support/docs/datadog-integration/)のセットアップ ドキュメントを参照してください。 -### 構成 +### 設定 LambdaTest を使用して Datadog でインシデントを追跡する方法を紹介します。 1. LambdaTest の Login ページから LambdaTest インテグレーションの認可を開始するには、**Connect Accounts** をクリックします。 -2. LambdaTest の Web サイトで LambdaTest のアカウントにログインすると、Datadog の認可ページにリダイレクトされます。 -3. **Authorize** をクリックし、インテグレーションを完了します。 -4. インテグレーション構成が完了すると、確認メールが送信されます。 -5. Datadog が LambdaTest アカウントと統合されたら、バグのログを取り、クロスブラウザテストを開始します。 +1. LambdaTest の Web サイトで LambdaTest のアカウントにログインすると、Datadog の認可ページにリダイレクトされます。 +1. **Authorize** をクリックし、インテグレーションを完了します。 +1. インテグレーション構成が完了すると、確認メールが送信されます。 +1. Datadog が LambdaTest アカウントと統合されたら、バグのログを取り、クロスブラウザテストを開始します。 ## アンインストール このインテグレーションをアンインストールすると、それまでの認可はすべて取り消されます。 -さらに、このインテグレーションに関連するすべての API キーが無効になっていることを、[API キー管理ページ][2]でインテグレーション名を検索して確認してください。 +さらに、このインテグレーションに関連するすべての API キーが無効になっていることを、[API キー管理ページ](/organization-settings/api-keys?filter=LambdaTest)でインテグレーション名を検索して確認してください。 ## サポート @@ -116,7 +59,4 @@ LambdaTest を使用して Datadog でインシデントを追跡する方法を メール: support@lambdatest.com 電話: +1-(866)-430-7087 -Web サイト: https://www.lambdatest.com/ - -[1]: https://www.lambdatest.com/support/docs/datadog-integration/ -[2]: https://app.datadoghq.com/organization-settings/api-keys?filter=LambdaTest +Web サイト: https://www.lambdatest.com/ \ No newline at end of file diff --git a/content/ja/integrations/servicenow.md b/content/ja/integrations/servicenow.md index d6d152a190e..e374d50891c 100644 --- a/content/ja/integrations/servicenow.md +++ b/content/ja/integrations/servicenow.md @@ -1,70 +1,181 @@ --- +app_id: servicenow +app_uuid: 5bd1d6c7-614b-4c49-95ad-d200041735c3 +assets: + integration: + auto_install: false + events: + creates_events: false + service_checks: + metadata_path: assets/service_checks.json + source_type_id: !!int "105" + source_type_name: ServiceNow +author: + homepage: https://www.datadoghq.com + name: Datadog + sales_email: info@datadoghq.com + support_email: help@datadoghq.com categories: - alerting - incidents -- issue tracking - notifications +- network +- collaboration +- security +- event management custom_kind: インテグレーション dependencies: [] -description: Datadog アラートからチケットを自動的に生成および更新 -doc_link: https://docs.datadoghq.com/integrations/servicenow/ +display_on_public_website: true draft: false -further_reading: -- link: https://www.datadoghq.com/blog/create-servicenow-tickets-from-datadog-alerts/ - tag: ブログ - text: Datadog アラートからの ServiceNow チケットの作成 -- link: https://www.datadoghq.com/blog/servicenow-cmdb-it-management-datadog/ - tag: ブログ - text: ServiceNow CMDB と Datadog を使用してインフラストラクチャーを管理する git_integration_title: servicenow -has_logo: true -integration_id: '' +integration_id: servicenow integration_title: ServiceNow -integration_version: '' +integration_version: "" is_public: true -manifest_version: '1.0' +manifest_version: 2.0.0 name: servicenow -public_title: Datadog-ServiceNow インテグレーション -short_description: Datadog アラートからチケットを自動的に生成および更新 -team: web-integrations -version: '1.0' +public_title: ServiceNow +short_description: ServiceNow のインシデントを作成し、CMDB の CI を取り込み、Datadog のリソース、ログ、イベントを CMDB データでエンリッチします。 +supported_os: [] +tile: + changelog: CHANGELOG.md + classifier_tags: + - "Category::Alerting" + - "Category::Incidents" + - "Category::Notifications" + - "Category::ネットワーク" + - "Category::コラボレーション" + - "Category::Security" + - "Category::Event Management" + - "Offering::Integration" + configuration: README.md#Setup + description: ServiceNow インシデントを作成し、CMDB CI に入力し、Datadog のリソース、ログ、イベントを CMDB データで強化します。 + media: + - caption: CMDB メタデータで Datadog ホストをエンリッチします。 + image_url: images/carousel_1.png + media_type: image + - caption: CMDB メタデータで Datadog ネットワーク デバイスをエンリッチします。 + image_url: images/carousel_2.png + media_type: image + - caption: CMDB リファレンス テーブルでログとイベントをエンリッチします。 + image_url: images/carousel_3.png + media_type: image + - caption: Datadog アラートから ServiceNow チケットを作成。 + image_url: images/carousel_4.png + media_type: image + - caption: Datadog Incident Management で ServiceNow インシデントを作成。 + image_url: images/carousel_5.png + media_type: image + overview: README.md#Overview + resources: + - resource_type: blog + url: https://www.datadoghq.com/blog/servicenow-cmdb-it-management-datadog/ + - resource_type: blog + url: https://www.datadoghq.com/blog/create-servicenow-tickets-from-datadog-alerts/ + - resource_type: ドキュメント + url: https://docs.datadoghq.com/integrations/servicenow/ + support: README.md#Support + title: ServiceNow --- - + + ## 概要 -ServiceNow は、企業のエンタープライズレベルの IT プロセスを 1 か所で記録、追跡、管理するための IT サービス管理プラットフォームです。 +ServiceNow は、企業のエンタープライズ レベルの IT プロセスを 1 か所で記録、追跡、管理するための IT サービス管理プラットフォームです。 +Datadog ServiceNow インテグレーションは双方向のインテグレーションで、以下のことが可能です: -Datadog ServiceNow インテグレーションは双方向インテグレーションです。これを使用すると、以下のことが可能です。 +ITOM/ITSM +- Datadog で生成されたイベントを ServiceNow のチケットに送信し、また IT サービス管理 (ITSM) および IT 運用管理 (ITOM) を通じて Datadog 内部で解決ワークフローを管理します。 -- Datadog で生成されたイベントを ServiceNow のチケットに送信し、また IT サービス管理 (ITSM) および IT 運用管理 (ITOM) を通じて Datadog 内部で解決ワークフローを管理します -- サービスグラフコネクタを使用して、ServiceNow Configuration Management Database (CMDB) の構成アイテム (CI) の発見メカニズムとして Datadog を使用します -- Datadog からのホスト、サービス、およびデバイスの情報を使用して、ServiceNow CMDB に CI として保存されているビジネス固有の情報を充実させることで、インフラストラクチャーの利用状況をより深く理解し、トラブルシューティングを加速し、リソース利用を最大化することができます +サービス グラフ コネクタ +- Datadog サービス グラフ コネクタを使用して、ServiceNow Configuration Management Database (CMDB) の構成アイテム (CI) の検出に Datadog を使用します。 -Datadog は、以下の ServiceNow ツールと統合されます。 +CMDB エンリッチメント +- Datadog からのホスト、サービス、およびデバイスの情報を使用して、ServiceNow CMDB に CI として保存されているビジネス固有の情報を充実させることで、インフラストラクチャーの利用状況をより深く理解し、トラブルシューティングを加速し、リソースを最大限活用することができます。 +- ServiceNow の CI から取得した追加フィールドを使用してログやイベントを自動的にエンリッチするには Datadog Reference Tables を作成します。Reference Tables を使用すると、ホスト名などのプライマリ キーに値フィールドのセットをマッピングし、指定したキーを含むすべてのログやイベントにこれらのフィールドを自動的に追加できます。 -- ITOM -- ITSM -- CMDB **注**: Datadog ServiceNow インテグレーションは、サポート終了と記載されていない [ServiceNow リリース][1]をサポートしています。 -### Datadog で ServiceNow タイルを構成する +### アプリのインストール + +アプリは 2 つの方法でインストールできます。 + +1. ServiceNow ストアから `ITOM/ITSM Integration for Datadog` アプリの最新バージョンをインストールします。 + +![ServiceNow アプリ ストア ITSM/ITOM インテグレーション][2] + +2. 最新の Update Set: [`Datadog-Snow_Update_Set_v2.7.2.xml`][3] をダウンロードして、ServiceNow インスタンスに手動でアップロードします。 + +**Changelog** +- v2.4.0 >= Case Management との一方向同期 +- v2.5.0 >= Incident Management との統合のための Case Management および ITSM テーブルとの双方向同期。ただし、Case Management との双方向同期は、ServiceNow ITSM でのみサポートされています。 +- v2.6.0 >= ITOM/ITSM によるテンプレート化されたモニター通知 +- v2.7.0 >= 手動作成されたインシデントのサポート、相関するアラートの取り込み、追加属性の一方向同期により、Case Management が強化されました。Incident Management が双方向同期に対応しました。最後に、モニターの解決状態に関するバグが修正されました。 + +**ServiceNow で Update Set をインストールする:** + +**注**: 変換マップをカスタマイズしている場合、競合が発生した際に通知され、要件に応じて適切な変更を選択することができます。更新を行う前に、既存の変換マップのカスタマイズをバックアップすることをお勧めします。 + +1. ダウンロードした Update Set の XML ファイルを ServiceNow インスタンスに手動でインポートします。 +2. XML ファイルをインポートすると、Update Set の状態が `Loaded` になります。Update Set の名前をクリックして、変更をプレビューします。 +3. Update Set をプレビューしてエラーがないことを確認したら、**Commit Update Set** を選択してアプリケーションをお使いのシステムにマージします。 + +アプリをインストールしたら、ServiceNow のナビゲーションメニューで **Datadog** を検索し、すべてのテーブルと双方向同期セットアップ用の構成ページにアクセスします。 + +- `Configuration` +- `Datadog Incidents ITSM` +- `Cases ITOM` (旧称: `Datadog Cases ITOM`) +- `Cases ITSM` (旧称: `Datadog Cases ITSM`) +- `Legacy Monitors ITOM` (旧称: `Datadog Monitors ITOM`) +- `Legacy Monitors ITSM` (旧称: `Datadog Monitors ITSM`) +- `Templated Monitors ITOM` +- `Templated Monitors ITSM` + +### Datadog の適切な権限を持つ ServiceNow アカウントを作成 + +インテグレーションを使用するには、ServiceNow ユーザー (例えば、ユーザー名 “datadog” または "datadog_integration") を作成し、そのユーザーに次のロールを割り当てます。 + +- `x_datad_datadog.user` および +- `import_set_loader` および +- `import_transformer` -1. Datadog で、Integrations ページの [ServiceNow インテグレーションタイル][2]に移動します。 +#### インシデント解決 + +
Case Management との双方向同期は、ServiceNow ITSM でのみサポートされています。
+ +解決のためにインシデントの状態を同期する場合、ServiceNow ユーザーは次のロールのいずれかが必要です。 + +- `ITIL` または +- `list_updater` または +- `sn_incident_write` + +#### モニター通知をインシデントおよびイベントテーブルへ直接送信する + +ITOM モジュールの **Event** テーブルまたは ITSM モジュールの **Incident** テーブルに直接通知を送信する場合、ServiceNow ユーザーは以下のロールのいずれかが必要です。 + +- `ITIL` は ITSM 用 +- `evt_mgmt_integration` は ITOM 用 + +**注**: この ServiceNow ユーザー ("datadog" または "datadog_integration") によって ServiceNow でチケットに行われた手動更新は、Datadog へ同期されません。 + +## Datadog で ServiceNow タイルを構成する + +1. Datadog で Integrations ページの [ServiceNow インテグレーション タイル][4] に移動します。 2. **Add New Instance** をクリックします。 3. ServiceNow ドメインのサブドメインであるインスタンス名、`<インスタンス>.service-now.com` を追加します。 4. ServiceNow インスタンスのユーザー名とパスワードを追加します。 **注**: Datadog のためだけに ServiceNow で制限ユーザーを作成できます。 -{{< img src="integrations/servicenow/servicenow-configuration-new-instance-12-23.png" alt="servicenow インテグレーション新規インスタンス" >}} +![ServiceNow インテグレーションの新規インスタンス][5] ## CMDB のセットアップ ### Datadog 用サービスグラフコネクタ -[Observability - Datadog 用サービスグラフコネクタ][3]により、Datadog によって検出された新しいリソースの CMDB に、サーバーとデータベースの構成アイテム (CI) が自動的に入力されます。サービスグラフコネクタは ServiceNow [ストア][4]から入手可能です。 +[Observability - Datadog 用サービス グラフ コネクタ][6]により、Datadog によって検出された新しいリソースについて、CMDB 内のサーバーとデータベースの構成アイテム (CI) が自動的に作成/更新されます。サービス グラフ コネクタは ServiceNow [ストア][7]から入手可能です。 コンフィギュレーションについては、サービスグラフコネクタのガイドに記載されたセットアップ手順に従ってください。 @@ -76,7 +187,27 @@ Datadog は、以下の ServiceNow ツールと統合されます。 下記の記述は、すでに ServiceNow ITOM/ITSM インテグレーションを構成済みの場合のみ適用されます。 - サービスグラフコネクタでは、コンフィギュレーションタイルの `Target table` 値と `Custom table` 値を使用しません。Target テーブルのデフォルト値とのインテグレーションを保存できます。 -- サービスグラフコネクタのセットアップ手順に記載されているように、ユーザーに cmdb_import_api_admin ロールを付与することで、同じ ITOM/ITSM ユーザーをサービスグラフコネクタで使用できます。 +- サービス グラフ コネクタのガイド付きセットアップ手順に記載されているように、ユーザーに `cmdb_import_api_admin` ロールを付与することで、同じ ITOM/ITSM ユーザーをサービス グラフ コネクタで使用できます。 + +### CI フィールドのカスタマイズ + +[Datadog ServiceNow][4] インテグレーション タイルで **Configure** タブをクリックし、次に **Service Graph Connector** タブをクリックします。**Customize CI fields** セクションを展開すると、以下のオプションが利用可能です。 + +CI Type +: このフィールドが適用される CI のタイプ。 + +ServiceNow Field +: 適用対象となる ServiceNow のフィールド。 + +Datadog Tag +: Datadog リソースから送信するタグ。(同じ名前のタグが複数見つかった場合は、カンマで区切られます。) + +たとえば、CI Type が `Host`、ServiceNow Field が `Host Name` の CI フィールドを追加するには、`Datadog Tag` フィールドに任意の _host_ タグ属性を追加します。 + +**注**: `Datadog Tag` フィールドは、Datadog ホスト上に存在するホスト タグでなければなりません。ホスト上の属性タグではありません。 + +![Service Graph Connector タブが表示された ServiceNow インテグレーション タイルのスクリーンショット][8] + ### ホストのタグ付け @@ -84,9 +215,9 @@ Datadog は、以下の ServiceNow ツールと統合されます。 ホストタグの取り込みを有効にするには -1. ServiceNow インスタンスで、Datadog でタグ付けしたいすべてのホストを返す [Query Builder][5] クエリを構成します。 +1. ServiceNow インスタンスで、Datadog でタグ付けしたいすべてのホストを返す [Query Builder][9] クエリを構成します。 1. 希望の更新間隔でクエリを実行するようにスケジュールします。 -1. クエリを ServiceNow に保存したら、Datadog の ServiceNow インテグレーションタイルに移動します。**CMDB Enrichment** タブの **Host Tagging** を選択します。 +1. クエリを ServiceNow に保存したら、Datadog の ServiceNow インテグレーション タイルに移動します。**Configure** 内の **CMDB Enrichment** タブで **Host Tagging** を選択します。 1. **Query Configuration** の下にある、**Add New Query** ボタンをクリックします。 1. ドロップダウンメニューから、**ServiceNow Instance** と **Query** を選択します。 1. クエリの root CI のホスト名フィールドを Datadog のホスト名フィールドにマッピングする **Hostname Column** の値を選択します。 @@ -95,13 +226,19 @@ Datadog は、以下の ServiceNow ツールと統合されます。 クエリのスケジュール実行後すぐにホストタグが Datadog に入力されます。 -{{< img src="integrations/servicenow/host-tags.jpg" alt="ServiceNow のホストタグを表示するホスト情報タブのスクリーンショット" >}} +![ServiceNow のホスト タグが表示された Host info タブのスクリーンショット][10] + +Datadog の [イベント エクスプローラー][11] で、検索クエリのスコープを `source:servicenow` に設定して、取り込みプロセスを監視します。 -Datadog の[イベントエクスプローラー][6]で、検索クエリを `source:servicenow` にスコープして、取り込みプロセスを監視します。 +![実行中の取り込みが 1 件表示されたスクリーンショット][12] -{{< img src="integrations/servicenow/ingestion-progress.jpg" alt="取り込み実行中のスクリーンショット" >}} +#### その他の非 CMDB フィールドのタグ付け -#### トラブルシューティング +一部の ServiceNow テーブルは非 CMDB であり、Query Builder で選択できません。これらのテーブルのタグで Datadog ホストをリッチ化するには、構成タイルの **Additional Fields** をクリックし、上記に従ってホストのタグ付けのためのクエリを構成します。その際には、ドットで連結された完全なパスを指定します。パスは、クエリで構成されたルートテーブルの最初の属性名から始める必要があります。たとえば、root CI が `cmdb_ci_server` のクエリに `vendor.manufacturer.name` と入力すると、ホストに `cmdb_ci_server_manufacturer_name` というタグが設定されます。 + +**注**: Additional Fields で使用できるのは、ServiceNow Table API でサポートされているドット連結パスのみです。多対多のリレーションシップはそのままでは動作せず、追加の設定が必要になる場合があります。 + +#### ホストのタグ付けに関するトラブルシューティング ホストのタグ付けが正しく機能するためには、以下のことがシステムで正しいことを確認してください。 @@ -119,26 +256,26 @@ Datadog の[イベントエクスプローラー][6]で、検索クエリを `so サービスのタグ付けにより、ServiceNow CMDB メタデータで Datadog サービスカタログを充実させます。 -サービスのタグ付けを使用すると、ServiceNow CMDB から Datadog [サービスカタログ][7]にサービスを取り込むことができます。 +サービスのタグ付けを使用すると、ServiceNow CMDB から Datadog [サービス カタログ][13] にサービスを取り込むことができます。 -#### セットアップ +## セットアップ サービスデータの取り込みを有効にするには -1. ServiceNow インスタンスで、サービスカタログをリッチ化したいすべてのサービスを返す [Query Builder][5] クエリを構成します。 +1. ServiceNow インスタンスで、サービス カタログを充実させるのに使用したいすべてのサービスを返す [Query Builder][9] クエリを構成します。 1. 希望の更新間隔でクエリを実行するようにスケジュールします。 -1. クエリを ServiceNow に保存したら、Datadog の ServiceNow インテグレーションタイルに移動します。**CMDB Enrichment** タブの **Service Tagging** を選択します。 +1. クエリを ServiceNow に保存したら、Datadog の ServiceNow インテグレーション タイルに移動します。**Configure** 内の **CMDB Enrichment** タブで **Service Tagging** を選択します。 1. **Query Configuration** の下にある、**Add New Query** ボタンをクリックします。 1. ドロップダウンメニューから、**ServiceNow Instance** と **Query** を選択します。 1. **Service Name Column** ドロップダウンメニューから値を選択します。この値は、クエリのルートサービス CI 上の列名と一致し、サービスカタログのサービス名を入力します。 -1. スキーママッピングを構成して、サービスに関する追加のメタデータをサービスカタログに取り込みます。詳細は[サービス定義][8]を参照してください。Datadog が取り込みを受け入れるためには、マッピングの各フィールドが、サービスカタログのサービス定義スキーマにマッピングされる正しいタイプである必要があります。 +1. スキーママッピングを構成して、サービスに関する追加のメタデータをサービス カタログに取り込みます。詳細は [サービス定義][14] を参照してください。Datadog が取り込みを受け入れるためには、マッピングの各フィールドが、サービス カタログのサービス定義スキーマにマッピングされる正しいタイプである必要があります。 1. **Save** をクリックします。 -Datadog にサービスデータが反映されるのは、クエリのスケジュール実行の数分後です。取り込みエラーを表示するには、[イベントエクスプローラー][6]で `source:servicenow` でイベントを検索します。 +Datadog にサービスデータが反映されるのは、クエリがスケジュール実行されてから数分後です。取り込みエラーを表示するには、[イベント エクスプローラー][11] で `source:servicenow` のイベントを検索します。 -{{< img src="integrations/servicenow/service-metadata.jpg" alt="ServiceNow から入力されたメタデータを示す Service Configuration パネルのスクリーンショット" >}} +![ServiceNow から入力されたメタデータを示す Service Configuration パネルのスクリーンショット][15] -#### トラブルシューティング +#### セットアップに関するトラブルシューティング サービスの取り込みが正しく機能するためには、以下のことがシステムで正しいことを確認してください。 @@ -150,14 +287,14 @@ Datadog にサービスデータが反映されるのは、クエリのスケジ ServiceNow CMDB のデータを用いて、Datadog 内のネットワークデバイスにタグを追加してください。 -デバイスタグ付けを利用することで、Datadog の [Network Device Monitoring][9] で監視しているネットワークデバイスに、ServiceNow CMDB 由来のデバイスメタデータを動的に付与できます。 +デバイスのタグ付けを利用することで、Datadog の [Network Device Monitoring][16] で監視しているネットワーク デバイスを、ServiceNow CMDB 由来のデバイス メタデータで動的にエンリッチできます。 デバイスタグの取り込みを有効にするには -1. ServiceNow インスタンスで [Query Builder][5] を使用してクエリを構成し、そのクエリがデバイスの IP アドレスを返すことを確認してください。 +1. ServiceNow インスタンスで [Query Builder][9] を使用してクエリを構成し、そのクエリがデバイスの IP アドレスを返すことを確認してください。 1. 希望の更新間隔でクエリを実行するようにスケジュールします。 1. Datadog でカスタム IP ネームスペースを使用している場合は、ServiceNow にそれを追加する必要があります。Network device CI 上に **u_dd_device_namespace** という列を作成し、各デバイスに対応するネームスペースを入力します。この列が存在しない場合は、デフォルトのネームスペースが使用されます。 -1. クエリを ServiceNow に保存したら、Datadog の ServiceNow インテグレーションタイルに移動します。**CMDB Enrichment** タブの **Device Tagging** を選択します。 +1. クエリを ServiceNow に保存したら、Datadog の ServiceNow インテグレーション タイルに移動します。**Configure** 内の **CMDB Enrichment** タブで **Device Tagging** を選択します。 1. **Query Configuration** の下にある、**Add New Query** ボタンをクリックします。 1. ドロップダウンメニューから、**ServiceNow Instance** と **Query** を選択します。 1. クエリの IP Address フィールドを Datadog の IP Address フィールドにマッピングする IP Address 列を選択します。 @@ -166,11 +303,11 @@ ServiceNow CMDB のデータを用いて、Datadog 内のネットワークデ クエリがスケジュール実行された後、数分以内にはネットワークデバイスタグが Datadog 上に反映されます。取り込みエラーが発生した場合は、イベントエクスプローラーで表示できるイベントを通じて報告されます。 -Datadog の[イベントエクスプローラー][6]で、検索クエリを `source:servicenow` にスコープして、取り込みプロセスを監視します。 +Datadog の[イベントエクスプローラー][11]で、検索クエリのスコープを `source:servicenow` に設定して、取り込みプロセスを監視します。 -{{< img src="integrations/servicenow/ingestion-progress.jpg" alt="取り込み実行中のスクリーンショット" >}} +![実行中の取り込みが 1 件表示されたスクリーンショット][12] -#### トラブルシューティング +#### ネットワーク デバイスのタグ付けに関するトラブルシューティング - querybuilder のクエリを作成または実行するユーザーが、Datadog 構成で指定されているユーザーと同一であり、かつ `cmdb_query_builder_read` ロールを持っていることを確認してください。 - クエリが ServiceNow の `glide.cmdb.query.max_results_limit` 設定で許可される結果件数を超えていないことを確認してください。 @@ -179,25 +316,25 @@ Datadog の[イベントエクスプローラー][6]で、検索クエリを `so #### 制限 - 取り込みは 1 回の実行につき 100k ホストに制限されています。 -- ネットワークデバイスのタグ付けは [SNMP デバイス][10]に限定されます。 +- ネットワーク デバイスのタグ付けは [SNMP デバイス][17] に限定されます。 - デバイスへの更新は 1 時間あたり数千件に制限されます。スケジュール間隔を選択する際にはこのことを考慮してください。 -### リファレンステーブル +### 参照テーブル -ServiceNow の CI からの追加フィールドを使用してログやイベントを自動的に拡充するには [Reference Tables][11] を使用します。Reference Tables を使用すると、ホスト名などのプライマリキーに値フィールドのセットをマッピングし、指定したキーを含むすべてのログやイベントにこれらのフィールドを自動的に付与できます。 +ServiceNow の CI から取得した追加フィールドを使用してログやイベントを自動的にエンリッチするには [Reference Tables][18] を使用します。Reference Tables を使用すると、ホスト名などのプライマリ キーに値フィールドのセットをマッピングし、指定したキーを含むすべてのログやイベントにこれらのフィールドを自動的に追加できます。 リファレンステーブルの取り込みを有効にするには -1. ServiceNow インスタンスで [Query Builder][12] クエリを構成します。 +1. ServiceNow インスタンスで [Query Builder][19] クエリを構成します。 1. 希望の更新間隔でクエリを実行するようにスケジュールします。 1. クエリを保存してください。 1. **Add New Query** を選択し、ドロップダウンメニューから該当するクエリを選択してください。 1. プライマリキーを選択するドロップダウンで、プライマリキーとして使用する列名を選んでください。 - 1. 任意で、このプライマリキーを用いて [Processing Pipeline][13] を作成し、ログやイベントの拡充および相関付けを行うことができます。 + 1. 任意で、このプライマリ キーを用いて [Processing Pipeline][20] を作成し、ログやイベントのエンリッチおよび相関付けを行うことができます。 1. リファレンステーブルに名前を入力してください。 1. **Save** をクリックします。 -[Reference Table][11] はクエリ保存後、間もなくそのデータで充填されます。 +保存後まもなく、[Reference Table][18] にクエリのデータが取り込まれます。 #### 注意事項および制限事項 @@ -205,112 +342,43 @@ ServiceNow の CI からの追加フィールドを使用してログやイベ - 既存テーブルの削除およびスキーマ更新はサポートされません。 ## ITOM と ITSM のセットアップ - -{{% site-region region="gov,ap1" %}} - -
-Case Management インテグレーションは {{< region-param key=dd_datacenter code="true" >}} サイトではサポートされません。 +{{% site-region region="gov" %}} +
+Case Management インテグレーションは、{{< region-param key=dd_datacenter code="true" >}} サイトではサポートされていません。
{{% /site-region %}} - {{% site-region region="gov" %}} -
-Incident Management インテグレーションは {{< region-param key=dd_datacenter code="true" >}} サイトではサポートされません。 +
+Incident Management インテグレーションは、{{< region-param key=dd_datacenter code="true" >}} サイトではサポートされていません。
{{% /site-region %}} - {{% site-region region="gov" %}} - -
-Templated Monitor Notifications は {{< region-param key=dd_datacenter code="true" >}} サイトではサポートされません。 +
+テンプレート化されたモニター通知は、{{< region-param key=dd_datacenter code="true" >}} サイトではサポートされていません。
{{% /site-region %}} -Monitors、Case Management、および Incident Management 用の Datadog インテグレーションを利用するには、以下の手順に従ってください。 -1. [アプリをインストールする](#install-the-app) -2. [Datadog に対して適切な権限を持つ ServiceNow アカウントを作成する](#create-a-servicenow-account-with-correct-permissions-for-datadog) -3. [ITOM および ITSM で使用する Datadog アプリケーションを構成する](#configure-datadog-applications-for-use-with-itom-and-itsm-modules) - -### アプリをインストールする - -アプリは次の 2 つの方法でインストールできます。 - -1. ServiceNow ストアから最新バージョンの `ITOM/ITSM Integration for Datadog` アプリをインストールします。 - -{{< img src="integrations/servicenow/servicenow-appstore-itxm-integration.png" alt="ServiceNow App Store ITSM/ITOM インテグレーション" >}} - -2. 最新のアップデートセット [`Datadog-Snow_Update_Set_v2.6.1.xml`][14] をダウンロードし、手動で ServiceNow インスタンスにアップロードします。 +モニター、Case Management、Incident Management 向けの Datadog インテグレーションを使用するには、各製品の手順に従ってください: +1. [Datadog のテンプレート化されたモニター通知の構成](#configure-templated-monitor-notifications) +2. [Datadog Case Management の構成](#configure-case-management) +3. [Datadog Incident Management の構成](#configure-incident-management) -**変更履歴** - -- v2.4.0 >= Case Management との一方向同期 -- v2.5.0 >= Case Management および ITSM テーブルとの双方向同期を実現し、Incident Management との統合が可能に。さらに、Case Management との双方向同期は ServiceNow ITSM のみサポートします。 -- v2.6.0 >= ITOM/ITSM を用いた Templated Monitor Notifications に対応 - -ServiceNow でアップデートセットをインストールする手順 - -1. ダウンロードしたアップデートセットの XML ファイルを手動で ServiceNow インスタンスにインポートします。 -2. インポート後、アップデートセットは `Loaded` 状態になります。アップデートセット名をクリックして変更内容をプレビューします。 -3. プレビューでエラーがないことを確認したら、**Commit Update Set** を選択してアプリケーションをシステムに統合します。 - -アプリをインストールしたら、ServiceNow のナビゲーションメニューで **Datadog** を検索し、以下のテーブルや双方向同期設定用の構成ページへアクセスできます。 - -- `Configuration` -- `Datadog Incidents ITSM` -- `Cases ITOM` (旧 `Datadog Cases ITOM`) -- `Cases ITSM` (旧 `Datadog Cases ITSM`) -- `Legacy Monitors ITOM` (旧 `Datadog Monitors ITOM`) -- `Legacy Monitors ITSM` (旧 `Datadog Monitors ITSM`) -- `Templated Monitors ITOM` -- `Templated Monitors ITSM` - -### Datadog 用に適切な権限を持つ ServiceNow アカウントを作成する - -インテグレーションを利用するには、ServiceNow ユーザー (例: "datadog" または "datadog_integration") を作成し、以下のロールをすべて割り当ててください。 -- `x_datad_datadog.user` -- `import_set_loader` -- `import_transformer` - -#### インシデント解決およびクローズ - -
Case Management との双方向同期は ServiceNow ITSM のみサポートしています。
- -解決のためにインシデントの状態を同期する場合、ServiceNow ユーザーは次のロールのいずれかが必要です。 - -- `ITIL` または -- `list_updater` または -- `sn_incident_write` - -クローズのためにインシデントの状態を同期する場合、ServiceNow ユーザーは以下のロールが必要です。 - -- `ITIL_admin` - -#### モニター通知をインシデントおよびイベントテーブルへ直接送信する - -ITOM モジュールの **Event** テーブルまたは ITSM モジュールの **Incident** テーブルに直接通知を送信する場合、ServiceNow ユーザーは以下のロールのいずれかが必要です。 - -- `ITIL` は ITSM 用 -- `evt_mgmt_integration` は ITOM 用 - -**注**: この ServiceNow ユーザー ("datadog" または "datadog_integration") によって ServiceNow でチケットに行われた手動更新は、Datadog へ同期されません。 - -### テンプレート化されたモニター通知 +### テンプレート化されたモニター通知の構成 **注**: この機能にはアプリバージョンが v2.6.0 以上であることが必要です。また、下記の手順を完了する前に Datadog 内の ServiceNow タイルの構成ページでインスタンスを追加する必要があります。 ##### インスタンス優先度マッピングの構成 -{{< img src="integrations/servicenow/servicenow-priority-mapping.png" alt="インテグレーションタイル上の ServiceNow 優先度マッピングフォーム" >}} +![インテグレーション タイル上の ServiceNow 優先度マッピング フォーム][21] 特定のインスタンスに対してテンプレート化されたすべての @ ハンドルに対し、Datadog はこのマッピングに従い、ServiceNow 内でモニター優先度をインパクトおよび緊急度へ自動的にマップします。 `Use Instance Priority Mapping` をオフに切り替えると、ServiceNow レコードでのインパクトおよび緊急度設定が無効になります。 -#### モニターテンプレートの構成 - -{{< img src="integrations/servicenow/servicenow-integration-tile.png" alt="新しい ServiceNow インテグレーションタイル" >}} +##### モニターテンプレートの構成 +![新しい ServiceNow インテグレーション タイル][22] Datadog 内で `@servicenow-` を使用するモニター通知の場合、Datadog 内の ServiceNow インテグレーションタイルの ITOM/ITSM タブにある新しいテンプレート作成 UI を使用して、ServiceNow 通知を作成します。 @@ -318,25 +386,24 @@ Datadog 内で `@servicenow-` を使用するモニター通知 ##### カスタム ServiceNow @ ハンドルの作成 (モニター通知用) -{{< img src="integrations/servicenow/servicenow-monitors.png" alt="新しい ServiceNow インテグレーションタイル上のモニター通知手順" >}} +![新しい ServiceNow インテグレーション タイル上のモニター通知手順][23] 1. `+ New` ボタンをクリックして新しいテンプレートを作成します。 2. モニター通知が配信される @ ハンドル `Name`、`Instance`、`Target Table` を定義します。その後、`Assignment Group`、`Business Service`、`User`、または `Unassigned` のいずれかを選択してレコードに割り当てます。バージョン 2.6.0 で定義された変換マップは、ここで選択した値を用いてインシデント `INC` レコードを自動的に補完します。 新しいテンプレートを使用するには、モニターの説明内に `@servicenow-` を追加します。 -`Customize notification payload` セクションの `Add Field` をクリックして、ペイロードにカスタムフィールドを追加できます。 +[チケット ペイロードとフィールド マッピングでの変数の使用](#use-variables-in-ticket-payload-and-field-mappings) セクションの `Add Field` をクリックして、ペイロードにカスタム フィールドを追加できます。 -#### Case Management の構成 +### Case Management の構成 -{{< img src="integrations/servicenow/servicenow-case-management.png" alt="新しい ServiceNow インテグレーションタイル上の Case Management 手順" >}} +![新しい ServiceNow インテグレーション タイル上の Case Management 手順][24] `Case Management` タブから - 1. Case Management 用に構成したいインスタンスを選択します。 2. ケースを送信するテーブルを `Datadog Cases ITOM` または `Datadog Cases ITSM` から選択します。 **注**: デフォルトではいずれのテーブルも選択されていません。 -3. Datadog 内の [Case Management][15] へ移動します。 +3. Datadog の [Case Management][25] に移動します。 4. Create ServiceNow Incident を選択します。 5. インスタンスおよびオプションの割り当てグループを選び、Create をクリックします。 @@ -344,39 +411,66 @@ Datadog 内で `@servicenow-` を使用するモニター通知 ServiceNow での編集によって Datadog の関連するケースが更新されるようにするには、`x_datad_datadog.user` ロールと `admin` ロールを持つ ServiceNow ユーザーが、ServiceNow で **ITOM/ITSM Integration for Datadog** アプリのインストール設定を構成する必要があります。 -1. 左上の **All** をクリックし、フィルターに `ITOM/ITSM Integration for Datadog` と入力し、フィルターリストに表示される **Configuration** リンクをクリックして、**ITOM/ITSM Integration for Datadog** アプリの構成設定ページに移動します。 +**注**: このセットアップでは、ユーザーの Application Key ではなく、Service Account Application Key を使用することが重要です。ユーザーの Application Key は、ユーザーのアカウント権限に紐付けられます。ユーザーの権限が減少したり、ユーザーが非アクティブになったりすると、ServiceNow と Datadog 間の双方向同期が停止します。 Service Account Application Key は、個々のユーザーには紐付けられないので、双方向同期がユーザーアカウントの変更によって影響を受けることはありません。 + +1. 左上の **All** をクリックし、フィルターに `ITOM/ITSM Integration for Datadog` と入力し、フィルター適用後のリストに表示される **Configuration** リンクをクリックして、**ITOM/ITSM Integration for Datadog** アプリの構成設定ページに移動します。 1. Datadog データセンターサイトを選択します。 1. **Organization Settings** にある Datadog API キーを **API Key** フィールドに貼り付けます。 1. **Organization Settings** にある Datadog Service Account Application Key を **Application Key** フィールドに貼り付けます。 1. Enabled チェックボックスをチェックし、構成の変更を保存します。 -ServiceNow のインストール設定を構成した後、Datadog Case Management に戻り、[インテグレーションを構成][16]します。 +**注**: **Application Scope** (右上の地球儀アイコンからアクセス可能) が`Global` ではなく、`ITOM/ITSM Integration for Datadog` に設定されていることを確認してください。間違ったスコープを使用すると、上記のフィールドを設定する際に権限エラーが発生する可能性があります。 +![Application Scope][26] + +![ServiceNow の変更を Datadog に同期するための ServiceNow の構成設定][27] + +ServiceNow でインストール設定を構成した後、Datadog Case Management に戻り、[インテグレーションを構成][28]します。 + +##### 相関アラートを使用して ServiceNow の値をカスタマイズする + +**注**: この機能にはアプリ バージョン >= v2.7.0 が必要です。 + +相関アラートの情報を使用して ServiceNow の値を入力するために、Datadog Cases ITSM テーブルと Datadog Cases ITOM テーブルの変換マップに変換スクリプトの例 (`onBefore`) が含まれています。デフォルトでは、このスクリプトはコメント アウトされています。このスクリプトを有効にするには、**コメントを解除**し、ユース ケースに合わせて **修正**してください。スクリプトで ServiceNow インシデントの値を入力するには、修正が**必須**です。 + +### Incident Management の構成 + +アプリのインストール後、Incident Management の [Integration Settings][29] にアクセスしてセットアップを完了します。Incident Management と ServiceNow の間で同期されるフィールドの詳細については、[Incident Management フィールド マッピング](#incident-management-field-mappings) を参照してください。 + +##### 状態、影響度、緊急度を Incident Management と双方向に同期 + +ServiceNow での編集によって Datadog の関連するインシデントが更新されるようにするには、`x_datad_datadog.user` ロールと `admin` ロールを持つ ServiceNow ユーザーが、ServiceNow で **ITOM/ITSM Integration for Datadog** アプリのインストール設定を構成する必要があります: **注**: このセットアップでは、ユーザーの Application Key ではなく、Service Account Application Key を使用することが重要です。ユーザーの Application Key は、ユーザーのアカウント権限に紐付けられます。ユーザーの権限が減少したり、ユーザーが非アクティブになったりすると、ServiceNow と Datadog 間の双方向同期が停止します。 Service Account Application Key は、個々のユーザーには紐付けられないので、双方向同期がユーザーアカウントの変更によって影響を受けることはありません。 -{{< img src="integrations/servicenow/datadog-sync-configuration.png" alt="ServiceNow の変更を Datadog で同期するための ServiceNow の構成設定" >}} +1. 左上の **All** をクリックし、フィルターに `ITOM/ITSM Integration for Datadog` と入力し、フィルターリストに表示される **Configuration** リンクをクリックして、**ITOM/ITSM Integration for Datadog** アプリの構成設定ページに移動します。 +1. Datadog データセンターサイトを選択します。 +1. **Organization Settings** にある Datadog API キーを **API Key** フィールドに貼り付けます。 +1. **Organization Settings** にある Datadog Service Account Application Key を **Application Key** フィールドに貼り付けます。 +1. Enabled チェックボックスをチェックし、構成の変更を保存します。 -#### Incident Management の構成 +**注**: **Application Scope** (右上の地球儀アイコンからアクセス可能) が`Global` ではなく、`ITOM/ITSM Integration for Datadog` に設定されていることを確認してください。間違ったスコープを使用すると、上記のフィールドを設定する際に権限エラーが発生する可能性があります。 +![Application Scope][26] -アプリをインストールした後、[Integration Settings][17] へ移動し、インシデントアプリ内でセットアップを完了します。 +ServiceNow でインストール設定を構成した後、Datadog Incident Management に戻り、[インテグレーションを構成][29]します。 -#### レガシーモニター通知 +### レガシーモニター通知 Datadog で `@servicenow-` を使用するレガシーモニター通知の場合、ITOM/ITSM タイルの下部にある "Manage Legacy Monitor Notifications" と題されたセクションで、通知を送信する中間テーブルを選択します。 1. 通知を構成したいインスタンスを選択し、レガシーモニター通知が書き込まれるテーブルを選択します。 2. インテグレーションが正しくセットアップされているかを検証するには、モニターまたはイベント通知に `@servicenow-` を追加します。未加工のデータが中間テーブルの行に挿入され、アプリで指定されている ServiceNow テーブルに転送されます。 -3. ServiceNow 内で[変換マップを使用](#customize-data-with-transform-maps)して、中間テーブルへ送信されるデータの変換をカスタマイズします。 +3. ServiceNow で[変換マップを使用](#customize-data-for-monitor-notifications-with-transform-maps)して、中間テーブルへ送信されるデータの変換をカスタマイズします。 4. Datadog 変数またはカスタム文字列を使用して、通知ペイロードをカスタマイズします。 +5. ServiceNow インシデントに優先度を設定するには、[インシデント優先度のフィールド マッピング](#incident-priority-field-mapping) の手順に従ってください。 -#### 変換マップによるモニター通知データのカスタマイズ +### 変換マップによるモニター通知データのカスタマイズ **Templated Monitors ITSM**、**Legacy Monitors ITSM** および **Datadog Cases ITSM** テーブルは、変換マップを使用して Datadog レコードを ServiceNow インシデントに変換します。 同様に、**Datadog Monitors ITOM** および **Datadog Cases ITOM** は、Datadog レコードを ServiceNow イベントに変換します。 **Templated Monitors ITOM** および **Templated Monitors ITSM** テーブルでは、変換マップを使用して、Datadog レコードをそれぞれ ServiceNow イベントおよびインシデントに変換します。`New Template` UI で通知ペイロードをカスタマイズし、ServiceNow で変換マップを拡張することで、これらのテーブルの ServiceNow イベントとインシデント情報をカスタマイズすることができます。 -**注**: **Datadog Cases ITOM** および **Datadog Cases ITSM** テーブルも同様に変換マップを使用しますが、Datadog ケースのペイロードはカスタマイズできないため、変換マップのカスタマイズは Case Management で使用することは推奨されません。 +**注**: **Datadog Cases ITOM** および **Datadog Cases ITSM** テーブルも同様に変換マップを使用しますが、Datadog ケースのペイロードはカスタマイズできないため、変換マップのカスタマイズは Case Management で使用することは推奨されません。変換マップのカスタマイズが推奨される唯一のケースは、相関アラートのデータを使用する場合です。この方法について詳しくは、[上記](#use-correlated-alerts-to-customize-values-in-servicenow)を参照してください。 ## トラブルシューティング @@ -395,47 +489,198 @@ ServiceNow のテーブルにイベントが表示されず、代わりに ServiceNow ユーザーは、インポートテーブルにアクセスできるように、`rest_service` および `x_datad_datadog.user` ロールが必要です。インシデントテーブルまたはイベントテーブルのいずれかに直接通知を送信する従来の方法を使用している場合は、`itil` および `evt_mgmt_integration` のアクセス許可が必要です。 -Datadog Case Management から ServiceNow への更新が見えても、ServiceNow から Datadog への更新が見えない場合、これは ServiceNow ITOM にとって想定される動作です。 Case Management との双方向同期は ServiceNow ITSM のみでサポートされています。 +Datadog Case Management から ServiceNow への更新は確認できるものの、ServiceNow から Datadog への更新が確認できない場合、これは ServiceNow ITOM では想定される動作です。Case Management との双方向同期は ServiceNow ITSM のみでサポートされています。 -ご不明な点は、[Datadog のサポートチーム][18]までお問い合わせください。 +ご不明な点は、[Datadog のサポート チーム][30] までお問い合わせください。 ## ナレッジベース ### テンプレート化されたモニター ITXM テーブルフィールドおよび変換マップ +`action` +: **タイプ**: 文字列
+モニターで行われているアクション: `create`、`update`、`acknowledge`、`resolve`" + +`additional_information` +: **タイプ**: 文字列
+**ITOM 変換**: `additional_info`
+すべてのイベントの詳細を含む整形された文字列 + +`aggreg_key` +: **タイプ**: 文字列
+アラートを発出しているモニターの ID のハッシュを表す集約キー + +`alert_cycle_key` +: **タイプ**: 文字列
+1 つのモニターのアラート サイクル (アラート → 警告 → 解決を追跡) のハッシュを表すキー。 + +`alert_id` +: **タイプ**: 文字列
+アラートを発出しているモニターの ID + +`alert_metric` +: **タイプ**: 文字列
+**ITOM 変換**: `metric_name`
+アラートのトリガーとなったメトリクス + +`alert_query` +: **タイプ**: 文字列
+アラートのトリガーとなったクエリ + +`alert_scope` +: **タイプ**: 文字列
+アラートのトリガーとなったスコープ + +`alert_status` +: **タイプ**: 文字列
+アラートの現在の状態 + +`alert_title` +: **タイプ**: 文字列
+アラートの名前 + +`alert_transition` +: **タイプ**: 文字列
+**ITSM 変換**: (script) -> state
+アラートの遷移状態: `Triggered`、`Warn`、`Recovered` + +`assignment_group_sys_id` +: **タイプ**: 参照
+**ITSM 変換**: `assignment_group`
+**Reference Table**: Group
+テンプレート化されたハンドルの割り当てグループの ServiceNow sys_id + +`business_service_sys_id` +: **タイプ**: 参照
+**ITSM 変換**: `business_service`
+**Reference Table**: Service
+テンプレート化されたハンドルのビジネス サービスの ServiceNow sys_id + +`custom_fields` +: **タイプ**: 文字列
+JSON 変換可能な文字列として整形された、ユーザー設定のキーと値のフィールド + +`datadog_tags` +: **タイプ**: 文字列
+アラートを発出しているモニターからの Datadog タグ + +`description` +: **タイプ**: 文字列
+**ITSM 変換**: `description`
+**ITOM 変換**: `description`
+モニター アラートの概要 + +`event_details` +: **タイプ**: 文字列
+**ITSM 変換**: `work_notes`
+整形されたクリック可能な Datadog へのリンクを含むイベント詳細 + +`event_id` +: **タイプ**: 文字列
+イベントの Datadog ID + +`event_link` +: **タイプ**: 文字列
+モニター アラートから作成されたイベントへのリンク + +`event_msg` +: **タイプ**: 文字列
+イベントからのメッセージ + +`event_title` +: **タイプ**: 文字列
+**ITSM 変換**: `short_description`
+イベントのタイトル + +`event_type` +: **タイプ**: 文字列
+**ITOM 変換**: `type`
+イベントのタイプ + +`hostname` +: **タイプ**: 文字列
+**ITSM 変換**: `cmdb_ci`
+**ITOM 変換**: `node`
+影響を受けるモニターのホスト + +`impact` +: **タイプ**: 整数
+**ITSM 変換**: `impact`
+モニター優先度のユーザー定義マッピングに基づく影響度の値 + +`logs_sample` +: **タイプ**: 文字列
+関連ログのサンプル + +`monitor_priority` +: **タイプ**: 整数
+**ITOM 変換**: `severity`
+アラートを発出しているモニターの優先度を整数で表したもの + +`org_name` +: **タイプ**: 文字列
+アラートを発出しているモニターの組織の名前 + +`sys_created_by` +: **タイプ**: 文字列
+**ITSM 変換**: `caller_id`
+レコードの作成者 (通常、構成済みの ServiceNow API アカウント) + +`ticket_state` +: **タイプ**: 文字列
+**ITSM 変換**: `state`、(script) -> close_code、(script) -> close_notes
+**ITOM 変換**: (script) -> resolution_notes
+ServiceNow レコードの状態: `new` または `resolved` + +`u_correlation_id` +: **タイプ**: 文字列
+**ITSM 変換**: `correlation_id`
+**ITOM 変換**: `message_key`
+レコードを同じターゲット インシデントに結合するために使用する alert_cycle_key と aggreg_key の組み合わせ + +`urgency` +: **タイプ**: 整数
+**ITSM 変換**: `urgency`
+モニター定義の優先度に基づいて、インテグレーション タイルのユーザー定義マッピングから設定された緊急度 + +`user_sys_id` +: **タイプ**: 参照
+**ITSM 変換**: `assigned_to`
+**Reference Table**: User
+ユーザー用に渡されたテンプレート化されたハンドルから取得した sys_id + + ### Datadog インポートホストのオートフラッシュルール インポートセットテーブル `x_datad_datadog_import_host` が蓄積する行が増えすぎることを防ぐために、最後の 24 時間のデータのみを保持するオートフラッシュルールがテーブルクリーナーツールに追加されました。このコンフィギュレーション設定は、必要に応じて、フィルターナビゲーターで `sys_auto_flush_list.do` に移動し、`x_datad_datadog_import_host` テーブルのルールに入ることで変更できます。必要に応じて `Age in seconds` フィールドを更新できます。 -{{< img src="integrations/servicenow/servicenow-cmdb-autoflush-rule.png" alt="インテグレーション構成設定" >}} +![インテグレーション構成設定][31] -### Datadog アラートからのサポートチケットの自動生成 +### モニターによるインシデントの重複作成 -ServiceNow が Datadog アカウントに接続されると、受信したアラートから自動的にサポートチケットを作成し、それを ServiceNow のチケットキューに送信できます。そこから、サポートチームは、ServiceNow 内で既に確立されている通信ワークフローを使用して、問題の通知を受けます。アラートメッセージで `@servicenow` をメンションするか、モニターの通知リストに `@servicenow` を追加します。 - -{{< img src="integrations/servicenow/servicenow-02-monitor-page.png" alt="ServiceNow" >}} +モニターが警告ごとに新しいインシデントを作成するのではなく、同じインシデントを再オープンすることを防ぐには、モニターがシンプル アラートに設定されていないことを確認してください。メトリクスのタグを使用してグループ化することにより、モニターを[マルチ アラート][32]に変換します。こうすることで、各アラートは個別のインシデントをトリガーします。 ### チケットペイロードとフィールドマッピングでの変数の使用 アラートの本文やフィールドマッピングで変数を使用して、ServiceNow にイベントの詳細を挿入することができます。たとえば、タイトルと重大度を該当する ServiceNow フィールドに含めたり、ServiceNow のチケットから Datadog 内の特定のインシデントに戻るリンクを入れたりすることができます。 -{{< img src="integrations/servicenow/servicenow-variables-form.png" alt="ServiceNow 変数入力フォーム" >}} - -{{< img src="integrations/servicenow/servicenow-variables.png" alt="ServiceNow 変数" >}} +![ServiceNow 変数入力フォーム][33] +![ServiceNow 変数][34] -### インシデント優先度のフィールドマッピング +### 従来のインシデント優先度のフィールド マッピング +**注**: モニターの説明の `Impact` と `Urgency` は、[従来のモニター構成](#legacy-monitor-notifications)でのみ使用できます。[テンプレート化されたモニター](#configure-templated-monitor-notifications)の場合は、[インスタンス優先度のマッピング](#configure-instance-priority-mapping)を構成してください。 -ServiceNow インシデントの `priority` フィールドは読み取り専用で、[優先度ルックアップ規則][19]を使用してのみ更新することができます。 +ServiceNow インシデントの `priority` フィールドは読み取り専用で、[優先度ルックアップ規則][35] を使用してのみ更新することができます。 ServiceNow のインシデント優先度を計算するために、モニターで `Impact` と `Urgency` を定義します。 -{{< img src="integrations/servicenow/servicenow-priority-field-mapping.png" alt="ServiceNow 優先度フィールドマッピング" >}} +![ServiceNow 優先度のフィールド マッピング][36] ### サポート解決ワークフローの自動化 -モニターステータスが正常に戻ると、関連付けられているサポートチケットが自動的に「resolved」としてマークされます。 +モニター ステータスが正常に戻ると、関連付けられているサポート チケットが自動的に "resolved" に変更されます。 -{{< img src="integrations/servicenow/servicenow-03-servicenow-resolved.png" alt="ServiceNow 解決済み" >}} +![ServiceNow Resolved][37] ### カスタムマッピングの定義 @@ -445,11 +690,11 @@ ServiceNow のインシデント優先度を計算するために、モニター 変換マップ名をクリックすると、レコードを確認できます。 -{{< img src="integrations/servicenow/servicenow-click-transform-map.png" alt="servicenow インテグレーション" >}} +![ServiceNow インテグレーション][38] 上部には、変換レコードに関する 2 つの重要なフィールド、`Source table` と `Target table` があります。 -{{< img src="integrations/servicenow/servicenow-source-target-fields.png" alt="servicenow インテグレーション" >}} +![ServiceNow インテグレーション][39] **注**: @@ -460,15 +705,15 @@ ServiceNow のインシデント優先度を計算するために、モニター **New** をクリックします。 -{{< img src="integrations/servicenow/servicenow-click-new.png" alt="servicenow インテグレーション" >}} +![ServiceNow インテグレーション][40] 1 対 1 マッピングのソースフィールドとターゲットフィールドを選択します。 -{{< img src="integrations/servicenow/servicenow-select-source-target.png" alt="servicenow インテグレーション" >}} +![ServiceNow インテグレーション][41] または、**Use source script** チェックボックスをオンにして、変換を定義します。 -{{< img src="integrations/servicenow/servicenow-script-example.png" alt="servicenow インテグレーション" >}} +![ServiceNow インテグレーション][42] **注:** インテグレーションタイルのカスタムフィールドをマッピングする場合、Datadog Monitors ITSM マップと ITSM Transform マップのいずれかに次のマッピングスクリプトを使用できます。この例では、フィールド `my_field` がインテグレーションタイルのカスタムフィールドとして定義されています。 @@ -476,40 +721,93 @@ ServiceNow のインシデント優先度を計算するために、モニター answer = (function transformEntry(source) { var additional_info = JSON.parse(source.additional_info); - return additional_info.custom_my_field; + return additional_info.my_field; })(source); ``` -### 複数のマッピングを定義する - -**Mapping Assist** (関連リンクの下にあります) を使用すると、複数のソースとターゲットフィールドを一度にマップできます。 - -{{< img src="integrations/servicenow/servicenow-mapping-assist.png" alt="servicenow インテグレーション" >}} - ### 検証 -インテグレーションが正しくセットアップされているかを検証するには、モニターまたはイベント通知に `@servicenow` を追加します。未加工のデータが中間テーブルの行に挿入され、作成したマッピングと変換で指定されている ServiceNow テーブルに転送されます。 +インテグレーションが正しくセットアップされているかを検証するには、モニターまたはイベント通知に `@servicenow-` を追加します。未加工のデータが中間テーブルの行に挿入され、作成したマッピングと変換で指定されている ServiceNow テーブルに転送されます。 + +### Incident Management フィールド マッピング +| **Incident Management** | **ServiceNow ケース テーブル** | **ServiceNow インシデント** | **同期ステータス** | +|-------------------------------|-------------------------------------------|----------------------------------|------------------------------------------------------------| +| タイトル | Title - 文字列 | Short Description | Datadog -> ServiceNow の一方向同期 | +| What Happened | Description - 文字列 | 説明 | Datadog -> ServiceNow の一方向同期 | +| 状態 | State - 文字列 | 状態 | 双方向同期 | +| DD Incident URL | Incident URL - 文字列 | Work Notes | Datadog -> ServiceNow の一方向同期 | +| 重大度 | Incident Urgency (整数) | Urgency | 双方向同期 | +| 重大度 | Incident Impact (整数) | 影響 | 双方向同期 | + +| **Datadog モニターの状態** | **ServiceNow インシデントの状態** | +|--------------------------------------------------|-------------------------------| +| Alert | In Progress | +| Warn | In Progress | +| OK | Resolved | +| Completed *(オプションで設定にて構成)* | Resolved | + +| **Datadog インシデント重大度** | **ServiceNow 緊急度** | **ServiceNow インパクト** | **ServiceNow 優先度** | +|-------------------------------|-------------------------|------------------------|--------------------------| +| SEV-1 | 1 | 1 | 1 - クリティカル | +| SEV-2 | 1 | 2 | 2 - 高 | +| SEV-2 | 2 | 1 | 2 - 高 | +| SEV-3 | 1 | 3 | 3 - 中 | +| SEV-3 | 2 | 2 | 3 - 中 | +| SEV-3 | 3 | 1 | 3 - 中 | +| SEV-4 | 2 | 3 | 4 - 低 | +| SEV-4 | 3 | 2 | 4 - 低 | +| SEV-5 (軽微) | 3 | 3 | 5 - 計画中 | +| Unknown | 3 | 3 | 5 - 計画中 | + +**注**: Incident Management Settings で `Start at SEV-0` が有効になっている場合、`ServiceNow Urgency`、`ServiceNow Impact`、`ServiceNow Priority` の値はどれも変わりませんが、`Datadog Incident Severity` は 1 つ下がります。たとえば、1 行目は **Datadog インシデント重大度: SEV-0、ServiceNow 緊急度: 1、ServiceNow インパクト: 1、ServiceNow 優先度: 1 - 重大**になります。 ## その他の参考資料 -{{< partial name="whats-next/whats-next.html" >}} +- [Datadog アラートから ServiceNow チケットを作成する][43] +- [ServiceNow CMDB と Datadog を使用してインフラストラクチャーを管理する][44] [1]: https://www.servicenow.com/community/now-platform-articles/servicenow-versions-release/ta-p/2312014 -[2]: https://app.datadoghq.com/integrations/servicenow -[3]: https://store.servicenow.com/sn_appstore_store.do#!/store/application/c877cb86687e0050f8774bfad236c950/1.2.1 -[4]: https://store.servicenow.com/ -[5]: https://docs.servicenow.com/bundle/xanadu-servicenow-platform/page/product/configuration-management/concept/cmdb-query-builder-landing-page.html -[6]: https://app.datadoghq.com/event/explorer -[7]: https://docs.datadoghq.com/ja/tracing/service_catalog/ -[8]: https://docs.datadoghq.com/ja/tracing/service_catalog/adding_metadata/ -[9]: https://docs.datadoghq.com/ja/network_monitoring/devices/ -[10]: https://docs.datadoghq.com/ja/network_monitoring/devices/snmp_metrics/ -[11]: https://app.datadoghq.com/reference-tables -[12]: https://docs.servicenow.com/bundle/rome-servicenow-platform/page/product/configuration-management/task/use-cmdb-query-builder.html -[13]: https://app.datadoghq.com/event/pipelines -[14]: https://docs.datadoghq.com/resources/xml/Datadog-Snow_Update_Set_v2.6.1.xml -[15]: https://app.datadoghq.com/cases -[16]: https://docs.datadoghq.com/ja/service_management/case_management/settings#servicenow -[17]: https://app.datadoghq.com/incidents/settings#Integrations -[18]: https://docs.datadoghq.com/ja/help/ -[19]: https://docs.servicenow.com/en-US/bundle/sandiego-it-service-management/page/product/incident-management/task/def-prio-lookup-rules.html \ No newline at end of file +[2]: images/servicenow-appstore-itxm-integration.png +[3]: https://docs.datadoghq.com/resources/xml/Datadog-Snow_Update_Set_v2.7.2.xml +[4]: https://app.datadoghq.com/integrations/servicenow +[5]: images/servicenow-configuration-new-instance-12-23.png +[6]: https://store.servicenow.com/sn_appstore_store.do#!/store/application/c877cb86687e0050f8774bfad236c950/1.2.1 +[7]: https://store.servicenow.com/ +[8]: images/SGC_datadog_tag.png +[9]: https://docs.servicenow.com/bundle/xanadu-servicenow-platform/page/product/configuration-management/concept/cmdb-query-builder-landing-page.html +[10]: images/host-tags.jpg +[11]: https://app.datadoghq.com/event/explorer +[12]: images/ingestion-progress.jpg +[13]: https://docs.datadoghq.com/tracing/service_catalog/ +[14]: https://docs.datadoghq.com/tracing/service_catalog/adding_metadata/ +[15]: images/service-metadata.jpg +[16]: https://docs.datadoghq.com/network_monitoring/devices/ +[17]: https://docs.datadoghq.com/network_monitoring/devices/snmp_metrics/ +[18]: https://app.datadoghq.com/reference-tables +[19]: https://docs.servicenow.com/bundle/rome-servicenow-platform/page/product/configuration-management/task/use-cmdb-query-builder.html +[20]: https://app.datadoghq.com/event/pipelines +[21]: images/servicenow-priority-mapping.png +[22]: images/servicenow-integration-tile.png +[23]: images/servicenow-monitors.png +[24]: images/servicenow-case-management.png +[25]: https://app.datadoghq.com/cases +[26]: images/servicenow-application-scope.png +[27]: images/datadog-sync-configuration.png +[28]: https://docs.datadoghq.com/service_management/case_management/settings#servicenow +[29]: https://app.datadoghq.com/incidents/settings#Integrations +[30]: https://docs.datadoghq.com/help/ +[31]: images/servicenow-cmdb-autoflush-rule.png +[32]: https://docs.datadoghq.com/monitors/configuration/?tab=thresholdalert#multi-alert +[33]: images/servicenow-variables-form.png +[34]: images/servicenow-variables.png +[35]: https://docs.servicenow.com/en-US/bundle/sandiego-it-service-management/page/product/incident-management/task/def-prio-lookup-rules.html +[36]: images/servicenow-priority-field-mapping.png +[37]: images/servicenow-03-servicenow-resolved.png +[38]: images/servicenow-click-transform-map.png +[39]: images/servicenow-source-target-fields.png +[40]: images/servicenow-click-new.png +[41]: images/servicenow-select-source-target.png +[42]: images/servicenow-script-example.png +[43]: https://www.datadoghq.com/blog/create-servicenow-tickets-from-datadog-alerts +[44]: https://www.datadoghq.com/blog/servicenow-cmdb-it-management-datadog + diff --git a/content/ja/integrations/sqlserver.md b/content/ja/integrations/sqlserver.md index 9e94738e306..16bbdb790de 100644 --- a/content/ja/integrations/sqlserver.md +++ b/content/ja/integrations/sqlserver.md @@ -23,6 +23,7 @@ assets: monitors: Auto-parameterization attempts are failing: assets/monitors/sqlserver_high_number_failed_auto_param.json Availability Group is not healthy: assets/monitors/sqlserver_ao_not_healthy.json + Availability group failover detected: assets/monitors/sqlserver_ao_failover.json Database is not online: assets/monitors/sqlserver_db_not_online.json Database not in sync: assets/monitors/sqlserver_db_not_sync.json Processes are blocked: assets/monitors/sqlserver_high_processes_blocked.json @@ -42,7 +43,7 @@ draft: false git_integration_title: sqlserver integration_id: sql-server integration_title: SQL Server -integration_version: 20.2.0 +integration_version: 22.7.0 is_public: true manifest_version: 2.0.0 name: sqlserver @@ -82,7 +83,7 @@ tile: title: SQL Server --- - + ![SQL Server のグラフ][1] @@ -119,6 +120,7 @@ SQL Server チェックでサポートされる SQL Server のバージョンは ```SQL CREATE LOGIN datadog WITH PASSWORD = ''; + USE master; CREATE USER datadog FOR LOGIN datadog; GRANT SELECT on sys.dm_os_performance_counters to datadog; GRANT VIEW SERVER STATE to datadog; @@ -127,7 +129,7 @@ SQL Server チェックでサポートされる SQL Server のバージョンは データベースごとにファイルサイズのメトリクスを収集するには、作成したユーザー (`datadog`) にデータベースへの[接続権限アクセス][6]があることを確認するために、以下を実行します。 ```SQL - GRANT CONNECT ANY DATABASE to datadog; + GRANT CONNECT ANY DATABASE to datadog; ``` 2. (AlwaysOn および `sys.master_files` メトリクスの場合に必要metrics) AlwaysOn および `sys.master_files` メトリクスを収集するには、以下の追加権限を付与します。 @@ -136,7 +138,7 @@ SQL Server チェックでサポートされる SQL Server のバージョンは GRANT VIEW ANY DEFINITION to datadog; ``` -### 構成 +### 設定 {{< tabs >}} {{% tab "ホスト" %}} @@ -154,20 +156,22 @@ SQL Server チェックでサポートされる SQL Server のバージョンは - host: "," username: datadog password: "" - connector: odbc # alternative is 'adodbapi' - driver: SQL Server + connector: adodbapi + adoprovider: MSOLEDBSQL19 # Replace with MSOLEDBSQL for versions 18 and previous ``` ポートオートディスカバリーを使用する場合は、`SQL_PORT` に `0` を使用します。カスタムクエリを使用して独自のメトリクスを作成する方法など、すべてのオプションの詳細については、[チェックコンフィギュレーションの例][2]を参照してください。 - **注**: (デフォルトの) プロバイダー `SQLOLEDB` は、非推奨になります。新しい `MSOLEDBSQL` プロバイダーを使用するには、[Microsoft][3] からこのプロバイダーをダウンロードし、`sqlserver.d/conf.yaml`ファイルで `adoprovider` 変数を `MSOLEDBSQL19` に設定します。`MSOLEDBSQL` バージョン 18 以下を使用している場合は、代わりに `adoprovider` 変数を `MSOLEDBSQL` に設定します。また、以下のように指定することで、Windows 認証を使用し、ユーザー名とパスワードを指定せずに済ますこともできます。 + SQL Server の設定に基づき、[サポートされているドライバー][3] を使用してください。 + + **注**: また、以下のように指定することで、Windows 認証を使用し、ユーザー名/パスワードを指定しないこともできます: ```yaml connection_string: "Trusted_Connection=yes" ``` -2. [Agent を再起動します][4]。 +2. [Agent を再起動][4]します。 ##### Linux @@ -200,11 +204,11 @@ _Agent バージョン 6.0 以降で利用可能_ `path` パラメーターと `service` パラメーターの値を環境に合わせて変更してください。使用可能なすべてのコンフィギュレーションオプションの詳細については、[sqlserver.d/conf.yaml のサンプル][2]を参照してください。 -3. [Agent を再起動します][4]。 +3. [Agent を再起動][4]します。 [1]: https://docs.datadoghq.com/ja/agent/guide/agent-configuration-files/#agent-configuration-directory [2]: https://github.com/DataDog/integrations-core/blob/master/sqlserver/datadog_checks/sqlserver/data/conf.yaml.example -[3]: https://docs.microsoft.com/en-us/sql/connect/oledb/oledb-driver-for-sql-server?view=sql-server-2017 +[3]: https://docs.datadoghq.com/ja/database_monitoring/setup_sql_server/selfhosted/#supported-drivers [4]: https://docs.datadoghq.com/ja/agent/guide/agent-commands/#start-stop-and-restart-the-agent [5]: https://docs.microsoft.com/en-us/sql/connect/odbc/linux-mac/installing-the-microsoft-odbc-driver-for-sql-server?view=sql-server-2017 [6]: http://www.freetds.org/ @@ -245,10 +249,10 @@ Datadog Agent で、ログの収集はデフォルトで無効になっていま [Agent の status サブコマンドを実行][7]し、Checks セクションの `sqlserver` を探します。 -## 収集データ +## 収集されるデータ ### メトリクス -{{< get-metrics-from-git "sql-server" >}} +{{< get-metrics-from-git "sqlserver" >}} これらのメトリクスのほとんどは、SQL Server の `sys.dm_os_performance_counters` テーブルにあります。 @@ -257,13 +261,13 @@ Datadog Agent で、ログの収集はデフォルトで無効になっていま SQL Server チェックには、イベントは含まれません。 -### サービスチェック -{{< get-service-checks-from-git "sql-server" >}} +### サービス チェック +{{< get-service-checks-from-git "sqlserver" >}} ## トラブルシューティング -ご不明な点は、[Datadog のサポートチーム][8]までお問合せください。 +ご不明な点は、[Datadog のサポートチーム][8]までお問い合わせください。 ARM aarch64 プロセッサで Agent を実行している場合、Agent バージョン 7.48.0 にバンドルされているこのチェックのバージョン 14.0.0 以降、既知の問題があります。Python の依存関係がロードに失敗し、[Agent の status サブコマンド][7]を実行すると以下のメッセージが表示されます。 @@ -307,4 +311,4 @@ Loading Errors [12]: https://www.datadoghq.com/blog/sql-server-performance [13]: https://www.datadoghq.com/blog/sql-server-metrics [14]: https://www.datadoghq.com/blog/migrate-sql-workloads-to-azure-with-datadog/ -[15]: https://www.datadoghq.com/blog/optimize-sql-server-performance-with-datadog/ +[15]: https://www.datadoghq.com/blog/optimize-sql-server-performance-with-datadog/ \ No newline at end of file diff --git a/content/ja/integrations/system.md b/content/ja/integrations/system.md index adfe55f01f6..5ca499be601 100644 --- a/content/ja/integrations/system.md +++ b/content/ja/integrations/system.md @@ -3,20 +3,20 @@ aliases: - /ja/integrations/system_swap/ - /ja/integrations/system_core/ categories: -- os & system +- OS & システム - configuration & deployment -custom_kind: インテグレーション +custom_kind: integration dependencies: - https://github.com/DataDog/documentation/blob/master/content/en/integrations/system.md -description: システムリソース (CPU、メモリ、ディスク、ファイルシステム) の使用状況を追跡。 +description: システム リソース (CPU、メモリ、ディスク、ファイル システムなど) の使用状況を追跡。 git_integration_title: system -integration_id: システム +integration_id: system integration_title: System チェック is_public: true name: system newhlevel: true public_title: Datadog-System インテグレーション -short_description: システムリソース (CPU、メモリ、ディスク、ファイルシステム) の使用状況を追跡。 +short_description: システムリソース (CPU、メモリ、ディスク、ファイルシステムなど) の使用状況を追跡。 supported_os: - linux - mac_os @@ -38,9 +38,9 @@ updated_for_agent: 5.8.5 System チェックは [Datadog Agent][4] パッケージに含まれています。サーバーに追加でインストールする必要はありません。 -## 収集データ +## 収集されるデータ -### Metrics +### メトリクス {{< get-metrics-from-git "system" "system.cpu system.fs system.io system.load system.mem system.proc. system.swap system.uptime" >}} @@ -71,16 +71,16 @@ System チェックには、サービスのチェック機能は含まれませ システムコアチェックは [Datadog Agent][4] パッケージに含まれています。サーバーに追加でインストールする必要はありません。 -#### 構成 +#### 設定 1. [Agent の構成ディレクトリ][5]のルートにある `conf.d/` フォルダーの `system_core.d/conf.yaml` ファイルを編集します。使用可能な全構成オプションの詳細については、[サンプル system_core.d/conf.yaml][6] を参照してください。**注**: チェックを有効にするには、`instances` に少なくとも 1 つのエントリが必要です。例: ```yaml init_config: instances: - - foo: bar + - foo: bar tags: - - key:value + - key:value ``` 2. [Agent を再起動します][7]。 @@ -89,9 +89,9 @@ System チェックには、サービスのチェック機能は含まれませ [Agent のステータスサブコマンドを実行][4]し、Checks セクションで `system_core` を探します。 -### 収集データ +### 収集されるデータ -#### Metrics +#### メトリクス {{< get-metrics-from-git "system_core" >}} @@ -115,7 +115,7 @@ System コアチェックには、イベントは含まれません。 システムのスワップチェックは [Datadog Agent][4] パッケージに含まれています。サーバーに追加でインストールする必要はありません。 -#### 構成 +#### 設定 1. [Agent の構成ディレクトリ][5]のルートにある `conf.d/` フォルダーの `system_swap.d/conf.yaml` ファイルを編集します。使用可能なすべての構成オプションの詳細については、[サンプル system_swap.d/conf.yaml][8] を参照してください。**注**: このチェックは初期コンフィギュレーションを受け取りません。 @@ -125,9 +125,9 @@ System コアチェックには、イベントは含まれません。 [Agent のステータスサブコマンドを実行][4]し、Checks セクションで `system_swap` を探します。 -### 収集データ +### 収集されるデータ -#### Metrics +#### メトリクス {{< get-metrics-from-git "system_swap" >}} diff --git a/content/ja/logs/guide/ease-troubleshooting-with-cross-product-correlation.md b/content/ja/logs/guide/ease-troubleshooting-with-cross-product-correlation.md index 15a594f7462..af8a904420b 100644 --- a/content/ja/logs/guide/ease-troubleshooting-with-cross-product-correlation.md +++ b/content/ja/logs/guide/ease-troubleshooting-with-cross-product-correlation.md @@ -6,7 +6,7 @@ further_reading: - link: /tracing/other_telemetry/connect_logs_and_traces tag: ドキュメント text: ログとトレースの接続 -- link: /real_user_monitoring/platform/connect_rum_and_traces/ +- link: /real_user_monitoring/correlate_with_other_telemetry/apm/ tag: ドキュメント text: RUM およびセッションリプレイとトレースの接続 - link: /synthetics/apm/ @@ -66,39 +66,9 @@ title: クロスプロダクト相関で容易にトラブルシューティン #### NGINX -##### OpenTracing のセットアップ +NGINX のログとトレースを関連付けるには、トレース ID が含まれるように NGINX の `log_format` を設定し、ログからその ID を解析するための Datadog パイプラインを設定する必要があります。 -[NGINX トレースインテグレーション][5]を参照。 - -##### ログのトレース ID の挿入 - -トレース ID は、`opentelemetry_trace_id` という変数に保存されます。NGINX コンフィギュレーションファイル (`/etc/nginx/nginx.conf`) の HTTP セクションに以下の構成ブロックを追加して、NGINX のログフォーマットを更新します。 - -```conf -http { - log_format main '$remote_addr - $opentelemetry_trace_id $http_x_forwarded_user [$time_local] "$request" ' - '$status $body_bytes_sent "$http_referer" ' - '"$http_user_agent" "$http_x_forwarded_for" '; - - access_log /var/log/nginx/access.log; -} -``` - -##### パイプラインでトレース ID をパース - -1. NGINX パイプラインのクローンを作成します。 - -2. 最初の [grok parser][6] をカスタマイズします。 - - **Parsing rules** で、パースルールを以下と置き換えます。 - ```text - access.common %{_client_ip} %{_ident} %{_trace_id} %{_auth} \[%{_date_access}\] "(?>%{_method} |)%{_url}(?> %{_version}|)" %{_status_code} (?>%{_bytes_written}|-) - ``` - - **Helper Rules** の **Advanced settings** で、行を追加します。 - ```text - _trace_id %{notSpace:dd.trace_id:nullIf("-")} - ``` - -3. `dd.trace_id` 属性で [トレース ID リマッパー][7]を追加します。 +完全なエンドツーエンドのセットアップ手順については、[NGINX のインスツルメンテーション][20]を参照してください。 ### データベースログの相関付け @@ -219,7 +189,7 @@ APM と Synthetic Monitoring のインテグレーションにより、テスト 詳しくは [Synthetic テストとトレースの接続][19]を参照してください。 -## その他の参考資料 +## 参考資料 {{< partial name="whats-next/whats-next.html" >}} @@ -235,10 +205,11 @@ APM と Synthetic Monitoring のインテグレーションにより、テスト [10]: https://www.postgresql.org/docs/13/sql-syntax-lexical.html#SQL-SYNTAX-COMMENTS [11]: /ja/logs/log_collection/javascript/ [12]: /ja/account_management/billing/rum/#how-do-you-view-logs-from-the-browser-collector-in-rum -[13]: /ja/real_user_monitoring/browser/setup/#initialization-parameters +[13]: /ja/real_user_monitoring/application_monitoring/browser/setup/#initialization-parameters [14]: https://app.datadoghq.com/apm/traces [15]: https://app.datadoghq.com/rum/explorer -[16]: /ja/real_user_monitoring/platform/connect_rum_and_traces +[16]: /ja/real_user_monitoring/correlate_with_other_telemetry/apm [17]: /ja/synthetics/browser_tests/ [18]: https://app.datadoghq.com/synthetics/tests -[19]: /ja/synthetics/apm \ No newline at end of file +[19]: /ja/synthetics/apm +[20]: /ja/tracing/trace_collection/proxy_setup/nginx \ No newline at end of file diff --git a/content/ja/product_analytics/charts/_index.md b/content/ja/product_analytics/charts/_index.md new file mode 100644 index 00000000000..be633533383 --- /dev/null +++ b/content/ja/product_analytics/charts/_index.md @@ -0,0 +1,50 @@ +--- +description: さまざまなチャートは、ユーザーが製品、サービス、またはブランドを発見する際にたどる経路を理解するのに役立ちます。 +further_reading: +- link: /product_analytics/ + tag: ドキュメント + text: プロダクトアナリティクス +title: チャート +--- + +## 概要 + +さまざまなチャートを使用すると、エンドツーエンドのユーザー ジャーニーを可視化し、ユーザーがアプリケーション内をどのように遷移しているかを把握できます。データを抽出することで、ユーザー ジャーニー上のフリクションを特定し、UI 変更の成果を測定し、アプリケーションのデザインに関する意思決定に役立てることができます。 + +## 使用するチャートを選択する + + +### Pathways ダイアグラム + +{{< img src="/product_analytics/overview_pathways_ga.png" alt="Pathways を使用して、アプリケーション内のすべてのユーザー ジャーニーを可視化し、クリティカル パスを分析する">}} + +[Pathways ダイアグラム][3]を使用すると、アプリケーション全体のすべてのユーザー ジャーニーを可視化し、フローに最も大きく寄与している経路を特定できます。 + + +### ファネル分析 + +{{< img src="/product_analytics/overview_funnel_ga.png" alt="ファネル分析でエンドツーエンドのコンバージョンを理解する。">}} + +[ファネル分析][2]を使用すると、1 つの重要なワークフローのエンドツーエンドのコンバージョンを把握できます。サイド パネルで詳細を確認し、コンバージョン率が現在の値になっている理由を理解できます。 +たとえば、パフォーマンスの問題が原因でユーザーが離脱したかどうかを判断できます。顧客は最近のリリースで発生したエラーに遭遇していないでしょうか。コンバージョンしたユーザー、または離脱したユーザーのセッション リプレイを確認して、何が起こったのかを正確に把握できます。 + +### Retention Analysis + +{{< img src="/product_analytics/overview_retention_ga.png" alt="ファネル分析でエンドツーエンドのコンバージョンを理解する。">}} + +[リテンション分析][4]では、ユーザーがページやアクションにどれくらいの頻度で正常に戻ってきているかを測定できます。この指標により、アプリケーションに対する全体的なユーザー満足度に関する洞察が得られます。 + +### アナリティクス エクスプローラー + +{{< img src="/product_analytics/overview_analytic_ga.png" alt="ファネル分析でエンドツーエンドのコンバージョンを理解する。">}} + +[アナリティクス エクスプローラー][1]には、製品がどのように使用されているかを理解するのに役立つビューとデータ集計が含まれています。その可視化を基にダッシュボードにウィジェットを作成し、可視化で利用できる操作に応じて、イベント リストのサブセットをさらに詳しく分析できます。 + + +## 参考資料 +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ja/product_analytics/charts/analytics_explorer/ +[2]: /ja/product_analytics/charts/funnel_analysis +[3]: /ja/product_analytics/charts/pathways +[4]: /ja/product_analytics/charts/retention_analysis \ No newline at end of file diff --git a/content/ja/product_analytics/charts/pathways.md b/content/ja/product_analytics/charts/pathways.md new file mode 100644 index 00000000000..2cdafb807ab --- /dev/null +++ b/content/ja/product_analytics/charts/pathways.md @@ -0,0 +1,75 @@ +--- +aliases: +- /ja/real_user_monitoring/product_analytics/sankey +- /ja/product_analytics/sankey +- /ja/product_analytics/journeys/sankey +- /ja/product_analytics/journeys/pathways +further_reading: +- link: /product_analytics/journeys + tag: ドキュメント + text: グラフ +- link: /dashboards/widgets/sankey/ + tag: ドキュメント + text: ダッシュボードで Sankey ウィジェットを構築する +title: Pathways ダイアグラム +--- + +## 概要 + +Pathways ダイアグラムを利用すると、アプリケーション全体にわたるすべてのユーザー ジャーニーを可視化し、クリティカル パスを分析できます。 + +{{< img src="/product_analytics/journeys/pathways/ga_pathway_diagrams_page.png" alt="アプリ用のデフォルトの Pathways ダイアグラム" style="width:90%;" >}} + +各ノードは、ユーザーが訪問したビューを表します。各ノードの太さは、そのページを含むユーザー セッション数を表します。訪問者が少ないページほど、ダイアグラム上のノードは細くなります。 + +ユーザーがセッション中に同じページを複数回訪問した場合、そのページは 1 回しかカウントされません。 + +Pathways ダイアグラムでは、アクション イベントはサポートされません。 + +## Pathways ダイアグラムの構築 + +### デフォルトのダイアグラムを表示する + +1. [**Product Analytics > Charts**][1] に移動します。 +2. まだ選択されていない場合は、**Pathways** をクリックします。これにより、アプリケーションで最も人気のあるユーザー ジャーニーを表すデフォルトの視覚化が表示されます。 + +### 指定したビューでダイアグラムを開始または終了する + +左側のメニューを使用してこのダイアグラムをカスタマイズし、次を表示できます: +- ユーザーが特定のビューを訪問した*後*に辿った経路 +- ユーザーが特定のビューを訪問する*前*に辿った経路 + +下の例では、米国のユーザーが `/department/lighting` にアクセスした後に辿る 4 つのステップが表示されています。 + +{{< img src="/product_analytics/journeys/pathways/pana_pathway_page_img2.png" alt="アプリ用のカスタマイズされた Pathways ダイアグラム" style="width:90%;" >}} + +### 指定したフレーズを含むすべてのビューをグラフ化する + +Pathways ダイアグラムは [Datadog ワイルドカード][2] をサポートしており、指定したフレーズを含むすべてのビューのダイアグラムを作成できます。 + +複数の経路にマッチさせるには、単一のビュー名を選択するのではなく、ワイルドカードを入力します。下の例では、`/department/*` に一致するビューにアクセスした後にユーザーが辿る 5 つのステップが表示されます。 + +{{< img src="/product_analytics/journeys/pathways/pana_pathway_page_img3.png" alt="複数の経路にマッチするようにワイルドカードを使用した Pathways ダイアグラム" style="width:90%;" >}} + +## Pathways ダイアグラムの分析 + +ダイアグラム ノードにカーソルを合わせると、そのビューへの訪問を含むセッション数を表示できます。 + +ノードをクリックすると、サンプル [Session Replay][3] の表示や、そのビューを始点とする Pathways ダイアグラムの構築など、分析オプションの一覧が表示されます。 + +{{< img src="/product_analytics/journeys/pathways/pana_pathway_page_img4.png" alt="Pathways ダイアグラム ノードのアクション メニュー" style="width:90%;" >}} + +### ダイアグラムをファネルに変換する + +1. Pathways ダイアグラム ページで、**Build Funnel** ボタンをクリックします。 +2. Pathways ダイアグラムで、ファネルに含めたいビューのノードをクリックします。 +3. **Create Funnel From Selection** をクリックします。 + +{{< img src="/product_analytics/journeys/pathways/pana_pathway_page_img5.png" alt="Pathway からファネルへの変換処理中" style="width:90%;" >}} + +## 参考資料 +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://app.datadoghq.com/product-analytics/user-journey/pathways +[2]: /ja/real_user_monitoring/explorer/search_syntax/#wildcards +[3]: /ja/product_analytics/session_replay/ \ No newline at end of file diff --git a/content/ja/product_analytics/session_replay/heatmaps.md b/content/ja/product_analytics/session_replay/heatmaps.md new file mode 100644 index 00000000000..9ab103af83a --- /dev/null +++ b/content/ja/product_analytics/session_replay/heatmaps.md @@ -0,0 +1,161 @@ +--- +aliases: +- /ja/product_analytics/heatmaps +description: ヒートマップは、ウェブ サイト上でユーザーがどこをクリックしているかを確認できるビジュアライゼーションの一種です。 +further_reading: +- link: /product_analytics/session_replay/browser/ + tag: ドキュメント + text: ブラウザー向け Session Replay +- link: /product_analytics/session_replay/mobile/ + tag: ドキュメント + text: モバイル向け Session Replay +- link: https://www.datadoghq.com/blog/visualize-behavior-datadog-scrollmaps/ + tag: ブログ + text: Datadog Heatmaps の Scroll maps を使用して、ページ上のユーザー インタラクションを可視化する +title: ヒートマップ +--- + +{{< img src="real_user_monitoring/session_replay/heatmaps/heatmaps-landing.png" alt="Click map オプションが表示されたヒートマップ ページの概要。" style="width:100%;">}} + +ヒートマップ (heat map とも呼ばれます) とは、Session Replay データの上にユーザーのインタラクションをオーバーレイ表示して可視化するものです。Product Analytics には 3 種類のヒートマップがあります: + +- **Click maps:** ページでユーザーがどのように操作しているかを理解するために、ユーザーのインタラクション (クリック) を表示します。 +- **Top elements:** 特定のページで最も操作された要素のランキングを、最大上位 10 件まで表示します。 +- **Scroll maps:** ユーザーがページをどこまでスクロールしたかを表示します。ページの平均的なファースト ビュー (average fold) の位置も確認できます。平均的なファースト ビューは、ユーザーがスクロールせずにデバイス上で見られる最下点を指します。 + +ヒートマップを使うと、ユーザー インタラクションに関するデータを確認し、ユーザー エクスペリエンスを改善する方法を特定できます。 + +## 前提条件 + +ヒート マップを使い始めるには: + +1. SDK のバージョンを確認します: + - Click maps の場合、SDK は v4.40.0+ である必要があります。 + - Scroll maps の場合、SDK は v4.50.0+ である必要があります。 +2. [Session Replay][1] を有効化します。 +3. アクション追跡を有効にするため、SDK の初期化時に `trackUserInteractions: true` を設定します (Click maps で必須)。 + +## はじめに + +[**Digital Experience > Product Analytics > Session Replay > Heatmaps**][2] に移動します。アプリケーションとビューを選択します。 + +タイムフレーム セレクターの左側で、表示したいヒートマップの種類を選択できます: Top Elements、Click Map、Scroll Map。 + +{{< img src="product_analytics/heatmaps/pa-heatmaps-page.png" alt="各ビューで異なる種類のヒートマップを選択できます: Top Elements、Click Map、Scroll Map。" style="width:100%;">}} + +次の追加の表示オプションがあります: + +- 表示中のビューを切り替えるには、上部の **View Name** と **Application** セレクターを使用します。 +- デバイス ビューを変更するには、**Device type** セレクターを使用します。 +- アクション名でフィルタするには、**Filter actions by** ドロップダウンを使用します。 +- 特定の地域など、より詳細なフィルターを追加するには、**Add Filter** ボタンをクリックします。 + +{{< img src="product_analytics/heatmaps/pa-heatmaps-annotated.png" alt="ヒートマップ ページでは、アプリケーション、マップ タイプ、デバイス タイプ、アクション名、詳細フィルターなどで異なるビューを表示できます。" style="width:100%;">}} + +## Top Elements + +Top Elements ヒート マップは、特定のビューにおけるクリック アクションを集計し、最も操作された要素とそのインタラクション順位を表示します。マップ上のランキングは、サイドに表示されるアクション名と対応しています。 + +{{< img src="real_user_monitoring/session_replay/heatmaps/heatmaps-top-elements.png" alt="ページでクリックされた要素の上位ランキング。" style="width:100%;">}} + +パネル内の任意のアクション名にホバーすると、マップ上の対応するアクションがハイライト表示されます。 + +## Click maps + +Click map は、セッションからのユーザー クリック アクションを集計し、マップ上にブロブとして可視化することで、特定のビューで最も操作されたアクションを示します。 + +{{< img src="real_user_monitoring/session_replay/heatmaps/heatmaps-clickmaps.png" alt="ウェブ サイト上にオーバーレイされた Click map データ。" style="width:100%;">}} + +左側には、そのページで発生したすべてのアクションが頻度順に一覧表示されます。アクションをクリックすると、次のようにそのインタラクションの詳細を確認できます: + +- ユーザーがそのアクションを実行した回数や、そのページにおける上位アクション全体の分析での位置づけ。 +- そのアクションでフラストレーション シグナルが発生している場合 (例: ボタンへのレイジ クリック)、関連するフラストレーション シグナルも確認できます。 + +このビューから **Start a Funnel** ボタンをクリックして、ユーザーの離脱を特定することもできます。 + +{{< img src="real_user_monitoring/session_replay/heatmaps/heatmaps-clickmap-actions.png" alt="アクション例と、そのアクションから取得できる情報の例。" style="width:50%;">}} + +## Scroll maps + +Scroll maps は、特定のページにおけるスクロール アクティビティの集計を表示します。Scroll maps を使うと、ページの平均的なファースト ビュー (average fold) がどこに位置するかや、どれだけのユーザーが特定の深さまでスクロールしたかを確認できます。Scroll map 上のフローティングの青いバーを、評価したい深さまでドラッグできます。 + +{{< img src="real_user_monitoring/session_replay/heatmaps/heatmaps-scrollmap.png" alt="平均的なファースト ビューとスクロールの深さの分布が表示されたサンプル E コマース ページの Scroll map。" style="width:100%;">}} + +Scroll map の左側のパネルには、ハイ レベル な インサイトとクエリ結果への直接リンクがあります。たとえば、特定のパーセンタイルを越えてスクロールしたビューの一覧へのリンクなどです。インサイト パネルの下には、ページのミニ マップと、詳細な スクロール データを表示する分布 グラフがあり、どこで最も大きな離脱が発生しているかの特定に役立ちます。 + +{{< img src="real_user_monitoring/session_replay/heatmaps/heatmaps-minimap.png" alt="スクロール データのインサイト向けクエリのスクリーン ショット" style="width:50%;">}} + +## スクリーンショット + +スクリーンショットは、特定の時点におけるビューの状態です。スクリーンショットを変更すると、選択したスクリーンショットに応じて異なる結果が表示されます。スクリーンショットを保存して、組織内の全員が同じビューの状態を分析できるようにすることもできます。 + +### スクリーンショットの変更 +ヒートマップのビューで、**Change Screenshot** ボタンをクリックします。チームメイトが以前保存した既存のスクリーンショットから選択するか、Session Replay からスクリーンショットを取得します。 + +Session Replay からスクリーンショットを選択するには: + +1. 希望するヒートマップのスクリーンショットがまだ保存されていない場合は、**Grab from replay** をクリックします。 + + {{< img src="real_user_monitoring/session_replay/heatmaps/heatmaps-change-screenshot-button-1.png" alt="ヒートマップの背景の基になっているスクリーンショットを変更するには Grab from replay ボタンをクリックします。" style="width:100%;">}} + +1. 右側のアクション イベントをクリックして、ヒート マップ用に別の Snapshot を選択します。 + + {{< img src="real_user_monitoring/session_replay/heatmaps/heatmaps-list-all-events-1.png" alt="Session Replay のアクション イベント一覧。" style="width:100%;">}} + +1. セッションに、希望するスクリーンショットにつながるような[アクションが含まれていない](#the-view-that-i-selected-is-not-showing-the-initial-content)場合は、**Choose Another Replay** をクリックしてリプレイの一覧に戻れます。 +1. **Take Screenshot** ボタンをクリックすると、一時停止している時点のスクリーンショットをヒートマップに適用します。 + +### スクリーンショットの保存 + +現在のヒートマップの状態をスクリーンショットとして保存することで、組織内でヒートマップを開く人のデフォルト ビューにすることができます。最近のリプレイから自動選択された現在のスクリーンショットを保存するには、現在のスクリーンショットの **Save** をクリックします。 + +{{< img src="real_user_monitoring/session_replay/heatmaps/heatmaps-save-screenshot-1.png" alt="Save をクリックして、自動選択されたスクリーンショットを適用します。" style="width:100%;">}} + +同じビューに対して複数のスクリーンショットを保存し (例: デフォルト ビュー、ナビゲーション メニューを開く、モーダルを開く)、チームメイトが保存したスクリーンショットに切り替えることができます。 + +現在保存されているスクリーンショットを削除し、最近のリプレイから自動選択されたスクリーンショットに戻すには、現在のスクリーンショットの **Unpin** をクリックします。 + +{{< img src="real_user_monitoring/session_replay/heatmaps/heatmaps-unpin-screenshot-1.png" alt="Unpin をクリックして、現在ピン止めされているスクリーンショットを削除します。" style="width:100%;">}} + +## 次のステップ + +ヒートマップを分析したら、関連データを探索してユーザーの行動の背景にある理由を理解しましょう。[Analytics Explorer][3] に切り替えるか、関連する [Session Replay][1] を視聴して、セッション全体の文脈の中でユーザー アクションを視覚的に確認できます。 + +## トラブル シューティング + +### 特定のビューのヒート マップを見ていますが、想定外のページが表示されます。 + +ヒートマップは Product Analytics のビュー名に基づきます。Product Analytics アプリケーションの構成によっては、多くのページが同じビュー名の下にグループ化されたり、非常に具体的なビュー名を持つようになったりすることがあります。 + +### 選択したビューで初期コンテンツが表示されません。 + +ヒートマップは Session Replay データで生成されます。Datadog は、ページの初期状態によく一致する最近のリプレイを自動的に選択します。場合によっては、ビューの別の状態のヒートマップを見たいこともあるでしょう。ヒートマップのスクリーンショットを切り替えるには、**Change Screenshot**、**Grab from replay** の順にクリックして、リプレイのさまざまな状態を確認し、目的の状態を見つけてください。閲覧中のリプレイに目的のスクリーンショットが含まれていない場合は、**Choose Another Replay** ボタンで同じビューの別のリプレイを選択できます。 + +### ヒート マップの横のアクション リストで、ヒート マップ内に表示されていない要素を示すアイコンが見えます。 + +アイコンのツールチップには element is not visible と表示されます。これは、その要素がページ上の一般的なアクションではあるものの、ヒートマップのスクリーンショットでは表示されていないことを意味します。その要素を確認するには、右上の **Change Screenshot** をクリックし、その要素が存在するスクリーンショットに切り替えてください。 + +{{< img src="real_user_monitoring/session_replay/heatmaps/heatmaps-hidden-elements.png" alt="ヒート マップのアクション リスト内の非表示要素。" style="width:100%;">}} + +### **ヒート マップの作成を試みると、「No Replay Data」状態が表示されます。** + +これは、現在の検索フィルターに一致し、ヒートマップの背景として使用できる Session Replay が Datadog に見つからなかったことを意味します。[Browser SDK][4] でセッションの記録を開始したばかりの場合、Session Replay が閲覧可能になるまで数分かかることがあります。 + +### ヒート マップの作成を試みると、「Not enough data to generate a heatmap」状態が表示されます。 + +これは、現在選択されているリプレイにユーザー アクションを一致させられなかったことを意味します。次のようなさまざまな理由が考えられます: + +- アプリケーションが最新の SDK バージョン (>= 4.20.0) を使用していない。 +- ページが最近大きく変更された。 + +### ページ上のユーザー情報がすべて空である。 + +ユーザー情報は、デフォルトでは収集されません。ヒートマップは、セッション データ内の利用可能なユーザー情報を使用して、行動に関する洞察を表示します。ユーザー情報を収集するには、SDK の実装でユーザー属性を設定してください。 + +## 参考資料 +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ja/product_analytics/session_replay/browser/ +[2]: https://app.datadoghq.com/product-analytics/heatmap +[3]: /ja/product_analytics/analytics_explorer/ +[4]: https://github.com/DataDog/browser-sdk/blob/main/packages/rum/package.json \ No newline at end of file diff --git a/content/ja/real_user_monitoring/guide/devtools-tips.md b/content/ja/real_user_monitoring/guide/devtools-tips.md index ac2d2e92337..e169aeef9b1 100644 --- a/content/ja/real_user_monitoring/guide/devtools-tips.md +++ b/content/ja/real_user_monitoring/guide/devtools-tips.md @@ -1,6 +1,7 @@ --- +description: Datadog Browser SDK の RUM とロギングのインスツルメンテーションの問題をトラブルシューティングするために、ブラウザの開発者ツールを使用する際のデバッグのヒント。 further_reading: -- link: /real_user_monitoring/browser +- link: /real_user_monitoring/application_monitoring/browser tag: ドキュメント text: RUM ブラウザモニタリング - link: /logs/log_collection/javascript @@ -19,7 +20,7 @@ title: ブラウザ開発ツール使用時の注意点 これは、以下に示すように、DevTool コンソールが不正な行番号とファイルを表示することにつながるかもしれません。 {{< img src="real_user_monitoring/guide/devtools-tips/issue_console.png" alt="DevTools コンソールで、console.error ステートメントのファイル番号と行番号が正しくないという問題が発生する。">}} -In the picture above, the `console.error` function is instrumented. Notice that instead of displaying the actual file and line number on which this statement was called, `VM505:1`, the console shows `datadog-rum.js:1`. +上の図では、`console.error` 関数がインスツルメンテーションされています。このステートメントが呼び出された実際のファイルと行番号、`VM505:1` の代わりに、コンソールに `datadog-rum.js:1` と表示されていることに注意してください。 ### ブラウザの無視リストにスクリプトを追加して、正しいファイル番号と行番号を表示させる @@ -47,10 +48,10 @@ In the picture above, the `console.error` function is instrumented. Notice that ネットワークタブで、`-url:intake-datadoghq.com` という形式のフィルターを追加します (パターンを更新して、[データセンターのインテーク][1]の url、または[プロキシ][2]の url と一致するようにします)。 -## その他の参考資料 +## 参考資料 {{< partial name="whats-next/whats-next.html" >}} [1]: /ja/getting_started/site [2]: /ja/real_user_monitoring/guide/proxy-rum-data -[3]: /ja/real_user_monitoring/browser/setup/#choose-the-right-installation-method \ No newline at end of file +[3]: /ja/real_user_monitoring/application_monitoring/browser/setup/#choose-the-right-installation-method \ No newline at end of file diff --git a/content/ja/synthetics/api_tests/udp_tests.md b/content/ja/synthetics/api_tests/udp_tests.md index e19abc8cb68..6e0c1503b85 100644 --- a/content/ja/synthetics/api_tests/udp_tests.md +++ b/content/ja/synthetics/api_tests/udp_tests.md @@ -25,7 +25,7 @@ title: UDP テスト --- ## 概要 -UDP テストでは、指定したホストのポートに低レベルの UDP 接続が確立されていることを監視し、UDP ポートに存在するあらゆるサービスの可用性を確保することが可能です。応答時間データを内蔵しているため、ネットワークアプリケーションのパフォーマンスを追跡し、予期しない速度低下が発生した場合に警告を受けることができます。 +UDP テストでは、指定したホストのポートで低レベルの UDP 接続を確立できるかどうかを監視し、UDP ポート上で稼働するあらゆるサービスの可用性を確保します。応答時間データが組み込まれているため、ネットワーク アプリケーションのパフォーマンスを追跡し、予期しない遅延が発生した場合にアラートを受け取ることができます。 通常の UDP トラフィックでは、確認応答を求めることなく、送信元から宛先へ情報を送信します。UDP サービスを監視するために、Datadog では UDP ポートをリッスンし、応答を返すプロセスを受信側のホストに置くことを推奨しています。このプロセスをセットアップした後、UDP テストを作成し、期待される応答についてアサーションを設定することができます。 diff --git a/content/ja/synthetics/browser_tests/test_steps.md b/content/ja/synthetics/browser_tests/test_steps.md new file mode 100644 index 00000000000..317193563da --- /dev/null +++ b/content/ja/synthetics/browser_tests/test_steps.md @@ -0,0 +1,520 @@ +--- +aliases: +- /ja/synthetics/browser_tests/actions +description: ブラウザテストの記録の自動記録と手動でのステップ設定方法について説明します。 +further_reading: +- link: /synthetics/browser_tests/advanced_options/ + tag: ドキュメント + text: ブラウザテストの高度なオプションについて +- link: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/synthetics_global_variable + tag: 外部サイト + text: Terraform による Synthetic グローバル変数の作成と管理 +title: ブラウザテストのステップ +--- + +## 概要 + +ステップは、ブラウザテストで記録し、編集または構築することができる一連のアクションです。ブラウザテストで実行するステップを定義するには、Datadog のテストレコーダ拡張機能で直接記録するか、手動で追加します。各ステップには、構成可能な[詳細オプション][1]のセットが含まれています。 + +各ステップのデフォルトのタイムアウトは 60 秒です。このデフォルトのタイムアウトは、専用の[タイムアウトオプション][2]を使用してオーバーライドできます。 + +## 自動記録されたステップ + +**Start Recording** をクリックすると、[Datadog ブラウザテストレコーダー拡張機能][3]が自動的に Web サイト上の操作手順を検出し、記録します。 + +### クリック + +ページ上の要素とインタラクトすることで、ステップを記録します。 + +{{< img src="synthetics/browser_tests/click_step.mp4" alt="クリックステップタイプのクリックタイプドロップダウンメニュー" video="true" width="60%" >}} + +ステップをクリックし、実行時にブラウザテストを実行させたいクリックタイプを選択します。 + +* 左クリックに対応するプライマリクリック +* ダブルクリック +* 右クリックに対応するコンテキストクリック + +### テキストを入力する + +Datadog は、`select` ドロップダウンメニューからオプションを選択するなど、アプリケーション上で実行したステップを記録し、その要約がステップとして表示されます。 + +{{< img src="synthetics/browser_tests/type_text.mp4" alt="ブラウザテストのテキスト入力ステップ" video="true" width="95%" >}} + +### オプションを選択する + +Datadog は、`select` ドロップダウンメニューからオプションを選択するなど、アプリケーション上で実行したステップを記録し、その要約が左隅にステップとして表示されます。 + +{{< img src="synthetics/browser_tests/select_options.png" alt="オプション選択ステップ" style="width:70%;" >}} + +### ファイルをアップロードする + +**Upload** ステップを記録するには、次のいずれかを行います。 + +* ブラウザからデスクトップを開く +* ファイルを記録する iframe にドラッグアンドドロップする + +Datadog は、アップロードなどアプリケーション上で実行したステップを記録し、その要約が左隅にステップとして表示されます。アップロードできるファイルは 10 個までで、それぞれ 5MB までの制限があります。 + +{{< img src="synthetics/browser_tests/upload_file_step.png" alt="ファイルのアップロードステップを作成する" style="width:70%;" >}} + +## 手動で追加したステップ + +ブラウザテストの記録の左隅で、手動でステップを追加したり、アレンジしたりすることができます。 + +### アサーション + +アサーションによって、シミュレーションされたユーザージャーニーのどの時点でも、ブラウザテストが期待通りの状態であることを検証することができます。 + +テストが期待通りの状態で終了することを確認するために、ブラウザテストは**アサーション**で終了させる必要があります。 + +{{< img src="synthetics/browser_tests/browser_test_assertions_2.png" alt="ブラウザテストステップでのアサーションのオプション" style="width:70%;" >}} + +いくつかのアサーションは、アクティブなページ、つまりユーザーがページ要素上で**クリック**や**アサーション**など、最後に操作したページを検証します。 + +ステップを作成するには、アサーションタイプを選択します。 + +{{< tabs >}} +{{% tab "アクティブページで要素をテストする" %}} + +#### 要素のコンテンツをテストする + +このアサーションステップを作成すると、ブラウザテストでページ要素を選択し、特定の値が含まれているかどうかを確認することができます。 + +#### 要素の属性をテストする + +このアサーションステップを作成すると、ブラウザテストでページ要素を選択し、その属性の 1 つが期待される内容と一致するかどうかを確認することができます。 + +#### ある要素が存在するかどうかをテストする + +このアサーションステップを作成すると、ブラウザテストで特定の `span`、`div`、`h`、`a` などのページ要素を選択し、それがページ上に存在することを確認できます。 + +ブラウザテストが正しい要素をターゲットにするように、ドロップダウンメニューから `CSS` または `XPath 1.0` を選択し、セレクタを追加してユーザーロケータを設定します。**Test** をクリックします。 + +#### チェックボックスやラジオボタンの状態をテストする + +このアサーションステップを作成することで、ブラウザテストでページ要素を選択し、アサーションの状態 (未チェックまたはチェック済み) を検証することができます。 + +{{< img src="synthetics/browser_tests/checkbox_state_assertion.png" alt="ブラウザテストステップでのアサーションのオプション" style="width:60%;" >}} + +{{% /tab %}} +{{% tab "アクティブページコンテンツのテスト" %}} + +#### テキストがアクティブページに存在しないことをテストする + +このアサーションステップを作成すると、`Value` フィールドに指定したテキストが、記録中の現在のページに**存在しない**ことをブラウザテストで確認することができます。 + +#### テキストがアクティブページに存在することをテストする + +このアサーションステップを作成すると、`Value` フィールドに指定したテキストが、記録中の現在のページに存在することをブラウザテストで確認することができます。 + +#### アクティブページの URL のコンテンツをテストする + +このアサーションステップを作成すると、ブラウザテストで、最後に操作されたページの URL に指定した値が含まれているかどうかを検証することができます。 + +`string`、`number`、`regex` などの URL 内の値をテストすることができます。 + +{{% /tab %}} + +{{% tab "特殊アサーション" %}} + +#### メールが受信されたことをテストする + +このアサーションステップを作成すると、ブラウザテストでアプリケーションのメールメカニズムが動作していることを確認し、`string`、`number`、`regex` などの指定した値がメールの件名や本文に存在することを検証することができます。 + +詳しくは、[ブラウザテストによるメール検証][1]をご覧ください。 + +#### カスタム JavaScript で UI をテストする + +このアサーションステップを作成すると、アクティブなページで JavaScript コードを使用してカスタムアサーションをテストすることができます。JavaScript アサーションは、同期と非同期の両方のコードをサポートします。ブラウザテストはページにスクリプトを追加することで外部 JavaScript を読み込むので、 ウェブサイトが外部 JavaScript を受け入れる場合にのみ機能します。 + +JavaScript アサーション関数には以下のパラメーターが含まれており、return ステートメントが必要です。 + +* `return` (必須) ステートメントは、テストステップが成功するためにアサーションが満たす必要がある条件を反映します。任意のタイプを返すことができますが、値はブール値として自動的にキャストされます。偽の値が返された場合、テストステップは失敗します。 + +* `vars` (オプション): ブラウザテストの[変数][2]を含む文字列。JavaScript スニペットでブラウザテスト変数を参照するには、`vars.` を使用します。たとえば、ブラウザテストに `USERNAME` 変数が含まれている場合は、`vars.USERNAME` を使用して JavaScript スニペットでそれを呼び出します。 + +* `element` (オプション): ページ上の要素のロケーター。これを設定するには、**Select** および **Update** ターゲット要素ボタンを使用します。選択された要素は、Datadog のブラウザテストの複数配置アルゴリズムを自動的に利用します。 + +{{< img src="synthetics/browser_tests/assertion_java.mp4" alt="ブラウザテストの JavaScript アサーション" video="true" width="100%" >}} + +JavaScript アサーションはアクティブページのコンテキストで実行されるため、これらのステップはアクティブページで定義されたすべてのオブジェクト (ライブラリ、組み込み、グローバル変数など) にアクセスできます。外部ライブラリをロードするには、promise を使用します。 + +例: + +```javascript +const script = document.createElement('script'); +script.type = 'text/javascript'; +script.src = "https://code.jquery.com/jquery-3.5.1.slim.min.js"; +const promise = new Promise((r) => script.onload = r) +document.head.appendChild(script) + +await promise + +// スクリプトが読み込まれました + +return jQuery().jquery.startsWith('3.5.1') +``` + +#### ダウンロードされたファイルのテスト + +このアサーションステップを作成すると、ブラウザテストで前のステップでダウンロードしたファイルを検証することができます。ファイルが正しくダウンロードされたことを確認し、ファイル名、サイズ、および MD5 値をアサートすることができます。 + +ダウンロードのテスト方法については、[ファイルのアップロードとダウンロードのテスト][3]を参照してください。 + +[1]: /ja/synthetics/guide/email-validation +[2]: /ja/synthetics/browser_tests/test_steps#use-variables +[3]: /ja/synthetics/guide/testing-file-upload-and-download/#testing-a-file-download + +#### HTTP リクエスト数のテスト + +このアサーションステップを作成して、特定の URL パターンへの HTTP リクエスト数をテストします。期待されるリクエスト数と、テスト対象のターゲット URL の正規表現を入力してください。 + +{{< img src="synthetics/browser_tests/number_and_target_2.png" alt="リクエスト数とターゲットをテストするオプションと、リクエストのドロップダウンが表示されている" style="width:60%;" >}} + +{{% /tab %}} +{{< /tabs >}} + +
+ +### インタラクション + +ブラウザのアサーションで記録されたステップに加えて、**Interaction** をクリックして手動でステップを作成することもできます。その後、アクションタイプを選んでインタラクションを追加します。 + +{{< img src="mobile_app_testing/test_steps/mobile_app_interaction_2.png" alt="インタラクションステップを追加するためのアクションタイプを選択" style="width:60%;" >}} + +#### ページを更新 + +このナビゲーションステップを作成すると、ブラウザテストで記録の現在のページを更新させることができます。 + +#### メールリンクをクリック + +[メール変数][4]を作成したら、このナビゲーションステップを追加し、ブラウザテストが固有の Synthetic メール受信ボックスにアクセスできるようにします。 + +ブラウザテストでクリックさせたいメールやリンクを選択します。このステップで対応するページが表示され、その特定のページから残りの行程に進むことができます。 + +#### リンクへ移動する + +このナビゲーションステップを作成すると、ブラウザテストで特定のページに移動することができます。**Enter link URL** の欄には、URL の前に `http` または `https` を付ける必要があります。 + +#### キーの押下 + +キーストロークを入力するユーザーをシミュレートするために、**Press Key** ステップを追加します。[Datadog ブラウザテストレコーダー拡張機能][3]は、以下のキーを記録することができます。 + +* Enter +* 矢印（上、下、右、左） +* Tab（フォーム外） +* Escape +* Backspace + +自動的に記録されないキーを押すには、**Value** フィールドで押す必要のある値を指定します。 + +入力された値に追加する修飾子として、`Alt`、`Control`、`Meta`、`Shift` を選択します。 + +{{< img src="synthetics/browser_tests/browser_test_press_key.png" alt="ブラウザテスト記録の Press Key ステップ" style="width:50%;" >}} + +#### 要素にカーソルを合わせる + +このステップでは、ホバーリング機構ではなく、専用のクリックを使用し、記録中にユーザーが要素にホバーリングするたびに別のステップが生成されることを回避しています。 + +**Hover** を選択し、要素をクリックするとステップが追加されます。 + +#### スクロール + +ブラウザテストでは、操作が必要な要素まで自動的にスクロールします。ほとんどの場合、手動でスクロールステップを追加する必要はありません。スクロールステップを使用するのは、無限スクロールのような追加の操作を発生させる必要がある場合です。 + +ブラウザテストで縦方向および横方向にスクロールさせたいピクセル数を指定します。 + +{{< img src="synthetics/browser_tests/browser_test_scroll_step.png" alt="ブラウザテスト記録 Test Scroll Step の Scroll ステップ" style="width:50%;" >}} + +デフォルトでは、**Scroll** ステップはページ全体をスクロールします。特定の要素 (例えば、特定の `
`) でスクロールする必要がある場合、**Target Element** をクリックして、ブラウザテストでスクロールさせたい要素を選択します。 + +#### 待機 + +デフォルトでは、ブラウザテストはページが完全に読み込まれるのを待ってから、ステップまたは次のステップを実行し、60 秒のタイムアウトが設定されています。 + +ページやページ要素の読み込みに 60 秒以上かかることがわかっている場合、ステップの[高度なオプション][2]でタイムアウトをカスタマイズするか、最大値 300 秒のハードコードされた待機ステップを追加することができます。 + +{{< img src="synthetics/browser_tests/browser_test_wait_step.png" alt="ブラウザテスト記録の Wait ステップ" style="width:50%;" >}} + +この追加時間は、ブラウザテストの記録の**すべての実行**に系統的に追加されます。 + +#### HTTP テストを実行 + +ブラウザテストの一部として、HTTP リクエストを実行し、[アサーション](#add-assertions)を追加し、[変数を抽出](#extract-a-variable-from-the-response)することができます。 + +{{< img src="synthetics/browser_tests/http_request_3.png" alt="HTTP Request ステップ" style="width:70%;" >}} + +HTTP リクエストを定義するには、 + +1. テストしたい URL を入力します。 +2. オプションで、**Advanced Options** を指定します。 + + {{< tabs >}} + + {{% tab "リクエストオプション" %}} + + * **Follow redirects**: このオプションを選択すると、HTTP テストが最大 10 回のリダイレクトを追従します。 + * **Ignore server certificate error**: SSL 証明書の検証でエラーが発生しても、HTTP テストを継続する場合にこのオプションを選択します。 + * **Request headers**: HTTP リクエストに追加するヘッダーを定義します。デフォルトのヘッダー (たとえば、`user-agent` ヘッダー) をオーバーライドすることもできます。 + * **Cookies**: HTTP リクエストに追加するクッキーを定義します。`=; =` の形式を使用して複数のクッキーを設定します。 + + {{% /tab %}} + + {{% tab "認証" %}} + + * **Client certificate**: クライアント証明書と関連する秘密キーをアップロードして、mTLS を介して認証します。 + * **HTTP Basic Auth**: HTTP 基本認証資格情報を追加します。 + * **Digest Auth**: ダイジェスト認証の資格情報を追加します。 + * **AWS Signature**: AWS Access Key ID と Secret Access Key を追加します。 + * **NTLM**: NTLM 認証の資格情報を追加します。NTLMv2 と NTLMv1 の両方に対応しています。 + * **OAuth 2.0**: Grant Type (Client credentials または Resource owner password) を選択します。 + + {{% /tab %}} + + {{% tab "クエリパラメーター" %}} + + * **Encode parameters**: エンコードが必要なクエリパラメーターの名前と値を追加します。 + + {{% /tab %}} + + {{% tab "リクエスト本文" %}} + + * **Body type**: HTTP リクエストのボディタイプを選択します (`text/plain`, `application/json`, `text/xml`, `text/html`, `application/x-www-form-urlencoded`, `application/octet-stream`, `multipart/form-data`, `GraphQL`, または `None`)。 + * **Request body**: HTTP リクエストボディの内容を追加します。ブラウザ HTTP ステップでのファイルアップロードではボディサイズは 3MB に制限され、リクエストボディの最大サイズは 50KB です。 + + {{% /tab %}} + + {{% tab "プロキシ" %}} + + * **Proxy URL**: HTTP リクエストが通過する必要があるプロキシの URL (`http://:@:`) を指定します。 + * **Proxy Header**: プロキシへの HTTP リクエストに含めるヘッダーを追加します。 + + {{% /tab %}} + + {{% tab "Privacy" %}} + + * **Do not save response body**: レスポンスの本文が実行時に保存されないようにするには、このオプションを選択します。これは、テスト結果に機密データが表示されないようにするために役立ちますが、障害のトラブルシューティングが困難になる可能性があります。セキュリティに関する完全な推奨事項については、[Synthetic モニタリングデータセキュリティ][1]を参照してください。 + +[1]: /ja/data_security/synthetics + {{% /tab %}} + + {{< /tabs >}} +
+ +3. **Send** をクリックしてリクエストを送信すると、レスポンスのプレビューが表示されます。 + +{{< img src="mobile_app_testing/test_steps/http_mobile_request.png" alt="HTTP リクエストを実行" style="width:80%;" >}} + +##### アサーションの追加 + +アサーションはテスト結果の期待値を定義します。**Send** をクリックした後、`status code`、`response time`、`header` の `content-type` に対する基本的なアサーションがテストレスポンスに基づいて追加されます。ブラウザテストの HTTP ステップではアサーションは任意です。 + +| 型 | 演算子 | 値の型 | +|-----------------|------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------| +| `body` | `contains`、`does not contain`、`is`、`is not`、
`matches`、`does not match`、
[`jsonpath`][11]、[`xpath`][12] | _String_
_[Regex][13]_
_String_, _[Regex][13]_ | +| `header` | `contains`、`does not contain`、`is`、`is not`、
`matches`、`does not match` | _文字列_
_[正規表現][13]_ | +| `response time` | `is less than` | 整数 (ms) | +| `status code` | `is`、`is not` | 整数 | + +HTTP リクエストでは、`br`、`deflate`、`gzip`、`identity` の `content-encoding` ヘッダーを使用して本文を解凍することが可能です。 + +- テストがレスポンス本文にアサーションを含まない場合、本文のペイロードはドロップし、Synthetics Worker で設定されたタイムアウト制限内でリクエストに関連するレスポンスタイムを返します。 + +- テストがレスポンス本文に対するアサーションを含み、タイムアウトの制限に達した場合、`Assertions on the body/response cannot be run beyond this limit` というエラーが表示されます。 + +**New Assertion** をクリックするか、応答プレビューを直接クリックすることで、ステップごとに最大 20 個のアサーションを作成できます。 + +{{< img src="synthetics/browser_tests/assertions.png" alt="ブラウザテストが成功または失敗するためのアサーションを定義する" style="width:80%;" >}} + +##### 応答から変数を抽出する + +必要に応じて、HTTP リクエストのレスポンスヘッダーやボディを解析し、その結果を変数として抽出できます。変数の値は HTTP リクエストステップが実行されるたびに更新され、以降の[ステップ](#use-variables)で使用できます。 + +変数の解析を開始するには、**Extract a variable from response content** をクリックし、変数を定義します。 + +1. **Variable Name** を入力します。変数名に使用できるのは大文字、数字、アンダースコアのみです。また、3 文字以上にする必要があります。 +2. 変数をレスポンスのヘッダーから抽出するか、本文から抽出するか決定します。 + + * レスポンスヘッダーから値を抽出する場合は、HTTP リクエストのレスポンスヘッダー全体を変数として使用するか、[`regex`][13] で解析します。 + * レスポンスボディから値を抽出する場合は、HTTP リクエストの完全なレスポンスボディをそのまま変数の値として利用するか、[`regex`][13]、[`JSONPath`][11]、[`XPath`][12] で解析します。 + +{{< img src="synthetics/browser_tests/extracted_variable.png" alt="応答から抽出された変数" style="width:80%;" >}} + +### 特別なアクション + +[Datadog ブラウザテストレコーダー拡張機能][3]を使用すると、ユーザージャーニーに関連するほとんどのステップを記録、監視することができます。しかし、この拡張機能は、**Hover**、*Press Key**、*Scroll**、*Wait** などの一部のステップを自動的に記録しません。 + +**Special Actions** をクリックし、アクションタイプを選択して、このアサーションステップを手動で作成します。 + +### 変数 + +**Variables** をクリックし、ドロップダウンメニューから変数作成の種類を選択します。 + +{{< img src="synthetics/browser_tests/variables.png" alt="ブラウザテスト変数" style="width:60%;" >}} + +ステップ内で変数を使用する方法については、[変数を使用する](#use-variables)を参照してください。 + +#### パターン + +使用可能なビルトインは以下の通りです。 + +`{{ numeric(n) }}` +: `n` 桁の数字列を生成します。 + +`{{ alphabetic(n) }}` +: `n` 文字のアルファベット文字列を生成します。 + +`{{ alphanumeric(n) }}` +: `n` 文字の英数字文字列を生成します。 + +`{{ date(n unit, format) }}` +: テストが + または - `n` 単位で開始された UTC 日付に対応する値を使用して、Datadog の許容される形式のいずれかで日付を生成します。 + +`{{ timestamp(n, unit) }}` +: テストが + または - `n` 単位で開始された UTC タイムスタンプに対応する値を使用して、Datadog の許容される単位のいずれかでタイムスタンプを生成します。 + +`{{ uuid }}` +: バージョン 4 の UUID (Universally unique identifier) を生成します。 + +テスト結果のローカル変数値を難読化するには、**Hide and obfuscate variable value** を選択します。変数文字列を定義したら、**Add Variable** をクリックします。 + +#### 要素 + +`span` や `div` などのコンテンツから、要素のテキストを抽出して変数を作成します。 + +#### メール本文 + +[`regex`][13] または [`Xpath`][12] のいずれかの方法で、メール本文から変数を作成します。 + +* [`Regex`][13] はメールのプレーンテキスト本文から最初に一致するパターン (例えば `/*./`) を検索して返します。パターンが見つからない場合は、HTML 本文を検索します。 + +* [`Xpath`][12] はメールの本文に HTML が含まれている場合にのみ適用されます。これは対応する場所 (例えば `$`) の内容を返します。 + +#### JavaScript + +JavaScript のステップは、同期と非同期の両方のコードをサポートしています。ブラウザテストは、ページにスクリプトを追加することで外部の JavaScript を読み込むため、Web サイトが外部の JavaScript を受け入れる場合にのみ機能します。 + +JavaScript 関数には以下のパラメーターが付属しており、return ステートメントが必要です。 + +* `return` (必須) ステートメントは、JavaScript の変数に関連づけたい値を返します。このステートメントは任意のタイプを返すことができますが、値は自動的に文字列にキャストされます。 + +* `vars` (オプション): コード内で使用することができるブラウザテストの[変数](#use-variables)を含む文字列。JavaScript スニペットでブラウザテスト変数を参照するには、`vars.` を使用します。たとえば、ブラウザテストですでに `PRICE` 変数を使用している場合は、`vars.PRICE` を使用して JavaScript スニペットでそれを呼び出します。 + +* `element` (オプション): ページ上の要素のロケーター。これを設定するには、**Select** および **Update** ターゲット要素ボタンを使用します。選択された要素は、Datadog のブラウザテストの複数配置アルゴリズムを自動的に利用します。 + +{{< img src="synthetics/browser_tests/custom_java_script.mp4" alt="ブラウザテストの JavaScript 変数" video="true" width="100%" >}} + +JavaScript アサーションはアクティブページのコンテキストで実行されるため、これらのステップはアクティブページで定義されたすべてのオブジェクト (ライブラリ、組み込み、グローバル変数など) にアクセスできます。外部ライブラリをロードするには、promise を使用します。 + +例: + +```javascript +const script = document.createElement('script'); +script.type = 'text/javascript'; +script.src = "https://code.jquery.com/jquery-3.5.1.slim.min.js"; +const promise = new Promise((r) => script.onload = r) +document.head.appendChild(script) + +await promise + +// スクリプトが読み込まれました + +return jQuery().jquery.startsWith('3.5.1') +``` + +#### グローバル変数 + +[Synthetic Monitoring Settings][5] で定義されたグローバル変数を選択します。 + +#### グローバル変数 - MFA + +[Synthetic Monitoring Settings][5] で定義された MFA グローバル変数を選択します。 + +このタイプのグローバル変数は、時間ベースのワンタイムパスワード (TOTP) シークレットキーを格納し、MFA モジュールと MFA で保護されたワークフローをテストすることができます。詳細については、[ブラウザテストにおける多要素認証 (MFA) のための TOTP][6] を参照してください。 + +#### Email + +Datadog Synthetics のメールアドレスを作成し、テストステップで使用して、[メールが正しく送信されたかどうかをアサート][7]したり、たとえば確認リンクをクリックするために、[メール内のリンクにナビゲート][8]することが可能です。 + +テスト実行のたびに一意のメールボックスが生成され、テスト実行間の競合を回避することができます。 + +### サブテスト + +ブラウザテストを他のブラウザテストの中で実行することで、既存のワークフローを最大 2 階層まで入れ子にして再利用することが可能です。 + +既存のブラウザテストをサブテストとして使用するには、**Add New Subtest** をクリックし、**From Existing Test** タブのドロップダウンメニューからブラウザテストを選択し、**Add Subtest** をクリックします。 + +現在のブラウザテストのステップをサブテストに変換するには、**Extract From Steps** タブをクリックし、抽出したい記録されたステップを選択し、**Convert to Subtest** をクリックしてください。デフォルトでは、サブテストは親テストの前のステップと順番に実行されます。 + +{{< img src="synthetics/browser_tests/advanced_options/subtest.png" alt="ブラウザテストでサブテストを追加する" style="width:60%;" >}} + +サブテストにある変数を親テストでオーバーライドするには、親テストレベルで作成された変数が、サブテストに存在する変数と同じ名前であることを確認してください。変数は、常に最初に代入された値を使用します。 + +サブテストの高度なオプションについては、[ブラウザテストステップの高度なオプション][9]を参照してください。 + +サブテストを独立して実行することに意味がない場合は、一時停止することができます。このテストは、親テストの一部として呼び出され続け、 個別に実行されることはありません。詳しくは、[ブラウザのテストジャーニーをテストスイート全体で再利用する][10]を参照ください。 + +## ステップ順序の管理 + +個々のステップをドラッグアンドドロップして新しいステップを手動で並べ替える代わりに、記録の特定の段階でテストステップにカーソルをセットし、追加のステップを挿入することができます。 + +1. 記録したテストステップにカーソルを合わせ、**Set Cursor** アイコンをクリックします。テストステップの上に青い線が表示されます。 +2. [テストステップ](#automatically-recorded-steps)を追加記録するか、[ステップを手動で](#manually-added-steps)追加します。 +3. テストステップの上にステップを追加し終えたら、**Clear Cursor** をクリックして終了してください。 + +{{< img src="synthetics/browser_tests/recording_cursor_step.mp4" alt="テストステップにカーソルを合わせると、このステップの前にステップが追加される" video="true" width="100%" >}} + +## 変数を使用する + +手動で追加したステップで利用可能なすべての変数を表示するには、入力フィールドに `{{` と入力します。 + +自動で記録されたステップで変数を使うには、**Inject this variable** アイコンをクリックし、記録中に変数の値を入力します。 + +{{< img src="synthetics/browser_tests/variable_input.mp4" alt="テストステップをクリックすると、レコーダーページに値が挿入される" video="true" width="100%" >}} + +ブラウザのテストステップで変数に異なる値が割り当てられる場合 (サブテストなど)、変数は最初に割り当てられた値を一貫して使用します。 + +HTTP リクエストや JavaScript ステップの変数など、実行時にのみ計算される変数もあります。例えば、`{{ }}` を使用する `Type text` ステップがあるとします。テスト実行時には、`{{ }}` が、変数に関連付けられた値に一貫して置き換えられます。これらの変数を使ったステップを記録するには、実際の変数の値でステップを記録し、テストを保存する前にステップの定義で実際の値を `{{ }}` に置き換えてください。 + +### 複数の変数を使用 + +ブラウザテストの記録ステップに複数の変数を追加できます。 + +ブラウザテストの記録で、**+ Add Variable** ボタンをクリックして、テストに 1 つ以上の変数を追加します。 + +{{< img src="synthetics/browser_tests/extract_multiple_variables.png" alt="グローバル変数からローカル変数を定義する" width="90%" >}} + +ブラウザテストのレコーダーで、ステップ記録を追加し、**Extract variables from the response(optional)** をクリックして、ブラウザテストで変数を抽出して使用します。 + +{{< img src="synthetics/browser_tests/edit_test_extract_multiple_variables.png" alt="ブラウザ記録中にフィールドにローカル変数を挿入する" width="90%" >}} + +## 記録を編集する + +ブラウザの記録を保存後に編集するには + +- [Synthetic Monitoring > Tests][14] に移動します。 +- 以前に保存したブラウザテストをクリックします。 +- 右上隅にある歯車アイコンをクリックし、"edit recording" をクリックします。 +- 削除または再生する複数のステップまたは単一のステップを選択し、**Save & Quit** をクリックします。 + +{{< img src="synthetics/browser_tests/edit_a_recording.png" alt="ブラウザ記録を編集し、マルチセレクト機能を使用する"="70%" >}} + + +## 参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ja/synthetics/browser_tests/advanced_options/ +[2]: /ja/synthetics/browser_tests/advanced_options/#timeout +[3]: https://chrome.google.com/webstore/detail/datadog-test-recorder/kkbncfpddhdmkfmalecgnphegacgejoa +[4]: /ja/synthetics/guide/email-validation/#create-an-email-variable +[5]: /ja/synthetics/settings/ +[6]: /ja/synthetics/guide/browser-tests-totp +[7]: /ja/synthetics/guide/email-validation/#confirm-the-email-was-sent +[8]: /ja/synthetics/guide/email-validation/#navigate-through-links-in-an-email +[9]: /ja/synthetics/browser_tests/advanced_options/#subtests +[10]: /ja/synthetics/guide/reusing-browser-test-journeys +[11]: https://restfulapi.net/json-jsonpath/ +[12]: https://www.w3schools.com/xml/xpath_syntax.asp +[13]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions +[14]: https://app.datadoghq.com/synthetics/tests \ No newline at end of file diff --git a/content/ja/tracing/guide/trace-php-cli-scripts.md b/content/ja/tracing/guide/trace-php-cli-scripts.md index 94cf635e1d7..27f0b1194f9 100644 --- a/content/ja/tracing/guide/trace-php-cli-scripts.md +++ b/content/ja/tracing/guide/trace-php-cli-scripts.md @@ -13,10 +13,7 @@ title: PHP CLI スクリプトのトレース 短時間実行のスクリプトは、通常、数秒から数分程度実行されます。スクリプトが実行されるたびに 1 つのトレースを受け取ります。 -デフォルトでは、コマンドラインから実行される PHP スクリプトのトレースは無効です。`DD_TRACE_CLI_ENABLED` を `1` に設定することで有効になります。 - ``` -$ export DD_TRACE_CLI_ENABLED=1 # オプションとして、エージェントのホストとポートが localhost と 8126 と異なる場合はそれぞれ設定します $ export DD_AGENT_HOST=agent $ export DD_TRACE_AGENT_PORT=8126 @@ -46,13 +43,9 @@ $ php script.php 長時間実行されるスクリプトは、数時間から数日にわたって実行されます。通常、このようなスクリプトは、新しい受信メッセージの処理やデータベースのテーブルに追加された新しい行の処理など、特定のタスクを繰り返し実行します。これにより、メッセージの処理など「作業単位」ごとに 1 つのトレースが生成されることが期待されます。 -デフォルトでは、コマンドラインから実行される PHP スクリプトのトレースは無効です。`DD_TRACE_CLI_ENABLED` を `1` に設定することで有効になります。 - ``` -$ export DD_TRACE_CLI_ENABLED=1 # この設定では、メソッドの実行が終了すると同時に、各「作業単位」のトレースが送信されます。 $ export DD_TRACE_GENERATE_ROOT_SPAN=0 -$ export DD_TRACE_AUTO_FLUSH_ENABLED=1 # オプションとしてサービス名や env などを設定します... $ export DD_SERVICE=my_service # オプションとして、エージェントのホストとポートが localhost と 8126 と異なる場合は、それぞれ設定します diff --git a/content/ja/tracing/trace_explorer/query_syntax.md b/content/ja/tracing/trace_explorer/query_syntax.md index 1949cb85712..e5452b006ef 100644 --- a/content/ja/tracing/trace_explorer/query_syntax.md +++ b/content/ja/tracing/trace_explorer/query_syntax.md @@ -19,6 +19,9 @@ aliases: - /ja/tracing/trace_explorer/trace_groups description: タグを使用したすべてのトレースのグローバル検索 further_reading: +- link: /getting_started/search/ + tag: ドキュメント + text: Datadog で検索を始める - link: /tracing/trace_collection/ tag: ドキュメント text: アプリケーションで APM トレースをセットアップする方法 @@ -27,7 +30,7 @@ further_reading: text: Datadog トレースの読み方を理解する - link: /tracing/software_catalog/ tag: ドキュメント - text: Datadog に報告するサービスの発見とカタログ化 + text: Datadog に送信しているサービスを検出してカタログ化する - link: /tracing/services/service_page/ tag: ドキュメント text: Datadog のサービスについて @@ -209,35 +212,35 @@ Span テーブルは、選択されたコンテキスト ([検索バー](#search {{< img src="tracing/app_analytics/search/trace_list_with_column.png" alt="列を含むトレースリスト" style="width:80%;">}} -### Trace Groups +### トレース グループ -Group the query by any span tag or attribute to observe request counts, error rates and latency distributions in the list view. You can select up to four dimensions in the **Group by** clause. +任意のスパン タグまたは属性でクエリをグループ化し、リクエスト数、エラー レート、レイテンシー分布をリスト ビューで確認できます。**Group by** 句では、最大 4 つのディメンションを選択できます。 -{{< img src="/tracing/trace_explorer/trace_groups/group_by_clause.png" alt="Group by clause" style="width:90%;" >}} +{{< img src="/tracing/trace_explorer/trace_groups/group_by_clause.png" alt="Group by 句" style="width:90%;" >}} -#### Advanced 'Group By' queries +#### 高度な 'Group By' クエリ -After selecting a dimension to group by, you can specify where to get the dimension's values from using the **from** dropdown: -- **Span**: Group by the dimension of the queried span (default). For example, `a`. -- **Parent of span**: Group by the specified dimension from the parent span of spans matching the query. For example, to visualize how an API endpoint performs based on the service calling it, group by `service` from `parent(a)`. -- **Root span**: Group by the specified dimension from the root span of the trace. For example, to analyze backend request patterns based on the frontend pages requests originate from, group by `@view.name` from `root`. +グループ化するディメンションを選択した後、**from** ドロップダウンを使用して、ディメンションの値の取得先を指定できます: +- **スパン**: クエリ対象のスパンのディメンションでグループ化します (デフォルト)。例: `a`。 +- **スパンの親**: クエリに一致するスパンの親スパンから、指定したディメンションの値を取得してグループ化します。たとえば、API エンドポイントのパフォーマンスを呼び出し元のサービスを基準に視覚化するには、`parent(a)` から `service` でグループ化します。 +- **ルート スパン**: トレースのルート スパンから、指定したディメンションでグループ化します。たとえば、リクエストの発生元であるフロントエンド ページを基準にバックエンドのリクエスト パターンを分析するには、`root` から `@view.name` でグループ化します。 -{{< img src="/tracing/trace_explorer/trace_groups/group_by_root.png" alt="Group by from root" style="width:90%;" >}} +{{< img src="/tracing/trace_explorer/trace_groups/group_by_root.png" alt="ルートからグループ化" style="width:90%;" >}} -#### View trace groups in the group list +#### グループ リストでトレース グループを表示する -Trace groups are displayed as unique values of the selected dimension. Each group is shown with three key metrics: -- **REQUESTS**: Count of spans within the group. -- **ERRORS**: Error rate and count of errors. -- **P95 Latency**: p95 latency of spans. +トレース グループは、選択したディメンションの一意の値として表示されます。各グループは、次の 3 つの主要なメトリクスと共に表示されます: +- **REQUESTS**: グループ内のスパンの数。 +- **ERRORS**: エラー レートとエラー数。 +- **P95 Latency**: スパンの p95 レイテンシー。 -To view these metrics aggregated over the parent or root span instead of the queried span, select `parent(a)` or `root` in the **Show metrics from** statement. +これらのメトリクスを、クエリ対象のスパンではなく親スパンまたはルート スパンに集約して表示するには、**Show metrics from** 文で `parent(a)` または `root` を選択します。 -Additionally, the `Latency Breakdown` surfaces how time is spent between different services within requests from each group, allowing you to visually spot latency bottlenecks for given groups. +また、`Latency Breakdown` により、各グループからのリクエスト内で、異なるサービス間でどのように時間が費やされるかが表示されるため、指定したグループについてレイテンシーのボトルネックを可視化することができます。 -{{< img src="/tracing/trace_explorer/trace_groups/group_list.png" alt="Group list" style="width:90%;" >}} +{{< img src="/tracing/trace_explorer/trace_groups/group_list.png" alt="グループ リスト" style="width:90%;" >}} -For deeper analysis, click any group to examine the individual span events that make up the aggregated metrics. +より詳細な分析を行うには、任意のグループをクリックして、集計されたメトリクスを構成する個々のスパン イベントを調べます。 ## ファセット @@ -338,7 +341,7 @@ For deeper analysis, click any group to examine the individual span events that **注**: ダッシュボードおよびノートブック内の APM クエリは、すべての[インデックス化されたスパン][14]に基づきます。一方、モニター内の APM クエリは、[カスタム保持フィルター][19]でインデックス化されたスパンにのみ基づきます。 -## 参考情報 +## 参考資料 {{< partial name="whats-next/whats-next.html" >}}