diff --git a/hugo/content/es/actions/private_actions/authorize_private_actions.md b/hugo/content/es/actions/private_actions/authorize_private_actions.md new file mode 100644 index 00000000000..09ef2882d35 --- /dev/null +++ b/hugo/content/es/actions/private_actions/authorize_private_actions.md @@ -0,0 +1,74 @@ +--- +description: Aprenda cómo Datadog autoriza Private Actions mediante Políticas de ejecución + y Conexiones. +disable_toc: false +further_reading: +- link: actions/private_actions/ + tag: Documentación + text: Descripción general de Private Actions +- link: actions/private_actions/enroll_runner/ + tag: Documentación + text: Inscripción y propiedad +- link: actions/private_actions/set_up_agent_based/ + tag: Documentación + text: Configurar un ejecutor de Private Actions +- link: actions/private_actions/execution_policies/ + tag: Documentación + text: Políticas de ejecución +- link: actions/connections/ + tag: Documentación + text: Conexiones +title: Autorizar Private Actions +--- +## Descripción general {#overview} + +Cuando sus flujos de trabajo y aplicaciones utilizan Private Actions, Datadog decide si la acción está permitida y, luego, su **runner de Private Actions** la ejecuta. Antes de que se envíe una tarea a un ejecutor, Datadog verifica si el usuario que realiza la solicitud tiene permiso para actuar en ese ejecutor. Si no está permitida, la tarea nunca se envía. + +Esta página explica cómo se toma esa decisión de autorización. Cubre los modelos que Datadog utiliza para permitir o denegar una acción, y qué modelo se aplica a su ejecutor. + +## Encuentre su modelo de autorización {#find-your-authorization-model} + +Un runner se autoriza mediante uno de dos modelos: [**Políticas de ejecución**](#execution-policies) o [**Conexiones**](#connections). El modelo está determinado por la propiedad del runner, establecida una vez cuando el runner se inscribe. Un runner determinado utiliza exactamente uno de estos modelos durante toda su vida útil; no puede combinar ambos en el mismo runner. Debido a que la propiedad se establece por runner, una sola flota basada en el Agent puede incluir runners sin propietario y con propietario, cada uno autorizado por su propio modelo. + +- **El runner en el Datadog Agent** depende de cómo se inscribió. Un runner de Agent sin propietario utiliza [Políticas de ejecución](#execution-policies); un runner de Agent con propietario utiliza [Conexiones](#connections). +- **El runner independiente** siempre tiene propietario, por lo que siempre utiliza [Conexiones](#connections). + +Para saber cómo la inscripción establece la propiedad de un runner, consulte [Inscripción y propiedad][1]. + +## Compare los dos modelos {#compare-the-two-models} + +| | Políticas de ejecución | Conexiones | +|---|---|---| +| **Funciona con** | Runners solo en el Datadog Agent | Tanto runners independientes como runners en el Datadog Agent | +| **Cómo se otorga el acceso** | Las Agent tags apuntan a uno o más conjuntos de runners, por lo que una política gestiona el acceso a través de una flota en lugar de una conexión separada por integración por runner | Una conexión almacena credenciales y las empareja con un solo runner | +| **Credenciales** | Las políticas de ejecución no almacenan credenciales; el acceso se otorga mediante etiquetas de agente. Las acciones que requieren credenciales (por ejemplo, HTTP, GitLab y MongoDB) no son compatibles. | La conexión contiene las credenciales utilizadas para ejecutar la acción | +| **Control** | Detallado: permite o deniega acciones específicas o conjuntos de acciones, además de alcances específicos de la integración, como los espacios de nombres de Kubernetes de destino para una acción de Kubernetes | Por runner: una conexión apunta a un runner específico | + +## Políticas de ejecución {#execution-policies} + +**Las políticas de ejecución** son un modelo de autorización para runners en el Datadog Agent. Cada política gestiona el acceso a través de uno o más conjuntos de runners a la vez. En lugar de una conexión independiente por integración por runner, usted utiliza **Agent tags** para definir los Agent de destino. Luego, les adjunta una regla de permitir o denegar. + +Las políticas de ejecución también proporcionan un control detallado. Una política puede permitir o denegar acciones específicas o conjuntos de acciones. También puede aplicar alcances específicos de la integración, como los espacios de nombres de Kubernetes de destino para una acción de Kubernetes. El acceso se otorga a través de Agent tags en lugar de credenciales almacenadas, por lo que las políticas de ejecución no almacenan credenciales y son utilizadas por runners sin propietario en el Agent. + +Para obtener más información sobre las políticas de ejecución y cómo configurarlas (objetivos, reglas, control de acceso y uso de políticas de ejecución en flujos de trabajo), consulte [Políticas de ejecución][2]. + +## Conexiones {#connections} + +Las conexiones funcionan tanto para runners independientes como para runners en el Datadog Agent, y son el modelo utilizado por runners propios. + +Una conexión hace dos cosas: + +- **Hace referencia a las credenciales** necesarias para ejecutar una acción en su servicio. Las credenciales en sí (por ejemplo, un token de API o un nombre de usuario y contraseña) se almacenan localmente con el runner, en un archivo de credenciales en su servidor o contenedor; la conexión apunta a ellas. +- **Empareja esas credenciales con un único runner.** Una conexión apunta a un runner, por lo que las credenciales solo son utilizadas por el runner que usted pretende. + +Para usar una conexión en un flujo de trabajo o aplicación, necesita el permiso adecuado para esa conexión. El acceso a una conexión puede restringirse para que solo las personas que la necesiten puedan usarla en sus flujos de trabajo y aplicaciones. + +Para obtener las instrucciones de configuración completas (creación, edición y restricción de conexiones, etiquetas de identificador de conexión y grupos de conexión), consulte [Conexiones][3]. + +## Lecturas adicionales {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /es/actions/private_actions/enroll_runner/ +[2]: /es/actions/private_actions/execution_policies/ +[3]: /es/actions/connections/ \ No newline at end of file diff --git a/hugo/content/es/actions/workflows/expressions/python.md b/hugo/content/es/actions/workflows/expressions/python.md new file mode 100644 index 00000000000..7bd51b616d2 --- /dev/null +++ b/hugo/content/es/actions/workflows/expressions/python.md @@ -0,0 +1,121 @@ +--- +code_lang: python +code_lang_weight: 20 +description: Capacidades y límites de las expresiones de Python en App Builder +title: Expresiones de Python +type: multi-code-lang +--- +La acción de función de Python le permite escribir scripts de Python personalizados para transformaciones de datos, parseo y enriquecimiento de carga útil dentro de sus flujos de trabajo. + +## Entorno de Python{#python-environment} + +La acción de función de Python se ejecuta en un entorno de ejecución restringido con las siguientes características: + +{{< workflow-python-action-characteristics >}} + +## Estructura del script{#script-structure} + +Todos los scripts de Python deben definir una función `main` que acepte un parámetro `ctx` de tipo `Context`. Por ejemplo: + +```python +from execution_context import Context + +def main(*, ctx: Context): + # Use ctx to access Trigger or Steps data + workflow_name = ctx["WorkflowName"] + return f"Running workflow {workflow_name!r}" +``` + +El objeto `ctx` proporciona acceso a todas las variables de contexto del flujo de trabajo, similar a la variable `$` en las expresiones de JavaScript. Utilice el acceso de estilo diccionario (por ejemplo, `ctx["Steps"]["Step_name"]["variable"]`) para hacer referencia a valores de pasos anteriores. + +## Agregar una acción de función de Python{#add-a-python-function-action} + +En el lienzo del flujo de trabajo: +1. Haga clic en {{< ui >}}\+{{< /ui >}} para agregar un paso al flujo de trabajo. +1. Busque `Python`. +1. Seleccione la acción de Python para agregarla a su flujo de trabajo. + +## Escribir scripts de Python con IA{#write-python-scripts-with-ai} + +Puede usar Bits AI para ayudar a escribir scripts de Python dentro de un paso del flujo de trabajo. + +Para escribir un script con Bits AI: + +1. Agregue un paso a su flujo de trabajo. +1. En la sección {{< ui >}}Inputs{{< /ui >}}, haga clic en {{< ui >}}Write Code with AI{{< /ui >}}. +1. Ingrese un prompt personalizado o seleccione uno de los prompts de ejemplo. +1. Opcionalmente, haga clic en {{< ui >}}Test script{{< /ui >}} para generar una vista previa del paso del flujo de trabajo. +1. Para guardar el script, haga clic en {{< ui >}}Accept changes{{< /ui >}}. Para continuar editando el script, haga clic en {{< ui >}}Reject changes{{< /ui >}}. +1. Haga clic en {{< ui >}}X{{< /ui >}} para cerrar el cuadro de diálogo de IA. +1. Ingrese un {{< ui >}}Description{{< /ui >}}. +1. Haga clic en {{< ui >}}Save{{< /ui >}}. + +## Ejemplos de scripts {#script-examples} + +### Analizar y transformar datos JSON {#parse-and-transform-json-data} + +Este ejemplo analiza una cadena JSON de un paso anterior y extrae campos específicos. + +```python +from execution_context import Context +import json + +def main(*, ctx: Context): + # Get JSON string from previous step + json_string = ctx["Steps"]["Get_data"]["output"] + + # Parse and transform + data = json.loads(json_string) + return { + "user_ids": [user["id"] for user in data["users"]], + "total_count": len(data["users"]) + } +``` + +### Trabajar con fechas y marcas de tiempo {#work-with-dates-and-timestamps} + +Este ejemplo utiliza la biblioteca python-dateutil para realizar cálculos de fechas. + +```python +from execution_context import Context +from dateutil import parser, relativedelta +from datetime import datetime + +def main(*, ctx: Context): + # Parse a date string + start_date = parser.parse(ctx["Trigger"]["date_string"]) + + # Calculate date 30 days in the future + future_date = start_date + relativedelta.relativedelta(days=30) + + return { + "start": start_date.isoformat(), + "end": future_date.isoformat(), + "days_difference": 30 + } +``` + +### Operaciones criptográficas {#cryptographic-operations} + +Este ejemplo utiliza la biblioteca rsa para cifrar un mensaje. + +```python +from execution_context import Context +import rsa +import base64 + +def main(*, ctx: Context): + # Get message from workflow context + message = ctx["Steps"]["Compose_message"]["text"] + + # Generate RSA key pair + (public_key, private_key) = rsa.newkeys(512) + + # Encrypt message + encrypted = rsa.encrypt(message.encode(), public_key) + + return { + "encrypted_message": base64.b64encode(encrypted).decode(), + "public_key": public_key.save_pkcs1().decode() + } +``` \ No newline at end of file diff --git a/hugo/content/es/agent/supported_platforms/linux.md b/hugo/content/es/agent/supported_platforms/linux.md index 3c17f835343..221986f40b4 100644 --- a/hugo/content/es/agent/supported_platforms/linux.md +++ b/hugo/content/es/agent/supported_platforms/linux.md @@ -26,66 +26,66 @@ aliases: further_reading: - link: /logs/ tag: Documentación - text: Reúne tus registros + text: Recopile sus registros - link: /infrastructure/process/ tag: Documentación - text: Reúne tus procesos + text: Recopile sus procesos - link: /tracing/ tag: Documentación - text: Reúne tus trazas + text: Recopile sus trazas - link: /agent/architecture/#agent-architecture tag: Documentación - text: Descubre más sobre la arquitectura del Agente + text: Obtenga más información sobre la arquitectura del Agent - link: /agent/configuration/network#configure-ports tag: Documentación - text: Configura los puertos de entrada + text: Configurar puertos de entrada platform: Linux title: Linux --- -## Resumen {#overview} +## Descripción general {#overview} -Esta página describe las características básicas del Agente de Datadog para entornos Linux. Consulta la documentación de [Plataformas Soportadas][5] para obtener la lista completa de distribuciones y versiones de Linux soportadas. +Esta página describe las características básicas del Datadog Agent para entornos Linux. Consulte la documentación de [Plataformas compatibles][5] para obtener la lista completa de distribuciones y versiones de Linux compatibles. -## Instalar el Agente {#install-the-agent} -Para instalar el Agente en Linux, sigue las [instrucciones en la aplicación en Fleet Automation][6] y ejecuta el script generado en tus servidores. +## Instale el Agent {#install-the-agent} +Para instalar el Agent en Linux, siga las instrucciones en Fleet Automation y ejecute el script generado en sus hosts. -{{< img src="/agent/basic_agent_usage/linux_img_july_25.png" alt="Pasos de instalación en la aplicación para el Agente de Datadog en un servidor Linux." style="width:90%;">}} +{{< img src="/agent/basic_agent_usage/linux_img_july_25.png" alt="Pasos de instalación in-app para el Datadog Agent en un host Linux." style="width:90%;">}} -## Configurar el Agente {#configure-the-agent} -El archivo de configuración del Agente de Datadog se encuentra en `/etc/datadog-agent/datadog.yaml`. Este archivo YAML contiene los detalles de conexión a nivel de servidor utilizados para enviar datos a Datadog, incluyendo: -- `api_key`: La [clave de API de Datadog][7] de tu organización -- `site`: Región objetivo de Datadog (por ejemplo `datadoghq.com`, `datadoghq.eu`, `ddog-gov.com`, `us2.ddog-gov.com`) -- `proxy`: Puntos de conexión de proxy HTTP/HTTPS para tráfico saliente (ver [Configuración del Proxy del Agente de Datadog][8]) +## Configure el Agent {#configure-the-agent} +El archivo de configuración del Datadog Agent se encuentra en `/etc/datadog-agent/datadog.yaml`. Este archivo YAML contiene los detalles de conexión a nivel de host que se utilizan para enviar datos a Datadog, incluyendo: +- `api_key`: La [clave de API de Datadog][7] de su organización +- `site`: Región de Datadog de destino (por ejemplo, `datadoghq.com`, `datadoghq.eu`, `ddog-gov.com`, `us2.ddog-gov.com`) +- `proxy`: Endpoints de proxy HTTP/HTTPS para tráfico saliente (consulte [Configuración de proxy del Datadog Agent][8]) - Etiquetas predeterminadas, nivel de registro y configuraciones de Datadog -Un archivo de referencia completamente comentado, ubicado en `/etc/datadog-agent/datadog.yaml.example`, enumera todas las opciones disponibles para comparación o para copiar y pegar. Alternativamente, consulta el archivo de muestra `config_template.yaml` para todas las opciones de configuración disponibles. +Un archivo de referencia totalmente comentado, ubicado en `/etc/datadog-agent/datadog.yaml.example`, enumera todas las opciones disponibles para comparación o para copiar y pegar. Alternativamente, consulte el archivo de configuración de ejemplo del Agent para Linux en GitHub. ### Archivos de integración {#integration-files} -Los archivos de configuración para integraciones se encuentran en `/etc/datadog-agent/conf.d/`. Cada integración tiene su propio subdirectorio, `.d/`, que contiene: +Los archivos de configuración para las integraciones se encuentran en `/etc/datadog-agent/conf.d/`. Cada integración tiene su propio subdirectorio, `.d/`, que contiene: - `conf.yaml`: La configuración activa que controla cómo la integración recopila métricas y registros -- `conf.yaml.example`: Un ejemplo que ilustra las claves y los valores predeterminados soportados +- `conf.yaml.example`: Una muestra que ilustra las claves admitidas y los valores predeterminados ## Comandos {#commands} | Descripción | Comando | |---------------|-----------------------| -| Iniciar el Agente como un servicio | `sudo systemctl start datadog-agent` | -| Detener el Agente que se ejecuta como un servicio | `sudo systemctl stop datadog-agent` | -| Reiniciar el Agente que se ejecuta como un servicio | `sudo systemctl restart datadog-agent` | -| Estado del servicio del Agente | `sudo systemctl status datadog-agent` | -| Página de estado del Agente en ejecución | `sudo datadog-agent status` | -| Enviar flare | `sudo datadog-agent flare` | -| Mostrar uso del comando | `sudo datadog-agent --help` | -| Ejecutar una verificación | `sudo -u dd-agent -- datadog-agent check ` | +| Iniciar el Agent como servicio | `sudo systemctl start datadog-agent` | +| Detener el Agent que se ejecuta como servicio | `sudo systemctl stop datadog-agent` | +| Reiniciar el Agent que se ejecuta como servicio | `sudo systemctl restart datadog-agent` | +| Estado del servicio del Agent | `sudo systemctl status datadog-agent` | +| Página de estado del Agent en ejecución | `sudo datadog-agent status` | +| Enviar flare | `sudo datadog-agent flare` | +| Monitor el uso del comando | `sudo datadog-agent --help` | +| Ejecute una verificación | `sudo -u dd-agent -- datadog-agent check ` | -**Nota**: Para sistemas basados en upstart, como `CentOS/RHEL 6` o `SUSE 11`, intercambie `systemctl ` con ``. Por ejemplo, al iniciar un Agente como un servicio en un sistema `SUSE 11`, use `sudo start datadog-agent`. +**Nota**: Para sistemas basados en upstart, como `CentOS/RHEL 6` o `SUSE 11`, intercambie `systemctl ` con ``. Por ejemplo, al iniciar un Agent como servicio en un sistema `SUSE 11`, use `sudo start datadog-agent`. -## Desinstalar el Agente {#uninstall-the-agent} +## Desinstale el Agent {#uninstall-the-agent} -Para desinstalar el Agente, ejecute el comando para el entorno de Linux correspondiente: +Para desinstalar el Agent, ejecute el comando para el entorno de Linux correspondiente: ### Para CentOS, Rocky, AlmaLinux, Amazon Linux, Oracle Linux y Red Hat {#for-centos-rocky-almalinux-amazon-linux-oracle-linux-and-red-hat} @@ -108,14 +108,14 @@ sudo zypper remove datadog-agent
-**Los comandos anteriores eliminan el Agente, pero no eliminan**: +**Los comandos anteriores eliminan el Agent, pero no eliminan**: * El archivo de configuración `datadog.yaml` * Archivos creados por el usuario en la carpeta de configuración `/etc/datadog-agent` * Archivos creados por el usuario en la carpeta `/opt/datadog-agent` * El usuario `dd-agent` * Archivos de registro de Datadog -**Para eliminar estos elementos, ejecute este comando después de eliminar el Agente:** +**Para eliminar estos elementos, ejecute este comando después de eliminar el Agent:** ```shell sudo userdel dd-agent \ @@ -124,7 +124,7 @@ sudo userdel dd-agent \ && sudo rm -rf /var/log/datadog/ ``` -Para desinstalar los artefactos restantes del Agente para `Debian` y `Ubuntu`, ejecute: +Para desinstalar los artefactos restantes del Agent para `Debian` y `Ubuntu` ejecute: ```shell sudo apt-get remove --purge datadog-agent -y @@ -133,22 +133,22 @@ sudo apt-get remove --purge datadog-agent -y
-### Desinstalar Instrumentación APM de Un Solo Paso {#uninstall-single-step-apm-instrumentation} -Si instaló el Agente con Instrumentación APM de Un Solo Paso y desea desinstalarlo, necesita [ejecutar comandos adicionales][9] para eliminar la Instrumentación APM. Siga los pasos para su [entorno específico][10]. +### Desinstalar la instrumentación de APM de un solo paso {#uninstall-single-step-apm-instrumentation} +Si instaló el Agent con la instrumentación de APM de un solo paso y desea desinstalarlo, debe [ejecutar comandos adicionales][9] para eliminar la instrumentación de APM. Siga los pasos para su [entorno específico][10]. -## Solución de Problemas {#troubleshooting} +## Solución de problemas {#troubleshooting} -Para pasos detallados, consulte [Solución de Problemas del Agente][2]. +Para conocer los pasos detallados, consulte [Solución de problemas del Agent][2]. -## Trabajando con el agente embebido {#working-with-the-embedded-agent} +## Trabajar con el Agent integrado {#working-with-the-embedded-agent} -El Agente contiene un entorno de Python embebido en `/opt/datadog-agent/embedded/`. Los binarios comunes como `python` y `pip` están contenidos dentro de `/opt/datadog-agent/embedded/bin/`. +El Agent contiene un entorno de Python integrado en `/opt/datadog-agent/embedded/`. Los binarios comunes como `python` y `pip` se encuentran dentro de `/opt/datadog-agent/embedded/bin/`. -Consulte las instrucciones sobre cómo [agregar paquetes al agente embebido][3] para más información. +Consulte las instrucciones sobre cómo [agregar paquetes al Agent integrado][3] para obtener más información. -## Lectura adicional {#further-reading} +## Lecturas adicionales {#further-reading} {{< partial name="whats-next/whats-next.html" >}} @@ -161,4 +161,5 @@ Consulte las instrucciones sobre cómo [agregar paquetes al agente embebido][3] [7]: https://app.datadoghq.com/organization-settings/api-keys [8]: https://docs.datadoghq.com/es/agent/configuration/proxy/ [9]: /es/tracing/trace_collection/automatic_instrumentation/single-step-apm/ -[10]: /es/tracing/trace_collection/automatic_instrumentation/single-step-apm/linux \ No newline at end of file +[10]: /es/tracing/trace_collection/automatic_instrumentation/single-step-apm/linux +[11]: https://github.com/DataDog/datadog-agent/blob/main/pkg/config/example/datadog-agent_linux.yaml.example \ No newline at end of file diff --git a/hugo/content/es/api/latest/agent-observability/get-an-agent-observability-prompt/index.md b/hugo/content/es/api/latest/agent-observability/get-an-agent-observability-prompt/index.md new file mode 100644 index 00000000000..f75c25ea7d3 --- /dev/null +++ b/hugo/content/es/api/latest/agent-observability/get-an-agent-observability-prompt/index.md @@ -0,0 +1,3 @@ +--- +title: Obtenga un prompt de Agent Observability +--- diff --git a/hugo/content/es/api/latest/agent-observability/get-annotation-queue-label-schema/index.md b/hugo/content/es/api/latest/agent-observability/get-annotation-queue-label-schema/index.md new file mode 100644 index 00000000000..44b9d848e25 --- /dev/null +++ b/hugo/content/es/api/latest/agent-observability/get-annotation-queue-label-schema/index.md @@ -0,0 +1,3 @@ +--- +title: Obtener el esquema de etiquetas de la cola de anotaciones +--- diff --git a/hugo/content/es/api/latest/agent-observability/list-versions-of-an-agent-observability-prompt/index.md b/hugo/content/es/api/latest/agent-observability/list-versions-of-an-agent-observability-prompt/index.md new file mode 100644 index 00000000000..338452986ab --- /dev/null +++ b/hugo/content/es/api/latest/agent-observability/list-versions-of-an-agent-observability-prompt/index.md @@ -0,0 +1,3 @@ +--- +title: Listar versiones de un prompt de Agent Observability +--- diff --git a/hugo/content/es/api/latest/data-deletion/cancels-a-data-deletion-request/index.md b/hugo/content/es/api/latest/data-deletion/cancels-a-data-deletion-request/index.md new file mode 100644 index 00000000000..bd1c63a4975 --- /dev/null +++ b/hugo/content/es/api/latest/data-deletion/cancels-a-data-deletion-request/index.md @@ -0,0 +1,3 @@ +--- +title: Cancele una solicitud de eliminación de datos +--- diff --git a/hugo/content/es/api/latest/execution-policy/get-an-execution-policy/index.md b/hugo/content/es/api/latest/execution-policy/get-an-execution-policy/index.md new file mode 100644 index 00000000000..f9533976651 --- /dev/null +++ b/hugo/content/es/api/latest/execution-policy/get-an-execution-policy/index.md @@ -0,0 +1,3 @@ +--- +title: Obtener una política de ejecución +--- diff --git a/hugo/content/es/api/latest/product-analytics/list-the-entities-behind-a-retention-cell/index.md b/hugo/content/es/api/latest/product-analytics/list-the-entities-behind-a-retention-cell/index.md new file mode 100644 index 00000000000..7204bade354 --- /dev/null +++ b/hugo/content/es/api/latest/product-analytics/list-the-entities-behind-a-retention-cell/index.md @@ -0,0 +1,3 @@ +--- +title: Utilice la función listar para ver las entidades detrás de una celda de retención +--- diff --git a/hugo/content/es/api/latest/tag-rules/create-a-tag-rule/index.md b/hugo/content/es/api/latest/tag-rules/create-a-tag-rule/index.md new file mode 100644 index 00000000000..18604b50511 --- /dev/null +++ b/hugo/content/es/api/latest/tag-rules/create-a-tag-rule/index.md @@ -0,0 +1,3 @@ +--- +title: Crear una regla de etiqueta +--- diff --git a/hugo/content/es/bits_ai/bits_investigation/chat_bits_investigation.md b/hugo/content/es/bits_ai/bits_investigation/chat_bits_investigation.md new file mode 100644 index 00000000000..2847c6a68f9 --- /dev/null +++ b/hugo/content/es/bits_ai/bits_investigation/chat_bits_investigation.md @@ -0,0 +1,34 @@ +--- +aliases: +- /es/bits_ai/bits_ai_sre/chat_bits_ai_sre/ +title: Chatear con Bits Investigation +--- +Dentro de una investigación, puede chatear con Bits para recopilar información adicional sobre la investigación, la telemetría relacionada y más. + +{{< img src="bits_ai/bits_ai_sre_chat_example.png" alt="Ejemplo de chat donde un usuario le pregunta a Bits AI sobre incidentes relacionados en curso, y Bits AI responde con una lista de incidentes relacionados y una explicación de qué los hace relacionados" style="width:100%;" >}} + +## Fuentes de datos {#data-sources} + +El Bits Investigation chatbot tiene acceso a: +- **Detalles de la investigación**: Detalles sobre la alerta del monitor, las consultas exploratorias que se ejecutaron, las hipótesis y sus evaluaciones, y la conclusión sobre la causa raíz +- **Telemetría**: Detalles sobre métricas, registros, trazas, eventos, monitores, eventos RUM, tableros, Notebooks y hosts +- **Incidentes**: Detalles sobre los incidentes y su estado, gravedad y más +- **Servicios**: Servicios en el Catálogo con sus dependencias, propietarios y más +- **Documentación de Datadog**: Información documentada del producto Datadog +- **Documentación de Confluence**: Documentación o runbooks relevantes de su documentación de Confluence (si la [integración de Confluence está configurada para habilitar el rastreo de cuentas][1]) + +## Ejemplos de preguntas {#example-questions} + +| Funcionalidad | Ejemplo de prompt | Fuente de datos | +|------------------------------------------------|-------------------------------------------------------------------|-----------------------------------| +| Pedir aclaraciones sobre los detalles de la investigación | `Why do you think there's database query slowness?` | Detalles de Bits Investigation | +| Pedir explicaciones sobre los hallazgos de la investigación | `Tell me more about the increased 500s on .` | Detalles de Bits Investigation | +| Aprender a hacer que Bits funcione mejor | `How can I make the investigation more effective next time?` | Detalles de Bits Investigation | +| Buscar información sobre un servicio | `Are there any ongoing incidents for ?` | Catálogo e incidentes | +| Encontrar cambios recientes para un servicio | `Were there any recent changes on ?` | Change Tracking | +| Consultar métricas de solicitudes, errores y duración de APM | `What's the current error rate for ?` | APM | +| Consultar y analizar datos de perfilado | `What performance bottlenecks do you see for ?` | Continuous Profiler | +| Preguntar sobre los productos de Datadog | `Does Bits Investigation connect to Datadog Work Management?` | Documentación de Datadog | +| Crear un Notebook | `Can you create a notebook with a summary of this investigation?` | Notebooks | + +[1]: bits_ai/bits_investigation/configure#confluence \ No newline at end of file diff --git a/hugo/content/es/dashboards/widgets/funnel.md b/hugo/content/es/dashboards/widgets/funnel.md index 32ebc120aff..9a2a549e3c3 100644 --- a/hugo/content/es/dashboards/widgets/funnel.md +++ b/hugo/content/es/dashboards/widgets/funnel.md @@ -1,46 +1,47 @@ --- aliases: - /es/graphing/widgets/funnel/ +description: Realice un seguimiento de las tasas de conversión e identifique cuellos + de botella en los flujos de trabajo de usuario con la visualización de análisis + de embudo. further_reading: - link: https://docs.datadoghq.com/product_analytics/journeys/funnel_analysis/ tag: Documentación - text: Más información sobre el análisis de embudos + text: Más información sobre Funnel Analysis - link: https://www.datadoghq.com/blog/reduce-customer-friction-funnel-analysis/ tag: Blog - text: Utilizar el análisis del embudo para comprender y optimizar los flujos de - usuarios clave -title: Widget embudo -widget_type: embudo + text: Utilice Funnel Analysis para comprender y optimizar los flujos clave de usuario +title: Funnel Widget +widget_type: funnel --- +Funnel Analysis le ayuda a realizar un seguimiento de las tasas de conversión en flujos de trabajo clave para identificar y abordar cualquier cuello de botella en las rutas de recorrido de extremo a extremo de los usuarios. Funnel Widget visualiza las tasas de conversión en los flujos de trabajo de usuario y en las rutas de recorrido de extremo a extremo. -El análisis del embudo te ayuda a realizar un seguimiento de las tasas de conversión en los flujos de trabajo clave para identificar y abordar los cuellos de botella en los recorridos de usuario de extremo a extremo. El widget embudo visualiza las tasas de conversión en los flujos de trabajo de los usuarios y en los recorridos integrales de los usuarios. +{{< img src="dashboards/widgets/funnel/funnel.png" alt="Funnel Widget que visualiza las tasas de abandono de un usuario en un sitio de comercio electrónico" >}} -{{< img src="dashboards/widgets/funnel/funnel.png" alt="Widget embudo que visualiza las tasas de abandono de un usuario en un sitio de comercio electrónico" >}} +## Configuración {#setup} -## Configuración +{{< img src="dashboards/widgets/funnel/funnel_setup.png" alt="Pantalla de configuración de Funnel Widget" >}} -{{< img src="dashboards/widgets/funnel/funnel_setup.png" alt="Pantalla de configuración del widget embudo" >}} +### Configuración {#configuration} -### Configuración +1. Elija los datos para graficar: + * RUM: Consulte la [documentación de búsqueda de eventos RUM][1] para configurar una consulta RUM. +2. Seleccione {{< ui >}}View{{< /ui >}} o {{< ui >}}Action{{< /ui >}} y elija una consulta del menú desplegable. +3. Haga clic en el botón {{< ui >}}\+{{< /ui >}} y seleccione otra consulta del menú desplegable para visualizar el embudo. Consulte la [documentación de visualización de RUM][2] para obtener más información sobre cómo visualizar Funnel Analysis. -1. Elige los datos para los que crear gráficas: - * RUM: consulta la [Search RUM Events documentation (búsqueda de documentación de eventos RUM)][1] para configurar una consulta RUM. -2. Selecciona **View** (Ver) o **Action** (Acción) y elige una consulta en el menú desplegable. -3. Haz clic en el botón **+** y selecciona otra consulta del menú desplegable para visualizar el embudo. Consulta la [RUM Visualize documentation (documentación de visualización de RUM)][2] para obtener más información sobre la visualización del análisis del embudo. +### Opciones {#options} -### Opciones +#### Tiempo global {#global-time} -#### Hora mundial +En los tableros y cuadernos, elija si su widget tiene un marco de tiempo personalizado o utiliza el marco de tiempo global. -En los screenboards y notebooks, elige si tu widget tiene un marco temporal personalizado o utiliza el marco temporal global. +## API {#api} -## API - -Este widget puede utilizarse con la [Dashboards API (API de dashboards)][3]. Ve la siguiente tabla para la [widget JSON schema definition (definición del esquema de widget JSON)][4]: +Funnel Widget se puede utilizar con la [Dashboards API][3]. Consulte la siguiente tabla para ver la [definición del esquema JSON del widget][4]: {{< dashboards-widgets-api >}} -## Leer más +## Lecturas adicionales {#further-reading} {{< partial name="whats-next/whats-next.html" >}} diff --git a/hugo/content/es/data_observability/quality_monitoring/business_intelligence/hex.md b/hugo/content/es/data_observability/quality_monitoring/business_intelligence/hex.md new file mode 100644 index 00000000000..76041da1e52 --- /dev/null +++ b/hugo/content/es/data_observability/quality_monitoring/business_intelligence/hex.md @@ -0,0 +1,21 @@ +--- +description: Integración de Hex para el linaje de Data Observability. Consulte la + documentación de integración para la configuración. +further_reading: +- link: /data_observability/ + tag: Documentación + text: Obtenga más información sobre Data Observability +title: Hex +--- +La integración de Hex de Datadog ayuda a los equipos de datos a visualizar el linaje de extremo a extremo entre las tablas del almacén de datos y los proyectos de Hex. + +El linaje se deriva de su data warehouse, por lo que también necesita al menos un [supported data warehouse destination][2] conectado a Datadog. + +Consulte la documentación de la [integración de Hex][1] para el setup y la configuración. + +## Lecturas adicionales {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /es/integrations/hex/ +[2]: /es/data_observability/quality_monitoring/data_warehouses/ \ No newline at end of file diff --git a/hugo/content/es/delivery_performance/dora_metrics/_index.md b/hugo/content/es/delivery_performance/dora_metrics/_index.md new file mode 100644 index 00000000000..e4ac01c1f46 --- /dev/null +++ b/hugo/content/es/delivery_performance/dora_metrics/_index.md @@ -0,0 +1,106 @@ +--- +aliases: +- /es/continuous_integration/dora_metrics +- /es/dora_metrics/ +description: Aprenda a utilizar las métricas DORA para medir y mejorar los procesos + de Software Delivery de su organización. +further_reading: +- link: /delivery_performance/dora_metrics/calculation/ + tag: Documentación + text: Aprenda cómo Datadog calcula las métricas DORA. +- link: /continuous_delivery/deployments + tag: Documentación + text: Aprenda sobre Deployment Visibility +- link: /events + tag: Documentación + text: Aprenda sobre Event Management +- link: /monitors/types/metric + tag: Documentación + text: Aprenda sobre los monitores de métricas +- link: /catalog + tag: Documentación + text: Aprenda sobre el catálogo +- link: https://www.datadoghq.com/blog/platform-engineering-metrics/ + tag: Blog + text: Métricas de éxito para Platform Engineering Teams. +- link: https://www.datadoghq.com/blog/dora-metrics-software-delivery/ + tag: Blog + text: Mejores prácticas para utilizar las métricas DORA para mejorar Software Delivery. +- link: https://www.datadoghq.com/blog/datadog-dora-metrics/ + tag: Blog + text: 3 formas de impulsar el éxito en Software Delivery con Datadog DORA Metrics. +- link: https://www.datadoghq.com/blog/devsecops-2026-study-learnings + tag: Blog + text: Aprendizajes clave del estudio State of DevSecOps 2026 +- link: https://app.datadoghq.com/release-notes?category=Software%20Delivery + tag: Notas de la versión + text: ¡Consulte las últimas versiones de Software Delivery! (Se requiere inicio + de sesión en la aplicación). +is_beta: true +title: DORA Metrics +--- +## Descripción general {#overview} + +Las métricas de DevOps Research and Assessment (DORA) son [cuatro métricas clave][1] que indican la velocidad y la estabilidad del desarrollo de software. + +Frecuencia de despliegue +: Con qué frecuencia una organización realiza despliegues exitosos a producción. + +Tiempo de entrega de cambios +: La cantidad de tiempo que le toma a una confirmación llegar a producción. + +Tasa de fallos en cambios +: La proporción de despliegues que fallan y requieren intervención inmediata. + +Tiempo de recuperación de despliegues fallidos +: El tiempo que toma recuperarse de un despliegue que falla y requiere intervención inmediata. + +Definir y realizar un seguimiento de las métricas DORA puede ayudarle a identificar áreas de mejora en la velocidad y la calidad de Software Delivery de su equipo u organización. + +## Configure DORA Metrics {#set-up-dora-metrics} + +Para comenzar a configurar las fuentes de datos para enviar eventos de despliegue a Datadog, consulte la [documentación de configuración][2]. + +## Analice DORA Metrics {#analyze-dora-metrics} + +Después de configurar las fuentes de datos para sus eventos de despliegue, navegue a [{{< ui >}}Software Delivery{{< /ui >}} > {{< ui >}}Delivery Performance{{< /ui >}} > {{< ui >}}DORA Metrics{{< /ui >}}][4] para identificar mejoras o regresiones para cada métrica. También puede agregar las métricas por equipo, servicio, repositorio, entorno, período de tiempo y [etiquetas personalizadas][8] para comparar tendencias a lo largo del tiempo. + +{{< img src="delivery_performance/dora_metrics/dora_ui_3.png" alt="Una descripción general de los cálculos de DORA Metrics filtrados por la etiqueta personalizada de idioma" style="width:100%;" >}} + +Haga clic en {{< ui >}}View Deployments{{< /ui >}} para abrir una nueva pestaña con la lista de eventos de despliegue. + +{{< img src="delivery_performance/dora_metrics/deployments_list.png" alt="El desglose de despliegues que muestra un desglose de las métricas y una lista de eventos relacionados" style="width:100%;" >}} + +Haga clic en {{< ui >}}View Change Failures{{< /ui >}} para abrir un panel lateral con la lista de eventos de despliegue marcados como fallos de cambio. + +{{< img src="delivery_performance/dora_metrics/change_failures_list.png" alt="El desglose de fallos de cambio que muestra un desglose de las métricas y una lista de eventos relacionados" style="width:100%;" >}} + +## Utilice los datos de DORA Metrics {#use-dora-metrics-data} + +### Exporte los widgets de DORA Metrics {#export-dora-metrics-widgets} +Exporte sus widgets de visualización a Dashboards o notebooks. + +Haga clic en el icono {{< ui >}}Export{{< /ui >}} en cualquier visualización para añadirla a un Dashboard o notebook. Para obtener más información sobre las métricas calculadas por DORA Metrics, consulte la [documentación de datos recopilados][3]. + +### Cree Dashboards personalizados {#create-custom-dashboards} + +Cree Dashboards personalizados utilizando DORA Metrics para analizar su flujo de trabajo de extremo a extremo, desde los commits y pull requests hasta los despliegues en producción. Por ejemplo, compare el rendimiento de la revisión de código entre Teams para identificar qué Teams están bloqueados por aprobaciones lentas y priorice dónde invertir en mejoras del flujo de trabajo. + +{{< img src="delivery_performance/dora_metrics/dashboard.png" alt="Un ejemplo de un Dashboard de DORA Metrics personalizado" style="width:100%;" >}} + +Dentro de los Dashboards y gráficos, las etiquetas personalizadas se tratan como [atributos][7]. Para filtrar o agrupar por una etiqueta personalizada, debe tener el prefijo de un símbolo `@`. + +{{< img src="delivery_performance/dora_metrics/graph_with_custom_tag.png" alt="Un ejemplo de un gráfico de DORA Metrics personalizado agrupado por una etiqueta personalizada" style="width:100%;" >}} + +## Lecturas adicionales {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://www.datadoghq.com/knowledge-center/dora-metrics/ +[2]: /es/delivery_performance/dora_metrics/setup/ +[3]: /es/delivery_performance/dora_metrics/data_collected/ +[4]: https://app.datadoghq.com/ci/dora +[5]: /es/monitors/types/metric/?tab=threshold +[6]: /es/monitors/ +[7]: /es/dashboards/guide/quick-graphs/#graphing-events +[8]: /es/delivery_performance/dora_metrics/data_collected/#custom-tags \ No newline at end of file diff --git a/hugo/content/es/deployment_gates/setup/preconfigured.md b/hugo/content/es/deployment_gates/setup/preconfigured.md new file mode 100644 index 00000000000..196d81d5024 --- /dev/null +++ b/hugo/content/es/deployment_gates/setup/preconfigured.md @@ -0,0 +1,579 @@ +--- +description: Cree gates y reglas en Datadog con antelación y, a continuación, haga + referencia a ellos por servicio y entorno en el momento de la implementación. +further_reading: +- link: /deployment_gates/setup/jit + tag: Documentación + text: Configure Just-In-Time (JIT) Deployment Gates +- link: /deployment_gates/explore + tag: Documentación + text: Obtenga información sobre el Deployment Gates explorer. +- link: /api/latest/deployment-gates + tag: Referencia de la API + text: Referencia de la API de Deployment Gates. +title: Configure Deployment Gates preconfigurados +--- +{{< callout url="http://datadoghq.com/product-preview/deployment-gates" >}} +Deployment Gates están en vista previa. Si le interesa esta función, complete el formulario para solicitar acceso. +{{< /callout >}} + +Con **Deployment Gates** preconfigurados, los gates y reglas se conservan en Datadog y se hace referencia a ellos por servicio y entorno en el momento de la evaluación. Los gates preconfigurados son una buena opción cuando desea compartir reglas entre muchas implementaciones, administrar la configuración en Terraform o permitir que usuarios que no son de CI editen reglas en la interfaz de usuario de Datadog. + +¿Busca definir reglas en línea en su configuración de implementación? Consulte [Just-In-Time (JIT) Deployment Gates][5]. + +## Cree una puerta {#create-a-gate} + +
Además de usar la interfaz de usuario de Deployment Gates, puede administrar gates y reglas mediante programación con la API de Deployment Gates o el proveedor de Terraform de Datadog.
+ +1. Vaya a [{{< ui >}}Software Delivery{{< /ui >}} > {{< ui >}}Deployment Gates{{< /ui >}} > {{< ui >}}Configuration{{< /ui >}}][6]. +2. Haga clic en {{< ui >}}Create Gate{{< /ui >}}. +3. Configure los siguientes ajustes: + - {{< ui >}}Service{{< /ui >}}: El nombre del servicio (ejemplo: `transaction-backend`). + - {{< ui >}}Environment{{< /ui >}}: El entorno de destino (ejemplo: `dev`). + - {{< ui >}}Identifier{{< /ui >}} (opcional, el valor predeterminado es `default`): Nombre único para varias puertas en el mismo servicio/entorno. Utilice esto para: + - Permitir diferentes estrategias de implementación (ejemplo: `fast-deploy` frente a `default`) + - Distinguir fases de implementación (ejemplo: `pre-deploy` frente a `post-deploy`) + - Definir etapas canary (ejemplo: `pre-deploy` frente a `canary-20pct`) + - {{< ui >}}Evaluation Mode{{< /ui >}}: Habilite {{< ui >}}Dry Run{{< /ui >}} para probar el comportamiento de la puerta sin afectar las implementaciones. La evaluación de una puerta de prueba (dry-run) siempre responde con un estado de aprobación, pero el resultado en la aplicación refleja la evaluación real. Esto es útil al realizar una evaluación inicial del comportamiento de la puerta sin afectar la canalización de implementación. + +## Agregar reglas a una puerta {#add-rules-to-a-gate} + +Cada puerta requiere una o más reglas para evaluar. Todas las reglas deben aprobarse para que la puerta tenga éxito. Para cada regla, especifique: + +1. {{< ui >}}Name{{< /ui >}}: Una etiqueta descriptiva que aparece en la página [Evaluaciones de Deployment Gates][7] (por ejemplo, `Check all P0 monitors`). +2. {{< ui >}}Type{{< /ui >}}: Seleccione {{< ui >}}Monitor{{< /ui >}} o {{< ui >}}Faulty Deployment Detection{{< /ui >}}. +3. Configuración adicional basada en el tipo de regla seleccionado. Consulte [Tipos de reglas](#rule-types) para ver las opciones disponibles. +4. {{< ui >}}Evaluation Mode{{< /ui >}}: Cuando una regla se establece como {{< ui >}}Dry Run{{< /ui >}}, su resultado no se tiene en cuenta al calcular el resultado general de la puerta. + +## Tipos de regla {#rule-types} + +Para ver el esquema completo y todas las opciones disponibles, consulte la [Deployment Gates API reference][4]. + +{{< tabs >}} +{{% tab "Seguimiento" %}} +La regla de seguimiento evalúa el estado de un conjunto de seguimientos durante un período de tiempo configurable. Falla si en cualquier momento durante el período de evaluación: + +- Ningún seguimiento coincide con la consulta. +- Más de 50 seguimientos coinciden con la consulta. +- Cualquier seguimiento coincidente está en estado `ALERT` o `NO_DATA`. + +##### Configuración de ajustes {#configuration-settings} + +- {{< ui >}}Search Query{{< /ui >}}: La consulta utilizada para encontrar los monitors a evaluar, según la [Sintaxis de búsqueda de Monitor][1]. Filtrar por etiquetas de seguimiento: + - Etiquetas estáticas de seguimiento: `service:transaction-backend` + - Etiquetas dentro de la consulta de seguimiento: `scope:"service:transaction-backend"` + - Etiquetas dentro de una [agrupación de seguimientos][2]: `group:"service:transaction-backend"` +- {{< ui >}}Duration{{< /ui >}}: El período de tiempo (en segundos) durante el cual se evalúan los monitors coincidentes. El valor predeterminado es 0 (los seguimientos se evalúan al instante). El máximo es 7200 segundos (2 horas). + +##### Ejemplos de consultas {#example-queries} + +- `env:prod service:transaction-backend` +- `env:prod (service:transaction-backend OR group:"service:transaction-backend" OR scope:"service:transaction-backend")` +- `tag:"use_deployment_gates" team:payment` +- `tag:"use_deployment_gates" AND (NOT group:("team:frontend"))` + +**Notas**: +- `group` los filtros evalúan solo los grupos coincidentes. +- Los seguimientos silenciados se excluyen automáticamente de la evaluación (la consulta siempre incluye `muted:false`). + +[1]: /es/monitors/manage/search/ +[2]: /es/monitors/manage/#triggered-monitors +{{% /tab %}} +{{% tab "APM Faulty Deployment Detection" %}} +Este tipo de regla utiliza el análisis de [APM Faulty Deployment Detection][1] de Watchdog para comparar la versión desplegada con versiones anteriores del mismo servicio. El análisis detecta: + +- Nuevos tipos de errores. +- Aumentos significativos en las tasas de error en comparación con versiones anteriores. + +El análisis se realiza automáticamente para todos los servicios instrumentados con APM y no se requiere configuración previa. + +##### Configuración de ajustes {#configuration-settings-1} + +- {{< ui >}}Operation Name{{< /ui >}}: Se completa automáticamente a partir de la configuración de [operación principal de APM][3] del servicio. +- {{< ui >}}Duration{{< /ui >}}: El período de tiempo (en segundos) durante el cual se ejecuta el análisis. Para una confianza de análisis óptima, este valor debe ser de al menos 900 segundos (15 minutos) después de que comience una implementación. El máximo es 7200 segundos (2 horas). +- {{< ui >}}Allowed Resources{{< /ui >}} (opcional): Una lista de [recursos de APM][2] separados por comas para incluir en el análisis. Cuando se especifica, solo se analizan los recursos enumerados. Mutualmente excluyente con {{< ui >}}Excluded Resources{{< /ui >}}. +- {{< ui >}}Excluded Resources{{< /ui >}} (opcional): Una lista de [recursos de APM][2] separados por comas a ignorar (como endpoints de bajo volumen o baja prioridad). Mutualmente excluyente con {{< ui >}}Allowed Resources{{< /ui >}}. + +**Notas**: +- La regla se evalúa para cada valor de [etiqueta principal adicional][4], así como para un análisis agregado. Para considerar solo una etiqueta principal, especifíquela al [solicitar una evaluación de puerta](#evaluate-a-gate-from-your-pipeline). +- Se detectan nuevos errores y aumentos en la tasa de errores a nivel de recurso. +- Este tipo de regla no admite servicios marcados como `database` o `inferred service`. + +[1]: /es/watchdog/faulty_deployment_detection/ +[2]: /es/tracing/services/resource_page/ +[3]: /es/tracing/guide/configuring-primary-operation/#primary-operations +[4]: /es/tracing/guide/setting_primary_tags_to_scope/?tab=helm#add-additional-primary-tags-in-datadog +{{% /tab %}} +{{< /tabs >}} + +## Evalúe un Deployment Gate desde su canalización {#evaluate-a-gate-from-your-pipeline} + +Una vez configurada la puerta, solicite una evaluación al implementar el servicio relacionado y decida si bloquear o continuar la implementación según el resultado. + +{{< tabs >}} +{{% tab "CLI de datadog-ci" %}} +El comando `deployment gate` de [datadog-ci][1] ejecuta la evaluación en un solo comando: + +```bash +datadog-ci deployment gate --service transaction-backend --env staging --identifier default +``` + +Si la puerta de implementación contiene reglas de detección de implementaciones defectuosas de APM, especifique también la versión (por ejemplo, `--version 1.0.1`). + +El comando: + +- Envía una solicitud para iniciar la evaluación de Deployment Gate y se bloquea hasta que se complete la evaluación. +- Proporciona un tiempo de espera configurable para cuánto tiempo esperar una evaluación. +- Tiene reintentos automáticos integrados para errores. +- Acepta `--fail-on-error` para personalizar el comportamiento ante errores inesperados de Datadog. + +El comando `deployment gate` está disponible en las versiones v3.17.0 y superiores de datadog-ci. + +**Variables de entorno requeridas**: + +- `DD_API_KEY`: Su [clave de API][2]. +- `DD_APP_KEY`: Su [clave de aplicación][3]. +- `DD_BETA_COMMANDS_ENABLED=1`: El comando `deployment gate` es un comando en versión beta. + +Para obtener opciones de configuración completas y ejemplos de uso, consulte la [documentación del comando `deployment gate`][4]. + +[1]: https://github.com/DataDog/datadog-ci +[2]: https://app.datadoghq.com/organization-settings/api-keys +[3]: https://app.datadoghq.com/organization-settings/application-keys +[4]: https://github.com/DataDog/datadog-ci/tree/master/packages/plugin-deployment#gate + +{{% /tab %}} +{{% tab "Argo Rollouts" %}} +Llame a Deployment Gates desde un recurso de Kubernetes de Argo Rollouts creando un [AnalysisTemplate][1] o un [ClusterAnalysisTemplate][1]. La plantilla ejecuta el [comando deployment gate de datadog-ci][7] para interactuar con la API de Deployment Gates. + +Utilice la siguiente plantilla como punto de partida: + +- Reemplace `` con su [nombre del sitio de Datadog][2] (por ejemplo, {{< region-param key="dd_site" code="true" >}}). +- Defina la [clave de API][5] y la [clave de aplicación][6] como variables de entorno. El ejemplo utiliza un [Kubernetes Secret][3] llamado `datadog` con dos valores de datos: `api-key` y `app-key`. También puede pasar los valores en texto plano con `value` en lugar de `valueFrom`. + +```yaml +apiVersion: argoproj.io/v1alpha1 +kind: ClusterAnalysisTemplate +metadata: + name: datadog-job-analysis +spec: + args: + - name: service + - name: env + metrics: + - name: datadog-job + provider: + job: + spec: + ttlSecondsAfterFinished: 300 + backoffLimit: 0 + template: + spec: + restartPolicy: Never + containers: + - name: datadog-check + image: datadog/ci:v3.17.0 + env: + - name: DD_BETA_COMMANDS_ENABLED + value: "1" + - name: DD_SITE + value: "" + - name: DD_API_KEY + valueFrom: + secretKeyRef: + name: datadog + key: api-key + - name: DD_APP_KEY + valueFrom: + secretKeyRef: + name: datadog + key: app-key + command: ["/bin/sh", "-c"] + args: + - datadog-ci deployment gate --service {{ args.service }} --env {{ args.env }} --identifier default +``` + +- La plantilla de análisis puede recibir argumentos del recurso Rollout (como `service`, `env` y `version`). Para obtener más información, consulte la [documentación oficial de Argo Rollouts][4]. +- `ttlSecondsAfterFinished` elimina los trabajos finalizados después de 5 minutos. +- `backoffLimit` se establece en 0 porque el trabajo no debe reintentarse si la evaluación de Deployment Gate falla. + +Después de crear la plantilla de análisis, haga referencia a ella desde la estrategia de Argo Rollouts: + +```yaml +apiVersion: argoproj.io/v1alpha1 +kind: Rollout +metadata: + name: rollouts-demo + labels: + tags.datadoghq.com/service: transaction-backend + tags.datadoghq.com/env: dev +spec: + replicas: 5 + strategy: + canary: + steps: + ... + - analysis: + templates: + - templateName: datadog-job-analysis + clusterScope: true # Only needed for cluster analysis + args: + - name: env + valueFrom: + fieldRef: + fieldPath: metadata.labels['tags.datadoghq.com/env'] + - name: service + valueFrom: + fieldRef: + fieldPath: metadata.labels['tags.datadoghq.com/service'] + - name: version #Required for APM Faulty Deployment Detection rules + valueFrom: + fieldRef: + fieldPath: metadata.labels['tags.datadoghq.com/version'] + - ... +``` + +[1]: https://argo-rollouts.readthedocs.io/en/stable/features/analysis/#analysis-progressive-delivery +[2]: /es/getting_started/site/ +[3]: https://kubernetes.io/docs/concepts/configuration/secret/ +[4]: https://argo-rollouts.readthedocs.io/en/stable/features/analysis/#analysis-template-arguments +[5]: https://app.datadoghq.com/organization-settings/api-keys +[6]: https://app.datadoghq.com/organization-settings/application-keys +[7]: https://github.com/DataDog/datadog-ci/tree/master/packages/plugin-deployment#gate + +{{% /tab %}} +{{% tab "GitHub Actions" %}} +La [Datadog Deployment Gate GitHub Action][4] ejecuta la evaluación como parte de un flujo de trabajo. + +Agregue un `DataDog/deployment-gate-github-action` paso a su flujo de trabajo de implementación existente: + +```yaml +name: Deploy with Datadog Deployment Gate +on: + push: + branches: [main] +jobs: + deploy: + runs-on: ubuntu-latest + steps: + - name: Deploy Canary + run: | + echo "Deploying canary release for service:'my-service' in 'production'. Version 1.0.1" + # Your deployment commands here + + - name: Evaluate Deployment Gate + uses: DataDog/deployment-gate-github-action@v2.1.0 + env: + DD_API_KEY: ${{ secrets.DD_API_KEY }} + DD_APP_KEY: ${{ secrets.DD_APP_KEY }} + with: + service: my-service + env: production + identifier: default + + - name: Deploy + run: | + echo "Deployment Gate passed, proceeding with deployment" + # Your deployment commands here +``` + +Si la puerta de implementación contiene reglas de detección de implementaciones defectuosas de APM, especifique también la versión (por ejemplo, `version: 1.0.1`). + +La acción: + +- Envía una solicitud para iniciar la evaluación de Deployment Gate y se bloquea hasta que se complete la evaluación. +- Proporciona un tiempo de espera configurable para cuánto tiempo esperar una evaluación. +- Tiene reintentos automáticos integrados para errores. +- Acepta `fail-on-error` para personalizar el comportamiento ante errores inesperados de Datadog. + +**Variables de entorno requeridas**: + +- `DD_API_KEY`: Su [clave de API][2]. +- `DD_APP_KEY`: Su [clave de aplicación][3]. + +Para obtener opciones de configuración completas y ejemplos de uso, consulte el [`DataDog/deployment-gate-github-action` repositorio][4]. + +[1]: https://github.com/DataDog/datadog-ci +[2]: https://app.datadoghq.com/organization-settings/api-keys +[3]: https://app.datadoghq.com/organization-settings/application-keys +[4]: https://github.com/DataDog/deployment-gate-github-action + +{{% /tab %}} +{{% tab "Script genérico" %}} + +Utilice este script como punto de partida. Evalúa una puerta preconfigurada sin reglas en línea. + +Reemplace lo siguiente: + +- ``: Su [nombre de sitio de Datadog][1] (por ejemplo, {{< region-param key="dd_site" code="true" >}}) +- ``: Su [clave de API][2] +- ``: Su [clave de aplicación][3] + +```bash +#!/bin/sh + +# Configuration +MAX_RETRIES=3 +DELAY_SECONDS=5 +POLL_INTERVAL_SECONDS=15 +MAX_POLL_TIME_SECONDS=10800 # 3 hours +API_URL="https://api./api/v2/deployments/gates/evaluation" +API_KEY="" +APP_KEY="" + +PAYLOAD=$(cat <`: Su [nombre de sitio de Datadog][1] (por ejemplo, {{< region-param key="dd_site" code="true" >}}) +- ``: Su [clave de API][2] +- ``: Su [clave de aplicación][3] + +Solicite una evaluación para una puerta que ya existe en Datadog: + +```bash +curl -X POST "https://api./api/v2/deployments/gates/evaluation" \ +-H "Content-Type: application/json" \ +-H "DD-API-KEY: " \ +-H "DD-APPLICATION-KEY: " \ +-d @- << EOF +{ + "data": { + "type": "deployment_gates_evaluation_request", + "attributes": { + "service": "transaction-backend", + "env": "staging", + "identifier": "my-custom-identifier", + "version": "v123-456", + "primary_tag": "region:us-central-1" + } + } +} +EOF +``` + +Atributos opcionales: + +- `identifier`: Opcional, el valor predeterminado es `default`. +- `version`: Requerido para las reglas de Detección de Implementación Defectuosa de APM. +- `primary_tag`: Opcional, limita el análisis de Detección de Implementación Defectuosa de APM a la etiqueta principal seleccionada. + +**Nota**: Una respuesta HTTP 404 puede significar que la puerta no se encontró, o que la puerta se encontró pero no tiene reglas. + +Si la evaluación de la puerta se inició correctamente, se devuelve un código de estado HTTP 202: + +```json +{ + "data": { + "id": "", + "type": "deployment_gates_evaluation_response", + "attributes": { + "evaluation_id": "e9d2f04f-4f4b-494b-86e5-52f03e10c8e9" + } + } +} +``` + +El campo `data.attributes.evaluation_id` contiene el identificador único para esta evaluación de puerta. + +Obtenga el estado de una evaluación de puerta consultando el punto de conexión de estado con el ID de evaluación: + +```bash +curl -X GET "https://api./api/v2/deployments/gates/evaluation/" \ +-H "DD-API-KEY: " \ +-H "DD-APPLICATION-KEY: " +``` + +**Nota**: Si llama a este punto de conexión demasiado pronto después de solicitar la evaluación, es posible que se devuelva una respuesta HTTP 404 porque la evaluación aún no ha comenzado. Vuelva a intentarlo unos segundos después. + +Cuando se devuelve una respuesta HTTP 200, tiene el siguiente formato: + +```json +{ + "data": { + "id": "", + "type": "deployment_gates_evaluation_result_response", + "attributes": { + "dry_run": false, + "evaluation_id": "e9d2f04f-4f4b-494b-86e5-52f03e10c8e9", + "evaluation_url": "https://app.datadoghq.com/ci/deployment-gates/evaluations?index=cdgates&query=level%3Agate+%40evaluation_id%3Ae9d2f14f-4f4b-494b-86e5-52f03e10c8e9", + "gate_id": "e140302e-0cba-40d2-978c-6780647f8f1c", + "gate_status": "pass", + "rules": [ + { + "name": "Check service monitors", + "status": "fail", + "reason": "One or more monitors in ALERT state: https://app.datadoghq.com/monitors/34330981", + "dry_run": true + } + ] + } + } +} +``` + +El campo `data.attributes.gate_status` contiene el resultado de la evaluación, con uno de estos valores: + +- `in_progress`: La evaluación de Deployment Gate aún está en curso; continúe consultando. +- `pass`: La evaluación de Deployment Gate fue aprobada. +- `fail`: La evaluación de Deployment Gate falló. + +**Nota**: Si el campo `data.attributes.dry_run` es `true`, el campo `data.attributes.gate_status` siempre es `pass`. + +[1]: /es/getting_started/site/ +[2]: https://app.datadoghq.com/organization-settings/api-keys +[3]: https://app.datadoghq.com/organization-settings/application-keys + +{{% /tab %}} +{{< /tabs >}} + +## Recomendación para la incorporación por primera vez {#recommendation-for-first-time-onboarding} + +Al integrar Deployment Gates en su flujo de trabajo de Continuous Delivery, una fase de evaluación ayuda a confirmar que el producto funciona como se espera antes de que afecte las implementaciones. Utilice el modo de evaluación de prueba (Dry Run) y la página [{{< ui >}}Deployment Gates Evaluations{{< /ui >}}][7]: + +1. Cree una puerta para un servicio y establezca {{< ui >}}Evaluation Mode{{< /ui >}} en {{< ui >}}Dry Run{{< /ui >}}. +2. Agregue la evaluación de la puerta a su proceso de implementación. Mientras la puerta esté en modo de prueba, la API siempre devuelve `pass` y las implementaciones no se ven afectadas por el resultado de la puerta. +3. Después de un período de tiempo (por ejemplo, 1-2 semanas), realice la verificación de las ejecuciones de la puerta y las reglas en la página {{< ui >}}Deployment Gates Evaluations{{< /ui >}}. La interfaz de usuario muestra el estado real, por lo que puede ver cuándo habría fallado la puerta y la razón detrás de esto. +4. Cuando esté seguro de que el comportamiento de la puerta es el esperado, edite la puerta y cambie el modo de evaluación de {{< ui >}}Dry Run{{< /ui >}} a {{< ui >}}Active{{< /ui >}}. Después, la API comienza a devolver el estado real y las implementaciones comienzan a promoverse o revertirse según el resultado de la puerta. + +## Lecturas adicionales {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /es/getting_started/site/ +[2]: https://app.datadoghq.com/organization-settings/api-keys +[3]: https://app.datadoghq.com/organization-settings/application-keys +[4]: /es/api/latest/deployment-gates +[5]: /es/deployment_gates/setup/jit +[6]: https://app.datadoghq.com/ci/deployment-gates/gates +[7]: https://app.datadoghq.com/ci/deployment-gates/evaluations \ No newline at end of file diff --git a/hugo/content/es/observability_pipelines/destinations/socket.md b/hugo/content/es/observability_pipelines/destinations/socket.md new file mode 100644 index 00000000000..f1771c01cf0 --- /dev/null +++ b/hugo/content/es/observability_pipelines/destinations/socket.md @@ -0,0 +1,72 @@ +--- +description: Aprenda a enviar registros a un punto de conexión de socket usando el + Observability Pipelines Worker. +disable_toc: false +products: +- icon: logs + name: Registros + url: /observability_pipelines/configuration/?tab=logs#pipeline-types +title: Destino de socket +--- +{{< product-availability >}} + +## Descripción general {#overview} + +Utilice el destino de socket de Observability Pipelines para enviar registros a un punto de conexión de socket. + +## Configuración {#setup} + +
Para la gestión de secretos: ingrese únicamente el identificador para la dirección del socket y, si corresponde, el key pass. No ingrese los valores reales.
+ +Configure el destino de socket cuando [configure un pipeline][2]. Puede configurar un pipeline en la [UI][1], utilizando la [API][3] o con [Terraform][4]. Los pasos en esta sección se configuran en la interfaz de usuario. + +Después de seleccionar el destino de socket en la UI del pipeline: + +1. Ingrese el identificador para su dirección. Si lo deja en blanco, se utiliza el [predeterminado](#secret-defaults). +1. En el menú desplegable {{< ui >}}Mode{{< /ui >}}, seleccione el tipo de socket que desea utilizar. +1. En el menú desplegable {{< ui >}}Encoding{{< /ui >}}, seleccione {{< ui >}}JSON{{< /ui >}} o {{< ui >}}Raw message{{< /ui >}} como formato de salida. + +{{% observability_pipelines/secrets_env_var_note %}} + +### Configuración opcional {#optional-settings} + +#### Habilitar TLS {#enable-tls} + +{{% observability_pipelines/tls_settings %}} + +#### Almacenamiento en búfer {#buffering} + +{{% observability_pipelines/destination_buffer %}} + +## Valores predeterminados de Secret {#secret-defaults} + +{{% observability_pipelines/set_secrets_intro %}} + +{{< tabs >}} +{{% tab "Gestión de secretos" %}} + +- Identificador de dirección de socket: + - Hace referencia a la dirección a la que el Observability Pipelines Worker envía los registros procesados. + - El identificador predeterminado es `DESTINATION_SOCKET_ADDRESS`. +- Identificador de frase de contraseña TLS del socket (cuando TLS está habilitado): + - El identificador predeterminado es `DESTINATION_SOCKET_KEY_PASS`. + +{{% /tab %}} + +{{% tab "Variables de entorno" %}} + +{{% observability_pipelines/configure_existing_pipelines/destination_env_vars/socket %}} + +{{% /tab %}} +{{< /tabs >}} + +## Cómo funciona el destino {#how-the-destination-works} + +### Procesamiento por lotes de eventos {#event-batching} + +El destino de socket no agrupa eventos. + +[1]: https://app.datadoghq.com/observability-pipelines +[2]: /es/observability_pipelines/configuration/set_up_pipelines/ +[3]: /es/api/latest/observability-pipelines/ +[4]: https://registry.terraform.io/providers/datadog/datadog/latest/docs/resources/observability_pipeline \ No newline at end of file diff --git a/hugo/content/es/observability_pipelines/packs/aviatrix_suricata_ids_ips.md b/hugo/content/es/observability_pipelines/packs/aviatrix_suricata_ids_ips.md new file mode 100644 index 00000000000..64fb453fa73 --- /dev/null +++ b/hugo/content/es/observability_pipelines/packs/aviatrix_suricata_ids_ips.md @@ -0,0 +1,15 @@ +--- +description: Obtenga más información sobre el paquete IDS/IPS de Aviatrix Suricata. +title: IDS/IPS de Aviatrix Suricata +--- +## Descripción general {#overview} + +{{< img src="observability_pipelines/packs/aviatrix_suricata_ids_ips.png" alt="El paquete IDS/IPS de Aviatrix Suricata" style="width:25%;" >}} + +Las alertas de IDS/IPS de Aviatrix Suricata capturan coincidencias de firmas en el tráfico de red de la puerta de enlace. + +Lo que hace este paquete: + +- Extrae la firma de alerta +- Asigna la gravedad de IDS al estado +- Etiqueta las acciones de bloqueo de IPS \ No newline at end of file diff --git a/hugo/content/es/observability_pipelines/packs/mitre_attack_okta_enrichment.md b/hugo/content/es/observability_pipelines/packs/mitre_attack_okta_enrichment.md new file mode 100644 index 00000000000..adebb849dbc --- /dev/null +++ b/hugo/content/es/observability_pipelines/packs/mitre_attack_okta_enrichment.md @@ -0,0 +1,16 @@ +--- +description: Obtenga más información sobre el paquete de enriquecimiento MITRE ATT&CK + Okta. +title: El enriquecimiento MITRE ATT&CK Okta +--- +## Descripción general {#overview} + +{{< img src="observability_pipelines/packs/mitre_attack_okta_enrichment.png" alt="El paquete de enriquecimiento MITRE ATT&CK Okta" style="width:25%;" >}} + +Este paquete etiqueta los registros de Okta con tácticas y técnicas de MITRE ATT&CK. + +Lo que hace este paquete: + +- Etiqueta eventos con técnicas de MITRE +- Mapea inicios de sesión, MFA y eventos de tokens +- Marca eventos como relevantes para la seguridad \ No newline at end of file diff --git a/hugo/content/es/observability_pipelines/packs/openai_audit_logs.md b/hugo/content/es/observability_pipelines/packs/openai_audit_logs.md new file mode 100644 index 00000000000..01f12977268 --- /dev/null +++ b/hugo/content/es/observability_pipelines/packs/openai_audit_logs.md @@ -0,0 +1,15 @@ +--- +description: Obtenga más información sobre el paquete OpenAI - Audit Logs. +title: OpenAI - Audit Logs +--- +## Descripción general {#overview} + +{{< img src="observability_pipelines/packs/openai_audit_logs.png" alt="El paquete OpenAI - Audit Logs" style="width:25%;" >}} + +Este paquete marca inicios de sesión fallidos, nuevas claves de API y cambios de privilegios de los registros de auditoría de la organización de OpenAI. + +Lo que hace este paquete: + +- Marca inicios de sesión fallidos +- Marca nuevas claves de API +- Marca cambios de roles \ No newline at end of file diff --git a/hugo/content/es/observability_pipelines/processors/add_hostname.md b/hugo/content/es/observability_pipelines/processors/add_hostname.md index c11a4b4857a..e0cf40daa5c 100644 --- a/hugo/content/es/observability_pipelines/processors/add_hostname.md +++ b/hugo/content/es/observability_pipelines/processors/add_hostname.md @@ -1,13 +1,24 @@ --- +description: Aprenda a usar el procesador Add Hostname para agregar un campo con el + nombre del servidor que envió el registro. disable_toc: false products: - icon: logs - name: Logs -title: Añadir procesador de nombres de host + name: Registros + url: /observability_pipelines/configuration/?tab=logs#pipeline-types +title: Add Hostname Processor --- - {{< product-availability >}} -{{% observability_pipelines/processors/add_hostname %}} +## Descripción general {#overview} + +Este procesador agrega un campo con el nombre del servidor que envió el registro. Por ejemplo, `hostname: 613e197f3526`. **Nota**: Si el `hostname` ya existe, el Worker genera un error y no sobrescribe el `hostname` existente. + +## Configuración {#setup} + +Para configurar este procesador: +- Defina un {{< ui >}}filter query{{< /ui >}}. Consulte [Sintaxis de búsqueda de registros][1] para obtener más información. + - Solo se procesan los registros que coinciden con la consulta de filtro especificada. + - Todos los registros, independientemente de si coinciden con la consulta de filtro, se envían al siguiente paso de la canalización. -{{% observability_pipelines/processors/filter_syntax %}} \ No newline at end of file +[1]: /es/observability_pipelines/search_syntax/logs/ \ No newline at end of file diff --git a/hugo/content/es/opentelemetry/setup/ddot_collector/install/kubernetes_standalone.md b/hugo/content/es/opentelemetry/setup/ddot_collector/install/kubernetes_standalone.md new file mode 100644 index 00000000000..f8d8994e9f4 --- /dev/null +++ b/hugo/content/es/opentelemetry/setup/ddot_collector/install/kubernetes_standalone.md @@ -0,0 +1,917 @@ +--- +description: Implemente la distribución independiente de Datadog del Collector de + OpenTelemetry (DDOT) en Kubernetes utilizando el OpenTelemetry Operator o el Helm + chart. +further_reading: +- link: /opentelemetry/setup/ddot_collector/custom_components + tag: Documentación + text: Utilice componentes personalizados de OpenTelemetry en DDOT +title: Instale el Collector DDOT independiente como un DaemonSet de Kubernetes +--- +{{< callout header="false" btn_hidden="true" >}} +La instalación del Collector DDOT independiente con herramientas de OpenTelemetry está en versión preliminar. +{{< /callout >}} + +## Descripción general {#overview} + +Siga esta guía para implementar la distribución de Datadog de OpenTelemetry (DDOT) Collector utilizando el OpenTelemetry Operator o el Helm chart. + +
+ ¿Necesita componentes adicionales de OpenTelemetry? Si necesita componentes más allá de los incluidos en el paquete predeterminado, siga Utilice componentes personalizados de OpenTelemetry para ampliar las capacidades de DDOT. Para obtener una lista de los componentes incluidos de forma predeterminada, consulte Componentes del Collector de OpenTelemetry. +
+ +## Requisitos {#requirements} + +Para completar esta guía, necesita lo siguiente: + +**Cuenta de Datadog**: +1. [Cree una cuenta de Datadog][1] si no tiene una. +1. Busque o cree su [clave de API de Datadog][2]. + +**Software**: +Instale y configure lo siguiente en su máquina: + +- Un clúster de Kubernetes (v1.29+) +- [Helm (v4+)][54] +- [kubectl][5] + +**Red**: +| Protocolo | Transporte | Puerto | +|:---------|:----------|-----:| +| gRPC | TCP | 4317 | +| HTTP | TCP | 4318 | + +## Instale la distribución de Datadog del Collector de OpenTelemetry {#install-the-datadog-distribution-of-the-opentelemetry-collector} + +### Seleccione el método de instalación {#select-installation-method} + +Elija uno de los siguientes métodos de instalación: + +- [Operador de OpenTelemetry][55]: un enfoque [nativo de Kubernetes][56] que reconcilia y mantiene automáticamente su configuración del OTel Collector. +- [Helm chart][4]: una forma sencilla de implementar OTel Collectors. + +{{< tabs >}} +{{% tab "Operador" %}} +### Instale el OpenTelemetry Operator {#install-the-opentelemetry-operator} + +Puede instalar el OpenTelemetry Operator en su clúster utilizando el [OpenTelemetry Operator Helm chart][1]: + +```shell +helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts +helm repo update +helm install opentelemetry-operator open-telemetry/opentelemetry-operator \ + --set "manager.createRbacPermissions=true" \ + --set "manager.collectorImage.repository=datadog/ddot-collector" \ + --set "manager.collectorImage.tag={{< version key="agent_version" >}}" +``` + +{{% site-region region="gov,gov2" %}} +
+Para FED, establezca la etiqueta en {{< version key="agent_version" >}}-fips para usar la imagen DDOT compatible con FIPS. +Consulte cumplimiento de FIPS. +
+{{% /site-region %}} + +[1]: https://github.com/open-telemetry/opentelemetry-helm-charts/blob/main/charts/opentelemetry-operator/README.md +{{% /tab %}} +{{% tab "Helm" %}} +### Agregue el repositorio de Helm de OpenTelemetry {#add-the-opentelemetry-helm-repository} + +Para agregar el repositorio de OpenTelemetry a sus repositorios de Helm: + +```shell +helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts +helm repo update +``` + +{{% /tab %}} +{{< /tabs >}} + +### Configure la clave de API de Datadog {#set-up-datadog-api-key} + +1. Obtenga la [clave de API][2] de Datadog. +1. Confirme que el **DATADOG SITE** seleccionado a la derecha (Valor actual: **{{< region-param key="dd_site_name" >}}**) corresponde a su [DATADOG SITE][52]. +1. Almacene la clave de API como un secreto de Kubernetes: + ```shell + kubectl create secret generic datadog-secret \ + --from-literal api-key= \ + --from-literal site={{< region-param key="dd_site" >}} + ``` + Replace `` with your actual Datadog API key. + +### Configure the OTel Collector + +{{< tabs >}} +{{% tab "Operador" %}} +Después de implementar el OTel Operator, cree el recurso `OpenTelemetryCollector` que activa la implementación del Collector. + +1. Utilice el archivo `node-collector.yaml` para especificar su configuración de daemonset `OpenTelemetryCollector`. + +{{< code-block lang="yaml" filename="node-collector.yaml" collapsible="true" >}} +apiVersion: opentelemetry.io/v1beta1 +kind: OpenTelemetryCollector +metadata: + name: node-collector +spec: + # Deploy 1 instance per node, that will collect telemetry from that node's pods + mode: daemonset + command: ['otel-agent', 'run'] # Will no longer be necessary from 7.82.0 onwards + config: + exporters: + datadog: + api: + key: ${env:DD_API_KEY} + site: ${env:DD_SITE} + sending_queue: + batch: + flush_timeout: 10s + service: + telemetry: + resource: + k8s.cluster.name: ${env:K8S_CLUSTER_NAME} + env: + - name: DD_API_KEY + valueFrom: + secretKeyRef: + key: api-key + name: datadog-apikey + - name: DD_SITE + valueFrom: + secretKeyRef: + key: site + name: datadog-apikey + - name: DD_OTELCOLLECTOR_CONVERTER_FEATURES + value: datadog,pprof,zpages,prometheus,infraattributes + - name: K8S_CLUSTER_NAME + value: + # vvv Will no longer be necessary from 7.83.0 onwards vvv + - name: DD_OTEL_STANDALONE + value: 'true' + # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + # vvv Will no longer be necessary from 7.82.0 onwards vvv + - name: DD_OTELCOLLECTOR_ENABLED + value: 'true' + # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +{{< /code-block >}} + +Reemplace `` con un nombre para su clúster. + +2. Agregue un receptor OTLP y el exportador de Datadog para todas las señales deseadas. Publique los puertos OTLP en el nodo con `hostPort` para que los pods de la aplicación puedan llegar a la instancia del Collector que se ejecuta en el mismo nodo: + +{{< code-block lang="yaml" filename="node-collector.yaml" collapsible="true" >}} +# [...] +spec: + # [...] + # Publish the OTLP ports on the node's network interface + ports: + - name: otlp-grpc + port: 4317 + protocol: TCP + hostPort: 4317 + - name: otlp-http + port: 4318 + protocol: TCP + hostPort: 4318 + config: + receivers: + otlp: + protocols: + grpc: + endpoint: 0.0.0.0:4317 + http: + endpoint: 0.0.0.0:4318 + # [...] + service: + # [...] + pipelines: + logs: + receivers: ['otlp'] + exporters: ['datadog'] + metrics: + receivers: ['otlp'] + exporters: ['datadog'] + traces: + receivers: ['otlp'] + exporters: ['datadog'] +{{< /code-block >}} + +3. (Opcional) Habilite funciones adicionales: + +
Habilitar estas funciones puede generar cargos adicionales. Revise la página de precios y hable con su Gerente de Éxito del Cliente antes de continuar.
+ +{{< code-block lang="yaml" filename="node-collector.yaml" collapsible="true" >}} +spec: + config: + receivers: + host_metrics: + collection_interval: 15s + scrapers: + cpu: {} + load: {} + memory: {} + network: {} + disk: {} + kubelet_stats: + auth_type: serviceAccount + collection_interval: 15s + endpoint: ${env:K8S_NODE_NAME}:10250 + node: ${env:K8S_NODE_NAME} + metric_groups: + - pod + - container + - volume + processors: + infraattributes: + cardinality: 2 + resource/add-cluster-name: + attributes: + - key: k8s.cluster.name + value: ${env:K8S_CLUSTER_NAME} + action: upsert + connectors: + datadog/connector: + traces: + compute_top_level_by_span_kind: true + peer_tags_aggregation: true + compute_stats_by_span_kind: true + extensions: + health_check: + endpoint: "${env:K8S_POD_IP}:13133" + # [...] + service: + # [...] + extensions: ['health_check'] + pipelines: + logs: + # [...] + processors: ['resource/add-cluster-name', 'infraattributes'] + metrics: + receivers: ['host_metrics', 'otlp', 'kubelet_stats', 'datadog/connector'] + processors: ['resource/add-cluster-name', 'infraattributes'] + # [...] + traces: + # [...] + processors: ['resource/add-cluster-name', 'infraattributes'] + exporters: ['datadog', 'datadog/connector'] + env: + # [...] + - name: K8S_POD_IP + valueFrom: + fieldRef: + apiVersion: v1 + fieldPath: status.podIP + # K8S_NODE_NAME is added automatically by the operator +{{< /code-block >}} + +4. (Opcional) Recopile registros de contenedor del sistema de archivos del nodo: + +
Habilitar la recopilación de registros puede generar cargos adicionales. Revise la página de precios y hable con su Gerente de Éxito del Cliente antes de continuar.
+ +El receptor `filelog` lee los registros de contenedor del nodo. Debido a que el Operador no monta rutas del servidor automáticamente, agregue los directorios de registro como volúmenes de solo lectura: + +{{< code-block lang="yaml" filename="node-collector.yaml" collapsible="true" >}} +spec: + config: + receivers: + filelog: + include: + - /var/log/pods/*/*/*.log + # Exclude the Collector's own logs to avoid a feedback loop + exclude: + - /var/log/pods/*_node-collector-collector-*_*/otc-container/*.log + start_at: end + include_file_path: true + include_file_name: false + retry_on_failure: + enabled: true + operators: + - id: container-parser + type: container + max_log_size: 102400 + # [...] + service: + # [...] + pipelines: + logs: + receivers: ['otlp', 'filelog'] + # [...] + # Mount the node's log directories into the Collector pod (read-only) + volumes: + - name: varlogpods + hostPath: + path: /var/log/pods + - name: varlibdockercontainers + hostPath: + path: /var/lib/docker/containers + volumeMounts: + - name: varlogpods + mountPath: /var/log/pods + readOnly: true + - name: varlibdockercontainers + mountPath: /var/lib/docker/containers + readOnly: true +{{< /code-block >}} + +{{% collapse-content title="Archivo node-collector.yaml completado" level="p" %}} +Su archivo `node-collector.yaml` debería verse más o menos así: +{{< code-block lang="yaml" filename="node-collector.yaml" collapsible="false" >}} +apiVersion: opentelemetry.io/v1beta1 +kind: OpenTelemetryCollector +metadata: + name: node-collector +spec: + # Deploy 1 instance per node, that will collect telemetry from that node's pods + mode: daemonset + command: ['otel-agent', 'run'] # Will no longer be necessary from 7.82.0 onwards + # Publish the OTLP ports on the node's network interface + ports: + - name: otlp-grpc + port: 4317 + protocol: TCP + hostPort: 4317 + - name: otlp-http + port: 4318 + protocol: TCP + hostPort: 4318 + config: + receivers: + otlp: + protocols: + grpc: + endpoint: 0.0.0.0:4317 + http: + endpoint: 0.0.0.0:4318 + host_metrics: + collection_interval: 15s + scrapers: + cpu: {} + load: {} + memory: {} + network: {} + disk: {} + kubelet_stats: + auth_type: serviceAccount + collection_interval: 15s + endpoint: ${env:K8S_NODE_NAME}:10250 + node: ${env:K8S_NODE_NAME} + metric_groups: + - pod + - container + - volume + filelog: + include: + - /var/log/pods/*/*/*.log + exclude: + - /var/log/pods/*_node-collector-collector-*_*/otc-container/*.log + start_at: end + include_file_path: true + include_file_name: false + retry_on_failure: + enabled: true + operators: + - id: container-parser + type: container + max_log_size: 102400 + processors: + infraattributes: + cardinality: 2 + resource/add-cluster-name: + attributes: + - key: k8s.cluster.name + value: ${env:K8S_CLUSTER_NAME} + action: upsert + connectors: + datadog/connector: + traces: + compute_top_level_by_span_kind: true + peer_tags_aggregation: true + compute_stats_by_span_kind: true + exporters: + datadog: + api: + key: ${env:DD_API_KEY} + site: ${env:DD_SITE} + sending_queue: + batch: + flush_timeout: 10s + extensions: + health_check: + endpoint: "${env:K8S_POD_IP}:13133" + service: + telemetry: + resource: + k8s.cluster.name: ${env:K8S_CLUSTER_NAME} + extensions: ['health_check'] + pipelines: + logs: + receivers: ['otlp', 'filelog'] + processors: ['resource/add-cluster-name', 'infraattributes'] + exporters: ['datadog'] + metrics: + receivers: ['host_metrics', 'otlp', 'kubelet_stats', 'datadog/connector'] + processors: ['resource/add-cluster-name', 'infraattributes'] + exporters: ['datadog'] + traces: + receivers: ['otlp'] + processors: ['resource/add-cluster-name', 'infraattributes'] + exporters: ['datadog', 'datadog/connector'] + env: + - name: DD_API_KEY + valueFrom: + secretKeyRef: + key: api-key + name: datadog-apikey + - name: DD_SITE + valueFrom: + secretKeyRef: + key: site + name: datadog-apikey + - name: DD_OTELCOLLECTOR_CONVERTER_FEATURES + value: datadog,pprof,zpages,prometheus,infraattributes + - name: K8S_CLUSTER_NAME + value: + - name: K8S_POD_IP + valueFrom: + fieldRef: + apiVersion: v1 + fieldPath: status.podIP + # K8S_NODE_NAME is added automatically by the operator + # vvv Will no longer be necessary from 7.83.0 onwards vvv + - name: DD_OTEL_STANDALONE + value: 'true' + # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + # vvv Will no longer be necessary from 7.82.0 onwards vvv + - name: DD_OTELCOLLECTOR_ENABLED + value: 'true' + # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + # Mount the node's log directories for the filelog receiver (read-only) + volumes: + - name: varlogpods + hostPath: + path: /var/log/pods + - name: varlibdockercontainers + hostPath: + path: /var/lib/docker/containers + volumeMounts: + - name: varlogpods + mountPath: /var/log/pods + readOnly: true + - name: varlibdockercontainers + mountPath: /var/lib/docker/containers + readOnly: true +{{< /code-block >}} + +Reemplace `` con un nombre para su clúster. + +{{% /collapse-content %}} + +{{% /tab %}} +{{% tab "Helm" %}} +Use un archivo YAML para especificar los parámetros del Helm chart para el [Collector chart][1]. + +1. Cree un archivo `node-collector-values.yaml` vacío: + +```shell +touch node-collector-values.yaml +``` + +
Los parámetros no especificados usan los valores predeterminados de values.yaml.
+ +2. Elija el modo daemonset y use DDOT como el Collector: + +{{< code-block lang="yaml" filename="node-collector-values.yaml" collapsible="true" >}} +mode: daemonset +image: + repository: datadog/ddot-collector + tag: {{< version key="agent_version" >}} +ports: + jaeger-compact: + enabled: false + jaeger-grpc: + enabled: false + jaeger-thrift: + enabled: false + zipkin: + enabled: false +# Can be removed from 7.82.0 onwards +command: + name: opt/datadog-agent/embedded/bin/otel-agent +{{< /code-block >}} + +{{% site-region region="gov,gov2" %}} +
Para FED, establezca tag: {{< version key="agent_version" >}}-fips para usar la imagen DDOT compatible con FIPS. Consulte cumplimiento de FIPS.
+{{% /site-region %}} + +
El Helm chart del Collector publica los puertos OTLP en cada nodo por defecto (hostPort: 4317 para gRPC y hostPort: 4318 para HTTP), por lo que los pods de la aplicación pueden llegar a la instancia del Collector que se ejecuta en el mismo nodo. Consulte Configurar la aplicación.
+ +3. Configure el exportador de Datadog y el secreto de la clave de API: + +{{< code-block lang="yaml" filename="node-collector-values.yaml" collapsible="true" >}} +config: + exporters: + datadog: + api: + key: ${env:DD_API_KEY} + site: ${env:DD_SITE} + sending_queue: + batch: + flush_timeout: 10s +extraEnvs: + - name: DD_API_KEY + valueFrom: + secretKeyRef: + key: api-key + name: datadog-apikey + - name: DD_SITE + valueFrom: + secretKeyRef: + key: site + name: datadog-apikey + - name: DD_OTELCOLLECTOR_CONVERTER_FEATURES + value: datadog,pprof,zpages,prometheus,infraattributes + - name: K8S_CLUSTER_NAME + value: + # vvv Will no longer be necessary from 7.83.0 onwards vvv + - name: DD_OTEL_STANDALONE + value: 'true' + # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + # vvv Will no longer be necessary from 7.82.0 onwards vvv + - name: DD_OTELCOLLECTOR_ENABLED + value: 'true' + # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +{{< /code-block >}} + +Reemplace `` con un nombre para su clúster. + +4. Habilite los ajustes preestablecidos: + +{{< code-block lang="yaml" filename="node-collector-values.yaml" collapsible="true" >}} +presets: + hostMetrics: + enabled: true + kubeletMetrics: + enabled: true + logsCollection: + enabled: true + includeCollectorLogs: false +{{< /code-block >}} + +5. Defina las canalizaciones para las señales deseadas, con un receptor OTLP: + +{{< code-block lang="yaml" filename="node-collector-values.yaml" collapsible="true" >}} +config: + # [...] + receivers: + otlp: + protocols: + grpc: + endpoint: 0.0.0.0:4317 + http: + endpoint: 0.0.0.0:4318 + service: + pipelines: + logs: + receivers: ['otlp'] + exporters: ['datadog'] + metrics: + receivers: ['otlp'] + exporters: ['datadog'] + traces: + receivers: ['otlp'] + exporters: ['datadog'] + telemetry: + resource: + k8s.cluster.name: ${env:K8S_CLUSTER_NAME} +{{< /code-block >}} + +6. (Opcional) Habilite funciones adicionales de Datadog: + +
Habilitar estas funciones puede generar cargos adicionales. Revise la página de precios y hable con su Gerente de Éxito del Cliente antes de continuar.
+ +{{< code-block lang="yaml" filename="node-collector-values.yaml" collapsible="true" >}} +config: + # [...] + processors: + infraattributes: + cardinality: 2 + resource/add-cluster-name: + attributes: + - key: k8s.cluster.name + value: ${env:K8S_CLUSTER_NAME} + action: upsert + connectors: + datadog/connector: + traces: + compute_top_level_by_span_kind: true + peer_tags_aggregation: true + compute_stats_by_span_kind: true + service: + pipelines: + logs: + # [...] + processors: ['resource/add-cluster-name', 'infraattributes'] + metrics: + receivers: ['otlp', 'datadog/connector'] + processors: ['resource/add-cluster-name', 'infraattributes'] + # [...] + traces: + # [...] + processors: ['resource/add-cluster-name', 'infraattributes'] + exporters: ['datadog', 'datadog/connector'] +{{< /code-block >}} + +{{% collapse-content title="Archivo node-collector-values.yaml completado" level="p" %}} +Su archivo `node-collector-values.yaml` debería verse más o menos así: +{{< code-block lang="yaml" filename="node-collector-values.yaml" collapsible="false" >}} +mode: daemonset +# vvv To be removed from 7.82.0 onwards vvv +command: + name: opt/datadog-agent/embedded/bin/otel-agent +# ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +image: + repository: datadog/ddot-collector + tag: {{< version key="agent_version" >}} +presets: + hostMetrics: # Add an hostmetrics receiver to the metrics pipeline + enabled: true + kubeletMetrics: # Add a kubeletstats receiver to the metrics pipeline + enabled: true + logsCollection: # Add a filelog receiver to the logs pipeline + enabled: true + includeCollectorLogs: false +config: + connectors: + datadog/connector: + traces: + compute_top_level_by_span_kind: true + peer_tags_aggregation: true + compute_stats_by_span_kind: true + exporters: + datadog: + api: + key: ${env:DD_API_KEY} + site: ${env:DD_SITE} + sending_queue: + batch: + flush_timeout: 10s + processors: + infraattributes: + cardinality: 2 + resource/add-cluster-name: + attributes: + - key: k8s.cluster.name + value: ${env:K8S_CLUSTER_NAME} + action: upsert + receivers: + otlp: + protocols: + grpc: + endpoint: 0.0.0.0:4317 + http: + endpoint: 0.0.0.0:4318 + service: + extensions: + - health_check + pipelines: + logs: + receivers: + - otlp + processors: + - resource/add-cluster-name + - infraattributes + exporters: + - datadog + metrics: + receivers: + - otlp + - datadog/connector + processors: + - resource/add-cluster-name + - infraattributes + exporters: + - datadog + traces: + receivers: + - otlp + processors: + - resource/add-cluster-name + - infraattributes + exporters: + - datadog + - datadog/connector + telemetry: + resource: + k8s.cluster.name: ${env:K8S_CLUSTER_NAME} +extraEnvs: + - name: DD_API_KEY + valueFrom: + secretKeyRef: + key: api-key + name: datadog-apikey + - name: DD_SITE + valueFrom: + secretKeyRef: + key: site + name: datadog-apikey + - name: DD_OTELCOLLECTOR_CONVERTER_FEATURES + value: datadog,pprof,zpages,prometheus,infraattributes + - name: K8S_CLUSTER_NAME + value: + # vvv Will no longer be necessary from 7.83.0 onwards vvv + - name: DD_OTEL_STANDALONE + value: 'true' + # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + # vvv Will no longer be necessary from 7.82.0 onwards vvv + - name: DD_OTELCOLLECTOR_ENABLED + value: 'true' + # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +ports: + jaeger-compact: + enabled: false + jaeger-grpc: + enabled: false + jaeger-thrift: + enabled: false + zipkin: + enabled: false +{{< /code-block >}} + +{{% /collapse-content %}} + +[1]: https://github.com/open-telemetry/opentelemetry-helm-charts/blob/main/charts/opentelemetry-collector/README.md +[2]: /es/getting_started/site/ +[3]: /es/containers/guide/changing_container_registry/ +{{% /tab %}} +{{< /tabs >}} + +### Implemente el Collector {#deploy-the-collector} + +{{< tabs >}} +{{% tab "Operador" %}} +Aplique el archivo `node-collector.yaml` para crear el recurso `OpenTelemetryCollector`. El OpenTelemetry Operator implementa el Collector como un DaemonSet, ejecutando una instancia por nodo: + +```shell +kubectl apply -f node-collector.yaml +``` +{{% /tab %}} +{{% tab "Helm" %}} +Instale el Helm chart del OpenTelemetry Collector con su archivo de valores: + +```shell +helm install node-collector open-telemetry/opentelemetry-collector -f node-collector-values.yaml +``` + +Para aplicar cambios posteriores, ejecute `helm upgrade node-collector open-telemetry/opentelemetry-collector -f node-collector-values.yaml`. +{{% /tab %}} +{{< /tabs >}} + +## Instale el Datadog Agent principal junto con DDOT {#install-the-core-datadog-agent-alongside-ddot} + +Si desea ejecutar el Datadog Agent principal en los mismos nodos que el Collector DDOT independiente (por ejemplo, para recopilar métricas de infraestructura, APM o registros a través del Agent principal mientras DDOT maneja la ingesta de OTLP), puede instalarlo por separado utilizando el [Datadog Operator][57]. + +De forma predeterminada, el Datadog Operator Helm chart observa DatadogAgent recursos solo en el espacio de nombres donde está instalado el Datadog Operator (watchNamespaces: []). Si el DatadogAgent recurso está en un espacio de nombres diferente al del Datadog Operator, por ejemplo, para mantenerlo separado del OpenTelemetryCollector espacio de nombres del recurso, establezca watchNamespaces para incluir el espacio de nombres donde el DatadogAgent recurso es creado: +
helm upgrade datadog-operator datadog/datadog-operator \
+  -n <OPERATOR_NAMESPACE> \
+  --reuse-values \
+  --set 'watchNamespaces[0]=<DATADOG_AGENT_NAMESPACE>'
+
+Si el Datadog Operator no observa el espacio de nombres donde el DatadogAgent recurso es creado, el recurso falla silenciosamente al reconciliarse, sin error, sin evento de Kubernetes y sin actualización de estado que indique el problema. + +## Envíe su telemetría a Datadog {#send-your-telemetry-to-datadog} + +Para enviar sus datos de telemetría a Datadog: + +1. [Instrumente su aplicación](#instrument-the-application) +2. [Configure la aplicación](#configure-the-application) +3. [Correlacione los datos de observabilidad](#correlate-observability-data) +4. [Ejecute su aplicación](#run-the-application) + +### Instrumente la aplicación {#instrument-the-application} + +Instrumente su aplicación [usando la API de OpenTelemetry][12]. + +{{% collapse-content title="Ejemplo de aplicación instrumentada con la API de OpenTelemetry" level="p" %}} +Como ejemplo, puede usar la [aplicación de muestra Calendar][9] que ya está instrumentada para usted. El siguiente código instrumenta el método [CalendarService.getDate()][10] usando las anotaciones y la API de OpenTelemetry: + {{< code-block lang="java" filename="CalendarService.java" disable_copy="true" collapsible="false" >}} +@WithSpan(kind = SpanKind.CLIENT) +public String getDate() { + Span span = Span.current(); + span.setAttribute("peer.service", "random-date-service"); + ... +} +{{< /code-block >}} +{{% /collapse-content %}} + +### Configure la aplicación {#configure-the-application} + +El contenedor de su aplicación debe enviar datos al Collector de DDOT que se ejecuta en el mismo nodo. Debido a que el Collector publica los puertos OTLP en el nodo con `hostPort`, la aplicación puede comunicarse con el Collector local a través de la dirección IP del nodo (`status.hostIP`). + +Si la variable de entorno `OTEL_EXPORTER_OTLP_ENDPOINT` aún no está configurada, agréguela al archivo de manifiesto de implementación de su aplicación: + {{< code-block lang="yaml" filename="deployment.yaml" disable_copy="true" collapsible="true" >}} +env: + ... + - name: HOST_IP + valueFrom: + fieldRef: + fieldPath: status.hostIP + - name: OTLP_GRPC_PORT + value: "4317" + - name: OTEL_EXPORTER_OTLP_ENDPOINT + value: 'http://$(HOST_IP):$(OTLP_GRPC_PORT)' + - name: OTEL_EXPORTER_OTLP_PROTOCOL + value: 'grpc' + {{< /code-block >}} + +### Correlacione los datos de observabilidad {#correlate-observability-data} + +[Unified service tagging][14] vincula los datos de observabilidad en Datadog para que pueda navegar entre métricas, trazas y registros con etiquetas consistentes. + +En entornos contenerizados, configure `env`, `service` y `version` utilizando variables de entorno de atributos de recursos de OpenTelemetry. El Collector de DDOT detecta esta configuración de etiquetado y la aplica a los datos que recopila de los contenedores. + +Agregue las siguientes variables de entorno al manifiesto de implementación de su aplicación: + +{{< code-block lang="yaml" filename="deployment.yaml" disable_copy="true" collapsible="true" >}} +apiVersion: apps/v1 +kind: Deployment +metadata: + name: +spec: + template: + spec: + containers: + - name: + env: + - name: OTEL_SERVICE_NAME + value: "" + - name: OTEL_RESOURCE_ATTRIBUTES + value: "service.version=,deployment.environment.name=" +{{< /code-block >}} + +### Ejecute la aplicación {#run-the-application} + +Vuelva a implementar su aplicación para aplicar los cambios realizados en el manifiesto de implementación. Una vez que la configuración actualizada esté activa, Unified Service Tagging estará completamente habilitado para sus métricas, trazas y registros. + +## Explore los datos de observabilidad en Datadog {#explore-observability-data-in-datadog} + +Utilice Datadog para explorar los datos de observabilidad de su aplicación. + +### Fleet Automation {#fleet-automation} + +Explore la configuración de su Collector. + +{{< img src="/opentelemetry/embedded_collector/fleet_automation.png" alt="Revise la configuración de su Collector desde la página de Fleet Automation." style="width:100%;" >}} + +### Monitoreo en vivo de contenedor {#live-container-monitoring} + +Haga un seguimiento del estado de sus contenedores utilizando las capacidades de Container Monitoring. + +{{< img src="/opentelemetry/embedded_collector/containers.png" alt="Haga un seguimiento del estado de sus contenedores desde la página de Containers." style="width:100%;" >}} + +### Estado de salud del nodo de infraestructura {#infrastructure-node-health} + +Vea las métricas de tiempo de ejecución y de infraestructura para visualizar, monitorear y medir el rendimiento de sus nodos. + +{{< img src="/opentelemetry/embedded_collector/infrastructure.png" alt="Vea las métricas de tiempo de ejecución y de infraestructura desde el Host List." style="width:100%;" >}} + +### Registros {#logs} + +Vea los registros para monitorear y solucionar problemas de las operaciones de la aplicación y del sistema. + +{{< img src="/opentelemetry/embedded_collector/logs.png" alt="Vea los registros desde el Log Explorer." style="width:100%;" >}} + +### Trazas {#traces} + +Visualice las trazas y los spans para observar el estado y el rendimiento de las solicitudes procesadas por su aplicación, con métricas de infraestructura correlacionadas en la misma traza. + +{{< img src="/opentelemetry/embedded_collector/traces.png" alt="Visualice las trazas desde el Trace Explorer." style="width:100%;" >}} + +### Métricas de tiempo de ejecución {#runtime-metrics} + +Monitoree las métricas de tiempo de ejecución (JVM) de sus aplicaciones. + +{{< img src="/opentelemetry/embedded_collector/metrics.png" alt="Visualice las métricas de JVM desde el JVM Metrics dashboard" style="width:100%;" >}} + +### Métricas de salud del colector {#collector-health-metrics} + +Visualice las métricas del DDOT Collector para hacer un seguimiento de la salud del Collector. + +{{< img src="/opentelemetry/embedded_collector/dashboard.png" alt="Visualice las métricas de salud del Collector desde el OTel dashboard." style="width:100%;" >}} + +## Lecturas adicionales {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://www.datadoghq.com/free-datadog-trial/ +[2]: https://app.datadoghq.com/organization-settings/api-keys/ +[3]: https://app.datadoghq.com/organization-settings/application-keys +[4]: https://opentelemetry.io/docs/platforms/kubernetes/helm/collector/ +[5]: https://kubernetes.io/docs/tasks/tools/#kubectl +[9]: https://github.com/DataDog/opentelemetry-examples/tree/main/apps/rest-services/java/calendar +[10]: https://github.com/DataDog/opentelemetry-examples/blob/main/apps/rest-services/java/calendar/src/main/java/com/otel/service/CalendarService.java#L27-L48 +[12]: /es/tracing/trace_collection/custom_instrumentation/otel_instrumentation/ +[14]: /es/getting_started/tagging/unified_service_tagging +[52]: /es/getting_started/site/ +[54]: https://helm.sh +[55]: https://opentelemetry.io/docs/platforms/kubernetes/operator/ +[56]: https://kubernetes.io/docs/concepts/extend-kubernetes/operator/ +[57]: /es/getting_started/containers/datadog_operator/ \ No newline at end of file diff --git a/hugo/content/es/security/cloud_siem/detect_and_monitor/custom_detection_rules/anomaly.md b/hugo/content/es/security/cloud_siem/detect_and_monitor/custom_detection_rules/anomaly.md index 43846811581..90eea39dd19 100644 --- a/hugo/content/es/security/cloud_siem/detect_and_monitor/custom_detection_rules/anomaly.md +++ b/hugo/content/es/security/cloud_siem/detect_and_monitor/custom_detection_rules/anomaly.md @@ -1,38 +1,36 @@ --- -description: Más información sobre el funcionamiento del método de detección de anomalías. +description: Aprenda cómo funciona el método de detección de anomalías. disable_toc: false title: Anomalía --- +## Descripción general {#overview} -## Información general +La detección de anomalías analiza los registros para identificar picos anormales en su volumen de registros, lo que podría indicar problemas como un ataque, una configuración incorrecta o un proceso fuera de control. -La detección de anomalías analiza logs para identificar picos anormales en tu volumen de logs, que podrían indicar problemas como un ataque, un error de configuración o un proceso fuera de control. +Consulte [Crear regla][1] para obtener instrucciones sobre cómo configurar una regla de anomalía. -Consulta [Crear regla][1] para obtener instrucciones sobre cómo configurar una regla de anomalías. - -## Funcionamiento de la detección de anomalías +## Cómo funciona la detección de anomalías {#how-anomaly-detection-works} La regla de detección de anomalías: -- Agrega los logs entrantes en buckets de tiempo y calcula una línea de base. - - El límite superior refleja el percentil 99,5 de tu historial reciente, utilizando hasta 2 semanas de logs históricos. -- Comprueba en cada evaluación el periodo de evaluación más reciente y mide cuánto excede la serie ese límite. - - Se activa una señal si el exceso es suficientemente grande en todo el periodo. +- Agrupa los registros entrantes en intervalos de tiempo y calcula una línea base. + - El límite superior refleja el percentil 99.5 de su historial reciente, utilizando hasta 2 semanas de registros históricos. +- Comprueba en cada evaluación la ventana de evaluación más reciente y mide cuánto excede la serie ese límite. + - Se activa una señal si el exceso es lo suficientemente grande durante toda la ventana. -El método de anomalías se adapta a tus patrones normales y reduce el ruido de las fluctuaciones rutinarias. +El método de anomalías se adapta a sus patrones normales y reduce el ruido de las fluctuaciones rutinarias. -**Nota**: El método de anomalías solo detecta picos, pero no alerta de caídas en el volumen de logs. +**Nota**: El método de anomalías solo detecta picos. No alerta sobre caídas en el volumen de registros. -### Estacionalidad y periodo de aprendizaje +### Estacionalidad y periodo de aprendizaje {#seasonality-and-learning-period} -El algoritmo tiene en cuenta automáticamente la estacionalidad diaria y semanal, de modo que los picos regulares, como los aumentos de fin de semana, no alertan. +El algoritmo tiene en cuenta automáticamente la estacionalidad diaria y semanal, por lo que no alerta ante picos regulares, como los aumentos de fin de semana. -Se aplica un breve periodo de aprendizaje de nuevas reglas o nuevos valores observados para un `group by`. Durante el periodo de aprendizaje, se recopilan datos para crear una línea de base. +Se aplica un periodo de aprendizaje corto para reglas nuevas o valores recién observados para un `group by`. Durante el periodo de aprendizaje, se recopilan datos para crear una línea base. -## Prácticas recomendadas +## Mejores prácticas {#best-practices} -- Limita la consulta. Filtra por servicio, entorno, equipo o endpoint para reducir el ruido. -- Comienza con reglas predeterminadas gestionadas para una amplia cobertura y luego añade reglas de anomalías personalizadas para fuentes con grandes volúmenes de logs. +- Delimite el contexto de la consulta de forma precisa. Filtre por servicio, entorno, equipo o punto de conexión para reducir el ruido. +- Comience con reglas predeterminadas administradas para una cobertura amplia, luego agregue reglas de anomalía personalizadas para fuentes de registros de alto volumen. -[1]: /es/security/cloud_siem/detect_and_monitor/custom_detection_rules/create_rule/real_time_rule?tab=anomaly -[2]: /es/security/cloud_siem/detect_and_monitor/custom_detection_rules/create_rule/real_time_rule/?tab=anomaly#rule-multi-triggering-rt-anomaly \ No newline at end of file +[1]: /es/security/cloud_siem/detect_and_monitor/custom_detection_rules/create_rule?cloud_siem_detection_rule_detection_method=anomaly \ No newline at end of file diff --git a/hugo/content/es/serverless/google_cloud_run/functions/nodejs.md b/hugo/content/es/serverless/google_cloud_run/functions/nodejs.md new file mode 100644 index 00000000000..367e9fd99ff --- /dev/null +++ b/hugo/content/es/serverless/google_cloud_run/functions/nodejs.md @@ -0,0 +1,109 @@ +--- +code_lang: nodejs +code_lang_weight: 20 +further_reading: +- link: /tracing/trace_collection/automatic_instrumentation/dd_libraries/nodejs/ + tag: Documentación + text: Seguimiento de aplicaciones Node.js +- link: /tracing/other_telemetry/connect_logs_and_traces/nodejs/ + tag: Documentación + text: Correlación de registros y trazas de Node.js +title: Instrumentación de una función de Node.js en Cloud Run +type: multi-code-lang +--- +
Una aplicación de muestra está disponible en GitHub.
+ +## Configuración {#setup} + +1. **Instale el SDK de Datadog para Node.js**. + + 1. En su aplicación principal, instale el paquete `dd-trace`. + + {{< code-block lang="shell" disable_copy="false" >}} +npm install dd-trace +{{< /code-block >}} + + 2. Inicialice el trazador de Node.js con la variable de entorno `NODE_OPTIONS`: + {{< code-block lang="dockerfile" disable_copy="false" >}} +ENV NODE_OPTIONS="--require dd-trace/init" +{{< /code-block >}} + + Para obtener más información, consulte [Seguimiento de aplicaciones Node.js][1]. + +2. **Instale serverless-init como sidecar**. + + {{< tabs >}} + + {{% tab "CLI de Datadog" %}} + {{% gcr-install-sidecar-datadog-ci %}} + {{% /tab %}} + + {{% tab "Terraform" %}} + {{% gcr-install-sidecar-terraform function="true" %}} + {{% /tab %}} + + {{% tab "Otro" %}} + {{% gcr-install-sidecar-other function="true" %}} + {{% /tab %}} + + {{< /tabs >}} + +3. **Configure los registros**. + + En el paso anterior, creó un volumen compartido. Es posible que también haya configurado la variable de entorno `DD_SERVERLESS_LOG_PATH`, que tiene como valor predeterminado `/shared-volume/logs/app.log`. + + En este paso, configure su biblioteca de registro para escribir registros en el archivo establecido en `DD_SERVERLESS_LOG_PATH`. En Node.js, Datadog recomienda escribir los registros en formato JSON. Por ejemplo, puede utilizar una biblioteca de registro de terceros como `winston`: + {{< code-block lang="javascript" disable_copy="false" >}} +const { createLogger, format, transports } = require('winston'); + +const LOG_FILE = "/shared-volume/logs/app.log" + +const logger = createLogger({ + level: 'info', + exitOnError: false, + format: format.json(), + transports: [ + new transports.File({ filename: LOG_FILE }), + new transports.Console() + ], +}); + +logger.info('Hello world!'); +{{< /code-block >}} + + Datadog recomienda configurar las variables de entorno `DD_LOGS_INJECTION=true` (en su contenedor principal) y `DD_SOURCE=nodejs` (en su contenedor sidecar) para habilitar el parseo avanzado de registros de Datadog. + + Para obtener más información, consulte [Correlación de registros y trazas de Node.js][2]. + +4. {{% gcr-service-label %}} + +5. **Enviar métricas personalizadas**. + + Para enviar métricas personalizadas, [vea ejemplos de código][3]. En Serverless Monitoring, solo se admite el tipo de métrica *distribution*. + +6. **Habilite la generación de perfiles (vista previa)**. + + Para habilitar el [Continuous Profiler][6], establezca la variable de entorno `DD_PROFILING_ENABLED=true` en el contenedor de su aplicación. + +
El Continuous Profiler de Datadog está disponible en vista previa para las funciones de Cloud Run de segunda generación.
+ +{{% serverless-init-env-vars-sidecar language="nodejs" function="true" defaultSource="cloudrun" %}} + +{{% svl-tracing-env %}} + +## Seguimiento distribuido con Pub/Sub {#distributed-tracing-with-pubsub} + +{{% gcr-pubsub-push-tracing %}} + +## Solución de problemas {#troubleshooting} + +{{% serverless-init-troubleshooting productNames="Cloud Run services" %}} + +## Lecturas adicionales {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /es/tracing/trace_collection/automatic_instrumentation/dd_libraries/nodejs/ +[2]: /es/tracing/other_telemetry/connect_logs_and_traces/nodejs/ +[3]: /es/metrics/custom_metrics/dogstatsd_metrics_submission/?tab=nodejs#code-examples-5 +[6]: /es/profiler/ \ No newline at end of file diff --git a/hugo/content/es/tests/guides/validate_optimizations/_index.md b/hugo/content/es/tests/guides/validate_optimizations/_index.md new file mode 100644 index 00000000000..123f5f2db47 --- /dev/null +++ b/hugo/content/es/tests/guides/validate_optimizations/_index.md @@ -0,0 +1,576 @@ +--- +description: Valide que las funciones de Test Optimization (incluyendo Early Flake + Detection, Auto Test Retries y Flaky Test Management) funcionen correctamente en + su repositorio. +further_reading: +- link: /tests/guides/setup_new_flaky_pr_gate + tag: Documentación + text: Configure un [New Flaky Test PR Gate] +- link: /tests/flaky_tests/early_flake_detection + tag: Documentación + text: Obtenga información sobre Early Flake Detection +- link: /tests/flaky_tests/auto_test_retries + tag: Documentación + text: Obtenga información sobre Auto Test Retries +- link: /tests/flaky_management + tag: Documentación + text: Obtenga información sobre Flaky Test Management +title: Valide Test Optimization +--- +Esta página explica cómo verificar que las optimizaciones ofrecidas por Test Optimization funcionen según lo previsto. La guía asume que [Test Optimization][12] ya funciona para el repositorio bajo validación, y muestra los pasos para validar las optimizaciones para un **solo repositorio**. + +
Ejecute estas validaciones solo en una rama de características y no las combine en su rama predeterminada o principal.
+ +## Requisitos previos {#prerequisites} + +Estas optimizaciones requieren una [biblioteca nativa compatible][12]. Las cargas de archivos XML de JUnit no son compatibles. + +## Opción 1: Validar localmente con un agente de codificación {#option-1-validate-locally-with-a-coding-agent} + +{{< callout url="#" btn_hidden="true" header="¡Únase a la vista previa!" >}} + La validación con agente de codificación local está en versión preliminar y solo es compatible con proyectos de JavaScript y TypeScript que utilizan el paquete [`dd-trace` ][15]. + + [15]: https://www.npmjs.com/package/dd-trace +{{< /callout >}} + +Utilizando el prompt proporcionado a continuación, pídale a un agente de codificación local (un asistente de IA que puede inspeccionar y ejecutar comandos en su repositorio local) que inspeccione su `dd-trace`paquete instalado y ejecute su manual de validación de Test Optimization. Este método verifica la compatibilidad de la biblioteca local y la configuración de CI. También verifica Early Flake Detection, Auto Test Retries y Test Management sin cambiar la configuración de Datadog ni enviar resultados de validación a Datadog. + +El manual se encuentra en `ci/runbook.md` en relación con la raíz del paquete `dd-trace` instalado. + +Pase este prompt a su agente de codificación local: + +```text +Locate the installed dd-trace package, then read and execute its ci/runbook.md. +``` + +Este método de agente de codificación es una verificación local que no ejecuta todo el flujo de trabajo de Datadog. Para validar los flujos de trabajo completos de [Prevención](#step-2-prevention), [Mitigación](#step-3-mitigation) y [Remediación](#step-4-remediation), o para validar un lenguaje distinto a JavaScript o TypeScript, use la [Opción 2, a continuación](#option-2-validate-the-full-workflow). + +## Opción 2: Validar el flujo de trabajo completo {#option-2-validate-the-full-workflow} + +Este flujo de trabajo de validación comprueba el flujo de trabajo completo de Test Optimization en Datadog. Realice estas validaciones ([Prevención](#step-2-prevention), [Mitigación](#step-3-mitigation) y [Remediación](#step-4-remediation)) en orden, ya que utilizan la misma rama y la prueba. + +### Paso 1: Configurar la validación {#step-1-set-up-validation} + +Esta guía lo lleva a través de la realización de cambios locales y su confirmación para que la CI los ejecute. Utiliza un servicio de pruebas y una rama dedicados para minimizar el impacto del flujo de trabajo de validación en otros desarrolladores del repositorio. + +1. Configure su trabajo de prueba de CI para establecer `DD_SERVICE` antes de que ejecute el comando de prueba: + + ```bash + export DD_SERVICE=validate-test-optimization + ``` + +2. Cree la rama de validación: + + ```bash + git checkout -b validate-test-optimization + ``` + +3. Confirme el cambio de configuración de CI que establece `DD_SERVICE`, luego envíe la rama de validación para activar una ejecución de prueba: + + ```bash + git add -A + git commit -m "Configure Test Optimization validation service" + git push -u origin validate-test-optimization + ``` + + Datadog detecta el `validate-test-optimization`servicio cuando las pruebas se reportan bajo ese nombre. + +4. Después de que finalice la CI, vaya a la [configuración de repositorios de CI/CD][3] y seleccione el repositorio que está validando. + + {{< img src="pr_gates/setup/ci_cd_repositories_settings.png" alt="Configuración de repositorios de CI/CD filtrada al repositorio que se está validando" style="width:100%" >}} + +5. En la esquina superior derecha del panel deslizante, haga clic en {{< ui >}}Test Service{{< /ui >}}. + + {{< img src="pr_gates/setup/repository_settings_test_services.png" alt="Configuración del repositorio con el botón de servicio de pruebas en la esquina superior derecha" style="width:100%" >}} + +6. En {{< ui >}}Test service overrides{{< /ui >}}, seleccione el `validate-test-optimization` servicio. + + {{< img src="pr_gates/setup/test_service_overrides.png" alt="Anulaciones de servicio de pruebas que muestran los servicios de pruebas detectados para un repositorio" style="width:100%" >}} + +7. Configure las siguientes anulaciones de servicio de pruebas: + - Habilite [Early Flake Detection][1]. + - Habilite [Auto Test Retries][4]. + - Deshabilite [Test Impact Analysis][13] (para que no omita la prueba de validación). +8. Regrese a la configuración del repositorio. [Flaky Test Policies][6] se aplican a cada servicio de pruebas en el repositorio, no a un servicio de pruebas individual. Para limitar el impacto de la política de validación, configúrela solo para la rama `validate-test-optimization`. En {{< ui >}}Flaky Test Policies{{< /ui >}}, en el mosaico {{< ui >}}Quarantine{{< /ui >}}, haga clic en {{< ui >}}Configure{{< /ui >}}. + + {{< img src="pr_gates/setup/flaky_test_policies_quarantine.png" alt="Configuración del repositorio que muestra el botón Configurar para la política de pruebas inestables en cuarentena" style="width:100%" >}} + +9. Habilite la segunda regla automática: **Si una prueba inestable activa falla en la rama `validate-test-optimization`, muévala a Cuarentena**. + + {{< img src="pr_gates/setup/quarantine_branch_policy.png" alt="Política de cuarentena configurada para pruebas inestables activas en la rama validate-test-optimization" style="width:100%" >}} + +10. Haga clic en {{< ui >}}Save{{< /ui >}}. +11. Cree un [New Flaky Test PR Gate][11] y asígnele el contexto del repositorio que está validando. + + {{< img src="pr_gates/setup/pr_gate_scope.png" alt="Contexto de la nueva puerta de PR para pruebas inestables" style="width:100%" >}} + +### Paso 2: Prevención {#step-2-prevention} + +[Early Flake Detection][1] detecta nuevas pruebas inestables. [New Flaky Test PR Gates][2] evitan que las nuevas pruebas inestables lleguen a su rama predeterminada. + +1. Agregue una prueba que falle en el primer intento y pase en los reintentos (opcionalmente usando el código proporcionado a continuación). El nombre de la prueba debe contener tanto `flaky` como `validation` para que pueda identificarla en Datadog. + + {{< tabs >}} + {{% tab "JavaScript" %}} + + ```javascript + const fs = require('node:fs'); + const os = require('node:os'); + const path = require('node:path'); + + test('flaky validation test', () => { + const marker = path.join(os.tmpdir(), 'dd-validation-flaky'); + if (!fs.existsSync(marker)) { + fs.writeFileSync(marker, '1'); + throw new Error('first attempt fails so Datadog can retry it'); + } + }); + ``` + + {{% /tab %}} + {{% tab "Python" %}} + + ```python + from pathlib import Path + from tempfile import gettempdir + + + def test_flaky_validation_test(): + marker = Path(gettempdir()) / "dd-validation-flaky" + if not marker.exists(): + marker.write_text("1") + raise AssertionError("first attempt fails so Datadog can retry it") + ``` + + {{% /tab %}} + {{% tab "Java" %}} + + ```java + import static org.junit.jupiter.api.Assertions.fail; + + import java.io.IOException; + import java.nio.file.Files; + import java.nio.file.Path; + import java.nio.file.Paths; + import org.junit.jupiter.api.Test; + + class ValidationFlakyTest { + @Test + void flakyValidationTest() throws IOException { + Path marker = Paths.get( + System.getProperty("java.io.tmpdir"), + "dd-validation-flaky" + ); + if (Files.notExists(marker)) { + Files.write(marker, new byte[] { '1' }); + fail("first attempt fails so Datadog can retry it"); + } + } + } + ``` + + {{% /tab %}} + {{% tab "Ruby" %}} + + ```ruby + require 'tmpdir' + + RSpec.describe 'validation flaky tests' do + it 'flaky validation test' do + marker = File.join(Dir.tmpdir, 'dd-validation-flaky') + unless File.exist?(marker) + File.write(marker, '1') + raise 'first attempt fails so Datadog can retry it' + end + end + end + ``` + + {{% /tab %}} + {{% tab ".NET" %}} + + ```csharp + using System.IO; + using Xunit; + + public class ValidationFlakyTests + { + [Fact] + public void FlakyValidationTest() + { + var marker = Path.Combine(Path.GetTempPath(), "dd-validation-flaky"); + if (!File.Exists(marker)) + { + File.WriteAllText(marker, "1"); + throw new System.Exception("first attempt fails so Datadog can retry it"); + } + } + } + ``` + + {{% /tab %}} + {{% tab "Go" %}} + + ```go + package validation + + import ( + "errors" + "os" + "path/filepath" + "testing" + ) + + func TestFlakyValidationTest(t *testing.T) { + marker := filepath.Join(os.TempDir(), "dd-validation-flaky") + if _, err := os.Stat(marker); errors.Is(err, os.ErrNotExist) { + if writeErr := os.WriteFile(marker, []byte("1"), 0600); writeErr != nil { + t.Fatal(writeErr) + } + t.Fatal("first attempt fails so Datadog can retry it") + } + } + ``` + + {{% /tab %}} + {{% tab "Swift" %}} + + ```swift + import XCTest + + final class ValidationFlakyTests: XCTestCase { + func testFlakyValidationTest() throws { + let marker = FileManager.default.temporaryDirectory + .appendingPathComponent("dd-validation-flaky") + if !FileManager.default.fileExists(atPath: marker.path) { + try "1".write(to: marker, atomically: true, encoding: .utf8) + XCTFail("first attempt fails so Datadog can retry it") + } + } + } + ``` + + {{% /tab %}} + {{< /tabs >}} + +2. Confirme y envíe (push) la prueba, luego abra una solicitud de extracción (pull request) desde la rama de validación: + + ```bash + git add -A + git commit -m "Validate Test Optimization prevention" + git push origin validate-test-optimization + ``` + +3. Espere a que se ejecute la CI. La detección temprana de inestabilidad (Early Flake Detection) reintenta la nueva prueba, y la puerta de PR de nueva prueba inestable (New Flaky Test PR Gate) evalúa el resultado. En las verificaciones de GitHub para su solicitud de extracción, confirme que la puerta de PR de nueva prueba inestable (New Flaky Test PR Gate) falle: + + {{< img src="pr_gates/setup/failed_pr_gate.png" alt="La verificación de solicitud de extracción de GitHub fallida porque se detectó una nueva prueba inestable." style="width:100%" >}} + +4. Haga clic en la verificación de GitHub fallida y confirme que la prueba esté incluida en la lista de nuevas pruebas inestables: + + {{< img src="pr_gates/setup/pr_gate_detail.png" alt="Vista detallada de la puerta de PR de Datadog" style="width:100%" >}} + +5. En [Test Runs][7], confirme que la detección temprana de inestabilidad (Early Flake Detection) reintentó la prueba y la detectó como una nueva prueba inestable usando [esta consulta][7], que utiliza los siguientes filtros: + + - `@test.name:*flaky*validation*` + - `@git.branch:validate-test-optimization` + - `@test.retry_reason:early_flake_detection` + - `@test.test_management.is_new_flaky:true` + +### Paso 3: Mitigación {#step-3-mitigation} + +La mitigación se logra a través de [Auto Test Retries][4], [Flaky Test Management][5] y [Flaky Test Policies][6]. Estas funciones reintentan las pruebas inestables y ponen en cuarentena las fallas inestables conocidas para que no bloqueen la CI. + +1. En la misma prueba que agregó para [Prevención](#step-2-prevention), cambie el nombre del archivo de marcador de `dd-validation-flaky` a `dd-validation-flaky-mitigation`. No cambie el nombre de la función de prueba ni del caso de prueba. El nuevo marcador provoca otra falla intencional en el primer intento. Mantener el nombre de la prueba sin cambios permite que Datadog asocie la ejecución con la prueba inestable detectada durante la [Prevención](#step-2-prevention). No se requiere configuración adicional de Datadog; Auto Test Retries y Flaky Test Management manejan la prueba durante esta ejecución. Actualice la prueba para su idioma: + + {{< tabs >}} + {{% tab "JavaScript" %}} + + ```javascript + const fs = require('node:fs'); + const os = require('node:os'); + const path = require('node:path'); + + test('flaky validation test', () => { + // Changed from dd-validation-flaky. + const marker = path.join(os.tmpdir(), 'dd-validation-flaky-mitigation'); + if (!fs.existsSync(marker)) { + fs.writeFileSync(marker, '1'); + throw new Error('first attempt fails so Datadog can retry it'); + } + }); + ``` + + {{% /tab %}} + {{% tab "Python" %}} + + ```python + from pathlib import Path + from tempfile import gettempdir + + + def test_flaky_validation_test(): + # Changed from dd-validation-flaky. + marker = Path(gettempdir()) / "dd-validation-flaky-mitigation" + if not marker.exists(): + marker.write_text("1") + raise AssertionError("first attempt fails so Datadog can retry it") + ``` + + {{% /tab %}} + {{% tab "Java" %}} + + ```java + import static org.junit.jupiter.api.Assertions.fail; + + import java.io.IOException; + import java.nio.file.Files; + import java.nio.file.Path; + import java.nio.file.Paths; + import org.junit.jupiter.api.Test; + + class ValidationFlakyTest { + @Test + void flakyValidationTest() throws IOException { + // Changed from dd-validation-flaky. + Path marker = Paths.get( + System.getProperty("java.io.tmpdir"), + "dd-validation-flaky-mitigation" + ); + if (Files.notExists(marker)) { + Files.write(marker, new byte[] { '1' }); + fail("first attempt fails so Datadog can retry it"); + } + } + } + ``` + + {{% /tab %}} + {{% tab "Ruby" %}} + + ```ruby + require 'tmpdir' + + RSpec.describe 'validation flaky tests' do + it 'flaky validation test' do + # Changed from dd-validation-flaky. + marker = File.join(Dir.tmpdir, 'dd-validation-flaky-mitigation') + unless File.exist?(marker) + File.write(marker, '1') + raise 'first attempt fails so Datadog can retry it' + end + end + end + ``` + + {{% /tab %}} + {{% tab ".NET" %}} + + ```csharp + using System.IO; + using Xunit; + + public class ValidationFlakyTests + { + [Fact] + public void FlakyValidationTest() + { + // Changed from dd-validation-flaky. + var marker = Path.Combine(Path.GetTempPath(), "dd-validation-flaky-mitigation"); + if (!File.Exists(marker)) + { + File.WriteAllText(marker, "1"); + throw new System.Exception("first attempt fails so Datadog can retry it"); + } + } + } + ``` + + {{% /tab %}} + {{% tab "Go" %}} + + ```go + package validation + + import ( + "errors" + "os" + "path/filepath" + "testing" + ) + + func TestFlakyValidationTest(t *testing.T) { + // Changed from dd-validation-flaky. + marker := filepath.Join(os.TempDir(), "dd-validation-flaky-mitigation") + if _, err := os.Stat(marker); errors.Is(err, os.ErrNotExist) { + if writeErr := os.WriteFile(marker, []byte("1"), 0600); writeErr != nil { + t.Fatal(writeErr) + } + t.Fatal("first attempt fails so Datadog can retry it") + } + } + ``` + + {{% /tab %}} + {{% tab "Swift" %}} + + ```swift + import XCTest + + final class ValidationFlakyTests: XCTestCase { + func testFlakyValidationTest() throws { + // Changed from dd-validation-flaky. + let marker = FileManager.default.temporaryDirectory + .appendingPathComponent("dd-validation-flaky-mitigation") + if !FileManager.default.fileExists(atPath: marker.path) { + try "1".write(to: marker, atomically: true, encoding: .utf8) + XCTFail("first attempt fails so Datadog can retry it") + } + } + } + ``` + + {{% /tab %}} + {{< /tabs >}} + +2. Confirme y envíe (push) el cambio en la misma rama: + + ```bash + git add -A + git commit -m "Validate Test Optimization mitigation" + git push origin validate-test-optimization + ``` + +3. Espere a que se ejecute la CI y, a continuación, confirme los siguientes resultados: + + - En [Test Runs][8], Auto Test Retries vuelve a ejecutar la prueba después de su primer intento fallido, y la prueba pasa en el reintento. Utilice [esta consulta][8], con los siguientes filtros: + - `@test.name:*flaky*validation*` + - `@git.branch:validate-test-optimization` + - `@test.retry_reason:auto_test_retry` + - En [Flaky Test Management][9], la prueba aparece como {{< ui >}}QUARANTINED{{< /ui >}}. Sus fallos ya no bloquean el trabajo de prueba. Utilice [esta consulta][9], con los siguientes filtros: + - `@test.name:*flaky*validation*` + - `first_flaked_branch:validate-test-optimization` + - `flaky_test_state:quarantined` + +### Paso 4: Remediación {#step-4-remediation} + +Test Optimization ayuda a corregir pruebas inestables mediante Attempt to Fix y [correcciones de pruebas inestables con Bits AI][16]. Esta sección valida el flujo de trabajo Attempt to Fix corrigiendo la misma prueba utilizada para [Prevención](#step-2-prevention) y [Mitigación](#step-3-mitigation). + +1. En [Flaky Test Management][9], abra la prueba de validación en cuarentena. +2. Haga clic en {{< ui >}}Actions{{< /ui >}}, seleccione {{< ui >}}Link commit to fix{{< /ui >}} y copie la clave generada (comienza con `DD_`). + + {{< img src="pr_gates/setup/attempt_to_fix_modal.png" alt="Modal de Attempt to Fix" style="width:50%" >}} + +3. Reemplace la prueba inestable con la versión aprobada para su idioma: + + {{< tabs >}} + {{% tab "JavaScript" %}} + + ```javascript + test('flaky validation test', () => { + expect(true).toBe(true); + }); + ``` + + {{% /tab %}} + {{% tab "Python" %}} + + ```python + def test_flaky_validation_test(): + assert True + ``` + + {{% /tab %}} + {{% tab "Java" %}} + + ```java + @Test + void flakyValidationTest() { + // intentionally empty - the test passes + } + ``` + + {{% /tab %}} + {{% tab "Ruby" %}} + + ```ruby + it 'flaky validation test' do + expect(true).to be(true) + end + ``` + + {{% /tab %}} + {{% tab ".NET" %}} + + ```csharp + [Fact] + public void FlakyValidationTest() + { + Assert.True(true); + } + ``` + + {{% /tab %}} + {{% tab "Go" %}} + + ```go + func TestFlakyValidationTest(t *testing.T) { + } + ``` + + {{% /tab %}} + {{% tab "Swift" %}} + + ```swift + func testFlakyValidationTest() { + XCTAssertTrue(true) + } + ``` + + {{% /tab %}} + {{< /tabs >}} + +4. Confirme la corrección con la clave generada en el cuerpo de la confirmación. Reemplace `` con la clave que copió: + + ```bash + git add -A + git commit -m "Fix flaky validation test" -m "" + git push origin validate-test-optimization + ``` + +5. Espere a que finalice la CI y, a continuación, confirme los siguientes resultados: + + - En [Test Runs][10], Attempt to Fix volvió a intentar el candidato a corrección y todos los intentos fueron exitosos. Utilice [esta consulta][10], que tiene los siguientes filtros: + - `@test.name:*flaky*validation*` + - `@git.branch:validate-test-optimization` + - `@test.test_management.is_attempt_to_fix:true` + - En [Flaky Test Management][14], la prueba está marcada como {{< ui >}}Fix in progress{{< /ui >}}. Utilice [esta consulta][14], que tiene los siguientes filtros: + - `@test.name:*flaky*validation*` + - `first_flaked_branch:validate-test-optimization` + - `fix_in_progress:true` + +### Paso 5: Limpieza posterior a la validación {#step-5-post-validation-cleanup} + +1. Cierre la solicitud de extracción sin fusionar. +2. Elimine la rama `validate-test-optimization`. La regla automática de cuarentena específica de la rama ya no se aplica después de que se elimina la rama, y el servicio de validación dedicado ya no recibe ejecuciones de prueba. +3. Notifique al equipo propietario del repositorio que el [New Flaky Test PR Gate][2] permanece activo para todo el repositorio. La puerta no es bloqueante de forma predeterminada. +4. Opcionalmente, habilite las funciones de Test Optimization configuradas para el servicio `validate-test-optimization` a nivel de repositorio. + +## Lecturas adicionales {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /es/tests/flaky_tests/early_flake_detection +[2]: /es/tests/guides/setup_new_flaky_pr_gate +[3]: https://app.datadoghq.com/ci/settings/ci-cd/repositories?tab=repository +[4]: /es/tests/flaky_tests/auto_test_retries +[5]: /es/tests/flaky_management +[6]: /es/tests/flaky_management/#configure-policies-to-automate-the-flaky-test-lifecycle +[7]: https://app.datadoghq.com/ci/test/runs?query=test_level%3Atest%20%40test.name%3A%2Aflaky%2Avalidation%2A%20%40git.branch%3Avalidate-test-optimization%20%40test.retry_reason%3Aearly_flake_detection%20%40test.test_management.is_new_flaky%3Atrue +[8]: https://app.datadoghq.com/ci/test/runs?query=test_level%3Atest%20%40test.name%3A%2Aflaky%2Avalidation%2A%20%40git.branch%3Avalidate-test-optimization%20%40test.retry_reason%3Aauto_test_retry +[9]: https://app.datadoghq.com/ci/test/flaky/explorer?query=%40test.name%3A%2Aflaky%2Avalidation%2A%20first_flaked_branch%3Avalidate-test-optimization%20flaky_test_state%3Aquarantined +[10]: https://app.datadoghq.com/ci/test/runs?query=test_level%3Atest%20%40test.name%3A%2Aflaky%2Avalidation%2A%20%40git.branch%3Avalidate-test-optimization%20%40test.test_management.is_attempt_to_fix%3Atrue +[11]: https://app.datadoghq.com/ci/pr-gates/rule/create?dataSource=test_optimization +[12]: /es/tests/ +[13]: /es/tests/test_impact_analysis/ +[14]: https://app.datadoghq.com/ci/test/flaky/explorer?query=%40test.name%3A%2Aflaky%2Avalidation%2A%20first_flaked_branch%3Avalidate-test-optimization%20fix_in_progress%3Atrue +[16]: /es/tests/flaky_management/#bits-ai-powered-flaky-test-fixes \ No newline at end of file diff --git a/hugo/content/es/tracing/trace_collection/single-step-apm/_index.md b/hugo/content/es/tracing/trace_collection/single-step-apm/_index.md index 49de4511992..51d32b71952 100644 --- a/hugo/content/es/tracing/trace_collection/single-step-apm/_index.md +++ b/hugo/content/es/tracing/trace_collection/single-step-apm/_index.md @@ -6,65 +6,78 @@ aliases: further_reading: - link: /tracing/metrics/runtime_metrics/ tag: Documentación - text: Habilitar métricas en tiempo de ejecución + text: Habilitar métricas de tiempo de ejecución - link: /tracing/guide/injectors tag: Documentación - text: Comprendiendo el comportamiento del inyector con la instrumentación de un - solo paso + text: Comprender el comportamiento del inyector con la instrumentación de un solo + paso - link: /tracing/trace_collection/automatic_instrumentation/single-step-apm/troubleshooting/ tag: Documentación - text: Solucionando problemas de APM de un solo paso -- link: https://learn.datadoghq.com/courses/troubleshooting-apm-instrumentation-on-a-host - tag: Centro de aprendizaje - text: Solucionando problemas de la instrumentación de APM en un servidor + text: Solución de problemas de APM de un solo paso - link: /tracing/guide/local_sdk_injection tag: Documentación - text: Instrumenta tus aplicaciones utilizando inyección de SDK local + text: Instrumente sus aplicaciones mediante la inyección de SDK local +- link: https://learn.datadoghq.com/courses/troubleshooting-apm-instrumentation-on-a-host + tag: Centro de aprendizaje + text: Solución de problemas de instrumentación de APM en un servidor - link: https://www.datadoghq.com/blog/datadog-csi-driver/ tag: Blog - text: Lleva la observabilidad de alto rendimiento a entornos de Kubernetes seguros + text: Lleve la observabilidad de alto rendimiento a entornos seguros de Kubernetes con el controlador CSI de Datadog - link: https://www.datadoghq.com/blog/rum-apm-single-step tag: Blog text: Habilite la visibilidad de extremo a extremo en sus aplicaciones Java con un solo comando +- link: https://www.datadoghq.com/blog/single-step-instrumentation-rules/ + tag: Blog + text: Administre el rastreo de servicios entre servidores con reglas de instrumentación + de un solo paso +- link: https://www.datadoghq.com/blog/choosing-apm-instrumentation/ + tag: Blog + text: 'De cero a trazas: elegir el método de instrumentación de APM adecuado para + su stack' title: Instrumentación de APM de un solo paso --- ## Descripción general {#overview} -La instrumentación de un solo paso (SSI) instala automáticamente los SDK de Datadog sin requerir configuración adicional, reduciendo el tiempo de incorporación de días a minutos. +La instrumentación de un solo paso (SSI) instala automáticamente los SDK de Datadog sin necesidad de configuración adicional, lo que reduce el tiempo de incorporación de días a minutos. -Para aprender más sobre cómo funciona, consulte la [guía del inyector para la instrumentación de un solo paso][8]. +Para obtener más información sobre cómo funciona, consulte la [guía del inyector para la instrumentación de un solo paso][8]. + +{{< skill-callout + title="Configurar APM con un Agent" + text="Install the `dd-apm` skill in your AI coding agent for guided APM setup." + action_name="copy_dd_apm_skill_install_cmd" >}} +npx skills add https://github.com/datadog-labs/agent-skills --skill dd-apm --full-depth -y +{{< /skill-callout >}} ## Requisitos previos {#prerequisites} -1. Elimine cualquier código de instrumentación personalizado de su aplicación y reiníciela. SSI se desactiva automáticamente si se detecta instrumentación personalizada. -1. Confirme la compatibilidad del entorno revisando la [guía de compatibilidad de SSI][18] para lenguajes, sistemas operativos y arquitecturas soportadas. +1. Elimine cualquier código de instrumentación personalizado de su aplicación y reiníciela. SSI se deshabilita automáticamente si se detecta instrumentación personalizada. +1. Confirme la compatibilidad del entorno revisando la [guía de compatibilidad de SSI][18] para conocer los lenguajes, sistemas operativos y arquitecturas compatibles. -## Instrumente SDKs en sus aplicaciones {#instrument-sdks-across-applications} +## Instrumentar SDKs en aplicaciones {#instrument-sdks-across-applications} -Cuando [instale o actualice el Agente de Datadog][1] con **instrumentación de APM** habilitada, el Agente instrumenta sus aplicaciones cargando el SDK de Datadog en procesos soportados. Esto permite el seguimiento distribuido al capturar y enviar datos de traza desde sus servicios sin requerir cambios en el código. +Cuando [instala o actualiza el Datadog Agent][1] con {{< ui >}}APM Instrumentation{{< /ui >}} habilitado, el Agent instrumenta sus aplicaciones cargando el Datadog SDK en los procesos compatibles. Esto permite el rastreo distribuido al capturar y enviar datos de traza desde sus servicios sin requerir cambios en el código. Después de la instrumentación, puede opcionalmente: -- [Configure Etiquetas de Servicio Unificadas (UST)][14] -- Habilite productos y características adicionales dependientes del SDK, como Continuous Profiler o Application Security Monitoring +- [configurar etiquetas de servicio unificado (UST, por sus siglas en inglés)][14] +- habilite productos y funciones adicionales que dependen del SDK, como Continuous Profiler o Application Security Monitoring Haga clic en uno de los siguientes mosaicos para aprender cómo configurar SSI para su tipo de implementación: {{< card-grid card_width="170px" image_width="200" >}} - {{< image-card href="linux/" src="integrations_logos/linux.png" alt="linux" >}} - {{< image-card href="docker/" src="integrations_logos/docker.png" alt="docker" >}} - {{< image-card href="kubernetes/" src="integrations_logos/kubernetes.png" alt="kubernetes" >}} - {{< image-card href="windows/" src="integrations_logos/windows.png" alt="windows" >}} + {{< image-card href="linux/" src="integrations_logos/linux.png" alt="Linux" >}} + {{< image-card href="docker/" src="integrations_logos/docker.png" alt="Docker" >}} + {{< image-card href="kubernetes/" src="integrations_logos/kubernetes.png" alt="Kubernetes" >}} + {{< image-card href="windows/" src="integrations_logos/windows.png" alt="Windows" >}} {{< /card-grid >}} -
- ## Solución de problemas {#troubleshooting} Si encuentra problemas al habilitar APM con SSI, consulte la [guía de solución de problemas de SSI][15]. -## Lectura adicional {#further-reading} +## Lecturas adicionales {#further-reading} {{< partial name="whats-next/whats-next.html" >}} diff --git a/hugo/content/fr/actions/forms/_index.md b/hugo/content/fr/actions/forms/_index.md new file mode 100644 index 00000000000..2250aa0bea4 --- /dev/null +++ b/hugo/content/fr/actions/forms/_index.md @@ -0,0 +1,183 @@ +--- +description: Créez des formulaires pour recueillir des entrées, analyser les réponses + et déclencher des automatisations. +disable_toc: false +further_reading: +- link: https://www.datadoghq.com/blog/datadog-forms + tag: Blog + text: Transformez les retours en actions au sein de votre organisation d'ingénierie + avec Datadog Forms +- link: https://www.datadoghq.com/blog/datadog-forms-sheets-developer-feedback/ + tag: Blog + text: Transformez les retours d'expérience des développeurs en informations opérationnelles + avec Datadog Forms et Sheets +title: Forms +--- +## Vue d'ensemble {#overview} + +Les formulaires Datadog vous permettent de recueillir des entrées, d'analyser les réponses et de déclencher des automatisations dans Datadog. Les formulaires et leurs réponses peuvent être partagés au sein de votre organisation, vous permettant de recueillir et d'analyser des données avec votre équipe. + +Quelques façons d'utiliser les formulaires : +- Créez la structure des services à partir de modèles prédéfinis. +- Sondez les retours d'expérience des ingénieurs dans un portail développeur interne (IDP). +- Créez des demandes de service et des [éléments de travail][1] pour les équipes de sécurité, de plateforme ou IT directement à partir des réponses aux formulaires des employés. + +## Créer un formulaire {#create-a-form} + +Sur la page [Forms][2], cliquez sur {{< ui >}}New Form{{< /ui >}}, puis sélectionnez une méthode de création : + +{{< tabs >}} +{{% tab "Créer avec l'IA" %}} +1. Sélectionnez {{< ui >}}Create with AI{{< /ui >}} et cliquez sur {{< ui >}}Continue{{< /ui >}}. L'éditeur de formulaire s'ouvre avec [Bits Chat][100]. +1. Décrivez le formulaire que vous souhaitez créer dans le panneau Bits Chat. +1. Cliquez sur {{< ui >}}Publish{{< /ui >}} ou {{< ui >}}Publish Changes{{< /ui >}} pour rendre le formulaire disponible aux répondants. + +Vous pouvez également demander à Bits Chat de créer un formulaire depuis n'importe où dans Datadog, et pas seulement depuis l'éditeur Forms. Consultez [Créer et gérer des formulaires avec MCP](#create-and-manage-forms-with-mcp). + +[100]: /fr/bits_ai/bits_chat/ + +{{% /tab %}} + +{{% tab "Formulaire vierge" %}} +1. Sélectionnez {{< ui >}}Start with a blank form{{< /ui >}} et cliquez sur {{< ui >}}Continue{{< /ui >}}. +1. Nommez votre formulaire et ajoutez éventuellement une description et une couleur de thème. Cliquez sur {{< ui >}}Continue{{< /ui >}}. +1. Pour ajouter un composant, cliquez sur {{< ui >}}Add Component{{< /ui >}}, ou dans le panneau {{< ui >}}Fields{{< /ui >}}, cliquez sur l'icône plus **+**. Consultez [Composants de formulaire][3] pour obtenir la liste complète des types de composants et leurs options. +1. Cliquez sur {{< ui >}}Publish{{< /ui >}} ou {{< ui >}}Publish Changes{{< /ui >}} pour rendre le formulaire disponible aux répondants. + +[3]: /fr/actions/forms/components/ + +{{% /tab %}} + +{{% tab "Blueprint" %}} +Les blueprints sont des formulaires de démarrage pour des cas d'utilisation courants, préchargés avec des exemples de questions. Certains blueprints incluent une automatisation préconfigurée. Les blueprints disponibles incluent Developer Experience Survey, IDP Feedback, Work Management Service Request, Report an Incident, Bug Report, On-Call Escalation, Post-Incident Review, et plus encore. + +1. Sélectionnez {{< ui >}}Create from blueprint{{< /ui >}} et parcourez les modèles disponibles. +1. Sélectionnez un blueprint et cliquez sur {{< ui >}}Continue{{< /ui >}}. +1. Nommez votre formulaire et ajoutez éventuellement une description et une couleur de thème. Cliquez sur {{< ui >}}Continue{{< /ui >}}. +1. Pour personnaliser davantage votre formulaire, consultez [Form components][3]. +1. Cliquez sur {{< ui >}}Publish{{< /ui >}} ou {{< ui >}}Publish Changes{{< /ui >}} pour rendre le formulaire disponible aux répondants. + + +[3]: /fr/actions/forms/components/ +{{% /tab %}} + +{{% tab "Importation" %}} +Vous pouvez importer un formulaire existant à partir d'un fichier PDF ou JSON. + +1. Sélectionnez {{< ui >}}Import a form{{< /ui >}}. Une boîte de dialogue d'importation s'ouvre. +1. Choisissez une source et suivez les instructions. +1. Nommez votre formulaire et ajoutez éventuellement une description et une couleur de thème. Cliquez sur {{< ui >}}Continue{{< /ui >}}. +1. Pour personnaliser davantage votre formulaire, consultez [Form components][3]. +1. Cliquez sur {{< ui >}}Publish{{< /ui >}} ou {{< ui >}}Publish Changes{{< /ui >}} pour rendre le formulaire disponible aux répondants. + + +[3]: /fr/actions/forms/components/ +{{% /tab %}} +{{< /tabs >}} + +Pour prévisualiser ou partager votre formulaire : +1. Cliquez sur {{< ui >}}Preview{{< /ui >}} pour afficher le formulaire tel qu'il apparaît aux répondants. +1. Cliquez sur {{< ui >}}Share{{< /ui >}} pour copier le lien du formulaire ou configurer les options de partage. + +## Form settings {#form-settings} + +Depuis la page [Forms][2], cliquez sur un formulaire pour l'ouvrir dans l'éditeur. Dans l'en-tête de l'éditeur, cliquez sur l'icône en forme de roue dentée pour accéder aux paramètres suivants : + +| Setting | Description | +|---------|-------------| +| Accepting Responses | Définissez le formulaire comme actif ou inactif. Lorsqu'il est inactif, le formulaire n'accepte pas de nouvelles réponses. Vous pouvez également définir une date de fin pour fermer automatiquement le formulaire à une date précise. Uniquement disponible pour les formulaires publiés. | +| Anonymous Responses | Lorsque cette option est activée, les adresses e-mail des répondants ne sont pas enregistrées. | +| Manage Permissions | Configurez qui peut afficher et modifier le formulaire, et qui peut consulter les réponses soumises. Consultez [Manage access](#manage-access). | +| Clone Form | Créez une copie du formulaire. | +| Import Form | Importez des champs depuis un fichier PDF ou JSON dans le formulaire actuel. | +| Export Form (JSON) | Téléchargez le formulaire sous forme de fichier JSON. | + +Pour plus d'informations sur la gestion des réponses, consultez [Form responses][4]. + +## Partager un formulaire {#share-a-form} + +Pour configurer le partage d'un formulaire : +1. Depuis la page [Forms][2], cliquez sur un formulaire. +1. Cliquez sur {{< ui >}}Share{{< /ui >}}. + +Les options de partage suivantes sont disponibles : + +{{% collapse-content title="Partager au sein de Datadog" level="h3" expanded=false %}} +Partagez le formulaire avec les utilisateurs de votre organisation Datadog. + +Sous {{< ui >}}Add to Dashboard{{< /ui >}}, utilisez le menu déroulant pour ajouter le formulaire à un dashboard existant ou pour créer un dashboard. + +Activez le toggle {{< ui >}}Add to IDP Self-Service Actions{{< /ui >}} pour afficher le formulaire dans le catalogue [Self-Service Actions][5]. Il s'agit d'un emplacement central où les équipes de plateforme et d'infrastructure publient des outils que le reste de l'organisation peut découvrir et utiliser. +{{% /collapse-content %}} + +{{% collapse-content title="Partager avec des utilisateurs externes" level="h3" expanded=false %}} +Partagez le formulaire avec des utilisateurs en dehors de votre organisation Datadog. Vous pouvez configurer une date d'expiration d'accès pour chaque option de partage et créer plusieurs configurations de partage avec des paramètres et des dates d'expiration différents. + +Les options suivantes sont disponibles : + +- **Specific individuals** : Ajoutez des destinataires par adresse e-mail individuelle. Par exemple, `alice@example.com` et `bob@example.com`. +- **Company domain** : Partagez avec toute personne disposant d'un domaine e-mail spécifique. Par exemple, `*@yourcompany.com`. +- **Shareable link** : Générez un lien que n'importe qui peut utiliser pour accéder au formulaire sans compte Datadog. +{{% /collapse-content %}} + +Pour suspendre ou supprimer le partage externe, cliquez sur {{< ui >}}Share{{< /ui >}}, puis cliquez sur {{< ui >}}Edit{{< /ui >}} et sélectionnez {{< ui >}}Pause Sharing{{< /ui >}} ou {{< ui >}}Delete Sharing{{< /ui >}}. + +Pour préremplir des champs dans un lien partagé afin que les répondants commencent avec certaines réponses déjà saisies, consultez [Préremplir les champs d'un formulaire][15]. + +## Ajouter un formulaire à un dashboard {#add-a-form-to-a-dashboard} + +Pour ajouter un formulaire à un dashboard depuis l'éditeur de formulaire : +1. Depuis la page [Formulaires][2], cliquez sur un formulaire pour l'ouvrir dans l'éditeur. +1. Cliquez sur le dropdown {{< ui >}}Share{{< /ui >}} et sélectionnez {{< ui >}}Share within Datadog{{< /ui >}}. +1. Sous {{< ui >}}Add to Dashboard{{< /ui >}}, sélectionnez un dashboard existant ou créez-en un, puis cliquez sur {{< ui >}}Add{{< /ui >}}. + +Vous pouvez également ajouter un formulaire à un dashboard directement depuis le dashboard : +1. Accédez à un [dashboard][6]. +1. Cliquez sur **Add Widgets** pour ouvrir le panneau latéral. +1. Cliquez sur l'onglet **Apps**. +1. Sélectionnez **Form Widget**. +1. Sélectionnez votre formulaire, puis cliquez sur {{< ui >}}Save{{< /ui >}}. + +## Add automation {#add-automation} + +Après avoir créé un formulaire, vous pouvez ajouter une [action][7] ou un [workflow blueprint][8] qui se déclenche automatiquement lorsqu'un formulaire est soumis. +1. Depuis la page [Forms][2], cliquez sur un formulaire. +1. En haut du formulaire, sélectionnez {{< ui >}}Automation{{< /ui >}}. +1. Choisissez une action ou un blueprint. +1. L'action ou le blueprint s'ouvre dans un workflow canvas, où vous pouvez [le modifier][9]. +1. Cliquez sur {{< ui >}}Create{{< /ui >}}. + +**Remarque** : Les automatisations déclenchées par des formulaires apparaissent sous [Workflow Automation][10]. + +## Create and manage Forms with MCP {#create-and-manage-forms-with-mcp} + +Connectez un agent IA externe au [Datadog MCP Server][11] pour créer, mettre à jour, publier et lire des formulaires ainsi que leurs réponses. Activez l'ensemble d'outils `forms` (ou `all`) lorsque vous vous [connectez au MCP Server][12]. Vous pouvez également demander à [Bits Chat][13] de créer un formulaire depuis n'importe où dans Datadog. Consultez [Forms][14] dans la référence des outils du Datadog MCP Server pour obtenir la liste complète des outils disponibles. + +## Manage access {#manage-access} + +Par défaut, seul le créateur d'un formulaire peut y accéder. Pour modifier les autorisations sur un formulaire : +1. Depuis la page [Formulaires][2], cliquez sur un formulaire pour l'ouvrir dans l'éditeur. +1. Dans l'en-tête de l'éditeur, cliquez sur l'icône d'engrenage . +1. Cliquez sur {{< ui >}}Manage Permissions{{< /ui >}}. Une fenêtre modale s'ouvre avec deux sections : + - **Form Access** : Contrôle qui peut consulter et modifier le formulaire. + - **Response Access** : Contrôle qui peut consulter les réponses soumises. Cette section n'est accessible qu'après que le formulaire ait reçu sa première soumission. + +## Lectures complémentaires {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /fr/incident_response/work_management/ +[2]: https://app.datadoghq.com/forms +[3]: /fr/actions/forms/components/ +[4]: /fr/actions/forms/responses/ +[5]: /fr/internal_developer_portal/self_service_actions/ +[6]: /fr/dashboards/ +[7]: https://app.datadoghq.com/actions/action-catalog/ +[8]: https://app.datadoghq.com/workflow/blueprints +[9]: /fr/actions/workflows/build/#build-a-workflow-with-the-workflow-builder +[10]: https://app.datadoghq.com/workflow +[11]: /fr/mcp_server/ +[12]: /fr/mcp_server/setup/#toolsets +[13]: /fr/bits_ai/bits_chat/ +[14]: /fr/mcp_server/tools/#forms +[15]: /fr/actions/forms/guide/prefill/ \ No newline at end of file diff --git a/hugo/content/fr/api/latest/agent-observability/batch-update-agent-observability-dataset-records/index.md b/hugo/content/fr/api/latest/agent-observability/batch-update-agent-observability-dataset-records/index.md new file mode 100644 index 00000000000..4b644d325b8 --- /dev/null +++ b/hugo/content/fr/api/latest/agent-observability/batch-update-agent-observability-dataset-records/index.md @@ -0,0 +1,3 @@ +--- +title: Mise à jour en lot des enregistrements du dataset Agent Observability +--- diff --git a/hugo/content/fr/api/latest/agent-observability/get-an-agent-observability-prompt/index.md b/hugo/content/fr/api/latest/agent-observability/get-an-agent-observability-prompt/index.md new file mode 100644 index 00000000000..c5ad539131b --- /dev/null +++ b/hugo/content/fr/api/latest/agent-observability/get-an-agent-observability-prompt/index.md @@ -0,0 +1,3 @@ +--- +title: Obtenez une invite d’Agent Observability +--- diff --git a/hugo/content/fr/api/latest/agent-observability/get-annotation-queue-label-schema/index.md b/hugo/content/fr/api/latest/agent-observability/get-annotation-queue-label-schema/index.md new file mode 100644 index 00000000000..c4b3f40cd06 --- /dev/null +++ b/hugo/content/fr/api/latest/agent-observability/get-annotation-queue-label-schema/index.md @@ -0,0 +1,3 @@ +--- +title: Obtenez le schéma d’étiquette de la file d’attente d’annotation +--- diff --git a/hugo/content/fr/api/latest/agent-observability/list-agent-observability-datasets/index.md b/hugo/content/fr/api/latest/agent-observability/list-agent-observability-datasets/index.md new file mode 100644 index 00000000000..98aee1377ad --- /dev/null +++ b/hugo/content/fr/api/latest/agent-observability/list-agent-observability-datasets/index.md @@ -0,0 +1,3 @@ +--- +title: Lister les jeux de données Agent Observability +--- diff --git a/hugo/content/fr/api/latest/agent-observability/list-events-for-an-agent-observability-experiment/index.md b/hugo/content/fr/api/latest/agent-observability/list-events-for-an-agent-observability-experiment/index.md new file mode 100644 index 00000000000..a6f12874685 --- /dev/null +++ b/hugo/content/fr/api/latest/agent-observability/list-events-for-an-agent-observability-experiment/index.md @@ -0,0 +1,3 @@ +--- +title: Listez les événements pour une expérience Agent Observability. +--- diff --git a/hugo/content/fr/api/latest/agent-observability/list-versions-of-an-agent-observability-prompt/index.md b/hugo/content/fr/api/latest/agent-observability/list-versions-of-an-agent-observability-prompt/index.md new file mode 100644 index 00000000000..174e4b66813 --- /dev/null +++ b/hugo/content/fr/api/latest/agent-observability/list-versions-of-an-agent-observability-prompt/index.md @@ -0,0 +1,3 @@ +--- +title: Lister les versions d'un Agent Observability prompt +--- diff --git a/hugo/content/fr/api/latest/data-deletion/cancels-a-data-deletion-request/index.md b/hugo/content/fr/api/latest/data-deletion/cancels-a-data-deletion-request/index.md new file mode 100644 index 00000000000..8863df31feb --- /dev/null +++ b/hugo/content/fr/api/latest/data-deletion/cancels-a-data-deletion-request/index.md @@ -0,0 +1,3 @@ +--- +title: Annule une demande de suppression de données +--- diff --git a/hugo/content/fr/api/latest/execution-policy/get-an-execution-policy/index.md b/hugo/content/fr/api/latest/execution-policy/get-an-execution-policy/index.md new file mode 100644 index 00000000000..89d440a2ab0 --- /dev/null +++ b/hugo/content/fr/api/latest/execution-policy/get-an-execution-policy/index.md @@ -0,0 +1,3 @@ +--- +title: Obtenez une politique d'exécution. +--- diff --git a/hugo/content/fr/api/latest/llm-observability/aggregate-agent-observability-experimentation/index.md b/hugo/content/fr/api/latest/llm-observability/aggregate-agent-observability-experimentation/index.md new file mode 100644 index 00000000000..a98431515c9 --- /dev/null +++ b/hugo/content/fr/api/latest/llm-observability/aggregate-agent-observability-experimentation/index.md @@ -0,0 +1,3 @@ +--- +title: Agréger l'expérimentation Agent Observability +--- diff --git a/hugo/content/fr/api/latest/product-analytics/list-the-entities-behind-a-retention-cell/index.md b/hugo/content/fr/api/latest/product-analytics/list-the-entities-behind-a-retention-cell/index.md new file mode 100644 index 00000000000..e290471ae0e --- /dev/null +++ b/hugo/content/fr/api/latest/product-analytics/list-the-entities-behind-a-retention-cell/index.md @@ -0,0 +1,3 @@ +--- +title: Listez les entités derrière une cellule de rétention +--- diff --git a/hugo/content/fr/byoc-logs/introduction/network.md b/hugo/content/fr/byoc-logs/introduction/network.md new file mode 100644 index 00000000000..693d54272b9 --- /dev/null +++ b/hugo/content/fr/byoc-logs/introduction/network.md @@ -0,0 +1,49 @@ +--- +aliases: +- /fr/cloudprem/introduction/network/ +further_reading: +- link: /byoc-logs/configure/ingress/ + tag: Documentation + text: Configuration de l'entrée de BYOC Logs +title: Network +--- +Ce document fournit une vue d'ensemble de la manière dont BYOC (Bring Your Own Cloud) Logs et Datadog communiquent entre eux. + +## Connexion inversée (par défaut) {#reverse-connection-default} + +Par défaut, les pods **searcher** de BYOC Logs initient une connexion WebSocket sortante vers Datadog en utilisant votre clé d'API. Chaque pod searcher de BYOC Logs maintient sa propre connexion vers `wss:///api/unstable/cloudprem-connection-gateway/connect`. + +Datadog recommande cette configuration car : +- **Aucun port entrant ne doit être ouvert** dans votre réseau. +- **Aucun enregistrement DNS ou entrée publique n'est requis.** +- La connexion est initiée depuis votre infrastructure, ce qui simplifie les politiques de pare-feu et de sécurité. + +### Ce qui transite par la connexion inversée {#what-flows-through-the-reverse-connection} + +| Données | Direction | Description | +|------|-----------|-------------| +| Requêtes de recherche | Datadog → BYOC Logs | Requêtes provenant du Log Explorer, des dashboards, des monitors | +| Résultats de requête | BYOC Logs → Datadog | Entrées de log correspondantes renvoyées pour affichage | +| Gestion des index | Datadog → BYOC Logs | Création, mise à jour, suppression d'index | + +### Exigences réseau {#network-requirements} + +Les pods searcher de BYOC Logs nécessitent **un accès HTTPS sortant (port 443)** à votre site Datadog (par exemple, `app.datadoghq.com`). Aucune connectivité entrante n'est requise. + +Si votre environnement utilise un proxy HTTP, BYOC Logs prend en charge la configuration standard du proxy avec les variables d'environnement `HTTPS_PROXY`, `ALL_PROXY` et `NO_PROXY`. + +### Quels pods se connectent à Datadog {#which-pods-connect-to-datadog} + +Seuls les pods **searcher** de BYOC Logs établissent la connexion inversée. Les indexeurs, le plan de contrôle, le metastore et le janitor n'initient aucune connexion vers Datadog. + +
Maintenez au moins un pod searcher de BYOC Logs en cours d'exécution lors de l'utilisation de la connexion inversée. Si tous les pods searcher de BYOC Logs sont indisponibles ou mis à l'échelle vers 0, Datadog ne peut pas acheminer les requêtes ou les demandes de gestion d'index via la connexion inversée tant qu'un pod searcher de BYOC Logs ne démarre pas et ne se reconnecte pas.
+ +## Entrée publique (facultatif) {#public-ingress-optional} + +Il est également possible de configurer BYOC Logs pour déployer une entrée public afin que Datadog puisse établir la connexion dans l'autre sens. + +L'entrée publique permet au plan de contrôle et au service de requête de Datadog de gérer et d'interroger les clusters BYOC Logs sur Internet public. Il fournit un accès sécurisé à l'API gRPC de BYOC Logs en utilisant l'authentification mTLS. Vous trouverez plus d'informations sur l'entrée de BYOC Logs sur sa [page de configuration](/byoc-logs/configure/ingress/). + +## Pour aller plus loin {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} \ No newline at end of file diff --git a/hugo/content/fr/coterm/usage.md b/hugo/content/fr/coterm/usage.md index ca179fbab36..8fff0b1ccc3 100644 --- a/hugo/content/fr/coterm/usage.md +++ b/hugo/content/fr/coterm/usage.md @@ -1,37 +1,36 @@ --- -description: Découvrir comment enregistrer des sessions de terminal, créer des shims - pour l'enregistrement automatique et configurer CoTerm pour se protéger contre les +description: Apprenez à enregistrer des sessions de terminal, à créer des shims pour + l'enregistrement automatique et à configurer CoTerm pour vous protéger contre les commandes dangereuses. further_reading: - link: /coterm - tag: documentation + tag: Documentation text: Datadog CoTerm - link: /coterm/install - tag: documentation + tag: Documentation text: Installer Datadog CoTerm - link: /coterm/rules - tag: documentation - text: Règles de configuration CoTerm -title: Utiliser Datadog CoTerm + tag: Documentation + text: Règles de configuration de CoTerm +title: Utilisation de Datadog CoTerm --- +## Afficher les sessions de terminal enregistrées {#view-recorded-terminal-sessions} +Au début et à la fin de chaque session de terminal enregistrée, CoTerm affiche un lien pour afficher la session dans Datadog. Vous pouvez également [afficher toutes les sessions de terminal enregistrées][7]. -## Consulter les sessions de terminal enregistrées -Au début et à la fin de chaque session de terminal enregistrée, CoTerm affiche un lien pour consulter la session dans Datadog. Vous pouvez également [consulter toutes les sessions de terminal enregistrées][7]. - -## Structure de commande de la CLI CoTerm +## Structure de commande de l'interface de ligne de commande CoTerm {#coterm-cli-command-structure} ```shell ddcoterm [OPTIONS] [-- ...] [COMMAND] ``` -Exécutez `ddcoterm --help` pour toutes les options et commandes. +Exécutez `ddcoterm --help` pour afficher toutes les options et commandes. -## Enregistrer une session de terminal +## Enregistrer une session de terminal {#record-a-terminal-session} -CoTerm enregistre des sessions de terminal que vous pouvez relire et consulter dans Datadog. Pour votre sécurité, les données sensibles (telles que les mots de passe et les clés d'API) sont [automatiquement supprimées][1]. Tous les processus lancés dans la session de terminal sont enregistrés en tant qu'[événements][2]. +CoTerm enregistre les sessions de terminal que vous pouvez lire et examiner dans Datadog. Pour votre sécurité, les données sensibles (telles que les mots de passe et les clés d'API) sont [automatiquement masquées][1]. Tous les processus lancés dans la session de terminal sont enregistrés en tant qu'[événements][2]. -### Lancer et enregistrer une session de terminal interactive -Pour lancer manuellement Datadog CoTerm et enregistrer l'intégralité de votre session de terminal : +### Lancer et enregistrer une session de terminal interactive {#launch-and-record-an-interactive-terminal-session} +Pour lancer manuellement Datadog CoTerm et enregistrer l'intégralité de votre session de terminal : ```shell ddcoterm @@ -39,18 +38,18 @@ ddcoterm Lorsque vous terminez la session, CoTerm arrête l'enregistrement et envoie les données de processus capturées à Datadog. -### Enregistrer la sortie d'une commande -Pour exécuter une commande individuelle et enregistrer sa sortie : +### Enregistrer la sortie d'une commande {#record-the-output-of-a-command} +Pour exécuter une commande individuelle et enregistrer sa sortie : ```shell ddcoterm -- datadog-agent status ``` -Cela lance CoTerm et exécute `datadog-agent status`. Lorsque le processus se termine, CoTerm arrête l'enregistrement et envoie les données de processus capturées à Datadog. +Ceci lance CoTerm et exécute `datadog-agent status`. Une fois le processus terminé, CoTerm arrête l'enregistrement et envoie les données de processus capturées à Datadog. -## Enregistrer automatiquement une commande +## Enregistrer automatiquement une commande {#automatically-record-a-command} -Pour configurer CoTerm afin d'enregistrer automatiquement toutes les invocations futures d'une commande particulière, créez un shim : +Pour configurer CoTerm afin d'enregistrer automatiquement toutes les futures invocations d'une commande particulière, créez un shim : ```shell ddcoterm shim create datadog-agent @@ -58,17 +57,17 @@ ddcoterm shim create datadog-agent Après avoir créé un shim, redémarrez votre terminal ou sourcez votre profil. (Par exemple, exécutez `source ~/.bashrc`.) Si vous utilisez un shell autre que Bash ou Zsh, ajoutez `path/to/.ddcoterm/overrides` à votre PATH manuellement. -## Protéger contre les commandes de terminal dangereuses +## Protéger contre les commandes de terminal dangereuses {#protect-against-dangerous-terminal-commands} -Pour éviter l'exécution accidentelle de commandes de terminal désignées, vous pouvez configurer CoTerm pour qu'il agisse comme un linter. Pour plus de contrôle, vous pouvez utiliser CoTerm avec la [gestion des cas Datadog][3] pour exiger une approbation pour les commandes désignées. +Pour empêcher l'exécution accidentelle de commandes de terminal désignées, vous pouvez configurer CoTerm pour agir comme un linter. Pour plus de contrôle, vous pouvez utiliser CoTerm avec [Datadog Work Management][3] pour exiger une approbation pour les commandes désignées. -### Linter une commande +### Analyser une commande {#lint-a-command} -Lorsque vous essayez d'exécuter une commande désignée (par exemple, `kubectl scale`), CoTerm peut afficher des avertissements et vous inviter à confirmer. +Lorsque vous essayez d'exécuter une commande désignée (par exemple, `kubectl scale`), CoTerm peut afficher des avertissements et vous demander une confirmation. -1. Créez un shim pour votre commande : `ddcoterm shim create kubectl` +1. Créer un shim pour votre commande : `ddcoterm shim create kubectl` -1. Configurez une règle de linting dans votre fichier `.ddcoterm/config.yaml`. Pour plus de détails sur la configuration du linting dans CoTerm, consultez la section [Règles de configuration CoTerm][4]. +1. Configurer une règle de linting dans votre fichier `.ddcoterm/config.yaml`. Pour plus de détails sur la configuration du linting dans CoTerm, consultez [Règles de configuration de CoTerm][4]. {{< code-block lang="yaml" filename=".ddcoterm/config.yaml" disable_copy="true" collapsible="true" >}} process_config: @@ -81,24 +80,24 @@ process_config: end {{< /code-block >}} -Avec cette configuration, CoTerm intercepte toute commande `kubectl scale` sans flag `--context`. +Avec cette configuration, CoTerm intercepte toute commande `kubectl scale` sans le flag `--context`. -{{< img src="coterm/linter-warning.png" alt="Interface de ligne de commande. L'utilisateur a exécuté 'kubectl scale foo'. La sortie indique 'Warning from CoTerm: No kubectl context specified (effective context: 'minikube'). It is recommended to always explicitly specify the context when running kubectl scale. Do you want to continue? (y/n)'" style="width:70%;" >}} +{{< img src="coterm/linter-warning.png" alt="Interface de ligne de commande. L'utilisateur a exécuté 'kubectl scale foo'. La sortie indique « Avertissement de CoTerm : Aucun contexte kubectl spécifié (contexte effectif : 'minikube') ». Il est recommandé de toujours spécifier explicitement le contexte lors de l'exécution de kubectl scale. Souhaitez-vous continuer ? (o/n)" style="width:70%;" >}} -### Exiger une approbation pour les commandes +### Exiger une approbation pour les commandes {#require-approval-for-commands} -Pour les commandes encore plus dangereuses, CoTerm peut exiger une approbation explicite d'un autre membre de l'équipe (via la gestion des cas) avant d'exécuter la commande. +Pour les commandes encore plus dangereuses, CoTerm peut exiger une approbation explicite par un autre membre de l'équipe (via Work Management) avant d'exécuter la commande. -1. Créez un shim pour votre commande : `ddcoterm shim create kubectl` +1. Créer un shim pour votre commande : `ddcoterm shim create kubectl` -2. Configurez l'exigence d'approbation dans votre fichier `.ddcoterm/config.yaml`. Pour plus de détails, consultez la section [Règles de configuration CoTerm][4]. +2. Configurer l'exigence d'approbation dans votre fichier `.ddcoterm/config.yaml`. Pour plus de détails, consultez les [Règles de configuration de CoTerm][4]. {{< code-block lang="yaml" filename=".ddcoterm/config.yaml" disable_copy="true" collapsible="true" >}} process_config: commands: - command: "kubectl" rules: - # Enregistrer et exiger une approbation pour toutes les exécutions de `kubectl scale` dans un contexte de production + # Record and require approval for all executions of `kubectl scale` in a production context - rule: | local applicable = has_arg("scale") and k8s_context:match("prod") local user_message = "Proceed with caution. This command may disrupt your Kubernetes cluster setup." @@ -107,17 +106,17 @@ process_config: actions: ["record", "logs", "process_info", "approval"] {{< /code-block >}} -Avec cette configuration, lorsque vous exécutez une commande `kubectl scale --context prod`, CoTerm crée une demande d'approbation dans la [gestion des cas][3]. Si vous choisissez d'associer la demande d'approbation à un [incident][5] actif, les autres intervenants en cas d'incident sont automatiquement ajoutés en tant qu'approbateurs. Une fois cette demande approuvée, votre commande s'exécute. Vous pouvez également configurer des [règles d'automatisation de cas][8] pour déclencher des workflows en fonction des demandes d'approbation. +Avec cette configuration, lorsque vous exécutez une commande `kubectl scale --context prod`, CoTerm crée une demande d'approbation dans [Work Management][3]. Si vous choisissez d'associer la demande d'approbation à un [incident][5] actif, les autres intervenants d'incident sont automatiquement ajoutés en tant qu'approbateurs. Une fois cette demande approuvée, votre commande s'exécute. Vous pouvez également configurer des [règles d'automatisation des éléments de travail][8] pour déclencher des workflows basés sur des demandes d'approbation. -#### Exiger manuellement une approbation +#### Exiger manuellement une approbation {#manually-require-approval} -Pour créer une demande d'approbation manuellement, exécutez : +Pour créer manuellement une demande d'approbation, exécutez : ```shell ddcoterm approve ``` -#### Contourner l'approbation +#### Contourner l'approbation {#bypass-approval} Pour contourner l'approbation et exécuter votre commande, définissez la variable d'environnement `COTERM_BREAK_GLASS`. @@ -127,15 +126,15 @@ Exemple : COTERM_BREAK_GLASS=true kubectl delete foo ``` -## Pour aller plus loin +## Lectures complémentaires {#further-reading} {{< partial name="whats-next/whats-next.html" >}} [1]: /fr/sensitive_data_scanner/ [2]: /fr/events/ -[3]: /fr/incident_response/case_management/ +[3]: /fr/incident_response/work_management/ [4]: /fr/coterm/rules [5]: /fr/incident_response/incident_management/ [6]: /fr/coterm/install [7]: https://app.datadoghq.com/terminal-streams -[8]: /fr/incident_response/case_management/automation_rules/ \ No newline at end of file +[8]: /fr/incident_response/work_management/automation_rules/ \ No newline at end of file diff --git a/hugo/content/fr/events/correlation/maintenance_windows.md b/hugo/content/fr/events/correlation/maintenance_windows.md new file mode 100644 index 00000000000..b570436a550 --- /dev/null +++ b/hugo/content/fr/events/correlation/maintenance_windows.md @@ -0,0 +1,41 @@ +--- +aliases: +- /fr/service_management/events/correlation/maintenance_windows/ +further_reading: +- link: events/correlation/ + tag: Documentation + text: En savoir plus sur la corrélation d'événements +title: Fenêtres de maintenance +--- +## Vue d'ensemble {#overview} +Datadog Event Management prend en charge les fenêtres de maintenance pour supprimer les notifications d'éléments de travail pendant la maintenance planifiée du système. Un élément de travail qui correspond à une condition de maintenance et qui survient pendant la fenêtre de maintenance sera automatiquement archivé. + +## Créer une fenêtre de maintenance {#create-a-maintenance-window} +
Vous devez disposer des autorisations d'écriture sur les paramètres partagés de gestion du travail (cases_shared_settings_write). Pour plus d'informations, consultez Datadog Role Permissions.
+ +Pour créer une [Fenêtre de maintenance][2] : +1. Accédez à {{< ui >}}Event Management Settings{{< /ui >}}. +1. Sélectionnez {{< ui >}}Maintenance Windows{{< /ui >}} à côté de **Work Item Attributes** dans la barre de navigation de gauche. +1. Cliquez sur {{< ui >}}New Maintenance Window{{< /ui >}} en haut à droite. +1. Saisissez un nom de fenêtre de maintenance. +1. Définissez les conditions pour les éléments de travail qui doivent être impactés par cette fenêtre de maintenance en utilisant des tags ou des attributs. Par défaut, les éléments de travail Event Management héritent des tags des alertes auxquelles ils sont corrélés. +1. Sélectionnez les heures de début et de fin de la fenêtre de maintenance. +1. Vérifiez les détails de la fenêtre de maintenance et cliquez sur {{< ui >}}Save{{< /ui >}}. + +Une fois enregistrée, votre fenêtre de maintenance sera ajoutée à la liste des fenêtres de maintenance où vous pourrez consulter ses détails, la mettre à jour en sélectionnant sa ligne, ou la supprimer en sélectionnant l'icône de corbeille à droite de la ligne. + +## Synchroniser les fenêtres de maintenance avec les changements ServiceNow {#sync-maintenance-windows-with-servicenow-changes} + +Pour synchroniser les fenêtres de maintenance avec les changements ServiceNow afin que vos changements ServiceNow créent, mettent à jour ou suppriment des fenêtres de maintenance d'éléments de travail : +1. Consultez [Transférer les demandes de changement vers Datadog][3] et suivez les étapes pour ingérer les changements ServiceNow. +1. Accédez à {{< ui >}}Event Management Settings{{< /ui >}}. +1. Sélectionnez {{< ui >}}Maintenance Windows{{< /ui >}} à côté de **Work Item Attributes** dans la barre de navigation de gauche. +1. Cliquez sur {{< ui >}}Sync from ServiceNow{{< /ui >}} en haut à droite +1. Optionnellement, définissez un filtre pour les changements ServiceNow qui doivent créer, mettre à jour ou supprimer des fenêtres de maintenance. +1. Définissez les conditions pour les éléments de travail qui doivent être impactés par cette fenêtre de maintenance en utilisant des tags ou des attributs. Vous pouvez référencer dynamiquement une valeur à partir de vos changements ServiceNow en faisant précéder l'attribut de `$`. +1. Définissez les champs de date et d'heure de changement ServiceNow qui doivent être utilisés pour les heures de début et de fin de la fenêtre de maintenance. + + +[1]: https://docs.datadoghq.com/fr/account_management/rbac/permissions/#case_management +[2]: https://app.datadoghq.com/event/settings/maintenance-windows +[3]: https://docs.datadoghq.com/fr/integrations/servicenow/?tab=changerequesteventforwarding#forward-change-request-events-to-datadog \ No newline at end of file diff --git a/hugo/content/fr/feature_flags/guide/migrate_from_statsig.md b/hugo/content/fr/feature_flags/guide/migrate_from_statsig.md new file mode 100644 index 00000000000..a10289298b2 --- /dev/null +++ b/hugo/content/fr/feature_flags/guide/migrate_from_statsig.md @@ -0,0 +1,292 @@ +--- +description: Apprenez à migrer les Feature Flags de Statsig vers Datadog Feature Flags. +further_reading: +- link: /feature_flags/ + tag: Documentation + text: Présentation des Feature Flags +- link: /feature_flags/client/ + tag: Documentation + text: Feature Flags côté client +- link: /feature_flags/server/ + tag: Documentation + text: Feature Flags côté serveur +title: Migrez vos Feature Flags de Statsig. +--- +## Présentation {#overview} + +Ce guide décrit le processus de migration de votre logique de migration des Feature Flags de Statsig vers [Datadog Feature Flags][1]. Il couvre les mappages conceptuels, l'installation du SDK, l'initialisation et l'évaluation des flags. + +## Liste de contrôle récapitulative {#summary-checklist} + +* Remplacez `@statsig/js-client` par `@datadog/openfeature-browser`. +* Échangez `statsig.initialize` avec `OpenFeature.setProviderAndWait`. +* Convertissez `checkGate` en `client.getBooleanValue`. +* Convertissez `getDynamicConfig` en `client.getObjectValue` ou `client.getStringValue`. +* Convertissez `getLayer` en `client.getObjectValue` et déréférencez les champs de l'objet JSON renvoyé. +* Utilisez `targetingKey` dans le contexte pour identifier les utilisateurs et piloter la randomisation basée sur le pourcentage. +* Recréez vos flags Statsig dans Datadog. +* Pour les applications côté serveur, utilisez `@openfeature/server-sdk` et transmettez un contexte d'évaluation par requête au lieu d'un contexte global unique. + +## Recréez les flags dans Datadog {#recreate-flags-in-datadog} + +Avant de modifier les appels SDK dans votre application, recréez vos gates, dynamic configs et layers Statsig en tant que flags dans Datadog. Dans l'interface utilisateur de Datadog, accédez à **Software Delivery** > **Feature Flags** et créez des flags qui correspondent à vos clés, types de variant et règles de ciblage Statsig. + +## Mappage conceptuel {#conceptual-mapping} + +Les concepts fondamentaux entre Statsig et Datadog sont similaires, mais la terminologie diffère légèrement. + +| Concept Statsig | Concept Datadog | Notes | +| :---- | :---- | :---- | +| **Feature Gate** | **Feature Flag** (booléen) | Basculements marche/arrêt de base. | +| **Dynamic Config** | **Feature Flag** (JSON/String variants) | Les Feature Flags dans Datadog peuvent renvoyer des chaînes, du JSON ou des nombres, couvrant les cas d'utilisation de Dynamic Config de Statsig. | +| **Layer** | **Feature Flag** (JSON variant) | Utilisez un feature flag à valeur JSON et lisez les champs de l'objet renvoyé, de manière similaire au déréférencement d'une Statsig layer. | +| **Experiment** | **Feature Flag** (with targeting) | Un feature flag Datadog peut être configuré avec des déploiements basés sur des pourcentages et des règles de ciblage spécifiques pour exécuter des experiments. Connectez les Feature Flags à [Datadog Experiments][5] pour mesurer l'impact sur les résultats utilisateur. | +| **User/StatsigUser** | **Evaluation Context** | Le contexte (attributs) transmis au SDK pour évaluer les Feature Flags. | + +## Installation {#installation} + +Datadog conçoit ses SDK de Feature Flags pour une utilisation avec [OpenFeature][6]. Cela fournit une API indépendante du fournisseur tout en utilisant Datadog comme fournisseur sous-jacent. + +Supprimez Statsig : + +{{< code-block lang="bash" >}} +npm uninstall @statsig/js-client +# or +yarn remove @statsig/js-client +{{< /code-block >}} + +Installez Datadog et OpenFeature : + +{{< code-block lang="bash" >}} +npm install @datadog/openfeature-browser @openfeature/web-sdk @openfeature/core +# or +yarn add @datadog/openfeature-browser @openfeature/web-sdk @openfeature/core +{{< /code-block >}} + +**Remarque** : Pour les applications React, installez également `@openfeature/react-sdk`. Consultez [React Feature Flags][7]. Pour les implémentations côté serveur, consultez la section [Contexte côté serveur et dynamique](#server-side-and-dynamic-context), ou [Server-Side Feature Flags][2] pour d'autres langages. + +## Initialisation {#initialization} + +Vous devez remplacer l'appel `statsig.initialize()` par la configuration du fournisseur OpenFeature. Transmettez le contexte d'évaluation à `setProviderAndWait` au moment de l'enregistrement afin que les Feature Flags soient évalués pour le bon utilisateur dès le départ. + +### Statsig (ancien) {#statsig-old} + +{{< code-block lang="javascript" >}} +import { StatsigClient } from '@statsig/js-client'; + +const client = new StatsigClient('client-sdk-key', { userID: 'user-123' }); +await client.initializeAsync(); +{{< /code-block >}} + +### Datadog (nouveau) {#datadog-new} + +{{< code-block lang="javascript" >}} +import { DatadogProvider } from '@datadog/openfeature-browser'; +import { OpenFeature } from '@openfeature/web-sdk'; +{{< /code-block >}} + +{{< code-block lang="javascript" >}} +// Configure the Datadog provider +const provider = new DatadogProvider({ + clientToken: '', + applicationId: '', + site: 'datadoghq.com', // or datadoghq.eu, etc. + env: 'production', // Environment from which to fetch flag configurations +}); + +// Set the evaluation context and register the provider together +const evaluationContext = { + targetingKey: 'user-123', // Identifies the user and drives percentage-based randomization + email: 'employee@company.com', + plan: 'premium', +}; + +await OpenFeature.setProviderAndWait(provider, evaluationContext); +{{< /code-block >}} + +
Le targetingKey est utilisé comme sujet de randomisation pour le ciblage basé sur le pourcentage. Lorsqu'un indicateur cible un pourcentage de sujets (par exemple, 50 %), le targetingKey détermine dans quel bucket se trouve un utilisateur. Les utilisateurs ayant le même targetingKey reçoivent toujours la même variante pour un indicateur donné.
+ +Pour plus d'informations sur la création de jetons client et d'identifiants d'application, consultez [Clés d'API et d'application][4]. + +## Évaluer les Feature Flags (vérifier les gates) {#evaluate-flags-check-gates} + +Remplacez les appels `checkGate` par ceux d'`getBooleanValue` d'OpenFeature. + +### Statsig (ancien) {#statsig-old-1} + +{{< code-block lang="javascript" >}} +const isEnabled = client.checkGate('new_homepage_design'); + +if (isEnabled) { + // Show new design +} else { + // Show old design +} +{{< /code-block >}} + +### Datadog (nouveau) {#datadog-new-1} + +{{< code-block lang="javascript" >}} +const client = OpenFeature.getClient(); + +// The second argument is the fallback value (default) if the flag fails to fetch +const isEnabled = client.getBooleanValue('new_homepage_design', false); + +if (isEnabled) { + // Show new design +} else { + // Show old design +} +{{< /code-block >}} + +## Obtenir la configuration (dynamic configs) {#get-configuration-dynamic-configs} + +Si vous utilisiez `getDynamicConfig` ou `getExperiment` pour récupérer des valeurs non booléennes (chaînes, JSON, nombres), utilisez la méthode typée appropriée dans OpenFeature. + +### Statsig (ancien) {#statsig-old-2} + +{{< code-block lang="javascript" >}} +const config = client.getDynamicConfig('banner_config'); +const title = config.get('title', 'Welcome'); +{{< /code-block >}} + +### Datadog (nouveau) {#datadog-new-2} + +{{< code-block lang="typescript" >}} +const client = OpenFeature.getClient(); + +// Assuming your Datadog flag 'banner_config' returns a JSON object variant +const bannerConfig = client.getObjectValue<{ title: string }>('banner_config', { title: 'Welcome' }); +const title = bannerConfig.title; +{{< /code-block >}} + +## Mapper les layers aux Feature Flags d'objet JSON {#map-layers-to-json-object-flags} + +Les Statsig layers regroupent les paramètres associés sous une seule évaluation. Dans Datadog, utilisez un feature flag à valeur JSON et lisez les champs dont vous avez besoin à partir de l'objet renvoyé. + +### Statsig (ancien) {#statsig-old-3} + +{{< code-block lang="javascript" >}} +const layer = client.getLayer('user_promo_experiments'); +const promoTitle = layer.get('title', 'Welcome to Statsig!'); +const discount = layer.get('discount', 0.1); +{{< /code-block >}} + +### Datadog (nouveau) {#datadog-new-3} + +{{< code-block lang="typescript" >}} +const client = OpenFeature.getClient(); + +const promoConfig = client.getObjectValue<{ title: string; discount: number }>('user_promo_experiments', { + title: 'Welcome!', + discount: 0.1, +}); +const promoTitle = promoConfig.title; +const discount = promoConfig.discount; +{{< /code-block >}} + +## Mettre à jour le contexte utilisateur après la connexion {#update-user-context-after-login} + +Statsig met à jour le contexte utilisateur en utilisant `updateUser`. Dans OpenFeature et Datadog, mettez à jour le contexte après l'initialisation avec `OpenFeature.setContext()`, par exemple après la connexion d'un utilisateur. + +### Statsig (ancien) {#statsig-old-4} + +{{< code-block lang="javascript" >}} +await client.updateUserAsync({ + userID: 'user-456', + email: 'employee@company.com', + custom: { plan: 'premium' }, +}); +{{< /code-block >}} + +### Datadog (nouveau) {#datadog-new-4} + +{{< code-block lang="javascript" >}} +// Update the context for all future flag evaluations +await OpenFeature.setContext({ + targetingKey: 'user-456', // Identifies the user and drives percentage-based randomization + email: 'employee@company.com', + plan: 'premium', +}); +{{< /code-block >}} + +## Tracking and Exposure {#tracking-and-exposure} + +Dans Statsig, la vérification d'un gate enregistre automatiquement une exposure. + +Dans Datadog, la télémétrie des Feature Flags se divise en deux catégories : + +**Exposure logging** enregistre le fait qu'un sujet a reçu une flag variant spécifique. Chaque événement d'exposure inclut la flag key, la flag variant servie et le contexte d'évaluation. Utilisez les données d'exposure pour analyser les résultats des experiments et l'adoption des fonctionnalités. + +**Evaluation logging** enregistre la fréquence à laquelle chaque flag variant est renvoyée. Les SDK clients envoient des comptes d'évaluation agrégés par défaut. Les SDKs serveur n'émettent la métrique `feature_flag.evaluations` qu'après l'activation de l'evaluation logging. + +1. **SDKs client** : Exposure logging est activé par défaut. Le SDK envoie des exposure events à l'exposures intake. Vous pouvez les consulter dans la liste **Feature Flags**. Définissez `enableExposureLogging: false` dans la config `DatadogProvider` si vous n'avez pas besoin d'exposure tracking. + +
Paramètre enableRumFeatureFlagTracking par true peut avoir un impact sur les coûts RUM, car il ajoute des évaluations de Feature Flags aux événements RUM. Les deux enableExposureLogging et enableRumFeatureFlagTracking sont activés par défaut pour les SDKs client.
+ +2. **SDKs serveur** : Exposure logging est activé par défaut. Evaluation logging est désactivé par défaut. Pour envoyer des métriques d'évaluation depuis les SDK serveur, activez les métriques OpenTelemetry (par exemple, `DD_METRICS_OTEL_ENABLED=true`) et suivez les conseils spécifiques au langage dans [Server-Side Feature Flags][2]. + +## Contexte côté serveur et dynamique {#server-side-and-dynamic-context} + +Les sections précédentes couvrent la migration côté navigateur et côté client, où le contexte d'évaluation est généralement statique pendant toute la durée de la session d'un utilisateur. Les applications côté serveur utilisent un SDK différent et s'authentifient avec une clé d'API Datadog au lieu d'un jeton client. Elles construisent également généralement un nouveau contexte d'évaluation pour chaque requête entrante. + +Configurez les variables d'environnement requises avant d'initialiser le SDK serveur : + +{{< code-block lang="bash" >}} +DD_API_KEY= +DD_SITE= +DD_ENV= +{{< /code-block >}} + +Consultez [Server-Side Feature Flags][2] pour obtenir la liste complète des options de configuration de l'Agent et de l'application. + +Installez le SDK côté serveur. Cet exemple utilise le [SDK Feature Flags pour Node.js][3] : + +{{< code-block lang="bash" >}} +npm install dd-trace @openfeature/server-sdk +{{< /code-block >}} + +Enregistrez le fournisseur via le traceur Datadog : + +{{< code-block lang="javascript" >}} +import tracer from 'dd-trace'; +import { OpenFeature } from '@openfeature/server-sdk'; + +tracer.init(); + +await OpenFeature.setProviderAndWait(tracer.openfeature); +{{< /code-block >}} + +### Statsig (ancien) {#statsig-old-5} + +{{< code-block lang="javascript" >}} +// The Statsig server SDK takes the user in each call +const isEnabled = statsig.checkGate(user, 'new_homepage_design'); +{{< /code-block >}} + +### Datadog (nouveau) {#datadog-new-5} + +{{< code-block lang="javascript" >}} +const client = OpenFeature.getClient(); + +app.get('/my-endpoint', async (req, res) => { + const evaluationContext = { + targetingKey: req.session?.userID ?? 'unknown', + }; + + const isEnabled = await client.getBooleanValue('new_homepage_design', false, evaluationContext); + res.send(isEnabled ? 'New design' : 'Old design'); +}); +{{< /code-block >}} + +Le SDK navigateur utilise le contexte d'évaluation défini pour chaque évaluation de feature flag. Vous pouvez mettre à jour ce contexte avec `OpenFeature.setContext()` lorsque l'utilisateur se connecte ou que ses attributs changent. Le SDK serveur transmet plutôt un nouveau contexte d'évaluation dans chaque appel d'évaluation de feature flag, car un processus gère de nombreux utilisateurs différents. + +Pour les autres langages serveur, consultez [Server-Side Feature Flags][2]. + +[1]: /fr/feature_flags/ +[2]: /fr/feature_flags/server/ +[3]: /fr/feature_flags/server/nodejs/ +[4]: /fr/account_management/api-app-keys/ +[5]: /fr/experiments/ +[6]: https://openfeature.dev/ +[7]: /fr/feature_flags/client/react/ \ No newline at end of file diff --git a/hugo/content/fr/incident_response/_index.md b/hugo/content/fr/incident_response/_index.md new file mode 100644 index 00000000000..96321008bd5 --- /dev/null +++ b/hugo/content/fr/incident_response/_index.md @@ -0,0 +1,25 @@ +--- +cascade: + algolia: + rank: 70 +further_reading: +- link: https://app.datadoghq.com/release-notes?category=Incident%20Response + tag: Notes de version + text: Vérifiez les dernières versions de Datadog Incident Response ! (Connexion + à l'application requise). +title: Incident Response +--- +## Composants {#components} + +{{< whatsnext desc="Explorez les composants d'Incident Response" >}} + {{< nextlink href="/incident_response/incident_management/" >}}Incident Management - Apprenez à gérer et à résoudre les incidents efficacement.{{< /nextlink >}} + {{< nextlink href="/incident_response/work_management/" >}}Gestion du travail - Suivez et organisez les éléments de travail liés aux incidents.{{< /nextlink >}} + {{< nextlink href="/incident_response/status_pages/" >}}Pages de statut - Communiquez le statut du système en temps réel avec des pages internes ou publiques.{{< /nextlink >}} + {{< nextlink href="/incident_response/on-call/" >}}Astreinte - Gérez les plannings d'astreinte et les rotations des intervenants.{{< /nextlink >}} +{{< /whatsnext >}} + + + +## Lectures complémentaires {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} \ No newline at end of file diff --git a/hugo/content/fr/incident_response/incident_management/investigate/declare.md b/hugo/content/fr/incident_response/incident_management/investigate/declare.md new file mode 100644 index 00000000000..6c63e79e74c --- /dev/null +++ b/hugo/content/fr/incident_response/incident_management/investigate/declare.md @@ -0,0 +1,133 @@ +--- +aliases: +- /fr/service_management/incident_management/declare/ +- /fr/incident_response/incident_management/declare +title: Déclarer un incident +--- +## Présentation {#overview} + +Dans Datadog, les situations suivantes entraînent la déclaration d'un incident : +- Un problème impacte ou pourrait impacter les clients. +- Vous estimez qu'un problème (y compris un problème interne) doit être traité en urgence. +- Vous ne savez pas si vous devez déclarer un incident - prévenez d'autres personnes et augmentez la gravité de manière appropriée. + +Vous pouvez déclarer un incident depuis plusieurs endroits au sein de la plateforme Datadog, comme un widget de graphique sur un dashboard, l'interface utilisateur des incidents ou toute alerte signalée dans Datadog. + +## Fenêtre modale de déclaration {#declaration-modal} + +Lorsque vous déclarez un incident, une fenêtre modale de déclaration apparaît. Cette fenêtre modale comporte plusieurs éléments principaux : + +| Éléments de l'incident | Description | +| ------------------ | ----------- | +| Titre | (Requis) Un titre descriptif pour l'incident. | +| Niveau de gravité | (Requis) Par défaut, la gravité varie de SEV-1 (la plus grave) à SEV-5 (la moins grave). Vous pouvez personnaliser le nombre de niveaux de gravité et leurs descriptions dans les paramètres d'Incident Management. +| Commandant d'incident | La personne désignée pour diriger la réponse à l'incident. | + +Vous pouvez configurer les [Paramètres d'Incident Management][2] pour inclure davantage de champs dans la fenêtre modale de déclaration d'incident ou pour rendre certains champs obligatoires. + + +## Depuis la page Incident {#from-the-incident-page} + +Dans l'[interface utilisateur Datadog][1], cliquez sur **Déclarer un incident** pour créer un incident. + +La fenêtre modale *Déclarer un incident* affiche un panneau latéral rétractable qui contient du texte d'aide et des descriptions pour les niveaux de gravité et les statuts utilisés par votre organisation. Le texte d'aide et les descriptions sont personnalisables dans les [Paramètres des incidents][2]. + +## Depuis un monitor {#from-a-monitor} + +Vous pouvez déclarer un incident directement depuis un monitor. Sélectionnez **Déclarer un incident** pour ouvrir une fenêtre modale de création d'incident, et le monitor est ajouté à l'incident en tant que signal. Vous pouvez également ajouter un monitor à un incident existant. + +{{< img src="incident_response/incident_management/investigate/declare/declare_monitor.png" alt="Menu déroulant Actions sur les monitors où vous pouvez sélectionner l'option Déclarer un incident" style="width:50%;" >}} + +Alternativement, vous pouvez configurer un monitor pour qu'il crée automatiquement un incident lorsqu'il passe à un statut `warn`, `alert` ou `no data`. Pour activer cette option, cliquez sur **Ajouter un incident** dans la section **Configurer les notifications et les automatisations** d'un monitor et sélectionnez une option `@incident-`. Les administrateurs peuvent créer des options `@incident-` dans [Incident Settings][9]. + +Les incidents créés à partir d'un monitor hériteront des [valeurs de champ][10] des tags du monitor. Pour envoyer des notifications automatisées à partir d'incidents, ajoutez des tags à un monitor afin que les incidents créés correspondent aux critères des [règles de notification][11]. + +## À partir d'un signal de sécurité {#from-a-security-signal} + +Déclarez un incident directement depuis le panneau latéral d'un signal Cloud SIEM ou Workload Protection, en cliquant sur **Déclarer un incident** ou **Escalader l'investigation**. Pour plus d'informations, consultez [Investigate Security Signals][3]. + +Déclarez un incident à partir d'un signal App and API Protection via les actions listées dans le panneau latéral du signal. Cliquez sur **Afficher toutes les actions** puis sur **Déclarer un incident**. +Pour plus d'informations, consultez [Investigate Security Signals][4] pour App and API Protection. + +{{< img src="/incident_response/incident_management/investigate/declare/declare_asm.png" alt="Description de votre image" style="width:90%;" >}} + +## À partir d'un secret divulgué {#from-a-leaked-secret} + +Déclarez un incident depuis [Secret Scanning][15] en cliquant sur **Déclarer un incident** dans le panneau latéral de détection. L'incident est pré-rempli avec toutes les métadonnées de détection. + +{{< img src="/incident_response/incident_management/investigate/declare/declare-secrets.png" alt="Description de votre image" style="width:90%;" >}} + +## À partir d'un élément de travail {#from-a-work-item} + +Déclarez un incident depuis [Work Management][5]. Depuis la page de détails de l'élément de travail individuel, cliquez sur **Déclarer un incident** pour faire passer un élément de travail en incident. + +## À partir d'un graphique {#from-a-graph} +Vous pouvez déclarer un incident directement depuis un graphique en cliquant sur le bouton d'exportation du graphique, puis en cliquant sur **Déclarer un incident**. La fenêtre modale de création d'incident s'affiche et le graphique est ajouté à l'incident en tant que signal. + +{{< img src="incident_response/incident_management/from-a-graph.png" alt="Créer un incident à partir d'un graphique" style="width:80%;">}} + +## Depuis un test Synthetic {#from-a-synthetic-test} + +Créez des incidents directement à partir d'un [test Synthetic][8] via le menu déroulant Actions. Sélectionnez **Déclarer un incident** pour ouvrir une fenêtre modale de création d'incident, où un résumé du test est ajouté à votre chronologie d'incident, vous permettant de poursuivre l'investigation à partir de là. + +{{< img src="incident_response/incident_management/investigate/declare/synthetics_declare_incident.png" alt="Déclarer un incident à partir d'un test Synthetic." style="width:90%;" >}} + +## Depuis le presse-papiers Datadog {#from-the-datadog-clipboard} +Utilisez le [presse-papiers Datadog][6] pour rassembler plusieurs monitors et graphiques et générer un incident. Pour déclarer un incident depuis le presse-papiers, copiez un graphique que vous souhaitez examiner et ouvrez le presse-papiers avec la commande `Cmd/Ctrl + Shift + K`. Cliquez sur **Déclarer un incident** ou sur l'icône d'exportation pour l'ajouter à l'incident en tant que signal. + +{{< img src="incident_response/incident_management/investigate/declare/declare_clipboard.png" alt="Déclarer un incident depuis le presse-papiers Datadog" style="width:90%;" >}} + +## Depuis une page Datadog On-Call {#from-a-datadog-on-call-page} + +Vous pouvez déclarer un incident directement depuis une [page Datadog On-Call][12]. Depuis la [liste des pages On-Call][13], sélectionnez une page et cliquez sur **Déclarer un incident** pour créer un incident et l'associer automatiquement à l'équipe d'astreinte concernée. + +## Depuis Slack {#from-slack} + +Si vous avez [activé l'intégration Datadog sur Slack][7], vous pouvez déclarer un nouvel incident avec la commande slash `/datadog incident` depuis n'importe quel canal Slack. + +Si l'utilisateur qui déclare l'incident a connecté son compte Slack à son compte Datadog, cet utilisateur est répertorié par défaut comme commandant d'incident. Le commandant d'incident (IC) peut être modifié ultérieurement dans l'application si nécessaire. Si l'utilisateur qui déclare un incident n'est pas membre d'un compte Datadog, l'IC est attribué à un `Slack app user` générique et peut être réattribué à un autre IC dans l'application. + +{{< img src="incident_response/incident_management/from-slack.png" alt="Créer un incident depuis Slack" style="width:60%;">}} + +Après avoir déclaré un incident depuis Slack, cela génère un canal d'incident. + +## Depuis Google Chat {#from-google-chat} + +Si vous avez configuré l'[intégration Datadog pour Google Chat][14], vous pouvez déclarer un incident avec la commande slash `/dd_incident` depuis n'importe quel espace Google Chat. + +## Depuis Handoff Notifications {#from-handoff-notifications} + +Handoff Notification affiche des cartes d'appel lorsque vous êtes appelé ou ajouté à des incidents actifs. Ces cartes vous permettent de : + +- Afficher et accuser réception des pages On-Call +- Naviguer vers les ressources d'incident pertinentes +- Prévisualiser les messages Slack des canaux d'incident +- Prendre des mesures directes sur les incidents + +{{< img src="/incident_response/incident_management/investigate/declare/handoff_notification_card.png" alt="Carte de notification de transfert affichant les détails de l'incident avec des options pour afficher, accuser réception et prendre des mesures" style="width:100%;" >}} + +Les cartes de notification de transfert restent visibles jusqu'à ce qu'elles soient fermées ou que le statut de l'incident change. Vous pouvez développer, réduire ou fermer l'intégralité du conteneur de transfert plutôt que des cartes individuelles. + +Vous pouvez déclarer un incident à partir de cartes de notification de transfert individuelles. + +## Prochaines étapes {#whats-next} + +{{< whatsnext desc="Ajoutez des informations utiles à votre incident et donnez du contexte à toutes les personnes impliquées dans l'enquête.">}} + {{< nextlink href="/incident_response/incident_management/investigate/describe" >}}Décrire l'incident : Ajouter du contexte et des détails{{< /nextlink >}} +{{< /whatsnext >}} + +[1]: https://app.datadoghq.com/incidents +[2]: /fr/incident_response/incident_management/setup_and_configuration/information +[3]: /fr/security/workload_protection/investigate_and_triage/security_signals/actions/#declare-an-incident +[4]: /fr/security/application_security/threat_protection/security_signals/#declare-an-incident +[5]: /fr/incident_response/work_management/view_and_manage +[6]: /fr/dashboards/guide/datadog_clipboard +[7]: /fr/integrations/slack/?tab=slackapplicationbeta#using-the-slack-app +[8]: https://app.datadoghq.com/synthetics/tests +[9]: https://app.datadoghq.com/incidents/settings?section=global-settings +[10]: /fr/incident_response/incident_management/setup_and_configuration/property_fields +[11]: /fr/incident_response/incident_management/setup_and_configuration/notification_rules +[12]: /fr/incident_response/on-call/ +[13]: https://app.datadoghq.com/on-call/pages +[14]: /fr/integrations/google-hangouts-chat/ +[15]: /fr/security/code_security/secret_scanning/ \ No newline at end of file diff --git a/hugo/content/fr/incident_response/incident_management/post_incident/follow-ups.md b/hugo/content/fr/incident_response/incident_management/post_incident/follow-ups.md new file mode 100644 index 00000000000..55990f2b1cc --- /dev/null +++ b/hugo/content/fr/incident_response/incident_management/post_incident/follow-ups.md @@ -0,0 +1,117 @@ +--- +algolia: + tags: + - follow ups + - follow-up + - follow up +aliases: +- /fr/service_management/incident_management/follow-ups/ +- /fr/incident_response/incident_management/follow-ups +description: Gérez les tâches de suivi définies au cours de votre processus de réponse + aux incidents. +further_reading: +- link: /incident_response/incident_management/setup_and_configuration + tag: Documentation + text: Paramètres d'incident +- link: /service_management/incident_management/integrations/slack/ + tag: Documentation + text: Intégrez Slack à Datadog Incident Management +title: Suivis d'incident +--- +## Vue d'ensemble {#overview} + +Les suivis d'incident sont des tâches effectuées après la résolution d'un incident. Lors d'une enquête sur un incident, votre équipe peut identifier des problèmes nécessitant une attention particulière mais qui ne sont pas directement liés à la résolution du problème immédiat. Plutôt que de perdre la trace de ces éléments dans la précipitation pour rétablir le service, vous pouvez les capturer en tant que suivis à traiter une fois l'incident résolu. + +Voici des exemples courants de création de suivis : + +- **Améliorations de l'infrastructure** : logs mal configurés, alertes manquantes ou couverture de surveillance inadéquate découverte pendant l'incident +- **Dette technique** : code nécessitant une refactorisation, systèmes fragiles à renforcer ou documentation à mettre à jour +- **Améliorations des processus** : lacunes dans les runbooks, chemins d'escalade flous ou autorisations d'accès manquantes +- **Correctifs de cause racine** : problèmes sous-jacents nécessitant plus de temps pour être traités que l'atténuation immédiate + +En consignant ces éléments en tant que suivis, votre équipe peut rester concentrée sur la résolution de l'incident tout en s'assurant que les améliorations importantes ne sont pas oubliées. + +## Tâches de suivi suggérées par l'IA {#ai-suggested-follow-up-tasks} + +{{< site-region region="gov" >}} +
Les tâches de suivi suggérées par l'IA ne sont pas prises en charge pour votre site Datadog sélectionné ({{< region-param key="dd_site_name" >}}).
+{{< /site-region >}} + +Une fois un incident résolu, Incident AI scanne le canal de l'incident à la recherche de tâches de suivi mentionnées par les intervenants pendant l'incident. Ensuite, Incident AI vous invite à les examiner et à les créer en un seul clic. Les tâches enregistrées de cette manière apparaissent en tant que Incident Follow-ups dans Datadog Incident Management. + +Pour afficher les tâches de suivi suggérées par l'IA : +1. Accédez à l'incident concerné dans Datadog. +1. Ouvrez l'onglet **Post-Incident** pour afficher une liste de toutes les tâches de suivi enregistrées depuis Slack. + +## Créer et gérer des suivis {#create-and-manage-follow-ups} + +Les suivis peuvent être créés à tout moment pendant un incident (même avant sa résolution), ce qui permet aux intervenants de documenter le travail nécessaire au fur et à mesure qu'ils le découvrent. Après la résolution, vous pouvez [exporter les suivis](#export-follow-ups) vers Jira ou Work Management pour les intégrer aux workflows existants de votre équipe. + +**Depuis Datadog** : Accédez à l'onglet **Post-Incident** de l'incident pour générer une vue, créer, modifier et suivre tous les suivis associés à l'incident. + +**Depuis Slack** : Dans le canal de l'incident, exécutez `/datadog followup` pour créer un nouveau suivi ou `/datadog followup list` pour générer une vue et gérer les suivis existants. Pour plus de commandes Slack, consultez [Integrate Slack with Datadog Incident Management][5]. + +## Suivis dans les carnets de post-mortem {#follow-ups-in-postmortem-notebooks} + +Vous pouvez afficher les suivis directement dans un notebook post-mortem en utilisant lavariable de modèle `{{incident.follow-ups}}`. Lorsqu'elle est ajoutée à un modèle de post-mortem de Datadog Notebooks, cette variable affiche une liste d'éléments de suivi. Depuis la vue en liste de Datadog Notebooks, vous pouvez définir des dates d'échéance, attribuer des éléments ou créer de nouveaux éléments de suivi. Pour plus d'informations, consultez [Incident Postmortems][6]. + +## Exporter les suivis {#export-follow-ups} + +Vous pouvez exporter les suivis depuis Incident Management vers Work Management ou Jira, ce qui vous permet de les suivre et de les gérer au sein des workflows existants de votre équipe. Vous pouvez exporter les suivis manuellement ou configurer Incident Management pour exporter automatiquement tous les suivis vers un projet Work Management ou Jira sélectionné. + +Pour exporter les suivis : +1. Accédez à [**Incident Management settings > Follow-Ups**][1]. +1. Ajoutez ou définissez un **export template** Un export template décrit la manière dont Datadog peut exporter et synchroniser un suivi. +1. Les types d'export template suivants sont pris en charge : + 1. [Work Management](#work-management-exports) + 1. [Jira](#jira-exports) +1. Lors de la définition d'un export template, vous pouvez configurer la manière dont Datadog doit définir les champs sur l'élément de travail Datadog ou le ticket Jira résultant, en utilisant les variables fournies par le suivi et son incident. Exemple : + * `{{ title }}` représente le titre de l'incident + * `{{ severity }}` représente la gravité de l'incident + * `{{ follow_up_description }}` représente la description du suivi + * `{{ follow_up_due_date }}` représente la date d'échéance du suivi +1. (Facultatif) Vous pouvez définir comment le statut est mappé entre les plateformes pour garantir que les changements de statut restent synchronisés sur les deux plateformes. Les suivis ont deux statuts : **Ouvert** et **Terminé**. + +### Exportations manuelles et automatiques {#manual-and-automatic-exports} + +Après avoir défini un export template, vous disposez de deux options : + +| Export Option | Description | When to Use | +|--------------------|--------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------| +| **Manual export** | Exportez des suivis individuels à la demande depuis l'onglet Post-Incident de l'incident. | Utilisez cette option si vous préférez exporter sélectivement uniquement certains suivis. | +| **Automatic export** | Configurez Incident Management pour exporter automatiquement tous les suivis à l'aide de l'export template dès leur création. | Choisissez cette option si vous souhaitez que tous les suivis soient suivis par défaut dans votre système externe. | + +### Work Management exports {#work-management-exports} + +Lorsque vous exportez vos suivis vers [Work Management][2], vous pouvez gérer, suivre et analyser vos suivis directement dans Datadog. Vous pouvez par exemple : + +* Créer une vue de tous les éléments de suivi ouverts assignés à un utilisateur particulier dans Datadog +* Créer un dashboard Datadog qui affiche les éléments de suivi par équipe +* Synchroniser automatiquement ces éléments avec toute application externe avec laquelle Work Management s'intègre, y compris Jira et ServiceNow + +Lorsque Datadog exporte un suivi d'incident vers Work Management, il crée un élément de travail pour le suivi dans le projet que vous avez sélectionné dans le modèle d'exportation. + +**Status syncing:** Datadog synchronise le statut entre le suivi et l'élément de travail **dans les deux sens**, en suivant le mappage que vous avez défini dans l'export template. + +**Assignee syncing:** Datadog synchronise le responsable entre le suivi et l'élément de travail **dans les deux sens**. Comme un élément de travail ne peut avoir qu'un seul responsable, seul le premier responsable du suivi y est ajouté. + + +### Jira exports {#jira-exports} + +Pour exporter des suivis vers Jira, vous devez d'abord installer l'intégration Jira. Pour plus d'informations, consultez [Integrate Jira with Datadog Incident Management][4]. + +Lorsque Datadog exporte un suivi d'incident vers Jira, il crée un ticket Jira pour le suivi dans le projet que vous avez sélectionné dans l'export template. + +**Status syncing:** Lorsque vous fermez ou ouvrez un suivi d'incident, Datadog synchronise automatiquement le statut du ticket Jira associé en fonction du mappage que vous avez défini dans l'export template. **Il s'agit d'une synchronisation unidirectionnelle.** + +Les organisations qui ont besoin d'une synchronisation bidirectionnelle doivent exporter vers un projet Work Management configuré pour une synchronisation bidirectionnelle avec un projet Jira. + +## Lectures complémentaires {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://app.datadoghq.com/incidents/settings?section=follow-ups +[2]: /fr/service_management/case_management +[4]: /fr/integrations/jira/ +[5]: /fr/service_management/incident_management/integrations/slack/#slack-commands +[6]: /fr/incident_response/incident_management/post_incident/postmortems \ No newline at end of file diff --git a/hugo/content/fr/integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose.md b/hugo/content/fr/integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose.md index 89f765c491e..7195008b9ca 100644 --- a/hugo/content/fr/integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose.md +++ b/hugo/content/fr/integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose.md @@ -1,4 +1,6 @@ --- +description: Diffusez les métriques CloudWatch vers Datadog via Amazon Data Firehose + pour une ingestion à faible latence. further_reading: - link: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Metric-Streams.html tag: Documentation @@ -6,81 +8,93 @@ further_reading: - link: https://www.datadoghq.com/blog/amazon-cloudwatch-metric-streams-datadog/ tag: Blog text: Recueillez des métriques Amazon CloudWatch à l'aide des flux de métriques. - title: Flux de métriques AWS CloudWatch avec Amazon Data Firehose --- -{{% site-region region="us3,gov" %}} -Les flux de métriques AWS CloudWatch avec Amazon Data Firehose ne sont pas disponibles pour le site Datadog ({{< region-param key="dd_site_name" >}}) que vous avez sélectionné. -{{% /site-region %}} - -Avec les flux de métriques Amazon CloudWatch et Amazon Data Firehose, vous pouvez transmettre des métriques CloudWatch à Datadog avec une latence de 2 à 3 minutes seulement. Cette approche est bien plus rapide que le processus d'interrogation de l'API Datadog par défaut, qui met à jour les métriques toutes les 10 minutes. Pour en savoir plus sur ce processus, consultez la [documentation relative au délai des métriques CloudWatch][1]. +En utilisant Amazon CloudWatch Metric Streams et Amazon Data Firehose, vous pouvez obtenir les métriques CloudWatch dans Datadog avec une latence de seulement deux à trois minutes. Ceci est nettement plus rapide que l'approche d'interrogation par API par défaut de Datadog, qui fournit des métriques mises à jour toutes les 10 minutes. Vous pouvez en savoir plus sur l'approche d'interrogation par API dans la [documentation sur le délai des métriques Cloud][1]. -## Présentation +## Présentation {#overview} -{{< img src="integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose/metric_streaming_diagram.png" alt="Diagramme du flux de métriques" responsive="true">}} +{{< img src="integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose/metric_streaming_diagram.png" alt="Diagramme du flux des métriques" responsive="true">}} -1. Créez un flux de métriques CloudWatch dans toutes les régions et tous les comptes AWS pour lesquels vous souhaitez diffuser des métriques. - - Vous pouvez également spécifier un ensemble limité d'espaces de nommage ou de métriques pour le flux. -2. Une fois le flux de métriques créé, Datadog commence immédiatement à recevoir les métriques diffusées et à les afficher sur le site de Datadog. Aucune configuration supplémentaire n'est requise. +1. Créez un flux de métriques CloudWatch dans chaque compte et région AWS pour lesquels vous souhaitez diffuser des métriques. + - Spécifiez éventuellement un ensemble limité d'espaces de nommage ou de métriques à diffuser. +2. Une fois le flux de métriques créé, Datadog commence immédiatement à recevoir les métriques diffusées et les affiche sur le site Datadog sans configuration supplémentaire nécessaire. +
Le filtrage par tag configuré dans la tuile d'intégration AWS s'applique également aux flux de métriques CloudWatch.
-### Comparaison entre les flux de métriques et l'API (#flux-de-metriques-et-api) +### Streaming de métriques par rapport à l'interrogation par API {#streaming-vs-polling} Les principales différences entre les flux de métriques CloudWatch et l'API sont les suivantes : -- **Filtrage par espace de nommage sur AWS** : les valeurs par défaut des espaces de nommage et les paramètres de compte de la page d'intégration AWS s'appliquent uniquement à l'API. Toutes les règles d'inclusion et d'exclusion d'espaces de nommage ou de métriques dans les flux doivent être gérées via la configuration des flux de métriques CloudWatch dans vos comptes AWS. +- **Métriques signalées avec un délai supérieur à deux heures** : l'interrogation par API continue de collecter des métriques comme `aws.s3.bucket_size_bytes` et `aws.billing.estimated_charges` après l'activation du streaming de métriques, car celles-ci ne peuvent pas être envoyées via CloudWatch Metric Stream. + +- **Métadonnées des métriques** : Datadog continue d'utiliser l'interrogation par API pour collecter des tags personnalisés et d'autres métadonnées pour vos métriques diffusées. Pour vous assurer de continuer à recevoir ces métriques, ne modifiez pas la configuration de l'intégration AWS. + +#### Passage de l'interrogation par API au streaming de métriques {#switching-from-api-polling-to-metric-streams} +Si vous recevez déjà des métriques pour un espace de nommage CloudWatch donné via la méthode d'interrogation par API, Datadog le détecte automatiquement et arrête d'interroger les métriques pour cet espace de nommage une fois que vous commencez à les diffuser. Laissez vos paramètres de configuration sur la page d'intégration AWS inchangés ; Datadog continue d'utiliser l'interrogation par API pour collecter des tags personnalisés et d'autres métadonnées pour vos métriques diffusées. + +#### Retour du streaming de métriques à l'interrogation par API {#switching-back-from-metric-streams-to-api-polling} + +Si vous décidez ultérieurement que vous ne souhaitez plus diffuser de métriques pour un compte et une région AWS donnés, ou même simplement pour un espace de nommage spécifique, Datadog recommence automatiquement à collecter ces métriques en utilisant l'interrogation par API en fonction des paramètres de configuration de la page d'intégration AWS. Si vous souhaitez arrêter la diffusion de toutes les métriques pour un compte et une région AWS, suivez les instructions de la section [Désactiver le streaming de métriques](#disable-metric-streaming) de ce document. -- **Métriques transmises avec plus de deux heures de retard** : l'API continue de recueillir des métriques telles que `aws.s3.bucket_size_bytes` et `aws.billing.estimated_charges` lorsque les flux de métriques sont activés, étant donné qu'elles ne peuvent pas être transmises via les flux de métriques CloudWatch. +#### Éviter les métriques en double pendant la migration {#avoiding-duplicate-metrics-during-migration} -#### Passer de l'API aux flux de métriques -Si vous recevez déjà des métriques pour un espace de nommage CloudWatch donné via l'API, Datadog détecte ce comportement et cesse de recueillir les métriques pour cet espace de nommage dès qu'elles commencent à être transmises via un flux de métriques. Veillez à ne pas modifier vos paramètres de configuration sur la page d'intégration AWS : Datadog continuera d'utiliser l'API pour récupérer les tags personnalisés et d'autres métadonnées sur vos métriques diffusées. +Lors du passage de l'interrogation par API aux flux de métriques, il existe une période de chevauchement où les deux méthodes de collecte peuvent envoyer des données pour les mêmes métriques. Cela peut entraîner un doublement des valeurs de métriques dans Datadog. -#### Passer des flux de métriques à l'API +Pour minimiser la duplication : +1. Activez les flux de métriques pour les espaces de noms et les régions souhaités. +2. Attendez que Datadog détecte le flux et arrête l'interrogation pour ces espaces de noms. Cette détection peut prendre jusqu'à cinq minutes, mais en pratique, la période de chevauchement peut durer plus longtemps en fonction du timing des crawlers d'interrogation actifs. +3. Vérifiez que la transition est terminée en consultant l'onglet **Collecte de métriques** sur la [page d'intégration AWS][5] pour les régions de flux activées. +4. Ne modifiez pas votre configuration d'intégration AWS existante pendant la transition. Datadog continue d'utiliser l'interrogation par API pour collecter des tags personnalisés et des métadonnées pour les métriques diffusées. -Si vous décidez ensuite que vous ne souhaitez plus utiliser les flux de métriques pour un compte et une région AWS donnés, ou même pour un espace de nommage spécifique, Datadog recommence automatiquement à recueillir ces métriques via l'API en fonction des paramètres définis sur la page d'intégration AWS. Si vous souhaitez désactiver complètement la diffusion de métriques pour un compte et une région AWS donnés, suivez les instructions indiquées à la rubrique [Désactiver la diffusion de métriques](#desactiver-la-diffusion-de-metriques) de ce document. +
+Certaines métriques ne peuvent pas être envoyées via les flux de métriques CloudWatch, notamment aws.s3.bucket_size_bytes et aws.billing.estimated_chargesDatadog continue de les collecter via l'interrogation par API, indépendamment de votre configuration de flux de métriques. +
-### Aide +### Facturation {#billing} Datadog ne facture pas de frais supplémentaires pour la diffusion des métriques. -La facturation AWS est basée sur le nombre de mises à jour de métriques dans le flux de métriques CloudWatch et sur le volume de données envoyées à Amazon Data Firehose. Il est possible que vos coûts CloudWatch augmentent pour le sous-ensemble de métriques que vous diffusez. Pour cette raison, Datadog vous recommande d'utiliser les flux de métriques pour les métriques, services, régions et comptes AWS pour lesquels vous avez le plus besoin d'une faible latence. Pour les autres, utilisez plutôt le processus d'interrogation. Pour en savoir plus, consultez la page [Tarification Amazon CloudWatch][1]. +AWS facture en fonction du nombre de mises à jour de métriques sur le flux de métriques CloudWatch et du volume de données envoyé à Amazon Data Firehose. Par conséquent, il est possible de constater une augmentation des coûts CloudWatch pour le sous-ensemble de métriques que vous diffusez. Pour cette raison, Datadog recommande d'utiliser les flux de métriques pour les métriques, services, régions et comptes AWS pour lesquels vous avez le plus besoin d'une latence plus faible, et l'interrogation par API pour les autres. Pour plus d'informations, consultez la [tarification d'Amazon CloudWatch][2]. -Les métriques EC2 ou Lambda du flux peuvent entraîner une augmentation du nombre d'appels Lambda et de hosts facturables (si ces hosts et fonctions ne sont pas déjà surveillés avec l'intégration AWS ou l'Agent Datadog, dans le cas d'EC2). +Les métriques EC2 ou Lambda du flux peuvent entraîner une augmentation du nombre d'appels Lambda et de hosts facturables (si ces hosts et fonctions ne sont pas déjà surveillés avec l'intégration AWS ou le Datadog Agent, dans le cas d'EC2). -## Socket de domaine Unix +**Remarque** : vous pouvez créer des filtres dans CloudWatch pour ne diffuser que des métriques spécifiques. Consultez le [guide de l'utilisateur d'Amazon CloudWatch][7] pour plus d'informations. -### Avant de commencer +## Configuration {#setup} -1. Lisez attentivement la section [Comparaison entre les flux de métriques et l'API](#flux-de-metriques-et-api) pour bien comprendre les différences entre les deux solutions avant d'activer les flux de métriques. +### Avant de commencer {#before-you-begin} -2. Si vous ne l'avez pas encore fait, connectez votre compte AWS à Datadog. Pour en savoir plus, consultez les [instructions de configuration de CloudFormation][3]. +1. Lisez attentivement la section [Flux de métriques par rapport à l'interrogation par API](#streaming-vs-polling) pour comprendre les différences avant d'activer les flux de métriques. -### Installation +2. Si ce n'est pas déjà fait, connectez votre compte AWS à Datadog. Pour plus d'informations, consultez les [instructions de configuration CloudFormation][3]. + +### Installation {#installation} {{< tabs >}} {{% tab "CloudFormation" %}} -Datadog recommande d'utiliser CloudFormation pour bénéficier d'un processus automatique et plus pratique si vous utilisez plusieurs régions AWS. +Datadog recommande d'utiliser CloudFormation, car c'est automatique et pratique si vous utilisez plusieurs régions AWS. -**Remarque** : à l'heure actuelle, la fonctionnalité de diffusion de métriques vers Datadog prend uniquement en charge le format de sortie OpenTelemetry v0.7. +**Remarque** : Le streaming de métriques prend uniquement en charge le format de sortie OpenTelemetry. La dernière version est la v1.0 ; la v0.7 est prise en charge mais peut entraîner des métriques manquantes. 1. Sur votre site Datadog, accédez à l'onglet **Configuration** de la [page d'intégration AWS][1]. -2. Cliquez sur le compte AWS pour configurer la diffusion de métriques. -3. Sous **Metric Collection**, cliquez sur **Automatically Using CloudFormation** en dessous de **CloudWatch Metric Streams** pour lancer une pile dans la console AWS. - {{< img src="integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose/metric-stream-setup.png" alt="La section CloudWatch Metric Streams de l'onglet Metric Collection de la page d'intégration AWS avec le bouton Automatically Using CloudFormation mis en évidence" responsive="true" style="width:60%;" >}} -4. Renseignez les paramètres requis : - - **ApiKey** : ajoutez votre [clé d'API Datadog][2]. - - **DdSite** : sélectionnez votre [site Datadog][3], à savoir {{< region-param key="site_dd" code="true" >}}. - - **Regions** : ajoutez la liste des régions, séparées par des virgules, que vous souhaitez configurer pour la diffusion de métriques. Pour obtenir la liste complète des régions prises en charge, consultez la page [Utilisation des flux de métriques][4] de la documentation AWS. -5. Vous pouvez définir des paramètres facultatifs : - - **FilterMethod** : liste d'inclusion ou d'exclusion d'espaces de nommage pour la diffusion de métriques. - - **First/Second/Third Namespace** : indiquez les espaces de nommage à inclure ou exclure. Remarque : les valeurs d'espace de nommage doivent correspondre précisément aux valeurs indiquées dans la colonne d'espace de nommage de la documentation AWS. Exemple : AWS/EC2. -6. Cochez la case d'acceptation indiquant "I acknowledge that AWS CloudFormation might create IAM resources with custom names." -7. Cliquez sur **Create Stack**. - -### Résultats - -Une fois la pile créée, patientez cinq minutes le temps que Datadog détecte la modification. Pour vous en assurer, accédez à l'onglet **Metric Collection** de la [page de l'intégration AWS][1] de Datadog et vérifiez que les régions activées apparaissent pour le compte sélectionné. +2. Cliquez sur le compte AWS pour configurer le streaming de métriques. +3. Sous **Metric Collection**, cliquez sur **Automatically Using CloudFormation** sous **CloudWatch Metric Streams** pour lancer une stack dans la console AWS. + {{< img src="integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose/metric-stream-setup.png" alt="La section CloudWatch Metric Streams de l'onglet Metric Collection de la page d'intégration AWS avec le bouton Automatically Using CloudFormation mis en surbrillance" responsive="true" style="width:60%;" >}} +4. Remplissez les paramètres requis : + - **ApiKey** : Ajoutez votre [clé d'API Datadog][2]. + - **DdSite** : Sélectionnez votre [site Datadog][3]. Votre site est : {{< region-param key="dd_site" code="true" >}} + - **Regions** : Une liste séparée par des virgules des régions pour lesquelles vous souhaitez configurer le streaming de métriques. Pour obtenir la liste complète des régions prises en charge, consultez la documentation AWS sur [l'utilisation des flux de métriques][4]. +5. Remplissez les paramètres optionnels : + - **FilterMethod** : Liste d'inclusion ou d'exclusion des espaces de noms à inclure pour le streaming de métriques. + - **First/Second/Third Namespace** : Spécifiez les espaces de noms que vous souhaitez inclure ou exclure. Remarque : Les valeurs des espaces de noms doivent correspondre précisément aux valeurs de la colonne des espaces de noms dans la documentation d'AWS. Par exemple, AWS/EC2. +6. Cochez la case d'accusé de réception indiquant : « Je reconnais qu'AWS CloudFormation peut créer des ressources IAM avec des noms personnalisés. » +7. Cliquez sur **Créer une pile**. + +### Résultats {#results} + +Une fois la pile créée avec succès, attendez cinq minutes que Datadog reconnaisse le changement. Pour valider l'achèvement, accédez à l'onglet **Collecte de métriques** sur la [page d'intégration AWS][1] de Datadog et vérifiez que les régions activées apparaissent pour le compte sélectionné. {{< img src="integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose/active-region.png" alt="La section CloudWatch Metric Streams de l'onglet Metric Collection de la page d'intégration AWS avec une région activée" responsive="true" style="width:60%;">}} @@ -91,66 +105,123 @@ Une fois la pile créée, patientez cinq minutes le temps que Datadog détecte l {{% /tab %}} {{% tab "Console AWS" %}} -Pour configurer des flux de métriques à l'aide de la console AWS, créez un [flux de métriques CloudWatch][2] pour chaque région AWS. +Pour configurer des flux de métriques à l'aide de la console AWS, créez un [flux de métriques CloudWatch][1] pour chaque région AWS. -**Remarque** : à l'heure actuelle, la fonctionnalité de diffusion de métriques vers Datadog prend uniquement en charge le format de sortie OpenTelemetry v0.7. +**Remarque** : Le streaming de métriques prend uniquement en charge le format de sortie OpenTelemetry. La dernière version est la v1.0 ; la v0.7 est prise en charge mais peut entraîner des métriques manquantes. -1. Choisissez l'option **Quick AWS Partner Setup** et sélectionnez dans le menu déroulant la valeur **Datadog** pour la destination de partenaire AWS. - {{< img src="integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose/metric-stream-partner-setup.png" alt="Configuration de partenaire rapide pour le flux de métriques CloudWatch" responsive="true" style="width:60%;">}} -2. Choisissez le site Datadog vers lequel vous souhaitez diffuser les métriques, puis saisissez votre [clé d'API Datadog][1]. -3. Définissez si vous souhaitez diffuser toutes les métriques CloudWatch, ou seulement celles de certains espaces de nommage. Vous pouvez également exclure certaines métriques. Si vous utilisez un compte de surveillance, vous avez la possibilité d'activer la [diffusion entre plusieurs comptes][5]. +1. Choisissez **Quick AWS Partner Setup** et sélectionnez **Datadog** comme destination du partenaire AWS dans le menu déroulant. + {{< img src="integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose/metric-stream-partner-setup.png" alt="Quick Partner Setup pour le flux de métriques CloudWatch" responsive="true" style="width:60%;">}} +2. Choisissez le site Datadog vers lequel vous souhaitez diffuser les métriques et saisissez votre [clé d'API Datadog][2]. +3. Choisissez si vous souhaitez diffuser toutes les métriques CloudWatch ou uniquement des espaces de noms spécifiques. Vous avez également la possibilité d'exclure des métriques spécifiques. Si vous êtes dans un compte de surveillance, vous pouvez également choisir d'activer la [diffusion inter-comptes][3]. {{< img src="integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose/metric-stream-namespace-filter.png" alt="Flux de métriques CloudWatch" responsive="true" style="width:60%;">}} -4. Sous **Add additional statistics**, incluez les métriques de centile AWS à envoyer à Datadog. Référez-vous au [modèle CloudFormation][3] pour consulter la liste des métriques de centile prises en charge par Datadog via le processus d'interrogation. +4. Sous **Ajouter des statistiques supplémentaires**, incluez les métriques de centile AWS à envoyer à Datadog. Consultez le [modèle CloudFormation][4] pour obtenir la liste des métriques de centile prises en charge par Datadog via l'interrogation. {{< img src="integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose/percentiles.png" alt="Centiles" responsive="true" style="width:60%;">}} 5. Attribuez un nom à votre flux de métriques. 6. Cliquez sur **Create metric stream**. -### Résultats +### Résultats {#results-1} -Une fois la ressource de flux de métriques créée, patientez cinq minutes le temps que Datadog détecte la modification. Pour vous en assurer, accédez à l'onglet **Metric Collection** de la [page de l'intégration AWS][4] de Datadog et vérifiez que les régions activées sont indiquées comme telles sous **CloudWatch Metric Streams** pour le compte AWS spécifié. +Une fois que vous avez constaté que la ressource Metric Stream a été créée avec succès, attendez cinq minutes pour que Datadog reconnaisse le changement. Pour valider l'achèvement, accédez à l'onglet **Metric Collection** sur la [page d'intégration AWS][5] de Datadog et vérifiez que les régions activées le sont sous **CloudWatch Metric Streams** pour le compte AWS spécifié. {{< img src="integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose/active-region.png" alt="La section CloudWatch Metric Streams de l'onglet Metric Collection de la page d'intégration AWS avec une région activée" responsive="true" style="width:60%;">}} -**Remarque** : si vous avez déjà activé l'interrogation des API CloudWatch, le changement de méthode peut entraîner la diffusion en double des métriques configurées lors d'une courte période (cinq minutes maximum). Cette duplication est causée par l'écart entre le moment où les crawlers Datadog exécutent et envoient vos métriques CloudWatch et le moment où Datadog détecte la diffusion de ces métriques et désactive les crawlers. -[1]: https://app.datadoghq.com/organization-settings/api-keys -[2]: https://console.aws.amazon.com/cloudwatch/home?region=us-east-1#metric-streams:streams/create -[3]: https://github.com/DataDog/cloudformation-template/blob/master/aws_streams/streams_single_region.yaml#L168-L249 -[4]: https://app.datadoghq.com/integrations/amazon-web-services -[5]: https://docs.datadoghq.com/fr/integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose/#cross-account-metric-streaming +**Remarque** : Si vous avez déjà activé l'interrogation des API CloudWatch, la transition vers la diffusion pourrait entraîner une brève période (jusqu'à cinq minutes) pendant laquelle les métriques spécifiques que vous diffusez sont comptabilisées deux fois dans Datadog. Cela est dû à la différence de timing entre le moment où les crawlers de Datadog s'exécutent et soumettent vos métriques CloudWatch, et le moment où Datadog reconnaît que vous avez commencé à diffuser ces métriques et désactive les crawlers. + +[1]: https://console.aws.amazon.com/cloudwatch/home?region=us-east-1#metric-streams:streams/create +[2]: https://app.datadoghq.com/organization-settings/api-keys +[3]: https://docs.datadoghq.com/fr/integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose/#cross-account-metric-streaming +[4]: https://github.com/DataDog/cloudformation-template/blob/master/aws_streams/streams_single_region.yaml#L168-L249 +[5]: https://app.datadoghq.com/integrations/amazon-web-services {{% /tab %}} {{< /tabs >}} -### Diffusion de métriques entre plusieurs comptes -La diffusion de métriques entre plusieurs comptes vous permet d'inclure dans un flux de métriques unique des métriques provenant de plusieurs comptes AWS d'une région. Vous pouvez ainsi limiter le nombre de flux nécessaires à la collecte de métriques pour une destination courante. Pour bénéficier de cette fonctionnalité, [associez vos comptes source][5] à votre compte de surveillance, puis activez la diffusion entre plusieurs comptes vers Datadog dans votre compte de surveillance AWS. +### Diffusion de métriques inter-comptes{#cross-account-metric-streaming} +Utilisez la diffusion de métriques inter-comptes pour inclure les métriques dans un seul flux de métriques couvrant plusieurs comptes AWS au sein d'une région AWS. Cela permet de réduire le nombre de flux nécessaires pour collecter des métriques vers une destination commune. Pour ce faire, [connectez vos comptes sources][4] à votre compte de surveillance et activez Cross-account streaming vers Datadog dans votre compte de surveillance AWS. Pour assurer le bon fonctionnement de la diffusion de métriques entre plusieurs comptes, votre compte de surveillance doit disposer des autorisations suivantes : * oam:ListSinks * oam:ListAttachedLinks -**Remarque** : pour recueillir des tags custom et d'autres métadonnées relatives à vos métriques diffusées, intégrez vos comptes source à Datadog. +**Remarque :** Pour collecter des tags personnalisés et d'autres métadonnées pour vos métriques diffusées, intégrez vos comptes sources à Datadog. + +### Désactiver la diffusion de métriques{#disable-metric-streaming} + +Pour désactiver complètement la diffusion de métriques pour un compte AWS et une région donnés, vous devez supprimer l'AWS Metric Stream et ses ressources associées. Pour éviter toute perte de métriques dans Datadog, il est important de suivre attentivement ces étapes de suppression : + +Si vous avez configuré la diffusion avec [CloudFormation](?tab=cloudformation#installation) : +1. Supprimez la pile (stack) qui a été créée lors de la configuration. + +Si vous avez configuré la diffusion via la [AWS Console](?tab=awsconsole#installation) : +1. Supprimez le CloudWatch Metric Stream lié à votre flux de diffusion. +2. Supprimez toutes les ressources qui ont été créées lors de la configuration du flux, y compris les rôles IAM S3 et Firehose associés au flux. + +Une fois les ressources supprimées, attendez cinq minutes pour que Datadog reconnaisse le changement. Pour valider l'achèvement, accédez à l'onglet **Metric Collection** sur la [page d'intégration AWS][5] de Datadog et vérifiez que les régions désactivées ne sont pas affichées sous **CloudWatch Metric Streams** pour le compte AWS spécifié. + +### Surveiller la santé des flux {#monitor-stream-health} + +Datadog soumet la métrique `datadog.aws_metric_streams.data_received` lorsqu'il reçoit des données d'un flux de métriques CloudWatch. Utilisez cette métrique pour confirmer qu'AWS envoie des métriques et que Datadog les reçoit. + +`datadog.aws_metric_streams.data_received` +: **Type** : Jauge
+Rapporte une valeur de `1` lorsque Datadog reçoit des données d'un flux de métriques CloudWatch, et ne rapporte rien lorsque Datadog ne reçoit aucune donnée. Marqué avec `stream_arn`, `stream_name`, `aws_account` et `region`. La fréquence à laquelle la métrique rapporte dépend de votre volume de données et de la configuration de mise en mémoire tampon de votre flux de diffusion Firehose. + +Pour un flux inter-comptes, le flux de métriques et le flux de diffusion Firehose se trouvent dans le compte de surveillance. Le tag `aws_account` identifie le compte de surveillance, et non les comptes sources d'où proviennent les métriques. + +Pour vérifier si un flux transmet des données, interrogez cette métrique dans le [Metrics Explorer][8] et regroupez par `stream_name` ou `stream_arn`. + +Comme la métrique ne rapporte rien lorsqu'un flux cesse de transmettre des données, surveillez-la pour détecter la transition entre la transmission et l'absence de données. Créez un [monitor de métrique][9] sur `datadog.aws_metric_streams.data_received`, regroupez-le par `stream_arn` et activez les notifications de données manquantes. Pour les étapes de configuration, consultez [Recevoir une alerte lorsqu'un tag spécifique ne transmet plus de données][10]. + +## Dépannage {#troubleshooting} + +Si vous rencontrez des problèmes lors de la configuration de Metric Streams ou des ressources associées, consultez [AWS Troubleshooting][6]. Si les métriques CloudWatch cessent d'apparaître après que Metric Streams a fonctionné correctement, le problème peut provenir d'erreurs de destination Firehose. + +### Erreurs de destination Firehose persistantes {#persistent-firehose-destination-errors} + +Si les métriques CloudWatch cessent d'apparaître dans Datadog, le CloudWatch Metric Stream et le flux de diffusion Firehose d'Amazon peuvent toujours afficher un état `running`. Cela peut se produire même lorsque Firehose ne transmet plus d'enregistrements. -### Désactiver la diffusion de métriques +Cela peut se produire lorsque Firehose ne parvient pas à transmettre les enregistrements à l'endpoint HTTP de Datadog dans sa [retry period][11], ni à écrire les enregistrements dans sa sauvegarde S3. Lorsque les deux chemins de livraison échouent, le flux de diffusion peut ne pas reprendre automatiquement la livraison HTTP une fois que l'endpoint est à nouveau disponible. -Pour désactiver complètement la diffusion de métriques pour un compte et une région AWS donnés, vous devez supprimer le flux de métriques AWS et les ressources associées. Afin d'empêcher toute perte de métriques dans Datadog, assurez-vous de bien suivre ces étapes de suppression : +Pour diagnostiquer et rétablir la livraison : -Si vous avez configuré la diffusion avec [CloudFormation](?tab=cloudformation#installation) : -1. Supprimez la pile créée durant la configuration. +1. Localisez le flux de diffusion Firehose associé au CloudWatch Metric Stream concerné. Exécutez la commande AWS CLI suivante pour trouver le `FirehoseArn` dans la réponse : -Si vous avez configuré la diffusion avec la [Console AWS](?tab=awsconsole#installation) : -1. Supprimez le flux de métriques CloudWatch lié à votre flux de diffusion. -2. Supprimez toutes les ressources créées lors de la configuration du flux, y compris les rôles IAM pour S3 et Firehose qui sont associés au flux. + ```shell + aws cloudwatch get-metric-stream \ + --name \ + --region + ``` -Une fois les ressources supprimées, patientez cinq minutes le temps que Datadog détecte la modification. Pour confirmer la suppression, accédez à l'onglet **Metric Collection** de la [page d'intégration AWS][4] de Datadog et vérifiez que les régions désactivées ne sont pas affichées sous **CloudWatch Metric Streams** pour le compte AWS spécifié. +2. Examinez les [logs d'erreurs de livraison Firehose][12] dans CloudWatch Logs. Si la journalisation des erreurs de livraison n'est pas activée, activez-la afin de pouvoir capturer les futures erreurs de livraison. Les erreurs pertinentes incluent `HttpEndpoint.DestinationException` (telles que les réponses HTTP 408) et `S3.AccessDenied`. +3. Inspectez les [métriques CloudWatch Firehose][13] dans la console CloudWatch (Datadog peut ne pas afficher ces métriques pendant l'interruption de la livraison). Vérifiez `DeliveryToHttpEndpoint.Success`, `DeliveryToHttpEndpoint.DataFreshness`, `DeliveryToHttpEndpoint.Records` et `IncomingRecords`. +4. Si Firehose reçoit des enregistrements mais ne les livre pas, vérifiez la configuration de sauvegarde S3 et le rôle IAM : + - Confirmez que Firehose peut assumer le rôle configuré et écrire dans le compartiment de sauvegarde. + - Vérifiez que la stratégie de compartiment, les limites d'autorisations, les stratégies de contrôle du service (SCP) et la stratégie de clé KMS ne bloquent pas l'accès requis. +5. Vérifiez si les enregistrements parviennent à S3 en consultant le compartiment de sauvegarde sous le préfixe configuré dans les paramètres de sauvegarde S3 de votre flux de diffusion Firehose. Si aucun objet n'est écrit, cela confirme un problème d'autorisations ou de configuration avec le chemin de sauvegarde S3. Si les logs d'erreurs de livraison de l'étape 2 indiquent une erreur d'autorisations S3, corrigez-la avant de continuer. +6. Mettez à jour la configuration de destination HTTP Firehose à l'aide de l'API [UpdateDestination API][14] de Firehose ; par exemple, en modifiant sa durée de nouvelle tentative. Une mise à jour de configuration comme celle-ci peut redémarrer une destination bloquée. -## Dépannage +Si la livraison ne se rétablit pas, contactez le [support Datadog][15] et fournissez : + - L'ID de compte AWS et la région + - Les ARN du flux de métriques CloudWatch et du flux de livraison Firehose + - Heure approximative de l'arrêt de la livraison + - Logs d'erreurs Firehose pertinents -Pour résoudre les problèmes rencontrés lors de la configuration des flux de métriques ou des ressources associées, consultez la [section Dépannage de la documentation AWS][5]. +**Remarque** : Le redémarrage de la livraison affecte uniquement les nouveaux enregistrements et ne restaure pas les enregistrements ayant échoué pendant l'interruption. Les enregistrements écrits dans la sauvegarde S3 ne sont pas automatiquement ingérés dans Datadog. -## Pour aller plus loin +## Pour aller plus loin {#further-reading} {{< partial name="whats-next/whats-next.html" >}} -[1]: https://aws.amazon.com/cloudwatch/pricing/ -[2]: https://docs.datadoghq.com/fr/integrations/amazon_web_services/?tab=roledelegation#setup -[3]: https://app.datadoghq.com/integrations/amazon-web-services -[4]: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-metric-streams-troubleshoot.html -[5]: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account-Setup.html \ No newline at end of file +[1]: /fr/integrations/guide/cloud-metric-delay/ +[2]: https://aws.amazon.com/cloudwatch/pricing/ +[3]: /fr/integrations/amazon_web_services/?tab=roledelegation#setup +[4]: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account-Setup.html +[5]: https://app.datadoghq.com/integrations/amazon-web-services +[6]: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-metric-streams-troubleshoot.html +[7]: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Metric-Streams.html +[8]: https://app.datadoghq.com/metric/explorer +[9]: /fr/monitors/types/metric/ +[10]: /fr/monitors/guide/set-up-an-alert-for-when-a-specific-tag-stops-reporting/ +[11]: https://docs.aws.amazon.com/firehose/latest/dev/retry.html +[12]: https://docs.aws.amazon.com/firehose/latest/dev/monitoring-with-cloudwatch-logs.html +[13]: https://docs.aws.amazon.com/firehose/latest/dev/monitoring-with-cloudwatch-metrics.html#fh-http-metrics +[14]: https://docs.aws.amazon.com/firehose/latest/APIReference/API_UpdateDestination.html +[15]: /fr/help/ \ No newline at end of file diff --git a/hugo/content/fr/logs/explorer/search.md b/hugo/content/fr/logs/explorer/search.md index 08013977586..a76f876023a 100644 --- a/hugo/content/fr/logs/explorer/search.md +++ b/hugo/content/fr/logs/explorer/search.md @@ -15,83 +15,85 @@ further_reading: text: Exporter des vues depuis le Log Explorer title: Rechercher des logs --- +## Présentation {#overview} -## Présentation +Le [Log Explorer][1] vous permet de rechercher et d'afficher des logs individuels sous forme de liste. Cependant, les informations les plus précieuses proviennent souvent de l'agrégation des logs à grande échelle. À l'aide de la fonctionnalité de recherche, vous pouvez filtrer les logs et les visualiser sous forme de graphiques de séries temporelles, de listes top, de treemaps, de graphiques circulaires ou de tableaux pour mieux comprendre les tendances, les modèles et les valeurs aberrantes dans vos données de log. -Bien que les listes de logs puissent vous fournir des informations précieuses, il est parfois préférable d'analyser les données en agrégeant les logs. Pour consulter ces agrégations, recherchez des logs dans le [Log Explorer][5] et affichez les données sous forme de séries temporelles, de top lists, de cartes proportionnelles, de graphiques circulaires ou de tableaux. +## Requêtes en langage naturel {#natural-language-queries} -La fonctionnalité de recherche du Log Explorer vous permet de définir un intervalle ainsi qu'une requête de recherche. Vous pouvez rechercher des paires `key:value` tout comme du texte intégral. +{{% site-region region="gov,gov2" %}} +
+Les requêtes en langage naturel ne sont pas disponibles sur le site Datadog ({{< region-param key="dd_site_name" >}}). +
+{{% /site-region %}} +Utilisez les requêtes en langage naturel (NLQ) pour décrire ce que vous recherchez en anglais simple. Datadog traduit automatiquement votre demande en une requête de log structurée, ce qui facilite l'exploration des logs sans avoir à écrire une syntaxe complexe. Pour accéder à cette fonctionnalité, cliquez sur {{< ui >}}Ask{{< /ui >}} dans le champ de recherche. -## Requête de recherche +{{< img src="/logs/explorer/search/log_explorer_nlq.mp4" alt="Requête en langage naturel dans le Log Explorer montrant comment rechercher des logs à l'aide d'expressions en anglais simple" video=true >}} -Par exemple, pour filtrer les logs qui possèdent un certain statut d'erreur et ont été générés par un service de boutique en ligne spécifique au cours des cinq dernières minutes, vous pouvez créer une requête personnalisée comme `service:payment status:error rejected`, puis définir l'intervalle sur `Past 15 minutes` : +Le système traduit les entrées en langage naturel en requêtes Datadog et comprend le contexte tel que les services, les attributs, les tags et les plages temporelles. Il détecte également automatiquement les champs pertinents et permet aux utilisateurs de créer des visualisations à l'aide de descriptions simples, par exemple : « Top 20 des services par erreurs » ou « Afficher les erreurs du service X au cours des 24 dernières heures ». -{{< img src="logs/explorer/search_filter.png" alt="Créer une requête de recherche dans le Log Explorer qui filtre les logs d'erreur associés aux paiements rejetés pour un service de boutique en ligne" style="width:100%;" >}} +Pour désactiver NLQ, vous devez disposer des [`org_management` autorisations][2]. Accédez à [{{< ui >}}Organization Settings{{< /ui >}} > {{< ui >}}Preferences{{< /ui >}}][3] et désactivez la fonctionnalité Requêtes en langage naturel. -Les [logs indexés][1] prennent en charge les recherches de texte intégral ainsi que les recherches de paires `key:value`. +## Requête de recherche {#search-query} -**Remarque** : pour effectuer une recherche `key:value`, vous n'avez **pas besoin** de [déclarer une facette][5]. +Une recherche dans le Log Explorer se compose d'une plage temporelle et d'une requête de recherche, combinant `key:value` et [recherche plein texte][4]. Vous pouvez choisir une fenêtre temporelle pour votre recherche à l'aide du sélecteur de plage temporelle situé en haut à droite du Log Explorer. Pour plus de détails sur la définition d'une plage temporelle personnalisée, consultez la [documentation sur les plages temporelles personnalisées][5]. -## Saisie automatique +Pour filtrer les logs produits par un service de boutique en ligne, avec un statut d'erreur, au cours des quinze dernières minutes, créez une requête personnalisée comme `service:payment status:error rejected` et définissez la plage temporelle sur `Past 15 minutes` : -Utilisez la fonctionnalité de saisie automatique de la barre de recherche pour compléter votre requête en utilisant : -- Des clés et des valeurs existantes dans vos logs -- Vos recherches récentes (les recherches récentes des autres utilisateurs ne sont pas affichées) -- Vues enregistrées +{{< img src="logs/explorer/search_filter.png" alt="Créez une requête de recherche dans le Log Explorer qui filtre les logs d'erreur des paiements rejetés pour un service de boutique en ligne" style="width:100%;" >}} -{{< img src="logs/explorer/search/log_search_bar_autocomplete.png" alt="La barre de recherche des logs affichant service: comme requête et emailer, balancer-checker, ad-server et vpc comme options de saisie automatique" style="width:80%;">}} +[Indexed Logs][6] prennent en charge à la fois la [recherche plein texte][4] et les requêtes de recherche `key:value`. -### Complétion automatique des facettes et valeurs +**Remarque** : les requêtes `key:value` **ne** nécessitent pas que vous [déclariez une facette][7] au préalable. -La barre de recherche suggère automatiquement des facettes en fonction de votre saisie. Ces facettes s'affichent dans le même ordre que celui du [volet des facettes][5]. Si une facette a un nom d'affichage défini, celui-ci est affiché sur le côté droit du menu déroulant. Les facettes qui ne sont pas configurées pour être affichées dans le volet des facettes ne sont pas suggérées automatiquement dans la barre de recherche. +Pour une référence complète sur la syntaxe des requêtes, consultez la [documentation sur la syntaxe de recherche][8]. -{{< img src="logs/explorer/search/log_facet_autocomplete.png" alt="Barre de recherche de logs affichant `network` comme requête et les facettes @network.bytes_written, @network.client.ip et @network.interface comme options d'autocomplétion." style="width:80%;">}} +## Fonctionnalités de la barre de recherche {#search-bar-features} -Après avoir sélectionné une facette et saisi le caractère `:`, la barre de recherche propose automatiquement des valeurs. Ces valeurs sont affichées par ordre décroissant en fonction du nombre de logs contenant cette paire `facette:valeur` au cours des 15 dernières minutes. Le nombre estimé de logs contenant cette valeur est affiché dans la partie droite du menu déroulant. Par exemple, le service `balance-checker` apparaît en premier dans la liste des valeurs suggérées automatiquement pour la facette `service`, car son nombre de logs `2.66M` est le plus élevé : +La barre de recherche du Log Explorer inclut plusieurs fonctionnalités pour vous aider à rédiger des requêtes plus efficacement et avec plus de précision. -{{< img src="logs/explorer/search/log_value_autocomplete.png" alt="Barre de recherche de logs affichant `service:` comme requête et les valeurs balance-checker, ad-server, fraud-detector et trade-executor comme options de complétion automatique." style="width:80%;">}} +### Coloration syntaxique et validation des erreurs {#syntax-highlighting-and-error-validation} -### Complétion automatique des recherches récentes +La coloration syntaxique différencie clairement les types d'entrée : clés, valeurs, texte libre et caractères de contrôle. Par exemple, `service` et `status` sont des clés, `auth-dotnet` et `error` sont des valeurs, `500` et `check-token` sont du texte libre, et les parenthèses sont des caractères de contrôle. Les attributs de statut sont codés par couleur selon le statut (rouge pour `error`, bleu pour `info`). -Le Log Explorer conserve vos 100 recherches les plus récentes. Les recherches récentes effectuées par d'autres utilisateurs ne sont ni conservées ni affichées. La barre de recherche propose automatiquement les quatre recherches les plus récentes en fonction de votre saisie, la recherche la plus récente étant affichée en premier. Elle indique également à quand remonte chaque recherche récente. Par exemple, si vous saisissez `service:web-store status:error` dans la barre de recherche, les quatre recherches les plus récentes contenant ces termes apparaissent en fonction de leur ancienneté, chacune spécifiant une erreur différente : +{{< img src="logs/explorer/search/log_syntax_highlighting.png" alt="La barre de recherche du Log Explorer affichant `service:auth-dotnet status:error 500 (check-token OR create-user)` comme requête avec une coloration syntaxique différenciable" style="width:100%;">}} -{{< img src="logs/explorer/search/log_recent_searches.png" alt="Barre de recherche de logs affichant `service:web-store status:error` comme requête ainsi que les recherches récentes pour les différentes erreurs du service de boutique en ligne comme options de complétion automatique" style="width:80%;">}} +La validation des erreurs identifie les erreurs de syntaxe et suggère des corrections, telles que des valeurs manquantes dans les paires `key:value`, des requêtes de plage incomplètes ou des parenthèses non fermées. -### Complétion automatique des vues enregistrées +{{< img src="logs/explorer/search/log_error_states.png" alt="La barre de recherche du Log Explorer affichant `service:(web-store OR auth-dotnet` comme requête avec le message `Caractère de parenthèse fermante manquant`" style="width:50%;">}} -Vous pouvez créer des vues enregistrées dans le Log Explorer pour enregistrer des requêtes et des données de contexte supplémentaires et ainsi les retrouver facilement plus tard. La barre de recherche suggère automatiquement les vues enregistrées qui correspondent à votre saisie. Les vues enregistrées apparaissent dans le même ordre que celui du volet des vues enregistrées, vos vues préférées étant affichées en premier. Le nom de la vue enregistrée, la requête enregistrée et la photo de profil de l'utilisateur qui l'a mise à jour pour la dernière fois sont affichés dans le menu déroulant. Si la requête d'une vue enregistrée est trop longue pour être affichée dans le menu déroulant, la requête complète apparaît lorsque vous passez votre curseur dessus. L'adresse e-mail du dernier utilisateur ayant mis à jour la vue enregistrée s'affiche également lorsque vous passez votre curseur sur sa photo de profil. +### Saisie semi-automatique {#autocomplete} -{{< img src="logs/explorer/search/log_autocomplete_saved_views.png" alt="Barre de recherche de logs affichant `service:web-store status:error` comme requête ainsi que les vues enregistrées pour les différentes erreurs du service de boutique en ligne comme options de complétion automatique" style="width:80%;">}} +La fonctionnalité de saisie semi-automatique de la barre de recherche vous aide à compléter vos requêtes en utilisant les clés et valeurs existantes dans vos logs, vos recherches récentes et vos vues enregistrées. -## Syntaxe de recherche +{{< img src="logs/explorer/search/log_search_bar_autocomplete.png" alt="La barre de recherche du Log Explorer affichant service: comme requête et emailer, balancer-checker, ad-server et vpc comme options de saisie semi-automatique" style="width:80%;">}} -La syntaxe est mise en forme de façon à différencier clairement les types de saisies, telles que les clés (par exemple, l'attribut `@merchant_name`), les valeurs (par exemple, le nom d'un marchand spécifique), le texte libre (par exemple, les mots-clés dans les messages de log tels que `responded 500`), ainsi que les caractères de contrôle (par exemple, les parenthèses et les deux-points). Les attributs de statut sont également mis en évidence dans des couleurs spécifiques, comme le rouge pour `error` et le bleu pour `info`. +La saisie semi-automatique suggère des facettes et des valeurs en fonction de votre saisie, affichées dans l'ordre dans lequel elles apparaissent dans le [panneau des facettes][7]. Après avoir sélectionné une facette et saisi `:`, les valeurs apparaissent par ordre décroissant selon le nombre de logs des 15 dernières minutes. -{{< img src="logs/explorer/search/log_syntax_highlighting.png" alt="Barre de recherche de logs affichant `service:auth-dotnet status:error 500 (check-token OR create-user)` comme requête, les différents éléments de la syntaxe étant mis en forme de façon à les distinguer" style="width:100%;">}} +{{< img src="logs/explorer/search/log_facet_autocomplete.png" alt="La barre de recherche du Log Explorer affichant `network` comme requête et les facettes @network.bytes_written, @network.client.ip et @network.interface comme options de saisie semi-automatique" style="width:80%;">}} -Les statuts d'erreur vous indiquent clairement la partie de la requête qui présente une erreur de syntaxe et la façon d'y remédier. Par exemple : -- Si vous saisissez la requête `service:` sans valeur, le message `Missing value in key:value pair` s'affiche lorsque vous survolez la requête avec votre souris. -- Si vous saisissez des parenthèses pour indiquer une plage dans votre requête mais que vous ne spécifiez pas les valeurs haute et basse, le message `Expected term but end of input found` s'affiche. -- Si vous saisissez plusieurs valeurs pour un champ de log mais que vous oubliez la parenthèse fermante, comme `service:(web-store OR auth-dotnet`, le message `Missing closing parenthesis character` s'affiche. +Vos 100 recherches les plus récentes sont conservées et suggérées au fur et à mesure que vous tapez. Les vues enregistrées qui correspondent à votre requête sont également suggérées, affichées dans le même ordre que dans le panneau Saved Views. -{{< img src="logs/explorer/search/log_error_states.png" alt="Barre de recherche de logs affichant `service:(web-store OR auth-dotnet` comme requête avec le message `Missing closing parenthesis character`" style="width:50%;">}} +{{< img src="logs/explorer/search/log_recent_searches.png" alt="La barre de recherche des logs affichant `service:web-store status:error` comme requête et des recherches récentes pour différentes erreurs du service web-store comme options de saisie semi-automatique" style="width:80%;">}} -Pour commencer à rechercher des logs et à personnaliser l'intervalle dans le Log Explorer, consultez les sections [Syntaxe de recherche][3] et [Intervalles personnalisés][4]. -## Désactiver la mise en forme et la complétion automatique dans la barre de recherche +## Désactiver le style et la saisie semi-automatique pour la barre de recherche {#disable-styling-and-autocomplete-for-search-bar} Cliquez sur le bouton à droite de la barre de recherche pour effectuer une recherche en mode brut et ainsi désactiver la coloration syntaxique, la mise en forme des boutons de recherche et la complétion automatique : -{{< img src="logs/explorer/search/log_raw_search_mode.png" alt="Barre de recherche de logs affichant `service:auth-dotnet status:error 500 (check-token OR create-user)` comme requête en mode de recherche brute" style="width:100%;">}} +{{< img src="logs/explorer/search/log_raw_search_mode.png" alt="La barre de recherche des logs affichant `service:auth-dotnet status:error 500 (check-token OR create-user)` comme requête en mode de recherche brute" style="width:100%;">}} -Vous pouvez interagir avec la barre de recherche à l'aide de la souris, mais aussi avec des raccourcis clavier. Par exemple, utilisez `CMD-A` pour sélectionner le texte, `CMD-C` pour copier le texte, `CMD-X` pour couper le texte, et `CMD-V` pour coller le texte. +Vous pouvez interagir avec la barre de recherche à l'aide de votre souris, ainsi qu'en utilisant des commandes clavier. Par exemple, utilisez `CMD-A` pour sélectionner du texte, `CMD-C` pour copier du texte, `CMD-X` pour couper du texte et `CMD-V` pour coller du texte. -## Pour aller plus loin +## Pour aller plus loin {#further-reading} {{< partial name="whats-next/whats-next.html" >}} -[1]: /fr/logs/indexes -[2]: /fr/logs/explorer/facets/ -[3]: /fr/logs/search-syntax -[4]: /fr/dashboards/guide/custom_time_frames -[5]: /fr/logs/explorer/ \ No newline at end of file +[1]: /fr/logs/explorer/ +[2]: /fr/account_management/rbac/permissions/#access-management +[3]: https://app.datadoghq.com/organization-settings/preferences +[4]: /fr/logs/explorer/search_syntax/#full-text-search +[5]: /fr/dashboards/guide/custom_time_frames +[6]: /fr/logs/indexes +[7]: /fr/logs/explorer/facets/ +[8]: /fr/logs/search-syntax \ No newline at end of file diff --git a/hugo/content/fr/logs/guide/increase-number-of-log-files-tailed.md b/hugo/content/fr/logs/guide/increase-number-of-log-files-tailed.md index 3fb822f6de5..f717b10c7f9 100644 --- a/hugo/content/fr/logs/guide/increase-number-of-log-files-tailed.md +++ b/hugo/content/fr/logs/guide/increase-number-of-log-files-tailed.md @@ -11,13 +11,9 @@ further_reading: - link: /logs/faq/how-to-investigate-a-log-parsing-issue/ tag: FAQ text: Comment étudier un problème de parsing de log ? - title: Augmenter le nombre de fichiers de log suivis par l'Agent --- - -Par défaut, l'Agent peut suivre jusqu'à 200 fichiers de log sur Windows et MacOS, et jusqu'à 500 fichiers sur les autres systèmes d'exploitation. Cette limite est appliquée pour éviter les problèmes de performances lorsque des wildcards sont utilisés sur des répertoires très volumineux. - -Pour augmenter cette limite, modifiez la valeur du paramètre `open_files_limit` dans la section `logs_config` du fichier de configuration de l'Agent (`/etc/datadog-agent/datadog.yaml`) : +Le paramètre `logs_config.open_files_limit` dans le fichier de configuration de l'Agent (`/etc/datadog-agent/datadog.yaml`) détermine le nombre maximal de fichiers logs dont l'Agent peut effectuer le suivi simultanément. Cette limite est définie pour éviter des problèmes de performance lorsque des caractères génériques sont utilisés sur d'immenses répertoires. Vous pouvez augmenter la limite en ajustant ce paramètre. ```yaml logs_config: @@ -26,4 +22,8 @@ logs_config: Pour les environnements conteneurisés, vous pouvez définir la variable d'environnement `DD_LOGS_CONFIG_OPEN_FILES_LIMIT`. -**Remarque** : l'augmentation du nombre de fichiers de log suivis est susceptible d'augmenter la charge système de l'Agent. \ No newline at end of file +La valeur par défaut varie en fonction de la version de l'Agent et du système d'exploitation. Pour vérifier la valeur par défaut de votre version de l'Agent, consultez les [exemples de fichiers de configuration de l'Agent][1] dans le dépôt Datadog Agent. Ouvrez le fichier correspondant à votre système d'exploitation. Assurez-vous de sélectionner le tag correspondant à votre version de l'Agent pour voir les valeurs par défaut correctes. + +**Remarque** : L'augmentation de la limite de fichiers logs suivis peut accroître la consommation de ressources de l'Agent. + +[1]: https://github.com/DataDog/datadog-agent/tree/main/pkg/config/example \ No newline at end of file diff --git a/hugo/content/fr/monitors/status/events.md b/hugo/content/fr/monitors/status/events.md new file mode 100644 index 00000000000..cdef3c8d775 --- /dev/null +++ b/hugo/content/fr/monitors/status/events.md @@ -0,0 +1,72 @@ +--- +description: Affichez et gérez les événements de monitor sur la page d'état, y compris + les actions rapides, les détails des événements et les outils de dépannage. +further_reading: +- link: events/ + tag: Documentation + text: Event Management +title: Événements d'état +--- +
Les événements d'état font partie de la page d'état du monitor provisoire. Si vous utilisez l'ancienne page d'état, consultez la documentation Status Page (Legacy).
+ +## Présentation {#overview} + +{{< img src="/monitors/status/status_page_event_details.png" alt="Page d'état du monitor affichant les détails de l'événement" style="width:100%;" >}} + +Tous les événements générés par votre monitor apparaissent sur la page d'état du monitor, indiquant le nom des groupes, le type d'événement et l'horodatage. La chronologie des événements inclut également les événements de downtime et de piste d'audit. + +Pour chaque événement, vous pouvez accéder aux actions rapides et afficher les ressources associées, comme les tableaux de bord et les logs. + +## Section des détails de l'événement {#event-details-section} + +Pour explorer chaque événement individuel afin d'obtenir plus d'informations, y compris les tags et les actions associées : + +1. Depuis la page d'état du monitor, faites défiler jusqu'à {{< ui >}}Event timeline{{< /ui >}}. +2. Cliquez sur un événement dans la chronologie pour afficher les détails de l'événement. + +Utilisez les détails de l'événement pour comprendre les alertes de monitor et identifier les causes profondes. Ces informations prennent en charge les flux de travail des intervenants et vous aident à rester informé des situations en cours. + +### Prenez des mesures pour remédier {#take-action-to-remediate} + +Avec Quick Actions, vous pouvez agir sans quitter la page d'état. Les intervenants gagnent du temps car le contexte est automatiquement ajouté. + +| Action | Description | +| :---- | :---- | +| {{< ui >}}Mute{{< /ui >}} | Créez un [downtime][1] pour désactiver les alertes de monitor. | +| {{< ui >}}Resolve{{< /ui >}} | Définissez temporairement l'état du monitor sur `OK` jusqu'à sa prochaine évaluation. | +| {{< ui >}}Declare Incident{{< /ui >}} | Faites remonter les alertes de monitor avec [Incident Management][2]. | +| {{< ui >}}Create Work Item{{< /ui >}} | Créez un [élément de travail][3] pour suivre cette enquête sur l'alerte sans quitter Datadog. | +| {{< ui >}}Run Workflow{{< /ui >}} | Exécutez l'automatisation [Workflow][4] avec des extraits prédéfinis pour exécuter des actions d'atténuation. | + +### Resolve {#resolve} + +Vous pouvez résoudre une alerte de monitor depuis la page d'état [Header][5] ou les sections de détails de l'événement. La résolution depuis la section des détails de l'événement n'affecte que le groupe lié à l'événement sélectionné, tandis que la résolution depuis [Header] résout tous les groupes de l'alerte et définit l'état du monitor sur `OK` (tous les groupes). + +Si un monitor envoie une alerte parce que ses données actuelles correspondent à l'état `ALERT`, l'utilisation de `resolve` entraînera le passage temporaire de l'état de `ALERT` à `OK`, puis le retour à `ALERT`. Par conséquent, `resolve` n'est pas destiné à accuser réception de l'alerte ou à demander à Datadog de l'ignorer. + +La résolution manuelle d'un monitor est utile lorsque les données sont signalées par intermittence. Par exemple, après le déclenchement d'une alerte, le monitor peut cesser de recevoir des données, ce qui l'empêche d'évaluer les conditions d'alerte et de revenir à l'état `OK`. Dans de tels cas, la fonction `resolve` ou {{< ui >}}Automatically resolve monitor after X hours{{< /ui >}} ramène le monitor à un état `OK`. + +**Cas d'utilisation typique** : Un monitor basé sur des métriques d'erreur qui ne sont pas générées lorsqu'il n'y a pas d'erreurs (`aws.elb.httpcode_elb_5xx`, ou tout compteur DogStatsD dans votre code signalant une erreur _uniquement lorsqu'il y a une erreur_). + +## Section de dépannage des événements {#event-troubleshooting-section} + +{{< img src="/monitors/status/events/event_troubleshooting.png" alt="Dépannage des événements avec un exemple de carte des dépendances" style="width:100%;" >}} + +Pour chaque événement, accédez aux informations de dépannage pour aider les intervenants à comprendre rapidement le contexte de l'alerte. + +| Composant de dépannage | Description | +| --- | ----------- | +| {{< ui >}}Dependency Map{{< /ui >}} | Lorsqu'un tag de service est disponible, soit en tant que tag de monitor, soit dans le groupe, vous pouvez accéder à une carte des dépendances affichant l'état de vos dépendances. | +| {{< ui >}}Change Tracking{{< /ui >}} | Lorsqu'un tag de service est disponible, soit en tant que tag de monitor, soit dans le groupe, vous pouvez accéder à une liste des changements pertinents pour votre service et ses dépendances. Pour plus de détails sur les types spécifiques de changements pris en charge et les exigences de configuration, consultez la documentation [Change Tracking][6]. | + + +## Lectures complémentaires {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /fr/monitors/downtimes/?tab=bymonitorname +[2]: /fr/incident_response/incident_management/ +[3]: /fr/incident_response/work_management/ +[4]: /fr/actions/workflows/trigger/#trigger-a-workflow-from-a-monitor +[5]: /fr/monitors/status/status_page/#header +[6]: /fr/change_tracking \ No newline at end of file diff --git a/hugo/content/fr/observability_pipelines/destinations/google_pubsub.md b/hugo/content/fr/observability_pipelines/destinations/google_pubsub.md new file mode 100644 index 00000000000..cc7e2173930 --- /dev/null +++ b/hugo/content/fr/observability_pipelines/destinations/google_pubsub.md @@ -0,0 +1,186 @@ +--- +description: Apprenez à publier des logs dans le système de messagerie Google Pub/Sub + à l'aide de l'Observability Pipelines Worker. +disable_toc: false +products: +- icon: logs + name: Logs + url: /observability_pipelines/configuration/?tab=logs#pipeline-types +title: Destination Google Pub/Sub +--- +{{< product-availability >}} + +## Présentation {#overview} + +Utilisez la destination Google Pub/Sub d'Observability Pipelines pour publier des logs dans le système de messagerie Google Pub/Sub, afin que les logs puissent être envoyés vers des services en aval, des lacs de données ou des applications personnalisées. + +### Quand utiliser cette destination : {#when-to-use-this-destination} + +Scénarios courants où vous pourriez utiliser cette destination : +- Pour les pipelines d'analyse : acheminez les logs en aval vers Google BigQuery, Data Lake ou des workflows d'apprentissage automatique personnalisés. +- Pour le traitement piloté par les événements : publiez les logs dans un sujet Pub/Sub afin que Google Cloud Functions, les fonctions Cloud Run et les tâches Dataflow puissent effectuer des actions en temps réel basées sur les données de log. + +## Prérequis {#prerequisites} + +Avant de configurer la destination, vous avez besoin des éléments suivants : + +- Abonnement Pub/Sub : créez un sujet Pub/Sub et au moins un abonnement pour consommer les messages. +- Authentification : configurez une [méthode d'authentification Google Cloud standard][2]. Ces options incluent : + - Une clé de compte de service (fichier JSON) + - Une identité de charge de travail (Google Kubernetes Engine (GKE)) +- Rôles IAM : + - `roles/pubsub.publisher` est requis pour la publication d'événements. + - `roles/pubsub.viewer` est recommandé pour les contrôles d'état. + - Si le rôle est manquant, l'erreur `Healthcheck endpoint forbidden` est enregistrée et le Worker continue comme d'habitude. + - Consultez [Rôles Pub/Sub disponibles][3] pour plus d'informations. + +### Configurez un compte de service pour le Worker {#set-up-a-service-account-for-the-worker} + +Un compte de service dans Google Cloud est un type de compte utilisé uniquement par des applications ou des services. +- Il possède sa propre identité et ses propres identifiants (un fichier de clé JSON). +- Vous lui attribuez des rôles IAM afin qu'il puisse accéder à des ressources spécifiques. +- Dans ce cas, l'Observability Pipelines Worker utilise un compte de service pour s'authentifier et envoyer des logs à Pub/Sub en votre nom. + +Pour vous authentifier à l'aide d'un compte de service : + +1. Dans la console Google Cloud, accédez à **IAM et administration** > **[Comptes de service][4]**. +1. Cliquez sur **+ Créer un compte de service**. +1. Saisissez un nom et cliquez sur **Créer et continuer**. +1. Attribuez des rôles : + - **Éditeur Pub/Sub** + - **Lecteur Pub/Sub** +1. Cliquez sur **Terminé**. + +#### Méthodes d'authentification {#authentication-methods} + +Une fois le compte de service créé avec les rôles appropriés, configurez l'une des méthodes d'authentification suivantes : + +##### Option A : méthode Workload Identity (pour GKE, recommandée) {#option-a-workload-identity-method-for-gke-recommended} + +1. Associez le compte de service à un compte de service Kubernetes (KSA). +1. Autorisez l'usurpation d'identité du compte de service par ce KSA. +1. Annotez le KSA afin que GKE sache quel compte de service utiliser. +1. L'authentification provient alors du serveur de métadonnées de GCP. + +##### Option B : attachez le GSA directement à une VM (pour Google Compute Engine) {#option-b-attach-the-gsa-directly-to-a-vm-for-google-compute-engine} + +Utilisez cette méthode d'authentification si vous exécutez l'Observability Pipelines Worker sur une VM Google Compute Engine (GCE). +- Lorsque vous créez ou modifiez la VM, spécifiez le compte de service Google sous **Identité et accès aux API** > **Compte de service**. + +##### Option C : Exécuter le service en tant que GSA (pour Cloud Run ou Cloud Functions) {#option-c-run-the-service-as-the-gsa-for-cloud-run-or-cloud-functions} + +Utilisez cette méthode d'authentification si vous déployez le Worker en tant que service Cloud Run ou Cloud Function. +- Dans les paramètres de déploiement de Cloud Run ou Cloud Functions, définissez le **Compte de service d'exécution** sur le compte de service Google que vous avez créé. + +##### Option D : Méthode de clé JSON (tout environnement sans liaisons d'identité) {#option-d-json-key-method-any-environment-without-identity-bindings} + +1. Ouvrez le nouveau compte de service et accédez à **Clés** > **Ajouter une clé** > **Créer une nouvelle clé**. +1. Choisissez le format JSON. +1. Enregistrez le fichier JSON téléchargé dans un emplacement sécurisé. +1. Après avoir installé le Worker, copiez ou montez le fichier JSON dans `DD_OP_DATA_DIR/config/`. +Vous référencez ce fichier dans le champ {{< ui >}}Credentials path{{< /ui >}} lorsque vous [configurez la destination](#set-up-the-destination) dans l'interface utilisateur des pipelines. + +## Configuration {#setup} + +Configurez la destination Google Pub/Sub lorsque vous [configurez un pipeline][9]. Vous pouvez configurer un pipeline dans l'[interface utilisateur][1], en utilisant l'[API][10] ou avec [Terraform][11]. Les étapes de cette section sont configurées dans l'interface utilisateur. + +Après avoir sélectionné la destination Google Pub/Sub dans l'interface utilisateur du pipeline : + +1. Saisissez le nom du projet de destination. + - Il s'agit du projet GCP où se trouve votre sujet Pub/Sub. +1. Saisissez le sujet. + - Il s'agit du sujet Pub/Sub vers lequel publier les logs. +1. Dans le menu déroulant {{< ui >}}Encoding{{< /ui >}}, sélectionnez si vous souhaitez encoder la sortie de votre pipeline en {{< ui >}}JSON{{< /ui >}} ou {{< ui >}}Raw message{{< /ui >}}. + - {{< ui >}}JSON{{< /ui >}} : Les journaux sont structurés au format JSON (recommandé si les outils en aval ont besoin de données structurées). + - {{< ui >}}Raw{{< /ui >}} : Les journaux sont envoyés sous forme de chaînes brutes (préserve le format d'origine). +1. Si vous disposez d'un fichier JSON d'identifiants, saisissez le chemin d'accès à votre fichier JSON d'identifiants. + - Si vous utilisez un fichier JSON de compte de service : saisissez le chemin `DD_OP_DATA_DIR/config/.json`. + - Ou définissez la variable d'environnement `GOOGLE_APPLICATION_CREDENTIALS`. + - Les identifiants sont gérés automatiquement si vous utilisez [l'identité de charge de travail][7] sur GKE. + +### Paramètres optionnels {#optional-settings} + +#### Activer TLS {#enable-tls} + +
Pour la gestion des secrets : saisissez uniquement l'identifiant du mot de passe de la clé TLS. Ne saisissez pas la valeur réelle.
+ +{{% observability_pipelines/tls_settings %}} + +{{% observability_pipelines/secrets_env_var_note %}} + +#### Mise en mémoire tampon {#buffering} + +{{% observability_pipelines/destination_buffer %}} + +{{< img src="observability_pipelines/destinations/google_pubsub_settings.png" alt="La destination Google Pub/Sub avec des exemples de valeurs" style="width:30%;" >}} + +## Valeurs par défaut des secrets {#secret-defaults} + +{{% observability_pipelines/set_secrets_intro %}} + +{{< tabs >}} +{{% tab "Gestion des secrets" %}} + +- (Facultatif) Identifiant de l'URL d'endpoint Google Pub/Sub : + - Par défaut, le Worker envoie les données vers l'endpoint global : `https://pubsub.googleapis.com`. + - Si votre sujet Pub/Sub est spécifique à une région, configurez l'URL d'endpoint Google Pub/Sub alternative avec l'endpoint régional. Consultez [À propos des points de terminaison Pub/Sub][1] pour plus d'informations. Saisissez l'URL d'endpoint configurée dans votre gestionnaire de secrets. + - L'identifiant par défaut est `DESTINATION_GCP_PUBSUB_ENDPOINT_URL`. +- Identifiant du mot de passe TLS Google Pub/Sub (lorsque TLS est activé) : + - L'identifiant par défaut est `DESTINATION_GCP_PUBSUB_KEY_PASS`. + +[1]: https://docs.cloud.google.com/pubsub/docs/reference/service_apis_overview#pubsub_endpoints + +{{% /tab %}} + +{{% tab "Variables d'environnement" %}} + +#### Points de terminaison Pub/Sub alternatifs facultatifs {#optional-alternative-pubsub-endpoints} + +{{< img src="observability_pipelines/destinations/google_pubsub_env_var.png" alt="La page d'installation affichant le champ de variable d'environnement Google Pub/Sub" style="width:70%;" >}} + +{{% observability_pipelines/configure_existing_pipelines/destination_env_vars/google_pubsub %}} + +{{% /tab %}} +{{< /tabs >}} + +## Dépannage {#troubleshooting} + +Problèmes courants et solutions : +- Vérification de l'état interdite + - Vérifiez le rôle IAM `roles/pubsub.viewer`. +- Autorisation refusée + - Assurez-vous que le compte de service dispose de `roles/pubsub.publisher`. +- Erreurs d'authentification + - Vérifiez le chemin d'accès au JSON des identifiants ou la configuration de l'identité de charge de travail GKE. +- Événements abandonnés + - Vérifiez les métriques `pipelines.component_discarded_events_total` et `pipelines.buffer_discarded_events_total`. + - Augmentez la taille du tampon ou corrigez les filtres mal configurés si nécessaire pour résoudre le problème. +- Latence élevée + - Réduisez la taille du tampon et le délai d'attente, ou mettez à l'échelle vos Workers. +- Aucun log n'arrive + - Dans la configuration de votre destination Google Pub/Sub, vérifiez le nom du sujet, le projet et l'endpoint Pub/Sub (global ou régional). + +## Métriques de santé {#health-metrics} + +Pour les [métriques de composant][8] et les [métriques de tampon de destination][12] émises par toutes les destinations, consultez la documentation sur les [métriques d'utilisation des pipelines][13]. Pour filtrer ou regrouper par métriques de destination Google Pub/Sub, utilisez le tag `component_type:gcp_pubsub`. + +### Traitement par lots d'événements {#event-batching} + +Un lot d'événements est vidé lorsque l'un de ces paramètres est atteint. Consultez [Lot d'événements des destinations][6] pour plus d'informations. + +| Nombre maximal d'événements | Taille maximale (Mo) | Délai d'attente (secondes) | +|----------------|-------------------|---------------------| +| 1 000 | 10 | 1 | + +[1]: https://app.datadoghq.com/observability-pipelines +[2]: https://cloud.google.com/docs/authentication#auth-flowchart +[3]: https://cloud.google.com/pubsub/docs/access-control#roles +[4]: https://console.cloud.google.com/iam-admin/serviceaccounts +[6]: /fr/observability_pipelines/destinations/#event-batching +[7]:https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity +[8]: /fr/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#component-metrics +[9]: /fr/observability_pipelines/configuration/set_up_pipelines/ +[10]: /fr/api/latest/observability-pipelines/ +[11]: https://registry.terraform.io/providers/datadog/datadog/latest/docs/resources/observability_pipeline +[12]: /fr/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#destination-buffer-metrics +[13]: /fr/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/ \ No newline at end of file diff --git a/hugo/content/fr/observability_pipelines/monitoring_and_troubleshooting/_index.md b/hugo/content/fr/observability_pipelines/monitoring_and_troubleshooting/_index.md new file mode 100644 index 00000000000..4e30c8f8ca0 --- /dev/null +++ b/hugo/content/fr/observability_pipelines/monitoring_and_troubleshooting/_index.md @@ -0,0 +1,18 @@ +--- +description: Trouvez des liens vers les commandes CLI du Worker, la surveillance des + pipelines, les métriques d'utilisation et les ressources de dépannage pour Observability + Pipelines. +disable_toc: false +title: Surveillance et dépannage +--- +Après avoir configuré les pipelines et mis à l'échelle les Workers : + +- Si vous essayez de résoudre un problème avec l'Observability Pipelines Worker, consultez [Worker CLI Commands][1] pour savoir comment voir les données brutes envoyées au Worker. +- Vous pouvez suivre l'état de vos pipelines et composants grâce à des graphiques de santé et des moniteurs prêts à l'emploi. Consultez [Monitoring Pipelines][2] pour plus d'informations. +- Vous pouvez également créer vos propres moniteurs, tableaux de bord et notebooks pour surveiller vos pipelines. Consultez [Pipeline Usage Metrics][3] pour obtenir une liste de métriques. +- Si vous rencontrez des problèmes avec Observability Pipelines, consultez [Troubleshooting][4]. + +[1]: /fr/observability_pipelines/monitoring_and_troubleshooting/worker_cli_commands/ +[2]: /fr/observability_pipelines/monitoring_and_troubleshooting/monitoring_pipelines/ +[3]: /fr/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/ +[4]: /fr/observability_pipelines/monitoring_and_troubleshooting/troubleshooting/ \ No newline at end of file diff --git a/hugo/content/fr/observability_pipelines/packs/aviatrix_suricata_ids_ips.md b/hugo/content/fr/observability_pipelines/packs/aviatrix_suricata_ids_ips.md new file mode 100644 index 00000000000..3dacf589a5a --- /dev/null +++ b/hugo/content/fr/observability_pipelines/packs/aviatrix_suricata_ids_ips.md @@ -0,0 +1,15 @@ +--- +description: En savoir plus sur le pack Aviatrix Suricata IDS/IPS. +title: Aviatrix Suricata IDS/IPS +--- +## Présentation {#overview} + +{{< img src="observability_pipelines/packs/aviatrix_suricata_ids_ips.png" alt="Le pack Aviatrix Suricata IDS/IPS" style="width:25%;" >}} + +Les alertes Aviatrix Suricata IDS/IPS capturent les correspondances de signatures sur le trafic réseau de la passerelle. + +Ce que fait ce pack : + +- Extrait la signature d'alerte : +- Associe la gravité IDS au statut : +- Marque les actions de blocage IPS : \ No newline at end of file diff --git a/hugo/content/fr/observability_pipelines/processors/tags.md b/hugo/content/fr/observability_pipelines/processors/tags.md new file mode 100644 index 00000000000..e19cc44eb02 --- /dev/null +++ b/hugo/content/fr/observability_pipelines/processors/tags.md @@ -0,0 +1,31 @@ +--- +aliases: +- /fr/observability_pipelines/processors/tag_control/logs/ +description: Apprenez à utiliser le processeur de tags pour exclure ou inclure des + tags spécifiques dans le tableau de tags Datadog pour les logs provenant du Datadog + Agent. +disable_toc: false +products: +- icon: logs + name: Logs + url: /observability_pipelines/configuration/?tab=logs#pipeline-types +title: Processeur de tags +--- +{{< product-availability >}} + +## Présentation {#overview} + +Pour les logs provenant du Datadog Agent, utilisez ce processeur pour exclure ou inclure des tags spécifiques dans le tableau de tags Datadog (`ddtags`). Les tags exclus ou non inclus sont supprimés et peuvent réduire votre volume de logs sortants. + +## Configuration {#setup} + +Pour configurer le processeur : + +1. Définissez un {{< ui >}}filter query{{< /ui >}}. Consultez [Logs Search Syntax][2] pour plus d'informations. + - Seuls les logs correspondant au filtre sont traités. + - Tous les logs, qu'ils correspondent ou non à la requête de filtrage, sont envoyés à l'étape suivante du pipeline. +1. Facultatif : saisissez un tableau de tags Datadog pour la section {{< ui >}}Configure tags{{< /ui >}}. Les formats pris en charge sont `["key:value", "key"]`. Consultez [Define Tags][1] pour plus d'informations sur le format `key:value`. +1. Dans la section {{< ui >}}Configure tags{{< /ui >}}, choisissez si vous souhaitez {{< ui >}}Exclude tags{{< /ui >}} ou {{< ui >}}Include tags{{< /ui >}}. Si vous avez fourni un tableau de tags à l'étape précédente, sélectionnez les clés de tag que vous souhaitez configurer. Vous pouvez également ajouter manuellement des clés de tag. **Remarque**: Vous pouvez sélectionner jusqu'à 100 tags. + +[1]: /fr/getting_started/tagging/#define-tags +[2]: /fr/observability_pipelines/search_syntax/logs/ \ No newline at end of file diff --git a/hugo/content/fr/observability_pipelines/scaling_and_performance/best_practices_for_scaling_observability_pipelines.md b/hugo/content/fr/observability_pipelines/scaling_and_performance/best_practices_for_scaling_observability_pipelines.md new file mode 100644 index 00000000000..8db940f8e4f --- /dev/null +++ b/hugo/content/fr/observability_pipelines/scaling_and_performance/best_practices_for_scaling_observability_pipelines.md @@ -0,0 +1,230 @@ +--- +aliases: +- /fr/observability_pipelines/best_practices_for_scaling_observability_pipelines/ +description: Apprenez l'architecture d'agrégateur recommandée, l'optimisation des + instances et les pratiques de planification de la capacité pour la mise à l'échelle + des Observability Pipelines Workers dans les grands déploiements. +further_reading: +- link: https://www.datadoghq.com/architecture/op-vm-deployment/ + tag: Architecture Center + text: Déploiement d'Observability Pipelines VM +- link: https://www.datadoghq.com/architecture/observability-pipelines-kubernetes-deployment/ + tag: Architecture Center + text: Déploiement d'Observability Pipelines pour Kubernetes +title: Recommandations pour la mise à l'échelle des Observability Pipelines +--- +
+Ce guide est destiné aux déploiements à grande échelle en production. +
+ +## Présentation {#overview} + +Déployez l'Observability Pipelines Worker dans votre infrastructure, comme vous le feriez pour tout autre service, afin d'intercepter, de manipuler et de transférer des données vers vos destinations. Chaque instance d'Observability Pipelines Worker est conçue pour fonctionner indépendamment, vous permettant de mettre à l'échelle votre architecture avec l'équilibrage de charge. + +Ce guide vous présente le modèle d'agrégateur recommandé pour les nouveaux utilisateurs d'Observability Pipelines Worker, spécifiquement : + +- [Modèles et approches d'architecture](#architecture) +- [Optimisation de l'instance](#optimize-the-instance) afin que vous puissiez mettre à l'échelle horizontalement l'agrégateur Observability Pipelines Worker. +- Points de départ pour estimer votre capacité de ressources pour la [planification de la capacité et la mise à l'échelle](#capacity-planning-and-scaling) du Observability Pipelines Worker. + +## Architecture {#architecture} + +Cette section couvre : + +- Modèles d'architecture : + - [Modèle basé sur des VM](#vm-based-architecture) + - [Modèle basé sur Kubernetes](#kubernetes-based-architecture) +- [Approche centralisée vs décentralisée](#centralized-vs-decentralized-approach) +- [Choisir entre une architecture basée sur des VM et une architecture basée sur Kubernetes](#choosing-a-vm-based-vs-kubernetes-based-architecture) + +### Modèles d'architecture {#architecture-models} + +Il existe deux modèles d'architecture courants : + +- **Architecture basée sur des machines virtuelles (basée sur des VM)** : un modèle basé sur l'host, précédé d'un équilibreur de charge. +- **Architecture basée sur Kubernetes** : un modèle basé sur des conteneurs qui peut éventuellement être placé derrière un contrôleur d'entrée ou un équilibreur de charge (pour les sources externes au cluster, un service Kubernetes gère les requêtes internes au cluster). + +Les deux modèles peuvent être appliqués à une approche centralisée ou décentralisée. Dans une approche centralisée, les Workers fonctionnent à l'échelle mondiale, à travers des centres de données ou des régions. Dans une approche décentralisée, les Workers fonctionnent à l'échelle locale, c'est-à-dire dans la région, le centre de données ou le cluster où se trouve la source de données. Pour les environnements à grande échelle couvrant de nombreux centres de données, régions ou comptes de fournisseurs cloud, un modèle hybride peut être approprié. + +En règle générale, Datadog recommande de faire fonctionner le Worker aussi près que possible de la source de données. Cela peut nécessiter davantage de frais administratifs et d'infrastructure, mais cela réduit les préoccupations concernant les problèmes de transit réseau et les points de défaillance uniques. + +Pour les deux modèles, Datadog recommande de mettre à l'échelle les Workers [horizontalement][1] pour gérer une charge accrue et maintenir une haute disponibilité. Vous pouvez y parvenir en utilisant un groupe d'instances géré (tel qu'un autoscaling group) ou horizontal pod autoscaling. + +Le Worker peut également être mis à l'échelle [verticalement][2], ce qui tire parti de cœurs et de mémoire supplémentaires sans aucune configuration additionnelle. Pour certains processeurs, tels que le processeur Sensitive Data Scanner avec de nombreuses règles activées, ou pour des cas d'utilisation à traitement intensif, le Worker bénéficie de cœurs supplémentaires pour permettre l'exécution de threads en parallèle. Lors d'une mise à l'échelle verticale, Datadog recommande de limiter la taille d'une instance afin qu'elle ne traite pas plus de 33 % de votre volume total. Cela permet une haute disponibilité en cas de défaillance d'un nœud. + +#### Architecture basée sur VM {#vm-based-architecture} + +Le diagramme d'architecture suivant concerne une architecture basée sur l'host, où un équilibreur de charge accepte le trafic provenant de sources basées sur le push. Si seules des sources basées sur le pull sont utilisées, un équilibreur de charge n'est pas requis. Dans le diagramme, le Worker fait partie d'un groupe d'instances géré qui s'adapte en fonction des besoins de traitement. Consultez [Déploiement de VM Observability Pipelines][9] pour plus de détails. + +{{< img src="observability_pipelines/scaling_best_practices/vm-infra.png" alt="Diagramme montrant le Worker faisant partie d'un groupe d'instances géré" style="width:100%;" >}} + + +#### Architecture basée sur Kubernetes {#kubernetes-based-architecture} + +Le diagramme d'architecture suivant concerne une architecture basée sur des conteneurs, où le service Kubernetes agit comme routeur vers le statefulset et accepte le trafic provenant de sources basées sur le push. Si vous envoyez de la télémétrie depuis l'extérieur du cluster, définissez le [service.type sur `LoadBalancer`][3] ou installez un [ingress controller][4] et configurez une [ingress][5] pour le routage. Le Worker s'exécute dans le cadre d'un statefulset et prend en charge la mise à l'échelle horizontale des pods pour ajuster la capacité en fonction des besoins de traitement. Comme pour l'architecture basée sur des VM, les Workers peuvent également évoluer verticalement et tirer parti de plusieurs cœurs pour le traitement parallèle. Consultez [Déploiement d'Observability Pipelines pour Kubernetes][10] pour plus de détails. + +{{< img src="observability_pipelines/scaling_best_practices/containerized-infra.png" alt="Diagramme montrant le Worker dans le cadre d'un statefulset" style="width:100%;" >}} + +### Choisir entre une architecture basée sur des VM et une architecture basée sur Kubernetes {#choosing-a-vm-based-vs-kubernetes-based-architecture} + +Choisissez l'architecture basée sur Kubernetes si : + +- Vos sources de logs se trouvent au sein d'un cluster Kubernetes et vous souhaitez utiliser l'approche décentralisée +- Votre organisation utilise intensivement Kubernetes et le maîtrise parfaitement + +Choisissez l'architecture basée sur des VM si votre organisation est davantage centrée sur les VM et ne maîtrise pas Kubernetes. + +Le choix entre les deux modèles dépend de ce que votre organisation est la mieux équipée pour faire du point de vue de l'infrastructure. Chaque modèle offre la possibilité de mettre à l'échelle automatiquement en fonction de l'utilisation du CPU, qui constitue généralement la contrainte principale pour Observability Pipelines. Consultez [Optimiser l'instance][6] pour plus d'informations. + +### Approche centralisée vs décentralisée {#centralized-vs-decentralized-approach} + +Datadog recommande l'approche décentralisée consistant à déployer les Workers aussi près que possible de la source de données. Cela signifie placer les Workers au sein de chaque emplacement où les données sont générées, comme la région, le cluster ou le centre de données. Le modèle décentralisé est préférable pour les environnements avec de grands volumes de données : + +- Minimise le transit réseau inter-région ou inter-centre de données +- Évite les problèmes de performance potentiels liés au transfert de données inter-région ou inter-compte +- Aide à réduire les coûts de transfert de données en maintenant le traitement localement au niveau des sources de données +- Réduit la latence de livraison des logs en traitant les données à la source avant leur transfert + +Un déploiement centralisé exécute les Workers dans un emplacement unique, agrégeant les données provenant de plusieurs régions, clusters ou centres de données. Un pool unique de Workers peut recevoir des données provenant de plusieurs clusters Kubernetes ou comptes AWS. Cette approche fonctionne mieux pour des volumes de données plus faibles ou lorsque le peering réseau existe déjà entre ces environnements. Sachez que les transferts de données à haut volume entre régions ou comptes peuvent entraîner des coûts supplémentaires. + +Un modèle hybride est un bon compromis entre les approches décentralisée et centralisée, en particulier pour les déploiements d'infrastructures vastes et étendues. Par exemple, si vous avez six régions et que dans chaque région vous avez 10 clusters Kubernetes, plutôt que : + +- Déployer des Workers dans chaque cluster, ce qui entraîne 60 déploiements +- Déployer des Workers dans une seule région et acheminer le trafic entre les régions, ce qui introduit un point de défaillance unique + +Une approche hybride utilise un cluster Kubernetes dédié ou un groupe d'instances géré dans chaque région, ce qui ne nécessite que six déploiements. Les 10 clusters au sein de chaque région envoient leurs données au déploiement régional de l'Observability Pipelines Worker (OPW). + +## Optimiser l'instance {#optimize-the-instance} + +### Dimensionnement de l'instance {#instance-sizing} + +Sur la base d'analyses de performance pour un pipeline utilisant 12 processeurs pour transformer les données, le Worker peut traiter environ 1 To par vCPU par jour. Par exemple, si vous avez 4 To d'événements par jour, vous devez provisionner suffisamment de ressources de calcul, avec une marge de sécurité, pour couvrir vos volumes. Cela pourrait correspondre à trois machines ou conteneurs à deux cœurs, ou à une machine ou un conteneur à six cœurs. + +L'Observability Pipelines Worker est presque toujours limité par le CPU et, comme les métriques d'utilisation du CPU ne produisent pas de faux positifs, elles constituent le signal le plus fiable pour la mise à l'échelle automatique. Datadog recommande de déployer les Workers dans le cadre d'un groupe de mise à l'échelle automatique ou avec [Horizontal Pod Autoscaling][7] activé. Ne vous reposez pas sur un nombre de machines virtuelles ou de conteneurs configuré de manière statique. Cela permet de garantir que vous pouvez gérer en toute sécurité les pics de trafic sans perte de données et maintenir une haute disponibilité si un Worker tombe en panne. + +Pour les environnements à haut débit, Datadog recommande des types de machines plus grands car ils disposent généralement d'une bande passante réseau plus élevée. Consultez la documentation de votre fournisseur cloud pour plus de détails (par exemple, [bande passante réseau des instances Amazon EC2][8]). + +| Fournisseur cloud| Recommandation (minimum) | +| ------------- | ------------------------ | +| AWS | c7i.xlarge | +| Azure | F4s v2 | +| Google Cloud | c2-standard-4 | + +**Remarque** : 1 vCPU = 1 processeur physique ARM ou 0,5 processeur physique Intel avec hyperthreading. + +### Dimensionnement du processeur {#cpu-sizing} + +La plupart des charges de travail des Observability Pipelines Worker sont limitées par le processeur et bénéficient des processeurs modernes. + +| Fournisseur cloud| Recommandation | +| ------------- | --------------------------------------------------------------------- | +| AWS | Intel Xeon de dernière génération, 8 vCPUs (recommandé), au moins 4 vCPUs | +| Azure | Intel Xeon de dernière génération, 8 vCPUs (recommandé), au moins 4 vCPUs | +| Google Cloud | Intel Xeon de dernière génération, 8 vCPUs (recommandé), au moins 4 vCPUs | +| Private | Intel Xeon de dernière génération, 8 vCPUs (recommandé), au moins 4 vCPUs | + +### Architectures de processeur {#cpu-architectures} + +L'Observability Pipelines Worker fonctionne sur des architectures processeur x86 et ARM modernes. + +### Dimensionnement de la mémoire {#memory-sizing} + +En raison du système de typage affine de l'Observability Pipelines Worker, la mémoire est rarement limitée pour les charges de travail de l'Observability Pipelines Worker. Par conséquent, Datadog recommande un minimum de ≥2 Gio de mémoire par vCPU. L'utilisation de la mémoire augmente avec le nombre de destinations en raison de la mise en mémoire tampon et du traitement par lots. Si vous avez un grand nombre de destinations, envisagez d'augmenter la mémoire. + +### Dimensionnement du disque {#disk-sizing} + +Vous avez besoin de 500 Mo d'espace disque pour installer l'Observability Pipelines Worker. + +## Planification de la capacité et mise à l'échelle {#capacity-planning-and-scaling} + +### Unités pour les estimations {#units-for-estimations} + +Les unités suivantes servent de points de départ pour estimer la capacité de vos ressources, mais elles peuvent varier en fonction de votre workload. + +| Unité | Taille | Débit d'Observability Pipelines Worker*| +| ----------------------| --------- | ----------------------------------------- | +| Événement de log non structuré| ~512 octets| ~10 MiB/s/vCPU | +| Événement de log structuré | ~1,5 Ko | ~25 MiB/s/vCPU | + +*Ces chiffres sont conservateurs à des fins d'estimation. 1 vCPU = 1 processeur physique ARM et 0,5 processeur physique Intel. + +### Mise à l'échelle {#scaling} + +#### Mise à l'échelle horizontale {#horizontal-scaling} + +La mise à l'échelle horizontale consiste à répartir le trafic entre plusieurs instances d'Observability Pipelines Worker. Observability Pipelines Worker possède une architecture sans partage et ne nécessite pas de nœuds principaux ni aucune coordination de ce type qui pourrait compliquer la mise à l'échelle. + +Pour les sources basées sur une méthode push, placez un répartiteur de charge réseau en amont de vos instances de l'Observability Pipelines Worker et dimensionnez-les en fonction des besoins. + +Un équilibreur de charge n'est pas requis pour les sources basées sur le modèle pull. Déployez Observability Pipelines Worker et adaptez sa taille à la hausse ou à la baisse selon vos besoins. Votre système de publication-abonnement coordonne l'accès exclusif aux données lorsque Observability Pipelines Worker demande à les lire. + +##### Équilibrage de charge {#load-balancing} + +Un équilibreur de charge n'est requis que pour les sources basées sur le modèle push, telles que les agents. Vous n'avez pas besoin d'un équilibreur de charge si vous utilisez exclusivement des sources basées sur le modèle pull, comme Kafka. + +###### Équilibrage de charge côté client {#client-side-load-balancing} + +L'équilibrage de charge côté client n'est pas recommandé. L'équilibrage de charge côté client fait référence aux clients qui effectuent l'équilibrage de charge du trafic entre plusieurs instances d'Observability Pipelines Worker. Bien que cette approche semble plus simple, elle peut être moins fiable et plus compliquée car : + +- L'équilibrage de charge avec basculement approprié est complexe. Les problèmes dans ce domaine sont sensibles car ils peuvent entraîner une perte de données ou des incidents qui perturbent vos services. Cela est exacerbé si vous travaillez avec plusieurs types de clients. +- L'intérêt de l'agrégateur Observability Pipelines Worker est de décharger vos agents, et la prise en charge de l'équilibrage de charge permet d'y parvenir. + +###### Types d'équilibreur de charge {#load-balancer-types} + +Datadog recommande des équilibreurs de charge de couche 4 (L4) (équilibreurs de charge réseau) car ils prennent en charge les protocoles d'Observability Pipelines Worker (TCP, UDP et HTTP). Même si vous envoyez exclusivement du trafic HTTP (couche 7), Datadog recommande des équilibreurs de charge L4 pour leurs performances et leur simplicité. + +| Fournisseur cloud| Recommandation | +| ------------- | --------------------------------------------------------------| +| AWS | AWS Network Load Balancer (NLB) | +| Azure | Internal Azure Load Balancer | +| Google Cloud | Internal TCP/UDP Network Load Balancer | +| Private | HAProxy, NGINX, ou un autre load balancer avec prise en charge de la couche 4 | + +###### Configurations de l'équilibreur de charge {#load-balancer-configurations} + +Lors de la configuration des clients et des équilibreurs de charge, Datadog recommande les paramètres généraux suivants : + +- Utilisez une stratégie d'équilibrage de charge round-robin simple. +- N'activez pas l'équilibrage de charge inter-zones à moins que le trafic entre les zones ne soit très déséquilibré. +- Configurez les équilibreurs de charge pour utiliser l'endpoint de l'API health d'Observability Pipelines Worker pour l'état de la cible. +- Assurez-vous que vos instances d'Observability Pipelines Worker s'enregistrent ou se désenregistrent automatiquement lors de leur mise à l'échelle. +- Activez le keep-alive avec un délai d'inactivité d'une minute maximum pour vos clients et vos équilibreurs de charge. +- Si cela est pris en charge, activez la simultanéité et le regroupement de connexions sur vos agents. Si cela n'est pas pris en charge, envisagez l'architecture unifiée qui déploie Observability Pipelines Worker à la périphérie. Le regroupement de connexions garantit que de grands volumes de données sont répartis sur plusieurs connexions pour aider à équilibrer le trafic. + +###### Points chauds de l'équilibreur de charge {#load-balancer-hot-spots} + +Les points chauds d'équilibrage de charge se produisent lorsqu'une ou plusieurs instances d'Observability Pipelines Worker reçoivent un trafic disproportionné. Les points chauds surviennent généralement pour l'une des deux raisons suivantes : + +1. Une quantité importante de trafic est envoyée via une seule connexion. +2. Le trafic dans une zone de disponibilité est beaucoup plus élevé que dans les autres. + +Dans ces cas, les tactiques d'atténuation respectives suivantes sont recommandées : + +1. Divisez les connexions volumineuses en plusieurs connexions. La plupart des clients autorisent la simultanéité et le regroupement de connexions qui répartissent les données sur plusieurs connexions. Cette tactique permet à votre équilibreur de charge de répartir la connexion sur plusieurs instances d'Observability Pipelines Worker. Si votre client ne prend pas cela en charge, envisagez l'architecture unifiée, où Observability Pipelines Worker peut être déployé en plus à la périphérie. +2. Activez l'équilibrage de charge inter-zones sur votre équilibreur de charge. L'équilibrage inter-zones répartit tout le trafic des zones de disponibilité sur toutes les instances d'Observability Pipelines Worker. + +#### Mise à l'échelle verticale {#vertical-scaling} + +Le modèle de concurrence d'Observability Pipelines Worker s'adapte automatiquement pour tirer parti de tous les vCPUs. Aucun paramètre de concurrence ni aucune modification de configuration ne sont requis. Lors d'une mise à l'échelle verticale, Datadog recommande de limiter la taille d'une instance pour traiter au maximum 50 % de votre volume total et de déployer au moins deux instances d'Observability Pipelines Worker pour assurer la haute disponibilité. + +#### Mise à l'échelle automatique {#auto-scaling} + +La mise à l'échelle automatique doit être basée sur l'utilisation moyenne du processeur. Pour la grande majorité des charges de travail, Observability Pipelines Worker est limité par le processeur. L'utilisation du processeur est le signal le plus fiable pour la mise à l'échelle automatique car elle ne produit pas de faux positifs. Datadog vous recommande d'utiliser les paramètres suivants, en les ajustant si nécessaire : + +- CPU moyen avec un objectif d'utilisation de 85 %. +- Une période de stabilisation de cinq minutes pour le passage à l'échelle supérieure et inférieure. + +## Lectures complémentaires {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /fr/observability_pipelines/scaling_and_performance/best_practices_for_scaling_observability_pipelines/#horizontal-scaling +[2]: /fr/observability_pipelines/scaling_and_performance/best_practices_for_scaling_observability_pipelines/#vertical-scaling +[3]: https://github.com/DataDog/helm-charts/blob/main/charts/observability-pipelines-worker/values.yaml#L208-L209 +[4]: https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/ +[5]: https://github.com/DataDog/helm-charts/blob/main/charts/observability-pipelines-worker/values.yaml#L238 +[6]: /fr/observability_pipelines/scaling_and_performance/best_practices_for_scaling_observability_pipelines/#optimize-the-instance +[7]: https://github.com/DataDog/helm-charts/blob/main/charts/observability-pipelines-worker/values.yaml#L70-L85 +[8]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html +[9]: https://www.datadoghq.com/architecture/op-vm-deployment/ +[10]: https://www.datadoghq.com/architecture/observability-pipelines-kubernetes-deployment/ \ No newline at end of file diff --git a/hugo/content/fr/observability_pipelines/sources/splunk_hec.md b/hugo/content/fr/observability_pipelines/sources/splunk_hec.md new file mode 100644 index 00000000000..e242cdba715 --- /dev/null +++ b/hugo/content/fr/observability_pipelines/sources/splunk_hec.md @@ -0,0 +1,117 @@ +--- +description: Apprenez à collecter des logs à partir d'un collecteur d'événements HTTP + (HEC) Splunk à l'aide de l'Observability Pipelines Worker. +disable_toc: false +products: +- icon: logs + name: Logs + url: /observability_pipelines/configuration/?tab=logs#pipeline-types +title: Source du Splunk HTTP Event Collector (HEC) +--- +{{< product-availability >}} + +## Présentation {#overview} + +Utilisez la source Splunk HTTP Event Collector (HEC) d’Observability Pipelines pour recevoir des logs de votre Splunk HEC. Vous pouvez choisir de stocker le jeton HEC en tant que métadonnée d'événement et : + +- Envoyer des logs d'Observability Pipelines vers Splunk HEC avec le jeton d'origine envoyé avec l'événement. +- Utilisez le processeur de tableau d'enrichissement pour ajouter un champ de log à partir de votre lookup file, basé sur le jeton dans les métadonnées, puis traitez et acheminez vos logs en fonction de la valeur de ce champ. + +**Remarques** : +- Le Worker transfère le jeton HEC stocké qui est reçu vers le composant suivant. +- Les jetons Splunk HEC stockés ne sont pas affichés dans [Live Capture][9]. +- Utilisez la source Splunk HEC si vous souhaitez [envoyer des logs de la Splunk Distribution of the OpenTelemetry Collector vers Observability Pipelines](#send-logs-from-the-splunk-distribution-of-the-opentelemetry-collector-to-observability-pipelines). + +## Prérequis {#prerequisites} + +{{% observability_pipelines/prerequisites/splunk_hec %}} + +## Configuration {#setup} + +
Pour la gestion des secrets : saisissez uniquement les identifiants de l'adresse Splunk HEC et, le cas échéant, les clés de mot de passe TLS et de jeton d'authentification. Ne saisissez pas les valeurs réelles.
+ +Configurez cette source lorsque vous [configurez un pipeline][1]. Vous pouvez configurer un pipeline dans l'[interface utilisateur][6], en utilisant l'[API][7] ou avec [Terraform][8]. Les instructions de cette section concernent la configuration de la source dans l'UI. + +Après avoir sélectionné la source Splunk HEC dans l'interface utilisateur du pipeline : + +1. Saisissez l'identifiant de votre adresse Splunk HEC. Si vous le laissez vide, le [default](#secret-defaults) est utilisé. +1. Activez {{< ui >}}Store HEC token{{< /ui >}} uniquement si vous souhaitez effectuer l'une des opérations suivantes : + - Utilisez une destination Splunk HEC avec la stratégie de jeton {{< ui >}}From Source{{< /ui >}}. + - Utilisez un processeur de tableau d'enrichissement pour mapper les jetons Splunk HEC à partir d'un fichier local. + +{{% observability_pipelines/secrets_env_var_note %}} + +### Paramètres optionnels {#optional-settings} + +#### Activer TLS {#enable-tls} + +{{% observability_pipelines/tls_settings %}} + +{{% observability_pipelines/tls_settings_mtls %}} + +#### Configurer les jetons d'authentification {#configure-authentication-tokens} + +Si vous stockez des jetons Splunk HEC dans l'en-tête d'autorisation de votre requête HTTP, vous pouvez configurer Observability Pipelines pour vérifier si les requêtes HTTP entrantes possèdent un jeton valide. Les événements de requête qui ne possèdent pas de jeton valide sont abandonnés. + +Pour configurer les jetons d'authentification, activez le commutateur {{< ui >}}Configure authentication tokens{{< /ui >}} : + +1. Cliquez sur {{< ui >}}Manage Tokens{{< /ui >}} puis sur {{< ui >}}Add Token{{< /ui >}}. +1. Saisissez l'identifiant de votre clé de jeton.
**Remarque** : Si vous utilisez des variables d'environnement, la variable d'environnement pour ce jeton est l'identifiant que vous avez saisi, précédé de `DD_OP_`. +1. (Facultatif) Saisissez un champ et une valeur si vous souhaitez ajouter des informations supplémentaires aux logs authentifiés avec succès avec ce jeton spécifique. + +## Valeurs par défaut des secrets {#secret-defaults} + +{{% observability_pipelines/set_secrets_intro %}} + +{{< tabs >}} +{{% tab "Gestion des secrets" %}} + +- Identifiant de l'adresse Splunk HEC : + - Référence l'adresse de liaison, telle que `0.0.0.0:8088`, sur laquelle votre Observability Pipelines Worker écoute pour recevoir les logs initialement destinés à l'indexeur Splunk. + - L'identifiant par défaut est `SOURCE_SPLUNK_HEC_ADDRESS`. +- Identifiant de la phrase secrète TLS Splunk HEC (lorsque TLS est activé) : + - L'identifiant par défaut est `SOURCE_SPLUNK_HEC_KEY_PASS`. + +{{% /tab %}} + +{{% tab "Variables d'environnement" %}} + +{{% observability_pipelines/configure_existing_pipelines/source_env_vars/splunk_hec %}} + +{{% /tab %}} +{{< /tabs >}} + +{{% observability_pipelines/log_source_configuration/splunk_hec %}} + +## Envoyez des logs depuis la Splunk Distribution of the OpenTelemetry Collector vers Observability Pipelines {#send-logs-from-the-splunk-distribution-of-the-opentelemetry-collector-to-observability-pipelines} + +Pour envoyer des logs depuis la Splunk Distribution of the OpenTelemetry Collector : + +1. Installez le Splunk OpenTelemetry Collector en fonction de votre environnement : + - [Kubernetes][2] + - [Linux][3] +1. [Configurez un pipeline][4] en utilisant la [source Splunk HEC](#set-up-the-source-in-the-pipeline-ui). +1. Configurez le Splunk OpenTelemetry Collector: + ```bash + cp /etc/otel/collector/splunk-otel-collector.conf.example etc/otel/collector/splunk-otel-collector.conf + ``` + ```bash + # Splunk HEC endpoint URL, if forwarding to Splunk Observability Cloud + # SPLUNK_HEC_URL=https://ingest.us0.signalfx.com/v1/log + # If you're forwarding to a Splunk Enterprise instance running on example.com, with HEC at port 8088: + SPLUNK_HEC_URL=http://:8088/services/collector + ``` + - `` est l'adresse IP ou l'URL de l'host (ou de l'équilibreur de charge) associé à l'Observability Pipelines Worker. + - Pour les installations CloudFormation, la sortie `LoadBalancerDNS` CloudFormation contient l'URL correcte à utiliser. + - Pour les installations Kubernetes, l'enregistrement DNS interne du service Observability Pipelines Worker peut être utilisé, par exemple `opw-observability-pipelines-worker.default.svc.cluster.local`. + +**Remarque** : si vous utilisez un pare-feu, assurez-vous qu'il autorise le trafic du Splunk OpenTelemetry Collector vers le Worker. + +[1]: /fr/observability_pipelines/configuration/set_up_pipelines/ +[2]: https://help.splunk.com/en/splunk-observability-cloud/manage-data/splunk-distribution-of-the-opentelemetry-collector/get-started-with-the-splunk-distribution-of-the-opentelemetry-collector/collector-for-kubernetes +[3]: https://help.splunk.com/en/splunk-observability-cloud/manage-data/splunk-distribution-of-the-opentelemetry-collector/get-started-with-the-splunk-distribution-of-the-opentelemetry-collector/collector-for-linux +[4]: /fr/observability_pipelines/configuration/set_up_pipelines +[6]: https://app.datadoghq.com/observability-pipelines +[7]: /fr/api/latest/observability-pipelines/ +[8]: https://registry.terraform.io/providers/datadog/datadog/latest/docs/resources/observability_pipeline +[9]: /fr/observability_pipelines/configuration/live_capture/ \ No newline at end of file diff --git a/hugo/content/fr/opentelemetry/setup/ddot_collector/install/windows.md b/hugo/content/fr/opentelemetry/setup/ddot_collector/install/windows.md new file mode 100644 index 00000000000..8f4920b4cbd --- /dev/null +++ b/hugo/content/fr/opentelemetry/setup/ddot_collector/install/windows.md @@ -0,0 +1,343 @@ +--- +code_lang: windows +code_lang_weight: 5 +further_reading: +- link: /opentelemetry/setup/ddot_collector/custom_components + tag: Documentation + text: Utiliser des composants OpenTelemetry personnalisés avec le Datadog Agent +title: Installer le Collector DDOT sur Windows +type: multi-code-lang +--- +## Présentation {#overview} + +Suivez ce guide pour installer la distribution Datadog du Collector OpenTelemetry (DDOT) sur des hosts bare-metal et des machines virtuelles basés sur Windows. + +## Prérequis {#requirements} + +Pour compléter ce guide, vous avez besoin des éléments suivants : + +**Compte Datadog** : +1. [Créez un compte Datadog][1] si vous n'en avez pas. +1. Trouvez ou créez votre [clé d'API Datadog][2]. + +**Logiciel** : +- Une version Windows prise en charge (Windows Server 2016+ ou Windows 10+). Consultez les [plateformes prises en charge][14] pour plus de détails. + +**Réseau** : + +{{% otel-network-requirements %}} + +## Installer le Datadog Agent avec le Collector OpenTelemetry {#install-the-datadog-agent-with-opentelemetry-collector} + +
Cette installation est requise pour les configurations Datadog SDK + DDOT et OpenTelemetry SDK + DDOT. Bien que le SDK Datadog implémente l'API OpenTelemetry, il nécessite toujours le Collector DDOT pour traiter et transférer les métriques et logs OTLP.
+ +### Installation {#installation} + +Pour installer le Collector DDOT sur un host Windows, utilisez la commande MSI suivante : + +```powershell +$p = Start-Process -Wait -PassThru msiexec -ArgumentList '/qn /i "https://windows-agent.datadoghq.com/datadog-agent-7-latest.amd64.msi" /log C:\Windows\SystemTemp\install-datadog.log APIKEY="" SITE="{{< region-param key="dd_site" >}}" DD_OTELCOLLECTOR_ENABLED=true' +if ($p.ExitCode -ne 0) { + Write-Host "msiexec failed with exit code $($p.ExitCode) please check the logs at C:\Windows\SystemTemp\install-datadog.log" -ForegroundColor Red +} +``` + +Cette commande installe à la fois le package principal du Datadog Agent et le Collector DDOT qui s'exécute parallèlement. + +**Remarque** : Pour l'Agent v7.78+, si le Datadog Agent est déjà installé sur le host, vous pouvez installer le Collector DDOT séparément. Exécutez depuis une **session PowerShell élevée** : + +```powershell +& "$env:ProgramFiles\Datadog\Datadog Agent\bin\agent.exe" otel install +``` + +### Validation {#validation} + +Exécutez la [commande de statut][3] de l'Agent pour vérifier l'installation. + +```powershell +& "$env:ProgramFiles\Datadog\Datadog Agent\bin\agent.exe" status +``` + +Si aucune erreur n'a été rencontrée lors de l'installation, un rapport sur le statut de l'Agent est renvoyé. Les premières lignes ressemblent alors à ce qui suit : + +```text +==================== +Agent (v7.x.x) +==================== + Status date: 2025-08-22 18:35:17.449 UTC (1755887717449) + Agent start: 2025-08-22 18:16:27.004 UTC (1755886587004) + Pid: 2828211 + Go Version: go1.24.6 + Python Version: 3.12.11 + Build arch: amd64 + Agent flavor: agent + FIPS Mode: not available + Log Level: info +``` + +Il y aura également une {{< ui >}}OTel Agent{{< /ui >}} section de statut qui inclut des informations OpenTelemetry : + +```text +========== +OTel Agent +========== + + Status: Running + Agent Version: 7.x.x + Collector Version: v0.129.0 + + Receiver + ========================== + Spans Accepted: 0 + Metric Points Accepted: 1055 + Log Records Accepted: 0 + + Exporter + ========================== + Spans Sent: 0 + Metric Points Sent: 1055 + Log Records Sent: 0 +``` + +## Configurez le Datadog Agent {#configure-the-datadog-agent} + +### Activez le DDOT Collector {#enable-the-ddot-collector} +Le fichier de configuration du Datadog Agent est automatiquement installé à `C:\ProgramData\Datadog\datadog.yaml`. L'installateur ajoute les paramètres de configuration suivants à `C:\ProgramData\Datadog\datadog.yaml` pour activer le DDOT Collector : + +{{< code-block lang="yaml" filename="datadog.yaml" collapsible="true" >}} +otelcollector: + enabled: true +agent_ipc: + port: 5009 + config_refresh_interval: 60 +{{< /code-block >}} + +DDOT lie automatiquement l'OpenTelemetry Collector aux ports 4317 (grpc) et 4318 (http) par défaut. + +### (Facultatif) Activez des fonctionnalités Datadog supplémentaires {#optional-enable-additional-datadog-features} + +
L'activation de ces fonctionnalités peut entraîner des frais supplémentaires. Consultez la page de tarification et parlez à votre responsable de la réussite client avant de continuer.
+ +Pour obtenir une liste complète des options disponibles, consultez le fichier de référence entièrement commenté sur `C:\ProgramData\Datadog\datadog.yaml.example`. Sinon, consultez le [fichier de configuration de l'Agent pour Windows][12] sur GitHub. + +Lors de l'activation de fonctionnalités Datadog supplémentaires, utilisez toujours les fichiers de configuration du Collector Datadog ou du Collector OpenTelemetry au lieu de vous fier aux variables d'environnement Datadog. + +## Configurez l'OpenTelemetry Collector {#configure-the-opentelemetry-collector} + +L'installateur fournit un exemple de configuration de l'OpenTelemetry Collector sur `C:\ProgramData\Datadog\otel-config.yaml` que vous pouvez utiliser comme point de départ. + +{{% collapse-content title="Exemple de fichier otel-config.yaml issu de l'installation" level="p" %}} +L'exemple `otel-config.yaml` issu de l'installation ressemblera à ceci : +{{< code-block lang="yaml" filename="otel-config.yaml" collapsible="true" >}} +receivers: + prometheus: + config: + scrape_configs: + - job_name: "otelcol" + scrape_interval: 60s + static_configs: + - targets: ["0.0.0.0:8888"] + otlp: + protocols: + grpc: + endpoint: 0.0.0.0:4317 + http: + endpoint: 0.0.0.0:4318 +exporters: + debug: + verbosity: detailed + datadog: + api: + key: + site: + sending_queue: + batch: + flush_timeout: 10s +processors: + infraattributes: + cardinality: 2 + cumulativetodelta: +connectors: + datadog/connector: + traces: + compute_top_level_by_span_kind: true + peer_tags_aggregation: true + compute_stats_by_span_kind: true +service: + pipelines: + traces: + receivers: [otlp] + processors: [infraattributes] + exporters: [datadog, datadog/connector] + metrics: + receivers: [otlp, datadog/connector, prometheus] + processors: [infraattributes, cumulativetodelta] + exporters: [datadog] + logs: + receivers: [otlp] + processors: [infraattributes] + exporters: [datadog] +{{< /code-block >}} +{{% /collapse-content %}} + +#### Composants clés {#key-components} + +Pour envoyer des données de télémétrie à Datadog, les composants suivants sont définis dans la configuration : + +{{< img src="/opentelemetry/embedded_collector/components-3.jpg" alt="Diagramme illustrant le modèle de déploiement de l'Agent" style="width:100%;" >}} + +##### Datadog connector {#datadog-connector} + +Le [Datadog connector][4] calcule les métriques de trace Datadog APM. + +{{< code-block lang="yaml" filename="otel-config.yaml" disable_copy="false" collapsible="true" >}} +connectors: + datadog/connector: + traces: +{{< /code-block >}} + +##### Datadog Exporter {#datadog-exporter} + +Le [Datadog exporter][5] exporte des traces, des métriques et des logs vers Datadog. + +{{< code-block lang="yaml" filename="otel-config.yaml" disable_copy="false" collapsible="true" >}} +exporters: + datadog: + api: + key: + site: + sending_queue: + batch: + flush_timeout: 10s +{{< /code-block >}} + +**Remarque** : Si `key` n'est pas spécifié ou défini sur un secret, ou si `site` n'est pas spécifié, le système utilise les valeurs de la configuration principale de l'Agent. Par défaut, l'Agent principal définit le site sur `datadoghq.com` (US1). + +##### Prometheus receiver {#prometheus-receiver} + +Le [Prometheus receiver][6] collecte des métriques de santé depuis l'OpenTelemetry Collector pour le pipeline de métriques. + +{{< code-block lang="yaml" filename="otel-config.yaml" disable_copy="false" collapsible="true" >}} +receivers: + prometheus: + config: + scrape_configs: + - job_name: "otelcol" + scrape_interval: 60s + static_configs: + - targets: ["0.0.0.0:8888"] +{{< /code-block >}} + +Pour plus d'informations, consultez la documentation sur les [Métriques de santé de Collector][11]. + +## Envoyez votre télémétrie vers Datadog {#send-your-telemetry-to-datadog} + +Pour envoyer vos données de télémétrie vers Datadog : + +1. [Instrumentez votre application](#instrument-the-application) +2. [Configurez l'application](#configure-the-application) +3. [Corrélez les données d'observabilité](#correlate-observability-data) +4. [Exécutez votre application](#run-the-application) + +### Instrumentez l'application {#instrument-the-application} + +Instrumentez votre application [en utilisant l'API OpenTelemetry][7]. + +{{% collapse-content title="Exemple d'application instrumentée avec l'API OpenTelemetry" level="p" %}} +À titre d'exemple, vous pouvez utiliser l'[exemple d'application Calendrier][8] qui est déjà instrumenté pour vous. Le code suivant instrumente la méthode [CalendarService.getDate()][9] en utilisant les annotations et l'API OpenTelemetry : + {{< code-block lang="java" filename="CalendarService.java" disable_copy="true" collapsible="false" >}} +@WithSpan(kind = SpanKind.CLIENT) +public String getDate() { + Span span = Span.current(); + span.setAttribute("peer.service", "random-date-service"); + ... +} +{{< /code-block >}} +{{% /collapse-content %}} + +### Configurez l'application {#configure-the-application} + +Votre application doit envoyer des données au DDOT Collector sur le même host. Assurez-vous que la variable d'environnement `OTEL_EXPORTER_OTLP_ENDPOINT` est définie sur votre application. + +Si vous utilisez l'application exemple, [`run-otel-local.sh`][13] configure les variables d'environnement requises et exécute l'application : +{{< code-block lang="bash" filename="run-otel-local.sh" disable_copy="true" collapsible="true" >}} +export OTEL_METRICS_EXPORTER="otlp" +export OTEL_LOGS_EXPORTER="otlp" +export OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:4317" +export OTEL_EXPORTER_OTLP_PROTOCOL="grpc" +{{< /code-block >}} + +**Remarque** : vous pouvez exécuter ce script dans Git Bash, qui est inclus avec Git pour Windows. +### Corréler les données d'observabilité {#correlate-observability-data} + +[Unified service tagging][10] relie les données d'observabilité dans Datadog afin que vous puissiez naviguer entre les métriques, les traces et les logs avec des tags cohérents. + +Dans les environnements bare-metal, `env`, `service` et `version` sont définis via les variables d'environnement des attributs de ressource OpenTelemetry. Le DDOT Collector détecte cette configuration de marquage et l'applique aux données qu'il collecte depuis les applications. + +Dans l'application exemple, cela est effectué dans `run-otel-local.sh` : +{{< code-block lang="bash" filename="run-otel-local.sh" disable_copy="true" collapsible="true" >}} +export OTEL_RESOURCE_ATTRIBUTES="service.name=my-calendar-service,service.version=1.0,deployment.environment.name=otel-test,host.name=calendar-host" +{{< /code-block >}} + +### Exécutez l'application {#run-the-application} + +Redéployez votre application pour appliquer les modifications apportées à vos variables d'environnement. Une fois la configuration mise à jour active, unified service tagging est entièrement activé pour vos métriques, traces et logs. + +## Explorer les données d'observabilité dans Datadog {#explore-observability-data-in-datadog} + +Utilisez Datadog pour explorer les données d'observabilité de votre application. + +### Automatisation du parc {#fleet-automation} + +Explorez vos configurations du Datadog Agent, du DDOT Collector et de l'OpenTelemetry Collector en amont. + +{{< img src="/opentelemetry/embedded_collector/fleet_automation.png" alt="Examinez la configuration de votre Agent et du Collector depuis la page Fleet Automation." style="width:100%;" >}} + +### Surveillance de l'infrastructure {#infrastructure-monitoring} + +Affichez les métriques d'exécution et d'infrastructure pour visualiser, surveiller et mesurer les performances de vos hosts. + +{{< img src="/opentelemetry/embedded_collector/infrastructure.png" alt="Affichez les métriques d'exécution et d'infrastructure depuis la liste des hosts." style="width:100%;" >}} + +### Logs {#logs} + +Consultez les logs pour surveiller et diagnostiquer les opérations de l'application et du système. + +{{< img src="/opentelemetry/embedded_collector/logs.png" alt="Affichez les logs depuis le Log Explorer." style="width:100%;" >}} + +### Traces {#traces} + +Affichez les traces et les spans pour observer le statut et les performances des requêtes traitées par votre application, avec des métriques d'infrastructure corrélées dans la même trace. + +{{< img src="/opentelemetry/embedded_collector/traces.png" alt="Affichez les traces depuis le Trace Explorer." style="width:100%;" >}} + +### Métriques d'exécution {#runtime-metrics} + +Surveillez les métriques d'exécution (JVM) de vos applications. + +{{< img src="/opentelemetry/embedded_collector/metrics.png" alt="Affichez les métriques JVM depuis le dashboard des métriques JVM." style="width:100%;" >}} + +### Métriques de santé du Collector {#collector-health-metrics} + +Affichez les métriques du DDOT Collector pour surveiller la santé du Collector. + +{{< img src="/opentelemetry/embedded_collector/dashboard.png" alt="Affichez les métriques de santé du Collector depuis le dashboard OTel." style="width:100%;" >}} + +## Pour aller plus loin {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://www.datadoghq.com/free-datadog-trial/ +[2]: https://app.datadoghq.com/organization-settings/api-keys/ +[3]: /fr/agent/configuration/agent-commands/#agent-status-and-information +[4]: https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/connector/datadogconnector +[5]: https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/datadogexporter +[6]: https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/prometheusreceiver +[7]: /fr/opentelemetry/instrument/api_support +[8]: https://github.com/DataDog/opentelemetry-examples/tree/main/apps/rest-services/java/calendar +[9]: https://github.com/DataDog/opentelemetry-examples/blob/main/apps/rest-services/java/calendar/src/main/java/com/otel/service/CalendarService.java#L27-L48 +[10]: /fr/opentelemetry/correlate/ +[11]: /fr/opentelemetry/integrations/collector_health_metrics/ +[12]: https://github.com/DataDog/datadog-agent/blob/main/pkg/config/example/datadog-agent_windows.yaml.example +[13]: https://github.com/DataDog/opentelemetry-examples/blob/main/apps/rest-services/java/calendar/run-otel-local.sh +[14]: /fr/agent/supported_platforms/windows/ \ No newline at end of file diff --git a/hugo/content/fr/product_analytics/charts/journey_paths.md b/hugo/content/fr/product_analytics/charts/journey_paths.md new file mode 100644 index 00000000000..fda968a90c1 --- /dev/null +++ b/hugo/content/fr/product_analytics/charts/journey_paths.md @@ -0,0 +1,48 @@ +--- +description: Visualisez les chemins les plus courants empruntés par les utilisateurs + entre deux événements, y compris les chemins des sessions qui ont été abandonnées + avant d'atteindre le second événement. +title: Parcours utilisateur +--- +Les parcours utilisateur montrent les chemins les plus courants empruntés par les utilisateurs entre des événements sélectionnés. + +Utilisez les parcours utilisateur pour : +- Voir comment les utilisateurs naviguent dans les parcours clés et effectuent des flux de travail. +- Comprendre si les utilisateurs se convertissent efficacement ou s'ils font des détours inattendus. +- Examinez où et pourquoi les utilisateurs abandonnent. + +{{< img src="product_analytics/journeys/journey_paths/pana_journey_paths_conversion_chart.png" alt="Un graphique de parcours utilisateur rendu montrant les principaux chemins empruntés par les utilisateurs entre deux vues." style="width:100%;" >}} + +## Créer un graphique de parcours utilisateur {#create-a-journey-paths-chart} + +1. Dans {{< ui >}}Product Analytics{{< /ui >}}, sélectionnez {{< ui >}}Create New{{< /ui >}} > {{< ui >}}Journey Paths{{< /ui >}}. + +2. Définissez {{< ui >}}User steps{{< /ui >}} en sélectionnant au moins deux événements entre lesquels vous souhaitez analyser les chemins. + + Pour une étape donnée, cliquez sur {{< ui >}}or...{{< /ui >}} pour spécifier plusieurs événements, ou cliquez sur l'icône de filtre pour filtrer l'étape selon des propriétés spécifiées. + +3. (Facultatif) Filtrez les résultats du graphique en fonction de propriétés telles que le pays ou le type d'appareil à l'aide des critères {{< ui >}}Filter by{{< /ui >}}. + +## Analyser un graphique de parcours utilisateur {#analyze-a-journey-paths-chart} + +Une fois que vous avez défini les étapes d'un parcours utilisateur, le graphique affiche les chemins les plus courants empruntés par les utilisateurs entre celles-ci. + +Chaque chemin indique le pourcentage et le nombre de sessions ayant suivi ce chemin, ainsi que le temps moyen passé sur celui-ci. Les chemins sans événements listés représentent les sessions qui sont passées directement de l'événement de début à l'événement de fin, sans vues ou actions intermédiaires. + +{{< img src="product_analytics/journeys/journey_paths/pana_journey_paths_customization.png" alt="Un graphique de parcours utilisateur avec des légendes numérotées pour le sélecteur de conversion/abandon, le sélecteur d'étape, la plage de dates, les bascules de type d'événement, View more, le menu des options de chemin et les commandes More Paths/Fewer Paths." style="width:100%;" >}} + +Vous pouvez affiner les graphiques de parcours utilisateur de différentes manières pour vous concentrer sur les chemins que vous souhaitez analyser. + +1. Utilisez le sélecteur {{< ui >}}Converted{{< /ui >}} / {{< ui >}}Dropped{{< /ui >}} pour basculer entre les chemins qui ont atteint l'étape finale et ceux qui ont été abandonnés. Les chemins d'abandon n'ont pas de nœud de fin. + +2. Dans les parcours comportant plusieurs étapes, utilisez le sélecteur d'étape pour choisir la paire d'étapes entre lesquelles analyser les chemins. + +3. Utilisez le sélecteur de plage temporelle pour modifier la période de données analysée par le graphique. + +4. Utilisez les commutateurs {{< ui >}}Views{{< /ui >}} et {{< ui >}}Actions{{< /ui >}} pour contrôler quels types d'événements apparaissent en tant que nœuds de chemin. Les vues, les actions et les actions personnalisées s'affichent chacune avec une couleur et une icône distinctes dans le diagramme, afin que vous puissiez identifier le type d'événement à chaque étape d'un chemin. + +5. Pour les chemins tronqués, cliquez sur {{< ui >}}View more{{< /ui >}} pour révéler les événements suivants dans ce chemin. Cliquez sur {{< ui >}}View less{{< /ui >}} pour le réduire à nouveau. + +6. Cliquez sur un événement pour ouvrir un menu proposant des options pour afficher les session replays ou les utilisateurs associés à ce chemin. Ou maintenez **Option** (macOS) ou **Alt** (Windows/Linux) enfoncée et cliquez sur un événement pour le masquer du diagramme. + +7. Utilisez {{< ui >}}More Paths{{< /ui >}} et {{< ui >}}Fewer Paths{{< /ui >}} pour contrôler le nombre de chemins affichés. \ No newline at end of file diff --git a/hugo/content/fr/security/application_security/setup/macos/_index.md b/hugo/content/fr/security/application_security/setup/macos/_index.md new file mode 100644 index 00000000000..b80081cf044 --- /dev/null +++ b/hugo/content/fr/security/application_security/setup/macos/_index.md @@ -0,0 +1,46 @@ +--- +disable_sidebar: true +further_reading: +- link: /security/application_security/ + tag: Documentation + text: Protégez contre les menaces avec Datadog App and API Protection +- link: /security/application_security/add-user-info/ + tag: Documentation + text: Suivi de l'activité des utilisateurs +- link: /security/default_rules/?category=cat-application-security + tag: Documentation + text: Règles App and API Protection prêtes à l'emploi +- link: /security/application_security/troubleshooting + tag: Documentation + text: Dépannage d'App and API Protection +- link: /security/application_security/how-it-works/ + tag: Documentation + text: Fonctionnement d'App and API Protection dans Datadog +title: Configurer App and API Protection sur macOS +--- +{{< site-region region="gov" >}} +
+App and API Protection est en préversion sur le site Datadog Government US1-FED. +
+{{< /site-region >}} + +Apprenez à configurer App and API Protection (AAP) sur vos services macOS en sélectionnant le langage de programmation du service. + +
+

Votre environnement est-il manquant ?

+ Envoyez-nous une demande pour votre environnement manquant ici. +
+ +{{< appsec-integrations >}} + {{< appsec-integration name="Python" avatar="python" link="/security/application_security/setup/python/macos" >}} + {{< appsec-integration name="Node.js" avatar="node" link="/security/application_security/setup/nodejs/macos" >}} + {{< appsec-integration name="Java" avatar="java" link="/security/application_security/setup/java/macos" >}} + {{< appsec-integration name="Go" avatar="go" link="/security/application_security/setup/go/" >}} + {{< appsec-integration name="Ruby" avatar="ruby" link="/security/application_security/setup/ruby/macos" >}} + {{< appsec-integration name=".NET" avatar="dotnet" link="/security/application_security/setup/dotnet" >}} + {{< appsec-integration name="PHP" avatar="php" link="/security/application_security/setup/php" >}} +{{< /appsec-integrations >}} + +## Pour aller plus loin {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} \ No newline at end of file diff --git a/hugo/content/fr/security/workload_protection/setup/windows.md b/hugo/content/fr/security/workload_protection/setup/windows.md new file mode 100644 index 00000000000..da551169b15 --- /dev/null +++ b/hugo/content/fr/security/workload_protection/setup/windows.md @@ -0,0 +1,10 @@ +--- +aliases: +- /fr/security/workload_protection/setup/agent/windows +description: Activez Workload Protection sur les hôtes Windows avec le Datadog Agent. +disable_toc: false +title: Mise en place de Workload Protection sur Windows. +--- +{{% wp-windows-setup %}} + +{{< partial name="security-platform/WP-billing-note.html" >}} \ No newline at end of file diff --git a/hugo/content/fr/serverless/aws_lambda/_index.md b/hugo/content/fr/serverless/aws_lambda/_index.md index b8c8bb2f193..175f543e8c5 100644 --- a/hugo/content/fr/serverless/aws_lambda/_index.md +++ b/hugo/content/fr/serverless/aws_lambda/_index.md @@ -1,97 +1,116 @@ --- +aliases: +- /fr/serverless/aws further_reading: - link: /serverless/configuration/ tag: Documentation - text: Configurer la surveillance sans serveur + text: Configurer la surveillance serverless - link: /integrations/amazon_lambda/ tag: Documentation text: Intégration AWS Lambda +- link: /serverless/guide/disable_serverless + tag: Documentation + text: Désactiver Serverless Monitoring +- link: /opentelemetry/setup/otlp_ingest/serverless/?tab=aws#lambda + tag: Documentation + text: Envoyer des traces AWS Lambda à Datadog avec OTLP - link: https://www.datadoghq.com/blog/monitoring-lambda-containers/ tag: Blog - text: Surveiller des fonctions Lambda Datadog AWS déployées à l'aide d'images de - conteneur + text: Surveiller des fonctions AWS Lambda déployées à l'aide d'images de conteneur - link: https://www.datadoghq.com/blog/manage-serverless-logs-datadog/ tag: Blog text: Meilleures pratiques pour la collecte et la gestion des logs depuis un environnement - sans serveur + serverless - link: https://www.datadoghq.com/blog/aws-serverless-application-design/ tag: Blog - text: Concevoir des applications sans serveur AWS prêtes pour la production + text: Concevoir des applications serverless AWS prêtes pour la production - link: https://www.datadoghq.com/blog/well-architected-serverless-applications-best-practices/ tag: Blog - text: Conseils pour créer des applications sans serveur tout en suivant le framework + text: Conseils pour créer des applications serverless tout en suivant le framework AWS Well-Architected - link: https://www.datadoghq.com/blog/aws-lambda-functions-ephemeral-storage-monitoring/ tag: Blog text: Surveiller l'utilisation du stockage éphémère de vos fonctions AWS Lambda - link: https://www.datadoghq.com/blog/serverless-cold-start-traces/ tag: Blog - text: Comprendre les performances des fonctions sans serveur avec le tracing des - démarrages à froid -title: Surveillance sans serveur pour AWS Lambda + text: Comprendre les performances des fonctions serverless avec le tracing des démarrages + à froid +- link: https://www.datadoghq.com/blog/identifying-deprecated-lambda-functions/ + tag: Blog + text: Identifier les fonctions Lambda obsolètes avec Datadog +- link: https://www.datadoghq.com/blog/monitoring-lwa-with-datadog/ + tag: Blog + text: Surveiller les applications Web hébergées sur Lambda avec l'intégration Lambda + Web Adapter +- link: https://www.datadoghq.com/blog/lambda-managed-instances + tag: Blog + text: Surveiller les instances gérées AWS Lambda avec Datadog +- link: https://learn.datadoghq.com/courses/visibility-aws-lambda + tag: Centre d'apprentissage + text: Configurer AWS Lambda pour Serverless Monitoring avec Datadog +title: Serverless Monitoring pour AWS Lambda --- +Datadog Serverless Monitoring pour AWS Lambda vous offre une visibilité optimale sur vos fonctions Lambda. -La surveillance de serveur Datadog pour AWS Lambda vous offre une visibilité optimale sur vos fonctions Lambda. - -Pour commencer, suivez les [instructions d'installation][1] pour recueillir des métriques, traces et logs à partir de vos applications sans serveur. +Pour commencer, suivez les [instructions d'installation][1] afin de collecter des métriques, des traces et des logs depuis vos applications serverless. -## Fonctionnement +## Fonctionnement {#how-it-works} -{{< img src="serverless/serverless_custom_metrics.png" alt="Collecte de métriques optimisées depuis AWS Lambda" >}} +{{< img src="serverless/serverless_custom_metrics.png" alt="Collecte de métriques améliorées depuis AWS Lambda" >}} -La surveillance sans serveur Datadog tire profit d'une bibliothèque Lambda Datadog spécifique au runtime, ainsi que de l'extension Lambda Datadog, pour envoyer des données de télémétrie à partir de vos fonctions Lambda. +Datadog Serverless Monitoring tire profit d'une bibliothèque Lambda Datadog spécifique au runtime, ainsi que de l'extension Lambda Datadog, pour envoyer des données de télémétrie à partir de vos fonctions Lambda. -L'extension Lambda Datadog recueille des logs via CloudWatch, ainsi que des traces, des métriques optimisées et des métriques custom à partir de la bibliothèque Lambda Datadog. +La Datadog Lambda Extension collecte les logs de fonction à l'aide de l'API de télémétrie Lambda, éliminant ainsi le besoin de CloudWatch. Elle génère également des métriques améliorées. Elle unifie ces signaux de télémétrie avec les traces APM, les spans personnalisés et les métriques personnalisées de la bibliothèque Datadog Lambda. -## Utilisation +## Utilisation {#usage} -Consultez les ressources suivantes pour découvrir comment installer et configurer la surveillance sans serveur pour AWS Lambda, et notamment comment utiliser les métriques, traces et logs pour bénéficier d'une visibilité complète. +Consultez les ressources suivantes pour découvrir comment installer et configurer Serverless Monitoring pour AWS Lambda, et notamment comment utiliser les métriques, traces et logs pour bénéficier d'une visibilité complète. {{< whatsnext desc=" ">}} - {{< nextlink href="/serverless/installation" >}}Installation : installez la surveillance sans serveur pour AWS Lambda.{{< /nextlink >}} - {{< nextlink href="/serverless/enhanced_lambda_metrics" >}}Métriques Lambda : familiarisez-vous avec les métriques optimisées et découvrez comment envoyer des métriques custom.{{< /nextlink >}} - {{< nextlink href="/serverless/distributed_tracing" >}}Tracing distribué : tirez profit d'APM et du tracing distribué pour bénéficier d'une vue d'ensemble détaillée et contextualisée des performances de votre application. {{< /nextlink >}} + {{< nextlink href="/serverless/installation" >}}Installation : Installez Serverless Monitoring for AWS Lambda.{{< /nextlink >}} + {{< nextlink href="/serverless/enhanced_lambda_metrics" >}}Métriques Lambda : Apprenez-en davantage sur les métriques améliorées et découvrez comment soumettre des métriques personnalisées.{{< /nextlink >}} + {{< nextlink href="/serverless/distributed_tracing" >}}Distributed Tracing : Utilisez APM et Distributed Tracing pour obtenir une vue riche en contexte des performances de votre application.{{< /nextlink >}} {{< nextlink href="/serverless/aws_lambda/logs" >}} - Collecte de logs : découvrez le fonctionnement de la collecte de logs, apprenez à filtrer des logs et associez vos logs à vos traces.{{< /nextlink >}} + Log Collection: Read more about log collection, how to filter logs, and how to connect logs and traces.{{< /nextlink >}} {{< /whatsnext >}} -### Surveiller toute votre pile sans serveur avec la vue Serverless +### Surveillez l'intégralité de votre stack serverless dans la vue Serverless {#monitor-your-entire-serverless-stack-in-the-serverless-view} Grâce à la vue Serverless, vous pouvez mettre en corrélation des métriques générales provenant de ressources AWS avec les métriques de fonctions Lambda, afin d'identifier rapidement vos problèmes et de commencer au plus tôt votre enquête. -Par défaut, la vue Serverless regroupe vos ressources sans serveur par service, afin que vous puissiez visualiser facilement les performances de chaque aspect de votre application. Chaque service répertorie les fonctions associées, ainsi que les ressources qui ont appelé ces fonctions (Amazon API Gateway, SNS, SQS, DynamoDB, S3, EventBridge, Kinesis). +Par défaut, la vue Serverless regroupe vos ressources serverless par service pour vous aider à visualiser les performances de chaque partie de votre application. Pour chaque service, vous pouvez voir les fonctions qui lui appartiennent, ainsi que les ressources (Amazon API Gateway, SNS, SQS, DynamoDB, S3, EventBridge, Kinesis) qui les ont invoquées. -{{< img src="serverless/serverless-view-hero.jpeg" alt="Surveillance sans serveur Datadog" style="width:100%;" >}} +{{< img src="serverless/serverless-view-hero.jpeg" alt="Datadog Serverless Monitoring" style="width:100%;" >}} -### Corriger plus rapidement les échecs des fonctions AWS Lambda en surveillant les charges utiles d'invocations +### Résolvez plus rapidement les échecs des fonctions AWS Lambda en surveillant les charges utiles d'invocation {#resolve-aws-lambda-function-failures-faster-by-monitoring-invocation-payloads} -Datadog recueille automatiquement les requêtes et réponses de tous vos appels de fonction. Vous disposez ainsi de précieux insights qui simplifient la résolution de problèmes. Par exemple, si vous découvrez qu'une de vos fonctions Lambda génère des échecs, vous pouvez analyser la charge utile des requêtes pour vérifier s'il manque des paramètres, si des adresses de ressource ont mal été saisies ou si ces échecs sont causés par d'autres problèmes de configuration. +Datadog collecte automatiquement les requêtes et les réponses de fonction pour toutes vos invocations de fonction, fournissant des informations clés qui peuvent aider à résoudre les problèmes. Par exemple, si vous êtes informé qu'une de vos fonctions Lambda rencontre des échecs, vous pouvez analyser les charges utiles de requête pertinentes pour vérifier l'absence de paramètres, les adresses de ressources mal saisies ou d'autres erreurs de configuration pouvant être à l'origine des échecs. Grâce à l'identification de ces erreurs, vous pouvez reproduire plus facilement les problèmes dans votre environnement de développement, puis exécuter des tests pour vous assurer que vos correctifs fonctionnent. -{{< img src="serverless/lambda_payload_hero.jpeg" alt="Surveillance sans serveur Datadog" style="width:100%;" >}} +{{< img src="serverless/lambda_payload_hero.jpeg" alt="Datadog Serverless Monitoring" style="width:100%;" >}} -### Envoyer des alertes liées à votre environnement de fonctions Lambda grâce aux métriques en temps réel +### Métriques en temps réel pour alerter sur les problèmes dans votre environnement de fonctions Lambda {#real-time-metrics-for-alerting-on-issues-across-your-lambda-function-environment} -Les métriques Lambda optimisées de Datadog, qui sont identifiées dans Datadog par le préfixe `aws.lambda.enhanced`, sont fournies quasiment en temps réel avec une granularité d'une seconde. Elles vous permettent de générer des alertes ou d'appliquer des SLO basés sur les démarrages à froid, les coûts AWS estimés, les expirations, les erreurs liées à une mémoire insuffisante et l'utilisation de la mémoire pour l'ensemble de vos fonctions Lambda. Vous pouvez ainsi visualiser en temps réel les problèmes de performance de vos environnements sans serveur et les diagnostiquer au plus vite. +Les métriques Lambda améliorées de Datadog, qui apparaissent dans Datadog avec le préfixe `aws.lambda.enhanced`, sont disponibles avec une granularité à la seconde et en temps quasi réel. Vous pouvez utiliser les métriques Lambda améliorées pour des alertes ou des SLO sur les démarrages à froid, les coûts AWS estimés, les délais d'attente, les erreurs de mémoire insuffisante et l'utilisation de la mémoire sur l'ensemble de vos fonctions Lambda. Cela vous permet de visualiser les problèmes de performance dans vos environnements serverless dès qu'ils surviennent et de les résoudre sans délai. -{{< img src="serverless/serverless_enhanced_metrics.jpeg" alt="Surveillance sans serveur Datadog" style="width:100%;" >}} +{{< img src="serverless/serverless_enhanced_metrics.jpeg" alt="Datadog Serverless Monitoring" style="width:100%;" >}} -### Surveiller les changements de configuration sans serveur grâce au suivi des déploiements +### Surveillez les changements de configuration serverless avec le suivi des déploiements {#monitor-serverless-configuration-changes-with-deployment-tracking} -Vous pouvez facilement mettre en corrélation les métriques, traces et logs de vos fonctions avec le code sans serveur, les configurations et les changements de déploiement. Cela vous permet d'obtenir en temps réel des informations pertinentes sur l'incidence de ces changements sur l'intégrité et les performances de vos applications. +Vous pouvez facilement mettre en corrélation les métriques, traces et logs de vos fonctions avec le code serverless, les configurations et les changements de déploiement. Cela vous permet d'obtenir en temps réel des informations pertinentes sur l'incidence de ces changements sur l'intégrité et les performances de vos applications. -{{< img src="serverless/serverless_deployment_tracking.jpeg" alt="Surveillance sans serveur Datadog" style="width:100%;" >}} +{{< img src="serverless/serverless_deployment_tracking.jpeg" alt="Datadog Serverless Monitoring" style="width:100%;" >}} -## Fonctionnalités supplémentaires +## Fonctionnalités supplémentaires {#additional-capabilities} {{< whatsnext desc=" ">}} - {{< nextlink href="/serverless/aws_lambda/profiling" >}}Profileur en continu : activez le profileur continu Datadog pour identifier la ligne de code précise de votre fonction Lambda qui génère des goulots d'étranglement.{{< /nextlink >}} - {{< nextlink href="/serverless/aws_lambda/securing_functions" >}}Sécurisation de vos fonctions : tirez profit de la solution Application Security Management (ASM) pour gérer les menaces envers vos fonctions.{{< /nextlink >}} - {{< nextlink href="/serverless/deployment_tracking" >}}Suivi des déploiements : surveillez vos déploiements afin de détecter lorsqu'une nouvelle version du code ou un changement de configuration entraîne une régression.{{< /nextlink >}} + {{< nextlink href="/serverless/aws_lambda/profiling" >}}Continuous Profiler : activez le Continuous Profiler de Datadog pour trouver la ligne de code exacte de votre fonction Lambda à l'origine des goulots d'étranglement.{{< /nextlink >}} + {{< nextlink href="/serverless/aws_lambda/securing_functions" >}}Secure Functions : utilisez App and API Protection (AAP) pour gérer les menaces pesant sur vos fonctions.{{< /nextlink >}} + {{< nextlink href="/serverless/deployment_tracking" >}}Deployment Tracking : suivez les déploiements pour voir quand une nouvelle version de code ou un changement de configuration provoque une régression.{{< /nextlink >}} {{< /whatsnext >}} -## Pour aller plus loin +## Lectures complémentaires {#further-reading} {{< partial name="whats-next/whats-next.html" >}} diff --git a/hugo/content/fr/tests/guides/validate_optimizations/_index.md b/hugo/content/fr/tests/guides/validate_optimizations/_index.md new file mode 100644 index 00000000000..fd7465f60e1 --- /dev/null +++ b/hugo/content/fr/tests/guides/validate_optimizations/_index.md @@ -0,0 +1,576 @@ +--- +description: Validez que les fonctionnalités Test Optimization — incluant Early Flake + Detection, Auto Test Retries et Flaky Test Management — fonctionnent correctement + dans votre dépôt. +further_reading: +- link: /tests/guides/setup_new_flaky_pr_gate + tag: Documentation + text: Configurez un New Flaky Test PR Gate. +- link: /tests/flaky_tests/early_flake_detection + tag: Documentation + text: En savoir plus sur Early Flake Detection. +- link: /tests/flaky_tests/auto_test_retries + tag: Documentation + text: En savoir plus sur Auto Test Retries. +- link: /tests/flaky_management + tag: Documentation + text: En savoir plus sur la Gestion des tests irréguliers +title: Validez les optimisations. +--- +Cette page explique comment vérifier que les optimisations offertes par Test Optimization fonctionnent comme prévu. Le guide suppose que [Test Optimization][12] fonctionne déjà pour le dépôt en cours de validation, et il présente les étapes pour valider les optimisations pour un **dépôt unique**. + +
Exécutez ces validations uniquement dans une branche de fonctionnalité et ne les fusionnez pas dans votre branche par défaut ou principale.
+ +## Prérequis {#prerequisites} + +Ces optimisations nécessitent une [bibliothèque native prise en charge][12]. Les téléchargements de fichiers XML JUnit ne sont pas pris en charge. + +## Option 1 : Valider localement avec un agent de codage {#option-1-validate-locally-with-a-coding-agent} + +{{< callout url="#" btn_hidden="true" header="Rejoignez la Preview !" >}} + La validation par agent de codage local est en préversion et ne prend en charge que les projets JavaScript et TypeScript qui utilisent le package npm [`dd-trace`][15]. + + [15]: https://www.npmjs.com/package/dd-trace +{{< /callout >}} + +À l'aide de l'invite fournie ci-dessous, demandez à un agent de codage local (un assistant IA capable d'inspecter et d'exécuter des commandes dans votre dépôt local) d'inspecter le package `dd-trace` installé et d'exécuter son runbook de validation Test Optimization. Cette méthode vérifie la compatibilité de la bibliothèque locale et la configuration CI. Elle vérifie également Early Flake Detection, Auto Test Retries et Flaky Test Management sans modifier les paramètres Datadog ni envoyer de résultats de validation à Datadog. + +Le runbook se trouve à `ci/runbook.md` par rapport à la racine du package `dd-trace` installé. + +Transmettez cette invite à votre agent de codage local : + +```text +Locate the installed dd-trace package, then read and execute its ci/runbook.md. +``` + +Cette méthode d'agent de codage est un check local qui n'exerce pas l'intégralité du workflow Datadog. Pour valider les workflows complets de [prévention](#step-2-prevention), d'[atténuation](#step-3-mitigation) et de [remédiation](#step-4-remediation), ou pour valider un langage autre que JavaScript ou TypeScript, utilisez l'[Option 2, ci-dessous](#option-2-validate-the-full-workflow). + +## Option 2 : Valider le workflow complet {#option-2-validate-the-full-workflow} + +Ce workflow de validation vérifie le workflow Test Optimization complet dans Datadog. Effectuez ces validations ([Prévention](#step-2-prevention), [Atténuation](#step-3-mitigation) et [Remédiation](#step-4-remediation)) dans l'ordre, car elles utilisent la même branche et le même test. + +### Étape 1 : Configurer la validation {#step-1-set-up-validation} + +Ce guide vous accompagne dans la réalisation de modifications locales et leur validation pour l'exécution de la CI. Il utilise un service de test et une branche dédiés afin de minimiser l'impact du workflow de validation sur les autres développeurs du dépôt. + +1. Configurez votre job de test CI pour définir `DD_SERVICE` avant l'exécution de la commande de test : + + ```bash + export DD_SERVICE=validate-test-optimization + ``` + +2. Créez la branche de validation : + + ```bash + git checkout -b validate-test-optimization + ``` + +3. Validez la modification de configuration CI qui définit `DD_SERVICE`, puis poussez la branche de validation pour déclencher une exécution de test : + + ```bash + git add -A + git commit -m "Configure Test Optimization validation service" + git push -u origin validate-test-optimization + ``` + + Datadog détecte le service `validate-test-optimization` lorsque les tests sont signalés sous ce nom. + +4. Une fois l'intégration continue terminée, accédez aux [paramètres des dépôts CI/CD][3] et sélectionnez le dépôt que vous validez. + + {{< img src="pr_gates/setup/ci_cd_repositories_settings.png" alt="Paramètres des dépôts CI/CD filtrés sur le dépôt en cours de validation" style="width:100%" >}} + +5. Dans le coin supérieur droit du panneau coulissant, cliquez sur {{< ui >}}Test Service{{< /ui >}}. + + {{< img src="pr_gates/setup/repository_settings_test_services.png" alt="Paramètres du dépôt avec le bouton Test Service dans le coin supérieur droit." style="width:100%" >}} + +6. Dans {{< ui >}}Test service overrides{{< /ui >}}, sélectionnez le service `validate-test-optimization`. + + {{< img src="pr_gates/setup/test_service_overrides.png" alt="Remplacements du Test Service affichant les services de test détectés pour un dépôt." style="width:100%" >}} + +7. Configurez les remplacements de service suivants : + - Activez [Early Flake Detection][1]. + - Activez [Auto Test Retries][4]. + - Désactivez [Test Impact Analysis][13] (afin qu'il ne passe pas à côté du test de validation). +8. Retournez aux paramètres du dépôt. Les [Flaky Test Policies][6] s'appliquent à chaque service de test du dépôt, et non à un service de test individuel. Pour limiter l'impact de la politique de validation, configurez-la uniquement pour la branche `validate-test-optimization`. Sous {{< ui >}}Flaky Test Policies{{< /ui >}}, sur la tuile {{< ui >}}Quarantine{{< /ui >}}, cliquez sur {{< ui >}}Configure{{< /ui >}}. + + {{< img src="pr_gates/setup/flaky_test_policies_quarantine.png" alt="Paramètres du dépôt affichant le bouton Configurer pour la politique Quarantine flaky test." style="width:100%" >}} + +9. Activez la deuxième règle automatique : **Si un Active flaky test échoue dans la branche `validate-test-optimization`, alors déplacez-le vers Quarantined**. + + {{< img src="pr_gates/setup/quarantine_branch_policy.png" alt="Politique Quarantine configurée pour les Active flaky tests sur la branche validate-test-optimization." style="width:100%" >}} + +10. Cliquez sur {{< ui >}}Save{{< /ui >}}. +11. Créez un [New Flaky Test PR Gate][11] et limitez-le au dépôt que vous validez. + + {{< img src="pr_gates/setup/pr_gate_scope.png" alt="Périmètre du New Flaky Test PR Gate." style="width:100%" >}} + +### Étape 2 : Prevention {#step-2-prevention} + +[Early Flake Detection][1] détecte les nouveaux tests instables. [New Flaky Test PR Gates][2] les empêchent d'atteindre votre branche par défaut. + +1. Ajoutez un test qui échoue à la première tentative et réussit lors des nouvelles tentatives (en utilisant éventuellement le code fourni ci-dessous). Le nom du test doit contenir à la fois `flaky` et `validation` afin que vous puissiez l'identifier dans Datadog. + + {{< tabs >}} + {{% tab "JavaScript" %}} + + ```javascript + const fs = require('node:fs'); + const os = require('node:os'); + const path = require('node:path'); + + test('flaky validation test', () => { + const marker = path.join(os.tmpdir(), 'dd-validation-flaky'); + if (!fs.existsSync(marker)) { + fs.writeFileSync(marker, '1'); + throw new Error('first attempt fails so Datadog can retry it'); + } + }); + ``` + + {{% /tab %}} + {{% tab "Python" %}} + + ```python + from pathlib import Path + from tempfile import gettempdir + + + def test_flaky_validation_test(): + marker = Path(gettempdir()) / "dd-validation-flaky" + if not marker.exists(): + marker.write_text("1") + raise AssertionError("first attempt fails so Datadog can retry it") + ``` + + {{% /tab %}} + {{% tab "Java" %}} + + ```java + import static org.junit.jupiter.api.Assertions.fail; + + import java.io.IOException; + import java.nio.file.Files; + import java.nio.file.Path; + import java.nio.file.Paths; + import org.junit.jupiter.api.Test; + + class ValidationFlakyTest { + @Test + void flakyValidationTest() throws IOException { + Path marker = Paths.get( + System.getProperty("java.io.tmpdir"), + "dd-validation-flaky" + ); + if (Files.notExists(marker)) { + Files.write(marker, new byte[] { '1' }); + fail("first attempt fails so Datadog can retry it"); + } + } + } + ``` + + {{% /tab %}} + {{% tab "Ruby" %}} + + ```ruby + require 'tmpdir' + + RSpec.describe 'validation flaky tests' do + it 'flaky validation test' do + marker = File.join(Dir.tmpdir, 'dd-validation-flaky') + unless File.exist?(marker) + File.write(marker, '1') + raise 'first attempt fails so Datadog can retry it' + end + end + end + ``` + + {{% /tab %}} + {{% tab ".NET" %}} + + ```csharp + using System.IO; + using Xunit; + + public class ValidationFlakyTests + { + [Fact] + public void FlakyValidationTest() + { + var marker = Path.Combine(Path.GetTempPath(), "dd-validation-flaky"); + if (!File.Exists(marker)) + { + File.WriteAllText(marker, "1"); + throw new System.Exception("first attempt fails so Datadog can retry it"); + } + } + } + ``` + + {{% /tab %}} + {{% tab "Go" %}} + + ```go + package validation + + import ( + "errors" + "os" + "path/filepath" + "testing" + ) + + func TestFlakyValidationTest(t *testing.T) { + marker := filepath.Join(os.TempDir(), "dd-validation-flaky") + if _, err := os.Stat(marker); errors.Is(err, os.ErrNotExist) { + if writeErr := os.WriteFile(marker, []byte("1"), 0600); writeErr != nil { + t.Fatal(writeErr) + } + t.Fatal("first attempt fails so Datadog can retry it") + } + } + ``` + + {{% /tab %}} + {{% tab "Swift" %}} + + ```swift + import XCTest + + final class ValidationFlakyTests: XCTestCase { + func testFlakyValidationTest() throws { + let marker = FileManager.default.temporaryDirectory + .appendingPathComponent("dd-validation-flaky") + if !FileManager.default.fileExists(atPath: marker.path) { + try "1".write(to: marker, atomically: true, encoding: .utf8) + XCTFail("first attempt fails so Datadog can retry it") + } + } + } + ``` + + {{% /tab %}} + {{< /tabs >}} + +2. Commitez et poussez le test, puis ouvrez une pull request depuis la branche de validation : + + ```bash + git add -A + git commit -m "Validate Test Optimization prevention" + git push origin validate-test-optimization + ``` + +3. Attendez que la CI s'exécute. Early Flake Detection relance le nouveau test, et le New Flaky Test PR Gate évalue le résultat. Dans les checks GitHub de votre pull request, confirmez que le New Flaky Test PR Gate échoue : + + {{< img src="pr_gates/setup/failed_pr_gate.png" alt="Check de la pull request GitHub échouant car un nouveau test instable est détecté" style="width:100%" >}} + +4. Cliquez sur le check GitHub en échec et confirmez que le test est inclus dans la liste des nouveaux tests instables : + + {{< img src="pr_gates/setup/pr_gate_detail.png" alt="Vue détaillée de la porte de PR Datadog" style="width:100%" >}} + +5. Dans [Test Runs][7], confirmez qu'Early Flake Detection a relancé le test et l'a détecté comme un nouveau test instable en utilisant [cette requête][7], qui utilise les filtres suivants : + + - `@test.name:*flaky*validation*` + - `@git.branch:validate-test-optimization` + - `@test.retry_reason:early_flake_detection` + - `@test.test_management.is_new_flaky:true` + +### Étape 3 : Mitigation {#step-3-mitigation} + +La mitigation est obtenue grâce à [Auto Test Retries][4], [Flaky Test Management][5] et [Flaky Test Policies][6]. Ces fonctionnalités relancent les tests instables et mettent en quarantaine les échecs instables connus afin qu'ils ne bloquent pas l'intégration continue (CI). + +1. Dans le même test que celui ajouté pour la [Prévention](#step-2-prevention), remplacez le nom de fichier du marqueur `dd-validation-flaky` par `dd-validation-flaky-mitigation`. Ne renommez pas la fonction de test ou le cas de test. Le nouveau marqueur provoque un autre échec intentionnel lors de la première tentative. Le maintien du nom de test inchangé permet à Datadog d'associer l'exécution au test instable détecté lors de la [Prévention](#step-2-prevention). Aucune configuration Datadog supplémentaire n'est requise ; [Auto Test Retries] et [Flaky Test Management] prennent en charge le test lors de cette exécution. Mettez à jour le test pour votre langage : + + {{< tabs >}} + {{% tab "JavaScript" %}} + + ```javascript + const fs = require('node:fs'); + const os = require('node:os'); + const path = require('node:path'); + + test('flaky validation test', () => { + // Changed from dd-validation-flaky. + const marker = path.join(os.tmpdir(), 'dd-validation-flaky-mitigation'); + if (!fs.existsSync(marker)) { + fs.writeFileSync(marker, '1'); + throw new Error('first attempt fails so Datadog can retry it'); + } + }); + ``` + + {{% /tab %}} + {{% tab "Python" %}} + + ```python + from pathlib import Path + from tempfile import gettempdir + + + def test_flaky_validation_test(): + # Changed from dd-validation-flaky. + marker = Path(gettempdir()) / "dd-validation-flaky-mitigation" + if not marker.exists(): + marker.write_text("1") + raise AssertionError("first attempt fails so Datadog can retry it") + ``` + + {{% /tab %}} + {{% tab "Java" %}} + + ```java + import static org.junit.jupiter.api.Assertions.fail; + + import java.io.IOException; + import java.nio.file.Files; + import java.nio.file.Path; + import java.nio.file.Paths; + import org.junit.jupiter.api.Test; + + class ValidationFlakyTest { + @Test + void flakyValidationTest() throws IOException { + // Changed from dd-validation-flaky. + Path marker = Paths.get( + System.getProperty("java.io.tmpdir"), + "dd-validation-flaky-mitigation" + ); + if (Files.notExists(marker)) { + Files.write(marker, new byte[] { '1' }); + fail("first attempt fails so Datadog can retry it"); + } + } + } + ``` + + {{% /tab %}} + {{% tab "Ruby" %}} + + ```ruby + require 'tmpdir' + + RSpec.describe 'validation flaky tests' do + it 'flaky validation test' do + # Changed from dd-validation-flaky. + marker = File.join(Dir.tmpdir, 'dd-validation-flaky-mitigation') + unless File.exist?(marker) + File.write(marker, '1') + raise 'first attempt fails so Datadog can retry it' + end + end + end + ``` + + {{% /tab %}} + {{% tab ".NET" %}} + + ```csharp + using System.IO; + using Xunit; + + public class ValidationFlakyTests + { + [Fact] + public void FlakyValidationTest() + { + // Changed from dd-validation-flaky. + var marker = Path.Combine(Path.GetTempPath(), "dd-validation-flaky-mitigation"); + if (!File.Exists(marker)) + { + File.WriteAllText(marker, "1"); + throw new System.Exception("first attempt fails so Datadog can retry it"); + } + } + } + ``` + + {{% /tab %}} + {{% tab "Go" %}} + + ```go + package validation + + import ( + "errors" + "os" + "path/filepath" + "testing" + ) + + func TestFlakyValidationTest(t *testing.T) { + // Changed from dd-validation-flaky. + marker := filepath.Join(os.TempDir(), "dd-validation-flaky-mitigation") + if _, err := os.Stat(marker); errors.Is(err, os.ErrNotExist) { + if writeErr := os.WriteFile(marker, []byte("1"), 0600); writeErr != nil { + t.Fatal(writeErr) + } + t.Fatal("first attempt fails so Datadog can retry it") + } + } + ``` + + {{% /tab %}} + {{% tab "Swift" %}} + + ```swift + import XCTest + + final class ValidationFlakyTests: XCTestCase { + func testFlakyValidationTest() throws { + // Changed from dd-validation-flaky. + let marker = FileManager.default.temporaryDirectory + .appendingPathComponent("dd-validation-flaky-mitigation") + if !FileManager.default.fileExists(atPath: marker.path) { + try "1".write(to: marker, atomically: true, encoding: .utf8) + XCTFail("first attempt fails so Datadog can retry it") + } + } + } + ``` + + {{% /tab %}} + {{< /tabs >}} + +2. Commitez et poussez la modification sur la même branche : + + ```bash + git add -A + git commit -m "Validate Test Optimization mitigation" + git push origin validate-test-optimization + ``` + +3. Attendez l'exécution de l'intégration continue (CI), puis confirmez les résultats suivants : + + - Dans [Test Runs][8], [Auto Test Retries] relance le test après son premier échec, et le test réussit lors de la nouvelle tentative. Utilisez [cette requête][8], avec les filtres suivants : + - `@test.name:*flaky*validation*` + - `@git.branch:validate-test-optimization` + - `@test.retry_reason:auto_test_retry` + - Dans [Flaky Test Management][9], le test apparaît comme {{< ui >}}QUARANTINED{{< /ui >}}. Ses échecs ne bloquent plus le job de test. Utilisez [cette requête][9], avec les filtres suivants : + - `@test.name:*flaky*validation*` + - `first_flaked_branch:validate-test-optimization` + - `flaky_test_state:quarantined` + +### Étape 4 : Remediation {#step-4-remediation} + +Test Optimization aide à remédier aux flaky tests grâce à Attempt to Fix et aux [Bits AI-powered flaky test fixes][16]. Cette section valide le workflow Attempt to Fix en corrigeant le même test utilisé pour [Prevention](#step-2-prevention) et [Mitigation](#step-3-mitigation). + +1. Dans [Flaky Test Management][9], ouvrez le test de validation mis en quarantaine. +2. Cliquez sur {{< ui >}}Actions{{< /ui >}}, sélectionnez {{< ui >}}Link commit to fix{{< /ui >}} et copiez la clé générée (elle commence par `DD_`). + + {{< img src="pr_gates/setup/attempt_to_fix_modal.png" alt="Modale Attempt to Fix." style="width:50%" >}} + +3. Remplacez le flaky test par la version réussie pour votre langage : + + {{< tabs >}} + {{% tab "JavaScript" %}} + + ```javascript + test('flaky validation test', () => { + expect(true).toBe(true); + }); + ``` + + {{% /tab %}} + {{% tab "Python" %}} + + ```python + def test_flaky_validation_test(): + assert True + ``` + + {{% /tab %}} + {{% tab "Java" %}} + + ```java + @Test + void flakyValidationTest() { + // intentionally empty - the test passes + } + ``` + + {{% /tab %}} + {{% tab "Ruby" %}} + + ```ruby + it 'flaky validation test' do + expect(true).to be(true) + end + ``` + + {{% /tab %}} + {{% tab ".NET" %}} + + ```csharp + [Fact] + public void FlakyValidationTest() + { + Assert.True(true); + } + ``` + + {{% /tab %}} + {{% tab "Go" %}} + + ```go + func TestFlakyValidationTest(t *testing.T) { + } + ``` + + {{% /tab %}} + {{% tab "Swift" %}} + + ```swift + func testFlakyValidationTest() { + XCTAssertTrue(true) + } + ``` + + {{% /tab %}} + {{< /tabs >}} + +4. Commitez la correction avec la clé générée dans le corps du commit. Remplacez `` par la clé que vous avez copiée : + + ```bash + git add -A + git commit -m "Fix flaky validation test" -m "" + git push origin validate-test-optimization + ``` + +5. Attendez la fin de l'intégration continue (CI), puis confirmez les résultats suivants : + + - Dans [Test Runs][10], [Attempt to Fix] a relancé le fix candidate, et chaque tentative a réussi. Utilisez [cette requête][10], qui comporte les filtres suivants : + - `@test.name:*flaky*validation*` + - `@git.branch:validate-test-optimization` + - `@test.test_management.is_attempt_to_fix:true` + - Dans [Flaky Test Management][14], le test est marqué {{< ui >}}Fix in progress{{< /ui >}}. Utilisez [cette requête][14], qui comporte les filtres suivants : + - `@test.name:*flaky*validation*` + - `first_flaked_branch:validate-test-optimization` + - `fix_in_progress:true` + +### Étape 5 : Nettoyage post-validation {#step-5-post-validation-cleanup} + +1. Fermez le pull request sans le fusionner. +2. Supprimez la `validate-test-optimization`branche. La règle automatique Quarantine spécifique à la branche ne s'applique plus une fois la branche supprimée, et le service de validation dédié ne reçoit plus d'exécutions de test. +3. Informez l'équipe propriétaire du dépôt que le [New Flaky Test PR Gate][2] reste actif pour l'ensemble du dépôt. La gate est non-blocking par défaut. +4. Optionnellement, activez les fonctionnalités Test Optimization configurées pour le `validate-test-optimization` service au niveau du dépôt. + +## Pour aller plus loin {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /fr/tests/flaky_tests/early_flake_detection +[2]: /fr/tests/guides/setup_new_flaky_pr_gate +[3]: https://app.datadoghq.com/ci/settings/ci-cd/repositories?tab=repository +[4]: /fr/tests/flaky_tests/auto_test_retries +[5]: /fr/tests/flaky_management +[6]: /fr/tests/flaky_management/#configure-policies-to-automate-the-flaky-test-lifecycle +[7]: https://app.datadoghq.com/ci/test/runs?query=test_level%3Atest%20%40test.name%3A%2Aflaky%2Avalidation%2A%20%40git.branch%3Avalidate-test-optimization%20%40test.retry_reason%3Aearly_flake_detection%20%40test.test_management.is_new_flaky%3Atrue +[8]: https://app.datadoghq.com/ci/test/runs?query=test_level%3Atest%20%40test.name%3A%2Aflaky%2Avalidation%2A%20%40git.branch%3Avalidate-test-optimization%20%40test.retry_reason%3Aauto_test_retry +[9]: https://app.datadoghq.com/ci/test/flaky/explorer?query=%40test.name%3A%2Aflaky%2Avalidation%2A%20first_flaked_branch%3Avalidate-test-optimization%20flaky_test_state%3Aquarantined +[10]: https://app.datadoghq.com/ci/test/runs?query=test_level%3Atest%20%40test.name%3A%2Aflaky%2Avalidation%2A%20%40git.branch%3Avalidate-test-optimization%20%40test.test_management.is_attempt_to_fix%3Atrue +[11]: https://app.datadoghq.com/ci/pr-gates/rule/create?dataSource=test_optimization +[12]: /fr/tests/ +[13]: /fr/tests/test_impact_analysis/ +[14]: https://app.datadoghq.com/ci/test/flaky/explorer?query=%40test.name%3A%2Aflaky%2Avalidation%2A%20first_flaked_branch%3Avalidate-test-optimization%20fix_in_progress%3Atrue +[16]: /fr/tests/flaky_management/#bits-ai-powered-flaky-test-fixes \ No newline at end of file diff --git a/hugo/content/ja/account_management/teams/_index.md b/hugo/content/ja/account_management/teams/_index.md index 3dc2e4e36da..0404981150e 100644 --- a/hugo/content/ja/account_management/teams/_index.md +++ b/hugo/content/ja/account_management/teams/_index.md @@ -1,174 +1,178 @@ --- -description: チームのアセットを整理し、Datadog のエクスペリエンスにフィルターをかけ、チームハンドル、通知、リソースの関連付けを使用してチームメンバーシップを管理します。 +description: チームのアセットを整理し、Datadog のエクスペリエンスをフィルタリングし、チームハンドル、通知、リソースの関連付けを使用してチームメンバーシップを管理します。 further_reading: - link: https://www.datadoghq.com/blog/datadog-teams-github-integration tag: ブログ - text: Datadog Teams の GitHub インテグレーションを使用して、サービスの所有権を最新の状態に保ちます。 + text: Datadog Teams の GitHub 統合でサービスオーナーシップを最新の状態に保つ title: Teams --- ## 概要 {#overview} -Datadog Teams は、ユーザーグループが Datadog 内でチームのアセットを整理し、Datadog 全体のエクスペリエンスに自動的にフィルターをかけて、これらのアセットに優先順位を付けることができるようにします。 +Datadog Teams を使用すると、ユーザーグループは Datadog 内のチームアセットを整理し、Datadog 全体のエクスペリエンスを自動的にフィルタリングして、これらのアセットを優先的に表示できます。 -Teams を使用して、ダッシュボード、サービス、モニター、インシデントなどのリソースをユーザーのグループにリンクします。また、Slack チャンネル、Jira ボード、GitHub リポジトリなどに、チーム固有のリンクを追加することもできます。 +Teams を使用して、ダッシュボード、サービス、モニター、インシデントなどのリソースをユーザーグループにリンクします。Slack チャンネル、Jira ボード、GitHub リポジトリなどへのチーム固有のリンクを追加することもできます。 -チームメンバーシップは柔軟です。ユーザーは、チームに参加したり、ほかのメンバーから追加されたり、管理者から追加されたりすることができます。ユーザーは複数のチームに所属できます。 +チームメンバーシップはフレキシブルです。ユーザーはチームに参加したり、他のメンバーによって追加されたり、管理者によって追加されたりすることができます。ユーザーは複数のチームに所属できます。 ## セットアップ {#setup} ### ナビゲーション {#navigation} -[組織設定][1] から、または [**Teams**][2] に移動してチームディレクトリページにアクセスします。[チームディレクトリページ][1] には、組織内のすべてのチームが一覧表示されます。 +[Organization Settings][1] から、または [**Teams**][2] に移動して、チームディレクトリページにアクセスします。[チームディレクトリページ][1] には、組織内のすべてのチームがリスト表示されます。 -### チームの作成 {#create-team} +### チームを作成する {#create-team} -1. [チームディレクトリページ][1] で、右上の [{{< ui >}}New Team{{< /ui >}}] (新規チーム) をクリックします。 -1. [{{< ui >}}Team Name{{< /ui >}}] (チーム名) を選択します。 -1. [{{< ui >}}Handle{{< /ui >}}] (ハンドル) は、チーム名に基づいて入力されます。 -1. ドロップダウンメニューを使用して、チームメンバーおよびチームマネージャーを選択します。 -1. オプションで [{{< ui >}}Description{{< /ui >}}] (説明) を入力します。 -1. [{{< ui >}}Create{{< /ui >}}] (作成) をクリックします。 +1. [チームディレクトリページ][1] で、右上の {{< ui >}}New Team{{< /ui >}} をクリックします。 +1. {{< ui >}}Team Name{{< /ui >}} を選択します。 +1. {{< ui >}}Handle{{< /ui >}} はチーム名に基づいて入力されます。 +1. ドロップダウンメニューを使用して、チームメンバーとチームマネージャーを選択します。 +1. オプションの {{< ui >}}Description{{< /ui >}} を指定します。 +1. {{< ui >}}Create{{< /ui >}} をクリックします。 **注**: -- チーム名に使用できる文字は、`a-z`、`A-Z`、`0-9`、および `._-:/` です。スペースはアンダースコアに置き換えてください。 -- チームハンドルに使用できる文字は、`a-z`、`0-9`、および `._-:/` です。最後の文字はアンダースコアにすることはできません。 +- チーム名に使用できる文字は、`a-z`、`A-Z`、`0-9`、および `._-:/` です。スペースはアンダースコアに置き換えます。 +- チームハンドルに使用できる文字は、`a-z`、`0-9`、および `._-:/` です。最後の文字にアンダースコアは使用できません。 -### チームの修正 {#modify-team} +### チームを変更する {#modify-team} -1. [チームディレクトリページ][1] で、修正するチームをクリックします。[チーム詳細ページ][3] が表示されます。 -1. 画面上部にある [{{< ui >}}Settings{{< /ui >}}] (設定) の歯車をクリックします。ポップアップウィンドウが表示されます。 -1. 修正する項目を選択します。 -1. 変更を行い、[{{< ui >}}Save{{< /ui >}}] (保存) をクリックします。 +1. [チームディレクトリページ][1] で、変更したいチームをクリックします。[チーム詳細ページ][3] が表示されます。 +1. 画面上部の {{< ui >}}Settings{{< /ui >}} 歯車アイコンをクリックします。ポップアップウィンドウが表示されます。 +1. 変更する項目を選択します。 +1. 変更を行い、{{< ui >}}Save{{< /ui >}} をクリックします。 -### プロビジョニングソースの選択 {#choose-provisioning-source} +### プロビジョニングソースを選択する {#choose-provisioning-source} -管理者とチームマネージャーがチームメンバーシップを更新する方法を 3 つのオプションから選択します。 +管理者およびチームマネージャーがチームメンバーシップを更新する方法を以下の 3 つのオプションから選択します。 -UI and API (UI と API) -: UI アクションと API 呼び出しのみでメンバーシップを更新します。 +UI および API +: UI アクションおよび API 呼び出しを通じてのみメンバーシップを更新する SAML -: *SAML 限定*モデルを使用し、アイデンティティプロバイダーデータによってチームメンバーシップが決定されるようにします。 +: *SAML 厳密*モデルを使用して、ID プロバイダーのデータでチームメンバーシップを決定します。 -All sources (すべてのソース) -: 出発点として SAML を使用し、UI および API によるオーバーライドを許可します。 +すべてのソース +: SAML を開始点として使用し、UI および API 経由での上書きを許可します -1. [チームディレクトリページ][1] で、[{{< ui >}}Teams Settings{{< /ui >}}] (チーム設定) をクリックします。 -1. [{{< ui >}}Team Provisioning Sources{{< /ui >}}] (チームプロビジョニングソース) のいずれかのオプションを選択します。 +1. [チームディレクトリページ][1] で、{{< ui >}}Teams Settings{{< /ui >}} をクリックします。 +1. {{< ui >}}Team Provisioning Sources{{< /ui >}} の下にあるオプションのいずれかを選択します。 -既存メンバーがいるチームがある場合、SAML 限定オプションを選択すると、設定が上書きされ、そのチームからメンバーが削除されます。[All Sources] オプションを選択すると、既存のメンバーシップが維持されます。SAML 属性を使用してチームおよびチームメンバーシップを管理するには、[SAML 属性のチームへのマッピング][4] を参照してください。 +既存のメンバーがいるチームがある場合、SAML 厳密オプションを選択すると設定が上書きされ、それらのチームからチームメンバーが削除されます。すべてのソースオプションを選択すると、既存のメンバーシップが保持されます。SAML 属性を使用してチームとチームメンバーシップを管理する方法については、[SAML 属性を Teams にマッピングする][4] を参照してください。 + +## チーム階層 {#team-hierarchies} + +組織の構造を反映するようにチームを相互にネスト (サブチーム) し、その結果を Teams マップとして視覚化します。GitHub Teams、Teams API、Terraform、または Datadog UI を使用してチーム間の階層関係を定義する方法については、[チーム階層][39] を参照してください。 ## チームハンドル {#team-handle} -チームハンドルは、チームと Datadog のリソースをリンクします。チームハンドルは、検索バーやファセットに `team:` または `teams:` という形式で表示されます。 +チームハンドルは、チームと Datadog リソースをリンクします。チームハンドルは、検索バーやファセットに `team:` または `teams:` の形式で表示されます。 -チームハンドルを探すには +チームハンドルを確認するには、以下の手順に従います。 1. チームディレクトリページでチーム名をクリックします。チーム詳細ページが表示されます。 -1. チームハンドルはページ上部の名前の右側に表示されます。 +1. チームハンドルは、ページ上部の名前の右側に表示されます。 -リソースを定義されたチームに関連付けるには、一致するチームハンドルを持つチームが Datadog に存在する必要があります。定義されたチームに関連付けられたリソースをクリックすると、チームハンドルと追加情報を含む小さなウィンドウが表示されます。定義されたチームは、以下のチームフィルターのような追加機能を提供します。 +リソースを定義済みのチームに関連付けるには、一致するチームハンドルを持つチームが Datadog 内に存在する必要があります。定義済みのチームに関連付けられたリソースをクリックすると、チームハンドルと追加情報が記載された小さなウィンドウが表示されます。定義済みのチームは、以下のチームフィルターなどの追加機能を提供します。 -Datadog で定義されたチームに関連付けられていないチームハンドルは、タグと同じような動作をします。Teams の機能を利用するために、未定義のチームハンドルを定義されたチームに変換してください。 +Datadog で定義されたチームに関連付けられていないチームハンドルは、タグと同様に機能します。未定義のチームハンドルを定義済み Teams に変換して、Teams 機能を活用してください。 -### リソースとチームハンドルの関連付け {#associate-resources-with-team-handles} +### リソースをチームハンドルに関連付ける {#associate-resources-with-team-handles} -Datadog は、以下のリソースをチームハンドルに関連付けることをサポートしています。 +Datadog は以下のリソースをチームハンドルに関連付けることをサポートしています。 - [Dashboards][5] -- [インシデント][6] -- [モニター][7] +- [Incidents][6] +- [Monitors][7] - [Resource Catalog][8] -- [Software Catalog][9] +- [Catalog][9] - [Service Level Objectives][10] -- Synthetic テスト、グローバル変数、プライベートロケーション +- Synthetic Tests、Global Variables、Private Locations -### 通知を特定のコミュニケーションチャンネルに送信する {#send-notifications-to-a-specific-communication-channel} +### 特定の通信チャネルに通知を送信する {#send-notifications-to-a-specific-communication-channel} -通知チャンネルをチームに追加して、Slack や Microsoft Teams などのコミュニケーションチャンネルにアラートをルーティングします。`@team-` を対象とするモニターアラートは、選択したチャンネルにリダイレクトされます。 +チームに通知チャネルを追加して、Slack や Microsoft Teams などの通信チャネルにアラートをルーティングします。`@team-` を対象とするモニターアラートは、選択したチャネルにリダイレクトされます。 -1. [チームディレクトリページ][1] で、修正するチームをクリックします。 -1. 画面上部にある [{{< ui >}}Settings{{< /ui >}}] の歯車をクリックします。ポップアップウィンドウが表示されます。 -1. [{{< ui >}}Notifications{{< /ui >}}] (通知) を選択します。 -1. チャンネルを追加して、[{{< ui >}}Save{{< /ui >}}] をクリックします。 +1. [チームディレクトリページ][1] で、変更したいチームをクリックします。 +1. 画面上部の {{< ui >}}Settings{{< /ui >}} 歯車アイコンをクリックします。ポップアップウィンドウが表示されます。 +1. {{< ui >}}Notifications{{< /ui >}} を選択します。 +1. チャネルを追加し、{{< ui >}}Save{{< /ui >}} をクリックします。 ## チームフィルター {#team-filter} -チームフィルターは、Datadog 全体でのエクスペリエンスを、所属チームに関連するコンテンツのみを表示するように調整します。[{{< ui >}}My Teams{{< /ui >}}] (自分のチーム) リストには、自分がメンバーであるチームおよびお気に入りとして選択したチームが含まれます。 +チームフィルターを使用すると、所属チームに関連付けられたコンテンツが表示され、Datadog でのエクスペリエンスが最適化されます。{{< ui >}}My Teams{{< /ui >}} リストには、自分がメンバーであるチームと、お気に入りとして選択したチームが含まれます。 -{{< img src="/account_management/teams/team-filter.png" alt="チームフィルターが赤いボックスで囲まれている、モニターリストページ。3 つの [My Teams] のうち、2 つが選択されています。">}} +{{< img src="/account_management/teams/team-filter.png" alt="チームフィルターの周囲に赤い枠線が表示されたモニターリストページ。3 つのうち 2 つのマイチームが選択されています。">}} -チームフィルターを有効にすると、自分が所属するチームに関連するリソース、またはそのチームが所有するサービスに関連するリソースのみが表示されます。チームフィルターの状態はグローバルかつ永続的であるため、Datadog 内のさまざまな製品間を移動しても、チームコンテキストが適用され続けます。 +チームフィルターを有効にすると、自分のチームに関連付けられたリソース、または自分のチームが所有するサービスに関連付けられたリソースのみが表示されます。チームフィルターの状態はグローバルで永続的であるため、Datadog は異なる製品間を移動する際にもチームコンテキストを適用します。 -チームフィルターは、チームベースの検索用語を検索クエリに追加することで機能します。チームフィルターを有効にすると、検索バーで追加されたチームベースの検索用語を確認できます。 +チームフィルターは、検索クエリにチームベースの検索語句を追加することで機能します。チームフィルターを有効にすると、検索バーに追加されたチームベースの検索語句を確認できます。 ### お気に入りのチーム {#favorite-teams} -特定のチームのメンバーではないが、そのチームのリソースに関心があるという場合があります。そのチームをお気に入りに追加することで、チームに参加することなく、チームのリソースのみをフィルターして表示することができます。 +特定のチームのメンバーでなくても、そのチームのリソースに関心がある場合があります。チームをお気に入りに追加すると、そのチームに参加しなくても、そのチームのリソースに関するフィルタリングされたビューを取得できます。 -お気に入りにしたチームは、自分が所属するチームとともにチームディレクトリページの上部やチームフィルター内に表示されます。 +お気に入りのチームは、チームディレクトリページの上部とチームフィルター内に所属しているチームと並んで表示されます。 -#### お気に入りのチームの追加または削除 {#add-or-remove-favorite-teams} +#### お気に入りのチームを追加または削除する {#add-or-remove-favorite-teams} -チームをお気に入りに追加または削除するには、チームディレクトリページまたはチームフィルターから行えます。 +チームディレクトリページまたはチームフィルターで、チームをお気に入りに追加したり、お気に入りから削除したりできます。 -[チームディレクトリページ][1] から、 -1. お気に入りに追加するチームをクリックします。[チーム詳細ページ][3] が表示されます。 -1. 右上の [{{< ui >}}Add Favorite{{< /ui >}}] (お気に入りに追加) または [{{< ui >}}Remove Favorite{{< /ui >}}] (お気に入りを削除) をクリックします。 +[チームディレクトリページ][1] から以下の手順を実行します。 +1. お気に入りとして追加したいチームをクリックします。[チーム詳細ページ][3] が表示されます。 +1. 右上の {{< ui >}}Add Favorite{{< /ui >}} または {{< ui >}}Remove Favorite{{< /ui >}} をクリックします。 -あるいは、同じくチームディレクトリページで、 -1. 追加または削除するチームにカーソルを合わせます。チーム名の右側にインラインアイコンが表示されます。 -1. 星のアイコン ([{{< ui >}}Add to Favorites{{< /ui >}}] または [{{< ui >}}Remove from Favorites{{< /ui >}}]) をクリックします。 +または、同じくチームディレクトリページから以下の手順を実行します。 +1. 追加または削除したいチームにカーソルを合わせます。チーム名の右側にインラインアイコンが表示されます。 +1. 星 ({{< ui >}}Add to Favorites{{< /ui >}} または {{< ui >}}Remove from Favorites{{< /ui >}}) アイコンをクリックします。 -チームフィルターから、 -1. フィルターが折りたたまれている場合、[{{< ui >}}My Teams{{< /ui >}}] をクリックして展開します。 -1. [{{< ui >}}Add Favorites{{< /ui >}}] をクリックします。検索ボックスとチームのリストが表示されます。 -1. チーム名を検索ボックスに入力してチームリストを絞り込みます。 -1. 目的のチームの横にある星をクリックして、お気に入りに追加または削除します。 +チームフィルターから以下の手順を実行します。 +1. フィルターが折りたたまれている場合は、{{< ui >}}My Teams{{< /ui >}} をクリックして展開します。 +1. {{< ui >}}Add Favorites{{< /ui >}} をクリックします。検索ボックスとチームのリストが表示されます。 +1. チームのリストを絞り込むには、検索ボックスでチーム名の入力を始めます。 +1. 目的のチームの横にある星をクリックすると、お気に入りに追加したり削除したりできます。 -### 対応製品 {#supported-products} +### サポートされている製品 {#supported-products} -以下の表は、チームフィルターを使用できる製品を示します。 +次のテーブルは、チームフィルターを使用できる製品について説明しています。 | 製品リストページ | フィルターの基準 | |--------------------------------|------------------------------------------------------------------------------------| -| [APM Error Tracking][15] | チームが所有するサービス ([Software Catalog][12] 内での所有権により決定) | -| [アプリ][21] | チームハンドル | -| [Case Management プロジェクト][22] | チームハンドル | -| [コネクション][23] | チームハンドル | -| [コネクショングループ][24] | チームハンドル | -| [組織間コネクション][25] | チームハンドル | -| [Datastore][26] | チームハンドル | +| [APM Error Tracking][15] | チームが所有するサービス ([Catalog][12] 内の所有権によって決定) | +| [Apps][21] | チームハンドル | +| [Work Management projects][22] | チームハンドル | +| [Connections][23] | チームハンドル | +| [Connection Groups][24] | チームハンドル | +| [Cross Org Connections][25] | チームハンドル | +| [Datastores][26] | チームハンドル | | [Data Streams Monitoring][18] | チームハンドル | | [Dashboards][11] | チームハンドル | -| [インシデント][13] | チームハンドル | +| [Incidents][13] | チームハンドル | | [Integrations][27] | チームハンドル | -| [Logs Error Tracking][16] | チームが所有するサービス ([Software Catalog][12] 内での所有権により決定) | +| [Logs Error Tracking][16] | チームが所有するサービス ([Resource Catalog][12] 内の所有権によって決定) | | [Logs Pipelines][28] | チームハンドル | -| [モニター][14] | チームハンドル | +| [Monitors][14] | チームハンドル | | [Notebooks][20] | チームハンドル | | [Observability Pipelines][29] | チームハンドル | -| [On-Call][30] | チームが所有するサービス ([Software Catalog][12] 内での所有権により決定) | -| [パワーパック][32] | チームハンドル | +| [On-Call][30] | チームが所有するサービス ([Resource Catalog][12] 内の所有権によって決定) | +| [Powerpacks][32] | チームハンドル | | [Private Action Runner][31] | チームハンドル | -| [リファレンステーブル][33] | チームハンドル | +| [Reference tables][33] | チームハンドル | | [Resource Catalog][8] | チームハンドル | -| [RUM アプリ][34] | チームハンドル | -| [セキュリティルール][35] | チームハンドル | -| [セキュリティ抑制][36] | チームハンドル | +| [RUM apps][34] | チームハンドル | +| [Security rules][35] | チームハンドル | +| [Security suppressions][36] | チームハンドル | | [Service Level Objectives][17] | チームハンドル | | [Sheets][37] | チームハンドル | -| [Software Catalog][12] | チームハンドル | -| [Synthetic テスト][19] | チームハンドル | -| [ワークフロー][38] | チームハンドル | +| [Catalog][12] | チームハンドル | +| [Synthetic Tests][19] | チームハンドル | +| [Workflows][38] | チームハンドル | ## 権限 {#permissions} -[Teams Manage] (チーム管理) 権限を持つロールのユーザーは、チームの作成、チーム名の変更、チームの削除、チームハンドルの変更を行うことができます。`user_access_manage` を持つユーザーは、チームメンバーやマネージャーの追加、削除、昇格が可能です。 +Teams Manage 権限を持つロールのユーザーは、チームの作成、名前の変更、削除、およびチームハンドルの変更を行うことができます。`user_access_manage` を持つユーザーは、チームメンバーやマネージャーの追加、削除、昇格を行うことができます。 -## チームの管理 {#manage-teams} +## チームを管理する {#manage-teams} -チームをカスタマイズする方法については、[チーム管理][3] を参照してください。 +チームをカスタマイズするには、[チーム管理][3] をご覧ください。 [1]: https://app.datadoghq.com/organization-settings/teams @@ -179,7 +183,7 @@ Datadog は、以下のリソースをチームハンドルに関連付けるこ [6]: /ja/incident_response/incident_management/ [7]: /ja/monitors/configuration/?tab=thresholdalert#add-metadata [8]: https://app.datadoghq.com/infrastructure/catalog -[9]: /ja/tracing/software_catalog/adding_metadata/#add-metadata-from-the-datadog-ui +[9]: /ja/internal_developer_portal/catalog/entity_model/ [10]: /ja/service_level_objectives/#slo-tags [11]: https://app.datadoghq.com/dashboard/lists [12]: https://app.datadoghq.com/services @@ -192,7 +196,7 @@ Datadog は、以下のリソースをチームハンドルに関連付けるこ [19]: https://app.datadoghq.com/synthetics [20]: https://app.datadoghq.com/notebook/list/ [21]: https://app.datadoghq.com/app-builder/apps/list -[22]: https://app.datadoghq.com/cases +[22]: https://app.datadoghq.com/work [23]: https://app.datadoghq.com/actions/connections [24]: https://app.datadoghq.com/actions/connections?sort=-updated_at&tab=groups [25]: https://app.datadoghq.com/organization-settings/cross-org-visibility @@ -208,4 +212,5 @@ Datadog は、以下のリソースをチームハンドルに関連付けるこ [35]: https://app.datadoghq.com/security/configuration/notification-rules [36]: https://app.datadoghq.com/security/configuration/suppressions [37]: https://app.datadoghq.com/sheets -[38]: https://app.datadoghq.com/workflow \ No newline at end of file +[38]: https://app.datadoghq.com/workflow +[39]: /ja/account_management/teams/manage/#team-hierarchies \ No newline at end of file diff --git a/hugo/content/ja/actions/app_builder/components/_index.md b/hugo/content/ja/actions/app_builder/components/_index.md new file mode 100644 index 00000000000..08c81068779 --- /dev/null +++ b/hugo/content/ja/actions/app_builder/components/_index.md @@ -0,0 +1,1345 @@ +--- +aliases: +- /ja/service_management/app_builder/components +description: ボタン、フォーム、テーブル、チャート、インタラクティブ要素など、App Builder UI コンポーネントの包括的なリファレンスです。 +disable_toc: true +further_reading: +- link: /actions/app_builder/components/tables/ + tag: ドキュメント + text: テーブル +- link: /actions/app_builder/build/ + tag: ドキュメント + text: アプリの構築 +- link: /actions/app_builder/expressions/ + tag: ドキュメント + text: JavaScript の式 +- link: https://learn.datadoghq.com/courses/app-builder-integration + tag: ラーニングセンター + text: App Builder を使用してサードパーティインテグレーション用のセルフサービスアプリを構築する +title: コンポーネント +--- +{{< site-region region="gov" >}} +
+App Builder は、Datadog の政府機関用サイト US1-FED でプレビュー版として提供されています。 +
+{{< /site-region >}} + +## 概要 {#overview} +このページでは、App Builder でアプリを作成する際に使用できる UI コンポーネントのリストを示します。 + +多くのコンポーネントプロパティでは、提供された値の中から選択できます。プロパティの値に式を使用する場合は、プロパティの横にある [{{< ui >}}</>{{< /ui >}}] をクリックして、コードエディターを使用します。 + +イベントをトリガーできるすべてのコンポーネントに、[イベントとリアクション][13] で利用可能な複数のリアクションがあります。これらのコンポーネントでは、[カスタムリアクション][14] も使用できます。 + +App Builder での JavaScript の使用に関する詳細については、「[JavaScript の式][7]」を参照してください。コンポーネントをテンプレートとして保存する方法については、「[再利用可能なモジュール][12]」を参照してください。 +
+ +## 使用可能なコンポーネント {#available-components} + +{{% collapse-content title="ボタン" level="h3" %}} +ボタンコンポーネントには、以下のプロパティがあります。 + +#### 一般 {#general} + +Label (ラベル) +: ボタンに表示されるテキスト。
+**値**: 文字列または式 + +#### 外観 {#appearance} + +Intent (意図) +: ボタンの色を制御します。色はボタンの目的を表します。
+**提示される値**: default (デフォルト)、danger (危険)、success (成功)、warning (警告) + +Is Primary (プライマリ) +: 特定のページやワークフローにおいて、最も重要なアクションにユーザーの注意を向けるために使用します。
+**提示される値**: on (オン)、off (オフ) + +Is Borderless (枠線なし) +: ボタンから枠線を取り除きます。マウスを重ねると、背景が塗りつぶされます。
+**提示される値**: on、off + +Is Loading (読み込み中) +: 読み込み中のインジケーターを表示します。
+**提示される値**: on、off + +Is Disabled (無効) +: 無効時のスタイルを適用し、操作を無効にします。
+**提示される値**: on、off + +Is Visible (表示) +: コンポーネントがユーザーに対して表示されるかどうかを決定します。編集モードでは、すべてのコンポーネントが表示されたままになります。
+**提示される値**: on、off + +#### イベント {#events} + +Event (イベント) +: **値**: click (クリック) + +Reaction (リアクション) +: **値**: 例: open modal (モーダルを開く)、trigger action (アクションのトリガー)、set component state (コンポーネントの状態の設定)
+すべての利用可能なリアクションは、「[イベント][1]」を参照してください。 + +#### データの検査 {#inspect-data} + +プロパティと値のペアを JSON 形式で表示します。 + +#### 例 {#example} + +このコンポーネントをコンテキスト内で表示するには、[Metrics Explorer および Monitors Builder][2] アプリのブループリントを参照してください。 +{{% /collapse-content %}} + + +{{% collapse-content title="コールアウト値" level="h3" %}} +コールアウト値コンポーネントには、以下のプロパティがあります。 + +#### 一般 {#general-1} + +Label +: コンポーネントの上部に表示されるテキスト。
+**値**: 文字列または式 + +Value (値) +: コールアウトで強調される値。
+**値**: 文字列または式 + +Unit (単位) +: 値に関連付けられている単位。
+**値**: 文字列または式 + +#### スタイル {#style} + +Style (スタイル) +: コンポーネントの視覚的なスタイル。
+**提示される値**: default、success、warning、danger、blue (青)、purple (紫)、pink (ピンク)、orange (オレンジ)、yellow (黄)、red (赤)、green (緑)、gray (グレー)、vivid blue (鮮やかな青)、vivid purple (鮮やかな紫)、vivid pink (鮮やかなピンク)、vivid orange (鮮やかなオレンジ)、vivid yellow (鮮やかな黄)、vivid red (鮮やかな赤)、vivid green (鮮やかな緑) + +Size (サイズ) +: 値のサイズに比例するように、指標のサイズをレスポンシブに調整します。
+**提示される値**: sm、md、lg、xl + +#### 外観 {#appearance-1} + +Is Loading +: 読み込み中のインジケーターを表示します。
+**提示される値**: on、off + +Is Disabled +: 無効時のスタイルを適用し、操作を無効にします。
+**提示される値**: on、off + +Is Visible +: コンポーネントがユーザーに対して表示されるかどうかを決定します。編集モードでは、すべてのコンポーネントが表示されたままになります。
+**提示される値**: on、off + +#### データの検査 {#inspect-data-1} + +プロパティと値のペアを JSON 形式で表示します。 + +#### 例 {#example-1} + +このコンポーネントをコンテキスト内で表示するには、[EC2 Instance Manager][3] アプリのブループリントを参照してください。 +{{% /collapse-content %}} + + + +{{% collapse-content title="チェックボックス" level="h3" %}} +チェックボックスコンポーネントには、以下のプロパティがあります。 + +#### 一般 {#general-2} + +Label +: コンポーネントの上部に表示されるテキスト。
+**値**: 文字列または式 + +Options (オプション) +: ユーザーが選択できるチェックボックスのリスト。形式はオブジェクトの配列であり、各オブジェクトは `label` と `value` のキーと値のペアで構成されます。指定できるオプション数の最小値は 1 です。
+**値**: 式
+**例**:
+: ```json + ${[ + { + "label": "Staging", + "value": "staging" + }, + { + "label": "Production", + "value": "production" + } + ]} + ``` + +#### 外観 {#appearance-2} + +Is Multiline (複数行) +: チェックボックスのテキストを改行して次の行に表示するか、切り捨てて省略記号を表示するかを決定します。
+**提示される値**: on、off + +Is Disabled +: 無効時のスタイルを適用し、操作を無効にします。
+**提示される値**: on、off + +Is Visible +: コンポーネントがユーザーに対して表示されるかどうかを決定します。編集モードでは、すべてのコンポーネントが表示されたままになります。
+**提示される値**: on、off + +#### イベント {#events-1} + +Event +: **値**: change (変更)
+ +Reaction +: **値**: 例: open modal、trigger action、set component state
+すべての利用可能なリアクションは、「[イベント][1]」を参照してください。 + +#### データの検査 {#inspect-data-2} + +プロパティと値のペアを JSON 形式で表示します。 + +#### 例 {#example-2} + +このコンポーネントをコンテキスト内で表示するには、[Metrics Explorer および Monitors Builder][2] アプリのブループリントを参照してください。 +{{% /collapse-content %}} + + + +{{% collapse-content title="コンテナ" level="h3" %}} +コンテナコンポーネントには、以下のプロパティがあります。 + +#### 外観 {#appearance-3} + +Is Visible +: コンポーネントがユーザーに対して表示されるかどうかを決定します。編集モードでは、すべてのコンポーネントが表示されたままになります。
+**提示される値**: on、off + +#### データの検査 {#inspect-data-3} + +プロパティと値のペアを JSON 形式で表示します。 + +#### 例 {#example-3} + +このコンポーネントをコンテキスト内で表示するには、[Metrics Explorer および Monitors Builder][2] アプリのブループリントを参照してください。 +{{% /collapse-content %}} + + + +{{% collapse-content title="カスタムチャート" level="h3" %}} +カスタムチャートコンポーネントには、以下のプロパティがあります。 + +#### 一般 {#general-3} + +Vega Specification (Vega 仕様) +: 有効な Vega-Lite または Vega JSON 仕様を表す文字列。 + +#### 外観 {#appearance-4} + +Is Loading +: 読み込み中のインジケーターを表示します。
+**提示される値**: on、off + +Is Visible +: コンポーネントがユーザーに対して表示されるかどうかを決定します。編集モードでは、すべてのコンポーネントが表示されたままになります。
+**提示される値**: on、off + +#### データの検査 {#inspect-data-4} + +プロパティと値のペアを JSON 形式で表示します。 + +#### 例 {#example-4} + +このコンポーネントの使用方法を示す例については、「[カスタムチャート][10]」を参照してください。 + +{{% /collapse-content %}} + + +{{% collapse-content title="日付ピッカー" level="h3" %}} +日付ピッカーコンポーネントには、以下のプロパティがあります。 + +#### 一般 {#general-4} + +Label +: 日付ピッカーの上部に表示されるラベル。
+**値**: 文字列または式 + +Tooltip (ツールチップ) +: 入力ラベルにカーソルを合わせたときに表示されるツールチップ。ツールチップにはマークダウンを含めることができます。
+**値**: 文字列または式 + +Default Value (デフォルト値) +: 日付ピッカーのデフォルトの日付。ミリ秒単位の UNIX タイムスタンプとして表示されます。
+**値**: 整数 + +Allow Future Dates (将来の日付を許可) +: 今日より後の日付を設定できるかどうかを決定します。
+**提示される値**: on、off + +#### 外観 {#appearance-5} + +Is Visible +: コンポーネントがユーザーに対して表示されるかどうかを決定します。編集モードでは、すべてのコンポーネントが表示されたままになります。
+**提示される値**: on、off + +#### イベント {#events-2} + +Event +: **値**: change + +Reaction +: **値**: 例: open modal、trigger action、set component state
+すべての利用可能なリアクションは、「[イベント][1]」を参照してください。 + +State Function (状態関数) +: setValue
+**例**: [状態関数][9] を参照してください。 + +#### データの検査 {#inspect-data-5} + +プロパティと値を JSON 形式で表示します。値は、ミリ秒単位の UNIX タイムスタンプと ISO 形式 (年、月、日、時、分、秒、ミリ秒) の両方で表示されます。 + +{{% /collapse-content %}} + + +{{% collapse-content title="日付範囲ピッカー" level="h3" %}} +日付範囲ピッカーコンポーネントには、以下のプロパティがあります。 + +#### 一般 {#general-5} + +Default timeframe (デフォルト期間) +: 日付ピッカーに表示されるデフォルトの期間。
+**提示される値**: past 5 minutes (過去 5 分)、past 30 minutes (過去 30 分)、past 1 hour (過去 1 時間)、past 4 hours (過去 4 時間)、past 1 day (過去 1 日) + +#### 外観 {#appearance-6} + +Is Visible +: コンポーネントがユーザーに対して表示されるかどうかを決定します。編集モードでは、すべてのコンポーネントが表示されたままになります。
+**提示される値**: on、off + +#### イベント {#events-3} + +Event +: **値**: change + +Reaction +: **値**: 例: open modal、trigger action、set component state
+すべての利用可能なリアクションは、「[イベント][1]」を参照してください。 + +#### データの検査 {#inspect-data-6} + +プロパティと値のペアを JSON 形式で表示します。 + +#### 例 {#example-5} + +このコンポーネントをコンテキスト内で表示するには、[Metrics Explorer および Monitors Builder][2] アプリのブループリントを参照してください。 +{{% /collapse-content %}} + + +{{% collapse-content title="区切り線" level="h3" %}} +区切り線コンポーネントには、以下のプロパティがあります。 + +#### 外観 {#appearance-7} + +Is Visible +: コンポーネントがユーザーに対して表示されるかどうかを決定します。編集モードでは、すべてのコンポーネントが表示されたままになります。
+**提示される値**: on、off + +#### データの検査 {#inspect-data-7} + +プロパティを JSON 形式で表示します。 + +{{% /collapse-content %}} + + +{{% collapse-content title="ファイル入力" level="h3" %}} +ファイル入力コンポーネントには、以下のプロパティがあります。 + +#### 一般 {#general-6} + +Accepted File Types (受け入れられるファイルタイプ) +: ファイル入力コンポーネントが受け入れるファイルタイプを指定します。
+**値**: .csv、.json + +#### 外観 {#appearance-8} + +Is Visible +: コンポーネントがユーザーに対して表示されるかどうかを決定します。編集モードでは、すべてのコンポーネントが表示されたままになります。
+**提示される値**: on、off + +#### イベント {#events-4} + +Event +: **値**: change + +Reaction +: **値**: 例: open modal、trigger action、set component state
+すべての利用可能なリアクションは、「[イベント][1]」を参照してください。 + +#### データの検査 {#inspect-data-8} + +プロパティと値のペアを JSON 形式で表示します。 + +{{% /collapse-content %}} + + +{{% collapse-content title="画像" level="h3" %}} +画像コンポーネントには、以下のプロパティがあります。 + +#### 一般 {#general-7} + +Source (ソース) +: 表示する画像。サポートされている形式は、JPG、PNG、GIF です。最大アップロードサイズは 4 MB です。
+**値**: URL またはファイル + +#### 外観 {#appearance-9} + +Fit (適合) +: 画像コンポーネントの境界内での画像の寸法を指定します。
+**提示される値**: fill (埋める)、contain (含める)、cover (重ねる)、none (なし) + +Padding (パディング) +: 画像の境界と画像コンポーネントの境界との間のスペースの幅を指定します。
+**提示される値**: none、small (小)、medium (中)、large (大) + +Vertical Alignment (垂直方向の配置) +: 画像コンポーネントの境界内での画像の垂直方向の位置を指定します。
+**提示される値**: align top (上揃え)、align center (中央揃え)、align bottom (下揃え) + +Horizontal Alignment (水平方向の配置) +: 画像コンポーネントの境界内での画像の水平方向の位置を指定します。
+**提示される値**: align left (左揃え)、align center (中央揃え)、align right (右揃え) + +Border (境界線) +: 画像コンポーネントの端に目に見える境界線を表示するかどうかを指定します。
+**提示される値**: on、off + +Transparent Background (透明な背景) +: 画像コンポーネント内の背景を透明にするかどうかを指定します。
+**提示される値**: on、off + +Is Loading +: 画像の読み込み中に読み込み中アイコンを表示するかどうかを指定します。
+**提示される値**: on、off + +Is Visible +: コンポーネントがユーザーに対して表示されるかどうかを決定します。編集モードでは、すべてのコンポーネントが表示されたままになります。
+**提示される値**: on、off + +#### データの検査 {#inspect-data-9} + +プロパティを JSON 形式で表示します。 + +{{% /collapse-content %}} + + +{{% collapse-content title="統合ロゴ" level="h3" %}} +統合ロゴコンポーネントには、以下のプロパティがあります。 + +#### 一般 {#general-8} + +Integration Id (統合 ID) +: 表示する統合ロゴアイコンを指定します。
+**値**: 文字列または式
+**例**: datadog、amazon-s3、postgres、okta + +#### 外観 {#appearance-10} + +Horizontal Alignment +: コンポーネント内でのロゴの水平方向の配置を制御します。
+**提示される値**: align left、align center、align right + +Vertical Alignment +: コンポーネント内でのロゴの垂直方向の配置を制御します。
+**提示される値**: align top、align center、align bottom + +Is Visible +: コンポーネントがユーザーに対して表示されるかどうかを決定します。編集モードでは、すべてのコンポーネントが表示されたままになります。
+**提示される値**: on、off + +Is Loading +: 読み込み中のインジケーターを表示します。
+**提示される値**: on、off + +#### データの検査 {#inspect-data-10} + +プロパティと値のペアを JSON 形式で表示します。 + +{{% /collapse-content %}} + + +{{% collapse-content title="フォーム" level="h3" %}} +フォームコンポーネントには、以下のプロパティがあります。 + +#### 一般 {#general-9} + +Title (タイトル) +: フォームのタイトル。
+**値**: 文字列または式 + +Default value +: アプリがフォームに設定するデフォルト値。特定のフィールドに値を設定する際には、JSON 表記を使用できます。たとえば、`{"org":"frontend"}` を使用して、`org` フィールドに `frontend` の値を設定します。
+**値**: 文字列または式 + +#### フィールド {#fields} + +各項目は、フォーム内のフィールドを表します。各フィールドのタイプは、: 、`textInput`、`select`、`textArea`、または`text` のいずれかです。 + +フィールドには、そのフィールドタイプに応じて、以下のプロパティのいずれかまたはすべてが指定されます。 + +Field name (フィールド名) +: フィールドの一意の識別子。この識別子を使用して、式の中でフィールドを参照できます。
+**値**: 文字列または式 + +Label +: フィールドの上に表示されるラベル。
+**値**: 文字列または式 + +Content (コンテンツ) +: `text` フィールドに表示されるコンテンツ。
+**値**: 文字列または式 + +Options +: `select` フィールドで使用可能なオプション。オプションはオブジェクトの配列である必要があり、オプション値には `const` キーを、オプションラベルにはオプションで `title` キーを使用します。
**値**: 各オブジェクトの `label` と `value` には、文字列または式を指定できます。
+GUI を使用して各オブジェクトに値を設定するか (デフォルト)、[{{< ui >}}Raw{{< /ui >}}] (生) に切り替えて、生の JSON 入力を使用してオブジェクトの配列全体を指定します。 + +Placeholder text (プレースホルダーテキスト) +: 値が入力されていない場合に、`textInput` または `textArea` フィールドに表示されるテキスト。
+**値**: 文字列または式 + +Is Disabled +: 無効時のスタイルを適用し、操作を無効にします。
+**提示される値**: on、off + +Is Visible +: フォーム内にフィールドを表示するかどうかを指定します。
+**提示される値**: on、off + +Is Required (必須) +: フォームを送信するためにフィールドが必須かどうかを指定します。
+**提示される値**: on、off + +#### 外観 {#appearance-11} + +Is Visible +: コンポーネントがユーザーに対して表示されるかどうかを決定します。編集モードでは、すべてのコンポーネントが表示されたままになります。
+**提示される値**: on、off + +Is Disabled +: 無効時のスタイルを適用し、操作を無効にします。
+**提示される値**: on、off + +#### イベント {#events-5} + +Event +: **値**: submit (送信)、change (変更)、validate (検証) + +Reaction +: **値**: 例: open modal、trigger action、set component state
+すべての利用可能なリアクションは、「[イベント][1]」を参照してください。 + +State Function +: setValue
+**例**: `form0.setValue({name: 'node-group-1'})` は、`form0` コンポーネントの値を `{name: 'node-group-1'}` に設定します。
+詳細については、「[状態関数][9]」を参照してください。 + +#### データの検査 {#inspect-data-11} + +プロパティと値のペアを JSON 形式で表示します。 + +{{% /collapse-content %}} + + +{{% collapse-content title="JSON 入力" level="h3" %}} +JSON 入力コンポーネントには、以下のプロパティがあります。 + +#### 一般 {#general-10} + +Label +: コンポーネントの上部に表示されるテキスト。 + +Default value +: コンポーネントに表示されるデフォルトの JSON 値です。 + +#### 外観 {#appearance-12} + +Is Read Only (読み取り専用) +: コンポーネントを読み取り専用にするかどうかを指定します。
+**提示される値**: on、off + +Is Visible +: コンポーネントがユーザーに対して表示されるかどうかを決定します。編集モードでは、すべてのコンポーネントが表示されたままになります。
+**提示される値**: on、off + +#### イベント {#events-6} + +Event +: **値**: change + +Reaction +: **値**: 例: open modal、trigger action、set component state
+すべての利用可能なリアクションは、「[イベント][1]」を参照してください。 + +#### データの検査 {#inspect-data-12} + +プロパティと値のペアを JSON 形式で表示します。 +{{% /collapse-content %}} + + + +{{% collapse-content title="モーダル" level="h3" %}} +モーダルコンポーネントには以下のプロパティがあります。 + +#### 一般 {#general-11} + +Title +: モーダルのタイトル。
+**値**: 文字列または式 + +#### 外観 {#appearance-13} + +Size +: モーダルのスケール。
+**提示される値**: sm、md、lg + +Is Visible +: コンポーネントがユーザーに対して表示されるかどうかを決定します。編集モードでは、すべてのコンポーネントが表示されたままになります。
+**提示される値**: on、off + +#### イベント {#events-7} + +Event +: **値**: toggleOpen (オープンを切り替え)、close (クローズ)、open (オープン) + +Reaction +: **値**: 例: open modal、trigger action、set component state
+すべての利用可能なリアクションは、「[イベント][1]」を参照してください。 + +State Function +: setIsOpen
+**例**: `modal0.setIsOpen(true)` は `modal0` の状態を open に設定します。
+詳細については、「[状態関数][9]」を参照してください。 + +#### データの検査 {#inspect-data-13} + +プロパティと値のペアを JSON 形式で表示します。 + +#### 例 {#example-6} + +このコンポーネントをコンテキスト内で表示するには、[Metrics Explorer および Monitors Builder][2] アプリのブループリントを参照してください。 +{{% /collapse-content %}} + + + +{{% collapse-content title="数値入力" level="h3" %}} +数値入力コンポーネントには、以下のプロパティがあります。 + +Label +: コンポーネントの上部に表示されるテキスト。
+**値**: 文字列または式 + +Default value +: 入力ボックスにアプリが設定するデフォルト値。
+**値**: 数値、または数値に評価される式 + +Placeholder text +: 値が入力されていないときに表示されるテキスト。
+**値**: 文字列または式 + +#### 検証 {#validation} + +Min (最小値) +: 数値入力で受け入れられる最小値。
+**値**: 数値、または数値に評価される式 + +Max (最大値) +: 数値入力で受け入れられる最大値。
+**値**: 数値、または数値に評価される式 + +#### 外観 {#appearance-14} + +Is Disabled +: 無効時のスタイルを適用し、操作を無効にします。
+**提示される値**: on、off + +Is Visible +: コンポーネントがユーザーに対して表示されるかどうかを決定します。編集モードでは、すべてのコンポーネントが表示されたままになります。
+**提示される値**: on、off + +#### イベント {#events-8} + +Event +: **値**: change + +Reaction +: **値**: 例: open modal、trigger action、set component state
+すべての利用可能なリアクションは、「[イベント][1]」を参照してください。 + +State Function +: setValue
+**例**: `numberInput0.setValue(3)` は、`numberInput0` コンポーネントの値を `3` に設定します。
+詳細については、「[状態関数][9]」を参照してください。 + +#### データの検査 {#inspect-data-14} + +プロパティと値のペアを JSON 形式で表示します。 + +#### 例 {#example-7} + +このコンポーネントをコンテキスト内で表示するには、[ECS Task Manager][4] アプリのブループリントを参照してください。 +{{% /collapse-content %}} + + + + +{{% collapse-content title="ラジオボタン" level="h3" %}} +ラジオボタンコンポーネントには、以下のプロパティがあります。 + +#### 一般 {#general-12} + +Label +: コンポーネントの上部に表示されるテキスト。
+**値**: 文字列または式 + +Options +: ユーザーが選択できるラジオボタンオプションのリスト。形式はオブジェクトの配列であり、各オブジェクトは `label` と `value` のキーと値のペアで構成されます。
+**値**: 式
+**例**:
+: ```json + ${[ + { + "label": "Staging", + "value": "staging" + }, + { + "label": "Production", + "value": "production" + } + ]} + ``` + +Default value +: ラジオボタンの読み込み時に選択される値。
+**値**: 文字列または式 + +#### 外観{#appearance-15} + +Is Disabled +: 無効時のスタイルを適用し、操作を無効にします。
+**提示される値**: on、off + +Is Visible +: コンポーネントがユーザーに対して表示されるかどうかを決定します。編集モードでは、すべてのコンポーネントが表示されたままになります。
+**提示される値**: on、off + +#### イベント {#events-9} + +Event +: **値**: change + +Reaction +: **値**: 例: open modal、trigger action、set component state
+すべての利用可能なリアクションは、「[イベント][1]」を参照してください。 + +State Function +: setValue
+**例**: `radioButtons0.setValue("production")` は、`radioButtons0` コンポーネントの値を `"production"` に設定します。
+詳細については、「[状態関数][9]」を参照してください。 + +#### データの検査 {#inspect-data-15} + +プロパティと値のペアを JSON 形式で表示します。 +{{% /collapse-content %}} + + + +{{% collapse-content title="React レンダラー" level="h3" %}} +React レンダラーコンポーネントには、以下のプロパティがあります。 + +#### 一般 {#general-13} + +React Component Definition (React コンポーネント定義) +: React コンポーネントを作成するために実行されるコード。
+ +Component Input Props (コンポーネントの Input Props) +: React コンポーネントに渡され、コンポーネントの props オブジェクトからアクセスできる props。 + +Initial Component State (コンポーネントの初期状態) +: コンポーネントの初期状態の値を設定します。この状態は、コンポーネントが初めてレンダリングされるとき、または状態がまだ設定されていない場合に使用されます。コンポーネントは、 props.stateからこのデータにアクセスできます。
+ +#### 外観 {#appearance-16} + +Is Visible +: コンポーネントがユーザーに対して表示されるかどうかを決定します。編集モードでは、すべてのコンポーネントが表示されたままになります。
+**提示される値**: on、off + +#### イベント {#events-10} +Event +: **値**: set component state、callback function (コールバック関数) + +Function Name (関数名) +: **値**:props.customFunctionName + +Reaction +: **値**: 例: open modal、trigger action、set component state
+すべての利用可能なリアクションは、「[イベント][1]」を参照してください。 + +#### データの検査 {#inspect-data-16} + +プロパティと値のペアを JSON 形式で表示します。 + +#### 関係 {#relationships} + +React レンダラーとアプリ内のコンポーネント間のデータ依存関係を表示します。 + +#### 例 {#example-8} + +このコンポーネントの使用方法を示す例は、「[React レンダラー][11]」を参照してください。 + +{{% /collapse-content %}} + + + +{{% collapse-content title="検索" level="h3" %}} +検索コンポーネントには以下のプロパティがあります。 + +#### 一般 {#general-14} + +Default value +: アプリが検索ボックスに設定するデフォルト値。
+**値**: 文字列または式 + +Placeholder text +: 値が入力されていないときに表示されるテキスト。
+**値**: 文字列または式 + +#### 外観 {#appearance-17} + +Size +: 検索コンポーネントのスケール。
+**提示される値**: sm、md、lg + +Is Loading +: 読み込み中のインジケーターを表示します。
+**提示される値**: on、off + +Is Visible +: コンポーネントがユーザーに対して表示されるかどうかを決定します。編集モードでは、すべてのコンポーネントが表示されたままになります。
+**提示される値**: on、off + +#### イベント {#events-11} + +Event +: **値**: change、submit + +Reaction +: **値**: 例: open modal、trigger action、set component state
+すべての利用可能なリアクションは、「[イベント][1]」を参照してください。 + +State Function +: setValue
+**例**: `search0.setValue("search query")` は、`search0` コンポーネントの値を `"search query"` に設定します。
+詳細については、「[状態関数][9]」を参照してください。 + +イベントの詳細については、「[イベント][1]」を参照してください。 + +#### データの検査 {#inspect-data-17} + +プロパティと値のペアを JSON 形式で表示します。 + +#### 例 {#example-9} + +このコンポーネントをコンテキスト内で表示するには、[EC2 Instance Manager][3] アプリのブループリントを参照してください。 +{{% /collapse-content %}} + +{{% collapse-content title="選択" level="h3" %}} +選択コンポーネントには以下のプロパティがあります。 + +#### 一般 {#general-15} + +Label +: コンポーネントの上部に表示されるテキスト。
+**値**: 文字列または式 + +Placeholder text +: 値が入力されていないときに表示されるテキスト。
+**値**: 文字列または式 + +Options +: ユーザーが選択できる選択肢のリスト。形式はオブジェクトの配列であり、各オブジェクトは `label` と `value` のキーと値のペアで構成されます。
+**値**: 式
+**例**:
+: ```json + ${[ + { + "label": "Staging", + "value": "staging" + }, + { + "label": "Production", + "value": "production" + } + ]} + ``` + +Default value +: 選択肢が読み込まれたときに選択されている値。
+**値**: 文字列または式 + +Is Multiselect (複数選択) +: ユーザーが一度に複数のオプションを選択できるかどうかを指定します。
+**提示される値**: on、off + +#### 外観{#appearance-18} + +Is Disabled +: 無効時のスタイルを適用し、操作を無効にします。
+**提示される値**: on、off + +Is Visible +: コンポーネントがユーザーに対して表示されるかどうかを決定します。編集モードでは、すべてのコンポーネントが表示されたままになります。
+**提示される値**: on、off + +#### イベント {#events-12} + +Event +: **値**: change + +Reaction +: **値**: 例: open modal、trigger action、set component state
+すべての利用可能なリアクションは、「[イベント][1]」を参照してください。 + +State Function +: setValue
+**例**: `select0.setValue("staging")` は、`select0` コンポーネントの値を `"staging"` に設定します。
+詳細については、「[状態関数][9]」を参照してください。 + +#### データの検査 {#inspect-data-18} + +プロパティと値のペアを JSON 形式で表示します。 + +#### 例 {#example-10} + +このコンポーネントをコンテキスト内で表示するには、[Metrics Explorer および Monitors Builder][2] アプリのブループリントを参照してください。 +{{% /collapse-content %}} + + +{{% collapse-content title="サイドパネル" level="h3" %}} +サイドパネルコンポーネントには、以下のプロパティがあります。 + +#### 一般 {#general-16} + +Title +: サイドパネルのタイトル。
+**値**: 文字列 + +#### 外観 {#appearance-19} + +Width (幅) +: サイドパネルの幅を指定します。値の後にパーセント記号 (`%`) を含める必要があります。
+**値**: 整数 + +Hide Close Button (閉じるボタンを非表示) +: サイドパネルを閉じるための X を表示するかどうかを指定します。
+**提示される値**: on、off + +#### イベント {#events-13} + +Event +: **値**: toggle open、close、open + +Reaction +: **値**: 例: open modal、trigger action、set component state
+すべての利用可能なリアクションは、「[イベント][1]」を参照してください。 + +State Function +: setIsOpen
+**例**: `sidePanel0.setIsOpen(true)` は `sidePanel0` の状態を open に設定します。
+詳細については、「[状態関数][9]」を参照してください。 + +#### データの検査 {#inspect-data-19} + +プロパティと値を JSON 形式で表示します。 + +{{% /collapse-content %}} + + +{{% collapse-content title="タブ" level="h3" %}} + +タブコンポーネントには以下のプロパティがあります。 + +#### Tabs (タブ) {#tabs} + +タブビューのリスト。({{< ui >}}+{{< /ui >}}) を使用してビューを追加します。 + + +#### スタイル {#style-1} + +Style +: タブコンポーネントに使用される配色スタイル。
+**提示される値**: Default、purple、pink、orange、red、green + +Alignment (配置) +: タブコンポーネント内でのタブの配置方法。
+**提示される値**: Horizontal (水平)(→)、vertical (垂直) (↓) + +Impact (影響) +: 選択したタブの背景を完全に塗りつぶすか、下部の小さな帯のみに色を付けるかを制御します。
+**提示される値**: High (高)、low (低) + + +#### 外観 {#appearance-20} + +Hide Tabs (タブを非表示) +: タブマーカーを表示するかどうかを制御します。
+**提示される値**: on、off + +Hide Body (ボディを非表示) +: タブのボディを表示するかどうかを制御します。
+**提示される値**: on、off + +Is Visible +: コンポーネントがユーザーに対して表示されるかどうかを決定します。編集モードでは、すべてのコンポーネントが表示されたままになります。
+**提示される値**: on、off + +#### イベント {#events-14} + +Event +: **値**: change + +Reaction +: **値**: 例: open modal、trigger action、set component state
+すべての利用可能なリアクションは、「[イベント][1]」を参照してください。 + +State Function +: setTabIndex
+**例**: `tab0.setTabIndex(0)` は、`tab0` コンポーネントの値を最初のタブに設定します。
+詳細については、「[状態関数][9]」を参照してください。 + +#### データの検査 {#inspect-data-20} + +プロパティと値のペアを JSON 形式で表示します。 + +{{% /collapse-content %}} + +{{% collapse-content title="テーブル" level="h3" %}} + +テーブルコンポーネントには以下のプロパティがあります。 + +#### 一般 {#general-17} + +Title +: テーブルのタイトル。カスタム書式設定の場合は [{{< ui >}}Markdown{{< /ui >}}] (マークダウン) を選択します。
+**値**: 文字列 + +Data source (データソース) +: テーブルに表示するオブジェクトの配列。
+**値**: query (クエリ)、demo data (デモデータ)、components (コンポーネント) + +#### 列 {#columns} + +データソースからの各データ列がここに表示され、以下のプロパティを持ちます。 + +Label +: 列の最上部に表示されるテキスト。
+**値**: 文字列または式 + +Data path (データパス) +: オブジェクトおよび指定された列の配列内にネストされている値にアクセスするための JSON パス。
+**値**: 文字列または式 + +Formatting (書式設定) +: 列に適用される書式の種類。
+**提示される値**: string (文字列)、link (リンク)、status pill (ステータスアイコン)、date / time (日付/時刻)、markdown (マークダウン)、tags (タグ)、percent bar (パーセントバー)、number (数値)、score bar (スコアバー)、avatar (アバター) + +Sortable (並べ替え可能) +: ユーザーが列で並べ替えを行えるかどうかを指定します。
+ +Copyable (コピー可能) +: ユーザーが列の内容をクリックしてコピーできるかどうかを指定します。
+**提示される値**: on、off + +Filterable (フィルタリング可能) +: 列のフィルターオプションが利用可能かどうかを指定します。
+**提示される値**: on、off + +一部の列には、その {{< ui >}}Formatting{{< /ui >}} プロパティに基づく追加のプロパティがあります。 + +#### ページネーション {#pagination} + +Has summary (サマリーを表示) +: テーブルのすぐ上にページネーションのサマリーを表示するかどうかを指定します。
+**提示される値**: on、off + +Page size (ページサイズ) +: 1 ページあたりに表示する行数。
+**値**: 数値、または数値に評価される式 + +Total count (合計数) +: テーブルに表示する行の合計数。
+**値**: 数値、または数値に評価される式 + +Type (タイプ) +: ページネーションのタイプを指定します。
+**提示される値**: client side (クライアントサイド)、server side (サーバーサイド) + +#### 並べ替え {#sorting} + +デフォルトのテーブルの並べ替えに使用する列と方向を選択します。 +Column (列) +: 並べ替えの基準にする列。
+**値**: 列名 + +Direction (方向) +: 並べ替えの方向。
+**提示される値**: ascending (昇順)、descending (降順) + +#### 行アクション {#row-actions} + +行アクションを追加すると、ユーザー定義のアクションボタンを含む [{{< ui >}}Actions{{< /ui >}}] (アクション) 列がテーブルに追加されます。行には複数のアクションを追加できます。アクションには以下のプロパティがあります: + +Label +: アクションボタンに表示されるテキスト。
+**値**: 文字列または式 + +Primary (プライマリ) +: 特定のページやワークフローにおいて、最も重要なアクションにユーザーの注意を向けるために使用します。
+**提示される値**: on、off + +Borderless (枠線なし) +: ボタンから枠線を取り除きます。マウスを重ねると、背景が塗りつぶされます。
+**提示される値**: on、off + +Disabled (無効) +: 無効時のスタイルを適用し、操作を無効にします。
+**提示される値**: on、off + +Level (レベル) +: ボタンの意図に応じて色を制御します。
+**提示される値**: default、danger、success、warning + +Reactions (リアクション) +: ボタンがトリガーするリアクション。ボタンには複数のリアクションを設定できます。
+**提示される値**: download file (ファイルのダウンロード)、open modal、close modal (モーダルを閉じる)、open side panel (サイドパネルを開く)、close side panel (サイドパネルを閉じる)、open URL (URL を開く)、set component state、set state variable value (ステート変数値の設定)、toast notification (トースト通知)、trigger action、custom (カスタム)
+一部のリアクションタイプには追加のプロパティがあります。 + +#### 外観 {#appearance-21} + +Scrollable (スクロール可能) +: テーブルのスクロール方法を指定します。
+**提示される値**: both (両方)、vertical + +Is Loading +: 読み込み中のインジケーターを表示します。
+**提示される値**: on、off + +Has text wrapping (テキストを折り返す) +: セルのテキストを折り返すかどうかを指定します。
+**提示される値**: on、off + +Has subrows (サブ行あり) +: 各行のサブ行を有効にします。データソースに `subRows` プロパティを含めます。
+**提示される値**: on、off + +Is searchable (検索可能) +: テーブルに検索バーを追加するかどうかを指定します。
+**提示される値**: on、off + +Show sort options (並べ替えオプションを表示) +: ユーザーに並べ替えオプションを提供する {{< ui >}}Sort{{< /ui >}} ボタンをテーブルに追加します。
+**提示される値**: on、off + +Show column options (列オプションを表示) +: テーブルの列を表示、非表示にするか、編成し直すための {{< ui >}}Columns{{< /ui >}} ボタンをテーブルに追加します。
+**提示される値**: on、off + +Has date range filter (日付範囲フィルターを追加) +: テーブルに日付範囲フィルターを追加します。
+**提示される値**: on、off + +Is Visible +: コンポーネントがユーザーに対して表示されるかどうかを決定します。編集モードでは、すべてのコンポーネントが表示されたままになります。
+**提示される値**: on、off + +#### イベント {#events-15} + +Event +: **値**: pageChange、tableRowClick + +Reaction +: **値**: 例: open modal、trigger action、set component state
+すべての利用可能なリアクションは、「[イベント][1]」を参照してください。 + +State Function +: setSelectedRow
+**例**:
  • `table0.setSelectedRow(0)` は `table0` の `selectedRow` プロパティを最初の行に設定します。
  • `table0.setSelectedRow(null)` は、`selectedRow` プロパティをクリアします。
+: setPageIndex
+**例**: `table0.setPageIndex(0)` は `table0` の `pageIndex` プロパティを最初のページに設定します。
+詳細については、「[状態関数][9]」を参照してください。 + +#### データの検査 {#inspect-data-21} + +プロパティと値のペアを JSON 形式で表示します。 + +#### 例 {#example-11} + +このコンポーネントをコンテキスト内で表示するには、[Metrics Explorer および Monitors Builder][2] アプリのブループリントを参照してください。 + +テーブルの高度な機能の使用方法を示す例は、「[テーブル][6]」を参照してください。 + +{{% /collapse-content %}} + + + +{{% collapse-content title="テキスト" level="h3" %}} +テキストコンポーネントには、以下のプロパティがあります。 + +#### 一般 {#general-18} + +Content (コンテンツ) +: コンポーネントが表示するコンテンツ。
+**値**: 文字列または式 + +Content type (コンテンツタイプ) +: テキストのレンダリング方法を指定します。[{{< ui >}}Markdown{{< /ui >}}] が選択されている場合、テキストコンポーネントは、外部でホストする画像も含め、[基本のマークダウン構文][8] をサポートします。
+**提示される値**: plain text (プレーンテキスト)、Markdown + +#### 外観 {#appearance-22} + +Text alignment (テキストの配置) +: コンポーネント内でのテキストの水平方向の配置を指定します。
+**提示される値**: align left、align center、align right + +Vertical alignment +: コンポーネント内でのテキストの垂直方向の配置を指定します。
+**提示される値**: align top、align center、align bottom + +Is Visible +: コンポーネントがユーザーに対して表示されるかどうかを決定します。編集モードでは、すべてのコンポーネントが表示されたままになります。
+**提示される値**: on、off + +#### データの検査 {#inspect-data-22} + +プロパティと値のペアを JSON 形式で表示します。 + +#### 関係 {#relationships-1} + +テーブルデータとアプリ内のコンポーネント間のデータ依存関係を表示します。 + +#### 例 {#example-12} + +このコンポーネントをコンテキスト内で表示するには、[Metrics Explorer および Monitors Builder][2] アプリのブループリントを参照してください。 +{{% /collapse-content %}} + + +{{% collapse-content title="テキストエリア" level="h3" %}} +テキストエリアコンポーネントには、以下のプロパティがあります。 + +Label +: コンポーネントの上部に表示されるテキスト。
+**値**: 文字列または式 + +Default value +: テキストエリアが読み込まれたときに選択されている値。
+**値**: 文字列または式 + +Placeholder text +: 値が入力されていないときに表示されるテキスト。
+**値**: 文字列または式 + +#### 外観 {#appearance-23} + +Is Disabled +: 無効にしたスタイルを適用し、操作を無効にします。
+**提示される値**: on、off + +Is Visible +: コンポーネントがユーザーに対して表示されるかどうかを決定します。編集モードでは、すべてのコンポーネントが表示されたままになります。
+**提示される値**: on、off + +#### イベント {#events-16} + +Event +: **値**: change、submit + +Reaction +: **値**: 例: open modal、trigger action、set component state
+すべての利用可能なリアクションは、「[イベント][1]」を参照してください。 + +State Function +: setValue
+**例**: `textArea0.setValue("text")` は、`textArea0` コンポーネントの値を `"text"` に設定します。
+詳細については、「[状態関数][9]」を参照してください。 + +#### データの検査 {#inspect-data-23} + +プロパティと値のペアを JSON 形式で表示します。 +{{% /collapse-content %}} + + +{{% collapse-content title="テキスト入力" level="h3" %}} +テキスト入力コンポーネントには、以下のプロパティがあります。 + +Label +: コンポーネントの上部に表示されるテキスト。
+**値**: 文字列または式 + +Default value +: テキスト入力が読み込まれたときに選択されている値。
+**値**: 文字列または式 + +Placeholder text +: 値が入力されていないときに表示されるテキスト。
+**値**: 文字列または式 + +#### 外観 {#appearance-24} + +Is Disabled +: 無効にしたスタイルを適用し、操作を無効にします。
+**提示される値**: on、off + +Is Visible +: コンポーネントがユーザーに対して表示されるかどうかを決定します。編集モードでは、すべてのコンポーネントが表示されたままになります。
+**提示される値**: on、off + +#### イベント {#events-17} + +Event +: **値**: change、submit + +Reaction +: **値**: 例: open modal、trigger action、set component state
+すべての利用可能なリアクションは、「[イベント][1]」を参照してください。 + +State Function +: setValue
+**例**: `textInput0.setValue("text")` は、`textInput0` コンポーネントの値を `"text"` に設定します。 +詳細については、「[状態関数][9]」を参照してください。 + +#### データの検査 {#inspect-data-24} + +プロパティと値のペアを JSON 形式で表示します。 + +#### 例 {#example-13} + +このコンポーネントをコンテキスト内で表示するには、[Metrics Explorer および Monitors Builder][2] アプリのブループリントを参照してください。 +{{% /collapse-content %}} + + +## 関連資料{#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +
ご質問やご意見がある場合は、[Datadog コミュニティ Slack][5] の {{< ui >}}#app-builder{{< /ui >}} チャンネルにご参加ください。 + + +[1]: /ja/actions/app_builder/events +[2]: https://app.datadoghq.com/app-builder/apps/edit?activeTab=queries&showActionCatalog=false&template=datadog_metrics_and_monitors&viewMode=preview +[3]: https://app.datadoghq.com/app-builder/apps/edit?activeTab=queries&showActionCatalog=false&template=ec2_instance_manager&viewMode=preview +[4]: https://app.datadoghq.com/app-builder/apps/edit?activeTab=queries&showActionCatalog=false&template=ecs_task_manager&viewMode=preview +[5]: https://chat.datadoghq.com/ +[6]: /ja/actions/app_builder/components/tables/ +[7]: /ja/actions/app_builder/expressions +[8]: https://www.markdownguide.org/basic-syntax/ +[9]: /ja/actions/app_builder/events/#state-functions +[10]: /ja/actions/app_builder/components/custom_charts/ +[11]: /ja/actions/app_builder/components/react_renderer/ +[12]: /ja/actions/app_builder/components/reusable_modules/ +[13]: /ja/actions/app_builder/events/#events-and-reactions +[14]: /ja/actions/app_builder/events/#custom-reactions \ No newline at end of file diff --git a/hugo/content/ja/agent/configuration/network.md b/hugo/content/ja/agent/configuration/network.md index dbc877fd16e..e03af6895d5 100644 --- a/hugo/content/ja/agent/configuration/network.md +++ b/hugo/content/ja/agent/configuration/network.md @@ -15,29 +15,29 @@ aliases: further_reading: - link: /getting_started/site tag: ドキュメント - text: Datadog サイトについて + text: Datadog サイトについて学ぶ - link: /logs/ tag: ドキュメント - text: ログの収集 + text: ログを収集する - link: /infrastructure/process tag: ドキュメント - text: プロセスの収集 + text: プロセスを収集する - link: tracing tag: ドキュメント - text: トレースの収集 + text: トレースを収集する title: ネットワークトラフィック --- ## 概要 {#overview}
-トラフィックは常に Agent から Datadog に対して開始されます。Datadog から Agent に対してセッションが開始されることはありません。 +トラフィックは常に Agent から Datadog に対して開始されます。Datadog から Agent へのセッションが開始されることはありません。
-すべての Agent トラフィックは SSL で送信されます。送信先は Datadog サービスとサイトにより異なります。使用している [Datadog サイト][11]の送信先を確認するには、右側の {{< ui >}}DATADOG SITE{{< /ui >}} セレクタをクリックしてください。 +Agent のトラフィックはすべて SSL 経由で送信されます。送信先は Datadog のサービスとサイトにより異なります。使用している [Datadog サイト][11]の送信先を確認するには、右側の [{{< ui >}}DATADOG SITE{{< /ui >}}](Datadog サイト) セレクターをクリックしてください。 ## インストール {#installation} -Agent のインストールを許可するために、下記のドメインを含めるリストに追加してください。 +Agent のインストールを許可するために、以下のドメインをインクルージョンリストに追加してください。 - `install.datadoghq.com` - `yum.datadoghq.com` @@ -59,10 +59,10 @@ Agent のインストールを許可するために、下記のドメインを [LLM 可観測性][23] : `llmobs-intake.`{{< region-param key="dd_site" code="true" >}} -[コンテナイメージ][13] +[Container Images][13] : `contimage-intake.`{{< region-param key="dd_site" code="true" >}} -[ライブコンテナ][3]、[ライブプロセス][4]、[Cloud Network Monitoring][24]、[Universal Service Monitoring][25] +[ライブコンテナ][3]、[Live Processes][4]、[Cloud Network Monitoring][24]、[Universal Service Monitoring][25] : `process.`{{< region-param key="dd_site" code="true" >}} [Network Device Monitoring][10] @@ -72,7 +72,7 @@ Agent のインストールを許可するために、下記のドメインを [Network Path][14] : `netpath-intake.`{{< region-param key="dd_site" code="true" >}}
-Agent v7.75 以降では、Network Path が HTTPS 経由で外部サービスに接続しすることにより、ソースホストの公開 IP を解決します。これはオプションであり、Network Path はそれなしでも機能しますが、ネットワークでアウトバウンドトラフィックが制限されている場合にソースの公開 IP を解決したいなら、次のものを許可リストに追加してください: `icanhazip.com`, `ipinfo.io`, `checkip.amazonaws.com`, `api.ipify.org`, `whatismyip.akamai.com`。詳細については、[Network Path のセットアップ][33] を参照してください。 +Agent v7.75 以降では、Network Path が HTTPS 経由で外部サービスに接続して、ソースホストの公開 IP を解決します。これはオプションであり、この処理なしでも Network Path は機能します。ただし、ご使用のネットワークでアウトバウンドトラフィックが制限されていて、ソースの公開 IP を解決する必要がある場合は、次のものを許可リストに追加してください: `icanhazip.com`、`ipinfo.io`、`checkip.amazonaws.com`、`api.ipify.org`、`whatismyip.akamai.com`。詳細については、[Network Path のセットアップ][33]を参照してください。 [Orchestrator][5] : `orchestrator.`{{< region-param key="dd_site" code="true" >}}
@@ -81,19 +81,19 @@ Agent v7.75 以降では、Network Path が HTTPS 経由で外部サービスに [プロファイリング][7] : `intake.profile.`{{< region-param key="dd_site" code="true" >}} -[Real User Monitoring (RUM)][6] +[RUM (Real User Monitoring)][6] : {{< region-param key="browser_sdk_endpoint_domain" code="true" >}} -[Cloud Security の脆弱性][29] +[Cloud Security Vulnerabilities][29] : `sbom-intake.`{{< region-param key="dd_site" code="true" >}} [Synthetic Monitoring プライベートロケーション][8] -: Synthetics Worker v1.5.0 以降: `intake.synthetics.`{{< region-param key="dd_site" code="true" >}} は、設定する必要がある唯一のエンドポイントです。
-Synthetics Worker < v0.1.6 の API テスト結果: `intake.synthetics.`{{< region-param key="dd_site" code="true" >}}
-Synthetics Worker > v0.2.0 のブラウザテスト結果: `intake-v2.synthetics.`{{< region-param key="dd_site" code="true" >}}
-Synthetics Worker < v0.1.5 の API テスト結果: `api.`{{< region-param key="dd_site" code="true" >}} +: Synthetics Worker v1.5.0 以降:`intake.synthetics.`{{< region-param key="dd_site" code="true" >}} が、設定する必要がある唯一のエンドポイントです。
+v0.1.6 より後の Synthetics Worker の API テスト結果: `intake.synthetics.`{{< region-param key="dd_site" code="true" >}}
+v0.2.0 より後の Synthetics Worker のブラウザテスト結果: `intake-v2.synthetics.`{{< region-param key="dd_site" code="true" >}}
+v0.1.5 より前の Synthetics Worker の API テスト結果: `api.`{{< region-param key="dd_site" code="true" >}} -{{% site-region region="us,eu,us3,us5,ap1,ap2" %}} +{{% site-region region="us,eu,us3,us5,ap1,ap2,uk1" %}} [Remote Configuration][101] : `config.`{{< region-param key="dd_site" code="true" >}} @@ -102,37 +102,42 @@ Synthetics Worker < v0.1.5 の API テスト結果: `api.`{{< region-param key=" : `dbm-metrics-intake.`{{< region-param key="dd_site" code="true" >}}
`dbquery-intake.`{{< region-param key="dd_site" code="true" >}} +[End User Device Monitoring][103] +: `softinv-intake.`{{< region-param key="dd_site" code="true" >}}
+`eudm-intake.`{{< region-param key="dd_site" code="true" >}} + [101]: /ja/remote_configuration [102]: /ja/database_monitoring/ +[103]: /ja/infrastructure/end_user_device_monitoring/ {{% /site-region %}} {{% logs-tcp-disclaimer %}} -[ログ][30] & [HIPAA ログ][31] +[ログ][30]、[HIPAA ログ][31] : (非推奨) TCP:{{< region-param key=tcp_endpoint code="true" >}}
HTTP:{{< region-param key=agent_http_endpoint code="true" >}}
-その他: [ログエンドポイント][32] を参照してください。 +その他: 「[ログエンドポイント][32]」を参照してください。 [HIPAA ログレガシー][31] (非推奨、TCP はサポートされていません) : {{< region-param key=hipaa_logs_legacy code="true" >}} [メトリクス][26]、[サービスチェック][27]、[イベント][28]、およびその他の Agent メタデータ : `-app.agent.`{{< region-param key="dd_site" code="true" >}}
-たとえば、Agent v7.31.0 は `7-31-0-app.agent.` に報告します。{{< region-param key="dd_site" code="true" >}}`*.agent.` を、{{< region-param key="dd_site" code="true" >}} ファイアウォールのインクルージョンリストに追加す必要があります。
-v6.1.0 以降、Agent は Datadog の API にもクエリを実行、重要ではない機能 (たとえば、構成された API キーの有効性の表示など) 提供します。
+たとえば、Agent v7.31.0 は `7-31-0-app.agent.` に報告します{{< region-param key="dd_site" code="true" >}}。`*.agent.` を{{< region-param key="dd_site" code="true" >}} ファイアウォールのインクルージョンリストに追加する必要があります。
+v6.1.0 以降、Agent は Datadog の API にもクエリを送信し、重要度の低い機能 (構成された API キーの有効性の表示など) を提供します:
Agent v7.18.0 または 6.18.0 以降: `api.`{{< region-param key="dd_site" code="true" >}}
-Agent < v7.18.0 または 6.18.0: `app.`{{< region-param key="dd_site" code="true" >}} +Agent v7.18.0 または 6.18.0 より前: `app.`{{< region-param key="dd_site" code="true" >}} [Agent フレア][12] : `-flare.agent.`{{< region-param key="dd_site" code="true" >}}
-たとえば、Agent v7.31.0 は `7-31-0-flare.agent.` にフレアデータを送信します。{{< region-param key="dd_site" code="true" >}}`*.agent.` を、{{< region-param key="dd_site" code="true" >}} ファイアウォールのインクルージョンリストに追加す必要があります。
+たとえば、Agent v7.31.0 は `7-31-0-flare.agent.` にフレアデータを送信します{{< region-param key="dd_site" code="true" >}}。`*.agent.` を{{< region-param key="dd_site" code="true" >}} ファイアウォールのインクルージョンリストに追加する必要があります。
### 静的 IP アドレス {#static-ip-addresses} -これらのドメインはすべて、**CNAME** レコードであり、一連の静的 IP アドレスを指しています。これらのアドレスは `https://ip-ranges.` で見つけることができます{{< region-param key="dd_site" code="true" >}}で設定します。 +これらのドメインはすべて **CNAME** レコードであり、一連の静的 IP アドレスを指しています。これらのアドレスは `https://ip-ranges.`{{< region-param key="dd_site" code="true" >}}で確認できます。 -この情報は、次のスキーマに従って JSON として構造化されます。 +この情報は、以下のスキーマに従って JSON として構造化されます。 {{< code-block lang="text" disable_copy="true" >}} { @@ -159,24 +164,24 @@ Agent < v7.18.0 または 6.18.0: `app.`{{< region-param key="dd_site" code="tru } {{< /code-block >}} -各セクションには専用のエンドポイントがあります。例: +各セクションには専用のエンドポイントがあります。たとえば、次のようなものです。 -- `https://ip-ranges.{{< region-param key="dd_site" >}}/logs.json` は、TCP 経由でログデータを受信するために使用される IP のためのものです。 -- `https://ip-ranges.{{< region-param key="dd_site" >}}/apm.json` は、APM データを受信するために使用される IP のためのものです。 +- `https://ip-ranges.{{< region-param key="dd_site" >}}/logs.json` (TCP 経由でログデータを受信するために使用される IP 用)。 +- `https://ip-ranges.{{< region-param key="dd_site" >}}/apm.json` (APM データを受信するために使用される IP 用)。 ### インクルージョン {#inclusion} -すべての `ip-ranges` をインクルージョンリストに追加してください。特定の時点ではサブセットだけがアクティブですが、定期的なネットワーク操作や保守のために、セット全体の中では時間が経つとバリエーションがでてきます。 +すべての `ip-ranges` をインクルージョンリストに追加してください。特定の時点でアクティブなのは一部のみですが、定期的なネットワーク操作や保守により、セット全体の中では時間の経過とともにアクティブなアドレスが変化します。 ## ポートを開く {#open-ports}
すべてのアウトバウンドトラフィックは、TCP または UDP を介して SSL 経由で送信されます。

-ファイアウォールルールや同様のネットワーク制限を使用して、Agent があなたのアプリケーションや信頼できるネットワークソースからのみアクセスできることを確認してください。信頼できないアクセスは、悪意のある行為者が侵入的な行動を行うことを許してしまう可能性があります。これには、あなたの Datadog アカウントにトレースやメトリクスを書き込むことや、あなたの構成やサービスに関する情報を取得することが含まれますが、これに限定されません。 +ファイアウォールルールや同様のネットワーク制限を使用して、ご使用のアプリケーションや信頼できるネットワークソースのみが Agent にアクセスできるようにしてください。信頼できないソースにアクセスを与えると、悪意のあるアクターが侵害行為を行えるようになるおそれがあります。このような行為には、Datadog アカウントへのトレースとメトリクスの書き込み、構成やサービスに関する情報の取得などがありますが、これらに制限されません。
-**Agent** のすべての機能を利用するには、下記のポートを開いてください。 +**Agent** のすべての機能を利用するには、以下のポートを開いてください。 #### アウトバウンド {#outbound} @@ -184,10 +189,11 @@ Agent < v7.18.0 または 6.18.0: `app.`{{< region-param key="dd_site" code="tru | 製品/機能 | ポート | プロトコル | 説明 | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Agent
APM
コンテナ
Live Processes
Metrics
Cloud Network Monitoring
Universal Service Monitoring | 443 | TCP | ほとんどの Agent のデータはポート 443 を使用します。 | -| [カスタム Agent オートスケーリング][22] | 8443 | TCP | | -| ログ収集 | {{< region-param key=web_integrations_port >}} | (非推奨) TCP | TCP 経由のログ記録。
**注**: TCP ログ収集は**サポートされていません**。Datadog は、TCP の使用で**配信や信頼性を保証していません**。ログデータは予告なく失われる可能性があります。信頼性のある取り込みにするために、HTTP インテークエンドポイント、公式の Datadog Agent、または代わりにフォワーダーインテグレーションを使用してください。他の接続タイプについては、[ログエンドポイント][21]を参照してください。| -| NTP | 123 | UDP | Network Time Protocol (NTP).[デフォルトの NTP ターゲット][20] を参照してください。
NTP のトラブルシューティングに関する情報は、[NTP の問題][19] を参照してください。 | +| Agent
APM
Containers
Live Processes
メトリクス
Cloud Network Monitoring
Universal Service Monitoring | 443 | TCP | ほとんどの Agent データはポート 443 を使用します。 | +| [カスタム Agent オートスケーリング][22]| 8443| TCP| | +| ログ収集 | {{< region-param key=web_integrations_port >}} | (非推奨) TCP | TCP 経由のロギング。
**注**: TCP ログ収集は**サポートされていません**。Datadog は、TCP の使用に関して**配信や信頼性を保証していません**。そのため、ログデータが予告なく失われる可能性があります。取り込みの信頼性を確保するためには、代わりに HTTP インテークエンドポイント、公式の Datadog Agent、またはフォワーダーインテグレーションを使用してください。その他の接続タイプについては、「[ログエンドポイント][21]」を参照してください。| +| NTP | 123 | UDP | NTP (Network Time Protocol)。[デフォルトの NTP ターゲット][20]を参照してください。
NTP のトラブルシューティングの詳細については、「[NTP に関する問題][19]」を参照してください。 | +| 接続テスト | 8042 | TCP | リモート構成の接続テスト。
**注**: これはプロトコル開発用の顧客データが含まれないテレメトリエンドポイントであり、[リモート構成][101]が有効な場合にのみ使用されます。 [19]: /ja/agent/faq/network-time-protocol-ntp-offset-issues/ [20]: /ja/integrations/ntp/#overview @@ -196,12 +202,12 @@ Agent < v7.18.0 または 6.18.0: `app.`{{< region-param key="dd_site" code="tru {{% /site-region %}} -{{% site-region region="us3,us5,gov,gov2,ap1,ap2" %}} +{{% site-region region="us3,us5,gov,gov2,ap1,ap2,uk1" %}} -| 製品/機能 | ポート | プロトコル | 説明 | +| 製品/機能 | ポート | プロトコル | 説明 | | ------------------------------------------------------------------------------------------------------------------- | ---- | -------- | ---------------------------------------------------------------------------------------------------------------------------- | -| Agent
APM
コンテナ
Live Processes
Metrics
Cloud Network Monitoring
Universal Service Monitoring | 443 | TCP | ほとんどの Agent のデータはポート 443 を使用します。 | -| NTP | 123 | UDP | Network Time Protocol (NTP).[デフォルトの NTP ターゲット][20] を参照してください。
NTP のトラブルシューティングに関する情報は、[NTP の問題][19] を参照してください。| +| Agent
APM
Containers
Live Processes
メトリクス
Cloud Network Monitoring
Universal Service Monitoring | 443 | TCP | ほとんどの Agent データはポート 443 を使用します。 | +| NTP | 123 | UDP | NTP (Network Time Protocol)。[デフォルトの NTP ターゲット][20]を参照してください。
NTP のトラブルシューティングの詳細については、「[NTP に関する問題][19]」を参照してください。| [19]: /ja/agent/faq/network-time-protocol-ntp-offset-issues/ [20]: /ja/integrations/ntp/#overview @@ -210,22 +216,22 @@ Agent < v7.18.0 または 6.18.0: `app.`{{< region-param key="dd_site" code="tru #### インバウンド {#inbound} -Agent のサービスがホスト内のローカルで相互に通信する場合にのみ使用されます。 +ホスト内でのローカル通信のみを行う Agent サービスで使用されます。 | 製品/機能 | ポート | プロトコル | 説明 | | ---------------------------- | ---- | -------- | ------------------------------------------------------------------------------------------------------------------------------ | -| [Agent ブラウザGUI][16] | 5002 | TCP | | +| [Agent ブラウザ GUI][16] | 5002 | TCP | | | APM レシーバー | 8126 | TCP | トレーシングとプロファイラーを含みます。 | -| [DogStatsD][18] | 8125 | UDP | DogStatsD 用のポート、ただし `dogstatsd_non_local_traffic` が true に設定されている場合は除く。このポートは IPv4 ローカルホストで利用可能です: `127.0.0.1`。| -| go_expvar サーバー (APM) | 5012 | TCP | 詳細については、[go_expar インテグレーションのドキュメント][15] を参照してください。 | -| go_expvar インテグレーションサーバー | 5000 | TCP | 詳細については、[go_expar インテグレーションのドキュメント][15] を参照してください。 | -| IPC API | 5001 | TCP | プロセス間通信 (IPC) に使用されるポート。 | +| [DogStatsD][18] | 8125 | UDP | DogStatsD 用のポート (`dogstatsd_non_local_traffic` が true に設定されている場合を除く)。このポートは IPv4 ローカルホストで利用可能です: `127.0.0.1`。| +| go_expvar サーバー (APM) | 5012 | TCP | 詳細については、[go_expvar インテグレーションのドキュメント][15]を参照してください。 | +| go_expvar インテグレーションサーバー | 5000 | TCP | 詳細については、[go_expvar インテグレーションのドキュメント][15]を参照してください。 | +| IPC API | 5001 | TCP | IPC (プロセス間通信) に使用されるポート。 | | Process Agent のデバッグ | 6062 | TCP | Process Agent のデバッグエンドポイント。 | -| Process Agent ランタイム | 6162 | TCP | Process Agent のランタイム構成。 | +| Process Agent ランタイム | 6162 | TCP | Process Agent のランタイム構成の設定。 | ## ポートの構成 {#configure-ports} -既存のサービスがネットワーク上でデフォルトポートを使用しているために、受信ポートを変更する必要がある場合は、`datadog.yaml` 構成ファイルを編集します。ほとんどのポートは、このファイルの **Advanced Configuration** セクションにあります: +既存のサービスがネットワーク上ですでにデフォルトポートを使用しているために、受信ポートを変更する必要がある場合は、`datadog.yaml` 構成ファイルを編集します。ほとんどのポートは、このファイルの **Advanced Configuration** セクションで確認できます。 {{< code-block lang="yaml" filename="datadog.yaml" disable_copy="true" collapsible="true" >}} ## @param expvar_port - integer - optional - default: 5000 @@ -253,7 +259,7 @@ Agent のサービスがホスト内のローカルで相互に通信する場 {{< /code-block >}} -APM レシーバーと DogStatsD のポートは、`datadog.yaml` 構成ファイルの、それぞれ **Trace Collection Configuration** セクションと **DogStatsD Configuration** セクションにあります。 +APM レシーバーのポートは `datadog.yaml` 構成ファイルの **Trace Collection Configuration** セクションで、DogStatsD ポートは **DogStatsD Configuration** セクションで確認できます。 {{< code-block lang="yaml" filename="datadog.yaml" disable_copy="true" collapsible="true" >}} ## @param dogstatsd_port - integer - optional - default: 8125 @@ -273,30 +279,30 @@ APM レシーバーと DogStatsD のポートは、`datadog.yaml` 構成ファ # receiver_port: 8126 {{< /code-block >}} -
ここで DogStatsD ポートまたは APM レシーバーポートの値を変更した場合は、対応するポートの Datadog SDK の構成も変更する必要があります。ポートの構成に関する情報は、お使いの言語のライブラリ構成ドキュメントを参照してください。
+
ここで DogStatsD ポートまたは APM レシーバーポートの値を変更した場合は、対応するポートの Datadog SDK の構成も変更する必要があります。ポートの構成の詳細については、お使いの言語のライブラリ構成ドキュメントを参照してください。
## プロキシの使用 {#using-proxies} -プロキシの設定に関する詳細な構成ガイドについては、[Agent プロキシ構成][9]を参照してください。 +プロキシの設定に関する詳細な構成ガイドは、「[Agent プロキシの構成][9]」を参照してください。 ## データバッファリング {#data-buffering} ネットワークが利用できなくなると、Agent はメトリクスをメモリに保存します。 メトリクスを保存するための最大メモリ使用量は、`forwarder_retry_queue_payloads_max_size` 構成の設定によって定義されます。この制限に達すると、メトリクスは破棄されます。 -Agent の v7.27.0 以降では、メモリ制限に達した場合にディスクにメトリクスを保存します。この機能を有効にするには、`forwarder_storage_max_size_in_bytes` に、Agent がディスクにメトリクスを保存するために使用できる最大ストレージスペース (バイト単位) を示す正の値を設定してください。 +Agent v7.27.0 以降では、メモリ制限に達した場合、ディスクにメトリクスを保存します。この機能を有効にするには、`forwarder_storage_max_size_in_bytes` に、Agent がディスクにメトリクスを保存するために使用できる最大ストレージ容量 (バイト数) を示す正の値を設定してください。 メトリクスは、`forwarder_storage_path` の設定で定義されるフォルダーに保存されます。デフォルトは、Unix システムでは `/opt/datadog-agent/run/transactions_to_retry`、Windows では `C:\ProgramData\Datadog\run\transactions_to_retry` です。 -ストレージスペースが不足しないように、Agent は使用されている総ストレージスペースが 80 パーセント未満の場合にのみメトリクスをディスクに保存します。この制限は `forwarder_storage_max_disk_ratio` の設定によって定義されます。 +ストレージ容量が不足することがないように、Agent は使用されている総ストレージ容量が 80 パーセント未満の場合にのみメトリクスをディスクに保存します。この制限は `forwarder_storage_max_disk_ratio` の設定によって定義されます。 ## Datadog Operator のインストール {#installing-the-datadog-operator} -限られた接続性を持つ Kubernetes 環境に Datadog Operator をインストールする場合は、レジストリに基づいて TCP ポート 443 の下記のエンドポイントを許可リストに追加する必要があります: +接続が制限されている Kubernetes 環境に Datadog Operator をインストールする場合は、ご使用のレジストリに基づいて TCP ポート 443 の下記のエンドポイントを許可リストに追加する必要があります。 -- `registry.datadoghq.com` (Datadog-Container レジストリ) +- `registry.datadoghq.com` (Datadog コンテナレジストリ) - `us-docker.pkg.dev/datadog-prod/public-images` (`registry.datadoghq.com` からのリダイレクトを受け取る場合があります) -- `gcr.io/datadoghq` (GCR US) +- `gcr.io/datadoghq` (GCR 米国) - `eu.gcr.io/datadoghq` (GCR ヨーロッパ) - `asia.gcr.io/datadoghq` (GCR アジア) - `datadoghq.azurecr.io` (Azure) diff --git a/hugo/content/ja/api/latest/agent-observability/batch-update-agent-observability-dataset-records/index.md b/hugo/content/ja/api/latest/agent-observability/batch-update-agent-observability-dataset-records/index.md new file mode 100644 index 00000000000..0b0a97b2a61 --- /dev/null +++ b/hugo/content/ja/api/latest/agent-observability/batch-update-agent-observability-dataset-records/index.md @@ -0,0 +1,3 @@ +--- +title: Agent Observability データセットのレコードを一括更新します +--- diff --git a/hugo/content/ja/api/latest/agent-observability/get-a-custom-evaluator-configuration/index.md b/hugo/content/ja/api/latest/agent-observability/get-a-custom-evaluator-configuration/index.md new file mode 100644 index 00000000000..753102aa9ef --- /dev/null +++ b/hugo/content/ja/api/latest/agent-observability/get-a-custom-evaluator-configuration/index.md @@ -0,0 +1,3 @@ +--- +title: カスタム評価設定の取得 +--- diff --git a/hugo/content/ja/api/latest/agent-observability/get-an-agent-observability-prompt/index.md b/hugo/content/ja/api/latest/agent-observability/get-an-agent-observability-prompt/index.md new file mode 100644 index 00000000000..d631b668af7 --- /dev/null +++ b/hugo/content/ja/api/latest/agent-observability/get-an-agent-observability-prompt/index.md @@ -0,0 +1,3 @@ +--- +title: Agent Observabilityのプロンプトを取得してください +--- diff --git a/hugo/content/ja/api/latest/agent-observability/get-annotation-queue-label-schema/index.md b/hugo/content/ja/api/latest/agent-observability/get-annotation-queue-label-schema/index.md new file mode 100644 index 00000000000..e4cebf27da6 --- /dev/null +++ b/hugo/content/ja/api/latest/agent-observability/get-annotation-queue-label-schema/index.md @@ -0,0 +1,3 @@ +--- +title: アノテーションキューのラベルスキーマを取得します +--- diff --git a/hugo/content/ja/api/latest/agent-observability/list-agent-observability-datasets/index.md b/hugo/content/ja/api/latest/agent-observability/list-agent-observability-datasets/index.md new file mode 100644 index 00000000000..d43bf5ab309 --- /dev/null +++ b/hugo/content/ja/api/latest/agent-observability/list-agent-observability-datasets/index.md @@ -0,0 +1,3 @@ +--- +title: Agent Observabilityデータセットを一覧表示する +--- diff --git a/hugo/content/ja/api/latest/agent-observability/list-events-for-an-agent-observability-experiment/index.md b/hugo/content/ja/api/latest/agent-observability/list-events-for-an-agent-observability-experiment/index.md new file mode 100644 index 00000000000..ac58904f93c --- /dev/null +++ b/hugo/content/ja/api/latest/agent-observability/list-events-for-an-agent-observability-experiment/index.md @@ -0,0 +1,3 @@ +--- +title: Agent Observability実験のイベントを一覧表示する +--- diff --git a/hugo/content/ja/api/latest/agent-observability/list-versions-of-an-agent-observability-prompt/index.md b/hugo/content/ja/api/latest/agent-observability/list-versions-of-an-agent-observability-prompt/index.md new file mode 100644 index 00000000000..5fb28360c72 --- /dev/null +++ b/hugo/content/ja/api/latest/agent-observability/list-versions-of-an-agent-observability-prompt/index.md @@ -0,0 +1,3 @@ +--- +title: Agent Observabilityプロンプトのバージョンを一覧表示します +--- diff --git a/hugo/content/ja/api/latest/data-deletion/cancels-a-data-deletion-request/index.md b/hugo/content/ja/api/latest/data-deletion/cancels-a-data-deletion-request/index.md new file mode 100644 index 00000000000..d906edc86a9 --- /dev/null +++ b/hugo/content/ja/api/latest/data-deletion/cancels-a-data-deletion-request/index.md @@ -0,0 +1,3 @@ +--- +title: Cancels a data deletion request +--- diff --git a/hugo/content/ja/api/latest/execution-policy/get-an-execution-policy/index.md b/hugo/content/ja/api/latest/execution-policy/get-an-execution-policy/index.md new file mode 100644 index 00000000000..be1ac4c48f2 --- /dev/null +++ b/hugo/content/ja/api/latest/execution-policy/get-an-execution-policy/index.md @@ -0,0 +1,3 @@ +--- +title: 実行ポリシーを取得してください +--- diff --git a/hugo/content/ja/api/latest/product-analytics/compute-journey-scalar-analytics/index.md b/hugo/content/ja/api/latest/product-analytics/compute-journey-scalar-analytics/index.md new file mode 100644 index 00000000000..8bfbdc8306b --- /dev/null +++ b/hugo/content/ja/api/latest/product-analytics/compute-journey-scalar-analytics/index.md @@ -0,0 +1,3 @@ +--- +title: ジャーニーのスカラー分析を計算する +--- diff --git a/hugo/content/ja/api/latest/product-analytics/list-the-entities-behind-a-retention-cell/index.md b/hugo/content/ja/api/latest/product-analytics/list-the-entities-behind-a-retention-cell/index.md new file mode 100644 index 00000000000..26e4e1a06af --- /dev/null +++ b/hugo/content/ja/api/latest/product-analytics/list-the-entities-behind-a-retention-cell/index.md @@ -0,0 +1,3 @@ +--- +title: リテンションセルの背後にあるエンティティを一覧表示してください。 +--- diff --git a/hugo/content/ja/containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd.md b/hugo/content/ja/containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd.md new file mode 100644 index 00000000000..aba65107d70 --- /dev/null +++ b/hugo/content/ja/containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd.md @@ -0,0 +1,280 @@ +--- +description: Pod のアノテーションではなく DatadogInstrumentation カスタムリソースを使用して、Kubernetes ワークロードの + Autodiscovery のチェックおよびログ収集を設定します。 +further_reading: +- link: /containers/kubernetes/integrations/ + tag: ドキュメント + text: Autodiscovery によるインテグレーションの設定 +- link: /getting_started/containers/autodiscovery/ + tag: ドキュメント + text: Autodiscovery の利用を開始する +- link: /containers/guide/autodiscovery-examples/ + tag: ドキュメント + text: Autodiscovery のシナリオと例 +- link: /containers/cluster_agent/ + tag: ドキュメント + text: Datadog Cluster Agent +title: DatadogInstrumentation CRD を使用した Autodiscovery の設定 +--- +## 概要{#overview} + +`DatadogInstrumentation` カスタムリソース (CR) を使用すると、[Pod アノテーション][2] ではなく、単一の Kubernetes リソースで [Autodiscovery][1] のチェックとログ収集を設定できます。このアプローチでは、Agent やアプリケーションを編集してロールアウトをトリガーすることなく、インテグレーション設定の有効化、更新、削除を行うことができます。 + +次のような場合に `DatadogInstrumentation` CR を使用します。 + +- ワークロードマニフェストを変更したりアノテーションを追加したりせずに、チェックとログ収集を設定する場合。 +- アノテーション内の生の JSON ではなく、検証機能を持つ構造化されたリソース仕様を使用する場合。 +- ワークロードごとの Autodiscovery 設定を、専用のバージョン管理された Kubernetes リソースとして一元管理する場合。 +- アプリケーション Pod を再起動せずに、Autodiscovery 設定を更新または削除する場合。 + +`DatadogInstrumentation` リソースを作成または更新すると、[Datadog Cluster Agent][3] がターゲットを検証し、リソースのステータスを報告して、ターゲットのワークロードに Autodiscovery 設定を適用します。 + +## 要件 {#requirements} + +Datadog Agent および Cluster Agent を **v7.82 以降**にアップグレードし、以下のいずれかの方法で `DatadogInstrumentation` CRD をインストールします。 +- Datadog Operator **v1.29** 以降。 +- Datadog Helm chart **v3.236.0** 以降。 + +## セットアップ {#setup} + +`DatadogInstrumentation` コントローラーは Cluster Agent 内で実行され、デフォルトでは無効になっています。Datadog Operator または Helm を使用して有効にします。 + +{{< tabs >}} +{{% tab "Datadog Operator" %}} + +1. Helm リポジトリを更新します。 + +```shell +helm repo update +``` + +2. Datadog Operator をアップグレードします。 + +```shell +helm upgrade datadog-operator datadog/datadog-operator +``` + +3. `DatadogAgent` リソースに `agent.datadoghq.com/instrumentation-crd-enabled` アノテーションを追加します。Cluster Agent は v7.82.0 以降である必要があります。 + +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog + annotations: + agent.datadoghq.com/instrumentation-crd-enabled: "true" +spec: + global: + [...] +``` + +4. 変更を適用します。 + +```shell +kubectl apply -f datadog-agent.yaml +``` + +Operator は、必要な Cluster Agent および Node Agent の環境変数を設定し、Cluster Agent に必要な RBAC を自動的に構成します。 + +{{% /tab %}} +{{% tab "Helm" %}} + +1. Helm リポジトリを更新します。 + +```shell +helm repo update +``` + +2. `datadog-values.yaml` ファイルで、コントローラーを有効にします。 + +```yaml +datadog: + instrumentationCrd: + enabled: true +``` + +3. リリースをアップグレードします。 + +```shell +helm upgrade -f datadog-values.yaml datadog/datadog +``` + +{{% /tab %}} +{{< /tabs >}} + +リソースを作成する前に、`DatadogInstrumentation` CRD がインストールされていることを確認してください。 + +```shell +kubectl get crd datadoginstrumentations.datadoghq.com +``` + +Datadog CRD を個別に管理している場合は、Datadog CRD Helm チャートをインストールまたはアップグレードしてください。 + +```shell +helm upgrade --install datadog-crds datadog/datadog-crds +``` + +## 対象ワークロード {#target-workloads} + +Autodiscovery 用の `DatadogInstrumentation` (DDI) は、次の 3 つの要素で構成されます。 + +- `spec.targetRef`: `apiVersion`、`kind`、および `name` を指定して、構成するワークロードを特定します。カスタムリソースと対象ワークロードは、同じ名前空間に存在する必要があります。 +- `spec.config.checks`: ワークロードに対して実行するインテグレーションチェックを定義します。 +- `spec.config.logs`: ワークロードから収集するログを定義します。 + +次の Kubernetes リソースを対象に指定できます。 + +| 対象 | グループ/バージョン/リソース | 最小 Agent バージョン | 注 | +|---|---|---|---| +| Deployment | `apps/v1/deployments` | 7.82.0 | | +| DaemonSet | `apps/v1/daemonsets` | 7.82.0 | | +| StatefulSet | `apps/v1/statefulsets` | 7.82.0 | | +| CronJob | `batch/v1/cronjobs` | 7.82.0 | | +| Job | `batch/v1/jobs` | 7.82.0 | | +| Service | `core/v1/services` | 7.82.0 | チェックのみをサポートします。「[対象 Service](#target-services)」を参照してください。| +| Rollout | `argoproj.io/v1alpha1/rollouts` | 7.83.0 | [Argo Rollouts][7] が必要です。| + +この例では、`redis` という名前の `StatefulSet` に対して [Redis インテグレーション][4] を設定します。これは [アノテーションベースの例][2] と同じ設定です。 + +```yaml +apiVersion: datadoghq.com/v1alpha1 +kind: DatadogInstrumentation +metadata: + name: + namespace: +spec: + targetRef: + apiVersion: apps/v1 + kind: StatefulSet + name: redis + config: + checks: + - integration: redisdb + containerName: redis + initConfig: {} + instances: + - host: "%%host%%" + port: "6379" + password: "%%env_REDIS_PASSWORD%%" + logs: + - containerName: redis + tags: + - env:demo +``` + +リソースを適用します。 + +```shell +kubectl apply -f redis-instrumentation.yaml +``` + +リソースのステータスを確認します。 + +```shell +kubectl describe datadoginstrumentation -n +``` + +`checks` の各エントリは、次のフィールドを受け入れます。 + +`integration` +: 必須。実行する Datadog インテグレーションの名前 (例: `redisdb`)。 + +`containerName` +: ワークロードを対象とする場合は必須。値は、Pod 内のコンテナ名と一致する必要があります。Service を対象とする場合は、このフィールドを省略します。 + +`initConfig` +: 任意。インテグレーションの `init_config` セクション。 + +`instances` +: 任意。チェックのインスタンス設定。各インスタンスは、`%%host%%` を含む [Autodiscovery テンプレート変数][5] を使用できます。 + +`logs` の各エントリでは、`tags`、`type`、`path` など、Autodiscovery のログアノテーションと同じログ収集オプションを指定できます。各エントリには、Pod 内のコンテナと一致する `containerName` が必要です。 + +### 対象 Service{#target-services} + +`Service` を対象にすると、Kubernetes Service のアノテーションと同様の [エンドポイントチェック][6] が設定されます。 + +- Datadog は、Service の各エンドポイントに対して 1 つずつエンドポイントチェックをスケジュールします。 +- `%%host%%`はエンドポイントの IP に解決されます。 +- エンドポイントが Kubernetes Pod によってバックアップされている場合、Datadog はその Pod について収集された Pod タグを追加します。 +- エンドポイントが Pod によってバックアップされていない場合、Datadog はそのチェックを Pod 固有のタグを持たない通常のクラスターチェックに変換します。 + +
+ +Service を対象とする場合、`containerName` は使用しません。このフィールドは省略してください。 + +
+ +以下は、Kubernetes の `Service` に対して nginx チェックを設定する例です。 + +```yaml +apiVersion: datadoghq.com/v1alpha1 +kind: DatadogInstrumentation +metadata: + name: + namespace: +spec: + targetRef: + apiVersion: v1 + kind: Service + name: nginx + config: + checks: + - integration: nginx + initConfig: {} + instances: + - name: "My NGINX Service Endpoints" + nginx_status_url: "http://%%host%%:%%port%%/status/" +``` + +## 優先順位{#precedence} + +複数の設定ソースがワークロードに適用される場合、Datadog Agent は次の順序で解決します (優先順位が高い順): + +1. Pod アノテーション +2. `DatadogInstrumentation` カスタムリソース +3. 静的設定 (自動設定やマウントされたファイルなど) + +ワークロードにチェックやログ収集のためのアノテーションベースの Autodiscovery 設定がすでに存在する場合、`DatadogInstrumentation` の設定によって上書きされることはありません。 + +## 対象ごとに 1 つのリソース {#one-resource-per-target} + +1 つのワークロードまたは Service は、1 つの名前空間内の 1 つの`DatadogInstrumentation`リソースのみを対象にできます。検証 Webhook は、`targetRef` がすでに別のリソースに属しているか、`targetRef` がサポートされていない種類を指しているリソースを拒否します。 + +## スケジュールされたチェックを確認する {#verify-scheduled-checks} + +リソースのステータスには、Cluster Agent が構成を受け入れたかどうかが表示されます。チェックがスケジュールされていることを確認するには、対象ワークロードが実行されている Node Agent で`agent configcheck` を実行します。 + +`DatadogInstrumentation` リソースを通じて構成されたチェックには、構成プロバイダーとして `instrumentation-checks`、構成ソースとして`datadoginstrumentation:/` が一覧表示されます。次の例は、Redis ワークロードを対象とするリソースからスケジュールされた `redisdb` チェックの出力を示しています。 + +```text +> agent configcheck +# other configs... + +=== redisdb check === +Configuration provider: instrumentation-checks +Configuration source: datadoginstrumentation:cache/redis-instrumentation +Config for instance ID: redisdb:d5dd267b580bc10e +host: 10.244.0.7 +password: "********" +port: 6379 +Init Config: +{} +Log Config: +- tags: + - env:demo +Auto-discovery IDs: +* redis +``` + +## 関連資料{#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ja/getting_started/containers/autodiscovery/ +[2]: /ja/containers/kubernetes/integrations/ +[3]: /ja/containers/cluster_agent/ +[4]: /ja/integrations/redisdb/ +[5]: /ja/containers/guide/template_variables/ +[6]: /ja/containers/cluster_agent/endpointschecks/ +[7]: https://argoproj.github.io/rollouts/ \ No newline at end of file diff --git a/hugo/content/ja/incident_response/work_management/approvals.md b/hugo/content/ja/incident_response/work_management/approvals.md new file mode 100644 index 00000000000..cfcaee882a2 --- /dev/null +++ b/hugo/content/ja/incident_response/work_management/approvals.md @@ -0,0 +1,60 @@ +--- +aliases: +- /ja/incident_response/case_management/approvals/ +further_reading: +- link: /incident_response/work_management/automation_rules + tag: ドキュメント + text: 作業項目の自動化ルール +- link: /incident_response/work_management + tag: ドキュメント + text: 作業管理 +title: 作業項目の承認 +--- +## 概要 {#overview} + +作業項目の承認機能は変更管理ワークフローをサポートするも機能で、作業項目に対してアクションを実行する前に 1 人以上のチームメンバーから承認を得ることができます。この機能は、すべての標準およびカスタム作業タイプで使用できます。すべての承認アクティビティは、作業項目のアクティビティタイムラインで追跡されます。 + +## 承認依頼 {#requesting-approvals} + +作業項目で承認を依頼するには、次の手順を実行します。 +1. 作業項目から、右側にある **More Options** アイコンをクリックします。 +1. **Request approval** を選択します。 +1. **Add reviewer** ドロップダウンを使用して、1 人以上のユーザーを選択します。 +1. (オプション) **Describe your request** フィールドにメッセージを入力します。 +1. **Request** をクリックします。 + +**注**: レビュー担当者が応答した後は、依頼を編集できません。 + +承認を依頼すると、作業項目の詳細パネルに **Reviewers** セクションが表示されます。各レビュー担当者の名前と現在のステータス (依頼済み、承認済み、または却下済み) が表示されます。レビュー担当者リストを変更するには、**Reviewers** の横にある編集アイコンをクリックします。すべての承認イベントは、作業項目のアクティビティタイムラインに記録されます。 + +### Notifications {#notifications} + +- 承認が依頼されると、承認者にメールで通知されます。 +- 承認または却下を受け取るたびに、依頼者に通知されます。 + +### 権限 {#permissions} + +| アクション | 必要な権限 | +|---|---| +| 作業項目の承認を依頼する | ケースの書き込み | +| 作業項目の承認者として追加される | ケースの読み取り | +| 作業項目を承認または却下する | ケースの読み取り | + +詳細については、[Datadog ロール権限][2] を参照してください。 + +## 自動化ルール {#automation-rules} + +作業項目の承認イベントに基づいて、作業項目の自動化ルールをトリガーできます。たとえば、すべての承認が完了した時点で作業項目のステータスを自動的に更新するワークフローをトリガーできます。 + +利用可能なトリガーは以下のとおりです。 +- 作業項目の最初の承認、各承認、またはすべての承認 +- 作業項目の最初の却下または各却下 + +設定手順については、[作業項目の自動化ルール][1] を参照してください。 + +## 関連資料{#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ja/incident_response/work_management/automation_rules +[2]: /ja/account_management/rbac/permissions/#case-and-incident-management \ No newline at end of file diff --git a/hugo/content/ja/integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose.md b/hugo/content/ja/integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose.md index 586048731b1..7ded44728ca 100644 --- a/hugo/content/ja/integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose.md +++ b/hugo/content/ja/integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose.md @@ -1,117 +1,130 @@ --- +description: 低レイテンシーで取り込むために、Amazon Data Firehose を介して CloudWatch メトリクスを Datadog にストリーミングします。 further_reading: - link: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Metric-Streams.html - tag: Documentation + tag: ドキュメント text: メトリクスストリーム - Amazon CloudWatch - link: https://www.datadoghq.com/blog/amazon-cloudwatch-metric-streams-datadog/ tag: ブログ - text: メトリクススストリームを使用して Amazon CloudWatch メトリクスを収集する -title: Amazon Data Firehose を使用した AWS CloudWatch メトリクスストリーム + text: メトリクスストリームを使用して Amazon CloudWatch メトリクスを収集する +title: AWS CloudWatch Metric Streams と Amazon Data Firehose --- -{{% site-region region="us3,gov" %}} -選択した Datadog サイト ({{< region-param key="dd_site_name" >}}) では AWS CloudWatch Metric Streams with Amazon Data Firehose は利用できません。 -{{% /site-region %}} +AWS CloudWatch Metric Streams と Amazon Data Firehose を使用すると、わずか 2 ～ 3 分のレイテンシーで CloudWatch メトリクスを Datadog に取り込むことができます。これは、10 分ごとにメトリクスを更新する Datadog のデフォルトの API ポーリングアプローチよりも大幅に高速です。API ポーリングアプローチの詳細については、[Cloud Metric Delay ドキュメント][1] を参照してください。 -Amazon CloudWatch メトリクスストリームと Amazon Data Firehose を使用すると、CloudWatch メトリクスを 2〜3 分のレイテンシーで Datadog に取り込むことができます。これは、Datadog のデフォルトの API ポーリングアプローチよりも大幅に高速で、デフォルトのアプローチではメトリクスが 10 分ごとに更新されます。API ポーリングアプローチについて、詳しくは[クラウドメトリクスの遅延に関するドキュメント][1]でご確認ください。 +## 概要 {#overview} -## 概要 +{{< img src="integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose/metric_streaming_diagram.png" alt="メトリクスのフロー図" responsive="true">}} -{{< img src="integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose/metric_streaming_diagram.png" alt="メトリクスフロー図" responsive="true">}} +1. メトリクスをストリーミングする各 AWS アカウントおよびリージョンで、CloudWatch Metric Stream を作成します。 + - オプションで、ストリーミングする名前空間またはメトリクスのセットを制限できます。 +2. Metric Stream を作成すると、Datadog は直ちにストリーミングされたメトリクスの受信を開始し、追加の設定なしで Datadog サイトに表示します。 -1. メトリクスをストリーミングする各 AWS アカウントとリージョンに CloudWatch メトリクスストリームを作成します。 - - オプションで、ストリーミングするためのネームスペースまたはメトリクスの限定されたセットを指定します。 -2. メトリクスストリームを作成すると、Datadog はストリーミングされたメトリクスの受信をすぐに開始し、追加の構成を必要とせずにそれらを Datadog サイトに表示します。 +
AWS インテグレーションタイルで設定されたタグフィルタリングは、CloudWatch Metric Streams にも適用されます。
-
AWS インテグレーションタイルで構成されたネームスペースフィルタリングは、CloudWatch メトリクスストリームには適用されません。詳細は以下をご覧ください。
+### Metric Streaming と API ポーリングの比較 {#streaming-vs-polling} -### メトリクスストリーミングと API ポーリングの比較 {#streaming-vs-polling} +CloudWatch Metric Streams を使用する場合と API ポーリングを使用する場合の主な違いは以下のとおりです。 -CloudWatch Metric Streams と API ポーリングの主な相違点は以下の通りです。 +- **2 時間以上遅延して報告されるメトリクス**: メトリクスストリーミングを有効にした後も、API ポーリングは `aws.s3.bucket_size_bytes` や `aws.billing.estimated_charges` のようなメトリクスの収集を継続します。これらは CloudWatch Metric Stream を通じて送信できないためです。 -- **AWS でのネームスペースフィルタリング**: AWS インテグレーションページのネームスペースごとのデフォルトとアカウントレベルの設定は、API ポーリングアプローチにのみ適用されます。AWS アカウントの CloudWatch メトリクスストリーム設定を使用して、ストリームにネームスペース/メトリクスを含めたり除外したりするためのすべてのルールを管理します。 +- **メトリクスのメタデータ**: Datadog は引き続き API ポーリングを使用して、ストリーミングされたメトリクスのカスタムタグやその他のメタデータを収集します。これらのメトリクスを確実に受信し続けるため、AWS インテグレーションの設定は変更しないでください。 -- **2 時間以上遅れて報告されるメトリクス**: API ポーリングは、CloudWatch Metric Stream を通して送ることができないため、メトリクスストリーミングを有効にした後も `aws.s3.bucket_size_bytes` や `aws.billing.estimated_charges` などのメトリクスを収集し続けます。 +#### API ポーリングからメトリクスストリームへの切り替え {#switching-from-api-polling-to-metric-streams} +特定の CloudWatch 名前空間のメトリクスを API ポーリング方式ですでに受信している場合、Datadog はこれを自動的に検出し、ストリーミングを開始するとその名前空間のメトリクスのポーリングを停止します。Datadog は引き続き API ポーリングを使用してストリーミングされたメトリクスのカスタムタグやその他のメタデータを収集するため、AWS インテグレーションページの設定は変更しないでください。 -#### API ポーリングからメトリクスストリームへの切り替え -API ポーリングメソッドを通じて特定の CloudWatch ネームスペースのメトリクスを既に受け取っている場合、Datadog は自動的にこれを検出し、ストリーミングを開始するとそのネームスペースのメトリクスポーリングを停止します。Datadog は引き続き API ポーリングを使用して、ストリームされたメトリクスに対してカスタムタグや他のメタデータを収集するため、AWS インテグレーションページの構成設定は変更しないままにしておきます。 +#### メトリクスストリームから API ポーリングへの切り替え {#switching-back-from-metric-streams-to-api-polling} -#### メトリクスストリームから API ポーリングに戻る +後で特定の AWS アカウントとリージョン、あるいは特定の名前空間のメトリクスをストリーミングしたくないと判断した場合、Datadog は AWS インテグレーションページの設定に基づいて、API ポーリングを使用したそれらのメトリクスの収集を自動的に再開します。AWS アカウントとリージョンのすべてのメトリクスのストリーミングを停止する場合は、本書の [Metric Streaming セクションを無効にする](#disable-metric-streaming)の手順に従います。 -AWS アカウントやリージョン、あるいは特定のネームスペースのメトリクスをストリーミングしたくないと後で判断した場合、Datadog は自動的に AWS インテグレーションページの構成設定に基づいて、API ポーリングを使用してそれらのメトリクスの収集を再び開始します。AWS アカウントとリージョンのすべてのメトリクスのストリーミングを停止したい場合は、本ドキュメントの[メトリクスストリーミングを無効にするのセクション](#disable-metric-streaming)の指示に従います。 +#### 移行中のメトリクスの重複の回避 {#avoiding-duplicate-metrics-during-migration} -### 課金 +API ポーリングからメトリクスストリームに移行する際、両方の収集方式が同じメトリクスのデータを送信する重複期間が発生します。これにより、Datadog でメトリクスの値が 2 倍になって表示される可能性があります。 -メトリクスをストリーミングするための Datadog からの追加料金はありません。 +重複を最小限に抑えるには、次の手順を実行します。 +1. 目的の名前空間とリージョンに対して Metric Streams を有効にします。 +2. Datadog がストリームを検出し、それらの名前空間のポーリングを停止するまで待ちます。この検出には最大 5 分かかる場合がありますが、実際にはアクティブなポーリングクローラーのタイミングによって重複期間がこれより長くなる可能性があります。 +3. アクティブ化されたストリームリージョンについて、[AWS インテグレーションページ][5] の **Metric Collection** タブを確認し、移行が完了したことを検証します。 +4. 移行中は、既存の AWS インテグレーション設定を変更しないでください。Datadog は引き続き API ポーリングを使用して、ストリーミングされたメトリクスのカスタムタグとメタデータを収集します。 -AWS は、CloudWatch メトリクスストリームのメトリクスアップデートの数および Amazon Data Firehose に送信されたデータ量に基づいて課金します。そのため、ストリーミングしている特定のメトリクスに関して CloudWatch コストが増加する可能性があります。このため、Datadog は、より低いレイテンシーが必要な AWS メトリクス、サービス、リージョン、およびアカウントにメトリクスストリームを使用し、それ以外にはポーリングを使用することを推奨します。詳細については、[Amazon CloudWatch の価格設定][2]を参照してください。 +
+一部のメトリクスは CloudWatch Metric Streams 経由で送信できません。これには以下が含まれます。 aws.s3.bucket_size_bytes および aws.billing.estimated_charges。Datadog は、メトリクスストリームの設定に関係なく、これらを API ポーリング経由で引き続き収集します。 +
-ストリーム内の EC2 または Lambda メトリクスは、請求対象のホストと Lambda 呼び出しの数を増やす可能性があります (EC2 の場合、これらのホストと関数が AWS インテグレーションまたは Datadog Agent でまだ監視されていない場合)。 +### 請求 {#billing} -## セットアップ +Datadog からメトリクスをストリーミングする場合、追加料金は発生しません。 -### はじめに +AWS は、CloudWatch Metric Stream でのメトリクス更新数と、Amazon Data Firehose に送信されるデータ量に基づいて課金します。そのため、ストリーミングしているメトリクスのサブセットに対して、CloudWatch のコストが増加する可能性があります。このため、Datadog では、低レイテンシーが最も必要な AWS メトリクス、サービス、リージョン、アカウントに対してはメトリクスストリームを使用し、それ以外についてはポーリングを使用することを推奨しています。詳細については、[Amazon CloudWatch の料金][2] を参照してください。 -1. [Metric Streaming と API ポーリングの比較](#streaming-vs-polling)のセクションをよく読んで、Metric Streaming を有効にする前に違いを理解してください。 +ストリーム内の EC2 または Lambda メトリクスは、課金対象のホスト数や Lambda 呼び出し数を増加させる可能性があります (これらのホストや関数が AWS インテグレーションや EC2 の場合の Datadog Agent によってまだ監視されていない場合)。 -2. まだ接続していない場合は、AWS アカウントを Datadog に接続します。詳細については、[CloudFormation のセットアップ手順][3]を参照してください。 +**注**: CloudWatch でフィルターを作成し、指定したメトリクスのみをストリーミングすることができます。詳細については、[Amazon CloudWatch ユーザーガイド][7] を参照してください。 -### インストール +## セットアップ {#setup} + +### 開始する前に {#before-you-begin} + +1. [Metric Streaming と API ポーリング](#streaming-vs-polling)セクションをよく読み、Metric Streaming を有効にする前にその違いを理解してください。 + +2. まだ接続していない場合は、AWS アカウントを Datadog に接続します。詳細については、[CloudFormation セットアップ手順][3] を参照してください。 + +### インストール {#installation} {{< tabs >}} {{% tab "CloudFormation" %}} -複数の AWS リージョンを使用している場合は自動的かつ簡単になるため、Datadog では CloudFormation の使用をお勧めします。 - -**注**: Datadog へのメトリクスストリーミングは現在、OpenTelemetry v0.7 出力フォーマットのみをサポートしています。 - -1. Datadog サイトで、[AWS インテグレーションページ][1]の **Configuration** タブに移動します。 -2. AWS アカウントをクリックして、メトリクスストリーミングを設定します。 -3. **Metric Collection** の下、**CloudWatch Metric Streams** の下にある **Automatically Using CloudFormation** をクリックし、AWS コンソールでスタックを起動させます。 - {{< img src="integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose/metric-stream-setup.png" alt="AWS インテグレーションページの Metric Collection タブの CloudWatch Metric Streams セクションで、Automatically Using CloudFormation ボタンをハイライトした状態" responsive="true" style="width:60%;" >}} -4. 必要なパラメータを入力します。 - - **ApiKey**: [Datadog API キー][2]を追加します。 - - **DdSite**: [Datadog サイト][3]を選択します。サイトは次のとおりです: {{< region-param key="dd_site" code="true" >}} - - **Regions**: メトリクスストリーミング用に設定するリージョンのコンマ区切りのリスト。サポートされるリージョンの完全なリストについては、AWS のドキュメント[メトリクスストリームを使用する][4]を参照してください。 -5. オプションのパラメータを入力します。 - - **FilterMethod**: メトリクスストリーミングに含めるネームスペースのリストを含めるか除外します。 - - **First/Second/Third Namespace**: 含めるまたは除外するネームスペースを指定します。注: ネームスペースの値は、AWS のドキュメントのネームスペース列の値と正確に一致する必要があります。例: AWS/EC2。 -6. "I acknowledge that AWS CloudFormation might create IAM resources with custom names." (AWS CloudFormation がカスタム名で IAM リソースを作成する可能性があることを認めます) という確認ボックスをオンにします。 +Datadog では、CloudFormation の使用を推奨しています。自動化されていて複数の AWS リージョンを使用している場合に容易であるためです。 + +**注**: メトリクスストリーミングは、OpenTelemetry 出力形式のみをサポートしています。最新バージョンは v1.0 です。v0.7 もサポートされていますが、メトリクスが欠落する可能性があります。 + +1. Datadog サイトで、[AWS インテグレーションページ][1] の **Configuration** タブに移動します。 +2. メトリクスストリーミングを設定する AWS アカウントをクリックします。 +3. **Metric Collection** の下にある **CloudWatch Metric Streams** の **Automatically Using CloudFormation** をクリックして、AWS コンソールでスタックを起動します。 + {{< img src="integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose/metric-stream-setup.png" alt="AWS インテグレーションページのメトリクス収集タブにある CloudWatch Metric Streams セクション。Automatically Using CloudFormation ボタンが強調表示されています。" responsive="true" style="width:60%;" >}} +4. 必要なパラメーターを入力します。 + - **ApiKey**: [Datadog API キー][2] を追加します。 + - **DdSite**: [Datadog サイト][3] を選択します。サイト:{{< region-param key="dd_site" code="true" >}} + - **Regions**: メトリクスストリーミング用に設定するリージョンのカンマ区切りの一覧。サポートされているリージョンの全一覧については、[メトリクスストリームの使用][4] 関する AWS ドキュメントを参照してください。 +5. オプションのパラメーターを入力します。 + - **FilterMethod**: メトリクスストリーミングに含める名前空間の一覧を含めるか除外するかを選択します。 + - **First/Second/Third Namespace**: 含める、または除外する名前空間を指定します。注: 名前空間の値は、AWS ドキュメントの名前空間列にある値と正確に一致している必要があります。例: AWS/EC2。 +6. 「AWS CloudFormation がカスタム名で IAM リソースを作成する可能性があることを認識しています」という確認ボックスにチェックを入れます。 7. **Create Stack** をクリックします。 -### 結果 +### 結果 {#results} -スタックが正常に作成されたら、Datadog が変更を認識するまで 5 分ほど待ちます。完了を確認するには、Datadog の [AWS インテグレーションページ][1]の **Metric Collection** タブに移動し、選択したアカウントに対してアクティブ化したリージョンが表示されることを確認します。 +スタックが正常に作成されたら、Datadog が変更を認識するまで 5 分間待ちます。完了を確認するには、Datadog の [AWS インテグレーションページ][1] の **Metric Collection** タブに移動し、選択したアカウントに対して有効化されたリージョンが表示されていることを確認します。 -{{< img src="integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose/active-region.png" alt="AWS インテグレーションページの Metric Collection タブの CloudWatch Metric Streams セクションで、1 つのリージョンがアクティブになっている状態" responsive="true" style="width:60%;">}} +{{< img src="integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose/active-region.png" alt="AWS インテグレーションページの Metric Collection タブにある CloudWatch Metric Streams セクション。1 つのリージョンが有効化されています" responsive="true" style="width:60%;">}} [1]: https://app.datadoghq.com/integrations/amazon-web-services [2]: https://app.datadoghq.com/organization-settings/api-keys [3]: /ja/getting_started/site/ [4]: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Metric-Streams.html {{% /tab %}} -{{% tab "AWS コンソール" %}} +{{% tab "AWS Console" %}} -AWS Console を使用してメトリクスストリームをセットアップするには、各 AWS リージョンに対して [CloudWatch メトリクスストリーム][1]を作成します。 +AWS Console を使用してメトリクスストリームを設定するには、各 AWS リージョンに対して [CloudWatch Metric Stream][1] を作成します。 -**注**: Datadog へのメトリクスストリーミングは現在、OpenTelemetry v0.7 出力フォーマットのみをサポートしています。 +**注**: メトリクスストリーミングは、OpenTelemetry 出力形式のみをサポートしています。最新バージョンは v1.0 です。v0.7 もサポートされていますが、メトリクスが欠落する可能性があります。 -1. **Quick AWS Partner Setup** を選択し、ドロップダウンメニューから AWS パートナーの宛先として **Datadog** を選択します。 - {{< img src="integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose/metric-stream-partner-setup.png" alt="Cloudwatch メトリクスストリームのクイックパートナセットアップ" responsive="true" style="width:60%;">}} -2. メトリクスをストリーミングする Datadog サイトを選択し、[Datadog API キー][2]を入力します。 -3. すべての CloudWatch メトリクスをストリーミングするか、特定のネームスペースのみをストリーミングするかを選択します。また、特定のメトリクスを除外するオプションもあります。モニタリングアカウントの場合は、[クロスアカウントストリーミング][3]を有効にすることもできます。 - {{< img src="integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose/metric-stream-namespace-filter.png" alt="Cloudwatch メトリクスストリーム" responsive="true" style="width:60%;">}} -4. **Add additional statistics** では、Datadog に送信する AWS のパーセンタイルメトリクスを含みます。Datadog がポーリングでサポートするパーセンタイルメトリクスの一覧は、[CloudFormation テンプレート][4]を参照してください。 +1. **Quick AWS Partner Setup** を選択し、ドロップダウンメニューから AWS パートナーの送信先として **Datadog** を選択します。 + {{< img src="integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose/metric-stream-partner-setup.png" alt="CloudWatch メトリクスストリームのクイックパートナーセットアップ" responsive="true" style="width:60%;">}} +2. メトリクスのストリーミング先となる Datadog サイトを選択し、[Datadog API キー][2] を入力します。 +3. すべての CloudWatch メトリクスをストリーミングするか、特定の名前空間のみをストリーミングするかを選択します。特定のメトリクスを除外するオプションもあります。Monitoring Account を使用している場合は、[クロスアカウントストリーミング][3] を有効にすることもできます。 + {{< img src="integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose/metric-stream-namespace-filter.png" alt="CloudWatch メトリクスストリーム" responsive="true" style="width:60%;">}} +4. **統計情報を追加する**の下で、Datadog に送信する AWS パーセンタイルメトリクスを含めます。Datadog がポーリングを通じてサポートするパーセンタイルメトリクスの一覧については、[CloudFormation テンプレート][4] を参照してください。 {{< img src="integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose/percentiles.png" alt="パーセンタイル" responsive="true" style="width:60%;">}} -5. メトリクスストリームに名前を付けます。 -6. **Create metric stream** をクリックします。 +5. メトリクスストリームに名前を割り当てます。 +6. **メトリクスストリームを作成する** をクリックします。 -### 結果 +### 結果 {#results-1} -Metric Stream リソースが正常に作成されたことを確認したら、Datadog が変更を認識するまで 5 分ほど待ちます。完了を確認するには、Datadog の [AWS インテグレーションページ][5]の **Metric Collection** タブを開き、指定した AWS アカウントの **CloudWatch Metric Streams** で有効化したリージョンが有効になっていることを確認します。 +Metric Stream リソースが正常に作成されたことを確認したら、Datadog が変更を認識するまで 5 分間待機します。完了を確認するには、Datadog の [AWS インテグレーションページ][5] の **Metric Collection** タブに移動し、指定した AWS アカウントの **CloudWatch Metric Streams** で有効なリージョンが有効になっていることを確認します。 -{{< img src="integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose/active-region.png" alt="AWS インテグレーションページの Metric Collection タブの CloudWatch Metric Streams セクションで、1 つのリージョンがアクティブになっている状態" responsive="true" style="width:60%;">}} +{{< img src="integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose/active-region.png" alt="AWS インテグレーションページの Metric Collection タブにある CloudWatch Metric Streams セクション。1 つのリージョンが有効化されています" responsive="true" style="width:60%;">}} -**注**: CloudWatch API のポーリングをすでに有効にしている場合、ストリーミングへの移行により、ストリーミングしている特定のメトリクスが Datadog で二重にカウントされる短い期間 (最大 5 分) が発生する可能性があります。これは、Datadog のクローラーが実行されて CloudWatch メトリクスを送信するタイミングと、Datadog がこれらのメトリクスのストリーミングを開始したことを認識してクローラーをオフにするタイミングが異なるためです。 +**注**: CloudWatch API のポーリングをすでに有効にしている場合、ストリーミングへの移行により、ストリーミングしている特定のメトリクスが Datadog で二重にカウントされる短い期間 (最大 5 分) が発生する可能性があります。これは、Datadog のクローラーが CloudWatch メトリクスを実行および送信するタイミングと、Datadog がそれらのメトリクスのストリーミングを開始したことを認識してクローラーをオフにするタイミングの差によるものです。 [1]: https://console.aws.amazon.com/cloudwatch/home?region=us-east-1#metric-streams:streams/create [2]: https://app.datadoghq.com/organization-settings/api-keys @@ -121,33 +134,79 @@ Metric Stream リソースが正常に作成されたことを確認したら、 {{% /tab %}} {{< /tabs >}} -### クロスアカウントメトリクスストリーミング -AWS リージョン内の複数の AWS アカウントにまたがる単一のメトリクストリームにメトリクスを含めるには、クロスアカウントメトリクストリーミングを使用します。これにより、共通の宛先にメトリクスを収集するために必要なストリームの数を減らすことができます。これを行うには、モニタリングアカウントに[ソースアカウントを接続][4]し、AWS モニタリングアカウントで Datadog へのクロスアカウントストリーミングを有効にします。 +### クロスアカウントメトリクスストリーミング {#cross-account-metric-streaming} +クロスアカウントメトリクスストリーミングを使用して、単一の AWS リージョン内の複数の AWS アカウントにまたがるメトリクスを 1 つの Metric Stream に含めます。これは、共通の送信先に対してメトリクスを収集するために必要なストリーム数を削減する上で役立ちます。これを行うには、[ソース][4] アカウントを接続し、AWS 監視アカウントで Datadog へのクロスアカウントストリーミングを有効にします。 -この機能を正しく動作させるには、モニタリングアカウントに以下の権限が必要です。 +この機能が正しく動作するためには、監視アカウントに以下の権限が必要です。 * oam:ListSinks * oam:ListAttachedLinks -**注:** ストリーミングされたメトリクスのカスタムタグやその他のメタデータを収集するには、ソースアカウントを Datadog とインテグレーションしてください。 +**注:** ストリーミングされたメトリクスのカスタムタグやその他のメタデータを収集するには、ソースを Datadog と統合します。 + +### メトリクスストリーミングを無効にする {#disable-metric-streaming} + +特定の AWS アカウントおよびリージョンのメトリクスストリーミングを完全に無効にするには、AWS Metric Stream とその関連リソースを削除する必要があります。Datadog でのメトリクスの損失を防ぐため、以下の削除手順に注意深く従うことが重要です。 + +[CloudFormation](?tab=cloudformation#installation) を使用してストリーミングを設定した場合: +1. セットアップ中に作成されたスタックを削除します。 + +[AWS Console](?tab=awsconsole#installation) からストリーミングを設定した場合: +1. 配信ストリームにリンクされている CloudWatch Metric Stream を削除します。 +2. ストリームのセットアップ時に作成されたすべてのリソース (ストリームに関連付けられている S3 および Firehose 用の IAM ロールを含む) を削除します。 + +リソースが削除されたら、Datadog が変更を認識するまで 5 分間待機します。完了を確認するには、Datadog の [AWS インテグレーションページ][5] の**メトリクス収集**タブに移動し、指定した AWS アカウントの **CloudWatch Metric Streams** の下に無効にしたリージョンが表示されていないことを確認します。 + +### ストリームの健全性を監視する {#monitor-stream-health} + +Datadog は、CloudWatch メトリクスストリームからデータを受信すると `datadog.aws_metric_streams.data_received` メトリクスを送信します。このメトリクスを使用して、AWS がメトリクスを送信しており、Datadog がそれを受信していることを確認します。 + +`datadog.aws_metric_streams.data_received` +: **タイプ**: ゲージ
+Datadog が CloudWatch メトリクスストリームからデータを受信したときに `1` の値を報告し、データを受信しない場合は報告しません。`stream_arn`、`stream_name`、`aws_account`、および `region` でタグ付けされます。メトリクスが報告される頻度は、データ量と Firehose 配信ストリームのバッファリング設定によって異なります。 + +クロスアカウントストリームの場合、メトリクスストリームと Firehose 配信ストリームは監視アカウント内にあります。`aws_account` タグは、メトリクスが収集されるソースアカウントではなく、監視アカウントを識別します。 + +ストリームがデータを配信しているかどうかをチェックするには、[Metrics Explorer][8] でこのメトリクスをクエリし、`stream_name` または `stream_arn` でグループ化します。 + +メトリクスはストリームがデータの配信を停止したときには報告されないため、報告状態からデータなしの状態への移行を監視します。[メトリクスモニター][9] を `datadog.aws_metric_streams.data_received` で作成し、`stream_arn` でグループ化して、データ欠落の通知を有効にします。設定手順については、[特定のタグが報告を停止した際のアラートの設定][10] を参照してください。 + +## トラブルシューティング {#troubleshooting} + +Metric Streams または関連リソースの設定中に問題が発生した場合は、[AWS トラブルシューティング][6] を参照してください。Metric Streams が正常に実行されていた後に CloudWatch メトリクスが表示されなくなった場合、問題の原因は Firehose 配信先のエラーである可能性があります。 + +### Firehose 配信先で発生する永続的なエラー {#persistent-firehose-destination-errors} + +CloudWatch メトリクスが Datadog に表示されなくなった場合でも、CloudWatch Metric Stream と Amazon Data Firehose 配信ストリームは `running` 状態を示している可能性があります。これは、Firehose がレコードを配信していない場合でも発生することがあります。 -### メトリクスストリーミングを無効にする +これは、Firehose が [再試行期間][11] 内に Datadog HTTP エンドポイントへレコードを配信できず、かつ S3 バックアップへレコードを書き込めない場合に発生します。両方の配信パスが失敗すると、エンドポイントが再び利用可能になっても、配信ストリームが自動的に HTTP 配信を再開しないことがあります。 -特定の AWS アカウントとリージョンに対してメトリクスストリーミングを完全に無効にするには、AWS メトリクスストリームとその関連リソースを削除する必要があります。Datadog のメトリクスの損失を防ぐために、これらの削除手順に注意深く従うことが重要です。 +配信を診断して復旧するには、以下を行います。 -[CloudFormation](?tab=cloudformation#installation) でストリーミングを設定した場合: -1. セットアップ時に作成されたスタックを削除します。 +1. 影響を受けている CloudWatch Metric Stream に関連付けられた Firehose 配信ストリームを特定します。次の AWS CLI コマンドを実行して、レスポンス内で `FirehoseArn` を見つけます。 -[AWS コンソール](?tab=awsconsole#installation)からストリーミングを設定した場合: -1. 配信ストリームにリンクしている CloudWatch Metric Stream を削除します。 -2. ストリームに関連付けられた S3 および Firehose IAM ロールを含め、ストリームのセットアップ中に作成されたすべてのリソースを削除します。 + ```shell + aws cloudwatch get-metric-stream \ + --name \ + --region + ``` -リソースが削除されたら、Datadog が変更を認識するまで 5 分ほど待ちます。完了を確認するには、Datadog の [AWS インテグレーションページ][5]の **Metric Collection** タブを開き、指定した AWS アカウントの **CloudWatch Metric Streams** に無効にしたリージョンが表示されていないことを確認します。 +2. CloudWatch Logs で [Firehose 配信エラーログ][12] を確認します。配信エラーログが有効になっていない場合は、将来の配信エラーをキャプチャできるように有効にします。関連するエラーには、`HttpEndpoint.DestinationException` (HTTP 408 レスポンスなど) や `S3.AccessDenied` が含まれます。 +3. CloudWatch コンソールで [Firehose CloudWatch メトリクス][13] を確認します (配信が中断されている間、Datadog ではこれらのメトリクスが表示されない場合があります)。`DeliveryToHttpEndpoint.Success`、`DeliveryToHttpEndpoint.DataFreshness`、`DeliveryToHttpEndpoint.Records`、および `IncomingRecords` をチェックします。 +4. Firehose がレコードを受信しても配信されない場合は、S3 バックアップ構成と IAM ロールをチェックします。 + - Firehose が設定されたロールを引き受け、バックアップバケットに書き込めることをチェックします。 + - バケットポリシー、権限の境界、サービスコントロールポリシー (SCP)、および KMS キーポリシーが必要なアクセスを拒否していないことをチェックします。 +5. Firehose 配信ストリームの S3 バックアップ設定で構成されたプレフィックスの下にあるバックアップバケットをチェックし、レコードが S3 に到達しているかどうかをチェックします。オブジェクトが書き込まれていない場合は、S3 バックアップパスの権限または設定に問題があることが確認されます。ステップ 2 の配信エラーログに S3 の権限エラーが表示されている場合は、続行する前に修正します。 +6. Firehose [UpdateDestination API][14] を使用して Firehose HTTP 送信先設定を更新します (例: 再試行時間を変更するなど)。このような構成の更新により、停止した送信先を再起動できる場合があります。 -## トラブルシューティング +配信が回復しない場合は、[DDatadog Support][15] に連絡し、以下の情報を提供します。 + - AWS アカウント ID およびリージョン + - CloudWatch Metric Stream および Firehose 配信ストリームの ARN + - 配信が停止したおおよその時刻 + - 関連する Firehose エラーログ -Metric Streams や関連リソースのセットアップで遭遇する問題を解決するには、[AWS のトラブルシューティング][6]をご覧ください。 +**注**: 配信の再起動は新しいレコードにのみ影響し、停止中に失敗したレコードをバックフィル (再取り込み) することはありません。S3 バックアップに書き込まれたレコードは、自動的に Datadog に取り込まれることはありません。 -## その他の参考資料 +## 関連資料{#further-reading} {{< partial name="whats-next/whats-next.html" >}} [1]: /ja/integrations/guide/cloud-metric-delay/ @@ -155,4 +214,13 @@ Metric Streams や関連リソースのセットアップで遭遇する問題 [3]: /ja/integrations/amazon_web_services/?tab=roledelegation#setup [4]: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account-Setup.html [5]: https://app.datadoghq.com/integrations/amazon-web-services -[6]: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-metric-streams-troubleshoot.html \ No newline at end of file +[6]: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-metric-streams-troubleshoot.html +[7]: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Metric-Streams.html +[8]: https://app.datadoghq.com/metric/explorer +[9]: /ja/monitors/types/metric/ +[10]: /ja/monitors/guide/set-up-an-alert-for-when-a-specific-tag-stops-reporting/ +[11]: https://docs.aws.amazon.com/firehose/latest/dev/retry.html +[12]: https://docs.aws.amazon.com/firehose/latest/dev/monitoring-with-cloudwatch-logs.html +[13]: https://docs.aws.amazon.com/firehose/latest/dev/monitoring-with-cloudwatch-metrics.html#fh-http-metrics +[14]: https://docs.aws.amazon.com/firehose/latest/APIReference/API_UpdateDestination.html +[15]: /ja/help/ \ No newline at end of file diff --git a/hugo/content/ja/llm_observability/instrument/_index.md b/hugo/content/ja/llm_observability/instrument/_index.md new file mode 100644 index 00000000000..75c3eca5c3f --- /dev/null +++ b/hugo/content/ja/llm_observability/instrument/_index.md @@ -0,0 +1,84 @@ +--- +aliases: +- /ja/llm_observability/instrumentation/ +description: Python、Node.js、Java 向けの SDK ベースおよび API ベースの方法を含む、Agent Observability + のインスツルメンテーションオプションの概要。 +further_reading: +- link: /llm_observability/auto_instrumentation + tag: 自動インスツルメンテーション + text: 自動インスツルメンテーションをすぐに利用する +- link: https://www.datadoghq.com/blog/llm-otel-semantic-convention + tag: ブログ + text: Datadog LLM Observability は、OpenTelemetry GenAI セマンティック規約をネイティブにサポートしています。 +- link: https://learn.datadoghq.com/courses/llm-obs-getting-started + tag: ラーニングセンター + text: Agent Observability の概要 +title: Agent Observability のインスツルメンテーション +--- +Agent Observability を初めて使用する場合は、ご使用のプログラミング言語とセットアップに基づいて複数のインスツルメンテーション方法の中から選択し、LLM アプリケーションまたはエージェントをインスツルメントします。Datadog は、最小限のコード変更で LLM アプリケーションやエージェントから詳細なトレース、メトリクス、評価をキャプチャするための、包括的なインスツルメンテーションオプションを提供します。 + +## インスツルメンテーションオプション {#instrumentation-options} +Python、Node.js、または Java SDK を使用するか、Agent Observability API を使用してアプリケーションをインスツルメントできます。 + +### SDK ベースのインスツルメンテーション (推奨) {#sdk-based-instrumentation-recommended} +Datadog のネイティブ SDK は、最も包括的な Agent Observability 機能を提供します。 +| 言語 | 利用可能な SDK | 自動インスツルメンテーション | カスタムインスツルメンテーション | +| -------- | ------------- | -------------------- | ---------------------- | +| Python | Python 3.7 以上 | {{< X >}} | {{< X >}} | +| Node.js | Node.js 16 以上 | {{< X >}} | {{< X >}} | +| Java | Java 8 以上 | {{< X >}} | {{< X >}} | + + +SDK を使用して LLM アプリケーションをインスツルメントするには: +1. Agent Observability SDK をインストールします。 +2. アプリケーションの起動コマンドで[必要な環境変数][6]を指定するか、プログラムの[コード内][7]で指定して、SDK を設定します。Datadog API キー、Datadog サイト、および ML (機械学習) アプリ名が設定されていることを確認してください。 + +#### 自動インスツルメンテーション {#auto-instrumentation} +自動インスツルメンテーションは、コード変更なしで、Python、Node.js、および Java アプリケーションの LLM 呼び出しをキャプチャします。そのため、一般的なフレームワークやプロバイダーに関するトレースと可観測性をすぐに利用できるようになります。詳細およびサポートされている全フレームワークとプロバイダーを確認するには、[自動インスツルメンテーションのドキュメント][1]を参照してください。 + +自動インスツルメンテーションでは、以下の項目が自動的にキャプチャされます。 +- 入力プロンプトと出力補完 +- トークンの使用量とコスト +- レイテンシーおよびエラー情報 +- モデルパラメータ (temperature、max_tokens など) +- フレームワーク固有のメタデータ + +
サポートされているフレームワークを使用する場合、LLM 呼び出しに対して手動でスパンを作成する必要はありません。SDK によって自動的に、豊富なメタデータを含む適切なスパンが作成されます。
+ +#### カスタムインスツルメンテーション {#custom-instrumentation} +サポートされるすべての SDK では、自動インスツルメンテーションに加え、LLM アプリケーションのカスタムインスツルメンテーションのための高度な機能を提供しています。たとえば、次のようなものがあります。 +- 関数デコレーターまたはコンテキストマネージャーを使用した手動でのスパン作成 +- マルチステップ LLM アプリケーション向けの複雑なワークフロートレース +- 自律型 LLM エージェント向けのエージェント監視 +- カスタム評価および品質測定 +- ユーザー操作のセッション追跡 + +詳細については、[SDK リファレンスドキュメント][2]を参照してください。 + +### HTTP API インスツルメンテーション {#http-api-instrumentation} +SDK でサポートされていない言語やカスタムインテグレーションを使用している場合は、Datadog の HTTP API を使用してアプリケーションをインスツルメントすることができます。 + +API では、以下を行うことができます。 +- HTTP エンドポイントを介して直接スパンを送信する +- スパンに関連付けられているカスタム評価を送信する +- 複雑なアプリケーションの完全なトレース階層を含める +- 入力、出力、メタデータ、メトリクスを使用してスパンに注釈を付ける + +API エンドポイント: +- [Spans API][4]: `POST` `https://api.{{< region-param key="dd_site" code="true" >}}/api/intake/llm-obs/v1/trace/spans` +- [Evaluations API(API 評価)][5]: `POST` `https://api.{{< region-param key="dd_site" code="true" >}}/api/intake/llm-obs/v2/eval-metric` + +詳細については、[HTTP API ドキュメント][3]を参照してください。 + +## 参考資料 {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + + +[1]: /ja/llm_observability/auto_instrumentation +[2]: /ja/llm_observability/instrument/sdk +[3]: /ja/llm_observability/setup/api +[4]: /ja/llm_observability/instrument/api/?tab=model#spans-api +[5]: /ja/llm_observability/instrument/api/?tab=model#evaluations-api +[6]: /ja/llm_observability/instrument/sdk#command-line-setup +[7]: /ja/llm_observability/instrument/sdk#in-code-setup \ No newline at end of file diff --git a/hugo/content/ja/llm_observability/instrument/agentic/_index.md b/hugo/content/ja/llm_observability/instrument/agentic/_index.md new file mode 100644 index 00000000000..a36157a452c --- /dev/null +++ b/hugo/content/ja/llm_observability/instrument/agentic/_index.md @@ -0,0 +1,104 @@ +--- +aliases: +- /ja/llm_observability/instrumentation/agentic/ +title: Agentic Instrumentation +--- +## ガイドライン {#guidelines} + +**重要**: 他の手順へのハイパーリンクをたどる際は、ここに記載されている**すべての**ガイドラインに従ってください。 + +1. Datadog Agent Observability および Datadog トレーサーに関連するコードのみを追加してください。手動インスツルメンテーションを目的とする場合を除き、関連のないコードを変更しないでください。 +2. モノレポや複数のサービスまたはインスツルメンテーションターゲットを持つプロジェクトで実行する場合は、どのサービスまたはサブプロジェクトを Agent Observability のインスツルメンテーション対象とするかをユーザーに確認してください。 +3. 最新の Datadog SDK をインストールしてください。すでにインストールされている場合は、依存関係を更新してもよいかユーザーに確認してください。 + +## 前提条件 {#pre-requisites} + +1. Agent Observability データを Datadog に送信するには、Datadog API Key が必要です。API キーがないと、ユーザーは Agent Observability データを受信できないため、これは**必須要件**です。ユーザーがまだ API キーを提供しておらず、提供を希望しない場合は、アプリケーションのインスツルメンテーションを続行してください。その際、最後に API キーを設定する必要があることを明示し、設定場所を案内してください。 +2. インスツルメンテーションを行うアプリケーションで使用されているプログラミング言語とフレームワークを特定してください。これは、アプリケーションを正しくインスツルメンテーションするために重要です。 + +## 環境変数 {#environment-variables} + +すべての環境変数は、メインのアプリケーションプロセスが起動する前、_または_アプリケーションのエントリポイントの最初の行で設定する必要があります。 + +これらの環境変数はインライン化しないでください。代わりに、プロセスから直接読み取るようにしてください。 + +- ローカル開発の場合は、アプリケーションと使用している言語に適した `.env` などのファイルに設定し、Agent Observability SDK の初期化時にそれらが設定されていることを確認してください (各言語固有のガイドを参照してください)。 +- ローカル開発以外の場合は、設定が必要な環境変数についてもユーザーに伝えてください。 + +### API キー {#api-key} + +これは**極めて重要**です。以下の環境変数で API キーを設定してください。 + +```bash +DD_API_KEY= +``` + +### Agent Observability を有効にする{#enable-agent-observability} + +これは**極めて重要**です。Agent Observability を適切に有効にするには、以下の環境変数を設定してください。 + +```bash +DD_LLMOBS_ENABLED=true +DD_LLMOBS_AGENTLESS_ENABLED=true +``` + +### Agent Observability アプリケーション名 {#agent-observability-application-name} + +これは**強く推奨されます**。ユーザーが最初のプロンプトの一部としてアプリケーション名 (または `DD_LLMOBS_ML_APP`) を提供した場合は、その値を使用してください。それ以外の場合は、フォルダー、リポジトリ、またはプロジェクト名に基づいた論理名を使用してください。 + +```bash +DD_LLMOBS_ML_APP= +``` + +### Datadog サイト {#datadog-site} + +これは**オプション**です。ユーザーの API キーに関連付けられたデータセンターに対応する Datadog サイトを設定してください。提供されない場合 (場合によっては `DD_SITE` を介して)、`datadoghq.com` のサイトが使用されることをユーザーに通知してください。_値が提供されている場合_は、それを環境変数として設定してください。 + +```bash +DD_SITE= +``` + +## アプリケーションをインスツルメンテーションする {#instrument-the-application} + +検出された言語の手順に従ってください。 + +| 言語 | 手順 | +|----------|-------------| +| Python| [Python アプリケーションの Agentic インスツルメンテーション](/llm_observability/instrument/agentic/python.md) | +| Node.js| [Node.js アプリケーションの Agentic インスツルメンテーション](/llm_observability/instrument/agentic/nodejs.md) | +| Java| [Java アプリケーションの Agentic インスツルメンテーション](/llm_observability/instrument/agentic/java.md) | +| OpenTelemetry| [OpenTelemetry インスツルメンテーション](/llm_observability/instrument/otel_instrumentation.md) | + +## プロンプトをインスツルメンテーションし、Prompt Management を提供する{#instrument-prompts-and-offer-prompt-management} + +Prompt Tracking は、デフォルトの Agent Observability インスツルメンテーションの一部です。選択した各 LLM 呼び出しのプロンプト構築境界を特定し、プロンプトテンプレートを動的変数とは別に保持してください。 + +1. ユーザーのリクエストですでに Datadog 管理プロンプト ID が指定されている場合は、[Prompt Management の Agent による統合ガイド](/llm_observability/instrument/agentic/prompt_management.md)に従ってください。Prompt Management を使用するかどうかについて再度尋ねないでください。 +2. それ以外の場合は、アプリケーションのプロンプトと、それらのフォーマットに使用される動的変数を特定してください。既存のプロバイダー、モデル、プロンプトコンテンツ、およびアプリケーションの動作を保持してください。 +3. サポートされている Python アプリケーションの場合は、特定したプロンプトをユーザーに伝え、それらのプロンプトを Datadog で管理するかどうかを尋ねてください。ユーザーが同意した場合は、[Prompt Management の Agent による統合ガイド](/llm_observability/instrument/agentic/prompt_management.md)に従って、選択したローカルプロンプトを昇格させ、ローカルでの構築を管理対象プロンプトの取得に置き換えてください。 +4. ユーザーが Prompt Management を拒否した場合、またはアプリケーションの言語がサポートされていない場合は、[Prompt Tracking の手順](/llm_observability/instrument/prompt_tracking)に従って、選択したプロンプトに構造化プロンプトメタデータを組み込んでください。ランタイムでのプロンプト取得は追加しないでください。 + +Prompt Management がローカルプロンプトを置き換える場合は、重複する構造化プロンプトメタデータを添付するのではなく、管理対象プロンプトの自動追跡を使用してください。 + +## トレースを表示する {#viewing-traces} + +アプリケーションにアクセスして Datadog でデータを確認できることをユーザーに伝えてください。 + +**必須**: ユーザーがこのアプリケーションに関連付けられたデータを表示できるパーマリンクを提供してください。これは以下の形式になります。 + +``` +https://app.{dd_site}/llm/applications?query=@ml_app:{application_name} +``` + +提供された値を入力してください。 +1. `dd_site` - [Datadog site](#datadog-site)の値が提供されている場合は、その値を使用してください。それ以外の場合は、`datadoghq.com` を使用してください。 +2. `application_name`- [Agent Observability アプリケーション名](#llm-observability-application-name)セクションから提供された値、または推論された値のいずれかを使用してください。 + +## 言語固有の手順 {#language-specific-instructions} + +{{< whatsnext desc="コーディングエージェントを使用してアプリケーションをインスツルメンテーションします：" >}} + {{< nextlink href="/llm_observability/instrument/agentic/python" >}}Python アプリケーションの Agentic インスツルメンテーション{{< /nextlink >}} + {{< nextlink href="/llm_observability/instrument/agentic/nodejs" >}}Node.js アプリケーションの Agentic インスツルメンテーション{{< /nextlink >}} + {{< nextlink href="/llm_observability/instrument/agentic/java" >}}Java アプリケーションの Agentic インスツルメンテーション{{< /nextlink >}} + {{< nextlink href="/llm_observability/instrument/agentic/prompt_management" >}}Prompt Management の Agent による統合{{< /nextlink >}} +{{< /whatsnext >}} \ No newline at end of file diff --git a/hugo/content/ja/llm_observability/quickstart/_index.md b/hugo/content/ja/llm_observability/quickstart/_index.md new file mode 100644 index 00000000000..7ab4d050b33 --- /dev/null +++ b/hugo/content/ja/llm_observability/quickstart/_index.md @@ -0,0 +1,247 @@ +--- +aliases: +- /ja/tracing/llm_observability/quickstart +description: Agent Observability SDK を使用して Python、Node.js、または Java LLM アプリケーションをインスツルメントして、Agent + Observability を使用します。 +further_reading: +- link: /llm_observability/instrument/auto_instrumentation + tag: ドキュメント + text: サポートされている自動インスツルメンテーションフレームワークおよびライブラリ +- link: /llm_observability/instrument/sdk + tag: ドキュメント + text: 手動インスツルメンテーション用の Agent Observability SDK リファレンス +- link: /llm_observability/instrument/api + tag: ドキュメント + text: 全言語対応のインスツルメンテーション用の Agent Observability HTTP API +- link: /llm_observability/instrument/otel_instrumentation + tag: ドキュメント + text: OpenTelemetry によるインスツルメンテーション +- link: /llm_observability/configure/evaluations + tag: 評価 + text: アプリケーションで評価を構成する +- link: /llm_observability/lapdog + tag: ドキュメント + text: Agent Observability 用ローカル開発ツール +title: クイックスタート +--- +このページでは、Datadog の Agent Observability SDK を使用して、Python、Node.js、または Java LLM アプリケーションをインスツルメントする方法を紹介します。 + +### 前提条件 {#prerequisites} + +Datadog Agent が実行されていない場合は、Agent Observability に Datadog API キーが必要です。[Datadog](https://app.datadoghq.com/organization-settings/api-keys) で API キーを確認してください。 + +### コーディングエージェントを使用して Agent Observability をインスツルメントする {#instrument-agent-observability-with-a-coding-agent} + +以下のプロンプトを貼り付けて、任意のコーディングエージェントで Agent Observability をインスツルメントします。 + +```bash +Follow the instructions at https://docs.datadoghq.com/llm_observability/instrument/agentic.md to instrument my application with Datadog Agent Observability. When configuring the environment, use the following values for variable entries: + +DD_SITE={{< region-param key="dd_site" code="true" >}} +DD_API_KEY= +``` + +**注:** API キーをプロンプトの中で指定することは任意であり、コーディングエージェントがアプリケーションをインスツルメントするために必須というわけではありません。 + +### 手動セットアップ {#manual-setup} + +Datadog の [アプリ内オンボーディングフロー](https://app.datadoghq.com/llm/applications?setupMethod=manual&showOnboarding=true)のセットアップ手順に従うと、対話式にすばやく設定を行えます。 + +{{< tabs >}} +{{% tab "Python" %}} + +1. SDK をインストールします。 + + ```shell + pip install ddtrace + ``` + +2. Python の起動コマンドの先頭に `ddtrace-run` を付加します。 + + ```shell + DD_LLMOBS_ENABLED=1 \ + DD_LLMOBS_ML_APP=quickstart-app \ + DD_SITE= \ + DD_API_KEY= \ + ddtrace-run + ``` + +有効にすると、SDK は OpenAI、LangChain、LangGraph、Bedrock、Anthropic など、[サポートされている Python フレームワーク][auto-instr-py] への呼び出しを自動的にトレースします。お使いのフレームワークが示されない場合は、[手動インスツルメンテーション][sdk] を追加して、LLM 呼び出しを直接トレースしてください。 + +[auto-instr-py]: /llm_observability/instrument/auto_instrumentation/?tab=python +[sdk]: /llm_observability/instrument/sdk?tab=python + +{{% /tab %}} + +{{% tab "Node.js" %}} +1. SDK をインストールします。 + + ```shell + npm install dd-trace + ``` + +2. Agent Observability を使用して、アプリケーションのエントリポイントで最初の依存関係として `dd-trace` をインポートして初期化します。 + ```shell + DD_LLMOBS_ENABLED=1 \ + DD_LLMOBS_ML_APP=quickstart-app \ + DD_SITE= \ + DD_API_KEY= \ + NODE_OPTIONS="--import dd-trace/initialize.mjs" + ``` + +有効にすると、SDK は OpenAI、LangChain、Vercel AI SDK、Bedrock、Anthropic など、[サポートされている Node.js フレームワーク][1] への呼び出しを自動的にトレースします。お使いのフレームワークが示されない場合は、[手動インスツルメンテーション][2] を追加して、LLM 呼び出しを直接トレースしてください。 + +**Next.js**: Agent Observability SDK を使用して Next.js アプリケーションを適切に構成する方法は、「[Agent Observability 用の Next.js アプリケーションのインスツルメンテーション][3]」を参照してください。 + +[1]: /ja/llm_observability/instrument/auto_instrumentation/?tab=nodejs +[2]: /ja/llm_observability/instrument/sdk?tab=nodejs +[3]: /ja/llm_observability/guide/nextjs_guide + +{{% /tab %}} +{{% tab "Java" %}} +1. SDK をインストールします。 + + ```shell + wget -O dd-java-agent.jar 'https://dtdg.co/latest-java-tracer' + ``` + +2. Java の起動コマンドに `-javaagent` JVM 引数を追加します。 + ```shell + java -javaagent:/path/to/dd-java-agent.jar \ + -Ddd.llmobs.enabled=true \ + -Ddd.llmobs.ml.app=quickstart-app \ + -Ddd.site= \ + -Ddd.api.key= \ + -jar path/to/your/app.jar + ``` + +有効にすると、SDK は [サポートされている Java フレームワーク][1] への呼び出しを自動的にトレースします。Java の自動インスツルメンテーションは、OpenAI および Azure OpenAI をサポートしています。Bedrock や LangChain4j などの他のライブラリでは、[手動インスツルメンテーション][2] を使用してください。 + +[1]: /ja/llm_observability/instrument/auto_instrumentation/?tab=java +[2]: /ja/llm_observability/instrument/sdk?tab=java + +{{% /tab %}} +{{% tab "その他の言語 / HTTP API" %}} + +Python、Node.js、Java 以外の言語では、SDK は使用せず、[Agent Observability HTTP API][1] を使用して Datadog にスパンを直接送信してください。 + +アプリケーションが [OpenTelemetry GenAI セマンティック規約][2] に準拠したスパンを出力する場合は、[OpenTelemetry インスツルメンテーション][2] を参照してください。 + +[1]: /ja/llm_observability/instrument/api +[2]: /ja/llm_observability/instrument/otel_instrumentation + +{{% /tab %}} +{{< /tabs >}} + +ご使用の Datadog サイトは {{< region-param key="dd_site" code="true" >}}です。`` をご使用の Datadog API キーに置き換えてください。 + +### トレースを表示する {#view-traces} + +アプリケーションに対して LLM 呼び出しをトリガーするリクエストを行い、Datadog の [[{{< ui >}}Agent Observability{{< /ui >}}] ページ][3] の [{{< ui >}}Traces{{< /ui >}}] (トレース) タブでトレースを表示します。 + +トレースが表示されない場合は、次のようにします。 + +- **ライブラリが自動インスツルメンテーションされていることをチェックする**: 自動インスツルメンテーションは、[サポートされているフレームワークおよびライブラリ][6] に対する呼び出しのみをキャプチャします。[Python][7]、[Node.js][8]、または [Java][9] のサポートされているライブラリのリストをチェックしてください。ご使用のライブラリがリストにない場合は、手動でインスツルメンテーションを追加する必要があります。 +- **手動インスツルメンテーションを追加する**: [Agent Observability SDK][5] を使用して、コード内で直接 LLM 呼び出しをスパンでラップします。この方法は、すべてのライブラリまたはモデルプロバイダーで使用できます。 +- **HTTP API を使用する**: [Agent Observability HTTP API][10] は、あらゆる言語やフレームワークからのスパンを受け入れ、SDK を必要としません。 +- **OpenTelemetry を使用する**: ご使用のフレームワークが [OpenTelemetry GenAI セマンティック規約][11] に準拠したスパンを出力する場合は、セットアップの詳細について「[OpenTelemetry インスツルメンテーション][11]」を参照してください。 + + +### 次のステップ {#next-steps} + +アプリケーションからトレースが送信されるようになったら、以下のことが可能になります。 + +- LLM アプリケーションの有効性を評価するために使用できる [評価を構成][4] します。 +- [手動インスツルメンテーション][5] をアプリケーションに追加し、自動インスツルメンテーションでは取得できないデータを抽出します。 + + +## 「Hello World」アプリケーションの例 {#example-hello-world-application} + +Agent Observability 製品について学ぶために利用できるシンプルなアプリケーションを以下で紹介します。 + + +{{< tabs >}} +{{% tab "Python" %}} + +1. `pip install openai` を実行して OpenAI をインストールします。 + +2. サンプルスクリプト `app.py` を保存します。 + + ```python + import os + from openai import OpenAI + + oai_client = OpenAI(api_key=os.environ.get("OPENAI_API_KEY")) + completion = oai_client.chat.completions.create( + model="gpt-4o-mini", + messages=[ + {"role": "system", "content": "You are a helpful customer assistant for a furniture store."}, + {"role": "user", "content": "I'd like to buy a chair for my living room."}, + ], + ) + ``` + +3. アプリケーションを実行します。 + + ```shell + DD_LLMOBS_ENABLED=1 \ + DD_LLMOBS_ML_APP=quickstart-app \ + DD_API_KEY= \ + ddtrace-run app.py + ``` +{{% /tab %}} + +{{% tab "Node.js" %}} +1. `npm install openai` を実行して OpenAI をインストールします。 + +2. サンプルスクリプト `app.js` を保存します。 + + ```js + const { OpenAI } = require('openai'); + const oaiClient = new OpenAI(process.env.OPENAI_API_KEY); + + async function main () { + const completion = await oaiClient.chat.completions.create({ + model: 'gpt-4o-mini', + messages: [ + { role: 'system', content: 'You are a helpful customer assistant for a furniture store.' }, + { role: 'user', content: 'I\'d like to buy a chair for my living room.' }, + ] + }); + return completion; + } + + main().then(console.log) + ``` + +3. アプリケーションを実行します。 + ```shell + DD_LLMOBS_ENABLED=1 \ + DD_LLMOBS_ML_APP=quickstart-app \ + DD_API_KEY= \ + NODE_OPTIONS="--import dd-trace/initialize.mjs" node app.js + ``` + +{{% /tab %}} +{{< /tabs >}} + + +## lapdog を使用してローカルで Agent Observability を試す {#try-agent-observability-locally-with-lapdog} + +Agent Observability をローカルで無料で試すには、[こちらの手順に従って][12] アプリケーションをインスツルメントし、[lapdog](https://lapdog.datadoghq.com) を使用してローカルでデータを表示します。 + + +## 関連資料{#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[3]: https://app.datadoghq.com/llm/traces +[4]: /ja/llm_observability/configure/evaluations +[5]: /ja/llm_observability/instrument/sdk#manual-instrumentation +[6]: /ja/llm_observability/instrument/auto_instrumentation +[7]: /ja/llm_observability/instrument/auto_instrumentation/?tab=python +[8]: /ja/llm_observability/instrument/auto_instrumentation/?tab=nodejs +[9]: /ja/llm_observability/instrument/auto_instrumentation/?tab=java +[10]: /ja/llm_observability/instrument/api +[11]: /ja/llm_observability/instrument/otel_instrumentation +[12]: /ja/llm_observability/lapdog \ No newline at end of file diff --git a/hugo/content/ja/monitors/status/events.md b/hugo/content/ja/monitors/status/events.md index 6047fc63301..4b89550afc2 100644 --- a/hugo/content/ja/monitors/status/events.md +++ b/hugo/content/ja/monitors/status/events.md @@ -1,71 +1,71 @@ --- +description: ステータスページで、クイックアクション、イベント詳細、トラブルシューティングツールなどのモニターイベントを表示し、管理します。 further_reading: - link: events/ tag: ドキュメント - text: イベント管理 -title: Status Events + text: Event Management +title: ステータスイベント --- +
ステータスイベントは、暫定的なモニターステータスページに含まれます。従来のステータスページをご利用の場合は、ステータスページ (レガシー) のドキュメントを参照してください。
-
Status Events は 暫定の Monitor Status Page の一部です。従来のステータス ページを使用している場合は、Status Page (Legacy) のドキュメントを参照してください。
+## 概要 {#overview} -## 概要 +{{< img src="/monitors/status/status_page_event_details.png" alt="イベント詳細が表示されているモニターステータスページ" style="width:100%;" >}} -{{< img src="/monitors/status/status_page_event_details.png" alt="イベントの詳細が表示された Monitor ステータス ページ" style="width:100%;" >}} +モニターによって生成されたすべてのイベントが、モニターのステータスページに表示され、グループ名、イベントタイプ、タイムスタンプが示されます。イベントタイムラインには、ダウンタイムイベントや監査証跡イベントも含まれます。 -お使いの Monitor で生成されたすべてのイベントは、Monitor のステータス ページに表示され、グループ名、イベント種別、タイムスタンプが表示されます。Event timeline にも、ダウンタイムや監査証跡のイベントが含まれます。 +各イベントについて、クイックアクションにアクセスしたり、ダッシュボードやログなどの関連アセットを表示したりすることができます。 -各イベントごとに、Quick Actions にアクセスしたり、ダッシュボードやログなどの関連アセットを表示したりできます。 +## [Event details] (イベント詳細) セクション {#event-details-section} -## Event details セクション +関連付けられているタグやアクションなど、個々のイベントの詳細情報を確認するには、次のようにします。 -関連するタグやアクションを含む、各イベントの詳細を確認するには: +1. モニターのステータスページから、[{{< ui >}}Event timeline{{< /ui >}}] (イベントタイムライン) まで下にスクロールします。 +2. タイムライン内のイベントをクリックすると、イベントの詳細が表示されます。 -1. Monitor ステータス ページで、**Event timeline** までスクロールします。 -2. タイムライン内のイベントをクリックして、イベントの詳細を表示します。 +イベント詳細を使用して、モニターアラートを把握し、根本原因を特定します。この情報は、対応者のワークフローをサポートし、現状を把握するために役立ちます。 -Event details を活用して Monitor アラートを理解し、根本原因を特定します。この情報は対応者のワークフローを支援し、進行中の状況を把握するのに役立ちます。 +### 修復アクションの実行 {#take-action-to-remediate} -### 復旧に向けてアクションを実行 - -Quick Actions を使うと、ステータス ページから離れずにアクションを起こせます。コンテキストが自動的に追加されるため、対応者の時間を節約できます。 +クイックアクションを使用すると、ステータスページから直接アクションを実行できます。コンテキストが自動的に追加されるので、対応者の作業時間短縮になります。 | アクション | 説明 | | :---- | :---- | -| Mute | Monitor アラートをミュートするための [ダウンタイム][1] を作成します。 | -| Resolve | 次回の評価まで Monitor のステータスを `OK` に一時的に設定します。 | -| Declare Incident | Monitor アラートを [Incident Management][2] でエスカレーションします。 | -| Create Case | Datadog を離れずにこのアラート調査を追跡するための [ケース][3] を作成します。 | -| Run Workflow | あらかじめ定義されたスニペットを用いて [Workflow][4] Automation を実行し、緩和アクションを実行します。 | +| {{< ui >}}Mute{{< /ui >}} | モニターアラートをミュートするための [ダウンタイム][1] を作成します。| +| {{< ui >}}Resolve{{< /ui >}} | 次回の評価まで、モニターのステータスを一時的に `OK` に設定します。| +| {{< ui >}}Declare Incident{{< /ui >}} | [Incident Management][2] を使用してモニターアラートをエスカレーションします。| +| {{< ui >}}Create Work Item{{< /ui >}} | Datadog から移動せずに、このアラートに関する調査を追跡するための [作業項目][3] を作成します。| +| {{< ui >}}Run Workflow{{< /ui >}} | 事前定義されたスニペットを使用して [Workflow][4] Automation を実行し、緩和アクションを実行します。| -### Resolve +### 解決 {#resolve} -ステータス ページの [Header][5] または Event details セクションから、Monitor アラートを解決できます。Event details セクションから解決した場合は、選択したイベントに関連するグループのみに影響します。一方、Header から解決すると、アラート内のすべてのグループが解決され、Monitor のステータスが `OK` (全グループ) に設定されます。 +ステータスページの [ヘッダー][5] または [Event details] (イベント詳細) セクションからモニターアラートを解決できます。[Event details] セクションから解決した場合は選択したイベントに関連するグループのみに影響しますが、ヘッダーから解決した場合はアラート内のすべてのグループが解決され、モニターのステータスが `OK` (すべてのグループ) に設定されます。 -現在のデータが `ALERT` 状態に相当するために Monitor がアラート発報中の場合、`resolve` を使用すると、状態は一時的に `ALERT` から `OK` に切り替わり、その後 `ALERT` に戻ります。したがって、`resolve` はアラートを承認したり、Datadog に無視させたりする目的ではありません。 +現在のデータが `ALERT` 状態に該当するためにモニターからアラートが生成されている場合は、`resolve` を使用すると、状態が一時的に `ALERT` から `OK` に変更された後、`ALERT` に戻ります。したがって、`resolve` はアラートを確認するためや、Datadog にアラートを無視するよう指示するためには使用できません。 -データが断続的に報告される場合、Monitor を手動で解決するのが有効です。たとえば、アラートがトリガーされた後に Monitor がデータの受信を停止し、アラート条件を評価できず `OK` 状態に復帰できないことがあります。このような場合は、`resolve` 機能、または `Automatically resolve monitor after X hours` により、Monitor を `OK` 状態に戻せます。 +データが断続的に報告される場合は、モニターを手動で解決すると役立ちます。たとえば、アラートがトリガーされた後、モニターがデータの受信を停止したために、アラート条件を評価して `OK` 状態に戻れなくなる場合があります。そのような場合は、`resolve` 機能または [{{< ui >}}Automatically resolve monitor after X hours{{< /ui >}}] (X 時間後に自動的にモニターを解決する) を使用すると、モニターが `OK` 状態に戻ります。 -**代表的なユース ケース**: エラーがないと指標が生成されないタイプの Monitor (`aws.elb.httpcode_elb_5xx`、または、エラーがある場合にのみエラーを報告するあなたのコード内の任意の DogStatsD カウンター)。 +**典型的なユースケース**: エラーがない場合は生成されないエラーメトリクスに基づくモニター (`aws.elb.httpcode_elb_5xx`、または、_エラーがある場合にのみ_エラーを報告するコード内の DogStatsD カウンタ)。 -## Event troubleshooting セクション +## イベントのトラブルシューティングセクション {#event-troubleshooting-section} -{{< img src="/monitors/status/events/event_troubleshooting.png" alt="Dependency Map の例を含む Event troubleshooting" style="width:100%;" >}} +{{< img src="/monitors/status/events/event_troubleshooting.png" alt="依存関係マップの例を使用したイベントのトラブルシューティング" style="width:100%;" >}} -各イベントに対して、対応者がアラートのコンテキストを素早く理解できるよう、トラブルシューティング情報にアクセスできます。 +対応者は各イベントのトラブルシューティング情報にアクセスして、アラートのコンテキストを迅速に理解することができます。 -| トラブルシューティング コンポーネント | 説明 | +| トラブルシューティングコンポーネント | 説明 | | --- | ----------- | -| Dependency Map | サービス タグが使用可能な場合 (Monitor タグとして、またはグループ内)、依存関係のステータスを示す Dependency Map にアクセスできます。 | -| Change Tracking | サービス タグが使用可能な場合 (Monitor タグとして、またはグループ内)、あなたのサービスとその依存関係に関連する変更の一覧にアクセスできます。サポートされる変更の種類や設定要件の詳細は、[Change Tracking][6] のドキュメントを参照してください。 | +| {{< ui >}}Dependency Map{{< /ui >}} | サービスタグがモニタータグとして、またはグループ内で使用可能な場合は、依存関係のステータスを示す依存関係マップにアクセスできます。| +| {{< ui >}}Change Tracking{{< /ui >}} | サービスタグがモニタータグとして、またはグループ内で使用可能な場合は、サービスとその依存関係に関連する変更のリストにアクセスできます。サポートされている変更の具体的な種類とセットアップ要件の詳細については、[Change Tracking][6] のドキュメントを参照してください。| -## 参考資料 +## 関連資料{#further-reading} {{< partial name="whats-next/whats-next.html" >}} [1]: /ja/monitors/downtimes/?tab=bymonitorname -[2]: /ja/service_management/incident_management/ -[3]: /ja/service_management/case_management/ -[4]: /ja/service_management/workflows/trigger/#trigger-a-workflow-from-a-monitor +[2]: /ja/incident_response/incident_management/ +[3]: /ja/incident_response/work_management/ +[4]: /ja/actions/workflows/trigger/#trigger-a-workflow-from-a-monitor [5]: /ja/monitors/status/status_page/#header [6]: /ja/change_tracking \ No newline at end of file diff --git a/hugo/content/ja/observability_pipelines/destinations/databricks.md b/hugo/content/ja/observability_pipelines/destinations/databricks.md index ce0fe044c60..8ad5a8ff8cb 100644 --- a/hugo/content/ja/observability_pipelines/destinations/databricks.md +++ b/hugo/content/ja/observability_pipelines/destinations/databricks.md @@ -1,30 +1,31 @@ --- +description: Databricks (Zerobus) 送信先を使用して、Databricks Unity Catalog テーブルにログを送信する方法を学びましょう。 disable_toc: false products: - icon: logs name: ログ url: /observability_pipelines/configuration/?tab=logs#pipeline-types -title: Databricks (Zerobus) 宛先 +title: Databricks (Zerobus) 送信先 --- {{< product-availability >}} {{< callout url="#" - btn_hidden="true" header="プレビューに参加しましょう">}} -Databricks (Zerobus) 宛先はプレビュー中です。アクセスをリクエストするには、アカウントマネージャーに連絡してください。 + btn_hidden="true" header="プレビュー版を利用しましょう">}} +Databricks (Zerobus) 送信先はプレビュー版です。アクセスをリクエストするには、アカウントマネージャーにお問い合わせください。 {{< /callout >}} ## 概要 {#overview} -Observability Pipelines の Databricks (Zerobus) 宛先を使用して、ログを Databricks Unity Catalog テーブルに送信します。送信先はログを [Zerobus Ingest API][1] にストリーミングし、OAuth サービス プリンシパルを使用して Databricks に認証します。 +Observability Pipelines の Databricks (Zerobus) 送信先を使用して、Databricks Unity Catalog テーブルにログを送信します。この送信先は、[Zerobus Ingest API][1] にログをストリーミングし、OAuth サービスプリンシパルを使用して Databricks に対して認証を行います。 -## 前提条件 {#prerequisites} +## 前提条件{#prerequisites} -Databricks (Zerobus) 宛先を構成する前に、次のことを行う必要があります。 +Databricks (Zerobus) 送信先を構成する前に、以下を実施する必要があります。 -- [Observability Pipelines Worker がログを書き込む Unity Catalog スキーマとテーブル](#set-up-a-schema-and-table)のセットアップ。 -- [Worker が Databricks に認証するために使用するサービス プリンシパル](#set-up-a-service-principal)のセットアップ。このサービス プリンシパルには、テーブルの読み取りおよび書き込みの権限が必要です。 +Observability Pipelines Worker がログを書き込む - [Unity Catalog スキーマとテーブルを設定](#set-up-a-schema-and-table)します。 +Worker が Databricks への認証に使用する- [サービスプリンシパルを設定](#set-up-a-service-principal)します。サービスプリンシパルには、テーブルへの読み取りおよび書き込み権限が必要です。 -### スキーマとテーブルのセットアップ{#set-up-a-schema-and-table} +### スキーマとテーブルを設定する {#set-up-a-schema-and-table} このセクションの SQL 例では、次のプレースホルダーを使用します。 @@ -34,13 +35,13 @@ Databricks (Zerobus) 宛先を構成する前に、次のことを行う必要 | `` | Unity Catalog 名。 | `main` | | `` | スキーマ名。 | `obs_pipelines` | | `` | テーブル名。 | `apache_common_logs` | -| `` | (オプション) 管理された場所の URI。 | `s3://your-bucket/managed` | +| `` | (オプション) 管理対象ロケーションの URI。 | `s3://your-bucket/managed` | -**注意**: `GRANT` コマンドは Databricks ワークスペース管理者によって実行される必要があります。 +**注**: `GRANT` コマンドは、Databricks ワークスペース管理者が実行する必要があります。 -Databricks ワークスペース内で以下を行います。 +Databricks ワークスペースで、 -1. Databricks ワークスペース管理者でない場合は、管理者に次のコマンドを実行して、スキーマを作成する権限をユーザーに付与してもらってください。 +1. Databricks ワークスペース管理者でない場合は、管理者に次のコマンドを実行してもらい、ユーザーにスキーマを作成する権限を付与してください。 ```sql GRANT CREATE SCHEMA ON CATALOG TO ; ``` @@ -52,12 +53,12 @@ Databricks ワークスペース内で以下を行います。 ``` - **Note**: `MANAGED LOCATION` is optional. See Databricks' [Create Schemas][2] documentation for more information. -1. 管理者ユーザーでない場合は、管理者に次のコマンドを実行して、スキーマでテーブルを作成する権限をユーザーに付与してもらってください。 +1. 管理者ユーザーでない場合は、管理者に次のコマンドを実行してもらい、ユーザーにスキーマ上でテーブルを作成する権限を付与してください。 ```sql GRANT CREATE TABLE ON SCHEMA . TO ; ``` -1. Observability Pipelines がログデータを書き込むテーブルを作成するために、次のコマンドを実行します。 +1. 次のコマンドを実行して、Observability Pipelines がログデータを書き込むテーブルを作成します。 ```sql CREATE TABLE .. ( host STRING, @@ -69,46 +70,53 @@ Databricks ワークスペース内で以下を行います。 ``` - See Databricks' [Create a Unity Catalog Managed Table][3] documentation for more information. -完全修飾テーブル名は `catalog.schema.table` で、例えば `main.obs_pipelines.apache_common_logs` です。これは、Observability Pipelines Databricksの宛先をセットアップする際に**テーブル名**に入力する値です。 +完全修飾テーブル名は `catalog.schema.table` です (例: `main.obs_pipelines.apache_common_logs`)。これは、Observability Pipelines Databricks 送信先を設定する際に {{< ui >}}Table Name{{< /ui >}} に入力する値です。 -### サービスプリンシパルのセットアップ{#set-up-a-service-principal} +### サービスプリンシパルを設定{#set-up-a-service-principal} -Databricks の [Zerobus Ingest API][1] は OAuth 認証を使用します。サービスプリンシパルを作成すると、OAuth クライアントシークレットが生成され、OAuth クライアント ID はサービスプリンシパルの UUID になります。 +Databricks [Zerobus Ingest API][1] は OAuth 認証を使用します。サービスプリンシパルを作成すると、OAuth クライアントシークレットが生成され、OAuth クライアント ID がサービスプリンシパルの UUID になります。 -サービスプリンシパルを作成するには、以下を行います。 +サービスプリンシパルを作成するには、 -1. Databricks ワークスペースで、[**User Settings**] (ユーザー設定) > [**Identity and access**] (アイデンティティとアクセス) > [**Service principals**] (サービスプリンシパル) に移動します。 -1. [**Add service principal**] (サービスプリンシパルを追加) をクリックします。 -1. サービスプリンシパルが作成された後、そのための OAuth シークレットを生成します。 - - サービスプリンシパルの**アプリケーション ID** (クライアント ID) と OAuth クライアントシークレットをメモしておいてください。Observability Pipelines Databricks の宛先を構成する際に、両方が必要です。 -1. Databricks でこの SQL を実行して、サービスプリンシパルにカタログ、スキーマ、およびテーブルへのアクセスを付与します。`` を前のステップでメモしたサービスプリンシパルのアプリケーション ID で置き換えます。 +1. Databricks ワークスペースで、**User Settings** > **Identity and access** > **Service principals** に移動します。 +1. **Add service principal** をクリックします。 +1. サービスプリンシパルが作成されたら、その OAuth シークレットを生成します。 + - サービスプリンシパルの **アプリケーション ID** (クライアント ID) と OAuth クライアントシークレットを控えておきます。Observability Pipelines Databricks 送信先を設定する際には、その両方が必要です。 +1. Databricks でこの SQL を実行し、サービスプリンシパルにカタログ、スキーマ、およびテーブルへのアクセス権を付与します。`` を、前のステップで取得したサービスプリンシパルのアプリケーション ID に置き換えてください。 ```sql GRANT USE CATALOG ON CATALOG TO ; GRANT USE SCHEMA ON SCHEMA . TO ; GRANT SELECT, MODIFY ON TABLE .. TO ; ``` -詳細については、Databricks の[アカウントにサービスプリンシパルを追加する][4]および[オブジェクトに対する権限を付与する][5]のドキュメントを参照してください。 +詳細については、Databricks の[アカウントへのサービスプリンシパルの追加][4]および[オブジェクトに対する権限の付与][5]のドキュメントを参照してください。 -## セットアップ{#setup} +## セットアップ {#setup} -[パイプラインをセットアップする][6]ときに、Databricks (Zerobus) 宛先を構成します。パイプラインのセットアップは、[UI][7] で、[API][8] を使用して、または [Terraform][9] で行えます。このセクションの手順は UI で構成されます。 +
シークレット管理の場合: OAuth クライアントシークレットの識別子のみを入力してください。実際の値は入力しないでください。
-**注意**: テーブルスキーマに存在しないログフィールドはドロップされます。例えば、ログにフィールド `id`、`name`、`host` があるのに、テーブルスキーマに `name` と `host` の列しか含まれていない場合、`id` フィールドはドロップされ、テーブルには書き込まれません。 +[パイプラインをセットアップ][6]する際に、Databricks (Zerobus) 送信先を設定します。パイプラインは、[UI][7]、[API][8]、または [Terraform][9] を使用して設定できます。このセクションの手順は UI で設定します。 -パイプライン UI で Databricks (Zerobus) 宛先を選択した後: +**注**: テーブルスキーマに存在しないログフィールドは破棄されます。たとえば、ログに `id`、`name`、`host` というフィールドがあり、テーブルスキーマに `name` と `host` という列しか含まれていない場合、`id` フィールドは破棄され、テーブルには書き込まれません。 -
Databricks (Zerobus) は、文字列形式のタイムスタンプを Databricks の TIMESTAMP タイプに変換しません。テーブルがタイムスタンプ列を使用している場合、詳細は文字列タイムスタンプをタイムスタンプ形式に変換するを参照してください。
+パイプライン UI で Databricks (Zerobus) 送信先を選択した後、 -
シークレット管理について: OAuth クライアントシークレットの識別子のみを入力してください。実際の値は入力しないでください。
+
-{{% observability_pipelines/secrets_env_var_note %}} + +
+ +1. Databricks ワークスペースの{{< ui >}}Ingestion Endpoint{{< /ui >}}を入力します (例: `https://.zerobus..cloud.databricks.com`)。Worker はこのエンドポイントにログを送信します。 +1. {{< ui >}}Table Name{{< /ui >}} を`catalog.schema.table`の形式で入力します (例: `main.obs_pipelines.apache_common_logs`)。 +1. Databricks ワークスペースの{{< ui >}}Unity Catalog Endpoint{{< /ui >}}を入力します (例: `https://.cloud.databricks.com`)。Worker はこのエンドポイントを使用してテーブルのスキーマを読み取ります。 +1. {{< ui >}}Auth - Client ID{{< /ui >}} フィールドに、`abcdefgh-1234-5678-abcd-ef0123456789` などのサービスプリンシパルのアプリケーション ID を入力します。 +1. {{< ui >}}Auth - Client Secret{{< /ui >}} フィールドに、OAuth クライアントシークレットの識別子を入力します。空白のままにすると、[デフォルト](#secret-defaults)が使用されます。 -1. Databricks ワークスペースの**取り込みエンドポイント**を入力します。`https://.zerobus..cloud.databricks.com` などです。ワーカーはこのエンドポイントにログを送信します。 -1. **テーブル名** を `catalog.schema.table` の形式で入力します。`main.obs_pipelines.apache_common_logs` などです。 -1. Databricksワークスペース用の **Unity Catalog エンドポイント**を入力します。`https://.cloud.databricks.com` などです。ワーカーはこのエンドポイントを使用してテーブルのスキーマを読み取ります。 -1. **認証 - クライアントID** フィールドに、サービスプリンシパルのアプリケーションIDを入力します。`abcdefgh-1234-5678-abcd-ef0123456789` などです。 -1. **Auth - Client Secret** フィールドに、OAuth クライアントシークレットの識別子を入力します。空白のままにすると、[デフォルト](#secret-defaults)が使用されます。 +{{% observability_pipelines/secrets_env_var_note %}} ### オプション設定 {#optional-settings} @@ -116,26 +124,36 @@ Databricks の [Zerobus Ingest API][1] は OAuth 認証を使用します。サ {{% observability_pipelines/destination_buffer %}} -### 文字列タイムスタンプをタイムスタンプ形式に変換する{#convert-string-timestamps-to-timestamp-format} +## 文字列のタイムスタンプをタイムスタンプ形式に変換する {#convert-string-timestamps-to-timestamp-format} -ログに文字列形式のタイムスタンプがあり、Databricks テーブルに[`TIMESTAMP` タイプ][11]として宣言されたタイムスタンプ列がある場合、ログを Databricks (Zerobus) 宛先に送信する前に、文字列をタイムスタンプ形式に変換する必要があります。Databricks (Zerobus) は、タイムスタンプ形式しかその `TIMESTAMP` 型に変換できません。 +ログのタイムスタンプが文字列形式で、Databricks テーブルに [`TIMESTAMP` 型][11]として宣言されたタイムスタンプ列がある場合は、ログを Databricks (Zerobus) 送信先に送信する前に、文字列をタイムスタンプ形式に変換する必要があります。Databricks (Zerobus) は、タイムスタンプ形式をその `TIMESTAMP` 型にのみ変換できます。 -文字列のタイムスタンプを変換しないと、ワーカーは次のようなエラーをスローします。 +文字列のタイムスタンプを変換しない場合、Worker は次のようなエラーをスローします。 ``` Protobuf encoding failed: Error converting timestamp field: Can't convert '2012-04-23T10[41]15Z' to i64: invalid digit found in string ``` -文字列形式のタイムスタンプをタイムスタンプ形式に変換するには: +文字列形式のタイムスタンプをタイムスタンプ形式に変換するには、次の手順を実行します。 1. パイプラインに[カスタムプロセッサ][12]を追加します。 -1. 次のカスタムスクリプトを持つ関数を追加します。 +1. 次のカスタムスクリプトを含む関数を追加します。 ``` .timestamp = parse_timestamp!(.timestamp, format: "%+") ``` See [parse_timestamp][13] for more information. -## シークレットのデフォルト{#secret-defaults} +## ログフィールド値のデータ型 {#data-type-of-log-field-values} + +ログフィールドの値は、テーブルスキーマ内の対応する列のデータ型と一致している必要があります。たとえば、テーブルスキーマで `message` が `STRING` と定義されているにもかかわらず、受信したログの `message` フィールドが `{"message": {"some": "string"}}` のようなオブジェクトである場合、Worker はイベントをエンコードできず、バッチ全体を破棄して次のようなエラーをスローします。 + +``` +error=Some(EncodingError { message: "Failed to encode batch: SerializingError(Arrow JSON decoding error: Json error: whilst decoding field 'message': expected string got {...})" }) request_id=1142 error_type="request_failed" stage="sending" +``` + +このエラーを防ぐには、[カスタムプロセッサ][17]を使用して、ログフィールドをテーブルスキーマで想定されているデータ型に変換してください。 + +## シークレットのデフォルト値 {#secret-defaults} {{% observability_pipelines/set_secrets_intro %}} @@ -143,7 +161,7 @@ Protobuf encoding failed: Error converting timestamp field: Can't convert '2012- {{% tab "シークレット管理" %}} - Databricks OAuth クライアントシークレット識別子: - - Observability Pipelines Worker が Databricks に認証するために使用するサービスプリンシパルの OAuth クライアントシークレットを参照します。 + - Observability Pipelines Worker が Databricks への認証に使用するサービスプリンシパルの OAuth クライアントシークレットを参照します。 - デフォルトの識別子は `DESTINATION_DATABRICKS_ZEROBUS_OAUTH_CLIENT_SECRET` です。 {{% /tab %}} @@ -155,13 +173,17 @@ Protobuf encoding failed: Error converting timestamp field: Can't convert '2012- {{% /tab %}} {{< /tabs >}} -## 宛先の動作方法{#how-the-destination-works} +## Health メトリクス {#health-metrics} + +すべての送信先から出力される[コンポーネントメトリクス][14]および[送信先バッファメトリクス][15]については、[Pipelines 使用状況メトリクス][16]ドキュメントを参照してください。Databricks 送信先メトリクスでフィルタリングまたはグループ化するには、タグ `component_type:databricks_zerobus` を使用します。 + +## 送信先の仕組み {#how-the-destination-works} -### イベントのバッチ処理{#event-batching} +### イベントのバッチ処理 {#event-batching} -これらのパラメータのいずれかが満たされると、イベントのバッチがフラッシュされます。詳細については[イベントのバッチ処理][10]を参照してください。 +イベントのバッチは、これらのパラメータのいずれかを満たしたときにフラッシュされます。詳細については、[送信先のイベントバッチ処理][10]を参照してください。 -| 最大イベント数 | 最大サイズ (MB) | タイムアウト (秒) | +| 最大イベント数| 最大サイズ (MB) | タイムアウト (秒) | |----------------|-------------------|---------------------| | なし | 10 | 1 | @@ -177,4 +199,8 @@ Protobuf encoding failed: Error converting timestamp field: Can't convert '2012- [10]: /ja/observability_pipelines/destinations/#event-batching [11]: https://docs.databricks.com/aws/en/sql/language-manual/data-types/timestamp-type [12]: /ja/observability_pipelines/processors/custom_processor#setup -[13]: /ja/observability_pipelines/processors/custom_processor/#parse_timestamp \ No newline at end of file +[13]: /ja/observability_pipelines/processors/custom_processor/#parse_timestamp +[14]: /ja/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#component-metrics +[15]: /ja/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#destination-buffer-metrics +[16]: /ja/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/ +[17]: /ja/observability_pipelines/processors/custom_processor/ \ No newline at end of file diff --git a/hugo/content/ja/observability_pipelines/destinations/datadog_byoc_logs.md b/hugo/content/ja/observability_pipelines/destinations/datadog_byoc_logs.md new file mode 100644 index 00000000000..564d06b53a8 --- /dev/null +++ b/hugo/content/ja/observability_pipelines/destinations/datadog_byoc_logs.md @@ -0,0 +1,86 @@ +--- +aliases: +- /ja/observability_pipelines/destinations/cloudprem/ +description: Observability Pipelines Worker を使用して、Datadog BYOC (Bring Your Own Cloud) + Logs にログを送信する方法を学びます。 +disable_toc: false +products: +- icon: logs + name: ログ + url: /observability_pipelines/configuration/?tab=logs#pipeline-types +title: Datadog BYOC Logs 送信先 +--- +{{< product-availability >}} + +## 概要 {#overview} + +Observability Pipelines の BYOC (Bring Your Own Cloud) Logs 送信先を使用して、Datadog BYOC Logs にログを送信します。 + + +## 前提条件 {#prerequisites} + +送信先を設定する前に、BYOC Logs クラスターをデプロイする必要があります。インストール方法については、[BYOC Logs のインストールに関するセクション][3] を参照してください。 + +## セットアップ {#setup} + +[パイプラインをセットアップ][4] する際に、BYOC Logs 送信先を設定します。パイプラインは、[UI][1]、[API][5]、または [Terraform][6] を使用してセットアップできます。このセクションの手順では、UI で設定します。 + +### オプションのバッファリング {#optional-buffering} + +パイプライン UI で BYOC Logs 送信先を選択したら、バッファリングを設定できます。 + +{{% observability_pipelines/destination_buffer %}} + +{{< img src="observability_pipelines/destinations/cloudprem_settings.png" alt="BYOC Logs 送信先の設定" style="width:35%;" >}} + +## シークレットのデフォルト {#secret-defaults} + +{{% observability_pipelines/set_secrets_intro %}} + +{{< tabs >}} +{{% tab "シークレット管理" %}} + +- BYOC Logs エンドポイント URL の識別子: + - Observability Pipelines がログを送信するインテークエンドポイントを参照します。 + - シークレットマネージャーで、次のようにします。 + - クラスター URL を定義します (例: `http://byoc-logs.acme.internal:7280`)。**注**: URL にはポート番号を含める必要があります。 + - Worker はエンドポイント URL に `/api/v2/logs` および `/api/v1/validate` を付加するため、転送ルールやファイアウォールルールを使用している場合は、これらのエンドポイントを許可する必要があります。 + - デフォルトの識別子は `DESTINATION_CLOUDPREM_ENDPOINT_URL` です。 + +{{% /tab %}} + +{{% tab "環境変数" %}} + +{{< img src="observability_pipelines/destinations/cloudprem_env_vars.png" alt="BYOC Logs 環境変数フィールドが示されているインストールページ" style="width:75%;" >}} + +- BYOC Logs エンドポイント URL + - Observability Pipelines は、BYOC Logs インテークエンドポイントにログを送信します。クラスター URL を定義します (例: `http://byoc-logs.acme.internal:7280`)。**注**: URL にはポート番号を含める必要があります。 + - Worker はエンドポイント URL に `/api/v2/logs` および `/api/v1/validate` を付加するため、転送ルールやファイアウォールルールを使用している場合は、これらのエンドポイントを許可する必要があります。 + - 次の環境変数として保存されます: `DD_OP_DESTINATION_CLOUDPREM_ENDPOINT_URL`。 + +{{% /tab %}} +{{< /tabs >}} + +## 正常性メトリクス {#health-metrics} + +すべての送信先から送信される [コンポーネントメトリクス][7] および [送信先バッファメトリクス][8] については、[Pipelines 使用状況メトリクス][9] のドキュメントを参照してください。Datadog Logs 送信先メトリクスでフィルタリングまたはグループ化するには、タグ `component_type:datadog_logs` を使用します。 + +## 送信先の動作 {#how-the-destination-works} + +### イベントのバッチ処理 {#event-batching} + +イベントのバッチは、以下のいずれかのパラメーターが満たされたときに起動されます。詳細については、[送信先のイベントのバッチ処理][2] を参照してください。 + +| 最大イベント数 | 最大サイズ (MB) | タイムアウト (秒) | +|----------------|-------------------|---------------------| +| 1,000 | 4.25 | 5 | + +[1]: https://app.datadoghq.com/observability-pipelines +[2]: /ja/observability_pipelines/destinations/#event-batching +[3]: /ja/byoc-logs/install/ +[4]: /ja/observability_pipelines/configuration/set_up_pipelines/ +[5]: /ja/api/latest/observability-pipelines/ +[6]: https://registry.terraform.io/providers/datadog/datadog/latest/docs/resources/observability_pipeline +[7]: /ja/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#component-metrics +[8]: /ja/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#destination-buffer-metrics +[9]: /ja/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/ \ No newline at end of file diff --git a/hugo/content/ja/observability_pipelines/destinations/http_client.md b/hugo/content/ja/observability_pipelines/destinations/http_client.md new file mode 100644 index 00000000000..1d0a018d144 --- /dev/null +++ b/hugo/content/ja/observability_pipelines/destinations/http_client.md @@ -0,0 +1,104 @@ +--- +description: Observability Pipelines Worker を使用して、ログ記録プラットフォームや SIEM などの HTTP クライアントにログを送信する方法を学びます。 +disable_toc: false +products: +- icon: logs + name: ログ + url: /observability_pipelines/configuration/?tab=logs#pipeline-types +- icon: metrics + name: メトリクス + url: /observability_pipelines/configuration/?tab=metrics#pipeline-types +title: HTTP クライアント送信先 +--- +{{< product-availability >}} + +## 概要 {#overview} + +Observability Pipelines の HTTP クライアント送信先を使用して、ログ記録プラットフォームや SIEM などの HTTP クライアントにログを送信します。 + +## 送信先の設定 {#set-up-destination} + +
シークレット管理の場合: HTTP クライアント URI の識別子と、該当する場合は基本認証のユーザー名とパスワードおよび TLS キーパスのみを入力してください。実際の値は入力しないでください。
+ +[パイプラインを設定][3] する際に、HTTP クライアント送信先を設定します。[UI][1]、[API][4]、または [Terraform][5] を使用してパイプラインを設定できます。このセクションの手順では、UI で設定します。 + +パイプライン UI で HTTP クライアント送信先を選択したら、次のようにします。 + +1. HTTP クライアント URI の識別子を入力します。空白のままにした場合は、[デフォルト](#secret-defaults)が使用されます。 +1. 認証戦略 ([{{< ui >}}None{{< /ui >}}] (なし)、[{{< ui >}}Basic{{< /ui >}}] (基本)、または [{{< ui >}}Bearer{{< /ui >}}]) を選択します。選択した項目に応じて、次のようにします。 + - {{< ui >}}Basic{{< /ui >}}: + - HTTP クライアントのユーザー名の識別子を入力します。空白のままにした場合は、[デフォルト](#secret-defaults)が使用されます。 + - HTTP クライアントのパスワードの識別子を入力します。空白のままにした場合は、[デフォルト](#secret-defaults)が使用されます。 + - {{< ui >}}Bearer{{< /ui >}}: + - HTTP クライアントのトークンの識別子を入力します。空白のままにした場合は、[デフォルト](#secret-defaults)が使用されます。 +1. JSON が唯一利用可能なエンコーダーです。 + +{{% observability_pipelines/secrets_env_var_note %}} + +### オプション設定 {#optional-settings} + +#### 圧縮の有効化 {#enable-compression} + +スイッチを [{{< ui >}}Enable Compression{{< /ui >}}] (圧縮の有効化) に切り替えます。有効にしたら、次のようにします。 +1. GZIP が唯一利用可能な圧縮アルゴリズムです。 +1. 使用する圧縮レベルを選択します。 + +#### TLS の有効化 {#enable-tls} + +{{% observability_pipelines/tls_settings %}} + +#### バッファリング {#buffering} + +{{% observability_pipelines/destination_buffer %}} + +## シークレットのデフォルト {#secret-defaults} + +{{% observability_pipelines/set_secrets_intro %}} + +{{< tabs >}} +{{% tab "シークレット管理" %}} + +- HTTP クライアント URI エンドポイントの識別子: + - デフォルトの識別子は `DESTINATION_HTTP_CLIENT_URI` です。 +- HTTP クライアント TLS パスフレーズの識別子 (TLS が有効な場合): + - デフォルトの識別子は `DESTINATION_HTTP_CLIENT_KEY_PASS` です。 +- 基本認証を使用している場合: + - HTTP クライアントのユーザー名の識別子: + - デフォルトの識別子は `DESTINATION_HTTP_CLIENT_USERNAME` です。 + - HTTP クライアントのパスワードの識別子: + - デフォルトの識別子は `DESTINATION_HTTP_CLIENT_PASSWORD` です。 +- Bearer 認証を使用している場合: + - HTTP クライアントの Bearer トークンの識別子: + - デフォルトの識別子は `DESTINATION_HTTP_CLIENT_BEARER_TOKEN` です。 + +{{% /tab %}} + +{{% tab "環境変数" %}} + +{{% observability_pipelines/configure_existing_pipelines/destination_env_vars/http_client %}} + +{{% /tab %}} +{{< /tabs >}} + +## 正常性メトリクス {#health-metrics} + +すべての送信先から送信される [コンポーネントメトリクス][6] および [送信先バッファメトリクス][7] については、[Pipelines 使用状況メトリクス][8] のドキュメントを参照してください。HTTP クライアント送信先メトリクスでフィルタリングまたはグループ化するには、タグ `component_type:http` を使用します。 + +## 送信先の動作 {#how-the-destination-works} + +### イベントのバッチ処理 {#event-batching} + +イベントのバッチは、以下のいずれかの条件が発生したときに起動されます。詳細については、[送信先のイベントのバッチ処理][2] を参照してください。 + +| 最大イベント数 | 最大サイズ (MB) | タイムアウト (秒) | +|----------------|-------------------|---------------------| +| 1,000 | 1 | 1 | + +[1]: https://app.datadoghq.com/observability-pipelines +[2]: /ja/observability_pipelines/destinations/#event-batching +[3]: /ja/observability_pipelines/configuration/set_up_pipelines/ +[4]: /ja/api/latest/observability-pipelines/ +[5]: https://registry.terraform.io/providers/datadog/datadog/latest/docs/resources/observability_pipeline +[6]: /ja/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#component-metrics +[7]: /ja/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#destination-buffer-metrics +[8]: /ja/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/ \ No newline at end of file diff --git a/hugo/content/ja/observability_pipelines/packs/mitre_attack_okta_enrichment.md b/hugo/content/ja/observability_pipelines/packs/mitre_attack_okta_enrichment.md new file mode 100644 index 00000000000..82aa45cee9b --- /dev/null +++ b/hugo/content/ja/observability_pipelines/packs/mitre_attack_okta_enrichment.md @@ -0,0 +1,15 @@ +--- +description: MITRE ATT&CK Okta Enrichmentパックの詳細をご覧ください。 +title: MITRE ATT&CK Okta Enrichment +--- +## 概要 {#overview} + +{{< img src="observability_pipelines/packs/mitre_attack_okta_enrichment.png" alt="MITRE ATT&CK Okta Enrichmentパック" style="width:25%;" >}} + +このパックは、OktaログにMITRE ATT&CKの戦術と手法をタグ付けします。 + +このパックの機能： + +- イベントにMITREの手法をタグ付けします +- ログイン、MFA、およびトークンイベントをマッピングします +- イベントをセキュリティ関連としてフラグ付けします \ No newline at end of file diff --git a/hugo/content/ja/observability_pipelines/processors/custom_processor.md b/hugo/content/ja/observability_pipelines/processors/custom_processor.md new file mode 100644 index 00000000000..e0a588ab986 --- /dev/null +++ b/hugo/content/ja/observability_pipelines/processors/custom_processor.md @@ -0,0 +1,96 @@ +--- +disable_toc: false +further_reading: +- link: /observability_pipelines/guide/remap_reserved_attributes/ + tag: ドキュメント + text: 予約済み属性の再マッピング +- link: /logs/guide/regex_log_parsing/ + tag: ガイド + text: 正規表現を使用した効果的な Grok パースルールの作成 +- link: https://www.datadoghq.com/blog/otel-ai-observability-pipelines-clickhouse/ + tag: ブログ + text: Observability Pipelines を使用して AI アプリから ClickHouse および Datadog へ OTel データをルーティングする +products: +- icon: logs + name: ログ + url: /observability_pipelines/configuration/?tab=logs#pipeline-types +- icon: metrics + name: メトリクス + url: /observability_pipelines/configuration/?tab=metrics#pipeline-types +title: カスタムプロセッサ +--- +{{< product-availability >}} + +## 概要 {#overview} + +このプロセッサを Vector Remap Language (VRL) と共に使用して、ログやメトリクスを変更およびエンリッチします。VRL は、データの変換用に設計された、式指向のドメイン固有言語です。可観測性のユースケース向けの組み込み関数を備えています。以下の方法でカスタム関数を使用できます。 + +- [配列](#array)、[文字列](#string)、およびその他のデータ型を操作する。 +- [コーデック](#codec)を使用して値をエンコードおよびデコードする。 +値を- [暗号化](#encrypt)および[復号化](#decrypt)する。 +あるデータ型を別のデータ型に- [強制変換](#coerce)する (例: 整数から文字列へ)。 +- [syslog の値を変換](#convert)して読み取り可能にする。 +- [エンリッチメントテーブル](#enrichment)を使用して値をエンリッチする。 +- [IP 値を操作する](#ip)。 +- ハバーシン公式を使用して[地理的距離](#map)と方位を計算する。 +カスタムルール (grok、正規表現など) や標準機能 (syslog、apache、VPC フローログなど) を使用して値を- [パース](#parse)する。詳細については、[正規表現を使用した効果的な Grok パースルールの作成][3]を参照してください。 +- イベント[パス](#path)を操作する。 + +利用可能な関数の全リストについては、[カスタム関数](#custom-functions)を参照してください。 + +カスタムプロセッサを使用して手動および動的に属性を再マッピングする方法については、[予約済み属性の再マッピング][1]を参照してください。 + +## セットアップ{#setup} + +このプロセッサをセットアップするには: + +- まだ関数を作成していない場合は、[{{< ui >}}Add custom processor{{< /ui >}}] (カスタムプロセッサを追加) をクリックし、[関数を追加する](#add-a-function)の指示に従って関数を作成します。 +- すでにカスタム関数を追加している場合は、[{{< ui >}}Manage custom processors{{< /ui >}}] (カスタムプロセッサを管理) をクリックします。リスト内の関数をクリックして、編集または削除します。検索バーを使用して、名前で関数を検索できます。[関数を追加](#add-a-function)するには [{{< ui >}}Add Custom Processor{{< /ui >}}] をクリックします。 + +### 関数を追加する {#add-a-function} + +1. カスタムプロセッサの名前を入力します。 +1. [カスタム関数][1]を使用してデータを変更するスクリプトを追加します。[{{< ui >}}Autofill with Example{{< /ui >}}] (例による自動入力) をクリックして、一般的なユースケースのいずれかを選択して開始することもできます。サンプルスクリプトのコピーアイコンをクリックし、スクリプトに貼り付けます。詳細については、[カスタムプロセッサの利用を開始する][2]を参照してください。 +1. 処理中にエラーが発生したイベントを破棄する場合は、[{{< ui >}}Drop events on error{{< /ui >}}] (エラーが発生したらイベントを破棄する) をチェックします。 +1. サンプルイベントを入力します。 +1. [{{< ui >}}Run{{< /ui >}}] (実行) をクリックして、そのイベントを関数がどのように処理するかをプレビューします。スクリプトの実行後、イベントの出力結果を確認できます。 +1. [{{< ui >}}Save{{< /ui >}}] (保存) をクリックします。 + +## カスタム関数 {#custom-functions} + +{{< whatsnext desc="関数は以下のカテゴリに分類されています。" >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#array" >}}配列{{< /nextlink >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#codec" >}}コーデック{{< /nextlink >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#convert" >}}変換{{< /nextlink >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#cryptography" >}}暗号化{{< /nextlink >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#debug" >}}デバッグ{{< /nextlink >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#enrichment" >}}エンリッチメント{{< /nextlink >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#ip" >}}IP{{< /nextlink >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#map" >}}マップ{{< /nextlink >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#number" >}}数値{{< /nextlink >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#object" >}}オブジェクト{{< /nextlink >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#parse" >}}パース{{< /nextlink >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#path" >}}パス{{< /nextlink >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#random" >}}ランダム{{< /nextlink >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#string" >}}文字列{{< /nextlink >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#system" >}}システム{{< /nextlink >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#timestamp" >}}タイムスタンプ{{< /nextlink >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#type" >}}タイプ{{< /nextlink >}} +{{< /whatsnext >}} + +{{< vrl-functions >}} + +## ヘルスメトリクス {#health-metrics} + +すべてのプロセッサから出力される[コンポーネントメトリクス][4]および[プロセッサバッファメトリクス][5]については、[パイプライン使用状況メトリクス][6]のドキュメントを参照してください。カスタムプロセッサメトリクスでフィルタリングまたはグループ化するには、タグ `component_type:remap_vrl` を使用します。 + +## 参考資料 {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ja/observability_pipelines/guide/remap_reserved_attributes +[2]: /ja/observability_pipelines/guide/get_started_with_the_custom_processor +[3]: /ja/logs/guide/regex_log_parsing/ +[4]: /ja/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#component-metrics +[5]: /ja/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#processor-buffer-metrics +[6]: /ja/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/ \ No newline at end of file diff --git a/hugo/content/ja/observability_pipelines/processors/throttle.md b/hugo/content/ja/observability_pipelines/processors/throttle.md index e8400179bfe..0e44927a7f9 100644 --- a/hugo/content/ja/observability_pipelines/processors/throttle.md +++ b/hugo/content/ja/observability_pipelines/processors/throttle.md @@ -1,8 +1,80 @@ --- +description: スロットルプロセッサーを使用して、特定の時間枠内に送信されるログ数の制限を設定する方法を学びます。 disable_toc: false -title: スロットル +products: +- icon: logs + name: ログ + url: /observability_pipelines/configuration/?tab=logs#pipeline-types +title: スロットルプロセッサー --- +{{< jqmath-vanilla >}} -{{% observability_pipelines/processors/throttle %}} +{{< product-availability >}} -{{% observability_pipelines/processors/filter_syntax %}} \ No newline at end of file +## 概要 {#overview} + +このプロセッサーを使用して、特定の時間枠内に送信されるログ数の制限を設定します。たとえば、1 秒あたり 100 ログのみが送信されるように制限を設定できます。レート制限を設定すると、ログ取り込み数の急増を捕捉し、予期しない請求額の発生を防ぐことができます。 + +## セットアップ {#setup} + +プロセッサーをセットアップするには: + +1. フィルタークエリを定義します。指定されたフィルタークエリに一致するログのみが処理されます。一致したすべてのログがスロットルされます。スロットル制限内に送信されたログや、フィルターに一致しないログは、次のステップに送信されます。スロットル制限に達した後で送信されたログは破棄されます。詳細については、「[検索構文][4]」を参照してください。 +1. スロットリングレートを設定します。これは、設定された時間枠内に特定のバケットに対して許可されるイベントの数です。**注**: このレート制限は、**ワーカー単位**で適用されます。ワーカーの数を増減させる場合は、それに応じてプロセッサーのレート制限を調整することをお勧めします。[Observability Pipelines API][1] を使用して、プログラムでレート制限を更新できます。 +1. 時間枠を設定します。 +1. フィールド別にグループ化する場合は、[{{< ui >}}Add Field{{< /ui >}}] (フィールドを追加) をクリックします。 + +## スロットルプロセッサーの動作 {#how-the-throttle-processor-works} + +スロットルプロセッサーは、指定された時間枠内に送信されるログの数にレート制限を設定します。[クォータプロセッサー][2] と似ていますが、スロットルプロセッサーとクォータプロセッサーの主な違いは、クォータプロセッサーの時間枠が 24 時間に固定されており変更できないのに対し、スロットルプロセッサーの時間枠は設定可能である点です。スロットルプロセッサーの時間枠は設定可能なため、このプロセッサーには、設定したスロットリングレートと時間枠に基づいた容量補充レートがあります。詳細については、「[容量補充レート](#capacity-replenishment-rate)」を参照してください。 + +次の表は、スロットルプロセッサーとクォータプロセッサーを比較したものです。 + +| 機能 | クォータプロセッサー | スロットルプロセッサー | +|---------|----------------|-------------------| +| 時間枠 | 24 時間に固定 | 設定可能 | +| イベントの初期バーストの処理 | 固定された 1 日あたりの上限までデータを処理します。| 設定したスロットリングレートまでイベントを処理します。| +| 制限に達した後 | 24 時間の時間枠がリセットされるまで、データの処理を停止します。| 計算された一定のレートで処理を継続します。| +| リセットメカニズム | 24 時間ごとにリセットされます。| 継続的に補充されます。Worker またはパイプラインを再デプロイした場合も、時間枠がリセットされます。| +| 制限の保存または追跡方法 | クォータ制限はバックエンドに保存されるため、Worker を再起動しても制限が保持されます。| スロットル制限は Worker のメモリ内で追跡されるため、Worker またはパイプラインを再デプロイすると時間枠がリセットされます。| + +### 初期容量 {#initial-capacity} + +{{< img src="observability_pipelines/processors/throttling_rate.png" alt="スロットリングレートが 1,000 K に設定されているスロットルプロセッサー" style="width:40%;" >}} + +スロットルプロセッサーが有効な場合、プロセッサーが即座に通過を許可するログの数は、設定された [{{< ui >}}Throttling Rate{{< /ui >}}] (スロットリングレート) に基づいて決まります。たとえば、[{{< ui >}}Throttling Rate{{< /ui >}}] が 60 秒間で `1000` イベントに設定されており、プロセッサーが有効になった瞬間に 5,000 件のイベントを受信した場合は、次のようになります。 + +- プロセッサーは、初期容量である 1,000 件のイベントの通過を許可します。 +- 残りの 4,000 件のイベントは破棄されます。 +- この初期動作は、クォータプロセッサーの場合も同じです。 + +### 容量補充レート {#capacity-replenishment-rate} + +スロットルプロセッサーは [汎用セルレートアルゴリズム][3] を使用しているため、一定のレートでイベントを通過させることができます。補充レートはスロットルプロセッサーの設定に基づいており、1 秒間に特定の数のイベントの通過を許可します。このレートは次のように計算できます。 + +$$\text"スロットルレート" / \text"時間枠 (秒数)"$$ + +#### 例 {#example} + +以下のプロセッサー設定を使用する場合: +- スロットルレート = 1,000 件のイベント +- 時間枠 = 60 分 (3,600 秒) + +容量補充レートは次のようになります。 + +$$\text"1,000 件のイベント" / \text"60 分" ≈ \text"17 件のイベント"/ \text"分" ≈ \text"0.28 件のイベント"/ \text"秒"$$ + +`T` がプロセッサーの有効化された時刻であり、その時点でプロセッサーが 5,000 件のイベントを受信した場合、`T` に基づいてプロセッサーが通過を許可するイベント数は次のようになります。 +- `T + 0` 分 (プロセッサーが有効化された時点): + - 1,000 件のイベントが処理されます。 + - 4,000 件のイベントが破棄されます。 +- `T + 1`分: 約 17 件のイベントを処理できます。 +- `T + 2` 分: 約 17 件のイベントを処理できます。 +- …プロセッサーは、毎分約 17 件という一定のレートでイベントの処理を継続し、1 分経過するまで残りのイベントは破棄します。 + +**注**: 補充レートによって、初期容量後の最大スループットが決まります。必要に応じて、スロットリングレートを調整し、スループットを高くしたり低くしたりできます。 + +[1]: /ja/api/latest/observability-pipelines/#update-a-pipeline +[2]: /ja/observability_pipelines/processors/quota/ +[3]: https://en.wikipedia.org/wiki/Generic_cell_rate_algorithm +[4]: /ja/observability_pipelines/search_syntax/logs/ \ No newline at end of file diff --git a/hugo/content/ja/observability_pipelines/sources/amazon_s3.md b/hugo/content/ja/observability_pipelines/sources/amazon_s3.md new file mode 100644 index 00000000000..a900dd409e0 --- /dev/null +++ b/hugo/content/ja/observability_pipelines/sources/amazon_s3.md @@ -0,0 +1,118 @@ +--- +description: Observability Pipelines Worker を使用して Amazon S3 からログを収集する方法を学びます。 +disable_toc: false +products: +- icon: logs + name: ログ + url: /observability_pipelines/configuration/?tab=logs#pipeline-types +title: Amazon S3 ソース +--- +{{< product-availability >}} + +## 概要 {#overview} + +Observability Pipelines の Amazon S3 ソースを使用して、Amazon S3 からログを受信します。 + +## 前提条件{#prerequisites} + +{{% observability_pipelines/prerequisites/amazon_s3 %}} + +## セットアップ {#setup} + +
シークレット管理の場合: Amazon S3 URL の識別子と、該当する場合は TLS キーパスの識別子のみを入力してください。実際の値を入力しないでください
。 + +[パイプラインをセットアップ][1]する際に、このソースを設定します。パイプラインは、[UI][3]、[API][4]、または [Terraform][5] を使用してセットアップできます。このセクションの手順は、UI でソースをセットアップするためのものです。 + +パイプライン UI で Amazon S3 ソースを選択した後、 + +1. Amazon S3 URL の識別子を入力します。空白のままにすると、[デフォルト](#secret-defaults)が使用されます。 +1. AWS リージョンを入力します。 + +{{% observability_pipelines/secrets_env_var_note %}} + +### オプション設定 {#optional-settings} + +#### AWS 認証 {#aws-authentication} + +{{< ui >}}AWS authentication{{< /ui >}} オプションを選択します。{{< ui >}}Assume role{{< /ui >}} を選択した場合、 +1. 引き受ける IAM ロールの ARN を入力します。 +1. 必要に応じて、引き受けロールのセッション名と外部 ID を入力します。 + +#### TLS を有効にする {#enable-tls} + +{{% observability_pipelines/tls_settings %}} + +## シークレットのデフォルト値 {#secret-defaults} + +{{% observability_pipelines/set_secrets_intro %}} + +{{< tabs >}} +{{% tab "シークレット管理" %}} + +- Amazon S3 URL 識別子: + - S3 バケットが通知イベントを送信する SQS キューの URL を参照します。 + - デフォルトの識別子は `SOURCE_AWS_S3_SQS_URL` です。 +- Amazon S3 TLS パスフレーズ識別子 (TLS が有効な場合): + - デフォルトの識別子は `SOURCE_AWS_S3_KEY_PASS` です。 + +{{% /tab %}} + +{{% tab "環境変数" %}} + +{{% observability_pipelines/configure_existing_pipelines/source_env_vars/amazon_s3 %}} + +{{% /tab %}} +{{< /tabs >}} + +## AWS 認証 {#aws-authentication-1} + +{{% observability_pipelines/aws_authentication/instructions %}} + +### 権限 {#permissions} + +{{% observability_pipelines/aws_authentication/amazon_s3_source/permissions %}} + +## Health メトリクス {#health-metrics} + +すべてのソースから出力される[コンポーネントメトリクス][6]および[ソースバッファメトリクス][7]については、[Pipelines 使用状況メトリクス][8]のドキュメントを参照してください。Amazon S3 ソース メトリクスでフィルタリングまたはグループ化するには、タグ `component_type:aws_s3` を使用します。 + +### Amazon S3 メトリクス {#amazon-s3-metrics} + +- `component_id` タグを使用して、個々のコンポーネントごとにフィルタリングまたはグループ化します。 +- ソース タイプでフィルタリングまたはグループ化するには、`component_type` タグを使用します。 + +`pipelines.sqs_message_received_messages_total` +: **説明**: 受信した SQS メッセージの数。 +: **メトリクスタイプ**: カウント + +`pipelines.sqs_message_processing_succeeded_total` +: **説明**: 正常に処理された SQS メッセージの数。 +: **メトリクスタイプ**: カウント + +`pipelines.sqs_message_delete_succeeded_total` +: **説明**: SQS メッセージの削除に成功した数。 +: **メトリクスタイプ**: カウント + +`pipelines.sqs_message_defer_succeeded_total` +: **説明**: 可視性タイムアウトの延期に成功した SQS メッセージの数。 +: **メトリクスタイプ**: カウント + +`pipelines.sqs_s3_event_record_ignored_total` +: **説明**: `ObjectCreated` イベントの種類ではないため無視された、SQS メッセージ内の S3 イベントレコードの数。 +: **メトリクスタイプ**: カウント + +`pipelines.s3_object_processing_succeeded_duration_seconds` +: **説明**: S3 オブジェクトの処理に成功するまでにかかった時間 (秒)。 +: **メトリクスタイプ**: 分布 + +`pipelines.s3_object_processing_failed_duration_seconds` +: **説明**: 処理に失敗した S3 オブジェクトの処理にかかった時間 (秒)。 +: **メトリクスタイプ**: 分布 + +[1]: /ja/observability_pipelines/configuration/set_up_pipelines/ +[3]: https://app.datadoghq.com/observability-pipelines +[4]: /ja/api/latest/observability-pipelines/ +[5]: https://registry.terraform.io/providers/datadog/datadog/latest/docs/resources/observability_pipeline +[6]: /ja/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#component-metrics +[7]: /ja/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#source-buffer-metrics +[8]: /ja/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/ \ No newline at end of file diff --git a/hugo/content/ja/partners/multi_tenant_billing/customer-contracts-management.md b/hugo/content/ja/partners/multi_tenant_billing/customer-contracts-management.md new file mode 100644 index 00000000000..453740345d2 --- /dev/null +++ b/hugo/content/ja/partners/multi_tenant_billing/customer-contracts-management.md @@ -0,0 +1,39 @@ +--- +description: 管理組織（Admin Org）から、パートナーの取引先（顧客、契約、請求書）を管理します。 +title: 顧客契約 +--- +
+「顧客契約」はプレビュー版です。 +
+ +## 概要 {#overview} + +「顧客契約」を使用すると、パートナーはDatadogとの取引に関する顧客、契約、請求書を一元管理できます。パートナーは、日常の情報照会のためにパートナーアカウントチームに依頼するのではなく、この情報を直接参照できます。 + +管理組織（Admin Org）の {{< ui >}}Plan & Usage{{< /ui >}} > {{< ui >}}Customer Contracts{{< /ui >}} に移動します。まだ設定されていない場合は、[管理組織（Admin Org）をリクエストする][2] を参照してください。 + +{{< img src="partners/multi_tenant_billing/customer_contracts.png" alt="管理組織（Admin Org）の「プランと使用量」の下にある「顧客契約」タブ。顧客と契約が一覧表示されます。" style="width:100%;" >}} + +**注**：「顧客契約」を表示するには、「請求の読み取り（Billing Read）」権限が必要です。 + +## 含まれるもの {#whats-included} + +- 管理組織（Admin Org）に接続されているすべての顧客、およびその現在および過去の契約。更新が近づいている、または更新日を過ぎている契約の更新リマインダーも含まれます。 +- 契約MRR（CMRR）、利用MRR（UMRR）、影響ステータス、契約開始日と終了日、製品ごとの料金、および注文書のPDF。 +- ドローダウン契約の場合、残高、予測超過分、および契約終了日と比較した予測枯渇日。 +- MSP契約の場合、各契約にどの顧客が属しているか。 +- 契約ごとの割引と利益率の可視化。 +- 各顧客に対して顧客価格設定が有効になっているか、まだ設定されていないか、または契約変更後に更新が必要か。 +- 顧客ごとの主要な連絡先：DatadogのCSM、DatadogのAE、パートナーアカウントチーム、および請求書を受け取る請求担当者。 + +{{< img src="partners/multi_tenant_billing/customer_contracts_detail.png" alt="顧客の支出概要、ドローダウンの枯渇状況、契約情報、および連絡先を表示する「顧客契約」詳細パネル。" style="width:100%;" >}} + +請求書は顧客ごとに発行日、支払期限、金額、支払状況とともに一覧表示され、「顧客契約」のメインページで延滞件数と合計に集計されます。 + +{{< img src="partners/multi_tenant_billing/customer_contracts_invoices.png" alt="顧客の請求書番号、日付、金額、およびステータスを一覧表示する「顧客契約」の請求書タブ。" style="width:100%;" >}} + +## 関連ドキュメント {#related-docs} + +- [管理組織（Admin Org）をリクエストする][2] + +[2]: /ja/partners/multi_tenant_billing/#requesting-an-admin-org \ No newline at end of file diff --git a/hugo/content/ja/real_user_monitoring/application_monitoring/roku/_index.md b/hugo/content/ja/real_user_monitoring/application_monitoring/roku/_index.md new file mode 100644 index 00000000000..ca23d6decd9 --- /dev/null +++ b/hugo/content/ja/real_user_monitoring/application_monitoring/roku/_index.md @@ -0,0 +1,32 @@ +--- +aliases: +- /ja/real_user_monitoring/mobile_and_tv_monitoring/setup/roku/ +- /ja/real_user_monitoring/mobile_and_tv_monitoring/roku +description: Roku プロジェクトから RUM および Error Tracking データを収集します。 +further_reading: +- link: /real_user_monitoring/application_monitoring/roku/advanced_configuration + tag: ドキュメント + text: RUM Roku の高度な設定 +- link: https://github.com/DataDog/dd-sdk-roku + tag: ソースコード + text: dd-sdk-roku のソースコード +- link: /real_user_monitoring + tag: ドキュメント + text: Datadog RUM を探索する +site_support_id: rum_roku +title: Roku の監視 +--- +## 概要{#overview} + +Datadog Real User Monitoring (RUM) を使用すると、アプリケーションの個々のユーザーのリアルタイムパフォーマンスとユーザー体験を可視化し、分析できます。 + +## Roku アプリケーションの監視を開始する{#start-monitoring-roku-applications} + +Roku 向けの RUM を使い始めるには、アプリケーションを作成し、Roku SDK を設定します。 + +{{< whatsnext desc="このセクションには、次のトピックが含まれています。">}} + {{< nextlink href="/real_user_monitoring/application_monitoring/roku/setup">}}セットアップ: Roku SDK のセットアップ方法、バックグラウンドイベントの追跡、およびデバイスがオフラインの時のデータ送信方法について説明します。{{< /nextlink >}} + {{< nextlink href="/real_user_monitoring/application_monitoring/roku/error_tracking">}}クラッシュレポート: クラッシュレポートを追加し、難読化解除されたスタックトレースを取得し、実装をテストします。{{< /nextlink >}} + {{< nextlink href="/real_user_monitoring/application_monitoring/roku/advanced_configuration">}}高度な設定: ユーザーセッションの拡充、イベントとデータの管理、カスタムグローバル属性の追跡、初期化パラメーターの確認、RUM イベントの変更や破棄などを行います。{{< /nextlink >}} + {{< nextlink href="/real_user_monitoring/application_monitoring/roku/web_view_tracking">}}Web ビューの追跡: Web ビューを監視し、モバイルアプリケーションの監視の死角をなくします。{{< /nextlink >}} +{{< /whatsnext >}} \ No newline at end of file diff --git a/hugo/content/ja/security/cloud_siem/detect_and_monitor/custom_detection_rules/anomaly.md b/hugo/content/ja/security/cloud_siem/detect_and_monitor/custom_detection_rules/anomaly.md new file mode 100644 index 00000000000..cc58dbf0d5e --- /dev/null +++ b/hugo/content/ja/security/cloud_siem/detect_and_monitor/custom_detection_rules/anomaly.md @@ -0,0 +1,36 @@ +--- +description: 異常検知方法の仕組みについて説明します。 +disable_toc: false +title: 異常 +--- +## 概要 {#overview} + +異常検知はログを分析して、ログボリュームの異常なスパイクを特定します。これは、攻撃、誤設定、暴走プロセスなどの問題を示している可能性があります。 + +異常検知ルールの設定方法については、「[Create Rule][1]」を参照してください。 + +## 異常検知の仕組み {#how-anomaly-detection-works} + +異常検知ルールは以下の通りです。 + +- 受信したログを時間バケットに集約し、ベースラインを計算します。 + - 上限値は、最大2週間分の過去のログを使用して、最近の履歴の99.5パーセンタイルを反映します。 +- 評価ごとに最新の評価ウィンドウを確認し、系列がその境界をどれだけ超えているかを測定します。 + - ウィンドウ全体で超過分が十分に大きい場合にシグナルがトリガーされます。 + +異常検知方法は、お客様の通常のパターンに適応し、日常的な変動によるノイズを低減します。 + +**注記**: 異常検知方法はスパイクのみを検知します。ログボリュームの減少についてはアラートを送信しません。 + +### 季節性と学習期間 {#seasonality-and-learning-period} + +このアルゴリズムは、日次および週次の季節性を自動的に考慮するため、週末の急増のような定期的なピークではアラートが発生しません。 + +新しいルールや新しく観測された値に対しては、短い学習期間が適用されます `group by`。学習期間中は、ベースラインを構築するためにデータが収集されます。 + +## ベストプラクティス {#best-practices} + +- クエリのスコープを絞り込みます。サービス、環境、チーム、またはエンドポイントでフィルタリングして、ノイズを低減します。 +- まずは管理されたデフォルトルールで広範囲をカバーし、その後、ログボリュームの大きいソースに対してカスタムの異常検知ルールを追加してください。 + +[1]: /ja/security/cloud_siem/detect_and_monitor/custom_detection_rules/create_rule?cloud_siem_detection_rule_detection_method=anomaly \ No newline at end of file diff --git a/hugo/content/ja/security/workload_protection/_index.md b/hugo/content/ja/security/workload_protection/_index.md new file mode 100644 index 00000000000..516ca56620f --- /dev/null +++ b/hugo/content/ja/security/workload_protection/_index.md @@ -0,0 +1,150 @@ +--- +aliases: +- /ja/security_platform/cloud_workload_security/ +- /ja/security/cloud_workload_security/ +- /ja/security/cloud_workload_security/agent_expressions +- /ja/security/cloud_workload_security/backend/ +- /ja/security/threats/security_profiles +- /ja/security/threats/runtime_anomaly_detection +- /ja/security/threats/ +- /ja/security/threats/agent +- /ja/security/workload_protection/agent +cascade: +- _target: + path: /security/workload_protection/backend_linux + aliases: + - /security/threats/backend_linux +- _target: + path: /security/workload_protection/backend_windows + aliases: + - /security/threats/backend_windows +- _target: + path: /security/workload_protection/linux_expressions + aliases: + - /security/threats/linux_expressions +- _target: + path: /security/workload_protection/windows_expressions + aliases: + - /security/threats/windows_expressions +description: Datadog Workload Protection を使用して、ホスト、コンテナ、サーバーレスワークロード全体で実行時の脅威を検出し、対応します。 +further_reading: +- link: https://www.datadoghq.com/blog/workload-protection-investigation/ + tag: ブログ + text: Datadog Workload Protection を使用して、断片化された実行時のシグナルを首尾一貫した攻撃のストーリーに変える +- link: https://www.datadoghq.com/blog/workload-protection-findings + tag: ブログ + text: Workload Protection の検出結果を使用して、実行時の体制の問題を表面化させ、修正する +- link: https://learn.datadoghq.com/courses/workload-protection-detect-compromises + tag: ラーニングセンター + text: Workload Protection でホストとコンテナの侵害を検出する +- link: https://learn.datadoghq.com/courses/workload-protection-enable-manage + tag: ラーニングセンター + text: Workload Protection を有効にして管理する +title: Workload Protection +--- +Datadog Workload Protection は、環境全体のファイル、ネットワーク、プロセスの活動を継続的に監視することで、インフラストラクチャーにリアルタイムの可視性と防御を提供します。脅威が発生した瞬間に検出し、セキュリティシグナルと検出結果を生成します。これらを使用して、悪意のある動作がワークロードに影響を与える前に、特定、調査、阻止します。 + +Workload Protection は、Datadog Security プラットフォームの一部です。シグナルは、誤構成スキャン、脆弱性評価、コードセキュリティの検出結果と相関するため、実行時の攻撃を既存の弱点と関連付けることができます。Datadog プラットフォーム上で実行されるため、インフラストラクチャーのメトリクス、トレース、ログとも連携します。そのコンテキストは、脅威のスコープを理解し、攻撃の経緯を再構築する上で役立ちます。 + +## 実行時以外の脅威検出 {#beyond-runtime-threat-detection} + +Workload Protection は、実行時の脅威検出に限定されません。多くの組織が、さまざまなセキュリティおよび運用のユースケースでこれを使用しています。 + +- **コンプライアンスの検証:** Workload Protection は、ポリシー違反、リスクの高い設定、不正な変更について実行時のアクティビティを継続的に監視することで、PCI、FedRAMP、SOC 2 などの規制フレームワークへの準拠を検証する上で役立ちます。 + +- **実行時のセキュリティ体制:** Workload Protection は、安全でない実行時の慣行や機密設定のドリフトを特定することでセキュリティ体制を改善し、弱点が悪用される前に発見できるようにします。 + +- **Infrastructure Monitoring:** Workload Protection は、セキュリティ関連かどうかにかかわらず、あらゆる種類のランタイム動作を追跡します。カスタムワークロードのデバッグから、システムレベルのプロセスやリモートユーザーセッションの監視まで、環境がどのように動作しているかについてのリアルタイムの可視性を提供します。 + +{{< img src="security/workload_protection/k8s_remote_access.png" alt="Kubernetes リモートユーザーセッションの内訳" width="100%">}} + +## 仕組み {#how-it-works} + +Workload Protection は、収集したアクティビティを Datadog Agent と Datadog の 2 か所で評価します。 + +### 設計によるリソースの節約 {#saving-resources-by-design} + +Workload Protection の検出ルールは複雑で、時間とプロセスにわたる複数のデータポイントを関連付けます。すべてのルールを Agent のホストで評価すると、この複雑さにより、かなりのコンピューティングリソースが要求されることになります。 + +Datadog は、ワークロードからセキュリティに関連しないアクティビティを除外する効率的なルールで Agent を軽量に保ち、残りのアクティビティを Datadog バックエンドの脅威検出ルールと検出結果ルールを使用して処理することで、この問題を解決します。Agent ルールは[ポリシー][14]で構成されており、 {{< tooltip glossary="Remote Configuration" case="title" >}} または手動でデプロイします。ルールとポリシーは、Datadog、Agent 構成ファイル、または Datadog Terraform プロバイダーで管理できます。 + +{{< img src="security/workload_protection/workload_protection_detection_architecture.png" alt="Workload Protection アーキテクチャの概要" width="100%">}} + +### ランタイムアクティビティの収集 {#collecting-runtime-activity} + +Datadog Agent は、ワークロードからランタイムアクティビティを収集します。収集メカニズムはプラットフォームによって異なります。 + +- **Linux**: 最も幅広い機能サポートを提供する eBPF Agent。 +- **AWS Fargate**: cws-instrumentation トレーサー。Fargate は eBPF アクセスを提供しないため、この Agent は代わりに ptrace を使用します。File Integrity Monitoring やプロセス実行監視など、主要な Workload Protection 機能をカバーしています。 +- **Windows**: Windows ドライバー。 + +Linux および Windows 全体で、Workload Protection はプロセス、ファイルシステム、カーネル、ネットワークアクティビティにわたる 40 種類以上のイベントタイプをカバーしています。各 Agent がサポートするディストリビューション、バージョン、クラウド環境については、[セットアップ][1]を参照してください。 + +### アクティビティの評価 {#evaluating-activity} + +Agent ルールは軽量なフィルタリングを実行するため、すべてのホストで効率的に動作します。Datadog は、時間とプロセスにわたるより複雑な相関関係を評価します。 + +1. [Agent ルール][6]は、Agent のホスト上のシステムアクティビティを評価します。 +2. アクティビティが Agent ルールの式と一致すると、Agent は [エージェントイベント][7]を生成し、Datadog に渡します。 +3. Datadog は、エージェントイベントを[検出ルール][8]および[検出結果ルール][9]と照らし合わせて評価します。 +4. 検出ルールが一致すると、シグナルが生成され、[シグナル][10]に表示されます。Agent イベントの属性が[脅威インテリジェンスインジケーター][13]と一致する場合、一致したインジケーターも表示されます。 +5. 検出結果ルールが一致すると、検出結果が生成され、[検出結果][11]に表示されます。 +6. シグナルの重大度、ルールタイプ、タグ、属性に一致する[通知ルール][12]がトリガーされます。 + +Workload Protection には 350 以上の Agent ルールと 200 以上の検出ルールが付属しており、MITRE ATT&CK の戦術とテクニックの大部分をカバーしています。独自のルールを作成することもでき、複雑な侵害インジケーターに対してのみアラートを送信する Agent 内ステートマシンも作成可能です。 + +### 脅威への対応 {#responding-to-threats} + +対応アクションは Agent 内で実行されます。Agent は、プロセスやコンテナを終了させたり、eBPF ベースのフィルターを使用してネットワークトラフィックをブロックしたりできます。これらのアクションは、次の 2 つの方法でトリガーできます。 + +- **自動対応**は Agent ルールにアクションを関連付けるため、ルールが一致するとすぐに Agent が動作します。 +- **手動対応**では、シグナルが生成された後にそれに基づいてアクションを実行できます。 + +どちらも、Agent で強制適用が有効になっている必要があります。[脅威に対応する][4]を参照してください。 + +Agent の代わりに Datadog から対応することもできます。シグナルから[ワークフロー][15]をトリガーするか、シグナルを既存の対応パイプラインと統合します。[シグナルアクション][16]を参照してください。 + +## 次のステップ {#next-steps} + +### セットアップ {#setup} + +[セットアップ][1]ガイドから始めます。Agent のデプロイ方法、サポートされている環境、およびプレイグラウンドスクリプトを使用して Workload Protection の機能を試す方法について説明しています。 + +### 検出と監視 {#detect-and-monitor} + +[検出と監視][2]ページを読んで、Agent イベントがどのように Workload Protection のシグナルや検出結果に変換されるかを理解します。これらのページは、組み込み (OOTB) 検出機能の調査や、独自の検出ロジックの作成に役立ちます。 + +### 調査とトリアージ {#investigate-and-triage} + +[調査とトリアージ][3]のページを参照して、Workload Protection で利用可能なエクスプローラーやアプリ内で表示する内容を確認します。これらのページは、プラットフォームによって生成されたイベント、シグナル、検出結果を最大限に活用する上で役立ちます。 + +### 脅威に対応する {#respond-to-threats} + +[脅威に対応する][4]ページでは、自動応答および手動応答の設定方法を説明しています。Agent の強制適用要件、利用可能な応答アクション、およびその結果の解釈方法について説明しています。 + +### カバレッジ {#coverage} + +[カバレッジ][5]を使用して、ホスト、コンテナ、サーバーレスワークロード全体における Workload Protection の状況を、統合されたリアルタイムビューで取得します。ポリシー展開の問題、保護されていないアセット、および検出のギャップが悪用可能なリスクになる前に特定します。 + +### ガイド {#guides} + +{{< whatsnext desc="Workload Protection について理解を深めるため、ケース主導の例を活用します。" >}} +{{< nextlink href="/security/workload_protection/guide/tuning-rules" >}}Workload Protection のセキュリティシグナルを調整するためのベストプラクティス{{< /nextlink >}} +{{< /whatsnext >}} + +[1]: /ja/security/workload_protection/setup +[2]: /ja/security/workload_protection/detect_and_monitor +[3]: /ja/security/workload_protection/investigate_and_triage +[4]: /ja/security/workload_protection/respond_and_report +[5]: /ja/security/workload_protection/inventory +[6]: /ja/security/workload_protection/detect_and_monitor/agent_rules +[7]: /ja/security/workload_protection/investigate_and_triage/agent_events +[8]: /ja/security/workload_protection/detect_and_monitor/detection_and_finding_rules/detection_rules +[9]: /ja/security/workload_protection/detect_and_monitor/detection_and_finding_rules/finding_rules +[10]: /ja/security/workload_protection/investigate_and_triage/security_signals +[11]: /ja/security/workload_protection/investigate_and_triage/security_findings +[12]: /ja/security/notifications/rules +[13]: /ja/security/workload_protection/detect_and_monitor/threat_intelligence +[14]: /ja/security/workload_protection/detect_and_monitor/agent_rules/policy_management +[15]: /ja/actions/workflows/ +[16]: /ja/security/workload_protection/investigate_and_triage/security_signals/actions \ No newline at end of file diff --git a/hugo/content/ja/security/workload_protection/detect_and_monitor/detection_and_finding_rules/detection_rules.md b/hugo/content/ja/security/workload_protection/detect_and_monitor/detection_and_finding_rules/detection_rules.md new file mode 100644 index 00000000000..1a1da5cdf79 --- /dev/null +++ b/hugo/content/ja/security/workload_protection/detect_and_monitor/detection_and_finding_rules/detection_rules.md @@ -0,0 +1,99 @@ +--- +aliases: +- /ja/security/workload_protection/detect_and_monitor/detection_rules +- /ja/security/workload_protection/setup/ootb_rules +description: Agent イベントを分析して Workload Protection のセキュリティシグナルを生成する、バックエンドルールを作成および管理します。 +disable_toc: false +title: 検出ルール +--- +検出ルールは、[Agent イベント][1]を分析することで、環境内の脅威を検出するために使用されるバックエンドロジックを記述します。検出ルールが一致すると、Workload Protection は Datadog で調査および対応可能な[セキュリティシグナル][2]を生成します。 + +検出ルールは、1 つ以上の Agent ルール (`@agent.rule_id` で参照) を組み合わせ、しきい値や異常検知などの検出方法を適用し、ノイズを抑制し、アラートを適切なチームに振り分けます。Agent ルールはホスト上のランタイムテレメトリを収集し、検出ルールはそのテレメトリを、優先順位付けされた脅威検出情報へと変換します。 + +このページでは、すぐに使える (OOTB) 検出ルールの仕組みと、Datadog でカスタム検出ルールを作成する方法について説明します。 + +## OOTB 検出ルール {#ootb-detection-rules} + +Workload Protection には、Datadog が管理する OOTB **検出ルール**が含まれています。これらのルールは、Agent ルールによって収集されたテレメトリとバックエンドの式を組み合わせ、疑わしいアクティビティが検出された場合にセキュリティシグナルを生成します。[デフォルトの検出ルール][3]で全カタログを参照するか、Datadog の Workload Protection の[検出ルール][4]リストで、検出ルールを確認および調整できます。 + +## カスタム検出ルールを作成する {#create-a-custom-detection-rule} + +カスタム検出ルールを作成するには、Workload Protection の[検出ルール][4]ページに移動し、{{< ui >}}New Rule{{< /ui >}} をクリックします。{{< ui >}}Assisted rule creator{{< /ui >}} を使用して、Agent ルールと検出ルールの両方を単一のフローで作成することもできます。「[カスタム Agent ルールと検出ルールを一緒に作成する](#create-the-custom-agent-and-detection-rules-together)」を参照してください。 + +ルールエディターでは、5 つのステップで設定を行います。 + +### ステップ 1: リアルタイムルールを定義する {#step-1-define-your-real-time-rule} + +使用する検出方法を選択します。 + +- {{< ui >}}Threshold{{< /ui >}}: 時間枠と、シグナルをトリガーするために必要な一致イベント数を定義します。たとえば、5 分以内に 5 件を超える一致イベントが発生した場合にトリガーします。 +- {{< ui >}}New value{{< /ui >}}: 追跡対象の属性が、これまで検知されたことのない値で出現した場合にトリガーします。 +- {{< ui >}}Anomaly{{< /ui >}}: イベントの量や動作が、想定されるベースラインから逸脱した場合にトリガーします。 +- {{< ui >}}Content anomaly{{< /ui >}}: 一致するイベントの内容が、過去のデータと比較して統計的に異常である場合にトリガーします。 + +### ステップ 2: 検索クエリを定義する {#step-2-define-search-query} + +ルールが評価する [Agent イベント][1]を選択するクエリを定義します。検索クエリは、シグナルを生成するかどうかを判断する際に考慮されるイベントを決定します。 + +次のことができます。 + +- Agent イベントを**特定のフィールド**でフィルタリングしてクエリを絞り込み、検出の精度を高めます。たとえば、`@process.executable.path`、`@file.path`、または `@agent.rule_id` でフィルタリングします。検出ルールは、バックエンドイベントスキーマに含まれる任意のフィールドをクエリに使用できます。利用可能なフィールドの一覧については、[Linux バックエンド構文][13]および [Windows バックエンド構文][14]を参照してください。 +- 複数の条件を組み合わせて、ルールをインフラストラクチャーまたはワークロードのサブセットに絞り込みます。 + +**しきい値**ルールの場合は、**ルックバックウィンドウ**も定義します。これは、Datadog がルール条件とカウントを比較する前に、一致するイベントをカウントする期間です。 + +ルールを公開する前に、[Agent Events Explorer][6] を使用してクエリをテストし、どのイベントが一致するかを確認できます。 + +### ステップ 3: ルール条件を定義する {#step-3-define-rule-conditions} + +ルールがシグナルを生成するタイミングを決定する条件を設定します。**複数のケース**を作成し、それぞれに異なる重大度レベルを設定することができます。 + +たとえば、しきい値ルールでは次のように定義できます。 + +- {{< ui >}}Critical{{< /ui >}}: 5 分以内に 10 件を超える一致イベントが発生した場合。 +- {{< ui >}}High{{< /ui >}}: 5 分以内に 5 件を超える一致イベントが発生した場合。 +- {{< ui >}}Medium{{< /ui >}}: 5 分以内に 2 件を超える一致イベントが発生した場合。 + +{{< ui >}}Add notify{{< /ui >}} セクションでは、ルールがトリガーされたときに通知を受け取るユーザーをオプションで設定できます。個別の受信者を追加することも、[通知ルール][7]を利用して複数の検出ルール全体のアラート通知を管理することもできます。 + +### ステップ 4: プレイブックを記述する {#step-4-describe-your-playbook} + +[Signals Explorer][2] で開いたときに表示される、シグナルの**タイトル**と**説明**を設定します。 + +1. {{< ui >}}Rule name{{< /ui >}} を入力します。この名前は検出ルールリストに表示され、生成されたセキュリティシグナルのタイトルになります。 +2. {{< ui >}}Rule message{{< /ui >}} セクションでは、[通知変数][8]と Markdown を使用して、何が発生したか、また対応担当者がどのように対処すべきかを記述します。テンプレート変数は、トリガーとなった Agent イベントから取得した動的なコンテキストを、シグナルとその通知に直接挿入します。 +3. {{< ui >}}Tag resulting signals{{< /ui >}} ドロップダウンメニューを使用して、生成されたシグナルにタグを追加します。例: `security:attack` または `technique:T1059-command-and-scripting-interpreter`。 + +### ステップ 5: 抑制を作成する{#step-5-create-a-suppression} + +オプションで**抑制クエリ**を追加し、特定のインフラストラクチャーやイベントをこのルールから除外することで、ノイズを減らします。抑制は、該当するアクティビティが想定内または無害なものである場合に、シグナルが生成されるのを防ぐのに役立ちます。 + +たとえば、既知の自動化ユーザーをルールから除外するには、`@usr.name:automation-bot` のような抑制クエリを追加します。 + +このステップでは、過去の**一致イベント数の概要**も提供されるため、ルールを保存する前に、どの程度の頻度でルールがトリガーされていたかを推定できます。このプレビューを使用して、クエリ、しきい値、または抑制を調整し、アラートが過剰に発生することを防ぎます。 + +検出ルール全体での抑制の詳細については、「[抑制][9]」を参照してください。 + +## カスタム Agent と検出ルールを一緒に作成する{#create-the-custom-agent-and-detection-rules-together} + +デフォルトの Agent ルールがどのようにポリシーにパッケージ化され、デプロイされるかについては、「[Agent ルール][10]」の概要および「[ポリシー管理][11]」を参照してください。 + +Agent ルールと検出ルールは、次のいずれかの方法で定義できます。 + +- {{< ui >}}Assisted rule creator{{< /ui >}}: Datadog でカスタムの Workload Protection の[検出ルール][4]を開始し、ウィザードを使用して Agent 式とバックエンドの検出ルールロジックの両方を設定します。 +- {{< ui >}}Manual rule creator{{< /ui >}}: [Agent Configuration][12] からポリシーを開くか作成し、{{< ui >}}Manual rule creator{{< /ui >}} を選択して Agent ルールを作成してから、それを参照する検出ルールを追加します。UI の手順とデプロイについては、「[ポリシー管理][11]」を参照してください。 + +[1]: /ja/security/workload_protection/investigate_and_triage/agent_events +[2]: /ja/security/workload_protection/investigate_and_triage/security_signals +[3]: /ja/security/default_rules/#cat-workload-security +[4]: https://app.datadoghq.com/security/configuration/rules?product=cws +[5]: /ja/security/workload_protection/respond_and_report/#automated-response +[6]: https://app.datadoghq.com/security/agent-events +[7]: /ja/security/notifications/rules/ +[8]: /ja/security/notifications/variables/ +[9]: /ja/security/suppressions/ +[10]: /ja/security/workload_protection/detect_and_monitor/agent_rules +[11]: /ja/security/workload_protection/detect_and_monitor/agent_rules/policy_management#create-a-custom-agent-rule +[12]: https://app.datadoghq.com/security/configuration/workload/agent-rules +[13]: /ja/security/workload_protection/backend_linux +[14]: /ja/security/workload_protection/backend_windows \ No newline at end of file diff --git a/hugo/content/ja/security/workload_protection/detect_and_monitor/detection_and_finding_rules/finding_rules.md b/hugo/content/ja/security/workload_protection/detect_and_monitor/detection_and_finding_rules/finding_rules.md new file mode 100644 index 00000000000..b9680c728d1 --- /dev/null +++ b/hugo/content/ja/security/workload_protection/detect_and_monitor/detection_and_finding_rules/finding_rules.md @@ -0,0 +1,81 @@ +--- +aliases: +- /ja/security/workload_protection/detect_and_monitor/finding_rules +description: ランタイムセキュリティ体制を評価し、Workload Protection の検出結果を生成するバックエンドルールを作成および管理します。 +disable_toc: false +further_reading: +- link: /security/workload_protection/investigate_and_triage/security_findings + tag: ドキュメント + text: 検出結果の調査とトリアージ +- link: /security/workload_protection/detect_and_monitor/agent_rules/secl_guide + tag: ドキュメント + text: SECL ガイド +- link: /security/workload_protection/detect_and_monitor/detection_and_finding_rules/detection_rules + tag: ドキュメント + text: 検出ルール +title: 検出結果ルール +--- +検出結果ルールは、[Agent イベント][1]を分析することで、ランタイムセキュリティ体制を評価するために使用されるバックエンドロジックを記述します。検出結果ルールが一致すると、Workload Protection は影響を受けるリソースに対して[検出結果][2]を生成します。 + +実際のランタイムセキュリティの脅威を表面化させる[検出ルール][3]とは異なり、検出結果ルールは進行中の不適切な慣行や設定ミスを追跡します。検出結果は、単一の不審なアクティビティではなく、セキュリティポリシーに違反しているリソース (ホストまたはコンテナ) を表します。 + +検出結果ルールは、既存の Agent イベントを使用して、コンテナ内でのパッケージマネージャーの使用、IMDS アクセスパターン、不要な権限設定など、実用的なセキュリティ推奨事項を提示します。これは、直接的な脅威ではないものの、本番環境におけるリスクの高い慣行を表す現実世界のリスクに対処する上で役立ちます。 + +## OOTB 検出結果ルール {#ootb-finding-rules} + +Workload Protection には、Datadog が管理する out-of-the-box (OOTB) 検出結果ルールが含まれています。これらのルールは、本番ワークロードにおける不適切な慣行やリスクの高い設定を継続的に提示します。Datadog は新しいデフォルトルールを継続的に開発しており、新しいルールは自動的にアカウントにインポートされます。全リストについては、[OOTB ルールリスト][8]を参照してください。 + +Datadog の Workload Protection [検出結果ルール][6]リストで、組織にデプロイされた検出結果ルールを参照および確認します。各ルールには、セキュリティリスクの説明、適用されるリソースタイプ、および修復ガイダンスが含まれています。 + +予期される設定に対するノイズを減らすには、検出結果の自動化を使用して、ルールを無効にせずにミュートします。[Findings automation][7] を参照してください。 + +## カスタム検出結果ルールを作成する {#create-a-custom-finding-rule} + +カスタム検出結果ルールは、[検出ルール][3]と同じ作成プロセスに従いますが、1 つの重要な違いがあります。それは、特定の時点のイベントを検出するのではなく、ホストやコンテナといった特定のリソースタイプを対象とする点です。 + +カスタム検出結果ルールを作成するには、Workload Protection の[検出結果ルール][6]ページに移動し、[{{< ui >}}New Rule{{< /ui >}}] をクリックします。 + +ルールエディターでは、5 つのステップで設定を行います。 + +### ステップ 1: リソースタイプを選択し、検索クエリを定義する {#step-1-select-a-resource-type-and-define-search-query} + +検出結果ルールが評価するリソースのタイプを選択します。 + +- {{< ui >}}Host{{< /ui >}}: ルールはホストに適用されます。Workload Protection は、コンテナイベントを除外するように、クエリの先頭に `-@container.id:*` を自動的に付加します。 +- {{< ui >}}Container{{< /ui >}}: ルールはコンテナに適用されます。Workload Protection は、コンテナイベントのみを含めるように、クエリの先頭に `@container.id:*` を自動的に付加します。 + +{{< img src="security/workload_protection/detect_and_monitor/finding_rules_editor.png" alt="ホストおよびコンテナのリソースタイプセレクターと検索クエリのプレビューを表示する検出結果ルールエディター" width="100%">}} + +ルールが評価する [Agent イベント][1]を選択するクエリを定義します。検索クエリは、リソースがルールに違反しているかどうかを判断する際に、どのイベントを考慮するかを決定します。 + +次のことができます。 + +- Agent イベントの**特定のフィールド**でフィルタリングしてクエリを絞り込み、検索結果をより正確にします。たとえば、`@process.executable.path`、`@file.path`、または `@agent.rule_id` でフィルタリングします。[検出ルール][3]と同様に、検出結果ルールはバックエンドイベントスキーマの任意のフィールドをクエリできます。これには、すべての Agent イベントフィールドに加え、インフラストラクチャーコンテキスト、プロセス系統、脅威インテリジェンスなどの追加のエンリッチメントが含まれます。利用可能なフィールドの全セットについては、[Linux backend syntax][9] および [Windows backend syntax][10] を参照してください。 +- 複数の条件を組み合わせて、ルールをインフラストラクチャーまたはワークロードのサブセットに絞り込みます。 + +ルールを公開する前に、[Agent Events Explorer][5] を使用してクエリをテストし、どのイベントが一致するかを確認します。 + +### ステップ 2: 検出結果の重大度を定義する {#step-2-define-finding-severity} + +ルールがトリガーされたときに検出結果が持つ重大度を定義します。 + +### ステップ 3: 検出結果を説明する {#step-3-describe-the-finding} + +検出結果が生成されたときに表示される**名前**、**説明**、および**修復ガイダンス**を構成します。 + +1. {{< ui >}}Rule name{{< /ui >}} を入力します。名前は検出結果ルール一覧表示に表示され、生成された検出結果のタイトルになります。 +2. {{< ui >}}Rule message{{< /ui >}} セクションでは、Markdown を使用して、検出結果の意味と対処方法を説明します。メッセージ本文に `## Remediation` ヘッダーを含めます。Workload Protection は、このセクションを使用して、検出結果のサイドパネルに修復手順を直接表示します。 +3. {{< ui >}}Tag resulting findings{{< /ui >}} ドロップダウンを使用して、生成された検出結果にタグを追加します。例: `security:posture` または `compliance:pci`。 + +**注**: 検出結果のサイドパネルに修復手順を正しく表示するには、`## Remediation` ヘッダーが必要です。 + +[1]: /ja/security/workload_protection/investigate_and_triage/agent_events +[2]: /ja/security/workload_protection/investigate_and_triage/security_findings +[3]: /ja/security/workload_protection/detect_and_monitor/detection_and_finding_rules/detection_rules +[4]: https://app.datadoghq.com/security/configuration/findings-automation +[5]: https://app.datadoghq.com/security/agent-events +[6]: https://app.datadoghq.com/security/workload-protection/finding-rules +[7]: /ja/security/automation_pipelines/mute +[8]: /ja/security/default_rules/#workload-activity +[9]: /ja/security/workload_protection/backend_linux +[10]: /ja/security/workload_protection/backend_windows \ No newline at end of file diff --git a/hugo/content/ja/security/workload_protection/setup/kubernetes.md b/hugo/content/ja/security/workload_protection/setup/kubernetes.md new file mode 100644 index 00000000000..6828d23acd6 --- /dev/null +++ b/hugo/content/ja/security/workload_protection/setup/kubernetes.md @@ -0,0 +1,190 @@ +--- +aliases: +- /ja/security/workload_protection/setup/agent/kubernetes +description: Datadog Operator、Helm、または DaemonSet を使用して、Kubernetes で Workload Protection + を有効にします。 +disable_toc: false +title: Kubernetes での Workload Protection のセットアップ +--- +Workload Protection を有効にするには、以下の手順に従います。 + +
Fargate コンピューティングオプションで構成された Amazon EKS に Workload Protection をデプロイするには、Fargate デプロイメントに関するページを参照してください。
+ +{{< partial name="security-platform/WP-billing-note.html" >}} + +## 前提条件 {#prerequisites} + +- 最新バージョンの Datadog Agent。インストール手順については、「[Agent の概要][5]」を参照するか、[Datadog UI][6] から Agent をインストールしてください。 + +**注**: SBOM 収集には、GKE (Google Kubernetes Engine) のイメージストリーミング機能との互換性がありません。無効にするには、GKE ドキュメントの [イメージストリーミングの無効化][7] に関するセクションを参照してください。 + +## インストール {#installation} + +{{< tabs >}} + +{{% tab "Datadog Operator" %}} + +1. `datadog-agent.yaml` ファイルの `spec` セクションに以下の内容を追加します。 + + ```yaml + # datadog-agent.yaml file + apiVersion: datadoghq.com/v2alpha1 + kind: DatadogAgent + metadata: + name: datadog + spec: + features: + # (Optional) Integrate with Kubernetes to enrich Workload Protection events with Kubernetes user identities + admissionController: + enabled: true + cwsInstrumentation: + enabled: true + + remoteConfiguration: + enabled: true + # Enables Threat Detection + cws: + enabled: true + # Enables Misconfigurations + cspm: + enabled: true + hostBenchmarks: + enabled: true + # Enables the image metadata collection and Software Bill of Materials (SBOM) collection + sbom: + enabled: true + # Enables Container Vulnerability Management + # Image collection is enabled by default with Datadog Operator version `>= 1.3.0` + containerImage: + enabled: true + + # Uncomment the following line if you are using Google Kubernetes Engine (GKE) or Amazon Elastic Kubernetes (EKS) + # uncompressedLayersSupport: true + + # Enables Host Vulnerability Management + host: + enabled: true + ``` + +2. 変更を適用し、Agent を再起動します。 + +[2]: https://github.com/DataDog/datadog-operator/blob/main/docs/configuration.v2alpha1.md + +{{% /tab %}} + +{{% tab "Helm" %}} + +1. `datadog-values.yaml` ファイルの `datadog` セクションに以下の内容を追加します。 + + ```yaml + # datadog-values.yaml file + + # (Optional) Integrate with Kubernetes to enrich Workload Protection events with Kubernetes user identities + clusterAgent: + admissionController: + enabled: true + cwsInstrumentation: + enabled: true + + datadog: + remoteConfiguration: + enabled: true + securityAgent: + # Enables Threat Detection + runtime: + enabled: true + # Enables Misconfigurations + compliance: + enabled: true + host_benchmarks: + enabled: true + sbom: + containerImage: + enabled: true + + # Uncomment the following line if you are using Google Kubernetes Engine (GKE) or Amazon Elastic Kubernetes (EKS) + # uncompressedLayersSupport: true + + # Enables Host Vulnerability Management + host: + enabled: true + + # Enables Container Vulnerability Management + # Image collection is enabled by default with Datadog Helm version `>= 3.46.0` + # containerImageCollection: + # enabled: true + ``` + +2. Agent を再起動します。 + +RBAC の問題を解決するには、`clusterRole` に対して `clusterRole.allowCreatePodsExec` オプションを有効にしてチャートを実行します。 + +```sh +helm install datadog-operator datadog/datadog-operator --set clusterRole.allowCreatePodsExec=true +``` + +{{% /tab %}} + +{{% tab "DaemonSet" %}} + +1. `daemonset.yaml` ファイルの `security-agent` および `system-probe` の `env` セクションに以下の設定を追加します。Workload Protection イベントに Kubernetes ユーザーの ID を付与するには、`cluster-agent-deployment.yaml` で、オプションの `DD_ADMISSION_CONTROLLER_ENABLED` 変数および `DD_RUNTIME_ADMISSION_CONTROLLER_CWS_INSTRUMENTATION_ENABLED` 変数も設定します。 + + ```bash + # Source: datadog/templates/daemonset.yaml + apiVersion:app/1 + kind: DaemonSet + [...] + spec: + [...] + spec: + [...] + containers: + [...] + - name: agent + [...] + env: + - name: DD_REMOTE_CONFIGURATION_ENABLED + value: "true" + - name: system-probe + [...] + env: + - name: DD_RUNTIME_SECURITY_CONFIG_ENABLED + value: "true" + - name: DD_RUNTIME_SECURITY_CONFIG_REMOTE_CONFIGURATION_ENABLED + value: "true" + - name: DD_COMPLIANCE_CONFIG_ENABLED + value: "true" + - name: DD_COMPLIANCE_CONFIG_HOST_BENCHMARKS_ENABLED + value: "true" + - name: DD_SBOM_CONTAINER_IMAGE_USE_MOUNT + value: "true" + [...] + + # Source: datadog/templates/cluster-agent-deployment.yaml + apiVersion:app/1 + kind: Deployment + [...] + spec: + [...] + template: + [...] + spec: + [...] + containers: + [...] + - name: cluster-agent + [...] + env: + - name: DD_ADMISSION_CONTROLLER_ENABLED + value: "true" + - name: DD_RUNTIME_ADMISSION_CONTROLLER_CWS_INSTRUMENTATION_ENABLED + value: "true" + ``` + +{{% /tab %}} +{{< /tabs >}} + + +[5]: /ja/getting_started/agent +[6]: https://app.datadoghq.com/account/settings/agent/latest +[7]: https://cloud.google.com/kubernetes-engine/docs/how-to/image-streaming#disable \ No newline at end of file diff --git a/hugo/content/ja/security/workload_protection/setup/windows.md b/hugo/content/ja/security/workload_protection/setup/windows.md new file mode 100644 index 00000000000..47d02dfd804 --- /dev/null +++ b/hugo/content/ja/security/workload_protection/setup/windows.md @@ -0,0 +1,10 @@ +--- +aliases: +- /ja/security/workload_protection/setup/agent/windows +description: Windows ホスト上で Datadog Agent を使って Workload Protection を有効化します。 +disable_toc: false +title: Windows での Workload Protection のセットアップ +--- +{{% wp-windows-setup %}} + +{{< partial name="security-platform/WP-billing-note.html" >}} \ No newline at end of file diff --git a/hugo/content/ja/serverless/google_cloud_run/containers/_index.md b/hugo/content/ja/serverless/google_cloud_run/containers/_index.md index b5c71786c24..25cdabbc9d0 100644 --- a/hugo/content/ja/serverless/google_cloud_run/containers/_index.md +++ b/hugo/content/ja/serverless/google_cloud_run/containers/_index.md @@ -5,7 +5,7 @@ further_reading: text: Google Cloud Run インテグレーション - link: https://www.datadoghq.com/blog/collect-traces-logs-from-cloud-run-with-datadog/ tag: ブログ - text: Cloud Run サービスからのトレース、ログ、カスタムメトリクスの収集 + text: Cloud Run サービスからトレース、ログ、カスタムメトリクスを収集する - link: /serverless/google_cloud_run/containers/in_container/ tag: ドキュメント text: インコンテナアプローチでコンテナをインスツルメントする @@ -17,36 +17,62 @@ further_reading: text: 新しい Datadog Agent サイドカーを使用して Google Cloud Run アプリケーションをインスツルメントする - link: /mcp_server/tools/#serverless_onboarding tag: ドキュメント - text: 'Datadog MCP サーバー: serverless_onboarding ツール' + text: 'Datadog MCP Server: serverless_onboarding ツール' title: コンテナのインスツルメンテーション方法の選択 --- -## Datadog MCP サーバーを使用する {#use-the-datadog-mcp-server} +## エージェント型オンボーディングを使用してセットアップする{#set-up-with-agentic-onboarding} -[Datadog MCP サーバー][3]を使用し、AI のサポートを活用して Cloud Run コンテナのモニターを設定します。接続したら、次のようなプロンプトを試してください。 +{{< site-region region="gov,gov2" >}} +
この機能は、選択した Datadog サイト ({{< region-param key="dd_site_name" >}}) ではサポートされていません。
+{{< /site-region >}} + +エージェント型オンボーディングを使用して、AI を活用した Cloud Run コンテナの監視を設定します。エージェント型オンボーディングは、プロジェクトのフレームワークを検出し、必要な構成を適用し、データが正常に送信されていることを確認します。同じ Datadog アカウントを使用する 2 つの補完的なパスがあります。 + +- **AI Setup CLI**: スタンドアロンのターミナルツールです。MCP サーバーをインストールしたくない場合に使用します。 +- **MCP サーバー**: Claude Code や Cursor などのコーディングアシスタントを通じて、IDE からセットアップします。 + +{{< tabs >}} +{{% tab "AI Setup CLI" %}} + +プロジェクトディレクトリで CLI を実行します (Node.js 22 以降が必要です)。Datadog アカウントをリンクし、Cloud Run サービスをインスツルメントします。 ```shell +npx @datadog/ai-setup-cli --product serverless --serverless-compute-type=gcp-cloud-run +``` + +対話形式で実行する場合は、`--product` を省略します。対象とする Datadog サイトを指定する場合は、`--site` を追加します。 + +{{% /tab %}} +{{% tab "MCP サーバー" %}} + +Datadog MCP Server の [`serverless_onboarding`](https://docs.datadoghq.com/ja/agentic_onboarding/setup/?tab=serverlessmonitoring#mcp-server) ツールを使用して、AI を活用した Cloud Run コンテナの監視を設定します。接続後、次のようなプロンプトを試してください。 + +``` Help me monitor my GCP Cloud Run services with Datadog using Terraform. ``` +{{% /tab %}} +{{< /tabs >}} + ## 手動インスツルメンテーション {#manual-instrumentation} Datadog を使用して Google Cloud Run コンテナをインスツルメントするには、次の 2 つのオプションのいずれかを選択します。 {{% gcr-container-options %}} -- [**インコンテナ**][1]: Datadog Agent でアプリケーションコンテナをラップします。より簡単なセットアップ、低コストオーバーヘッド、直接ログパイプを希望する場合は、このオプションを選択してください。 -- [**サイドカー**][2]: アプリコンテナとは別のコンテナに Datadog Agent をデプロイします。単一のサービスに複数のコンテナがある場合、Datadog Agent の厳密な分離を希望する場合、またはパフォーマンス要件が厳しいワークロードがある場合は、このオプションを選択してください。 +- [**インコンテナ**][1]: Datadog Agent でアプリケーションコンテナをラップします。セットアップをより簡単に行い、オーバーヘッドコストを削減し、直接ログパイプを使用する場合は、このオプションを選択します。 +- [**サイドカー**][2]: アプリコンテナとは別のコンテナに Datadog Agent をデプロイします。単一のサービスに複数のコンテナがある場合、Datadog Agent の厳密な分離を希望する場合、またはパフォーマンス要件が厳しいワークロードがある場合は、このオプションを選択します。 ### 比較: インコンテナとサイドカーのインスツルメンテーション {#comparison-in-container-versus-sidecar-instrumentation} -| 側面 | インコンテナ | サイドカー | +| 要素 | インコンテナ | サイドカー | |-------------------------------|----------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------| | デプロイメント | 1 つのコンテナ (アプリ、Datadog Agent でラップ) | 2 つのコンテナ (アプリ、Datadog Agent) | -| 画像の変更 | アプリの画像サイズが増加します。 | アプリの画像に変更はありません。 | -| コストオーバーヘッド | サイドカーよりも少ない (追加コンテナなし)。 | Extra vCPU / メモリ。サイドカーの過剰割り当てはコストを無駄にし、過少割り当てはプレマチュアスケーリングにつながります。 | -| ログ | 直接 stdout / stderr アクセス。 | ログファイルにルーティングする共有ボリューム + ログライブラリ。未処理のエラーには追加の処理が必要です。それらはロギングライブラリによって自動的に処理されないからです。| -| 障害の分離 | 稀なケースではありますが、Datadog Agent のバグがアプリに影響を与える可能性があります。 | Datadog Agent の障害は分離されます。 | +| 画像の変更 | アプリの画像サイズが増加します。 | アプリの画像は変更されません。 | +| オーバーヘッドコスト | サイドカーより低コスト (追加コンテナなし)。 | 追加の vCPU/メモリ。サイドカーに過剰に割り当てるとコストを浪費し、過少に割り当てると早すぎる段階でのスケーリングにつながります。 | +| ログ | 直接の stdout/stderr 直接アクセス。 | ログファイルにルーティングする共有ボリューム + ログライブラリ。捕捉されなかったエラーがログライブラリによって自動的に処理されることはないため、追加の処理が必要です。| +| 障害の分離 | 稀にしか発生しませんが、Datadog Agent のバグがアプリに影響を与えることがあります。 | Datadog Agent の障害は分離されます。 | -## 参考資料 {#further-reading} +## 関連資料{#further-reading} {{< partial name="whats-next/whats-next.html" >}} diff --git a/hugo/content/ja/tracing/guide/ingestion_sampling_use_cases.md b/hugo/content/ja/tracing/guide/ingestion_sampling_use_cases.md index 8601e084609..cde896462ea 100644 --- a/hugo/content/ja/tracing/guide/ingestion_sampling_use_cases.md +++ b/hugo/content/ja/tracing/guide/ingestion_sampling_use_cases.md @@ -1,152 +1,158 @@ --- +description: トラブルシューティング能力は保ちながら、取り込み量を最適化するためのさまざまなトレースサンプリングユースケースと戦略について説明します。 further_reading: - link: /tracing/guide/trace_ingestion_volume_control/ tag: ガイド - text: 取り込みボリュームを制御する方法 + text: 取り込み量を制御する方法 +- link: https://www.datadoghq.com/architecture/mastering-distributed-tracing-data-volume-challenges-and-datadogs-approach-to-efficient-sampling/ + tag: Architecture Center + text: '分散トレースの習得: データ量の課題と Datadog による効率的なサンプリング方法' +- link: https://www.datadoghq.com/architecture/optimizing-distributed-tracing-best-practices-for-remaining-within-budget-and-capturing-critical-traces/ + tag: Architecture Center + text: '分散トレースの最適化: 予算内に収め、重要なトレースをキャプチャするためのベストプラクティス' title: トレースサンプリングのユースケース --- +## 概要 {#overview} -## 概要 +トレースデータは反復される傾向があります。アプリケーションの問題が、1 つのトレースでのみ特定され、他のトレースでは特定されないということはほとんどありません。高スループットのサービス、特に注意を要するインシデントの場合、問題の症状は複数のトレースで繰り返し現れます。したがって通常は、サービスやエンドポイントのあらゆるトレースや、トレース内のあらゆるスパンをすべて収集する必要はありません。Datadog APM の[取り込み制御メカニズム][1]は、問題のトラブルシューティングに必要な可視性を維持しながら、ノイズを削減し、コストを管理するうえで役立ちます。 -トレースデータは反復される傾向があります。アプリケーションの問題が、たった 1 つのトレースで特定され、他のトレースがないことはほとんどありません。高スループットのサービス、特に注意を要するインシデントの場合、問題は複数のトレースで繰り返し症状が現れます。その結果、サービスやエンドポイントのトレースやトレース内のスパンをすべて収集する必要はありません。Datadog APM [取り込み制御メカニズム][1]は、問題のトラブルシューティングに必要な可視性を維持しながら、ノイズを削減し、コストを管理するのに役立ちます。 +取り込みメカニズムは、Datadog Agent および Datadog SDK 内の構成です。OpenTelemetry SDK を使用してアプリケーションをインスツルメントしている場合は、「[OpenTelemetry による取り込みサンプリング][2]」をお読みください。 -取り込みの仕組みは、Datadog Agent と Datadog トレーシングライブラリ内の構成です。OpenTelemetry SDK を使用してアプリケーションのインスツルメンテーションを行っている場合は、[OpenTelemetry による取り込みサンプリング][2]をお読みください。 +このガイドを利用すると、発生する可能性のある主なユースケースに応じて、いつ、どのように取り込み制御の構成を使用するかを理解することができます。ガイドの内容は以下のとおりです。 -このガイドでは、遭遇する可能性のある主なユースケースに応じて、いつ、どのように取り込み制御の構成を使用するかを理解するのに役立ちます。本書は、以下の内容をカバーしています。 - -- あるサービスに対して、[どの取り込みメカニズムを使用するかを判断する](#determining-which-ingestion-mechanisms-are-used) +- [あるサービスに対して、どの取り込みメカニズムを使用するかを判断する](#determining-which-ingestion-mechanisms-are-used) - [特定の種類のトレースを保持することに重点を置いたユースケース](#keeping-certain-types-of-traces) - [取り込みトレースの低減に重点を置いたユースケース](#reducing-ingestion-for-high-volume-services) -## どの取り込みメカニズムを使用するかを判断する +## どの取り込みメカニズムを使用するかを判断する {#determining-which-ingestion-mechanisms-are-used} -Datadog 環境で現在使用されている取り込みメカニズムを確認するには、[Ingestion Control ページ][3]に移動してください。 +Datadog 環境で現在使用されている取り込みメカニズムを確認するには、[[Ingestion Control] ページ][3]に移動してください。 -{{< img src="/tracing/guide/ingestion_sampling_use_cases/ingestion_control_page.png" alt="Ingestion Control ページ" style="width:90%;" >}} +{{< img src="/tracing/guide/ingestion_sampling_use_cases/ingestion_control_page.png" alt="[Ingestion Control] ページ" style="width:90%;" >}} -この表は、*サービス別*の取り込みボリュームに関する洞察を提供します。構成列は、現在のセットアップの最初の指標となります。これは、次のことを示しています。 -- Datadog Agent で計算したサンプリングレートをサービスから始まるトレースに適用する場合は `AUTOMATIC` となります。[Datadog Agent の取り込みロジック][5]の仕様については、こちらをご覧ください。 -- サービスから開始するトレースにトレーシングライブラリで構成したカスタムトレースサンプリングレートが適用される場合は `CONFIGURED` となります。 +このテーブルは、取り込み量に関する情報を*サービス別に*示します。[Configuration](構成) 列は、現在のセットアップの最初の指標となります。これには、次のことが示されます。 +- `AUTOMATIC`: Datadog Agent で計算したサンプリングレートを、サービスから開始されるトレースに適用する場合。[Datadog Agent の取り込みロジック][5]の詳細をご確認ください。 +- `CONFIGURED`:SDK で構成されたカスタムトレースサンプリングレートを、サービスから開始されるトレースに適用する場合。 -サービスをクリックすると、各サービスで使用されているサンプリングの決定要因 (Agent やトレーシングライブラリ、ルールやサンプルレートなど) や、取り込みスパンのサービスで利用されている[取り込みサンプリングメカニズム][1]の詳細を確認できます。 +サービスをクリックすると、各サービスで使用されているサンプリングの決定要因 (Agent または SDK、ルール、サンプルレートなど) や、取り込みスパンのサービスで利用されている[取り込みサンプリングメカニズム][1]の詳細を確認できます。 -{{< img src="/tracing/guide/ingestion_sampling_use_cases/service-ingestion-summary.png" alt="Service Ingestion Summary" style="width:90%;" >}} +{{< img src="/tracing/guide/ingestion_sampling_use_cases/service-ingestion-summary.png" alt="[Service Ingestion Summary](サービス取り込みの概要)" style="width:90%;" >}} -上記の Service Ingestion Summary の例では、**Ingestion reasons breakdown** テーブルに、このサービスの取り込み理由のほとんどが `rule` ([ユーザー定義サンプリングルール][6]) に由来することが示されています。 +上に示している [Service Ingestion Summary](サービス取り込みの概要) の例では、[{{< ui >}}Ingestion reasons breakdown{{< /ui >}}](取り込み理由の内訳) テーブルに、このサービスの取り込み理由のほとんどが `rule` ([ユーザー定義サンプリングルール][6]) に由来することが示されています。 -このサービスのトップサンプリング決定要因は、`web-store` サービスが、`web-store`、`shopist-web-ui`、`shipping-worker`、`synthetics-browser`、`product-recommendation` からサンプリング決定を受けることを示しています。これらの 5 つのサービスはすべて、`web-store` のサービススパンに影響を与える全体的なサンプリング決定に寄与しています。Web ストアの取り込みを微調整する方法を決定する場合、5 つのサービスすべてを考慮する必要があります。 +このサービスの上位サンプリング決定要因を見ると、`web-store` サービスのサンプリングに関する決定は、`web-store`、`shopist-web-ui`、`shipping-worker`、`synthetics-browser`、および `product-recommendation` に由来することがわかります。これら 5 つのサービスはすべて、`web-store` のサービススパンに影響を与える全体的なサンプリング決定に寄与しています。Web ストアの取り込みを微調整する方法を決定する場合、5 つのサービスすべてを考慮する必要があります。 -## 特定の種類のトレースを保持する +## 特定の種類のトレースを保持する {#keeping-certain-types-of-traces} -### トランザクションのトレースをすべて保持する +### トランザクションのトレースをすべて保持する {#keeping-entire-transaction-traces} トランザクショントレース全体を取り込むことで、個々のリクエストに対する**エンドツーエンドのサービスリクエストの流れ**を可視化することができます。 -#### ソリューション: ヘッドベースサンプリング +#### ソリューション: ヘッドベースサンプリング {#solution-head-based-sampling} -完全なトレースは、[ヘッドベースサンプリング][4]メカニズムで取り込むことができます。トレースが作成されたときに、トレースを維持するか削除するかの決定は、トレースの最初のスパン、*ヘッド*から決定されます。この決定は、リクエストコンテキストを通じてダウンストリームサービスに伝搬されます。 +トレース全体を取り込む場合は、[ヘッドベースサンプリング][4]メカニズムを使用します。トレース作成時のトレースを保持するか削除するかの決定は、トレースの最初のスパン (*ヘッド*) を基に行われます。この決定は、リクエストコンテキストを通じてダウンストリームサービスに伝搬されます。 {{< img src="/tracing/guide/ingestion_sampling_use_cases/head-based-sampling.png" alt="ヘッドベースサンプリング" style="width:100%;" >}} -Datadog Agent は、トレースの保持と削除を決定するために、アプリケーショントラフィックに基づいて、トレース作成時に適用する各サービスの[デフォルトサンプリングレート][5]を計算します。 -- トラフィックの少ないアプリケーションでは、サンプリング率 100% が適用されます。 +Datadog Agent は、トレースを保持するか削除するかを決定するために、アプリケーショントラフィックに基づいて、トレース作成時に適用する各サービスの[デフォルトサンプリングレート][5]を計算します。 +- トラフィックの少ないアプリケーションでは、100% のサンプリングレートが適用されます。 - トラフィックの多いアプリケーションでは、Agent あたり毎秒 10 個の完全なトレースを目標に、低いサンプリングレートが適用されます。 -また、サービスごとにサンプリングレートを構成することで、Agent のデフォルトサンプリングレートをオーバーライドすることができます。詳しくは、[特定のサービスに対してより多くのトレースを保持する](#keeping-more-traces-for-specific-services-or-resources)方法を参照してください。 +また、サービスごとにサンプリングレートを構成することで、Agent のデフォルトサンプリングレートをオーバーライドすることもできます。詳細については、[特定のサービスについて保持するトレース数を増やす方法](#keeping-more-traces-for-specific-services-or-resources)を参照してください。 -#### ヘッドベースサンプリングの構成 +#### ヘッドベースサンプリングの構成 {#configuring-head-based-sampling} -デフォルトのサンプリングレートは、Agent ごとに 1 秒間に 10 個の完全なトレースを目標に計算されています。これはトレースの*目標*数であり、一定期間のトレースを平均化した結果です。これはハード的な制限では*ありません*。また、トラフィックの急増により、短時間のうちに Datadog に送信されるトレースが大幅に増加することがあります。 +デフォルトのサンプリングレートは、Agent ごとに 1 秒間に 10 個の完全なトレースを目標に計算されています。これはトレースの*目標*数であり、一定期間のトレース数の平均を求めることで得られます。これは絶対的な制限では*ありません*。トラフィックの急増により、短時間のうちに Datadog に送信されるトレース数が大幅に増加することがあります。 -Datadog Agent のパラメーター `max_traces_per_second` または環境変数 `DD_APM_MAX_TPS` を構成することで、この目標を増減することができます。ヘッドベースサンプリングの取り込みメカニズム][5]の詳細はこちらをご覧ください。 +Datadog Agent のパラメータ `target_traces_per_second` または環境変数 `DD_APM_TARGET_TPS` を構成することで、この目標を増減させることができます。[ヘッドベースサンプリングの取り込みメカニズム][5]の詳細をご確認ください。 **注:** Agent の構成を変更すると、この Datadog Agent にトレースを報告する*すべてのサービス*のパーセントサンプリングレートに影響します。 ほとんどのシナリオで、この Agent レベルの構成は割り当てられたクォータ内にとどまり、アプリケーションのパフォーマンスを十分に可視化し、ビジネスのための適切な意思決定を支援します。 -### 特定のサービスやリソースに対してより多くのトレースを保持する +### 特定のサービスやリソースについて保持するトレース数を増やす {#keeping-more-traces-for-specific-services-or-resources} -サービスやリクエストがビジネスにとって重要なものである場合、その可視性を高めたいと思うものです。Datadog に関連するすべてのトレースを送信して、個々のトランザクションを調べることができるようにするとよいでしょう。 +自社のビジネスにとって重要なサービスやリクエストでは、その可視性を高める必要があります。関連するすべてのトレースを Datadog に送信して、個々のトランザクションを詳しく調べることができるようにすることをお勧めします。 -#### ソリューション: サンプリングルール +#### ソリューション: サンプリングルール {#solution-sampling-rules} -デフォルトでは、サンプリングレートは、Datadog Agent あたり 1 秒あたり 10 トレースを目標に計算されます。トレーシングライブラリで[サンプリングルール][6]を構成することで、デフォルトで計算されたサンプリングレートをオーバーライドすることができます。 +デフォルトでは、サンプリングレートは、Datadog Agent あたり、毎秒 10 トレースを目標に計算されます。SDK で[サンプリングルール][6]を構成すると、デフォルトで計算されたサンプリングレートをオーバーライドすることができます。 -サービス別にサンプリングルールを構成することができます。ルールの指定したサービスから始まるトレースには、Agent のデフォルトサンプリングレートの代わりに、定義されたパーセンテージサンプリングレートが適用されます。 +サンプリングルールはサービスごとに構成できます。ルールで指定されたサービスから開始されるトレースの場合は、Agent のデフォルトサンプリングレートの代わりに、定義されたパーセントのサンプリングレートが適用されます。 -#### サンプリングルールの構成 +#### サンプリングルールを構成する {#configuring-a-sampling-rule} -環境変数 `DD_TRACE_SAMPLING_RULES` を設定することで、サンプリングルールを構成することができます。 +環境変数 `DD_TRACE_SAMPLING_RULES` を設定して、サンプリングルールを構成することができます。 -例えば、`my-service` という名前のサービスのトレースの 20% を送信するには +たとえば、`my-service` という名前のサービスのトレースの 20% を送信するには、次のようにします。 ``` DD_TRACE_SAMPLING_RULES='[{"service": "my-service", "sample_rate": 0.2}]' ``` -[サンプリングルールの取り込みメカニズム][6]について詳しくはこちら。 +[サンプリングルールの取り込みメカニズム][6]の詳細をご確認ください。 -### エラー関連のトレースをより多く保持する +### 保持するエラー関連のトレース数を増やす {#keeping-more-error-related-traces} -エラースパンを持つトレースは、しばしばシステム障害の症状です。エラーのあるトランザクションの割合を高く保つことで、常にいくつかの関連する個々のリクエストにアクセスすることができます。 +エラースパンを含むトレースは、一般にシステム障害の兆候です。エラーのあるトランザクションの割合を高く保つことで、個別の関連するリクエストに常にアクセスできるようにすることができます。 -#### ソリューション: エラーサンプリングレート +#### ソリューション: エラーサンプリングレート {#solution-error-sampling-rate} -ヘッドベースサンプリングされたトレースに加えて、エラーサンプリングレートを上げることで、ヘッドベースサンプリングで関連トレースが保持されない場合でも、各 Agent が追加のエラースパンを保持することができます。 +ヘッドベースサンプリングによるトレースに加え、エラーサンプリングレートを高めることで、ヘッドベースサンプリングによって関連トレースが保持されない場合でも、各 Agent が追加のエラースパンを保持できるようにすることができます。 {{< img src="/tracing/guide/ingestion_sampling_use_cases/error-spans-sampling.png" alt="エラーサンプリング" style="width:100%;" >}} **注:** - Datadog Agent レベルでローカルにサンプリングが行われるため、トレースチャンクの分散された断片は取り込まれない可能性があります。 -- **Datadog Agent 6/7.41.0 以降**では、`DD_APM_FEATURES=error_rare_sample_tracer_drop` を設定することで、トレーシングライブラリルールまたは `manual.drop` でドロップしたスパンが含まれます。詳細は、[取り込みのメカニズムのドキュメントのエラートレースセクション][9]に記載されています。 +- **Datadog Agent 6/7.41.0 以降**では、`DD_APM_FEATURES=error_rare_sample_tracer_drop` を設定して、SDK ルールまたは `manual.drop` でドロップしたスパンが含まれるようにすることができます。詳細については、[取り込みメカニズムドキュメントのエラートレースセクション][9]を参照してください。 -#### エラーサンプリングの構成 +#### エラーサンプリングを構成する {#configuring-error-sampling} -環境変数 `DD_APM_ERROR_TPS` を設定することで、Agent ごとに 1 秒間に何個のエラーチャンクをキャプチャするかを構成することができます。デフォルト値は、1 秒間に `10` 個のエラーです。**すべてのエラー**を取り込みたい場合は、任意の高い値を設定してください。エラーサンプリングを無効にするには、`DD_APM_ERROR_TPS` を `0` に設定します。 +環境変数 `DD_APM_ERROR_TPS` を設定して、各 Agent がキャプチャする 1 秒あたりのエラーチャンク数を構成できます。デフォルト値は 1 秒あたり `10` 個のエラーです。**すべてのエラー**を取り込む場合は、任意の大きな値を設定してください。エラーサンプリングを無効にするには、`DD_APM_ERROR_TPS` を `0` に設定します。 -## ボリュームの大きいサービスの取り込みを減らす +## ボリュームの大きいサービスの取り込みを減らす {#reducing-ingestion-for-high-volume-services} -### データベースやキャッシュサービスからのボリュームを減らす +### データベースやキャッシュサービスからの取り込み量を減らす {#reducing-volume-from-database-or-cache-services} -トレースされたデータベース呼び出しは大量の取り込みデータを表し、アプリケーションのパフォーマンスメトリクス (エラーカウント、リクエストヒットカウント、レイテンシーなど) はデータベースの健全性を監視するのに十分です。 +トレースされたデータベース呼び出しは大量の取り込みデータを表す場合がありますが、データベースの健全性を監視するには、アプリケーションのパフォーマンスメトリクス (エラー数、リクエストヒット数、レイテンシーなど) で十分です。 -#### ソリューション: データベース呼び出しのあるトレースのサンプリングルール +#### ソリューション: データベース呼び出しを含むトレースのサンプリングルール {#solution-sampling-rules-for-traces-with-database-calls} -データベース呼び出しをトレースすることで生じるスパン量を減らすために、トレースの先頭でサンプリングを構成します。 +データベース呼び出しをトレースすることで生じるスパン量を減らすために、トレースのヘッドでサンプリングを構成します。 データベースサービスがトレースを開始することはほとんどありません。通常、クライアントデータベーススパンは、インスツルメンテーションされたバックエンドサービススパンの子です。 -**どのサービスがデータベーストレースを開始するか**を知るには、取り込み制御ページ [Service Ingestion Summary][7] の `Top Sampling Decision Makers` トップリストグラフを使用します。これらの特定のサービスに対してヘッドベースサンプリングを構成すると、取り込まれるデータベーススパンの量が減少し、不完全なトレースが取り込まれないようにすることができます。分散型トレーシングは、保持されるか、完全に削除されます。 +**どのサービスがデータベーストレースを開始するか**を知るには、[Ingestion Control] ページの [Service Ingestion Summary][7] の `Top Sampling Decision Makers` トップリストグラフを使用します。これらの特定のサービスに対してヘッドベースサンプリングを構成すると、取り込まれるデータベーススパンの量を減らしながら、不完全なトレースが取り込まれないようにすることができます。分散されたトレースは、保持されるか完全に削除されます。 -{{< img src="/tracing/guide/ingestion_sampling_use_cases/service-ingestion-summary-database.png" alt="トップサンプリング決定要因" style="width:90%;" >}} +{{< 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` のサービスに対してサンプリングを構成します。 +たとえば、`web-store-mongo` のデータベース呼び出しのトレースでは、99% の確率で `web-store` と `shipping-worker` のサービスからトレースが発生します。そのため、`web-store-mongo` のトレース量を減らすには、`web-store` と `shipping-worker` のサービスに対してサンプリングを構成します。 -#### データベーススパンをドロップするサンプリングの構成 +#### データベーススパンをドロップするサンプリングの構成 {#configure-sampling-to-drop-database-spans} サンプリングルールの構文については、[サンプリングルール構成セクション](#configuring-a-sampling-rule)を参照してください。 -バックエンドサービスの `web-store` は、トレースごとに何度も Mongo データベースを呼び出しており、不要なスパンボリュームを大量に作り出しています。 +バックエンドサービスの `web-store` は、各トレースで複数回 Mongo データベースを呼び出すため、不要なスパンが大量に作成されます。 -- バックエンドサービス `web-store` の **トレースサンプリングルール** を構成し、Mongo スパンを含むトレース全体の 10% を保持します。 +- バックエンドサービス `web-store` の**トレースサンプリングルール**を構成し、Mongo スパンを含め、すべてのトレースの 10% が保持されるようにします。 ``` DD_TRACE_SAMPLING_RULES='[{"service": "web-store", "sample_rate": 0.1}]' ``` -- オプションとして、すべての `web-store` スパンを保持したい場合は、バックエンドサービス `web-store` のスパンの 100% を保持する**シングルスパンサンプリングルール**を構成してください。このサンプリングでは、上記の 10% 以外のデータベース呼び出しスパンは取り込まれません。 +- オプションで、すべての `web-store` スパンを保持する必要がある場合は、バックエンドサービス `web-store` のスパンの 100% を保持するように**シングルスパンサンプリングルール**を構成します。このサンプリングでは、上記の 10% 以外のデータベース呼び出しスパンは取り込まれません。 ``` DD_SPAN_SAMPLING_RULES='[{"service": "web-store", "sample_rate": 1}]' ``` - **注**: スパンサンプリングルールの構成は、取り込みスパンから得られる[スパンベースメトリクス][8]を使用する場合に特に有効です。 + **注**: シングルスパンサンプリングルールを構成すると、取り込まれたスパンから得られる[スパンベースメトリクス][8]を使用する場合に特に役立ちます。 -{{< img src="/tracing/guide/ingestion_sampling_use_cases/single-span-sampling3.png" alt="Database spans sampling" style="width:100%;" >}} +{{< img src="/tracing/guide/ingestion_sampling_use_cases/single-span-sampling3.png" alt="データベーススパンのサンプリング" style="width:100%;" >}} -## その他の参考資料 +## 参考資料 {#further-reading} {{< partial name="whats-next/whats-next.html" >}} diff --git a/hugo/content/ja/tracing/trace_pipeline/trace_retention.md b/hugo/content/ja/tracing/trace_pipeline/trace_retention.md index 7277ae15897..3cb4f94b3c8 100644 --- a/hugo/content/ja/tracing/trace_pipeline/trace_retention.md +++ b/hugo/content/ja/tracing/trace_pipeline/trace_retention.md @@ -2,140 +2,187 @@ aliases: - /ja/tracing/trace_retention/ - /ja/tracing/trace_queries/one_percent_flat_sampling/ -description: 保持フィルターでトレース保持を制御する方法について説明します。 +description: 保持フィルターを使用してトレース保持を制御する方法を学びます。 further_reading: +- link: https://www.datadoghq.com/blog/rum-apm-retention-filters + tag: ブログ + text: 保持フィルターを使用してフロントエンドとバックエンドのデータを統合し、関連付けます。 - link: /tracing/trace_pipeline/ingestion_mechanisms tag: ドキュメント - text: 取り込みのメカニズム + text: 取り込みメカニズム - link: /tracing/trace_pipeline/ingestion_controls/ tag: ドキュメント - text: Ingestion Controls + text: 取り込み制御 - link: /tracing/trace_pipeline/metrics/ tag: ドキュメント - text: 使用量メトリクス -title: トレースの保持 + text: 使用状況メトリクス +- link: https://learn.datadoghq.com/courses/apm-rate-limit-retention + tag: ラーニングセンター + text: APM レート制限と保持 +- link: https://www.datadoghq.com/architecture/mastering-distributed-tracing-data-volume-challenges-and-datadogs-approach-to-efficient-sampling/ + tag: アーキテクチャセンター + text: '分散トレーシングの習得: データ量の課題、Datadog の効率的なサンプリングへのアプローチ' +title: トレース保持 --- - {{< img src="tracing/apm_lifecycle/retention_filters.png" style="width:100%; background:none; border:none; box-shadow:none;" alt="保持フィルター" >}} -Datadog APM では、[トレースの取り込みと 15 日間の保持][1]を完全にカスタマイズすることができます。 - -取り込まれたデータとインデックス化されたデータの量を追跡または監視するには、[使用量メトリクス][2]のドキュメントを参照してください。 - -## Retention Filters +Datadog APM では、[トレースの取り込みと 15 日間の保持][1] を完全にカスタマイズできます。 -スパンが取り込まれた後、アカウントに設定された保持フィルターに従って、一部は 15 日間保持されます。 +取り込まれたデータとインデックス化されたデータの量を確認または監視するには、[使用状況メトリクス][2] のドキュメントを参照してください。 -以下の保持フィルターはデフォルトで有効になっており、すべてのサービスやエンドポイント、エラーや高レイテンシーのトレースを確実に可視化することができます。 -- [インテリジェント保持フィルター](#datadog-intelligent-retention-filter)は、環境、サービス、オペレーション、リソースごとに異なるレイテンシー分布のスパンを保持します。 -- `Error Default` 保持フィルターは `status:error` を持つエラースパンをインデックス化します。保持率とクエリは構成することができます。例えば、本番環境のエラーを取得するには、クエリを `status:error, env:production` に設定します。デフォルトでエラーを捕捉したくない場合は、保持フィルターを無効にしてください。 -- Application Security Management を使用している場合、`Application Security` 保持フィルターが有効になります。このフィルタは、アプリケーションセキュリティの影響 (攻撃の試み) があると識別されたトレース内のすべてのスパンの保持を保証します。 -- Synthetic Monitoring を使用している場合、`Synthetics` 保持フィルターが有効になります。デフォルトでは、Synthetic API と Synthetic ブラウザテストから生成されたトレースが利用可能な状態に保たれます。トレースと Synthetic テストを相関付ける方法など、詳細は [Synthetic APM][15] を参照してください。 +## 保持フィルター {#retention-filters} +スパンが取り込まれた後、アカウントに設定された保持フィルターに従って一部のスパンが 15 日間保持されます。 +1. **[インテリジェント保持フィルター](#datadog-intelligent-retention-filter)**は、すべての環境、サービス、オペレーション、リソースについて、異なるレイテンシー分布ごとにスパンを保持します。 +2. いくつかの**[デフォルト保持フィルター](#default-retention-filters)**が作成されており、すべてのサービスとエンドポイント、さらにエラーや高レイテンシーのトレースに対する可視性を確実に維持できます。 +3. 任意の数の追加の**[カスタム保持フィルター](#create-your-own-retention-filter)**をサービスに対して作成し、スパン属性やタグフィルターに基づいて、ビジネスにとって最も重要なトレースを取得できます。 -これらに加えて、サービスのための[カスタムタグベースの保持フィルター](#create-your-own-retention-filter)をいくつでも追加作成し、ビジネスにとって最も重要なデータをキャプチャすることが可能です。 - -**注**: 保持フィルターの作成、削除、変更、有効化、無効化には `apm_retention_filter_write` 権限が必要です。 +**注**: 保持フィルターを作成、削除、変更、有効化、または無効化するには、`apm_retention_filter_write` 権限が必要です。 {{< img src="tracing/trace_indexing_and_ingestion/retention_filters/retention_filters.png" style="width:100%;" alt="保持フィルターページ" >}} -Datadog では、[Retention Filters タブ][3]で、すべての保持フィルターのリストを見ることができます。 +Datadog の [保持フィルター][3] 設定ページでは、すべての保持フィルターを一覧表示できます。 -Filter Name -: スパンをインデックス化するために使用される各保持フィルターの名前。 +フィルター名 +: スパンのインデックス化に使用される各保持フィルターの名前。 -Filter Query +フィルタークエリ : 各フィルターのタグベースのクエリ。 -Retention Rate -: インデックス化されるマッチングスパンの数の 0～100% のパーセンテージを指定します。保持されるスパンは、フィルタークエリに一致するスパンの中から一律に選ばれます。 +保持率 +: 一致するスパンのうち、インデックス化される割合 (0〜100%)。保持されるスパンは、フィルタークエリに一致するスパンの中から均一に選択されます。 -Spans Indexed +インデックス化されたスパン : 選択した期間中にフィルターによってインデックス化されたスパンの数。 -Last Updated -: 最後に保持フィルターを変更したユーザーとその日付。 +最終更新日 +: 保持フィルターを最後に変更した日付とユーザー。 + +有効化トグル +: フィルターのオン/オフを切り替えることができます。 + +**注**: 保持フィルター一覧の順序は、インデックス化動作に影響します。スパンが保持フィルター一覧の上位に一致した場合、そのスパンは保持されるか、破棄されます。保持フィルター一覧の下位にある一致するカスタム保持フィルターは、すでに処理されたスパンをキャッチしません。 + +各保持フィルターの `Spans Indexed` 列は、`datadog.estimated_usage.apm.indexed_spans` メトリクスによって提供されており、これを使用してインデックス化されたスパンの使用状況を追跡できます。詳細については、[使用状況メトリクス][2] をお読みいただくか、アカウントで利用可能な [すぐに使える使用状況ダッシュボード][4] をご覧ください。 + +
保持フィルターは、Agent によって収集されて Datadog に送信 (「インジェスト」) されるトレースには影響しません。取り込みを制御するには、専用の取り込み制御を使用します。
+ -Enabled toggle -: フィルターのオンとオフを切り替えることができます。 +### 保持フィルターの種類 {#retention-filter-types} -**注**: 保持フィルターリストの順序は、インデックスの動作を変更します。スパンがリストの早い段階で保持フィルタに一致した場合、そのスパンは保持されるか削除されるかのどちらかです。リストの下位にある一致する保持フィルターは、すでに処理されたスパンを捕らえません。 +保持フィルターには 2 つのタイプがあります。 -各保持フィルターの `Spans Indexed` 列は、 `datadog.estimated_usage.apm.indexed_spans` メトリクスによって提供され、これを使用してインデックス化されたスパンの使用量を追跡することが可能です。詳細については、[使用量メトリクス][2]を読むか、アカウントで利用できる[ダッシュボード][4]を参照してください。 +1. **スパンレベルの保持フィルター** - フィルター条件に一致する特定のスパンのみをインデックス化します。 +2. **トレースレベルの保持フィルター** - フィルター条件に一致するスパンを含むトレース全体をインデックス化し、Trace Queries で完全なトレースを検索できるようにします。 -
注: 保持フィルターは、Agent によって収集され、Datadog に送信される (「取り込まれる」) トレースには影響しません。取り込まれるトレースデータの量を変更する唯一の方法は、取り込みコントロールを使用することです。
+| 機能 | 標準の保持フィルター | トレースレベルの保持フィルター| +| ------- | ------------------------- | ----------------------------- | +| **構成** | スパンクエリ + スパン保持率 | スパンクエリ + スパン保持率 + トレース保持率 | +| **インデックス対象** | クエリで指定されたスパンのみ | クエリに一致するスパンを含むトレースに属するすべてのスパン | +| **クエリ可能な場所** | スパンエクスプローラー | スパンエクスプローラーおよびトレースクエリ | -### Datadog インテリジェント保持フィルター +**注**: トレースレベルの保持フィルターによって保持される間接的にインデックス化されたスパン (つまり、クエリには直接一致しないが、一致するトレースに属するスパン) は、[トレース分析モニター][19] では評価されません。 -Datadog のインテリジェント保持フィルターは、サービスに対して常にアクティブであり、何十ものカスタム保持フィルターを作成する必要なく、代表的なトレースの選択を保持します。これは以下で構成されます。 +### デフォルトの保持フィルター {#default-retention-filters} + +以下の保持フィルターがデフォルトで有効になっています。 +- `Error Default`保持フィルターは、`status:error` でエラーのスパンをインデックス化します。保持率とクエリは構成可能です。たとえば、本番環境のエラーをキャプチャするには、クエリを `status:error, env:production` に設定します。エラーをデフォルトでキャプチャしたくない場合は、保持フィルターを無効にします。 +- [App and API Protection][16] を使用している場合、`App and API Protection Default` 保持フィルターが有効になっています。これにより、アプリケーションセキュリティへの影響 (攻撃の試み) があると特定されたトレース内のすべてのスパンが確実に保持されます。 +- Synthetic Monitoring を使用している場合、`Synthetics Default` 保持フィルターが有効になっています。これにより、Synthetic API テストやブラウザテストから生成されたトレースがデフォルトで利用可能な状態に保たれます。トレースと Synthetic テストを関連付ける方法など、詳細については [Synthetic APM][15] を参照してください。 +- [Dynamic Instrumentation][17] を使用している場合、`Dynamic Instrumentation Default` 保持フィルターが有効になっています。これにより、Dynamic Instrumentation で動的に作成されたスパンがデフォルトで長期的に利用可能な状態に保たれます。 + +### Datadog インテリジェント保持フィルター {#datadog-intelligent-retention-filter} + +Datadog インテリジェント保持フィルターは利用中のサービスに対して常にアクティブであり、数十ものカスタム保持フィルターを作成することなく代表的なトレースの選択を保持します。これは以下で構成されています。 - [多様性サンプリング](#diversity-sampling) -- [1% フラットサンプリング](#one-percent-flat-sampling) +- [1% のフラットサンプリング](#one-percent-flat-sampling) + +**注:** [トレースクエリ][11] は、インテリジェント保持フィルターによってインデックス化されたデータに基づいています。 + +インテリジェント保持フィルター (多様性サンプリングおよび 1% のフラットサンプリング) によってインデックス化されたスパンは、インデックス化されたスパンの**使用量としてカウントされず**、**請求額に影響しません**。 + +インテリジェント保持フィルターが保持する以上のスパンを特定のタグや属性に対してインデックス化したい場合は、[独自の保持フィルターを作成](#create-your-own-retention-filter)します。 + +#### 多様性サンプリング {#diversity-sampling} + +多様性サンプリングは**サービスエントリスパン**をスキャンし、以下を 30 日間保持します。 -**Note:** [Trace Queries][11] are based on the data indexed by the Intelligent Retention filter. +- 環境、サービス、オペレーション、リソースの各組み合わせについて、最大 15 分ごとに少なくとも 1 つのスパン (および関連するトレース) を保持します。これにより、トラフィックが少ないエンドポイントであっても、[サービス][9] ページや [リソース][10] ページで常にトレースの例を見つけることができます。 +- 環境、サービス、オペレーション、リソースの各組み合わせにおける、`p75`、`p90`、および `p95` パーセンタイルの高レイテンシースパン (および関連するトレース)。 +- エラーの多様性を確保するための代表的なエラーの選択 (例: レスポンスステータスコード 400 番台、500 番台)。 -インテリジェント保持フィルターによってインデックス化されたスパン (多様性サンプリングと 1% フラットサンプリング) は、インデックス化されたスパンの**使用量にカウントされない**ため、**請求に影響を与えません**。 +多様性サンプリングによってキャプチャされたデータセットは、均一にサンプリングされたものではありません (つまり、全トラフィックを比例的に代表するものではありません)。エラーや高レイテンシートレースに偏ったデータとなっています。 -インテリジェント保持フィルターが保持するスパンよりも多くインデックス化したい特定のタグや属性がある場合、[独自の保持フィルターを作成](#create-your-own-retention-filter)してください。 +#### 1% のフラットサンプリング {#one-percent-flat-sampling} -#### 多様性サンプリング +フラット 1% サンプリングは以下をキャプチャします。 +1. トレースが取り込まれた RUM セッションの 1% と相関するすべての**トレース**。これにより、インデックス化された一部のセッションに必ず関連するトレースデータが存在するようになります。これにより [APM と RUM の相関][20] が向上し、フロントエンドセッションとバックエンドトレースの両方を一緒に表示することで、ユーザーの問題をデバッグできるようになります。サンプルは `session_id` に基づいて適用されるため、同じ RUM セッションにリンクされているすべてのトレースは、一貫したインデックス化の決定を共有します。 +2. [取り込まれたスパン][12] の**均一な 1% サンプル**は、`trace_id` に基づいて適用されるため、同じトレース内のすべてのスパンが同じサンプリング決定を共有します。このサンプルを一般的なシステムヘルスモニタリングおよび傾向分析に使用します。 -多様性サンプリングは**サービスエントリースパン**をスキャンして、以下を 30 日間保持します。 +このサンプリングメカニズムは均一であり、取り込まれた全トラフィックを比例的に代表しています。その結果、短い時間枠でフィルタリングすると、トラフィックの少ないサービスやエンドポイントがそのデータセットから欠落する可能性があります。 -- 環境、サービス、オペレーション、リソースの各組み合わせについて、最大 15 分ごとに少なくとも 1 つのスパン (および関連するトレース)。これにより、トラフィックの少ないエンドポイントでも、[サービス][9]と[リソース][10]のページに常にトレース例を見つけることができるようになっています。 -- 環境、サービス、オペレーション、リソースの組み合わせごとに、`p75`、`p90`、`p95` のパーセンタイルスパン (および関連するトレース) の高レイテンシースパン。 -- エラーの代表的な選択。これにより、エラーの多様性を保証します (たとえば、応答ステータスコード 400、500)。 +### 独自の保持フィルターを作成する {#create-your-own-retention-filter} -多様性サンプリングでキャプチャされたデータセットは、一様にサンプリングされていません (つまり、全トラフィックを比例的に代表していません)。エラーやレイテンシーの高いトレースに偏ります。 +特定のトレースデータを 15 日間保持するためのカスタム保持フィルターを作成します。フィルタークエリでスパンタグや属性を使用して、ビジネスにとって最も重要なスパンをターゲットにし、保持します。 -#### 1% フラットサンプリング +たとえば、以下のようなすべてのトレースを保持するフィルターを作成できます。 -フラット 1% サンプリングは[取り込まれたスパン][12]の**均一な 1% サンプル**です。これは `trace_id` に基づいて適用され、同じトレースに属するすべてのスパンが同じサンプリング決定を共有することを意味します。 +- 100 ドルを超えるクレジットカード取引: `@transaction_amount:>100` +- 本番環境で 2 秒を超える期間のチェックアウト操作スパン: `resource_name:"GET /checkout" @duration:>2s env:prod` +- オンラインデリバリーサービスアプリケーションの特定のバージョン: `service:delivery-api @version:v2.0` -このサンプリングメカニズムは均一であり、取り込まれたトラフィック全体を比例的に代表します。その結果、短い時間枠でフィルタリングすると、トラフィックの少ないサービスやエンドポイントがそのデータセットから欠落する可能性があります。 +保持フィルターを使用してスパンをインデックス化すると、以下のようになります。 -### 独自の Retention Filter を作成 +- **検索可能性**: インデックス化されたスパンは、Trace Explorer やダッシュボードで検索でき、15 日間監視されます。 -タグに基づく追加フィルターの作成、変更、無効化により、どのスパンをインデックス化し、15 日間保持するかを決定することができます。各フィルターに一致するスパンの保持する割合を設定します。保持されたスパンは、対応するトレースも保存され、[トレースエクスプローラー][7]で表示すると、完全なトレースが利用可能です。 +- **可視化コンテキスト**: Trace Explorer でインデックス化されたスパンをクリックすると、他のスパンがインデックス化されていたかどうかにかかわらず、常にその完全なトレースコンテキスト (すべての親スパンと子スパン) をフレームグラフまたはウォーターフォールビューで確認できます。 -**注: ** トレースエクスプローラーでタグによる検索を行うには、検索対象のタグを直接含むスパンが保持フィルターによってインデックス化されている必要があります。 +- **検索コンテキスト**: 完全なトレースを可視化することはできますが、Trace Explorer で検索できるのは保持フィルターによって明示的にインデックス化されたスパンのみです。 -{{< img src="tracing/trace_indexing_and_ingestion/retention_filters/create_retention_filter.png" style="width:90%;" alt="保持フィルターの作成">}} +{{< img src="tracing/trace_indexing_and_ingestion/retention_filters/retention_filter_create.png" style="width:90%;" alt="保持フィルターを作成する">}} -1. 任意のスパンタグを追加して、保持クエリを定義します。定義されたタグを持つ_すべてのスパン_を保持するか、_[サービスエントリスパン][5]_のみを保持するか (デフォルトで選択)、または_[トレースルートスパン][8]_のみを保持するかを選択します。 -2. インデックス化するこれらのタグに一致するスパンの割合を設定します。 -3. フィルターに名前を付けます。 -4. 新しいフィルターを保存します。 +保持フィルターを作成するには、以下の手順に従います。 +1. [{{< ui >}}APM{{< /ui >}} > {{< ui >}}Retention Filters{{< /ui >}}][18] に移動します。 +1. {{< ui >}}Add Retention Filter{{< /ui >}} をクリックします。 +1. 保持したいスパンをターゲットにするための {{< ui >}}Retention Query{{< /ui >}} 定義します。[Trace Explorer][7] でクエリを作成する場合と同様、任意のスパンまたは属性を使用してスパンをフィルタリングします。 +1. このクエリに一致するスパンのうち、インデックス化する割合を定義する {{< ui >}}Span rate{{< /ui >}} を設定します。 +1. オプションで {{< ui >}}Trace rate{{< /ui >}} を設定して、インデックス化するスパンに関連付けられた完全なトレースの割合を定義します。これにより、保持クエリによってターゲットにされたスパンに関連付けられたトレースの他のスパンも確実にインデックス化され、インデックス化されたデータが [トレースクエリ][11] でクエリ可能になります。 +1. フィルターの名前を設定します。 +1. {{< ui >}}Add Filter{{< /ui >}} をクリックして保持フィルターを保存します。 -新しいフィルターを作成したり、既存のフィルターの保持率を編集すると、Datadog はグローバルインデックスボリュームの変化率の推定値を表示します。 +
トレース率を構成すると、インデックス化されるスパンの使用量が大幅に増加する可能性があります。
-フィルターは直列に保持されます。上流フィルターで `resource:POST /hello_world` というタグのスパンを保持している場合、同じタグのスパンを検索する下流フィルターの **Edit** ウィンドウには、上流フィルターによって保持されているため、それらのスパンは表示されません。 +たとえば、`service:my-service` からのスパンをインデックス化するように保持フィルターを設定した場合: +- `50%` のスパン率を構成すると、`service:my-service` に一致するスパンを含むトレースの約 50% が選択されるようにする上で役立ちます。選択されたトレースについては、`service:my-service` に一致するすべてのスパンがインデックス化されます。 +- `10%` のトレース率を構成すると、スパン率によって選択されたトレースのうち 10% が完全にインデックス化されるようにする上で役立ちます。それらのトレースについては、トレース内の (`service:my-service` からのものだけでなく) すべてのスパンがインデックス化されます。トレースの平均スパン数が 100 で、`service:my-service` からのスパンが 5 つあると仮定すると、トレース率を構成することで、選択されたトレースの構成された割合に対してトレースの残りの 95 のスパンがインデックス化されます。 +- スパン率が最初に評価され、トレース率はスパン率によって選択されたトレースにのみ適用されます。 -たとえば、フィルターを作成し、以下のすべてのトレースを保持することができます。 +新しいフィルターを作成する場合や既存のフィルターの保持率を編集する場合、Datadog はグローバルインデックス化ボリュームの推定変化率を表示します。 -- $100 以上のクレジットカード取引。 -- SaaS ソリューションのミッションクリティカルな機能を使用中の最重要顧客。 -- オンラインのデリバリーサービスアプリケーションの特定バージョン。 +フィルターはシリアル順に保持されます。`resource:POST /hello_world` タグを持つスパンを保持するアップストリームフィルターがある場合、同じタグを持つスパンを検索するダウンストリームフィルターの {{< ui >}}Edit{{< /ui >}} ウィンドウにはそれらのスパンは表示されません。なぜなら、それらはアップストリームフィルターによって保持されているからです。 -## インデックス化されたスパンのトレース検索と分析 +## インデックス化されたスパンのトレース検索と分析 {#trace-search-and-analytics-on-indexed-spans} -### In the Trace Explorer, dashboards, and notebooks +### Trace Explorer、ダッシュボード、およびノートブック内 {#in-the-trace-explorer-dashboards-and-notebooks} -By default, spans indexed by custom retention filters **and** the intelligent retention filter are included in the Trace Explorer [aggregated views][6] (timeseries, toplist, table), as well as in dashboards and notebook queries. +デフォルトでは、カスタム保持フィルター**および**インテリジェント保持フィルターによってインデックス化されたスパンは、トレースエクスプローラーの [集計ビュー][6] (時系列、トップリスト、テーブル) のほか、ダッシュボードやノートブックのクエリにも含まれます。 -しかし、ダイバーシティサンプリングされたデータセットは、**一様にサンプリングされていない** (つまり、全トラフィックを比例して代表していない) ため、エラーや高レイテンシーのトレースに偏っているので、クエリに `-retained_by:diversity_sampling` クエリパラメーターを追加すれば、これらのスパンをこれらの表示から除外することができます。 -`retained_by` 属性は、すべての保持されたスパンに存在します。その値は次の通りです。 -- スパンがダイバーシティサンプリング ([インテリジェント保持フィルター](#datadog-intelligent-retention-filter)の一部) によってキャプチャされた場合は `retained_by:diversity_sampling`。 -- スパンが 1% フラットサンプリングでインデックス化された場合は、`retained_by:flat_sampled`。 -- スパンが、`Error Default` や `Application Security Default` などの[タグベースの保持フィルター](#create-your-own-retention-filter)によってキャプチャされていた場合は、`retained_by:retention_filter`。 +`retained_by` 属性は、保持されたすべてのスパンに存在します。その値は次のとおりです。 +- `retained_by:retention_filter`[カスタム保持フィルター](#create-your-own-retention-filter)によってスパンがキャプチャされた場合 ([デフォルトの保持フィルター](#default-retention-filters)を含み、**トレースレートなし**が構成されていた場合)。これらのスパンはトレースクエリには含まれません。トレースクエリでは、トレースのすべてのスパンがインデックス化されている必要があるためです。 +- `retained_by:trace_retention_filter`トレースレートが設定された保持フィルターによってスパンがキャプチャされた場合。 +- `retained_by:diversity_sampling`[多様性サンプリング](#diversity-sampling) ([インテリジェント保持フィルター](#datadog-intelligent-retention-filter)の一部) によってスパンがキャプチャされた場合。 +- `retained_by:flat_sampled`[1% フラットサンプリング](#one-percent-flat-sampling)によってスパンがインデックス化された場合。保持理由でさらに絞り込みます。 + - `@retention_reason:rum` `session_id` に基づいてサンプリングされた RUM セッションにリンクされたトレース。これを使用して、ユーザーセッションと相関するトレースを分析します。 + - `@retention_reason:trace` `trace_id` に基づいて均一にサンプリングされたトレース。これを使用して、一般的なパフォーマンスの傾向とシステム全体の分析を行います。 -{{< img src="tracing/trace_indexing_and_ingestion/retention_filters/trace_analytics.png" style="width:100%;" alt="ファセットで保持" >}} +{{< img src="tracing/trace_indexing_and_ingestion/retention_filters/trace_analytics.png" style="width:100%;" alt="ファセットによる保持" >}} -### In trace analytics monitors +### トレース分析モニター内 {#in-trace-analytics-monitors} -For the reasons explained above, spans indexed by the intelligent retention filter are **excluded** from APM trace analytics monitor evaluation. +インテリジェント保持フィルターによってインデックス化されたスパンは、APM トレース分析モニターの評価から**除外**されます。 -## その他の参考資料 +## 関連資料{#further-reading} {{< partial name="whats-next/whats-next.html" >}} @@ -153,4 +200,9 @@ For the reasons explained above, spans indexed by the intelligent retention filt [12]: /ja/tracing/trace_pipeline/ingestion_controls/ [13]: /ja/tracing/trace_explorer/ [14]: /ja/monitors/types/apm/?tab=traceanalytics -[15]: /ja/synthetics/apm/ \ No newline at end of file +[15]: /ja/synthetics/apm/ +[16]: /ja/security/application_security/ +[17]: /ja/dynamic_instrumentation/ +[18]: https://app.datadoghq.com/apm/traces/retention-filters +[19]: /ja/monitors/types/apm/?tab=traceanalytics +[20]: /ja/tracing/other_telemetry/rum/ \ No newline at end of file diff --git a/hugo/content/ko/account_management/rbac/data_access.md b/hugo/content/ko/account_management/rbac/data_access.md index 4449b861cb7..1b0d6597d8a 100644 --- a/hugo/content/ko/account_management/rbac/data_access.md +++ b/hugo/content/ko/account_management/rbac/data_access.md @@ -9,7 +9,7 @@ title: Data Access Control --- ## 개요 {#overview} -Datadog의 데이터에는 민감한 정보가 포함될 수 있으므로 주의해서 다루어야 합니다. 민감한 데이터를 Datadog으로 수집하는 경우, Data Access Control을 통해 Datadog 조직 내의 관리자와 액세스 관리자가 이 데이터에 대한 액세스를 제어할 수 있습니다. Data Access Control을 사용하여 쿼리로 민감한 데이터를 식별하고 특정 [팀][1] 또는 [역할][2]에만 액세스를 허용할 수 있습니다. +Datadog의 데이터에는 민감한 정보가 포함될 수 있으므로 주의해서 다루어야 합니다. 민감한 데이터를 Datadog으로 수집하는 경우, Data Access Control을 통해 Datadog 조직 내의 관리자와 액세스 관리자가 이 데이터에 대한 액세스를 제어할 수 있습니다. Data Access Control을 사용하여 쿼리로 민감한 데이터를 식별하고 특정 [Teams][1] 또는 [역할][2]에만 액세스를 허용할 수 있습니다. _Restricted Dataset_를 정의하면 해당 데이터 세트 경계 내의 모든 데이터에 대한 액세스가 제한됩니다. Restricted Dataset 외부의 데이터는 액세스가 제한되지 않으며 적절한 권한이 있는 사용자만 액세스할 수 있습니다. Data Access Control은 액세스 관리자가 데이터 세트에 포함된 민감한 데이터에 대해 허용된 사용자에게만 액세스 권한을 부여할 수 있는 직관적인 인터페이스를 제공합니다. @@ -25,27 +25,27 @@ Data Access Control은 액세스 경계를 정의하는 데 사용할 수 있는 ## 데이터 액세스 구성 {#configure-data-access} -Data Access Control를 사용하면 지정된 팀 또는 역할의 사용자만 액세스할 수 있는 데이터를 지정하여 Restricted Dataset를 만들 수 있습니다. +Data Access Control을 사용하면 지정된 팀 또는 역할의 사용자만 액세스할 수 있는 데이터를 지정하여 Restricted Dataset를 만들 수 있습니다. -Restricted Dataset를 모두 보려면 [조직 설정][6]으로 이동하여 왼쪽의 {{< ui >}}Access{{< /ui >}} 제목 아래에서 [Data Access Control][7]를 선택합니다. +Restricted Dataset를 모두 보려면 [조직 설정][6]으로 이동하여 왼쪽의 {{< ui >}}Access{{< /ui >}} 제목 아래에서 [Data Access Controls][7]를 선택합니다. ### Datadog 사이트 {#datadog-site} Datadog Admin 역할이 할당된 사용자 또는 조직 내에서 [`user_access_manage` 권한][5]을 지닌 역할의 사용자로 로그인합니다. 1. [조직 설정][6]으로 이동합니다. -1. 페이지 왼쪽에서 [Data Access Control][7]를 선택합니다. +1. 페이지 왼쪽에서 [Data Access Controls][7]를 선택합니다. 1. {{< ui >}}New Restricted Dataset{{< /ui >}}를 클릭합니다. Restricted Dataset를 만들려면 쿼리를 통해 제한할 데이터를 식별합니다. {{< img src="/account_management/rbac/restricted_dataset-3.png" alt="Restricted Dataset 생성 대화 상자. service:hr 태그와 일치하는 RUM, APM, 로그 및 메트릭의 데이터를 선택합니다. Privileged access 팀에 대한 액세스 권한을 부여합니다.">}} -이름 데이터 세트 +데이터 세트 이름 지정 : 사용자가 데이터 세트에 어떤 데이터가 포함되어 있는지 알기 쉽게 나타내는 이름입니다. 이 데이터 세트에 포함할 데이터 선택 -: 특정 사용자 세트로 제한할 데이터를 설명하는 경계 정의입니다. 경계는 액세스 관리자가 보호할 민감한 데이터의 범위를 정의할 수 있도록 제한 사항이 포함된 쿼리 문입니다. [지원되는 텔레메트리 유형][10]은 사용자 지정 메트릭, RUM 세션, APM 트레이스, 로그, 클라우드 비용, 오류 추적 이슈, Software Delivery 리포지토리 정보(CI Visibility pipelines) 및 Workload Protection Agent 이벤트입니다. +: 특정 사용자 세트로 제한할 데이터를 설명하는 경계 정의입니다. 경계는 액세스 관리자가 보호할 민감한 데이터의 범위를 정의할 수 있도록 제한 사항이 포함된 쿼리 문입니다. [지원되는 텔레메트리 유형][10]은 사용자 지정 메트릭, RUM 세션, APM 트레이스, 로그, 클라우드 비용, Error Tracking 이슈, Software Delivery 리포지토리 정보(CI Visibility pipelines), Workload Protection Agent 이벤트 및 보안 신호(Cloud SIEM 신호만 해당)입니다. 액세스 권한 부여 : Restricted Dataset에 바인딩된 콘텐츠에 액세스할 수 있는 하나 이상의 팀 또는 역할을 선택하세요. 이 그룹의 구성원이 아닌 사용자는 이 데이터에 액세스할 수 없습니다. @@ -66,12 +66,17 @@ Enterprise 플랜에서는 최대 100개의 Restricted Dataset를 생성할 수 - Error Tracking 이슈 - 로그 - RUM 세션 +- 보안 신호(Cloud SIEM 신호만 해당) - Software Delivery 리포지토리 정보(CI Visibility pipelines 내) - Workload Protection Agent 이벤트 다음은 요청 시 미리 보기로 제공됩니다. - 사용자 지정 메트릭 - **참고:** 표준 및 OpenTelemetry(OTel) 메트릭은 지원되지 않습니다. +- Database Monitoring +- 호스트 +- 프로세스 +- Containers ## 고급 구성 {#advanced-configuration} @@ -88,9 +93,9 @@ Strict Mode는 텔레메트리 유형별로 구성됩니다. 텔레메트리 유 Restricted Dataset는 Standard Mode와 Strict Mode 간에 공유할 수 없습니다(각 데이터 세트는 하나의 모드에 속함). -**Strict Mode를 활성화하기 전**, 해당 텔레메트리 유형에 대해 이미 Restricted Dataset에 _포함되지 않은_ 데이터가 무엇인지 확인하세요. Strict Mode가 활성화되면 해당 데이터는 숨겨집니다. [Data Access Control][7] 페이지에서 기존 Restricted Dataset를 검토하여 적용 범위를 확인하세요. +**Strict Mode를 활성화하기 전**, 해당 텔레메트리 유형에 대해 이미 Restricted Dataset에 _포함되지 않은_ 데이터가 무엇인지 확인하세요. Strict Mode가 활성화되면 해당 데이터는 숨겨집니다. [Data Access Controls][7] 페이지에서 기존 Restricted Dataset를 검토하여 적용 범위를 확인하세요. -텔레메트리 유형의 제한 모드를 변경하려면 [Data Access Control][7]로 이동하세요. 사용자는 제한 모드를 변경할 수 있는 [`user_access_manage` 권한][5]이 있어야 합니다. +텔레메트리 유형의 제한 모드를 변경하려면 [Data Access Controls][7]로 이동하세요. 사용자는 제한 모드를 변경할 수 있는 [`user_access_manage` 권한][5]이 있어야 합니다. ### Unrestricted User Group {#unrestricted-user-groups} @@ -104,7 +109,7 @@ Unrestricted User Group은 지정된 관리자가 모든 Restricted Dataset에 ## 사용량 제약 {#usage-constraints} -Data Access Control를 켜면 Datadog에서 민감한 데이터에 대한 액세스를 제어하는 다른 기능을 비활성화하거나 제한합니다. 제한되는 기능은 아래에서 영향을 받는 기능 목록을 참조하세요. +Data Access Control을 켜면 Datadog에서 민감한 데이터에 대한 액세스를 제어하는 다른 기능을 비활성화하거나 제한합니다. 제한되는 기능은 아래에서 영향을 받는 기능 목록을 참조하세요. ### Real User Monitoring(RUM) {#real-user-monitoring-rum} @@ -220,15 +225,15 @@ Data Access Control을 구성하기 전에 액세스 전략을 평가하는 것 * {{< ui >}}Grant access:{{< /ui >}} * 서비스를 소유한 팀 -이 설정 예제는 `NewService`에서 지원되는 모든 데이터를 보호합니다. +이 설정 예제는 `NewService`의 지원되는 모든 데이터를 보호합니다. ### 팀 및 역할 {#teams-and-roles} -Data Access Control은 Datadog 역할 또는 팀을 통해 사용자에게 액세스 권한을 부여하는 것을 지원합니다. 액세스 권한을 부여할 때는 기존 액세스 제어 구성 및 액세스 전략을 고려하세요. 서비스 기반 접근 방식을 사용하고 있고, 이미 [카탈로그를 사용자 지정][9]하고 있다면 Data Access Control 구성에 팀을 포함하여 서비스 소유권 모델을 활용하세요. +Data Access Control은 Datadog 역할 또는 팀을 통해 사용자에게 액세스 권한을 부여하는 것을 지원합니다. 액세스 권한을 부여할 때는 기존 액세스 제어 구성 및 액세스 전략을 고려하세요. 서비스 기반 접근 방식을 사용하고 있고, 이미 [카탈로그를 사용자 지정][9]하고 있다면 Data Access Control 구성에 Teams를 포함하여 서비스 소유권 모델을 활용하세요. -**참고:** Data Access Control에 사용되는 팀은 `Anyone in the organization`이 아닌 팀 구성원 또는 관리자만 사용자를 추가하거나 제거할 수 있도록 설정해야 합니다. +**참고:** Data Access Control에 사용되는 Teams는 `Anyone in the organization`이 아닌 팀 구성원 또는 관리자만 사용자를 추가하거나 제거할 수 있도록 설정해야 합니다. -## 액세스 실행 {#access-enforcement} +## 액세스 적용 {#access-enforcement} Data Access Control이 활성화된 Datadog 조직의 사용자는 Dashboard, Explorer 또는 API를 통해 액세스 권한이 있는 데이터에 대한 쿼리 결과만 볼 수 있습니다. Restricted Dataset는 권한이 없는 사용자에 대해 모든 Datadog 환경 및 진입점에서 Restricted Dataset에 정의된 데이터에 대한 액세스를 제거합니다. diff --git a/hugo/content/ko/actions/workflows/test_and_debug.md b/hugo/content/ko/actions/workflows/test_and_debug.md new file mode 100644 index 00000000000..8e63ffc26e5 --- /dev/null +++ b/hugo/content/ko/actions/workflows/test_and_debug.md @@ -0,0 +1,81 @@ +--- +algolia: + tags: + - workflow + - workflows + - workflow automation +aliases: +- /ko/service_management/workflows/test_and_debug +description: 실행 기록 및 오류 메시지를 사용하여 모니터 트리거, 개별 워크플로 단계를 테스트하고 실패한 단계를 디버깅하세요. +disable_toc: false +further_reading: +- link: /getting_started/workflow_automation/ + tag: 설명서 + text: Workflow Automation 시작 +- link: /actions/workflows/build + tag: 설명서 + text: 워크플로 빌드 +- link: /actions/workflows/trigger + tag: 설명서 + text: 워크플로를 트리거 +title: 테스트 및 디버깅 +--- +## 모니터 트리거를 테스트 {#test-a-monitor-trigger} + +워크플로 생성 중에 모니터 트리거를 테스트할 수 있습니다. 모니터를 테스트하면 워크플로를 트리거하기 위해 모니터 알림창에 붙여넣을 수 있는 스니펫이 생성됩니다. + +모니터 트리거를 테스트하려면 다음 단계를 따르세요. +1. 워크플로에서 모니터 트리거 액션을 선택합니다. +1. {{< ui >}}Test from Monitor{{< /ui >}}를 클릭합니다. +1. 모니터가 워크플로에 입력을 전달하는 경우, {{< ui >}}Workflow Inputs{{< /ui >}} 아래에 테스트 값을 입력합니다. +1. 테스트할 모니터를 선택합니다. +1. 모니터 상태를 선택합니다. +1. {{< ui >}}Run From Monitor{{< /ui >}}를 클릭합니다. + + +## 단계 테스트 {#test-a-step} + +전체 워크플로를 실행하지 않고도 단계가 원하는 대로 작동하는지 확인하기 위해 단계를 독립적으로 테스트할 수 있습니다. + +워크플로 단계를 테스트하려면 다음 단계를 따르세요. +1. 단계의 {{< ui >}}Inputs{{< /ui >}} 섹션에서 {{< ui >}}Test{{< /ui >}}를 클릭합니다. +1. 필요시 단계 구성을 조정합니다. 단계에서 이전 단계의 출력 변수를 사용하는 경우, 단계에서 사용할 하드코딩된 테스트 데이터를 입력하세요. +1. {{< ui >}}Test{{< /ui >}}를 클릭하여 액션을 테스트합니다. +1. 단계 테스트를 완료하면 {{< ui >}}Use in configuration{{< /ui >}}을 클릭하여 새 구성을 워크플로에 적용합니다. 테스트 구성을 저장하지 않고 워크플로로 돌아가려면 화면을 닫으세요. + +브랜치 및 로직 액션에는 테스트 기능을 사용할 수 없습니다. 이전 단계의 출력 변수를 사용하는 JavaScript 함수 또는 표현식 액션을 테스트하려면 코드에서 변수를 주석 처리하고 테스트 데이터로 교체하세요. 자세한 내용은 [표현식 및 함수 테스트][6]를 참조하세요. + + +## 실패한 단계 디버깅 {#debug-a-failed-step} + +워크플로의 {{< ui >}}Run History{{< /ui >}}를 사용하여 실패한 단계를 디버깅할 수 있습니다. 왼쪽 상단에서 {{< ui >}}Configuration{{< /ui >}} 또는 {{< ui >}}Run History{{< /ui >}}를 클릭하여 구성 조회와 실행 기록 조회 간에 전환하세요. + +실패한 단계를 클릭하면 해당 단계의 입력, 출력, 실행 컨텍스트 및 관련 오류 메시지가 표시됩니다. 아래 예시는 실패한 _GitHub 풀 리퀘스트 상태 확인_ 단계를 보여줍니다. 오류 메시지에는 권한 누락으로 인해 단계가 실패했음이 표시됩니다. + +{{< img src="actions/workflows/test_and_debug/failed-step4.png" alt="실패한 단계가 포함된 워크플로" >}} + +워크플로의 초기 실행 기록에는 이전 워크플로 실행 목록과 각 실행의 성공 또는 실패 여부가 패널에 표시됩니다. 실패한 실행에는 실패한 워크플로 단계로 연결되는 링크가 포함됩니다. 확인하려면 목록에서 워크플로 실행을 클릭하세요. 워크플로 캔버스의 아무 곳이나 클릭하면 언제든지 초기 실행 기록으로 돌아갈 수 있습니다. + + +## AI로 실패한 단계 수정{#fix-a-failed-step-with-ai} + +{{< ui >}}Run History{{< /ui >}}에서 실패한 단계를 선택하고 {{< ui >}}Outputs{{< /ui >}} 탭을 여세요. 오류 메시지 옆의 {{< ui >}}Fix with AI{{< /ui >}}를 클릭하여 실패 해결에 대한 도움을 받으세요. + +{{< img src="actions/workflows/test_and_debug/fix-with-ai.png" alt="실패한 워크플로 단계를 진단하고 수정 사항을 제안하는 Bits Chat" >}} + +어시스턴트가 [Bits Chat][7]에서 열리며, 단계의 입력값, 출력값, 실행 컨텍스트 및 오류 메시지를 사용하여 실패 원인을 진단하고, 타사 API에서 반환된 오류에 대해서는 외부 문서를 검색할 수 있습니다. 문제를 설명하고 해결 방법을 제안한 후, 변경 사항을 적용하기 전에 사용자에게 확인을 요청합니다. 사용자가 확인하면 어시스턴트가 단계 구성을 업데이트하고 유효성 검사를 다시 실행합니다. + +AI 수정은 잘못된 입력값이나 오래된 액션 설정과 같은 워크플로 구성의 문제에 적용됩니다. 잘못된 자격 증명, 속도 제한 또는 연결된 서비스의 중단과 같은 외부 요인으로 인한 실패의 경우, 어시스턴트가 근본 원인을 설명하고 자격 증명 확인 또는 연결된 서비스 소유자에게 문의하는 등의 다음 단계를 제안합니다. + +실패한 단계가 다른 워크플로를 트리거하는 경우, Bits Chat은 트리거된 워크플로까지 실패를 추적하여 해당 워크플로에 대해서도 원인을 진단하고 해결 방법을 제안할 수 있습니다. + + +## 추가 자료 {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +
질문이나 피드백이 있으신가요? [Datadog 커뮤니티 슬랙][10]의 **#workflows** 채널에 참여하세요. + +[6]: /ko/actions/workflows/expressions/ +[7]: /ko/bits_ai/bits_chat/ +[10]: https://chat.datadoghq.com/ \ No newline at end of file diff --git a/hugo/content/ko/agent/configuration/network.md b/hugo/content/ko/agent/configuration/network.md index ee3e93bfc60..cf820a5680c 100644 --- a/hugo/content/ko/agent/configuration/network.md +++ b/hugo/content/ko/agent/configuration/network.md @@ -18,19 +18,19 @@ further_reading: text: Datadog 사이트에 대해 알아보기 - link: /logs/ tag: 설명서 - text: 로그 수집 + text: 로그 수집하기 - link: /infrastructure/process tag: 설명서 - text: 프로세스 수집 + text: 프로세스 수집하기 - link: tracing tag: 설명서 - text: 트레이스 수집 + text: 트레이스 수집하기 title: 네트워크 트래픽 --- ## 개요 {#overview}
-트래픽은 항상 Agent에서 시작해 Datadog으로 이동합니다. Datadog에서 Agent로 시작되는 세션은 없습니다. +트래픽은 항상 Agent에서 시작해 Datadog으로 이동합니다. Datadog에서 Agent 방향으로 시작되는 세션은 없습니다.
모든 Agent 트래픽은 SSL을 통해 전송됩니다. Datadog 서비스 및 사이트에 따라 대상이 결정됩니다. [Datadog 사이트][11]에 따른 대상을 보려면 오른쪽의 {{< ui >}}DATADOG SITE{{< /ui >}} 선택기를 클릭하세요. @@ -48,18 +48,18 @@ Agent 설치를 허용하려면 다음의 도메인을 포함 목록에 추가 ## 대상 {#destinations}
버전 7.67.0부터 Agent는 DNS 쿼리 수를 줄이기 위해 Datadog 사이트를 완전한 적격 도메인 이름으로 변환합니다(도메인 끝에 점 추가). -예를 들어 APM 페이로드를 다음으로 전송합니다 trace.agent.datadoghq.com..
-이 동작은 버전 7.72.0 이상의 구성에서 convert_dd_site_fqdn.enabled 를 false 로 설정하거나 다음 환경 변수를 사용해 비활성화할 수 있습니다. DD_CONVERT_DD_SITE_FQDN_ENABLED=false. +예를 들어 APM 페이로드를 trace.agent.datadoghq.com.로 전송합니다.
+이 동작은 버전 7.72.0 이상의 구성에서 convert_dd_site_fqdn.enabled 를 false 로 설정하거나 DD_CONVERT_DD_SITE_FQDN_ENABLED=false환경 변수를 사용해 비활성화할 수 있습니다.
[APM][1] : `trace.agent.`{{< region-param key="dd_site" code="true" >}}
`instrumentation-telemetry-intake.`{{< region-param key="dd_site" code="true" >}} -[LLM Observabilty][23] +[LLM Observability][23] : `llmobs-intake.`{{< region-param key="dd_site" code="true" >}} -[컨테이너 이미지][13] +[Container Images][13] : `contimage-intake.`{{< region-param key="dd_site" code="true" >}} [Live Containers][3], [Live Process][4], [Cloud Network Monitoring][24], [Universal Service Monitoring][25] @@ -72,7 +72,7 @@ Agent 설치를 허용하려면 다음의 도메인을 포함 목록에 추가 [Network Path][14] : `netpath-intake.`{{< region-param key="dd_site" code="true" >}}
-Agent v7.75+에서는 Network Path가 소스 호스트의 퍼블릭 IP를 리졸브하기 위해 HTTPS를 사용해 외부 서비스에 접속합니다. 이것은 선택 사항이고 Network Path는 이 기능 없이도 정상 작동하지만, 네트워크가 아웃바운드 트래픽을 제한하고 소스 퍼블릭 IP를 리졸브하고자 하는 경우, 허용 목록에 다음을 추가하세요. `icanhazip.com`, `ipinfo.io`, `checkip.amazonaws.com`, `api.ipify.org`, `whatismyip.akamai.com`. 자세한 내용은 [Network Path 설정][33]을 참조하세요. +Agent v7.75+에서는 Network Path가 소스 호스트의 퍼블릭 IP를 리졸브하기 위해 HTTPS를 사용해 외부 서비스에 접속합니다. 이것은 선택 사항이고 Network Path는 이 기능 없이도 정상 작동하지만, 네트워크가 아웃바운드 트래픽을 제한하고 소스 퍼블릭 IP를 리졸브하고자 하는 경우, 허용 목록에 `icanhazip.com`, `ipinfo.io`, `checkip.amazonaws.com`, `api.ipify.org`, `whatismyip.akamai.com`을 추가하세요. 자세한 내용은 [Network Path 설정][33]을 참조하세요. [오케스트레이터][5] : `orchestrator.`{{< region-param key="dd_site" code="true" >}}
@@ -84,7 +84,7 @@ Agent v7.75+에서는 Network Path가 소스 호스트의 퍼블릭 IP를 리졸 [Real User Monitoring(RUM)][6] : {{< region-param key="browser_sdk_endpoint_domain" code="true" >}} -[Cloud Security 취약점][29] +[Cloud Security Vulnerabilities][29] : `sbom-intake.`{{< region-param key="dd_site" code="true" >}} [Synthetic Monitoring 프라이빗 위치][8] @@ -93,7 +93,7 @@ Synthetics Worker > v0.1.6의 API 테스트 결과: `intake.synthetics.`{{< regi Synthetics Worker > v0.2.0의 브라우저 테스트 결과: `intake-v2.synthetics.`{{< region-param key="dd_site" code="true" >}}
Synthetics Worker < v0.1.5의 API 테스트 결과: `api.`{{< region-param key="dd_site" code="true" >}} -{{% site-region region="us,eu,us3,us5,ap1,ap2" %}} +{{% site-region region="us,eu,us3,us5,ap1,ap2,uk1" %}} [Remote Configuration][101] : `config.`{{< region-param key="dd_site" code="true" >}} @@ -102,35 +102,40 @@ Synthetics Worker < v0.1.5의 API 테스트 결과: `api.`{{< region-param key=" : `dbm-metrics-intake.`{{< region-param key="dd_site" code="true" >}}
`dbquery-intake.`{{< region-param key="dd_site" code="true" >}} +[End User Device Monitoring][103] +: `softinv-intake.`{{< region-param key="dd_site" code="true" >}}
+`eudm-intake.`{{< region-param key="dd_site" code="true" >}} + [101]: /ko/remote_configuration [102]: /ko/database_monitoring/ +[103]: /ko/infrastructure/end_user_device_monitoring/ {{% /site-region %}} {{% logs-tcp-disclaimer %}} [로그][30] 및 [HIPAA 로그][31] -: (사용 중단됨) TCP: {{< region-param key=tcp_endpoint code="true" >}}
+: (지원 중단됨) TCP: {{< region-param key=tcp_endpoint code="true" >}}
HTTP: {{< region-param key=agent_http_endpoint code="true" >}}
기타: [로그 엔드포인트][32] 참조 -[HIPAA 로그 레거시][31](사용 중단됨, TCP 지원되지 않음) +[HIPAA 로그 레거시][31](지원 중단됨, TCP 지원되지 않음) : {{< region-param key=hipaa_logs_legacy code="true" >}} -[Metrics][26], [서비스 검사][27], [이벤트][28] 및 기타 Agent 메타데이터 +[메트릭][26], [서비스 검사][27], [이벤트][28] 및 기타 Agent 메타데이터 : `-app.agent.`{{< region-param key="dd_site" code="true" >}}
예를 들어 Agent v7.31.0은 `7-31-0-app.agent.`{{< region-param key="dd_site" code="true" >}}에 보고합니다. 방화벽의 포함 목록에 `*.agent.`{{< region-param key="dd_site" code="true" >}} 를 추가해야 합니다.
Agent는 v6.1.0 이후부터 Datadog의 API에 중요하지 않은 기능도 제공하도록 쿼리합니다(예를 들어 구성된 API 키의 유효성 표시).
Agent v7.18.0 또는 6.18.0 이상: `api.`{{< region-param key="dd_site" code="true" >}}
Agent < v7.18.0 또는 6.18.0: `app.`{{< region-param key="dd_site" code="true" >}} -[Agent flare][12] +[Agent 플레어][12] : `-flare.agent.`{{< region-param key="dd_site" code="true" >}}
-예를 들어 Agent v7.31.0 은 flare 데이터를 `7-31-0-flare.agent.`{{< region-param key="dd_site" code="true" >}}로 보냅니다. 방화벽의 포함 목록에 `*.agent.`{{< region-param key="dd_site" code="true" >}} 를 추가해야 합니다.
+예를 들어 Agent v7.31.0은 플레어 데이터를 `7-31-0-flare.agent.`{{< region-param key="dd_site" code="true" >}}에 보고합니다. 방화벽의 포함 목록에 `*.agent.`{{< region-param key="dd_site" code="true" >}} 를 추가해야 합니다.
### 정적 IP 주소 {#static-ip-addresses} -이러한 모든 도메인은 일련의 정적 IP 주소를 가리키는 **CNAME** 레코드입니다. 이러한 주소는 `https://ip-ranges.`에서 확인할 수 있습니다.{{< region-param key="dd_site" code="true" >}}. +이러한 모든 도메인은 일련의 정적 IP 주소를 가리키는 **CNAME** 레코드입니다. 이러한 주소는 `https://ip-ranges.`{{< region-param key="dd_site" code="true" >}}에서 확인할 수 있습니다. 정보는 이 스키마를 따른 JSON 형식으로 구조화됩니다. @@ -166,7 +171,7 @@ Agent < v7.18.0 또는 6.18.0: `app.`{{< region-param key="dd_site" code="true" ### 포함 {#inclusion} -`ip-ranges`를 모두 포함 목록에 추가하세요. 언제든 부분 집합 하나만 활성 상태이지만, 정기 네트워크 작업 및 유지 관리로 인해 시간이 지나면서 전체 세트 안에 변형 버전이 생깁니다. +`ip-ranges`를 모두 포함 목록에 추가하세요. 어느 시점이든 전체 주소 중 일부만 활성 상태이지만, 정기적인 네트워크 운영 및 유지 관리로 인해 활성화되는 주소는 시간이 지남에 따라 전체 집합 내에서 달라집니다. ## 포트 열기 {#open-ports} @@ -186,8 +191,9 @@ Agent < v7.18.0 또는 6.18.0: `app.`{{< region-param key="dd_site" code="true" | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Agent
APM
Containers
Live Processes
Metrics
Cloud Network Monitoring
Universal Service Monitoring | 443 | TCP | 대부분의 Agent 데이터는 포트 443을 사용합니다. | | [사용자 지정 Agent Autoscaling][22] | 8443 | TCP | | -| 로그 수집 | {{< region-param key=web_integrations_port >}} | (사용 중단됨) TCP | TCP를 통해 로깅합니다.
**참고**:TCP 로그 수집은 지원되지 **않습니다**. Datadog은 TCP 사용 시 **전달 또는 안정성을 보장하지 않으며** 통보 없이 로그 데이터가 손실될 수 있습니다. 안정적으로 수집하려면 공식 Datadog Agent인 HTTP 인테이크 엔드포인트를 사용하거나, 포워더 통합을 사용하세요. 다른 연결 유형은 [로그 엔드포인트][21]를 참조하세요. | +| 로그 수집 | {{< region-param key=web_integrations_port >}} | (지원 중단됨) TCP | TCP를 통해 로깅합니다.
**참고**:TCP 로그 수집은 **지원되지 않습니다**. Datadog은 TCP 사용 시 **전달 또는 안정성을 보장하지 않으며** 통보 없이 로그 데이터가 손실될 수 있습니다. 안정적으로 수집하려면 HTTP 인테이크 엔드포인트, 공식 Datadog Agent 또는 포워더 통합을 사용하세요. 다른 연결 유형은 [로그 엔드포인트][21]를 참조하세요. | | NTP | 123 | UDP | Network Time Protocol(NTP). [기본 NTP 대상][20]을 참조하세요.
NTP 문제 해결에 대한 자세한 내용은 [NTP 문제][19]를 참조하세요. | +| 연결성 테스트 | 8042 | TCP | 원격 구성 연결성 테스트입니다.
**참고**: 프로토콜 개발을 위한 텔레메트리 엔드포인트로, 고객 데이터가 포함되어 있지 않으며 [Remote Config][101]가 활성화된 경우에만 사용됩니다. [19]: /ko/agent/faq/network-time-protocol-ntp-offset-issues/ [20]: /ko/integrations/ntp/#overview @@ -196,7 +202,7 @@ Agent < v7.18.0 또는 6.18.0: `app.`{{< region-param key="dd_site" code="true" {{% /site-region %}} -{{% site-region region="us3,us5,gov,gov2,ap1,ap2" %}} +{{% site-region region="us3,us5,gov,gov2,ap1,ap2,uk1" %}} | 제품/기능 | 포트 | 프로토콜 | 설명 | | ------------------------------------------------------------------------------------------------------------------- | ---- | -------- | ---------------------------------------------------------------------------------------------------------------------------- | @@ -216,16 +222,16 @@ Agent < v7.18.0 또는 6.18.0: `app.`{{< region-param key="dd_site" code="true" | ---------------------------- | ---- | -------- | ------------------------------------------------------------------------------------------------------------------------------ | | [Agent 브라우저 GUI][16] | 5002 | TCP | | | APM 수신기 | 8126 | TCP | Tracing 및 Profiler를 포함합니다. | -| [DogStatsD][18] | 8125 | UDP | DogStatsD의 포트입니다. 단, `dogstatsd_non_local_traffic`이 true로 설정된 경우는 예외입니다. 이 포트는 다음 IPv4 localhost에서 사용 가능: `127.0.0.1`. | -| go_expvar 서버(APM) | 5012 | TCP | 자세한 내용은 [go_expar 통합 설명서][15]를 참조하세요. | -| go_expvar 통합 서버 | 5000 | TCP | 자세한 내용은 [the go_expar 통합 설명서][15]를 참조하세요. | +| [DogStatsD][18] | 8125 | UDP | DogStatsD의 포트입니다. 단, `dogstatsd_non_local_traffic`이 true로 설정된 경우는 예외입니다. 이 포트는 `127.0.0.1` IPv4 localhost에서 사용 가능합니다. | +| go_expvar 서버(APM) | 5012 | TCP | 자세한 내용은 [go_expvar 통합 설명서][15]를 참조하세요. | +| go_expvar 통합 서버 | 5000 | TCP | 자세한 내용은 [go_expvar 통합 설명서][15]를 참조하세요. | | IPC API | 5001 | TCP | 프로세스 간 통신(IPC)에 사용되는 포트입니다. | | Process Agent 디버그 | 6062 | TCP | Process Agent의 디버그 엔드포인트입니다. | | Process Agent 런타임 | 6162 | TCP | Process Agent의 런타임 구성 설정입니다. | -## 포트 구성 {#configure-ports} +## 포트 구성하기 {#configure-ports} -기본 포트를 이미 네트워크상의 기존 서비스가 사용 중이라서 인바운드 포트를 변경해야 하는 경우, `datadog.yaml` 구성 파일을 편집하세요. 대부분의 포트는 파일의 **고급 구성** 섹션에서 확인할 수 있습니다. +기본 포트를 이미 네트워크상의 기존 서비스에서 사용하고 있어 인바운드 포트를 변경해야 하는 경우, `datadog.yaml` 구성 파일을 편집하세요. 대부분의 포트는 파일의 **고급 구성** 섹션에서 확인할 수 있습니다. {{< code-block lang="yaml" filename="datadog.yaml" disable_copy="true" collapsible="true" >}} ## @param expvar_port - integer - optional - default: 5000 @@ -275,7 +281,7 @@ APM 수신기 및 DogStatsD 포트는 `datadog.yaml` 구성 파일에서 각각
여기에서 DogStatsD 포트 또는 APM 수신기 포트 값을 변경하는 경우, 해당하는 포트의 Datadog SDK 구성도 변경해야 합니다. 포트 구성에 관한 언어별 라이브러리 구성 설명서의 정보를 참조하세요.
-## 프록시 사용 {#using-proxies} +## 프록시 사용하기 {#using-proxies} 프록시 설정에 대한 자세한 구성 가이드는 [Agent 프록시 구성][9]을 참조하세요. @@ -284,13 +290,13 @@ APM 수신기 및 DogStatsD 포트는 `datadog.yaml` 구성 파일에서 각각 네트워크를 사용할 수 없게 되면 Agent가 메모리에 메트릭을 저장합니다. 메트릭 저장을 위한 메모리 최대 사용량은 `forwarder_retry_queue_payloads_max_size` 구성 설정으로 정의됩니다. 이 한도에 도달하면 메트릭이 삭제됩니다. -Agent v7.27.0 이상은 메모리 한도에 도달했을 때 메트릭을 디스크에 저장합니다. 이 기능을 활성화하려면 `forwarder_storage_max_size_in_bytes`를 양수로 설정하세요. 이것이 Agent가 메트릭을 디스크에 저장하는 데 사용할 수 있는 최대 스토리지 공간 양을 나타냅니다(바이트 단위). +Agent v7.27.0 이상은 메모리 한도에 도달했을 때 메트릭을 디스크에 저장합니다. 이 기능을 활성화하려면 `forwarder_storage_max_size_in_bytes`를 양수로 설정하세요. Agent가 메트릭을 디스크에 저장하는 데 사용할 수 있는 최대 스토리지 공간 양을 나타냅니다(바이트 단위). 메트릭은 `forwarder_storage_path` 설정에서 정의된 폴더에 저장되며, 이는 기본적으로 Unix 시스템의 경우 `/opt/datadog-agent/run/transactions_to_retry`, Windows의 경우 `C:\ProgramData\Datadog\run\transactions_to_retry`입니다. -저장 공간 부족을 방지하기 위해 Agent는 총 사용 저장 공간이 80% 미만인 경우에만 메트릭을 디스크에 저장합니다. 이 한도는`forwarder_storage_max_disk_ratio` 설정으로 정의됩니다. +저장 공간 부족을 방지하기 위해 Agent는 총 사용 저장 공간이 80% 미만인 경우에만 메트릭을 디스크에 저장합니다. 이 한도는 `forwarder_storage_max_disk_ratio` 설정으로 정의됩니다. -## Datadog Operator 설치{#installing-the-datadog-operator} +## Datadog Operator 설치하기 {#installing-the-datadog-operator} 연결에 한계가 있는 Kubernetes 환경에 Datadog Operator를 설치하는 경우, 레지스트리에 따라 다음과 같은 TCP 포트 443 엔드포인트를 허용 목록에 추가해야 합니다. diff --git a/hugo/content/ko/api/latest/agent-observability/batch-update-agent-observability-dataset-records/index.md b/hugo/content/ko/api/latest/agent-observability/batch-update-agent-observability-dataset-records/index.md new file mode 100644 index 00000000000..e5a03631a32 --- /dev/null +++ b/hugo/content/ko/api/latest/agent-observability/batch-update-agent-observability-dataset-records/index.md @@ -0,0 +1,3 @@ +--- +title: Agent Observability 데이터세트 레코드 일괄 업데이트 +--- diff --git a/hugo/content/ko/api/latest/agent-observability/get-a-specific-agent-observability-prompt-version/index.md b/hugo/content/ko/api/latest/agent-observability/get-a-specific-agent-observability-prompt-version/index.md new file mode 100644 index 00000000000..e8b79419ad3 --- /dev/null +++ b/hugo/content/ko/api/latest/agent-observability/get-a-specific-agent-observability-prompt-version/index.md @@ -0,0 +1,3 @@ +--- +title: 특정 Agent Observability 프롬프트 버전을 가져오기 +--- diff --git a/hugo/content/ko/api/latest/agent-observability/get-annotation-queue-label-schema/index.md b/hugo/content/ko/api/latest/agent-observability/get-annotation-queue-label-schema/index.md new file mode 100644 index 00000000000..c1942ceb94c --- /dev/null +++ b/hugo/content/ko/api/latest/agent-observability/get-annotation-queue-label-schema/index.md @@ -0,0 +1,3 @@ +--- +title: 주석 대기열 레이블 스키마 조회 +--- diff --git a/hugo/content/ko/api/latest/agent-observability/list-agent-observability-datasets/index.md b/hugo/content/ko/api/latest/agent-observability/list-agent-observability-datasets/index.md new file mode 100644 index 00000000000..5cca8fbba6f --- /dev/null +++ b/hugo/content/ko/api/latest/agent-observability/list-agent-observability-datasets/index.md @@ -0,0 +1,3 @@ +--- +title: Agent Observability 데이터세트 나열 +--- diff --git a/hugo/content/ko/api/latest/agent-observability/list-events-for-an-agent-observability-experiment/index.md b/hugo/content/ko/api/latest/agent-observability/list-events-for-an-agent-observability-experiment/index.md new file mode 100644 index 00000000000..c8d04d56c28 --- /dev/null +++ b/hugo/content/ko/api/latest/agent-observability/list-events-for-an-agent-observability-experiment/index.md @@ -0,0 +1,3 @@ +--- +title: Agent Observability 실험의 이벤트를 나열하십시오 +--- diff --git a/hugo/content/ko/api/latest/agent-observability/list-versions-of-an-agent-observability-prompt/index.md b/hugo/content/ko/api/latest/agent-observability/list-versions-of-an-agent-observability-prompt/index.md new file mode 100644 index 00000000000..824d76d0ab1 --- /dev/null +++ b/hugo/content/ko/api/latest/agent-observability/list-versions-of-an-agent-observability-prompt/index.md @@ -0,0 +1,3 @@ +--- +title: Agent Observability 프롬프트의 버전을 나열하십시오. +--- diff --git a/hugo/content/ko/api/latest/data-deletion/cancels-a-data-deletion-request/index.md b/hugo/content/ko/api/latest/data-deletion/cancels-a-data-deletion-request/index.md new file mode 100644 index 00000000000..0efc5df88f3 --- /dev/null +++ b/hugo/content/ko/api/latest/data-deletion/cancels-a-data-deletion-request/index.md @@ -0,0 +1,3 @@ +--- +title: 데이터 삭제 요청을 취소합니다 +--- diff --git a/hugo/content/ko/api/latest/llm-observability/aggregate-agent-observability-experimentation/index.md b/hugo/content/ko/api/latest/llm-observability/aggregate-agent-observability-experimentation/index.md new file mode 100644 index 00000000000..46b31bbc34b --- /dev/null +++ b/hugo/content/ko/api/latest/llm-observability/aggregate-agent-observability-experimentation/index.md @@ -0,0 +1,3 @@ +--- +title: Agent Observability 실험 집계 +--- diff --git a/hugo/content/ko/api/latest/llm-observability/list-agent-observability-datasets/index.md b/hugo/content/ko/api/latest/llm-observability/list-agent-observability-datasets/index.md new file mode 100644 index 00000000000..5cca8fbba6f --- /dev/null +++ b/hugo/content/ko/api/latest/llm-observability/list-agent-observability-datasets/index.md @@ -0,0 +1,3 @@ +--- +title: Agent Observability 데이터세트 나열 +--- diff --git a/hugo/content/ko/api/latest/llm-observability/unlock-agent-observability-dataset-draft-state/index.md b/hugo/content/ko/api/latest/llm-observability/unlock-agent-observability-dataset-draft-state/index.md new file mode 100644 index 00000000000..41731780e78 --- /dev/null +++ b/hugo/content/ko/api/latest/llm-observability/unlock-agent-observability-dataset-draft-state/index.md @@ -0,0 +1,3 @@ +--- +title: Agent Observability 데이터셋 초안 상태의 잠금을 해제하십시오. +--- diff --git a/hugo/content/ko/api/latest/product-analytics/list-the-entities-behind-a-retention-cell/index.md b/hugo/content/ko/api/latest/product-analytics/list-the-entities-behind-a-retention-cell/index.md new file mode 100644 index 00000000000..f0f698d1de9 --- /dev/null +++ b/hugo/content/ko/api/latest/product-analytics/list-the-entities-behind-a-retention-cell/index.md @@ -0,0 +1,3 @@ +--- +title: 리텐션 셀 뒤에 있는 엔티티를 나열하십시오. +--- diff --git a/hugo/content/ko/api/latest/rum-teams-ownership/list-teams-ownership-rules/index.md b/hugo/content/ko/api/latest/rum-teams-ownership/list-teams-ownership-rules/index.md new file mode 100644 index 00000000000..8772079840c --- /dev/null +++ b/hugo/content/ko/api/latest/rum-teams-ownership/list-teams-ownership-rules/index.md @@ -0,0 +1,3 @@ +--- +title: 팀 소유권 규칙 나열하기 +--- diff --git a/hugo/content/ko/byoc-logs/introduction/network.md b/hugo/content/ko/byoc-logs/introduction/network.md new file mode 100644 index 00000000000..55d6345f42f --- /dev/null +++ b/hugo/content/ko/byoc-logs/introduction/network.md @@ -0,0 +1,49 @@ +--- +aliases: +- /ko/cloudprem/introduction/network/ +further_reading: +- link: /byoc-logs/configure/ingress/ + tag: 설명서 + text: BYOC Logs 인그레스 구성 +title: 네트워크 +--- +이 문서는 BYOC(Bring Your Own Cloud) Logs와 Datadog이 서로 통신하는 방법에 대한 개요를 제공합니다. + +## 역방향 연결(기본값) {#reverse-connection-default} + +기본적으로 BYOC Logs **searcher** 포드는 API 키를 사용하여 Datadog으로의 아웃바운드 WebSocket 연결을 시작합니다. 각 searcher 포드는 `wss:///api/unstable/cloudprem-connection-gateway/connect`에 대한 자체 연결을 유지합니다. + +Datadog은 다음과 같은 이유로 이 설정을 권장합니다. +- **네트워크에서 열어야 할 인바운드 포트가 없습니다.** +- **DNS 레코드나 퍼블릭 인그레스가 필요하지 않습니다.** +- 연결이 귀하의 인프라에서 시작되므로 방화벽 및 보안 정책이 간소화됩니다. + +### 역방향 연결을 통해 흐르는 데이터 {#what-flows-through-the-reverse-connection} + +| 데이터 | 방향 | 설명 | +|------|-----------|-------------| +| 검색 쿼리 | Datadog → BYOC Logs | 로그 탐색기, 대시보드, 모니터에서 발생하는 쿼리 | +| 쿼리 결과 | BYOC Logs → Datadog | 표시를 위해 반환된 일치하는 로그 항목 | +| 인덱스 관리 | Datadog → BYOC Logs | 인덱스 생성, 업데이트, 삭제 | + +### 네트워크 요구 사항 {#network-requirements} + +검색기 포드는 Datadog 사이트에 대한 **아웃바운드 HTTPS(포트 443)** 액세스가 필요합니다(예: `app.datadoghq.com`). 인바운드 연결은 필요하지 않습니다. + +환경에서 HTTP 프록시를 사용하는 경우, BYOC Logs는 `HTTPS_PROXY`, `ALL_PROXY`, `NO_PROXY` 환경 변수를 사용한 표준 프록시 구성을 지원합니다. + +### Datadog에 연결되는 포드 {#which-pods-connect-to-datadog} + +**searcher** 포드만 역방향 연결을 설정합니다. 인덱서, 컨트롤 플레인, 메타스토어 및 자니터는 Datadog에 대한 연결을 시작하지 않습니다. + +
역방향 연결을 사용할 때는 최소 하나의 searcher 포드를 실행 상태로 유지하세요. 모든 searcher 포드를 사용할 수 없거나 다음으로 확장된 경우: 0, searcher 포드가 시작되어 다시 연결될 때까지 Datadog은 역방향 연결을 통해 쿼리나 인덱스 관리 요청을 라우팅할 수 없습니다.
+ +## 공용 인그레스(선택 사항) {#public-ingress-optional} + +BYOC Logs를 구성하여 공용 인그레스를 배포함으로써 Datadog이 반대 방향으로 연결을 설정하도록 할 수도 있습니다. + +공용 인그레스를 사용하면 Datadog의 컨트롤 플레인 및 쿼리 서비스가 공용 인터넷을 통해 BYOC Logs 클러스터를 관리하고 쿼리할 수 있습니다. 이는 mTLS 인증을 사용하여 BYOC Logs gRPC API에 대한 보안 액세스를 제공합니다. BYOC Logs 인그레스에 대한 자세한 내용은 [구성 페이지](/byoc-logs/configure/ingress/)에서 확인할 수 있습니다. + +## 추가 자료 {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} \ No newline at end of file diff --git a/hugo/content/ko/cloud_cost_management/allocation/tag_pipelines.md b/hugo/content/ko/cloud_cost_management/allocation/tag_pipelines.md new file mode 100644 index 00000000000..01e4de483f3 --- /dev/null +++ b/hugo/content/ko/cloud_cost_management/allocation/tag_pipelines.md @@ -0,0 +1,123 @@ +--- +aliases: +- /ko/cloud_cost_management/tag_pipelines/ +- /ko/cloud_cost_management/tags/tag_pipelines/ +further_reading: +- link: /cloud_cost_management/ + tag: 설명서 + text: Cloud Cost Management에 대해 알아보기 +- link: /getting_started/tagging/ + tag: 설명서 + text: 태그 시작하기 +- link: /integrations/guide/reference-tables + tag: 설명서 + text: Reference Table에 대해 알아보기 +- link: https://www.datadoghq.com/blog/cloud-cost-management-ai-costs/ + tag: 블로그 + text: Datadog Cloud Cost Management를 사용하여 공급자별 AI 비용 귀속하기 +- link: https://www.datadoghq.com/blog/cloud-cost-management-oci + tag: 블로그 + text: Datadog Cloud Cost Management로 OCI 비용 관리 및 최적화하기 +title: Tag Pipelines +--- +## 개요 {#overview} + +태그는 모든 Cloud Cost Management 분석 및 할당의 기반입니다. 태그를 사용하면 서비스, 팀, 프로젝트, 환경 또는 비즈니스와 관련된 모든 기준별로 지출을 세분화할 수 있습니다. Tag Pipelines는 클라우드 리소스 전반에서 표준화된 태그 사용을 적용하며 조직 전체에서 비용을 일관되고 정확하게 귀속할 수 있도록 지원합니다. + +[Tag Pipelines][1]를 사용하면 클라우드 청구서에서 누락되거나 잘못된 태그를 처리하기 위한 태그 규칙을 생성할 수 있습니다. 또한 특정 비즈니스 로직에 부합하는 새로운 추론 태그를 생성하여 비용 추적의 정확성을 높일 수 있습니다. 이러한 표준화된 태그는 컨테이너 비용 귀속, 사용자 지정 귀속 규칙, 비용 권장 사항을 포함한 모든 비용 분석 기능에 사용됩니다. + +Tag Pipelines는 모든 공급자의 Cloud Cost 메트릭에 적용됩니다. 생성한 규칙은 모든 비용 데이터 및 비용 권장 사항에 영향을 미치며, 대시보드, 모니터, 할당 보고서 전반에서 일관성을 보장합니다. + +태그 파이프라인이 변경되면 새로운 규칙이 최근 3개월간의 데이터에 자동으로 적용됩니다. 규칙이 추가되거나 수정된 후 과거 데이터 업데이트가 완료되기까지 최대 24시간이 소요될 수 있습니다. + +모든 신규 사용자에게는 [태그 정규화 활성화][6]를 위한 권장 규칙이 기본적으로 활성화되어 있습니다. + +## 규칙 세트 생성 {#create-a-ruleset} + +[API][7], [Terraform][8] 또는 아래 지침에 따라 Datadog에서 직접 태그 파이프라인 규칙 세트를 관리할 수 있습니다. + +규칙 세트를 생성하려면 [{{< ui >}}Cloud Cost{{< /ui >}} > {{< ui >}}Settings{{< /ui >}} > {{< ui >}}Tag Pipelines{{< /ui >}}][1]로 이동하세요. + +
최대 100개의 규칙을 생성할 수 있습니다. API 기반 Reference Table은 지원되지 않습니다.
+ +개별 규칙을 생성하기 전에 {{< ui >}}+ New Ruleset{{< /ui >}}을 클릭하여 규칙 세트(규칙을 포함하는 폴더)를 만드세요. + +각 규칙 세트 내에서 {{< ui >}}+ Add New Rule{{< /ui >}}을 클릭하고 {{< ui >}}Add tag{{< /ui >}}, {{< ui >}}Alias tag keys{{< /ui >}} 또는 {{< ui >}}Map multiple tags{{< /ui >}} 중 규칙 유형을 선택하세요. 이 규칙들은 위에서 아래로 정해진 순서에 따라 순차적으로 실행됩니다. + +{{< img src="cloud_cost/pipelines-create-ruleset-1.png" alt="Tag Pipelines 페이지에서 팀, 계정, 서비스, 부서, 사업부 등 다양한 범주를 표시하는 태그 규칙 목록" style="width:60%;" >}} + +규칙과 규칙 세트를 구성하여 실행 순서를 비즈니스 로직과 일치시킬 수 있습니다. + +### 태그 추가 {#add-tag} + +Cloud Cost 데이터에 기존 태그가 있는지 여부에 따라 새 태그(키 + 값)를 추가하세요. + +예를 들어, 리소스가 속한 서비스에 따라 모든 리소스에 해당 사업부를 태그로 지정하는 규칙을 만들 수 있습니다. + +{{< img src="cloud_cost/pipelines-add-tag-2.png" alt="service:process-agent 또는 service:process-billing이 포함된 리소스에 새 사업부 태그를 지정하세요." style="width:60%;" >}} + +{{< ui >}}Additional options{{< /ui >}} 섹션 아래에는 다음과 같은 옵션이 있습니다. + +- {{< ui >}}Action when tag `{tag}` exists{{< /ui >}} - 지정된 태그(위 예시에서는 `business-unit`)가 이미 존재하는 경우 수행할 작업을 선택하세요. + - {{< ui >}}Don't apply the rule{{< /ui >}} - 태그가 이미 존재하는 경우 규칙을 건너뛰고 원래 값을 유지합니다. + - {{< ui >}}Append the tag{{< /ui >}} - 원래 값을 제거하지 않고 기존 태그에 새 값을 추가합니다. + - {{< ui >}}Replace the tag{{< /ui >}} - 기존 태그 값을 새 값으로 교체합니다.
태그를 교체하면 기존 데이터를 덮어쓸 수 있습니다. 이 옵션은 주의해서 사용하세요.
+- {{< ui >}}Apply case-insensitive matching to resource tags{{< /ui >}} - `To resources with tag(s)` 필드에 정의된 태그와 비용 데이터의 태그를 대소문자 구분 없이 처리할 수 있게 합니다. 예를 들어, UI의 리소스 태그가 `foo:bar`이고 비용 데이터의 태그가 `Foo:bar`인 경우, 두 태그를 일치시킬 수 있습니다. + +### 태그 키 별칭 지정 {#alias-tag-keys} + +기존 태그 값을 더 표준화된 태그에 매핑합니다. + +예를 들어, 조직에서 표준 `application` 태그 키를 사용하려고 하지만 여러 팀에서 해당 태그의 변형(`app`, `webapp` 또는 `apps`)을 사용하는 경우, `apps`를 `application`의 별칭으로 지정할 수 있습니다. 각 태그 별칭 규칙에서 최대 25개의 태그 키를 새 태그의 별칭으로 지정할 수 있습니다. + +{{< img src="cloud_cost/pipelines-alias-tag-4.png" alt="app, webapp 또는 apps 태그가 있는 리소스에 application 태그 지정" style="width:60%;" >}} + +`app`, `webapp` 또는 `apps` 태그가 있는 리소스에 application 태그를 지정하세요. 각 리소스에서 첫 번째 일치 항목이 발견되면 규칙 실행을 중지합니다. 예를 들어, 리소스에 이미 `app` 태그가 있는 경우 규칙은 더 이상 `webapp` 또는 `apps` 태그를 식별하지 않습니다. + +{{< ui >}}Additional options{{< /ui >}} 섹션 아래에는 다음과 같은 옵션이 있습니다. + +- {{< ui >}}Action when tag `{tag}` exists{{< /ui >}} - 지정된 태그(위 예시에서는 `application`)가 이미 존재하는 경우 수행할 작업을 선택하세요. + - {{< ui >}}Don't apply the rule{{< /ui >}} - 태그가 이미 존재하는 경우 규칙을 건너뛰고 원래 값을 유지합니다. + - {{< ui >}}Append the tag{{< /ui >}} - 원래 값을 제거하지 않고 기존 태그에 새 값을 추가합니다. + - {{< ui >}}Replace the tag{{< /ui >}} - 기존 태그 값을 새 값으로 교체합니다.
태그를 교체하면 기존 데이터를 덮어쓸 수 있습니다. 이 옵션은 주의해서 사용하세요.
+- {{< ui >}}Apply case-insensitive matching to resource tags{{< /ui >}} - 별칭 태그 키에 정의된 태그와 비용 데이터의 태그를 대소문자 구분 없이 처리할 수 있습니다. 예를 들어, UI의 리소스 태그가 `app:bar`이고 비용 데이터의 태그가 `App:bar`인 경우, 두 태그를 일치시킬 수 있습니다. + +### 여러 태그 매핑 {#map-multiple-tags} + +[Reference Table][2]을 사용하여 여러 규칙을 만들지 않고도 비용 데이터에 여러 태그를 추가하세요. 이 기능은 Reference Table의 기본 키 열 값을 비용 태그의 값에 매핑합니다. 일치하는 항목이 발견되면 파이프라인은 선택한 Reference Table 열을 비용 데이터에 태그로 추가합니다. + +예를 들어, 다양한 AWS 및 Azure 계정이 어떤 VP, 조직 및 사업부에 속하는지에 대한 정보를 추가하려면 표를 만들고 태그를 매핑하세요. + +{{< img src="cloud_cost/pipelines-map-multiple-tags-2.png" alt="태그 파이프라인에 Reference Table을 사용하여 customer_name과 같은 계정 메타데이터 추가" style="width:60%;" >}} + +[별칭 태그 키](#alias-tag-keys)와 마찬가지로, 각 리소스에서 첫 번째 일치 항목이 발견되면 규칙 실행을 중지합니다. 예를 들어, `application`이 발견되면 규칙은 더 이상 `subscription_id`를 찾지 않습니다. + +{{< ui >}}Additional options{{< /ui >}} 섹션 아래에는 다음과 같은 옵션이 있습니다. + +- {{< ui >}}Action when column exists{{< /ui >}} - 지정된 열이 이미 존재하는 경우 수행할 작업을 선택하세요. + - {{< ui >}}Don't apply the rule{{< /ui >}} - 열이 이미 존재하는 경우 규칙을 건너뛰고 원래 값을 유지합니다. + - {{< ui >}}Append the column{{< /ui >}} - 원래 값을 제거하지 않고 기존 열에 새 값을 추가합니다. + - {{< ui >}}Replace the column{{< /ui >}} - 기존 열 값을 새 값으로 교체합니다.
열을 교체하면 기존 데이터를 덮어쓸 수 있습니다. 이 옵션은 주의해서 사용하세요.
+- {{< ui >}}Apply case-insensitive matching for primary key values{{< /ui >}} - Reference Table의 기본 키 값과 비용 데이터에서 태그 키가 기본 키와 일치하는 태그 값을 대소문자를 구분하지 않고 일치시킵니다. 예를 들어, UI의 기본 키 값 쌍이 `foo:Bar`이고 비용 데이터의 태그가 `foo:bar`인 경우 두 값을 일치시킬 수 있습니다. + +## 예약된 태그 {#reserved-tags} + +`env` 및 `host`와 같은 특정 태그는 [예약된 태그][4]이며 [Unified Service Tagging][3]의 일부입니다. `host` 태그는 Tag Pipelines에서 추가할 수 없습니다. + +태그를 사용하면 메트릭, 트레이스, 프로세스 및 로그를 상호 연결하는 데 도움이 됩니다. `host`와 같은 예약된 태그를 통해 인프라 전반에 대한 가시성을 확보하고 효과적으로 모니터링할 수 있습니다. 최적의 상관관계와 실행 가능한 인사이트를 얻으려면 Datadog의 태깅 전략의 일부로 이러한 예약된 태그를 사용하세요. + +## 태그 삭제 {#delete-tags} +Tag Pipelines를 사용하여 생성된 태그를 삭제하려면 해당 태그를 생성한 규칙을 삭제하세요. 24시간 이내에 최근 3개월간의 데이터에서 태그가 자동으로 제거됩니다. 더 오래된 데이터에서 태그를 제거하려면 [Datadog 지원팀][5]에 문의하세요. + +## 추가 자료 {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://app.datadoghq.com/cost/tag-pipelines +[2]: /ko/integrations/guide/reference-tables/?tab=manualupload +[3]: /ko/getting_started/tagging/unified_service_tagging/ +[4]: /ko/getting_started/tagging/ +[5]: /ko/help/ +[6]: /ko/cloud_cost_management/tags#how-tags-are-normalized +[7]: /ko/api/latest/cloud-cost-management/#create-tag-pipeline-ruleset +[8]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/tag_pipeline_ruleset \ No newline at end of file diff --git a/hugo/content/ko/containers/kubernetes/distributions.md b/hugo/content/ko/containers/kubernetes/distributions.md index 8296be99795..b0b257c19f3 100644 --- a/hugo/content/ko/containers/kubernetes/distributions.md +++ b/hugo/content/ko/containers/kubernetes/distributions.md @@ -1,6 +1,7 @@ --- aliases: - /ko/agent/kubernetes/distributions +description: 다양한 Kubernetes 배포판에서 Datadog Agent를 설치하고 구성하기 위한 플랫폼별 지침 further_reading: - link: agent/kubernetes/log tag: 설명서 @@ -16,54 +17,69 @@ further_reading: text: 애플리케이션 메트릭 및 로그 자동 수집 - link: /agent/guide/autodiscovery-management tag: 설명서 - text: 데이터 수집을 컨테이너의 하위 집합으로만 제한 + text: 데이터 수집을 컨테이너의 하위 세트로만 제한 - link: /agent/kubernetes/tag tag: 설명서 text: 컨테이너에서 내보내는 모든 데이터에 태그 할당 - link: https://www.datadoghq.com/blog/monitor-vsphere-tanzu-kubernetes-grid-with-datadog/ tag: 블로그 text: vSphere에서의 Tanzu Kubernetes Grid 모니터링 -title: 쿠버네티스 배포 +title: Kubernetes 배포 --- +## 개요 {#overview} -## 개요 +이 섹션은 모든 주요 Kubernetes 배포판에 대한 세부 사항을 문서화하고 적절한 기본 구성을 제공하는 것을 목표로 합니다. +그런 다음 이러한 구성을 사용자 지정하여 각종 Datadog 기능을 추가할 수 있습니다. -이 섹션은 구체적인 내용의 문서화 및 주요 쿠버네티스 배포에 적합한 기본 설정 제공을 목표로 합니다. -사용자에 맞게 설정을 변경하여 Datadog 기능을 추가할 수 있습니다. - -* [AWS Elastic Kubernetes Service (EKS)](#EKS) -* [Azure Kubernetes Service (AKS)](#AKS) -* [Google Kubernetes Engine (GKE)](#GKE) +* [AWS Elastic Kubernetes Service(EKS)](#EKS) +* [Azure Kubernetes Service(AKS)](#AKS) +* [Google Kubernetes Engine(GKE)](#GKE) * [Red Hat OpenShift](#Openshift) * [Rancher](#Rancher) -* [Oracle Container Engine for Kubernetes (OKE)](#OKE) -* [vSphere Tanzu Kubernetes Grid (TKG)](#TKG) +* [Oracle Container Engine for Kubernetes(OKE)](#OKE) +* [vSphere Kubernetes Service(VKS)](#VKS) +* [vSphere Tanzu Kubernetes Grid(TKG)](#TKG) -## AWS Elastic Kubernetes Service (EKS) {#EKS} +## AWS Elastic Kubernetes Service(EKS) {#EKS} 특정 설정이 필요하지 않습니다. -노드에서 AWS Bottlerocket OS를 사용하는 경우 컨테이너 모니터링(`containerd` 검사)을 사용하도록 설정하려면 다음을 추가하세요: - {{< tabs >}} -{{% tab "Helm" %}} +{{% tab "Datadog Operator" %}} -사용자 지정 `values.yaml`: +EKS 클러스터에서는 [Helm][1]을 사용하거나 [EKS 추가 기능][2]으로 Operator를 설치할 수 있습니다. + +아래 구성은 Agent가 Datadog Operator와 동일한 네임스페이스에 설치된 경우 두 설정(Helm 또는 EKS add-on) 모두에서 작동하도록 되어 있습니다. ```yaml -datadog: - apiKey: - appKey: - criSocketPath: /run/dockershim.sock - env: - - name: DD_AUTOCONFIG_INCLUDE_FEATURES - value: "containerd" +kind: DatadogAgent +apiVersion: datadoghq.com/v2alpha1 +metadata: + name: datadog +spec: + global: + clusterName: + credentials: + apiKey: + appKey: ``` +[1]:/ko/containers/kubernetes/installation/?tab=datadogoperator +[2]: /ko/agent/guide/operator-eks-addon + {{% /tab %}} -{{% tab "Operator" %}} -DatadogAgent 쿠버네티스 리소스: +{{< /tabs >}} + +## Azure Kubernetes Service(AKS) {#AKS} + +### Admission Controller {#admission-controller} +선택 사항인 [Admission Controller][1] 기능은 웹훅을 조정할 때 오류를 방지하기 위해 특정 구성이 필요합니다. + +{{< tabs >}} +{{% tab "Datadog Operator" %}} + +DatadogAgent Kubernetes 리소스: ```yaml kind: DatadogAgent @@ -71,54 +87,64 @@ apiVersion: datadoghq.com/v2alpha1 metadata: name: datadog spec: - features: - admissionController: - enabled: false - externalMetricsServer: - enabled: false - useDatadogMetrics: false global: + clusterName: + site: credentials: apiKey: appKey: - criSocketPath: /run/dockershim.sock override: clusterAgent: - image: - name: gcr.io/datadoghq/cluster-agent:latest + containers: + cluster-agent: + env: + - name: DD_ADMISSION_CONTROLLER_ADD_AKS_SELECTORS + value: "true" ``` -{{% /tab %}} -{{< /tabs >}} +``를 [Datadog 사이트][1]로 바꿉니다. 현재 사이트는 {{< region-param key="dd_site" code="true" >}}입니다(이 페이지 오른쪽에서 계정에 맞는 올바른 사이트가 선택되었는지 확인). -## Azure Kubernetes Service (AKS) {#AKS} - -AKS가 SSL 인증서를 설정한 방식에 따라 `Kubelet` 통합을 위한 특정 설정이 필요합니다. 또한 선택 사항인 [어드미션 컨트롤러][3] 기능을 사용하려면 웹훅을 조정할 때 발생하는 오류 방지를 위해 특정 설정이 필요합니다. - -{{< tabs >}} +[1]: /ko/getting_started/site +{{% /tab %}} {{% tab "Helm" %}} -사용자 지정 `values.yaml`: +사용자 지정 `datadog-values.yaml`: ```yaml datadog: + clusterName: apiKey: appKey: - # Required as of Agent 7.35. See Kubelet Certificate note below. - kubelet: - tlsVerify: false providers: aks: enabled: true ``` -이`providers.aks.enabled` 옵션은 필수적인 환경 변수 `DD_ADMISSION_CONTROLLER_ADD_AKS_SELECTORS="true"`를 설정합니다. +`providers.aks.enabled` 옵션은 필요한 환경 변수 `DD_ADMISSION_CONTROLLER_ADD_AKS_SELECTORS="true"`를 설정합니다. {{% /tab %}} -{{% tab "Operator" %}} +{{< /tabs >}} + +### Kubelet 서빙 인증서 교체 {#kubelet-serving-certificate-rotation} +클러스터에 [Kubelet 서빙 인증서 교체][13]가 활성화되어 있지 **않으면** Datadog Agent가 Kubelet에 연결할 수 있도록 추가 구성을 제공해야 합니다. Kubelet 서빙 인증서 교체는 2025년 7월 이후 업데이트된 노드 풀의 Kubernetes 클러스터 1.27 이상에서 활성화됩니다. + +노드에 `kubernetes.azure.com/kubelet-serving-ca=cluster` 레이블이 있는 경우 이 기능이 활성화된 것입니다. 다음 명령을 실행하여 모든 노드에 이 레이블이 있는지 확인하세요. + +```shell +kubectl get nodes -L kubernetes.azure.com/kubelet-serving-ca +``` + +모든 노드에 `cluster`가 표시되는지 확인하세요. + +#### Kubelet 서빙 인증서 교체 없이 {#without-kubelet-serving-certificate-rotation} + +Kubelet 서빙 인증서 교체가 활성화되지 않은 경우 다음 추가 Kubelet 구성을 제공하세요. + +{{< tabs >}} +{{% tab "Datadog Operator" %}} -DatadogAgent 쿠버네티스 리소스: +DatadogAgent Kubernetes 리소스: ```yaml kind: DatadogAgent @@ -126,15 +152,17 @@ apiVersion: datadoghq.com/v2alpha1 metadata: name: datadog spec: - features: - admissionController: - enabled: true global: + clusterName: + site: credentials: apiKey: appKey: kubelet: - tlsVerify: false + host: + fieldRef: + fieldPath: spec.nodeName + hostCAPath: /etc/kubernetes/certs/kubeletserver.crt override: clusterAgent: containers: @@ -143,28 +171,16 @@ spec: - name: DD_ADMISSION_CONTROLLER_ADD_AKS_SELECTORS value: "true" ``` - {{% /tab %}} -{{< /tabs >}} - -`kubelet.tlsVerify=false`는 서버 인증서 확인을 비활성화하기 위한 `DD_KUBELET_TLS_VERIFY=false` 환경 변수를 설정합니다. - -### AKS Kubelet 인증서 - -이전 노드 이미지 버전에서 AKS Kubelet 인증서의 형식과 관련해 발생한 문제가 있습니다. 에이전트 7.35부터 인증서에 유효한 Subject Alternative Name (SAN)이 포함되어 있지 않으므로 `tlsVerify: false`를 사용해야 합니다. - -AKS 클러스터 내의 모든 노드가 지원되는 노드 이미지 버전을 사용하는 경우, Kubelet TLS Verification을 사용할 수 있습니다. 버전은 [2022-10-30 릴리즈에 대해 여기에 나열된 버전][4] 이상이어야 합니다. 또한 커스텀 인증서 경로의 주소 및 맵에 노드 이름을 사용하도록 Kubelet 설정을 업데이트해야 합니다. - -{{< tabs >}} {{% tab "Helm" %}} -사용자 지정 `values.yaml`: +사용자 지정 `datadog-values.yaml`: ```yaml datadog: + clusterName: apiKey: appKey: - # Requires supported node image version kubelet: host: valueFrom: @@ -176,11 +192,34 @@ providers: aks: enabled: true ``` - {{% /tab %}} -{{% tab "Operator" %}} +{{< /tabs >}} + +이러한 AKS 노드 버전에서는 AKS Kubelet 인증서의 경우 이전 코드 조각에서 볼 수 있듯이 Kubelet 호스트를 `spec.nodeName`으로, 인증서 위치를 `hostCAPath`로 변경해야 합니다. TLS 검증이 활성화됩니다. 이러한 변경 사항이 없으면 Agent가 Kubelet에 연결할 수 없습니다. -DatadogAgent 쿠버네티스 리소스: +
클러스터에서 Kubelet 서빙 인증서 교체가 활성화된 후 이 구성을 제거하세요.
+ +AKS 클러스터를 업그레이드할 때 Kubelet 서빙 인증서 교체 기능이 자동으로 활성화될 수 있으며, 인증서 `/etc/kubernetes/certs/kubeletserver.crt`를 참조하기 위해 위의 특수 구성을 사용하는 경우 Datadog Agent에 부정적인 영향을 줄 수 있습니다. Kubelet 서빙 인증서 교체가 활성화되면 이 인증서가 제거되어 다음 문제가 발생합니다. + +- Datadog Operator의 경우: Agent 컨테이너가 Kubelet에 연결할 수 없어 `Error` 상태로 종료되고 `Error while getting hostname, exiting: unable to reliably determine the host name`을 로깅합니다. +- Helm의 경우: Agent 포드가 `MountVolume.SetUp failed for volume "kubelet-ca" : hostPath type check failed: /etc/kubernetes/certs/kubeletserver.crt is not a file` 이벤트와 함께 시작되지 않습니다. + +이러한 경우에는 추가 Kubelet 구성을 제거하세요. + +대안으로 [TLS 검증 없이 Kubelet에 연결](#without-tls-verification)할 수도 있습니다. + +### TLS 검증 없이 {#without-tls-verification} + +일부 클러스터에서는 AKS 내 포드에서 `spec.nodeName`에 대한 DNS 확인이 작동하지 않습니다. 영향을 받는 항목: + - Windows 노드 + - 사용자 지정 DNS를 사용하는 가상 네트워크에 클러스터가 설정된 경우의 Linux 노드 + +이 경우 아래 제공된 AKS 설정을 사용하여 `tlsVerify: false`를 설정하고 Kubelet 호스트 경로(기본값은 `status.hostIP`)에 대한 설정을 제거하세요. **Kubelet 호스트 경로와 `tlsVerify: false`를 동일한 설정에 지정하지 마세요**. + +{{< tabs >}} +{{% tab "Datadog Operator" %}} + +DatadogAgent Kubernetes 리소스: ```yaml kind: DatadogAgent @@ -188,18 +227,13 @@ apiVersion: datadoghq.com/v2alpha1 metadata: name: datadog spec: - features: - admissionController: - enabled: true global: + clusterName: credentials: apiKey: appKey: kubelet: - host: - fieldRef: - fieldPath: spec.nodeName - hostCAPath: /etc/kubernetes/certs/kubeletserver.crt + tlsVerify: false override: clusterAgent: containers: @@ -210,36 +244,66 @@ spec: ``` {{% /tab %}} -{{< /tabs >}} +{{% tab "Helm" %}} + +사용자 지정 `datadog-values.yaml`: + +```yaml +datadog: + clusterName: + apiKey: + appKey: + kubelet: + tlsVerify: false + +providers: + aks: + enabled: true +``` -일부 설정에서, 포드 내부 `spec.nodeName`에 대한 DNS 해결책이 AKS에서 작동하지 않을 수 있습니다. 이는 모든 AKS 윈도우 노드, 그리고 리눅스 노드에 있는 커스텀 DNS를 사용해 가상 네트워크에서 클러스터를 설정할 때 보고되었습니다. 이 경우 첫 번째 AKS 설정을 사용합니다. Kubelet 호스트 경로(기본값은 `status.hostIP`)에 대한 설정을 모두 제거하고 `tlsVerify: false`를 사용합니다. 이 설정은 **필수**입니다. +{{% /tab %}} +{{< /tabs >}} -## Google Kubernetes Engine (GKE) {#GKE} +## Google Kubernetes Engine(GKE) {#GKE} -GKE는 두 가지 작동 모드로 설정할 수 있습니다: +GKE는 두 가지 작동 모드로 설정할 수 있습니다. - **표준**: 클러스터의 기본 인프라를 관리하여 노드 설정의 유연성을 제공합니다. -- **Autopilot**: GKE는 노드 및 노드 풀을 포함한 클러스터의 기본 인프라를 공급 및 관리함으로써 hands-off 경험과 함께 최적화된 클러스터를 제공합니다. +- **Autopilot**: GKE는 노드 및 노드 풀을 포함한 클러스터의 기본 인프라를 공급 및 관리함으로써 핸즈오프(hands-off) 경험과 함께 최적화된 클러스터를 제공합니다. + +클러스터의 작동 모드에 따라 Datadog Agent를 다르게 설정해야 합니다. -클러스터의 작동 모드에 따라 Datadog 에이전트를 다르게 설정해야 합니다. +### 표준 {#standard} -### 표준 +Agent 7.26 이상 버전의 GKE에서는 `Docker` 또는 `containerd` 실행 여부와 관계없이 추가 설정이 필요하지 않습니다. 단, Helm 차트를 사용하는 Container-Optimized OS(COS)는 예외입니다. Datadog Operator는 GKE COS를 자동으로 탐지합니다. -에이전트 7.26부터는 GKE에 대한 특정 설정이 필요하지 않습니다(`Docker` 또는 `containerd` 실행 여부와 관계 없음). +{{< tabs >}} +{{% tab "Helm" %}} + +사용자 지정 `datadog-values.yaml`: + +```yaml +providers: + gke: + cos: true +``` -**참고**: COS (Container Optimized OS)를 사용하는 경우, Helm 차트 버전 3.0.1부터 eBPF 기반 `OOM Kill` 및 `TCP Queue Length` 검사가 지원됩니다. 이러한 검사를 활성화하려면 다음과 같이 설정합니다: -- `datadog.systemProbe.enableDefaultKernelHeadersPaths`를 `false`로 설정 +{{% /tab %}} +{{< /tabs >}} -### Autopilot +### Autopilot {#autopilot} GKE Autopilot 에는 아래와 같이 몇 가지 설정이 필요합니다. -Datadog은 에이전트 컨테이너에 대한 리소스 제한을 지정할 것을 권장합니다. Autopilot은 비교적 낮은 기본 제한(CPU 50m, 메모리 100Mi)을 설정하므로 사용자 환경에 따라 에이전트 컨테이너가 빠르게 OOMKill로 이어질 수 있습니다. 이에 해당되면, 트레이스 에이전트 및 프로세스 에이전트 컨테이너에 대한 리소스 제한도 지정하시기 바랍니다. +Datadog은 Agent 컨테이너에 대한 리소스 제한을 지정할 것을 권장합니다. Autopilot은 비교적 낮은 기본 제한(50m CPU, 100Mi 메모리)을 설정하므로 환경에 따라 Agent 컨테이너가 빠르게 OOMKill될 수 있습니다. 해당되는 경우 Trace Agent, Process Agent 및 System-Probe 컨테이너에 대한 리소스 제한도 지정합니다. 또한 Agent가 예약되도록 우선순위 클래스를 생성하는 것을 권장합니다. + +Agent `7.65.0+` 및 Helm 차트 버전 `3.113.0+`부터 Datadog은 Agent가 API 서버에서 포드 목록을 쿼리하도록 `datadog.kubelet.useApiServer`를 사용할 것을 권장합니다. [지원이 중단된 읽기 전용 kubelet 포트][12]를 사용하지 마세요. + {{< tabs >}} {{% tab "Helm" %}} -사용자 지정 `values.yaml`: +사용자 지정 `datadog-values.yaml`: ```yaml datadog: @@ -247,12 +311,16 @@ datadog: appKey: clusterName: - # Enable the new `kubernetes_state_core` check. - kubeStateMetricsCore: - enabled: true - # Avoid deploying kube-state-metrics chart. - # The new `kubernetes_state_core` doesn't require to deploy the kube-state-metrics anymore. - kubeStateMetricsEnabled: false + # The site of the Datadog intake to send Agent data to (example: `us3.datadoghq.com`) + # Default value is `datadoghq.com' (the US1 site) + # Documentation: https://docs.datadoghq.com/getting_started/site/ + site: + + # This option uses the API server to retrieve the node-level pod list from the API server. + # This setting is necessary to migrate away from the deprecated read-only kubelet port. + # Requires Agent 7.65.0+ and Datadog Helm chart version 3.113.0+. + kubelet: + useApiServer: true agents: containers: @@ -262,9 +330,6 @@ agents: requests: cpu: 200m memory: 256Mi - limits: - cpu: 200m - memory: 256Mi traceAgent: # resources for the Trace Agent container @@ -272,9 +337,6 @@ agents: requests: cpu: 100m memory: 200Mi - limits: - cpu: 100m - memory: 200Mi processAgent: # resources for the Process Agent container @@ -282,9 +344,15 @@ agents: requests: cpu: 100m memory: 200Mi - limits: + + systemProbe: + # resources for the System Probe container + resources: + requests: cpu: 100m - memory: 200Mi + memory: 400Mi + + priorityClassCreate: true providers: gke: @@ -292,89 +360,165 @@ providers: ``` {{% /tab %}} -{{< /tabs >}} +{{% tab "Datadog Operator" %}} -## Red Hat OpenShift {#Openshift} +Datadog Operator `1.27.0+`부터 `experimental.agent.datadoghq.com/autopilot` 주석을 사용하여 Autopilot 모드를 활성화하세요. Operator는 API 서버 포드 검색 및 필수 WorkloadAllowlist를 포함하여 GKE Autopilot용 Agent를 구성합니다. -OpenShift는 기본적으로 보안이 강화된 상태로 제공되므로(SELinux, SecurityContextConstraints) 몇 가지 설정이 필요합니다: -- 노드 에이전트 및 클러스터 에이전트용 SCC 생성 -- OpenShift가 CRI-O 컨테이너 런타임을 사용하는 특정 CRI 소켓 경로 -- Kubelet API 인증서가 항상 클러스터 CA에 의해 서명되는 것은 아닙니다. -- `master`와 `infra` 노드에 있는 노드 에이전트를 예약하려면 허용 오차가 필요합니다. -- 클러스터 이름은 클라우드 제공자에서 자동 검색할 수 없으므로 반드시 설정해야 합니다. +사용자 지정 `datadog-agent.yaml`: + +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog + annotations: + experimental.agent.datadoghq.com/autopilot: "true" +spec: + global: + credentials: + apiSecret: + secretName: datadog-secret + keyName: api-key + # The site of the Datadog intake to send Agent data to (example: `us3.datadoghq.com`) + # Default value is `datadoghq.com' (the US1 site) + # Documentation: https://docs.datadoghq.com/getting_started/site/ + site: + override: + nodeAgent: + containers: + agent: + resources: + requests: + cpu: 200m + memory: 256Mi + trace-agent: + resources: + requests: + cpu: 100m + memory: 200Mi + process-agent: + resources: + requests: + cpu: 100m + memory: 200Mi + system-probe: + resources: + requests: + cpu: 100m + memory: 400Mi +``` + +{{% /tab %}} +{{< /tabs >}} + +### 스팟 포드 및 컴퓨팅 클래스 {#spot-pods-and-compute-classes} -이 설정은 OpenShift 3.11 및 OpenShift 4 모두 지원하나 OpenShift 4에서 가장 잘 작동합니다. +GKE Autopilot 클러스터에서 [Spot Pods][10]를 사용하면 해당 Spot GKE 노드에 [taints][9]가 도입됩니다. 스팟 포드를 사용할 때는 Agent DaemonSet에 일치하는 허용 오차를 제공하기 위해 추가 구성이 필요합니다. {{< tabs >}} {{% tab "Helm" %}} -커스텀 `values.yaml`: - ```yaml -datadog: - apiKey: - appKey: - clusterName: - criSocketPath: /var/run/crio/crio.sock - # Depending on your DNS/SSL setup, it might not be possible to verify the Kubelet cert properly - # If you have proper CA, you can switch it to true - kubelet: - tlsVerify: false agents: - podSecurity: - securityContextConstraints: - create: true + #(...) + # agents.tolerations -- Allow the DaemonSet to schedule on tainted nodes (requires Kubernetes >= 1.6) tolerations: - effect: NoSchedule - key: node-role.kubernetes.io/master - operator: Exists + key: cloud.google.com/gke-spot + operator: Equal + value: "true" +``` +{{% /tab %}} + +{{% tab "Datadog Operator" %}} + +```yaml +spec: + override: + nodeAgent: + tolerations: + - effect: NoSchedule + key: cloud.google.com/gke-spot + operator: Equal + value: "true" +``` +{{% /tab %}} +{{< /tabs >}} + +마찬가지로 특정 하드웨어 요구 사항이 있는 워크로드를 실행하기 위해 [GKE Autopilot 컴퓨팅 클래스][11]를 사용할 때는 GKE Autopilot이 이러한 특정 노드에 적용하는 [테인트][9]에 유의하고 Agent DaemonSet에 일치하는 허용 오차를 추가하세요. 해당 포드의 허용 오차를 일치시킬 수 있습니다. 예를 들어, `Scale-Out` 컴퓨팅 클래스의 경우 다음과 같은 허용 오차를 사용하세요. + +{{< tabs >}} +{{% tab "Helm" %}} + +```yaml +agents: + #(...) + # agents.tolerations -- Allow the DaemonSet to schedule on tainted nodes (requires Kubernetes >= 1.6) + tolerations: - effect: NoSchedule - key: node-role.kubernetes.io/infra - operator: Exists -clusterAgent: - podSecurity: - securityContextConstraints: - create: true -kube-state-metrics: - securityContext: - enabled: false + key: cloud.google.com/compute-class + operator: Equal + value: Scale-Out ``` +{{% /tab %}} + +{{% tab "Datadog Operator" %}} +```yaml +spec: + override: + nodeAgent: + tolerations: + - effect: NoSchedule + key: cloud.google.com/compute-class + operator: Equal + value: Scale-Out +``` {{% /tab %}} -{{% tab "Operator" %}} +{{< /tabs >}} + -OpenShift에서 Datadog 오퍼레이터를 사용하는 경우, OperatorHub 또는 RedHat Marketplace를 통해 설치하는 것이 좋습니다. -아래 설정은 (SCC/ServiceAccount 설정으로 인해) 이러한 설정에서 작동하도록 되어 있습니다 -에이전트가 Datadog 오퍼레이터와 동일한 네임스페이스에 설치되어 있을 때 작동합니다. +## Red Hat OpenShift {#Openshift} + +OpenShift는 SELinux 및 SecurityContextConstraints(SCC)를 통해 기본적으로 강화된 보안을 제공합니다. 결과적으로 몇 가지 특정 구성이 필요합니다. +- Node Agent 및 Cluster Agent에 대한 높은 SCC 액세스 권한 +- Kubelet API 인증서가 항상 클러스터 CA에 의해 서명되는 것은 아닙니다. +- Node Agent를 `master` 및 `infra` 노드에 예약하려면 Tolerations가 필요합니다. +- 클러스터 이름은 클라우드 공급자에서 자동 검색할 수 없으므로 반드시 설정해야 합니다. +- *(선택 사항)* Node Agent에서 `hostNetwork: true`를 설정하여 Agent가 클라우드 공급자 메타데이터 서비스(IMDS)에 요청을 전송할 수 있도록 하세요. + +이 코어 구성은 OpenShift 3.11 및 OpenShift 4 모두 지원하지만 OpenShift 4에서 가장 잘 작동합니다. + +또한 로그 수집 및 APM에도 약간 다른 요구 사항이 있습니다. + +APM 및 DogStatsD에 Unix Domain Socket(UDS)을 사용하는 것은 OpenShift에서 작동할 수 있습니다. 그러나 Datadog은 Datadog Agent 포드와 애플리케이션 포드 **모두**에 추가 권한 및 SCC 액세스가 필요하므로 이를 권장하지 않습니다. 이러한 권한이 없으면 애플리케이션 포드 배포가 실패할 수 있습니다. Datadog은 이를 방지하기 위해 UDS 옵션을 비활성화하고 Admission Controller가 APM 연결을 위해 적절한 [TCP/IP 설정][7] 또는 [서비스 설정][8]을 주입하도록 할 것을 권장합니다. + +{{< tabs >}} +{{% tab "Datadog Operator" %}} + +OpenShift에서 Datadog Operator를 사용할 때는 OpenShift 클러스터 웹 콘솔의 OperatorHub에서 Operator Lifecycle Manager를 사용하여 Datadog Operator를 배포하는 것이 좋습니다. [Operator 설치 단계][1]를 참조하세요. 아래 구성은 해당 설정과 함께 작동하며, 지정된 ServiceAccount `datadog-agent-scc`에 대해 [SCC 기반의 ClusterRole 및 ClusterRoleBinding 액세스][2]를 생성합니다. 이 `DatadogAgent` 구성은 Datadog Operator와 동일한 네임스페이스에 배포해야 합니다. ```yaml kind: DatadogAgent apiVersion: datadoghq.com/v2alpha1 metadata: name: datadog + namespace: openshift-operators # set as the same namespace where the Datadog Operator was deployed spec: features: logCollection: - enabled: false - liveProcessCollection: - enabled: false - liveContainerCollection: enabled: true + containerCollectAll: true apm: - enabled: false - cspm: - enabled: false - cws: - enabled: false - npm: - enabled: false - admissionController: - enabled: false - externalMetricsServer: - enabled: false - useDatadogMetrics: false - port: 8443 + enabled: true + hostPortConfig: + enabled: true + unixDomainSocketConfig: + enabled: false + dogstatsd: + unixDomainSocketConfig: + enabled: false global: credentials: apiKey: @@ -382,15 +526,19 @@ spec: clusterName: kubelet: tlsVerify: false - criSocketPath: /var/run/crio/crio.sock override: clusterAgent: - image: - name: gcr.io/datadoghq/cluster-agent:latest + serviceAccountName: datadog-agent-scc nodeAgent: serviceAccountName: datadog-agent-scc - image: - name: gcr.io/datadoghq/agent:latest + hostNetwork: true + securityContext: + runAsUser: 0 + seLinuxOptions: + level: s0 + role: system_r + type: spc_t + user: system_u tolerations: - key: node-role.kubernetes.io/master operator: Exists @@ -400,19 +548,16 @@ spec: effect: NoSchedule ``` -{{% /tab %}} -{{< /tabs >}} - -## Rancher {#Rancher} - -Rancher 설치는 바닐라 쿠버네티스에 가깝기 때문에 약간의 설정만 필요합니다: -- `controlplane`와 `etcd` 노드에 있는 노드 에이전트를 예약하려면 허용 오차가 필요합니다. -- 클러스터 이름은 클라우드 제공업체에서 자동으로 검색할 수 없으므로 설정해야 합니다. +**참고**: `nodeAgent.securityContext.seLinuxOptions` 재정의는 Operator로 배포할 때 로그 수집을 위해 필요합니다. 로그 수집이 활성화되지 않은 경우 이 재정의를 생략할 수 있습니다. -{{< tabs >}} +[1]: https://github.com/DataDog/datadog-operator/blob/main/docs/install-openshift.md +[2]: https://docs.openshift.com/container-platform/4.10/authentication/managing-security-context-constraints.html#role-based-access-to-ssc_configuring-internal-oauth +{{% /tab %}} {{% tab "Helm" %}} -커스텀 `values.yaml`: +아래 구성은 Agent 및 Cluster Agent 서비스 계정에 대한 사용자 지정 SCC를 생성합니다. + +사용자 지정 `datadog-values.yaml`: ```yaml datadog: @@ -421,20 +566,41 @@ datadog: clusterName: kubelet: tlsVerify: false + apm: + portEnabled: true + socketEnabled: false agents: + podSecurity: + securityContextConstraints: + create: true + useHostNetwork: true tolerations: - - effect: NoSchedule - key: node-role.kubernetes.io/controlplane - operator: Exists - - effect: NoExecute - key: node-role.kubernetes.io/etcd - operator: Exists + - effect: NoSchedule + key: node-role.kubernetes.io/master + operator: Exists + - effect: NoSchedule + key: node-role.kubernetes.io/infra + operator: Exists +clusterAgent: + podSecurity: + securityContextConstraints: + create: true ``` {{% /tab %}} -{{% tab "Operator" %}} -DatadogAgent 쿠버네티스 리소스: +{{< /tabs >}} + +## Rancher {#Rancher} + +Rancher 설치는 Vanilla Kubernetes 설치와 유사하며, 간단한 설정만 필요합니다. +- Node Agent를 `controlplane` 및 `etcd` 노드에 예약하려면 Tolerations가 필요합니다. +- 클러스터 이름은 클라우드 공급자에서 자동으로 검색할 수 없으므로 반드시 설정해야 합니다. + +{{< tabs >}} +{{% tab "Datadog Operator" %}} + +DatadogAgent Kubernetes 리소스: ```yaml kind: DatadogAgent @@ -472,10 +638,10 @@ spec: override: clusterAgent: image: - name: gcr.io/datadoghq/cluster-agent:latest + name: registry.datadoghq.com/cluster-agent:latest nodeAgent: image: - name: gcr.io/datadoghq/agent:latest + name: registry.datadoghq.com/agent:latest tolerations: - key: node-role.kubernetes.io/controlplane operator: Exists @@ -486,33 +652,50 @@ spec: ``` {{% /tab %}} -{{< /tabs >}} - -## Oracle Container Engine for Kubernetes (OKE) {#OKE} - -특정 설정이 필요하지 않습니다. - -컨테이너 모니터링을 활성화하려면, 다음 (`containerd` 검사)을 추가합니다. - -{{< tabs >}} {{% tab "Helm" %}} -사용자 지정 `values.yaml`: +사용자 지정 `datadog-values.yaml`: ```yaml datadog: apiKey: appKey: - criSocketPath: /run/dockershim.sock - env: - - name: DD_AUTOCONFIG_INCLUDE_FEATURES - value: "containerd" + clusterName: + kubelet: + tlsVerify: false +agents: + tolerations: + - effect: NoSchedule + key: node-role.kubernetes.io/controlplane + operator: Exists + - effect: NoExecute + key: node-role.kubernetes.io/etcd + operator: Exists ``` {{% /tab %}} -{{% tab "Operator" %}} -DatadogAgent 쿠버네티스 리소스: +{{< /tabs >}} + +## Oracle Container Engine for Kubernetes(OKE) {#OKE} + +특정 설정이 필요하지 않습니다. + +## vSphere Kubernetes Service(VKS) {#VKS} + +VKS에서는 Datadog Agent가 배포되는 네임스페이스가 권한 있는 포드 보안 표준을 사용해야 합니다. Datadog Agent를 배포하기 전에 `datadog-agent`를 배포할 네임스페이스로 ``를 바꾸고 다음을 실행하세요. + +```shell +kubectl label --overwrite ns \ + pod-security.kubernetes.io/enforce=privileged +``` + +다음 구성을 사용하여 Kubernetes 이벤트 수집 및 kube-state-metrics 코어를 활성화하고, 자체 서명된 인증서에 대한 Kubelet TLS 확인을 비활성화하며, Agent가 컨트롤 플레인 노드에 예약될 수 있도록 허용 오차를 추가하세요. + +{{< tabs >}} +{{% tab "Datadog Operator" %}} + +DatadogAgent Kubernetes 리소스: ```yaml kind: DatadogAgent @@ -521,40 +704,36 @@ metadata: name: datadog spec: features: - admissionController: - enabled: false - externalMetricsServer: - enabled: false - useDatadogMetrics: false + eventCollection: + collectKubernetesEvents: true + kubeStateMetricsCore: + enabled: true global: + clusterName: credentials: - apiKey: - appKey: - criSocketPath: /run/dockershim.sock + apiSecret: + secretName: datadog-secret + keyName: api-key + appSecret: + secretName: datadog-secret + keyName: app-key + kubelet: + tlsVerify: false override: - clusterAgent: - image: - name: gcr.io/datadoghq/cluster-agent:latest + nodeAgent: + tolerations: + - key: node-role.kubernetes.io/master + effect: NoSchedule ``` {{% /tab %}} -{{< /tabs >}} - -더 많은 `values.yaml` 예제는 [Helm 차트 리포지토리][1]에서 확인할 수 있으며, -더 많은 `DatadogAgent` 예제는 [Datadog 오퍼레이터 리포지토리][2]를 참조하세요. - -## vSphere Tanzu Kubernetes Grid (TKG) {#TKG} - -TKG를 사용하려면 아래와 같이 몇 가지 설정을 변경해야 합니다. 예를 들어, 컨트롤러가 `master` 노드에서 노드 에이전트를 예약하려면 허용 오차를 설정해야 합니다. - - -{{< tabs >}} {{% tab "Helm" %}} -커스텀 `values.yaml`: +사용자 지정 `datadog-values.yaml`: ```yaml datadog: + clusterName: apiKey: appKey: kubelet: @@ -573,9 +752,18 @@ agents: ``` {{% /tab %}} -{{% tab "Operator" %}} -DatadogAgent 쿠버네티스 리소스: +{{< /tabs >}} + +## vSphere Tanzu Kubernetes Grid(TKG) {#TKG} + +TKG는 아래와 같이 약간의 구성 변경이 필요합니다. 예를 들어, 컨트롤러가 `master` 노드에 Node Agent를 예약하려면 허용 오차를 설정해야 합니다. + + +{{< tabs >}} +{{% tab "Datadog Operator" %}} + +DatadogAgent Kubernetes 리소스: ```yaml kind: DatadogAgent @@ -589,6 +777,7 @@ spec: kubeStateMetricsCore: enabled: true global: + clusterName: credentials: apiSecret: secretName: datadog-secret @@ -606,12 +795,47 @@ spec: ``` {{% /tab %}} +{{% tab "Helm" %}} + +사용자 지정 `datadog-values.yaml`: + +```yaml +datadog: + clusterName: + apiKey: + appKey: + kubelet: + # Set tlsVerify to false since the Kubelet certificates are self-signed + tlsVerify: false + # Disable the `kube-state-metrics` dependency chart installation. + kubeStateMetricsEnabled: false + # Enable the new `kubernetes_state_core` check. + kubeStateMetricsCore: + enabled: true +# Add a toleration so that the agent can be scheduled on the control plane nodes. +agents: + tolerations: + - key: node-role.kubernetes.io/master + effect: NoSchedule +``` + +{{% /tab %}} + {{< /tabs >}} {{< partial name="whats-next/whats-next.html" >}} -[1]: https://github.com/DataDog/helm-charts/tree/main/examples/datadog -[2]: https://github.com/DataDog/datadog-operator/tree/main/examples/datadogagent/v2alpha1 -[3]: /ko/containers/cluster_agent/admission_controller -[4]: https://github.com/Azure/AKS/releases/tag/2022-10-30 \ No newline at end of file +[1]: /ko/containers/cluster_agent/admission_controller +[2]: https://github.com/Azure/AKS/releases/tag/2022-10-30 +[3]: https://github.com/DataDog/helm-charts/tree/main/examples/datadog +[4]: https://github.com/DataDog/datadog-operator/tree/main/examples/datadogagent/v2alpha1 +[5]: /ko/getting_started/containers/datadog_operator +[6]: /ko/agent/guide/operator-eks-addon +[7]: /ko/containers/kubernetes/apm/?tab=tcp +[8]: /ko/tracing/guide/setting_up_apm_with_kubernetes_service +[9]: https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/ +[10]: https://cloud.google.com/kubernetes-engine/docs/how-to/autopilot-spot-pods +[11]: https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-compute-classes +[12]: https://cloud.google.com/kubernetes-engine/docs/how-to/disable-kubelet-readonly-port +[13]: https://learn.microsoft.com/en-us/azure/aks/certificate-rotation#kubelet-serving-certificate-rotation \ No newline at end of file diff --git a/hugo/content/ko/containers/monitoring/kubernetes_explorer.md b/hugo/content/ko/containers/monitoring/kubernetes_explorer.md index 26ea08b6552..74cb6368046 100644 --- a/hugo/content/ko/containers/monitoring/kubernetes_explorer.md +++ b/hugo/content/ko/containers/monitoring/kubernetes_explorer.md @@ -29,7 +29,7 @@ Kubernetes Explorer는 대부분의 Datadog Agent 설치에서 **기본적으로 Datadog Operator를 사용하여 Datadog Agent를 설치하면 Kubernetes Explorer가 기본적으로 활성화됩니다. -Kubernetes Explorer가 활성화되어 있는지 확인하려면 `datadog-agent.yaml`에서 `features.orchestratorExplorer.enabled` 매개변수가 `true`로 설정되어 있는지 확인합니다. +Kubernetes Explorer가 활성화되어 있는지 확인하려면 `datadog-agent.yaml`에서 `features.orchestratorExplorer.enabled` 파라미터가 `true`로 설정되어 있는지 확인합니다. ```yaml apiVersion: datadoghq.com/v2alpha1 @@ -52,7 +52,7 @@ spec: [공식 Helm 차트][1]를 사용하여 Datadog Agent를 설치하면 Kubernetes Explorer가 기본적으로 활성화됩니다. -Kubernetes Explorer가 활성화되어 있는지 확인하려면 `datadog-values.yaml` 파일에서 `orchestratorExplorer.enabled` 매개변수가 `true`로 설정되어 있는지 확인합니다. +Kubernetes Explorer가 활성화되어 있는지 확인하려면 `datadog-values.yaml` 파일에서 `orchestratorExplorer.enabled` 파라미터가 `true`로 설정되어 있는지 확인합니다. ```yaml datadog: @@ -79,6 +79,8 @@ datadog: Datadog Agent 대신 네이티브 OpenTelemetry 파이프라인을 사용하여 Kubernetes Explorer를 채울 수 있습니다. 이 설정은 [`k8sobjects`][1] 수신기를 사용하여 Kubernetes 리소스 데이터를 수집하고 [Datadog Exporter][2]의 Orchestrator Explorer 기능을 통해 전달합니다. +{{< site-region region="gov,gov2" >}}
이 기능은 다음에서는 사용할 수 없습니다 {{< region-param key="dd_site_name" >}}.
{{< /site-region >}} + #### 전제 조건 {#prerequisites} - OpenTelemetry Collector Contrib [v0.154.0][3] 이상. @@ -162,17 +164,17 @@ config: ##### 프로세서 및 파이프라인 {#processors-and-pipeline} -클러스터 UID와 이름을 감지하려면 [`resourcedetection`][8] 프로세서를 추가합니다. +클러스터 UID와 이름을 탐지하려면 [`resourcedetection`][8] 프로세서를 추가합니다. -- 클러스터 UID(`k8s.cluster.uid`)를 감지하려면 `k8s_api` 감지기가 필요합니다. -- 클러스터 이름 감지는 클라우드 공급자에 따라 다릅니다. 지원되는 공급자(EKS, AKS, GCP) 및 필요한 권한은 [`resourcedetection` 프로세서 문서][8]를 확인합니다. +- 클러스터 UID(`k8s.cluster.uid`)를 탐지하려면 `k8s_api` 탐지기가 필요합니다. +- 클러스터 이름 탐지는 클라우드 공급자에 따라 다릅니다. 지원되는 공급자(EKS, AKS, GCP) 및 필요한 권한은 [`resourcedetection` 프로세서 문서][8]를 확인합니다. - 공급자가 지원되지 않는 경우 `resource/add-cluster-name` 프로세서를 사용하여 클러스터 이름을 수동으로 설정합니다. `` 항목을 클러스터 이름으로 바꿉니다. 그런 다음 `logs` 파이프라인에서 구성 요소를 연결합니다. 다음 예시는 두 가지 접근 방식을 보여줍니다. EKS, AKS 또는 GCP에서 실행하는 경우 클라우드 공급자 예시를 사용합니다. 공급자가 지원되지 않는 경우 수동 대체를 사용합니다. -**클라우드 공급자 감지(EKS 예시):** +**클라우드 공급자 탐지(EKS 예시):** ```yaml processors: @@ -192,7 +194,7 @@ config: exporters: [datadog] ``` -`eks` 항목을 공급자의 감지기(`aks`, `gcp`)로 바꿉니다. 공급자별 구성은 [`resourcedetection` 프로세서 문서][8]를 참조합니다. +`eks` 항목을 공급자의 탐지기(`aks`, `gcp`)로 바꿉니다. 공급자별 구성은 [`resourcedetection` 프로세서 문서][8]를 참조합니다. **수동 대체:** @@ -231,7 +233,7 @@ helm install deployment-collector open-telemetry/opentelemetry-collector \ #### 4. 설치 확인 {#4-verify-the-installation} -[Kubernetes Explorer][9]를 열고 OpenTelemetry 클러스터 이름으로 필터링합니다. 모든 핵심 Kubernetes 리소스 섹션과 **커스텀 리소스 > CRD**가 채워져야 합니다. **커스텀 리소스 > 리소스** 섹션은 이 설정에서 지원되지 않습니다. +[Kubernetes Explorer][9]를 열고 OpenTelemetry 클러스터 이름으로 필터링합니다. 모든 핵심 Kubernetes 리소스 섹션과 **사용자 지정 리소스 > CRD**가 채워져야 합니다. **사용자 지정 리소스 > 리소스** 섹션은 이 설정에서 지원되지 않습니다. #### 5. Kubernetes Explorer와 로그, 메트릭 및 트레이스 연결(선택 사항) {#5-correlate-logs-metrics-and-traces-with-kubernetes-explorer-optional} @@ -298,11 +300,13 @@ service: Datadog Agent 대신 `opentelemetry-kube-stack` Helm 차트를 사용하여 Kubernetes Explorer를 채울 수 있습니다. -[`opentelemetry-kube-stack`][1] Helm 차트는 OpenTelemetry Operator를 설치하고 수집기를 `OpenTelemetryCollector` 커스텀 리소스(CR)로 관리합니다. Datadog은 두 개의 수집기를 구성하는 참조 [`values.yaml`][2]를 유지 관리합니다. +[`opentelemetry-kube-stack`][1] Helm 차트는 OpenTelemetry Operator를 설치하고 수집기를 `OpenTelemetryCollector` 사용자 지정 리소스(CR)로 관리합니다. Datadog은 두 개의 수집기를 구성하는 참조 [`values.yaml`][2]를 유지 관리합니다. - **`cluster`** (Deployment): kube-state-metrics를 수집하고, Kubernetes 객체를 감시하며, `orchestrator_explorer`를 활성화하여 Kubernetes Explorer를 채웁니다. - **`daemon`** (DaemonSet): 호스트 및 kubelet 메트릭을 수집하고 애플리케이션 텔레메트리 데이터를 위한 OTLP 엔드포인트를 노출합니다. +{{< site-region region="gov,gov2" >}}
이 기능은 다음에서는 사용할 수 없습니다 {{< region-param key="dd_site_name" >}}.
{{< /site-region >}} + #### 전제 조건 {#prerequisites-1} - OpenTelemetry Kube Stack Helm 차트 [0.20.1][3] 이상. @@ -326,7 +330,7 @@ Datadog Agent 대신 `opentelemetry-kube-stack` Helm 차트를 사용하여 Kube ./install ``` -설치 프로그램은 Datadog API 키, [Datadog 사이트][7], Kubernetes 플랫폼 및 배포 환경을 묻습니다. EKS, GKE 및 AKS의 경우 일치하는 리소스 감지 프리셋을 활성화합니다. 다른 플랫폼의 경우 클러스터 이름을 묻습니다. 그런 다음 `opentelemetry-operator-system` 네임스페이스와 `datadog-secret`을 생성하고, 필요한 경우 cert-manager를 설치하며, 차트를 설치하거나 업그레이드합니다. +설치 프로그램은 Datadog API 키, [Datadog 사이트][7], Kubernetes 플랫폼 및 배포 환경을 묻습니다. EKS, GKE 및 AKS의 경우 일치하는 리소스 탐지 프리셋을 활성화합니다. 다른 플랫폼의 경우 클러스터 이름을 묻습니다. 그런 다음 `opentelemetry-operator-system` 네임스페이스와 `datadog-secret`을 생성하고, 필요한 경우 cert-manager를 설치하며, 차트를 설치하거나 업그레이드합니다. #### 값 파일을 사용하여 설치 {#install-with-values-files} @@ -398,7 +402,7 @@ helm upgrade --install opentelemetry-kube-stack \ #### 설치 확인 {#verify-the-installation} -[Kubernetes Explorer][8]를 열고 클러스터 이름으로 필터링합니다. 모든 핵심 Kubernetes 리소스 섹션과 **커스텀 리소스 > CRD**가 채워져야 합니다. **커스텀 리소스 > 리소스** 섹션은 이 설정에서 지원되지 않습니다. +[Kubernetes Explorer][8]를 열고 클러스터 이름으로 필터링합니다. 모든 핵심 Kubernetes 리소스 섹션과 **사용자 지정 리소스 > CRD**가 채워져야 합니다. **사용자 지정 리소스 > 리소스** 섹션은 이 설정에서 지원되지 않습니다. [1]: https://github.com/open-telemetry/opentelemetry-helm-charts/tree/main/charts/opentelemetry-kube-stack [2]: https://github.com/DataDog/opentelemetry-examples/blob/main/guides/kubernetes/configuration/opentelemetry-kube-stack/values.yaml @@ -412,9 +416,9 @@ helm upgrade --install opentelemetry-kube-stack \ {{% /tab %}} {{< /tabs >}} -### 리소스에 커스텀 태그 추가 {#add-custom-tags-to-resources} +### 리소스에 사용자 지정 태그 추가 {#add-custom-tags-to-resources} -필터링을 쉽게 하려면 `DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS` 환경 변수를 통해 Kubernetes 리소스에 커스텀 태그를 추가할 수 있습니다. **이 태그는 Kubernetes Explorer에만 나타납니다.** +필터링을 쉽게 하려면 `DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS` 환경 변수를 통해 Kubernetes 리소스에 사용자 지정 태그를 추가할 수 있습니다. **이 태그는 Kubernetes Explorer에만 나타납니다.** {{< tabs >}} {{% tab "Datadog Operator" %}} @@ -530,7 +534,7 @@ clusterAgent: 사이드 패널의 {{< ui >}}YAML{{< /ui >}} 탭에는 전체 리소스 정의가 표시됩니다. **Agent 버전 7.44.0**부터는 7일간의 정의 기록도 포함됩니다. 시간 경과에 따른 변경 사항 및 서로 다른 버전 간에 무엇이 변경되었는지 비교할 수 있습니다. 표시된 시간은 변경 사항이 리소스에 적용된 대략적인 시간입니다. -관련 없는 변경 사항이 너무 많이 표시되는 것을 방지하기 위해 다음 필드에만 영향을 주는 업데이트는 무시됩니다, +관련 없는 변경 사항이 너무 많이 표시되는 것을 방지하기 위해 다음 필드에만 영향을 주는 업데이트는 무시됩니다. * metadata.resourceVersion * metadata.managedFields @@ -587,7 +591,7 @@ Kubernetes Explorer 탭 내에서 리소스 사용률 메트릭을 선택하여 | **주석**: [리소스 메타데이터][9]에서 추출됩니다. 일반적으로 클러스터 관리를 지원하는 도구를 보조하는 데 사용됩니다. | `annotation#checksum/configmap:a1bc23d4` | | **메트릭**: 워크로드 리소스(포드, 디플로이먼트 등)에 추가됩니다. 사용률을 기준으로 리소스를 찾을 수 있습니다. 지원되는 메트릭을 확인하려면 [리소스 사용률 필터](#resource-utilization-filters)를 참조하세요. | `metric#cpu_usage_pct_limits_avg15:>80%` | | **문자열 일치**: 일부 특정 리소스 속성에서 지원됩니다. 아래를 참조하세요.
_참고: 문자열 일치는 키-값 형식을 사용하지 않으며, 일치시킬 속성을 지정할 수 없습니다._ | `"10.132.6.23"` (IP),
`"9cb4b43f-8dc1-4a0e"` (UID),
`web-api-3` (이름) | -| **필드**: [리소스 메타데이터][10] 또는 커스텀 리소스의 인덱싱된 필드에서 추출됩니다. | `field#metadata.creationTimestamp:>=4wk`, `field#metadata.deletionTimestamp:<=1hr`, `field#status.currentReplicas:3`, `field#status.conditions.Active.status:True` | +| **필드**: [리소스 메타데이터][10] 또는 사용자 지정 리소스의 인덱싱된 필드에서 추출됩니다. | `field#metadata.creationTimestamp:>=4wk`, `field#metadata.deletionTimestamp:<=1hr`, `field#status.currentReplicas:3`, `field#status.conditions.Active.status:True` | > ***참고**: 동일한 키-값 쌍이 태그와 레이블(또는 주석)로 모두 존재할 수 있습니다. 이는 클러스터의 구성 방식에 따라 다릅니다.* @@ -612,7 +616,7 @@ Kubernetes Explorer 탭 내에서 리소스 사용률 메트릭을 선택하여 #### 연산자 {#operators} -여러 용어를 복잡한 쿼리로 결합하려면, 대소문자를 구분하는 다음 부울 연산자를 사용할 수 있습니다. +여러 용어를 복잡한 쿼리로 결합하려면, 대소문자를 구분하는 다음 불리언 연산자를 사용할 수 있습니다. | 연산자 | 설명 | 예시 | |---|---|---| @@ -639,8 +643,8 @@ app_name:(web-server OR database OR event-consumer) `*` 와일드카드를 용어의 일부로 사용하여 값과 키 모두에 대해 부분 일치로 필터링할 수 있습니다. 몇 가지 예: -- `kube_job:stats-*`: `kube_deployment` 항목으로 시작하는 `stats-` 태그 값을 가진 모든 리소스를 찾습니다. -- `pod_name:*canary`: `pod_name` 항목으로 끝나는 `canary` 값을 가진 모든 리소스를 찾습니다. +- `kube_job:stats-*`: `stats-` 항목으로 시작하는 `kube_deployment` 태그 값을 가진 모든 리소스를 찾습니다. +- `pod_name:*canary`: `canary` 항목으로 끝나는 `pod_name` 값을 가진 모든 리소스를 찾습니다. - `label#release:*`: 값에 상관없이 `release` 레이블이 있는 모든 리소스를 찾습니다. - `-label#*.datadoghq.com/*`: Datadog 범위 레이블이 없는 리소스를 찾습니다. - `kube_*:*stats*canary`: 값 중간에 `stats` 항목이 포함되고 `canary` 항목으로 끝나는 관련 리소스 태그(`kube_*`)가 있는 리소스를 찾습니다. @@ -681,7 +685,7 @@ Datadog Agent 내에서 [구성][7]한 태그 외에도, Datadog은 검색 및 관련 리소스는 서로 태그가 지정됩니다. 몇 가지 예: - 'XYZ' 배포의 일부인 포드에는 `kube_deployment:xyz` 태그가 지정됩니다. -- 서비스 'A'를 가리키는 수신에는 `kube_service:a` 태그가 지정됩니다. +- 서비스 'A'를 가리키는 인그레스에는 `kube_service:a` 태그가 지정됩니다. '상위' 리소스에서 생성된 리소스에는 `kube_ownerref_kind` 및 `kube_ownerref_name` 태그(예: 포드 및 작업)가 지정됩니다. @@ -718,7 +722,7 @@ Datadog Agent 내에서 [구성][7]한 태그 외에도, Datadog은 검색 및 | 리소스 | 추출된 태그 | |---|---| | **클러스터** | `api_server_version`
`kubelet_version` | -| **커스텀 리소스 정의** 및
**커스텀 리소스** | `kube_crd_kind`
`kube_crd_group`
`kube_crd_version`
`kube_crd_scope`
`kube_crd_resource` | +| **사용자 지정 리소스 정의** 및
**사용자 지정 리소스** | `kube_crd_kind`
`kube_crd_group`
`kube_crd_version`
`kube_crd_scope`
`kube_crd_resource` | | **네임스페이스** | `phase` | | **노드** | `kube_node_unschedulable`
`kube_node_kubelet_version`
`kube_node_kernel_version`
`kube_node_runtime_version`
`eks_fargate_node`
`node_schedulable`
`node_status` | | **Persistent Volume** | `kube_reclaim_policy`
`kube_storage_class_name`
`pv_type`
`pv_phase` | diff --git a/hugo/content/ko/data_security/cloud_siem.md b/hugo/content/ko/data_security/cloud_siem.md new file mode 100644 index 00000000000..921c50bb6e2 --- /dev/null +++ b/hugo/content/ko/data_security/cloud_siem.md @@ -0,0 +1,60 @@ +--- +disable_toc: false +further_reading: +- link: /data_security/ + tag: 설명서 + text: Datadog에 제출된 주요 데이터 카테고리 검토 +- link: /data_security/pci_compliance/ + tag: 설명서 + text: PCI 준수 Datadog 조직 설정 +title: Cloud SIEM 데이터 보안 +--- +
이 페이지에서는 Datadog으로 전송되는 데이터의 보안을 다룹니다. 클라우드 및 애플리케이션 보안 제품과 기능을 찾고 있다면 보안 섹션을 참조하세요.
+ +## 개요 {#overview} + +Datadog은 탐지 규칙에 정의된 케이스 중 하나 이상이 지정된 기간 동안 일치하면 보안 신호를 생성합니다. 탐지 규칙을 사용자 지정하여 신호에 대한 특정 정보(예: 사용자 ID, IP 주소 등)와 신호의 트리거 그룹화 값이 포함된 알림 메시지를 제공할 수 있습니다. 보안 규칙은 웹훅을 사용하여 타사 서비스에 알림을 전송할 수도 있습니다. + +Datadog으로 전송되는 데이터에는 민감한 정보가 포함될 수 있으므로 이 문서에서는 해당 알림 기능과 사용자가 이러한 기능을 사용할 수 없도록 하려는 경우 취해야 할 조치에 대해 설명합니다. + +## 보안 규칙은 메시지 템플릿 변수를 사용할 수 있음 {#security-rules-can-use-message-template-variables} + +탐지 규칙을 생성할 때 [알림 변수][1]를 사용하여 알림 메시지를 사용자 지정할 수 있으며, 이를 통해 신호와 관련된 특정 정보가 추가됩니다. 예를 들어, 다음 JSON 객체가 보안 신호와 연결된 경우 + +``` +{ + "network": { + "client": { + "ip": "1.2.3.4" + } + }, + "user": { + "id": "user@domain.com" + }, + "used_mfa": "false" +} +``` +알림 메시지에 '{{@network.client.ip}}'를 사용하면 신호와 연결된 IP 주소가 표시됩니다. + +사용자가 알림 메시지에 템플릿 변수를 추가하지 못하게 하려면 [지원팀][2]에 문의하세요. + +## 보안 규칙은 알림 제목에 트리거 그룹화 값을 포함할 수 있음 {#security-rules-can-include-triggering-group-by-values-in-the-notification-title} + +[탐지 규칙][3]의 {{< ui >}}Describe your playbook{{< /ui >}} 섹션에서 알림 제목에 그룹화 값을 추가할 수 있습니다. 예를 들어, `service`별로 그룹화하는 경우 서비스 이름이 제목에 표시됩니다. 제목에 그룹화 값이 표시되지 않게 하려면 {{< ui >}}Include triggering group-by values in notification title{{< /ui >}}을 선택 취소하세요. + +{{< ui >}}Include triggering group-by values in notification title{{< /ui >}} 옵션을 제거하려면 [지원팀][2]에 문의하세요. + +## 보안 규칙은 웹훅을 사용할 수 있음 {#security-rules-can-use-webhooks} + +
2024년 이전에 조직에서 HIPAA를 활성화한 경우, Datadog 지원팀에 문의하여 보안 규칙에 대한 웹훅을 활성화하세요.
+ +보안 알림은 Jira, PagerDuty 및 [웹훅][5]과 같은 [통합][4]으로 전송될 수 있습니다. 사용자가 웹훅을 사용하여 타사 서비스로 알림을 전송하지 못하게 하려면 [지원팀][2]에 문의하세요. + +## 추가 자료 {#further-reading} +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ko/security/notifications/variables/?tab=cloudsiem#template-variables +[2]: /ko/help/ +[3]: /ko/security/cloud_siem/detect_and_monitor/custom_detection_rules/create_rule#describe-your-playbook +[4]: /ko/security/notifications/#integrations +[5]: /ko/integrations/webhooks/ \ No newline at end of file diff --git a/hugo/content/ko/database_monitoring/guide/sql_extended_events.md b/hugo/content/ko/database_monitoring/guide/sql_extended_events.md new file mode 100644 index 00000000000..6ca5b13efcb --- /dev/null +++ b/hugo/content/ko/database_monitoring/guide/sql_extended_events.md @@ -0,0 +1,421 @@ +--- +aliases: +- /ko/database_monitoring/sql_extended_events +further_reading: +- link: /database_monitoring/ + tag: 설명서 + text: Database Monitoring +- link: /database_monitoring/setup_sql_server/ + tag: 설명서 + text: SQL Server 설정하기 +- link: /database_monitoring/guide/parameterized_queries/ + tag: 설명서 + text: 파라미터 값으로 쿼리 캡처 구성하기 +- link: /database_monitoring/troubleshooting/ + tag: 설명서 + text: Database Monitoring 문제 해결하기 +title: SQL Server에서 쿼리 완료 및 쿼리 오류 캡처 구성하기 +--- +이 기능은 XE(확장 이벤트)를 사용하여 SQL Server 인스턴스에서 쿼리 완료 및 쿼리 오류 이벤트를 수집합니다. 다음에 대한 가시성을 제공합니다. +- 파라미터 값이 포함된 SQL 쿼리의 메트릭 및 동작 +- 실행 중에 발생한 오류 및 시간 초과 + +여러 데이터베이스 시스템 전반의 쿼리 파라미터 캡처에 대한 자세한 내용은 [파라미터 값으로 쿼리 캡처 구성하기][1]를 참조하세요. + +[1]: /ko/database_monitoring/guide/parameterized_queries/ + +이 데이터는 다음에 유용합니다. +- 성능 분석 +- 앱 동작 디버깅 +- 예기치 않은 오류 또는 시간 초과 감사 + + +## 시작 전 참고 사항 {#before-you-begin} + +이 가이드를 계속 진행하기 전에 [SQL Server][1] 인스턴스에 대한 Database Monitoring을 구성해야 합니다. + + +지원되는 데이터베이스 +: SQL Server + +지원되는 배포 +: 모든 배포 유형. + +지원되는 Agent 버전 +: 7.67.0+ + +## 설정 {#setup} +{{< tabs >}} +{{% tab "Azure 외 SQL Server" %}} + +1. SQL Server 인스턴스에서 다음 XE(확장 이벤트) 세션을 만듭니다. 이 세션은 인스턴스 내의 모든 데이터베이스에서 만들 수 있습니다. + +`datadog_query_completions` XE 세션은 RPC 호출, SQL 배치 및 저장 프로시저에서 장기 실행 SQL 쿼리(1초 초과)를 캡처합니다. + +```sql +-- Query completions: RPC, batch, and stored procedure events +IF EXISTS ( + SELECT * FROM sys.server_event_sessions WHERE name = 'datadog_query_completions' +) + DROP EVENT SESSION datadog_query_completions ON SERVER; +GO + +CREATE EVENT SESSION datadog_query_completions ON SERVER -- datadog requires this exact session name +ADD EVENT sqlserver.rpc_completed ( -- capture remote procedure call completions + ACTION ( -- datadog requires these exact actions for rpc_completed + sqlserver.sql_text, + sqlserver.database_name, + sqlserver.username, + sqlserver.client_app_name, + sqlserver.client_hostname, + sqlserver.session_id, + sqlserver.request_id + ) + WHERE ( + sql_text <> '' AND + duration > 1000000 -- in microseconds, limit to queries with duration greater than 1 second + ) +), +ADD EVENT sqlserver.sql_batch_completed( -- capture batch completions + ACTION ( -- datadog requires these exact actions for sql_batch_completed + sqlserver.sql_text, + sqlserver.database_name, + sqlserver.username, + sqlserver.client_app_name, + sqlserver.client_hostname, + sqlserver.session_id, + sqlserver.request_id + ) + WHERE ( + sql_text <> '' AND + duration > 1000000 -- in microseconds, limit to queries with duration greater than 1 second + ) +), +ADD EVENT sqlserver.module_end( -- capture stored procedure completions + SET collect_statement = (1) + ACTION ( -- datadog requires these exact actions for module_end + sqlserver.sql_text, + sqlserver.database_name, + sqlserver.username, + sqlserver.client_app_name, + sqlserver.client_hostname, + sqlserver.session_id, + sqlserver.request_id + ) + WHERE ( + sql_text <> '' AND + duration > 1000000 -- in microseconds, limit to queries with duration greater than 1 second + ) +) +ADD TARGET package0.ring_buffer -- do not change, datadog is only configured to read from ring buffer at this time +( + SET MAX_MEMORY = 1024 +) +WITH ( + MAX_MEMORY = 1024 KB, -- do not exceed 1024, values above 1 MB may result in data loss due to SQLServer internals + TRACK_CAUSALITY = ON, -- allows datadog to correlate related events across activity ID + EVENT_RETENTION_MODE = ALLOW_SINGLE_EVENT_LOSS, + MAX_DISPATCH_LATENCY = 30 SECONDS, + MEMORY_PARTITION_MODE = PER_NODE, -- improves performance on multi-core systems (not supported on RDS) + STARTUP_STATE = ON +); + +ALTER EVENT SESSION datadog_query_completions ON SERVER STATE = START; +GO +``` + +datadog_query_errors XE 세션은 [심각도 ≥ 11][1]인 SQL 오류와 쿼리 시간 초과([대응 필요 이벤트][2]라고도 함)를 캡처하여 Datadog이 쿼리 실패 및 시간 초과를 보고할 수 있도록 합니다. + +```sql +-- Errors and timeouts: SQL errors and attention events +IF EXISTS ( + SELECT * FROM sys.server_event_sessions WHERE name = 'datadog_query_errors' +) + DROP EVENT SESSION datadog_query_errors ON SERVER; +GO +CREATE EVENT SESSION datadog_query_errors ON SERVER +ADD EVENT sqlserver.error_reported( + ACTION( -- datadog requires these exact actions for error_reported + sqlserver.sql_text, + sqlserver.database_name, + sqlserver.username, + sqlserver.client_app_name, + sqlserver.client_hostname, + sqlserver.session_id, + sqlserver.request_id + ) + WHERE severity >= 11 +), +ADD EVENT sqlserver.attention( + ACTION( -- datadog requires these exact actions for attention + sqlserver.sql_text, + sqlserver.database_name, + sqlserver.username, + sqlserver.client_app_name, + sqlserver.client_hostname, + sqlserver.session_id, + sqlserver.request_id + ) +) +ADD TARGET package0.ring_buffer -- do not change, datadog is only configured to read from ring buffer at this time +( + SET MAX_MEMORY = 1024 +) +WITH ( + MAX_MEMORY = 1024 KB, -- do not change, setting this larger than 1 MB may result in data loss due to SQLServer internals + EVENT_RETENTION_MODE = ALLOW_SINGLE_EVENT_LOSS, + MAX_DISPATCH_LATENCY = 30 SECONDS, + MEMORY_PARTITION_MODE = PER_NODE, -- improves performance on multi-core systems (not supported on RDS) + STARTUP_STATE = ON +); + +ALTER EVENT SESSION datadog_query_errors ON SERVER STATE = START; +GO +``` + + **참고**: Amazon RDS for SQL Server를 사용하는 경우, 이 옵션은 RDS 인스턴스에서 지원되지 않으므로 두 세션 구성에서 `MEMORY_PARTITION_MODE = PER_NODE` 라인을 제거하세요. + +2. Datadog Agent 구성에서 `sqlserver.d/conf.yaml`의 `collect_xe`를 활성화합니다. +사용 가능한 모든 구성 옵션은 [샘플 conf.yaml.example][3]을 참조하세요. + +```yaml + collect_xe: + query_completions: + enabled: true + query_errors: + enabled: true +``` +파라미터 값이 포함된 쿼리문을 수집하려면 `sqlserver.d/conf.yaml`의 `collect_raw_query_statement`를 활성화하세요. 파라미터 캡처에 대한 자세한 내용은 [파라미터 값으로 쿼리 캡처 구성하기][1]를 참조하세요. + +```yaml + collect_raw_query_statement: + enabled: true +``` + +
원시 쿼리문에는 민감한 정보(예: 쿼리 텍스트의 비밀번호)나 개인 식별 정보가 포함될 수 있습니다. 이 옵션을 활성화하면 Datadog이 쿼리 샘플에 나타나는 원시 쿼리문을 수집할 수 있습니다. 이 옵션은 기본적으로 비활성화되어 있습니다.
+ +[1]: https://learn.microsoft.com/en-us/sql/relational-databases/errors-events/database-engine-error-severities +[2]: https://learn.microsoft.com/en-us/sql/relational-databases/event-classes/attention-event-class +[3]: https://github.com/DataDog/integrations-core/blob/master/sqlserver/datadog_checks/sqlserver/data/conf.yaml.example +{{% /tab %}} + +{{% tab "Azure DB" %}} + +1. Azure SQL Server Database에서 다음의 XE(확장 이벤트) 세션을 만듭니다. + +`datadog_query_completions` XE 세션은 RPC 호출, SQL 배치 및 저장 프로시저에서 장기 실행 SQL 쿼리(1초 초과)를 캡처합니다. + +```sql +-- Query completions: RPC, batch, and stored procedure events +IF EXISTS ( + SELECT * FROM sys.database_event_sessions WHERE name = 'datadog_query_completions' +) + DROP EVENT SESSION datadog_query_completions ON DATABASE; +GO + +CREATE EVENT SESSION datadog_query_completions ON DATABASE -- datadog requires this exact session name +ADD EVENT sqlserver.rpc_completed ( -- capture remote procedure call completions + ACTION ( -- datadog requires these exact actions for rpc_completed + sqlserver.sql_text, + sqlserver.database_name, + sqlserver.username, + sqlserver.client_app_name, + sqlserver.client_hostname, + sqlserver.session_id, + sqlserver.request_id + ) + WHERE ( + sql_text <> '' AND + duration > 1000000 -- in microseconds, limit to queries with duration greater than 1 second + ) +), +ADD EVENT sqlserver.sql_batch_completed( -- capture batch completions + ACTION ( -- datadog requires these exact actions for sql_batch_completed + sqlserver.sql_text, + sqlserver.database_name, + sqlserver.username, + sqlserver.client_app_name, + sqlserver.client_hostname, + sqlserver.session_id, + sqlserver.request_id + ) + WHERE ( + sql_text <> '' AND + duration > 1000000 -- in microseconds, limit to queries with duration greater than 1 second + ) +), +ADD EVENT sqlserver.module_end( -- capture stored procedure completions + SET collect_statement = (1) + ACTION ( -- datadog requires these exact actions for module_end + sqlserver.sql_text, + sqlserver.database_name, + sqlserver.username, + sqlserver.client_app_name, + sqlserver.client_hostname, + sqlserver.session_id, + sqlserver.request_id + ) + WHERE ( + sql_text <> '' AND + duration > 1000000 -- in microseconds, limit to queries with duration greater than 1 second + ) +) +ADD TARGET package0.ring_buffer -- do not change, datadog is only configured to read from ring buffer at this time +( + SET MAX_MEMORY = 1024 +) +WITH ( + MAX_MEMORY = 1024 KB, -- do not exceed 1024, values above 1 MB may result in data loss due to SQLServer internals + TRACK_CAUSALITY = ON, -- allows datadog to correlate related events across activity ID + EVENT_RETENTION_MODE = ALLOW_SINGLE_EVENT_LOSS, + MAX_DISPATCH_LATENCY = 30 SECONDS, + MEMORY_PARTITION_MODE = PER_NODE, -- improves performance on multi-core systems + STARTUP_STATE = ON +); + +ALTER EVENT SESSION datadog_query_completions ON DATABASE STATE = START; +GO +``` + +datadog_query_errors XE 세션은 [심각도 ≥ 11][1]인 SQL 오류와 쿼리 시간 초과([대응 필요 이벤트][2]라고도 함)를 캡처하여 Datadog이 쿼리 실패 및 시간 초과를 보고할 수 있도록 합니다. + +```sql +-- Errors and timeouts: SQL errors and attention events +IF EXISTS ( + SELECT * FROM sys.database_event_sessions WHERE name = 'datadog_query_errors' +) + DROP EVENT SESSION datadog_query_errors ON DATABASE; +GO +CREATE EVENT SESSION datadog_query_errors ON DATABASE +ADD EVENT sqlserver.error_reported( + ACTION( -- datadog requires these exact actions for error_reported + sqlserver.sql_text, + sqlserver.database_name, + sqlserver.username, + sqlserver.client_app_name, + sqlserver.client_hostname, + sqlserver.session_id, + sqlserver.request_id + ) + WHERE severity >= 11 +), +ADD EVENT sqlserver.attention( + ACTION( -- datadog requires these exact actions for attention + sqlserver.sql_text, + sqlserver.database_name, + sqlserver.username, + sqlserver.client_app_name, + sqlserver.client_hostname, + sqlserver.session_id, + sqlserver.request_id + ) +) +ADD TARGET package0.ring_buffer -- do not change, datadog is only configured to read from ring buffer at this time +( + SET MAX_MEMORY = 1024 +) +WITH ( + MAX_MEMORY = 1024 KB, -- do not change, setting this larger than 1 MB may result in data loss due to SQLServer internals + EVENT_RETENTION_MODE = ALLOW_SINGLE_EVENT_LOSS, + MAX_DISPATCH_LATENCY = 30 SECONDS, + MEMORY_PARTITION_MODE = PER_NODE, -- improves performance on multi-core systems + STARTUP_STATE = ON +); + +ALTER EVENT SESSION datadog_query_errors ON DATABASE STATE = START; +GO +``` + +2. Datadog Agent 구성에서 `sqlserver.d/conf.yaml`의 `collect_xe`를 활성화합니다. +사용 가능한 모든 구성 옵션은 [샘플 conf.yaml.example][3]을 참조하세요. + +```yaml + collect_xe: + query_completions: + enabled: true + query_errors: + enabled: true +``` +파라미터 값이 포함된 쿼리문을 수집하려면 `sqlserver.d/conf.yaml`의 `collect_raw_query_statement`를 활성화하세요. 파라미터 캡처에 대한 자세한 내용은 [파라미터 값으로 쿼리 캡처 구성하기][1]를 참조하세요. + +```yaml + collect_raw_query_statement: + enabled: true +``` + +
원시 쿼리문 및 실행 계획에는 민감한 정보(예: 쿼리 텍스트의 비밀번호)나 개인 식별 정보가 포함될 수 있습니다. 이 옵션을 활성화하면 Datadog이 쿼리 샘플 또는 실행 계획에 나타나는 원시 쿼리문 및 실행 계획을 수집할 수 있습니다. 이 옵션은 기본적으로 비활성화되어 있습니다.
+ +[1]: https://learn.microsoft.com/en-us/sql/relational-databases/errors-events/database-engine-error-severities +[2]: https://learn.microsoft.com/en-us/sql/relational-databases/event-classes/attention-event-class +[3]: https://github.com/DataDog/integrations-core/blob/master/sqlserver/datadog_checks/sqlserver/data/conf.yaml.example + +{{% /tab %}} + +{{< /tabs >}} + +## 환경에 맞게 확장 이벤트 조정하기(선택 사항) {#tuning-extended-events-for-your-environment-optional} + +특정 요구 사항에 더욱 부합하도록 확장 이벤트 세션을 사용자 지정할 수 있습니다. + +### 쿼리 기간 임계값 {#query-duration-threshold} +기본 쿼리 기간 임계값은 `duration > 1000000`(1초)입니다. 이 값을 조정하여 캡처되는 쿼리 수를 제어하세요. + +- **더 많은 쿼리 캡처**: 임계값을 낮추세요(예: 500ms의 경우 `duration > 500000`) +- **더 적은 쿼리 캡처**: 임계값을 높이세요(예: 5초의 경우 `duration > 5000000`) +
임계값을 너무 낮게 설정하면 Datadog이 수집 간격당 가장 최근 이벤트 1,000개만 수집하므로 서버 성능에 영향을 미치는 과도한 이벤트 수집, 버퍼 오버플로로 인한 이벤트 손실, 불완전한 데이터 문제가 발생할 수 있습니다.
+ +### 메모리 할당 {#memory-allocation} +- 기본값은 `MAX_MEMORY = 1024 KB`입니다. +- 더 높은 값은 [SQL Server 내부 제한][3]으로 인해 데이터 손실이 발생할 수 있으므로 1024KB를 초과하지 마세요. +- 대용량 서버의 경우 최대값인 1024KB로 유지하는 것이 좋습니다. +- 트래픽이 적은 서버의 경우 512KB 설정이 충분할 수 있습니다. + +### 이벤트 필터링 {#event-filtering} + +이벤트 볼륨을 줄이려면 `WHERE` 절에 필터를 추가할 수 있습니다. 예를 들면 다음과 같습니다. + + ```sql + WHERE ( + sql_text <> '' AND + duration > 1000000 AND + -- Add custom filters here + database_name = 'YourImportantDB' AND -- Only track specific databases + username <> 'datadog' -- Exclude Datadog Agent queries or specific users + ) + ``` + +### 성능 고려 사항 {#performance-considerations} + +확장 이벤트는 경량으로 설계되었지만 약간의 오버헤드가 발생할 수 있습니다. 성능 문제를 확인하는 경우 다음 작업을 고려하세요. + +- [쿼리 기간 임계값 증가](#query-duration-threshold)를 통해 캡처되는 쿼리를 제한합니다. +- [더 구체적인 필터 추가](#event-filtering)를 통해 이벤트 볼륨을 줄입니다. +- 다음 명령을 실행하여 부하가 많은 기간에 하나 이상의 세션을 비활성화하세요. + +```sql +IF EXISTS ( + SELECT * FROM sys.server_event_sessions WHERE name = 'datadog_query_completions' +) + DROP EVENT SESSION datadog_query_completions ON SERVER; +GO +IF EXISTS ( + SELECT * FROM sys.server_event_sessions WHERE name = 'datadog_query_errors' +) + DROP EVENT SESSION datadog_query_errors ON SERVER; +GO +``` + +### Azure 관련 고려 사항 {#azure-specific-considerations} + +Azure SQL Database 환경은 일반적으로 리소스가 더욱 제한적입니다. 성능 영향을 최소화하려면 다음을 수행하세요. + +- [더 제한적인 필터를 사용](#event-filtering)합니다(하위 계층 서비스 수준을 사용하는 경우). +- 탄력적 풀을 사용하는 경우 모든 데이터베이스에 걸친 성능 영향을 모니터링해야 합니다. + +## 추가 자료 {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ko/database_monitoring/setup_sql_server/ +[2]: https://github.com/DataDog/integrations-core/blob/master/sqlserver/datadog_checks/sqlserver/data/conf.yaml.example +[3]: https://techcommunity.microsoft.com/blog/sqlserversupport/you-may-not-see-the-data-you-expect-in-extended-event-ring-buffer-targets8230-/315838 \ No newline at end of file diff --git a/hugo/content/ko/delivery_performance/dora_metrics/_index.md b/hugo/content/ko/delivery_performance/dora_metrics/_index.md new file mode 100644 index 00000000000..7f202212c33 --- /dev/null +++ b/hugo/content/ko/delivery_performance/dora_metrics/_index.md @@ -0,0 +1,104 @@ +--- +aliases: +- /ko/continuous_integration/dora_metrics +- /ko/dora_metrics/ +description: DORA Metrics를 사용하여 조직의 Software Delivery 프로세스를 측정하고 개선하는 방법을 알아보세요. +further_reading: +- link: /delivery_performance/dora_metrics/calculation/ + tag: 설명서 + text: Datadog이 DORA Metrics를 계산하는 방법 알아보기 +- link: /continuous_delivery/deployments + tag: 설명서 + text: Deployment Visibility에 대해 알아보기 +- link: /events + tag: 설명서 + text: Event Management에 대해 알아보기 +- link: /monitors/types/metric + tag: 설명서 + text: Metric Monitors에 대해 알아보기 +- link: /catalog + tag: 설명서 + text: Catalog에 대해 알아보기 +- link: https://www.datadoghq.com/blog/platform-engineering-metrics/ + tag: 블로그 + text: 플랫폼 엔지니어링 팀을 위한 성공 메트릭 +- link: https://www.datadoghq.com/blog/dora-metrics-software-delivery/ + tag: 블로그 + text: DORA Metrics를 사용하여 소프트웨어 제공을 개선하기 위한 모범 사례 +- link: https://www.datadoghq.com/blog/datadog-dora-metrics/ + tag: 블로그 + text: Datadog DORA Metrics로 소프트웨어 제공 성공을 이끄는 3가지 방법 +- link: https://www.datadoghq.com/blog/devsecops-2026-study-learnings + tag: 블로그 + text: 2026 State of DevSecOps 연구에서 얻은 주요 인사이트 +- link: https://app.datadoghq.com/release-notes?category=Software%20Delivery + tag: 릴리스 노트 + text: 최신 Software Delivery 릴리스를 확인하세요! (앱 로그인 필요) +is_beta: true +title: DORA Metrics +--- +## 개요 {#overview} + +DevOps Research and Assessment(DORA) Metrics는 소프트웨어 개발의 속도와 안정성을 나타내는 [4가지 핵심 메트릭][1]입니다. + +배포 빈도 +: 조직이 프로덕션 환경에 성공적으로 릴리스하는 빈도입니다. + +변경 리드 타임 +: 커밋이 프로덕션 환경에 반영되기까지 걸리는 시간입니다. + +변경 실패율 +: 실패하여 즉각적인 개입이 필요한 배포의 비율입니다. + +배포 실패 복구 시간 +: 실패하여 즉각적인 개입이 필요한 배포로부터 복구하는 데 걸리는 시간입니다. + +DORA Metrics를 정의하고 추적하면 팀이나 조직의 소프트웨어 제공 속도 및 품질을 개선할 영역을 파악하는 데 도움이 됩니다. + +## DORA Metrics 설정 {#set-up-dora-metrics} + +Datadog으로 배포 이벤트를 전송하기 위한 데이터 소스 구성을 시작하려면 [설정 문서][2]를 참조하세요. + +## DORA Metrics 분석 {#analyze-dora-metrics} + +배포 이벤트에 대한 데이터 소스를 설정한 후 [{{< ui >}}Software Delivery{{< /ui >}} > {{< ui >}}Delivery Performance{{< /ui >}} > {{< ui >}}DORA Metrics{{< /ui >}}][4]로 이동하여 각 메트릭의 개선 사항이나 회귀를 확인하세요. 또한 팀, 서비스, 리포지토리, 환경, 기간 및 [사용자 지정 태그][8]별로 메트릭을 집계하여 시간 경과에 따른 추세를 비교할 수 있습니다. + +{{< img src="delivery_performance/dora_metrics/dora_ui_3.png" alt="Language 사용자 지정 태그로 필터링된 DORA Metrics 계산 개요" style="width:100%;" >}} + +{{< ui >}}View Deployments{{< /ui >}}를 클릭하여 배포 이벤트 목록이 포함된 새 탭을 여세요. + +{{< img src="delivery_performance/dora_metrics/deployments_list.png" alt="메트릭 분석과 관련 이벤트 목록을 보여주는 배포 분석" style="width:100%;" >}} + +{{< ui >}}View Change Failures{{< /ui >}}를 클릭하여 변경 실패로 표시된 배포 이벤트 목록이 포함된 측면 패널을 여세요. + +{{< img src="delivery_performance/dora_metrics/change_failures_list.png" alt="메트릭 분석과 관련 이벤트 목록을 보여주는 변경 실패 분석" style="width:100%;" >}} + +## DORA Metrics 데이터 사용 {#use-dora-metrics-data} + +### DORA Metrics 위젯 내보내기 {#export-dora-metrics-widgets} +시각화 위젯을 대시보드나 노트북으로 내보내세요. + +시각화에서 {{< ui >}}Export{{< /ui >}} 아이콘을 클릭하여 대시보드나 노트북에 추가하세요. DORA Metrics에서 계산하는 메트릭에 대한 자세한 내용은 [수집된 데이터 문서][3]를 참조하세요. + +### 사용자 지정 대시보드 생성{#create-custom-dashboards} + +DORA Metrics를 사용하여 사용자 지정 대시보드를 구축하고 커밋 및 풀 리퀘스트부터 프로덕션 배포까지의 전체 워크플로를 분석하세요. 예를 들어, 팀 간의 코드 검토 성과를 비교하여 승인 지연으로 인해 차질이 발생한 팀을 파악하고 워크플로 개선에 투자할 우선순위를 정하세요. + +{{< img src="delivery_performance/dora_metrics/dashboard.png" alt="사용자 지정 DORA Metrics Dashboard 예시" style="width:100%;" >}} + +대시보드와 그래프 내에서 사용자 지정 태그는 [속성][7]으로 처리됩니다. 사용자 지정 태그로 필터링하거나 그룹화하려면 태그 앞에 `@` 기호를 붙여야 합니다. + +{{< img src="delivery_performance/dora_metrics/graph_with_custom_tag.png" alt="태그별로 그룹화된 사용자 지정 DORA Metrics 그래프의 예시" style="width:100%;" >}} + +## 추가 자료 {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://www.datadoghq.com/knowledge-center/dora-metrics/ +[2]: /ko/delivery_performance/dora_metrics/setup/ +[3]: /ko/delivery_performance/dora_metrics/data_collected/ +[4]: https://app.datadoghq.com/ci/dora +[5]: /ko/monitors/types/metric/?tab=threshold +[6]: /ko/monitors/ +[7]: /ko/dashboards/guide/quick-graphs/#graphing-events +[8]: /ko/delivery_performance/dora_metrics/data_collected/#custom-tags \ No newline at end of file diff --git a/hugo/content/ko/delivery_performance/dora_metrics/change_failure_detection/_index.md b/hugo/content/ko/delivery_performance/dora_metrics/change_failure_detection/_index.md new file mode 100644 index 00000000000..8405057226f --- /dev/null +++ b/hugo/content/ko/delivery_performance/dora_metrics/change_failure_detection/_index.md @@ -0,0 +1,194 @@ +--- +aliases: +- /ko/dora_metrics/change_failure_detection/ +description: 롤백, 되돌리기 PR, 사용자 지정 PR 필터를 사용하여 DORA Metrics에서 변경 실패 탐지를 구성하는 방법을 알아보세요. +further_reading: +- link: /delivery_performance/dora_metrics/ + tag: 설명서 + text: DORA Metrics에 대해 알아보기 +- link: /delivery_performance/dora_metrics/setup/ + tag: 설명서 + text: DORA Metrics용 데이터 소스 설정 +title: 변경 실패 탐지 +--- +{{< jqmath-vanilla >}} + +## 개요 {#overview} + +Datadog 변경 실패 탐지 기능은 이전에 실패한 배포를 수정하는 배포를 자동으로 식별합니다. 이 기능은 변경 실패를 수정 배포에 연결하여 제공 성능에 대한 완전한 보기를 제공함으로써 팀이 릴리스 속도와 운영 안정성 사이의 균형을 유지하도록 돕습니다. + +**변경 실패**는 프로덕션에서 문제를 발생시켜 수정 작업이 필요하게 만드는 배포입니다. 변경 실패는 다음 메트릭을 계산하는 데 사용됩니다. + +- [변경 실패율][2] +: 프로덕션에서 문제를 발생시키는 배포의 비율로, 다음과 같이 계산합니다. + + $$\text"변경 실패율" = \text"변경 실패 횟수" / \text"총 배포 횟수"$$ + +- [실패한 배포 복구 시간][3] +: 실패한 배포와 롤백 또는 롤포워드 배포를 통한 해당 배포의 수정 사이에 지난 중앙값 기간입니다. + +변경 실패 탐지 기능은 다음과 같은 두 가지 유형의 수정 배포를 식별합니다. +- **롤백**: 이전에 배포된 버전이 다시 배포되면 자동으로 탐지됩니다. +- **롤포워드**: 메타데이터 패턴(예: 되돌리기 PR 및 핫픽스 레이블)과 일치하는 사용자 지정 규칙을 통해 탐지됩니다. + + +## 롤백 {#rollbacks} + +롤백은 실패했거나 잘못된 변경 후 시스템을 복원하기 위해 이전에 배포된 버전이 다시 배포될 때 발생합니다. + +### 롤백 분류 작동 방식 {#how-rollback-classification-works} + +배포는 이전에 배포된 버전과 일치하지만 바로 이전 배포와는 다른 버전을 배포할 때 롤백으로 분류됩니다. + +- Git 메타데이터가 있는 경우, 커밋 SHA를 기준으로 일치 여부를 확인합니다. +- Git 메타데이터가 없는 경우, 버전 태그를 기준으로 일치 여부를 확인합니다. + +롤백이 탐지되면 변경 실패가 롤백 대상(되돌아간 버전) 이후의 첫 번째 배포입니다. + +### 예시: 롤백 탐지 {#example-rollback-detection} + +V1 → V2 → V3 → V1 시퀀스의 경우, 롤백 대상은 원본 V1이므로 V2가 변경 실패로, V1은 롤백 배포로 표시됩니다. + +{{< img src="delivery_performance/dora_metrics/rollback_example.png" alt="탐지된 롤백 배포의 예시" style="width:100%;" >}} + +**참고**: 동일한 버전을 연속으로 다시 배포하는 것(예: V1 → V1)은 롤백으로 간주되지 않습니다. + +## 롤포워드 {#rollforwards} + +롤포워드는 실패했거나 잘못된 변경을 수정하거나 재정의하기 위해 새로운 배포가 진행될 때 발생합니다. 이전 버전을 다시 배포하는 롤백과 달리, 롤포워드는 문제를 수정하기 위해 새 코드를 배포합니다. 여기에는 새 릴리스를 통해 이전 동작을 복원하는 풀 요청 되돌리기가 포함될 수 있습니다. + +롤포워드는 배포 메타데이터 패턴과 일치하는 사용자 지정 규칙을 통해 탐지됩니다. 사용자 지정 규칙은 [DORA Settings 페이지][1]에서 구성됩니다. + +## 사용자 지정 규칙 {#custom-rules} + +리포지토리 또는 릴리스 메타데이터를 기반으로 롤포워드 배포를 자동으로 분류하도록 사용자 지정 규칙을 정의할 수 있습니다. 규칙은 다음과 같은 두 가지 방식으로 작동할 수 있습니다. +- **배포 연결**: 공유된 변수 값(예: PR 번호 또는 버전)을 통해 배포 일치 여부를 확인합니다. +- **정적 패턴**: 변수 없이 메타데이터 패턴(예: 레이블 또는 브랜치 이름) 일치 여부를 확인합니다. + +### 실패한 배포에 연결된 규칙 {#rules-linked-to-failed-deployments} + +이 규칙을 사용하여 이전에 실패한 특정 배포에 연결되어야 하는 롤포워드 배포를 식별하세요. 이 규칙은 공유된 참조를 통해 배포 일치 여부를 확인하기 위해 변수가 포함된 정규 표현식(정규식) 패턴을 사용합니다. + +다음 변수 중 하나를 포함하는 정규식 규칙을 입력할 수 있습니다. +| 변수 | 설명 | +|---------------|-----------------------| +| `$pr_title` | PR 제목 일치 여부를 확인합니다. | +| `$pr_number` | PR 번호 일치 여부를 확인합니다. | +| `$version` | 버전 태그 일치 여부를 확인합니다. | + +#### 변수 기반 분류의 작동 방식 {#how-variable-based-classification-works} + +규칙이 배포와 일치하면 다음 액션이 발생합니다. +1. 현재 배포에서 변수 값이 추출됩니다. +2. 시스템이 동일한 추출된 값을 가진 이전 배포를 찾습니다. +3. 현재 배포가 해당 이전 배포에 연결된 롤포워드로 표시됩니다. +4. 이전 배포가 변경 실패로 표시됩니다. + +이 규칙은 실패한 배포를 공유된 커밋 SHA, 버전 태그 또는 PR 참조로 식별할 수 있을 때 가장 잘 작동합니다. + +#### 예시: 풀 요청 되돌리기 {#example-revert-pull-requests} + +풀 요청 되돌리기는 일반적인 복구 패턴입니다. 예를 들어, `Revert "Add feature X"`라는 제목의 PR은 원본 PR을 참조합니다. + +``` +Revert "$pr_title" +``` + +PR 제목이 이 패턴과 일치하면 다음 액션이 발생합니다. +1. 시스템이 되돌리기 PR에서 원본 PR 제목(`$pr_title`의 값)을 추출합니다. +2. 시스템이 해당 원본 PR 제목을 포함하는 이전 배포를 찾습니다. +3. 되돌리기를 포함하는 현재 배포가 롤포워드로 표시됩니다. +4. 이전 배포가 변경 실패로 표시됩니다. + +**참고**: 원본 PR이 이전 배포에서 발견되지 않거나 원본 PR과 해당 되돌리기가 모두 동일한 배포에 있는 경우 분류가 적용되지 않습니다. + +### 정적 규칙 {#static-rules} + +정적 규칙은 변수를 사용하지 않고 메타데이터 패턴을 기반으로 롤포워드 배포를 분류합니다. 이 규칙은 광범위한 수정 지표와의 일치 여부를 확인합니다. + +특정 유형의 메타데이터와 일치하는 정규식 규칙을 정의할 수 있습니다. 다음 표에서는 사용할 수 있는 몇 가지 예시 패턴을 보여주지만 프로세스에 맞게 조정할 수 있습니다. + +| 메타데이터 유형 | 예시 정규식 패턴 | 설명 | +|------------------|------------------------|-------------------------------------| +| **PR 제목** | `.*rollforward.*` | `rollforward` |를 포함하는 PR 제목과의 일치 여부를 확인합니다. +| **PR 레이블** | `.*hotfix.*` | `hotfix` |를 포함하는 PR 레이블과의 일치 여부를 확인합니다. +| **PR 브랜치 이름** | `recovery/.*` | `recovery/`|로 시작하는 브랜치 이름과의 일치 여부를 확인합니다. +| **커밋 메시지** | `^Revert ".*"$ ` | `Revert`로 시작하고 `"`|로 끝나는 커밋 메시지와의 일치 여부를 확인합니다. +| **버전 태그** | `.*_hotfix` | `_hotfix` |로 끝나는 버전 태그와의 일치 여부를 확인합니다. + +#### 정적 규칙 분류의 작동 방식 {#how-static-rule-classification-works} + +정적 규칙이 배포와 일치하면 다음 액션이 발생합니다. +1. 현재 배포가 롤포워드로 표시됩니다. +2. 바로 이전 배포가 변경 실패로 표시됩니다. + +핫픽스 레이블, 브랜치 접두사 또는 버전 태그 규칙과 같은 광범위한 수정 지표에 정적 규칙을 사용하세요. + + +### 기본 규칙 {#default-rules} + +Datadog은 자동으로 활성화되는 기본 규칙을 제공합니다. + +- **되돌리기 PR**: 되돌리기 명명 규칙(예: 이전 PR을 참조하는 'Revert')을 따르는 PR 제목은 롤포워드로 처리됩니다. 원본 변경이 포함된 이전 배포는 위에 설명된 변수 기반 연결 규칙을 사용하여 변경 실패로 표시됩니다. +- **핫픽스 지표**: 'hotfix'가 포함된 PR 레이블, 제목 또는 브랜치 이름은 롤포워드로 처리되며, 이전 배포는 변경 실패로 표시됩니다. + +이 기본 규칙은 [DORA Metrics 설정][1] 페이지에서 완전히 구성할 수 있습니다. 이 규칙은 일반적인 신호가 롤포워드 활동일 가능성이 높은 것으로 해석하는 의견형 시작점으로 의도되었습니다. 필요에 따라 패턴(예: 명명 규칙, 레이블 또는 버전 태그)을 조정하여 자체 워크플로를 반영하고 시간이 지나면서 정확도를 높여야 합니다. + +## 배포 상태 업데이트 {#update-deployment-status} + +자동 탐지 및 사용자 지정 규칙을 통해 대부분의 사례가 처리되지만 여전히 배포 상태를 수동으로 업데이트하여 변경 실패로 표시하거나 변경 실패를 안정 상태로 표시할 수 있습니다. + +### 배포 상태를 업데이트해야 하는 경우 {#when-to-update-deployment-status} + +다음 시나리오에서 배포 상태를 수동으로 업데이트하는 것을 고려하세요. +- 배포로 인해 프로덕션 문제가 발생했지만 변경 실패로 탐지되지 않은 경우 +- 배포가 변경 실패로 잘못 분류된 경우(오탐) +- 보고를 위해 올바른 상태를 즉시 반영해야 하는 경우 + +### API를 통한 상태 업데이트 {#update-status-through-the-api} + +[DORA Metrics API][4]를 사용하여 프로그래밍 방식으로 배포 상태를 업데이트하세요. 다음 예시에서는 배포를 변경 실패로 표시하고 롤백 수정에 연결합니다. + +```shell +curl -X PATCH "https://api.datadoghq.com/api/v2/dora/deployment/{deployment_id}" \ +-H "Accept: application/json" \ +-H "Content-Type: application/json" \ +-H "DD-API-KEY: ${DD_API_KEY}" \ +-d @- << EOF +{ + "data": { + "attributes": { + "change_failure": true, + "remediation": { + "id": "eG42zNIkVjM", + "type": "rollback" + } + }, + "id": "z_RwVLi7v4Y", + "type": "dora_deployment_patch_request" + } +} +EOF +``` + +`remediation` 필드는 선택 사항이지만 실패한 배포 복구 시간을 계산하려면 필요합니다. + +### UI를 통한 상태 업데이트 {#update-status-through-the-ui} + +Datadog UI에서 배포 상태를 업데이트하려면 다음 단계를 따르세요. + +1. {{< ui >}}Software Delivery{{< /ui >}} > {{< ui >}}DORA Metrics{{< /ui >}}로 이동하고 [{{< ui >}}View Deployments{{< /ui >}}][5]를 클릭합니다. +2. 배포를 클릭하여 배포 세부 정보 패널을 엽니다. +3. 배포 세부 정보 패널의 드롭다운에서 {{< ui >}}Deployment status{{< /ui >}}를 선택하여 배포를 failed 또는 stable로 표시합니다. + +{{< img src="delivery_performance/dora_metrics/deployment_status_update.mp4" alt="Datadog UI에서 배포의 변경 실패 상태 업데이트" video="true" >}} + +## 추가 자료 {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://app.datadoghq.com/ci/settings/dora +[2]: /ko/delivery_performance/dora_metrics/calculation/#change-failure-rate +[3]: /ko/delivery_performance/dora_metrics/calculation/#failed-deployment-recovery-time +[4]: /ko/api/latest/dora-metrics/#patch-a-deployment-event +[5]: https://app.datadoghq.com/ci/dora?detail=deployments \ No newline at end of file diff --git a/hugo/content/ko/deployment_gates/setup/preconfigured.md b/hugo/content/ko/deployment_gates/setup/preconfigured.md new file mode 100644 index 00000000000..dd3c57ad5f4 --- /dev/null +++ b/hugo/content/ko/deployment_gates/setup/preconfigured.md @@ -0,0 +1,578 @@ +--- +description: Datadog에서 게이트와 규칙을 미리 생성한 다음, 배포 시 서비스 및 환경별로 참조하세요. +further_reading: +- link: /deployment_gates/setup/jit + tag: 설명서 + text: JIT (Just-In-Time) Deployment Gates 설정하기 +- link: /deployment_gates/explore + tag: 설명서 + text: Deployment Gates 탐색기에 대해 알아보기 +- link: /api/latest/deployment-gates + tag: API 참조 + text: Deployment Gates API 참조 +title: 사전 구성된 Deployment Gates를 설정 +--- +{{< callout url="http://datadoghq.com/product-preview/deployment-gates" >}} +Deployment Gates는 미리 보기로 제공되고 있습니다. 이 기능에 관심이 있다면 양식을 작성하여 액세스 권한을 요청하세요. +{{< /callout >}} + +**사전 구성된** Deployment Gates를 사용하면 게이트와 규칙이 Datadog에 저장되며, 평가 시 서비스 및 환경을 기준으로 참조됩니다. 사전 구성된 게이트는 여러 배포에서 규칙을 공유하거나, Terraform에서 구성을 관리하거나, CI 사용자가 아닌 사용자가 Datadog UI에서 규칙을 편집하도록 하려는 경우에 적합합니다. + +배포 구성에서 규칙을 인라인으로 정의하려면 [JIT (Just-In-Time) Deployment Gates][5]를 참조하세요. + +## 게이트 생성 {#create-a-gate} + +
Deployment Gates UI를 사용하는 것 외에도 Deployment Gates API 또는 Datadog Terraform provider를 사용하여 프로그래밍 방식으로 게이트와 규칙을 관리할 수 있습니다.
+ +1. [{{< ui >}}Software Delivery{{< /ui >}} > {{< ui >}}Deployment Gates{{< /ui >}} > {{< ui >}}Configuration{{< /ui >}}][6]로 이동합니다. +2. {{< ui >}}Create Gate{{< /ui >}}를 클릭합니다. +3. 다음 설정을 구성합니다. + - {{< ui >}}Service{{< /ui >}}: 서비스 이름입니다(예: `transaction-backend`). + - {{< ui >}}Environment{{< /ui >}}: 대상 환경입니다(예: `dev`). + - {{< ui >}}Identifier{{< /ui >}}(필요시, 기본값은 `default`): 동일한 서비스/환경에 있는 여러 게이트에 대한 고유 이름입니다. 다음과 같은 용도로 사용할 수 있습니다. + - 다양한 배포 전략을 허용합니다(예: `fast-deploy` 또는 `default`). + - 배포 단계를 구분합니다(예: `pre-deploy` 또는 `post-deploy`). + - 카나리 스테이지를 정의합니다(예: `pre-deploy` 또는 `canary-20pct`). + - {{< ui >}}Evaluation Mode{{< /ui >}}: 배포에 영향을 주지 않고 게이트 동작을 테스트하려면 {{< ui >}}Dry Run{{< /ui >}}을 활성화하세요. Dry Run 게이트의 평가는 항상 통과 상태로 응답하지만, 앱 내 결과에서는 실제 평가가 표시됩니다. 이는 배포 파이프라인에 영향을 주지 않고 게이트 동작을 처음 평가할 때 유용합니다. + +## 게이트에 규칙 추가 {#add-rules-to-a-gate} + +각 게이트는 평가할 하나 이상의 규칙이 필요합니다. 게이트가 성공하려면 모든 규칙이 통과해야 합니다. 각 규칙에 대해 다음을 지정하세요. + +1. {{< ui >}}Name{{< /ui >}}: [Deployment Gates Evaluations][7] 페이지에 표시되는 설명 레이블입니다(예: `Check all P0 monitors`). +2. {{< ui >}}Type{{< /ui >}}: {{< ui >}}Monitor{{< /ui >}} 또는 {{< ui >}}Faulty Deployment Detection{{< /ui >}}을 선택합니다. +3. 선택한 규칙 유형에 따른 추가 설정을 구성합니다. 사용 가능한 옵션은 [규칙 유형](#rule-types)을 참조하세요. +4. {{< ui >}}Evaluation Mode{{< /ui >}}: 규칙을 {{< ui >}}Dry Run{{< /ui >}}으로 설정한 경우, 전체 게이트 결과를 계산할 때 해당 규칙의 결과는 반영되지 않습니다. + +## 규칙 유형 {#rule-types} + +전체 스키마 및 사용 가능한 모든 옵션은 [Deployment Gates API 참조][4]를 참조하세요. + +{{< tabs >}} +{{% tab "Monitor" %}} +Monitor 규칙은 구성 가능한 기간 동안 모니터 집합의 상태를 평가합니다. 평가 기간 중 언제든지 다음 상황이 발생하면 실패합니다. + +- 쿼리와 일치하는 모니터가 없는 경우 +- 쿼리와 일치하는 모니터가 50개를 초과하는 경우 +- 일치하는 모니터 중 하나라도 `ALERT` 또는 `NO_DATA` 상태인 경우 + +##### 구성 설정 {#configuration-settings} + +- {{< ui >}}Search Query{{< /ui >}}: [Search Monitor 구문][1]을 기반으로 평가할 모니터를 찾는 데 사용되는 쿼리입니다. 다음 모니터 태그를 기준으로 필터링할 수 있습니다. + - 모니터 정적 태그: `service:transaction-backend` + - 모니터 쿼리 내 태그: `scope:"service:transaction-backend"` + - [모니터 그룹][2] 내 태그: `group:"service:transaction-backend"` +- {{< ui >}}Duration{{< /ui >}}: 일치하는 모니터를 평가할 기간(초)입니다. 기본값은 0입니다. 이 경우 모니터가 즉시 평가됩니다. 최댓값은 7,200초(2시간)입니다. + +##### 쿼리 예시 {#example-queries} + +- `env:prod service:transaction-backend` +- `env:prod (service:transaction-backend OR group:"service:transaction-backend" OR scope:"service:transaction-backend")` +- `tag:"use_deployment_gates" team:payment` +- `tag:"use_deployment_gates" AND (NOT group:("team:frontend"))` + +**참고**: +- `group`필터는 일치하는 그룹만 평가합니다. +- 음소거된 모니터는 평가에서 자동으로 제외됩니다. 쿼리에는 항상 `muted:false`가 포함됩니다. + +[1]: /ko/monitors/manage/search/ +[2]: /ko/monitors/manage/#triggered-monitors +{{% /tab %}} +{{% tab "APM Faulty Deployment Detection" %}} +이 규칙 유형은 Watchdog의 [APM Faulty Deployment Detection][1] 분석을 사용하여 배포된 버전과 동일한 서비스의 이전 버전을 비교합니다. 분석을 통해 탐지되는 사항은 다음과 같습니다. + +- 새로운 유형의 오류 +- 이전 버전 대비 오류율이 크게 증가한 경우 + +이 분석은 모든 APM 계측 서비스에 대해 자동으로 수행되며, 사전 설정이 필요하지 않습니다. + +##### 구성 설정 {#configuration-settings-1} + +- {{< ui >}}Operation Name{{< /ui >}}: 서비스의 [APM 기본 작업][3] 설정에서 자동으로 입력됩니다. +- {{< ui >}}Duration{{< /ui >}}: 분석이 실행되는 시간(초)입니다. 분석 신뢰도를 위해 이 값은 배포 시작 후 900초(15분) 이상으로 설정하는 것이 좋습니다. 최댓값은 7,200초(2시간)입니다. +- {{< ui >}}Allowed Resources{{< /ui >}} (필요시): 분석에 포함할 쉼표로 구분된 [APM 리소스][2]입니다. 지정된 경우 목록에 있는 리소스만 분석됩니다. {{< ui >}}Excluded Resources{{< /ui >}}와 상호 배타적입니다. +- {{< ui >}}Excluded Resources{{< /ui >}} (선택 사항): 무시할 쉼표로 구분된 [APM 리소스][2]입니다(예: 낮은 볼륨 또는 낮은 우선순위 엔드포인트). {{< ui >}}Allowed Resources{{< /ui >}}와 상호 배타적입니다. + +**참고**: +- 이 규칙은 각 [추가 기본 태그][4] 값과 집계 분석에 대해 평가됩니다. 단일 기본 태그만 고려하려면 [게이트 평가를 요청](#evaluate-a-gate-from-your-pipeline)할 때 지정하세요. +- 리소스 수준에서 새로운 오류 및 오류율 증가가 탐지됩니다. +- 이 규칙 유형은 `database` 또는 `inferred service`로 표시된 서비스를 지원하지 않습니다. + +[1]: /ko/watchdog/faulty_deployment_detection/ +[2]: /ko/tracing/services/resource_page/ +[3]: /ko/tracing/guide/configuring-primary-operation/#primary-operations +[4]: /ko/tracing/guide/setting_primary_tags_to_scope/?tab=helm#add-additional-primary-tags-in-datadog +{{% /tab %}} +{{< /tabs >}} + +## 파이프라인에서 게이트 평가 {#evaluate-a-gate-from-your-pipeline} + +게이트를 구성한 후 관련 서비스를 배포할 때 평가를 요청하고, 결과에 따라 배포를 차단하거나 계속할지 결정하세요. + +{{< tabs >}} +{{% tab "datadog-ci CLI" %}} +[datadog-ci][1] `deployment gate` 명령은 단일 명령으로 평가를 실행합니다. + +```bash +datadog-ci deployment gate --service transaction-backend --env staging --identifier default +``` + +Deployment Gate에 APM Faulty Deployment Detection 규칙이 포함된 경우 버전(예: `--version 1.0.1`)도 지정하세요. + +이 명령은 다음을 수행합니다. + +- 게이트 평가를 시작하기 위한 요청을 전송하고 평가가 완료될 때까지 대기합니다. +- 평가를 기다릴 최대 시간을 구성할 수 있습니다. +- 오류에 대한 자동 재시도 기능이 내장되어 있습니다. +- 예기치 않은 Datadog 오류 발생 시 동작을 사용자 지정하기 위해 `--fail-on-error`을 지원합니다. + +`deployment gate` 명령은 datadog-ci 버전 v3.17.0 이상에서 사용할 수 있습니다. + +**필수 환경 변수**: + +- `DD_API_KEY`: [API 키][2] +- `DD_APP_KEY`: [애플리케이션 키][3] +- `DD_BETA_COMMANDS_ENABLED=1`: `deployment gate` 명령은 베타 명령입니다. + +전체 구성 옵션 및 사용 예시는 [`deployment gate` 명령 문서][4]를 참조하세요. + +[1]: https://github.com/DataDog/datadog-ci +[2]: https://app.datadoghq.com/organization-settings/api-keys +[3]: https://app.datadoghq.com/organization-settings/application-keys +[4]: https://github.com/DataDog/datadog-ci/tree/master/packages/plugin-deployment#gate + +{{% /tab %}} +{{% tab "Argo Rollouts" %}} +Argo Rollouts Kubernetes 리소스에서 [AnalysisTemplate][1] 또는 [ClusterAnalysisTemplate][1]을 생성하여 Deployment Gates를 호출하세요. 이 템플릿은 [datadog-ci 배포 게이트 명령][7]을 실행하여 Deployment Gates API와 상호작용합니다. + +아래 템플릿을 시작점으로 사용하세요. + +- ``를 [Datadog 사이트 이름][2]으로 바꿉니다(예: {{< region-param key="dd_site" code="true" >}}). +- [API 키][5] 및 [애플리케이션 키][6]를 환경 변수로 정의합니다. 이 예시에서는 `api-key` 및 `app-key`라는 두 개의 데이터 값을 가진 `datadog`이라는 [Kubernetes 시크릿][3]을 사용합니다. `valueFrom` 대신 `value`를 사용하여 일반 텍스트로 값을 전달할 수도 있습니다. + +```yaml +apiVersion: argoproj.io/v1alpha1 +kind: ClusterAnalysisTemplate +metadata: + name: datadog-job-analysis +spec: + args: + - name: service + - name: env + metrics: + - name: datadog-job + provider: + job: + spec: + ttlSecondsAfterFinished: 300 + backoffLimit: 0 + template: + spec: + restartPolicy: Never + containers: + - name: datadog-check + image: datadog/ci:v3.17.0 + env: + - name: DD_BETA_COMMANDS_ENABLED + value: "1" + - name: DD_SITE + value: "" + - name: DD_API_KEY + valueFrom: + secretKeyRef: + name: datadog + key: api-key + - name: DD_APP_KEY + valueFrom: + secretKeyRef: + name: datadog + key: app-key + command: ["/bin/sh", "-c"] + args: + - datadog-ci deployment gate --service {{ args.service }} --env {{ args.env }} --identifier default +``` + +- 분석 템플릿은 Rollout 리소스(예: `service`, `env`, `version`)로부터 인수를 받을 수 있습니다. 자세한 내용은 [공식 Argo Rollouts 문서][4]를 참조하세요. +- `ttlSecondsAfterFinished`는 완료된 작업을 5분 후에 제거합니다. +게이트 평가가 실패할 경우 작업을 재시도하지 않아야 하므로 - `backoffLimit`은 0으로 설정됩니다. + +분석 템플릿을 생성한 후 Argo Rollouts 전략에서 이를 참조하세요. + +```yaml +apiVersion: argoproj.io/v1alpha1 +kind: Rollout +metadata: + name: rollouts-demo + labels: + tags.datadoghq.com/service: transaction-backend + tags.datadoghq.com/env: dev +spec: + replicas: 5 + strategy: + canary: + steps: + ... + - analysis: + templates: + - templateName: datadog-job-analysis + clusterScope: true # Only needed for cluster analysis + args: + - name: env + valueFrom: + fieldRef: + fieldPath: metadata.labels['tags.datadoghq.com/env'] + - name: service + valueFrom: + fieldRef: + fieldPath: metadata.labels['tags.datadoghq.com/service'] + - name: version #Required for APM Faulty Deployment Detection rules + valueFrom: + fieldRef: + fieldPath: metadata.labels['tags.datadoghq.com/version'] + - ... +``` + +[1]: https://argo-rollouts.readthedocs.io/en/stable/features/analysis/#analysis-progressive-delivery +[2]: /ko/getting_started/site/ +[3]: https://kubernetes.io/docs/concepts/configuration/secret/ +[4]: https://argo-rollouts.readthedocs.io/en/stable/features/analysis/#analysis-template-arguments +[5]: https://app.datadoghq.com/organization-settings/api-keys +[6]: https://app.datadoghq.com/organization-settings/application-keys +[7]: https://github.com/DataDog/datadog-ci/tree/master/packages/plugin-deployment#gate + +{{% /tab %}} +{{% tab "GitHub Actions" %}} +[Datadog Deployment Gate GitHub Action][4]은 워크플로의 일부로 평가를 실행합니다. + +기존 배포 워크플로에 `DataDog/deployment-gate-github-action` 단계를 추가하세요: + +```yaml +name: Deploy with Datadog Deployment Gate +on: + push: + branches: [main] +jobs: + deploy: + runs-on: ubuntu-latest + steps: + - name: Deploy Canary + run: | + echo "Deploying canary release for service:'my-service' in 'production'. Version 1.0.1" + # Your deployment commands here + + - name: Evaluate Deployment Gate + uses: DataDog/deployment-gate-github-action@v2.1.0 + env: + DD_API_KEY: ${{ secrets.DD_API_KEY }} + DD_APP_KEY: ${{ secrets.DD_APP_KEY }} + with: + service: my-service + env: production + identifier: default + + - name: Deploy + run: | + echo "Deployment Gate passed, proceeding with deployment" + # Your deployment commands here +``` + +Deployment Gate에 APM Faulty Deployment Detection 규칙이 포함된 경우 버전(예: `version: 1.0.1`)도 지정하세요. + +이 액션은 다음을 수행합니다. + +- 게이트 평가를 시작하기 위한 요청을 전송하고 평가가 완료될 때까지 대기합니다. +- 평가를 기다릴 최대 시간을 구성할 수 있습니다. +- 오류에 대한 자동 재시도 기능이 내장되어 있습니다. +- 예기치 않은 Datadog 오류 발생 시 동작을 사용자 지정하기 위해 `fail-on-error`을 지원합니다. + +**필수 환경 변수**: + +- `DD_API_KEY`: [API 키][2] +- `DD_APP_KEY`: [애플리케이션 키][3] + +전체 구성 옵션 및 사용 예시는 [`DataDog/deployment-gate-github-action` 리포지토리][4]를 참조하세요. + +[1]: https://github.com/DataDog/datadog-ci +[2]: https://app.datadoghq.com/organization-settings/api-keys +[3]: https://app.datadoghq.com/organization-settings/application-keys +[4]: https://github.com/DataDog/deployment-gate-github-action + +{{% /tab %}} +{{% tab "일반 스크립트" %}} + +이 스크립트를 시작점으로 사용하세요. 이 스크립트는 인라인 규칙 없이 사전 구성된 게이트를 평가합니다. + +다음 값을 바꾸세요. + +- ``: [Datadog 사이트 이름][1](예: {{< region-param key="dd_site" code="true" >}}) +- ``: [API 키][2] +- ``: [애플리케이션 키][3] + +```bash +#!/bin/sh + +# Configuration +MAX_RETRIES=3 +DELAY_SECONDS=5 +POLL_INTERVAL_SECONDS=15 +MAX_POLL_TIME_SECONDS=10800 # 3 hours +API_URL="https://api./api/v2/deployments/gates/evaluation" +API_KEY="" +APP_KEY="" + +PAYLOAD=$(cat <`: [Datadog 사이트 이름][1](예: {{< region-param key="dd_site" code="true" >}}) +- ``: [API 키][2] +- ``: [애플리케이션 키][3] + +Datadog에 이미 존재하는 게이트에 대한 평가를 요청하세요. + +```bash +curl -X POST "https://api./api/v2/deployments/gates/evaluation" \ +-H "Content-Type: application/json" \ +-H "DD-API-KEY: " \ +-H "DD-APPLICATION-KEY: " \ +-d @- << EOF +{ + "data": { + "type": "deployment_gates_evaluation_request", + "attributes": { + "service": "transaction-backend", + "env": "staging", + "identifier": "my-custom-identifier", + "version": "v123-456", + "primary_tag": "region:us-central-1" + } + } +} +EOF +``` + +선택적 속성: + +- `identifier`: 선택 사항이며, 기본값은 `default`입니다. +- `version`: APM Faulty Deployment Detection 규칙에 필요합니다. +- `primary_tag`: 선택 사항이며, APM Faulty Deployment Detection 범위를 선택한 기본 태그로 제한합니다. + +**참고**: 404 HTTP 응답은 게이트를 찾을 수 없거나, 게이트는 찾았지만 규칙이 없음을 의미할 수 있습니다. + +게이트 평가가 성공적으로 시작되면 202 HTTP 상태 코드가 반환됩니다. + +```json +{ + "data": { + "id": "", + "type": "deployment_gates_evaluation_response", + "attributes": { + "evaluation_id": "e9d2f04f-4f4b-494b-86e5-52f03e10c8e9" + } + } +} +``` + +`data.attributes.evaluation_id` 필드에는 이 게이트 평가의 고유 식별자가 포함됩니다. + +평가 ID를 사용하여 상태 엔드포인트를 폴링하여 게이트 평가 상태를 가져오세요. + +```bash +curl -X GET "https://api./api/v2/deployments/gates/evaluation/" \ +-H "DD-API-KEY: " \ +-H "DD-APPLICATION-KEY: " +``` + +**참고**: 평가를 요청한 직후 이 엔드포인트를 호출하면 평가가 아직 시작되지 않아 404 HTTP 응답이 반환될 수 있습니다. 몇 초 후에 다시 시도하세요. + +200 HTTP 응답이 반환될 경우 응답의 형식은 다음과 같습니다. + +```json +{ + "data": { + "id": "", + "type": "deployment_gates_evaluation_result_response", + "attributes": { + "dry_run": false, + "evaluation_id": "e9d2f04f-4f4b-494b-86e5-52f03e10c8e9", + "evaluation_url": "https://app.datadoghq.com/ci/deployment-gates/evaluations?index=cdgates&query=level%3Agate+%40evaluation_id%3Ae9d2f14f-4f4b-494b-86e5-52f03e10c8e9", + "gate_id": "e140302e-0cba-40d2-978c-6780647f8f1c", + "gate_status": "pass", + "rules": [ + { + "name": "Check service monitors", + "status": "fail", + "reason": "One or more monitors in ALERT state: https://app.datadoghq.com/monitors/34330981", + "dry_run": true + } + ] + } + } +} +``` + +`data.attributes.gate_status` 필드에는 평가 결과가 포함되며, 값은 다음 중 하나입니다. + +- `in_progress`: Deployment Gates 평가가 아직 진행 중입니다. 폴링을 계속하세요. +- `pass`: Deployment Gates 평가가 통과되었습니다. +- `fail`: Deployment Gates 평가가 실패했습니다. + +**참고**: `data.attributes.dry_run` 필드가 `true`인 경우, `data.attributes.gate_status` 필드는 항상 `pass`입니다. + +[1]: /ko/getting_started/site/ +[2]: https://app.datadoghq.com/organization-settings/api-keys +[3]: https://app.datadoghq.com/organization-settings/application-keys + +{{% /tab %}} +{{< /tabs >}} + +## 첫 온보딩을 위한 권장 사항{#recommendation-for-first-time-onboarding} + +Continuous Delivery 워크플로에 Deployment Gates를 통합할 때 평가 단계를 사용하면 배포에 영향을 주기 전에 제품이 예상대로 작동하는지 확인하는 데 도움이 됩니다. Dry Run 평가 모드와 [{{< ui >}}Deployment Gates Evaluations{{< /ui >}}][7] 페이지를 사용하세요. + +1. 서비스에 대한 게이트를 생성하고 {{< ui >}}Evaluation Mode{{< /ui >}}를 {{< ui >}}Dry Run{{< /ui >}}으로 설정합니다. +2. 배포 프로세스에 게이트 평가를 추가합니다. 게이트가 Dry Run 모드인 동안 API는 항상 `pass`를 반환하며, 게이트 결과가 배포에 영향을 주지 않습니다. +3. 일정 기간(예: 1~2주) 후에 {{< ui >}}Deployment Gates Evaluations{{< /ui >}} 페이지에서 게이트 및 규칙 실행을 검사합니다. UI에 실제 상태가 표시되므로 게이트가 실패했을 시점과 그 이유를 확인할 수 있습니다. +4. 게이트가 예상대로 동작한다고 확신하면 게이트를 편집하고 평가 모드를 {{< ui >}}Dry Run{{< /ui >}}에서 {{< ui >}}Active{{< /ui >}}로 전환합니다. 그 후, API가 실제 상태를 반환하기 시작하고 게이트 결과에 따라 배포가 승격되거나 롤백되기 시작합니다. + +## 추가 자료 {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ko/getting_started/site/ +[2]: https://app.datadoghq.com/organization-settings/api-keys +[3]: https://app.datadoghq.com/organization-settings/application-keys +[4]: /ko/api/latest/deployment-gates +[5]: /ko/deployment_gates/setup/jit +[6]: https://app.datadoghq.com/ci/deployment-gates/gates +[7]: https://app.datadoghq.com/ci/deployment-gates/evaluations \ No newline at end of file diff --git a/hugo/content/ko/error_tracking/backend/exception_replay.md b/hugo/content/ko/error_tracking/backend/exception_replay.md index e6139d9d10d..f8f8fceed80 100644 --- a/hugo/content/ko/error_tracking/backend/exception_replay.md +++ b/hugo/content/ko/error_tracking/backend/exception_replay.md @@ -54,7 +54,7 @@ Exception Replay는 Python, Java, .NET, PHP를 지원하며 APM 기반 예외만 |---|---|---|---| | **활성화 방법** | 기본적으로 활성화됨| 설정 페이지| 환경 변수| | **Agent 버전** | v7.49.0+ | v7.49.0+ | v7.49.0+ | -| **트레이서 최소 버전** | [Python][8] ≥ 3.15.0
[Java][9] ≥ 1.54.0
[.NET][10] ≥ 3.29.0
[PHP][11] ≥ 1.19.0 | [Python][8] ≥ 3.10.0
[Java][9] ≥ 1.48.0
[.NET][10] ≥ 3.29.0
[PHP][11] ≥ 1.19.0 | [Python][8] ≥ 1.16.0
[Java][9] ≥ 1.47.0
[.NET][10] ≥ 2.53.0
[PHP][11] ≥ 1.12.1 | +| **최소 트레이서 버전** | [Python][8] ≥ 3.15.0
[Java][9] ≥ 1.54.0
[.NET][10] ≥ 3.29.0
[PHP][11] ≥ 1.19.0 | [Python][8] ≥ 3.10.0
[Java][9] ≥ 1.48.0
[.NET][10] ≥ 3.29.0
[PHP][11] ≥ 1.14.0 | [Python][8] ≥ 1.16.0
[Java][9] ≥ 1.47.0
[.NET][10] ≥ 2.53.0
[PHP][11] ≥ 1.12.1 | | **Remote Configuration 필요 여부** | 예 | 예 | 아니요 | 인앱에서 Exception Replay를 활성화하려면 Error Tracking의 Exception Replay {{< ui >}}Settings{{< /ui >}} 페이지로 이동하여, diff --git a/hugo/content/ko/error_tracking/ticketing_systems/_index.md b/hugo/content/ko/error_tracking/ticketing_systems/_index.md new file mode 100644 index 00000000000..e9a04ced4ce --- /dev/null +++ b/hugo/content/ko/error_tracking/ticketing_systems/_index.md @@ -0,0 +1,38 @@ +--- +further_reading: +- link: /error_tracking/explorer/ + tag: 설명서 + text: Error Tracking Explorer 시작하기 +- link: /error_tracking/issue_states/ + tag: 설명서 + text: Error Tracking 이슈 상태 및 워크플로 +- link: /incident_response/work_management/ + tag: 설명서 + text: Work Management +is_beta: false +private: false +title: Error Tracking 티켓팅 시스템 통합 +--- +## 개요 {#overview} + +Datadog Error Tracking은 기존 티켓팅 워크플로와 통합되어 이슈 해결을 간소화합니다. Error Tracking 이슈를 Jira 티켓, Linear 이슈 또는 Work Management 작업 항목에 연결하여 확립된 프로세스 내에서 오류를 추적 및 해결하세요. + +티켓팅 시스템 통합을 통해 다음을 수행할 수 있습니다. + +- **이슈에서 직접 티켓 생성**: Error Tracking 이슈 패널에서 Jira 티켓, Linear 이슈 또는 Work Management 작업 항목을 열어 조사 작업을 한곳에서 관리하세요. +- **여러 이슈를 하나의 티켓으로 그룹화**: 관련된 여러 Error Tracking 이슈를 하나의 티켓이나 작업 항목에 첨부하여 상관관계가 있는 이슈를 하나의 작업 단위로 통합하세요. +- **티켓 생성 자동화**: 이슈가 특정 기준과 일치할 때 특정 Jira 보드나 Work Management 프로젝트에서 티켓을 자동으로 생성하도록 규칙을 구성하세요. + +이러한 기능을 통해 오류 탐지와 해결 워크플로 간의 간극을 줄여 팀이 오류에 보다 신속하게 대응할 수 있습니다. + +## 시작 {#getting-started} + +{{< whatsnext desc="시작하려면 사용할 티켓팅 시스템을 선택하세요." >}} + {{< nextlink href="error_tracking/ticketing_systems/jira" >}}Jira{{< /nextlink >}} + {{< nextlink href="error_tracking/ticketing_systems/linear" >}}Linear{{< /nextlink >}} + {{< nextlink href="error_tracking/ticketing_systems/work_management" >}}Work Management{{< /nextlink >}} +{{< /whatsnext >}} + +## 추가 자료 {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} \ No newline at end of file diff --git a/hugo/content/ko/feature_flags/guide/apm_trace_enrichment.md b/hugo/content/ko/feature_flags/guide/apm_trace_enrichment.md new file mode 100644 index 00000000000..1c201a9fb0e --- /dev/null +++ b/hugo/content/ko/feature_flags/guide/apm_trace_enrichment.md @@ -0,0 +1,207 @@ +--- +description: 플래그 변형별로 트레이스를 검사하고 필터링할 수 있도록 APM 트레이스에 기능 플래그 평가 데이터를 자동으로 연결하세요. +further_reading: +- link: /feature_flags/server/ + tag: 설명서 + text: 서버 측 Feature Flags +- link: /feature_flags/guide/server_flag_evaluation_metrics/ + tag: 가이드 + text: 서버 측 플래그 평가 메트릭 설정 +- link: /tracing/trace_explorer/ + tag: 설명서 + text: Trace Explorer +title: Feature Flags에 대한 APM 트레이스 보강 설정 +--- +## 개요 {#overview} + +APM 트레이스 보강은 APM 트레이스에 기능 플래그 평가 데이터를 자동으로 연결합니다. 추적된 요청 중에 기능 플래그가 평가되면 SDK는 어떤 플래그가 평가되었고 어떤 변형이 반환되었는지 기록합니다. 이 데이터는 루트 스팬에 작성되고 서버 측에서 처리되므로 사용자가 다음을 수행할 수 있습니다. + +`@feature_flags.:` 패싯을 사용하여 [Trace Explorer][1]에서 - **플래그 변형별로 트레이스를 필터링**합니다. +오류 발생 시 활성화 상태였던 플래그를 확인하여 - **플래그 관련 문제를 디버깅**합니다. + +
APM 트레이스 보강은 실험적 기능이며 향후 릴리스에서 변경될 수 있습니다.
+ +APM 트레이스 보강은 다음 SDK에서 사용할 수 있습니다. + +| 언어 | 최소 버전 | +| -------- | --------------- | +| Go | 2.8.0 | +| Java | 1.64.1 | +| Node.js | 5.105.0 | + +## 전제 조건 {#prerequisites} + +APM 트레이스 보강을 설정하기 전에 다음 사항을 확인하세요. + +- 서버 측 기능 플래그가 이미 구성되어 있고 애플리케이션에서 플래그가 평가되고 있습니다. +- [APM 추적][3]이 활성화되어 있고 트레이스가 Datadog으로 흐르고 있습니다. + +## APM 트레이스 보강의 작동 방식 {#how-apm-trace-enrichment-works} + +APM 트레이스 보강이 활성화되면 Datadog OpenFeature 공급자가 평가 수명 주기에 연결됩니다. + +1. 플래그가 평가될 때마다 SDK가 평가 메타데이터(플래그 일련 ID, 타겟팅 키 및 기본 폴백 값)를 캡처합니다. +2. 메타데이터가 현재 트레이스의 루트 스팬에 누적됩니다. +3. 루트 스팬이 완료되면 SDK가 누적된 데이터를 압축된 스팬 태그(`ffe_flags_enc`, `ffe_subjects_enc`, `ffe_runtime_defaults`)로 작성합니다. +4. Datadog 백엔드가 이러한 태그를 디코딩하고 사람이 읽을 수 있는 `@feature_flags.` 패싯을 스팬에 작성하여 Trace Explorer에서 검색할 수 있도록 합니다. + +SDK 측 태그는 전송 전용이며 서버 측에서 제거됩니다. Trace Explorer에서 볼 수 있는 태그는 디코딩된 `@feature_flags.` 패싯입니다. + +## APM 트레이스 보강 활성화 {#enable-apm-trace-enrichment} + +스팬 보강을 활성화하려면 다음 환경 변수를 설정하세요. + +{{< code-block lang="bash" >}} +DD_EXPERIMENTAL_FLAGGING_PROVIDER_SPAN_ENRICHMENT_ENABLED=true +{{< /code-block >}} + +보강 환경 변수는 지원되는 모든 서버 측 SDK에서 지원됩니다. 코드를 변경할 필요가 없습니다. 이 변수를 활성화하면 Datadog OpenFeature 공급자가 초기화될 때 보강 후크가 자동으로 활성화됩니다. Node.js는 아래의 언어 탭에 나와 있는 대로 코드 수준 구성을 추가적으로 지원합니다. + +### 언어별 구성 {#language-specific-configuration} + +{{< tabs >}} +{{% tab "Go" %}} + +추가 코드 구성은 필요하지 않습니다. `DatadogProvider`가 초기화될 때 `DD_EXPERIMENTAL_FLAGGING_PROVIDER_SPAN_ENRICHMENT_ENABLED` 환경 변수가 스팬 보강을 활성화합니다. + +{{< code-block lang="go" filename="main.go" >}} +package main + +import ( + "log" + + "github.com/DataDog/dd-trace-go/v2/ddtrace/tracer" + ddopenfeature "github.com/DataDog/dd-trace-go/v2/openfeature" + "github.com/open-feature/go-sdk/openfeature" +) + +func main() { + tracer.Start() + defer tracer.Stop() + + provider, err := ddopenfeature.NewDatadogProvider(ddopenfeature.ProviderConfig{}) + if err != nil { + log.Fatalf("Failed to create provider: %v", err) + } + if ddProvider, ok := provider.(*ddopenfeature.DatadogProvider); ok { + defer ddProvider.Shutdown() + } + + if err := openfeature.SetProviderAndWait(provider); err != nil { + log.Fatalf("Failed to set provider: %v", err) + } + + client := openfeature.NewClient("my-service") + // Flag evaluations now enrich APM spans automatically +} +{{< /code-block >}} + +{{% /tab %}} +{{% tab "Java" %}} + +추가 코드 구성은 필요하지 않습니다. `DD_EXPERIMENTAL_FLAGGING_PROVIDER_SPAN_ENRICHMENT_ENABLED` 환경 변수가 스팬 보강을 활성화합니다. Java는 대안으로 시스템 속성 `-Ddd.experimental.flagging.provider.span.enrichment.enabled=true`도 지원합니다. + +{{< code-block lang="java" filename="Main.java" >}} +import dev.openfeature.sdk.OpenFeatureAPI; +import dev.openfeature.sdk.Client; +import datadog.trace.api.openfeature.Provider; + +OpenFeatureAPI api = OpenFeatureAPI.getInstance(); +api.setProviderAndWait(new Provider()); +Client client = api.getClient("my-app"); +// Flag evaluations now enrich APM spans automatically +{{< /code-block >}} + +{{% /tab %}} +{{% tab "Node.js" %}} + +코드에서 스팬 보강을 활성화할 수도 있습니다. + +{{< code-block lang="javascript" filename="app.js" >}} +import tracer from 'dd-trace'; + +tracer.init({ + experimental: { + flaggingProvider: { + enabled: true, + spanEnrichment: { + enabled: true, + }, + }, + }, +}); +{{< /code-block >}} + +{{% /tab %}} +{{< /tabs >}} + +## APM 트레이스 보강 확인 {#verify-apm-trace-enrichment} + +스팬 보강이 활성화된 상태에서 배포한 후 다음 단계를 따르세요. + +1. 애플리케이션에서 기능 플래그를 평가하는 요청을 트리거합니다. +2. [Trace Explorer][1]로 이동하고 서비스에서 최신 트레이스를 검색합니다. +3. 트레이스를 열고 루트 스팬에서 `@feature_flags.` 특성을 찾습니다. + +SDK는 압축된 인코딩형 태그(`ffe_flags_enc`, `ffe_subjects_enc`, `ffe_runtime_defaults`)를 루트 스팬에 작성합니다. Datadog 백엔드는 이를 디코딩하여 사람이 읽을 수 있는 `@feature_flags.` 패싯을 생성합니다. 이 처리에는 스팬이 수집된 후 몇 초 정도 걸립니다. + +백엔드 처리 후 루트 스팬에는 다음 예시와 같은 특성이 포함됩니다. + +| 예시 특성 | 예시 값 | +| --------- | ------------- | +| `@feature_flags.checkout-flow` | `treatment` | +| `@feature_flags.dark-mode` | `control` | + +각 특성 키는 `@feature_flags.`이며 값은 평가를 통해 반환된 변형입니다. + +### 문제 해결 {#troubleshooting} + +`@feature_flags.` 특성이 트레이스에 나타나지 않는 경우: + +- 스팬 보강이 활성화되어 있는지 확인합니다(`DD_EXPERIMENTAL_FLAGGING_PROVIDER_SPAN_ENRICHMENT_ENABLED=true`). +- 애플리케이션이 추적된 요청 중 플래그를 평가하고 있는지 확인합니다. 보강은 트레이스가 활성화된 상태에서 플래그가 평가될 때만 발생합니다. +- 스팬이 수집된 후 몇 초 정도 기다립니다. `@feature_flags.` 패싯은 백엔드 처리를 통해 파생되며 원시 스팬 메타데이터에 나타나지 않습니다. +- 디버깅을 위해 `ffe_flags_enc` 태그에 대한 원시 스팬 메타데이터를 검사합니다. 이 태그가 있으면 SDK가 보강 데이터를 내보내고 있는 것입니다. 백엔드가 아직 처리하지 않았거나 조직에 기능 플래그 게이트가 활성화되지 않았을 수 있습니다. +- 플래그가 전혀 평가되지 않는 경우, [서버 측 Feature Flags][2]에서 설정 및 언어별 문제 해결 정보를 확인합니다. + +## 플래그 변형별 검색 및 필터링 {#search-and-filter-by-flag-variant} + +이 예시에서는 `@feature_flags.` 패싯을 사용하여 Trace Explorer에서 트레이스를 필터링합니다. + +| 사용 사례 | 예시 쿼리 | +| -------- | ------------- | +| 특정 변형에 대한 트레이스 | `@feature_flags.checkout-flow:treatment` | +| 변형 하의 오류 | `@feature_flags.checkout-flow:treatment status:error` | +| 플래그가 평가된 모든 트레이스 | `@feature_flags.checkout-flow:*` | +| 동일한 요청에 대한 다중 플래그 | `@feature_flags.checkout-flow:treatment @feature_flags.new-search:enabled` | +| 서비스 및 환경으로 범위 지정됨 | `env:production service:api-gateway @feature_flags.rate-limit-v2:enabled` | + +## Datadog 전반에서 보강된 트레이스 사용{#use-enriched-traces-across-datadog} + +트레이스의 기능 플래그 특성은 Datadog 전반에서 사용할 수 있습니다. + +- **모니터링**: 특정 변형에 대한 오류 수가 임계값을 초과할 때 경고하여 변형별 회귀를 캡처합니다. +- **대시보드**: `@feature_flags.`를 그룹화 차원으로 사용하여 변형 간 p99 지연 시간을 비교하는 시계열 위젯을 추가합니다. +- **노트북**: 기능 플래그 변형 간의 성능을 비교하는 조사 노트북을 빌드합니다. +- **시각화**: Trace Explorer에서 상위 목록 보기를 사용하여 롤아웃 트래픽 분산이 타겟팅 규칙과 일치하는지 확인합니다. + +## 제한 {#limits} + +SDK는 페이로드 크기를 제한하기 위해 다음과 같은 스팬별 제한을 적용합니다. + +| 제한 | 값 | +| ----- | ----- | +| 스팬별 플래그 일련 ID | 128~200(SDK에 따라 다름)| +| 스팬별 대상 | 10~25(SDK에 따라 다름)| +| 스팬별 런타임 기본 키 | 5 | +| 런타임 기본 값 길이 | 64자(잘림)| + +이 제한을 초과하는 평가는 해당 스팬에서 삭제됩니다. + +## 추가 자료 {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ko/tracing/trace_explorer/ +[2]: /ko/feature_flags/server/ +[3]: /ko/tracing/ \ No newline at end of file diff --git a/hugo/content/ko/incident_response/incident_management/setup_and_configuration/_index.md b/hugo/content/ko/incident_response/incident_management/setup_and_configuration/_index.md new file mode 100644 index 00000000000..40be9b9f71d --- /dev/null +++ b/hugo/content/ko/incident_response/incident_management/setup_and_configuration/_index.md @@ -0,0 +1,46 @@ +--- +aliases: +- /ko/monitors/incident_management/notification_rules +- /ko/monitors/incident_management/incident_settings +- /ko/service_management/incident_management/incident_settings/ +- /ko/incident_response/incident_management/incident_settings +description: Incident Management 경험을 구성 및 맞춤 설정합니다 +title: 설정 및 구성 +--- +## 개요 {#overview} + +[인시던트 설정][1]을 사용하여 조직 전체의 Incident Management 경험을 사용자 지정하세요. 이 설정을 통해 Incident Management 사용 방식을 기존 프로세스에 맞출 수 있습니다. + +## 인시던트 유형 {#incident-types} + +인시던트 유형을 사용하면 다양한 인시던트 클래스에 서로 다른 설정을 적용할 수 있습니다. 보안 인시던트에 대한 대응은 서비스 중단에 대한 대응과 매우 다를 수 있습니다. 인시던트 유형을 사용하면 각 대응을 사용자 지정할 수 있습니다. + +인시던트 유형 만들기 +1. [Incidents Settings][1] 페이지로 이동합니다. +1. **Add Incident Type**을 클릭합니다. +1. 인시던트 유형 이름을 지정합니다. +1. (선택 사항) 설명을 추가합니다. + +## 전역 설정 {#global-settings} + +| 설정 | 설명 | +| --- | ----------- | +| Analytics Dashboard | 인시던트 홈페이지의 Analytics 버튼에 대한 Dashboard를 사용자 지정하세요. 기본적으로 이 링크는 [분석][1]을 위한 템플릿 Incident Management Overview Dashboard로 연결됩니다. | +| 모니터링 자동화| [모니터링 알림 메시지][2]에서 사용할 수 있는 인시던트 @멘션을 생성하여 모니터링이 트리거될 때 자동으로 인시던트를 생성하세요. | + +## 인시던트 대응 사용자 지정 {#customize-incident-response} + +{{< whatsnext desc="다음 항목에 대한 추가 사용자 지정을 설정하세요.">}} + {{< nextlink href="/incident_response/incident_management/setup_and_configuration/information" >}}정보{{< /nextlink >}} + {{< nextlink href="/incident_response/incident_management/setup_and_configuration/integrations" >}}Integrations{{< /nextlink >}} + {{< nextlink href="/incident_response/incident_management/post_incident/follow-ups" >}}후속 조치{{< /nextlink >}} + {{< nextlink href="/incident_response/incident_management/setup_and_configuration/notification_rules" >}}알림 규칙{{< /nextlink >}} + {{< nextlink href="/incident_response/incident_management/setup_and_configuration/property_fields" >}}속성 필드{{< /nextlink >}} + {{< nextlink href="/incident_response/incident_management/setup_and_configuration/transition_forms" >}}전환 양식{{< /nextlink >}} + {{< nextlink href="/incident_response/incident_management/setup_and_configuration/responder_types" >}}응답자 유형{{< /nextlink >}} + {{< nextlink href="/incident_response/incident_management/setup_and_configuration/templates" >}}템플릿{{< /nextlink >}} + {{< nextlink href="/incident_response/incident_management/setup_and_configuration/automations" >}}자동화{{< /nextlink >}} +{{< /whatsnext >}} + +[1]: https://app.datadoghq.com/incidents/settings +[2]: /ko/monitors/notify/ \ No newline at end of file diff --git a/hugo/content/ko/incident_response/incident_management/setup_and_configuration/transition_forms.md b/hugo/content/ko/incident_response/incident_management/setup_and_configuration/transition_forms.md new file mode 100644 index 00000000000..cf70eaa050c --- /dev/null +++ b/hugo/content/ko/incident_response/incident_management/setup_and_configuration/transition_forms.md @@ -0,0 +1,27 @@ +--- +description: 상태 변경 시 인시던트 대응자에게 특정 필드를 작성하도록 요청하세요. +title: 전환 양식 +--- +## 개요 {#overview} + +인시던트로 인해 상태 변경이 진행될 때마다 전환 양식을 사용하여 인시던트 필드를 작성할 것을 대응자에게 안내할 수 있습니다. 이 양식은 인시던트 대응 프로세스의 적절한 시점에 인시던트에 대한 정보가 수집되도록 하는 데 도움이 됩니다. + +{{< img src="/incident_response/incident_management/setup_and_configuration/status_transition_form.png" alt="인시던트를 Resolved로 이동할 때 사용자에게 필수 Teams 및 Postmortem Owner 필드를 작성할 것을 요청하는 상태 변경 양식" style="width:70%;" >}} + +## 전제 조건 {#prerequisites} + +전환 양식을 설정하려면 `Incident Settings Write` 권한이 있어야 합니다. 자세한 내용은 [Datadog 역할 권한][1]을 참조하세요. + +## 전환 양식 구성 {#configure-a-transition-form} + +1. Datadog에서 **Incidents** > [**Settings**][2]로 이동합니다. +1. **Incident Types**에서 편집할 인시던트 유형을 확장합니다. +1. **Transition Forms** 탭을 클릭합니다. +1. 구성하려는 상태를 선택합니다. +1. 양식에 표시할 필드를 선택합니다. [속성 필드][3] 및 [대응자 유형][4]을 추가할 수 있습니다. 모든 필드는 필수 또는 선택 사항으로 표시할 수 있습니다. +1. **Save**를 클릭합니다. + +[1]: /ko/account_management/rbac/permissions/#case-and-incident-management +[2]: https://app.datadoghq.com/incidents/settings +[3]: /ko/incident_response/incident_management/setup_and_configuration/property_fields +[4]: /ko/incident_response/incident_management/setup_and_configuration/responder_types \ No newline at end of file diff --git a/hugo/content/ko/integrations/_index.md b/hugo/content/ko/integrations/_index.md index c5b40a31e5d..52eda6cc14c 100644 --- a/hugo/content/ko/integrations/_index.md +++ b/hugo/content/ko/integrations/_index.md @@ -13,19 +13,21 @@ aliases: - /ko/integrations/shoreline/ - /ko/integrations/shoreline_license/ - /ko/integrations/shoreline_software_license/ +- /ko/integrations/pingdom_v3/ +- /ko/integrations/perimeterx/ +- /ko/integrations/open-policy-agent/ +- /ko/integrations/open_policy_agent/ +- /ko/integrations/coreos/ +- /ko/integrations/ubuntu/ +- /ko/integrations/amazon-opsworks/ cascade: -- _target: - lang: en - path: /integrations/akamai_datastream_2 - aliases: - - /integrations/akamai_datastream - _target: lang: en path: /integrations/azure algolia: - category: 설명서 + category: Documentation rank: 80 - subcategory: 통합 + subcategory: Integrations tags: - azure - microsoft azure @@ -33,18 +35,18 @@ cascade: lang: en path: /integrations/kubernetes_state_core algolia: - category: 설명서 + category: Documentation rank: 60 - subcategory: 통합 + subcategory: Integrations tags: - ksm - _target: lang: en path: /integrations/google_cloud_platform algolia: - category: 설명서 + category: Documentation rank: 80 - subcategory: 통합 + subcategory: Integrations tags: - gcp - google cloud platform @@ -52,9 +54,9 @@ cascade: lang: en path: /integrations/amazon_web_services algolia: - category: 설명서 + category: Documentation rank: 80 - subcategory: 통합 + subcategory: Integrations tags: - aws - amazon web services @@ -62,96 +64,31 @@ cascade: lang: en path: /integrations/eks_fargate algolia: - category: 설명서 + category: Documentation rank: 60 - subcategory: 통합 + subcategory: Integrations tags: - eks logging - _target: lang: en - path: /integrations/win32_event_log + path: /integrations/event-viewer algolia: - category: 설명서 + category: Documentation rank: 60 - subcategory: 통합 + subcategory: Integrations tags: - event viewer - aliases: - - /integrations/eventviewer/ -- _target: - lang: en - path: /integrations/lambdatest_license - aliases: - - /integrations/lambdatest_software_license/ -- _target: - lang: en - path: /integrations/mongo - aliases: - - /integrations/mongodb/ -- _target: - lang: en - path: /integrations/rapdev_validator - aliases: - - /integrations/rapdev_dashboard_widget_pack/ -- _target: - lang: en - path: /integrations/wmi_check - aliases: - - /integrations/wmi/ -- _target: - lang: en - path: /integrations/jfrog_platform_self_hosted - aliases: - - /integrations/jfrog_platform/ -- _target: - lang: en - path: /integrations/komodor_license - aliases: - - /integrations/komodor_komodor/ - _target: lang: en - path: /integrations/stormforge_license - aliases: - - /integrations/stormforge_stormforge_license/ -- _target: - lang: en - path: /integrations/feed - aliases: - - /integrations/rss/ -- _target: - lang: en - path: /integrations/java - aliases: - - /agent/faq/jmx_integrations/ - - /agent/faq/docker-jmx/ -- _target: - lang: en - path: /integrations/amazon_elb - aliases: - - /integrations/awselb -- _target: - lang: en - path: /integrations/elastic - aliases: - - /integrations/awses -- _target: - lang: en - path: /integrations/amazon_s3 - aliases: - - /integrations/awss3 -- _target: - lang: en - path: /integrations/snowflake_web - aliases: - - /integrations/snowflake/ + path: /integrations/confluent-cloud + site_support_id: confluent_cloud_integration description: 모든 시스템, 앱, 서비스에서 데이터를 수집하세요. disable_sidebar: true -title: 통합 +title: Integrations --- +총 {{< translate key="integration_count" >}} 개 이상의 내장 Integrations. 모든 시스템, 앱, 서비스 전반을 확인하세요. -{{< translate key="integration_count" >}}개 이상의 내장 통합. 모든 시스템, 앱, 서비스를 확인하세요. - -통합이란 무엇인가요? [통합 소개][1]를 참조하세요. +Integrations란 무엇인가요? [Integrations 소개][1]를 참조하세요. {{< integrations >}} diff --git a/hugo/content/ko/llm_observability/build_with_ai/mcp_server.md b/hugo/content/ko/llm_observability/build_with_ai/mcp_server.md new file mode 100644 index 00000000000..f48654a4016 --- /dev/null +++ b/hugo/content/ko/llm_observability/build_with_ai/mcp_server.md @@ -0,0 +1,532 @@ +--- +aliases: +- /ko/llm_observability/mcp_server/ +description: Datadog MCP Server를 사용하여 AI 에이전트를 Agent Observability 트레이스 및 실험에 연결하세요. +further_reading: +- link: mcp_server + tag: 설명서 + text: Datadog MCP Server +- link: /llm_observability/improve/experiments + tag: 설명서 + text: Agent Observability 실험 설정 및 사용하기 +- link: /llm_observability/investigate + tag: 설명서 + text: Agent Observability로 애플리케이션 모니터링하기 +- link: /llm_observability/build_with_ai/claude_code_skills + tag: 가이드 + text: Claude Code 스킬로 LLM 애플리케이션 분석하기 +- link: https://www.datadoghq.com/blog/debug-and-evaluate-your-ai-app-from-your-coding-agent/ + tag: 블로그 + text: Datadog Agent Observability를 사용하여 코딩 에이전트에서 AI 앱을 디버깅하고 평가하기 +- link: https://www.datadoghq.com/blog/bits-evals/ + tag: 블로그 + text: Bits Evals로 AI 에이전트 품질 개선하기 +title: Agent Observability MCP 및 스킬 +--- +## 개요 {#overview} + +[Datadog MCP Server][1]를 사용하면 AI 에이전트가 Model Context Protocol(MCP)을 통해 [Agent Observability][2] 데이터에 액세스할 수 있습니다. `llmobs` 도구 세트는 Cursor, Claude Code 또는 OpenAI Codex와 같은 AI 기반 클라이언트에서 직접 트레이스를 검색 및 분석하고, 스팬 세부 정보와 콘텐츠를 검사하며, 실험 결과를 평가하기 위한 도구를 제공합니다. + +## 설정 {#setup} + +`llmobs` 도구 세트는 활성화된 상태에서 MCP 호환 클라이언트를 Datadog MCP Server에 연결하세요. + +
Cursor 및 VS Code 확장 프로그램 구성 등 전체 설정 지침은 Datadog MCP Server 설정을 참조하세요.
+ +### 전제 조건 {#prerequisites} + +- Agent Observability 데이터에 액세스할 수 있는 권한이 있는 Datadog 계정. +- MCP 호환 클라이언트(예: Claude Code, Codex CLI, Cursor, Gemini CLI, Kiro CLI). + +### 엔드포인트 {#endpoint} + +MCP 서버 엔드포인트는 [Datadog 사이트][5]에 따라 다릅니다. {{< ui >}}Datadog Site{{< /ui >}} 선택기를 사용하여 사이트의 엔드포인트를 표시하세요. Agent Observability 및 핵심 도구 세트를 활성화하려면 `?toolsets=llmobs,core`를 추가하세요. + +{{< site-region region="us,us3,us5,eu,ap1,ap2,uk1" >}} +선택한 사이트({{< region-param key="dd_site_name" >}})에 대한 엔드포인트: +
{{< region-param key="mcp_server_endpoint" >}}?toolsets=llmobs,core
+{{< /site-region >}} + +{{< site-region region="gov,gov2" >}} +
이 제품은 선택한 사이트({{< region-param key="dd_site_name" >}})에서 지원되지 않습니다.
+{{< /site-region >}} + +### 연결 {#connect} + +가능한 경우 원격 인증을 선택하세요. 환경에서 원격 OAuth 흐름을 차단하는 경우 로컬 바이너리 인증을 사용하세요. + +{{< tabs >}} +{{% tab "원격 인증" %}} + +{{< site-region region="us,us3,us5,eu,ap1,ap2,uk1" >}} +원격 인증은 MCP 사양의 [스트림 가능한 HTTP][1] 전송을 사용합니다. + +**Claude Code**(명령줄): + +
claude mcp add --transport http datadog-mcp "{{< region-param key="mcp_server_endpoint" >}}?toolsets=llmobs,core"
+ +**Codex CLI**(`~/.codex/config.toml`): + +
[mcp_servers.datadog]
+url = "{{< region-param key="mcp_server_endpoint" >}}"
+http_headers = { "X-Datadog-MCP-Toolsets" = "llmobs,core" }
+
+ +구성을 추가한 후 `codex mcp login datadog`을 실행하여 OAuth 흐름을 완료하세요. + +**Gemini CLI, Kiro CLI 및 기타 MCP 호환 클라이언트**: + +
{
+  "mcpServers": {
+    "datadog": {
+      "type": "http",
+      "url": "{{< region-param key="mcp_server_endpoint" >}}?toolsets=llmobs,core"
+    }
+  }
+}
+
+ +[1]: https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#streamable-http +{{< /site-region >}} + +{{< site-region region="gov,gov2" >}} +
이 제품은 선택한 사이트({{< region-param key="dd_site_name" >}})에서 지원되지 않습니다.
+{{< /site-region >}} + +{{% /tab %}} + +{{% tab "로컬 바이너리 인증" %}} + +로컬 바이너리 인증은 MCP 사양의 [stdio][2] 전송을 사용합니다. 원격 인증을 사용할 수 없는 경우 이 방법을 사용하세요. + +1. Datadog MCP Server 바이너리를 설치합니다. + + ```bash + curl -sSL https://coterm.datadoghq.com/mcp-cli/install.sh | bash + ``` + + The binary installs to `~/.local/bin/datadog_mcp_cli`. + +2. OAuth 로그인 흐름을 완료합니다. + + ```bash + datadog_mcp_cli login + ``` + +3. AI 클라이언트를 구성합니다. Claude Code의 경우, 다음을 `~/.claude.json`에 추가하고 명령 경로에서 ``을 바꿉니다 + + ```json + { + "mcpServers": { + "datadog": { + "type": "stdio", + "command": "/Users//.local/bin/datadog_mcp_cli", + "args": [], + "env": {} + } + } + } + ``` + + Alternatively, add the server with the Claude Code CLI: + + ```bash + claude mcp add datadog --scope user -- ~/.local/bin/datadog_mcp_cli + ``` + +[2]: https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#stdio +{{% /tab %}} +{{< /tabs >}} + +### API 키로 인증 {#authenticate-with-api-keys} + +MCP 서버는 기본적으로 OAuth 2.0을 사용합니다. OAuth를 사용할 수 없는 경우, Datadog [API 키 및 애플리케이션 키][6]를 `DD_API_KEY` 및 `DD_APPLICATION_KEY` HTTP 헤더로 보내세요. + +{{< site-region region="us,us3,us5,eu,ap1,ap2,uk1" >}} +
{
+  "mcpServers": {
+    "datadog": {
+      "type": "http",
+      "url": "{{< region-param key="mcp_server_endpoint" >}}?toolsets=llmobs,core",
+      "headers": {
+          "DD_API_KEY": "<YOUR_API_KEY>",
+          "DD_APPLICATION_KEY": "<YOUR_APPLICATION_KEY>"
+      }
+    }
+  }
+}
+
+{{< /site-region >}} + +{{< site-region region="gov,gov2" >}} +
이 제품은 선택한 사이트({{< region-param key="dd_site_name" >}})에서 지원되지 않습니다.
+{{< /site-region >}} + +보안을 위해 API 키와 애플리케이션 키의 범위를 필수 권한만 있는 [서비스 계정][7]으로 제한하세요. + +## Agent 스킬 {#agent-skills} + +Agent 스킬은 일반적인 Agent Observability 워크플로를 자동화하는 AI 코딩 에이전트용으로 사전 구축된 지침 세트입니다. `agent-observability` 스킬 세트는 [Datadog agent-skills][8] 저장소에서 사용할 수 있습니다. 세션 분류, 장애 진단, 실험 분석, `ddtrace.llmobs` SDK를 사용한 실험 코드 생성, 실시간 운영 데이터에 대한 평가자 부트스트래핑을 위한 6가지 스킬을 제공합니다. + +### 설치 {#install} + +다음 명령어로 `agent-observability` 스킬을 설치하세요. + +```shell +npx skills add datadog-labs/agent-skills/agent-observability --full-depth -y +``` + +이 스킬을 사용하려면 `llmobs` MCP 도구 세트가 연결되어 있어야 합니다. 아직 연결하지 않았다면 다음을 실행하세요. + +{{< site-region region="us,us3,us5,eu,ap1,ap2,uk1" >}} +
claude mcp add --scope user --transport http "datadog-llmo-mcp" \
+  '{{< region-param key="mcp_server_endpoint" >}}?toolsets=llmobs,core'
+{{< /site-region >}} + +{{< site-region region="gov,gov2" >}} +
이 제품은 선택한 사이트({{< region-param key="dd_site_name" >}})에서 지원되지 않습니다.
+{{< /site-region >}} + +두 명령어를 모두 실행한 후 Claude Code를 다시 시작하세요. + +### 사용 가능한 스킬 {#available-skills} + +| 스킬 | 호출 방법 | 기능 | +|-------|-------------|-------------| +| Session classify | `/agent-observability-session-classify` | 세션, 트레이스 또는 배치에서 사용자 의도가 충족되었는지 분류 | +| Trace RCA | `/agent-observability-trace-rca` | 실패한 운영 트레이스에 대한 근본 원인 분석 | +| Experiment analyzer | `/agent-observability-experiment-analyzer` | LLM 실험 결과 분석 및 비교 | +| Experiment Python codegen | `/agent-observability-experiment-py-bootstrap` | SDK를 사용하여 Python 실험 코드 생성`ddtrace.llmobs` 앱을 내부적으로 검사하여 실제 `task_fn`을 연결하고, `.env` 자격 증명을 자동 검색하며, 평가자 선택을 지시하는 자유 형식의 `--purpose`를 허용| +| Eval bootstrap | `/agent-observability-eval-bootstrap` | 평가자 코드 생성, 온라인 LLM 판정 평가자 게시 또는 실험에 사용할 데이터세트로 트레이스 샘플링 | +| Eval pipeline | `/agent-observability-eval-pipeline` | 운영 트레이스부터 평가자, 데이터세트, 실험 및 분석까지 이어지는 6단계 가이드 파이프라인입니다. `--stop-after`를 사용하여 조기 중단하고, `--start-at` |을 사용하여 중간부터 재개하세요. + +#### 세션 분류 {#session-classification} + +`/agent-observability-session-classify`는 주어진 상호 작용에서 사용자 의도가 충족되었는지 분류합니다. 최대 3개의 신호 소스: Agent Observability 트레이스, RUM 행동 데이터, Audit Trail 이벤트를 활용합니다. 이 스킬은 뒷받침 근거와 함께 `yes / partial / no` 판정을 반환합니다. 추가적인 신호 소스가 늘어날 때마다 신뢰도가 향상됩니다. + +``` +/agent-observability-session-classify session_id= +/agent-observability-session-classify trace_id= +/agent-observability-session-classify ml_app=my-chatbot --timeframe now-7d +``` + +#### 트레이스 근본 원인 분석 {#trace-root-cause-analysis} + +`/agent-observability-trace-rca`는 LLM 애플리케이션이 왜 좋지 않은 결과를 생성하는지 진단합니다. 가장 강력한 가용 신호(LLM 판정 평가 판정, 런타임 오류 또는 구조적 이상)를 기반으로 분석 모드를 선택하고 구조화된 RCA 보고서를 컴파일합니다. 보고서에는 실패 분류와 트레이스 증거에 기반한 구체적인 `BEFORE` / `AFTER` 수정 제안이 포함됩니다. + +Claude Code가 코드베이스에 액세스할 수 있으면 이 스킬은 관련 소스 파일을 검색하고 인라인으로 diff를 제안할 수 있습니다. + +``` +/agent-observability-trace-rca ml_app=my-chatbot +/agent-observability-trace-rca ml_app=my-chatbot eval_name=faithfulness --timeframe now-24h +``` + +#### 평가자 부트스트랩 {#evaluator-bootstrap} + +`/agent-observability-eval-bootstrap`은 운영 트레이스를 분석하고 관찰된 실패 모드를 대상으로 하는 평가자 제품군을 제안합니다. 오프라인 실험을 위한 : Python `BaseEvaluator` / `LLMJudge` 클래스, 프레임워크에 구애받지 않는 JSON 사양, Datadog에 직접 게시되는 온라인 LLM 판정 평가자, 또는 `--emit-dataset `를 통해 운영 트레이스에서 샘플링되고 `DatasetRecordRaw[]`를 위해 형성된 `LLMObs.create_dataset(records=...)` JSON의 네 가지 아티팩트 중 하나를 출력합니다. dataset-emit 모드는 평가자 워크플로를 완전히 건너뛰며, 실험 입력으로 사용하기에 적합한 데이터세트를 생성합니다. + +``` +/agent-observability-eval-bootstrap ml_app=my-chatbot +/agent-observability-eval-bootstrap ml_app=my-chatbot --publish +/agent-observability-eval-bootstrap ml_app=my-chatbot --data-only +/agent-observability-eval-bootstrap ml_app=my-chatbot --emit-dataset ./datasets/my_chatbot_seed.json +``` + +#### Experiment analyzer {#experiment-analyzer} + +`/agent-observability-experiment-analyzer`는 실험 결과를 검색하고 후보와 기준 간에 무엇이 변경되었는지: 어떤 메트릭이 개선되었고 어떤 메트릭이 퇴보했으며 후보가 어디에서 성능이 저조했는지 알려줍니다. + +``` +/agent-observability-experiment-analyzer experiment_id= +/agent-observability-experiment-analyzer experiment_id= baseline_id= +``` + +#### Python SDK로 실험 코드 생성 {#generate-experiment-code-with-the-python-sdk} + +`/agent-observability-experiment-py-bootstrap`은 `ddtrace.llmobs` SDK를 사용하고 표준 참조 노트북 스타일과 일치하는 독립형 `.py` 스크립트 또는 Jupyter `.ipynb` 노트북을 생성합니다. + +데이터세트는 로컬 `DatasetRecordRaw[]` JSON(파일에 인라인됨), CSV(`LLMObs.create_dataset_from_csv`를 통해 런타임에 로드됨), 이름별 기존 Datadog 데이터세트(`LLMObs.pull_dataset`) 또는 기본적으로 작은 인라인 3개 레코드 샘플일 수 있습니다. 생성된 모든 실험에는 `generated_by=claude-code` 및 `config`와 `tags` 모두에서 확인된 `--purpose`가 태그로 지정됩니다. + +``` +/agent-observability-experiment-py-bootstrap --purpose "validate output accuracy" +/agent-observability-experiment-py-bootstrap --purpose "test tool selection" --dataset ./data/qa.json +/agent-observability-experiment-py-bootstrap --dataset-name --project-name +/agent-observability-experiment-py-bootstrap --task-source mymodule.handlers:respond +``` + +#### 엔드투엔드 평가 파이프라인 {#end-to-end-eval-pipeline} + +`/agent-observability-eval-pipeline`은 운영 트레이스부터 평가자, 데이터세트, 실험, 분석까지 설명이 포함된 6단계의 과정을 거치며, 다음 각 단계 사이에 사용자 체크포인트가 있습니다. + +1. **ml_app 트레이스 분류**: `ml_app`에서 최근 트레이스를 샘플링하고 분류합니다. +2. **근본 원인 분석**: 실패한 트레이스가 왜 실패하는지 진단합니다. +3. **부트스트랩 평가자**: 관찰된 실패 모드를 대상으로 하는 평가자 제품군을 제안합니다. +4. **데이터세트 생성 + 게시**: input/expected_output 쌍을 `DatasetRecordRaw[]` JSON으로 추출하고 프로젝트(필요 시 생성) 아래의 Datadog에 게시합니다. +5. **실험 생성 + 실행**: 데이터세트를 가져와 앱의 작업 함수를 연결하는 실행 가능한 `.py` 또는 `.ipynb`를 내보낸 다음, 이를 엔드투엔드로 실행하고 `experiment.url`을 캡처합니다. codegen과 실행 사이에 인페이스 검토 비트(`run` / `edit` / `stop`)가 있어 실행 전에 생성된 파일을 검사할 수 있습니다. +6. **실험 분석**: 메트릭 분석 및 권장 사항이 포함된 분석 보고서를 생성합니다. + +각 단계에는 표준 약칭이 있으며, `--start-at` 및 `--stop-after`에서도 동일한 값을 허용합니다. 아래 표에는 파이프라인이 호출할 수 있는 MCP 도구와 각 단계별 논리에 대한 한 줄 설명이 나열되어 있습니다. + +| # | 단계 제목 | 스테이지 이름 | 호출된 MCP 도구 | 요약 | +|---|-------------|----------------------------------------------------------------------------------------|------------------|---------| +| 1 | ml_app 트레이스 분류 | `classify` | `search_llmobs_spans` | `ml_app`에 대한 최근 루트 스팬을 샘플링하고, 각각을 성공/부분/실패로 분류하며, 공통 패턴을 표시합니다. | +| 2 | 근본 원인 분석 | `rca` | `search_llmobs_spans` | 1단계에서 실패한 스팬에 대한 전체 트레이스를 가져오고 트레이스 트리를 탐색하여 각 실패를 루트 스팬 및 실패 모드에 귀속시킵니다. | +| 3 | 부트스트랩 평가자 | `eval-bootstrap` | 없음(2단계 보고서에 대한 로컬 추론). `--publish`가 설정된 경우 온라인 LLM-판정 평가자를 게시하기 위한 선택적 Datadog API 호출 | Python 평가자 제품군(`sdk_code`), 프레임워크 독립적 JSON 사양(`data_only`)을 내보내거나 온라인 평가자를 게시(`publish`)합니다. | +| 4 | 데이터세트 생성 및 게시 | `dataset` | `search_llmobs_spans`(샘플링용) 및 ddtrace SDK(MCP 아님)를 통한 게시용 `LLMObs.create_dataset()` | 루트 스팬을 샘플링하고, input/expected_output 쌍을 추출하고, PII를 삭제하고, 로컬 JSON을 작성한 다음 Datadog에 게시합니다. | +| 5 | 실험 생성 및 실행 | `experiment` | `list_llmobs_evals`(원샷 시작 비콘 — 연결성 + 텔레메트리). 런타임은 ddtrace SDK를 사용합니다. | 앱을 검사하여 LLM 호출 지점을 찾고, 독립형 `.py` 또는 `.ipynb`를 생성하여 실제 진입점에 `task_fn`을 연결한 후 실행합니다. | +| 6 | 실험 분석 | `analyze` | `get_llmobs_experiment_summary`, `get_llmobs_experiment_metric_values`, `list_llmobs_experiment_events`, `get_llmobs_experiment_event`, `get_llmobs_experiment_dimension_values` | 최상위 메트릭, 레코드별 점수, 세그먼트 차원 및 드릴다운 이벤트를 가져와 구조화된 분석 보고서를 종합합니다. | + +`stop`에서 언제든지 깔끔하게 중단하고, `--start-at `으로 나중에 재개할 수 있어 다시 실행할 필요가 없습니다. 기존의 3단계 평가 전용 동작을 유지하려면 `--stop-after eval-bootstrap`을 전달하세요. + +``` +/agent-observability-eval-pipeline my-chatbot --project-name my-chatbot +/agent-observability-eval-pipeline my-chatbot --stop-after eval-bootstrap # classic 3-phase +/agent-observability-eval-pipeline my-chatbot --start-at experiment # resume mid-flow +/agent-observability-eval-pipeline my-chatbot --start-at analyze --experiment-id +``` + +이러한 스킬에 대한 전체 가이드와 권장되는 엔드투엔드 워크플로는 [Claude Code 스킬로 LLM 애플리케이션 분석하기][9]를 참조하세요. + +## 사용 사례 {#use-cases} + +Agent Observability MCP 도구는 다음을 위한 AI 지원 워크플로를 활성화합니다. + +- **에이전트 실행 디버깅**: ML 앱, 오류 상태 또는 사용자 지정 태그별로 트레이스를 검색한 다음 스팬 계층 구조와 콘텐츠를 검사하여 실패를 식별합니다. +- **트레이스 구조 분석**: 트레이스의 전체 스팬 트리를 시각화하여 에이전트, LLM, 도구 및 검색이 어떻게 상호 작용하는지 이해합니다. +- **에이전트 루프 조사**: 에이전트의 단계별 실행 루프를 검토하여 의사 결정 및 도구 호출 패턴을 파악합니다. +- **실험 평가**: 실험 메트릭에 대한 요약 통계를 가져오고, 디멘션 세그먼트 전반의 결과를 비교하며, 개별 이벤트를 검사합니다. +- **실험 생성**: 모델 추론을 실행하지 않고 실험 메타데이터(프로젝트, 데이터세트, 설명, 구성)를 기록하기 위해 `create_llmobs_experiment`로 새 실험 객체를 등록합니다. `submit_llmobs_experiment_events`로 이후 평가 메트릭을 첨부합니다. +- **실험 패턴 발견**: 메트릭 성능별로 실험 이벤트를 필터링하고 정렬하여 성능이 가장 우수한 케이스와 가장 저조한 케이스를 찾습니다. +- **평가자 관리**: ML 애플리케이션 또는 전체 조직 전반의 평가자 구성을 나열, 검사, 생성, 업데이트 및 삭제합니다. +- **패턴 탐색**: 패턴 구성을 나열하고, 실행 상태를 검사하며, 발견된 주제를 계층 구조를 탐색하여 사용자가 무엇을 묻고 트래픽이 어떻게 분산되는지 파악합니다. +- **데이터세트 관리**: 프로젝트와 데이터세트 목록을 확인하고, 데이터세트 레코드를 탐색 및 검사하며, 실험에 사용할 데이터세트에 새 레코드를 추가합니다. + +## 사용 가능한 도구 {#available-tools} + +`llmobs` 도구 세트에는 다음 도구가 포함되어 있습니다. + +### 트레이스 및 스팬 도구 {#trace-and-span-tools} + +`search_llmobs_spans` +: 필터 또는 원시 쿼리와 일치하는 스팬을 검색합니다. + +`get_llmobs_trace` +: 스팬 종류별 스팬 수, 오류 지표, 총 지속 시간을 포함하여 트레이스의 전체 구조를 스팬 계층 트리로 가져옵니다. + +`get_llmobs_span_details` +: 타이밍, 오류 정보, LLM 세부 정보(모델, 토큰 수), 메트릭 및 평가를 포함하여 하나 이상의 스팬에 대한 상세 메타데이터를 가져옵니다. + +`get_llmobs_span_content` +: 선택적 JSONPath 추출을 사용하여 스팬 필드(입력, 출력, 메시지, 문서 또는 메타데이터)의 실제 내용을 검색합니다. + +`find_llmobs_error_spans` +: 전파 컨텍스트가 있는 트레이스에서 모든 오류 스팬을 찾아 스팬 종류별로 그룹화하고 오류 메시지 및 스택 트레이스를 확인합니다. + +`expand_llmobs_spans` +: `get_llmobs_trace`가 축소된 노드를 반환할 때 점진적인 트리 탐색을 위해 특정 스팬의 하위 항목을 로드합니다. + +`get_llmobs_agent_loop` +: 에이전트의 실행 루프를 시간순으로 조회하여 각 단계(LLM 호출, 도구 호출, 결정)를 순서대로 표시합니다. + +### 실험 도구 {#experiment-tools} + +`create_llmobs_experiment` +: 프로젝트에 새로운 Agent Observability 실험 객체를 생성합니다. 모델 추론을 실행하지 않고 이벤트와 메트릭을 보고할 수 있도록 실험을 기록합니다. `project_id` 및 `experiment_name`이 필요합니다. 생성된 `experiment_id` 및 확인된 이름을 반환합니다. `submit_llmobs_experiment_events`를 사용하여 평가 메트릭을 첨부하거나 `update_llmobs_experiment`를 사용하여 속성을 변경하세요. + +`get_llmobs_experiment_summary` +: 모든 평가 메트릭에 대해 미리 계산된 통계가 포함된 상위 수준의 실험 요약을 가져옵니다. 다른 실험 도구를 사용하기 전에 여기서 시작하세요. + +`list_llmobs_experiment_events` +: 디멘션 또는 메트릭별로 필터링하고 메트릭 값별로 정렬하여 실험 이벤트를 나열합니다. + +`get_llmobs_experiment_event` +: 입력, 출력, 예상 출력, 모든 메트릭 및 디멘션을 포함하여 단일 실험 이벤트에 대한 전체 세부 정보를 가져옵니다. + +`get_llmobs_experiment_metric_values` +: 특정 평가 메트릭에 대한 통계 분석을 가져오며, 비교를 위해 디멘션별로 선택적으로 세분화할 수 있습니다. + +`get_llmobs_experiment_dimension_values` +: 유효한 필터 및 세그먼트 값을 찾는 데 유용한 개수가 포함된 디멘션의 고유 값을 가져옵니다. + +### 평가자 도구 {#evaluator-tools} + +`list_llmobs_evals` +: 모든 ML 애플리케이션에 구성된 모든 LLM 판정 평가자를 나열합니다. 각 평가자의 이름, ml_app 및 활성화 상태를 반환합니다. + +`list_llmobs_evals_by_ml_app` +: 특정 ML 애플리케이션에 대해 구성된 모든 LLM 판정 평가자를 나열합니다. + +`get_llmobs_evaluator` +: 이름으로 LLM 판정 평가자 구성을 검색하며, 대상(ml_app, 샘플링, 필터), LLM 공급자 및 평가자 프롬프트 템플릿을 포함합니다. + +`create_or_update_llmobs_evaluator` +: LLM 판정 평가자 구성을 생성하거나 업데이트합니다. 특정 ML 애플리케이션 및 필요에 따라 필터 또는 샘플링 비율을 대상으로 하며, 평가자의 모델 및 프롬프트 템플릿이 각 스팬의 점수를 매기는 방법을 정의합니다. + +`delete_llmobs_evaluator` +: 이름으로 LLM 판정 평가자 구성을 삭제합니다. + +### 프로젝트 및 데이터세트 도구 {#project-and-dataset-tools} + +`list_llmobs_projects` +: 조직의 모든 Agent Observability 실험 프로젝트 목록을 생성 날짜순(최신순)으로 나열합니다. 각 프로젝트의 `id`, `name` 및 타임스탬프와 페이지 매김 필드(`next_cursor`, `truncated`)를 반환합니다. 프로젝트 이름과 ID를 미리 알지 못할 때 이를 사용하여 찾으세요. + +`get_llmobs_project` +: ID 또는 이름으로 Agent Observability 실험 프로젝트를 조회합니다. 데이터세트 도구를 호출하기 전에 `project_id` UUID를 확인하려면 이를 사용하세요. + +`list_llmobs_datasets` +: ID 또는 이름 필터를 필요에 따라 사용하여 프로젝트 내의 데이터세트 목록을 나열합니다. 데이터세트 메타데이터 및 페이지 매김 필드를 반환합니다. `get_llmobs_dataset_records` 또는 `add_llmobs_dataset_records` 전에 이를 사용하세요. 해당 도구는 데이터세트 UUID가 필요합니다. + +`get_llmobs_dataset_records` +: 구조화된 미리보기와 스키마 요약으로 데이터세트 레코드를 읽습니다. 임의의 JSON 필드(`input`, `expected_output`, `metadata`)를 읽을 수 있는 미리보기 형태로 구성합니다. 새 레코드를 구성하기 전에 `compute_schema=true`을 사용하여 레코드 구조의 유형 인식 스케치를 가져오세요. + +`get_llmobs_full_dataset_records` +: 최대 3개의 특정 레코드를 전체 내용이 잘리지 않은 상태로 가져옵니다. `get_llmobs_dataset_records`로 레코드 ID를 찾은 후 이를 사용하여 개별 레코드를 자세히 검사하세요. + +`add_llmobs_dataset_records` +: 미리보기 후 확인하는 2단계 흐름을 사용하여 데이터세트에 레코드를 생성합니다. `confirmed=false`를 호출하여 계획된 쓰기 작업을 미리 본 다음, 사용자 승인 후 `confirmed=true`를 호출하여 커밋하세요. + +### 패턴 도구 {#patterns-tools} + +`list_llmobs_pattern_configs` +: 조직의 모든 패턴 구성을 나열합니다. 각 구성의 `id`, `name`, `evp_query`, 샘플링 설정 및 타임스탬프를 반환합니다. `config_id`를 찾으려면 여기서 시작하세요. + +`get_llmobs_pattern_config` +: 조직에서 가장 최근에 수정된 패턴 구성을 가져옵니다. + +`get_llmobs_pattern_run_status` +: 구성에 대한 가장 최근 패턴 실행의 상태 및 활동별 진행 상황을 가져옵니다. 주제를 읽기 전에 클러스터가 실행 중인지, 완료되었는지, 또는 실패했는지 검사하세요. + +`list_llmobs_pattern_runs` +: 구성에 대해 완료된 모든 패턴 실행을 최신순으로 나열합니다. 각 실행의 `id`, `status`, 타임스탬프 및 사용된 `config_snapshot`을 반환합니다. + +`get_llmobs_patterns` +: 패턴 실행으로 발견된 주제를 계층 구조를 가져옵니다. 주제를 계층으로 구성되며, 각 계층에는 `name`, `description` 및 `point_count`가 있습니다. 가장 최근에 완료된 실행을 읽으려면 `run_id`를 생략하세요. + +`get_llmobs_patterns_with_points` +: 각 리프 주제에 스팬 ID가 인라인으로 포함된 실행의 주제를 계층 구조를 가져옵니다. 스팬별 지속 시간, 비용, 토큰 수 및 평가도 포함하려면 `include_metrics=true`를 설정하세요. + +`get_llmobs_pattern_points` +: 단일 주제에 할당된 클러스터 포인트(개별 스팬)를 커서 기반으로 페이지 지정하여 가져옵니다. 각 포인트에는 `span_id`, `session_id` 및 스팬 입력 미리보기가 포함됩니다. 페이징을 계속하려면 `next_page_token`을 `page_token`으로 전달하세요. + +### 주석 대기열 도구 {#annotation-queue-tools} + +`list_llmobs_annotation_queues` +: 조직의 모든 [주석 대기열][10]을 나열합니다. + +`create_llmobs_annotation_queue` +: 트레이스에 대한 사람의 검토를 위해 주석 대기열을 생성하며, 생성 시 선택적으로 라벨 스키마를 정의합니다. + +`update_llmobs_annotation_queue` +: 주석 대기열의 이름, 설명 또는 라벨 스키마를 업데이트합니다. + +`delete_llmobs_annotation_queue` +: 주석 대기열을 삭제합니다. + +`get_llmobs_annotation_label_schema` +: 주석 대기열에 대한 레이블 스키마를 가져옵니다. 이 스키마는 검토 중에 주석 작성자가 적용하는 레이블을 정의합니다. + +`update_llmobs_annotation_label_schema` +: 주석 대기열에 대한 레이블 스키마를 생성하거나 교체합니다. + +`add_llmobs_annotation_queue_interactions` +: 검토를 위해 하나 이상의 트레이스를 주석 대기열에 추가합니다. + +`delete_llmobs_annotation_queue_interactions` +: 주석 대기열에서 트레이스를 제거합니다. + +`get_llmobs_annotated_interactions` +: 주석 대기열의 주석이 달린 상호 작용과 주석 작성자가 적용한 레이블을 가져옵니다. + +`get_llmobs_annotations_by_content_ids` +: 콘텐츠 ID를 기준으로 특정 트레이스 또는 세션에 적용된 주석을 가져옵니다. + +`upsert_llmobs_annotations` +: 대기열의 상호 작용에 적용된 주석을 생성하거나 업데이트합니다. + +`delete_llmobs_annotations` +: 대기열의 상호 작용에 적용된 주석을 삭제합니다. + +## 권장 워크플로 {#recommended-workflows} + +### 트레이스 분석 {#trace-analysis} + +1. **검색**: `search_llmobs_spans`를 사용하여 ML 앱, 상태, 스팬 종류 또는 사용자 지정 태그별로 트레이스를 조회합니다. +2. **시각화**: `get_llmobs_trace`를 사용하여 전체 스팬 계층 구조를 확인합니다. +3. **검사**: `get_llmobs_span_details`를 사용하여 특정 스팬에 대한 메타데이터, 타이밍 및 평가를 확인합니다. +4. **콘텐츠 읽기**: `get_llmobs_span_content`를 사용하여 실제 I/O, 메시지 또는 문서를 검색합니다. +5. **오류 디버깅**: `find_llmobs_error_spans`를 사용하여 전파 컨텍스트가 포함된 트레이스의 모든 오류를 확인합니다. +6. **확장**: `expand_llmobs_spans`를 사용하여 더 깊이 탐색하기 위해 축소된 스팬의 하위 스팬을 로드합니다. +7. **Agent 검토**: `get_llmobs_agent_loop`를 사용하여 Agent 스팬의 단계별 실행 흐름을 확인합니다. + +### 실험 분석 {#experiment-analysis} + +1. **요약**: `get_llmobs_experiment_summary`를 사용하여 전체 통계를 확인하고 사용 가능한 메트릭 및 디멘션을 확인합니다. +2. **이벤트 탐색**: `list_llmobs_experiment_events`를 사용하여 디멘션별로 필터링하거나 메트릭별로 정렬하여 관심 있는 이벤트를 찾습니다. +3. **이벤트 검사**: `get_llmobs_experiment_event`를 사용하여 특정 이벤트에 대한 전체 세부정보를 조회합니다. +4. **메트릭 분석**: `get_llmobs_experiment_metric_values`를 사용하여 백분위수 분포, 참/거짓 비율을 확인하거나 디멘션 세그먼트 간에 비교합니다. +5. **차원 발견**: `get_llmobs_experiment_dimension_values`를 사용하여 유효한 필터 및 세그먼트 값을 찾습니다. + +### 데이터세트 관리 {#dataset-management} + +1. **프로젝트 찾기**: `list_llmobs_projects`를 사용하여 프로젝트를 탐색합니다. 각 결과에는 후속 호출에 필요한 `id` UUID가 포함되어 있습니다. 프로젝트 이름은 알지만 UUID를 모르는 경우 `get_llmobs_project`를 사용하여 직접 확인합니다. +2. **데이터세트 찾기**: `list_llmobs_datasets`를 `project_id`와 함께 사용하여 데이터세트를 나열하고 해당 UUID를 가져옵니다. +3. **데이터 이해**: `get_llmobs_dataset_records`를 `compute_schema=true`와 함께 사용하여 레코드를 탐색하고, 읽거나 쓰기 전에 필드의 유형 스케치를 확인합니다. +4. **특정 레코드 읽기**: `get_llmobs_full_dataset_records`를 사용하여 ID별로 최대 3개의 레코드에 대한 전체 콘텐츠를 검색합니다. +5. **레코드 추가**: `add_llmobs_dataset_records`를 `confirmed=false`와 함께 사용하여 쓰기를 미리 본 다음, 사용자 승인 후 `confirmed=true`를 사용합니다. + +### 패턴 분석 {#patterns-analysis} + +1. **구성 나열**: `list_llmobs_pattern_configs`를 사용하여 사용 가능한 패턴 구성과 해당 `config_id` 값을 찾습니다. +2. **실행 상태 검사**: `get_llmobs_pattern_run_status`를 사용하여 가장 최근 실행이 완료되었는지 확인합니다. +3. **주제를 읽기**: `get_llmobs_patterns`를 사용하여 이름, 설명, 일관성 점수가 포함된 전체 주제를 계층 구조를 가져옵니다. +4. **스팬 검사**: `get_llmobs_patterns_with_points`를 사용하여 스팬 ID가 인라인된 주제를 가져오거나, `get_llmobs_pattern_points`를 사용하여 특정 주제의 스팬을 페이지별로 확인합니다. +5. **스팬 콘텐츠 분석**: 이전 단계의 `span_id` 값을 `get_llmobs_span_details` 또는 `get_llmobs_span_content`와 함께 사용하여 주제 내 개별 스팬의 실제 입력, 출력 및 메타데이터를 검사합니다. +6. **과거 실행 탐색**: `list_llmobs_pattern_runs`를 사용하여 과거 실행을 확인하고 특정 `run_id`를 전달하여 시간 경과에 따른 주제 분포를 비교합니다. + +## 프롬프트 예시 {#example-prompts} + +연결 후 다음과 같은 프롬프트를 시도해 보세요. + +- 지난주 내 `customer-support-bot` 앱에 대한 오류 트레이스를 검토해 줘. 가장 일반적인 실패 패턴을 요약하고, 발생 빈도를 알려주고, 무엇을 먼저 수정할지 추천해 줘. +- 평가에서 품질이 낮다고 표시된 내 Agent의 응답 트레이스를 찾아 줘. 입력과 출력을 살펴본 다음, 응답 품질을 개선하기 위해 시스템 프롬프트에 적용할 구체적인 변경 사항을 제안해 줘. +- 내 앱의 최근 에이전트 트레이스를 살펴보고 에이전트가 필요 이상으로 루프를 돌았던 사례를 찾아 줘. 각 단계에서의 의사결정을 분석하고 불필요한 도구 호출을 줄이기 위해 도구 설명을 개선하는 방법을 제안해 줘. +- 사용자가 잘못된 응답을 보고했어. 트레이스 ID는 `trace-123`이야. 무슨 일이 있었는지 정확히 설명해 줘. 사용자가 무엇을 물어보았는지, Agent가 각 단계에서 무엇을 했는지, 그리고 어디에서 문제가 발생하였는지 알려 줘. 코드 수정안을 제안해 줘. +- 실험 `exp-456`을 분석하고 평가 점수별로 가장 성능이 낮은 디멘션의 마크다운 표를 생성해 줘. 성능이 어디서 왜 저하되는지 이해하는 데 도움이 되는 다른 관련 열을 포함해. +- 실험 `exp-123`(기준)과 실험 `exp-456`을 비교해 줘. 무엇이 개선되었고, 무엇이 퇴보하였는지, 그리고 그 정도가 어느 정도인지를 요약해 줘. 변경 사항을 배포할 가치가 있는지 말해 줘. +- 실험 `exp-456`을 요약하고 점수가 가장 낮은 이벤트 상위 5개를 식별해 줘. 각 이벤트에 대해 입력, 출력, 그리고 실패한 평가 항목을 보여 줘. +- 내 프로젝트 `my-chatbot-project`에 'prompt-v2-test'라는 새 실험을 만들고, 메트릭을 첨부할 수 있도록 실험 ID를 반환해 줘. +- 내 `my-project` 프로젝트의 데이터세트를 나열하고, `qa-golden-set`이라는 데이터세트의 레코드 샘플을 스키마와 함께 보여 줘. +- 새로운 테스트 케이스가 포함된 CSV 파일이 있어. 이 케이스들을 `qa-golden-set` 데이터세트에 `my-project`의 새 버전으로 추가해 줘. 먼저 미리보기를 보여 줘. + +## 다른 Datadog 도구와 결합하기 {#combine-with-other-datadog-tools} + +설정 URL에 포함된 `core` 도구 세트를 통해 AI 에이전트가 Agent Observability 분석과 자연스럽게 연동되는 추가 Datadog 도구에 액세스할 수 있습니다. + +### 분석을 Datadog Notebooks로 내보내기 {#export-analysis-to-datadog-notebooks} + +`core` 도구 세트에는 `create_datadog_notebook` 및 `edit_datadog_notebook`이 포함되어 있어 AI 에이전트가 분석 결과에서 직접 [Datadog Notebooks][3]를 생성할 수 있습니다. 에이전트 채팅에서 얻은 분석 결과를 트레이스 및 실험과 함께 Datadog에 저장되는 협업 및 공유 가능한 노트북으로 내보낼 수 있습니다. + +다음과 같은 프롬프트를 시도해 보세요. + +- 실험 `exp-456`을 분석하고, 성능이 가장 낮은 차원을 식별한 다음, 평가 점수별로 분류된 요약 보고서를 Datadog 노트북으로 내보내 줘. +- 지난 일주일 동안의 `customer-support-bot`에 대한 오류 트레이스를 검토하고, 일반적인 실패 패턴과 권장 수정 사항을 포함하여 분석 결과가 담긴 Datadog 노트북을 생성해 줘. + +Notebooks는 비교 차트나 사분면 플롯과 같이 표준 Datadog 위젯 이외의 맞춤형 시각화를 위해 기본적으로 [Mermaid 다이어그램][4]도 렌더링합니다. 다음과 같은 프롬프트를 시도해 보세요. + +- 실험 `exp-456`을 분석하고, 각 프롬프트 버전 간의 `accuracy` 점수를 비교한 다음, 각 버전의 평균 점수를 나타내는 Mermaid 막대 차트가 포함된 Datadog 노트북으로 결과를 내보내 줘. +- 실험 `exp-456`을 분석하고, 한 축에는 `relevance`, 다른 축에는 `accuracy`를 사용하여 각 프롬프트 버전을 Mermaid 사분면 차트에 표시하는 Datadog 노트북을 내보내 줘. 두 디멘션 모두에서 성능이 저조한 버전을 식별해 줘. + +## 추가 자료 {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ko/mcp_server/setup/ +[2]: /ko/llm_observability/ +[3]: /ko/notebooks/ +[4]: /ko/notebooks/guide/build_diagrams_with_mermaidjs/ +[5]: /ko/getting_started/site/ +[6]: /ko/account_management/api-app-keys/ +[7]: /ko/account_management/org_settings/service_accounts/ +[8]: https://github.com/datadog-labs/agent-skills +[9]: /ko/llm_observability/build_with_ai/claude_code_skills +[10]: /ko/llm_observability/investigate/annotation_queues \ No newline at end of file diff --git a/hugo/content/ko/llm_observability/guide/monitor_proxy_services.md b/hugo/content/ko/llm_observability/guide/monitor_proxy_services.md new file mode 100644 index 00000000000..c90ebd47b8e --- /dev/null +++ b/hugo/content/ko/llm_observability/guide/monitor_proxy_services.md @@ -0,0 +1,188 @@ +--- +aliases: +- /ko/llm_observability/trace_proxy_services/ +description: Agent Observability를 사용하여 프록시 또는 게이트웨이 서비스를 거치는 LLM 호출을 전체 엔드투엔드 추적의 + 일부로서 추적하는 방법을 알아보세요. +title: 프록시 서비스 추적 +--- +## 개요 {#overview} + +전통적인 애플리케이션과 마찬가지로, LLM 애플리케이션은 여러 마이크로서비스에 걸쳐 있을 수 있습니다. Agent Observability를 사용하면 이러한 서비스 중 하나가 LLM 프록시 또는 게이트웨이인 경우, 전체 엔드투엔드 추적 내에서 LLM 호출을 추적하여 서비스 전반의 전체 요청 경로를 캡처할 수 있습니다. + +## 프록시 또는 게이트웨이 서비스에 대해 Agent Observability 활성화{#enabling-agent-observability-for-a-proxy-or-gateway-service} + +여러 ML 애플리케이션이 사용하는 프록시 또는 게이트웨이 서비스에 Agent Observability를 활성화하려면 ML 애플리케이션 이름을 지정하지 않고 구성할 수 있습니다. 대신 서비스 이름을 설정하세요. 이를 통해 [Agent Observability 내에서 해당 프록시 또는 게이트웨이 서비스에 특정한 스팬을 필터링](#observing-llm-gateway-and-proxy-services)할 수 있습니다. + +{{< tabs >}} +{{% tab "Python" %}} + +```python +# proxy.py +from ddtrace.llmobs import LLMObs + +LLMObs.enable(service="chat-proxy") + +# proxy-specific logic, including guardrails, sensitive data scans, and the LLM call +``` + +{{% /tab %}} +{{% tab "Node.js" %}} + +```javascript +// proxy.js +const tracer = require('dd-trace').init({ + llmobs: true, + service: "chat-proxy" +}); +const llmobs = tracer.llmobs; + +// proxy-specific logic, including guardrails, sensitive data scans, and the LLM call +``` + +{{% /tab %}} +{{< /tabs >}} + + +LLM 프록시 또는 게이트웨이로 요청을 보내는 ML 애플리케이션을 오케스트레이션하는 서비스가 있는 경우, ML 애플리케이션 이름으로 Agent Observability를 활성화하세요. + +{{< tabs >}} +{{% tab "Python" %}} + +```python +# application.py +from ddtrace.llmobs import LLMObs +LLMObs.enable(ml_app="my-ml-app") + +import requests + +if __name__ == "__main__": + with LLMObs.workflow(name="run-chat"): + # other application-specific logic - (such as RAG steps and parsing) + + response = requests.post("http://localhost:8080/chat", json={ + # data to pass to the proxy service + }) + + + # other application-specific logic handling the response +``` + +{{% /tab %}} +{{% tab "Node.js" %}} + +```javascript +// application.js +const tracer = require('dd-trace').init({ + llmobs: { + mlApp: 'my-ml-app' + } +}); +const llmobs = tracer.llmobs; + +const axios = require('axios'); + +async function main () { + llmobs.trace({ name: 'run-chat', kind: 'workflow' }, async () => { + // other application-specific logic - (such as RAG steps and parsing) + + // wrap the proxy call in a task span + const response = await axios.post('http://localhost:8080/chat', { + // data to pass to the proxy service + }); + + // other application-specific logic handling the response + }); +} + +main(); +``` + +{{% /tab %}} +{{< /tabs >}} + +LLM 애플리케이션이 프록시 또는 게이트웨이 서비스에 요청을 보내면, Agent Observability SDK가 원래 LLM 애플리케이션의 ML 애플리케이션 이름을 자동으로 전파합니다. 프록시 또는 게이트웨이 서비스에 지정된 ML 애플리케이션 이름보다 전파된 ML 애플리케이션 이름이 우선합니다. + +## LLM 게이트웨이 및 프록시 서비스 관찰{#observing-llm-gateway-and-proxy-services} + +### 프록시 또는 게이트웨이 서비스에 대한 모든 요청{#all-requests-to-the-proxy-or-gateway-service} + +프록시 서비스에 대한 모든 요청을 최상위 스팬으로 보려면 프록시 서비스 엔드포인트의 진입점을 `workflow` 스팬으로 래핑하세요. + +{{< tabs >}} +{{% tab "Python" %}} + +```python +# proxy.py +from ddtrace.llmobs import LLMObs + +LLMObs.enable(service="chat-proxy") + +@app.route('/chat') +def chat(): + with LLMObs.workflow(name="chat-proxy-entrypoint"): + # proxy-specific logic, including guardrails, sensitive data scans, and the LLM call +``` + +{{% /tab %}} +{{% tab "Node.js" %}} + +```javascript +// proxy.js +const tracer = require('dd-trace').init({ + llmobs: true, + service: "chat-proxy" +}); +const llmobs = tracer.llmobs; + +app.post('/chat', async (req, res) => { + await llmobs.trace({ name: 'chat-proxy-entrypoint', kind: 'workflow' }, async () => { + // proxy-specific logic, including guardrails, sensitive data scans, and the LLM call + res.send("Hello, world!"); + }); +}); +``` + +{{% /tab %}} +{{< /tabs >}} + +그러면 프록시 서비스에 대한 모든 요청을 LLM 트레이스 보기 내에서 최상위 스팬으로 볼 수 있습니다. + +1. [LLM 트레이스][1] 페이지에서 왼쪽 상단 드롭다운에서 {{< ui >}}All Applications{{< /ui >}}를 선택하세요. +2. 오른쪽 상단 드롭다운에서 {{< ui >}}All Spans{{< /ui >}} 보기로 전환하세요. +3. `service` 태그와 워크플로 이름으로 목록을 필터링하세요. + +{{< img src="llm_observability/all-spans-with-service-and-span-name.png" alt="서비스 및 워크플로 이름 태그가 있는 모든 ML 애플리케이션의 모든 스팬 조회하기" style="width:100%;" >}} + +트레이스 보기 왼쪽의 패싯을 사용하여 워크플로 {{< ui >}}Span Name{{< /ui >}}을 필터링할 수도 있습니다. + +{{< img src="llm_observability/span-name-facet-for-proxy-service-monitoring.png" alt="트레이스 보기 왼쪽의 패싯에서 워크플로 스팬 이름 선택하기" style="width:50%;" >}} + +### 프록시 또는 게이트웨이 서비스 내에서 이루어진 모든 LLM 호출 {#all-llm-calls-made-within-the-proxy-or-gateway-service} + +프록시 또는 게이트웨이 서비스 내에서 이루어진 LLM 호출만 모니터링하려면 추적 보기에서 `llm` 스팬으로 필터링하세요. + +{{< img src="llm_observability/all-spans-with-service-and-span-kind.png" alt="서비스 태그와 LLM 스팬 종류를 사용하여 모든 ML 애플리케이션의 모든 스팬 조회하기" style="width:100%;" >}} + +트레이스 보기 왼쪽의 {{< ui >}}Span Kind{{< /ui >}} 패싯으로도 필터링할 수 있습니다. + +{{< img src="llm_observability/span-kind-facet-for-proxy-service-monitoring.png" alt="트레이스 보기 왼쪽에서 LLM 스팬 종류 패싯 선택하기" style="width:50%;" >}} + +### 특정 ML 애플리케이션별 필터링 및 패턴과 추세 관찰 {#filtering-by-a-specific-ml-application-and-observing-patterns-and-trends} + +두 가지 필터링 프로세스([프록시 서비스에 대한 최상위 호출](#all-requests-to-the-proxy-or-gateway-service) 및 [프록시 또는 게이트웨이 서비스 내에서 이루어진 LLM 호출](#all-llm-calls-made-within-the-proxy-or-gateway-service))를 모두 특정 ML 애플리케이션에 적용하여 프록시 또는 게이트웨이 서비스와의 상호 작용을 조회할 수 있습니다. + +1. 왼쪽 상단 드롭다운에서 관심 있는 ML 애플리케이션을 선택하세요. +2. ML 애플리케이션에 대한 모든 추적을 보려면 오른쪽 상단 드롭다운에서 {{< ui >}}All Spans{{< /ui >}} 보기에서 {{< ui >}}Traces{{< /ui >}} 보기로 전환하세요. +3. ML 애플리케이션에 대한 추적 시계열을 보려면 오른쪽 상단의 드롭다운에서 {{< ui >}}All Spans{{< /ui >}} 필터로 다시 전환한 다음 'Visualize as' 옆에서 {{< ui >}}Timeseries{{< /ui >}}을 선택하세요. + +{{< img src="llm_observability/timeseries-view-for-proxy-services.png" alt="All Span 필터를 유지하면서 트레이스 보기 옵션 중 목록 보기에서 시계열 보기로 전환하기" style="width:100%;" >}} + +## 프록시 또는 게이트웨이 서비스에 호출을 수행하는 LLM 애플리케이션의 엔드투엔드 사용량 관찰 {#observing-end-to-end-usage-of-llm-applications-making-calls-to-a-proxy-or-gateway-service} + +프록시 또는 게이트웨이 서비스에 호출을 수행하는 LLM 애플리케이션의 전체 엔드투엔드 사용량을 관찰하려면 해당 ML 애플리케이션 이름으로 추적을 필터링할 수 있습니다. + +1. LLM 추적 보기의 왼쪽 상단 드롭다운에서 관심 있는 ML 애플리케이션 이름을 선택하세요. +2. 오른쪽 상단 드롭다운에서 {{< ui >}}Traces{{< /ui >}} 보기로 전환하세요. + + +[1]: https://app.datadoghq.com/llm/traces \ No newline at end of file diff --git a/hugo/content/ko/llm_observability/improve/datasets.md b/hugo/content/ko/llm_observability/improve/datasets.md new file mode 100644 index 00000000000..5d3a8dafbf1 --- /dev/null +++ b/hugo/content/ko/llm_observability/improve/datasets.md @@ -0,0 +1,257 @@ +--- +aliases: +- /ko/llm_observability/experiments/datasets/ +description: 데이터세트 생성, 검색, 관리 방법 및 버전 관리에 대한 정보 등 Agent Observability 실험에서의 데이터세트 + 사용을 다룹니다. +further_reading: +- link: /llm_observability/configure/automation_rules + tag: 설명서 + text: 자동화 규칙을 사용하여 데이터세트로 트레이스 자동 라우팅하기 +title: 데이터세트 +--- +Agent Observability 실험에서 _데이터세트_는 에이전트를 테스트하려는 시나리오를 나타내는 _입력_, _예상 출력_ 및 _메타데이터_의 모음입니다. 각 데이터세트는 _프로젝트_와 연결됩니다. + +데이터세트의 각 레코드에는 다음이 포함됩니다. +- **input**(필수): 에이전트가 작업에서 액세스할 수 있는 모든 정보를 나타냅니다. +- **expected output**(선택 사항): _정답(ground truth)_이라고도 하며, 에이전트가 출력해야 하는 이상적인 답변을 나타냅니다. _expected output_을 사용하여 앱의 실제 출력과 평가하려는 중간 결과를 저장할 수 있습니다. +- **metadata**(선택 사항): 레코드를 분류하고 추가 분석에 사용할 수 있는 유용한 정보가 포함됩니다. 예: 주제, 태그, 설명, 메모. +- **id**(선택 사항): 레코드에 대해 사용자가 정의한 식별자입니다. 128자 이하여야 하며 문자, 숫자, `_`, `-` 또는 `.`만 포함할 수 있습니다. 제공되지 않으면 SDK가 자동으로 생성합니다. + +데이터세트는 실험 전반에 걸쳐 일관된 평가 시나리오를 제공함으로써 체계적인 테스트와 회귀 탐지를 가능하게 합니다. + +### 데이터세트 생성하기 {#creating-a-dataset} + +프로덕션 데이터나 CSV 파일로 데이터세트를 생성하거나 프로그래밍 방식으로 직접 구성할 수 있습니다. + +{{< tabs >}} + +{{% tab "CSV 파일로 생성" %}} + +CSV 파일로 데이터세트를 생성하려면 `LLMObs.create_dataset_from_csv()`를 사용하세요. + +```python +# Create dataset from CSV +dataset = LLMObs.create_dataset_from_csv( + csv_path="questions.csv", + dataset_name="capitals-of-the-world", + project_name="capitals-project", # Optional: defaults to the project name from LLMObs.enable + description="Geography quiz dataset", # Optional: Dataset description + input_data_columns=["question", "category"], # Columns to use as input + expected_output_columns=["answer"], # Optional: Columns to use as expected output + metadata_columns=["difficulty"], # Optional: Additional columns as metadata + id_column="record_id", # Optional: Column to use as record IDs + csv_delimiter="," # Optional: Defaults to comma +) + +# Example "questions.csv": +# record_id,question,category,answer,difficulty +# japan-capital,What is the capital of Japan?,geography,Tokyo,medium +# brazil-capital,What is the capital of Brazil?,geography,Brasília,medium + +``` + +**참고**: +- CSV 파일에는 헤더 행이 있어야 합니다 +- 최대 필드 크기는 10MB입니다 +- `input_data_columns`, `expected_output_columns` 또는 `id_column`에 지정되지 않은 모든 열은 자동으로 메타데이터로 처리됩니다. +- 데이터세트는 생성 후 자동으로 Datadog으로 푸시됩니다. + +{{% /tab %}} + +{{% tab "수동 생성" %}} + +데이터세트를 수동으로 생성하려면 `LLMObs.create_dataset()`를 사용하세요. + +```python +from ddtrace.llmobs import LLMObs + +dataset = LLMObs.create_dataset( + dataset_name="capitals-of-the-world", + project_name="capitals-project", # optional, defaults to project_name used in LLMObs.enable + description="Questions about world capitals", + records=[ + { + "id": "china-capital", # optional, user-defined record ID + "input_data": {"question": "What is the capital of China?"}, # required, JSON or string + "expected_output": "Beijing", # optional, JSON or string + "metadata": {"difficulty": "easy"} # optional, JSON + }, + { + "input_data": {"question": "Which city serves as the capital of South Africa?"}, + "expected_output": "Pretoria", + "metadata": {"difficulty": "medium"} + } + ] +) +# View dataset in Datadog UI +print(f"View dataset: {dataset.url}") +``` +{{% /tab %}} + +{{% tab "프로덕션 트레이스로 생성" %}} +데이터세트에 프로덕션 트레이스를 UI를 통해 수동으로 추가하거나, 자동화를 사용하여 자동으로 추가할 수 있습니다. + +**수동 선택(UI)**: +1. [{{< ui >}}AI Observability{{< /ui >}} > {{< ui >}}Traces{{< /ui >}}][2]로 이동합니다. [Settings > Automations][3]에서 새로운 자동화를 추가할 수도 있습니다. +2. 데이터세트에 포함할 트레이스를 찾습니다. +3. {{< ui >}}Add to Dataset{{< /ui >}}를 클릭합니다. +4. 기존 데이터세트를 선택하거나 데이터세트를 생성합니다. +5. 트레이스의 입력, 출력 및 메타데이터가 자동으로 추출됩니다. + +**자동 라우팅(자동화)**: + +
자동화는 향후 적용됩니다. 규칙과 일치하는 새 트레이스는 도착하는 즉시 데이터세트로 라우팅됩니다. 필터와 일치하는 기존 트레이스는 소급하여 추가되지 않습니다.
+ +자동화를 사용하면 구성 가능한 규칙에 따라 프로덕션 트레이스를 데이터세트로 지속적으로 라우팅하여 수동 개입 없이도 프로덕션 동작에 맞춰 데이터세트를 최신 상태로 유지할 수 있습니다. + +자동 데이터세트 업데이트를 설정하려면 다음 단계를 따르세요. +1. [{{< ui >}}AI Observability{{< /ui >}} > {{< ui >}}Traces{{< /ui >}}][2]로 이동합니다. +2. 필터를 적용하여 라우팅할 트레이스(평가 실패, 지연 시간 임계값, 특정 애플리케이션)를 식별합니다. 허용되는 항목은 [Automation Rules > Supported filter fields][5]를 참조하세요. +3. {{< ui >}}Automate Query{{< /ui >}}를 클릭합니다. +4. 샘플링 비율을 구성합니다(예: 일치하는 트레이스의 10%). +5. {{< ui >}}Add to Dataset{{< /ui >}}를 액션으로 선택합니다. +6. 기존 데이터세트를 선택하거나 데이터세트를 생성합니다. + +자동화를 생성한 후 [{{< ui >}}AI Observability{{< /ui >}} > {{< ui >}}Settings{{< /ui >}} > {{< ui >}}Automations{{< /ui >}}][3]에서 관리합니다. +- {{< ui >}}Enable/disable{{< /ui >}}: 새로운 트레이스가 데이터세트에 추가되는지 여부를 제어합니다. +- {{< ui >}}Edit{{< /ui >}}: 필요에 따라 필터, 샘플링 비율 또는 대상 데이터세트를 수정합니다. +- {{< ui >}}Delete{{< /ui >}}: 더 이상 필요하지 않은 자동화를 제거합니다. + +**데이터세트 제한:** +- 자동화로 채워진 데이터세트는 최대 20,000개 레코드로 제한됩니다. +- 이러한 데이터세트는 자동화된 데이터의 우발적인 수정을 방지하기 위해 읽기 전용으로 설정됩니다. +- 레코드를 수정하려면 먼저 데이터세트를 복제하세요. + +**자동화 사용 사례 예시:** +- 실패한 평가가 포함된 트레이스의 10%를 샘플링하여 실패 데이터세트를 구축합니다. +- 지연 시간이 임계값을 초과하는 특수 케이스를 수집합니다. +- 사용자 세그먼트 전반에 걸쳐 계층적 샘플링을 사용하여 다양한 데이터세트를 유지합니다. +- 프로덕션 환경에서 새로운 실패 패턴이 나타나면 자동으로 캡처합니다. + +[2]: https://app.datadoghq.com/llm/traces +[3]: https://app.datadoghq.com/llm/settings/automations +[5]: /ko/llm_observability/configure/automation_rules/#supported-filter-fields +{{% /tab %}} +{{< /tabs >}} + +### 데이터세트 검색 중 {#retrieving-a-dataset} + +Datadog에서 프로젝트의 기존 데이터세트를 검색하려면 다음 단계를 따르세요. + +```python +dataset = LLMObs.pull_dataset( + dataset_name="capitals-of-the-world", + project_name="capitals-project", # optional, defaults to the project name from LLMObs.enable + version=1 # optional, defaults to the latest version +) + +# Get dataset length +print(len(dataset)) +``` + +#### 데이터세트를 pandas로 내보내기 {#exporting-a-dataset-to-pandas} + +Dataset 클래스는 [pandas DataFrame][1]으로 데이터세트를 변환할 수 있는 `as_dataframe()` 메서드도 제공합니다. + +
이 작업을 수행하려면 Pandas가 필요합니다. pandas를 설치하려면 pip install pandas를 실행하세요.
+ +```python +# Convert dataset to pandas DataFrame +df = dataset.as_dataframe() +print(df.head()) + +# DataFrame output with MultiIndex columns: +# input_data expected_output metadata +# question category answer difficulty +# 0 What is the capital of Japan? geography Tokyo medium +# 1 What is the capital of Brazil? geography Brasília medium +``` + +DataFrame은 다음 열을 포함하는 MultiIndex 구조를 가집니다. +- `input_data`: `input_data_columns`의 모든 입력 필드 포함 +- `expected_output`: `expected_output_columns`의 모든 출력 필드 포함 +- `metadata`: `metadata_columns`의 모든 추가 필드 포함 + + +### 데이터세트 버전 관리 {#dataset-versioning} + +데이터세트는 시간이 지남에 따라 변경 사항을 추적하기 위해 자동으로 버전이 관리됩니다. 버전 관리 정보는 재현성을 가능하게 하며 실험에서 특정 데이터세트 버전을 참조할 수 있도록 합니다. + +`Dataset` 객체에는 최신 버전에 해당하는 `current_version` 필드가 있으며, 이전 버전에는 90일 보존 기간이 적용됩니다. + +데이터세트 버전은 `0`에서 시작하며, 새로운 버전이 생성될 때마다 버전이 1씩 증가합니다. + +#### 새로운 데이터세트 버전이 생성되는 경우 {#when-new-dataset-versions-are-created} + +다음과 같은 경우 새로운 데이터세트 버전이 생성됩니다. +- 레코드 추가 +- 레코드 업데이트(`input`, `expected_output` 또는 `metadata` 필드 변경) +- 레코드 삭제 + +데이터세트 이름이나 설명을 업데이트할 때는 데이터세트 버전이 생성되지 **않습니다**. + +#### 버전 보존 {#version-retention} + +- 데이터세트의 활성 버전은 3년간 보관됩니다. +- 이전 버전(`current_version`의 콘텐츠가 **아님**)은 90일간 보존됩니다. +- 90일 보존 기간은 이전 버전이 사용될 때(예: 실험에서 버전을 읽을 때) 재설정됩니다. +- 90일 동안 연속으로 사용하지 않으면 이전 버전은 영구 삭제 대상이 되며 더 이상 액세스할 수 없을 수 있습니다. + +**버전 보존 동작 예시** + +`12`를 게시하면 `11`은 90일 보관 기간이 적용되는 이전 버전이 됩니다. 25일 후 버전 `11`을 사용하여 실험을 실행하면 90일 기간이 **재시작**됩니다. 버전 `11`을 사용하지 않은 상태로 90일이 더 지나면 버전 `11`이 삭제될 수 있습니다. + +### 데이터세트 레코드 액세스 및 관리하기 {#accessing-and-managing-dataset-records} + +표준 Python 인덱싱을 사용하여 데이터세트 레코드에 액세스할 수 있습니다. + +```python +# Get a single record +record = dataset[0] + +# Get multiple records +records = dataset[1:3] + +# Iterate through records +for record in dataset: + print(record["input_data"]) +``` + +Dataset 클래스는 레코드를 관리하는 메서드인 `append()`, `update()`, `delete()`를 제공합니다. 변경 사항을 Datadog에 저장하려면 변경 사항에 대해 `push()`를 실행해야 합니다. + +```python +# Add a new record +dataset.append({ + "id": "switzerland-capital", + "input_data": {"question": "What is the capital of Switzerland?"}, + "expected_output": "Bern", + "metadata": {"difficulty": "easy"} +}) + +# Update an existing record +dataset.update(0, { + "input_data": {"question": "What is the capital of China?"}, + "expected_output": "Beijing", + "metadata": {"difficulty": "medium"} +}) + +# Delete a record +dataset.delete(1) # Deletes the second record + +# Save changes to Datadog +dataset.push() +``` + +### 데이터세트 표 사용자 지정하기 {#customizing-the-dataset-table} + +데이터세트의 레코드를 조회할 때 표를 사용자 지정하여 각 레코드를 개별적으로 확장하지 않고도 빠르게 스캔하고 비교할 수 있습니다. + +#### 열 선택기 {#column-picker} + +열 선택기를 사용하여 열을 켜거나 끄고, 드래그하여 순서를 변경하세요. + +#### 사용자 지정 열 {#custom-columns} + +데이터세트 레코드에서 특정 필드를 추출하여 전용 표 열로 표시하세요. 사용자 지정 열을 추가하려면 표 상단의 {{< ui >}}Add Column{{< /ui >}} 입력란에 필드 경로를 입력하세요. 여러 개의 사용자 지정 열을 추가하고 열을 끌어다 놓아 순서를 변경할 수 있습니다. 열 구성은 프로젝트별로 브라우저의 로컬 스토리지에 저장됩니다. + +[1]: https://pandas.pydata.org/docs/reference/api/pandas.DataFrame.html \ No newline at end of file diff --git a/hugo/content/ko/llm_observability/instrument/_index.md b/hugo/content/ko/llm_observability/instrument/_index.md new file mode 100644 index 00000000000..0432fdd1317 --- /dev/null +++ b/hugo/content/ko/llm_observability/instrument/_index.md @@ -0,0 +1,84 @@ +--- +aliases: +- /ko/llm_observability/instrumentation/ +description: Python, Node.js 및 Java용 SDK 기반 및 API 기반 접근 방식을 포함한 Agent Observability를 + 위한 계측 옵션 개요입니다. +further_reading: +- link: /llm_observability/auto_instrumentation + tag: 자동 계측 + text: 자동 계측으로 빠르게 시작하기 +- link: https://www.datadoghq.com/blog/llm-otel-semantic-convention + tag: 블로그 + text: Datadog LLM Observability는 OpenTelemetry GenAI 시맨틱 규칙을 기본적으로 지원합니다. +- link: https://learn.datadoghq.com/courses/llm-obs-getting-started + tag: 학습 센터 + text: Agent Observability 시작하기 +title: Agent Observability 계측 +--- +Agent Observability를 시작하려면 프로그래밍 언어와 설정에 따라 여러 접근 방식 중 하나를 선택하여 LLM 애플리케이션 또는 에이전트를 계측하세요. Datadog은 최소한의 코드 변경으로 LLM 애플리케이션 및 에이전트에서 상세한 트레이스, 메트릭 및 평가를 캡처하도록 설계된 포괄적인 계측 옵션을 제공합니다. + +## 계측 옵션 {#instrumentation-options} +Python, Node.js 또는 Java SDK를 사용하거나 Agent Observability API를 사용하여 애플리케이션을 계측할 수 있습니다. + +### SDK 기반 계측(권장) {#sdk-based-instrumentation-recommended} +Datadog은 가장 포괄적인 Agent Observability 기능을 제공하는 네이티브 SDK를 제공합니다. +| 언어 | 사용 가능한 SDK | 자동 계측 | 사용자 지정 계측 | +| -------- | ------------- | -------------------- | ---------------------- | +| Python | Python 3.7+ | {{< X >}} | {{< X >}} | +| Node.js | Node.js 16+ | {{< X >}} | {{< X >}} | +| Java | Java 8+ | {{< X >}} | {{< X >}} | + + +SDK를 사용하여 LLM 애플리케이션을 계측하려면 다음 단계를 따르세요. +1. Agent Observability SDK를 설치합니다. +2. 애플리케이션 시작 명령에서 [필수 환경 변수][6]를 제공하거나 [코드 내에서][7] 프로그래밍 방식으로 SDK를 구성합니다. Datadog API 키, Datadog 사이트 및 ML(머신러닝) 앱 이름을 구성했는지 확인하세요. + +#### 자동 계측 {#auto-instrumentation} +자동 계측은 코드를 변경할 필요 없이 Python, Node.js 및 Java 애플리케이션에 대한 LLM 호출을 캡처합니다. 이를 통해 인기 프레임워크 및 공급자에 대한 즉시 사용 가능한 트레이스와 관측 가능성을 확보할 수 있습니다. 추가 세부 정보 및 지원되는 프레임워크와 공급자의 전체 목록은 [자동 계측 문서][1]를 참조하세요. + +자동 계측은 다음을 자동으로 캡처합니다. +- 입력 프롬프트 및 출력 완성 +- 토큰 사용량 및 비용 +- 지연 시간 및 오류 정보 +- 모델 파라미터(temperature, max_tokens 등) +- 프레임워크별 메타데이터 + +
지원되는 프레임워크를 사용할 때는 LLM 호출에 대해 수동 스팬 생성이 필요하지 않습니다. SDK는 풍부한 메타데이터와 함께 적절한 스팬을 자동으로 생성합니다.
+ +#### 사용자 지정 계측 {#custom-instrumentation} +지원되는 모든 SDK는 자동 계측 외에도 다음을 포함한 LLM 애플리케이션의 사용자 지정 계측을 위한 고급 기능을 제공합니다. +- 함수 데코레이터 또는 컨텍스트 관리자를 사용한 수동 스팬 생성 +- 다단계 LLM 애플리케이션에 대한 복합적인 워크플로 트레이스 +- 자율 LLM 에이전트에 대한 Agent 모니터링 +- 사용자 지정 평가 및 품질 측정 +- 사용자 상호 작용을 위한 세션 추적 + +자세한 내용은 [SDK 참조 문서][2]를 참조하세요. + +### HTTP API 계측 {#http-api-instrumentation} +SDK에서 지원하지 않는 언어를 사용하거나 사용자 지정 통합을 사용하는 경우, Datadog의 HTTP API를 사용하여 애플리케이션을 계측할 수 있습니다. + +API를 통해 다음을 수행할 수 있습니다: +- HTTP API 엔드포인트를 통해 직접 스팬 제출 +- 스팬과 연결된 사용자 지정 평가 전송 +- 복잡한 애플리케이션의 전체 트레이스 계층 구조 포함 +- 입력, 출력, 메타데이터 및 메트릭으로 스팬 주석 달기 + +API 엔드포인트: +- [스팬 API][4]: `POST` `https://api.{{< region-param key="dd_site" code="true" >}}/api/intake/llm-obs/v1/trace/spans` +- [평가 API][5]: `POST` `https://api.{{< region-param key="dd_site" code="true" >}}/api/intake/llm-obs/v2/eval-metric` + +자세한 내용은 [HTTP API 문서][3]를 참조하세요. + +## 추가 자료 {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + + +[1]: /ko/llm_observability/auto_instrumentation +[2]: /ko/llm_observability/instrument/sdk +[3]: /ko/llm_observability/setup/api +[4]: /ko/llm_observability/instrument/api/?tab=model#spans-api +[5]: /ko/llm_observability/instrument/api/?tab=model#evaluations-api +[6]: /ko/llm_observability/instrument/sdk#command-line-setup +[7]: /ko/llm_observability/instrument/sdk#in-code-setup \ No newline at end of file diff --git a/hugo/content/ko/llm_observability/quickstart/_index.md b/hugo/content/ko/llm_observability/quickstart/_index.md new file mode 100644 index 00000000000..8b992a98713 --- /dev/null +++ b/hugo/content/ko/llm_observability/quickstart/_index.md @@ -0,0 +1,247 @@ +--- +aliases: +- /ko/tracing/llm_observability/quickstart +description: Agent Observability SDK를 사용하여 Python, Node.js 또는 Java LLM 애플리케이션을 계측하여 + Agent Observability를 시작하세요. +further_reading: +- link: /llm_observability/instrument/auto_instrumentation + tag: 설명서 + text: 지원되는 자동 계측 프레임워크 및 라이브러리 +- link: /llm_observability/instrument/sdk + tag: 설명서 + text: 수동 계측을 위한 Agent Observability SDK 참조 +- link: /llm_observability/instrument/api + tag: 설명서 + text: 언어 중립적 계측을 위한 Agent Observability HTTP API +- link: /llm_observability/instrument/otel_instrumentation + tag: 설명서 + text: OpenTelemetry로 계측 +- link: /llm_observability/configure/evaluations + tag: 평가 + text: 애플리케이션에서 평가 구성 +- link: /llm_observability/lapdog + tag: 설명서 + text: Agent Observability를 위한 로컬 개발 도구 +title: 빠른 시작 +--- +이 페이지는 Datadog의 Agent Observability SDK를 사용하여 Python, Node.js 또는 Java LLM 애플리케이션을 계측하는 방법을 보여줍니다. + +### 전제 조건 {#prerequisites} + +Datadog Agent가 실행 중이지 않은 경우 Agent Observability에는 Datadog API 키가 필요합니다. [Datadog에서](https://app.datadoghq.com/organization-settings/api-keys) API 키를 찾으세요. + +### 코딩 에이전트로 Agent Observability 계측{#instrument-agent-observability-with-a-coding-agent} + +다음 프롬프트를 붙여넣으시어 원하는 코딩 에이전트로 Agent Observability를 계측하세요. + +```bash +Follow the instructions at https://docs.datadoghq.com/llm_observability/instrument/agentic.md to instrument my application with Datadog Agent Observability. When configuring the environment, use the following values for variable entries: + +DD_SITE={{< region-param key="dd_site" code="true" >}} +DD_API_KEY= +``` + +**참고:** API 키를 프롬프트의 일부로 제공하는 것은 선택 사항이며, 코딩 에이전트가 애플리케이션을 계측하는 데 필수는 아닙니다. + +### 수동 설정{#manual-setup} + +대화형 퀵스타트 환경을 보려면 Datadog의 [인앱 온보딩 흐름](https://app.datadoghq.com/llm/applications?setupMethod=manual&showOnboarding=true)에 있는 설정 지침을 따르세요. + +{{< tabs >}} +{{% tab "Python" %}} + +1. SDK 설치: + + ```shell + pip install ddtrace + ``` + +2. Python 시작 명령 앞에 `ddtrace-run`을 추가하세요. + + ```shell + DD_LLMOBS_ENABLED=1 \ + DD_LLMOBS_ML_APP=quickstart-app \ + DD_SITE= \ + DD_API_KEY= \ + ddtrace-run + ``` + +활성화 후 SDK는 OpenAI, LangChain, LangGraph, Bedrock, Anthropic 등 [지원되는 Python 프레임워크][auto-instr-py]에 대한 호출을 자동으로 트레이스합니다. 사용 중인 프레임워크가 목록에 없으면 [수동 계측][sdk]을 추가하여 LLM 호출을 직접 트레이스하세요. + +[auto-instr-py]: /llm_observability/instrument/auto_instrumentation/?tab=python +[sdk]: /llm_observability/instrument/sdk?tab=python + +{{% /tab %}} + +{{% tab "Node.js" %}} +1. SDK 설치: + + ```shell + npm install dd-trace + ``` + +2. 애플리케이션 진입점에서 Agent Observability를 첫 번째 종속성으로 `dd-trace`를 가져오고 초기화하세요. + ```shell + DD_LLMOBS_ENABLED=1 \ + DD_LLMOBS_ML_APP=quickstart-app \ + DD_SITE= \ + DD_API_KEY= \ + NODE_OPTIONS="--import dd-trace/initialize.mjs" + ``` + +활성화 후, SDK는 OpenAI, LangChain, Vercel AI SDK, Bedrock, Anthropic 등 [지원되는 Node.js 프레임워크][1]에 대한 호출을 자동으로 트레이스합니다. 프레임워크가 목록에 없는 경우, [수동 계측][2]을 추가하여 LLM 호출을 직접 트레이스하세요. + +**Next.js**: Agent Observability SDK로 Next.js 애플리케이션을 올바르게 구성하려면 [Agent Observability를 위한 Next.js 애플리케이션 계측][3]을 참조하세요. + +[1]: /ko/llm_observability/instrument/auto_instrumentation/?tab=nodejs +[2]: /ko/llm_observability/instrument/sdk?tab=nodejs +[3]: /ko/llm_observability/guide/nextjs_guide + +{{% /tab %}} +{{% tab "Java" %}} +1. SDK 설치: + + ```shell + wget -O dd-java-agent.jar 'https://dtdg.co/latest-java-tracer' + ``` + +2. Java 시작 명령에 `-javaagent` JVM 인수를 추가하세요. + ```shell + java -javaagent:/path/to/dd-java-agent.jar \ + -Ddd.llmobs.enabled=true \ + -Ddd.llmobs.ml.app=quickstart-app \ + -Ddd.site= \ + -Ddd.api.key= \ + -jar path/to/your/app.jar + ``` + +활성화 후, SDK는 [지원되는 Java 프레임워크][1]에 대한 호출을 자동으로 트레이스합니다. Java 자동 계측은 OpenAI 및 Azure OpenAI를 지원합니다. Bedrock이나 LangChain4j와 같은 다른 라이브러리의 경우, 대신 [수동 계측][2]을 사용하세요. + +[1]: /ko/llm_observability/instrument/auto_instrumentation/?tab=java +[2]: /ko/llm_observability/instrument/sdk?tab=java + +{{% /tab %}} +{{% tab "기타 언어/HTTP API" %}} + +Python, Node.js, Java 이외의 언어의 경우, [Agent Observability HTTP API][1]를 사용하여 SDK 없이 Datadog으로 스팬을 직접 전송하세요. + +애플리케이션이 [OpenTelemetry GenAI 의미 체계 규칙][2]을 준수하는 스팬을 내보내는 경우, 대신 [OpenTelemetry 계측][2]을 참조하세요. + +[1]: /ko/llm_observability/instrument/api +[2]: /ko/llm_observability/instrument/otel_instrumentation + +{{% /tab %}} +{{< /tabs >}} + +Datadog 사이트는 {{< region-param key="dd_site" code="true" >}}. ``를 Datadog API 키로 대체하세요. + +### 트레이스 조회 {#view-traces} + +애플리케이션에 요청을 전송해 LLM 호출을 트리거한 다음 Datadog [{{< ui >}}Agent Observability{{< /ui >}} 페이지의][3] {{< ui >}}Traces{{< /ui >}} 탭에서 트레이스를 조회하세요. + +트레이스가 보이지 않는 경우: + +- **라이브러리가 자동 계측되는지 검사**: 자동 계측은 [지원되는 프레임워크 및 라이브러리][6]에 대한 호출만 캡처합니다. [Python][7], [Node.js][8] 또는 [Java][9]에 대한 지원 목록을 확인하세요. 라이브러리가 목록에 없으면 수동으로 계측을 추가해야 합니다. +- **수동 계측 추가**: [Agent Observability SDK][5]를 사용하여 코드에서 직접 스팬으로 LLM 호출을 래핑하세요. 이는 모든 라이브러리나 모델 공급자에 적용됩니다. +- **HTTP API 사용**: [Agent Observability HTTP API][10]는 모든 언어나 프레임워크의 스팬을 허용하며 SDK가 필요하지 않습니다. +- **OpenTelemetry 사용**: 프레임워크가 [OpenTelemetry GenAI 의미 체계 규칙][11]을 준수하는 스팬을 내보내는 경우, 설정 세부 정보는 [OpenTelemetry 계측][11]을 참조하세요. + + +### 다음 단계 {#next-steps} + +애플리케이션에서 트레이스가 제출되면 다음을 수행할 수 있습니다. + +- [평가 구성][4]을 통해 LLM 애플리케이션의 효과를 평가할 수 있습니다. +- 애플리케이션에 [수동 계측][5]을 추가하여 자동 계측으로 추출할 수 없는 데이터를 추출하세요. + + +## 예시 'Hello World' 애플리케이션 {#example-hello-world-application} + +Agent Observability 제품 탐색을 시작하는 데 사용할 수 있는 간단한 애플리케이션은 아래를 참조하세요. + + +{{< tabs >}} +{{% tab "Python" %}} + +1. OpenAI를 `pip install openai`로 설치합니다. + +2. 예시 스크립트 `app.py`를 저장합니다. + + ```python + import os + from openai import OpenAI + + oai_client = OpenAI(api_key=os.environ.get("OPENAI_API_KEY")) + completion = oai_client.chat.completions.create( + model="gpt-4o-mini", + messages=[ + {"role": "system", "content": "You are a helpful customer assistant for a furniture store."}, + {"role": "user", "content": "I'd like to buy a chair for my living room."}, + ], + ) + ``` + +3. 애플리케이션을 실행합니다. + + ```shell + DD_LLMOBS_ENABLED=1 \ + DD_LLMOBS_ML_APP=quickstart-app \ + DD_API_KEY= \ + ddtrace-run app.py + ``` +{{% /tab %}} + +{{% tab "Node.js" %}} +1. OpenAI를 `npm install openai`로 설치합니다. + +2. 예시 스크립트 `app.js`를 저장합니다. + + ```js + const { OpenAI } = require('openai'); + const oaiClient = new OpenAI(process.env.OPENAI_API_KEY); + + async function main () { + const completion = await oaiClient.chat.completions.create({ + model: 'gpt-4o-mini', + messages: [ + { role: 'system', content: 'You are a helpful customer assistant for a furniture store.' }, + { role: 'user', content: 'I\'d like to buy a chair for my living room.' }, + ] + }); + return completion; + } + + main().then(console.log) + ``` + +3. 애플리케이션을 실행합니다. + ```shell + DD_LLMOBS_ENABLED=1 \ + DD_LLMOBS_ML_APP=quickstart-app \ + DD_API_KEY= \ + NODE_OPTIONS="--import dd-trace/initialize.mjs" node app.js + ``` + +{{% /tab %}} +{{< /tabs >}} + + +## Lapdog을 사용하여 로컬에서 Agent Observability 체험 {#try-agent-observability-locally-with-lapdog} + +Agent Observability를 로컬에서 무료로 체험하려면 [단계에 따라][12] 애플리케이션을 계측하고 [lapdog](https://lapdog.datadoghq.com)을 사용하여 로컬에서 데이터를 조회하세요. + + +## 추가 자료 {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[3]: https://app.datadoghq.com/llm/traces +[4]: /ko/llm_observability/configure/evaluations +[5]: /ko/llm_observability/instrument/sdk#manual-instrumentation +[6]: /ko/llm_observability/instrument/auto_instrumentation +[7]: /ko/llm_observability/instrument/auto_instrumentation/?tab=python +[8]: /ko/llm_observability/instrument/auto_instrumentation/?tab=nodejs +[9]: /ko/llm_observability/instrument/auto_instrumentation/?tab=java +[10]: /ko/llm_observability/instrument/api +[11]: /ko/llm_observability/instrument/otel_instrumentation +[12]: /ko/llm_observability/lapdog \ No newline at end of file diff --git a/hugo/content/ko/logs/explorer/search.md b/hugo/content/ko/logs/explorer/search.md index 6429d0a70b9..f8edfb361fb 100644 --- a/hugo/content/ko/logs/explorer/search.md +++ b/hugo/content/ko/logs/explorer/search.md @@ -11,86 +11,88 @@ further_reading: text: 로그에서 시각화 생성 - link: /logs/explorer/export tag: 설명서 - text: 로그 탐색기에서 보기 내보내기 + text: Log Explorer에서 보기 내보내기 title: 로그 검색 --- +## 개요 {#overview} -## 개요 +[Log Explorer][1]를 사용하면 개별 로그를 검색하고 목록으로 조회할 수 있습니다. 하지만 가장 가치 있는 인사이트는 대규모로 로그를 집계할 때 얻을 수 있는 경우가 많습니다. 검색 기능을 사용하면 로그를 필터링하고 시계열 차트, 상위 목록, 트리 맵, 파이 차트 또는 표로 시각화하여 로그 데이터 전반의 트렌드, 패턴 및 이상치를 더 잘 이해할 수 있습니다. -개별 로그를 목록화해서 정보를 보는 것도 좋지만 로그를 집계했을 때 유용한 정보가 나타나는 경우도 있습니다. 이와 같이 정보를 보려면 [Log Explorer][5]에서 로그를 검색하고 시계열, 상위 목록, 트리맵 차트, 파이 차트, 또는 테이블로 표시하세요. +## 자연어 쿼리 {#natural-language-queries} -Log Explorer의 검색 기능은 시간 범위, 검색 쿼리, `key:value` 및 전체 텍스트 검색을 혼합하여 사용합니다. +{{% site-region region="gov,gov2" %}} +
+자연어 쿼리는 Datadog 사이트에서 사용할 수 없습니다({{< region-param key="dd_site_name" >}}). +
+{{% /site-region %}} +자연어 쿼리(NLQ)를 사용하여 찾고 있는 내용을 쉬운 영어로 설명하세요. Datadog은 사용자의 요청을 구조화된 로그 쿼리로 자동 변환하므로 복잡한 구문을 작성할 필요 없이 더 쉽게 로그를 탐색할 수 있습니다. 이 기능에 액세스하려면 검색 필드에서 {{< ui >}}Ask{{< /ui >}}를 클릭하세요. -## 쿼리 검색 +{{< img src="/logs/explorer/search/log_explorer_nlq.mp4" alt="쉬운 영어 문구를 사용하여 로그를 검색하는 방법을 보여주는 Log Explorer의 자연어 쿼리" video=true >}} -예를 들어 지난 30분 간 웹 스토어 서비스에서 오류 상태가 된 로그를 필터링하려면 `service:payment status:error rejected`와 같은 커스텀 쿼리를 만들고 시간 범위를 `Past 15 minutes`로 설정하세요. +시스템은 자연어 입력을 Datadog 쿼리로 변환하며 서비스, 특성, 태그, 시간 범위와 같은 컨텍스트를 이해합니다. 또한 관련 필드를 자동으로 탐지하고 사용자가 간단한 설명(예: 'Top 20 services by errors' 또는 'Show errors from service X in the past 24 hours')을 사용하여 시각화를 생성할 수 있도록 합니다. -{{< img src="logs/explorer/search_filter.png" alt="Log Explorer에서 웹 스토어 서비스 내 결제 거부 오류 로그를 필터링하는 검색 쿼리 쿼리 생성" style="width:100%;" >}} +NLQ를 비활성화하려면 [`org_management` 권한][2]이 있어야 합니다. [{{< ui >}}Organization Settings{{< /ui >}} > {{< ui >}}Preferences{{< /ui >}}][3]로 이동하고 자연어 쿼리 기능을 끄세요. -[인덱싱된 로그][1]는 전체 컨텍스트 검색과 `key:value` 검색 쿼리를 모두 지원합니다. +## 검색 쿼리 {#search-query} -**참고**: `key:value` 쿼리를 사용하기 전에 [패싯을 선언][2]할 필요가 **없습니다**. +Log Explorer 검색은 시간 범위와 검색 쿼리로 구성되며, `key:value` 및 [전체 텍스트 검색][4]을 결합합니다. Log Explorer 오른쪽 상단에 있는 시간 범위 선택기를 사용하여 검색할 기간을 선택할 수 있습니다. 사용자 지정 시간 범위 설정에 대한 자세한 내용은 [사용자 지정 시간 프레임 설명서][5]를 참조하세요. -## 자동 완성 +지난 15분 동안 웹 스토어 서비스에서 생성된 로그(오류 상태 포함)를 필터링하려면 `service:payment status:error rejected`와 같은 사용자 지정 쿼리를 생성하고 시간 범위를 `Past 15 minutes`로 설정하세요. -검색 창의 자동 완성 기능을 통해 다음을 사용하여 쿼리를 완성할 수 있습니다. -- 로그의 기존 키와 값 -- 나의 최근 검색(다른 사용자의 최근 검색은 표시되지 않음) -- 저장된 페이지 +{{< img src="logs/explorer/search_filter.png" alt="Log Explorer에서 웹 스토어 서비스의 거부된 결제에 대한 오류 로그를 필터링하는 검색 쿼리 생성" style="width:100%;" >}} -{{< img src="logs/explorer/search/log_search_bar_autocomplete.png" alt="쿼리가 service이고 emailer, balancer-checker, ad-server, vpc가 자동 완성 옵션으로 표시된 로그 검색 창" style="width:80%;">}} +[인덱싱된 로그][6]는 [전체 텍스트 검색][4]과 `key:value` 검색 쿼리를 모두 지원합니다. -### 패싯 및 값 자동 완성 +**참고**: `key:value` 쿼리를 사용하기 전에 [패싯을 선언][7]할 필요가 **없습니다**. -검색 창은 검색 창 입력 내역을 기반으로 패싯을 자동 제안합니다. 이 패싯은 [패싯 패널][5] 위치와 같은 순서로 표시됩니다. 패싯에 정의된 표시 이름이 있을 경우 드롭다운 메뉴 우측에 표시됩니다. 패싯 패널에 표시되도록 구성하지 않은 패싯은 검색 창에 자동 제안되지 않습니다. +전체 쿼리 구문 참조는 [검색 구문 설명서][8]를 참조하세요. -{{< img src="logs/explorer/search/log_facet_autocomplete.png" alt="`network`가 쿼리이고 @network.bytes_written, @network.client.ip, @network.interface가 자동 완성 옵션 패싯으로 표시된 로그 검색 창" style="width:80%;">}} +## 검색 창 기능 {#search-bar-features} -패싯을 선택하고 `:` 문자를 입력하면 검색 창이 자동으로 값을 제안합니다. 이 값은 지난 15분간 `facet:value` 쌍을 포함하는 로그 수에 따라 내림차순으로 표시됩니다. 해당 값을 포함하는 예상 로그 수가 드롭다운 메뉴 우측에 표시됩니다. 예를 들어 `balance-checker` 서비스의 값이 `2.66M`이므로 `service` 패싯 값의 자동 제안 목록의 첫 번째에 위치하고 있으며 로그 개수가 가장 많다는 것을 알 수 있습니다. +Log Explorer 검색 창에는 쿼리를 더 효율적이고 정확하게 작성할 수 있도록 돕는 여러 기능이 포함되어 있습니다. -{{< img src="logs/explorer/search/log_value_autocomplete.png" alt="쿼리가 `service:`이고 values balance-checker, ad-server, fraud-detector, trade-executor가 자동 완성 옵션으로 표시된 로그 검색 창" style="width:80%;">}} +### 구문 강조 표시 및 오류 검증 {#syntax-highlighting-and-error-validation} -### 최근 검색 자동 완성 기능 +구문 강조 표시는 입력 유형(키, 값, 자유 텍스트, 제어 문자)을 명확하게 구분합니다. 예를 들어, `service` 및 `status`는 키이고, `auth-dotnet` 및 `error`는 값이며, `500` 및 `check-token`은 자유 텍스트이고, 괄호는 제어 문자입니다. 상태 특성은 상태별로 색상이 지정됩니다(빨간색은 `error`, 파란색은 `info`). -Log Explorer에는 가장 최근에 검색한 기록 100개가 남습니다. 다른 사용자의 최근 검색 기록은 저장되지 않고 나타나지 않습니다. 검색 창은 입력 기록과 일치하는 최근 기록 네 개를 자동 제안하며 가장 최근 검색 기록이 맨 처음에 표시됩니다. 또 최근 검색한 각 항목을 언제 검색했는지도 표시됩니다. 예를 들어 검색 창에 `service:web-store status:error`를 입력하면 이 용어를 포함한 최근 검색 항목 네 개가 시간 순서에 따라 표시되며, 각 항목과 연결된 오류도 표시됩니다. +{{< img src="logs/explorer/search/log_syntax_highlighting.png" alt="구분 가능한 구문 강조 표시와 함께 'service:auth-dotnet status:error 500 (check-token OR create-user)'를 쿼리로 보여주는 Log Explorer 검색 창" style="width:100%;">}} -{{< img src="logs/explorer/search/log_recent_searches.png" alt="쿼리가 `service:web-store status:error`이고 다른 웹 스토어 서비스 오류가 자동 완성 옵션으로 표시된 로그 검색 창" style="width:80%;">}} +오류 검증은 구문 오류를 식별하고 `key:value` 쌍의 누락된 값, 불완전한 범위 쿼리 또는 닫히지 않은 괄호와 같은 수정 사항을 제안합니다. -### 저장된 보기 자동 완성 +{{< img src="logs/explorer/search/log_error_states.png" alt="'Missing closing parenthesis character' 메시지와 함께 'service:(web-store OR auth-dotnet'을 쿼리로 보여주는 Log Explorer 검색 창" style="width:50%;">}} -Log Explorer에서 저장된 보기를 생성해 향후에 사용할 수 있도록 쿼리와 추가 컨텍스트를 저장하여 중앙에서 액세스를 할 수 있습니다. 검색 창에서 이전에 검색한 내역과 일치하는 저장된 보기를 자동 제안합니다. 이때 저장된 보기 패널에 있는 위치와 동일한 순서로 표시되고 즐겨 찾기 표시한 보기가 맨 먼저 표시됩니다. 드롭다운 메뉴에는 저장된 보기 이름, 저장된 쿼리, 가장 최근에 업데이트한 사용자 프로필 사진이 표시됩니다. 저장된 보기 쿼리가 드롭다운에 표시하기에 너무 길 경우, 마우스 커서를 도구 설명에 올리면 전체 쿼리가 나타납니다. 저장된 보기를 가장 최근에 업데이트한 사용자 이메일과 프로필 사진도 마우스 커서를 올렸을 때 함께 표시됩니다. +### 자동 완성 {#autocomplete} -{{< img src="logs/explorer/search/log_autocomplete_saved_views.png" alt="쿼리가 `service:web-store status:error`이고 웹 스토어 서비스 오류 여러 개가 자동 완성 옵션으로 표시된 로그 검색 창" style="width:80%;">}} +검색 창의 자동 완성 기능은 로그에 있는 기존 키와 값, 최근 검색어, 저장된 보기를 사용하여 쿼리를 완성하도록 도와줍니다. -## 검색 구문 +{{< img src="logs/explorer/search/log_search_bar_autocomplete.png" alt="'service:'를 쿼리로, emailer, balancer-checker, ad-server, vpc를 자동 완성 옵션으로 보여주는 Log Explorer 검색 창" style="width:80%;">}} -구문을 강조 표시하여 키(예: `@merchant_name` 속성), 값(예: 특정 판매자 이름), 일반 텍스트(예: `responded 500` 등 로그 메시지의 키워드), 제어 문자(예: 괄호와 콜론)를 구분할 수 있습니다. 상태 속성도 색으로 강조 표시되어 상태를 나타냅니다(예: `error`는 빨강, `info`는 파랑). +자동 완성은 입력 내용을 기반으로 패싯과 값을 제안하며, [패싯 패널][7]에 나타나는 순서대로 표시됩니다. 패싯을 선택하고 `:`을 입력하면 지난 15분 동안의 로그 수에 따라 내림차순으로 값이 나타납니다. -{{< img src="logs/explorer/search/log_syntax_highlighting.png" alt="`service:auth-dotnet status:error 500 (check-token OR create-user)`이고 구문을 구분하기 위해 강조 표시된 로그 검색 창" style="width:100%;">}} +{{< img src="logs/explorer/search/log_facet_autocomplete.png" alt="'network'를 쿼리로, 패싯 @network.bytes_written, @network.client.ip, @network.interface를 자동 완성 옵션으로 보여주는 Log Explorer 검색 창" style="width:80%;">}} -정확한 오류 상태를 통해 구문의 어떤 부분에 구문 오류가 포함되어 있으며 어떻게 해결할 수 있는지 알 수 있습니다. 다음 예를 참고하세요. -- 값을 넣지 않은 상태에서 `service:` 쿼리를 입력하면 쿼리에 마우스 커서를 올릴 때 메시지 "Missing value in key:value pair"가 나타납니다. -- 범위 쿼리에 괄호를 입력했는데 높은 값과 낮은 값을 넣지 않으면 메시지 "Expected term but end of input found"가 나타납니다. -- 로그 필드에 여러 값을 입력했는데 괄호 문자를 누락하면(예: `service:(web-store OR auth-dotnet`) 메시지 `Missing closing parenthesis character`가 나타납니다. +최근 검색어 100개가 유지되며 입력 시 제안됩니다. 쿼리와 일치하는 저장된 보기도 제안되며, Saved Views 패널과 동일한 순서로 표시됩니다. -{{< img src="logs/explorer/search/log_error_states.png" alt="쿼리가 `service:(web-store OR auth-dotnet`이고 메시지 `Missing closing parenthesis character`가 표시된 로그 검색 창" style="width:50%;">}} +{{< img src="logs/explorer/search/log_recent_searches.png" alt="'service:web-store status:error'를 쿼리로, 다양한 웹 스토어 서비스 오류에 대한 최근 검색어를 자동 완성 옵션으로 보여주는 로그 검색 창" style="width:80%;">}} -Log Explorer에서 로그를 검색하고 시간 프레임을 사용자 조정하려면 [구문 검색 설명서][3]와 [커스텀 시간 프레임 설명서][4]를 참고하세요. -## 검색 창에서 스타일과 자동 완료 기능 비활성화하기 +## 검색 창에서 스타일링 및 자동 완성 비활성화 {#disable-styling-and-autocomplete-for-search-bar} -검색 창 옆에 있는 버튼을 클릭해 원시 모드에서 검색하세요. 그러면 구문 강조 표시, 둥근 모서리 모양 스타일링, 자동 완성 기능이 모두 제거됩니다. +검색 창 오른쪽에 있는 버튼을 클릭해 원시 모드에서 검색하세요. 그러면 구문 강조 표시, 둥근 모서리 모양 스타일링, 자동 완성 기능이 모두 제거됩니다. -{{< img src="logs/explorer/search/log_raw_search_mode.png" alt="쿼리가 `service:auth-dotnet status:error 500 (check-token OR create-user)`이고 원시 모드인 로그 검색 창" style="width:100%;">}} +{{< img src="logs/explorer/search/log_raw_search_mode.png" alt="원시 검색 모드에서 'service:auth-dotnet status:error 500 (check-token OR create-user)'를 쿼리로 보여주는 로그 검색 창" style="width:100%;">}} -마우스나 키보드 명령으로 검색 창을 탐색할 수 있습니다. 예를 들어 `CMD-A`를 사용해 텍스트를 선택하고, `CMD-C`를 사용해 텍스트를 복사하고, `CMD-X`를 사용해 텍스트를 잘라내고, `CMD-V`를 사용해 텍스트를 붙여 넣을 수 있습니다. +검색 창은 마우스와 키보드 명령으로 상호작용할 수 있습니다. 예를 들어, 텍스트를 선택하려면 `CMD-A`를, 텍스트를 복사하려면 `CMD-C`를, 텍스트를 잘라내려면 `CMD-X`를, 텍스트를 붙여넣으려면 `CMD-V`를 사용하세요. -## 참고 자료 +## 추가 자료 {#further-reading} {{< partial name="whats-next/whats-next.html" >}} -[1]: /ko/logs/indexes -[2]: /ko/logs/explorer/facets/ -[3]: /ko/logs/search-syntax -[4]: /ko/dashboards/guide/custom_time_frames -[5]: /ko/logs/explorer/ \ No newline at end of file +[1]: /ko/logs/explorer/ +[2]: /ko/account_management/rbac/permissions/#access-management +[3]: https://app.datadoghq.com/organization-settings/preferences +[4]: /ko/logs/explorer/search_syntax/#full-text-search +[5]: /ko/dashboards/guide/custom_time_frames +[6]: /ko/logs/indexes +[7]: /ko/logs/explorer/facets/ +[8]: /ko/logs/search-syntax \ No newline at end of file diff --git a/hugo/content/ko/monitors/types/data_observability.md b/hugo/content/ko/monitors/types/data_observability.md new file mode 100644 index 00000000000..467372275d0 --- /dev/null +++ b/hugo/content/ko/monitors/types/data_observability.md @@ -0,0 +1,412 @@ +--- +description: 데이터 웨어하우스 전반에서 신선도, 행 수, 열 수준 메트릭 및 사용자 지정 SQL 쿼리를 모니터링합니다. +further_reading: +- link: /data_observability/ + tag: 설명서 + text: Data Observability 개요 +- link: /data_observability/quality_monitoring/ + tag: 설명서 + text: Quality Monitoring +- link: /monitors/notify/ + tag: 설명서 + text: 모니터링 알림 설정 +- link: /monitors/downtimes/ + tag: 설명서 + text: 모니터링 음소거를 위한 가동 중지 예약 +- link: /monitors/status/ + tag: 설명서 + text: 모니터링 상태 확인 +title: Data Observability 모니터 +--- +## 개요 {#overview} + +[Data Observability][1] 모니터는 계절성, 추세 및 사용자 피드백을 학습하는 이상 징후 탐지를 사용하여 지연된 데이터, 불완전한 로드 및 예기치 않은 값 변경이 다운스트림 대시보드, AI 애플리케이션 또는 비즈니스 결정에 영향을 미치기 전에 이를 포착합니다. 엔드투엔드 데이터 및 코드 계보와 결합된 이 모니터들은 팀이 문제를 조기에 탐지하고, 다운스트림 영향을 평가하며, 올바른 소유자에게 라우팅하도록 돕습니다. + +Data Observability 모니터는 다음 메트릭 유형을 지원합니다. + +**표 수준 메트릭 유형:** +| 메트릭 유형 | 설명 | +|---|---| +| 신선도 | 표가 마지막으로 업데이트된 후 경과된 시간을 추적합니다. | +| 행 수 | 표 또는 보기의 행 수를 추적합니다. | +| 커스텀 SQL | SQL 쿼리에서 반환된 사용자 지정 메트릭 값을 추적합니다. | + +**열 수준 메트릭 유형:** +| 메트릭 유형 | 설명 | +|---|---| +| 신선도 | 날짜/시간 열에서 확인된 가장 최근 날짜를 추적합니다. | +| 고유성 | 고유 값의 백분율을 추적합니다. | +| Null 여부 | Null 값의 백분율을 추적합니다. | +| 카디널리티 | 고유 값의 수를 추적합니다. | +| 0 백분율 | 0과 같은 값의 백분율을 추적합니다. | +| 음수 백분율 | 음수 값의 백분율을 추적합니다. | +| 최소/최대/평균/합계/표준 편차 | 열 값 전반의 통계적 측정값을 추적합니다. | + +Datadog은 가능할 경우 웨어하우스 시스템 메타데이터(예: `INFORMATION_SCHEMA`)에서 행 수 및 신선도와 같은 메트릭을 수집합니다. 이렇게 하면 웨어하우스에 대해 쿼리를 실행하지 않아도 되므로 컴퓨팅 비용이 절감됩니다. 모든 웨어하우스가 시스템 메타데이터를 노출하는 것은 아닙니다. 시스템 메타데이터에서 수집할 수 없는 메트릭의 경우, 모니터가 웨어하우스에 직접 쿼리를 실행하여 값을 계산합니다. + +Data Observability 모니터를 사용하려면 최소 하나 이상의 지원되는 데이터 웨어하우스(예: [Snowflake][3], [Databricks][4] 또는 [BigQuery][5])에 [Quality Monitoring][2]이 설정되어 있어야 합니다. + +Data Observability는 [모니터 생성 흐름][13]의 첫 번째 단계에서 선택하는 네 가지 모니터 유형을 제공합니다. + +| 모니터 유형 | 모니터링 대상 | +|---|---| +| 데이터 품질 | 테이블 및 열에 대한 신선도, 행 수, 열 수준 메트릭. | +| [소스-대상](#source-to-target-monitors) | 소스 자산과 대상 자산 간 동일한 메트릭의 차이. | +| [스키마 변경](#schema-change-monitors) | 웨어하우스에서 추가, 제거, 이름 변경 또는 유형이 변경된 필드. | +| 작업 | 실패한 작업 실행. | + +별도로 명시되지 않는 한, 아래 섹션에서는 데이터 품질 모니터 유형에 대해 설명합니다. + +## 모니터 생성 {#monitor-creation} + +Datadog에서 Data Observability 모니터를 생성하려면 [{{< ui >}}Data Observability{{< /ui >}} > {{< ui >}}Monitors{{< /ui >}} > {{< ui >}}New Monitor{{< /ui >}}][6] 또는 [{{< ui >}}Monitors{{< /ui >}} > {{< ui >}}New Monitor{{< /ui >}} > {{< ui >}}Data Observability{{< /ui >}}][6]로 이동하세요 기존의 모든 Data Observability 모니터를 보려면 [Data Observability 모니터 페이지][7]를 참조하세요 + +## 모니터링 데이터 선택 {#choose-data-to-monitor} + +먼저 {{< ui >}}Table{{< /ui >}} 수준 또는 {{< ui >}}Column{{< /ui >}} 수준 중 무엇을 모니터링할지 선택합니다. + +{{< img src="monitors/monitor_types/data_observability/entity_type_selection_and_aastra.png" alt="모니터링할 데이터 선택: 엔터티 유형 선택기, 쿼리 입력 및 계보 관계 필터" style="width:60%;" >}} + +그런 다음 {{< ui >}}Edit{{< /ui >}} 탭을 사용하여 검색 필드에 `key:value` 필터를 입력하여 테이블, 보기 또는 열을 검색합니다. + +**이름 또는 위치별 필터링:** + +| 필터 | 예시 | 설명 | +|---|---|---| +| 이름 | `name:USERS*` | 이름으로 일치시킵니다. `*` 와일드카드를 지원합니다. | +| 스키마 | `schema:PROD` | 스키마별로 일치시킵니다. | +| 데이터베이스 | `database:ANALYTICS_DB` | 데이터베이스별로 일치시킵니다. | +| 계정 | `account:my_account` | 계정별로 일치시킵니다. | + +**태그로 필터링:** + +태그 키를 필터 키로 사용하여 데이터 에셋에 적용된 모든 태그를 필터링합니다. 예를 들어, 에셋에 `owner`, `platform` 또는 `environment` 태그가 적용된 경우 해당 태그를 직접 검색합니다. + +| 예시 | 설명 | +|---|---| +| `owner:data-platform-team` | `owner:data-platform-team`으로 태그된 에셋을 일치시킵니다. | +| `platform:snowflake` | `platform:snowflake`으로 태그된 에셋을 일치시킵니다. | +| `environment:production` | `environment:production`으로 태그된 에셋을 일치시킵니다. | + +태그 필터는 이름 필터와 동일한 `*` 와일드카드 및 따옴표를 지원합니다(예: `owner:data-*` 또는 `platform:"Snowflake Prod"`). + +**계산된 속성으로 필터링:** + +사용자 지정 태그 외에도 Datadog은 필터링할 수 있는 데이터 에셋의 속성을 계산합니다. 사용 가능한 계산된 속성은 다음과 같습니다. + +| 속성 | 값 | 설명 | +|---|---|---| +| `lineage_score` | `0.00`, `0.10`, `0.30`, `0.50`, `0.70`, `0.90` 또는 `1.00` | 동일한 유형의 다른 에셋과 비교하여 얼마나 많은 다운스트림 에셋이 의존하는지에 따라 리니지 그래프에서 에셋이 얼마나 연결되어 있는지를 나타내는 상대적 척도입니다. 값이 높을수록 다운스트림 소비자가 의존하는 테이블, 뷰, 열임을 나타냅니다. | + +`lineage_score`는 연속적인 값을 취하는 대신 위에 나열된 개별 계층으로 버킷화되므로 해당 정확한 값 중 하나로 필터링합니다. 단일 계층을 일치시키거나 `OR`로 계층을 결합합니다. 예를 들어, `lineage_score:1.00`은 가장 많이 의존되는 자산을 반환하고, `lineage_score:(0.90 OR 1.00)`은 상위 2개 계층을 반환합니다. + +이러한 필터를 `AND` 또는 `OR`와 결합하고, 괄호를 사용하여 조건을 그룹화하며, `-`를 접두사로 사용하여 제외합니다. + +**예시:** + +| 목표 | 쿼리 | +|---|---| +| 임시 표를 제외한 PROD 스키마의 모든 표 | `schema:PROD AND -name:TEMP*` | +| 모든 타임스탬프 열 | `name:*_AT OR name:*_TIMESTAMP` | +| 특정 데이터베이스에 대해 PROD 또는 STAGING에 있는 표 | `database:ANALYTICS_DB AND (schema:PROD OR schema:STAGING)` | +| 특정 팀이 소유한 표 | `owner:data-platform-team` | +| 데이터베이스에서 가장 많이 의존되는 표 | `database:ANALYTICS_DB AND lineage_score:1.00` | + +**계보 관계별 필터:** + +계보 그래프에서 다른 자산과 연결된 자산으로 선택 범위를 좁히려면 {{< ui >}}Add Relation Filter{{< /ui >}}를 클릭합니다 {{< ui >}}Upstream of{{< /ui >}} 또는 {{< ui >}}Downstream of{{< /ui >}}를 선택한 다음, 특정 자산을 선택하거나 동일한 `key:value` 필터를 사용하여 자산 집합을 일치시킵니다. 예를 들어, 중요한 대시보드의 상위에 있는 모든 표를 모니터링하거나, 특정 소스 표의 하위에 있는 모든 열을 모니터링합니다. + +**계층 관계별 필터:** + +계보 그래프에서 다른 자산의 상위 또는 하위 자산으로 선택 범위를 좁히려면 {{< ui >}}Add Relation Filter{{< /ui >}}를 클릭합니다. {{< ui >}}Parent of{{< /ui >}} 또는 {{< ui >}}Child of{{< /ui >}}를 선택한 다음, 특정 자산을 선택하거나 동일한 `key:value` 필터를 사용하여 자산 집합을 일치시킵니다. 예를 들어, `revenue` 열이 있는 모든 표나 중요한 스키마 내에 있는 모든 표를 모니터링합니다 + +단일 모니터는 최대 5,000개의 표, 뷰 또는 열을 추적할 수 있습니다. 이 제한은 늘릴 수 없습니다. 쿼리가 더 많은 항목과 일치하는 경우, 여러 모니터로 나누세요 + +## 메트릭 유형 선택{#select-your-metric-type} + +추적하려는 데이터 품질 신호를 기반으로 메트릭 유형을 선택합니다. 각 모니터는 하나의 메트릭 유형을 추적합니다. + +{{< tabs >}} +{{% tab "신선도" %}} + +{{< ui >}}Freshness{{< /ui >}} 메트릭 유형은 예상 시간 창 내에 데이터가 업데이트되지 않은 경우를 감지합니다. 다운스트림 보고서나 모델에 영향을 미치기 전에 오래된 데이터를 포착하는 데 사용하세요. + +- **표 신선도**는 표가 마지막으로 업데이트된 이후 경과된 시간을 추적합니다. 표 신선도는 뷰나 시스템 메타데이터에서 표에 대한 업데이트된 타임스탬프를 제공하지 않는 데이터 웨어하우스에는 사용할 수 없습니다. 대신 열 수준 신선도를 사용하세요. +- **열 신선도**는 날짜/시간 열에서 확인된 가장 최근 날짜를 추적합니다. + +{{% /tab %}} +{{% tab "행 개수" %}} + +{{< ui >}}Row Count{{< /ui >}} 메트릭 유형은 표의 행 개수 변화를 추적합니다. 파이프라인 오류나 업스트림 문제를 나타낼 수 있는 예상치 못한 데이터 감소 또는 급증을 감지하는 데 사용하세요 + +{{% /tab %}} +{{% tab "열 메트릭" %}} + +{{< ui >}}Column{{< /ui >}} 메트릭 유형은 열 수준 메트릭을 추적하여 데이터 드리프트나 품질 저하를 감지합니다. 다음 중에서 선택하세요. + +| 메트릭 | 설명 | +|---|---| +| {{< ui >}}Uniqueness{{< /ui >}} | 열에서 고유한 값의 비율입니다. | +| {{< ui >}}Nullness{{< /ui >}} | 열에서 null인 값의 비율입니다. | +| {{< ui >}}Cardinality{{< /ui >}} | 열에 있는 고유 값의 개수입니다. | +| {{< ui >}}Percent Zero{{< /ui >}} | 열에서 0과 같은 값의 비율입니다. | +| {{< ui >}}Percent Negative{{< /ui >}} | 열에서 음수인 값의 비율입니다. | +| {{< ui >}}Min{{< /ui >}} | 열에 있는 모든 값의 최솟값입니다. | +| {{< ui >}}Max{{< /ui >}} | 열에 있는 모든 값의 최댓값입니다. | +| {{< ui >}}Mean{{< /ui >}} | 열에 있는 모든 값의 평균값입니다. | +| {{< ui >}}Standard Deviation{{< /ui >}} | 열에 있는 값들 사이의 변동을 측정한 값입니다. | +| {{< ui >}}Sum{{< /ui >}} | 열에 있는 모든 값의 합계입니다. | + +
일부 열 메트릭은 특정 열 유형에서만 사용할 수 있습니다. 숫자 메트릭(0 비율, 음수 비율, 최솟값, 최댓값, 평균, 표준 편차, 합계)은 숫자 열이 필요합니다.
+ +{{% /tab %}} +{{% tab "커스텀 SQL" %}} + +{{< ui >}}Custom SQL{{< /ui >}} 메트릭 유형은 사용자가 정의한 SQL 쿼리에 의해 반환된 사용자 지정 메트릭 값을 추적합니다. 비즈니스별 데이터 품질 규칙 모니터링과 같이 기본 제공 메트릭 유형이 사용 사례를 다루지 못할 때 사용하세요. + +1. 쿼리에서 반환된 값을 설명하는 모델 유형을 선택하세요. + - {{< ui >}}Default{{< /ui >}}: 쿼리가 스칼라 값을 반환합니다. 대부분의 경우에 사용하세요. + - {{< ui >}}Freshness{{< /ui >}}: 쿼리가 현재 시간과 이벤트가 마지막으로 발생한 시간 사이의 차이(초 단위)를 반환합니다. + - {{< ui >}}Percentage{{< /ui >}}: 쿼리가 0에서 100 사이의 백분율 값을 반환합니다. +2. `dd_value`로 별칭이 지정된 단일 값을 반환하는 SQL 쿼리를 작성하세요. 예: `SELECT COUNT(*) as dd_value FROM ANALYTICS_DB.PROD.ORDERS WHERE STATUS = 'FAILED'` +3. 쿼리 구문을 확인하려면 {{< ui >}}Validate{{< /ui >}}를 클릭합니다. + +SQL 쿼리에 `GROUP BY` 절이 포함된 경우, {{< ui >}}Group by{{< /ui >}} 필드에 그룹화된 열을 쉼표로 구분된 목록으로 나열합니다(예: `column_a, column_b`). 각 그룹은 독립적으로 평가됩니다. + +**참고**: 각 사용자 지정 SQL 모니터는 청구 목적상 개별 모니터링 대상 테이블로 계산됩니다. + +{{< img src="monitors/monitor_types/data_observability/custom_sql_example.png" alt="사용자 지정 SQL 모니터 생성을 위한 입력 필드입니다." style="width:60%;" >}} + +{{% /tab %}} +{{< /tabs >}} + +## 모니터 설정 {#configure-monitor} + +### 감지 방법 {#detection-method} + +감지 방법을 선택하세요. + +- {{< ui >}}Anomalies{{< /ui >}}: 메트릭이 예상 패턴에서 벗어날 때 경보를 보냅니다. 임계값은 필요하지 않습니다. 이상 모델은 기본 데이터 업데이트 빈도에 따라 **3~7일**(주말 포함)이 소요됩니다. 학습 기간 동안 모니터는 경보를 발생시키지 않으며 파란색으로 표시됩니다. 학습이 완료되면 모니터는 정상 상태일 때 녹색으로, 이상치 상태일 때 빨간색으로 표시됩니다. +- {{< ui >}}Thresholds{{< /ui >}}: 메트릭이 고정 값 기준을 지날 때 경보를 보냅니다. 비교 연산자(`above`, `above or equal to`, `below`, `below or equal to`, `equal to` 또는 `not equal to`)를 설정하고 {{< ui >}}Critical{{< /ui >}} 임계값을 정의하세요(필수). 선택적으로 {{< ui >}}Warning{{< /ui >}} 임계값을 정의할 수도 있습니다. 자세한 내용은 [Configure Monitors][8]를 참조하세요. + +### WHERE 절 {#where-clause} + +모니터가 평가하는 데이터를 필터링하려면 {{< ui >}}WHERE{{< /ui >}} 절을 추가하세요. 이는 특정 데이터 세그먼트나 최근 레코드만 모니터링할 때 유용합니다. 예를 들면 다음과 같습니다. + +- `created_at >= DATEADD(day, -7, CURRENT_TIMESTAMP())` — 지난주의 행만 모니터링합니다. +- `region = 'US'` — 특정 지역의 데이터만 모니터링합니다. + +### Group by {#group-by} + +{{< ui >}}Group by{{< /ui >}} 절을 추가하여 단일 모니터를 여러 그룹으로 분할하고 각 그룹을 독립적으로 평가할 수 있습니다. 예를 들어, 행 개수 모니터를 `REGION` 열별로 그룹화하면 각 지역에 대해 별도의 경보가 생성됩니다. + +{{< img src="monitors/monitor_types/data_observability/group_by_column_selection.png" alt="GROUP BY 차원을 선택하기 위한 입력 필드입니다." style="width:80%;" >}} + +기본 제한은 모니터당 500개 그룹입니다. 이 제한을 늘리려면 [지원팀에 문의][9]하세요. + +### 모델 구성 {#model-configuration} + +{{< ui >}}Anomalies{{< /ui >}} 감지 방법을 사용하는 모니터의 경우 {{< ui >}}Model configuration{{< /ui >}}을 확장하여 모델의 동작 방식을 구체화합니다. + +| 설정| 설명| +|---|---| +| {{< ui >}}Alert after N consecutive anomalies{{< /ui >}} | 모니터가 경고를 보내기 전까지 연속으로 실패한 평가 횟수입니다. 분리된 스파이크를 억제하도록 이 설정을 구성합니다. | +| {{< ui >}}Minimum upper bound size{{< /ui >}} | 모델이 상한에서 데이터를 얼마나 엄격하게 추적할지 제한합니다. | +| {{< ui >}}Minimum lower bound size{{< /ui >}} | 모델이 하한에서 데이터를 얼마나 엄격하게 추적할지 제한합니다. | + +{{< ui >}}If data is missing to evaluate{{< /ui >}} 드롭다운 메뉴에서 평가할 데이터를 사용할 수 없을 때 모니터가 보고할 내용을 선택하세요. + +### 모니터 일정 {#monitor-schedule} + +모니터가 데이터를 평가하는 빈도를 설정하세요. + +- {{< ui >}}Scheduled{{< /ui >}}: 모니터가 고정된 주기로 실행됩니다. {{< ui >}}Run this monitor{{< /ui >}} 아래에서 {{< ui >}}Hourly{{< /ui >}}, {{< ui >}}Every 3 hours{{< /ui >}}, {{< ui >}}Every 6 hours{{< /ui >}}, {{< ui >}}Every 12 hours{{< /ui >}}, {{< ui >}}Daily{{< /ui >}} 또는 {{< ui >}}Custom schedule{{< /ui >}}을 선택합니다. +- {{< ui >}}Manual{{< /ui >}} (미리 보기): 모니터가 프로그래밍 방식으로 트리거될 때만 실행됩니다. 모델링이 유용하도록 충분한 과거 데이터를 축적하려면 [Data Observability API][10]를 사용하여 일정에 따라 이러한 모니터를 실행합니다. UI는 행 수 및 신선도와 같은 기본 메트릭을 지원하지 않으므로 이 워크플로는 사용자 지정 또는 열 수준 메트릭에 적용됩니다. + +고유한 일정을 정의하려면 {{< ui >}}Custom schedule{{< /ui >}}를 선택하고 cron 표현식을 입력합니다. 사용자 지정 일정은 15분마다 실행될 수 있습니다. {{< ui >}}Preview times{{< /ui >}}는 현지 시간대의 다음 몇 번의 실행을 나열하므로 저장하기 전에 표현식을 확인할 수 있습니다. + +### 경보 조건 설정 {#set-alert-conditions} + +집계 유형을 선택합니다. + +- {{< ui >}}Simple Alert{{< /ui >}}: 모니터링되는 테이블이나 열이 조건을 충족할 때 단일 알림을 보냅니다. +- {{< ui >}}Multi Alert{{< /ui >}}: 조건을 충족하는 각 그룹에 대해 알림을 보냅니다. 경보 세분성을 제어하려면 그룹화할 차원(`table`, `schema`, `database` 등)을 사용자 지정합니다. 예를 들어 `schema`별로 그룹화하면 스키마당 하나의 경보만 전송되므로, 영향을 받는 모든 테이블을 하나로 묶어 노이즈를 줄일 수 있습니다. + +### 알림 예시 {#example-notification} + +{{< tabs >}} +{{% tab "임계값" %}} + +{{< code-block lang="text" >}} +{{#is_alert}} +Data quality issue detected on {{database.name}}.{{schema.name}}.{{table.name}}: +current value {{value}} has breached the threshold of {{threshold}}. +{{/is_alert}} + +{{#is_recovery}} +Data quality issue on {{database.name}}.{{schema.name}}.{{table.name}} has recovered. +Current value {{value}} is within the threshold of {{threshold}}. +{{/is_recovery}} +{{< /code-block >}} + +{{% /tab %}} +{{% tab "이상" %}} + +{{< code-block lang="text" >}} +{{#is_alert}} +Anomaly detected on {{database.name}}.{{schema.name}}.{{table.name}}: +observed value {{observed}} is outside the expected range of {{lower_bound}} to {{upper_bound}} +(predicted: {{predicted}}). +{{/is_alert}} + +{{#is_recovery}} +{{database.name}}.{{schema.name}}.{{table.name}} has recovered. +Observed value {{observed}} is within the expected range. +{{/is_recovery}} +{{< /code-block >}} + +{{% /tab %}} +{{< /tabs >}} + +## 소스-대상 모니터 {#source-to-target-monitors} + +
소스-대상 모니터는 미리 보기 상태입니다. 액세스를 요청하려면 Datadog 담당자나 지원 팀에 문의하세요.
+ +소스-대상 모니터는 두 데이터 자산의 동일한 메트릭을 비교하고 두 값이 다를 때 경보를 보냅니다. 다른 Data Observability 모니터는 단일 자산의 신선도나 완전성을 추적합니다. 소스-대상 모니터는 대상에 도착한 복사본이 소스에서 나간 것과 일치하는지 추적합니다. + +파이프라인이 시스템 간에 데이터를 이동할 때 부분적인 실패는 실패처럼 보이지 않는 경우가 많습니다. 100,000개의 행이 소스 테이블을 떠나고 99,850개의 행이 대상에 도착하면, 대상의 행 수 모니터만으로는 그럴듯한 값으로 보입니다. 두 자산을 비교하면 차이가 드러납니다. + +소스-대상 모니터를 사용하여 다음을 수행하세요. + +- Postgres에서 Databricks로의 복제를 검증합니다. +- 동일한 Snowflake 계정 내의 두 데이터베이스(예: 품질 데이터베이스와 프로덕션 데이터베이스)를 조정합니다. +- 전환 전에 Redshift에서 BigQuery로의 마이그레이션을 검증하기 위해 두 시스템을 나란히 실행하고 일치하는지 확인합니다. +- 변환 과정에서 입력과 출력 사이에 행이 누락되지 않았는지 확인합니다. + +소스-대상 모니터는 GovCloud를 제외한 모든 리전에서 사용할 수 있습니다. + +### 소스-대상 모니터 만들기 {#create-a-source-to-target-monitor} + +1. [{{< ui >}}Monitors{{< /ui >}} > {{< ui >}}New Monitor{{< /ui >}}][6]로 이동하여 {{< ui >}}Source to Target{{< /ui >}}을 선택합니다. +2. {{< ui >}}Choose source{{< /ui >}}에서 소스 데이터가 있는 웨어하우스를 선택한 다음 비교할 데이터를 선택합니다. +3. {{< ui >}}Choose target{{< /ui >}}에서 대상에 대해서도 동일하게 수행합니다. 소스와 대상은 서로 다른 데이터 웨어하우스에 있거나 동일한 웨어하우스에 있을 수 있습니다. +4. {{< ui >}}Select your metric type{{< /ui >}}에서 비교할 메트릭을 선택합니다. 소스-대상 모니터는 행 수, 신선도, null 여부, 고유성, 카디널리티 및 {{< ui >}}Custom SQL{{< /ui >}}을 포함하여 다른 Data Observability 모니터와 동일한 메트릭 유형을 지원합니다. +5. 비교가 표시되는 방식을 제어하려면 {{< ui >}}Format{{< /ui >}}을 설정합니다. + - {{< ui >}}Difference{{< /ui >}}: 대상 값에서 소스 값을 뺀 값입니다. 음수 값은 대상이 소스보다 작음을 의미합니다. + - {{< ui >}}% Difference{{< /ui >}}: 소스 값에 대한 백분율로 표시된 동일한 차이입니다. +6. [모니터 구성](#configure-monitor)에 설명된 대로 감지 방법, 예약 및 알림을 구성합니다. + +{{< ui >}}Preview Monitor Evaluation{{< /ui >}} 패널에는 식별된 소스 및 대상과 선택한 메트릭의 미리 보기가 표시됩니다. + +모니터링되는 자산이 대상이므로 모니터는 대상의 상태 페이지에 나타납니다. + +### 사용자 지정 메트릭 비교{#compare-a-custom-metric} + +메트릭 유형이 {{< ui >}}Custom SQL{{< /ui >}}인 경우 소스에 대한 쿼리 하나와 대상에 대한 쿼리 하나를 제공합니다. 이 메트릭 유형에는 {{< ui >}}WHERE{{< /ui >}} 절이 허용되지 않습니다. 각 쿼리에 필터링을 포함하세요. + +### 평가 {#evaluation} + +소스와 대상 간의 차이는 자체 메트릭으로 기록되므로 소스-대상 모니터는 이상 감지를 포함한 다른 Data Observability 모니터와 동일한 감지 방법으로 평가됩니다. 양쪽 모두 동기화된 일정에 따라 측정되므로 각 웨어하우스의 기본 수집 주기를 따르는 대신 두 값이 동시에 캡처됩니다. + +## 스키마 변경 모니터{#schema-change-monitors} + +
스키마 변경 모니터는 미리 보기 상태입니다.
+ +스키마 변경 모니터는 데이터의 내용이 변경될 때가 아니라 데이터의 구조가 변경될 때 경고합니다. 열이 삭제되거나, 이름이 변경되거나, 다른 데이터 유형으로 전환되는 경우와 같이 다운스트림 파이프라인이나 대시보드가 중단되기 전에 업스트림 변경 사항을 포착하는 데 사용합니다. + +스키마 변경 모니터는 데이터베이스, 스키마, 표 및 열 전반에서 네 가지 유형의 변경 사항을 감지합니다. + +| 변경 유형 | 설명 | +|---|---| +| 추가됨 | 데이터베이스, 스키마, 표 또는 열이 생성되었습니다. | +| 제거됨 | 데이터베이스, 스키마, 표 또는 열이 삭제되었습니다. | +| 이름 변경됨 | 표 또는 열의 이름이 변경되었습니다. | +| 유형 변경됨 | 열의 데이터 유형이 `INTEGER`에서 `STRING`으로 변경되었습니다. | + +스키마 변경은 Snowflake, BigQuery, Databricks 및 Redshift에 대해 감지됩니다. + +### 스키마 변경 모니터 만들기 {#create-a-schema-change-monitor} + +1. [{{< ui >}}Monitors{{< /ui >}} > {{< ui >}}New Monitor{{< /ui >}} > {{< ui >}}Schema Change{{< /ui >}}][11]로 이동합니다. +2. {{< ui >}}Choose data to monitor{{< /ui >}}에서 감시할 웨어하우스를 선택합니다. +3. [모니터 구성](#configure-monitor)에 설명된 대로 알림을 구성합니다. + +스키마 변경 모니터는 측정된 값이 경계를 넘는 것이 아니라 구조적 변경에 대해 경고하므로 메트릭 유형이나 감지 방법을 사용하지 않습니다. + +### 감지된 스키마 변경 찾아보기 {#browse-detected-schema-changes} + +모니터를 만들지 않고 Datadog이 감지한 변경 사항을 보려면 [{{< ui >}}Data Observability{{< /ui >}} > {{< ui >}}Schema Changes{{< /ui >}}][12]로 이동합니다. 플랫폼, 계정, 데이터베이스, 스키마 또는 변경 유형별로 필터링하고 항목을 확장하여 영향을 받는 열과 해당 데이터 유형을 확인합니다. + +변경 사항은 Datadog이 웨어하우스에서 스키마 메타데이터를 다음에 수집하고 현재 구조를 이전에 수집한 구조와 비교할 때 감지됩니다. + +## 모니터 예시 {#example-monitors} + +{{< tabs >}} +{{% tab "행 수 감소" %}} + +파이프라인 오류나 데이터 누락을 나타낼 수 있는 행 수의 상당한 감소를 감지합니다. + +1. {{< ui >}}Table{{< /ui >}} > {{< ui >}}Row Count{{< /ui >}}를 선택하고 대상 표(예: `ANALYTICS_DB.PROD.EVENTS`)를 선택합니다. +2. {{< ui >}}Anomalies{{< /ui >}}를 감지 방법으로 선택합니다. 행 수가 과거 기준선에서 벗어나면 모니터가 트리거됩니다. + +{{% /tab %}} +{{% tab "오래된 표" %}} + +중요한 표가 예상 시간 내에 업데이트되지 않았을 때 경고합니다. + +1. {{< ui >}}Table{{< /ui >}} > {{< ui >}}Freshness{{< /ui >}}를 선택하고 대상 표(예: `ANALYTICS_DB.PROD.ORDERS`)를 선택합니다. +2. {{< ui >}}Thresholds{{< /ui >}}를 감지 방법으로 선택합니다. +3. {{< ui >}}Alert threshold{{< /ui >}}를 **6시간**으로 설정하고 선택적으로 {{< ui >}}Warning threshold{{< /ui >}}를 **4시간**으로 설정합니다. + +{{% /tab %}} +{{% tab "Null 비율 급증" %}} + +열의 null 비율이 정상 수준을 초과할 때 감지하며, 이는 데이터 수집 문제를 나타낼 수 있습니다. + +1. {{< ui >}}Column{{< /ui >}} > {{< ui >}}Nullness{{< /ui >}}를 선택하고 대상 열(예: `ANALYTICS_DB.PROD.USERS.EMAIL`)을 선택합니다. +2. {{< ui >}}Anomalies{{< /ui >}}를 감지 방법으로 선택합니다. + +{{% /tab %}} +{{% tab "소스와 대상 간에 손실된 행" %}} + +복제 또는 마이그레이션 후 소스 표와 대상 표 사이에서 누락된 행을 감지합니다. + +1. {{< ui >}}Source to Target{{< /ui >}}을 선택한 다음 소스 표(예: `POSTGRES_DB.PUBLIC.ORDERS`)와 대상 표(예: `ANALYTICS_DB.PROD.ORDERS`)를 선택합니다. +2. {{< ui >}}Row Count{{< /ui >}}를 메트릭 유형으로 선택하고 {{< ui >}}Format{{< /ui >}}을 {{< ui >}}Difference{{< /ui >}}로 설정합니다. +3. {{< ui >}}Anomalies{{< /ui >}}를 감지 방법으로 선택합니다. + +{{% /tab %}} +{{< /tabs >}} + +## 경계 주석 달기{#annotate-bounds} + +**이상** 감지 방법을 사용하는 모니터의 경우, 경계 범위를 주석으로 달아 피드백을 제공하고 시간이 지남에 따라 모델을 개선할 수 있습니다. 인프라 메트릭과 달리 데이터 품질 메트릭은 비즈니스별로 다른 경우가 많으므로, 주석을 사용하여 데이터에 어떤 동작이 정상인지 모델에 학습시킵니다. + +{{< img src="/monitors/monitor_types/data_observability/annotate_bounds.png" alt="모니터 경계에 주석을 달기 위한 호버 메뉴입니다." style="width:90%;" >}} + +모니터의 상태 페이지에서 {{< ui >}}Annotate Bounds{{< /ui >}}를 클릭하고, 차트에서 시간 범위를 선택한 다음, 다음 주석 중 하나를 선택합니다. + +| 주석 | 설명 | +|---|---| +| {{< ui >}}Expected{{< /ui >}} | 경계를 확장하여 표시된 동작을 영구적으로 포함합니다. | +| {{< ui >}}Reset for now{{< /ui >}} | 동작을 OK로 표시하되, 다시 발생하면 경고합니다. | +| {{< ui >}}Missed alert{{< /ui >}} | 경계를 축소하여 이 동작에 대해 경고합니다. | +| {{< ui >}}Ignore{{< /ui >}} | 경계를 모델링할 때 주석이 달린 데이터를 제외합니다. | + +## 추가 자료 {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ko/data_observability/ +[2]: /ko/data_observability/quality_monitoring/ +[3]: /ko/data_observability/quality_monitoring/data_warehouses/snowflake/ +[4]: /ko/data_observability/quality_monitoring/data_warehouses/databricks/ +[5]: /ko/data_observability/quality_monitoring/data_warehouses/bigquery/ +[6]: https://app.datadoghq.com/monitors/create/data-quality +[7]: https://app.datadoghq.com/data-obs/monitors +[8]: /ko/monitors/configuration/?tab=thresholdalert#thresholds +[9]: /ko/help/ +[10]: /ko/api/latest/data-observability/ +[11]: https://app.datadoghq.com/monitors/create/schema-change +[12]: https://app.datadoghq.com/data-obs/schema-changes +[13]: https://app.datadoghq.com/monitors/create/data-quality \ No newline at end of file diff --git a/hugo/content/ko/observability_pipelines/destinations/datadog_byoc_logs.md b/hugo/content/ko/observability_pipelines/destinations/datadog_byoc_logs.md new file mode 100644 index 00000000000..0822fbe820b --- /dev/null +++ b/hugo/content/ko/observability_pipelines/destinations/datadog_byoc_logs.md @@ -0,0 +1,86 @@ +--- +aliases: +- /ko/observability_pipelines/destinations/cloudprem/ +description: Observability Pipelines Worker를 사용하여 Datadog BYOC(Bring Your Own Cloud) + Logs로 로그를 전송하는 방법을 알아보세요. +disable_toc: false +products: +- icon: logs + name: 로그 + url: /observability_pipelines/configuration/?tab=logs#pipeline-types +title: Datadog BYOC Logs 목적지 +--- +{{< product-availability >}} + +## 개요 {#overview} + +Observability Pipelines의 BYOC(Bring Your Own Cloud) Logs 목적지를 사용하여 Datadog BYOC Logs로 로그를 전송하세요. + + +## 전제 조건 {#prerequisites} + +목적지를 구성하기 전에 BYOC Logs 클러스터를 배포해야 합니다. [BYOC Logs 설치 섹션][3]에서 설치 방법을 확인하세요. + +## 설정 {#setup} + +[파이프라인을 설정][4]할 때 BYOC Logs 목적지를 구성하세요. 파이프라인은 [UI][1]에서 설정할 수 있으며, [API][5] 또는 [Terraform][6]을 사용하여 설정할 수 있습니다. 이 섹션에서 설명하는 단계는 UI에서 설정합니다. + +### 선택적 버퍼링 {#optional-buffering} + +파이프라인 UI에서 BYOC Logs 목적지를 선택한 후 버퍼링을 구성할 수 있습니다. + +{{% observability_pipelines/destination_buffer %}} + +{{< img src="observability_pipelines/destinations/cloudprem_settings.png" alt="BYOC Logs 목적지 설정" style="width:35%;" >}} + +## 시크릿 기본값 {#secret-defaults} + +{{% observability_pipelines/set_secrets_intro %}} + +{{< tabs >}} +{{% tab "시크릿 관리" %}} + +- BYOC Logs 엔드포인트 URL 식별자: + - Observability Pipelines가 로그를 전송하는 수집 엔드포인트를 참조합니다. + - 시크릿 관리자에서: + - 클러스터 URL을 정의합니다(예: `http://byoc-logs.acme.internal:7280`). **참고**: URL에는 포트가 포함되어야 합니다. + - Worker가 엔드포인트 URL에 `/api/v2/logs` 및 `/api/v1/validate`를 추가하므로 전달 또는 방화벽 규칙을 사용하는 경우 이러한 엔드포인트가 허용되어야 합니다. + - 기본 식별자는 `DESTINATION_CLOUDPREM_ENDPOINT_URL`입니다. + +{{% /tab %}} + +{{% tab "환경 변수" %}} + +{{< img src="observability_pipelines/destinations/cloudprem_env_vars.png" alt="BYOC Logs 환경 변수 필드가 표시된 설치 페이지" style="width:75%;" >}} + +- BYOC Logs 엔드포인트 URL + - Observability Pipelines는 BYOC Logs 수집 엔드포인트로 로그를 전송합니다. 클러스터 URL을 정의합니다(예: `http://byoc-logs.acme.internal:7280`). **참고**: URL에는 포트가 포함되어야 합니다. + - Worker가 엔드포인트 URL에 `/api/v2/logs` 및 `/api/v1/validate`를 추가하므로 전달 또는 방화벽 규칙을 사용하는 경우 이러한 엔드포인트가 허용되어야 합니다. + - 환경 변수 `DD_OP_DESTINATION_CLOUDPREM_ENDPOINT_URL`에 저장됩니다. + +{{% /tab %}} +{{< /tabs >}} + +## 상태 메트릭 {#health-metrics} + +모든 목적지에서 내보내는 [구성 요소 메트릭][7] 및 [목적지 버퍼 메트릭][8]은 [파이프라인 사용량 메트릭][9] 설명서를 참조하세요. Datadog Logs 목적지 메트릭을 필터링하거나 그룹화하려면 태그 `component_type:datadog_logs`를 사용하세요. + +## 목적지의 작동 방식 {#how-the-destination-works} + +### 이벤트 배치 처리{#event-batching} + +이벤트 배치는 다음 중 하나의 파라미터를 충족하면 플러시됩니다. 자세한 내용은 [목적지 이벤트 배치 처리][2]를 참조하세요. + +| 최대 이벤트 | 최대 크기(MB) | 타임아웃(초) | +|----------------|-------------------|---------------------| +| 1,000 | 4.25 | 5 | + +[1]: https://app.datadoghq.com/observability-pipelines +[2]: /ko/observability_pipelines/destinations/#event-batching +[3]: /ko/byoc-logs/install/ +[4]: /ko/observability_pipelines/configuration/set_up_pipelines/ +[5]: /ko/api/latest/observability-pipelines/ +[6]: https://registry.terraform.io/providers/datadog/datadog/latest/docs/resources/observability_pipeline +[7]: /ko/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#component-metrics +[8]: /ko/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#destination-buffer-metrics +[9]: /ko/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/ \ No newline at end of file diff --git a/hugo/content/ko/observability_pipelines/destinations/google_secops.md b/hugo/content/ko/observability_pipelines/destinations/google_secops.md new file mode 100644 index 00000000000..b9dba407fd6 --- /dev/null +++ b/hugo/content/ko/observability_pipelines/destinations/google_secops.md @@ -0,0 +1,87 @@ +--- +description: Observability Pipelines Worker를 사용하여 Google SecOps로 로그를 전송하는 방법을 알아보십시오. +disable_toc: false +products: +- icon: logs + name: 로그 + url: /observability_pipelines/configuration/?tab=logs#pipeline-types +title: Google SecOps 목적지 +--- +{{< product-availability >}} + +## 개요 {#overview} + +Observability Pipelines의 Google SecOps 목적지를 사용하여 Google SecOps로 로그를 전송하십시오. + +Observability Pipelines Worker는 표준 Google 인증 방식을 사용합니다. 사용 케이스에 적합한 인증 방식을 선택하는 방법에 대한 자세한 내용은 [Google의 인증 방법][3]을 참조하십시오. + +## 설정 {#setup} + +
비밀 관리의 경우: Google SecOps 엔드포인트 URL에 대한 식별자만 입력하십시오. 실제 값은 입력하지 마세요.
+ +[파이프라인을 설정][8]할 때 Google SecOps 목적지를 구성하십시오. Pipelines는 [UI][1]에서 설정할 수 있으며, [API][9] 또는 [Terraform][10]을 사용하여 설정할 수 있습니다. 이 섹션에서 설명하는 단계는 UI에서 설정합니다. + +Pipelines UI에서 Google SecOps 목적지를 선택한 후: + +1. Google SecOps 엔드포인트 URL에 대한 식별자를 입력하십시오. 비워두면 [기본값](#secret-defaults)이 사용됩니다. +1. Google SecOps 인스턴스의 고객 ID를 입력하십시오. +1. 자격 증명 JSON 파일이 있는 경우, 해당 파일의 경로를 입력합니다. 자격 증명 파일은 `DD_OP_DATA_DIR/config` 아래에 배치해야 합니다. 또는 `GOOGLE_APPLICATION_CREDENTIALS` 환경 변수를 사용하여 자격 증명 경로를 제공할 수 있습니다. + - Google Kubernetes Engine (GKE)에서 [워크로드 ID][6]를 사용하는 경우 `GOOGLE_APPLICATION_CREDENTIALS`가 자동으로 제공됩니다. + - Worker는 표준 [Google 인증 방식][7]을 사용합니다. +1. 드롭다운 메뉴에서 {{< ui >}}JSON{{< /ui >}} 또는 {{< ui >}}Raw{{< /ui >}} 인코딩을 선택하십시오. +1. 로그 유형을 입력하십시오. 로그의 특정 필드를 기반으로 서로 다른 로그 유형으로 로그를 라우팅하려면 [템플릿 구문][4]을 참조하십시오. + +{{% observability_pipelines/secrets_env_var_note %}} + +### 선택적 버퍼링 {#optional-buffering} + +{{% observability_pipelines/destination_buffer %}} + +**참고**: Google SecOps 목적지로 전송되는 로그에는 수집 레이블이 있어야 합니다. 예를 들어 로그가 A10 로드 밸런서에서 온 경우 수집 레이블`A10_LOAD_BALANCER`이 있어야 합니다. 사용 가능한 로그 유형 및 해당 수집 레이블 목록은 Google Cloud의 [기본 파서가 있는 지원 로그 유형][5]을 참조하십시오. + +## 시크릿 기본값 {#secret-defaults} + +{{% observability_pipelines/set_secrets_intro %}} + +{{< tabs >}} +{{% tab "시크릿 관리" %}} + +- Google Chronicle 엔드포인트 URL 식별자: + - 기본 식별자는 `DESTINATION_GOOGLE_CHRONICLE_UNSTRUCTURED_ENDPOINT_URL`입니다. + +{{% /tab %}} + +{{% tab "환경 변수" %}} + +{{% observability_pipelines/configure_existing_pipelines/destination_env_vars/chronicle %}} + +{{% /tab %}} +{{< /tabs >}} + +## 상태 메트릭 {#health-metrics} + +모든 목적지에서 내보내는 [구성 요소 메트릭][11] 및 [목적지 버퍼 메트릭][12]은 [Pipelines 사용량 메트릭][13] 설명서를 참조하십시오. Google SecOps 목적지 메트릭을 필터링하거나 그룹화하려면 태그 `component_type:gcp_chronicle_unstructured`을 사용하십시오. + +## 목적지의 작동 방식 {#how-the-destination-works} + +### 이벤트 배치 처리 {#event-batching} + +이벤트 배치는 다음 중 하나의 파라미터를 충족하면 플러시됩니다. 자세한 내용은 [목적지 이벤트 배치 처리][2]를 참조하세요. + +| 최대 이벤트 | 최대 크기(MB) | 타임아웃(초) | +|----------------|-------------------|---------------------| +| 없음 | 1 | 15 | + +[1]: https://app.datadoghq.com/observability-pipelines +[2]: /ko/observability_pipelines/destinations/#event-batching +[3]: https://cloud.google.com/docs/authentication#auth-flowchart +[4]: /ko/observability_pipelines/destinations/#template-syntax +[5]: https://cloud.google.com/chronicle/docs/ingestion/parser-list/supported-default-parsers#with-default-parser +[6]:https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity +[7]: https://cloud.google.com/docs/authentication#auth-flowchart +[8]: /ko/observability_pipelines/configuration/set_up_pipelines/ +[9]: /ko/api/latest/observability-pipelines/ +[10]: https://registry.terraform.io/providers/datadog/datadog/latest/docs/resources/observability_pipeline +[11]: /ko/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#component-metrics +[12]: /ko/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#destination-buffer-metrics +[13]: /ko/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/ \ No newline at end of file diff --git a/hugo/content/ko/observability_pipelines/destinations/syslog.md b/hugo/content/ko/observability_pipelines/destinations/syslog.md new file mode 100644 index 00000000000..db49ba25194 --- /dev/null +++ b/hugo/content/ko/observability_pipelines/destinations/syslog.md @@ -0,0 +1,92 @@ +--- +description: Observability Pipelines Worker를 사용하여 rsyslog 또는 syslog-ng로 로그를 전송하는 방법을 + 알아봅니다. +disable_toc: false +products: +- icon: logs + name: 로그 + url: /observability_pipelines/configuration/?tab=logs#pipeline-types +title: Syslog 대상 +--- +{{< product-availability >}} + +## 개요 {#overview} + +Observability Pipelines의 syslog 대상을 사용하여 rsyslog 또는 syslog-ng로 로그를 전송합니다. + +**참고**: rsyslog 및 syslog-ng 대상은 [RFC5424][5] 형식을 지원합니다. + +## 설정 {#setup} + +
시크릿 관리: syslog 엔드포인트 URL에 대한 식별자와 해당하는 경우 키 암호만 입력하십시오. 실제 값은 입력하지 마세요.
+ +[파이프라인을 설정할 때][2] rsyslog 또는 syslog-ng 대상을 구성하십시오. 파이프라인은 [UI][1], [API][3] 또는 [Terraform][4]을 사용하여 설정할 수 있습니다. 이 섹션에서 설명하는 단계는 UI에서 설정합니다. + +파이프라인 UI에서 rsyslog 또는 syslog-ng 대상을 선택한 후, 엔드포인트 URL에 대한 식별자를 입력하십시오. 비워두면 [기본값](#secret-defaults)이 사용됩니다. + +필드가 매핑되는 방법에 대한 자세한 내용은 [로그 필드를 syslog 필드에 매핑](#matching-log-fields-to-syslog-fields)을 참조하십시오. + +{{% observability_pipelines/secrets_env_var_note %}} + +### 선택적 설정 {#optional-settings} + +#### TLS 활성화 {#enable-tls} + +{{% observability_pipelines/tls_settings %}} + +#### TCP keepalive 프로브 대기 시간 {#wait-time-for-tcp-keepalive-probes} + +유휴 연결에서 TCP keepalive 프로브를 보내기 전에 대기할 시간(초)을 입력하십시오. + +#### 버퍼링 {#buffering} + +{{% observability_pipelines/destination_buffer %}} + +## 로그 필드를 syslog 필드에 매핑 {#matching-log-fields-to-syslog-fields} + +rsyslog 및 syslog-ng 대상은 이러한 로그 필드를 다음 syslog 필드에 매핑합니다: + +| 로그 이벤트 | SYSLOG 필드 | 기본값 | +|-----------------|--------------|----------------------------| +| log["message"] | MESSAGE | `NIL` | +| log[\"procid\"] | PROCID | 실행 중인 Worker의 프로세스 ID입니다. | +| log["appname"] | APP-NAME | `observability_pipelines` | +| log[\"facility\"] | FACILITY | `8 (log_user)` | +| log["msgid"] | MSGID | `NIL` | +| log["severity"] | SEVERITY | `info` | +| log["host"] | HOSTNAME | `NIL` | +| log[\"timestamp\"]| TIMESTAMP | 현재 UTC 시간입니다. | + +## 시크릿 기본값 {#secret-defaults} + +{{% observability_pipelines/set_secrets_intro %}} + +{{< tabs >}} +{{% tab "시크릿 관리" %}} + +- rsyslog 또는 syslog-ng 엔드포인트 URL 식별자: + - Observability Pipelines Worker가 로그를 전송할 주소 및 포트를 참조합니다. 예를 들어, `127.0.0.1:9997`입니다. + - 기본 식별자는 `DESTINATION_SYSLOG_ENDPOINT_URL`입니다. +- rsyslog 또는 syslog-ng TLS 암호 식별자(TLS가 활성화된 경우): + - 기본 식별자는 `DESTINATION_SYSLOG_KEY_PASS`입니다. + +{{% /tab %}} + +{{% tab "환경 변수" %}} + +{{% observability_pipelines/configure_existing_pipelines/destination_env_vars/syslog %}} + +{{% /tab %}} +{{< /tabs >}} + +## 대상 작동 방식 {#how-the-destination-works} + +### 이벤트 배치 처리 {#event-batching} + +rsyslog 및 syslog-ng 대상은 이벤트를 일괄 처리하지 않습니다. + +[1]: https://app.datadoghq.com/observability-pipelines +[2]: /ko/observability_pipelines/configuration/set_up_pipelines/ +[3]: /ko/api/latest/observability-pipelines/ +[4]: https://registry.terraform.io/providers/datadog/datadog/latest/docs/resources/observability_pipeline +[5]: https://datatracker.ietf.org/doc/html/rfc5424 \ No newline at end of file diff --git a/hugo/content/ko/observability_pipelines/packs/aviatrix_l7_tls_inspection.md b/hugo/content/ko/observability_pipelines/packs/aviatrix_l7_tls_inspection.md new file mode 100644 index 00000000000..b8735499a96 --- /dev/null +++ b/hugo/content/ko/observability_pipelines/packs/aviatrix_l7_tls_inspection.md @@ -0,0 +1,15 @@ +--- +description: Aviatrix L7/TLS Inspection 팩에 대해 자세히 알아보세요. +title: Aviatrix L7/TLS Inspection +--- +## 개요 {#overview} + +{{< img src="observability_pipelines/packs/aviatrix_l7_tls_inspection.png" alt="Aviatrix L7/TLS Inspection 팩" style="width:25%;" >}} + +Aviatrix L7/TLS Inspection 로그는 TLS 세션 컨텍스트 및 정책 적용을 캡처합니다. + +이 팩의 기능은 다음과 같습니다. + +- HTTPS 및 TLS 컨텍스트를 탐지합니다. +- SNI 호스트 이름 및 정책에 태그를 지정합니다. +- 거부된 TLS 흐름을 플래깅합니다. \ No newline at end of file diff --git a/hugo/content/ko/observability_pipelines/processors/generate_metrics.md b/hugo/content/ko/observability_pipelines/processors/generate_metrics.md index 1cc753140cc..42c690a3aca 100644 --- a/hugo/content/ko/observability_pipelines/processors/generate_metrics.md +++ b/hugo/content/ko/observability_pipelines/processors/generate_metrics.md @@ -1,4 +1,6 @@ --- +description: 쿼리와 일치하는 로그에서 카운트, 게이지 또는 분포 메트릭을 생성하기 위해 Generate Metrics 프로세서를 사용하는 + 방법을 알아보십시오. disable_toc: false products: - icon: logs diff --git a/hugo/content/ko/observability_pipelines/processors/grok_parser.md b/hugo/content/ko/observability_pipelines/processors/grok_parser.md new file mode 100644 index 00000000000..46e02454c7d --- /dev/null +++ b/hugo/content/ko/observability_pipelines/processors/grok_parser.md @@ -0,0 +1,119 @@ +--- +description: Grok Parser 프로세서를 사용하여 사용자 지정 또는 비표준 로그를 구조화하는 구문 분석 규칙을 생성하는 방법을 알아보세요. +disable_toc: false +further_reading: +- link: https://www.datadoghq.com/blog/otel-ai-observability-pipelines-clickhouse/ + tag: 블로그 + text: Observability Pipelines를 사용하여 AI 앱의 OTel 데이터를 ClickHouse 및 Datadog으로 라우팅 +- link: https://www.datadoghq.com/blog/observability-pipelines-mssp + tag: 블로그 + text: Datadog Observability Pipelines를 사용하여 MSSP의 로그 수집 및 집계 간소화 +products: +- icon: logs + name: 로그 + url: /observability_pipelines/configuration/?tab=logs#pipeline-types +title: Grok Parser 프로세서 +--- +{{< product-availability >}} + +{{< callout url="#" btn_hidden="true" header="미리 보기에 참여하세요!" >}} +규칙별 필터 및 AI 생성 구문 분석 규칙은 미리 보기로 제공되고 있습니다. 액세스 권한을 요청하려면 계정 관리자에게 문의하세요. +{{< /callout >}} + +## 개요 {#overview} + +사용자 지정 애플리케이션 또는 비표준 로그는 구조화된 형식으로 구문 분석하기 어려운 경우가 많습니다. 이 문제를 해결하려면 Grok Parser 프로세서를 사용하여 AI로 구문 분석 규칙을 생성하거나, 공급업체별 형식(예: Apache, Airflow, MySQL)에 라이브러리 규칙을 적용하거나, 직접 구문 분석 규칙을 생성하세요. 그런 다음 샘플 데이터에서 규칙을 테스트하여 구문을 검증하고 구문 분석된 로그 출력을 미리 보세요. + +**참고**: +- 구문 분석하려는 각 필드에 대해 별도의 Grok Parser를 생성해야 합니다. +- 로그는 일치하는 첫 번째 규칙에 의해서만 구문 분석되므로 [규칙의 순서가 중요합니다](#order-of-custom-rules). +- 2.17 이전 버전의 Worker를 사용하는 경우, 프로세서가 로그를 구문 분석하려면 로그에 `source` 또는 `ddsource` 필드와 `message` 필드가 있어야 합니다. + +## 설정 {#setup} + +Grok Parser 프로세서는 다음 작업을 수행합니다. + +1. 프로세서 수준 필터 쿼리를 사용하여 구문 분석 도구로 전송되는 로그를 결정합니다. +1. 로그에서 구문 분석할 지정된 필드를 식별합니다. +1. (미리 보기) 규칙 수준 필터 쿼리를 사용하여 로그와 일치하는 첫 번째 구문 분석 규칙을 적용합니다. +1. 지정된 로그 필드를 규칙의 출력으로 덮어쓴 다음 로그를 파이프라인의 다음 단계로 전송합니다. + +{{< img src="observability_pipelines/processors/grok_parser_setup.png" alt="필터 쿼리 및 구문 분석할 필드 설정을 보여주는 Grok Parser 프로세서 패널입니다." style="width:50%;" >}} + +Grok Parser 프로세서를 설정하려면 다음 단계를 따르세요. + +1. 프로세서 수준 필터 쿼리를 정의합니다. 이 필터 쿼리와 일치하는 로그만 구문 분석 도구로 전송됩니다. 모든 로그는 프로세서에 의해 구문 분석되는지 여부에 관계없이 파이프라인의 다음 단계로 전송됩니다. 쿼리 생성에 대한 자세한 내용은 [로그 검색 구문][3]을 참조하세요. +1. 구문 분석할 로그 필드를 입력합니다. 예를 들어, `logmessage`를 입력하면 `logmessage` 특성의 콘텐츠가 구문 분석됩니다. 필드가 지정되지 않은 경우 `message`가 기본 필드로 사용됩니다. +1. {{< ui >}}Enable Library Rules{{< /ui >}}를 꺼서 모든 라이브러리 구문 분석 규칙을 비활성화합니다. +
**참고**: + - 라이브러리 규칙을 비활성화하려면 먼저 사용자 지정 구문 분석 규칙을 생성해야 합니다. + - 라이브러리 규칙은 기본적으로 적용됩니다. 사용자 지정 구문 분석 규칙을 사용하는 경우에만 라이브러리 규칙을 비활성화하세요. +1. {{< ui >}}View Library Rules{{< /ui >}}를 클릭하여 통합을 위한 사전 설정 규칙을 미리 봅니다. 로그 샘플을 사용하여 기본 제공 구문 분석 규칙을 테스트할 수 있습니다. 자세한 내용은 [라이브러리 규칙](#library-rules)을 참조하세요. + +### AI 생성 또는 사용자 지정 구문 분석 규칙 생성 {#create-an-ai-generated-or-custom-parsing-rule} + +AI 지원 또는 사용자 지정 구문 분석 규칙을 설정하려면 Grok Parser 프로세서에서 {{< ui >}}Create Parsing Rules{{< /ui >}}를 클릭하세요. + +1. 구문 분석 규칙의 이름을 입력합니다. +1. (미리 보기) 이 규칙이 적용될 로그를 정의하기 위한 필터 쿼리를 입력합니다. Grok Parser는 로그가 규칙별 필터 쿼리와 일치하는 경우에만 규칙을 실행하므로 서로 다른 로그 형식에 서로 다른 구문 분석 규칙을 적용할 수 있습니다. 쿼리 생성에 대한 자세한 내용은 [로그 검색 구문][3]을 참조하세요. +1. 구문 분석하려는 로그 샘플을 입력합니다. 샘플은 Live Capture에서 복사하거나 다른 소스에서 붙여넣을 수 있습니다. +1. (미리 보기) {{< ui >}}Generate New Rule{{< /ui >}}을 클릭하여 AI가 샘플 로그를 기반으로 새 구문 분석 규칙을 생성하도록 합니다. 그렇지 않으면 [수동으로 규칙 작성](#manually-write-rules)을 참조하여 직접 규칙을 작성합니다. + 1. {{< ui >}}Preview Changes{{< /ui >}} 패널에서 구문 분석된 로그를 검토합니다. + 1. 로그가 올바르게 구문 분석되도록 {{< ui >}}Generate New Rule{{< /ui >}}을 클릭하여 AI 규칙 생성기를 다시 실행하거나 규칙을 수동으로 업데이트합니다. 구문 분석 규칙 작성에 대한 자세한 내용은 [구문 분석][1]을 참조하세요. +
**참고**: + - AI 규칙 생성기를 다시 실행하면 새 규칙이 생성됩니다. 이전에 AI가 생성한 규칙을 원하지 않는 경우, 수동으로 삭제해야 합니다. + - 샘플당 최대 3회까지 AI 규칙 생성기를 실행할 수 있습니다. + 1. 4단계를 반복하여 추가 샘플 로그를 기반으로 규칙을 생성합니다. 규칙 순서에 따라 로그를 구문 분석할 규칙이 결정되는 방법에 대한 자세한 내용은 [사용자 지정 규칙 순서](#order-of-custom-rules)를 참조하세요. +1. 규칙을 추가한 후 {{< ui >}}reference a library rule{{< /ui >}} 드롭다운 메뉴에서 라이브러리 규칙을 선택하여 라이브러리 규칙을 추가할 수 있습니다. 여러 라이브러리 규칙을 추가할 수 있습니다. 자세한 내용은 [라이브러리 규칙](#library-rules)을 참조하세요. +1. 도우미 규칙을 추가하려면 {{< ui >}}Advanced Settings{{< /ui >}}를 클릭합니다. 자세한 내용은 [공통 패턴을 재사용하기 위해 도우미 규칙 사용][2]을 참조하세요. +1. {{< ui >}}Create Rule{{< /ui >}}을 클릭합니다. + +{{< img src="observability_pipelines/processors/grok_parser_create_rule.png" alt="Grok Parser 프로세서의 Create Parsing Rule 모달입니다." style="width:50%;" >}} + +로그가 구문 분석 도구로 전송되었지만 어떤 규칙으로도 구문 분석되지 않는 경우, Worker는 `The parser failed to apply rule` 오류가 포함된 로그를 생성합니다. + +#### 사용자 지정 규칙 순서 {#order-of-custom-rules} + +Grok Parser 프로세서에 대해 여러 사용자 지정 규칙이 있는 경우, 로그는 쿼리가 일치하는 첫 번째 규칙에 의해 구문 분석된 다음 파이프라인의 다음 단계로 전송됩니다. 프로세서는 로그를 후속 규칙과 일치시키려고 시도하지 않습니다. 따라서 로그가 여러 규칙과 일치할 수 있는 경우 규칙의 순서가 중요합니다. 규칙의 순서를 변경하려면 규칙을 끌어다가 원하는 순서로 놓으세요. + +##### 예시 {#example} + +다음 구문 분석 규칙을 사용하는 구문 분석 도구를 고려해 보세요. + +1. 규칙 예시 1 +1. 규칙 예시 2 +1. 규칙 예시 3 + +구문 분석 도구로 전송된 로그가 세 가지 규칙 쿼리와 모두 일치하는 경우, 해당 로그는 규칙 2와 3보다 먼저 나열되어 있으므로 규칙 예시 1에 의해서_만_ 구문 분석됩니다. + +{{< img src="observability_pipelines/processors/grok_parser_rule_order.png" alt="Grok Parser 프로세서에 순서대로 나열된 세 가지 구문 분석 규칙입니다." style="width:50%;" >}} + +#### 수동으로 규칙 작성 {#manually-write-rules} + +구문 분석 규칙을 수동으로 작성하려면 {{< ui >}}Create Parsing Rule{{< /ui >}} 모달에서 다음 단계를 따르세요. + +1. {{< ui >}}write rules manually{{< /ui >}}를 클릭합니다. +1. 로그를 구문 분석하기 위한 규칙을 입력합니다. Datadog Grok 패턴을 사용하여 구문 분석 규칙을 작성하는 방법에 대한 자세한 내용은 [구문 분석][1]을 참조하세요. **참고**: `url`, `useragent` 및 `csv` 필터는 사용할 수 없습니다. +1. {{< ui >}}Preview Changes{{< /ui >}} 패널에서 구문 분석된 로그를 검토하고 로그가 예상대로 구문 분석될 때까지 규칙을 업데이트합니다. +1. {{< ui >}}Add rule{{< /ui >}}을 클릭하여 다른 규칙을 수동으로 작성합니다. + +### 라이브러리 규칙 {#library-rules} + +로그가 구문 분석 도구로 전송되면 `source` 또는 `ddsource` 필드가 있는 경우 라이브러리 규칙이 로그에 자동으로 적용됩니다. 예를 들어, 로그에 `source:mysql`이 있는 경우 구문 분석 도구는 해당 로그에 MySQL 라이브러리 규칙을 적용합니다. 사용 가능한 모든 라이브러리 규칙을 찾아보려면 Grok Parser 프로세서에서 {{< ui >}}View Library Rules{{< /ui >}}를 클릭하세요. 라이브러리 규칙 표를 검색하고 규칙을 클릭하여 로그에 어떻게 적용되는지 미리 볼 수 있습니다. + +사용자 지정 규칙을 생성할 때 라이브러리 규칙을 추가할 수도 있습니다. 자세한 내용은 [AI 지원 또는 사용자 지정 구문 분석 규칙 생성](#create-an-ai-assisted-or-custom-parsing-rule)을 참조하세요. + +## 상태 메트릭 {#health-metrics} + +모든 프로세서에서 내보내는 [구성 요소 메트릭][4] 및 [프로세서 버퍼 메트릭][5]에 대한 자세한 내용은 [파이프라인 사용량 메트릭][6] 설명서를 참조하세요. Parse 프로세서 메트릭별로 필터링하거나 그룹화하려면 `component_type:parse` 태그를 사용하세요. + +[1]: /ko/logs/log_configuration/parsing/ +[2]: /ko/logs/log_configuration/parsing/?tab=matchers#using-helper-rules-to-reuse-common-patterns +[3]: /ko/observability_pipelines/search_syntax/logs/ +[4]: /ko/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#component-metrics +[5]: /ko/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#processor-buffer-metrics +[6]: /ko/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/ + +## 추가 자료 {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} \ No newline at end of file diff --git a/hugo/content/ko/observability_pipelines/processors/quota.md b/hugo/content/ko/observability_pipelines/processors/quota.md new file mode 100644 index 00000000000..f1e01aac003 --- /dev/null +++ b/hugo/content/ko/observability_pipelines/processors/quota.md @@ -0,0 +1,135 @@ +--- +description: Quota 프로세서를 사용하여 로깅 트래픽을 측정하고, 일일 할당량에 도달한 후 로그를 유지, 삭제 또는 라우팅하는 방법을 + 알아보세요. +disable_toc: false +products: +- icon: logs + name: 로그 + url: /observability_pipelines/configuration/?tab=logs#pipeline-types +title: Quota 프로세서 +--- +{{< product-availability >}} + +## 개요 {#overview} + +Quota 프로세서는 지정한 필터와 일치하는 로그에 대한 로깅 트래픽을 측정합니다. 이 프로세서는 UTC 자정에 재설정되는 고정된 24시간 기간을 사용합니다. 기간 내에서 구성된 일일 할당량이 충족되면 프로세서는 추가 로그를 유지 또는 삭제하거나 스토리지 버킷으로 전송할 수 있습니다. 예를 들어, 프로세서가 지난 24시간 동안 특정 서비스로부터 천만 개의 이벤트를 수신한 후 새 로그를 삭제하거나 로그를 삭제하지 않고 경보를 발생시키도록 이 프로세서를 구성할 수 있습니다. + +`service`, `env`, `status`와 같은 필드 기반 파티셔닝을 사용할 수도 있습니다. 각 고유 필드는 자체 일일 할당량 제한이 있는 별도의 할당량 버킷을 사용합니다. 자세한 내용은 [파티션 예시](#partition-example)를 참조하세요. + +**참고**: 파이프라인은 할당량의 이름을 사용하여 Worker의 여러 Remote Configuration 배포에서 동일한 할당량을 식별합니다. + +### 제한 {#limits} + +- 각 파이프라인에는 최대 1,000개의 버킷이 있을 수 있습니다. 버킷 제한을 늘려야 하는 경우 [지원팀에 문의][5]하세요. +- Quota 프로세서는 Datadog 조직 내의 모든 Worker 간에 동기화됩니다. 이 동기화에는 조직당 기본적으로 최대 100개의 Worker 제한이 있습니다(Worker 버전 2.16 이상인 경우 300개). 조직의 Worker 수가 이 제한을 초과하는 경우: + - 프로세서는 계속 실행되지만 다른 Worker와 올바르게 동기화되지 않아 할당량 제한에 도달한 이후에도 로그가 전송될 수 있습니다. + - Worker는 `Failed to sync quota state` 오류를 출력합니다. + - 조직당 기본 Worker 수를 늘리려면 [지원팀에 문의][5]하세요. +- Quota 프로세서는 1분당 몇 번씩 Worker 간의 개수를 주기적으로 동기화합니다. 따라서 프로세서에 설정된 제한은 Worker 수와 로그 처리량에 따라 초과될 수 있습니다. Datadog은 프로세서가 분당 수신할 것으로 예상되는 로그 볼륨보다 한 자릿수 이상 더 크게 제한을 설정할 것을 권장합니다. Quota 프로세서와 함께 Throttle 프로세서를 사용하여 분당 허용되는 로그 수를 제한함으로써 이러한 짧은 급증을 제어할 수 있습니다. + +## 설정 {#setup} + +Quota 프로세서를 설정하려면 다음 단계를 따르세요. +1. Quota 프로세서 이름을 입력합니다. +1. {{< ui >}}filter query{{< /ui >}}를 정의합니다. 지정된 필터 쿼리와 일치하는 로그만 일일 제한에 포함됩니다. 자세한 내용은 [검색 구문][6]을 참조하세요. + - 할당량 필터와 일치하고 일일 할당량 내에 있는 로그는 파이프라인의 다음 단계로 전송됩니다. + - 할당량 필터와 일치하지 않는 로그는 파이프라인의 다음 단계로 전송됩니다. +1. {{< ui >}}Unit for quota{{< /ui >}} 드롭다운 메뉴에서 할당량을 `Events` 수로 측정할지, 아니면 바이트 단위 `Volume`으로 측정할지 선택합니다. +1. 일일 할당량 제한을 설정하고 원하는 할당량의 크기 단위를 선택합니다. +1. 선택 사항: 특정 서비스 또는 리전 필드에 할당량을 설정하려면 {{< ui >}}Add Field{{< /ui >}}를 클릭합니다. + 1. 파티셔닝하려는 기준 필드 이름을 입력합니다. 자세한 내용은 [파티션 예시](#partition-example)를 참조하세요. + 1. 파티션과 일치하는 이벤트에만 할당량을 적용하려면 {{< ui >}}Ignore when missing{{< /ui >}}을 선택합니다. 자세한 내용은 [Ignore when missing 예시](#example-for-the-ignore-when-missing-option)를 참조하세요. + 1. 선택 사항: 파티셔닝된 필드에 대해 서로 다른 할당량을 설정하려면 {{< ui >}}Overrides{{< /ui >}}를 클릭합니다. + - CSV 구조화 방법에 대한 예시를 보려면 {{< ui >}}Download as CSV{{< /ui >}}를 클릭합니다. + - 재정의 CSV를 끌어다 놓아 업로드합니다. {{< ui >}}Browse{{< /ui >}}를 클릭하여 업로드할 파일을 선택할 수도 있습니다. 자세한 내용은 [재정의 예시](#overrides-example)를 참조하세요. + 1. 다른 파티션을 추가하려면 {{< ui >}}Add Field{{< /ui >}}를 클릭합니다. +1. {{< ui >}}When quota is met{{< /ui >}} 드롭다운 메뉴에서 할당량이 충족되었을 때 원하는 옵션을 {{< ui >}}drop events{{< /ui >}}, {{< ui >}}keep events{{< /ui >}}, {{< ui >}}send events to overflow destination{{< /ui >}} 중에서 선택합니다. + 1. {{< ui >}}send events to overflow destination{{< /ui >}}을 선택하면 클라우드 스토리지 옵션: **Amazon S3**, **Azure Blob** 및 **Google Cloud**와 함께 오버플로 대상이 추가됩니다. + 1. 오버플로 로그를 보내려는 클라우드 스토리지를 선택합니다. 클라우드 스토리지: [Amazon S3][2], [Azure Blob Storage][3] 또는 [Google Cloud Storage][4]에 대한 설정 지침을 참조하세요. + +### 예시 {#examples} + +#### 파티션 예시 {#partition-example} + +특정 서비스나 리전에 할당량을 설정하려면 {{< ui >}}Partition by{{< /ui >}}를 사용하세요. 예를 들어, 하루에 10개 이벤트에 대한 할당량을 설정하고 `service` 필드별로 이벤트를 그룹화하려면 {{< ui >}}Partition by{{< /ui >}} 필드에 `service`를 입력합니다. + +#### 'ignore when missing' 옵션의 예시 {#example-for-the-ignore-when-missing-option} + +파티션과 일치하는 이벤트에만 할당량을 적용하려면 {{< ui >}}Ignore when missing{{< /ui >}}을 선택합니다. 예를 들어, Worker가 다음과 같은 이벤트 세트를 수신하고 + +``` +{"service":"a", "source":"foo", "message": "..."} +{"service":"b", "source":"bar", "message": "..."} +{"service":"b", "message": "..."} +{"source":"redis", "message": "..."} +{"message": "..."} +``` + +{{< ui >}}Ignore when missing{{< /ui >}}이 선택되면 Worker는 다음과 같이 동작합니다. +- `service:a` 및 `source:foo`가 포함된 로그용 세트를 생성합니다. +- `service:b` 및 `source:bar`가 포함된 로그용 세트를 생성합니다. +- 마지막 세 가지 이벤트를 무시합니다. + +할당량은 마지막 세 개의 이벤트가 아닌 두 개의 로그 세트에 적용됩니다. + +{{< ui >}}Ignore when missing{{< /ui >}}이 선택되지 않으면 5개 이벤트 모두에 할당량이 적용됩니다. + +#### 재정의 예시 {#overrides-example} + +`service`별로 파티셔닝하고 두 가지 서비스: `a` 및 `b`가 있는 경우, 재정의를 사용하여 각 서비스에 서로 다른 할당량을 적용할 수 있습니다. 예를 들어, `service:a`의 할당량 제한을 5,000바이트로 설정하고 `service:b`의 제한을 50개 이벤트로 설정하려는 경우 재정의 규칙은 다음과 같습니다. + +| 서비스 | 유형 | 제한 | +| ------- | ------ | ----- | +| `a` | 바이트 | 5,000 | +| `b` | 이벤트 | 50 | + +## 상태 메트릭 {#health-metrics} + +모든 프로세서에서 내보내는 [구성 요소 메트릭][7] 및 [프로세서 버퍼 메트릭][8]에 대한 자세한 내용은 [파이프라인 사용량 메트릭][9] 설명서를 참조하세요. + +### Quota 메트릭 {#quota-metrics} + +- `component_id` 태그를 사용하여 개별 구성 요소별로 필터링하거나 그룹화하세요. +- `component_type` 태그가 이러한 메트릭의 `quota`입니다. + +`pipelines.quota_reached_events_total` +: **설명**: 구성된 할당량 제한에 도달한 후 수신되어 삭제된 이벤트 수입니다. +: **메트릭 유형**: 개수 + +`pipelines.quota_reached_event_bytes_total` +: **설명**: 구성된 할당량 제한에 도달한 후 수신되어 삭제된 이벤트의 크기(바이트)입니다. +: **메트릭 유형**: 개수 + +`pipelines.quota_overflow_destination_sent_events_total` +: **설명**: 할당량 제한에 도달했을 때 보조 오버플로 대상으로 라우팅된 이벤트 수입니다. +: **메트릭 유형**: 개수 + +`pipelines.quota_fill` +: **설명**: 속도 제한 할당량 버킷의 현재 채우기 수준이며, 값 범위는 `0`에서 `100`까지입니다. +: **메트릭 유형**: 게이지 + +`pipelines.quotas_usage` +: **설명**: 모든 할당량 버킷의 총 채우기 수준이며, 값 범위는 `0`에서 `100`까지입니다. +: **메트릭 유형**: 게이지 + +`pipelines.quota_limit_events` +: **설명**: 할당량 규칙에 대해 구성된 간격당 최대 이벤트 처리량입니다. +: **메트릭 유형**: 게이지 + +`pipelines.quota_limit_bytes` +: **설명**: 할당량 규칙에 대해 구성된 간격당 최대 바이트 처리량입니다. +: **메트릭 유형**: 게이지 + +`pipelines.quotas_count` +: **설명**: 현재 추적 중인 활성 속도 제한 할당량 버킷의 수입니다. +: **메트릭 유형**: 게이지 + +[1]: /ko/monitors/types/metric/?tab=threshold +[2]: /ko/observability_pipelines/destinations/datadog_archives/ +[3]: /ko/observability_pipelines/destinations/azure_storage/ +[4]: /ko/observability_pipelines/destinations/google_cloud_storage/ +[5]: /ko/help/ +[6]: /ko/observability_pipelines/search_syntax/logs/ +[7]: /ko/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#component-metrics +[8]: /ko/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#processor-buffer-metrics +[9]: /ko/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/ \ No newline at end of file diff --git a/hugo/content/ko/observability_pipelines/processors/sensitive_data_scanner.md b/hugo/content/ko/observability_pipelines/processors/sensitive_data_scanner.md new file mode 100644 index 00000000000..b59823a6358 --- /dev/null +++ b/hugo/content/ko/observability_pipelines/processors/sensitive_data_scanner.md @@ -0,0 +1,411 @@ +--- +description: Sensitive Data Scanner 프로세서를 사용하여 로그나 트레이스에서 개인 식별 정보(PII) 및 결제 카드 산업(PCI) + 데이터와 같은 민감한 정보를 탐지하고 비식별화하거나 해싱하는 방법을 알아보세요. +disable_toc: false +further_reading: +- link: /logs/guide/regex_log_parsing/ + tag: 가이드 + text: 정규 표현식을 사용하여 효과적인 Grok 구문 분석 규칙 작성하기 +- link: https://www.datadoghq.com/blog/otel-ai-observability-pipelines-clickhouse/ + tag: 블로그 + text: Observability Pipelines를 사용하여 AI 앱의 OTel 데이터를 ClickHouse 및 Datadog으로 라우팅하기 +products: +- icon: logs + name: 로그 + url: /observability_pipelines/configuration/?tab=logs#pipeline-types +title: Sensitive Data Scanner 프로세서 +--- +{{< product-availability >}} + +## 개요 {#overview} + +Sensitive Data Scanner 프로세서는 로그를 스캔하여 PII, PCI 및 사용자 지정 민감 데이터와 같은 민감 정보를 탐지하고 비식별화하거나 해싱합니다. Datadog의 사전 정의된 라이브러리 규칙 중에서 선택하거나 사용자 지정 정규식 규칙을 입력하여 민감 데이터를 스캔할 수 있습니다. + +파이프라인과 프로세서는 [UI](#set-up-the-processor-in-the-ui), [API][10] 또는 [Terraform](#set-up-the-processor-using-terraform)에서 설정할 수 있습니다. + +리소스 사용량을 줄이는 방법은 [성능 최적화 모범 사례](#best-practices-to-optimize-performance)를 참조하세요. + +## UI에서 프로세서 설정 {#set-up-the-processor-in-the-ui} + +프로세서를 설정하려면 다음 단계를 따르세요. + +1. {{< ui >}}filter query{{< /ui >}}를 정의합니다. 자세한 내용은 [로그 검색 구문][1]을 참조하세요. + - 필터와 일치하는 이벤트만 스캔 및 처리됩니다. + - 모든 이벤트는 필터 쿼리와 일치하는지 여부에 관계없이 파이프라인의 다음 단계로 전송됩니다. +1. {{< ui >}}Add Scanning Rule{{< /ui >}}을 클릭합니다. +1. 다음 중 하나를 선택합니다. + +{{< tabs >}} +{{% tab "라이브러리 규칙" %}} + +1. 드롭다운 메뉴에서 사용할 라이브러리 규칙을 선택합니다. +1. 선택한 라이브러리 규칙에 따라 권장 키워드가 자동으로 추가됩니다. 스캔 규칙을 추가한 후 [키워드를 추가하거나 권장 키워드를 제거](#add-additional-keywords)할 수 있습니다. +1. {{< ui >}}Define rule target and conditions{{< /ui >}} 섹션의 드롭다운 메뉴에서 {{< ui >}}Entire Event{{< /ui >}}, {{< ui >}}Specific Attributes{{< /ui >}} 또는 {{< ui >}}Exclude Attributes{{< /ui >}} 중 무엇을 스캔할지 선택합니다. + - 전체 이벤트를 스캔하는 경우, 특정 속성을 스캔 대상에서 선택적으로 제외할 수 있습니다. 중첩된 키에 액세스하려면 [경로 표기법](#path-notation-example)(`outer_key.inner_key`)을 사용하세요. 중첩된 데이터가 있는 속성을 지정하면 해당 속성의 모든 중첩된 데이터가 제외됩니다. + - 특정 속성을 스캔하는 경우 스캔할 속성을 지정하세요. 중첩된 키에 액세스하려면 [경로 표기법](#path-notation-example)(`outer_key.inner_key`)을 사용하세요. 중첩된 데이터가 있는 속성을 지정하면 해당 속성의 모든 중첩된 데이터가 스캔됩니다. +1. {{< ui >}}Define actions on match{{< /ui >}}에서 일치하는 정보에 대해 수행할 액션을 선택합니다. **참고**: 비식별화, 부분 비식별화 및 해싱은 모두 되돌릴 수 없는 작업입니다. + - {{< ui >}}Redact{{< /ui >}}: 일치하는 모든 값을 {{< ui >}}Replacement text{{< /ui >}} 필드에서 지정한 텍스트로 대체합니다. + - {{< ui >}}Partially Redact{{< /ui >}}: 일치하는 모든 데이터에서 지정된 부분을 대체합니다. {{< ui >}}Redact{{< /ui >}} 섹션에서 비식별화할 문자 수와 일치하는 데이터의 어느 부분을 비식별화할지 지정합니다. + - {{< ui >}}Hash{{< /ui >}}: 일치하는 모든 데이터를 고유 식별자로 대체합니다. 일치하는 UTF-8 바이트를 FarmHash의 64비트 지문으로 해시합니다. +1. 필요시 {{< ui >}}Add Field{{< /ui >}}를 클릭하여 일치하는 이벤트와 연결할 태그를 추가합니다. +1. 스캔 규칙의 이름을 추가합니다. +1. 필요시 규칙 설명을 추가합니다. +1. {{< ui >}}Save{{< /ui >}}를 클릭합니다. + +### 키워드 추가 {#add-additional-keywords} + +라이브러리에서 스캔 규칙을 추가한 후 각 규칙을 개별적으로 편집하고 키워드 사전에 키워드를 추가할 수 있습니다. + +1. [파이프라인][1]으로 이동합니다. +1. 편집하려는 규칙이 있는 Sensitive Data Scanner 프로세서에서 {{< ui >}}Manage Scanning Rules{{< /ui >}}를 클릭합니다. +1. 규칙에서 권장 키워드를 사용하려면 {{< ui >}}Use recommended keywords{{< /ui >}}를 활성화합니다. 그렇지 않은 경우, {{< ui >}}Create keyword dictionary{{< /ui >}} 필드에 직접 키워드를 추가하세요. 또한 이러한 키워드가 일치 항목으로부터 지정된 문자 수 이내에 있도록 설정할 수 있습니다. 기본적으로 키워드는 일치한 값 앞의 30자 이내에 있어야 합니다. +1. {{< ui >}}Update{{< /ui >}}를 클릭합니다. + +[1]: https://app.datadoghq.com/observability-pipelines + +{{% /tab %}} +{{% tab "사용자 지정 규칙" %}} + +1. {{< ui >}}Define match conditions{{< /ui >}} 섹션에서 {{< ui >}}Define the regex{{< /ui >}} 필드의 이벤트와 일치시킬 정규식 패턴을 지정합니다. 자세한 내용은 [정규식을 사용한 효과적인 Grok 구문 분석 규칙 작성][1]을 참조하세요. + Sensitive Data Scanner는 Perl Compatible Regular Expressions(PCRE)를 지원하지만 다음 패턴은 지원하지 않습니다. + - 역참조 및 캡처 하위 표현식(lookaround) + - 임의의 제로폭 어설션(zero-width assertion) + - 서브루틴 참조 및 재귀 패턴 + - 조건부 패턴 + - 백트래킹 제어 동사 + - UTF-8 시퀀스를 손상시키는 `\C` "single-byte" 지시문 + - `\R` 줄바꿈 일치 + - `\K` 일치 시작 재설정 지시문 + - 콜아웃 및 임베디드 코드 + - 원자적 그룹화 및 소유형 수량자(possessive quantifiers) +1. {{< ui >}}Add sample data{{< /ui >}} 필드에 샘플 데이터를 입력하여 정규식 패턴이 유효한지 확인합니다. +1. {{< ui >}}Create keyword dictionary{{< /ui >}}에서 정규식 조건과 일치할 때 탐지 정확도를 높이기 위해 키워드를 추가합니다. 예를 들어 16자리 Visa 신용카드 번호를 스캔하는 경우 `visa`, `credit` 및 `card`와 같은 키워드를 추가할 수 있습니다. 또한 이러한 키워드가 일치 항목으로부터 지정된 문자 수 이내에 있도록 설정할 수 있습니다. 기본적으로 키워드는 일치한 값 앞의 30자 이내에 있어야 합니다. +1. {{< ui >}}Define rule target and conditions{{< /ui >}} 섹션의 드롭다운 메뉴에서 {{< ui >}}Entire Event{{< /ui >}}, {{< ui >}}Specific Attributes{{< /ui >}} 또는 {{< ui >}}Exclude Attributes{{< /ui >}} 중 무엇을 스캔할지 선택합니다. + - 전체 이벤트를 스캔하는 경우, 특정 속성을 스캔 대상에서 선택적으로 제외할 수 있습니다. 중첩된 키에 액세스하려면 [경로 표기법](#path-notation-example)(`outer_key.inner_key`)을 사용하세요. 중첩된 데이터가 있는 속성을 지정하면 해당 속성의 모든 중첩된 데이터가 제외됩니다. + - 특정 속성을 스캔하는 경우 스캔할 속성을 지정하세요. 중첩된 키에 액세스하려면 [경로 표기법](#path-notation-example-custom)(`outer_key.inner_key`)을 사용하세요. 중첩된 데이터가 있는 속성을 지정하면 해당 속성의 모든 중첩된 데이터가 스캔됩니다. +1. {{< ui >}}Define actions on match{{< /ui >}}에서 일치하는 정보에 대해 수행할 액션을 선택합니다. **참고**: 비식별화, 부분 비식별화 및 해싱은 모두 되돌릴 수 없는 작업입니다. + - {{< ui >}}Redact{{< /ui >}}: 일치하는 모든 값을 {{< ui >}}Replacement text{{< /ui >}} 필드에서 지정한 텍스트로 대체합니다. + - {{< ui >}}Partially Redact{{< /ui >}}: 일치하는 모든 데이터에서 지정된 부분을 대체합니다. {{< ui >}}Redact{{< /ui >}} 섹션에서 비식별화할 문자 수와 일치하는 데이터의 어느 부분을 비식별화할지 지정합니다. + - {{< ui >}}Hash{{< /ui >}}: 일치하는 모든 데이터를 고유 식별자로 대체합니다. 일치하는 UTF-8 바이트를 FarmHash의 64비트 지문으로 해싱합니다. +1. 필요시 {{< ui >}}Add Field{{< /ui >}}를 클릭하여 일치하는 이벤트와 연결할 태그를 추가합니다. +1. 스캔 규칙의 이름을 추가합니다. +1. 필요시 규칙 설명을 추가합니다. +1. {{< ui >}}Add Rule{{< /ui >}}을 클릭합니다. + +[1]: /ko/logs/guide/regex_log_parsing/ + +{{% /tab %}} +{{< /tabs >}} + +### 규칙 삭제 {#delete-a-rule} + +Sensitive Data Scanner에서 규칙을 삭제하려면 다음 단계를 따르세요. + +1. [Observability Pipelines][2]로 이동합니다. +1. 파이프라인을 선택합니다. +1. Sensitive Data Scanner 프로세서를 클릭하여 확장합니다. +1. {{< ui >}}Manage Scanning Rules{{< /ui >}}를 클릭합니다. +1. 삭제할 규칙을 선택합니다. +1. {{< ui >}}Delete{{< /ui >}}를 클릭합니다. + +### 경로 표기법 예시 {#path-notation-example} + +{{% observability_pipelines/path_notation %}} + +{{% observability_pipelines/path_notation_dots %}} + +## Terraform을 사용하여 프로세서를 설정 {#set-up-the-processor-using-terraform} + +[Datadog Observability Pipeline Terraform 리소스][4]를 사용하여 Sensitive Data Scanner 프로세서가 포함된 파이프라인을 설정할 수 있습니다. Terraform을 사용하여 Sensitive Data Scanner 프로세서에 규칙을 추가하려면 다음 단계를 따르세요. + +1. [Datadog Sensitive Data Scanner Standard Pattern][5] 데이터 소스를 사용하여 Sensitive Data Scanner [라이브러리 규칙][6]의 규칙 ID를 검색합니다. + + {{< code-block lang="terraform" >}} +data "datadog_sensitive_data_scanner_standard_pattern" "" { + filter = "" +} + {{< /code-block >}} + + 다음 자리 표시자를 바꿉니다. + + - ``: 나중에 Observability Pipeline 리소스에서 Sensitive Data Scanner 프로세서를 설정할 때 사용할 이름으로 바꾸세요. + - ``: 규칙의 정확한 이름으로 바꾸세요. 전체 규칙 목록은 [라이브러리 규칙][6]을 참조하세요. + + 예를 들어 [AWS Access Key ID Scanner][7]를 사용하려면 데이터 소스를 다음과 같이 구성하세요. + + {{< code-block lang="terraform" >}} +data "datadog_sensitive_data_scanner_standard_pattern" "aws_access_key" { + filter = "AWS Access Key ID Scanner" +} + {{< /code-block >}} + 여러 규칙의 데이터 소스를 추가하는 방법은 [전체 구성 예시](#full-configuration-example)를 참조하세요. + +1. 라이브러리 규칙에 대한 Observability Pipeline 리소스에 [rule][9] 블록을 추가합니다. + + {{< code-block lang="terraform" >}} +... + sensitive_data_scanner { + rule { + name = "" + tags = [] + on_match { + redact { + replace = "***" + } + } + pattern { + library { + id = data.datadog_sensitive_data_scanner_standard_pattern..id + use_recommended_keywords = true + } + } + scope { + all = true + } + } + } + {{< /code-block >}} + + 다음 자리 표시자를 바꿉니다. + + - ``: 규칙의 이름을 입력하세요. 이 이름은 Pipelines UI에 표시됩니다. + - ``: 1단계에서 데이터 소스에 사용한 규칙 식별자를 입력하세요. + + 예를 들어, 1단계에서 [AWS Access Key ID Scanner][7] 소스를 사용하는 경우 규칙 블록을 다음과 같이 구성하세요. + + {{< code-block lang="terraform" >}} +... + sensitive_data_scanner { + rule { + name = "Redact AWS Access Key IDs" + tags = [] + on_match { + redact { + replace = "***" + } + } + pattern { + library { + id = data.datadog_sensitive_data_scanner_standard_pattern.aws_access_key.id + use_recommended_keywords = true + } + } + scope { + all = true + } + } + } + {{< /code-block >}} + + 여러 규칙을 추가하는 방법은 [전체 설정 예시](#full-configuration-example)를 참조하세요. + +1. 추가하려는 모든 라이브러리 규칙에 대해 1단계와 2단계를 반복합니다. + +### 전체 구성 예시 {#full-configuration-example} + +{{< img src="observability_pipelines/processors/sds_tf_ui.png" alt="두 가지 스캔 규칙(AWS Access Key ID 비식별화 및 미국 SSN 비식별화)이 표시된 Sensitive Data Scanner 프로세서 패널" style="width:60%;" >}} + +Sensitive Data Scanner 프로세서를 사용하여 AWS Access Key ID 및 미국 사회보장번호를 스캔하고 `***` 문자열로 대체하여 비식별화하려면 다음 단계를 따르세요. + +1. [Datadog Sensitive Data Scanner Standard Pattern][5] 데이터 소스를 사용하여 [AWS Access Key ID Scanner][7] 및 [US Social Security Number Scanner][8]에 대한 규칙 ID를 검색합니다. +1. [Datadog Observability Pipeline][4] 리소스의 Sensitive Data Scanner 프로세서에서 데이터 소스에 정의된 Sensitive Data Scanner 규칙을 사용합니다. + +{{< code-block lang="terraform" >}} +data "datadog_sensitive_data_scanner_standard_pattern" "aws_access_key" { + filter = "AWS Access Key ID Scanner" +} +data "datadog_sensitive_data_scanner_standard_pattern" "us_ssn" { + filter = "US Social Security Number Scanner" +} + +resource "datadog_observability_pipeline" "sensitive_data_pipeline" { + name = "Sensitive Data Pipeline" + + config { + source { + id = "source-0" + datadog_agent {} + } + + processor_group { + display_name = "Processors" + enabled = true + id = "group-0" + include = "*" + inputs = ["source-0"] + + processor { + display_name = "Sensitive Data Scanner" + enabled = true + id = "processor-sds-0" + include = "*" + + sensitive_data_scanner { + rule { + name = "Redact AWS Access Key IDs" + tags = [] + on_match { + redact { + replace = "***" + } + } + pattern { + library { + id = data.datadog_sensitive_data_scanner_standard_pattern.aws_access_key.id + use_recommended_keywords = true + } + } + scope { + all = true + } + } + rule { + name = "Redact US SSNs" + tags = [] + on_match { + redact { + replace = "***" + } + } + pattern { + library { + id = data.datadog_sensitive_data_scanner_standard_pattern.us_ssn.id + use_recommended_keywords = true + } + } + scope { + all = true + } + } + } + } + } + + destination { + id = "destination-0" + inputs = ["group-0"] + datadog_logs {} + } + } +} +{{< /code-block >}} + +## 성능 최적화 모범 사례 {#best-practices-to-optimize-performance} + +Sensitive Data Scanner 프로세서는 CPU 사용량이 높습니다. 성능을 최적화하려면 다음 모범 사례를 따르세요. + +### Observability Pipelines Overview 대시보드에서 스캔 규칙 사용량 조회 {#view-scanning-rule-usage-with-the-observability-pipelines-overview-dashboard} + +Observability Pipelines에는 **Sensitive data found by Observability Pipelines** 섹션이 포함된 기본 제공 [Observability Pipelines Overview][16] 대시보드가 있습니다. 해당 섹션의 위젯을 사용하여 어떤 스캔 규칙이 데이터와 일치하는지 조회하세요. + +1. Dashboards > [Observability Pipelines Overview][16]로 이동합니다. +1. 대시보드 상단의 템플릿 변수(`pipeline_id`, `host`, `worker_uuid`, `component_type`, `component_kind`, `component_id`)를 사용하여 특정 파이프라인 또는 Worker로 조회 범위를 지정합니다. +1. 시간 선택기를 사용하여 더 넓은 시간 범위로 범위를 지정합니다. + +다음 위젯을 사용하여 Sensitive Data Scanner 프로세서의 스캔 규칙 사용량을 평가하세요. + +- **Logs containing sensitive data per scanning rule**: 선택한 시간 범위 동안의 일치 횟수와 함께 각 규칙을 이름별로 나열합니다(예: `visa_card_scanner_1x16_1x19_digits` 또는 `redact_ipv4`). 일치 횟수가 높은 규칙은 데이터를 활발하게 매칭하고 있습니다. 어떤 규칙이 사용 중인지 확인하는 기본 위젯입니다. +- **Total count of logs containing sensitive data**: 모든 규칙에서 일치한 민감 데이터의 총 볼륨을 표시합니다. +- **Logs containing sensitive data by Pipeline**: 민감 데이터가 포함된 일치 로그를 표시합니다. `pipeline_id`를 기준으로 범위를 좁혀 민감 데이터가 포함된 로그가 모든 파이프라인에서 발견되는지 아니면 특정 파이프라인에서만 발견되는지 확인할 수 있습니다. +- **Logs containing sensitive data per host**: 민감 데이터 일치 항목을 Worker 호스트별로 분류합니다. 이 위젯을 사용하여 배포 전반의 적용 범위를 확인하세요. +- **Patterns containing sensitive information** 및 **List of logs containing sensitive data**: 민감 데이터가 발견된 로그 패턴과 샘플 이벤트를 표시합니다. + +대표성 있는 시간 범위 동안 일치 항목이 없는 규칙을 식별한 후, 해당 규칙이 필요하지 않은지 확인하고 삭제하세요. [규칙 삭제](#delete-a-rule)를 참조하세요. + +**참고**: 일치 항목이 0인 규칙은 선택한 시간 범위 내에서 일치 항목이 없었다는 의미이며, 규칙이 유효하지 않다는 의미는 아닙니다. + +### 필요한 규칙만 활성화 {#only-enable-rules-you-need} + +활성화되어 있지만 사용되지 않는 규칙은 불필요한 리소스를 소비합니다. Sensitive Data Scanner 프로세서에서 지난 24시간 동안 각 규칙이 일치한 횟수를 조회하세요. + +1. [Observability Pipelines][2]로 이동합니다. +1. 파이프라인을 선택합니다. +1. Sensitive Data Scanner 프로세서를 클릭하여 확장합니다. +1. {{< ui >}}View Scanning Rules{{< /ui >}}를 클릭하여 사이드 패널을 열고 각 규칙의 {{< ui >}}Matches in the last 24 hours{{< /ui >}}를 확인합니다. + +사용하지 않는 규칙을 삭제하려면 [규칙 삭제](#delete-a-rule)를 참조하세요. + +### 민감 데이터 스캔이 필요한 이벤트와 필드만 스캔 {#only-scan-the-events-and-fields-that-need-to-be-scanned-for-sensitive-data} + +Sensitive Data Scanner가 이벤트를 스캔하는 데 걸리는 시간은 대체로 이벤트 크기에 비례합니다. 프로세서 성능을 최적화하려면 다음을 수행하세요. + +- 스캔하려는 이벤트 유형을 알고 있다면 해당 이벤트만 프로세서로 보내는 프로세서 쿼리를 정의하세요. + +- 스캔할 특정 이벤트 속성을 지정하거나 스캔에서 이벤트 속성을 제외하여 스캔 시간을 단축하세요. [프로세서 설정](#set-up-the-processor-in-the-ui)의 {{< ui >}}Define rule target and conditions{{< /ui >}} 단계를 참조하세요. + +### 성능 최적화 평가 및 벤치마킹 {#evaluate-and-benchmark-performance-optimizations} + +`pipelines.component_latency_seconds` 메트릭을 사용하여 다음을 수행할 수 있습니다. + +- 규칙을 추가할 때 프로세서 성능 벤치마킹 +- 스캔할 필드 수를 줄이거나 사용하지 않는 규칙을 제거하는 등 최적화 변경 후 성능 평가 + +`pipelines.component_latency_seconds` 메트릭을 조회하려면 다음 단계를 따르세요. + +1. [Metrics Explorer][11]로 이동합니다. +1. 메트릭 필드에 `pipelines.component_latency_seconds`를 입력합니다. +1. {{< ui >}}from{{< /ui >}} 필드에 `component_id:` 태그를 입력합니다. 여기서 ``는 Sensitive Data Scanner 프로세서의 ID입니다. + +**참고**: `pipelines.component_latency_seconds`는 분포 메트릭이므로 해당 메트릭의 백분위수를 활성화해야 합니다. 자세한 내용은 [고급 쿼리 기능 활성화][12]를 참조하세요. + +## 상태 메트릭 {#health-metrics} + +모든 프로세서에서 내보내는 [구성 요소 메트릭][13] 및 [프로세서 버퍼 메트릭][14]에 대한 자세한 내용은 [파이프라인 사용량 메트릭][15] 문서를 참조하세요. + +### Sensitive Data Scanner 메트릭 {#sensitive-data-scanner-metrics} + +- 개별 구성 요소별로 필터링하거나 그룹화하려면 `component_id` 태그를 사용하세요. +- Sensitive Data Scanner 프로세서 메트릭의 `component_type` 태그 값은 `sensitive_data_scanner`입니다. + +`pipelines.sds_rule_matched_total` +: **설명**: Sensitive Data Scanner 규칙과 일치하는 이벤트 수입니다. 일치하는 규칙 이름이 태그로 지정됩니다. +: **메트릭 유형**: 카운트 + +`pipelines.scanned_events` +: **설명**: Sensitive Data Scanner 엔진에서 스캔한 이벤트 수입니다. +: **메트릭 유형**: 카운트 + +`pipelines.scanning.match_count` +: **설명**: Sensitive Data Scanner에서 발견한 일치 항목 수입니다. +: **메트릭 유형**: 카운트 + +`pipelines.scanning.suppressed_match_count` +: **설명**: Sensitive Data Scanner에 의해 억제된 일치 항목의 수입니다. +: **메트릭 유형**: 카운트 + +`pipelines.scanning.duration` +: **설명**: 이벤트를 스캔하는 데 소요된 누적 벽시계 시간(초)입니다. 이 메트릭을 사용하여 프로세서 성능을 벤치마킹하고 최적화 효과를 평가하세요. +: **메트릭 유형**: 카운트 + +`pipelines.scanning.cpu_duration` +: **설명**: 이벤트를 스캔하는 데 소요된 누적 CPU 시간(초)입니다. +: **메트릭 유형**: 카운트 + +`pipelines.scanner.total_count` +: **설명**: 현재 실행 중인 Sensitive Data Scanner 프로세서의 수입니다. +: **메트릭 유형**: 게이지 + +`pipelines.scanner.total_regexes` +: **설명**: 모든 Sensitive Data Scanners에 포함된 정규식의 수입니다. +: **메트릭 유형**: 게이지 + +## 추가 자료 {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ko/observability_pipelines/search_syntax/logs/ +[2]: https://app.datadoghq.com/observability-pipelines +[3]: /ko/logs/guide/regex_log_parsing/ +[4]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/observability_pipeline +[5]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/data-sources/sensitive_data_scanner_standard_pattern +[6]: /ko/security/sensitive_data_scanner/scanning_rules/library_rules/ +[7]: /ko/security/sensitive_data_scanner/scanning_rules/library_rules/?search=AWS+Access+Key+ID+Scanner +[8]: /ko/security/sensitive_data_scanner/scanning_rules/library_rules/?search=US+Social+Security+Number+Scanner +[9]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/observability_pipeline#nested-schema-for-configprocessor_groupprocessorsensitive_data_scanner +[10]: /ko/api/latest/observability-pipelines/#create-a-new-pipeline +[11]: https://app.datadoghq.com/metric/explorer +[12]: /ko/metrics/distributions/#enabling-advanced-query-functionality +[13]: /ko/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#component-metrics +[14]: /ko/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#processor-buffer-metrics +[15]: /ko/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/ +[16]: https://app.datadoghq.com/dash/integration/32326/observability-pipelines-overview \ No newline at end of file diff --git a/hugo/content/ko/observability_pipelines/processors/tags.md b/hugo/content/ko/observability_pipelines/processors/tags.md new file mode 100644 index 00000000000..0619f57d808 --- /dev/null +++ b/hugo/content/ko/observability_pipelines/processors/tags.md @@ -0,0 +1,30 @@ +--- +aliases: +- /ko/observability_pipelines/processors/tag_control/logs/ +description: Datadog Agent에서 생성된 로그에 사용되는 Datadog 태그 배열에서 특정 태그를 제외하거나 포함하도록 태그 프로세서를 + 사용하는 방법을 알아보세요. +disable_toc: false +products: +- icon: logs + name: 로그 + url: /observability_pipelines/configuration/?tab=logs#pipeline-types +title: Tags Processor +--- +{{< product-availability >}} + +## 개요 {#overview} + +Datadog Agent에서 수신되는 로그의 경우, 이 프로세서를 사용하여 Datadog 태그(`ddtags`) 배열에서 특정 태그를 제외하거나 포함하세요. 제외되거나 포함되지 않은 태그는 삭제되며, 이로 인해 아웃바운드 로그의 볼륨이 줄어들 수 있습니다. + +## 설정 {#setup} + +프로세서를 설정하려면 다음 단계를 따르세요. + +1. {{< ui >}}filter query{{< /ui >}}를 정의합니다. 자세한 내용은 [로그 검색 구문][2]을 참조하세요. + - 필터와 일치하는 로그만 처리됩니다. + - 모든 로그는 필터 쿼리와 일치하는지 여부에 관계없이 파이프라인의 다음 단계로 전송됩니다. +1. 필요시 {{< ui >}}Configure tags{{< /ui >}} 섹션에 Datadog 태그 배열을 입력합니다. 지원되는 형식은 `["key:value", "key"]`입니다. `key:value`형식에 대한 자세한 내용은 [태그 정의][1]를 참조하세요. +1. {{< ui >}}Configure tags{{< /ui >}} 섹션에서 {{< ui >}}Exclude tags{{< /ui >}} 또는 {{< ui >}}Include tags{{< /ui >}}를 선택합니다. 이전 단계에서 태그 배열을 입력한 경우, 구성할 태그 키를 선택하세요. 태그 키를 수동으로 추가할 수도 있습니다. **참고**: 태그는 최대 100개까지 선택할 수 있습니다. + +[1]: /ko/getting_started/tagging/#define-tags +[2]: /ko/observability_pipelines/search_syntax/logs/ \ No newline at end of file diff --git a/hugo/content/ko/observability_pipelines/processors/throttle.md b/hugo/content/ko/observability_pipelines/processors/throttle.md new file mode 100644 index 00000000000..163aad57e18 --- /dev/null +++ b/hugo/content/ko/observability_pipelines/processors/throttle.md @@ -0,0 +1,80 @@ +--- +description: Throttle 프로세서를 사용하여 특정 기간 내에 전송되는 로그 수에 제한을 설정하는 방법을 알아보세요. +disable_toc: false +products: +- icon: logs + name: 로그 + url: /observability_pipelines/configuration/?tab=logs#pipeline-types +title: Throttle 프로세서 +--- +{{< jqmath-vanilla >}} + +{{< product-availability >}} + +## 개요 {#overview} + +이 프로세서를 사용하여 특정 기간 내에 전송되는 로그 수에 제한을 설정하세요. 예를 들어, 초당 100개의 로그만 전송되도록 제한을 설정할 수 있습니다. 속도 제한을 설정하면 로그 수집 급증을 포착하고 예상치 못한 청구 비용을 방지하는 데 도움이 될 수 있습니다. + +## 설정 {#setup} + +프로세서를 설정하려면 다음 단계를 따르세요. + +1. 필터 쿼리를 정의합니다. 지정된 필터 쿼리와 일치하는 로그만 처리됩니다. 일치하는 모든 로그는 스로틀링됩니다. 스로틀 제한 내에 전송된 로그와 필터와 일치하지 않는 로그는 다음 단계로 전송됩니다. 스로틀 제한에 도달한 후 전송된 로그는 삭제됩니다. 자세한 내용은 [검색 구문][4]을 참조하세요. +1. 스로틀링 속도를 설정합니다. 이는 설정된 기간 동안 특정 버킷에 허용되는 이벤트 수입니다. **참고**: 이 속도 제한은 **워커별 수준**으로 적용됩니다. 워커 수를 늘리거나 줄이는 경우, 그에 따라 프로세서 속도 제한을 조정해야 할 수 있습니다. [Observability Pipelines API][1]를 사용하여 프로그래밍 방식으로 속도 제한을 업데이트할 수 있습니다. +1. 기간을 설정합니다. +1. 필요시 필드별로 그룹화하려면 {{< ui >}}Add Field{{< /ui >}}를 클릭합니다. + +## Throttle 프로세서 작동 방식 {#how-the-throttle-processor-works} + +Throttle 프로세서는 지정된 기간 내에 전송되는 로그 수에 속도 제한을 설정합니다. [Quota 프로세서][2]와 유사하지만, Throttle 프로세서와 Quota 프로세서의 주요 차이점은 Quota 프로세서의 기간은 24시간으로 고정되어 변경할 수 없는 반면, Throttle 프로세서의 기간은 구성할 수 있다는 점입니다. Throttle 프로세서의 기간은 구성 가능하므로, 프로세서에는 설정한 스로틀링 속도와 기간을 기반으로 하는 용량 보충 속도가 있습니다. 자세한 내용은 [용량 보충 속도](#capacity-replenishment-rate)를 참조하세요. + +다음 표에서는 Throttle 프로세서와 Quota 프로세서를 비교합니다. + +| 기능 | Quota 프로세서 | Throttle 프로세서 | +|---------|----------------|-------------------| +| 기간 | 24시간으로 고정 | 구성 가능 | +| 초기 이벤트 버스트 처리 | 고정된 일일 제한까지 데이터를 처리합니다. | 구성한 스로틀링 속도까지 이벤트를 처리합니다. | +| 제한 도달 후 | 24시간 기간이 재설정될 때까지 데이터 처리를 중단합니다. | 계산된 일정한 속도로 계속 진행됩니다. | +| 재설정 메커니즘 | 24시간마다 재설정됩니다. | 지속적으로 보충합니다. Worker 또는 파이프라인을 다시 배포하면 기간도 재설정됩니다. | +| 제한이 저장되거나 추적되는 방식 | 할당량 제한은 백엔드에 저장되므로 Worker를 다시 시작해도 유지됩니다. | 스로틀 제한은 Worker의 메모리에서 추적되므로 Worker 또는 파이프라인을 다시 배포하면 기간이 재설정됩니다. | + +### 초기 용량 {#initial-capacity} + +{{< img src="observability_pipelines/processors/throttling_rate.png" alt="스로틀링 속도가 1000K로 설정된 Throttle 프로세서" style="width:40%;" >}} + +Throttle 프로세서가 활성화되면 프로세서가 즉시 통과시키는 로그 수는 구성된 {{< ui >}}Throttling Rate{{< /ui >}}를 기반으로 합니다. 예를 들어, {{< ui >}}Throttling Rate{{< /ui >}}가 60초 동안 `1000`개 이벤트로 설정되어 있고 프로세서가 활성화되는 순간 5,000개의 이벤트가 도착하는 경우: + +- 프로세서는 처음에 1,000개의 이벤트를 통과시킵니다. +- 나머지 4,000개의 이벤트는 삭제됩니다. +- 이 초기 동작은 Quota 프로세서의 동작과 동일합니다. + +### 용량 보충 속도 {#capacity-replenishment-rate} + +Throttle 프로세서는 [일반 셀 속도 알고리즘][3]을 사용하며, 이를 통해 일정한 속도로 이벤트를 통과시킬 수 있습니다. 보충 속도는 Throttle 프로세서의 설정을 기반으로 하며 초당 일정 수의 이벤트가 통과하도록 허용합니다. 이 속도는 다음과 같이 계산할 수 있습니다. + +$$\text"Throttle rate" / \text"Time window (in seconds)"$$ + +#### 예시 {#example} + +다음 프로세서 설정을 사용하는 경우: +- 스로틀링 속도 = 1000개 이벤트 +- 기간 = 60분(3,600초) + +용량 보충 속도는 다음과 같습니다. + +$$\text"1000 events" / \text"60 minutes" ≈ \text"17 events"/ \text"minute" ≈ \text"0.28 events"/ \text"second"$$ + +`T`이 프로세서가 활성화된 시간이고 해당 시점에 프로세서가 5000개의 이벤트를 수신하는 경우, `T`에 따라 프로세서가 통과시키는 이벤트 수는 다음과 같습니다. +- `T + 0`분(프로세서가 활성화된 시점): + - 1000개의 이벤트가 처리되었습니다. + - 4000개의 이벤트가 삭제되었습니다. +- `T + 1` 분: 최대 17개의 이벤트 처리 가능 +- `T + 2`분: 최대 17개의 이벤트 처리 가능 +- ...프로세서는 분당 최대 17개의 이벤트를 꾸준히 처리하고, 다음 분이 될 때까지 나머지를 삭제합니다. + +**참고**: 보충 속도는 초기 용량 이후의 최대 처리량을 결정합니다. 필요한 경우 더 높거나 낮은 처리량을 위해 스로틀링 속도를 조정할 수 있습니다. + +[1]: /ko/api/latest/observability-pipelines/#update-a-pipeline +[2]: /ko/observability_pipelines/processors/quota/ +[3]: https://en.wikipedia.org/wiki/Generic_cell_rate_algorithm +[4]: /ko/observability_pipelines/search_syntax/logs/ \ No newline at end of file diff --git a/hugo/content/ko/observability_pipelines/sources/http_server.md b/hugo/content/ko/observability_pipelines/sources/http_server.md new file mode 100644 index 00000000000..4dc5007df81 --- /dev/null +++ b/hugo/content/ko/observability_pipelines/sources/http_server.md @@ -0,0 +1,103 @@ +--- +description: Observability Pipelines Worker의 HTTP/S Server 소스를 사용하여 HTTP 클라이언트 로그를 + 수집하는 방법을 알아보세요. +disable_toc: false +products: +- icon: logs + name: 로그 + url: /observability_pipelines/configuration/?tab=logs#pipeline-types +title: HTTP/S Server 소스 +--- +{{< product-availability >}} + +## 개요 {#overview} + +Observability Pipelines의 HTTP/S Server 소스를 사용하여 HTTP 클라이언트 로그를 수집하세요. + +또한 [Datadog Lambda Forwarder를 사용하여 AWS vended 로그를 Observability Pipelines로 전송](#send-aws-vended-logs-with-the-datadog-lambda-forwarder-to-observability-pipelines)할 수 있습니다. + +## 전제 조건 {#prerequisites} + +{{% observability_pipelines/prerequisites/http_server %}} + +## 설정 {#setup} + +
시크릿 관리의 경우, HTTP/S Server 주소의 식별자만 입력하고, 해당하는 경우 일반(기본) 인증을 위한 사용자 이름 및 비밀번호의 식별자와 TLS 키 암호의 식별자만 입력하세요. 실제 값은 입력하지 마세요.
+ +[파이프라인을 설정할][3] 때 이 소스를 설정하세요. 파이프라인은 [UI][1], [API][4] 또는 [Terraform][5]을 사용하여 설정할 수 있습니다. 이 섹션의 지침은 UI에서 소스를 설정하는 방법을 설명합니다. + +파이프라인 UI에서 HTTP/S Server 소스를 선택한 후 다음 단계를 따르세요. + +1. HTTP/S Server 주소의 식별자를 입력합니다. 비워두면 [기본값](#secret-defaults)이 사용됩니다. + - **참고**: 주소의 식별자만 입력하세요. 실제 주소는 **입력하지 마세요**. +1. 인증 방식을 선택합니다. {{< ui >}}Plain{{< /ui >}}을 선택한 경우: + - HTTP/S Server 사용자 이름과 비밀번호의 식별자를 입력하세요. 비워두면 [기본값](#secret-defaults)이 사용됩니다. +1. (필요시) 인증 토큰을 설정합니다. 자세한 내용은 [인증 토큰 구성](#configure-authentication-tokens)을 참조하세요. +1. HTTP 메시지에 사용할 디코더를 선택합니다. HTTP 클라이언트 로그는 선택한 형식이어야 합니다. **참고**: `bytes` 디코딩을 선택하면 원시 로그가 `message` 필드에 저장됩니다. + +{{% observability_pipelines/secrets_env_var_note %}} + +### 선택적 설정 {#optional-settings} + +#### TLS 활성화 {#enable-tls} + +{{% observability_pipelines/tls_settings %}} + +{{% observability_pipelines/tls_settings_mtls %}} + +#### 인증 토큰 구성 {#configure-authentication-tokens} + +HTTP 요청의 인증 헤더에 토큰을 자격 증명으로 저장하는 경우, Worker가 들어오는 HTTP 요청에 유효한 토큰이 있는지 검사하도록 구성할 수 있습니다. 유효한 토큰이 없는 요청 이벤트는 삭제됩니다. Worker는 헤더 대신 엔드포인트 경로 또는 IP 주소를 조회할 수도 있습니다. + +**참고**: {{< ui >}}Plain{{< /ui >}} 인증 방식에서는 인증 토큰을 구성할 수 없습니다. + +{{% observability_pipelines/configure_authentication_tokens %}} + +## 시크릿 기본값 {#secret-defaults} + +{{% observability_pipelines/set_secrets_intro %}} + +{{< tabs >}} +{{% tab "시크릿 관리" %}} + +- HTTP/S Server 주소 식별자: + - Observability Pipelines Worker가 HTTP 클라이언트 로그를 수신하는 소켓 주소(예: `0.0.0.0:9997`)를 참조합니다. + - 기본 식별자는 `SOURCE_HTTP_SERVER_ADDRESS`입니다. +- HTTP/S Server TLS 암호 식별자(TLS가 활성화된 경우): + - 기본 식별자는 `SOURCE_HTTP_SERVER_KEY_PASS`입니다. +- 일반 인증을 사용하는 경우: + - HTTP/S Server 사용자 이름 식별자: + - 기본 식별자는 `SOURCE_HTTP_SERVER_USERNAME`입니다. + - HTTP/S Server 암호 식별자: + - 기본 식별자는 `SOURCE_HTTP_SERVER_PASSWORD`입니다. + +{{% /tab %}} + +{{% tab "환경 변수" %}} + +{{% observability_pipelines/configure_existing_pipelines/source_env_vars/http_server %}} + +{{% /tab %}} +{{< /tabs >}} + +## Datadog Lambda Forwarder를 사용하여 AWS vended 로그를 Observability Pipelines로 전송{#send-aws-vended-logs-with-the-datadog-lambda-forwarder-to-observability-pipelines} + +HTTP/S Server 소스를 사용하여 AWS vended 로그를 Observability Pipelines로 전송하려면 다음 단계를 따르세요. + +- [HTTP/S Server 소스로 파이프라인을 설정하세요](#set-up-a-pipeline). +- [Datadog Forwarder를 배포하세요](#deploy-the-datadog-lambda-forwarder). + +**참고**: 이 기능은 Worker 버전 2.51 이상에서 사용할 수 있습니다. + +### 파이프라인 설정 {#set-up-a-pipeline} + +{{% observability_pipelines/lambda_forwarder/pipeline_setup %}} + +### Datadog Lambda Forwarder 배포 {#deploy-the-datadog-lambda-forwarder} + +{{% observability_pipelines/lambda_forwarder/deploy_forwarder %}} + +[1]: https://app.datadoghq.com/observability-pipelines +[3]: /ko/observability_pipelines/configuration/set_up_pipelines/ +[4]: /ko/api/latest/observability-pipelines/ +[5]: https://registry.terraform.io/providers/datadog/datadog/latest/docs/resources/observability_pipeline \ No newline at end of file diff --git a/hugo/content/ko/opentelemetry/setup/ddot_collector/install/kubernetes_standalone.md b/hugo/content/ko/opentelemetry/setup/ddot_collector/install/kubernetes_standalone.md new file mode 100644 index 00000000000..1c0afc6213c --- /dev/null +++ b/hugo/content/ko/opentelemetry/setup/ddot_collector/install/kubernetes_standalone.md @@ -0,0 +1,916 @@ +--- +description: OpenTelemetry Operator 또는 Helm 차트를 사용하여 Kubernetes에 독립형 Datadog Distribution + of OpenTelemetry(DDOT) Collector를 배포하세요. +further_reading: +- link: /opentelemetry/setup/ddot_collector/custom_components + tag: 설명서 + text: DDOT에서 사용자 지정 OpenTelemetry 구성 요소 사용 +title: Kubernetes DaemonSet로 독립형 DDOT Collector 설치 +--- +{{< callout header="false" btn_hidden="true" >}} +OpenTelemetry 도구를 사용하여 독립형 DDOT Collector를 설치하는 기능은 미리 보기로 제공되고 있습니다. +{{< /callout >}} + +## 개요 {#overview} + +이 가이드에 따라 OpenTelemetry Operator 또는 Helm 차트를 사용하여 Datadog Distribution of OpenTelemetry(DDOT) Collector를 배포하세요. + +
+ 추가 OpenTelemetry 구성 요소가 필요하신가요? 기본 패키지에 포함된 구성 요소 외에 추가 구성 요소가 필요한 경우 사용자 지정 OpenTelemetry 구성 요소 사용을 참조하여 DDOT의 기능을 확장하세요. 기본적으로 포함되는 구성 요소 목록은 OpenTelemetry Collector 구성 요소를 참조하세요. +
+ +## 요구 사항 {#requirements} + +이 가이드를 완료하려면 다음이 필요합니다. + +**Datadog 계정**: +1. Datadog 계정이 없는 경우 [Datadog 계정 생성][1] 단계를 진행합니다. +1. [Datadog API 키][2]를 찾거나 생성합니다. + +**소프트웨어**: +다음을 머신에 설치하고 구성합니다. + +- Kubernetes 클러스터(v1.29 이상) +- [Helm(v4 이상)][54] +- [kubectl][5] + +**네트워크**: +| 프로토콜 | 전송 | 포트 | +|:---------|:----------|-----:| +| gRPC | TCP | 4317 | +| HTTP | TCP | 4318 | + +## Datadog Distribution of OpenTelemetry Collector 설치 {#install-the-datadog-distribution-of-the-opentelemetry-collector} + +### 설치 방법 선택 {#select-installation-method} + +다음 설치 방법 중 하나를 선택합니다. + +- [OpenTelemetry Operator][55]: OTel Collector 설정을 자동으로 조정하고 유지 관리하는 [Kubernetes 네이티브][56] 접근 방식입니다. +- [Helm 차트][4]: OTel Collector를 배포하는 간단한 방법입니다. + +{{< tabs >}} +{{% tab "Operator" %}} +### OpenTelemetry Operator 설치 {#install-the-opentelemetry-operator} + +[OpenTelemetry Operator Helm 차트][1]를 사용하여 클러스터에 OpenTelemetry Operator를 설치할 수 있습니다. + +```shell +helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts +helm repo update +helm install opentelemetry-operator open-telemetry/opentelemetry-operator \ + --set "manager.createRbacPermissions=true" \ + --set "manager.collectorImage.repository=datadog/ddot-collector" \ + --set "manager.collectorImage.tag={{< version key="agent_version" >}}" +``` + +{{% site-region region="gov,gov2" %}} +
+FED의 경우 태그를 설정( {{< version key="agent_version" >}}-fips )하여 FIPS 규정 준수 DDOT 이미지를 사용합니다. +FIPS 규정 준수를 참조하세요. +
+{{% /site-region %}} + +[1]: https://github.com/open-telemetry/opentelemetry-helm-charts/blob/main/charts/opentelemetry-operator/README.md +{{% /tab %}} +{{% tab "Helm" %}} +### OpenTelemetry Helm 리포지토리 추가 {#add-the-opentelemetry-helm-repository} + +Helm 리포지토리에 OpenTelemetry 리포지토리를 추가하려면 다음을 실행하세요. + +```shell +helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts +helm repo update +``` + +{{% /tab %}} +{{< /tabs >}} + +### Datadog API 키 설정 {#set-up-datadog-api-key} + +1. Datadog [API 키][2]를 가져옵니다. +1. 오른쪽에서 선택한 **DATADOG SITE**(현재 값: **{{< region-param key="dd_site_name" >}}**)가 [Datadog 사이트][52]와 일치하는지 확인합니다. +1. API 키를 Kubernetes 시크릿으로 저장합니다. + ```shell + kubectl create secret generic datadog-secret \ + --from-literal api-key= \ + --from-literal site={{< region-param key="dd_site" >}} + ``` + Replace `` with your actual Datadog API key. + +### Configure the OTel Collector + +{{< tabs >}} +{{% tab "Operator" %}} +OTel Operator를 배포한 후 Collector 배포를 트리거하는 `OpenTelemetryCollector` 리소스를 생성하세요. + +1. `node-collector.yaml` 파일을 사용하여 `OpenTelemetryCollector` DaemonSet 구성을 지정합니다. + +{{< code-block lang="yaml" filename="node-collector.yaml" collapsible="true" >}} +apiVersion: opentelemetry.io/v1beta1 +kind: OpenTelemetryCollector +metadata: + name: node-collector +spec: + # Deploy 1 instance per node, that will collect telemetry from that node's pods + mode: daemonset + command: ['otel-agent', 'run'] # Will no longer be necessary from 7.82.0 onwards + config: + exporters: + datadog: + api: + key: ${env:DD_API_KEY} + site: ${env:DD_SITE} + sending_queue: + batch: + flush_timeout: 10s + service: + telemetry: + resource: + k8s.cluster.name: ${env:K8S_CLUSTER_NAME} + env: + - name: DD_API_KEY + valueFrom: + secretKeyRef: + key: api-key + name: datadog-apikey + - name: DD_SITE + valueFrom: + secretKeyRef: + key: site + name: datadog-apikey + - name: DD_OTELCOLLECTOR_CONVERTER_FEATURES + value: datadog,pprof,zpages,prometheus,infraattributes + - name: K8S_CLUSTER_NAME + value: + # vvv Will no longer be necessary from 7.83.0 onwards vvv + - name: DD_OTEL_STANDALONE + value: 'true' + # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + # vvv Will no longer be necessary from 7.82.0 onwards vvv + - name: DD_OTELCOLLECTOR_ENABLED + value: 'true' + # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +{{< /code-block >}} + +``을 클러스터 이름으로 바꿉니다. + +2. 원하는 모든 신호에 대해 OTLP 수신기와 Datadog 익스포터를 추가합니다. 애플리케이션 포드가 동일한 노드에서 실행 중인 Collector 인스턴스에 도달할 수 있도록 `hostPort`를 통해 노드에서 OTLP 포트를 게시합니다. + +{{< code-block lang="yaml" filename="node-collector.yaml" collapsible="true" >}} +# [...] +spec: + # [...] + # Publish the OTLP ports on the node's network interface + ports: + - name: otlp-grpc + port: 4317 + protocol: TCP + hostPort: 4317 + - name: otlp-http + port: 4318 + protocol: TCP + hostPort: 4318 + config: + receivers: + otlp: + protocols: + grpc: + endpoint: 0.0.0.0:4317 + http: + endpoint: 0.0.0.0:4318 + # [...] + service: + # [...] + pipelines: + logs: + receivers: ['otlp'] + exporters: ['datadog'] + metrics: + receivers: ['otlp'] + exporters: ['datadog'] + traces: + receivers: ['otlp'] + exporters: ['datadog'] +{{< /code-block >}} + +3. (선택 사항) 추가 기능을 활성화합니다. + +
이 기능을 활성화하면 추가 비용이 발생할 수 있습니다. 진행하기 전에 가격 페이지를 검토하고 고객 성공 관리자와 상담하세요.
+ +{{< code-block lang="yaml" filename="node-collector.yaml" collapsible="true" >}} +spec: + config: + receivers: + host_metrics: + collection_interval: 15s + scrapers: + cpu: {} + load: {} + memory: {} + network: {} + disk: {} + kubelet_stats: + auth_type: serviceAccount + collection_interval: 15s + endpoint: ${env:K8S_NODE_NAME}:10250 + node: ${env:K8S_NODE_NAME} + metric_groups: + - pod + - container + - volume + processors: + infraattributes: + cardinality: 2 + resource/add-cluster-name: + attributes: + - key: k8s.cluster.name + value: ${env:K8S_CLUSTER_NAME} + action: upsert + connectors: + datadog/connector: + traces: + compute_top_level_by_span_kind: true + peer_tags_aggregation: true + compute_stats_by_span_kind: true + extensions: + health_check: + endpoint: "${env:K8S_POD_IP}:13133" + # [...] + service: + # [...] + extensions: ['health_check'] + pipelines: + logs: + # [...] + processors: ['resource/add-cluster-name', 'infraattributes'] + metrics: + receivers: ['host_metrics', 'otlp', 'kubelet_stats', 'datadog/connector'] + processors: ['resource/add-cluster-name', 'infraattributes'] + # [...] + traces: + # [...] + processors: ['resource/add-cluster-name', 'infraattributes'] + exporters: ['datadog', 'datadog/connector'] + env: + # [...] + - name: K8S_POD_IP + valueFrom: + fieldRef: + apiVersion: v1 + fieldPath: status.podIP + # K8S_NODE_NAME is added automatically by the operator +{{< /code-block >}} + +4. (선택 사항) 노드의 파일 시스템에서 컨테이너 로그를 수집합니다. + +
로그 수집을 활성화하면 추가 비용이 발생할 수 있습니다. 진행하기 전에 가격 페이지를 검토하고 고객 성공 관리자와 상담하세요.
+ +`filelog` 수신기는 노드에서 컨테이너 로그를 읽습니다. Operator가 호스트 경로를 자동으로 마운팅하지 않으므로 로그 디렉터리를 읽기 전용 볼륨으로 추가합니다. + +{{< code-block lang="yaml" filename="node-collector.yaml" collapsible="true" >}} +spec: + config: + receivers: + filelog: + include: + - /var/log/pods/*/*/*.log + # Exclude the Collector's own logs to avoid a feedback loop + exclude: + - /var/log/pods/*_node-collector-collector-*_*/otc-container/*.log + start_at: end + include_file_path: true + include_file_name: false + retry_on_failure: + enabled: true + operators: + - id: container-parser + type: container + max_log_size: 102400 + # [...] + service: + # [...] + pipelines: + logs: + receivers: ['otlp', 'filelog'] + # [...] + # Mount the node's log directories into the Collector pod (read-only) + volumes: + - name: varlogpods + hostPath: + path: /var/log/pods + - name: varlibdockercontainers + hostPath: + path: /var/lib/docker/containers + volumeMounts: + - name: varlogpods + mountPath: /var/log/pods + readOnly: true + - name: varlibdockercontainers + mountPath: /var/lib/docker/containers + readOnly: true +{{< /code-block >}} + +{{% collapse-content title="완성된 node-collector.yaml 파일" level="p" %}} +`node-collector.yaml` 파일은 다음과 유사해야 합니다. +{{< code-block lang="yaml" filename="node-collector.yaml" collapsible="false" >}} +apiVersion: opentelemetry.io/v1beta1 +kind: OpenTelemetryCollector +metadata: + name: node-collector +spec: + # Deploy 1 instance per node, that will collect telemetry from that node's pods + mode: daemonset + command: ['otel-agent', 'run'] # Will no longer be necessary from 7.82.0 onwards + # Publish the OTLP ports on the node's network interface + ports: + - name: otlp-grpc + port: 4317 + protocol: TCP + hostPort: 4317 + - name: otlp-http + port: 4318 + protocol: TCP + hostPort: 4318 + config: + receivers: + otlp: + protocols: + grpc: + endpoint: 0.0.0.0:4317 + http: + endpoint: 0.0.0.0:4318 + host_metrics: + collection_interval: 15s + scrapers: + cpu: {} + load: {} + memory: {} + network: {} + disk: {} + kubelet_stats: + auth_type: serviceAccount + collection_interval: 15s + endpoint: ${env:K8S_NODE_NAME}:10250 + node: ${env:K8S_NODE_NAME} + metric_groups: + - pod + - container + - volume + filelog: + include: + - /var/log/pods/*/*/*.log + exclude: + - /var/log/pods/*_node-collector-collector-*_*/otc-container/*.log + start_at: end + include_file_path: true + include_file_name: false + retry_on_failure: + enabled: true + operators: + - id: container-parser + type: container + max_log_size: 102400 + processors: + infraattributes: + cardinality: 2 + resource/add-cluster-name: + attributes: + - key: k8s.cluster.name + value: ${env:K8S_CLUSTER_NAME} + action: upsert + connectors: + datadog/connector: + traces: + compute_top_level_by_span_kind: true + peer_tags_aggregation: true + compute_stats_by_span_kind: true + exporters: + datadog: + api: + key: ${env:DD_API_KEY} + site: ${env:DD_SITE} + sending_queue: + batch: + flush_timeout: 10s + extensions: + health_check: + endpoint: "${env:K8S_POD_IP}:13133" + service: + telemetry: + resource: + k8s.cluster.name: ${env:K8S_CLUSTER_NAME} + extensions: ['health_check'] + pipelines: + logs: + receivers: ['otlp', 'filelog'] + processors: ['resource/add-cluster-name', 'infraattributes'] + exporters: ['datadog'] + metrics: + receivers: ['host_metrics', 'otlp', 'kubelet_stats', 'datadog/connector'] + processors: ['resource/add-cluster-name', 'infraattributes'] + exporters: ['datadog'] + traces: + receivers: ['otlp'] + processors: ['resource/add-cluster-name', 'infraattributes'] + exporters: ['datadog', 'datadog/connector'] + env: + - name: DD_API_KEY + valueFrom: + secretKeyRef: + key: api-key + name: datadog-apikey + - name: DD_SITE + valueFrom: + secretKeyRef: + key: site + name: datadog-apikey + - name: DD_OTELCOLLECTOR_CONVERTER_FEATURES + value: datadog,pprof,zpages,prometheus,infraattributes + - name: K8S_CLUSTER_NAME + value: + - name: K8S_POD_IP + valueFrom: + fieldRef: + apiVersion: v1 + fieldPath: status.podIP + # K8S_NODE_NAME is added automatically by the operator + # vvv Will no longer be necessary from 7.83.0 onwards vvv + - name: DD_OTEL_STANDALONE + value: 'true' + # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + # vvv Will no longer be necessary from 7.82.0 onwards vvv + - name: DD_OTELCOLLECTOR_ENABLED + value: 'true' + # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + # Mount the node's log directories for the filelog receiver (read-only) + volumes: + - name: varlogpods + hostPath: + path: /var/log/pods + - name: varlibdockercontainers + hostPath: + path: /var/lib/docker/containers + volumeMounts: + - name: varlogpods + mountPath: /var/log/pods + readOnly: true + - name: varlibdockercontainers + mountPath: /var/lib/docker/containers + readOnly: true +{{< /code-block >}} + +``을 클러스터 이름으로 바꿉니다. + +{{% /collapse-content %}} + +{{% /tab %}} +{{% tab "Helm" %}} +YAML 파일을 사용하여 [Collector 차트][1]의 Helm 차트 파라미터를 지정하세요. + +1. 비어 있는 `node-collector-values.yaml` 파일을 생성합니다. + +```shell +touch node-collector-values.yaml +``` + +
지정되지 않은 파라미터에는 values.yaml의 기본값이 사용됩니다.
+ +2. DaemonSet 모드를 선택하고 DDOT를 컬렉터로 사용합니다. + +{{< code-block lang="yaml" filename="node-collector-values.yaml" collapsible="true" >}} +mode: daemonset +image: + repository: datadog/ddot-collector + tag: {{< version key="agent_version" >}} +ports: + jaeger-compact: + enabled: false + jaeger-grpc: + enabled: false + jaeger-thrift: + enabled: false + zipkin: + enabled: false +# Can be removed from 7.82.0 onwards +command: + name: opt/datadog-agent/embedded/bin/otel-agent +{{< /code-block >}} + +{{% site-region region="gov,gov2" %}} +
FED의 경우 tag: {{< version key="agent_version" >}}-fips 설정을 통해 FIPS 규정 준수 DDOT 이미지를 사용합니다. FIPS 규정 준수를 참조하세요.
+{{% /site-region %}} + +
Collector Helm 차트는 기본적으로 각 노드에서 OTLP 포트를 게시하므로(hostPort: 4317 - gRPC, hostPort: 4318 - HTTP) 애플리케이션 포드가 동일한 노드에서 실행 중인 Collector 인스턴스에 도달할 수 있습니다. 애플리케이션 구성을 참조하세요.
+ +3. Datadog 익스포터 및 API 키 시크릿을 구성합니다. + +{{< code-block lang="yaml" filename="node-collector-values.yaml" collapsible="true" >}} +config: + exporters: + datadog: + api: + key: ${env:DD_API_KEY} + site: ${env:DD_SITE} + sending_queue: + batch: + flush_timeout: 10s +extraEnvs: + - name: DD_API_KEY + valueFrom: + secretKeyRef: + key: api-key + name: datadog-apikey + - name: DD_SITE + valueFrom: + secretKeyRef: + key: site + name: datadog-apikey + - name: DD_OTELCOLLECTOR_CONVERTER_FEATURES + value: datadog,pprof,zpages,prometheus,infraattributes + - name: K8S_CLUSTER_NAME + value: + # vvv Will no longer be necessary from 7.83.0 onwards vvv + - name: DD_OTEL_STANDALONE + value: 'true' + # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + # vvv Will no longer be necessary from 7.82.0 onwards vvv + - name: DD_OTELCOLLECTOR_ENABLED + value: 'true' + # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +{{< /code-block >}} + +``을 클러스터 이름으로 바꿉니다. + +4. 사전 설정을 활성화합니다. + +{{< code-block lang="yaml" filename="node-collector-values.yaml" collapsible="true" >}} +presets: + hostMetrics: + enabled: true + kubeletMetrics: + enabled: true + logsCollection: + enabled: true + includeCollectorLogs: false +{{< /code-block >}} + +5. OTLP 수신기를 사용하여 원하는 신호에 대한 파이프라인을 정의합니다. + +{{< code-block lang="yaml" filename="node-collector-values.yaml" collapsible="true" >}} +config: + # [...] + receivers: + otlp: + protocols: + grpc: + endpoint: 0.0.0.0:4317 + http: + endpoint: 0.0.0.0:4318 + service: + pipelines: + logs: + receivers: ['otlp'] + exporters: ['datadog'] + metrics: + receivers: ['otlp'] + exporters: ['datadog'] + traces: + receivers: ['otlp'] + exporters: ['datadog'] + telemetry: + resource: + k8s.cluster.name: ${env:K8S_CLUSTER_NAME} +{{< /code-block >}} + +6. (선택 사항) 추가 Datadog 기능을 활성화합니다. + +
이 기능을 활성화하면 추가 비용이 발생할 수 있습니다. 진행하기 전에 가격 페이지를 검토하고 고객 성공 관리자와 상담하세요.
+ +{{< code-block lang="yaml" filename="node-collector-values.yaml" collapsible="true" >}} +config: + # [...] + processors: + infraattributes: + cardinality: 2 + resource/add-cluster-name: + attributes: + - key: k8s.cluster.name + value: ${env:K8S_CLUSTER_NAME} + action: upsert + connectors: + datadog/connector: + traces: + compute_top_level_by_span_kind: true + peer_tags_aggregation: true + compute_stats_by_span_kind: true + service: + pipelines: + logs: + # [...] + processors: ['resource/add-cluster-name', 'infraattributes'] + metrics: + receivers: ['otlp', 'datadog/connector'] + processors: ['resource/add-cluster-name', 'infraattributes'] + # [...] + traces: + # [...] + processors: ['resource/add-cluster-name', 'infraattributes'] + exporters: ['datadog', 'datadog/connector'] +{{< /code-block >}} + +{{% collapse-content title="완성된 node-collector-values.yaml 파일" level="p" %}} +`node-collector-values.yaml` 파일은 다음과 유사해야 합니다. +{{< code-block lang="yaml" filename="node-collector-values.yaml" collapsible="false" >}} +mode: daemonset +# vvv To be removed from 7.82.0 onwards vvv +command: + name: opt/datadog-agent/embedded/bin/otel-agent +# ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +image: + repository: datadog/ddot-collector + tag: {{< version key="agent_version" >}} +presets: + hostMetrics: # Add an hostmetrics receiver to the metrics pipeline + enabled: true + kubeletMetrics: # Add a kubeletstats receiver to the metrics pipeline + enabled: true + logsCollection: # Add a filelog receiver to the logs pipeline + enabled: true + includeCollectorLogs: false +config: + connectors: + datadog/connector: + traces: + compute_top_level_by_span_kind: true + peer_tags_aggregation: true + compute_stats_by_span_kind: true + exporters: + datadog: + api: + key: ${env:DD_API_KEY} + site: ${env:DD_SITE} + sending_queue: + batch: + flush_timeout: 10s + processors: + infraattributes: + cardinality: 2 + resource/add-cluster-name: + attributes: + - key: k8s.cluster.name + value: ${env:K8S_CLUSTER_NAME} + action: upsert + receivers: + otlp: + protocols: + grpc: + endpoint: 0.0.0.0:4317 + http: + endpoint: 0.0.0.0:4318 + service: + extensions: + - health_check + pipelines: + logs: + receivers: + - otlp + processors: + - resource/add-cluster-name + - infraattributes + exporters: + - datadog + metrics: + receivers: + - otlp + - datadog/connector + processors: + - resource/add-cluster-name + - infraattributes + exporters: + - datadog + traces: + receivers: + - otlp + processors: + - resource/add-cluster-name + - infraattributes + exporters: + - datadog + - datadog/connector + telemetry: + resource: + k8s.cluster.name: ${env:K8S_CLUSTER_NAME} +extraEnvs: + - name: DD_API_KEY + valueFrom: + secretKeyRef: + key: api-key + name: datadog-apikey + - name: DD_SITE + valueFrom: + secretKeyRef: + key: site + name: datadog-apikey + - name: DD_OTELCOLLECTOR_CONVERTER_FEATURES + value: datadog,pprof,zpages,prometheus,infraattributes + - name: K8S_CLUSTER_NAME + value: + # vvv Will no longer be necessary from 7.83.0 onwards vvv + - name: DD_OTEL_STANDALONE + value: 'true' + # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + # vvv Will no longer be necessary from 7.82.0 onwards vvv + - name: DD_OTELCOLLECTOR_ENABLED + value: 'true' + # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +ports: + jaeger-compact: + enabled: false + jaeger-grpc: + enabled: false + jaeger-thrift: + enabled: false + zipkin: + enabled: false +{{< /code-block >}} + +{{% /collapse-content %}} + +[1]: https://github.com/open-telemetry/opentelemetry-helm-charts/blob/main/charts/opentelemetry-collector/README.md +[2]: /ko/getting_started/site/ +[3]: /ko/containers/guide/changing_container_registry/ +{{% /tab %}} +{{< /tabs >}} + +### Collector 배포 {#deploy-the-collector} + +{{< tabs >}} +{{% tab "Operator" %}} +`node-collector.yaml` 파일을 적용하여 `OpenTelemetryCollector` 리소스를 생성하세요. Operator는 Collector를 DaemonSet로 배포하여 노드당 하나의 인스턴스를 실행합니다. + +```shell +kubectl apply -f node-collector.yaml +``` +{{% /tab %}} +{{% tab "Helm" %}} +값 파일을 사용하여 OpenTelemetry Collector 차트를 설치하세요. + +```shell +helm install node-collector open-telemetry/opentelemetry-collector -f node-collector-values.yaml +``` + +이후 변경 사항을 적용하려면 `helm upgrade node-collector open-telemetry/opentelemetry-collector -f node-collector-values.yaml`을 실행하세요. +{{% /tab %}} +{{< /tabs >}} + +## DDOT와 함께 코어 Datadog Agent 설치 {#install-the-core-datadog-agent-alongside-ddot} + +독립형 DDOT Collector와 동일한 노드에서 코어 Datadog Agent를 실행하려는 경우(예: DDOT가 OTLP 수집을 처리하는 동안 코어 Agent를 통해 인프라 메트릭, APM 또는 로그를 수집하려는 경우) [Datadog Operator][57]를 사용하여 별도로 설치할 수 있습니다. + +기본적으로 Datadog Operator Helm 차트는 DatadogAgent 리소스를 Operator가 설치된 네임스페이스에서만 감시합니다(watchNamespaces: []). 만약 DatadogAgent 리소스가 Operator와 다른 네임스페이스에 있는 경우(예: OpenTelemetryCollector 리소스의 네임스페이스와 분리하려는 경우), watchNamespaces 를 DatadogAgent 리소스가 생성된 네임스페이스를 포함하도록 설정하세요. +
helm upgrade datadog-operator datadog/datadog-operator \
+  -n <OPERATOR_NAMESPACE> \
+  --reuse-values \
+  --set 'watchNamespaces[0]=<DATADOG_AGENT_NAMESPACE>'
+
+Operator가 DatadogAgent 리소스가 생성된 네임스페이스를 감시하지 않을 경우, 해당 리소스는 오류, Kubernetes 이벤트, 문제를 나타내는 상태 업데이트 없이 조용히 조정에 실패합니다. + +## Datadog으로 텔레메트리 전송 {#send-your-telemetry-to-datadog} + +텔레메트리 데이터를 Datadog으로 전송하려면 다음 단계를 따르세요. + +1. [애플리케이션 계측](#instrument-the-application) +2. [애플리케이션 구성](#configure-the-application) +3. [관측 가능성 데이터 상호 연결](#correlate-observability-data) +4. [애플리케이션 실행](#run-the-application) + +### 애플리케이션 계측 {#instrument-the-application} + +[OpenTelemetry API를 사용][12]하여 애플리케이션을 계측합니다. + +{{% collapse-content title="OpenTelemetry API로 계측된 예시 애플리케이션" level="p" %}} +예시로 이미 계측이 완료된 [Calendar 샘플 애플리케이션][9]을 사용할 수 있습니다. 다음 코드에서는 OpenTelemetry 주석 및 API를 사용하여 [CalendarService.getDate()][10] 메서드를 계측합니다. + {{< code-block lang="java" filename="CalendarService.java" disable_copy="true" collapsible="false" >}} +@WithSpan(kind = SpanKind.CLIENT) +public String getDate() { + Span span = Span.current(); + span.setAttribute("peer.service", "random-date-service"); + ... +} +{{< /code-block >}} +{{% /collapse-content %}} + +### 애플리케이션 구성 {#configure-the-application} + +애플리케이션 컨테이너는 동일한 노드에서 실행 중인 DDOT Collector로 데이터를 전송해야 합니다. Collector가 `hostPort`를 통해 노드에서 OTLP 포트를 게시하므로 애플리케이션은 노드의 IP 주소(`status.hostIP`)를 통해 로컬 Collector에 도달할 수 있습니다. + +`OTEL_EXPORTER_OTLP_ENDPOINT` 환경 변수가 아직 설정되어 있지 않은 경우 애플리케이션의 Deployment 매니페스트 파일에 추가합니다. + {{< code-block lang="yaml" filename="deployment.yaml" disable_copy="true" collapsible="true" >}} +env: + ... + - name: HOST_IP + valueFrom: + fieldRef: + fieldPath: status.hostIP + - name: OTLP_GRPC_PORT + value: "4317" + - name: OTEL_EXPORTER_OTLP_ENDPOINT + value: 'http://$(HOST_IP):$(OTLP_GRPC_PORT)' + - name: OTEL_EXPORTER_OTLP_PROTOCOL + value: 'grpc' + {{< /code-block >}} + +### 관측 가능성 데이터 상호 연결 {#correlate-observability-data} + +[Unified Service Tagging][14]은 Datadog에서 관측 가능성 데이터를 서로 연결하여 일관된 태그로 메트릭, 트레이스 및 로그를 탐색할 수 있도록 해줍니다. + +컨테이너화된 환경에서는 OpenTelemetry Resource Attributes 환경 변수를 사용하여 `env`, `service`, `version`을 설정합니다. DDOT Collector는 이러한 태깅 구성을 탐지하고 컨테이너에서 수집한 데이터에 적용합니다. + +애플리케이션의 배포 매니페스트에 다음 환경 변수를 추가하세요. + +{{< code-block lang="yaml" filename="deployment.yaml" disable_copy="true" collapsible="true" >}} +apiVersion: apps/v1 +kind: Deployment +metadata: + name: +spec: + template: + spec: + containers: + - name: + env: + - name: OTEL_SERVICE_NAME + value: "" + - name: OTEL_RESOURCE_ATTRIBUTES + value: "service.version=,deployment.environment.name=" +{{< /code-block >}} + +### 애플리케이션 실행 {#run-the-application} + +배포 매니페스트 변경 사항을 적용하기 위해 애플리케이션을 다시 배포합니다. 업데이트된 구성이 활성화되면 Unified Service Tagging이 메트릭, 트레이스, 로그에 대해 완전히 활성화됩니다. + +## Datadog에서 관측 가능성 데이터 살펴보기 {#explore-observability-data-in-datadog} + +Datadog을 사용하여 애플리케이션의 관측 가능성 데이터를 살펴볼 수 있습니다. + +### Fleet Automation {#fleet-automation} + +Collector 구성을 살펴보세요. + +{{< img src="/opentelemetry/embedded_collector/fleet_automation.png" alt="Fleet Automation 페이지에서 Collector 구성을 검토하세요." style="width:100%;" >}} + +### Live Container Monitoring {#live-container-monitoring} + +Live Container Monitoring 기능을 사용하여 컨테이너 상태를 모니터링하세요. + +{{< img src="/opentelemetry/embedded_collector/containers.png" alt="Containers 페이지에서 컨테이너 상태를 모니터링하세요." style="width:100%;" >}} + +### 인프라 노드 상태 {#infrastructure-node-health} + +런타임 및 인프라 메트릭을 조회하여 노드 성능을 시각화, 모니터링 및 측정하세요. + +{{< img src="/opentelemetry/embedded_collector/infrastructure.png" alt="Host List에서 런타임 및 인프라 메트릭을 조회하세요." style="width:100%;" >}} + +### 로그 {#logs} + +로그를 조회하여 애플리케이션 및 시스템 작동 문제를 모니터링 및 해결하세요. + +{{< img src="/opentelemetry/embedded_collector/logs.png" alt="Log Explorer에서 로그를 조회하세요." style="width:100%;" >}} + +### 트레이스 {#traces} + +트레이스와 스팬을 조회하여 애플리케이션이 처리하는 요청의 상태 및 성능을 관찰할 수 있습니다. 동일한 트레이스 내에서 인프라 메트릭도 함께 연관되어 표시됩니다. + +{{< img src="/opentelemetry/embedded_collector/traces.png" alt="Trace Explorer에서 트레이스를 조회하세요." style="width:100%;" >}} + +### 런타임 메트릭 {#runtime-metrics} + +애플리케이션의 런타임(JVM) 메트릭을 모니터링하세요. + +{{< img src="/opentelemetry/embedded_collector/metrics.png" alt="JVM Metrics 대시보드에서 JVM 메트릭을 조회하세요." style="width:100%;" >}} + +### Collector 상태 메트릭 {#collector-health-metrics} + +DDOT Collector의 메트릭을 조회하여 Collector 상태를 모니터링하세요. + +{{< img src="/opentelemetry/embedded_collector/dashboard.png" alt="OTel 대시보드에서 Collector 상태 메트릭을 조회하세요." style="width:100%;" >}} + +## 추가 자료 {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://www.datadoghq.com/free-datadog-trial/ +[2]: https://app.datadoghq.com/organization-settings/api-keys/ +[3]: https://app.datadoghq.com/organization-settings/application-keys +[4]: https://opentelemetry.io/docs/platforms/kubernetes/helm/collector/ +[5]: https://kubernetes.io/docs/tasks/tools/#kubectl +[9]: https://github.com/DataDog/opentelemetry-examples/tree/main/apps/rest-services/java/calendar +[10]: https://github.com/DataDog/opentelemetry-examples/blob/main/apps/rest-services/java/calendar/src/main/java/com/otel/service/CalendarService.java#L27-L48 +[12]: /ko/tracing/trace_collection/custom_instrumentation/otel_instrumentation/ +[14]: /ko/getting_started/tagging/unified_service_tagging +[52]: /ko/getting_started/site/ +[54]: https://helm.sh +[55]: https://opentelemetry.io/docs/platforms/kubernetes/operator/ +[56]: https://kubernetes.io/docs/concepts/extend-kubernetes/operator/ +[57]: /ko/getting_started/containers/datadog_operator/ \ No newline at end of file diff --git a/hugo/content/ko/partners/multi_tenant_billing/customer-contracts-management.md b/hugo/content/ko/partners/multi_tenant_billing/customer-contracts-management.md new file mode 100644 index 00000000000..dbc30ed5cfe --- /dev/null +++ b/hugo/content/ko/partners/multi_tenant_billing/customer-contracts-management.md @@ -0,0 +1,39 @@ +--- +description: 관리자 조직 (Admin Org)에서 파트너의 영업 실적(고객, 계약, 청구서)을 관리하십시오. +title: 고객 계약 +--- +
+고객 계약은 미리 보기 상태입니다. +
+ +## 개요 {#overview} + +고객 계약을 통해 파트너는 Datadog과의 영업 실적에 대한 고객, 계약 및 청구서를 한곳에서 관리할 수 있습니다. 파트너는 일상적인 조회를 위해 파트너 계정 팀에 의존하는 대신 이 정보를 직접 조회할 수 있습니다. + +관리자 조직에서 {{< ui >}}Plan & Usage{{< /ui >}} > {{< ui >}}Customer Contracts{{< /ui >}}(으)로 이동하십시오. 아직 설정되지 않은 경우 [관리자 조직 요청하기][2]를 참조하십시오. + +{{< img src="partners/multi_tenant_billing/customer_contracts.png" alt="관리자 조직의 Plan & Usage 아래에 있는 고객 계약 탭으로, 고객 및 계약 목록이 표시됩니다." style="width:100%;" >}} + +**참고**: 고객 계약을 조회하려면 Billing Read 권한이 필요합니다. + +## 포함된 내용 {#whats-included} + +- 관리자 조직에 연결된 모든 고객과 그들의 현재 및 과거 계약, 그리고 갱신 예정이거나 이미 갱신 날짜가 지난 계약에 대해 갱신 알림이 제공됩니다. +- 계약 MRR (CMRR), 사용량 MRR (UMRR), 영향 상태, 계약 시작 및 종료 날짜와 함께 제품별 요금 및 주문서 PDF가 표시됩니다. +- 차감형 계약의 경우, 계약 종료 날짜와 비교하여 잔액, 예상 초과 사용량 및 예상 소진 날짜가 표시됩니다. +- MSP 계약의 경우, 각 계약에 속한 고객이 표시됩니다. +- 계약별 할인 및 마진 가시성이 표시됩니다. +- 각 고객에 대해 고객 가격 책정이 활성화되었는지, 아직 구성되지 않았는지, 또는 계약 변경 후 업데이트가 필요한지 여부가 표시됩니다. +- 고객별 주요 연락처가 표시됩니다: Datadog CSM, Datadog AE, 파트너 계정 팀 및 청구서를 수신하는 청구 담당자. + +{{< img src="partners/multi_tenant_billing/customer_contracts_detail.png" alt="고객의 지출 개요, 차감 소진, 계약 정보 및 연락처를 보여주는 고객 계약 세부 정보 패널이 표시됩니다." style="width:100%;" >}} + +청구서는 고객별로 발행일, 마감일, 금액 및 결제 상태와 함께 나열되며, 주요 고객 계약 페이지에서 연체 건수 및 총액으로 합산됩니다: + +{{< img src="partners/multi_tenant_billing/customer_contracts_invoices.png" alt="고객의 청구서 번호, 날짜, 금액 및 상태를 나열하는 고객 계약 청구서 탭이 표시됩니다." style="width:100%;" >}} + +## 관련 문서 {#related-docs} + +- [관리자 조직 요청하기][2] + +[2]: /ko/partners/multi_tenant_billing/#requesting-an-admin-org \ No newline at end of file diff --git a/hugo/content/ko/product_analytics/charts/analytics_explorer/_index.md b/hugo/content/ko/product_analytics/charts/analytics_explorer/_index.md new file mode 100644 index 00000000000..c7b04fd475a --- /dev/null +++ b/hugo/content/ko/product_analytics/charts/analytics_explorer/_index.md @@ -0,0 +1,86 @@ +--- +aliases: +- /ko/product_analytics/analytics_explorer/ +- /ko/product_analytics/journeys +description: '' +further_reading: +- link: /real_user_monitoring/explorer/search/ + tag: 설명서 + text: Datadog에서 뷰 탐색하기 +- link: /dashboards/functions/ + tag: 설명서 + text: 쿼리에 함수 추가하기 +- link: https://www.datadoghq.com/blog/product-analytics-faster-decisions + tag: 블로그 + text: Datadog Product Analytics로 더 빠르고 나은 제품 결정 내리기 +- link: https://www.datadoghq.com/blog/datadog-geomaps/ + tag: 블로그 + text: 지오맵을 사용하여 위치별로 앱 데이터 시각화하기 +- link: https://www.datadoghq.com/blog/reduce-customer-friction-funnel-analysis/ + tag: 블로그 + text: 퍼널 분석을 사용하여 주요 사용자 흐름을 파악하고 최적화하기 +title: 분석 +--- +## 개요 {#overview} + +[Analytics Explorer][1] 페이지에는 제품이 어떻게 사용되는지 파악할 수 있는 뷰 데이터를 집계해서 보여줍니다. 다음 항목을 제어할 수 있습니다. + +* 뷰를 확인할 기준이 되는 이벤트 유형(세션, 뷰 또는 액션) +* 분석할 뷰 세트를 필터링하는 쿼리 +* 데이터를 분할할 기준 +* 집계 및 분할 결과의 시각화 방법 + +Analytics 시각화를 사용하면 다음을 수행할 수 있습니다. + +* 해당 시각화를 기반으로 대시보드에 위젯을 생성합니다. +* 시각화가 지원하는 상호 작용에 따라 이벤트 목록의 하위 집합을 더 자세히 살펴볼 수 있습니다. + +## 분석 차트 사용 {#using-the-analytics-chart} +{{< whatsnext desc="다음 링크에서 분석 검색 구문 사용 방법, 이벤트 조회 방법, 뷰를 시각화, 그룹화 및 내보내기하는 방법을 알아보세요. " >}} + {{< nextlink href="product_analytics/charts/analytics_explorer/search_syntax" >}}검색 구문{{< /nextlink >}} + {{< nextlink href="product_analytics/charts/analytics_explorer/events" >}} 이벤트 {{< /nextlink >}} + {{< nextlink href="product_analytics/charts/analytics_explorer/visualize" >}}시각화{{< /nextlink >}} + {{< nextlink href="product_analytics/charts/analytics_explorer/group" >}}그룹{{< /nextlink >}} + {{< nextlink href="product_analytics/charts/analytics_explorer/export" >}}내보내기{{< /nextlink >}} +{{< /whatsnext >}} + +## 쿼리 빌드 {#build-a-query} + +[Analytics][1]에서 검색 쿼리에 패싯과 측정값을 추가하여 디스플레이를 사용자 지정하세요. + +1. [뷰 이벤트 유형][2]을 선택합니다. + + {{< img src="product_analytics/analytics/view_type_selection1.png" alt="뷰 유형 선택으로 범위가 지정된 Product Analytics의 드롭다운 메뉴" style="width:70%;">}} + +1. 고유 개수를 그래프로 표시할 측정값을 선택합니다. + + {{< img src="product_analytics/analytics/measure_selection1.png" alt="고유 개수를 그래프로 표시할 측정값을 선택하기 위한 Product Analytics의 드롭다운 메뉴" style="width:70%;">}} + +1. 이벤트 속성 또는 [타사 통합][6]의 속성으로 필터링합니다. + + {{< img src="product_analytics/analytics/pana_analytics_filter_by.png" alt="이벤트 자체 속성 또는 타사 통합에서 가져온 속성으로 이벤트를 필터링하기 위한 Product Analytics의 드롭다운 메뉴" style="width:70%;">}} + +1. 결과를 추가로 세분화할 이벤트 속성을 선택합니다. + + {{< img src="product_analytics/analytics/pana_analytics_breakdown_by1.png" alt="이벤트 자체 속성 또는 타사 통합에서 가져온 속성으로 이벤트를 추가로 세분화하기 위한 Product Analytics의 드롭다운 메뉴" style="width:70%;">}} + +1. [함수][4]를 적용하여 시각화를 위해 쿼리 결과가 반환되는 방식을 수정합니다. + + {{< img src="product_analytics/analytics/pana_analytics_functions.png" alt="시각화에 대해 메트릭 쿼리 결과가 반환되는 방식을 수정하는 함수를 추가하기 위한 Product Analytics의 버튼" style="width:70%;">}} + +1. 그래프의 [그래프 유형][5] 및 시간 간격을 선택합니다. 전역 타임프레임을 변경하면 사용 가능한 타임스텝 값 목록이 변경됩니다. + + {{< img src="product_analytics/analytics/pana_analytics_time_interval2.png" alt="그래프에 대한 그래프 유형 및 시간 간격을 선택" style="width:50%;">}} + + + +## 추가 자료 {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://app.datadoghq.com/product-analytics/explorer +[2]: /ko/real_user_monitoring/guide/understanding-the-rum-event-hierarchy/ +[3]: /ko/product_analytics/charts/analytics_explorer/group +[4]: /ko/dashboards/functions/#overview +[5]: /ko/product_analytics/charts/analytics_explorer/visualize/ +[6]: https://app.datadoghq.com/product-analytics/integrations/custom-attributes \ No newline at end of file diff --git a/hugo/content/ko/real_user_monitoring/_index.md b/hugo/content/ko/real_user_monitoring/_index.md index d79966225e4..ba7f00c84a9 100644 --- a/hugo/content/ko/real_user_monitoring/_index.md +++ b/hugo/content/ko/real_user_monitoring/_index.md @@ -9,7 +9,7 @@ aliases: cascade: algolia: rank: 70 -description: 사용자가 보는 프론트엔드 애플리케이션의 성능을 시각화, 관찰 및 분석하세요. +description: 사용자가 보는 프런트엔드 애플리케이션의 성능을 시각화, 관찰 및 분석하세요. disable_sidebar: true further_reading: - link: /real_user_monitoring/application_monitoring/browser/data_collected/ @@ -17,55 +17,59 @@ further_reading: text: 수집된 RUM 브라우저 데이터 - link: https://dtdg.co/fe tag: 기반 활성화 - text: 대화형 세션에 참여하여 Real User Monitoring을 통해 인사이트를 얻으세요. + text: Real User Monitoring을 통해 인사이트를 얻는 대화형 세션 참여하기 +- link: https://learn.datadoghq.com/courses/intro-to-rum + tag: 학습 센터 + text: Real User Monitoring(RUM) 소개 +- link: https://www.datadoghq.com/blog/ai-summaries-and-smart-chapters/ + tag: 블로그 + text: AI 요약 및 스마트 챕터로 세션 리플레이 더 빠르게 이해하기 - link: https://www.datadoghq.com/blog/real-user-monitoring-with-datadog/ tag: 블로그 text: Datadog Real User Monitoring 소개 - link: https://www.datadoghq.com/blog/datadog-mobile-rum/ tag: 블로그 - text: Datadog Mobile Real User Monitoring을 통해 모바일 사용자 경험 개선 + text: Datadog Mobile Real User Monitoring을 통해 모바일 사용자 경험 개선하기 - link: https://www.datadoghq.com/blog/mobile-monitoring-best-practices/ tag: 블로그 text: 모바일 앱 성능 모니터링을 위한 모범 사례 - link: https://www.datadoghq.com/blog/error-tracking/ tag: 블로그 - text: Datadog Error Tracking을 통해 애플리케이션 문제 파악 + text: Datadog Error Tracking을 통해 애플리케이션 문제 파악하기 - link: https://www.datadoghq.com/blog/unify-apm-rum-datadog/ tag: 블로그 - text: 전체 스택 가시성을 위해 애플리케이션 성능 모니터링(APM) 및 RUM 데이터 통합 + text: 전체 스택 가시성을 위해 애플리케이션 성능 모니터링(APM) 및 RUM 데이터 통합하기 - link: https://www.datadoghq.com/blog/datadog-geomaps/ tag: 블로그 - text: 지오맵을 사용하여 위치별로 앱 데이터 시각화 + text: 지오맵을 사용하여 위치별로 앱 데이터 시각화하기 - link: https://www.datadoghq.com/blog/datadog-rum-react-components/#tune-up-your-react-data-collection tag: 블로그 text: 사용자 지정 React 구성 요소로 더 나은 RUM 데이터 얻기 - link: https://www.datadoghq.com/blog/hybrid-app-monitoring/ tag: 블로그 - text: Datadog으로 하이브리드 모바일 애플리케이션 모니터링 + text: Datadog으로 하이브리드 모바일 애플리케이션 모니터링하기 - link: https://www.datadoghq.com/blog/how-datadogs-tech-solutions-team-rum-session-replay/ tag: 블로그 - text: Datadog의 기술 솔루션 팀이 RUM, 세션 리플레이 및 Error Tracking을 사용하여 고객 문제를 해결하는 방법 + text: Datadog의 기술 솔루션 팀이 RUM, Session Replay 및 Error Tracking을 사용하여 고객 문제를 해결하는 + 방법 - link: https://www.datadoghq.com/blog/static-web-application-monitoring-best-practices/ tag: 블로그 text: 정적 웹 애플리케이션 모니터링 모범 사례 - link: https://www.datadoghq.com/blog/progressive-web-application-monitoring/ tag: 블로그 - text: 점진적 웹 애플리케이션 모범 사례 + text: 점진적 웹 애플리케이션 모니터링 모범 사례 - link: https://www.datadoghq.com/blog/datadog-executive-dashboards tag: 블로그 - text: Datadog으로 효과적인 임원 대시보드 설계 + text: Datadog으로 효과적인 임원 대시보드 설계하기 - link: https://www.datadoghq.com/blog/rum-product-analytics-bridging-teams tag: 블로그 - text: '성능에서 영향까지: 공유 컨텍스트를 통한 프런트엔드 팀 연결' + text: '성능에서 영향까지: 공유 컨텍스트를 통한 프런트엔드 팀 연결하기' - link: https://app.datadoghq.com/release-notes?category=Real%20User%20Monitoring tag: 릴리스 노트 text: 최신 Datadog RUM 릴리스를 확인하세요! (앱 로그인 필요) -- link: https://learn.datadoghq.com/courses/intro-to-rum - tag: 학습 센터 - text: Real User Monitoring(RUM) 소개 -title: RUM 및 세션 리플레이 +title: RUM 및 Session Replay --- -{{< learning-center-callout header="활성화 웨비나 세션에 참가하기" hide_image="true" btn_title="등록" btn_url="https://www.datadoghq.com/technical-enablement/sessions/?tags.topics-0=RUM">}} +{{< learning-center-callout header="교육 웨비나 세션 참가" hide_image="true" btn_title="등록" btn_url="https://www.datadoghq.com/technical-enablement/sessions/?tags.topics-0=RUM">}} 구체적인 비즈니스 니즈에 맞춘 사용자 지정 사용자 액션을 생성하여 사용자 행동을 정확하게 추적하는 방법을 알아보세요. {{< /learning-center-callout >}} @@ -73,84 +77,82 @@ title: RUM 및 세션 리플레이 {{< img src="real_user_monitoring/performance-summary-browser.png" alt="RUM 대시보드" >}} -Datadog의 *Real User Monitoring(RUM)*을 이용하면 개별 사용자의 실시간 활동 및 경험에 대한 엔드투엔드 가시성을 확보할 수 있습니다. RUM은 웹 및 모바일 애플리케이션 모니터링과 관련해 다음과 같은 4가지 유형의 사용 사례를 해결합니다. +Datadog의 *Real User Monitoring(RUM)*을 이용하면 개별 사용자의 실시간 활동 및 경험을 엔드투엔드로 파악할 수 있는 가시성을 확보할 수 있습니다. RUM은 웹 및 모바일 애플리케이션 모니터링과 관련해 다음과 같은 4가지 유형의 사용 사례를 지원합니다. * **성능**: 웹 페이지, 모바일 애플리케이션 화면, 사용자 액션, 네트워크 요청, 프런트엔드 코드의 성능을 추적합니다. -* **오류 관리**: 진행 중인 버그와 문제를 모니터링하고 시간 및 버전에 걸쳐 추적합니다. -* **분석/사용량**: 애플리케이션을 누가 사용하는지 파악하고(국가, 장치, OS), 개별 사용자의 여정을 모니터링하며, 사용자가 애플리케이션과 어떻게 상호작용하는지 분석합니다(가장 많이 방문한 페이지, 클릭 수, 상호작용 및 기능 사용량). +* **오류 관리**: 진행 중인 버그와 문제를 모니터링하고 시간 및 버전별로 추적합니다. +* **분석/사용량**: 애플리케이션 사용자를 파악하고(국가, 장치, OS), 개별 사용자의 여정을 모니터링하며, 사용자가 애플리케이션과 상호작용하는 방식을 분석합니다(가장 많이 방문한 페이지, 클릭 수, 상호작용 및 기능 사용량). * **지원**: 하나의 사용자 세션과 관련된 모든 정보를 검색하여 문제를 해결합니다(세션 지속 시간, 방문한 페이지, 상호작용, 로드된 리소스 및 오류). ### 세션 정의 {#session-definition} -사용자 세션이란 웹 또는 모바일 애플리케이션에서의 사용자 여정을 말합니다. 세션에는 각종 관련 탐색 이벤트(RUM 조회), 사용자 액션(RUM 액션), 네트워크 요청(RUM 리소스), 크래시 및 오류(RUM 오류), 그리고 합쳐서 사용자 경험을 충실히 재현하는 데 사용할 수 있는 기타 이벤트 및 신호가 모두 포함됩니다. +사용자 세션이란 웹 또는 모바일 애플리케이션에서의 사용자 여정을 말합니다. 세션에는 관련된 각종 탐색 이벤트(RUM 뷰), 사용자 액션(RUM 액션), 네트워크 요청(RUM 리소스), 크래시 및 오류(RUM 오류), 그리고 사용자 경험을 충실히 재현하는 기타 이벤트 및 신호가 모두 포함됩니다. -RUM 세션 하나는 최대 4시간 지속될 수 있고, 활동이 없으면 15분 후에 만료됩니다. 사용자가 두 한도 중 하나가 지난 뒤에 애플리케이션과 상호작용을 하면 자동으로 새 세션이 시작됩니다. +RUM 세션 하나는 최대 4시간 지속될 수 있으며, 15분 동안 활동이 없으면 만료됩니다. 사용자가 두 제한 중 하나에 도달한 후 애플리케이션과 상호작용하면 자동으로 새 세션이 시작됩니다. -### 기술적인 한계 {#technical-limitations} +### 기술적 제한 사항 {#technical-limitations} -| 속성 | 한계 | +| 속성 | 제한 사항 | | ------------------------------------------ | ------------------------ | -| 세션 최대 기간 | 4시간 | +| 세션 최대 지속 시간 | 4시간 | | 세션 시간 초과 | 15분간 활동 없음 | -| 세션당 최대 이벤트 수 | 1천만 | +| 세션당 최대 이벤트 수 | 1,000만 | | 이벤트당 최대 속성 수 | 1,000 | | 이벤트당 최대 속성 깊이 | 20 | -| 이벤트 최대 크기 | 1MB | -| 인테이크 페이로드 최대 크기 | 5MB | -| 소스 맵 및 매핑 파일 최대 크기 | 파일당 500MB | -| dSYM 파일 최대 크기 | 파일당 2GB | -| 수집 시 최대 지연 | 24시간 | +| 최대 이벤트 크기 | 1MB | +| 최대 수집 페이로드 크기 | 5MB | +| 최대 소스 맵 및 매핑 파일 크기 | 파일당 500MB | +| 최대 dSYM 파일 크기 | 파일당 2GB | +| 최대 수집 지연 시간 | 24시간 | -이벤트가 위에 나열된 기술적 한계 중 하나라도 초과하면 Datadog 인테이크가 해당 이벤트를 거부합니다. +이벤트가 위에 나열된 기술적 제한 사항 중 하나라도 초과하면 Datadog 인테이크가 해당 이벤트를 거부합니다. -## 세션 리플레이란? {#what-is-session-replay} +## Session Replay란? {#what-is-session-replay} -Datadog의 *세션 리플레이*를 사용하면 사용자의 웹 탐색 경험을 캡처하여 시각적으로 재생할 수 있습니다. +Datadog의 *Session Replay*를 사용하면 사용자의 웹 탐색 경험을 캡처하여 시각적으로 재생할 수 있습니다. -세션 리플레이를 RUM 성능 데이터와 함께 사용하면 오류 식별, 재현, 해결에 유익하며 웹 애플리케이션의 사용량 패턴과 설계상 위험에 관한 인사이트를 얻을 수 있습니다. +Session Replay를 RUM 성능 데이터와 함께 사용하면 오류를 식별, 재현 및 해결하는 데 도움이 되며 웹 애플리케이션의 사용 패턴과 설계상의 문제점에 관한 인사이트를 얻을 수 있습니다. -## 시작하기 {#get-started} +## 시작 {#get-started} -RUM 데이터를 수집할 애플리케이션 유형 선택: +RUM 데이터를 수집할 애플리케이션 유형을 선택하세요. {{< card-grid card_width="210" >}} {{< image-card href="/real_user_monitoring/application_monitoring/browser/" src="integrations_logos/javascript_large.svg" alt="browser" >}} - {{< image-card href="/real_user_monitoring/application_monitoring/android/setup" src="integrations_logos/android_large.svg" alt="android" >}} - {{< image-card href="/real_user_monitoring/application_monitoring/ios/setup" src="integrations_logos/ios_large.svg" alt="ios" >}} - {{< image-card href="/real_user_monitoring/application_monitoring/react_native/setup" src="integrations_logos/react-native_large.svg" alt="react native" >}} - {{< image-card href="/real_user_monitoring/application_monitoring/flutter/setup" src="integrations_logos/flutter_large.svg" alt="flutter" >}} - {{< image-card href="/real_user_monitoring/application_monitoring/android/setup" src="integrations_logos/android_tv_large.svg" alt="android tv" >}} - {{< image-card href="/real_user_monitoring/application_monitoring/ios/setup" src="integrations_logos/tv_os_large.svg" alt="tv OS" >}} + {{< image-card href="/real_user_monitoring/application_monitoring/android/setup" src="integrations_logos/android_large.svg" alt="Android" >}} + {{< image-card href="/real_user_monitoring/application_monitoring/ios/setup" src="integrations_logos/ios_large.svg" alt="iOS" >}} + {{< image-card href="/real_user_monitoring/application_monitoring/react_native/setup" src="integrations_logos/react-native_large.svg" alt="React Native" >}} + {{< image-card href="/real_user_monitoring/application_monitoring/flutter/setup" src="integrations_logos/flutter_large.svg" alt="Flutter" >}} + {{< image-card href="/real_user_monitoring/application_monitoring/android/setup" src="integrations_logos/android_tv_large.svg" alt="Android TV" >}} + {{< image-card href="/real_user_monitoring/application_monitoring/ios/setup" src="integrations_logos/tv_os_large.svg" alt="tvOS" >}} {{< image-card href="/real_user_monitoring/application_monitoring/roku/setup" src="integrations_logos/roku_large.svg" alt="Roku" >}} - {{< image-card href="/real_user_monitoring/application_monitoring/unity/setup" src="integrations_logos/rum-unity_large.svg" alt="rum-unity" >}} + {{< image-card href="/real_user_monitoring/application_monitoring/unity/setup" src="integrations_logos/rum-unity_large.svg" alt="RUM-Unity" >}} {{< image-card href="/real_user_monitoring/application_monitoring/kotlin_multiplatform/setup" src="integrations_logos/kotlin-multiplatform_large.svg" alt="Kotlin Multiplatform" >}} {{< /card-grid >}} -
- ### 기능 및 플랫폼 지원 {#capabilities-and-platform-support} **참고**: Datadog Flutter SDK는 MacOS, Windows 또는 Linux에서는 지원되지 않습니다. -다음 표에 각 플랫폼에서 지원되는 RUM 기능이 무엇인지 표시했습니다. +다음 표는 각 플랫폼에서 지원되는 RUM 기능을 보여줍니다. | 기능 | 브라우저 | Android | iOS | Flutter | React Native | Roku | KMP | Unity | 참고 | | ------------------------------------- | --------|---------|---------|---------|--------------|------|-----|-------|--------| -| Datadog에 로그 보내기 | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | -| 네트워크 요청에 대한 분산 추적 | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | - **Roku**는 일부 유형의 HTTP 요청만 추적할 수 있습니다.
- **Unity**는 요청 추적을 위해 `UnityWebRequest`를 감싸는 래퍼를 사용합니다. | -| 조회 및 액션 추적(RUM) | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | - **Flutter Web**에서 추적한 모든 액션은 `custom`으로 기록됩니다.
- **Roku** 및 **Unity**는 수동 액션 추적만 지원합니다. | -| 기능 플래그 추적 및 릴리스 추적 | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | {{< X >}} | {{< X >}} | | -| Error Tracking 및 소스 매핑 | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | **React Native**에 부분적으로만 지원됩니다. | -| 크래시 추적, 기호화, 난독화 해제 | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | +| Datadog으로 로그 전송 | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | +| 네트워크 요청 분산 추적 | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | - **Roku**는 일부 유형의 HTTP 요청만 추적할 수 있습니다.
- **Unity**는 `UnityWebRequest`를 래핑하여 요청을 추적합니다. | +| 뷰 및 액션 추적(RUM) | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | - **Flutter Web**에서 추적된 모든 액션은 `custom`으로 기록됩니다.
- **Roku** 및 **Unity**는 수동 액션 추적만 지원합니다. | +| Feature Flags 추적 및 릴리스 추적 | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | {{< X >}} | {{< X >}} | | +| 오류 추적 및 소스 매핑 | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | +| 충돌 추적, 기호화, 난독화 해제 | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | | 세션 중지(키오스크 모니터링) | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | {{< X >}} | {{< X >}} | | -| 웹 보기에서 이벤트 추적 | | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | {{< X >}} | | | +| 웹뷰에서 이벤트 추적 | | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | {{< X >}} | | | | 플랫폼별 바이탈 모니터링 | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | {{< X >}} | | | | 로그의 글로벌 컨텍스트/속성 추적 | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | {{< X >}} | {{< X >}} | | | 클라이언트 측 추적 | | {{< X >}} | {{< X >}}| | | | | | | | -| 세션 리플레이 | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | {{< X >}} | | **Flutter** 세션 리플레이는 미리 보기 상태입니다. | -| 불만 신호 | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | 모든 **모바일** 및 **Roku** 장치에 부분적으로만 지원됩니다. | +| Session Replay | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | {{< X >}} | | **Flutter** Session Replay는 미리 보기 상태입니다. | +| 불만 신호 | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | 모든 **모바일** 및 **Roku** 장치에서는 일부 기능만 지원됩니다. | -## SDK 도메인에 지원되는 엔드포인트 {#supported-endpoints-for-sdk-domains} +## SDK 도메인에서 지원되는 엔드포인트 {#supported-endpoints-for-sdk-domains} 모든 Datadog SDK 트래픽은 SSL(기본값 443)을 통해 다음 도메인으로 전송됩니다. @@ -164,16 +166,35 @@ RUM 데이터를 수집할 애플리케이션 유형 선택: | US2-FED | `https://browser-intake-us2-ddog-gov.com` | | AP1 | `https://browser-intake-ap1-datadoghq.com` | | AP2 | `https://browser-intake-ap2-datadoghq.com` | +| UK1 | `https://browser-intake-uk1-datadoghq.com` | + +### Browser Profiling용 추가 엔드포인트 {#additional-endpoints-for-browser-profiling} + +[Browser Profiling][19]을 활성화하면 SDK는 현재 세션에서 프로파일링이 허용되는지 확인하기 위해 할당량 API에도 연결합니다. 이는 표준 수집 출처의 `quota.` 하위 도메인을 사용합니다. + +| 사이트 | 쿼터 API URL | +|------|-----------------------------------------------------------| +| US1 | `https://quota.browser-intake-datadoghq.com` | +| US3 | `https://quota.browser-intake-us3-datadoghq.com` | +| US5 | `https://quota.browser-intake-us5-datadoghq.com` | +| EU1 | `https://quota.browser-intake-datadoghq.eu` | +| US1-FED | `https://quota.browser-intake-ddog-gov.com` | +| US2-FED | `https://quota.browser-intake-us2-ddog-gov.com` | +| AP1 | `https://quota.browser-intake-ap1-datadoghq.com` | +| AP2 | `https://quota.browser-intake-ap2-datadoghq.com` | +| UK1 | `https://quota.browser-intake-uk1-datadoghq.com` | + +[프록시][20]를 사용하거나 [콘텐츠 보안 정책(CSP)][21]이 있는 경우, 이러한 `quota.` 도메인도 허용되는지 확인하세요. 자세한 내용은 [Browser Profiling 설정][19] 페이지를 참조하세요. -## Datadog RUM 둘러보기 {#explore-datadog-rum} +## Datadog RUM 살펴보기 {#explore-datadog-rum} -RUM에 액세스하려면 [**디지털 경험 > 성능 요약**][1]으로 이동합니다. +[{{< ui >}}Digital Experience{{< /ui >}} > {{< ui >}}Performance Summary{{< /ui >}}][1]로 이동하여 RUM에 액세스하세요. -상단 탐색 창에서 애플리케이션을 선택하거나 [브라우저][15] 또는 [모바일][16] 설정 지침을 따라 첫 애플리케이션을 추가합니다. +상단 탐색 창에서 애플리케이션을 선택하거나 [브라우저][15] 또는 [모바일][16] 설정 지침을 따라 첫 애플리케이션을 추가하세요. {{< img src="real_user_monitoring/rum-performance-application-selector.png" alt="RUM 애플리케이션 선택" >}} -**팁**: Datadog 글로벌 검색에서 RUM을 열려면 Cmd/Ctrl + K를 누르고 `real user monitoring`을 검색하세요. +**팁**: Datadog 글로벌 검색에서 RUM을 열려면 Cmd/Ctrl+K 키를 누르고 `real user monitoring`을 검색하세요. ## 성능 모니터링 요약 {#performance-monitoring-summary} @@ -181,82 +202,82 @@ RUM에 액세스하려면 [**디지털 경험 > 성능 요약**][1]으로 이동 |---------|---------| | {{< img src="real_user_monitoring/performance-summary-browser.png" alt="브라우저 애플리케이션의 RUM 성능 모니터링 요약 페이지" >}} | {{< img src="real_user_monitoring/performance-summary-mobile-2.png" alt="모바일 애플리케이션의 RUM 성능 모니터링 요약 페이지" >}} | -[RUM 성능 모니터링 요약][1] 페이지에 웹 및 모바일 애플리케이션 양쪽 모두의 관련 인사이트 및 실행 가능한 인사이트가 표시됩니다. 각 플랫폼에 맞춤형 경험이 제공되어 다음과 같이 도움이 됩니다. +[RUM Performance Monitoring summary][1] 페이지에는 웹 및 모바일 애플리케이션 양쪽 모두의 관련성이 높고 실행 가능한 인사이트가 표시됩니다. 각 플랫폼에 맞게 최적화된 환경을 통해 다음을 수행할 수 있습니다. -플랫폼별로 - **주요 데이터 포인트에 집중**(예를 들어 웹 또는 모바일 크래시의 경우 UI 지연 시간) -- **애플리케이션 상태 모니터링**(웹 앱의 경우 코어 웹 바이탈, iOS의 경우 멈춤 빈도와 같이 친숙한 KPI를 통해 앱 안정성 평가) -- **심층 조사에 직접 돌입**(페이지를 종료할 필요 없이 대화형 위젯에서 직접 시작) +- **플랫폼별 주요 데이터 포인트에 집중**: 웹의 UI 지연 시간이나 모바일 충돌 등 주요 지표를 확인합니다. +- **애플리케이션 상태 모니터링**: 웹 앱의 Core Web Vitals이나 iOS의 중단 비율과 같은 익숙한 KPI를 통해 앱 안정성을 평가합니다. +- **즉시 조사 시작**: 페이지를 종료하지 않고 대화형 위젯에서 바로 조사할 수 있습니다. -**웹 앱**의 경우, 검색 창을 사용해 데이터를 필터링하고, 속도가 느린 페이지를 파악하고 UI를 따라 [RUM 최적화 조사][17] 페이지로 이동하세요. +**웹 앱**의 경우, 검색 창을 사용하여 데이터를 필터링하고, 속도가 느린 페이지를 파악하고 UI를 따라 [RUM Optimization Inspect][17] 페이지로 이동하세요. -**모바일 앱**의 경우, 페이지 맨 아래에서 최근 크래시를 검토하고 문제 해결에는 [Error Tracking][6] 사이드 패널을 사용하세요. +**모바일 앱**의 경우, 페이지 맨 아래에서 최근 충돌을 검토하고 [Error Tracking][6] 사이드 패널을 사용하여 문제를 해결하세요. -### 즉시 사용 가능한 대시보드 {#out-of-the-box-dashboards} +### 기본 제공 대시보드 {#out-of-the-box-dashboards} -[즉시 사용 가능한 RUM 대시보드][2]를 사용해 자동으로 수집된 사용자 세션, 성능, 모바일 애플리케이션, 불만 신호, 네트워크 리소스 및 오류 관련 정보를 분석합니다. +[기본 제공 RUM 대시보드][2]를 사용하여 자동으로 수집된 사용자 세션, 성능, 모바일 애플리케이션, 불만 신호, 네트워크 리소스 및 오류 관련 정보를 분석합니다. {{< img src="real_user_monitoring/rum-out-of-the-box-dashboard.png" alt="RUM 대시보드" >}} ### RUM 탐색기 및 시각화 {#rum-explorer-and-visualizations} -[시각화][3]를 사용해 사용자 세션을 세그먼트별로 조회합니다. 예를 들어 지연 시간이 프리미엄 고객에게 영향을 미치는 시점을 검사합니다. 사용자 지정 검색에 대한 데이터를 탐색하고, 뷰를 저장하고 [모니터][4]를 생성합니다. +[시각화][3]를 사용해 사용자 세션을 세그먼트별로 조회하세요. 예를 들어 지연 시간이 프리미엄 고객에게 영향을 미치는 시점을 확인할 수 있습니다. 데이터를 탐색하고, 뷰를 저장하고 사용자 지정 검색을 기반으로 [모니터][4]를 생성하세요. {{< img src="real_user_monitoring/explorer/analytics/rum_analytics.mp4" alt="RUM 분석" video=true >}} -### 로그, APM 및 프로파일러와 통합 {#integration-with-logs-apm-and-profiler} +### 로그, APM 및 프로파일러 통합 {#integration-with-logs-apm-and-profiler} [백엔드 트레이스, 로그 및 인프라 메트릭][5]을 애플리케이션 성능에 영향을 미치는 정확한 코드 줄까지 조회하세요. 이러한 내용은 사용자 경험 및 보고된 문제와 일치합니다. {{< img src="real_user_monitoring/connect_rum_and_traces/rum_apm_logs-2.png" alt="RUM 및 APM" >}} -### Error tracking 및 크래시 보고 {#error-tracking-and-crash-reporting} +### 오류 추적 및 충돌 보고 {#error-tracking-and-crash-reporting} -[Error tracking][6]을 통해 이상값과 오류 그룹, 시간 초과 및 충돌에 대한 자동 경고를 받아 MTTR을 크게 줄일 수 있습니다. +[Error Tracking][6]을 통해 이상치와 오류 그룹, 시간 초과 및 충돌에 대한 경보를 자동으로 받아 MTTR을 크게 줄일 수 있습니다. {{< img src="real_user_monitoring/error_tracking/errors_rum.mp4" alt="RUM 오류 추적" video=true >}} ### 웹 및 모바일 바이탈 {#web-and-mobile-vitals} -[iOS 및 tvOS][8]용 코어 웹 바이탈 및 모바일 바이탈 또는 [안드로이드 및 안드로이드 TV 애플리케이션][9]과 같은 [브라우저 애플리케이션][7]의 성능 점수 및 텔레메트리를 확인합니다. +[브라우저 애플리케이션][7]의 Core Web Vitals와 [iOS, iPadOS, tvOS 및 visionOS][8] 또는 [Android 및 Android TV 애플리케이션][9]의 Mobile Vitals와 같은 성능 점수 및 텔레메트리를 조회하세요. -### 웹 보기 추적 {#web-view-tracking} +### 웹뷰 추적 {#web-view-tracking} -[iOS 및 tvOS][10] 또는 [Android 및 Android TV][11]에 대한 웹 보기 추적을 통해 기본 웹 애플리케이션에서 정보를 수집하고 하이브리드 보기를 탐색할 수 있습니다. +[iOS, iPadOS 및 visionOS][10] 또는 [Android 및 Android TV][11]용 Web View Tracking을 사용하여 네이티브 웹 애플리케이션의 정보를 수집하고 하이브리드 웹뷰를 탐색하세요. -{{< img src="real_user_monitoring/webview_tracking/webview_tracking_light.png" alt="RUM 탐색기의 사용자 세션에 캡처된 웹 보기" >}} +{{< img src="real_user_monitoring/webview_tracking/webview_tracking_light.png" alt="RUM 탐색기의 사용자 세션에 캡처된 웹뷰" >}} -## Datadog 세션 리플레이 둘러보기 {#explore-datadog-session-replay} +## Datadog Session Replay 살펴보기 {#explore-datadog-session-replay} ### 세션 리플레이 {#session-replays} -웹사이트와 상호작용을 하는 실제 사용자의 [브라우저 녹화본][12]을 보고 조직의 [개인정보 보호 제어][13]를 설정하세요. +실제 사용자가 웹사이트와 상호작용하는 [브라우저 녹화][12]를 확인하고 조직의 [개인정보 보호 제어][13]를 설정하세요. ### 개발자 도구 {#developer-tools} -[브라우저 개발 도구][14]을 사용하여 애플리케이션 문제 해결 시 트리거된 로그, 오류 및 성능 정보에 액세스합니다. +애플리케이션 문제 해결 시 [브라우저 개발 도구][14]를 사용하여 트리거된 로그, 오류 및 성능 정보에 액세스하세요. ## 권한 {#permissions} 기본적으로 모든 사용자가 애플리케이션의 RUM 구성을 변경할 수 있습니다. -특정 애플리케이션의 RUM 구성을 편집할 수 있는 [역할][18]을 제한하려면 세분화된 액세스 제어 사용: -1. 애플리케이션의 RUM 구성을 조회하는 중에 화면 맨 위에 있는 **애플리케이션 편집** 버튼을 클릭합니다. 드롭다운이 표시됩니다. -1. **앱 권한 관리**를 선택합니다. -1. **액세스 제한**을 클릭합니다. -1. 대화 상자가 업데이트되어 기본적으로 **뷰어** 액세스 권한이 있는 조직 구성원이 표시됩니다. -1. 드롭다운을 사용하여 노트북을 편집할 수 있는 역할, 팀 또는 사용자를 하나 이상 선택합니다. -1. **추가**를 클릭합니다. -1. 대화 상자가 업데이트되어 선택한 역할에 **편집자** 권한이 있는 것으로 표시됩니다. -1. **저장**을 클릭합니다. +세분화된 액세스 제어를 사용하여 특정 애플리케이션의 RUM 구성을 편집할 수 있는 [역할][18]을 제한할 수 있습니다. +1. 애플리케이션의 RUM 구성을 조회하는 중에 화면 맨 위에 있는 {{< ui >}}Edit application{{< /ui >}} 버튼을 클릭합니다. 드롭다운이 표시됩니다. +1. {{< ui >}}Manage App Permissions{{< /ui >}}를 선택합니다. +1. {{< ui >}}Restrict Access{{< /ui >}}를 클릭합니다. +1. 대화 상자가 업데이트되어 조직 구성원이 기본적으로 {{< ui >}}Viewer{{< /ui >}} 액세스 권한이 있는 것으로 표시됩니다. +1. 드롭다운을 사용하여 노트북을 편집할 수 있는 하나 이상의 역할, 팀 또는 사용자를 선택합니다. +1. {{< ui >}}Add{{< /ui >}}를 클릭합니다. +1. 대화 상자가 업데이트되어 선택한 역할에 {{< ui >}}Editor{{< /ui >}} 권한이 있는 것으로 표시됩니다. +1. {{< ui >}}Save{{< /ui >}}를 클릭합니다. -**참고:** 애플리케이션에 대한 편집 액세스를 유지하려면 저장하기 전에 사용자가 구성원인 역할을 하나 이상 포함해야 합니다(시스템 요구 사항). +**참고:** 애플리케이션에 대한 편집 액세스를 유지하려면 저장하기 전에 사용자가 속한 역할을 하나 이상 포함해야 합니다. -제한된 애플리케이션에 대한 일반 액세스를 복원하려면 편집 액세스 권한이 있어야 합니다. 다음 단계를 완료하세요. -1. 애플리케이션의 RUM 구성을 조회하는 중에 화면 맨 위에 있는 **애플리케이션 편집** 버튼을 클릭합니다. 드롭다운이 표시됩니다. -1. **앱 권한 관리**를 선택합니다. -1. **전체 액세스 복원**을 클릭합니다. -1. **저장**을 클릭합니다. +제한된 애플리케이션에 대한 일반 액세스를 복원하려면 편집 권한이 있어야 합니다. 다음 단계를 따르세요. +1. 애플리케이션의 RUM 구성을 조회하는 중에 화면 맨 위에 있는 {{< ui >}}Edit application{{< /ui >}} 버튼을 클릭합니다. 드롭다운이 표시됩니다. +1. {{< ui >}}Manage App Permissions{{< /ui >}}를 선택합니다. +1. {{< ui >}}Restore Full Access{{< /ui >}}를 클릭합니다. +1. {{< ui >}}Save{{< /ui >}}를 클릭합니다. ## 추가 자료 {#further-reading} @@ -275,9 +296,12 @@ RUM에 액세스하려면 [**디지털 경험 > 성능 요약**][1]으로 이동 [10]: /ko/real_user_monitoring/application_monitoring/ios/web_view_tracking/ [11]: /ko/real_user_monitoring/application_monitoring/android/web_view_tracking/ [12]: /ko/session_replay/browser/ -[13]: /ko/session_replay/browser/privacy_options/ -[14]: /ko/session_replay/browser/dev_tools/ +[13]: /ko/session_replay/privacy_options?platform=browser +[14]: /ko/session_replay/dev_tools [15]: /ko/real_user_monitoring/application_monitoring/browser/setup/ [16]: /ko/real_user_monitoring/application_monitoring/ [17]: https://app.datadoghq.com/rum/optimization/inspect -[18]: /ko/account_management/rbac/ \ No newline at end of file +[18]: /ko/account_management/rbac/ +[19]: /ko/real_user_monitoring/correlate_with_other_telemetry/profiling +[20]: /ko/real_user_monitoring/guide/proxy-rum-data +[21]: /ko/integrations/content_security_policy_logs \ No newline at end of file diff --git a/hugo/content/ko/security/code_security/static_analysis/configuration.md b/hugo/content/ko/security/code_security/static_analysis/configuration.md index 30d2c7dc039..08d8e0a71a7 100644 --- a/hugo/content/ko/security/code_security/static_analysis/configuration.md +++ b/hugo/content/ko/security/code_security/static_analysis/configuration.md @@ -26,6 +26,7 @@ AI 네이티브 SAST가 활성화되면 리포지토리에서 감지된 지원 | 언어 | 규칙 세트 | | --- | --- | | C# | `csharp-ai_sast` | +| C++ | `cpp-ai_sast` | | Dart | `dart-ai_sast` | | Elixir | `elixir-ai_sast` | | Go | `go-ai_sast` | diff --git a/hugo/content/ko/security/sensitive_data_scanner/guide/investigate_sensitive_data_findings.md b/hugo/content/ko/security/sensitive_data_scanner/guide/investigate_sensitive_data_findings.md new file mode 100644 index 00000000000..31e7bc3314e --- /dev/null +++ b/hugo/content/ko/security/sensitive_data_scanner/guide/investigate_sensitive_data_findings.md @@ -0,0 +1,129 @@ +--- +aliases: +- /ko/sensitive_data_scanner/investigate_sensitive_data_issues/ +- /ko/sensitive_data_scanner/guide/investigate_sensitive_data_issues/ +- /ko/security/sensitive_data_scanner/guide/investigate_sensitive_data_issues/ +description: Findings 페이지에서 Sensitive Data Scanner 발견 결과를 분류하고 조사하세요. 여기에는 Blast Radius + 분석, 영향을 받는 서비스, Case Management 및 Incident Management 통합이 포함됩니다. +further_reading: +- link: sensitive_data_scanner/setup/telemetry_data/ + tag: 설명서 + text: 텔레메트리 데이터를 위한 Sensitive Data Scanner 설정하기 +- link: sensitive_data_scanner/setup/cloud_storage/ + tag: 설명서 + text: 클라우드 스토리지를 위한 Sensitive Data Scanner 설정하기 +- link: https://www.datadoghq.com/blog/scaling-sensitive-data-scanner/ + tag: 블로그 + text: Sensitive Data Scanner를 사용하여 대규모로 민감 데이터 문제를 식별, 분류 및 해결하기 +title: 민감 데이터 발견 결과 조사 +--- +## 개요 {#overview} + +Datadog의 Sensitive Data Scanner는 민감 데이터를 식별, 분류하고 필요시 비식별화하여 민감 데이터 유출을 방지하고 비준수 위험을 줄이는 데 도움을 줄 수 있습니다. 민감 데이터가 발견되면 다음과 같은 질문이 생길 수 있습니다. + +- 어떤 민감 데이터가 노출되었나요? +- 민감 데이터 노출의 우선순위는 무엇인가요? +- 확산 및 볼륨 측면에서 발견 결과가 얼마나 심각한가요? +- 민감 데이터의 출처는 어디인가요? + +Sensitive Data Scanner의 [Findings][1] 페이지에서는 민감 데이터 발견 결과를 분류하고 우선순위를 지정하므로 이를 조사, 협업, 문서화하고 해당 질문에 대한 답을 찾을 수 있습니다. + +{{< img src="sensitive_data_scanner/sds_findings_explorer.png" alt="US Passport Scanner 규칙이 확장되어 중요 발견 결과, 일치 항목 수 및 주간 추세 차트를 보여주는 규칙별 Sensitive Data Scanner Findings 탐색기" style="width:100%;" >}} + +## 민감 데이터 발견 결과 분류 {#triage-sensitive-data-findings} + +[Findings][1] 페이지로 이동하여 선택한 기간 내의 모든 민감 데이터 발견 결과를 확인하고 조사를 시작하세요. + +{{< tabs >}} +{{% tab "로그" %}} + +Logs Findings 탐색기는 로그 발견 결과를 조사하는 데 사용되는 업데이트된 탐색기입니다. 로그 발견 결과가 하나 이상 있는 경우 이 탐색기가 기본적으로 열립니다. APM, RUM 및 이벤트 발견 결과는 이 탐색기에서 사용할 수 없습니다. 해당 발견 결과를 조회하려면 페이지 상단 배너에서 {{< ui >}}Go back{{< /ui >}}을 클릭하세요. + +로그 발견 결과를 조사하려면 다음 단계를 따르세요. + +1. {{< ui >}}Group by{{< /ui >}}를 사용하여 발견 결과를 {{< ui >}}Rule{{< /ui >}}, {{< ui >}}Logs Pattern{{< /ui >}} 또는 {{< ui >}}Service{{< /ui >}}별로 구성합니다. 민감 데이터가 현재 노출되고 있는 발견 결과를 표시하려면 {{< ui >}}Match State{{< /ui >}} 패싯에서 {{< ui >}}Leaking{{< /ui >}}으로 필터링하세요. +2. 발견 결과를 클릭하여 세부 정보 패널을 엽니다. +3. 패널 상단에서 {{< ui >}}First Detected{{< /ui >}} 및 {{< ui >}}Last Detected{{< /ui >}}를 확인하여 노출이 활성화된 기간을 파악합니다. +4. 요약 섹션에서 {{< ui >}}Match State{{< /ui >}}, {{< ui >}}Service{{< /ui >}}, {{< ui >}}Environment{{< /ui >}} 및 {{< ui >}}Total matches{{< /ui >}}를 검토하여 노출 범위를 파악합니다. +5. {{< ui >}}Logs Pattern{{< /ui >}}을 검토하여 민감 데이터가 탐지된 로그 라인의 형식을 파악합니다. +6. {{< ui >}}Example Logs{{< /ui >}} 섹션에서 영향을 받는 로그의 대표적인 예시를 최대 5개까지 검토합니다. 예시 로그가 만료되면 다음 일치하는 이벤트로 대체됩니다. {{< ui >}}Show log{{< /ui >}}를 클릭하여 예시를 확장하고 로그 메시지, 필드 및 속성을 인라인으로 검사하세요. 기본적으로 예시 로그는 7일 동안 저장되며 Data Scanner Read 권한이 있는 모든 사용자가 액세스할 수 있습니다. 이러한 대표 로그를 다른 기간 동안 저장하려면 [지원팀][1]에 문의하세요. +7. {{< ui >}}Matches Trend{{< /ui >}}를 검토하여 지난 1주일 동안 일치 항목 볼륨이 어떻게 변화했는지 확인합니다. {{< ui >}}Related Access and Configuration Events{{< /ui >}}를 사용하여 최근 액세스 이벤트나 스캔 그룹 또는 스캔 규칙의 변경 사항이 일치 항목 볼륨의 변화와 일치하는지 확인합니다. + +또한 다음을 수행할 수 있습니다. +- {{< ui >}}Apply Targeted Obfuscation{{< /ui >}}을 사용하여 이 발견 결과에 대한 새 로그에서 향후 민감 데이터 일치 항목을 난독화하거나 난독화 적용 범위를 전체 서비스로 확장하세요. 비식별화가 이미 활성화된 경우, 이 섹션에서 일치하는 로그가 어떻게 난독화되는지 확인하세요. +- {{< ui >}}Tune Detection Logic{{< /ui >}}을 사용하여 스캔 규칙의 키워드를 편집하거나 오탐 또는 위험이 허용된 데이터를 억제하세요. +- {{< ui >}}Generate Code Fix{{< /ui >}}를 사용하여 유출을 유발하는 로그 패턴을 식별하고 수정 사항을 제안하는 [Bits Code][2] 세션을 시작하세요. 수정 사항을 검토하고 세션에서 직접 풀 리퀘스트를 생성하세요. 소스 리포지토리는 이미 Bits Code에 온보딩되어 있어야 합니다. + +[1]: /ko/help +[2]: /ko/bits_ai/bits_code/ + +{{% /tab %}} +{{% tab "APM, RUM 및 이벤트" %}} + +{{< ui >}}Sensitive Data Rule Findings{{< /ui >}} 탭에서 우선순위 상태, 케이스 상태 및 도메인별로 민감 데이터 발견 결과를 필터링할 수 있습니다. + +결과를 조사하려면 다음 단계를 따르세요. + +1. 목록에서 해당 발견 결과를 클릭합니다. +2. 발견 결과 패널에서 {{< ui >}}View Recent Changes{{< /ui >}}를 클릭하여 [Audit Trail][3]로 이동한 후 민감 데이터 발견 결과의 원인이 된 최근 구성 변경 사항이 있는지 확인합니다. +3. 다음 옵션을 사용하여 쿼리와 일치하는 다양한 유형의 데이터를 탐색합니다. + 1. Log Explorer에서 쿼리와 관련된 모든 로그를 조회하려면 {{< ui >}}View All Logs{{< /ui >}}를 클릭하세요. + 1. Trace Explorer에서 쿼리와 일치하는 모든 트레이스를 조회하려면 {{< ui >}}View All APM Spans{{< /ui >}}를 클릭하세요. + 1. 쿼리와 일치하는 모든 RUM 이벤트를 조회하려면 {{< ui >}}View All RUM Events{{< /ui >}}를 클릭하세요. + 1. 쿼리와 일치하는 모든 이벤트를 조회하려면 {{< ui >}}View All Events{{< /ui >}}를 클릭하세요. + {{< img src="sensitive_data_scanner/investigate_sensitive_data_issues/findings_panel_20251015.png" alt="심각한 Visa 카드 스캐너 발견 결과가 표시된 발견 결과 패널" style="width:50%;">}} +4. {{< ui >}}Blast Radius{{< /ui >}} 섹션에서 다음을 수행합니다. + 1. 이 민감 데이터 발견 결과로 인해 영향을 받은 상위 10개 서비스, 호스트, 환경을 조회합니다. + 1. 서비스를 클릭하여 {{< ui >}}Catalog{{< /ui >}}에서 해당 서비스에 대한 자세한 정보를 확인합니다. + 1. 호스트를 클릭하여 Infrastructure List 페이지에서 해당 호스트에 대한 자세한 정보를 확인합니다. + {{< img src="sensitive_data_scanner/investigate_sensitive_data_issues/blast_radius_02_01_2024.png" alt="영향을 받은 상위 10개 서비스가 표시된 발견 결과 패널" style="width:50%;">}} + + 민감 데이터 발견 결과를 탐지하는 데 사용된 스캔 규칙을 수정하려면 패널 상단의 {{< ui >}}Modify Rule{{< /ui >}}을 클릭하세요. + +또한 다음을 수행할 수 있습니다. +- [Case Management][1]를 사용하여 발견 결과를 추적, 분류 및 조사하려면 패널 상단의 {{< ui >}}Create Case{{< /ui >}}를 클릭하세요. 관련 케이스는 Findings 페이지에 표시됩니다. +- [Incident Management][2]를 사용하여 인시던트를 생성하고, 발견 결과를 기존 인시던트에 추가하거나 새 인시던트를 선언할 수 있습니다. {{< ui >}}Declare Incident{{< /ui >}} 드롭다운 메뉴를 클릭하여 발견 결과를 기존 인시던트에 추가하세요. {{< ui >}}Declare Incident{{< /ui >}}을 클릭하여 새 인시던트를 선언하세요. +- [Audit Trail][3]을 사용하여 Datadog 내에서 이 민감 데이터에 액세스했을 수 있는 사용자를 확인하려면 {{< ui >}}Users who accessed these events{{< /ui >}} 섹션에서 {{< ui >}}View in Audit Trail{{< /ui >}}을 클릭하세요. + +{{< img src="sensitive_data_scanner/investigate_sensitive_data_issues/case_mgmt_02_01_2024.png" alt="보안 발견 결과, 담당자, 케이스 생성자 및 이벤트 타임라인에 대한 정보가 표시되는 케이스 페이지" style="width:60%;">}} + +[1]: /ko/incident_response/work_management/ +[2]: /ko/incident_response/incident_management/ +[3]: /ko/account_management/audit_trail + +{{% /tab %}} +{{% tab "Cloud Storage" %}} + +{{< ui >}}Datastores with Sensitive Data{{< /ui >}} 탭을 클릭하여 Cloud Storage에 대한 모든 민감 데이터 발견 결과를 확인합니다. + +데이터스토어를 조사하려면 다음 단계를 따르세요. + +1. 데이터스토어를 클릭합니다. +1. 민감 데이터가 발견된 파일을 조회한 후 파일을 클릭하여 AWS에서 검사할 수 있습니다. + Datadog은 다음을 수행할 것을 권장합니다. + - 몇 개의 파일을 검토하여 분류 정확도를 파악하세요. + - 사이드 패널에 나열된 팀 또는 서비스 소유자에게 문의하여 민감 데이터가 해당 버킷에 포함되어야 하는 데이터인지 확인하세요. + - 버킷에 포함되어서는 안 되는 경우 파일을 삭제하거나 적절한 버킷으로 이동하세요. + - 버킷에 있어야 하는 경우 다음 단계를 완료하여 보안 상태를 개선하세요. + 1. 사이드 패널에서 {{< ui >}}Security{{< /ui >}} 탭을 클릭하고 {{< ui >}}Misconfigurations{{< /ui >}} 섹션을 검토합니다. + 1. 잘못된 구성을 클릭하여 Cloud Security에서 세부 정보를 확인합니다. + 1. {{< ui >}}Next Steps{{< /ui >}} 섹션에서 다음을 수행합니다. + 1. {{< ui >}}Triage{{< /ui >}} 아래에서 드롭다운을 클릭하여 신호의 분류 상태를 변경합니다. 기본 상태는 `OPEN`입니다. + 1. {{< ui >}}Assign Signal{{< /ui >}}을 클릭하여 본인 또는 다른 Datadog 사용자에게 신호를 할당합니다. + 1. {{< ui >}}See remediation{{< /ui >}}을 클릭하여 해당 발견 결과를 해결하는 방법에 대한 자세한 정보를 확인합니다. + 1. {{< ui >}}More Actions{{< /ui >}} 아래에서 Jira 이슈를 추가하거나, 워크플로를 실행하거나, 댓글을 추가할 수 있습니다. + 워크플로를 실행하려면 {{< ui >}}Run Workflow{{< /ui >}}를 선택한 다음, 워크플로 브라우저에서 실행할 워크플로를 검색하여 선택하세요. 자세한 내용은 [Workflow Automation을 사용하여 보안 워크플로 자동화][1]를 참조하세요. + 1. 각 탭을 클릭하여 심각도 분포, 관련 로그 및 해당 발견 결과의 타임라인을 확인합니다. + + {{< img src="sensitive_data_scanner/investigate_sensitive_data_issues/datastore_side_panel.png" alt="\"S3 버킷에 Block Public Access가 활성화되어야 함\" 잘못된 구성이 표시된 데이터스토어 발견 결과 사이드 패널" style="width:90%;">}} + +[1]: /ko/security/cloud_security_management/review_remediate/workflows/ + +{{% /tab %}} +{{< /tabs >}} + +## 추가 자료 {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://app.datadoghq.com/sensitive-data-scanner/telemetry \ No newline at end of file diff --git a/hugo/content/ko/security/workload_protection/detect_and_monitor/agent_rules/policy_management.md b/hugo/content/ko/security/workload_protection/detect_and_monitor/agent_rules/policy_management.md new file mode 100644 index 00000000000..e5a2603948f --- /dev/null +++ b/hugo/content/ko/security/workload_protection/detect_and_monitor/agent_rules/policy_management.md @@ -0,0 +1,195 @@ +--- +aliases: +- /ko/security/workload_protection/workload_security_rules/custom_rules +- /ko/security/threats/workload_security_rules/custom_rules +description: Workload Protection 정책을 생성, 배포하고 인프라에 적용할 범위를 지정하며, 사용자 지정 Agent 규칙을 + 작성하세요. +disable_toc: false +title: 정책 관리 +--- +Agent 규칙은 **정책으로 구성**됩니다. 정책은 함께 배포하고, 특정 인프라(호스트, 클러스터 등)에 **적용 범위를 지정**하는 Agent 규칙 집합입니다. + +기본 제공(OOTB) [기본 Agent 규칙][7] 외에도 **사용자 지정 Agent 규칙**을 작성하여 표준 OOTB 규칙만으로는 Datadog에서 표시되지 않는 이벤트를 탐지할 수 있습니다. + +## 정책 {#policies} + +### 정책 생성 {#create-a-policy} + +1. [Policies][3]로 이동합니다. +2. {{< ui >}}New Policy{{< /ui >}}를 클릭합니다. 기존 정책을 열고 {{< ui >}}Actions{{< /ui >}}를 클릭하여 복제할 수도 있습니다. +3. 정책 이름을 입력하고 {{< ui >}}Create{{< /ui >}}를 클릭합니다. + 새 정책이 생성되지만 활성화되거나 배포되지는 않습니다. +4. 정책을 클릭하여 엽니다. +5. {{< ui >}}New Rule{{< /ui >}}에서 정책에 사용자 지정 Agent 규칙을 추가합니다. Agent 규칙을 생성하려면 [사용자 지정 Agent 규칙 생성][14]을 참조하세요. +6. {{< ui >}}Deployed on 0 agents{{< /ui >}} 옆의 {{< ui >}}Edit{{< /ui >}}를 클릭합니다. +7. 정책에 [태그][17]를 추가하여 특정 인프라를 대상으로 지정합니다. +8. 정책을 배포하려면 {{< ui >}}Policy is disabled{{< /ui >}} 옆의 스위치를 켜고 확인합니다. 이는 아래 페이지에 자세히 설명된 [Remote Configuration](#remote-configuration)을 사용합니다. + +### Datadog 관리형 정책을 현재 버전으로 고정 {#pin-a-datadog-managed-policy-to-its-current-version} + +
정책 고정은 Agent 버전 7.71.0 이상에서 지원됩니다. 이전 Agent는 최신 정책 업데이트를 자동으로 계속 수신합니다.
+ +Datadog에서 관리하는 정책이 Datadog에 의해 업데이트되면 인프라에 자동으로 배포됩니다. + +새 정책 버전이 인프라에 배포되는 시점을 제어하려면 정책을 현재 버전으로 고정할 수 있습니다. 정책 버전을 고정하면 Datadog에서 새 정책 버전을 릴리스할 때 정책 업데이트가 자동으로 롤아웃되지 않습니다. + +정책을 고정하려면 다음 단계를 따르세요. + +1. [Policies][3]로 이동합니다. +2. Datadog 관리형 정책을 클릭합니다. +3. {{< ui >}}Version{{< /ui >}}에서 고정 옵션을 클릭합니다. + 인프라에서 7.71.0 미만 버전의 Agent를 실행 중인 경우, 오래된 Agent 경고가 표시됩니다. [Fleet Automation][18]에서 Agent 버전을 조회하고 업그레이드하세요. +4. {{< ui >}}Pin{{< /ui >}}을 클릭합니다. 정책 버전 고정을 해제하려면 고정 옵션을 다시 클릭하세요. + +### 충돌하는 규칙 {#conflicting-rules} + +동일한 호스트에 배포된 두 정책에 상태가 서로 다른 동일한 규칙(활성 및 비활성)이 포함된 경우, 해당 규칙은 활성 상태로 간주됩니다. + +### 태그 적용 {#apply-tags} + +태그는 환경, 클러스터 또는 호스트와 같이 정책이 적용되는 위치를 정의합니다. 정책에 태그를 추가하여 규칙 적용 범위를 인프라의 일부로 제한하세요. + +1. [Agent Configuration][6]으로 이동합니다. +2. 정책을 열고 {{< ui >}}Edit{{< /ui >}}를 클릭합니다. +3. 태그를 입력하고 {{< ui >}}Apply{{< /ui >}}를 클릭합니다. 정책이 활성화되면 태그가 지정한 대상에 정책이 적용됩니다. + +태그를 추가하면 Datadog에서 해당 태그가 지정된 Agent 수와 각 Agent를 실행하는 인프라를 표시합니다. 예: `Tags match 144 agents`. + +## 사용자 지정 Agent 규칙 생성 {#create-a-custom-agent-rule} + +사용자 지정 Agent 규칙을 생성하여 사용자 지정 정책의 일부로 배포할 수 있습니다. 이후 사용자 지정 [탐지 규칙][19]을 정의할 때 사용자 지정 Agent 규칙을 참조하고 표현식 파라미터를 추가합니다. +사용자 지정 Agent 규칙은 기본 정책과 별도의 사용자 지정 정책을 통해 Agent에 배포됩니다. 사용자 지정 정책에는 사용자 지정 Agent 규칙만 포함됩니다. + +1. [Agent Configuration][6]으로 이동합니다. +2. 정책을 생성하거나 기존 정책을 엽니다. +3. 정책을 연 상태에서 {{< ui >}}Actions{{< /ui >}}에서 {{< ui >}}Manual rule creator{{< /ui >}}를 선택하여 Agent 규칙 편집기를 엽니다. 동일한 편집기를 Datadog의 [Agent rules][21] 페이지에서도 사용할 수 있습니다. 대신 {{< ui >}}Assisted rule creator{{< /ui >}} 마법사를 사용하여 Agent 규칙과 위협 탐지 규칙을 함께 설정하려면 [사용자 지정 Agent 및 탐지 규칙 함께 생성][20]을 참조하세요. +4. 규칙의 {{< ui >}}Name{{< /ui >}} 및 {{< ui >}}Description{{< /ui >}}을 입력합니다. +5. {{< ui >}}Expression{{< /ui >}}에서 [Datadog Security Language(SECL)][15]를 사용하여 일치 항목을 정의합니다. +6. (필요시) 규칙이 이벤트와 일치할 때 실행되는 변수 또는 작업을 추가합니다. [변수 및 액션][22]을 참조하세요. +7. {{< ui >}}Create Agent Rule{{< /ui >}}을 클릭합니다. 정책으로 돌아갑니다. + +사용자 지정 Agent 규칙을 생성하면 변경 사항이 다른 보류 중인 규칙 업데이트와 함께 저장됩니다. 변경 사항을 환경에 적용하려면 업데이트된 사용자 지정 정책을 Agent에 배포하세요. + +## 정책 활성화 및 배포 {#enable-and-deploy-policies} + +활성화된 정책은 해당 태그로 식별된 인프라 대상에 규칙을 적용합니다. 정책을 활성화하는 것은 정책을 배포하는 것과 같습니다. + +Datadog UI에서 **Remote Configuration**을 사용하여 정책 태그(모든 호스트 또는 정의된 호스트 하위 집합)로 지정된 호스트에 사용자 지정 정책을 자동으로 배포하거나, 각 호스트의 Agent에 정책을 **수동으로 배포**할 수 있습니다. + +### Remote Configuration {#remote-configuration} + +**Remote Configuration**은 Datadog이 Agent에 정책을 자동으로 전달하는 방식입니다. 이 방식은 서명되고 인증된 정책만 Agent로 푸시하는 보안 메커니즘을 사용합니다. Remote Configuration을 사용하여 정책을 배포하려면 위의 정책 생성 절차를 따르세요. + +#### 배포 전략 {#deployment-strategies} + +Remote Configuration을 사용하여 Agent 규칙이나 정책의 변경 사항을 롤아웃할 때 두 가지 전략 중 하나를 선택할 수 있습니다. 모든 호스트에 즉시 변경 사항을 배포하거나, 관리형 배포를 사용하여 단계별로 배포할 수 있습니다. [Deployments 페이지][23]에서 배포를 모니터링하세요. + +##### 즉시 배포 {#deploy-instantly} + +즉시 배포를 사용하면 업데이트된 정책이 스테이지별 검증 없이 범위 내의 모든 호스트에 동시에 전송됩니다. 일반적으로 몇 분 정도 소요되며, 변경 사항을 모든 곳에 즉시 적용해야 할 때 적합합니다. + +{{< ui >}}Deploy instantly{{< /ui >}}를 선택한 후 {{< ui >}}Update Policy{{< /ui >}}를 클릭하세요. [Deployments 페이지][23]에서 진행 상황을 추적하세요. + +##### 관리형 배포 {#managed-deployment} + +관리형 배포는 변경 사항을 스테이지별로 롤아웃하므로 전체 인프라에 적용하기 전에 일부 호스트에서 변경 사항을 검증할 수 있습니다. + +1. 정책이나 규칙을 편집할 때 {{< ui >}}Start a managed deployment{{< /ui >}}를 선택하세요. 정책이나 규칙이 관리형 배포로 이미 롤아웃된 경우, {{< ui >}}Start from your last deployment{{< /ui >}}를 선택하여 마지막 배포의 파라미터를 재사용하세요. 규칙 변경의 경우, 재사용되는 파라미터는 해당 규칙을 포함하는 정책의 마지막 배포 파라미터입니다. +2. {{< ui >}}Customize deployment roll-out plan{{< /ui >}}에서 배포 범위를 설정한 후 최대 10개의 스테이지를 구성하여 변경 사항을 점진적으로 롤아웃합니다. 각 스테이지는 {{< ui >}}By percentage of hosts in scope{{< /ui >}} 또는 {{< ui >}}By host tags{{< /ui >}}를 기준으로 정의됩니다. +3. {{< ui >}}Set up monitoring and delay time{{< /ui >}}에서 배포 중에 검사할 모니터를 하나 이상 선택합니다. 배포가 진행되는 동안 모니터가 경보를 보내면 롤아웃이 일시 중지됩니다. 그 이후 다음 스테이지로 넘어가기 전에 대기할 지연 시간을 설정하세요. +4. {{< ui >}}Set deployment window{{< /ui >}}에서 배포가 실행될 수 있는 요일, 시간 및 시간대를 설정합니다. 배포가 지정된 시간대를 벗어나면 일시 중지되었다가 다음 실행 시간대에 다시 시작됩니다. +5. (필요시) {{< ui >}}Add a description{{< /ui >}}에서 배포에 관한 설명을 추가합니다. +6. {{< ui >}}Update Policy{{< /ui >}}를 클릭하여 롤아웃을 시작합니다. [Deployments 페이지][23]에서 진행 상황을 추적하세요. + +### 수동 배포{#manual-deployment} + +**수동 배포**의 경우, 각 Agent에 정책 파일을 직접 설치합니다. Datadog UI에서 정책과 해당 규칙을 빌드하고 생성된 파일을 **다운로드**할 수 있습니다. 정책 구문을 이미 알고 있다면 `.policy` 파일을 직접 작성하세요. 그런 다음 아래 설명에 따라 정책이 실행되어야 하는 모든 Agent에 해당 파일을 업로드하거나 동기화하세요. + +1. {{< ui >}}Agent Configuration{{< /ui >}} 페이지에서 정책을 엽니다. +2. Actions에서 {{< ui >}}Download Policy{{< /ui >}}를 선택합니다. + +다음으로, 아래 지침에 따라 각 호스트에 정책 파일을 업로드하세요. + +{{< tabs >}} +{{% tab "호스트" %}} + +`default.policy` 파일을 대상 호스트의 `/etc/datadog-agent/runtime-security.d` 폴더(모든 `.policy` 파일이 저장될 폴더)로 복사하세요. 호스트의 `root` 사용자가 해당 파일에 대한 `read` 및 `write` 권한이 있어야 합니다. + +변경 사항을 적용하려면 다음 중 **하나**를 수행하세요. + +- 런타임 정책을 다시 로드하세요(Agent 전체 재시작 불필요). + + ```bash + sudo /opt/datadog-agent/embedded/bin/system-probe runtime policy reload + ``` + +- [Datadog Agent][27]를 재시작하세요. + +[27]: /ko/agent/configuration/agent-commands/?tab=agentv6v7#restart-the-agent + +{{% /tab %}} + +{{% tab "Helm" %}} + +1. `default.policy`를 포함하는 ConfigMap을 생성합니다(예: `kubectl create configmap jdefaultpol --from-file=default.policy`). +2. `values.yaml`의 `datadog.securityAgent.runtime.policies.configMap` 항목에 ConfigMap(`jdefaultpol`)을 지정합니다. + + ```yaml + securityAgent: + # [...] + runtime: + # datadog.securityAgent.runtime.enabled + # Set to true to enable Security Runtime Module + enabled: true + policies: + # datadog.securityAgent.runtime.policies.configMap + # Place custom policies here + configMap: jdefaultpol + # [...] + ``` + +3. `helm upgrade -f values.yaml --set datadog.apiKey= datadog/datadog`을 사용하여 Helm 차트를 업그레이드합니다. + + **참고:** `default.policy`를 추가로 변경해야 하는 경우 `kubectl edit cm jdefaultpol`을 사용하거나 `kubectl create configmap jdefaultpol --from-file default.policy -o yaml --dry-run=client | kubectl replace -f -`를 사용하여 ConfigMap을 바꿀 수 있습니다. + +{{% /tab %}} +{{< /tabs >}} + +## 기본 Agent 규칙 비활성화 {#disable-default-agent-rules} + +1. Agent 규칙을 비활성화하려면 [{{< ui >}}Agent Configuration{{< /ui >}}][6] 페이지로 이동하여 해당 규칙을 사용하는 정책을 선택합니다. +2. 정책에서 규칙을 엽니다. +3. 상태를 {{< ui >}}Inactive{{< /ui >}}로 설정합니다. +4. {{< ui >}}Save Changes{{< /ui >}}를 클릭합니다. + +[Rules Configuration][21]에서 규칙을 삭제하면 해당 규칙이 포함된 **모든 정책**에서 규칙이 제거됩니다. + +## 사용자 지정 규칙 관리를 위한 RBAC {#rbac-for-custom-rule-management} + +사용자 지정 규칙 RBAC에 사용할 몇 가지 중요한 [역할 및 권한][11]은 다음과 같습니다. + +- `security_monitoring_cws_agent_rules_actions` 권한을 사용하여 규칙에서 차단 모드를 활성화하는 [Automated response][12] 기능을 켜고 구성할 수 있습니다. + - `security_monitoring_cws_agent_rules_actions` 권한을 사용하려면 Datadog Admin 역할을 맡은 사용자가 `security_monitoring_cws_agent_rules_actions` 권한이 포함된 역할을 생성한 후 Automated response를 관리하는 사용자만 해당 역할에 추가해야 합니다. +- {{< ui >}}Datadog Standard{{< /ui >}} 역할은 작업으로 인해 규칙의 **보호** 설정이 변경되지 않는 한 기본적으로 사용자가 사용자 지정 규칙을 생성/업데이트할 수 있도록 허용합니다. + +[3]: https://app.datadoghq.com/security/workload-protection/policies +[4]: https://app.datadoghq.com/security/configuration/agent-rules +[5]: /ko/security/notifications/variables/?tab=cloudsiem +[6]: https://app.datadoghq.com/security/configuration/workload/agent-rules +[7]: /ko/security/workload_protection/detect_and_monitor/agent_rules/#ootb-rules +[8]: /ko/security/workload_protection/ +[9]: /ko/security/cloud_siem/detect_and_monitor/custom_detection_rules/?tab=threshold#set-a-rule-case +[10]: https://app.datadoghq.com/notebook/list?type=runbook +[11]: /ko/account_management/rbac/permissions/ +[12]: /ko/security/workload_protection/respond_and_report/#automated-response +[13]: #disable-default-agent-rules +[14]: #create-a-custom-agent-rule +[15]: /ko/security/workload_protection/detect_and_monitor/agent_rules/secl_guide/ +[16]: #prioritize-policies +[17]: #apply-tags +[18]: https://app.datadoghq.com/fleet +[19]: /ko/security/workload_protection/detect_and_monitor/detection_and_finding_rules/detection_rules +[20]: /ko/security/workload_protection/detect_and_monitor/detection_and_finding_rules/detection_rules/#create-the-custom-agent-and-detection-rules-together +[21]: https://app.datadoghq.com/security/workload-protection/agent-rules +[22]: /ko/security/workload_protection/detect_and_monitor/agent_rules/variables_and_actions +[23]: https://app.datadoghq.com/security/workload-protection/deployments \ No newline at end of file diff --git a/hugo/content/ko/security/workload_protection/detect_and_monitor/detection_and_finding_rules/detection_rules.md b/hugo/content/ko/security/workload_protection/detect_and_monitor/detection_and_finding_rules/detection_rules.md new file mode 100644 index 00000000000..8f872f8c251 --- /dev/null +++ b/hugo/content/ko/security/workload_protection/detect_and_monitor/detection_and_finding_rules/detection_rules.md @@ -0,0 +1,99 @@ +--- +aliases: +- /ko/security/workload_protection/detect_and_monitor/detection_rules +- /ko/security/workload_protection/setup/ootb_rules +description: Agent 이벤트를 분석하고 Workload Protection 보안 신호를 생성하는 백엔드 규칙을 생성하고 관리합니다. +disable_toc: false +title: 탐지 규칙 +--- +탐지 규칙은 [Agent 이벤트][1]를 분석하여 환경 내의 위협을 탐지하는 데 사용되는 백엔드 로직을 설명합니다. 탐지 규칙이 일치하면 Workload Protection은 Datadog에서 조사하고 대응할 수 있는 [보안 신호][2]를 생성합니다. + +탐지 규칙은 하나 이상의 Agent 규칙(`@agent.rule_id`로 참조됨)을 결합하고, 임계값이나 이상 징후와 같은 탐지 방법을 적용하며, 노이즈를 억제하고, 적절한 팀에 경보를 라우팅합니다. Agent 규칙은 호스트에서 런타임 텔레메트리를 수집하며, 탐지 규칙은 해당 텔레메트리를 우선순위가 지정된 위협 탐지로 전환합니다. + +이 페이지에서는 기본 제공(OOTB) 탐지 규칙의 작동 방식과 Datadog에서 사용자 지정 탐지 규칙을 생성하는 방법을 설명합니다. + +## 기본 제공 탐지 규칙 {#ootb-detection-rules} + +Workload Protection에는 Datadog에서 유지 관리하는 기본 제공 **탐지 규칙**이 포함되어 있습니다. 이 규칙들은 Agent 규칙을 통해 수집된 텔레메트리와 백엔드 표현식을 결합하여 활동이 의심스러울 때 보안 신호를 발생시킵니다. [기본 탐지 규칙][3]에서 전체 카탈로그를 찾아보거나 Datadog의 Workload Protection [탐지 규칙][4] 목록에서 검토하고 조정하세요. + +## 사용자 지정 탐지 규칙 생성{#create-a-custom-detection-rule} + +사용자 지정 탐지 규칙을 생성하려면 Workload Protection [탐지 규칙][4] 페이지로 이동하여 {{< ui >}}New Rule{{< /ui >}}을 클릭하세요. {{< ui >}}Assisted rule creator{{< /ui >}}을 사용하여 Agent 규칙과 탐지 규칙을 단일 흐름으로 구성할 수도 있습니다. [사용자 지정 Agent 및 탐지 규칙 함께 생성](#create-the-custom-agent-and-detection-rules-together)을 참조하세요. + +규칙 편집기에서 5단계를 거치게 됩니다. + +### 1단계: 실시간 규칙 정의{#step-1-define-your-real-time-rule} + +사용할 탐지 방법을 선택하세요. + +- {{< ui >}}Threshold{{< /ui >}}: 시간 범위와 신호를 트리거하는 데 필요한 일치 이벤트 수를 정의합니다. 예를 들어, 5분 이내에 5개를 초과하는 일치 이벤트가 발생할 때 트리거합니다. +- {{< ui >}}New value{{< /ui >}}: 이전에 관찰되지 않은 값을 가진 추적된 속성이 나타날 때 트리거합니다. +- {{< ui >}}Anomaly{{< /ui >}}: 이벤트 볼륨이나 동작이 예상 기준선에서 벗어날 때 트리거합니다. +- {{< ui >}}Content anomaly{{< /ui >}}: 일치하는 이벤트의 내용이 과거 데이터와 비교하여 통계적으로 비정상적일 때 트리거합니다. + +### 2단계: 검색 쿼리 정의 {#step-2-define-search-query} + +규칙이 평가할 [Agent 이벤트][1]를 선택하는 쿼리를 정의하세요. 검색 쿼리는 신호를 보낼지 여부를 결정할 때 고려할 이벤트를 결정합니다. + +여기서는 다음을 할 수 있습니다. + +- Agent 이벤트의 **특정 필드**를 필터링하여 쿼리를 구체화하고 탐지 정확도를 높이세요. 예를 들어 `@process.executable.path`, `@file.path` 또는 `@agent.rule_id`를 기준으로 필터링하세요. 탐지 규칙은 백엔드 이벤트 스키마의 모든 필드를 쿼리할 수 있습니다. 사용 가능한 전체 필드 세트는 [Linux 백엔드 구문][13] 및 [Windows 백엔드 구문][14]을 참조하세요. +- 여러 조건을 결합하여 인프라 또는 워크로드의 하위 집합으로 규칙 범위를 제한합니다. + +**임계값** 규칙의 경우, **조회 기간**(Datadog이 규칙 조건과 비교하기 전에 일치하는 이벤트를 집계하는 기간)도 정의하세요. + +[Agent 이벤트 탐색기][6]를 사용하여 쿼리를 테스트하여 규칙을 게시하기 전에 어떤 이벤트가 일치하는지 확인하세요. + +### 3단계: 규칙 조건 정의 {#step-3-define-rule-conditions} + +규칙이 신호를 보낼 시점을 결정하는 제한을 설정하세요. 각각 다른 심각도 수준과 연결된 **여러 케이스**를 생성할 수 있습니다. + +예를 들어, 임계값 규칙으로 다음을 정의할 수 있습니다. + +- {{< ui >}}Critical{{< /ui >}} 5분 이내에 10개를 초과하는 일치 이벤트가 발생할 때. +- {{< ui >}}High{{< /ui >}} 5분 이내에 5개를 초과하는 일치 이벤트가 발생할 때. +- {{< ui >}}Medium{{< /ui >}} 5분 이내에 2개를 초과하는 일치 이벤트가 발생할 때. + +{{< ui >}}Add notify{{< /ui >}} 섹션에서 규칙이 트리거될 때 알림을 받을 대상을 선택적으로 구성하세요. 개별 수신자를 추가하거나 [알림 규칙][7]을 사용하여 여러 탐지 규칙 전반의 경보를 관리할 수 있습니다. + +### 4단계: 플레이북 설명{#step-4-describe-your-playbook} + +[신호 탐색기][2]에서 열 때 나타나는 신호의 **제목** 및 **설명**을 구성하세요. + +1. {{< ui >}}Rule name{{< /ui >}}을 입력합니다. 이 이름은 탐지 규칙 목록에 나타나며 생성된 보안 신호의 제목이 됩니다. +2. {{< ui >}}Rule message{{< /ui >}} 섹션에서 [알림 변수][8]와 Markdown을 사용하여 발생한 상황과 대응자가 취해야 할 조치를 설명하세요. 템플릿 변수는 트리거된 에이전트 이벤트의 동적 컨텍스트를 신호 및 해당 알림에 직접 삽입합니다. +3. {{< ui >}}Tag resulting signals{{< /ui >}} 드롭다운 메뉴를 사용하여 생성된 신호에 태그를 추가하세요. 예를 들어, `security:attack` 또는 `technique:T1059-command-and-scripting-interpreter`. + +### 5단계: 차단 규칙 만들기{#step-5-create-a-suppression} + +선택적으로 **차단 쿼리**를 추가하여 특정 인프라나 이벤트를 이 규칙에서 제외함으로써 노이즈를 줄일 수 있습니다. 차단은 일치하는 활동이 예상되거나 무해할 때 신호가 생성되지 않도록 방지하는 데 도움이 됩니다. + +예를 들어, 알려진 자동화 사용자를 규칙에서 제외하려면 `@usr.name:automation-bot`과 같은 차단 쿼리를 추가하세요. + +이 단계에서는 과거의 **일치 이벤트 수에 대한 개요**도 제공하므로, 규칙을 저장하기 전에 규칙이 얼마나 자주 트리거되었을지 추정할 수 있습니다. 이 미리 보기를 사용하여 쿼리, 임계값 또는 차단을 조정하고 과도한 경보 볼륨을 방지하세요. + +탐지 규칙 전반의 차단에 대한 자세한 내용은 [차단][9]을 참조하세요. + +## 사용자 지정 에이전트 및 탐지 규칙 함께 만들기 {#create-the-custom-agent-and-detection-rules-together} + +기본 에이전트 규칙이 정책에 패키징되고 배포되는 방법에 대한 자세한 내용은 [에이전트 규칙][10] 개요 및 [정책 관리][11]를 참조하세요. + +다음 방법 중 하나로 일치하는 에이전트 규칙과 탐지 규칙을 정의할 수 있습니다. + +- {{< ui >}}Assisted rule creator{{< /ui >}}: Datadog에서 사용자 지정 Workload Protection [탐지 규칙][4]을 시작하고 마법사를 사용하여 에이전트 표현식과 백엔드 탐지 규칙 로직을 모두 구성하세요. +- {{< ui >}}Manual rule creator{{< /ui >}}: [에이전트 구성][12]에서 정책을 열거나 생성하고 {{< ui >}}Manual rule creator{{< /ui >}}를 선택하여 에이전트 규칙을 먼저 작성한 다음, 이를 참조하는 탐지 규칙을 추가하세요. UI 단계 및 배포에 대해서는 [정책 관리][11]를 참조하세요. + +[1]: /ko/security/workload_protection/investigate_and_triage/agent_events +[2]: /ko/security/workload_protection/investigate_and_triage/security_signals +[3]: /ko/security/default_rules/#cat-workload-security +[4]: https://app.datadoghq.com/security/configuration/rules?product=cws +[5]: /ko/security/workload_protection/respond_and_report/#automated-response +[6]: https://app.datadoghq.com/security/agent-events +[7]: /ko/security/notifications/rules/ +[8]: /ko/security/notifications/variables/ +[9]: /ko/security/suppressions/ +[10]: /ko/security/workload_protection/detect_and_monitor/agent_rules +[11]: /ko/security/workload_protection/detect_and_monitor/agent_rules/policy_management#create-a-custom-agent-rule +[12]: https://app.datadoghq.com/security/configuration/workload/agent-rules +[13]: /ko/security/workload_protection/backend_linux +[14]: /ko/security/workload_protection/backend_windows \ No newline at end of file diff --git a/hugo/content/ko/security/workload_protection/setup/kubernetes.md b/hugo/content/ko/security/workload_protection/setup/kubernetes.md new file mode 100644 index 00000000000..0bc2a259feb --- /dev/null +++ b/hugo/content/ko/security/workload_protection/setup/kubernetes.md @@ -0,0 +1,190 @@ +--- +aliases: +- /ko/security/workload_protection/setup/agent/kubernetes +description: Kubernetes에서 Datadog Operator, Helm 또는 DaemonSet을 사용하여 Workload Protection을 + 활성화하세요. +disable_toc: false +title: Kubernetes에서 Workload Protection 설정 +--- +다음 지침을 따라 Workload Protection을 활성화하세요. + +
Fargate 컴퓨팅 옵션이 구성된 Amazon EKS에 Workload Protection을 배포하려면 Fargate 배포 페이지를 참조하세요.
+ +{{< partial name="security-platform/WP-billing-note.html" >}} + +## 전제 조건 {#prerequisites} + +- 최신 Datadog Agent 버전. 설치 지침은 [Agent 시작하기][5]를 참조하거나 [Datadog UI][6]에서 Agent를 설치하세요. + +**참고**: SBOM 수집은 Google Kubernetes Engine(GKE)의 이미지 스트리밍 기능과 호환되지 않습니다. 비활성화하려면 GKE 설명서의 [이미지 스트리밍 비활성화][7] 섹션을 참조하세요. + +## 설치 {#installation} + +{{< tabs >}} + +{{% tab "Datadog Operator" %}} + +1. `datadog-agent.yaml` 파일의 `spec` 섹션에 다음을 추가합니다. + + ```yaml + # datadog-agent.yaml file + apiVersion: datadoghq.com/v2alpha1 + kind: DatadogAgent + metadata: + name: datadog + spec: + features: + # (Optional) Integrate with Kubernetes to enrich Workload Protection events with Kubernetes user identities + admissionController: + enabled: true + cwsInstrumentation: + enabled: true + + remoteConfiguration: + enabled: true + # Enables Threat Detection + cws: + enabled: true + # Enables Misconfigurations + cspm: + enabled: true + hostBenchmarks: + enabled: true + # Enables the image metadata collection and Software Bill of Materials (SBOM) collection + sbom: + enabled: true + # Enables Container Vulnerability Management + # Image collection is enabled by default with Datadog Operator version `>= 1.3.0` + containerImage: + enabled: true + + # Uncomment the following line if you are using Google Kubernetes Engine (GKE) or Amazon Elastic Kubernetes (EKS) + # uncompressedLayersSupport: true + + # Enables Host Vulnerability Management + host: + enabled: true + ``` + +2. 변경 사항을 적용하고 Agent를 재시작합니다. + +[2]: https://github.com/DataDog/datadog-operator/blob/main/docs/configuration.v2alpha1.md + +{{% /tab %}} + +{{% tab "Helm" %}} + +1. `datadog-values.yaml` 파일의 `datadog` 섹션에 다음을 추가합니다. + + ```yaml + # datadog-values.yaml file + + # (Optional) Integrate with Kubernetes to enrich Workload Protection events with Kubernetes user identities + clusterAgent: + admissionController: + enabled: true + cwsInstrumentation: + enabled: true + + datadog: + remoteConfiguration: + enabled: true + securityAgent: + # Enables Threat Detection + runtime: + enabled: true + # Enables Misconfigurations + compliance: + enabled: true + host_benchmarks: + enabled: true + sbom: + containerImage: + enabled: true + + # Uncomment the following line if you are using Google Kubernetes Engine (GKE) or Amazon Elastic Kubernetes (EKS) + # uncompressedLayersSupport: true + + # Enables Host Vulnerability Management + host: + enabled: true + + # Enables Container Vulnerability Management + # Image collection is enabled by default with Datadog Helm version `>= 3.46.0` + # containerImageCollection: + # enabled: true + ``` + +2. Agent를 재시작합니다. + +RBAC 문제를 해결하려면 `clusterRole.allowCreatePodsExec` 옵션을 활성화한 상태로 `clusterRole`에 대해 차트를 실행하세요. + +```sh +helm install datadog-operator datadog/datadog-operator --set clusterRole.allowCreatePodsExec=true +``` + +{{% /tab %}} + +{{% tab "DaemonSet" %}} + +1. `daemonset.yaml`파일에서 `security-agent` 및 `system-probe`의 `env` 섹션에 다음 설정을 추가하세요. Workload Protection 이벤트를 Kubernetes 사용자 ID로 보강하려면 `cluster-agent-deployment.yaml`에서 선택 사항인 `DD_ADMISSION_CONTROLLER_ENABLED` 및 `DD_RUNTIME_ADMISSION_CONTROLLER_CWS_INSTRUMENTATION_ENABLED` 변수를 추가로 설정하세요. + + ```bash + # Source: datadog/templates/daemonset.yaml + apiVersion:app/1 + kind: DaemonSet + [...] + spec: + [...] + spec: + [...] + containers: + [...] + - name: agent + [...] + env: + - name: DD_REMOTE_CONFIGURATION_ENABLED + value: "true" + - name: system-probe + [...] + env: + - name: DD_RUNTIME_SECURITY_CONFIG_ENABLED + value: "true" + - name: DD_RUNTIME_SECURITY_CONFIG_REMOTE_CONFIGURATION_ENABLED + value: "true" + - name: DD_COMPLIANCE_CONFIG_ENABLED + value: "true" + - name: DD_COMPLIANCE_CONFIG_HOST_BENCHMARKS_ENABLED + value: "true" + - name: DD_SBOM_CONTAINER_IMAGE_USE_MOUNT + value: "true" + [...] + + # Source: datadog/templates/cluster-agent-deployment.yaml + apiVersion:app/1 + kind: Deployment + [...] + spec: + [...] + template: + [...] + spec: + [...] + containers: + [...] + - name: cluster-agent + [...] + env: + - name: DD_ADMISSION_CONTROLLER_ENABLED + value: "true" + - name: DD_RUNTIME_ADMISSION_CONTROLLER_CWS_INSTRUMENTATION_ENABLED + value: "true" + ``` + +{{% /tab %}} +{{< /tabs >}} + + +[5]: /ko/getting_started/agent +[6]: https://app.datadoghq.com/account/settings/agent/latest +[7]: https://cloud.google.com/kubernetes-engine/docs/how-to/image-streaming#disable \ No newline at end of file diff --git a/hugo/content/ko/tracing/guide/ingestion_sampling_use_cases.md b/hugo/content/ko/tracing/guide/ingestion_sampling_use_cases.md index ada71f5ce63..f714e548703 100644 --- a/hugo/content/ko/tracing/guide/ingestion_sampling_use_cases.md +++ b/hugo/content/ko/tracing/guide/ingestion_sampling_use_cases.md @@ -1,85 +1,91 @@ --- +description: 문제 해결 기능을 유지하면서 수집 볼륨을 최적화하기 위한 다양한 트레이스 샘플링 사용 사례와 전략을 살펴보세요. further_reading: - link: /tracing/guide/trace_ingestion_volume_control/ - tag: 지침 + tag: 가이드 text: 수집된 볼륨을 제어하는 방법 +- link: https://www.datadoghq.com/architecture/mastering-distributed-tracing-data-volume-challenges-and-datadogs-approach-to-efficient-sampling/ + tag: 아키텍처 센터 + text: '분산 트레이스 마스터하기: 데이터 볼륨 문제와 효율적인 샘플링을 위한 Datadog의 접근 방식' +- link: https://www.datadoghq.com/architecture/optimizing-distributed-tracing-best-practices-for-remaining-within-budget-and-capturing-critical-traces/ + tag: 아키텍처 센터 + text: '분산 트레이스 최적화: 예산 범위 내에서 중요 트레이스를 캡처하기 위한 모범 사례' title: 트레이스 샘플링 사용 사례 --- +## 개요 {#overview} -## 개요 +트레이스 데이터는 반복되는 경향이 있습니다. 애플리케이션의 문제는 단일한 트레이스에서만 식별되는 경우가 거의 없습니다. 처리량이 많은 서비스의 경우, 특히 주의가 필요한 인시던트에서는 문제가 여러 트레이스에서 반복적으로 나타납니다. 결과적으로 서비스나 엔드포인트의 모든 트레이스 또는 트레이스 내의 모든 스팬을 수집할 필요는 없습니다. Datadog APM [수집 제어 메커니즘][1]은 노이즈를 줄이고 비용을 관리하면서 문제를 해결하는 데 필요한 가시성을 유지하도록 돕습니다. -트레이스 데이터는 반복적인 경향이 있습니다. 애플리케이션의 문제가 트레이스 한 곳에서만 확인되고 다른 곳에서는 확인되지 않는 경우는 거의 없습니다. 처리량이 많은 서비스, 특히 주의가 필요한 인시던트의 경우, 한 문제가 여러 추적에서 반복적으로 증상을 보이는 경우가 많습니다. 따라서 일반적으로 서비스나 엔드포인트의 모든 트레이스 내의 모든 스팬을 수집할 필요가 없습니다. Datadog APM의 [수집 제어 메커니즘][1]은 문제 해결에 필요한 가시성을 유지하면서 소음을 줄이고 비용을 관리할 수 있도록 도와줍니다. +수집 메커니즘은 Datadog Agent 및 Datadog SDK 내의 구성입니다. OpenTelemetry SDK를 사용하여 애플리케이션을 계측하는 경우 [OpenTelemetry를 사용한 수집 샘플링][2]을 읽어보세요. -수집 메커니즘은 추적 라이브러리의 Datadog Agent 및 Datadog 추적 라이브러리 내에서 구성됩니다. 애플리케이션을 계측하기 위해 OpenTelemetry SDK를 사용하는 경우 [OpenTelemetry를 사용한 수집 샘플링][2]을 참조하세요. +이 가이드는 주요 사용 사례에 따른 수집 제어 설정 사용 시점과 방법을 이해할 수 있도록 지원합니다. 가이드에서 다루는 내용은 다음과 같습니다. -이 가이드는 주요 사용 사례에 따른 수집 제어 설정 사용 시점과 방법을 이해할 수 있도록 지원합니다. 가이드에서는 다음을 다룹니다. - -- 특정 서비스에 [어떤 수집 메커니즘이 사용되는지 결정하기](#determining-which-ingestion-mechanisms-are-used) -- [특정 유형의 트레이스 유지에 중점을 둔 사용 사례](#keeping-certain-types-of-traces) +- [특정 서비스에서 사용 중인 수집 메커니즘 파악하기](#determining-which-ingestion-mechanisms-are-used) +- [특정 유형의 트레이스를 유지하는 데 중점을 둔 사용 사례](#keeping-certain-types-of-traces) - [수집된 트레이스를 줄이는 데 중점을 둔 사용 사례](#reducing-ingestion-for-high-volume-services) -## 사용할 수집 메커니즘 결정하기 +## 사용 중인 수집 메커니즘 파악하기 {#determining-which-ingestion-mechanisms-are-used} -Datadog 환경에서 현재 어떤 수집 메커니즘이 사용되고 있는지 확인하려면 [수집 제어 페이지][3]로 이동하세요. +Datadog 환경에서 현재 어떤 수집 메커니즘이 사용되고 있는지 확인하려면 [Ingestion Control 페이지][3]로 이동하세요. -{{< img src="/tracing/guide/ingestion_sampling_use_cases/ingestion_control_page.png" alt="Ingestion Control Page" style="width:90%;" >}} +{{< img src="/tracing/guide/ingestion_sampling_use_cases/ingestion_control_page.png" alt="Ingestion Control 페이지" style="width:90%;" >}} -이 표는 수집된 볼륨에 대한 *서비스별* 인사이트를 제공합니다. 설정 열은 현재 설정에 일차적인 표시를 제공합니다. 다음이 표시됩니다. -- `AUTOMATIC` Datadog Agent에서 계산된 샘플링 속도가 서비스에서 시작되는 추적에 적용되는 경우. 자세한 내용은 [Datadog Agent 수집 로직][5]을 참조하세요. -- `CONFIGURED` 트레이스 라이브러리에서 설정된 사용자 지정 트레이스 샘플링 속도가 서비스에서 시작하는 추적에 적용되는 경우입니다. +이 표는 *서비스별* 수집 볼륨에 대한 통찰력을 제공합니다. Configuration 열은 현재 설정에 대한 초기 정보를 제공합니다. 다음을 표시합니다. +- `AUTOMATIC`: Datadog Agent에서 계산된 샘플링 비율이 서비스에서 시작하는 트레이스에 적용되는 경우. [Datadog Agent 수집 로직][5]의 세부 정보에 대해 자세히 알아보세요. +- `CONFIGURED`: SDK에서 구성된 사용자 지정 트레이스 샘플링 비율이 서비스에서 시작하는 추적에 적용되는 경우. -서비스를 클릭하면 각 서비스에 사용되는 샘플링 의사 결정자(예: Agent 또는 트레이스 라이브러리, 규칙 또는 샘플 속도)와 수집된 범위의 서비스에 어떤 [수집 샘플링 메커니즘][1]이 활용되는지에 대한 세부 정보를 확인할 수 있습니다. +서비스를 클릭하면 각 서비스에 사용되는 샘플링 의사 결정자(예: Agent 또는 SDK, 규칙 또는 샘플링 비율)와 수집된 스팬의 서비스에 활용되는 [수집 샘플링 메커니즘][1]에 대한 세부 정보를 확인할 수 있습니다. {{< img src="/tracing/guide/ingestion_sampling_use_cases/service-ingestion-summary.png" alt="서비스 수집 요약" style="width:90%;" >}} -위의 서비스 수집 요약 예시에서 **수집 이유 분석** 표를 보면 이 서비스의 수집 이유 대부분이 `rule`([사용자 정의 샘플링 규칙][6])에서 비롯된 것임을 알 수 있습니다. +위의 서비스 수집 요약 예시에서 {{< ui >}}Ingestion reasons breakdown{{< /ui >}} 표를 통해 이 서비스의 수집 이유 대부분이 `rule`([사용자 정의 샘플링 규칙][6])에서 비롯된 것임을 확인할 수 있습니다. -이 서비스의 상위 샘플링 의사 결정권자는 `web-store` 서비스가 `web-store`, `shopist-web-ui`, `shipping-worker`, `synthetics-browser`, `product-recommendation`에서 샘플링 결정을 내리는 것으로 나타났습니다. 이 다섯 가지 서비스는 모두 `web-store` 서비스 범위에 영향을 미치는 전체 샘플링 결정에 기여합니다. 웹 스토어에 수집을 미세 조정하는 방법을 결정할 때는 다섯 가지 서비스를 모두 고려해야 합니다. +이 서비스의 상위 샘플링 의사 결정자를 보면 `web-store` 서비스가 `web-store`, `shopist-web-ui`, `shipping-worker`, `synthetics-browser` 및 `product-recommendation`으로부터 샘플링 결정을 받음을 알 수 있습니다. 이 5개 서비스 모두 `web-store` 서비스 스팬에 영향을 미치는 전반적인 샘플링 결정에 기여합니다. web-store에 대한 수집을 미세 조정하는 방법을 결정할 때는 5개 서비스를 모두 고려해야 합니다. -## 특정 유형의 트레이스 유지 +## 특정 유형의 트레이스 유지하기 {#keeping-certain-types-of-traces} -### 전체 거래 트레이스 유지 +### 전체 트랜잭션 트레이스 유지하기 {#keeping-entire-transaction-traces} -전체 트랜잭션 추적을 수집하면 특정 개별 요청에 **엔드투엔드 서비스 요청 흐름**에 관한 가시성을 확보할 수 있습니다. +전체 트랜잭션 트레이스를 수집하면 특정 개별 요청에 대한 **종합 서비스 요청 흐름**에 관한 가시성을 확보할 수 있습니다. -#### 솔루션: 헤드 기반 샘플링 +#### 솔루션: 헤드 기반 샘플링 {#solution-head-based-sampling} -[헤드 기반 샘플링][4] 메커니즘으로 완전한 트레이스를 수집할 수 있습니다. 트레이스를 유지할지 삭제할지 여부는 트레이스가 생성될 때 트레이스 첫 번째 스팬인 *헤드*에서 결정됩니다. 이 결정은 요청 컨텍스트를 통해 다운스트림 서비스로 전파됩니다. +[헤드 기반 샘플링][4] 메커니즘으로 완전한 트레이스를 수집할 수 있습니다. 트레이스를 유지할지 드롭할지 여부는 트레이스가 생성될 때 트레이스의 첫 번째 스팬인 *head*에서 결정됩니다. 이 결정은 요청 컨텍스트를 통해 다운스트림 서비스로 전파됩니다. {{< img src="/tracing/guide/ingestion_sampling_use_cases/head-based-sampling.png" alt="헤드 기반 샘플링" style="width:100%;" >}} -유지 및 삭제할 트레이스를 결정하기 위해 Datadog Agent에서는 애플리케이션 트래픽을 기반으로 트레이스 생성 시 적용할 각 서비스의 [기본 샘플링 속도][5]를 계산합니다. -- 트래픽이 적은 애플리케이션의 경우 샘플링 속도 100%가 적용됩니다. -- 트래픽이 많은 애플리케이션의 경우, 더 낮은 샘플링 속도가 적용되는데, 각 Agent에서 초당 10개의 완전한 트레이스를 목표로 합니다. +유지 및 드롭할 트레이스를 결정하기 위해 Datadog Agent에서는 애플리케이션 트래픽을 기반으로 트레이스 생성 시 적용할 각 서비스의 [기본 샘플링 비율][5]를 계산합니다. +- 트래픽이 적은 애플리케이션의 경우 샘플링 비율 100%가 적용됩니다. +- 트래픽이 많은 애플리케이션의 경우, 더 낮은 샘플링 비율이 적용되는데, 각 Agent에서 초당 10개의 완전한 트레이스를 목표로 합니다. -서비스별 샘플링 속도를 구성하여 기본값 Agent 샘플링 속도를 재정의할 수도 있습니다. 자세한 내용은 [특정 서비스에 더 많은 추적 유지](#keeping-more-traces-for-specific-services-or-resources) 도움말을 참조하세요. +서비스별로 샘플링 비율을 구성하여 기본 Agent 샘플링 비율을 재정의할 수도 있습니다. 자세한 내용은 [특정 서비스에 대해 더 많은 트레이스를 유지](#keeping-more-traces-for-specific-services-or-resources)하는 방법을 참조하세요. -#### 헤드 기반 샘플링 구성 +#### 헤드 기반 샘플링 구성하기 {#configuring-head-based-sampling} -기본 샘플링 속도는 Agent에 따라 초당 10개의 완전한 트레이스를 목표로 계산됩니다. 이는 *목표* 트레이스 수이며 일정 기간의 트레이스를 평균한 결과입니다. 이는 하드 제한이 *아닙니다*. 트래픽이 급증하면 단기간에 Datadog로 훨씬 더 많은 트레이스가 전송될 수 있습니다. +기본 샘플링 비율은 Agent당 초당 10개의 완전한 트레이스를 목표로 계산됩니다. 이는 *목표* 트레이스 수이며 일정 기간 동안의 트레이스 평균 결과입니다. 엄격한 제한이 *아니며*, 트래픽 급증으로 인해 짧은 기간 동안 Datadog으로 훨씬 더 많은 트레이스가 전송될 수 있습니다. -Datadog Agent 파라미터 `max_traces_per_second` 또는 환경 변수 `DD_APM_MAX_TPS`를 구성하여 이 목표를 늘리거나 줄일 수 있습니다. [헤드 기반 샘플링 수집 메커니즘][5]에서 자세히 알아보세요. +Datadog Agent 파라미터 `target_traces_per_second` 또는 환경 변수 `DD_APM_TARGET_TPS`를 구성하여 이 목표치를 늘리거나 줄일 수 있습니다. [헤드 기반 샘플링 수집 메커니즘][5]에 대해 자세히 알아보세요. -**참고:** Agent 설정을 변경하면 Datadog Agent에 트레이스를 보고하는 *모든 서비스*의 샘플링 비율에 영향을 미칩니다. +**참고:** Agent 구성을 변경하면 Datadog Agent에 트레이스를 보고하는 *모든 서비스*의 샘플링 비율에 영향을 미칩니다. 대부분의 시나리오에서 이 Agent 수준 설정은 할당된 할당량 내에서 애플리케이션 성능에 충분한 가시성을 제공하고 비즈니스에 적합한 의사 결정을 내리는 데 도움이 됩니다. -### 특정 서비스 또는 리소스에 더 많은 트레이스 유지 +### 특정 서비스 또는 리소스의 더 많은 트레이스 유지하기 {#keeping-more-traces-for-specific-services-or-resources} -일부 서비스 및 요청이 비즈니스에 중요한 경우, 이에 관한 가시성을 높이고 싶어 합니다. 모든 관련 추적을 Datadog 으로 보내 개별 트랜잭션을 살펴볼 수 있도록 하세요. +일부 서비스와 요청이 비즈니스에 중요한 경우 해당 서비스와 요청에 대한 가시성을 높여야 합니다. 개별 트랜잭션을 조사할 수 있도록 관련 트레이스를 모두 Datadog으로 보내야 할 수도 있습니다. -#### 솔루션: 샘플링 규칙 +#### 솔루션: 샘플링 규칙 {#solution-sampling-rules} -기본적으로 샘플링 속도는 Datadog Agent당 초당 10개의 트레이스를 목표로 계산됩니다. 추적 라이브러리에서 [샘플링 규칙][6]을 구성하여 기본 계산된 샘플링 속도를 재정의할 수 있습니다. +기본적으로 샘플링 비율은 Datadog Agent당 초당 10개의 트레이스를 목표로 계산됩니다. SDK에서 [샘플링 규칙][6]을 구성하여 기본적으로 계산된 샘플링 비율을 재정의할 수 있습니다. -서비스별로 샘플링 규칙을 설정할 수 있습니다. 규칙의 특정 서비스에서 시작하는 트레이스의 경우 Agent의 기본 샘플링 속도 대신 정의된 백분율 샘플링 속도가 적용됩니다. +서비스별로 샘플링 규칙을 설정할 수 있습니다. 규칙의 특정 서비스에서 시작하는 트레이스의 경우 Agent의 기본 샘플링 비율 대신 정의된 백분율 샘플링 비율이 적용됩니다. -#### 샘플링 규칙 설정하기 +#### 샘플링 규칙 구성하기 {#configuring-a-sampling-rule} 환경 변수 `DD_TRACE_SAMPLING_RULES`를 설정하여 샘플링 규칙을 구성할 수 있습니다. -예를 들어 서비스 `my-service` 에 관해 트레이스의 20%를 보내는 방법: +예를 들어, `my-service`라는 이름이 지정된 서비스에 대해 트레이스의 20%를 보내는 경우: ``` DD_TRACE_SAMPLING_RULES='[{"service": "my-service", "sample_rate": 0.2}]' @@ -87,66 +93,66 @@ DD_TRACE_SAMPLING_RULES='[{"service": "my-service", "sample_rate": 0.2}]' [샘플링 규칙 수집 메커니즘][6]에 관해 자세히 알아보세요. -### 오류 관련 트레이스 더 많이 유지 +### 오류 관련 트레이스 더 많이 유지하기 {#keeping-more-error-related-traces} 오류 스팬이 있는 트레이스는 시스템 장애 증상인 경우가 많습니다. 오류가 있는 트랜잭션의 비율을 높게 유지하면 항상 관련 개별 요청에 액세스할 수 있습니다. -#### 솔루션: 오류 샘플링 속도 +#### 솔루션: 오류 샘플링 비율 {#solution-error-sampling-rate} -헤드 기반 샘플링된 트레이스 외에도 오류 샘플링 속도를 높여 각 Agent가 관련 트레이스가 헤드 기반 샘플링으로 유지되지 않더라도 추가 오류 스팬을 유지할 수 있도록 합니다. +헤드 기반 샘플링된 트레이스 외에도 오류 샘플링 비율을 높여 각 Agent가 관련 트레이스가 헤드 기반 샘플링으로 유지되지 않더라도 추가 오류 스팬을 유지할 수 있도록 합니다. -{{< img src="/tracing/guide/ingestion_sampling_use_cases/error-spans-sampling.png" alt="Error Sampling" style="width:100%;" >}} +{{< img src="/tracing/guide/ingestion_sampling_use_cases/error-spans-sampling.png" alt="오류 샘플링" style="width:100%;" >}} -**참조**: +**참고:** - 샘플링이 Datadog Agent 수준에서 로컬로 이루어지므로 분산된 트레이스 조각은 수집되지 않을 수 있습니다. -- **Datadog Agent 6/7.41.0 이상**부터 `DD_APM_FEATURES=error_rare_sample_tracer_drop`은 트레이스 라이브러리 규칙 또는 `manual.drop`에 의해 삭제된 스팬을 포함하도록 설정할 수 있습니다. 자세한 내용은 [수집 메커니즘 설명서의 오류 추적 섹션][9]에서 확인할 수 있습니다. +- **Datadog Agent 6/7.41.0 이상 및 그 이후 버전**부터는 `DD_APM_FEATURES=error_rare_sample_tracer_drop`를 SDK 규칙 또는 `manual.drop`으로 삭제된 스팬을 포함하도록 설정할 수 있습니다. 자세한 내용은 [수집 메커니즘 설명서의 오류 트레이스 섹션][9]에서 확인하세요. -#### 오류 샘플링 구성 +#### 오류 샘플링 구성하기 {#configuring-error-sampling} -환경 변수 `DD_APM_ERROR_TPS`를 구성하여 캡처할 Agent당 초당 오류 조각 수를 구성할 수 있습니다. 기본값은 초당 `10` 오류 수입니다. **모든 오류**를 수집하려면 임의의 높은 값으로 설정하세요. 오류 샘플링을 사용하지 않으려면 `DD_APM_ERROR_TPS`를 `0`로 설정합니다. +환경 변수 `DD_APM_ERROR_TPS`를 설정하여 Agent당 초당 캡처할 오류 청크 수를 구성할 수 있습니다. 기본값은 초당 `10`개의 오류입니다. **모든 오류**를 수집하려면 임의의 높은 값으로 설정하세요. 오류 샘플링을 비활성화하려면 `DD_APM_ERROR_TPS`를 `0`으로 설정하세요. -## 대용량 서비스의 수집량 줄이기 +## 대용량 서비스의 수집량 줄이기 {#reducing-ingestion-for-high-volume-services} -### 데이터베이스 또는 캐시 서비스에서 볼륨 줄이기 +### 데이터베이스 또는 캐시 서비스에서 볼륨 줄이기 {#reducing-volume-from-database-or-cache-services} -추적되는 데이터베이스 호출의 경우 수집 데이터 양이 대량일 수 있습니다. 그러나 애플리케이션 성능 메트릭(예: 오류 수, 요청 히트 수, 지연 시간)은 데이터베이스 상태를 확인할 수 있는 정도입니다. +추적되는 데이터베이스 호출의 경우 수집 데이터 양이 대량일 수 있습니다. 그러나 애플리케이션 성능 메트릭(예: 오류 수, 요청 히트 수, 지연 시간)은 데이터베이스 상태를 모니터링할 수 있는 정도입니다. -#### 솔루션: 데이터베이스 호출을 사용한 트레이스 샘플링 규칙 +#### 솔루션: 데이터베이스 호출을 사용한 트레이스 샘플링 규칙 {#solution-sampling-rules-for-traces-with-database-calls} 데이터베이스 호출을 추적하여 생성된 스팬 볼륨을 줄이려면 트레이스의 헤드에서 샘플링을 설정합니다. -데이터베이스 서비스는 트레이스를 시작하는 일이 거의 없습니다. 일반적으로 클라이언트 데이터베이스 범위는 계측된 백엔드 서비스 스팬의 하위 서비스입니다. +데이터베이스 서비스는 트레이스를 시작하는 일이 거의 없습니다. 일반적으로 클라이언트 데이터베이스 스팬은 계측된 백엔드 서비스 스팬의 하위 스팬입니다. -**데이터베이스 트레이스를 시작하는 서비스**를 파악하려면, 수집 제어 페이지 [서비스 수집 요약][7]의 `Top Sampling Decision Makers` 상위 목록 그래프를 사용하세요. 이러한 특정 서비스에 헤드 기반 샘플링을 설정하면 수집되는 데이터베이스 스팬의 양을 줄이면서 불완전한 트레이스가 수집되지 않도록 할 수 있습니다. 분산된 트레이스는 유지되거나 모두 삭제됩니다. +**어떤 서비스가 데이터베이스 트레이스를 시작하는지** 확인하려면, Ingestion Control 페이지 [서비스 수집 요약][7]의 `Top Sampling Decision Makers` 상위 목록 그래프를 사용하세요. 이러한 특정 서비스에 대해 헤드 기반 샘플링을 구성하면 데이터베이스 스팬의 수집량을 줄이면서, 불완전한 트레이스가 수집되지 않도록 할 수 있습니다. 분산 트레이스는 전부 유지하거나 전부 드롭됩니다. -{{< img src="/tracing/guide/ingestion_sampling_use_cases/service-ingestion-summary-database.png" alt="상위 샘플링 의사 결정자" style="width:90%;" >}} +{{< 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` 서비스의 샘플링을 설정합니다. +예를 들어, `web-store-mongo`의 트레이스가 적용된 데이터베이스 호출의 경우 트레이스는 99%의 확률로 `web-store` 및 `shipping-worker` 서비스에서 시작됩니다. 결과적으로 `web-store-mongo`의 수집량을 줄이려면 `web-store` 및 `shipping-worker` 서비스에 대한 샘플링을 구성하세요. -#### 데이터베이스 스팬을 삭제하도록 샘플링 설정 +#### 데이터베이스 스팬을 삭제하도록 샘플링 구성하기 {#configure-sampling-to-drop-database-spans} -샘플링 규칙 구문에 관한 자세한 내용은 [샘플링 규칙 설정 섹션](#configuring-a-sampling-rule)을 참조하세요. +샘플링 규칙 구문에 대한 자세한 내용은 [샘플링 규칙 구성 섹션](#configuring-a-sampling-rule)을 참조하세요. -백엔드 서비스 `web-store`는 트레이스당 여러 번 Mongo 데이터베이스를 호출하며, 원치 않는 스팬 볼륨을 많이 생성하고 있습니다. +백엔드 서비스 `web-store`는 트레이스당 여러 번 Mongo 데이터베이스를 호출하며, 원치 않는 스팬 볼륨을 생성하고 있습니다. -- 백엔드 서비스 `web-store`에 **트레이스 샘플링 규칙**을 설정하여 Mongo 스팬을 포함하여 전체 트레이스의 10%가 유지되도록 합니다. +- 백엔드 서비스 `web-store`에 **트레이스 샘플링 규칙**을 구성하여 Mongo 스팬을 포함한 전체 트레이스 중 10%가 유지되도록 합니다. ``` DD_TRACE_SAMPLING_RULES='[{"service": "web-store", "sample_rate": 0.1}]' ``` -- 선택적으로 모든 `web-store` 스팬을 유지하려면 백엔드 서비스 `web-store`에 스팬의 100%를 유지하도록 **단일 스팬 샘플링 규칙**을 설정합니다. 이 샘플링은 위에서 파악한 10% 이외의 데이터베이스 호출 스팬을 수집하지 않습니다. +- 필요한 경우 모든 `web-store` 스팬을 유지하려면, 백엔드 서비스 `web-store`의 스팬을 100% 유지하도록 **단일 스팬 샘플링 규칙**을 구성하세요. 이 샘플링은 위에서 식별된 10% 이외의 데이터베이스 호출 스팬을 수집하지 않습니다. ``` DD_SPAN_SAMPLING_RULES='[{"service": "web-store", "sample_rate": 1}]' ``` - **참고**: 단일 스팬 샘플링 규칙을 설정하는 것은 수집된 스팬에서 파생된 [스팬 기반 메트릭][8]을 사용하는 경우에 특히 유용합니다. + **참고**: 단일 스팬 샘플링 규칙을 설정하는 것은 수집된 스팬을 기반으로 하는 [스팬 기반 메트릭][8]을 사용하는 경우에 특히 유용합니다. {{< img src="/tracing/guide/ingestion_sampling_use_cases/single-span-sampling3.png" alt="데이터베이스 스팬 샘플링" style="width:100%;" >}} -## 참고 자료 +## 추가 자료 {#further-reading} {{< partial name="whats-next/whats-next.html" >}} diff --git a/hugo/content/ko/tracing/trace_collection/single-step-apm/_index.md b/hugo/content/ko/tracing/trace_collection/single-step-apm/_index.md index de0ccb44842..b5888a94127 100644 --- a/hugo/content/ko/tracing/trace_collection/single-step-apm/_index.md +++ b/hugo/content/ko/tracing/trace_collection/single-step-apm/_index.md @@ -13,18 +13,24 @@ further_reading: - link: /tracing/trace_collection/automatic_instrumentation/single-step-apm/troubleshooting/ tag: 설명서 text: 단일 단계 APM 문제 해결하기 -- link: https://learn.datadoghq.com/courses/troubleshooting-apm-instrumentation-on-a-host - tag: 학습 센터 - text: 호스트에서 APM 계측 문제 해결하기 - link: /tracing/guide/local_sdk_injection tag: 설명서 text: 로컬 SDK 주입을 사용한 애플리케이션 계측 +- link: https://learn.datadoghq.com/courses/troubleshooting-apm-instrumentation-on-a-host + tag: 학습 센터 + text: 호스트에서 APM 계측 문제 해결하기 - link: https://www.datadoghq.com/blog/datadog-csi-driver/ tag: 블로그 text: Datadog의 CSI 드라이버로 보안 Kubernetes 환경에 고성능 관측 가능성 실현 - link: https://www.datadoghq.com/blog/rum-apm-single-step tag: 블로그 text: 단일 명령으로 Java 앱에 대한 엔드투엔드 가시성 활성화 +- link: https://www.datadoghq.com/blog/single-step-instrumentation-rules/ + tag: 블로그 + text: 단일 단계 계측 규칙을 사용하여 호스트 전반에서 서비스 추적을 관리하십시오 +- link: https://www.datadoghq.com/blog/choosing-apm-instrumentation/ + tag: 블로그 + text: '제로에서 트레이스까지: 스택에 적합한 APM 계측 방법 선택하기' title: 단일 단계 APM 계측 --- ## 개요 {#overview} @@ -33,6 +39,13 @@ SSI(단일 단계 계측)는 추가 구성 없이 Datadog SDK를 자동으로 작동 방식에 대해 더 알아보려면 [단일 단계 계측을 위한 인젝터 가이드][8]를 참조하세요. +{{< skill-callout + title="에이전트를 사용해 APM 설정하기" + text="Install the `dd-apm` skill in your AI coding agent for guided APM setup." + action_name="copy_dd_apm_skill_install_cmd" >}} +npx skills add https://github.com/datadog-labs/agent-skills --skill dd-apm --full-depth -y +{{< /skill-callout >}} + ## 전제 조건 {#prerequisites} 1. 애플리케이션에서 사용자 정의 계측 코드를 제거하고 재시작하세요. 사용자 정의 계측이 감지되면 SSI는 자동으로 비활성화됩니다. @@ -40,7 +53,7 @@ SSI(단일 단계 계측)는 추가 구성 없이 Datadog SDK를 자동으로 ## 애플리케이션 전반에 걸쳐 SDK 계측 {#instrument-sdks-across-applications} -**APM 계측**이 활성화된 상태에서 [Datadog Agent를 설치하거나 업데이트][1]하면, Agent는 지원되는 프로세스에 Datadog SDK를 로드하여 애플리케이션을 계측합니다. 이를 통해 코드 변경 없이 서비스에서 트레이스 데이터를 캡처하고 전송하여 분산 트레이싱을 할 수 있습니다. +{{< ui >}}APM Instrumentation{{< /ui >}}이 활성화된 상태에서 [Datadog Agent를 설치하거나 업데이트][1]하면, Agent가 지원되는 프로세스에 Datadog SDK를 로드하여 애플리케이션을 계측합니다. 이를 통해 코드 변경 없이 서비스에서 트레이스 데이터를 캡처하고 전송하여 분산 트레이싱을 할 수 있습니다. 계측 후 필요시 다음을 수행할 수 있습니다. - [UST(Unified Service Tag) 구성][14] @@ -55,8 +68,6 @@ SSI(단일 단계 계측)는 추가 구성 없이 Datadog SDK를 자동으로 {{< image-card href="windows/" src="integrations_logos/windows.png" alt="windows" >}} {{< /card-grid >}} -
- ## 문제 해결 {#troubleshooting} SSI를 사용한 APM 활성화와 관련한 문제가 발생하는 경우, [SSI 문제 해결 가이드][15]를 참조하세요. diff --git a/hugo/customization_config/ko/option_groups/cloud_siem_custom_detection_rules.yaml b/hugo/customization_config/ko/option_groups/cloud_siem_custom_detection_rules.yaml new file mode 100644 index 00000000000..7bf2472ec84 --- /dev/null +++ b/hugo/customization_config/ko/option_groups/cloud_siem_custom_detection_rules.yaml @@ -0,0 +1,63 @@ +cloud_siem_detection_rule_detection_method_options: + - id: threshold + default: true + - id: new_value + - id: anomaly + - id: content_anomaly + - id: impossible_travel + - id: third_party + - id: sequence + +cloud_siem_detection_threshold_rule_type_options: + - id: real_time_rule + default: true + - id: scheduled_rule + - id: historical_job + +cloud_siem_detection_new_value_rule_type_options: + - id: real_time_rule + default: true + - id: scheduled_rule + - id: historical_job + +cloud_siem_detection_anomaly_rule_type_options: + - id: real_time_rule + default: true + - id: scheduled_rule + - id: historical_job + +cloud_siem_detection_content_anomaly_rule_type_options: + - id: real_time_rule + default: true + - id: scheduled_rule + - id: historical_job + +cloud_siem_detection_impossible_travel_rule_type_options: + - id: real_time_rule + default: true + - id: scheduled_rule + - id: historical_job + +cloud_siem_detection_third_party_rule_type_options: + - id: real_time_rule + default: true + - id: scheduled_rule + - id: historical_job + +cloud_siem_detection_sequence_rule_type_options: + - id: real_time_rule + default: true + - id: historical_job + +cloud_siem_detection_rule_event_query_only_language_options: + - id: event_query + default: true + +cloud_siem_detection_threshold_sql_rule_query_language_options: + - id: event_query + default: true + - id: sql + +cloud_siem_detection_sequence_rule_query_language_options: + - id: event_rule_query + default: true diff --git a/hugo/layouts/shortcodes/observability_pipelines/set_up_pipelines/add_another_destination.fr.md b/hugo/layouts/shortcodes/observability_pipelines/set_up_pipelines/add_another_destination.fr.md new file mode 100644 index 00000000000..ddaa259da08 --- /dev/null +++ b/hugo/layouts/shortcodes/observability_pipelines/set_up_pipelines/add_another_destination.fr.md @@ -0,0 +1,13 @@ +Si vous souhaitez ajouter une destination supplémentaire à un groupe de processeurs, cliquez sur le signe plus (**+**) à droite du groupe de processeurs. + +Pour supprimer une destination, cliquez sur l'icône de corbeille dans le coin supérieur droit de la destination. +- Si vous supprimez une destination d'un groupe de processeurs qui comporte plusieurs destinations, seule cette destination est supprimée. +- Si vous supprimez une destination d'un groupe de processeurs qui ne comporte qu'une seule destination, la destination et le groupe de processeurs sont tous deux supprimés. + +**Remarques** : + +- Un pipeline doit comporter au moins une destination. Si un groupe de processeurs ne comporte qu'une seule destination, cette destination ne peut pas être supprimée. +- Vous pouvez ajouter un total de 20 destinations pour un pipeline. +- Si vous ajoutez plusieurs destinations du même type à un pipeline, vous devez utiliser [Secrets Management][101]. Par exemple, si vous ajoutez deux destinations HTTP Client pour deux HTTP Clients différents, vous devez utiliser des identifiants secrets pour les HTTP Client URIs. Vous ne pouvez pas utiliser la valeur par défaut `DESTINATION_HTTP_CLIENT_URI` pour stocker les deux HTTP Client URIs. + +[101]: /fr/observability_pipelines/configuration/secrets_management/ \ No newline at end of file