diff --git a/content/fr/account_management/api-app-keys.md b/content/fr/account_management/api-app-keys.md index ccfed6867f185..8750b6b5cd402 100644 --- a/content/fr/account_management/api-app-keys.md +++ b/content/fr/account_management/api-app-keys.md @@ -15,11 +15,11 @@ Les clés d'API sont uniques à votre organisation. Une [clé d'API][1] est requ ## Clés d'application -Les [clés d'application][2] sont utilisées conjointement avec la clé d'API de votre organisation afin de donner aux utilisateurs un accès complet à l'API de programmation de Datadog. Les clés d'application sont associées au compte utilisateur qui les a créées. Par défaut, elles possèdent les autorisations et les portées de cet utilisateur. +Les [clés d'application][2], associées à la clé API de votre organisation, permettent aux utilisateurs d'accéder à l'API programmatique de Datadog. Les clés d'application sont associées au compte utilisateur qui les a créées et disposent par défaut des autorisations de l'utilisateur qui les a créées. ### Portées -Afin de mieux protéger et sécuriser vos applications, vous avez la possibilité d'appliquer des [portées d'autorisation][3] à vos clés d'application, de façon à définir des autorisations plus granulaires et à limiter les données auxquelles les applications ont accès. Vous pourrez ainsi contrôler les accès de vos applications avec plus de précision et réduire les failles de sécurité en limitant les accès superflus. Par exemple, une application qui se contente de lire des dashboards n'a pas besoin de pouvoir gérer les utilisateurs ou de supprimer les données de votre organisation. +Afin de mieux protéger et sécuriser vos applications, vous avez la possibilité d'appliquer des portées d'autorisation à vos clés d'application, de façon à définir des autorisations plus granulaires et à limiter les données auxquelles les applications ont accès. Vous pourrez ainsi contrôler les accès de vos applications avec plus de précision et réduire les failles de sécurité en limitant les accès superflus. Par exemple, une application qui se contente de lire des dashboards n'a pas besoin de pouvoir gérer les utilisateurs ou de supprimer les données de votre organisation. Lorsque vous appliquez des portées à des clés d'application, il est recommandé d'accorder uniquement les privilèges et les autorisations dont l'application a besoin pour fonctionner correctement. Seules les portées spécifiées par l'utilisateur sont appliquées à la clé d'application : aucune autre autorisation n'est accordée. Vous pouvez modifier la portée d'autorisation d'une clé d'application à tout moment, mais il est essentiel de réfléchir à l'impact que ces modifications auront sur le fonctionnement de votre application et les données auxquelles elle pourra accéder. @@ -68,6 +68,10 @@ Pour ajouter une clé d'application Datadog, accédez à [**Organization Setting {{< img src="account_management/app-key.png" alt="Accédez à la page des clés dʼapplication de votre organisation dans Datadog" style="width:80%;" >}} +{{< site-region region="ap2,gov" >}} +
Assurez-vous de stocker votre clé d'application en toute sécurité dès sa création, car le secret de la clé ne peut pas être récupéré ultérieurement.
+{{< /site-region >}} + **Remarques :** - Les noms de clé d'application ne peuvent pas être vides. @@ -76,9 +80,21 @@ Pour ajouter une clé d'application Datadog, accédez à [**Organization Setting Pour supprimer une clé d'application Datadog, accédez à [**Organization Settings** > **Application Keys**][2]. Vos clés d'application s'affichent alors. Cliquez ensuite sur l'option **Revoke** en regard de la clé à révoquer. Cette option s'affiche uniquement si vous disposez de l'[autorisation][4] requise pour créer et gérer des clés d'application. Si vous êtes autorisé à gérer toutes les clés d'application de votre organisation, vous pouvez rechercher la clé à révoquer, puis cliquer sur l'option **Revoke** correspondante. -## Appliquer une portée à des clés d'application +## Propagation des clés et cohérence éventuelle + +Les clés API et les clés d'application de Datadog suivent un modèle de cohérence éventuelle. En raison de l'architecture distribuée du système, les mises à jour de clés, comme leur création ou révocation, peuvent prendre quelques secondes pour se propager complètement. + +En conséquence : + +- N'utilisez pas immédiatement une nouvelle clé API ou d'application dans des workflows critiques. Prévoyez quelques secondes pour sa propagation. Mettez en place une stratégie de nouvelle tentative avec backoff exponentiel court pour gérer les erreurs transitoires durant la propagation. +- Pour vérifier si une clé API est active, utilisez l'endpoint [/api/v1/validate][18]. +- Pour vérifier si une clé d'application est active, utilisez l'endpoint `/api/v2/validate_keys` avec les bonnes paires de clés. + +L'utilisation d'une clé nouvellement créée avant sa propagation complète peut entraîner des erreurs d'authentification temporaires, telles que 403 Forbidden ou 401 Unauthorized. + +## Définir le champ d'application d'une clé d'application -Pour appliquer des [portées d'autorisation][3] à des clés d'application, créez ou modifiez une clé d'application en [envoyant une requête sur l'API Datadog][5] ou lʼIU pour créer ou modifier une clé dʼapplication. Il est possible d'appliquer une portée aux clés d'application appartenant à [l'utilisateur actuel][14] ou à un [compte de service][15]. Si ce champ n'est pas spécifié, par défaut, la portée de la clé d'application correspondra aux autorisations de l'utilisateur qui l'a créée. +Pour appliquer des portées d'autorisation à des clés d'application, créez ou modifiez une clé d'application en [envoyant une requête sur l'API Datadog][5] ou lʼIU pour créer ou modifier une clé dʼapplication. Il est possible d'appliquer une portée aux clés d'application appartenant à [l'utilisateur actuel][14] ou à un [compte de service][15]. Si ce champ n'est pas spécifié, par défaut, la portée de la clé d'application correspondra aux autorisations de l'utilisateur qui l'a créée. **Remarques :** @@ -127,7 +143,6 @@ Besoin d'aide ? Contactez [l'assistance Datadog][16]. [1]: https://app.datadoghq.com/organization-settings/api-keys [2]: https://app.datadoghq.com/access/application-keys -[3]: /fr/api/latest/scopes/ [4]: /fr/account_management/rbac/permissions [5]: /fr/api/latest/key-management/ [6]: /fr/logs/log_collection/javascript/ @@ -141,4 +156,5 @@ Besoin d'aide ? Contactez [l'assistance Datadog][16]. [14]: /fr/api/latest/key-management/#create-an-application-key-for-current-user [15]: /fr/api/latest/service-accounts/ [16]: /fr/help/ -[17]: /fr/account_management/org_settings/service_accounts/ \ No newline at end of file +[17]: /fr/account_management/org_settings/service_accounts/ +[18]: /fr/api/latest/authentication/#validate-api-key \ No newline at end of file diff --git a/content/fr/agent/basic_agent_usage/saltstack.md b/content/fr/agent/basic_agent_usage/saltstack.md index 434f25ee7cee4..138ac5e479e7e 100644 --- a/content/fr/agent/basic_agent_usage/saltstack.md +++ b/content/fr/agent/basic_agent_usage/saltstack.md @@ -214,7 +214,7 @@ Les formules Salt sont des states Salt pré-écrits. Les states suivants sont di **REMARQUE** : lorsque vous utilisez le state `datadog.config` pour configurer différentes instances de check sur plusieurs machines, l'option [pillar_merge_lists][5] doit être définie sur `True` dans la configuration master de Salt, ou dans la configuration minion de Salt dans le cas d'une exécution sans master. -[1]: http://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html +[1]: https://docs.saltproject.io/en/latest/topics/development/conventions/formulas.html [2]: https://app.datadoghq.com/organization-settings/api-keys [3]: https://docs.datadoghq.com/fr/integrations/directory/ [4]: https://github.com/DataDog/datadog-formula/blob/master/pillar.example diff --git a/content/fr/cloudcraft/components-azure/_index.md b/content/fr/cloudcraft/components-azure/_index.md new file mode 100644 index 0000000000000..8abea3e65fa6b --- /dev/null +++ b/content/fr/cloudcraft/components-azure/_index.md @@ -0,0 +1,44 @@ +--- +title: 'Composants : Azure' +--- + +{{< whatsnext desc="Calcul :" >}} + {{< nextlink href="cloudcraft/components-azure/virtual-machine">}}Machine virtuelle{{< /nextlink >}} + {{< nextlink href="cloudcraft/components-azure/function-app">}}App de fonction{{< /nextlink >}} + {{< nextlink href="cloudcraft/components-azure/web-app">}}App Web{{< /nextlink >}} +{{< /whatsnext >}} + +{{< whatsnext desc="Conteneurs :" >}} + {{< nextlink href="cloudcraft/components-azure/aks-cluster">}}Cluster AKS{{< /nextlink >}} + {{< nextlink href="cloudcraft/components-azure/aks-workload">}}Workload AKS{{< /nextlink >}} + {{< nextlink href="cloudcraft/components-azure/aks-pod">}}Pod AKS{{< /nextlink >}} +{{< /whatsnext >}} + +{{< whatsnext desc="Réseau :" >}} + {{< nextlink href="cloudcraft/components-azure/load-balancer">}}Répartiteur de charge{{< /nextlink >}} + {{< nextlink href="cloudcraft/components-azure/application-gateway">}}Passerelle d'application{{< /nextlink >}} + {{< nextlink href="cloudcraft/components-azure/bastion">}}Bastion{{< /nextlink >}} + {{< nextlink href="cloudcraft/components-azure/vpn-gateway">}}Passerelle VPN{{< /nextlink >}} +{{< /whatsnext >}} + +{{< whatsnext desc="Stockage :" >}} + {{< nextlink href="cloudcraft/components-azure/managed-disk">}}Disque géré{{< /nextlink >}} + {{< nextlink href="cloudcraft/components-azure/block-blob">}}Blob en blocs{{< /nextlink >}} + {{< nextlink href="cloudcraft/components-azure/azure-queue">}}File d'attente Azure{{< /nextlink >}} + {{< nextlink href="cloudcraft/components-azure/azure-table">}}Table Azure{{< /nextlink >}} + {{< nextlink href="cloudcraft/components-azure/file-share">}}Partage de fichiers{{< /nextlink >}} +{{< /whatsnext >}} + +{{< whatsnext desc="Base de données :" >}} + {{< nextlink href="cloudcraft/components-azure/cosmos-db">}}Cosmos DB{{< /nextlink >}} + {{< nextlink href="cloudcraft/components-azure/database-for-mysql">}}Base de données pour MySQL{{< /nextlink >}} + {{< nextlink href="cloudcraft/components-azure/database-for-postgresql">}}Base de données pour PostgreSQL{{< /nextlink >}} + {{< nextlink href="cloudcraft/components-azure/cache-for-redis">}}Cache pour Redis{{< /nextlink >}} +{{< /whatsnext >}} + +{{< whatsnext desc="Intégrations :" >}} + {{< nextlink href="cloudcraft/components-azure/service-bus-queue">}}File d'attente Service Bus{{< /nextlink >}} + {{< nextlink href="cloudcraft/components-azure/service-bus-topic">}}Sujet Service Bus{{< /nextlink >}} + {{< nextlink href="cloudcraft/components-azure/service-bus-namespace">}}Espace de nommage Service Bus{{< /nextlink >}} + {{< nextlink href="cloudcraft/components-azure/api-management">}}Gestion des API{{< /nextlink >}} +{{< /whatsnext >}} \ No newline at end of file diff --git a/content/fr/containers/kubernetes/log.md b/content/fr/containers/kubernetes/log.md new file mode 100644 index 0000000000000..a995a3a05928b --- /dev/null +++ b/content/fr/containers/kubernetes/log.md @@ -0,0 +1,547 @@ +--- +aliases: +- /fr/agent/kubernetes/log +further_reading: +- link: /agent/kubernetes/apm/ + tag: Documentation + text: Recueillir les traces de vos applications +- link: /agent/kubernetes/prometheus/ + tag: Documentation + text: Recueillir vos métriques Prometheus +- link: /agent/kubernetes/integrations/ + tag: Documentation + text: Recueillir automatiquement les métriques et les logs de vos applications +- link: /agent/guide/autodiscovery-management/ + tag: Documentation + text: Limiter la collecte de données à un sous-ensemble de conteneurs +- link: /agent/kubernetes/tag/ + tag: Documentation + text: Attribuer des tags à toutes les données envoyées par un conteneur +title: Collecte de logs Kubernetes +--- + +Cette page explique comment collecter des logs à partir des fichiers de logs Kubernetes. + +Lorsque vos applications conteneurisées écrivent leurs logs dans les flux standard `stdout`/`stderr`, le runtime de conteneur et Kubernetes gèrent automatiquement ces logs. Par défaut, [Kubernetes enregistre ces flux sous forme de fichiers][13] sur le host, dans le dossier `/var/log/pods` et ses sous-dossiers, un par pod et par conteneur. + +L’Agent Datadog peut collecter ces fichiers de logs Kubernetes à l’aide des instructions ci-dessous. Cette méthode est bien adaptée au caractère éphémère des pods créés par Kubernetes et est plus économe en ressources que la collecte via le socket Docker. Datadog recommande cette approche pour la collecte des logs dans Kubernetes. + +Par ailleurs, l’Agent Datadog peut aussi collecter les logs en interrogeant l’API Docker via le socket Docker. Cela nécessite que Docker soit le runtime utilisé dans votre cluster Kubernetes. Cette méthode est plus gourmande en ressources que la collecte par fichiers. Pour l’utiliser, consultez la section [collecte des logs via le socket Docker][1]. Si vos applications conteneurisées écrivent dans des fichiers de logs internes aux conteneurs, cela complique la collecte. Consultez la section [collecte de logs à partir d’un fichier](#a-partir-d-un-fichier-log-de-conteneurfile). + +## Configuration + +### Collecte de logs + +Avant de commencer la collecte des logs d’application, assurez-vous que l’Agent Datadog est en cours d’exécution dans votre cluster Kubernetes. + +Pour configurer la collecte de logs manuellement dans le DaemonSet, consultez la section [Collecte de logs avec DaemonSet][9]. Sinon, suivez les instructions ci-dessous : + +{{< tabs >}} +{{% tab "Operator Datadog" %}} + +Mettez à jour votre manifeste `datadog-agent.yaml` comme suit : + +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + global: + credentials: + apiKey: + + features: + logCollection: + enabled: true + containerCollectAll: true +``` + +Ensuite, appliquez la nouvelle configuration : + +```shell +kubectl apply -n $DD_NAMESPACE -f datadog-agent.yaml +``` + +Consultez l'exemple de [manifeste avec activation des logs, de l'APM et de la collecte des métriques][1] pour plus d'informations. Vous pouvez définir `features.logCollection.containerCollectAll` sur `true` pour collecter les logs de tous les conteneurs détectés par défaut. Lorsque cette valeur est définie sur `false` (valeur par défaut), vous devez spécifier des configurations de collecte de logs avec Autodiscovery pour activer la collecte. Pour en savoir plus, consultez la section [Détection des logs - Filtrage](#filtrage). + +[1]: https://github.com/DataDog/datadog-operator/blob/main/examples/datadogagent/datadog-agent-with-logs-apm.yaml +{{% /tab %}} +{{% tab "Helm" %}} + +Pour activer la collecte de logs avec Helm, mettez à jour votre fichier [datadog-values.yaml][1] avec la configuration suivante pour la collecte de logs. Ensuite, mettez à jour votre chart Helm Datadog : + +```yaml +datadog: + logs: + enabled: true + containerCollectAll: true +``` + +Vous pouvez définir `datadog.logs.containerCollectAll` sur `true` pour collecter les logs de tous les conteneurs détectés par défaut. Lorsque cette valeur est définie sur `false` (valeur par défaut), vous devez spécifier des configurations de collecte de logs avec Autodiscovery pour activer la collecte. Pour en savoir plus, consultez [Détection des logs - Filtrage](#filtrage). + +[1]: https://github.com/DataDog/helm-charts/blob/master/charts/datadog/values.yaml +{{% /tab %}} +{{< /tabs >}} + +### Sans privilèges + +{{< tabs >}} +{{% tab "Datadog Operator" %}} +(Facultatif) Pour exécuter une installation sans privilèges, ajoutez le bloc suivant à la [ressource personnalisée DatadogAgent][1] : + +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + global: + credentials: + apiKey: + + features: + logCollection: + enabled: true + containerCollectAll: true + + override: + nodeAgent: + securityContext: + runAsUser: + supplementalGroups: + - +``` + +- Remplacez par l'identifiant utilisateur (UID) qui exécutera l'Agent. +- Remplacez par l'identifiant du groupe possédant le socket Docker ou containerd. + +[1]: https://github.com/DataDog/datadog-operator/blob/main/docs/configuration.v2alpha1.md#override +{{% /tab %}} +{{% tab "Helm" %}} + +(Facultatif) Pour exécuter une installation sans privilèges, ajoutez le bloc suivant au fichier `values.yaml` : + +```yaml +datadog: + securityContext: + runAsUser: + supplementalGroups: + - +``` + +- Remplacez par l'identifiant utilisateur (UID) qui exécutera l'Agent. +- Remplacez par l'identifiant du groupe possédant le socket Docker ou containerd. + +{{% /tab %}} +{{< /tabs >}} + +
+Avertissement pour les installations non privilégiées +

+Lors d’une installation non privilégiée, l’Agent doit pouvoir lire les fichiers de logs dans /var/log/pods. +

+Si vous utilisez le runtime containerd, les fichiers dans /var/log/pods sont lisibles par les membres du groupe root. Avec la configuration ci-dessus, l’Agent s’exécute avec le groupe root. Aucune action supplémentaire n’est nécessaire. +

+Si vous utilisez le runtime Docker, les fichiers de /var/log/pods sont des liens symboliques vers /var/lib/docker/containers, qui n’est accessible qu’à l’utilisateur root. Par conséquent, avec Docker, un Agent non root ne peut pas lire les logs de /var/log/pods. Le socket Docker doit être monté dans le conteneur de l’Agent pour lui permettre d’accéder aux logs via le démon Docker. +

+Pour collecter les logs de /var/log/pods lorsque le socket Docker est monté, définissez la variable d’environnement DD_LOGS_CONFIG_K8S_CONTAINER_USE_FILE (ou logs_config.k8s_container_use_file dans datadog.yaml) sur true. Cela force l’Agent à utiliser le mode de collecte basé sur les fichiers. +
+ +## Détection de logs + +L'Agent Datadog dans Kubernetes est déployé via un DaemonSet (géré par le Datadog Operator ou par Helm). Ce DaemonSet déploie une réplique du pod Agent sur chaque nœud du cluster. Chaque pod Agent est alors responsable de la remontée des logs des autres pods et conteneurs présents sur son nœud. Lorsque la fonctionnalité « Container Collect All » est activée, l’Agent remonte les logs de chaque conteneur détecté avec un ensemble par défaut de tags. + +### Filtrage + +Lorsque « Container Collect All » est activé, vous pouvez configurer les conteneurs dont vous souhaitez collecter les logs. Cela peut être utile si vous souhaitez éviter, par exemple, de collecter les logs de l’Agent Datadog. Vous pouvez procéder en transmettant une configuration à l’Agent pour contrôler ce qu’il collecte, ou en configurant les pods Kubernetes afin d’exclure explicitement certains logs. + +Lorsque vous filtrez des logs à l’aide de méthodes comme `DD_CONTAINER_EXCLUDE_LOGS` ou `ad.datadoghq.com/logs_exclude`, l’Agent ignore la collecte des logs, même si une configuration explicite est définie via les [annotations Autodiscovery][19] ou les [fichiers de configuration Autodiscovery][20]. + +Lorsque « Container Collect All » est désactivé (valeur par défaut), aucun filtrage n’est nécessaire car tout est exclu par défaut. Pour collecter uniquement certains pods, vous pouvez activer la configuration de collecte via les [annotations Autodiscovery][19] ou les [fichiers de configuration Autodiscovery][20] pour les pods concernés. + +Consultez la section [Gestion de la détection des conteneurs][8] (en anglais) pour en savoir plus sur le filtrage. + +### Tags + +L’Agent Datadog ajoute aux logs des conteneurs Kubernetes les tags Kubernetes par défaut ainsi que tous les tags personnalisés extraits. Lorsque « Container Collect All » est activé, les logs d’un conteneur sont remontés avec des tags `source` et `service` correspondant au nom court de l’image du conteneur. Par exemple, les logs d’un conteneur utilisant l’image `gcr.io/owner/example-image:latest` auront la valeur `example-image` pour les tags `source`, `service` et `short_image`. + +Le tag `service` peut également être défini à l’aide du label Pod [Unified Service Tagging][4] `tags.datadoghq.com/service: ""`. Pour en savoir plus sur les attributs `source` et `service`, consultez la page [Attributs réservés][11]. + +Le tag `source` peut être important pour vos logs, car les [pipelines de logs préconfigurés][15] sont filtrés en fonction de ce tag. Ces pipelines peuvent cependant être personnalisés selon vos besoins. Vous trouverez plus de détails sur la personnalisation des tags dans vos logs dans la section [Logs d’intégration](#logs-d-integration) ci-dessous. + +## Logs d'intégration + +[Autodiscovery][10] vous permet d’utiliser des modèles pour configurer la collecte des logs (et d’autres fonctionnalités) sur les conteneurs. Cela permet d’activer la collecte, de personnaliser les tags et de définir des règles avancées. Pour configurer la collecte pour une intégration avec Autodiscovery, vous pouvez : + +- Définir une configuration de log dans les annotations Autodiscovery d’un pod donné, pour configurer les règles pour un conteneur spécifique *(Recommandé)* +- Définir une configuration de log dans un fichier de configuration, pour appliquer les règles à chaque conteneur correspondant à une image + +Ces configurations doivent au minimum spécifier les tags `source` et `service`. Il est recommandé d’associer le tag `source` à l’un des [pipelines de logs préconfigurés Datadog][15] afin d’enrichir automatiquement vos logs. Vous pouvez également consulter une [bibliothèque de pipelines dans Datadog][16]. + +### Annotations Autodiscovery + +Avec Autodiscovery, l’Agent recherche automatiquement les modèles d’intégration dans les annotations des pods. + +Pour appliquer une configuration spécifique à un conteneur, ajoutez l’annotation `ad.datadoghq.com/.logs` à votre pod avec une configuration de log au format JSON. + +**Remarque** : les annotations Autodiscovery identifient les conteneurs par leur nom, **et non** par leur image. Elles tentent de faire correspondre `` à `.spec.containers[i].name`, et non à `.spec.containers[i].image`. + +
+Si vous définissez vos pods Kubernetes directement (avec kind:Pod), ajoutez les annotations de chaque Pod dans la section metadata, comme montré dans la section suivante. +

+Si vous définissez vos pods Kubernetes indirectement (à l’aide de contrôleurs de réplication, de ReplicaSets ou de déploiements), ajoutez les annotations de pod au modèle de pod sous .spec.template.metadata.
+ +#### Configurer un seul conteneur +Pour configurer la collecte des logs pour un conteneur donné dans un pod, ajoutez les annotations suivantes à votre pod : + +```yaml +apiVersion: v1 +kind: Pod +# (...) +metadata: + name: '' + annotations: + ad.datadoghq.com/.logs: '[]' + # (...) +spec: + containers: + - name: '' +# (...) +``` + +#### Exemple d’annotations Autodiscovery pour les logs + +L'annotation de pod suivante définit le modèle d'intégration pour un exemple de conteneur. Elle est définie dans les annotations du modèle de pod, et non sur le déploiement lui-même. Cette configuration de logs applique aux logs du conteneur `app` les tags `source:java`, `service:example-app` et un tag supplémentaire `foo:bar`. + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: example + labels: + app: example-app +spec: + selector: + matchLabels: + app: example-app + template: + metadata: + labels: + app: example-app + annotations: + ad.datadoghq.com/app.logs: '[{"source":"java", "service":"example-app", "tags":["foo:bar"]}]' + spec: + containers: + - name: app + image: owner/example-image:latest +``` + +#### Configurer deux conteneurs différents +Pour appliquer deux modèles d'intégration différents à deux conteneurs différents dans votre pod, `` et ``, ajoutez les annotations suivantes à votre pod : + +```yaml +apiVersion: v1 +kind: Pod +# (...) +metadata: + name: '' + annotations: + ad.datadoghq.com/.logs: '[]' + # (...) + ad.datadoghq.com/.logs: '[]' +spec: + containers: + - name: '' + # (...) + - name: '' +# (...) +``` + +### Fichiers de configuration Autodiscovery +Vous pouvez fournir à l'Agent Datadog des fichiers de configuration afin qu'il exécute une intégration donnée lorsqu'il découvre un conteneur correspondant à un identifiant d'image. Cela vous permet de créer une configuration de logs générique qui s'applique à un ensemble d'images de conteneurs. + +{{< tabs >}} +{{% tab "Datadog Operator" %}} +Vous pouvez personnaliser la collecte des logs par intégration à l'aide d'un override dans `override.nodeAgent.extraConfd.configDataMap`. Cette méthode crée le ConfigMap et monte le fichier de configuration souhaité dans le conteneur de l'Agent. + +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + #(...) + override: + nodeAgent: + extraConfd: + configDataMap: + .yaml: |- + ad_identifiers: + - + + logs: + - source: example-source + service: example-service +``` + +Le champ `` doit correspondre au nom court de l'image de conteneur auquel cette configuration doit s'appliquer. Consultez le manifeste d'exemple [avec mappage ConfigMap][1] pour un exemple supplémentaire. + +[1]: https://github.com/DataDog/datadog-operator/blob/main/examples/datadogagent/datadog-agent-with-extraconfd.yaml +{{% /tab %}} + +{{% tab "Helm" %}} +Vous pouvez personnaliser la collecte des logs par intégration dans `datadog.confd`. Cette méthode crée le ConfigMap et monte le fichier de configuration souhaité dans le conteneur de l'Agent. + +```yaml +datadog: + #(...) + confd: + .yaml: |- + ad_identifiers: + - + + logs: + - source: example-source + service: example-service +``` + +Le champ `` doit correspondre au nom court de l'image de conteneur auquel cette configuration doit s'appliquer. + +{{% /tab %}} + +{{% tab "Key-value store" %}} +Les commandes etcd suivantes créent un modèle d'intégration Redis avec un paramètre `password` personnalisé, et appliquent les bons attributs `source` et `service` aux logs : + +```conf +etcdctl mkdir /datadog/check_configs/redis +etcdctl set /datadog/check_configs/redis/logs '[{"source": "redis", "service": "redis", "tags": ["env:prod"]}]' +``` + +Notez que chacune des trois valeurs est une liste. Autodiscovery assemble les éléments de liste en fonction des index de liste partagée de manière à générer la configuration de l'intégration. Dans le cas présent, il assemble la première (et unique) configuration de check à partir de `check_names[0]`, `init_configs[0]` et `instances[0]`. + +Contrairement aux fichiers de configuration automatique, **les stockages key/value peuvent utiliser la version courte OU la version longue du nom d'image comme identificateur de conteneur**. Exemple : `redis` OU `redis:latest`. + +Autodiscovery peut utiliser [Consul][1], Etcd et Zookeeper comme sources de modèles d'intégration. + +Pour utiliser un key-value store, configurez-le dans le fichier `datadog.yaml` de l'Agent et montez ce fichier dans le conteneur de l'Agent. Vous pouvez aussi passer votre key-value store via des variables d'environnement dans le conteneur de l'Agent. + +#### Dans `datadog.yaml` + +Dans le fichier `datadog.yaml`, définissez l'adresse `` et le `` de votre stockage clé-valeur : + + ```yaml + config_providers: + - name: etcd + polling: true + template_dir: /datadog/check_configs + template_url: ':' + username: + password: + + - name: consul + polling: true + template_dir: datadog/check_configs + template_url: ':' + ca_file: + ca_path: + cert_file: + key_file: + username: + password: + token: + + - name: zookeeper + polling: true + template_dir: /datadog/check_configs + template_url: ':' + username: + password: + ``` + +[Redémarrez ensuite l'Agent][2] pour prendre en compte le changement de configuration. + +#### Dans les variables d'environnement + +Lorsque le stockage clé-valeur est activé en tant que source de modèle, l'Agent recherche des modèles à partir de la clé `/datadog/check_configs`. Autodiscovery s'attend à une hiérarchie clé-valeur comme suit : + +```yaml +/datadog/ + check_configs/ + / + - logs: [""] + ... +``` + +**Remarque** : pour appliquer une configuration spécifique à un conteneur donné, Autodiscovery identifie les conteneurs par **image** en cas d'utilisation de stockages clé-valeur. En d'autres termes, il cherche à faire correspondre `` à `.spec.containers[0].image`. + +[1]: /fr/integrations/consul/ +[2]: /fr/agent/configuration/agent-commands/ +{{% /tab %}} +{{< /tabs >}} + +## Collecte de logs avancée + +Utilisez des étiquettes de log Autodiscovery afin d'appliquer une logique de traitement avancée pour la collecte de logs. Par exemple : + +* [Filtrer les logs avant de les envoyer à Datadog][5]. +* [Nettoyer les données sensibles de vos logs][6]. +* [Effectuer une agrégation multiligne][7]. + +### Depuis un fichier de logs local au conteneur + +Datadog recommande d'utiliser les flux de sortie `stdout` et `stderr` pour les applications conteneurisées afin de configurer automatiquement la collecte des logs. + +Cependant, l'Agent peut également collecter directement des logs à partir d'un fichier à l'aide d'une annotation. Pour collecter ces logs, utilisez `ad.datadoghq.com/.logs` avec une configuration `type: file` et `path`. Les logs collectés à partir de fichiers avec une telle annotation sont automatiquement étiquetés avec le même ensemble de tags que ceux provenant du conteneur lui-même. Datadog recommande d'utiliser les flux de sortie `stdout` et `stderr` pour les applications conteneurisées, afin de configurer automatiquement la collecte des logs. Pour plus d'informations, consultez les [configurations recommandées](#configurations-recommandees). + +Ces chemins de fichiers sont **relatifs** au conteneur de l'Agent. Le répertoire contenant le fichier de logs doit donc être monté à la fois dans le conteneur applicatif et dans le conteneur de l'Agent afin que celui-ci puisse y accéder. + +Par exemple, vous pouvez utiliser un volume partagé `hostPath`. Le pod ci-dessous émet des logs dans le fichier `/var/log/example/app.log`, situé dans le répertoire `/var/log/example`, configuré à l'aide d'un volume et d'un volumeMount de type `hostPath`. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: logger + annotations: + ad.datadoghq.com/busybox.logs: | + [{ + "type": "file", + "path": "/var/log/example/app.log", + "source": "example-source", + "service": "example-service" + }] +spec: + containers: + - name: busybox + image: busybox + command: [ "/bin/sh", "-c", "--" ] + args: [ "while true; do sleep 1; echo `date` example file log >> /var/log/example/app.log; done;" ] + volumeMounts: + - name: applogs + mountPath: /var/log/example + volumes: + - name: applogs + hostPath: + path: /var/log/example +``` + +Le même volume et le même chemin `volumeMount` doivent être définis dans le conteneur de l'Agent pour qu'il puisse lire ce fichier de log. + +```yaml + containers: + - name: agent + # (...) + volumeMounts: + - mountPath: /var/log/example + name: applogs + # (...) + volumes: + - name: applogs + hostPath: + path: /var/log/example + # (...) +``` +#### Configurations recommandées +- Cette stratégie peut fonctionner pour un pod donné, mais elle peut devenir contraignante lorsqu'elle est utilisée par plusieurs applications. Vous pouvez également rencontrer des problèmes si plusieurs réplicas utilisent le même chemin de log. Si possible, Datadog recommande de tirer parti de la [variable de modèle Autodiscovery][17] `%%kube_pod_name%%`. Par exemple, vous pouvez définir le champ `path` en utilisant cette variable : `"path": "/var/log/example/%%kube_pod_name%%/app.log"`. Le pod de votre application doit alors également écrire ses fichiers de log en respectant ce nouveau chemin. Vous pouvez utiliser l'[API Downward][18] pour aider votre application à déterminer son nom de pod. + +- Lorsque vous utilisez ce type d'annotation avec un conteneur, les logs `stdout` et `stderr` ne sont pas automatiquement collectés depuis ce conteneur. Si vous avez besoin de collecter à la fois les flux de sortie du conteneur et les fichiers, vous devez l'activer explicitement dans l'annotation. Par exemple : + ```yaml + ad.datadoghq.com/.logs: | + [ + {"type":"file","path":"/var/log/example/app.log","source":"file","service":"example-service"}, + {"source":"container","service":"example-service"} + ] + ``` + +- Lorsque vous utilisez ce type de combinaison, les paramètres `source` et `service` ne présentent aucune valeur par défaut pour les logs recueillis depuis un fichier. Ils doivent être définis explicitement dans l'annotation. + +## Dépannage + +#### Conteneurs de courte durée + +Par défaut, l'Agent recherche de nouveaux conteneurs toutes les 5 secondes. + +Si vous utilisez l'Agent v6.12+, les logs de conteneurs de courte durée (en raison d'une interruption ou d'un crash) sont automatiquement recueillis à partir des fichiers Kubernetes (via `/var/log/pods`). Les logs des conteneurs d'initialisation sont eux aussi recueillis. + +#### Tags manquants sur les nouveaux conteneurs ou pods + +Lors de l'envoi de logs vers Datadog depuis des conteneurs ou des pods nouvellement créés, le tagger interne de l'Agent Datadog peut ne pas encore avoir les tags associés au conteneur ou au pod. Par conséquent, ces logs peuvent manquer de certains tags. + +Pour résoudre ce problème, vous pouvez utiliser la variable d'environnement `DD_LOGS_CONFIG_TAGGER_WARMUP_DURATION` pour configurer une durée (en secondes) pendant laquelle l'Agent Datadog attend avant de commencer à envoyer les logs provenant de conteneurs et de pods nouvellement créés. La valeur par défaut est `0`. + +{{< tabs >}} +{{% tab "Operator Datadog" %}} + +```yaml +spec: + override: + nodeAgent: + env: + - name: DD_LOGS_CONFIG_TAGGER_WARMUP_DURATION + value: "5" +``` +{{% /tab %}} +{{% tab "Helm" %}} +```yaml +datadog: + env: + - name: DD_LOGS_CONFIG_TAGGER_WARMUP_DURATION + value: "5" +``` +{{% /tab %}} +{{< /tabs >}} + +#### Tags manquants au niveau du host sur de nouveaux hosts ou nœuds + +Les tags au niveau du host sont ceux visibles dans la liste d'infrastructure pour un host donné, et proviennent soit du fournisseur cloud, soit de l'Agent Datadog. Les tags de host courants incluent `kube_cluster_name`, `region`, `instance-type` et `autoscaling-group`. + +Lors de l'envoi de logs vers Datadog depuis un host ou un nœud nouvellement créé, il peut s'écouler quelques minutes avant que les tags de host ne soient [hérités][12]. Par conséquent, ces logs peuvent manquer de tags au niveau du host. + +Pour résoudre ce problème, vous pouvez utiliser la variable d'environnement `DD_LOGS_CONFIG_EXPECTED_TAGS_DURATION` pour configurer une durée (en minutes). Pendant cette durée, l'Agent Datadog ajoute manuellement les tags de host qu'il connaît à chaque log envoyé. Après cette période, l'Agent revient à l'utilisation de l'héritage des tags à l'ingestion. + +{{< tabs >}} +{{% tab "Operator Datadog" %}} +```yaml +spec : + override : + nodeAgent: + env : + - name : DD_LOGS_CONFIG_EXPECTED_TAGS_DURATION + value : "10m" +``` +{{% /tab %}} +{{% tab "Helm" %}} +```yaml +datadog : + env : + - name : DD_LOGS_CONFIG_EXPECTED_TAGS_DURATION + value : "10m" +``` +{{% /tab %}} +{{< /tabs >}} + +## Pour aller plus loin + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /fr/agent/faq/log-collection-with-docker-socket/ +[2]: /fr/agent/kubernetes/ +[3]: /fr/integrations/#cat-autodiscovery +[4]: /fr/getting_started/tagging/unified_service_tagging/?tab=kubernetes +[5]: /fr/agent/logs/advanced_log_collection/?tab=kubernetes#filter-logs +[6]: /fr/agent/logs/advanced_log_collection/?tab=kubernetes#scrub-sensitive-data-from-your-logs +[7]: /fr/agent/logs/advanced_log_collection/?tab=kubernetes#multi-line-aggregation +[8]: /fr/agent/guide/autodiscovery-management/ +[9]: /fr/containers/guide/kubernetes_daemonset/#log-collection +[10]: /fr/getting_started/containers/autodiscovery +[11]: /fr/logs/log_configuration/attributes_naming_convention/ +[12]: /fr/getting_started/tagging/assigning_tags/#integration-inheritance +[13]: https://kubernetes.io/docs/concepts/cluster-administration/logging/#log-location-node +[14]: /fr/containers/kubernetes/tag +[15]: /fr/logs/log_configuration/pipelines/?tab=source#integration-pipelines +[16]: https://app.datadoghq.com/logs/pipelines/pipeline/library +[17]: /fr/containers/guide/template_variables/ +[18]: https://kubernetes.io/docs/tasks/inject-data-application/environment-variable-expose-pod-information/ +[19]: /fr/containers/kubernetes/log/?tab=helm#autodiscovery-annotations +[20]: /fr/containers/kubernetes/log/?tab=helm#autodiscovery-configuration-files \ No newline at end of file diff --git a/content/fr/containers/kubernetes/prometheus.md b/content/fr/containers/kubernetes/prometheus.md index 410beff091a54..a723ad5e844e7 100644 --- a/content/fr/containers/kubernetes/prometheus.md +++ b/content/fr/containers/kubernetes/prometheus.md @@ -27,15 +27,15 @@ further_reading: title: Collecte de métriques Prometheus et OpenMetrics avec Kubernetes --- -Recueillez vos métriques Prometheus et OpenMetrics exposées à partir de votre application exécutée dans Kubernetes à l'aide de l'Agent Datadog et de l'intégration [Datadog/OpenMetrics][1] ou [Datadog/Prometheus][2]. - ## Présentation -Depuis la version 6.5.0, l'Agent inclut des checks [OpenMetrics][3] et [Prometheus][4] capables de scraper les endpoints Prometheus. Nous vous conseillons d'utiliser le check OpenMetrics du fait de son efficacité accrue et de sa prise en charge complète du format texte Prometheus. Pour en savoir plus sur l'utilisation avancée de l'interface `OpenMetricsCheck` et le développement d'un check custom, consultez la section [Outils de développement][5]. N'utilisez le check Prometheus que lorsque l'endpoint de métriques ne prend pas en charge un format texte. +Collectez les métriques Prometheus et OpenMetrics exposées par votre application s'exécutant dans Kubernetes à l'aide de l'Agent Datadog et des intégrations [OpenMetrics][1] ou [Prometheus][2]. Par défaut, toutes les métriques récupérées par la vérification Prometheus générique sont considérées comme des métriques personnalisées. + +Depuis la version 6.5.0, l'Agent inclut les vérifications [OpenMetrics][3] et [Prometheus][4], capables d'interroger des endpoints Prometheus. Pour un usage avancé de l'interface `OpenMetricsCheck`, y compris la création d'une vérification personnalisée, consultez la section [Outils pour développeurs][5]. -Cette page décrit les principes d'utilisation de base de ces checks. Ils vous permettent de scraper des métriques custom à partir d'endpoints Prometheus. +Cette page explique l'utilisation de base de ces checks, qui vous permettent d'interroger des métriques personnalisées à partir de endpoints Prometheus. Pour une explication du mappage entre les métriques Prometheus et celles de Datadog, consultez le guide [Mappage de métriques Prometheus avec des métriques Datadog][6]. -Pour obtenir une explication sur le mappage de métriques Prometheus et OpenMetrics avec des métriques Datadog, consultez le [guide dédié][6]. +**Remarque :** nous vous conseillons d'utiliser le [check OpenMetrics][1] du fait de son efficacité accrue et de sa prise en charge complète du format texte Prometheus. N'utilisez le check Prometheus que lorsque l'endpoint de métriques ne prend pas en charge un format texte. ## Configuration @@ -50,22 +50,22 @@ Configurez votre check OpenMetrics ou Prometheus à l'aide de la fonctionnalité {{< tabs >}} {{% tab "Kubernetes (AD v2)" %}} -**Remarque :** les annotations AD v2 ont été ajoutées dans l'Agent Datadog 7.36 afin de simplifier la configuration de l'intégration. Pour les versions précédentes de l'Agent Datadog, utilisez les annotations AD v1. +**Remarque :** les annotations AD v2 ont été ajoutées dans la version 7.36 de l'Agent Datadog afin de simplifier la configuration de l'intégration. Pour les versions précédentes de l'Agent Datadog, utilisez les annotations AD v1. ```yaml # (...) metadata: #(...) annotations: - ad.datadoghq.com/.checks: | + ad.datadoghq.com/.checks: | { "openmetrics": { "init_config": {}, "instances": [ { - "openmetrics_endpoint": "http://%%host%%:%%port%%/ ", - "namespace": "", - "metrics": [{"":""}] + "openmetrics_endpoint": "http://%%host%%:%%port%%/ ", + "namespace": "", + "metrics": [{"":""}] } ] } @@ -73,7 +73,7 @@ metadata: spec: containers: - - name: '' + - name: '' ``` {{% /tab %}} @@ -84,21 +84,21 @@ spec: metadata: #(...) annotations: - ad.datadoghq.com/.check_names: | + ad.datadoghq.com/.check_names: | ["openmetrics"] - ad.datadoghq.com/.init_configs: | + ad.datadoghq.com/.init_configs: | [{}] - ad.datadoghq.com/.instances: | + ad.datadoghq.com/.instances: | [ { - "openmetrics_endpoint": "http://%%host%%:%%port%%/ ", - "namespace": "", - "metrics": [{"":""}] + "openmetrics_endpoint": "http://%%host%%:%%port%%/ ", + "namespace": "", + "metrics": [{"":""}] } ] spec: containers: - - name: '' + - name: '' ``` {{% /tab %}} @@ -106,24 +106,26 @@ spec: Les placeholders à configurer sont les suivants : -| Placeholder | Description | +| Placeholder | Rôle | |------------------------------------------|----------------------------------------------------------------------------------------------------| -| `` | L'identificateur utilisé dans les `annotations` doit correspondre au `name` du conteneur exposant les métriques. | +| `` | Correspond au nom du conteneur qui expose les métriques. | | `` | Le chemin d'URL pour les métriques traitées par le conteneur, au format Prometheus. | | `` | L'espace de nommage spécifié ici sera ajouté comme préfixe à chaque métrique lors de son affichage dans Datadog. | | `` | La clé de la métrique Prometheus à récupérer à partir de l'endpoint Prometheus. | | `` | Remplace la clé de métrique `` par le `` dans Datadog. | -Le paramètre `metrics` correspond à la liste des métriques à récupérer sous forme de métriques custom. Ajoutez chaque métrique à récupérer et le nom de métrique souhaité dans Datadog sous la forme de paires key/value : `{"":""}`. Il est également possible de fournir une liste de noms de métriques sous forme de chaînes, qui seront interprétées en tant qu'expressions régulières, afin de récupérer les métriques de votre choix avec leur nom actuel. Si vous souhaitez récupérer **toutes** les métriques, utilisez `"*"` au lieu de `".*"`. +La configuration `metrics` est une liste de métriques à récupérer en tant que métriques personnalisées. Indiquez chaque métrique à collecter ainsi que le nom souhaité dans Datadog sous forme de paires clé-valeur, par exemple : `{"":""}`. Pour éviter des frais excessifs liés aux métriques personnalisées, Datadog recommande de limiter la portée aux seules métriques nécessaires. Vous pouvez également fournir une liste de noms de métriques sous forme de chaînes de caractères, interprétées comme des expressions régulières, pour collecter les métriques souhaitées avec leur nom d'origine. Pour récupérer **toutes** les métriques, utilisez `".*"` plutôt que `"*"`. **Remarque** : les expressions régulières peuvent entraîner l'envoi d'un volume important de métriques custom. Pour obtenir la liste complète des paramètres disponibles pour les instances, notamment `namespace` et `metrics`, consultez l'[exemple de configuration openmetrics.d/conf.yaml][9]. +**Remarque** : la vérification est limitée par défaut à 2 000 métriques. Utilisez le paramètre optionnel `max_returned_metrics` pour modifier cette limite. + ## Prise en main -### Collecte de métriques simple +### Collecte simple de métriques (OpenMetrics Check) 1. [Lancez l'Agent Datadog][10]. @@ -131,7 +133,7 @@ Pour obtenir la liste complète des paramètres disponibles pour les instances, {{< tabs >}} {{% tab "Kubernetes (AD v2)" %}} - **Remarque :** Annotations AD v2 a été ajouté dans l'Agent Datadog 7.36 afin de simplifier la configuration de l'intégration. Pour les versions précédentes de l'Agent Datadog, utilisez Annotations AD v1. + **Remarque :** les annotations AD v2 ont été ajoutées dans la version 7.36 de l'Agent Datadog afin de simplifier la configuration de l'intégration. Pour les versions précédentes de l'Agent Datadog, utilisez les annotations AD v1. ```yaml # (...) @@ -160,7 +162,7 @@ Pour obtenir la liste complète des paramètres disponibles pour les instances, - name: prometheus-example # (...) ``` - {{< /tabs >}} + {{% /tab %}} {{% tab "Kubernetes (AD v1)" %}} ```yaml @@ -191,7 +193,7 @@ Pour obtenir la liste complète des paramètres disponibles pour les instances, # (...) ``` - {{< /tabs >}} + {{% /tab %}} {{< /tabs >}} Commande pour créer le déploiement Prometheus : @@ -200,14 +202,18 @@ Pour obtenir la liste complète des paramètres disponibles pour les instances, kubectl create -f prometheus.yaml ``` -3. Accédez à votre page [Metric summary][12] pour visualiser les métriques recueillies à partir de cet exemple de pod. Cette configuration recueillera les métriques `promhttp_metric_handler_requests`, `promhttp_metric_handler_requests_in_flight`, ainsi que toutes les métriques commençant par `go_memory` qui sont exposées. +3. Rendez-vous sur votre page [Fleet Automation][16] et filtrez par l'intégration `openmetrics` pour consulter des informations détaillées sur l'état de vos vérifications. + +4. Accédez à votre page [Metric summary][12] pour visualiser les métriques recueillies à partir de cet exemple de pod. Cette configuration recueillera les métriques `promhttp_metric_handler_requests`, `promhttp_metric_handler_requests_in_flight`, ainsi que toutes les métriques commençant par `go_memory` qui sont exposées. {{< img src="integrations/guide/prometheus_kubernetes/openmetrics_v2_collected_metric_kubernetes.png" alt="Métriques Prometheus recueillies Kubernetes">}} -## Collecte de métriques avec des annotations Prometheus +## Collecte de métriques avec les annotations Prometheus (Prometheus Check) Grâce à la fonctionnalité Autodiscovery Prometheus, l'Agent Datadog peut détecter les annotations Prometheus natives (comme `prometheus.io/scrape`, `prometheus.io/path` ou `prometheus.io/port`) et planifier automatiquement des checks OpenMetrics de façon à recueillir des métriques Prometheus dans Kubernetes. +**Remarque :** nous vous conseillons d'utiliser le [check OpenMetrics][1] du fait de son efficacité accrue et de sa prise en charge complète du format texte Prometheus. N'utilisez le check Prometheus que lorsque l'endpoint de métriques ne prend pas en charge un format texte. + ### Prérequis - Agent Datadog v7.27+ ou v6.27+ (pour les checks de pod) @@ -225,23 +231,51 @@ kubectl get services -o=jsonpath='{.items[?(@.metadata.annotations.prometheus\.i Une fois la fonctionnalité Prometheus Scrape activée, l'Agent Datadog recueille des métriques custom à partir de ces ressources. Si vous ne souhaitez pas recueillir de métriques custom à partir de ces ressources, vous pouvez supprimer cette annotation ou mettre à jour les règles Autodiscovery comme décrit dans la section [Configuration avancée](#configuration-avancee). +**Remarque** : l'activation de cette fonctionnalité sans configuration avancée peut entraîner une augmentation importante du nombre de métriques personnalisées, avec des conséquences sur la facturation. Consultez la [section de configuration avancée](#configuration-avancee) pour apprendre à limiter la collecte à un sous-ensemble de conteneurs/pods/services. + #### Configuration de base {{< tabs >}} +{{% tab "Operator Datadog" %}} + +Mettez à jour la configuration de votre opérateur Datadog pour inclure ce qui suit : + +{{< code-block lang="yaml" filename="datadog-agent.yaml" >}} +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + global: + credentials: + apiKey: + + features: + prometheusScrape: + enabled: true + enableServiceEndpoints: true +{{< /code-block >}} + +{{% k8s-operator-redeploy %}} + +{{% /tab %}} {{% tab "Helm" %}} -Ajoutez ce qui suit dans votre fichier `values.yaml` Helm : +Mettez à jour votre configuration Helm pour inclure ce qui suit : -```yaml +{{< code-block lang="yaml" filename="datadog-values.yaml" >}} datadog: # (...) prometheusScrape: enabled: true serviceEndpoints: true # (...) -``` +{{< /code-block >}} + +{{% k8s-helm-redeploy %}} + {{% /tab %}} -{{% tab "DaemonSet" %}} +{{% tab "Configuration manuelle (DaemonSet)" %}} Dans votre manifeste DaemonSet pour l'Agent, `daemonset.yaml`, ajoutez les variables d'environnement suivantes pour le conteneur de l'Agent : ```yaml @@ -255,7 +289,7 @@ Si l'Agent de cluster est activé, à l'intérieur de son manifeste `cluster-age - name: DD_PROMETHEUS_SCRAPE_ENABLED value: "true" - name: DD_PROMETHEUS_SCRAPE_SERVICE_ENDPOINTS - value: "true" + value: "true" ``` {{% /tab %}} @@ -273,81 +307,92 @@ Ces paramètres permettent de générer un check qui recueille toutes les métri #### Configuration avancée -{{< tabs >}} -{{% tab "Helm" %}} - -Vous pouvez définir des configurations de check OpenMetrics avancées ou des règles Autodiscovery personnalisées qui diffèrent des annotations Prometheus natives. Pour ce faire, utilisez le champ de configuration `additionalConfigs` du fichier `values.yaml`. +Vous pouvez configurer davantage la collecte de métriques (au-delà des annotations Prometheus natives) à l'aide du champ `additionalConfigs`. -`additionalConfigs` liste les structures contenant des configurations de check OpenMetrics et des règles Autodiscovery. +##### Configurations de checks OpenMetrics supplémentaires -Chaque [champ de configuration][1] pris en charge par le check OpenMetrics peut être transmis dans la liste des configurations. +Utilisez `additionalConfigs.configurations` pour définir des configurations de checks OpenMetrics supplémentaires. Consultez la [liste des paramètres OpenMetrics pris en charge][15] que vous pouvez passer via `additionalConfigs`. -La configuration Autodiscovery peut reposer sur des noms de conteneur, des annotations Kubernetes ou un mélange des deux. Si vous définissez `kubernetes_container_names` et `kubernetes_annotations`, une logique d'addition (AND) s'applique, à savoir que les deux règles doivent être respectées. +##### Règles personnalisées d'Autodiscovery -`kubernetes_container_names` liste les noms de conteneur à cibler. Le wildcard `*` peut être utilisé. +Utilisez `additionalConfigs.autodiscovery` pour définir des règles personnalisées d'Autodiscovery. Ces règles peuvent reposer sur les noms de conteneurs, les annotations Kubernetes, ou les deux. -`kubernetes_annotations` contient deux maps d'annotations permettant de définir les règles de découverte : `include` et `exclude`. +`additionalConfigs.autodiscovery.kubernetes_container_names` +: Une liste de noms de conteneurs à cibler, au format expression régulière. -**Remarque** : dans la configuration de l'Agent Datadog, `kubernetes_annotations` a par défaut la valeur suivante : +`additionalConfigs.autodiscovery.kubernetes_annotations` +: Deux maps (`include` et `exclude`) d'annotations permettant de définir des règles de découverte. -```yaml -kubernetes_annotations: + Par défaut : + ```yaml include: prometheus.io/scrape: "true" exclude: prometheus.io/scrape: "false" -``` + ``` -**Exemple :** +Si `kubernetes_container_names` et `kubernetes_annotations` sont tous deux définis, une logique **ET** est appliquée (les deux règles doivent correspondre). -Dans l'exemple ci-dessous, nous définissons une configuration avancée ciblant un conteneur `my-app`, qui exécute un pod contenant l'annotation `app=my-app`. Nous personnalisons également la configuration du check OpenMetrics, en activant l'option `send_distribution_buckets` et en définissant un délai d'expiration personnalisé de cinq secondes. +##### Exemples -```yaml +La configuration suivante cible un conteneur nommé `my-app` exécuté dans un pod avec l'annotation `app=my-app`. La configuration du check OpenMetrics est personnalisée pour activer l'option `send_distribution_buckets` et définir un délai d'attente personnalisé de 5 secondes. + +{{< tabs >}} +{{% tab "Operator Datadog" %}} + +Mettez à jour la configuration de votre opérateur Datadog pour inclure ce qui suit : + +{{< code-block lang="yaml" filename="datadog-agent.yaml" >}} +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + global: + credentials: + apiKey: + + features: + prometheusScrape: + enabled: true + enableServiceEndpoints: true + additionalConfigs: |- + - autodiscovery: + kubernetes_container_names: + - my-app + kubernetes_annotations: + include: + app: my-app + configurations: + - timeout: 5 + send_distribution_buckets: true +{{< /code-block >}} + +{{% /tab %}} +{{% tab "Helm" %}} + +{{< code-block lang="yaml" filename="datadog-values.yaml" >}} datadog: # (...) prometheusScrape: enabled: true serviceEndpoints: true additionalConfigs: - - - configurations: - - timeout: 5 - send_distribution_buckets: true - autodiscovery: + - autodiscovery: kubernetes_container_names: - my-app kubernetes_annotations: include: app: my-app -``` - + configurations: + - timeout: 5 + send_distribution_buckets: true -[1]: https://github.com/DataDog/integrations-core/blob/master/openmetrics/datadog_checks/openmetrics/data/conf.yaml.example +{{< /code-block >}} {{% /tab %}} -{{% tab "DaemonSet" %}} - -Vous pouvez définir des configurations de check OpenMetrics avancées ou des règles Autodiscovery personnalisées qui diffèrent des annotations Prometheus natives. Pour ce faire, utilisez la variable d'environnement `DD_PROMETHEUS_SCRAPE_CHECKS` dans les manifestes de l'Agent et de l'Agent de cluster. - -`DD_PROMETHEUS_SCRAPE_CHECKS` liste les structures contenant des configurations de check OpenMetrics et des règles Autodiscovery. - -Chaque [champ de configuration][1] pris en charge par le check OpenMetrics peut être transmis dans la liste des configurations. - -La configuration Autodiscovery peut reposer sur des noms de conteneur, des annotations Kubernetes ou un mélange des deux. Si vous définissez `kubernetes_container_names` et `kubernetes_annotations`, une logique d'addition (AND) s'applique, à savoir que les deux règles doivent être respectées. - -`kubernetes_container_names` liste les noms de conteneur à cibler. Le wildcard `*` peut être utilisé. - -`kubernetes_annotations` contient deux maps d'annotations permettant de définir les règles de découverte : `include` et `exclude`. - -**Remarque** : dans la configuration de l'Agent Datadog, `kubernetes_annotations` a par défaut la valeur suivante : - -```yaml -- name: DD_PROMETHEUS_SCRAPE_CHECKS - value: "[{\"autodiscovery\":{\"kubernetes_annotations\":{\"exclude\":{\"prometheus.io/scrape\":\"false\"},\"include\":{\"prometheus.io/scrape\":\"true\"}}}}]" -``` - -**Exemple :** +{{% tab "Manual (DaemonSet)" %}} -Dans l'exemple ci-dessous, nous définissons une configuration avancée ciblant un conteneur `my-app`, qui exécute un pod contenant l'annotation `app=my-app`. Nous personnalisons également la configuration du check OpenMetrics, en activant l'option `send_distribution_buckets` et en définissant un délai d'expiration personnalisé de cinq secondes. +Pour DaemonSet, la configuration avancée se définit dans la variable d'environnement `DD_PROMETHEUS_SCRAPE_CHECKS`, et non dans un champ `additionalConfigs`. ```yaml - name: DD_PROMETHEUS_SCRAPE_ENABLED @@ -360,6 +405,7 @@ Dans l'exemple ci-dessous, nous définissons une configuration avancée ciblant [1]: https://github.com/DataDog/integrations-core/blob/master/openmetrics/datadog_checks/openmetrics/data/conf.yaml.example +[2]: https://github.com/DataDog/datadog-agent/blob/main/comp/core/autodiscovery/common/types/prometheus.go#L99-L123 {{% /tab %}} {{< /tabs >}} @@ -382,8 +428,10 @@ Les intégrations officielles utilisent des répertoires dédiés. Le check gén [7]: /fr/agent/kubernetes/#installation [8]: /fr/getting_started/tagging/ [9]: https://github.com/DataDog/integrations-core/blob/master/openmetrics/datadog_checks/openmetrics/data/conf.yaml.example -[10]: https://app.datadoghq.com/account/settings#agent/kubernetes +[10]: https://app.datadoghq.com/account/settings/agent/latest?platform=kubernetes [11]: /resources/yaml/prometheus.yaml [12]: https://app.datadoghq.com/metric/summary [13]: /fr/agent/faq/template_variables/ -[14]: https://github.com/DataDog/integrations-core/tree/master/kube_proxy \ No newline at end of file +[14]: https://github.com/DataDog/integrations-core/tree/master/kube_proxy +[15]: https://github.com/DataDog/datadog-agent/blob/main/comp/core/autodiscovery/common/types/prometheus.go#L57-L123 +[16]: https://app.datadoghq.com/fleet?query=integration:openmetrics \ No newline at end of file diff --git a/content/fr/dora_metrics/_index.md b/content/fr/dora_metrics/_index.md new file mode 100644 index 0000000000000..3e3c9c3374b47 --- /dev/null +++ b/content/fr/dora_metrics/_index.md @@ -0,0 +1,101 @@ +--- +aliases: +- /fr/continuous_integration/dora_metrics +description: Découvrez comment utiliser les métriques DORA pour mesurer et améliorer + les processus de livraison logicielle de votre organisation. +further_reading: +- 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). +- link: https://www.datadoghq.com/blog/dora-metrics-software-delivery/ + tag: Blog + text: Bonnes pratiques pour utiliser les métriques DORA afin d’améliorer la livraison + logicielle +- link: https://www.datadoghq.com/blog/datadog-dora-metrics/ + tag: Blog + text: 3 façons de favoriser la réussite de la livraison logicielle avec les métriques + DORA de Datadog +- link: /continuous_delivery/deployments + tag: Documentation + text: En savoir plus sur Deployment Visibility +- link: /service_management/events + tag: Documentation + text: En savoir plus Event Management +- link: /monitors/types/metric + tag: Documentation + text: En savoir plus sur les monitors de métriques +- link: /software_catalog + tag: Documentation + text: En savoir plus sur le Software Catalog +is_beta: true +title: Métriques DORA +--- + +## Section Overview + +Les métriques DORA (DevOps Research and Assessment) sont [quatre métriques clés][1] qui indiquent la vélocité et la stabilité du développement logiciel. + +Deployment frequency (Fréquence de déploiement) +: Fréquence à laquelle une organisation effectue des mises en production réussies. + +Change lead time (Délai de changement) +: Temps nécessaire pour qu'un commit soit mis en production. + +Change failure rate (Taux d'échec de changement) +: Pourcentage de déploiements entraînant une défaillance en production. + +Time to restore service (Temps de restauration du service) +: Durée nécessaire à une organisation pour se remettre d'une défaillance en production. + +Définir et suivre les métriques DORA peut vous aider à identifier les axes d'amélioration de la rapidité et de la qualité de livraison logicielle de votre équipe ou de votre organisation. + +## Configurer les métriques DORA + +Pour commencer à configurer les sources de données afin d'envoyer les événements de déploiement et d'échec vers Datadog, consultez la [documentation relative à la configuration][2]. + +## Analyser les métriques DORA + +Une fois les sources de données configurées pour vos événements de déploiement et d'échec, rendez-vous dans [Software Delivery > DORA Metrics][4] pour identifier les améliorations ou régressions de chaque métrique. Vous pouvez également agréger les métriques par équipe, service, référentiel, environnement, période et [tags custom][8] pour comparer les tendances dans le temps. + +{{< img src="dora_metrics/dora_ui_3.png" alt="Vue d'ensemble des calculs des métriques DORA filtrés par le tag custom Language" style="width:100%;" >}} + +Cliquez sur **View Deployments** pour ouvrir un nouvel onglet affichant les métriques Deployment Frequency et Change Lead Time, ainsi qu'une liste des événements de déploiement. + +{{< img src="dora_metrics/deployments_list.png" alt="La répartition des déploiements affichant un détail des métriques ainsi qu'une liste des événements associés" style="width:100%;" >}} + +Cliquez sur **View Failures** pour ouvrir un panneau latéral affichant les métriques Change Failure Rate et Time To Restore, ainsi qu'une liste des événements d'échec. + +{{< img src="dora_metrics/failures_list.png" alt="La répartition des échecs affichant un détail des métriques ainsi qu'une liste des événements associés" style="width:100%;" >}} + +## Utiliser les données des métriques DORA + +### Exporter les widgets des métriques DORA +Exportez vos widgets de visualisation vers des dashboards, des notebooks, ou ajoutez-les à des incidents existants. + +{{< img src="dora_metrics/dora_ui_2.png" alt="Cliquez sur l'icône Exporter pour ajouter le widget de visualisation à un incident, un dashboard ou un notebook." style="width:100%;" >}} + +Cliquez sur l'icône **Export** de n'importe quelle visualisation pour l'ajouter à un incident, un dashboard ou un notebook. Pour en savoir plus sur les métriques calculées par les métriques DORA, consultez la [documentation relative aux données collectées][3]. + +### Créer des dashboards personnalisés + +Les métriques DORA sont très flexibles et peuvent être utilisées dans des dashboards customisés pour répondre aux besoins spécifiques de votre équipe. + +{{< img src="dora_metrics/dashboard.png" alt="Exemple de dashboard personnalisé pour les métriques DORA" style="width:100%;" >}} + +Dans les dashboards et graphiques, les tags custom sont traités comme des [attributs][7]. Pour filtrer ou regrouper par tag custom, celui-ci doit être précédé du symbole @. + +{{< img src="dora_metrics/graph_with_custom_tag.png" alt="Exemple de graphique personnalisé des métriques DORA regroupé par un tag custom" style="width:100%;" >}} + +## Pour aller plus loin + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://www.datadoghq.com/knowledge-center/dora-metrics/ +[2]: /fr/dora_metrics/setup/ +[3]: /fr/dora_metrics/data_collected/ +[4]: https://app.datadoghq.com/ci/dora +[5]: /fr/monitors/types/metric/?tab=threshold +[6]: /fr/monitors/ +[7]: /fr/dashboards/guide/quick-graphs/#graphing-events +[8]: /fr/dora_metrics/data_collected/#custom-tags \ No newline at end of file diff --git a/content/fr/getting_started/integrations/_index.md b/content/fr/getting_started/integrations/_index.md index f067225ba4cd2..29596fff7a8bb 100644 --- a/content/fr/getting_started/integrations/_index.md +++ b/content/fr/getting_started/integrations/_index.md @@ -9,7 +9,7 @@ further_reading: title: Présentation des intégrations --- -## Présentation +## Section Overview Ce guide décrit comment utiliser les intégrations. Si vous souhaitez découvrir comment créer une nouvelle intégration, consultez la page [Créer une nouvelle intégration][1]. @@ -31,7 +31,7 @@ Le package de l'Agent Datadog inclut les intégrations officiellement prises en ### Autorisations -L'autorisation `manage_integrations` est requise pour interagir avec un carré dʼintégration. Consultez la section relative aux [rôles RBAC][45] pour en savoir plus. +La permission Integrations Manage (Gestion des intégrations) est requise pour interagir avec un carré d'intégration. Consultez la section relative aux [rôles RBAC][45] pour en savoir plus. ### Clés d'API et d'application @@ -100,13 +100,26 @@ Par exemple, il est conseillé d'utiliser `service` pour la [configuration de l' Pour mieux unifier votre environnement, il est également recommandé de configurer le tag `env` dans l'Agent. Pour en savoir plus, consultez la section relative au [tagging de service unifié][27]. -Par défaut, les métriques transmises par les intégrations comprennent des tags découverts automatiquement dans l'environnement. Par exemple, les métriques transmises par un check Redis exécuté à l'intérieur d'un conteneur comprennent des tags associés au conteneur, tels que `image_name`. Vous pouvez désactiver ce comportement en définissant le paramètre `ignore_autodiscovery_tags` sur `true` : +#### Configuration des tags par check +Vous pouvez personnaliser le comportement des tags pour chaque check, en remplaçant les paramètres globaux définis au niveau de l'Agent : + +1. **Désactiver les balises Autodiscovery** + + Par défaut, les métriques transmises par les intégrations comprennent des tags découverts automatiquement dans l'environnement. Par exemple, les métriques transmises par un check Redis exécuté à l'intérieur d'un conteneur comprennent des tags associés au conteneur, tels que `image_name`. Vous pouvez désactiver ce comportement en définissant le paramètre `ignore_autodiscovery_tags` sur `true`. + +1. **Définir la cardinalité des tags par check d'intégration** + + Vous pouvez définir le niveau de cardinalité des tags (low, orchestrator ou high) pour chaque check individuellement à l'aide du paramètre `check_tag_cardinality`. Cela remplace le paramètre global de cardinalité des tags défini dans la configuration de l'Agent. + ```yaml init_config: - +# Ignore les tags provenant de l'autodécouverte ignore_autodiscovery_tags: true -# Insérer le reste de la configuration ici +# Remplace le paramètre global de cardinalité des tag +check_tag_cardinality: low + +# Le reste de la configuration ici ``` ### Validation @@ -123,16 +136,41 @@ Si vous avez configuré la [collecte de processus][29], Datadog détecte automat {{< img src="getting_started/integrations/ad_integrations_1.png" alt="Intégrations détectées automatiquement" >}} -Chaque intégration possède l'un des trois statuts suivants : +Chaque intégration possède l'un des quatre types de statut suivants : - **Detected** : la technologie s'exécute sur un host, mais l'intégration n'a pas été installée ou configurée. Pour cette raison, seule une partie des métriques est recueillie. Configurez l'intégration pour en profiter pleinement. Pour obtenir la liste des hosts qui exécutent une technologie détectée automatiquement, ouvrez le carré de l'intégration, puis sélectionnez l'onglet **Hosts**. - **Installed** : l'intégration est installée et configurée sur un host. - **Available** : cette catégorie rassemble toutes les intégrations qui ne possèdent pas le statut **Installed** ni **Detected**. +- **Données manquantes** : aucune métrique d'intégration n'a été détectée au cours des dernières 24 heures. ## Mesures de sécurité Pour en savoir plus sur la manière dont Datadog traite vos données et sur d'autres aspects de la sécurité, consultez notre [documentation dédiée][30]. +## Contrôle d'accès granulaire +Par défaut, l'accès aux ressources d'intégration (comptes, services, webhooks) est illimité. Des contrôles d'accès granulaires peuvent être utilisés pour restreindre le comportement des utilisateurs, équipes, rôles ou de l'ensemble de votre organisation au niveau des ressources d'intégration. + +**Remarque** : l'option d'accès restreint n'est visible que si l'intégration prend en charge les contrôles d'accès granulaires. Pour vérifier si une intégration prend en charge les contrôles d'accès granulaires, consultez la [documentation relative à cette intégration][46].{{< img src="getting_started/integrations/GRACE integration-account-modal.png" alt="Contrôles d'accès granulaires" style="width:70%;" >}} + +1. Lorsque vous consultez une intégration, accédez à l'onglet **Configure** et repérez la ressource (compte, service, webhook) à laquelle appliquer des contrôles d'accès granulaires. +2. Cliquez sur **Set Permissions**. +3. Par défaut, tous les membres de votre organisation ont un accès complet. Cliquez sur **Restrict Access**. +4. La boîte de dialogue affiche alors les membres de votre organisation disposant de l'autorisation **Viewer** par défaut. +5. Utilisez le menu déroulant pour sélectionner un ou plusieurs rôles, équipes ou utilisateurs autorisés à modifier le monitor. + **Remarque** : la permission [Integrations Manage][45] est également requise pour modifier des ressources individuelles. +6. Cliquez sur **Add**. +7. La boîte de dialogue se met à jour pour afficher les autorisations mises à jour. +8. Cliquez sur **Save**. La page d'intégration s'actualise automatiquement avec les autorisations mises à jour. + +**Remarque** : afin de toujours pouvoir modifier la ressource, vous devez inclure au moins un de vos rôles ou une de vos équipes avant d'enregistrer vos modifications. + +Pour rétablir l'accès général à une ressource d'intégration restreinte, procédez comme suit : + +1. Depuis l'écran de l'intégration, accédez à l'onglet **Configure** et localisez la ressource (compte, service, webhook) dont l'accès général doit être rétabli. +2. Cliquez sur **Set Permissions**. +3. Cliquez sur **Restore Full Access**. +4. Cliquez sur **Save**. La page d'intégration s'actualise automatiquement avec les autorisations mises à jour. + ## Et ensuite ? Maintenant que votre première intégration est configurée, [explorez toutes les métriques][31] envoyées par votre application à Datadog et utilisez ces métriques pour configurer des [dashboards][32] et des [alertes][33] afin de surveiller vos données. @@ -230,4 +268,5 @@ Tags [42]: /fr/metrics/ [43]: /fr/metrics/custom_metrics/ [44]: /fr/monitors/guide/visualize-your-service-check-in-the-datadog-ui/ -[45]: /fr/account_management/rbac/permissions/#integrations \ No newline at end of file +[45]: /fr/account_management/rbac/permissions/#integrations +[46]: /fr/integrations/ \ No newline at end of file diff --git a/content/fr/getting_started/logs/_index.md b/content/fr/getting_started/logs/_index.md index fcd5951fcfb26..b5cad08b1181d 100644 --- a/content/fr/getting_started/logs/_index.md +++ b/content/fr/getting_started/logs/_index.md @@ -6,9 +6,18 @@ further_reading: - link: https://learn.datadoghq.com/courses/going-deeper-with-logs-processing tag: Centre d'apprentissage text: Des analyses plus poussées grâce au traitement des logs +- link: https://learn.datadoghq.com/courses/log-indexes + tag: Centre d'apprentissage + text: Gérer et surveiller les volumes de logs indexés +- link: https://learn.datadoghq.com/courses/log-pipelines + tag: Centre d'apprentissage + text: Créer et gérer des pipelines de logs +- link: https://learn.datadoghq.com/courses/integration-pipelines + tag: Centre d'apprentissage + text: Traiter les logs automatiquement avec les pipelines d'intégration - link: /logs/log_collection/ tag: Documentation - text: Collecte de logs et intégrations + text: Collecte de log et intégrations - link: /getting_started/tagging/unified_service_tagging tag: Documentation text: Apprendre à configurer le tagging de service unifié @@ -18,7 +27,7 @@ further_reading: title: Débuter avec les logs --- -## Présentation +## Section Overview Utilisez la fonction Datadog Log Management, également appelée logs, pour recueillir les logs issus de plusieurs sources de journalisation, comme votre serveur, votre conteneur, votre environnement Cloud, votre application ou vos processeurs et forwarders de logs existants. Avec un système de journalisation conventionnel, vous devez choisir les logs à analyser et à conserver afin de limiter les coûts. La fonctionnalité Logging without Limits* de Datadog vous permet de recueillir, traiter, archiver, explorer et surveiller vos logs sans limites de journalisation. @@ -59,7 +68,7 @@ Pour commencer à recueillir des logs à partir d'un serveur : **Remarque** : si vous recueillez des logs à partir de fichiers personnalisés et avez besoin d'exemples pour les fichiers suivis, TCP/UDP, journald ou événements Windows, consultez la section [Collecte de logs personnalisés][9]. -### Container +### Conteneur À partir de l'Agent Datadog v6, l'Agent peut recueillir des logs à partir de conteneurs. Chaque service de conteneurisation dispose d'instructions de configuration spécifiques en fonction de l'emplacement où l'Agent est déployé ou exécuté, ou encore de l'acheminement des logs. @@ -95,13 +104,13 @@ Pour commencer à recueillir des logs à partir d'un service cloud, suivez les [ Une fois qu'une source de journalisation est configurée, vos logs sont disponibles dans le [Log Explorer][16]. Cet explorateur vous permet de filtrer, d'agréger et de consulter vos logs. -Par exemple, si vous souhaitez analyser en détail les logs d'un service donné, filtrez vos logs en fonction de `service`. Vous pouvez ensuite les filtrer en fonction de `status`, comme `ERROR`, puis sélectionner [Aggregate by Patterns][17] pour voir la partie de votre service qui génère le plus d'erreurs. +Par exemple, si vous souhaitez analyser en détail les logs d'un service donné, filtrez vos logs en fonction de `service`. Vous pouvez ensuite les filtrer en fonction de `status`, comme `ERROR`, puis sélectionner [Group into Patterns][17] pour voir la partie de votre service qui génère le plus d'erreurs. -{{< img src="/getting_started/logs/error-pattern.png" alt="Filtrage dans le Log Explorer par pattern d'erreur">}} +{{< img src="/getting_started/logs/error-pattern-2024.png" alt="Filtrage dans le Log Explorer par pattern d'erreur">}} -Agrégez vos logs en fonction du paramètre `Field` de `Source` et passez à l'option de visualisation **Top List** pour voir vos services qui génèrent le plus de logs. Sélectionnez une source, comme `error`, et sélectionnez **View Logs** dans le menu déroulant. Le volet latéral affiche des logs en fonction des erreurs, ce qui vous permet d'identifier rapidement les hosts et services qui nécessitent votre attention. +Agrégerez vos logs dans des `Fields` (champs) et affichez-les sous forme de **Top List** pour identifier vos services les plus bavards. Sélectionnez une source comme `info` ou `warn`, puis choisissez **View Logs** dans le menu déroulant. Le panneau latéral affiche alors les logs classés par erreur, ce qui vous permet d'identifier rapidement les hosts et services à surveiller. -{{< img src="/getting_started/logs/top-list-view.png" alt="Affichage Top List dans le Log Explorer">}} +{{< img src="/getting_started/logs/top-list-view-2024.png" alt="Affichage Top List dans le Log Explorer">}} ## Et ensuite ? @@ -111,7 +120,7 @@ Une fois qu'une source de journalisation est configurée et que vos logs sont di * Définissez des [attributs et alias][18] afin d'unifier votre environnement de logs. * Contrôlez le traitement de vos logs avec des [pipelines][19] et [processeurs][20]. -* Étant donné que la fonctionnalité Logging without Limits* dissocie l'ingestion et l'indexation de logs, vous pouvez [configurer vos logs][21] de façon à choisir ceux que vous souhaitez indexer, conserver ou archiver. +* Grâce à Logging without Limits*, qui dissocie l'ingestion de l'indexation, vous pouvez [configurer vos logs][21] et choisir ceux à [indexer][22], [conserver][23] ou [archiver][24]. ### Mise en corrélation des logs @@ -120,9 +129,9 @@ Une fois qu'une source de journalisation est configurée et que vos logs sont di ### Guides -* [Meilleures pratiques pour la solution Log Management][22] -* Explorer en détail la fonctionnalité [Logging without Limits*][23] -* Gérer les données de log sensibles avec les [réglages RBAC][24] +* [Bonnes pratiques de gestion des logs][25] +* Explorer en détail la fonctionnalité [Logging without Limits*][26] +* Gérer les données sensibles avec les [paramètres RBAC][27] ## Pour aller plus loin @@ -137,7 +146,7 @@ Une fois qu'une source de journalisation est configurée et que vos logs sont di [4]: /fr/security/cloud_siem/ [5]: /fr/getting_started/integrations/ [6]: /fr/agent/ -[7]: https://github.com/DataDog/datadog-agent/blob/main/docs/agent/changes.md#cli +[7]: /fr/agent/configuration/agent-commands/#restart-the-agent [8]: https://app.datadoghq.com/logs/onboarding/server [9]: /fr/agent/logs/?tab=tailfiles#custom-log-collection [10]: /fr/agent/docker/log/?tab=containerinstallation @@ -147,11 +156,14 @@ Une fois qu'une source de journalisation est configurée et que vos logs sont di [14]: https://app.datadoghq.com/logs/onboarding/client [15]: https://app.datadoghq.com/logs/onboarding/other [16]: /fr/logs/explorer/ -[17]: /fr/logs/explorer/#patterns +[17]: /fr/logs/explorer/analytics/patterns/ [18]: /fr/logs/log_configuration/attributes_naming_convention/ [19]: /fr/logs/log_configuration/pipelines/ [20]: /fr/logs/log_configuration/processors/ [21]: /fr/logs/log_configuration/ -[22]: /fr/logs/guide/best-practices-for-log-management/ -[23]: /fr/logs/guide/getting-started-lwl/ -[24]: /fr/logs/guide/logs-rbac/ \ No newline at end of file +[22]: https://docs.datadoghq.com/fr/logs/log_configuration/indexes +[23]: https://docs.datadoghq.com/fr/logs/log_configuration/flex_logs +[24]: https://docs.datadoghq.com/fr/logs/log_configuration/archives +[25]: /fr/logs/guide/best-practices-for-log-management/ +[26]: /fr/logs/guide/getting-started-lwl/ +[27]: /fr/logs/guide/logs-rbac/ \ No newline at end of file diff --git a/content/fr/integrations/google_cloud_platform.md b/content/fr/integrations/google_cloud_platform.md index ed148d23bfc65..60507d4ea6743 100644 --- a/content/fr/integrations/google_cloud_platform.md +++ b/content/fr/integrations/google_cloud_platform.md @@ -1,6 +1,27 @@ --- -aliases: -- /fr/integrations/gcp/ +app_id: google-cloud-platform +app_uuid: 8516e126-1eac-45e5-8e34-ff43db45f362 +assets: + dashboards: + gce: assets/dashboards/gce.json + gcp_overview: assets/dashboards/gcp_overview.json + integration: + auto_install: false + events: + creates_events: true + metrics: + check: gcp.gce.instance.cpu.utilization + metadata_path: metadata.csv + prefix: gcp + service_checks: + metadata_path: assets/service_checks.json + source_type_id: 61 + source_type_name: Google Cloud Platform +author: + homepage: https://www.datadoghq.com + name: Datadog + sales_email: info@datadoghq.com + support_email: help@datadoghq.com categories: - cloud - google cloud @@ -9,58 +30,76 @@ categories: - network custom_kind: integration dependencies: [] -description: Recueillez une multitude de métriques GCP et visualisez vos instances - sur une host map. -doc_link: https://docs.datadoghq.com/integrations/google_cloud_platform/ +display_on_public_website: true draft: false -further_reading: -- link: https://www.datadoghq.com/blog/cspm-for-gcp-with-datadog/ - tag: Blog - text: Améliorez la conformité et la sécurité de votre environnement Google Cloud - avec Datadog -- link: https://www.datadoghq.com/blog/google-cloud-vertex-ai-monitoring-datadog/ - tag: Blog - text: Surveiller Google Cloud Vertex AI avec Datadog -- link: https://www.datadoghq.com/blog/monitor-dataflow-pipelines-with-datadog/ - tag: Blog - text: Surveiller des pipelines Dataflow avec Datadog -- link: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/integration_gcp_sts - tag: Terraform - text: Créer et gérer votre intégration Google Cloud avec Terraform -- link: https://www.datadoghq.com/blog/track-bigquery-costs-performance/ - tag: Blog - text: Surveiller BigQuery avec Datadog git_integration_title: google_cloud_platform -has_logo: true integration_id: google-cloud-platform integration_title: Google Cloud Platform integration_version: '' is_public: true -manifest_version: '1.0' +manifest_version: 2.0.0 name: google_cloud_platform -public_title: Intégration Datadog/Google Cloud Platform -short_description: Recueillez une multitude de métriques GCP et visualisez vos instances - sur une host map. -version: '1.0' +public_title: Google Cloud Platform +short_description: Google Cloud Platform est un ensemble de services web qui constituent + une plateforme d'informatique en nuage. +supported_os: [] +tile: + changelog: CHANGELOG.md + classifier_tags: + - Category::Cloud + - Category::Google Cloud + - Category::IoT + - Category::Log Collection + - Category::Network + - Offering::Intégration + configuration: README.md#Setup + description: Google Cloud Platform est un ensemble de services web qui constituent + une plateforme d'informatique en nuage. + media: [] + overview: README.md#Overview + resources: + - resource_type: blog + url: https://www.datadoghq.com/blog/cspm-for-gcp-with-datadog/ + - resource_type: blog + url: https://www.datadoghq.com/blog/google-cloud-vertex-ai-monitoring-datadog/ + - resource_type: blog + url: https://www.datadoghq.com/blog/monitor-dataflow-pipelines-with-datadog/ + - resource_type: autres + url: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/integration_gcp_sts + - resource_type: blog + url: https://www.datadoghq.com/blog/track-bigquery-costs-performance/ + - resource_type: blog + url: https://www.datadoghq.com/blog/recent-changes-tab/ + support: README.md#Support + title: Google Cloud Platform --- - -## Présentation + + +{{< site-region region="gov" >}} +
L'usurpation de compte de service n'est pas disponible pour le site Datadog sélectionné ({{< region-param key="dd_site_name" >}})
+{{< /site-region >}} -Associez votre solution Google Cloud Platform pour visualiser tous vos hosts Google Compute Engine (GCE) dans Datadog. Vos hosts apparaissent dans l'aperçu de l'infrastructure de Datadog. Vous pouvez les trier grâce aux tags de host GCE et aux libellés GCE qui leur sont automatiquement attribués par Datadog. +## Vue d'ensemble + +Utilisez ce guide pour commencer à surveiller votre environnement Google Cloud. Cette approche simplifie la configuration des environnements Google Cloud comportant plusieurs projets, vous permettant de maximiser votre couverture de surveillance. + +{{% collapse-content title="Voir la liste complète des intégrations Google Cloud" level="h4" %}}
-L'intégration GCP de Datadog est conçue pour recueillir toutes les métriques Google Cloud. Datadog s'efforce de mettre régulièrement à jour sa documentation afin d'inclure chaque sous-intégration. Toutefois, les métriques et les services proposés par les différents services cloud étant en permanente évolution, il est possible que la liste ne soit pas à jour. +L'intégration Google Cloud de Datadog collecte toutes les métriques Google Cloud. Datadog met régulièrement à jour la documentation pour répertorier chaque intégration dépendante, mais cette liste peut ne pas refléter les derniers services ou métriques disponibles. + + Si vous ne voyez pas d'intégration pour un service Google Cloud spécifique, contactez l'assistance Datadog.
-| Intégration | Description | +| Intégration | Rôle | |-------------------------------------|---------------------------------------------------------------------------------------| | [App Engine][1] | PaaS (plateforme en tant que service) permettant de développer des applications évolutives | -| [Big Query][2] | Entrepôt de données pour entreprise | +| [BigQuery][2] | Entrepôt de données pour entreprise | | [Bigtable][3] | Service de base de données Big Data NoSQL | | [Cloud SQL][4] | Service de base de données MySQL | | [API Cloud][5] | Interfaces de programmation pour tous les services Google Cloud Platform | -| [Cloud Armor][6] | Service de sécurité sur le réseau protégeant contre le déni de service et les attaques web | +| [Cloud Armor][6] | Service de sécurité réseau conçu pour protéger contre les attaques par déni de service et les attaques web | | [Cloud Composer][7] | Service d'orchestration de workflows entièrement géré | | [Cloud Dataproc][8] | Service cloud permettant d'exécuter des clusters Apache Spark et Apache Hadoop | | [Cloud Dataflow][9] | Un service entièrement géré pour la transformation et l'enrichissement des données en mode flux et en mode batch. | @@ -73,7 +112,7 @@ L'intégration GCP de Datadog est conçue pour recueillir }} +{{% tab "Org- and Folder-level project discovery" %}} + + {{< site-region region="gov" >}} +La collecte de métriques au niveau de l'organisation n'est pas disponible pour le site {{< region-param key="dd_site_name" >}}. +{{< /site-region >}} + + + +{{< site-region region="us,us3,us5,eu,ap1" >}} +Une surveillance au niveau de l'organisation (ou du dossier) est recommandée pour assurer une couverture complète de tous les projets, y compris les projets futurs qui pourraient être créés dans l'organisation ou le dossier. + +**Remarque** : votre compte utilisateur [Google Cloud Identity][408] doit disposer du rôle `Admin` assigné à la portée souhaitée (par exemple, `Organization Admin`) pour effectuer la configuration dans Google Cloud. + +{{% collapse-content title="1. Créer un compte de service Google Cloud dans le projet par défaut" level="h5" %}} +1. Ouvrez votre [console Google Cloud][401]. +2. Accédez à **IAM & Admin** > **Service Accounts**. +3. Cliquez sur **Create service account** en haut de la page. +4. Saisissez un nom unique pour le compte de service. +5. Cliquez sur **Done** pour finaliser la création du compte de service. + +[401]: https://console.cloud.google.com/ +{{% /collapse-content %}} + +{{% collapse-content title="2. Ajouter le compte de service au niveau de l'organisation ou d'un dossier" level="h5" %}} +1. Dans la console Google Cloud, accédez à la page **IAM**. +2. Sélectionnez un dossier ou une organisation. +3. Pour attribuer un rôle à un service principal qui ne possède pas encore de rôle pour la ressource, cliquez sur **Grant Access**, puis saisissez l'adresse e-mail du compte de service créé précédemment. +4. Saisissez l'adresse e-mail du compte de service. +5. Attribuez les rôles suivants : + - [Compute Viewer][402] : fournit un accès **en lecture seule** pour obtenir et lister les ressources Compute Engine + - [Monitoring Viewer][403] : fournit un accès **en lecture seule** aux données de monitoring disponibles dans votre environnement Google Cloud + - [Cloud Asset Viewer][404] : fournit un accès **en lecture seule** aux métadonnées des ressources cloud + - [Browser][405] : fournit un accès **en lecture seule** à la hiérarchie d'un projet + - [Service Usage Consumer][406] (**optionnel**, pour les environnements multi-projets) : fournit l'[attribution des coûts et quotas d'API par projet](#attribution-des-couts-et-quotas-d-api-par-projet) après activation par l'assistance Datadog +6. Cliquez sur **Save**. + +**Remarque** : le rôle `Browser` est requis uniquement dans le projet par défaut du compte de service. Les autres projets nécessitent uniquement les autres rôles listés. + +[402]: https://cloud.google.com/compute/docs/access/iam#compute.viewer +[403]: https://cloud.google.com/monitoring/access-control#monitoring_roles +[404]: https://cloud.google.com/iam/docs/understanding-roles#cloudasset.viewer +[405]: https://cloud.google.com/resource-manager/docs/access-control-proj#browser +[406]: https://cloud.google.com/service-usage/docs/access-control#serviceusage.serviceUsageConsumer +{{% /collapse-content %}} + +{{% collapse-content title="3. Ajouter le principal Datadog à votre compte de service" level="h5" %}} +**Remarque** : si vous avez précédemment configuré l'accès à l'aide d'un principal Datadog partagé, vous pouvez révoquer cette autorisation une fois les étapes suivantes terminées. + +1. Dans Datadog, accédez à **Integrations** > [**Google Cloud Platform**][407]. +2. Cliquez sur **Add Google Cloud Account**. +Si aucun projet n'est encore configuré, vous serez automatiquement redirigé vers cette page. +3. Copiez votre service principal Datadog et conservez-le pour la prochaine section. + +{{< img src="integrations/google_cloud_platform/principal-2.png" alt="La page permettant d'ajouter un nouveau compte Google Cloud dans le carré d'intégration Google Cloud de Datadog" style="width:70%;">}} + +**Remarque** : gardez cette fenêtre ouverte pour la section 4. + +4. Dans la [console Google Cloud][409], dans le menu **Service Accounts**, recherchez le compte de service que vous avez créé à l'étape 1.  +5. Allez dans l'onglet **Permissions** et cliquez sur **Grant Access**. + +{{< img src="integrations/google_cloud_platform/grant-access.png" alt="Interface de la console Google Cloud, avec l'onglet Permissions sous Service Accounts." style="width:70%;">}} + +6. Collez votre service principal Datadog dans la zone **New Principals**. +7. Attribuez le rôle **Service Account Token Creator**. +8. Cliquez sur **Save**. + +[407]: https://app.datadoghq.com/integrations/google-cloud-platform +[409]: https://console.cloud.google.com/ +{{% /collapse-content %}} + +{{% collapse-content title="4. Finaliser la configuration de l'intégration dans Datadog" level="h5" %}} +1. Dans la console Google Cloud, accédez à l'onglet **Details** du **Service Account**. Sur cette page, trouvez l'adresse email associée à ce compte de service Google. Elle suit le format `@.iam.gserviceaccount.com`. +2. Copiez cette adresse e-mail. +3. Revenez sur le carré de configuration de l'intégration dans Datadog (là où vous avez copié le principal Datadog lors de la section précédente). +4. Collez l'adresse email copiée dans le champ **Add Service Account Email**. +5. Cliquez sur **Verify and Save Account**. +{{% /collapse-content %}} + +Les métriques apparaissent dans Datadog environ **15 minutes** après la configuration. + +[408]: https://cloud.google.com/identity/docs/overview +{{< /site-region >}} -L'intégration Google Cloud/Datadog pour le site {{< region-param key="dd_site_name" >}} utilise des comptes de service pour créer une connexion API entre Google Cloud et Datadog. Vous trouverez ci-dessous les instructions à suivre pour créer un compte de service et fournir à Datadog les identifiants du compte de service afin de commencer à effectuer des appels d'API en votre nom. -La fonctionnalité [dʼemprunt d'identité de compte de service][209] n'est pas disponible pour le site {{< region-param key="dd_site_name" >}}. +#### Bonnes pratiques pour la surveillance de plusieurs projets + +##### Activer l'attribution des coûts et quotas d'API par projet + +Par défaut, Google Cloud attribue les coûts liés aux appels d'API de monitoring ainsi que l'utilisation des quotas d'API au projet contenant le compte de service utilisé pour cette intégration. Dans les environnements Google Cloud comportant plusieurs projets, il est recommandé d'activer l'attribution des coûts et des quotas par projet. Lorsque cette option est activée, les coûts et l'utilisation des quotas sont attribués au projet *interrogé*, plutôt qu'au projet contenant le compte de service. Cela permet d'obtenir une meilleure visibilité sur les coûts de monitoring générés par chaque projet, tout en contribuant à éviter d'atteindre les limites de quotas d'API. + +Pour activer cette fonctionnalité : +1. Assurez-vous que le compte de service Datadog dispose du rôle [Service Usage Consumer][1] à la portée souhaitée (dossier ou organisation). +2. Cliquez sur le bouton **Enable Per Project Quota** dans l'onglet **Projects** de la [page d'intégration Google Cloud][2]. + +[1]: https://cloud.google.com/service-usage/docs/access-control#serviceusage.serviceUsageConsumer +[2]: https://app.datadoghq.com/integrations/google-cloud-platform +{{% /tab %}} + +{{% tab "Project-level metric collection" %}} + + +{{< site-region region="gov" >}} +L'intégration Google Cloud de Datadog pour le site {{< region-param key="dd_site_name" >}} utilise des comptes de service pour établir une connexion API entre Google Cloud et Datadog. Suivez les instructions ci-dessous pour créer un compte de service et fournir à Datadog les identifiants nécessaires pour exécuter des appels API en votre nom. + +La fonctionnalité [dʼemprunt d'identité de compte de service][201] n'est pas disponible pour le site {{< region-param key="dd_site_name" >}}. **Remarque** : vous devez avoir activé [Google Cloud Billing][204], l'[API Cloud Monitoring][205], l'[API Compute Engine][206] et l'[API Cloud Asset][207] pour les projets que vous souhaitez surveiller. @@ -132,8 +288,8 @@ La fonctionnalité [dʼemprunt d'identité de compte de service][209] n'est pas - Cloud Asset Viewer 7. Cliquez sur **Done**. **Remarque** : vous devez être un administrateur clé de compte de service pour sélectionner les rôles Compute Engine et Cloud Asset. Tous les rôles sélectionnés permettent à Datadog de recueillir des métriques, des tags, des événements et des étiquettes dʼutilisateurs à votre place. -8. En bas de la page se trouvent vos comptes de service. Sélectionnez celui que vous venez de créer. -9. Cliquez sur **Add Key** -> **Create new key** et choisissez **JSON** comme type. +8. En bas de la page se trouvent vos comptes de service. Sélectionnez celui que vous venez de créer. +9. Cliquez sur **Add Key** -> **Create new key** et choisissez **JSON** comme type. 10. Cliquez sur **Create**. Un fichier de clé JSON est alors téléchargé sur votre ordinateur. Souvenez-vous de son emplacement, car vous en aurez besoin pour terminer lʼinstallation. 11. Accédez à la [page relative à lʼintégration Datadog/Google Cloud][203]. 12. Dans l'onglet **Configuration**, sélectionnez **Upload Key File** pour intégrer ce projet à Datadog. @@ -147,34 +303,23 @@ La fonctionnalité [dʼemprunt d'identité de compte de service][209] n'est pas - Répétez les étapes ci-dessus pour utiliser plusieurs comptes de service. - Utilisez le même compte de service en modifiant la valeur de `project_id` dans le fichier JSON téléchargé à l'étape 10. Importez ensuite le fichier dans Datadog, tel que décrit aux étapes 11 à 14. -### Configuration - -Si vous le souhaitez, vous pouvez limiter les instances GCE récupérées par Datadog. Pour ce faire, saisissez des tags dans la zone de texte **Limit Metric Collection** située dans le menu déroulant d'un projet donné. Seuls les hosts qui correspondent à l'un des tags définis sont alors importés dans Datadog. Vous pouvez utiliser des wildcards (`?` pour un caractère unique, `*` pour plusieurs caractères) pour inclure un grand nombre de hosts, ou encore `!` pour exclure certains hosts. L'exemple ci-dessous englobe toutes les instances de taille `c1*`, mais exclut les hosts de type staging : - -```text -datadog:monitored,env:production,!env:staging,instance-type:c1.* -``` - -Consultez la [documentation Google][208] pour obtenir plus de renseignements sur la création et la gestion de libellés. - +[201]: https://cloud.google.com/iam/docs/service-account-impersonation [202]: https://console.cloud.google.com/apis/credentials [203]: https://app.datadoghq.com/account/settings#integrations/google_cloud_platform [204]: https://support.google.com/cloud/answer/6293499?hl=en [205]: https://console.cloud.google.com/apis/library/monitoring.googleapis.com [206]: https://console.cloud.google.com/apis/library/compute.googleapis.com [207]: https://console.cloud.google.com/apis/api/cloudasset.googleapis.com/overview -[208]: https://cloud.google.com/compute/docs/labeling-resources -[209]: https://cloud.google.com/iam/docs/service-account-impersonation - {{< /site-region >}} + + {{< site-region region="us,us3,us5,eu,ap1" >}} Grâce à l'[emprunt d'identité de compte de service][301] et à la découverte automatique des projets, vous pouvez intégrer Datadog à [Google Cloud][302]. Cette approche vous permet de surveiller tous les projets accessibles depuis un compte de service, en attribuant des rôles IAM aux projets pertinents. Il est possible d'attribuer ces rôles à des projets spécifiques, mais aussi de les attribuer à l'échelle d'une organisation ou d'un dossier, afin de surveiller des groupes de projets. De cette façon, Datadog découvre et surveille automatiquement tous les projets d'un contexte donné, y compris les nouveaux projets qui intègrent ultérieurement le groupe. -#### 1. Créer votre compte de service Google Cloud - +{{% collapse-content title="1. Créer un compte de service Google Cloud" level="h5" id="create-service-account" %}} 1. Ouvrez votre [console Google Cloud][303]. 2. Accédez à **IAM & Admin** > **Service Accounts**. 3. Cliquez sur **Create service account** en haut de la page. @@ -188,144 +333,163 @@ Cette approche vous permet de surveiller tous les projets accessibles depuis un {{< img src="integrations/google_cloud_platform/create-service-account.png" alt="Interface de la console Google Cloud, avec le processus de création de compte de service. Sous l'étape « Grant this service account access to project », les quatre rôles indiqués dans les instructions sont ajoutés." style="width:70%;">}} -#### 2. Ajouter le service principal Datadog à votre compte de service +[303]: https://console.cloud.google.com/ +{{% /collapse-content %}} -1. Dans Datadog, accédez à [**Integrations** > **Google Cloud Platform**][304]. +{{% collapse-content title="2. Ajouter le principal Datadog à votre compte de service" level="h5" id="add-principal-to-service-account" %}} +1. Dans Datadog, accédez à la page [**Integrations** > **Google Cloud Platform**][305]. 2. Cliquez sur **Add GCP Account**. SI vous n'avez pas encore configuré de projet, vous êtes automatiquement redirigé vers cette page. 3. Si vous n'avez pas généré de service principal Datadog pour votre organisation, cliquez sur le bouton **Generate Principal**. 4. Copiez votre service principal Datadog et conservez-le pour la prochaine section. {{< img src="integrations/google_cloud_platform/principal-2.png" alt="Interface Datadog, avec le processus d'ajout d'un nouveau compte GCP. La première étape, « Add Datadog Principal to Google », contient une zone de texte permettant à l'utilisateur de générer un service principal Datadog et de le copier dans son presse-papiers. La deuxième étape, « Add Service Account Email », inclut une zone de texte que l'utilisateur peut remplir lors de la section 3." style="width:70%;">}} - Gardez cette fenêtre ouverte, car vous en aurez besoin lors de la [prochaine section](#3-terminer-la-configuration-de-l-integration-dans-datadog). -5. Dans la [console Google Cloud][38303 sous le menu **Service Accounts**, recherchez le compte de service que vous avez créé lors de la [première section](#1-creer-votre-compte-de-service-google-cloud). + + **Remarque** : gardez cette fenêtre ouverte pour la section suivante. +5. Dans la [console Google Cloud][304] sous le menu **Service Accounts**, recherchez le compte de service que vous avez créé lors de la [première section](#creer-votre-compte-de-service). 6. Accédez à l'onglet **Permissions**, puis cliquez sur **Grant Access**. {{< img src="integrations/google_cloud_platform/grant-access.png" alt="Interface de la console Google Cloud, avec l'onglet Permissions sous Service Accounts." style="width:70%;">}} 7. Collez votre service principal Datadog dans la zone **New Principals**. -8. Attribuez le rôle **Service Account Token Creator**, puis cliquez sur **Save**. +8. Attribuez le rôle **Service Account Token Creator**, puis cliquez sur **SAVE**. {{< img src="integrations/google_cloud_platform/add-principals-blurred.png" alt="Interface de la console Google Cloud, avec les sections « Add principals » et « Assign roles »." style="width:70%;">}} **Remarque** : si vous avez déjà configuré l'accès à l'aide d'un service principal Datadog partagé, vous pouvez révoquer l'autorisation pour ce service principal après avoir suivi ces étapes. -#### 3. Terminer la configuration de l'intégration dans Datadog +[304]: https://console.cloud.google.com/ +[305]: https://app.datadoghq.com/integrations/google-cloud-platform +{{% /collapse-content %}} +{{% collapse-content title="3. Finaliser la configuration de l'intégration dans Datadog" level="h5" %}} 1. Dans votre console Google Cloud, accédez à l'onglet **Service Account** > **Details**, afin de consulter l'adresse e-mail associée à ce compte de service Google. Son format est `@.iam.gserviceaccount.com`. 2. Copiez cette adresse e-mail. -3. Revenez sur le carré de configuration de l'intégration dans Datadog (là où vous avez copié votre service principal Datadog lors de la [section précédente](#2-ajouter-le-service-principal-datadog-a-votre-compte-de-service)). +3. Revenez sur le carré de configuration de l'intégration dans Datadog (là où vous avez copié votre service principal Datadog lors de la [section précédente](#ajouter-le-principal-a-votre-compte-de-service)). 4. Dans la zone de texte sous **Add Service Account Email**, collez l'adresse e-mail que vous avez précédemment copiée. 5. Cliquez sur **Verify and Save Account**. -Les métriques devraient s'afficher dans Datadog après environ 15 minutes. +Les métriques apparaîtront dans Datadog environ quinze minutes après la configuration. +{{% /collapse-content %}} -#### 4. Attribuer des rôles à d'autres projets (facultatif) +[301]: https://cloud.google.com/iam/docs/service-account-impersonation +[302]: https://docs.datadoghq.com/fr/integrations/google_cloud_platform/ +{{< /site-region >}} -Grâce à la découverte automatique de projets, il est beaucoup plus simple d'ajouter de nouveaux projets à surveiller. SI vous attribuez à d'autres projets, dossiers ou organisations un accès à votre compte de service, Datadog découvre ces projets (ainsi que tous les projets imbriqués dans les dossiers ou organisations) et les ajoute automatiquement à votre carré d'intégration. -1. Vérifiez que vous avez configuré les bonnes autorisations, afin que les rôles attribués disposent de l'accès prévu : - * Project IAM Admin (ou autorisation de plus haut niveau) - * Folder Admin - * Organization Admin -2. Dans la console Google Cloud, accédez à la page **IAM**. -3. Sélectionnez un projet, un dossier ou une organisation. -4. Pour attribuer un rôle à un service principal qui ne possède pas encore de rôle pour la ressource, cliquez sur **Grant Access**, puis saisissez l'adresse e-mail du compte de service créé précédemment. -5. Attribuez les rôles suivants : - * Compute Viewer - * Monitoring Viewer - * Cloud Asset Viewer - **Remarque** : le rôle Browser est uniquement requis pour le projet par défaut du compte de service. -6. Cliquez sur **Save**. +{{% /tab %}} +{{< /tabs >}} -[301]: https://cloud.google.com/iam/docs/service-account-overview#impersonation -[302]: https://docs.datadoghq.com/fr/integrations/google_cloud_platform/ -[303]: https://console.cloud.google.com/ -[304]: https://app.datadoghq.com/integrations/google-cloud-platform +#### Validation -{{< /site-region >}} +Pour consulter vos métriques, utilisez le menu de gauche pour accéder à **Metrics** > **Summary**, puis recherchez `gcp` : + +{{< img src="integrations/google_cloud_platform/gcp_metric_summary.png" alt="La page Metric Summary dans Datadog filtrée sur les métriques commençant par GCP" style="width:100%;" >}} #### Configuration -Si vous le souhaitez, vous pouvez limiter les instances GCE récupérées par Datadog. Pour ce faire, saisissez des tags dans la zone de texte **Limit Metric Collection** située dans le menu déroulant d'un projet donné. Seuls les hosts qui correspondent à l'un des tags définis sont alors importés dans Datadog. Vous pouvez utiliser des wildcards (`?` pour un caractère unique, `*` pour plusieurs caractères) pour inclure un grand nombre de hosts, ou encore `!` pour exclure certains hosts. L'exemple ci-dessous englobe toutes les instances de taille `c1*`, mais exclut les hosts de type staging : +{{% collapse-content title="Limiter la collecte de métriques par espace de noms" level="h5" %}} + +Vous pouvez, si vous le souhaitez, choisir les services Google Cloud à surveiller avec Datadog. Configurer la collecte de métriques pour des services spécifiques vous permet d'optimiser les coûts liés à l'API Google Cloud Monitoring tout en conservant la visibilité sur vos services critiques. + +Sous l'onglet **Metric Collection** de la page d'intégration Google Cloud dans la [page d'intégration Google Cloud][43] de Datadog, décochez les espaces de nommage des métriques à exclure. Vous pouvez également désactiver la collecte de tous les espaces de nommage. + +{{< img src="integrations/google_cloud_platform/limit_metric_namespaces.png" alt="L'onglet Metric Collection dans la page d'intégration Google Cloud de Datadog" style="width:80%;" >}}{{% /collapse-content %}} + +{{% collapse-content title="Limiter la collecte de métriques par tag" level="h5" %}} + +Par défaut, toutes vos instances Google Compute Engine (GCE) apparaissent dans la vue d'ensemble de l'infrastructure de Datadog. Datadog les taggue automatiquement avec les tags d'hôte GCE ainsi que les éventuels labels GCE que vous avez ajoutés. + +Vous pouvez éventuellement utiliser des tags pour limiter les instances importées dans Datadog. Dans l'onglet **Metric Collection** d'un projet, saisissez les tags dans le champ **Limit Metric Collection Filters**. Seuls les hosts correspondant à l'un des tags définis seront importés dans Datadog. Vous pouvez utiliser des jokers (`?` pour un caractère, `*` pour plusieurs caractères) pour cibler de nombreux hosts, ou `!` pour exclure certains hosts. Cet exemple inclut toutes les instances de type `c1*` mais exclut les hosts de staging : ```text datadog:monitored,env:production,!env:staging,instance-type:c1.* ``` -Consultez la [documentation Google][41] pour obtenir plus de renseignements sur la création et la gestion de libellés. +Consultez la page [Organiser des ressources à l'aide d'étiquettes][44] de Google pour en savoir plus. -### Collecte de logs +{{% /collapse-content %}} -Transmettez des logs à Datadog depuis vos services Google Cloud en utilisant [Google Cloud Dataflow][42] et le [modèle Datadog][43]. Cette méthode permet à la fois de compresser et de mettre en lots des événements avant de les transmettre à Datadog. Suivez les instructions indiquées dans cette section pour : +#### Utiliser l'Agent Datadog -[1](#1-creer-une-rubrique-pubsub-cloud-et-un-abonnement). Créer une [rubrique][44] Pub/Sub et un [abonnement pull][45] pour recevoir des logs provenant d'un récepteur de logs configuré. -[2](#2-creer-un-compte-de-service-de-worker-dataflow-personnalise). Créer un compte de service de worker Datadog personnalisé pour accorder [le moindre privilège][46] aux workers de votre pipeline Dataflow. -[3](#3-exporter-des-logs-depuis-une-rubrique- --google-cloud-pubsub). Créer un [récepteur de logs][47] pour publier des logs dans la rubrique Pub/Sub. -[4](#4-creer-et-executer-la-tache-dataflow). Créer une tâche Dataflow à lʼaide du [modèle Datadog][43] pour transmettre à Datadog des logs à partir de l'abonnement Pub/Sub. +Utilisez l'[Agent Datadog][45] pour collecter les [métriques les plus granulaires et à faible latence][46] depuis votre infrastructure. Installez l'Agent sur tout host, y compris [GKE][47], afin d'obtenir une visibilité accrue grâce aux [traces][48] et aux [logs][49] qu'il peut collecter. Pour plus d'informations, consultez [Pourquoi installer l'Agent Datadog sur mes instances cloud ?][50] -Vous contrôlez entièrement les logs qui sont envoyés à Datadog via filtres de journalisation que vous créez dans le récepteur de logs, y compris les logs GCE et GKE. Consultez la page [Langage de requête Logging][48] de Google pour en savoir plus sur l'écriture de filtres. +## Collecte de logs -**Remarque** : vous devez activer l'API Dataflow pour utiliser Google Cloud Dataflow. Consultez la section [Activation des API][49] de la documentation de Google Cloud pour en savoir plus. +{{< tabs >}} +{{% tab "Dataflow Method (Recommended)" %}} -Vous pouvez également utiliser [lʼAgent Datadog][50] pour recueillir des logs à partir d'applications exécutées dans GCE ou GKE, . +Transférez les logs de vos services Google Cloud vers Datadog en utilisant [Google Cloud Dataflow][1] et le [modèle Datadog][2]. Cette méthode permet la compression et le regroupement des événements avant leur envoi vers Datadog. -
+Vous pouvez utiliser le module [terraform-gcp-datadog-integration][3] pour gérer cette infrastructure via Terraform, ou suivre les étapes ci-dessous pour : -La collecte de logs Google Cloud à l'aide d'un abonnement Push Pub/Sub est sur le point d'être rendue obsolète pour les raisons suivantes : +1. Créer un [sujet Pub/Sub][4] et un [abonnement pull][5] pour recevoir les logs depuis un récepteur de logs configuré +2. Créer un compte de service personnalisé pour Dataflow afin d'appliquer le principe du [moindre privilège][6] à vos workers Dataflow +3. Créer un [récepteur de logs][7] pour publier les logs sur la rubrique Pub/Sub +4. Créer un job Dataflow à l'aide du [modèle Datadog][2] pour diffuser les logs depuis l'abonnement Pub/Sub vers Datadog -- Si vous disposez d'un VPC Google Cloud, les nouveaux abonnements Push ne peuvent pas être configurés depuis des endpoints externes (consultez la page [Produits compatibles et limites][51] de Google Cloud pour en savoir plus). -- L'abonnement Push n'assure pas la compression ou la mise en lots dʼévénements, et n'est donc adapté qu'à un très faible volume de logs +Vous gardez un contrôle total sur les logs envoyés à Datadog grâce aux filtres que vous définissez dans le récepteur de logs, y compris pour les logs GCE et GKE. Consultez la page [Langage de requête Logging][8] de Google pour écrire vos filtres. Pour un aperçu complet de l'architecture mise en place, consultez [Stream logs from Google Cloud to Datadog (en anglais)][9] dans le Cloud Architecture Center. -La documentation relative à l'abonnement Pushest uniquement conservée à des fins de dépannage ou de modification dʼanciennes configurations. Utilisez un abonnement Pull avec le modèle Dataflow de Datadog pour transmettre vos logs Google Cloud vers Datadog. -
+**Remarque :** vous devez activer l'**API Dataflow** pour utiliser Google Cloud Dataflow. Consultez la rubrique [Activer des API][10] dans la documentation Google Cloud pour plus d'informations. -#### 1. Créer une rubrique et un abonnement Cloud Pub/Sub +Pour collecter les logs d'applications exécutées sur GCE ou GKE, vous pouvez également utiliser l'[Agent Datadog][11]. -1. Accédez à la [console Pub/Sub Cloud][52] et créez une rubrique. Sélectionnez l'option **Add a default subscription** pour simplifier la configuration. +#### 1. Créer un sujet et un abonnement Cloud Pub/Sub - **Remarque** : vous pouvez aussi configurer un [abonnement Cloud Pub/Sub][53] manuellement avec le type de livraison **Pull**. Si vous créez manuellement votre abonnement Pub/Sub, ne cochez **pas** la case `Enable dead lettering`. Pour en savoir plus, référez-vous à la section [Fonctionnalités Pub/Sub non prises en charge][54]. +1. Accédez à la [console Cloud Pub/Sub][12] et créez un nouveau sujet. Sélectionnez l'option **Add a default subscription** pour simplifier la configuration. + + **Remarque :** vous pouvez également configurer manuellement un [abonnement Cloud Pub/Sub][13] avec le type de livraison **Pull**. Si vous créez manuellement votre abonnement Pub/Sub, laissez la case `Enable dead lettering` **non cochée**. Pour plus de détails, consultez la section [Fonctionnalités Pub/Sub non compatibles][14]. {{< img src="integrations/google_cloud_platform/create_a_topic.png" alt="la page « Créer un sujet » dans la console Google Cloud avec la case « Ajouter un abonnement par défaut » cochée" style="width:80%;">}} 2. Donnez un nom clair à ce sujet, comme `export-logs-to-datadog`, et cliquez sur *Create*. -3. Créez un autre sujet et un autre abonnement par défaut pour gérer tous les messages de logs rejetés par lʼAPI Datadog. Le nom de ce sujet est utilisé dans le modèle Dataflow Datadog, où il fait partie de la configuration du chemin pour le [paramètre de modèle][55] `outputDeadletterTopic`. Une fois que vous avez inspecté et corrigé tous les problèmes des messages dʼéchec, renvoyez-les au sujet `export-logs-to-datadog` dʼorigine en exécutant une tâche [Modèle Pub/Sub vers Pub/Sub][56]. +3. Créez un autre sujet et un autre abonnement par défaut pour gérer tous les messages de log rejetés par lʼAPI Datadog. Le nom de ce sujet est utilisé dans le modèle Dataflow Datadog, où il fait partie de la configuration du chemin pour le [paramètre de modèle][10] `outputDeadletterTopic`. Une fois que vous avez inspecté et corrigé tous les problèmes des messages d'échec, renvoyez-les au sujet `export-logs-to-datadog` d'origine en exécutant une tâche [Modèle Pub/Sub vers Pub/Sub][15]. -4. Datadog recommande de créer un secret dans [Secret Manager][57] avec la valeur de votre clé dʼAPI Datadog valide, afin de lʼutiliser plus tard dans le modèle Dataflow Datadog. +4. Datadog recommande de créer un secret dans [Secret Manager][16] avec la valeur de votre clé d'API Datadog valide, afin de l'utiliser plus tard dans le modèle Dataflow Datadog. -**Avertissement** : les Pub/Sub Cloud sont inclus dans les [quotas et limitations de Google Cloud][58]. Si votre nombre de logs dépasse ces limites, Datadog vous conseille de les répartir sur plusieurs sujets. Consultez la [rubrique Surveiller la redirection de logs Pub/Sub](#surveiller-la-redirection-de-logs-pubsub-cloud) pour découvrir comment configurer des notifications de monitor si vous vous approchez de ces limites. +**Avertissement** : les Cloud Pub/Sub sont inclus dans les [quotas et limites de Google Cloud][7]. Si votre nombre de logs dépasse ces limites, Datadog vous conseille de les répartir sur plusieurs sujets. Consultez la [rubrique Surveiller la redirection de logs Pub/Sub](#surveiller-la-redirection-des-logs-cloud-pubsub) pour découvrir comment configurer des notifications de monitor si vous vous approchez de ces limites. #### 2. Créer un compte de service de worker Dataflow personnalisé -Par défaut, les workers de pipelines Dataflow utilisent le [compte de service Compute Engine par défaut][59] de votre projet, qui accorde des autorisations pour toutes les ressources du projet. Si vous transmettez des logs dʼun environnement **Production**, il est conseillé de privilégier la création dʼun compte de service de worker personnalisé nʼincluant que les rôles et les autorisations nécessaires, et dʼattribuer ce compte de service à vos workers de pipeline Dataflow. +Par défaut, les workers de pipeline Dataflow utilisent le [compte de service Compute Engine par défaut][17] de votre projet, qui accorde des autorisations pour toutes les ressources du projet. Si vous transmettez des logs d'un environnement **Production**, il est conseillé de privilégier la création d'un compte de service de worker personnalisé n'incluant que les rôles et les autorisations nécessaires, et d'attribuer ce compte de service à vos workers de pipeline Dataflow. -1. Accédez à la page [Comptes de service][60] de la console Google Cloud et sélectionnez votre projet. -2. Cliquez sur **CREATE SERVICE ACCOUNT** et attribuez un nom descriptif au compte de service. Cliquez sur **CREATE AND CONTINUE**. +1. Accédez à la page [Service Accounts][18] de la console Google Cloud et sélectionnez votre projet. +2. Cliquez sur **CREATE SERVICE ACCOUNT** et attribuez un nom descriptif au compte de service. Cliquez sur **CREATE AND CONTINUE**. 3. Ajoutez les rôles dans le tableau des autorisations correspondant et cliquez sur **DONE**. ##### Autorisations requises -| Rôle | Chemin | Description | -|--------------------------------------|--------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------| -| [Dataflow Admin][61] | `roles/dataflow.admin` | Autoriser ce compte de service à effectuer des tâches administratives Dataflow | -| [Dataflow Worker][62] | `roles/dataflow.worker` | Autoriser ce compte de service à effectuer des opérations de tâches Dataflow | -| [Pub/Sub Viewer][63] | `roles/pubsub.viewer` | Autoriser ce compte de service à consulter des messages de lʼabonnement Pub/Sub avec vos logs Google Cloud | -| [Pub/Sub Subscriber][64] | `roles/pubsub.subscriber` | Autoriser ce compte de service à consommer des messages de lʼabonnement Pub/Sub avec vos logs Google Cloud | -| [Pub/Sub Publisher][65] | `roles/pubsub.publisher` | Autoriser ce compte de service à publier les messages échoués dans un abonnement distinct, permettant dʼanalyser et de renvoyer les logs | -| [Secret Manager Secret Accessor][66] | `roles/secretmanager.secretAccessor` | Autoriser ce compte de service à accéder à la clé dʼAPI Datadog dans Secret Manager | -| [Storage Object Admin][67] | `roles/storage.objectAdmin` | Autoriser ce compte de service à lire et écrire sur le compartiment de Cloud Storage indiqué pour les fichiers en staging | +[Administrateur Dataflow][19] +: `roles/dataflow.admin`
Permet au compte de service d'effectuer des tâches administratives Dataflow. + +[Nœud de calcul Dataflow][20] +: `roles/dataflow.worker`
Permet au compte de service d'effectuer des opérations de job Dataflow. + +[Lecteur Pub/Sub][21] +: `roles/pubsub.viewer`
Permet au compte de service de consulter les messages de l'abonnement Pub/Sub avec vos logs Google Cloud. + +[Abonné Pub/Sub][22] +: `roles/pubsub.subscriber`
Permet au compte de service de consommer les messages de l'abonnement Pub/Sub avec vos logs Google Cloud. + +[Éditeur Pub/Sub][1] +: `roles/pubsub.publisher`
Permet au compte de service de publier les messages ayant échoué dans un abonnement distinct, ce qui permet d'analyser ou de renvoyer les logs. + +[Accesseur de secrets Secret Manager][23] +: `roles/secretmanager.secretAccessor`
Permet au compte de service d'accéder à la clé d'API Datadog dans Secret Manager. + +[Administrateur des objets Storage][24] +: `roles/storage.objectAdmin`
permet au compte de service de lire et d'écrire sur le compartiment Cloud Storage indiqué pour les fichiers en staging. **Remarque** : si vous ne créez par de compte de service pour les workers de pipeline Dataflow, assurez-vous que le compte de service Compute Engine par défaut possède les autorisations requises ci-dessus. #### 3. Exporter des logs depuis le sujet Pub/Sub Google Cloud -1. Accédez à [la page Logs Explorer][68] dans la console Google Cloud. +1. Accédez à [la page Log Explorer][25] dans la console Google Cloud. 2. Depuis lʼonglet **Log Router**, sélectionnez **Create Sink**. 3. Nommez le récepteur. 4. Choisissez _Cloud Pub/Sub_ comme destination et sélectionnez le sujet Cloud Pub/Sub créé à cette fin. **Remarque** : le sujet Cloud Pub/Sub peut se situer dans un autre projet. {{< img src="integrations/google_cloud_pubsub/creating_sink2.png" alt="Exporter les logs Google Cloud Pub/Sub vers le Pub Sub" >}} -5. Choisissez les logs que vous souhaitez inclure dans le récepteur avec un filtre dʼinclusion ou dʼexclusion facultatif. Vous pouvez filtrer les logs avec une requête de recherche, ou utiliser [lʼexemple de fonction][69]. Par exemple, si vous souhaitez inclure seulement 10 % des logs avec `ERROR` comme niveau de `severity`, créez un filtre dʼinclusion avec `severity="ERROR" AND sample(insertId, 0.01)`. +5. Choisissez les logs que vous souhaitez inclure dans le récepteur avec un filtre d'inclusion ou d'exclusion facultatif. Vous pouvez filtrer les logs avec une requête de recherche, ou utiliser [l'exemple de fonction][5]. Par exemple, si vous souhaitez inclure seulement 10 % des logs avec `ERROR` comme niveau de `severity`, créez un filtre d'inclusion avec `severity="ERROR" AND sample(insertId, 0.1)`. - {{< img src="integrations/google_cloud_platform/sink_inclusion_filter.png" alt="Le filtre dʼinclusion pour un récepteur de logs Google Cloud avec une requête ayant comme propriétés severity=ERROR et sample(insertId, 0.1)" >}} + {{< img src="integrations/google_cloud_platform/sink_inclusion_filter_2.png" alt="Le filtre dʼinclusion pour un récepteur de logs Google Cloud avec une requête ayant comme propriétés severity=ERROR et sample(insertId, 0.1)" >}} 6. Cliquez sur **Create Sink**. @@ -333,62 +497,495 @@ Par défaut, les workers de pipelines Dataflow utilisent le [compte de service C #### 4. Créer et exécuter la tâche Dataflow -1. Accédez à la page [Créer une tâche à partir d'un modèle][70] dans la console Google Cloud. +1. Accédez à la page de [création d'une tâche à partir d'un modèle][17] dans la console Google Cloud. 2. Donnez un nom à la tâche et sélectionnez un endpoint régional Dataflow. -3. Sélectionnez `Pub/Sub to Datadog` dans la liste déroulante **Dataflow template**, et la section **Required parameters** apparaît. - a. Sélectionnez l'abonnement en entrée dans la liste déroulante **Pub/Sub input subscription**. - b. Saisissez les informations suivantes dans le champ **Datadog logs API URL** : - - ```shell - https://{{< region-param key="http_endpoint" code="true" >}} +3. Sélectionnez `Pub/Sub to Datadog` dans la liste déroulante **Dataflow template**, et la section **Required parameters** apparaît. + a. Sélectionnez l'abonnement en entrée dans la liste déroulante **Pub/Sub input subscription**. + b. Saisissez les informations suivantes dans le champ **Datadog logs API URL** : + 
https://{{< region-param key="http_endpoint" code="true" >}}
- ``` - **Remarque** : assurez-vous que le sélecteur de site Datadog à droite de la page est défini sur votre [site Datadog][64] avant de copier l'URL ci-dessus. + **Remarque** : assurez-vous que le sélecteur de site Datadog à droite de la page est défini sur votre [site Datadog][22] avant de copier l'URL ci-dessus. - c. Sélectionnez le sujet créé pour recevoir les échecs de messages dans la liste déroulante **Output deadletter Pub/Sub topic**. - d. Indiquez un chemin d'accès pour les fichiers temporaires dans votre compartiement de stockage dans le champ **Temporary location**. + c. Sélectionnez le sujet créé pour recevoir les échecs de messages dans la liste déroulante **Output deadletter Pub/Sub topic**. + d. Indiquez un chemin d'accès pour les fichiers temporaires dans votre compartiment de stockage dans le champ **Temporary location**. -{{< img src="integrations/google_cloud_platform/dataflow_parameters.png" alt="Paramètres requis dans le modèle Dataflow Datadog" style="width:80%;">}} +{{< img src="integrations/google_cloud_platform/dataflow_parameters.png" alt="Paramètres requis dans le modèle Dataflow Datadog" style="width:80%;">}} 4. Sous **Optional Parameters**, cochez `Include full Pub/Sub message in the payload`. -5. Si vous avez créé un secret dans Secret Manager avec la valeur de votre clé API Datadog comme indiqué dans [étape 1](#1-creer-une-rubrique-et-un-abonnement-pubsub-cloud)), entrez le **nom de la ressource** du secret dans le champ **Google Cloud Secret Manager ID**. +5. Si vous avez créé un secret dans Secret Manager avec la valeur de votre clé d'API Datadog comme indiqué dans [étape 1](#1-creer-un-sujet-et-un-abonnement-cloud-pubsub)), entrez le **nom de la ressource** du secret dans le champ **Google Cloud Secret Manager ID**. -{{< img src="integrations/google_cloud_platform/dataflow_template_optional_parameters.png" alt="Paramètres facultatifs dans le modèle Dataflow Datadog avec les champs de lʼID de Secret Manager dans Google Cloud et la source de la clé dʼAPI transmise mis en évidence" style="width:80%;">}} +{{< img src="integrations/google_cloud_platform/dataflow_template_optional_parameters.png" alt="Paramètres facultatifs dans le modèle Dataflow Datadog avec les champs de lʼID de Secret Manager dans Google Cloud et la source de la clé dʼAPI transmise mis en évidence" style="width:80%;">}} -Consultez la section [Paramètres de modèle][55] dans le modèle Dataflow pour en savoir plus sur lʼutilisation des autres options disponibles : +Consultez la rubrique [Paramètres de modèle][10] dans le modèle Dataflow pour en savoir plus sur l'utilisation des autres options disponibles : - - `apiKeySource=KMS` avec `apiKeyKMSEncryptionKey` défini sur votre clé dʼID de [Cloud KMS][71] et `apiKey` défini sur la clé dʼAPI chiffrée + - `apiKeySource=KMS` avec `apiKeyKMSEncryptionKey` défini sur l'ID de votre clé [Cloud KMS][19] et `apiKey` défini sur la clé d'API chiffrée - **Non conseillé** : `apiKeySource=PLAINTEXT` avec `apiKey` défini sur la clé dʼAPI en texte brut -6. Si vous avez créé un compte service de worker personnalisé, sélectionnez-le dans le menu déroulant **Service account email**. +6. Si vous avez créé un compte service de worker personnalisé, sélectionnez-le dans le menu déroulant **Service account email**. {{< img src="integrations/google_cloud_platform/dataflow_template_service_account.png" alt="Paramètres facultatifs dans le modèle Dataflow Datadog avec le menu déroulant de lʼe-mail du compte de service mis en évidence" style="width:80%;">}} 7. Cliquez sur **RUN JOB**. -**Remarque** : si vous possédez un VPC partagé, consultez la page [Spécifier un réseau et un sous-réseau][72] de la documentation Dataflow pour obtenir des instructions sur la spécification des paramètres `Network` et `Subnetwork`. +**Remarque** : si vous possédez un VPC partagé, consultez la page [Spécifier un réseau et un sous-réseau][20] de la documentation Dataflow pour obtenir des instructions sur la spécification des paramètres `Network` et `Subnetwork`. #### Validation -Les nouveaux événements de logs envoyés au sujet Cloud Pub/Sub apparaissent dans le [Log Explorer de Datadog][73]. +Les nouveaux événements de log envoyés au sujet Cloud Pub/Sub apparaissent dans le [Log Explorer de Datadog][24]. -**Remarque** : vous pouvez utiliser le [Calculateur de prix Google Cloud][74] pour calculer les coûts potentiels. +**Remarque** : vous pouvez utiliser le [simulateur de coût de Google Cloud][26] pour calculer les coûts potentiels. #### Surveiller la redirection des logs Cloud Pub/Sub -Lʼ[intégration Google Cloud Pub/Sub][30] fournit des métriques utiles pour surveiller l'état de la redirection des logs : +Lʼ[intégration Google Cloud Pub/Sub][4] fournit des métriques utiles pour surveiller l'état de la redirection des logs : - `gcp.pubsub.subscription.num_undelivered_messages` pour le nombre de messages en attente de livraison - `gcp.pubsub.subscription.oldest_unacked_message_age` pour l'âge du plus ancien message non acquitté dans un abonnement -Utilisez les métriques ci-dessus avec un [monitor de métriques][75] pour recevoir des alertes pour les messages dans vos abonnements en entrée et de messages non aboutis. +Utilisez les métriques ci-dessus avec un [monitor de métrique][72] pour recevoir des alertes pour les messages dans vos abonnements d'entrée et de lettres mortes. #### Surveiller le pipeline Dataflow -Utilisez [lʼintégration Google Cloud Dataflow][9] de Datadog pour surveiller tous les aspects de vos pipelines Dataflow. Vous pouvez voir toutes vos métriques Dataflow principales sur le dashboard prêt à l'emploi, doté de données contextuelles telles que des informations sur les instances GCE qui exécutent vos workloads Dataflow, et votre débit Pub/Sub. +Utilisez [lʼintégration Google Cloud Dataflow][28] de Datadog pour surveiller tous les aspects de vos pipelines Dataflow. Vous pouvez voir toutes vos métriques Dataflow principales sur le dashboard prêt à l'emploi, doté de données contextuelles telles que des informations sur les instances GCE qui exécutent vos workloads Dataflow, et votre débit Pub/Sub. + +Vous pouvez également utiliser un [monitor recommandé][29] préconfiguré pour configurer des notifications pour les augmentations du temps de backlog dans votre pipeline. Pour en savoir plus, lisez la section [Monitor your Dataflow pipelines with Datadog][30] (en anglais) dans le blog de Datadog. + + +[1]: https://cloud.google.com/dataflow +[2]: https://cloud.google.com/dataflow/docs/guides/templates/provided/pubsub-to-datadog +[3]: https://github.com/GoogleCloudPlatform/terraform-gcp-datadog-integration +[4]: https://docs.datadoghq.com/fr/integrations/google_cloud_pubsub/ +[5]: https://cloud.google.com/pubsub/docs/create-subscription +[6]: https://www.datadoghq.com/blog/datadog-recommended-monitors/ +[7]: https://cloud.google.com/logging/docs/export/configure_export_v2#creating_sink +[8]: https://cloud.google.com/logging/docs/view/logging-query-language +[9]: https://cloud.google.com/architecture/partners/stream-cloud-logs-to-datadog +[10]: https://cloud.google.com/apis/docs/getting-started#enabling_apis +[11]: https://docs.datadoghq.com/fr/agent/ +[12]: https://console.cloud.google.com/cloudpubsub/topicList +[13]: https://console.cloud.google.com/cloudpubsub/subscription/ +[14]: https://cloud.google.com/pubsub/docs/access-control#pubsub.viewer +[15]: https://cloud.google.com/dataflow/docs/guides/templates/provided/pubsub-to-pubsub +[16]: https://www.datadoghq.com/blog/monitor-dataflow-pipelines-with-datadog/ +[17]: https://console.cloud.google.com/dataflow/createjob +[18]: https://console.cloud.google.com/iam-admin/serviceaccounts +[19]: https://cloud.google.com/kms/docs +[20]: https://cloud.google.com/dataflow/docs/guides/specifying-networks#shared +[21]: https://cloud.google.com/dataflow/docs/concepts/access-control#dataflow.worker +[22]: https://console.cloud.google.com/logs/viewer +[23]: https://cloud.google.com/logging/docs/view/logging-query-language#sample +[24]: https://app.datadoghq.com/logs +[25]: https://cloud.google.com/pubsub/docs/access-control#pubsub.subscriber +[26]: https://cloud.google.com/products/calculator +[27]: https://docs.datadoghq.com/fr/monitors/types/metric/ +[28]: https://cloud.google.com/pubsub/docs/access-control#pubsub.publisher +[29]: https://cloud.google.com/secret-manager/docs/access-control#secretmanager.secretAccessor +[30]: https://cloud.google.com/storage/docs/access-control/iam-roles/ +{{% /tab %}} +{{% tab "Pub/Sub Push Method (Legacy)" %}} + +La collecte des logs Google Cloud à l'aide d'un abonnement Push Pub/Sub est en cours de **dépréciation**. + +La documentation ci-dessus relative à l'abonnement **Push** n'est maintenue que pour le dépannage ou la modification d'anciennes configurations. + +Utilisez un abonnement **Pull** avec le modèle Dataflow de Datadog, comme décrit dans la [méthode Dataflow][1], pour transférer vos logs Google Cloud vers Datadog. + + +[1]: http://docs.datadoghq.com/integrations/google_cloud_platform/?tab=dataflowmethodrecommended +{{% /tab %}} +{{< /tabs >}} + +## Surveillance étendue de BigQuery + +{{< callout url="https://www.datadoghq.com/product-preview/bigquery-monitoring/" header="Join the Preview!" >}} + La surveillance étendue de BigQuery est disponible en préversion. Utilisez ce formulaire pour vous inscrire et commencer à obtenir des informations sur les performances de vos requêtes. +{{< /callout >}} + +La surveillance étendue de BigQuery offre une visibilité granulaire sur vos environnements BigQuery. + +### Surveillance des performances des jobs BigQuery + +Pour surveiller les performances de vos jobs BigQuery, attribuez le rôle [BigQuery Resource Viewer][51] au compte de service Datadog pour chaque projet Google Cloud. + +**Remarques** : + - Vous devez avoir vérifié votre compte de service Google Cloud dans Datadog, comme indiqué dans la [section de configuration](#configuration). + - Vous **n'avez pas** besoin de configurer Dataflow pour collecter les logs dans le cadre de la surveillance BigQuery étendue. + +1. Dans la console Google Cloud, accédez à la [page IAM][52]. +2. Cliquez sur **Accorder un accès**. +3. Saisissez l'adresse e-mail de votre compte de service dans **Nouveaux principaux**. +4. Attribuez le rôle [BigQuery Resource Viewer][51]. +5. Cliquez sur **ENREGISTRER**. +6. Dans la [page d'intégration Google Cloud de Datadog][43], accédez à l'onglet **BigQuery**. +7. Cliquez sur le bouton **Enable Query Performance**. + +### Surveillance de la qualité des données BigQuery + +La surveillance de la qualité des données BigQuery fournit des métriques de qualité à partir de vos tables BigQuery (comme la fraîcheur ou les mises à jour du nombre de lignes et de la taille). Explorez en profondeur les données de vos tables sur la [page Surveillance de la qualité des données][53]. + +Pour collecter les métriques de qualité, attribuez le rôle [BigQuery Metadata Viewer][54] au compte de service Datadog pour chaque table BigQuery que vous utilisez. + +**Remarque** : le rôle BigQuery Metadata Viewer peut être appliqué à une table, un ensemble de données, un projet ou une organisation. + - Pour surveiller la qualité des données de toutes les tables d’un ensemble de données, attribuez l’accès au niveau de l’ensemble de données. + - Pour surveiller la qualité des données de tous les ensembles de données d’un projet, attribuez l’accès au niveau du projet. + +1. Accédez à [BigQuery][55]. +2. Dans l'Explorer, recherchez la ressource BigQuery souhaitée. +3. Cliquez sur le menu à trois points à côté de la ressource, puis cliquez sur ***Share -> Manage Permissions**. + +{{< img src="integrations/google_cloud_platform/bigquery_manage_permissions.png" alt="L'option de menu Gérer les autorisations pour une ressource d'ensemble de données BigQuery" style="width:80%;">}}  + +4. Cliquez sur **ADD PRINCIPAL**. +5. Dans la zone de nouveaux principaux, saisissez le compte de service Datadog configuré pour l'intégration Google Cloud. +6. Attribuez le rôle [BigQuery Metadata Viewer][54]. +7. Cliquez sur **SAVE**. +8. Dans la [page d'intégration Google Cloud de Datadog][43], cliquez dans l'onglet **BigQuery**. +9. Cliquez sur le bouton **Enable Data Quality**. + +### Rétention des logs de jobs BigQuery + +Datadog recommande de créer un nouvel [index de logs][56] appelé `data-observability-queries`, et d'y indexer les logs de vos jobs BigQuery pendant 15 jours. Utilisez le filtre d'index suivant pour inclure les logs : + +```bash +service:data-observability @platform:* +``` + +Consultez la [page de tarification de la gestion des logs][57] pour une estimation des coûts. + +## Collecte de données sur les changements de ressource + +{{< callout url="https://www.datadoghq.com/private-beta/recent-changes-tab/" >}} + La collection Resource changes est en avant-première ! Pour demander l'accès, utilisez le formulaire ci-joint. +{{< /callout >}} + +Sélectionnez **Enable Resource Collection** dans [l’onglet Resource Collection][58] de la page d’intégration Google Cloud. Cela vous permet de recevoir des événements de ressource dans Datadog lorsque l’[inventaire des ressources Cloud][59] de Google détecte des modifications dans vos ressources cloud. + +Suivez ensuite les étapes ci-dessous pour transférer les événements de modification depuis un sujet Pub/Sub vers l’[Event Explorer][60] de Datadog. + +{{% collapse-content title="Google Cloud CLI" level="h4" %}} +### Créer un sujet et un abonnement Cloud Pub/Sub + +#### Créer un sujet + +1. Sur la [page des sujets Pub/Sub Google Cloud][61], cliquez sur **CREATE TOPIC**. +2. Attribuez un nom descriptif au sujet. +3. **Décochez** l'option permettant d'ajouter un abonnement par défaut. +4. Cliquez sur **CREATE**. + +#### Créer un abonnement + +1. Sur la [page des abonnements Pub/Sub Google Cloud][62], cliquez sur **CREATE SUBSCRIPTION**. +2. Saisissez `export-asset-changes-to-datadog` pour le nom de l'abonnement. +3. Sélectionnez le sujet Cloud Pub/Sub précédemment créé. +4. Sélectionnez le type de diffusion **Pull**. +5. Cliquez sur **CREATE**. + +### Autoriser l'accès + +Pour pouvoir lire les données de l'abonnement Pub/Sub, le compte de service Google Cloud utilisé par l'intégration doit disposer de l'autorisation `pubsub.subscriptions.consume` pour l'abonnement. Le rôle par défaut **Pub/Sub subscriber** possède cette autorisation, en plus d'autres autorisations minimales. Suivez les étapes ci-dessous pour attribuer ce rôle : -Vous pouvez également utiliser un [monitor recommandé][76] préconfiguré pour configurer des notifications pour les augmentations du temps de backlog dans votre pipeline. Pour en savoir plus, lisez la section [Monitor your Dataflow pipelines with Datadog][77] (en anglais) dans le blog de Datadog. +1. Sur la [page des abonnements Pub/Sub Google Cloud][62], cliquez sur l'abonnement `export-asset-changes-to-datadog`. +2. Depuis le **volet d'informations** sur la droite de la page, cliquez sur l'onglet **Permissions**. Si vous ne voyez pas ce volet, cliquez sur **SHOW INFO PANEL**. +3. Cliquez sur **ADD PRINCIPAL**. +4. Saisissez l'**adresse e-mail du compte de service** utilisée par l'intégration Datadog/Google Cloud. Vos comptes de service sont répertoriés sur la gauche de l'onglet **Configuration**, sur la [page de l'intégration Google Cloud][43] dans Datadog. + +### Créer un flux d'éléments + +Exécutez la commande ci-dessous dans [Cloud Shell][63] ou dans la [CLI gcloud][64] pour créer un flux d'inventaire d'éléments cloud qui envoie les événements de changement au sujet Pub/Sub précédemment créé. + +{{< tabs >}} + +{{% tab "Project" %}} + +```bash +gcloud asset feeds create +--project= +--pubsub-topic=projects//topics/ +--asset-names= +--asset-types= +--content-type= +``` + +Remplacez les placeholders comme indiqué ci-dessous : + + - `` : nom descriptif du flux d'inventaire d'éléments cloud. + - `` : ID de votre projet Google Cloud. + - `` : le nom du sujet Pub/Sub associé à l'abonnement `export-asset-changes-to-datadog`. + - `` : liste des [noms complets][1] des ressources (séparés par des virgules) d'où proviennent les événements de changement. **Facultatif** si `asset-types` est défini. + - `` : liste des [types d'éléments][2] (séparés par des virgules) d'où proviennent les événements de changement. **Facultatif** si `asset-names` est défini. + - `` : [type de contenu][3] **facultatif** des éléments d'où proviennent les événements de changement. + +[1]: https://cloud.google.com/asset-inventory/docs/resource-name-format +[2]: https://cloud.google.com/asset-inventory/docs/supported-asset-types +[3]: https://cloud.google.com/asset-inventory/docs/overview#content_types +{{% /tab %}} +{{% tab "Folder" %}} +```bash +gcloud asset feeds create +--folder= +--pubsub-topic=projects//topics/ +--asset-names= +--asset-types= +--content-type= +``` + +Remplacez les placeholders comme indiqué ci-dessous : + + - `` : nom descriptif du flux d'inventaire d'éléments cloud. + - `` : ID de votre dossier Google Cloud. + - `` : le nom du sujet Pub/Sub associé à l'abonnement `export-asset-changes-to-datadog`. + - `` : liste des [noms complets][1] des ressources (séparés par des virgules) d'où proviennent les événements de changement. **Facultatif** si `asset-types` est défini. + - `` : liste des [types d'éléments][2] (séparés par des virgules) d'où proviennent les événements de changement. **Facultatif** si `asset-names` est défini. + - `` : [type de contenu][3] **facultatif** des éléments d'où proviennent les événements de changement. + + +[1]: https://cloud.google.com/asset-inventory/docs/resource-name-format +[2]: https://cloud.google.com/asset-inventory/docs/supported-asset-types +[3]: https://cloud.google.com/asset-inventory/docs/overview#content_types +{{% /tab %}} + +{{% tab "Organisation" %}} + +```bash +gcloud asset feeds create +--organization= +--pubsub-topic=projects//topics/ +--asset-names= +--asset-types= +--content-type= +``` + +Remplacez les placeholders comme indiqué ci-dessous : + + - `` : nom descriptif du flux d'inventaire d'éléments cloud. + - `` : ID de votre organisation Google Cloud. + - `` : le nom du sujet Pub/Sub associé à l'abonnement `export-asset-changes-to-datadog`. + - `` : liste des [noms complets][1] des ressources (séparés par des virgules) d'où proviennent les événements de changement. **Facultatif** si `asset-types` est défini. + - `` : liste des [types d'éléments][2] (séparés par des virgules) d'où proviennent les événements de changement. **Facultatif** si `asset-names` est défini. + - `` : [type de contenu][3] **facultatif** des éléments d'où proviennent les événements de changement. + + +[1]: https://cloud.google.com/asset-inventory/docs/resource-name-format +[2]: https://cloud.google.com/asset-inventory/docs/supported-asset-types +[3]: https://cloud.google.com/asset-inventory/docs/overview#content_types +{{% /tab %}} +{{< /tabs >}} + +{{% /collapse-content %}} + +{{% collapse-content title= "Terraform" level="h4" %}} +### Créer un flux d'éléments + +Copiez le modèle Terraform suivant et remplacez les arguments nécessaires : + +{{< tabs >}} +{{% tab "Projet" %}} + +```h +locals { + project_id = "" +} + +resource "google_pubsub_topic" "pubsub_topic" { + project = local.project_id + name = "" +} + +resource "google_pubsub_subscription" "pubsub_subscription" { + project = local.project_id + name = "export-asset-changes-to-datadog" + topic = google_pubsub_topic.pubsub_topic.id +} + +resource "google_pubsub_subscription_iam_member" "subscriber" { + project = local.project_id + subscription = google_pubsub_subscription.pubsub_subscription.id + role = "roles/pubsub.subscriber" + member = "serviceAccount:" +} + +resource "google_cloud_asset_project_feed" "project_feed" { + project = local.project_id + feed_id = "" + content_type = "" # Facultatif. Supprimez cette ligne si non utilisée. + + asset_names = [""] # Facultatif si vous spécifiez asset_types. Supprimez cette ligne si non utilisée. + asset_types = [""] # Facultatif si vous spécifiez asset_names. Supprimez cette ligne si non utilisée.. + + feed_output_config { + pubsub_destination { + topic = google_pubsub_topic.pubsub_topic.id + } + } +} +``` + +Remplacez les placeholders comme indiqué ci-dessous : + + - `` : ID de votre projet Google Cloud. + - `` : le nom du sujet Pub/Sub associé à l'abonnement `export-asset-changes-to-datadog`. + - `` : adresse e-mail du compte de service utilisé par l’intégration Google Cloud de Datadog. + - `` : nom descriptif du flux d'inventaire d'éléments cloud. + - `` : liste des [noms complets][1] des ressources (séparés par des virgules) d'où proviennent les événements de changement. **Facultatif** si `asset-types` est défini. + - `` : liste des [types d'éléments][2] (séparés par des virgules) d'où proviennent les événements de changement. **Facultatif** si `asset-names` est défini. + - `` : [type de contenu][3] **facultatif** des éléments d'où proviennent les événements de changement. + + +[1]: https://cloud.google.com/asset-inventory/docs/resource-name-format +[2]: https://cloud.google.com/asset-inventory/docs/supported-asset-types +[3]: https://cloud.google.com/asset-inventory/docs/overview#content_types +{{% /tab %}} + +{{% tab "Dossier" %}} + +```h +locals { + project_id = "" +} + +resource "google_pubsub_topic" "pubsub_topic" { + project = local.project_id + name = "" +} + +resource "google_pubsub_subscription" "pubsub_subscription" { + project = local.project_id + name = "export-asset-changes-to-datadog" + topic = google_pubsub_topic.pubsub_topic.id +} + +resource "google_pubsub_subscription_iam_member" "subscriber" { + project = local.project_id + subscription = google_pubsub_subscription.pubsub_subscription.id + role = "roles/pubsub.subscriber" + member = "serviceAccount:" +} + +resource "google_cloud_asset_folder_feed" "folder_feed" { + billing_project = local.project_id + folder = "" + feed_id = "" + content_type = "" # Facultatif. Supprimez cette ligne si non utilisée. + + asset_names = [""] # Facultatif si vous spécifiez asset_types. Supprimez cette ligne si non utilisée. + asset_types = [""] # Facultatif si vous spécifiez asset_names. Supprimez cette ligne si non utilisée. + + feed_output_config { + pubsub_destination { + topic = google_pubsub_topic.pubsub_topic.id + } + } +} +``` + +Remplacez les placeholders comme indiqué ci-dessous : + + - `` : ID de votre projet Google Cloud. + -  : ID du dossier dans lequel créer ce flux. + - `` : le nom du sujet Pub/Sub associé à l'abonnement `export-asset-changes-to-datadog`. + - `` : adresse e-mail du compte de service utilisé par l’intégration Google Cloud de Datadog. + - `` : nom descriptif du flux d'inventaire d'éléments cloud. + - `` : liste des [noms complets][1] des ressources (séparés par des virgules) d'où proviennent les événements de changement. **Facultatif** si `asset-types` est défini. + - `` : liste des [types d'éléments][2] (séparés par des virgules) d'où proviennent les événements de changement. **Facultatif** si `asset-names` est défini. + - `` : [type de contenu][3] **facultatif** des éléments d'où proviennent les événements de changement. + + +[1]: https://cloud.google.com/asset-inventory/docs/resource-name-format +[2]: https://cloud.google.com/asset-inventory/docs/supported-asset-types +[3]: https://cloud.google.com/asset-inventory/docs/overview#content_types +{{% /tab %}} + +{{% tab "Organisation" %}} + +```h +locals { + project_id = "" +} + +resource "google_pubsub_topic" "pubsub_topic" { + project = local.project_id + name = "" +} + +resource "google_pubsub_subscription" "pubsub_subscription" { + project = local.project_id + name = "export-asset-changes-to-datadog" + topic = google_pubsub_topic.pubsub_topic.id +} + +resource "google_pubsub_subscription_iam_member" "subscriber" { + project = local.project_id + subscription = google_pubsub_subscription.pubsub_subscription.id + role = "roles/pubsub.subscriber" + member = "serviceAccount:" +} + +resource "google_cloud_asset_organization_feed" "organization_feed" { + billing_project = local.project_id + org_id = "" + feed_id = "" + content_type = "" # Facultatif. Supprimez cette ligne si non utilisée. + + asset_names = [""] # Facultatif si vous spécifiez asset_types. Supprimez cette ligne si non utilisée. + asset_types = [""] # Facultatif si vous spécifiez asset_names. Supprimez cette ligne si non utilisée. + + feed_output_config { + pubsub_destination { + topic = google_pubsub_topic.pubsub_topic.id + } + } +} +``` + +Remplacez les placeholders comme indiqué ci-dessous : + + - `` : ID de votre projet Google Cloud. + - `` : le nom du sujet Pub/Sub associé à l'abonnement `export-asset-changes-to-datadog`. + - `` : adresse e-mail du compte de service utilisé par l’intégration Google Cloud de Datadog. + - `` : ID de votre organisation Google Cloud. + - `` : nom descriptif du flux d'inventaire d'éléments cloud. + - `` : liste des [noms complets][1] des ressources (séparés par des virgules) d'où proviennent les événements de changement. **Facultatif** si `asset-types` est défini. + - `` : liste des [types d'éléments][2] (séparés par des virgules) d'où proviennent les événements de changement. **Facultatif** si `asset-names` est défini. + - `` : [type de contenu][3] **facultatif** des éléments d'où proviennent les événements de changement. + + +[1]: https://cloud.google.com/asset-inventory/docs/resource-name-format +[2]: https://cloud.google.com/asset-inventory/docs/supported-asset-types +[3]: https://cloud.google.com/asset-inventory/docs/overview#content_types +{{% /tab %}} +{{< /tabs >}} + +{{% /collapse-content %}} + +Datadog vous conseille de définir le paramètre `asset-types` sur l'expression régulière `.*` afin de recueillir les changements concernant toutes les ressources. + +**Remarque** : vous devez spécifier au moins une valeur pour le paramètre `asset-names` ou le paramètre `asset-types`. + +Consultez la section [gcloud asset feeds create][65] (en anglais) pour obtenir la liste complète des paramètres configurables. + +### Activer la collecte de données sur les changements de ressource + +Cliquez sur **Enable Resource Changes Collection** dans [l’onglet Resource Collection][58] de la page d’intégration Google Cloud. + +{{< img src="integrations/google_cloud_platform/enable_resource_change_collection.png" alt="Le bouton Enable Resource Changes Collection dans le carré d'intégration Google Cloud de Datadog" popup="true" style="width:80%;">}} + +#### Validation + +Consultez vos événements de changement d'élément dans l'[Events Explorer Datadog][66]. + +## Private Service Connect + + +{{< site-region region="us,us3,ap1,gov" >}} +
Private Service Connect n'est disponible que pour les sites US5 et EU de Datadog.
+{{< /site-region >}} + + +Utilisez l’[intégration Private Service Connect de Google Cloud][29] pour visualiser les connexions, les données transférées et les paquets rejetés via Private Service Connect. Cela vous permet de superviser les métriques clés de vos connexions PSC, qu’il s’agisse du côté producteur ou consommateur. +[Private Service Connect (PSC)][67] est un service de mise en réseau Google Cloud qui permet d’accéder à des [services Google Cloud][68], [services partenaires tiers][69] ou applications internes de manière privée depuis votre VPC (Virtual Private Cloud). + +Pour plus d’informations, consultez [Access Datadog privately and monitor your Google Cloud Private Service Connect usage][70] (en anglais) sur le blog de Datadog. ## Données collectées @@ -398,15 +995,15 @@ Consultez les différentes pages des intégrations Google Cloud pour en savoir #### Métriques cumulatives -Les métrique cumulatives sont importées dans Datadog avec une métrique `.delta` chaque nom de métrique. Une métrique cumulative est une métrique dont la valeur augmente constamment au fil du temps. Par exemple, une métrique pour `sent bytes` peut être cumulative. Chaque valeur enregistre le nombre total d'octets envoyés par un service à ce moment-là. La valeur delta représente la différence avec la mesure précédente. +Les métriques cumulatives sont importées dans Datadog avec une métrique `.delta` chaque nom de métrique. Une métrique cumulative est une métrique dont la valeur augmente constamment au fil du temps. Par exemple, une métrique pour `sent bytes` peut être cumulative. Chaque valeur enregistre le nombre total d'octets envoyés par un service à ce moment-là. La valeur delta représente la différence avec la mesure précédente. Exemple : - `gcp.gke.container.restart_count` est une métrique CUMULATIVE. Lors de l'importation de cette métrique en tant que métrique cumulative, Datadog ajoute la métrique `gcp.gke.container.restart_count.delta`, qui inclut les valeurs delta (par opposition à la valeur agrégée émise dans le cadre de la métrique CUMULATIVE). Référez-vous à a section [types de métriques Google Cloud][78] pour en savoir plus. + `gcp.gke.container.restart_count` est une métrique CUMULATIVE. Lors de l'importation de cette métrique en tant que métrique cumulative, Datadog ajoute la métrique `gcp.gke.container.restart_count.delta`, qui inclut les valeurs delta (par opposition à la valeur agrégée émise dans le cadre de la métrique CUMULATIVE). Référez-vous à a documentation relative aux [types de métriques de Google Cloud][71] pour en savoir plus. ### Événements -Tous les événements de service générés par Google Cloud Platform sont transférés vers votre [Events Explorer Datadog][79]. +Tous les événements de service générés par Google Cloud Platform sont transférés vers l'[Events Explorer Datadog][72]. ### Checks de service @@ -425,18 +1022,26 @@ En outre, Datadog recueille les éléments suivants en tant que tags : ### Mes métadonnées sont incorrectes pour les métriques _gcp.logging_ définies par l'utilisateur -Pour les métriques _gcp.logging_ non standard, comme les métriques qui ne correspondent pas aux [métriques de journalisation Datadog par défaut][80], les métadonnées appliquées peuvent différer de celles de Google Cloud Logging. +Pour les métriques _gcp.logging_ non standard, comme les métriques qui ne correspondent pas aux [métriques de journalisation Datadog prêtes à l'emploi][73], les métadonnées appliquées peuvent différer de celles de Google Cloud Logging. -Dans ce cas, les métadonnées doivent être définies manuellement sur la [page de résumé de la métrique][81] : recherchez et sélectionnez la métrique en question, puis cliquez sur l'icône en forme de crayon à côté des métadonnées. +Dans ce cas, les métadonnées doivent être définies manuellement sur la [page de résumé de la métrique][74] : recherchez et sélectionnez la métrique en question, puis cliquez sur l'icône en forme de crayon à côté des métadonnées. -Besoin d'aide ? Contactez [l'assistance Datadog][82]. +Besoin d'aide ? Contactez [l'assistance Datadog][75]. ## Pour aller plus loin +Documentation, liens et articles supplémentaires utiles : + +- [Améliorez la conformité et la sécurité de votre environnement Google Cloud avec Datadog][76] +- [Surveiller Google Cloud Vertex AI avec Datadog][77] +- [Surveiller des pipelines Dataflow avec Datadog][78] +- [Créer et gérer votre intégration Google Cloud avec Terraform][79] +- [Surveiller BigQuery avec Datadog][80] +- [Troubleshoot infrastructure changes faster with Recent Changes in the Resource Catalog][81] (en angmais) +- [Stream logs from Google Cloud to Datadog][82] (en anglais) -{{< partial name="whats-next/whats-next.html" >}} [1]: https://docs.datadoghq.com/fr/integrations/google_app_engine/ -[2]: https://docs.datadoghq.com/fr/integrations/google_bigquery/ +[2]: https://docs.datadoghq.com/fr/integrations/google_cloud_bigquery/ [3]: https://docs.datadoghq.com/fr/integrations/google_cloud_bigtable/ [4]: https://docs.datadoghq.com/fr/integrations/google_cloudsql/ [5]: https://docs.datadoghq.com/fr/integrations/google_cloud_apis/ @@ -469,51 +1074,51 @@ Besoin d'aide ? Contactez [l'assistance Datadog][82]. [32]: https://docs.datadoghq.com/fr/integrations/google_cloud_storage/ [33]: https://docs.datadoghq.com/fr/integrations/google_cloud_vertex_ai/ [34]: https://docs.datadoghq.com/fr/integrations/google_cloud_vpn/ -[35]: https://console.cloud.google.com/apis/library/cloudresourcemanager.googleapis.com -[36]: https://console.cloud.google.com/apis/library/cloudbilling.googleapis.com -[37]: https://console.cloud.google.com/apis/library/monitoring.googleapis.com -[38]: https://console.cloud.google.com/apis/library/compute.googleapis.com -[39]: https://console.cloud.google.com/apis/library/cloudasset.googleapis.com -[40]: https://console.cloud.google.com/apis/library/iam.googleapis.com -[41]: https://cloud.google.com/compute/docs/labeling-resources -[42]: https://cloud.google.com/dataflow -[43]: https://cloud.google.com/dataflow/docs/guides/templates/provided/pubsub-to-datadog -[44]: https://cloud.google.com/pubsub/docs/create-topic -[45]: https://cloud.google.com/pubsub/docs/create-subscription -[46]: https://cloud.google.com/iam/docs/using-iam-securely#least_privilege -[47]: https://cloud.google.com/logging/docs/export/configure_export_v2#creating_sink -[48]: https://cloud.google.com/logging/docs/view/logging-query-language -[49]: https://cloud.google.com/apis/docs/getting-started#enabling_apis -[50]: https://docs.datadoghq.com/fr/agent/ -[51]: https://cloud.google.com/vpc-service-controls/docs/supported-products#table_pubsub -[52]: https://console.cloud.google.com/cloudpubsub/topicList -[53]: https://console.cloud.google.com/cloudpubsub/subscription/ -[54]: https://cloud.google.com/dataflow/docs/concepts/streaming-with-cloud-pubsub#unsupported-features -[55]: https://cloud.google.com/dataflow/docs/guides/templates/provided/pubsub-to-datadog#template-parameters -[56]: https://cloud.google.com/dataflow/docs/guides/templates/provided/pubsub-to-pubsub -[57]: https://console.cloud.google.com/security/secret-manager -[58]: https://cloud.google.com/pubsub/quotas#quotas -[59]: https://cloud.google.com/compute/docs/access/service-accounts#default_service_account -[60]: https://console.cloud.google.com/iam-admin/serviceaccounts -[61]: https://cloud.google.com/dataflow/docs/concepts/access-control#dataflow.admin -[62]: https://cloud.google.com/dataflow/docs/concepts/access-control#dataflow.worker -[63]: https://cloud.google.com/pubsub/docs/access-control#pubsub.viewer -[64]: https://cloud.google.com/pubsub/docs/access-control#pubsub.subscriber -[65]: https://cloud.google.com/pubsub/docs/access-control#pubsub.publisher -[66]: https://cloud.google.com/secret-manager/docs/access-control#secretmanager.secretAccessor -[67]: https://cloud.google.com/storage/docs/access-control/iam-roles/ -[68]: https://console.cloud.google.com/logs/viewer -[69]: https://cloud.google.com/logging/docs/view/logging-query-language#sample -[70]: https://console.cloud.google.com/dataflow/createjob -[71]: https://cloud.google.com/kms/docs -[72]: https://cloud.google.com/dataflow/docs/guides/specifying-networks#shared -[73]: https://app.datadoghq.com/logs -[74]: https://cloud.google.com/products/calculator -[75]: https://docs.datadoghq.com/fr/monitors/types/metric/ -[76]: https://www.datadoghq.com/blog/datadog-recommended-monitors/ -[77]: https://www.datadoghq.com/blog/monitor-dataflow-pipelines-with-datadog/ -[78]: https://cloud.google.com/monitoring/api/v3/kinds-and-types -[79]: https://app.datadoghq.com/event/stream -[80]: https://docs.datadoghq.com/fr/integrations/google_stackdriver_logging/#metrics -[81]: https://app.datadoghq.com/metric/summary -[82]: https://docs.datadoghq.com/fr/help/ \ No newline at end of file +[35]: https://console.cloud.google.com/apis/library/monitoring.googleapis.com +[36]: https://console.cloud.google.com/apis/library/compute.googleapis.com +[37]: https://console.cloud.google.com/apis/library/cloudasset.googleapis.com +[38]: https://console.cloud.google.com/apis/library/cloudresourcemanager.googleapis.com +[39]: https://console.cloud.google.com/apis/library/iam.googleapis.com +[40]: https://console.cloud.google.com/apis/library/cloudbilling.googleapis.com +[41]: https://docs.datadoghq.com/fr/cloud_cost_management/setup/google_cloud/ +[42]: https://cloud.google.com/monitoring/settings#:~:text=A%20scoping%20project%20hosts%20a,is%20also%20a%20scoping%20project. +[43]: https://app.datadoghq.com/integrations/google-cloud-platform +[44]: https://cloud.google.com/compute/docs/labeling-resources +[45]: https://docs.datadoghq.com/fr/agent/ +[46]: https://docs.datadoghq.com/fr/data_security/data_retention_periods/ +[47]: https://docs.datadoghq.com/fr/integrations/gke/ +[48]: https://docs.datadoghq.com/fr/tracing/ +[49]: https://docs.datadoghq.com/fr/logs/ +[50]: https://docs.datadoghq.com/fr/agent/guide/why-should-i-install-the-agent-on-my-cloud-instances/ +[51]: https://cloud.google.com/bigquery/docs/access-control#bigquery.resourceViewer +[52]: https://console.cloud.google.com/iam-admin/ +[53]: https://app.datadoghq.com/datasets/tables/explore +[54]: https://cloud.google.com/bigquery/docs/access-control#bigquery.metadataViewer +[55]: https://console.cloud.google.com/bigquery +[56]: https://app.datadoghq.com/logs/pipelines/indexes +[57]: https://www.datadoghq.com/pricing/?product=log-management#products +[58]: https://app.datadoghq.com/integrations/google-cloud-platform?panel=resources +[59]: https://cloud.google.com/asset-inventory/docs/monitoring-asset-changes +[60]: https://app.datadoghq.com/event/explorer +[61]: https://console.cloud.google.com/cloudpubsub/topicList +[62]: https://console.cloud.google.com/cloudpubsub/subscription/ +[63]: https://cloud.google.com/shell +[64]: https://cloud.google.com/sdk/gcloud +[65]: https://cloud.google.com/sdk/gcloud/reference/asset/feeds/create +[66]: https://app.datadoghq.com/event/explorer?query=source%3Agoogle_cloud_asset_inventory +[67]: https://cloud.google.com/vpc/docs/private-service-connect +[68]: https://cloud.google.com/vpc/docs/private-service-connect-compatibility#google-services +[69]: https://cloud.google.com/vpc/docs/private-service-connect-compatibility#third-party-services +[70]: https://www.datadoghq.com/blog/google-cloud-private-service-connect/ +[71]: https://cloud.google.com/monitoring/api/v3/kinds-and-types +[72]: https://app.datadoghq.com/event/stream +[73]: https://docs.datadoghq.com/fr/integrations/google_stackdriver_logging/#metrics +[74]: https://app.datadoghq.com/metric/summary +[75]: https://docs.datadoghq.com/fr/help/ +[76]: https://www.datadoghq.com/blog/cspm-for-gcp-with-datadog/ +[77]: https://www.datadoghq.com/blog/google-cloud-vertex-ai-monitoring-datadog/ +[78]: https://www.datadoghq.com/blog/monitor-dataflow-pipelines-with-datadog/ +[79]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/integration_gcp_sts +[80]: https://www.datadoghq.com/blog/track-bigquery-costs-performance/ +[81]: https://www.datadoghq.com/blog/recent-changes-tab/ +[82]: https://cloud.google.com/architecture/partners/stream-cloud-logs-to-datadog \ No newline at end of file diff --git a/content/fr/integrations/pingdom_legacy.md b/content/fr/integrations/pingdom_legacy.md new file mode 100644 index 0000000000000..426c6f02f14ae --- /dev/null +++ b/content/fr/integrations/pingdom_legacy.md @@ -0,0 +1,112 @@ +--- +app_id: pingdom +app_uuid: bde11e46-65f6-4cee-b011-f0944c5fb5bb +assets: + integration: + auto_install: false + events: + creates_events: false + metrics: + check: pingdom.response_time + metadata_path: metadata.csv + prefix: pingdom. + service_checks: + metadata_path: assets/service_checks.json + source_type_id: 8 + source_type_name: API héritée Pingdom (V2.1) +author: + homepage: https://www.datadoghq.com + name: Datadog + sales_email: info@datadoghq.com + support_email: help@datadoghq.com +categories: +- monitors +custom_kind: integration +dependencies: [] +display_on_public_website: true +draft: false +git_integration_title: pingdom_legacy +integration_id: pingdom +integration_title: API héritée Pingdom (V2.1) +integration_version: '' +is_public: true +manifest_version: 2.0.0 +name: pingdom_legacy +public_title: API héritée Pingdom (V2.1) +short_description: Gérez et migrez des configurations existantes d'endpoints de surveillance + Pingdom obsolètes. +supported_os: [] +tile: + changelog: CHANGELOG.md + classifier_tags: + - Offering::Integration + - Category::Metrics + configuration: README.md#Setup + description: Gérez et migrez des configurations existantes d'endpoints de surveillance + Pingdom obsolètes. + media: [] + overview: README.md#Overview + support: README.md#Support + title: API héritée Pingdom (V2.1) +--- + + +## Section Overview + +
+Cette intégration est obsolète et l'API sur laquelle elle repose peut ne plus être prise en charge à tout moment. Utilisez plutôt l'intégration Datadog Pingdom V3. +
+ +Surveillez les métriques de performance axées sur l'utilisateur de Pingdom dans Datadog, afin de les corréler avec d'autres événements et métriques pertinents. + +Datadog surveille la métrique `response_time` pour tous les sites que vous configurez sur le site Web de Pingdom. + +Les événements de Pingdom peuvent être ajoutés en configurant le [monitor de statut d'intégration][1] adéquat. + +
+Les métriques peuvent uniquement être importées pour les clients Pingdom de niveau Starter ou supérieur. +
+ +## Configuration + +### Installation + +1. Ouvrez le carré d'intégration Pingdom. +2. Saisissez le nom d'utilisateur et le mot de passe de votre compte Pingdom. Si vous possédez un compte d'équipe, vous pouvez utiliser vos propres identifiants et spécifier le compte à partir duquel vous souhaitez effectuer des vérifications. +3. Vous pouvez ignorer certains checks en les décochant ou en ajoutant des tags aux événements qui seront générés. + +## Données collectées + +### Métriques +{{< get-metrics-from-git "pingdom_legacy" >}} + + +### Événements + +L'intégration Pingdom n'inclut aucun événement. + +### Checks de service + +L'intégration Pingdom récupère les checks de transaction et les signale en tant que checks de service. + +Pour le check `pingdom.status`, le tableau suivant présente les corrélations entre les checks de transaction Pingdom et les checks de service Datadog. + +| Statut Datadog | Statut Pingdom | +| -------------- | ------------------- | +| `OK` | `up` | +| `CRITICAL` | `down` | +| `WARNING` | `unconfirmed_down` | +| `UNKNOWN` | `unknown`, `paused` | + +## Dépannage + +### Erreur lors de la mise à jour du nom d'utilisateur ou du mot de passe + +Vous avez peut-être déjà rencontré l'erreur suivante lors de l'enregistrement de vos identifiants Pingdom : + +`“There was an issue while testing your Pingdom configuration: Not permitted for account type”`. + +Ajoutez l'adresse e-mail du propriétaire de votre compte Pingdom dans le champ **(Optional) Account to query**, puis enregistrez-la. + +[1]: https://app.datadoghq.com/monitors/create/integration +[2]: https://github.com/DataDog/dogweb/blob/prod/integration/pingdom/pingdom_metadata.csv \ No newline at end of file diff --git a/content/fr/logs/_index.md b/content/fr/logs/_index.md index 749f3e5548d2c..c4736015784af 100644 --- a/content/fr/logs/_index.md +++ b/content/fr/logs/_index.md @@ -71,8 +71,6 @@ La solution Log Management de Datadog (également appelée « logs Datadog » La solution Logging without Limits\* simplifie vos processus de dépannage dans le [Log Explorer][1]. Vos équipes et vous-même pouvez accéder rapidement aux problèmes concernant votre infrastructure et les corriger au plus vite. Les fonctionnalités intuitives d'archivage facilitent le travail d'audit et d'évaluation des équipes IT et de sécurité. Logging without Limits\* alimente également la solution [Cloud SIEM Datadog][2], qui détecte les menaces de sécurité dans votre environnement sans nécessiter l'indexation de vos logs. -**Remarque** : consultez la section [Conformité PCI DSS][3] pour obtenir des informations sur la mise en place d'une organisation Datadog conforme à la norme PCI. - {{< vimeo url="https://player.vimeo.com/progressive_redirect/playback/293195142/rendition/1080p/file.mp4?loc=external&signature=8a45230b500688315ef9c8991ce462f20ed1660f3edff3d2904832e681bd6000" poster="/images/poster/logs.png" >}}
@@ -124,7 +122,6 @@ Commencez à explorer vos logs ingérés dans le [Log Explorer][1]. [1]: /fr/logs/explorer/ [2]: /fr/security/cloud_siem/ -[3]: /fr/data_security/pci_compliance/ [4]: /fr/logs/log_collection/ [5]: /fr/logs/log_configuration/ [6]: /fr/tracing/other_telemetry/connect_logs_and_traces/ diff --git a/content/fr/logs/explorer/search_syntax.md b/content/fr/logs/explorer/search_syntax.md index 0f8f7a1184da1..263ffacaf6115 100644 --- a/content/fr/logs/explorer/search_syntax.md +++ b/content/fr/logs/explorer/search_syntax.md @@ -72,7 +72,7 @@ Utilisez la syntaxe `*:search_term` pour effectuer une recherche en texte intég Les caractères suivants, considérés comme spéciaux : `+` `-` `=` `&&` `||` `>` `<` `!` `(` `)` `{` `}` `[` `]` `^` `"` `“` `”` `~` `*` `?` `:` `\` `#`, ainsi que les espaces, doivent être échappés à l'aide du caractère `\`. - `/` n'est pas considéré comme un caractère spécial et n'a pas besoin d'être échappé. -- `@` ne peut pas être utilisé dans les requêtes de recherche dans Logs Explorer, car il est réservé à la [recherche d'attributs](#recherche-d-attributs). +- `@` ne peut pas être utilisé dans les requêtes de recherche dans Logs Explorer, car il est réservé à la [recherche d'attributs](#attributes-search). Il n'est pas possible de rechercher des caractères spéciaux dans un message de log. Il est possible de rechercher des caractères spéciaux lorsqu'ils se trouvent dans un attribut. @@ -94,7 +94,7 @@ Par exemple, si le nom de votre attribut est **url** et que vous souhaitez filtr 1. Vous n'avez **pas** besoin de définir une facette pour rechercher des attributs et des tags. -2. Les recherches d'attributs sont sensibles à la casse. Utilisez la [recherche en texte intégral](#recherche-en-texte-integral) pour obtenir des résultats insensibles à la casse. Une autre option consiste à utiliser le filtre `lowercase` avec votre parser Grok lors de l'analyse pour obtenir des résultats insensibles à la casse pendant la recherche. +2. Les recherches d'attributs sont sensibles à la casse. Utilisez la [recherche en texte intégral](#full-text-search) pour obtenir des résultats insensibles à la casse. Une autre option consiste à utiliser le filtre `lowercase` avec votre parser Grok lors de l'analyse pour obtenir des résultats insensibles à la casse pendant la recherche. 3. Lorsque vous recherchez une valeur d'attribut qui contient des caractères spéciaux, vous devez utiliser des caractères d'échappement ou des guillemets. - Par exemple, pour un attribut `my_attribute` ayant pour valeur `hello:world`, recherchez `@my_attribute:hello\:world` ou `@my_attribute:"hello:world"`. @@ -124,7 +124,7 @@ La fonction `CIDR()` prend en charge les notations CIDR IPv4 et IPv6, et fonctio ## Les wildcards -Vous pouvez utiliser des caractères génériques dans la recherche en texte libre. Toutefois, cela ne recherche que les termes présents dans le message de log, c'est-à-dire le texte de la colonne `content` dans Log Explorer. Référez-vous à la rubrique [Recherche en texte intégral](#recherche-en-texte-integral) si vous souhaitez rechercher une valeur dans un attribut de log. +Vous pouvez utiliser des caractères génériques dans la recherche en texte libre. Toutefois, cela ne recherche que les termes présents dans le message de log, c'est-à-dire le texte de la colonne `content` dans Log Explorer. Référez-vous à la rubrique [Recherche en texte intégral](#full-text-search) si vous souhaitez rechercher une valeur dans un attribut de log. ### Wildcard pour plusieurs caractères @@ -159,7 +159,7 @@ Lorsque vous recherchez une valeur d'attribut ou de tag qui contient des caract ## Valeurs numériques -Pour effectuer une recherche sur un attribut numérique, commencez par [l’ajouter comme facette][2]. Vous pourrez ensuite utiliser des opérateurs numériques (`<`, `>`, `<=` ou `>=`) pour effectuer une recherche sur ces facettes numériques. +Pour effectuer une recherche sur un attribut numérique, commencez par [l'ajouter comme facette][2]. Vous pourrez ensuite utiliser des opérateurs numériques (`<`, `>`, `<=` ou `>=`) pour effectuer une recherche sur ces facettes numériques. Par exemple, récupérez tous les logs dont le temps de réponse dépasse 100 ms avec :

diff --git a/content/fr/logs/log_collection/_index.md b/content/fr/logs/log_collection/_index.md index 39fae8b8db4d5..a273e77bba293 100644 --- a/content/fr/logs/log_collection/_index.md +++ b/content/fr/logs/log_collection/_index.md @@ -149,7 +149,6 @@ Utilisez le menu déroulant situé à droite de la page pour sélectionner votre | Site | Type | Endpoint | Port | Rôle | |------|-------------|---------------------------------------------------------------------------|--------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | US | HTTPS | `http-intake.logs.datadoghq.com` | 443 | Utilisé par les redirecteurs personnalisés pour envoyer des logs au format JSON ou texte brut via HTTPS. Consultez la [documentation relative à l'API Logs HTTP][1]. | -| US | HTTPS | `agent-http-intake-pci.logs.datadoghq.com` | 443 | Utilisé par l'Agent pour envoyer des logs via HTTPS à une organisation pour laquelle la conformité PCI DSS est activée. Consultez la section [Conformité PCI DSS pour Log Management][3] pour en savoir plus. | | US | HTTPS | `agent-http-intake.logs.datadoghq.com` | 443 | Utilisé par l'Agent pour envoyer des logs au format JSON via HTTPS. Consultez la [section Collecte de logs de l'Agent de host][2]. | | US | HTTPS | `lambda-http-intake.logs.datadoghq.com` | 443 | Utilisé par les fonctions Lambda pour envoyer des logs au format brut, Syslog ou JSON via HTTPS. | | US | HTTPS | `logs.`{{< region-param key="browser_sdk_endpoint_domain" code="true" >}} | 443 | Utilisé par le SDK Browser pour envoyer des logs au format JSON via HTTPS. | @@ -161,7 +160,6 @@ Utilisez le menu déroulant situé à droite de la page pour sélectionner votre [1]: /fr/api/latest/logs/#send-logs [2]: /fr/agent/logs/#send-logs-over-https -[3]: /fr/data_security/logs/#pci-dss-compliance-for-log-management {{< /site-region >}} {{< site-region region="eu" >}} diff --git a/content/fr/logs/log_configuration/pipelines.md b/content/fr/logs/log_configuration/pipelines.md index b5b86d1a1e087..35fe46ad10b0c 100644 --- a/content/fr/logs/log_configuration/pipelines.md +++ b/content/fr/logs/log_configuration/pipelines.md @@ -12,15 +12,30 @@ further_reading: - link: /logs/explorer/ tag: Documentation text: Apprendre à explorer vos logs +- link: /logs/troubleshooting/ + tag: Documentation + text: Dépannage des logs - link: https://learn.datadoghq.com/courses/going-deeper-with-logs-processing tag: Centre d'apprentissage text: Des analyses plus poussées grâce au traitement des logs +- link: https://www.datadoghq.com/blog/monitor-cloudflare-zero-trust/ + tag: Blog + text: Surveiller Cloudflare Zero Trust avec la solution Cloud SIEM de Datadog +- link: https://www.datadoghq.com/blog/monitor-1password-datadog-cloud-siem/ + tag: Blog + text: Surveiller 1Password avec la solution Cloud SIEM de Datadog +- link: https://www.datadoghq.com/blog/ocsf-common-data-model/ + tag: Blog + text: Normalisez vos données avec le modèle de données commun OCSF dans Datadog + Cloud SIEM title: Pipelines --- -## Présentation +## Section Overview + +
Les pipelines et processeurs décrits dans cette documentation sont spécifiques aux environnements de log cloud. Pour agréger, traiter et router des logs sur site, consultez la page Observability Pipelines.
-Datadog [parse][1] automatiquement les logs JSON. Lorsque les logs ne sont pas au format JSON, vous pouvez enrichir leurs données brutes en les faisant passer par un pipeline de traitement. Les pipelines traitent la grande majorité des formats de logs et les convertissent en un format commun dans Datadog. La mise en œuvre de pipelines de logs et d'une stratégie de traitement vous permet également de bénéficier d'une [convention de nommage des attributs][2] à l'échelle de votre organisation. +Datadog analyse automatiquement les logs au format JSON à l'aide du [parsing][1]. Vous pouvez ensuite enrichir tous vos logs (bruts et JSON) en les envoyant dans un pipeline de traitement. Les pipelines prennent en charge des logs de formats variés et les traduisent dans un format commun au sein de Datadog. Mettre en place une stratégie de pipelines et de traitement des logs est avantageux, car cela introduit une [convention de nommage des attributs][2] pour votre organisation. Avec les pipelines, les logs sont assemblés de façon séquentielle via des [processeurs][3] afin d'être parsés et enrichis. Cette étape permet d'extraire des informations ou des attributs utiles à partir de texte semi-structuré, afin de les réutiliser sous la forme de [facettes][4]. Lorsqu'un log passe par les pipelines, tous les filtres de pipeline lui sont appliqués. S'il répond aux critères d'un filtre, tous les processeurs associés lui sont appliqués de façon séquentielle. Il passe ensuite au prochain pipeline. @@ -114,7 +129,7 @@ Chaque entrée de log peut spécifier un niveau de statut. Celui-ci peut est dis * `level` * `syslog.severity` -Pour remapper un statut existant dans l'attribut `status`, utilisez le [remappeur de statuts de log][1]. +Vous pouvez préciser des attributs alternatifs à utiliser comme source pour le statut d'un log en définissant un [processeur de remappage de statut de log][1]. [1]: /fr/logs/log_configuration/processors/#log-status-remapper {{% /tab %}} @@ -147,6 +162,19 @@ Vous pouvez préciser des attributs alternatifs à utiliser comme source pour l' [1]: /fr/tracing/other_telemetry/connect_logs_and_traces/ [2]: /fr/logs/log_configuration/processors/#trace-remapper {{% /tab %}} + +{{% tab "Span ID" %}} + +#### Attribut Span ID + +Par défaut, les traceurs Datadog peuvent [injecter automatiquement les IDs de span dans vos logs][1]. Cependant, si un log au format JSON contient les attributs suivants, Datadog interprète leur valeur comme `span_id` du log : + +* `dd.span_id` +* `contextMap.dd.span_id` + +[1]: /fr/tracing/other_telemetry/connect_logs_and_traces/ +{{% /tab %}} + {{< /tabs >}} ## Créer un pipeline @@ -158,9 +186,9 @@ Vous pouvez préciser des attributs alternatifs à utiliser comme source pour l' **Remarque** : les filtres de pipeline sont appliqués avant tout traitement par les processeurs du pipeline. Par conséquent, vous ne pouvez pas appliquer un filtre basé sur un attribut qui est extrait dans le pipeline. 4. Donnez un nom à votre pipeline. -5. (Facultatif) Accordez un accès en modification aux processeurs dans le pipeline. -6. (Facultatif) Ajoutez des tags et une description au pipeline. La description peut être utilisée pour indiquer l'objectif du pipeline et l'équipe qui en est propriétaire. -7. Sélectionnez **Save**. +5. (Facultatif) Accorder un accès d'édition aux processeurs dans le pipeline. Si vous assignez un rôle à un pipeline, ce rôle reçoit les [autorisations][12] `logs_write_processor` spécifiquement limitées à ce pipeline. Les rôles disposant des autorisations `logs_write_processor` assignées globalement (via la modification du rôle) ne peuvent pas être sélectionnés, car ils ont accès à tous les pipelines. +6. (Facultatif) Ajoutez une description et des tags au pipeline pour indiquer son objectif et sa responsabilité. Les tags de pipeline n'affectent pas les logs, mais peuvent être utilisés pour filtrer et effectuer des recherches dans la [page Pipelines][5]. +7. Sélectionnez **Create**. Voici un exemple de log converti par un pipeline : @@ -172,16 +200,18 @@ Voici un exemple de log converti par un pipeline : Consultez la liste des intégrations prises en charge disponibles. -Les pipelines de traitement d'intégration sont disponibles pour certaines sources lorsqu'elles sont configurées pour recueillir les logs. Ces pipelines disposent d'un accès en **lecture seule** et effectuent le parsing de vos logs en tenant compte de la source en question. Un pipeline d'intégration est automatiquement installé pour les logs d'intégration, afin de prendre en charge leur parsing et d'ajouter la facette correspondante dans Log Explorer. +Les pipelines de traitement d'intégration sont disponibles pour certaines sources lorsqu'elles sont configurées pour recueillir les logs. Ces pipelines disposent d'un accès en **lecture seule** et effectuent le parsing de vos logs en tenant compte de la source en question. Un pipeline d'intégration est automatiquement installé pour les logs d'intégration, afin de prendre en charge leur parsing et d'ajouter la facette correspondante dans votre Log Explorer. Pour afficher un pipeline d'intégration, accédez à la page [Pipelines][5]. Pour modifier un pipeline d'intégration, clonez-le, puis modifiez le doublon : -{{< img src="logs/processing/pipelines/cloning_pipeline.png" alt="cloner un pipeline" style="width:80%;">}} +{{< img src="logs/processing/pipelines/cloning_pipeline.png" alt="Clonage d'un pipeline" style="width:80%;">}} Consultez l'exemple de logs ELB ci-dessous : {{< img src="logs/processing/elb_log_post_processing.png" alt="Post traitement de logs ELB" style="width:70%;">}} +**Remarque** : les pipelines d'intégration ne peuvent pas être supprimés, seulement désactivés. + ### Bibliothèque de pipelines d'intégration Pour afficher la liste complète des pipelines d'intégration proposés par Datadog, consultez la [bibliothèque de pipelines d'intégration][7]. Cette bibliothèque indique également comment Datadog traite les différents formats de log par défaut. @@ -202,7 +232,9 @@ Il est également possible de copier un pipeline d'intégration à l'aide du bou ### Processeurs -Un processeur s'exécute dans un pipeline afin d'effectuer une action de structuration de données. Consultez la [documentation relative aux processeurs][3] pour découvrir comment ajouter et configurer chaque type de processeur, que ce soit dans l'application ou avec l'API. +Un processeur s'exécute dans un pipeline afin d'effectuer une action de structuration de données. Consultez la [documentation relative aux processeurs][3] pour découvrir comment ajouter et configurer chaque type de processeur, que ce soit dans l'application ou avec l'API. + +Consultez la page [Parsing des dates][10] pour en savoir plus sur le parsing d'un format de date et d'heure personnalisé et sur le paramètre `timezone`, requis si vos horodatages ne sont pas en UTC. ### Pipelines imbriqués @@ -212,9 +244,11 @@ Un pipeline peut inclure des pipelines imbriqués et des processeurs, tandis qu' {{< img src="logs/processing/pipelines/nested_pipeline.png" alt="Pipelines imbriqués" style="width:80%;">}} -Il est possible de déplacer un pipeline vers un autre pipeline pour le transformer en pipeline imbriqué : +Déplacez un pipeline dans un autre pipeline pour le transformer en pipeline imbriqué : -{{< img src="logs/processing/pipelines/move_to_pipeline.mp4" alt="Faire glisser et déposer des pipelines imbriqués" video="true" width="80%" >}} +1. Survolez le pipeline que vous souhaitez déplacer, puis cliquez sur l'icône **Déplacer vers**. +1. Sélectionnez le pipeline dans lequel vous souhaitez intégrer le pipeline d'origine. **Remarque** : les pipelines contenant des pipelines imbriqués ne peuvent être déplacés que vers une position de niveau supérieur. Ils ne peuvent pas être déplacés dans un autre pipeline. +1. Cliquez sur **Move**. ## Gérer vos pipelines @@ -228,7 +262,7 @@ Réorganisez vos pipelines avec précision à l'aide de l'option `Move to` dans ## Métriques d'estimation d'utilisation -Les métriques d'estimation d'utilisation fournissent des données propres à un pipeline. Elles indiquent le volume et le nombre de logs ingérés et modifiés par chaque pipeline. Vous disposez également d'un lien vers le [dashboard d'estimation de l'utilisation des logs][10] prêt à l'emploi pour chaque pipeline. Ce dashboard présente les métriques d'utilisation d'un pipeline à l'aide de graphiques détaillés. +Des métriques d'utilisation estimées sont affichées par pipeline, notamment le volume et le nombre de logs ingérés et modifiés par chaque pipeline. Un lien vers le [tableau de bord d'estimation de l'utilisation des logs][11] prêt à l'emploi est également disponible dans chaque pipeline, vous permettant de consulter ses métriques d'utilisation sous forme de graphiques détaillés. {{< img src="logs/processing/pipelines/log_pipeline_statistics.png" alt="Comment consulter une vue d'ensemble des métriques d'utilisation de vos pipelines" style="width:50%;">}} @@ -248,4 +282,6 @@ Les métriques d'estimation d'utilisation fournissent des données propres à un [7]: https://app.datadoghq.com/logs/pipelines/pipeline/library [8]: https://app.datadoghq.com/logs/pipelines/remapping [9]: /fr/integrations/#cat-log-collection -[10]: https://app.datadoghq.com/dash/integration/logs_estimated_usage \ No newline at end of file +[10]: /fr/logs/log_configuration/parsing/?tab=matchers#parsing-dates +[11]: https://app.datadoghq.com/dash/integration/logs_estimated_usage +[12]: /fr/account_management/rbac/permissions/?tab=ui#log-management \ No newline at end of file diff --git a/content/fr/metrics/custom_metrics/_index.md b/content/fr/metrics/custom_metrics/_index.md new file mode 100644 index 0000000000000..c529146c7751d --- /dev/null +++ b/content/fr/metrics/custom_metrics/_index.md @@ -0,0 +1,145 @@ +--- +algolia: + tags: + - custom metrics +aliases: +- /fr/guides/metrics/ +- /fr/metrictypes/ +- /fr/units/ +- /fr/developers/metrics/datagram_shell +- /fr/developers/metrics/custom_metrics/ +- /fr/getting_started/custom_metrics +- /fr/developers/metrics/ +- /fr/metrics/guide/tag-configuration-cardinality-estimation-tool/ +further_reading: +- link: /developers/dogstatsd/ + tag: Documentation + text: En savoir plus sur DogStatsD +- link: /developers/community/libraries/ + tag: Documentation + text: Bibliothèques client de Datadog et sa communauté pour DogStatsD et les API +- link: /account_management/billing/custom_metrics/?tab=countrate + tag: Documentation + text: Facturation des métriques custom +- link: /metrics/guide/custom_metrics_governance/ + tag: Guide + text: Bonne pratique pour la gouvernance des métriques custom +- link: https://www.datadoghq.com/blog/metrics-without-limits/ + tag: Blog + text: Contrôler de façon dynamique le volume de vos métriques custom grâce à Metrics + without Limits™ +title: Métriques custom +--- + +{{< learning-center-callout header="Participez un webinar de formation" hide_image="true" btn_title="Inscription" btn_url="https://www.datadoghq.com/technical-enablement/sessions/?tags.topics-0=Metrics">}} + Explorez et inscrivez-vous aux sessions Foundation Enablement sur les métriques personnalisées. Découvrez comment ces métriques vous aident à suivre les KPI de vos applications, comme le nombre de visiteurs, la taille moyenne des paniers, la latence des requêtes ou la répartition des performances d'un algorithme personnalisé. +{{< /learning-center-callout >}} + +## Section Overview + +Les métriques custom vous permettent de suivre les KPI de votre application : nombre de visiteurs, taille moyenne du panier client, latence des requêtes ou répartition des performances pour un algorithme personnalisé. Une métrique custom est identifiée par **une combinaison unique du nom de la métrique et des valeurs de tags (y compris le tag de host)**. Dans l'exemple ci-dessous, la métrique `request.Latency` comporte quatre combinaisons uniques de valeurs de tags issues de ses deux clés de tag : + +- `endpoint`, qui a pour valeur `endpoint:X` ou `endpoint:Y` ; +- `status`, qui a pour valeur `status:200` ou `status:400`. + +{{< img src="account_management/billing/custom_metrics/request_latency.png" alt="Latence des requêtes" style="width:80%;">}} + +Les éléments suivants sont également considérés comme des métriques custom : +- Globalement, toute métrique soumise par l'intermédiaire de [DogStatsD][3] ou d'un [check custom d'Agent][4] +- Les métriques envoyées par les intégrations [Marketplace][29] +- Certaines [intégrations standard](#integrations-standard) peuvent potentiellement émettre des métriques custom +- Les métriques envoyées depuis une intégration qui ne fait pas partie des [plus de {{< translate key="integration_count" >}} intégrations Datadog][1]. + +**Remarque** : les utilisateurs ayant le rôle Admin Datadog ou la permission `usage_read` peuvent consulter le nombre mensuel moyen de métriques custom par heure, ainsi que les 5 000 métriques custom les plus utilisées pour leur compte sur la [page des détails sur l'utilisation][5]. Pour en savoir plus, consultez la page [sur le mode de comptabilisation des métriques custom][6]. + +## Propriétés des métriques custom + +Les métriques custom Datadog possèdent les propriétés ci-dessous. Consultez la [présentation des métriques][7] pour découvrir comment représenter graphiquement des métriques au sein de Datadog. + +| Propriété | Rôle | +|------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------| +| `` | Le [nom de votre métrique](#nom-des-metriques-custom). | +| `` | La valeur de votre métrique. **Remarque** : les valeurs des métriques respecter un format 32 bits. Elles ne doivent pas représenter des dates ou des timestamps. | +| `` | Le timestamp associé à la valeur de la métrique. **Remarque** : les timestamps des métriques ne peuvent pas correspondre à une date plus d'une heure avant l'événement et plus de 10 minutes après celui-ci. | +| `` | L'ensemble des tags associés à votre métrique. | +| `` | Le type de votre métrique. En savoir plus sur les [types de métriques][8]. | +| `` | Si le `` de la métrique est [RATE][9] ou [COUNT][10], cette propriété définit l'[intervalle][11] correspondant. | + +### Nom des métriques custom + +La convention de nommage suivante s'applique aux métriques custom : + +* Les noms des métriques doivent commencer par une lettre. +* Les noms de métriques doivent contenir uniquement des caractères alphanumériques ASCII, des underscores et des points. + * Les autres caractères, y compris les espaces, sont remplacés par des underscores. + * Le format Unicode n'est _pas_ pris en charge. +* Les noms de métriques ne doivent pas dépasser 200 caractères. Nous vous recommandons d'utiliser moins de 100 caractères pour une meilleure lisibilité sur l'interface. + +**Remarque** : les noms de métrique sont sensibles à la casse dans Datadog. + +### Unités des métriques + +Définissez les unités des métriques via le [Résumé des métriques][12] ou définissez des unités personnalisées pour les métriques à l'aide de la fonctionnalité [Remplacement des unités][13] dans l'éditeur de graphiques de vos visualisations. Pour plus d'informations, consultez la documentation relative aux [unités de métriques][14]. + +## Envoi de métriques custom + +{{< whatsnext desc="Il existe plusieurs façons d'envoyer des métriques à Datadog :">}} + {{< nextlink href="/metrics/custom_metrics/agent_metrics_submission" >}}Check d'Agent custom{{{< /nextlink >}} + {{< nextlink href="/metrics/custom_metrics/dogstatsd_metrics_submission" >}}DogStatsD{{< /nextlink >}} + {{< nextlink href="/metrics/custom_metrics/powershell_metrics_submission" >}}PowerShell{{< /nextlink >}} + {{< nextlink href="/serverless/custom_metrics" >}}AWS Lambda{{< /nextlink >}} + {{< nextlink href="/api/v1/metrics/#submit-metrics" >}}API HTTP Datadog{{{< /nextlink >}} + {{< nextlink href="/logs/log_configuration/logs_to_metrics/#generate-a-log-based-metric" >}}Générer des métriques basées sur des logs{{< /nextlink >}} + {{< nextlink href="/tracing/generate_metrics/" >}}Générer des métriques basées sur des spans APM{{< /nextlink >}} + {{< nextlink href="/real_user_monitoring/platform/generate_metrics/" >}}Générer des métriques basées sur les événements du RUM{{< /nextlink >}} + {{< nextlink href="/infrastructure/process/increase_process_retention/#generate-a-process-based-metric" >}}Générer des mesures basées sur les live processes{{< /nextlink >}} +{{< /whatsnext >}} + +Vous pouvez également utiliser l'une des [bibliothèques client de Datadog et sa communauté pour DogStatsD et les API][15] afin d'envoyer vos métriques custom. + +**Remarque** : aucune limite de débit fixe n'est appliquée lors de l'envoi des métriques custom. Si vous dépassez votre nombre de métriques par défaut, vous serez facturé conformément à la [politique de facturation de Datadog pour les métriques custom][6]. + +## Intégrations standard + +Les intégrations standard suivantes peuvent potentiellement générer des métriques custom. + +| Types d'intégrations | Intégrations | +|------------------------------------------------|------------------------------------------------------------------------------------| +| Limitées à 350 métriques custom par défaut. | [ActiveMQ XML][16] / [Go-Expvar][17] / [Java-JMX][18] | +| Aucune limite appliquée à la collecte de métriques custom par défaut. | [Nagios][19] / [PDH Check][20] / [OpenMetrics][21] / [Compteurs de performances Windows][22] / [WMI][23] / [Prometheus][21] | +| Peuvent être configurées pour collecter des métriques custom. | [MySQL][24] /[Oracle][25] /[Postgres][26] /[SQL Server][27] | +| Métriques custom envoyées depuis des intégrations cloud | [AWS][28] | + +## Pour aller plus loin + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /fr/integrations/ +[2]: /fr/account_management/billing/custom_metrics/#standard-integrations +[3]: /fr/metrics/custom_metrics/dogstatsd_metrics_submission/ +[4]: /fr/metrics/custom_metrics/agent_metrics_submission/ +[5]: https://app.datadoghq.com/account/usage/hourly +[6]: /fr/account_management/billing/custom_metrics/#counting-custom-metrics +[7]: /fr/metrics +[8]: /fr/metrics/types/ +[9]: /fr/metrics/types/?tab=rate#metric-types +[10]: /fr/metrics/types/?tab=count#metric-types +[11]: /fr/developers/dogstatsd/data_aggregation/#how-is-aggregation-performed-with-the-dogstatsd-server +[12]: /fr/metrics/summary/#metric-unit +[13]: /fr/dashboards/guide/unit-override/ +[14]: /fr/metrics/units/ +[15]: /fr/developers/community/libraries/ +[16]: /fr/integrations/activemq/#activemq-xml-integration +[17]: /fr/integrations/go_expvar/ +[18]: /fr/integrations/java/ +[19]: /fr/integrations/nagios +[20]: /fr/integrations/pdh_check/ +[21]: /fr/integrations/openmetrics/ +[22]: /fr/integrations/windows_performance_counters/ +[23]: /fr/integrations/wmi_check/ +[24]: /fr/integrations/mysql/ +[25]: /fr/integrations/oracle/ +[26]: /fr/integrations/postgres/ +[27]: /fr/integrations/sqlserver/ +[28]: /fr/integrations/amazon_web_services/ +[29]: /fr/integrations/#cat-marketplace \ No newline at end of file diff --git a/content/fr/metrics/types.md b/content/fr/metrics/types.md index cd92936682ea4..8d98b1c8091bd 100644 --- a/content/fr/metrics/types.md +++ b/content/fr/metrics/types.md @@ -1,4 +1,7 @@ --- +algolia: + tags: + - metric types aliases: - /fr/developers/metrics/counts/ - /fr/developers/metrics/distributions/ @@ -13,13 +16,16 @@ further_reading: - link: developers/dogstatsd tag: Documentation text: En savoir plus sur DogStatsD +- link: /metrics/units + tag: Documentation + text: Unités de métriques - link: developers/libraries tag: Documentation text: Bibliothèques client de Datadog et sa communauté pour DogStatsD et les API title: Types de métriques --- -## Présentation +## Section Overview Chaque métrique envoyée à Datadog doit posséder un type. Le type d'une métrique définit l'affichage des valeurs de la métrique renvoyées, ainsi que les fonctionnalités graphiques associées reposant sur des [modificateurs][1] et des [fonctions][2] supplémentaires dans Datadog. Le type d'une métrique figure dans le volet latéral des détails de votre métrique sur la page [Metrics Summary][3]. @@ -83,7 +89,7 @@ Le type de métrique envoyé GAUGE représente un snapshot des événements surv {{% /tab %}} {{% tab "HISTOGRAM" %}} -Le type de métrique envoyé HISTOGRAM représente la distribution statistique d'un ensemble de valeurs calculées côté Agent sur un intervalle unique. Le type de métrique HISTOGRAM de Datadog est une extension du type de métrique timing de StatsD. L'Agent agrège les valeurs envoyées durant un intervalle donné et génère différentes métriques représentant l'ensemble de valeurs. +Le type de métrique envoyé HISTOGRAM représente la distribution statistique d'un ensemble de valeurs calculées côté Agent sur un intervalle unique. Le type de métrique HISTOGRAM de Datadog est une extension du type de métrique de durée (timing) de StatsD. L'Agent agrège les valeurs envoyées durant un intervalle donné et génère différentes métriques représentant l'ensemble de valeurs. Si vous envoyez `X` valeurs pour la métrique HISTOGRAM `` durant un intervalle donné, l'Agent génère par défaut les métriques suivantes : @@ -155,7 +161,7 @@ Si vous envoyez `X` valeurs pour la métrique DISTRIBUTION `` du {{< tabs >}} {{% tab "COUNT" %}} -Imaginons que vous envoyiez la métrique COUNT `activeusers.basket_size` depuis un seul host sur lequel l'Agent Datadog s'exécute. Ce host génère les valeurs suivantes lors de l'intervalle de transmission : `[1,1,1,2,2,2,3,3]`. +Imaginons que vous envoyiez la métrique COUNT `notifications.sent` depuis un seul host sur lequel l'Agent Datadog s'exécute. Ce host génère les valeurs suivantes lors de l'intervalle de transmission : `[1,1,1,2,2,2,3,3]`. L'Agent ajoute toutes les valeurs reçues durant cet intervalle. Il envoie ensuite le total, ici `15`, en tant que valeur de la métrique COUNT. @@ -176,7 +182,7 @@ L'Agent envoie la dernière valeur transmise, ici `71.5`, pour la métrique GAUG {{% /tab %}} {{% tab "HISTOGRAM" %}} -Imaginons que vous envoyez la métrique HISTOGRAM `request.response_time.histogram` à partir d'un serveur Web. Celle-ci envoie les valeurs `[1,1,1,2,2,2,3,3]` lors de l'intervalle de transmission. Par défaut, l'Agent transmet les métriques suivantes à Datadog afin de représenter la distribution statistique des valeurs lors de l'intervalle : +Imaginons que vous envoyez la métrique HISTOGRAM `request.response_time.histogram` à partir d'un serveur Web. Celle-ci envoie les valeurs `[1,1,1,2,2,2,3,3]` lors de l'intervalle de transmission de 10 secondes. Par défaut, l'Agent transmet les métriques suivantes à Datadog afin de représenter la distribution statistique des valeurs lors de l'intervalle : | Nom de la métrique | Valeur | Type stocké dans Datadog | | ---------------------------------------------- | ------ | ------------------- | @@ -245,10 +251,10 @@ Envoyez vos métriques de type COUNT depuis l'une des sources suivantes : **Remarque** : lorsque vous envoyez une métrique de type COUNT via DogStatsD, la métrique stockée dans Datadog possède le type RATE, afin de garantir la pertinence des comparaisons entre les différents Agents. Par conséquent, les nombres totaux StatsD peuvent comporter des décimales dans Datadog (puisqu'ils sont normalisés sur un intervalle dans le but de transmettre des unités par seconde). -[1]: /fr/metrics/agent_metrics_submission/?tab=count#count -[2]: /fr/metrics/agent_metrics_submission/?tab=count#monotonic-count +[1]: /fr/metrics/custom_metrics/agent_metrics_submission/?tab=count#count +[2]: /fr/metrics/custom_metrics/agent_metrics_submission/?tab=count#monotonic-count [3]: /fr/api/v1/metrics/#submit-metrics -[4]: /fr/metrics/dogstatsd_metrics_submission/#count +[4]: /fr/metrics/custom_metrics/dogstatsd_metrics_submission/#count {{% /tab %}} {{% tab "RATE" %}} @@ -262,7 +268,7 @@ Envoyez vos métriques de type RATE depuis l'une des sources suivantes : **Remarque** : lorsque vous envoyez une métrique de type RATE via DogStatsD, la métrique stockée dans Datadog possède le type GAUGE, afin de garantir la pertinence des comparaisons entre les différents Agents. -[1]: /fr/metrics/agent_metrics_submission/?tab=rate +[1]: /fr/metrics/custom_metrics/agent_metrics_submission/?tab=rate [2]: /fr/api/v1/metrics/#submit-metrics {{% /tab %}} {{% tab "GAUGE" %}} @@ -276,9 +282,9 @@ Envoyez vos métriques de type GAUGE depuis l'une des sources suivantes : | [DogStatsD][3] | `dog.gauge(...)` | GAUGE | GAUGE | -[1]: /fr/metrics/agent_metrics_submission/?tab=gauge +[1]: /fr/metrics/custom_metrics/agent_metrics_submission/?tab=gauge [2]: /fr/api/v1/metrics/#submit-metrics -[3]: /fr/metrics/dogstatsd_metrics_submission/#gauge +[3]: /fr/metrics/custom_metrics/dogstatsd_metrics_submission/#gauge {{% /tab %}} {{% tab "HISTOGRAM" %}} @@ -292,9 +298,9 @@ Envoyez vos métriques de type HISTOGRAM depuis l'une des sources suivantes : L'envoi d'une métrique TIMER à l'Agent Datadog correspond à l'envoi d'une métrique HISTOGRAM dans DogStatsD. Ne confondez pas les métriques TIMER avec les timers StatsD standard. Les [`TIMER` DogStatsD][3] représentent uniquement les données caractérisées par une durée, par exemple le temps d'exécution d'une section de code ou le temps d'affichage d'une page entière. -[1]: /fr/metrics/agent_metrics_submission/?tab=histogram -[2]: /fr/metrics/dogstatsd_metrics_submission/#histogram -[3]: /fr/metrics/dogstatsd_metrics_submission/#timer +[1]: /fr/metrics/custom_metrics/agent_metrics_submission/?tab=histogram +[2]: /fr/metrics/custom_metrics/dogstatsd_metrics_submission/#histogram +[3]: /fr/metrics/custom_metrics/dogstatsd_metrics_submission/#timer {{% /tab %}} {{% tab "DISTRIBUTION" %}} @@ -305,7 +311,7 @@ Envoyez vos métriques de type DISTRIBUTION depuis la source suivante : | [DogStatsD][1] | `dog.distribution(...)` | DISTRIBUTION | GAUGE, COUNT | -[1]: /fr/metrics/dogstatsd_metrics_submission/#distribution +[1]: /fr/metrics/custom_metrics/dogstatsd_metrics_submission/#distribution {{% /tab %}} {{< /tabs >}} @@ -334,21 +340,21 @@ Vous trouverez ci-dessous une synthèse de l'ensemble des sources et des méthod {{< partial name="whats-next/whats-next.html" >}} -[1]: /fr/metrics/type_modifiers/ +[1]: /fr/metrics/custom_metrics/type_modifiers/ [2]: /fr/dashboards/functions/ [3]: /fr/metrics/summary/ -[4]: https://statsd.readthedocs.io/en/v3.2.2/types.html#sets -[5]: /fr/metrics/agent_metrics_submission/ -[6]: /fr/metrics/dogstatsd_metrics_submission/ +[4]: https://statsd.readthedocs.io/en/v3.3/types.html#sets +[5]: /fr/metrics/custom_metrics/agent_metrics_submission/ +[6]: /fr/metrics/custom_metrics/dogstatsd_metrics_submission/ [7]: /fr/api/v1/metrics/#submit-metrics [8]: /fr/developers/dogstatsd/#how-it-works -[9]: /fr/metrics/agent_metrics_submission/?tab=count#count -[10]: /fr/metrics/agent_metrics_submission/?tab=count#monotonic-count -[11]: /fr/metrics/agent_metrics_submission/?tab=gauge -[12]: /fr/metrics/agent_metrics_submission/?tab=histogram -[13]: /fr/metrics/agent_metrics_submission/?tab=rate -[14]: /fr/metrics/dogstatsd_metrics_submission/#gauge -[15]: /fr/metrics/dogstatsd_metrics_submission/#distribution -[16]: /fr/metrics/dogstatsd_metrics_submission/#count -[17]: /fr/metrics/dogstatsd_metrics_submission/#set -[18]: /fr/metrics/dogstatsd_metrics_submission/#histogram \ No newline at end of file +[9]: /fr/metrics/custom_metrics/agent_metrics_submission/?tab=count#count +[10]: /fr/metrics/custom_metrics/agent_metrics_submission/?tab=count#monotonic-count +[11]: /fr/metrics/custom_metrics/agent_metrics_submission/?tab=gauge +[12]: /fr/metrics/custom_metrics/agent_metrics_submission/?tab=histogram +[13]: /fr/metrics/custom_metrics/agent_metrics_submission/?tab=rate +[14]: /fr/metrics/custom_metrics/dogstatsd_metrics_submission/#gauge +[15]: /fr/metrics/custom_metrics/dogstatsd_metrics_submission/#distribution +[16]: /fr/metrics/custom_metrics/dogstatsd_metrics_submission/#count +[17]: /fr/metrics/custom_metrics/dogstatsd_metrics_submission/#set +[18]: /fr/metrics/custom_metrics/dogstatsd_metrics_submission/#histogram \ No newline at end of file diff --git a/content/fr/monitors/notify/variables.md b/content/fr/monitors/notify/variables.md new file mode 100644 index 0000000000000..01417d81b4c8b --- /dev/null +++ b/content/fr/monitors/notify/variables.md @@ -0,0 +1,715 @@ +--- +description: Utiliser des variables pour personnaliser les notifications de vos monitors +further_reading: +- link: /monitors/guide/template-variable-evaluation/ + tag: Guide + text: Utiliser des opérations et des fonctions arithmétiques à l'aide d'évaluations + de template variables +- link: /monitors/ + tag: Documentation + text: Créer des monitors +- link: /monitors/notify/ + tag: Documentation + text: Notifications des monitors +- link: /monitors/manage/ + tag: Documentation + text: Gérer les monitors +- link: https://learn.datadoghq.com/courses/alert-monitor-notifications + tag: Centre d'apprentissage + text: Suivez une formation pour apprendre à personnaliser les notifications de vos + monitors d'alerte. +- link: https://www.datadoghq.com/blog/monitor-notification-rules/ + tag: Blog + text: Dirigez vos alertes de monitor avec les règles de notification des monitors + Datadog +title: Variables +--- + +Utilisez des variables dans les messages de notification pour afficher un contenu conditionnel et router la notification vers différentes équipes grâce aux [variables conditionnelles](#variables-conditionnelles), ou pour enrichir le contenu en utilisant des [variables d'attributs et d'étiquettes](#variables-d-attributs-et-d-etiquettes) et des [variables de modèle](#variables-de-modèle). + +## Variables conditionnelles + +Les variables conditionnelles reposent sur une logique `if-else` pour afficher un message personnalisé en fonction de l'état du monitor et des détails de son déclenchement. Ces variables peuvent être utilisées dans le sujet ou le corps du message de la notification. + +Voici la liste des variables conditionnelles disponibles : + +| Variable conditionnelle | Condition d'affichage du texte | +|----------------------------|--------------------------------------------------------------------| +| `{{#is_alert}}` | Le monitor génère une alerte. | +| `{{^is_alert}}` | Le monitor ne génère pas d'alerte. | +| `{{#is_match}}` | Le contexte correspond à la sous-chaîne fournie. Si une valeur numérique est utilisée, elle est convertie en chaîne.| +| `{{^is_match}}` | Le contexte ne correspond pas à la sous-chaîne indiquée. | +| `{{#is_exact_match}}` | Le contexte correspond exactement à la chaîne fournie.
Si une valeur numérique est utilisée, sa valeur est prise en compte, quel que soit son type. Cela signifie que deux nombres de même valeur seront considérés comme égaux par la fonction. | +| `{{^is_exact_match}}` | Le contexte ne correspond pas exactement à la chaîne indiquée. | +| `{{#is_no_data}}` | Le monitor s'est déclenché en raison de données manquantes. | +| `{{^is_no_data}}` | Le monitor ne s'est pas déclenché en raison de données manquantes. | +| `{{#is_warning}}` | Le monitor génère un avertissement. | +| `{{^is_warning}}` | Le monitor ne génère pas d'avertissement. | +| `{{#is_recovery}}` | Le monitor est rétabli depuis un état `ALERT`, `WARNING`, `UNKNOWN` ou `NO DATA`. | +| `{{^is_recovery}}` | Le monitor n'est pas rétabli depuis un état `ALERT`, `WARNING`, `UNKNOWN` ou `NO DATA`. | +| `{{#is_warning_recovery}}` | Le monitor passe d'un état `WARNING` à un état `OK`. | +| `{{^is_warning_recovery}}` | Le monitor ne passe pas d'un état `WARNING` à un état `OK`. | +| `{{#is_alert_recovery}}` | Le monitor passe d'un état `ALERT` à un état `OK`. | +| `{{^is_alert_recovery}}` | Le monitor ne passe pas d'un état ALERT à un état OK. | +| `{{#is_alert_to_warning}}` | Le monitor passe d'un état `ALERT` à un état `WARNING`. | +| `{{^is_alert_to_warning}}` | Le monitor ne passe pas d'un état `ALERT` à un état `WARNING`. | +| `{{#is_no_data_recovery}}` | Le monitor est rétabli depuis un état `NO DATA`. | +| `{{^is_no_data_recovery}}` | Le monitor n'est pas rétabli depuis un état `NO DATA`. | +| `{{#is_priority 'valeur'}}` | Le monitor possède la priorité `valeur`, qui va de `P1` à `P5`. | +| `{{#is_unknown}}` | Le monitor possède un état inconnu. | +| `{{^is_unknown}}` | Le monitor ne possède pas un état inconnu. | +| `{{#is_renotify}}` | Le monitor renvoie des notifications. | +| `{{^is_renotify}}` | Le monitor ne renvoie pas de notification. | + +### Exemples + +La variable conditionnelle doit comporter un élément d'ouverture et un élément de fermeture entourant le texte et les **notifications « @ »**. + +{{< tabs >}} +{{% tab "is_alert" %}} + +Pour envoyer un message de notification lorsqu'un monitor génère une alerte, utilisez le format suivant : + +```text +{{#is_alert}} + <@-NOTIFICATION> +{{/is_alert}} +``` + +{{% /tab %}} +{{% tab "is_warning" %}} + +Pour envoyer un message de notification lorsqu'un monitor génère un avertissement, utilisez le format suivant : + +```text +{{#is_warning}} + <@-NOTIFICATION> +{{/is_warning}} +``` + +{{% /tab %}} +{{% tab "is_recovery" %}} + +Pour envoyer un message de notification lorsqu'un monitor est rétabli, utilisez le format suivant : + +```text +{{#is_recovery}} + <@-NOTIFICATION> +{{/is_recovery}} +``` + +{{% /tab %}} +{{% tab "is_match" %}} + +Pour rechercher une sous-chaîne dans une [variable de tag](#variables-d-attribut-et-de-tag), utilisez le format suivant : + +```text +{{#is_match ".name" ""}} + Cela s'affiche si fait partie de . +{{/is_match}} +``` + +Pour informer votre équipe DB qu'un host déclencheur dispose du tag `role:db_cassandra` ou `role:db_postgres`, utilisez le format suivant : + +```text +{{#is_match "role.name" "db"}} + Cela s'affiche si le nom du rôle du host qui a déclenché l'alerte contient `db`. @db-team@company.com +{{/is_match}} +``` + +La condition `is_match` prend également en charge plusieurs chaînes : + +```text +{{#is_match "role.name" "db" "database"}} + Cela s'affiche si le nom du rôle du host qui a déclenché l'alerte contient `db` ou `database`. + @db-team@company.com +{{/is_match}} +``` + +Pour envoyer une autre notification lorsque le tag ne contient pas `db`, utilisez la négation de la condition tel que suit : + +```text +{{^is_match "role.name" "db"}} + Cela s'affiche si le tag du rôle ne contient pas `db`. + @slack-example +{{/is_match}} +``` + +Vous pouvez également utiliser le paramètre `{{else}}` dans le premier exemple : + +```text +{{#is_match "role.name" "db"}} + Cela s'affiche si le nom du rôle du host qui a déclenché l'alerte contient `db`. + @db-team@company.com +{{else}} + Cela s'affiche si le tag du rôle ne contient pas `db`. + @slack-example +{{/is_match}} +``` +**Remarque** : pour vérifier si une `` n'existe pas ou si elle est vide, utilisez `is_exact_match`. Voir l'onglet `is_exact_match` pour plus de détails. + +{{% /tab %}} +{{% tab "is_exact_match" %}} + +Pour rechercher une chaîne exacte dans une [variable de tag](#variables-d-attribut-et-de-tag), utilisez le format suivant : + +```text +{{#is_exact_match ".name" ""}} + Cela s'affiche si correspond exactement à . +{{/is_exact_match}} +``` + +Pour informer votre équipe de développement lorsqu'un host déclencheur dispose du nom `production`, utilisez le format suivant : + +```text +{{#is_exact_match "host.name" "production"}} + Cela s'affiche si le host qui a déclenché l'alerte s'intitule précisément « production ». @dev-team@company.com +{{/is_exact_match}} +``` + +La condition `is_exact_match` prend également en charge la correspondance avec plusieurs chaînes : + +```text +{{#is_exact_match "host.name" "production" "staging"}} + Ce message s'affiche si le host qui a déclenché l'alerte s'appelle + exactement production ou staging. @dev-team@company.com +{{/is_exact_match}} +``` + +La variable conditionnelle `is_exact_match` prend également en charge les [variables de modèle `{{value}}`](#variables-de-modele) : + +```text +{{#is_exact_match "value" ""}} + Ceci s'affiche si la valeur ayant dépassé le seuil du monitor est exactement . +{{/is_exact_match}} +``` + +Pour notifier votre équipe de développement si la valeur ayant dépassé le seuil du monitor est 5 (ou 5.0), utilisez l'exemple suivant : + +```text +{{#is_exact_match "value" "5"}} + Ce message s'affiche si la valeur ayant dépassé le seuil du monitor est 5. @dev-team@company.com +{{/is_exact_match}} +``` + +La variable conditionnelle `is_exact_match` prend également en charge une chaîne vide pour le `` afin de vérifier si l’attribut ou le tag est vide ou n’existe pas. +```text +{{#is_exact_match "host.datacenter" ""}} + Ce message s'affiche si l'attribut ou le tag n'existe pas ou s'il est vide +{{/is_match}} +``` + + +{{% /tab %}} +{{% tab "is_renotify" %}} + +Pour envoyer un message de réaffectation à une autre destination, seulement pour l'environnement `production` : + +```text +{{#is_renotify}} +{{#is_match "env" "production"}} + Ceci est un message de réaffectation envoyé à @dev-team@company.com +{{/is_match}} +{{/is_renotify}} +``` + +Pour envoyer un autre message de réaffectation qui ne contient pas les informations du message d'origine, utilisez à la fois les blocs `{{^is_renotify}}` et `{{#is_renotify}}` : + +```text +{{^is_renotify}} +Ce monitor possède un état d'alerte et envoie un premier message à @dev-team@company.com + +Pour rétablir l'état de ce monitor, suivez les étapes suivantes : +1. Allez ici +2. Faites ceci +{{/is_renotify}} + +Cette section est générique et est envoyée pour le premier déclenchement et le message de réaffectation. +{{#is_renotify}} + Ceci est le message de réaffectation @dev-team@company.com +{{/is_renotify}} + +``` + +Dans la nouvelle notification du monitor, les utilisateurs pourront lire le message de réaffectation suivant : + +``` +Cette section est générique et est envoyée pour le premier déclenchement et le message de réaffectation. + +Ceci est le message de réaffectation @dev-team@company.com +``` + +{{% /tab %}} +{{< /tabs >}} + +Si vous configurez un bloc conditionnel pour une transition d'état vers les conditions `alert` ou `warning` avec une mention **@-notifications**, il est recommandé de configurer une condition `recovery` correspondante afin qu'une notification de rétablissement soit envoyée à cette même mention. + +**Remarque** : tout texte ou handle de notification placé **en dehors** des variables conditionnelles configurées est invoqué à chaque changement d'état du monitor. À l'inverse, tout texte ou handle de notification placé **au sein** des variables conditionnelles configurées est invoqué uniquement si le changement d'état du monitor respecte la condition. + +## Variables d'attribut et de tag + +Utilisez des variables d'attributs et de tag pour créer des messages d'alerte personnalisés, informatifs et ciblés afin de mieux comprendre la nature de l'alerte. Voir les sections suivantes pour des exemples et cas d'usage : +- [Variables à alertes multiples](#variables-a-alertes-multiples) +- [Variables d'attributs et d'étiquettes correspondantes](#variables-d-attributs-et-d-etiquettes-correspondantes) + +Tags +: automatiquement associés (comme le nom de host, le nom du conteneur, le nom du fichier de log ou le nom de la fonction serverless) ou ajoutés via des tags personnalisés (comme l'équipe responsable, l'environnement, l'application ou la version). + +Attributs +: basés sur le contenu du log et soit analysés, soit ajoutés à l'aide de recherches dans des tables de référence (par exemple, geoip). + +**Remarque** : Si le monitor est configuré pour se rétablir en cas d'absence de données (par exemple, lorsqu'aucun événement ne correspond à la requête), le message de rétablissement ne contient aucune donnée. Pour conserver des informations dans le message de rétablissement, effectuez un groupement par des tags supplémentaires, accessibles via `{{tag.name}}`. + +### Variables à alertes multiples + +Configurez des variables à alertes multiples dans des [monitors à alertes multiples][1] en fonction de la dimension sélectionnée dans la section du groupe à alertes multiples. Enrichissez le contenu de la notification en incluant de façon dynamique la valeur associée au groupe en fonction des dimensions de chaque alerte. + +**Remarque** : lorsque vous utilisez le champ `group_by` pour l'agrégation, des tags et des alertes supplémentaires issus du monitor peuvent être hérités automatiquement. Cela signifie que toute alerte ou configuration définie sur l'endpoint surveillé pourrait être appliquée à chaque groupe résultant de l'agrégation. + +{{< tabs >}} +{{% tab "Regrouper par tag" %}} + +Lorsqu'une métrique possède un tag au format `key:value` et que la requête du monitor est regroupée en fonction de ce tag, utilisez la variable suivante : + +``` +{{ key.name }} +``` + +Cette variable insère la `value` associée à la `key` dans chaque notification d’alerte. Par exemple, si votre monitor déclenche une alerte pour chaque `env`, alors la variable `{{env.name}}` est disponible dans votre message de notification. + +Si un groupe possède plusieurs `values` associées à la même `key`, le message d'alerte affiche une chaîne contenant toutes les valeurs, séparées par des virgules, dans l'ordre lexicographique. + +#### Clé de tag avec un point + +Si la clé de votre tag contient un point, entourez l'intégralité de la clé avec des crochets lors de l'utilisation d'une variable de tag. Par exemple, si votre tag est `dot.key.test:five` et que votre monitor est groupé par `dot.key.test`, utilisez : + +```text +{{[dot.key.test].name}} +``` + +{{% /tab %}} + +{{% tab "Regrouper par facette" %}} + +Les log monitors, monitors d'analyse de traces, monitors RUM et monitors d'événement peuvent utiliser des facettes en tant que variables lorsqu'ils sont regroupés par facette. Si un log monitor est regroupé en fonction de `@facet_key`, utilisez la variable suivante : + +```text +{{ @facet_key.name }} +``` + +**Exemple** : pour inclure les informations spécifiques d'un groupe de monitors de logs à alertes multiples, effectuez un regroupement selon `@machine_id` : + +```text +Cette alerte a été déclenchée sur {{ @machine_id.name }} +``` + +Si votre facette comporte des points, placez-la entre crochets. Par exemple : + +```text +{{ [@network.client.ip].name }} +``` + +{{% /tab %}} +{{< /tabs >}} + +#### Personnaliser la notification en fonction du groupe + +Lorsque votre requête est groupée par certaines dimensions, vous pouvez enrichir les notifications avec les métadonnées dynamiques associées au groupe. Pour voir la liste des variables de tag en fonction de votre sélection, cliquez sur **Use message template variables** (Utiliser des variables de modèle de message) dans la section **Configure notifications & automations** (Configurer les notifications et automatisations). Voici des exemples : + +{{% collapse-content title="Requête avec group by host" level="h5" %}} + +Si votre monitor déclenche une alerte pour chaque `host`, alors les variables de tag `{{host.name}}` et `{{host.ip}}` sont disponibles, ainsi que tout tag de host disponible sur ce host. + +Variables spécifiques aux métadonnées du host : + +- Version de l'Agent : `{{host.metadata_agent_version}}` +- Machine : `{{host.metadata_machine}}` +- Plateforme : `{{host.metadata_platform}}` +- Processeur : `{{host.metadata_processor}}` +{{% /collapse-content %}} + +{{% collapse-content title="Requête avec group by kube_namespace et kube_cluster_name" level="h5" %}} +Si votre monitor déclenche une alerte pour chaque `kube_namespace` et `kube_cluster_name`, vous pouvez alors accéder à n'importe quel attribut de l'espace de nommage. + +Variables de métadonnées de l'espace de nommage : + +- Nom du cluster : `{{kube_namespace.cluster_name}}` +- Nom de l'espace de nommage : `{{kube_namespace.display_name}}` +- Statut de l’espace de nommage : `{{kube_namespace.status}}` +- Étiquettes de l'espace de nommage : `{{kube_namespace.labels}}` + +Le tableau suivant contient tous les attributs disponibles : + +| Syntaxe de la variable | Attributs de premier niveau | +|-------------------|------------------------| +| `{{kube_namespace.key}}` | `k8s_namespace_key`, `tags`, `annotations`, `cluster_id`, `cluster_name`, `creation_timestamp`, `deletion_timestamp`, `display_name`, `external_id`, `finalizers`, `first_seen_at`, `group_size`, `labels`, `name`, `namespace`, `status`, `uid`| +{{% /collapse-content %}} + +{{% collapse-content title="Requête avec group by pod_name, kube_namespace et kube_cluster_name" level="h5" %}} +Si votre monitor déclenche une alerte pour chaque `pod_name`, `kube_namespace` et `kube_cluster_name`, vous pouvez alors accéder à n'importe quel attribut du pod. + +Variables de métadonnées du pod : +- Nom du cluster : `{{pod_name.cluster_name}}` +- Nom du pod : `{{pod_name.name}}` +- Phase du pod : `{{pod_name.phase}}` + +Le tableau suivant contient tous les attributs disponibles : + +| Syntaxe de la variable | Attributs de premier niveau | +|-------------------|------------------------| +| `{{pod_name.key}}` | `k8s_pod_key`, `tags`, `annotations`, `cluster_id`, `cluster_name`, `conditions`, `container_statuses`, `creation_timestamp`, `deletion_timestamp`, `display_name`, `external_id`, `finalizers`, `first_seen_at`, `host_id`, `host_key`, `hostname`, `init_container_statuses`, `ip`, `labels`, `name`, `namespace`, `node_name`, `nominated_node_name`, `phase`, `pod_scheduled_timestamp`, `priority_class_name`, `qosclass`, `resource_requirements`, `uid`| +{{% /collapse-content %}} + + +{{% collapse-content title="Requête avec group by service" level="h5" %}} + +Si votre monitor déclenche une alerte pour chaque `service`, alors vous pouvez accéder à certains attributs du service, tels que définis dans le [Software Catalog][10]. + +Variables de métadonnées de service : + +- Nom du service : `{{service.name}}` +- Nom de l'équipe : `{{service.team}}` +- Docs : `{{service.docs}}` +- Liens : `{{service.links}}` + +Pour les documents et liens, vous pouvez également accéder à un élément spécifique avec la syntaxe suivante : `[]`. Par exemple, pour les services qui disposent d'un schéma de définition comme celui défini dans [cet exemple][11], vous pouvez accéder au lien « Runbook » en utilisant la syntaxe suivante : + +```texte +{{service.links[Runbook]}} +``` +{{% /collapse-content %}} + + + +### Correspondance des variables d'attribut et de tag + +
Disponible pour + les monitors de log , + les monitors Trace Analytics (APM), + les monitors Error Tracking , + les monitors RUM , + les monitors CI , and + les monitors Database Monitoring. +
+ +Pour inclure **n’importe quel** attribut ou tag provenant d'un log, d'un span de trace, d'un événement RUM, d'un pipeline CI ou d'un événement de test CI correspondant à la requête du monitor, utilisez les variables suivantes : + +| Type de monitor | Syntaxe de la variable | +|-----------------|--------------------------------------------------| +| Log | `{{log.attributes.key}}` ou `{{log.tags.key}}` | +| Analyse de traces | `{{span.attributes.key}}` ou `{{span.tags.key}}` | +| Error Tracking | `{{issue.attributes.key}}` | +| RUM | `{{rum.attributes.key}}` ou `{{rum.tags.key}}` | +| Piste d'audit | `{{audit.attributes.key}}` ou `{{audit.message}}` | +| Pipeline CI | `{{cipipeline.attributes.key}}` | +| Test de CI | `{{citest.attributes.key}}` | +| Database Monitoring | `{{databasemonitoring.attributes.key}}` | + +{{% collapse-content title= "Exemple d'utilisation de la syntaxe" level="h4" %}} +- Pour n'importe quelle paire `key:value`, la variable `{{log.tags.key}}` affiche la `value` dans le message d'alerte. +- Le `@` qui précède tous les attributs n'est pas inclus. Par exemple, si un monitor de log est groupé par `@http.status_code`, vous pouvez inclure le message d'erreur ou les tags d'infrastructure dans le message de notification en utilisant les variables suivantes : + + ```text + {{ log.attributes.[error.message] }} + {{ log.tags.env }} + ... + ``` + + {{< img src="monitors/notifications/tag_attribute_variables.png" alt="Syntaxe des variables d'attribut correspondantes"style="width:90%;">}} +- Le message affiche l'attribut `error.message` d'un log correspondant à la requête, **tant que l'attribut existe**. +- Si le tag est présent sur un événement, utilisez la syntaxe suivante : + + ```text + {{ event.tags.[dot.key.test] }} + ``` + + +{{% /collapse-content %}} + + +#### Remarques importantes + +- Si l'événement sélectionné n'inclut pas la clé d'attribut ou de tag, la variable apparaîtra vide dans le message de notification. Pour éviter les notifications manquantes, n'utilisez pas ces variables pour router les notifications avec des handles `{{#is_match}}`. +- Pour les monitors qui utilisent des formules et des fonctions dans leurs requêtes, les valeurs sont résolues à partir des événements extraits de la première requête. + + +#### Attributs réservés + +Les événements de logs, de gestion des événements, de spans, de RUM, de Pipeline CI et de tests CI disposent d'attributs réservés génériques, que vous pouvez utiliser dans les variables avec la syntaxe suivante : + +| Type de monitor | Syntaxe de la variable | Attributs de premier niveau | +|-----------------|-------------------|------------------------| +| Log | `{{log.key}}` | `message`, `service`, `status`, `source`, `span_id`, `timestamp`, `trace_id`, `link`, `host` | +| Analyse de traces | `{{span.key}}` | `env`, `operation_name`, `resource_name`, `service`, `status`, `span_id`, `timestamp`, `trace_id`, `type`, `link` | +| RUM | `{{rum.key}}` | `service`, `status`, `timestamp`, `link` | +| Événement | `{{event.key}}` | `attributes`, `host.name`, `id`, `link`, `title`, `text`, `tags` | +| Pipeline CI | `{{cipipeline.key}}` | `service`, `env`, `resource_name`, `ci_level`, `trace_id`, `span_id`, `pipeline_fingerprint`, `operation_name`, `ci_partial_array`, `status`, `timestamp`, `link` | +| Test de CI | `{{citest.key}}` | `service`, `env`, `resource_name`, `trace_id`, `span_id`, `operation_name`, `status`, `timestamp`, `link` | + +Si l'événement correspondant ne contient pas l'attribut dans sa définition, la variable n'affiche rien. + +#### Lien Explorer + +Utilisez `{{log.link}}`, `{{span.link}}`, `{{rum.link}}`, et `{{issue.link}}` pour enrichir la notification avec un lien vers le Log Explorer, le Trace Explorer, le RUM Explorer ou Error Tracking, ciblé sur les événements correspondant à la requête. + +### Variables des monitors de check + +Pour les monitors de check (check custom et check d'intégration), vous pouvez utiliser la variable `{{check_message}}` afin d'afficher le message du check custom ou du check d'intégration. + +### Variables des monitors composite + +Les monitors composite peuvent accéder à la valeur et à l'état associés aux sous-monitors au moment du déclenchement de l'alarme. + +Par exemple, si votre monitor composite possède un sous-monitor `a`, vous pouvez inclure la valeur de `a` avec : + +```text +{{ a.value }} +``` + +Pour récupérer le statut du sous-monitor `a`, utilisez : + +```text +{{ a.status }} +``` + +Les valeurs possibles pour l'état sont : `OK`, `Alert`, `Warn` et `No Data`. + +Les monitors composite prennent également en charge les variables de tag, tout comme leurs monitors sous-jacents. Ils reprennent le même format que les autres monitors, tant que les monitors sous-jacents sont regroupés en fonction du même tag ou de la même facette. + +Par exemple, supposons que votre monitor composite comporte un sous-monitor `a`, qui est un monitor de logs. Vous pouvez inclure la valeur de n'importe quel tag ou facette de `a` avec : + +```text +{{ a.log.message }} ou {{ a.log.my_facet }} +``` + +### Échappement de caractères + +Par défaut, le contenu des variables est échappé par défaut. Pour éviter que du contenu JSON ou du code soit échappé, utilisez trois accolades au lieu de deux. Exemple : `{{{event.text}}}`. + +## Template variables + +Utilisez des template variables pour personnaliser les notifications de votre monitor. Voici la liste des variables intégrées : + +| Variable | Rôle | +|----------------------------------- |-------------------------------------------------------------------------------| +| `{{value}}` | La valeur qui a déclenché l'alerte pour les monitors de requête basés sur des métriques. | +| `{{threshold}}` | La valeur du seuil d'alerte défini dans les conditions d'alerte du monitor. | +| `{{warn_threshold}}` | La valeur du seuil d'avertissement défini dans les conditions d'alerte du monitor. | +| `{{alert_recovery_threshold}}` | La valeur qui a permis de sortir le monitor de l'état `ALERT`. | +| `{{warn_recovery_threshold}}` | La valeur qui a permis de sortir le monitor de l'état `WARN`. | +| `{{ok_threshold}}` | La valeur qui a permis de sortir le monitor de check de service. | +| `{{comparator}}` | La valeur relationnelle définie dans les conditions d'alerte du monitor. | +| `{{first_triggered_at}}`
*Voir la section ci-dessous* | La date et l'heure UTC auxquelles le monitor a été déclenché pour la première fois. | +| `{{first_triggered_at_epoch}}`
*Voir la section ci-dessous* | La date et l'heure UTC auxquelles le monitor a été déclenché pour la première fois, en millisecondes Unix. | +| `{{last_triggered_at}}`
*Voir la section ci-dessous* | La date et l'heure UTC du dernier déclenchement du monitor. | +| `{{last_triggered_at_epoch}}`
*Voir la section ci-dessous* | La date et l'heure UTC du dernier déclenchement du monitor, au format EPOCH en millisecondes. | +| `{{triggered_duration_sec}}` | Le nombre de secondes pendant lesquelles le monitor est resté dans un état déclenché. | + +### Variables déclenchées + + Les variables de modèle `{{first_triggered_at}}`, `{{first_triggered_at_epoch}}`, `{{last_triggered_at}}` et `{{last_triggered_at_epoch}}` reflètent les valeurs au moment d'un changement d'état du monitor, et **NON** à chaque nouvel événement du monitor. Les événements de renotification affichent la même variable si l'état du monitor n'a pas changé. Utilisez `{{triggered_duration_sec}}` pour afficher la durée au moment de l'événement. + + `{{first_triggered_at}}` est défini lorsque le groupe de monitor passe de `OK` à un état différent de `OK`, ou lorsqu'un nouveau groupe apparaît dans un état non `OK`. `{{last_triggered_at}}` est défini quand le groupe de monitor passe à un état non `OK`, quel que soit l'état précédent (y compris `WARN` → `ALERT`, `ALERT` → `WARN`). `{{last_triggered_at}}` est également défini lorsqu'un nouveau groupe apparaît dans un état non `OK`. La différence est que `{{last_triggered_at}}` est indépendant de l'état précédent. + + {{< img src="monitors/notifications/triggered_variables.png" alt="Transitions montrant quatre horodatages A : 1419 OK vers WARN, B : 1427 WARN vers ALERT, C : 1445 ALERT vers NO DATA, D : 1449 NO DATA vers OK" style="width:90%;" >}} + +**Exemple** : lorsque le monitor passe de `OK` à `WARN`, les variables `{{first_triggered_at}}` et `{{last_triggered_at}}` auront toutes deux la valeur de l'horodatage A. Le tableau ci-dessous affiche les valeurs jusqu'à la récupération du monitor. + +| Transition | first_triggered_at | last_triggered_at | triggered_duration_sec | +|------------------ |-------------------------------- |-------------------------------- |-------------------------------- | +| `OK` → `WARN` | A | A | 0 | +| `WARN` → `ALERT` | A | B | B - A | +| `ALERT` → `NO DATA`| A | C | C - A | +| `NO DATA` → `OK` | A | C | D - A | + +### Évaluation + +Les template variables qui renvoient des valeurs numériques prennent en charge les opérations et les fonctions. Vous pouvez ainsi effectuer des opérations mathématiques ou mettre en forme les valeurs. Pour en savoir plus, consultez la rubrique [Évaluer des template variables][7]. + +### Heure locale + +La fonction `local_time` vous permet d'ajouter une autre date dans votre notification, avec le fuseau horaire de votre choix. Cette fonction transforme une date en une heure locale : `{{local_time 'time_variable' 'timezone'}}`. Par exemple, pour afficher l'heure du dernier déclenchement du monitor dans votre notification en fonction du fuseau horaire de Tokyo, ajoutez ce qui suit au message de notification : + +``` +{{local_time 'last_triggered_at' 'Asia/Tokyo'}} +``` + +Le résultat s'affiche au format ISO 8601 : `yyyy-MM-dd HH:mm:ss±HH:mm`, par exemple `2021-05-31 23:43:27+09:00`. Consultez la [liste des fuseaux horaires de la base de données TZ][8], notamment la colonne de nom, pour obtenir la liste des valeurs de fuseau horaire disponibles. + +## Réglages avancés + +### Handles dynamiques + +Utilisez des [variables de tag](#variables-d-attribut-et-de-tag) pour générer de façon dynamiques les handles des notifications et transmettre ces dernières à la bonne équipe ou au bon service, en fonction du type de problème détecté par le monitor. + +**Exemple** : si votre monitor interroge une métrique et la regroupe en fonction d'un tag `service`, vous pouvez transmettre vos notifications à différents canaux Slack, en fonction du service défaillant : + +```text +@slack-{{service.name}} Un problème est en cours pour le service {{service.name}}. +``` + +Si votre monitor commence à détecter des échecs pour le groupe `service:ad-server`, la notification est envoyée au canal Slack `#ad-server`, avec le contexte suivant : + +```text +@slack-ad-server Un problème est en cours pour le service ad-server. +``` + +Lorsque vous créez des handles dynamiques avec des attributs qui peuvent être absents, cela peut poser des problèmes de livraison des notifications. Si un attribut est manquant, la variable sera vide dans le message de notification, ce qui rend le handle invalide. + +Pour éviter les notifications manquées avec ces variables, pensez à ajouter un handle de secours : + +```text +{{#is_exact_match "kube_namespace.owner" ""}} + @slack-example + // Cela enverra une notification à @slack-example si la variable kube_namespace.owner est vide ou inexistante. +{{/is_match}} +``` + + +### Liens dynamiques + +Utilisez des [variables de tag](#variables-d-attribut-et-de-tag) pour activer la création d'URL dynamiques. Celles-ci vous permettent de rediriger votre équipe vers la ressource adéquate. Par exemple, vous pouvez fournir des liens vers des pages de Datadog : dashboards, hostmap, monitors, etc. + +{{< tabs >}} +{{% tab "Dashboards" %}} + +Utilisez la [variable de tag](#variables-d-attribut-et-de-tag) `{{host.name}}` pour fournir un lien vers un dashboard système : + +```text +https://app.datadoghq.com/dash/integration/system_overview?tpl_var_scope=host:{{host.name}} +``` + +Utilisez la [variable de tag](#variables-d-attribut-et-de-tag) `{{host.name}}`, en prenant soin de remplacer `` par le nom d'une intégration, pour fournir un lien vers le dashboard de cette intégration : + +```text +https://app.datadoghq.com/dash/integration/?tpl_var_scope=host:{{host.name}} +``` + +Utilisez la [template variable](#template-variable) `{{last_triggered_at_epoch}}` ainsi qu’un `` et un `` pour créer un lien vers des dashboards avec une plage temporelle relative à l’alerte : + +```text +https://app.datadoghq.com/dashboard//?from_ts={{eval "last_triggered_at_epoch-10*60*1000"}}&to_ts={{eval "last_triggered_at_epoch+10*60*1000"}}&live=false +``` + +{{% /tab %}} +{{% tab "Hostmap" %}} + +Utilisez une [variable de tag](#variables-d-attribut-et-de-tag) comme `{{service.name}}` pour fournir un lien vers la hostmap : + +```text +https://app.datadoghq.com/infrastructure/map?filter=service:{{service.name}} +``` + +Vous pouvez personnaliser le lien vers la hostmap en définissant des paramètres supplémentaires. Voici les paramètres les plus utilisés : + +| Paramètre | Défini par | Fonction | +|-----------|----------------------------|--------------------------------------| +| `fillby` | `fillby=avg:` | Détermine la couleur de remplissage des hexagones des hosts. | +| `groupby` | `groupby=` | Détermine les groupes d'hexagones des hosts. | +| `sizeby` | `sizeby=avg:` | Détermine la taille des hexagones des hosts. | + +{{% /tab %}} +{{% tab "Monitors" %}} + +Utilisez la [variable de tag](#variables-d-attribut-et-de-tag) `{{host.name}}` pour fournir un lien vers tous les monitors associés à un certain host : + +```text +https://app.datadoghq.com/monitors/manage?q=scope:host:{{host.name}} +``` + +Vous pouvez personnaliser le lien vers les monitors en définissant des paramètres supplémentaires. Voici les paramètres les plus utilisés : + +| Paramètre | Exemple | Contenu affiché | +|-----------|----------------|---------------------------------------------------------------------------------| +| `status` | `status:Alert` | Les monitors avec un état d'alerte (statuts supplémentaires : `WARN`, `NO DATA` et `OK`) | +| `muted` | `muted: true` | Les monitors désactivés (indiquez `false` pour afficher les monitors qui ne sont pas désactivés) | +| `type` | `type:log` | Les log monitors (découvrez les autres [types de monitors][1]) | + + + +[1]: /fr/monitors/types +{{% /tab %}} +{{% tab "Logs" %}} + +Utilisez la [template variable](#template-variable) `{{last_triggered_at_epoch}}` pour fournir un lien vers tous les logs en cours au moment de l'alerte. + +```text +https://app.datadoghq.com/logs?from_ts={{eval "last_triggered_at_epoch-10*60*1000"}}&to_ts={{eval "last_triggered_at_epoch+10*60*1000"}}&live=false +``` + +Le lien vers les logs est personnalisable avec des paramètres supplémentaires. Les plus courants sont : + +| Paramètre | Défini par | Fonction | +|-----------|----------------------------|----------------------------------------| +| `service` | `service=` | Filtre sur les logs d'un service spécifique. | +| `host` | `host=` | Filtre sur les logs d'un host spécifique. | +| `status` | `status=` | Statut des logs : Error, Warn, Info, etc. | + + +{{% /tab %}} +{{< /tabs >}} + +### Commentaires + +Pour ajouter un commentaire dans le message du monitor, utilisez la syntaxe suivante : + +```text +{{!-- ceci est un commentaire --}} +{{!-- ceci est un commentaire }} +``` + +### Format brut + +Si votre message d'alerte doit envoyer deux accolades, par exemple `{{ }}`, utilisez le format `{{{{raw}}}}`. Exemple : + +```text +{{{{raw}}}} +{{ }} {{ }} +{{{{/raw}}}} +``` + +Résultat : + +```text +{{ }} {{ }} +``` + +Les auxiliaires `^|#` utilisés dans les [variables conditionnelles](#variables-conditionnelles) ne peuvent pas être utilisés avec le format `{{{{raw}}}}` et doivent être supprimés. Par exemple, pour générer un texte brut de sortie avec la variable conditionnelle `{{is_match}}`, utilisez le modèle suivant : + +```text +{{{{is_match "host.name" ""}}}} +{{ .matched }} le hostname +{{{{/is_match}}}} +``` + +Si `host.name` correspond à ``, le modèle affiche : + +```text +{{ .matched }} le hostname +``` + +### Encodage URL + +Si votre message d'alerte contient des données à inclure dans une URL (par exemple pour une redirection), utilisez la syntaxe `{{ urlencode ""}}`. + +**Exemple** : si votre message de monitor inclut une URL vers le Software Catalog filtrée par service, utilisez la [variable de tag](#variables-d-attributs-et-de-tags) `service` et appliquez `{{ urlencode ""}}` dans l'URL. + +``` +https://app.datadoghq.com/services/{{urlencode "service.name"}} +``` + +## Pour aller plus loin + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /fr/monitors/configuration/#alert-grouping +[2]: /fr/monitors/types/log/ +[3]: /fr/monitors/types/apm/?tab=analytics +[4]: /fr/monitors/types/real_user_monitoring/ +[5]: /fr/monitors/types/ci/ +[6]: /fr/monitors/types/database_monitoring/ +[7]: /fr/monitors/guide/template-variable-evaluation/ +[8]: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones +[9]: /fr/monitors/types/error_tracking/ +[10]: /fr/software_catalog/service_definitions/ +[11]: https://docs.datadoghq.com/fr/software_catalog/service_definitions/v2-2/#example-yaml \ No newline at end of file diff --git a/content/fr/observability_pipelines/set_up_pipelines/archive_logs/_index.md b/content/fr/observability_pipelines/set_up_pipelines/archive_logs/_index.md new file mode 100644 index 0000000000000..ffa9ce95061ef --- /dev/null +++ b/content/fr/observability_pipelines/set_up_pipelines/archive_logs/_index.md @@ -0,0 +1,48 @@ +--- +aliases: +- /fr/observability_pipelines/archive_logs/ +disable_toc: false +title: Archiver les logs dans les archives Datadog +--- + +## Présentation + +Utilisez Observability Pipelines pour router les logs ingérés vers une solution de stockage cloud (Amazon S3, Google Cloud Storage ou Azure Storage) au format réhydratable par Datadog. Vous pouvez ensuite réhydrater l'archive dans Datadog à la demande, chaque fois que vous avez besoin d'analyser ou d'investiguer ces données. Cela est utile lorsque : + +- vous migrez depuis un autre fournisseur de gestion des logs vers Datadog Log Management et souhaitez vous assurer d'avoir accès aux logs historiques une fois la migration terminée. +- vous avez un volume élevé de logs peu pertinents, mais vous pourriez avoir besoin de les indexer ponctuellement dans Log Management. +- vous avez une politique de conservation. + +{{% observability_pipelines/use_case_images/archive_logs %}} + +Sélectionnez une source pour commencer : + +- [Amazon Data Firehose][12] +- [Amazon S3][11] +- [Agent Datadog][1] +- [Fluentd ou Fluent Bit][2] +- [Google Pub/Sub][3] +- [Client HTTP][4] +- [Serveur HTTP][5] +- [Kafka][13] +- [Logstash][6] +- [HTTP Event Collector (HEC) Splunk][7] +- [Splunk Heavy ou Universal Forwarders (TCP)][8] +- [Socket (TCP ou UDP)][14] +- [Collector hébergé Sumo Logic][9] +- [rsylsog ou syslog-ng][10] + +[1]: /fr/observability_pipelines/archive_logs/datadog_agent +[2]: /fr/observability_pipelines/archive_logs/fluent +[3]: /fr/observability_pipelines/set_up_pipelines/archive_logs/google_pubsub +[4]: /fr/observability_pipelines/archive_logs/http_client +[5]: /fr/observability_pipelines/set_up_pipelines/archive_logs/http_server +[6]: /fr/observability_pipelines/set_up_pipelines/archive_logs/logstash +[7]: /fr/observability_pipelines/archive_logs/splunk_hec +[8]: /fr/observability_pipelines/archive_logs/splunk_tcp +[9]: /fr/observability_pipelines/archive_logs/sumo_logic_hosted_collector +[10]: /fr/observability_pipelines/archive_logs/syslog +[11]: /fr/observability_pipelines/set_up_pipelines/archive_logs/amazon_s3 +[12]: /fr/observability_pipelines/set_up_pipelines/archive_logs/amazon_data_firehose +[13]: /fr/observability_pipelines/set_up_pipelines/archive_logs/kafka +[14]: /fr/observability_pipelines/set_up_pipelines/archive_logs/socket \ No newline at end of file diff --git a/content/fr/real_user_monitoring/browser/_index.md b/content/fr/real_user_monitoring/browser/_index.md index b47fd52c535b7..d348dd40bf385 100644 --- a/content/fr/real_user_monitoring/browser/_index.md +++ b/content/fr/real_user_monitoring/browser/_index.md @@ -9,26 +9,31 @@ further_reading: title: Surveillance Browser avec RUM --- -## Présentation +## Section Overview Real User Monitoring (RUM) de Datadog permet dʼobtenir des informations détaillées sur les performances frontend de votre application. Surveillez les données réelles des utilisateurs pour optimiser votre expérience Web et proposer les meilleures expériences utilisateur possibles. Mettez en corrélation les tests Synthetic, les métriques de backend, les traces, et les logs en un seul endroit pour identifier et résoudre les problèmes de performance sur l'ensemble de la pile. -Datadog vous aide à comprendre le niveau actuel de l'expérience utilisateur, à identifier les domaines à améliorer et à mesurer le succès de chaque changement et/ou déploiement. Utilisez ces informations pour identifier et résoudre les problèmes frontend imprévus avant que les utilisateurs ne soient affectés, afin de proposer la meilleure expérience possible. +Datadog vous aide à comprendre le niveau actuel d’expérience utilisateur, à identifier les points d’amélioration et à mesurer l’impact de chaque modification ou déploiement. Utilisez ces informations pour repérer et résoudre les problèmes front-end imprévus avant qu’ils n’affectent les utilisateurs, afin d’offrir la meilleure expérience possible. Avec le SDK Browser RUM de Datadog, vous pouvez également : - Surveiller les consultations de pages et les performances de votre application afin d'étudier les éventuels problèmes -- Obtenir une visibilité complète, de bout en bout, sur les ressources et les requêtes (comme les images, les fichiers CSS, les ressources JavaScript et les fichiers de polices). +- Bénéficiez d’une visibilité complète de bout en bout sur les ressources et les requêtes (telles que les images, fichiers CSS, éléments JavaScript et polices de caractères). - Collecter et surveiller automatiquement tous les événements intéressants avec lʼensemble du contexte pertinent, et collecter manuellement les erreurs qui ne sont pas automatiquement suivies. - Suivre les interactions des utilisateurs au cours de leur utilisation afin d'obtenir des informations sur leur comportement tout en respectant les exigences en matière de confidentialité. - Mettre en évidence les difficultés des utilisateurs à l'aide de signaux de frustration. - Identifier la cause d'une erreur au niveau de la ligne de code pour la résoudre. -{{< img src="real_user_monitoring/browser/rum-browser-overview.png" alt="Dashboard de synthèse des performances RUM" style="width:100%;">}} +{{< img src="real_user_monitoring/performance-summary-browser.png" alt="Dashboard de synthèse des performances RUM" style="width:100%;">}} + +La responsabilité de la sécurité des données utilisateur est partagée entre Datadog et les développeurs qui utilisent les SDK RUM. En savoir plus sur la [responsabilité partagée][1]. ## Prise en main -Pour commencer à utiliser le SDK Browser RUM, suivez les étapes pour [la création dʼune application RUM JavaScript][1]. +{{< whatsnext desc="Pour commencer avec le SDK Browser RUM pour navigateur, suivez les étapes pour créer une application RUM en fonction de la façon dont votre application est servie :" >}} + {{< nextlink href="/real_user_monitoring/browser/setup/client">}}Côté client : Instrumentez chacune de vos applications web basées sur un navigateur, déployez l’application, puis configurez les paramètres d’initialisation que vous souhaitez suivre, et utilisez la configuration avancée pour gérer plus finement les données et le contexte collectés par RUM.{{< /nextlink >}} + {{< nextlink href="/real_user_monitoring/browser/setup/server">}}Auto-instrumentation : Injectez un script JavaScript du SDK RUM dans les réponses HTML de vos applications web servies via un serveur ou un proxy.{{< /nextlink >}} +{{< /whatsnext >}} À partir de là, vous pouvez modifier les [données et le contexte][2] que le SDK Browser RUM collecte pour les adapter à vos besoins spécifiques. Apprenez à remplacer les paramètres par défaut dans la section [Configuration avancée][3]. @@ -36,6 +41,6 @@ Pour commencer à utiliser le SDK Browser RUM, suivez les étapes pour [la cré {{< partial name="whats-next/whats-next.html" >}} -[1]: /fr/real_user_monitoring/browser/setup/#setup +[1]: /fr/data_security/real_user_monitoring/#shared-responsibility [2]: /fr/real_user_monitoring/browser/data_collected/ [3]: /fr/real_user_monitoring/browser/advanced_configuration/ \ No newline at end of file diff --git a/content/fr/security/cloud_security_management/setup/agent/_index.md b/content/fr/security/cloud_security_management/setup/agent/_index.md new file mode 100644 index 0000000000000..c8d24302885c4 --- /dev/null +++ b/content/fr/security/cloud_security_management/setup/agent/_index.md @@ -0,0 +1,14 @@ +--- +aliases: +- /fr/security/cloud_security_management/setup/csm_cloud_workload_security/agent +- /fr/security/cloud_security_management/setup/csm_pro/agent +- /fr/security/cloud_security_management/setup/csm_enterprise/agent +title: Déploiement de Cloud Security sur l'Agent +type: multi-code-lang +--- + +Suivez les instructions ci-dessous pour activer les fonctionnalités de Cloud Security (erreurs de configuration et gestion des vulnérabilités) sur l'Agent Datadog. + +{{< partial name="security-platform/CSW-billing-note.html" >}} + +{{< partial name="csm/csm-agent-tiles.html" >}} \ No newline at end of file diff --git a/content/fr/synthetics/platform/metrics/_index.md b/content/fr/synthetics/platform/metrics/_index.md new file mode 100644 index 0000000000000..8441cbf552d55 --- /dev/null +++ b/content/fr/synthetics/platform/metrics/_index.md @@ -0,0 +1,114 @@ +--- +aliases: +- /fr/synthetics/metrics/ +description: Ces métriques sont générées par les tests Synthetic Monitoring. +further_reading: +- link: /synthetics/guide/api_test_timing_variations/ + tag: Documentation + text: En savoir plus sur les temps d'exécution et les variations des tests d'API +- link: /synthetics/guide/using-synthetic-metrics/ + tag: Documentation + text: En savoir plus sur l'utilisation des métriques Synthetic dans les monitors +- link: /continuous_testing/settings + tag: Documentation + text: En savoir plus sur la parallélisation pour Continuous Testing +title: Métriques de Synthetic Monitoring et Continuous Testing +--- + +## Présentation + +Les métriques suivantes sont générées par les tests Synthetic Monitoring et les paramètres de Continuous Testing. + +Les métriques qui commencent par : + +* `synthetics.test_runs` proviennent de tous vos tests Synthetic ; +* `datadog.estimated_usage.synthetics.*` renvoient les données d'utilisation pertinentes de vos tests Synthetic. +* `synthetics.on_demand` renvoie des données d'utilisation pertinentes pour [Continuous Testing](#continuous-testing) + +Les métriques qui commencent par : + +* `synthetics.api.*` proviennent de vos [tests API][1] ; + * `synthetics.http.*` proviennent de vos [tests API HTTP][2] ; + * `synthetics.ssl.*` proviennent de vos [tests API SSL][3] ; + * `synthetics.dns.*` proviennent de vos [tests API DNS][4] ; + * `synthetics.websocket.*` proviennent de vos [tests API WebSocket][5] ; + * `synthetics.tcp.*` proviennent de vos [tests API TCP][6] ; + * `synthetics.udp.*` proviennent de vos [tests API UDP][7] ; + * `synthetics.icmp.*` proviennent de vos [tests API ICMP][8] ; +* `synthetics.multi.*` proviennent de vos [tests API à plusieurs étapes][9] ; +* `synthetics.browser.*` proviennent de vos [tests Browser][10] ; +* `synthetics.pl.*` provient de vos [emplacements privés][11] + +### Métriques générales + +{{< get-metrics-from-git "synthetics" "synthetics.test_runs synthetics.test_run_steps datadog.estimated_usage.synthetics" >}} + +### Tests API + +{{< get-metrics-from-git "synthetics" "synthetics.api" >}} + +#### Tests HTTP + +{{< get-metrics-from-git "synthetics" "synthetics.http" >}} + +#### Tests SSL + +{{< get-metrics-from-git "synthetics" "synthetics.ssl" >}} + +#### Tests DNS + +{{< get-metrics-from-git "synthetics" "synthetics.dns" >}} + +#### Tests WebSocket + +{{< get-metrics-from-git "synthetics" "synthetics.websocket" >}} + +#### Tests TCP + +{{< get-metrics-from-git "synthetics" "synthetics.tcp" >}} + +#### Tests UDP + +{{< get-metrics-from-git "synthetics" "synthetics.udp" >}} + +#### Tests ICMP + +{{< get-metrics-from-git "synthetics" "synthetics.icmp" >}} + +Pour en savoir plus sur les durées des tests API, consultez le guide sur [les durées et les écarts des tests API][12]. + +### Tests API à plusieurs étapes + +{{< get-metrics-from-git "synthetics" "synthetics.multi" >}} + +### Tests Browser + +{{< get-metrics-from-git "synthetics" "synthetics.browser" >}} + +### Emplacements privés + +{{< get-metrics-from-git "synthetics" "synthetics.pl.worker" >}} + +### Tests continus + +{{< get-metrics-from-git "synthetics" "synthetics.on_demand.concurrency" >}} + +Pour en savoir plus sur la parallélisation, consultez la section [Paramètres des tests continus][13]. + +## Pour aller plus loin + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /fr/synthetics/api_tests/ +[2]: /fr/synthetics/api_tests/http_tests +[3]: /fr/synthetics/api_tests/ssl_tests +[4]: /fr/synthetics/api_tests/dns_tests +[5]: /fr/synthetics/api_tests/websocket_tests +[6]: /fr/synthetics/api_tests/tcp_tests +[7]: /fr/synthetics/api_tests/udp_tests +[8]: /fr/synthetics/api_tests/icmp_tests +[9]: /fr/synthetics/multistep/ +[10]: /fr/synthetics/browser_tests/ +[11]: /fr/synthetics/private_locations/ +[12]: /fr/synthetics/guide/api_test_timing_variations/ +[13]: /fr/continuous_testing/settings/#parallelization \ No newline at end of file diff --git a/content/fr/tracing/metrics/runtime_metrics/_index.md b/content/fr/tracing/metrics/runtime_metrics/_index.md new file mode 100644 index 0000000000000..99ccf307b7f07 --- /dev/null +++ b/content/fr/tracing/metrics/runtime_metrics/_index.md @@ -0,0 +1,305 @@ +--- +aliases: +- /fr/tracing/advanced/runtime_metrics/ +- /fr/tracing/metrics/runtime_metrics/dotnet +- /fr/tracing/metrics/runtime_metrics/java +- /fr/tracing/metrics/runtime_metrics/nodejs +- /fr/tracing/metrics/runtime_metrics/python +- /fr/tracing/metrics/runtime_metrics/ruby +- /fr/tracing/runtime_metrics/dotnet +- /fr/tracing/runtime_metrics/java +- /fr/tracing/runtime_metrics/nodejs +- /fr/tracing/runtime_metrics/python +- /fr/tracing/runtime_metrics/ruby +description: Consultez des statistiques supplémentaires sur les performances d'une + application grâce aux métriques runtime associées à vos traces. +further_reading: +- link: tracing/other_telemetry/connect_logs_and_traces + tag: Documentation + text: Corréler vos logs et vos traces +- link: tracing/trace_collection/custom_instrumentation + tag: Documentation + text: Instrumenter vos applications manuellement pour créer des traces +- link: tracing/glossary/ + tag: Documentation + text: Explorer vos services, ressources et traces +title: Métriques runtime +--- + +## Présentation + +Les métriques runtime surveillent l'utilisation de la mémoire, la collecte des déchets et la parallélisation de votre application. Les bibliothèques de tracing Datadog collectent automatiquement ces métriques pour les environnements pris en charge et les envoient à l'Agent Datadog. + +Ces métriques vous aident à identifier les goulots d'étranglement, à résoudre les problèmes de performance et à optimiser l'utilisation des ressources. En visualisant les métriques runtime conjointement avec les traces et les logs, vous obtenez une visibilité complète sur la santé et les performances de votre application. + +## Compatibilité + +Les métriques runtime sont disponibles pour plusieurs langages de programmation et environnements d'exécution, avec des niveaux de support et des options de configuration variables. + +{{< tabs >}} +{{% tab "Java" %}} + +- **Activé par défaut** : Oui +- **Version de la bibliothèque** : 0.29.0+ +- **Runtime** : Java 8+ + +
La collecte des métriques JMX n'est pas prise en charge dans les environnements AWS Lambda.
+ +{{% /tab %}} + +{{% tab "Python" %}} + + - **Activé par défaut** : Non + - **Version de la bibliothèque** : 0.30.0+ + - **Niveau de prise en charge** : Aperçu + - **Runtime** : Toutes les versions de Python prises en charge + +{{% /tab %}} + +{{% tab "Ruby" %}} + + - **Activé par défaut** : Non + - **Version de la bibliothèque** : 0.44.0+ + - **Runtime** : Toutes les versions de Ruby prises en charge + + +
Vous devez ajouter la gem dogstatsd-ruby à votre application.
+ +{{% /tab %}} + +{{% tab "Go" %}} + + - **Activé par défaut** : Non + - **Version de la bibliothèque** : 1.18.0+ + - **Runtime** : Toutes les versions de Go prises en charge + +{{% /tab %}} + +{{% tab "Node.js" %}} + + - **Activé par défaut** : Non + - **Version de la bibliothèque** : 3.0.0+ + - **Runtime** : Toutes les versions de Node.js prises en charge + +{{% /tab %}} + +{{% tab ".NET" %}} + + - **Activé par défaut** : Non + - **Version de la bibliothèque** : 1.23.0+ + - **Runtime**: .NET Framework 4.6.1+ et .NET Core 3.1+ (y compris .NET 5 et ultérieur). + +#### Autorisations pour Internet Information Services (IIS) + +Sur .NET Framework, les métriques peuvent être recueillies à l'aide de compteurs de performances. Les utilisateurs avec une session ouverte non interactive (notamment ceux avec des comptes de pool d'applications IIS et certains comptes de service) doivent être ajoutés au groupe **Performance Monitoring Users** pour accéder aux données des compteurs. + +Les pools d'applications IIS utilisent des comptes spéciaux qui n'apparaissent pas dans la liste des utilisateurs. Pour les ajouter au groupe Performance Monitoring Users, recherchez `IIS APPPOOL\`. Par exemple, l'utilisateur pour DefaultAppPool est `IIS APPPOOL\DefaultAppPool`. + +Vous pouvez effectuer cette opération depuis l'interface Computer Management, ou depuis l'invite de commandes administrateur : + +```shell +net localgroup "Performance Monitor Users" "IIS APPPOOL\DefaultAppPool" /add +``` + +{{% /tab %}} +{{% tab "PHP" %}} + +
Les métriques runtime pour PHP ne sont pas prises en charge.
+ +{{% /tab %}} +{{% tab "C++" %}} + +
Les métriques runtime pour C++ ne sont pas prises en charge.
+ +{{% /tab %}} +{{< /tabs >}} + +## Instructions de configuration + +Pour configurer les métriques runtime, vous devez configurer à la fois l'Agent Datadog et votre application. + +### 1. Configurer l'Agent Datadog + +Activez [DogStatsD pour l'Agent][2]. Par défaut, l'Agent Datadog est configuré pour ingérer les métriques via UDP sur le port `8125`. + +{{% collapse-content title="Configuration spécifique au conteneur" level="h4" expanded=false %}} + +Lors de l'exécution de l'Agent dans des environnements conteneurisés, une configuration supplémentaire est nécessaire : + +1. Définissez `dogstatsd_non_local_traffic: true` dans votre fichier principal de configuration [`datadog.yaml`][8], ou définissez la [variable d'environnement][3] `DD_DOGSTATSD_NON_LOCAL_TRAFFIC=true`. +2. Suivez ces instructions de configuration spécifiques aux conteneurs : + +{{< partial name="apm/apm-runtime-metrics-containers.html" >}} + +
+ +{{< site-region region="us3,us5,eu,gov,ap1,ap2" >}} + +3. Définissez `DD_SITE` dans l'Agent Datadog sur {{< region-param key="dd_site" code="true" >}} pour vous assurer que l'Agent envoie les données au bon site Datadog. + +{{< /site-region >}} + +{{% /collapse-content %}} + +### 2. Configurer votre application + +Configurez les métriques runtime dans votre application a l'aide de variables d'environnement. Certains langages prennent également en charge la configuration des métriques runtime [directement dans le code](#configuration-basee-sur-le-code). + +#### Variables d'environnement + +Utilisez les variables d'environnement suivantes pour configurer les métriques runtime dans votre application : + +`DD_RUNTIME_METRICS_ENABLED` +: **Par défaut** : `true` pour Java, `false` pour les autres langages`
` +**Description** : Active la collecte des métriques runtime. Les métriques sont envoyées à l'Agent Datadog, selon la configuration de l'application instrumentée. + +`DD_RUNTIME_METRICS_RUNTIME_ID_ENABLED` +: **Par défaut** : `true` pour Java, `false` pour Node.js, Ruby et Python. N'existe pas pour .NET et Go ; le `runtime_id` est toujours rapporté.`
` +**Description** : Active les métriques runtime améliorées, en ajoutant un tag `runtime_id` à chaque métrique. Le `runtime_id` représente l'identifiant du processus de l'application et permet de corréler directement les métriques runtime avec chaque application en cours d'exécution. + +`DD_AGENT_HOST` +: **Par défaut** : `localhost` `
` +**Description** : Définit l'adresse du host pour la soumission des métriques par la bibliothèque de tracing. Il peut s'agir d'un nom de host ou d'une adresse IP. + +`DD_DOGSTATSD_PORT` +: **Par défaut** : `8125`
+**Description** : Définit le port pour l'envoi des métriques par la bibliothèque de tracing. + +#### Configuration basée sur le code + +En plus des variables d'environnement, certains langages permettent de configurer les métriques runtime directement dans le code. + +{{< tabs >}} +{{% tab "Java" %}} + +Vous pouvez uniquement activer les métriques runtime à l'aide de [variables d'environnement](#variables-d-environnement). + +Cependant, vous pouvez étendre les métriques collectées en ajoutant des métriques JMX custom. Pour plus d'informations, consultez la documentation de l'[intégration JMX][100]. + +[100]: /fr/integrations/java/ +{{% /tab %}} + +{{% tab "Python" %}} + +Vous pouvez activer les métriques runtime à l'aide de [variables d'environnement](#variables-d-environnement) ou directement dans le code : + +```python +from ddtrace.runtime import RuntimeMetrics +RuntimeMetrics.enable() +``` + +
Cela s'applique uniquement si vous n'utilisez pas ddtrace-run
+{{% /tab %}} + +{{% tab "Ruby" %}} + +Vous pouvez activer les métriques runtime à l'aide de [variables d'environnement](#variables-d-environnement) ou directement dans le code : + +```ruby +# config/initializers/datadog.rb +require 'datadog/statsd' +require 'datadog' # Utilisez 'ddtrace' si vous utilisez v1.x + +Datadog.configure do |c| + c.runtime_metrics.enabled = true + + # Vous pouvez, si vous le souhaitez, configurer l'instance DogStatsD utilisée pour l'envoi des métriques runtime. + # DogStatsD est automatiquement configuré avec les paramètres par défaut si `dogstatsd-ruby` est disponible.  + # Vous pouvez la configurer avec le host et le port de l'Agent Datadog ; la valeur par défaut est 'localhost:8125'. + c.runtime_metrics.statsd = Datadog::Statsd.new +end +``` +{{% /tab %}} + +{{% tab "Go" %}} + +Vous pouvez activer les métriques runtime à l'aide de [variables d'environnement](#variables-d-environnement) ou directement dans le code : + +```go +// Configuration basique +tracer.Start(tracer.WithRuntimeMetrics()) + +// Avec une adresse DogStatsD personnalisée +tracer.Start( + tracer.WithRuntimeMetrics(), + tracer.WithDogstatsdAddr("custom-host:8125") +) +``` + +L'option `WithDogstatsdAddr` permet de spécifier une adresse personnalisée pour le serveur DogStatsD. Utilisez [`WithDogstatsdAddr`][101] (ou [`WithDogstatsdAddress` v1][100]) si votre adresse diffère de la valeur par défaut `localhost:8125`. (Disponible à partir de la version 1.18.0+). + +[100]: https://pkg.go.dev/gopkg.in/DataDog/dd-trace-go.v1/ddtrace/tracer#WithDogstatsdAddress +[101]: https://pkg.go.dev/github.com/DataDog/dd-trace-go/v2/ddtrace/tracer#WithDogstatsdAddr +{{% /tab %}} + +{{% tab "Node.js" %}} + +Vous pouvez activer les métriques runtime à l'aide de [variables d'environnement](#variables-d-environnement) ou directement dans le code : + +```js +const tracer = require('dd-trace').init({ + // Autres options du tracer... + runtimeMetrics: true +}) +``` +{{% /tab %}} + +{{% tab ".NET" %}} + +Vous pouvez uniquement activer les métriques runtime à l'aide de [variables d'environnement](#variables-d-environnement). + +{{% /tab %}} +{{< /tabs >}} + +## Dashboards + +Une fois la configuration terminée, vous pouvez afficher les métriques runtime dans : + +- La page des détails du service instrumenté +- L'onglet **Metrics** du flame graph +- Dashboards runtime par défaut + +{{< img src="tracing/runtime_metrics/jvm_runtime_trace.png" alt="Trace runtime JVM" >}} + +## Dépannage +- Pour associer les métriques runtime aux flame graphs, assurez-vous que le tag `env` (sensible à la casse) est défini et identique dans tout votre environnement. +- Pour que les métriques runtime s'affichent sur la page du service lorsque vous utilisez Fargate, assurez-vous que `DD_DOGSTATSD_TAGS` est défini sur la tâche de votre Agent, et que le tag `env` configuré correspond à celui du service instrumenté. + +## Données collectées + +Chaque langage pris en charge collecte un ensemble de métriques runtime fournissant des informations sur l'utilisation de la mémoire, la collecte des déchets, l'utilisation du CPU et d'autres indicateurs de performance. + +{{< tabs >}} +{{< tab "Java" >}} +{{< get-metrics-from-git "java" >}} +{{< /tab >}} + +{{< tab "Python" >}} +{{< get-metrics-from-git "python" >}} +{{< /tab >}} + +{{< tab "Ruby" >}} +{{< get-metrics-from-git "ruby" >}} +{{< /tab >}} + +{{< tab "Go" >}} +{{< get-metrics-from-git "go" >}} +{{< /tab >}} + +{{< tab "Node.js" >}} +{{< get-metrics-from-git "node" >}} +{{< /tab >}} + +{{< tab ".NET" >}} +{{< get-metrics-from-git "dotnet" >}} +{{< /tab >}} +{{< /tabs >}} + +## Pour aller plus loin + +{{< partial name="whats-next/whats-next.html" >}} + +[2]: /fr/developers/dogstatsd/#setup +[3]: /fr/agent/docker/#dogstatsd-custom-metrics +[7]: /fr/developers/dogstatsd/unix_socket/ +[8]: /fr/agent/configuration/agent-configuration-files/#main-configuration-file \ No newline at end of file diff --git a/content/fr/tracing/trace_collection/automatic_instrumentation/dd_libraries/php.md b/content/fr/tracing/trace_collection/automatic_instrumentation/dd_libraries/php.md index 741b494b9d2df..99408d78345a5 100644 --- a/content/fr/tracing/trace_collection/automatic_instrumentation/dd_libraries/php.md +++ b/content/fr/tracing/trace_collection/automatic_instrumentation/dd_libraries/php.md @@ -56,16 +56,16 @@ apk add libgcc Exécutez le programme d'installation : ```shell -# Installation complète : APM, ASM et profiling +# Installation complète : APM + AAP + Profiling php datadog-setup.php --php-bin=all --enable-appsec --enable-profiling -# APM seulement +# APM uniquement php datadog-setup.php --php-bin=all -# APM et ASM +# APM + AAP php datadog-setup.php --php-bin=all --enable-appsec -# APM et profiling +# APM + Profiling php datadog-setup.php --php-bin=all --enable-profiling ``` diff --git a/content/ja/account_management/audit_trail/guides/_index.md b/content/ja/account_management/audit_trail/guides/_index.md index 2bc949c9abb4a..36614dfae08c2 100644 --- a/content/ja/account_management/audit_trail/guides/_index.md +++ b/content/ja/account_management/audit_trail/guides/_index.md @@ -3,6 +3,7 @@ disable_toc: false title: 監査証跡ガイド --- -{{< whatsnext desc="Guides:" >}} - {{< nextlink href="account_management/audit_trail/guides/track_dashboard_usage" >}}ダッシュボードの使用状況を追跡{{< /nextlink >}} +{{< whatsnext desc="ガイド:" >}} + {{< nextlink href="account_management/audit_trail/guides/track_dashboard_access_and_configuration_changes" >}}Dashboard へのアクセスと設定変更の追跡{{< /nextlink >}} + {{< nextlink href="account_management/audit_trail/guides/track_monitor_access_and_configuration_changes" >}}Monitor へのアクセスと設定変更の追跡{{< /nextlink >}} {{< /whatsnext >}} \ No newline at end of file diff --git a/content/ja/account_management/audit_trail/guides/track_dashboard_access_and_configuration_changes.md b/content/ja/account_management/audit_trail/guides/track_dashboard_access_and_configuration_changes.md new file mode 100644 index 0000000000000..e184f2bd532c0 --- /dev/null +++ b/content/ja/account_management/audit_trail/guides/track_dashboard_access_and_configuration_changes.md @@ -0,0 +1,72 @@ +--- +aliases: +- /ja/./track_dashboard_usage/ +disable_toc: false +further_reading: +- link: account_management/audit_trail/ + tag: ドキュメント + text: Audit Trail のセットアップ +title: ダッシュボードのアクセスと構成変更を追跡する +--- + +## 概要 + +Audit Trail は、組織内で誰が Datadog を使用しているか、またどのように使用しているかについて、Datadog 管理者に可視性を提供します。本ガイドでは、特定のダッシュボードの使用状況を確認する方法を説明します。 + +## 特定のダッシュボードの使用状況を表示する + +### ダッシュボード ID を取得する + +ダッシュボードの使用状況を取得するには、そのダッシュボードの ID が必要です。 + +1. [Dashboards][1] に移動します。 +1. 対象のダッシュボードを選択します。 +1. ダッシュボード ID はダッシュボード URL に含まれており、 `https://app.datadoghq.com/dashboard/` の後に続きます。例えば、ダッシュボード URL が `https://app.datadoghq.com/dashboard/pte-tos-7kc/escalations-report` の場合、ダッシュボード ID は `pte-tos-7kc` です。 +1. ダッシュボード ID をコピーします。 + +### Audit Trail でダッシュボードの使用状況を表示する + +ダッシュボードの使用状況を確認するには、Audit Trail でそのダッシュボード ID に対するすべての API `GET` リクエストを検索します。 + +1. [Audit Trail][2] に移動します。 +2. 検索バーに次のクエリを入力します: `@http.status_code:200 @http.method:GET @http.url_details.path:/api/v1/dashboard/`。 `` は先ほどコピーしたダッシュボード ID に置き換えてください。
例えば、ダッシュボード ID が `pte-tos-7kc` の場合、検索クエリは次のようになります: +{{< img src="account_management/audit_logs/dashboard_access_query.png" alt="ダッシュボード ID pte-tos-7kc に対する成功したすべての GET リクエストの検索クエリ" style="width:100%;" >}} +`@http.status_code:200` は、結果を成功したリクエストのみに絞り込みます。 +
**注**: ページ左側のファセット パネルを使用して、検索クエリを組み立てることもできます。 +3. ページ右上のタイム フレームを選択して、特定期間のイベントを表示します。 +4. **Group into fields** セクションを構成し、ユース ケースに応じてデータを分解して分析するために異なる可視化ツールを選択できます。例えば、 `group by` フィールドを `User Email` に設定し、**Visualize as** セクションで **Top List** をクリックすると、ダッシュボードにアクセスしたユーザーの Top List が得られます。 +5. この情報をダッシュボードやグラフに取り込みたい場合は、 [ダッシュボードまたはグラフの作成][3] を参照してください。 + +## 最近のダッシュボードの構成変更を表示する + +Audit Trail の [イベント クエリ][7] を使用して、最近構成が変更されたダッシュボードの一覧を確認できます。 + +1. [Audit Trail][2] に移動します。 +1. **Search for** フィールドに、表示したい変更の種類でフィルタリングするクエリを貼り付けます。以下は一般的な例です: + + | 監査イベント | Audit Explorer 内のクエリ | + |-----------------------------------|--------------------------------------------------------------| + | [最近作成されたダッシュボード][4] | `@evt.name:Dashboard @asset.type:dashboard @action:created` | + | [最近変更されたダッシュボード][5] | `@evt.name:Dashboard @asset.type:dashboard @action:modified` | + | [最近削除されたダッシュボード][6] | `@evt.name:Dashboard @asset.type:dashboard @action:deleted` | + +1. 必要に応じて、ファセット パネルの **Asset ID** や **Asset Name** などのフィルターを使用し、特定のダッシュボードに結果を絞り込みます。 +1. テーブルの各イベントでは、最後の変更を実行したユーザーのメール アドレスと、何が起きたかの概要を確認できます。 + + 特定の変更について追加情報を表示するには、テーブル内の行をクリックします。次に、**Inspect Changes (Diff)** タブをクリックして、ダッシュボードの構成に対して行われた変更を確認します: + + {{< img src="account_management/audit_logs/dashboard_change_diff.png" alt="ダッシュボードに新しいウィジェットが追加されたことを示すテキスト ディフ" style="width:100%;" >}} + +1. この情報をダッシュボードやグラフに取り込みたい場合は、 [ダッシュボードまたはグラフの作成][3] を参照してください。 + +## 参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://app.datadoghq.com/dashboard/lists +[2]: https://app.datadoghq.com/audit-trail +[3]: /ja/account_management/audit_trail/#create-a-dashboard-or-a-graph +[4]: https://app.datadoghq.com/audit-trail?query=%40evt.name%3ADashboard%20%40asset.type%3Adashboard%20%40action%3Acreated +[5]: https://app.datadoghq.com/audit-trail?query=%40evt.name%3ADashboard%20%40asset.type%3Adashboard%20%40action%3Amodified +[6]: https://app.datadoghq.com/audit-trail?query=%40evt.name%3ADashboard%20%40asset.type%3Adashboard%20%40action%3Adeleted +[7]: /ja/account_management/audit_trail/events \ No newline at end of file diff --git a/content/ja/account_management/audit_trail/guides/track_monitor_access_and_configuration_changes.md b/content/ja/account_management/audit_trail/guides/track_monitor_access_and_configuration_changes.md new file mode 100644 index 0000000000000..6ad7a631745ff --- /dev/null +++ b/content/ja/account_management/audit_trail/guides/track_monitor_access_and_configuration_changes.md @@ -0,0 +1,73 @@ +--- +disable_toc: false +further_reading: +- link: account_management/audit_trail/ + tag: ドキュメント + text: Audit Trail をセットアップする +title: モニターへのアクセスと構成変更を追跡する +--- + +## 概要 + +Audit Trail は、組織内で誰が Datadog を使用しているか、またどのように使用しているかについて、Datadog 管理者に可視性を提供します。このガイドでは、特定のモニターの使用状況情報を確認する方法を説明します。 + +## 特定のモニターの使用状況を表示する + +### モニター ID を取得する + +モニターの使用状況情報を取得するには、そのモニターの ID が必要です。 + +1. [Monitors][1] に移動します。 +1. 対象のモニターを選択します。 +1. モニター ID はモニターの URL に含まれており、 `https://app.datadoghq.com/monitors/` の後ろにあります。例えば、モニターの URL が `https://app.datadoghq.com/monitors/123456789` の場合、モニター ID は `123456789` です。 +1. モニター ID をコピーします。 + +### Audit Trail でモニターの使用状況を表示する + +そのモニターの使用状況を確認するには、Audit Trail を使用して、そのモニター ID に対するすべての API `GET` リクエストを検索します。 + +1. [Audit Trail][2] に移動します。 +2. 検索バーに次のクエリを入力します: `@http.status_code:200 @http.method:GET @http.url_details.path:/api/v1/monitor/`。`` を先ほどコピーしたモニター ID に置き換えます。 + + 例えば、モニター ID が `123456789` の場合、検索クエリは `@http.status_code:200 @http.method:GET @http.url_details.path:/api/v1/monitor/123456789` になります。`@http.status_code:200` は、成功したリクエストのみに結果を絞り込みます。 + + **注**: ページ左側のファセット パネルを使って、検索クエリを作成することもできます。 +3. ページ右上の期間を選択して、特定の期間のイベントを表示します。 +4. **Group into fields** セクションを構成し、ユース ケースに応じてデータを分解・分析できるように、さまざまな可視化ツールを選択できます。例えば、`group by` フィールドを `User Email` に設定し、**Visualize as** セクションで **Top List** をクリックすると、そのモニターにアクセスしたユーザーのトップ リストが得られます。 +5. この情報をダッシュボードやグラフに入れたい場合は、[ダッシュボードまたはグラフを作成する][3] を参照してください。 + +## 最近のモニター構成の変更を表示する + +Audit Trail の [イベント クエリ][8] を使用すると、最近構成が変更されたモニターの一覧を表示できます。 + +1. [Audit Trail][2] に移動します。 +1. **Search for** フィールドに、表示したい変更の種類で絞り込むためのクエリを貼り付けます。よくある例は次のとおりです: + + | 監査イベント | Audit Explorer のクエリ | + |-----------------------|----------------------------------------------------------| + | [モニターの作成][4] | `@evt.name:Monitor @asset.type:monitor @action:created` | + | [モニターの変更][5] | `@evt.name:Monitor @asset.type:monitor @action:modified` | + | [モニターの削除][6] | `@evt.name:Monitor @asset.type:monitor @action:deleted` | + | [モニターの解決][7] | `@evt.name:Monitor @asset.type:monitor @action:resolved` | + +1. 必要に応じて、ファセット パネルで **Asset ID** や **Asset Name** などのフィルターを使用し、特定のモニターに結果を絞り込むこともできます。 +1. 表の各イベントでは、最後の変更を実行したユーザーのメール アドレスと、何が起きたかの概要を確認できます。 + + 特定の変更の詳細を確認するには、表の行をクリックします。次に、**Inspect Changes (Diff) タブ** をクリックして、そのモニターの構成に加えられた変更を表示します: + + {{< img src="account_management/audit_logs/monitor_change_diff.png" alt="モニターに `check_type: api` タグが追加されたことを示すテキスト差分" style="width:100%;" >}} + +1. この情報をダッシュボードやグラフに入れたい場合は、[ダッシュボードまたはグラフを作成する][3] を参照してください。 + +## 参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://app.datadoghq.com/monitors/manage +[2]: https://app.datadoghq.com/audit-trail +[3]: /ja/account_management/audit_trail/#create-a-dashboard-or-a-graph +[4]: https://app.datadoghq.com/audit-trail?query=%40evt.name%3AMonitor%20%40asset.type%3Amonitor%20%40action%3Acreated +[5]: https://app.datadoghq.com/audit-trail?query=%40evt.name%3AMonitor%20%40asset.type%3Amonitor%20%40action%3Amodified +[6]: https://app.datadoghq.com/audit-trail?query=%40evt.name%3AMonitor%20%40asset.type%3Amonitor%20%40action%3Adeleted +[7]: https://app.datadoghq.com/audit-trail?query=%40evt.name%3AMonitor%20%40asset.type%3Amonitor%20%40action%3Aresolved +[8]: /ja/account_management/audit_trail/events/#monitor-events \ No newline at end of file diff --git a/content/ja/account_management/guide/_index.md b/content/ja/account_management/guide/_index.md index 088d691ab22f4..d33357ed18d17 100644 --- a/content/ja/account_management/guide/_index.md +++ b/content/ja/account_management/guide/_index.md @@ -8,11 +8,11 @@ private: true title: アカウントの管理ガイド --- -{{< whatsnext desc="Usage metering API migration guides:" >}} - {{< nextlink href="account_management/guide/relevant-usage-migration" >}}Migrate Indexed Logs and RUM in the Hourly Usage and Summary Usage APIs{{< /nextlink >}} - {{< nextlink href="account_management/guide/hourly-usage-migration" >}}Migrating from the v1 Hourly Usage APIs to v2{{< /nextlink >}} - {{< nextlink href="account_management/guide/usage-attribution-migration" >}}Migrating from v1 to v2 of the Usage Attribution API{{< /nextlink >}} - {{< nextlink href="account_management/guide/csv-headers-billing-migration" >}}Updates to Plan & Usage CSV Headers as of September 18, 2023{{< /nextlink >}} +{{< whatsnext desc="Usage Metering API の移行ガイド:" >}} + {{< nextlink href="account_management/guide/relevant-usage-migration" >}}Hourly Usage API と Summary Usage API における Indexed Logs と RUM の移行{{< /nextlink >}} + {{< nextlink href="account_management/guide/hourly-usage-migration" >}}Hourly Usage API の v1 から v2 への移行{{< /nextlink >}} + {{< nextlink href="account_management/guide/usage-attribution-migration" >}}Usage Attribution API の v1 から v2 への移行{{< /nextlink >}} + {{< nextlink href="account_management/guide/csv-headers-billing-migration" >}}2023 年 9 月 18 日付 Plan & Usage CSV ヘッダーの更新{{< /nextlink >}} {{< /whatsnext >}} {{< whatsnext desc="一般的なアカウント管理:" >}} diff --git a/content/ja/account_management/saml/entra.md b/content/ja/account_management/saml/entra.md new file mode 100644 index 0000000000000..fe35ae8b76eb5 --- /dev/null +++ b/content/ja/account_management/saml/entra.md @@ -0,0 +1,49 @@ +--- +aliases: +- /ja/account_management/saml/azure/ +- /ja/account_management/faq/how-do-i-configure-azure-ad-as-a-saml-idp/ +further_reading: +- link: /account_management/saml/ + tag: ドキュメント + text: Datadog アカウントのための SAML の構成 +- link: /account_management/multi_organization/ + tag: ドキュメント + text: 複数のアカウントを持つチームとオーガニゼーションの構成 +title: Microsoft Entra ID SAML IdP +--- + +## セットアップ + +[Microsoft Entra の Datadog とのシングル サインオン (SSO) 統合][1] チュートリアルに従って、Entra ID を SAML アイデンティティ プロバイダー (IdP) として設定します。**注**: Entra ID サブスクリプションが必要です。サブスクリプションをお持ちでない場合は、[無料 アカウント][2] に登録してください。 + +### Datadog + +1. [Datadog SAML ページ][3]に移動します。 + +2. Microsoft からダウンロードした **SAML XML Metadata** ファイルを選択してアップロードします。 + +3. **SAML is ready** と **Valid IdP metadata installed** というメッセージが表示されます。 + + {{< img src="account_management/saml/SAML_Configuration___Datadog11.png" alt="SAML_Configuration___Datadog11" style="width:70%;">}} + +4. **Enable** をクリックして、SAML を使用した Entra ID のシングル サインオンを開始します: + + {{< img src="account_management/saml/SAML_Configuration___Datadog12.png" alt="SAML_Configuration___Datadog12" style="width:70%;">}} + +### 高度な URL + +Datadog ボタンまたはリンクで SSO を使用している場合は、サインオン URL が必要です。 + +1. [Datadog SAML ページ][3]からシングルサインオン URL を取得します。 + + {{< img src="account_management/saml/SAML_Configuration___Datadog13.png" alt="SAML_Configuration___Datadog13" style="width:70%;">}} + +2. Microsoft Entra ID で、アプリケーションの SSO Configuration セクションに移動し、**Show advanced URL settings** をチェックして、シングル サインオン URL を追加します。 + +## その他の参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://learn.microsoft.com/en-us/entra/identity/saas-apps/datadog-tutorial +[2]: https://azure.microsoft.com/free/ +[3]: https://app.datadoghq.com/saml/saml_setup \ No newline at end of file diff --git a/content/ja/agent/basic_agent_usage/saltstack.md b/content/ja/agent/basic_agent_usage/saltstack.md index 0b0744fdbe894..207243cf6e424 100644 --- a/content/ja/agent/basic_agent_usage/saltstack.md +++ b/content/ja/agent/basic_agent_usage/saltstack.md @@ -127,7 +127,7 @@ file_roots: ホストに Agent インテグレーションを追加するには、`checks` 変数とチェックの名前を合わせてキーとして使用します。各チェックに 2 つのオプションが存在します。 -| オプション | 説明 | +| オプション | Description | |-----------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | `config` | チェックのコンフィギュレーションファイルに書き込むためのコンフィギュレーションオプションを追加します。
Agent v6 & v7: /.d/conf.yaml`
Agent v5: `/.yaml` | | `version` | Agent v6 & v7 環境でインストールするチェックのバージョン (デフォルトは Agent にバンドルされたバージョンとなります) 。 | @@ -204,7 +204,7 @@ datadog: Salt Formula には Salt の状態が事前に記述されています。Datadog Formula で利用可能な状態は以下の通りです。 -| 状態 | 説明 | +| 状態 | Description | |---------------------|---------------------------------------------------------------------------------------------------------| | `datadog` | Datadog Agent サービスをインストール、構成、起動します。 | | `datadog.install` | Datadog Agent の適切なリポジトリとインストールを構成します。 | @@ -214,7 +214,7 @@ Salt Formula には Salt の状態が事前に記述されています。Datadog **注**: `datadog.config` を使用して別のマシンで異なるチェックのインスタンスを構成する場合は、Salt マスターコンフィギュレーションまたは Salt ミニオンコンフィギュレーション (マスターなしの場合) の [pillar_merge_lists][5] を必ず `True` に設定してください。 -[1]: http://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html +[1]: https://docs.saltproject.io/en/latest/topics/development/conventions/formulas.html [2]: https://app.datadoghq.com/organization-settings/api-keys [3]: https://docs.datadoghq.com/ja/integrations/directory/ [4]: https://github.com/DataDog/datadog-formula/blob/master/pillar.example diff --git a/content/ja/agent/configuration/agent-log-files.md b/content/ja/agent/configuration/agent-log-files.md new file mode 100644 index 0000000000000..7631491ea7c48 --- /dev/null +++ b/content/ja/agent/configuration/agent-log-files.md @@ -0,0 +1,53 @@ +--- +algolia: + tags: + - Agent のログファイル +aliases: +- /ja/agent/faq/agent-log-files +- /ja/agent/guide/agent-log-files +further_reading: +- link: /agent/troubleshooting/ + tag: ドキュメント + text: Agent のトラブルシューティング +- link: /agent/configuration/agent-configuration-files/ + tag: よくあるご質問 + text: Agent 構成ファイル +- link: /agent/configuration/agent-commands/ + tag: よくあるご質問 + text: Agent のコマンド +title: Agent のログファイル +--- + +Datadog Agent は、デフォルトでログファイルが 10 MB に達するたびにログをローテーションします。ロールオーバーが発生すると、1 つのバックアップ (`agent.log.1`) が保存されます。以前のバックアップが存在する場合、ロールオーバー中に上書きされます。1 つのログファイルの最大サイズと保持するバックアップファイルの最大数を変更するには、[Agent 構成ファイル][1]で `log_file_max_size` (デフォルト: 10 485 760 バイト) と `log_file_max_rolls` (デフォルト: 1) を設定します。 + +## Agent のログディレクトリ + +| プラットフォーム | コマンド | +|---------------------------------------|-------------------------------| +| Linux | `/var/log/datadog/` | +| macOS、Agent v7.28+ および v6.28+ | `/opt/datadog-agent/logs` | +| macOS、6.28.0/7.28.0 以前の Agent | `/var/log/datadog` | +| Windows | `C:\ProgramData\Datadog\logs` | + +## Agent のログファイル + +* `agent.log` +* `process-agent.log` +* `trace-agent.log` +* `system-probe.log` +* Agent 7.24.0/6.24.0 以上では `jmxfetch.log` を使用します。 +* Agent 7.46.0 以上では `dogstatsd.log` を使用します。 + +## Agent インストールログファイル + +| プラットフォーム | 場所とファイル名 | +|--------------------------------------|-------------------------------| +| Linux | `$(pwd)/ddagent-install.log` | +| macOS | `/tmp/dd_agent.log` | +| Windows | `%TEMP%\MSI*.LOG` | + +## その他の参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://docs.datadoghq.com/ja/agent/configuration/agent-configuration-files/?tab=agentv6v7#agent-main-configuration-file \ No newline at end of file diff --git a/content/ja/agent/configuration/agent-status-page.md b/content/ja/agent/configuration/agent-status-page.md new file mode 100644 index 0000000000000..b708c98299a0d --- /dev/null +++ b/content/ja/agent/configuration/agent-status-page.md @@ -0,0 +1,279 @@ +--- +algolia: + tags: + - ステータスページ +aliases: +- /ja/agent/guide/agent-status-page +further_reading: +- link: /agent/troubleshooting/ + tag: ドキュメント + text: Agent のトラブルシューティング +- link: /agent/configuration/agent-configuration-files/ + tag: ガイド + text: Agent 構成ファイル +- link: /agent/configuration/agent-commands/ + tag: ガイド + text: Agent のコマンド +title: Agent ステータスページ +--- + +Agent ステータスページでは、実行中の Agent に関する情報が表示されます。[Agent のコマンド][1] で、使用中の環境のステータスコマンドを探すことができます。次のセクションでは、ステータスページの詳細を説明します。 + +**注**: ステータスページは Agent のバージョンにより若干異なる場合があります。 + +## Agent バージョン + +Agent の一般情報は Agent バージョンで見つけることができます。例： +```text + Status date: 2019-08-29 18:16:41.526203 UTC + Agent start: 2019-08-29 18:04:18.060507 UTC + Pid: 12141 + Go Version: go1.11.5 + Python Version: 2.7.16 + Check Runners: 4 + Log Level: info +``` + +### パス + +このセクションには、Datadog コンフィグファイル、`conf.d` ディレクトリと `checks.d` ディレクトリへのパスが表示されます。例： +```text + Config File: /etc/datadog-agent/datadog.yaml + conf.d: /etc/datadog-agent/conf.d + checks.d: /etc/datadog-agent/checks.d +``` + +### クロック + +このセクションには、[NTP オフセット][2] とシステム UTC 時間が表示されます。例： +```text + NTP offset: 2.095ms + System UTC time: 2019-08-29 18:16:41.526203 UTC +``` + +### ホスト情報 + +このセクションには、Agent が実行中のホストに関する情報が表示されます。例： +```text + bootTime: 2019-08-29 18:01:27.000000 UTC + kernelVersion: 4.4.0-109-generic + os: linux + platform: ubuntu + platformFamily: debian + platformVersion: 16.04 + procs: 175 + uptime: 2m53s + virtualizationRole: guest + virtualizationSystem: vbox +``` + +### ホスト名 + +このセクションには、Agent が検出するホスト名が表示されます（以下参照）。`hostname` はバックエンドに報告される最終的なホスト名です。詳細は、[Datadog が Agent ホスト名を決定する方法][3]を参照してください。 + +```text + hostname: ubuntu-xenial + socket-fqdn: ubuntu-xenial + socket-hostname: ubuntu-xenial + hostname provider: os + unused hostname providers: + aws: not retrieving hostname from AWS: the host is not an ECS instance, and other providers already retrieve non-default hostnames + configuration/environment: hostname is empty + gce: unable to retrieve hostname from GCE: Get http://169.254.169.254/computeMetadata/v1/instance/hostname: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) +``` + +## コレクター + +### チェックの実行 + +このセクションには、実行中のチェックインスタンスが一覧表示されます。例： + +```text + load + ---- + Instance ID: load [OK] + Total Runs: 4 + Metric Samples: Last Run: 6, Total: 24 + Events: Last Run: 0, Total: 0 + Service Checks: Last Run: 0, Total: 0 + Histogram Buckets: Last Run: 12, Total: 36 + Average Execution Time : 6ms +``` + +用語と説明 + +| 用語 | 説明 | +|------------------------|------------------------------------------------------------------| +| Instance ID | インスタンス ID とチェックのステータス。 | +| Total Runs | インスタンスが実行された合計回数。 | +| Metric Samples | 取得されたメトリクスの数。 | +| イベント | トリガーされたイベントの数。 | +| サービスチェック | 報告されたサービスチェックの数。 | +| Histogram Buckets | 送信されたヒストグラムバケットの数。 | +| Average Execution Time | インスタンスの実行にかかる平均時間。 | +| Last Run | 最後のチェック実行中の番号。 | +| 合計 | Agent が最後に起動または再起動してからの合計数。 | + +### 構成エラー + +このセクションには、構成エラーのあるチェックのみが表示されます。例： + +```text + test + ---- + Configuration file contains no valid instances +``` + +### 読み込みエラー + +このセクションには、読み込みエラーのあるチェックのみが表示されます。例： + +```text + test + ---- + Core Check Loader: + Check test not found in Catalog + + JMX Check Loader: + check is not a jmx check, or unable to determine if it's so + + Python Check Loader: + unable to import module 'test': No module named test +``` + +## JMXFetch + +このセクションには、チェックがない場合でも、初期化および失敗した JMX チェックが一覧表示されます。例： + +```text + Initialized checks + ================== + no checks + + Failed checks + ============= + no checks +``` + +## Forwarder + +Forwarder はいくつかのワーカーを使用して Datadog にペイロードを送信します。 + +`the forwarder dropped transactions, there is probably an issue with your network` という警告文は、全てのワーカーがビジー状態であることを意味します。ネットワークのパフォーマンスを確認し、 `forwarder_num_workers` と `forwarder_timeout` オプションを調整する必要があります。 + +### トランザクション + +このセクションには、Forwarder が実行したトランザクションが表示されます。例： + +```text + CheckRunsV1: 2 + Dropped: 0 + DroppedOnInput: 0 + Events: 0 + HostMetadata: 0 + IntakeV1: 2 + Metadata: 0 + Requeued: 0 + Retried: 0 + RetryQueueSize: 0 + Series: 0 + ServiceChecks: 0 + SketchSeries: 0 + Success: 6 + TimeseriesV1: 2 + Errors: 1 +``` + +用語と説明 + +| 用語 | 説明 | +|----------------|------------------------------------------------------------------------------| +| Success | 正常に送信されたトランザクションの数。 | +| エラー | トランザクションの送信に失敗し再試行した回数。 | +| RetryQueueSize | 現在再試行を待つトランザクションの数。 | +| Retried | トランザクションを再試行した回数。 | +| DroppedOnInput | ワーカーがビジー状態であるためにドロップされたトランザクションの数。 | +| Dropped | 再試行が多すぎるためにドロップされたトランザクションの数。 | + +### API キーステータス + +このセクションには、構成された API キーのステータスが表示されます。例： + +```text + API key ending with ab123: API Key valid +``` + +## エンドポイント + +このセクションには、Datadog Agent が使用するエンドポイントが一覧表示されます。例： + +```text + https://app.datadoghq.com - API Key ending with: + - ab123 +``` + +## ログ Agent + +ログ Agent が有効な場合、このセクションには処理および送信されたログの情報が表示されます。例、 + +```text + LogsProcessed: 10 + LogsSent: 10 +``` + +## Aggregator + +このセクションには、Agent の Aggregator に関する情報が表示されます。例： + +```text + Checks Metric Sample: 399 + Dogstatsd Metric Sample: 123 + Event: 1 + Events Flushed: 1 + Number Of Flushes: 2 + Series Flushed: 273 + Service Check: 20 + Service Checks Flushed: 20 + Sketches Flushed: 8 + Checks Histogram Bucket Metric Sample: 24 +``` + +用語と説明 + +| 用語 | 説明 | +|----------------------------------------------|-------------------------------------------------------------------------------------------------------| +| Checks Metric Sample | チェックから Aggregator へ送信されたメトリクスの総数。 | +| Dogstatsd Metric Sample | DogStatsD サーバーから Aggregator へ送信されたメトリクスの総数。 | +| イベント | Aggregator へ送信されたイベントの総数。 | +| サービスチェック | Aggregator へ送信されたサービスチェックの総数。 | +| Flush | 集計されたメトリクスが Datadog へ送信するために Forwarder へフラッシュされた回数。 | +| Sketches Flushed | 集計されたディストリビューションメトリクスが Datadog へ送信するために Forwarder へフラッシュされた回数。 | +| Checks Histogram Bucket Metric Sample | チェックから Aggregator に送信されたヒストグラムバケットメトリクスの数。 | + +## DogStatsD + +このセクションには、DogStatsD サーバーが各データタイプや関連するエラーのために受信するパケットの数が表示されます。例： + +```text + Event Packets: 0 + Event Parse Errors: 0 + Metric Packets: 122 + Metric Parse Errors: 0 + Service Check Packets: 0 + Service Check Parse Errors: 0 + Udp Bytes: 7,672 + Udp Packet Reading Errors: 0 + Udp Packets: 123 + Uds Bytes: 0 + Uds Origin Detection Errors: 0 + Uds Packet Reading Errors: 0 + Uds Packets: 0 +``` + +## その他の参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ja/agent/configuration/agent-commands/#agent-information +[2]: /ja/agent/troubleshooting/ntp/ +[3]: /ja/agent/faq/how-datadog-agent-determines-the-hostname/ \ No newline at end of file diff --git a/content/ja/agent/guide/agent-5-log-files.md b/content/ja/agent/guide/agent-5-log-files.md new file mode 100644 index 0000000000000..4117005c1dc1a --- /dev/null +++ b/content/ja/agent/guide/agent-5-log-files.md @@ -0,0 +1,43 @@ +--- +disable_toc: false +private: true +title: Agent 5 のログファイル +--- + +## 概要 + +このページでは、Agent 5 のログファイルについて説明します。Datadog では、最新の機能を利用するために、Agent 7 のインストールまたはアップグレードを推奨しています。Agent の最新バージョンのインストールについては、[Agent 7 のインストール手順][1]に従ってください。以前のバージョンから Agent 7 へのアップグレードについては、[Datadog Agent v7 へのアップグレード][2]を参照してください。 + +Datadog Agent は、デフォルトでログファイルが 10 MB に達するたびにログをローテーションします。ロールオーバーが発生すると、1 つのバックアップ (`agent.log.1`) が保存されます。以前のバックアップが存在する場合、ロールオーバー中に上書きされます。1 つのログファイルの最大サイズと保持するバックアップファイルの最大数を変更するには、[Agent 構成ファイル][3]で `log_file_max_size` (デフォルト: 10 485 760 バイト) と `log_file_max_rolls` (デフォルト: 1) を設定します。 + +## Agent のログディレクトリ + +| プラットフォーム | コマンド | +|--------------------------------------|----------------------------------------------------------------------| +| Linux | `/var/log/datadog/` | +| macOS | `/var/log/datadog/` | +| Windows Server 2008/Vista 以降 | `C:\ProgramData\Datadog\logs\` | +| Windows Server 2003/XP 以前 | `C:\Documents and Settings\All Users\Application Data\Datadog\logs\` | +| SmartOS | `/opt/local/datadog/logs/supervisord/` | +| ソースビルド | `~/.datadog-agent/supervisord/logs/` | + +**注**: Windows Server 2008、Vista 以降のシステムでは、Agent のログは `C:\ProgramData\Datadog\logs` にあります。`ProgramData` は隠しフォルダです。 + +## Agent のログファイル + +* `collector.log` +* `dogstatsd.log` +* `forwarder.log` +* `supervisord.log` + +## Agent インストールログファイル + +| プラットフォーム | 場所とファイル名 | +|--------------------------------------|-------------------------------| +| Linux | `$(pwd)/ddagent-install.log` | +| macOS | `/tmp/dd_agent.log` | +| Windows | `%TEMP%\MSI*.LOG` | + +[1]: https://app.datadoghq.com/account/settings/agent/latest?platform=overview +[2]: /ja/agent/versions/upgrade_to_agent_v7/ +[3]: /ja/agent/guide/agent-5-configuration-files#agent-main-configuration-file \ No newline at end of file diff --git a/content/ja/agent/logs/proxy.md b/content/ja/agent/logs/proxy.md index acb092c7f5abd..3be3da3b13f13 100644 --- a/content/ja/agent/logs/proxy.md +++ b/content/ja/agent/logs/proxy.md @@ -12,7 +12,7 @@ further_reading: title: TCP Agent のログ用プロキシ --- -{{% site-region region="us3,eu,us5,gov,ap1" %}} +{{% site-region region="us3,eu,us5,gov,ap1,ap2" %}}
TCP は {{< region-param key="dd_site_name" >}} サイトでは利用できません。詳細についてはサポートにお問い合わせください。
diff --git a/content/ja/api/latest/on-call-paging/_index.md b/content/ja/api/latest/on-call-paging/_index.md new file mode 100644 index 0000000000000..416cf36a22177 --- /dev/null +++ b/content/ja/api/latest/on-call-paging/_index.md @@ -0,0 +1,3 @@ +--- +title: On-Call Paging +--- diff --git a/content/ja/api/v1/_index.md b/content/ja/api/v1/_index.md index 656a875183d19..d4a5ffa8975c4 100644 --- a/content/ja/api/v1/_index.md +++ b/content/ja/api/v1/_index.md @@ -1,12 +1,12 @@ --- -title: Api V1 build: - render: never list: always publishResources: false + render: never cascade: build: - render: never list: always publishResources: false + render: never +title: Api V1 --- diff --git a/content/ja/api/v2/_index.md b/content/ja/api/v2/_index.md index a19c538714b43..1228112672376 100644 --- a/content/ja/api/v2/_index.md +++ b/content/ja/api/v2/_index.md @@ -1,12 +1,12 @@ --- -title: Api V2 build: - render: never list: always publishResources: false + render: never cascade: build: - render: never list: always publishResources: false + render: never +title: Api V2 --- diff --git a/content/ja/bits_ai/bits_ai_dev_agent.md b/content/ja/bits_ai/bits_ai_dev_agent.md new file mode 100644 index 0000000000000..396a97bd89505 --- /dev/null +++ b/content/ja/bits_ai/bits_ai_dev_agent.md @@ -0,0 +1,62 @@ +--- +further_reading: +- link: https://www.datadoghq.com/blog/bits-ai-dev-agent/ + tag: ブログ + text: Bits AI Dev Agent が問題を自動検出し、修正案を生成 +title: Bits AI Dev Agent +--- + +"{{< callout url="http://datadoghq.com/product-preview/bits-ai-dev-agent" >}} +Bits AI Dev Agent はプレビュー版です。サインアップするには、 Request Access をクリックし、フォームに入力してください。 +{{< /callout >}}" + +{{< img src="bits_ai/dev_agent/error_tracking_assistant.png" alt="Bits AI Dev Agent が Django アプリで発生した IndexError の修正を提案している様子" style="width:100%;">}} + +Bits AI Dev Agent は、可観測性データを活用してコードの重大な問題を検出、診断、修正する生成 AI コーディング アシスタントです。重大な問題が検出されると、プロダクション レディのプル リクエストを自動で作成し、開発者からのフィードバックに基づいて修正を繰り返します。 + +## 主な機能 + +- 重大な問題が検出されると、プロダクション レディの修正を含む GitHub プル リクエストを自動で作成します。 +- チャット メッセージやレビュー コメントに応じてコードを繰り返し改善します。 +- Bits AI Dev Agent が生成したプル リクエストを一元表示し、ステータス、トリガー元のプロダクト、影響を受けるサービスでフィルターできます。 + +## 対応している Datadog プロダクト + +Bits AI Dev Agent は次の Datadog プロダクトで利用できます。 + +| プロダクト | 提供状況 | 検出される問題 | +|---------------------------|----------------------|--------------------------------------------------------------------| +| [Error Tracking][1] | プレビュー | クラッシュ、パニック、例外、未処理エラー | +| [Code Security][2] | プレビュー | ファーストパーティ コードおよびオープン ソース 依存関係におけるセキュリティ問題 | +| [Continuous Profiler][3] | プレビュー | コード レベルのパフォーマンス問題 | + +## セットアップ + +
現時点では、Bits AI Dev Agent がサポートするのは GitHub のみです。
+ +### GitHub インテグレーションを有効化する + +Bits AI Dev Agent を使用するには、 [GitHub integration][4] をインストールする必要があります。インストールと設定の詳細については、 [GitHub インテグレーション ガイド][5] を参照してください。 + +
+ Bits AI Dev Agent の機能を有効にするため、GitHub インテグレーションには次の権限を付与する必要があります: +
    +
  • Repository contents (contents: read, contents: write)
    • +
  • Pull requests (pull_requests: write)
    • +
+
+ +### service と version でテレメトリーにタグを付与する + +Bits AI Dev Agent は `service` と `version` のテレメトリー タグを使用し、エラーや脆弱性などの問題を、その時点で実行されていたコードのバージョンに関連付けます。テレメトリーへのタグ付け方法については、Datadog Source Code Integration ドキュメントの [Tag your telemetry with Git information][6] セクションを参照してください。 + +## 参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ja/error_tracking +[2]: /ja/security/code_security +[3]: /ja/profiler/ +[4]: https://app.datadoghq.com/integrations/github +[5]: /ja/integrations/github/ +[6]: /ja/integrations/guide/source-code-integration/?tab=go#tag-your-telemetry-with-git-information \ No newline at end of file diff --git a/content/ja/cloudcraft/account-management/enable-sso-with-azure-ad.md b/content/ja/cloudcraft/account-management/enable-sso-with-azure-ad.md index 20bbb3deced54..4a11a4cc63c61 100644 --- a/content/ja/cloudcraft/account-management/enable-sso-with-azure-ad.md +++ b/content/ja/cloudcraft/account-management/enable-sso-with-azure-ad.md @@ -13,7 +13,7 @@ Cloudcraft で SSO を使用するための一般的な情報については、[ ## SAML/SSO のセットアップ -
Only the account owner can configure the SAML SSO feature. If the account owner is unable to configure SSO, contact the Cloudcraft support team to enable this feature. +
アカウントオーナーのみが SAML SSO 機能を設定できます。アカウントオーナーが SSO を設定できない場合は、Cloudcraft サポートチームに連絡してこの機能を有効にしてください。
1. Cloudcraft で、**User** > **Security & SSO** に移動します。 @@ -27,7 +27,7 @@ Cloudcraft で SSO を使用するための一般的な情報については、[ 6. **New application** をクリックし、**Non-gallery application** を選択します。 7. アプリケーション名として **Cloudcraft** を入力し、**Add** をクリックします。 -Next, configure the SAML integration using the details provided by Cloudcraft. +次に、Cloudcraft から提供された詳細を使用して SAML インテグレーションを構成します。 1. **Getting started** セクションで、**Set up single sign on** を選択し、**SAML** をクリックします。 2. **Basic SAML Configuration** セクションで、**Edit** をクリックします。 diff --git a/content/ja/cloudcraft/getting-started/group-by-presets.md b/content/ja/cloudcraft/getting-started/group-by-presets.md new file mode 100644 index 0000000000000..465a4613e500b --- /dev/null +++ b/content/ja/cloudcraft/getting-started/group-by-presets.md @@ -0,0 +1,78 @@ +--- +title: Group By と Presets +--- + +Cloudcraft の **Group By** と **Presets** 機能は、インフラストラクチャー、ネットワーク、セキュリティなどのユース ケースに合わせて、カスタムで洞察に富むダイアグラムを作成できるようにします。これらのツールはクラウド アーキテクチャの可視化を効率化し、リソースの分析と管理を容易にします。 + +トラブルシューティング、セキュリティ監査、ネットワーク パフォーマンスの評価など、さまざまな場面で、これらの機能は正確で焦点を絞ったダイアグラムを簡単に生成できるようにし、ワークフローの効率を高めます。 + +## Group By + +**Group By** を使うと、Cloudcraft はダイアグラムをグループ タイプごとの明確なセクションに分割します。この機能により、リソースをわかりやすく整理されたビューで表示でき、複雑なクラウド環境の可視化に特に有用です。 + +### AWS のグルーピング オプション + +AWS では、次の単位でリソースをグループ化できます: +- Region +- VPC +- Security Group +- Subnet +- Network ACL + +### Azure のグルーピング オプション + +Azure では、次の単位でリソースをグループ化できます: +- Resource Group +- Region +- VNet +- Subnet + +## Presets + +**Presets** は、事前定義された group-by とフィルターのセットを適用する便利な方法を提供し、さまざまな視点からリソースをすばやく確認できます。この機能により、ダイアグラムへのグルーピングやフィルターの適用作業が簡素化され、アーキテクチャの特定の側面に集中できます。 + +**Cloudcraft は 3 つの組み込み preset を提供しています:** Infrastructure、Network、Security。これらの preset は、異なる運用上のニーズに対応するよう設計されています。 + +{{< img src="cloudcraft/getting-started/group-by-presets/diagram-presets.png" alt="Infrastructure ダイアグラム プリセットが選択された状態の Cloudcraft インターフェイスで、プリセット オプションを示しています。" responsive="true" style="width:100%;">}} + +preset をダイアグラムに適用するには: + +1. Cloudcraft 内の **Live** タブに切り替えます。 +2. ダイアグラム ビュー上部のメニューから目的の preset を選択します。 +3. 選択した preset を反映してダイアグラムが自動で更新されます。 + +### Infrastructure ダイアグラム + +{{< img src="cloudcraft/getting-started/group-by-presets/infrastructure-diagram.png" alt="サーバー、データベース、セキュリティ コンポーネントとそれらの関係を示す Infrastructure ダイアグラム。" responsive="true" style="width:100%;">}} + +Infrastructure preset は概観を広く提供し、AWS では Region と VPC、Azure では Region と VNet でリソースをグループ化します。トラブルシューティングやハイレベルなレビュー向けに、アーキテクチャ ダイアグラムをすばやく生成するのに最適です。 + +- AWS では、EBS、NAT Gateway、Transit Gateway などのコンポーネントを除外して重要な部分だけを示し、ダイアグラムの煩雑さを抑えます。 +- Azure では、Azure VNGW や Azure Disk などのコンポーネントは表示されません。 + +### Security ダイアグラム + +{{< img src="cloudcraft/getting-started/group-by-presets/security-diagram.png" alt="サーバー、データベース、セキュリティ コンポーネントとそれらの関係を示す Security ダイアグラム。" responsive="true" style="width:100%;">}} + +Security preset は潜在的なセキュリティ リスクに焦点を当て、AWS では Region、VPC、Security Group 単位でリソースをグループ化します。このビューは、受信および送信のサービス通信を制御するルールの把握や、ペネトレーション テストやセキュリティ監査時の攻撃面のマッピングに最適です。 + +- この preset は現在、Azure 構成をサポートしていません。 +- AWS では Infrastructure と同様に、EBS、NAT Gateway など、セキュリティ ビューを煩雑にしかねないコンポーネントを除外します。さらに、複数の Subnet に属している場合、コンポーネントが複数回表示されることがあります。 + +### Network ダイアグラム + +{{< img src="cloudcraft/getting-started/group-by-presets/network-diagram.png" alt="サーバー、データベース、セキュリティ コンポーネントとそれらの関係を示す Network ダイアグラム。" responsive="true" style="width:100%;">}} + +Network preset は Subnet でのグループ化を導入して粒度を高め、レイテンシの原因やトラフィック パターンの特定を目指すネットワーク チームに特に有用です。 + +- AWS では、EBS、S3、SNS などのコンポーネントを除外します。 +- Azure では、Azure Disk および Network Security Group コンポーネントを除外します。 + +## Custom Presets + +特定のユース ケースに合わせたビューが必要な場合、Cloudcraft ではグループ化やフィルターをカスタマイズして、パーソナライズした preset を作成できます。 + +1. 要件に合わせてフィルターと group-by 設定を調整します。 +2. **Save as preset** ボタンをクリックして、カスタム構成を新しい preset として保存します。 + +保存後は、blueprint にアクセスできるユーザーであれば誰でもこれらのカスタム preset を再利用できます。 \ No newline at end of file diff --git a/content/ja/code_analysis/github_pull_requests.md b/content/ja/code_analysis/github_pull_requests.md new file mode 100644 index 0000000000000..aaa92fa66474f --- /dev/null +++ b/content/ja/code_analysis/github_pull_requests.md @@ -0,0 +1,101 @@ +--- +aliases: +- /ja/static_analysis/github_pull_requests +description: GitHub プル リクエストで Code Analysis を使用する方法を学びましょう。 +further_reading: +- link: /integrations/github/ + tag: ドキュメント + text: GitHub インテグレーションについて学びましょう +- link: /code_analysis/ + tag: ドキュメント + text: Code Analysis について学びましょう +title: GitHub プル リクエスト +--- + +## 概要 + +Code Analysis は GitHub プル リクエストと 2 つの方法で連携します: +- [違反をフラグ付けするプル リクエスト コメント](#enable-code-analysis-pr-comments-for-your-repositories): GitHub でコード レビューを行う際、Datadog は少なくとも 1 つのルール セットが適用されているリポジトリのプル リクエストに対し、静的解析 (SAST) の違反を自動で検出し、該当するコード行にインライン レビュー コメントとしてフラグ付けします。また、該当する場合はプル リクエスト内で直接適用できる修正案も提示されます。これは静的解析 (SAST) のみで利用可能です。 +{{< img src="ci/static-analysis-pr-comment-example.png" alt="プル リクエストにおける Code Analysis コメントの例" style="width:90%;" >}} + +- [Datadog から直接問題を修正するプル リクエストを作成](#fixing-a-vulnerability-directly-from-datadog): Datadog が提案するコード修正に基づき、UI からセキュリティ脆弱性またはコード品質の問題を修正するプル リクエストを作成できます。これも静的解析 (SAST) のみで利用可能です。 +{{< img src="ci/sast_one_click_light.png" alt="Code Analysis のワン クリック修正例" style="width:90%;" >}} + +これらの機能を有効化するには、対象リポジトリに GitHub の必要な権限 (Read & Write) が付与されていることを確認してください。 + +## GitHub プル リクエストで Code Analysis をセットアップする + +### Datadog Code Analysis を有効化する + +Datadog Code Analysis を使用するには、[セットアップ手順][1] に従って適切な構成ファイルをリポジトリに追加してください。 + +### GitHub App を設定する + +GitHub で Code Analysis を使用するには、次のいずれかを行ってください。 + +- Datadog で GitHub App を新規作成します。 +- すでに Datadog で作成済みの GitHub App を更新します。 + +付与した権限によって、設定できる [GitHub インテグレーション][2] 機能が決まります。 + +#### GitHub App を作成してインストールする + +1. Datadog で **[Integrations > GitHub Applications > Add New GitHub Application][3]** に移動します。 +1. GitHub 組織名など、必要な情報を入力します。 +1. **Select Features** で **Code Analysis: Pull Request Review Comments** ボックスをチェックします。 +1. **Edit Permissions** で **Pull Requests** 権限が **Read & Write** になっていることを確認します。 +1. **Create App in GitHub** をクリックします。 +1. アプリ名を入力し、送信します。 +1. **Install GitHub App** をクリックします。 +1. アプリをインストールするリポジトリを選択し、**Install & Authorize** をクリックします。 + +{{< img src="ci/static-analysis-install-github-app.png" alt="GitHub App インストール画面" style="width:50%;" >}} + +#### 既存の GitHub App を更新する + +1. Datadog で **[Integrations > GitHub Applications][5]** に移動し、Code Analysis に使用する GitHub App を検索します。 +{{< img src="ci/static-analysis-existing-github-app.png" alt="プル リクエストでの Static Analysis コメントの例" style="width:90%;" >}} +1. **Features** タブの **Code Analysis: Pull Request Comments** セクションを確認し、追加の権限が必要かどうかを判断します。必要であれば **Update permissions in GitHub** をクリックしてアプリ設定を編集します。 +1. **Repository permissions** で **Pull Requests** アクセスを **Read & Write** に設定します。 +{{< img src="ci/static-analysis-pr-read-write-permissions.png" alt="Pull Request Read & Write 権限のドロップ ダウン" style="width:90%;" >}} +1. **Subscribe to events** の下で **Pull request** ボックスをチェックします。 +{{< img src="ci/static-analysis-pr-review-comment.png" alt="Pull Request Review Comment 権限のチェック ボックス" style="width:90%;" >}} + +### Code Analysis の PR コメントをリポジトリで有効化する + +1. Datadog で **[CI Settings > Code Analysis Settings][4]** に移動します。 +1. 対象リポジトリ名の横にあるトグル スイッチをクリックし、**GitHub Comments** を有効化します。下の例では `demo-static-analysis-gates` リポジトリでコメントが有効化されています。 + +{{< img src="ci/static-analysis-github-comments.png" alt="Code Analysis のプル リクエスト コメントの例" style="width:100%;" >}} + +**注:** スキャンの実行に [GitHub Actions][6] を使用している場合、`push` トリガーでアクションを起動しないとコメントは表示されません。 + +### Datadog から直接脆弱性を修正する + +GitHub App の **Pull Requests** 権限が **Read & Write** に設定されている場合、推奨修正が用意されているすべての静的解析結果でワン クリック修正が利用できます。 + +脆弱性を修正してプル リクエストを開く手順 +1. Code Analysis で対象の結果を表示します。 +2. サイド パネルで **Fix Violation** をクリックします。 +3. **Open a Pull Request** を選択します。 +4. プル リクエストのタイトルとコミット メッセージを入力します。 +5. **Create PR** をクリックします。 + +結果が検出されたブランチに直接コミットして修正することも可能です。 + +推奨修正をコミットする手順 + +1. Code Analysis で対象の結果を表示します。 +2. サイド パネルで **Fix Violation** をクリックします。 +3. **Commit to current branch** をクリックします。 + +## その他の参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ja/code_analysis#setup +[2]: /ja/integrations/github/ +[3]: https://app.datadoghq.com/integrations/github/add +[4]: https://app.datadoghq.com/ci/settings/static-analysis +[5]: https://app.datadoghq.com/integrations/github/configuration +[6]: /ja/code_analysis/static_analysis/github_actions/ \ No newline at end of file diff --git a/content/ja/code_analysis/ide_plugins/_index.md b/content/ja/code_analysis/ide_plugins/_index.md new file mode 100644 index 0000000000000..461ed69b23f2a --- /dev/null +++ b/content/ja/code_analysis/ide_plugins/_index.md @@ -0,0 +1,32 @@ +--- +algolia: + tags: + - コード分析 + - datadog code analysis + - static analysis + - ide plugins + - SAST +description: 開発環境におけるコード解析と品質保証を強化するための Datadog IDE プラグインのセットアップ方法について説明します。 +disable_toc: false +further_reading: +- link: /developers/ide_plugins + tag: ドキュメント + text: Datadog IDE プラグインについて +title: Code Analysis のための Datadog IDE プラグイン +--- + +## 概要 + +[Code Analysis][1] は統合開発環境 (IDE) ツールと直接統合し、ファースト パーティ コードの品質とセキュリティに関するリアルタイム フィードバックをコード作成中に提供します。 + +{{< whatsnext desc="以下のインテグレーションについては、ドキュメントを参照してください。">}} + {{< nextlink href="developers/ide_plugins/idea/#static-analysis" >}}JetBrains IDEs: IntelliJ IDEA、GoLand、PhpStorm、PyCharm{{< /nextlink >}} + {{< nextlink href="developers/ide_plugins/vscode/#static-analysis" >}}Visual Studio Code{{< /nextlink >}} + {{< nextlink href="developers/ide_plugins/visual_studio/#static-analysis" >}}Visual Studio{{< /nextlink >}} +{{< /whatsnext >}} + +## その他の参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ja/code_analysis/ \ No newline at end of file diff --git a/content/ja/code_analysis/static_analysis/generic_ci_providers.md b/content/ja/code_analysis/static_analysis/generic_ci_providers.md new file mode 100644 index 0000000000000..837aea242f825 --- /dev/null +++ b/content/ja/code_analysis/static_analysis/generic_ci_providers.md @@ -0,0 +1,119 @@ +--- +algolia: + tags: + - static analysis + - CI パイプライン + - SAST +description: Datadog Static Analysis について学ぶことで、コードが本番環境に到達する前に、コードの品質問題やセキュリティ脆弱性をスキャンすることができます。 +further_reading: +- link: https://www.datadoghq.com/blog/monitor-ci-pipelines/ + tag: ブログ + text: Datadog によるすべての CI パイプラインの監視 +is_beta: false +title: 汎用 CI プロバイダー +--- + +{{< callout url="#" btn_hidden="true" header="Join the Preview!" >}} +Code Analysis is in Preview. +{{< /callout >}} + +{{% site-region region="gov" %}} +
+ Code Analysis は {{< region-param key="dd_site_name" >}} サイトでは利用できません。 +
+{{% /site-region %}} + +## 概要 + +CircleCI Orbs または GitHub Actions を使用しない場合は、CI パイプライン プラットフォームで Datadog CLI を直接実行できます。 + +前提条件: + +- unzip +- Node.js 14 以降 + +次の環境変数を設定します: + +| 名前 | 説明 | 必須 | デフォルト | +|--------------|-----------------------------------------------------------------------------------------------------------------------------------------------------|------|--------------------| +| `DD_API_KEY` | Datadog API キーです。このキーはあなたの [Datadog 組織][1] によって作成され、シークレットとして保存する必要があります。 | はい | | +| `DD_APP_KEY` | Datadog アプリケーション キーです。このキーはあなたの [Datadog 組織][2] によって作成され、`code_analysis_read` スコープを含め、シークレットとして保存してください。 | はい | | +| `DD_SITE` | 情報の送信先となる [Datadog サイト][3] です。あなたの Datadog サイトは {{< region-param key="dd_site" code="true" >}} です。 | いいえ | `datadoghq.com` | + +次の入力を指定します: + +| 名前 | 説明 | 必須 | デフォルト | +|-----------------|-----------------------------------------------------------------------------------------------------------------------------------------------|------|-----------| +| `service` | 結果にタグ付けするサービス名。 | はい | | +| `env` | 結果にタグ付けする環境。`ci` はこの入力に有用な値です。 | いいえ | `none` | +| `cpu_count` | アナライザーが使用する CPU 数を設定します。デフォルトでは、利用可能な CPU の数が使用されます。 | いいえ | | +| `subdirectory` | 解析を限定するサブディレクトリ パス。パスはリポジトリのルート ディレクトリからの相対パスです。 | いいえ | | + +解析対象ファイルの実行時間統計を取得するには、静的解析コマンドに `--performance-statistics` フラグを追加します。 + +次のオプションから、アーキテクチャと OS に対応したアナライザーを選択します: + +| アーキテクチャ | OS | 名前 | リンク | +|---------------|-----------|---------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------| +| `aarch64` | `Darwin` | `datadog-static-analyzer-aarch64-apple-darwin.zip` | [ダウンロード](https://github.com/DataDog/datadog-static-analyzer/releases/latest/download/datadog-static-analyzer-aarch64-apple-darwin.zip) | +| `aarch64` | `Linux` | `datadog-static-analyzer-aarch64-unknown-linux-gnu.zip` | [ダウンロード](https://github.com/DataDog/datadog-static-analyzer/releases/latest/download/datadog-static-analyzer-aarch64-unknown-linux-gnu.zip) | +| `x86_64` | `Darwin` | `datadog-static-analyzer-x86_64-apple-darwin.zip` | [ダウンロード](https://github.com/DataDog/datadog-static-analyzer/releases/latest/download/datadog-static-analyzer-x86_64-apple-darwin.zip) | +| `x86_64` | `Linux` | `datadog-static-analyzer-x86_64-unknown-linux-gnu.zip` | [ダウンロード](https://github.com/DataDog/datadog-static-analyzer/releases/latest/download/datadog-static-analyzer-x86_64-unknown-linux-gnu.zip) | +| `x86_64` | `Windows` | `datadog-static-analyzer-x86_64-pc-windows-msvc.zip` | [ダウンロード](https://github.com/DataDog/datadog-static-analyzer/releases/latest/download/datadog-static-analyzer-x86_64-pc-windows-msvc.zip) | + +次を CI パイプラインに追加します: + +```bash +# 送信先の Datadog サイトを設定 +export DD_SITE="datadoghq.com" + +# 依存関係をインストール +npm install -g @datadog/datadog-ci + +# 最新の Datadog 静的アナライザーをダウンロード: +# https://github.com/DataDog/datadog-static-analyzer/releases +DATADOG_STATIC_ANALYZER_URL=https://github.com/DataDog/datadog-static-analyzer/releases/latest/download/datadog-static-analyzer-x86_64-unknown-linux-gnu.zip +curl -L $DATADOG_STATIC_ANALYZER_URL > /tmp/ddog-static-analyzer.zip +unzip /tmp/ddog-static-analyzer.zip -d /tmp +mv /tmp/datadog-static-analyzer /usr/local/datadog-static-analyzer + +# 静的解析を実行 +/usr/local/datadog-static-analyzer -i . -o /tmp/report.sarif -f sarif + +# 結果をアップロード +datadog-ci sarif upload /tmp/report.sarif +``` + +
+ この例では、Datadog の静的アナライザーの x86_64 Linux 版を使用しています。別の OS またはアーキテクチャを使用している場合は、上の表から選択し、以下の DATADOG_STATIC_ANALYZER_URL の値を更新してください。すべてのリリースは GitHub Releases ページで確認できます。 +
+ + +## Diff-aware scanning + +差分認識スキャンは、 Datadog Static Analysis がフィーチャー ブランチのコミットで変更されたファイルのみをスキャンできるようにする機能です。各スキャンでリポジトリ内のすべてのファイルに対して解析を実行しないため、スキャン時間を大幅に短縮できます。初回のスキャンおよびデフォルト ブランチのスキャンでは、常にリポジトリ全体を解析します (差分認識ではありません)。 + +GitHub Actions を使用している場合、差分認識スキャンはデフォルトで有効です。 + +その他の CI プロバイダーでは、差分認識スキャンを有効にするために次の手順に従ってください: + +1. Make sure your `DD_APP_KEY`, `DD_SITE` and `DD_API_KEY` variables are set in your CI pipeline. +2. Add a call to `datadog-ci git-metadata upload` before invoking the static analyzer. This command ensures that Git metadata is available to the Datadog backend. Git metadata is required to calculate the number of files to analyze. +3. Ensure that the datadog-static-analyzer is invoked with the flag `--diff-aware`. + +Example of commands sequence (these commands must be invoked in your Git repository): +```bash +datadog-ci git-metadata upload + +datadog-static-analyzer -i /path/to/directory -g -o sarif.json -f sarif –-diff-aware <...other-options...> +``` + +**Note:** When a diff-aware scan cannot be completed, the entire directory is scanned. + +## その他の参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ja/account_management/api-app-keys/#api-keys +[2]: /ja/account_management/api-app-keys/#application-keys +[3]: /ja/getting_started/site/ \ No newline at end of file diff --git a/content/ja/code_analysis/static_analysis/github_actions.md b/content/ja/code_analysis/static_analysis/github_actions.md new file mode 100644 index 0000000000000..30e3cddc566f8 --- /dev/null +++ b/content/ja/code_analysis/static_analysis/github_actions.md @@ -0,0 +1,116 @@ +--- +aliases: +- /ja/continuous_integration/static_analysis/github_actions +- /ja/static_analysis/github_actions +dependencies: +- https://github.com/DataDog/datadog-static-analyzer-github-action/blob/main/README.md +description: Datadog と GitHub を使用して、CI パイプラインで Static Analysis ジョブを実行します。 +title: Static Analysis と GitHub Actions +--- +## 概要 + +GitHub Action ワークフローで [Datadog Static Analysis][1] ジョブを実行します。このアクションは [Datadog Static Analyzer][8] をラップし、コード ベースに対して実行した後、その結果を Datadog にアップロードします。 + +## ワークフロー + +Datadog Static Analysis ジョブを実行するためのファイルを `.github/workflows` に作成します。 + +以下はワークフローファイルのサンプルです。 + +```yaml +on: [push] + +jobs: + check-quality: + runs-on: ubuntu-latest + name: Datadog Static Analyzer + steps: + - name: Checkout + uses: actions/checkout@v4 + - name: Check code meets quality standards + id: datadog-static-analysis + uses: DataDog/datadog-static-analyzer-github-action@v1 + with: + dd_app_key: ${{ secrets.DD_APP_KEY }} + dd_api_key: ${{ secrets.DD_API_KEY }} + dd_site: "datadoghq.com" + cpu_count: 2 + enable_performance_statistics: false +``` + +組織レベルでもリポジトリ レベルでも、Datadog API キーとアプリケーション キーを [GitHub リポジトリの secrets][4] として設定 **する必要があります**。Datadog アプリケーション キーには `code_analysis_read` スコープを追加してください。詳細は [API と アプリケーション キー][2] を参照してください。 + +`dd_site` を、使用している Datadog サイトに置き換えてください[3]。 + +## 入力 + +Static Analysis に以下のパラメーターを設定することができます。 + +| 名前 | 説明 | 必須 | デフォルト | +|--------------|---------------------------------------------------------------------------------------------------------------------------------------------------------|----------|-----------------| +| `dd_api_key` | Datadog API キーです。このキーは [Datadog 組織][2] によって作成され、[シークレット][2] として保存する必要があります。 | はい | | +| `dd_app_key` | Datadog アプリケーション キーです。このキーは [Datadog 組織][2] によって作成され、[シークレット][4] として保存する必要があります。 | はい | | +| `dd_site` | 情報を送信する [Datadog サイト][3]。 | いいえ | `datadoghq.com` | +| `cpu_count` | アナライザーが使用する CPU の数を設定します。 | いいえ | `2` | +| `enable_performance_statistics` | 分析されたファイルの実行時間統計を取得します。 | いいえ | `false` | +| `debug` | デバッグに役立つ追加ログをアナライザーに出力させます。有効にするには `yes` を設定します。 | いいえ | `no` | +| `subdirectory` | 解析対象を制限するサブディレクトリ パターンまたはグロブ (複数の場合はスペース区切り) を指定します。例: "src" または "src packages"。 | `false` | | +| `architecture` | アナライザーで使用する CPU アーキテクチャを指定します。サポートされている値は `x86_64` と `aarch64` です。 | いいえ | `x86_64` | +| `diff_aware` | [差分認識スキャン モード][5] を有効にします。 | いいえ | `true` | +| `secrets_enabled` | シークレット スキャンを有効にします (非公開ベータ)。 | いいえ | `false` | + +### 注 + +1. 差分認識スキャンでは、フィーチャ ブランチを解析する際にコミットで変更されたファイルのみをスキャンします。差分認識はデフォルトで有効です。無効にするには、GitHub アクションの `diff_aware` パラメーターを `false` に設定してください。 +2. シークレット スキャンは非公開ベータです。シークレット スキャンを有効にするには、Datadog カスタマー サクセス マネージャーにお問い合わせください。 + +### 廃止済み入力 +以下のアクション入力は廃止されており、もはや効果はありません。これらを指定すると警告が表示されます。 +* `dd_service` +* `dd_env` + +## ルールのカスタマイズ + +デフォルトでは、[Datadog Static Analyzer][8] がコード ベースの言語を自動検出し、デフォルトのルール セットを使用してコード ベースを解析します。 + +ルール セットを指定・カスタマイズするには、リポジトリのルート ディレクトリに `static-analysis.datadog.yml` ファイルを追加し、使用するルール セットを定義してください。 + +```yaml +rulesets: + - + - +``` + +ルール セットの完全な一覧については、[Datadog ドキュメント][6] を参照してください。 + +### Python の例 + +Python ベースのリポジトリ向けの例を次に示します: + +```yaml +rulesets: + - python-code-style + - python-best-practices + - python-inclusive +``` + + +## その他の便利な GitHub Actions + +Datadog Software Composition Analysis (SCA) では、依存関係をスキャンし、脆弱性とライセンスを検出することもできます。このプロダクトは [`datadog-sca-github-action`][7] と組み合わせて利用できます。 + + +## その他の参考資料 + +お役に立つドキュメント、リンクや記事: + +- [Code Analysis について + +[1]: https://docs.datadoghq.com/ja/code_analysis/static_analysis +[2]: https://docs.datadoghq.com/ja/account_management/api-app-keys/ +[3]: https://docs.datadoghq.com/ja/getting_started/site/ +[4]: https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#creating-secrets-for-a-repository +[5]: https://github.com/DataDog/datadog-static-analyzer/blob/main/README.md#diff-aware-scanning +[6]: https://docs.datadoghq.com/ja/code_analysis/static_analysis_rules/ +[7]: https://github.com/DataDog/datadog-sca-github-action +[8]: https://github.com/DataDog/datadog-static-analyzer \ No newline at end of file diff --git a/content/ja/code_analysis/static_analysis/setup.md b/content/ja/code_analysis/static_analysis/setup.md new file mode 100644 index 0000000000000..e797d87683055 --- /dev/null +++ b/content/ja/code_analysis/static_analysis/setup.md @@ -0,0 +1,294 @@ +--- +algolia: + tags: + - static analysis + - static analysis rules + - static application security testing + - SAST +aliases: +- /ja/continuous_integration/static_analysis +- /ja/static_analysis +description: Datadog Static Analysis について学ぶことで、コードが本番環境に到達する前に、コードの品質問題やセキュリティ脆弱性をスキャンすることができます。 +further_reading: +- link: https://www.datadoghq.com/blog/monitor-ci-pipelines/ + tag: ブログ + text: Datadog によるすべての CI パイプラインの監視 +- link: /integrations/guide/source-code-integration/ + tag: ドキュメント + text: ソースコードインテグレーションについて +is_beta: false +title: Static Analysis セットアップ +--- + +{{< callout url="#" btn_hidden="true" header="Join the Preview!" >}} +Code Analysis is in Preview. +{{< /callout >}} + +{{% site-region region="gov" %}} +
+ Code Analysis は {{< region-param key="dd_site_name" >}} サイトでは利用できません。 +
+{{% /site-region %}} + +## 概要 +Datadog Static Analysis をセットアップするには、[**Software Delivery** > **Code Analysis**][1] に移動します。 + +## Static Analysis のスキャンの実行先を選択 +### Datadog ホスト型スキャンでの実行 + +{{< callout url="#" header="false" btn_hidden="true" >}} + Datadog ホスト型の Static Analysis スキャンはプレビュー段階です。アクセスのリクエストはカスタマー サクセス マネージャーに連絡してください。 +{{< /callout >}} + +Datadog のインフラストラクチャ上で直接 Datadog Static Analysis のスキャンを実行できます。開始するには、[**Code Analysis** ページ][1] に移動します。 + +### CI パイプラインでスキャン +Datadog Static Analysis は [`datadog-ci` CLI][8] を使用して CI パイプラインで実行されます。[Datadog API キー と アプリケーション キー (`code_analysis_read` スコープが必要)][3] を設定し、各 CI プロバイダで Static Analysis を実行します。 + +{{< whatsnext desc="CI プロバイダに応じた手順を参照してください:" >}} + {{< nextlink href="code_analysis/static_analysis/circleci_orbs" >}}CircleCI Orbs{{< /nextlink >}} + {{< nextlink href="code_analysis/static_analysis/github_actions" >}}GitHub Actions{{< /nextlink >}} + {{< nextlink href="code_analysis/static_analysis/generic_ci_providers" >}}汎用 CI プロバイダ{{< /nextlink >}} +{{< /whatsnext >}} + +## ソース コード管理プロバイダの選択 +Datadog Static Analysis はすべてのソース コード管理プロバイダをサポートし、GitHub にはネイティブ サポートがあります。 +### GitHub 連携を設定 +ソース コード管理プロバイダが GitHub の場合、[GitHub integration タイル][9] から GitHub App を構成し、[source code integration][10] をセットアップして、インライン コード スニペットを表示し、[pull request comments][11] を有効にする必要があります。 + +GitHub App をインストールする際、特定の機能を有効にするために次の権限が必要です: + +- `Content: Read`: Datadog に表示される コード スニペットを確認できるようにします +- `Pull Request: Read & Write`: [pull request comments][11] を使用して違反に対するフィードバックをあなたの Pull Requests に直接追加できるようにし、さらに [脆弱性を修正][12] するための Pull Requests を作成できるようにします + +### その他のソース コード管理プロバイダ +別のソース コード管理プロバイダを使用している場合は、`datadog-ci` CLI ツールを使用して CI パイプラインで Static Analysis を実行し、Datadog に[結果をアップロード](#upload-third-party-static-analysis-results-to-datadog) してください。 +結果が **Code Analysis** ページに表示され始める前に、デフォルト ブランチでリポジトリの解析を **必ず** 実行する必要があります。 + +## 構成をカスタマイズ +既定では、Datadog Static Analysis は使用しているプログラミング言語向けの [Datadog の ルール セット][6] でリポジトリをスキャンします。適用する ルール セットと適用範囲をカスタマイズするには、リポジトリの **ルート ディレクトリ** に `static-analysis.datadog.yml` ファイルを追加します。 + +`static-analysis.datadog.yml` ファイルには、次の **グローバル** オプションを含めることができます: + +| 名前 | 説明 | 必須 | デフォルト | +|--------------------|--------------------------------------------------------------------------------------------|----------|---------| +| `rulesets` | ルール セット名と構成の一覧。 [利用可能な ルール セットをすべて表示][6]。 | `true` | | +| `ignore` | 無視するパス プレフィックスおよび glob パターンの一覧。 一致したファイルは解析されません。 | `false` | | +| `only` | 解析対象とするパス プレフィックスおよび glob パターンの一覧。 一致したファイルのみ解析されます。| `false` | | +| `ignore-gitignore` | 特定のファイルの解析をスキップするために `.gitignore` ファイルに記載されたパスを使用しないようにします。 | `false` | `false` | +| `max-file-size-kb` | 指定サイズ (kB 単位) より大きいファイルを無視します。 | `false` | `200` | + +`static-analysis.datadog.yml` ファイルには、次の **ruleset** オプションを含めることができます: + +| 名前 | 説明 | 必須 | +|--------------------|----------------------------------------------------------------------------------------------------------------------|----------| +| `rules` | この ruleset に属するルールの構成の一覧。 | `false` | +| `ignore` | この ルール セットに対して無視するパス プレフィックスおよび glob パターン。 該当するファイルは解析されません。 | `false` | +| `only` | この ルール セットに対して解析するパス プレフィックスおよび glob パターン。 該当するファイルのみ解析されます。| `false` | + +`static-analysis.datadog.yml` ファイルには、次の **rule** オプションを含めることができます: + +| 名前 | 説明 | 必須 | +|--------------------|----------------------------------------------------------------------------------------------------------------------|----------| +| `ignore` | このルールに対して無視するパス プレフィックスおよび glob パターン。 該当するファイルは解析されません。 | `false` | +| `only` | このルールに対して解析するパス プレフィックスおよび glob パターン。 該当するファイルのみ解析されます。 | `false` | +| `arguments` | カスタマイズ可能な引数をサポートするルール向けの値のマップ。 | `false` | + +`arguments` フィールドのマップは、引数の名前をキーとし、その値は文字列またはマップです: + +* リポジトリ全体に対して値を設定するには、文字列として指定します。 +* リポジトリ内のサブツリーごとに異なる値を設定するには、サブツリー プレフィックスから、そのサブツリー内でその引数が持つ値へのマップとして指定します。 + +`static-analysis.datadog.yml` ファイルの完全な構造は次のとおりです: + +```yaml +rulesets: + - ruleset-name + - ruleset-name: + # 次のパス / ファイルにのみこの ルール セットを適用します + only: + - "path/example" + - "**/*.file" + # 次のパス / ファイルではこの ルール セットを適用しません + ignore: + - "path/example" + - "**/*.file" + - ruleset-name: + rules: + rule-name: + # 次のパス / ファイルにのみこのルールを適用します + only: + - "path/example" + - "**/*.file" + # 次のパス / ファイルではこのルールを適用しません + ignore: + - "path/example" + - "**/*.file" + arguments: + # ルールの引数を value に設定します + argument-name: value + rule-name: + arguments: + # 異なるサブ ツリーで異なる引数値を設定します + argument-name: + # 既定では value_1 を設定します (リポジトリの root パス) + /: value_1 + # 特定のパスでは value_2 を設定します + path/example: value_2 +# 次のパス / ファイル内にあるもののみを解析します (いずれの ルール セットでも) +only: + - "path/example" + - "**/*.file" +# 次のパス / ファイル内にあるものは解析しません (いずれの ルール セットでも) +ignore: + - "path/example" + - "**/*.file" +``` + +例の構成ファイル: + +```yaml +rulesets: + - python-best-practices + - python-security + - python-code-style: + rules: + max-function-lines: + # 次のファイルには ルール max-function-lines を適用しません + ignore: + - "src/main/util/process.py" + - "src/main/util/datetime.py" + arguments: + # ルール max-function-lines のしきい値を 150 行に設定します + max-lines: 150 + max-class-lines: + arguments: + # ルール max-class-lines のしきい値をサブ ツリーごとに変えます + max-lines: + # 既定ではしきい値を 200 行に設定します (リポジトリの root パス) + /: 200 + # src/main/backend ではしきい値を 100 行に設定します + src/main/backend: 100 + - python-inclusive + - python-django: + # 次のパスにのみ python-django ルール セットを適用します + only: + - "src/main/backend" + - "src/main/django" + # 次のパターンに一致するファイルでは python-django ルール セットを適用しません + ignore: + - "src/main/backend/util/*.py" +# ソース ファイルのみを解析します +only: + - "src/main" + - "src/tests" + - "**/*.py" +# サード パーティ または生成されたファイルは解析しません +ignore: + - "lib/third_party" + - "**/*.generated.py" + - "**/*.pb.py" +``` + +### 違反の無視 +#### リポジトリ単位で無視 +`static-analysis.datadog.yml` ファイルに ignore ルールを追加します。以下の例では、すべてのディレクトリに対して `javascript-express/reduce-server-fingerprinting` ルールを無視します。 + +``` +rulesets: + - javascript-express: + rules: + reduce-server-fingerprinting: + ignore: "**" +``` + +#### ファイルまたはディレクトリで無視 +`static-analysis.datadog.yml` ファイルに ignore ルールを追加します。以下の例では、このファイルに対して `javascript-express/reduce-server-fingerprinting` ルールを無視します。パスでの無視方法の詳細は、[構成のカスタマイズ セクション](#customize-your-configuration) を参照してください。 + +``` +rulesets: + - javascript-express: + rules: + reduce-server-fingerprinting: + ignore: "ad-server/src/app.js" +``` + +#### 特定のインスタンスを無視 + +違反の特定のインスタンスを無視するには、無視したいコード行の上に `no-dd-sa` というコメントを記述します。これにより、その行から違反が生成されることはなくなります。たとえば、次の Python コード スニペットでは、`foo = 1` の行は Static Analysis スキャンで無視されます。 + +```python +#no-dd-sa +foo = 1 +bar = 2 +``` + +すべてのルールを無視するのではなく、特定のルールだけを無視するために `no-dd-sa` を使用することもできます。その場合は、次のテンプレートで `` を無視したいルール名に置き換えて指定します: + +`no-dd-sa:` + +たとえば、次の JavaScript コード スニペットでは、`my_foo = 1` の行は `javascript-code-style/assignment-name` ルールを除くすべてのルールで解析されます。このルールは、開発者に [キャメル ケース][6] を [スネーク ケース][7] の代わりに使用するよう指示します。 + +```javascript +// no-dd-sa:javascript-code-style/assignment-name +my_foo = 1 +myBar = 2 +``` + +## サード パーティの Static Analysis 結果を Datadog にアップロード + +
+ SARIF インポートは Snyk、CodeQL、Semgrep、Checkov、Gitleaks、Sysdig でテスト済みです。他の SARIF 準拠ツールで問題が発生した場合は Datadog サポート までお問い合わせください。 +
+ +相互運用可能な[静的分析結果交換形式 (SARIF)][2] であることを条件に、サードパーティーの静的分析ツールから Datadog へ結果を送信することができます。Node.js バージョン 14 以降が必要です。 + +SARIF レポートをアップロードするには + +1. [`DD_API_KEY` 変数と `DD_APP_KEY` 変数が定義されている][4]ことを確認します。 +2. Optionally, set a [`DD_SITE` variable][7] (this default to `datadoghq.com`). +3. `datadog-ci` ユーティリティをインストールします。 + + ```bash + npm install -g @datadog/datadog-ci + ``` + +4. サードパーティの静的分析ツールをコード上で実行し、結果を SARIF 形式で出力します。 +5. 結果を Datadog にアップロードします。 + + ```bash + datadog-ci sarif upload $OUTPUT_LOCATION + ``` + +## Diff-aware スキャン + +Diff-aware スキャンでは、Datadog の static analyzer がフィーチャー ブランチのコミットで変更されたファイルのみをスキャンします。これにより、毎回のスキャンでリポジトリ内のすべてのファイルを解析しないため、スキャン時間が大幅に短縮されます。CI パイプラインで Diff-aware スキャンを有効にするには、次の手順に従ってください: + +1. CI パイプラインで `DD_APP_KEY`、`DD_SITE`、`DD_API_KEY` 変数が設定されていることを確認します。 +2. static analyzer を起動する前に `datadog-ci git-metadata upload` の呼び出しを追加します。このコマンドは、Datadog バック エンドで Git メタ データを利用できるようにします。解析対象ファイル数を算出するには、Git メタ データが必要です。 +3. datadog-static-analyzer がフラグ `--diff-aware` 付きで呼び出されることを確認します。 + +コマンド シーケンスの例 (これらのコマンドは Git リポジトリ内で実行する必要があります): +```bash +datadog-ci git-metadata upload + +datadog-static-analyzer -i /path/to/directory -g -o sarif.json -f sarif –-diff-aware <...other-options...> +``` + +**注:** Diff-aware スキャンを完了できない場合は、ディレクトリ全体がスキャンされます。 + +## その他の参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://app.datadoghq.com/ci/setup/code-analysis +[2]: https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sarif +[3]: /ja/developers/ide_plugins/idea/#static-analysis +[4]: /ja/account_management/api-app-keys/ +[6]: /ja/code_analysis/static_analysis_rules +[7]: /ja/getting_started/site/ +[8]: https://github.com/DataDog/datadog-ci +[9]: /ja/integrations/github/#link-a-repository-in-your-organization-or-personal-account +[10]: /ja/integrations/guide/source-code-integration +[11]: /ja/code_analysis/github_pull_requests/ +[12]: /ja/code_analysis/github_pull_requests#fixing-a-vulnerability-directly-from-datadog \ No newline at end of file diff --git a/content/ja/containers/guide/ad_identifiers.md b/content/ja/containers/guide/ad_identifiers.md index ada76c9dc9a12..9e023c014d227 100644 --- a/content/ja/containers/guide/ad_identifiers.md +++ b/content/ja/containers/guide/ad_identifiers.md @@ -15,11 +15,11 @@ further_reading: title: オートディスカバリーコンテナ識別子 --- -This document explains how to apply an [Autodiscovery][1] configuration template to a specific container. The `ad_identifiers` parameter can match a container image name or a custom identifier. +このドキュメントでは、特定のコンテナに [オートディスカバリー][1] 構成テンプレートを適用する方法を説明します。`ad_identifiers` パラメーターは、コンテナ イメージ名またはカスタム識別子と一致させることができます。 -## Container image name +## コンテナ イメージ名 -To apply the following Autodiscovery configuration template to a given container, replace `` with the [short][2] container image name: +次のオートディスカバリー構成テンプレートを特定のコンテナに適用するには、`` を [短い][2] コンテナ イメージ名に置き換えてください: ```yaml ad_identifiers: @@ -32,7 +32,7 @@ instances: ``` -**Example**: The following Apache Autodiscovery configuration template applies to a container image named `httpd`: +**例**: 次の Apache オートディスカバリー構成テンプレートは、`httpd` という名前のコンテナ イメージに適用されます: ```yaml ad_identifiers: @@ -45,9 +45,9 @@ logs: service: webapp ``` -This matches **any** `httpd` container image on your host. If you have one container running `foo/httpd:latest` and another running `bar/httpd:v2`, the Agent applies the above template to both containers. +これは、ホスト上の **すべての** `httpd` コンテナ イメージに一致します。`foo/httpd:latest` を実行しているコンテナと `bar/httpd:v2` を実行しているコンテナがある場合でも、Agent は上記のテンプレートを両方のコンテナに適用します。 -When using short image names as Autodiscovery container identifiers, the Agent cannot distinguish between identically named images from different sources or with different tags. +短いイメージ名をオートディスカバリーのコンテナ識別子として使用する場合、Agent は異なるソースやタグで同じ名前のイメージを区別できません。 ### 複数の識別子 @@ -59,16 +59,16 @@ ad_identifiers: - my-custom-httpd-image ``` -This matches **any** container images on your host that match `httpd` **or** `my-custom-httpd-image`. +これは、ホスト上で `httpd` **または** `my-custom-httpd-image` に一致する **すべての** コンテナ イメージに適用されます。 ## カスタムなオートディスカバリーコンテナ識別子 -If you want to apply different configuration templates to containers running the same image, use custom container identifiers. +同じイメージを実行するコンテナに別々の構成テンプレートを適用したい場合は、カスタム コンテナ識別子を使用してください。 -1. Supply a custom container identifier to your container using a Docker label or Kubernetes annotation. +1. Docker ラベルまたは Kubernetes アノテーションを使用して、コンテナにカスタム コンテナ識別子を付与します。 - **Example**: - Apply a Docker label or Kubernetes annotation to identify your container as `foo`: + **例**: + `foo` としてコンテナを識別する Docker ラベルまたは Kubernetes アノテーションを適用します: {{< tabs >}} {{% tab "Docker label" %}} @@ -77,25 +77,25 @@ If you want to apply different configuration templates to containers running the LABEL com.datadoghq.ad.check.id="foo" ``` - **Note**: The `com.datadoghq.ad.check.id` label takes precedence over the image name. + **注**: `com.datadoghq.ad.check.id` ラベルはイメージ名より優先されます。 {{% /tab %}} {{% tab "Kubernetes annotation" %}} ```text - ad.datadoghq.com/.check.id: 'foo' + ad.datadoghq.com/.check.id: 'foo' ``` - Replace `` with the container name within the pod. + `` をポッド内のコンテナ名に置き換えてください。 - **Note**: Supported in Datadog Agent v6.25+ and v7.25. The `ad.datadoghq.com/.check.id` label takes precedence over the image name. + **注**: Datadog Agent v6.25+ および v7.25 でサポートされています。`ad.datadoghq.com/.check.id` ラベルはイメージ名より優先されます。 {{% /tab %}} {{< /tabs >}} -2. Reference this custom value in your Autodiscovery configuration template. +2. このカスタム値をオートディスカバリー構成テンプレート内で参照します。 - **Example**: - The following Apache Autodiscovery configuration template designates a container image with the custom name `foo`: + **例**: + 次の Apache オートディスカバリー構成テンプレートは、`foo` というカスタム名のコンテナ イメージを指定します: ```yaml ad_identifiers: diff --git a/content/ja/containers/guide/autodiscovery-with-jmx.md b/content/ja/containers/guide/autodiscovery-with-jmx.md index ef8bd500f556b..27944b5d1455b 100644 --- a/content/ja/containers/guide/autodiscovery-with-jmx.md +++ b/content/ja/containers/guide/autodiscovery-with-jmx.md @@ -1,4 +1,14 @@ --- +algolia: + tags: + - JMX + - JMX メトリクス + - Web ロジックの欠落 + - JMX 制限 + - Cassandra + - Kafka + - Tomcat + - Weblogic aliases: - /ja/agent/guide/autodiscovery-with-jmx further_reading: @@ -73,7 +83,7 @@ kind: Pod metadata: name: annotations: - ad.datadoghq.com/.checks: | + ad.datadoghq.com/.checks: | { "": { "init_config": { @@ -89,7 +99,7 @@ metadata: # (...) spec: containers: - - name: '' + - name: '' # (...) env: - name: POD_IP @@ -109,7 +119,7 @@ spec: この例では - `` はポッドの名前です。 -- `` はポッド内の希望するコンテナにマッチします。 +- `` はポッド内の希望するコンテナにマッチします。 - `` は希望する JMX インテグレーションの名前です。利用可能な JMX インテグレーション](#available-jmx-integrations)のリストを参照してください。 - `` は、アノテーションと `JAVA_OPTS` 間で一致する限り、任意に設定します。 @@ -168,7 +178,7 @@ spec: これらのインテグレーションから追加のメトリクスを収集する必要がある場合は、`init_config` セクションに追加します。 ```yaml -ad.datadoghq.com/.checks: | +ad.datadoghq.com/.checks: | { "": { "init_config": { @@ -217,7 +227,7 @@ Datadog-JMX インテグレーションのより複雑なカスタム構成を ```yaml ad_identifiers: - - "" + - init_config: is_jmx: true @@ -229,7 +239,7 @@ instances: port: "" ``` -`` は、希望するコンテナのショートイメージ名に置き換えてください。例えば、コンテナイメージ `gcr.io/CompanyName/my-app:latest` のショートイメージ名は `my-app` です。Datadog Agent がこのコンテナを検出すると、このファイルに記述されているように JMX 構成を設定します。 +`` は、希望するコンテナのショートイメージ名に置き換えてください。例えば、コンテナイメージ `gcr.io/CompanyName/my-app:latest` のショートイメージ名は `my-app` です。Datadog Agent がこのコンテナを検出すると、このファイルに記述されているように JMX 構成を設定します。 ショートイメージ名を基にしたくない場合は、[コンテナへのカスタム識別子][4]を参照して指定することもできます。 @@ -258,7 +268,7 @@ spec: configDataMap: .yaml: |- ad_identifiers: - - "" + - init_config: is_jmx: true @@ -278,7 +288,7 @@ datadog: confd: .yaml: | ad_identifiers: - - "" + - init_config: is_jmx: true @@ -290,7 +300,7 @@ datadog: {{% /tab %}} {{% tab "Custom image" %}} -If you cannot mount these files in the Agent container (for example, on Amazon ECS) you can build an Agent Docker image containing the desired configuration files. +これらのファイルを Agent コンテナにマウントできない場合 (Amazon ECS など)、希望するコンフィギュレーションファイルを含む Agent Docker イメージを構築できます。 例: diff --git a/content/ja/containers/guide/cluster_agent_autoscaling_metrics.md b/content/ja/containers/guide/cluster_agent_autoscaling_metrics.md index 9fba7effd55fc..9534a83151104 100644 --- a/content/ja/containers/guide/cluster_agent_autoscaling_metrics.md +++ b/content/ja/containers/guide/cluster_agent_autoscaling_metrics.md @@ -368,6 +368,13 @@ Datadog Cluster Agent は、自動的にそのネームスペース (`dcaautogen 後で HPA を移行して `DatadogMetric` を参照するようにした場合、自動生成されたリソースは数時間後に Datadog Cluster Agent によりクリーンアップされます。 +オプションで、この動作を無効にするには、`DD_EXTERNAL_METRICS_PROVIDER_ENABLE_DATADOGMETRIC_AUTOGEN` を `false` に設定します。 + +```yaml +- name: DD_EXTERNAL_METRICS_PROVIDER_ENABLE_DATADOGMETRIC_AUTOGEN + value: "false" +``` + ## Cluster Agent によるクエリの実行 Cluster Agent は `DatadogMetric` オブジェクト用に 30 秒ごとにクエリを実行します。また、Cluster Agent は、実行されたメトリクスクエリを 35 件ずつグループ化します。したがって、Datadog メトリクス API に対する 1 つのリクエストには 35 件の`DatadogMetric` クエリが含まれます。 diff --git a/content/ja/containers/guide/compose-and-the-datadog-agent.md b/content/ja/containers/guide/compose-and-the-datadog-agent.md index 19889881a945e..3b8726ae451c3 100644 --- a/content/ja/containers/guide/compose-and-the-datadog-agent.md +++ b/content/ja/containers/guide/compose-and-the-datadog-agent.md @@ -67,6 +67,72 @@ FROM gcr.io/datadoghq/agent:latest ADD conf.d/redisdb.yaml /etc/datadog-agent/conf.d/redisdb.yaml ``` +### APM トレース収集 + +上記の Redis 例を基に、Compose を使用して Datadog Agent を構成し、アプリケーション トレースを収集することもできます。この `docker-compose.yml` は、GitHub の [Docker Compose 例][4]から取得したものです。 + +```yaml +version: "4" +services: + web: + build: web + command: ddtrace-run python app.py + ports: + - "5000:5000" + volumes: + - ./web:/code # 新しい app パスに対応するように変更 + links: + - redis + environment: + - DATADOG_HOST=datadog # web アプリが Datadog ライブラリを初期化する際に使用 + - DD_AGENT_HOST=dd-agent # トレース送信先として dd-agent を指す + redis: + image: redis + # Agent セクション + datadog: + container_name: dd-agent + build: datadog + links: + - redis # redis がコンテナで解決可能なホスト名になるように保証 + - web # web アプリがメトリクスを送信できるように保証 + environment: + - DD_API_KEY= + - DD_DOGSTATSD_NON_LOCAL_TRAFFIC=true # 他コンテナからのカスタム メトリクスを Agent が受信できるようにする + - DD_APM_ENABLED=true # トレースを有効化 + - DD_APM_NON_LOCAL_TRAFFIC=true # 他コンテナからのトレースを Agent が受信できるようにする + - DD_AGENT_HOST=dd-agent # web コンテナがトレースを Agent に転送できるようにする + - DD_SITE=datadoghq.com # データ送信先の Datadog インスタンスを指定 (例: EU1 なら datadoghq.eu に変更) + volumes: + - /var/run/docker.sock:/var/run/docker.sock + - /proc/:/host/proc/:ro + - /sys/fs/cgroup:/host/sys/fs/cgroup:ro +``` + +`` をあなたの API キーに置き換えてください。 + +前述の例での主な変更点は、`DD_AGENT_HOST` 環境変数の設定です。トレースを収集するためには、`web` コンテナと Agent コンテナの両方で同じ値にする必要があります。`DD_APM_ENABLED` は APM を有効にし、`DD_APM_NON_LOCAL_TRAFFIC` は Agent が他コンテナからのトレースを受信できるようにします。 + +この例では、Python Web アプリの `requirements.txt` に `ddtrace` ライブラリも追加しており、`ddtrace-run` で初期化して APM を有効化します。(以下のリストにある `datadog` ライブラリは、カスタム DogStatsD メトリクスを収集するために使用されます。) +``` +flask +redis +datadog +ddtrace <-- +``` + +最後に、Web アプリの `Dockerfile` を次のように変更して、`service`、`env`、`version` タグを設定します: + +```dockerfile +FROM python:2.7 +ADD . /code +WORKDIR /code +RUN pip install -r requirements.txt + +# ここで DD タグを設定する +ENV DD_SERVICE web <-- Datadog での "service" 名を設定 +ENV DD_ENV sandbox <-- Datadog での "env" 名を設定 +ENV DD_VERSION 1.0 <-- Datadog での "version" 番号を設定 +``` ### ログ収集 @@ -93,7 +159,7 @@ services: - /var/lib/docker/containers:/var/lib/docker/containers:ro ``` -**注**: 上記の構成では、`Redis` コンテナからログを収集するのみです。同様の `com.datadoghq.ad.logs` ラベルを追加することで、Datadog Agent からログを収集することができます。また、環境変数 `DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL` を `true` に設定することにより、全てのコンテナに対して明示的にログ収集を有効にすることができます。詳細は [Docker ログ収集ドキュメント][4]を参照してください。 +**注**: この構成では `Redis` コンテナのログのみを収集します。Datadog Agent のログを収集したい場合は、同様の `com.datadoghq.ad.logs` ラベルを追加してください。すべてのコンテナからログを収集するには、環境変数 `DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL` を `true` に設定します。詳細は [Docker ログ収集][5]を参照してください。 ## その他の参考資料 @@ -103,4 +169,5 @@ services: [1]: https://docs.docker.com/compose/overview [2]: /ja/agent/docker/ [3]: https://github.com/DataDog/integrations-core/blob/master/redisdb/datadog_checks/redisdb/data/conf.yaml.example -[4]: /ja/agent/logs/ \ No newline at end of file +[4]: https://github.com/DataDog/docker-compose-example +[5]: /ja/agent/logs/ \ No newline at end of file diff --git a/content/ja/containers/guide/template_variables.md b/content/ja/containers/guide/template_variables.md index ecebc13079791..a3f09c5e4730c 100644 --- a/content/ja/containers/guide/template_variables.md +++ b/content/ja/containers/guide/template_variables.md @@ -6,10 +6,10 @@ aliases: further_reading: - link: /containers/kubernetes/integrations/ tag: Documentation - text: Configure integrations with Autodiscovery on Kubernetes + text: Kubernetes で Autodiscovery を使用してインテグレーションを構成する - link: /containers/docker/integrations/ tag: Documentation - text: Configure integrations with Autodiscovery on Docker + text: Docker で Autodiscovery を使用してインテグレーションを構成する - link: /agent/guide/ad_identifiers/ tag: Documentation text: コンテナと該当するインテグレーションテンプレートとの対応 @@ -19,28 +19,28 @@ further_reading: title: オートディスカバリーテンプレート変数 --- -[Autodiscovery][1] enables you to set static configurations for dynamic resources like containers. +[Autodiscovery][1] を使用すると、コンテナのような動的リソースに対して静的な設定を行うことができます。 -You can use the following template variables to dynamically assign your container's values: +コンテナの値を動的に割り当てるために、以下のテンプレート変数を使用できます: | テンプレート変数 | 説明 | | -------------------------- | --- | -| `"%%host%%"` | The container's network IP. | -| `"%%host_<ネットワーク名>%%"` | When the container is attached to multiple networks, returns the network name to use. | -| `"%%port%%"` | The highest exposed port **sorted numerically and in ascending order**.
For example, returns `8443` for a container that exposes ports `80`, `443`, and `8443`. | -| `"%%port_<数値_X>%%"` | The `` port **sorted numerically and in ascending order**.
For example, if a container exposes ports `80`, `443`, and `8443`, `"%%port_0%%` refers to port `80`, and `"%%port_1%%"` refers to `443`. | -| `"%%port_<名前>%%"` | The port associated with the port name ``. | -| `"%%pid%%"` | The container process ID, as returned by `docker inspect --format '{{.State.Pid}}' `. | -| `"%%hostname%%"` | The `hostname` value from the container configuration. Only use this variable if the `"%%host%%"` variable cannot fetch a reliable IP (for example, in [ECS awsvpc mode][2]). | -| `"%%env_<環境変数>%%"` | The contents of the `$` environment variable **as seen by the Agent process**. | -| `"%%kube_namespace%%"` | The Kubernetes namespace. | -| `"%%kube_pod_name%%"` | The Kubernetes pod name. | -| `"%%kube_pod_uid%%"` | The Kubernetes pod UID. | +| `"%%host%%"` | コンテナのネットワーク IP。 | +| `"%%host_<ネットワーク名>%%"` | コンテナが複数のネットワークに接続されている場合、使用すべきネットワーク名を返します。 | +| `"%%port%%"` | 最も大きい公開ポート (**数値で昇順にソート**)。
例えば、ポート `80`、`443`、`8443` を公開するコンテナの場合、`8443` が返されます。 | +| `"%%port_<数値_X>%%"` | `` ポート (**数値で昇順にソート**)。
例えば、コンテナがポート `80`、`443`、`8443` を公開している場合、`"%%port_0%%` はポート `80`、`"%%port_1%%"` は `443` を指します。 | +| `"%%port_<名前>%%"` | `` というポート名に関連付けられたポート。 | +| `"%%pid%%"` | `docker inspect --format '{{.State.Pid}}' ` で返されるコンテナのプロセス ID。 | +| `"%%hostname%%"` | コンテナ設定の `hostname` 値。`"%%host%%"` 変数で信頼できる IP を取得できない場合 (例えば、[ECS awsvpc モード][2]など) のみ、この変数を使用してください。 | +| `"%%env_<環境変数>%%"` | Agent プロセスから見える `$` 環境変数の内容。 | +| `"%%kube_namespace%%"` | Kubernetes ネームスペース。 | +| `"%%kube_pod_name%%"` | Kubernetes Pod 名。 | +| `"%%kube_pod_uid%%"` | Kubernetes Pod UID。 | **フォールバック**: -* For the `"%%host%%"` template variable: in case the Agent is not able to find the IP, this template variable falls back to the `bridge` network IP. -* For the `"%%host_%%"`: if the `` specified is not found, this template variable behaves like `"%%host%%"`. +* `"%%host%%"` テンプレート変数について: Agent が IP を検出できない場合、このテンプレート変数は `bridge` ネットワークの IP にフォールバックします。 +* `"%%host_%%"` について: 指定した `` が見つからない場合、このテンプレート変数は `"%%host%%"` と同様に動作します。 プラットフォームによっては、すべてのテンプレート変数がサポートされているわけではありません。 diff --git a/content/ja/containers/troubleshooting/_index.md b/content/ja/containers/troubleshooting/_index.md index 7f46317b290cd..4af35529e1854 100644 --- a/content/ja/containers/troubleshooting/_index.md +++ b/content/ja/containers/troubleshooting/_index.md @@ -15,7 +15,7 @@ Agent のデプロイ方法には、以下の 3 つがあります。 2. [Amazon ECS][2] や [Amazon ECS 環境の Fargate][3]、[Amazon EKS][4] などの**クラウド環境**で -3. In a [Kubernetes environment][16] +3. [Kubernetes 環境][16]で これらの異なる方法には、独自のデプロイメント上の課題があります。このページは、問題を解決するための出発点として使用してください。問題が解決しない場合は、[Datadog サポート][6]に連絡してください。 @@ -31,7 +31,7 @@ Agent のリリース更新や変更の詳細については、Datadog の[リ 以下が正しいことを確認します。 -- The metrics endpoint is exposed and is open for the Agent to reach. +- メトリクスエンドポイントは公開され、Agent がアクセスできるようになっている。 - Agent がエンドポイントにアクセスするのを妨げるようなプロキシやファイアウォールは存在しない。 @@ -84,7 +84,7 @@ IAM ポリシーが更新されていることを確認します。 - [ECS][12]: ログを収集するコンテナにログルーターがアタッチされていることを確認します。 - - [EKS][13]: There are two common ways for the Agent to collect logs in an EKS Fargate environment: Log forwarding with CloudWatch logs, and log forwarding through [Amazon Data Firehose][14]. Using Amazon Data Firehose to collect logs requires the successful implementation of the Amazon Data Firehose delivery stream, as well as some command line tools. + - [EKS][13]: EKS Fargate 環境において Agent がログを収集する一般的な方法は 2 つあります。CloudWatch のログを利用したログ転送と、[Amazon Data Firehose][14] を利用したログ転送です。Amazon Data Firehose を使用してログを収集するには、Amazon Data Firehose の配信ストリームを正常に実装する必要があり、いくつかのコマンドラインツールも必要です。 ## Kubernetes @@ -99,7 +99,16 @@ IAM ポリシーが更新されていることを確認します。 Azure Kubernetes Service (AKS) や Google Kubernetes Engine (GKE) などのマネージドサービスでは、ユーザーは Control Plane コンポーネントにアクセスできません。そのため、これらの環境では `kube_apiserver`、`kube_controller_manager`、`kube_scheduler`、または `etcd` チェックを実行することができません。 +## ECS Fargate +### Windows Agent がサービスの起動時にタイムアウトする + +```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)] +``` + +このエラーを回避するには、 Datadog Agent に対して **CPU units** のリザベーションを少なくとも `512` に設定してください。 # Datadog サポートが収集するトラブルシューティングのデータ diff --git a/content/ja/containers/troubleshooting/cluster-agent.md b/content/ja/containers/troubleshooting/cluster-agent.md new file mode 100644 index 0000000000000..169bde3c85a8e --- /dev/null +++ b/content/ja/containers/troubleshooting/cluster-agent.md @@ -0,0 +1,149 @@ +--- +aliases: +- /ja/agent/cluster_agent/troubleshooting +- /ja/containers/cluster_agent/troubleshooting +further_reading: +- link: https://www.datadoghq.com/blog/datadog-cluster-agent/ + tag: ブログ + text: Datadog Cluster Agent のご紹介 +- link: /containers/kubernetes/installation/ + tag: ドキュメント + text: Kubernetes のインストール +- link: /containers/kubernetes/integrations/ + tag: ドキュメント + text: カスタムインテグレーション +title: Cluster Agent のトラブルシューティング +--- + +このドキュメントには、次のコンポーネントのトラブルシューティング情報が記載されています。 + +- [Datadog Cluster Agent](#datadog-cluster-agent) +- [Node Agent](#node-agent) + +## Datadog Cluster Agent + +Cluster Agent のトラブルシューティングコマンドを実行するには、まず Cluster Agent またはノードベースの Agent ポッド内に入る必要があります。そのために、次のコマンドを使用します。 + +```text +kubectl exec -it bash +``` + +Datadog Cluster Agent が提供するクラスターレベルのメタデータを確認するには、次を実行します。 + +```text +agent metamap +``` + +次の結果が表示されます。 + +```text +root@datadog-cluster-agent-8568545574-x9tc9:/# agent metamap + +=============== +Metadata Mapper +=============== + +Node detected: gke-test-default-pool-068cb9c0-sf1w + + - Namespace: kube-system + - Pod: kube-dns-788979dc8f-hzbj5 + Services: [kube-dns] + - Pod: kube-state-metrics-5587867c9f-xllnm + Services: [kube-state-metrics] + - Pod: kubernetes-dashboard-598d75cb96-5khmj + Services: [kubernetes-dashboard] + +Node detected: gke-test-default-pool-068cb9c0-wntj + + - Namespace: default + - Pod: datadog-cluster-agent-8568545574-x9tc9 + Services: [datadog-custom-metrics-server dca] + + - Namespace: kube-system + - Pod: heapster-v1.5.2-6d59ff54cf-g7q4h + Services: [heapster] + - Pod: kube-dns-788979dc8f-q9qkt + Services: [kube-dns] + - Pod: l7-default-backend-5d5b9874d5-b2lts + Services: [default-http-backend] + - Pod: metrics-server-v0.2.1-7486f5bd67-v827f + Services: [metrics-server] +``` + +Datadog Cluster Agent が照会されていることを確認するには、以下を探します。 + +```text +root@datadog-cluster-agent-8568545574-x9tc9:/# tail -f /var/log/datadog/cluster-agent.log +2018-06-11 09:37:20 UTC | DEBUG | (metadata.go:40 in GetPodMetadataNames) | CacheKey: agent/KubernetesMetadataMapping/ip-192-168-226-77.ec2.internal, with 1 services +2018-06-11 09:37:20 UTC | DEBUG | (metadata.go:40 in GetPodMetadataNames) | CacheKey: agent/KubernetesMetadataMapping/ip-192-168-226-77.ec2.internal, with 1 services +``` + +イベントを正しく収集できない場合は、`DD_LEADER_ELECTION` と `DD_COLLECT_KUBERNETES_EVENTS` を `true` に設定し、RBAC に記載されている適切な動詞 (特に、`watch events`) も設定するようにしてください。 + +これらを有効にしている場合は、リーダー選出ステータスと `kube_apiserver` チェックを次のコマンドで確認します。 + +```text +agent status +``` + +これにより、次の結果が生成されます。 + +```text +root@datadog-cluster-agent-8568545574-x9tc9:/# agent status +[...] + Leader Election + =============== + Leader Election Status: Running + Leader Name is: datadog-cluster-agent-8568545574-x9tc9 + Last Acquisition of the lease: Mon, 11 Jun 2018 06:38:53 UTC + Renewed leadership: Mon, 11 Jun 2018 09:41:34 UTC + Number of leader transitions: 2 transitions +[...] + Running Checks + ============== + kubernetes_apiserver + -------------------- + Total Runs: 736 + Metrics: 0, Total Metrics: 0 + Events: 0, Total Events: 100 + Service Checks: 3, Total Service Checks: 2193 +[...] +``` + +## Node Agent + +Agent ステータスコマンドを実行することで、Datadog Cluster Agent のステータスを確認できます。 +`agent status` + +Datadog Cluster Agent が有効になっており、正しく構成されている場合、以下が表示されます。 + +```text +[...] + ===================== + Datadog Cluster Agent + ===================== + - Datadog Cluster Agent endpoint detected: https://XXX.XXX.XXX.XXX:5005 + Successfully Connected to the Datadog Cluster Agent. + - Running: {Major:1 Minor:0 Pre:xxx Meta:xxx Commit:xxxxx} +``` + +DNS が環境変数で使用できるように、Agent のポッドの前に Cluster Agent サービスが作成されていることを確認します。 + +```text +root@datadog-agent-9d5bl:/# env | grep DATADOG_CLUSTER_AGENT | sort +DATADOG_CLUSTER_AGENT_PORT=tcp://10.100.202.234:5005 +DATADOG_CLUSTER_AGENT_PORT_5005_TCP=tcp://10.100.202.234:5005 +DATADOG_CLUSTER_AGENT_PORT_5005_TCP_ADDR=10.100.202.234 +DATADOG_CLUSTER_AGENT_PORT_5005_TCP_PORT=5005 +DATADOG_CLUSTER_AGENT_PORT_5005_TCP_PROTO=tcp +DATADOG_CLUSTER_AGENT_SERVICE_HOST=10.100.202.234 +DATADOG_CLUSTER_AGENT_SERVICE_PORT=5005 +DATADOG_CLUSTER_AGENT_SERVICE_PORT_AGENTPORT=5005 + +root@datadog-agent-9d5bl:/# echo ${DD_CLUSTER_AGENT_AUTH_TOKEN} +DD_CLUSTER_AGENT_AUTH_TOKEN=1234****9 +``` + +## その他の参考資料 + +{{< partial name="whats-next/whats-next.html" >}} \ 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 08fc3ee13a266..99a6cea4a43ba 100644 --- a/content/ja/continuous_integration/explorer/search_syntax.md +++ b/content/ja/continuous_integration/explorer/search_syntax.md @@ -50,6 +50,8 @@ title: CI Visibility Explorer の検索構文 * `web*` は、`web` で始まるすべてのログメッセージに一致します。 * `*web` は、`web` で終わるすべてのログメッセージに一致します。 +**注**: ワイルドカードはダブルクォーテーションの外側でのみワイルドカードとして機能します。たとえば、`@ci.pipeline.name:"*test*"` は名前に文字列 `*test*` を含むパイプラインに一致しますが、`@ci.pipeline.name:*test*` は名前に文字列 `test` を含むパイプラインに一致します。 + ワイルドカード検索は、この構文でタグや属性 (ファセット化されていないものも含む) 内で機能します。 ### ワイルドカードを検索 diff --git a/content/ja/continuous_integration/guides/pipeline_data_model.md b/content/ja/continuous_integration/guides/pipeline_data_model.md index be834cc928ac1..423efd8698143 100644 --- a/content/ja/continuous_integration/guides/pipeline_data_model.md +++ b/content/ja/continuous_integration/guides/pipeline_data_model.md @@ -17,7 +17,7 @@ title: パイプラインのデータモデルと実行タイプ パイプラインの実行は、[APM の分散トレース][1]と同様にトレースとしてモデル化され、スパンがパイプラインの各部分の実行を表します。CI Visibility でパイプライン実行を表すデータモデルは、4 つのレベルで構成されます。 -| レベル名 | 説明 | +| レベル名 | 説明 | | ---------- | ----------- | | パイプライン (必須) | 他のすべてのレベルを子として含む、最上位のルートスパン。パイプラインの開始から終了までの全体的な実行を表します。CI プロバイダーによっては、このレベルを `build` や `workflow` と呼ぶこともあります。 | | ステージ | ユーザーが定義した名前でジョブをグループ化するレベルです。一部の CI プロバイダーでは、このレベルが存在しない場合があります。 | diff --git a/content/ja/continuous_testing/settings/_index.md b/content/ja/continuous_testing/settings/_index.md index 442b7049e8e7c..e2695e95f47b1 100644 --- a/content/ja/continuous_testing/settings/_index.md +++ b/content/ja/continuous_testing/settings/_index.md @@ -24,9 +24,9 @@ title: Continuous Testing 設定 ## 概要 -You can access Continuous Testing settings on the [Synthetic Monitoring & Testing Settings page][1]. +Continuous Testing の設定には、[Synthetic Monitoring & Testing Settings ページ][1]からアクセスできます。 -{{< img src="continuous_testing/settings/parallelization.png" alt="Set parallelization for your Continuous Testing tests on the Settings page" style="width:100%;">}} +{{< img src="continuous_testing/settings/parallelization.png" alt="Settings ページで Continuous Testing テストの並列実行を設定する" style="width:100%;">}} デフォルトでは、CI/CD パイプラインで実行されるすべてのテストは、順次実行されます (1 つずつ実行されます)。この動作を変更するには、[並列化値](#set-parallelization)を設定し、選択を保存してください。 @@ -59,7 +59,7 @@ $$\text"estimated parallelization" = {\text"CI バッチあたりの平均テス 3. **Save Selection** をクリックします。 4. 選択内容を確認します。 -{{< img src="continuous_testing/settings/parallelization.png" alt="Parallelization settings for 25 parallel Continuous Testing test runs" style="width:100%;">}} +{{< img src="continuous_testing/settings/parallelization.png" alt="25 並列で Continuous Testing テストを実行するための並列化設定" style="width:100%;">}} ## 権限 diff --git a/content/ja/dashboards/configure/_index.md b/content/ja/dashboards/configure/_index.md index 28a98c74596bd..8f9b24f53d455 100644 --- a/content/ja/dashboards/configure/_index.md +++ b/content/ja/dashboards/configure/_index.md @@ -50,13 +50,13 @@ Markdown に対応するダッシュボードの説明を更新したり、[チ | キーボードショートカット | 使用可能なキーボードショートカットのリストを表示します。 | | UTC 時間を表示 | UTC 時間とデフォルトのタイムゾーンを切り替えます。 | | 密度を高める | 高密度モードでは、ウィジェットの密度を高めるために、ダッシュボードにグループウィジェットが並べて表示されます。このモードは、グループウィジェットを使用するダッシュボードの大画面でデフォルトでオンになります。 | -| TV モード | 切り替えることで、主要なパフォーマンスメトリクスを大画面やテレビに表示できます。 | +| TV モード | キー パフォーマンス メトリクスを大型スクリーンまたは TV で表示するには、トグルを使用します。詳細は [ダッシュボード用 TV モードの使用][5] を参照してください。 | ### 通知 ダッシュボードの変更通知を受信するには、通知追跡を有効にします。管理者権限に関係なく、これは組織内のどのユーザーでも有効にできます。 -ダッシュボードで通知が有効になると、[イベントエクスプローラー][5]でイベントが作成されます。このイベントでは、テキストの変更、ウィジェットの変更、ダッシュボードの複製、ダッシュボードの削除に関する情報が、アクションを実行したユーザーの名前とともに表示されます。以下の検索により、イベントエクスプローラーで特定のダッシュボードの変更イベントを表示します。 +ダッシュボードで通知が有効になると、[Events Explorer][6] にイベントが作成されます。このイベントには、テキストの変更、ウィジェットの変更、ダッシュボードのクローン作成、ダッシュボードの削除、および操作を実行したユーザーの名前に関する情報が含まれます。特定のダッシュボードの変更イベントを確認するには、Events Explorer で次の検索を行ってください: ```text tags:(audit AND dash) @@ -76,25 +76,25 @@ tags:(audit AND dash)
削除する前に、ダッシュボードのスターを解除する必要があります。
-ダッシュボードを完全に削除するには、このオプションを使用します。削除したダッシュボードを復元するには、プリセットの **Recently Deleted** リストを使用します。**Recently Deleted** にあるダッシュボードは、30 日後に完全に削除されます。詳細については、[ダッシュボードリスト][6]のドキュメントを参照してください。 +このオプションを使用して、ダッシュボードを完全に削除します。削除したダッシュボードを復元するには、プリセットの **Recently Deleted** リストを使用します。**Recently Deleted** にあるダッシュボードは 30 日後に完全に削除されます。詳細については、[ダッシュボード リスト][7] のドキュメントを参照してください。 ## 権限 -
View restrictions on individual dashboards are available to anyone on an Enterprise tier plan. Reach out to your account team or Datadog support to enable this feature.
+
View 制限は、有料プランをご利用の方であればリクエストに応じて個々のダッシュボードに対して利用できます。この機能を有効にするには、アカウント チームまたは Datadog サポート にお問い合わせください。
{{< img src="dashboards/access_popup.png" alt="ダッシュボードにアクセスするためのロールを選択するためのドロップダウンメニューを備えたダイアログボックス。" style="width:70%;">}} -きめ細かいアクセス制御を使用して、特定のダッシュボードを編集できる[ロール][7]を制限することができます。 +詳細なアクセス制御を使用して、特定のダッシュボードを編集できる [ロール][8] を制限します: 1. ダッシュボードを表示中に、右上の歯車 **Configure** をクリックします。 1. **Permissions** を選択します。 1. **Restrict Access** をクリックします。 1. ダイアログボックスが更新され、組織のメンバーはデフォルトで **Viewer** アクセス権を持っていることが表示されます。 -1. Use the dropdown to select one or more roles, teams, or users that may edit the dashboard. +1. ドロップ ダウンを使用して、ダッシュボードを編集できるロール、チーム、またはユーザーを 1 つ以上選択します。 1. **Add** をクリックします。 1. ダイアログボックスが更新され、選択したロールに **Editor** 権限があることが表示されます。 1. **Save** をクリックします。 -**注:** ダッシュボードの編集アクセス権を維持するために、保存する前に、少なくとも 1 つのロールのメンバーであることを含めることがシステムから要求されます。ロールの詳細については、[RBAC ドキュメント][7]を参照してください。 +**注:** ダッシュボードの編集権限を保持するために、保存する前に、自分が所属しているロールを少なくとも 1 つ含める必要があります。ロールの詳細については、[RBAC ドキュメント][8] を参照してください。 アクセスが制限されたダッシュボードのアクセス制限を解除するには、以下の手順に従ってください。 1. ダッシュボードを表示中に、右上の歯車 **Configure** をクリックします。 @@ -104,9 +104,9 @@ tags:(audit AND dash) ダッシュボードが非推奨の「読み取り専用」設定で作成された場合、アクセス制御リストにはアクセス管理 (`user_access_manage`) 権限を持つロールのリストが事前に入力されます。 -Terraform でダッシュボードを管理する場合、最新バージョンの Datadog Terraform プロバイダーを使用して、ダッシュボードを編集できるロールを制御することができます。詳細については、[Terraform ダッシュボードロール制限ガイド][8]を参照してください。 +Terraform でダッシュボードを管理している場合は、最新バージョンの Datadog Terraform プロバイダーを使用して、どのロールがダッシュボードを編集できるかを制御できます。詳細は、[Terraform ダッシュボード ロール制限ガイド][9] を参照してください。 -The access indicator appears at the top right of each edit-restricted dashboard. Depending on your permissions, it may say **Gain Edit Access** or **Request Edit Access**. Click the access indicator to understand your access permissions and what steps to take to edit the dashboard. +アクセス インジケーターは、編集が制限された各ダッシュボードの右上に表示されます。権限によって、**Gain Edit Access** または **Request Edit Access** と表示される場合があります。ダッシュボードを編集するためのアクセス権と手順を確認するには、アクセス インジケーターをクリックしてください。 ## その他の参考資料 @@ -117,7 +117,8 @@ The access indicator appears at the top right of each edit-restricted dashboard. [2]: /ja/dashboards/template_variables/ [3]: /ja/dashboards/guide/version_history/ [4]: /ja/account_management/audit_trail/ -[5]: /ja/events/ -[6]: /ja/dashboards/list -[7]: /ja/account_management/rbac/ -[8]: /ja/dashboards/guide/how-to-use-terraform-to-restrict-dashboard-edit/ \ No newline at end of file +[5]: /ja/dashboards/guide/tv_mode +[6]: /ja/events/ +[7]: /ja/dashboards/list +[8]: /ja/account_management/rbac/ +[9]: /ja/dashboards/guide/how-to-use-terraform-to-restrict-dashboard-edit/ \ No newline at end of file diff --git a/content/ja/dashboards/guide/tv_mode.md b/content/ja/dashboards/guide/tv_mode.md new file mode 100644 index 0000000000000..02a601a2c5b88 --- /dev/null +++ b/content/ja/dashboards/guide/tv_mode.md @@ -0,0 +1,36 @@ +--- +further_reading: +- link: /dashboards/configure/ + tag: ドキュメント + text: ダッシュボードの設定について学ぶ +title: ダッシュボードで TV モードを使用する +--- + +## 概要 + +TV モードは、スクロールを必要とせず、すべてのウィジェットが表示されるように大画面で Datadog ダッシュボードを表示するために設計されています。このガイドでは、TV モード用にダッシュボードを設定する手順を詳しく説明し、注意すべき制限事項を取り上げ、最適な表示のための解決策を提案します。 + +## TV モード用にダッシュボードを設定する + +TV に正しく表示されるようにするには、次の手順に従ってください。 +1. **ダッシュボードを設計する**: まず Datadog でダッシュボードを作成します。Datadog のダッシュボードが採用する 12 カラム グリッド レイアウト内でウィジェットを配置することに注力してください。ウィジェットおよびダッシュボード全体のアスペクト比が、TV モードでの表示に影響します。 +2. **TV モードを有効化する**: ダッシュボードの準備ができたら、TV モードを有効化します。画面を TV に接続し、フル スクリーン モードの状態で有効化してください。これにより、手動でサイズ変更を行わなくても、ダッシュボードが TV 画面に合わせて自動的に調整されます。 + {{< img src="/dashboards/guide/tv_mode/tv_mode_config_option.png" alt="Enable the TV mode option through the dashboard Configure menu" style="width:100%;" >}} +3. **表示設定を最適化する**: 画面の端までコンテンツが満たされない場合は、ブラウザーの表示倍率を変更して大きな画面を擬似的に再現できます。TV モードに再入する前に、キーボード ショートカットでブラウザー表示を調整します。`CMD/CTRL + +(plus)` でズーム イン、`CMD/CTRL + -(minus)` でズーム アウト。**注**: この方法には可読性の低下というトレードオフがあります。フォントが小さくなり、離れた場所から読みづらくなることがあります。 + +## TV モードの制限事項を理解する + +TV モードはダッシュボードを表示する便利な方法ですが、いくつかの制限や考慮事項があります。 +- **12 カラム グリッドの制約**: TV モードのダッシュボードは固定の 12 カラム グリッドに従います。これにより、画面全体の幅に合わせてコンテンツを引き延ばす柔軟性が制限される場合があります。高密度モードでは、ダッシュボードは 12 カラムのグリッド 2 つに分割され、ウィジェット数が増えるほど縦方向に拡張されます。 +- **アスペクト比の制約**: TV モードは、スクロールなしで画面内にすべてが収まるようにダッシュボードを縮小表示するため、実質的にアスペクト比が固定されます。ダッシュボードの高さと幅のバランスが悪い場合、端に余白が生じたり、ウィジェットが最小化されて表示されたりします(ズーム アウト)。これを抑えるには、TV の表示に近いアスペクト比でダッシュボードを設計してください。 +- **コンテンツの中央寄せ**: コンテンツが画面の端まで広がらず、中央に配置されることがあります。これは固定グリッド システムとアスペクト比に起因することがよくあります。画面の幅を最大限活用したい場合は、ウィジェットの位置をより細かく制御できるスクリーンボードへの切り替えを検討してください。 + +## 代替手段と推奨事項 + +12 カラム グリッドの制約により、TV モードで希望のレイアウトを実現しづらい場合は、次の代替案を検討してください。 +- **柔軟性を高めるスクリーンボード**: ダッシュボードと異なり、スクリーンボードはピクセル 単位の配置が可能で、TV のアスペクト比により適したレイアウトを作成できます。これにより、端の余白を解消し、画面領域を最大限活用できます。 +- **問題の追跡と報告**: コンテンツが正しく表示されないなど、TV モードに関する問題が継続する場合は、Datadog 内でバグとして報告してください。将来のアップデートでこれらの制限が対処される可能性があります。 + +## 参考資料 + +{{< partial name="whats-next/whats-next.html" >}} \ No newline at end of file diff --git a/content/ja/dashboards/guide/version_history.md b/content/ja/dashboards/guide/version_history.md index e7f4c09511377..4ff8a8f54adad 100644 --- a/content/ja/dashboards/guide/version_history.md +++ b/content/ja/dashboards/guide/version_history.md @@ -39,7 +39,7 @@ Version History サイドパネルから任意のバージョンをクリック ## バージョンの復元 ダッシュボードを以前のバージョンに復元するには、2 つの方法があります。 -{{< img src="/dashboards/guide/version_history/dashboard_version_history_options.png" alt="Version History side panel shows past dashboard versions and ways to restore them." style="width:100%;" >}} +{{< img src="/dashboards/guide/version_history/dashboard_version_history_options.png" alt="Version History サイド パネルには、過去のダッシュボード バージョンとそれらを復元する方法が表示されます。" style="width:100%;" >}} - Version History サイドパネルから復元するバージョンを決め、ユーザープロファイルの右側にあるケバブメニューをクリックし、**Restore this version** を選択します。 - Version History サイドパネルが開いた際に、ページ上部に **Restore this version** ボタンが表示されます。 diff --git a/content/ja/dashboards/sharing/_index.md b/content/ja/dashboards/sharing/_index.md new file mode 100644 index 0000000000000..435644e644e73 --- /dev/null +++ b/content/ja/dashboards/sharing/_index.md @@ -0,0 +1,39 @@ +--- +aliases: +- /ja/graphing/faq/is-there-a-way-to-share-graphs +- /ja/graphing/faq/is-there-a-way-to-share-or-revoke-previously-shared-graphs +- /ja/graphing/dashboards/shared_graph/ +further_reading: +- link: https://www.datadoghq.com/blog/dashboard-sharing/ + tag: ブログ + text: ダッシュボードを組織外の人と安全に共有する +- link: /dashboards/ + tag: ドキュメント + text: Datadog でダッシュボードを作成 +- link: /dashboards/widgets/ + tag: ドキュメント + text: ダッシュボードのウィジェットについて +title: 共有 +--- + +## 概要 + +共有ビジュアライゼーションを使用すると、Datadog 以外でもメトリクス、トレース、ログのビジュアライゼーションを表示できます。ビジュアライゼーションを共有して、チーム メンバーとの意思決定および問題解決プロセスを強化しましょう。 + +{{< whatsnext desc="ビジュアライゼーションを共有する方法:" >}} + {{< nextlink href="dashboards/sharing/shared_dashboards" >}}共有ダッシュボード: ユーザーがアクセスできるパブリック リンクを生成する{{< /nextlink >}} + {{< nextlink href="dashboards/sharing/graphs" >}}グラフの共有: 埋め込みコードを生成する{{< /nextlink >}} + {{< nextlink href="dashboards/sharing/scheduled_reports" >}}スケジュール済みレポート: メール レポートを送信するスケジュールを設定する{{< /nextlink >}} +{{< /whatsnext >}} + +## 公開ダッシュボードおよびグラフをすべて表示 + +公開共有されているダッシュボードの一覧を確認するには、[**Organization Settings > Public Sharing > Shared Dashboards**][1] に移動します。組織で公開共有されているグラフを確認するには、**Shared Graphs** タブをクリックします。アクセスを取り消す方法については、[ダッシュボード][2] および [グラフ][3] のドキュメントを参照してください。 + +## 参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://app.datadoghq.com/organization-settings/public-sharing/shared-dashboards +[2]: /ja/dashboards/sharing/shared_dashboards/ +[3]: /ja/dashboards/sharing/graphs/#revoke \ No newline at end of file diff --git a/content/ja/dashboards/widgets/geomap.md b/content/ja/dashboards/widgets/geomap.md index 827ee1b18c866..4be2b1e633c1e 100644 --- a/content/ja/dashboards/widgets/geomap.md +++ b/content/ja/dashboards/widgets/geomap.md @@ -22,11 +22,11 @@ widget_type: ジオマップ ## セットアップ -{{< img src="dashboards/widgets/geomap/geomap_setup2.png" alt="ウィジェット構成の Geomap Graph your data セクション">}} +{{< img src="dashboards/widgets/geomap/geomap_setup3.png" alt="ウィジェット構成の Geomap Graph your data セクション">}} ### 構成 1. 視覚化レイヤーを選択します。 - * **Regions**: 国レベルでメジャーを集計します。 + * **Regions**: 国レベルまたは国の下位区分レベルで集計した指標。 * **Points**: イベントをマップ上でポイントとしてオーバーレイし、地理的なイベントデータを表示します。 2. グラフ化するデータを選択します。
@@ -35,11 +35,11 @@ widget_type: ジオマップ {{% tab "Regions" %}} | データソース | 備考 | | -------------- | -------- | - |ログイベント | group by タグには、alpha-2 の ISO フォーマットに従った国の ISO コードを含める必要があります。これを行うには、[GeoIP Processor][1] を使用するか、手動で[取り込み時にタグ][2]を含めます。ログイベントクエリを構成するには、[ログ検索ドキュメント][3]を参照してください。| - |メトリクス | group by タグには、alpha-2 の ISO フォーマットに従った国の ISO コードを含める必要があります。[取り込んだログからメトリクスを生成する][4]か、手動で[取り込み時にタグ][2]を含めます。メトリクスクエリを構成するには、[クエリのドキュメント][5]を参照してください。| + |ログイベント | グループ化用タグには、国の ISO コード (alpha-2 の ISO フォーマット) または国の下位区分 ISO コード (ISO-3166-2 フォーマット) を含める必要があります。これを行うには、[GeoIP Processor][1] を使用するか、手動で[取り込み時にタグ][2]を含めます。ログイベントクエリを構成するには、[ログ検索ドキュメント][3]を参照してください。| + |メトリクス | グループ化用タグには、国の ISO コード (alpha-2 の ISO フォーマット) または国の下位区分 ISO コード (ISO-3166-2 フォーマット) を含める必要があります。[取り込んだログからメトリクスを生成する][4]か、手動で[取り込み時にタグ][2]を含めます。メトリクスクエリを構成するには、[クエリのドキュメント][5]を参照してください。| |RUM | RUM クエリを構成するには、[RUM ドキュメント][6]を参照してください。| |SLO | SLO クエリを構成するには、[SLO 検索ドキュメント][7]を参照してください。 | - |セキュリティシグナル
アプリケーションセキュリティ
監査証跡 | クエリを構成するには、[ログ検索ドキュメント][3]を参照してください。 | + |セキュリティシグナル
App and API Protection
監査証跡 | クエリを構成するには、[ログ検索ドキュメント][3]を参照してください。 | [1]: /logs/log_configuration/processors/#geoip-parser [2]: /getting_started/tagging/#define-tags @@ -71,6 +71,10 @@ widget_type: ジオマップ [コンテキストリンク][7]はデフォルトで有効になっていますが、有効/無効を切り替えることができます。コンテキストリンクは、ダッシュボードウィジェットと他のページ (Datadog 内またはサードパーティ) を接続します。 +#### ビジュアルフォーマットルール + +条件付きルールを使用して、Geomap ウィジェットのリージョンレイヤーの色をカスタマイズします。 + ## API このウィジェットは **[Dashboards API][8]** で使用できます。[ウィジェット JSON スキーマ定義][9]については、以下の表を参照してください。 diff --git a/content/ja/dashboards/widgets/list.md b/content/ja/dashboards/widgets/list.md index c50801d465089..2ec14b0f742cc 100644 --- a/content/ja/dashboards/widgets/list.md +++ b/content/ja/dashboards/widgets/list.md @@ -14,7 +14,7 @@ title: リストウィジェット widget_type: list_stream --- -The list widget displays a list of events and issues, which can come from a variety of sources such as Logs, RUM, or Events. Search and query across sources to narrow down the events you want the widget to highlight and display. +このリストウィジェットは、Logs、RUM、Events など、さまざまなソースから取得したイベントやインシデントを一覧表示します。ソースを検索およびクエリを実行して、ウィジェットでハイライト表示したいイベントを絞り込めます。 _エラー追跡問題を表示するリストウィジェット_ @@ -26,7 +26,7 @@ _エラー追跡問題を表示するリストウィジェット_ ### 構成 -1. Choose the type of data to graph. You can create a list widget from Issues, Logs, Audit Trail, Watchdog Alerts, or Events depending on which products are available for your organization. +1. グラフ化するデータの種類を選択してください。組織で利用可能な製品に応じて、Issues、Logs、Audit Trail、Watchdog Alerts、Events からリストウィジェットを作成できます。 2. ディスプレイの環境設定を行います。スクリーンボードとノートブックの場合にのみ、ウィジェットがカスタムタイムフレームを持つか、グローバルタイムフレームを使用するかを選択します。 @@ -87,14 +87,46 @@ RUM については、以下でソートすることができます。 #### ソート方法 -For incidents, you can sort by: +インシデントの場合、以下の項目でソートが可能です。 -* Created time +* 作成時間 * 重大度 * ステータス 昇順または降順 +### CD デプロイ + +#### ソート方法 + +CD デプロイの場合、以下の項目でソートが可能です。 + +* デプロイステータス +* サービス +* デプロイ名 +* 環境 +* Duration +* リビジョン値 +* Repository URL +* タイムスタンプ + +昇順または降順 + +### CI パイプライン + +#### ソート方法 + +CI パイプラインの場合、以下の項目でソートが可能です。 + +* CI Status +* Pipeline Name +* Duration +* Pipeline ID +* Branch +* タイムスタンプ + +昇順または降順 + ## API このウィジェットは **[Dashboards API][1]** で使用できます。[ウィジェット JSON スキーマ定義][2]については、以下の表を参照してください。 diff --git a/content/ja/dashboards/widgets/split_graph.md b/content/ja/dashboards/widgets/split_graph.md new file mode 100644 index 0000000000000..f557a786901e9 --- /dev/null +++ b/content/ja/dashboards/widgets/split_graph.md @@ -0,0 +1,83 @@ +--- +further_reading: +- link: /dashboards/guide/graphing_json/ + tag: ガイド + text: JSON を使用してダッシュボードを構築 +title: Split Graph ウィジェット +widget_type: split_group +--- + +
Split Graph ウィジェットはスクリーンボードおよび共有ダッシュボードではサポートされていません。
+ +## 概要 + +Split Graph を使用すると、クエリを複数のタグ値ごとに分割して外れ値やパターンを特定できます。この機能を使用して、複数のファセットにわたるメトリクス パフォーマンスを調査したり、複数のタグにわたるイベントを比較したり、動的なビジュアライゼーションを作成できます。 + +## セットアップ + +### Split Graph ウィジェットを作成 + +ウィジェット トレイのグループ セクションから Split Graph ウィジェットを選択し、ダッシュボードにドラッグすると、一から Split Graph を作成できます。これにより、クエリと分割ディメンションを同時に定義できます。設定オプションの詳細については、[設定](#configuration)セクションを参照してください。 + +### 既存のウィジェットから Split Graph を作成 + +既存のウィジェットをタグ値で分割し、**Split Graph** タブを使用して Split Graph を作成することもできます。**Split Graph** タブを開くには、次のいずれかを実行します。 +- ダッシュボードに新しいウィジェットを追加し、クエリ エディタ上部の **Split Graph** タブをクリックします。 +- ウィジェット コントロール オプションから編集または拡大アイコンを選択してウィジェットをフル スクリーン モードで開き、**Split Graph** タブをクリックします。 +- ダッシュボード上のウィジェットのコンテキスト メニューを開き、**Split Graph** を選択します。 + +**Split Graph** タブでは、グラフの分割方法、グラフ数の上限、並び順を設定できます。 +1. 分割ディメンション、表示するグラフ数、表示オプションを編集して Split を調整できます。設定オプションの詳細については、[設定](#configuration)セクションを参照してください。 +2. **Save to Dashboard** をクリックすると、新しい Split Graph ウィジェットがダッシュボードの一番下に作成されます。元のウィジェットはダッシュボード上で変更されません。 + +### Datadog の他の場所から Split Graph を作成 + +アプリ内で複数値にわたる Split が表示されている場合、その表示をウィジェットとしてダッシュボードにエクスポートできます。 +1. **Export to Dashboard** をクリックします。 +1. エクスポート モーダルが開き、既存のダッシュボードを検索してウィジェットをエクスポートするか、このウィジェットを含む新しいダッシュボードを作成できます。 + +## 設定 + +Split Graph を一から作成する場合やダッシュボード上の既存の Split Graph を編集する場合、グラフと Split の両方を設定できます。 + +Split Graph エディタは、[**Edit Graph**](#edit-graph) と [**Split Graph**](#edit-split) の 2 つのセクションで構成されています。ウィジェット タイトルを追加するには、エディタ上部のテキスト入力を更新します。 + +**注**: ウィジェットから Split Graph を作成した場合、**Split Graph** タブでは Split のみを設定できます。クエリを編集するには、いつでも **Edit** タブをクリックしてください。 + +{{< img src="dashboards/widgets/split_graph/split_graph_tab.png" alt="Split Graph タブに Split Graph の設定オプションが表示される" style="width:100%;" >}} + +### グラフを編集 + +分割する前にグラフ クエリを設定します。分割をサポートする任意の可視化タイプを選択し、グラフの表示方法を変更できます。標準のクエリ エディタと同様に、一からクエリを作成することも可能です。 + +これらの可視化タイプごとの詳細な設定オプションについては、[ウィジェット][1]ページの各ウィジェット ドキュメントを参照してください。 + +変更内容は、Split Graph エディタ モーダルの下部にある分割グラフに即座に反映されます。 + +{{< img src="dashboards/widgets/split_graph/split_graph_editor.png" alt="Split Graph エディタにグラフ クエリの設定と Split Graph の設定オプションが表示される" style="width:100%;" >}} + +### グラフを分割 + +グラフの分割方法や、分割特有の表示オプションを設定するための入力項目が複数あります。 + +| 設定項目 | 説明 | +| --- | ----------- | +| One graph per | 元のグラフを分割するディメンションを定義するドロップダウンです。 | +| Limit to | 表示するグラフ数と選択する値を指定するオプションです。デフォルトでは、Split Graph ウィジェットが平均値の高い値を動的に選択します。 | +| Sort by | グラフを並び替えるメトリクスまたは属性/ファセットを選択します。**custom** を選択すると、表示するタグを手動で選択できます。 | +| Show Controls | 利用可能なタグ値をすべて表示するサイドバーの表示/非表示を切り替えます。タグ値を手動で選択すると、分割が動的から静的に変わり、選択した値のみが表示されます。動的動作に戻すには、選択をクリアするか **Custom** ボタンをクリックして **Top** または **Bottom** を選択し、並び替えを再有効化します。 | +| Graph Setting | Split Graph 特有の表示オプションです
`Graph Size`: Split Graph ウィジェット内の個々のグラフ サイズを 4 種類から選択できます。
`Uniform Y-Axes`: ウィジェット内のグラフが同一の y 軸を使用するか、可読性を最大化するために個別に調整するかを選択します。 | + +## API + +このウィジェットは [Dashboards API][2] で使用できます。以下の表で[ウィジェット JSON スキーマ定義][3]を参照してください。 + +{{< dashboards-widgets-api >}} + +## その他の参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ja/dashboards/widgets/ +[2]: /ja/api/latest/dashboards/ +[3]: /ja/dashboards/graphing_json/widget_json/ \ No newline at end of file diff --git a/content/ja/data_security/guide/tls_ciphers_deprecation.md b/content/ja/data_security/guide/tls_ciphers_deprecation.md new file mode 100644 index 0000000000000..abc755aef87b3 --- /dev/null +++ b/content/ja/data_security/guide/tls_ciphers_deprecation.md @@ -0,0 +1,62 @@ +# 概要 + +**Transport Layer Security (TLS)** は、Web トラフィックを保護するために使用される重要なセキュリティプロトコルです。TLS は、クライアントとサーバー間で情報をやり取りする際に、データの機密性と完全性を提供します。TLS セッションの確立中に、両当事者は通信を保護するために使用される暗号アルゴリズムを定める暗号スイートについて合意します。 + +Datadog は、顧客データのセキュリティと保護に対する継続的なコミットメントの一環として、システム全体により最新の暗号化エンジンを展開しており、それにより受け入れ可能な構成にいくつかの変更が生じます。 + +**2024 年 4 月 1 日**以降、Datadog の外部公開向けアプリケーションでは、以下の暗号スイートのサポートが無効化されました。これらの旧プロトコルが無効化された後に非対応クライアントで Datadog に接続すると、接続エラーが表示されます。 + +## 無効な暗号スイート + +| コード | IANA 名 | +|------------|------------------------------------------| +| 0xC0,0x27 | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 | +| 0xC0,0x23 | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 | +| 0xC0,0x28 | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 | +| 0xC0,0x24 | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 | +| 0x00,0x3C | TLS_RSA_WITH_AES_128_CBC_SHA256 | +| 0x00,0x3D | TLS_RSA_WITH_AES_256_CBC_SHA256 | + +この日以降、以下の暗号スイートが使用可能になります。 + +## 使用可能な暗号スイート + +| コード | IANA 名 | +|------------|-------------------------------------------------| +| 0xC0,0x2B | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | +| 0xC0,0x2F | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | +| 0xC0,0x2C | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | +| 0xC0,0x30 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | +| 0xCC,0xA9 | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 | +| 0xCC,0xA8 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | +| 0xC0,0x09 | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA | +| 0xC0,0x13 | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA | +| 0xC0,0x0A | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA | +| 0xC0,0x14 | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA | +| 0x00,0x9C | TLS_RSA_WITH_AES_128_GCM_SHA256 | +| 0x00,0x9D | TLS_RSA_WITH_AES_256_GCM_SHA384 | +| 0x00,0x2F | TLS_RSA_WITH_AES_128_CBC_SHA | +| 0x00,0x35 | TLS_RSA_WITH_AES_256_CBC_SHA | +| 0x13,0x01 | TLS_AES_128_GCM_SHA256 | +| 0x13,0x02 | TLS_AES_256_GCM_SHA384 | +| 0x13,0x03 | TLS_CHACHA20_POLY1305_SHA256 | + +この変更は、Datadog for Government サイトには影響を与えず、当該サイトでは以下の暗号スイートが引き続き受け入れられます。 + +## 使用可能な暗号スイート (Datadog for Government) + +| コード | IANA 名 | +|------------|------------------------------------------| +| 0xC0,0x2F | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | +| 0xC0,0x30 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | +| 0xC0,0x2B | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | +| 0xC0,0x2C | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | + +# クライアントとの互換性 + +Datadog のシステムでは、すでに **TLS 1.2** の使用が義務付けられており、互換性のあるクライアントは他の暗号スイートをネゴシエートすることができます。ただし、クライアント側の特定の構成によって、この動作が変更される場合があります。対象の暗号で構成されている [tls-config-test.datadoghq.com][3] に接続するためにお好みのクライアントを使用するか、[How's my SSL? API][1] を使用してサポートする暗号スイートを確認してください。その他ご不明な点がございましたら、[Datadog サポート][2]までお問い合わせください。 + + +[1]: https://www.howsmyssl.com/s/api.html +[2]: /ja/help +[3]: https://tls-config-test.datadoghq.com \ No newline at end of file diff --git a/content/ja/database_monitoring/_index.md b/content/ja/database_monitoring/_index.md index 2b04cd4a7d672..7ebd47dc09d0f 100644 --- a/content/ja/database_monitoring/_index.md +++ b/content/ja/database_monitoring/_index.md @@ -8,6 +8,9 @@ cascade: rank: 70 description: Database Monitoring について学び、始めましょう further_reading: +- link: https://www.datadoghq.com/blog/database-monitoring-recommendations/ + tag: ブログ + text: Database Monitoring 推奨事項でデータベース ホストとクエリ パフォーマンスを改善する - link: https://www.datadoghq.com/blog/database-performance-monitoring-datadog tag: ブログ text: データベースのパフォーマンスを監視、視覚化する diff --git a/content/ja/database_monitoring/setup_documentdb/amazon_documentdb.md b/content/ja/database_monitoring/setup_documentdb/amazon_documentdb.md new file mode 100644 index 0000000000000..e416c779a1e40 --- /dev/null +++ b/content/ja/database_monitoring/setup_documentdb/amazon_documentdb.md @@ -0,0 +1,136 @@ +--- +title: Amazon DocumentDB 用 Database Monitoring のセットアップ +--- + +Database Monitoring は、重要なメトリクス、オペレーション サンプル、実行計画、レプリケーション 状態の変更へのアクセスを提供することで、MongoDB 互換の Amazon DocumentDB データベースに対する包括的なインサイトを提供します。Amazon DocumentDB で Database Monitoring を利用するには、Datadog Agent がインストールされ、Amazon DocumentDB インスタンスに接続するように構成されていることを確認してください。このガイドでは、Amazon DocumentDB 用 Database Monitoring をセットアップする手順を説明します。 + +## 開始する前に + +サポートされている Amazon DocumentDB メジャー バージョン +: 4.0.0, 5.0.0 + +サポートされている Amazon DocumentDB クラスター タイプ +: インスタンス ベース クラスター。

+**注**: Amazon DocumentDB Elastic クラスターには対応していません。 + +{{% dbm-documentdb-before-you-begin %}} + +## セットアップ + +データベースで Database Monitoring を有効にするには、次の手順を実行します: + +1. [Datadog Agent に Amazon DocumentDB インスタンスへのアクセスを許可する](#grant-the-agent-access-to-your-amazon-documentdb-instances) +2. [Agent をインストールして構成する](#install-and-configure-the-agent) +3. [(任意) Amazon DocumentDB インテグレーションをインストールする](#install-the-amazon-documentdb-integration) + +### Datadog Agent に Amazon DocumentDB インスタンスへのアクセスを許可する + +Datadog Agent が統計情報とクエリを収集するためには、Amazon DocumentDB インスタンスへの読み取り専用アクセスが必要です。 + +Mongo シェルでレプリカ セットのプライマリ ノードに認証し、`admin` データベースで Datadog Agent 用の読み取り専用ユーザーを作成して、必要な権限を付与します: + +{{< code-block lang="shell" >}} + +# admin ユーザーとして認証します。 + +use admin +db.auth("admin", "") + +# Datadog Agent 用のユーザーを作成します。 + +db.createUser({ +"user": "datadog", +"pwd": "", +"roles": [ +{ role: "read", db: "admin" }, +{ role: "read", db: "local" }, +{ role: "clusterMonitor", db: "admin" } +] +}) +{{< /code-block >}} + +監視対象データベースで `datadog` ユーザーに追加の権限を付与します: + +{{< code-block lang="shell" >}} +db.grantRolesToUser("datadog", [ +{ role: "read", db: "mydatabase" }, +{ role: "read", db: "myotherdatabase" } +]) +{{< /code-block >}} + +代わりに、すべてのデータベースを監視するために、`admin` データベースで `datadog` ユーザーに `readAnyDatabase` ロールを付与することもできます: + +{{< code-block lang="shell" >}} +db.grantRolesToUser("datadog", [ +{ role: "readAnyDatabase", db: "admin" } +]) +{{< /code-block >}} + +### パスワードを安全に保管 + +{{% dbm-secret %}} + +### Agent をインストールして構成する + +Amazon DocumentDB クラスターを監視するには、[リモート アクセス][1] が可能なホストに Datadog Agent をインストールして構成する必要があります。このホストは Linux ホスト、Docker コンテナ、または Kubernetes ポッドのいずれでもかまいません。 + +#### 構成ファイルを作成する + +{{% dbm-amazon-documentdb-agent-config-replica-set %}} + +インスタンスに Amazon DocumentDB インテグレーション テレメトリを追加するために [Amazon DocumentDB インテグレーション][3] をインストールした場合は、このセクションを構成に追加してください: + +```yaml +## @param aws - mapping - optional +## このブロックは Amazon DocumentDB インスタンスの構成を定義します。 +## これらの値は `dbm: true` オプションが設定されている場合のみ適用されます。 +# +aws: + ## @param instance_endpoint - string - optional + ## Agent が接続するインスタンスの Endpoint.Address と同じ値です。 + ## `host` にインスタンス エンドポイントがすでに設定されている場合は省略可能です。 + ## + ## インスタンス エンドポイントの詳細については、 + ## AWS ドキュメント https://docs.aws.amazon.com/documentdb/latest/developerguide/API_Endpoint.html を参照してください + # + instance_endpoint: + ## @param cluster_identifier - string - optional + ## Agent が接続するインスタンスのクラスター識別子と同じ値です。 + ## `cluster_name` にクラスター識別子がすでに設定されている場合は省略可能です。 + ## + ## クラスター識別子の詳細については、 + ## AWS ドキュメント https://docs.aws.amazon.com/documentdb/latest/developerguide/API_DBCluster.html を参照してください + # + cluster_identifier: +``` + +#### Agent をセットアップする + +{{< tabs >}} +{{% tab "Linux Host" %}} +{{% dbm-mongodb-agent-setup-linux %}} +{{% /tab %}} +{{% tab "Docker" %}} +{{% dbm-mongodb-agent-setup-docker %}} +{{% /tab %}} +{{% tab "Kubernetes" %}} +{{% dbm-mongodb-agent-setup-kubernetes %}} +{{% /tab %}} +{{< /tabs >}} + +### Amazon DocumentDB インテグレーションをインストールする + +Amazon DocumentDB からより包括的なデータベース メトリクスを収集するには、[Amazon DocumentDB インテグレーション][3] をインストールしてください (任意)。 + +## 収集されるデータ + +### メトリクス + +インテグレーションで収集されるメトリクスの詳細な一覧については、[インテグレーション ドキュメント][2] を参照してください。 + +{{% dbm-amazon-documentdb-agent-data-collected %}} + +[1]: /ja/account_management/api-app-keys/ +[2]: /ja/integrations/mongo/?tab=replicaset#metrics +[3]: /ja/integrations/amazon_documentdb/ +[4]: /ja/integrations/amazon_documentdb/#metrics \ No newline at end of file diff --git a/content/ja/database_monitoring/setup_mongodb/selfhosted.md b/content/ja/database_monitoring/setup_mongodb/selfhosted.md new file mode 100644 index 0000000000000..959df6fcb19f4 --- /dev/null +++ b/content/ja/database_monitoring/setup_mongodb/selfhosted.md @@ -0,0 +1,199 @@ +--- +further_reading: +- link: /integrations/mongo/ + tag: ドキュメント + text: 基本的な MongoDB インテグレーション +title: セルフホスト型 MongoDB 向け Database Monitoring のセットアップ +--- + +Database Monitoring は、重要なメトリクス、低速な操作、操作のサンプル、実行計画、レプリケーション 状態の変更へのアクセスを提供し、MongoDB データベースに対する包括的なインサイトを提供します。MongoDB で Database Monitoring を活用するには、Datadog Agent がインストールされ、MongoDB インスタンスに接続するよう構成されていることを確認してください。本ガイドでは、セルフホスト型 MongoDB 用に Database Monitoring をセットアップする手順を説明します。 + +## 開始前に + +サポートされている MongoDB メジャー バージョン +: 4.4, 5.0, 6.0, 7.0, 8.0 + +サポート対象の MongoDB エディション +: Community, Enterprise + +{{% dbm-mongodb-before-you-begin %}} + +## セットアップ + +データベースで Database Monitoring を有効にするには: + +1. [Agent に MongoDB インスタンスへのアクセス権を付与する](#grant-the-agent-access-to-your-mongodb-instances) +2. [Agent をインストールして構成する](#install-and-configure-the-agent) + +### Agent に MongoDB インスタンスへのアクセス権を付与する + +Datadog Agent が統計情報やクエリを収集するには、MongoDB インスタンスへの読み取り専用アクセスが必要です。 + +{{< tabs >}} +{{% tab "Standalone" %}} + +Mongo シェルで、MongoDB インスタンスに接続して認証し、`admin` データベースに Datadog Agent 用の読み取り専用ユーザーを作成し、必要な権限を付与します: + +{{< code-block lang="shell" >}} +# admin ユーザーとして認証します。 +use admin +db.auth("admin", "") + +# Datadog Agent 用のユーザーを作成します。 +db.createUser({ + "user": "datadog", + "pwd": "", + "roles": [ + { role: "read", db: "admin" }, + { role: "read", db: "local" }, + { role: "clusterMonitor", db: "admin" } + ] +}) +{{< /code-block >}} + +監視したいデータベースで、`datadog` ユーザーに追加の権限を付与します: + +{{< code-block lang="shell" >}} +db.grantRolesToUser("datadog", [ + { role: "read", db: "mydatabase" }, + { role: "read", db: "myotherdatabase" } +]) +{{< /code-block >}} + +すべてのデータベースを監視するには、代わりに `admin` データベースで `datadog` ユーザーに `readAnyDatabase` ロールを付与することもできます: + +{{< code-block lang="shell" >}} +db.grantRolesToUser("datadog", [ + { role: "readAnyDatabase", db: "admin" } +]) +{{< /code-block >}} + +{{% /tab %}} +{{% tab "Replica Set" %}} + +Mongo シェルで、レプリカ セットのプライマリ ノードに接続して認証し、`admin` データベースに Datadog Agent 用の読み取り専用ユーザーを作成し、必要な権限を付与します: + +{{< code-block lang="shell" >}} +# admin ユーザーとして認証します。 +use admin +db.auth("admin", "") + +# Datadog Agent 用のユーザーを作成します。 +db.createUser({ + "user": "datadog", + "pwd": "", + "roles": [ + { role: "read", db: "admin" }, + { role: "read", db: "local" }, + { role: "clusterMonitor", db: "admin" } + ] +}) +{{< /code-block >}} + +監視したいデータベースで、`datadog` ユーザーに追加の権限を付与します: + +{{< code-block lang="shell" >}} +db.grantRolesToUser("datadog", [ + { role: "read", db: "mydatabase" }, + { role: "read", db: "myotherdatabase" } +]) +{{< /code-block >}} + +すべてのデータベースを監視するには、代わりに `admin` データベースで `datadog` ユーザーに `readAnyDatabase` ロールを付与することもできます: + +{{< code-block lang="shell" >}} +db.grantRolesToUser("datadog", [ + { role: "readAnyDatabase", db: "admin" } +]) +{{< /code-block >}} + +{{% /tab %}} +{{% tab "Sharded Cluster" %}} + +1. クラスター内の各シャードについて、該当シャードのプライマリ ノードに接続し、`admin` データベースに Datadog Agent 用の読み取り専用ユーザーを作成して、必要な権限を付与します: + +{{< code-block lang="shell" >}} +# admin ユーザーとして認証します。 +use admin +db.auth("admin", "") + +# Datadog Agent 用のユーザーを作成します。 +db.createUser({ + "user": "datadog", + "pwd": "", + "roles": [ + { role: "read", db: "admin" }, + { role: "read", db: "local" }, + { role: "clusterMonitor", db: "admin" } + ] +}) +{{< /code-block >}} + +監視したいデータベースで、`datadog` ユーザーに追加の権限を付与します: + +{{< code-block lang="shell" >}} +db.grantRolesToUser("datadog", [ + { role: "read", db: "mydatabase" }, + { role: "read", db: "myotherdatabase" } +]) +{{< /code-block >}} + +すべてのデータベースを監視するには、代わりに `admin` データベースで `datadog` ユーザーに `readAnyDatabase` ロールを付与することもできます: + +{{< code-block lang="shell" >}} +db.grantRolesToUser("datadog", [ + { role: "readAnyDatabase", db: "admin" } +]) +{{< /code-block >}} + +2. 同じ手順を `mongos` プロキシからも実施し、同じユーザーを作成してください。これにより、コンフィグ サーバーにローカル ユーザーが作成され、直接接続が可能になります。 + +{{% /tab %}} +{{< /tabs >}} + +### パスワードを安全に保管する +{{% dbm-secret %}} + +### Agent をインストールして構成する + +Datadog は Agent を MongoDB ホストに直接インストールすることを推奨します。これにより、MongoDB 固有のテレメトリに加えて、システム テレメトリ (CPU、メモリ、ディスク、ネットワーク) も収集できます。 + +#### 構成ファイルを作成する + +{{< tabs >}} +{{% tab "Standalone" %}} +{{% dbm-mongodb-agent-config-standalone %}} +{{% /tab %}} +{{% tab "Replica Set" %}} +{{% dbm-mongodb-agent-config-replica-set %}} +{{% /tab %}} +{{% tab "Sharded Cluster" %}} +{{% dbm-mongodb-agent-config-sharded-cluster %}} +{{% /tab %}} +{{< /tabs >}} + +#### Agent をセットアップする + +{{< tabs >}} +{{% tab "Linux Host" %}} +{{% dbm-mongodb-agent-setup-linux %}} +{{% /tab %}} +{{% tab "Docker" %}} +{{% dbm-mongodb-agent-setup-docker %}} +{{% /tab %}} +{{% tab "Kubernetes" %}} +{{% dbm-mongodb-agent-setup-kubernetes %}} +{{% /tab %}} +{{< /tabs >}} + + +## 収集データ + +### メトリクス + +MongoDB インテグレーションで収集されるメトリクスの包括的な一覧については、[MongoDB インテグレーション ドキュメント][2] を参照してください。 + +{{% dbm-mongodb-agent-data-collected %}} + +[1]: /ja/account_management/api-app-keys/ +[2]: /ja/integrations/mongo/?tab=standalone#metrics \ No newline at end of file diff --git a/content/ja/database_monitoring/setup_oracle/_index.md b/content/ja/database_monitoring/setup_oracle/_index.md index 5ec4ec721bfd8..62fbe62bce00a 100644 --- a/content/ja/database_monitoring/setup_oracle/_index.md +++ b/content/ja/database_monitoring/setup_oracle/_index.md @@ -4,7 +4,7 @@ disable_sidebar: true title: Oracle の設定 --- -## Supported Oracle versions +## サポートされている Oracle バージョン | | Self-Hosted | RDS | RAC | エクサデータ | 自律型データベース | Automatic Storage Management | |------------|-------------|-----------|-----------|-----------|---------------------|------------------------------| @@ -14,12 +14,12 @@ title: Oracle の設定 | Oracle 19c | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | Oracle 21c | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | -## Supported architectures -- Multi-tenant (CDB/PDB) +## サポートされているアーキテクチャ +- マルチテナント (CDB/PDB) - Non-CDB ## セットアップ -For setup instructions, select your hosting type: +セットアップ手順については、ホスティングタイプを選択してください: {{< partial name="dbm/dbm-setup-oracle" >}} [1]: https://app.datadoghq.com/integrations diff --git a/content/ja/developers/authorization/_index.md b/content/ja/developers/authorization/_index.md index ca2d4b767c797..7fc2857e8eb55 100644 --- a/content/ja/developers/authorization/_index.md +++ b/content/ja/developers/authorization/_index.md @@ -24,9 +24,9 @@ Datadog は、[OAuth 2.0 (OAuth2) Authorization Framework][1] を使用し、ユ OAuth2 クライアントは、ユーザーに代わって Datadog リソースへのアプリケーションのアクセスを承認できるようにするアプリケーションのコンポーネントです。OAuth2 は、パブリックと[機密][3]の 2 種類のクライアントを定義しています。 -Public Clients -: Typically used for browser-based applications and are not capable of storing confidential information. - +パブリッククライアント +: 通常、ブラウザベースのアプリケーションで使用され、機密情報を保存できません。 + 機密クライアント : 機密データを保存することができ、認可リクエストを行うために追加の `client_secret` を必要とします。インテグレーション用の OAuth クライアントは機密クライアントです。 diff --git a/content/ja/error_tracking/frontend/collecting_browser_errors.md b/content/ja/error_tracking/frontend/collecting_browser_errors.md new file mode 100644 index 0000000000000..a733fcd8c02a4 --- /dev/null +++ b/content/ja/error_tracking/frontend/collecting_browser_errors.md @@ -0,0 +1,5 @@ +--- +title: ブラウザエラーの収集 +--- + +{{< include-markdown "real_user_monitoring/browser/collecting_browser_errors" >}} \ No newline at end of file diff --git a/content/ja/getting_started/incident_management/_index.md b/content/ja/getting_started/incident_management/_index.md index d28a0ff9ff318..1a72c9adf340a 100644 --- a/content/ja/getting_started/incident_management/_index.md +++ b/content/ja/getting_started/incident_management/_index.md @@ -4,13 +4,13 @@ further_reading: tag: ラーニングセンター text: Incident Management の紹介 - link: /service_management/incident_management/datadog_clipboard - tag: Documentation + tag: ドキュメント text: Datadog クリップボード - link: https://www.youtube.com/watch?v=QIambwILy_M tag: ビデオ text: Datadog Incident Management について - link: /monitors/incident_management - tag: Documentation + tag: ドキュメント text: インシデント管理 - link: https://dtdg.co/fe tag: Foundation Enablement @@ -19,10 +19,10 @@ further_reading: tag: ブログ text: Datadog でのインシデント管理 - link: /service_management/incident_management/incident_settings - tag: Documentation + tag: ドキュメント text: 通知ルール - link: /integrations/slack/?tab=slackapplicationus#using-datadog-incidents - tag: Documentation + tag: ドキュメント text: インシデントと Slack のインテグレーション - link: https://www.datadoghq.com/blog/pair-programming-coscreen-datadog/ tag: ブログ @@ -104,7 +104,7 @@ _Overview_ セクションで、調査が進むにつれてインシデントの 3. descriptions フィールドに値を追加します: `TEST: Some customers seeing pages loading slowly.`　 4. **Save** をクリックしてフィールドを更新します。_Impact_ セクションが更新され、顧客への影響がどのくらい継続しているかが表示されます。_Overview_ ページで行われたすべての変更が _Timeline_ に追加されます。 -#### 沿革 +#### タイムライン _Timeline_ には、インシデントのフィールドや情報の追加・変更が時系列で表示されます。 @@ -166,7 +166,7 @@ _Notifications_ セクションで、インシデントのステータス更新 8. タイムラインセクションで **Marked as Important** (重要としてマーク) を選択すると、_重要な_イベントのみが事後分析に追加されます。 9. **Generate** をクリックします。 -事後分析は Datadog ノートブックとして生成され、調査と修復の際に参照されたタイムラインイベントとリソースが含まれます。これにより、問題の原因や今後の予防方法を簡単に確認し、さらに文書化することができます。Datadog ノートブックはライブコラボレーションをサポートしているため、リアルタイムでチームメンバーと共同編集を行うことができます。 +ポストモーテムは Datadog Notebook または Confluence ページとして生成され、調査および修復の過程で参照されたタイムライン イベントやリソースが含まれます。これにより、問題の原因と将来の再発防止策を確認・文書化しやすくなります。 問題の再発を防ぐためにあなたおよびチームが完了しなければならないフォローアップタスクがある場合は、それらを追加して、Remediation の _Incident Tasks_ セクションで追跡します。 @@ -185,7 +185,7 @@ Incident Management をカスタマイズするには、[インシデント設 また、インシデントの宣言と編集、Slack や Zoom などとのインテグレーションにより、チームへの迅速なコミュニケーションも可能です。 -{{< img src="service_management/incidents/incidents-list-mobile.png" style="width:100%; background:none; border:none; box-shadow:none;" alt="モバイルアプリでのモニター">}} +{{< img src="service_management/mobile/iOS_Incident_V2.png" style="width:100%; background:none; border:none; box-shadow:none;" alt="Datadog モバイル アプリの 2 つのビュー: 1 つは各インシデントの概要を示すインシデント リスト、もう 1 つは単一インシデントの詳細パネル" >}} ## その他の参考資料 diff --git a/content/ja/getting_started/integrations/aws.md b/content/ja/getting_started/integrations/aws.md index 80be0b787ee5f..52519da621cf1 100644 --- a/content/ja/getting_started/integrations/aws.md +++ b/content/ja/getting_started/integrations/aws.md @@ -36,7 +36,7 @@ title: AWS の概要 簡単に言うと、これには Datadog の AWS アカウントがデータの収集やプッシュのために AWS アカウントに API コールを行うことを可能にする IAM ロールと関連するポリシーの作成が含まれます。また、このテンプレートは、Datadog にログを送信するための [Datadog Forwarder][1] Lambda 関数をデプロイします。CloudFormation テンプレートを使用することで、このデータを Datadog アカウントに送信するために必要なすべてのツールが提供されます。Datadog は、最新の機能を提供するために CloudFormation テンプレートを保守しています。 -最初の接続が確立された後、AWS 環境に関連する個々の AWS サービスインテグレーションを有効にすることができます。ワンクリックで、Datadog は AWS アカウントに必要なリソースをプロビジョニングし、使用するサービスのメトリクスとイベントのクエリを開始します。人気のある AWS サービスをご使用の場合、Datadog はすぐに使えるダッシュボードを用意しています。これは即座に視覚化を提供し、カスタマイズも可能です。このガイドでは、インテグレーションの設定と Amazon Linux EC2 インスタンスへの Datadog Agent のインストールをデモし、インテグレーションの機能の概要を説明します。利用可能なサブインテグレーションについては、[個々の AWS サービスに対するインテグレーションを有効にする](#enable-integrations-for-individual-aws-service)セクションを参照してください。 +最初の接続が確立された後、AWS 環境に関連する個々の AWS サービスインテグレーションを有効にすることができます。ワンクリックで、Datadog は AWS アカウントに必要なリソースをプロビジョニングし、使用するサービスのメトリクスとイベントのクエリを開始します。人気のある AWS サービスをご使用の場合、Datadog はすぐに使えるダッシュボードを用意しています。これは即座に視覚化を提供し、カスタマイズも可能です。このガイドでは、インテグレーションの設定と Amazon Linux EC2 インスタンスへの Datadog Agent のインストールをデモし、インテグレーションの機能の概要を説明します。利用可能なサブインテグレーションについては、[個々の AWS サービスに対するインテグレーションを有効にする](#enable-integrations-for-individual-aws-services)セクションを参照してください。 このプロセスは必要な数の AWS アカウントに対して繰り返すことができますし、[API][3]、[AWS CLI][4]、[Terraform][5] を使って一度に複数のアカウントを設定することも可能です。詳しくは、[Datadog-Amazon CloudFormation ガイド][6]をご参照ください。 @@ -116,20 +116,28 @@ title: AWS の概要 c. オプションで、[Datadog Forwarder Lambda][1] でログなどを Datadog に送ります。 d. 必要に応じて、[Cloud Security Misconfigurations][54] を有効にして、クラウド環境、ホスト、コンテナをスキャンして、誤構成やセキュリティリスクを検出します。 -5. **Launch CloudFormation Template** をクリックします。これで AWS コンソールが開き、CloudFormation スタックがロードされます。すべてのパラメーターは、事前の Datadog フォームでの選択に基づいて入力されているため、必要な場合以外は編集する必要はありません。 +4. **Launch CloudFormation Template** をクリックします。これで AWS コンソールが開き、CloudFormation スタックがロードされます。すべてのパラメーターは、事前の Datadog フォームでの選択に基づいて入力されているため、必要な場合以外は編集する必要はありません。 **注:** `DatadogAppKey` パラメーターは、CloudFormation スタックが Datadog に API コールを行い、この AWS アカウントに対して Datadog の構成を追加・編集できるようにするものです。キーは自動的に生成され、Datadog アカウントに結びつけられます。 -6. AWS から必要な項目にチェックを入れ、**Create stack** をクリックします。これにより、Datadog スタックと 3 つのネストされたスタックの作成プロセスが開始されます。これには数分かかる場合があります。続行する前に、スタックが正常に作成されたことを確認します。 +5. AWS から必要な項目にチェックを入れ、**Create stack** をクリックします。これにより、Datadog スタックと 3 つのネストされたスタックの作成プロセスが開始されます。これには数分かかる場合があります。続行する前に、スタックが正常に作成されたことを確認します。 -7. スタック作成後、Datadog の AWS インテグレーションタイルに戻り、**Ready!** をクリックします。 +6. スタック作成後、Datadog の AWS インテグレーションタイルに戻り、**Ready!** をクリックします。 -8. データ収集が開始されるまで最大 10 分待ち、すぐに使える [AWS 概要ダッシュボード][12]を表示し、AWS サービスやインフラストラクチャーから送信されるメトリクスを確認します。 +7. データ収集が開始されるまで最大 10 分待ち、すぐに使える [AWS 概要ダッシュボード][12]を表示し、AWS サービスやインフラストラクチャーから送信されるメトリクスを確認します。 {{< img src="getting_started/integrations/aws-dashboard.png" alt="Datadog アカウントの AWS 概要ダッシュボード。左側には AWS のロゴと、'No matching entries found' (該当するエントリーはありません) を示す AWS イベントグラフが表示されます。中央には、数値データが表示された EBS ボリューム関連のグラフと、一貫したデータを示すヒートマップが表示されています。右側には、数値データが表示された ELB 関連のグラフと、3 つのソースからのスパイク状のデータを示す時系列グラフが表示されています。">}} -## 個々の AWS サービスに対するインテグレーションを有効にする +## 設定 + +### 個々の AWS サービスに対するインテグレーションを有効にする 利用可能なサブインテグレーションの全リストは、[Integrations ページ][13]をご覧ください。これらのインテグレーションの多くは、Datadog が AWS アカウントから入ってくるデータを認識する際に、デフォルトでインストールされます。 +Datadog インテグレーションがどのサービスからメトリクスを収集するかを設定するには、[AWS 統合ページ][8] の **Metric Collection** タブを使用します。 + +### リージョンを追加 + +Datadog がメトリクス、CloudWatch イベント、リソースを収集する AWS リージョンは、[AWS 統合ページ][8] の **General** タブで管理できます。 + ## ログを送信 AWSサービスログを Datadog に送信する方法はいくつかあります。 @@ -204,7 +212,7 @@ Datadog の UI や [API][33] を利用するほか、[CloudFormation Registry][3 ### セキュリティ -#### Cloud SIEM +#### クラウド SIEM [Cloud SIEM の概要][50]を参照して、すぐに使える[ログ検出ルール][51]に照らし合わせてログを評価します。これらのルールはカスタマイズ可能で、脅威が検出されると[セキュリティシグナルエクスプローラー][52]でアクセス可能なセキュリティシグナルが生成されます。適切なチームに通知するために、[通知ルール][53]を使用して複数のルールにまたがる通知設定を構成することができます。 @@ -216,7 +224,7 @@ Datadog の UI や [API][33] を利用するほか、[CloudFormation Registry][3 `Datadog is not authorized to perform sts:AssumeRole` というエラーが発生した場合は、専用の[トラブルシューティングページ][2]を参照してください。その他の問題については、[AWS インテグレーショントラブルシューティングガイド][57]を参照してください。 -## その他の参考資料 +## 参考情報 {{< partial name="whats-next/whats-next.html" >}} diff --git a/content/ja/glossary/terms/custom_span.md b/content/ja/glossary/terms/custom_span.md index 9d59b0732f839..8e2d5be72c524 100644 --- a/content/ja/glossary/terms/custom_span.md +++ b/content/ja/glossary/terms/custom_span.md @@ -3,4 +3,4 @@ core_product: - ci-cd title: カスタムスパン --- -カスタムスパンは、CI Pipeline Visibility においてコマンドレベルのイベントを統合し、それをパイプラインのフレームグラフで視覚化する機能です。詳細については、ドキュメントを参照してください。 \ No newline at end of file +カスタムスパンは、CI Pipeline Visibility においてコマンドレベルのイベントを統合し、それをパイプラインのフレームグラフで視覚化する機能です。詳細については、ドキュメントを参照してください。 \ No newline at end of file diff --git a/content/ja/glossary/terms/instrumentation.md b/content/ja/glossary/terms/instrumentation.md index 55447b9440612..03acdc78b7130 100644 --- a/content/ja/glossary/terms/instrumentation.md +++ b/content/ja/glossary/terms/instrumentation.md @@ -1,6 +1,7 @@ --- core_product: - apm +short_definition: インスツルメンテーションとは、トレース、メトリクス、ログなどの可観測性データをキャプチャして Datadog にレポートするために、アプリケーションにコードを追加するプロセスです。 title: インスツルメンテーション --- diff --git a/content/ja/glossary/terms/service_map.md b/content/ja/glossary/terms/service_map.md index 9eb0eac2b72af..2133ca1229067 100644 --- a/content/ja/glossary/terms/service_map.md +++ b/content/ja/glossary/terms/service_map.md @@ -1,7 +1,7 @@ --- core_product: - apm -- service catalog +- software catalog title: サービスマップ --- APM では、サービスマップを視覚化することで、サービスの概要とその健全性を確認できます。アプリケーションをコンポーネントサービスに分解し、サービス間の観測された依存関係を描画します。 \ No newline at end of file diff --git a/content/ja/integrations/active_directory.md b/content/ja/integrations/active_directory.md index 9a81603d71620..a635d309de489 100644 --- a/content/ja/integrations/active_directory.md +++ b/content/ja/integrations/active_directory.md @@ -37,7 +37,7 @@ draft: false git_integration_title: active_directory integration_id: active-directory integration_title: Active Directory -integration_version: 4.1.0 +integration_version: 4.2.0 is_public: true manifest_version: 2.0.0 name: active_directory @@ -91,7 +91,7 @@ Datadog Agent をドメイン環境にインストールするには、[Agent ## 収集データ ### メトリクス -{{< get-metrics-from-git "active-directory" >}} +{{< get-metrics-from-git "active_directory" >}} ### イベント diff --git a/content/ja/integrations/agentil_software_sap_hana.md b/content/ja/integrations/agentil_software_sap_hana.md index fa73767afab8f..8b07691e32217 100644 --- a/content/ja/integrations/agentil_software_sap_hana.md +++ b/content/ja/integrations/agentil_software_sap_hana.md @@ -5,9 +5,9 @@ app_id: agentil-software-sap-hana app_uuid: 75784ba6-6a1a-4059-849e-c4cbdb56f258 assets: dashboards: - SAP HANA services overview: assets/dashboards/agentil_software_sap_hana_services_overview.json - SAP HANA systems overview: assets/dashboards/agentil_software_sap_hana_overview.json - SAP HANA tables overview: assets/dashboards/agentil_software_sap_hana_tables_overview.json + SAP HANA DB services overview: assets/dashboards/agentil_software_sap_hana_services_overview.json + SAP HANA DB tables overview: assets/dashboards/agentil_software_sap_hana_tables_overview.json + SAP HANA databases overview: assets/dashboards/agentil_software_sap_hana_overview.json integration: auto_install: false configuration: {} @@ -33,7 +33,7 @@ categories: - data stores - イベント管理 - モニター -custom_kind: integration +custom_kind: インテグレーション dependencies: [] display_on_public_website: true draft: false @@ -108,13 +108,13 @@ Agent ベースのソリューションとは異なり、このプラットフ ### 監視対象モジュール - HANA ノード -- Alerts +- アラート - バックアップ - サービス CPU - サービスメモリ - サービスディスク - ブロックされたトランザクション -- Connections +- 接続 - スレッド - レプリケーションステータス - レプリケーション統計 @@ -142,4 +142,4 @@ AGENTIL Software では、SAP のエキスパートと開発者のチームが --- -このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。このアプリケーションを購入するには、こちらをクリックしてください。 +このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。利用するには、Marketplace でこのアプリケーションを購入してください。 \ No newline at end of file diff --git a/content/ja/integrations/amazon_mediaconvert.md b/content/ja/integrations/amazon_mediaconvert.md index aa95372b14cce..716f4526ade2c 100644 --- a/content/ja/integrations/amazon_mediaconvert.md +++ b/content/ja/integrations/amazon_mediaconvert.md @@ -9,7 +9,7 @@ assets: metrics: check: - aws.mediaconvert.hdoutput_duration - metadata_path: metadata.csv + metadata_path: assets/metrics/metric-spec.yaml prefix: aws.mediaconvert. service_checks: metadata_path: assets/service_checks.json @@ -92,7 +92,7 @@ AWS Elemental MediaConvert を構成して、ログを S3 バケットまたは ## 収集データ ### メトリクス -{{< get-metrics-from-git "amazon-mediaconvert" >}} +{{< get-metrics-from-git "amazon_mediaconvert" >}} ### イベント @@ -113,5 +113,5 @@ AWS Elemental MediaConvert インテグレーションには、サービスの [4]: https://docs.datadoghq.com/ja/logs/guide/forwarder/ [5]: https://docs.datadoghq.com/ja/logs/guide/send-aws-services-logs-with-the-datadog-lambda-function/#collecting-logs-from-s3-buckets [6]: https://docs.datadoghq.com/ja/logs/guide/send-aws-services-logs-with-the-datadog-lambda-function/#collecting-logs-from-cloudwatch-log-group -[7]: https://github.com/DataDog/dogweb/blob/prod/integration/amazon_mediaconvert/amazon_mediaconvert_metadata.csv +[7]: https://github.com/DataDog/integrations-internal-core/blob/main/amazon_mediaconvert/assets/metrics/metric-spec.yaml [8]: https://docs.datadoghq.com/ja/help/ \ No newline at end of file diff --git a/content/ja/integrations/amazon_memorydb.md b/content/ja/integrations/amazon_memorydb.md index ac5a2be21deb1..669af51ccbaa7 100644 --- a/content/ja/integrations/amazon_memorydb.md +++ b/content/ja/integrations/amazon_memorydb.md @@ -27,7 +27,7 @@ categories: - クラウド - モニター - data stores -custom_kind: integration +custom_kind: インテグレーション dependencies: [] display_on_public_website: true draft: false @@ -82,7 +82,7 @@ Amazon MemoryDB for Redis は、高いインメモリパフォーマンスと複 ## 収集データ ### メトリクス -{{< get-metrics-from-git "amazon-memorydb" >}} +{{< get-metrics-from-git "amazon_memorydb" >}} ### イベント @@ -101,11 +101,11 @@ Amazon MemoryDB インテグレーションには、サービスのチェック お役に立つドキュメント、リンクや記事: -- [Monitor Amazon MemoryDB with Datadog][6] +- [Datadog で Amazon MemoryDB を監視する][6] [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-memorydb [4]: https://github.com/DataDog/integrations-internal-core/blob/main/amazon_memorydb/assets/metrics/metric-spec.yaml [5]: https://docs.datadoghq.com/ja/help/ -[6]: https://www.datadoghq.com/blog/amazon-memorydb-integration/ +[6]: https://www.datadoghq.com/blog/amazon-memorydb-integration/ \ No newline at end of file diff --git a/content/ja/integrations/avm_consulting_avm_bootstrap_datadog.md b/content/ja/integrations/avm_consulting_avm_bootstrap_datadog.md index 359b0270eec59..0f15379536b72 100644 --- a/content/ja/integrations/avm_consulting_avm_bootstrap_datadog.md +++ b/content/ja/integrations/avm_consulting_avm_bootstrap_datadog.md @@ -13,7 +13,7 @@ author: vendor_id: avmconsulting categories: - マーケットプレイス -custom_kind: integration +custom_kind: インテグレーション dependencies: [] display_on_public_website: true draft: false @@ -88,4 +88,4 @@ AVM Consulting は、Datadog のゴールドパートナーであり、カリフ --- -このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。このアプリケーションを購入するには、こちらをクリックしてください。 +このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。利用するには、Marketplace でこのアプリケーションを購入してください。 \ No newline at end of file diff --git a/content/ja/integrations/bigpanda_saas.md b/content/ja/integrations/bigpanda_saas.md index 6cd16afd5a565..bab33879cd63a 100644 --- a/content/ja/integrations/bigpanda_saas.md +++ b/content/ja/integrations/bigpanda_saas.md @@ -128,5 +128,6 @@ Datadog マーケットプレイスでのご提供には、BigPanda プラット [5]: https://docs.datadoghq.com/ja/infrastructure [6]: https://docs.datadoghq.com/ja/logs [7]: https://docs.datadoghq.com/ja/tracing + --- このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。利用するには、Marketplace でこのアプリケーションを購入してください。 \ No newline at end of file diff --git a/content/ja/integrations/blink_blink.md b/content/ja/integrations/blink_blink.md index 9d7e170c623c8..db582e524a11f 100644 --- a/content/ja/integrations/blink_blink.md +++ b/content/ja/integrations/blink_blink.md @@ -26,7 +26,7 @@ categories: - クラウド - セキュリティ - マーケットプレイス -custom_kind: integration +custom_kind: インテグレーション dependencies: [] display_on_public_website: true draft: false @@ -117,4 +117,4 @@ Blink の詳細については、[Blink ドキュメント][3]を参照してく [8]: mailto:support@blinkops.com --- -このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。このアプリケーションを購入するには、こちらをクリックしてください。 +このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。利用するには、Marketplace でこのアプリケーションを購入してください。 \ No newline at end of file diff --git a/content/ja/integrations/cisco_secure_firewall.md b/content/ja/integrations/cisco_secure_firewall.md new file mode 100644 index 0000000000000..43b5b0b828e0b --- /dev/null +++ b/content/ja/integrations/cisco_secure_firewall.md @@ -0,0 +1,265 @@ +--- +app_id: cisco-secure-firewall +app_uuid: 15c8217d-1a43-4efb-a338-053fca68169d +assets: + dashboards: + Cisco Secure Firewall - Application and Identity-based Firewall: assets/dashboards/cisco_secure_firewall_application_and_identity_firewall.json + Cisco Secure Firewall - Command Interface: assets/dashboards/cisco_secure_firewall_command_interface.json + Cisco Secure Firewall - Failover: assets/dashboards/cisco_secure_firewall_failover.json + Cisco Secure Firewall - IP Stack: assets/dashboards/cisco_secure_firewall_ip_stack.json + Cisco Secure Firewall - Intrusion Protection System: assets/dashboards/cisco_secure_firewall_intrusion_protection_system.json + Cisco Secure Firewall - OSPF and RIP Routing: assets/dashboards/cisco_secure_firewall_ospf_and_rip_routing.json + Cisco Secure Firewall - Overview: assets/dashboards/cisco_secure_firewall_overview.json + Cisco Secure Firewall - Resource Manager: assets/dashboards/cisco_secure_firewall_resource_manager.json + Cisco Secure Firewall - SNMP: assets/dashboards/cisco_secure_firewall_snmp.json + Cisco Secure Firewall - Security Events: assets/dashboards/cisco_secure_firewall_security_events.json + Cisco Secure Firewall - Threat Detection: assets/dashboards/cisco_secure_firewall_threat_detection.json + Cisco Secure Firewall - Transparent Firewall: assets/dashboards/cisco_secure_firewall_transparent_firewall.json + Cisco Secure Firewall - User Authentication: assets/dashboards/cisco_secure_firewall_user_authentication.json + Cisco Secure Firewall - VPN Failover: assets/dashboards/cisco_secure_firewall_vpn_failover.json + integration: + auto_install: true + configuration: + spec: assets/configuration/spec.yaml + events: + creates_events: false + service_checks: + metadata_path: assets/service_checks.json + source_type_id: 6690422 + source_type_name: cisco-secure-firewall +author: + homepage: https://www.datadoghq.com + name: Datadog + sales_email: info@datadoghq.com (日本語対応) + support_email: help@datadoghq.com +categories: +- network +- security +- log collection +custom_kind: integration +dependencies: +- https://github.com/DataDog/integrations-core/blob/master/cisco_secure_firewall/README.md +display_on_public_website: true +draft: false +git_integration_title: cisco_secure_firewall +integration_id: cisco-secure-firewall +integration_title: Cisco Secure Firewall +integration_version: 1.0.0 +is_public: true +manifest_version: 2.0.0 +name: cisco_secure_firewall +public_title: Cisco Secure Firewall +short_description: Cisco Secure Firewall ログのインサイトを取得 +supported_os: +- linux +- windows +- macos +tile: + changelog: CHANGELOG.md + classifier_tags: + - Supported OS::Linux + - Supported OS::Windows + - Supported OS::macOS + - Category::Network + - Category::Security + - Category::Log Collection + - Submitted Data Type::Logs + - Offering::Integration + configuration: README.md#Setup + description: Cisco Secure Firewall ログのインサイトを取得 + media: + - caption: Cisco Secure Firewall - SNMP + image_url: images/cisco_secure_firewall_snmp.png + media_type: image + - caption: Cisco Secure Firewall - アプリケーション ＆ アイデンティティ ベース ファイアウォール + image_url: images/cisco_secure_firewall_application_and_identity_based_firewall.png + media_type: image + - caption: Cisco Secure Firewall - フェイルオーバー + image_url: images/cisco_secure_firewall_failover.png + media_type: image + - caption: Cisco Secure Firewall - 侵入防御システム + image_url: images/cisco_secure_firewall_intrusion_protection_system.png + media_type: image + - caption: Cisco Secure Firewall - IP スタック + image_url: images/cisco_secure_firewall_ip_stack.png + media_type: image + - caption: Cisco Secure Firewall - 脅威検出 + image_url: images/cisco_secure_firewall_threat_detection.png + media_type: image + - caption: Cisco Secure Firewall - トランスペアレント ファイアウォール + image_url: images/cisco_secure_firewall_transparent_firewall.png + media_type: image + - caption: Cisco Secure Firewall - ユーザー認証 + image_url: images/cisco_secure_firewall_user_authentication.png + media_type: image + overview: README.md#Overview + support: README.md#Support + title: Cisco Secure Firewall +--- + + +## 概要 + +[Cisco Secure Firewall Threat Defense (FTD)][1] は、統合管理を備えた脅威特化型の次世代ファイアウォール (NGFW) です。攻撃の前、最中、そして後に高度な脅威防御を提供します。[Cisco Secure Firewall Management Center (FMC)][2] は、オンプレミスおよび仮想環境で Cisco Secure Firewall Threat Defense (FTD) のイベントとポリシーを一元管理するプラットフォームです。 + +このインテグレーションは、Cisco Secure FMC を使用して Cisco Secure FTD から次のログを取り込み、情報を付加します: +- ユーザー認証ログ +- SNMP ログ +- フェイルオーバー ログ +- トランスペアレント ファイアウォール ログ +- 脅威検出ログ +- セキュリティ イベント +- IP スタック ログ +- アプリケーション ファイアウォール ログ +- アイデンティティ ベース ファイアウォール ログ +- コマンド インターフェイス ログ +- OSPF ルーティング ログ +- RIP ルーティング ログ +- リソース マネージャー ログ +- VPN フェイルオーバー ログ +- 侵入防御システム ログ +- ダイナミック アクセス ポリシー +- IP アドレス割り当て + +SNMP リクエスト、アイデンティティ ベース ファイアウォール ログ、リアルタイム脅威分析、セキュリティ検出と監視、そしてコンプライアンス監視を、すぐに利用できるダッシュボードで詳細に可視化できます。 + +## セットアップ + +### インストール + +Cisco Secure Firewall インテグレーションをインストールするには、以下の Agent インストール コマンドを実行し、その後の手順に従ってください。詳細は[インテグレーション管理ドキュメント][3]を参照してください。 + +**注**: Agent バージョン >= 7.52.0 の場合、この手順は不要です。 + +Linux コマンド: + ```shell + sudo -u dd-agent -- datadog-agent integration install datadog-cisco_secure_firewall==1.0.0 + ``` + +### コンフィギュレーション + +#### Cisco Secure Firewall + +1. Datadog Agent ではデフォルトでログ収集が無効化されています。`datadog.yaml` で有効化してください: + ```yaml + logs_enabled: true + ``` + +2. Cisco Secure Firewall のログ収集を開始するには、次のコンフィギュレーション ブロックを `cisco_secure_firewall.d/conf.yaml` に追加します。 + + 利用可能な設定オプションは、[サンプル cisco_secure_firewall.d/conf.yaml][3] を参照してください。 + + ```yaml + logs: + - type: tcp/udp + port: + service: cisco-secure-firewall + source: cisco-secure-firewall + ``` + +3. [Agent を再起動します][4]。 + +4. Cisco Secure Firewall Management Center での Syslog メッセージ転送設定: + + 1. **Devices > Platform Settings** を選択し、FTD ポリシーを作成または編集します。 + 2. **Syslog > Logging Setup** を選択します。 + - **Enable Logging**: Firepower Threat Defense デバイスのデータ プレーン システム ログを有効化します。 + - **Enable Logging on the failover standby unit**: スタンバイ Firepower Threat Defense デバイスのログを有効化します (利用可能な場合)。 + - **Save** をクリックします。 + 3. **Syslog > Syslog Settings** を選択します。 + - **Facility** ドロップダウンから **LOCAL7(20)** を選択します。 + - Syslog メッセージにメッセージ生成日時を含めるには、**Enable Timestamp on Syslog Messages** チェック ボックスをオンにします。 + - Timestamp Format ドロップダウン リストで **RFC 5424 (yyyy-MM-ddTHH:mm:ssZ)** を選択します。 + - Syslog メッセージの冒頭にデバイス識別子を付加したい場合は、**Enable Syslog Device ID** チェック ボックスをオンにし、識別子の種類を選択してください。 + - **Interface**: メッセージ送信インターフェイスに関係なく、選択したインターフェイスの IP アドレスを使用します。セキュリティ ゾーンを選択してください (ゾーンは単一インターフェイスにマップされる必要があります)。 + - **User Defined ID**: 任意の文字列 (最大 16 文字) を使用します。 + - **Host Name**: デバイスのホスト名を使用します。 + - **Save** をクリックします。 + 4. **Syslog > Syslog Server** を選択します。 + - **Allow user traffic to pass when TCP syslog server is down** をチェックし、TCP プロトコル使用時に syslog サーバーがダウンしてもトラフィックを許可します。 + - **Add** をクリックし、新しい syslog サーバーを追加します。 + - **IP Address** ドロップダウンで、syslog サーバーの IP アドレスを含むネットワーク ホスト オブジェクトを選択します。 + - プロトコル (TCP または UDP) を選択し、Firepower Threat Defense デバイスと syslog サーバー間の通信ポート番号を入力します。 + - Syslog サーバーとの通信に使用する Device Management Interface、Security Zones、または Named Interfaces を選択します。 + - Security Zones または Named Interfaces: 利用可能なゾーン一覧からインターフェイスを選択し Add をクリックします。 + - **OK** をクリックします。 + - **Save** をクリックします。 + 5. **Deploy > Deployment** に進み、ポリシーを割り当て済みデバイスへデプロイします。デプロイが完了するまで変更は適用されません。 + + +### 検証 + +[Agent のステータス サブコマンドを実行][5]し、Checks セクションで `cisco_secure_firewall` を探してください。 + +## 収集されるデータ + +### ログ + +Cisco Secure Firewall インテグレーションは、ユーザー認証、SNMP、フェイルオーバー、トランスペアレント ファイアウォール、IP スタック、アプリケーション ファイアウォール、アイデンティティ ベース ファイアウォール、脅威検出、コマンド インターフェイス、セキュリティ イベント、OSPF ルーティング、RIP ルーティング、リソース マネージャー、VPN フェイルオーバー、侵入防御システムの各ログを収集します。 + +### メトリクス + +Cisco Secure Firewall インテグレーションにはメトリクスは含まれていません。 + +### イベント + +Cisco Secure Firewall インテグレーションにはイベントは含まれていません。 + +### サービス チェック + +Cisco Secure Firewall インテグレーションにはサービス チェックは含まれていません。 + +## トラブルシューティング + +### Cisco Secure Firewall + +**ポート バインド時の Permission denied:** + +Agent ログでポート バインド時に **Permission denied** エラーが表示された場合は、以下の手順を確認してください。 + + 1. 1024 未満のポート番号にバインドするには昇格権限が必要です。`setcap` コマンドでそのポートへのアクセスを許可してください: + + - `setcap` コマンドでポートへのアクセスを付与します。 + + ```shell + sudo setcap CAP_NET_BIND_SERVICE=+ep /opt/datadog-agent/bin/agent/agent + ``` + + - `getcap` コマンドを実行し、設定が正しいことを確認します。 + + ```shell + sudo getcap /opt/datadog-agent/bin/agent/agent + ``` + + 正しければ、次のように出力されます。 + + ```shell + /opt/datadog-agent/bin/agent/agent = cap_net_bind_service+ep + ``` + + **注**: Agent をアップグレードするたびに、この `setcap` コマンドを再実行してください。 + + 2. [Agent を再起動][4]します。 + +**データが収集されない:** + +ファイアウォールが有効な場合、設定したポートからのトラフィックがバイパスされていることを確認してください。 + +**ポートが既に使用中:** + +**Port Already in Use** エラーが表示される場合は、以下の手順を確認してください。例として PORT-NO = 514 の場合を示します。 + +Syslog を使用するシステムで Agent がポート 514 で Cisco Secure Firewall ログを受信しようとすると、Agent ログに次のエラーが表示されることがあります: `Can't start UDP forwarder on port 514: listen udp :514: bind: address already in use` + +これは Syslog がデフォルトでポート 514 を使用しているために発生します。解決するには、以下のいずれか **1 つ** の方法を実施してください: +- Syslog を無効化する。 +- Agent を別の利用可能なポートで待ち受けるように設定する。 + +さらなる支援が必要な場合は、[Datadog サポート][6]までお問い合わせください。 + +[1]: https://www.cisco.com/c/en/us/support/security/firepower-ngfw/series.html +[2]: https://www.cisco.com/c/en/us/products/collateral/security/firesight-management-center/datasheet-c78-736775.html +[3]: https://docs.datadoghq.com/ja/agent/guide/integration-management/?tab=linux#install +[4]: https://docs.datadoghq.com/ja/agent/guide/agent-commands/#start-stop-and-restart-the-agent +[5]: https://docs.datadoghq.com/ja/agent/guide/agent-commands/#agent-status-and-information +[6]: https://docs.datadoghq.com/ja/help/ \ No newline at end of file diff --git a/content/ja/integrations/citrix_hypervisor.md b/content/ja/integrations/citrix_hypervisor.md index 42f03553cfeab..711b7c0d33cd5 100644 --- a/content/ja/integrations/citrix_hypervisor.md +++ b/content/ja/integrations/citrix_hypervisor.md @@ -25,7 +25,7 @@ author: sales_email: info@datadoghq.com (日本語対応) support_email: help@datadoghq.com categories: -- cloud +- クラウド - ログの収集 custom_kind: インテグレーション dependencies: @@ -35,7 +35,7 @@ draft: false git_integration_title: citrix_hypervisor integration_id: citrix-hypervisor integration_title: Citrix Hypervisor -integration_version: 5.1.0 +integration_version: 5.1.1 is_public: true manifest_version: 2.0.0 name: citrix_hypervisor @@ -122,7 +122,7 @@ _Agent バージョン 6.0 以降で利用可能_ ## 収集データ ### メトリクス -{{< get-metrics-from-git "citrix-hypervisor" >}} +{{< get-metrics-from-git "citrix_hypervisor" >}} ### イベント @@ -130,7 +130,7 @@ _Agent バージョン 6.0 以降で利用可能_ Citrix Hypervisor インテグレーションには、イベントは含まれません。 ### サービスチェック -{{< get-service-checks-from-git "citrix-hypervisor" >}} +{{< get-service-checks-from-git "citrix_hypervisor" >}} ## トラブルシューティング diff --git a/content/ja/integrations/crest_data_systems_anomali_threatstream.md b/content/ja/integrations/crest_data_systems_anomali_threatstream.md index 2689757f123e1..bb03a2592fb8b 100644 --- a/content/ja/integrations/crest_data_systems_anomali_threatstream.md +++ b/content/ja/integrations/crest_data_systems_anomali_threatstream.md @@ -126,4 +126,4 @@ Anomali ThreatStream は、環境内で生成される Observable もサポー [9]: https://docs.datadoghq.com/ja/account_management/api-app-keys/ [10]: https://docs.crestdata.ai/datadog-integrations-readme/Crest_Data_Datadog_Integrations_FAQ.pdf --- -このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。このアプリケーションを購入するには、こちらをクリックしてください。 \ No newline at end of file +このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。利用するには、Marketplace でこのアプリケーションを購入してください。 \ No newline at end of file diff --git a/content/ja/integrations/crest_data_systems_barracuda_waf.md b/content/ja/integrations/crest_data_systems_barracuda_waf.md new file mode 100644 index 0000000000000..349f6703c1da3 --- /dev/null +++ b/content/ja/integrations/crest_data_systems_barracuda_waf.md @@ -0,0 +1,154 @@ +--- +algolia: + subcategory: Marketplace インテグレーション +app_id: crest-data-systems-barracuda-waf +app_uuid: 6d143b10-1da5-44e6-9143-19506722385f +assets: + dashboards: + CDS Barracuda WAF - Access Details: assets/dashboards/cds_barracuda_waf_access_details.json + CDS Barracuda WAF - Audit Details (WAAS): assets/dashboards/cds_barracuda_waf_audit_details_waas.json + CDS Barracuda WAF - Audit Details (WAF): assets/dashboards/cds_barracuda_waf_audit_details_waf.json + CDS Barracuda WAF - Event Details: assets/dashboards/cds_barracuda_waf_event_details.json + CDS Barracuda WAF - Network Firewall Details: assets/dashboards/cds_barracuda_waf_network_firewall_details.json + CDS Barracuda WAF - System Details: assets/dashboards/cds_barracuda_waf_system_details.json + CDS Barracuda WAF - Web Firewall Details: assets/dashboards/cds_barracuda_waf_web_firewall_details.json + integration: + auto_install: false + configuration: + spec: assets/configuration/spec.yaml + events: + creates_events: true + service_checks: + metadata_path: assets/service_checks.json + source_type_id: 10380 + source_type_name: crest_data_systems_barracuda_waf + monitors: + 'Server Responding with Status Code lying in Range: [400-599]': assets/monitors/cds_server_response_error_status_code.json +author: + homepage: https://www.crestdata.ai + name: Crest Data + sales_email: datadog-sales@crestdata.ai + support_email: datadog.integrations@crestdata.ai + vendor_id: crest-data-systems +categories: +- マーケットプレイス +- イベント管理 +- ログの収集 +custom_kind: インテグレーション +dependencies: [] +display_on_public_website: true +draft: false +git_integration_title: crest_data_systems_barracuda_waf +integration_id: crest-data-systems-barracuda-waf +integration_title: Barracuda WAF +integration_version: '' +is_public: true +legal_terms: + eula: assets/EULA.pdf +manifest_version: 2.0.0 +name: crest_data_systems_barracuda_waf +pricing: +- billing_type: flat_fee + includes_assets: true + product_id: barracuda-waf + short_description: Barracuda WAF インテグレーションの月額定額料金。 + unit_price: 295.0 +public_title: Barracuda WAF +short_description: Barracuda WAF および Barracuda WAAS のデータを Syslog または API 経由で可視化 +supported_os: +- linux +- windows +- macos +tile: + changelog: CHANGELOG.md + classifier_tags: + - Supported OS::Linux + - Supported OS::Windows + - Supported OS::macOS + - Category::Marketplace + - Category::Event Management + - Category::Log Collection + - Offering::Integration + - Submitted Data Type::Events + - Submitted Data Type::Logs + configuration: README.md#Setup + description: Barracuda WAF および Barracuda WAAS のデータを Syslog または API 経由で可視化 + media: + - caption: CDS Barracuda WAF - アクセス詳細 + image_url: images/cds_barracuda_waf_access_details.png + media_type: image + - caption: CDS Barracuda WAF - 監査詳細 (WAF) + image_url: images/cds_barracuda_waf_audit_details_waf.png + media_type: image + - caption: CDS Barracuda WAF - 監査詳細 (WAAS) + image_url: images/cds_barracuda_waf_audit_details_waas.png + media_type: image + - caption: CDS Barracuda WAF - ネットワークファイアウォール詳細 + image_url: images/cds_barracuda_waf_network_firewall_details.png + media_type: image + - caption: CDS Barracuda WAF - システム詳細 + image_url: images/cds_barracuda_waf_system_details.png + media_type: image + - caption: CDS Barracuda WAF - Web ファイアウォール詳細 + image_url: images/cds_barracuda_waf_web_firewall_details.png + media_type: image + - caption: CDS Barracuda WAF - イベント詳細 + image_url: images/cds_barracuda_waf_event_details.png + media_type: image + overview: README.md#Overview + support: README.md#Support + title: Barracuda WAF + uninstallation: README.md#Uninstallation +--- + + + + +## 概要 + +この Barracuda WAF インテグレーションは、Barracuda WAF と Barracuda WAAS の監視および可視化を行います。 + +### Barracuda Web Application Firewall (WAF) + +**Barracuda Web Application Firewall (WAF)** は、さまざまなサイバー脅威や攻撃から Web アプリケーションを保護するために設計されたセキュリティ ソリューションです。Web アプリケーション サーバーとインターネットの間でゲートウェイとして機能し、アプリケーションのセキュリティと可用性を確保するために、受信および送信トラフィックを監視・フィルタリングします。 + +### Barracuda Web Application Firewall as-a-Service (WAAS) + +**Barracuda WAF-as-a-Service (WAAS)** は、アプライアンスの管理負荷なしにクラウド提供されるエンタープライズ グレードのアプリケーション セキュリティを提供します。Barracuda WAF-as-a-Service により、ホスト場所を問わず数分でアプリケーションを保護できます。導入・スケール・サイズ調整・保守は一切不要です。 + +### 機能 + +| 製品 | メソッド | 収集ログ | ドキュメント 参照リンク | + | ---- | ----------- | -------- | --------- | + | WAF | Syslog | Network Firewall、Access、Web Firewall、Audit、System| [Barracuda WAF][9]| + | WAAS | Syslog | Web Firewall、Access、Event| [Barracuda WAAS Syslog][10]| + | WAAS | API | Web Firewall、Access、Audit| [Barracuda WAAS API][11]| + + +## Agent + +サポートまたは機能リクエストをご希望の場合は、以下のチャンネルから Crest Data にお問い合わせください。 + +- サポート: [datadog.integrations@crestdata.ai][2] +- 営業: [datadog-sales@crestdata.ai][3] +- Web サイト: [crestdata.ai][1] +- FAQ: [Crest Data Datadog Marketplace Integrations FAQ][15] + + +[1]: https://www.crestdata.ai/ +[2]: mailto:datadog.integrations@crestdata.ai +[3]: mailto:datadog-sales@crestdata.ai +[4]: https://docs.datadoghq.com/ja/agent/guide/agent-commands/?tab=agentv6v7#start-stop-and-restart-the-agent +[5]: https://docs.datadoghq.com/ja/agent/guide/agent-commands/#agent-status-and-information +[6]: https://docs.datadoghq.com/ja/agent/guide/agent-configuration-files/?tab=agentv6v7 +[7]: https://campus.barracuda.com/product/webapplicationfirewall/doc/92767342/adding-a-syslog-server +[8]: https://campus.barracuda.com/product/WAAS/doc/91980986/managing-administrator-roles/ +[9]: https://campus.barracuda.com/product/webapplicationfirewall/doc/92767349/exporting-log-formats/ +[10]: https://campus.barracuda.com/product/WAAS/doc/79462622/log-export +[11]: https://blog.barracuda.com/2021/10/18/barracuda-waf-as-a-service-rest-api +[12]: https://docs.crestdata.ai/datadog-integrations-readme/barracuda_WAF.pdf +[13]: https://docs.datadoghq.com/ja/agent/?tab=Linux +[14]: https://docs.datadoghq.com/ja/account_management/api-app-keys/ +[15]: https://docs.crestdata.ai/datadog-integrations-readme/Crest_Data_Datadog_Integrations_FAQ.pdf +--- +このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。利用するには、Marketplace でこのアプリケーションを購入してください。 \ No newline at end of file diff --git a/content/ja/integrations/crest_data_systems_sysdig.md b/content/ja/integrations/crest_data_systems_sysdig.md index d943052139373..d81061cda5b4e 100644 --- a/content/ja/integrations/crest_data_systems_sysdig.md +++ b/content/ja/integrations/crest_data_systems_sysdig.md @@ -100,41 +100,7 @@ tile: * アクティビティ監査 * 監査タップ -## トラブルシューティング - -* Agent ログでポートバインディング中に **Permission denied** エラーが表示された場合は、以下の手順に従ってください。 - - 1. 1024 未満のポート番号にバインドするには、昇格権限が必要です。以下の手順に従って設定してください。 - - - setcap コマンドを使用して、ポートへのアクセスを許可します。 - - ``` - sudo setcap CAP_NET_BIND_SERVICE=+ep /opt/datadog-agent/bin/agent/agent - ``` - - - セットアップが正しいか確認するために、getcap コマンドを実行します。 - - ``` - sudo getcap /opt/datadog-agent/bin/agent/agent - ``` - 正しければ、次のように出力されます。 - - ``` - /opt/datadog-agent/bin/agent/agent = cap_net_bind_service+ep - ``` - **注**: Agent をアップグレードするたびに、この setcap コマンドを再実行してください。 - - 2. [Agent を再起動します][3]。 - -* ファイアウォールが有効になっている場合、構成ポートからのトラフィックがバイパスされることを確認してください。 - -* **Port Already in Use** エラーが表示された場合は、以下の手順に従ってください (以下の例は PORT-NO = 514 の場合です)。 - - * Syslog があるシステムで、Agent がポート 514 で Sysdig ログをリッスンしている場合、Agent ログに以下のエラーが表示されることがあります: **Can't start UDP forwarder on port 514: listen udp :514: bind: address already in use** - - * これは、デフォルトで Syslog がポート 514 をリッスンしているために発生します。このエラーを解決するには、Syslog を無効にするか、Agent が他のサービスに占有されていない利用可能なポートをリッスンします。 - -## Agent +## サポート サポートまたは機能リクエストをご希望の場合は、以下のチャンネルから Crest Data にお問い合わせください。 @@ -156,4 +122,4 @@ tile: [10]: https://docs.datadoghq.com/ja/agent/?tab=Linux [11]: https://docs.crestdata.ai/datadog-integrations-readme/Crest_Data_Datadog_Integrations_FAQ.pdf --- -このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。このアプリケーションを購入するには、こちらをクリックしてください。 \ No newline at end of file +このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。利用するには、Marketplace でこのアプリケーションを購入してください。 \ No newline at end of file diff --git a/content/ja/integrations/cribl_stream.md b/content/ja/integrations/cribl_stream.md new file mode 100644 index 0000000000000..d7962ec8b6fee --- /dev/null +++ b/content/ja/integrations/cribl_stream.md @@ -0,0 +1,152 @@ +--- +app_id: cribl-stream +app_uuid: 2ef15aea-af91-4769-940c-2b124e4d04a6 +assets: + dashboards: + cribl_stream_overview: assets/dashboards/cribl_stream_overview.json + integration: + auto_install: true + configuration: {} + events: + creates_events: false + metrics: + check: cribl.logstream.health.outputs + metadata_path: metadata.csv + prefix: cribl.logstream. + service_checks: + metadata_path: assets/service_checks.json + source_type_id: 10391 + source_type_name: Cribl +author: + homepage: https://cribl.io + name: Cribl + sales_email: sales@cribl.io + support_email: support@cribl.io +categories: +- AWS +- Azure +- クラウド +- incident-teams +- kubernetes +- Google Cloud +- ログの収集 +- セキュリティ +- モニター +custom_kind: インテグレーション +dependencies: +- https://github.com/DataDog/integrations-extras/blob/master/cribl_stream/README.md +display_on_public_website: true +draft: false +git_integration_title: cribl_stream +integration_id: cribl-stream +integration_title: Cribl Stream +integration_version: '' +is_public: true +manifest_version: 2.0.0 +name: cribl_stream +public_title: Cribl Stream +short_description: ベンダーに依存しないデータテレメトリーパイプラインで可観測性データを収集します +supported_os: +- linux +- windows +tile: + changelog: CHANGELOG.md + classifier_tags: + - Supported OS::Linux + - Supported OS::Windows + - Submitted Data Type::Metrics + - Category::AWS + - Category::Azure + - Category::Cloud + - Category::Containers + - Category::Kubernetes + - Category::Google Cloud + - Category::Log Collection + - Category::Security + - Category::Metrics + - Offering::Integration + configuration: README.md#Setup + description: ベンダーに依存しないデータテレメトリーパイプラインで可観測性データを収集します + media: + - caption: 可観測性がすべてを変える + image_url: images/observability_changes.png + media_type: ビデオ + vimeo_id: 567294419 + - caption: Datadog 用 Cribl Stream ダッシュボード + image_url: images/cribl_dashboard_for_datadog.png + media_type: image + overview: README.md#Overview + support: README.md#Support + title: Cribl Stream + uninstallation: README.md#Uninstallation +--- + + + + +## 概要 +[Cribl Stream][1] は、機械データのログ、インスツルメンテーションデータ、アプリケーションデータ、メトリクスをリアルタイムで処理し、任意の分析プラットフォームへ配信するのを支援します。次のようなことが可能です。 + +- 外部データソースからの情報を付加してデータを強化し、コンテキストを追加する +- 機密フィールドをマスク、難読化、または暗号化してデータを保護する +- パフォーマンスやコスト要件に応じてデータを最適化する + +これはセルフホステッド版 Cribl Stream 向けの手順です。 + +標準で用意されているダッシュボードを使用すると、1 秒あたりのイベント数、1 秒あたりのバイト数、入力タイプ、出力タイプ、インフラメトリクスなどの基本メトリクスを用いて Stream のパフォーマンスを可視化できます。イベントまたはバイト数ごとの削減率をモニタリングし、検索パフォーマンスの向上や分析システムのライセンスおよびインフラコストの削減に役立てることができます。 + +## セットアップ +Cribl Stream の[内部メトリクス][2]を Datadog API に送信できます。 + +### インストール + +#### Datadog +組織設定の [_API Keys_][3] に移動し、Cribl がデータを送信するための API キーを作成します。 + +#### Cribl +1. Cribl で _Quick Connects_ に移動し、_+Add Source_ ボタンをクリックします。 +![step1][4] +2. _System Internal_ までスクロールし、_Cribl Internal_ にカーソルを合わせて _Select Existing_ を選択します。_CriblLogs_ と _CriblMetrics_ の両方を有効にします。 + - **注**: この 2 つのソースは **Routes** ではなく **Quick Connect** が有効になっている必要があります。 +![step3][5] + +3. _+Add Destination_ ボタンをクリックします。 +4. _Datadog_ タイルまでスクロールし、_+Add New_ をクリックします。 +5. 入力に名前を付けます (例: Cribl_Datadog)。 +![step4][6] + +6. 次に、_Datadog API Key_ を入力し、使用している Datadog サイトを選択します。 +7. 必要に応じて Datadog タグや、メッセージフィールド、ソース、ホスト情報を追加します。詳細については [Cribl Datadog Destination のドキュメント][7]を参照してください。 +8. _Save_ をクリックします。 +10. _CriblMetrics_ を Datadog 宛先に接続するために _Passthru_ を選択します。 +![step5][8] + +![complete][9] + +## アンインストール +Cribl Stream ダッシュボードの設定で [delete dashboard][10] オプションを使用して Cribl Stream ダッシュボードを削除できます。Datadog 宛先を Cribl Stream デプロイから削除することで、データ送信を停止します。 + +## 収集データ +### メトリクス +{{< get-metrics-from-git "cribl_stream" >}} + +### イベント +Cribl Stream インテグレーションにはイベントは含まれていません。 +### サービスチェック +Cribl Stream インテグレーションにはサービスチェックは含まれていません。 + +## トラブルシューティング +サポートが必要ですか？[Cribl Support][12] までお問い合わせください。 + +[1]: https://cribl.io/stream +[2]: http://docs.cribl.io/logstream/sources-cribl-internal/ +[3]: https://app.datadoghq.com/organization-settings/api-keys +[4]: https://raw.githubusercontent.com/DataDog/integrations-extras/master/cribl_stream/images/cribl_dd_1.png +[5]: https://raw.githubusercontent.com/DataDog/integrations-extras/master/cribl_stream/images/cribl_dd_3.png +[6]: https://raw.githubusercontent.com/DataDog/integrations-extras/master/cribl_stream/images/cribl_dd_4.png +[7]: https://docs.cribl.io/stream/destinations-datadog +[8]: https://raw.githubusercontent.com/DataDog/integrations-extras/master/cribl_stream/images/cribl_dd_6.png +[9]: https://raw.githubusercontent.com/DataDog/integrations-extras/master/cribl_stream/images/cribl_dd_5.png +[10]: https://docs.datadoghq.com/ja/dashboards/#delete-dashboard +[11]: https://github.com/DataDog/integrations-extras/blob/master/cribl_stream/metadata.csv +[12]: https://cribl.io/support \ No newline at end of file diff --git a/content/ja/integrations/dylibso-webassembly.md b/content/ja/integrations/dylibso-webassembly.md index 3b30c453feaee..c430f24cef42d 100644 --- a/content/ja/integrations/dylibso-webassembly.md +++ b/content/ja/integrations/dylibso-webassembly.md @@ -11,7 +11,7 @@ categories: - 開発ツール - 言語 - tracing -custom_kind: integration +custom_kind: インテグレーション dependencies: - https://github.com/DataDog/integrations-extras/blob/master/dylibso-webassembly/README.md display_on_public_website: true @@ -56,50 +56,50 @@ tile: ## 概要 -This integration provides function traces from WebAssembly (WASM) code running in your application. Gain insight into WebAssembly code performance as well as the following behavior: -- Function call duration -- Execution tracing -- Memory allocation +このインテグレーションは、アプリケーションで実行される WebAssembly (WASM) コードから関数トレースを提供します。WebAssembly コードのパフォーマンスに加えて、以下の動作についてのインサイトを得ることができます: +- 関数呼び出しの実行時間 +- 実行トレース +- メモリ割り当て -Since WebAssembly code is executed in a secure and constrained environment, traditional techniques to monitor code do not work. Our specialized observability stack allows you to continuously monitor WASM modules at the same level you expect of your other applications. +WebAssembly コードは安全かつ制限された環境で実行されるため、従来のコード監視手法は機能しません。専用の可観測性スタックにより、他のアプリケーションと同じレベルで WASM モジュールを継続的にモニタリングできます。 -Datadog customers can use our open source SDKs and Adapters to emit full traces from your WASM programs. Please see the [`dylibso/observe-sdk`][1] repository to install the Datadog Adapter for your application. +Datadog の利用者は、オープンソースの SDK と Adapter を使って WASM プログラムから完全なトレースを出力できます。アプリケーションに Datadog Adapter をインストールするには、[`dylibso/observe-sdk`][1] リポジトリを参照してください。 -In addition, Dylibso provides automatic instrumentation tooling which can take any existing WASM module and recompile it to include function and memory allocation tracing. For more information, contact [support@dylibso.com][2] or learn more about [automatic WebAssembly instrumentation][3]. +さらに、Dylibso は既存の WASM モジュールを再コンパイルして関数およびメモリ割り当てのトレースを追加する自動インスツルメンテーションツールを提供しています。詳しくは [support@dylibso.com][2] にお問い合わせいただくか、[自動 WebAssembly インスツルメンテーション][3]についてご覧ください。 ## セットアップ ### インストール -Depending on the programming language your application is written in, choose one of the appropriate Datadog Adapters from [`dylibso/observe-sdk`][1] on GitHub. +アプリケーションのプログラミング言語に応じて、GitHub 上の [`dylibso/observe-sdk`][1] から適切な Datadog Adapter を選択してください。 ### 構成 -In order to connect the SDK and Adapter to your Datadog Agent, you must have the following information ready: +SDK と Adapter を Datadog Agent に接続するためには、以下の情報が必要です: -1. Your Datadog Agent host URL. -2. The service name of the application where the SDK and Adapter are imported. +1. Datadog Agent ホスト URL +2. SDK と Adapter をインポートしているアプリケーションのサービス名 ### 検証 -After you have imported and configured your Datadog Adapter from the available options within the Observe SDK: +Observe SDK に含まれるオプションの中から Datadog Adapter をインポートし、設定したら: -1. Redeploy your application so the Datadog Adapter is included where you're calling WebAssembly code. -2. Ensure that a WebAssembly module (`.wasm`) has been loaded and you are calling one of its exported functions. -3. Check in your Datadog dashboard for traces sent from your service. +1. アプリケーションを再デプロイして、WebAssembly コードを呼び出す箇所に Datadog Adapter が組み込まれるようにします。 +2. WebAssembly モジュール (`.wasm`) が読み込まれていることと、そのエクスポートされた関数のいずれかを呼び出していることを確認します。 +3. Datadog ダッシュボードで、サービスから送信されたトレースをチェックします。 ## 収集データ ### イベント -WebAssembly Observe SDK collects traces of function execution and memory allocation events from your application. +WebAssembly Observe SDK は、アプリケーションから関数実行やメモリ割り当てイベントのトレースを収集します。 ## トラブルシューティング -Need help? Contact [Dylibso support][2]. +ご不明な点がございましたら、[Dylibso サポート][2]までお問い合わせください。 [1]: https://github.com/dylibso/observe-sdk [2]: mailto:support@dylibso.com -[3]: https://dylibso.com/products/observe +[3]: https://dylibso.com/products/observe \ No newline at end of file diff --git a/content/ja/integrations/ecco_select_custom_implementation__migration_services.md b/content/ja/integrations/ecco_select_custom_implementation__migration_services.md new file mode 100644 index 0000000000000..5becdb4840aba --- /dev/null +++ b/content/ja/integrations/ecco_select_custom_implementation__migration_services.md @@ -0,0 +1,107 @@ +--- +algolia: + subcategory: Marketplace インテグレーション +app_id: ecco-select-custom-implementation-migration-services +app_uuid: 0193d201-c87f-7a50-90fe-8c93799857e5 +assets: {} +author: + contact_link: https://www.eccoselect.com/ + homepage: https://www.eccoselect.com/ + name: ECCO Select + sales_email: lmurphy@eccoselect.com + support_email: lmurphy@eccoselect.com + vendor_id: ecco-select +categories: +- configuration & deployment +- automation +- collaboration +- testing +- event management +- marketplace +custom_kind: integration +dependencies: [] +display_on_public_website: true +draft: false +git_integration_title: ecco_select_custom_implementation__migration_services +integration_id: ecco-select-custom-implementation-migration-services +integration_title: カスタム実装 & 移行サービス +integration_version: '' +is_public: true +manifest_version: 2.0.0 +name: ecco_select_custom_implementation__migration_services +pricing: +- includes_assets: false + private_offer_only: true + product_id: custom-implementation--migration-services + short_description: プライベート オファー プレースホルダー + unit_price: null +public_title: カスタム実装 & 移行サービス +short_description: ECCO Select は、組織の Datadog プラットフォームへの導入または移行を長年支援してきました。 +supported_os: [] +tile: + changelog: CHANGELOG.md + classifier_tags: + - Category::Configuration & Deployment + - Category::Automation + - Category::Collaboration + - Category::Testing + - Category::Event Management + - Category::Marketplace + - Offering::Professional Service + configuration: README.md#Setup + description: ECCO Select は、組織の Datadog プラットフォームへの導入または移行を長年支援してきました。 + media: + - caption: 業界での実績 + image_url: images/1j.jpg + media_type: image + - caption: マネージド サービス プロバイダー + image_url: images/2j.jpg + media_type: image + - caption: 対応能力 + image_url: images/3j.jpg + media_type: image + overview: README.md#Overview + support: README.md#Support + title: カスタム実装 & 移行サービス + uninstallation: README.md#Uninstallation +--- + + + + +## 概要 + +**説明:** + +ECCO Select のカスタマイズされた導入・移行サービスで、貴社の可観測性戦略を変革します。当社のエンドツーエンド サービスは、設計、実装、モニタリング、最適化、継続的なサポートなど、Datadog 管理のあらゆる側面を網羅します。貴社固有のビジネス要件に合わせたソリューションを提供し、重要なシステムやアプリケーションを継続的に可視化します。当社の知見を活用することで、ダウンタイムを削減し、運用効率を向上させ、社内チームに複雑さを追加することなく、Datadog への投資から一貫した価値を引き出せます。 + +Agent のデプロイ、カスタム ダッシュボードの作成、既存のツールやシステムとの連携など、貴社環境で Datadog を導入・拡張するあらゆるステップを伴走します。レガシーな監視ソリューションからの移行でも、現在の可観測性プラットフォームのスケールでも、当社チームがシームレスで効率的な移行を実現します。カスタマイズされたアプローチにより、Datadog 構成を貴社のビジネス目標に整合させ、ダウンタイムを低減し、価値実現までの時間を短縮します。 + +**マルチテナント構成 & サポート:** ECCO Select のエキスパートによるサポートと構成サービスで、マルチテナント環境管理の複雑さを解消します。複数テナントに対応しつつ明確な分離と効率的なリソース配分を維持できる、スケーラブルで堅牢なアーキテクチャの構築を得意としています。SaaS 環境の管理でも、複数の社内チームの支援でも、大規模環境でも運用の卓越性を実現するためのツールと専門知識を提供します。 + +**お客様環境のアセスメント/コンサルテーション:** ECCO Select の詳細な環境アセスメントとコンサルテーション サービスにより、Datadog の潜在力を最大限に引き出します。現在の可観測性フレームワークを精査し、システムの健全性、モニタリング設定、パフォーマンス メトリクスを分析します。本サービスは、システムの信頼性を高め、コスト管理を改善し、業界標準やビジネス目標との整合性を確保したい組織に最適です。 + +**継続的なメンテナンス、サポート & オペレーション:** ECCO Select の継続的なメンテナンスと運用サポート サービスにより、Datadog 環境が常に最高の効率で稼働するようにします。プロアクティブなシステムのヘルス チェックやモニターのチューニングから、設定問題の解消やスケーリング対応まで、ビジネスの進化に合わせて包括的に支援します。当社チームは貴社の IT 組織の延長として、アップデート対応、トラブルシューティング、パフォーマンス最適化を担い、可観測性管理に煩わされることなく中核的なビジネス目標に集中できるよう支えます。 + +**Datadog 最適化サポート サービス:** ECCO Select の最適化サポート サービスにより、Datadog 環境のパフォーマンスと効率を最大化します。監視戦略の洗練、アラートのチューニング、データ ノイズの排除に注力し、意思決定に直結するインサイトを提供します。コスト ガバナンスや効果的なライセンス管理/活用を通じて、適切なコスト コントロールの下で貴社が Datadog Product Suite を最大限に活用できるよう支援します。さらに、重要な KPI を確実に監視しながらリソース使用を最適化し、コスト削減を実現します。既存の設定のスリム化でも、新たな運用要件への適応でも、当社の最適化サービスは貴社の可観測性プラットフォームが戦略的資産であり続けることを保証します。 + +**付加価値:** + +- Datadog ベスト プラクティス & トレーニング +- コスト ガバナンス サポート: ライセンス管理 + 活用 +- カスタム インテグレーション サポート +- ライセンス価格の割引 +- 民間セクター + 公共セクターの業界専門知識 +- GovCloud & GA Datadog プラットフォームの専門知識 +- 最高水準の社内 Program Management Office (PMO) +- Datadog およびエンタープライズ可観測性を超える専門性 + +## サポート + +- Web サイト: www.eccoselect.com +- 電話: 816-960-3800 +- 価格および追加情報: Lindsey Murphy, Vice President – lmurphy@eccoselect.com + + +--- +このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。利用するには、Marketplace でこのアプリケーションを購入してください。 \ No newline at end of file diff --git a/content/ja/integrations/eks_anywhere.md b/content/ja/integrations/eks_anywhere.md index 391fb028894c2..bb9ff00662e59 100644 --- a/content/ja/integrations/eks_anywhere.md +++ b/content/ja/integrations/eks_anywhere.md @@ -17,12 +17,12 @@ author: sales_email: info@datadoghq.com (日本語対応) support_email: help@datadoghq.com categories: -- AWS +- aws - クラウド -- コンテナ +- incident-teams - kubernetes - ログの収集 -- orchestration +- オーケストレーション - プロビジョニング custom_kind: インテグレーション dependencies: diff --git a/content/ja/integrations/go_pprof_scraper.md b/content/ja/integrations/go_pprof_scraper.md new file mode 100644 index 0000000000000..b95083edb3fbe --- /dev/null +++ b/content/ja/integrations/go_pprof_scraper.md @@ -0,0 +1,127 @@ +--- +app_id: go-pprof-scraper +app_uuid: 2b13f6b1-d3ba-4254-93c0-2ceaf783cd85 +assets: + integration: + auto_install: true + configuration: + spec: assets/configuration/spec.yaml + events: + creates_events: false + service_checks: + metadata_path: assets/service_checks.json + source_type_id: 10309 + source_type_name: go_pprof_scraper +author: + homepage: https://www.datadoghq.com + name: コミュニティ + sales_email: info@datadoghq.com (日本語対応) + support_email: help@datadoghq.com +categories: [] +custom_kind: インテグレーション +dependencies: +- https://github.com/DataDog/integrations-extras/blob/master/go_pprof_scraper/README.md +display_on_public_website: true +draft: false +git_integration_title: go_pprof_scraper +integration_id: go-pprof-scraper +integration_title: Go pprof scraper +integration_version: 1.0.4 +is_public: true +manifest_version: 2.0.0 +name: go_pprof_scraper +public_title: Go pprof scraper +short_description: Go プログラムから /debug/pprof エンドポイント経由でプロファイルを収集する +supported_os: +- linux +- macos +- windows +tile: + changelog: CHANGELOG.md + classifier_tags: + - Supported OS::Linux + - Supported OS::macOS + - Supported OS::Windows + - Offering::Integration + configuration: README.md#Setup + description: Go プログラムから /debug/pprof エンドポイント経由でプロファイルを収集する + media: [] + overview: README.md#Overview + support: README.md#Support + title: Go pprof scraper +--- + + + + +## 概要 + +このチェックは、[`/debug/pprof`][1] エンドポイントを公開している Go アプリケーションからプロファイルを収集します。 + +**注**: サービスに [dd-trace-go][2] プロファイリングクライアントライブラリを組み込める場合は、そちらを優先的に使用してください。クライアントライブラリを利用すると、[コードホットスポットやエンドポイントフィルタリング][3]など、他の Datadog サービスとの連携が強化されます。ソースコードを管理できないサービスには、このインテグレーションを使用してください。 + +**注**: このインテグレーションを使用すると、Datadog の [Continuous Profiler][4] サービスにおいてホストが課金対象となります。Continuous Profiler の課金に関する詳細は、[課金に関するドキュメント][5]を参照してください。 + +## セットアップ + +ホストで実行されている Agent 用にこのチェックをインストールおよび構成する場合は、以下の手順に従ってください。コンテナ環境の場合は、[オートディスカバリーのインテグレーションテンプレート][6]のガイドを参照してこの手順を行ってください。 + +### インストール + +Agent バージョンが v7.21/v6.21 以上の場合は、以下の手順に従ってホストに `go_pprof_scraper` チェックをインストールしてください。Agent バージョンが [v7.21/v6.21 未満][8]、または [Docker Agent][9] を使用している場合にコミュニティインテグレーションをインストールする手順については、専用の Agent ガイドである[コミュニティインテグレーションのインストール][7]を参照してください。 + +1. [Datadog Agent をダウンロードして起動][10]します。 +2. 次のコマンドを実行して、Agent でインテグレーション Wheel をインストールします。 + + ```shell + datadog-agent integration install -t datadog-go-pprof-scraper== + ``` + 最新バージョンは [Datadog Integrations Release Page][11] で確認できます。 + + **注**: I必要に応じて、インストールコマンドの先頭に `sudo -u dd-agent` を追加します。 + +### 構成 + +1. Agent の設定ディレクトリ直下にある `conf.d/` フォルダ内の `go_pprof_scraper.d/conf.yaml` ファイルを編集して、Go のパフォーマンスデータの収集を開始します。利用可能なすべての設定オプションについては、[サンプル go_pprof_scraper.d/conf.yaml][12] を参照してください。 + +2. [Agent を再起動します][13]。 + +### 検証 + +[Agent のステータスサブコマンドを実行][14]し、Checks セクション内に `go_pprof_scraper` が表示されていることを確認します。 + +## 収集データ + +### メトリクス + +Go-pprof-scraper インテグレーションは、いかなるメトリクスも作成しません。 + +### イベント + +Go-pprof-scraper インテグレーションには、イベントは含まれていません。 + +### サービスチェック +{{< get-service-checks-from-git "go_pprof_scraper" >}} + + +## トラブルシューティング + +ご不明な点は、[Datadog のサポートチーム][16]までお問合せください。 + + +[1]: https://pkg.go.dev/net/http/pprof +[2]: https://docs.datadoghq.com/ja/profiler/enabling/go/ +[3]: https://docs.datadoghq.com/ja/profiler/connect_traces_and_profiles/ +[4]: https://docs.datadoghq.com/ja/profiler/ +[5]: https://docs.datadoghq.com/ja/account_management/billing/apm_tracing_profiler/ +[6]: https://docs.datadoghq.com/ja/agent/kubernetes/integrations/ +[7]: https://docs.datadoghq.com/ja/agent/guide/use-community-integrations/?tab=agentv721v621 +[8]: https://docs.datadoghq.com/ja/agent/guide/use-community-integrations/?tab=agentearlierversions +[9]: https://docs.datadoghq.com/ja/agent/guide/use-community-integrations/?tab=docker +[10]: https://app.datadoghq.com/account/settings/agent/latest +[11]: https://github.com/DataDog/integrations-extras/tags +[12]: https://github.com/DataDog/integrations-extras/blob/master/go_pprof_scraper/datadog_checks/go_pprof_scraper/data/conf.yaml.example +[13]: https://docs.datadoghq.com/ja/agent/guide/agent-commands/#start-stop-and-restart-the-agent +[14]: https://docs.datadoghq.com/ja/agent/guide/agent-commands/#agent-status-and-information +[15]: https://github.com/DataDog/integrations-extras/blob/master/go_pprof_scraper/assets/service_checks.json +[16]: https://docs.datadoghq.com/ja/help/ \ No newline at end of file diff --git a/content/ja/integrations/guide/send-tcp-udp-host-metrics-to-the-datadog-api.md b/content/ja/integrations/guide/send-tcp-udp-host-metrics-to-the-datadog-api.md new file mode 100644 index 0000000000000..df945115c0317 --- /dev/null +++ b/content/ja/integrations/guide/send-tcp-udp-host-metrics-to-the-datadog-api.md @@ -0,0 +1,37 @@ +--- +aliases: +- /ja/integrations/faq/how-to-send-tcp-udp-host-metrics-via-the-datadog-api +title: TCP/UDP ホストメトリクスを Datadog API に送信する +--- + +TCP/UDP 接続に関するインサイトを得るには、Crontab エントリーを介して統計情報を収集し、それらを Datadog プラットフォームに転送できます。 + +これを行うには、/proc/net/sockstat にある Linux の sockstats を使用してください。 + +以下は、開始に役立つコードスニペットの例です。 + +https://gist.github.com/sage-oli-wood/70e0931f037ea0aac132 + +これは HTTP POST を通じて Datadog にデータを送信します。 + +より適切な方法は、DogStatsD を使用してメトリクスとイベントを送信することです。cron ジョブを調整して、データを UDP でローカルの Agent に転送するようにできます。詳細はここで確認してください。 + +これにより、次の情報を取得できます。 + +* TCP: + +|||| +|:---|:---|:---| +|in use| 確立された接続の総数 | integer (number)| +|Orphan| 孤立した TCP 接続 | +(ユーザーファイルハンドルにアタッチされていない) | integer (number)| +|TW | TIME_WAIT 接続 | integer (millisec)| +|Alloc| 割り当てられた TCP ソケット | (すべてのタイプ、例: ESTABLISH、CLOSE_WAIT、TIME_WAIT など)| +|mem| TCP ソケットの総メモリ | integer (KiloBytes)| + +* UDP: + +|||| +|:---|:---|:---| +|inuse| 確立された接続の総数 | 整数| +|mem |UDP ソケットの総メモリ | integer (KB)| \ No newline at end of file diff --git a/content/ja/integrations/hasura_cloud.md b/content/ja/integrations/hasura_cloud.md index de037de738ed5..ad7afd099694e 100644 --- a/content/ja/integrations/hasura_cloud.md +++ b/content/ja/integrations/hasura_cloud.md @@ -28,8 +28,8 @@ author: categories: - クラウド - ログの収集 -- トレーシング -custom_kind: integration +- tracing +custom_kind: インテグレーション dependencies: - https://github.com/DataDog/integrations-extras/blob/master/hasura_cloud/README.md display_on_public_website: true @@ -95,7 +95,7 @@ Hasura Cloud プロジェクトのログ、メトリクス、トレースは、 ## 収集データ ### メトリクス -{{< get-metrics-from-git "hasura-cloud" >}} +{{< get-metrics-from-git "hasura_cloud" >}} ### サービスチェック @@ -112,6 +112,6 @@ Hasura Cloud インテグレーションには、イベントは含まれませ [1]: https://hasura.io/cloud/ [2]: https://hasura.io/docs/latest/observability/integrations/datadog/ -[3]: http://app.datadoghq.com/logs +[3]: https://app.datadoghq.com/logs [4]: https://docs.datadoghq.com/ja/logs/explorer/facets/#create-facets -[5]: https://docs.datadoghq.com/ja/help/ +[5]: https://docs.datadoghq.com/ja/help/ \ No newline at end of file diff --git a/content/ja/integrations/hcp_vault.md b/content/ja/integrations/hcp_vault.md index ae8fcde0f27ee..7c3118b3498c9 100644 --- a/content/ja/integrations/hcp_vault.md +++ b/content/ja/integrations/hcp_vault.md @@ -23,7 +23,7 @@ author: sales_email: help@datadoghq.com support_email: help@datadoghq.com categories: [] -custom_kind: integration +custom_kind: インテグレーション dependencies: - https://github.com/DataDog/integrations-extras/blob/master/hcp_vault/README.md display_on_public_website: true @@ -123,4 +123,4 @@ HCP Vault インテグレーションには、イベントは含まれません [3]: https://cloud.hashicorp.com/docs/hcp/access-control [4]: https://raw.githubusercontent.com/DataDog/integrations-extras/master/hcp_vault/images/metrics-streaming.png [5]: https://raw.githubusercontent.com/DataDog/integrations-extras/master/hcp_vault/images/choose-provider.png -[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/ibm_i.md b/content/ja/integrations/ibm_i.md index 8e77f60acc25a..a4835d7b18f22 100644 --- a/content/ja/integrations/ibm_i.md +++ b/content/ja/integrations/ibm_i.md @@ -120,7 +120,7 @@ IBM i ODBC ドライバーの名前は、IBM i のチェックを構成するた ## 収集データ ### メトリクス -{{< get-metrics-from-git "ibm-i" >}} +{{< get-metrics-from-git "ibm_i" >}} ### イベント diff --git a/content/ja/integrations/jlcp_sefaz.md b/content/ja/integrations/jlcp_sefaz.md new file mode 100644 index 0000000000000..f8c27a2ba333e --- /dev/null +++ b/content/ja/integrations/jlcp_sefaz.md @@ -0,0 +1,123 @@ +--- +algolia: + subcategory: Marketplace インテグレーション +app_id: jlcp-sefaz +app_uuid: fc85f52c-08c0-48bc-9617-6950707c8f91 +assets: + dashboards: + JLCPSefaz_CompactView: assets/dashboards/JLCPSefaz_CompactView.json + JLCPSefaz_DetailedView: assets/dashboards/JLCPSefaz_DetailedView.json + JLCPSefaz_Overview: assets/dashboards/JLCPSefaz_Overview.json + integration: + auto_install: false + configuration: + spec: assets/configuration/spec.yaml + events: + creates_events: false + metrics: + check: + - sefaz.can_connect + - sefaz.response_time + metadata_path: metadata.csv + prefix: sefaz. + service_checks: + metadata_path: assets/service_checks.json + source_type_id: 15205183 + source_type_name: JLCP Sefaz + monitors: + Authorizer Service is down: assets/monitors/metric_monitor.json +author: + homepage: https://www.jlcp.com.br/ + name: JLCP + sales_email: contato@jlcp.com.br + support_email: contato@jlcp.com.br + vendor_id: jlcp +categories: +- alerting +- marketplace +custom_kind: integration +dependencies: [] +display_on_public_website: true +draft: false +git_integration_title: jlcp_sefaz +integration_id: jlcp-sefaz +integration_title: Sefaz +integration_version: '' +is_public: true +legal_terms: + eula: assets/eula.pdf +manifest_version: 2.0.0 +name: jlcp_sefaz +pricing: +- billing_type: flat_fee + includes_assets: true + product_id: jlcp-sefaz + short_description: ブラジル全州を監視 + unit_price: 100.0 +public_title: Sefaz +short_description: ブラジル各州の SEFAZ サービスを監視 +supported_os: +- linux +- windows +- macos +tile: + changelog: CHANGELOG.md + classifier_tags: + - Supported OS::Linux + - Supported OS::Windows + - Supported OS::macOS + - Category::Alerting + - Category::Marketplace + - Offering::Integration + - Submitted Data Type::Metrics + configuration: README.md#Setup + description: ブラジル各州の SEFAZ サービスを監視 + media: + - caption: 'JLCP: Sefaz 概要' + image_url: images/JLCPSefaz_Overview.png + media_type: image + - caption: 'JLCP: Sefaz コンパクト ビュー' + image_url: images/JLCPSefaz_CompactView.png + media_type: image + - caption: 'JLCP: Sefaz 詳細ビュー' + image_url: images/JLCPSefaz_DetailedView.png + media_type: image + overview: README.md#Overview + support: README.md#Support + title: Sefaz + uninstallation: README.md#Uninstallation +--- + + + + +## 概要 + +JLCP Sefaz インテグレーションは、ブラジル各州で電子インボイス (NF-e) 向けのサービスを提供する Secretaria de Estado da Fazenda (SEFAZ) を監視します。SEFAZ は税務管理と電子会計文書の発行を担っており、これらはブラジルにおける財務管理と商取引の適法性に不可欠です。 + +このインテグレーションは、NF-e サービスの可用性ステータス (OK、WARNING、CRITICAL など) と各サービスの応答時間に関するテレメトリー データを収集します。 + +監視対象サービスは次のとおりです: +- nfe_inutilizacao: NF-e 番号の無効化 +- nfe_consulta_protocolo: NF-e プロトコルの照会 +- nfe_status_servico: NF-e サービスステータスの照会 +- nfe_consulta_cadastro: 納税者登録の照会 +- nfe_recepcao_evento: NF-e イベントの受信 +- nfe_autorizacao: NF-e 発行の承認 +- nfe_ret_autorizacao: NF-e 承認結果の取得 +- nfe_distribuicao_dfe: 電子会計文書の配布 + +##### お客様へのメリット + +このインテグレーションにより、ブラジルで電子インボイス (NF-e) を発行するうえで不可欠な NF-e サービスの健全性を、包括的かつプロアクティブに可視化できます。可用性やパフォーマンスの問題を迅速に特定・解決し、商取引を継続しながら税務要件を確実に満たせます。詳細な可視化とパフォーマンス分析により、プロセス最適化、インフラ容量計画、ダウンタイム削減が可能となり、運用効率と顧客満足度が向上します。 + +## サポート + +サポートや機能追加のご要望は [contato@jlcp.com.br][3] までご連絡ください。対応言語: 英語、スペイン語、ポルトガル語。 + +[1]: https://docs.datadoghq.com/ja/agent/guide/agent-commands/ +[2]: https://docs.datadoghq.com/ja/agent/guide/agent-configuration-files/#agent-configuration-directory +[3]: mailto:contato@jlcp.com.br + +--- +本アプリケーションは Datadog Marketplace を通じて提供され、Datadog テクノロジーパートナーによってサポートされています。ご利用の際は、Marketplace で本アプリケーションを購入してください。 \ No newline at end of file diff --git a/content/ja/integrations/komodor_license.md b/content/ja/integrations/komodor_license.md index 8d99963359ba7..45ba75000dfdd 100644 --- a/content/ja/integrations/komodor_license.md +++ b/content/ja/integrations/komodor_license.md @@ -16,7 +16,7 @@ categories: - 問題追跡 - kubernetes - マーケットプレイス -custom_kind: integration +custom_kind: インテグレーション dependencies: [] display_on_public_website: true draft: false @@ -93,6 +93,6 @@ Datadog マーケットプレイスでのご提供には、Komodor プラット Komodor では、お客様の成功に必要なツールと情報の提供をお約束します。そのため、必要なときに必要なサポートを受けられるよう、以下のとおり複数の方法をご用意しています。Komodor アプリケーション内（右下のお問い合わせボタン）からメッセージを送信、ドキュメントで必要な情報を見つける、あるいは [support@komodor.com](mailto:support@komodor.com) までメールを送信しサポートチケットを作成してください。 -[1]: /ja/integrations/komodor +[1]: https://app.datadoghq.com/integrations/komodor --- -このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。このアプリケーションを購入するには、こちらをクリックしてください。 +このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。利用するには、Marketplace でこのアプリケーションを購入してください。 \ No newline at end of file diff --git a/content/ja/integrations/microsoft-teams.md b/content/ja/integrations/microsoft-teams.md new file mode 100644 index 0000000000000..a5816a5b3dcdc --- /dev/null +++ b/content/ja/integrations/microsoft-teams.md @@ -0,0 +1,850 @@ +--- +aliases: +- /ja/integrations/microsoft_teams +app_id: microsoft-teams +categories: +- collaboration +- network +- notifications +custom_kind: integration +description: Microsoft Teams は Office 365 における、ユーザー、コンテンツ、ツールを統合するチャット ベースのワーク スペースです。 +media: [] +title: Microsoft Teams +--- +## 概要 + +Microsoft Teams と統合して、以下のことができます。 + +{{< site-region region="us,us3,us5,eu,ap1,ap2" >}} + +- Microsoft Teams で Datadog アラートとイベントの通知を受信 +- Microsoft Teams の中からインシデントを管理することができます。 +- Microsoft Teams から直接トリガーされたモニターをミュートします。 + {{< /site-region >}} + +{{< site-region region="gov" >}} + +- Microsoft Teams で Datadog アラートとイベントの通知を受信 +- Microsoft Teams から直接トリガーされたモニターをミュートします。 + {{< /site-region >}} + +{{< site-region region="gov" >}} +**注**: お使いの Datadog アカウントはセキュアな US1-FED 環境でホストされていますが、Microsoft Teams 環境のセキュリティ (アクセス、権限、データ保護を含む) の管理はお客様の責任です。 +{{< /site-region >}} + +## セットアップ + +{{< tabs >}} + +{{% tab "Datadog アプリ (推奨)" %}} + +### Microsoft Teams チャンネルへのモニター通知の送信 + +Microsoft のテナントを Datadog に接続します。 + +1. Datadog で、[**Integrations > Microsoft Teams**](https://app.datadoghq.com/integrations/microsoft-teams) に移動します。 +1. **Add Tenant** をクリックすると、Microsoft に移動します。 +1. 画面の指示に従って、**OK** をクリックします。 + +{{< site-region region="us,us3,us5,eu,ap1,ap2" >}} +Datadog の通知を受信したいすべてのチームに Datadog アプリを追加済みであることを確認します。 +{{< /site-region >}} + +{{< site-region region="gov" >}} +Datadog の通知を受信したいすべてのチームに Datadog for Government アプリを追加済みであることを確認します。 +{{< /site-region >}} + +{{< site-region region="us,us3,us5,eu,ap1,ap2" >}} + +1. Microsoft Teams を開きます。 +1. 垂直ツールバーの **Apps** をクリックします。 +1. "Datadog" を検索し、**Open** をクリックします。 +1. 開いたモーダルで、アプリを追加するチームのプライマリ チャネルを選択します。インストールを完了するには、**Go** をクリックします。 + {{< /site-region >}} + +{{< site-region region="gov" >}} + +1. Microsoft Teams を開きます。 +1. 垂直ツールバーの **Apps** をクリックします。 +1. "Datadog for Government" を検索し、**Open** をクリックします。 +1. 開いたモーダルで、アプリを追加するチームのプライマリ チャネルを選択します。インストールを完了するには、**Go** をクリックします。 + {{< /site-region >}} + +{{< site-region region="us,us3,us5,eu,ap1,ap2" >}} +{{< img src="integrations/microsoft_teams/microsoft_teams_add_app_to_team.png" alt="Microsoft Teams でアプリをチームに追加" >}} +{{< /site-region >}} + +{{< site-region region="gov" >}} +{{< img src="integrations/microsoft_teams/microsoft_teams_add_gov_app_to_team.png" alt="Microsoft Teams でアプリをチームに追加" >}} +{{< /site-region >}} + +ボットをチームに追加したら、Datadog で通知ハンドルを構成します。 + +1. 構成されたテナントの下で、**Add Handle** をクリックします。ハンドルに名前を付け、ドロップダウンメニューから希望のチームとチャンネルを選択し、**Save** をクリックします。 + +### 旧来コネクタのテナントベースインテグレーションへの移行 + +Microsoft は、Microsoft Teams 向け Office 365 コネクタの非推奨化を発表しました。これには次の影響があります: + +- すべての Datadog コネクタは 2025 年 1 月 31 日に機能しなくなります。 +- [更新済み URL](https://learn.microsoft.com/en-us/microsoftteams/m365-custom-connectors#update-connectors-url) のない Incoming Webhook コネクタは 2025 年 1 月 31 日に機能しなくなります。 +- すべてのコネクタは 2025 年 12 月 31 日に機能しなくなります (以前は 2024 年 10 月 1 日)。 + +詳細は、Microsoft の [ブログ記事](https://devblogs.microsoft.com/microsoft365dev/retirement-of-office-365-connectors-within-microsoft-teams/) を参照してください。 + +レガシーな Office 365 コネクタを現在使用している通知ハンドルを Datadog のテナント ベースのインテグレーションに移行するには: + +{{< site-region region="us,us3,us5,eu,ap1,ap2" >}} + +1. [セットアップ手順](#setup) に従って Microsoft テナントを Datadog に接続します。 +1. レガシーな Office 365 コネクタが構成されているすべてのチームに Datadog アプリを追加します。 +1. [Microsoft Teams Integration Tile](https://app.datadoghq.com/integrations/microsoft-teams) 内の各レガシー通知コネクタ ハンドルについて: + 1. 構成済みのテナントで **Add Handle** をクリックします。 + 1. 新しいハンドルに、コネクタハンドルと同じ名前を付けます。例えば、旧来のコネクタハンドルの名前が `channel-123` の場合、テナント構成に `channel-123` という名前で新しいハンドルを作成します。 + 1. 旧来のコネクタハンドルがメッセージを送信していたドロップダウンメニューから希望するチームとチャンネルを選択し、**Save** をクリックします。この新しいハンドルは既存の旧来のコネクタハンドルをオーバーライドします。 + +{{< /site-region >}} + +{{< site-region region="gov" >}} + +1. [セットアップ手順](#setup) に従って Microsoft テナントを Datadog に接続します。 +1. レガシーな Office 365 コネクタが構成されているすべてのチームに Datadog for Government アプリを追加します。 +1. [Microsoft Teams Integration Tile](https://app.datadoghq.com/integrations/microsoft-teams) 内の各レガシー通知コネクタ ハンドルについて: + 1. 構成済みのテナントで **Add Handle** をクリックします。 + 1. 新しいハンドルに、コネクタハンドルと同じ名前を付けます。例えば、旧来のコネクタハンドルの名前が `channel-123` の場合、テナント構成に `channel-123` という名前で新しいハンドルを作成します。 + 1. 旧来のコネクタハンドルがメッセージを送信していたドロップダウンメニューから希望するチームとチャンネルを選択し、**Save** をクリックします。この新しいハンドルは既存の旧来のコネクタハンドルをオーバーライドします。 + +{{< /site-region >}} + +### Usage + +Datadog モニターから、[`@-notification` 機能](https://app.datadoghq.com/integrations/microsoft-teams) を使用して Microsoft Teams に通知を送信します。通知はアドレス `@teams-` 宛てに送信します。`` は Microsoft Teams ハンドル名に置き換えます。Microsoft Teams からトリガーされたモニターをミュートするには、**Mute Monitor** をクリックし、**Mute Duration** を選択して、**Mute** をクリックします。 + +#### ユーザー メンション + +ユーザー メンションを使用すると、モニターのアラートがトリガーされたときに Microsoft Teams のチャネルで特定のユーザーに通知できます。これにより、重要なイベントについて適切な担当者に確実に通知できます。特定のユーザーにメンションするには、以下の手順に従ってユーザー プリンシパル名 (UPN) を見つけます。 + +**構文**: `{User Principal Name}` + +**例**: `user@microsoft.com` + +**完全な通知例**: `@teams-CHANNEL_NAME user@microsoft.com another.user@microsoft.com` + +**ユーザーのユーザー プリンシパル名 (UPN) を見つけるには:** + +1. **方法 1 (UPN がメール アドレスと一致する場合のみ有効):** + + - Microsoft Teams で、そのユーザーのプロフィール写真または名前をクリックして、連絡先カードを開きます。 + - `Chat` フィールドに表示されるメール アドレスは、多くの場合 UPN です。異なる場合は、以下の 方法 2 を使用します。 + +1. **方法 2 (常に有効ですが、Azure Portal の権限が必要):** + + - [Microsoft Azure Portal](https://portal.azure.com) にサインインします。 + - `Microsoft Entra ID` > `Manage` > `Users` に移動します。 + - リストで該当ユーザーを見つけ、`User principal name` 列から UPN をコピーします。 + +確実な配信を確認するため、Datadog はモニター通知のテストを推奨します。手順については、[通知のテスト](https://docs.datadoghq.com/monitors/notify/#test-notifications) を参照してください。 + +#### ダッシュボード + +任意のチームまたはチャットにダッシュボード ウィジェットのスナップショットを投稿できます。サポートされるウィジェットの一覧については、[スケジュール済みレポート](https://docs.datadoghq.com/dashboards/sharing/scheduled_reports/) を参照してください。 + +Teams でダッシュボードウィジェットを共有するには + +1. Datadog でダッシュボードウィジェットにカーソルを合わせ、`CMD + C` または `CTRL + C` を押すか、共有メニューから **Copy** ボタンをクリックします。 +1. リンクを Teams に貼り付けます。 + +{{< site-region region="us,us3,us5,eu,ap1,ap2" >}} +{{< img src="integrations/microsoft_teams/dashboard_share.png" alt="Microsoft Teams でダッシュボード ウィジェットを共有">}} +{{< /site-region >}} + +{{< site-region region="gov" >}} +{{< img src="integrations/microsoft_teams/dashboard_share_gov.png" alt="Microsoft Teams でダッシュボード ウィジェットを共有">}} +{{< /site-region >}} + +### 編集アクセス権の制限 + +既定では、接続済みの Microsoft Teams テナントに対して、すべてのユーザーにフル アクセスが付与されています。 + +特定のテナントを編集できるロールを制限するには、[きめ細かなアクセス制御](https://docs.datadoghq.com/account_management/rbac/granular_access/) を使用します: + +1. テナントを表示している間に、右上の歯車アイコンをクリックして設定メニューを開きます。 +1. **Permissions** を選択します。 +1. **Restrict Access** をクリックします。ダイアログボックスが更新され、組織のメンバーはデフォルトで **Viewer** アクセス権を持っていることが表示されます。 +1. ドロップダウンを使用して、Microsoft Teams テナントを編集できる 1 つ以上のロール、チーム、またはユーザーを選択します。 +1. **Add** をクリックします。ダイアログ ボックスが更新され、選択したロールに **Editor** 権限が付与されたことが表示されます。 +1. **Save** をクリックします。 + +**注:** テナントに対する編集アクセスを維持するには、保存前に自分が所属するロールを少なくとも 1 つ含める必要があります。 + +編集アクセスがある場合、以下の手順を完了することで、制限されたテナントへの一般アクセスを復元できます: + +1. テナントを表示中に、右上の歯車アイコンをクリックして設定メニューを開きます。 +1. **Permissions** を選択します。 +1. **Restore Full Access** をクリックします。 +1. **Save** をクリックします。 + +{{% /tab %}} + +{{% tab "Microsoft Workflows Webhooks" %}} + +### Microsoft Workflows Webhooks とは何ですか？ + +Workflows / Power Automate は、自動化されたワークフローを作成するための Microsoft 製品です。Microsoft Workflows を使用すると、Incoming Webhook で通知を送信できます。推奨は Microsoft Teams テナントへの Datadog アプリのインストールですが、インストールできない場合やプライベート チャネルに通知を送信したい場合は、Datadog ハンドルを構成して Microsoft Workflows 経由で Microsoft Teams のチャネルに通知を送信できます。このインテグレーションは、次の Microsoft Workflows テンプレートでの使用を想定しています: [Webhook リクエストを受信したときにチャネルに投稿](https://make.preview.powerautomate.com/galleries/public/templates/d271a6f01c2545a28348d8f2cddf4c8f/post-to-a-channel-when-a-webhook-request-is-received) + +{{< img src="integrations/microsoft_teams/microsoft_teams_workflows_template.png" alt="Webhook リクエストを受信したときにチャネルに投稿 テンプレート" style="width:30%;" >}} + +### レガシー コネクタを Microsoft Workflows Webhooks インテグレーションに移行しますか？ + +Microsoft は、Microsoft Teams 向け Office 365 コネクタの非推奨化を[発表しました](https://devblogs.microsoft.com/microsoft365dev/retirement-of-office-365-connectors-within-microsoft-teams/)。既存のコネクタ URL は 2025 年 1 月 31 日に動作を停止します。Microsoft は、レガシー コネクタの代替として Microsoft Workflows の incoming webhooks の使用を推奨しています。現在レガシー Office 365 コネクタを使用しているすべての通知ハンドルを Datadog の Microsoft Workflows webhooks インテグレーションに移行するには、以下の手順に従ってください。 + +Microsoft Teams インテグレーション タイル内の各レガシー コネクタ ハンドルについて: + +1. [セットアップ手順](#create-a-microsoft-workflows-webhook) に従って、目的の Microsoft Teams チャネル向けのワークフロー Webhook ハンドルを作成します。 +1. Microsoft Workflows Webhooks セクションで、新しいハンドルに置き換える対象のコネクタ ハンドルと同じ名前を付けます。たとえば、レガシー コネクタ ハンドル名が `channel-123` の場合、Microsoft Workflows Webhooks セクションで新しいハンドルにも `channel-123` という名前を付けます。この新しいハンドルが既存のレガシー コネクタ ハンドルを上書きします。 + +### Microsoft Workflows Webhook を作成する + +#### 前提条件 + +- 新しいワークフローを作成する際、ワークフローの所有およびチャネルへの通知送信の双方に Microsoft アカウントが必要です (同一の Microsoft アカウントである必要はありません)。 +- ワークフローを所有するアカウント (以下の手順 2 で構成) が、ワークフローの編集および更新を行えるアカウントです。共有アクセス性を高めるには、サービス アカウントの使用を推奨します。 +- チャネルに通知を送信するアカウント (以下の手順 8 で構成) は、そのアカウントのユーザーとして投稿します。このアカウントは、通知を送信したいチームのメンバーである必要があります。プライベート チャネルに通知を送信する場合は、このアカウントをチャネルにも追加する必要があります。このアカウントに「Datadog Notifications」のような名前を付けたい場合は、サービス アカウントを使用してください。 + +#### 手順 + +**注:** これらの手順の多くは Microsoft Workflows 側での操作です。Microsoft が Workflows を更新すると、以下の手順は最新の変更を反映していない場合があります。 + +1. Microsoft Teams で、[Workflows アプリ](https://teams.microsoft.com/l/app/c3a1996d-db0f-4857-a6ea-7aabf0266b00?source=app-details-dialog) を通知したいすべてのチームに追加します。チームにアプリを追加できない場合は、以下の "Private channels" セクションの手順に従ってください。 + {{< img src="integrations/microsoft_teams/microsoft_teams_workflows_step_1.png" alt="手順 1" style="width:90%;" >}} +1. Microsoft の [Webhook リクエストを受信したときにチャネルに投稿](https://make.preview.powerautomate.com/galleries/public/templates/d271a6f01c2545a28348d8f2cddf4c8f/post-to-a-channel-when-a-webhook-request-is-received) テンプレートから、Power Automate で新しいワークフローを作成します。 +1. ワークフローの所有に使用する Microsoft アカウントを選択します (共有アクセスを容易にするため、サービス アカウントの使用を推奨)。その後、**Continue** をクリックします。 + {{< img src="integrations/microsoft_teams/microsoft_teams_workflows_step_3.png" alt="手順 3" style="width:90%;" >}} +1. **Edit in advanced mode** をクリックします。 + {{< img src="integrations/microsoft_teams/microsoft_teams_workflows_step_4.png" alt="手順 4" style="width:90%;" >}} +1. **Send each adaptive card** を展開し、**Post card in a chat or channel** をクリックします。 + {{< img src="integrations/microsoft_teams/microsoft_teams_workflows_template_dropdown_step_5.png" alt="手順 5" style="width:90%;" >}} +1. **Post As** のドロップ ダウンで **Post as** を **Flow bot** に設定します。通知は「`` via Workflows」から送信されたように表示されます。これらの通知を受信するには、Workflows アプリケーションを目的のチームに追加する必要があります。プライベート チャネルに通知を送信する場合は、**Post As** をそのチャネル内のユーザーに設定する必要があります。詳細は下記の "Private channels" セクションを参照してください。**注:** **Post as** を変更すると、**Post in** フィールドがリセットされます。 + {{< img src="integrations/microsoft_teams/microsoft_teams_workflows_step_6.png" alt="手順 6" style="width:90%;" >}} +1. チームおよびチャネルのドロップ ダウンにアクセスするには、@ 記号を削除するか、**X** アイコンをクリックして取り除きます。 + {{< img src="integrations/microsoft_teams/microsoft_teams_workflows_step_7.png" alt="手順 7" style="width:90%;" >}} +1. ドロップ ダウンを使用して、目的のチームとチャネルを選択します。 + {{< img src="integrations/microsoft_teams/microsoft_teams_workflows_step_8.png" alt="手順 8" style="width:90%;" >}} +1. 通知送信用に意図した Microsoft アカウント (例: "Datadog Notifications" という名前のサービス アカウント) にワークフローが接続されていることを確認します。通知は「`` through Workflows」から送信されたように表示されます。このアカウントは、構成済みの Microsoft Teams チャネルにアクセスできる必要があります。アカウントを変更するには、**Change connection** をクリックし、表示に従って別の Microsoft アカウントを構成します。 + {{< img src="integrations/microsoft_teams/microsoft_teams_workflows_step_9.png" alt="手順 9" style="width:90%;" >}} +1. **Save** ボタンをクリックします。 + {{< img src="integrations/microsoft_teams/microsoft_teams_workflows_step_10.png" alt="手順 10" style="width:90%;" >}} +1. Webhook リンクを見つけるには、ワークフローの最初のブロックをクリックします。 + {{< img src="integrations/microsoft_teams/microsoft_teams_workflows_step_11.png" alt="手順 11" style="width:50%;" >}} +1. **Anyone** がフローをトリガーできることを確認し、リンクをコピーします。 + {{< img src="integrations/microsoft_teams/microsoft_teams_workflows_step_12.png" alt="手順 12" style="width:90%;" >}} +1. **Back** ボタンをクリックして、ワークフローのダッシュボードに移動します。 + {{< img src="integrations/microsoft_teams/microsoft_teams_workflows_step_13.png" alt="手順 13" style="width:90%;" >}} +1. ダッシュボードで、ワークフローがオンになっていることを確認します。オフの場合は、"Turn on" ボタンをクリックします。 + {{< img src="integrations/microsoft_teams/microsoft_teams_workflows_step_14.png" alt="手順 14" style="width:90%;" >}} +1. Datadog で、[**Integrations > Microsoft Teams**](https://app.datadoghq.com/integrations/microsoft-teams) に移動します。 +1. Configuration タブで Microsoft Workflows Webhooks セクションに進み、**Add Handle** をクリックします。ハンドルに名前を付け (レガシー コネクタ ハンドルから移行する場合は、対応するコネクタ ハンドルと同じ名前を使用)、Webhook URL を貼り付けます。 +1. **Save** をクリックします。 + +### プライベート チャネル + +プライベート チャネルに通知を送信するには、**Post Card to chat or channel** ブロック内で構成されたアカウントがそのチャネルにアクセスできる必要があります。これにより、ワークフローはそのユーザー アカウントの代理として通知を送信できます。 + +1. **Post Card to chat or channel** ブロック内で、**Post as** を **User** に変更します。 + {{< img src="integrations/microsoft_teams/microsoft_teams_workflows_private_channels_step_1.png" alt="プライベート チャネルの手順 1" style="width:30%;" >}} +1. 次に、アカウントを選択するため **Change connection** をクリックし、表示に従ってアカウントを変更します。 + {{< img src="integrations/microsoft_teams/microsoft_teams_workflows_private_channels_step_2.png" alt="プライベート チャネルの手順 2" style="width:90%;" >}} + +### 制限 + +- Microsoft 365 のお客様は、成功したトリガーが 90 日間発生しない場合、ワークフローは自動的にオフになります。ワークフローの有効期限が近づくと、Microsoft はワークフローの所有者アカウントにメールを送信します。この 90 日のタイマーは、Microsoft Workflows 内でテストを実行することでリセットできます。 + +- テンプレートを使用している場合、すべてのメッセージの末尾に、ワークフローの作成者とテンプレートへのリンクを示す 1 行のテキストが追加されます。 + {{< img src="integrations/microsoft_teams/microsoft_teams_workflows_used_a_template.png" alt="テンプレートを使用" style="width:90%;" >}} + + これを削除するには、対象のワークフローを開いて **Save As** をクリックしてコピーを作成し、**My Flows** 内でそのコピーを見つけて開き、元のワークフローではなくコピーしたワークフローの新しい Webhook を使用します。 + +- Microsoft Workflows は、投稿するメッセージに対するインタラクティブな機能 (Microsoft Teams から直接モニターをミュートするなど) をサポートしません。 + +- Microsoft Workflows は、共有チャネルをサポートしません。 + +- Microsoft Workflows では、**Post as** を **User** に設定して Workflows Webhook を投稿する場合、ユーザー メンションはサポートされません。 + +### Usage + +Datadog モニターから、[`@-notification` 機能](https://make.preview.powerautomate.com/galleries/public/templates/d271a6f01c2545a28348d8f2cddf4c8f/post-to-a-channel-when-a-webhook-request-is-received) を使用して Microsoft Teams に通知を送信します。通知はアドレス `@teams-` 宛てに送信します。`` は Microsoft Teams ハンドル名に置き換えます。 + +#### Microsoft Workflows Webhooks ハンドルでのユーザー メンション + +ユーザー メンションを使用すると、モニターのアラートがトリガーされたときに Microsoft Teams のチャネルで特定のユーザーに通知できます。これにより、重要なイベントについて適切な担当者に確実に通知できます。特定のユーザーにメンションするには、以下の手順に従ってユーザー プリンシパル名 (UPN) を見つけます。 + +**構文**: `{User Principal Name}` + +**例**: `user@microsoft.com` + +**完全な通知例**: `@teams-CHANNEL_NAME user@microsoft.com another.user@microsoft.com` + +**ユーザーのユーザー プリンシパル名 (UPN) を見つけるには:** + +1. **方法 1 (UPN がメール アドレスと一致する場合のみ有効):** + + - Microsoft Teams で、そのユーザーのプロフィール写真または名前をクリックして連絡先カードを開きます。 + - `Chat` フィールドに表示されるメール アドレスは、多くの場合 UPN です。異なる場合は、以下の 方法 2 を使用します。 + +1. **方法 2 (常に有効ですが、Azure Portal の権限が必要):** + + - [Microsoft Azure Portal](https://portal.azure.com) にサインインします。 + - `Microsoft Entra ID` > `Manage` > `Users` に移動します。 + - リストで該当ユーザーを見つけ、`User principal name` 列から UPN をコピーします。 + +
プライベート チャネル向けに User として投稿される Workflows Webhook ハンドルでは、ユーザー メンションはサポートされません。Workflows Webhook を User として投稿する際にユーザー メンションを含めると失敗します。Workflows Webhooks でユーザー メンションを使用するには、Flow Bot を使用する必要があります。
+ +確実な配信を確認するため、Datadog はモニター通知のテストを推奨します。手順については、[通知のテスト](https://docs.datadoghq.com/monitors/notify/#test-notifications) を参照してください。 + +### 編集アクセス権の制限 + +既定では、すべてのユーザーに各 Microsoft Workflows Webhook ハンドルへのフル アクセスが付与されています。 + +特定の Workflows Webhook ハンドルを編集できるロールを制限するには、[きめ細かなアクセス制御](https://docs.datadoghq.com/account_management/rbac/granular_access/) を使用します: + +1. **Workflows Webhooks** を表示中に、対象のハンドルにカーソルを合わせて、行の右側にアクションを表示します。 +1. **Permissions** と表示された鍵アイコンをクリックします。 +1. **Restrict Access** をクリックします。ダイアログボックスが更新され、組織のメンバーはデフォルトで **Viewer** アクセス権を持っていることが表示されます。 +1. ドロップ ダウンを使用して、その Workflows Webhook ハンドルを編集できる 1 つ以上のロール、チーム、またはユーザーを選択します。 +1. **Add** をクリックします。ダイアログ ボックスが更新され、選択したロールに **Editor** 権限が付与されたことが表示されます。 +1. **Save** をクリックします。 + +**注:** Workflows Webhook ハンドルに対する自分の編集アクセスを維持するには、保存前に自分が所属するロールを少なくとも 1 つ含める必要があります。 + +編集アクセスがある場合、以下の手順を完了することで、制限された Workflows Webhook ハンドルへの一般アクセスを復元できます: + +1. **Workflows Webhooks** を表示中に、制限されたハンドルにカーソルを合わせて、行の右側にアクションを表示します。 +1. **Permissions** と表示された鍵アイコンをクリックします。 +1. **Restore Full Access** をクリックします。 +1. **Save** をクリックします。 + +API 経由で Workflows Webhooks の権限を編集するには: + +1. [Microsoft Teams Integration API](https://docs.datadoghq.com/api/latest/microsoft-teams-integration/#get-all-workflows-webhook-handles) を使用して、Workflows Webhooks の ID を取得します。 +1. [Restriction Policies API](https://docs.datadoghq.com/api/latest/restriction-policies/) を使用します。Resource Type は `integration-webhook`、id は `microsoft-teams:` です。 + +{{% /tab %}} + +{{% tab "コネクタ (非推奨)" %}} + +### 旧来コネクタのテナントベースインテグレーションへの移行 + +Microsoft は、Microsoft Teams 向け Office 365 コネクタの非推奨化を発表しました。これには次の影響があります: + +- すべての Datadog コネクタは 2025 年 1 月 31 日に機能しなくなります。 +- [更新済み URL](https://learn.microsoft.com/en-us/microsoftteams/m365-custom-connectors#update-connectors-url) のない Incoming Webhook コネクタは 2025 年 1 月 31 日に機能しなくなります。 +- すべてのコネクタは 2025 年 12 月 31 日に機能しなくなります (以前は 2024 年 10 月 1 日)。 + +詳細は、Microsoft の [ブログ記事](https://devblogs.microsoft.com/microsoft365dev/retirement-of-office-365-connectors-within-microsoft-teams/) を参照してください。 + +レガシーな Office 365 コネクタを現在使用しているすべての通知ハンドルを、テナント ベースの Datadog アプリに移行するには: + +{{< site-region region="us,us3,us5,eu,ap1,ap2" >}} + +1. [セットアップ手順](https://docs.datadoghq.com/integrations/microsoft-teams/?tab=datadogapprecommended#setup) に従って、Microsoft テナントを Datadog に接続します。 +1. レガシー Office 365 コネクタが構成されているすべてのチームに Datadog アプリを追加します。 +1. [Microsoft Teams Integration Tile](https://app.datadoghq.com/integrations/microsoft-teams) 内の各レガシー通知コネクタ ハンドルについて: + 1. 構成済みのテナントで **Add Handle** をクリックします。 + 1. 新しいハンドルに、コネクタハンドルと同じ名前を付けます。例えば、旧来のコネクタハンドルの名前が `channel-123` の場合、テナント構成に `channel-123` という名前で新しいハンドルを作成します。 + 1. 旧来のコネクタハンドルがメッセージを送信していたドロップダウンメニューから希望するチームとチャンネルを選択し、**Save** をクリックします。この新しいハンドルは既存の旧来のコネクタハンドルをオーバーライドします。 + +{{< /site-region >}} + +{{< site-region region="gov" >}} + +1. [セットアップ手順](https://docs.datadoghq.com/integrations/microsoft-teams/?tab=datadogapprecommended#setup) に従って、Microsoft テナントを Datadog に接続します。 +1. レガシー Office 365 コネクタが構成されているすべてのチームに Datadog for Government アプリを追加します。 +1. [Microsoft Teams Integration Tile](https://app.datadoghq.com/integrations/microsoft-teams) 内の各レガシー通知コネクタ ハンドルについて: + 1. 構成済みのテナントで **Add Handle** をクリックします。 + 1. 新しいハンドルに、コネクタハンドルと同じ名前を付けます。例えば、旧来のコネクタハンドルの名前が `channel-123` の場合、テナント構成に `channel-123` という名前で新しいハンドルを作成します。 + 1. 旧来のコネクタハンドルがメッセージを送信していたドロップダウンメニューから希望するチームとチャンネルを選択し、**Save** をクリックします。この新しいハンドルは既存の旧来のコネクタハンドルをオーバーライドします。 + +{{< /site-region >}} + +### レガシー コネクタから Microsoft Workflows Webhooks インテグレーションに移行する + +Microsoft は、Microsoft Teams 向け Office 365 コネクタの非推奨化を発表しました。これには次の影響があります: + +- すべての Datadog コネクタは 2025 年 1 月 31 日に機能しなくなります。 +- [更新済み URL](https://learn.microsoft.com/en-us/microsoftteams/m365-custom-connectors#update-connectors-url) のない Incoming Webhook コネクタは 2025 年 1 月 31 日に機能しなくなります。 +- すべてのコネクタは 2025 年 12 月 31 日に機能しなくなります (以前は 2024 年 10 月 1 日)。 + +詳細は、Microsoft の [ブログ記事](https://devblogs.microsoft.com/microsoft365dev/retirement-of-office-365-connectors-within-microsoft-teams/) を参照してください。 + +現在レガシー Office 365 コネクタを使用しているすべての通知ハンドルを Datadog の Microsoft Workflows webhooks インテグレーションに移行するには、[Microsoft Workflows Webhooks](https://docs.datadoghq.com/integrations/microsoft-teams/?tab=microsoftworkflowswebhooks#what-are-microsoft-workflows-webhooks) を参照してください。 + +### コネクタのセットアップ (非推奨) + +
+レガシー通知ハンドルは、同じ @teams-HANDLE_NAME を使用しない限り新しいセットアップの影響を受けませんが、使用する場合は新しい構成がレガシー構成をオーバーライドします。 +
+ +1. チャンネルのリストで、チャンネル名の横にある `...` ボタンを選択し、**Connectors** を選択します。 + + {{< img src="integrations/microsoft_teams/microsoft_team_step_1_v2.png" alt="Microsoft Teams の手順 1" >}} + +1. Datadog を検索し、**Configure** をクリックします。 + + {{< img src="integrations/microsoft_teams/microsoft_team_step_2_v2.png" alt="Microsoft Teams の手順 2" >}} + +1. コネクタ構成モーダルで、Webhook URL をコピーします。 + +1. Datadog で、[**Integrations > Microsoft Teams**](https://app.datadoghq.com/integrations/microsoft-teams) に移動します。 + +1. Configuration タブで、**Add Handle** をクリックしてハンドルに名前を付け、webhook URL を貼り付けます。 + +1. コネクタ構成モーダルで、**Save** をクリックします。 + +{{% /tab %}} + +{{< /tabs >}} + +{{< site-region region="us,us3,us5,eu,ap1,ap2" >}} + +## Microsoft Teams における Datadog Incident Management + +### アカウント設定 + +まず、Microsoft Teams に Datadog アプリをインストールします: + +1. Microsoft Teams を開きます。 +1. 垂直ツールバーの **Apps** をクリックします。 +1. "Datadog" を検索し、**Open** をクリックします。 +1. 開いたモーダルで、アプリを追加するチームのプライマリ チャネルを選択します。インストールを完了するには **Go** をクリックします。 + {{< img src="integrations/microsoft_teams/microsoft_teams_add_app_to_team.png" alt="Microsoft Teams でアプリをチームに追加" >}} + +次に、Microsoft のテナントを Datadog に接続します。 + +1. Datadog で、[Microsoft Teams Integration Tile](https://app.datadoghq.com/integrations/microsoft-teams) に移動します。 +1. **Add Tenant** をクリックすると、Microsoft に移動します。 +1. 画面の指示に従って、**OK** をクリックします。 + +### 追加の権限の付与 + +一部の Datadog Incident Management 機能では、テナント上での操作 (例: インシデント用の新規チャネルの作成) を実行するための権限が必要です。Microsoft 組織を代表して同意を付与できる権限を持つ人物が、*Global Admin* ロールを割り当てられたユーザーなど、テナント全体の管理者同意を付与する必要があります。Datadog アプリケーションに対してテナント全体の管理者同意を付与できるのは誰かについては、[Microsoft Entra ID のドキュメント](https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/grant-admin-consent?pivots=ms-graph#prerequisites) を参照してください。 + +Datadog に対してアプリケーション権限と委任された権限の両方を付与するか、委任された権限のみを付与するかを選択できます。両方の権限を使用する方法は設定が容易で、委任された権限のみを使用する方法は、テナント内の Datadog アプリに対してよりきめ細かな制御を提供します。詳細は、[Microsoft の権限と同意の概要ドキュメント](https://docs.datadoghq.com/integrations/microsoft-teams/?tab=datadogapprecommended#setup) を参照してください。 + +{{< tabs >}} + +{{% tab "アプリケーション権限の使用" %}} + +1. Datadog で、[Microsoft Teams Integration Tile](https://app.datadoghq.com/integrations/microsoft-teams) に移動します。 +1. Incident Management を使用したいテナントで、右側の歯車アイコンをクリックします。 +1. **Grant application permissions** をクリックすると、Microsoft にリダイレクトされます。この手順は、テナント全体の管理者同意を付与できるユーザーが実行する必要があります。このユーザーは Datadog アカウントを保有している必要がありますが、その Datadog アカウントのメール アドレスは Microsoft アカウントのメール アドレスと一致している必要はありません。 +1. 画面の指示に従って、**OK** をクリックします。 + +{{% /tab %}} + +{{% tab "委任された権限の使用" %}} + +委任された権限を使用すると、Datadog は Microsoft Teams テナント内でユーザーとして動作できます。Datadog は、そのユーザーが実行できるあらゆる操作を行い、同ユーザーがアクセスできるリソースにアクセスできます。 + +まず、Datadog アプリに委任された権限を付与します: + +1. Datadog で、[Microsoft Teams Integration Tile](https://app.datadoghq.com/integrations/microsoft-teams) に移動します。 +1. Incident Management を使用したいテナントで、右側の歯車アイコンをクリックします。 +1. **Grant delegated permissions** をクリックすると、Microsoft にリダイレクトされます。この手順は、テナント全体の管理者同意を付与できるユーザーが実行する必要があります。このユーザーは Datadog アカウントを保有している必要がありますが、その Datadog アカウントのメール アドレスは Microsoft アカウントのメール アドレスと一致している必要はありません。 +1. 画面の指示に従って、**OK** をクリックします。 + +次に、Datadog が動作するサービス アカウントを作成します: + +1. Office 365 のサービス アカウント ユーザーを作成します。実際の Microsoft Teams ユーザーと区別して混乱を避けるため、このサービス アカウント ユーザーには 'Datadog' のような名前を付けることを Datadog は推奨します。 + +1. サービス アカウントに Microsoft Teams ライセンスを割り当てます。 + +1. インシデント レスポンスを管理したい各チームに、サービス アカウント ユーザーを追加します。これには、新しいインシデント チャネルが作成されるチームや、ユーザーがインシデントを宣言するチームが含まれます。 + +1. 各チームで次の権限が有効になっていることを確認します: + + - `Allow members to create and update channels` + - `Allow members to delete and restore channels` + - `Allow members to create, update, and remove tabs` + + これらの権限を有効にするには、チーム名の横の **...** をクリックし、**Manage Team** > **Settings** > **Member Permissions** を選択します。 + +最後に、最初の手順で作成したサービス アカウント ユーザーを接続します。 + +1. 作成したサービス アカウント ユーザーとしてログインしていることを確認します。**注:** サービス アカウント用に Datadog ユーザーを作成する必要はありません。また、このサービス アカウント ユーザーは、この手順を実行する Datadog ユーザーとは関連付けられていません。 +1. Datadog で、[Microsoft Teams Integration Tile](https://app.datadoghq.com/integrations/microsoft-teams) に移動します。 +1. Incident Management を使用したいテナントで、右側の歯車アイコンをクリックします。 +1. **Connect delegated user** をクリックすると、Microsoft にリダイレクトされます。**注:** この手順を実行するためにテナント全体の管理者である必要はありません。 +1. 画面の指示に従って、**OK** をクリックします。 + +#### リフレッシュ トークンに関する重要な注意 + +委任されたサービス アカウントを使用して Microsoft Teams を接続すると、Datadog はリフレッシュ トークンを使用して、繰り返しのログインなしにアクセスを維持します。サービス アカウントのパスワードが変更された場合、アカウントが無効化された場合、または Microsoft がトークンを失効させた場合、このトークンは無効になる可能性があります。 + +これらのトークンは 90 日後に期限切れになります。Datadog が委任ユーザーの代理でアクションを実行するたびに新しいトークンが発行されますが、委任ユーザーが 90 日間使用されない場合はトークンが失効し、インテグレーションは動作を停止します。 + +トークンが無効になったり期限切れになったりした場合は、機能を復旧するためにサービス アカウントを再接続する必要があります。 + +詳細は、Microsoft のドキュメント [Microsoft identity platform におけるリフレッシュ トークン](https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens) を参照してください。 + +{{% /tab %}} + +{{< /tabs >}} + +### ユーザー設定 + +Microsoft Teams から Datadog のアクションを実行するには、Datadog と Microsoft Team のアカウントを接続する必要があります。 + +Microsoft Teams からアカウントを接続するには + +1. Microsoft Teams を開きます。 + +1. 垂直ツールバーの `...` ボタンをクリックし、Datadog を選択すると、Datadog ボットとのチャットが開始されます。 + +1. "accounts" と入力し、エンターキーを押します。 + {{< img src="integrations/microsoft_teams/microsoft_teams_connect_account_from_teams.png" alt="Microsoft Teams からのアカウント接続" >}} + +1. Datadog ボットが、アカウントの接続方法について応答します。**Connect Datadog Account** をクリックします。 + +1. その後、Datadog ボットが、アカウントを接続するためのリンクが含まれたメッセージを送信します。リンクをクリックし、プロンプトに従います。 + +1. [Microsoft Teams Integration Tile](https://app.datadoghq.com/integrations/microsoft-teams) にリダイレクトされます。 + +1. [Microsoft Teams Integration Tile](https://app.datadoghq.com/integrations/microsoft-teams) 上のプロンプトで **Create** をクリックして、アプリケーション キーを作成します。 + +Datadog からアカウントを接続することも可能です。 + +1. Datadog で、[Microsoft Teams Integration Tile](https://app.datadoghq.com/integrations/microsoft-teams) に移動します。 +1. 表示されたテナントの中から、**Connect** をクリックします。 +1. 画面の指示に従って、**OK** をクリックします。 +1. 上記のプロンプトで **Create** をクリックして、[Microsoft Teams Integration Tile](https://app.datadoghq.com/integrations/microsoft-teams) からアプリケーション キーを作成します。 + +{{< img src="integrations/microsoft_teams/microsoft_teams_connect_account_from_datadog_v2.png" alt="Datadog Microsoft Teams インテグレーションタイルからアカウントを接続します" >}} + +### インシデントの使用方法 + +#### インシデント + +Microsoft Teams から新しいインシデントを宣言するには + +1. 任意のチームのチャネルで会話を開始するか、Datadog アプリとのチャットを開始します。 +1. `@Datadog incident` と入力します。 +1. アダプティブ カードが表示されます。**Declare Incident** ボタンをクリックして Datadog タブを開き、インシデントを宣言します。 + +インシデントを宣言するには、ユーザーは自分の Microsoft Teams アカウントを Datadog アカウントに接続する必要があります。 + +インシデントを更新するには、作成と同様の手順で行います。 + +1. インシデントチームにいながら、会話を始めます。 +1. `@Datadog` と入力するか、`...` ボタンで **Messaging extensions** メニューを開き、**Datadog** アプリを選択します。 +1. **Update Incident** を選択します。 +1. 希望の情報をフォームに入力します。 +1. **Update** をクリックします。 + +次を使用してオープン（アクティブで安定している）インシデントをリスト表示します。 + +``` +@Datadog list incidents +``` + +インシデントチーム内のメッセージの右端にある "More actions" メニューを使用すると、そのメッセージをインシデントタイムラインに送信することができます。 + +#### インシデントの更新チャンネル + +インシデント更新チャンネルを使用すると、関係者は Microsoft Teams から直接、すべてのインシデントのステータスを組織全体で確認することができます。これらのアップデートを投稿するチームとチャンネルをアカウントで選択すると、チャンネルは次の投稿を受け取ります。 + +- 新しく宣言されたインシデント。 +- 重要度、ステータスの移行、インシデントコマンダーへの変更点。 +- App 内のインシデントの Overview ページへのリンク。 +- インシデント専門チームへの参加リンク。 + +Microsoft Teams アプリがインストールされたら、**Incident Settings** ページに移動できます。ここから、**Incident Updates** Channel セクションまでスクロールダウンし、セットアップフローを開始することができます。 + +#### インシデントチャンネルの設定方法 + +1. [Incidents Settings](https://app.datadoghq.com/incidents/settings#Integrations) に移動します。 +1. Microsoft Teams セクションで、接続している Microsoft Teams テナントを選択します。 +1. **Automatically create a Microsoft Teams channel for every incident** (インシデントごとに Microsoft Teams チャンネルを自動的に作成する) をオンに切り替えます。 +1. 新しいチャンネルを自動的に作成するチームを選択します。 +1. 設定を保存します。 + +{{< img src="integration/microsoft_teams/ms_teams_incident_updates_v2.png" alt="Microsoft Teams インシデント更新チャンネル設定." >}} + +{{< /site-region >}} + +## 収集されたデータ + +### メトリクス + +Microsoft Teams インテグレーションは、メトリクスを提供しません。 + +### イベント + +Microsoft Teams インテグレーションには、イベントは含まれません。 + +### サービスチェック + +Microsoft Teams インテグレーションには、サービスのチェック機能は含まれません。 + +## 権限 + +Microsoft Teams インテグレーションは、追加されたチームに対して次の権限を受け取ります。詳細は、[Microsoft アプリの権限リファレンス](https://learn.microsoft.com/en-us/microsoftteams/app-permissions#what-can-apps-do-in-teams) を参照してください。 + +| 権限の説明 | リクエスト理由 | +| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | +| 私が提供するメッセージとデータを受信します。 | ユーザーは、Datadog アプリと個人チャットでやり取りすることができます。 | +| 私にメッセージや通知を送信します。 | ユーザーは、Datadog アプリと個人チャットでやり取りすることができます。 | +| 名前、メールアドレス、会社名、使用言語など、私のプロフィール情報にアクセスします。 | Datadog UI 内で Microsoft Teams の通知やワークフローを構成することができます。 | +| チームやチャットのメンバーがチャンネルやチャットで提供するメッセージやデータを受信します。 | ユーザーは、@Datadog コマンドを通して Datadog とやり取りすることができます。 | +| チャンネルやチャットでメッセージや通知を送信します。 | 構成されたターゲットに Datadog 通知を送信します。 | +| チームやチャットの情報 (チーム名やチャット名、チャンネルリスト、名簿 (チームやチャットメンバーの名前やメールアドレスを含む)) にアクセスし、それを使って連絡を取ることができます。 | ユーザーが Datadog 内で Microsoft Teams の通知やワークフローを構成できるようにします。 | + +{{< site-region region="us,us3,us5,eu,ap1,ap2" >}} + +Microsoft Teams インテグレーションで Incident Management 機能を使用するには、追加の権限が必要です。これらはテナント全体の権限を持つユーザーによって承認される必要があります (詳細な手順は [Datadog Incident Management in Microsoft Teams: アカウント セットアップ](#account-setup) を参照)。 +これらの権限の詳細は、[Microsoft Graph の権限リファレンス](https://learn.microsoft.com/en-us/graph/permissions-reference) を参照してください。 +{{< tabs >}} + +{{% tab "アプリケーション権限の使用" %}} + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
API / 権限名種類リクエスト理由
Channel.Createアプリケーション権限および委任された権限Datadog Incident Management を使用してインシデントを管理・復旧するためにチャネルを作成します。
Channel.Delete.Allアプリケーション権限および委任された権限指定した期間後にインシデント チャネルを自動アーカイブします。
ChannelMessage.Read.Allアプリケーション権限および委任された権限インシデント チャネルからインシデント タイムラインへ、タイムライン メッセージを自動同期します。
ChannelSettings.ReadWrite.Allアプリケーション権限および委任された権限Datadog Incident Management を使用してインシデントを復旧するため、チャネルを作成および変更します。
Directory.Read.All,GroupMember.Read.Allアプリケーション権限Datadog Incident Management の構成時に、チーム名およびチャネル名のオート コンプリート候補を提供します。
TeamsTab.Createアプリケーション権限および委任された権限Datadog アプリ用にチーム内にタブを作成します (この権限は今後の Microsoft Teams におけるインシデント宣言エクスペリエンスに必要です)。
OnlineMeetings.ReadWrite委任された権限Datadog アプリ用にチーム内で会議を自動作成します (この権限は今後の Microsoft Teams におけるインシデント宣言エクスペリエンスに必要です)。
TeamsAppInstallation. + ReadWriteSelfForTeam委任された権限Datadog アプリがチームのメンバーであるかどうかを確認できるようにします。
TeamsTab.Read.All委任された権限チャネルに Datadog タブが作成されているかどうかを確認します (この権限は今後の Microsoft Teams におけるインシデント宣言エクスペリエンスに必要です)。
User.Read委任された権限Microsoft Teams アカウントを対応する Datadog アカウントに接続するため、サインイン中のユーザーに関する詳細を提供します。
User.Read.All委任された権限インシデントを更新または作成した Microsoft Teams ユーザーの名前を表示します。
Team.ReadBasic.All委任された権限インシデント設定ページに、サービス アカウントがメンバーであるチームを表示します。
+ +{{% /tab %}} + +{{% tab "委任された権限の使用" %}} + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
API / 権限名種類リクエスト理由
Channel.Create委任された権限Datadog Incident Management を使用してインシデントを管理・復旧するためにチャネルを作成します。
Channel.Delete.All委任された権限指定した期間後にインシデント チャネルを自動アーカイブします。
ChannelMessage.Read.All委任された権限インシデント チャネルからインシデント タイムラインへ、タイムライン メッセージを自動同期します。
ChannelSettings.ReadWrite.All委任された権限Datadog Incident Management を使用してインシデントを復旧するため、チャネルを作成および変更します。
TeamsTab.Create委任された権限Datadog アプリ用にチーム内にタブを作成します (この権限は今後の Microsoft Teams におけるインシデント宣言エクスペリエンスに必要です)。
OnlineMeetings.ReadWrite委任された権限Datadog アプリ用にチーム内で会議を自動作成します (この権限は今後の Microsoft Teams におけるインシデント宣言エクスペリエンスに必要です)。
TeamsAppInstallation. + ReadWriteSelfForTeam委任された権限Datadog アプリがチームのメンバーであるかどうかを確認できるようにします。
TeamsTab.Read.All委任された権限チャネルに Datadog タブが作成されているかどうかを確認します (この権限は今後の Microsoft Teams におけるインシデント宣言エクスペリエンスに必要です)。
User.Read委任された権限Microsoft Teams アカウントを対応する Datadog アカウントに接続するため、サインイン中のユーザーに関する詳細を提供します。
User.Read.All委任された権限インシデントを更新または作成した Microsoft Teams ユーザーの名前を表示します。
Team.ReadBasic.All委任された権限インシデント設定ページに、サービス アカウントがメンバーであるチームを表示します。
+ +{{% /tab %}} + +{{< /tabs >}} + +{{< /site-region >}} + +## トラブルシューティング + +### SSO の使用 + +次の手順を使用して、新しいチャンネルコネクターを設定します。 + +1. Datadog にログインし、セットアップ手順 1 および 2 を完了します。 + +1. セットアップ手順 3 で MS Teams ページから Datadog にリダイレクトされたら、新しいタブを開き、SSO で Datadog にログインします。次に、セットアップ手順 4 を個別に実行します。 + +### インテグレーションタイルにチームが表示されないのはなぜですか？ + +{{< site-region region="us,us3,us5,eu,ap1,ap2" >}} +Datadog にテナントを追加する前にボットをチームに追加した場合、Datadog はチームの存在を把握するための参加イベントを受信できていない可能性があります。 +次のいずれかを試してください: + +- そのチームの任意の標準チャンネルに `@Datadog sync` を投稿して、チームの標準チャンネルを Datadog と同期します。 + +1. 同期したい Team 内の標準チャンネルに移動します。 +1. そのチャンネルで投稿を開始します。 +1. チャンネルに `@Datadog sync` を投稿し、操作が成功したことを示す確認メッセージがスレッドに表示されるのを待ちます。 + +- チームから Datadog アプリを削除して、再度追加します。**注**: これにより、そのチームで構成済みのコネクタが削除されます。この操作は、そのチームのすべてのコネクタを Datadog のテナント ベースのインテグレーションに移行する準備ができている場合にのみ実行してください: + +1. 左サイドバーのチーム名の横にある 3 つの点をクリックします。 +1. **Manage Team** をクリックします。 +1. **Apps** というラベルの付いたタブに移動します。 +1. Datadog アプリの横にある 3 つの点をクリックします。 +1. **Remove** をクリックします。 +1. [セットアップ手順](https://docs.datadoghq.com/integrations/microsoft-teams/?tab=datadogapprecommended#setup) に従って Datadog アプリを再追加します。 + +{{< /site-region >}} + +{{< site-region region="gov" >}} +Datadog にテナントを追加する前にボットをチームに追加した場合、Datadog はチームの存在を把握するための参加イベントを受信できていない可能性があります。 +次のいずれかを実行できます: + +- そのチームの任意の標準チャネルで `@Datadog for Government sync` を投稿して、チームの標準チャネルを Datadog と同期します: + +1. 同期したい Team 内の標準チャンネルに移動します。 +1. そのチャンネルで投稿を開始します。 +1. チャネルに `@Datadog for Government sync` を投稿し、スレッド内に操作成功の確認メッセージが表示されるまで待ちます。 + +- チームから Datadog for Government アプリを削除して、再度追加します。**注**: これにより、そのチームで構成済みのコネクタが削除されます。この操作は、そのチームのすべてのコネクタを Datadog のテナント ベースのインテグレーションに移行する準備ができている場合にのみ実行してください。 + +1. 左サイドバーのチーム名の横にある 3 つの点をクリックします。 +1. **Manage Team** をクリックします。 +1. **Apps** というラベルの付いたタブに移動します。 +1. Datadog for Government アプリの横の **...** をクリックします。 +1. **Remove** をクリックします。 +1. [セットアップ手順](https://docs.datadoghq.com/integrations/microsoft-teams/?tab=datadogapprecommended#setup&site=gov) に従って Datadog for Government アプリを再追加します。 + +{{< /site-region >}} + +### プライベートチャンネルはボットでサポートされていますか？ + +[Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/private-channels#private-channel-limitations) のプライベート チャネルの制限により、ボットはプライベート チャネルをサポートしません。プライベート チャネルに通知を送信したい場合は、[Microsoft Workflows Webhooks](https://docs.datadoghq.com/integrations/microsoft-teams/?tab=microsoftworkflowswebhooks#what-are-microsoft-workflows-webhooks) を参照してください。 + +{{< site-region region="us,us3,us5,eu,ap1,ap2" >}} + +### モニター通知で複数のユーザー メンションはサポートされていますか？ + +はい、1 件の通知に複数のユーザー メンションを含めて、関係するチーム メンバー全員に通知できます。 + +**例**: `@teams-handle user1@microsoft.com user2@microsoft.com user3@microsoft.com` + +
通知に複数のユーザー メンションが含まれ、そのうち 1 つが無効な場合でも、有効なユーザーには通知が届きますが、無効なユーザー メンションが原因でメンションの順序が入れ替わって表示されることがあります。
+ +{{< /site-region >}} + +{{< site-region region="gov" >}} + +### Datadog for Government アプリは GCC または GCC High でサポートされていますか？ + +現在、Datadog for Government アプリは、`commercial` Microsoft Teams テナントへの接続を試みる Datadog US1-FED 顧客のみをサポートしています。GCC および GCC High のテナントは、このアプリではサポートされていません。 +{{< /site-region >}} + +### 委任された権限の使用時にインシデント機能が動作しないのはなぜですか？ + +まず、その機能を使用しているチームにサービス アカウント ユーザーがメンバーとして参加していることを確認してください。 + +- インシデント タブが作成されない場合は、そのチームでメンバーによるチャネル内タブの作成・更新・削除が許可されていることを確認してください。 +- 新しいインシデント チャネルが作成または名前変更されない場合は、そのチームでメンバーによるチャネルの作成・更新が許可されていることを確認してください。 +- インシデント チャネルがアーカイブされない場合は、そのチームでメンバーによるチャネルの削除・復元が許可されていることを確認してください。 + +最後に、委任ユーザーのトークンが期限切れまたは失効している可能性があります。その場合は、委任ユーザーを再接続してください。 + +### インシデントを宣言しようとしたときにアプリ構成の確認を求められるのはなぜですか？ + +新しいインシデント宣言エクスペリエンスを使用するには、次の点を確認してください: + +- アプリ バージョンが 3.1.23 以上であること。[アプリ バージョンを更新する方法](https://support.microsoft.com/en-us/office/update-an-app-in-microsoft-teams-3d53d136-5c5d-4dfa-9602-01e6fdd8015b) を参照してください。 +- アプリケーション 権限を使用している場合は、`TeamsTab.Create` アプリケーション 権限を付与していること。 +- 委任された権限を使用している場合は、`TeamsTab.Create` および `TeamsTab.Read.All` の委任された権限を付与していること。 +- 委任された権限を使用している場合は、`@Datadog incident` コマンドを実行するチームにサービス アカウントがメンバーとして参加していること。 + +また、チャネル上部の `+` をクリックして Datadog アプリを検索することで、新しいインシデント宣言エクスペリエンスを使用することもできます。 + +お困りですか？ [Datadog サポート](https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens) にお問い合わせください。 \ No newline at end of file diff --git a/content/ja/integrations/opentelemetry_for_mulesoft_implementation.md b/content/ja/integrations/opentelemetry_for_mulesoft_implementation.md index b80bfd71cfbbf..f8b2d81885dfa 100644 --- a/content/ja/integrations/opentelemetry_for_mulesoft_implementation.md +++ b/content/ja/integrations/opentelemetry_for_mulesoft_implementation.md @@ -103,4 +103,4 @@ AVIO のプロフェッショナルサービスには以下が含まれます。 --- -このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。このアプリケーションを購入するには、こちらをクリックしてください。 \ No newline at end of file +このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。利用するには、Marketplace でこのアプリケーションを購入してください。 \ No newline at end of file diff --git a/content/ja/integrations/palo_alto_cortex_xdr.md b/content/ja/integrations/palo_alto_cortex_xdr.md new file mode 100644 index 0000000000000..e844eecf08f14 --- /dev/null +++ b/content/ja/integrations/palo_alto_cortex_xdr.md @@ -0,0 +1,130 @@ +--- +app_id: palo-alto-cortex-xdr +app_uuid: 156afdc8-d8e9-4544-92fd-d8da87278671 +assets: + dashboards: + Palo Alto Cortex XDR - Alerts: assets/dashboards/palo_alto_cortex_xdr_alerts.json + Palo Alto Cortex XDR - Incidents: assets/dashboards/palo_alto_cortex_xdr_incidents.json + integration: + auto_install: false + events: + creates_events: false + service_checks: + metadata_path: assets/service_checks.json + source_type_id: 20766332 + source_type_name: Palo Alto Cortex XDR + logs: + source: palo-alto-cortex-xdr +author: + homepage: https://www.datadoghq.com + name: Datadog + sales_email: info@datadoghq.com + support_email: help@datadoghq.com +categories: +- log collection +- security +custom_kind: integration +dependencies: +- https://github.com/DataDog/integrations-core/blob/master/palo_alto_cortex_xdr/README.md +display_on_public_website: true +draft: false +git_integration_title: palo_alto_cortex_xdr +integration_id: palo-alto-cortex-xdr +integration_title: Palo Alto Cortex XDR +integration_version: '' +is_public: true +manifest_version: 2.0.0 +name: palo_alto_cortex_xdr +public_title: Palo Alto Cortex XDR +short_description: Palo Alto Cortex XDR のログから洞察を得る +supported_os: [] +tile: + changelog: CHANGELOG.md + classifier_tags: + - Category::Log Collection + - Category::Security + - Submitted Data Type::Logs + - Offering::Integration + configuration: README.md#Setup + description: Palo Alto Cortex XDR のログから洞察を得る + media: + - caption: Palo Alto Cortex XDR - インシデント + image_url: images/palo_alto_cortex_xdr_incidents.png + media_type: image + - caption: Palo Alto Cortex XDR - アラート + image_url: images/palo_alto_cortex_xdr_alerts.png + media_type: image + overview: README.md#Overview + support: README.md#Support + title: Palo Alto Cortex XDR +--- + + + + +## 概要 + +[Palo Alto Cortex XDR][1] は、エンドポイント、ネットワーク、クラウド環境全体に高度な脅威保護を提供する包括的な検知・対応プラットフォームです。エンドポイント保護、ネットワーク セキュリティ、アナリティクスを統合し、リアルタイムの可視性と対応能力を提供して、高度なサイバー脅威に効果的に対処します。 + +このインテグレーションは、次のログを取り込みます: + +- インシデント: 脅威イベントに関するアーティファクト、アセット、アラートの情報 (重大度、ステータス、対応ユーザーなど) を表します。 +- アラート: アラートのリアルタイム分析 (重大度、頻度、発生源など) を表します。 + +Palo Alto Cortex XDR インテグレーションは、REST API を使用して Palo Alto Cortex XDR のログ データをシームレスに収集します。取り込み前にログを正規化および拡充し、データ形式を一貫させて、後続の処理や分析に役立つ情報量を高めます。インシデントとアラートに対する洞察は、すぐに使えるダッシュボードで提供されます。 + +## セットアップ + +### Palo Alto Cortex XDR で API 資格情報を生成 + +1. **Palo Alto Cortex XDR** アカウントにログインします。 +2. **Settings** > **Configurations** > **Integrations** > **API Keys** に移動します。 +3. **New Key** をクリックします。 +4. 希望するセキュリティ レベルに基づいて API キーの種類 (**Advanced** または **Standard**) を選択します。 +5. API キー認証に有効期限を設定する場合は **Enable Expiration Date** を有効にし、**expiration date and time** を選択します。各 API キーの **Expiration Time** 設定は **Settings** > **Configurations** > **Integrations** > **API Keys** で確認できます。 +6. 必要に応じて、この API キーの用途を説明するコメントを入力します。 +7. 既存の **Roles** からこのキーのアクセス レベルを選択するか、**Custom** を選択して権限をきめ細かく設定します。 +8. **Generate** をクリックして API キーを生成します。 + +### Palo Alto Cortex XDR の API キー ID を取得 + +1. API Keys テーブルで、ID フィールドを見つけます。 +2. 対応する ID 番号を控えます。この値が **x-xdr-auth-id:{key_id}** トークンを表します。 + +### Palo Alto Cortex XDR の FQDN を取得 + +1. API キーを右クリックし、**View Examples** を選択します。 +2. **CURL Example** の URL をコピーします。この例にあなた固有の **FQDN** が含まれています。 + +### Palo Alto Cortex XDR アカウントを Datadog に接続 + +1. Palo Alto Cortex XDR の認証情報を追加します。 + + | パラメーター | 説明 | + | -------------| ------------ | + | API key | Palo Alto Cortex XDR の API キー。 | + | API Key ID | Palo Alto Cortex XDR の認証 ID。 | + | FQDN | Palo Alto Cortex XDR の FQDN。これは `baseUrl/public_api/v1/{name of api}/{name of call}/` の `baseUrl` 部分です。 | + +2. 設定を保存するには **Save** ボタンをクリックします。 + +## 収集データ + +### ログ + +Palo Alto Cortex XDR インテグレーションは、Palo Alto Cortex XDR のインシデント ログとアラート ログを収集して Datadog に転送します。 + +### メトリクス + +Palo Alto Cortex XDR インテグレーションには、メトリクスは含まれません。 + +### イベント + +Palo Alto Cortex XDR インテグレーションには、イベントは含まれません。 + +## サポート + +お困りですか? [Datadog サポート][2] にお問い合わせください。 + +[1]: https://docs-cortex.paloaltonetworks.com/p/XDR +[2]: https://docs.datadoghq.com/ja/help/ \ No newline at end of file diff --git a/content/ja/integrations/performetriks_composer.md b/content/ja/integrations/performetriks_composer.md index 6778976f142f3..faa4d715c66da 100644 --- a/content/ja/integrations/performetriks_composer.md +++ b/content/ja/integrations/performetriks_composer.md @@ -11,8 +11,8 @@ author: support_email: composer@performetriks.com vendor_id: performetriks categories: -- マーケットプレイス -custom_kind: integration +- marketplace +custom_kind: インテグレーション dependencies: [] display_on_public_website: true draft: false diff --git a/content/ja/integrations/php_apcu.md b/content/ja/integrations/php_apcu.md index d6a161a31b914..189e421e5b0cf 100644 --- a/content/ja/integrations/php_apcu.md +++ b/content/ja/integrations/php_apcu.md @@ -118,7 +118,7 @@ Alias /apcu-status /opt/datadog-agent/embedded/lib/python3.8/site-packages/datad ## 収集データ ### メトリクス -{{< get-metrics-from-git "php-apcu" >}} +{{< get-metrics-from-git "php_apcu" >}} ### イベント @@ -126,7 +126,7 @@ Alias /apcu-status /opt/datadog-agent/embedded/lib/python3.8/site-packages/datad PHP APCu インテグレーションには、イベントは含まれません。 ### サービスチェック -{{< get-service-checks-from-git "php-apcu" >}} +{{< get-service-checks-from-git "php_apcu" >}} ## トラブルシューティング diff --git a/content/ja/integrations/pinecone.md b/content/ja/integrations/pinecone.md index a9425aafde4c1..536bf73a5f584 100644 --- a/content/ja/integrations/pinecone.md +++ b/content/ja/integrations/pinecone.md @@ -1,108 +1,110 @@ --- app_id: pinecone -app_uuid: dd7ebeb0-9910-4897-81b3-d8bc73003413 -assets: - dashboards: - pinecone: assets/dashboards/pinecone_overview.json - integration: - auto_install: true - events: - creates_events: false - metrics: - check: - - pinecone.index.fullness - metadata_path: metadata.csv - prefix: pinecone. - service_checks: - metadata_path: assets/service_checks.json - source_type_id: 10363 - source_type_name: Pinecone - monitors: - Index is approaching limit: assets/monitors/index_fullness.json -author: - homepage: https://www.datadoghq.com - name: Datadog - sales_email: info@datadoghq.com (日本語対応) - support_email: help@datadoghq.com categories: - メトリクス - data stores - ai/ml custom_kind: インテグレーション -dependencies: [] -display_on_public_website: true -draft: false -git_integration_title: pinecone -integration_id: pinecone -integration_title: Pinecone -integration_version: '' -is_public: true -manifest_version: 2.0.0 -name: pinecone -public_title: Pinecone -short_description: 高性能 AI アプリケーションのためのクラウドベースのベクターデータベース。 +description: 高性能 AI アプリケーションのためのクラウドベースのベクターデータベース。 +further_reading: +- link: https://www.datadoghq.com/blog/ai-integrations/ + tag: blog + text: 'インテグレーションのまとめ: AI スタックのモニタリング' +- link: https://docs.datadoghq.com/integrations/pinecone/ + tag: blog + text: Pinecone +integration_version: 1.1.0 +media: +- caption: Pinecone ポッド ベース ダッシュボード概要 + image_url: images/pinecone-dashboard.png + media_type: image +- caption: Pinecone サーバーレス ダッシュボード概要 + image_url: images/pinecone-serverless-dashboard.png + media_type: image supported_os: - linux - windows - macos -tile: - changelog: CHANGELOG.md - classifier_tags: - - Category::Metrics - - Category::Data Stores - - Category::AI/ML - - Submitted Data Type::Metrics - - Supported OS::Linux - - Supported OS::Windows - - Supported OS::macOS - - Offering::Integration - configuration: README.md#Setup - description: 高性能 AI アプリケーションのためのクラウドベースのベクターデータベース。 - media: - - caption: Pinecone ダッシュボード概要 - image_url: images/pinecone-dashboard.png - media_type: image - overview: README.md#Overview - support: README.md#Support - title: Pinecone +title: Pinecone --- - - ## 概要 -- **パフォーマンスの最適化と使用量の管理:** Pinecone 内で特定のアクション (リクエスト数など) を観測、追跡し、レイテンシーが高かったり使用量が多かったりするアプリケーションリクエストを特定します。傾向を監視し、実用的な洞察を得ることで、リソースの使用量を改善し、コストを削減します。 +- **パフォーマンスを最適化し、使用量を制御**: Pinecone 内の特定アクション (例: リクエスト カウント) を監視して、レイテンシーや使用量が高いアプリケーション リクエストを特定します。トレンドを可視化し、リソース利用率を改善してコストを削減するためのインサイトを取得できます。 + +- **メトリクスで自動アラート**: インデックスの充填率がしきい値に達したときにアラートを受け取ります。また、特定のメトリクスやしきい値に対してカスタム モニターを作成することも可能です。 + +- **使用量やレイテンシーの突発的なスパイクを特定・トリアージ**: Datadog の Pinecone ダッシュボードで使用量やレイテンシーの異常を迅速に可視化。メトリクスを時系列で表示し、スパイクの傾向と重大度を把握します。 -- **メトリクスの自動アラート:** インデックスの空き状況が特定のしきい値に達したときにアラートを取得します。また、特定のメトリクスやしきい値にアラートする独自のカスタムモニターを作成することもできます。 +## 要件 -- **使用量やレイテンシーにおける予期せぬスパイクの発見とトリアージ:** Pinecone の Datadog ダッシュボードで、使用量やレイテンシーの異常をすばやく視覚化します。メトリクスを時系列で表示することで、傾向の理解を深め、スパイクの重大度を判断します。 +Datadog で Pinecone を監視するための前提条件 + +- Enterprise または Enterprise Dedicated の Pinecone プラン +- ポッド ベースまたはサーバーレス インデックス: Datadog は両方のメトリクス取得をサポートします。 ## セットアップ ### インストール -1. [Pinecone アカウント][1]にログインします。 -2. **API Keys** タブに移動します。 -3. API キーを作成します。 -4. 作成した API キーをクリップボードにコピーします。 +1. [Pinecone アカウント](https://app.pinecone.io/) にログインします。 +1. **API Keys** タブに移動します。 +1. API キーを作成します。 +1. 作成した API キーをクリップボードにコピーします。 -### 構成 +### 設定 -1. Datadog の [Pinecone インテグレーションタイル][2]内のコンフィギュレーションタブに移動します。 -2. プロジェクト ID を入力します。 -3. API キーをクリップボードにコピーした際に表示される、環境を入力します。 -4. コピーした API キーを入力します。 +1. Datadog の [Pinecone インテグレーション タイル](https://app.datadoghq.com/account/settings#integrations/pinecone) 内の Configuration タブへ移動します。 +1. Pinecone コンソールのプロジェクト一覧に表示される Pinecone Project ID を入力します。 +1. ポッド ベース環境のみ: 使用している環境を選択します。サーバーレス環境のプロジェクトは空欄のままで構いません。 +1. コピーした API キーを貼り付けます。 -## 収集データ +## 収集されるデータ ### メトリクス -{{< get-metrics-from-git "pinecone" >}} - -### Logs +| **タイプ** | **説明** | **収集されるメトリクス プレフィックス** | +|------|-------------|-----------------------------| +| **アカウント 使用量** | インデックス内のポッド当たりレコード数を判定するためのメトリクス集 | `pinecone.vector` | +| **レイテンシー** | Pinecone データ プレーン コールのサーバー サイド レイテンシー メトリクス集 | `pinecone.request` | +| **Serverless** | タイプが `Serverless` として定義されたインデックスのメトリクス集 | `pinecone.db` | + +| | | +| --- | --- | +| **pinecone.vector.count**
(gauge) | インデックス内の Pod あたりのレコード数。
_record として表示_ | +| **pinecone.request.count.total**
(count) | クライアントによって行われたデータ プレーン コール数。
_request として表示_ | +| **pinecone.request.error.count.total**
(count) | エラーとなったクライアントのデータ プレーン コール数。
_request として表示_ | +| **pinecone.request.latency.seconds.min**
(gauge) | Pinecone データ プレーン コールのサーバー サイド処理レイテンシー分布の最小値。
_second として表示_ | +| **pinecone.request.latency.seconds.max**
(gauge) | Pinecone データ プレーン コールのサーバー サイド処理レイテンシー分布の最大値。
_second として表示_ | +| **pinecone.request.latency.seconds.avg**
(gauge) | Pinecone データ プレーン コールのサーバー サイド処理レイテンシー分布の平均値。
_second として表示_ | +| **pinecone.request.latency.seconds.50percentile**
(gauge) | Pinecone データ プレーン コールのサーバー サイド処理レイテンシー分布の p50。
_second として表示_ | +| **pinecone.request.latency.seconds.90percentile**
(gauge) | Pinecone データ プレーン コールのサーバー サイド処理レイテンシー分布の p90。
_second として表示_ | +| **pinecone.request.latency.seconds.95percentile**
(gauge) | Pinecone データ プレーン コールのサーバー サイド処理レイテンシー分布の p95。
_second として表示_ | +| **pinecone.request.latency.seconds.99percentile**
(gauge) | Pinecone データ プレーン コールのサーバー サイド処理レイテンシー分布の p99。
_second として表示_ | +| **pinecone.request.latency.seconds.99.9percentile**
(gauge) | Pinecone データ プレーン コールのサーバー サイド処理レイテンシー分布の p99.9。
_second として表示_ | +| **pinecone.request.latency.seconds.count**
(count) | Pinecone データ プレーン コールのサーバー サイド処理レイテンシー分布のカウント。
_request として表示_ | +| **pinecone.index.fullness**
(gauge) | インデックスの充填率 (0〜1 のスケール)。
_unit として表示_ | +| **pinecone.db.op.query.total**
(count) | インデックス (サーバーレス) への Query リクエスト数。
_request として表示_ | +| **pinecone.db.op.fetch.total**
(count) | インデックス (サーバーレス) への Fetch リクエスト数。
_request として表示_ | +| **pinecone.db.op.update.total**
(count) | インデックス (サーバーレス) への Update リクエスト数。
_request として表示_ | +| **pinecone.db.op.delete.total**
(count) | インデックス (サーバーレス) への Delete リクエスト数。
_request として表示_ | +| **pinecone.db.op.upsert.total**
(count) | インデックス (サーバーレス) への Upsert リクエスト数。
_request として表示_ | +| **pinecone.db.op.query.duration.total**
(count) | インデックス (サーバーレス) の Query リクエスト処理に要した総時間。
_millisecond として表示_ | +| **pinecone.db.op.fetch.duration.total**
(count) | インデックス (サーバーレス) の Fetch リクエスト処理に要した総時間。
_millisecond として表示_ | +| **pinecone.db.op.update.duration.total**
(count) | インデックス (サーバーレス) の Update リクエスト処理に要した総時間。
_millisecond として表示_ | +| **pinecone.db.op.delete.duration.total**
(count) | インデックス (サーバーレス) の Delete リクエスト処理に要した総時間。
_millisecond として表示_ | +| **pinecone.db.op.upsert.duration.total**
(count) | インデックス (サーバーレス) の Upsert リクエスト処理に要した総時間。
_millisecond として表示_ | +| **pinecone.db.op.write.unit.total**
(count) | 消費された書き込みユニット合計 (サーバーレス)。
_request として表示_ | +| **pinecone.db.op.read.unit.total**
(count) | 消費された読み取りユニット合計 (サーバーレス)。
_request として表示_ | +| **pinecone.db.storage.size.bytes**
(gauge) | インデックスの合計サイズ (バイト、サーバーレス)。
_byte として表示_ | +| **pinecone.db.record.total**
(gauge) | レコード総数 (サーバーレス)。
_record として表示_ | +| **pinecone.db.op.list.duration.total**
(count) | インデックスの list リクエスト処理に要した総時間 (ミリ秒)。
_millisecond として表示_ | +| **pinecone.db.op.list.total**
(count) | インデックスへの list リクエスト数。
_request として表示_ | + +### ログ Pinecone には、収集ログは含まれません。 -### サービスチェック +### サービス チェック Pinecone には、サービスのチェック機能は含まれません。 @@ -112,9 +114,4 @@ Pinecone には、イベントは含まれません。 ## トラブルシューティング -ご不明な点は、[Datadog のサポートチーム][4]までお問合せください。 - -[1]: https://app.pinecone.io/ -[2]: https://app.datadoghq.com/account/settings#integrations/pinecone -[3]: https://github.com/DataDog/integrations-internal-core/blob/main/pinecone/metadata.csv -[4]: https://docs.datadoghq.com/ja/help/ \ No newline at end of file +お問合せは、[Datadog サポート](https://docs.datadoghq.com/help/) まで。 \ No newline at end of file diff --git a/content/ja/integrations/pingdom_legacy.md b/content/ja/integrations/pingdom_legacy.md new file mode 100644 index 0000000000000..521caef314069 --- /dev/null +++ b/content/ja/integrations/pingdom_legacy.md @@ -0,0 +1,110 @@ +--- +app_id: pingdom +app_uuid: bde11e46-65f6-4cee-b011-f0944c5fb5bb +assets: + integration: + auto_install: false + events: + creates_events: false + metrics: + check: pingdom.response_time + metadata_path: metadata.csv + prefix: pingdom. + service_checks: + metadata_path: assets/service_checks.json + source_type_id: 8 + source_type_name: Pingdom Legacy API (V2.1) +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: pingdom_legacy +integration_id: pingdom +integration_title: Pingdom Legacy API (V2.1) +integration_version: '' +is_public: true +manifest_version: 2.0.0 +name: pingdom_legacy +public_title: Pingdom Legacy API (V2.1) +short_description: レガシー Pingdom モニタリングエンドポイントの既存構成を管理および移行します。 +supported_os: [] +tile: + changelog: CHANGELOG.md + classifier_tags: + - Offering::Integration + - Category::Metrics + configuration: README.md#Setup + description: レガシー Pingdom モニタリングエンドポイントの既存構成を管理および移行します。 + media: [] + overview: README.md#Overview + support: README.md#Support + title: Pingdom Legacy API (V2.1) +--- + + +## 概要 + +
+このインテグレーションは非推奨であり、依存する API はいつサポートを失うかわかりません。代わりに Datadog Pingdom V3 インテグレーションを使用してください。 +
+ +他のイベントやメトリクスに関連付けて、ユーザー中心の Pingdom パフォーマンスメトリクスを Datadog で追跡します。 + +Datadog は、Pingdom Web サイトで構成されているすべてのサイトの `response_time` メトリクスを追跡します。 + +[インテグレーションステータスモニター][1]を構成することで、Pingdom イベントを追加できます。 + +
+メトリクスのインポートは、Starter レベル以上の Pingdom ユーザーで行うことができます。 +
+ +## セットアップ + +### インストール + +1. Pingdom インテグレーションタイルを開きます。 +2. Pingdom アカウントのユーザー名とパスワードを入力します (チームアカウントがある場合は、ご自身の認証情報を使用し、チェックの取得元のアカウントを指定できます)。 +3. 一部のチェックをオフにして無視したり、生成されるイベントにタグを追加することもできます。 + +## 収集データ + +### メトリクス +{{< get-metrics-from-git "pingdom_legacy" >}} + + +### イベント + +Pingdom インテグレーションには、イベントは含まれません。 + +### サービスチェック + +Pingdom インテグレーションは、トランザクションチェックを取得し、それをサービスチェックとしてレポートします。 + +`pingdom.status` チェックについて、以下の表に、Pingdom トランザクションチェックの結果と Datadog サービスチェックの結果の対応関係を示します。 + +| Datadog ステータス | Pingdom ステータス | +| -------------- | ------------------- | +| `OK` | `up` | +| `CRITICAL` | `down` | +| `WARNING` | `unconfirmed_down` | +| `UNKNOWN` | `unknown`、`paused` | + +## トラブルシューティング + +### ユーザー名またはパスワードの更新時にエラーが発生する + +Pingdom 認証情報の保存時に以下のエラーが表示されることがあります。 + +`“There was an issue while testing your Pingdom configuration: Not permitted for account type”`. + +Pingdom アカウント所有者の電子メールアドレスを **(Optional) Account to query** フィールドに追加し、保存してください。 + +[1]: https://app.datadoghq.com/monitors/create/integration +[2]: https://github.com/DataDog/dogweb/blob/prod/integration/pingdom/pingdom_metadata.csv \ No newline at end of file diff --git a/content/ja/integrations/rapdev-oracle-timesten.md b/content/ja/integrations/rapdev-oracle-timesten.md new file mode 100644 index 0000000000000..3bb5d732fd748 --- /dev/null +++ b/content/ja/integrations/rapdev-oracle-timesten.md @@ -0,0 +1,51 @@ +--- +algolia: + subcategory: Marketplace インテグレーション +aliases: +- /ja/integrations/oracle_timesten +app_id: rapdev-oracle-timesten +categories: +- キャッシュ +- data stores +- marketplace +- oracle +custom_kind: integration +description: Oracle TimesTen データベースのパフォーマンスを監視する +media: +- caption: Oracle TimesTen Datadog インテグレーション + image_url: images/video.png + media_type: ビデオ + vimeo_id: 630489692 +- caption: ステータスの概要 + image_url: images/1.png + media_type: image +- caption: レプリケーションメトリクス + image_url: images/2.png + media_type: image +- caption: SQL 統計 + image_url: images/3.png + media_type: image +- caption: ダッシュボード概要 + image_url: images/4.png + media_type: image +supported_os: +- linux +title: Oracle TimesTen +--- +## 概要 + +Oracle TimesTen インテグレーションにより、TimesTen インメモリデータベースを監視できます。このインテグレーションは 200 を超えるメトリクスをカバーし、上位のクエリ、データベースステータス、実行時間などに関する詳細を提供します。 + +このインテグレーションには、TimesTen データベースのステータスとメトリクスを概観するダッシュボードが含まれています。 + +## サポート + +サポートまたは機能リクエストについては、以下のチャンネルで RapDev.io までお問い合わせください。 + +- メール: support@rapdev.io +- チャット: [rapdev.io](https://www.rapdev.io/#Get-in-touch) +- 電話: 855-857-0222 + + +--- +このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。このアプリケーションを購入するには、こちらをクリックしてください。 \ No newline at end of file diff --git a/content/ja/integrations/rapdev_ansible_automation_platform.md b/content/ja/integrations/rapdev_ansible_automation_platform.md index c40bc558e3f60..ea1f220b86212 100644 --- a/content/ja/integrations/rapdev_ansible_automation_platform.md +++ b/content/ja/integrations/rapdev_ansible_automation_platform.md @@ -119,4 +119,4 @@ Automation Platform 環境の監視を始める際に役立つよう、Ansible [8]: mailto:sales@rapdev.io --- -このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。このアプリケーションを購入するには、こちらをクリックしてください。 \ No newline at end of file +このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。利用するには、Marketplace でこのアプリケーションを購入してください。 \ No newline at end of file diff --git a/content/ja/integrations/rapdev_cisco_class_based_qos.md b/content/ja/integrations/rapdev_cisco_class_based_qos.md new file mode 100644 index 0000000000000..009b3fd9eb001 --- /dev/null +++ b/content/ja/integrations/rapdev_cisco_class_based_qos.md @@ -0,0 +1,130 @@ +--- +algolia: + subcategory: Marketplace インテグレーション +app_id: rapdev-cisco-class-based-qos +app_uuid: 97f3eada-2bd0-4100-94f7-fe7f20132442 +assets: + dashboards: + RapDev Cisco QOS Dashboard: assets/dashboards/rapdev_cisco_classbased_qos_overview.json + integration: + auto_install: false + configuration: + spec: assets/configuration/spec.yaml + events: + creates_events: false + metrics: + check: rapdev.cisco_class_based_qos.devices_monitored + metadata_path: metadata.csv + prefix: rapdev.cisco_class_based_qos. + service_checks: + metadata_path: assets/service_checks.json + source_type_id: 10457427 + source_type_name: cisco_class_based_qos + logs: {} +author: + homepage: https://rapdev.io + name: RapDev + sales_email: sales@rapdev.io + support_email: support@rapdev.io + vendor_id: rapdev +categories: +- マーケットプレイス +- ネットワーク +- snmp +- モニター +custom_kind: インテグレーション +dependencies: [] +display_on_public_website: true +draft: false +git_integration_title: rapdev_cisco_class_based_qos +integration_id: rapdev-cisco-class-based-qos +integration_title: Cisco Quality of Service (QOS) +integration_version: '' +is_public: true +legal_terms: + eula: assets/EULA.pdf +manifest_version: 2.0.0 +name: rapdev_cisco_class_based_qos +pricing: +- billing_type: tag_count + includes_assets: true + metric: datadog.marketplace.rapdev.cisco_class_based_qos + product_id: cisco + short_description: QOS デバイス 1 台あたりの単価 + tag: qos_host + unit_label: QOS デバイス + unit_price: 20 +public_title: Cisco Quality of Service (QOS) +short_description: Cisco クラスベースの QoS を使用してネットワークトラフィックを監視 +supported_os: +- linux +- macos +tile: + changelog: CHANGELOG.md + classifier_tags: + - Supported OS::Linux + - Supported OS::macOS + - Category::Marketplace + - Offering::Integration + - Submitted Data Type::Metrics + - Category::Network + - Category::SNMP + - Category::Metrics + configuration: README.md#Setup + description: Cisco クラスベースの QoS を使用してネットワークトラフィックを監視 + media: + - caption: QOS ダッシュボード - ライトモード 1/3 + image_url: images/dashboard_light_1.jpg + media_type: image + - caption: QOS ダッシュボード - ライトモード 2/3 + image_url: images/dashboard_light_2.jpg + media_type: image + - caption: QOS ダッシュボード - ライトモード 3/3 + image_url: images/dashboard_light_3.jpg + media_type: image + overview: README.md#Overview + support: README.md#Support + title: Cisco Quality of Service (QOS) + uninstallation: README.md#Uninstallation +--- + + + + +## 概要 + +Cisco ネットワークにおける QoS (Quality of Service) は、トラフィックを管理し、各種ネットワークサービスがパフォーマンス要件を満たすように設計された技術と手法の集合体です。Cisco の QoS は、音声やビデオ会議などの重要なアプリケーションが適切に機能するよう、特にネットワーク輻輳時に必要な帯域幅と低レイテンシーを確保するため、特定のトラフィックを優先的に扱うことで機能します。 + +Cisco QoS の主なコンポーネントには以下が含まれます。 +- 分類とマーキング: トラフィックの種類を識別し、異なる処理のためにマーキングします。これは、パケットを検査し、ポリシーに基づいて異なるクラスに割り当てるプロセスです。 +- キューイング: トラフィック混雑を管理し、優先度の高いトラフィックを確実に処理します。これには、優先キューイング、加重公平キューイング (WFQ)、クラスベース加重公平キューイング (CBWFQ) などのアルゴリズムが含まれます。 +- 輻輳管理および回避: Tail Drop や Random Early Detection (RED) などのツールを使用して、トラフィックフローを管理し、パケットを制御された形で破棄することで、ネットワークの輻輳を防止します。 +- トラフィックシェーピングとポリシング: 定義された帯域幅制限に従ってトラフィックフローを調整します。トラフィックシェーピングはフローをスムーズにし、ポリシングは指定されたレートを超えたトラフィックを破棄します。 +- リンク効率化メカニズム: リンクフラグメンテーションおよびインターリーブ (LFI) や圧縮技術を利用してネットワークリンクの効率を向上させます。 + +インテグレーションは、選択された MIB オブジェクトについて Cisco デバイスを定期的にポーリングし、収集されたデータは QoS ポリシーのパフォーマンスと使用状況の統計を示します。これにより、ネットワーク管理者はトラフィックパターンを分析し、QoS ポリシーの効果を検証し、必要に応じて調整を行うことができます。 + +Cisco クラスベースの QoS インテグレーションは、SNMP 対応の Cisco デバイス上で[クラスベースのトラフィックポリシング][2]の統計を監視します。クラスベースのポリシングを使用すると、インターフェイス上で送信または受信されるトラフィックの最大レートを制御できます。デバイスを流れるさまざまなクラスのネットワークトラフィックを、ポリシー適用前後の両方で観測でき、異なるポリシーがこのトラフィックにどのように影響を与えるかも確認することが可能です。 + +## Agent +サポートまたは機能リクエストをご希望の場合は、以下のチャンネルから RapDev.io にお問い合わせください。 + +- サポート: [support@rapdev.io][8] +- セールス: [sales@rapdev.io][9] +- チャット: [rapdev.io][10] +- 電話: 855-857-0222 + +[1]: https://docs.datadoghq.com/ja/agent/kubernetes/integrations/ +[2]: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_plcshp/configuration/xe-16/qos-plcshp-xe-16-book/qos-plcshp-class-plc.html +[3]: https://docs.datadoghq.com/ja/agent/guide/agent-commands/#start-stop-and-restart-the-agent +[4]: https://docs.datadoghq.com/ja/agent/guide/agent-commands/#agent-status-and-information +[5]: https://sourceforge.net/projects/net-snmp/ +[6]: https://www.cisco.com/c/en/us/support/docs/ip/simple-network-management-protocol-snmp/7282-12.html +[7]: https://community.cisco.com/t5/networking-knowledge-base/configuration-template-for-snmpv3/ta-p/4666450 +[8]: mailto:support@rapdev.io +[9]: mailto:sales@rapdev.io +[10]: https://www.rapdev.io/#Get-in-touch +[11]: https://app.datadoghq.com/marketplace/app/rapdev-snmp-profiles/ + +--- +このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。利用するには、Marketplace でこのアプリケーションを購入してください。 \ No newline at end of file diff --git a/content/ja/integrations/rapdev_commvault.md b/content/ja/integrations/rapdev_commvault.md index 7c4b0de8fa9bb..0386cf17b2485 100644 --- a/content/ja/integrations/rapdev_commvault.md +++ b/content/ja/integrations/rapdev_commvault.md @@ -51,7 +51,7 @@ pricing: short_description: 月額料金 (1 テラバイトあたり) tag: terrabyte_count unit_label: テラバイト - unit_price: 100 + unit_price: 10.0 public_title: Commvault short_description: Commvault ジョブ、ライブラリステータス、アラート、イベントの監視 supported_os: @@ -131,4 +131,4 @@ Rapdev Commvault インテグレーションは、Command Center から Datadog ボストンより ❤️ を込めて *お探しのインテグレーションが見つかりませんか？組織に必要な重要な機能が欠けていますか？RapDev へ[お問い合わせ](mailto:support@rapdev.io)ください。私たちがその機能を構築します！* --- -このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。このアプリケーションを購入するには、こちらをクリックしてください。 \ No newline at end of file +このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。利用するには、Marketplace でこのアプリケーションを購入してください。 \ No newline at end of file diff --git a/content/ja/integrations/rapdev_jira.md b/content/ja/integrations/rapdev_jira.md index dd5732d555fc6..0bf02ccf5e2ee 100644 --- a/content/ja/integrations/rapdev_jira.md +++ b/content/ja/integrations/rapdev_jira.md @@ -110,4 +110,4 @@ Jira インテグレーションにより、サマリーレポート、ワーク [7]: mailto:sales@rapdev.io --- -このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。このアプリケーションを購入するには、こちらをクリックしてください。 \ No newline at end of file +このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。利用するには、Marketplace でこのアプリケーションを購入してください。 \ No newline at end of file diff --git a/content/ja/integrations/rapdev_managed_datadog_reports.md b/content/ja/integrations/rapdev_managed_datadog_reports.md new file mode 100644 index 0000000000000..fe4601c3619e6 --- /dev/null +++ b/content/ja/integrations/rapdev_managed_datadog_reports.md @@ -0,0 +1,94 @@ +--- +algolia: + subcategory: Marketplace インテグレーション +app_id: rapdev-managed-datadog-reports +app_uuid: 76ce1013-ac71-4253-8af5-8936afc32de9 +assets: + oauth: assets/oauth_clients.json +author: + contact_link: https://www.rapdev.io/datadogservices + homepage: https://www.rapdev.io + name: RapDev + sales_email: ddsales@rapdev.io + support_email: support@rapdev.io + vendor_id: rapdev +categories: +- marketplace +custom_kind: インテグレーション +dependencies: [] +display_on_public_website: true +draft: false +git_integration_title: rapdev_managed_datadog_reports +integration_id: rapdev-managed-datadog-reports +integration_title: RapDev Managed Datadog Reports +integration_version: '' +is_public: true +manifest_version: 2.0.0 +name: rapdev_managed_datadog_reports +pricing: +- includes_assets: true + private_offer_only: true + product_id: md-reports + short_description: プライベートオファーのプレースホルダー + unit_price: null +public_title: RapDev Managed Datadog Reports +short_description: RapDev の Datadog 専門知識へ柔軟にアクセスし、Datadog デプロイメントを強化 +supported_os: +- linux +- windows +- macos +tile: + changelog: CHANGELOG.md + classifier_tags: + - Supported OS::Linux + - Supported OS::Windows + - Supported OS::macOS + - Category::Marketplace + - Offering::Professional Service + configuration: README.md#Setup + description: RapDev の Datadog 専門知識へ柔軟にアクセスし、Datadog デプロイメントを強化 + media: + - caption: RapDev Services Overview + image_url: images/dd-pcp-op2.png + media_type: image + - caption: RapDev Managed Datadog Reports + image_url: images/pcp_reports.jpg + media_type: image + overview: README.md#Overview + support: README.md#Support + title: RapDev Managed Datadog Reports + uninstallation: README.md#Uninstallation +--- + + + + +## 概要 + +Datadog Gold Partner である RapDev は、Datadog のアプリケーションおよびインフラ監視機能を最大限に活用してきた豊富な実績を有します。Managed Datadog Reports サービスは、これまで以上に柔軟な形で当社の専門知識を活用できるようにし、Datadog デプロイメントを自動的に監視・改善します。 + +Datadog プラットフォームのヘルスを監視し、セキュリティ脆弱性の自動検出、コスト監査、平均応答時間 (MTTR) の短縮を実現します。次の領域で支援します。 + +- **Hygiene**: Ensure your platform is clean and efficient, with visibility into the staleness of your tags, monitors, notebooks, dashboards, and service catalog. +- **リアルタイム インサイト**: 余剰使用量、未使用コンポーネント、誤ったログ取り込みを検知し、メールとチャットで即時通知。週次および月次のサマリーで推奨アクションを確認できます。 +- **継続的 モニタリング**: 統合の破損、応答しない Agent、EOS・EOL Agent、API キーの誤構成などの問題を即座に特定します。 + +## サポート + +サポートまたは機能リクエストをご希望の場合は、以下のチャンネルから RapDev.io にお問い合わせください。 + +- Email: [support@rapdev.io][2] +- チャット: [rapdev.io][3] +- 電話: 855-857-0222 + +--- +ボストンより ❤️ を込めて + +*お探しのインテグレーションが見つかりませんか？組織に必要な重要な機能が欠けていますか？私たちがその機能を構築しますので、[お問い合わせ](mailto:support@rapdev.io)ください！* + +[1]: mailto:sales@rapdev.io +[2]: mailto:support@rapdev.io +[3]: https://www.rapdev.io/#Get-in-touch + +--- +このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。利用するには、Marketplace でこのアプリケーションを購入してください。 \ No newline at end of file diff --git a/content/ja/integrations/rapdev_maxdb.md b/content/ja/integrations/rapdev_maxdb.md index e82a15ad89f01..83aae635496a0 100644 --- a/content/ja/integrations/rapdev_maxdb.md +++ b/content/ja/integrations/rapdev_maxdb.md @@ -35,7 +35,7 @@ author: categories: - キャッシュ - data stores -- マーケットプレイス +- marketplace - sap custom_kind: インテグレーション dependencies: [] @@ -107,7 +107,7 @@ MaxDB インテグレーションは MaxDB インスタンスのデータ、ロ 4. MaxDB ロック使用率 5. MaxDB ログ領域使用量 -## Agent +## サポート サポートまたは機能リクエストをご希望の場合は、以下のチャンネルから RapDev.io にお問い合わせください。 diff --git a/content/ja/integrations/rapdev_spacelift.md b/content/ja/integrations/rapdev_spacelift.md index 2957edd8e8c58..f822f6bf4539b 100644 --- a/content/ja/integrations/rapdev_spacelift.md +++ b/content/ja/integrations/rapdev_spacelift.md @@ -111,4 +111,4 @@ Spacelift は、Infrastructure as Code ワークフローを自動化し、状 [5]: https://www.rapdev.io/#Get-in-touch [6]: mailto:support@rapdev.io --- -このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。このアプリケーションを購入するには、こちらをクリックしてください。 \ No newline at end of file +このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。利用するには、Marketplace でこのアプリケーションを購入してください。 \ No newline at end of file diff --git a/content/ja/integrations/rapdev_validator.md b/content/ja/integrations/rapdev_validator.md index a41fb60f809ec..2ab6cb7d758cf 100644 --- a/content/ja/integrations/rapdev_validator.md +++ b/content/ja/integrations/rapdev_validator.md @@ -34,8 +34,8 @@ author: vendor_id: rapdev categories: - コンプライアンス -- 構成 & デプロイ -- マーケットプレイス +- 構成とデプロイ +- marketplace custom_kind: インテグレーション dependencies: [] display_on_public_website: true @@ -99,7 +99,7 @@ RapDev Validator は、Datadog 環境でのタグモニタリングと Agent の 1. ホストに必要なタグキーが割り当てられていない 2. ホストのタグキーに非準拠の値が割り当てられている -## Agent +## サポート サポートまたは機能リクエストをご希望の場合は、以下のチャンネルから RapDev.io にお問い合わせください。 - メール: support@rapdev.io diff --git a/content/ja/integrations/rapdev_veeam.md b/content/ja/integrations/rapdev_veeam.md index 8908edf375360..4e25ba11b5183 100644 --- a/content/ja/integrations/rapdev_veeam.md +++ b/content/ja/integrations/rapdev_veeam.md @@ -121,4 +121,4 @@ Veeam インテグレーションにより、Veeam 内で生成されたサマ [6]: mailto:support@rapdev.io [7]: mailto:sales@rapdev.io --- -このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。このアプリケーションを購入するには、こちらをクリックしてください。 \ No newline at end of file +このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。利用するには、Marketplace でこのアプリケーションを購入してください。 \ No newline at end of file diff --git a/content/ja/integrations/redis_cloud.md b/content/ja/integrations/redis_cloud.md new file mode 100644 index 0000000000000..1a13ce5cf318e --- /dev/null +++ b/content/ja/integrations/redis_cloud.md @@ -0,0 +1,177 @@ +--- +app_id: redis-cloud +app_uuid: 0b59b80e-db72-44a6-8c2b-67475d10ad71 +assets: + dashboards: + redis-cloud-active-active: assets/dashboards/redis_cloud_active-active.json + redis-cloud-database: assets/dashboards/redis_cloud_database.json + redis-cloud-networking: assets/dashboards/redis_cloud_networking.json + redis-cloud-overview: assets/dashboards/redis_cloud_overview.json + redis-cloud-proxy: assets/dashboards/redis_cloud_proxy.json + redis-cloud-proxy-threads: assets/dashboards/redis_cloud_proxy-threads.json + integration: + auto_install: true + configuration: + spec: assets/configuration/spec.yaml + events: + creates_events: false + metrics: + check: rdsc.bdb_conns + metadata_path: metadata.csv + prefix: rdsc + service_checks: + metadata_path: assets/service_checks.json + source_type_id: 7769531 + source_type_name: Redis Cloud + logs: {} +author: + homepage: https://redis.com/cloud/overview/ + name: Redis, Inc. + sales_email: press@redis.com + support_email: support@redis.com +categories: +- ai/ml +- caching +- data stores +- cloud +custom_kind: integration +dependencies: +- https://github.com/DataDog/integrations-extras/blob/master/redis_cloud/README.md +display_on_public_website: true +draft: false +git_integration_title: redis_cloud +integration_id: redis-cloud +integration_title: Redis Cloud +integration_version: 1.1.0 +is_public: true +manifest_version: 2.0.0 +name: redis_cloud +public_title: Redis Cloud +short_description: Redis Cloud Integration +supported_os: +- linux +- windows +- macos +tile: + changelog: CHANGELOG.md + classifier_tags: + - Supported OS::Linux + - Supported OS::Windows + - Supported OS::macOS + - Category::AI/ML + - Category::Caching + - Category::Data Stores + - Category::Cloud + - Offering::Integration + - Submitted Data Type::Metrics + configuration: README.md#Setup + description: Redis Cloud Integration + media: + - caption: redis cloud overview display + image_url: images/datadog-cloud-overview-dashboard.png + media_type: image + - caption: redis cloud cluster details + image_url: images/datadog-cloud-cluster-database.png + media_type: image + - caption: redis cloud node details + image_url: images/datadog-cloud-node-dashboard.png + media_type: image + overview: README.md#Overview + support: README.md#Support + title: Redis Cloud +--- + + + + +## 概要 + +Redis は、高速で多機能なデータ ストアであり、文字列、ハッシュ、リスト、セット、ストリームなど、さまざまなデータ構造をサポートします。さらに、プログラマビリティ、拡張性、永続化、クラスタリング、高可用性も提供します。Redis の Community Edition では、ベクター サーチ、確率的データ構造、JSON サポート、全文検索など、追加のデータ モデルと機能が利用できます。 + +[Redis Cloud][1] インテグレーションは、Redis ソフトウェアの Redis Cloud デプロイで使用することを想定しています。Redis Enterprise 環境では使用しません。Redis Enterprise をご利用の場合は、[Datadog Redis Enterprise インテグレーション][3] を参照してください。 + +このインテグレーションは、Datadog Agent を使用して、データベース、ノード、シャードというクラスターの 3 つの重要コンポーネントのメトリクスを提供します。これにより、Datadog 内でデータベース スループット、メモリ使用率、CPU 使用率、接続数、レプリケーションの健全性、その他多数のメトリクスを監視できます。これらの情報を使用して、Redis Cloud クラスター全体の健全性を把握し、アプリケーション パフォーマンスの問題を診断し、ダウンタイムを防止できます。 + +サポートされているメトリクスの完全な一覧については、下記 **メトリクス** セクションを参照してください。 + +## セットアップ + +### インストール + +1. 次のコマンドを実行して Agent インテグレーションをインストールします。 +- Datadog Agent v6 の場合: + ```shell + datadog-agent integration install -t datadog-redis_cloud==1.1.0 + ``` +- Datadog Agent v7 の場合: + ```shell + agent integration install -t datadog-redis_cloud==1.1.0 + ``` + +2. `openmetrics_endpoint` をクラスターのマスター ノードに設定してインテグレーションを構成します。詳細は [インテグレーションの概要][4] を参照してください。 +3. 設定後、Agent を [再起動][5] します。 + + +### 構成 + +`openmetrics_endpoint` をクラスターを指すように設定し、`tls_verify` は false のままにします。 + +オプション パラメーターとして `extra_metrics` と `excluded_metrics` の 2 つがあります。例の構成ファイルを参照してください。 + +**extra_metrics** パラメーターにはメトリクス グループのリストを指定します。利用可能なグループは RDSC.REPLICATION、RDSC.NODE、RDSC.BIGSTORE、RDSC.FLASH、RDSC.SHARDREPL です。デフォルトのメトリクス グループ RDSC.DATABASE、RDSC.PROXY、RDSC.LISTENER、RDSC.SHARD はインテグレーションによって自動的に追加されます。 + +`exclude_metrics` パラメーターには除外する個別メトリクスのリストを指定します。指定したメトリクスは Datadog に送信されません。各メトリクス名はプレフィックスを外して指定してください。たとえば 'rdsc.bdb_up' は 'bdb_up' になります。メトリクスの完全な一覧は、インテグレーション ページの **Data Collected** タブおよび [メトリクス](#metrics) セクションで確認できます。 以下の追加グループでは、それぞれ関連付けられたプレフィックスを使用しており、**Data Collected** ページで個別メトリクスを検索する際に利用できます。 + +| グループ | プレフィックス | 注 | +|------------------|---------------------------|-------------------------------------------------------| +| RDSC.NODE | rdsc.node_ | Bigstore と Flash のメトリクスも返します。 | +| RDSC.DATABASE | rdsc.bdb_ | レプリケーションのメトリクスも返します。 | +| RDSC.SHARD | rdsc.redis_ | シャード レプリケーションのメトリクスも返します。 | +| RDSC.REPLICATION | rdsc.bdb_crdt_ | | +| RDSC.REPLICATION | rdsc.bdb_replicaof_ | | +| RDSC.SHARDREPL | rdsc.redis_crdt_ | | +| RDSC.PROXY | rdsc.dmcproxy_ | | +| RDSC.LISTENER | rdsc.listener_ | | +| RDSC.BIGSTORE | rdsc.node_bigstore_ | | +| RDSC.FLASH | rdsc.node_available_flash | すべての Flash メトリクスは rdsc.node_*_flash 形式です。 | + + +### 検証 + +1. クラウド環境では特に、対象マシンに ping できることを確認してください。`wget --no-check-certificate ` または `curl -k ` を実行し、メトリクスを受信できることを確認します。 + +2. Datadog Agent の [ステータス][6] もチェックしてください。 + + +## 収集データ + +Redis Cloud インテグレーションは、データベース、ノード、シャードのすべてのメトリクスを収集します。 + + +### メトリクス +{{< get-metrics-from-git "redis_cloud" >}} + + + +### サービス チェック + +Redis Cloud インテグレーションにはサービス チェックは含まれていません。 + + +### イベント + +Redis Cloud インテグレーションにはイベントは含まれていません。 + + +## トラブルシューティング + +お困りの場合は、[Redis Field Engineering][8] までお問い合わせください。 + +[1]: https://redis.io/docs/latest/operate/rc/ +[2]: https://redis.io/docs/latest/operate/rs/ +[3]: https://app.datadoghq.com/integrations?integrationId=redis-enterprise +[4]: https://docs.datadoghq.com/ja/getting_started/integrations/ +[5]: https://docs.datadoghq.com/ja/agent/guide/agent-commands/#start-stop-and-restart-the-agent +[6]: https://docs.datadoghq.com/ja/agent/guide/agent-commands/#agent-status-and-information +[7]: https://github.com/DataDog/integrations-extras/blob/master/redis_cloud/metadata.csv +[8]: mailto:support@redis.com \ No newline at end of file diff --git a/content/ja/integrations/rigor.md b/content/ja/integrations/rigor.md index 2111b0109918e..6630e268f39ee 100644 --- a/content/ja/integrations/rigor.md +++ b/content/ja/integrations/rigor.md @@ -22,7 +22,7 @@ author: support_email: support@rigor.com categories: - テスト -custom_kind: integration +custom_kind: インテグレーション dependencies: - https://github.com/DataDog/integrations-extras/blob/master/rigor/README.md display_on_public_website: true @@ -147,4 +147,4 @@ Rigor インテグレーションには、サービスのチェック機能は [9]: https://raw.githubusercontent.com/DataDog/integrations-extras/master/rigor/images/rigor_add_webhook_to_check.png [10]: https://github.com/DataDog/integrations-extras/blob/master/rigor/metadata.csv [11]: https://raw.githubusercontent.com/DataDog/integrations-extras/master/rigor/images/rigor_events_example.png -[12]: mailto:support@rigor.com +[12]: mailto:support@rigor.com \ No newline at end of file diff --git a/content/ja/integrations/rollbar_license.md b/content/ja/integrations/rollbar_license.md index 78bcc0e7df959..11d69bd9def7e 100644 --- a/content/ja/integrations/rollbar_license.md +++ b/content/ja/integrations/rollbar_license.md @@ -12,7 +12,7 @@ author: vendor_id: rollbar categories: - マーケットプレイス -custom_kind: integration +custom_kind: インテグレーション dependencies: [] display_on_public_website: true draft: false @@ -107,4 +107,4 @@ Datadog、GitHub、GitHub Enterprise Server、Atlassian、Google Cloud、Terrafo [3]: https://docs.rollbar.com/ [4]: https://www.rollbar.com/support --- -このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。このアプリケーションを購入するには、こちらをクリックしてください。 +このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。利用するには、Marketplace でこのアプリケーションを購入してください。 \ No newline at end of file diff --git a/content/ja/integrations/rum_expo.md b/content/ja/integrations/rum_expo.md index 07746a3793546..e950161aa5827 100644 --- a/content/ja/integrations/rum_expo.md +++ b/content/ja/integrations/rum_expo.md @@ -13,7 +13,7 @@ categories: - apm - ネットワーク - tracing -custom_kind: integration +custom_kind: インテグレーション dependencies: - https://github.com/DataDog/integrations-extras/blob/master/rum_expo/README.md display_on_public_website: true @@ -122,4 +122,4 @@ Expo インテグレーションには、サービスのチェック機能は含 [4]: https://docs.datadoghq.com/ja/real_user_monitoring/generate_metrics [5]: https://docs.datadoghq.com/ja/real_user_monitoring/reactnative/expo/ [6]: https://docs.datadoghq.com/ja/help/ -[7]: https://docs.datadoghq.com/ja/real_user_monitoring/error_tracking/expo/ +[7]: https://docs.datadoghq.com/ja/real_user_monitoring/error_tracking/expo/ \ No newline at end of file diff --git a/content/ja/integrations/rum_roku.md b/content/ja/integrations/rum_roku.md index bcc5a9460772a..b6764d93e3f00 100644 --- a/content/ja/integrations/rum_roku.md +++ b/content/ja/integrations/rum_roku.md @@ -12,7 +12,7 @@ categories: - モニター - ネットワーク - tracing -custom_kind: integration +custom_kind: インテグレーション dependencies: - https://github.com/DataDog/integrations-extras/blob/master/rum_roku/README.md display_on_public_website: true @@ -53,15 +53,15 @@ tile: ## 概要 -With the Datadog [Roku integration][1], you can spend less time triaging issues and more time releasing new features by: +Datadog [Roku インテグレーション][1]を利用することで、問題のトリアージに費やす時間を減らし、新機能のリリースにより多くの時間を充てられます。たとえば、次のような操作が可能になります。 -- Debugging the root cause of slow performance issues and application crashes, network requests, or large media files -- Improving application responsiveness, setting up service level indicators (SLIs), and diagnosing issues with out-of-the-box dashboards and real-time metrics +- パフォーマンス低下の問題、アプリケーションのクラッシュ、ネットワークリクエスト、大容量メディアファイルの根本原因をデバッグできます +- アプリケーションの応答性を向上させ、サービスレベルインジケータ (SLI) を設定し、すぐに使えるダッシュボードとリアルタイムメトリクスで問題を診断できます - 大量のアプリケーションエラーを管理可能な固有の問題群にインテリジェントにグループ化 ユーザーエクスペリエンスがビジネスに与える影響を関連付けます。 -- Analyzing critical user experience data such as screen engagement by demographics, version releases, or any custom attributes, to reach your business KPIs +- デモグラフィック別、バージョンリリース別、その他のカスタム属性別の画面エンゲージメントなど、重要なユーザーエクスペリエンスデータを分析して、ビジネス KPI 達成に役立てることができます - カスタマイズ可能なアナリティクスと地理的マップによりユーザー行動傾向を把握 アプリケーションのエンドツーエンドの健全性を監視します。 @@ -74,25 +74,25 @@ With the Datadog [Roku integration][1], you can spend less time triaging issues ### RUM イベントの収集 -To start collecting Real User Monitoring events from your application, see [Roku Monitoring][2]. Additionally, you can [Connect RUM and Traces][3]. +アプリケーションからリアルユーザーモニタリングのイベント収集を開始するには、[Roku モニタリング][2]を参照してください。また、[RUM とトレースを接続][3]することもできます。 ### ログの収集 -To start forwarding your Roku application's logs to Datadog, see [Roku Log Collection][4]. +Roku アプリケーションのログを Datadog に転送するには、[Roku ログ収集][4]をご覧ください。 ## 収集データ ### メトリクス -The Roku integration does not include any metrics. To generate custom metrics from your RUM application, see [Generate Metrics][5]. +Roku インテグレーションには、メトリクスは含まれていません。RUM アプリケーションからカスタムメトリクスを生成するには、[メトリクスの生成][5]を参照してください。 ### イベント -For more information about events and attributes, see [RUM Roku Data Collected][6]. +イベントや属性の詳細については、[RUM Roku データ収集][6]を参照してください。 ### サービスチェック -The Roku integration does not include any service checks. +Roku インテグレーションにはサービスチェックは含まれません。 ## トラブルシューティング @@ -102,8 +102,8 @@ The Roku integration does not include any service checks. お役に立つドキュメント、リンクや記事: -- [RUM Roku Channel Monitoring][2] documentation -- [Monitor your Roku channels with Datadog RUM][8] blog post +- [RUM Roku チャンネルモニタリング][2]ドキュメント +- [Datadog RUM で Roku チャンネルをモニタリング][8]ブログ記事 [1]: https://app.datadoghq.com/integrations/rum-roku [2]: https://docs.datadoghq.com/ja/real_user_monitoring/roku/ @@ -112,4 +112,4 @@ The Roku integration does not include any service checks. [5]: https://docs.datadoghq.com/ja/real_user_monitoring/generate_metrics [6]: https://docs.datadoghq.com/ja/real_user_monitoring/roku/data_collected/ [7]: https://docs.datadoghq.com/ja/help/ -[8]: https://www.datadoghq.com/blog/monitor-roku-with-rum/ +[8]: https://www.datadoghq.com/blog/monitor-roku-with-rum/ \ No newline at end of file diff --git a/content/ja/integrations/snmp_hewlett_packard_enterprise.md b/content/ja/integrations/snmp_hewlett_packard_enterprise.md index 793a376069411..3e0cbb55802fd 100644 --- a/content/ja/integrations/snmp_hewlett_packard_enterprise.md +++ b/content/ja/integrations/snmp_hewlett_packard_enterprise.md @@ -21,7 +21,7 @@ categories: - ネットワーク - notifications - snmp -custom_kind: integration +custom_kind: インテグレーション dependencies: - https://github.com/DataDog/integrations-core/blob/master/snmp_hewlett_packard_enterprise/README.md display_on_public_website: true @@ -93,12 +93,12 @@ SNMP インテグレーションをインストールして構成するには、 お役に立つドキュメント、リンクや記事: -* [Monitor SNMP with Datadog][5] +* [Datadog を使用した SNMP の監視][5] -[1]: https://docs.datadoghq.com/ja/network_performance_monitoring/devices/data -[2]: https://docs.datadoghq.com/ja/network_performance_monitoring/devices/setup -[3]: https://docs.datadoghq.com/ja/network_monitoring/devices/#vendor-profiles +[1]: https://docs.datadoghq.com/ja/network_monitoring/devices/data +[2]: https://docs.datadoghq.com/ja/network_monitoring/devices/setup +[3]: https://docs.datadoghq.com/ja/network_monitoring/devices/supported_devices/ [4]: https://docs.datadoghq.com/ja/help/ -[5]: https://www.datadoghq.com/blog/monitor-snmp-with-datadog/ +[5]: https://www.datadoghq.com/blog/monitor-snmp-with-datadog/ \ No newline at end of file diff --git a/content/ja/integrations/sophos_central_cloud.md b/content/ja/integrations/sophos_central_cloud.md new file mode 100644 index 0000000000000..e6908e50755f4 --- /dev/null +++ b/content/ja/integrations/sophos_central_cloud.md @@ -0,0 +1,118 @@ +--- +app_id: sophos-central-cloud +app_uuid: 7293cd88-ceda-4094-94cd-09851f203f0e +assets: + dashboards: + Sophos Central Cloud - Alerts: assets/dashboards/sophos_central_cloud_alerts.json + Sophos Central Cloud - Events: assets/dashboards/sophos_central_cloud_events.json + integration: + auto_install: false + events: + creates_events: false + service_checks: + metadata_path: assets/service_checks.json + source_type_id: 18598661 + source_type_name: Sophos Central Cloud + logs: + source: sophos-central-cloud +author: + homepage: https://www.datadoghq.com + name: Datadog + sales_email: info@datadoghq.com + support_email: help@datadoghq.com +categories: +- log collection +- security +custom_kind: integration +dependencies: +- https://github.com/DataDog/integrations-core/blob/master/sophos_central_cloud/README.md +display_on_public_website: true +draft: false +git_integration_title: sophos_central_cloud +integration_id: sophos-central-cloud +integration_title: Sophos Central Cloud +integration_version: '' +is_public: true +manifest_version: 2.0.0 +name: sophos_central_cloud +public_title: Sophos Central Cloud +short_description: Sophos Central Cloud のアラート ログとイベント ログから洞察を得られます。 +supported_os: [] +tile: + changelog: CHANGELOG.md + classifier_tags: + - Category::Log Collection + - Category::Security + - Submitted Data Type::Logs + - Offering::Integration + configuration: README.md#Setup + description: Sophos Central Cloud のアラート ログとイベント ログから洞察を得られます。 + media: + - caption: Sophos Central Cloud - アラート + image_url: images/sophos_central_cloud_alerts.png + media_type: image + - caption: Sophos Central Cloud - イベント + image_url: images/sophos_central_cloud_events.png + media_type: image + overview: README.md#Overview + support: README.md#Support + title: Sophos Central Cloud +--- + + + + +## 概要 + +[Sophos Central][1] は、脅威から組織を監視・保護するための統合型、クラウド ベースの管理プラットフォームです。あらゆる規模の企業で、Sophos 製品スイートを単一の管理ソリューションへ集約する目的で利用されています。 + +このインテグレーションは、次のログを取り込みます: + +- アラート: Sophos Central Cloud がセキュリティ イベントや潜在的な脅威に応答して生成する通知または警告を表します。あらかじめ定義されたセキュリティ ポリシーや検知ルール、Sophos Central Cloud によって識別された異常なアクティビティに基づいてトリガーされます。 +- イベント: Sophos Central Cloud によって検出・記録される特定の事象を表します。マルウェア 検知、不正アクセス 試行、システムの脆弱性、その他のセキュリティ関連アクティビティなどが含まれます。 + +Sophos Central Cloud インテグレーションは、上記のログをシームレスに収集し、Datadog に取り込みます。組み込みのログ パイプラインを活用してログをパースおよびエンリッチし、容易に検索・分析できるようにします。さらに、アラートとイベントについては組み込み ダッシュボードで可視化できます。加えて、**get_endpoint_details** フラグにより、アラート ログおよびイベント ログに対応するエンドポイントの詳細情報が付加されます。 + +## セットアップ + +### Sophos Central Cloud で API 資格情報を生成する + +1. [**Sophos Central アカウント**][2] にログインします。 +2. Sophos Central Admin で、**My Products** > **General Settings** > **API Credentials Management** に移動します。 +3. **Add Credential** をクリックします。 +4. 資格情報名を入力し、適切なロールを選択し、必要に応じて説明を追加して、**Add** ボタンをクリックします。クライアント ID を含む API 資格情報のサマリー ページが表示されます。 +5. **Show Client Secret** をクリックして **Client Secret** を表示します。 + +### Sophos Central Cloud アカウントを Datadog に接続する + +1. Sophos Central Cloud の資格情報を追加します。 + + | パラメータ | 説明 | + | ------------------------------- | -------------------------------------------------------------------------- | + | Client ID | Sophos Central Cloud の Client ID です。 | + | Client Secret | Sophos Central Cloud の Client Secret です。 | + | Get Endpoint Details | Sophos Central Cloud のアラート ログおよびイベント ログのエンドポイントの詳細を収集するには、既定値の "true" のままにします。収集しない場合は "false" に設定します。 | + +2. **Save** ボタンをクリックして設定を保存します。 + +## 収集データ + +### ログ + +このインテグレーションは、Sophos Central Cloud のアラート ログおよびイベント ログを収集し、Datadog に転送します。 + +### メトリクス + +Sophos Central Cloud インテグレーションにメトリクスは含まれません。 + +### イベント + +Sophos Central Cloud インテグレーションにイベントは含まれません。 + +## サポート + +お困りの場合は [Datadog サポート][3] までお問い合わせください。 + +[1]: https://www.sophos.com/en-us/products/sophos-central +[2]: https://cloud.sophos.com/manage/login +[3]: https://docs.datadoghq.com/ja/help/ \ No newline at end of file diff --git a/content/ja/integrations/ssh_check.md b/content/ja/integrations/ssh_check.md index 02132fe484876..65df6f3eebe98 100644 --- a/content/ja/integrations/ssh_check.md +++ b/content/ja/integrations/ssh_check.md @@ -37,7 +37,7 @@ draft: false git_integration_title: ssh_check integration_id: ssh integration_title: SSH -integration_version: 4.1.0 +integration_version: 4.2.1 is_public: true manifest_version: 2.0.0 name: ssh_check @@ -131,7 +131,7 @@ SSH/SFTP チェックは [Datadog Agent][1] パッケージに含まれていま ## 収集データ ### メトリクス -{{< get-metrics-from-git "ssh" >}} +{{< get-metrics-from-git "ssh_check" >}} ### イベント @@ -139,7 +139,7 @@ SSH/SFTP チェックは [Datadog Agent][1] パッケージに含まれていま SSH チェックには、イベントは含まれません。 ### サービスチェック -{{< get-service-checks-from-git "ssh" >}} +{{< get-service-checks-from-git "ssh_check" >}} ## トラブルシューティング @@ -150,4 +150,4 @@ SSH チェックには、イベントは含まれません。 [1]: https://app.datadoghq.com/account/settings/agent/latest [2]: https://docs.datadoghq.com/ja/agent/guide/agent-commands/#agent-status-and-information -[3]: https://docs.datadoghq.com/ja/help/ +[3]: https://docs.datadoghq.com/ja/help/ \ No newline at end of file diff --git a/content/ja/integrations/tailscale.md b/content/ja/integrations/tailscale.md new file mode 100644 index 0000000000000..1a6b4a63350ee --- /dev/null +++ b/content/ja/integrations/tailscale.md @@ -0,0 +1,132 @@ +--- +app_id: tailscale +app_uuid: e3f4a5cf-3594-43fc-9d4e-4e86b9c91ea2 +assets: + dashboards: + tailscale-overview: assets/dashboards/tailscale_overview.json + integration: + auto_install: true + configuration: {} + events: + creates_events: false + service_checks: + metadata_path: assets/service_checks.json + source_type_id: 10420 + source_type_name: Tailscale + monitors: + High Physical Traffic Received by Destination: assets/monitors/physical_traffic_received.json + High Virtual Traffic Received by Destination: assets/monitors/virtual_traffic_received.json +author: + homepage: https://www.datadoghq.com + name: Datadog + sales_email: info@datadoghq.com (日本語対応) + support_email: help@datadoghq.com +categories: +- セキュリティ +- ログの収集 +- ネットワーク +custom_kind: インテグレーション +dependencies: +- https://github.com/DataDog/integrations-extras/blob/master/tailscale/README.md +display_on_public_website: true +draft: false +git_integration_title: tailscale +integration_id: tailscale +integration_title: Tailscale +integration_version: '' +is_public: true +manifest_version: 2.0.0 +name: tailscale +public_title: Tailscale +short_description: Datadog で Tailscale の監査ログとネットワーク フロー ログを表示します。 +supported_os: +- linux +- windows +- macos +tile: + changelog: CHANGELOG.md + classifier_tags: + - Supported OS::Linux + - Supported OS::Windows + - Supported OS::macOS + - Category::Security + - Category::Log Collection + - Category::Network + - Submitted Data Type::Logs + - Offering::Integration + configuration: README.md#Setup + description: Datadog で Tailscale の監査ログとネットワーク フロー ログを表示します。 + media: [] + overview: README.md#Overview + resources: + - resource_type: blog + url: https://www.datadoghq.com/blog/monitor-tailscale-with-datadog/ + support: README.md#Support + title: Tailscale +--- + + + + +## 概要 + +[Tailscale][1] は、ネットワーク接続を簡素化し安全にするピアツーピア VPN サービスです。 + +このインテグレーションでできること: + +1. Tailscale のデータ保持期間を制御できます。 +2. カスタムウィジェットやカスタムダッシュボードを構築できます。 +3. スタック内の他サービスのデータと Tailscale のイベントを突合できます。 + +このインテグレーションは Tailscale から次の 2 種類のログをストリーミングします: + +[構成監査ログ][2]: + +構成監査ログにより、tailnet で「誰が・何を・いつ」行ったかを特定できます。これらのログは、アクションの種類、実行者、対象リソース、日時など、tailnet の構成を変更する操作を記録します。 + +[ネットワーク フロー ログ][3]: + +Tailscale ネットワークでどのノードがいつどのノードと接続したかを示します。これらのネットワーク ログは、長期保存、セキュリティ分析、脅威検出、インシデント調査のためにエクスポートできます。 + +Tailscale のログを解析した後、Datadog は物理トラフィックと仮想トラフィックのセキュリティ関連イベントのインサイトを、既製の Tailscale Overview ダッシュボードに表示します。 + +## セットアップ + +ログ ストリーミングを有効にするには: + +1. Tailscale 管理コンソールにログインします +2. Logs タブに移動します +3. **Start streaming...** ボタンを選択します +4. メニューから Datadog を選択し、URL とトークンまたは [API キー][4] を追加します +5. **Start streaming** ボタンを選択します + +## 収集データ + +### メトリクス + +Tailscale にメトリクスはありません。 + +### サービスチェック + +Tailscale にサービスチェックはありません。 + +### イベント + +Tailscale にイベントはありません。 + +## トラブルシューティング + +ご不明な点は、[Datadog のサポートチーム][5]までお問い合わせください。 + +## その他の参考資料 + +お役に立つドキュメント、リンクや記事: + +- [Datadog で Tailscale プライベート ネットワークの状態を監視する][6] + +[1]: https://tailscale.com/ +[2]: https://tailscale.com/kb/1203/audit-logging/ +[3]: https://tailscale.com/kb/1219/network-flow-logs/ +[4]: https://docs.datadoghq.com/ja/account_management/api-app-keys/ +[5]: https://docs.datadoghq.com/ja/help/ +[6]: https://www.datadoghq.com/blog/monitor-tailscale-with-datadog/ \ No newline at end of file diff --git a/content/ja/integrations/teradata.md b/content/ja/integrations/teradata.md index b0cd81bb0e012..40e482d7455e9 100644 --- a/content/ja/integrations/teradata.md +++ b/content/ja/integrations/teradata.md @@ -19,8 +19,8 @@ assets: source_type_id: 10275 source_type_name: Teradata monitors: - High disk space: assets/monitors/high_disk_space.json - Low ready threads: assets/monitors/low_ready_threads.json + Database ready thread count is too low: assets/monitors/low_ready_threads.json + Datadase disk space usage is high: assets/monitors/high_disk_space.json author: homepage: https://www.datadoghq.com name: Datadog @@ -29,7 +29,7 @@ author: categories: - キャッシュ - data stores -custom_kind: integration +custom_kind: インテグレーション dependencies: - https://github.com/DataDog/integrations-core/blob/master/teradata/README.md display_on_public_website: true @@ -37,7 +37,7 @@ draft: false git_integration_title: teradata integration_id: teradata integration_title: Teradata -integration_version: 2.2.1 +integration_version: 4.0.0 is_public: true manifest_version: 2.0.0 name: teradata @@ -104,7 +104,7 @@ CREATE USER "datadog" AS PASSWORD=""; 任意ですが、強くお勧めします。読み取り専用で監視するために指定された `datadog` ユーザーに新規または既存のロールを付与します。 ```shell -GRANT "" TO "datadog"; +GRANT "" TO "datadog"; ``` Teradata システムは、デフォルトでほとんどの [Data Dictionary ビュー][12]で PUBLIC に `SELECT` 権限を付与しています。すべての Teradata Database ユーザーは `PUBLIC` 権限を持ちます。 @@ -197,4 +197,4 @@ Teradata インテグレーションには、イベントは含まれません [11]: https://docs.datadoghq.com/ja/agent/guide/agent-commands/#agent-status-and-information [12]: https://github.com/DataDog/integrations-core/blob/master/teradata/metadata.csv [13]: https://github.com/DataDog/integrations-core/blob/master/teradata/assets/service_checks.json -[14]: https://docs.datadoghq.com/ja/help/ +[14]: https://docs.datadoghq.com/ja/help/ \ No newline at end of file diff --git a/content/ja/integrations/traffic_server.md b/content/ja/integrations/traffic_server.md index 0e005b6fa4931..3bd79173d8b88 100644 --- a/content/ja/integrations/traffic_server.md +++ b/content/ja/integrations/traffic_server.md @@ -46,7 +46,7 @@ draft: false git_integration_title: traffic_server integration_id: traffic-server integration_title: Traffic Server -integration_version: 3.1.0 +integration_version: 3.2.0 is_public: true manifest_version: 2.0.0 name: traffic_server @@ -132,7 +132,7 @@ stats_over_http.so ## 収集データ ### メトリクス -{{< get-metrics-from-git "traffic-server" >}} +{{< get-metrics-from-git "traffic_server" >}} ### ログ収集 @@ -167,7 +167,7 @@ _Agent バージョン 6.0 以降で利用可能_ Traffic Server インテグレーションには、イベントは含まれません。 ### サービスチェック -{{< get-service-checks-from-git "traffic-server" >}} +{{< get-service-checks-from-git "traffic_server" >}} ## トラブルシューティング diff --git a/content/ja/integrations/vault.md b/content/ja/integrations/vault.md index 3b3b21e5f1c59..bfc06b7b52ffe 100644 --- a/content/ja/integrations/vault.md +++ b/content/ja/integrations/vault.md @@ -43,7 +43,7 @@ draft: false git_integration_title: vault integration_id: vault integration_title: Vault -integration_version: 6.0.0 +integration_version: 6.1.0 is_public: true manifest_version: 2.0.0 name: vault @@ -248,7 +248,7 @@ _Agent バージョン 6.0 以降で利用可能_ ... [Service] ... - ExecStart=/bin/sh -c '/home/vagrant/bin/vault server -config=/home/vagrant/vault_nano/config/vault -log-level="trace" > /var/log/vault.log + ExecStart=/bin/sh -c '/home/vagrant/bin/vault server -config=/home/vagrant/vault_nano/config/vault -log-level="trace" > /var/log/vault.log' ... ``` diff --git a/content/ja/integrations/yarn.md b/content/ja/integrations/yarn.md index e287195f62b2a..9854455e06c06 100644 --- a/content/ja/integrations/yarn.md +++ b/content/ja/integrations/yarn.md @@ -37,7 +37,7 @@ draft: false git_integration_title: yarn integration_id: yarn integration_title: Yarn -integration_version: 5.3.1 +integration_version: 7.1.0 is_public: true manifest_version: 2.0.0 name: yarn diff --git a/content/ja/integrations/zeek.md b/content/ja/integrations/zeek.md new file mode 100644 index 0000000000000..51286625059ff --- /dev/null +++ b/content/ja/integrations/zeek.md @@ -0,0 +1,301 @@ +--- +app_id: zeek +app_uuid: 81ba5f4a-0e85-48c3-9ba3-2e5ea37b1ed2 +assets: + dashboards: + Corelight Suricata: assets/dashboards/corelight_suricata.json + Zeek - Connections: assets/dashboards/zeek_connections.json + Zeek - DHCP: assets/dashboards/zeek_dhcp.json + Zeek - DNS: assets/dashboards/zeek_dns.json + Zeek - Datared: assets/dashboards/zeek_datared.json + Zeek - Detection: assets/dashboards/zeek_detection.json + Zeek - Diagnostics: assets/dashboards/zeek_diagnostics.json + Zeek - Files: assets/dashboards/zeek_files.json + Zeek - Miscellaneous: assets/dashboards/zeek_miscellaneous.json + Zeek - Network Observations: assets/dashboards/zeek_network_observations.json + Zeek - Network Protocols: assets/dashboards/zeek_network_protocols.json + Zeek - Network Protocols (NTP, SNMP, SSL): assets/dashboards/zeek_network_protocols_ntp_snmp_ssl.json + Zeek - Syslog: assets/dashboards/zeek_syslog.json + integration: + auto_install: true + configuration: + spec: assets/configuration/spec.yaml + events: + creates_events: false + service_checks: + metadata_path: assets/service_checks.json + source_type_id: 6777560 + source_type_name: zeek +author: + homepage: https://www.datadoghq.com + name: Datadog + sales_email: info@datadoghq.com (日本語対応) + support_email: help@datadoghq.com +categories: +- ログの収集 +- security +- ネットワーク +custom_kind: インテグレーション +dependencies: +- https://github.com/DataDog/integrations-core/blob/master/zeek/README.md +display_on_public_website: true +draft: false +git_integration_title: zeek +integration_id: zeek +integration_title: Zeek +integration_version: 1.0.0 +is_public: true +manifest_version: 2.0.0 +name: zeek +public_title: Zeek +short_description: Zeek ログからインサイトを得て、Cloud SIEM に接続する +supported_os: +- linux +- macos +tile: + changelog: CHANGELOG.md + classifier_tags: + - Supported OS::Linux + - Supported OS::macOS + - Category::Log Collection + - Category::Security + - Category::Network + - Offering::Integration + - Submitted Data Type::Logs + configuration: README.md#Setup + description: Zeek ログからインサイトを得て、Cloud SIEM に接続する + media: + - caption: Zeek - Connections + image_url: images/zeek_connections.png + media_type: image + - caption: Zeek - DHCP + image_url: images/zeek_dhcp.png + media_type: image + - caption: Zeek - DNS + image_url: images/zeek_dns.png + media_type: image + - caption: Zeek - Network Protocols + image_url: images/zeek_network_protocols.png + media_type: image + - caption: Zeek - Detection + image_url: images/zeek_detection.png + media_type: image + - caption: Zeek - Diagnostics + image_url: images/zeek_diagnostics.png + media_type: image + - caption: Zeek - Files + image_url: images/zeek_files.png + media_type: image + - caption: Zeek - Network Observations + image_url: images/zeek_network_observations.png + media_type: image + overview: README.md#Overview + support: README.md#Support + title: Zeek +--- + + +## 概要 + +[Zeek][1] はネットワーク セキュリティ監視のためのプラットフォームです。Zeek は観測内容を解釈し、高精度かつコンパクトなトランザクションログとファイルコンテンツを生成します。出力は完全にカスタマイズでき、ディスク上で手動レビューする場合や、セキュリティ情報イベント管理 (SIEM) などアナリスト向けのツールで分析する場合に適しています。 + +This integration ingests the following logs: +- 接続ログ +- DNS および DHCP ログ +- ネットワークプロトコル +- ファイル +- 検知 +- その他のイベントタイプ + +標準で用意されているダッシュボードを使えば、ネットワーク接続、DNS と DHCP のアクティビティ、詳細なネットワークプロトコル分析、ファイルおよび証明書の分析、セキュリティ検知と観測、コンプライアンス監視を詳細に可視化できます。 + +## セットアップ + +### インストール + +Zeek インテグレーションをインストールするには、次の Agent インストール コマンドを実行し、以下の手順に従ってください。詳細は [Integration Management][2] ドキュメントを参照してください。 + +**注**: Agent バージョン >= 7.52.0 ではこの手順は不要です。 + +Linux コマンド + ```shell + sudo -u dd-agent -- datadog-agent integration install datadog-zeek==1.0.0 + ``` + +#### オープンソース版 Zeek +1. Zeek マシンに [Agent をインストール][3]してください。 +2. JSON ログ出力用に [Corelight Zeek プラグイン][4]をインストールしてください。 + ``` + /opt/zeek/bin/zkg install corelight/json-streaming-logs + ``` +3. ZKG パッケージをロードしてください。 + ``` + echo -e "\n# Load ZKG packages\n@load packages" >> /opt/zeek/share/zeek/site/local.zeek + ``` +4. Zeek を再起動してください。 + ``` + /opt/zeek/bin/zeekctl install + ``` + ``` + /opt/zeek/bin/zeekctl restart + ``` + +#### Corelight Zeek +* [Datadog Agent][3] がインストールされ、稼働していることを確認してください。 + +### 構成 + +#### オープンソース版 Zeek +1. Datadog Agent で、ログの収集はデフォルトで無効になっています。`datadog.yaml` で有効にします。 + ```yaml + logs_enabled: true + ``` + +2. Zeek ログの収集を開始するには、次の設定ブロックを `zeek.d/conf.yaml` ファイルに追加してください。 + + 利用可能な設定オプションについては[サンプル zeek.d/conf.yaml][5] を参照してください。 + + ```yaml + logs: + - type: file + path: /opt/zeek/logs/current/*.log + exclude_paths: + - /opt/zeek/logs/current/*.*.log + service: zeek + source: zeek + ``` + + **注**: 監視中に未サポートまたは不要なログ ファイルが取り込まれないよう、`exclude_paths` パラメータに対象ログ ファイルのパスを含めてください。 + + + ```yaml + # 除外パスの例 + exclude_paths: + - /opt/zeek/logs/current/ntlm.log + - /opt/zeek/logs/current/radius.log + - /opt/zeek/logs/current/rfb.log + ``` + +3. [Agent を再起動します][6]。 + +#### Corelight Zeek +1. デフォルトでは Datadog Agent でのログ収集は無効になっています。datadog.yaml で有効化してください: + ```yaml + logs_enabled: true + ``` + +2. ログの収集を開始するには、この設定ブロックを `zeek.d/conf.yaml` ファイルに追加してください。 + ```yaml + logs: + - type: tcp + port: + service: corelight + source: zeek + ``` + +3. [Agent を再起動します][6]。 + +4. Corelight から Syslog メッセージを転送する設定 + 1. Web ブラウザを開き、Corelight センサーの IP アドレスまたはホスト名にアクセスします。 + 2. 管理者資格情報でログインします。 + 3. Zeek 設定ページへ移動します。正確なパスはセンサーのファームウェア バージョンによって異なる場合があります。 + 4. 「Zeek」または「Logging」に関連するオプションを探します。一般的なパス例: + - Settings > Logging + - Configuration > Zeek > Logging + 5. Zeek ログ用の syslog 出力を有効にするオプションを見つけ、チェックボックスまたはトグルをオンにします。 + 6. Syslog サーバーの詳細を指定します: + - **Syslog server IP address**: Zeek ログを送信する宛先 IP アドレス + - **Syslog port**: Syslog サーバーが待ち受けているポート (通常は 514) + - **Facility**: 使用する syslog ファシリティ + - **Severity level**: 送信するイベントの最小重大度 + 7. **Save** または **Apply** ボタンをクリックして設定を保存します。 + + +### 検証 + +[Agent の status サブコマンド][7]を実行し、Checks セクションに `zeek` があることを確認します。 + +## 収集データ + +### Logs + +Zeek インテグレーションは以下のログ タイプを収集します。 + +| 形式 | イベントタイプ | +| --------- | -------------- | +| オープンソース版 Zeek - JSON 形式 | conn, dhcp, dns, ftp, http, ntp, rdp, smtp, snmp, socks, ssh, ssl, syslog, tunnel, files, pe, intel, notice, signatures, traceroute, known-certs, known-modbus, known-services, known-hosts, software, x509, dpd, weird, captureloss, reporter, ldap, ldap-search, smb-files, smb-mappings | +| Corelight Zeek - Syslog RFC 3164 (レガシー) 形式 | conn, dhcp, dns, ftp, http, ntp, rdp, smtp, snmp, socks, ssh, ssl, syslog, tunnel, files, pe, intel, notice, signatures, traceroute, known-certs, known-modbus, known-services, known-hosts, software, x509, dpd, weird, captureloss, reporter, ldap, ldap-search, smb-files, smb-mappings, conn-long, conn-red, encrypted-dns, generic-dns-tunnels, smtp-links, suricata-corelight | + +### メトリクス + +Zeek インテグレーションにはメトリクスは含まれていません。 + +### イベント + +Zeek インテグレーションにはイベントは含まれません。 + +### サービスチェック + +Zeek インテグレーションにはサービスチェックは含まれません。 + +## トラブルシューティング + +### オープンソース版 Zeek: + +ログファイルを監視している際に **Permission denied** エラーが表示される場合は、`dd-agent` ユーザーに対してファイルの読み取り権限を付与してください。 + + ```shell + sudo chown -R dd-agent:dd-agent /opt/zeek/current/ + ``` + +### Corelight Zeek: + +**Permission denied while port binding:** + +Agent ログでポートバインド中に **Permission denied** エラーが表示された場合は、以下の手順を参照してください。 + +1. Binding to a port number under 1024 requires elevated permissions. Grant access to the port using the `setcap` command: + ```shell + sudo setcap CAP_NET_BIND_SERVICE=+ep /opt/datadog-agent/bin/agent/agent + ``` + +2. Verify the setup is correct by running the `getcap` command: + + ```shell + sudo getcap /opt/datadog-agent/bin/agent/agent + ``` + + 正しければ、次のように出力されます。 + + ```shell + /opt/datadog-agent/bin/agent/agent = cap_net_bind_service+ep + ``` + + **Note**: Re-run this `setcap` command every time you upgrade the Agent. + +3. [Agent を再起動します][6]。 + +**Data is not being collected:** + +Make sure that traffic is bypassed from the configured port if the firewall is enabled. + +**Port already in use:** + +**Port Already in Use** エラーが表示された場合は、以下の手順を参照してください。例として PORT-NO = 514: + +Syslog を使用しているシステムで、Agent が Zeek ログをポート 514 で受信しようとすると、Agent ログに次のエラーが表示されることがあります: `Can't start UDP forwarder on port 514: listen udp :514: bind: address already in use` + +このエラーは、Syslog がデフォルトでポート 514 を使用しているために発生します。次のいずれか**一つ**の方法で解決してください: +- Syslog を無効化する +- Agent が他の空きポートで待ち受けるように設定する + +さらにサポートが必要な場合は [Datadog サポート][8]までお問い合わせください。 + +[1]: https://zeek.org/ +[2]: https://docs.datadoghq.com/ja/agent/guide/integration-management/?tab=linux#install +[3]: https://docs.datadoghq.com/ja/agent/ +[4]: https://github.com/corelight/json-streaming-logs +[5]: https://github.com/DataDog/integrations-core/blob/master/cisco_secure_firewall/datadog_checks/cisco_secure_firewall/data/conf.yaml.example +[6]: https://docs.datadoghq.com/ja/agent/guide/agent-commands/#start-stop-and-restart-the-agent +[7]: https://docs.datadoghq.com/ja/agent/guide/agent-commands/#agent-status-and-information +[8]: https://docs.datadoghq.com/ja/help/ \ No newline at end of file diff --git a/content/ja/integrations/zoom_activity_logs.md b/content/ja/integrations/zoom_activity_logs.md new file mode 100644 index 0000000000000..3aec98f0d73ed --- /dev/null +++ b/content/ja/integrations/zoom_activity_logs.md @@ -0,0 +1,129 @@ +--- +app_id: zoom-activity-logs +app_uuid: 2297e963-5129-4711-bf04-767d5c929f5e +assets: + dashboards: + zoom-activity-logs: assets/dashboards/zoom_activity_logs_overview.json + integration: + auto_install: false + events: + creates_events: false + service_checks: + metadata_path: assets/service_checks.json + source_type_id: 10394 + source_type_name: Zoom アクティビティログ +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: zoom_activity_logs +integration_id: zoom-activity-logs +integration_title: Zoom アクティビティログ +integration_version: '' +is_public: true +manifest_version: 2.0.0 +name: zoom_activity_logs +public_title: Zoom アクティビティログ +short_description: Zoomからオペレーションログおよびアクティビティログを収集する +supported_os: +- linux +- windows +- macos +tile: + changelog: CHANGELOG.md + classifier_tags: + - Category::Log Collection + - Category::Security + - Submitted Data Type::Logs + - Supported OS::Linux + - Supported OS::Windows + - Supported OS::macOS + - Offering::Integration + configuration: README.md#Setup + description: Zoomからオペレーションログおよびアクティビティログを収集する + media: [] + overview: README.md#Overview + support: README.md#Support + title: Zoom アクティビティログ +--- + + + + +## 概要 +このインテグレーションを使用すると、Zoom アカウント内のアクティビティを把握するための Zoom アクティビティログを収集できます。これにより、次のことが可能になります。 + +- Zoom イベントを環境内の他のサービスのデータと相互参照できます。 +- Zoom イベントデータを使ってカスタムウィジェットやダッシュボードを構築できます。 +- 標準のログパイプラインを使用して [Cloud SIEM][1] の検出ルールを設定できます。 + +Datadog の Zoom インテグレーションでは、[サインインおよびサインアウトのアクティビティ][1]と[オペレーションログ][2]を使用してログを収集し、管理者およびユーザーのアクティビティに関する洞察を提供します。これには以下が含まれます。 + - 新しいユーザーの追加 + - アカウント設定の変更 + - 録画の削除 + - サインインおよびサインアウトアクティビティ + + +## セットアップ + +### インストール + +1. Integrations ページに移動して、「Zoom Activity Log」インテグレーションを検索します。 +3. タイルをクリックします。 +4. インテグレーションをインストールするためにアカウントを追加するには、「Add Account」ボタンをクリックします。 +5. モーダルに表示された手順を確認したら、「Authorize」ボタンをクリックします。Zoom のログインページにリダイレクトされます。 +6. Zoom の管理者アカウントを使用して Zoom にログインします。 +7. Datadog が監査レポートデータを閲覧できるようにする +`report:read:admin` スコープへのアクセスを求める画面が表示されます。「Accept」をクリックします。 +8. 新しいアカウントが追加された状態で、Datadog の Zoom Activity Log タイルにリダイレクトされます。「Account Name」を覚えやすい名称に変更することをおすすめします。 + + +## 権限 + +Datadog for Zoom は以下の OAuth スコープを必要とします。詳細については、[Zoom OAuth スコープのドキュメント][3]を参照してください。 + +### ユーザーレベルのスコープ + +| スコープ | リクエスト理由 | +|--------------------------|----------------------------------------------------------------------------------------------------------------| +| `report:read:admin` | 新しいユーザーの追加、アカウント設定の変更、録画の削除などのイベントを含む、監査用の管理者およびユーザーアクティビティログを読み取ります。また、Zoom アカウントに属するユーザーのサインイン/サインアウトアクティビティログも読み取ります。 | + + +### アプリの削除 +Zoom Activity Log インテグレーションをアンインストールするには、Zoom Activity Log タイルに移動し、アカウントテーブルに表示されている既存のアカウントを削除してください。 + + +## 収集データ + +### メトリクス + +Zoom アクティビティログにはメトリクスは含まれていません。 + +### サービスチェック + +Zoom アクティビティログにはサービスチェックは含まれていません。 + +### Logs +Zoom アクティビティログは、Zoom の [Sign In and Out Activity Log][1] および [Operation Log][2] エンドポイントからデータを収集します。 + +### イベント + +Zoom アクティビティログにはイベントは含まれていません。 + +## トラブルシューティング + +ご不明な点は、[Datadog のサポートチーム][4]までお問合せください。 + + +[1]: https://developers.zoom.us/docs/api/rest/reference/zoom-api/methods/#operation/reportSignInSignOutActivities +[2]: https://developers.zoom.us/docs/api/rest/reference/zoom-api/methods/#operation/reportOperationLogs +[3]: https://developers.zoom.us/docs/integrations/oauth-scopes-granular/#reports +[4]: https://docs.datadoghq.com/ja/help/ \ No newline at end of file diff --git a/content/ja/logs/_index.md b/content/ja/logs/_index.md index 3844fa03b2891..0f107be123693 100644 --- a/content/ja/logs/_index.md +++ b/content/ja/logs/_index.md @@ -66,8 +66,6 @@ Datadog ログ管理 (Datadog Logs または Logging とも呼ばれる) は、 Logging without Limits\* は、[ログエクスプローラー][1]でトラブルシューティングを合理化し、インフラストラクチャーの問題を迅速に評価および修正する力を提供します。また、直感的なアーカイブ機能により、監査や評価時にセキュリティチームや IT チームをサポートします。[Datadog Cloud SIEM][2] は、ログのインデックスを作成することなく、環境内のセキュリティ脅威を検出します。 -**注**: PCI 準拠の Datadog 組織のセットアップに関する情報については、[PCI DSS 準拠][3]を参照してください。 - {{< vimeo url="https://player.vimeo.com/progressive_redirect/playback/293195142/rendition/1080p/file.mp4?loc=external&signature=8a45230b500688315ef9c8991ce462f20ed1660f3edff3d2904832e681bd6000" poster="/images/poster/logs.png" >}}
@@ -110,7 +108,7 @@ Logging without Limits\* は、[ログエクスプローラー][1]でトラブ 実際のクラウドコンピュートキャパシティと Datadog のトライアルアカウントを使用して、コストをかけずに学ぶことができます。今すぐ登録して、ログの収集、クエリ、分析、メトリクス、監視、処理、ストレージ、アクセス制御を学習しましょう。 {{< /learning-center-callout >}} -## その他の参考資料 +## 参考情報 {{< partial name="whats-next/whats-next.html" >}}
@@ -118,7 +116,6 @@ Logging without Limits\* は、[ログエクスプローラー][1]でトラブ [1]: /ja/logs/explorer/ [2]: /ja/security/cloud_siem/ -[3]: /ja/data_security/pci_compliance/ [4]: /ja/logs/log_collection/ [5]: /ja/logs/log_configuration/ [6]: /ja/tracing/other_telemetry/connect_logs_and_traces/ diff --git a/content/ja/logs/explorer/search.md b/content/ja/logs/explorer/search.md index 3293b383f52e7..128cd3e74a56b 100644 --- a/content/ja/logs/explorer/search.md +++ b/content/ja/logs/explorer/search.md @@ -17,13 +17,31 @@ title: ログを検索 ## 概要 -個々のログからの情報はリストとして視覚化すると便利ですが、集計することで価値ある情報にアクセスできる場合もあります。この情報にアクセスするには、[ログエクスプローラー][5]でログを検索し、時系列、トップリスト、ツリーマップ、円グラフまたはテーブルとして表示します。 +[Logs Explorer][5] を使用すると、個々のログをリストとして検索・表示できます。ただし、最も価値のあるインサイトはログを大規模に集約することで得られることが多いです。検索機能を使用してログをフィルタリングし、時系列チャート、トップ リスト、ツリー マップ、円グラフ、またはテーブルとして可視化することで、ログ データ全体のトレンド、パターン、外れ値を把握できます。 -ログエクスプローラーの検索は、時間範囲と検索クエリからなり、`key:value` 検索と[全文検索][6]が混在しています。 +## 自然言語クエリ + +{{% site-region region="gov" %}} +
+Natural Language Queries は Datadog サイト ({{< region-param key="dd_site_name" >}}) では利用できません。 +
+{{% /site-region %}} + +
Logs 用 Natural Language Queries (NLQ) は Llama を使用して構築されています。
+ +Natural Language Queries (NLQ) を使用すると、探している内容を平易な英語で記述できます。Datadog がリクエストを自動的に構造化されたログ クエリへ変換するため、複雑な構文を記述せずにログを探索できます。この機能にアクセスするには、検索フィールドの **Ask** をクリックします。 + +{{< img src="/logs/explorer/search/log_explorer_nlq.mp4" alt="Logs Explorer で自然言語クエリを使用して、平易な英語のフレーズでログを検索する方法を示す" video=true >}} + +システムは自然言語の入力を Datadog クエリに変換し、サービス、属性、タグ、時間範囲などのコンテキストを理解します。また、関連フィールドを自動的に検出し、「Top 20 services by errors」や「Show errors from service X in the past 24 hours」のような簡単な説明から可視化を作成できます。 + +NLQ を無効にするには [`org_management` permissions][8] が必要です。[Organization Settings > Preferences][7] に移動し、Natural Language Queries 機能をオフに切り替えてください。 ## 検索クエリ -例えば、過去 15 分間に Web ストアサービスがエラーステータスで生成したログをフィルタリングするには、`service:payment status:error rejected` のようなカスタムクエリを作成し、時間範囲を `Past 15 minutes` に設定します。 +Log Explorer の検索は時間範囲と検索クエリで構成され、`key:value` と [全文検索][6] を組み合わせて使用します。 + +Web ストア サービスが生成したログのうちステータスが error のものを過去 15 分間でフィルタリングするには、`service:payment status:error rejected` のようなカスタム クエリを作成し、時間範囲を `Past 15 minutes` に設定します。 {{< img src="logs/explorer/search_filter.png" alt="ログエクスプローラーで、Web ストアサービスの支払い拒否のエラーログをフィルターする検索クエリを作成する" style="width:100%;" >}} @@ -42,7 +60,7 @@ title: ログを検索 ### ファセットと値のオートコンプリート -検索バーは、検索バーに入力された内容に基づきファセットを自動で提案します。これらのファセットは、[ファセットパネル][5]内での位置と同じ順番で表示されます。ファセットの表示名が定義されている場合は、ドロップダウンメニューの右側に表示されます。ファセットパネルに表示されるように設定されていないファセットは、検索時に自動提案されません。 +検索バーは入力内容に基づいてファセットを自動提案します。これらのファセットは [ファセット パネル][5] での配置順と同じ順序で表示されます。ファセットに表示名が定義されている場合、その名前はドロップダウン メニューの右側に表示されます。 {{< img src="logs/explorer/search/log_facet_autocomplete.png" alt="クエリとして `network` が、オートコンプリートのオプションとしてファセット @network.bytes_written、@network.client.ip、@network.interface が表示されているログ検索バー" style="width:80%;">}} @@ -94,4 +112,6 @@ title: ログを検索 [3]: /ja/logs/search-syntax [4]: /ja/dashboards/guide/custom_time_frames [5]: /ja/logs/explorer/ -[6]: /ja/logs/explorer/search_syntax/#full-text-search \ No newline at end of file +[6]: /ja/logs/explorer/search_syntax/#full-text-search +[7]: https://app.datadoghq.com/organization-settings/preferences +[8]: /ja/account_management/rbac/permissions/#access-management \ No newline at end of file diff --git a/content/ja/logs/guide/aws-account-level-logs.md b/content/ja/logs/guide/aws-account-level-logs.md new file mode 100644 index 0000000000000..32bf719d3afad --- /dev/null +++ b/content/ja/logs/guide/aws-account-level-logs.md @@ -0,0 +1,268 @@ +--- +further_reading: +- link: /logs/explorer/ + tag: ドキュメント + text: ログの調査方法 +title: AWS アカウントレベルのログサブスクリプション +--- + +## 概要 + +アカウントレベルのログサブスクリプションを使用すると、AWS 環境の CloudWatch Logs をすべて自動で Datadog に転送できます。アカウントレベルのログサブスクリプションを利用すれば、新しいログソースを追加したときや AWS が新しいサービスをリリースしたときに、手動でログ転送を設定する必要がありません。また、転送対象となるログをより細かく制御するために、独自の選択条件やフィルタパターンを定義することも可能です。 + +## アカウントレベルのログサブスクリプションを作成する + +アカウントレベルのログサブスクリプションを作成する方法は、[CloudFormation](#cloudformation-recommended) と [マニュアルでの設定](#manual) の 2 つがあります。最も簡単なセットアップ方法としては、CloudFormation を使って選択した各リージョンに Amazon Data Firehose と関連リソースを作成できます。 + +### CloudFormation (推奨) + +1. CloudFormation テンプレートの URL をコピーします。 + +{{< code-block lang="bash" filename="" disable_copy="false" >}} +https://datadog-cloudformation-template.s3.amazonaws.com/aws_account_level_logs/main.yaml +{{< /code-block >}} + +2. AWS コンソールで [CloudFormation][1] を開きます。 +3. **Create stack** をクリックします。 + - `With new resources (standard)` を選択します。 +4. **Choose an existing template** と **Amazon S3 URL** のオプションは既定のままにします。 +5. **Amazon S3 URL** フィールドに、先ほどコピーした CloudFormation テンプレートの URL を貼り付けます。 +6. **Next** をクリックします。 +7. **Stack name** フィールドに、`datadog-account-level-logs-stack` のようなわかりやすい名前を入力します。 +8. **ApiKey** フィールドに、有効な [Datadog API キー][4] を貼り付けます。 +9. **Regions** フィールドに、アカウントレベルのログサブスクリプションを適用したい AWS リージョンコード (例: `us-east-1`) をカンマ区切りで入力します。 +10. **DatadogHttpEndpointUrl** フィールドで、利用している [Datadog サイト][5] に対応する URL を選択します。 +11. **Next** をクリックします。 +12. 必要に応じて追加のスタックオプションを設定します。 +13. **Next** をクリックします。 +14. スタックオプションを確認し、`I acknowledge that AWS CloudFormation might create IAM resources with custom names` チェックボックスを選択します。 +15. **Submit** をクリックします。 + +### 手動 + +{{< tabs >}} +{{% tab "Lambda Forwarder" %}} + +1. まだ設定していない場合は、[Datadog Forwarder][101] Lambda 関数をセットアップします。 +2. [AWS CLI][102] を使って、CloudWatch Logs に関数を実行する権限を付与します。 + - `` は Datadog Forwarder Lambda 関数があるリージョンに置き換えてください。 + - `` はハイフンを除いた 12 桁の AWS アカウント ID に置き換えてください。 + +```bash +aws lambda add-permission \ + --region "" \ + --function-name "forwarder-function" \ + --statement-id "forwarder-function" \ + --principal "logs.amazonaws.com" \ + --action "lambda:InvokeFunction" \ + --source-arn "arn:aws:logs:::log-group:*" \ + --source-account "" +``` + +3. アカウントレベルのサブスクリプションフィルタポリシーを作成します。以下の例では、`ERROR` という文字列を含むすべてのログイベントがストリーミングされますが、`LogGroupToExclude1` と `LogGroupToExclude2` というロググループは除外されます。 + - `FORWARDER_ARN` は Datadog Forwarder Lambda 関数の ARN に置き換えてください。 + +```bash +aws logs put-account-policy \ + --policy-name "ExamplePolicyLambda" \ + --policy-type "SUBSCRIPTION_FILTER_POLICY" \ + --policy-document '{"DestinationArn":"", "FilterPattern": "", "Distribution": "Random"}' \ + --scope "ALL" +``` + +**注**: 特定のロググループをログ転送の対象外にするには、[コマンドリファレンス][103]の説明にあるように `--selection-criteria` オプションを使用してください。 + +[101]: /ja/logs/guide/send-aws-services-logs-with-the-datadog-lambda-function/ +[102]: https://aws.amazon.com/cli/ +[103]: https://docs.aws.amazon.com/cli/latest/reference/logs/put-account-policy.html +{{% /tab %}} +{{% tab "Amazon Data Firehose" %}} + +#### Amazon Data Firehose 用の S3 バケットとロールを作成する + +以下の手順では、バケットと IAM ロールの作成方法を案内します。このロールは Amazon Data Firehose が配信失敗時に Amazon S3 バケットにデータを保存できるよう権限を付与するロールです。 + +1. [AWS CLI][201] を使って S3 バケットを作成します。既存のバケットを使うことも可能です。 + - `` は S3 バケットの名前に、 + - `` はバケットを作成するリージョンに置き換えてください。 + +``` +aws s3api create-bucket \ + --bucket MY-BUCKET \ + --create-bucket-configuration LocationConstraint= +``` + +2. `TrustPolicyForFirehose.json` というファイルを作成し、以下のステートメントを含めます。 + +```bash +{ + "Statement": { + "Effect": "Allow", + "Principal": { "Service": "firehose.amazonaws.com" }, + "Action": "sts:AssumeRole" + } +} +``` + +3. IAM ロールを作成し、上記の信頼ポリシーファイルを指定します。 + **注**: ここで返される **Role.Arn** は後のステップで使用します。 + +```bash +aws iam create-role \ + --role-name FirehosetoS3Role \ + --assume-role-policy-document file://./TrustPolicyForFirehose.json +``` + +4. `PermissionsForFirehose.json` というファイルを作成し、以下のステートメントを含めます。 + - `` は対象の S3 バケット名に置き換えてください。 + +```bash +{ + "Statement": [ + { + "Effect": "Allow", + "Action": [ + "s3:AbortMultipartUpload", + "s3:GetBucketLocation", + "s3:GetObject", + "s3:ListBucket", + "s3:ListBucketMultipartUploads", + "s3:PutObject" ], + "Resource": [ + "arn:aws:s3:::", + "arn:aws:s3:::/*" ] + } + ] +} +``` +5. このロールに権限ポリシーを関連付けます。 + +```bash +aws iam put-role-policy \ + --role-name FirehosetoS3Role \ + --policy-name Permissions-Policy-For-Firehose \ + --policy-document file://./PermissionsForFirehose.json +``` + +#### Amazon Data Firehose 配信ストリームを作成する + +以下の手順では、Amazon Data Firehose の配信ストリームを作成し、設定する方法を説明します。 + +1. AWS コンソールで [Amazon Data Firehose][202] を開きます。 +2. **Create Firehose stream** をクリックします。 +3. **Source** フィールドでログのソースを選択します。 + - ログソースが Kinesis Data Streams の場合は `Amazon Kinesis Data Streams` を選択します。 + - ログソースが CloudWatch Logs の場合は `Direct PUT` を選択します。 +4. **Destination** フィールドで `Datadog` を選択します。 +5. **Source** が `Amazon Kinesis Data Streams` の場合は、**Source settings** で使用する Kinesis データストリームを選択します。 +6. 必要に応じて、配信ストリームにわかりやすい名前を付けることもできます。 +7. **Destination settings** セクションで、お使いの [Datadog サイト][203]に対応する Datadog ログの HTTP エンドポイント URL を選択します。 +8. **Authentication** には有効な [Datadog API キー][204]が必要です。以下のいずれかを選択できます。 + - **Use API key** を選び、**API key** フィールドにキーの値を貼り付ける + - **Use AWS Secrets Manager** を選び、有効な Datadog API キーの値を含むシークレットを **Secret name** ドロップダウンで選択する +9. **Content encoding** には `GZIP` を選択します。 +10. 任意で、**Retry duration**、バッファ設定、あるいは **Parameters** (ログのタグとして付与されます) を設定できます。 + **注**: ログが 1 行ごとのメッセージである場合、Datadog では **Buffer size** を `2` MiB に設定することを推奨しています。 +11. **Backup settings** セクションでは、再試行期間を超えたイベントのバックアップ先となる S3 バケットを選択します。 + **注**: 配信ストリームによりログが転送できなかった場合でも Datadog に送信されるようにするには、この S3 バケットから[ログを転送するよう Datadog Forwarder Lambda 関数][205]を設定してください。 +12. **Create Firehose stream** をクリックします。 + +#### CloudWatch Logs 用のロールを作成する + +以下の手順では、CloudWatch Logs 用の IAM ロールを作成します。このロールにより、CloudWatch Logs に Firehose 配信ストリームへデータを送信する権限を付与します。 + +1. `./TrustPolicyForCWL.json` ファイルを作成し、以下のステートメントを記述します。 + - `` はハイフンを除いた 12 桁の AWS アカウント ID に、 + - `` は CloudWatch Logs が存在するリージョンに置き換えてください。 + +```bash +{ + "Statement": { + "Effect": "Allow", + "Principal": { "Service": "logs.amazonaws.com" }, + "Action": "sts:AssumeRole", + "Condition": { + "StringLike": { + "aws:SourceArn": "arn:aws:logs:::*" + } + } + } +} +``` +2. IAM ロールを作成し、上記の信頼ポリシーファイルを指定します。 + +```bash +aws iam create-role \ + --role-name CWLtoKinesisFirehoseRole \ + --assume-role-policy-document file://./TrustPolicyForCWL.json +``` + **注**: ここで返される **Role.Arn** は後のステップで使用します。 + +3. `./PermissionsForCWL.json` ファイルを作成し、以下のステートメントを記述します。 + - `` は Datadog Forwarder Lambda 関数が存在するリージョンに、 + - `` はハイフンを除いた 12 桁の AWS アカウント ID に、 + - `` は作成した配信ストリームの名前に置き換えてください。 + +```bash +{ + "Statement":[ + { + "Effect":"Allow", + "Action":["firehose:PutRecord"], + "Resource":[ + "arn:aws:firehose:::deliverystream/"] + } + ] +} +``` + +4. このロールに権限ポリシーを関連付けます。 + +```bash +aws iam put-role-policy \ + --role-name CWLtoKinesisFirehoseRole \ + --policy-name Permissions-Policy-For-CWL \ + --policy-document file://./PermissionsForCWL.json +``` + +#### CloudWatch Logs アカウントレベルのサブスクリプションフィルタポリシーを作成する + +この手順を完了する前に、Amazon Data Firehose の配信ストリームが `Active` 状態であることを確認してください。 + +1. CloudWatch Logs のアカウントレベルのサブスクリプションフィルタポリシーを作成します。これにより、指定したロググループから Amazon Data Firehose 配信ストリームへリアルタイムでログが転送され始めます。 + - `` をサブスクリプションフィルタポリシーの名前に、 + - `` を作成した CloudWatch Logs ロールの ARN に、 + - `` を Amazon Data Firehose 配信ストリームの ARN に置き換えてください。 + +```bash +aws logs put-account-policy \ + --policy-name "" \ + --policy-type "SUBSCRIPTION_FILTER_POLICY" \ + --policy-document '{"RoleArn":"", "DestinationArn":"", "FilterPattern": "", "Distribution": "Random"}' \ + --scope "ALL" +``` + +**注**: 特定のロググループを転送対象から除外するには、[コマンドリファレンス][206]にあるように `--selection-criteria` オプションを使用してください。 + +[201]: https://aws.amazon.com/cli/ +[202]: https://console.aws.amazon.com/firehose/home +[203]: /ja/getting_started/site/ +[204]: https://app.datadoghq.com/organization-settings/api-keys +[205]: /ja/logs/guide/send-aws-services-logs-with-the-datadog-lambda-function/?tab=automaticcloudformation#collecting-logs-from-s3-buckets +[206]: https://docs.aws.amazon.com/cli/latest/reference/logs/put-account-policy.html +{{% /tab %}} +{{< /tabs >}} + +### 検証 + +[Log Explorer][2] に移動し、検索クエリ `@aws.firehose.arn:""` を入力すると、Amazon Data Firehose によって転送されたログを確認できます。 + - `` はログストリーミング用の [Firehose][3] の ARN に置き換えてください。 + +## 参考資料 +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://console.aws.amazon.com/cloudformation/home +[2]: https://app.datadoghq.com/logs +[3]: https://console.aws.amazon.com/firehose/home +[4]: https://app.datadoghq.com/organization-settings/api-keys +[5]: /ja/getting_started/site/ \ No newline at end of file diff --git a/content/ja/logs/guide/custom-log-file-with-heightened-read-permissions.md b/content/ja/logs/guide/custom-log-file-with-heightened-read-permissions.md index b6ec9a845b091..31520e059c9db 100644 --- a/content/ja/logs/guide/custom-log-file-with-heightened-read-permissions.md +++ b/content/ja/logs/guide/custom-log-file-with-heightened-read-permissions.md @@ -14,15 +14,15 @@ further_reading: title: 高度な読み取り権限を持つカスタムログファイルからのログ送信 --- -Often, log files, especially system logs such as *syslog* or *journald*, have heightened read-permissions blocking the Datadog Agent log collection as it does not have *sudo* or *admin* access. +多くの場合、*syslog* や *journald* などのシステムログを含むログファイルは読み取り権限が厳しく設定されているため、*sudo* や *admin* アクセス権を持たない Datadog Agent がログを収集できないことがあります。 -There are three potential solutions to get around this: +この問題を回避する方法は 3 つあります。 -* (Not Recommended) Give the Agent root access so it can tail those files. Datadog strongly recommends against going this route. -* Change the file permission to let the Agent access it. The Agent needs execute and read permissions on the directories and also read permission on the file. Run the following commands to provide those permissions (for any user, not just the Agent): +* (非推奨) Agent に root アクセス権を付与してファイルを tail できるようにする。Datadog ではこの方法を強く非推奨としています。 +* ファイルの権限を変更して Agent がアクセスできるようにする。Agent にはディレクトリに対する実行権限と読み取り権限、ファイルに対する読み取り権限が必要です。以下のコマンドを実行して (Agent だけでなく任意のユーザーに) これらの権限を付与します。 * chmod 755 `` * chmod 644 `` -* Configure an open source log shipper (such as Rsyslog, NXLog, ...) that has root access to send those logs either directly to your Datadog platform or locally to a running Datadog Agent. For instructions, read the dedicated documentation for [Rsyslog][1], [Syslog-ng][2], [NXlog][3], [FluentD][4], or [Logstash][5]. +* root アクセス権を持つオープンソースのログシッパー (Rsyslog、NXLog など) を構成し、これらのログを直接 Datadog プラットフォームに送信するか、ローカルで稼働している Datadog Agent に送信する。設定手順については [Rsyslog][1]、[Syslog-ng][2]、[NXLog][3]、[FluentD][4]、[Logstash][5] の各ドキュメントを参照してください。 {{< partial name="whats-next/whats-next.html" >}} diff --git a/content/ja/logs/log_collection/_index.md b/content/ja/logs/log_collection/_index.md index b39d97ec81821..1f3a34b8fe5e1 100644 --- a/content/ja/logs/log_collection/_index.md +++ b/content/ja/logs/log_collection/_index.md @@ -148,7 +148,6 @@ Datadog では、SSL で暗号化された接続と暗号化されていない | サイト | タイプ | エンドポイント | ポート | 説明 | |------|-------------|---------------------------------------------------------------------------|--------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | US | HTTPS | `http-intake.logs.datadoghq.com` | 443 | HTTPS 経由で JSON またはプレーンテキスト形式のログを送信するためにカスタムフォワーダーが使用。[Logs HTTP API のドキュメント][1]参照。 | -| US | HTTPS | `agent-http-intake-pci.logs.datadoghq.com` | 443 | Agent が PCI DSS コンプライアンスを有効にした組織へ HTTPS でログを送信するために使用します。詳しくは、[ログ管理のための PCI DSS コンプライアンス][3]を参照してください。 | | US | HTTPS | `agent-http-intake.logs.datadoghq.com` | 443 | HTTPS 経由で JSON 形式のログを送信するために Agent が使用。[ホスト Agent ログ収集のドキュメント][2]参照。 | | US | HTTPS | `lambda-http-intake.logs.datadoghq.com` | 443 | HTTPS 経由で未加工、Syslog、または JSON 形式のログを送信するために Lambda 関数が使用。 | | US | HTTPS | `logs.`{{< region-param key="browser_sdk_endpoint_domain" code="true" >}} | 443 | Browser SDK が HTTPS で JSON 形式のログを送信するために使用します。 | @@ -160,12 +159,11 @@ Datadog では、SSL で暗号化された接続と暗号化されていない [1]: /ja/api/latest/logs/#send-logs [2]: /ja/agent/logs/#send-logs-over-https -[3]: /ja/data_security/logs/#pci-dss-compliance-for-log-management {{< /site-region >}} {{< site-region region="eu" >}} -| サイト | タイプ | エンドポイント | ポート | 説明 | +| サイト | タイプ | エンドポイント | ポート | Description | |------|-------------|---------------------------------------------------------------------------|------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | EU | HTTPS | `http-intake.logs.datadoghq.eu` | 443 | HTTPS 経由で JSON またはプレーンテキスト形式のログを送信するためにカスタムフォワーダーが使用。[Logs HTTP API のドキュメント][1]参照。 | | EU | HTTPS | `agent-http-intake.logs.datadoghq.eu` | 443 | HTTPS 経由で JSON 形式のログを送信するために Agent が使用。[ホスト Agent ログ収集のドキュメント][2]参照。 | @@ -181,7 +179,7 @@ Datadog では、SSL で暗号化された接続と暗号化されていない {{< site-region region="us3" >}} -| サイト | タイプ | エンドポイント | ポート | 説明 | +| サイト | タイプ | エンドポイント | ポート | Description | |------|-------|--------------------------------------------- |------|--------------------------------------------------------------------------------------------------------------------------| | US3 | HTTPS | `http-intake.logs.us3.datadoghq.com` | 443 | HTTPS 経由で JSON またはプレーンテキスト形式のログを送信するためにカスタムフォワーダーが使用。[Logs HTTP API のドキュメント][1]参照。 | | US3 | HTTPS | `lambda-http-intake.logs.us3.datadoghq.com` | 443 | HTTPS 経由で未加工、Syslog、または JSON 形式のログを送信するために Lambda 関数が使用。 | @@ -195,7 +193,7 @@ Datadog では、SSL で暗号化された接続と暗号化されていない {{< site-region region="us5" >}} -| サイト | タイプ | エンドポイント | ポート | 説明 | +| サイト | タイプ | エンドポイント | ポート | Description | |------|-------|---------------------------------------------------------------------------|------|--------------------------------------------------------------------------------------------------------------------------| | US5 | HTTPS | `http-intake.logs.us5.datadoghq.com` | 443 | HTTPS 経由で JSON またはプレーンテキスト形式のログを送信するためにカスタムフォワーダーが使用。[Logs HTTP API のドキュメント][1]参照。 | | US5 | HTTPS | `lambda-http-intake.logs.us5.datadoghq.com` | 443 | HTTPS 経由で未加工、Syslog、または JSON 形式のログを送信するために Lambda 関数が使用。 | @@ -209,7 +207,7 @@ Datadog では、SSL で暗号化された接続と暗号化されていない {{< site-region region="ap1" >}} -| サイト | タイプ | エンドポイント | ポート | 説明 | +| サイト | タイプ | エンドポイント | ポート | Description | |------|-------|---------------------------------------------------------------------------|------|--------------------------------------------------------------------------------------------------------------------------| | AP1 | HTTPS | `http-intake.logs.ap1.datadoghq.com` | 443 | HTTPS 経由で JSON またはプレーンテキスト形式のログを送信するためにカスタムフォワーダーが使用。[Logs HTTP API のドキュメント][1]参照。 | | AP1 | HTTPS | `lambda-http-intake.logs.ap1.datadoghq.com` | 443 | HTTPS 経由で未加工、Syslog、または JSON 形式のログを送信するために Lambda 関数が使用。 | @@ -221,9 +219,23 @@ Datadog では、SSL で暗号化された接続と暗号化されていない {{< /site-region >}} +{{< site-region region="ap2" >}} + +| サイト | タイプ | エンドポイント | ポート | Description | +|------|-------|---------------------------------------------------------------------------|------|--------------------------------------------------------------------------------------------------------------------------| +| AP2 | HTTPS | `http-intake.logs.ap2.datadoghq.com` | 443 | HTTPS 経由で JSON またはプレーンテキスト形式のログを送信するためにカスタムフォワーダーが使用。[Logs HTTP API のドキュメント][1]参照。 | +| AP2 | HTTPS | `lambda-http-intake.logs.ap2.datadoghq.com` | 443 | HTTPS 経由で未加工、Syslog、または JSON 形式のログを送信するために Lambda 関数が使用。 | +| AP2 | HTTPS | `agent-http-intake.logs.ap2.datadoghq.com` | 443 | HTTPS 経由で JSON 形式のログを送信するために Agent が使用。[ホスト Agent ログ収集のドキュメント][2]参照。 | +| AP2 | HTTPS | {{< region-param key="browser_sdk_endpoint_domain" code="true" >}} | 443 | Browser SDK が HTTPS で JSON 形式のログを送信するために使用します。 | + +[1]: /ja/api/latest/logs/#send-logs +[2]: /ja/agent/logs/#send-logs-over-https + +{{< /site-region >}} + {{< site-region region="gov" >}} -| サイト | タイプ | エンドポイント | ポート | 説明 | +| サイト | タイプ | エンドポイント | ポート | Description | |---------|-------|---------------------------------------------------------------------------|------|--------------------------------------------------------------------------------------------------------------------------| | US1-FED | HTTPS | `http-intake.logs.ddog-gov.com` | 443 | HTTPS 経由で JSON またはプレーンテキスト形式のログを送信するためにカスタムフォワーダーが使用。[Logs HTTP API のドキュメント][1]参照。 | | US1-FED | HTTPS | `lambda-http-intake.logs.ddog-gov.datadoghq.com` | 443 | HTTPS 経由で未加工、Syslog、または JSON 形式のログを送信するために Lambda 関数が使用。 | @@ -350,7 +362,11 @@ TCP エンドポイントは、このサイトでは推奨していません。 この機能を使用するには、以下の属性名を使用します。 +<<<<<<< HEAD | 属性 | 説明 | +======= +| 属性 | Description | +>>>>>>> 37c1c0d9e6 (Translated file updates) |----------------------|-------------------------------------------------------------------------| | `logger.name` | ロガーの名前 | | `logger.thread_name` | 現在のスレッドの名前 | @@ -368,7 +384,7 @@ TCP エンドポイントは、このサイトでは推奨していません。 {{< img src="logs/explore.png" alt="ログエクスプローラーに表示されるログ" style="width:100%" >}} -## その他の参考資料 +## 参考情報 {{< partial name="whats-next/whats-next.html" >}}
diff --git a/content/ja/logs/log_configuration/_index.md b/content/ja/logs/log_configuration/_index.md index e074dc5f4b681..19a613faaec7f 100644 --- a/content/ja/logs/log_configuration/_index.md +++ b/content/ja/logs/log_configuration/_index.md @@ -5,7 +5,7 @@ description: ログコンフィギュレーションページからログを処 further_reading: - link: /data_security/pci_compliance/ tag: ドキュメント - text: PCI 準拠の Datadog 組織をセットアップする + text: PCI DSS 準拠 - link: https://www.datadoghq.com/blog/logging-without-limits/ tag: ブログ text: Logging without Limits* の詳細 @@ -25,8 +25,6 @@ title: ログコンフィギュレーション Datadog Logging without Limits* は、ログの取り込みとインデックス作成を切り離します。[**Logs > Pipelines**][1] のログ構成ページから、インデックスを作成して保持するログ、またはアーカイブするログを選択し、トップレベルで設定と制御を管理します。 -**注**: PCI 準拠の Datadog 組織をセットアップするための情報は、[PCI DSS 準拠][2]をご覧ください。 - ## コンフィギュレーションオプション - [パイプライン][3]と[プロセッサ][4]を使用してログを処理する方法を制御します。 @@ -41,7 +39,7 @@ Datadog Logging without Limits* は、ログの取り込みとインデックス コンフィギュレーションが完了したら、[ログエクスプローラー][11]でログの調査とトラブルシューティングを開始します。 -## その他の参考資料 +## 参考情報 {{< partial name="whats-next/whats-next.html" >}} diff --git a/content/ja/logs/log_configuration/indexes.md b/content/ja/logs/log_configuration/indexes.md index 048313f0c88ae..0b1ab063765af 100644 --- a/content/ja/logs/log_configuration/indexes.md +++ b/content/ja/logs/log_configuration/indexes.md @@ -29,7 +29,7 @@ title: インデックス デフォルトでは、新しい各アカウントは、すべてのログのモノリシックセットを表す単一のインデックスを取得します。Datadog では、次が必要な場合に複数のインデックスを使用することを推奨します。 -* 複数の[保持期間](#ログ保持期間の更新) +* 複数の[保持期間](#ログ保持期間の更新) * [1日の割り当て](#日別の割り当てを設定する)を複数使用して、バジェットをより細かく管理したい場合。 Log Explorer は、[複数のインデックスにわたるクエリ][7]をサポートしています。 @@ -53,7 +53,7 @@ Log Explorer は、[複数のインデックスにわたるクエリ][7]をサ {{< img src="logs/indexes/delete-index.png" alt="インデックスを削除" style="width:70%;">}}
-削除されたインデックスと同じ名前のインデックスを再作成することはできません。 +削除されたインデックスと同じ名前のインデックスを再作成することはできません。
**注:** 削除されたインデックスは、今後新しい受信ログを受け付けません。削除されたインデックス内のログは、クエリに使用できなくなります。適用される保持期間に従ってすべてのログがエージングアウトした後、そのインデックスはインデックスページに表示されなくなります。 @@ -77,7 +77,7 @@ Log Explorer は、[複数のインデックスにわたるクエリ][7]をサ 除外フィルターを追加するには 1. [ログインデックス][11]に移動します。 -2. 除外フィルターを追加するパイプラインを展開します。 +2. 除外フィルターを追加したいインデックスを展開します。 3. **Add an Exclusion Filter** をクリックします。 除外フィルターは、クエリ、サンプリング規則、および active/inactive のトグルで定義します。 @@ -135,9 +135,9 @@ Web アクセスサーバーリクエストからのすべてのログを保持 ## ログの保持を更新 -インデックス保持設定は、ログが Datadog に保存され、検索できる期間を決定します。保持は、アカウント構成で許可されている任意の値に設定できます。 +インデックス保持期間設定は、Datadog でログが保存され検索可能な期間を決定します。保持期間は、アカウント設定で許可されている任意の値に設定できます。 -現在の契約に含まれていない追加の保持期間を設定するには、カスタマーサクセス (`success@datadoghq.com`) までご連絡ください。追加保持を有効にした後、インデックスの保持期間を更新する必要があります。 +現在の契約に含まれていない追加の保持期間を有効化するには、Customer Success (`success@datadoghq.com`) までお問い合わせください。追加の保持期間が有効化されたら、各インデックスの保持期間を更新する必要があります。 {{< img src="logs/indexes/log_retention.png" alt="インデックスの詳細" style="width:70%;">}} @@ -159,7 +159,7 @@ Web アクセスサーバーリクエストからのすべてのログを保持 1 日の割り当てまたは警告のしきい値に達すると、イベントが生成されます。 -{{< img src="logs/indexes/index_quota_event.png" alt="インデックスの割り当て数通知" style="width:70%;">}} +{{< img src="logs/indexes/daily_quota_warning_events.png" alt="デイリー クオータと警告イベント" style="width:90%;">}} 使用量を監視してアラートを出す方法については、[ログの使用量を監視する][20]を参照してください。 @@ -188,4 +188,4 @@ Web アクセスサーバーリクエストからのすべてのログを保持 [18]: /ja/logs/live_tail/#overview [19]: https://www.timeanddate.com/worldclock/converter.html [20]: /ja/logs/guide/best-practices-for-log-management/#monitor-log-usage -[21]: /ja/account_management/org_settings/#out-of-contract-retention-periods-for-log-indexes +[21]: /ja/account_management/org_settings/#out-of-contract-retention-periods-for-log-indexes \ No newline at end of file diff --git a/content/ja/mobile/enterprise_configuration.md b/content/ja/mobile/enterprise_configuration.md new file mode 100644 index 0000000000000..ee53b4d844df3 --- /dev/null +++ b/content/ja/mobile/enterprise_configuration.md @@ -0,0 +1,56 @@ +--- +aliases: +- /ja/service_management/enterprise-configuration +further_reading: +- link: /monitors/ + tag: ドキュメント + text: アラート設定 +- link: /dashboards/ + tag: ドキュメント + text: ダッシュボード +- link: https://www.datadoghq.com/blog/datadog-mobile-widgets/ + tag: ブログ + text: Datadog モバイルダッシュボードウィジェットで、オンコールエクスペリエンスを改善 +title: 企業構成 +--- +Datadog モバイルアプリは [AppConfig][1] および AppConfig に対応しているモバイルデバイス管理 (MDM) プロバイダーに完全対応しています。 + +## サポートされる機能 + +モバイルアプリは [iOS][2] および [Android][3] 向けのすべてのデフォルト MDM 機能に加え、以下の専用機能をサポートしています。 + +| キー | 説明 |タイプ|デフォルト値| +|---------|---------|-----|-----| +|`datadogDefaultLoginOrganizationUUID`|ログイン時にパラメーターとして渡される組織の UUID `dd_oid` を定義します。|文字列|null| +|`datadogDefaultLoginOrganizationPublicID`|ログイン時にパラメーターとして渡される組織の`public_id`を定義します ([管理対象の組織一覧を取得する API エンドポイント][4]を通じて利用可能)。もし `datadogDefaultLoginOrganizationUUID` が設定されている場合は、`public_id` よりも優先されます。|文字列|null| +|`disableSharing`|アプリからのコンテンツ共有を無効にします。|Boolean|false| +|`disableHomeScreenWidgets`|ホーム画面ウィジェットへのアクセスを無効にします (代わりに「disabled by your organization」と表示)。|Boolean|false| + +デフォルト機能の詳細については、各モバイルデバイス管理プロバイダーのドキュメントをご確認ください。 + +## ユースケース + +### 組織固有のログインオプション +モバイルアプリでは組織情報を設定することで、組織専用のサブドメインがある場合に専用のモバイルアプリ用ログインページを表示したり、ユーザー認証用の特定オプションを提供したりできます。たとえば、モバイルアプリで Google SSO やメール/パスワード認証を無効にしたり、専用の SAML ログインボタンを追加することが可能です。 + +ログイン時にパラメーターとして渡すデフォルトの組織を特定するには、`datadogDefaultLoginOrganizationPublicID` または `datadogDefaultLoginOrganizationUUID` を設定できます。両方が設定されている場合は、`datadogDefaultLoginOrganizationUUID` が優先されます。 + +`datadogDefaultLoginOrganizationPublicID` は API 経由で確認可能です。 + +`datadogDefaultLoginOrganizationUUID` は **Personal Settings > My Organizations** から **Log in to Mobile App** をクリックすることで確認できます。 + +### ユーザーによるデータ漏洩の防止 +ユーザーによるデータ漏洩リスクが懸念される場合は、標準設定 ([iOS][2] および [Android][3] 向け)を使用してコピー & ペーストやスクリーンショットを無効にできます。さらにリスクを低減するため、Datadog モバイルアプリでは次の機能を任意で有効化できます。 + +- **アプリからの共有を無効化**: これにより Datadog モバイルアプリの各製品ページからすべての共有ボタンが削除されます。 + *注*: モバイルアプリの共有ボタンは、閲覧するには認証が必要な対象の製品ページへのリンクを作成します。このデフォルトの制御で十分かどうかをご検討ください。共有を無効にすると、モバイルアプリを使ったチームのコラボレーションが阻害される可能性があります。 +- **ホーム画面ウィジェットを無効化**: これにより、モニター、インシデント、SLO、またはダッシュボードの実際のデータの代わりにホーム画面ウィジェット上に「Disabled by your organization」と表示されます。 + +### その他の参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://www.appconfig.org/ +[2]: https://www.appconfig.org/ios.html +[3]: https://www.appconfig.org/android.html +[4]: https://docs.datadoghq.com/ja/api/latest/organizations/#list-your-managed-organizations \ No newline at end of file diff --git a/content/ja/monitors/guide/composite_use_cases.md b/content/ja/monitors/guide/composite_use_cases.md new file mode 100644 index 0000000000000..3d10627520add --- /dev/null +++ b/content/ja/monitors/guide/composite_use_cases.md @@ -0,0 +1,104 @@ +--- +further_reading: +- link: monitors/types/composite/ + tag: ドキュメント + text: Composite Monitor タイプ +title: Composite Monitor の使用例 +--- + + +## 概要 + +このガイドでは、Composite Monitor の代表的な使用例を紹介します。これらの例は、モニタリング環境でさまざまなユースケースに対応できるように Composite Monitor を構成する方法を示しています。 + +- [エラーレート](#error-rates) +- [頻繁に発生するメトリクスの監視](#monitor-frequent-metrics) +- [ステップモニター](#step-monitor) +- [リカバリー時の再通知](#renotifying-on-recovery) +- [通知の遅延](#delay-on-notification) + + +## エラーレート + +ヒット数が一定数を超えている場合に限り、エラーレートがしきい値を上回ったときにアラートを送る例です。 + +以下の 2 つのモニターを作成します: + +- **Monitor A**: `trace.requests.request.errors / trace.requests.request.hits > X` のときにアラート +- **Monitor B**: `trace.requests.request.hits > Y` のときにアラート + +**Composite Monitor C**: Monitor A と Monitor B の両方がアラート状態の場合にアラート (A && B) + +| Monitor A | Monitor B | Composite Monitor C | +|-----------|-----------|---------------------| +| **Alert** エラーレートがしきい値を超過 | **Alert** ヒット数がしきい値を超過 | **Alert** | +| **Alert** エラーレートがしきい値を超過 | **OK** ヒット数がしきい値未満 | **OK** 条件が1つのみ満たされておりアラートなし | +| **OK** エラーレートがしきい値未満 | **Alert** ヒット数がしきい値を超過 | **OK** 条件が1つのみ満たされておりアラートなし | + +より多くの状態の組み合わせについては、[Composite Monitor](https://docs.datadoghq.com/monitors/create/types/composite/#computing-trigger-conditions) を参照してください。 + +## 頻繁に発生するメトリクスの監視 + +サービスのレイテンシーを監視するときに、トラフィックの少ない時間帯などで一時的に発生するスパイクを無視したい場合の例です。 + +以下の 2 つのモニターを作成します: + +- **Monitor A**: `latency > X` のときにアラート +- **Monitor B**: 過去 1 時間において `sum:latency{*}.rollup(count) > Y` のときにアラート + +**Composite Monitor C**: 両方の条件が満たされた場合にアラート + +| Monitor A | Monitor B | Composite Monitor C | +|-----------|-----------|---------------------| +| **Alert** レイテンシーがしきい値超過 | **Alert** メトリクス総数が Y 超過 | **Alert** | +| **Alert** レイテンシーがしきい値超過 | **OK** メトリクス総数が Y 未満 | **OK** メトリクスが十分でない | +| **OK** レイテンシーがしきい値未満 | **Alert** メトリクス総数が Y 超過 | **OK** Latency below threshold**OK** レイテンシーが問題ないがメトリクスは多い  | + +## ステップモニター + +ペアになるメトリクスが欠如した場合にアラートを送る例です。たとえば、送信/受信、ダウン/アップ、作成/解決などのログメトリクスがペアになっている場合を想定します。ペアのメトリクスが N 分以内に報告されることを想定している場合は、各モニターの評価ウィンドウを調整します。 + +- **Monitor A**: `action:create` が 0 を上回ったらアラート +- **Monitor B**: `action:resolve` が 0 を上回ったらアラート + +**Composite**: `a && !b` (Monitor A がアラート && Monitor B がアラートでない) ならアラート + +| Monitor A | Monitor B | Composite Monitor C | +|-----------|-----------|---------------------| +| **Alert** Action create > 0 | **Alert** Action resolve > 0 | **OK** | +| **Alert** Action create > 0 | **OK** | **Alert** Action resolve が発生していない | +| **OK** | **Alert** Action resolve > 0 | **OK** | + +## リカバリー時の再通知 + +`timeshift` を使用した 2 つのモニターによって、リカバリー時に再通知を行う例です。 + +- **Monitor A**: 現在のメトリクス状態 +- **Monitor B**: `timeshift` を使用した過去のメトリクス状態 + +**Composite Monitor**: `!a && b` (現在がアラートではなく、過去はアラート状態) + +| Monitor A | Monitor B | Composite Monitor C | +|-----------|-----------|---------------------| +| **Alert** リアルタイムのメトリクス | **Alert** 過去のメトリクス | **OK** | +| **Alert** リアルタイムのメトリクス | **OK** トリガーなし | **OK** | +| **OK** トリガーなし | **Alert** 過去のメトリクス | **Alert** | + +## 通知の遅延 + +一定時間エラーが持続した場合にアラートを送る例です。たとえば、少なくとも 15 分間エラーが持続しているときにアラートを送る場合。 + +- **Monitor A**: リアルタイムのメトリクス +- **Monitor B (timeshifted)**: X 分シフトしたメトリクス + +**Composite Monitor**: `a && b` (両方がアラート状態) + +| Monitor A | Monitor B (timeshifted) | Composite Monitor C | +|-----------|--------------------------|---------------------| +| **Alert** リアルタイム | **Alert** 過去のメトリクス | **Alert** | +| **Alert** リアルタイム | **OK** トリガーなし | **OK** | +| **OK** トリガーなし | **Alert** 過去のメトリクス | **OK** | + +## 参考資料 + +{{< partial name="whats-next/whats-next.html" >}} \ No newline at end of file diff --git a/content/ja/monitors/guide/how-to-update-anomaly-monitor-timezone.md b/content/ja/monitors/guide/how-to-update-anomaly-monitor-timezone.md index c8bfde6f269b9..ac4317e258f0b 100644 --- a/content/ja/monitors/guide/how-to-update-anomaly-monitor-timezone.md +++ b/content/ja/monitors/guide/how-to-update-anomaly-monitor-timezone.md @@ -25,34 +25,29 @@ Agile または Robust 異常検知アルゴリズムを Weekly または Daily ## UI -UI でローカルタイムゾーンを考慮して異常検知モニターを更新するには、UI の [Create a new monitor][1] > [Anomaly monitor][2] セクションに移動します。セクション 3 の Set Alert Conditions で、Advanced パネルを開き、モニターの評価中にサマータイムを考慮するスイッチをオンに切り替えます。次に、タイムゾーンドロップダウンを追跡したいタイムゾーンに合わせます。 +UI でローカル タイムゾーンを考慮して異常検知モニターを更新するには、**[New monitor > Anomaly monitor][1]** に移動します。*Set Alert Conditions* セクションで Advanced パネルを開き、モニターの評価時にサマータイムを考慮するスイッチをオンにします。次に、タイムゾーン ドロップダウンで追跡したいタイムゾーンを選択します。 -{{< img src="monitors/guide/anomaly_monitor_timezone_ui.png" alt="UI の DST 追跡" >}} +{{< img src="monitors/guide/how_to_update_anomaly_monitor_timezone/daylight_savings_toggle.png" alt="UI 上 の DST トグル オプション" >}} ## API 1. モニター API で更新リクエストを行うには、次の情報が必要です。 - - 認証に使用する [Datadog API キーとアプリケーションキー][3] - - 異常検知モニターからのモニター ID とクエリ - {{< img src="monitors/guide/anomaly_monitor_timezone.png" alt="モニター ID とクエリ" >}} - - `America/New_York` や `Europe/Paris` など、メトリクスに関連するタイムゾーンの TZ 識別文字列。[tz データベースタイムゾーン一覧][4]の TZ 列で、希望するタイムゾーンを探します (正規の形式を推奨)。

-2. anomalies() 関数の呼び出しに `timezone` 引数を追加して、更新版のモニタークエリを作成します。 - - 例えば、上に示したクエリをニューヨークの現地時間を使うように変更したい場合、クエリは次のように更新されます。 - + - 認証用の [Datadog API キーとアプリケーション キー][3] + - 異常検知モニターの Monitor ID とクエリ (アプリで該当モニターに移動し、URL に含まれる Monitor ID を確認します) + - `America/New_York` や `Europe/Paris` など、メトリクスに関連するタイムゾーンの TZ 識別文字列。[tz データベースタイムゾーン一覧][4]の TZ 列で、希望するタイムゾーンを探します (正規の形式を推奨)。

+2. anomalies() 関数呼び出しに `timezone` 引数を追加して、モニター クエリを更新版として作成します。たとえば、上記のクエリをニューヨークのローカル時間で評価するよう変更する場合、クエリは次のようになります。 ``` avg(last_4h):anomalies(avg:system.cpu.user{role:trace-cassandra} by {host}, 'basic', 2, direction='both', alert_window='last_15m', interval=60, count_default_zero='true', timezone='America/New_York') >= 1 ``` - 3. モニターの定義を更新するには、[Edit a Monitor][5] API を使用します。 - - Python、Ruby、cURL の例があります。 - - 既存の設定をオーバーライドしないように、ID とクエリのみをリクエストに含めます。名前、メッセージ、オプション、タグは必須ではありません。 + - Python、Ruby、cURL の例があります。 + - 既存の設定をオーバーライドしないように、ID とクエリのみをリクエストに含めます。名前、メッセージ、オプション、タグは必須ではありません。 ## その他の参考資料 {{< partial name="whats-next/whats-next.html" >}} -[1]: https://app.datadoghq.com/monitors#/create -[2]: https://app.datadoghq.com/monitors#create/anomaly +[1]: https://app.datadoghq.com/monitors/create/anomaly [3]: https://app.datadoghq.com/organization-settings/api-keys [4]: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones -[5]: /ja/api/v1/monitors/#edit-a-monitor \ No newline at end of file +[5]: /ja/api/latest/monitors/#edit-a-monitor \ No newline at end of file diff --git a/content/ja/monitors/guide/on_missing_data.md b/content/ja/monitors/guide/on_missing_data.md new file mode 100644 index 0000000000000..50db57eb99542 --- /dev/null +++ b/content/ja/monitors/guide/on_missing_data.md @@ -0,0 +1,93 @@ +--- +further_reading: +- link: /api/latest/monitors/ + tag: API + text: Monitors API ドキュメント +title: On Missing Data 設定への移行 +--- + +## 概要 + +メトリクス モニターは欠損データの処理に関する拡張オプションを提供し、欠損データを障害モードとして扱う場合と健全な状態とみなす場合を区別できます。 + +これらのオプションは、Logs、 Events、 CI、 Database、 Error Tracking などの他のモニター タイプで利用できる内容と整合しています。 + +## On Missing Data オプションを使う利点 + +エラーのような不良イベントの件数を測定している場合、データが検出されないときはモニターは「OK」を示すべきです。従来の No Data 設定では、モニターは No Data を報告していました。On Missing Data の設定オプションにより、モニターは健全性の状態をより正確に反映でき、明確さが向上します。 + +## UI から管理しているモニター + +UI からモニターを管理している場合、次回編集時に設定が自動的に更新されます。より早く On Missing Data 設定を更新するには、以下の API を介した調整のセクションを参照してください。 + +## API または Terraform で管理しているモニター + +API または Terraform でモニターを管理している場合は、 `notify_no_data` と `no_data_timeframe` を `on_missing_data` に置き換えてください。`on_missing_data` は time window と同じ時間枠を使用するため、 `no_data_timeframe` パラメーターは不要です。 + +### API パラメーター + +従来の No Data パラメーター `notify_no_data` は既存のモニターで引き続き利用できますが、新しい `on_missing_data` 機能に自動移行はされません。 + +| パラメーター | UI 説明 | +|-----------------------------------------|----------------------------------------------------------------------------------------------------| +| `"on_missing_data": "show_and_notify_no_data"` | データがない場合は NO DATA を表示して通知
(旧: "Notify if data is missing") | +| `"on_missing_data": "show_no_data"` | データがない場合は NO DATA を表示
(旧: "Do not notify if data is missing") | +| `"on_missing_data": "resolve"` | データがない場合は OK を表示 | +| `"on_missing_data": "default"` (sum または count のアグリゲーションを使用している場合) | データがない場合は 0 (またはその他のデフォルト値) として評価 | +| `"on_missing_data": "default"` (上記以外のアグリゲーション タイプを使用している場合) | データがない場合は最後に既知のステータスを表示 | + +利用可能なすべてのフィールドについては、[API ドキュメント][1] を参照してください。 + +以下は、これらのフィールドを含む JSON モニターの Before/After 例です: + +**Before** +{{< highlight yaml "hl_lines=11-12" >}}{ + "name": "ホスト $host.value の CPU 使用率が高い", + "type": "query alert", + "query": "avg(last_5m):100 - avg:system.cpu.idle{$host} > 90", + "message": "ホスト $host.value で CPU 使用率の上昇が検出されました。これはシステム パフォーマンスに影響する可能性があります。", + "tags": [], + "options": { + "thresholds": { "critical": 90 }, + "notify_audit": false, + "include_tags": false, + "notify_no_data": true, + "no_data_timeframe": 10 + } +} +{{< /highlight >}} + + +**After** +{{< highlight yaml "hl_lines=11" >}}{ + "name": "ホスト $host.value の CPU 使用率が高い", + "type": "query alert", + "query": "avg(last_5m):100 - avg:system.cpu.idle{$host} > 90", + "message": "ホスト $host.value で CPU 使用率の上昇が検出されました。これはシステム パフォーマンスに影響する可能性があります。", + "tags": [], + "options": { + "thresholds": { "critical": 90 }, + "notify_audit": false, + "include_tags": false, + "on_missing_data": "show_and_notify_no_data" + } +} +{{< /highlight >}} + +## SLO モニター + +SLO は稼働時間と停止時間を以下の対応で扱います: + +| On Missing Data 設定 | モニター ステータス | SLO の扱い | +|-------------------------------|--------------------------------|-----------------------------| +| Show OK | OK | Uptime | +| Show No Data | No Data | Uptime | +| Show No Data and Notify | No Data | Downtime | +| Show last known status | 最後のステータスに依存 | OK の場合は Uptime
Alert の場合は Downtime | +| Evaluate as zero | しきい値の設定に依存 | OK の場合は Uptime
Alert の場合は Downtime | + +## 関連情報 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://docs.datadoghq.com/ja/api/latest/monitors/ \ No newline at end of file diff --git a/content/ja/monitors/guide/scoping_downtimes.md b/content/ja/monitors/guide/scoping_downtimes.md index 03787ce4020c3..c070e182cf748 100644 --- a/content/ja/monitors/guide/scoping_downtimes.md +++ b/content/ja/monitors/guide/scoping_downtimes.md @@ -39,7 +39,7 @@ title: ダウンタイムのスコープ ダウンタイムは、モニタータグに基づいてモニターにスケジュールすることができ、さらにモニタークエリでグループ化されたタグによってスコープダウンすることができます。`By Monitor Tags` を選択し、対象とするモニタータグを入力します。 -**Note**: Tags are additive, meaning that an input of `env:dev team:automations` will target monitors that are tagged with **both**, `env:dev` AND `team:automations`. +**注**: タグは付加的です。つまり、`env:dev team:automations` という入力は、`env:dev` と `team:automations` の**両方**のタグが付けられたモニターを対象とします。 ### すべてのモニターを対象にする @@ -60,8 +60,6 @@ title: ダウンタイムのスコープ スケジュールされたダウンタイムが始まると、このモニターではグループ `service:web-store` のアラートのみがミュートされます。 -{{< img src="monitors/downtimes/downtime_examplebyname1_monitor.png" alt="グループ service:web-store のダウンタイムを示す評価グラフ" style="width:90%;">}} - これは、`service:web-store` タグを含むアラートをミュートします。例: | モニターグループ | ミュート | @@ -122,12 +120,8 @@ title: ダウンタイムのスコープ 6. *モニター A* は、ダウンタイムが開始されたことを示していますが、スコープ内のグループのみです: `service:web-store` -{{< img src="monitors/downtimes/downtime_examplebytag1_monitor.png" alt="グループ service:web-store のダウンタイムを示す評価グラフ" style="width:80%;">}} - 7. *モニター B* は、`service:web-store` のダウンタイムが開始されたことを示しています。すべてのモニターのグループ (`host` ごと) は `service:web-store` に属しているため、このモニターのダウンタイム中にすべてのホストがミュートされます。 -{{< img src="monitors/downtimes/downtime_examplebytag1_monitor2.png" alt="グループ service:web-store と影響を受ける両ホストのダウンタイムを示す評価グラフ" style="width:80%;">}} - ## 参考資料 {{< partial name="whats-next/whats-next.html" >}} diff --git a/content/ja/monitors/guide/set-up-an-alert-for-when-a-specific-tag-stops-reporting.md b/content/ja/monitors/guide/set-up-an-alert-for-when-a-specific-tag-stops-reporting.md index 8fe4ee691c7af..1d609a4972fc1 100644 --- a/content/ja/monitors/guide/set-up-an-alert-for-when-a-specific-tag-stops-reporting.md +++ b/content/ja/monitors/guide/set-up-an-alert-for-when-a-specific-tag-stops-reporting.md @@ -17,10 +17,12 @@ title: 特定のタグがレポートを停止した場合のアラート設定 1. 決してトリガーされることのないアラート条件を選択します。例えば、`system.cpu.user` のような正のメトリクスには、`a < -1` を指定します。 1. この例で見られるように、_Notify if data is missing_ オプションを有効にします。 -{{< img src="monitors/guide/tag_stop_reporting.png" alt="Tag stop reporting" >}} +{{< img src="monitors/guide/tag_stop_reporting.png" alt="タグがレポートを停止" >}} タグがレポートを停止した場合、アラートがトリガーします。 +## 参考資料 + {{< partial name="whats-next/whats-next.html" >}} [1]: /ja/monitors/ diff --git a/content/ja/monitors/status.md b/content/ja/monitors/status.md new file mode 100644 index 0000000000000..2d01192cce9a2 --- /dev/null +++ b/content/ja/monitors/status.md @@ -0,0 +1,191 @@ +--- +aliases: +- /ja/monitors/monitor_status/ +- /ja/monitors/manage/status +description: 時系列でのモニターステータスの概要を取得 +further_reading: +- link: /monitors/ + tag: ドキュメント + text: モニターの作成 +- link: /monitors/notify/ + tag: ドキュメント + text: モニター通知 +- link: /monitors/manage/ + tag: ドキュメント + text: モニターの管理 +title: モニターのステータス +--- + +## 概要 + +[モニターの作成][1]後、モニターのステータスページを使用して、経時的なステータスを表示します。 + +{{< img src="monitors/monitor_status/monitor_status_page.png" alt="モニターステータスページ" >}} + +## ヘッダー + +ヘッダーには、モニターのステータス、ステータスの時間、モニターのタイトルが含まれます。右側には、**Mute**、**Resolve**、設定歯車ボタンがあります。 + +### ミュート + +ミュートボタンを使用してモニター全体をミュートするか、**スコープ** を設定して部分的にミュートします。使用できるスコープは、モニターのグループタグに基づきます。複数のスコープまたはモニターを同時にミュートする方法の詳細については、[ダウンタイム][2]を参照してください。 + +**注**: UI を使用してモニターをミュートまたはミュート解除すると、そのモニターに関連付けられているすべてのスケジュールされたダウンタイムが削除されます。 + +### 解決 + +モニターがアラート状態の場合、**Resolve** ボタンが表示されます。このボタンを使用して、モニターを手動で解決します。 + +モニターの `resolve` 機能を使用すると、次回のモニター評価に備えて、モニターのステータスを意図的に `OK` に切り替えることができます。通常は、モニターの元データに基づいて、次のモニター評価が実行されます。 + +現在のデータが `ALERT` 状態であるためにモニターでアラートが発生した場合は、`resolve` によってモニターの状態が `ALERT -> OK -> ALERT` の順に切り替わります。このため、アラートを確認したり、Datadog にアラートを無視させたりするために `resolve` を使用するのは不適切です。 + +データが断続的に報告される場合は、手動でモニターを解決しても問題ありません。たとえば、アラートがトリガーされると、モニターはデータを受信しなくなります。このため、モニターはアラートの条件を評価することや、`OK` の状態に回復することができなくなります。このような場合は、`resolve` 機能、またはタイマーにより自動的に解決する `Automatically resolve monitor after X hours` 機能を使用することで、モニターを `OK` の状態に戻すことができます。 + +**一般的な使用例**: エラーがない場合には生成されないエラーメトリクスに基づいたモニター (`aws.elb.httpcode_elb_5xx`、コード内に置かれて_エラーがある場合にのみ_エラーを報告する DogStatsD カウンター) + +### インシデントを作成する +**Declare incident** を選択して、モニターからインシデントを作成します。重大度レベル、通知、および追加のメモを含む *Declare Incident* ポップアップモーダル を構成します。詳細については、[インシデント管理][3]のドキュメントを参照してください。 + +### 設定 + +設定歯車をクリックして、使用可能なオプションを表示します。 + +| オプション | 説明 | +|--------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| 編集 | 現在のモニターを編集します。[モニターの構成][1]セクションの詳細を参照してください。 | +| Clone | 現在のモニターのコピーを作成します。 | +| エクスポート | 現在のモニターの JSON 構成をエクスポートします。このオプションは、[モニターの作成][1]時でも使用できます。プログラムでモニターを管理する場合は、UI でモニターを定義し、JSON をエクスポートします。 | +| 削除 | 現在のモニターを削除します。削除の確認を求められます。 | + +## プロパティ + +プロパティセクションは、モニターの概要です。 + +| プロパティ | 説明 | +|--------------|---------------------------------------------------------------------------------------| +| ステータス | アラート、警告、データなし、または OK | +| タイプ | [モニターの種類][4]の詳細をご覧ください。 | +| ID | [モニター API][5] に使用されます。 | +| Date created | モニターが作成された日付。 | +| Author | モニターを作成した人。 | +| タグ | モニターレベルでアタッチされたタグ。鉛筆アイコンをクリックしてタグを編集します。 | +| クエリ | [クエリ][6]の詳細をご覧ください。 | +| メッセージ | モニターの[通知][7]セクションで指定されたメッセージ。 | + +## ステータスと履歴 + +ステータスと履歴セクションには、モニターのクエリと状態の経時的な変化が表示されます。情報をフィルタリングするには、セクションの上の検索ボックス、ステータス、および時間セレクターを使用します。 + +### ステータス + +ステータスグラフは、時間の経過に伴うモニターのステータスをグループごとに示します。**注**: `None` または `no groups found` と表示される場合、次のいずれかの状況が当てはまる可能性があります。 + +* 新しく作成されたモニターがまだ評価されていない。 +* モニターのクエリが最近変更された。 +* モニターのタイムフレームがメトリクスに対して短すぎるため、データの供給頻度が低くなっています。 +* モニターは、データ提供頻度の低いメトリクスに対して完全なウィンドウのデータを必要とするよう設定されています。詳しくは [Advanced Alert Conditions][32] を参照してください。 +* 以前にクエリに含まれていたホストの名前が変更されました。ホスト名の変更は、2 時間以内に UI から期限切れになります。 +* フィルターしているクエリが期待通りに動作していない。 + +ステータスグラフには、モニタークエリのディメンションではなく、アラート用に構成したディメンションが表示されます。例えば、モニタークエリは `service` と `host` でグループ化されていますが、`service` のアラートのみを受信したい場合、ステータスグラフはモニターのステータスを `service` でグループ化して表示します。`host` サブグループは、View all をクリックすると、各サブグループのステータスグラフを表示するパネルが開きます。アラートのグループ化の詳細については、[モニターの構成][14]を参照してください。 + +{{< img src="monitors/monitor_status/monitor_status_group_subgroup.png" alt="モニターステータスをサービス別にグループ化し、サブグループを表示するオプションをハイライトしています" style="width:100%;" >}} + +#### グループまたはイベントによるモニターステータスのフィルター + + +**Status & History** ビューを特定のグループに絞り込むには、フィルターフィールドを使用し、フィルタリングしたい属性を入力します。グループフィルターの構文は、[モニター検索クエリ][30]と同じ原則に従います。従うべきベストプラクティスをいくつか紹介します。 + +- フィルターは大文字と小文字を区別し、`env:prod` と `env:Prod` は同じモニターグループを返しません。Datadog ではタグの統一を推奨しています。詳細については、[タグの概要][31]を参照してください。 +- クエリは自動的にワイルドカードを付加します。特定のフィルターを適用するには、クエリを二重引用符 (`"`) で囲んでください。 + 例えば、以下のクエリは二重引用符を使用していません。 + ``` + availability-zone:us-central1-a,instance-type:*,name:gke-demo-1 + ``` + クエリが 1 つの特定のグループを表示することを期待しているにもかかわらず、モニターはフォローグループを返します。 + ``` + availability-zone:us-central1-a,instance-type:*,name:gke-demo-10 + availability-zone:us-central1-a,instance-type:*,name:gke-demo-12 + ``` + + クエリを二重引用符で囲むと、期待通りのグループが返されます。 + `"availability-zone:us-central1-a,instance-type:*,name:gke-demo-1"` + +#### ノートブックのモニターを調査する + +メトリクスの進化をさらに詳しく調べるには、ステータスグラフの横にある **Open in a notebook** をクリックします。これにより、モニタークエリのフォーマットされたグラフを含む調査用[ノートブック][8]が生成されます。 + +{{< img src="monitors/monitor_status/notebook-button2.png" alt="Open in notebook ボタン" style="width:90%;">}} + +ノートブックはモニターの評価期間と一致し、関連する場合は関連するログを含んでいます。 + +#### フォローモニターグループの保持 + +Datadog は、クエリが変更されない限り、UI 上でモニターグループを 24 時間利用可能な状態に保ちます。データの欠落を通知するように構成されているホストモニターとサービスチェックは、48 時間利用可能です。モニターグラフに点線が表示され、non-reporting (報告なし) になっている場合は、以下の理由が考えられます。 + +- 新しいグループは、モニター作成後しばらくして評価されます。評価グラフには、期間の開始からグループが最初に評価されるまでの点線が表示されます。 +- グループは報告を停止し、脱落し、その後再び報告を開始します。点線は、グループが脱落した時点から再び評価を開始する時点まで表示されます。 + +{{< img src="monitors/monitor_status/dotted-line.png" alt="グループ維持率を表示" style="width:90%;">}} + +**注**: non-reporting は no data (データなし) と同じではありません。non-reporting はグループ固有のステータスです。 + +### 履歴 + +履歴グラフは、収集されたデータをステータスグラフと並べて表示します。これは、モニターのメトリクスクエリに送信される生のデータポイントを表示します。モニターステータスページでは、ノートブックやダッシュボードで使用されているのと同じ時系列グラフウィジェットを使用します。 + +### 評価グラフ + +評価グラフは、モニターに固有のものです。履歴グラフと同じクエリロジックを使用しますが、履歴グラフの時間枠ブラケットにスコープされます。表示されたポイントが正しく集計されるように、モニターの[評価ウィンドウ][9]に対応する固定でズームされたウィンドウを持ちます。たとえば、過去 15 分間のクエリの平均を評価するようにモニターが構成されている場合、評価グラフの各データポイントは、前の 15 分間の評価ウィンドウのメトリクスの集計値を表示します。 + +このグラフは、モニターで構成した評価条件に対して適用した、あるメトリクスの生データポイントからの結果を示しています。この視覚化は、モニタークエリを通過した後のデータの値を表示しているため、履歴グラフとは異なります。 + +{{< img src="monitors/monitor_status/status_monitor_history.mp4" alt="ステータスモニター履歴" video="true" width="100%" >}} + +## イベント + +モニターから生成されたイベント (アラート、警告、回復など) は、**Status & History** セクションの上の時間セレクターに基づいてこのセクションに表示されます。イベントは[イベントエクスプローラー][10]にも表示されます。 + +### Audit trail（監査証跡） +監査証跡は、あらゆるタイプのモニターの変更を自動的にキャプチャし、イベントを生成します。このイベントはモニターへの変更をドキュメント化します。 + +例えば、モニターを編集した場合、監査証跡イベントには次のように表示されます。 + - 以前のモニター構成 + - 現在のモニター構成 + - 変更を行ったユーザー + + 詳細については、[監査証跡][11]ドキュメントを参照し、[監査証跡のベストプラクティス][12]ブログをお読みください。 + +Datadog は、作成したモニターへの変更に対する通知オプションも提供しています。モニターエディターの下部にある、**Define permissions and audit notifications** の下にある *If this monitor is modified, notify monitor creator and alert recipients.* (このモニターが変更された場合、モニターの作成者とアラート受信者に通知する) の隣のドロップダウンで、**Notify** を選択します。 + +この設定により、モニター監査イベントに関する電子メールが、特定のモニターの全アラート受信者とモニター作成者に送信されます。モニター監査イベントは[イベントエクスプローラー][10]にも表示されます。 + +## エクスポートとインポート + +モニターのステータスページから、任意のモニターのエクスポートを JSON で取得できます。右上にある歯車アイコン（設定）をクリックし、メニューから **Export** を選択します。 + +メインナビゲーションで、*Monitors --> New Monitor --> Import* の順に選択し、JSON を使用して Datadog に[モニターをインポート][13]します。 + +## その他の参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + + +[1]: /ja/monitors/configuration/ +[2]: /ja/monitors/downtimes/ +[3]: /ja/service_management/incident_management/#from-a-monitor +[4]: /ja/monitors/types/ +[5]: /ja/api/v1/monitors/ +[6]: /ja/dashboards/querying/ +[7]: /ja/monitors/notify/ +[8]: /ja/notebooks +[9]: /ja/monitors/configuration/?tab=thresholdalert#evaluation-window +[10]: https://app.datadoghq.com/event/explorer +[11]: /ja/account_management/audit_trail/ +[12]: https://www.datadoghq.com/blog/audit-trail-best-practices/ +[13]: https://app.datadoghq.com/monitors/create/import +[14]: /ja/monitors/configuration/?tab=thresholdalert#configure-notifications-and-automations +[30]: /ja/monitors/manage/search/#query +[31]: /ja/getting_started/tagging/ +[32]: /ja/monitors/types/metric/?tab=threshold#advanced-alert-conditions \ No newline at end of file diff --git a/content/ja/monitors/types/change-alert.md b/content/ja/monitors/types/change-alert.md new file mode 100644 index 0000000000000..a56688651aac5 --- /dev/null +++ b/content/ja/monitors/types/change-alert.md @@ -0,0 +1,103 @@ +--- +aliases: +- /ja/monitors/guide/change-alert +disable_toc: false +further_reading: +- link: /monitors/types/metric/?tab=change#choose-the-detection-method + tag: ドキュメント + text: メトリクスモニターの検出方法を選択 +- link: /monitors/configuration/ + tag: ドキュメント + text: モニターの構成方法について +title: 変更アラートモニター +--- + +## 概要 + +メトリクスモニターは、最も一般的に使用されるタイプのモニターの 1 つです。このガイドでは、変化アラート検出方法の動作と追加オプションについて説明します。変化アラートモニターの動作と変化アラート評価のトラブルシューティング方法について説明します。 + +## 変化アラートモニターとは？ +以下は、変化検出方式のモニターがどのように機能するかの内訳です。 +1. モニターは現在時刻のデータポイントのクエリを取ります。 +1. N 分前、N 時間前、N 日前のデータポイントのクエリを取ります。 +1. そして、(1) と (2) の値の差のクエリを取ります。 +1. 集計は、単一の値を返す (3) のクエリに対して適用されます。 +1. **Set alert conditions** で定義されたしきい値は、(4) で返された単一の値と比較されます。 + +## モニターの作成 + +Datadog で [変更アラートモニター][9]を作成するには、メインナビゲーションで *Monitors → New Monitor → Change* を選択します。 + +## 評価条件 + +ここでは、変化アラートモニターで構成する必要があるさまざまなオプションを示します。 + +{{< img src="/monitors/monitor_types/change-alert/configure_define_the_metrics.png" alt="変更アラート検出方法の設定オプション" style="width:100%;" >}} + +この例では、次のアラート条件が設定されています。 +**1 時間** における **change** の **平均** を **5 分** 前と比較する + +| 選択したオプション | 説明 | オプション | +| --------------- | --------------------------------------------------------------------------- | ----------------------------- | +| average | クエリに適用される集約方法。 | `Average`, `Maximum`, `Minimum`, `Sum` | +| change | 値の絶対変化量かパーセント変化量かを選択。 | `change` または `% change` | +| 1 hour | 評価ウィンドウ。詳細は[モニター設定][1]ドキュメントを参照。 | N 分、時間、日、週、最大 1 か月まで設定可能 | +| 5 minutes | クエリをどれだけシフトさせるかの時間範囲。 | N 分、時間、日、週、最大 1 か月前まで指定可能 | + +### 変化と変化率 + +変化アラート検出の構成には、**Change** と **% Change** の 2 つのオプションがあります。 + +これは、次の表の数式セクションで表されるモニターの評価方法を決定します。 + +| オプション | 説明 | 計算式 | +| ------- | ------------------------------------------------------------------ | -------------------- | +| 変更 | 値の絶対変化量です。 | `a - b` | +| % Change | 前回値と比較した値の変化率。 | `((a - b) / b) * 100`| + +どちらの場合も、`Change` と `% Change` は正でも負でもかまいません。 + +## 通知 + +For instructions on the **Configure notifications and automations** section, see the [Notifications][7] and [Monitor configuration][8] pages. + +## 変化アラート評価のトラブルシューティング + +変化アラートの評価結果を確認するには、メトリクスクエリをノートブックで再構築します。 +この変化アラートモニターを以下の設定で実行します。 + +{{< img src="monitors/monitor_types/change-alert/example_monitor_config.png" alt="変更アラートを選択し、メトリクス system.load.1 の平均値について、直近 5 分間と過去 30 分間を比較してパーセント変化を評価しているモニター作成ページ" style="width:100%;" >}} + +モニタークエリ: +```pct_change(avg(last_5m),last_30m): > -50``` + +これは、以下の条件のクエリの内訳です。 +1. **avg** の集計。 +2. **% change** を使用する。 +3. 評価ウィンドウは **5 minutes**。 +4. タイムシフトは **30 minutes** つまり 1800 秒。 +5. しきい値は **> -50**。 + +### クエリの再構築 + +1. [ノートブック][2]と[タイムシフト関数][3]を使って、特定の評価でモニターが使用したデータを再構築します。 + - 現在時刻のデータポイントのクエリ (これは通常のクエリ)。 + - N 分前のデータポイントのクエリ (これは通常のクエリ + timeshift(-1800))。 + - タイムシフト関数は、データを後ろにシフトするため、**負の**期間を使用します。これらのクエリと、表の変化率式を組み合わせてください。 + - **注**: この例ではメトリクスが 1 つしかないため、1 つのクエリ (a) を使用し、数式 `((a - timeshift(a, -1800)) / timeshift(a, -1800)) * 100` を追加することも可能です。 + {{< img src="monitors/monitor_types/change-alert/notebook_query_reconstruct_timeshift.png" alt="ノートブックのセル編集画面。タイトルは「Reconstruct Change Alert query」。あらゆるホストから取得したメトリクス system.load.1 の平均を時系列で表示し、式 ((a - timeshift(a, -1800)) / timeshift(a, -1800)) * 100 を適用している" style="width:100%;" >}} +2. モニターの履歴グラフとノートブックのグラフを比較してください。値は同等ですか？ +3. 集計を適用します。 + - ノートブックのグラフを変化アラートのモニター評価と比較するには、時間枠を変化アラートと一致させます。 + - 例えば、1:30 に過去 5 分間のモニター評価値を確認したい場合、ノートブックの範囲を 1:25 - 1:30 にします。 + +## 参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ja/monitors/configuration/#evaluation-window +[2]: /ja/monitors/status/#investigate-a-monitor-in-a-notebook +[3]: /ja/dashboards/functions/timeshift/ +[7]: /ja/monitors/notify/ +[8]: /ja/monitors/configuration/?tab=thresholdalert#configure-notifications-and-automations +[9]: https://app.datadoghq.com/monitors/create/metric/change \ No newline at end of file diff --git a/content/ja/monitors/types/integration.md b/content/ja/monitors/types/integration.md index 2b074ed54066d..f46422e6992d7 100644 --- a/content/ja/monitors/types/integration.md +++ b/content/ja/monitors/types/integration.md @@ -10,7 +10,7 @@ further_reading: - link: /monitors/downtimes/ tag: ドキュメント text: モニターをミュートするダウンタイムのスケジュール -- link: /monitors/manage/status/ +- link: /monitors/status/ tag: ドキュメント text: モニターステータスを確認 title: インテグレーションモニター @@ -31,7 +31,7 @@ Datadog で[インテグレーションモニター][2]を作成するには [メトリクスモニター][3]ドキュメントの手順に従って、インテグレーションメトリクスモニターを作成します。モニタータイプにインテグレーションメトリクスを選択すると、[モニターの管理][4] ページで、確実にインテグレーションモニタータイプのファセットでモニターを選択できるようになります。 -**Note**: To configure an integration monitor, ensure that the integration submits metrics or service checks. +**注**: インテグレーション モニターを設定するには、そのインテグレーションがメトリクスまたはサービス チェックを送信していることを確認してください。 #### チェックを選択する @@ -72,7 +72,7 @@ Datadog で[インテグレーションモニター][2]を作成するには 何回連続して `OK` ステータスが送信されたらアラートを解決するか、回数を選択します。 -[1]: /ja/monitors/manage/status +[1]: /ja/monitors/status {{% /tab %}} {{% tab "Cluster Alert" %}} @@ -98,14 +98,14 @@ Datadog で[インテグレーションモニター][2]を作成するには #### 通知 -For detailed instructions on the **Configure notifications and automations** section, see the [Notifications][9] page. +**Configure notifications and automations** セクションの詳細な手順については、[通知][9] ページを参照してください。 ## その他の参考資料 {{< partial name="whats-next/whats-next.html" >}} [1]: /ja/integrations/ -[2]: https://app.datadoghq.com/monitors#create/integration +[2]: https://app.datadoghq.com/monitors/create/integration [3]: /ja/monitors/types/metric/ [4]: https://app.datadoghq.com/monitors/manage [5]: /ja/monitors/configuration/#advanced-alert-conditions diff --git a/content/ja/monitors/types/metric.md b/content/ja/monitors/types/metric.md index 66cf8da2e30f0..d6a69ef4b57d3 100644 --- a/content/ja/monitors/types/metric.md +++ b/content/ja/monitors/types/metric.md @@ -11,7 +11,7 @@ further_reading: - link: /monitors/downtimes/ tag: ドキュメント text: モニターをミュートするダウンタイムのスケジュール -- link: /monitors/manage/status/ +- link: /monitors/status/ tag: ドキュメント text: モニターステータスの参照 - link: /monitors/types/change-alert @@ -24,7 +24,7 @@ title: メトリクスモニター メトリクスモニターは連続的なデータのストリームに役立ちます。Datadog に送信されるメトリクスのいずれかが、一定の期間にしきい値から外れると、アラートを送信します。 -To create a metric monitor in Datadog, navigate to [**Monitors > New Monitor**][1] and select the **Metric** monitor type. +Datadog でメトリクスモニターを作成するには、[**Monitors > New Monitor**][1] に移動し、**Metric** モニタータイプを選択します。 ## 検出方法を選択します。 @@ -33,9 +33,9 @@ To create a metric monitor in Datadog, navigate to [**Monitors > New Monitor**][ しきい値アラートは、メトリクス値を静的なしきい値と比較します。 -On each alert evaluation, Datadog calculates the average, minimum, maximum, or sum over the selected period and checks if it is above, below, equal to, or not equal to the threshold. This is for standard alert cases where you know the expected values. The [distribution metric type][1] offers the additional threshold option of calculating percentiles over the selected period. +各アラートの評価時に、Datadog は選択した期間の平均値、最小値、最大値、または合計値を算出し、それがしきい値を上回っているか、下回っているか、等しいか、等しくないかをチェックします。これは予想される値が明確な標準的なアラートケース向けです。[distribution メトリクス型][1] では、選択した期間のパーセンタイルを計算する追加のしきい値オプションが利用できます。 -For more information, see the [Set alert conditions](#set-alert-conditions) section. +詳細は[アラートの条件を設定する](#set-alert-conditions)セクションを参照してください。 [1]: /ja/metrics/distributions/ {{% /tab %}} @@ -47,7 +47,7 @@ For more information, see the [Set alert conditions](#set-alert-conditions) sect このタイプのアラートは、しきい値を常に予測できる場合に、メトリクスのスパイク、ドロップ、あるいは緩やかな変化を追跡するのに役立ちます。 -For more information, see the [Change alert monitors][1] guide. +詳細は[変化アラートモニター][1]ガイドを参照してください。 [1]: /ja/monitors/types/change-alert/ {{% /tab %}} @@ -59,7 +59,7 @@ For more information, see the [Change alert monitors][1] guide. アラートの評価には、予期される範囲の内、外、上、下にある系列の割合を計算します。この割合がしきい値から外れる場合にアラートがトリガーされます。 -For more information, see the [Anomaly Monitor][1] page. +詳細は[異常検知モニター][1]ページを参照してください。 [1]: /ja/monitors/types/anomaly/ {{% /tab %}} @@ -69,7 +69,7 @@ For more information, see the [Anomaly Monitor][1] page. アラートの評価では、すべてのグループが一緒にクラスター化され、同じ動作を示しているかをチェックします。1 つ以上のグループの動作が他のグループと異なる場合にアラートがトリガーされます。 -For more information, see the [Outlier Monitor][1] page. +詳細は[外れ値モニター][1]ページを参照してください。 [1]: /ja/monitors/types/outlier/ {{% /tab %}} @@ -79,7 +79,7 @@ For more information, see the [Outlier Monitor][1] page. アラートの評価では、偏差の範囲を考慮してメトリクスの今後の値を予測します。この範囲のいずれかの部分がしきい値から外れる場合にアラートがトリガーされます。 -For more information, see the [Forecast Monitor][1] page. +詳細は[予測値モニター][1]ページを参照してください。 [1]: /ja/monitors/types/forecasts/ {{% /tab %}} @@ -92,7 +92,7 @@ Datadog に報告する任意のメトリクスは、モニターに利用でき {{< tabs >}} {{% tab "しきい値" %}} -{{< img src="monitors/monitor_types/metric/metric_threshold_config.png" alt="define the metric for threshold detection metric monitor" style="width:100%;">}} +{{< img src="monitors/monitor_types/metric/metric_threshold_config.png" alt="しきい値検知用メトリクスモニターのメトリクスを定義する" style="width:100%;">}} | 手順 | 必須 | デフォルト | 例 | |-----------------------------------|----------|----------------|-------------------| @@ -117,7 +117,7 @@ Datadog に報告する任意のメトリクスは、モニターに利用でき {{% /tab %}} {{% tab "変化" %}} -{{< img src="monitors/monitor_types/metric/metric_change_alert_config.png" alt="define the metric for change detection metric monitor" style="width:100%;">}} +{{< img src="monitors/monitor_types/metric/metric_change_alert_config.png" alt="変化検知用メトリクスモニターのメトリクスを定義する" style="width:100%;">}} | 手順 | 必須 | デフォルト | 例 | |-----------------------------------|----------|----------------|-------------------| @@ -147,14 +147,15 @@ Datadog に報告する任意のメトリクスは、モニターに利用でき {{< /tabs >}} **注:** - - If using a distribution metric with a percentile aggregator, a matching percentile threshold is automatically specified. Metrics with percentile aggregators do not generate a snapshot graph in the notifications message. + - パーセンタイルアグリゲータを使用する distribution メトリクスの場合、対応するパーセンタイルしきい値が自動的に指定されます。パーセンタイルアグリゲータを使用しているメトリクスは、通知メッセージ内にスナップショットグラフを生成しません。 - **max/min**: これらの max と min の説明は、メトリクスがしきい値を上回ったときにモニターがアラートすることを想定しています。しきい値を下回ったときにアラートするモニターでは、max と min の動作は逆になります。 - モニターを作成するメトリクスの定義は、グラフを作成するメトリクスの定義と似ています。`Advanced...` オプションの使用について詳しくは、[高度なグラフの作成][2]を参照してください。 - `as_count()` を使用する場合は動作が異なります。詳しくは、[モニター評価での as_count()][3] を参照してください。 + - `N/A` グループはモニターに含まれないため、タグキーには値が必要です。 ## アラートの条件を設定する -Trigger when the metric is one of the following: +メトリクスが以下のいずれかの場合にトリガーします: - `above` - `above or equal to` - `below` @@ -162,7 +163,7 @@ Trigger when the metric is one of the following: - `equal to` - `not equal to` -If the value is between zero and one, a leading zero is required. For example, `0.3`. +値が 0 と 1 の間にある場合、先頭に 0 が必要です (例: `0.3`)。 ### 高度なアラート条件 @@ -188,7 +189,7 @@ If the value is between zero and one, a leading zero is required. For example, ` 「フルウィンドウ」と見なされるには、モニターに次のものが必要です。 1. 最初のバケットに少なくとも 1 つのデータポイント。最初のバケットは、ウィンドウで時系列的に一番早いバケットです。 -2. データポイントのない合計で最大 3 つのバケット (最初のバケットを含む)。 +2. 合計で 3 つを超えるバケットにデータポイントが存在しない場合は認められません。 条件が満たされると、モニターが評価されます。それ以外の場合、評価はキャンセルされ、モニターの状態は変更されません。 @@ -205,11 +206,11 @@ If the value is between zero and one, a leading zero is required. For example, ` #### その他のオプション -For instructions on the advanced alert options (no data, auto resolve), see the [Monitor configuration][6] page. +高度なアラートオプション（no data、auto resolve）の手順については、[モニターの構成][6]ページを参照してください。 ## 通知 -For instructions on the **Configure notifications and automations** section, see the [Notifications][7] and [Monitor configuration][8] pages. +**Configure notifications and automations** セクションの手順については、[通知][7]と[モニターの構成][8]ページを参照してください。 ## その他の参考資料 diff --git a/content/ja/monitors/types/slo.md b/content/ja/monitors/types/slo.md index cd74c44301e53..a1086c899c9d4 100644 --- a/content/ja/monitors/types/slo.md +++ b/content/ja/monitors/types/slo.md @@ -12,7 +12,7 @@ title: SLO アラート ---
-This monitor is available for the Metric-based SLOs, Time Slice SLOs, and Monitor-based SLOs composed of Metric Monitor types (Metric, Integration, APM Metric, Anomaly, Forecast, or Outlier Monitors). +このモニターは、Metric-based SLO、Time Slice SLO、および以下のメトリックモニタータイプ (Metric、Integration、APM Metric、Anomaly、Forecast、Outlier Monitor) で構成された Monitor-based SLO に対して利用できます。
## 概要 @@ -37,7 +37,7 @@ Datadog で [SLO アラート][2]を作成するには、メインナビゲー ### 通知 -For detailed instructions on the **Configure notifications and automations** section, see the [Notifications][5] page. +**Configure notifications and automations** セクション (通知と自動化の構成) の詳細な手順については、[通知][5]のページをご覧ください。 すべてのモニタータイプで利用可能な[標準テンプレート変数][6]に加えて、SLO アラートは以下の変数もサポートします。 diff --git a/content/ja/network_monitoring/cloud_network_monitoring/guide/detecting_a_network_outage.md b/content/ja/network_monitoring/cloud_network_monitoring/guide/detecting_a_network_outage.md new file mode 100644 index 0000000000000..58b2596a743d5 --- /dev/null +++ b/content/ja/network_monitoring/cloud_network_monitoring/guide/detecting_a_network_outage.md @@ -0,0 +1,38 @@ +--- +aliases: +- /ja/network_performance_monitoring/guide/detecting_a_network_outage/ +- /ja/network_monitoring/performance/guide/detecting_a_network_outage/ +further_reading: +- link: /network_monitoring/cloud_network_monitoring/guide/detecting_application_availability/ + tag: ガイド + text: Detecting Application Availability using Network Insights +title: ネットワーク停止の検出 +--- +ネットワークの停止は、多くの場合、インフラストラクチャー、アプリケーション、またはコンテナの問題に偽装されているため、検出が困難です。地域のネットワークパフォーマンスまたは依存しているサードパーティのエンドポイントのパフォーマンスを可視化しないと、サードパーティまたはクラウドの地域の停止を検出するのに数時間かかる場合があり、最終的には顧客に影響を与える可能性があります。 + +Cloud Network Monitoring (CNM) を使用すると、ネットワークの停止を数分で検出できます。プロセスメトリクス、トレース、ログ、インフラストラクチャーメトリクスとともにネットワークフローデータを分析することで、問題の根本について推測することを避け、代わりに消去法 (以下の手順を参照) を使って、ネットワークの停止が発生しているかどうかを判断できます。 + +## 基底のインフラストラクチャーに過負荷がかかるトラフィック + +CNM メトリクスを使用して、ソースエンドポイントが大量のトラフィックを送信しているのか、宛先エンドポイントに多数のオープン接続を確立しているのかを確認します。障害のある依存関係 (たとえば、高レイテンシーの依存関係) を選択する場合、サイドパネルのグラフを使用して、このようなトラフィックの急増を見つけることができます。この急増は、受信アプリケーションを圧迫して (TCP の場合) すべての接続に応答できなくなり、パケット損失が増加し、TCP レイテンシーが増加する可能性があります。 + +{{< img src="network_performance_monitoring/guide/detecting_a_network_outage/cnm_metrics.png" alt="基盤インフラストラクチャーへのトラフィック過負荷">}} + +## 基底のインフラストラクチャーの CPU の過剰消費 + +一方、クライアントまたはサーバーエンドポイントのいずれかのリソースの過剰消費は、両者間の通信不良の原因になる可能性があります。サイドパネルの **Processes** タブで、ソースエンドポイントまたは宛先エンドポイントのいずれかで実行されているプロセスにビューのスコープを設定して、基底のホストまたはコンテナのパフォーマンスを低下させ、ネットワーク呼び出しに応答する能力を低下させている可能性のある重いソフトウェアを見つけます。この場合、基底のホストが熱くなり、アプリケーションのレイテンシーが発生しているかどうかを知ることに加えて、それが熱くなっている理由を知る必要があります。プロセスメトリクスをコマンドでグループ化すると、CPU およびメモリリソースを消費している特定のワークロードを特定できるため、この粒度が得られます。 + +{{< img src="network_performance_monitoring/guide/detecting_a_network_outage/cnm_processes_tab.png" alt="基盤インフラストラクチャーの CPU の過剰使用">}} + +## コード内のアプリケーションエラー + +ネットワークエラーとレイテンシーは、クライアント側のアプリケーションエラーによっても発生する可能性があります。たとえば、アプリケーションがループ上で不必要に接続を生成している場合、それに依存するエンドポイントを圧迫し、ダウンストリームアプリケーションとネットワークの問題につながる可能性があります。このケースかどうかを判断するには、[CNM > DNS][1] の特定のサービスの **Traces** タブ、または APM Traces の特定のトレースの **Network** タブでアプリケーションリクエストエラーを探します。 + +{{< img src="network_performance_monitoring/guide/detecting_a_network_outage/traces_2.png" alt="コード内のアプリケーションエラー">}} + +これらの手順のいずれも根本原因につながるものではなく、特定のリージョン、アベイラビリティーゾーン、またはサードパーティドメインエンドポイントを対象とする依存関係のエラーとレイテンシーが発生している場合は、ネットワークの停止が発生しています。この場合、関連するプロバイダーに連絡して、問題を報告して解決することができます。 + +## 参考資料 +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://app.datadoghq.com/network/dns \ No newline at end of file diff --git a/content/ja/observability_pipelines/destinations/splunk_hec.md b/content/ja/observability_pipelines/destinations/splunk_hec.md new file mode 100644 index 0000000000000..4bf350d8ede53 --- /dev/null +++ b/content/ja/observability_pipelines/destinations/splunk_hec.md @@ -0,0 +1,31 @@ +--- +disable_toc: false +title: Splunk HTTP Event Collector (HEC) Destination +--- + +Observability Pipelines の Splunk HTTP Event Collector (HEC) Destination を使用して、ログを Splunk HEC に送信します。 + +## セットアップ + +[パイプラインをセットアップする][1] 際に、Splunk HEC Destination とその環境変数を設定します。以下の情報は Pipelines UI で構成します。 + +### Set up the destination + +{{% observability_pipelines/destination_settings/splunk_hec %}} + +### 環境変数を設定する + +{{% observability_pipelines/configure_existing_pipelines/destination_env_vars/splunk_hec %}} + +### Destination の動作 + +#### イベントのバッチ処理 + +以下のいずれかのパラメーターを満たすと、イベントのバッチがフラッシュされます。詳細は [イベントのバッチ処理][2] を参照してください。 + +| Max Events | Max Bytes | タイムアウト (秒) | +|----------------|-----------------|---------------------| +| なし | 1,000,000 | 1 | + +[1]: https://app.datadoghq.com/observability-pipelines +[2]: /ja/observability_pipelines/destinations/#event-batching \ No newline at end of file diff --git a/content/ja/observability_pipelines/destinations/sumo_logic_hosted_collector.md b/content/ja/observability_pipelines/destinations/sumo_logic_hosted_collector.md new file mode 100644 index 0000000000000..6512418686898 --- /dev/null +++ b/content/ja/observability_pipelines/destinations/sumo_logic_hosted_collector.md @@ -0,0 +1,31 @@ +--- +disable_toc: false +title: Sumo Logic Hosted Collector Destination +--- + +Observability Pipelines の Sumo Logic Destination を使用して、ログを Sumo Logic Hosted Collector に送信します。 + +## セットアップ + +[パイプラインをセットアップする][1] 際に、Sumo Logic Destination とその環境変数を設定します。以下の情報は Pipelines UI で構成します。 + +### Set up the destination + +{{% observability_pipelines/destination_settings/sumo_logic %}} + +### Set the environment variables + +{{% observability_pipelines/configure_existing_pipelines/destination_env_vars/sumo_logic %}} + +## How the destination works + +### イベントのバッチ処理 + +A batch of events is flushed when one of these parameters is met. See [event batching][2] for more information. + +| Max Events | Max Bytes | タイムアウト (秒) | +|----------------|-----------------|---------------------| +| なし | 10,000,000 | 1 | + +[1]: https://app.datadoghq.com/observability-pipelines +[2]: /ja/observability_pipelines/destinations/#event-batching \ No newline at end of file diff --git a/content/ja/observability_pipelines/legacy/architecture/_index.md b/content/ja/observability_pipelines/legacy/architecture/_index.md new file mode 100644 index 0000000000000..8c2b6a99b2a33 --- /dev/null +++ b/content/ja/observability_pipelines/legacy/architecture/_index.md @@ -0,0 +1,40 @@ +--- +aliases: +- /ja/observability_pipelines/production_deployment_overview/aggregator_architecture +- /ja/observability_pipelines/aggregator_architecture/ +- /ja/observability_pipelines/architecture/ +title: (レガシー) OPW アグリゲーターアーキテクチャのベストプラクティス +--- + +{{< site-region region="gov" >}} +
Observability Pipelines は、US1-FED Datadog サイトでは利用できません。
+{{< /site-region >}} + +{{% observability_pipelines/legacy_warning %}} + +
+このガイドは、大規模な本番環境レベルのデプロイメント向けです。
+ +## 概要 + +観測可能性パイプラインワーカー (OPW) のアグリゲーターアーキテクチャは、データの集中処理とルーティングのためのスタンドアローンサービスとして観測可能性パイプラインワーカーをデプロイします。 + +{{< img src="observability_pipelines/production_deployment_overview/aggregator_role2.png" alt="ネットワークロードバランサーが様々なソースからデータを受け取り、観測可能性パイプラインワーカーアグリゲーターにデータを送る様子を示した図。このアグリゲーターは、異なるアベイラビリティゾーンに複数のワーカーを持ち、様々なシンクにデータを送る" style="width:100%;" >}} + +観測可能性パイプラインワーカーを他のサービスのようにインフラストラクチャーにデプロイし、データをインターセプトして操作し、宛先に転送することができます。観測可能性パイプラインワーカーインスタンスはそれぞれ独立して動作するため、シンプルなロードバランサーでアーキテクチャを拡張することができます。 + +このガイドでは、新規の観測可能性パイプラインワーカーユーザーのために、推奨されるアグリゲーターアーキテクチャを説明します。具体的には、以下のトピックが含まれています。 + +- [インスタンスの最適化][3]により、観測可能性パイプラインワーカーのアグリゲーターを水平方向にスケールさせることができるようになります。 +- [キャパシティプランニングと観測可能性パイプラインワーカーをスケーリングする][4]ためのリソース容量を見積もるための出発点。 +- 観測可能性パイプラインワーカー用の[ネットワークトポロジと構成][5]の決定。 +- [高耐久性][6]と[高可用性](#high-availability)の実現。 +- 観測可能性パイプラインワーカーを[災害復旧][7]の一環として活用する。 +- 複数のアグリゲーター、パブリッシュサブスクライブシステム、およびグローバル集計をデプロイするための、その他の[高度な構成][8]。 + +[3]: /ja/observability_pipelines/legacy/architecture/optimize +[4]: /ja/observability_pipelines/legacy/architecture/capacity_planning_scaling +[5]: /ja/observability_pipelines/legacy/architecture/networking +[6]: /ja/observability_pipelines/legacy/architecture/preventing_data_loss +[7]: /ja/observability_pipelines/legacy/architecture/availability_disaster_recovery +[8]: /ja/observability_pipelines/legacy/architecture/advanced_configurations \ No newline at end of file diff --git a/content/ja/observability_pipelines/legacy/architecture/networking.md b/content/ja/observability_pipelines/legacy/architecture/networking.md index e585aea56c84f..54e7a34a08fa8 100644 --- a/content/ja/observability_pipelines/legacy/architecture/networking.md +++ b/content/ja/observability_pipelines/legacy/architecture/networking.md @@ -5,9 +5,13 @@ title: (レガシー) ネットワーキング --- {{< site-region region="gov" >}} -Observability Pipelines は、US1-FED Datadog サイトでは利用できません。このガイドは、大規模な本番環境レベルのデプロイメント向けです。 +
Observability Pipelines は、US1-FED Datadog サイトでは利用できません。
{{< /site-region >}} +
+このガイドは、大規模な本番環境レベルのデプロイメント向けです。 +
+ ## ネットワークトポロジー ### ネットワーク境界 diff --git a/content/ja/observability_pipelines/legacy/guide/_index.md b/content/ja/observability_pipelines/legacy/guide/_index.md new file mode 100644 index 0000000000000..94e619c469bd6 --- /dev/null +++ b/content/ja/observability_pipelines/legacy/guide/_index.md @@ -0,0 +1,20 @@ +--- +aliases: +- /ja/integrations/observability_pipelines/guide/ +- /ja/observability_pipelines/guide/custom-metrics-governance +cascade: + algolia: + category: ガイド + rank: 20 + subcategory: Observability Pipelines ガイド +disable_toc: true +private: true +title: (レガシー) Observability Pipelines ガイド +--- + +{{< whatsnext desc="一般ガイド:" >}} + {{< nextlink href="/observability_pipelines/legacy/setup/splunk" >}}Splunk 環境での可観測性パイプラインのセットアップ{{< /nextlink >}} + {{< nextlink href="/observability_pipelines/legacy/guide/control_log_volume_and_size" >}}ログのボリュームとサイズの制御{{< /nextlink >}} + {{< nextlink href="/observability_pipelines/legacy/guide/ingest_aws_s3_logs_with_the_observability_pipelines_worker" >}}可観測性パイプラインワーカーを使用して Amazon S3 ログを取り込む{{< /nextlink >}} + {{< nextlink href="/observability_pipelines/legacy/guide/route_logs_in_datadog_rehydratable_format_to_amazon_s3/" >}}Datadog のリハイドレート可能な形式のログを Amazon S3 にルーティングする{{< /nextlink >}} +{{< /whatsnext >}} \ No newline at end of file diff --git a/content/ja/observability_pipelines/legacy/guide/route_logs_in_datadog_rehydratable_format_to_Amazon_S3.md b/content/ja/observability_pipelines/legacy/guide/route_logs_in_datadog_rehydratable_format_to_Amazon_S3.md index db1e08f1d1852..9048a5aa7f974 100644 --- a/content/ja/observability_pipelines/legacy/guide/route_logs_in_datadog_rehydratable_format_to_Amazon_S3.md +++ b/content/ja/observability_pipelines/legacy/guide/route_logs_in_datadog_rehydratable_format_to_Amazon_S3.md @@ -194,7 +194,7 @@ Terraform で作成された IAM インスタンスプロファイルにポリ `datadog_archives` 宛先は、[コンフィギュレーションファイル](#configuration-file)または[パイプラインビルダー UI](#configuration-file) を使用して構成できます。 -
Worker が Datadog Agent から来ていないログを取り込み、それらのログが Datadog Archives 宛先にルーティングされる場合、これらのログには予約済み属性がタグ付けされません。これは、Datadog のテレメトリーや統合サービスタグ付けの利点を失うことを意味します。例えば、syslog が datadog_archives に送信され、そのログのステータスが予約済み属性の status ではなく severity としてタグ付けされ、ホストが予約済み属性の hostname ではなく hostname としてタグ付けされているとします。これらのログが Datadog で再ハイドレートされると、ログの status はすべて info に設定され、ログにはホスト名タグが付きません。
+
Worker が Datadog Agent から来ていないログを取り込み、それらのログが Datadog Archives 宛先にルーティングされる場合、これらのログには予約済み属性がタグ付けされません。これは、Datadog のテレメトリーや統合サービスタグ付けの利点を失うことを意味します。例えば、syslog が datadog_archives に送信され、そのログのステータスが予約済み属性の status ではなく severity としてタグ付けされ、ホストが予約済み属性の host ではなく hostname としてタグ付けされているとします。これらのログが Datadog で再ハイドレートされると、ログの status はすべて info に設定され、ログにはホスト名タグが付きません。
### 構成ファイル diff --git a/content/ja/observability_pipelines/log_volume_control/datadog_agent.md b/content/ja/observability_pipelines/log_volume_control/datadog_agent.md new file mode 100644 index 0000000000000..cd7f086811968 --- /dev/null +++ b/content/ja/observability_pipelines/log_volume_control/datadog_agent.md @@ -0,0 +1,233 @@ +--- +disable_toc: false +title: Datadog Agent の Log Volume Control +--- + +## 概要 + +Datadog Agent ソースを使用して Observability Pipelines Worker をセットアップし、有用なログのみを宛先にルーティングできるようにします。 + +{{% observability_pipelines/use_case_images/log_volume_control %}} + +This document walks you through the following steps: +1. The [prerequisites](#prerequisites) needed to set up Observability Pipelines +1. [Setting up Observability Pipelines](#set-up-observability-pipelines) +1. [Datadog Agent を Observability Pipelines Worker に接続する](#connect-the-datadog-agent-to-the-observability-pipelines-worker) + +## 前提条件 + +{{% observability_pipelines/prerequisites/datadog_agent %}} + +## 観測可能性パイプラインを設定する + +1. [Observability Pipelines][1] に移動します。 +1. **Log Volume Control** テンプレートを選択して新しいパイプラインを作成します。 +1. ソースとして **Datadog Agent** を選択します。 + +### Set up the source + +{{% observability_pipelines/source_settings/datadog_agent %}} + +### Set up the destinations + +Enter the following information based on your selected logs destination. + +{{< tabs >}} +{{% tab "Datadog" %}} + +{{% observability_pipelines/destination_settings/datadog %}} + +{{% /tab %}} +{{% tab "Splunk HEC" %}} + +{{% observability_pipelines/destination_settings/splunk_hec %}} + +{{% /tab %}} +{{% tab "Sumo Logic" %}} + +{{% observability_pipelines/destination_settings/sumo_logic %}} + +{{% /tab %}} +{{% tab "Syslog" %}} + +{{% observability_pipelines/destination_settings/syslog %}} + +{{% /tab %}} +{{% tab "Chronicle" %}} + +{{% observability_pipelines/destination_settings/chronicle %}} + +{{% /tab %}} +{{% tab "Elasticsearch" %}} + +{{% observability_pipelines/destination_settings/elasticsearch %}} + +{{% /tab %}} +{{% tab "OpenSearch" %}} + +{{% observability_pipelines/destination_settings/opensearch %}} + +{{% /tab %}} +{{% tab "Amazon OpenSearch" %}} + +{{% observability_pipelines/destination_settings/amazon_opensearch %}} + +{{% /tab %}} +{{< /tabs >}} + +### Set up processors + +{{% observability_pipelines/processors/intro %}} + +{{% observability_pipelines/processors/filter_syntax %}} + +{{% observability_pipelines/processors/add_processors %}} + +{{< tabs >}} +{{% tab "Filter" %}} + +{{% observability_pipelines/processors/filter %}} + +{{% /tab %}} +{{% tab "Edit fields" %}} + +{{% observability_pipelines/processors/remap %}} + +{{% /tab %}} +{{% tab "Sample" %}} + +{{% observability_pipelines/processors/sample %}} + +{{% /tab %}} +{{% tab "Grok Parser" %}} + +{{% observability_pipelines/processors/grok_parser %}} + +{{% /tab %}} +{{% tab "Quota" %}} + +{{% observability_pipelines/processors/quota %}} + +{{% /tab %}} +{{% tab "Reduce" %}} + +{{% observability_pipelines/processors/reduce %}} + +{{% /tab %}} +{{% tab "Dedupe" %}} + +{{% observability_pipelines/processors/dedupe %}} + +{{% /tab %}} +{{% tab "Sensitive Data Scanner" %}} + +{{% observability_pipelines/processors/sensitive_data_scanner %}} + +{{% /tab %}} +{{% tab "Add hostname" %}} + +{{% observability_pipelines/processors/add_hostname %}} + +{{% /tab %}} +{{% tab "Parse JSON" %}} + +{{% observability_pipelines/processors/parse_json %}} + +{{% /tab %}} +{{% tab "Enrichment table" %}} + +{{% observability_pipelines/processors/enrichment_table %}} + +{{% /tab %}} +{{< /tabs >}} + +### 観測可能性パイプラインワーカーのインストール +1. Select your platform in the **Choose your installation platform** dropdown menu. +1. Datadog Agent のアドレスを入力します。これは Datadog Agent がログデータを送信しているアドレスとポートです。Observability Pipelines Worker はこのアドレスでログを受信します。 +1. 選択した各宛先に対する環境変数を設定します。 +{{< tabs >}} +{{% tab "Datadog" %}} + +{{% observability_pipelines/destination_env_vars/datadog %}} + +{{% /tab %}} +{{% tab "Splunk HEC" %}} + +{{% observability_pipelines/destination_env_vars/splunk_hec %}} + +{{% /tab %}} +{{% tab "Sumo Logic" %}} + +{{% observability_pipelines/destination_env_vars/sumo_logic %}} + +{{% /tab %}} +{{% tab "Syslog" %}} + +{{% observability_pipelines/destination_env_vars/syslog %}} + +{{% /tab %}} +{{% tab "Chronicle" %}} + +{{% observability_pipelines/destination_env_vars/chronicle %}} + +{{% /tab %}} +{{% tab "Elasticsearch" %}} + +{{% observability_pipelines/destination_env_vars/elasticsearch %}} + +{{% /tab %}} +{{% tab "OpenSearch" %}} + +{{% observability_pipelines/destination_env_vars/opensearch %}} + +{{% /tab %}} +{{% tab "Amazon OpenSearch" %}} + +{{% observability_pipelines/destination_env_vars/amazon_opensearch %}} + +{{% /tab %}} +{{< /tabs >}} +1. Follow the instructions for your environment to install the Worker. +{{< tabs >}} +{{% tab "Docker" %}} + +{{% observability_pipelines/install_worker/docker %}} + +{{% /tab %}} +{{% tab "Amazon EKS" %}} + +{{% observability_pipelines/install_worker/amazon_eks %}} + +{{% /tab %}} +{{% tab "Azure AKS" %}} + +{{% observability_pipelines/install_worker/azure_aks %}} + +{{% /tab %}} +{{% tab "Google GKE" %}} + +{{% observability_pipelines/install_worker/google_gke %}} + +{{% /tab %}} +{{% tab "Linux (APT)" %}} + +{{% observability_pipelines/install_worker/linux_apt %}} + +{{% /tab %}} +{{% tab "Linux (RPM)" %}} + +{{% observability_pipelines/install_worker/linux_rpm %}} + +{{% /tab %}} +{{% tab "CloudFormation" %}} + +{{% observability_pipelines/install_worker/cloudformation %}} + +{{% /tab %}} +{{< /tabs >}} + +## Connect the Datadog Agent to the Observability Pipelines Worker + +{{% observability_pipelines/log_source_configuration/datadog_agent %}} + +[1]: https://app.datadoghq.com/observability-pipelines \ No newline at end of file diff --git a/content/ja/observability_pipelines/processors/generate_metrics.md b/content/ja/observability_pipelines/processors/generate_metrics.md new file mode 100644 index 0000000000000..a47d1226788e1 --- /dev/null +++ b/content/ja/observability_pipelines/processors/generate_metrics.md @@ -0,0 +1,8 @@ +--- +disable_toc: false +title: メトリクス生成プロセッサ +--- + +{{% observability_pipelines/processors/generate_metrics %}} + +{{% observability_pipelines/processors/filter_syntax %}} \ No newline at end of file diff --git a/content/ja/observability_pipelines/processors/parse_json.md b/content/ja/observability_pipelines/processors/parse_json.md new file mode 100644 index 0000000000000..0878c21c2c564 --- /dev/null +++ b/content/ja/observability_pipelines/processors/parse_json.md @@ -0,0 +1,8 @@ +--- +disable_toc: false +title: Parse JSON Processor +--- + +{{% observability_pipelines/processors/parse_json %}} + +{{% observability_pipelines/processors/filter_syntax %}} \ No newline at end of file diff --git a/content/ja/observability_pipelines/processors/reduce.md b/content/ja/observability_pipelines/processors/reduce.md new file mode 100644 index 0000000000000..1ec398b88d896 --- /dev/null +++ b/content/ja/observability_pipelines/processors/reduce.md @@ -0,0 +1,8 @@ +--- +disable_toc: false +title: Reduce Processor +--- + +{{% observability_pipelines/processors/reduce %}} + +{{% observability_pipelines/processors/filter_syntax %}} \ No newline at end of file diff --git a/content/ja/observability_pipelines/sensitive_data_redaction/http_client.md b/content/ja/observability_pipelines/sensitive_data_redaction/http_client.md new file mode 100644 index 0000000000000..a6bbb8a8f294c --- /dev/null +++ b/content/ja/observability_pipelines/sensitive_data_redaction/http_client.md @@ -0,0 +1,231 @@ +--- +disable_toc: false +title: HTTP クライアント向け機密データのマスキング +--- + +## 概要 + +クレジットカード番号、銀行のルーティング番号、API キーなどの機密データは、意図せずログに含まれる可能性があり、組織を財務面やプライバシー面のリスクにさらすおそれがあります。 + +Observability Pipelines を使用すると、ログをさまざまな宛先へルーティングする前に機密情報を特定・タグ付けし、必要に応じてマスキングまたはハッシュ化を行うことができます。メールアドレス、クレジットカード番号、API キー、認証トークンなどの一般的なパターンは、あらかじめ用意されたスキャンルールで検出可能です。また、独自の正規表現パターンを使用してカスタムスキャンルールを作成し、機密情報を検出することもできます。 + +{{% observability_pipelines/use_case_images/sensitive_data_redaction %}} + +このドキュメントでは、以下の手順を説明します。 +1. Observability Pipelines の設定に必要な[前提条件](#prerequisites) +1. [Observability Pipelines のセットアップ](#set-up-observability-pipelines) + +## 前提条件 + +{{% observability_pipelines/prerequisites/http_client %}} + +## 観測可能性パイプラインを設定する + +1. [Observability Pipelines][1] に移動します。 +1. **Sensitive Data Redactions** テンプレートを選択し、新しいパイプラインを作成します。 +1. ソースとして **HTTP Client** を選択します。 + +### ソースの設定 + +{{% observability_pipelines/source_settings/http_client%}} + +### 宛先の設定 + +選択したログの送信先に応じて、以下の情報を入力します。 + +{{< tabs >}} +{{% tab "Datadog" %}} + +{{% observability_pipelines/destination_settings/datadog %}} + +{{% /tab %}} +{{% tab "Splunk HEC" %}} + +{{% observability_pipelines/destination_settings/splunk_hec %}} + +{{% /tab %}} +{{% tab "Sumo Logic" %}} + +{{% observability_pipelines/destination_settings/sumo_logic %}} + +{{% /tab %}} +{{% tab "Syslog" %}} + +{{% observability_pipelines/destination_settings/syslog %}} + +{{% /tab %}} +{{% tab "Chronicle" %}} + +{{% observability_pipelines/destination_settings/chronicle %}} + +{{% /tab %}} +{{% tab "Elasticsearch" %}} + +{{% observability_pipelines/destination_settings/elasticsearch %}} + +{{% /tab %}} +{{% tab "OpenSearch" %}} + +{{% observability_pipelines/destination_settings/opensearch %}} + +{{% /tab %}} +{{% tab "Amazon OpenSearch" %}} + +{{% observability_pipelines/destination_settings/amazon_opensearch %}} + +{{% /tab %}} +{{< /tabs >}} + +### プロセッサーの設定 + +{{% observability_pipelines/processors/intro %}} + +{{% observability_pipelines/processors/filter_syntax %}} + +{{% observability_pipelines/processors/add_processors_sds %}} + +{{< tabs >}} +{{% tab "Filter" %}} + +{{% observability_pipelines/processors/filter %}} + +{{% /tab %}} +{{% tab "Edit fields" %}} + +{{% observability_pipelines/processors/remap %}} + +{{% /tab %}} +{{% tab "Sample" %}} + +{{% observability_pipelines/processors/sample %}} + +{{% /tab %}} +{{% tab "Grok Parser" %}} + +{{% observability_pipelines/processors/grok_parser %}} + +{{% /tab %}} +{{% tab "Quota" %}} + +{{% observability_pipelines/processors/quota %}} + +{{% /tab %}} +{{% tab "Reduce" %}} + +{{% observability_pipelines/processors/reduce %}} + +{{% /tab %}} +{{% tab "Dedupe" %}} + +{{% observability_pipelines/processors/dedupe %}} + +{{% /tab %}} +{{% tab "Sensitive Data Scanner" %}} + +{{% observability_pipelines/processors/sensitive_data_scanner %}} + +{{% /tab %}} +{{% tab "Add hostname" %}} + +{{% observability_pipelines/processors/add_hostname %}} + +{{% /tab %}} +{{% tab "Parse JSON" %}} + +{{% observability_pipelines/processors/parse_json %}} + +{{% /tab %}} +{{% tab "Enrichment table" %}} + +{{% observability_pipelines/processors/enrichment_table %}} + +{{% /tab %}} +{{< /tabs >}} + +## 観測可能性パイプラインワーカーのインストール +1. **Choose your installation platform** ドロップダウンメニューで使用するプラットフォームを選択します。 +1. HTTP/S エンドポイント URL のフルパスを入力します (例: `https://127.0.0.8/logs`)。Observability Pipelines Worker はこのエンドポイントからログイベントを収集します。 + +1. 選択した各宛先に必要な環境変数を設定します。詳細は[前提条件](#prerequisites)を参照してください。 +{{< tabs >}} +{{% tab "Datadog" %}} + +{{% observability_pipelines/destination_env_vars/datadog %}} + +{{% /tab %}} +{{% tab "Splunk HEC" %}} + +{{% observability_pipelines/destination_env_vars/splunk_hec %}} + +{{% /tab %}} +{{% tab "Sumo Logic" %}} + +{{% observability_pipelines/destination_env_vars/sumo_logic %}} + +{{% /tab %}} +{{% tab "Syslog" %}} + +{{% observability_pipelines/destination_env_vars/syslog %}} + +{{% /tab %}} +{{% tab "Chronicle" %}} + +{{% observability_pipelines/destination_env_vars/chronicle %}} + +{{% /tab %}} +{{% tab "Elasticsearch" %}} + +{{% observability_pipelines/destination_env_vars/elasticsearch %}} + +{{% /tab %}} +{{% tab "OpenSearch" %}} + +{{% observability_pipelines/destination_env_vars/opensearch %}} + +{{% /tab %}} +{{% tab "Amazon OpenSearch" %}} + +{{% observability_pipelines/destination_env_vars/amazon_opensearch %}} + +{{% /tab %}} +{{< /tabs >}} +1. 環境に合わせた手順に従い、Worker をインストールしてください。 +{{< tabs >}} +{{% tab "Docker" %}} + +{{% observability_pipelines/install_worker/docker %}} + +{{% /tab %}} +{{% tab "Amazon EKS" %}} + +{{% observability_pipelines/install_worker/amazon_eks %}} + +{{% /tab %}} +{{% tab "Azure AKS" %}} + +{{% observability_pipelines/install_worker/azure_aks %}} + +{{% /tab %}} +{{% tab "Google GKE" %}} + +{{% observability_pipelines/install_worker/google_gke %}} + +{{% /tab %}} +{{% tab "Linux (APT)" %}} + +{{% observability_pipelines/install_worker/linux_apt %}} + +{{% /tab %}} +{{% tab "Linux (RPM)" %}} + +{{% observability_pipelines/install_worker/linux_rpm %}} + +{{% /tab %}} +{{% tab "CloudFormation" %}} + +{{% observability_pipelines/install_worker/cloudformation %}} + +{{% /tab %}} +{{< /tabs >}} + +[1]: https://app.datadoghq.com/observability-pipelines \ No newline at end of file diff --git a/content/ja/observability_pipelines/sources/fluent.md b/content/ja/observability_pipelines/sources/fluent.md new file mode 100644 index 0000000000000..3af8021934e1c --- /dev/null +++ b/content/ja/observability_pipelines/sources/fluent.md @@ -0,0 +1,22 @@ +--- +disable_toc: false +title: Fluentd と Fluent Bit のソース +--- + +Observability Pipelines の Fluentd または Fluent Bit ソースを使用して、Fluentd もしくは Fluent Bit エージェントからのログを受信します。[パイプラインのセットアップ][1]時に、このソースを選択して設定してください。 + +## 前提条件 + +{{% observability_pipelines/prerequisites/fluent %}} + +## Set up the source in the pipeline UI + +[パイプラインのセットアップ][1]の際に、このソースを選択して設定します。以下の情報は、パイプライン UI におけるソース設定に関するものです。 + +{{% observability_pipelines/source_settings/fluent %}} + +## Fluent を介して Observability Pipelines Worker にログを送信します。 + +{{% observability_pipelines/log_source_configuration/fluent %}} + +[1]: /ja/observability_pipelines/set_up_pipelines/ \ No newline at end of file diff --git a/content/ja/observability_pipelines/sources/sumo_logic.md b/content/ja/observability_pipelines/sources/sumo_logic.md new file mode 100644 index 0000000000000..db67059226f3d --- /dev/null +++ b/content/ja/observability_pipelines/sources/sumo_logic.md @@ -0,0 +1,20 @@ +--- +disable_toc: false +title: Sumo Logic ホスト型コレクター +--- + +Observability Pipelines の Sumo Logic ホスト型コレクターソースを使用し、Sumo Logic ホスト型コレクターに送信されたログを受信します。パイプラインを[設定する][1]際に、このソースを選択してセットアップしてください。 + +## 前提条件 + +{{% observability_pipelines/prerequisites/sumo_logic %}} + +## パイプライン UI でソースをセットアップする + +パイプラインを[設定する][1]際に、このソースを選択してセットアップしてください。以下に示す情報は、パイプライン UI 内のソース設定についてのものです。 + +{{% observability_pipelines/source_settings/sumo_logic %}} + +{{% observability_pipelines/log_source_configuration/sumo_logic %}} + +[1]: /ja/observability_pipelines/set_up_pipelines/ \ No newline at end of file diff --git a/content/ja/partners/_index.md b/content/ja/partners/_index.md index 12b541105bea2..1667618842b5e 100644 --- a/content/ja/partners/_index.md +++ b/content/ja/partners/_index.md @@ -1,82 +1,6 @@ --- -description: セールス・サービスパートナー向けの Datadog の始め方 -private: true -title: パートナー +cascade: + type: partners +external_redirect: /partners/getting_started/ +title: Partners --- - -Datadog は、クライアントのハイブリッドクラウドインフラストラクチャーとアプリケーションに対するインサイトを提供します。直感的な UI と強力な API により、クライアントの多様な環境のオンボード、プロビジョニング、管理を実現し、各アカウントのデータセキュリティを確立することができます。 - -## はじめに - -ベストプラクティスを学び、クライアント環境の監視を始めましょう。 - -- [基礎固め][1]: どのように始めるか、最初の段階でどのような重要な決定を下すかについての情報が記載されています。 -- [データの取り込み][2]: Datadog にデータを取り込む方法と、環境で満たす必要のある前提条件について説明します。 -- [価値の提供][3]: Datadog にデータを流した後の推奨ステップを説明します。 -- [Billing and Usage Reporting][4]: Covers monitoring individual client and aggregate usage of the Datadog platform in single and multi-organization account setups. - -## パートナーセールスイネーブルメントガイド - -Datadog のセールスエンジニアリングプロセスに備えるためのトレーニングロードマップについては、[パートナーセールスイネーブルメントガイド][5]を参照してください。 -## Datadog の最新情報 - -Datadog の最新情報を入手し、新機能を知るための方法は複数あります。 -- Datadog サイトで[リリースノートを見る][6]ことができます -- Datadog Partner Network のメンバーは、[Datadog Partner Network ポータル][7]に特別にアクセスすることができます。そこには、以下のものがあります。 - - 資料・トレーニング教材 - - 四半期ごとの DPN ライブブリーフィングウェビナー: 録画セッションをアセットライブラリで見るか、受信トレイで招待状を確認します。 -- Datadog は、クラウドにおけるスケーラブルな分散システムについて学んだ多くの教訓を、[Datadog on...][8] シリーズで紹介しています。 - -### ステータス情報 - -Datadog は、最新のサービスステータス情報を取得するために、以下のリソースを提供しています。 -- US 地域: [https://status.datadoghq.com][9] -- EU 地域: [https://status.datadoghq.eu][10] - -このページを購読すると、ステータス変更に関するお知らせを受け取ることができます。 - -Datadog で有効化したサードパーティインテグレーションのステータスを確認したい場合は、[https://datadogintegrations.statuspage.io][11] を参照してください。 - -### その他のリソース - -Datadog の最新情報を入手するためのその他の重要なリソースをご覧ください。 - -{{< whatsnext desc="GitHub リポジトリ" >}} - {{< nextlink href="https://github.com/DataDog/datadog-agent/" >}}Datadog Agent: Datadog Agent バージョン 7 とバージョン 6 のソースコード。 {{< /nextlink >}} - {{< nextlink href="https://github.com/DataDog/integrations-core/" >}}インテグレーションコア: Datadog が公式に開発・サポートする Agent インテグレーション。{{< /nextlink >}} - {{< nextlink href="https://github.com/DataDog/integrations-extras/" >}}インテグレーションエクストラ: コミュニティが管理する Datadog インテグレーション。{{< /nextlink >}} - {{< nextlink href="https://github.com/DataDog/Miscellany" >}}その他: Datadog の各種スクリプトとツール。{{< /nextlink >}} -{{< /whatsnext >}} - -{{< whatsnext desc="Datadog のブログとソーシャルメディア" >}} - {{< nextlink href="www.datadoghq.com/blog/" >}}Datadog ブログ{{< /nextlink >}} - {{< nextlink href="https://www.linkedin.com/company/datadog/" >}}LinkedIn{{< /nextlink >}} - {{< nextlink href="https://twitter.com/datadoghq" >}}Twitter{{< /nextlink >}} - {{< nextlink href="https://www.facebook.com/datadoghq/" >}}Facebook{{< /nextlink >}} -{{< /whatsnext >}} - -{{< whatsnext desc="YouTube" >}} - {{< nextlink href="https://www.youtube.com/user/DatadogHQ" >}}YouTube 公式チャンネル{{< /nextlink >}} - {{< nextlink href="https://www.youtube.com/playlist?list=PLdh-RwQzDsaM9Sq_fi-yXuzhmE7nOlqLE" >}}ヒントとコツのプレイリスト{{< /nextlink >}} -{{< /whatsnext >}} - -{{< whatsnext desc="Dash Conferences playlists" >}} - {{< nextlink href="https://www.youtube.com/playlist?list=PLdh-RwQzDsaPhn1p7Sz6nc_6-9YInd__u" >}}Dash 2023{{< /nextlink >}} - {{< nextlink href="https://www.youtube.com/playlist?list=PLdh-RwQzDsaOlLse2WlvFXYRJ8iirG2QO" >}}Dash 2022{{< /nextlink >}} - {{< nextlink href="https://www.youtube.com/playlist?list=PLdh-RwQzDsaO-_rgnDSBn221gWacNCkDr" >}}Dash 2021{{< /nextlink >}} - {{< nextlink href="https://www.youtube.com/playlist?list=PLdh-RwQzDsaMlgvtlJRyXGgt4i-9Oiyi1" >}}Dash 2020{{< /nextlink >}} - {{< nextlink href="https://www.youtube.com/playlist?list=PLdh-RwQzDsaPkMoleskq9YcWMWvYfBCRB" >}}Dash 2019{{< /nextlink >}} - -{{< /whatsnext >}} - -[1]: /ja/partners/laying-the-groundwork/ -[2]: /ja/partners/data-intake/ -[3]: /ja/partners/delivering-value/ -[4]: /ja/partners/billing-and-usage-reporting/ -[5]: /ja/partners/sales-enablement/ -[6]: https://app.datadoghq.com/release-notes -[7]: https://partners.datadoghq.com/ -[8]: https://datadogon.datadoghq.com/ -[9]: https://status.datadoghq.com -[10]: https://status.datadoghq.eu -[11]: https://datadogintegrations.statuspage.io \ No newline at end of file diff --git a/content/ja/product_analytics/session_replay/mobile/privacy_options.md b/content/ja/product_analytics/session_replay/mobile/privacy_options.md new file mode 100644 index 0000000000000..e0b7244abd8dc --- /dev/null +++ b/content/ja/product_analytics/session_replay/mobile/privacy_options.md @@ -0,0 +1,22 @@ +--- +description: モバイルセッションリプレイのプライバシーオプションの構成 +further_reading: +- link: /product_analytics/session_replay/mobile + tag: ドキュメント + text: モバイルセッションリプレイ +- link: /product_analytics/session_replay/mobile/app_performance + tag: ドキュメント + text: モバイルセッションリプレイがアプリのパフォーマンスに与える影響 +- link: /product_analytics/session_replay/mobile/setup_and_configuration + tag: ドキュメント + text: モバイルセッションリプレイの設定と構成 +- link: /product_analytics/session_replay/mobile/troubleshooting + tag: ドキュメント + text: モバイルセッションリプレイのトラブルシューティング +- link: /product_analytics/session_replay + tag: ドキュメント + text: セッション リプレイ +title: モバイルセッションリプレイのプライバシーオプション +--- + +{{< include-markdown "real_user_monitoring/session_replay/mobile/privacy_options" >}} \ No newline at end of file diff --git a/content/ja/profiler/enabling/php.md b/content/ja/profiler/enabling/php.md index 469e0b39691ef..d3a856ce2b7bd 100644 --- a/content/ja/profiler/enabling/php.md +++ b/content/ja/profiler/enabling/php.md @@ -15,7 +15,7 @@ further_reading: text: プロファイラの使用中に発生する問題を修正 - link: https://www.datadoghq.com/blog/php-exception-profiling/ tag: ブログ - text: Why care about exception profiling in PHP? + text: PHP で例外プロファイリングを行うべき理由 title: PHP プロファイラーの有効化 type: multi-code-lang --- @@ -26,7 +26,7 @@ type: multi-code-lang Datadog Profiler を使用するには、64 ビットの Linux で、少なくとも PHP 7.1 が必要です。 -PHP ZTS builds are supported since `dd-trace-php` version 0.99+, while PHP debug builds are **not** supported. +PHP ZTS ビルドは `dd-trace-php` バージョン 0.99 以降でサポートされていますが、PHP デバッグ ビルドは **サポートされていません**。 {{< tabs >}} {{% tab "GNU C Linux" %}} @@ -52,27 +52,27 @@ apk add libgcc {{% /tab %}} {{< /tabs >}} -The following profiling features are available in the following minimum versions of the `dd-trace-php` library: +`dd-trace-php` ライブラリで次のプロファイリング機能を利用するには、以下の最小バージョンが必要です: -| 機能 | Required `dd-trace-php` version | +| 機能 | 必要な `dd-trace-php` バージョン | |---------------------------|------------------------------------------| | [Code Hotspots][12] | 0.71+ | | [Endpoint Profiling][13] | 0.79.0+ | -| [Timeline][15] | 0.98.0+ (beta since 0.89.0+) | +| [タイムライン][15] | 0.98.0+ | -Continuous Profiler は、AWS Lambda などのサーバーレスプラットフォームには対応していません。 +Continuous Profiler は、AWS Lambda などの一部のサーバーレスプラットフォームには対応していません。 ## インストール アプリケーションのプロファイリングを開始するには -1. Ensure Datadog Agent v6+ is installed and running. Datadog recommends using [Datadog Agent v7+][2]. +1. Datadog Agent v6 以上がインストールされ、稼働していることを確認してください。Datadog は [Datadog Agent v7+][2] の使用を推奨しています。 2. [GitHub リリースページ][3]から `datadog-setup.php` スクリプトをダウンロードします。バージョン 0.69.0 は、このインストーラーを含む最初のトレーサーのリリースです。 3. トレーサーとプロファイラーの両方をインストールするために、例えば `php datadog-setup.php --enable-profiling` のようにインストーラーを実行します。このスクリプトは対話型で、検出された PHP の位置のどれにインストールするかを尋ねます。スクリプトの最後には、今後の使用のために非対話型バージョンのコマンド引数を出力します。 -4. Configure the profiler using config mode through the `datadog-setup.php`: +4. `datadog-setup.php` の config モードを使用してプロファイラを設定します: ``` # `datadog.profiling.enabled` is not required for v0.82.0+. @@ -86,10 +86,10 @@ Continuous Profiler は、AWS Lambda などのサーバーレスプラットフ php hello.php ``` - Apache, PHP-FPM and other servers require a restart after changing the INI -settings. + Apache、PHP-FPM などのサーバーは、INI 設定を変更した後に再起動が +必要です。 - See the [configuration docs][4] for more INI settings. + 詳細な INI 設定については [構成ドキュメント][4] を参照してください。 5. リクエストを受け取ってから 1～2 分後、[APM > Profiler ページ][5]にプロファイルが表示されます。 diff --git a/content/ja/real_user_monitoring/error_tracking/explorer.md b/content/ja/real_user_monitoring/error_tracking/explorer.md new file mode 100644 index 0000000000000..e0fcdaa97d801 --- /dev/null +++ b/content/ja/real_user_monitoring/error_tracking/explorer.md @@ -0,0 +1,10 @@ +--- +description: エラー追跡エクスプローラーについて説明します。 +further_reading: +- link: /monitors/types/error_tracking + tag: ドキュメント + text: エラー追跡モニターについて +title: エラー追跡エクスプローラー +--- + +{{< include-markdown "error_tracking/explorer" >}} \ No newline at end of file diff --git a/content/ja/real_user_monitoring/error_tracking/mobile/flutter.md b/content/ja/real_user_monitoring/error_tracking/mobile/flutter.md new file mode 100644 index 0000000000000..2a843cd71b803 --- /dev/null +++ b/content/ja/real_user_monitoring/error_tracking/mobile/flutter.md @@ -0,0 +1,165 @@ +--- +aliases: +- /ja/real_user_monitoring/error_tracking/flutter +code_lang: flutter +code_lang_weight: 40 +dependencies: +- https://github.com/DataDog/dd-sdk-flutter/blob/main/packages/datadog_flutter_plugin/doc/rum/error_tracking.md +description: Error Tracking を使用して Flutter のエラーを追跡する方法を学びます。 +further_reading: +- link: https://github.com/DataDog/dd-sdk-flutter + tag: ソース コード + text: dd-sdk-flutter のソース コード +- link: real_user_monitoring/error_tracking/ + tag: ドキュメント + text: Error Tracking について学ぶ +title: Flutter の Crash Reporting と Error Tracking +type: multi-code-lang +--- +## 概要 + +Real User Monitoring と併用して Crash Reporting と Error Tracking を有効化すると、包括的なクラッシュ レポートとエラーのトレンドを取得できます。 + +クラッシュ レポートは [**Error Tracking**][1] に表示されます。 + +## セットアップ + +まだ Datadog Flutter SDK をセットアップしていない場合は、 [アプリ内セットアップ手順][2] に従うか、 [Flutter セットアップ ドキュメント][3] を参照してください。 + +### Dart エラー トラッキングを追加 + +`DatadogSdk.runApp` を使用している場合、 Datadog Flutter SDK はキャッチされない Dart 例外を自動的に追跡してレポートします。 + +`DatadogSdk.runApp` を使用して **いない** 場合は、 Datadog を初期化する前に、次のコードで Dart エラー トラッキングを手動で設定する必要があります: + +```dart +final originalOnError = FlutterError.onError; +FlutterError.onError = (details) { + DatadogSdk.instance.rum?.handleFlutterError(details); + originalOnError?.call(details); +}; +final platformOriginalOnError = PlatformDispatcher.instance.onError; +PlatformDispatcher.instance.onError = (e, st) { + DatadogSdk.instance.rum?.addErrorInfo( + e.toString(), + RumErrorSource.source, + stackTrace: st, + ); + return platformOriginalOnError?.call(e, st) ?? false; +}; +``` + +### ネイティブ クラッシュ レポートを追加 + +iOS と Android 向けにネイティブ クラッシュ レポートを有効化するには、初期化スニペットを更新し、`nativeCrashReportEnabled` を `true` に設定します。 + +例: + +```dart +final configuration = DatadogConfiguration( + clientToken: '' + env: '' + site: DatadogSite.us1, + nativeCrashReportEnabled: true, // Set this flag + loggingConfiguration: DatadogLoggingConfiguration(), + rumConfiguration: DatadogRumConfiguration( + applicationId: '', + ), +); +``` + +アプリケーションが致命的なクラッシュを起こした場合、Datadog Flutter SDK はアプリの再起動後にクラッシュ レポートを Datadog にアップロードします。致命的でないエラーについては、Datadog Flutter SDK は他の RUM データとともにこれらのエラーをアップロードします。 + +## 難読化解除済みのスタック トレースを取得 + +マッピング ファイルはスタック トレースの難読化解除に使用され、エラーのデバッグに役立ちます。生成される一意のビルド ID を用いて、Datadog は対応するマッピング ファイルと正しいスタック トレースを自動的に照合します。これにより、マッピング ファイルがいつアップロードされたか (プレプロダクションまたはプロダクション ビルド中) に関係なく、Datadog に報告されたクラッシュやエラーをレビューする際に、効率的な QA プロセスのための正しい情報が利用可能になります。 + +Flutter アプリケーションでは、スタック トレースとソース マップの対応付けは、それらの `service`、`version`、`variant`、`architecture` フィールドに依存します。 + +### シンボル ファイルを Datadog にアップロード + +ネイティブ iOS のクラッシュ レポートは生の形式で収集され、主にメモリ アドレスを含みます。これらのアドレスを可読なシンボル情報にマッピングするには、アプリケーションのビルド プロセスで生成される .dSYM ファイルを Datadog にアップロードする必要があります。 + +`--split-debug-info` オプションや `--obfuscate` オプションを設定してビルドされた Flutter の iOS および Android アプリケーションから送信されるクラッシュ レポートおよびエラーも、生または難読化された形式になります。これらのアプリケーションでは、Flutter のビルド プロセスで生成される Android Proguard マッピング ファイルと Dart シンボル ファイルをアップロードする必要があります。 + +Flutter Web アプリケーションから送信されるエラーは、マッピングされていない JavaScript のファイルと行番号を含みます。これらは Dart のファイルと行番号にマッピングする必要があります。このようなアプリケーションでは、Flutter のビルド プロセスで生成された JavaScript ソース マップをアップロードする必要があります。 + +[@datadog/datadog-ci][4] コマンド ライン ツールは、必要なファイル (dSYM、Android Proguard マッピング、Dart シンボル ファイル) を 1 回のコマンドでアップロードすることをサポートします。 + +まず、上記の手順に従って `datadog-ci` ツールをインストールし、プロジェクトのルートに `datadog-ci.json` ファイルを作成して、API キーと (任意で) Datadog サイトを含めます: +```json +{ + "apiKey": "", + "datadogSite": "datadoghq.eu" // datadoghq.com を使用している場合はオプション +} +``` + +このファイルには API キーが含まれるため、バージョン管理にコミットしないでください。 + +または、`DATADOG_API_KEY` と `DATADOG_SITE` の環境変数を設定することもできます。 + +次に、クラッシュ レポートのシンボリケーションと難読化解除に必要なすべてのファイルを、次のコマンドでアップロードできます: +```sh +datadog-ci flutter-symbols upload --service-name --dart-symbols-location --android-mapping --ios-dsyms +``` + +**注**: バージョンが変更されていない場合、ソース マップを再アップロードしても既存のものは上書きされません。 + +利用可能なオプションの全一覧については、`datadog-ci` の [Flutter Symbols ドキュメント][5] を参照してください。 + +### アップロード済みのシンボル ファイルを一覧表示 + +すべてのアップロード済みシンボルを表示するには、[RUM Debug Symbols][10] ページを参照してください。 + +## 制限事項 + +マッピング ファイルは、それぞれのサイズが **500 MB** に制限されています。一方、dSYM ファイルは各 **2 GB** まで対応できます。 + +## 実装をテストする + +Flutter の Crash Reporting と Error Tracking 設定を検証するには、アプリケーションで意図的にエラーを発生させ、Datadog にエラーが表示されることを確認します。 + +1. アプリケーションをシミュレーター、エミュレーター、または実機で実行します。iOS で実行している場合は、デバッガがアタッチされていないことを確認してください。そうでないと、Datadog SDK より先に Xcode がクラッシュを捕捉します。 +2. エラーやクラッシュを含むコードを実行します。例えば: + + ```dart + void throwError() { + throw Exception("My Exception") + } + ``` + +3. クラッシュに至らない難読化済みのエラー レポートについては、 [**Error Tracking**][8] でシンボリケーションと難読化解除を確認できます。 +4. クラッシュの場合は、クラッシュ発生後にアプリケーションを再起動し、Flutter SDK が [**Error Tracking**][8] にクラッシュ レポートをアップロードするまで待ちます。 + +### フレーバーとビルド番号 + +Datadog は `service-name`、`version`、`flavor` の組み合わせを使用して、難読化解除に必要な正しいシンボルを特定します。クラッシュ レポートに完全な情報を含めるには、`datadog-ci` コマンドに渡すパラメーターと、 [DatadogConfiguration][6] で設定するパラメーターが厳密に一致している必要があります。 + +Flutter でアプリの [フレーバー][7] を使用している場合は、 [DatadogConfiguration.flavor][8] でフレーバー名を設定する必要があります。フレーバーは自動検出できないためです。その後、 `datadog-ci` コマンドの `--flavor` パラメーターにこれを渡します: + +```sh +datadog-ci flutter-symbols upload --service-name --dart-symbols-location --android-mapping --ios-dsyms --flavor my_flavor +``` + +Datadog SDK は、 `pubspec.yaml` に指定されたアプリケーションのバージョン番号を、ビルド番号を含まない範囲まで自動的に検出します。アプリケーションでバージョンにビルド番号を含めており、ビルドごとにシンボルをアップロードする必要がある場合は、 [DatadogConfiguration.version][9] にそのバージョンを追加してください。その後、 `datadog-ci` コマンドの `--version` パラメーターにこれを渡します: + +```sh +datadog-ci flutter-symbols upload --service-name --dart-symbols-location --android-mapping --ios-dsyms --version 1.2.3+22 +``` + +**注**: Datadog はバージョンのタグ付けに `+` を使用できません。すべてのツールは、Datadog でバージョン タグを検索可能にするために `+` を `-` に自動置換します。 + +## 参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://app.datadoghq.com/rum/error-tracking +[2]: https://app.datadoghq.com/rum/application/create +[3]: https://docs.datadoghq.com/ja/real_user_monitoring/mobile_and_tv_monitoring/flutter/setup +[4]: https://www.npmjs.com/package/@datadog/datadog-ci +[5]: https://github.com/DataDog/datadog-ci/tree/master/src/commands/flutter-symbols +[6]: https://pub.dev/documentation/datadog_flutter_plugin/latest/datadog_flutter_plugin/DatadogConfiguration-class.html +[7]: https://docs.flutter.dev/deployment/flavors +[8]: https://pub.dev/documentation/datadog_flutter_plugin/latest/datadog_flutter_plugin/DatadogConfiguration/flavor.html +[9]: https://pub.dev/documentation/datadog_flutter_plugin/latest/datadog_flutter_plugin/DatadogConfiguration/version.html +[10]: https://app.datadoghq.com/source-code/setup/rum \ No newline at end of file diff --git a/content/ja/real_user_monitoring/guide/initialize-your-native-sdk-before-react-native-starts.md b/content/ja/real_user_monitoring/guide/initialize-your-native-sdk-before-react-native-starts.md new file mode 100644 index 0000000000000..4a86b48fc5bff --- /dev/null +++ b/content/ja/real_user_monitoring/guide/initialize-your-native-sdk-before-react-native-starts.md @@ -0,0 +1,116 @@ +--- +algolia: + tags: + - bots +description: React Native が起動する前にネイティブ SDK を初期化する方法を学びましょう +further_reading: +- link: real_user_monitoring/dashboards/usage + tag: ドキュメント + text: React Native のモニタリングについて +title: React Native 起動前にネイティブ SDK を初期化する +--- + +## 概要 + +デフォルトでは、React Native SDK は JS レイヤーで `DdSdkReactNative.initialize(config)` を呼び出すか、`DatadogProvider` を使用する際にネイティブ SDK を初期化します。そのため、JS レイヤーで初期化が呼び出される前に発生したネイティブのクラッシュは SDK によってキャプチャされません。バージョン v2.3.0 以降では、React Native レイヤーが起動する前にクラッシュを捕捉するために、ネイティブ SDK を初期化できます。 + +## 構成 + +React Native が起動する前にネイティブ SDK を初期化するには、次の手順に従います。 + +1. `react-native` プロジェクトのルートに、以下の構造を持つ `datadog-configuration.json` ファイルを作成します。 + + ```json + { + "$schema": "./node_modules/@datadog/mobile-react-native/datadog-configuration.schema.json", + "configuration": { + } + } + ``` + + `"$schema"` 属性を指定すると、オートコンプリートが有効になり、設定が不完全または無効な場合に多くの最新 IDE でエラーが表示されるようになります。 + + {{< img src="real_user_monitoring/guide/initialize-your-native-sdk-before-react-native-starts/initialize-sdk-before-rn-1.png" alt="設定が不完全または無効な場合、IDE にエラーが表示されることがあります" style="width:100%" >}} + + {{< img src="real_user_monitoring/guide/initialize-your-native-sdk-before-react-native-starts/initialize-sdk-before-rn-2.png" alt="設定が不完全または無効な場合、IDE にエラーが表示されることがあります" style="width:100%" >}} + + {{< img src="real_user_monitoring/guide/initialize-your-native-sdk-before-react-native-starts/initialize-sdk-before-rn-3.png" alt="設定が不完全または無効な場合、IDE にエラーが表示されることがあります" style="width:100%" >}} + +2. ご利用の OS に応じて、以下の手順に従ってください。 + + {{< tabs >}} + {{% tab "Android" %}} + + 1. `MainApplication.kt` ファイルに次のスニペットを追加します。 + + ```kotlin + import com.datadog.reactnative.DdSdkNativeInitialization + + class MainApplication : Application(), ReactApplication { + override fun onCreate() { + super.onCreate() + DdSdkNativeInitialization.initFromNative(this.applicationContext) + // Rest of the method + } + } + ``` + + 2. さらに、`android/app/build.gradle` ファイルに次のスニペットを追加します。 + + ```gradle + apply from: "../../node_modules/@datadog/mobile-react-native/datadog-configuration.gradle" + ``` + + このスクリプトは、ビルドのアセットディレクトリに設定ファイルをコピーします。 + + {{% /tab %}} + {{% tab "iOS" %}} + + 1. `AppDelegate.mm` ファイルに次のスニペットを追加します。 + + ```objc + // Add this import + #import "DdSdk.h" + + - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions + { + [DdSdk initFromNative]; + // rest of the function + } + ``` + + 2. `datadog-configuration.json` ファイルをプロジェクトのリソースに追加します。 + + {{% /tab %}} + {{% tab "JS" %}} + + 同一ファイルを参照して Datadog を初期化するように変更し、設定の一貫性を保ちます。 + + ```jsx + const configuration = new FileBasedConfiguration(require("./datadog-configuration.json")) + + + // Rest of the app + + ``` + + {{% /tab %}} + {{< /tabs >}} + +## 設定ファイルの場所 + +OS によって設定ファイルの場所が異なります。 + +- **Android**: 次のスニペットを追加して、コピー元のファイルのパスを指定できます。 + + ```gradle + project.ext.datadog = [ + configurationFilePath: "../../../datadog-configuration.json" + ] + ``` +- **iOS**: 設定ファイルは配置場所にかかわらず、ビルド時にプロジェクトの Resources ディレクトリ直下へコピーされます。 +- **React Native**: `require` パターンを使用することで、任意のパスを指定できます。 + +## その他の参考資料 + +{{< partial name="whats-next/whats-next.html" >}} \ No newline at end of file diff --git a/content/ja/real_user_monitoring/mobile_and_tv_monitoring/ios/error_tracking.md b/content/ja/real_user_monitoring/mobile_and_tv_monitoring/ios/error_tracking.md new file mode 100644 index 0000000000000..f118ee03e08fd --- /dev/null +++ b/content/ja/real_user_monitoring/mobile_and_tv_monitoring/ios/error_tracking.md @@ -0,0 +1,319 @@ +--- +title: iOS Crash Reporting と Error Tracking +--- + +## 概要 + +iOS Crash Reporting と Error Tracking を有効にすると、包括的なクラッシュ レポートとエラーのトレンドを取得できます。この機能により、以下にアクセスできます: + + - 集約された iOS クラッシュ ダッシュボードと属性 + - シンボリケート済みの iOS クラッシュ レポート + - iOS Error Tracking によるトレンド分析 + +スタック トレースをシンボリケートするには、`.dSYM` ファイルを見つけて Datadog にアップロードします。次に、テスト クラッシュを実行してアプリケーションを再起動し、構成を検証します。 + +クラッシュ レポートは [**Error Tracking**][1] に表示されます。 + +## セットアップ + +iOS SDK をまだセットアップしていない場合は、[アプリ内セットアップ手順][2] に従うか、[iOS セットアップ ドキュメント][3] を参照してください。 + +### クラッシュ レポーティングを追加 + +Crash Reporting を有効にするには、使用している依存関係マネージャに応じてパッケージを追加し、初期化スニペットを更新します。 + +{{< tabs >}} +{{% tab "CocoaPods" %}} + +[CocoaPods][1] を使用して `dd-sdk-ios` をインストールできます: +``` +pod 'DatadogCrashReporting' +``` + +[1]: https://cocoapods.org/ + +{{% /tab %}} +{{% tab "Swift Package Manager (SPM)" %}} + +Apple の Swift Package Manager を使用して統合するには、`Package.swift` に次を依存関係として追加します: +```swift +.package(url: "https://github.com/Datadog/dd-sdk-ios.git", .upToNextMajor(from: "2.0.0")) +``` + +プロジェクトで、次のライブラリをリンクします: +``` +DatadogCrashReporting +``` + +{{% /tab %}} +{{% tab "Carthage" %}} + +[Carthage][1] を使用して `dd-sdk-ios` をインストールできます: +``` +github "DataDog/dd-sdk-ios" +``` + +Xcode で、次のフレームワークをリンクします: +``` +DatadogCrashReporting.xcframework +CrashReporter.xcframework +``` + +[1]: https://github.com/Carthage/Carthage + +{{% /tab %}} +{{< /tabs >}} + +初期化スニペットを更新して Crash Reporting を含める + +```swift +import DatadogCore +import DatadogCrashReporting + +Datadog.initialize( + with: Datadog.Configuration( + clientToken: "", + env: "", + service: "" + ), + trackingConsent: trackingConsent +) + +CrashReporting.enable() +``` + +### アプリ ハング レポーティングを追加 + +アプリ ハングは、アプリケーションが長時間応答しないときに発生する iOS 固有のエラー タイプです。 + +既定ではアプリ ハングのレポーティングは **無効** ですが、初期化パラメータ `appHangThreshold` を使用すると有効化でき、指定した時間を超えるアプリ ハングを監視するための独自のしきい値を設定できます。しきい値を調整できることで、きめ細かな観測性とノイズの多さのバランスを最適化できます。設定の詳細は [アプリ ハングのしきい値を構成する][5] を参照してください。 + +アプリ ハングは iOS SDK を通じてレポートされます ([Logs][4] ではありません)。 + +有効化すると、指定した `appHangThreshold` より長いメイン スレッドの一時停止は、[**Error Tracking**][1] で _ハング_ と見なされます。ハングには 2 種類あります: + +- **致命的なアプリ ハング**: ハングから回復せず、アプリが終了された場合のレポート方法です。致命的なアプリ ハングには、Error Tracking と RUM Explorer で「Crash」のマークが付きます。 + + {{< img src="real_user_monitoring/error_tracking/ios-fatal-app-hang.png" alt="Error パネルのサイドに表示された致命的なアプリ ハングの例。" style="width:60%;" >}} + +- **非致命的なアプリ ハング**: 比較的短いハングからアプリが回復し、実行を継続した場合のレポート方法です。非致命的なアプリ ハングには、Error Tracking と RUM Explorer で「Crash」のマークは付きません。 + + {{< img src="real_user_monitoring/error_tracking/ios-non-fatal-app-hang.png" alt="Error パネルのサイドに表示された非致命的なアプリ ハングの例。" style="width:60%;" >}} + +#### アプリ ハング監視を有効化 + +アプリ ハング監視を有効にするには: + +1. [Crash Reporting を有効化][19] + +2. 初期化スニペットに `appHangThreshold` パラメータを追加して更新します: + + ```swift + RUM.enable( + with: RUM.Configuration( + applicationID: "", + appHangThreshold: 0.25 + ) + ) + ``` + +3. アプリ ハングをレポートしたい最小の継続時間に `appHangThreshold` を設定します。たとえば、少なくとも 250 ms のハングをレポートするには `0.25` を指定します。設定の考え方は [アプリ ハングのしきい値を構成する][5] を参照してください。 + + 必ず、以下の手順に従って [難読化解除済みのスタック トレース][6] を取得できるようにしてください。 + +#### アプリ ハングのしきい値を構成する + +- Apple は Xcode Organizer のハング率メトリクスで 250 ms を超えるハングのみを対象とします。Datadog は、`appHangThreshold` の初期値として同様に `0.25` を設定し、その後、適切な設定が見つかるまで段階的に下げるまたは上げることを推奨します。 + +- ノイズとなるハングの大半をふるい落とすには、`appHangThreshold` を 2～3 秒に設定することをおすすめします。 + +- `appHangThreshold` に設定できる最小値は `0.1` 秒 (100 ms) です。ただし、しきい値を極端に小さくすると、ハングの過剰なレポートにつながる可能性があります。 + +- SDK はアプリ ハングを監視するためのセカンダリ スレッドを実装しています。CPU 使用率を抑えるため、2.5% の許容誤差でハングを追跡します。そのため、`appHangThreshold` に近い長さの一部のハングはレポートされない場合があります。 + + +#### アプリ ハング監視を無効化 + +アプリ ハング監視を無効にするには、初期化スニペットを更新し、パラメータ `appHangThreshold` を `nil` に設定します。 + +### ウォッチドッグ ターミネーションのレポーティングを追加 + +Apple エコシステムでは、オペレーティング システムがウォッチドッグ メカニズムを用いてアプリケーションの健全性を監視し、応答しなくなったり、CPU やメモリなどのリソースを過剰に消費した場合に終了させます。これらのウォッチドッグ ターミネーションは致命的で、復旧できません (詳細は公式の [Apple ドキュメント][12] を参照)。 + +既定ではウォッチドッグ ターミネーションのレポーティングは **無効** ですが、初期化パラメータ `trackWatchdogTerminations` を使用して有効化できます。 + +有効化すると、次回のアプリケーション起動時に、ヒューリスティックに基づいて前回のユーザー セッションにウォッチドッグ ターミネーションがレポートされ、紐付けられます: + +- その間にアプリケーションがアップグレードされていないこと + +- アプリが `exit` も `abort` も呼び出していないこと + +- 例外、または致命的な [アプリ ハング][13] によるクラッシュではないこと + +- ユーザーによって強制終了されていないこと + +- デバイスが再起動していないこと (OS のアップグレードを含む) + +{{< img src="real_user_monitoring/error_tracking/ios-watchdog-termination.png" alt="Error Tracking のサイド パネルに表示されたウォッチドッグ ターミネーションの例。" style="width:60%;" >}} + +#### ウォッチドッグ ターミネーションのレポーティングを有効化 + +ウォッチドッグ ターミネーションのレポーティングを有効化するには: + +1. [Crash Reporting を有効化][19] + +2. 初期化スニペットを `trackWatchdogTerminations` フラグで更新します: + + ```swift + RUM.enable( + with: RUM.Configuration( + applicationID: "", + trackWatchdogTerminations: true + ) + ) + ``` + +#### ウォッチドッグ ターミネーションのレポーティングを無効化 + +ウォッチドッグ ターミネーションのレポーティングを無効化するには、初期化スニペットを更新し、パラメータ `trackWatchdogTerminations` を `false` に設定します。 + +## 難読化解除済みのスタック トレースを取得する + +マッピング ファイルはスタック トレースの難読化を解除するために使用され、エラーのデバッグに役立ちます。生成される一意のビルド ID を使用して、Datadog は正しいスタック トレースを対応するマッピング ファイルに自動的に照合します。これにより、マッピング ファイルのアップロード時期がいつであっても (プレ プロダクション ビルドでもプロダクション ビルドでも)、Datadog にレポートされたクラッシュやエラーをレビューする際に、効率的な QA プロセスのための正しい情報を利用できます。 + +iOS アプリケーションでは、スタック トレースとシンボル ファイルの照合は、それぞれの `uuid` フィールドに基づいて行われます。 + +### クラッシュ レポートをシンボリケートする + +クラッシュ レポートは生の形式で収集され、多くはメモリ アドレスを含みます。これらのアドレスを可読なシンボル情報にマップするために、Datadog では `dSYM` ファイルが必要です。`dSYM` ファイルはアプリケーションのビルドまたは配布プロセスで生成されます。 + +### .dSYM ファイルを見つける + +すべての iOS アプリケーションは、各アプリケーション モジュールごとに `.dSYM` ファイルを生成します。これらのファイルはアプリケーションのバイナリ サイズを最小化し、ダウンロード 速度の向上に寄与します。各アプリケーション バージョンには `.dSYM` ファイル一式が含まれます。 + +セットアップによっては、`.dSYM` ファイルを App Store Connect からダウンロードするか、ローカル マシン上で見つける必要があります。 + +| Bitcode Enabled | 説明 | +|---|---| +| Yes | [App Store Connect][7] がアプリケーションのビルド処理を完了した後に、`.dSYM` ファイルが利用可能になります。 | +| No | Xcode は、アプリケーションのビルドの最後に `.dSYM` ファイルを `$DWARF_DSYM_FOLDER_PATH` に書き出します。ビルド設定 `DEBUG_INFORMATION_FORMAT` が **DWARF with dSYM File** に設定されていることを確認してください。既定では、Xcode プロジェクトは Release プロジェクト構成でのみ `DEBUG_INFORMATION_FORMAT` を **DWARF with dSYM File** に設定します。 | + +### .dSYM ファイルをアップロードする + +`.dSYM` ファイルを Datadog にアップロードすると、エラーに関連するスタック トレース内の各フレームのファイル パスと行番号にアクセスできます。 + +アプリケーションがクラッシュし、再起動されると、iOS SDK がクラッシュ レポートを Datadog にアップロードします。 + +**注**: バージョンが変更されていない場合、ソース マップを再アップロードしても既存のものは上書きされません。 + +### Datadog CI を使用して .dSYM ファイルをアップロードする + +コマンド ライン ツール [@datadog/datadog-ci][8] を使用して、`.dSYM` ファイルをアップロードできます: + +```sh +export DATADOG_API_KEY="" + +// dSYM ファイルを含む zip ファイルがある場合 +npx @datadog/datadog-ci dsyms upload appDsyms.zip + +// dSYM ファイルを含むフォルダがある場合 +npx @datadog/datadog-ci dsyms upload /path/to/appDsyms/ +``` + +**注**: ツールを EU エンドポイントで使用するには、環境変数 `DATADOG_SITE` を `datadoghq.eu` に設定します。インテーク エンドポイントの完全な URL を上書きするには、環境変数 `DATADOG_DSYM_INTAKE_URL` を定義します。 + +あるいは、ワークフローで Fastlane または GitHub Actions を使用している場合は、`datadog-ci` の代わりに、これらの連携を活用できます: + +### Fastlane プラグインを使用して .dSYM ファイルをアップロードする + +Fastlane プラグインは、Fastlane 構成から Datadog に `.dSYM` ファイルをアップロードするのに役立ちます。 + +1. [`fastlane-plugin-datadog`][9] をプロジェクトに追加します。 + + ```sh + fastlane add_plugin datadog + ``` + +2. シンボルをアップロードするように Fastlane を構成します。 + + ```ruby + # download_dsyms action feeds dsym_paths automatically + lane :upload_dsym_with_download_dsyms do + download_dsyms + upload_symbols_to_datadog(api_key: "datadog-api-key") + end + ``` + +詳細は [`fastlane-plugin-datadog`][9] を参照してください。 + +### GitHub Actions を使用して .dSYM ファイルをアップロードする + +[Datadog Upload dSYMs GitHub Action][10] を使用すると、GitHub Actions のジョブ内でシンボルをアップロードできます: + +```yml +name: Upload dSYM Files + +jobs: + build: + runs-on: macos-latest + + steps: + - name: Checkout + uses: actions/checkout@v2 + + - name: Generate/Download dSYM Files + uses: ./release.sh + + - name: Upload dSYMs to Datadog + uses: DataDog/upload-dsyms-github-action@v1 + with: + api_key: ${{ secrets.DATADOG_API_KEY }} + site: datadoghq.com + dsym_paths: | + path/to/dsyms/folder + path/to/zip/dsyms.zip +``` + +詳細は [dSYMs コマンド][11] を参照してください。 + +## 制限事項 + +各 dSYM ファイルのサイズ上限は **2 GB** です。 + +## 実装をテストする + +iOS Crash Reporting と Error Tracking の構成を検証するには、アプリケーションでクラッシュを発生させ、Datadog にエラーが表示されることを確認します。 + +1. アプリケーションを iOS シミュレータまたは実機で実行します。デバッガがアタッチされていないことを確認します。そうしないと、 iOS SDK より前に Xcode がクラッシュを捕捉します。 +2. クラッシュを含むコードを実行します: + + ```swift + func didTapButton() { + fatalError("Crash the app") + } + ``` + +3. クラッシュ後、アプリケーションを再起動し、 iOS SDK が [**Error Tracking**][1] にクラッシュ レポートをアップロードするのを待ちます。 + +**注**: Error Tracking は、iOS v14+ の arm64 および arm64e アーキテクチャ向けのシステム シンボル ファイルのシンボリケーションをサポートします。 + + +[1]: https://app.datadoghq.com/rum/error-tracking +[2]: https://app.datadoghq.com/rum/application/create +[3]: /ja/real_user_monitoring/ios +[4]: /ja/logs/log_collection/ios +[5]: /ja/real_user_monitoring/mobile_and_tv_monitoring/ios/error_tracking/?tab=cocoapods#configure-the-app-hang-threshold +[6]: /ja/real_user_monitoring/mobile_and_tv_monitoring/ios/error_tracking/?tab=cocoapods#get-deobfuscated-stack-traces +[7]: https://appstoreconnect.apple.com/ +[8]: https://www.npmjs.com/package/@datadog/datadog-ci +[9]: https://github.com/DataDog/datadog-fastlane-plugin +[10]: https://github.com/marketplace/actions/datadog-upload-dsyms +[11]: https://github.com/DataDog/datadog-ci/blob/master/src/commands/dsyms/README.md +[12]: https://developer.apple.com/documentation/xcode/addressing-watchdog-terminations +[13]: /ja/real_user_monitoring/mobile_and_tv_monitoring/ios/error_tracking/?tab=cocoapods#add-app-hang-reporting +[14]: /ja/real_user_monitoring/mobile_and_tv_monitoring/mobile_vitals?tab=ios#telemetry +[15]: https://developer.apple.com/documentation/xcode/analyzing-responsiveness-issues-in-your-shipping-app#View-your-apps-hang-rate +[16]: https://developer.apple.com/documentation/metrickit/mxhangdiagnostic +[17]: /ja/real_user_monitoring/explorer/search/#facets +[18]: /ja/dashboards/widgets/timeseries +[19]: /ja/real_user_monitoring/mobile_and_tv_monitoring/ios/error_tracking/?tab=cocoapods#add-crash-reporting \ No newline at end of file diff --git a/content/ja/real_user_monitoring/mobile_and_tv_monitoring/react_native/troubleshooting.md b/content/ja/real_user_monitoring/mobile_and_tv_monitoring/react_native/troubleshooting.md new file mode 100644 index 0000000000000..1ba73ff0f5ffe --- /dev/null +++ b/content/ja/real_user_monitoring/mobile_and_tv_monitoring/react_native/troubleshooting.md @@ -0,0 +1,294 @@ +--- +aliases: +- /ja/real_user_monitoring/mobile_and_tv_monitoring/troubleshooting/reactnative +description: React Native Monitoring で発生する問題の対処方法を学びましょう。 +further_reading: +- link: https://github.com/DataDog/dd-sdk-reactnative + tag: ソースコード + text: dd-sdk-reactnative のソースコード +- link: /real_user_monitoring + tag: ドキュメント + text: Datadog Real User Monitoring +title: React Native SDK のトラブルシューティング +--- + +## 概要 + +Datadog React Native RUM で予期せぬ動作が発生した場合、このガイドを使用して問題を迅速に解決してください。問題が解決しない場合は、[Datadog サポート][1]にお問い合わせください。 + +## Datadog にデータが送信されていない + +SDK をインストールし、アプリをコンパイルしたが、Datadog からデータが受信されない場合、以下の手順で順番に説明します。 + +### 構成を確認する + +構成のちょっとした手違いによって、データが送信されない場合があります。 + +ここでは、よくあるチェックポイントをご紹介します。 + +- `clientToken` と `applicationId` が正しいことを確認します。 +- `sessionSamplingRate` を 100 (デフォルト値) 以外に設定していないか確認してください。それ以外の値に設定するとセッションが送信されない可能性があります。 +- Datadog の構成で `Proxy` を設定している場合、それが正しく構成されているか確認します。 +- ビューの追跡 (すべてのイベントはビューにアタッチされている必要があります) とイベントの送信を行っていることを確認してください。 + +### React Native で SDK のログを確認する + +- `config.verbosity = SdkVerbosity.DEBUG` を設定します。これは `@datadog/mobile-react-native` から `SdkVerbosity` をインポートしています。 +- 以下の出力のように、JavaScript コンソールにログが表示されるようになります。 + + ``` + INFO DATADOG: Datadog SDK was initialized + INFO DATADOG: Datadog SDK is tracking interactions + INFO DATADOG: Datadog SDK is tracking XHR resources + INFO DATADOG: Datadog SDK is tracking errors + DEBUG DATADOG: Starting RUM View "Products" #Products-oaZlP_FVwGM5vtPoup_rT + DEBUG DATADOG: Adding RUM Action "RCTView" (TAP) + ``` + + **注**: この例では、最初の 4 つのログは SDK が正しく構成されていることを示し、最後の 2 行は送信されたイベントです。 + +#### 考えられる原因 + +iOS で、ログや RUM イベントが初期化ログの**前**に送信されたことを示す DEBUG ログがある場合、これが SDK がイベントを送信しない理由かもしれません。 + +初期化前にイベントを送ることはできませんし、送ろうとすると SDK がデータを送れない状態になります。 + +#### ソリューション + +{{< tabs >}} +{{% tab "DdSdkReactNative.initialize" %}} + +Datadog SDK を起動するために `DdSdkReactNative.initialize` を使用する場合、トップレベルの `index.js` ファイルでこの関数を呼び出し、他のイベントが送信される前に SDK が初期化されるようにします。 + +{{% /tab %}} +{{% tab "DatadogProvider" %}} + +SDK バージョン `1.2.0` からは、`DatadogProvider` コンポーネントを使用して SDK を初期化することができます。このコンポーネントには RUM イベントバッファが含まれており、Datadog にデータを送信する前に SDK が初期化されていることを確認することで、この問題の発生を防ぐことができます。 + +利用するには、[Datadog Provider への移行ガイド][1]をご覧ください。 + +[1]: https://github.com/DataDog/dd-sdk-reactnative/blob/develop/docs/migrating_to_datadog_provider.md + +{{% /tab %}} +{{< /tabs >}} + +### ネイティブログを確認する + +ネイティブのログを確認することで、何が問題になっているのか、より多くの情報を得ることができます。 + +#### iOS の場合 + +- Xcode で `xed ios` を実行し、プロジェクトを開きます。 +- シミュレーターやデバイス向けにプロジェクトを構築します。 +- 右下にネイティブログが表示され始めます。 + + {{< img src="real_user_monitoring/react_native/troubleshooting-xcode-logs.png" alt="ネイティブログを確認することで、データが送信されない原因を突き止めることができます" >}} + +"DATADOG" でログをフィルターして、任意のエラーを探すことができます。 + +確かにイベントを送信していれば、以下のようなログが表示されるはずです。 + +``` +[DATADOG SDK] 🐶 → 10:02:47.398 [DEBUG] ⏳ (rum) Uploading batch... +[DATADOG SDK] 🐶 → 10:02:47.538 [DEBUG] → (rum) accepted, won't be retransmitted: [response code: 202 (accepted), request ID: AAAABBBB-1111-2222-3333-777788883333] +``` + +第 1 ログは、何らかのデータを送信中であることを示し、第 2 ログは、データを受信したことを示します。 + +##### 考えられる原因 + +以下のようなログが表示された場合、SDK を初期化する前に RUM メソッドを呼び出したことを意味します。 + +``` +[DATADOG SDK] 🐶 → 10:09:13.621 [WARN] The `Global.rum` was called but no `RUMMonitor` is registered. Configure and register the RUM Monitor globally before invoking the feature: +``` + +##### ソリューション + +{{< tabs >}} +{{% tab "DdSdkReactNative.initialize" %}} + +Datadog SDK を起動するために `DdSdkReactNative.initialize` を使用する場合、トップレベルの `index.js` ファイルでこの関数を呼び出し、他のイベントが送信される前に SDK が初期化されるようにします。 + +{{% /tab %}} +{{% tab "DatadogProvider" %}} + +SDK バージョン `1.2.0` からは、`DatadogProvider` コンポーネントを使用して SDK を初期化することができます。このコンポーネントには RUM イベントバッファが含まれており、Datadog にデータを送信する前に SDK が初期化されていることを確認することで、この問題の発生を防ぐことができます。 + +利用するには、[Datadog Provider への移行ガイド][1]をご覧ください。 + + +[1]: https://github.com/DataDog/dd-sdk-reactnative/blob/develop/docs/migrating_to_datadog_provider.md + +{{% /tab %}} +{{< /tabs >}} + +#### Android の場合 + +- より快適にデバッグするために、Datadog では [pidcat][2] のインストールを推奨しています。 + - pidcat は、デバイスログ (`adb logcat` で取得) をフィルターして、アプリケーションからのものだけを表示します。 + - Python 2 を持っていない M1 ユーザーは [この Issue][3] をご参照ください。 +- ネイティブ SDK から冗長ログを有効にするため、`node_modules/@datadog/mobile-react-native/android/src/main/kotlin/com/datadog/reactnative/DdSdk.kt` を修正します。 + + ```java + fun initialize(configuration: ReadableMap, promise: Promise) { + // ... + + datadog.initialize(appContext, credentials, nativeConfiguration, trackingConsent) + datadog.setVerbosity(Log.VERBOSE) // Add this line + + // ... + } + ``` + +- ラップトップにデバッグモードで接続されたスマートフォン (`adb devices` を実行すると表示されるはずです)、またはエミュレーターからアプリを実行してください。 +- ラップトップから pidcat `my.app.package.name` または `adb logcat` を実行します。 +- Datadog に言及したエラーがないか確認します。 + +Pidcat の出力は次のようになります。 + +{{< img src="real_user_monitoring/react_native/troubleshooting-pidcat-logs.png" alt="これは、pidcat の出力例です" >}} + +この例では、最後のログは、RUM データのバッチが正常に送信されたことを示します。 + +## 未定義のシンボル: Swift + +以下のエラーメッセージが表示された場合 + +``` +Undefined symbols for architecture x86_64: + "static Foundation.JSONEncoder.OutputFormatting.withoutEscapingSlashes.getter : Foundation.JSONEncoder.OutputFormatting", referenced from: + static (extension in Datadog):Foundation.JSONEncoder.default() -> Foundation.JSONEncoder in libDatadogSDK.a(JSONEncoder.o) +... +``` + +Xcode を開き、プロジェクト (アプリのターゲットではない) の `Build Settings` を開き、Library Search Paths が以下の設定になっていることを確認してください。 + +```shell +LIBRARY_SEARCH_PATHS = ( + "\"$(TOOLCHAIN_DIR)/usr/lib/swift/$(PLATFORM_NAME)\"", + "\"/usr/lib/swift\"", + "\"$(inherited)\"", +); +``` + +## 未定義のシンボル: _RCTModule + +_RCTModule が未定義である旨のエラーが表示される場合は、[react-native v0.63 のチェンジログ][4]にある変更が原因かもしれません。 + +以下のように変更することで解決します。 + +```objectivec +// DdSdk.m +// 以下の代わりに +#import +// おそらく: +@import React // または @import React-Core +``` + +## 無限ループのようなエラーメッセージ + +[React Native プロジェクトがエラーメッセージを次々と表示し、CPU 使用率が著しく上昇する問題][5]に遭遇した場合は、React Native プロジェクトを新規に作成してみてください。 + +## SDK バージョン 2.* での Android ビルドエラー + +### Unable to make field private final java.lang.String java.io.File.path accessible + +もし Android ビルドが以下のようなエラーで失敗する場合: + +``` +FAILURE: Build failed with an exception. + +* What went wrong: +Execution failed for task ':app:processReleaseMainManifest'. +> Unable to make field private final java.lang.String java.io.File.path accessible: module java.base does not "opens java.io" to unnamed module @1bbf7f0e +``` + +現在使用している Java 17 は、お使いの React Native バージョンと互換性がありません。Java 11 に切り替えると問題を解決できます。 + +### java.lang.UnsupportedClassVersionError + +もし Android ビルドが以下のようなエラーで失敗する場合: + +``` +java.lang.UnsupportedClassVersionError: com/datadog/android/lint/DatadogIssueRegistry has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0 +``` + +Java のバージョンが古すぎます。Java 17 に切り替えてください。 + +### Unsupported class file major version 61 + +もし Android ビルドが以下のようなエラーで失敗する場合: + +``` +FAILURE: Build failed with an exception. + +* What went wrong: +Could not determine the dependencies of task ':app:lintVitalRelease'. +> Could not resolve all artifacts for configuration ':app:debugRuntimeClasspath'. + > Failed to transform dd-sdk-android-core-2.0.0.aar (com.datadoghq:dd-sdk-android-core:2.0.0) to match attributes {artifactType=android-manifest, org.gradle.category=library, org.gradle.dependency.bundling=external, org.gradle.libraryelements=aar, org.gradle.status=release, org.gradle.usage=java-runtime}. + > Execution failed for JetifyTransform: /Users/me/.gradle/caches/modules-2/files-2.1/com.datadoghq/dd-sdk-android-core/2.0.0/a97f8a1537da1de99a86adf32c307198b477971f/dd-sdk-android-core-2.0.0.aar. + > Failed to transform '/Users/me/.gradle/caches/modules-2/files-2.1/com.datadoghq/dd-sdk-android-core/2.0.0/a97f8a1537da1de99a86adf32c307198b477971f/dd-sdk-android-core-2.0.0.aar' using Jetifier. Reason: IllegalArgumentException, message: Unsupported class file major version 61. (Run with --stacktrace for more details.) +``` + +Android Gradle Plugin のバージョンが `5.0` 未満です。問題を修正するには、`android/gradle.properties` ファイルに以下を追加してください: + +```properties +android.jetifier.ignorelist=dd-sdk-android-core +``` + +### Duplicate class kotlin.collections.jdk8.* + +もし Android ビルドが以下のようなエラーで失敗する場合: + +``` +FAILURE: Build failed with an exception. + +* What went wrong: +Execution failed for task ':app:checkReleaseDuplicateClasses'. +> A failure occurred while executing com.android.build.gradle.internal.tasks.CheckDuplicatesRunnable + > Duplicate class kotlin.collections.jdk8.CollectionsJDK8Kt found in modules jetified-kotlin-stdlib-1.8.10 (org.jetbrains.kotlin:kotlin-stdlib:1.8.10) and jetified-kotlin-stdlib-jdk8-1.7.20 (org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.20) + Duplicate class kotlin.internal.jdk7.JDK7PlatformImplementations found in modules jetified-kotlin-stdlib-1.8.10 (org.jetbrains.kotlin:kotlin-stdlib:1.8.10) and jetified-kotlin-stdlib-jdk7-1.7.20 (org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.7.20) +``` + +Kotlin の依存関係が競合しないよう、プロジェクトで使用する Kotlin バージョンを指定する必要があります。`android/build.gradle` ファイルで `kotlinVersion` を指定してください: + +```groovy +buildscript { + ext { + // targetSdkVersion = ... + kotlinVersion = "1.8.21" + } +} +``` + +あるいは、`android/app/build.gradle` ファイルのビルドスクリプトに以下のルールを追加できます: + +```groovy +dependencies { + constraints { + implementation("org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.8.21") { + because("kotlin-stdlib-jdk7 is now a part of kotlin-stdlib") + } + implementation("org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.8.21") { + because("kotlin-stdlib-jdk8 is now a part of kotlin-stdlib") + } + } +} +``` + +## "Deobfuscation failed" warning + +スタックトレースのデオブフスケーションに失敗したときに警告が表示されることがあります。スタックトレースがもともと難読化されていない場合は、この警告は無視してかまいません。そうでない場合は、[RUM Debug Symbols ページ][6]でアップロードしたソースマップや dSYM、mapping ファイルを確認してください。[RUM Debug Symbols を用いた難読化スタックトレースの調査][7]も併せてご覧ください。 + +## その他の参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ja/help +[2]: https://github.com/JakeWharton/pidcat +[3]: https://github.com/JakeWharton/pidcat/issues/180#issuecomment-1124019329 +[4]: https://github.com/facebook/react-native/commit/6e08f84719c47985e80123c72686d7a1c89b72ed +[5]: https://github.com/facebook/react-native/issues/28801 +[6]: https://app.datadoghq.com/source-code/setup/rum +[7]: /ja/real_user_monitoring/guide/debug-symbols \ No newline at end of file diff --git a/content/ja/real_user_monitoring/mobile_and_tv_monitoring/setup/ios.md b/content/ja/real_user_monitoring/mobile_and_tv_monitoring/setup/ios.md new file mode 100644 index 0000000000000..ef47a0f0bc67f --- /dev/null +++ b/content/ja/real_user_monitoring/mobile_and_tv_monitoring/setup/ios.md @@ -0,0 +1,530 @@ +--- +aliases: +- /ja/real_user_monitoring/ios +- /ja/real_user_monitoring/ios/getting_started +- /ja/real_user_monitoring/ios/swiftui/ +- /ja/real_user_monitoring/swiftui/ +- /ja/real_user_monitoring/mobile_and_tv_monitoring/swiftui/ +beta: true +code_lang: ios +code_lang_weight: 20 +description: iOS と tvOS アプリケーションから RUM または Error Tracking のデータを収集します。 +further_reading: +- link: /real_user_monitoring/mobile_and_tv_monitoring/advanced_configuration/ios + tag: ドキュメント + text: RUM iOS の高度なコンフィギュレーション +- link: https://github.com/DataDog/dd-sdk-ios + tag: ソースコード + text: dd-sdk-ios のソースコード +- link: /real_user_monitoring + tag: ドキュメント + text: RUM データの調査方法 +- link: /real_user_monitoring/error_tracking/ios/ + tag: ドキュメント + text: iOS のエラーの追跡方法について +- link: /real_user_monitoring/ios/swiftui/ + tag: ドキュメント + text: SwiftUI アプリケーションのインスツルメンテーションについて +- link: /real_user_monitoring/mobile_and_tv_monitoring/supported_versions/ios/ + tag: ドキュメント + text: RUM iOS および tvOS のモニタリングのサポート対象バージョン +title: iOS と tvOS のモニタリング セットアップ +type: multi-code-lang +--- + +## 概要 + +このページでは、iOS SDK を使用して、[リアル ユーザー モニタリング (RUM)][1] と [Error Tracking][2] の両方に向けてアプリケーションをインスツルメント化する方法を説明します。RUM (Error Tracking を含む) または単体製品として Error Tracking を購入している場合は、以下の手順に従ってアプリケーションをインスツルメント化できます。 + +## セットアップ + +1. SDK を依存関係として宣言します。 +2. UI でアプリケーションの詳細を指定します。 +3. ライブラリを初期化します。 +4. データの送信を開始するには、Datadog Monitor を初期化し、`URLSessionInstrumentation` を有効にします。 + +### SDK を依存関係として宣言 + +Declare the library as a dependency depending on your package manager. Swift Package Manager (SPM) is recommended. + +{{< tabs >}} +{{% tab "Swift Package Manager (SPM)" %}} + +Apple の Swift Package Manager を使用して統合するには、`Package.swift` に以下を依存関係として追加します。 +```swift +.package(url: "https://github.com/Datadog/dd-sdk-ios.git", .upToNextMajor(from: "2.0.0")) +``` + +プロジェクトで、以下のライブラリをリンクします。 +``` +DatadogCore +DatadogRUM +``` + +{{% /tab %}} +{{% tab "CocoaPods" %}} + +[CocoaPods][1] を使用して、`dd-sdk-ios` をインストールできます。 +``` +pod 'DatadogCore' +pod 'DatadogRUM' +``` + + +[1]: https://cocoapods.org/ +{{% /tab %}} +{{% tab "Carthage" %}} + +[Carthage][1] を使用して、`dd-sdk-ios` をインストールできます。 +``` +github "DataDog/dd-sdk-ios" +``` + +Xcode で、以下のフレームワークをリンクします。 +``` +DatadogInternal.xcframework +DatadogCore.xcframework +DatadogRUM.xcframework +``` + +[1]: https://github.com/Carthage/Carthage +{{% /tab %}} +{{< /tabs >}} + +### UI でアプリケーションの詳細を指定 + +{{< tabs >}} +{{% tab "RUM" %}} + +1. [**Digital Experience** > **Add an Application**][1] に移動します。 +2. アプリケーションタイプとして `iOS` を選択し、新しいアプリケーション名を入力して一意の Datadog アプリケーション ID とクライアントトークンを生成します。 +3. Web ビューをインスツルメントするには、**Instrument your webviews** トグルをクリックします。詳しくは、[Web ビュー追跡][2]を参照してください。 +4. クライアント IP やジオロケーション データに関する自動ユーザー データ収集を無効にするには、該当する設定のトグルを使用します。詳細は [RUM iOS で収集されるデータ][3] を参照してください。 + + {{< img src="real_user_monitoring/ios/ios-create-application.png" alt="Datadog で iOS 用 RUM アプリケーションを作成する" style="width:100%;border:none" >}} + +[1]: https://app.datadoghq.com/rum/application/create +[2]: /ja/real_user_monitoring/ios/web_view_tracking/ +[3]: /ja/real_user_monitoring/ios/data_collected/ + +{{% /tab %}} +{{% tab "Error Tracking" %}} + +1. [**Error Tracking** > **Settings** > **Browser and Mobile** > **Add an Application**][1] に移動します。 +2. アプリケーションタイプとして `iOS` を選択し、新しいアプリケーション名を入力して一意の Datadog アプリケーション ID とクライアントトークンを生成します。 +3. Web ビューをインスツルメントするには、**Instrument your webviews** トグルをクリックします。詳しくは、[Web ビュー追跡][2]を参照してください。 +4. クライアント IP やジオロケーション データに関する自動ユーザー データ収集を無効にするには、該当する設定のトグルを使用します。詳細は [iOS で収集されるデータ][3] を参照してください。 + + {{< img src="real_user_monitoring/error_tracking/mobile-new-application.png" alt="Datadog で iOS 用アプリケーションを作成" style="width:90%;">}} + +[1]: https://app.datadoghq.com/error-tracking/settings/setup/client +[2]: /ja/real_user_monitoring/ios/web_view_tracking/ +[3]: /ja/real_user_monitoring/ios/data_collected/ + +{{% /tab %}} +{{< /tabs >}} + +データの安全性を確保するために、クライアント トークンを必ず使用してください。`dd-sdk-ios` ライブラリの構成に [Datadog API キー][3] のみを使用した場合、iOS アプリケーションのバイト コード内でクライアント サイドに露出します。 + +クライアント トークンの設定についての詳細は、[クライアント トークンのドキュメント][4] を参照してください。 + +### ライブラリの初期化 + +初期化スニペットでは、環境名、サービス名、バージョン番号を設定します。以下の例では、`app-name` はデータを生成するアプリケーションのバリアントを指定します。 + +詳細は [タグの使用][5] を参照してください。 + +{{< site-region region="us" >}} +{{< tabs >}} +{{% tab "Swift" %}} + +```swift +import DatadogCore + +Datadog.initialize( + with: Datadog.Configuration( + clientToken: "", + env: "", + service: "" + ), + trackingConsent: trackingConsent +) +``` +{{% /tab %}} +{{% tab "Objective-C" %}} +```objective-c +@import DatadogObjc; + +DDConfiguration *configuration = [[DDConfiguration alloc] initWithClientToken:@"" env:@""]; +configuration.service = @""; + +[DDDatadog initializeWithConfiguration:configuration + trackingConsent:trackingConsent]; +``` +{{% /tab %}} +{{< /tabs >}} +{{< /site-region >}} + +{{< site-region region="eu" >}} +{{< tabs >}} +{{% tab "Swift" %}} +```swift +import DatadogCore + +Datadog.initialize( + with: Datadog.Configuration( + clientToken: "", + env: "", + site: .eu1, + service: "" + ), + trackingConsent: trackingConsent +) +``` +{{% /tab %}} +{{% tab "Objective-C" %}} +```objective-c +@import DatadogObjc; + +DDConfiguration *configuration = [[DDConfiguration alloc] initWithClientToken:@"" env:@""]; +configuration.service = @""; +configuration.site = [DDSite eu1]; + +[DDDatadog initializeWithConfiguration:configuration + trackingConsent:trackingConsent]; +``` +{{% /tab %}} +{{< /tabs >}} +{{< /site-region >}} + +{{< site-region region="us3" >}} +{{< tabs >}} +{{% tab "Swift" %}} +```swift +import DatadogCore + +Datadog.initialize( + with: Datadog.Configuration( + clientToken: "", + env: "", + site: .us3, + service: "" + ), + trackingConsent: trackingConsent +) +``` +{{% /tab %}} +{{% tab "Objective-C" %}} +```objective-c +@import DatadogObjc; + +DDConfiguration *configuration = [[DDConfiguration alloc] initWithClientToken:@"" env:@""]; +configuration.service = @""; +configuration.site = [DDSite us3]; + +[DDDatadog initializeWithConfiguration:configuration + trackingConsent:trackingConsent]; +``` +{{% /tab %}} +{{< /tabs >}} +{{< /site-region >}} + +{{< site-region region="us5" >}} +{{< tabs >}} +{{% tab "Swift" %}} +```swift +import DatadogCore + +Datadog.initialize( + with: Datadog.Configuration( + clientToken: "", + env: "", + site: .us5, + service: "" + ), + trackingConsent: trackingConsent +) +``` +{{% /tab %}} +{{% tab "Objective-C" %}} +```objective-c +@import DatadogObjc; + +DDConfiguration *configuration = [[DDConfiguration alloc] initWithClientToken:@"" env:@""]; +configuration.service = @""; +configuration.site = [DDSite us5]; + +[DDDatadog initializeWithConfiguration:configuration + trackingConsent:trackingConsent]; +``` +{{% /tab %}} +{{< /tabs >}} +{{< /site-region >}} + +{{< site-region region="gov" >}} +{{< tabs >}} +{{% tab "Swift" %}} +```swift +import DatadogCore + +Datadog.initialize( + with: Datadog.Configuration( + clientToken: "", + env: "", + site: .us1_fed, + service: "" + ), + trackingConsent: trackingConsent +) +``` +{{% /tab %}} +{{% tab "Objective-C" %}} +```objective-c +@import DatadogObjc; + +DDConfiguration *configuration = [[DDConfiguration alloc] initWithClientToken:@"" env:@""]; +configuration.service = @""; +configuration.site = [DDSite us1_fed]; + +[DDDatadog initializeWithConfiguration:configuration + trackingConsent:trackingConsent]; +``` +{{% /tab %}} +{{< /tabs >}} +{{< /site-region >}} + +{{< site-region region="ap1" >}} +{{< tabs >}} +{{% tab "Swift" %}} +```swift +import DatadogCore + +Datadog.initialize( + with: Datadog.Configuration( + clientToken: "", + env: "", + site: .ap1, + service: "" + ), + trackingConsent: trackingConsent +) +``` +{{% /tab %}} +{{% tab "Objective-C" %}} +```objective-c +@import DatadogObjc; + +DDConfiguration *configuration = [[DDConfiguration alloc] initWithClientToken:@"" env:@""]; +configuration.service = @""; +configuration.site = [DDSite ap1]; + +[DDDatadog initializeWithConfiguration:configuration + trackingConsent:trackingConsent]; +``` +{{% /tab %}} +{{< /tabs >}} +{{< /site-region >}} + +iOS SDK は、SDK の初期化時に指定したオプションに応じてユーザー セッションを自動的にトラッキングします。EU ユーザー向けの GDPR 準拠やその他の [初期化パラメーター][6] を SDK 構成に追加するには、[トラッキング同意の設定に関するドキュメント](#set-tracking-consent-gdpr-compliance) を参照してください。 + +### RUM セッションのサンプリング + +
セッションのサンプルレートの設定はError Tracking には適用されません。
+ +アプリケーションが Datadog RUM に送信するデータを制御するには、[RUM iOS SDK の初期化][7] 時に RUM セッションのサンプリング レートを指定できます。レートは 0 から 100 の間のパーセンテージです。既定では、`sessionSamplingRate` は 100 (すべてのセッションを保持) に設定されています。 + +たとえば、セッションの使用の 50% のみを維持するには、 + +{{< tabs >}} +{{% tab "Swift" %}} +```swift +let configuration = RUM.Configuration( + applicationID: "", + sessionSampleRate: 50 +) +``` +{{% /tab %}} +{{% tab "Objective-C" %}} +```objective-c +DDRUMConfiguration *configuration = [[DDRUMConfiguration alloc] initWithApplicationID:@""]; +configuration.sessionSampleRate = 50; +``` +{{% /tab %}} +{{< /tabs >}} + +### トラッキングの同意を設定 (GDPR の遵守) + +GDPR 規制を遵守するため、RUM iOS SDK は初期化時に追跡に関する同意を求めます。 + +`trackingConsent` 設定は以下のいずれかの値で示されます。 + +1. `.pending`: RUM iOS SDK はデータの収集とバッチ処理を開始しますが、Datadog へは送信しません。RUM iOS SDK はバッチ処理が完了したデータをどうするかについての新たな同意値が得られるまで待機します。 +2. `.granted`: RUM iOS SDK はデータの収集を開始し、Datadog へ送信します。 +3. `.notGranted`: RUM iOS SDK は一切のデータを収集しません。Datadog にはログ、トレース、イベントは送信されません。 + +RUM iOS SDK の初期化後に追跡同意値を変更するには、`Datadog.set(trackingConsent:)` API 呼び出しを使用します。RUM iOS SDK は、新しい値に応じて動作を変更します。 + +たとえば、現在の追跡同意が `.pending` の場合: + +- 値を `.granted` に変更すると、RUM iOS SDK は現在および今後のすべてのデータを Datadog に送信します。 +- 値を `.notGranted` に変更すると、RUM iOS SDK は現在のすべてのデータを消去し、今後のデータを収集しません。 + +### Datadog Monitor を初期化し、`URLSessionInstrumentation` を有効にする + +Datadog Monitor を構成して登録します。これは 1 回だけ、通常は `AppDelegate` のコード内で実行します: + +{{< tabs >}} +{{% tab "Swift" %}} + +```swift +import DatadogRUM + +RUM.enable( + with: RUM.Configuration( + applicationID: "", + uiKitViewsPredicate: DefaultUIKitRUMViewsPredicate(), + uiKitActionsPredicate: DefaultUIKitRUMActionsPredicate(), + urlSessionTracking: RUM.Configuration.URLSessionTracking() + ) +) +``` +{{% /tab %}} +{{% tab "Objective-C" %}} +```objective-c +@import DatadogObjc; + +DDRUMConfiguration *configuration = [[DDRUMConfiguration alloc] initWithApplicationID:@""]; +configuration.uiKitViewsPredicate = [DDDefaultUIKitRUMViewsPredicate new]; +configuration.uiKitActionsPredicate = [DDDefaultUIKitRUMActionsPredicate new]; +[configuration setURLSessionTracking:[DDRUMURLSessionTracking new]]; + +[DDRUM enableWith:configuration]; +``` +{{% /tab %}} +{{% /tabs %}} + +`URLSession` インスタンスから送信されるリクエストをリソースとして監視するには、デリゲート タイプに対して `URLSessionInstrumentation` を有効にし、`URLSession` にデリゲート インスタンスを渡します: + +{{< tabs >}} +{{% tab "Swift" %}} +```swift +URLSessionInstrumentation.enable( + with: .init( + delegateClass: .self + ) +) + +let session = URLSession( + configuration: .default, + delegate: (), + delegateQueue: nil +) +``` +{{% /tab %}} +{{% tab "Objective-C" %}} +```objective-c +DDURLSessionInstrumentationConfiguration *config = [[DDURLSessionInstrumentationConfiguration alloc] initWithDelegateClass:[ class]]; +[DDURLSessionInstrumentation enableWithConfiguration:config]; + +NSURLSession *session = [NSURLSession sessionWithConfiguration:[NSURLSessionConfiguration defaultSessionConfiguration] + delegate:[[ alloc] init] + delegateQueue:nil]; +``` +{{% /tab %}} +{{< /tabs >}} + + +### ビューをインスツルメントする + +Datadog iOS SDK は、`SwiftUI` アプリケーションのビューをインスツルメント化できます。このインスツルメント化は、`UIKit` と `SwiftUI` のハイブリッド アプリケーションでも機能します。 + +`SwiftUI.View` をインスツルメントするためには、以下のメソッドをビュー宣言に追加します。 + +```swift +import SwiftUI +import DatadogRUM + +struct FooView: View { + + var body: some View { + FooContent { + ... + } + .trackRUMView(name: "Foo") + } +} +``` + +`trackRUMView(name:)` メソッドは、`SwiftUI` のビューが画面に表示される時と消える時にビューを開始および停止します。 + +### タップアクションをインスツルメントする + +Datadog iOS SDK は、`SwiftUI` アプリケーションのタップ アクションをインスツルメント化できます。このインスツルメント化は、`UIKit` と `SwiftUI` のハイブリッド アプリケーションでも機能します。 + +`SwiftUI.View` のタップアクションをインスツルメントするためには、以下のメソッドをビュー宣言に追加します。 + +```swift +import SwiftUI +import DatadogRUM + +struct BarView: View { + + var body: some View { + Button("BarButton") { { + ... + } + .trackRUMTapAction(name: "Bar") + } +} +``` + +## バックグラウンドイベントの追跡 + +

バックグラウンドイベントを追跡すると、セッションが追加され、課金に影響を与える可能性があります。ご質問は、Datadog サポートまでお問い合わせください。

+
+ +アプリケーションがバックグラウンドにあるとき (例えば、アクティブなビューがないとき)、クラッシュやネットワークリクエストなどのイベントを追跡することができます。 + +Datadog の構成で、初期化時に以下のスニペットを追加します。 + +```swift +import DatadogRUM + +RUM.enable( + with: RUM.Configuration( + ... + trackBackgroundEvents: true + ) +) +``` + +## iOS エラーの追跡 + +[iOS Crash Reporting と Error Tracking][7] は、アプリケーション内のあらゆる問題と最新のエラーを表示します。エラーの詳細や JSON を含む属性は [RUM Explorer][9] で表示できます。 + +## デバイスがオフラインの時のデータ送信 + +iOS SDK は、ユーザー デバイスがオフラインのときでもデータの可用性を確保します。ネットワークが弱いエリアやデバイスのバッテリーが少ない場合、すべてのイベントはまずローカル デバイスにバッチで保存されます。ネットワークが利用可能になり、かつ iOS SDK がエンド ユーザーの体験に影響を与えないよう十分なバッテリー レベルになったら、すぐに送信されます。アプリケーションがフォアグラウンドにある間にネットワークが利用できない場合や、データのアップロードが失敗した場合は、そのバッチは送信に成功するまで保持されます。 + +つまり、ユーザーがオフラインでアプリケーションを開いても、データが失われることはありません。 + +**注**: iOS SDK が過剰なディスク容量を使用しないよう、ディスク上のデータは古くなりすぎた場合に自動的に破棄されます。 + +## サポートされるバージョン + +iOS SDK と互換性のある OS バージョンおよびプラットフォームの一覧は、[サポート対象バージョン][10] を参照してください。 + +## その他の参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ja/real_user_monitoring/ +[2]: /ja/error_tracking/ +[3]: /ja/account_management/api-app-keys/#api-keys +[4]: /ja/account_management/api-app-keys/#client-tokens +[5]: /ja/getting_started/tagging/using_tags/#rum--session-replay +[6]: /ja/real_user_monitoring/ios/advanced_configuration/#initialization-parameters +[7]: https://github.com/DataDog/dd-sdk-ios +[8]: /ja/real_user_monitoring/error_tracking/ios/ +[9]: /ja/real_user_monitoring/explorer/ +[10]: /ja/real_user_monitoring/mobile_and_tv_monitoring/supported_versions/ios/ \ No newline at end of file diff --git a/content/ja/security/application_security/threats/setup/compatibility/dotnet.md b/content/ja/security/application_security/threats/setup/compatibility/dotnet.md new file mode 100644 index 0000000000000..c2e8d35c562dd --- /dev/null +++ b/content/ja/security/application_security/threats/setup/compatibility/dotnet.md @@ -0,0 +1,110 @@ +--- +code_lang: dotnet +code_lang_weight: 10 +title: .NET 互換性要件 +type: multi-code-lang +--- + +## App and API Protection 機能サポート + +指定されたトレーサーバージョンに対して、.NET ライブラリでサポートされる App and API Protection 機能は以下のとおりです: + +| App and API Protection 機能 | .NET トレーサーの最小バージョン | +| -------------------------------- | ----------------------------| +| Threat Detection | 2.23.0| +| Threat Protection | 2.26.0| +| ブロックされたリクエストへの対応をカスタマイズする | 2.27.0 | +| Software Composition Analysis (SCA) | 2.16.0 | +| コードセキュリティ | 2.42.0 | +| ユーザーアクティビティイベントの自動追跡 | 2.32.0 | +| API セキュリティ | 2.42.0 | + +.NET でサポートされるすべての App and API Protection 機能を利用するための最小トレーサーバージョンは 2.42.0 です。 + +**注**: Threat Protection を利用するには [Remote Configuration][3] を有効にする必要があります。Remote Configuration は上記の最小トレーサーバージョンに含まれています。 + +### サポートされるデプロイメントタイプ +| タイプ | Threat Detection のサポート | Software Composition Analysis | +|-------------------|--------------------------|------------------------------------------| +| Docker | {{< X >}} | {{< X >}} | +| Kubernetes | {{< X >}} | {{< X >}} | +| Amazon ECS | {{< X >}} | {{< X >}} | +| AWS Fargate | {{< X >}} | {{< X >}} | +| AWS Lambda | {{< X >}} | | +| Azure App Service | {{< X >}} | {{< X >}} | + +**注**: Azure App Service は **Web アプリケーションのみ**サポートされます。Azure Functions は App and API Protection 機能のサポート対象外です。 + +## 言語とフレームワークの互換性 + +### サポートされている .NET バージョン + +| .NET Framework バージョン | マイクロソフトサポート終了 | サポートレベル | パッケージバージョン | +| ----------------------- | --------------------- | ----------------------------------- | --------------------------- | +| 4.8 | | GA | 最新 | +| 4.7.2 | | GA | 最新 | +| 4.7 | | GA | 最新 | +| 4.6.2 | | GA | 最新 | +| 4.6.1 | 04/26/2022 | GA | 最新 | + + +これらは、以下のアーキテクチャでサポートされています。 +- Linux (GNU) x86-64、ARM64 +- Alpine Linux (musl) x86-64、ARM64 +- macOS (Darwin) x86-64、ARM64 +- Windows (msvc) x86、x86-64 + + + +### Web フレームワークの互換性 + +- 攻撃元の HTTP リクエストの詳細 +- HTTP リクエスト用のタグ (ステータスコード、メソッドなど) +- アプリケーション内の攻撃フローを確認するための分散型トレーシング + +##### App and API Protection 機能に関する注意事項 +- **Software Composition Analysis** はすべてのフレームワークでサポートされます。 +- リストにないフレームワークの場合、**Code Security** では Insecure Cookie (不適切な Cookie 設定) の検出が継続されます。 + + +| フレームワーク | Threat Detection のサポートの有無 | Threat Protection のサポートの有無 | Code Security? | +| ----------------------- | --------------- | ---------------------------------------------- | ---------------------------------------------- | +| ASP.NET MVC | {{< X >}} |{{< X >}} | {{< X >}} | +| ASP.NET Web API 2 | {{< X >}} | {{< X >}} | {{< X >}} | + +
ご希望のフレームワークが掲載されていない場合は、お知らせください！この短いフォームに必要事項を記入して、詳細を送信してください。
+ +### データストアの互換性 + +**データストアのトレーシングでは以下の確認が可能です** + +- SQL 攻撃の検知 +- クエリ情報 (サニタイジングされたクエリ文字列など) +- エラーとスタックトレースの取得 + +##### App and API Protection 機能に関する注意事項 +- **Threat Protection** は HTTP リクエスト (input) レイヤーでも機能するため、下表に掲載されていなくても、デフォルトですべてのデータベースで機能します。 + +| フレームワーク | Threat Detection のサポートの有無 | Threat Protection のサポートの有無 | Code Security? | +|-------------------|-----------------|---------------------|---| +| OracleDB | {{< X >}} | {{< X >}} |{{< X >}} | +| ADO.NET | {{< X >}} | {{< X >}} |{{< X >}} | +| SQL Server | {{< X >}} | {{< X >}} |{{< X >}} | +| MySQL | {{< X >}} | {{< X >}} |{{< X >}} | +| SQLite | {{< X >}} | {{< X >}} |{{< X >}} | + +### User Authentication Frameworks の互換性 + +**User Authentication Frameworks へのインテグレーションは以下を提供します。** + +- ユーザー ID を含むユーザーログインイベント +- ユーザーサインアップイベント (組み込みの SignInManager を使用するアプリ) +- ユーザーログインイベントのアカウント乗っ取り検出モニタリング + +| フレームワーク | +|-------------------| +| > .Net Core 2.1 | + +[1]: /ja/tracing/trace_collection/compatibility/dotnet-core/ +[2]: /ja/tracing/trace_collection/compatibility/dotnet-framework/ +[3]: /ja/agent/remote_config/#enabling-remote-configuration \ No newline at end of file diff --git a/content/ja/security/cloud_siem/security_operational_metrics.md b/content/ja/security/cloud_siem/security_operational_metrics.md new file mode 100644 index 0000000000000..12a82e8c0d0d1 --- /dev/null +++ b/content/ja/security/cloud_siem/security_operational_metrics.md @@ -0,0 +1,72 @@ +--- +disable_toc: false +further_reading: +- link: security/cloud_siem/investigate_security_signals + tag: ドキュメント + text: Cloud SIEM Security Signals の調査 +- link: getting_started/dashboards + tag: ドキュメント + text: ダッシュボードの使用開始 +- link: getting_started/monitors + tag: ドキュメント + text: モニターの使用開始 +- link: metrics/summary/ + tag: ドキュメント + text: Metrics Summary について詳しく知る +title: セキュリティ オペレーショナル メトリクス +--- + +## 概要 + +Cloud SIEM は、クラウド環境に対するセキュリティ脅威への対応および解決におけるチームの有効性を判断するためのセキュリティ オペレーショナル メトリクスを提供します。これらのメトリクスは、デフォルトの [Cloud SIEM ダッシュボード][1] に表示され、Cloud SIEM の [週次ダイジェスト レポート][2] でも送信されます。また、これらのメトリクス用のダッシュボードやモニターを作成することもできます。 + +{{< img src="security/security_monitoring/secops_metrics.png" alt="Cloud SIEM Overview ダッシュボードの セキュリティ オペレーショナル メトリクス セクション" style="width:100%;" >}} + +## オペレーショナル メトリクス + +``datadog.security.siem_signal.time_to_detect`` +: **名前**: Time to Detect (TTD) +: **説明**: 一致するログがトリガーされてからシグナルが生成されるまでの時間 (秒)。 +: **メトリクス タイプ**: [DISTRIBUTION][3] + +``datadog.security.siem_signal.time_to_acknowledge`` +: **名前**: Time to Acknowledge (TTA) +: **説明**: シグナルがトリガーされてからそのシグナルの調査が開始されるまでの時間 (秒)。 +: **メトリクス タイプ**: [DISTRIBUTION][3] + +``datadog.security.siem_signal.time_to_resolve`` +: **名前**: Time to Resolve (TTR) +: **説明**: 検知の通知を受けてからシグナルをクローズするまでに要した時間 (秒)。 +: **メトリクス タイプ**: [DISTRIBUTION][3] + +## メトリクスの計算方法 + +TTD、TTA、TTR の各メトリクスは、以下のタイムスタンプに基づいて計算されます。 + +1. セキュリティ シグナルをトリガーするログのタイムスタンプ (`T0`) +1. シグナルが生成されたタイムスタンプ (`T1`) +1. シグナル ステータスが `under_review` に変更されたタイムスタンプ (`T2`) +1. シグナル ステータスが `archived` に変更されたタイムスタンプ (`T3`) + +| メトリクス | 計算方法 | +| ------------------------------------------------------------------------------------- | ---------------------------- | +| Time to Detect (TTD)
``datadog.security.siem_signal.time_to_detect`` | `T1 - T0` | +| Time to Acknowledge (TTA)
``datadog.security.siem_signal.time_to_acknowledge`` | `T2 - T1` | +| Time to Resolve (TTR)
``datadog.security.siem_signal.time_to_resolve`` | `T3 - T1` | + +## メトリクスの探索、可視化、モニタリング + +[Metrics Summary][3] を使用して、オペレーショナル メトリクスのメタデータやタグを確認できます。また、これらのメトリクスを使用しているダッシュボード、ノートブック、モニター、SLO も確認できます。 + +タグを使用してメトリクスを特定のチーム、ソース、環境でフィルタリングし、必要に応じてそれらのメトリクスの [ダッシュボード][5] を作成してデータを可視化したり、[モニター][6] を作成してメトリクスが指定したしきい値を超えた際にアラートを受け取ったりできます。 + +## 参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://app.datadoghq.com/dash/integration/30378/cloud-siem-overview +[2]: https://app.datadoghq.com/security/configuration/reports +[3]: /ja/metrics/types/?tab=distribution#metric-types +[4]: https://app.datadoghq.com/metric/summary?filter=datadog.security.siem&window=604800 +[5]: /ja/getting_started/dashboards/ +[6]: /ja/getting_started/monitors/ \ No newline at end of file diff --git a/content/ja/security/code_security/iast/setup/compatibility/dotnet.md b/content/ja/security/code_security/iast/setup/compatibility/dotnet.md new file mode 100644 index 0000000000000..2e9538f5f7413 --- /dev/null +++ b/content/ja/security/code_security/iast/setup/compatibility/dotnet.md @@ -0,0 +1,110 @@ +--- +code_lang: dotnet +code_lang_weight: 10 +title: .NET 互換性要件 +type: multi-code-lang +--- + +## Application Security capabilities support + +指定されたトレーサーバージョンに対して、.NET ライブラリでサポートされるアプリケーションセキュリティ機能は以下のとおりです: + +| アプリケーションセキュリティ機能 | .NET トレーサーの最小バージョン | +| -------------------------------- | ----------------------------| +| Threat Detection | 2.23.0| +| Threat Protection | 2.26.0| +| ブロックされたリクエストへの対応をカスタマイズする | 2.27.0 | +| ソフトウェア構成分析 (SCA) | 2.16.0 | +| コードセキュリティ | 2.42.0 | +| ユーザーアクティビティイベントの自動追跡 | 2.32.0 | +| API セキュリティ | 2.42.0 | + +.NET でサポートされるすべてのアプリケーションセキュリティ機能を利用するための最小トレーサーバージョンは 2.42.0 です。 + +**注**: Threat Protection を利用するには [Remote Configuration][3] を有効にする必要があります。Remote Configuration は上記の最小トレーサーバージョンに含まれています。 + +### サポートされるデプロイメントタイプ +| タイプ | Threat Detection のサポート | ソフトウェア構成分析 | +|-------------------|--------------------------|------------------------------------------| +| Docker | {{< X >}} | {{< X >}} | +| Kubernetes | {{< X >}} | {{< X >}} | +| Amazon ECS | {{< X >}} | {{< X >}} | +| AWS Fargate | {{< X >}} | {{< X >}} | +| AWS Lambda | {{< X >}} | | +| Azure App Service | {{< X >}} | {{< X >}} | + +**注**: Azure App Service は **Web アプリケーションのみ**サポートされます。Azure Functions は Application Security 機能のサポート対象外です。 + +## 言語とフレームワークの互換性 + +### サポートされている .NET バージョン + +| .NET Framework バージョン | マイクロソフトサポート終了 | サポートレベル | パッケージバージョン | +| ----------------------- | --------------------- | ----------------------------------- | --------------------------- | +| 4.8 | | GA | 最新 | +| 4.7.2 | | GA | 最新 | +| 4.7 | | GA | 最新 | +| 4.6.2 | | GA | 最新 | +| 4.6.1 | 04/26/2022 | GA | 最新 | + + +これらは、以下のアーキテクチャでサポートされています。 +- Linux (GNU) x86-64、ARM64 +- Alpine Linux (musl) x86-64、ARM64 +- macOS (Darwin) x86-64、ARM64 +- Windows (msvc) x86、x86-64 + + + +### Web フレームワークの互換性 + +- 攻撃元の HTTP リクエストの詳細 +- HTTP リクエスト用のタグ (ステータスコード、メソッドなど) +- アプリケーション内の攻撃フローを確認するための分散型トレーシング + +##### アプリケーションセキュリティ機能に関する注意事項 +- **Software Composition Analysis** はすべてのフレームワークでサポートされます。 +- リストにないフレームワークの場合、**Code Security** では Insecure Cookie (不適切な Cookie 設定) の検出が継続されます。 + + +| フレームワーク | Threat Detection のサポートの有無 | Threat Protection のサポートの有無 | Code Security ですか？ | +| ----------------------- | --------------- | ---------------------------------------------- | ---------------------------------------------- | +| ASP.NET MVC | {{< X >}} |{{< X >}} | {{< X >}} | +| ASP.NET Web API 2 | {{< X >}} | {{< X >}} | {{< X >}} | + +
ご希望のフレームワークが掲載されていない場合は、お知らせください！この短いフォームに必要事項を記入して、詳細を送信してください。
+ +### データストアの互換性 + +**データストアのトレーシングでは以下の確認が可能です** + +- SQL 攻撃の検知 +- クエリ情報 (サニタイジングされたクエリ文字列など) +- エラーとスタックトレースの取得 + +##### アプリケーションセキュリティ機能に関する注意事項 +- **Threat Protection** は HTTP リクエスト (input) レイヤーでも機能するため、下表に掲載されていなくても、デフォルトですべてのデータベースで機能します。 + +| フレームワーク | Threat Detection のサポートの有無 | Threat Protection のサポートの有無 | Code Security ですか？ | +|-------------------|-----------------|---------------------|---| +| OracleDB | {{< X >}} | {{< X >}} |{{< X >}} | +| ADO.NET | {{< X >}} | {{< X >}} |{{< X >}} | +| SQL Server | {{< X >}} | {{< X >}} |{{< X >}} | +| MySQL | {{< X >}} | {{< X >}} |{{< X >}} | +| SQLite | {{< X >}} | {{< X >}} |{{< X >}} | + +### User Authentication Frameworks の互換性 + +**User Authentication Frameworks へのインテグレーションは以下を提供します。** + +- ユーザー ID を含むユーザーログインイベント +- ユーザーサインアップイベント (組み込みの SignInManager を使用するアプリ) +- ユーザーログインイベントのアカウント乗っ取り検出モニタリング + +| フレームワーク | +|-------------------| +| > .Net Core 2.1 | + +[1]: /ja/tracing/trace_collection/compatibility/dotnet-core/ +[2]: /ja/tracing/trace_collection/compatibility/dotnet-framework/ +[3]: /ja/remote_configuration#enabling-remote-configuration \ No newline at end of file diff --git a/content/ja/service_management/case_management/troubleshooting.md b/content/ja/service_management/case_management/troubleshooting.md index 71e4f87ab8551..05f767c2b8cb8 100644 --- a/content/ja/service_management/case_management/troubleshooting.md +++ b/content/ja/service_management/case_management/troubleshooting.md @@ -2,12 +2,6 @@ title: トラブルシューティング --- -{{% site-region region="gov,ap1" %}} -
-Case Management は現在、{{< region-param key=dd_datacenter code="true" >}} サイトでは利用できません。 -
-{{% /site-region %}} - ## 概要 このガイドは、Case Management のサードパーティインテグレーションに関する問題を解決するためのものです。問題が解決しない場合は、[Datadog サポート][1]までお問い合わせください。 @@ -16,7 +10,7 @@ Case Management は現在、{{< region-param key=dd_datacenter code="true" >}} カスタムフィールドを持つ Jira 課題タイプ、プライベート Jira プロジェクト、およびオンプレミス Jira インスタンスはサポートされていません。同期による Jira チケットの自動作成に問題がある場合は、次のセクションを参照してください。 -### 構成 +### 設定 1. Jira プロジェクトが Jira インテグレーション構成画面のドロップダウンに反映されない場合は、`manage_integrations` 権限があるか確認してください。 diff --git a/content/ja/service_management/events/ingest.md b/content/ja/service_management/events/ingest.md new file mode 100644 index 0000000000000..ca8a627399586 --- /dev/null +++ b/content/ja/service_management/events/ingest.md @@ -0,0 +1,24 @@ +--- +title: Datadog にイベントを送信する +--- + +## 標準イベント +追加設定を行わなくても、Datadog Events は Agent およびインストール済みインテグレーションによって収集されたイベントを自動的に集約します。 + +Kubernetes、Docker、Jenkins、Chef、Puppet、Amazon ECS または Autoscaling、Sentry、Nagios など、100 を超える Datadog インテグレーションがイベント収集をサポートしています。 + +{{< whatsnext desc="イベントを Datadog に送信する:" >}} + {{< nextlink href="https://app.datadoghq.com/integrations" >}}インテグレーション{{< /nextlink >}} +{{< /whatsnext >}} + +## カスタムイベント +Datadog API、カスタム Agent チェック、DogStatsD、または Events Email API を使用して、独自のカスタムイベントを送信することもできます。 + +{{< whatsnext desc="カスタムイベントを Datadog に送信する:" >}} + {{< nextlink href="/api/latest/events/#post-an-event" >}}Datadog API{{< /nextlink >}} + {{< nextlink href="/service_management/events/guides/agent/" >}}カスタム Agent チェック{{< /nextlink >}} + {{< nextlink href="/service_management/events/guides/email/" >}}メール{{< /nextlink >}} + {{< nextlink href="/service_management/events/guides/dogstatsd/" >}}DogStatsD{{< /nextlink >}} + {{< nextlink href="/integrations/guide/events-from-sns-emails/" >}}Amazon SNS メール{{< /nextlink >}} + {{< nextlink href="/logs/guide/sending-events-and-logs-to-datadog-with-amazon-eventbridge-api-destinations/#configuration" >}}Amazon EventBridge API デスティネーション{{< /nextlink >}} +{{< /whatsnext >}} \ No newline at end of file diff --git a/content/ja/service_management/on-call/schedules.md b/content/ja/service_management/on-call/schedules.md new file mode 100644 index 0000000000000..8956cd8161c83 --- /dev/null +++ b/content/ja/service_management/on-call/schedules.md @@ -0,0 +1,115 @@ +--- +further_reading: +- link: /service_management/on-call/ + tag: ドキュメント + text: Datadog On-Call +title: スケジュール +--- + +Datadog On-Call では、チームメンバーがページ (呼び出し) に対応できる特定の時間をスケジュールで定義します。スケジュールは、異なるタイムゾーンやシフトにわたるチームメンバーの対応可否を整理し、管理します。 + +### 概念 + +On-Call のスケジュールはレイヤー構造になっており、各レイヤーが週の異なる部分や特定の責任範囲をカバーします。 + +次の例となるスケジュールを見てみましょう: + +{{< img src="service_management/oncall/schedule.png" alt="複数のレイヤー (JP、EU、US の営業時間) で構成されたサンプルスケジュール。" style="width:100%;" >}} + +4 つのレイヤーがあります: +- **JP Business Hours**: DM が日本の営業時間 (UTC から見た場合の各日) を担当します。月曜日から金曜日まで毎日繰り返されます。 +- **EU Business Hours**: 次に、DB がヨーロッパの営業時間を担当します。月曜日から金曜日まで毎日繰り返されます。 +- **US Business Hours**: 最後に、BS がアメリカの営業時間 (UTC から見て各日の終わり) を担当します。月曜日から金曜日まで毎日繰り返されます。 +- **Overrides**: 一時的なシフト調整や休日など、スケジュールの変更に対応します。詳細は[オーバーライド](#overrides)を参照してください。 + +**最終的なスケジュール (Final Schedule)** はすべてのレイヤーで構成されます。下にあるレイヤーほど優先され、上位レイヤーを上書きします。 + +### スケジュールを作成する + +1. [**On-Call** > **Schedules**][1] に移動します。 +1. [**+ New Schedule**][2] を選択します。 +1. スケジュールの **Name** を入力し、使用する **Schedule Time Zone** とこのスケジュールを管理する **Teams** を選択します。 +1. レイヤーを追加します: + - **Starts**: スケジュールが有効になる日時です。この日時より前にはシフトは表示されません。 + - **Shift length**: 各シフトの長さ (つまり、スケジュールが繰り返される間隔) を指定します。以下のオプションがあります: + - _One Day_ (24 時間) + - _One Week_ (168 時間) + - _Custom_ + - **Handoff Time**: シフトが次の担当者に切り替わる日時です。 + - **End time**: このレイヤーにおいて、これ以降のシフトがスケジュールされない日時です。 + - **Conditions**: 各シフトに適用される時間条件を設定します。たとえば、月曜から金曜の午前 9 時から午後 5 時まで、などが指定できます。 + - **Members**: On-Call の任務を実行するメンバーのリストです。リストに追加した順序でシフトを担当します。 +1. **Create** を選択します。 + +### エスカレーションポリシーにスケジュールを参照する +特定のスケジュールの当番者にページを送信するには、そのスケジュールをエスカレーションポリシー内で参照します。エスカレーションポリシーを作成または編集するときに、エスカレーションステップの **Notify** ドロップダウンメニューから目的のスケジュールを検索して選択します。エスカレーションポリシーはページがトリガーされたときに、当番の人物にページを送信します。 + +### オーバーライド {#overrides} +オーバーライドは、スケジュールされた On-Call シフトに対して行われる修正のことです。一時的なシフト調整や休日などの変更に対応できます。 + +{{< img src="service_management/oncall/schedule_override.png" alt="スケジュールを編集するとき、シフトが選択される。ダイアログが表示され、Override ボタンがある。" style="width:100%;" >}} + +シフトを完全または部分的に上書きするには、シフトを選択し、**Override** をクリックします。 + +#### Slack または Microsoft Teams でオーバーライドをリクエストする + +On-Call のローテーションに参加していて、シフト中に席を外すことが事前にわかっている場合は、Slack または Microsoft Teams でオーバーライドをリクエストできます。`/dd override` と入力し、上書きしたい時間枠を選択して説明を追加します。これにより、チャンネルにリクエストが送信されます: + +{{< img src="service_management/oncall/schedule_override_request.png" alt="Slack のメッセージ例: Datadog Staging が『@Daljeet がオーバーライドをリクエストしました: スケジュール [Primary] Payments & Transactions (payments-transactions)。開始: 今日13時、終了: 今日15時、所要時間2時間。メモ: Doctor's appointment. Will offer cookies for override.』と表示。末尾に 'Take it' ボタンがある。" style="width:80%;" >}} + +ほかのチャンネルメンバーは **Take it** を選択することで、あなたのシフトをオーバーライドするよう自分のシフトに組み込めます。 + +### スケジュールをエクスポートする + +Export Shifts 機能を使うと、`.webcal` リンクを利用してお好みのカレンダーアプリ (たとえば Google カレンダー、Apple カレンダー、Outlook など) に On-Call スケジュールを統合できます。**自分のシフトのみ**を同期するか、**スケジュール全体**を同期するかを選択できます。 + +--- + +##### 📆 *自分のシフト*をエクスポートする + +1. [**On-Call** > **Schedules**][1] セクションに移動します。 +2. **Export My Shifts** を選択します。個人用の `.webcal` リンクが自動的に生成されます。 +3. **Copy Link** をクリックします。 +4. 生成されたリンクをカレンダーアプリに貼り付けます。例: + - **Google カレンダー**: [リンクを使用して公開カレンダーを追加する][3] + - **Outlook**: [インターネットカレンダーを購読する][4] + - **Apple カレンダー**: [Mac または iPhone で購読する][5] + +On-Call シフトに変更があった場合、カレンダーは自動的に更新されます。以前共有したリンクへのアクセスを無効にしたい場合は新しいリンクを生成してください。前のリンクは無効化されます。 + +--- + +##### 🌐 *スケジュール全体*をエクスポートする + +1. [**On-Call** > **Schedules**][1] セクションに移動します。 +2. エクスポートしたいスケジュールを開きます。 +3. **Export Schedule** を選択します。これにより、全参加者とシフトを含むスケジュール全体用の `.webcal` リンクが生成されます。 +4. **Copy Link** をクリックします。 +5. 生成されたリンクをカレンダーアプリに貼り付けます: + - **Google カレンダー**: [リンクを使用して公開カレンダーを追加する][3] + - **Outlook**: [インターネットカレンダーを購読する][4] + - **Apple カレンダー**: [Mac または iPhone で購読する][5] + +--- + +##### 🔔 通知を受け取る + +カレンダーアプリで、これから始まるシフトのリマインダーを有効にできます。また、[Datadog On-Call のプロフィール設定][6]で、SMS やプッシュ通知、メールによるカスタムシフト通知を設定できます。 + + +#### スケジュールエクスポートのトラブルシューティング + +Google カレンダーに On-Call のスケジュールフィードをエクスポートする際 (「URL を取得できませんでした」など) や、Outlook でのエラー (「カレンダーをインポートできません。再試行してください」など) が発生する場合、URL で初期購読を行う際に以下の対処を試してください: + +- URL の先頭を `webcal://` から `http://` または `https://` に変更します。たとえば、`webcal://` を `http://` に変更します。 + +## その他の参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://app.datadoghq.com/on-call/schedules +[2]: https://app.datadoghq.com/on-call/schedules/create +[3]: https://support.google.com/calendar/answer/37100?hl=en&co=GENIE.Platform%3DDesktop +[4]: https://support.microsoft.com/en-us/office/import-or-subscribe-to-a-calendar-in-outlook-com-or-outlook-on-the-web-cff1429c-5af6-41ec-a5b4-74f2c278e98c +[5]: https://support.apple.com/en-us/102301 +[6]: /ja/service_management/on-call/profile_settings/ \ No newline at end of file diff --git a/content/ja/service_management/service_level_objectives/guide/slo-checklist.md b/content/ja/service_management/service_level_objectives/guide/slo-checklist.md index 01af8a34122a9..bb51879f8b789 100644 --- a/content/ja/service_management/service_level_objectives/guide/slo-checklist.md +++ b/content/ja/service_management/service_level_objectives/guide/slo-checklist.md @@ -10,14 +10,17 @@ further_reading: text: サービスレベル目標入門 - link: /service_management/service_level_objectives/guide/slo_types_comparison/ tag: ドキュメント - text: Comparison of Datadog SLO Types + text: Datadog SLO タイプの比較 +- link: https://www.datadoghq.com/blog/define-and-manage-slos/ + tag: ブログ + text: Datadog で SLO を管理するためのベストプラクティス title: SLO チェックリスト --- ## はじめに -1. Navigate to the [SLO Manage page][1]. +1. [SLO Manage ページ][1] に移動します。 2. ユーザーの目線から考えてみてください: @@ -32,7 +35,7 @@ title: SLO チェックリスト #### 応答 / リクエスト -| Type of SLI | 説明 | +| SLI の種類 | 説明 | | ------------ | -------------------------------------------------------------- | | 可用性 | サーバーはリクエストに正常に応答しましたか？ | | レイテンシー | サーバーがリクエストに応答するまでにどれぐらい時間がかかりましたか？ | @@ -40,7 +43,7 @@ title: SLO チェックリスト #### Storage -| Type of SLI | 説明 | +| SLI の種類 | 説明 | | ------------ | -------------------------------------------- | | 可用性 | データにオンデマンドでアクセスできますか？ | | レイテンシー | データの読み書きにどれぐらい時間がかかりますか？ | @@ -48,44 +51,52 @@ title: SLO チェックリスト #### パイプライン -| Type of SLI | 説明 | +| SLI の種類 | 説明 | | ----------- | ------------------------------------------------------------------ | | 正確性 | 正しいデータが返されましたか？ | | 鮮度 | 新しいデータまたは処理された結果が表示されるまでにどれぐらい時間がかかりますか？ | ### ステップ 2 -**Do you require an SLI calculation that is time-based or count-based?** +#### SLO タイプを選択する際のベスト プラクティス + +- 可能な限り、メトリクス ベースの SLO を使用してください。エラー バジェットが SLO 違反までに残された不良イベント数を反映する SLO にするのがベスト プラクティスです。また、SLO の計算はイベント数に基づいてボリューム加重されます。 +- 代わりに、アップタイムを追跡し時間 ベースの SLI 計算を使用する SLO が必要な場合は、タイム スライス SLO を使用してください。モニター ベースの SLO と異なり、タイム スライス SLO では SLO 用の基盤モニターを維持する必要がありません。 +- 最後に、タイム スライス SLO でカバーできないユース ケース—ノン メトリクス モニターや複数モニターに基づく SLO など—では、モニター ベースの SLO を検討してください。 + +SLO タイプの詳細な比較については、[SLO タイプ比較][8] ガイドを参照してください。 + +**SLI 計算は時間 ベースですか、それともカウント ベースですか?** -The following SLO types are available in Datadog: +Datadog では、次の SLO タイプを利用できます: -**Metric-based SLOs** +**メトリクス ベース SLO** _例: リクエストの 99% は、30 日間で 250 ms 未満で完了する必要があります。_ -- Count-based SLI calculation -- SLI is calculated as the sum of good events divided by the sum of total events +- カウント ベースの SLI 計算 +- SLI は正常イベントの合計を総イベント数の合計で割って計算します -**Monitor-based SLOs** +**モニター ベース SLO** _例: すべてのユーザーリクエストのタイムレイテンシーの 99% は、いずれの 30 日の範囲内でも250 ms 未満で ある必要があります。_ -- Time-based SLI calculation -- SLI calculated based on the underlying Monitor’s uptime -- You can select a single monitor, multiple monitors (up to 20), or a single multi alert monitor with groups +- 時間 ベースの SLI 計算 +- SLI は基盤モニターのアップタイムに基づいて計算されます +- 1 つのモニター、複数モニター (最大 20)、またはグループ化されたマルチ アラート モニターを選択できます 新しいモニターの作成が必要な場合は [Monitor create][2] ページを開きます。 -**Time Slice SLOs** +**タイム スライス SLO** _例: すべてのユーザーリクエストのタイムレイテンシーの 99% は、いずれの 30 日の範囲内でも250 ms 未満で ある必要があります。_ -- Time-based SLI calculation -- SLI calculated based on your custom uptime definition using a metric query +- 時間 ベースの SLI 計算 +- SLI はメトリクス クエリを用いて定義したカスタム アップタイムに基づいて計算されます -## Implement your SLIs +## SLI を実装する 1. [カスタムメトリクス][3] (例: カウンター) 2. [インテグレーションメトリクス][4] (例: ロードバランサー、HTTP リクエスト) @@ -94,8 +105,8 @@ _例: すべてのユーザーリクエストのタイムレイテンシーの 9 ## ターゲット目標および時間枠の設定 -1. Select your target: `99%`, `99.5%`, `99.9%`, `99.95%`, or any other target value that makes sense for your requirements. -2. Select your time window: over the last rolling `7`, `30`, or `90 days` +1. ターゲットを選択します: `99%`、`99.5%`、`99.9%`、`99.95%`、または要件に適したその他の値。 +2. 時間 ウィンドウを選択します: 直近のローリング `7`、`30`、または `90 days` ## SLO の名前、説明、タグの追加 @@ -112,9 +123,10 @@ _例: すべてのユーザーリクエストのタイムレイテンシーの 9 {{< partial name="whats-next/whats-next.html" >}} [1]: https://app.datadoghq.com/slo/manage -[2]: https://app.datadoghq.com/monitors#create/metric +[2]: https://app.datadoghq.com/monitors/create/metric [3]: /ja/metrics [4]: /ja/integrations [5]: /ja/tracing/trace_pipeline/generate_metrics/ [6]: /ja/logs/logs_to_metrics/ -[7]: /ja/service_management/service_level_objectives/#searching-and-viewing-slos \ No newline at end of file +[7]: /ja/service_management/service_level_objectives/#searching-and-viewing-slos +[8]: /ja/service_management/service_level_objectives/guide/slo_types_comparison \ No newline at end of file diff --git a/content/ja/service_management/service_level_objectives/guide/slo_types_comparison.md b/content/ja/service_management/service_level_objectives/guide/slo_types_comparison.md index c2be96f463917..06eb6a57e69c1 100644 --- a/content/ja/service_management/service_level_objectives/guide/slo_types_comparison.md +++ b/content/ja/service_management/service_level_objectives/guide/slo_types_comparison.md @@ -2,45 +2,55 @@ further_reading: - link: /service_management/service_level_objectives/ tag: ドキュメント - text: サービスレベル目標の概要 + text: サービス レベル目標の概要 - link: /service_management/service_level_objectives/metric/ tag: ドキュメント - text: Metric-based SLOs + text: メトリクス ベースの SLO - link: /service_management/service_level_objectives/monitor/ tag: ドキュメント - text: Monitor-based SLOs + text: Monitor ベースの SLO - link: /service_management/service_level_objectives/time_slice/ tag: ドキュメント - text: Time Slice SLOs + text: タイム スライス SLO +- link: https://www.datadoghq.com/blog/define-and-manage-slos/ + tag: ブログ + text: Datadog で SLO を管理するためのベスト プラクティス title: SLO タイプの比較 --- ## 概要 -When creating SLOs, you can choose from the following types: -- **Metric-based SLOs**: can be used when you want the SLI calculation to be count-based, the SLI is calculated as the sum of good events divided by the sum of total events. -- **Monitor-based SLOs**: can be used when you want the SLI calculation to be time-based, the SLI is based on the Monitor's uptime. Monitor-based SLOs must be based on a new or existing Datadog monitor, any adjustments must be made to the underlying monitor (cannot be done through SLO creation). -- **Time Slice SLOs**: can be used when you want the SLI calculation to be time-based, the SLI is based on your custom uptime definition (amount of time your system exhibits good behavior divided by the total time). Time Slice SLOs do not require a Datadog monitor, you can try out different metric filters and thresholds and instantly explore downtime during SLO creation. - -
The supported history duration for Metric-based and Time Slice SLOs matches your account's metric duration (by default, this is 15 months).
- -## Comparison chart - -| | **Metric-based SLO** | **Monitor-based SLO** | **Time Slice SLO** | -|-----------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------| -| **Supported data types** | Metrics with type of count, rate, or distribution | Metric Monitor types, Synthetic Monitors, and Service Checks | All metric types (including gauge metrics) | -| **Functionality for SLO with Groups** | SLO calculated based on all groups

Can view all groups in SLO side panel and SLO widget | Supported for SLOs with a single multi alert Monitor

**Option 1:** SLO calculated based on all groups (can view all groups in SLO side panel and SLO widget)
**Option 2:** SLO calculated based on up to 20 selected groups (can view all selected groups in SLO side panel and SLO widget) | SLO calculated based on all groups

Can view all groups in SLO side panel and SLO widget | -| **SLO side panel** | Can set custom time windows to view up to 15 months of SLO history | Can set custom time windows to view up to 3 months of SLO history | Can set custom time windows to view up to 15 months of SLO history | -| **SLO alerting ([Error Budget][1] or [Burn Rate][2] Alerts)** | Available | Available for SLOs based on Metric Monitor types only (not available for Synthetic Monitors or Service Checks) | Available | -| [**SLO Status Corrections**][3] | Correction periods are ignored from SLO status calculation | 修正期間は SLO ステータスの計算から無視されます | Correction periods are counted as uptime in SLO status calculation | -| **SLO widgets ([SLO List widget][10] or [SLO widget][9])** | Can view up to 15 months of historical data with the SLO widget | Can view up to 3 months of historical data with the SLO widget | Can view up to 15 months of historical data with the SLO widget | -| **[SLO Data Source][5] (up to 15 months of historical data)** | Available | Not available | Available | -| **Handling missing data in the SLO calculation** | Missing data is ignored in SLO status and error budget calculations | Missing data is handled based on the [underlying Monitor's configuration][6] | Missing data is treated as uptime in SLO status and error budget calculations | -| **Uptime Calculations** | N/A | Uptime calculations are based on the underlying Monitor

If groups are present, overall uptime requires *all* groups to have uptime| [Uptime][7] is calculated by looking at discrete time chunks, not rolling time windows

If groups are present, overall uptime requires *all* groups to have uptime | -| **[Calendar View][11] on SLO Manage Page** | Available | Not available | Available | -| **Public [APIs][8] and Terraform Support** | Available | 利用可 | 利用可能 | - -## その他の参考資料 +SLO を作成する際は、次のタイプから選択できます: +- **メトリクス ベースの SLO**: SLI の計算をカウント ベースにしたい場合に使用できます。SLI は、良いイベントの合計を全イベントの合計で割って算出します。 +- **Monitor ベースの SLO**: SLI の計算を時間ベースにしたい場合に使用できます。SLI は Monitor のアップタイムに基づきます。Monitor ベースの SLO は、新規または既存の Datadog Monitor を基盤にする必要があり、調整は基盤となる Monitor 側で行う必要があります (SLO の作成からは実施できません)。 +- **タイム スライス SLO**: SLI の計算を時間ベースにしたい場合に使用できます。SLI はカスタムのアップタイム定義 (システムが良好な挙動を示した時間の合計を、総時間で割ったもの) に基づきます。タイム スライス SLO は Datadog Monitor を必要としません。SLO の作成中に各種メトリクス フィルターやしきい値を試し、ダウンタイムを即座に調査できます。 + +
メトリクス ベースおよびタイム スライス SLO が参照できる履歴期間は、アカウントのメトリクス保持期間に一致します (既定では 15 か月)。
+ +## 比較表 + +| | **メトリクス ベースの SLO** | **Monitor ベースの SLO** | **タイム スライス SLO** | +|-----------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------| +| **サポートされるデータ タイプ** | タイプが count、rate、distribution のメトリクス | Metric Monitor タイプ、Synthetic Monitors、Service Checks | すべてのメトリクス タイプ (gauge メトリクスを含む) | +| **グループ付き SLO の機能** | すべてのグループに基づいて SLO を計算

SLO サイド パネルと SLO ウィジェットで全グループを表示可能 | single multi alert Monitor を持つ SLO でサポート

**オプション 1:** すべてのグループに基づいて SLO を計算 (SLO サイド パネルと SLO ウィジェットで全グループを表示可能)
**オプション 2:** 最大 20 個の選択したグループに基づいて SLO を計算 (SLO サイド パネルと SLO ウィジェットで選択したすべてのグループを表示可能) | すべてのグループに基づいて SLO を計算

SLO サイド パネルと SLO ウィジェットで全グループを表示可能 | +| **SLO サイド パネル** | カスタムの時間ウィンドウを設定して最大 15 か月の SLO 履歴を表示可能 | カスタムの時間ウィンドウを設定して最大 3 か月の SLO 履歴を表示可能 | カスタムの時間ウィンドウを設定して最大 15 か月の SLO 履歴を表示可能 | +| **SLO アラート ([エラー バジェット][1] または [バーン レート][2] アラート)** | 利用可能

グループがある場合、SLO 全体のみを基準にアラート可能 | Metric Monitor タイプに基づく SLO のみに対して利用可能 (Synthetic Monitors および Service Checks では利用不可)

グループがある場合、SLO 全体のみを基準にアラート可能 | 利用可能

グループがある場合、グループ単位または SLO 全体を基準にアラート可能 | +| [**SLO Status Corrections**][3] | 補正期間は SLO ステータスの計算から除外されます | 補正期間は SLO ステータスの計算から除外されます | 補正期間は SLO ステータスの計算でアップタイムとして算入されます | +| **SLO ウィジェット ([SLO List ウィジェット][10] または [SLO ウィジェット][9])** | SLO ウィジェットで最大 15 か月の履歴データを表示可能 | SLO ウィジェットで最大 3 か月の履歴データを表示可能 | SLO ウィジェットで最大 15 か月の履歴データを表示可能 | +| **[SLO Data Source][5] (最大 15 か月の履歴データ)** | 利用可能 | 利用不可 | 利用可能 | +| **SLO 計算における欠損データの扱い** | 欠損データは SLO ステータスおよびエラー バジェットの計算で無視されます | 欠損データは [基盤となる Monitor の設定][6] に従って処理されます | 欠損データは SLO ステータスおよびエラー バジェットの計算でアップタイムとして扱われます | +| **アップタイムの計算** | 該当なし | アップタイムの計算は基盤となる Monitor に基づきます

グループがある場合、全体のアップタイムには*すべての*グループにアップタイムがあることが必要です| [アップタイム][7] はローリング タイム ウィンドウではなく、離散的な時間 チャンクを用いて計算されます

グループがある場合、全体のアップタイムには*すべての*グループにアップタイムがあることが必要です | +| **SLO Manage ページの [Calendar View][11]** | 利用可能 | 利用不可 | 利用可能 | +| **パブリック [API][8] と Terraform サポート** | 利用可能 | 利用可能 | 利用可能 | + +## SLO タイプの選び方に関するベスト プラクティス + +- 可能な限りメトリクス ベースの SLO を使用してください。SLO を違反するまでに残された不良イベント数をエラー バジェットが正確に反映するようにすることがベスト プラクティスです。SLO の計算は、イベント数に基づいてボリューム加重にもなります。 +- 一方、アップタイムを追跡し、時間ベースの SLI 計算を用いる SLO が必要な場合は、タイム スライス SLO を使用してください。Monitor ベースの SLO と異なり、タイム スライス SLO では SLO のために基盤となる Monitor を維持する必要がありません。 +- 最後に、タイム スライス SLO でカバーされないユース ケース (非メトリクス系の Monitor や複数の Monitor に基づく SLO など) については、Monitor ベースの SLO の活用を検討してください。 + + +## 関連資料 {{< partial name="whats-next/whats-next.html" >}} diff --git a/content/ja/service_management/service_level_objectives/metric.md b/content/ja/service_management/service_level_objectives/metric.md index ba2381e12b1c6..8984c96988972 100644 --- a/content/ja/service_management/service_level_objectives/metric.md +++ b/content/ja/service_management/service_level_objectives/metric.md @@ -10,6 +10,9 @@ further_reading: - link: /service_management/service_level_objectives/ tag: Documentation text: SLO の概要、構成、計算 +- link: https://www.datadoghq.com/blog/define-and-manage-slos/ + tag: ブログ + text: Datadog で SLO を管理するためのベストプラクティス title: メトリクスベース SLO --- @@ -17,33 +20,33 @@ title: メトリクスベース SLO メトリクスベースの SLO は、計数ベースのデータストリームでイベントの良し悪しを判断する場合に有用です。メトリクスクエリは良質なイベントの合計を同様の時間軸におけるイベント総数で割り、サービスレベル指標 (SLI) を算出します。SLO の作成には、[APM スパン][1]、[RUM イベント][2]、[ログ][3]から生成されるカスタムメトリクスを含め、あらゆるメトリクスを使用することができます。SLO の構成と計算方法については、[サービスレベル目標][4]のページを参照してください。 -{{< img src="service_management/service_level_objectives/metric_slo_side_panel.png" alt="example metric-based SLO" >}} +{{< img src="service_management/service_level_objectives/metric_slo_side_panel.png" alt="メトリクス ベース SLO の例" >}} ## セットアップ -On the [SLO status page][5], click **+ New SLO**. Then select, [**By Count**][6]. +[SLO ステータス ページ][5] で **+ New SLO** をクリックします。次に [**By Count**][6] を選択します。 ### クエリの定義 -1. 定義するクエリは 2 つあります。分子クエリは良好なイベントの合計を定義し、分母クエリは総イベントの合計を定義します。SLO 計算が正しく動作するように、クエリでは COUNT、RATE、またはパーセンタイル対応の DISTRIBUTION メトリクスを使用する必要があります。詳しくは[クエリ][9]のドキュメントをご覧ください。 +1. 定義するクエリは 2 つあります。分子クエリは正常イベントの合計を定義し、分母クエリは総イベントの合計を定義します。SLO 計算を正しく行うため、クエリでは COUNT、RATE、またはパーセンタイル対応 DISTRIBUTION メトリクスを使用する必要があります。詳細は [クエリ方法][9] ドキュメントを参照してください。 1. タグを使用して特定のグループを含めるか除外するには、`FROM` フィールドを使用します。 1. パーセンタイル対応の DISTRIBUTION メトリクスでは、`count values...` アグリゲーターを使用して、メトリクスがカウントする数値のしきい値を指定する必要があります。この機能はしきい値クエリと呼ばれ、数値のしきい値に一致する生の値の数をカウントして、分子と分母のカウントを生成することができます。詳しくは、[しきい値クエリ][7]を参照してください。 1. オプションとして、パーセンタイル対応の DISTRIBUTION メトリクススでは、`count values...` アグリゲーターのすぐ右にあるドロップダウンを使用して、SLI を特定のグループごとに分割することができます。 1. オプションとして、COUNT または RATE のメトリクスでは、`sum by` アグリゲーターを使用して、SLI を特定のグループごとに分割することができます。 -**例:** HTTP のリターンコードを追跡しており、メトリクスに `code:2xx OR code:3xx OR code:4xx` などのタグが含まれている場合の例。良好なイベントの合計は `sum:httpservice.hits{code:2xx} + sum:httpservice.hits{code:4xx}` です。イベント自体の合計を表す `total` は `sum:httpservice.hits{!code:3xx}` となります。 +**例:** HTTP 返却コードをトラッキングしていて、メトリクスに `code:2xx OR code:3xx OR code:4xx` のようなタグが含まれている場合、正常イベントの合計は `sum:httpservice.hits{code:2xx} + sum:httpservice.hits{code:4xx}`、`total` イベントは `sum:httpservice.hits{!code:3xx}` となります。 `HTTP 3xx` を省いた理由は、これらは一般的にリダイレクトされるもので、SLI として、または SLl に対してカウントされるべきではないためです。一方、3xx ベースでないエラーコードは合計に含める必要があります。`total` には `HTTP 3xx` を除いたすべてのタイプのデータを、また `numerator` には `OK` タイプのステータスコードのみを充当します。 #### メトリクスベース SLI のマルチグループ -Metric-based SLIs allow you to focus on the most important attributes of your SLIs. You can add groups to your metric-based SLIs in the editor by using tags like `datacenter`, `env`, `availability-zone`, `resource`, or any other relevant group: +メトリクス ベース SLI を使用すると、SLI の最も重要な属性にフォーカスできます。エディタで `datacenter`、`env`、`availability-zone`、`resource` などのタグを使って、メトリクス ベース SLI にグループを追加できます: -{{< img src="service_management/service_level_objectives/metric_slo_creation.png" alt="grouped metric-based SLO editor" >}} +{{< img src="service_management/service_level_objectives/metric_slo_creation.png" alt="グループ化された メトリクス ベース SLO エディタ" >}} これらの SLI をグループ化すると、個々のグループのステータス、適切なリクエスト数、残りのエラーバジェットを詳細パネルで視覚化できます。 -{{< img src="service_management/service_level_objectives/metric_slo_history_groups.png" alt="metric-based SLO group results" >}} +{{< img src="service_management/service_level_objectives/metric_slo_history_groups.png" alt="メトリクス ベース SLO グループ結果" >}} デフォルトで、棒グラフは SLO 全体の正しい/正しくない要求すべての全体数を表示します。テーブルの該当する行をクリックすると、個別のグループの正しい/正しくない要求の棒グラフを詳しく確認できます。さらに、棒グラフの下にある凡例でオプションを選択し、正しいまたは正しくない要求の数を表示/非表示にすることも可能です。 @@ -53,7 +56,7 @@ SLO ターゲットは、ターゲットパーセンテージとタイムウィ 例: `リクエストの 99% は、過去 7 日間でエラーが生じていないこと`。 -SLO がターゲットパーセンテージを上回っている間、SLO のステータスは緑色のフォントで表示されます。ターゲットパーセンテージに違反すると、SLO のステータスは赤色のフォントで表示されます。オプションで、ターゲットパーセンテージより大きい警告パーセンテージを含めて、SLO 違反に近づいていることを示すこともできます。警告パーセンテージに違反している場合 (ただし、ターゲットパーセンテージには違反していない場合)、SLO ステータスは黄色のフォントで表示されます。 +SLO が目標パーセンテージ以上のあいだは、SLO ステータスが緑色フォントで表示されます。目標パーセンテージを下回ると、SLO ステータスは赤色フォントで表示されます。また、SLO 違反が近いことを示すために、目標パーセンテージより低い警告パーセンテージをオプションで設定できます。警告パーセンテージを下回り、目標パーセンテージを下回っていない場合、SLO ステータスは黄色フォントで表示されます。 **注:** メトリクスベースの SLO ターゲットには小数第 3 位まで使用できます。SLO の詳細 UI に表示される精度は `num_target_decimal_places + 1 = 小数第 4 位` までです。正確な精度は、分母クエリ内の値の大きさにより異なります。分母が大きいほど、小数第 4 位の上限まで精度を表示できます。 @@ -69,4 +72,4 @@ SLO がターゲットパーセンテージを上回っている間、SLO のス [6]: https://app.datadoghq.com/slo/new/metric [7]: /ja/metrics/distributions/#threshold-queries [8]: /ja/service_management/service_level_objectives/monitor/ -[9]: https://docs.datadoghq.com/ja/dashboards/querying/#advanced-graphing +[9]: https://docs.datadoghq.com/ja/dashboards/querying/#advanced-graphing \ No newline at end of file diff --git a/content/ja/synthetics/api_tests/dns_tests.md b/content/ja/synthetics/api_tests/dns_tests.md index e4c306e93e283..e4832095089b1 100644 --- a/content/ja/synthetics/api_tests/dns_tests.md +++ b/content/ja/synthetics/api_tests/dns_tests.md @@ -38,20 +38,30 @@ DNS テストは、ネットワークの外部または内部からのテスト ## 構成 -`DNS` テストの作成を選択した後、テストのリクエストを定義します。 +You may create a test using one of the following options: -### リクエストを定義する +- **Create a test from a template**: -1. テストでクエリする**ドメイン**を指定します (例: `www.example.com`)。 -2. 使用する **DNS サーバー** を指定します（任意）。ドメイン名または IP アドレスを使用できます。指定されていない場合、DNS テストは `8.8.8.8` を使用して解決を実行し、 `1.1.1.1` と内部 AWS DNS サーバーにフォールバックします。 -3. DNS サーバーの **ポート** を指定します（任意）。指定されていない場合、DNS サーバーのポートはデフォルトで 53 になります。 -4. テストがタイムアウトするまでの時間を秒単位で指定します (オプション)。 -5. DNS テストに**名前**を付けます。 -6. DNS テストに `env` **タグ**とその他のタグを追加します。次に、これらのタグを使用して、[Synthetic Monitoring & Continuous Testing ページ][3]で Synthetic テストをフィルタリングできます。 + 1. Hover over one of the pre-populated templates and click **View Template**. This opens a side panel displaying pre-populated configuration information, including: Test Details, Request Details, Assertions, Alert Conditions, and Monitor Settings. + 2. Click **+Create Test** to open the **Define Request** page, where you can review and edit the pre-populated configuration options. The fields presented are identical to those available when creating a test from scratch. + 3. Click **Save Details** to submit your API test.

-{{< img src="synthetics/api_tests/dns_test_config_new.png" alt="DNS クエリを定義する" style="width:90%;" >}} + {{< img src="getting_started/synthetics/synthetics_templates_api_video.mp4" alt="Video of Synthetics API test landing page with templates" video="true" >}} -**Test URL** をクリックして、リクエストのコンフィギュレーションをテストします。画面の右側に応答プレビューが表示されます。 +- **Build a test from scratch**: + + 1. テストを一から作成するには、**+ Start from scratch** テンプレートをクリックし、DNS リクエストタイプを選択します。 + 1. テストでクエリする**ドメイン**を指定します (例: `www.example.com`)。 + 1. 使用する **DNS サーバー** を指定します（任意）。ドメイン名または IP アドレスを使用できます。指定されていない場合、DNS テストは `8.8.8.8` を使用して解決を実行し、 `1.1.1.1` と内部 AWS DNS サーバーにフォールバックします。 + 1. DNS サーバーの **ポート** を指定します（任意）。指定されていない場合、DNS サーバーのポートはデフォルトで 53 になります。 + 1. テストがタイムアウトするまでの時間を秒単位で指定します (オプション)。 + 1. DNS テストに**名前**を付けます。 + 1. DNS テストに Environment **タグ**とその他のタグを追加します。次に、これらのタグを使用して、[Synthetic Monitoring & Continuous Testing ページ][3]で Synthetic テストをフィルタリングできます。 + 1. **Test Domain** をクリックして、リクエストの構成をテストします。画面の右側に応答プレビューが表示されます。

+ + {{< img src="synthetics/api_tests/synthetics_dns_test_domain.png" alt="DNS クエリを定義する" style="width:90%;" >}} + + 1. Click **Create Test** to submit your API test. ### スニペット @@ -83,7 +93,7 @@ DNS テストは、ネットワークの外部または内部からのテスト DNS テストを実行するための **Locations** を選択します。DNS テストは、パブリックドメインまたはプライベートドメインを監視するかに応じて、管理ロケーションおよび[プライベートロケーション][1]の両方から実行することができます。 -{{% managed-locations %}} +{{% managed-locations %}} ### テストの頻度を指定する @@ -95,7 +105,7 @@ DNS テストは次の頻度で実行できます。 {{% synthetics-alerting-monitoring %}} -{{% synthetics-variables %}} +{{% synthetics-variables %}} ### 変数を使用する @@ -105,7 +115,7 @@ DNS テストの URL、高度なオプション、アサーションで、[**Set ## テストの失敗 -テストが 1 つ以上のアサーションを満たさない場合、またはリクエストが途中で失敗した場合、テストは `FAILED` と見なされます。場合によっては、エンドポイントに対するアサーションをテストせずにテストが実際に失敗することがあります。 +テストが 1 つ以上のアサーションを満たさない場合、またはリクエストが時期尚早に失敗した場合、テストは `FAILED` と見なされます。場合によっては、エンドポイントに対してアサーションをテストすることなくテストが実際に失敗することがあります。 これらの理由には以下が含まれます。 @@ -115,7 +125,7 @@ DNS テストの URL、高度なオプション、アサーションで、[**Set `DNS` : テスト URL に対応する DNS エントリが見つかりませんでした。原因としては、テスト URL の誤構成や DNS エントリの誤構成が考えられます。 -`INVALID_REQUEST` +`INVALID_REQUEST` : テストのコンフィギュレーションが無効です (URL に入力ミスがあるなど)。 `TIMEOUT` @@ -132,11 +142,7 @@ DNS テストの URL、高度なオプション、アサーションで、[**Set ### アクセス制限 -アカウントに[カスタムロール][12]を使用しているお客様は、アクセス制限が利用可能です。 - -組織内の役割に基づいて、DNS テストへのアクセスを制限することができます。DNS テストを作成する際に、(ユーザーのほかに) どのロールがテストの読み取りと書き込みを行えるかを選択します。 - -{{< img src="synthetics/settings/restrict_access_1.png" alt="テストの権限の設定" style="width:70%;" >}} +{{% synthetics_grace_permissions %}} ## その他の参考資料 @@ -152,5 +158,4 @@ DNS テストの URL、高度なオプション、アサーションで、[**Set [8]: /ja/synthetics/guide/synthetic-test-monitors [9]: /ja/synthetics/settings/#global-variables [10]: /ja/account_management/rbac/ -[11]: /ja/account_management/rbac#custom-roles -[12]: /ja/account_management/rbac/#create-a-custom-role \ No newline at end of file +[11]: /ja/account_management/rbac#custom-roles \ No newline at end of file diff --git a/content/ja/synthetics/browser_tests/app-that-requires-login.md b/content/ja/synthetics/browser_tests/app-that-requires-login.md new file mode 100644 index 0000000000000..6ab48bb0d5ab3 --- /dev/null +++ b/content/ja/synthetics/browser_tests/app-that-requires-login.md @@ -0,0 +1,113 @@ +--- +aliases: +- /ja/synthetics/guide/app-that-requires-login +description: Synthetic ブラウザテストでアプリケーションにログインできるようにする方法について説明します。 +further_reading: +- link: https://www.datadoghq.com/blog/test-creation-best-practices/ + tag: ブログ + text: エンドツーエンドテスト作成のベストプラクティス +- link: /synthetics/guide/browser-tests-totp + tag: ドキュメント + text: ブラウザテストにおける多要素認証 (MFA) 用 TOTP +- link: /synthetics/guide/browser-tests-passkeys + tag: ドキュメント + text: ブラウザテストのパスキーについて +- link: /synthetics/browser_tests/actions + tag: ドキュメント + text: ブラウザテストステップについて +title: Browser Testing で認証が必要なアプリケーションを監視 +--- + +## 概要 + +
MFA が有効なアプリケーションのテストに興味がある場合は、Multi-factor authentication セクション を参照してください。
+ +ログイン後に配置されているユーザージャーニーを監視する必要がある場合、Datadog のブラウザテストでアプリケーションのログイン手順を実行しログイン後のページ検証を実行するには 2 つの方法があります。 + +- [ブラウザテストの記録にログイン手順を含める](#include-the-login-steps-in-your-recording) +- [ブラウザテストの高度なオプションを活用する](#leverage-browser-test-configuration-options) + +認証情報をアプリケーション全体で確実に難読化し安全に保存するには、[難読化されたグローバル変数](#account-security)を使用します。 + +## 記録にログイン手順を含める + +1 つ目は、ログインの実行に必要な手順をブラウザテストの初めに記録（ユーザー名とパスワードを入力してログインボタンをクリック）する方法です。それから、[後続ステップの記録を開始][1]します。 +テストの実行時、ブラウザテストで初めのログイン手順が体系的にまず実行され、その後のジャーニーへと進みます。 + +{{< img src="synthetics/guide/app_that_requires_login/login_test_2.mp4" video="true" alt="ログインを記録するデモ">}} + +デフォルトでは、レコーダーの iframe/ポップアップは独自のブラウザを使用します。すでにアプリケーションにログインした状態で記録を始めた場合、iframe/ポップアップがログイン後のページを直接表示する可能性があり、ログアウトしないとログイン手順を記録できなくなります。 + +アプリケーションからログアウトせずに手順を記録するには、レコーダーの**シークレットモード**を使用します。 + +{{< img src="synthetics/guide/app_that_requires_login/incognito_2.mp4" video="true" alt="シークレット モードでログインを記録するデモ">}} + +シークレットモードでポップアップを開くと、独自のブラウザのメインセッションとユーザーデータから完全に分離されたセッションで、テストコンフィギュレーションに設定された開始 URL からテストの記録を開始できます。新しく開いたシークレットポップアップは、以前のブラウザ履歴 (Cookie やローカルデータなど) をすべて無視します。アカウントから自動的にログアウトされ、初めてウェブサイトにアクセスした場合と同じようにログイン手順の記録を開始できます。 + +**注:** 今後、ログインが必要な他のブラウザテストに再利用できるよう、ログイン手順を単一のサブテストにグループ化するには、[サブテスト機能][2]を使用します。 + +### SSO ログイン + +SSO を使用してログインするウェブサイトの場合は、ブラウザテストの最初の URL としてアプリケーションの URL を入力します。テストで、デフォルトの最初の **Navigate to URL** 手順の一部として必要な再ダイレクトが実行されます。 + +一部の SSO プロバイダーでは、Datadog のブラウザテストがボットと認識され、ログインできない場合があります（例: reCAPTCHA の追加）。このような場合、[Synthetic ブラウザテストからのリクエストの検出][3]時 (特定の認証情報、Synthetic テスト固有のヘッダーなど) には、テストの目的のためボット検出機能を無効化することが可能かどうか、SSO プロバイダーにお問い合わせください。 + +その他、SSO 以外のアプローチを使用して通常のユーザー名とパスワードの組み合わせを利用してログインする方法があります。 + +### パスキー +Datadog Synthetic モニタリングは、フィッシングやあらゆる形態のパスワード盗難、リプレイ攻撃のリスクを排除するセキュリティ手法である[パスキー][4]をサポートしています。 + +Virtual Authenticator グローバル変数を作成し、テストにインポートします。次に、ブラウザ内でパスキーに関連するステップを記録します。 + +### 多要素認証 + +Datadog Synthetic モニタリングは、[Time-based One Time Passwords (TOTP)][5] をサポートしています。これは、秘密鍵と現在時刻を組み合わせてワンタイムパスワードを生成する多要素認証方法です。 + +ブラウザテストでは、通常のユーザーがブラウザ内で実行するすべてのアクションを再現できます。テストを設定するときは、ブラウザ内で多要素 (2FA または TFA を含む) 認証手順を記録します。 + +一部の MFA プロバイダーでは、Datadog のブラウザテストがボットと認識され、ログインできない場合があります（例: reCAPTCHA の追加）。このような場合、[Synthetic ブラウザテストからのリクエストの検出][3]時 (特定の認証情報、Synthetic テスト固有のヘッダーなど) には、ボット検出機能を無効化することが可能かどうか、MFA プロバイダーにお問い合わせください。 + +MFA プロセスに、ブラウザ外で実行される手順 (音声およびテキストメッセージの送信や TOTP を利用しないモバイルアプリケーションを開くなど) が含まれる場合、[Synthetic ブラウザテストからのリクエストの検出][3]時 (特定の認証情報、Synthetic テスト固有のヘッダーなど) には、テストの目的のため MFA 設定の変更または MFA の無効化が可能かどうか、MFA プロバイダーにお問い合わせください。 +アプリケーションにより利用される MFA のタイプによっては、[JavaScript 手順][6]が有効な場合があります。 + +
Datadog では、テストシナリオをより簡単に記録できるよう、常に機能が追加されています。最も重要な MFA システムについて、ぜひご意見をお聞かせください。
+ +## ブラウザテストのコンフィギュレーションオプションを活用する + +Datadog のブラウザテストがアプリケーションにログインできるようにする 2 つ目の方法は、利用可能なブラウザテストのコンフィギュレーションを使用することです。以下を適用することを設定できます。 + +- 特定のヘッダー +- Cookie +- 基本認証、ダイジェスト認証、または NTLM 資格情報 + +これらのコンフィギュレーションオプションは、テストの実行ごとに設定され、記録時間ではなく、実行時にブラウザテストのすべてのステップに適用されます。 + +記録元のページにこれらの構成済みヘッダー、Cookie、および資格情報を手動で適用してから、テストがログイン後に実行するステップを記録できます。デフォルトでは、ブラウザテストは、実行時に指定されたヘッダー、Cookie、または資格情報を使用した認証を自動的に通過し、記録されたすべてのステップを実行します。 + +{{< img src="synthetics/guide/app_that_requires_login/bt_adv_options.jpg" alt="ブラウザテストのコンフィギュレーションオプションでアプリにログイン">}} + +## アカウントのセキュリティ + +### 認証データの安全性を確保 + +資格情報を[グローバル変数][7]として保存し (例えば、ユーザー名用のグローバル変数とパスワード用のグローバル変数)、**Hide and obfuscate variable value** を選択してテスト結果からその値を隠します。Datadog のインスタンスにアクセスできる個人に対して、ブラウザテストの権限を制限することができます。 + +難読化された変数を作成したら、ブラウザテストに[そのグローバル変数をインポート][8]して、ログイン手順に利用します。 + +**注:** Datadog のグローバル変数は安全に保存され暗号化されますが、テストの一般的なベストプラクティスとして、ダミーの資格情報に紐づけられたテスト用のアカウントを使用することを強くお勧めします。 + +アカウントセキュリティについては、[Synthetic モニタリングのデータセキュリティ][9]を参照してください。 + +## その他の参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ja/synthetics/browser_tests/actions/ +[2]: /ja/synthetics/browser_tests/actions/#subtests +[3]: /ja/synthetics/guide/identify_synthetics_bots/ +[4]: /ja/synthetics/guide/browser-tests-passkeys +[5]: /ja/synthetics/guide/browser-tests-totp +[6]: /ja/synthetics/browser_tests/actions/#test-your-ui-with-custom-javascript +[7]: /ja/synthetics/settings/?tab=specifyvalue#global-variables +[8]: /ja/synthetics/browser_tests/actions#a-global-variable +[9]: /ja/data_security/synthetics \ No newline at end of file diff --git a/content/ja/synthetics/guide/http-tests-with-hmac.md b/content/ja/synthetics/guide/http-tests-with-hmac.md new file mode 100644 index 0000000000000..aea0759c0720b --- /dev/null +++ b/content/ja/synthetics/guide/http-tests-with-hmac.md @@ -0,0 +1,109 @@ +--- +description: HMAC を使用した HTTP テストの作成方法をご紹介します。 +further_reading: +- link: /synthetics/api_tests/http_tests + tag: ドキュメント + text: HTTP テストについて +- link: /synthetics/api_tests/http_tests#variables + tag: ドキュメント + text: Synthetic テスト変数について +title: HMAC 認証を使った HTTP テストの作成 +--- + +## 概要 + +Synthetic モニタリングでは、JavaScript のスクリプトから変数を生成できるので、カスタム認証を定義したり、パラメーターをエンコードしたりすることができます。 + +{{< img src="synthetics/guide/http-tests-with-hmac/test_with_hmac_authentication.png" alt="HMAC 認証を使った HTTP テスト" style="width:100%;" >}} + +このガイドでは、スクリプトの変数を使用して、HMAC 署名付きの HTTP テストを作成する方法を説明します。 + +**注**: 標準的な HMAC 認証は存在しないため、実際にご利用になる HMAC 認証は若干異なる可能性があります。例えば、使用するヘッダー名が異なる場合があります。 + +## セットアップ + +### ローカル変数を使って HMAC 認証の構成要素を作成する + +[Synthetic HTTP テスト][3]を作成し、**Create a Local Variable** をクリックして、以下の変数を追加します。 + +`MY_SECRET_KEY` +: メッセージの署名に使用される UTF-8 でエンコードされた鍵 ([グローバル変数][4]からインポートすることも可能)。 + +`BODY` +: リクエストの本文 (**Request Body** に設定)で、HMAC 認証の計算処理に使用されます。 + +`DATETIME` +: HMAC 署名を計算するためのパラメーター。[ローカル変数][1]として作成するか、`dd.variable.set('DATETIME', new Date().toISOString())` を使って[スクリプトからの変数](#compute-the-hmac-signature-with-javascript)内で作成してエクスポートすることができます。 + +### テスト URL とリクエスト本文の定義 + +HTTP テストの URL とリクエストタイプを定義します。次に、**Advanced Options** > **Request Body** をクリックして、変数 `{{ BODY }}` をリクエスト本文として追加します。 + +{{< img src="synthetics/guide/http-tests-with-hmac/request_body.png" alt="HTTP テストのリクエスト本文として設定されたローカル変数" style="width:80%;" >}} + +### JavaScript で HMAC 署名を計算する + +**Variable From Script** をクリックして、HTTP リクエストの HMAC 署名を生成します。 + +{{< img src="synthetics/guide/http-tests-with-hmac/variables_from_script.png" alt="JavaScript で生成されたローカル変数" style="width:80%;" >}} + +* 変数をスクリプトにインポートするには、`dd.variable.get("")` を使用します。 +* 変数を定義するには、`dd.variable.set("", )` または`dd.variable.setObfuscated("", )` を使用します。 + +また、以下のようなヘルパー関数にもアクセス可能です。 +* [`std` ライブラリ][5]の大部分は、`std.*` でアクセスできます。例えば、`@std/encoding/hex.ts` で定義されている関数 `encodeHex` を呼び出すには、`std.encoding.hex.encodeHex` を使用します。 +* [Web Crypto API][6] などの標準的な JavaScript API。 + +**注***: これらの API の一部はセキュリティ上の理由で無効になっています。 + +例: + +{{< code-block lang="JavaScript" filename="Variable from Script" collapsible="true" >}} +const datetime = new Date().toISOString(); +// "日付" の HTTP ヘッダーを設定し、DATETIME を UI におけるその値として使用します +dd.variable.set("DATETIME", datetime); + +const message = "Hello, World!"; +// BODY を UI におけるリクエスト本文として使用します +dd.variable.set("BODY", message); + +const secretKeyUtf8 = dd.variable.get("MY_SECRET_KEY"); +const key = await crypto.subtle.importKey( + "raw", + new TextEncoder().encode(secretKeyUtf8), + { name: "HMAC", hash: "SHA-256" }, + false, + ["sign"] +); + +const rawSignature = await crypto.subtle.sign( + { name: "HMAC" }, + key, + new TextEncoder().encode(datetime + "." + message) +); + +// "認証" の HTTP ヘッダーを設定し、SIGNATURE を UI におけるその値として使用します +dd.variable.set("SIGNATURE", std.encoding.hex.encodeHex(rawSignature)); + +// 別の方法: +dd.variable.set("SIGNATURE_BASE64", std.encoding.base64.encode(rawSignature)); +{{< /code-block >}} + +### リクエストヘッダーに HMAC 署名を追加する + +エクスポートされた変数 `SIGNATURE` を使用して、HTTP リクエストヘッダーを構築します。 + +**Request Options** タブで、`Name` を `Authentication` に、`Value` を `{{ SIGNATURE }}` に設定したヘッダーと、`Name` を `Date` に、`Value` を `{{ DATETIME }}` に設定したヘッダーを追加します。`Authorization` など別のヘッダーを定義することもできます。 + +HTTP テストの残りの部分を構成し、**Create** をクリックして保存します。 + +## その他の参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ja/synthetics/api_tests/http_tests/?tab=requestoptions#create-local-variables +[2]: /ja/synthetics/api_tests/http_tests/ +[3]: https://app.datadoghq.com/synthetics/create +[4]: /ja/synthetics/settings/?tab=specifyvalue#global-variables +[5]: https://jsr.io/@std +[6]: https://developer.mozilla.org/en-US/docs/Web/API/Crypto \ No newline at end of file diff --git a/content/ja/synthetics/platform/settings/_index.md b/content/ja/synthetics/platform/settings/_index.md index 375046e340099..5988fe3e79fab 100644 --- a/content/ja/synthetics/platform/settings/_index.md +++ b/content/ja/synthetics/platform/settings/_index.md @@ -49,7 +49,7 @@ title: Synthetic テストおよびモニタリングの設定 #### すべてのテストに対して**使用状況帰属 (usage attribution)** のタグを必須にする -Usage Attribution ページでは、コストや使用状況属性を分解するためのタグを最大 3 つまで設定できます。**Enforce tags for usage attribution on all tests** (すべてのテストに対して使用状況帰属タグを必須にする) を選択すると、Synthetic テストを新規作成または編集する際、構成済みの Usage Attribution タグをすべて入力しなければなりません。この設定が有効な場合、必要なタグがすべて入力されるまでテストを保存できません。 +Usage Attribution ページでは、コストと使用量の属性を分析するために最大 3 つのタグを構成できます。Synthetic テストを作成または編集する際に、ユーザーがすべての構成済み使用量属性タグを入力することを要求するには、**Enforce tags for usage attribution on all tests** (すべてのテストで使用量属性に関するタグを強制する) を選択します。この設定を有効にした場合、ユーザーはすべての必須タグを入力しないとテストを保存できません。 #### すべてのテストに対して必須**モニタータグポリシー**を適用する @@ -127,7 +127,7 @@ Datadog で管理されるすべての場所と、ご使用のアカウントで ### ブラウザテスト用の APM インテグレーション -Datadog の APM インテグレーションヘッダーにより、Datadog はブラウザテストと APM を関連付けることができます。 +Datadog の APM インテグレーションヘッダーにより、Datadog はブラウザテストと APM を関連付けることができます。 APM ヘッダーを送信するエンドポイントを定義するには、**Value** リストに URL を追加します。エンドポイントがトレースされ、許可されている場合、ブラウザテストの結果は自動的にその対応するトレースに結びつけられます。 @@ -231,7 +231,7 @@ APM ヘッダーを送信するエンドポイントを定義するには、**Va [5]: https://www.w3schools.com/xml/xpath_syntax.asp {{% /tab %}} -{{% tab "MFA Token" %}} +{{% tab "MFA Token" %}} テスト内で TOTP を生成・使用するには、グローバル変数を作成し、認証プロバイダーから取得したシークレットキーを入力するか、QR コードをアップロードしてください。**注:** 現在、TOTP では SHA1 ハッシュアルゴリズムのみサポートされています。 @@ -243,6 +243,8 @@ APM ヘッダーを送信するエンドポイントを定義するには、**Va {{< img src="synthetics/guide/browser-tests-totp/new-variable-totp.png" alt="MFA トークンの作成" style="width:100%;" >}} +**注**: お使いの TOTP トークンが Google Authenticator で動作する場合、 Datadog と互換性がある可能性が高いです。一部の QR コードは特定の認証方式に限定されており、プラットフォーム間で動作しない場合があります。互換性を確保するには、標準的な TOTP プロトコルに準拠した QR コードまたはシークレットを使用してください。 + ブラウザテストにおける TOTP ベースの MFA については、[ブラウザテストにおける多要素認証 (MFA) のための TOTP][1] を参照してください。 [1]: /ja/synthetics/guide/browser-tests-totp @@ -278,11 +280,24 @@ Synthetic テストでパスキーを使ってユーザージャーニーを完 ### アクセス制限 -アカウントに[カスタムロール][11]を使用しているお客様は、アクセス制限が可能です。[カスタムロール機能][12]を使用している場合は、`synthetics_global_variable_read` および `synthetics_global_variable_write` 権限を含むカスタムロールにユーザーを追加します。 +ロール、チーム、または個々のユーザーに基づいて、テストへのアクセス権を制限するには[きめ細かなアクセス制御][22]を使用します。 + +1. フォームの権限セクションを開きます。 +2. **Edit Access** をクリックします。 + {{< img src="synthetics/settings/grace_2.png" alt="プライベートロケーションの構成フォームからテストの権限を設定する画面" style="width:100%;" >}} +3. **Restrict Access** をクリックします。 +4. チーム、ロール、またはユーザーを選択します。 +5. **Add** をクリックします。 +6. それぞれに付与するアクセスレベルを選択します。 +7. **Done** をクリックします。 -組織内のロールに基づきグローバル変数へのアクセスを制限できます。グローバル変数を作成する際に、**Permissions settings** で、グローバル変数の読み取りおよび書き込みが可能なロール (ユーザーに加えて) を選択します。 +
注: このプライベートロケーションに対するビューアアクセス権がなくても、そのプライベートロケーションで実行された結果を確認できます。
-{{< img src="synthetics/settings/restrict_access_1.png" alt="グローバル変数へのアクセス制限" style="width:100%;" >}} +| アクセスレベル | GV の値を表示 | GV のメタ データを表示 | テストで GV を使用 | GV の値 / メタ データを編集 | +| ------------ | --------------| ---------------- | -------------- | ----------------------- | +| アクセスなし | | | | | +| ビューア | {{< X >}} | {{< X >}} | {{< X >}} | | +| エディター | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | ## インテグレーション設定 @@ -306,7 +321,7 @@ Datadog がテスト実行から RUM データを収集することを許可す 詳しくは、[RUM とセッションリプレイの確認][14]をご覧ください。 -## その他の参考資料 +## 参考情報 {{< partial name="whats-next/whats-next.html" >}} @@ -330,4 +345,5 @@ Datadog がテスト実行から RUM データを収集することを許可す [18]: /ja/synthetics/mobile_app_testing/settings/ [19]: /ja/synthetics/mobile_app_testing/#use-global-variables [20]: https://app.datadoghq.com/synthetics/settings/default -[21]: https://app.datadoghq.com/monitors/settings/policies \ No newline at end of file +[21]: https://app.datadoghq.com/monitors/settings/policies +[22]: /ja/account_management/rbac/granular_access \ No newline at end of file diff --git a/content/ja/tests/test_impact_analysis/setup/java.md b/content/ja/tests/test_impact_analysis/setup/java.md new file mode 100644 index 0000000000000..c5813f59c07ae --- /dev/null +++ b/content/ja/tests/test_impact_analysis/setup/java.md @@ -0,0 +1,328 @@ +--- +aliases: +- /ja/continuous_integration/intelligent_test_runner/java/ +- /ja/continuous_integration/intelligent_test_runner/setup/java/ +- /ja/intelligent_test_runner/setup/java +code_lang: java +code_lang_weight: 10 +further_reading: +- link: /continuous_integration/tests + tag: ドキュメント + text: テスト結果とパフォーマンスを確認する +- link: /continuous_integration/troubleshooting/ + tag: ドキュメント + text: CI Visibility のトラブルシューティング +title: Java 向け Test Impact Analysis +type: multi-code-lang +--- + +## 互換性 + +Test Impact Analysis は `dd-java-agent >= 1.27.0` でサポートされています。 + +以下のテストフレームワークがサポートされています。 +- JUnit >= 4.10 および >= 5.3 +- TestNG >= 6.4 +- Spock >= 2.0 +- Cucumber >= 5.4.0 +- Karate >= 1.0.0 +- ScalaTest 3.0.8 以上 + +## セットアップ + +### テストの最適化 + +Test Impact Analysis を設定する前に、[Java 向け Test Optimization][1] をセットアップしてください。Agent 経由でデータを報告する場合は、v6.40 以降または v7.40 以降を使用してください。 + +{{% ci-itr-activation-instructions %}} + +## Test Impact Analysis を有効にしてテストを実行する + +設定が完了したら、通常通りテストを実行します。 + +{{< tabs >}} +{{% tab "Gradle" %}} + +{{< code-block lang="shell" >}} +DD_CIVISIBILITY_ENABLED=true \ +DD_ENV=ci \ +DD_SERVICE=my-java-app \ +GRADLE_OPTS=-javaagent:$DD_TRACER_FOLDER/dd-java-agent.jar \ +./gradlew clean test +{{< /code-block >}} + +{{% /tab %}} +{{% tab "Maven" %}} + +{{< code-block lang="shell" >}} +DD_CIVISIBILITY_ENABLED=true \ +DD_ENV=ci \ +DD_SERVICE=my-java-app \ +MAVEN_OPTS=-javaagent:$DD_TRACER_FOLDER/dd-java-agent.jar \ +mvn clean verify +{{< /code-block >}} + +{{% /tab %}} +{{% tab "その他" %}} + +{{< code-block lang="shell" >}} +DD_CIVISIBILITY_ENABLED=true \ +DD_ENV=ci \ +DD_SERVICE=my-java-app \ +JAVA_TOOL_OPTIONS=-javaagent:$DD_TRACER_FOLDER/dd-java-agent.jar \ +// テストを実行 +{{< /code-block >}} + +{{% /tab %}} +{{< /tabs >}} + +## 特定のテストに対するスキップの無効化 + +Test Impact Analysis の動作を上書きし、特定のテストがスキップされないようにできます。これらのテストは unskippable テストと呼ばれます。 + +### テストをスキップできないようにする理由は？ + +Test Impact Analysis はコード カバレッジ データを使用してテストをスキップすべきかどうかを判断します。場合によっては、このデータだけでは判断が不十分なことがあります。 + +例: + +- テキストファイルからデータを読み込むテスト +- テスト対象のコード以外の API とやりとりするテスト (リモートの REST API など) +- テストを unskippable に指定すると、カバレッジ データに関係なく Test Impact Analysis によって常に実行されます。 + +### 互換性 + +スキップできないテストは、以下のバージョンとテストフレームワークでサポートされています。 + +- JUnit >= 4.10 および >= 5.3 +- TestNG >= 6.4 +- Spock >= 2.2 +- Cucumber >= 5.4.0 +- ScalaTest 3.0.8 以上 + +### unskippable テストの指定方法 + +{{< tabs >}} +{{% tab "JUnit 5" %}} + +#### 個別のテスト ケース + +テスト ケースをスキップ不可にするには、JUnit `Tag` 値 `datadog_itr_unskippable` を追加します。 + +```java +import org.junit.jupiter.api.Tag; +import org.junit.jupiter.api.Tags; +import org.junit.jupiter.api.Test; + +public class MyTestSuite { + + @Test + @Tags({@Tag("datadog_itr_unskippable")}) + public void myTest() { + // ... + } +} +``` + +#### テストスイート + +テスト スイートをスキップ不可にするには、JUnit `Tag` 値 `datadog_itr_unskippable` を追加します。 + +スイートがスキップ不可に指定されている場合、そのスイート内のテスト ケースは Test Impact Analysis によりスキップされません。 + +```java +import org.junit.jupiter.api.Tag; +import org.junit.jupiter.api.Tags; +import org.junit.jupiter.api.Test; + +@Tags({@Tag("datadog_itr_unskippable")}) +public class MyTestSuite { + + @Test + public void myTest() { + // ... + } +} +``` + +{{% /tab %}} +{{% tab "JUnit 4" %}} + +#### 個別のテスト ケース + +"テスト ケースをスキップ不可にするには、JUnit `Category` 値 `datadog_itr_unskippable` を追加します。 +すべてのテスト ケースまたはテスト スイートごとに `datadog_itr_unskippable` を作成する必要はありません。プロジェクト 全体で 1 つの Category で十分です。" + +```java +import org.junit.Test; +import org.junit.experimental.categories.Category; + +public class MyTestSuite { + + @Category(datadog_itr_unskippable.class) + @Test + public void myTest() { + // ... + } + + public interface datadog_itr_unskippable {} +} +``` + +#### テストスイート + +"テスト スイートをスキップ不可にするには、JUnit `Tag` 値 `datadog_itr_unskippable` を追加します。 +すべてのテスト ケースまたはテスト スイートごとに `datadog_itr_unskippable` を作成する必要はありません。プロジェクト全体で 1 つの Category で十分です。" + +スイートがスキップ不可に指定されている場合、そのスイート内のテスト ケースは Test Impact Analysis によりスキップされません。 + +```java +import org.junit.Test; +import org.junit.experimental.categories.Category; + +@Category(MyTestSuite.datadog_itr_unskippable.class) +public class MyTestSuite { + + @Test + public void myTest() { + // ... + } + + public interface datadog_itr_unskippable {} +} +``` + +{{% /tab %}} +{{% tab "TestNG" %}} + +#### 個別のテスト ケース + +テスト ケースをスキップ不可にするには、`datadog_itr_unskippable` グループをテスト ケースに追加します。 + +```java +import org.testng.annotations.Test; + +public class MyTestSuite { + + @Test(groups = "datadog_itr_unskippable") + public void myTest() { + // ... + } +} +``` + +#### テストスイート + +テスト スイートをスキップ不可にするには、`datadog_itr_unskippable` グループをテスト スイートに追加します。 + +スイートがスキップ不可に指定されている場合、そのスイート内のテスト ケースは Test Impact Analysis によりスキップされません。 + +```java +import org.testng.annotations.Test; + +@Test(groups = "datadog_itr_unskippable") +public class MyTestSuite { + + @Test + public void myTest() { + // ... + } +} +``` + +{{% /tab %}} +{{% tab "Spock" %}} + +#### 個別のテスト ケース + +テスト ケースをスキップ不可にするには、`spock.lang.Tag` 値 `datadog_itr_unskippable` を追加します。 + +```java +import spock.lang.Specification +import spock.lang.Tag + +class MyTestSuite extends Specification { + + @Tag("datadog_itr_unskippable") + def myTest() { + // ... + } +} +``` + +#### テストスイート + +テスト スイートをスキップ不可にするには、`spock.lang.Tag` 値 `datadog_itr_unskippable` を追加します。 + +スイートがスキップ不可に指定されている場合、そのスイート内のテスト ケースは Test Impact Analysis によりスキップされません。 + +```java +import spock.lang.Specification +import spock.lang.Tag + +@Tag("datadog_itr_unskippable") +class MyTestSuite extends Specification { + + def myTest() { + // ... + } +} +``` + +{{% /tab %}} +{{% tab "Cucumber" %}} + +#### 個別のシナリオ + +Gherkin シナリオをスキップ不可にするには、`datadog_itr_unskippable` タグを追加します。 + +```gherkin +Feature: My Feature + + @datadog_itr_unskippable + Scenario: My Scenario + # ... +``` + +#### 機能 + +Gherkin フィーチャーをスキップ不可にするには、`datadog_itr_unskippable` タグを追加します。 + +フィーチャーがスキップ不可に指定されている場合、そのフィーチャー内のシナリオは Test Impact Analysis によりスキップされません。 + +```gherkin +@datadog_itr_unskippable +Feature: My Feature + + Scenario: My Scenario + # ... +``` + +{{% /tab %}} +{{% tab "ScalaTest" %}} + +`datadog_itr_unskippable` 値を持つ `Tag` を作成し、それをテスト ケースに付与します。 + +```scala +import org.scalatest.Tag +import org.scalatest.flatspec.AnyFlatSpec + +object ItrUnskippableTag extends Tag("datadog_itr_unskippable") + +class MyTestSuite extends AnyFlatSpec { + "myTest" should "assert something" taggedAs ItrUnskippableTag in { + // ... + } +} +``` + +{{% /tab %}} +{{< /tabs >}} + + +## その他の参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ja/continuous_integration/tests/java +[2]: https://www.jacoco.org/jacoco/ \ No newline at end of file diff --git a/content/ja/tracing/guide/apm_dashboard.md b/content/ja/tracing/guide/apm_dashboard.md index 2ac154f57825f..9f209a478b085 100644 --- a/content/ja/tracing/guide/apm_dashboard.md +++ b/content/ja/tracing/guide/apm_dashboard.md @@ -29,7 +29,7 @@ Datadog APM では、ビジネスの優先順位と重要なメトリクスに * 手動で作成する。_（ステップ 4.、5.）_ * Analytics クエリをエクスポートする。_（ステップ 7.）_ -1. **[サービスカタログ][1]を開き**、`web-store` サービスを選択します。 +1. **[ソフトウェアカタログ][1]を開き**、`web-store` サービスを選択します。 2. **Total Requests グラフを見つけ**、右上の `export` ボタンをクリックして `Export to Dashboard` を選択します。**`New Timeboard` をクリックします**。 diff --git a/content/ja/tracing/guide/latency_investigator.md b/content/ja/tracing/guide/latency_investigator.md new file mode 100644 index 0000000000000..048d302a1bfd6 --- /dev/null +++ b/content/ja/tracing/guide/latency_investigator.md @@ -0,0 +1,116 @@ +--- +further_reading: +- link: /tracing/ + tag: ドキュメント + text: Datadog APM +private: true +title: APM Investigator +--- + +{{< callout url="" btn_hidden="true" header="プレビューへのアクセスをリクエスト!" >}} +APM Investigator はプレビュー版です。アクセスをリクエストするには、Datadog サポートにお問い合わせください。 +{{< /callout >}} + +## 概要 + +APM Investigator は、ガイド付きのステップ バイ ステップ ワークフローによってアプリケーションのレイテンシー問題を診断・解決するのに役立ちます。分析ツールを 1 つのインターフェイスに統合し、根本原因を特定して対応できます。 + +{{< img src="tracing/guide/apm_investigator/apm_investigator.png" alt="APM Investigator の UI" style="width:90%;">}} + +## 主な機能 + +APM Investigator では、次のことが可能です: + +- **遅いリクエスト クラスターを調査**: レイテンシー スキャッター プロットから問題のあるリクエストを直接選択します。 +- **レイテンシーの発生源を特定**: レイテンシーが自サービス、ダウンストリーム 依存関係、データベース、サード パーティ API のどこから発生しているかを判定します。 +- **範囲を絞り込む**: [タグ分析][1] を使用して、特定のデータ センター、クラスター、ユーザー セグメントに問題を絞り込みます。 +- **根本原因を発見**: 不具合のあるデプロイ、データベース遅延、サード パーティ サービスの障害、インフラストラクチャーの問題、サービス レベルの問題を検出します。 + +## 調査の開始 + +APM サービス ページまたはリソース ページから調査を開始します。 + +1. レイテンシー問題を示しているサービスに移動します。 +2. 異常を示す **Latency** グラフを見つけます。 +3. グラフにカーソルを合わせて **Investigate** をクリックします。これで調査用のサイド パネルが開きます。 + + +{{< img src="tracing/guide/apm_investigator/apm_investigator_entrypoint.png" alt="APM Investigator のエントリポイント" style="width:90%;">}} + +## 調査ワークフロー + +### コンテキストを定義: 遅いスパンと正常なスパンを選択 + +レイテンシー分析を開始するには、ポイント プロットで 2 つのゾーンを選択します: + +- **Slow**: 問題のある遅いスパン +- **Normal**: ベースラインとなる正常なスパン + +
Watchdog が検出したレイテンシー異常はあらかじめ選択されています。
+ +{{< img src="tracing/guide/apm_investigator/latency_selection.png" alt="ポイント プロットでの遅いスパンの選択" style="width:90%;">}} + +この遅いスパンと正常なスパンの比較により、その後のすべての分析が実行されます。 + +### ステップ 1: レイテンシーのボトルネックを特定 + +インベスティゲーターは、レイテンシーが自サービスか、そのダウンストリーム 依存関係 (サービス、データベース、サード パーティ API) のどこから発生しているかを識別します。 + +**分析アプローチ**: +インベスティゲーターは、選択した遅い期間と正常な期間のトレース データを比較します。レイテンシー増加の原因となったサービスを特定するため、次の 2 点を比較します: + +**実行時間**: それぞれのサービスの「self‑time」(ダウンストリーム 依存関係の待機時間を除いた自己処理時間) を 2 つのデータ セット間で比較します。最も絶対的にレイテンシーが増加したサービスが主な注目対象となります。 +- **サービス間の呼び出しパターン**: サービス間のリクエスト数の変化を解析します。たとえば、サービス Y からダウンストリーム サービス X への呼び出しが大幅に増加している場合、インベスティゲーターは Y をボトルネックと判断する可能性があります。 + +この総合的な分析に基づき、インベスティゲーターはレイテンシー ボトルネックとなり得るサービスを推奨します。ボトルネック セクションを展開すると、遅いトレースと正常なトレースの比較詳細を確認できます。テーブルには、サービスごとの self‑time の変化とインバウンド リクエスト数の変化が表示されます。 + +次の例は、遅いトレースと正常なトレースを並べて比較する 2 つのフレーム グラフを示しています。矢印で例示トレースを切り替え、**View** をクリックするとフル ページ ビューでトレースを開けます。 + +{{< img src="tracing/guide/apm_investigator/latency_bottleneck.png" alt="レイテンシー ボトルネック セクション" style="width:100%;">}} + +サービスの最近の変更を調査するには、行にカーソルを合わせたときに表示される `+` アイコンをクリックし、調査のコンテキストとして追加します。 + +### ステップ 2: 最近の変更と相関付け + +インベスティゲーターは、サービスまたはレイテンシー ボトルネック サービスでの最近のデプロイがレイテンシー増加を引き起こしたかどうかを判断するのに役立ちます。 + +**Recent changes** セクションには次が表示されます: +- [変更トラッキング][2] ウィジェットで、レイテンシー スパイクのタイムライン付近に発生したデプロイ +- バージョン別に分解されたレイテンシー グラフ + +{{< img src="tracing/guide/apm_investigator/recent_changes.png" alt="最近の変更" style="width:80%;">}} + +**分析アプローチ**: +APM Investigator は、このデータをバックグラウンドで解析し、レイテンシー増加のタイミングでデプロイが発生している場合に、このセクションを確認すべきかどうかをフラグ付けします。 + +### ステップ 3: Tag Analysis で共通パターンを発見 + +インベスティゲーターは、[タグ分析][1] を活用して、遅いトレースと正常なトレースを区別する共通属性を見つけるのにも役立ちます。Tag Analysis は、遅いデータ セットと正常なデータ セットの間で分布が大きく異なるディメンションをハイライトします。 + +{{< img src="tracing/guide/apm_investigator/tag_analysis.png" alt="遅いトレースに共通するパターン" style="width:80%;">}} + +このセクションでは次が表示されます: +- すべてのスパン ディメンションにわたる、遅いデータ セットと正常なデータ セットのタグ分布 +- `org_id`, `kubernetes_cluster`, `datacenter.name` など、レイテンシー問題の理解に役立つ可能性が高い、最も判別力の高いディメンションのハイライト + +APM Investigator は、ディメンションに顕著な差が見られる場合にのみ、このセクションを表示します。 + +### エンド ユーザーへの影響 + +ポイント プロットの上部には、問題の影響を受けたエンド ユーザー数、アカウント、およびアプリケーション ページ (例: `/checkout`) のプレビューが表示されます。この情報は、[RUM とトレース][3] の接続を有効にしている場合に収集されます。 + +{{< img src="tracing/guide/apm_investigator/end_user_impact.png" alt="エンド ユーザーへの影響" style="width:80%;">}} + +### 根本原因 + +インベスティゲーターは、すべての分析ステップ (レイテンシー ボトルネック、最近の変更、タグ分析) の結果を統合し、根本原因の仮説を生成します。例: 「このダウンストリーム サービスのデプロイによりレイテンシーが増加した」。 + +APM Investigator は、トレースと変更データを自動解析して、問題の診断と対応を迅速化し、**Mean Time to Resolution (MTTR)** を短縮するのに役立ちます。 + +## 参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ja/tracing/trace_explorer/tag_analysis +[2]: /ja/change_tracking/ +[3]: /ja/tracing/other_telemetry/rum/ \ No newline at end of file diff --git a/content/ja/tracing/guide/monitor-kafka-queues.md b/content/ja/tracing/guide/monitor-kafka-queues.md index b6f8ae5512029..f12ccfc09e87c 100644 --- a/content/ja/tracing/guide/monitor-kafka-queues.md +++ b/content/ja/tracing/guide/monitor-kafka-queues.md @@ -26,7 +26,7 @@ title: Kafka キューの監視 [Datadog Data Streams Monitoring][3] は、パイプラインの健全性と、システムを通過するイベントのエンドツーエンドのレイテンシーを測定するための標準的な方法を提供します。Data Streams Monitoring が提供する深い可視性により、パイプラインの遅延や遅れを引き起こしている不良のプロデューサー、コンシューマー、またはキューを正確に特定することが可能になります。ブロックされたメッセージ、ホットパーティション、オフラインのコンシューマーなど、デバッグが困難なパイプラインの問題を発見することができます。また、関連するインフラストラクチャーやアプリのチーム間でシームレスに連携することができます。 -{{< img src="tracing/guide/monitor_kafka_queues/dash-2022-data-streams-compressed-blurb2.mp4" alt="Data Streams Monitoring Demo" video="true">}} +{{< img src="tracing/guide/monitor_kafka_queues/dash-2022-data-streams-compressed-blurb2.mp4" alt="Data Streams Monitoring のデモ" video="true">}} ### 分散型トレース @@ -78,7 +78,7 @@ Kafka アプリケーションをトレースするために、Datadog は Kafka {{% tab "Java" %}} -See [Java's tracer documentation][7] for configuration of Kafka. +Kafka の設定については、[Java の tracer ドキュメント][7] を参照してください。 [7]: /ja/tracing/trace_collection/compatibility/java/#networking-framework-compatibility @@ -86,11 +86,11 @@ See [Java's tracer documentation][7] for configuration of Kafka. {{% tab ".NET" %}} -The [Kafka .NET Client documentation][9] states that a typical Kafka consumer application is centered around a consume loop, which repeatedly calls the Consume method to retrieve records one-by-one. The `Consume` method polls the system for messages. Thus, by default, the consumer span is created when a message is returned and closed before consuming the next message. The span duration is then representative of the computation between one message consumption and the next. +[Kafka .NET Client ドキュメント][9] によると、典型的な Kafka コンシューマー アプリケーションは Consume ループを中心とし、Consume メソッドを繰り返し呼び出してレコードを 1 つずつ取得します。`Consume` メソッドはシステムからメッセージをポーリングします。したがってデフォルトでは、コンシューマー スパンはメッセージが返されたときに作成され、次のメッセージを消費する前に終了します。スパンの長さは、あるメッセージを消費してから次のメッセージを消費するまでの処理時間を表します。 -When a message is not processed completely before consuming the next one, or when multiple messages are consumed at once, you can set `DD_TRACE_KAFKA_CREATE_CONSUMER_SCOPE_ENABLED` to `false` in your consuming application. When this setting is `false`, the consumer span is created and immediately closed. If you have child spans to trace, follow [the headers extraction and injection documentation for .NET custom instrumentation][10] to extract the trace context. +メッセージを完全に処理し終わる前に次のメッセージを消費する場合、または複数のメッセージを一度に消費する場合、あるいは複数のメッセージを一度に消費する場合、消費するアプリケーションで `DD_TRACE_KAFKA_CREATE_CONSUMER_SCOPE_ENABLED` を `false` に設定することができます。この設定が `false` の場合、コンシューマースパンが作成され、すぐに閉じられます。トレースする子スパンがある場合は、[.NET カスタムインストルメンテーションのヘッダー抽出と挿入のドキュメント][10]に従って、トレースコンテキストを抽出してください。 -The .NET tracer allows tracing Confluent.Kafka since [v1.27.0][11]. The trace context propagation API is available since [v2.7.0][12]. +.NET トレーサーは [v1.27.0][11] から Confluent.Kafka をトレースできるようになりました。トレース コンテキスト伝搬 API は [v2.7.0][12] から利用可能です。 [9]: https://docs.confluent.io/kafka-clients/dotnet/current/overview.html#the-consume-loop [10]: /ja/tracing/trace_collection/custom_instrumentation/dotnet/#headers-extraction-and-injection @@ -101,7 +101,7 @@ The .NET tracer allows tracing Confluent.Kafka since [v1.27.0][11]. The trace co {{% tab "Ruby" %}} -The Kafka integration provides tracing of the `ruby-kafka` gem. Follow [Ruby's tracer documentation][8] to enable it. +Kafka インテグレーションでは、`ruby-kafka` gem のトレーシング機能を提供しています。[Ruby のトレーサー ドキュメント][8] に従って有効化してください。 [8]: /ja/tracing/trace_collection/dd_libraries/ruby/#kafka @@ -111,7 +111,7 @@ The Kafka integration provides tracing of the `ruby-kafka` gem. Follow [Ruby's t ### Kafka のトレースを無効にする -If you want to disable Kafka tracing on an application, set the appropriate [language-specific configuration][6]. +アプリケーションで Kafka トレーシングを無効にする場合は、該当する [言語固有の構成][6] を設定してください。 ## 参考資料 diff --git a/content/ja/tracing/guide/tutorial-enable-java-aws-ecs-ec2.md b/content/ja/tracing/guide/tutorial-enable-java-aws-ecs-ec2.md index d3d52e4e5380b..e3af0ad38cffa 100644 --- a/content/ja/tracing/guide/tutorial-enable-java-aws-ecs-ec2.md +++ b/content/ja/tracing/guide/tutorial-enable-java-aws-ecs-ec2.md @@ -20,7 +20,7 @@ title: チュートリアル - EC2 を使用した Amazon ECS 上の Java アプ ## 概要 -This tutorial walks you through the steps for enabling tracing on a sample Java application installed in a cluster on AWS Elastic Container Service (ECS). In this scenario, the Datadog Agent is also installed in the cluster. +このチュートリアルでは、AWS Elastic Container Service (ECS) 上のクラスターにインストールされたサンプル Java アプリケーションでトレースを有効にするための手順を説明します。このシナリオでは、Datadog Agent もクラスターにインストールされています。 ホスト、コンテナ、クラウドインフラストラクチャー、他の言語で書かれたアプリケーションなど、他のシナリオについては、他の[トレース有効化のチュートリアル][1]を参照してください。例えば、コンテナや EKS を使用したチュートリアルの中には、Datadog で見られる自動インスツルメンテーションとカスタムインスツルメンテーションの違いを説明するものがあります。このチュートリアルでは、完全にカスタムインスツルメンテーションされた例までスキップします。 @@ -46,11 +46,11 @@ Java の一般的なトレース設定ドキュメントについては、[Java git clone https://github.com/DataDog/apm-tutorial-java-host.git {{< /code-block >}} -The repository contains a multi-service Java application pre-configured to run inside Docker containers. The `docker-compose` YAML files to make the containers are located in the `docker` directory. This tutorial uses the `service-docker-compose-ECS.yaml` file, which builds containers for the application. +リポジトリには、Docker コンテナ内で動作するようにあらかじめ構成されたマルチサービスの Java アプリが含まれています。コンテナを作成するための `docker-compose` YAML ファイルは `docker` ディレクトリに配置されています。このチュートリアルでは、アプリケーション用のコンテナをビルドする `service-docker-compose-ECS.yaml` ファイルを使用します。 `notes` と `calendar` の各ディレクトリには、アプリケーションをビルドするための Dockerfile が、Maven と Gradle の 2 つのセットで用意されています。このチュートリアルでは Maven を使用しますが、Gradle に慣れている場合は、ビルドコマンドを変更することで、Maven の代わりに Gradle を使用することができます。 -The sample application is a simple multi-service Java application with two APIs, one for a `notes` service and another for a `calendar` service. The `notes` service has `GET`, `POST`, `PUT`, and `DELETE` endpoints for notes stored within an in-memory H2 database. The `calendar` service can take a request and return a random date to be used in a note. Both applications have their own associated Docker images, and you deploy them on Amazon ECS as separate services, each with its own tasks and respective containers. ECS pulls the images from ECR, a repository for application images that you publish the images to after building. +サンプルアプリケーションはシンプルなマルチサービスの Java アプリケーションで、2 つの API (`notes` サービスと `calendar` サービス) を備えています。`notes` サービスには、メモリ内 H2 データベースに保存されたノートに対する `GET`、`POST`、`PUT`、`DELETE` のエンドポイントがあります。`calendar` サービスはリクエストを受け、ノートで使用するランダムな日付を返します。両方のアプリケーションには、それぞれ関連する Docker イメージがあり、Amazon ECS に別々のサービスとして、それぞれ独自のタスクとそれぞれのコンテナを持ってデプロイします。ECS は、ビルド後にイメージを公開するアプリケーションイメージのリポジトリである ECR からイメージを取得します。 ### ECS の初期設定 @@ -106,7 +106,7 @@ docker push :calendar{{< /code-block >}} アプリケーションを起動し、トレースせずにいくつかのリクエストを送信します。アプリケーションがどのように動作するかを確認した後、トレーシングライブラリと Datadog Agent を使用してインスツルメントを行います。 -To start, use a terraform script to deploy to Amazon ECS: +まずは、Terraform スクリプトを使用して Amazon ECS にデプロイします。 1. `terraform/EC2/deployment` ディレクトリで、以下のコマンドを実行します。 @@ -175,7 +175,7 @@ Java アプリケーションが動作するようになったので、トレー
注: これらのサンプルコマンドのフラグ、特にサンプルレートは、このチュートリアル以外の環境では、必ずしも適切ではありません。実際の環境で何を使うべきかについては、トレース構成を読んでください。
-3. Automatic instrumentation is convenient, but sometimes you want more fine-grained spans. Datadog's Java DD Trace API allows you to specify spans within your code using annotations or code. Add some annotations to the code to trace into some sample methods. +3. 自動インスツルメンテーションは便利ですが、より細かいスパンが欲しい場合もあります。Datadog の Java DD Trace API では、アノテーションやコードを使用してコード内のスパンを指定することができます。コードにアノテーションを追加し、いくつかのサンプルメソッドにトレースします。 `/notes/src/main/java/com/datadog/example/notes/NotesHelper.java` を開きます。このサンプルには、コードにカスタムトレースを設定するさまざまな方法を示す、コメントアウトされたコードがすでに含まれています。 @@ -367,7 +367,7 @@ docker push :calendar{{< /code-block >}} アプリケーションを再デプロイし、API を実行します。 -1. Redeploy the application to Amazon ECS using the [same terraform commands as before](#deploy-the-application). From the `terraform/EC2/deployment` directory, run the following commands: +1. [先ほどと同じ terraform コマンド](#deploy-the-application)を使って、Amazon ECS にアプリケーションを再デプロイしてください。`terraform/EC2/deployment` ディレクトリから、以下のコマンドを実行します。 ```sh terraform init @@ -403,7 +403,7 @@ docker push :calendar{{< /code-block >}} 4. しばらく待って、Datadog の [**APM > Traces**][11] にアクセスすると、API 呼び出しに対応するトレースの一覧が表示されます。 - {{< img src="tracing/guide/tutorials/tutorial-java-container-traces2.png" alt="Traces from the sample app in APM Trace Explorer" style="width:100%;" >}} + {{< img src="tracing/guide/tutorials/tutorial-java-container-traces2.png" alt="APM トレースエクスプローラーのサンプルアプリのトレース" style="width:100%;" >}} `h2` はこのチュートリアルのために埋め込まれたメモリ内データベースで、`notes` は Spring Boot アプリケーションです。トレースリストには、すべてのスパン、いつ開始したか、どのリソースがスパンで追跡されたか、どれくらいの時間がかかったか、が表示されます。 diff --git a/content/ja/tracing/guide/tutorial-enable-java-aws-eks.md b/content/ja/tracing/guide/tutorial-enable-java-aws-eks.md index 53a4b2150750f..30b81510c6515 100644 --- a/content/ja/tracing/guide/tutorial-enable-java-aws-eks.md +++ b/content/ja/tracing/guide/tutorial-enable-java-aws-eks.md @@ -20,7 +20,7 @@ title: チュートリアル - AWS Elastic Kubernetes Service 上の Java アプ ## 概要 -This tutorial walks you through the steps for enabling tracing on a sample Java application installed in a cluster on AWS Elastic Kubernetes Service (EKS). In this scenario, the Datadog Agent is also installed in the cluster. +このチュートリアルでは、AWS Elastic Kubernetes Service (EKS) クラスターにインストールしたサンプルの Java アプリケーションでトレーシングを有効化する手順を説明します。このシナリオでは、Datadog Agent も同じクラスターにインストールされています。 ホスト、コンテナ、他のクラウドインフラストラクチャー、他の言語で書かれたアプリケーションなど、他のシナリオについては、他の[トレース有効化のチュートリアル][1]を参照してください。 @@ -52,7 +52,7 @@ helm repo update{{< /code-block >}} git clone https://github.com/DataDog/apm-tutorial-java-host.git {{< /code-block >}} -The repository contains a multi-service Java application pre-configured to run inside a Kubernetes cluster. The sample app is a basic notes app with a REST API to add and change data. The `docker-compose` YAML files to make the containers for the Kubernetes pods are located in the `docker` directory. This tutorial uses the `service-docker-compose-k8s.yaml` file, which builds containers for the application. +リポジトリには、Kubernetes クラスター内で動作するようにあらかじめ構成されたマルチサービスの Java アプリが含まれています。サンプルアプリは基本的なメモアプリで、データの追加や変更を行うための REST API が用意されています。Kubernetes のポッド用コンテナを作成するための `docker-compose` YAML ファイルは `docker` ディレクトリに配置されています。このチュートリアルでは、アプリケーション用のコンテナをビルドする `service-docker-compose-k8s.yaml` ファイルを使用します。 `notes` と `calendar` の各ディレクトリには、アプリケーションをビルドするための Dockerfile が、Maven と Gradle の 2 つのセットで用意されています。このチュートリアルでは Maven を使用しますが、Gradle に慣れている場合は、ビルドコマンドを変更することで、Maven の代わりに Gradle を使用することができます。 @@ -97,13 +97,13 @@ docker push :notes{{< /code-block >}} ### AWS クラスターのインバウンドセキュリティポリシーの更新 -To communicate with the sample applications, ensure that the cluster's security rules are configured with ports `30080` and `30090` open. +サンプル アプリケーションと通信できるように、クラスターのセキュリティ ルールでポート `30080` と `30090` が開放されていることを確認してください。 -1. Open AWS Console and navigate to your deployed cluster within the EKS service. +1. AWS Console を開き、EKS サービス内でデプロイ済みのクラスターに移動します。 2. クラスターコンソールで、networking タブを選択し、クラスターセキュリティグループをクリックします。 -3. In your security group settings, edit the inbound rules. Add a rule allowing custom TCP traffic, a port range of `30060` to `30100`, and source of `0.0.0.0/0`. +3. セキュリティ グループの設定でインバウンド ルールを編集し、カスタム TCP トラフィックを許可するルールを追加します。ポート範囲を `30060`～`30100`、送信元を `0.0.0.0/0` に設定してください。 4. ルールを保存します。 @@ -244,7 +244,7 @@ helm upgrade -f datadog-values.yaml --install --debug latest --set datadog.apiKe しばらく待って、Datadog の [**APM > Traces**][11] にアクセスすると、API 呼び出しに対応するトレースの一覧が表示されます。 -{{< img src="tracing/guide/tutorials/tutorial-java-container-traces2.png" alt="Traces from the sample app in APM Trace Explorer" style="width:100%;" >}} +{{< img src="tracing/guide/tutorials/tutorial-java-container-traces2.png" alt="APM トレースエクスプローラーのサンプルアプリのトレース" style="width:100%;" >}} `h2` はこのチュートリアルのために埋め込まれたメモリ内データベースで、`notes` は Spring Boot アプリケーションです。トレースリストには、すべてのスパン、いつ開始したか、どのリソースがスパンで追跡されたか、どれくらいの時間がかかったか、が表示されます。 diff --git a/content/ja/tracing/guide/tutorial-enable-java-gke.md b/content/ja/tracing/guide/tutorial-enable-java-gke.md index 82f92ecdf8bfe..fd319ff4a7733 100644 --- a/content/ja/tracing/guide/tutorial-enable-java-gke.md +++ b/content/ja/tracing/guide/tutorial-enable-java-gke.md @@ -20,7 +20,7 @@ title: チュートリアル - Google Kubernetes Engine 上の Java アプリケ ## 概要 -This tutorial walks you through the steps for enabling tracing on a sample Java application installed in a cluster on Google Kubernetes Engine (GKE). In this scenario, the Datadog Agent is also installed in the cluster. +このチュートリアルでは、Google Kubernetes Engine (GKE) 上のクラスターにインストールされたサンプル Java アプリケーションでトレースを有効にするための手順を説明します。このシナリオでは、Datadog Agent もクラスターにインストールされています。 ホスト、コンテナ、他のクラウドインフラストラクチャー、他の言語で書かれたアプリケーションなど、他のシナリオについては、他の[トレース有効化のチュートリアル][1]を参照してください。 @@ -57,7 +57,7 @@ helm repo update{{< /code-block >}} git clone https://github.com/DataDog/apm-tutorial-java-host.git {{< /code-block >}} -The repository contains a multi-service Java application pre-configured to run inside a Kubernetes cluster. The sample app is a basic notes app with a REST API to add and change data. The `docker-compose` YAML files to make the containers for the Kubernetes pods are located in the `docker` directory. This tutorial uses the `service-docker-compose-k8s.yaml` file, which builds containers for the application. +リポジトリには、Kubernetes クラスター内で動作するようにあらかじめ構成されたマルチサービスの Java アプリが含まれています。サンプルアプリは基本的なメモアプリで、データの追加や変更を行うための REST API が用意されています。Kubernetes のポッド用コンテナを作成するための `docker-compose` YAML ファイルは `docker` ディレクトリに配置されています。このチュートリアルでは、アプリケーション用のコンテナをビルドする `service-docker-compose-k8s.yaml` ファイルを使用します。 `notes` と `calendar` の各ディレクトリには、アプリケーションをビルドするための Dockerfile が、Maven と Gradle の 2 つのセットで用意されています。このチュートリアルでは Maven を使用しますが、Gradle に慣れている場合は、ビルドコマンドを変更することで、Maven の代わりに Gradle を使用することができます。 @@ -86,7 +86,7 @@ gcloud config set container/cluster {{< /code-block >}} ### アプリケーションイメージの構築とアップロード -If you're not familiar with Google Container Registry (GCR), it might be helpful to read [Quickstart for Container Registry][16]. +Google Container Registry (GCR) に馴染みがない方は、[Container Registry のクイックスタート][16]を読むとよいかもしれません。 サンプルプロジェクトの `/docker` ディレクトリで、以下のコマンドを実行します。 @@ -244,7 +244,7 @@ helm upgrade -f datadog-values.yaml --install --debug latest --set datadog.apiKe しばらく待って、Datadog の [**APM > Traces**][11] にアクセスすると、API 呼び出しに対応するトレースの一覧が表示されます。 -{{< img src="tracing/guide/tutorials/tutorial-java-container-traces2.png" alt="Traces from the sample app in APM Trace Explorer" style="width:100%;" >}} +{{< img src="tracing/guide/tutorials/tutorial-java-container-traces2.png" alt="APM トレースエクスプローラーのサンプルアプリのトレース" style="width:100%;" >}} `h2` はこのチュートリアルのために埋め込まれたメモリ内データベースで、`notes` は Spring Boot アプリケーションです。トレースリストには、すべてのスパン、いつ開始したか、どのリソースがスパンで追跡されたか、どれくらいの時間がかかったか、が表示されます。 diff --git a/content/ja/tracing/legacy_app_analytics/_index.md b/content/ja/tracing/legacy_app_analytics/_index.md index 102cc4bc6c6c5..9e811eeaf27f5 100644 --- a/content/ja/tracing/legacy_app_analytics/_index.md +++ b/content/ja/tracing/legacy_app_analytics/_index.md @@ -35,7 +35,7 @@ App Analytics は、Java トレースクライアントのバージョン 0.25.0 {{< /programming-lang >}} {{< programming-lang lang="python" >}} -App Analytics は、Python トレースクライアントのバージョン 0.19.0 以降で使用できます。トレースクライアントでコンフィギュレーションパラメーターを 1 つ設定することで、すべての **web** インテグレーションに対して App Analytics をグローバルに有効にできます。 +App Analytics は Python トレーシング クライアント バージョン 0.19.0 以降で利用できます。この構成は ddtrace バージョン 3.x 以前でのみ利用可能です。Tracing Client の 1 つの構成パラメーターで、すべての **web** 統合に対して App Analytics をグローバルに有効化できます: * トレーサー構成: `ddtrace.config.analytics_enabled = True` * @@ -59,7 +59,7 @@ Datadog.configure { |c| c.tracing.analytics.enabled = true } App Analyticsは、Go トレースクライアントのバージョン 1.11.0 以降で使用できます。以下を使用することで、すべての **web** インテグレーションにグローバルに有効化できます: -* [`WithAnalytics`][1] トレーサー開始オプション。例: +* [`WithAnalytics`][2] ([v1 ドキュメント][1]) トレーサー起動オプション。例: ```go tracer.Start(tracer.WithAnalytics(true)) @@ -68,6 +68,7 @@ App Analyticsは、Go トレースクライアントのバージョン 1.11.0 * バージョン 1.26.0 以降は、環境変数 `DD_TRACE_ANALYTICS_ENABLED=true` を使用 [1]: https://pkg.go.dev/gopkg.in/DataDog/dd-trace-go.v1/ddtrace/tracer#WithAnalytics +[2]: https://pkg.go.dev/github.com/DataDog/dd-trace-go/v2/ddtrace/tracer#WithAnalytics {{< /programming-lang >}} {{< programming-lang lang="nodejs" >}} @@ -185,14 +186,16 @@ Datadog.configure { |c| c.tracing.instrument :integration, analytics_enabled: tr {{< /programming-lang >}} {{< programming-lang lang="go" >}} +{{% tracing-go-v2 %}} + グローバル設定に加えて、各インテグレーションで App Analytics を個別に有効または無効にできます。たとえば、標準ライブラリの `net/http` パッケージを構成する場合は、以下のようにします。 -```go +```go package main import ( - httptrace "gopkg.in/DataDog/dd-trace-go.v1/contrib/net/http" - "gopkg.in/DataDog/dd-trace-go.v1/ddtrace/tracer" + httptrace "github.com/DataDog/dd-trace-go/contrib/net/http/v2" + "github.com/DataDog/dd-trace-go/v2/ddtrace/tracer" ) func main() { @@ -200,9 +203,9 @@ func main() { defer tracer.Stop() mux := httptrace.NewServeMux(httptrace.WithAnalytics(true)) - // ... -} -``` + // ... +} +``` {{< /programming-lang >}} {{< programming-lang lang="nodejs" >}} @@ -513,4 +516,4 @@ Agent の APM レート制限を増やすには、Agent のコンフィギュレ [1]: /ja/tracing/trace_pipeline/ingestion_controls/ -[2]: /ja/tracing/trace_pipeline/ingestion_mechanisms/ +[2]: /ja/tracing/trace_pipeline/ingestion_mechanisms/ \ No newline at end of file diff --git a/content/ja/tracing/trace_collection/compatibility/php_v0.md b/content/ja/tracing/trace_collection/compatibility/php_v0.md new file mode 100644 index 0000000000000..79fea1556377c --- /dev/null +++ b/content/ja/tracing/trace_collection/compatibility/php_v0.md @@ -0,0 +1,179 @@ +--- +description: PHP トレーサーの互換性要件です +further_reading: +- link: tracing/trace_collection/dd_libraries/php + tag: ドキュメント + text: アプリケーションのインスツルメンテーション +title: (レガシー) PHP 互換性要件 +--- +
このドキュメントは PHP tracer v0.x 用です。PHP tracer v1.x のドキュメントをお探しの場合は、最新の PHP 互換性要件 のドキュメントをご覧ください。
+ +## PHP APM のランタイムサポートポリシー + +PHP Datadog Trace ライブラリはオープンソースです。詳細については、[GitHub リポジトリ][1]をご覧ください。 + +Datadog APM for PHP は、ホスト OS や PHP ランタイム、特定の PHP ライブラリ、 Datadog Agent や API の特定のバージョンで定義される依存関係に基づいて構築されています。 +これらのバージョンがメンテナによってサポートされなくなった場合、 Datadog APM for PHP はこれらのサポートにも制限をかけます。 + +#### サポートレベル + +| **レベル** | **サポート内容** | +|--------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------| +| 非対応 | 実装していません。[特別なご要望はカスタマーサポートチームにお問い合わせください][2]。 | +| プレビュー | 初期実装です。まだすべての機能が含まれていない可能性があります。新機能のサポート、バグやセキュリティの修正は、ベストエフォートで提供されます。 | +| 一般提供 (GA) | 全機能の完全実装。新機能、バグ、セキュリティフィックスを完全サポート。 | +| メンテナンス | 既存機能の完全実装。新機能は受けません。バグフィックス、セキュリティフィックスのみの対応となります。 | +| レガシー | レガシーな実装。機能は限定されますが、メンテナンスは提供されません。[特別なご要望がある場合は、サポートチームにお問い合わせください。 | +| サポート終了 (EOL) | サポートなし。このバージョンはまだ使用可能ですが、バグ修正は提供されません。 | + + +PHP APM は次の PHP バージョン (ZTS と NTS の両方) をサポートしています: + +
+注: +PHP 5.x はバージョン 0.75.0 まで完全にサポートされています。現在はメンテナンスモードに移行しており、2023 年 12 月 31 日までセキュリティや重要なバグの修正でサポートされています。 +
+もし、アプリケーションで PHP 5.x バージョンを使用していて、ビジネスニーズにとって重要な機能要求がある場合は、Datadog サポートにご連絡ください。 +
+PHP は公式にサポートされているバージョン、特に 7.4、8.0、8.1 を使用することが推奨されています。 +
+ +| PHP バージョン | サポートレベル | パッケージバージョン | +|:------------|:-----------------------------------------|:----------------| +| 8.3.x | プレビュー (正式な PHP リリースまで) | > `0.93.0+` | +| 8.2.x | 一般提供 | > `0.82.0+` | +| 8.1.x | 一般提供 | > `0.66.0+` | +| 8.0.x | 一般提供 | > `0.52.0+` | +| 7.4.x | 一般提供 | All | +| 7.3.x | 一般提供 | All | +| 7.2.x | 一般提供 | All | +| 7.1.x | 一般提供 | All | +| 7.0.x | 一般提供 | All | +| 5.6.x | メンテナンス (2023 年 12 月 31 日まで) | All | +| 5.5.x | メンテナンス (2023 年 12 月 31 日まで) | All | +| 5.4.x | メンテナンス (2023 年 12 月 31 日まで) | All | + +PHP APM は以下の SAPI に対応しています。 + +| SAPI | サポートの種類 | +|:---------------|:----------------| +| apache2handler | 完全対応 | +| cli | 完全対応 | +| fpm-fcgi | 完全対応 | +| cgi-fcgi | 完全対応 | + +## 対応プロセッサアーキテクチャー + +PHP APM は以下のアーキテクチャに対応しています。 + +| プロセッサアーキテクチャー | サポートレベル | パッケージバージョン | サポートの種類 | +|-----------------------------------------|-------------------|---------------|----------------------------| +| Linux GNU amd64 (`x86-64-linux-gnu`) | [GA](#support-ga) | All | サポートされているすべての PHP バージョン | +| Linux MUSL amd64 (`x86-64-linux-musl`) | [GA](#support-ga) | All | サポートされているすべての PHP バージョン | +| Linux GNU arm64 (`aarch64-linux-gnu`) | [GA](#support-ga) | > `0.78.0` | サポートされているすべての PHP バージョン | +| Linux MUSL arm64 (`aarch64-linux-musl`) | [GA](#support-ga) | > `0.78.0` | サポートされているすべての PHP バージョン | +| Windows amd64 (`x86_64-windows`) | [GA](#support-ga) | > `0.98.0` | PHP 7.20 | + +### インテグレーション + +#### Web フレームワークの互換性 + +Datadog はデフォルトで、**すべての PHP Web フレームワークをサポート**し、フレームワークレベルのインスツルメンテーション、または一般的な Web トレースを行うことができます。 + +フレームワークレベルのインスツルメンテーションには、内部メソッドのトレースとフレームワーク固有のタグ付けが含まれます。 + +一般的な Web トレースには、データベースや HTTP クライアントなどのサポートされたライブラリのスパンに加えて、コールから発生したレイテンシーやエラーを追跡するための `web.request` スパンが含まれています。 + +次の表は、Datadog が正常にトレースするフレームワークとバージョンの一部を示しています。 + +**ウェブフレームワーク**: + +| モジュール | バージョン | サポートの種類 | インスツルメンテーションレベル | +|:---------------|:----------------------------------------|:---------------------------|:--------------------------------| +| CakePHP | 2.x, 3.x, 4.x, 5.x | サポートされているすべての PHP バージョン | フレームワークレベルのインスツルメンテーション | +| CodeIgniter | 2.x、3.x | PHP 7+ | フレームワークレベルのインスツルメンテーション | +| Drupal | | サポートされているすべての PHP バージョン | フレームワークレベルのインスツルメンテーション | +| FuelPHP | 1.1 | PHP 7+ | 一般的な Web トレース | +| Laminas | | サポートされているすべての PHP バージョン | フレームワークレベルのインスツルメンテーション | +| Laravel | 4.2、5.x、6.x | サポートされているすべての PHP バージョン | フレームワークレベルのインスツルメンテーション | +| Laravel 8+ | 8.x, 9.x, 10.x, 11.x (tracer `0.52.0+`) | サポートされているすべての PHP バージョン | フレームワークレベルのインスツルメンテーション | +| Lumen | 5.2+ | サポートされているすべての PHP バージョン | フレームワークレベルのインスツルメンテーション | +| Magento | 1 | サポートされているすべての PHP バージョン | 一般的な Web トレース | +| Magento | 2 | PHP 7+ | フレームワークレベルのインスツルメンテーション | +| Neos Flow | 1.1 | サポートされているすべての PHP バージョン | 一般的な Web トレース | +| Phalcon | 1.3、3.4 | サポートされているすべての PHP バージョン | 一般的な Web トレース | +| RoadRunner | 2.x | サポートされているすべての PHP バージョン | フレームワークレベルのインスツルメンテーション | +| Slim | 2.x、3.x、4.x | サポートされているすべての PHP バージョン | フレームワークレベルのインスツルメンテーション | +| Symfony | 2.x, 3.3, 3.4, 4.x, 5.x, 6.x, 7.x | サポートされているすべての PHP バージョン | フレームワークレベルのインスツルメンテーション | +| WordPress | 4.x、5.x、6.x | PHP 7+ | フレームワークレベルのインスツルメンテーション | +| Yii | 1.1、2.0 | サポートされているすべての PHP バージョン | フレームワークレベルのインスツルメンテーション | +| Zend Framework | 1.12, 1.21 | サポートされているすべての PHP バージョン | フレームワークレベルのインスツルメンテーション | +| Zend Framework | 2.x | サポートされているすべての PHP バージョン | 一般的な Web トレース | + +このリストにウェブフレームワークがない場合でも、トレーサーの最新リリースではそのまま使用できます。 + +Datadog は PHP Web フレームワーク用の詳細なトレーシング サポートを継続的に追加しています。追加のスパン メタデータやフレームワーク内部のサポートをリクエストする場合は、当社の素晴らしい [サポート チーム][3] までご連絡ください。 + +#### CLI ライブラリの互換性 + +デフォルトで、CLI SAPI からのトレースは無効になっています。PHP CLI スクリプトのトレースを有効にするには、`DD_TRACE_CLI_ENABLED=true` とします。 + +| モジュール | バージョン | サポートの種類 | +|:----------------|:--------------------|:----------------| +| CakePHP Console | 2.x | 完全対応 | +| Laravel Artisan | 5.x、8.x、9.x、10.x | 完全対応 | +| Symfony CLI | 4.x、5.x、6.x | 完全対応 | + +追加 CLI ライブラリに関するサポートをご希望の場合は、[サポートチーム][3]までお気軽にお問い合わせください。 + +#### データストアの互換性 + +| モジュール | バージョン | サポートの種類 | +|-------------------------------------------------------------------------|----------------------------|-----------------| +| Amazon RDS (PDO または MySQLi 使用) | *(対応する PHP)* | 完全対応 | +| Elasticsearch | 1+ | 完全対応 | +| Eloquent | Laravel 対応バージョン | 完全対応 | +| Laravel Queues | Laravel 対応バージョン | 完全対応 | +| Memcache | *(対応する PHP)* | 完全対応 | +| Memcached | *(対応する PHP)* | 完全対応 | +| MongoDB - [mongo][4] 拡張機能を使用 | 1.4.x | 完全対応 | +| MySQLi | *(対応する PHP)* | 完全対応 | +| PDO | *(対応する PHP)* | 完全対応 | +| PhpRedis | 3、4、5 | PHP 7、8 | +| Predis | 1.1 | 完全対応 | +| SQLSRV | *(対応する PHP)* | 完全対応 | + +追加データストアに関するサポートをご希望の場合は、[サポートチーム][3]までお気軽にお問い合わせください。 + +#### ライブラリの互換性 + +| モジュール | バージョン | サポートの種類 | +|:----------------------------------------------------------|:----------------------|:----------------| +| [php-amqplib][10] | 2.x、3.x | PHP 7.1+ | +| Curl | *(対応する PHP)* | 完全対応 | +| Guzzle | 5.x, 6.x, 7.x | 完全対応 | + + +ライブラリに関するサポートをご希望の場合は、[サポートチーム][3]までお気軽にお問い合わせください。 + +#### PHP 5 の深いコールスタック + +コールスタックは PHP 5 のみに限定されます。詳細は[深いコールスタックのトラブルシューティングページ][5]を参照してください。 + +### ジェネレータ + +[ジェネレータ][6]のインスツルメントは、PHP 5 および PHP 7 ではサポートされていません。 + +### PCNTL + +Datadog は [pcntl][7] を使用したフォーク プロセスのトレーシングをサポートしています。`pcntl_fork` の呼び出しを検出すると、専用のスパンが作成され、フォーク プロセスがインスツルメントされます。これは `DD_TRACE_FORKED_PROCESS` で無効化できます。詳細は [ライブラリ設定ページ][9] を参照してください。 + +アプリケーションが `pcntl_unshare(CLONE_NEWUSER);` を実行し、トレーサーがインストールされている場合、アプリケーションは致命的にクラッシュします。これは、`CLONE_NEWUSER` を持つ `unshare` がプロセスを[スレッド化しない][8]ことを要求し、PHP トレーサーが別スレッドを使用してメインプロセスをブロックせずに Datadog Agent にトレースを送信するために起こります。 + +## その他の参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://github.com/DataDog/dd-trace-php +[2]: https://www.datadoghq.com/support/ +[3]: /ja/help \ No newline at end of file diff --git a/content/ja/tracing/trace_collection/custom_instrumentation/android/_index.md b/content/ja/tracing/trace_collection/custom_instrumentation/android/_index.md new file mode 100644 index 0000000000000..01464ab652a39 --- /dev/null +++ b/content/ja/tracing/trace_collection/custom_instrumentation/android/_index.md @@ -0,0 +1,5 @@ +--- +external_redirect: /tracing/trace_collection/custom_instrumentation/android/otel +title: Android +type: multi-code-lang +--- diff --git a/content/ja/tracing/trace_collection/custom_instrumentation/dotnet/dd-api.md b/content/ja/tracing/trace_collection/custom_instrumentation/dotnet/dd-api.md new file mode 100644 index 0000000000000..64ebb2dc9fcec --- /dev/null +++ b/content/ja/tracing/trace_collection/custom_instrumentation/dotnet/dd-api.md @@ -0,0 +1,235 @@ +--- +aliases: +- /ja/tracing/opentracing/dotnet +- /ja/tracing/manual_instrumentation/dotnet +- /ja/tracing/custom_instrumentation/dotnet +- /ja/tracing/setup_overview/custom_instrumentation/dotnet +- /ja/tracing/trace_collection/custom_instrumentation/dotnet +- /ja/tracing/trace_collection/custom_instrumentation/dd_libraries/dotnet +code_lang: dd-api +code_lang_weight: 1 +description: .NET アプリケーションを手動でインスツルメントしてカスタムトレースを Datadog に送信します。 +further_reading: +- link: tracing/guide/instrument_custom_method + tag: ガイド + text: カスタムメソッドをインスツルメントして、ビジネスロジックを詳細に可視化する +- link: tracing/other_telemetry/connect_logs_and_traces + tag: ドキュメント + text: ログとトレースの接続 +- link: tracing/glossary/ + tag: ドキュメント + text: サービス、リソース、トレースの詳細 +- link: https://github.com/DataDog/dd-trace-dotnet/tree/master/tracer/samples + tag: ソースコード + text: .NET コードサンプル +title: .NET で Datadog API を使用したカスタム インスツルメンテーション +type: multi-code-lang +--- + +
+自動インスツルメンテーションとセットアップの手順をまだ確認していない場合は、まず .NET/.NET Core または .NET Framework のセットアップ手順をご覧ください。 +
+ +このページでは、Datadog APM で可観測性を追加・カスタマイズするための一般的なユースケースを詳しく説明します。サポートされているランタイムの一覧は、[.NET Framework 互換性要件][1]または [.NET Core 互換性要件][2]を参照してください。 + +[デフォルトの自動インスツルメンテーション][3]以上を取得するためには、いくつかの方法があります。 + +- [設定による方法](#instrument-methods-through-configuration) — 特定のタグを追加することはできません。 +- [属性を使用する方法](#instrument-methods-through-attributes) — オペレーション名とリソース名をカスタマイズできます。 +- [カスタム コードを使用する方法](#custom-instrumentation-with-code) — スパンを最も柔軟に制御できます。 + +これらの方法は組み合わせて使用でき、望む詳細レベルのインスツルメンテーションを実現できます。ただし、自動インスツルメンテーションを先に設定する必要があります。 + +## 構成によるインスツルメントメソッド + +環境変数 `DD_TRACE_METHODS` を使用すると、アプリケーションコードを変更せずに、サポートされていないフレームワークを可視化することができます。`DD_TRACE_METHODS` の入力フォーマットの詳細については、[.NET Framework 構成手順][8]または [.NET Core 構成手順][9]を参照してください。例えば、`Store.Managers.SessionManager` 型で定義された `SaveSession` というメソッドをインスツルメンテーションするには、次のように設定します。 + +```ini +DD_TRACE_METHODS=Store.Managers.SessionManager[SaveSession] +``` + +結果として得られるスパンは、`trace.annotation` という値を持つ `operationName` 属性と `SaveSession` という値を持つ `resourceName` 属性を持っています。 + +スパンの属性をカスタマイズしたい場合で、ソースコードを修正する能力がある場合は、代わりに[属性を通してメソッドをインスツルメントする](#instrument-methods-through-attributes)ことが可能です。 + +## 属性によるインスツルメントメソッド + +Datadog が自動インスツルメンテーションを行う際に、メソッドに `[Trace]` を追加し、トレースするようにします。自動インスツルメンテーションが有効でない場合、この属性はアプリケーションに何の影響も及ぼしません。 + +`[Trace]` 属性はデフォルトのオペレーション名 `trace.annotation` とトレースされるメソッドのリソース名を持っています。**操作名**と**リソース名**を `[Trace]` 属性の名前付き引数として設定することで、インスツルメンテーションされる内容をより良く反映させることができます。`[Trace]` 属性に設定できる引数は、オペレーション名とリソース名のみです。例: + +```csharp +using Datadog.Trace.Annotations; + +namespace Store.Managers +{ + public class SessionManager + { + [Trace(OperationName = "database.persist", ResourceName = "SessionManager.SaveSession")] + public static void SaveSession() + { + // ここにメソッドの実装 + } + } +} +``` + +## コードによるカスタムインスツルメンテーション + +
+ 注: この機能を使用するには、Datadog.Trace NuGet パッケージをアプリケーションに追加する必要があります。これは、トレーサーとアクティブスパンに直接アクセスするための API を提供します。 +
+ +
+ 注: v3.0.0 以降、カスタム インスツルメンテーションを使用するには自動インスツルメンテーションも併用する必要があります。自動およびカスタム インスツルメンテーションのパッケージ バージョン (例: MSI と NuGet) は同期させ、メジャー バージョンを混在させないようにしてください。 +
+ +### コードによる Datadog の構成 + +アプリケーションを構成する方法は複数あります。環境変数、`web.config` ファイル、`datadog.json` ファイルを使用する方法があり、 [ドキュメントで説明されています][11]。また、`Datadog.Trace` NuGet パッケージでは、コード内で構成を行うことができます。 + +構成設定をオーバーライドするには、`TracerSettings` のインスタンスを作成して、静的な `Tracer.Configure()` メソッドに渡します。 + +```csharp +using Datadog.Trace; + +// 既存の環境変数と構成ソースを使用して +// 設定オブジェクトを作成します +var settings = TracerSettings.FromDefaultSources(); + +// 値をオーバーライドします +settings.GlobalTags.Add("SomeKey", "SomeValue"); + +// トレーサーの構成を置き換えます +Tracer.Configure(settings); +``` + +`Tracer.Configure()` を呼び出すと、カスタムインスツルメンテーションでも自動インスツルメンテーションでも、それ以降のすべてのトレースの設定が置き換わります。 + +
+ 構成の置き換えは、アプリケーションで一度だけ、できるだけ早い段階で行う必要があります。 +
+ +### カスタムトレース/スパンの作成 + +自動インスツルメンテーション、 `[Trace]` 属性、`DD_TRACE_METHODS` の構成に加えて、プログラム的に任意のコードブロックの周りにスパンを作成することで、観測可能性をカスタマイズすることが可能です。 + +カスタムスパンを作成してアクティブにするには、`Tracer.Instance.StartActive()` を使用します。トレースがすでにアクティブな場合 (例えば、自動インスツルメンテーションによって作成された場合)、スパンは現在のトレースの一部となります。現在のトレースがない場合は、新しいトレースが開始されます。 + +
警告: StartActive から返されたスコープを確実にディスポーズしてください。スコープをディスポーズすると、スパンが閉じられ、そのスパンがすべて閉じられると、トレースが Datadog にフラッシュされるようになります。 +
+ +```csharp +using Datadog.Trace; + +// 新しいスパンを開始します +using (var scope = Tracer.Instance.StartActive("custom-operation")) +{ + // 操作を実行します +} +``` + +カスタム[スパンタグ][5]を[スパン][6]に追加して、Datadog 内の可観測性をカスタマイズします。スパンタグは受信トレースに適用されるため、観測された動作を、マーチャントの階層、チェックアウト金額、ユーザー ID などのコードレベルの情報と関連付けることができます。 + +### 新しいスパンを手動で作成する + +手動で作成したスパンは、他のトレースメカニズムからのスパンと自動的にインテグレーションされます。つまり、トレースがすでに開始されている場合、手動スパンはその呼び出し元を親スパンとして持っています。同様に、ラップされたコードブロックから呼び出されたトレースされたメソッドは、その親として手動スパンを持ちます。 + +```csharp +using (var parentScope = + Tracer.Instance.StartActive("manual.sortorders")) +{ + parentScope.Span.ResourceName = ""; + using (var childScope = + Tracer.Instance.StartActive("manual.sortorders.child")) + { + // トレースするコードの周囲にあるステートメントを使用してネストします + childScope.Span.ResourceName = ""; + SortOrders(); + } +} +``` + +### カスタムスパンタグを追加する + +`customer.id` などのアプリケーションコード内の動的な値に対応するカスタムタグをスパンに追加します。 + +```csharp +using Datadog.Trace; + +public class ShoppingCartController : Controller +{ + private IShoppingCartRepository _shoppingCartRepository; + + [HttpGet] + public IActionResult Index(int customerId) + { + // グローバルトレーサーでアクティブスコープにアクセスする + // 注: アクティブなスパンが存在しない場合は null を返すことがあります + var scope = Tracer.Instance.ActiveScope; + + if (scope != null) + { + // Datadog の Web UI で使用するためのタグをスパンに追加する + scope.Span.SetTag("customer.id", customerId.ToString()); + } + + var cart = _shoppingCartRepository.Get(customerId); + + return View(cart); + } +} +``` + +### スパンにエラーを設定する + +コードで発生したエラーをマークするには、`Span.SetException(Exception)` メソッドを使用します。このメソッドは、スパンをエラーとしてマークし、[関連するスパンメタデータ][5]を追加して、例外の情報を提供します。 + +```csharp +try +{ + // 例外をスローする可能性のある作業を行います +} +catch(Exception e) +{ + span.SetException(e); +} +``` + +これは、スパンに以下のタグを設定します。 +- `"error.message":exception.Message` +- `"error.stack":exception.ToString()` +- `"error.type":exception.GetType().ToString()` + +## ヘッダー抽出と挿入によるコンテキストの伝搬 + +分散型トレーシングのコンテキストの伝搬は、ヘッダーの挿入と抽出で構成できます。詳しくは[トレースコンテキストの伝播][12]をお読みください。 + +## すべてのスパンにグローバルにタグを追加する + +`DD_TAGS` 環境変数を使用して、アプリケーションに対して生成されたすべてのスパンにタグを設定します。これは、Datadog UI 内でアプリケーション、データセンター、または地域の統計データをグループ化するのに役立ちます。例: + +```ini +DD_TAGS=datacenter:njc,key2:value2 +``` + +## リソースのフィルター + +リソース名に基づいてトレースを除外することで、ヘルスチェックなどの Synthetic トラフィックを削除することができます。セキュリティや追加構成については、[データセキュリティのための Datadog Agent またはトレーサーの構成][10]を参照してください。 + +## その他の参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + + +[1]: /ja/tracing/trace_collection/compatibility/dotnet-framework +[2]: /ja/tracing/trace_collection/compatibility/dotnet-core +[3]: /ja/tracing/trace_collection/dd_libraries/dotnet-core +[5]: /ja/tracing/glossary/#span-tags +[6]: /ja/tracing/glossary/#spans +[7]: /ja/tracing/glossary/#trace +[8]: /ja/tracing/trace_collection/library_config/dotnet-framework/#automatic-instrumentation-optional-configuration +[9]: /ja/tracing/trace_collection/library_config/dotnet-core/#automatic-instrumentation-optional-configuration +[10]: /ja/tracing/security +[11]: /ja/tracing/trace_collection/library_config/dotnet-core/ +[12]: /ja/tracing/trace_collection/trace_context_propagation/ \ No newline at end of file diff --git a/content/ja/tracing/trace_collection/custom_instrumentation/php/otel.md b/content/ja/tracing/trace_collection/custom_instrumentation/php/otel.md new file mode 100644 index 0000000000000..02acc0baa6fe9 --- /dev/null +++ b/content/ja/tracing/trace_collection/custom_instrumentation/php/otel.md @@ -0,0 +1,166 @@ +--- +aliases: +- /ja/tracing/trace_collection/otel_instrumentation/php/ +- /ja/tracing/trace_collection/custom_instrumentation/otel_instrumentation/php +code_lang: otel +code_lang_weight: 2 +description: OpenTelemetry API を使用して PHP アプリケーションをインスツルメントし、Datadog へトレースを送信します。 +further_reading: +- link: tracing/glossary/ + tag: ドキュメント + text: サービス、リソース、トレースの詳細 +- link: /opentelemetry/guide/otel_api_tracing_interoperability + tag: ドキュメント + text: OpenTelemetry API と Datadog でインスツルメントされたトレースの相互運用性 +title: OpenTelemetry API を使用した PHP カスタム インスツルメンテーション +type: multi-code-lang +--- + +{{% otel-custom-instrumentation-lang %}} + +## セットアップ + +OpenTelemetry を Datadog トレースプロバイダーを使用するように構成するには + +1. [OpenTelemetry API パッケージ][13]をインストールします。 + ```php + composer require open-telemetry/sdk + ``` +2. [OpenTelemetry PHP Manual Instrumentation ドキュメント][5]に従って、ご希望の手動 OpenTelemetry インスツルメンテーションを PHP コードに追加します。 + +3. [Datadog PHP トレーシングライブラリ][6] をインストールします。 + +4. `DD_TRACE_OTEL_ENABLED` を `true` に設定します。 + +Datadog は、これらの OpenTelemetry スパンと他の Datadog APM スパンを組み合わせて、アプリケーションの単一のトレースにします。 + +## スパンタグの追加 + +スパンを開始する瞬間に属性を追加できます。 + +```php +$span = $tracer->spanBuilder('mySpan') + ->setAttribute('key', 'value') + ->startSpan(); +``` + +またはスパンがアクティブな間: + +```php +$activeSpan = OpenTelemetry\API\Trace\Span::getCurrent(); + +$activeSpan->setAttribute('key', 'value'); +``` + + +## スパンにエラーを設定する + +例外発生時にスパンがアクティブな場合、その例外情報がスパンに添付されます。 + +```php +// スパンを作成 +$span = $tracer->spanBuilder('mySpan')->startSpan(); + +throw new \Exception('Oops!'); + +// 'mySpan' にエラーフラグを立て、 +// スタックトレースと例外メッセージをタグとして追加 +``` + +トレースにエラーフラグを付けることは、手動でも可能です。 + +```php +use OpenTelemetry\API\Trace\Span; +use OpenTelemetry\Context\Context; + +// トレーサーの初期化など、セットアップ手順の後にのみ実行できます。 + +try { + throw new \Exception('Oops!'); +} catch (\Exception $e) { + $rootSpan = Span::fromContext(Context::getRoot()); + $rootSpan->recordException($e); +} +``` +## タグの追加 + +スパンを追加するには + +```php +// トレーサーを入手するか、既存のものを使用 +$tracerProvider = \OpenTelemetry\API\Globals::tracerProvider(); +$tracer = $tracerProvider->getTracer('datadog') + +// スパンを作成 +$span = $tracer->spanBuilder('mySpan')->startSpan(); + +// ... 処理内容 + +// スパンを閉じる +$span->end(); + +``` + +## スパン イベントの追加 + +
スパン イベントを追加するには SDK バージョン 1.3.0 以上が必要です。
+ +`addEvent` API を使用してスパン イベントを追加できます。このメソッドには必須パラメーター `name` があり、オプションで `attributes` と `timestamp` を受け取ります。メソッドは指定されたプロパティを持つ新しいスパン イベントを作成し、対象のスパンに関連付けます。 + +- **Name** [_required_]: イベント名を表す文字列。 +- **Attributes** [_optional_]: 以下のプロパティを持つ 0 個以上のキーと値のペア。 + - キーは空でない文字列である必要があります。 + - 値として指定できるのは次のいずれかです。 + - プリミティブ型: string、Boolean、number。 + - 同一プリミティブ型の要素のみを含む配列 (例: string の配列)。 + - 入れ子の配列や異なるデータ型を混在させた配列は使用できません。 +- **Timestamp** [_optional_]: イベント発生時刻を表す UNIX タイムスタンプ。`nanoseconds` を想定します。 + +以下の例は、スパンにイベントを追加するさまざまな方法を示しています。 + +```php +$span->addEvent("Event With No Attributes"); +$span->addEvent( + "Event With Some Attributes", + [ + 'int_val' => 1, + 'string_val' => "two", + 'int_array' => [3, 4], + 'string_array' => ["5", "6"], + 'bool_array' => [true, false] + ] +); +``` + +詳細は [OpenTelemetry 仕様][14] を参照してください。 + +### 例外の記録 + +例外を記録するには `recordException` API を使用します。このメソッドには必須パラメーター `exception` があり、オプションで UNIX `timestamp` を受け取ります。標準化された例外属性を含む新しいスパン イベントを作成し、対象のスパンに関連付けます。 + +以下の例は、例外を記録するさまざまな方法を示しています。 + +```php +$span->recordException(new \Exception("Error Message")); +$span->recordException(new \Exception("Error Message"), [ "status" => "failed" ]); +``` + +詳細は [OpenTelemetry 仕様][15] を参照してください。 + +## アクティブなスパンへのアクセス + +現在アクティブなスパンにアクセスするには + +```php +$span = OpenTelemetry\API\Trace\Span::getCurrent(); +``` + +## その他の参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + +[5]: https://opentelemetry.io/docs/instrumentation/php/manual/ +[6]: /ja/tracing/trace_collection/dd_libraries/php#getting-started +[13]: https://opentelemetry.io/docs/languages/php/instrumentation/#instrumentation-setup +[14]: https://opentelemetry.io/docs/specs/otel/trace/api/#add-events +[15]: https://opentelemetry.io/docs/specs/otel/trace/api/#record-exception \ No newline at end of file diff --git a/content/ja/tracing/trace_collection/custom_instrumentation/python/_index.md b/content/ja/tracing/trace_collection/custom_instrumentation/python/_index.md new file mode 100644 index 0000000000000..461efc5ff8195 --- /dev/null +++ b/content/ja/tracing/trace_collection/custom_instrumentation/python/_index.md @@ -0,0 +1,5 @@ +--- +external_redirect: /tracing/trace_collection/custom_instrumentation/python/dd-api +title: Python +type: multi-code-lang +--- diff --git a/content/ja/tracing/trace_collection/custom_instrumentation/python/otel.md b/content/ja/tracing/trace_collection/custom_instrumentation/python/otel.md new file mode 100644 index 0000000000000..26d3155a8815d --- /dev/null +++ b/content/ja/tracing/trace_collection/custom_instrumentation/python/otel.md @@ -0,0 +1,114 @@ +--- +aliases: +- /ja/tracing/trace_collection/otel_instrumentation/python/ +- /ja/tracing/trace_collection/custom_instrumentation/otel_instrumentation/python +code_lang: otel +code_lang_weight: 2 +description: OpenTelemetry API で Python アプリケーションをインスツルメンテーションし、Datadog にトレースを送信します。 +further_reading: +- link: tracing/glossary/ + tag: ドキュメント + text: サービス、リソース、トレースの詳細 +- link: /opentelemetry/guide/otel_api_tracing_interoperability + tag: ドキュメント + text: OpenTelemetry API と Datadog でインスツルメントされたトレースの相互運用性 +title: OpenTelemetry API を使った Python カスタムインスツルメンテーション +type: multi-code-lang +--- + +{{% otel-custom-instrumentation-lang %}} + + +## セットアップ + +OpenTelemetry を Datadog トレースプロバイダーを使用するように構成するには + +1. 自動インスツルメンテーションとセットアップの説明をまだお読みでない場合は、[Python セットアップ手順][1]からお読みください。 + +1. `DD_TRACE_OTEL_ENABLED` 環境変数を `true` に設定します。 + +### カスタムスパンの作成 + +既存のトレースコンテキスト内にカスタムスパンを作成するには + +{{< highlight python "hl_lines=6" >}} +from opentelemetry import trace + +tracer = trace.get_tracer(__name__) + +def do_work(): + with tracer.start_as_current_span("operation_name") as span: + # スパンで追跡したい作業を実行 + print("Doing work...") + # 'with' ブロックが終了すると、スパンは自動的に閉じる +{{< /highlight >}} + +## アクティブなスパンへのアクセス + +現在アクティブなスパンにアクセスするには、`get_current_span()` 関数を使います。 + +```python +from opentelemetry import trace + +current_span = trace.get_current_span() +# 'current_span' に情報を追加 +``` + +## スパンタグの追加 + +スパンに属性を追加して、追加のコンテキストやメタデータを提供します。 + +以下は、現在のスパンに属性を追加する方法の例です。 + +```python +from opentelemetry import trace + +current_span = trace.get_current_span() + +current_span.set_attribute("attribute_key1", 1) +``` + +## スパン イベントの追加 + +
スパン イベントを追加するには SDK バージョン 2.9.0 以上が必要です。
+ +`add_event` API を使用してスパン イベントを追加できます。このメソッドには必須パラメーター `name` があり、オプションで `attributes` と `timestamp` を受け取ります。メソッドは指定されたプロパティを持つ新しいスパン イベントを作成し、対象のスパンに関連付けます。 + +- **Name** [_required_]: イベント名を表す文字列。 +- **Attributes** [_optional_]: 以下のプロパティを持つ 0 個以上のキーと値のペア。 + - キーは空でない文字列である必要があります。 + - 値として指定できるのは次のいずれかです。 + - プリミティブ型: string、Boolean、number。 + - 同一プリミティブ型の要素のみを含む配列 (例: string の配列)。 + - 入れ子の配列や異なるデータ型を混在させた配列は使用できません。 +- **Timestamp** [_optional_]: イベント発生時刻を表す UNIX タイムスタンプ。`microseconds` を想定します。 + +以下の例は、スパンにイベントを追加するさまざまな方法を示しています。 + +```python +span.add_event("Event With No Attributes") +span.add_event("Event With Some Attributes", {"int_val": 1, "string_val": "two", "int_array": [3, 4], "string_array": ["5", "6"], "bool_array": [True, False]}) +``` + +詳細は [OpenTelemetry 仕様][2] を参照してください。 + +### 例外の記録 + +例外を記録するには `record_exception` API を使用します。このメソッドには必須パラメーター `exception` があり、オプションで UNIX `timestamp` を受け取ります。標準化された例外属性を含む新しいスパン イベントを作成し、対象のスパンに関連付けます。 + +以下の例は、例外を記録するさまざまな方法を示しています。 + +```python +span.record_exception(Exception("Error Message")) +span.record_exception(Exception("Error Message"), {"status": "failed"}) +``` + +詳細は [OpenTelemetry 仕様][3] を参照してください。 + +## 参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ja/tracing/setup/python/ +[2]: https://opentelemetry.io/docs/specs/otel/trace/api/#add-events +[3]: https://opentelemetry.io/docs/specs/otel/trace/api/#record-exception \ No newline at end of file diff --git a/content/ja/tracing/trace_collection/custom_instrumentation/ruby/otel.md b/content/ja/tracing/trace_collection/custom_instrumentation/ruby/otel.md new file mode 100644 index 0000000000000..34613ab6ec678 --- /dev/null +++ b/content/ja/tracing/trace_collection/custom_instrumentation/ruby/otel.md @@ -0,0 +1,136 @@ +--- +aliases: +- /ja/tracing/trace_collection/otel_instrumentation/ruby/ +- /ja/tracing/trace_collection/custom_instrumentation/otel_instrumentation/ruby +code_lang: otel +code_lang_weight: 2 +description: OpenTelemetry API を使用して Ruby アプリケーションをインスツルメントし、トレースを Datadog に送信します。 +further_reading: +- link: tracing/glossary/ + tag: ドキュメント + text: サービス、リソース、トレースの詳細 +- link: /opentelemetry/guide/otel_api_tracing_interoperability + tag: ドキュメント + text: OpenTelemetry API と Datadog でインスツルメントされたトレースの相互運用性 +title: Ruby で OpenTelemetry API を使用したカスタム インスツルメンテーション +type: multi-code-lang +--- + +{{% otel-custom-instrumentation %}} + + +## 要件と制限 + +- Datadog Ruby トレーシングライブラリ `dd-trace-rb` バージョン 1.9.0 以上。 +- Gem バージョンサポート 1.1.0 以上。 + +特記されている通り、Datadog のライブラリに実装されている以下の OpenTelemetry 機能: + +| 機能 | サポートノート | +|---------------------------------------|--------------------------------------| +| [OpenTelemetry コンテキスト伝搬][1] | [Datadog と W3C Trace Context のヘッダーフォーマット][9]はデフォルトで有効になっています。 | +| [スパンプロセッサー][2] | 非サポート | +| [スパンエクスポーター][3] | 非サポート | +| `OpenTelemetry.logger` | `OpenTelemetry.logger` は `Datadog.logger` と同じオブジェクトに設定されています。[カスタムロギング][10]から構成します。 | +| トレース/スパン [ID ジェネレーター][4] | ID 生成はトレーシングライブラリによって実行され、[128 ビットのトレース ID][12] をサポートしています。 | + + +## Datadog トレーシングライブラリを使用するための OpenTelemetry の構成 + +1. [OpenTelemetry Ruby Manual Instrumentation のドキュメント][5] に従って、必要な手動の OpenTelemetry インスツルメンテーションを Ruby コードに追加します。**重要!** その手順で OpenTelemetry SDK を呼び出すように示されている箇所では、代わりに Datadog トレース ライブラリを呼び出してください。 + +1. `datadog` gem を Gemfile に追加します。 + + ```ruby + source 'https://rubygems.org' + gem 'datadog' # For dd-trace-rb v1.x, use the `ddtrace` gem. + ``` + +1. `bundle install` を実行して gem をインストールします。 +1. OpenTelemetry のコンフィギュレーションファイルに以下の行を追加します。 + + ```ruby + require 'opentelemetry/sdk' + require 'datadog/opentelemetry' + ``` + +1. インテグレーションを有効にし、トレーサー設定を変更できる構成ブロックをアプリケーションに追加します。ここで追加の構成を行わないと、OpenTelemetry でインスツルメンテーションを行ったコードのみがトレースされます。 + + ```ruby + Datadog.configure do |c| + ... + end + ``` + + このブロックを使うと、以下のことができます。 + + - [Datadog コンフィギュレーション設定の追加][6] + - [Datadog インスツルメンテーションの有効化または再構成][7] + + OpenTelemetry の設定は、[`OpenTelemetry::SDK.configure` ブロック][15] を使用して、個別に変更できます。 + +Datadog は、これらの OpenTelemetry スパンと他の Datadog APM スパンを組み合わせて、アプリケーションの単一のトレースにします。また、[インテグレーションインスツルメンテーション][7]と [OpenTelemetry 自動インスツルメンテーション][8]もサポートしています。 + +## Adding span events + +
スパン イベントを追加するには、SDK バージョン 2.3.0 以上が必要です。
+ +`add_event` API を使用してスパン イベントを追加できます。このメソッドには必須パラメーター `name` があり、オプションで `attributes` と `timestamp` を受け取ります。メソッドは指定されたプロパティを持つ新しいスパン イベントを作成し、対象のスパンに関連付けます。 + +- **Name** [_required_]: A string representing the event's name. +- **Attributes** [_optional_]: Zero or more key-value pairs with the following properties: + - The key must be a non-empty string. + - The value can be either: + - A primitive type: string, Boolean, or number. + - A homogeneous array of primitive type values (for example, an array of strings). + - Nested arrays and arrays containing elements of different data types are not allowed. +- **Timestamp** [_オプション_]: イベントが発生した時刻を表す UNIX タイムスタンプ。`seconds(Float)` を想定します。 + +The following examples demonstrate different ways to add events to a span: + +```ruby +span.add_event('Event With No Attributes') +span.add_event( + 'Event With All Attributes', + attributes: { 'int_val' => 1, 'string_val' => 'two', 'int_array' => [3, 4], 'string_array' => ['5', '6'], 'bool_array' => [false, true]} +) +``` + +詳細は [OpenTelemetry][13] 仕様を参照してください。 + +### Recording exceptions + +例外を記録するには `record_exception` API を使用します。このメソッドには必須パラメーター `exception` があり、オプションで UNIX `timestamp` を受け取ります。標準化された例外属性を含む新しいスパン イベントを作成し、対象のスパンに関連付けます。 + +The following examples demonstrate different ways to record exceptions: + +```ruby +span.record_exception( + StandardError.new('Error Message') +) +span.record_exception( + StandardError.new('Error Message'), + attributes: { 'status' => 'failed' } +) +``` + +詳細は [OpenTelemetry 仕様][14] を参照してください。 + +## その他の参考資料 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://opentelemetry.io/docs/instrumentation/ruby/manual/#context-propagation +[2]: https://opentelemetry.io/docs/reference/specification/trace/sdk/#span-processor +[3]: https://opentelemetry.io/docs/reference/specification/trace/sdk/#span-exporter +[4]: https://opentelemetry.io/docs/reference/specification/trace/sdk/#id-generators +[5]: https://opentelemetry.io/docs/instrumentation/ruby/manual/ +[6]: /ja/tracing/trace_collection/dd_libraries/ruby/#additional-configuration +[7]: /ja/tracing/trace_collection/dd_libraries/ruby#integration-instrumentation +[8]: https://opentelemetry.io/docs/languages/ruby/libraries/ +[9]: /ja/tracing/trace_collection/trace_context_propagation/ +[10]: /ja/tracing/trace_collection/dd_libraries/ruby/#custom-logging +[12]: /ja/opentelemetry/guide/otel_api_tracing_interoperability/ +[13]: https://opentelemetry.io/docs/specs/otel/trace/api/#add-events +[14]: https://opentelemetry.io/docs/specs/otel/trace/api/#record-exception +[15]: https://opentelemetry.io/docs/languages/ruby/getting-started/#instrumentation \ No newline at end of file diff --git a/content/ja/tracing/trace_pipeline/metrics.md b/content/ja/tracing/trace_pipeline/metrics.md index fe48dc4e17830..472fdd500ad54 100644 --- a/content/ja/tracing/trace_pipeline/metrics.md +++ b/content/ja/tracing/trace_pipeline/metrics.md @@ -42,12 +42,20 @@ Datadog APM のプランには、インデックス化されたスパンと取 - `datadog.estimated_usage.apm.ingested_spans` - `datadog.estimated_usage.apm.ingested_traces` -使用量は `datadog.estimated_usage.apm.ingested_bytes` で制御します。取り込みはスパンやトレース数ではなく、量として計測されます。このメトリクスは `env` と `service` によってタグ付けされているので、どの環境とサービスが取り込み量に寄与しているかを特定することができます。 +使用量を制御するには `datadog.estimated_usage.apm.ingested_bytes` を使用します。取り込みはスパンやトレースの数ではなく、ボリュームで計測されます。このメトリクスには `env`、`service`、`sampling_service` タグが付与され、どの環境やサービスが取り込み量に寄与しているかを特定できます。`sampling_service` 次元の詳細は [サンプリング サービスとは？](#what-is-the-sampling-service) をご覧ください。 このメトリクスはまた、`ingestion_reason` によってタグ付けされ、Datadog にスパンを送信する責任がある[取り込みメカニズム][5]を反映させることができます。これらのメカニズムは、Datadog Agent のトレーシングライブラリの中にネストされています。このディメンションの詳細については、[取り込み理由ダッシュボード][6]を参照してください。 `datadog.estimated_usage.apm.ingested_traces` メトリクスは、1 秒間にサンプリングされるリクエスト数を計測し、[ヘッドベースサンプリング][7]によってサンプリングされたトレースのみをカウントします。このメトリクスは `env` と `service` によってタグ付けされているので、どのサービスが最も多くのトレースを開始しているのかを特定することもできます。 +#### サンプリング サービスとは？ + +`datadog.estimated_usage.apm.ingested_bytes` の `sampling_service` 次元は、スパンを発行したサービスではなく、**サンプリング決定を行ったサービス** に取り込まれたバイト数を割り当てます。 + +`sampling_service` でメトリクスをグループ化すると、総取り込み量に最も寄与しているサービスを特定できます。たとえば、サービス `A` がトレースを開始し、サービス `B` と `C` を呼び出す前に head ベース サンプリングを行った場合、サービス `A`、`B`、`C` のすべてのバイトは `sampling_service:A` に帰属します。 + +{{< img src="tracing/trace_indexing_and_ingestion/usage_metrics/sampling_service.png" style="width:80%;" alt="インジェスト バイト サンプリング サービスの説明" >}} + ### Indexed Span `datadog.estimated_usage.apm.indexed_spans` メトリクスを使用して、[タグベースの保持フィルター][2]でインデックス化されるスパン数を制御します。 @@ -86,4 +94,4 @@ Datadog APM のプランには、インデックス化されたスパンと取 [5]: /ja/tracing/trace_pipeline/ingestion_mechanisms/ [6]: https://app.datadoghq.com/dash/integration/apm_ingestion_reasons [7]: /ja/tracing/trace_pipeline/ingestion_mechanisms/#head-based-sampling -[8]: https://app.datadoghq.com/dash/integration/apm_estimated_usage +[8]: https://app.datadoghq.com/dash/integration/apm_estimated_usage \ No newline at end of file diff --git a/content/ko/agent/basic_agent_usage/saltstack.md b/content/ko/agent/basic_agent_usage/saltstack.md index 4e70591a0806e..4dd2d6448c904 100644 --- a/content/ko/agent/basic_agent_usage/saltstack.md +++ b/content/ko/agent/basic_agent_usage/saltstack.md @@ -214,7 +214,7 @@ Salt 공식은 사전에 작성된 Salt State입니다. Datadog 공식에서 사 **참조**: `datadog.config`를 사용해 다양한 점검 인스턴스를 서로 달느 머신에서 설정하는 경우, Salt 마스터 설정 또는 (마스터 없는 환경에서 실행 중이라면) Salt minion 설정에서 [pillar_merge_lists][5]를 `True`로 설정해야 합니다. -[1]: http://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html +[1]: https://docs.saltproject.io/en/latest/topics/development/conventions/formulas.html [2]: https://app.datadoghq.com/organization-settings/api-keys [3]: https://docs.datadoghq.com/ko/integrations/directory/ [4]: https://github.com/DataDog/datadog-formula/blob/master/pillar.example diff --git a/content/ko/agent/guide/heroku-ruby.md b/content/ko/agent/guide/heroku-ruby.md index 37463a2d67302..8a9520fb3b9eb 100644 --- a/content/ko/agent/guide/heroku-ruby.md +++ b/content/ko/agent/guide/heroku-ruby.md @@ -615,10 +615,10 @@ APM Agent {{< img src="agent/guide/heroku_ruby/traces.png" alt="Ruby application traces in Datadog" >}} -[서비스 카탈로그][20]로 이동하여 모든 애플리케이션 서비스 및 애플리케이션 서비스 보기를 확인합니다. +[Software Catalog][20]로 이동해서 모든 애플리케이션 서비스와 애플리케이션 서비스 보기를 확인합니다. -{{< img src="agent/guide/heroku_ruby/ruby_service.png" alt="Datadog 서비스 카탈로그" >}} -{{< img src="agent/guide/heroku_ruby/service_page.png" alt="Datadog의 루비 애플리케이션 서비스 상세 정보 페이지" >}} +{{< img src="agent/guide/heroku_ruby/ruby_service.png" alt="Datadog의 Software Catalog" >}} +{{< img src="agent/guide/heroku_ruby/service_page.png" alt="Datadog의 Ruby 애플리케이션 서비스 세부 정보 페이지" >}} ## 로그 diff --git a/content/ko/agent/guide/how-do-i-uninstall-the-agent.md b/content/ko/agent/guide/how-do-i-uninstall-the-agent.md index 7429e57d274a7..1a58961353492 100644 --- a/content/ko/agent/guide/how-do-i-uninstall-the-agent.md +++ b/content/ko/agent/guide/how-do-i-uninstall-the-agent.md @@ -5,254 +5,18 @@ algolia: aliases: - /ko/agent/faq/how-do-i-uninstall-the-agent/ further_reading: -- link: /agent/ +- link: /agent/basic_agent_usage/ tag: 설명서 - text: Datadog 에이전트에 대해 자세히 알아보기 -title: 에이전트 설치 제거 + text: Agent 기본 사용량 +title: Agent 설치 제거 --- -에이전트를 설치 제거하는 방법을 보려면 전용 플랫폼을 선택하세요. +시스템에서 Agent를 제거하는 방법은 운영 체제, 플랫폼, 또는 설정 도구의 [Basic Agent Usage][1] 페이지에서 확인하세요. -## Debian 및 Ubuntu +{{< uninstall-agent >}} -{{< tabs >}} -{{% tab "에이전트 v6 및 v7" %}} -```shell -sudo apt-get remove datadog-agent -y -``` +## 참고 자료 -> 이 명령을 사용하면 에이전트가 제거되나 다음은 제거되지 않습니다. +{{< partial name="whats-next/whats-next.html" >}} -* `datadog.yaml` 구성 파일, -* `/etc/datadog-agent` 구성 폴더 내 사용자가 생성한 파일, -* `/opt/datadog-agent` 폴더 내 사용자가 생성한 파일, -* `dd-agent` 사용자. - -> 위와 같은 요소도 제거하고 싶으면 대신 다음 명령을 사용하세요. - -```shell -sudo apt-get remove --purge datadog-agent -y -``` -{{% /tab %}} - -{{% tab "에이전트 v5" %}} -```shell -sudo apt-get remove datadog-agent -y -``` - -> 이 명령을 사용하면 에이전트가 제거되나 다음은 제거되지 않습니다. -* `datadog.yaml` 구성 파일, -* `/etc/dd-agent` 구성 폴더 내 사용자가 생성한 파일, -* `/opt/datadog-agent` 폴더 내 사용자가 생성한 파일, -* `dd-agent` 사용자. -> 위와 같은 요소도 제거하고 싶으면 대신 다음 명령을 사용하세요. - -```shell -sudo apt-get --purge remove datadog-agent -y -``` -{{% /tab %}} -{{< /tabs >}} - -## CentOS, RHEL, Fedora, Amazon Linux -{{< tabs >}} -{{% tab "에이전트 v6 및 v7" %}} - - -```shell -sudo yum remove datadog-agent -``` - -> 이 명령을 사용하면 에이전트가 제거되나 다음은 제거되지 않습니다. -* `datadog.yaml` 구성 파일, -* `/etc/datadog-agent` 구성 폴더 내 사용자가 생성한 파일, -* `/opt/datadog-agent` 폴더 내 사용자가 생성한 파일, -* `dd-agent` 사용자. - -> 위와 같은 요소와 Datadog 로그 파일을 제거하고 싶으면 에이전트를 제거한 후 다음 명령을 실행하세요. - -```shell -sudo userdel dd-agent \ -&& sudo rm -rf /opt/datadog-agent/ \ -&& sudo rm -rf /etc/datadog-agent/ \ -&& sudo rm -rf /var/log/datadog/ -``` -{{% /tab %}} - -{{% tab "에이전트 v5" %}} -```shell -sudo yum remove datadog-agent -``` - -> 이 명령을 사용하면 에이전트가 제거되나 다음은 제거되지 않습니다. - -* `datadog.yaml` 구성 파일, -* `/etc/dd-agent` 구성 폴더 내 사용자가 생성한 파일, -* `/opt/datadog-agent` 폴더 내 사용자가 생성한 파일, -* `dd-agent` 사용자. - -> 위와 같은 요소와 Datadog 로그 파일을 제거하고 싶으면 에이전트를 제거한 후 다음 명령을 실행하세요. - -```shell -sudo userdel dd-agent \ -&& sudo rm -rf /opt/datadog-agent/ \ -&& sudo rm -rf /etc/dd-agent/ \ -&& sudo rm -rf /var/log/datadog/ -``` -{{% /tab %}} -{{< /tabs >}} - -## openSUSE 및 SLES -{{< tabs >}} -{{% tab "에이전트 v6 및 v7" %}} -```shell -sudo zypper remove datadog-agent -``` - -> 이 명령을 사용하면 에이전트가 제거되나 다음은 제거되지 않습니다. -* `datadog.yaml` 구성 파일, -* `/etc/datadog-agent` 구성 폴더 내 사용자가 생성한 파일, -* `/opt/datadog-agent` 폴더 내 사용자가 생성한 파일, -* `dd-agent` 사용자. - -> 위와 같은 요소와 Datadog 로그 파일을 제거하고 싶으면 에이전트를 제거한 후 다음 명령을 실행하세요. - -```shell -sudo userdel dd-agent \ -&& sudo rm -rf /opt/datadog-agent/ \ -&& sudo rm -rf /etc/datadog-agent/ \ -&& sudo rm -rf /var/log/datadog/ -``` -{{% /tab %}} - -{{% tab "에이전트 v5" %}} - -```shell -sudo zypper remove datadog-agent -``` - -이 명령을 사용하면 에이전트가 제거되나 다음은 제거되지 않습니다. -* `datadog.yaml` 구성 파일, -* `/etc/dd-agent` 구성 폴더 내 사용자가 생성한 파일, -* `/opt/datadog-agent` 폴더 내 사용자가 생성한 파일, -* `dd-agent` 사용자. - - 위와 같은 요소와 Datadog 로그 파일을 제거하고 싶으면 에이전트를 제거한 후 다음 명령을 실행하세요. - -```shell -sudo userdel dd-agent \ -&& sudo rm -rf /opt/datadog-agent/ \ -&& sudo rm -rf /etc/dd-agent/ \ -&& sudo rm -rf /var/log/datadog/ -``` -{{% /tab %}} -{{< /tabs >}} -## macOS -{{< tabs >}} -{{% tab "에이전트 v6 및 v7" %}} -**단일 사용자 설치** - -에이전트와 에이전트 구성 파일을 모두 삭제하는 방법: -1. 트레이에 있는 뼈다귀 아이콘을 눌러 Datadog 에이전트를 실행 중지하고 종료합니다. -2. Datadog 애플리케이션을 애플리케이션 폴더에서 휴지통으로 드래그합니다. -3. 다음 명령을 실행합니다. - ```shell - sudo rm -rf /opt/datadog-agent - sudo rm -rf /usr/local/bin/datadog-agent - sudo rm -rf ~/.datadog-agent/**​ #to remove broken symlinks - launchctl remove com.datadoghq.agent - sudo rm -rf /var/log/datadog - ``` -4. 변경 사항을 적용하려면 컴퓨터를 재부팅합니다. - -**시스템 전체 LaunchDaemon 설치** - -에이전트와 에이전트 구성 파일을 모두 삭제하는 방법: -1. Datadog 애플리케이션을 애플리케이션 폴더에서 휴지통으로 드래그합니다. -2. 남은 파일을 제거하려면 다음을 실행합니다. - ```shell - sudo rm -rf /opt/datadog-agent - sudo rm -rf /usr/local/bin/datadog-agent - sudo rm -rf ~/.datadog-agent/**​ #to remove broken symlinks - sudo launchctl disable system/com.datadoghq.agent && sudo launchctl bootout system/com.datadoghq.agent - sudo rm /Library/LaunchDaemons/com.datadoghq.agent.plist - sudo rm -rf /var/log/datadog - ``` -3. 변경 사항을 적용하려면 컴퓨터를 재부팅합니다. -{{% /tab %}} - -{{% tab "에이전트 v5" %}} -1. 트레이에 있는 뼈다귀 아이콘을 눌러 Datadog 에이전트를 실행 중지하고 종료합니다. -2. Datadog 애플리케이션을 애플리케이션 폴더에서 휴지통으로 드래그합니다. -3. 다음을 실행합니다. - -```shell -sudo rm -rf /opt/datadog-agent -sudo rm -rf /usr/local/bin/datadog-agent -sudo rm -rf ~/.datadog-agent/** #to remove broken symlinks -``` - -에이전트가 부팅 시간에 실행되도록 하는 설치 명령 옵션을 실행했을 경우 다음 명령을 실행해 설치 제거를 완료합니다. - -```shell -sudo launchctl unload -w /Library/LaunchDaemons/com.datadoghq.agent.plist -sudo rm /Library/LaunchDaemons/com.datadoghq.agent.plist -``` - -> 이 방법으로 에이전트와 에이전트 구성 파일 모두를 제거할 수 있습니다. -{{% /tab %}} -{{< /tabs >}} - -## Windows - -{{< tabs >}} -{{% tab "에이전트 v6 및 v7" %}} - -Windows에서 에이전트를 설치 제거하는 두 가지 방법이 있습니다. 이 두 방법 모두 에이전트를 제거하나 호스트에 있는 `C:\ProgramData\Datadog` 구성 폴더를 제거하지 않습니다. - -### 프로그램 추가 또는 제거 - -1. **CTRL** 및 **Esc** 키를 누르거나 Windows 키를 사용해 Windows Search를 실행합니다. -1. `add`를 검색하고 **프로그램 추가 또는 제거**를 클릭합니다. -1. `Datadog Agent`를 검색하고 **제거**를 클릭합니다. - -### PowerShell - -**참고:** WinRM을 활성화해 다음 명령을 사용합니다. - -다음 PowerShell 명령의 하나를 사용해 재부팅하지 않고 에이전트를 제거할 수 있습니다. -```powershell -start-process msiexec -Wait -ArgumentList ('/log', 'C:\uninst.log', '/q', '/x', (Get-CimInstance -ClassName Win32_Product -Filter "Name='Datadog Agent'" -ComputerName .).IdentifyingNumber, 'REBOOT=ReallySuppress') -``` - -`/norestart` 사용: - -```powershell -start-process msiexec -Wait -ArgumentList ('/log', 'C:\uninst.log', '/norestart', '/q', '/x', (Get-CimInstance -ClassName Win32_Product -Filter "Name='Datadog Agent'" -ComputerName .).IdentifyingNumber) -``` - -{{% /tab %}} - -{{% tab "에이전트 v5" %}} - -Windows에서 에이전트를 설치 제거하는 두 가지 방법이 있습니다. 이 두 방법 모두 에이전트를 제거하나 호스트에 있는 `C:\ProgramData\Datadog` 구성 폴더를 제거하지 않습니다. - -> **참고**: 에이전트 < v5.12.0의 경우, 에이전트를 설치할 때 사용한 **원 계정**으로 에이전트를 설치 제거해야 합니다. 그러지 않으면 완벽하게 제거되지 않을 수 있습니다. - -### 프로그램 추가 또는 제거 - -1. **CTRL** 및 **Esc** 키를 누르거나 Windows 키를 사용해 Windows Search를 실행합니다. -1. `add`를 검색하고 **프로그램 추가 또는 제거**를 클릭합니다. -1. `Datadog Agent`를 검색하고 **제거**를 클릭합니다. - -### PowerShell - -**참고:** WinRM을 활성화해 다음 명령을 사용합니다. - -다음 PowerShell 명령을 사용해 재부팅하지 않고 에이전트를 제거할 수 있습니다. - -```powershell -start-process msiexec -Wait -ArgumentList ('/log', 'C:\uninst.log', '/norestart', '/q', '/x', (Get-CimInstance -ClassName Win32_Product -Filter "Name='Datadog Agent'" -ComputerName .).IdentifyingNumber) -``` - -{{% /tab %}} -{{< /tabs >}} \ No newline at end of file +[1]: /ko/agent/basic_agent_usage \ No newline at end of file diff --git a/content/ko/agent/guide/install-agent-5.md b/content/ko/agent/guide/install-agent-5.md index 179b7d8c880de..043464bfe397d 100644 --- a/content/ko/agent/guide/install-agent-5.md +++ b/content/ko/agent/guide/install-agent-5.md @@ -2,11 +2,12 @@ further_reading: - link: /agent/basic_agent_usage/ tag: 설명서 - text: 기본 에이전트 사용 + text: 에이전트 기본 사용량 +private: true title: Datadog 에이전트 5 설치 --- -이 가이드에서는 에이전트 5를 설치하는 방법을 안내합니다. Datadog에서는 최신 기능을 사용하기 위해 에이전트 7을 설치하거나 에이전트 7로 업그레이드하기를 권고합니다. 에이전트 최신 버전 설치에 관한 자세한 정보는 [에이전트 7 설치 지침][1]을 따르세요. 이전 버전에서 에이전트 7로 업그레이드하는 방법에 관한 자세한 정보는 [Datadog 에이전트 v7][2]를 참고하세요. +본 가이드에서는 Agent 5 설치에 관해 알아봅니다. Datadog의 최신 기능을 사용하려면 Agent 7을 설치하거나 업그레이드할 것을 권장합니다. 최신 버전의 Agent 설치에 관한 자세한 내용은 [Agent 7 설치 지침][1]을 따르세요. 이전 버전에서 Agent 7로 업그레이드하는 방법은 [Datadog Agent v7로 업그레이드][2]를 참고하세요. ## macOS @@ -14,62 +15,102 @@ title: Datadog 에이전트 5 설치 #### 명령줄 -`MY_API_KEY`를 내 Datadog API 키로 변경한 후 다음 명령을 실행하세요. +다음 명령을 실행하여 `MY_API_KEY`를 Datadog API 키로 바꿉니다. {{< code-block lang="shell" >}} DD_API_KEY=MY_API_KEY bash -c "$(curl -L https://raw.githubusercontent.com/DataDog/dd-agent/master/packaging/osx/install.sh)" {{< /code-block >}} - -에이전트를 관리하려면 `datadog-agent` 명령을 사용하세요. 기본적으로 `datadog-agent` 이진은 `/usr/local/bin`에 위치합니다. `/opt/datadog-agent/etc/conf.d`에서 통합을 활성화하거나 비활성화할 수 있습니다. +Agent를 관리하려면 `datadog-agent` 명령을 사용합니다. 기본적으로 `datadog-agent` 바이너리는 `/usr/local/bin`에 위치합니다. `/opt/datadog-agent/etc/conf.d`에서 통합을 활성화하거나 비활성화합니다. #### GUI -1. [DMG 패키지][3]를 다운로드하고 설치합니다. -1. `/opt/datadog-agent/etc/datadog.conf`에 다음 줄을 추가하고 `MY_API_KEY`를 내 Datadog API 키로 변경합니다. +1. [DMG 패키지[3]를 다운로드하고 설치합니다. +1. `/opt/datadog-agent/etc/datadog.conf`에 다음 줄을 추가하고 `MY_API_KEY`를 Datadog API 키로 바꿉니다. {{< code-block lang="shell" >}} api_key:MY_API_KEY {{< /code-block >}} -에이전트를 관리하려면 시스템 트레이에 있는 Datadog 에이전트 앱을 사용하세요. `/opt/datadog-agent/etc/conf.d`에서 통합을 활성화하거나 비활성화할 수 있습니다. +Agent를 관리하려면 시스템 트레이에서 Datadog Agent 앱을 사용합니다. `/opt/datadog-agent/etc/conf.d`에서 통합을 활성화하거나 비활성화합니다. -### 에이전트 실행 동작 +### Agent 실행 동작 -기본값은 로그인하면 에이전트가 바로 실행됩니다. 시스템 트레이에서 Datadog 에이전트 앱을 사용해 이를 비활성화할 수 있습니다. 부팅할 때 에이전트를 실행하고 싶으면 다음 명령을 사용하세요. +기본적으로 로그인 시 Agent가 실행됩니다. 시스템 트레이에서 Datadog Agent 앱으로 이를 비활성화할 수 있습니다. 부팅 시 Agent를 실행하려면 다음 명령을 사용합니다. {{< code-block lang="shell" >}} sudo cp '/opt/datadog-agent/etc/com.datadoghq.agent.plist' /Library/LaunchDaemons sudo launchctl load -w /Library/LaunchDaemons/com.datadoghq.agent.plist {{< /code-block >}} -## Windows +### 설치 제거 + +1. 트레이에서 뼈 모양 아이콘이 있는 Datadog 에이전트를 중지한 후 종료합니다. +1. Datadog 애플리케이션을 애플리케이션 폴더에서 휴지통으로 드래그합니다. +1. 실행: + + ```shell + sudo rm -rf /opt/datadog-agent + sudo rm -rf /usr/local/bin/datadog-agent + sudo rm -rf ~/.datadog-agent/** # to remove broken symlinks + ``` + +옵션 설치 명령을 실행하여 부팅 시 Agent를 실행하는 경우, 다음을 실행하여 제거를 완료합니다. + +```shell +sudo launchctl unload -w /Library/LaunchDaemons/com.datadoghq.agent.plist +sudo rm /Library/LaunchDaemons/com.datadoghq.agent.plist +``` + +## 윈도우즈(Windows) ### 에이전트 설치 #### GUI -Datadog 에이전트 설치 프로그램을 다운로드하고 실행합니다. -- [64비트 설치 프로그램][4]. -- [32비트 설치 프로그램][5]. 32비트 설치는 에이전트 버전 5.10.1까지만 지원됩니다. +Datadog Agent 인스톨러를 다운로드하여 실행합니다. +- [64비트 인스톨러][4]. +- [32비트 인스톨러][5]. 32비트 설치는 Agent 버전 5.10.1까지만 지원됩니다. 사용 가능한 모든 버전의 Windows 설치 프로그램 링크는 [JSON 형식으로 제공됩니다][6]. #### 명령줄 -1. 에이전트를 다운로드합니다. - - 새롭게 설치하는 경우에는 [Datadog 에이전트 설치 프로그램][4]을 다운로드하세요. - - Datadog 에이전트 버전 >5.12.0에서 업그레이드하는 경우에는 [EXE 설치 방법][7]을 사용하세요. -1. `cmd.exe` 셸에서 설치 프로그램을 다운로드 받은 디렉터리에 다음 명령을 실행하세요. `MY_API_KEY`를 내 Datadog API 키로 변경하세요. +1. Agent 다운로드 + - 새로 설치하려면 [Datadog Agent 인스톨러][4]를 다운로드합니다. + - Datadog Agent 5.12.0 미만 버전에서 업그레이드하는 경우 [EXE 설치 메서드][7]를 사용합니다. +1. 인스톨러를 다운로드한 디렉터리의 `cmd.exe` 셸에서 다음 명령을 실행합니다. `MY_API_KEY`를 Datadog API 키로 바꿉니다. {{< code-block lang="shell" >}} start /wait msiexec /qn /i ddagent-cli-latest.msi APIKEY="MY_API_KEY" {{< /code-block >}} - (선택 사항) `TAG`와 `HOSTNAME` 값을 추가하세요. + 옵션으로 `TAG` 및 `HOSTNAME` 값을 추가합니다. #### Azure에 배포 -에이전트를 Azure에 설치하려면 [Microsoft Azure 설명서][8]를 따르세요. +Azure에 Agent를 설치하려면 [Microsoft Azure 설명서][8]를 따르세요. + +### 5.12 버전 신규 업그레이드 절차 -### 5.12용 새 업그레이드 절차 +5.12 이전 버전 Windows Agent를 실행하는 기존 고객의 경우, 장치를 업그레이드하는 데 추가 단계가 필요할 수 있습니다. 특히 최신 Agent는 ''머신별' 설치 방식입니다. 이전 버전의 Agent는 기본적으로 '사용자별' 설치 방식이었습니다. 아울러, Chef로 배포하는 경우 추가 단계가 필요할 수 있습니다. 자세한 내용은 [Windows Agent 설치][9]를 참조하세요. -Windows 에이전트 5.12 이전 버전을 사용하는 기존 고객의 경우, 디바이스를 업그레이드해야 하는 추가 단계가 있을 수 있습니다. 구체적으로는 최신 에이전트를 "기기별"로 설치해야 합니다. 이전 에이전트 버전의 경우에는 기본값이 "사용자별"로 설치였습니다. Chef를 사용해 배포하는 경우에도 추가 단계가 필요할 수 있습니다. 자세한 정보는 [Windows 에이전트 설치][9]를 참고하세요. +### 설치 제거 + +Windows에서 Agent를 제거하는 방법에는 두 가지가 있습니다. 두 가지 방법 모두 Agent를 제거하지만 호스트의 `C:\ProgramData\Datadog` 구성 폴더는 제거하지 않습니다. + +**참고**: Agent v5.12.0 미만인 경우, Agent를 설치하는 데 사용한 **원본 계정**으로 Agent를 삭제하는 것이 중요합니다. 그렇지 않으면 완전히 삭제되지 않을 수도 있습니다. + +### 프로그램 추가 또는 제거 + +1. **CTRL** 및 **Esc**를 누르거나 Windows 키를 사용하여 Windows Search를 실행합니다. +1. `add`를 검색하고 **Add or remove programs**를 클릭합니다. +1. `Datadog Agent`를 검색하고 **Uninstall**를 클릭합니다. + +### PowerShell + +**참고:** 아래 명령을 사용하려면 WinRM을 활성화하세요. + +재부팅하지 않고 Agent를 제거하려면 다음 PowerShell 명령을 사용합니다. + +```powershell +start-process msiexec -Wait -ArgumentList ('/log', 'C:\uninst.log', '/norestart', '/q', '/x', (Get-CimInstance -ClassName Win32_Product -Filter "Name='Datadog Agent'" -ComputerName .).IdentifyingNumber) +``` ## Linux 및 Unix @@ -78,21 +119,21 @@ Windows 에이전트 5.12 이전 버전을 사용하는 기존 고객의 경우, {{% tab "Debian" %}} ### 원스텝 설치 -원스텝 명령을 사용하면 Datadog 에이전트의 APT 패키지를 설치하고 패스워드 입력 프롬프트가 나타납니다. 기기에 에이전트를 아직 설치하지 않았고 설치 후 Datadog가 바로 시작되지 않도록 하려면 실행하기 전에 명령 앞에 `DD_INSTALL_ONLY=true`를 추가하세요. +원스텝 명령은 Datadog Agent용 APT 패키지를 설치하고 비밀번호를 묻는 메시지를 표시합니다. Agent가 시스템에 아직 설치되어 있지 않고 설치 후 자동으로 시작되지 않도록 하려면 Agent를 실행하기 전에 `DD_INSTALL_ONLY=true`를 명령 앞에 추가하세요. -다음 명령을 실행합니다. `MY_API_KEY`를 내 Datadog API 키로 변경하세요. +`MY_API_KEY`를 Datadog API 키로 바꿔서 다음 명령을 실행합니다. ```shell DD_API_KEY=MY_API_KEY bash -c "$(curl -L https://raw.githubusercontent.com/DataDog/dd-agent/master/packaging/datadog-agent/source/install_agent.sh)" ``` -### 멀티 스텝 설치 +### 단계별 설치 -1. HTTPS를 통해 다운로드하고 `curl` 및 `gnupg`를 설치할 수 있도록 APT를 설정합니다. +1. HTTPS를 통해 다운로드하고 `curl`과 `gnupg`를 설치할 수 있도록 APT를 설정합니다. ```shell sudo apt-get update sudo apt-get install apt-transport-https curl gnupg ``` -1. 내 시스템에 Datadog Debian 레포를 구성하고 Datadog 아카이브 인증 키를 생성합니다. +1. 시스템에 Datadog Debian 리포지토리를 설정하고 Datadog 아카이브 키링을 만듭니다. ```shell sudo sh -c "echo 'deb [signed-by=/usr/share/keyrings/datadog-archive-keyring.gpg] https://apt.datadoghq.com/ stable main' > /etc/apt/sources.list.d/datadog.list" sudo touch /usr/share/keyrings/datadog-archive-keyring.gpg @@ -104,23 +145,23 @@ DD_API_KEY=MY_API_KEY bash -c "$(curl -L https://raw.githubusercontent.com/DataD curl https://keys.datadoghq.com/DATADOG_APT_KEY_F14F620E.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch curl https://keys.datadoghq.com/DATADOG_APT_KEY_382E94DE.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch ``` -1. Debian 8 이전 버전을 실행하는 경우 인증 키를 `/etc/apt/trusted.gpg.d`에 복사합니다. +1. Debian 8 이하를 실행하는 경우 키링을 `/etc/apt/trusted.gpg.d`에 복사하세요. ```shell sudo cp -a /usr/share/keyrings/datadog-archive-keyring.gpg /etc/apt/trusted.gpg.d/ ``` -1. 로컬 APT 레포를 업데이트하고 에이전트를 설치하세요. +1. 로컬 APT 리포지토리를 업데이트하고 Agent를 설치합니다. ```shell sudo apt-get update sudo apt-get install datadog-agent datadog-signing-keys ``` -1. 다음 명령을 실행하고 config 예시를 복사하여 적절한 필드에 붙여넣으세요. `MY_API_KEY`를 내 Datadog API 키로 변경하세요. +1. 다음 명령을 실행하여 예시 구성을 헤당 위치에 복사합니다. `MY_API_KEY`를 Datadog API 키로 바꿉니다. ```shell sudo sh -c "sed 's/api_key:.*/api_key:MY_API_KEY /' /etc/dd-agent/datadog.conf.example > /etc/dd-agent/datadog.conf" ``` -1. 에이전트를 시작합니다. +1. Agent를 시작합니다. ```shell sudo /etc/init.d/datadog-agent start ``` @@ -130,21 +171,21 @@ DD_API_KEY=MY_API_KEY bash -c "$(curl -L https://raw.githubusercontent.com/DataD {{% tab "Ubuntu" %}} ### 원스텝 설치 -원스텝 명령을 사용하면 Datadog 에이전트의 APT 패키지를 설치하고 패스워드 입력 프롬프트가 나타납니다. 기기에 에이전트를 아직 설치하지 않았고 설치 후 Datadog가 바로 시작되지 않도록 하려면 실행하기 전에 명령 앞에 `DD_INSTALL_ONLY=true`를 추가하세요. +원스텝 명령은 Datadog Agent용 APT 패키지를 설치하고 비밀번호를 묻는 메시지를 표시합니다. Agent가 시스템에 아직 설치되어 있지 않고 설치 후 자동으로 시작되지 않도록 하려면 Agent를 실행하기 전에 `DD_INSTALL_ONLY=true`를 명령 앞에 추가하세요. -다음 명령을 실행합니다. `MY_API_KEY`를 내 Datadog API 키로 변경하세요. +`MY_API_KEY`를 Datadog API 키로 바꿔서 다음 명령을 실행합니다. ```shell DD_API_KEY=MY_API_KEY bash -c "$(curl -L https://raw.githubusercontent.com/DataDog/dd-agent/master/packaging/datadog-agent/source/install_agent.sh)" ``` -### 멀티 스텝 설치 +### 단계별 설치 -1. HTTPS를 통해 다운로드하고 `curl` 및 `gnupg`를 설치할 수 있도록 APT를 설정합니다. +1. HTTPS를 통해 다운로드하고 `curl`과 `gnupg`를 설치할 수 있도록 APT를 설정합니다. ```shell sudo apt-get update sudo apt-get install apt-transport-https curl gnupg ``` -1. 내 시스템에 Datadog Debian 레포를 구성하고 Datadog 아카이브 인증 키를 생성합니다. +1. 시스템에 Datadog Debian 리포지토리를 설정하고 Datadog 아카이브 키링을 만듭니다. ```shell sudo sh -c "echo 'deb [signed-by=/usr/share/keyrings/datadog-archive-keyring.gpg] https://apt.datadoghq.com/ stable main' > /etc/apt/sources.list.d/datadog.list" sudo touch /usr/share/keyrings/datadog-archive-keyring.gpg @@ -156,42 +197,64 @@ DD_API_KEY=MY_API_KEY bash -c "$(curl -L https://raw.githubusercontent.com/DataD curl https://keys.datadoghq.com/DATADOG_APT_KEY_F14F620E.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch curl https://keys.datadoghq.com/DATADOG_APT_KEY_382E94DE.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch ``` -1. Debian 8 이전 버전을 실행하는 경우 인증 키을 `/etc/apt/trusted.gpg.d`에 복사합니다. +1. Debian 8 이하를 실행하는 경우 키링을 `/etc/apt/trusted.gpg.d`에 복사하세요. ```shell sudo cp -a /usr/share/keyrings/datadog-archive-keyring.gpg /etc/apt/trusted.gpg.d/ ``` -1. 로컬 APT 레포를 업데이트하고 에이전트를 설치하세요. +1. 로컬 APT 리포지토리를 업데이트하고 Agent를 설치합니다. ```shell sudo apt-get update sudo apt-get install datadog-agent datadog-signing-keys ``` -1. 다음 명령을 실행하고 config 예시를 복사하여 적절한 필드에 붙여넣으세요. `MY_API_KEY`를 내 Datadog API 키로 변경하세요. +1. 다음 명령을 실행하여 예제 구성을 복사합니다. `MY_API_KEY`를 Datadog API 키로 바꿉니다. ```shell sudo sh -c "sed 's/api_key:.*/api_key:MY_API_KEY /' /etc/dd-agent/datadog.conf.example > /etc/dd-agent/datadog.conf" ``` -1. 에이전트를 시작합니다. +1. Agent를 시작합니다. ```shell sudo /etc/init.d/datadog-agent start ``` +### 설치 제거 + +에이전트를 삭제하려면 다음 명령을 실행합니다. + +```shell +sudo apt-get remove datadog-agent -y +``` + +이 명령어를 사용하면 Agent가 삭제되나, 다음은 삭제되지 않습니다. + +* `datadog.yaml` 설정 파일 +* `/etc/dd-agent` 설정 폴더에 있는 사용자 생성 파일 +* `/opt/datadog-agent` 폴더에서 사용자가 생성한 파일 +* `dd-agent` 사용자 +* Datadog 로그 파일 + +이들 요소도 제거하려면 에이전트 제거 후 이 명령을 실행합니다. + +```shell +sudo apt-get --purge remove datadog-agent -y +``` + {{% /tab %}} {{% tab "Amazon Linux" %}} ### 원스텝 설치 -원스텝 명령을 사용하면 Datadog 에이전트의 YUM 패키지를 설치하고 패스워드 입력 프롬프트가 나타납니다. 기기에 에이전트를 아직 설치하지 않았고 설치 후 Datadog가 바로 시작되지 않도록 하려면 실행하기 전에 명령 앞에 `DD_INSTALL_ONLY=true`를 추가하세요. +원스텝 명령은 Datadog Agent용 YUM 패키지를 설치하고 비밀번호를 묻는 메시지를 표시합니다. Agent가 시스템에 아직 설치되어 있지 않고 설치 후 자동으로 시작되지 않도록 하려면, Agent를 실행하기 전에 `DD_INSTALL_ONLY=true`를 명령 앞에 추가하세요. -다음 명령을 실행합니다. `MY_API_KEY`를 내 Datadog API 키로 변경하세요. +`MY_API_KEY`를 Datadog API 키로 바꿔서 다음 명령을 실행합니다. ```shell DD_API_KEY=MY_API_KEY bash -c "$(curl -L https://raw.githubusercontent.com/DataDog/dd-agent/master/packaging/datadog-agent/source/install_agent.sh)" ``` -### 멀티 스텝 설치 +### 단계별 설치 -1. 다음 내용으로 `/etc/yum.repos.d/datadog.repo`를 생성해 Datadog YUM 레포를 설정합니다. +1. 다음에 따라 `/etc/yum.repos.d/datadog.repo`를 생성해 Datadog YUM 리포지토리를 구성합니다. ```conf [datadog] name=Datadog, Inc. @@ -205,35 +268,61 @@ DD_API_KEY=MY_API_KEY bash -c "$(curl -L https://raw.githubusercontent.com/DataD **참고**: i386/i686 아키텍처의 경우 "x86_64"를 "i386"로 변경하세요. -1. 로컬 Yum 레포를 업데이트하고 에이전트를 설치하세요. +1. 로컬 Yum 저장소를 업데이트하고 Agent를 설치하세요. ```shell sudo yum makecache sudo yum install datadog-agent ``` -1. 예시 config를 적절한 필드에 붙여넣으세요. `MY_API_KEY`를 내 Datadog API 키로 변경하세요. +1. 예시 구성을 해당 위치에 복사합니다. `MY_API_KEY`를 Datadog API 키로 바꿉니다. ```shell sudo sh -c "sed 's/api_key:.*/api_key:MY_API_KEY /' /etc/dd-agent/datadog.conf.example > /etc/dd-agent/datadog.conf" ``` -1. 에이전트를 시작합니다. +1. Agent를 재시작합니다. ```shell sudo /etc/init.d/datadog-agent restart ``` + + +### 설치 제거 + +에이전트를 삭제하려면 다음 명령을 실행합니다. + +```shell +sudo yum remove datadog-agent +``` + +이 명령어를 사용하면 Agent가 삭제되나, 다음은 삭제되지 않습니다. + +* `datadog.yaml` 설정 파일 +* `/etc/dd-agent` 설정 폴더에 있는 사용자 생성 파일 +* `/opt/datadog-agent` 폴더에서 사용자가 생성한 파일 +* `dd-agent` 사용자 +* Datadog 로그 파일 + +이들 요소도 제거하려면 에이전트 제거 후 이 명령을 실행합니다. + +```shell +sudo userdel dd-agent \ +&& sudo rm -rf /opt/datadog-agent/ \ +&& sudo rm -rf /etc/dd-agent/ \ +&& sudo rm -rf /var/log/datadog/ +``` {{% /tab %}} -{{% tab "CentOS 및 Red Hat" %}} +{{% tab "CentOS and Red Hat" %}} ### 원스텝 설치 -원스텝 명령을 사용하면 Datadog 에이전트의 YUM 패키지를 설치하고 패스워드 입력 프롬프트가 나타납니다. 기기에 에이전트를 아직 설치하지 않았고 설치 후 Datadog가 바로 시작되지 않도록 하려면 실행하기 전에 명령 앞에 `DD_INSTALL_ONLY=true`를 추가하세요. +원스텝 명령은 Datadog Agent용 YUM 패키지를 설치하고 비밀번호를 묻는 메시지를 표시합니다. Agent가 시스템에 아직 설치되어 있지 않고 설치 후 자동으로 시작되지 않도록 하려면, Agent를 실행하기 전에 `DD_INSTALL_ONLY=true`를 명령 앞에 추가하세요. -다음 명령을 실행합니다. `MY_API_KEY`를 내 Datadog API 키로 변경하세요. +`MY_API_KEY`를 Datadog API 키로 바꿔서 다음 명령을 실행합니다. ```shell DD_API_KEY=MY_API_KEY bash -c "$(curl -L https://raw.githubusercontent.com/DataDog/dd-agent/master/packaging/datadog-agent/source/install_agent.sh)" ``` -### 멀티 스텝 설치 +### 단계별 설치 -1. 다음 내용으로 `/etc/yum.repos.d/datadog.repo`를 생성해 Datadog YUM 레포를 설정합니다. +1. 다음에 따라 `/etc/yum.repos.d/datadog.repo`를 생성해 Datadog YUM 리포지토리를 구성합니다. ```conf [datadog] name=Datadog, Inc. @@ -247,36 +336,62 @@ DD_API_KEY=MY_API_KEY bash -c "$(curl -L https://raw.githubusercontent.com/DataD **참고**: i386/i686 아키텍처의 경우 "x86_64"를 "i386"로 변경하세요. -1. 로컬 YUM 레포를 업데이트하고 에이전트를 설치합니다. +1. 로컬 YUM 리포지토리를 업데이트하고 Agent를 설치합니다. ```shell sudo yum makecache sudo yum remove datadog-agent-base sudo yum install datadog-agent ``` -1. 예시 config를 적절한 필드에 붙여넣으세요. `MY_API_KEY`를 내 Datadog API 키로 변경하세요. +1. 예시 구성을 헤당 위치에 복사합니다. `MY_API_KEY`를 Datadog API 키로 바꿉니다. ```shell sudo sh -c "sed 's/api_key:.*/api_key:MY_API_KEY /' /etc/dd-agent/datadog.conf.example > /etc/dd-agent/datadog.conf" ``` -1. 에이전트를 시작합니다. +1. Agent를 재시작합니다. ```shell sudo /etc/init.d/datadog-agent restart ``` + +### 설치 제거 + +에이전트를 삭제하려면 다음 명령을 실행합니다. + +```shell +sudo yum remove datadog-agent +``` + +이 명령어를 사용하면 Agent가 삭제되나, 다음은 삭제되지 않습니다. + +* `datadog.yaml` 설정 파일 +* `/etc/dd-agent` 설정 폴더에 있는 사용자 생성 파일 +* `/opt/datadog-agent` 폴더에서 사용자가 생성한 파일 +* `dd-agent` 사용자 +* Datadog 로그 파일 + +이들 요소도 제거하려면 에이전트 제거 후 이 명령을 실행합니다. + +```shell +sudo userdel dd-agent \ +&& sudo rm -rf /opt/datadog-agent/ \ +&& sudo rm -rf /etc/dd-agent/ \ +&& sudo rm -rf /var/log/datadog/ +``` + {{% /tab %}} {{% tab "Fedora" %}} ### 원스텝 설치 -원스텝 명령을 사용하면 Datadog 에이전트의 YUM 패키지를 설치하고 패스워드 입력 프롬프트가 나타납니다. 기기에 에이전트를 아직 설치하지 않았고 설치 후 Datadog가 바로 시작되지 않도록 하려면 실행하기 전에 명령 앞에 `DD_INSTALL_ONLY=true`를 추가하세요. +원스텝 명령은 Datadog Agent용 YUM 패키지를 설치하고 비밀번호를 묻는 메시지를 표시합니다. Agent가 시스템에 아직 설치되어 있지 않고 설치 후 자동으로 시작되지 않도록 하려면, Agent를 실행하기 전에 `DD_INSTALL_ONLY=true`를 명령 앞에 추가하세요. -다음 명령을 실행합니다. `MY_API_KEY`를 내 Datadog API 키로 변경하세요. +`MY_API_KEY`를 Datadog API 키로 바꿔서 다음 명령을 실행합니다. ```shell DD_API_KEY=MY_API_KEY bash -c "$(curl -L https://raw.githubusercontent.com/DataDog/dd-agent/master/packaging/datadog-agent/source/install_agent.sh)" ``` -### 멀티 스텝 설치 +### 단계별 설치 -1. 다음 내용으로 `/etc/yum.repos.d/datadog.repo`를 생성해 Datadog YUM 레포를 설정합니다. +1. 다음에 따라 `/etc/yum.repos.d/datadog.repo`를 생성해 Datadog YUM 리포지토리를 구성합니다. ```conf [datadog] name=Datadog, Inc. @@ -290,35 +405,61 @@ DD_API_KEY=MY_API_KEY bash -c "$(curl -L https://raw.githubusercontent.com/DataD **참고**: i386/i686 아키텍처의 경우 "x86_64"를 "i386"로 변경하세요. -1. 로컬 YUM 레포를 업데이트하고 에이전트를 설치합니다. +1. 로컬 YUM 리포지토리를 업데이트하고 Agent를 설치합니다. ```shell sudo yum makecache sudo yum install datadog-agent ``` -1. 예시 config를 적절한 필드에 붙여넣으세요. `MY_API_KEY`를 내 Datadog API 키로 변경하세요. +1. 예시 구성을 헤당 위치에 복사합니다. `MY_API_KEY`를 Datadog API 키로 바꿉니다. ```shell sudo sh -c "sed 's/api_key:.*/api_key:MY_API_KEY /' /etc/dd-agent/datadog.conf.example > /etc/dd-agent/datadog.conf" ``` -1. 에이전트를 시작합니다. +1. Agent를 재시작합니다. ```shell sudo /etc/init.d/datadog-agent restart ``` + +### 설치 제거 + +에이전트를 삭제하려면 다음 명령을 실행합니다. + +```shell +sudo yum remove datadog-agent +``` + +이 명령어를 사용하면 Agent가 삭제되나, 다음은 삭제되지 않습니다. + +* `datadog.yaml` 설정 파일 +* `/etc/dd-agent` 설정 폴더에 있는 사용자 생성 파일 +* `/opt/datadog-agent` 폴더에서 사용자가 생성한 파일 +* `dd-agent` 사용자 +* Datadog 로그 파일 + +이들 요소도 제거하려면 에이전트 제거 후 이 명령을 실행합니다. + +```shell +sudo userdel dd-agent \ +&& sudo rm -rf /opt/datadog-agent/ \ +&& sudo rm -rf /etc/dd-agent/ \ +&& sudo rm -rf /var/log/datadog/ +``` + {{% /tab %}} {{% tab "Suse" %}} ### 원스텝 설치 -원스텝 명령을 사용하면 Datadog 에이전트의 YUM 패키지를 설치하고 패스워드 입력 프롬프트가 나타납니다. 기기에 에이전트를 아직 설치하지 않았고 설치 후 Datadog가 바로 시작되지 않도록 하려면 실행하기 전에 명령 앞에 `DD_INSTALL_ONLY=true`를 추가하세요. +원스텝 명령은 Datadog Agent용 YUM 패키지를 설치하고 비밀번호를 묻는 메시지를 표시합니다. Agent가 시스템에 아직 설치되어 있지 않고 설치 후 자동으로 시작되지 않도록 하려면, Agent를 실행하기 전에 `DD_INSTALL_ONLY=true`를 명령 앞에 추가하세요. -다음 명령을 실행합니다. `MY_API_KEY`를 내 Datadog API 키로 변경하세요. +`MY_API_KEY`를 Datadog API 키로 바꿔서 다음 명령을 실행합니다. ```shell DD_API_KEY=MY_API_KEY bash -c "$(curl -L https://raw.githubusercontent.com/DataDog/dd-agent/master/packaging/datadog-agent/source/install_agent.sh)" ``` -### 멀티 스텝 설치 +### 단계별 설치 -1. 다음 내용으로 `/etc/yum.repos.d/datadog.repo`를 생성해 Datadog YUM 레포를 설정합니다. +1. 다음에 따라 `/etc/yum.repos.d/datadog.repo`를 생성해 Datadog YUM 리포지토리를 구성합니다. ```conf [datadog] name=Datadog, Inc. @@ -331,69 +472,107 @@ DD_API_KEY=MY_API_KEY bash -c "$(curl -L https://raw.githubusercontent.com/DataD gpgkey=https://keys.datadoghq.com/DATADOG_RPM_KEY_FD4BF915.public ``` -1. 로컬 zypper 레포를 업데이트하고 에이전트를 설치합니다. +1. 로컬 Zypper 리포지토리를 업데이트하고 Agent를 설치합니다. ```shell sudo zypper refresh sudo zypper install datadog-agent ``` -1. 예시 config를 적절한 필드에 붙여넣으세요. `MY_API_KEY`를 내 Datadog API 키로 변경하세요. +1. 예시 구성을 헤당 위치에 복사합니다. `MY_API_KEY`를 Datadog API 키로 바꿉니다. ```shell sudo sh -c "sed 's/api_key:.*/api_key: MY_API_KEY/' /etc/dd-agent/datadog.conf.example > /etc/dd-agent/datadog.conf" ``` -1. 에이전트를 시작합니다. +1. Agent를 재시작합니다. ```shell sudo /etc/init.d/datadog-agent restart ``` + +### 설치 제거 + +에이전트를 삭제하려면 다음 명령을 실행합니다. + +```shell +sudo zypper remove datadog-agent +``` + +이 명령어를 사용하면 Agent가 삭제되나, 다음은 삭제되지 않습니다. +* `datadog.yaml` 설정 파일 +* `/etc/dd-agent` 설정 폴더에 있는 사용자 생성 파일 +* `/opt/datadog-agent` 폴더에서 사용자가 생성한 파일 +* `dd-agent` 사용자 +* Datadog 로그 파일 + +이들 요소도 제거하려면 에이전트 제거 후 이 명령을 실행합니다. + +```shell +sudo userdel dd-agent \ +&& sudo rm -rf /opt/datadog-agent/ \ +&& sudo rm -rf /etc/dd-agent/ \ +&& sudo rm -rf /var/log/datadog/ +``` + + {{% /tab %}} {{% tab "AIX" %}} ### 원스텝 설치 -원스텝 명령을 사용하면 Datadog 에이전트의 최신 BFF 패키지를 설치하고 필요한 경우 패스워드 프롬프트가 나타납니다. 기기에 에이전트를 아직 설치하지 않았고 설치 후 Datadog가 바로 시작되지 않도록 하려면 실행하기 전에 명령 앞에 `DD_INSTALL_ONLY=true`를 추가하세요. +원스텝 명령은 Datadog Agent용 최신 BFF 패키지를 설치하고 필요 시 비밀번호를 묻는 메시지를 표시합니다. Agent가 시스템에 아직 설치되어 있지 않고 설치 후 자동으로 시작되지 않도록 하려면, Agent를 실행하기 전에 `DD_INSTALL_ONLY=true`를 명령 앞에 추가하세요. -다음 명령을 실행합니다. `MY_API_KEY`를 내 Datadog API 키로 변경하세요. +`MY_API_KEY`를 Datadog API 키로 바꿔서 다음 명령을 실행합니다. ```shell DD_API_KEY=MY_API_KEY bash -c "$(curl -L https://raw.githubusercontent.com/DataDog/dd-agent/master/packaging/datadog-agent/source/install_agent.sh)" ``` ### 이전 설치에서 업그레이드 -기존 구성을 유지하면서 에이전트를 설치하려면 다음 명령을 실행하세요. +기존 구성을 유지하면서 Agent를 설치하려면 다음 명령을 실행합니다. ```shell DD_UPGRADE=true ksh -c "$(curl -L https://raw.githubusercontent.com/DataDog/datadog-unix-agent/master/scripts/install_script.sh)" ``` -사용할 수 있는 설치 스크립트 환경 변수 전체 목록을 보려면 [AIX용 기본 에이전트 사용][1]을 참고하세요. +사용 가능한 설치 스크립트 환경 변수의 전체 목록은 [AIX용 기본 Agent 사용법][1]을 참조하세요. -### 멀티 스텝 설치 +### 단계별 설치 -1. [datadog-unix-agent][2] 레포 릴리스에서 원하는 BFF를 다운로드 받으세요. -1. `installp`를 사용해 아티팩트를 루트로 설치합니다. +1. [datadog-unix-agent][2] 리포지토리 릴리스에서 선호하는 BFF를 다운로드하세요. +1. `installp`로 루트 권한으로 아티팩트를 설치합니다. ```shell installp -aXYgd datadog-unix-agent-latest.powerpc.aix..bff datadog-unix-agent ``` -1. 기존 구성 파일이 있는 경우에는 예시 config를 복사해 적절한 필드에 붙여넣으세요. `MY_API_KEY`를 내 Datadog API 키로 변경하세요. +1. 기존 구성 파일이 없는 경우 예시 구성을 해당 위치에 복사합니다. `MY_API_KEY`를 Datadog API 키로 바꿉니다. ```shell sudo sh -c "sed 's/api_key:.*/api_key: MY_API_KEY/' /etc/datadog-agent/datadog.yaml.example > /etc/datadog-agent/datadog.yaml" ``` -1. Datadog 에이전트에 올바른 권한이 있는지 확인: +1. Datadog Agent에 올바른 권한이 있는지 확인합니다. ```shell sudo sh -c "chown dd-agent:dd-agent /etc/datadog-agent/datadog.yaml && chmod 660 /etc/datadog-agent/datadog.yaml" ``` -1. 에이전트 서비스를 중단: +1. 서비스형 Agent를 중지합니다. ```shell sudo stopsrc -s datadog-agent ``` -1. 에이전트 서비스가 중단되었는지 확인: +1. 서비스형 Agent가 중지되었는지 확인합니다. ``` sudo lssrc -s datadog-agent ``` -1. 에이전트 서비스 재시작: +1. 서비스형 Agent를 재시작합니다. ```shell sudo startsrc -s datadog-agent ``` +### 설치 제거 + +에이전트를 삭제하려면 다음 명령을 실행합니다. + +설치된 에이전트를 제거하려면 다음 `installp` 명령을 실행하세요. + +```shell +installp -e dd-aix-uninstall.log -uv datadog-unix-agent +``` + +참고: 에이전트 설치 제거 로그는 `dd-aix-install.log` 파일에서 찾을 수 있습니다. 이 로깅을 비활성화하려면 설치 제거 명령에서 '-e' 매개변수를 제거하세요. + [1]: /ko/agent/basic_agent_usage/aix/#installation [2]: https://github.com/DataDog/datadog-unix-agent/releases {{% /tab %}} @@ -407,14 +586,14 @@ DD_UPGRADE=true ksh -c "$(curl -L https://raw.githubusercontent.com/DataDog/data ## 에이전트 설치 ### DaemonSets로 설치 -쿠버네티스 >=1.1.0을 실행하는 중이라면 [DaemonSets][1]를 사용해 Datadog 에이전트를 내 모든 노드에 배포할 수 있습니다. +Kubernetes 버전 1.1.0 이하를 실행하는 경우, [DaemonSets][1]를 활용하여 Datadog Agent를 모든 노드에 자동 배포할 수 있습니다. -1. API 키를 포함하는 비밀을 생성하세요. 이 비밀은 매니페스트에서 Datadog 에이전트를 배포하는 데 사용됩니다. `MY_API_KEY`를 내 Datadog API 키로 변경하세요. +1. API 키가 포함된 시크릿을 생성합니다. 해당 시크릿은 Datadog Agent 배포를 위한 매니페스트에서 사용됩니다. `MY_API_KEY`를 Datadog API 키로 바꿉니다. ```shell kubectl create secret generic datadog-secret --from-literal api-key =" MY_API_KEY" ``` -1. 이름이 `dd-agent.yaml`인 다음 매니페스트를 생성하세요. +1. `dd-agent.yaml`이라는 이름의 다음 매니페스트를 생성합니다. ```yaml apiVersion: extensions/v1beta1 @@ -487,25 +666,25 @@ DD_UPGRADE=true ksh -c "$(curl -L https://raw.githubusercontent.com/DataDog/data name: cgroups ``` -1. DaemonSet를 배포합니다. +1. DaemonSet을 배포합니다. ```shell kubectl create -f dd-agent.yaml ``` -
이는 자동탐지의 자동 설정 기능을 활성화하는 매니페스트입니다. 자동 설정을 비활성화하려면 SD_BACKEND 환경 변수 정의를 제거하세요. 자동탐지를 구성하는 방법을 알아보려면 쿠버네티스 통합 자동탐지를 참고하세요.
+
해당 매니페스트는 Autodiscovery 자동 구성 기능을 활성화합니다. 자동 구성을 비활성화하려면 SD_BACKEND 환경 변수 정의를 삭제합니다. Autodiscovery를 구성하는 방법을 알아보려면 Kubernetes 통합 Autodiscovery를 참조하세요.
-### 에이전트를 Docker 컨테이너로 실행 +### Docker 컨테이너로 Agent 실행 -사용하는 쿠버네티스 버전이 1.1.0 이상이 아니거나 DaemonSets를 사용하고 싶지 않은 경우에는 에이전트를 모니터링하고 싶은 각 노드에 Docker 컨테이너로 실행하세요. 다음 명령을 실행하고 `MY_API_KEY`를 내 Datadog API 키로 변경하세요. +Kubernetes 1.1.0 이상 버전을 실행하지 않거나 DaemonSets를 사용하지 않으려면, 모니터링하려는 각 노드에서 Agent를 Docker 컨테이너로 실행합니다. 다음 명령을 실행하여 `MY_API_KEY`를 Datadog API 키로 바꿉니다. ```shell docker run -d --name dd-agent -h `hostname` -v /var/run/docker.sock:/var/run/docker.sock:ro -v /proc/:/host/proc/:ro -v /sys/fs/cgroup/:/host/sys/fs/cgroup:ro -e API_KEY=MY_API_KEY -e KUBERNETES=yes -e SD_BACKEND=docker gcr.io/datadoghq/docker-dd-agent:latest ``` -## 커스텀 메트릭 전송 +## 커스텀 메트릭 전송하기 -DogStatsD를 사용해 [커스텀 메트릭][2]을 전송하려면 다음을 따르세요. -1. 매니페스트의 `ports` 섹션에 `hostPort`를 추가해 컨테이너의 StatsD 포트를 노드 IP 주소에 바인딩하세요. +DogStatsD를 사용해 [커스텀 메트릭][2]을 전송하려는 경우 +1. 매니페스트의 `ports` 섹션에 `hostPort`를 추가하여 컨테이너의 StatsD 포트를 노드의 IP 주소에 바인딩합니다. ```yaml ports: - containerPort: 8125 @@ -514,13 +693,13 @@ DogStatsD를 사용해 [커스텀 메트릭][2]을 전송하려면 다음을 따 protocol: UDP ``` -1. UDP 패킷을 노드 IP로 전송하도록 클라이언트 라이브러리를 구성합니다. 브리지 네트워킹을 사용하는 경우 애플리케이션 컨테이너의 기본 게이트웨이가 노드 IP와 일치합니다. 또 하향 API를 사용해 노드의 호스트 이름을 환경 변수로 노출할 수도 있습니다. +1. 클라이언트 라이브러리가 노드의 IP로 UDP 패킷을 전송하도록 구성합니다. 브리지 네트워킹을 사용하는 경우 애플리케이션 컨테이너의 기본 게이트웨이는 노드의 IP와 일치합니다. 하향 API로 노드의 호스트 이름을 환경 변수로 노출할 수도 있습니다. -## 에이전트 구성 사용자 지정 +## Agent 구성 커스텀하기 -에이전트 구성을 사용자 지정하려면 에이전트 5 [docker-dd-agent][3] 레포에 있는 설명서를 참고하세요. 자동탐지 구성을 조정하려면 [쿠버네티스 통합 자동탐지][4]를 참고하세요. 자동탐지를 비활성화하려면 매니페스트에서 `SD_BACKEND` 환경 변수를 제거하세요. +Agent 구성을 커스텀하려면 Agent 5 [docker-dd-agent][3] 리포지토리의 문서를 참조하세요. Autodiscovery 구성을 조정하려면 [Kubernetes 통합 Autodiscovery][4]를 참조하세요. Autodiscovery를 비활성화하려면 매니페스트에서 `SD_BACKEND` 환경 변수를 삭제하세요. -메트릭 수집, 서비스 점검, 이벤트에 관한 정보는 [쿠버네티스 통합][5] 설명서를 참고하세요. +메트릭 수집, 서비스 점검, 이벤트에 대한 자세한 내용은 [Kubernetes 통합][5] 문서를 참조하세요. [1]: https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/ [2]: /ko/metrics/custom_metrics @@ -533,36 +712,36 @@ DogStatsD를 사용해 [커스텀 메트릭][2]을 전송하려면 다음을 따 {{% tab "Docker" %}} ### 원스텝 설치 -원스텝 설치를 실행하면 Docker 컨테이너가 설치되고, 여기에 Datadog 에이전트의 호스트 모니터링이 포함되어 있습니다. 또 Docker 통합과 자동 config 모드의 자동탐지가 기본적으로 활성화되어 있습니다. 자동탐지를 비활성화하려면 원스텝 설치 명령에서 `SD_BACKEND`를 제거하세요. +원스텝 설치는 Datadog Agent가 내장된 Docker 컨테이너를 실행하여 호스트를 모니터링합니다. Docker 통합은 기본적으로 활성화되며, 자동 구성 모드에서는 autodiscovery도 활성화됩니다. autodiscovery를 비활성화하려면 원스텝 설치 명령에서 `SD_BACKEND` 변수를 삭제하세요. -#### Ansible -다음 명령을 실행합니다. `MY_API_KEY`를 내 Datadog API 키로 변경하세요. +#### Amazon Linux +`MY_API_KEY`를 Datadog API 키로 바꿔서 다음 명령을 실행합니다. ```shell docker run -d --name dd-agent -v /var/run/docker.sock:/var/run/docker.sock:ro -v /proc/:/host/proc/:ro -v /cgroup/:/host/sys/fs/cgroup:ro -e API_KEY=MY_API_KEY -e SD_BACKEND=docker gcr.io/datadoghq/docker-dd-agent:latest ``` #### 기타 운영체제 -다음 명령을 실행합니다. `MY_API_KEY`를 내 Datadog API 키로 변경하세요. +`MY_API_KEY`를 Datadog API 키로 바꿔서 다음 명령을 실행합니다. ```shell docker run -d --name dd-agent -v /var/run/docker.sock:/var/run/docker.sock:ro -v /proc/:/host/proc/:ro -v /sys/fs/cgroup/:/host/sys/fs/cgroup:ro -e API_KEY=MY_API_KEY -e SD_BACKEND=docker gcr.io/datadoghq/docker-dd-agent:latest ``` #### 트러블슈팅 -원스텝 설치 명령이 작동하지 않으면 시스템에서 `cgroup` 디렉터리를 예상치 못한 곳에 연결했거나 메모리 관리에 CGroup을 사용하고 있지 않을 수 있습니다. Docker 점검을 하려면 CGroup이 필요합니다. Cgroup을 사용하려면 [docker-dd-agent][1] 레포에 있는 설명서를 참고하세요. 예상치 못한 `cgroup` 디렉터리 위치로 인해 점검이 실패하는 경우에는 다음을 따르세요. +원스텝 설치 명령이 작동하지 않을 경우에는 시스템이 `cgroup` 디렉터리를 예상치 못한 위치에 마운트했거나, 메모리 관리에 CGroup을 사용하지 않기 때문일 수 있습니다. Docker 점검을 성공적으로 실행하려면 CGroup이 필요합니다. CGroup을 활성화하려면 [docker-dd-agent][1] 리포지토리의 문서를 참조하세요. 예상치 못한 `cgroup` 디렉터리 위치로 인해 점검에 실패하는 경우는 다음을 참고하세요. -1. `mount | grep "cgroup type tmpfs"`를 실행해 `cgroup` 디렉터리 위치를 얻습니다. +1. `mount | grep "cgroup type tmpfs"`를 실행해 `cgroup` 디렉터리 위치를 불러옵니다. 1. 원스텝 설치 명령에서 나오는 첫 번째 `/sys/fs/cgroup`를 `cgroup` 디렉터리 위치로 변경합니다. -### 커스텀 메트릭 전송 +### 커스텀 메트릭 전송하기 -DogStatsD를 사용해 커스텀 메트릭을 전송하는 방법: -1. 설치 명령에 `-p 8125:8125/udp` 옵션을 추가합니다. 이는 컨테이너의 StatsD 포트를 호스트 IP 주소에 바인딩합니다. -1. 클라이언트 라이브러리를 구성해 UDP 패킷을 호스트 IP 주소에 전송합니다. +DogStatsD를 사용해 커스텀 메트릭을 전송하는 방법 +1. 설치 명령에 `-p 8125:8125/udp` 옵션을 추가합니다. 이렇게 하면 컨테이너의 StatsD 포트가 호스트 IP 주소에 바인딩됩니다. +1. 클라이언트 라이브러리를 구성하여 호스트 IP 주소로 UDP 패킷을 전송합니다. -### 에이전트 구성 사용자 지정 +### Agent 구성 커스텀하기 -에이전트 구성을 사용자 지정하려면 에이전트 5 [docker-dd-agent][2] 레포에 있는 설명서를 참고하세요. 자동탐지 구성을 조정하려면 [Docker 통합 자동탐지][3]를 참고하세요. 자동탐지를 비활성화하려면 원스텝 설치 명령에서 `SD_BACKEND` 환경 변수를 제거하세요. +Agent 구성을 커스텀하려면 Agent 5 [docker-dd-agent][2] 리포지토리의 문서를 참조하세요. Autodiscovery 구성을 조정하려면 [Docker 통합 Autodiscovery][3]를 참조하세요. Autodiscovery를 비활성화하려면 원스텝 설치 명령에서 `SD_BACKEND` 환경 변수를 삭제하세요. [1]: https://github.com/DataDog/docker-dd-agent?tab=readme-ov-file#cgroups [2]: https://github.com/DataDog/docker-dd-agent @@ -571,9 +750,9 @@ DogStatsD를 사용해 커스텀 메트릭을 전송하는 방법: {{% /tab %}} {{% tab "CoreOS" %}} -Docker 런타임으로 CoreOS Container Linux를 실행할 수 있습니다. 설치 지침은 [Docker][1]에서 볼 수 있습니다. +CoreOS Container Linux는 Docker 런타임 실행이 지원됩니다. 설치 방법은 [Docker][1] 문서를 참고하세요. -쿠버네티스에서 CoreOS Tectonic을 실행하려면 [쿠버네티스][2]를 참고하세요. +Kubernetes에서 CoreOS Tectonic을 실행하려면 [Kubernetes][2]를 참조하세요. [1]: ?tab=docker#cloud-and-containers [2]: ?tab=kubernetes#cloud-and-containers @@ -581,16 +760,16 @@ Docker 런타임으로 CoreOS Container Linux를 실행할 수 있습니다. 설 {{% /tab %}} {{% tab "OpenShift" %}} -OpenShift로 Datadog를 실행하는 방법은 [datadog-openshift][1] 레포를 참고하세요. +Datadog을 OpenShift에 설치하는 방법에 관한 내용은 [datadog-openshift][1] 리포지토리를 참조하세요. [1]: https://github.com/DataDog/datadog-openshift {{% /tab %}} {{% tab "Cloud Foundry" %}} -
Datadog 에이전트 BOSH 릴리스는 Ubuntu와 Red Hat 스템셀에서만 작동합니다.
+
Datadog Agent BOSH 릴리스는 Ubuntu 및 Red Hat 스템셀에서만 작동합니다.
-1. Datadog 에이전트 릴리스를 BOSH Director에 업로드합니다. +1. BOSH Director에 Datadog Agent 릴리스 업로드 ```shell # BOSH CLI v1 @@ -600,7 +779,7 @@ OpenShift로 Datadog를 실행하는 방법은 [datadog-openshift][1] 레포를 bosh upload-release https://cloudfoundry.datadoghq.com/datadog-agent/datadog-agent-boshrelease-latest.tgz ``` -2. 런타임 config에서 Datadog를 애드온으로 구성합니다. `MY_API_KEY`를 내 Datadog API 키로 변경하세요. +2. 런타임 구성에서 Datadog을 애드온으로 구성합니다. `MY_API_KEY`를 Datadog API 키로 바꿉니다. ```yaml # runtime.yml @@ -628,7 +807,7 @@ OpenShift로 Datadog를 실행하는 방법은 [datadog-openshift][1] 레포를 # directory: "." ``` -3. 런타임 config에 런타임을 추가합니다. +3. 런타임 구성에 런타임을 추가합니다. ```shell # BOSH cli v1 @@ -638,7 +817,7 @@ OpenShift로 Datadog를 실행하는 방법은 [datadog-openshift][1] 레포를 bosh update-runtime-config runtime.yml ``` -4. 기존 배포를 다시 배포합니다. +4. 기존 배포를 재배포합니다. ```shell # BOSH cli v1 bosh deployment myDeployment.yml @@ -657,19 +836,19 @@ OpenShift로 Datadog를 실행하는 방법은 [datadog-openshift][1] 레포를 {{< tabs >}} {{% tab "Ansible" %}} -
Datadog Ansible 컬렉션은 Debian, RHEL 기반 및 SUSE 기반 Linux 배포, macOS, Windows를 대부분 지원합니다.
Ansible 버전 2.10 이상이 필요합니다.
+
Datadog Ansible Collection은 대부분의 Debian, RHEL 기반 및 SUSE 기반 Linux 배포, macOS, Windows를 지원합니다.
Ansible 버전 2.10 이상이 필요합니다.
-### 필수 요구 사항 +### 사전 필수 조건 -#### Windows -Datadog Ansible Collection을 사용해 Windows 호스트를 관리하기 전에 `ansible.windows` 컬렉션을 먼저 설치해야 합니다. +#### 윈도우즈(Windows) +Datadog Ansible Collection으로 Windows 호스트를 관리하려면 먼저 `ansible.windows` 컬렉션을 설치합니다. ```shell ansible-galaxy collection install ansible.windows ``` #### openSUSE 및 SLES -Datadog Ansible Collection을 사용해 openSUSE/SLES 호스트를 관리하기 전에 `community.general` 컬렉션을 먼저 설치해야 합니다. +Datadog Ansible Collection으로 openSUSE/SLES 호스트를 관리하려면 먼저 `community.general` 컬렉션을 설치합니다. ```shell ansible-galaxy collection install community.general @@ -677,14 +856,14 @@ ansible-galaxy collection install community.general ### Datadog 설치 -1. Ansible Galaxy를 사용해 Ansible 서버에 Datadog Ansible 컬렉션을 설치합니다. +1. Ansible 서버의 Ansible Galaxy에서 Datadog Ansible Collection을 설치합니다. ```shell ansible-galaxy collection install datadog.dd ``` - - Datadog Ansible 컬렉션은 공식 Red Hat 인증 허브인 [Red Hat Automation Hub][1]에서도 사용할 수 있습니다. - - 컬렉션을 설치하는 것이 좋습니다. 필요한 경우 [독립형 역할][2]을 사용해 Datadog를 설치할 수도 있습니다. + - Datadog Ansible Collection은 Red Hat의 공식 인증을 받은 [Red Hat Automation Hub][1]를 통해서도 제공됩니다. + - Collection을 설치할 것을 권장합니다. 필요한 경우 [독립 실행 역할][2]로 Datadog을 설치할 수도 있습니다. -2. 호스트에서 Datadog 에이전트를 배포하려면 Datadog 역할과 API 키를 플레이북에 추가하세요. `MY_API_KEY`를 내 Datadog API 키로 변경하세요. +2. Datadog Agent를 호스트에 배포하려면 Datadog 역할과 API 키를 플레이북에 추가합니다. `MY_API_KEY`를 Datadog API 키로 바꿉니다. ```yaml - hosts: servers tasks: @@ -696,15 +875,15 @@ ansible-galaxy collection install community.general datadog_agent_major_version: 5 ``` - 에이전트가 호스트를 함께 그룹화할 수 있도록 Datadog 에이전트가 추적 중인 노드 호스트 이름만 사용하세요. 에이전트가 추적 중인 호스트 이름을 확인하려면 다음 명령을 사용하세요. + Agent가 호스트를 그룹화하게 하려면, Datadog Agent이 추적 중인 노드 호스트 이름만 사용합니다. 다음 명령으로 Agent가 추적하는 호스트 이름을 확인할 수 있습니다. ```shell service datadog-agent info ``` -## 특정 에이전트 점검 +## 특정 Agent 점검 -노드에 특정 에이전트 점검이나 통합을 사용하려면 `datadog_checks` 변수를 사용할 수 있습니다. 다음은 프로세스 점검 예시입니다. +노드 중 하나에서 특정 Agent를 점검하거나 통합을 사용하려면 `datadog_checks` 변수를 활용합니다. 다음은 프로세스 점검 예시입니다. ```yaml - hosts: servers tasks: @@ -727,11 +906,11 @@ ansible-galaxy collection install community.general ignore_denied_access: true ``` -Github 레포에 있는 [독립형 역할][3]에서 에이전트 역할 사용과 관련한 예시를 더 보실 수 있습니다. +[독립 실행 역할][3]에 관한 Github 리포지토리에서 더 많은 Agent 역할 사용 예시를 찾을 수 있습니다. ### 메트릭 및 이벤트 -Ansible 실행 후 Datadog에서 메트릭과 이벤트를 얻으려면 Ansible 콜백 프로젝트의 [Github 페이지][4]를 참고하세요. +Ansible 실행 후 Datadog에서 메트릭 및 이벤트를 가져오려면 Ansible 콜백 프로젝트의 [Github Page][4]를 참조하세요. [1]: https://console.redhat.com/ansible/automation-hub/repo/published/datadog/dd/ [2]: /ko/agent/guide/ansible_standalone_role/#ansible-role-versus-ansible-collection @@ -740,19 +919,19 @@ Ansible 실행 후 Datadog에서 메트릭과 이벤트를 얻으려면 Ansible {{% /tab %}} {{% tab "Puppet" %}} -
datadog_agent 모듈은 Linux 노드만 지원합니다.
Puppet 에이전트 버전 2.7 이상이 필요합니다.
+
Datadog_agent 모듈은 Linux 노드만 지원합니다.
Puppet Agent 버전 2.7 이상이 필요합니다.
1. Puppet의 [Puppet Forge][1]에서 `datadog_agent` 모듈을 설치하세요. - - 새롭게 설치하는 경우에는 `module install command`를 실행하세요. + - 새로 설치하려면 `module install command`를 실행하세요. ```shell puppet module install datadog-datadog_agent ``` - - 모듈이 이미 설치되어 있다면 업그레이드하세요. + - 모듈이 이미 설치되어 있는 경우 업그레이드합니다. ```shell puppet module upgrade datadog-datadog_agent ``` -2. Datadog 에이전트를 노드에 배포하려면 다음 파라미터화된 클래스를 매니페스트에 추가하세요. `MY_API_KEY`를 내 Datadog API 키로 변경하세요. +2. Datadog Agent를 노드에 배포하려면 이 매니페스트에 파라미터화된 클래스를 추가합니다. `MY_API_KEY`를 Datadog API 키로 바꿉니다. ```puppet node "db1.mydomain.com" { class { "datadog_agent": @@ -761,14 +940,14 @@ Ansible 실행 후 Datadog에서 메트릭과 이벤트를 얻으려면 Ansible } ``` - 에이전트가 호스트를 함께 그룹화할 수 있도록 Datadog 에이전트가 추적 중인 노드 호스트 이름만 사용하세요. 에이전트가 추적 중인 호스트 이름을 확인하려면 다음 명령을 사용하세요. + Agent가 호스트를 그룹화하게 하려면, Datadog Agent이 추적 중인 노드 호스트 이름만 사용합니다. 다음 명령으로 Agent가 추적하는 호스트 이름을 확인할 수 있습니다. ```shell service datadog-agent info ``` -3. Puppet 서버에서 Datadog로 보고 활성화 - 1. `/etc/puppet/puppet.conf`를 다음 파라미터에 추가하세요. +3. Puppet 서버에서 Datadog으로 리포트를 활성화합니다. + 1. `/etc/puppet/puppet.conf`에 다음 파라미터를 추가합니다. ```conf [master] report = true @@ -779,7 +958,7 @@ Ansible 실행 후 Datadog에서 메트릭과 이벤트를 얻으려면 Ansible report = true pluginsync = true ``` - 1. 매니페스트에서 Puppet 서버에 `puppet_run_reports` 옵션을 추가하세요. 다음 예를 참고하세요. + 1. 매니페스트에서 Puppet 서버에 `puppet_run_reports` 옵션을 추가합니다. 예시: ```puppet node "puppet" { class { "datadog_agent": @@ -788,12 +967,12 @@ Ansible 실행 후 Datadog에서 메트릭과 이벤트를 얻으려면 Ansible } } ``` -1. Puppet 서버에서 Puppet을 실행해 필요한 종속성을 모두 설치하세요. -1. Puppet 서버를 다시 시작하면 Datadog에서 Puppet 데이터를 수신하기 시작합니다. +1. Puppet 서버에서 Puppet을 실행하여 필요한 모든 종속성을 설치합니다. +1. Puppet 서버를 재시작하여 Datadog에서 Puppet 데이터 수신을 시작합니다. -## 특정 에이전트 점검 +## 특정 Agent 점검 -노드에서 특정 에이전트 점검이나 통합을 사용하려면 [통합 매니페스트][2]에서 관련 코드 예시를 참고하세요. 다음은 elasticsearch 통합의 예시입니다. +노드 중 하나에서 특정 Agent를 점검하거나 통합을 사용하려면 [통합 매니페스트][2]에서 코드 예시를 확인하세요. 다음은 Elasticsearch 통합 예시입니다. ```puppet node "elastic-node1.mydomain.com" { @@ -811,27 +990,27 @@ node "elastic-node1.mydomain.com" { {{% tab "Chef" %}} -
Chef 버전 10.14x 이상이 필요합니다.
+
Chef 버전 10.14.x 이상이 필요합니다.
1. Datadog 쿡북을 추가합니다. - - [Berkshelf][1]를 사용한다면 Berksfile에 쿡북을 추가하세요. + - [Berkshelf][1]를 사용하는 경우 Berkfile에 쿡북을 추가합니다. ```shell cookbook 'datadog' ``` - - Berkshelf를 사용하지 않는 경우 Knife를 사용해 내 리포지토리에 쿡북을 설치하세요. + - Berkshelf를 사용하지 않는 경우 Knife를 사용하여 리포지토리에 쿡북을 설치합니다. ```shell knife cookbook site install datadog ``` -1. 역할, 환경, 또는 다른 레시피에 Datadog용 속성을 설정하세요. `MY_API_KEY`를 내 Datadog API 키로 변경하세요. +1. 역할, 환경 또는 다른 레시피에서 Datadog 특정 속성을 설정합니다. `MY_API_KEY`를 Datadog API 키로 바꿉니다. ```chef node.default['datadog']['api_key'] = "MY_API_KEY" # Use an existing application key or create a new one for Chef node.default['datadog']['application_key'] = "Generate Application Key" ``` -1. Chef 서버에 업데이트된 쿡북을 업로드합니다. +1. 업데이트된 쿡북을 Chef 서버에 업로드합니다. ```shell berks upload # or @@ -841,14 +1020,14 @@ node "elastic-node1.mydomain.com" { echo -e "e[0;31mmissing datadog cookbook - OKe[0m" ``` -1. 노드의 `run_list`나 `role`에 쿡북을 추가하세요. +1. 노드의 `run_list` 또는 `role`에 쿡북을 추가합니다. ```chef "run_list": [ "recipe[datadog::dd-agent]" ] ``` -1. 다음 예약된 `chef-client` 실행을 기다립니다. +1. 다음 `chef-client` 실행 일정까지 기다립니다. [1]: https://docs.chef.io/workstation/berkshelf/ @@ -856,13 +1035,13 @@ node "elastic-node1.mydomain.com" { {{% tab "SaltStack" %}} -
Datadog Saltstack 포뮬러는 Debian 기반 및 Redhat 기반 시스템만 지원합니다.

-다음은 Datadog 포뮬러를 기본 Salt 환경에 추가하는 방법입니다. 다른 Salt 환경에 추가하려면 기본에서 참조를 내 Salt 환경 이름으로 바꾸세요.
+
Datadog Saltstack 포뮬러는 Debian 기반 및 RedHat 기반 시스템만 지원합니다.

+다음 지침은 기본(base) Salt 환경에 Datadog 포뮬러를 추가하는 방법을 설명합니다. 다른 Salt 환경에 추가하려면 기본(base)에 대한 참조를 해당 Salt 환경의 이름으로 교체합니다.
-### `gitfs_remotes`를 사용해 설치 -1. 내 Salt Master 노드 기본 환경에서 Salt Master 구성 파일(기본값 `/etc/salt/master`)에 있는 `gitfs_remotes` 옵션을 사용해 [Datadog 포뮬러][1]를 설치하세요. +### `gitfs_remotes`를 사용해 설치하기 +1. Salt Master 설정 파일(기본 설정: `/etc/salt/master`)에서 `gitfs_remotes` 옵션을 사용하여 Salt Master 노드의 베이스 환경에 [Datadog 포뮬러][1]를 설치합니다. ```yaml fileserver_backend: - roots # Active by default, necessary to be able to use the local salt files we define in the next steps @@ -875,22 +1054,22 @@ node "elastic-node1.mydomain.com" { - ref: 3.0 # Pin here the version of the formula you want to use ``` -1. Salt Master 서비스를 재시작합니다. +1. Salt Master 서비스를 재시작 ```shell systemctl restart salt-master ``` - 또는 + 또는 ```shell service salt-master restart ``` ### Datadog 포뮬러를 복제하여 설치 -1. Salt Master 노드에 [Datadog 포뮬러][1]를 복제합니다. +1. Salt Master 노드에 [Datadog 포뮬러][1]를 복제합니다. ```shell mkdir -p /srv/formulas && cd /srv/formulas git clone https://github.com/DataDog/datadog-formula.git ``` -1. Salt Master 구성 파일(기본값 `/etc/salt/master`)의 `file_roots`에 있는 기본 환경에 복제한 포뮬러를 추가합니다. +1. 복제한 포뮬러를 Salt Master 구성 파일(기본값: `/etc/salt/master`)의 `file_roots` 기본 환경에 추가합니다. ```yaml file_roots: base: @@ -898,16 +1077,16 @@ node "elastic-node1.mydomain.com" { - /srv/formulas/datadog-formula/ ``` -## 에이전트를 호스트에 배포 +## 호스트에 Agent 배포하기 -1. Datadog 포뮬러를 상위 파일(기본값 `/srv/salt/top.sls`)에 추가합니다. +1. Datadog 포뮬러를 상단 파일에 추가합니다(기본값: `/srv/salt/top.sls`). ```yaml base: '*': - datadog ``` -1. `datadog.sls` 필러 파일을 필러 디렉터리(기본값 `/srv/pillar/`)에 추가하고 API 키를 추가합니다. `MY_API_KEY`를 내 Datadog API 키로 변경하세요. +1. `datadog.sls` Pillar 파일을 Pillar 디렉터리(기본값: `/srv/pillar/`)에 추가하고 API 키를 추가합니다. `MY_API_KEY`를 Datadog API 키로 바꿉니다. ```yaml datadog: config: @@ -916,14 +1095,14 @@ node "elastic-node1.mydomain.com" { agent_version: ``` -1. `datadog.sls` 필러 파일을 상위 필러 파일(기본값 `/srv/pillar/top.sls`)에 추가하세요. +1. `datadog.sls` Pillar 파일을 상단 Pillar 파일(기본값: `/srv/pillar/top.sls`)에 추가합니다. ```yaml base: '*': - datadog ``` -1. 호스트에 특정 에이전트 점검이나 통합을 사용하려면 점검 변수를 사용할 수 있습니다. 다음은 디렉터리 통합 예시입니다. +1. 호스트 중 하나에서 특정 Agent를 점검하거나 통합을 사용하려면 점검 변수를 활용합니다. 다음은 디렉터리 통합의 예시입니다. ```yaml datadog: config: @@ -938,7 +1117,7 @@ node "elastic-node1.mydomain.com" { name: "pillars" ``` -로그 구성, 점검 예시, 고급 사용 사례를 보려면 [Github 리포지토리][1]를 참고하세요. +로그 구성, 점검 예시, 고급 사용 사례는 포뮬러 [Github 리포지토리][1]를 참조하세요. [1]: https://github.com/DataDog/datadog-formula {{% /tab %}} @@ -947,18 +1126,18 @@ node "elastic-node1.mydomain.com" { ## 소스에서 설치 -
Datadog 에이전트를 사용하려면 Linux에 Python 2.7과 sysstat이 필요합니다.
+
Datadog Agent는 Linux에서 Python 2.7 및 sysstat가 필요합니다.
-원스텝 소스 설치 스크립트를 사용하세요. `MY_API_KEY`를 내 Datadog API 키로 변경하세요. +원스텝 소스 설치 스크립트를 사용합니다. `MY_API_KEY`를 Datadog API 키로 바꿉니다. ```shell DD_API_KEY=MY_API_KEY sh -c "$(curl -L https://raw.githubusercontent.com/DataDog/dd-agent/master/packaging/datadog-agent/source/setup_agent.sh)" ``` -이 스크립트는 에이전트를 `~/.datadog-agent`에 위치한 자체 포함 샌드박스에 설치합니다. +본 스크립트는 `~/.datadog-agent`에 위치한 독립형 샌드박스에 Agent를 설치합니다. -영구적으로 설치하려면 `init` daemon을 설정하고 현재 실행 중인 디렉터리에서 `$sandbox_dir`를 설정한 후 `$sandbox_dir/bin/agent`를 실행하세요. 샌드박스 디렉터리는 이식 가능하고 파일 시스템에 있는 모든 위치에서 실행 가능합니다. 샌드박스 디렉터리는 기본값으로 `~/.datadog-agent`로 설정되어 있습니다. +설치를 영구 유지하려면 `init` daemon이 현재 작업 디렉터리에서 `$sandbox_dir`를 설정한 상태로 `$sandbox_dir/bin/agent`를 실행하도록 설정합니다. 샌드박스 디렉터리는 이식 가능하며, 파일 시스템 어느 위치에서나 실행할 수 있습니다. 샌드박스 디렉터리는 기본적으로 `~/.datadog-agent`로 설정되어 있습니다. -## 참고 자료 +## 추가 읽기 {{< partial name="whats-next/whats-next.html" >}} @@ -971,4 +1150,4 @@ DD_API_KEY=MY_API_KEY sh -c "$(curl -L https://raw.githubusercontent.com/DataDog [6]: https://s3.amazonaws.com/ddagent-windows-stable/installers.json [7]: https://s3.amazonaws.com/ddagent-windows-stable/ddagent-cli-latest.exe [8]: /ko/integrations/azure/ -[9]: https://github.com/DataDog/dd-agent/wiki/Windows-Agent-Installation +[9]: https://github.com/DataDog/dd-agent/wiki/Windows-Agent-Installation \ No newline at end of file diff --git a/content/ko/api/latest/datasets/_index.md b/content/ko/api/latest/datasets/_index.md new file mode 100644 index 0000000000000..bcee35f10c9b9 --- /dev/null +++ b/content/ko/api/latest/datasets/_index.md @@ -0,0 +1,3 @@ +--- +title: 데이터셋 +--- diff --git a/content/ko/api/latest/rum-retention-filters/_index.md b/content/ko/api/latest/rum-retention-filters/_index.md new file mode 100644 index 0000000000000..ab54b2ecb658d --- /dev/null +++ b/content/ko/api/latest/rum-retention-filters/_index.md @@ -0,0 +1,3 @@ +--- +title: Rum 보존 필터 +--- diff --git a/content/ko/cloudcraft/account-management/billing-and-invoices.md b/content/ko/cloudcraft/account-management/billing-and-invoices.md new file mode 100644 index 0000000000000..8bee1ca421b70 --- /dev/null +++ b/content/ko/cloudcraft/account-management/billing-and-invoices.md @@ -0,0 +1,49 @@ +--- +title: 청구 및 인보이스 +--- + +계정 소유자는 언제든지 구독 및 결제 방법을 변경할 수 있습니다. + +
AWS Marketplace를 통해 생성된 구독은 Marketplace 계정을 통해 관리됩니다. +
+ +{{< img src="cloudcraft/account-management/billing-and-invoices/subscription-settings.png" alt="Pro Monthly 플랜 세부 정보, 체험판 상태 및 Visa 카드를 사용한 결제 정보를 보여주는 Cloudcraft의 구독 관리 인터페이스." responsive="true" style="width:100%;">}} + +## 영수증 조회, 출력, 설정하기 + +1. **User** > **Subscription settings**로 이동합니다. +2. 이전 결제 내역의 영수증을 조회, 다운로드 또는 출력하려면 **Billing history**를 클릭합니다. +3. 매달 이메일로 영수증을 받도록 설정하거나 회사 주소 또는 VAT ID와 같은 추가 청구 정보를 포함하려면 **Receipt settings**을 클릭합니다. + +
+

영수증 작성 시 다음 템플릿을 참고할 수도 있습니다.

+

+ 청구 발행처:
+ Datadog, Inc.
+ 620 8th Avenue, 45th Floor
+ New York, NY 10018, USA

+ 청구 대상:
+ 사용자 회사에 대한 세부 정보 +

+
+ +## 결제 정보 업데이트 + +1. **User** > **Subscription settings**로 이동합니다. +2. **Edit card**를 클릭합니다. +3. 새로운 카드 정보를 입력한 후 **Update payment info**를 클릭합니다. + +## 연간 결제로 전환 + +언제든지 연간 구독 결제로 전환할 수 있습니다. + +1. **User** > **Subscription settings**로 이동합니다. +2. **Change plan**을 클릭한 후 **Monthly**에서 **Annual**로 전환합니다. +3. **Continue**를 클릭한 다음 **Confirm**을 클릭합니다. + +{{< img src="cloudcraft/account-management/billing-and-invoices/toggle-annual-payments.png" alt="Cloudcraft의 Pro Team 구독 플랜 스크린샷으로 연간 비용과 주요 기능(AWS 동기화, 우선 지원, 두 사용자를 위한 협업 옵션)을 강조해 보여줌." responsive="true" style="width:100%;">}} + +수표나 은행 송금으로 결제하려면 [Cloudcraft 영업팀](mailto:cloudcraft-sales@datadoghq.com)에 문의하세요. + +
이미 결제한 구독 기간은 비례하여 환산되고, 남은 크레딧은 자동으로 다음 청구 주기에 적용됩니다. +
\ No newline at end of file diff --git a/content/ko/cloudcraft/components-aws/availability-zone.md b/content/ko/cloudcraft/components-aws/availability-zone.md new file mode 100644 index 0000000000000..ae640db199989 --- /dev/null +++ b/content/ko/cloudcraft/components-aws/availability-zone.md @@ -0,0 +1,53 @@ +--- +title: Availability Zone 구성 요소 +--- +## 개요 + +Availability Zone 구성 요소를 사용하여 Amazon Web Services 아키텍처의 가용성 영역을 나타냅니다. + +{{< img src="cloudcraft/components-aws/availability-zone/component-availability-zone-diagram.png" alt="AWS 구성 요소인 'Availability zone'을 보여주는 아이소메트릭 Cloudcraft 다이어그램의 스크린샷." responsive="true" style="width:60%;">}} + +## 도구 모음 + +도구 모음을 사용해 구성 요소를 구성하고 사용자 지정할 수 있습니다. 다음 옵션을 사용할 수 있습니다. + +- **Color**: 미리 정의된 색상을 선택하거나 구성 요소의 색상 값을 16진수로 입력합니다. 2D 및 3D 보기에 같은 색상을 사용하거나 각각 다른 색상을 사용할 수 있습니다. +- **Raise**: 가용성 영역 구성 요소를 다른 가용성 영역 위로 올립니다. +- **Lower**: 가용성 영역 구성 요소를 다른 가용성 영역 아래로 내립니다. + +## API + +[Cloudcraft API][1]를 사용해 프로그래밍을 통해 액세스하여 JSON 개체의 아키텍처 다이어그램을 렌더링할 수 있습니다. + +### 스키마 + +다음은 Availability Zone 구성 요소의 JSON 객체 예입니다. + +```json +{ + "type": "zone", + "id": "a46cfaf2-ce78-4d44-9a41-a55fc7cd4ceb", + "region": "us-east-2", + "mapPos": [-6.75, 10.25], + "mapSize": [2.5, 2.5], + "color": { + "2d": "#000000", + "isometric": "#000000" + }, + "link": "blueprint://34b7a049-e92b-4146-b937-7eee9ae788b5", + "locked": true +} +``` + +- **type: zone**: 구성 요소 유형 +- **id: string**: `uuid` 형식의 구성 요소 고유 식별자 +- **region: string**: 가용성 영역이 속한 AWS 리전. `cn-` 리전을 제외한 모든 글로벌 리전이 지원됩니다. +- **mapPos: [number, number]**: 청사진에 있는 구성 요소의 포지션. X와 Y 좌표 쌍을 이용해 표현됩니다. +- **mapSize: [number, number]**. 청사진에서 가용성 영역의 크기 +- **color: object**. 가용성 영역에 채울 색상 + - **isometric: string**. 3D 보기에서 구성 요소에 채울 색상. 16진수 색상이어야 합니다. + - **2d: string**: 2D 보기에서 컴포넌트에 적용할 색상. 16진수 색상이어야 합니다. +- **link: uri**. `blueprint://ID` 형식을 사용하여 구성 요소를 다른 다이어그램에 연결하거나`https://LINK` 형식을 사용하여 외부 웹사이트에 연결합니다. +- **locked: boolean**: `true`로 설정하면 애플리케이션을 통한 구성 요소 변경은 잠금 해제 시까지 비활성화됩니다. + +[1]: https://developers.cloudcraft.co/ \ No newline at end of file diff --git a/content/ko/cloudcraft/components-aws/ec2.md b/content/ko/cloudcraft/components-aws/ec2.md new file mode 100644 index 0000000000000..15474927786ce --- /dev/null +++ b/content/ko/cloudcraft/components-aws/ec2.md @@ -0,0 +1,160 @@ +--- +title: EC2 구성 요소 +--- +## 개요 + +EC2 구성 요소를 사용해 Amazon Web Services 아키텍처의 Elastic Compute 인스턴스를 표시합니다. + +{{< img src="cloudcraft/components-aws/ec2/component-ec2-diagram.png" alt="EC2 AWS 구성 요소를 보여주는 아이소메트릭 Cloudcraft 다이어그램의 스크린샷." responsive="true" style="width:60%;">}} + +## 도구 모음 + +도구 모음을 사용해 구성 요소를 구성하고 사용자 지정할 수 있습니다. 다음 옵션을 사용할 수 있습니다. + +- **Color**: 미리 정의된 색상을 선택하거나 구성 요소와 강조 색상의 16진수 값을 입력합니다. 2D 및 3D 보기에 같은 색상을 사용하거나 각각 다른 색상을 사용할 수 있습니다. +- **Transparency**: EC2 블록이 단색인지 반투명인지 선택합니다. +- **Platform**: Elastic Compute 인스턴스에 사용할 플랫폼을 선택합니다. 라이선스 요금이 있는 플랫폼을 선택하는 경우, 비용 견적이 요금에 포함됩니다. +- **Instance type**: 인스턴스 종류. 인스턴스 종류를 바꾸면 툴바에 나타나는 하드웨어 상세 정보가 하이퍼바이저에서 사용되는 것을 반영하도록 변경됩니다. +- **Size**: 인스턴스 규모. 인스턴스 종류와 마찬가지로, 툴바에 나타나는 하드웨어 상세 정보가 규모를 반영하도록 변경됩니다. +- **Billing option**: 인스턴스에 사용된 유료 모델입니다. 현재 지원되는 옵션은 On-Demand, Reserved Instance, Spot Instance입니다. + +## API + +[Cloudcraft API][1]를 사용해 프로그래밍을 통해 액세스하여 JSON 객체의 아키텍처 다이어그램을 렌더링할 수 있습니다. + +### 스키마 + +다음은 EC2 블록의 JSON 예입니다. + +```json +{ + "type": "ec2", + "id": "d2ee1b7c-4368-4384-81dc-19c9c7866623", + "region": "us-west-1", + "mapPos": [3, 9], + "transparent": false, + "platform": "linux", + "instanceType": "t3a", + "instanceSize": "xlarge", + "billingOptions": { + "type": "si", + "utilization": 0.42 + }, + "color": { + "isometric": "#e6e7e8", + "2d": "#e6e7e8" + }, + "accentColor": { + "isometric": "#4286c5", + "2d": "#4286c5" + }, + "link": "blueprint://ae6349e1-fa15-41c8-8e89-d201f9fa3cc9", + "locked": true +} +``` + +- **type: ec2**: 구성 요소 유형 +- **id: string**: `uuid` 형식의 구성 요소 고유 식별자 +- **region: string**: EC2 인스턴스가 배포된 AWS 지역. `cn-` 지역을 제외한 모든 글로벌 지역이 지원됩니다. +- **mapPos: [number, number]**: 청사진에 있는 구성 요소의 포지션. X와 Y 좌표 쌍을 이용해 표현됩니다. +- **transparent: boolean**: `true`이면 구성 요소가 3D 보기에서 반투명하게 표시됨. 2D 보기에는 적용되지 않습니다. +- **platform: string**: 인스턴스에 사용된 플랫폼. 자세한 내용은 [플랫폼에 허용되는 값](#accepted-values-for-the-platform)을 참조하세요. +- **instanceType: string**: 인스턴스 유형. 자세한 내용은 [instanceType에 허용되는 값](#accepted-values-for-instancetype)을 참조하세요. +- **instanceSize: string**: 인스턴스 크기. 자세한 내용은 [instanceSize에 허용되는 값](#accepted-values-for-instancesize)을 참조하세요. +- **billingOptions: object**: AWS에서 인스턴스에 사용되는 유료 모델. 자세한 내용은 [billingOptions에 허용되는 값](#accepted-values-for-billingoptions)을 참조하세요. +- **color: object**: 구성 요소에 적용할 색 + - **isometric: string**: 3D 보기에서 구성 요소에 적용할 색. 16진수 색이어야 합니다. + - **2d: string**: 2D 보기에서 구성 요소에 적용할 색. 16진수 색이어야 합니다. +- **accentColor: object**: 블록 상단의 구성 요소 로고 디스플레이에 적용할 강조 색입니다. + - **isometric: string**: 3D 보기의 구성 요소 강조색. 16진수 색이어야 합니다. + - **2d: string**: 2D 보기의 구성 요소 강조색. 16진수 색이어야 합니다. +- **link: uri**: `blueprint://ID` 형식을 사용해 구성 요소를 다른 다이어그램으로 연결하거나 `https://LINK` 형식을 사용해 외부 웹사이트로 연결합니다. +- **locked: boolean**: `true`로 설정하면 어플리케이션을 통한 컴포넌트 변경은 잠금 해제 시까지 비활성화됩니다. + +EC2 구성 요소는 [VPC][2], [보안 그룹][3], [자동 확장 그룹][4], [서브넷][5]에 추가할 수 있습니다. + +## `platform`에 허용되는 값 + +`platform` 키는 다음 값을 허용합니다. + +``` +linux, linuxSQL, linuxSQLWeb, linuxSQLEnterprise, rhel, sles, mswin, mswinSQL, mswinSQLWeb, mswinSQLEnterprise +``` + +## `instanceType`에 허용된 값 + +`instanceType` 키에서는 다음 값을 허용합니다. + +``` +a1, c1, c3, c4, c5, c5a, c5ad, c5d, c5n, c6g, c6gd, c6gn, cc2, cr1, d2, d3, d3en, f1, g2, g3, g3s, g4ad, g4dn, h1, hs1, i2, i3, i3en, inf1, m1, m2, m3, m4, m5, m5a, m5ad, m5d, m5dn, m5n, m5zn, m6g, m6gd, p2, p3, p3dn, p4d, r3, r4, r5, r5a, r5ad, r5b, r5d, r5dn, r5n, r6g, r6gd, t1, t2, t3, t3a, t4g, x1, x1e, z1d +``` + +## `instanceSize`에서 허용된 값 + +`instanceSize` 키에서는 다음 값을 허용합니다. + +``` +micro, nano, small, medium, large, xlarge, 2xlarge, 3xlarge, 4xlarge, 6xlarge, 8xlarge, 9xlarge, 10xlarge, 12xlarge, 16xlarge, 18xlarge, 24xlarge, 32xlarge, metal +``` + +## `billingOptions`에 허용된 값 + +`billingOptions` 키는 Cloudcraft에서 허용하는 모든 청구 옵션을 지원합니다. + +- 온디맨드 +- 예약된 인스턴스 +- 스팟 인스턴스 + +각 옵션은 `billingOptions` 객체에서 다르게 표현됩니다. + +### 온디맨드 + +``` +{ + "billingOptions": { + "type": "od", + "utilization": 1 + } +} +``` + +- **type: od**: 온디맨드의 요금 옵션은 항상 `od`입니다. +- **utilization: number**: 부동 소수점은 해당 월의 인스턴스 사용량을 표현합니다. + +### 예약된 인스턴스 + +``` +{ + "billingOptions": { + "type": "ri", + "leaseContractLength": 36, + "purchaseOption": "Partial Upfront", + "offeringClass": "convertible" + } +} +``` + +- **type: ri**: 예약된 인스턴스의 요금 옵션은 항상 `ri`입니다. +- **leaseContractLenght: number**: 인스턴스가 예약된 기간. 허용값은 12 또는 36. +- **purchaseOption: string**: 인스턴스의 구매 옵션. 허용된 값은 `No Upfront`, `Partial Upfront`, `All Upfront`입니다. +- **offeringClass: string**: 인스턴스 제공 유형. 허용값은 `standard` 및 `convertible` + +### 스팟 인스턴스 + +``` +{ + "billingOptions": { + "type": "si", + "utilization": 0.42 + } +} +``` + +- **type: si**: Spot Instance의 청구 옵션 값은 항상 `si`. +- **utilization: number**: 부동 소수점은 해당 월의 인스턴스 사용량을 표현합니다. + +[1]: https://developers.cloudcraft.co/ +[2]: /ko/cloudcraft/components-aws/vpc/ +[3]: /ko/cloudcraft/components-aws/security-group/ +[4]: /ko/cloudcraft/components-aws/auto-scaling-group/ +[5]: /ko/cloudcraft/components-aws/subnet/ \ No newline at end of file diff --git a/content/ko/cloudcraft/components-aws/s3.md b/content/ko/cloudcraft/components-aws/s3.md new file mode 100644 index 0000000000000..f4aefab2d60a9 --- /dev/null +++ b/content/ko/cloudcraft/components-aws/s3.md @@ -0,0 +1,72 @@ +--- +title: S3 컴포넌트 +--- +## 개요 + +S3 컴포넌트로 Amazon Web Services 아키텍처에서 S3 버킷을 표시합니다. + +{{< img src="cloudcraft/components-aws/s3/component-s3-diagram.png" alt="'S3' AWS 컴포넌트를 보여주는 아이소메트릭 Cloudcraft 다이어그램 스크린샷." responsive="true" style="width:60%;">}} + +## 도구 모음 + +도구 모음을 사용해 구성 요소를 구성하고 사용자 지정할 수 있습니다. 다음 옵션을 사용할 수 있습니다. + +- **Color**: 컴포넌트와 강조 항목에 적용할 사전 정의된 색상을 선택하거나 16진수 값을 입력할 수 있습니다. 컴포넌트에서는 2D와 3D 모두에 같은 색상을 사용하거나 각각에 다른 색상을 적용할 수 있습니다. +- **Volume type**: S3 버킷에서 사용되는 볼륨 유형입니다. +- **Storage**: 버킷에서 사용되는 스토리지의 양(기가바이트 단위)입니다. +- **PUT/COPY/POST**: S3 버킷의 월간 `PUT`, `COPY`, `POST` 요청 수(천 단위)입니다. +- **GET and others**: S3 버킷의 월간 `GET`, `SELECT` 요청 수(천 단위) 및 기타 요청입니다. +- **Lifecycle Transition**: S3 버킷의 월간 지속 시간 전환 요청 수(천 단위)입니다. Infrequent Access 볼륨 유형을 사용하는 S3 버킷에만 사용할 수 있습니다. + + +## API + +[Cloudcraft API][1]를 사용해 프로그래밍을 통해 액세스하여 JSON 개체의 아키텍처 다이어그램을 렌더링할 수 있습니다. + +### 스키마 + +다음은 S3 컴포넌트의 JSON 예시입니다. + +```json +{ + "type": "s3", + "id": "e8622f0d-7fec-41e0-846d-fa14a6c3c9e7", + "region": "us-east-1", + "mapPos": [2.25,9.25], + "volumeType": "Standard - Infrequent Access", + "dataGb": "200", + "putCopyPostRequests": "50", + "getAndOtherRequests": "100", + "lifecycleTransitions": "200", + "color": { + "isometric": "#4286c5", + "2d": "#3f8624" + }, + "accentColor": { + "isometric": "#4286c5", + "2d": "#ffffff" + }, + "link": "blueprint://ae6349e1-fa15-41c8-8e89-d201f9fa3cc9", + "locked": true +} +``` + +- **type: s3**: 컴포넌트 유형입니다. +- **id: string**: `uuid` 형식의 구성 요소 고유 식별자입니다. +- **region: string**: S3 버킷이 배포된 AWS 리전. `cn-` 리전을 제외한 모든 글로벌 리전이 지원됩니다. +- **mapPos: [number, number]**: 청사진에 있는 구성 요소의 포지션. X와 Y 좌표 쌍을 이용해 표현됩니다. +- **volumeType: string**: S3 버킷이 사용하는 총 볼륨. 허용값은 `Standard`, `Standard - Infrequent Access` 또는 `One Zone - Infrequent Access`입니다. +- **dataGb: number**: 버킷에서 사용되는 스토리지 총량(기가바이트 단위)입니다. 기본값은 `10`입니다. +- **putCopyPostRequests: number**: 천 단위로 나타낸 월별 `PUT`, `COPY`, `POST` 요청 수. 기본값은 `0`입니다. +- **getAndOtherRequests: number**: 천 단위로 나타낸 월별 `GET`, `SELECT` 수와 기타 요청. 기본값은 `0`입니다. +- **lifecycleTransitions: number**: 천 단위로 나타낸 월별 지속 시간 전환 요청 수입니다. `Standard - Infrequent Access` 볼륨 유형만 사용할 수 있습니다. +- **color: object**: 구성 요소에 적용할 색입니다. + - **isometric: string**: 3D 보기에서 구성 요소에 적용할 색. 16진수 색이어야 합니다. + - **2d: string**: 2D 보기에서 구성 요소에 적용할 색. 16진수 색이어야 합니다. +- **accentColor: object**: 블록에 있는 구성 요소 로고의 강조색입니다. + - **isometric: string**: 3D 보기의 구성 요소 강조색. 16진수 색이어야 합니다. + - **2d: string**: 2D 보기의 구성 요소 강조색. 16진수 색이어야 합니다. +- **link: uri**: `blueprint://ID` 형식을 사용해 구성 요소를 다른 다이어그램으로 연결하거나 `https://LINK` 형식을 사용해 외부 웹사이트로 연결합니다. +- **locked: boolean**: true로 설정하면 어플리케이션을 통한 컴포넌트 변경은 잠금 해제 시까지 비활성화됩니다. + +[1]: https://developers.cloudcraft.co/ \ No newline at end of file diff --git a/content/ko/cloudcraft/components-aws/sqs.md b/content/ko/cloudcraft/components-aws/sqs.md new file mode 100644 index 0000000000000..3d1672c6a9b67 --- /dev/null +++ b/content/ko/cloudcraft/components-aws/sqs.md @@ -0,0 +1,65 @@ +--- +title: SQS 구성 요소 +--- +## 개요 + +SQS 구성 요소를 사용하여 Amazon Web Services 아키텍처의 메시지 대기열을 나타냅니다. + +{{< img src="cloudcraft/components-aws/sqs/component-sqs-diagram.png" alt="'SQS' AWS 구성 요소를 보여주는 아이소메트릭 Cloudcraft 다이어그램의 스크린샷." responsive="true" style="width:60%;">}} + +## 도구 모음 + +도구 모음을 사용해 구성 요소를 구성하고 사용자 지정할 수 있습니다. 다음 옵션을 사용할 수 있습니다. + +- **Color**: 구성 요소와 강조 항목에 적용할 사전 정의된 색상을 선택하거나 16진수 값을 입력할 수 있습니다. 구성 요소에서는 2D와 3D 모두에 같은 색상을 사용하거나 각각에 다른 색상을 적용할 수 있습니다. +- **Rotate item**: 컴포넌트를 회전하여 방향을 바꿉니다. +- **Type**: SQS 인스턴스에 대한 메시지 대기열 유형을 선택합니다. +- **Req./month (M)**: 매달 전송되는 요청 수를 백만 단위로 입력합니다. + +## API + +[Cloudcraft API][1]를 사용해 프로그래밍을 통해 액세스하여 JSON 개체의 아키텍처 다이어그램을 렌더링할 수 있습니다. + +### 스키마 + +다음은 SQS 구성 요소의 JSON 예입니다. + +```json +{ + "type": "sqs", + "id": "c671ec0c-3103-4312-9c85-286a58dbc457", + "region": "us-east-1", + "mapPos": [0,10], + "direction": "down", + "queueType": "standard", + "requests": 1, + "color": { + "isometric": "#ececed", + "2d": "#cc2264" + }, + "accentColor": { + "isometric": "#f4b934", + "2d": "#ffffff" + }, + "link": "https://aws.amazon.com/sqs/", + "locked": true +} +``` + +- **type: sqs**: 구성 요소 유형 +- **id: string**: `uuid` 형식의 구성 요소 고유 식별자 +- **region: string**: SQS가 배포된 AWS 지역. `cn-` 지역을 제외한 모든 글로벌 지역이 지원됩니다. +- **mapPos: [number, number]**: 청사진에 있는 구성 요소의 포지션. X와 Y 좌표 쌍을 이용해 표현됩니다. +- **direction: string**: 컴포넌트의 회전 또는 방향을 지정합니다. `down`, `up`, `right`, 또는 `left` 값을 허용합니다. 기본값은 `down` +- **queueType: string**: SQS 인스턴스의 메시지 대기열 유형입니다. 허용값은 `standard` 또는 `fifo` +- **requests: number**: 월간 전송된 요청 수(백만 단위). 기본값은 `1`. +- **color: object**: 구성 요소에 적용할 색 + - **isometric: string**: 3D 보기에서 구성 요소에 적용할 색. 16진수 색이어야 합니다. + - **2d: string**: 2D 보기에서 구성 요소에 적용할 색. 16진수 색이어야 합니다. +- **accentColor: object**: 블록에 있는 구성 요소 로고의 강조색 + - **isometric: string**: 3D 보기의 구성 요소 강조색. 16진수 색이어야 합니다. + - **2d: string**: 2D 보기의 구성 요소 강조색. 16진수 색이어야 합니다. +- **link: uri**: `blueprint://ID` 형식을 사용해 구성 요소를 다른 다이어그램으로 연결하거나 `https://LINK` 형식을 사용해 외부 웹사이트로 연결합니다. +- **locked: boolean**: `true`로 설정하면 애플리케이션을 사용해 변경한 항목은 잠금 해제될 때까지 비활성화 상태입니다. + +[1]: https://developers.cloudcraft.co/ \ No newline at end of file diff --git a/content/ko/cloudcraft/components-azure/aks-workload.md b/content/ko/cloudcraft/components-azure/aks-workload.md new file mode 100644 index 0000000000000..f3f17020ad3da --- /dev/null +++ b/content/ko/cloudcraft/components-azure/aks-workload.md @@ -0,0 +1,81 @@ +--- +title: AKS Workload 구성 요소 +--- + +## 개요 + +AKS Workload 구성 요소를 사용하여 Azure 환경에서 Kubernetes 워크로드를 나타내고 시각화합니다. + +{{< img src="cloudcraft/components-azure/aks-workload/component-aks-workload-diagram.png" alt="상호 연결된 Azure 구성 요소를 보여주는 아이소메트릭 Cloudcraft 다이어그램 스크린샷." responsive="true" style="width:60%;">}} + +## 도구 모음 + +도구 모음을 사용해 구성 요소를 구성하고 사용자 지정할 수 있습니다. 다음 옵션을 사용할 수 있습니다. + +- **Color**: 구성 요소와 강조 항목에 적용할 색을 선택을 선택합니다. 2D와 3D 보기에 같은 색을 적용하거나 각각 다른 색을 선택할 수 있습니다. +- **Name**: AKS 워크로드의 이름을 입력합니다. +- **Type**: 클러스터 내부의 워크로드 유형을 선택합니다. + +## API + +[Cloudcraft API][1]를 사용하여 아키텍처 다이어그램에 프로그래밍 방식으로 액세스하고 JSON 객체로 렌더링할 수 있습니다. 다음은 AKS Workload 구성 요소의 JSON 객체 예시입니다. + +### 스키마 + +```json +{ + "type": "azureaksworkload", + "id": "2d432a67-4b2b-4040-8e4b-19c513bc2491", + "resourceId": "/subscriptions/2dedf330-e79d-4b8e-82b9-13f6fa619bbb/resourceGroups/DOC-RESOURCE-GROUP/providers/Microsoft.ContainerService/managedClusters/doc-cluster/workloads/default/deployment/doc-agent", + "region": "eastus", + "mapPos": [2,3.25], + "mapSize": [4,4], + "nodes": [ + "375083c7-8212-4af6-859b-15fdc9da777d", + "42062b69-bb14-4e05-87db-fa10cb408d5a", + "26440a62-c06e-48f0-8c03-c5a3a2004050", + "28efba36-1f3f-48ef-a1df-0d5473bcbf6e" + ], + "name": "AKS Workload", + "workloadType": "deployment", + "color": { + "isometric": "#CEE0F5", + "2d": "#CEE0F5" + }, + "accentColor": { + "isometric": "#0078D4", + "2d": "#0078D4" + }, + "link": "https://azure.microsoft.com/products/kubernetes-service", + "locked": true +} +``` + +- **type: string**: 구성 요소 유형. 이 구성 요소에 대한 값은 `azureaksworkload`(문자열). +- **id: string, uuid**: 구성 요소의 고유 식별자입니다. API에서는 내부적으로 UUID v4를 사용하나 다른 고유 식별자도 사용할 수 있습니다. +- **resourceId: string**: Azure 구성 요소 내 전역 고유 식별자 +- **region: string**: 구성 요소의 Azure 리전. API가 중국을 제외한 전역 리전을 지원합니다. +- **mapPos: array**: 청사진에 있는 구성 요소 포지션. API에서는 포지션을 표현하기 위해 고유 X와 Y 좌표 쌍을 사용합니다. +- **mapSize: array**: 청사진에 있는 구성 요소 크기입니다. API에서는 고유한 너비와 높이 쌍을 사용해 크기를 표현합니다. +- **nodes: array**: 워크로드 내부의 애플리케이션 컨테이너. [AKS Pod 구성 요소][2]의 고유 식별자 배열을 허용합니다. +- **name: string**: 워크로드 이름. 기본값은 `AKS Workload` +- **workloadType: string**: 클러스터 내부의 워크로드 유형. [자세한 내용은 아래 참조](#accepted-values-for-workloadType). 기본값은 `deployment`. +- **color: object**: 구성 요소에 적용할 색 + - **isometric: string**: 구성 요소 바디의 3D 보기에 적용할 16진수 색. 기본값은 `#CEE0F5`입니다. + - **2d: string**: 구성 요소의 2D 보기에 적용할 16진수 색. 기본값은 `#CEE0F5`입니다. +- **accentColor: object**: 구성 요소 로고의 강조 색 + - **isometric: string**: 3D 보기에서 구성 요소 로고에 적용할 16진수 색상. 기본값은 `#0078D4`. + - **2d: string**: 구성 요소 로고의 2D 보기에 적용할 16진수 색. 기본값은 `#0078D4`입니다. +- **link: string, uri**: 구성 요소를 다른 다이어그램 또는 외부 웹사이트로 연결할 URL. `blueprint://` 또는 `https://` 형식 중 하나를 사용할 수 있습니다. +- **locked: boolean**: 웹 인터페이스를 통해 포지션 변경을 허용할지 여부 결정. 기본값은 `false`입니다. + +## `workloadType`에 허용되는 값 + +`workloadType` 키는 다음 문자열 값을 허용합니다. + +``` +deployment, statefulSet, daemonSet, job, cronJob +``` + +[1]: https://developers.cloudcraft.co/ +[2]: https://help.cloudcraft.co/article/218-component-aks-pod \ No newline at end of file diff --git a/content/ko/cloudcraft/components-azure/file-share.md b/content/ko/cloudcraft/components-azure/file-share.md new file mode 100644 index 0000000000000..d75542294fb61 --- /dev/null +++ b/content/ko/cloudcraft/components-azure/file-share.md @@ -0,0 +1,72 @@ +--- +title: File share 구성 요소 +--- + +## 개요 + +File Share 구성 요소를 사용하여 Azure 환경에서 파일 스토리지 서비스를 표시하고 시각화합니다. + +{{< img src="cloudcraft/components-azure/file-share/component-file-share-diagram.png" alt="상호 연결된 Azure 구성 요소를 보여주는 아이소메트릭 Cloudcraft 다이어그램의 스크린샷." responsive="true" style="width:60%;">}} + +## 도구 모음 + +도구 모음을 사용해 구성 요소를 구성하고 사용자 지정할 수 있습니다. 다음 옵션을 사용할 수 있습니다. + +- **Color**: 3D 보기 구성 요소의 강조 및 채우기 색상을 선택합니다. +- **Tier**: 파일 스토리지 서비스의 스토리지 티어를 선택합니다. +- **Redundancy**: 주요 및 보조 지역에서 데이터를 복제하는 방법을 선택합니다. +- **Data at-rest (GB)**: 파일 서비스에 프로비저닝된 크기를 입력합니다. +- **Snapshots (GB)**: 스냅샷에 사용할 수 있는 총 데이터 볼륨을 입력합니다. +- **Metadata at-rest (GB)**: 파일 시스템 메타데이터에 사용된 총 데이터 볼륨을 입력합니다. + +## API + +[Cloudcraft API][1]를 사용하여 아키텍처 다이어그램에 프로그래밍 방식으로 액세스하고 JSON 객체로 렌더링할 수 있습니다. 다음은 File Share 구성 요소의 JSON 객체 예시입니다. + +### 스키마 + +```json +{ + "type": "azurefiles", + "id": "70cc1d82-30e1-4c62-bd29-634f72cd21cf", + "region": "eastus", + "mapPos": [2,6], + "tier": "Standard", + "redundancy": "LRS", + "dataGb": 0, + "snapshotsGb": 0, + "metadataGb": 0, + "color": { + "isometric": null, + "2d": null + }, + "accentColor": { + "isometric": null, + "2d": null + }, + "link": "https://azure.microsoft.com/products/storage/files/", + "locked": true +} + +``` + +- **type: string**: 구성 요소 유형. 이 구성 요소의 값은 `azurefiles`(문자열)이어야 함. +- **id: string, uuid**: 구성 요소의 고유 식별자입니다. API에서는 내부적으로 UUID v4를 사용하나 다른 고유 식별자도 사용할 수 있습니다/ +- **resourceId: string**: Azure 구성 요소 내 전역 고유 식별자 +- **region: string**: 구성 요소의 Azure 리전. API가 중국을 제외한 전역 리전을 지원합니다. +- **mapPos: array**: 청사진에 있는 구성 요소 포지션. API에서는 포지션을 표현하기 위해 고유 X와 Y 좌표 쌍을 사용합니다. +- **tier: string**: 스토리지 서비스의 스토리지 티어로 `Premium`, `Hot`, `Cool`, `Standard`로 구성됩니다. 기본값은 `Standard`. +- **redundancy: string**: 지역 간 데이터 복제 방법의 중복성 옵션. 허용값: `LRS`, `ZRS`, `GRS`, `GZRS`. 기본값은 `LRS`. +- **dataGb: number**: 파일 서비스에 프로비저닝된 크기(기가바이트). 기본값 `0`. +- **snapshotGb: number**: 스냅샷에 사용 가능한 총 데이터 볼륨(기가바이트). 기본값은 `0`. +- **metadataGb: number**: 파일 시스템 메타데이터에 사용된 총 데이터 볼륨(기가바이트). 기본값은 `0`. +- **color: object**: 구성 요소에 적용할 색 + - **isometric: string**: 구성 요소 바디의 3D 보기에 적용할 16진수 색. 기본값은 `#CEE0F5` + - **2d: string**: 구성 요소의 2D 보기에 적용할 16진수 색. 기본값은 `null` +- **accentColor: object**: 구성 요소 로고의 강조 색 + - **isometric: string**: 구성 요소 로고의 3D 보기에 적용할 16진수 색. 기본값은 `#0078D4` + - **2d: string**: 구성 요소 로고의 2D 보기에 적용할 16진수 색. 기본값은 `null` +- **link: string, uri**: 구성 요소를 다른 다이어그램 또는 외부 웹사이트로 연결할 URL. `blueprint://` 또는 `https://` 형식 중 하나를 사용할 수 있습니다. +- **locked: boolean**: 웹 인터페이스를 통해 포지션 변경을 허용할지 여부 결정. 기본값은 `false` + +[1]: https://developers.cloudcraft.co/ \ No newline at end of file diff --git a/content/ko/cloudcraft/getting-started/group-by-presets.md b/content/ko/cloudcraft/getting-started/group-by-presets.md new file mode 100644 index 0000000000000..7fd511ce76b8e --- /dev/null +++ b/content/ko/cloudcraft/getting-started/group-by-presets.md @@ -0,0 +1,78 @@ +--- +title: Group By 및 Presets 기능 +--- + +Cloudcraft의 **Group By** 및 **Presets** 기능을 통해 사용자는 인프라, 네트워크 또는 보안과 같은 특정 사용 사례에 맞는 통찰력 있는 사용자 지정 다이어그램을 만들 수 있습니다. 이러한 도구는 클라우드 아키텍처의 시각화를 간소화하여 리소스를 더 쉽게 분석하고 관리할 수 있게 해줍니다. + +이 기능은 문제 해결, 보안 감사 수행, 네트워크 성능 평가 등 사용자가 정확하고 집중적인 다이어그램을 쉽게 생성할 수 있도록 하여 워크플로 효율성을 향상합니다. + +## Group By + +**Group By**를 사용하면 Cloudcraft에서 다양한 그룹 유형에 따라 다이어그램을 여러 섹션으로 나눌 수 있습니다. 이 기능은 리소스를 명확하고 체계적으로 볼 수 있게 해주며, 특히 복잡한 클라우드 환경을 시각화하는 데 유용합니다. + +### AWS 그룹화 옵션 + +AWS에서 리소스를 기준으로 그룹화할 수 있습니다. +- Region +- VPC +- 보안 그룹 +- 서브넷 +- Network ACL + +### Azure 그룹화 옵션 + +Azure에서는 다음을 기준으로 리소스를 그룹화할 수 있습니다. +- 리소스 그룹 +- Region +- VNet +- 서브넷 + +## Presets + +**Presets**는 미리 정의된 그룹화 및 필터 세트를 적용하는 편리한 방법을 제공하여 다양한 관점에서 리소스를 빠르게 볼 수 있게 해줍니다. 이 기능은 다이어그램에 그룹화 및 필터를 적용하는 프로세스를 간소화하여 아키텍처의 특정 측면에 집중할 수 있게 해줍니다. + +**Cloudcraft에는 인프라, 네트워크, 보안의 세 가지 기본 제공 프리셋 옵션이 있습니다.** 이와 같은 프리셋 옵션은 다양한 운영 요구 사항을 해결하도록 설계되었습니다. + +{{< img src="cloudcraft/getting-started/group-by-presets/diagram-presets.png" alt="Cloudcraft 인터페이스에서 인프라 다이어그램 프리셋이 선택된 프리셋 옵션." responsive="true" style="width:100%;">}} + +다이어그램에 프리셋을 적용하는 방법: + +1. Cloudcraft에서 **Live** 탭으로 전환합니다. +2. 다이어그램 보기 상단의 메뉴에서 원하는 프리셋을 선택합니다. +3. 선택한 프리셋을 반영하도록 다이어그램이 자동으로 업데이트됩니다. + +### 인프라 다이어그램 + +{{< img src="cloudcraft/getting-started/group-by-presets/infrastructure-diagram.png" alt="서버, 데이터베이스, 보안 구성요소 및 이들 간의 관계를 나타내는 인프라 다이어그램" responsive="true" style="width:100%;">}} + +인프라 프리셋은 광범위한 개요를 제공하며, AWS에서 리소스를 지역 및 VPC별로, Azure에서 리전 및 VNet별로 그룹화합니다. 이 프리셋은 문제 해결 또는 높은 수준의 검토를 위한 아키텍처 다이어그램을 빠르게 생성하는 데 이상적입니다. + +- AWS에서는 EBS, NAT 게이트웨이, 트랜짓 게이트웨이와 같은 컴포넌트를 제외하여 아키텍처의 가장 중요한 부분을 보여주는 깔끔한 다이어그램을 제공합니다. +- Azure에서는 Azure VNGW 및 Azure Disk와 같은 컴포넌트가 표시되지 않습니다. + +### 보안 다이어그램 + +{{< img src="cloudcraft/getting-started/group-by-presets/security-diagram.png" alt="서버, 데이터베이스, 보안 구성요소 및 이들 간의 관계를 나타내는 보안 다이어그램" responsive="true" style="width:100%;">}} + +보안 프리셋은 잠재적인 보안 노출에 중점을 두고 AWS에서 리소스를 지역, VPC 및 보안 그룹별로 그룹화합니다. 이 뷰는 보안 위험을 식별하고 인바운드 및 아웃바운드 서비스 통신에 적용되는 규칙을 이해하는 데 필수적이며, 침투 테스트 또는 보안 감사 중에 공격 표면을 매핑하는 데 적합합니다. + +- 이 프리셋은 현재 Azure 구성을 지원하지 않습니다. +- 인프라와 마찬가지로 AWS에서는 EBS, NAT 게이트웨이 및 보안 뷰를 복잡하게 만들 수 있는 기타 구성 요소를 제외합니다. 또한 구성 요소가 여러 서브넷에 속하는 경우 구성 요소가 여러 번 나타날 수 있습니다. + +### 네트워크 다이어그램 + +{{< img src="cloudcraft/getting-started/group-by-presets/network-diagram.png" alt="서버, 데이터베이스, 보안 구성 요소 및 이들 간의 관계를 나타내는 네트워크 다이어그램" responsive="true" style="width:100%;">}} + +네트워크 프리셋은 서브넷 그룹화를 도입하여 세분화를 추가로 지원하므로 지연 소스 및 트래픽 패턴을 식별하려는 네트워크 팀에 특히 유용합니다. + +- AWS에서는 EBS, S3, SNS와 같은 구성 요소를 제외합니다. +- Azure에서는 Azure Disk 및 네트워크 보안 그룹 구성 요소를 제외합니다. + +## 사용자 지정 프리셋 + +맞춤형 뷰가 필요한 경우 Cloudcraft에서 그룹 및 필터를 사용자 지정하여 개인화된 프리셋을 만들 수 있습니다. + +1. 요구 사항에 맞게 필터 및 그룹별 설정을 조정하세요. +2. **프리셋으로 저장하기** 버튼을 클릭하여 사용자 지정 구성을 새 프리셋으로 저장합니다. + +이러한 사용자 지정 프리셋을 저장하면 블루프린트에 액세스할 수 있는 사람이라면 누구나 재사용할 수 있습니다. \ No newline at end of file diff --git a/content/ko/cloudprem/processing.md b/content/ko/cloudprem/processing.md new file mode 100644 index 0000000000000..7b1f5e89d93fd --- /dev/null +++ b/content/ko/cloudprem/processing.md @@ -0,0 +1,158 @@ +--- +description: CloudPrem에서 프로세싱 파이프라인을 구성하는 방법 알아보기 +further_reading: +- link: /logs/log_configuration/processors/ + tag: 설명서 + text: Datadog Log Management Processors +- link: /cloudprem/ + tag: 설명서 + text: CloudPrem 개요 +- link: /cloudprem/installation/ + tag: 설명서 + text: CloudPrem 설치 및 Agent를 사용하여 로그 전송 +- link: /cloudprem/ingress/ + tag: 설명서 + text: CloudPrem Ingress 구성하기 +- link: /cloudprem/aws_config + tag: 설명서 + text: AWS 구성하기 +- link: /cloudprem/cluster/ + tag: 설명서 + text: 클러스터 크기 조정 및 운영 +- link: /cloudprem/architecture/ + tag: 설명서 + text: CloudPrem Architecture란? +- link: /cloudprem/troubleshooting/ + tag: 설명서 + text: 트러블슈팅 +private: true +title: 프로세싱 구성 +--- + +
CloudPrem는 Preview 버전입니다.
+ +## 개요 + +CloudPrem에는 로그를 파싱하고 보강할 수 있는 프로세싱 기능이 포함되어 있어 JSON 형식으로 된 로그를 자동으로 파싱합니다. 파이프라인과 프로세서를 정의하여 반구조화된 텍스트에서 의미 있는 정보나 속성을 추출한 후 집계에 사용할 수 있습니다. + +
CloudPrem 로그 파이프라인과 프로세서는 Datadog의 클라우드 기반 로그 파이프라인과 프로세서의 성능과 일치하도록 설계되었습니다.
+ +지원 프로세서와 미지원 프로세서 목록은 [클라우드 기반 파이프라인과의 호환성](#compatibility-with-cloud-based-pipelines)을 참고하세요. + +Datadog 파이프라인 구성과 동일한 형식을 따르는 JSON 파일을 사용하여 로그 프로세싱 파이프라인을 구성할 수 있습니다. + +## 프로세싱 설정하기 + +1. (선택 사항) Datadog에 기존 클라우드 기반 파이프라인이 있는 경우 [Logs Pipelines API][2]를 사용하여 구성을 가져올 수 있습니다. + + ```bash + curl -X GET "https://api.datadoghq.com/api/v1/logs/config/pipelines" \ + -H "Accept: application/json" \ + -H "DD-API-KEY: ${DD_API_KEY}" \ + -H "DD-APPLICATION-KEY: ${DD_APP_KEY}" > pipelines-config.json + ``` + +이 JSON 파일은 CloudPrem에서 직접 사용할 수 있습니다. + +2. Helm 차트에서 구성을 설정하려면 CloudPrem Helm 차트에서 `pipelinesConfig` 파라미터를 사용하여 JSON 구성 파일의 경로를 제공하세요. + + ```bash + helm repo update + helm upgrade -n --set-file pipelinesConfig=./pipelines-config.json -f datadog-values.yaml + ``` + + CloudPrem이 구성 파일을 성공적으로 읽으면 정보 메시지(`Successfully read pipeline config file`)를 기록합니다. 파일에 정의된 프로세서 중 CloudPrem에서 지원하지 않는 프로세서는 시작 시 무시됩니다. + **참고**: Helm은 기본 저장소인 etcd의 제한 때문에 구성 파일 크기를 1MB로 제한합니다. + +## 구성 파일 형식 + +구성은 JSON 배열이며, 각 요소는 프로세서나 중첩된 파이프라인을 나타냅니다. + +배열 내 요소의 순서는 프로세서의 순차적 실행 순서를 정의합니다. 이 구조는 Datadog API 엔드포인트 `api/v1/logs/config/pipelines`의 출력을 반영합니다. + + +```json +[ + { + // processor1 details + }, + { + // processor2 details + } +] +``` + +```json +[ + { + "type": "pipeline", + "id": "U73LOMZ9QG2iM-04OcXypA", + "name": "cluster agent logs parsing", + "enabled": true, + "filter": { + "query": "service:cluster-agent" + }, + "processors": [ + { + "type": "grok-parser", + "id": "xn2WAzysQ1asaasdfakjf", + "enabled": true, + "grok": { + "supportRules": "", + "matchRules": "agent_rule %{date(\"yyyy-MM-dd HH:mm:ss z\"):timestamp} \\| %{notSpace:agent} \\| %{word:level} \\| \\(%{notSpace:filename}:%{number:lineno} in %{word:process}\\) \\|( %{data::keyvalue(\":\")} \\|)?( - \\|)?( \\(%{notSpace:pyFilename}:%{number:pyLineno}\\) \\|)?%{data}\nagent_rule_pre_611 %{date(\"yyyy-MM-dd HH:mm:ss z\"):timestamp} \\| %{word:level} \\| \\(%{notSpace:filename}:%{number:lineno} in %{word:process}\\)%{data}\njmxfetch_rule %{date(\"yyyy-MM-dd HH:mm:ss z\"):timestamp} \\| %{notSpace:agent} \\| %{word:level}\\s+\\| %{word:class} \\| %{data}" + } + }, + { + "id": "xnsd5oanXq2893utcsQ", + "type": "status-remapper", + "enabled": true, + "sources": ["level"] + }, + { + "type": "date-remapper", + "id": "xn2WAzysQ1asdjJsb9dfb", + "enabled": true, + "sources": ["timestamp"] + } + ] + } +] +``` + +## 클라우드 기반 파이프라인과의 호환성 + +CloudPrem 프로세싱는 클라우드 기반 [Datadog Log Management][3]와 긴밀하게 연계되도록 설계되어 기존 로그 파이프라인 구성을 그대로 사용할 수 있습니다. 이는 알려지지 않았거나 지원되지 않는 프로세서를 무시함으로써 가능합니다. 그러나 몇 가지 차이점이 있습니다. +- 일부 필터 쿼리는 파싱할 수 없습니다(예:`@data.message:+*`와 같이 결합된 와일드카드가 있는 필터). +- `message`에 있는 필터에 다른 매칭 동작이 있습니다(또한 카테고리 프로세서에도 영향을 미칩니다) +- CloudPrem은 단어를 찾기 위해 정규식을 사용하지만, 해당 텍스트를 토큰화한 후 토큰과 일치하는지 비교해야 합니다. 또한 구(Phrases)는 무시됩니다. +- Groks는 내부적으로 정규식을 사용합니다. 정규식 엔진마다 매칭 동작이 약간 다를 수 있습니다. +- 일부 grok 패턴은 파싱할 수 없습니다(예: `%{?>notSpace:db.severity}`). + +무시된 프로세서는 인덱서 로그에 경고로 표시됩니다. + +### 지원 프로세서: +- attribute-remapper +- category-processor +- date-remapper +- grok-parser(호환성 제한) +- message-remapper +- 파이프라인 +- service-remapper +- status-remapper +- string-builder-processor +- trace-id-remapper + +### 미지원 프로세서: +- arithmetic-processor +- geo-ip-parser +- lookup-processor +- url-parser +- user-agent-parser + +## 참고 자료 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ko/logs/log_configuration/pipelines/?tab=source +[2]: /ko/api/latest/logs-pipelines/#get-all-pipelines +[3]: /ko/logs/log_configuration/processors/ \ No newline at end of file diff --git a/content/ko/containers/cluster_agent/commands.md b/content/ko/containers/cluster_agent/commands.md index 8dea4f51c9c0d..e3a0d4259cfb4 100644 --- a/content/ko/containers/cluster_agent/commands.md +++ b/content/ko/containers/cluster_agent/commands.md @@ -4,55 +4,115 @@ aliases: further_reading: - link: https://www.datadoghq.com/blog/datadog-cluster-agent/ tag: 블로그 - text: Datadog 클러스터 에이전트 소개 + text: Datadog Cluster Agent 소개 - link: https://www.datadoghq.com/blog/autoscale-kubernetes-datadog/ tag: 블로그 text: Datadog 메트릭으로 Kubernetes 작업량 오토스케일링 - link: /agent/cluster_agent/clusterchecks/ tag: 설명서 - text: 자동탐지로 클러스터 검사 실행 + text: Autodiscovery로 클러스터 검사 실행 - link: /agent/kubernetes/daemonset_setup/ tag: 설명서 text: Kubernetes DaemonSet 설정 - link: /agent/cluster_agent/troubleshooting/ tag: 설명서 - text: Datadog 클러스터 에이전트 트러블슈팅 -title: 클러스터 에이전트 명령 및 옵션 + text: Datadog Cluster Agent 트러블슈팅 +title: Cluster Agent 명령 및 옵션 --- -## 클러스터 에이전트 명령 +## Cluster Agent 명령 -Datadog 클러스터 에이전트에서 사용할 수 있는 명령은 다음과 같습니다: +Datadog Cluster Agent에서 사용할 수 있는 명령은 다음과 같습니다. `datadog-cluster-agent status` -: 에이전트의 구성 요소 및 상태에 대한 개요를 제공합니다. +: 에이전트의 구성 요소 및 상태에 관한 개요를 제공합니다. `datadog-cluster-agent metamap ` : `NODE_NAME`에 있는 포드와 클러스터 레벨 메타데이터(예: 엔드포인트) 사이에서 매핑의 로컬 캐시를 쿼리합니다. `NODE_NAME`를 지정하지 않으면 클러스터의 모든 노드에서 매퍼가 실행됩니다. `datadog-cluster-agent flare ` -: 노드 기반 에이전트와 마찬가지로 클러스터 에이전트는 사용된 로그와 설정을 집계하여 지원팀에 아카이브를 전달하거나 압축을 해제하여 로컬에서 사용할 수 있습니다. **참고**: 이 명령은 클러스터 에이전트 포드 내에서 실행됩니다. - -## 클러스터 에이전트 옵션 +: 노드 기반 에이전트와 마찬가지로 Cluster Agent는 사용된 로그와 설정을 집계하여 지원팀에 아카이브를 전달하거나 압축을 해제하여 로컬에서 사용할 수 있습니다. **참고**: 이 명령은 Cluster Agent 포드 내에서 실행됩니다. + +## Cluster Agent 환경 변수 + +{{< tabs >}} +{{% tab "Datadog Operator" %}} +`override.clusterAgent.env`에서 Cluster Agent 환경 변수를 설정합니다. + +{{< code-block lang="yaml" filename="datadog-agent.yaml" >}} +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + override: + clusterAgent: + env: + - name: + value: +{{< /code-block >}} + +{{% /tab %}} +{{% tab "Helm" %}} +`clusterAgent.env`에서 Cluster Agent 환경 변수를 설정합니다. : +{{< code-block lang="yaml" filename="datadog-values.yaml" >}} +clusterAgent: + env: + - name: + value: +{{< /code-block >}} + +{{% /tab %}} +{{< /tabs >}} 지원되는 환경 변수는 다음과 같습니다: `DD_API_KEY` : 사용자의 [Datadog API key][1]. +`DD_CLUSTER_CHECKS_ENABLED` +: 클러스터 검사 Autodiscovery를 활성화합니다. 기본값은 `false`입니다. + +`DD_CLUSTER_AGENT_AUTH_TOKEN` +: 에이전트 노드와 Datadog Cluster Agent 노드 간에 공유되는 32자 토큰입니다. + +`DD_CLUSTER_AGENT_KUBERNETES_SERVICE_NAME` +: Cluster Agent가 노출되는 Kubernetes 서비스 이름입니다. 기본값은 `datadog-cluster-agent`입니다. + +`DD_CLUSTER_NAME` +: 클러스터 이름. 모든 클러스터 검사 설정에 인스턴스 태그로 추가되어 있습니다. + +`DD_CLUSTER_CHECKS_ENABLED` +: True이면, 리더 Cluster Agent에서 로직 배포를 활성화합니다. 기본값은 `false`입니다. + +`DD_CLUSTER_CHECKS_NODE_EXPIRATION_TIMEOUT` +: 노드 기반 에이전트가 다운된 것으로 간주되어 풀에서 제거될 때까지의 시간(초)입니다. 기본값은 `30`초입니다. + +`DD_CLUSTER_CHECKS_WARMUP_DURATION` +: 모든 노드 기반 에이전트가 먼저 등록할 수 있도록 리더십을 획득하고 클러스터 검사 로직을 시작하는 데 걸리는 지연 시간(초)입니다. 기본값은 `30`초입니다. + +`DD_CLUSTER_CHECKS_CLUSTER_TAG_NAME` +: `DD_CLUSTER_NAME` 옵션과 함께 설정된 인스턴스 태그의 이름입니다. 기본값은`cluster_name` 입니다. + +`DD_CLUSTER_CHECKS_EXTRA_TAGS` +: 클러스터 점검 메트릭에 태그를 추가합니다. + +`DD_CLUSTER_CHECKS_ADVANCED_DISPATCHING_ENABLED` +: True이면, Cluster Agent는 로직을 배포하는 점검을 최적화하기 위해 클러스터 수준 점검 실행기에서 통계를 수집합니다. 기본값은 `false`입니다. + +`DD_CLUSTER_CHECKS_CLC_RUNNERS_PORT` +: Cluster Agent 클라이언트에서 클러스터 수준 점검 실행기에 접근하여 통계를 수집합니다. 기본값은 `5005`입니다. + `DD_HOSTNAME` -: : Datadog 클러스터 에이전트에 사용할 호스트 이름 +: : Datadog Cluster Agent에 사용할 호스트 이름 `DD_ENV` -: 클러스터 에이전트에서 내보내는 데이터에 대해 `env` 태그를 설정합니다. 클러스터 에이전트가 단일 환경 내에서 서비스를 모니터링하는 경우에만 권장됩니다. - -`DD_CLUSTER_AGENT_CMD_PORT` -: Datadog 클러스터 에이전트가 서비스할 포트입니다. 기본값은 `5005`입니다. +: Cluster Agent에서 내보내는 데이터에 대해 `env` 태그를 설정합니다. Cluster Agent가 단일 환경 내에서 서비스를 모니터링하는 경우에만 권장됩니다. `DD_USE_METADATA_MAPPER` : 클러스터 레벨 메타데이터 매핑을 활성화합니다. 기본값은 `true`입니다. -`DD_COLLECT_KUBERNETES_EVENTS` +`DD_COLLECT_KUBERNETES_EVENTS` : Kubernetes 이벤트를 수집하도록 에이전트를 설정합니다. 기본값은 `false`입니다. `DD_LEADER_ELECTION` @@ -61,23 +121,17 @@ Datadog 클러스터 에이전트에서 사용할 수 있는 명령은 다음과 `DD_LEADER_LEASE_DURATION` : 리더 선택이 활성화된 경우에만 사용됩니다. 기본값은 60초입니다. -`DD_CLUSTER_AGENT_AUTH_TOKEN` -: 노드 에이전트와 Datadog 클러스터 에이전트 간에 공유해야 하는 32자 길이의 토큰. - `DD_KUBE_RESOURCES_NAMESPACE` -: 클러스터 에이전트가 리더 선택, 이벤트 수집(선택 사항) 및 수평 포드 오토스케일링에 필요한 구성 맵을 만드는 네임스페이스를 설정합니다. - -`DD_CLUSTER_AGENT_KUBERNETES_SERVICE_NAME` -: 클러스터 에이전트가 노출되는 Kubernetes 서비스의 이름입니다. 기본값은 `datadog-cluster-agent`입니다. +: Cluster Agent가 리더 선택, 이벤트 수집(선택 사항) 및 수평 포드 오토스케일링에 필요한 구성 맵을 만드는 네임스페이스를 설정합니다. `DD_KUBERNETES_INFORMERS_RESYNC_PERIOD` -: API 서버를 쿼리하여 로컬 캐시를 다시 동기화하는 빈도(초)입니다. 기본값은 5분 또는 `300` 초입니다. +: API 서버를 쿼리하여 로컬 캐시를 다시 동기화하는 빈도(초)입니다. 기본값은 5분 또는 `300`초입니다. `DD_KUBERNETES_INFORMERS_RESTCLIENT_TIMEOUT` : API 서버와 통신하는 클라이언트의 시간 제한(초)입니다. 기본값은 `60`초입니다. -`DD_METRICS_PORT` -: Datadog 클러스터 에이전트 메트릭 포트. 기본값은 포트 `5000`. +`DD_METRICS_PORT` +: Datadog Cluster Agent 메트릭을 노출할 포트입니다. 기본값은 포트 `5000`입니다. `DD_EXTERNAL_METRICS_PROVIDER_BATCH_WINDOW` : 여러 오토스케일러에서 메트릭 집단을 처리하기 위해 대기한 시간(초)입니다. 기본값은 `10`초입니다. @@ -92,46 +146,28 @@ Datadog 클러스터 에이전트에서 사용할 수 있는 명령은 다음과 : Datadog에서 메트릭을 쿼리하는 데 사용되는 창의 크기(초)입니다. 기본값은 `300`초입니다. `DD_EXTERNAL_METRICS_LOCAL_COPY_REFRESH_RATE` -: 처리된 메트릭의 로컬 캐시를 글로벌 저장소와 다시 동기화하는 속도입니다. 클러스터 에이전트의 복제본이 여러 개 있을 때 유용합니다. - -`DD_CLUSTER_CHECKS_ENABLED` -: 클러스터 검사 자동탐지를 활성화합니다. 기본값은 `false`입니다. +: 처리된 메트릭의 로컬 캐시를 글로벌 저장소와 다시 동기화하는 속도입니다. Cluster Agent의 복제본이 여러 개 있을 때 유용합니다. `DD_EXTRA_CONFIG_PROVIDERS` -: 추가적인 자동탐지 설정 공급자. +: 추가적인 Autodiscovery 설정 공급자. `DD_EXTRA_LISTENERS` -: 실행할 추가 자동탐지 수신기. - -`DD_CLUSTER_NAME` -: 클러스터 이름. 모든 클러스터 검사 설정에 인스턴스 태그로 추가되어 있습니다. - -`DD_CLUSTER_CHECKS_CLUSTER_TAG_NAME` -: `DD_CLUSTER_NAME` 옵션과 함께 설정된 인스턴스 태그의 이름입니다. 기본값은`cluster_name` 입니다. - -`DD_CLUSTER_CHECKS_NODE_EXPIRATION_TIMEOUT` -: 노드 기반 에이전트가 다운된 것으로 간주되어 풀에서 제거될 때까지의 시간(초)입니다. 기본값은 `30`초입니다. - -`DD_CLUSTER_CHECKS_WARMUP_DURATION` -: 모든 노드 기반 에이전트가 먼저 등록할 수 있도록 리더십을 획득하고 클러스터 검사 로직을 시작하는 데 걸리는 지연 시간(초)입니다. 기본값은 `30`초입니다. - -`DD_CLUSTER_CHECKS_EXTRA_TAGS` -: 클러스터 검사 메트릭에 태그를 추가합니다. +: 실행할 추가 Autodiscovery 수신기. -`DD_PROXY_HTTPS` +`DD_PROXY_HTTPS` : HTTPS 요청의 프록시 서버를 설정합니다. -`DD_PROXY_HTTP` -: HTTP 요청의 프록시 서버를 설정합니다. +`DD_PROXY_HTTP` +: HTTP 요청용 프록시 서버를 설정합니다. -`DD_PROXY_NO_PROXY` -: 프록시를 바이패스하는 호스트 목록을 설정합니다. 이 목록은 띄어쓰기로 구분됩니다. +`DD_PROXY_NO_PROXY` +: 프록시를 우회해야 하는 호스트 목록을 설정합니다. 목록은 공백으로 구분됩니다. `DD_ADMISSION_CONTROLLER_AUTO_INSTRUMENTATION_INIT_RESOURCES_CPU` -: init 컨테이너의 CPU 요청과 제한을 구성합니다. +: 초기화 컨테이너에 대한 CPU 요청 및 제한을 설정합니다. `DD_ADMISSION_CONTROLLER_AUTO_INSTRUMENTATION_INIT_RESOURCES_MEMORY` -: init 컨테이너의 메모리 요청과 제한을 구성합니다. +: 초기화 컨테이너에 대한 메모리 요청 및 제한을 설정합니다. ## 참고 자료 diff --git a/content/ko/containers/guide/changing_container_registry.md b/content/ko/containers/guide/changing_container_registry.md index 9d1a190e53505..50b7e352ac662 100644 --- a/content/ko/containers/guide/changing_container_registry.md +++ b/content/ko/containers/guide/changing_container_registry.md @@ -4,48 +4,45 @@ aliases: title: 컨테이너 레지스트리 변경하기 --- -Datadog은 Google의 gcr.io, Azure의 ACR, AWS의 ECR 및 Docker Hub에 컨테이너 이미지를 게시합니다. +Datadog은 컨테이너 이미지를 Google gcr.io, Azure ACR, AWS ECR, Docker Hub에 게시합니다. -| dockerhub.io | gcr.io | public.ecr.aws | datadoghq.azurecr.io | -| ------------------------------------------ | --------------------------------------------------- | --------------------------------------------------------- | ------------------------------------------------------- | -| datadog/agent | gcr.io/datadoghq/agent | public.ecr.aws/datadog/agent | datadoghq.azurecr.io/agent | -| datadog/cluster-agent | gcr.io/datadoghq/cluster-agent | public.ecr.aws/datadog/cluster-agent | datadoghq.azurecr.io/cluster-agent | -| datadog/dogstatsd | gcr.io/datadoghq/dogstatsd | public.ecr.aws/datadog/dogstatsd | datadoghq.azurecr.io/dogstatsd | -| datadog/synthetics-private-location-worker | gcr.io/datadoghq/synthetics-private-location-worker | public.ecr.aws/datadog/synthetics-private-location-worker | datadoghq.azurecr.io/synthetics-private-location-worker | +{{% container-images-table %}} +ACR, GCR 또는 ECR 레지스트리에서 불러오면 Docker 허브에서 불러오는 것과 동일하게 동작합니다(Notary 제외). 동일한 명령(다른 매개변수 포함)을 사용하여 동일한 이미지를 얻을 수 있습니다. -GCR 또는 ECR 레지스트리에서 가져오는 것은 Docker Hub에서 가져오는 것과 동일하게 작동합니다(Notary 제외). 동일한 명령(다른 파라미터 포함)을 사용하여 동일한 이미지를 얻을 수 있습니다. +**참고**: ACR, ECR 및 GCR은 Notary를 지원하지 않습니다. Docker에서 가져온 이미지의 서명을 확인하는 경우 이 기능은 GCR 또는 ECR에서 작동하지 않습니다. -**참고**: ECR 및 GCR은 Notary를 지원하지 않습니다. Docker에서 가져온 이미지의 서명을 확인하는 경우 이 기능은 GCR 또는 ECR에서 작동하지 않습니다. +레지스트리를 업데이트하려면 배포 중인 컨테이너 환경 유형에 따라 레지스트리 값을 업데이트합니다. -레지스트리를 업데이트하려면 배포 중인 컨테이너 환경 유형에 따라 레지스트리 값을 업데이트해야 합니다. +**참고**: 비공개 레지스트리도 사용할 수 있지만 이미지를 비공개 레지스트리에서 가져오려면 풀 시크릿(Pull Secret)을 생성해야 합니다. +풀 시크릿을 생성하는 방법에 대한 자세한 내용은 [Kubernetes 설명서][1]를 참조하세요. ## Docker -### 레지스트리 업데이트하기 +### 레지스트리 업데이트 -컨테이너 레지스트리를 업데이트하려면 새 레지스트리에 대해 pull 명령을 실행합니다. 다양한 컨테이너 레지스트리에 대한 Docker 풀 명령을 보려면 [Docker 문서 페이지 개요][1]의 예를 참조하세요. +컨테이너 레지스트리를 업데이트하려면 새 레지스트리에 대해 Pull 명령을 실행하세요. 다른 컨테이너 레지스트리에 대한 Docker Pull 명령어를 보려면 [Docker 문서 페이지 개요][2]의 예시를 참조하세요. -## Helm 차트를 사용하는 Kubernetes +## Kubernetes에서 Helm Chart 활용 -Kubernetes(GKE, EKS, AKS 및 OpenShift 포함)에서 Datadog helm 차트를 사용하여 Datadog Agent(또는 Datadog Cluster Agent)를 배포하는 동안 컨테이너 레지스트리를 업데이트하려면 다른 레지스트리를 지정하도록 `values.yaml`을 업데이트하세요. +Datadog Helm Chart로 Kubernetes(GKE, EKS, AKS, OpenShift 포함)에 Datadog Agent(또는 Datadog Cluster Agent)를 배포하면서 컨테이너 레지스트리를 업데이트하려면 `values.yaml` 값을 업데이트하여 다른 레지스트리를 지정하세요. -### Datadog Helm 차트 >= v2.7.0 +### Datadog Helm Chart >= v2.7.0 1. `values.yaml`을 업데이트하세요. ```yaml registry: gcr.io/datadoghq ``` -2. `values.yaml`에서 `agents.image.repository`, `clusterAgent.image.repository`, `clusterChecksRunner.image.repository`에 대한 오버라이드를 제거하세요. +2. `values.yaml`에서 `agents.image.repository`, `clusterAgent.image.repository`, `clusterChecksRunner.image.repository`에 대한 재정의를 모두 삭제합니다. -### Datadog Helm 차트 < v2.7.0 +### Datadog Helm Chart < v2.7.0 -리포지토리를 `gcr.io`로 변경하세요. +리포지토리를 `gcr.io`로 변경합니다. ```yaml agents: image: - repository: gcr.io/datadoghq/agent + repository: gcr.io/datadoghq/agent clusterAgent: image: @@ -56,14 +53,31 @@ clusterChecksRunner: repository: gcr.io/datadoghq/agent ``` -Datadog Helm 차트 사용에 대한 자세한 내용은 [Datadog Kubernetes 문서][2] 및 예시 [`values.yaml`][3] 파일을 참조하세요. +Datadog Helm Chart 사용에 대한 자세한 내용은 [Datadog Kubernetes 문서][3] 및 예제 [`values.yaml`][4] 파일을 참조하세요. + +비공개 레지스트리를 사용하는 경우 각 이미지의 `[key].image.pullSecrets` 필드에 풀 시크릿(Pull secret)을 추가해야 합니다. +```yaml +agents: + image: + pullSecrets: + - name: PrivateRegistrySecret -## Datadog Operator를 사용하는 Kubernetes +clusterAgent: + image: + pullSecrets: + - name: PrivateRegistrySecret + +clusterChecksRunner: + image: + pullSecrets: + - name: PrivateRegistrySecret +``` -Datadog Operator를 사용하여 Datadog Agent (또는 Datadog Cluster Agent)를 배포하는 동안 레지스트리를 업데이트하려면: +## Kubernetes에서 Datadog Operator 활용 -1. Datadog Agent 매니페스트 파일을 업데이트하여 기본 레지스트리(`gcr.io/datadoghq`)를 재정의합니다. 예를 들어 `public.ecr.aws/datadog`을 사용하는 경우는 다음과 같습니다. +Datadog Operator로 Datadog Agent(또는 Datadog Cluster Agent)를 배포하는 동안 레지스트리를 업데이트합니다. +1. Datadog Agent 매니페스트 파일을 업데이트하여 기본 레지스트리(`gcr.io/datadoghq`)를 재정의합니다. 예를 들어 `public.ecr.aws/datadog`의 경우는 다음과 같습니다. ```yaml apiVersion: datadoghq.com/v2alpha1 kind: DatadogAgent @@ -74,69 +88,92 @@ spec: registry: gcr.io/datadoghq // .. ``` -2. `spec.override.nodeAgent.image.name`, `spec.override.clusterAgent.image.name`, `spec.override.clusterChecksRunner.image.name` 필드에 대한 오버라이드를 제거하세요. -Datadog Operator에 대한 자세한 내용은 [Operator를 사용하여 Agent 배포][4]를 참조하세요. +2. `spec.override.nodeAgent.image.name`, `spec.override.clusterAgent.image.name`, `spec.override.clusterChecksRunner.image.name` 필드에 대한 재정의를 모두 삭제합니다. +3. 비공개 레지스트리를 사용하는 경우 각 이미지의 `[key].image.pullSecrets` 필드에 풀 시크릿(Pull secret)을 추가해야 합니다. +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + override: + nodeAgent: + image: + pullSecrets: + - name: PrivateRegistrySecret + clusterAgent: + image: + pullSecrets: + - name: PrivateRegistrySecret + clusterChecksRunner: + image: + pullSecrets: + - name: PrivateRegistrySecret + // .. +``` +Datadog Operator에 대한 자세한 내용은 [Operator로 Agent 배포하기][5]를 참조하세요. -### Helm과 함께 public.ecr.aws/datadog 레지스트리 사용하기 -Helm 차트를 사용하여 Operator를 설치할 때 기본 `gcr.io/datadoghq` 레지스트리에서 `public.ecr.aws/datadog`레지스트리로 전환할 수도 있습니다. `public.ecr.aws/datadog` 레지스트리로 전환하려면: +### Helm으로 다른 컨테이너 레지스트리 사용하기 -[`values.yaml`][5]를 새 이미지로 업데이트합니다. +Helm Chart로 Operator를 설치할 때 기본 `gcr.io/datadoghq` 레지스트리에서 `datadoghq.azurecr.io`와 같은 다른 레지스트리로 전환할 수 있습니다. + +[`values.yaml`][6]을 새 이미지로 업데이트합니다. ```yaml image: - repository: public.ecr.aws/datadog + repository: datadoghq.azurecr.io ``` ## ECS -ECS에 배포하는 동안 레지스트리를 업데이트하려면 `datadog-agent-ecs.json` 파일에서 `"image"` 키 값을 `containerDefinitions`에서 `"public.ecr.aws/datadog/agent:latest"`로 변경합니다. +ECS에 배포하는 동안 레지스트리를 업데이트하려면 `datadog-agent-ecs.json` 파일에서 `containerDefinitions`의 `"image"` 키 값을 `"public.ecr.aws/datadog/agent:latest"`로 변경합니다. ```json "image": "public.ecr.aws/datadog/agent:latest", ``` -ECS에 Datadog을 배포하는 방법에 대한 자세한 내용은 [Datadog ECS ​​설명서][6] 및 예시 [`datadog-agent-ecs.json`파일][6]을 참조하세요. +ECS에 Datadog 배포하기에 대한 자세한 내용은 [Datadog ECS 문서][7] 및 예제 [`datadog-agent-ecs.json`][7] 파일을 참조하세요. ## Fargate -Fargate에 배포하는 동안 레지스트리를 업데이트하려면 `public.ecr.aws`를 사용하여 Fargate 작업 정의에서 이미지를 업데이트합니다. +Fargate에 배포하는 동안 레지스트리를 업데이트하려면 Fargate 작업 정의에서 이미지를 업데이트하여 `public.ecr.aws`을 사용합니다. ```json "image": "public.ecr.aws/datadog/agent:latest" ``` -다음에 작업이 시작되면 Docker Hub 대신 `public.ecr.aws`에서 가져옵니다. Fargate 배포에 대한 자세한 내용은 [ECS에 Agent 배포][7] 및 [EKS에 Agent 배포][8]를 참조하세요. - +다음에 작업이 시작되면 Docker Hub 대신 `public.ecr.aws`에서 가져옵니다. Fargate에 배포하는 방법에 대한 자세한 내용은 [ECS에 Agent 배포하기][8] 및 [EKS에 Agent 배포하기][9]를 참조하세요. -## 클러스터 에이전트 +## Cluster Agent -Helm 차트를 사용하여 Datadog Agent 및 Datadog Cluster Agent를 배포하는 경우 [Helm 차트를 사용하는 Kubernetes](#kubernetes-with-helm-chart)의 지침을 따르세요. 다른 업데이트는 필요하지 않습니다. 위에서 설명한 Helm `values.yaml`에 대한 변경 사항은 Cluster Agent와 Datadog Agent를 모두 가져오는 리포지토리를 변경합니다. +Helm chart로 Datadog Agent 및 Datadog Cluster Agent를 배포하는 경우, [Kubernetes에서 Helm 차트 활용](#kubernetes-with-helm-chart) 지침을 따르세요. 다른 업데이트는 필요하지 않습니다. 위에서 설명한 Helm `values.yaml`을 변경하면 Cluster Agent 및 Datadog Agent가 이미지를 가져오는 리포지토리가 변경됩니다. -Datadog Operator를 사용하여 Datadog Cluster Agent를 배포하는 경우 [Datadog Operator를 사용하는 Kubernetes](#kubernetes-with-the-datadog-operator)의 지침을 따르세요. 그러면 다른 업데이트가 필요하지 않습니다. Operator 설정 업데이트 지침은 Cluster Agent와 Datadog Agent를 모두 가져오는 리포지토리를 업데이트합니다. +Datadog Operator로 Datadog Cluster Agent를 배포하는 경우, [Kubernetes에서 Datadog Operator 활용](#kubernetes-with-the-datadog-operator) 지침을 따르세요. 다른 업데이트는 필요하지 않습니다. Operator 구성 업데이트 지침에 따르면 Cluster Agent 및 Datadog Agent가 이미지를 가져오는 리포지토리가 업데이트됩니다. -Datadog Cluster Agent에 대한 자세한 내용은 [Cluster Agent 문서][9] 및 [설정 문서][10]를 참조하세요. +Datadog Cluster Agent에 대한 자세한 내용은 [Cluster Agent 문서][10] 및 [설정 문서][11]를 참조하세요. -## Datadog Private Location 작업자를 위한 Kubernetes Helm +## Datadog Private Location 워커용 Kubernetes Helm -Private Location 작업자를 위한 레지스트리를 업데이트하려면 `datadog/synthetics-private-location-worker` 이미지를 `public.ecr.aws/datadog/synthetics-private-location-worker` 또는 `gcr.io/datadoghq/synthetics-private-location-worker` 이미지로 변경하세요. +Private Location 워커의 레지스트리를 업데이트하려면 `datadog/synthetics-private-location-worker` 이미지를 `public.ecr.aws/datadog/synthetics-private-location-worker` 또는 `gcr.io/datadoghq/synthetics-private-location-worker` 이미지로 업데이트하세요. -기본 리포지토리(`gcr.io/datadoghq`)를 변경하려면 `values.yaml`을 새 이미지로 업데이트하세요. +기본 리포지토리(`gcr.io/datadoghq`)를 변경하려면 `values.yaml`를 새 이미지로 업데이트합니다. ```yaml image: repository: gcr.io/datadoghq/synthetics-private-location-worker ``` -[1]: https://docs.datadoghq.com/ko/agent/docker/?tab=standard -[2]: https://docs.datadoghq.com/ko/agent/kubernetes/?tab=helm -[3]: https://github.com/DataDog/helm-charts/blob/dae884481c5b3c9b67fc8dbd69c944bf3ec955e9/charts/datadog/values.yaml#L19 -[4]: https://docs.datadoghq.com/ko/agent/kubernetes/?tab=operator#deploy-an-agent-with-the-operator -[5]: https://github.com/DataDog/helm-charts/blob/main/charts/datadog-operator/values.yaml#L28 -[6]: https://docs.datadoghq.com/ko/agent/amazon_ecs/?tab=awscli -[7]: https://www.datadoghq.com/blog/aws-fargate-monitoring-with-datadog/#deploy-the-agent-on-ecs -[8]: https://www.datadoghq.com/blog/aws-fargate-monitoring-with-datadog/#deploy-the-agent-on-eks -[9]: https://docs.datadoghq.com/ko/agent/cluster_agent/ -[10]: https://docs.datadoghq.com/ko/agent/cluster_agent/setup/?tab=helm \ No newline at end of file +[1]: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials +[2]: https://docs.datadoghq.com/ko/agent/docker/?tab=standard +[3]: https://docs.datadoghq.com/ko/agent/kubernetes/?tab=helm +[4]: https://github.com/DataDog/helm-charts/blob/dae884481c5b3c9b67fc8dbd69c944bf3ec955e9/charts/datadog/values.yaml#L19 +[5]: https://docs.datadoghq.com/ko/agent/kubernetes/?tab=operator#deploy-an-agent-with-the-operator +[6]: https://github.com/DataDog/helm-charts/blob/main/charts/datadog-operator/values.yaml#L28 +[7]: https://docs.datadoghq.com/ko/agent/amazon_ecs/?tab=awscli +[8]: https://www.datadoghq.com/blog/aws-fargate-monitoring-with-datadog/#deploy-the-agent-on-ecs +[9]: https://www.datadoghq.com/blog/aws-fargate-monitoring-with-datadog/#deploy-the-agent-on-eks +[10]: https://docs.datadoghq.com/ko/agent/cluster_agent/ +[11]: https://docs.datadoghq.com/ko/agent/cluster_agent/setup/?tab=helm \ No newline at end of file diff --git a/content/ko/containers/guide/how-to-import-datadog-resources-into-terraform.md b/content/ko/containers/guide/how-to-import-datadog-resources-into-terraform.md index a57c71e2c90c1..5d3722c320b96 100644 --- a/content/ko/containers/guide/how-to-import-datadog-resources-into-terraform.md +++ b/content/ko/containers/guide/how-to-import-datadog-resources-into-terraform.md @@ -7,18 +7,18 @@ title: Datadog 리소스를 Terraform으로 가져오기 ## 개요 -Terraform은 [`terraform import`][1] 명령을 통해 기존 리소스를 Terraform 상태로 가져오는 기본 방법을 지원합니다. -`terraform import . `를 통해서 가능합니다. +Terraform은 [`terraform import`][1] 명령을 통해 기존 리소스를 terraform 상태로 가져올 수 있는 즉시 사용 가능한 방법을 지원합니다. +이 작업은 `terraform import . `를 통해 수행할 수 있습니다. -이 접근 방식은 `state only`이며 Terraform 설정 파일에 HCL 리소스가 완전히 정의되어 있어야 합니다. 설정을 완전히 가져오려면, Terraformer와 같은 도구를 사용할 수 있습니다. +이 접근 방식은 `state only`이며, terraform 설정 파일에 이미 HCL 리소스가 완전히 정의되어 있어야 합니다. 설정을 완전히 가져오려면 Terraformer과 같은 도구를 사용할 수 있습니다. ## Terraformer -[terraformer 프로젝트][2]를 사용하면 상태 및 HCL 설정으로 리소스를 가져올 수 있습니다. +[Terraformer 프로젝트][2]를 사용하면 상태와 HCL 설정 모두로 리소스를 가져오기할 수 있습니다. -일단 설치되면 기본 `main.tf`로 terraform 디렉터리를 설정할 수 있습니다 +설치가 완료되면 기본 `main.tf`를 통해 terraform 디렉터리를 설정할 수 있습니다. -이것은 Terraform 0.13+ 구문을 사용하지만 [공식 Datadog 공급자 문서][3]에서 더 많은 설정을 찾을 수 있습니다. +다음은 terraform 0.13+ 구문을 사용한 것입니다. 더 많은 설정은 [공식 Datadog 공급자 문서][3]에서 확인할 수 있습니다. ```hcl # main.tf @@ -31,17 +31,17 @@ terraform { } } -# Datadog 공급자 구성 +# Configure the Datadog provider provider "datadog" {} ``` -그런 다음 이 디렉터리 내에서 `terraform init`을 실행하여 datadog terraform 공급자를 가져옵니다. +그런 다음 이 디렉터리 내에서 `terraform init`를 실행하여 Datadog terraform 공급자를 가져옵니다. -이제 `terraformer`을 사용하여 리소스를 가져올 수 있습니다. 예를 들어, 대시보드 `abc-def-ghi`를 가져오려면 다음을 실행하세요. +이제 `terraformer`을 사용하여 리소스 가져오기를 시작할 수 있습니다. 예를 들어 대시보드 `abc-def-ghi`를 가져오려면 다음을 실행할 수 있습니다. `terraformer import datadog --resources=dashboard --filter=dashboard=abc-def-ghi --api-key --app-key --api-url ` -이는 Terraform 상태 파일과 가져온 리소스를 나타내는 HCL Terraform 설정 파일이 모두 포함된 폴더 `generated`를 생성합니다. +이렇게 하면 가져온 리소스를 나타내는 HCL terraform 설정 파일과 terraform 상태 파일이 모두 포함된 `generated` 폴더가 생성됩니다. ``` generated @@ -53,34 +53,34 @@ generated └── terraform.tfstate ``` -* `dashboard.tf`: 새로 가져온 대시보드에 대한 HCL 설정 파일 -* `outputs.tf`: 다른 설정에서 잠재적으로 사용할 출력이 포함된 HCL -* `provider.tf`: `main.tf` 파일의 내용과 유사한 공급자의 HCL 초기화 -* `terraform.tfstate`: 가져온 대시보드를 나타내는 Terraform 상태 +* `dashboard.tf`: 새로 가져온 HCL 설정 파일입니다. +* `outputs.tf`: 다른 설정에서 잠재적으로 사용할 수 있는 출력을 포함하는 HCL입니다. +* `provider.tf`: 공급자 HCL 초기화로 `main.tf` 파일에 포함된 항목과 유사합니다. +* `terraform.tfstate`: 가져오기된 대시보드를 나타내는 terraform 상태입니다. ## Terraformer 실행의 다른 예 -모든 예시 명령에는 `--api-key`, `--app-key`, and `--api-url` 플래그가 필요합니다. +모든 예제 명령에는 `--API-key`, `--app-key`, `--API-url` 플래그가 필요합니다. -* 모든 모니터 가져오기: `terraformer import datadog --resources=monitor` -* ID가 1234인 모니터 가져오기:`terraformer import datadog --resources=monitor --filter=monitor=1234` +* 모든 모니터 가져오기: `terraformer import Datadog --resources=모니터링하다` +* ID 1234로 모니터 가져오기: `terraformer import datadog --resources=monitor --filter=monitor=1234` * ID가 1234 및 12345인 모니터 가져오기:`terraformer import datadog --resources=monitor --filter=monitor=1234:12345` -* 모든 모니터 및 대시보드 가져오기: `terraformer import datadog --resources=monitor,dashboard` -* ID가 1234인 모니터 및 ID가 abc-def-ghi인 대시보드 가져오기:`terraformer import datadog --resources=monitor,dashboard --filter=monitor=1234,dashboard=abc-def-ghi` +* 모든 모니터 및 대시보드 가져오기: `terraformer import datadog --resources=monitor,dashboard` +* ID 1234 포함 모니터 및 id abc-def-ghi 포함 대시보드 가져오기: `terraformer import datadog --resources=monitor,dashboard --filter=monitor=1234,dashboard=abc-def-ghi` -## Terraform v0.13+를 사용하여 리소스 생성 +## Terraform v0.13+로 리소스 생성하기 -버전 `0.8.10`부터 Terraformer는 Terraform `v0.12.29`를 사용하여 `tf`/`json` 및 `tfstate` 파일을 생성합니다. 호환성을 보장하려면 Terraform `v0.13.x`을 사용하여 업그레이드 명령 `terraform 0.13upgrade .`을 실행하세요. 업그레이드하려면 [공식 Terraform 문서][4]를 참조하세요. +버전 `0.8.10`부터 Terraform `v0.12.29`은 Terraform을 사용하여 `tf`/`json` 및 `tfstate` 파일을 생성합니다. 호환성을 보장하려면 Terraform `v0.13.x`을 사용하여 업그레이드 명령 `terraform 0.13upgrade .`을 실행하세요. 업그레이드에 대해서는 [공식 Terraform 설명서][4]를 참조하세요. -##### 생성된 파일을 Terraform v0.13+용으로 업그레이드하기: +##### 생성된 파일을 Terraform v0.13+용으로 업그레이드: -1. Terraformer를 사용하여 리소스를 가져옵니다. +1. terraformer를 사용하여 리소스를 가져옵니다. -2. 생성된 리소스 디렉터리에 Terraform `v0.13.x`, `cd`를 사용하여 `terraform 0.13upgrade .`을 실행합니다. +2. Terraform `v0.13.x`를 사용하여, 생성된 리소스 디렉터리에 `cd`를 넣고 `terraform 0.13upgrade .`를 실행합니다. -3. 공급자 설치 프로그램을 다시 실행하려면 `terraform init`를 실행하세요. +3. `terraform init`를 실행하여 공급자 설치 관리자를 다시 실행합니다. -4. Terraform 상태 파일에 업그레이드를 적용하려면 `terraform apply`를 실행하세요. +4. `terraform apply`를 실행하여 Terraform 상태 파일에 업그레이드를 적용합니다. [1]: https://www.terraform.io/docs/import/index.html [2]: https://github.com/GoogleCloudPlatform/terraformer diff --git a/content/ko/containers/guide/operator-eks-addon.md b/content/ko/containers/guide/operator-eks-addon.md new file mode 100644 index 0000000000000..640979f0f6f18 --- /dev/null +++ b/content/ko/containers/guide/operator-eks-addon.md @@ -0,0 +1,154 @@ +--- +aliases: +- /ko/agent/guide/operator-eks-addon +further_reading: +- link: agent/kubernetes/log + tag: 설명서 + text: Datadog와 쿠버네티스(Kubernetes) +title: Datadog Operator 애드온을 사용해 Amazon EKS에 Datadog Agent 설치하기 +--- + +
v0.1.9부터 Datadog Operator 애드온은 Fargate 인스턴스에서 예약된 포드 자동 Agent 사이드카 주입을 지원합니다. 이 가이드에서 자세한 내용을 확인하세요.
+ + +[Datadog Operator](/containers/datadog_operator)를 [Amazon EKS 애드온](https://docs.aws.amazon.com/eks/latest/userguide/eks-add-ons.html)으로 설치하고 `DatadogAgent` 매니페스트를 적용하여 +Amazon EKS 클러스터에 Datadog Agent를 설치할 수 있습니다. + +Operator 애드온을 사용해 설치한 Agent는 EC2 인스턴스에서 실행되는 포드에서만 데이터를 수집합니다. AWS Fargate에서 실행되는 포드의 경우 [AWS Fargate 기반 Amazon EKS 설명서][10]를 따르세요. + +일반적인 [Helm 설치][4]와 비교할 때 애드온 설치 시에는 차이점이 존재합니다. +* Operator 설치 중 이미지는 EKS 리포지토리에서만 풀링되어야 합니다. 사용자가 이를 변경할 수 없습니다. +* Operator Helm Chart 값은 재정의될 수 있으며 [스키마 파일][3]로만 제한됩니다. + +이 제한 사항은 Operator가 EKS 애드온 정책을 준수하는 데 필요합니다. 또한 EKS가 설치 안전성을 보장하고, 애드온 환경에서 아직 지원되지 않는 기능을 비활성화하는 데 필요합니다. + +## 사전 필수 조건 + +* [Datadog Operator][1] 제품 구독 +* kubectl 설치됨 +* 애드온 설정 시 명령줄을 사용하는 경우 [AWS CLI](https://aws.amazon.com/cli/)를 사용합니다. + +## Operator 설치하기 + +{{< tabs >}} +{{% tab "Console" %}} + +* AWS 콘솔에서 EKS 클러스터로 이동합니다. +* 애드온 탭으로 이동해 *Get more add-ons*을 선택합니다. +* *Datadog Operator*를 찾아 선택합니다. 그런 다음 프롬프트를 따라 설치를 완료합니다. + +{{% /tab %}} +{{% tab "CLI" %}} + +Operator 애드온을 설치하려면 다음을 실행합니다. + ```bash + aws eks create-addon --addon-name datadog_operator --region --cluster-name + ``` + +애드온 설치는 비동기식입니다. 설치 상태를 보려면 다음을 실행합니다. + ```bash + aws eks describe-addon --addon-name datadog_operator --region --cluster-name + ``` +{{% /tab %}} +{{< /tabs >}} + +설치가 성공적인지 확인하려면 AWS Management Console, `eksctl` 또는 AWS CLI를 사용하여 `datadog-operator` 포드가 실행 중인지 확인합니다. + +## Agent 구성하기 + +Operator 애드온을 설치했다면 Datadog Agent 설정을 진행할 수 있습니다. + +지침에 따라 `DatadogAgent` 커스텀 리소스를 사용하여 Datadog Agent를 설정합니다. + +1. Operator 설치 네임스페이스로 전환합니다. 기본적으로 `datadog-agent`입니다. + ```bash + kubectl config set-context --current --namespace=datadog-agent + ``` +2. [Datadog API 및 애플리케이션 키][5]를 사용하여 Kubernetes 암호를 생성합니다. + ```bash + kubectl create secret generic datadog-secret --from-literal api-key= --from-literal app-key= + ``` + ``와 ``를 [Datadog API 및 애플리케이션 키][5]로 교체합니다. + + +3. `DatadogAgent` 배포 구성 스펙을 통해 `datadog-agent.yaml` 파일을 생성합니다. Datadog Operator는 기본 Agent와 Cluster Agent 이미지 설정을 사용하여 공공 레지스트리에서 이미지를 풀링합니다. + + 프라이빗 EKS 레지스트리에서 이미지를 풀링하려면 `global.registry`를 추가할 수 있습니다. 다음 구성은 메트릭, 로그 및 APM을 활성화합니다. + ```yaml + apiVersion: datadoghq.com/v2alpha1 + kind: DatadogAgent + metadata: + name: datadog + spec: + global: + # Required in case the Agent cannot resolve the cluster name through IMDS. See the note below. + clusterName: + registry: + credentials: + apiSecret: + secretName: datadog-secret + keyName: api-key + appSecret: + secretName: datadog-secret + keyName: app-key + features: + apm: + enabled: true + logCollection: + enabled: true + ``` + 이 Agent 인스턴스 구성은 AWS Marketplace에서 호스팅한 ECR 리포지토리에서 Datadog Agent 이미지를 풀링합니다. 해당 항목은 또한 Datadog Operator Amazon EKS 애드온에 대한 이미지를 포함하고 있습니다. 대체 항목이 필요한 경우 위 매니페스트에서 'global.registry' 엔트리를 편집하세요. + + 모든 구성 옵션은 [Operator 설정 사양][6]을 참조하세요. + + **참고:** 노드에서 IMDS v1 액세스가 차단된 경우, Agent는 클러스터 이름 및 특정 기능([Orchestrator Explorer][6])을 실행하지 못할 수 있습니다. 그러므로 Datadog에서는 `DatadogAgent` 매네페스트에서 `spec.global.ClusterName`를 추가할 것을 권장합니다. Agent가 IMDS v2를 사용해 메타데이터를 요청하도록 구성하는 방법에 대한 [메모][8]를 확인하세요. + +4. Datadog Agent를 배포하세요: + ```bash + kubectl apply -f /path/to/your/datadog-agent.yaml + ``` + + +## Operator 설치 제거 + +Agent와 Operator를 설치 제거하려면 먼저 `DatadogAgent` 커스텀 리소스를 삭제합니다. + + ```bash + kubectl delete datadogagents.datadoghq.com datadog + ``` + +모든 Agent 리소스가 삭제되었는지 확인한 다음 애드온 설치 제거를 진행합니다. + +{{< tabs >}} +{{% tab "Console" %}} + +* AWS 콘솔에서 EKS 클러스터로 이동합니다. +* 애드온 탭으로 이동하여 *Datadog Operator* 애드온을 선택합니다. +* **Remove**를 클릭한 다음 프롬프트가 나타나면 확인합니다. + +{{% /tab %}} +{{% tab "CLI" %}} + +애드온을 삭제하려면 다음을 실행합니다. + ```bash + aws eks delete-addon --addon-name datadog_operator --region --cluster-name + ``` + +{{% /tab %}} +{{< /tabs >}} + + **참고:** `DatadogAgent` 커스텀 리소스 삭제 전에 Operator 애드온을 설치 제거해도 Agent가 계속 클러스터에서 실행됩니다. Operator를 실행해야 `DatadogAgent`가 완료되기 때문에 네임스페이스 삭제가 실패합니다. 해결 방법은 이 Github [문제][9]를 참고하세요. + + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://aws.amazon.com/marketplace/pp/prodview-wedp6r37fkufe +[2]: /ko/getting_started/containers/datadog_operator +[3]: https://github.com/DataDog/helm-charts/blob/operator-eks-addon/charts/operator-eks-addon/aws_mp_configuration.schema.json +[4]: https://github.com/DataDog/helm-charts/tree/main/charts/datadog-operator +[5]: https://app.datadoghq.com/organization-settings/api-keys +[6]: https://github.com/DataDog/datadog-operator/blob/main/docs/configuration.v2alpha1.md +[7]: https://docs.datadoghq.com/ko/infrastructure/containers/orchestrator_explorer/?tab=datadogoperator +[8]: https://github.com/DataDog/datadog-agent/blob/4896a45f586f74de1da2e985f98988f0181afc36/pkg/config/config_template.yaml#L407-L416 +[9]: https://github.com/DataDog/datadog-operator/issues/654 +[10]: /ko/integrations/eks_fargate/#setup \ No newline at end of file diff --git a/content/ko/continuous_integration/explorer/search_syntax.md b/content/ko/continuous_integration/explorer/search_syntax.md index 1f76bfe6b89b5..a61aa8edb5ca7 100644 --- a/content/ko/continuous_integration/explorer/search_syntax.md +++ b/content/ko/continuous_integration/explorer/search_syntax.md @@ -1,9 +1,9 @@ --- -description: 테스트 실행 또는 파이프라인 실행 전체를 검색합니다. +description: CI Visibility Explorer에서 모든 파이프라인 실행을 검색하는 방법을 알아보세요. further_reading: - link: /continuous_integration/search tag: 설명서 - text: 필터 및 그룹 테스트와 파이프라인 + text: 파이프라인 필터링 및 그룹화 - link: /continuous_integration/explorer/facets tag: 설명서 text: 패싯에 대해 자세히 알아보기 @@ -16,13 +16,13 @@ title: CI 가시성 탐색기 검색 구문 용어에는 다음과 같은 두 가지 유형이 있습니다. -* **단일 용어**는 `test` 또는 `hello` 과 같은 단일 단어입니다. +* **단일 용어**는 `pipeline` 또는 `hello`와 같은 하나의 단어입니다. -* **시퀀스**는 `"hello dolly"`와 같이 큰따옴표로 묶인 단어의 그룹입니다. +* **시퀀스**는 `"hello dolly"`와 같이 큰 따옴표로 묶인 단어의 그룹입니다. 복잡한 쿼리로 여러 용어를 결합하려면, 대소문자를 구분해 다음 부울 연산자를 사용할 수 있습니다. -| **운영자자** | **Description** | **예시** | +| **연산자** | **설명** | **예시** | |--------------|--------------------------------------------------------------------------------------------------------|------------------------------| | `AND` | **Intersection**: 모든 용어가 선택한 이벤트에 존재합니다(추가된 것이 없으면 AND가 기본적으로 적용됨). | 인증 AND 실패 | | `OR` | **Union** 용어 중 하나가 선택한 이벤트에 포함되어 있습니다. | 인증 OR 비밀번호 | @@ -32,7 +32,7 @@ title: CI 가시성 탐색기 검색 구문 속성과 태그를 검색하기 위해 패싯을 정의하지 않아도 됩니다. 특정 속성을 검색하려면 `@`를 추가해 속성에서 검색하려는 대상을 지정합니다. 속성 검색은 대소문자를 구분해야 합니다. 자유어 검색을 사용하면 대소문자가 구분되지 않은 결과를 얻게 됩니다. -예를 들어 `git.repository.name` 속성에 관심이 있고 `Datadog/documentation` 값을 필터링하길 원하는 경우 `@git.repository.name:DataDog/documentation`를 사용합니다. +예를 들어 `git.repository.id` 속성에 관심이 있고 `Datadog/documentation` 값을 필터링하려면 `@git.repository.id:"github.com/Datadog/documentation"`를 사용합니다. 특정 문자가 포함된 속성 값을 검색하려면 이스케이핑이나 따옴표가 필요합니다. 예를 들어 `hello:world` 값을 포함하는 `my_attribute` 속성에 대해 `@my_attribute:hello\:world` 또는 `@my_attribute:"hello:world"`를 사용해 검색합니다. @@ -50,32 +50,27 @@ title: CI 가시성 탐색기 검색 구문 * `web*`은 `web`으로 시작되는 모든 로그 메시지를 찾습니다. * `*web`은 `web`으로 끝나는 모든 로그 메시지를 찾습니다. -와일드카드 검색은 이 구문을 포함하는 태그 및 속성(패싯 처리/처리 안 됨) 내에서 작동합니다. 이 쿼리는 `mongo` 문자열로 끝나는 모든 서비스를 반환합니다. -

-

+**참고**: 와일드카드는 큰따옴표 밖에서만 와일드카드로 작동합니다. 예를 들어, `@ci.pipeline.name:"*test*"`는 이름에 `*test*` 문자열이 포함된 파이프라인과 일치하고, `@ci.pipeline.name:*test*`는 이름에 `test` 문자열이 포함된 파이프라인과 일치합니다. -``` -test.service:*mongo -``` +와일드카드 검색은 이 구문을 사용하는 태그 및 속성내에서 (패싯 여부와 관계없이) 동작합니다. ### 와일드카드 검색 특수 문자를 포함하거나 이스케이핑 또는 따옴표를 필요로 하는 속성 또는 태그 값을 검색하는 경우, `?` 와일드카드를 사용해 단일 특수 문자나 공백을 찾습니다. 예를 들어 `hello world` 값이 포함된 `my_attribute` 속성을 검색하려면 `@my_attribute:hello?world`를 사용합니다. -

-## 숫자값 +## 숫자 값 숫자 속성을 검색하려면 먼저 [패싯으로 추가합니다][1]. 그런 다음 숫자 연산자(`<`, `>`, `<=`, `>=`)를 사용해 숫자 패싯에 대한 검색을 실행합니다. -예를 들어 한 주의 기간 동안 모든 테스트 실행을 검색하려면 `@duration:>=7days`를 사용합니다. +예를 들어 한 주의 기간 동안 모든 파이프라인 실행을 검색하려면 `@duration:>=7days`를 사용합니다. ## 태그 -테스트 실행 및 파이프라인 실행은 해당 항목을 생성한 [호스트][3] 및 [통합][4]에서 태그를 상속합니다. 검색과 패싯에서도 사용할 수 있습니다. +파이프라인 실행은 해당 항목을 생성한 [호스트][3] 및 [통합][4]에서 태그를 상속합니다. 검색과 패싯에서도 사용할 수 있습니다. -* `test`는 문자열 "test"를 검색합니다. -* `env:(prod OR test)`는 `env:prod` 태그 또는 `env:test` 태그를 포함하는 모든 테스트 실행이나 파이프라인 실행을 찾습니다. -* `(env:prod AND -version:beta)`는 `env:prod` 태그를 포함하고 `version:beta` 태그를 포함하지 않는 테스트 실행이나 파이프라인 실행을 찾습니다. +* `pipeline`은 문자열 "파이프라인"을 검색합니다. +* `env:(prod OR pipeline)`는 `env:prod` 태그 또는 `env:pipeline`태그를 포함하는 모든 파이프라인 실행과 매칭됩니다. +* `(env:prod AND -version:beta)`는 `env:prod` 태그를 포함하고 `version:beta` 태그를 포함하지 않는 모든 파이프라인 실행과 매칭됩니다. 태그가 [태그 모범 사례][5]를 따르지 않고 `key:value` 구문을 사용하지 않는 경우, 이 검색 쿼리(`tags:`)를 사용합니다. diff --git a/content/ko/continuous_testing/cicd_integrations/gitlab.md b/content/ko/continuous_testing/cicd_integrations/gitlab.md new file mode 100644 index 0000000000000..a3bc6f62cd518 --- /dev/null +++ b/content/ko/continuous_testing/cicd_integrations/gitlab.md @@ -0,0 +1,105 @@ +--- +aliases: +- /ko/synthetics/cicd_integrations/gitlab +description: CI/CD 파이프라인에서 Continuous Testing 테스트를 실행하기 위해 GitLab 인스턴스를 설정하세요. +further_reading: +- link: https://www.datadoghq.com/blog/monitor-ci-pipelines/ + tag: 블로그 + text: GitLab 파이프라인에서 Datadog Synthetic 테스트 실행 +- link: /continuous_integration/pipelines/gitlab/ + tag: 설명서 + text: GitLab 파이프라인에서 트레이스 설정 +title: GitLab +--- + +## 개요 + +[GitLaab][1] 파이프라인에서 Continuous Testing 테스트를 실행하고, 배포를 차단하며, 롤백을 트리거함으로써 필수 비즈니스 워크플로가 예상대로 작동할 때 프로덕션에 코드를 추가할 수 있도록 하세요. + + +[GitLab 파이프라인][2]으로 Continuous Testing 테스트를 통합하려면 [datadog-ci npm 패키지][3]를 사용하세요. + +## 설정 + +시작하기: + +1. GitLab 프로젝트에 Datadog API와 애플리케이션 키를 변수로 추가합니다. +2. GitLab 러너에 Node.js 10.24.1 버전 이상이 설치되어 있는지 확인하세요. + +자세한 정보는 [CI/CD Integrations 설정][4]을 참고하세요. + +## 간단한 구성 + +### 테스트 ID를 사용해 테스트 실행 + +{{< code-block lang="yaml" >}} +stages: + - test +synthetic-tests: + stage: test + script: + - npm install -g @datadog/datadog-ci + - datadog-ci synthetics run-tests --apiKey "$DATADOG_API_KEY" --appKey "$DATADOG_APP_KEY" --public-id xtf-w5p-z5n --public-id eif-van-tu7 +{{< /code-block >}} + +### 테그를 사용해 테스트 실행 + +{{< code-block lang="yaml" >}} +stages: + - test +synthetic-tests: + stage: test + script: + - npm install -g @datadog/datadog-ci + - datadog-ci synthetics run-tests --apiKey "$DATADOG_API_KEY" --appKey "$DATADOG_APP_KEY" -s 'tag:e2e-tests' +{{< /code-block >}} + +### 변수 재정의를 사용해 테스트 실행 + +내 CI/CD 환경에 따라 데이터나 테스트 사용자가 다른 경우 이 변수를 `-v` 명령으로 재정의할 수 있습니다. 더 자세한 정보는 `datadog-ci` NPM 패키지의 [Synthetics 명령](https://github.com/DataDog/datadog-ci/tree/master/src/commands/synthetics)을 참고하세요. + +{{< code-block lang="yaml" >}} +stages: + - test +synthetic-tests: + stage: test + script: + - npm install -g @datadog/datadog-ci + - datadog-ci synthetics run-tests --apiKey "$DATADOG_API_KEY" --appKey "$DATADOG_APP_KEY" -s 'tag:e2e-tests' -v PASSWORD="$PASSWORD" +{{< /code-block >}} + +## 고급 설정 + +### 커스텀 설정 파일을 사용해 테스트 실행 + +파이프라인 리포지토리에 커스텀 `config.json` 파일을 추가하고 파이프라인 설정에서 액세스합니다. + +{{< code-block lang="yaml" >}} +stages: + - test +synthetic-tests: + stage: test + script: + - npm install -g @datadog/datadog-ci + - datadog-ci synthetics run-tests --apiKey "$DATADOG_API_KEY" --appKey "$DATADOG_APP_KEY" --config synthetics_global.json -f synthetic_test.json +{{< /code-block >}} + +### 테스트 출력 + +이 예시는 파이프라인이 설정 파일을 확인하고 테스트를 실행하는 것을 나타냅니다: + +{{< img src="synthetics/cicd_integrations/gitlab/synthetic_test_run.png" alt="A Synthetic test running in GitLab" style="width:100%;" >}} + +테스트 출력이 성공하면 GitLab에서 다음과 같이 반환됩니다: + +{{< img src="synthetics/cicd_integrations/gitlab/successful_test_run.png" alt="A successful Synthetic test run result in a GitLab pipeline" style="width:100%;" >}} + + +## 참고 자료 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ko/integrations/gitlab/ +[2]: https://docs.gitlab.com/ee/ci/pipelines/ +[3]: https://www.npmjs.com/package/@datadog/datadog-ci +[4]: /ko/synthetics/cicd_integrations/configuration \ No newline at end of file diff --git a/content/ko/dashboards/functions/smoothing.md b/content/ko/dashboards/functions/smoothing.md index ec5e7a5dc12fc..7f516e3cd8525 100644 --- a/content/ko/dashboards/functions/smoothing.md +++ b/content/ko/dashboards/functions/smoothing.md @@ -28,7 +28,7 @@ title: 평활화 | :---- | :------- | :--------- | | `ewma_3()` | 3의 스팬에 걸쳐 지수 가중 이동 평균을 계산합니다. | `ewma_3({*})` | -참고: 스팬 값은 데이터 포인트의 수입니다. 따라서 `ewma_3()`은(는) 마지막 3개의 데이터 포인트를 사용하여 평균을 계산합니다. +참고: 스팬 값은 시계열의 가중 평균 경과 시간의 2배입니다. 그러므로 `ewma_3()`은 3일 단순 이동 평균과 비교 가능합니다. 예시: @@ -42,7 +42,7 @@ title: 평활화 | :---- | :------- | :--------- | | `ewma_5()` | 5의 스팬에 걸쳐 지수 가중 이동 평균을 계산합니다. | `ewma_5({*})` | -참고: 스팬 값은 데이터 포인트의 수입니다. 따라서 `ewma_5()`은(는) 마지막 5개 데이터 포인트를 사용하여 평균을 계산합니다. +참고: 스팬 값은 시계열의 가중 평균 경과 시간의 2배입니다. 그러므로 `ewma_5()`은 5일 단순 이동 평균과 비교 가능합니다. 예시: @@ -56,7 +56,7 @@ title: 평활화 | :---- | :------- | :--------- | | `ewma_7()` | 7의 스팬에 걸쳐 지수 가중 이동 평균을 계산합니다. | `ewma_7({*})` | -참고: 스팬 값은 데이터 포인트의 수입니다. 따라서 `ewma_7()`은(는) 마지막 7개 데이터 포인트를 사용하여 평균을 계산합니다. +참고: 스팬 값은 시계열의 가중 평균 경과 시간의 2배입니다. 그러므로 `ewma_7()`은 7일 단순 이동 평균과 비교 가능합니다. ### Ewma 10 @@ -64,7 +64,7 @@ title: 평활화 | :---- | :------- | :--------- | | `ewma_10()` | 10의 스팬에 걸쳐 지수 가중 이동 평균을 계산합니다. | `ewma_10({*})` | -참고: 스팬 값은 데이터 포인트의 수입니다. 따라서 `ewma_10()`은(는) 마지막 10개 데이터 포인트를 사용하여 평균을 계산합니다. +참고: 스팬 값은 시계열의 가중 평균 경과 시간의 2배입니다. 그러므로 `ewma_10()`은 10일 단순 이동 평균과 비교 가능합니다. 예시: @@ -78,7 +78,7 @@ title: 평활화 | :---- | :------- | :--------- | | `ewma_20()` | 20의 스팬에 걸쳐 지수 가중 이동 평균을 계산합니다. | `ewma_20({*})` | -참고: 스팬 값은 데이터 포인트의 수입니다. 따라서 `ewma_20()`은(는) 마지막 20개 데이터 포인트를 사용하여 평균을 계산합니다. +참고: 스팬 값은 시계열의 가중 평균 경과 시간의 2배입니다. 그러므로 `ewma_20()`은 20일 단순 이동 평균과 비교 가능합니다. 예시: diff --git a/content/ko/dashboards/guide/unit-override.md b/content/ko/dashboards/guide/unit-override.md new file mode 100644 index 0000000000000..05ae45f9d502f --- /dev/null +++ b/content/ko/dashboards/guide/unit-override.md @@ -0,0 +1,61 @@ +--- +algolia: + tags: + - 단위 재정의 + - 커스텀 단위 +disable_toc: false +further_reading: +- link: metrics/units/ + tag: 설명서 + text: 메트릭 단위 +- link: logs/explorer/facets/#units + tag: 설명서 + text: 이벤트 단위 +- link: dashboards/widgets/ + tag: 설명서 + text: 위젯 목록 +title: 단위 재정의로 시각화 맞춤 설정 +--- + +## 개요 + +시각화의 단위 재정의 기능을 사용하면 데이터 레이블 지정 방식을 맞춤 설정할 수 있습니다. 이 가이드에서는 단위를 재정의하는 설정 옵션을 소개하고 이 옵션을 사용해 그래프를 분석하는 방법을 다룹니다. + +**참고**: 이 가이드의 예제에서는 [테이블 위젯][1]을 사용하는 경우가 많습니다. 그러나 이 위젯에만 국한되지 않습니다. + +{{< whatsnext desc="조직 수준에서 단위를 설정하려면 다음 문서를 참조하세요: ">}} + {{< nextlink href="/metrics/units">}} 메트릭 단위 설정{{< /nextlink >}} + {{< nextlink href="/logs/explorer/facets/#units">}} 이벤트 기반 쿼리의 단위 설정{{< /nextlink >}} +{{< /whatsnext >}} + +## 구성 + +Notebooks 및 Dashboard 위젯에서 셀 또는 위젯의 그래프 편집기를 찾습니다. Notebooks인 경우 **More Options**를 클릭하고, Dashboards인 경우 **Graph your data** 섹션을 찾으세요. + +{{< img src="dashboards/guide/unit_override/unit_override_config.png" alt="Change 위젯의 데이터 섹션 그래프에서 단위 재정의 옵션" style="width:100%;" >}} + +## 단위 및 크기 속성 작동 원리 + +Datadog는 단위를 감지하면 데이터 크기에 따라 가장 읽기 쉬운 단위를 자동으로 선택합니다. 예를 들어, 소스 데이터가 나노초인 경우, 위젯에는 수백 나노초 대신 분과 초 단위로 읽기 쉬운 값을 표시할 수 있습니다. + +{{< img src="dashboards/guide/unit_override/unit_override_with_autoscale.png" alt="Autoscale 단위가 활성화된 단위 재정의 설정 및 분과 초 단위로 크기가 조정된 값을 표시하는 테이블 위젯" style="width:100%;" >}} + +단위 재정의를 사용하면 값을 비교할 단일 고정 척도를 선택할 수 있습니다. 아래 예에서는 모든 값이 `minutes`로 조정되도록 구성되어 있습니다. 이는 동일한 척도에 있는 값을 직접 비교하기 위한 것입니다. + +{{< img src="dashboards/guide/unit_override/unit_override_without_autoscale.png" alt="Autoscale 단위가 비활성화된 단위 재정의 설정 및 모든 값을 분 단위로 조정하여 표시하는 테이블 위젯" style="width:100%;" >}} + +## 커스텀 단위 할당 + +위젯에 커스텀 단위를 할당하여 단위가 없는 메트릭(예: counts)에 컨텍스트를 추가합니다. + +{{< img src="dashboards/guide/unit_override/custom_unit_tests.png" alt="단위 재정의 설정, 커스텀 단위를 할당하는 Unit 드롭다운 메뉴가 표시됨" style="width:100%;" >}} + +제공된 단위 목록에 포함되지 않은 완전한 커스텀 단위를 정의합니다. 일반적인 이벤트 수 대신 10,000개의 테스트 또는 100개의 세션을 시각화하도록 지정할 수 있습니다. 이를 통해 분석 중인 데이터의 컨텍스트를 즉각적으로 얻을 수 있습니다. + +**참고**: Autoscaling의 경우 단위 계열로 인식되지 않으므로 커스텀 단위로 사용할 수 없습니다. + +## 참고 자료 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://docs.datadoghq.com/ko/dashboards/widgets/table/ \ No newline at end of file diff --git a/content/ko/dashboards/guide/version_history.md b/content/ko/dashboards/guide/version_history.md index adb2c8d8493d0..3f47c622d36ef 100644 --- a/content/ko/dashboards/guide/version_history.md +++ b/content/ko/dashboards/guide/version_history.md @@ -16,7 +16,7 @@ title: 대시보드 버전 기록 ## 개요 버전 기록은 대시보드의 변경 사항을 자동으로 추적하고 이전 버전을 저장하므로 변경 사항 및 누구에 의해 변경되었는지를 정확하게 확인할 수 있습니다. 이전 버전을 확인거나, 대시보드를 저장된 버전으로 복원하거나, 버전을 복제하여 새 대시보드를 만들 수 있습니다. -## 전제 조건 +## 사전 필수 조건 모든 대시보드에 기본적으로 30일 동안의 버전 기록이 보관됩니다. 이전 버전을 보려면 지난 30일 이내에 수정이 이루어져야 합니다. [감사 추적][1]을 활성화하면 버전 기록이 30일에서 90일로 연장됩니다. 감사 추적을 활성화하면 모든 기존 대시보드에서 30~90일 전에 이루어진 모든 편집 내용을 볼 수 있습니다. @@ -26,23 +26,23 @@ title: 대시보드 버전 기록 {{< img src="/dashboards/guide/version_history/configure_actions_version_history.png" alt="대시보드 Configure Actions 메뉴에서 버전 기록 옵션이 비활성화됨" style="width:50%;" >}} -Version History 사이드 패널에서 각 버전에 대해 다음을 확인할 수 있습니다. +Version History 측면 패널에서 각 버전에 대해 다음을 확인할 수 있습니다. - 변경한 Datadog 사용자 - 변경 날짜 및 시간 - 변경 사항 요약 및 이전 버전에 대한 변경 사항 세부 설명 -## 버전 미리보기 +## 버전 미리 보기 Version History 측면 패널에서 버전을 클릭하면 해당 버전으로 복원 시 대시보드가 어떻게 나타나는지 미리 볼 수 있습니다. 버전을 클릭하여 변경이 발생한 위치로 스크롤하고 변경된 위젯이나 셀을 강조 표시합니다. -**참고**: 미리 보기 위해 버전을 클릭하면 해당 버전으로 복원하도록 선택할 때까지 변경 사항이 저장되거나 다른 사용자가 보는 내용에 영향을 미치지 않습니다. +**참고**: 해당 버전을 미리 보기 해도 복원하도록 확실히 선택할 때까지 변경 사항이 저장되거나 다른 사용자가 보는 내용에 영향을 미치지 않습니다. ## 버전 복원하기 대시보드를 이전 버전으로 복원하는 방법에는 두 가지가 있습니다. -{{< img src="/dashboards/guide/version_history/dashboard_version_history_options.png" alt="이미지 설명" style="width:100%;" >}} +{{< img src="/dashboards/guide/version_history/dashboard_version_history_options.png" alt="Version History 사이드 패널은 과거 대시보드 버전과 복원 방법을 보여줍니다." style="width:100%;" >}} -- Version History 사이드 패널에서 복원할 버전을 선택한 후 사용자 프로필 오른쪽에 있는 케밥 메뉴를 클릭하고 **Restore this version**을 선택합니다. -- Version History 사이드 패널이 열리면 페이지 상단에 **Restore this version** 버튼이 나타납니다. +- Version History 측면 패널에서 복원할 버전을 선택한 후 사용자 프로필 오른쪽에 있는 케밥 메뉴를 클릭하고 **Restore this version**을 선택합니다. +- Version History 측면 패널이 열리면 페이지 상단에 **Restore this version** 버튼이 나타납니다. 버전을 복원하면 대시보드의 모든 사용자도 해당 버전으로 업데이트되고 복원을 표시하는 버전 기록에 새 항목이 추가됩니다. 변경 내역을 덮어쓰지 않으므로 보존 기간 내에 있는 모든 버전을 미리 보고 복원할 수 있습니다. diff --git a/content/ko/dashboards/widgets/geomap.md b/content/ko/dashboards/widgets/geomap.md index ae68665f2413a..1a5adef7f58f2 100644 --- a/content/ko/dashboards/widgets/geomap.md +++ b/content/ko/dashboards/widgets/geomap.md @@ -22,11 +22,11 @@ Geomap 위젯을 사용하면 지역을 그라데이션 또는 점으로 표현 ## 설정 -{{< img src="dashboards/widgets/geomap/geomap_setup2.png" alt="위젯 구성의 데이터 섹션 Geomap 그래프">}} +{{< img src="dashboards/widgets/geomap/geomap_setup3.png" alt="Geomap Graph 위젯 설정의 데이터 섹션">}} ### 구성 1. 시각화 레이어 선택: - * **Regions**: 국가 수준에서 측정 값 누계 + * **지역**: 국가 또는 국가 하위 수준에서 집계된 측정값입니다. * **Points**: 이벤트를 점으로 오버레이하여 지리 이벤트 데이터 표시 2. 그래프로 표시할 데이터 선택:
@@ -35,11 +35,11 @@ Geomap 위젯을 사용하면 지역을 그라데이션 또는 점으로 표현 {{% tab "리전" %}} | 데이터 소스 | 참고 | | -------------- | -------- | - |로그 이벤트 | 태그별 그룹에는 alpha-2 ISO 형식을 따르는 국가 ISO 코드가 포함되어야 합니다. 이를 위해 [GeoIP Processor][1]를 사용하거나 수작업으로 [수집한 로그에 태그][2]를 포함할 수 있습니다. 이벤트 쿼리를 구성하려면 [로그 검색 설명서][3]를 참고하세요.| - |이벤트 | 태그별 그룹에는 alpha-2 ISO 형식을 따르는 국가 ISO 코드가 포함되어야 합니다. 이를 위해 [수집된 로그에서 메트릭을 생성][4]하거나 수작업으로 [수집한 로그에 태그][2]를 포함할 수 있습니다. 메트릭 쿼리를 구성하려면 [쿼리 설명서][5]를 참고하세요.| + |로그 이벤트 | 태그별 그룹에는 국가 ISO 코드(알파-2 ISO 형식) 또는 국가 세분화 ISO 코드(ISO-3166-2 형식)가 포함되어야 합니다. 이를 위해 [GeoIP 프로세서][1]를 사용하거나 [수집 시 태그][2]를 수동으로 포함할 수 있습니다. 로그 이벤트 쿼리를 설정하려면 [로그 검색 설명서][3]를 참조하세요. + |메트릭 | 태그별 그룹에는 국가 ISO 코드(알파-2 ISO 형식) 또는 국가 세분화 ISO 코드(ISO-3166-2 형식)가 포함되어야 합니다. 수집된 로그에서 메트릭을 생성][4]하거나 [수집 시 태그][2]를 수동으로 포함할 수 있습니다. 메트릭 쿼리를 설정하려면 [쿼리 설명서][5]를 참조하세요. |RUM | RUM 쿼리를 구성하려면 [RUM 설명서][6]를 참고하세요. | |SLO | SLO 쿼리를 구성하려면 [SLO 검색 설명서][7]를 참고하세요. | - |보안 신호
애플리케이션 보안
감사 추적 | 쿼리를 구성하려면 [로그 검색 설명서][3]를 참고하세요. | + |보안 신호
앱 및 API 보호
Audit Trail | 쿼리를 설정하려면 로그 검색 설명서][3]를 참조하세요. | [1]: /logs/log_configuration/processors/#geoip-parser [2]: /getting_started/tagging/#define-tags @@ -71,6 +71,10 @@ Geomap 위젯을 사용하면 지역을 그라데이션 또는 점으로 표현 [컨텍스트 링크][7]는 기본적으로 활성화되어 있으나 토글하여 비활성화할 수 있습니다. 컨텍스트 링크를 사용하면 대시보드 위젯을 다른 페이지(Datadog 페이지나 타사 페이지)와 연결할 수 있습니다. +#### 시각적 서식 규칙 + +조건부 규칙을 사용해 Geomap 위젯의 지역 레이어 색상을 맞춤화하세요. + ## API 위젯을 **[대시보드 API][8]**와 함께 사용해야 합니다. [위젯 JSON 스키마 정의][9]를 보려면 다음 테이블을 참고하세요. diff --git a/content/ko/dashboards/widgets/profiling_flame_graph.md b/content/ko/dashboards/widgets/profiling_flame_graph.md new file mode 100644 index 0000000000000..4ff2c58decb38 --- /dev/null +++ b/content/ko/dashboards/widgets/profiling_flame_graph.md @@ -0,0 +1,64 @@ +--- +aliases: +- /ko/video-categories/flamegraph/ +description: 가장 많이 사용되는 코드 줄(CPU, 메모리 등)과 관련한 세부 정보를 그래프로 표시합니다. +further_reading: +- link: /profiler/profile_visualizations/ + tag: 설명서 + text: 프로파일 시각화에 대해 알아보기 +- link: /dashboards/graphing_json/ + tag: 설명서 + text: JSON을 사용하여 대시보드 구축 +title: 프로파일링 플레임 그래프 위젯 +widget_type: flame_graph +--- + +## 개요 + +{{< img src="dashboards/widgets/profiling_flame_graph/profiling_flame_graph.png" alt="프로파일링 플레임 그래프" >}} + +[프로파일링 플레임 그래프 시각화][1]는 CPU 및 메모리와 같이 가장 많이 사용되는 코드 줄의 세부 정보를 보여줍니다. 이 위젯을 추가하면 프로파일링된 애플리케이션의 스택 트레이스를 시각화하고 빈번한 리소스 요청을 정확하게 파악할 수 있습니다. + +## 설정 + + {{< img src="dashboards/widgets/profiling_flame_graph/profiling_flame_graph_config.png" alt="프로파일링 플레임 그래프 위젯 설정에서 데이터 섹션을 그래프로 표시합니다." style="width:100%;" >}} + +### 구성 + +1. 태그를 사용하여 프로파일링 데이터 범위를 지정합니다. 예: `host`, `container_name`, `service`, `env`, `version`. +2. **Show** 옆에 있는 드롭다운 메뉴를 클릭해 리소스를 선택합니다. 옵션으로는 `CPU Time`, `Allocated Memory`, `Thrown Exceptions`가 있습니다. +3. **by** 및 **for** 옆에 있는 드롭다운 메뉴를 클릭하여 각각 프레임 세분화 수준과 코드 출처를 선택합니다. +4. 그래프에 타이틀을 지정하거나, 제안된 타이틀 상자를 공란으로 두세요. +5. **Save**을 클릭합니다. + +### 옵션 + +#### 고급 옵션 및 필터링 + +세 개의 점으로 된 줄임표를 클릭하여 고급 옵션을 열고 색상 및 해상도를 지정합니다. + +플레임 그래프를 사용자 지정합니다. *Filter flame graph* 필드에 그래프 작업이나 필터를 추가합니다. + +#### 엔드포인트 범위 + +총 소비량(`per Minute by Endpoint`) 또는 요청당 소비량(`per Endpoint Call`)을 보기 위해 특정 엔드포인트로 필터링합니다. + +#### 함수 범위 + +다른 기준(예: `Method`, `Package`, `Thread name`, `Trace Operation`)으로 필터링합니다. + +#### 글로벌 시간 + +위젯이 커스텀 타임프레임을 사용하는지 또는 대시보드의 글로벌 타임프레임을 사용하는지 선택합니다. + +## API + +이 위젯은 **[대시보드 API][2]**와 함께 사용할 수 있습니다. [위젯 JSON 스키마 정의][3]를 참조하세요. + +## 참고 자료 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ko/profiler/profile_visualizations/#flame-graph +[2]: /ko/api/latest/dashboards/ +[3]: /ko/dashboards/graphing_json/widget_json/ \ No newline at end of file diff --git a/content/ko/dashboards/widgets/service_summary.md b/content/ko/dashboards/widgets/service_summary.md index e39061c66ba98..b65d0a5dada6a 100644 --- a/content/ko/dashboards/widgets/service_summary.md +++ b/content/ko/dashboards/widgets/service_summary.md @@ -6,37 +6,36 @@ further_reading: - link: /dashboards/graphing_json/ tag: 설명서 text: JSON을 사용하여 대시보드 구축 +- link: /tracing/services/service_page/ + tag: 설명서 + text: APM 서비스 페이지란? title: 서비스 요약 위젯 widget_type: trace_service --- -서비스 요약은 선택한 [서비스][1]의 그래프를 스크린보드에 표시합니다. +서비스는 동일한 작업을 실행하는 프로세스의 집합입니다. 예를 들어 웹 프레임워크나 데이터베이스가 있습니다. Datadog는 Service 페이지에서 볼 수 있듯, 서비스 정보를 표시하는 기본 제공 그래프를 제공합니다. 서비스 요약 위젯을 사용해 선택한 [서비스][1]의 그래프를 대시보드에 표시할 수 있습니다. {{< img src="dashboards/widgets/service_summary/service_summary.png" alt="서비스 요약" >}} -## 구성 - -{{< img src="dashboards/widgets/service_summary/service_summary_setup.png" alt="서비스 요약 구성" style="width:80%;">}} +## 설정 -### 설정 +### 구성 1. [환경][2] 및 [서비스][1]를 선택합니다. 2. 위젯 크기를 선택합니다. 3. 다음 중 표시할 정보를 선택합니다. - * Hit - * Error - * Latency + * 히트 + * 오류 + * 레이턴시 * Breakdown - * Distribution + * 분포 * Resource(**참고**: 이 옵션을 보려면 큰 위젯 크기를 선택해야 합니다.) -4. 그래프를 표시할 타임프레임과 열 수를 선택하여 표시 기본 설정을 선택합니다. +4. 열 수를 선택해 그래프를 어떻게 표시할지 설정하세요. 5. 그래프 타이틀을 입력합니다. ## API -이 위젯은 **Dashboards API**와 함께 사용할 수 있습니다. 더 많은 정보를 원하신다면 [대시보드 API 가이드][3]를 참조하세요. - -서비스 요약 위젯의 전용 [위젯 JSON 스키마 정의][4]는 다음과 같습니다. +해당 위젯은 **[대시보드 API][3]**와 함께 사용할 수 있습니다. [위젯 JSON 스키마 정의][4]에 대해서는 다음 표를 참고하세요. {{< dashboards-widgets-api >}} @@ -46,5 +45,5 @@ widget_type: trace_service [1]: /ko/tracing/services/service_page/ [2]: /ko/tracing/send_traces/ -[3]: /ko/api/v1/dashboards/ +[3]: /ko/api/latest/dashboards/ [4]: /ko/dashboards/graphing_json/widget_json/ \ No newline at end of file diff --git a/content/ko/database_monitoring/setup_oracle/selfhosted.md b/content/ko/database_monitoring/setup_oracle/selfhosted.md index 2eafcd0936ea5..b840bf8a1a277 100644 --- a/content/ko/database_monitoring/setup_oracle/selfhosted.md +++ b/content/ko/database_monitoring/setup_oracle/selfhosted.md @@ -119,7 +119,7 @@ CREATE USER datadog IDENTIFIED BY &password ; Oracle Agent conf 파일 `/etc/datadog-agent/conf.d/oracle.d/conf.yaml`을 생성합니다. 사용 가능한 설정 옵션은 [샘플 conf 파일][4]을 참조하세요. -**참고:** `7.53.0` 이하 Agent 릴리스의 설정 하위 디렉터리는 `oracle-dbm.d`입니다. +**참고:** `7.50.1`과 `7.53.0`사이의 Agent 릴리스에 대한 구성 하위 디렉터리는 `oracle-dbm.d`입니다. 자세한 내용은 [Agent 7.50.1 이상 버전에서 Oracle 통합 구성][10]을 참고하세요. {{< tabs >}} {{% tab "Multi-tenant" %}} @@ -159,16 +159,6 @@ Agent는 루트 다중 테넌트 컨테이너 데이터베이스(CDB)에만 연 에이전트 설정이 모두 완료되면 [Datadog 에이전트를 다시 시작][9]하세요. -### Oracle 통합 설치 또는 확인 - -#### 최초 설치 - -Datadog의 Integrations 페이지에서 조직에 대한 [Oracle 통합][7]을 설치합니다. 그러면 Oracle 데이터베이스의 성능을 모니터링할 수 있는 [Oracle 대시보드][2]가 계정에 설치됩니다. - -#### 기존 설치 - -{{% dbm-existing-oracle-integration-setup %}} - ### 설정 확인 [Agent의 상태 하위 명령을 실행][8]하고 **Checks** 섹션에서 `oracle`을 찾습니다. 시작하려면 Datadog의 [대시보드][2] 및 [데이터베이스][3] 페이지로 이동하세요. @@ -188,6 +178,7 @@ Datadog의 Integrations 페이지에서 조직에 대한 [Oracle 통합][7]을 [7]: https://app.datadoghq.com/integrations/oracle [8]: /ko/agent/configuration/agent-commands/#agent-status-and-information [9]: /ko/agent/guide/agent-commands/#start-stop-and-restart-the-agent +[10]: /ko/integrations/guide/oracle-check-upgrade-7.50.1/ ## 참고 자료 diff --git a/content/ko/database_monitoring/setup_postgres/troubleshooting.md b/content/ko/database_monitoring/setup_postgres/troubleshooting.md index 9bd25452ad372..6eddf0b28c6d0 100644 --- a/content/ko/database_monitoring/setup_postgres/troubleshooting.md +++ b/content/ko/database_monitoring/setup_postgres/troubleshooting.md @@ -2,9 +2,6 @@ description: Postgres에서 데이터베이스 모니터링 설정 트러블슈팅 title: Postgres에서 DMB 설정 트러블슈팅 --- -{{< site-region region="gov" >}} -해당 지역에서는 데이터베이스 모니터링이 지원되지 않습니다 -{{< /site-region >}} 이 페이지에서는 Postgres에서 데이터베이스 모니터링을 설정하고 사용할 때 발생하는 일반적인 문제와 이를 해결하는 방법을 설명합니다. 에이전트 버전에 따라 문제 해결 방법이 다를 수 있기 때문에 Datadog에서는 안정적인 최신 에이전트 버전을 사용하고 최신 [설정 설명서][1]를 참고하기를 권장합니다. @@ -108,23 +105,24 @@ psql -h localhost -U datadog -d postgres -c "select nspname from pg_extension, p psql -h localhost -U datadog -d -c "show search_path;" ``` -`datadog` 사용자의 `search_path`에 `pg_stat_statements` 스키마가 보이지 않는다면 `datadog` 사용자에 추가해야 합니다. 다음 예를 참고하세요. +`datadog` 사용자의 `search_path`에 `pg_stat_statements` 스키마가 보이지 않으면 `datadog` 사용자에 추가해야 합니다. 예를 들어 ``를 `pg_stat_statements`가 있는 스키마로 대체합니다. ```sql -ALTER ROLE datadog SET search_path = "$user",public,schema_with_pg_stat_statements; +ALTER ROLE datadog SET search_path = "$user",public,; ``` ### 특정 쿼리가 누락됨 -데이터베이스 모니터링에 일부 쿼리 데이터는 보이는데 특정 쿼리나 쿼리 그룹이 보이지 않는다면 다음 가이드를 따르세요. -| 잠재적 원인 | 해결 방법 | +일부 쿼리의 데이터가 있지만 Database 모니터링에 예상한 특정 쿼리 또는 쿼리 집합이 표시되지 않는 경우 이 가이드를 따르세요. +| 가능한 원인 | 해결 방법 |----------------------------------------|-------------------------------------------| -| Postgres 9.6에서 Datadog 사용자가 실행한 쿼리만 보인다면 설정에서 인스턴스 설정 일부가 누락된 것입니다. | Postgres 9.6에서 인스턴스를 모니터링하려면 Datadog 에이전트 인스턴스 구성에서 초기 설정 가이드에서 생성한 함수에 기반해 `pg_stat_statements_view: datadog.pg_stat_statements()`와 `pg_stat_activity_view: datadog.pg_stat_activity()` 설정을 사용해야 합니다. 이 함수는 모든 데이터베이스에 생성되어야 합니다. | -| 쿼리가 "상위 쿼리"가 아닙니다. 즉, 총 실행 시간의 합이 선택된 시간대 내 어디에서도 표준화된 상위 200개 쿼리에 들지 않는다는 뜻입니다. | 쿼리가 "Other Queries" 행에 그룹화되어 있을 수 있습니다. 어떤 쿼리를 추적하는지에 관한 자세한 정보는 [수집된 데이터][5]를 참고하세요. 추적된 상위 쿼리 수는 Datadog 고객 지원팀에 문의하여 알 수 있습니다. | -| 쿼리가 SELECT, INSERT, UPDATE, DELETE 쿼리가 아닙니다. | 기본적으로 비효용 함수는 추적되지 않습니다. 이를 수집하려면 Postgres 파라미터 `pg_stat_statements.track_utility`를 `on`으로 설정하세요. 더 자세한 정보는 [Postgres 설명서][6]를 참고하세요. | -| 함수나 저장된 절차에서 쿼리가 실행되었습니다. | 함수나 절차에서 실행된 쿼리를 추적하려면 설정 파라미터`pg_stat_statements.track`을 `on`으로 설정합니다. 더 자세한 정보는 [Postgres 설명서][6]를 참고하세요. | -| `pg_stat_statements.max` Postgres 설정 파라미터가 워크로드에 비해 너무 낮습니다. | 표준화된 쿼리가 짧은 시간 내에 대량으로 실행될 경우(10초 내에 표준화된 고유 쿼리가 수천 개 실행되는 경우), `pg_stat_statements`에 있는 버퍼가 표준화된 쿼리 모두를 처리하지 못할 수 있습니다. 이 값을 올리면 표준화된 쿼리를 추적하는 범위를 증가시킬 수 있고 생성된 SQL에서 변동률이 높을 경우 그 영향을 줄일 수 있습니다. **참고**: 열 이름에 밑줄이 있는 쿼리나 길이가 다양한 배열을 가진 쿼리는 표준화된 쿼리 변동률을 급격하게 높입니다. 예를 들어 `SELECT ARRAY[1,2]`와 `SELECT ARRAY[1,2,3]`는 `pg_stat_statements`에서 별도 쿼리로 추적됩니다. 이 설정에 관한 더 자세한 정보는 [고급 설정][7]을 참고하세요. | -| 최근 에이전트 재시작 후 쿼리가 한 번만 실행되었습니다. | 마지막 에이전트 재시작 후 10초 간격이 두 번 있을 동안 쿼리가 최소 한 번 실행되어야 쿼리 메트릭이 전송됩니다. | +| Postgres 9.6의 경우, Datadog 사용자가 실행한 쿼리만 표시되는 경우 인스턴스 구성에 일부 설정이 누락되었을 가능성이 있습니다. | Postgres 9.6의 인스턴스 모니터링의 경우, Datadog Agent 인스턴스 구성은 초기 설정 가이드에서 생성된 함수를 기반으로 `pg_stat_statements_view: datadog.pg_stat_statements()` 및 `pg_stat_activity_view: datadog.pg_stat_activity()` 설정을 사용해야 합니다. 이러한 함수는 모든 데이터베이스에서 생성되어야 합니다. | +| Datadog 사용자는 다른 사용자의 쿼리를 볼 수 있는 충분한 액세스 권한이 없습니다. | Datadog 사용자는 [`pg_monitor` 역할][25]이 있어야 `pg_stat_activity`와 같은 테이블에 액세스할 수 있습니다. Datadog 사용자에게 이 역할이 있는지 확인합니다. `GRANT pg_monitor TO datadog`. | +| 쿼리가 '상위 쿼리'가 아니므로 선택한 시간 프레임의 어느 시점에서든 총 실행 시간의 합이 정규화된 상위 200개 쿼리에 속하지 않습니다. | 쿼리는 '기타 쿼리' 행으로 그룹화될 수 있습니다. 추적되는 쿼리에 대한 자세한 내용은 [수집된 데이터][5]를 참조하세요. 추적된 상위 쿼리의 수는 Datadog 지원팀에 문의하여 늘릴 수 있습니다. | +| 쿼리가 SELECT, INSERT, UPDATE 또는 DELETE 쿼리가 아닙니다. | 비유틸리티 함수는 기본적으로 추적되지 않습니다. 이를 수집하려면 Postgres 파라미터 `pg_stat_statements.track_utility`를 `all`로 설정하세요. 자세한 내용은 [Postgres 설명서][6]를 참고하세요. | +| 쿼리가 함수 또는 저장 프로시저에서 실행됩니다. | 함수 또는 프로시저에서 실행된 쿼리를 추적하려면 구성 매개변수 `pg_stat_statements.track`을 `on`으로 설정하세요. 자세한 내용은 [Postgres 설명서][6]를 참고하세요. | +| `pg_stat_statements.max` Postgres 구성 파라미터가 워크로드에 비해 너무 낮을 수 있습니다. | 단시간에 많은 수의 정규화된 쿼리가 실행되는 경우(10초 동안 수천 개의 고유 정규화된 쿼리) `pg_stat_statements` 버퍼가 모든 정규화된 쿼리를 수용하지 못할 수 있습니다. 이 값을 늘리면 추적된 정규화된 쿼리의 적용 범위를 개선하고 생성된 SQL에서 발생하는 높은 이탈의 영향을 줄일 수 있습니다. **참고**: 열 이름이 정렬되지 않은 쿼리 또는 가변 길이의 배열을 사용하는 쿼리는 정규화된 쿼리 이탈률을 크게 증가시킬 수 있습니다. 예를 들어 `SELECT ARRAY[1,2]`와 `SELECT ARRAY[1,2,3]`는 `pg_stat_statements`에서 별도의 쿼리로 추적됩니다. 이 설정 조정에 대한 자세한 내용은 [고급 구성][7]을 참조하세요. | +| Agent가 마지막으로 재시작한 이후 쿼리가 한 번만 실행되었습니다. | 쿼리 메트릭은 Agent를 다시 시작한 이후 10초 간격으로 두 번 이상 실행된 후에만 릴리스됩니다. | ### 쿼리 샘플이 잘림 @@ -190,25 +188,25 @@ SECURITY DEFINER; 클라이언트가 Postgres [확장 쿼리 프로토콜][9]이나 준비된 문을 사용하는 경우 구문 분석한 쿼리와 원시 바인딩 파라미터가 분리되어 Datadog 에이전트가 실행 계획을 수집하지 못할 수 있습니다. 다음은 이 같은 문제를 해결할 수 있는 몇 가지 옵션입니다. -Postgres 버전 12 이상을 사용하는 경우 [Postgres 통합 설정][19]에서 다음 베타 기능을 활성화하세요. +Postgres 버전 12 이상의 경우 다음 파라미터가 [Postgres 통합 구성][19]에서 기본적으로 활성화됩니다. Agent에서 설명 계획을 수집할 수 있습니다. ``` query_samples: explain_parameterized_queries: true ... ``` -Postgres 12 이전 버전은 이 기능을 지원하지 않습니다. 그러나 클라이언트가 단순 쿼리 프로토콜을 사용하도록 강제하는 옵션이 있을 경우 Datadog에서 실행 계획을 수집하는 것을 활성화할 수 있습니다. +Postgres 12 이전 버전의 경우, 이 파라미터는 지원되지 **않습니다**. 그러나 클라이언트에서 단순 쿼리 프로토콜을 강제로 사용하는 옵션을 제공하는 경우 Datadog Agent를 사용하여 실행 계획을 수집할 수 있습니다. | 언어 | 클라이언트 | 단순 쿼리 프로토콜 설정| |----------|--------|----------------------------------------| -| Go | [pgx][10] | 설정에서 `PreferSimpleProtocol`을 단순 쿼리 프로토콜([ConnConfig 설명서][11] 참고)로 바꿉니다. 또는 `Query`나 `Exec` 호출에서 [QuerySimpleProtocol][24] 플래그를 첫 인수로 사용해 쿼리나 호출별로 적용할 수 있습니다. -| Java | [Postgres JDBC 클라이언트][12] | 설정에서 `preferQueryMode = simple`을 단순 쿼리 프로토콜로 바꾸세요([PreferQueryMode 설명서][13] 참고). | -| Python | [asyncpg][14] | 확장된 쿼리 프로토콜을 사용하며, 이를 비활성화할 수 없습니다. 준비된 문을 비활성화해도 문제가 해결되지 않습니다. 실행 계획 수집을 활성화하려면 [psycopg sql][15](또는 SQL 값을 이스케이프하는 기타 유사 SQL 포맷터)을 사용해 SQL Queries를 포맷한 후 DB 클라이언트로 전달합니다. | -| Python | [psycopg][16] | `psycopg2`는 확장된 쿼리 프로토콜을 사용하지 않기 때문에 실행 계획을 수집하는 데 문제가 없습니다.
`psycopg3`는 기본적으로 확장된 쿼리 프로토콜을 사용하며 비활성화할 수 없습니다. 준비된 문을 비활성화해도 문제가 해결되지 않습니다. 실행 계획 수집을 활성화하려면 [psycopg sql[15]을 사용해 SQL Queries를 포맷한 후 DB 클라이언트에 전달하세요. | +| 고(Go) | [pgx][10] | 설정에서 `PreferSimpleProtocol`을 단순 쿼리 프로토콜([ConnConfig 설명서][11] 참고)로 바꿉니다. 또는 `Query`나 `Exec` 호출에서 [QuerySimpleProtocol][24] 플래그를 첫 인수로 사용해 쿼리나 호출별로 적용할 수 있습니다. +| 자바(Java) | [Postgres JDBC 클라이언트][12] | 설정에서 `preferQueryMode = simple`을 단순 쿼리 프로토콜로 바꾸세요([PreferQueryMode 설명서][13] 참고). | +| 파이썬(Python) | [asyncpg][14] | 확장된 쿼리 프로토콜을 사용하며, 이를 비활성화할 수 없습니다. 준비된 문을 비활성화해도 문제가 해결되지 않습니다. 실행 계획 수집을 활성화하려면 [psycopg sql][15](또는 SQL 값을 이스케이프하는 기타 유사 SQL 포맷터)을 사용해 SQL Queries를 포맷한 후 DB 클라이언트로 전달합니다. | +| 파이썬(Python) | [psycopg][16] | `psycopg2`는 확장된 쿼리 프로토콜을 사용하지 않기 때문에 실행 계획을 수집하는 데 문제가 없습니다.
`psycopg3`는 기본적으로 확장된 쿼리 프로토콜을 사용하며 비활성화할 수 없습니다. 준비된 문을 비활성화해도 문제가 해결되지 않습니다. 실행 계획 수집을 활성화하려면 [psycopg sql[15]을 사용해 SQL Queries를 포맷한 후 DB 클라이언트에 전달하세요. | | Node | [node-postgres][17] | 확장된 쿼리 프로토콜을 사용하며 비활성화할 수 없습니다. Datadog 에이전트가 실행 계획을 수집할 수 있도록 하려면 [pg-format][18]을 사용해 SQL Queries를 포맷한 후 [node-postgres][17]로 전송합니다.| #### 데이터베이스에 있는 쿼리가 에이전트 인스턴스 설정으로 인해 무시됨 -데이터베이스에 있는 쿼리가 에이전트 인스턴스 설정 `ignore_databases`로 인해 무시됩니다. `ignore_databases` 설정에서는 `rdsadmin`과 `azure_maintenance`과 같은 기본 데이터베이스가 무시됩니다. 이와 같은 데이터베이스에는 샘플이나 실행 계획이 없습니다. 인스턴스 설정에 있는 설정 값과 [설정 파일 예시][19]에 있는 기본값을 확인하세요. +Agent 인스턴스 설정 파일 `ignore_databases`에 의해 무시되는 데이터베이스에 쿼리가 있습니다. `rdsadmin` 및 `azure_maintenance` 데이터베이스와 같은 기본 데이터베이스는 `ignore_databases` 설정에서 무시됩니다. 이러한 데이터베이스의 쿼리에는 샘플이나 설명 계획이 없습니다. 인스턴스 구성에서 이 설정의 값과 [예제 구성 파일][19]의 기본값을 확인하세요. **참고:** 에이전트 버전 <7.41.0에서는 `postgres` 데이터베이스가 기본적으로 무시됩니다. @@ -252,8 +250,8 @@ sudo apt-get install postgresql-contrib-10 [1]: /ko/database_monitoring/setup_postgres/ [2]: /ko/agent/troubleshooting/ -[3]: /ko/agent/guide/agent-commands/?tab=agentv6v7#agent-status-and-information -[4]: /ko/agent/guide/agent-log-files +[3]: /ko/agent/configuration/agent-commands/?tab=agentv6v7#agent-status-and-information +[4]: /ko/agent/configuration/agent-log-files [5]: /ko/database_monitoring/data_collected/#which-queries-are-tracked [6]: https://www.postgresql.org/docs/current/pgstatstatements.html#id-1.11.7.38.8 [7]: /ko/database_monitoring/setup_postgres/advanced_configuration @@ -273,4 +271,5 @@ sudo apt-get install postgresql-contrib-10 [21]: https://www.postgresql.org/docs/14/monitoring-stats.html#MONITORING-PG-STAT-ACTIVITY-VIEW [22]: https://www.postgresql.org/docs/12/contrib.html [23]: https://github.com/DataDog/integrations-core/blob/master/postgres/datadog_checks/postgres/data/conf.yaml.example#L281 -[24]: https://pkg.go.dev/github.com/jackc/pgx/v4#QuerySimpleProtocol \ No newline at end of file +[24]: https://pkg.go.dev/github.com/jackc/pgx/v4#QuerySimpleProtocol +[25]: https://www.postgresql.org/docs/current/predefined-roles.html#:~:text=a%20long%20time.-,pg_monitor,-Read/execute%20various \ No newline at end of file diff --git a/content/ko/developers/integrations/log_pipeline.md b/content/ko/developers/integrations/log_pipeline.md new file mode 100644 index 0000000000000..d82f8492be63f --- /dev/null +++ b/content/ko/developers/integrations/log_pipeline.md @@ -0,0 +1,238 @@ +--- +aliases: +- /ko/logs/faq/partner_log_integration +- /ko/developers/integrations/log_integration/ +description: Datadog Log Integration Pipeline 생성 방법에 대해 알아보세요. +further_reading: +- link: /integrations/#cat-log-collection + tag: 설명서 + text: 기존 Datadog 로그 통합 보기 +- link: /logs/explorer/facets/ + tag: 설명서 + text: 로그 패싯에 대해 알아보기 +- link: /logs/explorer/ + tag: 설명서 + text: 로그 탐색기에 대해 알아보기 +- link: /logs/log_configuration/pipelines/ + tag: 설명서 + text: 로그 파이프라인에 대해 알아보기 +title: 로그 파이프라인 생성 +--- +## 개요 + +이 페이지에서는 Technology Partners가 어떻게 로그 파이프라인을 생성할 수 있는지에 대해 알아봅니다. 통합에서 Datadog으로 로그를 전송하려면 로그 파이프라인이 필요합니다. + + +Datadog으로 로그를 전송하는 통합을 개발할 때, 사용자에게 최상의 경험을 제공할 수 있도록 다음 가이드를 따르세요. + +## 모범 사례 + +로그 파이프라인을 생성하기 전에 아래의 지침과 권장 사항을 참고하세요. + +통합은 지원되는 Datadog 로그 엔드포인트를 사용해야 합니다 +: 통합은 Datadog이 로그 수집을 위해 제공하는 [지원되는 엔드포인트][23] 중 하나를 사용해야 합니다. 또는 [Logs Ingestion HTTP 엔드포인트][1]를 사용하여 Datadog에 로그를 전송할 수 있습니다. + +통합은 모든 Datadog 사이트를 지원해야 합니다 +: 상황에 따라 사용자가 다양한 Datadog 사이트 중에서 선택할 수 있어야 합니다. 사이트 차이점에 대한 자세한 내용은 [Datadog 사이트 시작하기][2]를 참고하세요.

Datadog 사이트 엔드포인트는 `http-intake.logs`.{{< region-param key="dd_site" code="true" >}}입니다. + +통합 설정 시 사용자 지정 태그 추가를 허용하세요 +: 태그는 통합 로그 페이로드의 JSON 본문에 키-값 속성으로 설정할 수 있습니다. Datadog은 사용자가 통합에 대해 사용자 지정 태그를 설정할 수 있도록 허용하는 것을 권장합니다. 통합이 [API를 통해 로그를 전송하는 경우][1], `ddtags=` 쿼리 파라미터를 사용하여 태그를 설정할 수 있습니다. + +통합의 로그 `source` 태그를 통합 이름으로 설정합니다 +: Datadog은 애플리케이션에 대한 `source` 태그를 ``(`source:okta`)로 설정할 것을 권장합니다. Datadog UI에서 다시 매핑할 수 없으므로 Datadog 엔드포인트로 로그를 전송하기 전에 반드시 `source`를 설정해야 합니다.

`source` 태그는 소문자로 작성해야 하며, 통합 파이프라인 및 대시보드를 활성화하는 데 사용되므로 사용자가 편집할 수 없어야 합니다. + +가능하면 JSON 본문에 배열이 포함된 로그를 전송하지 마세요 +: Datadog에서 로그 데이터를 보낼 때 배열을 사용하는 것이 가능하지만, 배열은 [패싯][24]할 수 없으므로 사용하지 않는 것이 좋습니다. + +Datadog API 키를 기록하지 마세요 +: Datadog API 키는 API 요청 시 Header 또는 HTTP Path를 통해 전달할 수 있습니다. 자세한 내용은 [Send Logs API 문서][1]를 참고하세요. 설정에서 API 키를 기록하지 않도록 주의하세요. + +Datadog Application Keys를 사용하지 마세요 +: Datadog Application Keys는 HTTP 엔드포인트를 사용하여 로그를 전송하는 데 필요하지 않습니다. + +## 로그 통합 자산 생성하기 + +Datadog 파트너 계정 내에서 직접 로그 통합 자산을 만들고 디자인할 수 있습니다. + +로그 통합은 [파이프라인][13]과 관련 [패싯][12]이라는 두 가지 자산 세트로 구성됩니다. 다양한 기술 및 애플리케이션의 로그를 중앙에서 관리하면 여러 가지 고유한 특성을 얻을 수 있습니다. 기본 대시보드를 사용하려면 Technology Partner Integrations가 통합을 생성할 때 Datadog의 [표준 명명 규칙][17]을 따라야 합니다. + +Datadog Integration 디자인을 마무리하고 Datadog의 로그 엔드포인트로 로그를 성공적으로 전송한 후, 로그 파이프라인과 패싯을 정의하여 통합의 로그를 풍부하게 하고 구조화합니다. + +Datadog Technology Partner와 통합 개발 샌드박스 액세스에 관한 정보는 [통합 구축][18]에서 확인하세요. + +
Datadog 통합팀에서 검토하려면 로그 통합에 자산이 포함되어야 하며 파이프라인 프로세서 또는 패싯이 있어야 합니다.
+ +### 파이프라인 개요 + +Datadog으로 전송된 로그는 파이프라인 프로세서를 사용하여 [로그 파이프라인][13]에서 처리됩니다. 이 프로세서를 통해 사용자는 속성 정보를 파싱, 재매핑 및 추출하여 플랫폼 전반에서 사용할 수 있도록 로그를 풍부하게 하고 표준화할 수 있습니다. + +#### 파이프라인 생성 + +파이프라인 프로세서로 지정된 로그를 처리하기 위해 로그 파이프라인을 생성합니다. + + +1. [**Pipelines**][3] 페이지에서 **+ New Pipeline**을 클릭합니다. +2. **Filter** 필드에 Technology Partner 로그의 로그 소스를 정의하는 고유 `source` 태그를 입력합니다. 예를 들어, Okta 통합은 `source:okta`입니다. +**참고**: Datadog으로 전송되기 전 통합을 통해 전송되는 로그에 올바른 소스 태그가 적용되었는지 확인하세요. +3. (선택 사항) 태그와 설명을 추가합니다. +4. **생성**을 클릭합니다. + +파이프라인을 설정한 후 프로세서를 추가하여 로그를 더욱 구조화하고 정보를 강화합니다. +#### 파이프라인 프로세서 추가 + +파이프라인 프로세서를 정의하기 전에 [Datadog의 Standard Attributes][6]를 검토하세요. + +파이프라인 내에서 프로세서를 사용하여 데이터를 보강하고 재구성하며 로그 속성을 생성하세요. 모든 로그 프로세서 목록은 [프로세서][10] 문서를 참고하세요. + +##### 필수 조건 + +애플리케이션의 로그 속성을 Datadog Standard Attributes에 매핑합니다 +: [Attribute Remapper][5]를 사용하여 가능한 경우 속성 키를 [Datadog Standard Attributes][6]에 매핑합니다. 예를 들어, 네트워크 서비스 클라이언트 IP 값의 속성은 `network.client.ip`로 리매핑해야 합니다. + +로그 `service` 태그를 원격 측정 데이터를 생성하는 서비스 이름에 매핑합니다 +: [Service Remapper]][7]를 사용하여 `service` 속성을 리매핑합니다. 소스와 [서비스][26]가 동일한 값을 공유하는 경우, `service` 태그를 `source` 태그에 리매핑합니다. `service` 태그는 소문자여야 합니다. + +로그의 내부 타임스탬프를 공식 Datadog 타임스탬프에 매핑합니다 +: [Date Remapper][4]를 사용하여 로그의 공식 타임스탬프를 정의합니다. 로그의 타임스탬프가 [표준 날짜 속성][28]에 매핑되지 않으면 Datadog은 타임스탬프를 수집 시점으로 설정합니다. + +로그의 사용자 지정 상태 속성을 공식 Datadog `status` 속성에 매핑합니다 +: [Status Remapper][25]를 사용하여 로그의 `status`를 리매핑하거나, [Category Processor][19]를 사용하여 범위에 매핑된 상태(HTTP 상태 코드처럼)를 리매핑합니다. + +로그의 사용자 지정 메시지 속성을 공식 Datadog `message` 속성에 매핑합니다 +: 애플리케이션 로그가 표준 메시지 속성에 매핑되지 않는 경우 [Message Remapper][9]를 사용하여 로그의 공식 메시지를 정의합니다. 이를 통해 사용자는 원하는 텍스트를 입력하여 로그를 검색할 수 있습니다. + +로그 내 사용자 지정 속성에 대한 네임스페이스를 설정합니다 +: [Datadog Standard Attribute][6]에 매핑되지 않는 일반 로그 속성은 [Facets][14]에 매핑된 경우 네임스페이스를 지정해야 합니다. 예를 들어, `file`은 `integration_name.file`로 다시 매핑됩니다. +[Attribute Remapper][5]를 사용하여 속성 키를 새로운 네임스페이스 속성으로 설정하세요. + +1. 새로 만든 파이프라인을 확장하고 **Add Processor**를 클릭하여 프로세서를 사용하여 파이프라인을 구축하세요. +2. 통합 로그가 JSON 형식이 아닌 경우 [Grok Processor][8]를 추가하여 속성 정보를 추출하세요. Grok 프로세서는 속성을 파싱하고 로그를 보강한 후 재매핑 또는 추가 처리합니다. +3. 로그 속성을 추출한 후 가능한 경우 [Attribute Remappers][5]를 사용하여 [Datadog의 Standard Attributes][6]로 다시 매핑합니다. +4. [Date Remapper][4]를 사용하여 통합 로그의 타임스탬프를 공식 Datadog 타임스탬프로 설정합니다. +5. 고급 처리 및 데이터 변환을 위해 추가 [프로세서][10]를 활용하세요. +예를 들어, `Arithmetic Processor`는 속성을 기반으로 정보를 계산하는 데 사용할 수도 있고, `String Builder Processor`는 여러 문자열 속성을 연결하는 데 사용할 수도 있습니다. + +**팁** +* 로그 속성을 다시 매핑할 때 `preserveSource:false`를 사용하여 원래 속성을 제거하세요. 이렇게 하면 혼란을 줄이고 중복을 제거할 수 있습니다. +* 최적의 grok 파싱 성능을 유지하려면 `%{data:}` 및 `%{regex(".*"):}`와 같은 와일드카드 매처를 사용하지 마세요. 파싱 구문은 최대한 구체적으로 작성하세요. +* 프로세서 작성 및 표준 속성 활용에 대한 전반적인 개요는 무료 과정 [Going Deeper with Logs Processing][20]에서 확인해 보세요. + +### 패싯 개요 + +패싯(Facet)은 검색 결과를 필터링하고 범위를 좁히는 데 사용할 수 있는 구체적인 질적 또는 양적 속성입니다. 패싯은 검색 결과를 필터링하는 데 반드시 필요한 것은 아니지만, 사용자가 검색을 세분화할 수 있는 기준(차원)을 이해하는 데 중요한 역할을 합니다. + +파이프라인이 발행되면 Datadog에서 표준 속성에 대한 패싯을 자동으로 추가합니다. 해당 속성을 [Datadog Standard Attribute][6]로 다시 매핑해야 하는지 검토하세요. + +모든 속성이 패싯으로 사용되지는 않습니다. 통합에서 패싯이 필요한 주요 이유는 다음과 같습니다. +* 패싯은 로그 필터링에 직관적인 인터페이스를 제공합니다. Log Management 자동 완성 기능에 활용되어 사용자가 로그에서 주요 정보를 찾고 집계할 수 있도록 합니다. +* 패싯을 사용하면 가독성이 낮은 속성의 이름을 이해하기 쉬운 레이블로 바꿀 수 있습니다. 예: `@deviceCPUper` → `Device CPU Utilization Percentage`. + +[Log Explorer][16]에서 [패싯][12]을 생성할 수 있습니다. + +#### 패싯 생성 + +패싯을 올바르게 정의하는 것이 중요합니다. Datadog의 Log Management 제품 전반에 걸쳐 분석, 모니터, 집계 기능에서 인덱싱된 로그의 유용성을 향상시키기 때문입니다. + +Log Management 전반에 자동 완성 기능을 추가하여 애플리케이션 로그를 더 쉽게 찾을 수 있습니다. + +
"Measures"라고 하는 정량적 패싯을 사용하면 관계 연산자를 사용하여 다양한 숫자 값 범위에서 로그를 필터링할 수 있습니다. +예를 들어, 대기 시간 속성에 대한 측정값을 사용하면 특정 기간보다 긴 모든 로그를 검색할 수 있습니다.
+ +##### 필수 조건 + +사용자 지정 패싯에 매핑된 속성은 먼저 네임스페이스를 지정해야 합니다 +: [Datadog Standard Attribute][6]에 매핑되지 않는 일반 사용자 지정 속성은 사용자 지정 [패싯][14]과 함께 사용할 때 네임스페이스를 지정해야 합니다. [Attribute Remapper][5]를 사용하면 통합 이름으로 속성의 네임스페이스를 지정할 수 있습니다. +예를 들어, `attribute_name`은 `integration_name.attribute_name`로 리매핑됩니다. + +사용자 정의 패싯은 기존 Datadog 패싯을 복제해서는 안 됩니다 +: 기존의 기본 제공 Datadog 패싯과 혼동을 피하기 위해, 이미 [Datadog Standard Attributes][6]에 매핑된 패싯과 중복되는 사용자 정의 패싯은 생성하지 마세요. + +사용자 지정 패싯은 `source` 이름 아래에 그룹화해야 합니다 +: 사용자 지정 패싯을 생성할 때 그룹을 지정해야 합니다. `Group` 값을 통합 이름과 동일하게 `source`로 설정하세요. + +사용자 지정 패싯은 매핑된 속성과 동일한 데이터 유형을 가져야 합니다 +: 패싯 데이터 유형(String, Boolean, Double, Integer)을 매핑된 속성과 동일한 유형으로 설정하세요. 유형이 일치하지 않으면 패싯이 의도한 대로 사용되지 않고 잘못 입력될 수 있습니다. + +**패싯 또는 측정값 추가** + +1. 패싯이나 측정값을 추가하려는 속성이 포함된 로그를 클릭합니다. +2. 로그 패널에서 속성 옆에 있는 톱니바퀴 아이콘을 클릭합니다. +3. **Create facet/measure for @attribute**를 선택합니다. +4. 측정값의 단위를 정의하려면 **Advanced options**을 클릭합니다. 속성이 어떻게 나타나는지에 따라 단위를 선택하세요. +**참고**: 속성이 어떻게 나타나는지에 따라 측정값의 [단위][11]을 정의하세요. +5. Facet List를 확인하는데 도움이 되는 패싯 **Group**을 지정합니다. 패싯 그룹이 없으면 **New group**을 선택하고 소스 태그와 일치하는 그룹 이름을 입력한 후 새 그룹에 대한 설명을 추가하세요. +6. 패싯을 생성하려면 **Add**를 클릭합니다. + +#### 패싯 구성 및 편집 + +1. 로그 패널에서 구성하거나 그룹화하려는 속성 옆에 있는 톱니바퀴 아이콘을 클릭합니다. +2. **Edit facet/measure for @attribute**을 선택합니다. 해당 속성에 대한 패싯이 아직 없으면 **Create facet/measure for @attribute**를 선택합니다. +3. 완료되면 **Add*** 또는 **Update**를 클릭합니다. + +**팁** +* 가능한 경우 측정값 단위를 지정해야 합니다. 측정값 단위에는 [단위][27]를 할당할 수 있습니다. `millisecond` 또는`gibibyte`와 같은 단위를 사용하는 두 가지 단위 계열(`TIME`, `BYTES`)이 있습니다. +* 패싯에 설명을 지정할 수 있습니다. 사용자가 패싯을 가장 효과적으로 사용할 수 있도록 명확한 설명을 추가하는 것이 좋습니다. +* `preserveSource:true` 옵션을 사용하여 속성을 다시 매핑하고 원본을 유지하는 경우, 단일 속성에만 패싯을 정의합니다. +* 파이프라인 `.yaml` 구성 파일에서 패싯을 수동으로 구성할 때 패싯에 `source`가 할당됩니다. 이는 속성이 캡처된 위치를 나타내며, 속성의 경우 `log`로, 태그의 경우 `tag`로 표시될 수 있습니다. + +## 통합 검토 및 배포 + +Datadog은 이 페이지에 명시된 지침 및 요구 사항을 기반으로 로그 통합을 검토하고 GitHub를 통해 Technology Partner에게 피드백을 제공합니다. Technology Partner는 이를 검토하고 그에 따라 수정 작업을 진행합니다. + +검토 프로세스를 시작하려면 [Logs Configuration 페이지][3]의 **Export** 아이콘을 사용하여 로그 파이프라인과 관련 사용자 정의 패싯을 내보내세요. + +{{< img src="developers/integrations/export_pipeline.png" alt="Datadog에서 로그 파이프라인을 내보내려면 Export Pipeline 아이콘을 클릭합니다." width="50%">}} + +통합을 통해 Datadog으로 전송될 **모든** 속성이 포함된 샘플 원시 로그를 포함하세요. 원시 로그는 Datadog으로 전송되기 **전에** 소스 애플리케이션에서 직접 생성된 원시 메시지로 구성됩니다. + +로그 파이프라인을 내보낼 때 두 개의 YAML 파일이 포함됩니다. + +* 사용자 정의 패싯, 속성 리매퍼, grok 파서를 포함하는 로그 파이프라인이 있는 파일입니다. 내보낸 파일의 이름은 `pipeline-name.yaml`입니다. +* 원시 샘플 로그가 포함되어 있고, 비어있는 `result` 섹션이 있는 파일입니다. 내보낸 파일의 이름은 `pipeline-name_test.yaml`입니다. + +**참고**: 브라우저에 따라 파일 다운로드를 허용하도록 설정을 조정해야 할 수도 있습니다. + +이 파일들을 다운로드한 후 GitHub의 [통합 풀 리퀘스트][22]로 이동하여 **Assets** > **Logs** 디렉터리에 파일을 추가하세요. Logs 폴더가 아직 없다면 직접 생성할 수 있습니다. + +풀 리퀘스트에서 자동으로 검증이 실행되며, 제공된 원시 샘플을 기준으로 파이프라인의 유효성을 검사합니다. 검증 결과는 `pipeline-name_test.yaml` 파일의 `result` 섹션으로 설정할 수 있습니다. +검증을 다시 실행한 후 감지되는 이슈가 없으면, 로그 검증이 성공적으로 완료됩니다. + +일반적인 세 가지 검증 오류는 다음과 같습니다. +1. 두 YAML 파일의 `id` 필드: 파이프라인을 통합에 연결하려면 `id` 필드가 통합 `manifest.json` 파일의 `app_id` 필드와 일치하는지 확인하세요. +2. 제공한 원시 로그를 파이프라인에 실행한 `result`를 제공하지 않는 경우입니다. 검증 결과 출력이 정확하다면 해당 출력을 원시 예제 로그가 포함된 YAML 파일의 `result` 필드에 추가하세요. +3. 로그 페이로드에 넣어 보내는 대신 `service`를 파라미터로 보내는 경우 yaml 파일 내 로그 샘플 아래에 있는 `service` 필드를 포함해야 합니다. + +검증이 통과되면 Datadog은 새로운 로그 통합 자산을 생성하고 배포합니다. 질문이 있으시면 풀 리퀘스트에 댓글로 남겨주세요. Datadog 담당자가 영업일 기준 2~3일 이내에 답변해 드립니다. + +## 참고 자료 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://docs.datadoghq.com/ko/api/latest/logs/#send-logs +[2]: https://docs.datadoghq.com/ko/getting_started/site/ +[3]: https://app.datadoghq.com/logs/pipelines +[4]: https://docs.datadoghq.com/ko/logs/log_configuration/processors/?tab=ui#log-date-remapper +[5]: https://docs.datadoghq.com/ko/logs/log_configuration/processors/?tab=ui#remapper +[6]: https://docs.datadoghq.com/ko/standard-attributes?product=log+management +[7]: https://docs.datadoghq.com/ko/logs/log_configuration/processors/?tab=ui#service-remapper +[8]: https://docs.datadoghq.com/ko/logs/log_configuration/processors/?tab=ui#grok-parser +[9]: https://docs.datadoghq.com/ko/logs/log_configuration/processors/?tab=ui#log-message-remapper +[10]: https://docs.datadoghq.com/ko/logs/log_configuration/processors/ +[11]: https://docs.datadoghq.com/ko/logs/explorer/facets/#units +[12]: https://docs.datadoghq.com/ko/logs/explorer/facets/ +[13]: https://docs.datadoghq.com/ko/logs/log_configuration/pipelines/ +[14]: https://docs.datadoghq.com/ko/glossary/#facet +[15]: https://docs.datadoghq.com/ko/glossary/#measure +[16]: https://docs.datadoghq.com/ko/logs/explorer/ +[17]: https://docs.datadoghq.com/ko/logs/log_configuration/attributes_naming_convention/#standard-attributes +[18]: https://docs.datadoghq.com/ko/developers/integrations/?tab=integrations +[19]: https://docs.datadoghq.com/ko/logs/log_configuration/processors/?tab=ui#category-processor +[20]: https://learn.datadoghq.com/courses/going-deeper-with-logs-processing +[21]: https://partners.datadoghq.com/ +[22]: https://docs.datadoghq.com/ko/developers/integrations/create_a_tile/?tab=buildatileontheintegrationspage#open-a-pull-request +[23]: https://docs.datadoghq.com/ko/logs/log_collection/?tab=http#additional-configuration-options +[24]: https://docs.datadoghq.com/ko/logs/explorer/search_syntax/#arrays +[25]: https://docs.datadoghq.com/ko/logs/log_configuration/processors/?tab=ui#log-status-remapper +[26]: https://docs.datadoghq.com/ko/getting_started/tagging/#overview +[27]: https://docs.datadoghq.com/ko/logs/explorer/facets/#units +[28]: https://docs.datadoghq.com/ko/logs/log_configuration/pipelines/?tab=date#date-attribute \ No newline at end of file diff --git a/content/ko/dora_metrics/failures/_index.md b/content/ko/dora_metrics/failures/_index.md new file mode 100644 index 0000000000000..a31746fa54180 --- /dev/null +++ b/content/ko/dora_metrics/failures/_index.md @@ -0,0 +1,63 @@ +--- +aliases: +- /ko/continuous_integration/dora_metrics/setup/incidents +- /ko/dora_metrics/setup/incidents +description: DORA Metrics에 대한 인시던트 이벤트 전송 방법 +further_reading: +- link: /continuous_integration/dora_metrics/setup/deployments + tag: 설명서 + text: DORA Metrics에서 배포 데이터 설정 +- link: /tracing/service_catalog + tag: 설명서 + text: Service Catalog에 대해 알아보기 +- link: https://github.com/DataDog/datadog-ci + tag: 소스 코드 + text: datadog-ci CLI 도구에 대해 알아보기 +- link: /continuous_delivery/deployments + tag: 설명서 + text: Deployment Visibility에 대해 알아보기 +- link: https://app.datadoghq.com/release-notes?category=Software%20Delivery + tag: 릴리스 노트 + text: 최신 소프트웨어 배포 릴리스를 확인하세요! (앱 로그인 필요) +is_beta: true +title: DORA Metrics에 대한 인시던트 데이터 설정 +--- + +{{< site-region region="gov" >}} +
현재 선택한 사이트({{< region-param key="dd_site_name" >}})에서 DORA 메트릭을 사용할 수 없습니다.
+{{< /site-region >}} + +
DORA 메트릭은 공개 베타 버전입니다.
+ +## 개요 + +실패한 배포 이벤트는 현재 인시던트 이벤트로 간주되며, [변경 실패율](#calculating-change-failure-rate) 및 [평균 복구 시간(MTTR)](#calculating-mean-time-to-restore)을 계산하는 데 사용됩니다. + +## 인시던트 데이터 소스 선택 + +{{< whatsnext desc="DORA Metrics는 배포 이벤트에 관해 다음 데이터 소스를 지원합니다. 배포 이벤트의 데이터 소스를 설정하려면 해당 문서를 참고하세요:" >}} + {{< nextlink href="/dora_metrics/failures/pagerduty" >}}PagerDuty{{< /nextlink >}} + {{< nextlink href="/dora_metrics/failures/incident_api" >}}Incident Event API{{< /nextlink >}} +{{< /whatsnext >}} + +## 변경 실패율 계산 +변경 실패율에는 [배포 데이터][7]와 [인시던트 데이터](#configuring-failure-data-sources)가 모두 필요합니다. + +변경 실패율은 총 배포 횟수 중 인시던트 이벤트의 비율로 계산됩니다. Datadog은 실패 이벤트와 배포 이벤트가 모두 연결된 경우 동일한 서비스 및/또는 팀에 `dora.incidents.count`를 `dora.deployments.count`로 나누어 계산합니다. + +## 복구 시간 계산 +복구 시간은 *해결된 인시던트* 이벤트의 기간 분포로 계산됩니다. + +DORA Metrics는 각 인시던트 이벤트의 시작 및 종료 시간을 기록하여 `dora.time_to_restore` 메트릭을 생성합니다. 선택한 기간 동안 `dora.time_to_restore` 데이터 포인트의 평균으로 평균 복구 시간(MTTR)을 계산합니다. + +## 참고 자료 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ko/api/latest/dora-metrics/#send-a-deployment-event-for-dora-metrics +[2]: https://www.npmjs.com/package/@datadog/datadog-ci +[3]: /ko/tracing/service_catalog +[4]: /ko/tracing/service_catalog/setup +[5]: /ko/tracing/service_catalog/adding_metadata +[6]: https://git-scm.com/docs/git-log +[7]: /ko/dora_metrics/deployments \ No newline at end of file diff --git a/content/ko/error_tracking/backend/logs.md b/content/ko/error_tracking/backend/logs.md new file mode 100644 index 0000000000000..aef4259c7a3b8 --- /dev/null +++ b/content/ko/error_tracking/backend/logs.md @@ -0,0 +1,354 @@ +--- +aliases: +- /ko/error_tracking/logs +description: 로그에서 백엔드 오류를 추적하는 방법을 알아보세요. +further_reading: +- link: https://www.datadoghq.com/blog/error-tracking/ + tag: 블로그 + text: Datadog 오류 추적을 통해 애플리케이션 문제 파악 +- link: /logs/error_tracking/explorer/ + tag: 문서 + text: 오류 추적 탐색기에 대해 알아보기 +is_beta: true +title: 백엔드 오류 로그 추적 +--- + +## 개요 + +아직 Datadog로 로그를 수집하고 있지 않다면 [로그 설명서][10]를 참조하여 로그를 설정하세요. `source` 태그(언어 지정)가 올바르게 구성되었는지 확인하세요. Datadog에서는 Agent 기반 로그 수집을 설정할 것을 권장합니다. + +## 설정 + +**Python**, **Java**, **Ruby**와 같은 언어의 경우 로그의 `source` 태그가 올바르게 구성되어 있으면 추가 구성이 필요하지 않습니다. 모든 필수 속성은 자동으로 태그가 지정되어 Datadog로 전송됩니다. + +**C#**, **.NET**, **Go**, **Node.js**와 같은 백엔드 언어의 경우 각 섹션의 코드 예제에서 오류 로그를 올바르게 구성하고 로그의 `error.stack`에 필요한 스택 트레이스를 첨부하는 방법을 보여줍니다. + +이미 Datadog로 스택 추적을 보내고 있는데 `error.stack`에 없는 경우, [일반 로그 리매퍼][8]를 설정하여 스택 트레이스를 Datadog의 올바른 속성으로 리매핑할 수 있습니다. + +이슈에서 인라인 코드 조각을 구성하려면 [소스 코드 통합][9]을 설정하세요. Error Tracking에 코드 조각을 추가하는 데는 APM이 필요하지 않으며, 보강 태그와 연결된 리포지토리는 둘 다 동일합니다. + +#### Error Tracking 속성 + +Error Tracking을 활성화하려면 로그에 다음 속성이 포함되어야 합니다. + +- `error.kind` 또는 `error.stack` 필드입니다. **참고**: `error.stack`을 사용하는 경우 유효한 스택 트레이스여야 합니다. +- `Service` 속성 +- 상태 수준은 `ERROR`, `CRITICAL`, `ALERT`, 또는 `EMERGENCY` 입니다. + +아래 안내된 나머지 속성은 선택 사항이나 오류 그룹화를 개선하는 데 도움이 됩니다. + +특정 속성은 Datadog 내에 전용 UI 표시가 있습니다. Error Tracking에서 이러한 기능을 사용하려면 다음 속성 이름을 사용합니다. + +| 속성 | 설명 | +|----------------------|-------------------------------------------------------------------------| +| `error.stack` | 실제 스택 추적 | +| `error.message` | 스택 추적에 포함된 오류 메시지 | +| `error.kind` | 오류의 유형 또는 "종류"(예: "Exception" 또는 "OSError") | + +**참고**: 기본적으로 통합 파이프라인은 기본 로깅 라이브러리 파라미터를 해당 특정 속성으로 리매핑하고 스택 추적 또는 트레이스백을 파싱하여 자동으로 `error.message`와 `error.kind`를 추출하려고 시도합니다. + +자세한 내용은 전체 [소스 코드 속성 문서][11]를 참조하세요. + +### C# 및 .NET + +{{< tabs >}} +{{% tab "Serilog" %}} + +C#용 로그 수집을 설정하지 않은 경우 [C# 로그 수집 설명서][1]를 참조하세요. + +탐지된 예외를 직접 로깅하려면 옵션으로 다음을 사용할 수도 있습니다. + +```csharp +var log = new LoggerConfiguration() + .WriteTo.File(new JsonFormatter(renderMessage: true), "log.json") + .Enrich.WithExceptionDetails() + .CreateLogger(); +try { + // ... +} catch (Exception ex) { + // 로그 호출 첫 인수로 예외 전달 + log.Error(ex, "an exception occurred"); +} +``` + +[1]: /ko/logs/log_collection/csharp/?tab=serilog + +{{% /tab %}} +{{% tab "NLog" %}} + +C#용 로그 수집을 설정하지 않은 경우 [C# 로그 수집 설명서][1]를 참조하세요. + +탐지된 예외를 직접 로깅하려면 옵션으로 다음을 사용할 수도 있습니다. + +```csharp +private static Logger log = LogManager.GetCurrentClassLogger(); + +static void Main(string[] args) +{ + try { + // ... + } catch (Exception ex) { + // 로그 호출의 두 번째 인수로 예외 전달 + log.ErrorException("an exception occurred", ex); + } +} +``` + +[1]: /ko/logs/log_collection/csharp/?tab=serilog + +{{% /tab %}} +{{% tab "Log4Net" %}} + +C#용 로그 수집을 설정하지 않은 경우 [C# 로그 수집 설명서][1]를 참조하세요. + +탐지된 예외를 직접 로깅하려면 옵션으로 다음을 사용할 수도 있습니다. + +```csharp +class Program +{ + private static ILog logger = LogManager.GetLogger(typeof(Program)); + + static void Main(string[] args) + { + try { + // ... + } catch (Exception ex) { + // 로그 호출의 두 번째 인수로 예외 전달 + log.Error("an exception occurred", ex); + } + } +} +``` + +[1]: /ko/logs/log_collection/csharp/?tab=serilog + +{{% /tab %}} +{{< /tabs >}} + +### Go + +#### Logrus + +Go에 로그 수집을 설정하지 않은 경우 [Go 로그 수집 설명서][3]를 참조하세요. + +탐지된 예외를 직접 로깅하려면 옵션으로 다음을 사용할 수도 있습니다. + +```go +// for https://github.com/pkg/errors +type stackTracer interface { + StackTrace() errors.StackTrace +} + +type errorField struct { + Kind string `json:"kind"` + Stack string `json:"stack"` + Message string `json:"message"` +} + +func ErrorField(err error) errorField { + var stack string + if serr, ok := err.(stackTracer); ok { + st := serr.StackTrace() + stack = fmt.Sprintf("%+v", st) + if len(stack) > 0 && stack[0] == '\n' { + stack = stack[1:] + } + } + return errorField{ + Kind: reflect.TypeOf(err).String(), + Stack: stack, + Message: err.Error(), + } +} + + +log.WithFields(log.Fields{ + "error": ErrorField(err) +}).Error("an exception occurred") +``` + +### Java(파싱됨) + +Java용 로그 수집을 설정하지 않은 경우 [Java 로그 수집 설명서][4]를 참조하세요. 로그에 `source:java` 태그가 있는지 확인하세요. + +{{< tabs >}} +{{% tab "Log4j" %}} + +탐지된 예외를 직접 로깅하려면 옵션으로 다음을 사용할 수도 있습니다. + +```java +Logger logger = LogManager.getLogger("HelloWorld"); +try { + // ... +} catch (Exception e) { + // 로그 호출의 마지막 인수로 예외 전달 + logger.error("an exception occurred", e) +} +``` + +{{% /tab %}} +{{% tab "SLF4J" %}} + +탐지된 예외를 직접 로깅하려면 옵션으로 다음을 사용할 수도 있습니다. + +```java +Logger logger = LoggerFactory.getLogger(NameOfTheClass.class); +try { + // ... +} catch (Exception e) { + // 로그 호출의 마지막 인수로 예외 전달 + logger.error("an exception occurred", e) +} +``` + +{{% /tab %}} +{{< /tabs >}} + +### Node.js + +#### Winston(JSON) + +Node.js에 관해 로그 수집을 설정하지 않은 경우 [Node.js 로그 수집 설명서][5]를 참조하세요. + +탐지된 예외를 직접 로깅하려면 옵션으로 다음을 사용할 수도 있습니다. + +```json +try { + // ... +} catch (e) { + logger.error("an exception occurred", { + error: { + message: e.message, + stack: e.stack + } + }); +} +``` + +### PHP + +#### Monolog(JSON) + +PHP용 로그 수집을 설정하지 않은 경우 [PHP 로그 수집 설명서][12]를 참조하세요. + +탐지된 예외를 직접 로깅하려면 옵션으로 다음을 사용할 수도 있습니다. + +```php +try { + // ... +} catch (\Exception $e) { + $logger->error('An error occurred', [ + 'error.message' => $e->getMessage(), + 'error.kind' => get_class($e), + 'error.stack' => $e->getTraceAsString(), + ]); +} +``` + +### Python + +#### 로깅 + +Python용 로그 수집을 설정하지 않은 경우 [Python 로그 수집 설명서][6]를 참조하세요. 로그에 `source:python` 태그가 있는지 확인하세요. + +탐지된 예외를 직접 로깅하려면 옵션으로 다음을 사용할 수도 있습니다. + +```python +try: + // ... +except: + logging.exception('an exception occurred') +``` + +### Ruby on Rails + +#### 사용자 지정 로거 포맷터 + +Ruby on Rails에 대해 로그 수집을 설정하지 않은 경우 [Ruby on Rails 로그 수집 설명서][7]를 참조하세요. + +수동으로 오류를 기록하려면 JSON을 사용하여 포맷터를 만들고 예외 값을 올바른 필드에 매핑하세요, + +```ruby +require 'json' +require 'logger' + +class JsonWithErrorFieldFormatter < ::Logger::Formatter + def call(severity, datetime, progname, message) + log = { + timestamp: "#{datetime.to_s}", + level: severity, + } + + if message.is_a?(Hash) + log = log.merge(message) + elsif message.is_a?(Exception) + log['message'] = message.inspect + log['error'] = { + kind: message.class, + message: message.message, + stack: message.backtrace.join("\n"), + } + else + log['message'] = message.is_a?(String) ? message : message.inspect + end + + JSON.dump(log) + "\n" + end +end +``` + +그리고 로거에서 사용하세요. +```ruby +logger = Logger.new(STDOUT) +logger.formatter = JsonWithErrorFieldFormatter.new +``` + +**Lograge**를 사용하는 경우 형식이 지정된 오류 로그를 전송하도록 설정할 수도 있습니다. +``` ruby +Rails.application.configure do + jsonLogger = Logger.new(STDOUT) # 에이전트 구성에 따라 STDOUT 또는 파일 + jsonLogger.formatter = JsonWithErrorFieldFormatter.new + + # Rails 기본 TaggedLogging 로거를 json 포맷터를 사용하여 새 로거로 교체합니다. + # TaggedLogging은 더 복잡한 json 형식 메시지와 호환되지 않습니다. + config.logger = jsonLogger + + # Lograge 구성 + config.lograge.enabled = true + config.lograge.formatter = Lograge::Formatters::Raw.new + + # 로그 색상을 비활성화합니다. + config.colorize_logging = false + + # 올바른 필드에 대한 예외 로깅을 구성합니다. + config.lograge.custom_options = 람다 do |event| + if event.payload[:exception_object] + return { + level: 'ERROR', + message: event.payload[:exception_object].inspect, + error: { + kind: event.payload[:exception_object].class, + message: event.payload[:exception_object].message, + stack: event.payload[:exception_object].backtrace.join("\n") + } + } + end + end +end +``` +## 참고 자료 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://app.datadoghq.com/logs/error-tracking +[2]: https://app.datadoghq.com/logs/onboarding/client +[3]: /ko/logs/log_collection/go/ +[4]: /ko/logs/log_collection/java/?tab=log4j +[5]: /ko/logs/log_collection/nodejs/?tab=winston30 +[6]: /ko/logs/log_collection/python/?tab=jsonlogformatter +[7]: /ko/logs/log_collection/ruby/ +[8]: /ko/logs/log_configuration/processors/?tab=ui#remapper +[9]: https://app.datadoghq.com/source-code/setup/apm +[10]: /ko/logs/log_collection/ +[11]: /ko/logs/log_configuration/attributes_naming_convention/#source-code +[12]: /ko/logs/log_collection/php/ \ No newline at end of file diff --git a/content/ko/getting_started/tagging/assigning_tags.md b/content/ko/getting_started/tagging/assigning_tags.md index dbb26d6272a5d..27cc406825cd1 100644 --- a/content/ko/getting_started/tagging/assigning_tags.md +++ b/content/ko/getting_started/tagging/assigning_tags.md @@ -159,7 +159,7 @@ hostname: mymachine.mydomain #### 환경 변수 -컨테이너화된 Datadog 에이전트를 설치한 후 에이전트 주 구성 파일에서 환경 변수 `DD_TAGS`를 사용해 호스트 태그를 설정할 수 있습니다. 여러 태그를 지정하면 쉼표와 띄어쓰기로 구분하세요. +컨테이너화된 Datadog Datadog Agent를 설치한 후, Agent 기본 구성 파일의 `DD_TAGS` 환경 변수를 사용하여 호스트 태그를 설정할 수 있습니다. 여러 태그 지정 시 각 태그를 공백으로 구분하세요. Datadog는 [도커(Docker), 쿠버네티스(Kubernetes), ECS, Swarm, Mesos, Nomad, Rancher][6]에서 일반적인 태그를 자동으로 수집합니다. 더 많은 태그를 추출하려면 다음 옵션을 사용하세요. @@ -216,7 +216,7 @@ services: environment: - DD_API_KEY= "" - DD_CONTAINER_LABELS_AS_TAGS={"my.custom.label.project":"projecttag","my.custom.label.version":"versiontag"} - - DD_TAGS="key1:value1, key2:value2, key3:value3" + - DD_TAGS="key1:value1 key2:value2 key3:value3" image: 'gcr.io/datadoghq/agent:latest' deploy: restart_policy: @@ -239,10 +239,19 @@ services: ##### 태그 카디널리티(Cardinality) -태그 카디널리티를 설정하는 환경 변수는 `DD_CHECKS_TAG_CARDINALITY`와 `DD_DOGSTATSD_TAG_CARDINALITY`로 두 가지가 있습니다. DogStatsD의 요금 설정이 다르므로, 이에 따라 DogStatsD 태그 카디널리티도 세밀하게 구성할 수 있도록 나뉘어 있습니다. 그 이외에는 이러한 변수가 동일하게 작동합니다. 사용할 수 있는 값은 `low`, `orchestrator` 또는 `high`입니다. 모두 기본적으로는 `low`로 설정되어 있으며, 호스트 수준의 태그를 가져옵니다. +태그 카디널리티를 설정하는 두 가지 환경 변수는 `DD_CHECKS_TAG_CARDINALITY` 및 `DD_DOGSTATSD_TAG_CARDINALITY`입니다. DogStatsD는 가격이 다르기 때문에 DogStatsD 태그 카디널리티 설정이 분리되어 있어 더욱 세밀하게 구성할 수 있습니다. 그 외에는 이 변수 함수가 동일하게 작동하는데 `low`, `orchestrator`, `high` 값을 가질 수 있습니다. 두 변수 모두 기본값이 `low`이며, Kubernetes 클러스터 수준 태그를 가져옵니다. + +다양한 카디널리티 설정값은 다음과 같습니다. +* `low`: Kubernetes 클러스터 수준 태그 (예: `kube_namespace`) +* `orchestrator`: 포드 수준 태그 (예: `pod_name`) +* `high`: 컨테이너 수준 태그 (예: `container_id`) 카디널리티에 따라 [쿠버네티스, OpenShift][7] 및 [도커, Rancher, Mesos][8]에서 서로 다른 태그를 바로 사용할 수 있도록 태그 세트가 준비되어 있습니다. ECS와 Fargate에서는 변수를 `orchestrator`로 설정하면 `task_arn` 태그가 추가됩니다. +**참고**: +- DogStatsD 메트릭용 컨테이너 태그를 전송하면 더 많은 메트릭이 생성됩니다(호스트당 하나가 아닌 컨테이너당 하나). 이는 커스텀 메트릭 청구에 영향을 미칠 수 있습니다. +- 메트릭에서 타임스탬프는 가장 가까운 초로 반올림됩니다. 동일한 타임스탬프를 가진 데이터 포인트가 여러 개 있을 경우, 가장 마지막 값이 이전 값을 덮어씁니다. 카디널리티를 설정하면 이 문제를 방지할 수 있습니다. + #### 트레이스 Datadog 트레이서는 환경 변수, 시스템 속성 또는 코드 내의 설정을 통해 구성할 수 있습니다. 각 트레이서의 태깅 옵션과 설정 정보는 [Datadog 트레이싱 설정][9] 가이드를 참조하시기 바랍니다. [통합 서비스 태깅][2] 가이드에서도 통합 서비스 태깅 트레이서를 설정하는 방법을 확인할 수 있습니다. @@ -303,11 +312,12 @@ Datadog 트레이서는 환경 변수, 시스템 속성 또는 코드 내의 설 {{% /tab %}} {{% tab "통합" %}} -[AWS][1] 통합 타일을 사용하면 계정 수준에서 모든 메트릭에 추가 태그를 할당할 수 있습니다. 쉼표(",")로 구분되는 `:` 형식의 태그 목록을 사용하세요. +[AWS][1] 통합 타일을 사용하면 계정 수준의 모든 메트릭과 [자동 구독 트리거][2]를 통해 전송된 로그에 추가 태그를 할당할 수 있습니다. 태그 목록은 쉼표로 구분하여 `:` 형식에 맞추세요. {{< img src="tagging/assigning_tags/integrationtags.png" alt="AWS 태그" style="width:80%;">}} [1]: /ko/integrations/amazon_web_services/ +[2]: /ko/logs/guide/send-aws-services-logs-with-the-datadog-lambda-function/#automatically-set-up-triggers {{% /tab %}} {{% tab "서비스 수준 목표" %}} diff --git a/content/ko/getting_started/workflow_automation/_index.md b/content/ko/getting_started/workflow_automation/_index.md index 4f73b4cfce22c..054e2729452da 100644 --- a/content/ko/getting_started/workflow_automation/_index.md +++ b/content/ko/getting_started/workflow_automation/_index.md @@ -14,97 +14,105 @@ title: 워크플로 자동화 시작 ## 개요 -워크플로 인증을 사용하면 Datadog 경고 및 보안 신호에 대응하여 엔드투엔드 프로세스를 자동화할 수 있습니다. 워크플로 인증은 실시간 관찰 가능 데이터를 기반으로 하므로 이슈를 보다 신속하게 해결하고 시스템의 가용성 및 보안을 사전 예방으로 유지할 수 있습니다. +Workflow Automation을 사용하면 Datadog 알림 및 보안 신호에 대응하여 엔드 투 엔드 프로세스를 자동화할 수 있습니다. Workflow Automation은 실시간 관측 데이터를 기반으로 하므로 문제를 더 빠르게 해결하고 시스템의 가용성과 보안을 사전에 유지할 수 있습니다. -이 가이드에 따라 모니터 알림에 의해 트리거된 커스텀 워크플로를 생성합니다. 이 가이드가 트리거되면 워크플로는 Jira에 업무를 생성하고 Jira 티켓 링크와 함께 Slack에 메세지를 보냅니다. 이 가이드에서는 워크플로의 다음 단계로 데이터를 전달하고 워크플로를 저장 및 게시하며 워크플로의 실행 기록을 볼 수 있습니다. +모니터 알림에 의해 트리거되는 커스텀 워크플로를 만들려면 이 가이드를 따르세요. 트리거되면 워크플로는 Jira에서 작업을 생성하고 Jira 티켓 링크와 함께 Slack에 알림을 보냅니다. 이 가이드에서는 워크플로의 한 단계에서 다른 단계로 데이터를 전달하고, 워크플로를 저장 및 게시하며, 워크플로의 실행 기록을 보는 방법을 다룹니다. -## 필수 요구 사항 +## 사전 필수 조건 -시작하기 전에 [Datadog 계정][1]에 Jira와 Slack 통합이 설치되어 있어야 합니다. 설치 방법은 [Slack][2] 및 [Jira 통합][3] 문서를 참고하세요. +시작하기 전에 [Datadog 계정][1]에 Jira 및 Slack 통합을 설치해야 합니다. 설치 지침은 [Slack][2] 및 [Jira 통합][3] 문서를 참고하세요. Jira 및 Slack 통합 타일에서 설정한 계정 자격 증명 및 인증은 워크플로 인증의 Jira 및 Slack 작업에 자동으로 전파됩니다. 일부 통합에서는 인증을 위해 추가 설정이 필요합니다. 자세한 내용은 [연결][4]을 참고하세요. -## 워크플로 구축 +## 워크플로 구축하기 -### 모니터 트리거를 사용하여 워크플로 생성 -모니터 또는 보안 신호와 같은 알림, 예약, 또는 수동으로 워크플로를 트리거할 수 있습니다. 이 경우 모니터 트리거를 사용하여 워크플로를 생성합니다. +### 모니터 트리거로 워크플로 만들기 +모니터나 보안 신호와 같은 알림에서, 일정에서, 또는 수동으로 워크플로를 트리거할 수 있습니다. 모니터 트리거를 사용하여 워크플로를 생성하세요. -모니터 트리거를 사용하여 워크플로를 생성하는 방법: +워크플로 생성 +1. **[Workflow Automation][5]** 페이지에서 **New Workflow**를 클릭합니다. +1. 워크플로의 이름과 설명을 입력합니다. 예제 워크플로에서는 다음 이름과 설명을 사용합니다.
+ 이름: `Create a Jira Ticket`.
+ 설명: `Create a Jira issue and Slack notification when there is a monitor alert`. -1. Datadog에서 **Service Management** > **[Workflow Automation][5]**으로 이동합니다. -2. **New Workflow**를 클릭합니다. -3. 워크플로의 이름과 설명을 입력합니다. 샘플 이름의 경우 `Create a Jira Ticket`를 사용합니다(샘플 설명 예: `Create a Jira issue and Slack notification when there is a monitor alert`). -4. **Monitor or Security Signal**를 선택합니다. -5. **Create**을 클릭합니다. -6. 워크플로우 캔버스에서 **Monitor 또는 Security Signal** 트리거를 클릭합니다. -7. **Configure** 탭의 `@workflow-` 옆에 워크플로의 고유 ID`@workflow-Create-Jira-Ticket`를 입력합니다. 워크플로 핸들은 항상 `@workflow-`로 시작합니다. 나중에 이 핸들을 사용하여 워크플로를 모니터 알림에 연결합니다. -8. **Save**를 클릭하여 워크플로를 저장합니다. +모니터를 추가하고 구성합니다. +1. 워크플로 캔버스에서 **Add Trigger**를 클릭하고 **Monitor**를 선택합니다. +1. **Configure** 탭에서 `@workflow-` 옆에 워크플로: `Create-Jira-Ticket`에 대한 고유 ID 를 입력합니다.
+ 워크플로 핸들은 항상 `@workflow-`로 시작합니다. 나중에 이 핸들을 사용하여 워크플로를 모니터 알림에 연결합니다. +1. **Save**를 클릭하여 워크플로를 저장합니다. -{{< img src="/getting_started/workflow_automation/trigger.png" alt="워크플로우 트리거">}} +{{< img src="/getting_started/workflow_automation/trigger1.png" alt="워크플로용 트리거">}} -### Jira 및 Slack 작업 추가 -Jira 단계 추가하는 방법: -1. 워크플로 캔버스에서 **Add a step to get started**를 클릭합니다. -2. Jira 작업을 검색하여 **Create issue**를 선택하고 **Create issue** 단계를 클릭한 후 **Jira account**을 선택합니다. 계정은 Jira 통합 타일의 **Accounts** 섹션에 있는 Jira URL에 해당해야 합니다. -3. 워크플로에서 생성하는 Jira 이슈에 **Project** 및 **Issue type**를 입력합니다. -4. 워크플로를 트리거하는 모니터의 데이터를 전달하기 위해 컨텍스트 변수를 사용하여 Jira 이슈의 **요약** 및 **설명**을 입력합니다. 이중 괄호(`{{`)로 둘러싸서 단계에서 컨텍스트 변수에 액세스할 수 있습니다. 다음 설명 예제에서는 소스, 트리거, 워크플로 변수를 사용해 모니터 경고를 트리거한 소스, 영향을 받는 모니터의 링크, 워크플로 이름 및 워크플로 ID를 전달합니다. +### Jira 및 Slack 작업 추가하기 +Jira 단계를 추가하고 구성합니다. +1. 워크플로 캔버스에서 **+** 아이콘을 클릭합니다. +1. Jira 작업을 검색하고 **Create issue**를 선택합니다. +1. 워크플로 캔버스에서 **Create issue** 단계를 클릭합니다. +1. **Configure** 탭에서 **Jira Account**를 선택합니다. 계정은 Jira 통합 타일의 **Jira Account**섹션에 있는 Jira URL과 일치해야 합니다. +1. 워크플로가 생성하는 Jira 이슈에 대한 **Project** 및 **Issue type**을 입력합니다. +1. Jira 이슈에 대한 **Summary** 및 **Description**을 입력하고 컨텍스트 변수를 사용하여 워크플로를 트리거하는 모니터의 데이터를 전달합니다. 컨텍스트 변수를 이중 중괄호(`{{`)로 묶어 단계에서 컨텍스트 변수에 액세스할 수 있습니다.

+ 다음 예제 설명에서는 소스, 트리거 및 워크플로 변수를 사용하여 다음을 전달합니다. + - 모니터 알림을 발생시킨 소스 + - 영향을 받은 모니터에 대한 링크 + - 워크플로 이름 및 워크플로 ID -``` -CPU 사용량이 {{ Trigger.hostname }}의 95% 임계값을 초과 + ``` + The CPU usage is above the 95% threshold for {{ Trigger.hostname }} -살펴보기 - 모든 워크플로 실행을 보려면 Datadog 대시보드를 참고하세요. -https://app.datadoghq.com/dash/integration/workflow_automation?refresh_mode=sliding&from_ts=1698164453793&to_ts=1698168053793&live=true. + Please investigate - see this Datadog Dashboard to view all workflow executions: + https://app.datadoghq.com/dash/integration/workflow_automation?refresh_mode=sliding&from_ts=1698164453793&to_ts=1698168053793&live=true. -Jira 이슈를 만든 워크플로우는 -{{ WorkflowName }} : {{ WorkflowId }} + The workflow that created this Jira issue is + {{ WorkflowName }} : {{ WorkflowId }} -워크플로를 트리거한 모니터는 다음에서 확인할 수 있습니다. {{ Source.url }} -``` + The monitor that triggered the workflow can be found here: {{ Source.url }} + ``` -컨텍스트 변수에 관한 자세한 내용은 **[컨텍스트 변수][6]**를 참고하세요. + 컨텍스트 변수에 대한 자세한 내용은 **[Context variables][6]**를 참조하세요. -5. 작업의 **Configure** 탭에서 녹색 **Test** 아이콘을 클릭하여 Jira 작업을 테스트합니다. -6. **Save**를 클릭하여 워크플로를 저장합니다. +1. **Configure** 탭에서 **Test**를 클릭하여 Jira 작업을 테스트합니다. 작업을 테스트하면 실제 Jira 티켓이 생성됩니다. +1. **Save**를 클릭하여 워크플로를 저장합니다. -이전 지침서에서는 Jira 티켓을 생성하는 단계를 설정했습니다. 다음으로 Slack 단계를 추가합니다. -1. 워크플로 캔버스에서 더하기 아이콘을 클릭해 다른 단계를 추가합니다. -2. Slack 작업을 검색하고 **Send message**를 선택합니다. -3. **Slack 워크스페이스 이름**을 입력합니다. -4. **Slack 채널 이름**을 입력합니다. -5. Slack 알림을 보다 유용하게 사용하려면 단계 출력 변수를 사용합니다. 단계 출력 변수를 사용하면 워크플로의 Jira 단계에서 Slack 단계로 데이터를 전달할 수 있습니다. 다음 메시지 텍스트를 사용해 Slack 메시지에 Jira 이슈 키와 Jira 이슈를 포함할 수 있습니다. +다음으로 Slack 단계를 추가합니다. +1. 워크플로 캔버스에서 더하기 아이콘을 클릭하여 다른 단계를 추가합니다. +1. Slack을 검색하고 **Send message**를 선택합니다. +1. **Slack Workspace 이름**을 입력합니다. +1. **Slack Channel 이름**을 입력합니다. +1. 보다 유용한 Slack 알림을 얻으려면 단계 출력 변수를 사용합니다. 단계 출력 변수를 사용하면 워크플로의 Jira 단계에서 Slack 단계로 데이터를 전달할 수 있습니다. Slack 메시지에 Jira 이슈 키, 모니터 이름, Jira 이슈를 포함하려면 다음 메시지 텍스트를 사용하세요. -``` -{{ Source.monitor.name }}라는 이름의 모니터가 새로운 Jira 이슈 트리거 및 생성 -{{ Steps.Create_issue.issueKey }}: {{ Steps.Create_issue.issueUrl }} + ``` + The monitor named {{ Source.monitor.name }} triggered and created a new Jira issue + {{ Steps.Create_issue.issueKey }}: {{ Steps.Create_issue.issueUrl }} -Jira 이슈를 만든 워크플로는 {{ WorkflowName }}임 -``` + The workflow that created this Jira issue is {{ WorkflowName }} + ``` -6. 작업의 **Configure** 탭에서 녹색 **Test** 아이콘을 클릭하여 이 Slack 작업을 테스트합니다. -7. 모니터의 알림 드롭다운에 워크플로 이름을 보려면 워크플로를 저장한 후 게시하세요. 워크플로 페이지에서 **Publish**를 클릭합니다. +1. 작업을 테스트하려면 **Configure** 탭에서 **Test**를 클릭합니다. 작업을 테스트하면 실제 Slack 메시지가 생성됩니다. +1. 모니터 알림 드롭다운에서 워크플로 이름을 보려면 워크플로를 저장하고 발행해야 합니다. 워크플로 페이지에서 **Publish**를 클릭합니다. -## 워크플로 테스트 및 게시 +## 워크플로 테스트 및 발행하기 -변경 사항을 적용하려면 **Save**를 클릭하여 워크플로를 저장해야 합니다. 다음으로 워크플로를 수동으로 트리거하여 테스트합니다. +
사용 중인 Slack 및 Jira 계정에 연결된 워크플로를 테스트하면 실제 Slack 메시지와 Jira 티켓이 생성됩니다.
-{{< img src="/getting_started/workflow_automation/run_workflow.png" alt="수동으로 워크플로 트리거" style="width:90%;" >}} +변경사항을 워크플로에 적용하려면 **Save**를 클릭합니다. 다음으로 워크플로를 수동으로 트리거하여 테스트합니다. -워크플로를 수동으로 트리거하려면 워크플로 페이지에서 **Run**을 클릭하고 트리거 변수의 값을 입력합니다. +워크플로를 수동으로 트리거하려면 워크플로 페이지에서 **Run**을 클릭하고 트리거 변수에 대한 값을 입력합니다. -워크플로를 실행하면 지정한대로 Jira 티켓이 생성되고 Slack 메시지가 전송되는지 확인합니다. +{{< img src="/getting_started/workflow_automation/run_workflow.png" alt="워크플로를 수동으로 트리거" style="width:90%;" >}} -게시하기 전에는 예약 및 트리거된 워크플로가 자동으로 트리거되지 않습니다. 워크플로를 게시하려면 워크플로 페이지에서 **Publish**를 클릭하세요. +워크플로를 실행하면 Jira 티켓이 생성되고 Slack 메시지가 전송되는지 확인합니다. -
활성화된 Slack 및 Jira 계정에 연결된 워크플로를 테스트하면 실제 Slack 메시지와 Jira 티켓이 생성됩니다.
+예약 및 트리거된 워크플로는 발행하기 전까지 자동으로 실행되지 않습니다. 워크플로를 발행하려면 워크플로 페이지에서 **Publish**를 클릭하세요. -## 워크플로를 트리거하는 모니터 업데이트 +## 워크플로를 트리거하는 모니터 업데이트하기 -1. Datadog에서 [모니터 페이지][7]로 이동합니다. -2. 워크플로를 트리거하고 편집하거나 새 모니터를 만드는 데 사용할 모니터를 찾습니다. -3. 메시지 섹션에서 전체 워크플로 기재 이름을 경고 알림에 추가합니다. 언급된 이름은 `@workflow-`로 시작합니다. 예를 들어, `@workflow-Create-Jira-Ticket`입니다. - - 구문 `@workflow-name(key=value, key=value)`와 함께 쉼표로 구분된 목록을 사용해 트리거 변수를 워크플로에 전달할 수 있습니다(예: `@workflow-Create-Jira-Ticket(hostname=host.name)`). -4. **Test Notifications**를 클릭하여 워크플로 및 모니터의 모든 알림을 테스트합니다. -5. 모니터를 저장합니다. +1. Datadog의 [Monitors 페이지][7]로 이동합니다. +1. 워크플로를 트리거하려는 모니터를 찾아 편집하거나 새 모니터를 만듭니다. +1. **Configure notifications & automations** 섹션에서 **Add Workflow**를 클릭합니다. +1. 워크플로 멘션 이름(`@workflow-Create-Jira-Ticket`)을 사용하여 워크플로를 검색하고 드롭다운에서 선택합니다. + - `@workflow-name(key=value, key=value)` 구문과 함께 쉼표로 구분된 목록을 사용하여 트리거 변수를 워크플로에 전달할 수 있습니다. 예를 들어, `@workflow-Create-Jira-Ticket(hostname={{host.name}})`입니다. +1. 워크플로와 이 모니터의 모든 알림을 테스트하려면 **Test Notifications**를 클릭합니다. +1. 모니터를 저장합니다. {{< img src="/getting_started/workflow_automation/monitor_trigger.png" alt="모니터에서 워크플로우 트리거">}} @@ -112,13 +120,13 @@ Jira 이슈를 만든 워크플로는 {{ WorkflowName }}임 ## 실행 기록 -워크플로를 트리거하면 **실행 기록** 보기에서 워크플로의 진행 상황 및 디버그 실패 단계를 볼 수 있습니다. 실행된 단계를 선택하면 입력, 출력, 실행 컨텍스트 및 오류 메시지를 볼 수 있습니다. 아래 예는 잘못된 Jira 설정으로 인해 실패한 단계를 보여줍니다. +워크플로를 트리거한 후 **Run History** 보기에서 진행 상황을 확인하고 실패한 단계를 디버깅할 수 있습니다. 실행된 단계를 선택하여 입력, 출력, 실행 컨텍스트 및 오류 메시지를 확인하세요. 아래 예는 잘못된 Jira 구성으로 인해 실패한 단계를 보여줍니다. {{< img src="/getting_started/workflow_automation/testing_the_workflow.mp4" alt="워크플로 테스트 미리보기" style="width:100%" video=true >}} -워크플로우를 편집하려면 **Configuration**을 클릭하고, 실행 내역 보기로 돌아가려면 **Run History**을 클릭합니다. +워크플로를 수정하려면 **Configuration**을 클릭합니다. 실행 기록 보기로 돌아가려면 **Run History**를 클릭합니다. -이전 워크플로 실행 목록과 각 실행이 성공했는지 실패했는지를 보려면 초기 실행 기록 보기를 사용합니다. 워크플로 캔버스를 클릭하여 언제든지 초기 실행 기록으로 돌아갑니다. +이전 워크플로 실행 목록과 각 실행의 성공 여부를 보려면 초기 실행 기록 보기를 사용합니다. 워크플로 캔버스를 클릭하면 언제든지 초기 실행 기록으로 돌아갈 수 있습니다. ## 결론 @@ -126,11 +134,11 @@ Jira 이슈를 만든 워크플로는 {{ WorkflowName }}임 {{< img src="/getting_started/workflow_automation/jira_ticket.png" alt="워크플로에서 생성된 Jira 티켓">}} -또한 이 워크플로는 Slack 메시지를 생성하여 팀에 Jira 이슈를 알리고 경고를 모니터링합니다. 다음은 Slack 알림 예시입니다. +또한 워크플로는 Slack 메시지를 생성하여 팀에 Jira 이슈를 알리고 알림을 모니터링합니다. 다음은 Slack 알림의 예입니다. {{< img src="/getting_started/workflow_automation/slack-message.png" alt="워크플로우에서 생성된 Slack 메시지">}} -## 다음에는 무엇을 해야 하나요? +## 다음 단계 * [작업 카탈로그][8]에서 사용 가능한 모든 워크플로 작업 목록을 탐색합니다. * 기본으로 제공되는 [블루 프린트][9]로 워크플로를 구축합니다. @@ -149,7 +157,7 @@ Jira 이슈를 만든 워크플로는 {{ WorkflowName }}임 [5]: https://app.datadoghq.com/workflow [6]: /ko/workflows/build/#context-variables [7]: https://app.datadoghq.com/monitors/manage -[8]: /ko/service_management/workflows/actions_catalog/ +[8]: /ko/actions/actions_catalog/ [9]: /ko/workflows/build -[10]: /ko/service_management/workflows/actions_catalog/generic_actions/#http -[11]: /ko/service_management/workflows/actions_catalog/generic_actions/#data-transformation \ No newline at end of file +[10]: /ko/service_management/workflows/actions/#http +[11]: /ko/service_management/workflows/actions/#data-transformation \ No newline at end of file diff --git a/content/ko/glossary/terms/slo_list.md b/content/ko/glossary/terms/slo_list.md new file mode 100644 index 0000000000000..74ee6d455a9ca --- /dev/null +++ b/content/ko/glossary/terms/slo_list.md @@ -0,0 +1,9 @@ +--- +core_product: +- dashboards +related_terms: +- 서비스 수준 목표(SLO) +- dashboard +title: slo list widget +--- +SLO List 위젯은 기본 시간 창에 SLO 하위 집합을 표시합니다. 설정된 모든 시간 창은 SLO 페이지의 SLO 사이드 패널에서 확인할 수 있습니다. 자세한 내용은 관련 문서를 참고하세요. \ No newline at end of file diff --git a/content/ko/integrations/agentil_software_sap_businessobjects.md b/content/ko/integrations/agentil_software_sap_businessobjects.md index 8b23588343bd5..4fefc2603620a 100644 --- a/content/ko/integrations/agentil_software_sap_businessobjects.md +++ b/content/ko/integrations/agentil_software_sap_businessobjects.md @@ -5,8 +5,8 @@ app_id: agentil-software-sap-businessobjects app_uuid: cac9d777-3bd1-40a1-aef3-28a8141804f1 assets: dashboards: - SAP BusinessObjects overview: assets/dashboards/agentil_software_sap_businessobjects_global_overview.json - SAP BusinessObjects system dashboard: assets/dashboards/agentil_software_sap_businessobjects_system.json + SAP BusinessObjects dashboard: assets/dashboards/agentil_software_sap_businessobjects_system.json + SAP BusinessObjects global overview: assets/dashboards/agentil_software_sap_businessobjects_global_overview.json integration: auto_install: false configuration: {} @@ -29,6 +29,7 @@ author: categories: - marketplace - sap +custom_kind: 통합 dependencies: [] display_on_public_website: true draft: false @@ -37,7 +38,6 @@ integration_id: agentil-software-sap-businessobjects integration_title: SAP BusinessObjects integration_version: '' is_public: true -custom_kind: integration legal_terms: eula: assets/eula.pdf manifest_version: 2.0.0 @@ -110,4 +110,4 @@ SAP BusinessObjects 통합에서는 SAP **BusinessObjects** 시스템을 모니 --- -이 애플리케이션은 Marketplace에서 사용할 수 있고 Datadog Technology Partner에서 지원됩니다. 이 애플리케이션을 구입하려면 여기를 클릭하세요. \ No newline at end of file +이 애플리케이션은 Datadog Marketplace를 통해 제공되며 Datadog 기술 파트너의 지원을 받습니다. 사용하려면 Marketplace에서 구매하세요. \ No newline at end of file diff --git a/content/ko/integrations/amazon_eks.md b/content/ko/integrations/amazon_eks.md index c0bf9044b32ab..3903bb0999a19 100644 --- a/content/ko/integrations/amazon_eks.md +++ b/content/ko/integrations/amazon_eks.md @@ -24,6 +24,7 @@ categories: - kubernetes - log collection - orchestration +custom_kind: 통합 dependencies: - https://github.com/DataDog/integrations-core/blob/master/amazon_eks/README.md display_on_public_website: true @@ -33,7 +34,6 @@ integration_id: amazon-eks integration_title: Amazon EKS integration_version: '' is_public: true -custom_kind: integration manifest_version: 2.0.0 name: amazon_eks public_title: Amazon EKS @@ -55,10 +55,18 @@ tile: - Supported OS::Linux - Supported OS::Windows - Supported OS::macOS + - Offering::Integration configuration: README.md#Setup description: Amazon EKS는 관리형 서비스로, AWS에서 쿠버네티스(Kubernetes)를 손쉽게 실행할 수 있도록 해줍니다. media: [] overview: README.md#Overview + resources: + - resource_type: 블로그 + url: https://www.datadoghq.com/blog/announcing-eks + - resource_type: 블로그 + url: https://www.datadoghq.com/blog/eks-cluster-metrics + - resource_type: 문서 + url: https://docs.datadoghq.com/integrations/eks_fargate/ support: README.md#Support title: Amazon EKS --- @@ -88,11 +96,11 @@ EKS 모니터링을 위해서는 다음 Datadog 통합 중 하나를 설치해 - [쿠버네티스][6] - [AWS][7] -- [AWS EC2][8] +- [Amazon EC2][8] ### 로그 수집 -_에이전트 버전 > 6.0 이상 사용 가능_ +_Agent 버전 6.0 이상에서 사용 가능_ 설치 방법은 쿠버네티스의 설치 방법과 동일합니다. 모든 컨테이너에서 로그 수집을 시작하려면 Datadog 에이전트 [환경 변수][9]를 사용하세요. diff --git a/content/ko/integrations/amazon_mediaconvert.md b/content/ko/integrations/amazon_mediaconvert.md index c3e25fc3943ae..3671fbdea7cfe 100644 --- a/content/ko/integrations/amazon_mediaconvert.md +++ b/content/ko/integrations/amazon_mediaconvert.md @@ -9,7 +9,7 @@ assets: metrics: check: - aws.mediaconvert.hdoutput_duration - metadata_path: metadata.csv + metadata_path: assets/metrics/metric-spec.yaml prefix: aws.mediaconvert. service_checks: metadata_path: assets/service_checks.json @@ -25,6 +25,7 @@ categories: - 메트릭 - 로그 수집 - 클라우드 +custom_kind: integration dependencies: [] display_on_public_website: true draft: false @@ -33,7 +34,6 @@ integration_id: amazon-mediaconvert integration_title: Amazon MediaConvert integration_version: '' is_public: true -custom_kind: integration manifest_version: 2.0.0 name: amazon_mediaconvert public_title: Amazon MediaConvert @@ -46,6 +46,7 @@ tile: - Category::Metrics - Category::Log Collection - Category::Cloud + - 제공::통합 configuration: README.md#Setup description: 텔레비전 및 연결 디바이스에서 비디오 형식을 만들고 압축하기 media: [] @@ -57,7 +58,7 @@ tile: ## 개요 -Amazon Elemental MediaConvert는 오프라인 비디오 컨텐츠의 형식을 지정하고 압축해 텔레비전이나 연결된 디바이스로 전송하는 서비스입니다. +AWS Elemental MediaConvert는 오프라인 비디오 컨텐츠의 형식을 지정하고 압축해 텔레비전이나 연결된 디바이스로 전송하는 서비스입니다. 이 통합을 활성화하면 Elemental MediaConvert 메트릭 전체를 Datadog에서 확인할 수 있습니다. @@ -70,37 +71,37 @@ Amazon Elemental MediaConvert는 오프라인 비디오 컨텐츠의 형식을 ### 메트릭 수집 1. [AWS 통합 페이지][2]에서 `Metric Collection` 탭 아래 `MediaConvert`가 활성화되어 있는지 확인하세요. -2. [Datadog - Amazon Elemental MediaConvert 통합][3]을 설치하세요. +2. [Datadog - AWS Elemental MediaConvert 통합][3]을 설치하세요. ### 로그 수집 #### 로깅 활성화 -S3 버킷이나 CloudWatch로 로그를 전송하도록 Amazon ElementalConvert를 구성하세요. +S3 버킷이나 CloudWatch로 로그를 전송하도록 AWS ElementalConvert를 설정하세요. **참고**: S3 버킷에 로깅하는 경우 `amazon_mediaconvert`가 _Target prefix_로 지정되어야 합니다. -#### Datadog에 로그 전송 +#### Datadog로 로그 전송 1. 아직 설정하지 않은 경우 [Datadog Forwarder Lambda 함수][4]를 설정하세요. -2. Lambda 함수를 설치한 후 AWS 콘솔에서 Amazon Elemental MediaConvert 로그를 포함하는 S3 버킷이나 CloudWatch 로그 그룹에 수동으로 트리거를 추가하세요. +2. Lambda 함수가 설치되면, AWS 콘솔에서 AWS Elemental MediaConvert 로그를 포함하는 S3 버킷이나 CloudWatch 로그 그룹에 수동으로 트리거를 추가하세요. - - [S3 버킷에서 직접 트리거 추가][5] + - [S3 버킷에서 수동 트리거 추가][5] - [CloudWatch 로그 그룹에 수동으로 트리거 추가][6] -## 수집한 데이터 +## 수집한 데이터 ### 메트릭 -{{< get-metrics-from-git "amazon-mediaconvert" >}} +{{< get-metrics-from-git "amazon_mediaconvert" >}} ### 이벤트 -Amazon Elemental MediaConvert 통합에는 이벤트가 포함되어 있지 않습니다. +AWS Elemental MediaConvert 통합에는 이벤트가 포함되지 않습니다. -### 서비스 검사 +### 서비스 점검 -Amazon Elemental MediaConvert 통합에는 서비스 점검이 포함되어 있지 않습니다. +AWS Elemental MediaConvert 통합에는 서비스 점검이 포함되지 않습니다. ## 트러블슈팅 @@ -110,7 +111,7 @@ Amazon Elemental MediaConvert 통합에는 서비스 점검이 포함되어 있 [2]: https://app.datadoghq.com/integrations/amazon-web-services [3]: https://app.datadoghq.com/integrations/amazon-mediaconvert [4]: https://docs.datadoghq.com/ko/logs/guide/forwarder/ -[5]: https://docs.datadoghq.com/ko/logs/guide/send-aws-services-logs-with-the-datadog-lambda-function/?tab=awsconsole#collecting-logs-from-s3-buckets -[6]: https://docs.datadoghq.com/ko/logs/guide/send-aws-services-logs-with-the-datadog-lambda-function/?tab=awsconsole#collecting-logs-from-cloudwatch-log-group -[7]: https://github.com/DataDog/dogweb/blob/prod/integration/amazon_mediaconvert/amazon_mediaconvert_metadata.csv +[5]: https://docs.datadoghq.com/ko/logs/guide/send-aws-services-logs-with-the-datadog-lambda-function/#collecting-logs-from-s3-buckets +[6]: https://docs.datadoghq.com/ko/logs/guide/send-aws-services-logs-with-the-datadog-lambda-function/#collecting-logs-from-cloudwatch-log-group +[7]: https://github.com/DataDog/integrations-internal-core/blob/main/amazon_mediaconvert/assets/metrics/metric-spec.yaml [8]: https://docs.datadoghq.com/ko/help/ \ No newline at end of file diff --git a/content/ko/integrations/avm_consulting_avm_bootstrap_datadog.md b/content/ko/integrations/avm_consulting_avm_bootstrap_datadog.md new file mode 100644 index 0000000000000..6448cc5cf3b57 --- /dev/null +++ b/content/ko/integrations/avm_consulting_avm_bootstrap_datadog.md @@ -0,0 +1,92 @@ +--- +algolia: + subcategory: Marketplace 통합 +app_id: avm-consulting-insightflow +app_uuid: 1f5f3120-5585-45ad-ac50-4b34f73637fd +assets: {} +author: + contact_link: https://avmconsulting.net/contact-us/ + homepage: https://avmconsulting.net/ + name: AVM Consulting + sales_email: contact@avmconsulting.net + support_email: contact@avmconsulting.net + vendor_id: avmconsulting +categories: +- marketplace +custom_kind: integration +dependencies: [] +display_on_public_website: true +draft: false +git_integration_title: avm_consulting_avm_bootstrap_datadog +integration_id: avm-consulting-insightflow +integration_title: InsightFlow - Bootstrap Datadog +integration_version: '' +is_public: true +legal_terms: + eula: assets/eula.pdf +manifest_version: 2.0.0 +name: avm_consulting_avm_bootstrap_datadog +pricing: +- includes_assets: true + private_offer_only: true + product_id: insightflow + short_description: \u0008AVM Consulting은 고객의 고유한 옵저버빌리티 목표를 달성하기 위해 세 가지 맞춤형 솔루션을 + 제공합니다. 예를 들어 관리 서비스에 대한 효과적인 태그 지정 전략 구현, 컨설팅 서비스 제공 등이 있습니다. + unit_price: null +public_title: InsightFlow - Bootstrap Datadog +short_description: AVM의 전문 서비스인 InsightFlow를 통해 Datadog의 모든 기능을 활용하세요. +supported_os: +- linux +- windows +- macos +tile: + changelog: CHANGELOG.md + classifier_tags: + - Supported OS::Linux + - Supported OS::Windows + - Supported OS::macOS + - Category::Marketplace + - Offering::Professional Service + configuration: README.md#Setup + description: AVM의 전문 서비스인 InsightFlow를 통해 Datadog의 모든 기능을 활용하세요. + media: + - caption: AVM InsightFlow + image_url: images/avmpsdd.jpg + media_type: image + overview: README.md#Overview + support: README.md#Support + title: InsightFlow - Bootstrap Datadog + uninstallation: README.md#Uninstallation +--- + + + +## 개요 + +### Bootstrap Datadog: AVM의 InsightFlow로 Datadog의 모든 기능을 활용하세요 + +30일 AVM 지원 프로그램인 InsightFlow를 통해 Datadog에 대한 투자를 극대화하고 모니터링 프로세스를 가속화할 수 있습니다. Datadog의 경험과 필요에 관계없이 고객의 로드맵과 요구 사항을 충족하는 3가지 맞춤형 솔루션을 제공합니다. + +AVM Consulting은 옵저버빌리티, 컨설팅, 태깅 전략, 관리형 서비스, CloudOps, 데이터 및 엔터프라이즈 아키텍처를 전문으로 하는 Datadog Gold Partner이자 캘리포니아 로스앤젤레스에 본사를 둔 글로벌 컨설팅 회사입니다. + +**다음 서비스 중에서 선택하세요:** + +| 패키지 | 이점 | +| ------ | ------ | +|**Starter**: 고급 Datadog 전문 지식과 맞춤형 솔루션을 원하는 조직에 적합합니다.| Slack을 통한 무제한 지원, 트러블슈팅을 위한 Zoom 세션(횟수 제한), AVM Marketplace 통합 할인, 모범 사례 및 시작 가이드 제공. +|**Expert**: 고급 Datadog 전문 지식과 맞춤형 솔루션을 원하는 조직에 적합합니다.| Starter 플랜에 포함된 모든 서비스와 더불어 무제한 Zoom 세션을 통한 트러블슈팅 및 전문가 조언, 종합적인 Datadog 환경 평가 및 갭 분석, 태그 지정, APM, 로그-메트릭-트레이스 상관관계, RUM 등에 대한 모범 권장 사항 제공. +|**Enterprise**: Datadog 투자를 극대화하고 탁월한 옵저버빌리티 표준을 달성하려는 대규모 조직에 적합한 가장 포괄적인 솔루션입니다.| Expert 플랜에 포함된 모든 것 외에 전담 시니어 Datadog 전문가, 명확한 목표와 이니셔티브를 갖춘 맞춤형 옵저버빌리티 로드맵 개발, 최적의 성능 모니터링을 위한 SLO 및 SLA 식별, 고급 Datadog 기능 및 통합에 대한 전문가 가이드, 원활한 구현과 지속적인 최적화를 위한 현장 지원 등 제공. + +**InsightFlow를 통해 다음을 수행할 수 있습니다* +- 팀 생산성 향상: 팀이 핵심 작업에 집중할 수 있도록 역량을 강화합니다. +- 순조로운 진행: 모니터링 전략이 로드맵과 일치하도록 합니다. +- 리스크 감소: 구현 문제를 줄이고 ROI를 극대화합니다. + +## 지원 +지원이나 추가 기능이 필요한 경우 다음 채널을 통해 AVM에 문의해 주세요. +- 이메일: contact@avmconsulting.net +- 전화: 855-AVM-0555 + + +--- +이 애플리케이션은 Datadog Marketplace를 통해 제공되며 Datadog 기술 파트너의 지원을 받습니다. 사용하려면 Marketplace에서 이 애플리케이션을 구매하세요. \ No newline at end of file diff --git a/content/ko/integrations/cloud_foundry_api.md b/content/ko/integrations/cloud_foundry_api.md index bcf88d76de16f..d5b532a325fbd 100644 --- a/content/ko/integrations/cloud_foundry_api.md +++ b/content/ko/integrations/cloud_foundry_api.md @@ -26,11 +26,11 @@ custom_kind: integration dependencies: - https://github.com/DataDog/integrations-core/blob/master/cloud_foundry_api/README.md display_on_public_website: true -draft: true +draft: false git_integration_title: cloud_foundry_api integration_id: cloud-foundry-api integration_title: Cloud Foundry API -integration_version: 5.0.0 +integration_version: 5.2.0 is_public: true manifest_version: 2.0.0 name: cloud_foundry_api @@ -70,7 +70,7 @@ tile: ### 설치 -Cloud Foundry API 점검은 [Datadog 에이전트][3] 패키지에 포함됩니다. +Cloud Foundry API 점검은 [Datadog 에이전트][3] 패키지에 포함됩니다. 서버에 추가 설치할 필요가 없습니다. ### 구성 @@ -86,7 +86,7 @@ Cloud Foundry API 점검은 [Datadog 에이전트][3] 패키지에 포함됩니 ## 수집한 데이터 ### 메트릭 -{{< get-metrics-from-git "cloud-foundry-api" >}} +{{< get-metrics-from-git "cloud_foundry_api" >}} ### 이벤트 @@ -94,7 +94,7 @@ Cloud Foundry API 점검은 [Datadog 에이전트][3] 패키지에 포함됩니 Cloud Foundry API 통합으로 설정한 감사 이벤트를 수집합니다. ### 서비스 점검 -{{< get-service-checks-from-git "cloud-foundry-api" >}} +{{< get-service-checks-from-git "cloud_foundry_api" >}} ## 트러블슈팅 @@ -110,4 +110,4 @@ Cloud Foundry API 통합으로 설정한 감사 이벤트를 수집합니다. [6]: https://docs.datadoghq.com/ko/agent/guide/agent-commands/#agent-status-and-information [7]: https://github.com/DataDog/integrations-core/blob/master/cloud_foundry_api/metadata.csv [8]: https://github.com/DataDog/integrations-core/blob/master/cloud_foundry_api/assets/service_checks.json -[9]: https://docs.datadoghq.com/ko/help +[9]: https://docs.datadoghq.com/ko/help \ No newline at end of file diff --git a/content/ko/integrations/consul_connect.md b/content/ko/integrations/consul_connect.md index 30bdeb2590dc0..115d0a1f4f206 100644 --- a/content/ko/integrations/consul_connect.md +++ b/content/ko/integrations/consul_connect.md @@ -22,6 +22,7 @@ categories: - 네트워크 - 로그 수집 - 컨테이너 +custom_kind: 통합 dependencies: - https://github.com/DataDog/integrations-core/blob/master/consul_connect/README.md display_on_public_website: true @@ -31,7 +32,6 @@ integration_id: consul-connect integration_title: Consul Connect integration_version: '' is_public: true -custom_kind: 통합 manifest_version: 2.0.0 name: consul_connect public_title: Consul Connect @@ -39,7 +39,7 @@ short_description: Consul Connect Envoy 사이드카 프록시를 모니터링 supported_os: - linux - macos -- windows +- 윈도우즈(Windows) tile: changelog: CHANGELOG.md classifier_tags: @@ -49,6 +49,7 @@ tile: - Category::Network - Category::Log Collection - Category::Containers + - Offering::Integration configuration: README.md#Setup description: Consul Connect Envoy 사이드카 프록시를 모니터링하세요. media: [] @@ -70,7 +71,7 @@ tile: Consul Connect를 실행하는 서비스에 [Datadog Agent][4]를 설치하고 해당 환경에 맞는 [구성](#configuration) 지침을 따르세요. -### 구성 +### 설정 호스트에서 실행 중인 Agent에 대해 이 검사를 구성하려면 아래 지침을 따르세요. 컨테이너화된 환경의 경우 [Containerized](#containerized) 섹션을 참조하세요. {{< tabs >}} @@ -78,7 +79,7 @@ Consul Connect를 실행하는 서비스에 [Datadog Agent][4]를 설치하고 #### 호스트 -호스트에서 실행 중인 에이전트에 대해 이 점검을 구성하려면: +호스트에서 실행 중인 에이전트에 이 점검을 구성하는 방법: ##### 메트릭 수집 1. Consul Connect에서 구성 옵션 [`-admin-bind`][1]을 활성화하여 Envoy Admin API가 노출되는 포트를 구성합니다. @@ -93,9 +94,9 @@ Consul Connect를 실행하는 서비스에 [Datadog Agent][4]를 설치하고 [2]: https://docs.datadoghq.com/ko/integrations/envoy/?tab=host#metric-collection [3]: https://docs.datadoghq.com/ko/integrations/envoy/?tab=host#log-collection {{% /tab %}} -{{% tab "컨테이너화" %}} +{{% tab "Containerized" %}} -#### 컨테이너화 +#### 컨테이너화된 환경 [Envoy 컨테이너화 지침][1]에 따라 Envoy용 Datadog Agent를 구성합니다. @@ -120,7 +121,7 @@ Consul Connect를 실행하는 서비스에 [Datadog Agent][4]를 설치하고 [Agent의 상태 하위 명령을 실행][5]하고 Checks 섹션에서 `envoy`를 찾습니다. -## 수집한 데이터 +## 수집한 데이터 ### 메트릭 diff --git a/content/ko/integrations/eks_anywhere.md b/content/ko/integrations/eks_anywhere.md new file mode 100644 index 0000000000000..1bd2c13742e97 --- /dev/null +++ b/content/ko/integrations/eks_anywhere.md @@ -0,0 +1,155 @@ +--- +app_id: eks-anywhere +app_uuid: 21bd91d8-7594-4c2f-bbd8-11595e4511d1 +assets: + integration: + auto_install: true + configuration: {} + events: + creates_events: false + service_checks: + metadata_path: assets/service_checks.json + source_type_id: 10248 + source_type_name: Amazon EKS Anywhere +author: + homepage: https://www.datadoghq.com + name: Datadog + sales_email: info@datadoghq.com + support_email: help@datadoghq.com +categories: +- aws +- 클라우드 +- 컨테이너 +- 쿠버네티스(Kubernetes) +- 로그 수집 +- 오케스트레이션 +- 프로비저닝 +custom_kind: 통합 +dependencies: +- https://github.com/DataDog/integrations-core/blob/master/eks_anywhere/README.md +display_on_public_website: true +draft: false +git_integration_title: eks_anywhere +integration_id: eks-anywhere +integration_title: Amazon EKS Anywhere +integration_version: '' +is_public: true +manifest_version: 2.0.0 +name: eks_anywhere +public_title: Amazon EKS Anywhere +short_description: 온프레미스에서 Kubernetes 클러스터를 운영하기 위한 EKS 배포 옵션 +supported_os: +- linux +- 윈도우즈(Windows) +- macos +tile: + changelog: CHANGELOG.md + classifier_tags: + - Category::AWS + - Category::Cloud + - Category::Containers + - Category::Kubernetes + - Category::Log Collection + - Category::Orchestration + - Category::Provisioning + - Supported OS::Linux + - Supported OS::Windows + - Supported OS::macOS + - Offering::Integration + configuration: README.md#Setup + description: 온프레미스에서 Kubernetes 클러스터를 운영하기 위한 EKS 배포 옵션 + media: [] + overview: README.md#Overview + resources: + - resource_type: 블로그 + url: https://www.datadoghq.com/blog/announcing-eks + - resource_type: 블로그 + url: https://www.datadoghq.com/blog/eks-cluster-metrics + - resource_type: 설명서 + url: https://docs.datadoghq.com/integrations/eks_fargate/ + support: README.md#Support + title: Amazon EKS Anywhere +--- + + + + +![EKS Dashboard][1] + +## 개요 + +Amazon Elastic Kubernetes Service(EKS)는 모든 표준 Kubernetes 환경에 대한 배포 및 유지 관리의 특정 측면을 자동화하는 관리형 Kubernetes 서비스입니다. 기존 Kubernetes 애플리케이션을 Amazon EKS로 마이그레이션하든 AWS Outposts의 Amazon EKS에 새 클러스터를 배포하든 Datadog은 EKS 환경을 실시간으로 모니터링하는 데 도움이 됩니다. + +[Amazon EKS Anywhere][2]는 가상 머신(예: VMware vSphere) 및 베어 메탈 서버를 포함하여 온프레미스에서 Kubernetes 클러스터를 생성하고 운영할 수 있는 배포 옵션입니다. + +## 설정 + +그 이유는 바로 Datadog가 이미 쿠버네티스(Kubernetes)와 AWS에 통합되었기 때문입니다. EKS 모니터링에 바로 사용할 수 있습니다. 쿠버네티스 클러스터에서 에이전트를 실행하거나 EKS로 마이그레이션할 계획이라면 Datadog를 사용해 클러스터를 계속 모니터링할 수 있습니다. + +또한 [Amazon EKS Managed Node Groups][3] 및 [Amazon EKS on AWS Outposts][4]가 지원됩니다. + +### Datadog Helm 차트 설정 + +다음 추가 구성 지침과 함께 [Helm을 사용한 Agent 배포 지침][5]을 사용하세요. + +1. `datadog.kubelet.tlsVerify`를 `false`로 설정합니다. +2. Agent 파드에서 허용 오차를 설정합니다. 이는 컨트롤 플레인을 모니터링하는 데 필요합니다. + +다음 Helm 스니펫은 EKS Anywhere 모니터링에 대한 구체적인 변경 사항을 보여줍니다. + +```yaml +datadog: + kubelet: + tlsVerify: false +agents: + tolerations: + - effect: NoSchedule + key: node-role.kubernetes.io/master + operator: Exists +``` + +### 메트릭 수집 + +EKS를 모니터링하려면 [ELB][6]와 같이 EKS로 실행 중인 다른 AWS 서비스에 대한 통합과 함께 다음 Datadog 통합 중 하나를 설정해야 합니다. + +- [Kubernetes][7] +- [AWS][8] +- [AWS EC2][9] + +### 로그 수집 + +_에이전트 버전 > 6.0에서 사용 가능_ + +설정은 Kubernetes와 동일합니다. +모든 컨테이너에서 로그 수집을 시작하려면 Datadog Agent [환경 변수][10]를 사용하세요. + +DaemonSets를 사용하여 [모든 노드에 Datadog Agent를 자동으로 배포][11]합니다. + +환경 변수 및 고급 설정 옵션에 대해 자세히 알아보려면 [컨테이너 로그 수집 지침][12]을 따르세요. + +## 트러블슈팅 + +도움이 필요하세요? [Datadog 지원팀][13]에 문의하세요. + +## 참고 자료 + +- [Datadog으로 Amazon EKS 모니터링][14] +- [Amazon EKS 모니터링의 주요 메트릭][15] +- [AWS Fargate의 Amazon EKS][16] + +[1]: https://raw.githubusercontent.com/DataDog/integrations-core/master/amazon_eks/images/amazon_eks_dashboard.png +[2]: https://aws.amazon.com/eks/eks-anywhere/ +[3]: https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html +[4]: https://docs.aws.amazon.com/eks/latest/userguide/eks-on-outposts.html +[5]: https://docs.datadoghq.com/ko/agent/kubernetes/?tab=helm#installation +[6]: https://docs.datadoghq.com/ko/integrations/amazon_elb/ +[7]: https://docs.datadoghq.com/ko/integrations/kubernetes/ +[8]: https://docs.datadoghq.com/ko/integrations/amazon_web_services/ +[9]: https://docs.datadoghq.com/ko/integrations/amazon_ec2/ +[10]: https://docs.datadoghq.com/ko/agent/basic_agent_usage/kubernetes/#log-collection-setup +[11]: https://docs.datadoghq.com/ko/agent/basic_agent_usage/kubernetes/#container-installation +[12]: https://docs.datadoghq.com/ko/logs/log_collection/docker/#option-2-container-installation +[13]: https://docs.datadoghq.com/ko/help/ +[14]: https://www.datadoghq.com/blog/announcing-eks +[15]: https://www.datadoghq.com/blog/eks-cluster-metrics +[16]: https://docs.datadoghq.com/ko/integrations/eks_fargate/ \ No newline at end of file diff --git a/content/ko/integrations/embrace_mobile.md b/content/ko/integrations/embrace_mobile.md index d99ab7c94d727..00fd185cd9d92 100644 --- a/content/ko/integrations/embrace_mobile.md +++ b/content/ko/integrations/embrace_mobile.md @@ -58,20 +58,14 @@ tile: - 카테고리::메트릭 - Category::Mobile - Category::Network - - 제공::UI 확장 + - Offering::Integration + - Submitted Data Type::Metrics - Supported OS::Linux - Supported OS::Windows - Supported OS::macOS configuration: README.md#Setup description: iOS, Android, React Native 및 Unity의 모바일 옵저버빌리티 media: - - caption: 위젯을 추가하여 Datadog에서 직접 Embrace 충돌 및 네트워킹 데이터를 모니터링하세요. - image_url: images/datadog_dashboard.jpg - media_type: image - - caption: 앱 및 세션 세부정보와 함께 영향을 받은 모든 사용자 세션의 모든 스택 트레이스에 액세스하여 충돌을 조사합니다. 자세한 내용을 - 보려면 Embrace의 전체 사용자 세션 재생으로 직접 이동하세요. - image_url: images/datadog_side_panel.jpg - media_type: image - caption: Embrace의 사용자 세션 재생은 시간 기반 시각화로 모든 사용자 세션의 전체 기술 및 동작 세부 정보를 제공합니다. 문제를 수동으로 재현할 필요 없이 근본 원인을 즉시 식별합니다. image_url: images/embrace_session.jpg @@ -104,8 +98,6 @@ Embrace의 핵심은 복잡한 모바일 데이터를 실행 가능한 데이터 1. 무료 평가판을 시작하고 [Embrace 문서][2]를 참고하세요. **Datadog에서 메트릭을 확인하기 전 먼저 이 문서의 지침을 따라야 합니다.** 1. Embrace 통합 설정을 완료한 후 Datadog으로 다시 이동하여 두 플랫폼을 모두 연결하세요. 1. 크리덴셜로 로그인하여 Embrace 계정을 인증하고 Datadog에 연결하세요. -1. Datadog에서 New Dashboard를 만듭니다. Embrace 위젯을 선택하여 충돌 또는 네트워킹 메트릭이 포함된 Embrace 데이터를 표시합니다. -1. Datadog의 Embrace에 대해 더 자세히 알아보려면 "Details"를 클릭하세요. ## 지원 diff --git a/content/ko/integrations/google_cloud_datastore.md b/content/ko/integrations/google_cloud_datastore.md index 899fc4a81d62b..7e3b10fbe6c31 100644 --- a/content/ko/integrations/google_cloud_datastore.md +++ b/content/ko/integrations/google_cloud_datastore.md @@ -1,4 +1,24 @@ --- +app_id: google-cloud-datastore +app_uuid: 93acce72-3f1c-444f-8518-0f16635af95d +assets: + integration: + auto_install: false + events: + creates_events: false + metrics: + check: gcp.datastore.api.request_count + metadata_path: metadata.csv + prefix: gcp.datastore. + service_checks: + metadata_path: assets/service_checks.json + source_type_id: 184 + source_type_name: Google Cloud Datastore +author: + homepage: https://www.datadoghq.com + name: Datadog + sales_email: info@datadoghq.com + support_email: help@datadoghq.com categories: - cloud - data stores @@ -8,22 +28,39 @@ categories: custom_kind: 통합 dependencies: [] description: Datastore 읽기/쓰기 성능, 요청, 카운트 등을 추적합니다. +display_on_public_website: true doc_link: https://docs.datadoghq.com/integrations/google_cloud_datastore/ draft: false git_integration_title: google_cloud_datastore has_logo: true integration_id: google-cloud-datastore -integration_title: Google Datastore +integration_title: Google Cloud Datastore integration_version: '' is_public: true -manifest_version: '1.0' +manifest_version: 2.0.0 name: google_cloud_datastore -public_title: Datadog-Google Datastore 통합 -short_description: Datastore 읽기/쓰기 성능, 요청, 카운트 등을 추적합니다. +public_title: Google Cloud Datastore +short_description: Cloud Datastore는 확장성이 뛰어난 웹 및 모바일 애플리케이션용 NoSQL 데이터베이스입니다. +supported_os: [] +tile: + changelog: CHANGELOG.md + classifier_tags: + - Category::Cloud + - Category::Data Stores + - Category::Google Cloud + - Category::Log Collection + - Category::Mobile + - Offering::Integration + configuration: README.md#Setup + description: Cloud Datastore는 확장성이 뛰어난 웹 및 모바일 애플리케이션용 NoSQL 데이터베이스입니다. + media: [] + overview: README.md#Overview + support: README.md#Support + title: Google Cloud Datastore version: '1.0' --- - + ## 개요 Cloud Datastore는 확장성이 뛰어난 웹 및 모바일 애플리케이션용 NoSQL 데이터베이스입니다. @@ -53,7 +90,7 @@ Google Cloud Datastore 로그는 Google Cloud Logging으로 수집하여 클라 ## 수집한 데이터 ### 메트릭 -{{< get-metrics-from-git "google-cloud-datastore" >}} +{{< get-metrics-from-git "google_cloud_datastore" >}} ### 이벤트 diff --git a/content/ko/integrations/guide/application-monitoring-vmware-tanzu.md b/content/ko/integrations/guide/application-monitoring-vmware-tanzu.md new file mode 100644 index 0000000000000..68735d15514ae --- /dev/null +++ b/content/ko/integrations/guide/application-monitoring-vmware-tanzu.md @@ -0,0 +1,68 @@ +--- +description: VMware Tanzu용 Datadog 애플리케이션 모니터 +further_reading: +- link: https://www.datadoghq.com/blog/monitor-tanzu-application-service/ + tag: 블로그 + text: VMware Tanzu Application Service에서 실행되는 애플리케이션 모니터 +- link: /integrations/guide/cluster-monitoring-vmware-tanzu/ + tag: documentation + text: VMware Tanzu용 Datadog 클러스터 모니터 +- link: /tracing/ + tag: documentation + text: 애플리케이션 성능 모니터 +- link: /developers/dogstatsd/ + tag: documentation + text: DogStatsD으로 커스텀 메트릭을 Datadog에 포워딩하기 +title: VMware Tanzu용 Datadog 애플리케이션 모니터 +--- + + +## 개요 + +VMware Tanzu용 Datadog 애플리케이션 모니터로 VMware Tanzu 사용자는 애플리케이션의 상태와 성능을 모니터링할 수 있습니다. +이는 다음 세 가지 컴포넌트로 구성됩니다. + +* DogStatsD +* 트레이스 에이전트 +* Container Agent + +DogStatsD를 통해 커스텀 애플리케이션 메트릭을 Datadog로 가져올 수 있습니다. DogStatsD는 StatsD 프로토콜을 구현하고, 몇 가지 Datadog 전용 확장 기능을 추가하는 메트릭 집계 서비스입니다. 자세한 내용은 [DogStatsD][5] 문서를 참조하세요. 아울러, Datadog은 애플리케이션과 호환되는 [라이브러리][9] 를 찾는 데 사용할 수 있는 DogStatsD 라이브러리의 목록을 제공해 드립니다. + +트레이스 Agent는 다양한 소스에서 애플리케이션 트레이스를 수집하여 Datadog APM으로 포워딩하는 서비스입니다. 자세한 내용은 [트레이싱][7] 문서를 참조하세요. + +컨테이너 Agent는 [Datadog Agent][6]의 더 작고 가벼운 버전으로, 메트릭과 로그를 Datadog으로 포워딩할 수 있습니다. 자세한 내용은 [로그][8] 설명서를 참조하세요. 이를 활성화하면 기본 동작은 `stdout` 및 `stderr`의 모든 로그를 수집하여 TCP를 통해 컨테이너 Agent로 포워딩하는 것입니다. + +## 주요 기능 +VMware Tanzu용 Datadog 애플리케이션 모니터에는 다음과 같은 주요 기능이 포함됩니다. + +* 애플리케이션 성능 모니터 +* Datadog으로 메트릭, 로그, 트레이스를 포워딩 + +## 사전 필수 조건 +VMware Tanzu용 Datadog 애플리케이션 모니터에는 다음과 같은 필수 조건이 있습니다. + +* 타일을 설정하기 전 [Datadog 계정][4]이 있거나 생성해야 합니다. +* [Datadog API 키][3]를 생성해야 합니다. + +## 설치 + +1. [Tanzu 네트워크][10]에서 **VMware Tanzu용 Datadog 애플리케이션 모니터** 제품 파일을 다운로드합니다. +2. Tanzu Ops Manager 설치 대시보드로 이동하여 **Import a Product**를 클릭해 제품 파일을 업로드하세요. +3. **1** 단계에서 다운로드한 제품 파일을 선택합니다. 이렇게 하면 스테이지 영역에 타일이 추가됩니다. +4. 새로 추가된 **VMware Tanzu용 Datadog 애플리케이션 모니터** 타일을 클릭합니다. +5. **Save**를 클릭합니다. +6. Tanzu Ops Manager 설치 대시보드로 돌아가서 **Apply changes**를 클릭하여 VMware Tanzu용 Datadog 애플리케이션 모니터 타일을 설치합니다. + +## 참고 자료 + +{{< partial name="whats-next/whats-next.html" >}} + +[2]: /ko/help +[3]: https://app.datadoghq.com/organization-settings/api-keys +[4]: https://app.datadoghq.com/signup +[5]: /ko/developers/dogstatsd/?tab=hostagent +[6]: /ko/agent/ +[7]: /ko/tracing/ +[8]: /ko/logs/ +[9]: /ko/libraries/ +[10]: https://network.pivotal.io/products/datadog-application-monitoring/ \ No newline at end of file diff --git a/content/ko/integrations/guide/send-tcp-udp-host-metrics-to-the-datadog-api.md b/content/ko/integrations/guide/send-tcp-udp-host-metrics-to-the-datadog-api.md new file mode 100644 index 0000000000000..f9986e4482aaf --- /dev/null +++ b/content/ko/integrations/guide/send-tcp-udp-host-metrics-to-the-datadog-api.md @@ -0,0 +1,37 @@ +--- +aliases: +- /ko/integrations/faq/how-to-send-tcp-udp-host-metrics-via-the-datadog-api +title: Datadog API에 TCP/UDP 호스트 메트릭 전송 +--- + +Crontab Entry를 통해 통계를 수집하여 Datadog 플랫폼으로 전달하면 TCP/UDP 연결에 대한 인사이트를 얻을 수 있습니다. + +이 작업을 하려면 /proc/net/sockstat에 위치한 Linux sockstats를 사용하세요. + +아래는 참고용 예제 코드 스니펫입니다. + +https://gist.github.com/sage-oli-wood/70e0931f037ea0aac132 + +이렇게 하면 HTTP POST를 통해 데이터가 Datadog에 제출됩니다. + +더 적절한 방법은 DogStatsD를 사용하여 메트릭과 이벤트를 전송하는 것입니다. Cron 작업을 수정하여 데이터를 로컬에서 UDP를 통해 Agent로 전달할 수 있습니다. 자세한 내용은 여기에서 확인하세요. + +다음에서 데이터를 가져옵니다. + +* TCP: + +|||| +|:---|:---|:---| +|in use| 설정된 총 연결 수 | 정수(숫자)| +|Orphan| 고립된 TCP 연결 | +(어떤 사용자 파일 핸들에도 첨부되지 않음) 정수 (숫자)| +|TW | TIME_WAIT 연결 | 정수 (밀리초)| +|Alloc| 할당된 TCP 소켓 | (모든 유형. 예를 들어, ESTABLISH, CLOSE_WAIT, TIME_WAIT 등)| +|mem| TCP 소켓의 총 메모리 | 정수 (KB)| + +* UDP: + +|||| +|:---|:---|:---| +|inuse| 설정된 총 연결 수 | 정수| +|mem |UDP 소켓의 총 메모리 | 정수(KB)| \ No newline at end of file diff --git a/content/ko/integrations/hcp_vault.md b/content/ko/integrations/hcp_vault.md new file mode 100644 index 0000000000000..53f615cc5288d --- /dev/null +++ b/content/ko/integrations/hcp_vault.md @@ -0,0 +1,126 @@ +--- +app_id: hcp-vault +app_uuid: ad48fccf-95f1-4ead-ae7f-efac1757418a +assets: + dashboards: + HCPVault Overview: assets/dashboards/hcp_vault_overview.json + integration: + auto_install: true + configuration: {} + events: + creates_events: false + metrics: + check: [] + metadata_path: metadata.csv + prefix: hcp_vault. + service_checks: + metadata_path: assets/service_checks.json + source_type_id: 10223 + source_type_name: HCPVault +author: + homepage: https://github.com/DataDog/integrations-extras + name: Datadog + sales_email: help@datadoghq.com + support_email: help@datadoghq.com +categories: [] +custom_kind: 통합 +dependencies: +- https://github.com/DataDog/integrations-extras/blob/master/hcp_vault/README.md +display_on_public_website: true +draft: false +git_integration_title: hcp_vault +integration_id: hcp-vault +integration_title: HCP Vault +integration_version: '' +is_public: true +manifest_version: 2.0.0 +name: hcp_vault +public_title: HCP Vault +short_description: HCP Vault 통합에서 Vault 클러스터에 대한 개요를 확인할 수 있습니다. +supported_os: +- linux +- macos +- 윈도우즈(Windows) +tile: + changelog: CHANGELOG.md + classifier_tags: + - Supported OS::Linux + - Supported OS::macOS + - Supported OS::Windows + - Offering::Integration + configuration: README.md#Setup + description: HCP Vault 통합에서 Vault 클러스터에 대한 개요를 확인할 수 있습니다. + media: [] + overview: README.md#Overview + support: README.md#Support + title: HCP Vault +--- + + + + +## 개요 + +HCP Vault(통합)는 Vault 클러스터에 대한 개요를 제공하여 성능 및 클러스터 상태를 모니터링할 수 있습니다. + +HCP Vault 메트릭 스트리밍은 모든 프로덕션 등급 클러스터 티어에서 사용할 수 있습니다. 개발 티어 클러스터에서는 이 기능을 사용할 수 없습니다. + +메트릭 범위 및 해석에 대한 자세한 내용은 [HCP Vault 메트릭 안내][1]를 참조하세요. + +## 설정 + +### 설치 + +아래 설정 안내를 따르세요. + +### 사전 필수 조건 +- 프로덕션 등급 HCP Vault 클러스터 +- Datadog 지역 및 [Datadog API 키][2] +- 관리자 또는 기여자[HCP에서 할당된 역할][3]가 있는 계정 + +### 설정 + +메트릭 스트리밍을 활성화하려면 + +1. HCP Vault 클러스터 개요에서 메트릭 보기를 선택합니다. + + ![메트릭 스트리밍][4] + +2. 아직 메트릭 스트리밍을 설정하지 않은 경우 스트리밍 사용을 클릭합니다. + +3. Stream Vault 메트릭 보기에서 Datadog를 공급자 로 선택합니다. + +4. Datadog 설정에서 API 키를 입력하고 Datadog 환경과 일치하는 Datadog 사이트 지역을 선택합니다. + + ![공급자 선택][5] + +5. 저장을 클릭합니다. +**참고**: HCP Vault는 한 번에 하나의 메트릭 엔드포인트에 대해서만 메트릭 스트리밍을 지원합니다. + +6. Datadog로 이동한 다음 통합 타일에서 설치를 클릭하여 통합을 활성화합니다. 이렇게 하면 HCP Vault 원격 분석을 최대한 활용할 수 있도록 지원하는 위젯 및 HCP Vault 대시보드가 설치됩니다. 대시보드 목록에서 "HCP Vault 개요"를 검색하여 대시보드를 찾을 수 있습니다. + **참고**: 대시보드 메트릭에서 `cluster` & `project_id` 값을 입력하여 올바른 클러스터를 선택합니다. `cluster`는 클러스터 생성 시 설정한 클러스터의 이름입니다. `project_id`는 HCP 포털의 URL `https://portal.cloud.hashicorp.com/orgs/xxxx/projects/xxxx`에 있는 이름입니다. + +## 수집한 데이터 + +### 메트릭 + +메트릭 범위 및 해석에 대한 자세한 내용은 [HCP Vault 메트릭 안내][1]를 참조하세요. + +### 서비스 점검 + +HCP Vault 통합에는 서비스 점검이 포함되지 않습니다. + +### 이벤트 + +HCP Vault 통합은 이벤트를 포함하지 않습니다. + +## 트러블슈팅 + +도움이 필요하신가요? [Datadog 지원팀][6]에 문의하세요. + +[1]: https://learn.hashicorp.com/collections/vault/cloud +[2]: https://docs.datadoghq.com/ko/account_management/api-app-keys/ +[3]: https://cloud.hashicorp.com/docs/hcp/access-control +[4]: https://raw.githubusercontent.com/DataDog/integrations-extras/master/hcp_vault/images/metrics-streaming.png +[5]: https://raw.githubusercontent.com/DataDog/integrations-extras/master/hcp_vault/images/choose-provider.png +[6]: https://docs.datadoghq.com/ko/help/ \ No newline at end of file diff --git a/content/ko/integrations/ibm_i.md b/content/ko/integrations/ibm_i.md index acc73d632786e..994f669b9f4ef 100644 --- a/content/ko/integrations/ibm_i.md +++ b/content/ko/integrations/ibm_i.md @@ -24,8 +24,8 @@ author: sales_email: info@datadoghq.com support_email: help@datadoghq.com categories: -- os & system -custom_kind: integration +- OS & 시스템 +custom_kind: 통합 dependencies: - https://github.com/DataDog/integrations-core/blob/master/ibm_i/README.md display_on_public_website: true @@ -40,7 +40,7 @@ name: ibm_i public_title: IBM i short_description: 작업, 작업 대기열, ASP 등을 포함하여 IBM i 시스템을 원격으로 모니터링하세요. supported_os: -- 리눅스 +- linux - macos tile: changelog: CHANGELOG.md @@ -48,7 +48,7 @@ tile: - Supported OS::Linux - Supported OS::macOS - Category::OS & System - - 제공::통합 + - Offering::Integration configuration: README.md#Setup description: 작업, 작업 대기열, ASP 등을 포함하여 IBM i 시스템을 원격으로 모니터링하세요. media: [] @@ -66,7 +66,7 @@ tile: ## 설정 -아래 지침을 따라 호스트에서 실행되는 에이전트에 대해 이 점검을 설치하고 설정하세요. 컨테이너화된 환경의 경우 이러한 지침을 적용하는 데 가이드가 필요하면 [오토파일럿 통합 템플릿][3]을 참조하세요. +아래 지침을 따라 호스트에서 실행되는 에이전트에 대해 이 점검을 설치하고 설정하세요. 컨테이너화된 환경의 경우 이러한 지침을 적용하는 데 가이드가 필요하면 [자동탐지 통합 템플릿][2]을 참조하세요. **참고**: 이 검사는 Unix 계열 운영 체제에 특정한 `fcntl()` 시스템 호출을 사용하므로 Windows에서는 사용할 수 없습니다. @@ -75,7 +75,7 @@ tile: IBM i 점검은 [Datadog Agent][3] 패키지에 포함되어 있습니다. 서버에 추가 설치가 필요하지 않습니다. -#### ODBC 드라이버 +#### ODBC 드라이버 IBM i 검사는 IBM i ODBC 드라이버를 사용하여 IBM i 호스트에 원격으로 연결합니다. @@ -83,7 +83,7 @@ IBM i 검사는 IBM i ODBC 드라이버를 사용하여 IBM i 호스트에 원 Linux 호스트용 `ACS Linux App Pkg` 등 플랫폼에 맞는 `ACS App Pkg` 패키지를 선택합니다. 패키지를 다운로드하고 설치 지침에 따라 드라이버를 설치합니다. -### 구성 +### 설정 IBM i 검사는 Datadog Agent를 실행하는 호스트에서 원격으로 IBM i 시스템을 쿼리합니다. IBM i 시스템과 통신하려면 Datadog Agent를 실행하는 호스트에 IBM i ODBC 드라이버를 설정해야 합니다. @@ -111,7 +111,7 @@ IBM i 검사를 구성하려면 IBM i ODBC 드라이버의 이름이 필요합 1. Agent의 구성 디렉터리 루트에 있는 `conf.d/` 폴더에서 `ibm_i.d/conf.yaml` 파일을 편집하여 IBM i 성능 데이터 수집을 시작하세요. 사용 가능한 모든 구성 옵션은 [샘플 ibm_i.d/conf.yaml][5]을 참조하세요. `obdcinst.ini` 파일의 드라이버 이름을 사용하세요. -2. [Agent를 재시작합니다][6]. +2. [에이전트를 재시작합니다][6]. ### 검증 @@ -120,7 +120,7 @@ IBM i 검사를 구성하려면 IBM i ODBC 드라이버의 이름이 필요합 ## 수집한 데이터 ### 메트릭 -{{< get-metrics-from-git "ibm-i" >}} +{{< get-metrics-from-git "ibm_i" >}} ### 이벤트 diff --git a/content/ko/integrations/loadrunner_professional.md b/content/ko/integrations/loadrunner_professional.md new file mode 100644 index 0000000000000..e1721ded31f8e --- /dev/null +++ b/content/ko/integrations/loadrunner_professional.md @@ -0,0 +1,144 @@ +--- +app_id: loadrunner-professional +app_uuid: e6b5ab52-139d-4dde-a4ad-94fedeac7f29 +assets: + dashboards: + loadrunner_professional_overview: assets/dashboards/loadrunner_professional_overview.json + integration: + auto_install: true + configuration: {} + events: + creates_events: false + metrics: + check: + - loadrunner.vusers.running + - loadrunner.vusers.ready + - loadrunner.vusers.finished + - loadrunner.vusers.error + - loadrunner.total.transactions.passed.per.sec + - loadrunner.transaction.response_time + - loadrunner.transaction.passed + - loadrunner.transaction.failed + - loadrunner.transaction.stopped + metadata_path: metadata.csv + prefix: loadrunner. + service_checks: + metadata_path: assets/service_checks.json + source_type_id: 8492858 + source_type_name: LoadRunner Professional + logs: + source: loadrunner +author: + homepage: https://www.microfocus.com/en-us/products/loadrunner-professional/overview + name: OpenText + sales_email: dmcleish@opentext.com + support_email: MFI-Supportline@opentext.com +categories: +- 테스트 +custom_kind: integration +dependencies: +- https://github.com/DataDog/integrations-extras/blob/master/loadrunner_professional/README.md +display_on_public_website: true +draft: false +git_integration_title: loadrunner_professional +integration_id: loadrunner-professional +integration_title: LoadRunner Professional +integration_version: '' +is_public: true +manifest_version: 2.0.0 +name: loadrunner_professional +public_title: LoadRunner Professional +short_description: LoadRunner Professional 메트릭과 시나리오 실행 정보를 Datadog으로 보내세요 +supported_os: +- windows +- linux +tile: + changelog: CHANGELOG.md + classifier_tags: + - 지원 OS::Windows + - 지원 OS::Linux + - Category::Testing + - 제공::통합 + - Submitted Data Type::Metrics + - 제출한 데이터 유형::로그 + configuration: README.md#Setup + description: LoadRunner Professional 메트릭과 시나리오 실행 정보를 Datadog으로 보내세요 + media: + - caption: Controller Design 탭 + image_url: images/controller_design.png + media_type: image + - caption: Controller Run 탭 + image_url: images/controller_run.png + media_type: image + - caption: Analysis Summary Report + image_url: images/analysis_summary.png + media_type: image + - caption: Vugen New Script + image_url: images/vugen_new.png + media_type: image + - caption: Datadog 구성 창 + image_url: images/datadog_configuration_window.png + media_type: image + overview: README.md#Overview + support: README.md#Support + title: LoadRunner Professional +--- + + + + +## 개요 + +OpenText LoadRunner Professional은 다양한 애플리케이션의 성능을 테스트하여, 서비스 출시 전에 문제를 식별하고 해결할 수 있도록 지원하는 부하 테스트 솔루션입니다. + +LoadRunner Controller는 LoadRunner Professional 시나리오를 생성하고 관리하는 도구입니다. 시나리오는 각 테스트 세션 동안 발생하는 이벤트를 정의합니다. 에뮬레이션할 사용자 수(가상 사용자 또는 Vuser), 사용자가 하는 작업, 그리고 에뮬레이션을 실행하는 컴퓨터를 제어합니다. 시나리오를 사용하여 부하 테스트를 생성하고 서버의 안정성과 성능을 확인할 수 있습니다. + +이러한 통합을 통해 Controller는 시나리오 실행에서 얻은 실시간 메트릭과 데이터를 Datadog으로 푸시합니다. + +| | | +|---|---| +|__Send scenario information__| 시작 및 종료 시간, 기간, 포함된 스크립트 등 시나리오 실행에 관한 정보를 로그 형태로 보냅니다. +|__Send run metrics__| Vuser 상태 및 트랜잭션 응답 시간과 같은 시나리오 실행에 관한 메트릭을 보냅니다. | + +## 설정 + +Datadog에 데이터를 푸시하도록 LoadRunner Controller를 구성합니다. 시나리오 정보, 실행 메트릭, 또는 둘 다 전송할지 선택할 수 있습니다. 이 통합을 구성하면 미리 구성된 위젯에서 데이터를 확인할 수 있는 Datadog 대시보드가 제공됩니다. + +1. Controller를 엽니다. +2. Controller 도구 모음에서 __Tools > Datadog Configuration__을 선택합니다. +3. __Site__ 필드에서 해당 [Datadog 사이트][1]를 선택합니다. +4. __API key__ 필드에 Datadog이 생성한 [API 키][2]를 입력합니다. +5. __Test Connection__을 클릭합니다. +6. 연결이 성공하면, Datadog으로 시나리오 정보, 실행 메트릭, 또는 둘 모두를 전송할지 선택합니다. +7. Controller가 시나리오 정보를 전송하도록 설정하면, 이 통합에 포함된 로그 파이프라인이 자동으로 로그를 처리하고 관련 태그를 추가합니다. 파이프라인에 관한 자세한 내용은 Logs > Pipelines in Datadog에서 확인하세요. +8. Datadog에서는 __LoadRunner Professional Dashboard__가 통합과 함께 자동으로 설치됩니다. 이 대시보드에는 실행 메트릭과 시나리오 정보(Controller가 전송하도록 구성된 데이터에 따라 다름)를 표시하는 위젯이 포함되어 있습니다. + +Controller가 Datadog에 데이터를 푸시하도록 구성되면 Controller에서 시나리오를 실행할 때마다 데이터가 푸시됩니다. Controller가 Datadog에 데이터를 푸시하는 것을 비활성화하려면 __Tools > Datadog Configuration__을 선택하고 Datadog Configuration 대화 상자에서 해당 필드를 삭제하세요. + +![Datadog 구성 창][3] + +## 수집한 데이터 + +### 메트릭 +{{< get-metrics-from-git "loadrunner_professional" >}} + + +### 서비스 점검 + +LoadRunner Professional은 서비스 점검을 포함하지 않습니다. + +### 이벤트 + +LoadRunner Professional은 이벤트를 포함하지 않습니다. + +## 트러블슈팅 + +도움이 필요하신가요? [LoadRunner Professional 문서][5]를 참고하거나 [Datadog 지원팀][6]에 문의하세요. + + +[1]: https://docs.datadoghq.com/ko/getting_started/site/ +[2]: https://docs.datadoghq.com/ko/account_management/api-app-keys/#add-an-api-key-or-client-token +[3]: https://raw.githubusercontent.com/DataDog/integrations-extras/master/loadrunner_professional/images/datadog_configuration_window.png +[4]: https://github.com/DataDog/integrations-extras/blob/master/loadrunner_professional/metadata.csv +[5]: https://admhelp.microfocus.com/lr +[6]: https://docs.datadoghq.com/ko/help/ \ No newline at end of file diff --git a/content/ko/integrations/oracle_timesten.md b/content/ko/integrations/oracle_timesten.md new file mode 100644 index 0000000000000..02099c6e5a28c --- /dev/null +++ b/content/ko/integrations/oracle_timesten.md @@ -0,0 +1,117 @@ +--- +algolia: + subcategory: Marketplace 통합 +app_id: rapdev-oracle-timesten +app_uuid: bddd0f6a-efe0-4e3f-bff4-46df8bb839f9 +assets: + dashboards: + Oracle TimesTen: assets/dashboards/oracle_timesten.json + integration: + auto_install: false + configuration: {} + events: + creates_events: false + metrics: + check: rapdev.oracle_timesten.reportduration + metadata_path: metadata.csv + prefix: rapdev.oracle_timesten. + service_checks: + metadata_path: assets/service_checks.json + source_type_id: 10116 + source_type_name: Oracle TimesTen +author: + homepage: https://www.rapdev.io + name: RapDev + sales_email: ddsales@rapdev.io + support_email: support@rapdev.io + vendor_id: rapdev +categories: +- 캐싱(caching) +- 데이터 스토어 +- marketplace +- oracle +custom_kind: integration +dependencies: [] +display_on_public_website: true +draft: false +git_integration_title: oracle_timesten +integration_id: rapdev-oracle-timesten +integration_title: Oracle TimesTen +integration_version: '' +is_public: true +legal_terms: + eula: assets/EULA.pdf +manifest_version: 2.0.0 +name: oracle_timesten +pricing: +- billing_type: tag_count + includes_assets: true + metric: datadog.marketplace.rapdev.oracle_timesten + product_id: oracle-timesten + short_description: 호스트별 유닛 비용 + tag: 호스트 + unit_label: Oracle Times Ten 데이터베이스 + unit_price: 500 +public_title: Oracle TimesTen +short_description: Oracle TimesTen 데이터베이스 성능 모니터링 +supported_os: +- 리눅스 +tile: + changelog: CHANGELOG.md + classifier_tags: + - 카테고리::캐싱(Caching) + - 카테고리::데이터 저장 + - Category::Marketplace + - Category::Oracle + - Offering::Integration + - Supported OS::Linux + - 제출한 데이터 유형::메트릭 + configuration: README.md#Setup + description: Oracle TimesTen 데이터베이스 성능 모니터링 + media: + - caption: Oracle TimesTen Datadog 통합 + image_url: images/video.png + media_type: 비디오 + vimeo_id: 630489692 + - caption: 상태 개요 + image_url: images/1.png + media_type: image + - caption: 복제 메트릭 + image_url: images/2.png + media_type: image + - caption: SQL 통계 + image_url: images/3.png + media_type: image + - caption: 대시보드 개요 + image_url: images/4.png + media_type: image + overview: README.md#Overview + support: README.md#Support + title: Oracle TimesTen + uninstallation: README.md#Uninstallation +--- + + + + +## 개요 + +Oracle TimesTen 통합으로 TimesTen 인메모리 데이터베이스를 모니터링할 수 있습니다. 본 통합은 200개 이상의 메트릭을 다루며 상위 쿼리, 데이터베이스 상태, 실행 시간 등에 대한 세부 정보를 제공합니다. + +본 통합에는 TimesTen 데이터베이스의 상태 개요 및 메트릭을 표시하는 기본 제공 대시보드가 포함되어 있습니다. + +## 지원 + +지원 또는 기능 요청은 다음 채널을 통해 RapDev.io에 문의해 주세요. + + - 이메일: support@rapdev.io + - 채팅: [rapdev.io](https://www.rapdev.io/#Get-in-touch) + - 전화: 855-857-0222 + +--- +Made with ❤️ in Boston + +*원하는 통합을 찾을 수 없나요? 조직에 필요한 중요한 기능이 누락되었나요? [요청 사항](mailto:support@rapdev.io)을 보내주시면 반영하도록 하겠습니다.* + +--- +이 애플리케이션은 Datadog Marketplace를 통해 제공되며 Datadog 기술 파트너의 지원을 받습니다. 사용하려면 Marketplace에서 구매하세요. \ No newline at end of file diff --git a/content/ko/integrations/rapdev_zoom.md b/content/ko/integrations/rapdev_zoom.md index 6662ef1442835..ba1c900135fba 100644 --- a/content/ko/integrations/rapdev_zoom.md +++ b/content/ko/integrations/rapdev_zoom.md @@ -67,7 +67,7 @@ short_description: Zoom 계정 모니터링 및 라이선스 최적화 supported_os: - linux - macos -- windows +- 윈도우즈(Windows) tile: changelog: CHANGELOG.md classifier_tags: @@ -125,9 +125,9 @@ Zoom 통합은 미팅, 룸, 사용자, 네트워크 통계 및 지리적 위치 6. RapDev Zoom Phones 개요 ## 지원 -지원 또는 기능 요청은 다음 채널을 통해 RapDev.io에 문의하세요. +지원 또는 기능 요청은 다음 채널을 통해 RapDev.io에 문의해 주세요. -- 지원: support@rapdev.io +- 지원 팀: support@rapdev.io - 영업 팀: sales@rapdev.io - 채팅: [rapdev.io](https://www.rapdev.io/#Get-in-touch) - 전화: 855-857-0222 diff --git a/content/ko/integrations/redpanda.md b/content/ko/integrations/redpanda.md index 68a50c96e2848..48104bb8baf0e 100644 --- a/content/ko/integrations/redpanda.md +++ b/content/ko/integrations/redpanda.md @@ -27,7 +27,7 @@ author: support_email: support@redpanda.com categories: - 로그 수집 -- 메시지 큐 +- 메시지 대기열 custom_kind: 통합 dependencies: - https://github.com/DataDog/integrations-extras/blob/master/redpanda/README.md @@ -44,7 +44,7 @@ public_title: Redpanda short_description: Redpanda 클러스터의 전반적인 서비스 상태 및 성능을 모니터링하세요. supported_os: - linux -- windows +- 윈도우즈(Windows) - macos tile: changelog: CHANGELOG.md @@ -88,7 +88,7 @@ Datadog을 [Redpanda][1]와 연결하여 키 메트릭를 확인하고 특정 {{% /tab %}} {{% tab "Containerized" %}} -#### 컨테이너화 +#### 컨테이너화된 환경 컨테이너화된 환경의 경우 도커(Docker) 에이전트로 본 통합을 사용하는 가장 좋은 방법은 Redpanda 통합이 설치된 에이전트를 빌드하는 것입니다. @@ -138,7 +138,7 @@ Redpanda 성능 데이터 수집을 시작하려면, 1. [에이전트 설정 디렉토리][1] 루트에 있는 `conf.d/` 폴더에서 `redpanda.d/conf.yaml` 파일을 편집하세요. 사용 가능한 모든 설정 옵션은 [redpanda.d/conf.yaml.example][2] 샘플을 참조하세요. -2. [에이전트를 재시작][3]하세요. +2. [에이전트를 다시 시작합니다][3]. ##### 로그 수집 @@ -169,7 +169,7 @@ Datadog 에이전트에서 로그 수집은 기본적으로 비활성화되어 {{% /tab %}} {{% tab "Containerized" %}} -#### 컨테이너화 +#### 컨테이너화된 환경 ##### 메트릭 수집 diff --git a/content/ko/integrations/reporter.md b/content/ko/integrations/reporter.md index 0b2a2b412dfd5..696d9b2af2f16 100644 --- a/content/ko/integrations/reporter.md +++ b/content/ko/integrations/reporter.md @@ -50,7 +50,7 @@ public_title: 리포터 short_description: 모든 Datadog 대시보드에서 이메일 리포트 생성하기 supported_os: - linux -- windows +- 윈도우즈(Windows) tile: changelog: CHANGELOG.md classifier_tags: diff --git a/content/ko/integrations/rigor.md b/content/ko/integrations/rigor.md index 4f9714c68e07c..7a1ad990a83a2 100644 --- a/content/ko/integrations/rigor.md +++ b/content/ko/integrations/rigor.md @@ -21,8 +21,8 @@ author: sales_email: support@rigor.com support_email: support@rigor.com categories: -- 테스팅 -custom_kind: integration +- 테스트 +custom_kind: 통합 dependencies: - https://github.com/DataDog/integrations-extras/blob/master/rigor/README.md display_on_public_website: true @@ -37,8 +37,8 @@ name: rigor public_title: Rigor short_description: Rigor는 개발 라이프 사이클 동안 신서틱(Synthetic) 모니터링 및 최적화를 제공합니다. supported_os: -- 리눅스 -- windows +- linux +- 윈도우즈(Windows) - macos tile: changelog: CHANGELOG.md @@ -47,7 +47,7 @@ tile: - Supported OS::Windows - Category::Testing - Supported OS::macOS - - 제공::통합 + - Offering::Integration configuration: README.md#Setup description: Rigor는 개발 라이프 사이클 동안 신서틱(Synthetic) 모니터링 및 최적화를 제공합니다. media: [] @@ -69,7 +69,7 @@ Rigor를 사용하면 신서틱, 프런트엔드 성능 메트릭을 수집하 Rigor는 Datadog를 통해 두 개의 서로 다른 통합을 제공합니다. 메트릭 통합과 이벤트 통합입니다. -### 구성 +### 설정 #### 메트릭 수집 관리자로 화면 오른쪽 상단에서 "관리 도구" 메뉴를 클릭한 다음 "통합"을 선택합니다. diff --git a/content/ko/integrations/rum_android.md b/content/ko/integrations/rum_android.md new file mode 100644 index 0000000000000..e4be3cdb1ba9e --- /dev/null +++ b/content/ko/integrations/rum_android.md @@ -0,0 +1,122 @@ +--- +app_id: rum-android +app_uuid: a70b6926-49a8-4f90-8190-315170e97e4f +assets: {} +author: + homepage: https://www.datadoghq.com + name: Datadog + sales_email: info@datadoghq.com + support_email: help@datadoghq.com +categories: +- log collection +- metrics +- mobile +- network +- tracing +custom_kind: integration +dependencies: +- https://github.com/DataDog/integrations-extras/blob/master/rum_android/README.md +display_on_public_website: true +draft: false +git_integration_title: rum_android +integration_id: rum-android +integration_title: 안드로이드 +integration_version: '' +is_public: true +manifest_version: 2.0.0 +name: rum_android +public_title: 안드로이드 +short_description: Datadog RUM으로 Android 애플리케이션 모니터링 및 메트릭 생성 +supported_os: +- android +tile: + changelog: CHANGELOG.md + classifier_tags: + - Category::Log Collection + - 카테고리::메트릭 + - Category::Mobile + - Category::Network + - Category::Tracing + - Supported OS::Android + - 제공::통합 + configuration: README.md#Setup + description: Datadog RUM으로 Android 애플리케이션 모니터링 및 메트릭 생성 + media: [] + overview: README.md#Overview + resources: + - resource_type: 설명서 + url: https://docs.datadoghq.com/real_user_monitoring/android/ + support: README.md#Support + title: 안드로이드 +--- + + + + +## 개요 + +Datadog [Android 통합]을 사용하면 다음과 같은 방식으로 문제 해결 시간을 줄이고, 새로운 기능 개발에 더 집중할 수 있습니다. + +- 타사 라이브러리, 네트워크 요청, 대용량 미디어 파일에서 발생하는 느린 성능 문제 및 애플리케이션 충돌에 대한 원인 디버깅 +- 애플리케이션 반응 속도 개선, 서비스 수준 지표(SLI) 설정, 기본 제공 대시보드, 실시간 메트릭, 난독화된 충돌 보고서를 통한 문제 진단 +- 대량의 애플리케이션 오류를 정교하게 분류하여 관리 가능한 고유 이슈 집합으로 그룹화 + +사용자 경험이 비즈니스에 미치는 영향을 다음과 같은 방식으로 파악할 수 있습니다. + +- 인구통계, 버전 릴리스, 사용자 정의 속성별 화면 참여도 같은 핵심 모바일 사용자 경험 데이터를 분석하여 비즈니스 KPI에 도달 +- ID, 셀룰러 활동, 추천 URL 등을 포함한 세션 이벤트 및 속성의 타임라인과 모든 사용자 여정을 자동으로 연결 +- 맞춤형 분석 및 지리적 지도를 통해 사용자 행동 트렌드 파악 + +다음을 통해 애플리케이션의 엔드투엔드 상태를 모니터링합니다. + +- 이슈 조사 시 사용자 경험 데이터를 백엔드 트레이스, 런타임 메트릭, 로그로 전환하여 전체 컨텍스트 파악 +- 클라이언트 측과 서버 측 메트릭, 트레이스, 로그를 통합하여 충돌 디버깅을 더 빠르게 수행 +- 프런트엔드 및 백엔드 팀을 위한 단일 플랫폼에서 풀스택 모니터링 통합 + +## 설정 + +### RUM 이벤트 수집 + +애플리케이션에서 Real User Monitoring 이벤트 수집을 시작하려면 [Android 및 Android TV 모니터링][2]을 참고하세요. + +### 트레이스 수집 + +Android 애플리케이션의 트레이스를 Datadog으로 전송하려면 [Android 트레이스 수집][3]을 참고하세요. 또한 [RUM과 트레이스를 연결할 수도 있습니다][4]. + +### 로그 수집 + +Android 애플리케이션 로그를 Datadog으로 전달하려면 [Android 로그 수집][5]을 참고하세요. + +## 수집한 데이터 + +### 메트릭 + +Android 통합은 메트릭을 포함하지 않습니다. RUM 애플리케이션에서 커스텀 메트릭을 생성하려면 [메트릭 생성][6]을 참고하세요. + +### 이벤트 + +이벤트 및 속성에 관한 자세한 내용은 [수집된 RUM Android 데이터][7]를 참고하세요. + +### 서비스 점검 + +Android 통합은 서비스 점검을 포함하지 않습니다. + +## 트러블슈팅 + +도움이 필요하신가요? [Datadog 지원팀][8]에 문의하세요. + +## 참고 자료 + +기타 유용한 문서, 링크 및 기사: + +- [Android 및 Android TV 모니터링][9] + +[1]: https://app.datadoghq.com/integrations/rum-android +[2]: https://docs.datadoghq.com/ko/real_user_monitoring/android/?tabs=kotlin#setup +[3]: https://docs.datadoghq.com/ko/tracing/trace_collection/dd_libraries/android +[4]: https://docs.datadoghq.com/ko/real_user_monitoring/connect_rum_and_traces/?tab=androidrum#setup-rum +[5]: https://docs.datadoghq.com/ko/logs/log_collection/android/?tab=kotlin +[6]: https://docs.datadoghq.com/ko/real_user_monitoring/generate_metrics +[7]: https://docs.datadoghq.com/ko/real_user_monitoring/android/data_collected/ +[8]: https://docs.datadoghq.com/ko/help/ +[9]: https://docs.datadoghq.com/ko/real_user_monitoring/android/ \ No newline at end of file diff --git a/content/ko/integrations/rum_cypress.md b/content/ko/integrations/rum_cypress.md new file mode 100644 index 0000000000000..55def36ba8f4e --- /dev/null +++ b/content/ko/integrations/rum_cypress.md @@ -0,0 +1,103 @@ +--- +app_id: rum-cypress +app_uuid: a6c112b6-f3af-4f9e-bf25-e0f8d8d7bb5f +assets: {} +author: + homepage: https://www.datadoghq.com + name: Datadog + sales_email: info@datadoghq.com + support_email: help@datadoghq.com +categories: +- 문제 추적 +- 메트릭 +- 네트워크 +- 테스팅 +- 추적 +custom_kind: integration +dependencies: +- https://github.com/DataDog/integrations-extras/blob/master/rum_cypress/README.md +display_on_public_website: true +draft: false +git_integration_title: rum_cypress +integration_id: rum-cypress +integration_title: Cypress +integration_version: '' +is_public: true +manifest_version: 2.0.0 +name: rum_cypress +public_title: Cypress +short_description: Datadog으로 애플리케이션의 Cypress 테스트 실행 모니터링 +supported_os: +- 모두 +tile: + changelog: CHANGELOG.md + classifier_tags: + - 카테고리::이슈 추적 + - 카테고리::메트릭 + - Category::Network + - Category::Testing + - Category::Tracing + - Supported OS::Any + - 제공::통합 + configuration: README.md#Setup + description: Datadog으로 애플리케이션의 Cypress 테스트 실행 모니터링 + media: [] + overview: README.md#Overview + support: README.md#Support + title: Cypress +--- + + + + +## 개요 + +Datadog [Cypress 통합][1]을 사용하면 다음의 방식으로 파이프라인에서 실행되는 CI/CD 파이프라인과 Cypress 테스트의 성능을 모니터링할 수 있습니다. + +- 불안정하거나 실패하는 테스트를 조사하고, 실패한 단계에 집중하여 문제를 정확히 파악 +- 분산 추적 정보가 포함된 테스트 결과를 확인하고 Cypress 테스트가 느린 이유 분석 +- RUM 및 Session Replay에서 수집된 데이터를 사용하여 엔드투엔드 Cypress 테스트의 성능 격차 문제 해결 +- 실제 사용자 세션을 모니터링하고 캡처하여 시각적으로 재생 + + +## 설정 + +Cypress 테스트를 RUM 및 Session Replay과 통합하는 방법은 [CI Visibility-RUM 통합 문서][2]를 참고하세요. + + +### RUM 이벤트 수집 + +애플리케이션에서 Real User Monitoring 이벤트 수집을 시작하려면 [Cypress 모니터링][3]을 참고하세요. + +### 트레이스 수집 + +해당 애플리케이션은 자동으로 Datadog에 트레이스를 보냅니다. + +## 수집한 데이터 + +### 메트릭 + +CI Visibility-RUM 통합은 메트릭을 포함하지 않습니다. RUM 애플리케이션에서 커스텀 메트릭을 생성하려면 [메트릭 생성][4]을 참고하세요. + +### 서비스 점검 + +Cypress 통합은 서비스 점검을 포함하지 않습니다. + +## 트러블슈팅 + +도움이 필요하신가요? [Datadog 지원팀][5]에 문의하세요. + +## 참고 자료 + +참고할 만한 유용한 문서, 링크, 게시물: + +- [CI Visibility][6] + + + +[1]: https://app.datadoghq.com/integrations/rum-cypress +[2]: https://docs.datadoghq.com/ko/continuous_integration/guides/rum_integration/ +[3]: https://docs.datadoghq.com/ko/continuous_integration/guides/rum_integration/#browser-tests-and-rum +[4]: https://docs.datadoghq.com/ko/real_user_monitoring/generate_metrics +[5]: https://docs.datadoghq.com/ko/help/ +[6]: https://docs.datadoghq.com/ko/continuous_integration/ \ No newline at end of file diff --git a/content/ko/integrations/rum_flutter.md b/content/ko/integrations/rum_flutter.md new file mode 100644 index 0000000000000..cc6988f54b837 --- /dev/null +++ b/content/ko/integrations/rum_flutter.md @@ -0,0 +1,121 @@ +--- +app_id: rum-flutter +app_uuid: a7344e0c-5fcf-43c0-af3b-734b484c1f29 +assets: {} +author: + homepage: https://www.datadoghq.com + name: Datadog + sales_email: info@datadoghq.com + support_email: help@datadoghq.com +categories: +- log collection +- metrics +- mobile +- network +- tracing +custom_kind: integration +dependencies: +- https://github.com/DataDog/integrations-extras/blob/master/rum_flutter/README.md +display_on_public_website: true +draft: false +git_integration_title: rum_flutter +integration_id: rum-flutter +integration_title: Flutter +integration_version: '' +is_public: true +manifest_version: 2.0.0 +name: rum_flutter +public_title: Flutter +short_description: Datadog RUM으로 Flutter 애플리케이션 모니터링 및 메트릭 생성 +supported_os: +- android +- ios +tile: + changelog: CHANGELOG.md + classifier_tags: + - Category::Log Collection + - 카테고리::메트릭 + - Category::Mobile + - Category::Network + - Category::Tracing + - Supported OS::Android + - Supported OS::iOS + - 제공::통합 + configuration: README.md#Setup + description: Datadog RUM으로 Flutter 애플리케이션 모니터링 및 메트릭 생성 + media: [] + overview: README.md#Overview + support: README.md#Support + title: Flutter +--- + + + + +## 개요 + +Datadog [Flutter 통합][1]을 사용하면 다음과 같은 방식으로 문제 해결 시간을 줄이고, 새로운 기능 개발에 더 집중할 수 있습니다. + +- 타사 라이브러리, 네트워크 요청, 대용량 미디어 파일에서 발생하는 느린 성능 문제 및 애플리케이션 충돌에 관한 원인 디버깅 +- 애플리케이션 반응 속도 개선, 서비스 수준 지표(SLI) 설정, 기본 제공 대시보드, 실시간 메트릭, 난독화된 충돌 보고서를 통한 문제 진단 +- 대량의 애플리케이션 오류를 정교하게 분류하여 관리 가능한 고유 이슈 집합으로 그룹화 + +사용자 경험이 비즈니스에 미치는 영향을 다음과 같은 방식으로 연결할 수 있습니다. + +- 인구통계, 버전 릴리스, 사용자 정의 속성별 화면 참여도 같은 핵심 모바일 사용자 경험 데이터를 분석하여 비즈니스 KPI 달성 +- ID, 셀룰러 활동, 추천 URL 등을 포함한 세션 이벤트 및 속성의 타임라인과 모든 사용자 여정을 자동으로 연결 +- 맞춤형 분석 및 지리적 지도를 통해 사용자 행동 트렌드 파악 + +Flutter 애플리케이션의 엔드투엔드 상태를 다음과 같이 모니터링합니다. + +- 이슈 조사 시 사용자 경험 데이터를 백엔드 트레이스, 런타임 메트릭, 로그로 전환하여 전체 컨텍스트 파악 +- 클라이언트 측과 서버 측 메트릭, 트레이스, 로그를 통합하여 충돌 디버깅을 더 빠르게 수행 +- 프런트엔드 및 백엔드 팀을 위한 단일 플랫폼에서 풀스택 모니터링 통합 + + +## 설정 + +### RUM 이벤트 수집 + +애플리케이션에서 Real User Monitoring 이벤트 수집을 시작하려면 [Flutter 모니터링][2]을 참고하세요. + +### 트레이스 수집 + +Flutter 애플리케이션은 자동으로 Datadog에 트레이스를 보냅니다. + +### 로그 수집 + +Flutter 애플리케이션 로그를 Datadog으로 전달하려면 [Flutter 로그 수집][3]을 참고하세요. + +## 수집한 데이터 + +### 메트릭 + +Flutter 통합은 메트릭을 포함하지 않습니다. RUM 애플리케이션에서 커스텀 메트릭을 생성하려면 [메트릭 생성][4]을 참고하세요. + +### 이벤트 + +이벤트 및 속성에 관한 자세한 내용은 [RUM Flutter 모니터링][5]을 참고하세요. + +### 서비스 점검 + +Flutter 통합은 서비스 점검을 포함하지 않습니다. + +## 트러블슈팅 + +도움이 필요하신가요? [Datadog 지원팀][6]에 문의하세요. + +## 참고 자료 + +참고할 만한 유용한 문서, 링크, 게시물: + +- [Flutter 모니터링][5] + + + +[1]: https://app.datadoghq.com/integrations/rum-flutter +[2]: https://docs.datadoghq.com/ko/real_user_monitoring/flutter/#setup +[3]: https://docs.datadoghq.com/ko/logs/log_collection/flutter/ +[4]: https://docs.datadoghq.com/ko/real_user_monitoring/generate_metrics +[5]: https://docs.datadoghq.com/ko/real_user_monitoring/flutter/ +[6]: https://docs.datadoghq.com/ko/help/ \ No newline at end of file diff --git a/content/ko/integrations/rum_react_native.md b/content/ko/integrations/rum_react_native.md new file mode 100644 index 0000000000000..f0c6ad98f3d4b --- /dev/null +++ b/content/ko/integrations/rum_react_native.md @@ -0,0 +1,118 @@ +--- +app_id: rum-react-native +app_uuid: 61207de8-cc1e-4915-a18a-7fb25093d85c +assets: {} +author: + homepage: https://www.datadoghq.com + name: Datadog + sales_email: info@datadoghq.com + support_email: help@datadoghq.com +categories: +- log collection +- metrics +- mobile +- network +- tracing +custom_kind: integration +dependencies: +- https://github.com/DataDog/integrations-extras/blob/master/rum_react_native/README.md +display_on_public_website: true +draft: false +git_integration_title: rum_react_native +integration_id: rum-react-native +integration_title: 리액트 네이티브 +integration_version: '' +is_public: true +manifest_version: 2.0.0 +name: rum_react_native +public_title: 리액트 네이티브 +short_description: Datadog RUM으로 React Native 애플리케이션 모니터링 및 메트릭 생성 +supported_os: +- android +- ios +tile: + changelog: CHANGELOG.md + classifier_tags: + - Category::Log Collection + - 카테고리::메트릭 + - Category::Mobile + - Category::Network + - Category::Tracing + - Supported OS::Android + - Supported OS::iOS + - 제공::통합 + configuration: README.md#Setup + description: Datadog RUM으로 React Native 애플리케이션 모니터링 및 메트릭 생성 + media: [] + overview: README.md#Overview + support: README.md#Support + title: 리액트 네이티브 +--- + + + + +## 개요 + +Datadog [React Native 통합][1]을 사용하면 다음과 같은 방식으로 문제 해결 시간을 줄이고, 새로운 기능 개발에 더 집중할 수 있습니다. + +- 타사 라이브러리, 네트워크 요청, 대용량 미디어 파일에서 발생하는 느린 성능 문제 및 애플리케이션 충돌에 대한 원인 디버깅 +- 애플리케이션 반응 속도 개선, 서비스 수준 지표(SLI) 설정, 기본 제공 대시보드, 실시간 메트릭, 난독화된 충돌 보고서를 통한 문제 진단 +- 대량의 애플리케이션 오류를 정교하게 분류하여 관리 가능한 고유 이슈 집합으로 그룹화 + +사용자 경험이 비즈니스에 미치는 영향을 다음과 같은 방식으로 연결할 수 있습니다. + +- 인구통계, 버전 릴리스, 사용자 정의 속성별 화면 참여도 같은 핵심 모바일 사용자 경험 데이터를 분석하여 비즈니스 KPI 달성 +- ID, 셀룰러 활동, 추천 URL 등을 포함한 세션 이벤트 및 속성의 타임라인과 모든 사용자 여정을 자동으로 연결 +- 맞춤형 분석 및 지리적 지도를 통해 사용자 행동 트렌드 파악 + +React Native 애플리케이션의 엔드투엔드 상태를 다음과 같이 모니터링합니다. + +- 이슈 조사 시 사용자 경험 데이터를 백엔드 트레이스, 런타임 메트릭, 로그로 전환하여 전체 컨텍스트 파악 +- 클라이언트 측과 서버 측 메트릭, 트레이스, 로그를 통합하여 충돌 디버깅을 더 빠르게 수행 +- 프런트엔드 및 백엔드 팀을 위한 단일 플랫폼에서 풀스택 모니터링 통합 + +## 설정 + +### RUM 이벤트 수집 + +애플리케이션에서 Real User Monitoring 이벤트 수집을 시작하려면 [React Native 모니터링][2]을 참고하세요. + +### 트레이스 수집 + +React Native 애플리케이션은 자동으로 Datadog에 트레이스를 보냅니다. + +### 로그 수집 + +React Native 애플리케이션 로그를 Datadog으로 전달하려면 [React Native 로그 수집][3]을 참고하세요. + +## 수집한 데이터 + +### 메트릭 + +React Native 통합은 메트릭을 포함하지 않습니다. RUM 애플리케이션에서 커스텀 메트릭을 생성하려면 [메트릭 생성][4]을 참고하세요. + +### 이벤트 + +이벤트 및 속성에 대한 자세한 내용은 [RUM React Native 모니터링][5]을 참고하세요. + +### 서비스 점검 + +React Native 통합은 서비스 점검을 포함하지 않습니다. + +## 트러블슈팅 + +도움이 필요하신가요? [Datadog 지원팀][6]에 문의하세요. + +## 참고 자료 + +기타 유용한 문서, 링크 및 기사: + +- [React Native 모니터링][5] + +[1]: https://app.datadoghq.com/integrations/rum-react-native +[2]: https://docs.datadoghq.com/ko/real_user_monitoring/reactnative/#setup +[3]: https://docs.datadoghq.com/ko/real_user_monitoring/reactnative/#manual-instrumentation +[4]: https://docs.datadoghq.com/ko/real_user_monitoring/generate_metrics +[5]: https://docs.datadoghq.com/ko/real_user_monitoring/reactnative/ +[6]: https://docs.datadoghq.com/ko/help/ \ No newline at end of file diff --git a/content/ko/integrations/sap_hana.md b/content/ko/integrations/sap_hana.md index 86f9e7a442435..7d4f377cd5319 100644 --- a/content/ko/integrations/sap_hana.md +++ b/content/ko/integrations/sap_hana.md @@ -24,9 +24,9 @@ author: sales_email: info@datadoghq.com support_email: help@datadoghq.com categories: -- 데이터 스토어 +- 데이터 저장소 - sap -custom_kind: integration +custom_kind: 통합 dependencies: - https://github.com/DataDog/integrations-core/blob/master/sap_hana/README.md display_on_public_website: true @@ -41,18 +41,18 @@ name: sap_hana public_title: SAP HANA short_description: SAP HANA 시스템에서 메모리, 네트워크, 볼륨 및 기타 메트릭을 모니터링하세요. supported_os: -- 리눅스 -- windows +- linux +- 윈도우즈(Windows) - macos tile: changelog: CHANGELOG.md classifier_tags: - - 카테고리::데이터 저장 + - Category::Data Stores - Category::SAP - Supported OS::Linux - Supported OS::Windows - Supported OS::macOS - - 제공::통합 + - Offering::Integration configuration: README.md#Setup description: SAP HANA 시스템에서 메모리, 네트워크, 볼륨 및 기타 메트릭을 모니터링하세요. media: [] @@ -149,11 +149,11 @@ HANA 테넌트, 단일 테넌트 및 시스템 데이터베이스의 포트 번 GRANT DD_MONITOR TO ; ``` -### 구성 +### 설정 1. 에이전트 설정 디렉터리 루트의 `conf.d/` 폴더에 있는 `sap_hana.d/conf.yaml` 파일을 편집하여 sap_hana 성능 데이터 수집을 시작합니다. 사용 가능한 모든 설정 옵션은 [샘플 sap_hana.d/conf.yaml][5]을 참조하세요. -2. [Agent를 재시작합니다][6]. +2. [에이전트를 재시작합니다][6]. #### 로그 수집 @@ -181,7 +181,7 @@ HANA 테넌트, 단일 테넌트 및 시스템 데이터베이스의 포트 번 사용 가능한 모든 설정 옵션은 [샘플 sap_hana.d/conf.yaml][5]을 참조하세요. -3. [에이전트를 재시작하세요][6]. +3. [에이전트를 재시작합니다][6]. ### 검증 @@ -190,7 +190,7 @@ HANA 테넌트, 단일 테넌트 및 시스템 데이터베이스의 포트 번 ## 수집한 데이터 ### 메트릭 -{{< get-metrics-from-git "sap-hana" >}} +{{< get-metrics-from-git "sap_hana" >}} ### 이벤트 @@ -198,7 +198,7 @@ HANA 테넌트, 단일 테넌트 및 시스템 데이터베이스의 포트 번 SAP HANA에는 이벤트가 포함되어 있지 않습니다. ### 서비스 점검 -{{< get-service-checks-from-git "sap-hana" >}} +{{< get-service-checks-from-git "sap_hana" >}} ## 트러블슈팅 diff --git a/content/ko/integrations/tcp_queue_length.md b/content/ko/integrations/tcp_queue_length.md new file mode 100644 index 0000000000000..a26c8e606665a --- /dev/null +++ b/content/ko/integrations/tcp_queue_length.md @@ -0,0 +1,164 @@ +--- +app_id: tcp-queue-length +app_uuid: 2c48a360-9fbb-4cd6-9316-0e9afd9926c8 +assets: + integration: + auto_install: true + configuration: {} + events: + creates_events: false + metrics: + check: tcp_queue.read_buffer_max_usage_pct + metadata_path: metadata.csv + prefix: tcp_queue. + service_checks: + metadata_path: assets/service_checks.json + source_type_id: 10295 + source_type_name: TCP Queue Length +author: + homepage: https://www.datadoghq.com + name: Datadog + sales_email: info@datadoghq.com + support_email: help@datadoghq.com +categories: +- 개발 툴 +- 네트워크 +custom_kind: integration +dependencies: +- https://github.com/DataDog/integrations-core/blob/master/tcp_queue_length/README.md +display_on_public_website: true +draft: false +git_integration_title: tcp_queue_length +integration_id: tcp-queue-length +integration_title: TCP Queue Length +integration_version: '' +is_public: true +manifest_version: 2.0.0 +name: tcp_queue_length +public_title: TCP Queue Length +short_description: Datadog으로 TCP 버퍼 크기를 추적합니다. +supported_os: +- 리눅스 +tile: + changelog: CHANGELOG.md + classifier_tags: + - Category::Developer Tools + - Category::Network + - Supported OS::Linux + - 제공::통합 + configuration: README.md#Setup + description: Datadog으로 TCP 버퍼 크기를 추적합니다. + media: [] + overview: README.md#Overview + support: README.md#Support + title: TCP Queue Length +--- + + + + +## 개요 + +해당 검사는 Linux의 TCP 수신 및 전송 대기열 사용량을 모니터링합니다. 개별 컨테이너의 TCP 수신 또는 전송 대기열이 꽉 찼는지 감지할 수 있습니다. + +## 설정 + +### 설치 + +`tcp_queue_length`는 `system-probe`에 구현된 eBPF 구성 요소에 의존하는 핵심 Agent 6/7 점검입니다. Agent 버전 7.24.1/6.24.1 이상이 필요합니다. + +`system-probe`에서 사용하는 eBPF 프로그램은 런타임에 컴파일되며 적절한 커널 헤더에 액세스할 수 있어야 합니다. + +데비안(Debian) 유사 배포에서 다음과 같이 커널 헤더를 설치합니다. +```sh +apt install -y linux-headers-$(uname -r) +``` + +RHEL 유사 배포에서 다음으로 커널 헤더를 설치합니다. +```sh +yum install -y kernel-headers-$(uname -r) +yum install -y kernel-devel-$(uname -r) +``` + +**참고**: Windows 및 CentOS/RHEL 8 이전 버전은 지원하지 않습니다. + +### 구성 + +`tcp_queue_length` 통합을 활성화하려면 `system-probe` 및 코어 Agent 모두 구성 옵션이 활성화되어 있어야 합니다. + +`system-probe.yaml` 구성 파일 내에서 다음 매개변수를 설정합니다. +```yaml +system_probe_config: + enable_tcp_queue_length: true +``` + +1. 다음 루트의 `conf.d/` 폴더에 있는 `tcp_queue_length.d/conf.yaml` 파일을 편집합니다. + Agent의 설정 디렉터리에서 tcp_queue_length 성능 데이터 수집을 시작합니다. + 사용 가능한 모든 구성 옵션은 [tcp_queue_length.d/conf.yaml 샘플][1]을 참조하세요. + +2. [Agent를 재시작합니다][2]. + + +### Helm으로 설정하기 + +[Datadog Helm 차트][3]의 경우, `values.yaml` 파일에서 `datadog.systemProbe.enabled`를 `true`로 설정하여 `system-probe`를 활성화합니다. +그런 다음 `datadog.systemProbe.enableTCPQueueLength` 파라미터를 설정하여 검사를 활성화합니다. + +### 오퍼레이터(v1.0.0 이상)로 설정하기 + +DatadogAgent 매니페스트에서 `features.tcpQueueLength.enabled` 파라미터를 설정합니다. +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + features: + tcpQueueLength: + enabled: true +``` + +**참고**: COS(컨테이너에 최적화된 OS)를 사용하는 경우 다음과 같이 노드 에이전트에서 `src` 볼륨을 오버라이드합니다. +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + features: + tcpQueueLength: + enabled: true + override: + nodeAgent: + volumes: + - emptyDir: {} + name: src +``` + +### 검증 + +[Agent의 `status` 하위 명령을 실행][2]하고 Checks 섹션에서 `tcp_queue_length`를 찾습니다. + +## 수집한 데이터 + +### 메트릭 +{{< get-metrics-from-git "tcp_queue_length" >}} + + +### 서비스 점검 + +TCP Queue Length 점검은 서비스 점검을 포함하지 않습니다. + +### 이벤트 + +TCP Queue Length 점검은 이벤트를 포함하지 않습니다. + +## 트러블슈팅 + +도움이 필요하신가요? [Datadog 지원팀][5]에 문의하세요. + +[1]: https://github.com/DataDog/datadog-agent/blob/master/cmd/agent/dist/conf.d/tcp_queue_length.d/conf.yaml.example +[2]: https://docs.datadoghq.com/ko/agent/guide/agent-commands/#start-stop-and-restart-the-agent +[3]: https://github.com/DataDog/helm-charts +[4]: https://github.com/DataDog/integrations-core/blob/master/tcp_queue_length/metadata.csv +[5]: https://docs.datadoghq.com/ko/help/ \ No newline at end of file diff --git a/content/ko/integrations/vmware_tanzu_application_service.md b/content/ko/integrations/vmware_tanzu_application_service.md index 0ec2bff5c71c6..f21e5369f44be 100644 --- a/content/ko/integrations/vmware_tanzu_application_service.md +++ b/content/ko/integrations/vmware_tanzu_application_service.md @@ -6,6 +6,7 @@ categories: - 프로비저닝 - 설정 및 배포 - 로그 수집 +custom_kind: 통합 dependencies: - https://github.com/DataDog/documentation/blob/master/content/en/integrations/vmware_tanzu_application_service.md description: VMware Tanzu Application Service(이전 Pivotal Cloud Foundry) VM 상태 및 실행하는 @@ -14,17 +15,16 @@ doc_link: /integrations/vmware_tanzu_application_service/ further_reading: - link: https://www.datadoghq.com/blog/pcf-monitoring-with-datadog/ tag: 블로그 - text: Datadog를 통한 Pivotal 플랫폼 모니터링 + text: Datadog를 통한 핵심 플랫폼 모니터링 - link: /integrations/guide/application-monitoring-vmware-tanzu/ - tag: documentation - text: VMware Tanzu용 Datadog 애플리케이션 모니터링 + tag: 설명서 + text: VMware Tanzu용 Datadog 애플리케이션 모니터 - link: /integrations/guide/cluster-monitoring-vmware-tanzu/ - tag: documentation - text: VMware Tanzu용 Datadog 클러스터 모니터링 + tag: 설명서 + text: VMware Tanzu용 Datadog 클러스터 모니터 integration_id: pivotal-platform integration_title: VMware Tanzu Application Service is_public: true -custom_kind: 통합 name: vmware_tanzu_application_service newhlevel: true public_title: Datadog-VMware Tanzu Application Service (Pivotal Cloud Foundry) 통합 @@ -44,7 +44,7 @@ Datadog와 VMware Tanzu Application Service 통합에는 세 개의 주요 구 [VMware Tanzu 설치 및 설정][4] 가이드를 사용해 Tanzu Ops Manager를 통한 통합을 설치합니다. 수동 설정 단계의 경우 수동 설정 가이드의 [애플리케이션 모니터링][5] 섹션을 읽으세요. -### 구성 +### 설정 #### 메트릭 수집 @@ -61,7 +61,7 @@ cf restage Datadog 애플리케이션 성능 모니터링(APM)은 기본적으로 활성화됩니다. [APM 설정][6] 및 [프로파일링 설정][7]에서 사용자 언어를 위한 자세한 설정 정보를 알아보세요. -#### 오류 +#### 로그 수집 {{% site-region region="us3" %}} @@ -133,7 +133,7 @@ cf restage {{% /site-region %}} -### 수집한 데이터 +### DogStatsD [DogStatsD][10]를 사용해 커스텀 애플리케이션 메트릭을 Datadog로 전송할 수 있습니다. 자세한 정보는 [메트릭 제출: DogStatsD][11]을 참조하세요. 다양한 애플리케이션과 호환되는 [DogStatsD 라이브러리][12] 목록이 있습니다. @@ -141,9 +141,9 @@ cf restage [VMware Tanzu 설치 및 설정][13] 가이드를 사용해 Tanzu Ops Manager를 통한 통합을 설치하세요. 수동 설정 단계는 수동 설정 가이드의 [VMware Tanzu Application Service 클러스터 모니터링][14] 섹션을 읽으세요. -## 수집된 데이터 +## 수집한 데이터 -### 메트릭 +### Metrics 다음 메트릭은 Datadog Firehose Nozzle에서 전송되었으며 접두어로 `cloudfoundry.nozzle`이 사용되었습니다. Datadog 에이전트는 기본적으로 Director 런타임 설정, [시스템][15], [네트워크][16], [디스크][17] 및 [NTP][18] 메트릭에서 설정한 모든 에이전트 검사에서 메트릭을 전송합니다. diff --git a/content/ko/integrations/zenduty.md b/content/ko/integrations/zenduty.md new file mode 100644 index 0000000000000..107305ee0040b --- /dev/null +++ b/content/ko/integrations/zenduty.md @@ -0,0 +1,149 @@ +--- +app_id: zenduty +app_uuid: 0f2dea25-5757-477c-ad92-d459133d8b05 +assets: + integration: + auto_install: true + configuration: {} + events: + creates_events: false + metrics: + check: [] + metadata_path: metadata.csv + prefix: zenduty. + service_checks: + metadata_path: assets/service_checks.json + source_type_id: 10305 + source_type_name: Zenduty +author: + homepage: https://www.zenduty.com + name: Zenduty + sales_email: vishwa@zenduty.com + support_email: shubham@zenduty.com +categories: +- 경고 +- 협업 +- 인시던트 +- 문제 추적 +- 알림 +custom_kind: 통합 +dependencies: +- https://github.com/DataDog/integrations-extras/blob/master/zenduty/README.md +display_on_public_website: true +draft: false +git_integration_title: zenduty +integration_id: zenduty +integration_title: Zenduty +integration_version: '' +is_public: true +manifest_version: 2.0.0 +name: zenduty +public_title: Zenduty +short_description: Datadog 경고의 인시던트 대응 및 알림 파트너로 Zenduty를 사용하세요 +supported_os: +- linux +- windows +- macos +tile: + changelog: CHANGELOG.md + classifier_tags: + - Category::Alerting + - Category::Collaboration + - Category::Incidents + - Category::Issue Tracking + - Category::Notifications + - Offering::Integration + - Supported OS::Linux + - Supported OS::Windows + - Supported OS::macOS + configuration: README.md#Setup + description: Datadog 경고의 인시던트 대응 및 알림 파트너로 Zenduty를 사용하세요 + media: + - caption: 상세하면서도 보기 쉬운 인시던트 대시보드 + image_url: images/incident_dashboard.png + media_type: image + - caption: Slack 또는 Teams에서 인시던트를 직접 처리하세요 + image_url: images/slack_controls.png + media_type: image + - caption: 경고 규칙을 정교하게 다듬어 팀의 인시던트 대응 수준을 끌어올리세요 + image_url: images/alert_rules.png + media_type: image + - caption: 인시던트 관리 사이클 전반에 걸쳐 안정적이고 노이즈가 없는 경고 시스템 + image_url: images/incident_timeline.png + media_type: image + - caption: 인시던트에 플레이북을 자동으로 적용하고 단계별 가이드를 받으세요 + image_url: images/task_playbooks.png + media_type: image + overview: README.md#Overview + support: README.md#Support + title: Zenduty +--- + + +## 개요 + +Zenduty 통합을 사용해 Datadog 경고를 적절한 팀에 전송하고, 대기 일정에 따라 알림을 전달하며, 신속하게 사고를 해결하도록 지원하세요. 이메일, Slack, Microsoft Teams, SMS, 전화 통화, Android 및 iOS 푸시 메시지를 통해 알림을 전송할 수 있습니다. + +Zenduty를 Datadog에 연결하면 다음과 같은 이점이 있습니다. +- Zenduty 인시던트를 트리거하여 해결하고, 생성된 인시던트에 대한 경고를 받고, Datadog에서 문제를 추적합니다. +- 온콜 일정, 에스컬레이션 정책, 인시던트 플레이북, 사후 분석 및 상세 분석을 배포합니다. +- 경고 규칙을 사용해 특정 사용자 또는 팀과 관련한 Datadog 알림 라우팅을 맞춤 설정하고, 억제 규칙을 작성하며, 메모, 응답자 및 인시던트 작업을 자동으로 추가합니다. + +## 설정 + +### Zenduty +[Zenduty][1]에서 아래 단계를 따르세요. + +1. **Teams**로 이동한 후 통합을 추가할 팀을 클릭합니다. + +2. **Services**로 이동한 후 새로운 서비스를 만들거나 기존 서비스를 선택합니다. + +3. **Integrations**에서 **Add New Integration**으로 이동합니다. 통합에 이름을 지정하고 드롭다운 메뉴에서 **Datadog** 애플리케이션을 선택합니다. + +4. 해당 통합에서 **Configure**로 이동한 후 생성된 Datadog 웹훅 URL을 복사합니다. + +### Datadog에서 아래 단계를 따르세요. + +5. 사이드바에서 **Integrations**로 이동합니다. [이 페이지][2]에서 **Webhooks**를 검색하고 추가 버튼을 클릭합니다. + +6. 아래로 스크롤하여 Webhooks 섹션에서 **+New** 버튼을 클릭합니다. 이름과 Zenduty에서 복사한 웹훅 URL을 입력하고 다음 JSON을 페이로드 상자에 붙여넣습니다. +```json +{ + "alert_id": "$ALERT_ID", + "hostname": "$HOSTNAME", + "date_posix": "$DATE_POSIX", + "aggreg_key": "$AGGREG_KEY", + "title": "$EVENT_TITLE", + "alert_status": "$ALERT_STATUS", + "alert_transition": "$ALERT_TRANSITION", + "link": "$LINK", + "event_msg": "$TEXT_ONLY_MSG" +} +``` + +7. **Save**를 클릭합니다. Datadog Zenduty 통합 설정이 완료되었습니다. + +자세한 내용 및 통합 활용법은 [Zenduty 설명서][3]를 참조하세요. + +**참고**: Datadog 인시던트가 생성되거나 해결될 때 Zenduty를 통해 알림을 받으려면 Datadog 모니터 설정의 **Notify your team**에서 채널로 `@zenduty`를 멘션합니다. + +## 수집한 데이터 +### 메트릭 + +Zenduty 통합은 메트릭을 포함하지 않습니다. + +### 이벤트 + +트리거된 이벤트, 확인된 이벤트, 해결된 이벤트는 Zenduty 대시보드에 표시됩니다. + +### 서비스 점검 + +Zenduty 통합은 서비스 점검을 포함하지 않습니다. + +## 트러블슈팅 +도움이 필요하신가요? [Datadog 지원팀][4]에 문의하세요. + +[1]: https://www.zenduty.com +[2]: https://app.datadoghq.com/integrations/webhooks?search=webhook +[3]: https://docs.zenduty.com/docs/datadog +[4]: https://docs.datadoghq.com/ko/help/ \ No newline at end of file diff --git a/content/ko/integrations/zoom_activity_logs.md b/content/ko/integrations/zoom_activity_logs.md new file mode 100644 index 0000000000000..4c05707af3430 --- /dev/null +++ b/content/ko/integrations/zoom_activity_logs.md @@ -0,0 +1,129 @@ +--- +app_id: zoom-activity-logs +app_uuid: 2297e963-5129-4711-bf04-767d5c929f5e +assets: + dashboards: + zoom-activity-logs: assets/dashboards/zoom_activity_logs_overview.json + integration: + auto_install: false + events: + creates_events: false + service_checks: + metadata_path: assets/service_checks.json + source_type_id: 10394 + source_type_name: Zoom Activity Logs +author: + homepage: https://www.datadoghq.com + name: Datadog + sales_email: info@datadoghq.com + support_email: help@datadoghq.com +categories: +- log collection +- 보안 +custom_kind: integration +dependencies: [] +display_on_public_website: true +draft: false +git_integration_title: zoom_activity_logs +integration_id: zoom-activity-logs +integration_title: Zoom Activity Logs +integration_version: '' +is_public: true +manifest_version: 2.0.0 +name: zoom_activity_logs +public_title: Zoom Activity Log +short_description: Zoom에서 작업 및 활동 로그 소비 +supported_os: +- linux +- windows +- macos +tile: + changelog: CHANGELOG.md + classifier_tags: + - Category::Log Collection + - 카테고리::보안 + - 제출한 데이터 유형::로그 + - 지원되는 OS::Linux + - 지원되는 OS::Windows + - 지원되는 OS::macOS + - 제공::통합 + configuration: README.md#Setup + description: Zoom에서 작업 및 활동 로그 소비 + media: [] + overview: README.md#Overview + support: README.md#Support + title: Zoom Activity Log +--- + + + + +## 개요 +이 통합은 Zoom Activity Log 컬렉션을 활성화하여 Zoom 계정 내 활동을 캡처합니다. 이를 통해 다음과 같은 작업이 가능합니다. + +- 환경 내 다른 서비스에서 데이터와 Zoom 이벤트를 상호 참조합니다. +- Zoom 이벤트 데이터를 사용해 커스텀 위젯과 대시보드를 빌드합니다. +- 실시간 사용 가능한 로그 파이프라인을 사용해 [Cloud SIEM][1] 탐지 규칙을 설정합니다. + +Datadog의 Zoom 통합에서는 [로그인 및 로그아웃 활동][1] 및 [작업 로그][2]를 사용하여 로그를 수집하기 때문에 관리자 및 사용자 활동에 관한 인사이트를 얻을 수 있습니다. 여기에는 다음이 포함됩니다. + - 새로운 사용자 추가 + - 계정 설정 변경 + - 레코딩 삭제 + - 로그인 및 로그아웃 활동 + + +## 설정 + +### 설치 + +1. 통합 페이지로 이동하여 "Zoom Activity Log" 통합을 검색합니다. +3. 타일을 클릭합니다. +4. 통합을 설치할 계정을 추가하려면 "Add Account" 버튼을 클릭합니다. +5. 모달에서 지침을 읽은 후 "Authorize" 버튼을 클릭하면 Zoom 로그인 페이지로 이동합니다. +6. Zoom 관리자 계정을 사용해 Zoom에 로그인합니다. +7. 감사 데이터를 확인할 수 있는 +`report:read:admin` 범위에 액세스를 요청하는 화면이 나타나면 "Accept"를 클릭합니다. +8. 새 계정을 사용하면 Datadog Zoom Activity Log 타일로 다시 리디렉션됩니다. 'Account Name'을 기억하기 쉬운 이름으로 변경하는 것이 좋습니다. + + +## 권한 + +Zoom용 Datadog는 다음 OAuth 범위를 필요로 합니다. 자세한 정보는 [Zoom OAuth 범위 설명서][3]를 참조하세요. + +### 사용자 수준 범위 + +| 범위 | 요청 이유 | +|--------------------------|----------------------------------------------------------------------------------------------------------------| +| `report:read:admin` | 새 사용자 추가, 계절 설정 변경, 레코딩 삭제와 같은 이벤트를 포함하는 감사 관리자 및 사용자 활동 로그를 읽습니다. Zoom 계정 아래에서 사용자의 로그인/로그아웃 활동을 읽습니다. | + + +### 앱 제거하기 +Zoom Activity Log 통합을 설치 제거하려면 Zoom Activity Log 타일로 이동한 다음 계정 표에 나타나는 기존 계정을 모두 삭제합니다. + + +## 수집한 데이터 + +### 메트릭 + +Zoom Activity Log는 메트릭을 포함하지 않습니다. + +### 서비스 점검 + +Zoom Activity Log는 서비스 점검을 포함하지 않습니다. + +### 로그 +Zoom Activity Log는 Zoom [로그인 및 로그아웃 활동][1] 및 [작업 로그][2] 엔드포인트에서 데이터를 수집합니다. + +### 이벤트 + +Zoom Activity Log는 이벤트를 포함하지 않습니다. + +## 트러블슈팅 + +도움이 필요하신가요? [Datadog 지원 팀][4]에 문의하세요. + + +[1]: https://developers.zoom.us/docs/api/rest/reference/zoom-api/methods/#operation/reportSignInSignOutActivities +[2]: https://developers.zoom.us/docs/api/rest/reference/zoom-api/methods/#operation/reportOperationLogs +[3]: https://developers.zoom.us/docs/integrations/oauth-scopes-granular/#reports +[4]: https://docs.datadoghq.com/ko/help/ \ No newline at end of file diff --git a/content/ko/logs/explorer/facets.md b/content/ko/logs/explorer/facets.md index 84f7803def773..a41a1a815c636 100644 --- a/content/ko/logs/explorer/facets.md +++ b/content/ko/logs/explorer/facets.md @@ -1,4 +1,7 @@ --- +algolia: + tags: + - 로그 패싯 aliases: - /ko/logs/facets description: 로그 패싯과 패싯 패널 @@ -30,7 +33,7 @@ title: 로그 패싯 또 패싯을 사용해 [대시보드][5]와 [노트북][6]의 [로그 모니터][4]와 로그 위젯에서 로그를 조절할 수 있습니다. -**참고**: 로그, [아카이브][11] 포워딩, 또는 [리하이드레이션][12]의 [로그 프로세싱], [livetail 검색][8], [로그 탐색기 검색][30], [메트릭 생성][10]을 지원할 때는 패싯이 필요 없습니다. 또 필터로 [파이프라인][13]과 [인덱스][14]를 통해 로그를 라우팅하거나 [예외 필터][15]로 인덱스에서 로그를 제외하거나 샘플링할 때도 패싯이 필요하지 않습니다. +**참고**: 로그, [아카이브][11] 포워딩, 또는 [리하이드레이션][12]의 [로그 프로세싱][7], [라이브테일 검색][8], [로그 탐색기 검색][9], [메트릭 생성][10]을 지원할 때는 패싯이 필요 없습니다. 또한 필터로 [파이프라인][13]과 [인덱스][14]를 통해 로그를 라우팅하거나 [예외 필터][15]로 인덱스에서 로그를 제외 또는 샘플링할 때도 패싯이 필요 없습니다. 이와 같은 컨텍스트에서는 자동 완료 기능에서 기존 패싯을 사용하나, 수신 로그와 일치하는 입력이라면 무엇이든 사용할 수 있습니다. @@ -96,18 +99,18 @@ title: 로그 패싯 ### 패싯 숨기기 조직에는 다양한 팀의 여러 사용 사례에 맞게 대처하도록 수집하는 패싯 종류가 매우 많습니다. 그러나 보통 특정 트러블슈팅 컨텍스트에서는 이 패싯의 하위 세트만이 유용하게 사용됩니다. 트러블슈팅 세션에서 일상에서 사용하지 않는 패싯을 숨기고 필요한 패싯만 표시하세요. - -{{< img src="logs/explorer/facet/hide_facet.png" alt="패싯 숨기기" style="width:30%;">}} +1. [로그 탐색기][30]에서 숨기려는 패싯을 찾습니다. +1. 패싯 옆에 있는 톱니 아이콘을 클릭합니다. +1. **패싯 숨기기**를 선택합니다. 패싯을 숨겨도 필요할 경우에 대비해 패싯 검색 결과에는 표시됩니다([패싯 필터링](#filter-facets) 섹션 참고). 여기에서 패싯 숨기기를 해제할 수 있습니다. -{{< img src="logs/explorer/facet/unhide_facet.png" style="width:50%;" alt="패싯 숨기기 해제" style="width:30%;">}} 숨긴 패싯은 검색 바 자동 완료와 Log Explorer의 분석 결과 드롭다운(예: 수치, 그룹별)에서도 숨겨진 상태로 나타납니다. 그러나 검색 쿼리에서는 패싯을 숨겨도 유효한 상태로 나타납니다(예: 로그 탐색기 링크를 복사-붙여넣기 한 경우). -숨긴 패싯은 로그 탐색기(예: livetail, 모니터, 또는 대시보드 위젯 정의) 외 기능에는 아무 영향이 없습니다. +숨긴 패싯은 로그 탐색기(예: 대시보드의 라이브테일, 모니터 또는 위젯 정의) 외에 미치는 영향이 없습니다. -#### 숨겨진 패싯과 팀원 +#### 숨겨진 패싯 및 팀 구성원 패싯 숨기기 기능은 내 트러블슈팅 컨텍스트에 맞게 사용해야 하고 팀원의 보기에는 아무런 영향을 미치지 않습니다. 단, [저장된 보기][24]를 업데이트한 경우에는 다릅니다. 숨긴 패싯은 저장된 보기에 저장된 컨텍스트의 일부가 됩니다. @@ -182,7 +185,7 @@ JSON 개체 어레이에서 패싯을 생성하려면 먼저 [grok 파서][29] 일치하는 로그를 찾을 수 없는 경우에는 _패싯 추가_ 버튼을 사용해 패싯 패널에서 바로 새 패싯을 생성할 수 있습니다. -이 패싯의 기본 필드(키) 이름을 정의합니다: +이 패싯의 기본 필드(키) 이름을 정의하세요. - 태그의 태그 키 이름을 사용하세요. - `@` 접두사를 사용해 속성 경로를 사용하세요. @@ -239,7 +242,7 @@ _앨리어싱된_ 패싯을 _표준_ 패싯에 앨리어싱하는 경우: [6]: /ko/notebooks/ [7]: /ko/logs/log_configuration/processors [8]: /ko/logs/live_tail/ -[9]: /ko/logs/log_configuration/attributes_naming_convention/#standard-attributes +[9]: /ko/logs/explorer/ [10]: /ko/logs/logs_to_metrics/ [11]: /ko/logs/archives/ [12]: /ko/logs/archives/rehydrating/ @@ -260,4 +263,4 @@ _앨리어싱된_ 패싯을 _표준_ 패싯에 앨리어싱하는 경우: [27]: /ko/logs/indexes/#indexes [28]: /ko/logs/log_configuration/rehydrating [29]: /ko/logs/log_configuration/parsing/?tab=matchers#nested-json -[30]: /ko/logs/explorer/ \ No newline at end of file +[30]: https://app.datadoghq.com/logs \ No newline at end of file diff --git a/content/ko/logs/guide/manage_logs_and_metrics_with_terraform.md b/content/ko/logs/guide/manage_logs_and_metrics_with_terraform.md new file mode 100644 index 0000000000000..8159503744165 --- /dev/null +++ b/content/ko/logs/guide/manage_logs_and_metrics_with_terraform.md @@ -0,0 +1,60 @@ +--- +disable_toc: false +title: Terraform으로 로그 및 메트릭 관리 +--- + +## 개요 +[Terraform][1]으로 Datadog API와 상호 작용하고 로그 및 메트릭을 관리할 수 있습니다. 본 지침에서는 사용 사례 예시를 제시하며, Tearraform 레지스트리에서 일반적으로 사용되는 Datadog 리소스와 데이터 소스 링크가 포함되어 있습니다. + +또한, 기존 리소스를 Terraform 설정으로 [불러오기][2]하여 기존 리소스를 Terraform [데이터 소스][3]로 참조할 수 있습니다. + +## Datadog Terraform 공급자 설정 + +아직 설정하지 않은 경우, Terraform 설정에서 [Datadog Terraform 제공자][4]를 설정하여 Datadog API와 상호작용할 수 있도록 합니다. + +## 로그 설정 + +### 다중 인덱스 설정 + +보존 기간 또는 일일 할당량, 사용량 모니터, 청구에 따라 로그를 분할하려면 [다중 인덱스][5]를 설정합니다. 예를 들어, 7일 동안만 보존해야 하는 로그와 30일 동안 보존해야 하는 로그가 있다면 다중 인덱스로 로그를 두 가지 보존 기간으로 구분합니다. 이러한 필터의 쿼리 정의에 관한 자세한 내용은 [포함 필터][6] 및 [제외 필터][7] 문서를 참조하세요. 수집한 로그는 필터와 일치하는 첫 번째 인덱스로 이동하므로, 사용 사례에 따라 [인덱스 순서][8]를 지정하세요. + +### 커스텀 파이프라인 설정 + +로그 파이프라인은 콘텐츠에서 의미 있는 정보나 속성을 추출하여 패싯으로 재사용하는 일련의 순차적 프로세서입니다. 파이프라인을 거치는 각 로그는 각 파이프라인 필터와 매칭됩니다. 필터와 매칭되면 다음 파이프라인으로 이동하기 전 모든 프로세서가 로그에 적용됩니다. [커스텀 파이프라인][9]을 설정하여 로그를 파싱하고 보강합니다. 사용 가능한 프로세서에 관한 자세한 내용은 [프로세서 문서][10]를 참조하세요. 또한, [파이프라인 재정렬][11]로 로그가 올바른 순서로 처리되고 있는지 확인할 수 있습니다. + +통합 파이프라인은 특정 소스(예: NGINX 통합)에서 로그를 전송하면 자동 설치됩니다. [로그 통합 파이프라인 리소스][12]로 해당 파이프라인을 재정렬할 수 있습니다. + +### 장기 보관용 다중 아카이브 설정 + +로그를 더 장기간 보관하려면 [로그 아카이브][13]를 설정합니다. 로그 아카이브는 로그를 Amazon S3, Azure Storage 또는 Google Cloud Storage 등, 스토리지에 최적화된 시스템으로 전송합니다. 필요에 따라 [아카이브를 재정렬][14]할 수도 있습니다. + +### 수집한 로그에서 메트릭 생성 + +[로그 기반 메트릭을 생성][15]하여 수집한 로그에서 로그 데이터를 요약합니다. 예를 들어, 쿼리와 매칭되는 로그의 카운트 메트릭을 생성하거나, 요청 기간과 같이 로그에 포함된 숫자 값의 분포 메트릭과 일치하는 로그의 카운트 메트릭을 생성할 수 있습니다. 자세한 내용은 [수집된 로그에서 메트릭 생성하기][16]를 참조하세요. + +## 메트릭 설정 + +메트릭의 메타데이터에는 메트릭 이름, 설명 및 유닛이 포함됩니다. 정보를 수정하려면 [메트릭 메타데이터 리소스][17]를 사용합니다. + +태그로 메트릭에 차원을 추가하여 시각화에서 필터링, 집계, 비교할 수 있습니다. [메트릭 태그 설정 리소스][18]로 Terraform에서 메트릭 태그를 수정합니다. 태그 활용에 관한 자세한 내용은 [태그 사용 시작하기][19]를 참조하세요. + + +[1]: https://www.terraform.io/ +[2]: https://developer.hashicorp.com/terraform/cli/import +[3]: https://developer.hashicorp.com/terraform/language/data-sources +[4]: /ko/integrations/terraform/ +[5]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/logs_index +[6]: /ko/logs/log_configuration/indexes/#indexes-filters +[7]: /ko/logs/log_configuration/indexes/#exclusion-filters +[8]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/logs_index_order +[9]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/logs_custom_pipeline +[10]: /ko/logs/log_configuration/processors/?tab=ui +[11]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/logs_pipeline_order +[12]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/logs_integration_pipeline +[13]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/logs_archive +[14]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/logs_archive_order +[15]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/logs_metric +[16]: https://docs.datadoghq.com/ko/logs/log_configuration/logs_to_metrics/ +[17]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/metric_metadata +[18]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/metric_tag_configuration +[19]: /ko/getting_started/tagging/ \ No newline at end of file diff --git a/content/ko/logs/log_configuration/indexes.md b/content/ko/logs/log_configuration/indexes.md index 4a19549a2623c..d610766fdec08 100644 --- a/content/ko/logs/log_configuration/indexes.md +++ b/content/ko/logs/log_configuration/indexes.md @@ -6,16 +6,16 @@ description: Datadog로 인덱싱된 로그 볼륨 제어 further_reading: - link: /logs/explorer/#visualize tag: 설명서 - text: 로그 분석 실행하기 + text: 로그를 남기다 분석 수행 - link: /logs/log_configuration/processors tag: 설명서 - text: 로그 처리하는 방법 배우기 + text: 로그 처리 방법 - link: /logs/log_configuration/parsing tag: 설명서 - text: 파싱에 대해 배우기 + text: 파싱에 대해 알아보기 - link: https://www.datadoghq.com/blog/logging-without-limits/ tag: 블로그 - text: 제한없는 로그 수집 + text: Logging without Limits* title: 인덱스 --- @@ -77,7 +77,7 @@ title: 인덱스 제외 필터를 추가하려면 다음을 수행하세요. 1. [로그 인덱스][11]를 탐색합니다. -2. 제외 필터를 추가할 파이프라인을 확장합니다. +2. 예외 필터를 추가하려는 인덱스 확장 3. **제외 필터 추가**를 클릭합니다. 제외 필터는 쿼리, 샘플링 규칙 및 활성/비활성 토글로 정의됩니다. @@ -159,7 +159,7 @@ title: 인덱스 일일 할당량 또는 경고 임계값에 도달하면 이벤트가 생성됩니다: -{{< img src="logs/indexes/index_quota_event.png" alt="인덱스 할당량 알림" style="width:70%;">}} +{{< img src="logs/indexes/daily_quota_warning_events.png" alt="일일 할당량 및 경고 이벤트" style="width:90%;">}} 사용량에 대한 모니터링과 알림 방법은 [로그 사용량 모니터링][20]을 참조하세요. diff --git a/content/ko/metrics/guide/calculating-the-system-mem-used-metric.md b/content/ko/metrics/guide/calculating-the-system-mem-used-metric.md new file mode 100644 index 0000000000000..3bb94275f6f0e --- /dev/null +++ b/content/ko/metrics/guide/calculating-the-system-mem-used-metric.md @@ -0,0 +1,36 @@ +--- +aliases: +- /ko/agent/faq/how-is-the-system-mem-used-metric-calculated/ +further_reading: +- link: /metrics/ + tag: 설명서 + text: 메트릭에 대해 자세히 알아보기 +title: '''system.mem.used'' 메트릭 계산하기' +--- + +Datadog에서 `system.mem.used` 메트릭을 계산하는 방식은 때때로 일반적인 시스템 리소스 보고 도구가 표시하는 값과 다른 값을 생성할 수 있습니다. + +예를 들어 Ubuntu 머신에서 'free -m'을 실행하면 다음 메모리 상세 내역이 생성될 수 있습니다(값은 메가바이트를 표시): + +| | | | | | | +| :--- | :--- | :--- | :--- | :--- | :--- | +| total | used | free | shared | cached | available | +| 128831 | 1203 | 71975 | 4089 | 55653 | 122380 | + +동일한 머신에서 실행되는 Datadog Agent는 56856MB 값의 `system.mem.used` 메트릭을 보고합니다. 이는 'free -m'의 사용된 메모리 값인 1203MB와 분명히 다릅니다. + +이러한 차이가 발생한 이유는 Datadog가 'free -m'과는 달리 사용된 메모리 계산식에 캐싱된 메모리를 포함하기 때문입니다. + +Datadog는 다음과 같이 사용된 메모리를 계산합니다. + +* system.mem.used(56856) = system.mem.total(128831) - system.mem.free(71975) + +Datadog의 `system.mem.used` 메트릭은 캐싱된 메모리를 포함하므로 사용된 메모리에서 이 캐싱된 메모리를 빼면 다음 값이 도출됩니다. + +* system.mem.used(56856) - system.mem.cached(55653) = 1203 + +1203MB는 위 예에서 'free -m'에서 보고한 사용된 메모리 값과 동일합니다. + +**`system.mem.usable` 메트릭은 남은 메모리와 캐싱된 메모리와 버퍼(Linux에서 가능한 경우, /proc/meminfo의 "MemAvailable" 속성을 반영)를 더한 값을 나타냅니다. + +{{< partial name="whats-next/whats-next.html" >}} \ No newline at end of file diff --git a/content/ko/metrics/guide/micrometer.md b/content/ko/metrics/guide/micrometer.md index 1f46bed9f726c..e865e122be12d 100644 --- a/content/ko/metrics/guide/micrometer.md +++ b/content/ko/metrics/guide/micrometer.md @@ -1,36 +1,36 @@ --- further_reading: -- link: https://micrometer.io/docs/registry/otlp - tag: 마이크로미터 - text: 마이크로미터 OTLP -- link: https://micrometer.io/docs/registry/prometheus - tag: 마이크로미터 - text: 마이크로미터 프로메테우스(Prometheus) -title: 마이크로미터(Micrometer)를 사용한 메트릭 전송 +- link: https://docs.micrometer.io/micrometer/reference/implementations/otlp.html + tag: 외부 사이트 + text: Micrometer OTLP +- link: https://docs.micrometer.io/micrometer/reference/implementations/prometheus.html + tag: 외부 사이트 + text: Micrometer Prometheus +title: Micrometer로 메트릭 전송하기 --- ## 개요 -[마이크로미터][1]는 벤더 독립적 인터페이스로, 메트릭에 액세스하여 다양한 차원에서 분석할 수 있는 기능을 제공합니다. 주로 메트릭 제출을 위해 추상화 레이어로 자바(Java) 스프링 부트(Spring Boot) 애플리케이션과 함께 사용됩니다. +[Micrometer][1]는 벤더 중립형 인터페이스로, 이를 이용해 메트릭에 접근해 여러 차원 전반에서 메트릭을 분석할 수 있습니다. Java Spring Boot 애플리케이션과 함께 메트릭 전송용 추상화 계층으로 사용됩니다. -마이크로미터는 Datadog와 통합할 수 있는 다양한 방법을 제공합니다. 이 가이드는 에이전트를 사용해 Datadog에 메트릭을 전송하는 Datadog 권장 방법에 대해 간략히 설명합니다. +Micrometer는 Datadog과 통합하는 다양한 방법을 제공합니다. 이 가이드에서는 Agent를 사용해 메트릭을 Datadog으로 전송하는 Datadog 권장 옵션을 설명합니다. -## 패싯 +## OpenTelemetry -Datadog 에이전트의 OTLP(OpenTelemetry Protocol) 수집을 통해 Datadog 에이전트의 관측 가능성 기능을 활용할 수 있습니다. +Datadog Agent의 OpenTelemetry Protocol(OTLP) 수집 기능으로 Datadog Agent의 가시성을 활용할 수 있습니다. -{{< whatsnext desc="다음 설명서에 간략히 설명된 설정 참조:" >}} - {{< nextlink href="/opentelemetry/otlp_ingest_in_the_agent/" >}}Datadog 에이전트의 OTLP 수집{{< /nextlink >}} +{{< whatsnext desc="다음 문서에서 설명한 설정을 참조하세요." >}} + {{< nextlink href="/opentelemetry/otlp_ingest_in_the_agent/" >}}Datadog Agent로 OTLP 수집{{< /nextlink >}} {{< /whatsnext >}} -## 프로메테우스 및 개방형메트릭(OpenMetrics) +## Prometheus 및 OpenMetrics -프로메테우스나 개방형메트릭 통합을 사용해 애플리케이션 메트릭을 Datadog에 전송합니다. +Prometheus 또는 OpenMetrics 통합으로 애플리케이션 메트릭을 Datadog에 전송합니다. -{{< whatsnext desc="다음 설명서에 설명된 설정 참조:" >}} - {{< nextlink href="/integrations/guide/prometheus-host-collection/#overview" >}}호스트에서 프로메테우스와 개방형 메트릭을 사용한 메트릭 수집{{< /nextlink >}} - {{< nextlink href="/containers/kubernetes/prometheus/?tab=kubernetesadv2" >}}쿠버네티스(Kubernetes) 프로메테우스 및 개방형메트릭을 사용한 메트릭 수집{{< /nextlink >}} - {{< nextlink href="/containers/docker/prometheus/?tab=standard" >}}도커(Docker) 프로메테우스 및 개방형메트릭을 사용한 메트릭 수집{{< /nextlink >}} +{{< whatsnext desc="다음 문서에서 설명한 설정을 참조하세요." >}} + {{< nextlink href="/integrations/guide/prometheus-host-collection/#overview" >}}호스트에서 Prometheus 및 OpenMetrics 메트릭 수집{{< /nextlink >}} + {{< nextlink href="/containers/kubernetes/prometheus/?tab=kubernetesadv2" >}}Kubernetes Prometheus 및 OpenMetrics 메트릭 수집{{< /nextlink >}} + {{< nextlink href="/containers/docker/prometheus/?tab=standard" >}}Docker Prometheus 및 OpenMetrics 메트릭 수집{{< /nextlink >}} {{< /whatsnext >}} ## 참고 자료 diff --git a/content/ko/metrics/guide/why-does-zooming-out-a-timeframe-also-smooth-out-my-graphs.md b/content/ko/metrics/guide/why-does-zooming-out-a-timeframe-also-smooth-out-my-graphs.md new file mode 100644 index 0000000000000..851afce81fd2e --- /dev/null +++ b/content/ko/metrics/guide/why-does-zooming-out-a-timeframe-also-smooth-out-my-graphs.md @@ -0,0 +1,31 @@ +--- +aliases: +- /ko/graphing/faq/why-does-zooming-out-a-timeframe-also-smooth-out-my-graphs +- /ko/dashboards/faq/why-does-zooming-out-a-timeframe-also-smooth-out-my-graphs +further_reading: +- link: /metrics/types/ + tag: 설명서 + text: Datadog 메트릭 유형 알아보기 +- link: /dashboards/functions/rollup/ + tag: 설명서 + text: 롤업 기능에 대해 자세히 알아보기 +title: 기간을 늘리면 그래프가 더 평탄해지는 이유가 무엇인가요? +--- + +Datadog 내에서 그래프는 정해진 수의 포인트만 포함할 수 있으며, 메트릭에 기간이 길어질수록 포인트 간 집계로 인해 포인트 수가 정의된 수 이하로 유지됩니다. 따라서 기간이 길어질수록 세분화가 줄어들게 됩니다. 예를 들어, 4시간 동안의 데이터는 선 그래프의 경우 1분에 하나의 값, 막대 그래프의 경우 2분에 하나의 값으로 집계됩니다. 더 긴 기간을 선택하여 축소하면 그래프에 표시되는 데이터가 더 긴 기간을 나타냅니다. + +{{< img src="metrics/guide/smooth_line.mp4" alt="선 그래프 평활화" video="true" width="90%" >}} + +막대가 표시되면 반영 간격이 더 명확해집니다. + +{{< img src="metrics/guide/smoothing.mp4" alt="막대 그래프 평활화하기" 비디오="true" width="90%" >}} + +쿼리에 `.rollup()` 기능을 수동으로 추가하여 시간 집계 방법과 세분화를 조정할 수 있습니다. Datadog는 기본적으로 데이터 포인트를 자동으로 반영하여 `GAUGE`, `RATE` 및 `COUNT` 메트릭 유형에 반영 간격의 값을 평균화합니다. + +**참고**: Datadog 위젯 UI를 통해 메트릭을 쿼리하면 [애플리케이션 내 메트릭 유형 수정자][1]가 `RATE` 및 `COUNT` 메트릭 유형에 자동으로 추가됩니다. 이렇게 하면 `.rollup()` 동작이 변경되어 보간 없이 값이 합산됩니다. + +## 참고 자료 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ko/metrics/custom_metrics/type_modifiers/ \ No newline at end of file diff --git a/content/ko/monitors/guide/custom_schedules.md b/content/ko/monitors/guide/custom_schedules.md index 8e7395d9a0fb2..ef8d8149a6548 100644 --- a/content/ko/monitors/guide/custom_schedules.md +++ b/content/ko/monitors/guide/custom_schedules.md @@ -13,91 +13,85 @@ further_reading: title: 모니터 평가 빈도 사용자 지정 --- -{{< beta-callout url="https://docs.datadoghq.com/help/" btn_hidden="false" >}} -모니터 사용자 지정 일정 기능은 비공개 베타 버전입니다. 액세스를 요청하려면 Datadog 지원팀에 문의하세요. -{{< /beta-callout >}} - ## 개요 -특정 평가 시간을 설정하고 모니터의 평가 빈도를 제어하여 환경에서 실행 중인 중요한 작업의 실행을 추적합니다. 모니터 사용자 지정 일정을 사용하면 cron 작업과 같이 지속적으로 모니터링할 필요가 없는 시스템 및 프로세스에 대해 경고할 수 있습니다. - +특정 평가 시간을 설정하고 모니터 평가 주기를 제어하여 환경에서 실행되는 핵심 작업의 실행을 추적하세요. 모니터 커스텀 일정은 cron 작업 등 지속적인 모니터링이 필요하지 않은 시스템과 프로세스의 알림을 받을 수 있도록 해줍니다. -모니터 사용자 지정 일정은 일별, 주별 및 월별 일정 간격을 사용하여 이벤트, 로그 및 메트릭 모니터에서 지원됩니다. +모니터 커스텀 일정은 매일, 매주, 매월 일정 간격이 있는 이벤트, 로그, 메트릭 모니터에서 지원됩니다. -## 설정 +## 구성 -{{< img src="/monitors/guide/custom_schedules/add_custom_schedule.png" alt="모니터링 설정에서 커스텀 일정을 추가하는 버튼" style="width:100%;" >}} +{{< img src="/monitors/guide/custom_schedules/add_custom_schedule.png" alt="모니터 설정에서 커스텀 일정을 추가하는 버튼" style="width:100%;" >}} -**Add Custom Schedule**을 클릭하여 평가 빈도를 설정합니다. +**Add Custom Schedule**를 클릭하여 평가 주기를 설정합니다. -
모니터링에서 커스텀 예약을 실행한 후에는 실행 중지할 수 없습니다. -
+
커스텀 일정이 모니터에서 활성화되면 일정을 비활성화할 수 없습니다. 커스텀 일정은 모니터 생성 중에만 추가하거나 제거할 수 있습니다.
{{< tabs >}} {{% tab "Day" %}} -하루 중 모니터를 평가할 시간을 선택합니다. +하루 중 모니터가 평가하는 시간을 선택하세요. -예를 들어 다음 모니터는 매일 오후 8시에 일일 백업 작업이 각 데이터베이스 인스턴스에 대해 성공 이벤트를 생성했는지 확인합니다. +예를 들어, 다음 모니터는 매일 오후 8시에 일일 백업 작업이 각 데이터베이스 인스턴스에 성공 이벤트를 생성했는지 확인합니다. -{{< img src="monitors/guide/custom_schedules/custom_day.png" alt="매일 오후 8시에 매일 백업 작업의 결과로 각 데이터베이스 인스턴스에 대해 성공 이벤트가 생성되었는지 확인하는 모니터 설정." style="width:100%;" >}} +{{< img src="monitors/guide/custom_schedules/custom_day.png" alt="일일 백업 작업의 결과로 각 데이터베이스에 성공 이벤트가 생성되었는지 매일 오후 8시에 확인하는 모니터 설정" style="width:100%;" >}} {{% /tab %}} {{% tab "Week" %}} -모니터를 평가할 요일과 시간을 선택합니다. +한 주 중 모니터가 평가하도록 하려는 일자와 시간을 선택하세요. -예를 들어, 다음 모니터는 매주 화요일과 토요일 오전 6시에 각 개별 캠페인에 대해 마케팅 이메일이 전송되었는지 확인합니다. +예를 들어, 다음 모니터는 매주 화요일과 토요일 오전 6시에 각 개별 캠페인에 마케팅 이메일이 전송되었는지를 확인합니다. -{{< img src="monitors/guide/custom_schedules/custom_week.png" alt="매주 화, 토요일 오전 6시에 개별 캠페인별로 마케팅 이메일이 발송되었는지 확인하는 모니터 설정" style="width:100%;" >}} +{{< img src="monitors/guide/custom_schedules/custom_week.png" alt="각 개별 캠페인에 마케팅 이메일이 전송되었는지 매주 화요일 및 토요일 오전 6시에 확인하는 모니터 설정" style="width:100%;" >}} {{% /tab %}} {{% tab "Month" %}} -모니터가 평가할 날짜와 시간을 선택하세요. +한 달 중 모니터가 평가하는 일자와 시간을 선택하세요. -예를 들어 다음 모니터는 매월 1일 고객 인보이스를 생성하는 cron 작업이 성공적으로 실행되었는지 확인합니다. +예를 들어, 다음 모니터는 매월 첫 번째 날에 고객 인보이스를 생성하는 cron 작업이 성공적으로 실행되었는지 확인합니다. -{{< img src="monitors/guide/custom_schedules/custom_month.png" alt="매월 1일 고객 인보이스를 생성하는 cron 작업이 성공적으로 실행되었는지 확인하는 모니터링 설정." style="width:100%;" >}} +{{< img src="monitors/guide/custom_schedules/custom_month.png" alt="매월 첫 번째 날에 고객 인보이스를 생성하는 cron 작업이 성공적으로 실행되었는지 확인하는 모니터 설정" style="width:100%;" >}} {{% /tab %}} {{< /tabs >}} ## RRULES -반복 규칙(RRULE)은 반복 이벤트를 정의하는 표준인 [iCalendar RFC][1]의 속성 이름입니다. 반복 규칙을 생성하려면 [공식 RRULE 생성기][2]를 사용하세요. 고급 스케줄링 사용 사례를 다루기 위해 RRULE을 활용하세요. +반복 규칙(RRULE)은 [iCalendar RFC][1]의 속성 이름으로, 반복되는 이벤트를 정의하는 표준입니다. [공식 RRULE 생성기][2]를 사용하여 반복되는 규칙을 생성하세요. RRULE을 활용하여 향상된 방법으로 일정 사용 사례를 지원하세요. -모니터에 대한 커스텀 RRULE을 작성하려면 **Use RRULE**을 클릭합니다. +모니터에 커스텀 RRULE을 작성하려면 **Use RRULE**을 클릭합니다. **참고**: -- RRULE에서 기간을 지정하는 속성(예: DTSTART, DTEND, DURATION)은 지원되지 않습니다. -- 평가 빈도는 하루 이상이어야 하며, 평가 빈도가 짧으면 기본 모니터 일정을 사용합니다. +- RRULE에서 기간을 정의하는 속성은 지원되지 않습니다(예: DTSTART, DTEND, DURATION). +- 평가 주기는 1일 이상이어야 합니다. 더 짧은 주기의 평가의 경우 기본 모니터 일정을 사용하세요. -#### 예시: 모니터는 매월 말일에 평가합니다. +#### 예: 매월 마지막 날에 평가하는 모니터 ```text FREQ=MONTHLY;BYMONTHDAY=28,29,30,31;BYSETPOS=-1 ``` -{{< img src="monitors/guide/custom_schedules/RRULE_last_day_month.png" alt="UI에서 매월 마지막 날을 평가하는 데 사용되는 RRULE 구문" style="width:90%;" >}} +{{< img src="monitors/guide/custom_schedules/RRULE_last_day_month.png" alt="UI에 사용된 RRULE 구문, 매월 마지막 날에 평가" style="width:90%;" >}} -#### 예시: 모니터는 격월로 매월 첫째 주와 마지막 주 일요일에 평가합니다: +#### 예: 두 달마다 해당 월 첫 번째 및 마지막 일요일에 평가하는 모니터 ```text FREQ=MONTHLY;INTERVAL=2;BYDAY=1SU,-1SU ``` -{{< img src="monitors/guide/custom_schedules/RRULE_month_last_sunday.png" alt="UI에서 격월로 매월 첫째 주와 마지막 주 일요일에 평가하는 데 사용되는 RRULE 구문" style="width:90%;" >}} +{{< img src="monitors/guide/custom_schedules/RRULE_month_last_sunday.png" alt="UI에 사용된 RRULE 구문, 두 달마다 해당 월 첫 번째 및 마지막 일요일에 평가" style="width:90%;" >}} -## 커스텀 일정이 있는 모니터의 알림 동작 +## 커스텀 일정을 사용해 모니터 행동 알리기 -기본 스케줄링을 사용하는 모니터는 기본 평가 빈도로 쿼리를 실행하고 모니터 상태 전환(예: 모니터가 WARN에서 OK로 또는 OK에서 ALERT로 전환되는 경우)에 따라 알림을 보냅니다. +기본 일정을 사용하는 모니터는 기본 평가 주기로 쿼리를 실행하고 모니터 상태 전환(예: 모니터가 WARN->OK, OK->ALERT로 변경되는 경우)에 따라 알림을 전송합니다. -아래 타임라인은 기본 스케줄링을 사용하는 모니터의 동작을 보여줍니다. 모니터는 상태 변경에 해당하는 알림을 보냅니다. +아래 타임라인은 기본 일정의 모니터 행동을 설명합니다. 모니터는 상태 변경에 따라 알림을 전송합니다. -{{< img src="monitors/guide/custom_schedules/alerting_behavior_regular.png" alt="모니터가 30분 평가 빈도로 기본 일정에 대한 모니터 상태 전환을 기반으로 보내는 알림을 보여주는 시각적 다이어그램" style="width:100%;" >}} +{{< img src="monitors/guide/custom_schedules/alerting_behavior_regular.png" alt="비주얼 다이어그램, 30분 평가 주기로 기본 일정에 모니터 상태 전환 시 알림을 전송하는 모니터 표시" style="width:100%;" >}} -반면, 사용자 지정 일정을 사용하는 모니터링은 매일, 매주 또는 매월 기준으로 평가하고 개별 평가 결과에 따라 알림을 보냅니다. 각 평가는 이전 평가와 독립적이며 결과가 양호하지 않을 때 알림을 보냅니다. +커스텀 일정의 모니터의 경우, 매일, 매주, 매월 기준으로 개별 평가 결과에 따라 알림을 전송합니다. 각 평가는 이전 평가와 독립적이며, 결과가 OK가 아닌 경우에 알림을 전송합니다. -아래 타임라인은 사용자 지정 일정에 따라 실행되는 모니터의 동작을 보여줍니다. 기본 예약 모니터와 달리 사용자 지정 예약 모니터는 모니터 상태에 따라 평가 시간 동안 경고를 보냅니다. -{{< img src="monitors/guide/custom_schedules/alerting_behavior_custom.png" alt="모니터가 일일 평가 빈도를 사용하여 사용자 지정 일정에 대해 모니터 상태를 기반으로 보내는 알림을 보여주는 시각적 다이어그램" style="width:100%;" >}} +아래 타임라인은 커스텀 일정이 실행되는 모니터 행동을 설명합니다. 기본 일정 모니터와 달리 커스텀 일정 모니터는 모니터 상태에 따라 평가 시간 동안 알림을 전송합니다. +{{< img src="monitors/guide/custom_schedules/alerting_behavior_custom.png" alt="비주얼 다이어그램, 매일 평가 주기로 커스텀 일정의 모니터 상태에 따라 알림을 전송하는 모니터 표시 " style="width:100%;" >}} ## 참고 자료 diff --git a/content/ko/monitors/guide/integrate-monitors-with-statuspage.md b/content/ko/monitors/guide/integrate-monitors-with-statuspage.md index 994845d6d21dc..df60bbec19fff 100644 --- a/content/ko/monitors/guide/integrate-monitors-with-statuspage.md +++ b/content/ko/monitors/guide/integrate-monitors-with-statuspage.md @@ -44,7 +44,7 @@ Statuspage 알림을 트리거하는 [메트릭 모니터][8]을 생성하는 1. [**모니터** > **새 모니터**][9]로 이동한 다음 **메트릭**을 클릭합니다. 2. [메트릭 모니터 설명서][8]를 참조해 탐지 방법을 선택하고, 메트릭을 정의하고, 알림 조건과 고급 모니터 옵션을 설정하세요. 3. 모니터 이름을 커스터마이즈하여 테스트 상태에 따라 `UP` 또는 `DOWN`을 반환하도록 합니다. 예: `{{#is_alert}}DOWN{{/is_alert}}{{#is_recovery}}UP{{/is_recovery}}` -4. **팀에 알리기** 섹션에서 메시지의 `@custom-statuspage-email@notifications.statuspage.io` 등 생성된 이메일 주소를 추가합니다. 이를 통해 자동으로 **재알림** 위에 있는 `Notify your services and your team members` 필드를 채울 수 있습니다. +4. **Configure notifications and automations** 섹션에서 메시지의 `@custom-statuspage-email@notifications.statuspage.io` 등 생성된 이메일 주소를 추가합니다. 이를 통해 **Renotification** 위에 있는 `Notify your services and your team members` 필드를 자동으로 채울 수 있습니다. 5. 모니터 알림 섹션을 작성하고 `Shopist Checkout Functionality` 등 모니터 이름에 요약을 추가합니다. 6. 모니터 재알림 조건을 설정하고 `service:status-page` 등 태그를 추가하세요. 7. 팀을 선택하고 모니터에 우선순위를 할당하세요. diff --git a/content/ko/monitors/types/service_check.md b/content/ko/monitors/types/service_check.md index 8213a4b1e8683..cfd0777044160 100644 --- a/content/ko/monitors/types/service_check.md +++ b/content/ko/monitors/types/service_check.md @@ -7,11 +7,11 @@ description: 임의 서비스 검사 상태를 모니터링합니다. further_reading: - link: /monitors/notify/ tag: 설명서 - text: Configure your monitor notifications + text: 모니터 알림 설정 - link: /monitors/downtimes/ tag: 설명서 - text: Schedule a downtime to mute a monitor -- link: /monitors/manage/status/ + text: 모니터 음소거를 위한 다운타임 시간 예약 +- link: /모니터/상태/ tag: 설명서 text: 모니터 상태를 확인하세요 title: 서비스 검사 모니터 @@ -43,24 +43,24 @@ Datadog에서 [서비스 검사 모니터][6]를 생성하려면 기본 탐색 {{< tabs >}} {{% tab "Check Alert" %}} -검사 알림은 검사 그룹별로 제출된 연속 상태를 추적하고 이를 임계값과 비교합니다. +검사 알림은 검사 그룹별로 제출된 연속 상태를 추적하고 이를 임계값과 비교합니다. 검사 알림 설정 1. 검사를 보고하는 각 ``에 대해 별도의 알림을 트리거합니다. * 검사 그룹화는 알려진 그룹화 목록에서 또는 사용자가 지정합니다. 서비스 검사 모니터의 경우 검사별 그룹화가 명시되지 않으므로 직접 지정해야 합니다. -2. 선택한 장애가 연속적으로 발생하면 경고를 트리거합니다:`` - * 알림을 트리거하는 `CRITICAL` 상태의 연속 실행 횟수를 선택합니다. 예를 들어 검사가 실패할 때 즉시 알림을 받으려면 `1` 위험 상태에 대한 모니터 경고를 트리거합니다. +2. 연속 실패 횟수를 선택하여 알림을 트리거합니다:`` + * 알림을 트리거하는 `CRITICAL` 상태의 연속 실행 횟수를 선택합니다. 예를 들어 검사가 실패할 때 즉시 알림을 받으려면 `1` 위험 상태에 대한 모니터 알림을 트리거합니다. 3. Unknown 상태에 대해 `Do not notify` 또는 `Notify`를 선택합니다. * `Notify`를 선택하면 `UNKNOWN`으로 전환될 때 알림을 트리거합니다. [모니터 상태 페이지][1]에서 `UNKNOWN` 상태에 있는 그룹의 상태 표시줄은 `NODATA` 회색을 사용합니다. 모니터의 전반적인 상태는 `OK`로 유지됩니다. 4. 연속 성공 횟수를 선택하여 알림을 해결합니다: `` - * 알림을 해결하는 `OK` 상태의 연속 실행 횟수를 선택합니다. 예를 들어 문제가 해결되었는지 확인하려면 `4``OK`상태에서 모니터를 해결합니다. + * 알림을 해결하는 `OK` 상태의 연속 실행 횟수를 선택합니다. 예를 들어 문제가 해결되었는지 확인하려면 `4``OK` 상태에서 모니터를 해결합니다. -[1]: /ko/monitors/manage/status +[1]: /ko/monitors/status {{% /tab %}} {{% tab "Cluster Alert" %}} @@ -70,24 +70,24 @@ Datadog에서 [서비스 검사 모니터][6]를 생성하려면 기본 탐색 {{< img src="monitors/monitor_types/process_check/cluster_check_thresholds.png" alt="클러스터 검사 임계값" style="width:90%;">}} -예를 들어, 환경별로 그룹화된 클러스터 검사 모니터는 환경에 대한 검사 중 70% 이상이 `CRITICAL` 상태를 제출하면 알림을 트리거할 수 있고, 환경에 대한 검사 중 70% 이상이 `WARN` 상태를 제출하면 경고할 수 있습니다. +예를 들어, 환경별로 그룹화된 클러스터 검사 모니터는 환경에 대한 검사 중 70% 이상이 `CRITICAL` 상태를 제출하면 알림을 트리거할 수 있고, 환경에 대한 검사 중 70% 이상이 `WARN` 상태를 제출하면 경고할 수 있습니다. 클러스터 알림을 설정하려면: 1. 태그에 따라 검사를 그룹화할지를 결정합니다. `Ungrouped`는 모든 소스의 상태 비율을 계산합니다. `Grouped`는 그룹별로 상태 비율을 계산합니다. -2. 알림 및 알림 임계값의 백분율을 선택합니다. 하나의 설정(알림 또는 경고)만 필요합니다. +2. 알림 및 경고 임계값의 백분율을 선택합니다. 하나의 설정(알림 또는 경고)만 필요합니다. {{% /tab %}} {{< /tabs >}} -#### 고급 경고 조건 +#### 고급 알림 조건 -[데이터 없음][8], [자동 해결][9] 및 [새 그룹 지연][10] 옵션에 대한 자세한 내용은 [모니터 설정][7] 설명서를 참조하세요. +[데이터 없음][8], [자동 해결][9], [새 그룹 지연][10] 옵션에 대한 자세한 내용은 [모니터 설정][7] 설명서를 참조하세요. ### 알림 -**Say what's happening** 및 **Notify your team** 섹션에 대한 자세한 지침은 [알림][11] 페이지를 참조하세요. +**알림 및 자동화 설정하기** 섹션에 관한 자세한 지침은 [알림][11] 페이지를 참조하세요. ## 참고 자료 diff --git a/content/ko/observability_pipelines/legacy/architecture/capacity_planning_scaling.md b/content/ko/observability_pipelines/legacy/architecture/capacity_planning_scaling.md new file mode 100644 index 0000000000000..f4893af5c378e --- /dev/null +++ b/content/ko/observability_pipelines/legacy/architecture/capacity_planning_scaling.md @@ -0,0 +1,101 @@ +--- +aliases: +- /ko/observability_pipelines/architecture/capacity_planning_scaling/ +title: (레거시) 용량 계획 및 확장 +--- + +{{< site-region region="gov" >}} +
Observability Pipelines는 US1-FED Datadog 사이트에서 사용할 수 없습니다.
+{{< /site-region >}} + +
+본 지침은 대규모 프로덕션 수준 배포용입니다. +
+ +## 예측을 위한 유닛 + +다음은 예상 리소스 용량을 계산하기 위해 시작 지점이 되는 유닛입니다. 그러나 워크로드에 따라 다를 수 있습니다. + +| 단위 | 크기 | Observability Pipelines Worker 처리량*| +| ----------------------| --------- | ----------------------------------------- | +| 구조화되지 않은 로그 이벤트| ~512 바이트| ~10 MiB/s/vCPU | +| 구조화된 로그 이벤트 | ~1.5 KB | ~25 MiB/s/vCPU | +| 메트릭 이벤트 | ~256바이트| ~25 MiB/s/vCPU | +| 트레이스 스팬 이벤트 | ~1.5 KB | ~25 MiB/s/vCPU | + +*이 수치는 예상값을 내기 위해 보수적으로 잡은 것입니다. vCPU 1개 = ARM 물리적 CPU 1개와 Intel 물리적 CPU 0.5개 + +## 확장 + +### 수평적 확장 + +수평적 확장이란 여러 Observability Pipelines Worker 인스턴스에 트래픽을 분산하는 것을 뜻합니다. Observability Pipelines Worker는 아무것도 공유하지 않는 아키텍처를 갖추고 있고, 확장할 때 복잡한 리더 노드나 다른 조정 작업이 필요 없습니다. + +푸시 기반 소스의 경우, Observability Pipelines Worker 인스턴스들을 네트워크 로드 밸런서와 함께 구성하고 필요에 따라 확장 및 축소하세요.  + +{{< img src="observability_pipelines/production_deployment_overview/horizontal_scaling_push.png" alt="클라우드 영역을 에이전트, 네트워크 로드 밸런서, Observability Pipelines Worker 애그리게이터 나눠 표현한 다이어그램. 에이전트에서 나온 데이터는 로드 밸런서, Observability Pipelines Worker로 전송된 후, 다른 대상으로 이동" style="width:60%;" >}} + +로드 밸런서는 풀 기반 소스에 필요하지 않습니다. Observability Pipelines Worker를 배포한 후 상황에 맞게 확장하거나 축소하세요. Observability Pipelines Worker에서 읽기를 요청하면 게시-구독 시스템에서 데이터 전용 액세스를 부여합니다. + +{{< img src="observability_pipelines/production_deployment_overview/horizontal_scaling_pull.png" alt="클라우드 영역을 에이전트, 브로커, Observability Pipelines 애그리게이터로 나눠 표현한 다이어그램. 에이전트에서 나온 데이터가 브로커로 전송되고, 이후 브로커와 Observability Pipelines Worker 간에 송수신되며, 마지막으로 Worker에서 다른 대상으로 전송됨." style="width:60%;" >}} + +혼합 워크로드(푸시 및 풀 기반 소스)에 대한 자세한 내용은 [고급 설정][1]을 참조하세요. + +#### 로드 밸런싱 + +에이전트와 같은 푸시 기반 소스에만 로드 밸런서가 필요합니다. Kafka와 같은 풀 기반 소스만 사용할 경우에는 로드 밸런서가 필요 없습니다. + +##### 클라이언트측 로드 밸런싱 + +클라이언트측 로드 밸런싱을 권장하지 않습니다. 클라이언트측 로드 밸런싱은 클라이언트에서 여러 Observability Pipelines Worker 인스턴스로 트래픽을 로드 밸런싱한다는 뜻입니다. 이 방법이 간단하게 보이지만, 실제로는 안정성이 떨어지고 더 복잡할 수 있습니다. 그 이유는 다음과 같습니다. + +- 적절한 장애 조치가 있는 로드 밸런싱은 복잡합니다. 이 영역의 문제는 데이터 손실이나 서비스에 영향을 미치는 인시던트로 이어질 수 있기 때문에 민감합니다. 또 여러 유형의 클라이언트가 있으면 더욱 복잡해집니다. +- Observability Pipelines Worker Aggregator의 목적은 에이전트의 책임을 분산시키는 것이며, 로드 밸런싱으로 이를 지원할 수 있습니다. + +##### 로드 밸런서 유형 + +Datadog은 Observability Pipelines Worker 프로토콜(TCP, UDP, HTTP)을 지원하는 Layer 4(L4) 로드 밸런서(네트워크 로드 밸런서) 사용을 권고합니다. HTTP 트래픽(Layer 7)만 전송하는 경우에도 성능과 간편함의 측면을 고려할 때 L4 로드 밸런서를 사용하는 것이 좋습니다. + +| 클라우드 공급자| 추천 | +| ------------- | --------------------------------------------------------------| +| AWS | AWS Network Load Balancer(NLB) | +| Azure | Internal Azure Load Balancer | +| Google Cloud | Internal TCP/UDP Network Load Balancer | +| 프라이빗 | HAProxy, NGINX, 또는 Layer-4 지원 기타 로드 밸런서 | + +##### 로드 밸런서 구성 + +Datadog에서는 클라이언트와 로드 밸런서를 구성할 때 다음과 같은 일반 설정을 권장합니다. + +- 간단한 라운드 로빈 로드 밸런싱 전략을 사용하세요. +- 영역 간 트래픽 불균형이 심할 경우를 제외하고 교차 영역 로드 밸런싱을 사용하지 마세요. +- 대상 상태를 확인을 위해 Observability Pipelines Worker의 API 엔드포인트를 사용해 로드 밸런서를 구성하세요. +- Observability Pipelines Worker 인스턴스 확장 시 자동으로 등록/등록 해제되도록 합니다. 자세한 내용은 [네트워킹][2]을 참조하세요. +- 클라이언트와 로드 밸런서 모두에서 유휴 시간 초과를 1분 이하로 설정하세요. +- 가능할 경우 에이전트에서 연결 동시성 및 풀링을 활성화하세요. 지원되지 않을 경우에는 마지막 단계에 Observability Pipelines Worker를 배포하는 통합 아키텍처를 사용하는 것을 고려해 보세요. 연결 풀링을 사용하면 대량의 데이터가 여러 연결을 통해 분산되도록 하여 트래픽 균형을 맞추는 데 도움을 줍니다. + +##### 로드 밸런서 핫 스팟 + +로드 밸런싱 핫 스팟은 하나 이상의 Observability Pipelines Worker 인스턴스에서 너무 많은 트래픽을 수신할 때 발생합니다. 다음 두 이유의 하나로 핫 스팟이 발생합니다. + +1. 연결 하나에 대량 트래픽이 전송되는 경우 +2. 하나의 가용 영역이 다른 가용 영역에 비해 트래픽이 너무 높은 경우 + +이와 같은 상황이 발생할 경우, 다음 해결 방법을 사용하는 것이 좋습니다. + +1. 규모가 큰 연결 하나를 여러 연결로 분할합니다. 대부분의 클라이언트가 데이터를 여러 연결로 분산할 수 있는 동시 연결성과 풀링을 허용합니다. 이와 같은 방법을 사용하면 로드 밸런서가 여러 Observability Pipelines Worker 인스턴스로 연결을 분산할 수 있습니다. 클라이언트에서 이를 지원하지 않을 경우 통합 아키텍처를 사용할 수 있습니다. 통합 아키텍처를 사용하면 마지막 단계에서 Observability Pipelines Worker를 추가로 배포할 수 있습니다. +2. 로드 밸런서에 교차 영역 로드 밸런싱을 활성화하세요. 교차 영역 밸런싱을 이용하면 가용 영역 전체에 있는 트래픽을 Observability Pipelines Worker 인스턴스 전체로 분산하여 균형을 맞춥니다. + +### 수직적 확장 + +Observability Pipelines Worker의 동시성 모델은 자동으로 vCPU를 모두 사용해 확장합니다. 동시성 설정이나 구성 변경이 따로 필요 없습니다. Datadog에서는 수직적 확장을 할 때 처리하는 인스턴스의 크기를 총 볼륨의 50%를 넘지 않도록 제한하고, 가용성을 높이기 위해 최소 2개의 Observability Pipelines Worker 인스턴스로 배포하는 것을 권고합니다. + +### Autoscaling + +Autoscaling은 평균 CPU 사용률을 기준으로 해야 합니다. 대부분의 주요 워크로드에서 Observability Pipelines Worker는 CPU의 제약을 받습니다. CPU 사용률은 오탐 신호를 보내지 않기 때문에 Autoscaling에 사용할 수 있는 가장 유용한 신호입니다. Datadog은 다음 설정을 이용하고 필요에 따라 조정할 것을 권장합니다. + +- 평균 CPU 사용률 85%를 목표로 설정합니다. +- 확장 및 축소 안정화 시간 5분 + +[1]: /ko/observability_pipelines/legacy/architecture/advanced_configurations +[2]: /ko/observability_pipelines/legacy/architecture/networking \ No newline at end of file diff --git a/content/ko/observability_pipelines/legacy/guide/_index.md b/content/ko/observability_pipelines/legacy/guide/_index.md new file mode 100644 index 0000000000000..8d4319437537c --- /dev/null +++ b/content/ko/observability_pipelines/legacy/guide/_index.md @@ -0,0 +1,20 @@ +--- +aliases: +- /ko/integrations/observability_pipelines/guide/ +- /ko/observability_pipelines/guide/custom-metrics-governance +cascade: + algolia: + category: 가이드 + rank: 20 + subcategory: Observability Pipelines 가이드 +disable_toc: true +private: true +title: (레거시) Observability Pipelines 가이드 +--- + +{{< whatsnext desc="일반 가이드:" >}} + {{< nextlink href="/observability_pipelines/legacy/setup/splunk" >}}Splunk 환경에서 Observability Pipelines 설정{{< /nextlink >}} + {{< nextlink href="/observability_pipelines/legacy/guide/control_log_volume_and_size" >}}로그 볼륨 및 크기 제어{{< /nextlink >}} + {{< nextlink href="/observability_pipelines/legacy/guide/ingest_aws_s3_logs_with_the_observability_pipelines_worker" >}}Observability Pipelines Worker로 Amazon S3 로그 수집{{< /nextlink >}} + {{< nextlink href="/observability_pipelines/legacy/guide/route_logs_in_datadog_rehydratable_format_to_amazon_s3/" >}}Datadog-Rehydratable 형식 로그를 Amazon S3로 라우팅{{< /nextlink >}} +{{< /whatsnext >}} \ No newline at end of file diff --git a/content/ko/observability_pipelines/sensitive_data_redaction/http_client.md b/content/ko/observability_pipelines/sensitive_data_redaction/http_client.md new file mode 100644 index 0000000000000..3051701c02bf6 --- /dev/null +++ b/content/ko/observability_pipelines/sensitive_data_redaction/http_client.md @@ -0,0 +1,231 @@ +--- +disable_toc: false +title: HTTP Client용 민감한 데이터 삭제 +--- + +## 개요 + +신용 카드 번호, 은행 라우팅 번호, API 키와 같은 민감한 데이터는 종종 로그에 의도치 않게 노출되어 조직을 재무 및 프라이버시 위험에 노출시킬 수 있습니다. + +Observability Pipelines로 다른 대상 및 인프라스트럭처 외부로 로그를 라우팅하기 전에 민감한 정보를 식별하고 태그를 설정하거나 옵션으로 삭제하거나 해싱할 수 있습니다. 기본 제공 스캔 규칙으로 이메일 주소, 신용카드 번호, API 키, 인증 토큰 등과 같은 일반 패턴을 감지할 수 있습니다. 또는 정규식 패턴으로 커스텀 스캔 규칙을 생성하고 매칭을 통해 민감한 정보를 식별할 수 있습니다. + +{{% observability_pipelines/use_case_images/sensitive_data_redaction %}} + +본 문서에서는 다음 단계를 안내합니다. +1. Observability Pipelines를 설정하는 데 필요한 [사전 필수 조건](#prerequisites) +1. [Observability Pipelines 설정하기](#set-up-observability-pipelines) + +## 사전 필수 조건 + +{{% observability_pipelines/prerequisites/http_client %}} + +## Observability Pipelines 설정 + +1. [Observability Pipelines][1]로 이동합니다. +1. **Sensitive Data Redactions** 템플릿을 선택하여 새 파이프라인을 생성합니다. +1. 소스로 **HTTP Client**를 선택합니다. + +### 소스 설정하기 + +{{% observability_pipelines/source_settings/http_client%}} + +### 대상 설정하기 + +선택한 로그 대상에 따라 다음 정보를 입력합니다. + +{{< tabs >}} +{{% tab "Datadog" %}} + +{{% observability_pipelines/destination_settings/datadog %}} + +{{% /tab %}} +{{% tab "Splunk HEC" %}} + +{{% observability_pipelines/destination_settings/splunk_hec %}} + +{{% /tab %}} +{{% tab "Sumo Logic" %}} + +{{% observability_pipelines/destination_settings/sumo_logic %}} + +{{% /tab %}} +{{% tab "Syslog" %}} + +{{% observability_pipelines/destination_settings/syslog %}} + +{{% /tab %}} +{{% tab "Chronicle" %}} + +{{% observability_pipelines/destination_settings/chronicle %}} + +{{% /tab %}} +{{% tab "Elasticsearch" %}} + +{{% observability_pipelines/destination_settings/elasticsearch %}} + +{{% /tab %}} +{{% tab "OpenSearch" %}} + +{{% observability_pipelines/destination_settings/opensearch %}} + +{{% /tab %}} +{{% tab "Amazon OpenSearch" %}} + +{{% observability_pipelines/destination_settings/amazon_opensearch %}} + +{{% /tab %}} +{{< /tabs >}} + +### 프로세서 설정하기 + +{{% observability_pipelines/processors/intro %}} + +{{% observability_pipelines/processors/filter_syntax %}} + +{{% observability_pipelines/processors/add_processors_sds %}} + +{{< tabs >}} +{{% tab "Filter" %}} + +{{% observability_pipelines/processors/filter %}} + +{{% /tab %}} +{{% tab "Edit fields" %}} + +{{% observability_pipelines/processors/remap %}} + +{{% /tab %}} +{{% tab "Sample" %}} + +{{% observability_pipelines/processors/sample %}} + +{{% /tab %}} +{{% tab "Grok Parser" %}} + +{{% observability_pipelines/processors/grok_parser %}} + +{{% /tab %}} +{{% tab "Quota" %}} + +{{% observability_pipelines/processors/quota %}} + +{{% /tab %}} +{{% tab "Reduce" %}} + +{{% observability_pipelines/processors/reduce %}} + +{{% /tab %}} +{{% tab "Dedupe" %}} + +{{% observability_pipelines/processors/dedupe %}} + +{{% /tab %}} +{{% tab "Sensitive Data Scanner" %}} + +{{% observability_pipelines/processors/sensitive_data_scanner %}} + +{{% /tab %}} +{{% tab "Add hostname" %}} + +{{% observability_pipelines/processors/add_hostname %}} + +{{% /tab %}} +{{% tab "Parse JSON" %}} + +{{% observability_pipelines/processors/parse_json %}} + +{{% /tab %}} +{{% tab "Enrichment table" %}} + +{{% observability_pipelines/processors/enrichment_table %}} + +{{% /tab %}} +{{< /tabs >}} + +## Observability Pipelines Worker 설치하기 +1. **Choose your installation platform** 드롭다운 메뉴에서 플랫폼을 선택합니다. +1. HTTP/S 엔드포인트 URL의 전체 경로를 입력합니다(예: `https://127.0.0.8/logs`). Observability Pipelines Worker는 이 엔드포인트에서 로그 이벤트를 수집합니다. + +1. 선택한 각 대상의 환경 변수를 입력합니다. 자세한 내용은 [사전 필수 조건](#prerequisites)을 참조하세요. +{{< tabs >}} +{{% tab "Datadog" %}} + +{{% observability_pipelines/destination_env_vars/datadog %}} + +{{% /tab %}} +{{% tab "Splunk HEC" %}} + +{{% observability_pipelines/destination_env_vars/splunk_hec %}} + +{{% /tab %}} +{{% tab "Sumo Logic" %}} + +{{% observability_pipelines/destination_env_vars/sumo_logic %}} + +{{% /tab %}} +{{% tab "Syslog" %}} + +{{% observability_pipelines/destination_env_vars/syslog %}} + +{{% /tab %}} +{{% tab "Chronicle" %}} + +{{% observability_pipelines/destination_env_vars/chronicle %}} + +{{% /tab %}} +{{% tab "Elasticsearch" %}} + +{{% observability_pipelines/destination_env_vars/elasticsearch %}} + +{{% /tab %}} +{{% tab "OpenSearch" %}} + +{{% observability_pipelines/destination_env_vars/opensearch %}} + +{{% /tab %}} +{{% tab "Amazon OpenSearch" %}} + +{{% observability_pipelines/destination_env_vars/amazon_opensearch %}} + +{{% /tab %}} +{{< /tabs >}} +1. 환경에 맞는 지침에 따라 Worker를 설치합니다. +{{< tabs >}} +{{% tab "Docker" %}} + +{{% observability_pipelines/install_worker/docker %}} + +{{% /tab %}} +{{% tab "Amazon EKS" %}} + +{{% observability_pipelines/install_worker/amazon_eks %}} + +{{% /tab %}} +{{% tab "Azure AKS" %}} + +{{% observability_pipelines/install_worker/azure_aks %}} + +{{% /tab %}} +{{% tab "Google GKE" %}} + +{{% observability_pipelines/install_worker/google_gke %}} + +{{% /tab %}} +{{% tab "Linux (APT)" %}} + +{{% observability_pipelines/install_worker/linux_apt %}} + +{{% /tab %}} +{{% tab "Linux (RPM)" %}} + +{{% observability_pipelines/install_worker/linux_rpm %}} + +{{% /tab %}} +{{% tab "CloudFormation" %}} + +{{% observability_pipelines/install_worker/cloudformation %}} + +{{% /tab %}} +{{< /tabs >}} + +[1]: https://app.datadoghq.com/observability-pipelines \ No newline at end of file diff --git a/content/ko/opentelemetry/integrations/collector_health_metrics.md b/content/ko/opentelemetry/integrations/collector_health_metrics.md new file mode 100644 index 0000000000000..b69a992e646da --- /dev/null +++ b/content/ko/opentelemetry/integrations/collector_health_metrics.md @@ -0,0 +1,133 @@ +--- +aliases: +- /ko/opentelemetry/collector_exporter/collector_health_metrics +further_reading: +- link: /opentelemetry/collector_exporter/ + tag: 설명서 + text: OpenTelemetry 설정 컬렉터(Collector) +title: 서비스 상태 메트릭 +--- + +## 개요 + +{{< img src="/opentelemetry/collector_exporter/collector_health_metrics.png" alt="OpenTelemetry 컬렉터 서비스 상태 메트릭 대시보드" style="width:100%;" >}} + +OpenTelemetry 컬렉터 자체에서 서비스 상태 메트릭을 수집하려면, Datadog 탐색기에서 [Prometheus 리시버][1]를 설정합니다. + +자세한 내용을 확인하려면 [Prometheus 리시버][1]용 OpenTelemetry 프로젝트 설명서를 참조하세요. + +## 설정 + +컬렉터(Collector) 설정에 다음 줄을 추가합니다. + +```yaml +receivers: + prometheus: + config: + scrape_configs: + - job_name: 'otelcol' + scrape_interval: 10s + static_configs: + - targets: ['0.0.0.0:8888'] +``` + +## 수집한 데이터 + +| OpenTelemetry 메트릭 | 설명 | +|---|---| +| `otelcol_process_uptime` | 프로세스 업타임 | +| `otelcol_process_memory_rss` | 물리적 메모리 총량(레지던트 세트 크기) | +| `otelcol_exporter_queue_size` | 재시도 대기열의 현재 크기(일괄 처리) | +| `otelcol_exporter_sent_spans` | 대상에게 전송 완료된 스팬(span) 개수 | +| `otelcol_exporter_send_failed_metric_points` | 대상에게 전송 실패한 메트릭 포인트 개수 | +| `otelcol_exporter_send_failed_spans` | 대상에게 전송 실패한 스팬(span) 개수 | +| `otelcol_process_cpu_seconds` | CPU 사용자 및 시스템 시간 총계(초) | +| `otelcol_receiver_refused_spans` | 파이프라인으로 푸시할 수 없는 스팬(span)의 개수 | +| `otelcol_exporter_queue_capacity` | 재시도 대기열의 고정 수용량(일괄 처리) | +| `otelcol_receiver_accepted_spans` | 파이프라인으로 푸시한 스팬(span)의 개수 | +| `otelcol_exporter_sent_metric_points` | 대상에게 전송 완료된 메트릭 포인트 개수 | +| `otelcol_exporter_enqueue_failed_spans` | 전송 대기열에 추가 실패한 스팬(span)의 개수 | +| `otelcol_scraper_errored_metric_points` | 스크랩에 실패한 메트릭 포인트 개수 | +| `otelcol_scraper_scraped_metric_points` | 스크랩 완료한 메트릭 포인트 개수 | +| `otelcol_receiver_refused_metric_points` | 파이프라인으로 푸시할 수 없는 메트릭 포인트 개수 | +| `otelcol_receiver_accepted_metric_points` | 파이프라인으로 푸시한 메트릭 포인트 개수 | +| `otelcol_process_runtime_heap_alloc_bytes` | 할당된 힙(heap) 오브젝트 바이트('go doc runtime.MemStats.HeapAlloc' 참조) | +| `otelcol_process_runtime_total_alloc_bytes` | 힙 객체에 할당된 누적 바이트('go doc runtime.MemStats.TotalAlloc' 참조) | +| `otelcol_exporter_enqueue_failed_log_records` | 전송 대기열에 추가 실패한 로그 레코드 개수 | +| `otelcol_processor_batch_timeout_trigger_send` | 시간 초과 트리거로 인해 배치가 전송된 횟수 | +| `otelcol_exporter_enqueue_failed_metric_points` | 전송 대기열에 추가 실패한 메트릭 포인트 개수 | +| `otelcol_process_runtime_total_sys_memory_bytes` | OS에서 확보한 메모리 바이트 총계([ `runtime.MemStats.Sys`][3]의 Go 문서 참조) | +| `otelcol_processor_batch_batch_size_trigger_send` | 사이즈 트리거로 인해 배치가 전송된 횟수 | +| `otelcol_exporter_sent_log_records` | 대상에게 전송 완료된 로그 레코드 개수 | +| `otelcol_receiver_refused_log_records` | 파이프라인으로 푸시할 수 없는 로그 레코드 개수 | +| `otelcol_receiver_accepted_log_records` | 파이프라인으로 푸시한 로그 레코드 개수 | + + +## 전체 예제 설정 + +Datadog 내보내기를 사용한 전체 작업 예제 설정을 확인하려면 [`collector-metrics.yaml`][2]을 참조하세요. + +## 로깅 출력 예시 + +``` +ResourceMetrics #0 +Resource SchemaURL: https://opentelemetry.io/schemas/1.6.1 +Resource attributes: + -> service.name: Str(opentelemetry-collector) + -> net.host.name: Str(192.168.55.78) + -> service.instance.id: Str(192.168.55.78:8888) + -> net.host.port: Str(8888) + -> http.scheme: Str(http) + -> k8s.pod.ip: Str(192.168.55.78) + -> cloud.provider: Str(aws) + -> cloud.platform: Str(aws_ec2) + -> cloud.region: Str(us-east-1) + -> cloud.account.id: Str(XXXXXXXXX) + -> cloud.availability_zone: Str(us-east-1c) + -> host.id: Str(i-0368add8e328c28f7) + -> host.image.id: Str(ami-08a2e6a8e82737230) + -> host.type: Str(m5.large) + -> host.name: Str(ip-192-168-53-115.ec2.internal) + -> os.type: Str(linux) + -> k8s.pod.name: Str(opentelemetry-collector-agent-gqwm8) + -> k8s.daemonset.name: Str(opentelemetry-collector-agent) + -> k8s.daemonset.uid: Str(6d6fef61-d4c7-4226-9b7b-7d6b893cb31d) + -> k8s.node.name: Str(ip-192-168-53-115.ec2.internal) + -> kube_app_name: Str(opentelemetry-collector) + -> kube_app_instance: Str(opentelemetry-collector) + -> k8s.namespace.name: Str(otel-staging) + -> k8s.pod.start_time: Str(2023-11-20T12:53:23Z) + -> k8s.pod.uid: Str(988d1bdc-5baf-4e98-942f-ab026a371daf) +ScopeMetrics #0 +ScopeMetrics SchemaURL: +InstrumentationScope otelcol/prometheusreceiver 0.88.0-dev +Metric #0 +Descriptor: + -> Name: otelcol_otelsvc_k8s_namespace_added + -> Description: Number of namespace add events received + -> Unit: + -> DataType: Sum + -> IsMonotonic: true + -> AggregationTemporality: Cumulative +NumberDataPoints #0 +Data point attributes: + -> service_instance_id: Str(d80d11f9-aa84-4e16-818d-3e7d868c0cfe) + -> service_name: Str(otelcontribcol) + -> service_version: Str(0.88.0-dev) +StartTimestamp: 1970-01-01 00:00:00 +0000 UTC +Timestamp: 2023-11-20 13:17:36.881 +0000 UTC +Value: 194151496.000000 +Metric #9 +Descriptor: + -> Name: otelcol_receiver_accepted_spans + -> Description: Number of spans successfully pushed into the pipeline. + -> Unit: + -> DataType: Sum + -> IsMonotonic: true + -> AggregationTemporality: Cumulative +``` + + +[1]: https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/prometheusreceiver +[2]: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/exporter/datadogexporter/examples/collector-metrics.yaml +[3]: https://pkg.go.dev/runtime#MemStats.Sys \ No newline at end of file diff --git a/content/ko/product_analytics/session_replay/_index.md b/content/ko/product_analytics/session_replay/_index.md new file mode 100644 index 0000000000000..d6642c5eb9446 --- /dev/null +++ b/content/ko/product_analytics/session_replay/_index.md @@ -0,0 +1,65 @@ +--- +aliases: +- /ko/real_user_monitoring/guide/session-replay-getting-started/ +description: Session Replay를 사용해 사용자의 웹 브라우징이나 모바일 웹 경험을 캡처하고 시각적으로 재생하는 방법을 알아보세요. +further_reading: +- link: https://www.datadoghq.com/blog/session-replay-datadog/ + tag: 블로그 + text: Datadog 세션 재생을 사용하여 실시간 사용자 여정 보기 +- link: https://www.datadoghq.com/blog/reduce-customer-friction-funnel-analysis/ + tag: 블로그 + text: Funnel 분석으로 주요 사용자 플로를 이해하고 최적화 +- link: https://www.datadoghq.com/blog/zendesk-session-replay-integration/ + tag: 블로그 + text: Zendesk 및 Datadog Session Replay를 통해 사용자가 경험하는 문제를 시각적으로 재현합니다. +- link: /integrations/content_security_policy_logs + tag: 설명서 + text: Datadog으로 CSP 위반 감지 및 집계 +title: 사용자 행동 다시 보기 +--- + + +## 개요 + +Session Replay는 사용자의 웹 브라우징이나 모바일 앱 경험을 시각적으로 캡처하고 재생할 수 있도록 함으로써 사용자 경험 모니터링을 확장합니다. RUM 성능 데이터와 결합된 Session Replay는 오류 식별/재생산/해결에 유용하며 애플리케이션 사용 패턴과 설계적 결함에 대한 인사이트를 제공합니다. + +## Browser Session Replay + +Browser Session Replay는 사용자의 웹 브라우징 경험을 캡처하고 시각적으로 재생할 수 있도록 함으로써 사용자 경험 모니터링을 확대합니다. RUM 성능 데이터와 결합하면 Session Replay는 오류 식별/재생산/해결에 유용하며 웹 애플리케이션의 사용량 패턴과 디자인 결함에 대한 인사이트를 제공합니다. + +RUM Browser SDK는 [오픈 소스][1]이며 오픈 소스 [rrweb][2] 프로젝트를 활용합니다. + +[브라우저를 위한 Session Replay][3]에 대해 자세히 알아보세요. + +## 모바일 세션 리플레이 + +모바일 세션 리플레이는 탭, 스와이프, 스크롤과 같은 각 사용자 상호 작용을 시각적으로 재생하여 모바일 애플리케이션에 대한 가시성을 확장합니다. Android 및 iOS의 네이티브 앱에서 사용할 수 있습니다. 애플리케이션에서 사용자 상호 작용을 시각적으로 재생하면 충돌과 오류를 쉽게 재현할 수 있을 뿐만 아니라 UI 개선을 위한 사용자 경험을 파악할 수 있습니다. + +[모바일을 위한 Session Replay][4]에 대해 자세히 알아보세요. + +## 재생 기록 + +플레이어 페이지에 표시된 **watched** 횟수를 클릭하면 해당 세션 리플레이를 누가 시청했는지 확인할 수 있습니다. 이 기능을 사용하면 녹화 내용을 공유하려고 했던 사람이 이미 해당 내용을 시청했는지 확인할 수 있습니다. + +{{< img src="real_user_monitoring/session_replay/session-replay-playback-history.png" alt="세션 녹화를 본 사람 확인" style="width:100%;" >}} + +기록은 플레이어 페이지 또는 [노트북][5]이나 사이드 패널과 같은 내장 플레이어에서 발생한 플레이백만을 포함합니다. 포함된 플레이백은 또한 [감사 트레일][6] 이벤트를 생성합니다. 썸네일 미리 보기는 기록에 포함되지 않습니다. + +내 플레이백 기록을 보려면, [내 기록 보기][7] 재생 목록을 확인하세요. + +## 플레이리스트 + +Session Replay 재생 목록을 생성해 발견한 패턴별로 정리할 수 있습니다. [Session Replay 재생 목록][8]을 자세히 알아보세요. + +## 참고 자료 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://github.com/DataDog/browser-sdk +[2]: https://www.rrweb.io/ +[3]: /ko/product_analytics/session_replay/browser/ +[4]: /ko/product_analytics/session_replay/mobile/ +[5]: https://docs.datadoghq.com/ko/notebooks/ +[6]: https://docs.datadoghq.com/ko/account_management/audit_trail/ +[7]: https://app.datadoghq.com/rum/replay/playlists/my-watch-history +[8]: /ko/product_analytics/session_replay/playlists \ No newline at end of file diff --git a/content/ko/profiler/automated_analysis.md b/content/ko/profiler/automated_analysis.md new file mode 100644 index 0000000000000..22d9964747e57 --- /dev/null +++ b/content/ko/profiler/automated_analysis.md @@ -0,0 +1,74 @@ +--- +description: 상황별 인사이트와 다음 단계 추천을 제시하고 중대 오류를 자동으로 표시 +further_reading: +- link: profiler/enabling + tag: 설명서 + text: 애플리케이션에 대해 지속적 프로파일러 사용 +- link: getting_started/profiler + tag: 설명서 + text: 프로파일러 시작하기 +- link: https://www.datadoghq.com/blog/introducing-datadog-profiling/ + tag: 블로그 + text: DataDog에 상시 가동 프로덕션 프로파일링 도입 +- link: https://www.datadoghq.com/blog/continuous-profiler-timeline-view/ + tag: 블로그 + text: Continuous Profiler의 타임라인 뷰를 사용해 런타임 및 코드 비효율성 진단 +title: Automated Analysis +--- +{{< callout url="https://www.datadoghq.com/product-preview/automated-analysis/" btn_hidden="false" header="체험판 신청하기" >}} +Automated Analysis는 현재 체험판 버전입니다. +{{< /callout >}} + +## 개요 +Automated Analysis는 Continuous Profiler 데이터를 사용하여 애플리케이션의 성능 문제를 자동으로 감지하고 실행 가능한 해결 인사이트를 제공합니다. 문제가 감지되면 Automated Analysis는 다음을 제공합니다. + +- 문제와 해당 문제가 중요한 이유를 설명하는 개괄적 요약 +- 프로파일링 데이터에서 얻은 상황별 인사이트(예: 영향을 받는 메서드, 패키지 또는 프로세스) +- 문제 해결에 도움이 되는 다음 단계 권장 사항 + +발견하지 못할 수도 있는 애플리케이션의 성능 문제를 식별하고 이를 해결하는 데 필요한 프로파일링 전문성을 줄입니다. + +{{< img src="profiler/profiling_automated_analysis.png" alt="발생 예외 인사이트가 표시된 Profiler 스레드 타임라인" style="width:100%;" >}} + +## 인사이트 살펴보기 +[Profile Explorer][1]에서 Automated Analysis에 액세스합니다. 다음 인사이트가 표시됩니다. + +- 특정 서비스로 범위가 지정되면 Page 상단의 **Top Insights** 배너에서 다음을 확인할 수 있습니다. +{{< img src="profiler/profiling_automated_analysis_banner.png" alt="Automated Analysis 배너, 지정된 서비스에 대해 탐지된 인사이트가 표시됨" style="width:100%;">}} + +- 서비스 목록의 **Insights** 열에 다음과 같이 표시됩니다. +{{< img src="profiler/profiling_automated_analysis_column.png" alt="Automated Analysis 열, 서비스 목록 내 지정된 서비스와 관련하여 탐지된 인사이트가 표시됨" style="width:100%;">}} + +- 플레임 그래프 보기 내에서는 다음과 같이 표시됩니다. +{{< img src="profiler/profiling_automated_analysis_flamegraph_viz.png" alt="Automated Analysis 열, 플레임 그래프 내의 지정된 서비스와 관련하여 탐지된 인사이트가 표시됨" style="width:100%;">}} + +- 타임라인 보기 내에서는 다음과 같이 표시됩니다. +{{< img src="profiler/profiling_automated_analysis.png" alt="Automated Analysis 열, 타임라인 내 지정된 서비스에 대해 탐지된 인사이트가 표시됨" style="width:100%;">}} + +인사이트를 클릭하면 문제를 설명하는 개괄적 요약, 프로파일링 데이터의 상황별 인사이트, 권장 다음 단계를 확인할 수 있습니다. +{{< img src="profiler/profiling_automated_analysis_details.png" alt="감지된 문제의 세부 사항을 보여주는 확장 프로파일링 인사이트" style="width:100%;">}} + +## 지원되는 인사이트 + +Automated Analysis는 다음 인사이트를 확인할 수 있도록 지원합니다. + +| 이름 | 심각도 | 설명 | +|---------------------------|----------|-------------| +| 중복 플래그 | Info | 런타임에 중복 플래그가 입력된 경우 트리거됩니다(예: `-Xmx2g -Xmx5g`). 이는 예상 효과가 나타나지 않는 변경으로 이어질 수 있으므로 문제가 됩니다. | +| 명시적 GC | Info | System.gc() 호출이 있는 경우 트리거됩니다. | +| GC 일시 중지 피크 지속 시간 | Info | 하나 이상의 GC 일시 중지가 1초 이상 소요될 경우 트리거됩니다. | +| GC 설정 | Info | 멀티코어 머신에서 시리얼 GC가 사용된 경우, 단일 코어 머신에서 병렬 GC가 사용된 경우, 사용 가능한 코어보다 많은 GC 스레드가 구성된 경우, 또는 병렬 GC가 1개의 스레드로 실행되도록 구성된 경우 중 하나가 발생하면 트리거됩니다. | +| HOL 차단 | Info | 큐 이벤트가 지정된 활동 뒤에서 멈춘 경우 트리거됩니다. | +| 기본 값 박싱 | Info | 기본 값<>오브젝트 값 간의 변환에 CPU 시간의 5% 이상이 소모된 경우 트리거됩니다. | +| 교착 상태의 스레드 감지 | 경고 | 쿼리 컨텍스트에 대한 최대 교착 상태 스레드 수가 0보다 클 경우 트리거됩니다. | +| GC 일시 중지 | 경고 | GC 일시 중지에 10% 이상의 시간을 소모한 경우 트리거됩니다. | +| 옵션 | 경고 | 문서화되지 않았거나 사용 중단되었거나 권장되지 않는 옵션 플래그가 감지되면 트리거됩니다. | +| 스택 깊이 설정 | 경고 | 잘린 스택트레이스가 있는 이벤트 때문에 프로파일링 데이터를 이해하기 어려우면 트리거됩니다. | +| 발생 예외(Thrown Exceptions) | 경고 | 1분당 발생하는 발생 예외(처리된 예외 및 처리되지 않은 예외)의 비율이 임계값(기본값: 1만 건)을 초과하면 트리거됩니다. | +| VMOperation 피크 지속 시간 | 경고 | 차단성 VM 작업(또는 시간상 가까운 여러 작업의 조합)이 2초를 초과해 실행될 경우 트리거됩니다. 가장 오래 걸린 작업과 관련한 세부 정보가 보고됩니다. | + +## 참고 자료 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://app.datadoghq.com/profiling/explorer \ No newline at end of file diff --git a/content/ko/profiler/guide/_index.md b/content/ko/profiler/guide/_index.md new file mode 100644 index 0000000000000..1f23aab3bcdfc --- /dev/null +++ b/content/ko/profiler/guide/_index.md @@ -0,0 +1,25 @@ +--- +disable_toc: true +further_reading: +- link: https://www.datadoghq.com/blog/request-latency-profiling/ + tag: 블로그 + text: 프로파일링을 통한 요청 지연 시간 이해 +- link: https://www.datadoghq.com/blog/engineering/how-we-optimized-our-akka-application-using-datadogs-continuous-profiler/ + tag: 블로그 + text: Continuous Profiler를 사용해 Akka 애플리케이션을 최적화하는 방법 +- link: https://www.datadoghq.com/blog/dotnet-datadog-continuous-profiler/ + tag: 블로그 + text: Continuous Profiler로 .NET 애플리케이션 성능 최적화하기 +title: Continuous Profiler 가이드 +--- + + +{{< whatsnext desc="가이드" >}} + {{< nextlink href="/profiler/guide/isolate-outliers-in-monolithic-services/" >}}모놀리식 서비스에서 이상치 격리{{< /nextlink >}} + {{< nextlink href="/profiler/guide/solve-memory-leaks/" >}}프로파일링으로 메모리 누수 해결{{< /nextlink >}} + {{< nextlink href="/profiler/guide/save-cpu-in-production-with-go-pgo/" tag="Go">}}프로파일 기반 최적화로 프로덕션 환경에서 CPU 14%까지 절약하기 {{< /nextlink >}} +{{< /whatsnext >}} + +## 참고 자료 + +{{< partial name="whats-next/whats-next.html" >}} \ No newline at end of file diff --git a/content/ko/profiler/guide/isolate-outliers-in-monolithic-services.md b/content/ko/profiler/guide/isolate-outliers-in-monolithic-services.md index 16197f807296a..3701f91c83042 100644 --- a/content/ko/profiler/guide/isolate-outliers-in-monolithic-services.md +++ b/content/ko/profiler/guide/isolate-outliers-in-monolithic-services.md @@ -110,7 +110,7 @@ pprof.Do(ctx, pprof.Labels("customer_name", ), func(context.Context) { }) ``` -필터링에 사용할 레이블 키를 지정하려면 프로파일러를 시작할 때 [WithCustomProfilerLabelKeys][2]를 추가하세요. +필터링에 사용할 레이블 키를 지정하려면 프로파일러를 시작할 때 [WithCustomProfilerLabelKeys][3] (또는[WithCustomProfilerLabelKeys v1][2]) 옵션을 추가하세요. ```go profiler.Start( @@ -123,6 +123,7 @@ profiler.Start( [1]: https://pkg.go.dev/runtime/pprof#Do [2]: https://pkg.go.dev/gopkg.in/DataDog/dd-trace-go.v1/profiler#WithCustomProfilerLabelKeys +[3]: https://pkg.go.dev/github.com/DataDog/dd-trace-go/v2/profiler#WithCustomProfilerLabelKeys {{< /programming-lang >}} {{< /programming-lang-wrapper >}} diff --git a/content/ko/quality_gates/guide/understanding_rule_scopes.md b/content/ko/quality_gates/guide/understanding_rule_scopes.md new file mode 100644 index 0000000000000..014c516a9fe4d --- /dev/null +++ b/content/ko/quality_gates/guide/understanding_rule_scopes.md @@ -0,0 +1,83 @@ +--- +description: Quality Gate 규칙 범위를 설정하는 방법을 알아봅니다. +further_reading: +- link: /quality_gates/setup + tag: 설명서 + text: Quality Gate 게이트 설정 방법 알아보기 +title: Quality Gate에서 규칙 범위 작동 방식 이해하기 +--- + +## 개요 + +Quality Gate로 Datadog에서 신호에 기반하여 워크플로의 통과를 제어할 수 있습니다. 규칙을 만들 때 규칙을 평가해야 하는 시점를 명시하는 규칙 범위를 정의할 수 있습니다. + +특정 CI 파이프라인에 관해 평가되는 규칙을 필터링하려면, 규칙을 생성할 때 커스텀 범위를 추가합니다. 이 프로세스에서는 빌드 설정에서 [`datadog-ci gate evaluate` 명령][1]과 함께 `--scope` 옵션을 사용해야 합니다. + +예시: + +```shell +datadog-ci gate evaluate --scope team:backend --scope team:frontend +``` + +## 규칙 범위 정의하기 + +`datadog-ci gate evaluate` 명령이 호출되면 명령 컨텍스트와 매칭되는 범위의 규칙이 평가됩니다. `backend` 또는 `frontend` 팀 태그가 지정된 규칙을 기준으로 필터링할 수 있습니다. + +{{< img src="ci/rule_scope_always_evaluate.png" alt="항상 평가되는 규칙에 관한 규칙 범위" style="width:80%;">}} + +각 범위(예: `branch`)에 대하여 포함 또는 제외되는 값을 선택할 수 있습니다. + +- 포함된 값을 선택한 경우, 포함된 값 중 하나 이상이 명령 컨텍스트에 포함되어 있으면 규칙이 평가됩니다. +- 제외된 값을 선택한 경우, 제외된 값이 명령 컨텍스트의 일부라면 해당 규칙은 평가되지 않습니다. + +`example-repository` 리포지토리의 `main`를 제외한 모든 브랜치에서 평가되는 규칙을 생성하려면, 다음 범위로 규칙을 생성할 수 있습니다. + +1. `Select when to evaluate`를 클릭합니다. +1. **Repository** 필드에 `example-repository`를 입력하고 **Include**를 클릭합니다. +1. **Add Filter**를 클릭하고 **Branch**를 선택합니다. +1. **Branch** 필드에 `main`을 입력하고 **Exclude**를 클릭합니다. + +{{< img src="ci/scope_not_main_example_repository.png" alt="예시 리포지토리 및 비메인 브랜치에 대한 규칙 범위" style="width:90%;">}} + +규칙에 범위에 포함되지 않는 경우, 해당 범위의 모든 값을 평가합니다. +예를 들어, 규칙에 `repository` 범위가 포함되지 않으면 모든 리포지토리를 평가합니다. + +## 커스텀 범위 추가하기 + +브랜치 및 리포지토리외에도 커스텀 범위를 정의하여 특정 CI 파이프라인을 평가하는 규칙을 필터링할 수 있습니다. + +{{< img src="quality_gates/setup/custom_scope.png" alt="Quality Gate의 규칙 범위에 커스텀 범위 추가하기" style="width:80%;">}} + +규칙 생성 시 커스텀 범위를 추가하려면 다음을 따릅니다. + +1. **+필터 추가**를 클릭하고 **커스텀 범위 **를 선택합니다. +2. 범위 이름을 정의합니다(예: `team`). +3. 범위에 포함 또는 제외되는 값을 정의합니다. + +`branch` 및 `repository` 범위와는 다르게 커스텀 범위는 반드시 `--scope` 옵션으로 [`datadog-ci gate evaluate` 명령][1]에 전달해야 합니다. + +예를 들어 `example-repository` 리포지토리를 평가하는 규칙을 만들 수 있지만, 팀이 `backend`인 경우에만 만들 수 있습니다. + +1. `Select when to evaluate`를 클릭합니다. +1. **Repository** 필드에 `example-repository`를 입력하고 **Include**를 클릭합니다. +1. **Add Filter**를 클릭하고 **Custom scope**를 선택합니다. +1. 태그 이름을 입력하고 **Add Custom Scope**를 클릭합니다. + + {{< img src="quality_gates/setup/add_tag.png" alt="예시 리포지토리 및 팀 백엔드의 규칙 범위" style="width:50%;">}} + +1. **team** 필드에 `backend`를 입력하고 **Include**를 클릭합니다. + +{{< img src="ci/rule_scope_example_repository_team_backend.png" alt="예시 리포지토리 및 팀 백엔드의 규칙 범위" style="width:80%;">}} + +해당 규칙은 `example-repository` 리포지토리의 CI 파이프라인에서 다음 명령이 호출될 시 평가됩니다. +- `datadog-ci gate evaluate --scope team:backend` + +다음 명령이 대신 호출되면 규칙이 평가되지 **않습니다.** +- 팀을 지정하지 않을 경우 `datadog-ci gate evaluate`입니다. +- `backend` 이외의 특정 팀을 지정하는 경우 `datadog-ci gate evaluate --scope team:api --scope team:frontend`입니다. + +## 참고 자료 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://www.npmjs.com/package/@datadog/datadog-ci \ No newline at end of file diff --git a/content/ko/real_user_monitoring/correlate_with_other_telemetry/_index.md b/content/ko/real_user_monitoring/correlate_with_other_telemetry/_index.md new file mode 100644 index 0000000000000..0be0667ad24a7 --- /dev/null +++ b/content/ko/real_user_monitoring/correlate_with_other_telemetry/_index.md @@ -0,0 +1,41 @@ +--- +description: 추가 Datadog 제품으로 수집한 텔레메트리와 RUM 이벤트를 연결하는 방법에 관해 알아봅니다. +further_reading: +- link: /logs/guide/ease-troubleshooting-with-cross-product-correlation/ + tag: 설명서 + text: 교차 제품 연결을 통한 트러블슈팅 +- link: https://www.datadoghq.com/blog/unify-apm-rum-datadog/ + tag: 블로그 + text: RUM 이벤트와 APM 텔레메트리를 원활하게 연결하여 풀 스택을 가시화하기 +title: RUM 이벤트를 다른 텔레메트리와 상호 연결하기 +--- + +다양한 Datadog 프로덕트별로 데이터를 상호 연관시켜 단 몇 번의 클릭만으로 비즈니스에 미치는 영향을 추정하고 문제의 근본 원인을 찾을 수 있도록 도와드리는 컨텍스트를 제공합니다. 수신 데이터 간의 연결을 설정하여 탐색기와 대시보드에서 빠르게 피벗 작업을 할 수 있도록 도와드립니다. + +## RUM과 로그 상호 연결 + +사용자 세션과 보기 이벤트에서 수집한 데이터를 로그와 상호 연결하여 애플리케이션 동작에 관해 더욱 깊은 인사이트를 얻고 트러블슈팅을 간소화할 수 있습니다. 설정 방법은 [로그와 RUM 연결]을 참고하세요. + +{{< img src="real_user_monitoring/correlate_rum_and_logs/rum_browser_logs.png" alt="RUM 작업 내 브라우저 로그" style="width:100%;" >}} + +## RUM 및 트레이스 상호 연결 + +[RUM과 트레이스를 연결][2]하여 프런트엔드 보기에서 수집한 데이터와 백엔드의 트레이스 및 스팬을 상호 연관시킵니다. 이를 통해 스택의 어느 위치에서든 문제를 정확히 찾아내고 사용자 경험을 이해할 수 있습니다. 자세한 정보는 [RUM과 트레이스 연결][2]을 참고하세요. + +{{< img src="real_user_monitoring/connect_rum_and_traces/rum_trace_tab.png" alt="RUM 및 트레이스" style="width:100%;">}} + + +## RUM과 신서틱 테스트 상호 연결 + +관련 RUM 이벤트 데이터를 조사해 신서틱 테스트의 데이터를 근본 원인까지 추적할 수 있습니다. [신서틱과 RUM을 연결][3]하여 신서틱 테스트를 더욱 면밀히 가시화하여 살펴볼 수 있습니다. + +{{< img src="synthetics/guide/rum_in_synthetics/sessions_details_panel.png" alt="세션 세부 정보 사이드 패널" style="width:100%;" >}} + + +## 참고 자료 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ko/real_user_monitoring/correlate_with_other_telemetry/logs/ +[2]: /ko/real_user_monitoring/correlate_with_other_telemetry/apm/ +[3]: /ko/synthetics/guide/explore-rum-through-synthetics/ \ No newline at end of file diff --git a/content/ko/real_user_monitoring/guide/remotely-configure-rum-using-launchdarkly.md b/content/ko/real_user_monitoring/guide/remotely-configure-rum-using-launchdarkly.md index 8ba5a27a3ad69..37ae55b62647d 100644 --- a/content/ko/real_user_monitoring/guide/remotely-configure-rum-using-launchdarkly.md +++ b/content/ko/real_user_monitoring/guide/remotely-configure-rum-using-launchdarkly.md @@ -115,13 +115,13 @@ datadogRum.init(RUM_configuration_object) ``` ## LaunchDarkly 제어를 포함해 대시보드에서 직접 RUM을 설정할 수 있습니다. -Datadog 애플리케이션에서 직접 RUM 설정을 변경하려면 Datadog에 LaunchDarkly UI를 포함하고 기능 플래그 켜기/끄기를 전환할 수 있습니다. 기능 플래그가 설정되면 기본 값을 사용해 꺼둘 수 있습니다. 고정확도 데이터를 사용하려면 기능 플래그를 켭니다. 그러면 ON 변수에 대해 설정한 값이 RUM 초기화에 사용됩니다. +Datadog 애플리케이션에서 RUM 구성을 직접 변경하려면 LaunchDarkly UI를 Datadog에 임베드하여 기능 플래그를 켜거나 끄면 됩니다. 기본값을 사용하여 기능 플래그를 끈 채로 유지할 수 있습니다. 더 정밀한 데이터가 필요할 때 기능 플래그를 활성화하면, ON 변수에 설정된 값이 RUM 초기화에 적용됩니다. -LaunchDarkly의 Datadog 앱 통합에는 기능 플래그 관리 UI가 대시보드 위젯으로 포함되어 있습니다. 이 위젯을 사용하면 Datadog을 나가지 않고도 기능 플래그를 전환할 수 있습니다. 주요 메트릭을 표시하는 새 대시보드나 기존 대시보드 내에 LaunchDarkly 위젯을 포함할 수 있습니다. 인시던트가 발생하거나 오류가 급증하는 경우 Datadog 내에서 RUM 구성에 대한 기능 플래그를 빠르게 전환하여 더 많은 데이터 샘플링을 시작하고 팀이 문제를 해결하는 데 필요한 정보에 액세스할 수 있도록 할 수 있습니다. +LaunchDarkly의 Datadog 앱 통합 기능은 기능 플래그 관리 UI를 대시보드 위젯으로 임베드합니다. 이 위젯을 사용하면 Datadog 내에서 기능 플래그를 전환할 수 있고, 주요 메트릭을 표시하는 새 대시보드나 기존 대시보드에 LaunchDarkly 위젯을 임베드할 수 있습니다. 인시던트가 발생하거나 오류가 급증하면 Datadog 내에서 RUM 구성의 기능 플래그를 전환하여 더 많은 데이터를 샘플링하고 문제 해결에 필요한 정보를 얻을 수 있습니다. {{< img src="real_user_monitoring/guide/remotely-configure-rum-using-launchdarkly/datadog-launchdarkly-ui-widget.png" alt="Datadog 및 LaunchDarkly UI 통합 위젯" style="width:100%;">}} -설정에 대해 원래 구성한 값을 변경해야 하는 경우 언제든지 LaunchDarkly 내에서 플래그를 업데이트할 수 있습니다. 변경 사항을 저장한 후에는 모든 새 플래그 평가에 업데이트된 값이 적용됩니다. +초기 설정 값을 변경해야 할 때는 LaunchDarkly에서 언제든지 플래그를 업데이트할 수 있습니다. 변경 사항을 저장하면 모든 새 플래그 평가에 업데이트된 값이 적용됩니다. ## 참고 자료 {{< partial name="whats-next/whats-next.html" >}} diff --git a/content/ko/real_user_monitoring/guide/setup-feature-flag-data-collection.md b/content/ko/real_user_monitoring/guide/setup-feature-flag-data-collection.md new file mode 100644 index 0000000000000..131b7a74d09b4 --- /dev/null +++ b/content/ko/real_user_monitoring/guide/setup-feature-flag-data-collection.md @@ -0,0 +1,996 @@ +--- +aliases: +- /ko/real_user_monitoring/guide/getting-started-feature-flags/ +beta: true +description: RUM을 설정하여 기능 플래그 데이터를 캡처하고 Datadog에서 성능을 분석하는 방법 알아뷰 +further_reading: +- link: /real_user_monitoring/feature_flag_tracking + tag: 설명서 + text: Feature flag tracking(기능 플래그 추적)으로 기능 플래그 데이터를 분석합니다. +- link: /real_user_monitoring/explorer + tag: 설명서 + text: RUM 탐색기에서 RUM 데이터 시각화 +title: RUM에서 기능 플래그 데이터로 시작하기 +--- + +## 개요 +기능 플래그 데이터를 사용하면 어떤 사용자에게 특정 기능이 표시되는지, 도입한 변경 사항이 사용자 경험에 영향을 미치거나 성능에 부정적인 영향을 미치는지 확인할 수 있으므로 사용자 경험 및 성능 모니터링에 대한 가시성을 높일 수 있습니다. + +기능 플래그 데이터로 RUM 데이터를 보강하면 의도치 않은 버그나 성능 저하를 일으키지 않고도 기능을 성공적으로 출시할 수 있다고 확신할 수 있습니다. 추가 인사이트 레이어로 기능 릴리스와 성능의 상관 관계를 파악하고, 특정 릴리스에 관한 문제를 정확히 찾아내며 해당 문제를 더 빠르게 해결할 수 있습니다. + +## 설정 + +{{< tabs >}} +{{% tab "Browser" %}} + +Feature flag tracking은 RUM Browser SDK에서 사용할 수 있습니다. 시작하려면 [RUM 브라우저 모니터링][1]을 설정합니다. RUM Browser SDK 버전 4.25.0 이상이 필요합니다. + +
+ v5.17.0 이전 버전 + +5.17.0 이전 버전을 사용하는 경우에는 RUM SDK를 초기화하고 `enableExperimentalFeatures` 초기화 파라미터를 `["feature_flags"]`로 설정하여 기능 플래그 데이터 수집을 시작합니다. + +{{% collapse-content title="NPM" level="h4" %}} +```javascript + import { datadogRum } from '@datadog/browser-rum'; + + // Initialize Datadog Browser SDK + datadogRum.init({ + ... + enableExperimentalFeatures: ["feature_flags"], + ... +}); +``` +{{% /collapse-content %}} + +{{% collapse-content title="CDN async" level="h4" %}} +```javascript +window.DD_RUM.onReady(function() { + window.DD_RUM.init({ + ... + enableExperimentalFeatures: ["feature_flags"], + ... + }) +}) +``` +{{% /collapse-content %}} + +{{% collapse-content title="CDN sync" level="h4" %}} +```javascript +window.DD_RUM && + window.DD_RUM.init({ + ... + enableExperimentalFeatures: ["feature_flags"], + ... + }) +``` +{{% /collapse-content %}} + +
+
+ +[1]: /ko/real_user_monitoring/browser/setup/ +{{% /tab %}} +{{% tab "Android" %}} + +Feature flag tracking은 RUM Android SDK에서 사용할 수 있습니다. 시작하려면 [RUM Android 모니터링][1]을 설정합니다. Android RUM SDK 버전 1.18.0 이상이 필요합니다. + +[1]: /ko/real_user_monitoring/mobile_and_tv_monitoring/android/setup/ +{{% /tab %}} +{{% tab "Flutter" %}} + +Feature flag tracking은 Flutter 애플리케이션에서 사용할 수 있습니다. 시작하려면 [RUM Flutter 모니터링][1]을 설정합니다. Flutter Plugin 버전 1.3.2 이상이 필요합니다. + +[1]: /ko/real_user_monitoring/mobile_and_tv_monitoring/flutter/setup/ +{{% /tab %}} +{{% tab "iOS" %}} + +Feature flag tracking은 RUM iOS SDK에서 사용할 수 있습니다. 시작하려면 [RUM iOS 모니터링][1]을 설정합니다. iOS RUM SDK 버전 1.16.0 이상이 필요합니다. + +[1]: /ko/real_user_monitoring/mobile_and_tv_monitoring/ios/setup +{{% /tab %}} +{{% tab "Kotlin Multiplatform" %}} + +Feature flag tracking은 Kotlin Multiplatform 애플리케이션에서 사용할 수 있습니다. 시작하려면 [RUM Kotlin Multiplatform 모니터링][1]을 설정합니다. + +[1]: /ko/real_user_monitoring/mobile_and_tv_monitoring/kotlin_multiplatform +{{% /tab %}} +{{% tab "React Native" %}} + +Feature flag tracking은 React Native 애플리케이션에서 사용할 수 있습니다. 시작하려면 [RUM React Native 모니터링][1]을 설정합니다. React Native RUM SDK 버전 1.7.0 이상이 필요합니다. + +[1]: /ko/real_user_monitoring/mobile_and_tv_monitoring/react_native/setup +{{% /tab %}} +{{% tab "Unity" %}} + +Feature flag tracking은 Unity 애플리케이션에서 사용할 수 있습니다. 시작하려면 [RUM Unity 모니터링][1]을 설정합니다. + +[1]: /ko/real_user_monitoring/mobile_and_tv_monitoring/unity/setup +{{% /tab %}} +{{< /tabs >}} + +## 통합 + +[커스텀 기능 플래그 관리 솔루션](#custom-feature-flag-management)을 사용하거나 Datadog 통합 파트너 중 하나를 사용하여 기능 플래그 데이터 수집을 시작할 수 있습니다. + +Datadog은 다음 통합을 지원합니다. +{{< partial name="rum/rum-feature-flag-tracking.html" >}} + + +
+ +### Amplitude 통합 + +{{< tabs >}} +{{% tab "Browser" %}} + +다음 코드 스니펫을 사용하여 Amplitude 소프트웨어 개발 키트(SDK)를 초기화하고 Datadog에 기능 플래그 평가를 보고하는 익스포저 리스너를 생성합니다. + +Amplitude 초기화에 대한 자세한 내용은 Amplitude 소프트웨어 개발 키트(SDK), [JavaScript 소프트웨어 개발 키트(SDK) 설명서][1]를 참조하세요. + +```javascript + const experiment = Experiment.initialize("CLIENT_DEPLOYMENT_KEY", { + exposureTrackingProvider: { + track(exposure: Exposure) { + // Amplitude에서 노출을 보고할 때 기능 플래그 전송 + datadogRum.addFeatureFlagEvaluation(exposure.flag_key, exposure.variant); + } + } + }) +``` + + +[1]: https://www.docs.developers.amplitude.com/experiment/sdks/javascript-sdk/ + +{{% /tab %}} +{{% tab "iOS" %}} + +Amplitude 소프트웨어 개발 키트(SDK)를 초기화하고 아래 코드 스니펫을 사용하여 Datadog로 기능 플래그 평가를 보고하는 인스팩터를 생성하세요. + +Amplitude SDK 초기화에 대한 자세한 내용은 Amplitude의 [iOS 소프트웨어 개발 키트(SDK) 설명서][1]를 참조하세요. + +```swift + class DatadogExposureTrackingProvider : ExposureTrackingProvider { + func track(exposure: Exposure) { + // Amplitude에서 노출을 보고할 때 기능 플래그 전송 + if let variant = exposure.variant { + RUMMonitor.shared().addFeatureFlagEvaluation(name: exposure.flagKey, value: variant) + } + } + } + + // In initialization: + ExperimentConfig config = ExperimentConfigBuilder() + .exposureTrackingProvider(DatadogExposureTrackingProvider(analytics)) + .build() +``` + +[1]: https://www.docs.developers.amplitude.com/experiment/sdks/ios-sdk/ + + +{{% /tab %}} +{{% tab "Android" %}} + +Amplitude 소프트웨어 개발 키트(SDK)를 초기화하고 아래 코드 스니펫을 사용하여 Datadog로 기능 플래그 평가를 보고하는 인스팩터를 생성하세요. + +Amplitude SDK 초기화에 대한 자세한 내용은 Amplitude의 [Android 소프트웨어 개발 키트(SDK) 설명서][1]를 참조하세요. + +```kotlin + internal class DatadogExposureTrackingProvider : ExposureTrackingProvider { + override fun track(exposure: Exposure) { + // Amplitude에서 노출을 보고할 때 기능 플래그 전송 + GlobalRumMonitor.get().addFeatureFlagEvaluation( + exposure.flagKey, + exposure.variant.orEmpty() + ) + } + } + + // In initialization: + val config = ExperimentConfig.Builder() + .exposureTrackingProvider(DatadogExposureTrackingProvider()) + .build() +``` + +[1]: https://www.docs.developers.amplitude.com/experiment/sdks/android-sdk/ + + +{{% /tab %}} +{{% tab "Flutter" %}} + +Amplitude는 이 통합 기능을 지원하지 않습니다. 이 기능을 요청하려면 Amplitude를 통해 티켓을 생성하세요. + + +{{% /tab %}} +{{< /tabs >}} + +### ConfigCat 통합 + +{{< tabs >}} +{{% tab "Browser" %}} + +ConfigCat 자바스크립트 소프트웨어 개발 키트(SDK)를 초기화하면 `flagEvaluated` 이벤트를 구독하고 기능 플래그 평가를 Datadog에 전송하게 됩니다. + +```javascript +const configCatClient = configcat.getClient( + '#YOUR-SDK-KEY#', + configcat.PollingMode.AutoPoll, + { + setupHooks: (hooks) => + hooks.on('flagEvaluated', (details) => { + datadogRum.addFeatureFlagEvaluation(details.key, details.value); + }) + } +); +``` + +ConfigCat 자바스크립트 소프트웨어 개발 키트(SDK) 초기화에 대한 자세한 내용은 ConfigCat [자바스크립트 소프트웨어 개발 키트(SDK) 설명서][1]를 참조하세요. + +[1]: https://configcat.com/docs/sdk-reference/js + + +{{% /tab %}} +{{% tab "iOS" %}} + +ConfigCat Swift iOS 소프트웨어 개발 키트(SDK)를 초기화하면 `flagEvaluated` 이벤트를 구독하고 Datadog에 기능 플래그 평가를 전송하게 됩니다. + +```swift + let client = ConfigCatClient.get(sdkKey: "#YOUR-SDK-KEY#") { options in + options.hooks.addOnFlagEvaluated { details in + RUMMonitor.shared().addFeatureFlagEvaluation(featureFlag: details.key, variation: details.value) + } + } +``` + +ConfigCat Swift (iOS) 소프트웨어 개발 키트(SDK) 초기화에 대한 자세한 내용은 ConfigCat Swift iOS 소프트웨어 개발 키트(SDK) 설명서][1]를 참조하세요. + +[1]: https://configcat.com/docs/sdk-reference/ios + + +{{% /tab %}} +{{% tab "Android" %}} + +ConfigCat 안드로이드 소프트웨어 개발 키트(SDK)를 초기화하면 `flagEvaluated` 이벤트를 구독하고 기능 플래그 평가를 Datadog 에 보고하게 됩니다. + +```java + ConfigCatClient client = ConfigCatClient.get("#YOUR-SDK-KEY#", options -> { + options.hooks().addOnFlagEvaluated(details -> { + GlobalRumMonitor.get().addFeatureFlagEvaluation(details.key, details.value); + }); + }); +``` + +ConfigCat 안드로이드 소프트웨어 개발 키트(SDK) 초기화에 대한 자세한 내용은 ConfigCat [안드로이드 소프트웨어 개발 키트(SDK) 설명서][1]를 참조하세요. + +[1]: https://configcat.com/docs/sdk-reference/android + + +{{% /tab %}} +{{% tab "Flutter" %}} + +ConfigCat Dart 소프트웨어 개발 키트(SDK) 초기화 시`flagEvaluated` 이벤트를 구독하고 기능 플래그 평가를 Datadog에 보고합니다. + +```dart + final client = ConfigCatClient.get( + sdkKey: '#YOUR-SDK-KEY#', + options: ConfigCatOptions( + pollingMode: PollingMode.autoPoll(), + hooks: Hooks( + onFlagEvaluated: (details) => { + DatadogSdk.instance.rum?.addFeatureFlagEvaluation(details.key, details.value); + } + ) + ) + ); +``` + +ConfigCat Dart (Flutter) 소프트웨어 개발 키트(SDK) 초기화에 대한 자세한 내용은 ConfigCat [Dart 소프트웨어 개발 키트(SDK) 설명서][1]를 참조하세요. + +[1]: https://configcat.com/docs/sdk-reference/dart + + +{{% /tab %}} + + +{{% tab "React Native" %}} + +ConfigCat React 소프트웨어 개발 키트(SDK) 초기화 시 `flagEvaluated` 이벤트를 구독하고 Datadog에 기능 플래그 평가를 전송합니다. + +```typescript + + hooks.on('flagEvaluated', (details) => { + DdRum.addFeatureFlagEvaluation(details.key, details.value); + }), + }} +> + ... + +``` + +ConfigCat React 소프트웨어 개발 키트(SDK) 초기화에 대한 자세한 내용은 ConfigCat [React 소프트웨어 개발 키트(SDK) 설명서][1]를 참조하세요. + +[1]: https://configcat.com/docs/sdk-reference/react + +{{% /tab %}} +{{< /tabs >}} + +### 커스텀 기능 플래그 관리 + +{{< tabs >}} +{{% tab "Browser" %}} + +기능 플래그가 평가될 때마다 다음 함수를 추가하여 기능 플래그 정보를 RUM으로 전송합니다. + +```javascript +datadogRum.addFeatureFlagEvaluation(key, value); +``` + +{{% /tab %}} +{{% tab "iOS" %}} + +기능 플래그가 평가될 때마다 다음 함수를 추가하여 기능 플래그 정보를 RUM으로 전송합니다. + + ```swift + RUMMonitor.shared().addFeatureFlagEvaluation(key, value); + ``` + +{{% /tab %}} +{{% tab "Android" %}} + +기능 플래그가 평가될 때마다 다음 함수를 추가하여 기능 플래그 정보를 RUM으로 전송합니다. + + ```kotlin + GlobalRumMonitor.get().addFeatureFlagEvaluation(key, value); + ``` + +{{% /tab %}} +{{% tab "Flutter" %}} + +기능 플래그가 평가될 때마다 다음 함수를 추가하여 기능 플래그 정보를 RUM으로 전송합니다. + + ```dart + DatadogSdk.instance.rum?.addFeatureFlagEvaluation(key, value); + ``` +{{% /tab %}} +{{% tab "React Native" %}} + +기능 플래그가 평가될 때마다 다음 함수를 추가하여 기능 플래그 정보를 RUM으로 전송합니다. + + ```javascript + DdRum.addFeatureFlagEvaluation(key, value); + ``` + +{{% /tab %}} +{{< /tabs >}} + +### DevCycle 통합 + +{{< tabs >}} +{{% tab "Browser" %}} + +모든 변수 평가 `variableEvaluated:*` 또는 특정 변수 평가 `variableEvaluated:my-variable-key`를 구독하도록 선택하여 DevCycle 소프트웨어 개발 키트(SDK) 를 초기화하고 `variableEvaluated` 이벤트를 구독합니다. + +DevCycle 소프트웨어 개발 키트(SDK) 초기화에 대한 자세한 내용은 [DevCycle JavaScript 소프트웨어 개발 키트(SDK) 설명서][5]를 참조하고 DevCycle 이벤트 시스템에 대한 자세한 내용은 [DevCycle 소프트웨어 개발 키트(SDK) 이벤트 설명서][6]를 참조하세요. + +```javascript +const user = { user_id: "" }; +const dvcOptions = { ... }; +const dvcClient = initialize("", user, dvcOptions); +... +dvcClient.subscribe( + "variableEvaluated:*", + (key, variable) => { + // track all variable evaluations + datadogRum.addFeatureFlagEvaluation(key, variable.value); + } +) +... +dvcClient.subscribe( + "variableEvaluated:my-variable-key", + (key, variable) => { + // track a particular variable evaluation + datadogRum.addFeatureFlagEvaluation(key, variable.value); + } +) +``` + + +[5]: https://docs.devcycle.com/sdk/client-side-sdks/javascript/javascript-install +[6]: https://docs.devcycle.com/sdk/client-side-sdks/javascript/javascript-usage#subscribing-to-sdk-events +{{% /tab %}} +{{% tab "iOS" %}} + +DevCycle은 이 통합을 지원하지 않습니다. 이 기능을 요청하려면 DevCycle을 통해 티켓을 생성하세요. + + +{{% /tab %}} +{{% tab "Android" %}} + +DevCycle은 이 통합을 지원하지 않습니다. 이 기능을 요청하려면 DevCycle을 통해 티켓을 생성하세요. + + +{{% /tab %}} +{{% tab "Flutter" %}} + +DevCycle은 이 통합을 지원하지 않습니다. 이 기능을 요청하려면 DevCycle을 통해 티켓을 생성하세요. + + +{{% /tab %}} +{{% tab "React Native" %}} + +DevCycle은 이 통합을 지원하지 않습니다. 이 기능을 요청하려면 DevCycle을 통해 티켓을 생성하세요. + + +{{% /tab %}} +{{< /tabs >}} + +### Eppo 통합 + +{{< tabs >}} +{{% tab "Browser" %}} + +아래 표시된 코드 스니펫을 사용하여 Eppo 소프트웨어 개발 키트(SDK) 을 초기화하고 기능 플래그 평가를 Datadog 에 추가로 보고하는 할당 로거를 생성합니다. + +Eppo 소프트웨어 개발 키트(SDK) 초기화에 대한 자세한 내용은 [Eppo 자바스크립트 소프트웨어 개발 키트(SDK) 설명서][1]를 참조하세요. + +```typescript +const assignmentLogger: IAssignmentLogger = { + logAssignment(assignment) { + datadogRum.addFeatureFlagEvaluation(assignment.featureFlag, assignment.variation); + }, +}; + +await eppoInit({ + apiKey: "", + assignmentLogger, +}); +``` + +[1]: https://docs.geteppo.com/sdks/client-sdks/javascript +{{% /tab %}} +{{% tab "iOS" %}} + +아래 표시된 코드 스니펫을 사용하여 Eppo 소프트웨어 개발 키트(SDK) 을 초기화하고 기능 플래그 평가를 Datadog 에 추가로 보고하는 할당 로거를 생성합니다. + +Eppo 소프트웨어 개발 키트(SDK) 초기화에 대한 자세한 내용은 [Eppo iOS 소프트웨어 개발 키트(SDK) 설명서][1]를 참조하세요. + +```swift +func IAssignmentLogger(assignment: Assignment) { + RUMMonitor.shared().addFeatureFlagEvaluation(featureFlag: assignment.featureFlag, variation: assignment.variation) +} + +let eppoClient = EppoClient(apiKey: "mock-api-key", assignmentLogger: IAssignmentLogger) +``` + +[1]: https://docs.geteppo.com/sdks/client-sdks/ios + +{{% /tab %}} +{{% tab "Android" %}} + +아래 표시된 코드 스니펫을 사용하여 Eppo 소프트웨어 개발 키트(SDK) 을 초기화하고 기능 플래그 평가를 Datadog 에 추가로 보고하는 할당 로거를 생성합니다. + +Eppo 소프트웨어 개발 키트(SDK) 초기화에 대한 자세한 내용은 [Eppo 안드로이드 소프트웨어 개발 키트(SDK) 설명서][1]를 참조하세요. + +```java +AssignmentLogger logger = new AssignmentLogger() { + @Override + public void logAssignment(Assignment assignment) { + GlobalRumMonitor.get().addFeatureFlagEvaluation(assignment.getFeatureFlag(), assignment.getVariation()); + } +}; + +EppoClient eppoClient = new EppoClient.Builder() + .apiKey("YOUR_API_KEY") + .assignmentLogger(logger) + .application(application) + .buildAndInit(); +``` + + +[1]: https://docs.geteppo.com/sdks/client-sdks/android + +{{% /tab %}} +{{% tab "Flutter" %}} + +Eppo는 이 통합을 지원하지 않습니다. 이 기능을 요청하려면 [Eppo로 문의][1]하세요. + +[1]: mailto:support@geteppo.com + +{{% /tab %}} +{{% tab "React Native" %}} + +아래 표시된 코드 스니펫을 사용하여 Eppo 소프트웨어 개발 키트(SDK) 을 초기화하고 기능 플래그 평가를 Datadog 에 추가로 보고하는 할당 로거를 생성합니다. + +Eppo 소프트웨어 개발 키트(SDK) 초기화에 대한 자세한 내용은 [Eppo의 React 네이티브 소프트웨어 개발 키트(SDK) 설명서][1]를 참조하세요. + +```typescript +const assignmentLogger: IAssignmentLogger = { + logAssignment(assignment) { + DdRum.addFeatureFlagEvaluation(assignment.featureFlag, assignment.variation); + }, +}; + +await eppoInit({ + apiKey: "", + assignmentLogger, +}); +``` + +[1]: https://docs.geteppo.com/sdks/client-sdks/react-native + +{{% /tab %}} +{{< /tabs >}} + +### Flagsmith 통합 + +{{< tabs >}} +{{% tab "Browser" %}} + +아래 표시된 코드 스니펫을 사용하여 Datadog에 기능 플래그 평가를 보고하는 `datadogRum` 옵션으로 Flagsmith의 SDK를 초기화합니다. + + 선택적으로 Flagsmith 특성이 `datadogRum.setUser()` 을 통해 Datadog 으로 전송되도록 클라이언트를 설정할 수 있습니다. Flagsmith 소프트웨어 개발 키트(SDK) 초기화에 대한 자세한 내용은 [Flagsmith자바스크립트 소프트웨어 개발 키트(SDK) 설명서][1]를 참조하세요. + + ```javascript + // Initialize the Flagsmith SDK + flagsmith.init({ + datadogRum: { + client: datadogRum, + trackTraits: true, + }, + ... + }) + ``` + + +[1]: https://docs.flagsmith.com/clients/javascript +{{% /tab %}} +{{% tab "iOS" %}} + +Flagsmith는 이 통합 기능을 지원하지 않습니다. 이 기능을 요청하려면 Flagsmith를 통해 티켓을 생성하세요. + + +{{% /tab %}} +{{% tab "Android" %}} + +Flagsmith는 이 통합 기능을 지원하지 않습니다. 이 기능을 요청하려면 Flagsmith를 통해 티켓을 생성하세요. + +{{% /tab %}} +{{% tab "Flutter" %}} + +Flagsmith는 이 통합 기능을 지원하지 않습니다. 이 기능을 요청하려면 Flagsmith를 통해 티켓을 생성하세요. + +{{% /tab %}} +{{% tab "React Native" %}} + +Flagsmith는 현재 이 연동 기능을 지원하지 않습니다. 이 기능을 요청하려면 Flagsmith를 통해 티켓을 생성하세요. + +{{% /tab %}} +{{< /tabs >}} + +### GrowthBook 통합 + +{{< tabs >}} +{{% tab "Browser" %}} + +GrowthBook 소프트웨어 개발 키트(SDK) 초기화 시 `onFeatureUsage` 콜백을 사용하여 Datadog로 기능 플래그 평가를 보고합니다. + +GrowthBook 소프트웨어 개발 키트(SDK) 초기화에 대한 자세한 내용은 [GrowthBook 자바스크립트 소프트웨어 개발 키트(SDK) 설명서][1]를 참조하세요. + +```javascript +const gb = new GrowthBook({ + ..., + onFeatureUsage: (featureKey, result) => { + datadogRum.addFeatureFlagEvaluation(featureKey, result.value); + }, +}); + +gb.init(); +``` + +[1]: https://docs.growthbook.io/lib/js#step-1-configure-your-app + +{{% /tab %}} +{{% tab "iOS" %}} + +GrowthBook은 이 통합을 지원하지 않습니다. 이 기능을 요청하려면 GrowthBook으로 문의하세요. + +{{% /tab %}} +{{% tab "Android" %}} + +GrowthBook 소프트웨어 개발 키트(SDK) 초기화 시 `setFeatureUsageCallback` 호출을 통해 Datadog에 기능 플래그 평가를 보고합니다. + +GrowthBook 소프트웨어 개발 키트(SDK) 초기화에 대한 자세한 내용은 [GrowthBook 안드로이드 소프트웨어 개발 키트(SDK) 설명서][1]를 참조하세요. + +```kotlin +val gbBuilder = GBSDKBuilder(...) + +gbBuilder.setFeatureUsageCallback { featureKey, result -> + GlobalRumMonitor.get().addFeatureFlagEvaluation(featureKey, result.value); +} + +val gb = gbBuilder.initialize() +``` + +[1]: https://docs.growthbook.io/lib/kotlin#quick-usage + +{{% /tab %}} +{{% tab "Flutter" %}} + +GrowthBook 소프트웨어 개발 키트(SDK) 초기화 시 `setFeatureUsageCallback` 호출을 통해 Datadog에 기능 플래그 평가를 보고합니다. + +GrowthBook 소프트웨어 개발 키트(SDK) 초기화에 대한 자세한 내용은 [GrowthBook Flutter 소프트웨어 개발 키트(SDK) 설명서][1]를 참조하세요. + +```dart +final gbBuilder = GBSDKBuilderApp(...); +gbBuilder.setFeatureUsageCallback((featureKey, result) { + DatadogSdk.instance.rum?.addFeatureFlagEvaluation(featureKey, result.value); +}); +final gb = await gbBuilder.initialize(); +``` + +[1]: https://docs.growthbook.io/lib/flutter#quick-usage + +{{% /tab %}} +{{% tab "React Native" %}} + +GrowthBook 소프트웨어 개발 키트(SDK) 초기화 시 `onFeatureUsage` 콜백을 사용하여 Datadog로 기능 플래그 평가를 보고합니다. + +GrowthBook 소프트웨어 개발 키트(SDK) 초기화에 대한 자세한 내용은 [GrowthBook GrowthBook 소프트웨어 개발 키트(SDK) 설명서[1]를 참조하세요. + +```javascript +const gb = new GrowthBook({ + ..., + onFeatureUsage: (featureKey, result) => { + datadogRum.addFeatureFlagEvaluation(featureKey, result.value); + }, +}); + +gb.init(); +``` + +[1]: https://docs.growthbook.io/lib/react-native#step-1-configure-your-app + +{{% /tab %}} +{{< /tabs >}} + +### Kameleoon 통합 + +{{< tabs >}} +{{% tab "Browser" %}} + +Kameleoon SDK를 생성 및 초기화한 후, `onEvent` 핸들러로 `Evaluation` 이벤트를 구독합니다. + +SDK에 대한 자세한 내용은 [Kameleoon 자바스크립트 SDK 설명서][1]를 참조하세요. + +```javascript +client.onEvent(EventType.Evaluation, ({ featureKey, variation }) => { + datadogRum.addFeatureFlagEvaluation(featureKey, variation.key); +}); +``` + + +[1]: https://developers.kameleoon.com/feature-management-and-experimentation/web-sdks/js-sdk +{{% /tab %}} +{{% tab "iOS" %}} + +Kameleoon은 이 통합을 지원하지 않습니다. 이 기능을 요청하려면 product@kameleoon.com으로 문의하세요. + +{{% /tab %}} +{{% tab "Android" %}} + +Kameleoon은 이 통합을 지원하지 않습니다. 이 기능을 요청하려면 product@kameleoon.com으로 문의하세요. + + +{{% /tab %}} +{{% tab "Flutter" %}} + +Kameleoon은 이 통합을 지원하지 않습니다. 이 기능을 요청하려면 product@kameleoon.com으로 문의하세요. + + +{{% /tab %}} +{{% tab "React Native" %}} + +Kameleoon 소프트웨어 개발 키트(SDK)를 생성 및 초기화한 후, `onEvent` 핸들러로 `Evaluation` 이벤트를 구독합니다. + +SDK 초기화에 대한 자세한 내용은 [Kameleoon React Native SDK 설명서][1]를 참조하세요. + +```javascript +const { onEvent } = useInitialize(); + +onEvent(EventType.Evaluation, ({ featureKey, variation }) => { + datadogRum.addFeatureFlagEvaluation(featureKey, variation.key); +}); +``` + + +[1]: https://developers.kameleoon.com/feature-management-and-experimentation/web-sdks/react-js-sdk +{{% /tab %}} +{{< /tabs >}} + + +### LaunchDarkly 통합 + +{{< tabs >}} +{{% tab "Browser" %}} + +LaunchDarkly 소프트웨어 개발 키트(SDK) 를 초기화하고 아래 코드 스니펫을 사용하여 Datadog에 기능 플래그 평가를 보고하는 인스펙터를 생성합니다. + + LaunchDarkly 소프트웨어 개발 키트(SDK) 초기화에 대한 자세한 내용은 [LaunchDarkly 자바스크립트 소프트웨어 개발 키트(SDK) 설명서][1]를 참조하세요 + +```javascript +const client = LDClient.initialize("", "", { + inspectors: [ + { + type: "flag-used", + name: "dd-inspector", + method: (key: string, detail: LDClient.LDEvaluationDetail) => { + datadogRum.addFeatureFlagEvaluation(key, detail.value); + }, + }, + ], +}); +``` + + +[1]: https://docs.launchdarkly.com/sdk/client-side/javascript#initializing-the-client +{{% /tab %}} +{{% tab "iOS" %}} + +LaunchDarkly는 이 통합을 지원하지 않습니다. 이 기능을 요청하려면 LaunchDarkly를 통해 티켓을 생성하세요. + + +{{% /tab %}} +{{% tab "Android" %}} + +LaunchDarkly는 이 통합을 지원하지 않습니다. 이 기능을 요청하려면 LaunchDarkly를 통해 티켓을 생성하세요. + + +{{% /tab %}} +{{% tab "Flutter" %}} + +LaunchDarkly는 이 통합을 지원하지 않습니다. 이 기능을 요청하려면 LaunchDarkly를 통해 티켓을 생성하세요. + + +{{% /tab %}} +{{% tab "React Native" %}} + +LaunchDarkly는 이 통합을 지원하지 않습니다. 이 기능을 요청하려면 LaunchDarkly를 통해 티켓을 생성하세요. + + +{{% /tab %}} +{{< /tabs >}} + + +### Split 통합 + +{{< tabs >}} +{{% tab "Browser" %}} + +Split 소프트웨어 개발 키트(SDK) 을 초기화하고 다음 코드 스니펫을 사용하여 Datadog에 기능 플래그 평가를 보고하는 노출 리스너를 생성합니다. + +Split 소프트웨어 개발 키트(SDK) 초기화에 대한 자세한 내용은 Split [JavaScript 소프트웨어 개발 키트(SDK) 설명서][1]를 참조하세요. + +```javascript +const factory = SplitFactory({ + core: { + authorizationKey: "", + key: "", + }, + impressionListener: { + logImpression(impressionData) { + datadogRum + .addFeatureFlagEvaluation( + impressionData.impression.feature, + impressionData.impression.treatment + ); + }, + }, +}); + +const client = factory.client(); +``` + + +[1]: https://help.split.io/hc/en-us/articles/360020448791-JavaScript-SDK#2-instantiate-the-sdk-and-create-a-new-split-client +{{% /tab %}} +{{% tab "iOS" %}} + +Split 소프트웨어 개발 키트(SDK) 을 초기화하고 아래 코드 스니펫을 사용하여 Datadog로 기능 플래그 평가를 보고하는 인스펙터를 만듭니다. + +Split 소프트웨어 개발 키트(SDK) 초기화에 대한 자세한 내용은 Split [iOS 소프트웨어 개발 키트(SDK) 설명서][1]를 참조하세요. + +```swift + let config = SplitClientConfig() + // Send the feature flag when Split reports the impression + config.impressionListener = { impression in + if let feature = impression.feature, + let treatment = impression.treatment { + RUMMonitor.shared().addFeatureFlagEvaluation(name: feature, value: treatment) + } + } +``` + + +[1]: https://help.split.io/hc/en-us/articles/360020401491-iOS-SDK +{{% /tab %}} +{{% tab "Android" %}} + +Split 소프트웨어 개발 키트(SDK) 을 초기화하고 아래 코드 스니펫을 사용하여 Datadog로 기능 플래그 평가를 보고하는 인스펙터를 만듭니다. + +Split 소프트웨어 개발 키트(SDK) 초기화에 대한 자세한 내용은 Split [안드로이드 소프트웨어 개발 키트(SDK) 설명서][1]를 참조하세요. + +```kotlin + internal class DatadogSplitImpressionListener : ImpressionListener { + override fun log(impression: Impression) { + // Send the feature flag when Split reports the impression + GlobalRumMonitor.get().addFeatureFlagEvaluation( + impression.split(), + impression.treatment() + ) + } + override fun close() { + } + } + + // In initialization: + val apikey = BuildConfig.SPLIT_API_KEY + val config = SplitClientConfig.builder() + .impressionListener(DatadogSplitImpressionListener()) + .build() +``` + + +[1]: https://help.split.io/hc/en-us/articles/360020343291-Android-SDK +{{% /tab %}} +{{% tab "Flutter" %}} + +Split 소프트웨어 개발 키트(SDK) 을 초기화하고 아래 코드 스니펫을 사용하여 Datadog로 기능 플래그 평가를 보고하는 인스펙터를 만듭니다. + +Split 소프트웨어 개발 키트(SDK) 초기화에 대한 자세한 내용은 Split의 [Flutter 플러그인 설명서][1]를 참조하세요. + +```dart + StreamSubscription impressionsStream = _split.impressionsStream().listen((impression) { + // Send the feature flag when Split reports the impression + final split = impression.split; + final treatment = impression.treatment; + if (split != null && treatment != null) { + DatadogSdk.instance.rum?.addFeatureFlagEvaluation(split, treatment); + } + }); +``` + + +[1]: https://help.split.io/hc/en-us/articles/8096158017165-Flutter-plugin +{{% /tab %}} +{{% tab "React Native" %}} + +Split 소프트웨어 개발 키트(SDK) 을 초기화하고 다음 코드 스니펫을 사용하여 Datadog에 기능 플래그 평가를 보고하는 노출 리스너를 생성합니다. + +Split 소프트웨어 개발 키트(SDK) 초기화에 대한 자세한 내용은 Split [React Native 소프트웨어 개발 키트(SDK) 설명서][1]를 참조하세요. + +```javascript +const factory = SplitFactory({ + core: { + authorizationKey: "", + key: "", + }, + impressionListener: { + logImpression(impressionData) { + DdRum + .addFeatureFlagEvaluation( + impressionData.impression.feature, + impressionData.impression.treatment + ); + }, + }, +}); + +const client = factory.client(); +``` + + +[1]: https://help.split.io/hc/en-us/articles/4406066357901-React-Native-SDK#2-instantiate-the-sdk-and-create-a-new-split-client +{{% /tab %}} +{{< /tabs >}} + +### Statsig 통합 + +{{< tabs >}} +{{% tab "Browser" %}} + +Statsig의소프트웨어 개발 키트(SDK)를 `statsig.initialize`를 사용하여 초기화합니다. + +1. 브라우저 RUM SDK 버전 4.25.0 이상으로 업데이트하세요. +2. RUM SDK를 초기화하고 `enableExperimentalFeatures` 초기화 파라미터를 `["feature_flags"]`으로 설정합니다. +3. Statsig의 SDK(`>= v4.34.0`)를 초기화하고 아래와 같이 `gateEvaluationCallback` 옵션을 구현합니다. + + ```javascript + await statsig.initialize('client-', + {userID: ''}, + { + gateEvaluationCallback: (key, value) => { + datadogRum.addFeatureFlagEvaluation(key, value); + } + } + ); + ``` + +[1]: https://docs.statsig.com/client/jsClientSDK +{{% /tab %}} +{{% tab "iOS" %}} + +Statsig는 이 통합을 지원하지 않습니다. 이 기능을 요청하려면 support@statsig.com으로 문의하세요. + +{{% /tab %}} +{{% tab "Android" %}} + +Statsig는 이 통합을 지원하지 않습니다. 이 기능을 요청하려면 support@statsig.com으로 문의하세요. + +{{% /tab %}} +{{% tab "Flutter" %}} + +Statsig는 이 통합을 지원하지 않습니다. 이 기능을 요청하려면 support@statsig.com으로 문의하세요. + +{{% /tab %}} +{{% tab "React Native" %}} + +Statsig는 현재 이 통합 기능을 지원하지 않습니다. 이 기능을 요청하려면 support@statsig.com으로 문의하세요. + +{{% /tab %}} +{{< /tabs >}} + +## RUM에서 기능 플래그 성능 분석하기 + +기능 플래그는 RUM 세션, 뷰 및 오류의 컨텍스트에 목록으로 표시됩니다. + +{{< img src="real_user_monitoring/guide/setup-feature-flag-data-collection/feature-flag-list-rum-event.png" alt="RUM Explorer의 Feature Flag 속성 목록" style="width:75%;">}} + +### RUM Explorer 기능 플래그 검색하기 +[RUM Explorer][2]에서 RUM이 수집한 모든 데이터를 검색하여 기능 플래그의 추세를 파악하고, 더 많은 컨텍스트에서 패턴을 분석하거나, [대시보드][3] 및 [모니터][4]로 내보낼 수 있습니다. `@feature_flags.{flag_name}` 속성으로 RUM Explorer에서 세션, 뷰 또는 오류를 검색할 수 있습니다. + +#### 세션 +`@feature_flags.{flag_name}` 속성으로 **세션**을 필터링하면 지정된 타임 프레임 동안 기능 플래그가 평가된 모든 세션을 찾을 수 있습니다. + +{{< img src="real_user_monitoring/guide/setup-feature-flag-data-collection/rum-explorer-session-feature-flag-search.png" alt="RUM Explorer에서 기능 플래그에 대한 세션 검색" style="width:75%;">}} + +#### 보기 +`@feature_flags.{flag_name}` 속성으로 **뷰**를 필터링하면 지정된 타임 프레임 동안 기능 플래그가 평가된 특정 뷰를 찾을 수 있습니다. + +{{< img src="real_user_monitoring/guide/setup-feature-flag-data-collection/rum-explorer-view-feature-flag-search.png" alt="RUM Explorer에서 기능 플래그에 대한 뷰 검색" style="width:75%;">}} + +#### 오류 +`@feature_flags.{flag_name}` 속성으로 **오류**를 필터링하면 지정된 타임 프레임 동안 기능 플래그가 평가된 뷰에서 발생한 모든 오류를 찾을 수 있습니다. + +{{< img src="real_user_monitoring/guide/setup-feature-flag-data-collection/rum-explorer-error-feature-flag-search.png" alt="RUM Explorer에서 기능 플래그에 대한 오류 검색" style="width:75%;">}} + +## 트러블슈팅 + +### 내 기능 플래그 데이터가 예상한 것과 다르게 나타납니다. +기능 플래그는 평가되는 이벤트의 컨텍스트에 표시되기 때문에 기능 플래그 코드 로직이 실행되는 뷰에 표시됩니다. + +코드를 구조화하고 기능 플래그를 설정한 방식에 따라 일부 이벤트의 컨텍스트에 예상치 못한 플래그가 표시될 수 있습니다. + +예를 들어, 어떤 **뷰**에서 기능 플래그가 평가되고 있는지 확인하려면 RUM Explorer로 유사한 쿼리를 실행할 수 있습니다. + +{{< img src="real_user_monitoring/guide/setup-feature-flag-data-collection/feature_flag_view_query.png" alt="RUM Explorer에서 기능 플래그 뷰 검색" style="width:75%;">}} + +다음은 관련이 없는 뷰에서 기능 플래그가 평가되는 이유에 대한 몇 가지 예시입니다. 조사에 사용하시기 바랍니다. + +- 실행될 때마다 기능 플래그를 평가하는, 여러 페이지에 표시되는 일반적인 React 컴포넌트. +- 기능 플래그 평가가 있는 컴포넌트가 URL 변경 전/후에 렌더링되는 라우팅 문제. + +조사할 때 기능 플래그와 관련된 `View Name`의 데이터 범위를 지정할 수도 있습니다. + + +## 참고 자료 +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ko/real_user_monitoring/browser/setup/ +[2]: https://app.datadoghq.com/rum/explorer +[3]: /ko/dashboards/ +[4]: /ko/monitors/#create-monitors +[5]: /ko/real_user_monitoring/feature_flag_tracking \ No newline at end of file diff --git a/content/ko/real_user_monitoring/mobile_and_tv_monitoring/flutter/integrated_libraries.md b/content/ko/real_user_monitoring/mobile_and_tv_monitoring/flutter/integrated_libraries.md new file mode 100644 index 0000000000000..902cf183d1c39 --- /dev/null +++ b/content/ko/real_user_monitoring/mobile_and_tv_monitoring/flutter/integrated_libraries.md @@ -0,0 +1,232 @@ +--- +aliases: +- /ko/real_user_monitoring/flutter/integrated_libraries/ +- /ko/real_user_monitoring/mobile_and_tv_monitoring/integrated_libraries/flutter +further_reading: +- link: https://github.com/DataDog/dd-sdk-flutter + tag: 소스 코드 + text: dd-sdk-flutter의 소스 코드 +title: RUM용 Flutter 라이브러리 +--- + +이 페이지에서는 Flutter 애플리케이션에 사용할 수 있는 통합 라이브러리 목록을 확인할 수 있습니다. + +## 라우팅 및 자동 보기 트래킹 + +Flutter Navigator v2.0을 사용하는 경우 라우팅 미들웨어에 따라 자동 보기 추적 설정이 달라집니다. 이 섹션에서는 가장 많이 사용되는 라우팅 패키지를 사용해 통합하는 방법을 설명합니다. + +### go_router + +[go_router][2]는 Flutter Navigator v1과 동일한 옵저버 인터페이스를 사용하므로 다른 옵저버에 `DatadogNavigationObserver`를 `GoRouter`에 대한 파라미터로 추가할 수 있습니다. + +```dart +final _router = GoRouter( + routes: [ + // 경로 정보는 여기에 + ], + observers: [ + DatadogNavigationObserver(datadogSdk: DatadogSdk.instance), + ], +); +MaterialApp.router( + routerConfig: _router, + // Your remaining setup +); +``` + +ShellRoute를 사용하는 경우 아래와 같이 각 `ShellRoute`에 별도의 옵저버를 제공해야 합니다. 자세한 내용은 [이 버그][3]를 참조하세요. + +```dart +final _router = GoRouter( + routes: [ + ShellRoute(build: shellBuilder), + routes: [ + // 추가 경로 + ], + observers: [ + DatadogNavigationObserver(datadogSdk: DatadogSdk.instance), + ], + ], + observers: [ + DatadogNavigationObserver(datadogSdk: DatadogSdk.instance), + ], +); +MaterialApp.router( + routerConfig: _router, + // 남은 설정 +); +``` + +또한 `builder` 파라미터 위에 `GoRoute`의 `pageBuilder`파라미터를 사용하는 경우 `state.pageKey` 값과 `name` 값을 `MaterialPage`에 전달해야 합니다. + +```dart +GoRoute( + name: 'My Home', + path: '/path', + pageBuilder: (context, state) { + return MaterialPage( + key: state.pageKey, // GoRouter가 Observers를 호출하는 데 필요합니다. + name: name, // Datadog이 올바른 경로 이름을 얻는 데 필요합니다. + child: _buildContent(), + ); + }, +), +``` + +### AutoRoute + +[AutoRoute][4]는 `config` 메서드의 일부로 `navigatorObservers` 중 하나로 제공되는 `DatadogNavigationObserver`를 사용할 수 있습니다. + +```dart +return MaterialApp.router( + routerConfig: _router.config( + navigatorObservers: () => [ + DatadogNavigationObserver( + datadogSdk: DatadogSdk.instance, + ), + ], + ), + // 남은 설정 +); +``` + +그러나 AutoRoute의 탭 라우팅을 사용하는 경우 AutoRoute의 `AutoRouteObserver`인터페이스로 Datadog의 기본 옵저버를 확장해야 합니다. + +```dart +class DatadogAutoRouteObserver extends DatadogNavigationObserver + implements AutoRouterObserver { + DatadogAutoRouteObserver({required super.datadogSdk}); + + // 옵저버 탭 경로로만 재정의 + @override + void didInitTabRoute(TabPageRoute route, TabPageRoute? previousRoute) { + datadogSdk.rum?.startView(route.path, route.name); + } + + @override + void didChangeTabRoute(TabPageRoute route, TabPageRoute previousRoute) { + datadogSdk.rum?.startView(route.path, route.name); + } +} +``` + +이 새 개체는 더 간단한 `DatadogNavigationObserver`를 대체합니다. + +### Beamer + +[Beamer][5]는 `BeamerDelegate`에 대한 인자로 `DatadogNavigationObserver`를 사용할 수 있습니다: + +```dart +final routerDelegate = BeamerDelegate( + locationBuilder: RoutesLocationBuilder( + routes: { + // 경로 설정 + }, + ), + navigatorObservers: [ + DatadogNavigationObserver(DatadogSdk.instance), + ] +); +``` + +## 웹 보기 추적 + +실제 사용자 모니터링(RUM)을 통해 모니터 웹 뷰를 확인하고 하이브리드 모바일 애플리케이션의 사각지대를 제거할 수 있습니다. + +Datadog Flutter SDK에는 [`webview_flutter`][8] 및 [`flutter_inappwebview`][9]와 함께 작업할 수 있는 패키지가 있습니다. 자세한 내용은 [웹 뷰 추적 설명서 페이지][10]를 참조하세요. + +## gRPC + +Datadog는 [grpc Flutter 패키지][7]와 함께 사용할 수 있는 [`datadog_grpc_interceptor`][6]을 제공합니다. gRPC 인터셉터는 RUM 리소스로 gRPC 요청을 자동으로 추적하고 APM을 통해 분산 추적을 지원합니다. + +### 설정 + +`pubspec.yaml` 또는 터미널에서 `flutter pub add datadog_grpc_interceptor`를 실행하여 `datadog_grpc_interceptor`를 추가합니다. + +```yaml +dependencies: + # Other dependencies + datadog_grpc_interceptor: ^1.1.0 +``` + +이 플러그인을 사용하려면 `DatadogGrpcInterceptor` 인스턴스를 생성한 다음 생성된 gRPC 클라이언트에 전달합니다. + +```dart +import 'package:datadog_grpc_interceptor/datadog_grpc_interceptor.dart' + +// Datadog 초기화 - [DatadogConfiguration.firstPartyHosts] 구성원으로 설정 +// Datadog 분산 추적 활성화 +final config = DatadogConfiguration( + // ... + firstPartyHosts = ['localhost'] +) + +// gRPC 채널 생성 +final channel = ClientChannel( + 'localhost', + port: 50051, + options: ChannelOptions( + // ... + ), +); + +// 지원되는 채널을 사용해 gRPC 인터셉터 생성 +final datadogInterceptor = DatadogGrpcInterceptor(DatadogSdk.instance, channel); + +// Datadog 인터셉터를 패스하는 gRPC 생성 +final stub = GreeterClient(channel, interceptors: [datadogInterceptor]); +``` + +## GraphQL (gql_link) + +Datadog `graphql_flutter` 및 `ferry`를 포함한 대부분의 GraphQL Flutter 라이브러리에서 사용할 수 있도록 [`datadog_gql_link`][1]을 제공합니다. 이 링크는 GraphQL 요청을 RUM 리소스로서 자동으로 추적하고, 쿼리 이름, 변이 이름 및 변수를 리소스의 속성으로 추가하며, APM에서 분산 추적을 활성화합니다. + +### 설정 + +`pubspec.yaml` 또는 터미널에서 `flutter pub add datadog_gql_link`를 실행하여 `datadog_gql_link`를 추가합니다. + +```yaml +dependencies: + # Other dependencies + datadog_gql_link: ^1.0.0 +``` + +GraphQL 링크를 생성할 때 종료 링크 위에 `DatadogGqlLink`를 추가합니다. 다음 에를 참고하세요. + +```dart +final graphQlUrl = "https://example.com/graphql"; + +final link = Link.from([ + DatadogGqlLink(DatadogSdk.instance, Uri.parse(graphQlUrl)), + HttpLink(graphQlUrl), +]); +``` + +`datadog_tracking_http_client`를 사용해 GraphQL 외 네트워크 호출을 추적하는 경우 GraphQL 엔드포인트에 대한 요청을 무시하도록 추적 플러그인을 구성해야 합니다. 그렇지 않으면 GraphQL 리소스가 두 번 보고되고 APM 추적이 중단될 수 있습니다. `datadog_tracking_http_client` 버전 2.1.0에 추가된 `ignoreUrlPatterns` 매개변수를 사용하여 GraphQL 엔드포인트를 무시하세요. + +```dart +final datadogConfig = DatadogConfiguration( + // 내 구성 + )..enableHttpTracking( + ignoreUrlPatterns: [ + RegExp('example.com/graphql'), + ], + ); +``` + + + +## 참고 자료 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://pub.dev/packages/datadog_gql_link +[2]: https://pub.dev/packages?q=go_router +[3]: https://github.com/flutter/flutter/issues/112196 +[4]: https://pub.dev/packages/auto_route +[5]: https://pub.dev/packages/beamer +[6]: https://pub.dev/packages/datadog_grpc_interceptor +[7]: https://pub.dev/packages/grpc +[8]: https://pub.dev/packages/webview_flutter +[9]: https://pub.dev/packages/flutter_inappwebview +[10]: /ko/real_user_monitoring/mobile_and_tv_monitoring/web_view_tracking?tab=flutter \ No newline at end of file diff --git a/content/ko/real_user_monitoring/mobile_and_tv_monitoring/ios/troubleshooting.md b/content/ko/real_user_monitoring/mobile_and_tv_monitoring/ios/troubleshooting.md new file mode 100644 index 0000000000000..fecb20bee49f2 --- /dev/null +++ b/content/ko/real_user_monitoring/mobile_and_tv_monitoring/ios/troubleshooting.md @@ -0,0 +1,101 @@ +--- +aliases: +- /ko/real_user_monitoring/mobile_and_tv_monitoring/troubleshooting/ios/ +description: iOS 모니터링 문제를 해결하는 방법을 알아보세요. +further_reading: +- link: https://github.com/DataDog/dd-sdk-ios + tag: 소스 코드 + text: dd-sdk-ios 소스 코드 +- link: /real_user_monitoring + tag: 설명서 + text: Datadog 실제 사용자 모니터링 +title: iOS SDK 문제 해결 +--- + +## 개요 + +Datadog RUM을 사용하면서 예기지 못한 동작을 경험하였다면 이 가이드를 통해 빠르게 문제를 해결하세요. 문제가 지속되면 [Datadog 지원팀][1]에 문의하여 추가 지원을 받으세요. + +## Datadog SDK 초기화가 적절하게 완료되었는지 확인 + +Datadog SDK를 구성하고 최초로 앱을 실행한 후 Xcode의 디버거 콘솔을 확인합니다. 잘못 구성된 경우, SDK가 여러 일관성 점검과 출력 관련 경고를 구축합니다. + +## 디버깅 +애플리케이션 작성 시 `verbosityLevel` 값을 설정하여 개발 로그를 활성화할 수 있습니다. 제공된 수준보다 높은 우선순위를 지닌 SDK 관련 메시지는 Xcode의 디버거 콘솔에 출력됩니다. + +```swift +Datadog.verbosityLevel = .debug +``` + +그러면 아래와 같은 유사 출력이 표시되며, 이는 RUM 데이터 배치가 제대로 업로드되었음을 나타냅니다. +``` +[DATADOG SDK] 🐶 → 17:23:09.849 [DEBUG] ⏳ (rum) Uploading batch... +[DATADOG SDK] 🐶 → 17:23:10.972 [DEBUG] → (rum) accepted, won't be retransmitted: success +``` + +**권장 사항:** `DEBUG` 구성에서 `Datadog.verbosityLevel`을 사용하고 `RELEASE`에서 설정 해제합니다. + +## 자체적인 세션 위임을 통해 `DDURLSessionDelegate` 사용하기 + +`DDURLSessionDelegate`을 사용해 [네트워크 요청을 자동으로 추적][2]하려 하나, 앱에 이미 자체적인 세션 위임이 구현된 경우 _상속_ 또는 _구성_ 패턴을 사용하여 `DDURLSessionDelegate`으로 호출을 전달할 수 있습니다. + +_상속_ 패턴을 사용할 때는 사용자 정의 위임의 기본 클래스로 `DDURLSessionDelegate`을 사용하고 재정의된 메서드에서 `super` 구현을 호출해야 합니다. 다음 예를 참고하세요. + +```swift +class YourCustomDelegateURLSessionDelegate: DDURLSessionDelegate { + override func urlSession(_ session: URLSession, task: URLSessionTask, didCompleteWithError error: Error?) { + super.urlSession(session, task: task, didCompleteWithError: error) // forward to Datadog delegate + /* your custom logic */ + } +} +``` + +_구성_ 패턴을 사용할 때는 Datadog의 `__URLSessionDelegateProviding` 프로토콜을 활용하여 `DDURLSessionDelegate`의 내부 인스턴스를 유지하고 호출을 `ddURLSessionDelegate`로 전달합니다 . 다음 예를 참고하세요. + +```swift +private class YourCustomDelegateURLSessionDelegate: NSObject, URLSessionTaskDelegate, URLSessionDataDelegate, __URLSessionDelegateProviding { + // MARK: - __URLSessionDelegateProviding conformance + + let ddURLSessionDelegate = DDURLSessionDelegate() + + // MARK: - __URLSessionDelegateProviding handling + + func urlSession(_ session: URLSession, task: URLSessionTask, didFinishCollecting metrics: URLSessionTaskMetrics) { + ddURLSessionDelegate.urlSession(session, task: task, didFinishCollecting: metrics) // Datadog 위임으로 전달 + /* your custom logic */ + } + + func urlSession(_ session: URLSession, task: URLSessionTask, didCompleteWithError error: Error?) { + ddURLSessionDelegate.urlSession(session, task: task, didCompleteWithError: error) // Datadog 위임으로 전달 + /* your custom logic */ + } + + func urlSession(_ session: URLSession, dataTask: URLSessionDataTask, didReceive data: Data) { + ddURLSessionDelegate.urlSession(session, dataTask: dataTask, didReceive: data) // Datadog 위임으로 전달 + /* your custom logic */ + } +} +``` +**참고**: _구성_을 사용하는 경우 `ddURLSessionDelegate`은 [`__URLSessionDelegateProviding` 프로토콜 코멘트][3] 목록에 있는 모든 필수 호출을 수신해야 합니다. 위임에서는 다음이 필요합니다. +* `URLSessionTaskDelegate` 구현 및 전달: + * [`urlSession(_:task:didFinishCollecting:)`][4] + * [`urlSession(_:task:didCompleteWithError:)`][5] +* `URLSessionDataDelegate` 구현 및 전달: + * [`urlSession(_:dataTask:didReceive:)`][6] + +## "Deobfuscation failed" 경고 + +스택 트레이스에 대한 난독화 해제에 실패하면 경고가 표시됩니다. 스택 트레이스가 아예 난독화되지 않은 경우 이 경고를 무시해도 됩니다. 그렇지 않은 경우, [RUM 디버그 기호 페이지][7]를 사용하여 업로드된 모든 dSYM을 확인하세요. [RUM 디버그 기호로 난독화된 스택 트레이스 조사][8]를 참조하세요. + +## 참고 자료 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ko/help +[2]: /ko/real_user_monitoring/mobile_and_tv_monitoring/ios/advanced_configuration/?tab=swift#automatically-track-network-requests +[3]: https://github.com/DataDog/dd-sdk-ios/blob/56e972a6d3070279adbe01850f51cb8c0c929c52/DatadogInternal/Sources/NetworkInstrumentation/URLSession/DatadogURLSessionDelegate.swift#L14 +[4]: https://developer.apple.com/documentation/foundation/urlsessiontaskdelegate/1643148-urlsession +[5]: https://developer.apple.com/documentation/foundation/urlsessiontaskdelegate/1411610-urlsession +[6]: https://developer.apple.com/documentation/foundation/urlsessiondatadelegate/1411528-urlsession +[7]: https://app.datadoghq.com/source-code/setup/rum +[8]: /ko/real_user_monitoring/guide/debug-symbols \ No newline at end of file diff --git a/content/ko/real_user_monitoring/mobile_and_tv_monitoring/setup/android.md b/content/ko/real_user_monitoring/mobile_and_tv_monitoring/setup/android.md new file mode 100644 index 0000000000000..2bc321b6e8678 --- /dev/null +++ b/content/ko/real_user_monitoring/mobile_and_tv_monitoring/setup/android.md @@ -0,0 +1,513 @@ +--- +aliases: +- /ko/real_user_monitoring/android/ +code_lang: android +code_lang_weight: 10 +further_reading: +- link: /real_user_monitoring/mobile_and_tv_monitoring/advanced_configuration/android + tag: 설명서 + text: RUM 안드로이드 고급 설정 +- link: https://github.com/DataDog/dd-sdk-android + tag: 소스 코드 + text: dd-sdk-android를 위한 소스 코드 +- link: /real_user_monitoring + tag: 설명서 + text: Datadog RUM 탐색 +title: RUM Android 및 Android TV 모니터링 설정 +type: multi-code-lang +--- +## 개요 + +이 페이지에서는 Android SDK를 사용하여 [실제 사용자 모니터링(RUM)][1] 및 [Error Tracking][2] 모두에 애플리케이션을 계측하는 방법을 설명합니다. 아래 단계에 따라 RUM(Error Tracking 포함) 또는 Error Tracking(독립형 제품으로 구매한 경우)을 사용하여 애플리케이션을 계측할 수 있습니다. + +Datadog 안드로이드 SDK는 안드로이드 5.0+(API 레벨 21) 및 안드로이드 TV를 지원합니다. + +## 설정 + +### UI에서 애플리케이션 세부 정보를 지정합니다. + +1. Datadog SDK를 종속성으로 선언합니다. +2. UI에서 애플리케이션 세부 정보를 지정합니다. +3. 애플리케이션 컨텍스트를 사용하여 Datadog SDK를 초기화합니다. +4. 데이터 전송을 시작하려면 기능을 활성화합니다. +5. 인터셉터를 초기화하여 네트워크 이벤트를 추적합니다. + +### Datadog SDK를 종속성으로 선언합니다. + +애플리케이션 모듈의 **애플리케이션 모듈** `build.gradle` 파일에 [dd-sdk-android-rum][3] 및 [Gradle 플러그인][4]을 종속성으로 선언합니다. + +```groovy +buildscript { + dependencies { + classpath("com.datadoghq:dd-sdk-android-gradle-plugin:x.x.x") + } +} +plugins { + id("com.datadoghq.dd-sdk-android-gradle-plugin") + //(...) +} +android { + //(...) +} +dependencies { + implementation "com.datadoghq:dd-sdk-android-rum:x.x.x" + //(...) +} + +``` + +### UI에서 애플리케이션 세부 정보를 지정합니다. +{{< tabs >}} +{{% tab "RUM" %}} + +1. [디지털 경험** > **애플리케이션 추가**][1]로 이동합니다. +2. `android`를 애플리케이션 유형으로 선택하고 애플리케이션 이름을 입력하여 고유한 Datadog 애플리케이션 ID 및 클라이언트 토큰을 생성합니다. +3. 웹 뷰를 계측하려면 **웹 뷰 계측** 토글을 클릭합니다. 자세한 내용은 [웹 뷰 트래킹][2]을 참조하세요. +4. 클라이언트 IP 또는 위치 정보 데이터에 대한 자동 사용자 데이터 수집을 사용하지 않으려면 해당 설정의 토글을 사용합니다. 자세한 내용은 [RUM Android 데이터 수집][3]을 참조하세요. + + {{< img src="real_user_monitoring/android/android-new-application.png" alt="Datadog에서 Android용 RUM 애플리케이션 만들기" style="width:90%;">}} + +[1]: https://app.datadoghq.com/rum/application/create +[2]: /ko/real_user_monitoring/android/web_view_tracking/ +[3]: /ko/real_user_monitoring/android/data_collected/ + +{{% /tab %}} +{{% tab "Error Tracking" %}} + +1. [Error Tracking** > **설정** > **브라우저 및 모바일** > **애플리케이션 추가**][1]로 이동합니다. +2. `android`를 애플리케이션 유형으로 선택하고 애플리케이션 이름을 입력하여 고유한 Datadog 애플리케이션 ID 및 클라이언트 토큰을 생성합니다. +3. 웹 뷰를 계측하려면 **웹 뷰 계측** 토글을 클릭합니다. 자세한 내용은 [웹 뷰 트래킹][2]을 참조하세요. +4. 클라이언트 IP 또는 지리적 위치 데이터에 대한 자동 사용자 데이터 수집을 사용하지 않으려면 해당 설정의 토글을 사용하세요. 자세한 내용은 [Android 데이터 수집][3]을 참조하세요. + + {{< img src="real_user_monitoring/error_tracking/mobile-new-application.png" alt="Datadog에서 Android 애플리케이션 생성" style="width:90%;">}} + +[1]: https://app.datadoghq.com/error-tracking/settings/setup/client +[2]: /ko/real_user_monitoring/android/web_view_tracking/ +[3]: /ko/real_user_monitoring/android/data_collected/ + +{{% /tab %}} +{{< /tabs >}} + +데이터의 안전을 보장하려면 클라이언트 토큰을 사용해야 합니다. [Datadog API 키][5]만 사용하여 Datadog SDK를 구성하는 경우 Android 애플리케이션의 APK 바이트 코드에 클라이언트 측에 노출됩니다. + +클라이언트 토큰 설정에 대한 자세한 내용은 [클라이언트 토큰 설명서][6]를 참조하세요. + +### 애플리케이션 컨텍스트를 사용하여 Datadog SDK 초기화 + +초기화 스니펫에서 환경 이름, 서비스 이름 및 버전 번호를 설정합니다. 아래 예에서 `APP_VARIANT_NAME`은 데이터를 생성하는 애플리케이션의 변형을 지정합니다. 자세한 내용은 [태그 사용][7]을 참조하세요. + +EU 사용자를 위한 GDPR 준수를 추가하려면 [`trackingConsent`][8]을 참조하세요. 라이브러리를 초기화하려면 [기타 구성 옵션][9]을 참조하세요. + +{{< site-region region="us" >}} +{{< tabs >}} +{{% tab "Kotlin" %}} +```kotlin +class SampleApplication : Application() { + override fun onCreate() { + super.onCreate() + val configuration = Configuration.Builder( + clientToken = , + env = , + variant = + ).build() + Datadog.initialize(this, configuration, trackingConsent) + } +} +``` +{{% /tab %}} +{{% tab "Java" %}} +```java +public class SampleApplication extends Application { + @Override + public void onCreate() { + super.onCreate(); + Configuration configuration = + new Configuration.Builder(, , ) + .build(); + Datadog.initialize(this, configuration, trackingConsent); + } +} +``` +{{% /tab %}} +{{< /tabs >}} +{{< /site-region >}} + +{{< site-region region="eu" >}} +{{< tabs >}} +{{% tab "Kotlin" %}} +```kotlin +class SampleApplication : Application() { + override fun onCreate() { + super.onCreate() + val configuration = Configuration.Builder( + clientToken = , + env = , + variant = + ) + .useSite(DatadogSite.EU1) + .build() + Datadog.initialize(this, configuration, trackingConsent) + } +} +``` +{{% /tab %}} +{{% tab "Java" %}} +```java +public class SampleApplication extends Application { + @Override + public void onCreate() { + super.onCreate(); + Configuration configuration = + new Configuration.Builder(, , ) + .useSite(DatadogSite.EU1) + .build(); + Datadog.initialize(this, configuration, trackingConsent); + } +} +``` +{{% /tab %}} +{{< /tabs >}} +{{< /site-region >}} + +{{< site-region region="us3" >}} +{{< tabs >}} +{{% tab "Kotlin" %}} +```kotlin +class SampleApplication : Application() { + override fun onCreate() { + super.onCreate() + val configuration = Configuration.Builder( + clientToken = , + env = , + variant = + ) + .useSite(DatadogSite.US3) + .build() + Datadog.initialize(this, configuration, trackingConsent) + } +} +``` +{{% /tab %}} +{{% tab "Java" %}} +```java +public class SampleApplication extends Application { + @Override + public void onCreate() { + super.onCreate(); + Configuration configuration = + new Configuration.Builder(, , ) + .useSite(DatadogSite.US3) + .build(); + Datadog.initialize(this, configuration, trackingConsent); + } +} +``` +{{% /tab %}} +{{< /tabs >}} +{{< /site-region >}} + +{{< site-region region="us5" >}} +{{< tabs >}} +{{% tab "Kotlin" %}} +```kotlin +class SampleApplication : Application() { + override fun onCreate() { + super.onCreate() + val configuration = Configuration.Builder( + clientToken = , + env = , + variant = + ) + .useSite(DatadogSite.US5) + .build() + Datadog.initialize(this, configuration, trackingConsent) + } +} +``` +{{% /tab %}} +{{% tab "Java" %}} +```java +public class SampleApplication extends Application { + @Override + public void onCreate() { + super.onCreate(); + Configuration configuration = + new Configuration.Builder(, , ) + .useSite(DatadogSite.US5) + .build(); + Datadog.initialize(this, configuration, trackingConsent); + } +} +``` +{{% /tab %}} +{{< /tabs >}} +{{< /site-region >}} + +{{< site-region region="gov" >}} +{{< tabs >}} +{{% tab "Kotlin" %}} +```kotlin +class SampleApplication : Application() { + override fun onCreate() { + super.onCreate() + val configuration = Configuration.Builder( + clientToken = , + env = , + variant = + ) + .useSite(DatadogSite.US1_FED) + .build() + Datadog.initialize(this, configuration, trackingConsent) + } +} +``` +{{% /tab %}} +{{% tab "Java" %}} +```java +public class SampleApplication extends Application { + @Override + public void onCreate() { + super.onCreate(); + Configuration configuration = + new Configuration.Builder(, , ) + .useSite(DatadogSite.US1_FED) + .build(); + Datadog.initialize(this, configuration, trackingConsent); + } +} +``` +{{% /tab %}} +{{< /tabs >}} +{{< /site-region >}} + +{{< site-region region="ap1" >}} +{{< tabs >}} +{{% tab "Kotlin" %}} +```kotlin +class SampleApplication : Application() { + override fun onCreate() { + super.onCreate() + val configuration = Configuration.Builder( + clientToken = , + env = , + variant = + ) + .useSite(DatadogSite.AP1) + .build() + Datadog.initialize(this, configuration, trackingConsent) + } +} +``` +{{% /tab %}} +{{% tab "Java" %}} +```java +public class SampleApplication extends Application { + @Override + public void onCreate() { + super.onCreate(); + Configuration configuration = + new Configuration.Builder(, , ) + .useSite(DatadogSite.AP1) + .build(); + Datadog.initialize(this, configuration, trackingConsent); + } +} +``` +{{% /tab %}} +{{< /tabs >}} +{{< /site-region >}} + +초기화 자격 증명에는 애플리케이션의 변형 이름이 필요하며 `BuildConfig.FLAVOR` 값을 사용합니다. 이 변형을 사용하면 SDK는 애플리케이션에서 보고된 오류를 Gradle 플러그인에서 업로드한 매핑 파일과 일치시킬 수 있습니다. 변형이 없는 경우 자격 증명은 빈 문자열을 사용합니다. + +Gradle 플러그인은 빌드 시점에 적절한 ProGuard `mapping.txt` 파일을 자동으로 업로드하여 난독화된 오류 스택 추적을 볼 수 있도록 합니다. 자세한 내용은 [Android 오류 추적][10]을 참조하세요. + +### 샘플 세션 + +
세션 샘플 속도 구성은 Error Tracking에는 적용되지 않습니다.
+ +애플리케이션이 Datadog로 전송하는 데이터를 제어하려면 [RUM 초기화][11] 시 세션의 샘플 속도를 지정할 수 있습니다. 비율은 0에서 100 사이의 백분율입니다. 기본적으로 `sessionSamplingRate`은 100으로 설정되어 있습니다(모든 세션 유지). + +```kotlin +val rumConfig = RumConfiguration.Builder(applicationId) + // 여기서 RUM 세션의 75%가 Datadog으로 전송됩니다. + .setSessionSampleRate(75.0f) + .build() +Rum.enable(rumConfig) +``` + +### 추적 동의 설정(GDPR 준수) + +GDPR 규정을 준수하기 위해 SDK 초기화 시 추적 동의 값을 입력해야 합니다. + +추적 동의는 다음 값 중 하나를 선택할 수 있습니다. + +- `TrackingConsent.PENDING`: (기본값) SDK가 데이터 수집 및 일괄 처리를 시작하지만 해당 데이터를 + 데이터 수집 엔드포인트로 전송하지는 않습니다. SDK에서는 새 추적 동의 값으로 일괄 처리 데이터 작업이 결정될 때까지 대기합니다. +- `TrackingConsent.GRANTED`: SDK가 데이터를 수집하고 데이터 수집 엔드포인트로 전송합니다. +- `TrackingConsent.NOT_GRANTED`: SDK는 어떠한 데이터도 수집하지 않습니다. 로그, 추적 또는 이벤트를 수동으로 전송할 수 없습니다. + +SDK를 초기화한 후 추적 동의를 업데이트하려면 `Datadog.setTrackingConsent()`를 호출합니다. SDK는 새 동의에 따라 동작을 변경합니다. 예를 들어, 현재 추적 동의가 `TrackingConsent.PENDING`이고 다음으로 업데이트하는 경우: + +- `TrackingConsent.GRANTED`: SDK에서 기존 일괄 처리된 전체 데이터와 향후 데이터를 데이터 수집 엔드포인트로 직접 전송합니다. +- `TrackingConsent.NOT_GRANTED`: SDK에서 일괄 처리된 데이터 전체를 삭제하고 이후 데이터를 수집하지 않습니다. + + +### 데이터 전송을 시작하려면 기능을 활성화하세요. + +Android SDK에서 데이터 전송을 시작하도록 설정합니다. + +{{< tabs >}} +{{% tab "Kotlin" %}} + +```kotlin + val rumConfig = RumConfiguration.Builder(applicationId) + .trackInteractions() + .trackLongTasks(durationThreshold) // Not applicable to Error Tracking + .useViewTrackingStrategy(strategy) + .build() + Rum.enable(rumConfig) +``` + +{{% /tab %}} +{{% tab "Java" %}} + +```java + RumConfiguration rumConfig = new RumConfiguration.Builder(applicationId) + .trackInteractions() + .trackLongTasks(durationThreshold) // Not applicable to Error Tracking + .useViewTrackingStrategy(strategy) + .build(); + Rum.enable(rumConfig); +``` + +{{% /tab %}} +{{< /tabs >}} + +모든 조회수(활동, 조각 등)를 자동으로 추적하려면 [`ViewTrackingStrategy`][12]를 참조하세요. + +### 인터셉터를 초기화하여 네트워크 이벤트 추적하기 + +네트워크 이벤트 추적을 위한 인터셉터를 초기화합니다. + +1. 분산 추적을 사용하려면 [트레이스 기능을 추가하고 활성화][13]하세요. +2. 모듈 수준 `build.gradle` 파일에서 `dd-sdk-android-okhttp` 라이브러리에 Gradle 종속성을 추가합니다: + + ```groovy + dependencies { + implementation "com.datadoghq:dd-sdk-android-okhttp:x.x.x" + } + ``` + +3. OkHttp 요청을 리소스로 추적하려면 제공된 [인터셉터][14]를 추가하세요. + +{{< tabs >}} +{{% tab "Kotlin" %}} +```kotlin +val tracedHostsWithHeaderType = mapOf( + "example.com" to setOf( + TracingHeaderType.DATADOG, + TracingHeaderType.TRACECONTEXT), + "example.eu" to setOf( + TracingHeaderType.DATADOG, + TracingHeaderType.TRACECONTEXT)) +val okHttpClient = OkHttpClient.Builder() + .addInterceptor(DatadogInterceptor.Builder(tracedHostsWithHeaderType).build()) + .build() +``` +{{% /tab %}} +{{% tab "Java" %}} +```java +final Map> tracedHostsWithHeaderType = new HashMap<>(); +final Set datadogAndW3HeadersTypes = new HashSet<>(Arrays.asList(TracingHeaderType.DATADOG, TracingHeaderType.TRACECONTEXT)); +tracedHostsWithHeaderType.put("example.com", datadogAndW3HeadersTypes); +tracedHostsWithHeaderType.put("example.eu", datadogAndW3HeadersTypes); +OkHttpClient okHttpClient = new OkHttpClient.Builder() + .addInterceptor(new DatadogInterceptor.Builder(tracedHostsWithHeaderType).build()) + .build(); +``` +{{% /tab %}} +{{< /tabs >}} + +여기에는 `OkHttpClient`에서 처리된 각 요청이 리소스로 기록되며 모든 관련 정보(URL, 방법, 상태 코드 및 오류)가 자동으로 채워집니다. 보기가 활성화되어 있을 때 시작된 네트워크 요청만 추적됩니다. 애플리케이션이 백그라운드에 있을 때 요청을 추적하려면 [수동으로 보기 만들기][15]를 참조하세요. + +**참고**: 여러 개의 인터셉터를 사용하는 경우 `DatadogInterceptor`를 먼저 추가합니다. + +타사 제공업체 및 네트워크 요청의 [리소스 타이밍 자동 추적][16]을 위해 `OkHttpClient`에 `EventListener`를 추가할 수도 있습니다. + +## 백그라운드 이벤트 추적 + +애플리케이션이 백그라운드에 있을 때(예: 활성 보기를 사용할 수 없음) 크래시 및 네트워크 요청과 같은 이벤트를 추적할 수 있습니다. + +구성하는 동안 다음 코드 조각을 추가합니다. + +{{< tabs >}} +{{% tab "Kotlin" %}} +```kotlin +.trackBackgroundEvents(true) +``` +{{% /tab %}} +{{% tab "Java" %}} +```java +.trackBackgroundEvents(true) +``` +{{% /tab %}} +{{< /tabs >}} +

백그라운드 이벤트 추적으로 추가 세션이 발생하여 청구 금액에 영향을 미칠 수 있습니다. 자세한 내용은 Datadog 지원팀에 문의하세요.

+
+ +## Kotlin 확장 프로그램 + +### `Closeable` 확장 + +`useMonitored` 메서드를 사용하여 `Closeable` 인스턴스 사용량을 모니터링하여 오류를 Datadog에 전송하고 이후 리소스를 닫을 수 있습니다. + +```kotlin +val closeable: Closeable = ... +closeable.useMonitored { + // Your code here +} + +``` + +### 리소스로서 로컬 자산 추적 + +`getAssetAsRumResource` 확장 메서드를 사용하여 어셋에 대한 액세스를 추적할 수 있습니다: + +```kotlin +val inputStream = context.getAssetAsRumResource(fileName) +``` + +`getRawResAsRumResource` 확장 메서드를 사용하여 로컬 리소스 사용량을 추적할 수 있습니다: + +```kotlin +val inputStream = context.getRawResAsRumResource(id) +``` + +## 디바이스가 오프라인일 때 데이터 전송 + +Android SDK는 사용자 장치가오프라인 상태일 때 데이터 가용성을 보장합니다. 네트워크가 연결이 원활하지 않은 지역 또는 장치 배터리가 너무 부족한 경우 모든 이벤트는 먼저 로컬 장치에 일괄적으로 저장됩니다. + +각 배치는 수집 사양을 따릅니다. 배치는 네트워크가 사용 가능한 즉시 전송됩니다. 또한 배터리는 Datadog SDK 최종 사용자 경험에 영향을 주지 않을 만큼 충분합니다. 애플리케이션이 포그라운드에 있는 동안 네트워크를 사용할 수 없거나 데이터 업로드에 실패하면 배치가 성공적으로 전송될 때까지 배치가 유지됩니다. + +즉, 사용자가 오프라인 상태에서 애플리케이션을 열어도 데이터가 손실되지 않습니다. SDK가 너무 많은 디스크 공간을 사용하지 않도록 디스크의 데이터가 너무 오래되면 자동으로 삭제됩니다. + +## 참고 자료 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ko/real_user_monitoring/ +[2]: /ko/error_tracking/ +[3]: https://github.com/DataDog/dd-sdk-android/tree/develop/features/dd-sdk-android-rum +[4]: https://github.com/DataDog/dd-sdk-android-gradle-plugin +[5]: /ko/account_management/api-app-keys/#api-keys +[6]: /ko/account_management/api-app-keys/#client-tokens +[7]: /ko/getting_started/tagging/using_tags/#rum--session-replay +[8]: #set-tracking-consent-gdpr-compliance +[9]: /ko/real_user_monitoring/mobile_and_tv_monitoring/advanced_configuration/android/#initialization-parameters +[10]: /ko/real_user_monitoring/error_tracking/android/#upload-your-mapping-file +[11]: https://app.datadoghq.com/rum/application/create/ +[12]: /ko/real_user_monitoring/mobile_and_tv_monitoring/advanced_configuration/android/#automatically-track-views +[13]: /ko/tracing/trace_collection/dd_libraries/android/?tab=kotlin +[14]: https://square.github.io/okhttp/interceptors/ +[15]: /ko/real_user_monitoring/mobile_and_tv_monitoring/advanced_configuration/android/#custom-views +[16]: /ko/real_user_monitoring/mobile_and_tv_monitoring/advanced_configuration/android/#automatically-track-network-requests \ No newline at end of file diff --git a/content/ko/real_user_monitoring/mobile_and_tv_monitoring/setup/ios.md b/content/ko/real_user_monitoring/mobile_and_tv_monitoring/setup/ios.md new file mode 100644 index 0000000000000..0f9619b11cd34 --- /dev/null +++ b/content/ko/real_user_monitoring/mobile_and_tv_monitoring/setup/ios.md @@ -0,0 +1,530 @@ +--- +aliases: +- /ko/real_user_monitoring/ios +- /ko/real_user_monitoring/ios/getting_started +- /ko/real_user_monitoring/ios/swiftui/ +- /ko/real_user_monitoring/swiftui/ +- /ko/real_user_monitoring/mobile_and_tv_monitoring/swiftui/ +beta: true +code_lang: ios +code_lang_weight: 20 +description: iOS 및 tvOS 애플리케이션에서 RUM 또는 Error Tracking 데이터를 수집합니다. +further_reading: +- link: /real_user_monitoring/mobile_and_tv_monitoring/advanced_configuration/ios + tag: 설명서 + text: RUM iOS 고급 구성 +- link: https://github.com/DataDog/dd-sdk-ios + tag: 소스 코드 + text: dd-sdk-ios 소스 코드 +- link: /real_user_monitoring + tag: 설명서 + text: RUM 데이터를 탐색하는 방법 알아보기 +- link: /real_user_monitoring/error_tracking/ios/ + tag: 설명서 + text: iOS 오류 추적 방법 알아보기 +- link: /real_user_monitoring/ios/swiftui/ + tag: 설명서 + text: SwiftUI 애플리케이션 계측에 대해 알아보기 +- link: /real_user_monitoring/mobile_and_tv_monitoring/supported_versions/ios/ + tag: 설명서 + text: RUM iOS 및 tvOS 모니터링 지원 버전 +title: iOS 및 tvOS 모니터링 설정 +type: multi-code-lang +--- + +## 개요 + +이 페이지에서는 iOS SDK를 사용하여 [Real User Monitoring(RUM)][1] 및 [Error Tracking][2] 모두에서 애플리케이션을 계측하는 방법을 설명합니다. 아래 단계에 따라 RUM(Error Tracking 포함) 또는 Error Tracking(독립형 제품으로 구매한 경우)을 사용하여 애플리케이션을 계측할 수 있습니다. + +## 설정 + +1. SDK를 종속성으로 선언합니다. +2. UI에서 애플리케이션 세부 정보를 지정합니다. +3. 라이브러리를 초기화합니다. +4. Datadog 모니터를 초기화하고 `URLSessionInstrumentation`를 활성화하여 데이터 전송을 시작합니다. + +### SDK를 종속성으로 선언 + +패키지 관리자에 따라 라이브러리를 종속성으로 선언하세요. Swift 패키지 관리자(SPM)를 권장합니다. + +{{< tabs >}} +{{% tab "Swift Package Manager (SPM)" %}} + +Apple의 Swift 패키지 관리자를 사용하여 통합하려면 다음을 종속 항목으로 `Package.swift`에 추가합니다. +```swift +.package(url: "https://github.com/Datadog/dd-sdk-ios.git", .upToNextMajor(from: "2.0.0")) +``` + +프로젝트에서 다음 라이브러리를 연결합니다. +``` +DatadogCore +DatadogRUM +``` + +{{% /tab %}} +{{% tab "CocoaPods" %}} + +[CocoaPods][1]을 사용하여 `dd-sdk-ios`을 설치할 수 있습니다. +``` +pod 'DatadogCore' +pod 'DatadogRUM' +``` + + +[1]: https://cocoapods.org/ +{{% /tab %}} +{{% tab "Carthage" %}} + +[Carthage][1]를 사용하여 `dd-sdk-ios`를 설치할 수 있습니다. +``` +github "DataDog/dd-sdk-ios" +``` + +Xcode에서 다음 프레임워크를 연결합니다. +``` +DatadogInternal.xcframework +DatadogCore.xcframework +DatadogRUM.xcframework +``` + +[1]: https://github.com/Carthage/Carthage +{{% /tab %}} +{{< /tabs >}} + +### UI에서 애플리케이션 세부 정보를 지정합니다. + +{{< tabs >}} +{{% tab "RUM" %}} + +1. [**Digital Experience** > **Add an Application**][1]로 이동합니다. +2. 애플리케이션 유형으로 `iOS`를 선택하고 애플리케이션 이름을 입력하여 고유한 Datadog 애플리케이션 ID와 클라이언트 토큰을 생성합니다. +3. 웹 뷰를 계측하려면 ***Instrument your webviews** 토글을 클릭합니다. 자세한 내용은 [웹 뷰 트래킹][2]을 참조하세요. +4. 클라이언트 IP 또는 지리적 위치 데이터에 대한 자동 사용자 데이터 수집을 사용하지 않으려면 해당 설정의 토글을 사용하세요. 자세한 내용은 [RUM iOS 데이터 수집][3]을 참조하세요. + + {{< img src="real_user_monitoring/ios/ios-create-application.png" alt="Datadog에서 iOS용 RUM 애플리케이션 생성" style="width:100%;border:none" >}} + +[1]: https://app.datadoghq.com/rum/application/create +[2]: /ko/real_user_monitoring/ios/web_view_tracking/ +[3]: /ko/real_user_monitoring/ios/data_collected/ + +{{% /tab %}} +{{% tab "Error Tracking" %}} + +1. [**Error Tracking** > **Settings** > **Browser and Mobile** > **Add an Application**][1]으로 이동합니다. +2. 애플리케이션 유형으로 `iOS`를 선택하고 애플리케이션 이름을 입력하여 고유한 Datadog 애플리케이션 ID와 클라이언트 토큰을 생성합니다. +3. 웹 뷰를 계측하려면 **웹 뷰 계측** 토글을 클릭합니다. 자세한 내용은 [웹 뷰 트래킹][2]을 참조하세요. +4. 클라이언트 IP 또는 지리적 위치 데이터에 대한 자동 사용자 데이터 수집을 사용하지 않으려면 해당 설정의 토글을 사용합니다. 자세한 내용은 [iOS 데이터 수집][3]을 참조하세요. + + {{< img src="real_user_monitoring/error_tracking/mobile-new-application.png" alt="Datadog에서 iOS 애플리케이션 생성" style="width:90%;">}} + +[1]: https://app.datadoghq.com/error-tracking/settings/setup/client +[2]: /ko/real_user_monitoring/ios/web_view_tracking/ +[3]: /ko/real_user_monitoring/ios/data_collected/ + +{{% /tab %}} +{{< /tabs >}} + +데이터의 안전을 보장하려면 클라이언트 토큰을 사용해야 합니다. Datadog API 키][3]만 사용하여 `dd-sdk-ios` 라이브러리를 구성하는 경우 iOS 애플리케이션의 바이트 코드에 클라이언트 측에 노출됩니다. + +클라이언트 토큰 설정에 대한 자세한 내용은 [클라이언트 토큰 설명서][4]를 참조하세요. + +### 라이브러리 초기화 + +초기화 스니펫에서 환경 이름, 서비스 이름 및 버전 번호를 설정합니다. 아래 예제에서 `app-name`은 데이터를 생성하는 애플리케이션의 버전을 지정합니다. + +자세한 내용은 [태그 사용][5]을 참조하세요. + +{{< site-region region="us" >}} +{{< tabs >}} +{{% tab "Swift" %}} + +```swift +import DatadogCore + +Datadog.initialize( + with: Datadog.Configuration( + clientToken: "", + env: "", + service: "" + ), + trackingConsent: trackingConsent +) +``` +{{% /tab %}} +{{% tab "Objective-C" %}} +```objective-c +@import DatadogObjc; + +DDConfiguration *configuration = [[DDConfiguration alloc] initWithClientToken:@"" env:@""]; +configuration.service = @""; + +[DDDatadog initializeWithConfiguration:configuration + trackingConsent:trackingConsent]; +``` +{{% /tab %}} +{{< /tabs >}} +{{< /site-region >}} + +{{< site-region region="eu" >}} +{{< tabs >}} +{{% tab "Swift" %}} +```swift +import DatadogCore + +Datadog.initialize( + with: Datadog.Configuration( + clientToken: "", + env: "", + site: .eu1, + service: "" + ), + trackingConsent: trackingConsent +) +``` +{{% /tab %}} +{{% tab "Objective-C" %}} +```objective-c +@import DatadogObjc; + +DDConfiguration *configuration = [[DDConfiguration alloc] initWithClientToken:@"" env:@""]; +configuration.service = @""; +configuration.site = [DDSite eu1]; + +[DDDatadog initializeWithConfiguration:configuration + trackingConsent:trackingConsent]; +``` +{{% /tab %}} +{{< /tabs >}} +{{< /site-region >}} + +{{< site-region region="us3" >}} +{{< tabs >}} +{{% tab "Swift" %}} +```swift +import DatadogCore + +Datadog.initialize( + with: Datadog.Configuration( + clientToken: "", + env: "", + site: .us3, + service: "" + ), + trackingConsent: trackingConsent +) +``` +{{% /tab %}} +{{% tab "Objective-C" %}} +```objective-c +@import DatadogObjc; + +DDConfiguration *configuration = [[DDConfiguration alloc] initWithClientToken:@"" env:@""]; +configuration.service = @""; +configuration.site = [DDSite us3]; + +[DDDatadog initializeWithConfiguration:configuration + trackingConsent:trackingConsent]; +``` +{{% /tab %}} +{{< /tabs >}} +{{< /site-region >}} + +{{< site-region region="us5" >}} +{{< tabs >}} +{{% tab "Swift" %}} +```swift +import DatadogCore + +Datadog.initialize( + with: Datadog.Configuration( + clientToken: "", + env: "", + site: .us5, + service: "" + ), + trackingConsent: trackingConsent +) +``` +{{% /tab %}} +{{% tab "Objective-C" %}} +```objective-c +@import DatadogObjc; + +DDConfiguration *configuration = [[DDConfiguration alloc] initWithClientToken:@"" env:@""]; +configuration.service = @""; +configuration.site = [DDSite us5]; + +[DDDatadog initializeWithConfiguration:configuration + trackingConsent:trackingConsent]; +``` +{{% /tab %}} +{{< /tabs >}} +{{< /site-region >}} + +{{< site-region region="gov" >}} +{{< tabs >}} +{{% tab "Swift" %}} +```swift +import DatadogCore + +Datadog.initialize( + with: Datadog.Configuration( + clientToken: "", + env: "", + site: .us1_fed, + service: "" + ), + trackingConsent: trackingConsent +) +``` +{{% /tab %}} +{{% tab "Objective-C" %}} +```objective-c +@import DatadogObjc; + +DDConfiguration *configuration = [[DDConfiguration alloc] initWithClientToken:@"" env:@""]; +configuration.service = @""; +configuration.site = [DDSite us1_fed]; + +[DDDatadog initializeWithConfiguration:configuration + trackingConsent:trackingConsent]; +``` +{{% /tab %}} +{{< /tabs >}} +{{< /site-region >}} + +{{< site-region region="ap1" >}} +{{< tabs >}} +{{% tab "Swift" %}} +```swift +import DatadogCore + +Datadog.initialize( + with: Datadog.Configuration( + clientToken: "", + env: "", + site: .ap1, + service: "" + ), + trackingConsent: trackingConsent +) +``` +{{% /tab %}} +{{% tab "Objective-C" %}} +```objective-c +@import DatadogObjc; + +DDConfiguration *configuration = [[DDConfiguration alloc] initWithClientToken:@"" env:@""]; +configuration.service = @""; +configuration.site = [DDSite ap1]; + +[DDDatadog initializeWithConfiguration:configuration + trackingConsent:trackingConsent]; +``` +{{% /tab %}} +{{< /tabs >}} +{{< /site-region >}} + +iOS SDK에서는 SDK 초기화에서 제공된 옵션에 따라 사용자 세션을 자동으로 추적합니다. EU 사용자에 대한 GDPR 준수 및 기타 [초기화 매개변수][6]를 SDK 구성에 추가하려면 [추적 동의 설정 설명서](#set-tracking-consent-gdpr-compliance)를 참조하세요. + +### RUM 세션 예시 + +
Error Tracking에는 세션 샘플 속도 구성이 적용되지 않습니다.
+ +애플리케이션이 Datadog RUM으로 전송하는 데이터를 제어하려면 [RUM iOS SDK 초기화][7] 중에 RUM 세션의 샘플링 속도를 지정합니다. 비율은 0에서 100 사이의 백분율입니다. 기본적으로 `sessionSamplingRate`은 100으로 설정되어 있습니다(모든 세션 유지). + +예를 들어, 세션 사용량의 50%만 유지하려면 다음과 같이 하세요. + +{{< tabs >}} +{{% tab "Swift" %}} +```swift +let configuration = RUM.Configuration( + applicationID: "", + sessionSampleRate: 50 +) +``` +{{% /tab %}} +{{% tab "Objective-C" %}} +```objective-c +DDRUMConfiguration *configuration = [[DDRUMConfiguration alloc] initWithApplicationID:@""]; +configuration.sessionSampleRate = 50; +``` +{{% /tab %}} +{{< /tabs >}} + +### 추적 동의 설정(GDPR 준수) + +GDPR 규정을 준수하려면, RUM iOS 소프트웨어 개발 키트(SDK)는 초기화 시 추적 동의 값이 필요합니다. + +`trackingConsent` 설정은 다음 값 중 하나가 될 수 있습니다: + +1. `.pending`: RUM iOS 소프트웨어 개발 키트(SDK)는 데이터 수집 및 일괄 처리 작업을 시작하지만 해당 데이터를 Datadog으로 전송하지는 않습니다. RUM iOS소프트웨어 개발 키트(SDK)는 새로운 추적 동의 값을 기다렸다가 일괄 처리된 데이터로 실행할 작업을 결정합니다. +2. `.granted`: RUM iOS 소프트웨어 개발 키트(SDK)가 데이터 수집을 시작하고 Datadog으로 해당 데이터를 전송합니다. +3. `.notGranted`: RUM iOS SDK는 어떠한 데이터도 수집하지 않습니다. Datadog로 로그, 추적 또는 이벤트가 전송되지 않습니다. + + RUM iOS SDK 초기화 후 추적 동의 값을 변경하려면 `Datadog.set(trackingConsent:)` API 호출을 사용합니다. RUM iOS SDK에서 새로운 값에 따라 동작을 변경합니다. + +예를 들어 현재 추적 동의가 `.pending`인 경우는 다음과 같습니다. + +- 값을 `.granted`로 변경하면 RUM iOS 소프트웨어 개발 키트(SDK)는 현재 및 향후 모든 데이터를 Datadog 으로 전송합니다. +- 값을 `.notGranted`로 변경하면 RUM iOS 소프트웨어 개발 키트(SDK)는 현재 데이터를 모두 삭제하고 향후 데이터를 수집하지 않습니다. + +### Datadog 모니터 초기화 및 `URLSessionInstrumentation` 활성화 + +Datadog 모니터를 구성하고 등록합니다. 보통 `AppDelegate` 코드에 한 번만 등록하면 됩니다. + +{{< tabs >}} +{{% tab "Swift" %}} + +```swift +import DatadogRUM + +RUM.enable( + with: RUM.Configuration( + applicationID: "", + uiKitViewsPredicate: DefaultUIKitRUMViewsPredicate(), + uiKitActionsPredicate: DefaultUIKitRUMActionsPredicate(), + urlSessionTracking: RUM.Configuration.URLSessionTracking() + ) +) +``` +{{% /tab %}} +{{% tab "Objective-C" %}} +```objective-c +@import DatadogObjc; + +DDRUMConfiguration *configuration = [[DDRUMConfiguration alloc] initWithApplicationID:@""]; +configuration.uiKitViewsPredicate = [DDDefaultUIKitRUMViewsPredicate new]; +configuration.uiKitActionsPredicate = [DDDefaultUIKitRUMActionsPredicate new]; +[configuration setURLSessionTracking:[DDRUMURLSessionTracking new]]; + +[DDRUM enableWith:configuration]; +``` +{{% /tab %}} +{{% /tabs %}} + +`URLSession` 인스턴스에서 리소스로 전송된 요청을 모니터로 보내려면 위임 유형에 대해 `URLSessionInstrumentation`을 활성화하고 위임 인스턴스를 `URLSession`으로 전달합니다. + +{{< tabs >}} +{{% tab "Swift" %}} +```swift +URLSessionInstrumentation.enable( + with: .init( + delegateClass: .self + ) +) + +let session = URLSession( + configuration: .default, + delegate: (), + delegateQueue: nil +) +``` +{{% /tab %}} +{{% tab "Objective-C" %}} +```objective-c +DDURLSessionInstrumentationConfiguration *config = [[DDURLSessionInstrumentationConfiguration alloc] initWithDelegateClass:[ class]]; +[DDURLSessionInstrumentation enableWithConfiguration:config]; + +NSURLSession *session = [NSURLSession sessionWithConfiguration:[NSURLSessionConfiguration defaultSessionConfiguration] + delegate:[[ alloc] init] + delegateQueue:nil]; +``` +{{% /tab %}} +{{< /tabs >}} + + +### 뷰 계측 + +Datadog iOS SDK에서는 `SwiftUI` 애플리케이션의 뷰를 계측할 수 있습니다. 이 계측 기능은 하이브리드 `UIKit` 및 `SwiftUI` 애플리케이션에서도 작동합니다. + +`SwiftUI.View`를 계측하려면 보기 선언에 다음 메서드를 추가하세요. + +```swift +import SwiftUI +import DatadogRUM + +struct FooView: View { + + var body: some View { + FooContent { + ... + } + .trackRUMView(name: "Foo") + } +} +``` + +`trackRUMView(name:)` 메서드는 `SwiftUI` 뷰가 화면에서 나타나고 사라질 때 뷰를 시작하고 중지합니다. + +### 계측 탭 작업 + +Datadog iOS SDK에서 `SwiftUI` 애플리케이션의 탭 동작을 계측할 수 있습니다. 이 계측 기능은 하이브리드 `UIKit` 및 `SwiftUI` 애플리케이션에서도 작동합니다. + +`SwiftUI.View`에서 탭 작업을 계측하려면 보기 선언에 다음 메서드를 추가하세요. + +```swift +import SwiftUI +import DatadogRUM + +struct BarView: View { + + var body: some View { + Button("BarButton") { { + ... + } + .trackRUMTapAction(name: "Bar") + } +} +``` + +## 백그라운드 이벤트 추적 + +

백그라운드 이벤트 추적으로 추가 세션이 발생하여 청구 금액에 영향을 미칠 수 있습니다. 자세한 내용은 Datadog 지원팀에 문의하세요.

+
+ +애플리케이션이 백그라운드에서 동작할 때(예: 활성 보기를 사용할 수 없음) 크래시 및 네트워크 요청과 같은 이벤트를 추적할 수 있습니다. + +Datadog 설정에서 초기화하는 동안 다음 스니펫을 추가합니다: + +```swift +import DatadogRUM + +RUM.enable( + with: RUM.Configuration( + ... + trackBackgroundEvents: true + ) +) +``` + +## iOS 오류 추적 + +[iOS 크래시 보고 및 Error Tracking][7]에서는 애플리케이션의 모든 문제와 사용 가능한 최신 오류를 표시합니다. [RUM 탐색기)][9]에서 JSON을 포함한 오류 세부 정보 및 속성을 확인할 수 있습니다. + +## 디바이스가 오프라인일 때 데이터 전송 + +iOS SDK는 사용자 디바이스가 오프라인 상태일 때 데이터 가용성을 보장합니다. 네트워크가 약한 지역이나 디바이스 배터리가 부족할 경우 모든 이벤트는 먼저 로컬 디바이스에 일괄적으로 저장됩니다. 네트워크를 사용할 수 있고 배터리가 충분히 충전되는 즉시 iOS SDK 최종 사용자의 경험에 영향을 미치지 않는 방식으로 전송됩니다. 애플리케이션이 포그라운드에 있는 동안 네트워크를 사용할 수 없거나 데이터 업로드에 실패하면 성공적으로 전송될 때까지 배치가 유지됩니다. + +즉, 사용자가 오프라인 상태에서 애플리케이션을 열어도 데이터가 손실되지 않습니다. + +**참고**: iOS SDK에서 디스크 공간을 너무 많이 사용하지 않도록 하기 위해 디스크의 데이터가 너무 오래되면 자동으로 삭제됩니다. + +## 지원 버전 + +iOS SDK와 호환되는 운영 체제 버전 및 플랫폼 목록은 [지원되는 버전][10]을 참조하세요. + +## 참고 자료 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ko/real_user_monitoring/ +[2]: /ko/error_tracking/ +[3]: /ko/account_management/api-app-keys/#api-keys +[4]: /ko/account_management/api-app-keys/#client-tokens +[5]: /ko/getting_started/tagging/using_tags/#rum--session-replay +[6]: /ko/real_user_monitoring/ios/advanced_configuration/#initialization-parameters +[7]: https://github.com/DataDog/dd-sdk-ios +[8]: /ko/real_user_monitoring/error_tracking/ios/ +[9]: /ko/real_user_monitoring/explorer/ +[10]: /ko/real_user_monitoring/mobile_and_tv_monitoring/supported_versions/ios/ \ No newline at end of file diff --git a/content/ko/security/application_security/software_composition_analysis/_index.md b/content/ko/security/application_security/software_composition_analysis/_index.md new file mode 100644 index 0000000000000..d9a9e6612b5e1 --- /dev/null +++ b/content/ko/security/application_security/software_composition_analysis/_index.md @@ -0,0 +1,149 @@ +--- +algolia: + tags: + - Software Composition Analysis + - 취약성 관리 + - SCA + - AVM + - GuardDog +aliases: +- /ko/security/application_security/risk_management/ +- /ko/security/application_security/vulnerability_management/ +further_reading: +- link: /getting_started/application_security/software_composition_analysis + tag: 가이드 + text: Software Composition Analysis 시작하기 +- link: /security/application_security/code_security + tag: 설명서 + text: 서비스에서 코드 보안 취약점 탐지 활성화 +- link: /code_analysis/software_composition_analysis/ + tag: 설명서 + text: CI 파이프라인에서 Software Composition Analysis 설정하기 +- link: https://www.datadoghq.com/blog/datadog-software-composition-analysis/ + tag: 블로그 + text: Datadog Software Composition Analysis를 통해 타사 라이브러리의 취약점을 완화합니다. +- link: https://www.datadoghq.com/blog/iast-datadog-application-vulnerability-management/ + tag: 블로그 + text: 애플리케이션 취약성 관리로 운영 환경의 애플리케이션 보안 강화 +- link: https://securitylabs.datadoghq.com/articles/guarddog-identify-malicious-pypi-packages/ + tag: 블로그 + text: '정적 코드 분석을 통해 악성 PyPI 패키지 찾기: GuardDog에 대해 알아보기' +- link: https://www.datadoghq.com/blog/sca-prioritize-vulnerabilities/ + tag: 블로그 + text: Datadog SCA로 취약성 해결 우선 순위 지정하기 +- link: https://www.datadoghq.com/blog/smart-vulnerability-remediation/ + tag: 블로그 + text: Datadog는 더 스마트한 취약점 수정 방안을 제공합니다. +title: Software Composition Analysis +--- + +{{< site-region region="gov" >}} +
선택한 Datadog 사이트에서는 Application Security Management가 지원되지 않습니다({{< region-param key="dd_site_name" >}}).
+{{< /site-region >}} + +## 개요 + +Datadog Software Composition Analysis(SCA)를 사용하면 소스를 안심하고 활용할 수 있습니다. SCA의 기능에는 취약성 탐지, 비즈니스 위험(라이브러리 인벤토리 및 라이선스 정보), 서비스 내 오픈 소스 라이브러리의 품질 평가가 포함됩니다. + +Datadog SCA는 개발자가 커밋하는 코드부터 Datadog 배포에서 이미 실행 중인 프로덕션 애플리케이션까지 소프트웨어 개발 수명주기의 엔드투엔드 커버리지를 제공한다는 점에서 독보적입니다. + +Datadog SCA는 엄선된 독점 데이터베이스를 사용합니다. 이 데이터베이스는 오픈 소스 취약점(OSV), 국가 취약점 데이터베이스(NVD), GitHub 권고 및 기타 언어 에코시스템 권고에서 가져옵니다. 또한 Datadog 보안 연구팀에서 취약점 및 멀웨어 발견 사항을 평가합니다. 자세한 내용은 [GuardDog][13] GitHub 프로젝트를 참고하세요. + + +각 ASM 제품의 ASM 호환성을 확인하여 사용 중인 서비스가 지원되는지 확인하세요. + + +## 라이브러리 인벤토리 + +Datadog SCA 라이브러리 인벤토리는 애플리케이션을 구성하는 라이브러리 목록과 버전을 이해하는 데 도움이 됩니다. Library Explorer에 액세스하려면 [**Security** > **Application Security** > **Catalog** > **Libraries**][8]로 이동합니다. + +코드에서 프로덕션에 이르는 소프트웨어 개발 수명 주기에 걸쳐 Datadog SCA를 사용하면 애플리케이션의 수명 주기 전반에 걸쳐 라이브러리를 감지하고 취약성, 위험, 라이선스 등에 관해 알 수 있습니다. + +{{< img src="/security/application_security/software_composition_analysis/asm_library_explorer.png" alt="Software Composition Analysis(SCA) 라이브러리 탐색기 페이지에서 라이브러리별로 그룹화된 라이브러리 취약점을 표시합니다." style="width:100%;" >}} + +## SCA 취약점 탐색 및 관리하기 + +
Datadog Software Composition Analysis(SCA)은 소프트웨어 개발 수명 주기(SDLC) 전반에서 취약한 라이브러리를 찾을 수 있습니다. 애플리케이션 보안은 리포지토리의 기본 브랜치와 실행 중인 서비스에서 발견된 결과를 요약하여 보여줍니다. 다른 브랜치 및 커밋에서 발견된 취약점을 보려면 자세한 내용은 코드 분석을 참조하세요.
+ +[Vulnerability Explorer][3]는 Datadog SCA에서 탐지한 오픈 소스 라이브러리의 전체 목록과 이와 관련된 보안 취약점을 보고합니다. + +Datadog SCA는 두 가지 기술을 활용하여 서비스를 분석합니다. + +- 리포지토리의 정적 코드 분석(정적 관점) +- 배포된 서비스의 런타임 분석(런타임 관점) + +두 기술을 결합하면 코드 리포지토리 커밋(정적 관점)부터 프로덕션에서 실행 중인 애플리케이션(런타임 관점)까지 오픈 소스 라이브러리를 엔드투엔드 모니터링할 수 있습니다. + +코드 리포지토리 커밋 관점으로 전환하려면 **정적**을 선택하세요. 정적 보기는 리포지토리에 있는 _소스 코드_의 취약점을 보여줍니다. + +이미 실행 중인 애플리케이션의 _실시간_ 시점으로 전환하려면 **런타임**을 선택합니다. 런타임 보기는 Datadog에서 모니터링하는 서비스의 실시간 보기입니다. + +{{< img src="/security/application_security/software_composition_analysis/asm_sca_vulnerabilities.png" alt="Software Composition Analysis(SCA) 탐색기 페이지에서 취약점을 정적 또는 런타임별로 구분하여 표시합니다." style="width:100%;" >}} + +특정 취약점을 선택하면 영향을 받는 서비스, 심각도 분류 점수, 권장 해결 단계 등 세부 정보를 확인할 수 있습니다. + +취약점에 대한 Details Explorer에서 영향을 받는 인프라를 볼 수 있습니다. 이 보기는 전반적인 공격 노출에 관해 더 나은 인사이트를 제공합니다. + +## Datadog 심각도 점수 + +각 취약점에는 정의된 기본 심각도 점수가 있습니다. 수정 우선순위를 정하는 데 사용하기 위해 Datadog에서는 의심스러운 요청 또는 공격의 증거, 비즈니스 민감도 또는 인터넷 노출 환경, 공격 성공의 위험성을 고려하여 기본 CVSS 점수를 Datadog 심각도 점수로 수정합니다. + +기본 점수에는 네 가지 점수 수정자가 적용될 수 있습니다. 두 개는 런타임 컨텍스트에서 제공됩니다. + - 취약점이 프로덕션에 있습니다. + - 취약점의 영향을 받는 서비스가 공격을 받고 있습니다. + +두 가지는 CVE 컨텍스트에서 제공됩니다. + - 공격 가능 여부 + - 공격 확률 + +Datadog는 위의 요소에 따라 기본 CVSS 점수가 Datadog 심각도 점수로 조정되는 과정을 보여줍니다. + +{{< img src="security/application_security/vulnerability-score-modified_3.png" alt="취약점 세부정보 페이지에서 수정된 심각도 점수를 표시합니다." style="width:100%;" >}} + +조정된 취약점 점수에 관한 자세한 내용은 [Software Composition Analysis 시작하기][7]를 참조하세요. + +## 복구 + +Vulnerability Explorer에서는 발견된 취약점에 대해 해결 권장 사항을 표시합니다. 권장 사항을 통해 취약점의 상태를 변경하고, 검토를 위해 팀원에게 할당하고, 추적할 Jira 이슈를 만들 수 있습니다. 또 각 취약점의 배경을 이해하는 데 도움이 되는 웹사이트 또는 정보 소스에 대한 링크 및 참조 모음도 포함되어 있습니다. + +**참고**: SCA 취약성에 대한 Jira 이슈를 만들려면 Jira 통합을 구성하고 `manage_integrations` 권한이 있어야 합니다. 자세한 지침은 [Jira 통합][11] 설명서 및 [역할 기반 액세스 제어][10] 설명서를 참조하세요. + +{{< img src="getting_started/appsec/appsec-vuln-remediation_3.png" alt="애플리케이션 취약점 관리의 취약점 세부정보 페이지에서 영향을 받는 서비스, 인프라 연결 링크, 권장되는 조치사항 및 추가 정보 링크를 표시합니다." style="width:100%;" >}} + +## Software Composition Analysis 구성 + +Software Composition Analysis(SCA)에는 [코드 분석][9]을 사용하여 CI 파이프라인의 취약점을 스캔할 수 있는 추가 기능이 포함되어 있습니다. 코드 분석용 SCA를 사용하면 코드베이스로 가져온 취약한 오픈 소스 라이브러리를 식별할 수 있습니다. + +CI 파이프라인에서 취약점을 구성하려면 [Security -> Application Security -> Settings][12]으로 이동하세요. + +**Software Composition Analysis(SCA)**에서 **Get Started**를 클릭하여 Software Composition Analysis을 활성화하고 리포지토리 및 서비스를 선택합니다. + +자세한 지침은 [Software Composition Analysis 시작하기][7]를 참조하세요. + +## APM 뷰의 위험 정보 + +Software Composition Analysis는 APM에서 이미 수집하고 있는 정보를 보강하고 현재 취약성 권고와 일치하는 라이브러리에 플래그를 지정합니다. 잠재적으로 취약한 서비스는 [APM Service Catalog][2]에 포함된 **Security** 뷰에 바로 강조 표시됩니다. + +{{< img src="security/application_security/threats/threats-on-svc-cat_3.png" alt="APM Service Catalog에 표시된 취약점 정보" style="width:100%;" >}} + +## Software Composition Analysis 비활성화 + +Software Composition Analysis 비활성화에 대한 자세한 내용은 [Software Composition Analysis 비활성화][14]를 참고하세요. + +## 참고 자료 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ko/help/ +[2]: https://app.datadoghq.com/services?lens=Security +[3]: https://app.datadoghq.com/security/appsec/vm +[4]: https://app.datadoghq.com/security/appsec +[5]: https://app.datadoghq.com/security/appsec/landing +[7]: /ko/getting_started/application_security/software_composition_analysis +[8]: https://app.datadoghq.com/security/appsec/inventory/libraries +[9]: /ko/code_analysis/software_composition_analysis/setup/?tab=githubactions +[10]: /ko/account_management/rbac/permissions/#integrations +[11]: /ko/integrations/jira/ +[12]: https://app.datadoghq.com/security/configuration/asm/setup +[13]: https://github.com/DataDog/guarddog +[14]: /ko/security/application_security/troubleshooting/#disabling-software-composition-analysis \ No newline at end of file diff --git a/content/ko/security/application_security/software_composition_analysis/setup/_index.md b/content/ko/security/application_security/software_composition_analysis/setup/_index.md new file mode 100644 index 0000000000000..7af0f7b052ee3 --- /dev/null +++ b/content/ko/security/application_security/software_composition_analysis/setup/_index.md @@ -0,0 +1,182 @@ +--- +aliases: +- /ko/security/application_security/enabling/tracing_libraries/sca/ +disable_toc: false +further_reading: +- link: /security/application_security/software_composition_analysis + tag: 문서 + text: 소프트웨어 구성 분석(SCA) +- link: https://www.datadoghq.com/blog/sca-prioritize-vulnerabilities/ + tag: 블로그 + text: Datadog SCA로 취약성 해결 우선 순위 지정하기 +- link: /security/default_rules/?category=cat-application-security + tag: 문서 + text: OOTB 애플리케이션 보안 관리 규칙 +- link: /security/application_security/troubleshooting + tag: 문서 + text: 애플리케이션 보안 관리 트러블슈팅 +- link: /security/application_security/how-appsec-works/ + tag: 문서 + text: Datadog에서 애플리케이션 보안 관리가 작동하는 방식 +- link: https://www.datadoghq.com/blog/secure-serverless-applications-with-datadog-asm/ + tag: 블로그 + text: Datadog ASM을 통한 서버리스 애플리케이션 보안 +title: Software Composition Analysis 설정 +--- + +## 사전 필수 조건 +Software Composition Analysis를 설정하기 전에 다음 필수 조건을 충족하는지 확인하세요. + +1. **Datadog Agent 설치:** Datadog Agent는 애플리케이션의 운영 체제 또는 컨테이너, 클라우드 또는 가상 환경에 맞게 설치 및 구성되어 있습니다. +2. **Datadog APM 구성:** 애플리케이션 또는 서비스에 Datadog APM이 구성되어 있으며, Datadog에서 웹 추적(`type:web`)을 수신 중입니다. +3. **Tracing Library 호환:** 애플리케이션 또는 서비스에서 사용하는 Datadog Tracing Library가 애플리케이션 또는 서비스 언어에 대한 Software Composition Analysis 기능을 지원합니다. 자세한 내용은 각 ASM 제품의 [라이브러리 호환성][5] 페이지를 참고하세요. + +## Software Composition Analysis 사용 유형 + +### 퀵 스타트 가이드 + +1. [빠른 시작 가이드][2]로 이동합니다. + 1. **Enable Vulnerability Detection**를 확장합니다. + 2. **Open source vulnerabilities**를 선택합니다. + 3. **Start Activation**을 선택합니다. + 4. 라이브러리 취약점을 식별하려는 서비스를 선택한 후 **Next**을 클릭합니다. + 5. **Enable for Selected Services**을 선택합니다. + +### 설정 페이지 + +또는 [설정][3] 페이지를 통해 Software Composition Analysis를 활성화할 수 있습니다. + +1. [Settings][3] 페이지로 이동하여 **Software Composition Analysis(SCA)** 에서 **Get Started**를 선택합니다. +2. 소스 코드에서 정적 분석을 하려면 **Select Repositories**을 선택합니다. +3. **Add Github Account**를 선택하고 [지침][4]에 따라 새 Github 애플리케이션을 생성합니다. +4. GitHub 계정이 설정되면 **Select Repositories**을 선택하고 **Software Composition Analysis(SCA)**을 활성화합니다. +5. 실행 중인 서비스에서 런타임 분석을 하려면 **Select Services**을 클릭합니다. +6. 라이브러리 취약점을 식별하려는 서비스를 선택하고 **Next**을 선택합니다. +7. **선택한 서비스에 사용**을 선택합니다. + +### Datadog Tracing Libraries + +Datadog Tracing Library 구성에 환경 변수 또는 새 인수를 추가합니다. + +이 단계를 따르면 애플리케이션에 대한 Software Composition Analysis을 성공적으로 설정하여 애플리케이션 또는 서비스에서 사용하는 오픈 소스 라이브러리의 취약점을 포괄적으로 모니터링하고 식별할 수 있습니다. + +Datadog Software Composition Analysis(SCA)을 사용하여 앱에서 오픈 소스 라이브러리를 모니터링할 수 있습니다. + +SCA는 지원되는 언어에서 `-Ddd.appsec.sca.enabled` 플래그 또는 `DD_APPSEC_SCA_ENABLED` 환경 변수를 `true`로 설정하여 구성합니다. + +- 자바(Java) +- .NET +- Go +- Ruby +- PHP +- Node.js +- 파이썬(Python) + +이 항목에서는 Java 예제를 사용하여 SCA를 설정하는 방법을 설명합니다. + +**예시: Java에서 Software Composition Analysis 활성화** + +1. **[Datadog Java 라이브러리][1]**를 버전 0.94.0 이상(Software Composition Analysis 탐지 기능의 경우 버전 1.1.4 이상)으로 업데이트하세요. + + {{< tabs >}} + {{% tab "Wget" %}} + ```shell + wget -O dd-java-agent.jar 'https://dtdg.co/latest-java-tracer' + ``` +{{% /tab %}} +{{% tab "cURL" %}} + ```shell + curl -Lo dd-java-agent.jar 'https://dtdg.co/latest-java-tracer' + ``` +{{% /tab %}} +{{% tab "Dockerfile" %}} + ```dockerfile + ADD 'https://dtdg.co/latest-java-tracer' dd-java-agent.jar + ``` +{{% /tab %}} +{{< /tabs >}} + 서비스의 언어 및 프레임워크 버전이 ASM 기능을 지원하는지 확인하려면 [호환성][2]을 참고하세요. + +1. 명령줄에서 **SCA를 활성화한 상태로 Java 애플리케이션을 실행합니다**. + ```shell + java -javaagent:/path/to/dd-java-agent.jar -Ddd.appsec.sca.enabled=true -Ddd.service= -Ddd.env= -jar path/to/app.jar + ``` + + 또는 애플리케이션이 실행되는 위치에 따라 다음 방법 중 하나를 선택합니다. + + **참고**: 현재 읽기 전용 파일 시스템은 지원되지 않습니다. 애플리케이션은 쓰기 가능한 `/tmp` 디렉터리에 대한 액세스 권한이 있어야 합니다. + + {{< tabs >}} +{{% tab "Docker CLI" %}} + +```shell +docker run [...] -e DD_APPSEC_SCA_ENABLED=true [...] +``` + +{{% /tab %}} +{{% tab "Dockerfile" %}} + +컨테이너 Dockerfile에 다음 환경 변수 값을 추가합니다. + +```Dockerfile +ENV DD_APPSEC_SCA_ENABLED=true +``` + +{{% /tab %}} +{{% tab "Kubernetes" %}} + +APM에 대한 배포 구성 파일을 업데이트하고 SCA 환경 변수를 추가합니다. + +```yaml +spec: + template: + spec: + containers: + - name: + image: / + env: + - name: DD_APPSEC_SCA_ENABLED + value: "true" +``` + +{{% /tab %}} +{{% tab "Amazon ECS" %}} + +환경 섹션에서 다음을 추가하여 ECS 작업 정의 JSON 파일을 업데이트합니다. + +```json +"environment": [ + ..., + { + "name": "DD_APPSEC_SCA_ENABLED", + "value": "true" + } +] +``` + +{{% /tab %}} +{{% tab "AWS Fargate" %}} + +서비스 호출에서 `-Ddd.appsec.sca.enabled` 플래그 또는 `DD_APPSEC_SCA_ENABLED` 환경 변수를 `true`로 설정하세요. + +```shell +java -javaagent:dd-java-agent.jar \ + -Ddd.appsec.sca.enabled=true \ + -jar .jar \ + +``` + +{{% /tab %}} + + {{< /tabs >}} + +## 참고 자료 + +{{< partial name="whats-next/whats-next.html" >}} + + +[1]: /ko/security/application_security/software_composition_analysis/setup/compatibility/java +[2]: https://app.datadoghq.com/security/configuration/asm/onboarding +[3]: https://app.datadoghq.com/security/configuration/asm/setup +[4]: /ko/integrations/github/ +[5]: /ko/security/application_security/software_composition_analysis/setup/compatibility/ \ No newline at end of file diff --git a/content/ko/security/application_security/threats/add-user-info.md b/content/ko/security/application_security/threats/add-user-info.md new file mode 100644 index 0000000000000..468e4f95dc81b --- /dev/null +++ b/content/ko/security/application_security/threats/add-user-info.md @@ -0,0 +1,848 @@ +--- +aliases: +- /ko/security_platform/application_security/add-user-info +- /ko/security/application_security/add-user-info +further_reading: +- link: /security/application_security/ + tag: 설명서 + text: Datadog App과 API Protection을 사용하여 위협으로부터 보호 +- link: /security/application_security/threats/library_configuration/ + tag: 설명서 + text: 기타 고려 사항 및 구성 옵션 +title: 사용자 모니터링 및 보호 +--- + +## 개요 + +서비스를 계측하고 사용자 활동을 추적하여 악성 행위자를 탐지하고 차단하세요. + +[트레이스에 인증된 사용자 정보를 추가](#adding-authenticated-user-information-to-traces-and-enabling-user-blocking-capability)하여 인증된 공격 영역을 노리는 악성 공격자를 식별하고 차단합니다. 이를 위해 실행 중인 APM 트레이스에 사용자 ID 태그를 설정하여 AAP가 인증된 공격자를 차단하는 데 필요한 도구를 제공해야 합니다. 이렇게 하면 AAP는 공격 및 비즈니스 로직 이벤트를 사용자와 연결할 수 있습니다. + +기본 제공 탐지 규칙을 활용해 [사용자의 로그인 및 활동을 추적](#adding-business-logic-information-login-success-login-failure-any-business-logic-to-traces)함으로써, 계정 탈취나 비즈니스 로직 악용을 탐지하고 궁극적으로 공격자를 차단할 수 있습니다. + +기본 탐지 규칙을 적용한 사용자 맞춤 활동은 다음과 같습니다. + +| 기본 제공 이벤트 이름 | 필수 메타데이터 | 관련 규칙 | +|------------------------|------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| `activity.sensitive` | `{ "name": "coupon_use", "required_role": "user" }` | [IP 기반 속도 제한이 적용된 활동][4]
[승인되지 않은 활동 감지][5] | +| `users.login.success` | 사용자 ID는 필수이며, 필요시 메타데이터를 추가할 수 있음 | [크리덴셜 스터핑 공격[6]
[무차별 대입 공격][12]
[분산형 크리덴셜 스터핑 공격][13] | +| `users.login.failure` | 사용자 ID와 `usr.exists`는 필수이며, 필요시 메타데이터를 추가할 수 있음 | [크리덴셜 스터핑 공격[6]
[무차별 대입 공격][12]
[분산형 크리덴셜 스터핑 공격][13] | +| `users.signup` | `{ "usr.id": "12345" }` | [IP에서 과도한 계정 생성][7] | +| `users.delete` | `{ "usr.id": "12345" }` | [IP에서 과도한 계정 삭제][8] | +| `users.password_reset` | `{ "usr.id": "12345", "usr.login": "user@email.com", "exists": true }` | [암호 재설정 무차별 대입 시도][9] | +| `payment.failure` | 없음 | [IP에서 과도한 결제 실패][10] | + +## 인증된 사용자 정보를 추적에 추가하고 사용자 차단 기능 활성화 + +
+사용자 활동 자동 감지: Datadog Tracing Libraries는 사용자 활동 이벤트를 자동으로 감지하고 보고합니다. 자세한 내용은 자동 사용자 활동 이벤트 추적 비활성화를 참고하세요. +
+ +[루트 스팬에 사용자 정의 태그를 추가][3]하거나 아래 설명된 계측 기능을 사용할 수 있습니다. + +{{< programming-lang-wrapper langs="java,dotnet,go,ruby,php,nodejs,python" >}} + +{{< programming-lang lang="java" >}} + +Java 트레이서 API를 사용하여 루트 스팬에 사용자 정의 태그와 사용자 정보를 추가하면 애플리케이션에서 인증된 요청을 모니터링할 수 있습니다. + +사용자 모니터링 태그는 루트 스팬에 적용되며 `usr` 접두사로 시작하고 그 뒤에 필드 이름이 옵니다. 예를 들어, `usr.name`는 사용자 이름을 추적하는 사용자 모니터링 태그입니다. + +**참고**: [애플리케이션에 필요한 종속성][1]이 추가되었는지 확인하세요. + +아래 예에서는 루트 스팬을 얻고, 관련 사용자 모니터링 태그를 추가하고, 사용자 차단 기능을 활성화하는 방법을 보여줍니다. + +```java +import io.opentracing.Span; +import io.opentracing.util.GlobalTracer; +import datadog.appsec.api.blocking.Blocking; +import datadog.trace.api.interceptor.MutableSpan; + +// 활성화된 스팬 가져오기 +final Span span = GlobalTracer.get().activeSpan(); +if ((span instanceof MutableSpan)) { + MutableSpan localRootSpan = ((MutableSpan) span).getLocalRootSpan(); + // 필수 사용자 ID 태그 설정 + localRootSpan.setTag("usr.id", "d131dd02c56eec4"); + // 선택적 사용자 모니터링 태그 설정 + localRootSpan.setTag("usr.name", "Jean Example"); + localRootSpan.setTag("usr.email", "jean.example@example.com"); + localRootSpan.setTag("usr.session_id", "987654321"); + localRootSpan.setTag("usr.role", "admin"); + localRootSpan.setTag("usr.scope", "read:message, write:files"); +} + +Blocking + .forUser("d131dd02c56eec4") + .blockIfMatch(); +``` + +[1]: /ko/tracing/trace_collection/custom_instrumentation/opentracing/java#setup +{{< /programming-lang >}} + +{{< programming-lang lang="dotnet" >}} + +.NET 트레이서 패키지는 `SetUser()` 함수를 제공하여 사용자 정보를 트레이스에 추가하고 인증된 요청을 모니터링할 수 있는 기능을 제공합니다. + +아래 예에서는 관련 사용자 모니터링 태그를 추가하고 사용자 차단 기능을 활성화하는 방법을 보여줍니다. + +```csharp + +using Datadog.Trace; + +// ... + + var userDetails = new UserDetails() + { + // 사용자를 위한 시스템 내부 식별자 + Id = "d41452f2-483d-4082-8728-171a3570e930", + // 사용자 이메일 주소 + Email = "test@adventure-works.com", + // 시스템에 표시되는 사용자 이름 + Name = "Jane Doh", + // 사용자의 세션 ID + SessionId = "d0632156-132b-4baa-95b2-a492c5f9cb16", + // 사용자가 요청하는 역할 + Role = "standard", + }; + Tracer.Instance.ActiveScope?.Span.SetUser(userDetails); +``` + +자세한 내용과 옵션은 [.NET 트레이서 문서][1]를 참고하세요. + +[1]: https://github.com/DataDog/dd-trace-dotnet/tree/master/docs/Datadog.Trace#user-identification + +{{< /programming-lang >}} + +{{< programming-lang lang="go" >}} + +Go 트레이서 패키지는 트레이스에 사용자 정보를 추가하여 인증된 요청을 모니터링할 수 있는 `SetUser()` 함수를 제공합니다. 더 많은 옵션은 [Go 트레이서 문서][1](또는 [v2 문서][2])를 참고하세요. + +이 예제에서는 현재 트레이서 스팬을 검색하고 이를 사용하여 사용자 모니터링 태그를 설정하며, 사용자 차단 기능을 활성화하는 방법을 보여줍니다. + +```go +import ( + "gopkg.in/DataDog/dd-trace-go.v1/appsec" // 1.x + // "github.com/DataDog/dd-trace-go/v2/appsec // 2.x +) + +func handler(w http.ResponseWriter, r *http.Request) { + if appsec.SetUser(r.Context(), "my-uid") != nil { + // 요청 핸들러를 최대한 빨리 중단하여 사용자를 차단해야 합니다. + // 차단 응답은 AppSec 미들웨어에 의해 자동으로 처리되어 전송됩니다. + return + } +} +``` + +[1]: https://pkg.go.dev/gopkg.in/DataDog/dd-trace-go.v1/ddtrace/tracer#SetUser +[2]: https://pkg.go.dev/github.com/DataDog/dd-trace-go/v2/ddtrace/tracer#SetUser +{{< /programming-lang >}} + +{{< programming-lang lang="ruby" >}} + +다음 API 중 하나를 사용하여 트레이스에 사용자 정보를 추가하면 애플리케이션에서 인증된 요청을 모니터링할 수 있습니다. + +{{% collapse-content title="set_user" level="h4" expanded="true" %}} + +`ddtrace` 1.1.0 버전부터 `Datadog::Kit::Identity.set_user` 메서드를 사용할 수 있습니다. 트레이스에 사용자 정보를 추가하려면 다음 API를 사용하는 것이 좋습니다. + +```ruby +# 활성화된 트레이스 가져오기 +trace = Datadog::Tracing.active_trace + +# 필수 사용자 ID 태그 설정 +Datadog::Kit::Identity.set_user(trace, id: 'd131dd02c56eeec4') + +# 또는 선택적 사용자 모니터링 태그 설정 +Datadog::Kit::Identity.set_user( + trace, + + # 필수 ID + id: 'd131dd02c56eeec4', + + # 의미가 정해진 선택적 태그들 + name: 'Jean Example', + email:, 'jean.example@example.com', + session_id:, '987654321', + role: 'admin', + scope: 'read:message, write:files', + + # 선택적인 자유 형식 태그 + another_tag: 'another_value', +) +``` +{{% /collapse-content %}} + +{{% collapse-content title="set_tag" level="h4" expanded="false" id="ruby-set-tag" %}} + +`Datadog::Kit::Identity.set_user`로 충분하지 않으면 `set_tag`를 대신 사용할 수 있습니다. + +사용자 모니터링 태그는 트레이스에 적용되며 접두사 `usr.`로 시작하고 그 뒤에 필드 이름이 옵니다. 예를 들어, `usr.name`는 사용자 이름을 추적하는 사용자 모니터링 태그입니다. + +아래 예에서는 활성화된 트레이스를 얻고 관련 사용자 모니터링 태그를 추가하는 방법을 보여줍니다. + +**참고**: +- 태그 값은 문자열이어야 합니다. +- `usr.id` 태그는 필수입니다. + +```ruby +# 활성 추적 가져오기 +trace = Datadog::Tracing.active_trace + +# 필수 사용자 ID 태그 설정 +trace.set_tag('usr.id', 'd131dd02c56eeec4') + +# 의미가 정해진 선택적 사용자 모니터링 태그 설정 +trace.set_tag('usr.name', 'Jean Example') +trace.set_tag('usr.email', 'jean.example@example.com') +trace.set_tag('usr.session_id', '987654321') +trace.set_tag('usr.role', 'admin') +trace.set_tag('usr.scope', 'read:message, write:files') + +# 자유 형식 태그 설정 +trace.set_tag('usr.another_tag', 'another_value') +``` +{{% /collapse-content %}} + +{{< /programming-lang >}} + +{{< programming-lang lang="php" >}} + +PHP 트레이서는 인증된 요청을 모니터링하고 차단할 수 있는 `\DDTrace\set_user()` 함수를 제공합니다. + +`\DDTrace\set_user()`는 트레이스에 관련 사용자 태그와 메타데이터를 추가하고 자동으로 사용자를 차단합니다. + +다음 예제에서는 사용자 모니터링 태그를 설정하고 사용자 차단을 활성화하는 방법을 보여줍니다. + +```php + 'Jean Example', + 'email' => 'jean.example@example.com', + 'session_id' => '987654321', + 'role' => 'admin', + 'scope' => 'read:message, write:files', + ] +); +?> +``` + +{{< /programming-lang >}} + +{{< programming-lang lang="nodejs" >}} + +Node 트레이서 패키지는 사용자 정보를 트레이스에 추가하여 인증된 요청을 모니터링할 수 있는 `tracer.setUser(user)` 함수를 제공합니다. + +아래 예에서는 관련 사용자 모니터링 태그를 추가하고 사용자 차단 기능을 활성화하는 방법을 보여줍니다. + +```javascript +const tracer = require('dd-trace').init() + +function handle () { + tracer.setUser({ + id: '123456789', // *필수* 사용자 고유 식별자. + + // 다른 모든 필드는 선택 사항입니다. + email: 'jane.doe@example.com', // 사용자 이메일 주소 + name: 'Jane Doe', // 사용자 이름 + session_id: '987654321', // 사용자 세션 ID + role: 'admin', // 사용자가 요청하는 역할 + scope: 'read:message, write:files', // 사용자가 현재 소유하고 있는 범위 또는 부여된 권한 + + // 커스텀 데이터를 추가하기 위한 임의의 필드도 허용됩니다(RBAC, Oauth 등). + custom_tag: 'custom data' + }) + +// 현재 인증된 사용자를 설정하고 차단 여부를 확인하세요. +if (tracer.appsec.isUserBlocked(user)) { // 현재 인증된 사용자도 설정합니다. + return tracer.appsec.blockRequest(req, res) // 차단 응답이 전송되었습니다. + } + +} +``` + +자세한 내용과 옵션은 [Node.js 트레이서 문서][1]를 참고하세요. + + + +[1]: https://datadoghq.dev/dd-trace-js/#set-user +{{< /programming-lang >}} + +{{< programming-lang lang="python" >}} + +Python 트레이서 패키지가 제공하는 `set_user` 함수를 사용하여 트레이스에 사용자 정보를 추가하고 인증된 요청을 모니터링합니다. + +이 예제에서는 사용자 모니터링 태그를 설정하고 사용자 차단 기능을 활성화하는 방법을 보여줍니다. + +```python +from ddtrace.contrib.trace_utils import set_user +from ddtrace import tracer +# 현재 인증된 사용자 ID를 추적하려면 set_user()를 호출합니다. +user_id = "some_user_id" +set_user(tracer, user_id, name="John", email="test@test.com", scope="some_scope", + role="manager", session_id="session_id", propagate=True) +``` + +{{< /programming-lang >}} + +{{< /programming-lang-wrapper >}} + +## 트레이스에 비즈니스 로직 정보(로그인 성공, 로그인 실패, 모든 비즈니스 로직) 추가 + +
+usr.id 및 usr.login에 대한 참고 사항: 로그인 악용 조사는 비슷하지만 서로 다른 두 가지 개념에 기반합니다. usr.id는 데이터베이스에 저장된 사용자 계정의 고유 식별자를 포함합니다. 이 값은 고유하며 변경되지 않습니다. 존재하지 않는 계정에 로그인을 시도할 경우 usr.id를 얻을 수 없습니다. 사용자 차단은 usr.id를 대상으로 수행됩니다.
+ +사용자는 일반적으로 자신의 사용자 ID를 알지 못합니다. 대신 변경 가능한 식별자(전화번호, 사용자 이름, 이메일 주소 등)를 사용합니다. 사용자가 계정에 로그인하는 데 사용하는 문자열은 로그인 이벤트에서 usr.login으로 보고되어야 합니다.
+usr.login를 제공하지 않으면 usr.id가 대신 사용됩니다. +
+ +{{< programming-lang-wrapper langs="java,dotnet,go,ruby,php,nodejs,python" >}} +{{< programming-lang lang="java" >}} + +dd-trace-java v1.8.0부터 Java 트레이서 API를 사용하여 사용자 이벤트를 추적할 수 있습니다. + +다음 예제는 로그인 이벤트나 사용자 정의 이벤트(가입을 예로 들어)를 추적하는 방법을 보여줍니다. + +{{% collapse-content title="로그인 성공" level="h4" expanded="true" %}} +```java +import datadog.trace.api.EventTracker; +import datadog.trace.api.GlobalTracer; + +public class LoginController { + + private User doLogin(String userName, String password) { + // 여기서 userName과 password 크리덴셜을 기반으로 사용자를 가져옵니다. + User user = checkLogin(userName, password); + + Map metadata = new HashMap<>(); + metadata.put("email", user.getEmail()); + metadata.put("usr.login", userName); + + // 시스템에 여러 "테넌트"가 있는 경우 해당 테넌트를 입력해 주세요. 테넌트는 사용자 환경/그룹입니다 + metadata.put("usr.org", usr.getTenant()); + + // 사용자 인증 성공 이벤트를 추적합니다. + GlobalTracer + .getEventTracker() + .trackLoginSuccessEvent(user.getId(), metadata); + + } +} + +``` +{{% /collapse-content %}} + +{{% collapse-content title="로그인 실패" level="h4" expanded="false" id="java-login-failure" %}} +```java +import datadog.trace.api.EventTracker; +import datadog.trace.api.GlobalTracer; + +public class LoginController { + + private User doLogin(String userName, String password) { + // 여기서 userName/password 크리덴셜을 기반으로 사용자를 가져옵니다 + User user = checkLogin(userName, password); + + // 함수가 null을 반환하는 경우 - 사용자가 존재하지 않습니다 + boolean userExists = (user != null); + String userId = null; + Map metadata = new HashMap<>(); + metadata.put("usr.login", userName); + if (userExists != null) { + userId = getUserId(userName) + metadata.put("email", user.getEmail()); + } else { + userId = userName; + } + + // 사용자 인증 오류 이벤트를 추적합니다 + GlobalTracer + .getEventTracker() + .trackLoginFailureEvent(userId, userExists, metadata); + } +} +``` +{{% /collapse-content %}} + +{{% collapse-content title="사용자 정의 비즈니스 로직" level="h4" expanded="false" id="java-custom-business" %}} +```java +import datadog.trace.api.EventTracker; +import datadog.trace.api.GlobalTracer; + +public class LoginController { + + private User doSignup(String userId, String email) { + // 여기서 사용자 계정을 생성합니다 + User user = createUser(userId, email); + + Map metadata = new HashMap<>(); + metadata.put("usr.id", user.getId()); + + // 사용자 가입 이벤트를 추적합니다 + GlobalTracer + .getEventTracker() + .trackCustomEvent("users.signup", metadata); + } +} + +``` +{{% /collapse-content %}} + +{{< /programming-lang >}} + +{{< programming-lang lang="dotnet" >}} + +dd-trace-dotnet v2.23.0부터 .NET 트레이서 API를 사용하여 사용자 이벤트를 추적할 수 있습니다. + +다음 예제는 로그인 이벤트나 사용자 정의 이벤트(가입을 예로 들어)를 추적하는 방법을 보여줍니다. + +{{% collapse-content title="로그인 성공" level="h4" expanded="true" %}} +```csharp +using Datadog.Trace.AppSec; + +void OnLogonSuccess(string userId, string login...) +{ + // 메타데이터는 선택사항입니다. + var metadata = new Dictionary() + { + { "usr.login", login } + }; + EventTrackingSdk.TrackUserLoginSuccessEvent(userId, metadata); + + // ... +} + +``` +{{% /collapse-content %}} +{{% collapse-content title="로그인 실패" level="h4" expanded="false" id="dotnet-login-failure" %}} +```csharp +using Datadog.Trace.AppSec; + +void OnLogonFailure(string userId, string login, bool userExists, ...) +{ + // 사용자 ID를 제공할 수 없는 경우 고유한 사용자 식별자(사용자 이름, 이메일 등)를 사용할 수 있습니다 + // 메타데이터는 선택사항입니다 + var metadata = new Dictionary() + { + { "usr.login", login } + }; + EventTrackingSdk.TrackUserLoginFailureEvent(userId, userExists, metadata); + + // ... +} +``` +{{% /collapse-content %}} + +{{% collapse-content title="사용자 정의 비즈니스 로직" level="h4" expanded="false" id="dotnet-custom-business" %}} +```csharp +void OnUserSignupComplete(string userId, ...) +{ + // 메타데이터 파라미터는 선택 사항이지만 "usr.id"를 추가합니다 + var metadata = new Dictionary() + { + { "usr.id", userId } + }; + // 사용자 가입을 추적하기 위해 사용자 정의 비즈니스 로직 추적을 활용합니다 + EventTrackingSdk.TrackCustomEvent("users.signup", metadata); + + // ... +} +``` +{{% /collapse-content %}} + +{{< /programming-lang >}} +{{< programming-lang lang="go" >}} + +dd-trace-go v1.47.0부터 Go 트레이서 API를 사용하여 사용자 이벤트를 추적할 수 있습니다. + +다음 예제는 로그인 이벤트나 사용자 정의 이벤트(가입을 예로 들어)를 추적하는 방법을 보여줍니다. + +{{% collapse-content title="로그인 성공" level="h4" expanded="true" %}} +```go +import ( + "gopkg.in/DataDog/dd-trace-go.v1/appsec" // 1.x + // "github.com/DataDog/dd-trace-go/v2/appsec" // 2.x +) + +func handler(w http.ResponseWriter, r *http.Request) { + metadata := make(map[string]string) /* 선택적 추가 이벤트 메타데이터*/ + userdata := /* 선택적 추가 사용자 데이터 */ + + metadata["usr.login"] = "user-email" + + // 로그인 성공 여부를 추적하고 `my-uid`를 사용자의 고유 식별자(숫자, 사용자 이름, 이메일 등)로 바꿉니다 + if appsec.TrackUserLoginSuccessEvent(r.Context(), "my-uid", metadata, userdata) != nil { + // 해당 사용자 ID가 차단되었으며 핸들러는 최대한 빨리 중단되어야 합니다 + // 차단 응답은 AppSec 미들웨어에 의해 전송됩니다 + return + } +} +``` +{{% /collapse-content %}} +{{% collapse-content title="로그인 실패" level="h4" expanded="false" id="go-login-failure" %}} +```go +import ( + "gopkg.in/DataDog/dd-trace-go.v1/appsec" // 1.x + // "github.com/DataDog/dd-trace-go/v2/appsec" // 2.x +) + +func handler(w http.ResponseWriter, r *http.Request) { + exists := /* 주어진 사용자 ID가 존재하는지 여부 */ + metadata := make(map[string]string) /* 선택적 추가 이벤트 메타데이터 */ + metadata["usr.login"] = "user-email" + + // `my-uid`를 사용자의 고유 식별자(숫자, 사용자 이름, 이메일...)로 바꿉니다 + appsec.TrackUserLoginFailureEvent(r.Context(), "my-uid", exists, metadata) +} +``` +{{% /collapse-content %}} + +{{% collapse-content title="사용자 정의 비즈니스 로직" level="h4" expanded="false" id="go-custom-business" %}} +```go +import ( + "gopkg.in/DataDog/dd-trace-go.v1/appsec" // 1.x + // "github.com/DataDog/dd-trace-go/v2/appsec" // 2.x +) + +func handler(w http.ResponseWriter, r *http.Request) { + metadata := map[string]string{"usr.id": "my-uid"} + + // 사용자 가입을 추적하기 위해 사용자 정의 비즈니스 로직 추적을 활용합니다 + appsec.TrackCustomEvent(r.Context(), "users.signup", metadata) +} +``` +{{% /collapse-content %}} + +{{< /programming-lang >}} +{{< programming-lang lang="ruby" >}} + +dd-trace-rb v1.9.0부터 Ruby 트레이서 API를 사용하여 사용자 이벤트를 추적할 수 있습니다. + +다음 예제는 로그인 이벤트나 사용자 정의 이벤트(가입을 예로 들어)를 추적하는 방법을 보여줍니다. + +로그인 성공/실패 이벤트가 포함된 트레이스는 `@appsec.security_activity:business_logic.users.login.success` 또는 `@appsec.security_activity:business_logic.users.login.failure` 쿼리를 사용하여 조회할 수 있습니다. + +{{% collapse-content title="Login success" level="h4" expanded="true" %}} +```ruby +require 'datadog/kit/appsec/events' + +trace = Datadog::Tracing.active_trace +# `my_user_id`를 사용자의 고유 식별자(숫자, 사용자 이름, 이메일...)로 바꾸세요 +Datadog::Kit::AppSec::Events.track_login_success(trace, user: { id: 'my_user_id' }, { 'usr.login': 'my_user_email' }) +``` +{{% /collapse-content %}} + +{{% collapse-content title="로그인 실패" level="h4" expanded="false" id="ruby-login-failure" %}} +```ruby +require 'datadog/kit/appsec/events' +trace = Datadog::Tracing.active_trace + +# `my_user_id`를 사용자의 고유 식별자(숫자, 사용자 이름, 이메일...)로 바꾸세요 + +# 사용자가 존재하는 경우 +Datadog::Kit::AppSec::Events.track_login_failure(trace, user_id: 'my_user_id', user_exists: true, { 'usr.login': 'my_user_email' }) + +# 사용자가 존재하지 않는 경우 +Datadog::Kit::AppSec::Events.track_login_failure(trace, user_id: 'my_user_id', user_exists: false, { 'usr.login': 'my_user_email' }) +``` +{{% /collapse-content %}} + +{{% collapse-content title="사용자 정의 비즈니스 로직" level="h4" expanded="false" id="ruby-custom-business" %}} +```ruby +require 'datadog/kit/appsec/events' +trace = Datadog::Tracing.active_trace + +# `my_user_id`를 사용자의 고유 식별자(숫자, 사용자 이름, 이메일...)로 바꾸세요 + +# 사용자 가입을 추적하기 위해 사용자 정의 비즈니스 로직 추적을 활용합니다 +Datadog::Kit::AppSec::Events.track('users.signup', trace, nil, { 'usr.id': 'my_user_id'}) +``` +{{% /collapse-content %}} + +{{< /programming-lang >}} + +{{< programming-lang lang="php" >}} +dd-trace-php v0.84.0부터 PHP 트레이서 API를 사용하여 사용자 이벤트를 추적할 수 있습니다. + +다음 예제는 로그인 이벤트나 사용자 정의 이벤트(가입을 예로 들어)를 추적하는 방법을 보여줍니다. + +{{% collapse-content title="Login success" level="h4" expanded="true" %}} +```php + $email]) +?> +``` +{{% /collapse-content %}} + +{{% collapse-content title="로그인 실패" level="h4" expanded="false" id="php-login-failure" %}} +```php + $email]) +?> +``` +{{% /collapse-content %}} + +{{% collapse-content title="사용자 정의 비즈니스 로직" level="h4" expanded="false" id="php-custom-business" %}} +```php + $id]); +?> +``` +{{% /collapse-content %}} + +{{< /programming-lang >}} + +{{< programming-lang lang="nodejs" >}} + +dd-trace-js v3.13.1부터 Node.js 트레이서 API를 사용하여 사용자 이벤트를 추적할 수 있습니다. dd-trace-js v5.48.0 버전에서는 `eventTrackingV2` 네임스페이스에 새로운 메서드가 추가되었습니다. 기존 이벤트 추적 메서드는 호환성을 위해 그대로 유지됩니다. + + +다음 예제는 로그인 이벤트나 사용자 정의 이벤트(가입을 예로 들어)를 추적하는 방법을 보여줍니다. + +{{% collapse-content title="Login success" level="h4" expanded="true" %}} +```javascript +const tracer = require('dd-trace') + +// 컨트롤러에서: +const user = { +id: 'user-id', // ID는 필수입니다. ID가 없는 경우, 사용자 이름, 이메일 등 어떤 고유 식별자라도 사용 가능합니다. + email: 'user@email.com' // 다른 필드는 선택사항입니다 +} +const user = 'user-id' // 사용자를 ID 로만 나타낼 수도 있습니다 +const login = 'user@email.com' +const metadata = { 'key': 'value' } // 임의의 필드를 추가할 수 있습니다 + +// 성공적인 사용자 인증 이벤트를 기록합니다 +// 사용자 및 메타데이터는 선택 사항입니다 +tracer.appsec.eventTrackingV2.trackUserLoginSuccess(login, user, metadata) +``` +{{% /collapse-content %}} + +{{% collapse-content title="로그인 실패" level="h4" expanded="false" id="nodejs-login-failure" %}} +```javascript +const tracer = require('dd-trace') + +// 컨트롤러에서: +const login = 'user-id' // 사용자가 로그인하는 데 사용하는 문자열 +const userExists = true // 예를 들어 사용자 로그인이 데이터베이스에 있는 경우 +const metadata = { 'key': 'value' } // 임의의 필드를 추가할 수 있습니다 + +// 실패한 사용자 인증 이벤트를 기록합니다 +// userExists는 선택 사항이며, 기본값은 false입니다 +// 메타데이터는 선택 사항입니다. +tracer.appsec.eventTrackingV2.trackUserLoginFailure(login, userExists, metadata) +``` +{{% /collapse-content %}} + +{{% collapse-content title="사용자 정의 비즈니스 로직" level="h4" expanded="false" id="nodejs-custom-business" %}} +```javascript +const tracer = require('dd-trace') + +// 컨트롤러에서: +const eventName = 'users.signup' +const metadata = { 'usr.id': 'user-id' } + +tracer.appsec.trackCustomEvent(eventName, metadata) +``` +{{% /collapse-content %}} + +#### 새로운 로그인 성공 및 실패 메서드로 마이그레이션 + +`eventTrackingV2`에 새롭게 도입된 메서드는 더욱 직관적인 파라미터 순서와 더욱 명확한 책임 분리를 제공합니다. 주요 변경 사항은 다음과 같습니다. + +1. 로그인 식별자(이메일, 사용자 이름)는 첫 번째 파라미터이며 필수입니다. +2. 성공 이벤트에서는 사용자 개체/ID가 선택 사항이며 실패 이벤트에서는 제거되었습니다. +3. 메타데이터가 간소화되어 더 이상 `usr.login` 필드가 필요하지 않습니다. + +**참고**: 기존 메서드인 `trackUserLoginSuccessEvent` 및 `trackUserLoginFailureEvent`는 더 이상 사용되지 않으며, 새로운 메서드인`eventTrackingV2.trackUserLoginSuccess` 및 `eventTrackingV2.trackUserLoginFailure`가 사용됩니다. + +다음 예에서는 주석이 달린 코드가 더 이상 필요하지 않습니다. + +{{% collapse-content title="Login success" level="h4" expanded="true" %}} +```javascript +const tracer = require('dd-trace') + +// 컨트롤러에서: +const user = { + id: 'user-id', + email: 'user@email.com' +} // 이전과 동일하지만 이제 객체는 선택 사항입니다. 그래도 사용자 ID를 제공하면 침해 이후 활동 연관성 파악에 도움이 됩니다 + +const login = 'user@email.com' // 새로운 필수 인수 + +const metadata = { +// 'usr.login': 'user@email.com', 더 이상 메타데이터에 포함할 필요가 없습니다. 반드시 메인 인수로 전달되어야 합니다 + 'key': 'value' +} + +// tracer.appsec.trackUserLoginSuccessEvent(user, metadata) // 더 이상 사용되지 않음 +tracer.appsec.eventTrackingV2.trackUserLoginSuccess(login, user, metadata) +``` +{{% /collapse-content %}} + +{{% collapse-content title="로그인 실패" level="h4" expanded="false" id="nodejs-migration-login-failure" %}} +```javascript +const tracer = require('dd-trace') + +// 더 이상 사용되지 않는 메서드가 있는 컨트롤러에서: +const userId = 'user-id' // 더 이상 필수는 아니지만 사용 가능한 경우 도움이 됩니다. +const login = 'user@email.com' // 새로운 필수 인수 +const userExists = true +const metadata = { +// 'usr.login': 'user@email.com', 더 이상 메타데이터에 포함할 필요가 없습니다. 반드시 메인 인수로 전달되어야 합니다 + 'usr.id': userId, // 로그인 실패를 나머지 사용자 활동과 연관시키는 데 도움이 됩니다. + 'key': 'value' +} + +// tracer.appsec.trackUserLoginFailureEvent(userId, userExists, metadata) // 더 이상 사용되지 않음 +tracer.appsec.eventTrackingV2.trackUserLoginFailure(login, userExists, metadata) +``` +{{% /collapse-content %}} + +{{< /programming-lang >}} + +{{< programming-lang lang="python" >}} + +dd-trace-py v1.9.0부터 Python 트레이서 API를 사용하여 사용자 이벤트를 추적할 수 있습니다. + +다음 예제는 로그인 이벤트나 사용자 정의 이벤트(가입을 예로 들어)를 추적하는 방법을 보여줍니다. + +{{% collapse-content title="Login success" level="h4" expanded="true" %}} +```python +from ddtrace.appsec.trace_utils import track_user_login_success_event +from ddtrace import tracer +metadata = {"usr.login": "user@email.com"} +# name, email, scope, role, session_id, propagate는 선택 인수이며 +# 기본값은 None입니다(단, propagate 기본값은 True). +# 이 인수들은 set_user() 함수에 전달됩니다. +track_user_login_success_event(tracer, "userid", metadata) +``` +{{% /collapse-content %}} + +{{% collapse-content title="로그인 실패" level="h4" expanded="false" id="python-login-failure" %}} +```python +from ddtrace.appsec.trace_utils import track_user_login_failure_event +from ddtrace import tracer +metadata = {"usr.login": "user@email.com"} +# exists는 실패한 로그인 사용자가 시스템에 존재하는지 여부를 나타냅니다. +exists = False +# 숫자로 된 사용자 ID를 사용할 수 없는 경우, 고유 식별자(사용자 이름, 이메일 등)를 사용하면 됩니다 +track_user_login_failure_event(tracer, "userid", exists, metadata) +``` +{{% /collapse-content %}} + +{{% collapse-content title="사용자 정의 비즈니스 로직" level="h4" expanded="false" id="python-custom-business" %}} +```python +from ddtrace.appsec.trace_utils import track_custom_event +from ddtrace import tracer +metadata = {"usr.id": "userid"} +event_name = "users.signup" +track_custom_event(tracer, event_name, metadata) +``` +{{% /collapse-content %}} + +{{< /programming-lang >}} + +{{< /programming-lang-wrapper >}} + +### 코드를 수정하지 않고 비즈니스 로직 정보 추적 + +서비스에 AAP와 [Remote Configuration][1]이 활성화되어 있는 경우, 사용자 지정 WAF 규칙을 생성하여 일치하는 모든 요청에 ​​사용자 지정 비즈니스 로직 태그를 지정할 수 있습니다. 이 작업은 애플리케이션을 수정할 필요 없이 Datadog에서 모두 수행할 수 있습니다. + +시작하려면 [Custom WAF Rule 페이지][2]로 이동하여 "Create New Rule"을 클릭하세요. + +{{< img src="security/application_security/threats/custom-waf-rule-menu.png" alt="AAP 홈페이지에서 Protection을 클릭한 다음 In-App WAF 및 Custom Rules를 클릭하여 Custom WAF Rule 메뉴에 액세스합니다." style="width:100%;" >}} + +사용자 지정 WAF 규칙을 정의할 수 있는 메뉴가 열립니다. "Business Logic" 카테고리를 선택하면 이벤트 유형(예: `users.password_reset`)을 구성할 수 있습니다. 그런 다음 추적할 서비스와 특정 엔드포인트를 선택합니다. 규칙 조건을 사용하여 _계측할_ 코드 흐름을 식별하는 특정 파라미터를 타게팅할 수도 있습니다. 조건이 일치하면 라이브러리는 트레이스에 태그를 지정하고 AAP로 전달하도록 플래그를 지정합니다. 조건이 필요하지 않은 경우 모든 조건을 일치시키는 광범위한 조건을 설정할 수 있습니다. + +{{< img src="security/application_security/threats/custom-waf-rule-form.png" alt="Create New Rule 버튼을 클릭하면 나타나는 양식의 스크린샷" style="width:50%;" >}} + +저장된 규칙은 Remote Configuration이 활성화된 서비스 인스턴스에 배포됩니다. + + +[1]: /ko/agent/remote_config?tab=configurationyamlfile#application-security-management-asm +[2]: https://app.datadoghq.com/security/appsec/in-app-waf?config_by=custom-rules + +## 자동 사용자 활동 이벤트 추적 + +AAP가 활성화되면 Datadog Tracing Libraries는 사용자 활동 이벤트를 자동으로 감지하려고 시도합니다. + +자동으로 감지할 수 있는 이벤트는 다음과 같습니다. + +- `users.login.success` +- `users.login.failure` +- `users.signup` + +### 자동 사용자 활동 이벤트 추적 모드 + +자동 사용자 활동 추적은 다음과 같은 모드를 제공합니다. + +- `identification` 모드 (약어: `ident`): + - 이 모드는 기본 모드이며, 항상 사용자 ID를 수집하거나 가능한 최대한으로 수집합니다. + - 사용자 ID는 로그인 성공 및 실패 시 수집됩니다. 실패 시에는 사용자 존재 여부와 관계없이 사용자 ID가 수집됩니다. + - 계측된 프레임워크가 사용자 ID를 명확하게 제공하지 않고 구조화된 사용자 객체를 제공하는 경우, 객체 필드 이름을 기반으로 가능한 최적의 사용자 ID를 결정합니다. 다음 필드 이름 목록은 우선순위에 따라 정렬되고 고려됩니다. + - `id` + - `email` + - `username` + - `login` + - `user` + - 사용자 ID를 사용할 수 없거나 찾을 수 없는 경우 사용자 이벤트가 발생하지 않습니다. +- `anonymization` 모드(약어: `anon`): + - 이 모드는 `identification`와 동일하지만 사용자 ID를 해싱(SHA256)하고 결과 해시를 잘라내어 익명화합니다. +- `disabled` 모드: + - AAP 라이브러리는 자동화된 계측을 통해 사용자 ID를 수집하지 *않습니다*. + - 사용자 로그인 이벤트가 발생하지 않습니다. + +
모든 모드는 자동 계측에만 영향을 미치며, 수동 수집에는 적용되지 않습니다. 수동 수집은 SDK를 사용하여 구성되며, 해당 설정은 자동 계측에 의해 재정의되지 않습니다.
+ +### 수동 설정 + +Datadog 라이브러리를 사용하면 모드 약어인 `ident`|`anon`|`disabled`와 함께 `DD_APPSEC_AUTO_USER_INSTRUMENTATION_MODE` 환경 변수를 사용하여 자동 계측을 구성할 수 있습니다. + +기본 모드는 `identification`(약어: `ident`)입니다. + +예를 들면, `DD_APPSEC_AUTO_USER_INSTRUMENTATION_MODE=anon`입니다. + +### 더 이상 사용되지 않는 모드 + +
이전 모드는 더 이상 지원되지 않지만, 다음 주요 릴리스까지는 호환성이 유지됩니다.
+ +다음 모드는 더 이상 사용되지 않습니다. + +- `safe` 모드: 추적 라이브러리는 이벤트 메타데이터에 개인 식별 정보(PII) 정보를 포함하지 않습니다. 추적 라이브러리는 사용자 ID를 수집하려고 시도하며, 해당 사용자 ID가 유효한 [GUID][10]인 경우에만 수집합니다. +- `extended` 모드: 추적 라이브러리는 사용자 ID와 사용자 이메일을 수집하려고 시도합니다. 이 모드에서 Datadog은 사용자 ID가 GUID인지 유형을 확인하지 않습니다. 추적 라이브러리는 이벤트에서 추출할 수 있는 모든 값을 보고합니다. + +**참고**: 추적 라이브러리가 사용자 이벤트에서 정보를 추출하지 못할 수도 있습니다. 이러한 경우 이벤트는 빈 메타데이터로 보고됩니다. 해결하려면 [SDK](#adding-business-logic-information-login-success-login-failure-any-business-logic-to-traces)를 사용하여 사용자 이벤트를 수동으로 계측하세요. + +## 사용자 활동 이벤트 추적 비활성화 + +[AAP Software Catalog][14]를 통해 자동 사용자 활동 감지를 비활성화하려면 비활성화하려는 서비스의 자동 추적 모드 환경 변수 `DD_APPSEC_AUTO_USER_INSTRUMENTATION_MODE`를 `disabled`로 변경하세요. 모든 모드는 자동 계측에만 영향을 미치며, [Remote Configuration][15]을 활성화해야 합니다. + +수동 구성에서는 서비스에서 환경 변수 `DD_APPSEC_AUTOMATED_USER_EVENTS_TRACKING_ENABLED`를 `false`로 설정하고 다시 시작할 수 있습니다. 이 설정은 Datadog Agent가 아닌 Datadog Tracing Library를 호스팅하는 애플리케이션에서 설정해야 합니다. + +## 참고 자료 + +{{< partial name="whats-next/whats-next.html" >}} + +[3]: /ko/tracing/trace_collection/custom_instrumentation/ +[4]: /ko/security/default_rules/bl-rate-limiting/ +[5]: /ko/security/default_rules/bl-privilege-violation-user/ +[6]: /ko/security/default_rules/appsec-ato-groupby-ip/ +[7]: /ko/security/default_rules/bl-signup-ratelimit/ +[8]: /ko/security/default_rules/bl-account-deletion-ratelimit/ +[9]: /ko/security/default_rules/bl-password-reset/ +[10]: /ko/security/default_rules/bl-payment-failures/ +[11]: https://guid.one/guid +[12]: /ko/security/default_rules/appsec-ato-bf/ +[13]: /ko/security/default_rules/distributed-ato-ua-asn/ +[14]: https://app.datadoghq.com/security/appsec/inventory/services?tab=capabilities +[15]: /ko/agent/remote_config/ \ No newline at end of file diff --git a/content/ko/security/application_security/threats/setup/standalone/gcp-service-extensions.md b/content/ko/security/application_security/threats/setup/standalone/gcp-service-extensions.md new file mode 100644 index 0000000000000..9f9b07d265309 --- /dev/null +++ b/content/ko/security/application_security/threats/setup/standalone/gcp-service-extensions.md @@ -0,0 +1,489 @@ +--- +code_lang: gcp-service-extensions +code_lang_weight: 50 +further_reading: +- link: https://github.com/DataDog/dd-trace-go/tree/main/contrib/envoyproxy/go-control-plane/cmd/serviceextensions + tag: 소스 코드 + text: App and API Protection Service Extension 소스 코드 +- link: https://cloud.google.com/service-extensions/docs/overview + tag: 설명서 + text: Google Cloud Service Extensions 개요 +- link: /security/default_rules/?category=cat-application-security + tag: 설명서 + text: OOTB App and API Protection 규칙 +- link: /security/application_security/troubleshooting + tag: 설명서 + text: App and API Protection 트러블슈팅 +title: GCP Service Extensions를 위한 App and API Protection 활성화 +type: multi-code-lang +--- + +{{< callout url="#" btn_hidden="true" header="App and API Protection Service Extensions is in Preview" >}} +GCP App and API Protection Service Extensions 미리 보기를 사용해 보려면 하단의 설정 지침을 따릅니다. +{{< /callout >}} + +GCP Cloud Load Balancing 내에서 GCP Service Extensions를 통해 App and API Protection(AAP)를 활성화할 수 있습니다. Datadog App and API Protection Service Extensions 통합은 GCP 환경에서 직접 위협 탐지 및 차단 기능을 제공합니다. + +## 사전 필수 조건 + +- [Datadog Agent][1]는 애플리케이션의 운영 체제나 컨테이너, 클라우드 또는 가상 환경에 맞게 설치 및 설정됩니다. +- [원격 설정][2]으로 Datadog UI를 통해 공격자를 차단할 수 있게 설정합니다. +- GCP 프로젝트에는 `owner` 역할이나 `editor` 역할, 또는 관련 Compute Engine IAM 역할 `compute.instanceAdmin.v1`(인스턴스 생성) 및 `compute.networkAdmin`(로드 밸런싱 설정)이 있습니다. +- 서비스에 Cloud Load Balancer가 포함된 GCP 프로젝트가 설정됩니다. Cloud Load Balancer는 [Traffic Callouts를 지원하는 Application Load Balancers][3] 중 하나여야 합니다. +- Compute Engine API 및 Network Services API가 활성화됩니다. + + ```bash + gcloud services enable compute.googleapis.com networkservices.googleapis.com + ``` + +## 위협 탐지 활성화 + +GCP 환경에서 App and API Protection Service Extension을 설정하려면 Google Cloud Console 또는 Terraform 스크립트로 다음 단계를 완료합니다. + +**참고:** Google Cloud는 [콜아웃 백엔드 서비스 생성][4] 및 [Service Extension을 트래픽 확장으로 설정][5]하는 지침을 제공합니다. 다음 단계는 동일한 일반 설정을 사용하지만 Datadog App and API Protection에 특화된 커스텀 설정을 포함합니다. + +{{< tabs >}} +{{% tab "Google Cloud Console" %}} + +1. [Datadog App and API Protection Service Extensions Docker 이미지][1]로 VM Compute 인스턴스를 생성합니다. + + VM 인스턴스를 설정할 때 사용 가능한 환경 변수는 [설정](#configuration)을 참조하세요. + +
+ Note: Be sure to update your Firewall rules to allow the Load Balancer and Datadog agent to communicate with the Callout VM instance. +
+ +2. 비관리형 인스턴스 그룹에 VM을 추가합니다. + + 인스턴스 그룹의 포트 매핑에 `http:80` 및 `grpc:443` (또는 사용자가 설정한 값)을 지정합니다. + +3. 다음 설정으로 백엔드 서비스를 생성합니다. + - 프로토콜: `HTTP2` + - 포트 이름: `grpc` + - 리전: 리전 선택 + - 서비스 상태 확인 포트 번호: `80`(또는 사용자가 설정한 값) + +4. 해당 백엔드 서비스에 서비스 확장 VM이 포함된 인스턴스 그룹을 백엔드로 추가합니다. + +5. Traffic Service Extension 콜아웃을 설정합니다. + 1. Google Cloud Console에서 **Service Extensions**으로 이동하여 새 Service Extension을 만듭니다. + 2. 로드 밸런서 유형을 선택합니다. + 3. 유형으로 `Traffic extensions`를 선택합니다. + 4. 포워딩 규칙을 선택합니다. +

+ +6. Extension Chain 생성하기 + + 1. 모든 트래픽을 확장으로 전송하려면 **Match condition**에 `true`를 입력합니다. + 2. **Programability type**의 경우 `Callouts`를 선택합니다. + 3. 이전 단계에서 생성한 백엔드 서비스를 선택합니다. + 4. 목록에서 App and API Protection가 탐지를 실행할 모든 **이벤트**를 선택합니다(요청 헤더 및 응답 헤더는 **필수**입니다). + +
+ +{{% appsec-getstarted-2-plusrisk %}} + +{{< img src="/security/application_security/appsec-getstarted-threat-and-vuln_2.mp4" alt="Signals Explorer 및 세부 정보와 Vulnerabilities Explorer 및 세부 정보를 보여주는 영상" video="true" >}} + +[1]: https://github.com/DataDog/dd-trace-go/pkgs/container/dd-trace-go%2Fservice-extensions-callout +{{% /tab %}} + +{{% tab "Terraform" %}} + +Terraform으로 App and API Protection GCP Service Extension의 배포를 자동화할 수 있습니다. 이렇게 하면 기존 로드 밸런서와 함께 작동하도록 서비스 확장을 설정하는 프로세스가 간소화됩니다. + +### Terraform 배포 사전 필수 조건 + +- 로컬 머신에 설치된 [Terraform][1](버전 1.0.0 이상). +- 적절한 권한이 있는 GCP 자격 증명 +- Datadog API 키(Datadog Agent 설정에 사용) +- 애플리케이션용 기존 GCP Cloud Load Balancer + +### 인프라스트럭처 개요 + +Terraform 배포는 다음 컴포넌트를 생성합니다. +- 보안 이벤트가 포함된 트레이스를 수집하는 Datadog Agent VM +- 컨테이너에서 Datadog Service Extension Callout을 실행하는 VM +- 확장 프로그램과 Agent 간의 통신을 허용하는 방화벽 규칙 +- Service Extension VM을 포함하는 비관리형 인스턴스 그룹 +- 서비스 상태 점검이 있는 HTTP/2용으로 설정된 백엔드 서비스 +- 기존 로드 밸런서에 연결된 서비스 확장 + +### 배포 단계 + +App and API Protection Service Extension 배포에는 함께 동작하는 여러 컴포넌트가 필요합니다. 이러한 모든 컴포넌트를 모두 포함하여 배포 프로세스를 반복 가능하고 유지 관리하기 쉽도록 도와주는 Terraform 모듈을 만들어봅니다. + +1. 새 디렉터리와 필요한 Terraform 파일을 생성합니다. + + ```bash + mkdir gcp-aap-service-extension && cd gcp-aap-service-extension + touch main.tf variables.tf + ``` + +2. `main.tf` 파일에 다음 코드를 추가합니다. 이 파일은 네트워크 규칙, VM 인스턴스, 로드 밸런서 설정을 포함하여 App and API Protection Service Extension에 필요한 모든 인프라스트럭처 컴포넌트를 정의합니다. + + ```hcl + # main.tf + + #---------------------------------------------------------- + # Network Configuration + #---------------------------------------------------------- + + # Firewall rule to allow the Service Extension to communicate with the Datadog Agent + resource "google_compute_firewall" "aap_se_firewall" { + name = "${var.project_prefix}-dd-agent-firewall" + network = "default" + + allow { + protocol = "tcp" + ports = ["8126"] + } + + source_tags = ["http-server"] + target_tags = ["datadog-agent"] + } + + #---------------------------------------------------------- + # Datadog Agent Configuration + #---------------------------------------------------------- + + # Datadog Agent container configuration + module "gce-container-datadog-agent" { + source = "terraform-google-modules/container-vm/google" + + container = { + image = "public.ecr.aws/datadog/agent:latest" + env = [ + { + name = "DD_API_KEY", + value = var.datadog_agent_api_key, + }, + { + name = "DD_ENV", + value = "dev", + }, + ] + } + } + + # Datadog Agent VM instance that collects traces from the Service Extension + resource "google_compute_instance" "datadog_agent" { + name = "${var.project_prefix}-datadog-agent" + machine_type = "e2-medium" + zone = var.zone + + boot_disk { + auto_delete = true + + initialize_params { + image = module.gce-container-datadog-agent.source_image + } + + } + + network_interface { + network = "default" + subnetwork = var.application_vpc_subnetwork + } + + metadata = { + gce-container-declaration = module.gce-container-datadog-agent.metadata_value + google-logging-enabled = "true" + } + + lifecycle { + create_before_destroy = true + } + + tags = ["datadog-agent"] + } + + #---------------------------------------------------------- + # Service Extension Callout Container Configuration + #---------------------------------------------------------- + + # Datadog App and API Protection GCP Service Extension container configuration + module "gce-container-aap-service-extension" { + source = "terraform-google-modules/container-vm/google" + + container = { + image = "ghcr.io/datadog/dd-trace-go/service-extensions-callout:v1.72.1" # Replace with the latest version + env = [ + { + name = "DD_AGENT_HOST", + value = google_compute_instance.datadog_agent.network_interface.0.network_ip, + } + ] + } + } + + # Service Extension VM instance (callout instance) + resource "google_compute_instance" "default" { + name = "${var.project_prefix}-instance" + machine_type = "e2-medium" + zone = var.zone + + boot_disk { + auto_delete = true + + initialize_params { + image = module.gce-container-aap-service-extension.source_image + } + + } + + network_interface { + network = var.application_vpc_network + subnetwork = var.application_vpc_subnetwork + } + + metadata = { + gce-container-declaration = module.gce-container-aap-service-extension.metadata_value + google-logging-enabled = "true" + } + + lifecycle { + create_before_destroy = true + } + + # http-server: Allow access on the http server for health checks + # https-server: Allow access on the 443 port for the AAP Service Extension + tags = ["http-server", "https-server", "lb-health-check"] + } + + #---------------------------------------------------------- + # Load Balancer Integration + #---------------------------------------------------------- + + # Unmanaged Instance Group including the App and API Protection Service Extension instance + resource "google_compute_instance_group" "aap_se_instance_group" { + name = "${var.project_prefix}-instance-group" + description = "Unmanaged instance group for the App and API Protection Service Extension" + zone = var.zone + + named_port { + name = "http" + port = 80 + } + + named_port { + name = "grpc" + port = "443" + } + + instances = [ + google_compute_instance.default.self_link + ] + } + + # Health Check for the Backend Service + resource "google_compute_health_check" "aap_se_health_check" { + name = "${var.project_prefix}-health-check" + check_interval_sec = 5 + timeout_sec = 5 + healthy_threshold = 2 + unhealthy_threshold = 2 + + http_health_check { + port = 80 + request_path = "/" + } + } + + # Backend Service that points to the Service Extension instance group + resource "google_compute_backend_service" "se_backend_service" { + name = "${var.project_prefix}-backend-service" + port_name = "grpc" + protocol = "HTTP2" + timeout_sec = 10 + health_checks = [google_compute_health_check.aap_se_health_check.self_link] + load_balancing_scheme = "EXTERNAL_MANAGED" + + backend { + group = google_compute_instance_group.aap_se_instance_group.self_link + } + } + + #---------------------------------------------------------- + # GCP Service Extension + #---------------------------------------------------------- + + # GCP Service Extension configuration for traffic interception + resource "google_network_services_lb_traffic_extension" "default" { + name = "${var.project_prefix}-service-extension" + description = "Datadog App and API Protection Service Extension" + location = "global" + + load_balancing_scheme = "EXTERNAL_MANAGED" + forwarding_rules = [var.load_balancer_forwarding_rule] + + extension_chains { + name = "${var.project_prefix}-service-extension-chain" + + match_condition { + cel_expression = "true" # Match all traffic + } + + extensions { + name = "${var.project_prefix}-service-extension-chain-ext" + authority = "datadoghq.com" + service = google_compute_backend_service.se_backend_service.self_link + timeout = "0.5s" + fail_open = false # If the extension fails, the request is dropped + + # Supported events for the App and API Protection Service Extension + supported_events = ["REQUEST_HEADERS", "REQUEST_BODY", "RESPONSE_HEADERS", "RESPONSE_BODY"] + } + } + } + ``` + + +3. `variables.tf` 파일에 다음 콘텐츠를 추가합니다. 이 파일은 Terraform 설정에 필요한 모든 입력 변수를 정의합니다. + + ```hcl + # variables.tf + + variable "region" { + description = "The GCP region where resources will be created (e.g., us-central1)" + type = string + validation { + condition = length(var.region) > 0 + error_message = "Region cannot be empty." + } + } + + variable "zone" { + description = "The GCP zone where zonal resources will be created (e.g., us-central1-a)" + type = string + validation { + condition = length(var.zone) > 0 + error_message = "Zone cannot be empty." + } + } + + # Project configuration + variable "project_prefix" { + description = "Prefix for the project. All resource names will be prefixed with this value" + type = string + validation { + condition = length(var.project_prefix) > 0 + error_message = "Project prefix cannot be empty." + } + } + + # Network configuration + variable "application_vpc_network" { + + description = "Name of the VPC network for the application" + type = string + validation { + condition = length(var.application_vpc_network) > 0 + error_message = "VPC network name cannot be empty." + } + } + + variable "application_vpc_subnetwork" { + + description = "Name of the VPC subnetwork for the application" + type = string + validation { + condition = length(var.application_vpc_subnetwork) > 0 + error_message = "VPC subnetwork name cannot be empty." + } + } + + # Authentication and API keys + variable "datadog_agent_api_key" { + description = "Datadog API key" + type = string + sensitive = true + validation { + condition = length(var.datadog_agent_api_key) > 0 + error_message = "Datadog API key cannot be empty." + } + } + + # Load balancer configuration + variable "load_balancer_forwarding_rule" { + description = "Self link to the forwarding rule for the load balancer" + } + ``` + +4. 메인 Terraform 프로젝트에 모듈을 포함합니다. 본 예시는 위에서 생성한 모듈을 참조하는 방법을 보여줍니다. + + ```hcl + # main.tf + + module "service_extension" { + source = "./gcp-aap-service-extension" + zone = "us-central1-a" + region = "us-central1" + project_prefix = "datadog-aap" + application_vpc_subnetwork = "your-subnet-name" + datadog_agent_api_key = "your-datadog-api-key" + load_balancer_forwarding_rule = "projects/your-project/regions/us-central1/forwardingRules/your-lb-rule" # or with a self link on your resource + } + ``` + +5. Terraform 파일이 있는 디렉토리에서 다음 명령을 실행하여 인프라스트럭처를 배포합니다. + + ```bash + terraform init + terraform plan + terraform apply + ``` + +### 배포 후 유효성 검사 + +서비스 확장은 로드 밸런서를 통과하는 모든 트래픽을 자동 검사하여 보안 위협을 탐지합니다. + +{{% appsec-getstarted-2-plusrisk %}} + +{{< img src="/security/application_security/appsec-getstarted-threat-and-vuln_2.mp4" alt="신호 탐색기 및 세부 정보와 취약점 탐색기 및 세부 정보를 보여주는 영상" video="true" >}} + +[1]: https://www.terraform.io/ +{{% /tab %}} +{{< /tabs >}} + +## 설정 + +Datadog App and API Protection Service Extension Docker 이미지는 다음 구성 설정을 지원합니다. + +| 환경 변수 | 기본값 | 설명 | +|----------------------------------------|-----------------|-------------------------------------------------------------------| +| `DD_SERVICE_EXTENSION_HOST` | `0.0.0.0` | gRPC 서버 수신 주소입니다. | +| `DD_SERVICE_EXTENSION_PORT` | `443` | gRPC 서버 포트입니다. | +| `DD_SERVICE_EXTENSION_HEALTHCHECK_PORT`| `80` | 서비스 상태 점검을 위한 HTTP 서버 포트입니다. | + +다음 환경 변수를 사용하여 Datadog Agent로 트레이스를 전송하도록 컨테이너를 설정합니다. + +| 환경 변수 | 기본값 | 설명 | +|----------------------------------------|---------------|-----------------------------------------------------------------------| +| `DD_AGENT_HOST` | `localhost` | Datadog Agent가 실행되는 호스트 이름입니다. | +| `DD_TRACE_AGENT_PORT` | `8126` | 트레이스 수집용 Datadog Agent 포트입니다. | + +
+ 참고: GCP Service Extensions 통합은 Datadog Go Tracer에 기반하여 만들어졌습니다. 트레이서와 동일한 릴리스 프로세스를 따르며, Docker 이미지에 해당 트레이스 버전 태그가 지정됩니다. +
+ +GCP Service Extensions 통합은 [Datadog Go Tracer][6]를 사용하며 트레이서로부터 모든 환경 변수를 상속받습니다. 자세한 설정 옵션은 [Go 추적 라이브러리 설정하기][7] 및 [App and API Protection 라이브러리 설정하기][8]에서 확인할 수 있습니다. + +## 한계 + +GCP Service Extensions에는 다음과 같은 제한 사항이 있습니다. + +* 요청 본문은 콘텐츠 유형에 관계없이 검사하지 않습니다. + +## 참고 자료 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://app.datadoghq.com/account/settings#agent +[2]: https://docs.datadoghq.com/ko/agent/remote_config/?tab=configurationyamlfile#enabling-remote-configuration +[3]: https://cloud.google.com/service-extensions/docs/lb-extensions-overview#supported-lbs +[4]: https://cloud.google.com/service-extensions/docs/configure-callout-backend-service +[5]: https://cloud.google.com/service-extensions/docs/configure-traffic-extensions +[6]: https://github.com/DataDog/dd-trace-go +[7]: https://docs.datadoghq.com/ko/tracing/trace_collection/library_config/go/ +[8]: https://docs.datadoghq.com/ko/security/application_security/threats/library_configuration/ \ No newline at end of file diff --git a/content/ko/security/workload_protection/agent.md b/content/ko/security/workload_protection/agent.md new file mode 100644 index 0000000000000..1fe909a8fc92f --- /dev/null +++ b/content/ko/security/workload_protection/agent.md @@ -0,0 +1,94 @@ +--- +aliases: +- /ko/security/threats/agent +description: CSM Threats 규칙에 관한 에이전트 표현식 속성 및 연산자 +disable_edit: true +further_reading: +- link: /security/cloud_workload_security/getting_started/ + tag: 설명서 + text: Datadog CSM Threats 시작하기 +title: 에이전트 규칙 표현식 만들기 +--- + + + +## 지원 규칙 생성자를 활용하여 커스텀 규칙 생성하기 + +**지원 규칙 생성자** 옵션을 사용하면 에이전트 및 종속 탐지 규칙을 함께 생성할 수 있으며, 탐지 규칙에서 에이전트 규칙을 참조하도록 할 수 있습니다. 이 도구를 사용하면 에이전트 및 탐지 규칙을 별도로 생성하는 고급 작업보다 더 빠르게 생성할 수 있습니다. + +자세한 내용은 [커스텀 탐지 규칙 생성하기][1]를 참조하세요. + +## 에이전트 정규식 구문 +클라우드 보안 관리 위협(CSM 위협)은 먼저 Datadog 에이전트 내의 활동을 에이전트 정규식에 대해 평가하여 수집할 활동을 결정합니다. CSM 위협 규칙의 이러한 부분을 에이전트 정규식이라고 합니다. 에이전트 정규식은 Datadog의 보안 언어(SECL)를 사용합니다. SECL 정규식의 표준 형식은 다음과 같습니다. + +{{< code-block lang="javascript" >}} +. [ .] ... + +{{< /code-block >}} + +이 형식을 사용하는 Linux 시스템의 규칙 예시는 다음과 같습니다. + +{{< code-block lang="javascript" >}} +open.file.path == "/etc/shadow" && process.file.path not in ["/usr/sbin/vipw"] + +{{< /code-block >}} + +## 연산자 +SECL 연산자는 이벤트 속성을 전체 정규식에 조합하는 데 사용됩니다. 다음과 같은 연산자를 사용할 수 있습니다. + +| SECL 연산자 | 유형 | 정의 | 에이전트 버전 | +|-----------------------|------------------|------------------------------------------|---------------| +| `==` | 프로세스 | Equal | 7.27 | +| `!=` | 파일 | Not equal | 7.27 | +| `>` | 파일 | Greater | 7.27 | +| `>=` | 파일 | Greater or equal | 7.27 | +| `<` | 파일 | Lesser | 7.27 | +| `<=` | 파일 | Lesser or equal | 7.27 | +| `!` | 파일 | Not | 7.27 | +| `^` | 파일 | Binary not | 7.27 | +| `in [elem1, ...]` | 파일 | 목록에 포함된 요소 | 7.27 | +| `not in [elem1, ...]` | 파일 | 목록에 포함되지 않은 요소 | 7.27 | +| `=~` | 파일 | 문자열 일치 | 7.27 | +| `!~` | 파일 | 문자열이 일치하지 않음 | 7.27 | +| `&` | 파일 | Binary and | 7.27 | +| `\|` | 파일 | Binary or | 7.27 | +| `&&` | 파일 | Logical and | 7.27 | +| `\|\|` | 파일 | Logical or | 7.27 | +| `in CIDR` | 네트워크 | IP 범위에 있는 요소 | 7.37 | +| `not in CIDR` | 네트워크 | IP 범위에 없는 요소 | 7.37 | +| `allin CIDR` | 네트워크 | IP 범위에 있는 모든 요소 | 7.37 | +| `in [CIDR1, ...]` | 네트워크 | IP 범위에 있는 요소 | 7.37 | +| `not in [CIDR1, ...]` | 네트워크 | IP 범위에 없는 요소 | 7.37 | +| `allin [CIDR1, ...]` | 네트워크 | IP 범위에 있는 모든 요소 | 7.37 | + +## 패턴 및 정규식 +패턴 또는 정규식은 SECL 정규식에 사용할 수 있습니다. `in`, `not in`, `=~`, `!~` 연산자와 같이 사용할 수 있습니다. + +| 형식 | 예시 | 지원되는 필드 | 에이전트 버전 | +|------------------|----------------------|--------------------|---------------| +| `~"pattern"` | `~"httpd.*"` | 전체 | 7.27 | +| `r"regexp"` | `r"rc[0-9]+"` | `.path` 제외 전체 | 7.27 | + +`.path` 필드의 패턴은 Glob으로 사용됩니다. `*` 은 파일과 폴더를 같은 레벨에서 일치시킵니다. `**` 는 7.34에서 도입한 것으로, 경로 끝에 사용하여 모든 파일과 하위 폴더를 매칭합니다. + +## 기간 +SECL을 사용하여 특정 시간 동안 이벤트에서 트리거되는 '기간에 기반한 규칙'을 작성할 수 있습니다. 예를 들어, 프로세스 생성 후 일정 시간 이상 기밀 파일에 액세스하면 이벤트에서 트리거됩니다. +다음과 같이 규칙을 작성할 수 있습니다. + +{{< code-block lang="javascript" >}} +open.file.path == "/etc/secret" && process.file.name == "java" && process.created_at > 5s + +{{< /code-block >}} + +기간은 단위 접미사가 있는 숫자입니다. 지원되는 접미사는 "s", "m", "h"입니다. + +## 플랫폼별 구문 + +SECL 정규식은 여러 플랫폼을 지원합니다. 아래 문서에서 각각에 대해 어떤 속성과 헬퍼를 사용할 수 있는지 확인할 수 있습니다. + +* [Linux][2] +* [Windows][3] + +[1]: /ko/security/workload_protection/workload_security_rules/custom_rules +[2]: /ko/security/workload_protection/linux_expressions +[3]: /ko/security/workload_protection/windows_expressions \ No newline at end of file diff --git a/content/ko/serverless/guide/datadog_forwarder_go.md b/content/ko/serverless/guide/datadog_forwarder_go.md index ab3694da75c16..1c90c6071aee8 100644 --- a/content/ko/serverless/guide/datadog_forwarder_go.md +++ b/content/ko/serverless/guide/datadog_forwarder_go.md @@ -1,6 +1,7 @@ --- title: Datadog 포워더를 사용하여 Go 서버리스 애플리케이션 계측하기 --- + ## 개요
@@ -31,7 +32,7 @@ go get github.com/DataDog/datadog-lambda-go 다음 단계에 따라 함수를 계측합니다: 1. 환경 변수 `DD_FLUSH_TO_LOG`와 `DD_TRACE_ENABLED`를 `true`로 설정합니다. -2. Lamda 함수 처리기가 표시되는 파일에서 필요한 패키지를 가져옵니다. +2. Lambda 함수 핸들러를 정의하는 파일에서 필수 패키지를 가져옵니다. {{% tracing-go-v2 %}} ```go package main @@ -39,8 +40,8 @@ go get github.com/DataDog/datadog-lambda-go import ( "github.com/aws/aws-lambda-go/lambda" "github.com/DataDog/datadog-lambda-go" - "gopkg.in/DataDog/dd-trace-go.v1/ddtrace/tracer" - httptrace "gopkg.in/DataDog/dd-trace-go.v1/contrib/net/http" + "github.com/DataDog/dd-trace-go/v2/ddtrace/tracer" + httptrace "github.com/DataDog/dd-trace-go/contrib/net/http/v2" ) ``` 3. Datadog Lamda 라이브러리에서 제공하는 래퍼를 사용해 Lamda 함수 처리기를 래핑합니다. @@ -77,9 +78,9 @@ go get github.com/DataDog/datadog-lambda-go } ``` -### 연결 +### 구독 -메트릭, 트레이스, 로그를 Datadog으로 보내려면 각 함수 로그 그룹에서 Datadog 포워더 Lamda 함수를 연결하세요. +메트릭, 트레이스, 로그를 Datadog로 보내려면 각 함수 로그 그룹에서 Datadog 포워더 Lamda 함수를 연결하세요. 1. [아직 설치하지 않았다면 Datadog 포워더를 설치하세요][2]. 2. [Datadog 포워더를 함수의 로그 그룹에 연결][4]합니다. @@ -147,4 +148,5 @@ func myHandler(ctx context.Context, event MyEvent) (string, error) { [4]: /ko/logs/guide/send-aws-services-logs-with-the-datadog-lambda-function/#collecting-logs-from-cloudwatch-log-group [5]: /ko/getting_started/tagging/unified_service_tagging/#aws-lambda-functions [6]: https://app.datadoghq.com/functions -[7]: /ko/serverless/custom_metrics?tab=go \ No newline at end of file +[7]: /ko/serverless/custom_metrics?tab=go +[8]: /ko/tracing/trace_collection/custom_instrumentation/go/migration \ No newline at end of file diff --git a/content/ko/service_management/service_level_objectives/guide/slo_types_comparison.md b/content/ko/service_management/service_level_objectives/guide/slo_types_comparison.md new file mode 100644 index 0000000000000..2322ae7376bb1 --- /dev/null +++ b/content/ko/service_management/service_level_objectives/guide/slo_types_comparison.md @@ -0,0 +1,67 @@ +--- +further_reading: +- link: /service_management/service_level_objectives/ + tag: 설명서 + text: 서비스 수준 목표(Service Level Objectives) 개요 +- link: /service_management/service_level_objectives/metric/ + tag: 설명서 + text: 메트릭 기반 SLO +- link: /service_management/service_level_objectives/monitor/ + tag: 설명서 + text: 모니터 기반 SLO +- link: /service_management/service_level_objectives/time_slice/ + tag: 설명서 + text: 타임 슬라이스 SLO +- link: https://www.datadoghq.com/blog/define-and-manage-slos/ + tag: 블로그 + text: Datadog으로 SLO를 관리한 모범 사례 +title: SLO 유형 비교 +--- + +## 개요 + +SLO를 생성할 때 다음 유형 중에서 선택할 수 있습니다: +- **메트릭 기반 SLO**: SLI 계산을 개수 기반으로 하고자 할 때 사용할 수 있으며, SLI는 총 이벤트 합계를 좋은 이벤트 합계로 나눠 계산됩니다. +- **모니터링-기반 SLO**: SLI 계산을 시간 기반으로 하고자 할 때 사용할 수 있으며, SLI는 모니터링 가동 시간을 기반으로 합니다. 모니터링-기반 SLO는 신규 또는 기존 Datadog 모니터링을 기반으로 해야 하며, 모든 조정은 기본 모니터링 을 통해 이루어져야 합니다(SLO 생성을 통해서는 할 수 없음). +- **타임 슬라이스 SLO**: 시간 기반 SLI 계산을 원할 때 사용할 수 있으며, SLI는 커스텀 가동 시간 정의(시스템이 정상 동작한 시간을 총 시간으로 나눈 값)를 기반으로 합니다. 타임 슬라이스 SLO에는 Datadog 모니터 , 다양한 메트릭 필터 및 임계값을 사용해 볼 수 있으며 SLO를 만드는 동안 다운타임을 즉시 탐색할 수 있습니다. + +
메트릭 기반 및 시간 슬라이스 SLO에 지원되는 기록 기간은 계정의 메트릭 기간과 일치합니다(기본값은 15개월).
+ +## 비교 차트 + +| | **메트릭 기반 SLO** | **모니터 기반 SLO** | **타임 슬라이스 SLO** | +|-----------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------| +| **지원되는 데이터 유형** | 카운트, 비율, 또는 분포 유형이 있는 메트릭 | 메트릭 모니터 유형, 신서틱 모니터 및 서비스 점검 | 모든 메트릭 유형(게이지 메트릭 포함) | +| **SLO with Groups 기능** | SLO는 모든 그룹을 기준으로 계산됩니다.

SLO 사이드 패널 및 SLO 위젯에서 모든 그룹을 볼 수 있습니다. | 단일 멀티 알림 모니터로 SLO를 지원합니다.

**옵션 1:** 모든 그룹을 기준으로 SLO 계산(SLO 사이드 패널 및 SLO 위젯에서 모든 그룹 보기 가능)
**옵션 2:** 최대 20개의 선택된 그룹을 기준으로 SLO 계산(SLO 사이드 패널 및 SLO 위젯에서 선택된 모든 그룹 보기 가능) | SLO는 모든 그룹을 기준으로 계산됩니다.

SLO 사이드 패널 및 SLO 위젯에서 모든 그룹을 볼 수 있습니다. | +| **SLO 사이드 패널** | 사용자 지정 기간을 설정하여 최대 15개월의 SLO 기록을 볼 수 있습니다. | 사용자 지정 기간을 설정하여 최대 3개월의 SLO 기록을 볼 수 있습니다. | 사용자 지정 기간을 설정하여 최대 15개월의 SLO 기록을 볼 수 있습니다. | +| **SLO 알림([Error Budget)][1] 또는 [Burn Rate][2] 알림)** ** | 사용 가능

그룹이 있는 경우 전체 SLO만 기준으로 알림 가능 | 메트릭 모니터 유형에 기반한 SLO에만 사용 가능(신서틱 모니터 또는 서비스 점검에는 사용 불가)

그룹이 있는 경우 전체 SLO에 대해서만 알림 가능 | 사용 가능

그룹이 있는 경우 그룹 또는 전체 SLO를 기준으로 경고할 수 있습니다. | +| [**SLO 상태 수정**][3] | 수정 기간은 SLO 상태 계산에서 무시됩니다. | 수정 기간은 SLO 상태 계산에서 무시됩니다. | 수정 기간은 SLO 상태 계산에서 가동 시간으로 계산됩니다. | +| **SLO 위젯([SLO 목록 위젯][10] 또는 [SLO 위젯][9]**)** | SLO 위젯으로 최대 15개월의 과거 데이터를 볼 수 있습니다. | SLO 위젯으로 최대 3개월의 과거 데이터를 볼 수 있습니다. | SLO 위젯으로 최대 15개월의 과거 데이터를 볼 수 있습니다. | +| **[SLO 데이터 소스][5](최대 15개월의 과거 데이터)** | 사용 가능 | 사용 불가 | 사용 가능 | +| **SLO 계산에서 누락된 데이터 처리하기** | 누락된 데이터는 SLO 상태 및 오류 예산 계산에서 무시됩니다. | 누락된 데이터는 [기본 모니터 구성][6]에 따라 처리됩니다. | 누락된 데이터는 SLO 상태 및 오류 예산 계산에서 가동 시간으로 처리됩니다. | +| **가동 시간 계산** | N/A | 가동 시간 계산은 기본 모니터를 기준으로 합니다.

그룹이 있으면, 전체 가동 시간의 경우 *모든* 그룹에 가동 시간이 있어야 합니다.| [가동 시간][7]은 롤링 시간 창이 아닌 개별 시간 청크를 기반으로 계산됩니다
.
그룹이 있으면, 전체 가동 시간의 경우 *모든* 그룹에 가동 시간이 있어야 합니다. | +| **SLO 관리 페이지의 [달력 보기][11]** | 사용 가능 | 사용 불가 | 사용 가능 | +| **공개 [API][8] 및 Terraform 지원** | 사용 가능 | 사용 가능 | 사용 가능 | + +## SLO 유형 선택 모범 사례 + +- 가능하면 메트릭 기반 SLO를 사용하세요. 오류 예산에서 SLO를 위반하기 전에 발생한 불량 이벤트 수를 반영하도록 SLO를 설정하는 것이 가장 좋습니다. 또한 이벤트 수에 따라 SLO 계산에 볼륨 가중치가 적용됩니다. +- 대신 가동 시간을 추적하고 시간 기반 SLI 계산을 사용하는 SLO를 원한다면 시간 슬라이스 SLO를 사용하세요. 모니터 기반 SLO와 달리 시간 슬라이스 SLO는 SLO에 대한 기본 모니터를 유지 관리할 필요가 없습니다. +- 마지막으로, 메트릭 외 모니터 또는 여러 모니터에 기반한 SLO를 포함해, 시간 슬라이스 SLO가 적용되지 않는 사용 사례의 경우 모니터 기반 SLO를 고려하세요. + + +## 참고 자료 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://docs.datadoghq.com/ko/service_management/service_level_objectives/error_budget/ +[2]: https://docs.datadoghq.com/ko/service_management/service_level_objectives/burn_rate/ +[3]: https://docs.datadoghq.com/ko/service_management/service_level_objectives/#slo-status-corrections +[4]: https://docs.datadoghq.com/ko/service_management/service_level_objectives/#slo-widgets +[5]: https://docs.datadoghq.com/ko/dashboards/guide/slo_data_source/ +[6]: https://docs.datadoghq.com/ko/service_management/service_level_objectives/monitor/#missing-data +[7]: /ko/service_management/service_level_objectives/time_slice/#uptime-calculations +[8]: https://docs.datadoghq.com/ko/api/latest/service-level-objectives/ +[9]: https://docs.datadoghq.com/ko/dashboards/widgets/slo/ +[10]: https://docs.datadoghq.com/ko/dashboards/widgets/slo_list/ +[11]: https://docs.datadoghq.com/ko/service_management/service_level_objectives/#slo-calendar-view \ No newline at end of file diff --git a/content/ko/synthetics/explore/results_explorer/search.md b/content/ko/synthetics/explore/results_explorer/search.md new file mode 100644 index 0000000000000..cbc33826b057b --- /dev/null +++ b/content/ko/synthetics/explore/results_explorer/search.md @@ -0,0 +1,87 @@ +--- +aliases: +- /ko/synthetics/explorer/search +- /ko/continuous_testing/explorer/search/ +description: 실행된 CI 작업의 배치를 검사하고 실패한 테스트 결과의 문제를 해결합니다. +further_reading: +- link: /synthetics/explore/results_explorer + tag: 설명서 + text: 신서틱 모니터링 및 테스트 결과 탐색기에 대해 자세히 알아보기 +title: 테스트 배치 검색 +--- + +## 개요 + +오른쪽 상단의 드롭다운 메뉴에서 기간을 선택한 후 [신서틱(Synthetic) 모니터링 및 테스트 결과 탐색기][1]에서 **CI 배치** 이벤트 유형을 클릭하여 CI 작업의 배치를 검색할 수 있습니다. + +{{< img src="continuous_testing/explorer/results_explorer.png" alt="CI batches in the Synthetic Monitoring & Testing Results Explorer" style="width:100%;">}} + +패싯을 사용하여 다음 작업을 수행할 수 있습니다. + +- CI 파이프라인에서 실행 중인 최신 테스트 배치를 확인합니다. +- CI 배치를 집계하고 CI 파이프라인에 추가할 테스트 ID를 식별합니다. +- 차단 상태별로 테스트 실행 실패 횟수를 비교합니다. + +## 패싯 탐색하기 + +왼쪽 패싯 패널에 배치 검색에 사용할 수 있는 여러 패싯이 표시됩니다. 검색 쿼리를 사용자 지정하려면 **배치**로 시작하는 패싯 목록을 클릭하세요. + +### 배치 속성 + +**배치** 패싯을 사용하면 배치의 속성을 필터링할 수 있습니다. + +| 패싯 | 설명 | +|------------------|-------------------------------------------------------------| +| `Summary Status` | 배치 상태: `Passed`, `Failed`, `In Progress`. | +| `Duration` | 배치의 전체 처리 시간입니다. | +| `ID` | 배치 ID입니다. | + +### CI 속성 + +**CI** 패싯을 사용하면 배치의 CI 관련 속성을 필터링할 수 있습니다. + +| 패싯 | 설명 | +|----------------|---------------------------------------------| +| `CI Provider` | 배치와 연관된 CI 공급자입니다. | +| `Job Name` | 배치와 연관된 작업 이름입니다. | +| `Job URL` | 배치와 연관된 작업 URL입니다. | +| `Pipeline ID` | 배치와 연관된 파이프라인 ID입니다. | +| `Pipeline Name` | 배치와 연관된 파이프라인 또는 리포지토리 이름입니다. | +| `Pipeline Number` | 배치와 연관된 파이프라인 또는 빌드 넘버입니다. | +| `Pipeline URL` | 배치와 연관된 파이프라인 URL입니다. | +| `Stage Name` | 배치와 연관된 스테이지 이름입니다. | + +### 테스트 결과 속성 + +**테스트 결과** 패싯을 사용하면 실행한 테스트 결과 속성을 필터링할 수 있습니다. + +| 패싯 | 설명 | +|------------------|---------------------------------------------------------------------------------------------------------| +| 실행 규칙 | 배치의 테스트 결과와 연관된 실행 규칙입니다: `Blocking`, `Non Blocking`, `Skipped`. | +| `Fast Retries` | 배치의 테스트 결과와 연관된 빠른 재시도 횟수입니다. | +| `Location` | 배치의 테스트 결과와 연관된 위치입니다. | +| `Test ID` | 배치의 테스트 결과와 연관된 테스트 ID입니다. | +| `Test Name` | 배치의 테스트 결과와 연관된 테스트 이름입니다. | + +### Git 속성 + +**Git** 패싯을 사용하면 배치의 Git 관련 속성을 필터링할 수 있습니다. + +| 패싯 | 설명 | +|-------------|-------------------------------------------| +| `Author Email` | 커밋 작성자의 이메일 주소입니다. | +| `Branch` | 배치와 연관된 브랜치입니다. | +| `Commit SHA`| 배치와 연관된 커밋 SHA입니다. | +| `Repository URL`| 배치와 연관된 Git 리포지토리 URL입니다. | +| `Tag` | 배치와 연관된 Git 태그입니다. | + +지난 하루 동안 실행된 CI 작업 배치를 필터링하려면 `@ci.provider.name:github`와 같은 검색 쿼리를 생성하고 시간 범위를 `1d`로 설정합니다. + +CI 배치에 대한 더 자세한 정보는 [검색 신택스][2]를 참조하시기 바랍니다. + +## 참고 자료 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://app.datadoghq.com/synthetics/explorer/ +[2]: /ko/continuous_testing/explorer/search_syntax \ No newline at end of file diff --git a/content/ko/synthetics/guide/authentication-protocols.md b/content/ko/synthetics/guide/authentication-protocols.md new file mode 100644 index 0000000000000..1224ec3c6bec6 --- /dev/null +++ b/content/ko/synthetics/guide/authentication-protocols.md @@ -0,0 +1,106 @@ +--- +description: 신서틱(Synthetic) API 및 다단계 API 테스트가 애플리케이션에 로그인할 수 있는 방법을 알아봅니다. +further_reading: +- link: /data_security/synthetics + tag: 설명서 + text: 신서틱 데이터 보안에 관해 알아보기 +- link: /synthetics/api_tests + tag: 설명서 + text: API 테스트 생성 +- link: /synthetics/multistep + tag: 설명서 + text: 멀티스텝 API 테스트 만들기 +title: API 및 다단계 API 테스트에서 인증 사용 +--- + +## 개요 + +[API 테스트][1]로 애플리케이션의 API 엔드포인트에 요청을 전송하여 전체 응답 시간, 예상 상태 코드, 헤더, 또는 바디 콘텐츠와 같은 응답 및 정의된 조건을 확인할 수 있습니다. [다단계 API 테스트][2]로 요청을 체이닝하여 주요 서비스의 복잡한 여정을 사전 모니터링하고, 관리형 또는 비공개 위치에서 언제든지 사용할 수 있도록 할 수 있습니다. + +본 지침에서는 신서틱 API 및 다단계 API 테스트에 사용할 수 있는 다양한 인증 프로토콜에 관해 설명합니다. 브라우저 테스트에서 인증에 관한 자세한 내용은 [인증이 필요한 애플리케이션에서 테스트 실행하기][3]를 참조하세요. + +## 인증 메서드 + +엔드포인트에 인증이 필요한 경우, [API 생성][4] 또는 [다단계 API 테스트][5] 생성 시 자격 증명을 추가할 수 있습니다. API 및 다단계 API 테스트는 기본 액세스 인증, Digest 액세스 인증, OAuth2.0, NTLM, AWS Sigv4, 클라이언트 인증서 등의 인증 프로토콜을 지원합니다. + +**Define the request** 섹션에서 **Advanced Options** > **Authentication**을 클릭하고 다음 인증 메서드를 선택합니다. + +{{< tabs >}} +{{% tab "Basic Access" %}} + +**HTTP Basic Auth**을 클릭하고 사용자 아이디와 비밀번호를 입력합니다. 기본 액세스 인증은 [HTTP 테스트][1], [다단계 API 테스트][2], [WebSocket 테스트][3]에서 지원됩니다. + +[1]: /ko/synthetics/api_tests/http_tests/ +[2]: /ko/synthetics/multistep/ +[3]: /ko/synthetics/api_tests/websocket_tests/ +{{% /tab %}} +{{% tab "Digest Access" %}} + +**Digest Auth**를 클릭하고 사용자 아이디와 비밀번호를 입력합니다. 디지털 액세스 인증은 [HTTP 테스트][1]와 [다단계 API 테스트][2]에서 지원됩니다. + +[1]: /ko/synthetics/api_tests/http_tests/ +[2]: /ko/synthetics/multistep/ +{{% /tab %}} +{{% tab "OAuth 2.0" %}} + +**OAuth 2.0**을 클릭하고 인증 유형(**Client Credentials** 또는 **Resource Password**)을 선택한 다음 액세스 토큰 URL, 클라이언트 ID, 클라이언트 시크릿을 입력합니다. 토큰 API 인증 메서드(**Send as Basic Auth header** 또는 **Send client credentials in body**)를 선택하고 옵션으로 대상, 리소스, 범위를 입력합니다. OAuth 2.0 인증은 [HTTP 테스트][1]와 [다단계 API 테스트][2]에서 지원됩니다. + +[1]: /ko/synthetics/api_tests/http_tests/ +[2]: /ko/synthetics/multistep/ +{{% /tab %}} +{{% tab "NTLM" %}} + +**NTLM**을 클릭하고 사용자 아이디와 비밀번호, 옵션으로 도메인과 워크스테이션을 입력합니다. NTLM 인증은 [HTTP 테스트][1]와 [다단계 API 테스트][2]에서 지원됩니다. + +[1]: /ko/synthetics/api_tests/http_tests/ +[2]: /ko/synthetics/multistep/ +{{% /tab %}} +{{% tab "AWS Signature" %}} + +**AWS Signature**를 클릭하고 액세스 키 ID와 시크릿 액세스 키, 옵션으로 리전, 서비스 이름, 세션 토큰을 입력합니다. AWS 인증은 [HTTP 테스트][1]와 [다단계 API 테스트][2]에서 지원됩니다. + +[1]: /ko/synthetics/api_tests/http_tests/ +[2]: /ko/synthetics/multistep/ +{{% /tab %}} +{{% tab "Client Certificate" %}} + +**Upload File**를 클릭하여 비공개 키 파일과 인증서 파일을 업로드합니다. 클라이언트 +인증서 인증은 [HTTP 테스트][1], [다단계 API 테스트][2], [SSL 테스트][3], [gRPC 테스트][4]에서 지원됩니다. + +[1]: /ko/synthetics/api_tests/http_tests/ +[2]: /ko/synthetics/multistep/ +[3]: /ko/synthetics/api_tests/ssl_tests/ +[4]: /ko/synthetics/api_tests/grpc_tests/ +{{% /tab %}} +{{< /tabs >}} + +## 계정 보안 + +테스트 결과와 설정에서 사용자 자격 증명을 숨기려면 [API 생성][4] 또는 [다단계 API 테스트][5] 생성 시의 전역 및 로컬 변수를 사용할 수 있습니다. + +### 전역 변수 + +다음에 따라 자격 증명을 전역 변수로 저장합니다. + +- 여러 테스트에서 쉽게 재사용할 수 있습니다. +- **Hide and obfuscate variable value**를 선택하여 테스트 결과 및 설정에서 해당 값을 숨깁니다. +- [커스텀 역할][6]로 조직의 사용자 하위 집합에 대한 액세스를 제한합니다. + +### 로컬 변수 + +자격 증명을 로컬 변수로 저장하면 자격 증명의 범위가 고유한 테스트로 한정됩니다. 테스트 결과 및 설정에서 해당 값을 숨기려면 **Hide and obfuscate variable value**를 선택하세요. + +계정 보안과 관련한 자세한 정보는 [신서틱 모니터 데이터 보안][7]을 참고하세요. + +## 참고 자료 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ko/synthetics/api_tests/http_tests/ +[2]: /ko/synthetics/multistep/ +[3]: /ko/synthetics/guide/app-that-requires-login/ +[4]: https://app.datadoghq.com/synthetics/create?subtype=http +[5]: https://app.datadoghq.com/synthetics/multi-step/create +[6]: /ko/account_management/rbac/?tab=datadogapplication#create-a-custom-role +[7]: /ko/data_security/synthetics +[8]: /ko/synthetics/api_tests/grpc_tests \ No newline at end of file diff --git a/content/ko/tests/explorer/_index.md b/content/ko/tests/explorer/_index.md new file mode 100644 index 0000000000000..b1fa4ba0cb52b --- /dev/null +++ b/content/ko/tests/explorer/_index.md @@ -0,0 +1,141 @@ +--- +description: Test Optimization Explore에서 테스트 실행을 검색하고 필터링하는 방법을 알아보세요. +further_reading: +- link: /continuous_integration/tests/ + tag: 설명서 + text: 테스트 데이터를 탐색하여 문제가 발생한 테스트를 찾고 해결하세요 +- link: https://www.datadoghq.com/blog/configure-pipeline-alerts-with-ci-monitors/ + tag: 블로그 + text: Datadog CI 모니터로 파이프라인 알림을 설정하세요 +- link: /continuous_testing/guide/view-continuous-testing-test-runs-in-test-optimization/ + tag: 가이드 + text: Test Optimization에서 Continuous Testing 테스트 실행 보기 +title: Test Optimization Explorer +--- + +## 개요 + +Test Optimization Explorer를 통해 태그를 사용하여 여러 수준에서 테스트 실행을 [검색 및 필터링](#search-and-filter), [시각화](#visualize), [내보내기](#export)할 수 있습니다. + +[Software Delivery** > **Test Optimization** > **Test Runs**][6]으로 이동하여 **Session**, **Module**, **Suite** 및 **Test** 수준에서 CI 테스트 실행 결과를 확인합니다. 각 테스트 수준은 서로 다른 수준의 테스트 집계를 나타냅니다. + +{{< img src="/tests/explorer/test_runs.png" text="Test Optimization Explorer의 테스트 실행 결과 목록" style="width:100%" >}} + +## 일반 패싯 + +왼쪽의 **Test** 패널에는 테스트 실행을 검색하는 데 사용할 수 있는 기본 패싯이 나와 있습니다. + +| 패싯 | 설명 | +|---|---| +| Test Status | 테스트 결과로 `Passed`, `Failed`, 또는 `Skipped`가 있습니다. | +| 기간 | 테스트 완료하는 데 걸린 시간입니다. | +| Test Service | CI Visibility를 사용해 계측한 [테스트 서비스][12]입니다. | +| Test Full Name | 테스트 이름, 테스트 제품군 이름, 구성 또는 파라미터(있는 경우)를 포함하는 테스트 식별자입니다. | +| Test Name | 테스트 사례에 대한 간략한 이름. 테스트에서 정의됩니다. | +| 테스트 스위트 | 언어 및 테스트 프레임워크에 따라 동일한 코드 단위를 실행하는 [테스트 그룹][13]입니다. | +| Flaky | 동일한 커밋에 대해 여러 테스트 실행에서 통과 및 실패 상태를 모두 표시합니다. | +| Has Parameters | 테스트에 파라미터가 있는지 여부. `true` 또는 `false`입니다. | +| Known Flaky | 테스트가 `true` 또는 `false`로 일관되지 않을 수 있습니다.

이 테스트 실행은 실패하여 테스트가 현재 브랜치나 기본 브랜치에서 일관되지 않은 테스트로 식별됩니다. | +| 언어 | 테스트가 생성된 라이브러리의 프로그래밍 언어입니다. | +| New Flaky | `true` 또는 `false`로 일관되지 않은 테스트가 발생한 적이 있는지 여부.

테스트 실행이 커밋에서 비일관된 테스트로 식별됩니다. 테스트가 현재 브랜치나 기본 브랜치에서 일관되지 않은 테스트로 식별된 적 없습니다. | +| Performance Regression + | 테스트 시간이 평균의 5배이고 기본 브랜치의 동일 테스트 최대 시간보다 큰 경우 테스트 실행이 회귀로 표시됩니다. | +| Baseline Mean | 테스트 회귀의 경우 지난주 테스트 실행 동안 계산된 기본 브랜치의 동일한 기간 평균을 의미합니다. | +| Baseline Standard Deviation | 테스트 회귀의 경우 지난주 테스트 실행 기간에 계산된 기본 브랜치의 동일한 테스트에 대한 표준 편차를 의미합니다. | +| Absolute Change | 테스트 회귀에서 기준 평균과 비교한 테스트 실행 기간에 대한 절대적 변경을 의미합니다. | +| Relative Change | 테스트 회귀에서 기준 평균 대비 테스트 실행 기간에 대한 상대적 변경을 의미합니다. | +| Standard Deviation Change | 테스트가 신규로 추가되었는지 나타냅니다. | +| Test Code Owners | 리포지토리 구성에서 추론된 테스트 코드 소유자 이름입니다. | +| Test Fingerprint | 개별 테스트 실행에 대한 고유 식별자입니다. | +| Test Framework | 테스트 생성 및 실행에 사용된 기본 프레임워크 또는 일련의 툴입니다. | +| Test Command | 테스트 실행에 사용된 명령입니다. | +| Test Bundle | 테스트 모듈과 동등합니다. 이전 Datadog 테스트 라이브러리 버전에서 사용됩니다. | +| 테스트 전체 이름 | 테스트 전체 이름입니다. | +| Test Module | 테스트 모듈은 언어에 따라 다릅니다.

.NET에서는 테스트 모듈은 동일한 유닛 테스트 프로젝트에서 실행되는 모든 테스트를 그룹화합니다.
Swift에서는 테스트 모듈이 주어진 번들에 실행되는 모든 테스트를 그룹화합니다.
JavaScript에서 테스트 모듈은 테스트 세션에 일대일로 매핑됩니다.
Java에서 테스트 모듈은 동일한 Maven Surefire, Failsafe 또는 Gradle 테스트 작업 실행으로 실행되는 모든 테스트를 그룹화합니다.
Python에서 테스트 모듈은 일반적으로 `unittest` 또는 `pytest`와 같은 프레임워크에서 관리되는 테스트 제품군의 일부로 동일한 `.py` 파일에서 실행되는 모든 테스트를 그룹화합니다.
Ruby에서 테스트 모듈은 일반적으로 `RSpec` 또는 `Minitest`와 같은 프레임워크에서 관리되는 동일한 테스트 파일 내에서 실행되는 모든 테스트를 그룹화합니다. | +| Test Traits | `category:flaky`와 같은 테스트 특징입니다. | +| Test Type | `unit benchmark` 또는 `browser`와 같은 테스트 유형입니다. | +| RUM Active | 테스트가 활성 [실제 사용자 모니터링][14] 웹 세션 내부에서 실행되는지를 나타냅니다. | +| Is New | 테스트가 신규로 추가되었는지 나타냅니다. | +| Is Retry | 테스트가 재시도 결과로 실행되었는지 나타냅니다. | +| Code Coverage Enabled | [Test Impact Analysis][16]가 세션에 대해 테스트당 [코드 지원 범위][17]를 활성화했는지 나타냅니다. | +| Skipped by ITR | Test Impact Analysis에 의해 세션 동안 건너 뛴 테스트 수입니다. | +| Test Skipping Enabled | 테스트 세션 또는 모듈이 Test Impact Analysis를 사용해 건너뛰도록 허용되었는지 나타냅니다. | +| Test Skipping Type | Test Impact Analysis에서 사용된 메서드 또는 기준으로 건너 뛸 테스트를 결정하는 데 사용됩니다. | +| Test Skipped | 테스트 세션 중에 실행되지 않은 테스트의 총 개수로, 건너 뛰도록 구성되었거나 수동 제외로 설정된 테스트가 포함될 수 있습니다. | +| Time Saved | Test Impact Analysis 사용으로 세션에 절약한 시간입니다. | +| Early Flake Detection Enabled | [Early Flake Detection][15]를 사용하여 테스트를 실행했는지 여부를 나타냅니다. | +| Early Flake Detection Abort Reason | 테스트의 Early Flake Detection 금지 이유를 나타냅니다. | + +Test Optimization Explorer에서 검색 쿼리의 일부로 사용할 수 있는 일반적인 패싯에 대한 자세한 정보는 [테스트 실행 패싯][3]을 참조하세요. + +### 세션 + +테스트 세션은 가장 높은 수준의 집계입니다. `yarn test`, `mvn test` 또는 `dotnet test`와 같은 테스트 명령에 일대일로 대응합니다. + +JUnit 보고서 업로드의 경우 업로드되는 보고서 파일당 1개의 세션이 있습니다. + +### 모듈 + +모듈의 정의는 언어마다 조금씩 다릅니다. + +* .NET에서 테스트 모듈은 동일한 [단위 테스트 프로젝트][9]에서 실행되는 모든 테스트를 그룹화합니다. +* Swift에서 테스트 모듈은 지정된 번들에 실행되는 모든 테스트를 그룹화합니다. +* JavaScript에서 테스트 모듈은 테스트 세션에 일대일로 매핑됩니다. +* Java에서 테스트 모듈은 동일한 Maven Surefire/Failsafe 또는 Gradle Test 작업으로 실행되는 모든 테스트를 그룹화합니다. +* JUnit 보고서 업로드에서 테스트 모듈은 테스트 세션에 일대일로 매핑됩니다. + +모듈의 예는 `SwiftLintFrameworkTests`이며, 이는 [`SwiftLint`][10]의 테스트 대상에 해당합니다. + +### Suite + +테스트 제품군은 동일한 코드 단위를 실행하는 테스트 그룹입니다. + +테스트 제품군의 예는 `src/commands/junit/__tests__/upload.test.ts`이며, 이는 [`datadog-ci`][11]의 테스트 파일에 해당합니다. + +테스트 실행 데이터는 [대시보드][7]와 [노트북][8]에서 사용할 수 있기 때문에 빌드 엔지니어링 팀에서 우선순위가 높은 작업과 시간 경과에 따른 CI 트렌드에 따라 커뮤니케이션을 맞춤화할 수 있습니다. + +## 검색 및 필터링 + +왼쪽의 패싯을 클릭하거나 검색창에 사용자 지정 쿼리를 직접 작성하여 테스트 실행의 하위 집합으로 범위를 좁히거나, 넓히거나, 초점을 이동할 수 있습니다. 패싯을 선택하거나 선택 해제하면 검색창에 변경 사항이 자동으로 반영됩니다. 마찬가지로 검색창 쿼리를 수정하거나 검색창에 처음부터 쿼리를 작성하여 왼쪽의 패싯을 선택하거나 선택을 해제할 수 있습니다. + +- 테스트 검색 방법을 알아보려면 [탐색기)][1]을 참조하세요. +- 쿼리를 만드는 방법을 알아보려면 [검색 구문][2]을 참조하세요. + +## 분석 + +쿼리한 테스트 실행을 필드, 패턴 및 트랜잭션과 같은 상위 엔터티로 그룹화하여 정보를 도출하거나 통합합니다. 속성을 검색하기 위해 만들 필요가 없는 [패싯][3]을 사용하면 다음과 같은 작업을 할 수 있습니다. + +- CI/CD에서 실행 중인 테스트의 진행 상황을 검색하고 추적할 수 있습니다. +- 모든 CI/CD 작업 실행 건을 조사하여 실패한 테스트 실행을 식별하고 문제를 해결하세요. +- [일관되지 않은 테스트][5]를 식별하여 수정하세요. + +## 시각화 + +시각화 유형을 선택하여 필터 및 집계 결과를 시각화하고 테스트 실행 결과를 더 잘 이해할 수 있습니다. 예를 들어 테스트 결과를 목록으로 표시하여 테스트 데이터를 열로 구성하거나 [시계열 그래프][18]로 표시하여 시간 경과에 따른 CI 테스트 데이터를 측정할 수 있습니다. + +## 내보내기 + +Test Optimization Explorer에서 [보기 내보내기][4]를 하여 나중에 또는 다른 상황에서 재사용할 수 있습니다. + +## 참고 자료 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ko/tests/explorer/ +[2]: /ko/tests/explorer/search_syntax +[3]: /ko/tests/explorer/facets +[4]: /ko/tests/explorer/saved_views +[5]: /ko/tests/flaky_test_management +[6]: https://app.datadoghq.com/ci/test-runs +[7]: https://app.datadoghq.com/dashboard/lists +[8]: https://app.datadoghq.com/notebook/list +[9]: https://learn.microsoft.com/en-us/visualstudio/test/create-a-unit-test-project?view=vs-2022#to-create-a-unit-test-project +[10]: https://github.com/realm/SwiftLint/blob/7738f0c0a5990201ca6556bdb2f13f8e67b5191d/Package.swift#L71 +[11]: https://github.com/DataDog/datadog-ci/blob/6de6ea3bbffa57d8576422535061ca35c759feb6/src/commands/junit/__tests__/upload.test.ts +[12]: /ko/glossary/?product=ci-cd#test-service +[13]: /ko/glossary/?product=ci-cd#test-suite +[14]: /ko/real_user_monitoring/ +[15]: /ko/tests/flaky_test_management/early_flake_detection/ +[16]: /ko/intelligent_test_runner/ +[17]: /ko/tests/code_coverage/ +[18]: https://app.datadoghq.com/ci/test-runs?viz=timeseries \ No newline at end of file diff --git a/content/ko/tracing/guide/ingestion_sampling_use_cases.md b/content/ko/tracing/guide/ingestion_sampling_use_cases.md new file mode 100644 index 0000000000000..ada71f5ce6361 --- /dev/null +++ b/content/ko/tracing/guide/ingestion_sampling_use_cases.md @@ -0,0 +1,161 @@ +--- +further_reading: +- link: /tracing/guide/trace_ingestion_volume_control/ + tag: 지침 + text: 수집된 볼륨을 제어하는 방법 +title: 트레이스 샘플링 사용 사례 +--- + +## 개요 + +트레이스 데이터는 반복적인 경향이 있습니다. 애플리케이션의 문제가 트레이스 한 곳에서만 확인되고 다른 곳에서는 확인되지 않는 경우는 거의 없습니다. 처리량이 많은 서비스, 특히 주의가 필요한 인시던트의 경우, 한 문제가 여러 추적에서 반복적으로 증상을 보이는 경우가 많습니다. 따라서 일반적으로 서비스나 엔드포인트의 모든 트레이스 내의 모든 스팬을 수집할 필요가 없습니다. Datadog APM의 [수집 제어 메커니즘][1]은 문제 해결에 필요한 가시성을 유지하면서 소음을 줄이고 비용을 관리할 수 있도록 도와줍니다. + +수집 메커니즘은 추적 라이브러리의 Datadog Agent 및 Datadog 추적 라이브러리 내에서 구성됩니다. 애플리케이션을 계측하기 위해 OpenTelemetry SDK를 사용하는 경우 [OpenTelemetry를 사용한 수집 샘플링][2]을 참조하세요. + +이 가이드는 주요 사용 사례에 따른 수집 제어 설정 사용 시점과 방법을 이해할 수 있도록 지원합니다. 가이드에서는 다음을 다룹니다. + +- 특정 서비스에 [어떤 수집 메커니즘이 사용되는지 결정하기](#determining-which-ingestion-mechanisms-are-used) +- [특정 유형의 트레이스 유지에 중점을 둔 사용 사례](#keeping-certain-types-of-traces) +- [수집된 트레이스를 줄이는 데 중점을 둔 사용 사례](#reducing-ingestion-for-high-volume-services) + + +## 사용할 수집 메커니즘 결정하기 + +Datadog 환경에서 현재 어떤 수집 메커니즘이 사용되고 있는지 확인하려면 [수집 제어 페이지][3]로 이동하세요. + +{{< img src="/tracing/guide/ingestion_sampling_use_cases/ingestion_control_page.png" alt="Ingestion Control Page" style="width:90%;" >}} + +이 표는 수집된 볼륨에 대한 *서비스별* 인사이트를 제공합니다. 설정 열은 현재 설정에 일차적인 표시를 제공합니다. 다음이 표시됩니다. +- `AUTOMATIC` Datadog Agent에서 계산된 샘플링 속도가 서비스에서 시작되는 추적에 적용되는 경우. 자세한 내용은 [Datadog Agent 수집 로직][5]을 참조하세요. +- `CONFIGURED` 트레이스 라이브러리에서 설정된 사용자 지정 트레이스 샘플링 속도가 서비스에서 시작하는 추적에 적용되는 경우입니다. + +서비스를 클릭하면 각 서비스에 사용되는 샘플링 의사 결정자(예: Agent 또는 트레이스 라이브러리, 규칙 또는 샘플 속도)와 수집된 범위의 서비스에 어떤 [수집 샘플링 메커니즘][1]이 활용되는지에 대한 세부 정보를 확인할 수 있습니다. + +{{< img src="/tracing/guide/ingestion_sampling_use_cases/service-ingestion-summary.png" alt="서비스 수집 요약" style="width:90%;" >}} + +위의 서비스 수집 요약 예시에서 **수집 이유 분석** 표를 보면 이 서비스의 수집 이유 대부분이 `rule`([사용자 정의 샘플링 규칙][6])에서 비롯된 것임을 알 수 있습니다. + +이 서비스의 상위 샘플링 의사 결정권자는 `web-store` 서비스가 `web-store`, `shopist-web-ui`, `shipping-worker`, `synthetics-browser`, `product-recommendation`에서 샘플링 결정을 내리는 것으로 나타났습니다. 이 다섯 가지 서비스는 모두 `web-store` 서비스 범위에 영향을 미치는 전체 샘플링 결정에 기여합니다. 웹 스토어에 수집을 미세 조정하는 방법을 결정할 때는 다섯 가지 서비스를 모두 고려해야 합니다. + +## 특정 유형의 트레이스 유지 + +### 전체 거래 트레이스 유지 + +전체 트랜잭션 추적을 수집하면 특정 개별 요청에 **엔드투엔드 서비스 요청 흐름**에 관한 가시성을 확보할 수 있습니다. + +#### 솔루션: 헤드 기반 샘플링 + +[헤드 기반 샘플링][4] 메커니즘으로 완전한 트레이스를 수집할 수 있습니다. 트레이스를 유지할지 삭제할지 여부는 트레이스가 생성될 때 트레이스 첫 번째 스팬인 *헤드*에서 결정됩니다. 이 결정은 요청 컨텍스트를 통해 다운스트림 서비스로 전파됩니다. + +{{< img src="/tracing/guide/ingestion_sampling_use_cases/head-based-sampling.png" alt="헤드 기반 샘플링" style="width:100%;" >}} + +유지 및 삭제할 트레이스를 결정하기 위해 Datadog Agent에서는 애플리케이션 트래픽을 기반으로 트레이스 생성 시 적용할 각 서비스의 [기본 샘플링 속도][5]를 계산합니다. +- 트래픽이 적은 애플리케이션의 경우 샘플링 속도 100%가 적용됩니다. +- 트래픽이 많은 애플리케이션의 경우, 더 낮은 샘플링 속도가 적용되는데, 각 Agent에서 초당 10개의 완전한 트레이스를 목표로 합니다. + +서비스별 샘플링 속도를 구성하여 기본값 Agent 샘플링 속도를 재정의할 수도 있습니다. 자세한 내용은 [특정 서비스에 더 많은 추적 유지](#keeping-more-traces-for-specific-services-or-resources) 도움말을 참조하세요. + +#### 헤드 기반 샘플링 구성 + +기본 샘플링 속도는 Agent에 따라 초당 10개의 완전한 트레이스를 목표로 계산됩니다. 이는 *목표* 트레이스 수이며 일정 기간의 트레이스를 평균한 결과입니다. 이는 하드 제한이 *아닙니다*. 트래픽이 급증하면 단기간에 Datadog로 훨씬 더 많은 트레이스가 전송될 수 있습니다. + +Datadog Agent 파라미터 `max_traces_per_second` 또는 환경 변수 `DD_APM_MAX_TPS`를 구성하여 이 목표를 늘리거나 줄일 수 있습니다. [헤드 기반 샘플링 수집 메커니즘][5]에서 자세히 알아보세요. + +**참고:** Agent 설정을 변경하면 Datadog Agent에 트레이스를 보고하는 *모든 서비스*의 샘플링 비율에 영향을 미칩니다. + +대부분의 시나리오에서 이 Agent 수준 설정은 할당된 할당량 내에서 애플리케이션 성능에 충분한 가시성을 제공하고 비즈니스에 적합한 의사 결정을 내리는 데 도움이 됩니다. + +### 특정 서비스 또는 리소스에 더 많은 트레이스 유지 + +일부 서비스 및 요청이 비즈니스에 중요한 경우, 이에 관한 가시성을 높이고 싶어 합니다. 모든 관련 추적을 Datadog 으로 보내 개별 트랜잭션을 살펴볼 수 있도록 하세요. + +#### 솔루션: 샘플링 규칙 + +기본적으로 샘플링 속도는 Datadog Agent당 초당 10개의 트레이스를 목표로 계산됩니다. 추적 라이브러리에서 [샘플링 규칙][6]을 구성하여 기본 계산된 샘플링 속도를 재정의할 수 있습니다. + +서비스별로 샘플링 규칙을 설정할 수 있습니다. 규칙의 특정 서비스에서 시작하는 트레이스의 경우 Agent의 기본 샘플링 속도 대신 정의된 백분율 샘플링 속도가 적용됩니다. + +#### 샘플링 규칙 설정하기 + +환경 변수 `DD_TRACE_SAMPLING_RULES`를 설정하여 샘플링 규칙을 구성할 수 있습니다. + +예를 들어 서비스 `my-service` 에 관해 트레이스의 20%를 보내는 방법: + +``` +DD_TRACE_SAMPLING_RULES='[{"service": "my-service", "sample_rate": 0.2}]' +``` + +[샘플링 규칙 수집 메커니즘][6]에 관해 자세히 알아보세요. + +### 오류 관련 트레이스 더 많이 유지 + +오류 스팬이 있는 트레이스는 시스템 장애 증상인 경우가 많습니다. 오류가 있는 트랜잭션의 비율을 높게 유지하면 항상 관련 개별 요청에 액세스할 수 있습니다. + +#### 솔루션: 오류 샘플링 속도 + +헤드 기반 샘플링된 트레이스 외에도 오류 샘플링 속도를 높여 각 Agent가 관련 트레이스가 헤드 기반 샘플링으로 유지되지 않더라도 추가 오류 스팬을 유지할 수 있도록 합니다. + +{{< img src="/tracing/guide/ingestion_sampling_use_cases/error-spans-sampling.png" alt="Error Sampling" style="width:100%;" >}} + +**참조**: +- 샘플링이 Datadog Agent 수준에서 로컬로 이루어지므로 분산된 트레이스 조각은 수집되지 않을 수 있습니다. +- **Datadog Agent 6/7.41.0 이상**부터 `DD_APM_FEATURES=error_rare_sample_tracer_drop`은 트레이스 라이브러리 규칙 또는 `manual.drop`에 의해 삭제된 스팬을 포함하도록 설정할 수 있습니다. 자세한 내용은 [수집 메커니즘 설명서의 오류 추적 섹션][9]에서 확인할 수 있습니다. + +#### 오류 샘플링 구성 + +환경 변수 `DD_APM_ERROR_TPS`를 구성하여 캡처할 Agent당 초당 오류 조각 수를 구성할 수 있습니다. 기본값은 초당 `10` 오류 수입니다. **모든 오류**를 수집하려면 임의의 높은 값으로 설정하세요. 오류 샘플링을 사용하지 않으려면 `DD_APM_ERROR_TPS`를 `0`로 설정합니다. + +## 대용량 서비스의 수집량 줄이기 + +### 데이터베이스 또는 캐시 서비스에서 볼륨 줄이기 + +추적되는 데이터베이스 호출의 경우 수집 데이터 양이 대량일 수 있습니다. 그러나 애플리케이션 성능 메트릭(예: 오류 수, 요청 히트 수, 지연 시간)은 데이터베이스 상태를 확인할 수 있는 정도입니다. + +#### 솔루션: 데이터베이스 호출을 사용한 트레이스 샘플링 규칙 + +데이터베이스 호출을 추적하여 생성된 스팬 볼륨을 줄이려면 트레이스의 헤드에서 샘플링을 설정합니다. + +데이터베이스 서비스는 트레이스를 시작하는 일이 거의 없습니다. 일반적으로 클라이언트 데이터베이스 범위는 계측된 백엔드 서비스 스팬의 하위 서비스입니다. + +**데이터베이스 트레이스를 시작하는 서비스**를 파악하려면, 수집 제어 페이지 [서비스 수집 요약][7]의 `Top Sampling Decision Makers` 상위 목록 그래프를 사용하세요. 이러한 특정 서비스에 헤드 기반 샘플링을 설정하면 수집되는 데이터베이스 스팬의 양을 줄이면서 불완전한 트레이스가 수집되지 않도록 할 수 있습니다. 분산된 트레이스는 유지되거나 모두 삭제됩니다. + +{{< img src="/tracing/guide/ingestion_sampling_use_cases/service-ingestion-summary-database.png" alt="상위 샘플링 의사 결정자" style="width:90%;" >}} + +예를 들어, 추적 중인 `web-store-mongo` 데이터베이스 호출의 경우, 트레이스의 99%가 `web-store` 및 `shipping-worker` 서비스에서 시작됩니다. 따라서 `web-store-mongo`의 볼륨을 줄이려면 `web-store` 및 `shipping-worker` 서비스의 샘플링을 설정합니다. + +#### 데이터베이스 스팬을 삭제하도록 샘플링 설정 + +샘플링 규칙 구문에 관한 자세한 내용은 [샘플링 규칙 설정 섹션](#configuring-a-sampling-rule)을 참조하세요. + +백엔드 서비스 `web-store`는 트레이스당 여러 번 Mongo 데이터베이스를 호출하며, 원치 않는 스팬 볼륨을 많이 생성하고 있습니다. + +- 백엔드 서비스 `web-store`에 **트레이스 샘플링 규칙**을 설정하여 Mongo 스팬을 포함하여 전체 트레이스의 10%가 유지되도록 합니다. + + ``` + DD_TRACE_SAMPLING_RULES='[{"service": "web-store", "sample_rate": 0.1}]' + ``` + +- 선택적으로 모든 `web-store` 스팬을 유지하려면 백엔드 서비스 `web-store`에 스팬의 100%를 유지하도록 **단일 스팬 샘플링 규칙**을 설정합니다. 이 샘플링은 위에서 파악한 10% 이외의 데이터베이스 호출 스팬을 수집하지 않습니다. + + ``` + DD_SPAN_SAMPLING_RULES='[{"service": "web-store", "sample_rate": 1}]' + ``` + + **참고**: 단일 스팬 샘플링 규칙을 설정하는 것은 수집된 스팬에서 파생된 [스팬 기반 메트릭][8]을 사용하는 경우에 특히 유용합니다. + +{{< img src="/tracing/guide/ingestion_sampling_use_cases/single-span-sampling3.png" alt="데이터베이스 스팬 샘플링" style="width:100%;" >}} + + +## 참고 자료 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ko/tracing/trace_pipeline/ingestion_mechanisms/ +[2]: /ko/opentelemetry/guide/ingestion_sampling_with_opentelemetry/ +[3]: https://app.datadoghq.com/apm/traces/ingestion-control +[4]: /ko/tracing/trace_pipeline/ingestion_mechanisms/#head-based-sampling +[5]: /ko/tracing/trace_pipeline/ingestion_mechanisms/#in-the-agent +[6]: /ko/tracing/trace_pipeline/ingestion_mechanisms/#in-tracing-libraries-user-defined-rules +[7]: /ko/tracing/trace_pipeline/ingestion_controls/#service-ingestion-summary +[8]: /ko/tracing/trace_pipeline/generate_metrics/ +[9]: /ko/tracing/trace_pipeline/ingestion_mechanisms/?tab=java#error-and-rare-traces \ No newline at end of file diff --git a/content/ko/tracing/guide/tutorial-enable-java-aws-eks.md b/content/ko/tracing/guide/tutorial-enable-java-aws-eks.md new file mode 100644 index 0000000000000..d28e8a5d6abdc --- /dev/null +++ b/content/ko/tracing/guide/tutorial-enable-java-aws-eks.md @@ -0,0 +1,451 @@ +--- +further_reading: +- link: /tracing/trace_collection/library_config/java/ + tag: 설명서 + text: 추가 추적 라이브러리 설정 옵션 +- link: /tracing/trace_collection/dd_libraries/java/ + tag: 설명서 + text: 상세한 추적 라이브러리 설정 지침 +- link: /tracing/trace_collection/compatibility/java/ + tag: 설명서 + text: 자동 계측을 위해 지원되는 자바(Java) 프레임워크 +- link: /tracing/trace_collection/custom_instrumentation/java/ + tag: 설명서 + text: 수동으로 트레이스와 스팬 설정하기 +- link: https://github.com/DataDog/dd-trace-java + tag: 소스 코드 + text: 추적 라이브러리 오픈 소스 리포지토리 +title: 튜토리얼 - AWS Elastic Kubernetes 서비스에서 Java 애플리케이션에 추적 활성화하기 +--- + +## 개요 + +이 튜토리얼에서는 AWS EKS(Elastic Kubernetes) 서비스의 클러스터에 설치된 샘플 자바 애플리케이션에서 추적을 활성화하는 단계를 안내합니다. 이 시나리오에서는 Datadog Agent가 클러스터에 설치되어 있습니다. + +호스트, 컨테이너, 클라우드, 기타 인프라스트럭처, 다른 언어로 작성된 애플리케이션 등 다른 시나리오의 경우 기타 [추적 활성화 튜토리얼][1]을 참조하세요. + +자바(Java)에 대한 일반적인 종합 추적 설정 설명서의 경우 [자바 애플리케이션 추적][2]을 참조하세요. + +### 사전 필수 조건 + +- Datadog 계정과 [조직 API 키][3] +- Git +- Kubectl +- eksctl +- Helm - 다음 명령을 실행하여 설치합니다. + {{< code-block lang="sh" >}} +curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 +chmod 700 get_helm.sh +./get_helm.sh{{< /code-block >}} + 다음 명령을 실행하여 Helm를 설정합니다. + {{< code-block lang="sh" >}} +helm repo add datadog-crds https://helm.datadoghq.com +helm repo add kube-state-metrics https://prometheus-community.github.io/helm-charts +helm repo add datadog https://helm.datadoghq.com +helm repo update{{< /code-block >}} + +## 샘플 Kubernetes Java 애플리케이션 설치 + +이 튜토리얼의 코드 샘플은 GitHub의 [github.com/DataDog/apm-tutorial-java-host][9]에서 찾을 수 있습니다. 시작하려면 리포지토리를 복제합니다. + +{{< code-block lang="sh" >}} +git clone https://github.com/DataDog/apm-tutorial-java-host.git +{{< /code-block >}} + +리포지토리에는 Kubernetes 클러스터 내에서 실행되도록 미리 설정된 다중 서비스 Java 애플리케이션이 포함되어 있습니다. 본 샘플 앱은 REST API를 갖춘 기본 노트 앱으로 데이터를 추가 및 변경합니다. Kubernetes 파드(pod) 컨테이너를 만드는 데 필요한 `docker-compose` YAML 파일은 `docker` 디렉토리에 있습니다. 이 튜토리얼에서는 애플리케이션의 컨테이너를 빌드하는 `service-docker-compose-k8s.yaml` 파일을 사용합니다. + +`notes` 및 `calendar` 디렉토리에는 Maven 또는 Gradle로 애플리케이션을 빌드하는 두 세트의 Dockerfile이 있습니다. 이 튜토리얼에서는 Maven 빌드를 사용하지만, Gradle에 더 익숙하다면 해당 빌드 명령의 변경 사항을 사용하여 Maven 빌드를 사용할 수 있습니다. + +`notes` 앱용 Kubernetes 설정 파일, `calendar` 앱, Datadog Agent 파일은 `Kubernetes` 디렉토리에 있습니다. + +샘플 애플리케이션을 가져오는 프로세스에는 `docker` 폴더에서 이미지를 빌드하고, 이를 레지스트리에 업로드한 다음, `kubernetes` 폴더에서 Kubernetes 리소스를 생성하는 작업이 포함됩니다. + +### 클러스터 시작하기 + +재사용하려는 EKS 클러스터가 아직 없는 경우 다음 명령을 실행하여 ``을 사용하려는 이름으로 바꾸어 클러스터를 만듭니다. + +{{< code-block lang="sh" >}} +eksctl create cluster --name {{< /code-block >}} + +이렇게 하면 포드를 배포할 수 있는 관리형 노드 그룹이 있는 EKS 클러스터가 생성됩니다. 문제 해결 및 설정에 관한 자세한 내용은 [클러스터 생성과 관련한 eksctl 설명서][16]를 참조하세요. 다른 방법(예: AWS 웹 콘솔)으로 생성한 클러스터를 사용하는 경우, eksctl 설명서에 설명된 대로 클러스터가 로컬 `kubeconfig` 파일에 연결되어 있는지 확인합니다. + +클러스터를 만드는 데 15~20분 정도 걸릴 수 있습니다. 클러스터 생성이 완료될 때까지 기다리는 동안 다른 단계를 계속 진행하세요. + +### 애플리케이션 이미지 빌드 및 업로드 + +EKS 이미지용 레지스트리인 Amazon ECR에 익숙하지 않다면 [AWS CLI로 Amazon ECR 사용하기][17]를 읽어보는 것이 도움이 될 수 있습니다. + +샘플 프로젝트 `/docker` 디렉토리에서 다음 명령을 실행합니다. + +1. 다음 명령에 사용자 이름과 비밀번호를 입력하여 ECR에 인증합니다. + {{< code-block lang="sh" >}} +aws ecr get-login-password --region us-east-1 | docker login --username --password-stdin {{< /code-block >}} + +2. 샘플 앱에 대한 Docker 이미지를 빌드하고 플랫폼 설정을 사용자 설정에 맞게 조정합니다. + {{< code-block lang="sh" >}} +DOCKER_DEFAULT_PLATFORM=linux/amd64 docker-compose -f service-docker-compose-k8s.yaml build notes{{< /code-block >}} + +3. 컨테이너에 ECR 대상 태그를 지정합니다. + {{< code-block lang="sh" >}} +docker tag docker-notes:latest :notes{{< /code-block >}} + +4. 컨테이너를 ECR 레지스트리에 업로드합니다. + {{< code-block lang="sh" >}} +docker push :notes{{< /code-block >}} + +애플리케이션은 컨테이너화되어 있으며 EKS 클러스터에서 가져올 수 있습니다. + +### AWS 클러스터 인바운드 보안 정책 업데이트 + +샘플 애플리케이션과 통신하려면 포트 `30080` 및 `30090`가 열려 있는 상태에서 클러스터의 보안 규칙이 설정되어 있는지 확인하세요. + +1. AWS 콘솔을 열고 EKS 서비스 내에서 배포된 클러스터로 이동합니다. + +2. 클러스터 콘솔에서 네트워킹 탭을 선택하고 클러스터 보안 그룹을 클릭합니다. + +3. 보안 그룹 설정에서 인바운드 규칙을 편집합니다. 사용자 지정 TCP 트래픽을 허용하는 규칙을 추가합니다. 이때 포트 범위는 `30060`~`30100`로 설정하고 `0.0.0.0/0`을 소스로 추가합니다. + +4. 규칙을 저장합니다. + +### 로컬에서 애플리케이션을 설정하고 배포 + +1. `kubernetes/notes-app.yaml`을 열고 위에서 컨테이너를 푸시한 ECR 이미지의 URL을 사용하여 `image` 항목을 업데이트합니다. + {{< code-block lang="yaml" >}} + spec: + containers: + - name: notes-app + image: :notes + imagePullPolicy: Always +{{< /code-block >}} + +2. `/Kubernetes` 디렉토리에서 다음 명령을 실행하여 `notes` 앱을 배포합니다. + {{< code-block lang="sh" >}} +kubectl create -f notes-app.yaml{{< /code-block >}} + +3. 앱을 실행하려면 REST API를 호출할 외부 IP 주소를 찾아야 합니다. 먼저 다음 명령으로 출력되는 목록에서 `notes-app-deploy` 파드를 찾아 해당 노드를 기록합니다. + + {{< code-block lang="sh" >}} +kubectl get pods -o wide{{< /code-block >}} + + {{< img src="tracing/guide/tutorials/tutorial-java-eks-pods.png" alt="notes-app-deploy 파드와 연결된 노드 이름을 표시하는 kubectle 명령 출력" style="width:100%;" >}} + + 다음 명령의 출력에서 해당 노드 이름을 찾아 외부 IP 값을 확인합니다. + + {{< code-block lang="sh" >}} +kubectl get nodes -o wide{{< /code-block >}} + + {{< img src="tracing/guide/tutorials/tutorial-java-eks-external-ip.png" alt="노드의 외부 IP 값을 표시하는 kubectl 명령 출력" style="width:100%;" >}} + + 표시된 예제에서 `notes-app`은 외부 IP가 `34.230.7.210`인 노드 `ip-192-189-63-129.ec2.internal`에서 실행 중입니다. + +3. 다른 터미널을 열고 앱을 실행하기 위한 API 요청을 보냅니다. 노트 애플리케이션은 데이터를 동일한 컨테이너에서 실행 중인 인메모리 H2 데이터베이스에 저장하는 REST API입니다. 다음과 같이 몇 가지 명령을 보내세요. + +`curl ':30080/notes'` +: `[]` + +`curl -X POST ':30080/notes?desc=hello'` +: `{"id":1,"description":"hello"}` + +`curl ':30080/notes?id=1'` +: `{"id":1,"description":"hello"}` + +`curl ':30080/notes'` +: `[{"id":1,"description":"hello"}]` + +4. 애플리케이션 실행을 확인한 후 추적을 활성화할 수 있도록 중단합니다. + {{< code-block lang="sh" >}} +kubectl delete -f notes-app.yaml{{< /code-block >}} + +## 추적 활성화 + +이제 Java 애플리케이션이 작동하므로 추적을 활성화하도록 구성하면 됩니다. + +1. 프로젝트에 자바 추적 패키지를 추가합니다. Agent는 EKS 클러스터에서 실행되므로 Dockerfile이 제대로 설정되었는지 확인합니다. 아무것도 설치할 필요가 없습니다. `notes/dockerfile.notes.maven` 파일을 열고 `dd-java-agent`를 다운로드하는 줄의 주석 처리를 해제합니다. + + ``` + RUN curl -Lo dd-java-agent.jar 'https://dtdg.co/latest-java-tracer' + ``` + +2. 같은 `notes/dockerfile.notes.maven` 파일 내에서 추적 없이 실행할 `ENTRYPOINT` 줄을 주석 처리합니다. 그런 다음 추적 기능을 활성화하여 애플리케이션을 실행하는 `ENTRYPOINT` 줄의 주석 처리를 제거합니다. + + ``` + ENTRYPOINT ["java" , "-javaagent:../dd-java-agent.jar", "-Ddd.trace.sample.rate=1", "-jar" , "target/notes-0.0.1-SNAPSHOT.jar"] + ``` + + 자동으로 Datadog 서비스를 포함하는 애플리케이션을 계측합니다. + +
참고: 이 샘플 명령의 플래그, 특히 샘플 속도는 이 튜토리얼이 적용되지 않은 환경에는 적합하지 않을 수 있습니다. 실제 환경에서 어떤 플래그를 사용해야 하는지에 대해 살펴보려면 추적 설정을 참고하세요.
+ +3. [Universal Service Tags][10]는 다양한 버전 및 배포 환경에서 추적된 서비스를 식별하여 Datadog 내에서 상관 관계를 분석하고 검색 및 필터링에 사용할 수 있도록 합니다. Unified Service Tagging에 사용되는 세 가지 환경 변수는 `DD_SERVICE`, `DD_ENV`, `DD_VERSION`입니다. Kubernetes로 배포된 애플리케이션의 경우, 이러한 환경 변수는 배포 YAML 파일 내, 특히 배포 오브젝트, 파드(Pod) 사양, 파드(Pod) 컨테이너 템플릿에 추가할 수 있습니다. + + 이 튜토리얼의 경우, `Kubernetes/notes-app.yaml` 파일에는 이미 배포 오브젝트, 포드(Pod) 사양 및 포드(Pod) 컨테이너 템플릿에 대한 노트 애플리케이션 환경 변수가 정의되어 있습니다. 다음은 그 예시입니다. + + ```yaml + ... + spec: + replicas: 1 + selector: + matchLabels: + name: notes-app-pod + app: java-tutorial-app + template: + metadata: + name: notes-app-pod + labels: + name: notes-app-pod + app: java-tutorial-app + tags.datadoghq.com/env: "dev" + tags.datadoghq.com/service: "notes" + tags.datadoghq.com/version: "0.0.1" + ... + ``` + +### 애플리케이션 이미지를 다시 빌드한 후 업로드 + +이전과 동일한 단계](#build-and-upload-the-application-image)를 사용하여 추적을 활성화한 상태로 이미지를 다시 빌드합니다. +{{< code-block lang="sh" >}} +aws ecr get-login-password --region us-east-1 | docker login --username --password-stdin +DOCKER_DEFAULT_PLATFORM=linux/amd64 docker-compose -f service-docker-compose-k8s.yaml build notes +docker tag docker-notes:latest :notes +docker push :notes{{< /code-block >}} + +추적이 활성화된 애플리케이션은 컨테이너화되어 EKS 클러스터에서 가져올 수 있습니다. + +## Helm으로 Agent 설치 및 실행 + +그런 다음 Agent를 EKS에 배포하여 계측된 애플리케이션에서 트레이스 데이터를 수집합니다. + +1. `Kubernetes/Datadog-values.yaml`을 열어 GKE에서 Agent 및 APM에 필요한 최소 설정을 확인합니다. 이 설정 파일은 다음에 실행하는 명령에 사용됩니다. + +2. `/Kubernetes` 디렉토리에서 API 키와 클러스터 이름을 입력하여 다음 명령을 실행합니다. + {{< code-block lang="sh" >}} +helm upgrade -f datadog-values.yaml --install --debug latest --set datadog.apiKey= --set datadog.clusterName= --set datadog.site=datadoghq.com datadog/datadog{{< /code-block >}} + + API 키를 노출하지 않는 보다 안전한 배포에 대해서는 [시크릿 사용에 대한 본 지침][18]를 참조하세요. 아울러, `us1` 외의 [Datadog 사이트][6]를 사용하는 경우 `datadoghq.com`를 해당 사이트로 변경하세요. + +## 앱을 시작해 자동 추적을 확인합니다. + +[이전과 동일한 단계](#configure-the-application-locally-and-deploy)에 따라 `notes` 앱을 `kubectl create -f notes-app.yaml`을 통해 배포하고 해당 앱이 실행되는 노드의 외부 IP 주소를 확인합니다. + +몇 가지 Curl 명령을 실행하여 앱을 실행합니다. + +`curl ':30080/notes'` +: `[]` + +`curl -X POST ':30080/notes?desc=hello'` +: `{"id":1,"description":"hello"}` + +`curl ':30080/notes?id=1'` +: `{"id":1,"description":"hello"}` + +`curl ':30080/notes'` +: `[{"id":1,"description":"hello"}]` + + +잠시 기다린 다음 Datadog에서 [**APM > 트레이스**][11]로 이동합니다. API 호출과 대응되는 트레이스 목록을 확인할 수 있습니다. + +{{< img src="tracing/guide/tutorials/tutorial-java-container-traces2.png" alt="APM Trace Explore 샘플 앱에서의 트레이스" style="width:100%;" >}} + +`h2`는 이 튜토리얼에 대해 내장된 인메모리 데이터베이스이며, `notes`는 Spring Boot 애플리케이션입니다. 추적 목록에는 모든 스팬, 시작 시점, 스팬과 함께 추적된 리소스, 그리고 소요 시간이 표시됩니다. + +몇 분이 지난 후에도 트레이스를 확인할 수 없다면 트레이스 검색 필드에서 모든 필터를 해제합니다. 때론 사용하지 않는 `ENV` 등 환경 변수에 대해 필터링되었을 수 있습니다. + +### 트레이스 검사 + +트레이스 페이지에서 `POST /notes` 트레이스를 클릭해 각 스팬에 걸리는 시간 및 스팬 완료 전 발생한 다른 스팬을 나타내는 플레임(Flame) 그래프를 확인할 수 있습니다. 그래프 상단의 막대는 이전 화면에서 선택한 스팬입니다. (이 경우 메모 애플리케이션의 최초 엔트리 포인트입니다.) + +바의 너비는 완료되는 데 소요된 시간을 나타냅니다. 낮은 깊이의 막대는 높은 깊이의 막대 수명 동안 완료된 스팬을 나타냅니다. + +`POST` 트레이스의 불꽃 그래프는 이와 비슷한 형태입니다. + +{{< img src="tracing/guide/tutorials/tutorial-java-container-post-flame.png" alt="POST 트레이스의 플레임 그레프." style="width:100%;" >}} + +`GET /notes` 트레이스는 이와 비슷한 형태입니다. + +{{< img src="tracing/guide/tutorials/tutorial-java-container-get-flame.png" alt="GET 트레이스의 플레임 그래프." style="width:100%;" >}} + +### 추적 설정 + +Java 추적 라이브러리는 Java에 내장된 Agent 및 모니터링 지원을 사용합니다. Dockerfile의 플래그 `-javaagent:../dd-java-agent.jar`는 JVM에 Java 추적 라이브러리의 위치를 ​​알려 Java Agent로 실행할 수 있도록 합니다. Java Agent에 대한 자세한 내용은 [https://www.baeldung.com/java-instrumentation][7]에서 확인하세요. + +`dd.trace.sample.rate` 플래그는 이 애플리케이션의 샘플링 속도를 설정합니다. Dockerfile의 ENTRYPOINT 명령은 값을 `1`로 설정합니다. 즉, `notes` 서비스의 모든 요청 100%가 분석 및 표시를 위해 Datadog 백엔드로 전송됩니다. 저용량 테스트 애플리케이션에는 적합하나 프로덕션 환경이나 고용량 환경에서는 데이터 양이 매우 많아질 수 있어 권장하지 않습니다. 대신 일부 요청을 샘플링할 수 있습니다. 0에서 1 사이의 값을 선택하세요. 예를 들어, `-Ddd.trace.sample.rate=0.1`는 요청의 10%에 대한 트레이스를 Datadog으로 전송합니다. 관련 정보는 [추적 구성 설정][14] 및 [샘플링 메커니즘][15]에서 자세히 살펴보세요. + +명령에서 샘플링 속도 플래그가 `-jar` 플래그 _앞에_ 나타나는 것을 확인할 수 있습니다. 이는 이 플래그가 애플리케이션이 아닌 Java Virtual Machine의 파라미터이기 때문입니다. 애플리케이션에 Java Agent를 추가할 때 플래그를 올바른 위치에 지정해야 합니다. + +## Java 애플리케이션에 수동 계측 추가 + +자동 계측은 편리하지만 때때로 더욱 세분화된 스팬을 원할 수 있습니다. Datadog의 Java DD 트레이스 API를 사용하면 주석이나 코드로 코드 내 스팬을 지정할 수 있습니다. + +다음 단계에서는 빌드 스크립트를 수정하여 Java 추적 라이브러리를 다운로드하고, 코드에 몇 가지 주석을 추가하여 몇 가지 샘플 메서드를 추적하는 방법을 알아봅니다. + +1. 현재 애플리케이션 배포를 삭제합니다. + {{< code-block lang="sh" >}} +kubectl delete -f notes-app.yaml{{< /code-block >}} + +2. `/notes/src/main/java/com/datadog/example/notes/NotesHelper.java`를 엽니다. 이 예제에는 주석 처리된 코드가 포함되어 있으며, 코드에서 커스텀 추적을 설정하는 다양한 방법을 보여줍니다. + +3. 수동 추적을 지원하기 위해 라이브러리를 가져오는 줄의 주석 처리를 제거합니다. + + ```java + import datadog.trace.api.Trace; + import datadog.trace.api.DDTags; + import io.opentracing.Scope; + import io.opentracing.Span; + import io.opentracing.Tracer; + import io.opentracing.tag.Tags; + import io.opentracing.util.GlobalTracer; + import java.io.PrintWriter; + import java.io.StringWriter + ``` + +4. 두 개의 공개 프로세스를 수동으로 추적하는 줄의 주석 처리를 제거합니다. 이는 트레이스에서 `@Trace` 어노테이션을 사용하여 `operationName` 및 `resourceName`을 지정하는 방법을 보여줍니다. + ```java + @Trace(operationName = "traceMethod1", resourceName = "NotesHelper.doLongRunningProcess") + // ... + @Trace(operationName = "traceMethod2", resourceName = "NotesHelper.anotherProcess") + ``` + +5. 애플리케이션의 특정 코드 블록에 대해 별도의 스팬을 생성할 수도 있습니다. 스팬 내에 서비스 및 리소스 이름 태그와 오류 처리 태그를 추가합니다. 이러한 태그를 추가하면 Datadog 시각화에서 스팬과 메트릭을 보여주는 플레임 그래프가 생성됩니다. 프라이빗 메서드를 수동으로 추적하는 줄의 주석 처리를 제거합니다. + + ```java + Tracer tracer = GlobalTracer.get(); + // Tags can be set when creating the span + Span span = tracer.buildSpan("manualSpan1") + .withTag(DDTags.SERVICE_NAME, "NotesHelper") + .withTag(DDTags.RESOURCE_NAME, "privateMethod1") + .start(); + try (Scope scope = tracer.activateSpan(span)) { + // Tags can also be set after creation + span.setTag("postCreationTag", 1); + Thread.sleep(30); + Log.info("Hello from the custom privateMethod1"); + ``` + 그리고 오류에 태그를 설정하는 줄도 있습니다. + ```java + } catch (Exception e) { + // Set error on span + span.setTag(Tags.ERROR, true); + span.setTag(DDTags.ERROR_MSG, e.getMessage()); + span.setTag(DDTags.ERROR_TYPE, e.getClass().getName()); + + final StringWriter errorString = new StringWriter(); + e.printStackTrace(new PrintWriter(errorString)); + span.setTag(DDTags.ERROR_STACK, errorString.toString()); + Log.info(errorString.toString()); + } finally { + span.finish(); + } + ``` + +6. 수동 추적을 위한 종속성을 구성하는 `notes/pom.xml` 줄을 열고 주석 처리를 제거하여 Maven 빌드를 업데이트하세요. `dd-trace-api` 라이브러리는 `@Trace` 어노테이션에 사용되고, `opentracing-util` 와 `opentracing-api`는 수동 스팬 생성에 사용됩니다. + +7. 애플리케이션을 다시 빌드하고 다음 명령을 실행하여 [이전과 동일한 단계](#build-and-upload-the-application-image)에 따라 ECR에 업로드합니다. + + {{< code-block lang="sh" >}} +aws ecr get-login-password --region us-east-1 | docker login --username --password-stdin +DOCKER_DEFAULT_PLATFORM=linux/amd64 docker-compose -f service-docker-compose-k8s.yaml build notes +docker tag docker-notes:latest :notes +docker push :notes +{{< /code-block >}} + +8. [이전과 동일한 단계](#configure-the-application-locally-and-deploy)에 따라 `notes` 앱을 `kubectl create -f notes-app.yaml`을 통해 배포하고 해당 앱이 실행되는 노드의 외부 IP 주소를 확인합니다. + +9. 일부 HTTP 요청, 특히 `GET` 요청을 다시 전송합니다. +10. 트레이스 탐색기에서 새로운 `GET` 요청 중 하나를 클릭한 다음 이와 같은 불꽃 그래프를 확인하세요. + + {{< img src="tracing/guide/tutorials/tutorial-java-container-custom-flame.png" alt="커스텀 계측이 포함된 GET 추적에 대한 플레임 그래프." style="width:100%;" >}} + + `getAll` 함수가 커스텀 추적을 포함하므로 스택 트레이스(stack trace)에서 상위 수준의 상세 정보를 확인할 수 있습니다. + + 수동 스팬(span)을 생성한 `privateMethod`는 다른 호출과 별도의 블록으로 표시되며 다른 색상으로 강조 표시됩니다.`@Trace` 어노테이션을 사용한 다른 메서드는 `GET` 요청(`notes` 애플리케이션)과 동일한 서비스와 색상으로 표시됩니다. 커스텀 계측은 코드의 핵심 부분을 강조 표시하고 모니터링해야 할 때 유용합니다. + +자세한 정보는 [커스텀 계측][12]을 참조하세요. + +## 두 번째 애플리케이션을 추가해 분산된 트레이스를 확인하세요. + +단일 애플리케이션 추적은 좋은 시작이지만 추적의 진정한 가치는 서비스를 통한 요청의 흐름을 확인하는 데 있습니다. 이것을 _분산 추적_이라고 부릅니다. + +샘플 프로젝트에 `calendar`라는 두 번째 애플리케이션이 포함되어 있습니다. 이 애플리케이션은 호출 시 임의의 날짜를 반환합니다. 메모 애플리케이션의 `POST` 엔드포인트는 `add_date`라는 두 번째 쿼리 파라미터를 포함합니다. `y`로 설정되어 있는 경우 메모는 캘린더 애플리케이션을 호출하여 메모에 추가할 날짜를 가져옵니다. + +1. 이전에 메모 앱에서 했던 작업과 마찬가지로, `dd-java-agent`을 Dockerfile의 시작 명령에 추가하여 캘린더 앱을 설정합니다. `calendar/dockerfile.calendar.maven`를 열고 `dd-java-agent`를 다운로드하는지 확인합니다. + + ``` + RUN curl -Lo dd-java-agent.jar 'https://dtdg.co/latest-java-tracer' + ``` + +2. 같은 `calendar/dockerfile.calendar.maven` 파일 내에서 추적 없이 실행할 `ENTRYPOINT` 줄을 주석 처리합니다. 그런 다음 추적 기능을 활성화하여 애플리케이션을 실행하는 `ENTRYPOINT` 줄의 주석 처리를 제거합니다. + + ``` + ENTRYPOINT ["java" , "-javaagent:../dd-java-agent.jar", "-Ddd.trace.sample.rate=1", "-jar" , "target/calendar-0.0.1-SNAPSHOT.jar"] + ``` + +
참고: 이 플래그, 특히 샘플 속도는 이 튜토리얼이 적용되지 않은 환경에는 적합하지 않을 수 있음을 다시 강조합니다. 실제 환경에서 어떤 플래그를 사용해야 하는지에 살펴보려면 추적 설정을 참고하세요.
+ +3. 두 애플리케이션을 모두 빌드하고 ECR에 게시합니다. `docker` 디렉터리에서 실행합니다. + {{< code-block lang="sh" >}} +aws ecr get-login-password --region us-east-1 | docker login --username --password-stdin +DOCKER_DEFAULT_PLATFORM=linux/amd64 docker-compose -f service-docker-compose-k8s.yaml build calendar +docker tag docker-calendar:latest :calendar +docker push :calendar +{{< /code-block >}} + +4. `kubernetes/calendar-app.yaml`을 열고 이전 단계에서 `calendar` 앱을 푸시한 ECR 이미지의 URL을 사용해 `image` 항목을 업데이트합니다. + {{< code-block lang="yaml" >}} + spec: + containers: + - name: calendar-app + image: :calendar + imagePullPolicy: Always +{{< /code-block >}} + +5. 이제 커스텀 계측 기능이 포함된 `notes` 및 `calendar` 앱을 모두 클러스터에 배포합니다. + {{< code-block lang="sh" >}} +kubectl create -f notes-app.yaml +kubectl create -f calendar-app.yaml{{< /code-block >}} + +6. 이전에 사용한 방법로 `notes` 앱의 외부 IP를 찾습니다. + +7. `add_date` 파라미터를 사용하여 POST 요청을 보냅니다. + +`curl -X POST ':30080/notes?desc=hello_again&add_date=y'` +: `{"id":1,"description":"hello_again with date 2022-11-06"}` + +8. 트레이스 탐색기에서 다음 최신 트레이스를 클릭하여 두 서비스 간의 분산 트레이스를 확인하세요. + + {{< img src="tracing/guide/tutorials/tutorial-java-container-distributed.png" alt="분산 추적을 보여주는 플레임 그래프" style="width:100%;" >}} + + `notes` 애플리케이션에서는 아무것도 변경하지 않았습니다. Datadog은 `notes`에서 `calendar`로의 HTTP 호출에 사용되는 `okHttp`라이브러리와 `notes` 및 `calendar`에서 HTTP 요청을 수신하는 데 사용되는 Jetty 라이브러리를 모두 자동으로 계측합니다. 이를 통해 트레이스 정보를 한 애플리케이션에서 다른 애플리케이션으로 전달하여 분산 트레이스를 캡처할 수 있습니다. + +9. 탐색이 끝나면 모든 리소스를 정리하고 배포를 삭제하세요. + {{< code-block lang="sh" >}} +kubectl delete -f notes-app.yaml +kubectl delete -f calendar-app.yaml{{< /code-block >}} + + 클러스터 삭제와 관련된 자세한 내용은 [EKS 설명서][19]를 참조하세요. + +## 트러블슈팅 + +예상대로 트레이스를 수신하지 않으면 Java 트레이서의 디버그 모드를 설정합니다. 자세한 내용은 [디버그 모드 활성화][13]에서 확인하세요. + +## 참고 자료 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ko/tracing/guide/#enabling-tracing-tutorials +[2]: /ko/tracing/trace_collection/dd_libraries/java/ +[3]: /ko/account_management/api-app-keys/ +[4]: /ko/tracing/trace_collection/compatibility/java/ +[6]: /ko/getting_started/site/ +[8]: https://app.datadoghq.com/event/explorer +[7]: https://www.baeldung.com/java-instrumentation +[9]: https://github.com/DataDog/apm-tutorial-java-host +[10]: /ko/getting_started/tagging/unified_service_tagging/ +[11]: https://app.datadoghq.com/apm/traces +[12]: /ko/tracing/trace_collection/custom_instrumentation/java/ +[13]: /ko/tracing/troubleshooting/tracer_debug_logs/#enable-debug-mode +[14]: /ko/tracing/trace_collection/library_config/java/ +[15]: /ko/tracing/trace_pipeline/ingestion_mechanisms/?tab=java +[16]: https://eksctl.io/usage/creating-and-managing-clusters/ +[17]: https://docs.aws.amazon.com/AmazonECR/latest/userguide/getting-started-cli.html +[18]: https://github.com/DataDog/helm-charts/blob/main/charts/datadog/README.md#create-and-provide-a-secret-that-contains-your-datadog-api-and-app-keys +[19]: https://docs.aws.amazon.com/eks/latest/userguide/delete-cluster.html \ No newline at end of file diff --git a/content/ko/tracing/legacy_app_analytics/_index.md b/content/ko/tracing/legacy_app_analytics/_index.md index 0ba09502a1857..8897ab2dc0e71 100644 --- a/content/ko/tracing/legacy_app_analytics/_index.md +++ b/content/ko/tracing/legacy_app_analytics/_index.md @@ -35,7 +35,7 @@ title: 애플리케이션 분석 {{< /programming-lang >}} {{< programming-lang lang="python" >}} -애플리케이션 분석은 파이썬(Python) 트레이싱 클라이언트 버전 0.19.0부터 사용할 수 있습니다. 트레이싱 클라이언트에 있는 단일 설정 파라미터를 사용해 모든 **웹** 통합에 대해 애플리케이션 분석을 글로벌 활성화할 수 있습니다. +App Analytics는 Python Tracing Client 버전 0.19.0부터 사용할 수 있으며, 이 구성은 ddtrace 버전 3.x 이하에서만 사용할 수 있습니다. Tracing Client에서 하나의 구성 파라미터를 사용하여 모든 **웹** 통합에 App Analytics를 전역적으로 활성화하세요. * 트레이서 설정: `ddtrace.config.analytics_enabled = True` * 환경 변수: `DD_TRACE_ANALYTICS_ENABLED=true` @@ -57,9 +57,9 @@ Datadog.configure { |c| c.tracing.analytics.enabled = true } {{< /programming-lang >}} {{< programming-lang lang="go" >}} -애플리케이션 분석은 고(Go) 트레이싱 클라이언트 1.11.0 버전부터 사용할 수 있으며 다음을 사용해 모든 **웹** 통합을 글로벌 활성화할 수 있습니다. +애플리케이션 분석은 고(Go) 트레이싱 클라이언트 1.11.0 버전부터 사용할 수 있으며 다음을 사용해 모든 **웹** 통합을 글로벌 활성화할 수 있습니다. -* [`WithAnalytics`][1] 트레이서 시작 옵션 예: +* [`WithAnalytics`][2] ([v1 문서][1]) 트레이서 시작 옵션, 예: ```go tracer.Start(tracer.WithAnalytics(true)) @@ -68,6 +68,7 @@ Datadog.configure { |c| c.tracing.analytics.enabled = true } * `DD_TRACE_ANALYTICS_ENABLED=true` 환경 변수를 사용하는 1.26.0 버전부터 [1]: https://pkg.go.dev/gopkg.in/DataDog/dd-trace-go.v1/ddtrace/tracer#WithAnalytics +[2]: https://pkg.go.dev/github.com/DataDog/dd-trace-go/v2/ddtrace/tracer#WithAnalytics {{< /programming-lang >}} {{< programming-lang lang="nodejs" >}} @@ -151,7 +152,7 @@ Nginx용 애플리케이션 분석을 활성화: {{< /programming-lang >}} {{< programming-lang lang="python" >}} -전 세계 설정과 더불어, 다음 설정을 사용해 개별 통합에 대한 애플리케이션 분석을 활성화하거나 비활성화할 수 있습니다. +글로벌 설정과 더불어, 다음 설정을 사용해 개별 통합에 대한 애플리케이션 분석을 활성화하거나 비활성화할 수 있습니다. * 트레이서 설정: `ddtrace.config..analytics_enabled = True` * 환경 변수: `DD__ANALYTICS_ENABLED=true` @@ -185,14 +186,16 @@ Datadog.configure { |c| c.tracing.instrument :integration, analytics_enabled: tr {{< /programming-lang >}} {{< programming-lang lang="go" >}} +{{% tracing-go-v2 %}} + 글로벌 설정과 더불어 각 통합에 대해 애플리케이션 분석을 각각 활성화하거나 비활성화할 수 있습니다. 예를 들어, 표준 라이브러리의 `net/http` 패키지를 설정하는 경우 다음을 수행할 수 있습니다. ```go package main import ( - httptrace "gopkg.in/DataDog/dd-trace-go.v1/contrib/net/http" - "gopkg.in/DataDog/dd-trace-go.v1/ddtrace/tracer" + httptrace "github.com/DataDog/dd-trace-go/contrib/net/http/v2" + "github.com/DataDog/dd-trace-go/v2/ddtrace/tracer" ) func main() { @@ -249,7 +252,7 @@ Tracer.Instance.Settings.Integrations["AspNetMvc"].AnalyticsEnabled = true; {{< /programming-lang >}} {{< programming-lang lang="php" >}} -전 세계 설정과 더불어, 다음 설정을 사용해 개별 통합에 대한 애플리케이션 분석을 활성화하거나 비활성화할 수 있습니다. +글로벌 설정과 더불어, 다음 설정을 사용해 개별 통합에 대한 애플리케이션 분석을 활성화하거나 비활성화할 수 있습니다. * 환경 변수: `DD__ANALYTICS_ENABLED=true` diff --git a/content/ko/tracing/services/deployment_tracking.md b/content/ko/tracing/services/deployment_tracking.md new file mode 100644 index 0000000000000..75136543a05a2 --- /dev/null +++ b/content/ko/tracing/services/deployment_tracking.md @@ -0,0 +1,239 @@ +--- +aliases: +- /ko/tracing/version_tracking +- /ko/tracing/deployment_tracking/ +description: Datadog을 사용하여 버전 태그를 통해 배포를 추적하세요 +further_reading: +- link: getting_started/tagging/unified_service_tagging/ + tag: 설명서 + text: Unified Service Tagging 및 예약된 태그에 대해 알아보세요 +- link: tracing/app_analytics + tag: 설명서 + text: App Analytics 쿼리에서 버전을 차원으로 사용하세요 +title: 배포 추적 +--- +## 버전 태그 + +`version` 태그는 Unified Service Tagging에 예약되어 있습니다. 이는 인프라스트럭처 메트릭(호스트, 컨테이너, 프로세스 및 NPM 검사), 트레이스 메트릭, 트레이스, 프로필 및 로그에 적용됩니다. + +`version` 태그를 사용하여 소프트웨어 배포 전략을 지원하는 배포 및 서비스 동작을 모니터링할 수 있습니다. + +`version` 태그를 설정하지 않은 경우 [[Unified Service Tagging 문서][1]에서 설정 정보를 참조하세요. + +## Service 페이지에서 버전 태그 사용 + +{{< img src="tracing/deployment_tracking/ServicePageRequestsErrorsByVersion.png" alt="Service 페이지의 버전" style="width:100%;">}} + + Service 페이지에서 `version` 태그를 사용할 수 있는 경우 요청 위젯의 범위를 다음으로 지정할 수 있습니다. + +- 버전별 총 요청 수 또는 +- 버전별 초당 요청 수 + +오류 위젯의 범위를 다음으로 지정할 수 있습니다. + +- 버전별 총 오류 수 +- 버전별 초당 오류 수 또는 +- 버전별 오류율(%) + +요청 및 오류 위젯은 모두 대시보드와 모니터로 내보낼 수 있습니다. + +## 잘못된 배포 자동 감지를 위해 버전 태그 사용 + +`version` 태그를 사용하여 서비스를 구성하면 [Automatic Faulty Deployment Detection][4]이 활성화됩니다. + +잠재적으로 결함이 있는 모든 배포에 대해 자동으로 알림을 받도록 모니터를 설정할 수 있습니다. 이렇게 하려면 New Monitors 페이지로 이동하여 이벤트를 선택하고 모니터를 정의하는 검색 쿼리에 `tags:deployment_analysis`를 포함합니다. + + +## 배포된 버전 + +`version` 태그로 구성된 서비스에는 Service 페이지의 기본 서비스 상태 그래프 아래에 버전 섹션이 있습니다. 버전 섹션에는 선택한 시간 간격 동안 활성화된 서비스의 모든 버전이 표시되며 활성 서비스가 맨 위에 표시됩니다. + +기본적으로 다음이 표시됩니다. + +- 일정 기간 동안 이 서비스에 배포된 버전 이름입니다. +- 이 버전에 해당하는 트레이스가 처음이자 마지막으로 표시된 시간입니다. +- 바로 이전 버전에는 나타나지 않았지만 각 버전에는 나타나는 오류 유형 수를 보여주는 Error Types 표시기입니다. + + **참고:** 이 표시는 이전 버전의 트레이스에서 볼 수 없었던 오류를 표시합니다. 이 버전에서 반드시 이러한 오류가 발생했다는 의미는 아닙니다. 새로운 오류 유형을 살펴보는 것은 오류 조사를 시작하는 좋은 방법이 될 수 있습니다. + +- 초당 요청입니다. +- 총 요청에 대한 오류율(%)입니다. + + +이 개요 테이블에서 열을 추가하거나 제거할 수 있으며 선택 사항이 저장됩니다. 추가로 사용 가능한 열은 다음과 같습니다. + +- 이전 버전에는 없었지만 버전에서 활성화된 엔드포인트입니다. +- 활성 시간 - 첫 번째 트레이스부터 해당 버전에 대해 Datadog으로 전송된 마지막 트레이스까지의 시간을 표시합니다. +- 총 요청 수입니다. +- 총 오류 수입니다. +- p50, p75, p90, p95, p99 또는 최대로 측정된 지연 시간입니다. + +{{< img src="tracing/deployment_tracking/VersionComparison.png" alt="서비스 페이지의 버전" style="width:100%;">}} + +**참고:** 버전 섹션은 페이지 상단에서 선택한 기간 동안 보고되는 버전이 두 개 이상인 경우에만 나타납니다. + +## 배포 비교 + +버전 요약 표에서 버전 행을 클릭하면 버전 비교 페이지가 열리며, 동일한 서비스의 두 버전을 비교할 수 있습니다. 기본적으로 선택한 버전은 바로 이전 버전과 비교되지만 지난 30일 내의 두 버전을 비교하도록 변경할 수 있습니다. + +버전 비교 페이지에서 다음 정보를 확인할 수 있습니다. + +- [비교 그래프](#comparison-graphs): 서비스에 대한 요청 및 오류를 시각화하여 다양한 유형의 [배포](#deployment-strategies)를 관찰하는 데 유용합니다. +- [오류 비교](#error-comparison): 버전에 따라 발생했거나 해결되었을 수 있는 오류입니다. +- [엔드포인트 비교](#endpoint-comparison): 각 버전에서 엔드포인트 대기 시간 및 오류율이 어떻게 나타나는지 파악할 수 있습니다. + +### 비교 그래프 + +Service 페이지의 그래프와 유사하게 요청 및 오류 그래프는 배포 롤아웃 개요 또는 오류율 급증을 보여줍니다. 이 페이지에서 그래프는 비교를 위해 선택한 버전을 강조 표시하고 추가 컨텍스트를 위해 다른 모든 버전은 회색으로 둡니다. + +{{< img src="tracing/deployment_tracking/ComparisonGraphs.png" alt="배포 비교 그래프" style="width:100%;">}} + +[Continuous Profiler가 활성화된 경우][5] CPU 시간이나 할당된 메모리와 같은 주요 성능 메트릭의 비교가 APM 리소스별로 분류되어 표시됩니다. 여기에서 [Profile Comparison 페이지][6]로 전환할 수 있습니다. + +{{< img src="tracing/deployment_tracking/DeploymentTrackingProfileComparison.png" alt="배포 프로파일링 비교 그래프" style="width:100%;">}} + +### 오류 비교 + +이 섹션에는 두 버전 각각에 대해 감지된 오류 유형의 차이점이 나열되어 있으며 다음을 강조합니다. + + - 소스 버전에만 나타나며 문제 해결에 유용한 오류 유형입니다. + - 더 이상 소스 버전에 나타나지 않으며 수정 사항을 검증하는 데 유용한 오류 유형입니다. + - 둘다에서 나타나는 오류 유형입니다. + +이 테이블에서 추가 조사를 위해 선택한 오류에 해당하는 실시간 또는 기록 트레이스로 전환할 수 있습니다. + +**참고:** 오류 비교는 _관찰된_ 오류 유형을 기반으로 합니다. 오류 유형이 드물다면 _아직_ 표시되지 않았기 때문에 더 이상 표시되지 않는 것으로 나열될 수 있습니다. + +{{< img src="tracing/deployment_tracking/ErrorComparison.mp4" alt="오류 비교" video=true style="width:100%;">}} + +### 엔드포인트 비교 + +이 섹션에서는 서비스에 있는 각 엔드포인트의 성능(요청, 대기 시간 및 오류)을 비교할 수 있습니다. 배포 후에도 처리량이 가장 높은 엔드포인트가 여전히 정상인지 확인하려면 값을 기준으로 테이블을 정렬하고, 대기 시간 또는 오류율의 큰 변화를 확인하려면 변경률을 기준으로 정렬하세요. + +{{< img src="tracing/deployment_tracking/EndpointComparison.png" alt="엔드포인트 비교" style="width:100%;">}} + +## 배포 전략 + +Datadog의 배포 추적은 잘못된 코드 배포를 감지하고 변경 사항의 영향을 억제합니다. 또한 사고에 더 빠르게 대응하기 위해 다음 배포 전략(또는 기타)을 사용할 때 배포된 코드의 성능에 대한 가시성을 제공합니다. + +### 롤링 배포 + +롤링 배포는 호스트 또는 컨테이너에 새 버전을 하나씩 배포하는 동안 트래픽을 다른 인스턴스로 이동시켜 다운타임을 없앱니다. + +Datadog을 사용하면 롤링 배포를 모니터링하고 그에 따른 오류 증가를 감지할 수 있습니다. + +{{< img src="tracing/deployment_tracking/rolling.png" alt="롤링 배포" style="width:100%;">}} + +### 파란색 및 녹색 배포 + +파란색과 녹색(또는 기타 색상 조합) 배포는 트래픽을 모두 허용하는 두 개의 서비스 클러스터를 실행하거나 하나를 대기 상태로 유지하고 다른 하나에 문제가 있을 경우 활성화할 수 있도록 하여 가동 중지 시간을 줄입니다. + +이러한 서비스에 대해 `version` 태그를 설정하고 확인하면 요청과 오류를 비교하여 클러스터 중 하나의 오류율이 다른 클러스터보다 높은지, 클러스터가 SLO를 충족하지 않는지, 또는 트래픽을 수신해서는 안 되는 클러스터인지 감지할 수 있습니다. + +{{< img src="tracing/deployment_tracking/BlueGreenDeploy.png" alt="Blue/Green 배포" style="width:100%;">}} + +### 카나리 배포 + +카나리 배포를 사용하면 제한된 수의 호스트 또는 일부 고객을 대상으로 서비스를 배포하여 제한된 영향력 내에서 테스트할 수 있습니다. + +Datadog 내에서 `version` 태그를 사용하면 카나리 배포에 대한 오류율, 트레이스 및 서비스 동작을 비교할 수 있습니다. + +예를 들어 다음 이미지에서는 카나리 버전이 배포되고 몇 가지 오류가 발생하여 제거되었으며 추가 영향 없이 조사에 사용가능한 해당 버전에 해당하는 트레이스를 볼 수 있습니다. + +{{< img src="tracing/deployment_tracking/canarydeployment.png" alt="카나리 배포" style="width:100%;">}} + +### 섀도우 배포 + +섀도우 배포에서는 릴리스 후보 버전이 프로덕션 버전과 함께 배포되며, 들어오는 트래픽이 두 서비스 모두로 전송됩니다. 사용자는 프로덕션의 결과만 볼 수 있지만 두 서비스 모두에서 데이터를 수집할 수 있습니다. + +섀도우 배포를 사용하면 실제 프로덕션 트래픽에 대해 잠재적인 릴리스를 테스트할 수 있습니다. 섀도우에 `version` 태그를 지정하면 두 버전 간의 오류율, 트레이스 및 서비스 동작을 비교하여 섀도우 버전을 릴리스해야 하는지 결정할 수 있습니다. + +## Datadog 내 다른 곳에서 버전 태그 사용 + +`version` 태그는 검색 보기를 특정 버전으로 필터링하거나 다른 버전의 메트릭을 비교하는 등 Datadog 내 어디에서나 사용할 수 있습니다. + +### Resource 페이지 + +{{< img src="tracing/deployment_tracking/ResourcePage.png" alt="Resource 페이지의 버전" style="width:100%;">}} + +Resource 페이지에서 버전 태그를 사용할 수 있는 경우 요청 위젯의 범위는 다음 중 하나로 지정될 수 있습니다. + +- 버전별 총 요청 +- 버전별 초당 요청 + +오류 위젯의 범위는 `version` 태그와 관련된 세 가지 옵션 중 하나로 지정될 수 있습니다. + +- 버전별 총 오류 수 +- 버전별 초당 오류 +- 버전별 오류율(%) + +이들 모두는 대시보드와 모니터로 내보낼 수 있습니다. + +### 트레이스 검색 및 분석 + +{{< img src="tracing/deployment_tracking/AnalyticsErrorsByVersion.mp4" alt="App Analytics 버전" video=true style="width:100%;">}} + +사용 가능한 경우 실시간 검색 모드 및 인덱싱된 트레이스를 필터링하거나 분석 쿼리를 필터링 또는 그룹화하기 위해 Trace Search 및 Analytics 모두에 대한 태그로 `version`을 사용할 수 있습니다. + +`version` 태그 필터링을 포함한 분석을 대시보드 및 모니터로 내보낼 수 있습니다. + +### 버전별 프로필 + +특정 버전에 해당하는 프로필을 검색할 수 있습니다. [Deployment Comparison](#deployment-comparison) 페이지 오른쪽 상단에 있는 **View Profiles**를 클릭하여 비교 중인 두 버전으로 범위가 지정된 Continuous Profiler를 열 수도 있습니다. + +{{< img src="tracing/deployment_tracking/VersionProfiler.png" alt="버전별로 프로필 필터링" style="width:100%;">}} + +
+ +## 배포 메트릭 사이의 시간 + +서비스의 새 배포가 감지될 때마다 배포 추적은 `time_between_deployments` 메트릭에 대한 값을 계산합니다. 새 배포와 그 이전의 최신 버전 배포 사이의 기간(초)으로 계산됩니다. + +### 메트릭 정의 + +`datadog.service.time_between_deployments{env, service, second_primary_tag}` +: **전제 조건:** 이 지표는 [Unified Service Tagging][1]을 통해 버전 태그 지정이 활성화된 모든 APM 서비스에 대해 존재합니다.
+**설명:** 서비스 배포와 그 이전의 최신 버전 배포 사이에 경과된 시간(초)입니다.
+**메트릭 유형:** [분포][2]
+**태그:** 메트릭에는 서비스의 `env`, `service` 및 [두 번째 기본 태그][3] 태그가 지정됩니다. + +### 예시 + +time = 0에 버전 A를 배포하고 time = 10에 버전 B를 배포하는 서비스가 있는 경우 `datadog.service.time_between_deployments` 메트릭 값은 10입니다. + +Time = 0 +: `{service: foo, env: prod, cluster-name: dev-shopist, version: A}` + +Time = 10 +: `{service: foo, env: prod, cluster_name: dev-shopist, version: B}` + +배포 간 시간 +: `datadog.service.time_between_deployments{env: prod, cluster_name: dev-shopist} = 10` + + +클러스터 `dev-shopist`에서 time = 20에 버전 X를 배포하고 클러스터 `us-staging`에서 time = 30에 버전 Y를 배포하며, 클러스터 `dev-shopist`에서 time = 45에 버전 Y를 다시 배포하는 경우 모든 클러스터에 대한 `datadog.service.time_between_deployments` 메트릭 `max` 값은 25(가장 최근 Y의 시간에서 마지막 X를 뺀 값 )입니다. + +Time = 20 +: `{service: foo, env: staging, cluster-name: dev-shopist, version: X}` + +Time = 30 +: `{service: foo, env: staging, cluster-name: us-staging, version: Y}` + +Time = 45 +: `{service: foo, env: staging, cluster-name: dev-shopist, version: Y}` + +배포 간 최대 시간: +: `max:datadog.service.time_between_deployments{env: staging, cluster-name: *} = 25` + + +## 참고 자료 + +{{< partial name="whats-next/whats-next.html" >}} + + +[1]: /ko/getting_started/tagging/unified_service_tagging/ +[2]: /ko/metrics/types/?tab=distribution#metric-types +[3]: /ko/tracing/guide/setting_primary_tags_to_scope/#add-a-second-primary-tag-in-datadog +[4]: /ko/watchdog/faulty_deployment_detection/ +[5]: /ko/profiler/enabling/ +[6]: /ko/profiler/compare_profiles \ No newline at end of file diff --git a/layouts/shortcodes/observability_pipelines/configure_existing_pipelines/source_env_vars/http_server.ja.md b/layouts/shortcodes/observability_pipelines/configure_existing_pipelines/source_env_vars/http_server.ja.md new file mode 100644 index 0000000000000..f93157db452a6 --- /dev/null +++ b/layouts/shortcodes/observability_pipelines/configure_existing_pipelines/source_env_vars/http_server.ja.md @@ -0,0 +1,3 @@ +- HTTP/S server address: + - The Observability Pipelines Worker listens to this socket address, such as `0.0.0.0:9997`, for your HTTP client logs. + - 環境変数 `DD_OP_SOURCE_HTTP_SERVER_ADDRESS` に格納されています。 \ No newline at end of file diff --git a/layouts/shortcodes/observability_pipelines/configure_existing_pipelines/source_env_vars/logstash.ja.md b/layouts/shortcodes/observability_pipelines/configure_existing_pipelines/source_env_vars/logstash.ja.md new file mode 100644 index 0000000000000..cf2274fac9e6f --- /dev/null +++ b/layouts/shortcodes/observability_pipelines/configure_existing_pipelines/source_env_vars/logstash.ja.md @@ -0,0 +1,3 @@ +- Logstash address and port: + - Observability Pipelines Worker は着信ログメッセージを受信するためにこのアドレス (例: `0.0.0.0:9997`) をリッスンします。 + - `DD_OP_SOURCE_LOGSTASH_ADDRESS` として環境変数に格納されています。 diff --git a/layouts/shortcodes/observability_pipelines/configure_existing_pipelines/source_env_vars/sumo_logic.ja.md b/layouts/shortcodes/observability_pipelines/configure_existing_pipelines/source_env_vars/sumo_logic.ja.md new file mode 100644 index 0000000000000..fbe2f8810006d --- /dev/null +++ b/layouts/shortcodes/observability_pipelines/configure_existing_pipelines/source_env_vars/sumo_logic.ja.md @@ -0,0 +1,4 @@ +- Sumo Logic address: + - The bind address that your Observability Pipelines Worker listens on to receive logs originally intended for the Sumo Logic HTTP Source. For example, `0.0.0.0:80`. + **Note**: `/receiver/v1/http/` path is automatically appended to the endpoint. + - 環境変数 `DD_OP_SOURCE_SUMO_LOGIC_ADDRESS` に格納されています。 \ No newline at end of file diff --git a/layouts/shortcodes/observability_pipelines/configure_log_archive/amazon_s3/connect_s3_to_datadog_log_archives.ja.md b/layouts/shortcodes/observability_pipelines/configure_log_archive/amazon_s3/connect_s3_to_datadog_log_archives.ja.md new file mode 100644 index 0000000000000..eef3986a39744 --- /dev/null +++ b/layouts/shortcodes/observability_pipelines/configure_log_archive/amazon_s3/connect_s3_to_datadog_log_archives.ja.md @@ -0,0 +1,19 @@ +#### S3 バケットを Datadog Log Archives に接続する + +1. Datadog の [Log Forwarding][201] に移動します。 +1. Click **New archive**. +1. わかりやすいアーカイブ名を入力します。 +1. ログパイプラインを通過するすべてのログをフィルタリングして、それらのログがこのアーカイブに入らないようにするクエリを追加します。例えば、クエリ `observability_pipelines_read_only_archive` を追加します。これは、パイプラインを通過するログにそのタグが追加されていないと仮定しています。 +1. **AWS S3** を選択します。 +1. バケットが存在する AWS アカウントを選択します。 +1. S3 バケットの名前を入力します。 +1. オプションでパスを入力します。 +1. 確認文をチェックします。 +1. オプションで、タグを追加し、再ハイドレートのための最大スキャンサイズを定義します。詳細については、[高度な設定][202]を参照してください。 +1. **Save** をクリックします。 + +詳細については [Log Archives のドキュメント][203]を参照してください。 + +[201]: https://app.datadoghq.com/logs/pipelines/log-forwarding +[202]: /ja/logs/log_configuration/archives/?tab=awss3#advanced-settings +[203]: /ja/logs/log_configuration/archives \ No newline at end of file diff --git a/layouts/shortcodes/observability_pipelines/destination_env_vars/amazon_opensearch.ja.md b/layouts/shortcodes/observability_pipelines/destination_env_vars/amazon_opensearch.ja.md new file mode 100644 index 0000000000000..3333fc992d425 --- /dev/null +++ b/layouts/shortcodes/observability_pipelines/destination_env_vars/amazon_opensearch.ja.md @@ -0,0 +1,3 @@ +1. Enter the Amazon OpenSearch authentication username. +1. Enter the Amazon OpenSearch authentication password. +1. Enter the Amazon OpenSearch endpoint URL. For example, `http://:9200`. \ No newline at end of file diff --git a/layouts/shortcodes/observability_pipelines/destination_env_vars/datadog_archives_google_cloud_storage.ja.md b/layouts/shortcodes/observability_pipelines/destination_env_vars/datadog_archives_google_cloud_storage.ja.md new file mode 100644 index 0000000000000..295399107aa24 --- /dev/null +++ b/layouts/shortcodes/observability_pipelines/destination_env_vars/datadog_archives_google_cloud_storage.ja.md @@ -0,0 +1 @@ +There are no environment variables to configure. \ No newline at end of file diff --git a/layouts/shortcodes/observability_pipelines/destination_env_vars/elasticsearch.ja.md b/layouts/shortcodes/observability_pipelines/destination_env_vars/elasticsearch.ja.md new file mode 100644 index 0000000000000..23a4c40d16168 --- /dev/null +++ b/layouts/shortcodes/observability_pipelines/destination_env_vars/elasticsearch.ja.md @@ -0,0 +1,3 @@ +1. Enter the Elasticsearch authentication username. +2. Enter the Elasticsearch authentication password. +3. Enter the Elasticsearch endpoint URL. For example, `http://CLUSTER_ID.LOCAL_HOST_IP.ip.es.io:9200`. diff --git a/layouts/shortcodes/observability_pipelines/destination_env_vars/elasticsearch.ko.md b/layouts/shortcodes/observability_pipelines/destination_env_vars/elasticsearch.ko.md new file mode 100644 index 0000000000000..b5b17395c5cf5 --- /dev/null +++ b/layouts/shortcodes/observability_pipelines/destination_env_vars/elasticsearch.ko.md @@ -0,0 +1,3 @@ +1. Elasticsearch 인증 사용자 이름을 입력합니다. +2. Elasticsearch 인증 비밀번호를 입력합니다. +3. Elasticsearch 엔드포인트 URL을 입력합니다. 예: `http://CLUSTER_ID.LOCAL_HOST_IP.ip.es.io:9200` diff --git a/layouts/shortcodes/observability_pipelines/destination_env_vars/opensearch.ko.md b/layouts/shortcodes/observability_pipelines/destination_env_vars/opensearch.ko.md new file mode 100644 index 0000000000000..518793c9e323e --- /dev/null +++ b/layouts/shortcodes/observability_pipelines/destination_env_vars/opensearch.ko.md @@ -0,0 +1,3 @@ +1. OpenSearch 인증 사용자 이름을 입력합니다. +1. OpenSearch 인증 비밀번호를 입력합니다. +1. OpenSearch 엔드포인트 URL을 입력합니다. 예: `http://:9200` \ No newline at end of file diff --git a/layouts/shortcodes/observability_pipelines/log_source_configuration/fluent.ja.md b/layouts/shortcodes/observability_pipelines/log_source_configuration/fluent.ja.md new file mode 100644 index 0000000000000..67c2b13c670a7 --- /dev/null +++ b/layouts/shortcodes/observability_pipelines/log_source_configuration/fluent.ja.md @@ -0,0 +1,25 @@ +### Fluent Bit 構成 +To configure Fluent Bit to send logs to the Observability Pipelines Worker, use the following output configuration: +``` +[OUTPUT] + Name forward + Match * + # Update these to point to your Observability Pipelines Worker + Host 127.0.0.1 + Port 24224 +``` + +### Fluentd configuration +To configure Fluentd to send logs to the Observability Pipelines Worker, use the following output configuration: +``` + + @type forward + + # Update these to point to your Observability Pipelines Worker + name local + host 127.0.0.1 + port 24224 + + compress gzip + +``` \ No newline at end of file diff --git a/layouts/shortcodes/observability_pipelines/prerequisites/logstash.ja.md b/layouts/shortcodes/observability_pipelines/prerequisites/logstash.ja.md new file mode 100644 index 0000000000000..02ea05d19bd7d --- /dev/null +++ b/layouts/shortcodes/observability_pipelines/prerequisites/logstash.ja.md @@ -0,0 +1,4 @@ +Observability Pipelines の Logstash ソースを使用するには、次の情報が必要です。 + +- `0.0.0.0:8088` などの Logstash アドレス。Observability Pipelines Worker は、このバインドアドレスでアプリケーションからのログを受信します。後で、アプリケーションを設定してログをこのアドレスに送信します。 +- フォワーダーがグローバル設定で SSL を有効にしている場合は、適切な TLS 証明書と、秘密鍵を作成する際に使用したパスワード。 \ No newline at end of file diff --git a/layouts/shortcodes/observability_pipelines/processors/add_hostname.ja.md b/layouts/shortcodes/observability_pipelines/processors/add_hostname.ja.md new file mode 100644 index 0000000000000..bca6c68694f65 --- /dev/null +++ b/layouts/shortcodes/observability_pipelines/processors/add_hostname.ja.md @@ -0,0 +1,4 @@ +This processor adds a field with the name of the host that sent the log. For example, `hostname: 613e197f3526`. **Note**: If the `hostname` already exists, the Worker throws an error and does not overwrite the existing `hostname`. + +To set up this processor: +- Define a **filter query**. Only logs that match the specified [filter query](#filter-query-syntax) are processed. All logs, regardless of whether they do or do not match the filter query, are sent to the next step in the pipeline.