+{{< /code-block >}}
+
+No se requiere la habilitación de Feature Flags ni la configuración de la fuente. Registre el proveedor como se muestra en [Inicializar el SDK](#initialize-the-sdk) para comenzar el sondeo. Instalar o inicializar `ddtrace` por sí solo no crea tráfico de CDN de Feature Flags.
+
+Para configurar `feature_flag.evaluations`, incluida la versión requerida de la traza y la configuración de OTLP del Agent, consulte [Set Up Server-Side Flag Evaluation Metrics][4]. Para obtener más información sobre los gráficos disponibles, consulte [Feature Flag Graphs][5].
+
+## Instalación {#installation}
+
+Instale el SDK de Datadog para Python y el SDK de OpenFeature:
+
+{{< code-block lang="bash" >}}
+pip install ddtrace openfeature-sdk
+{{< /code-block >}}
+
+O agréguelos a su `requirements.txt`:
+
+{{< code-block lang="text" filename="requirements.txt" >}}
+ddtrace>=4.14.0
+openfeature-sdk>=0.5.0
+{{< /code-block >}}
+
+Si habilita las métricas de evaluación de Feature Flags, también debe instalar el SDK de OpenTelemetry y el exportador OTLP:
+
+{{< code-block lang="bash" >}}
+pip install opentelemetry-sdk opentelemetry-exporter-otlp-proto-grpc
+{{< /code-block >}}
+
+O agréguelos a su `requirements.txt`:
+
+{{< code-block lang="text" filename="requirements.txt" >}}
+opentelemetry-sdk>=1.41.0
+opentelemetry-exporter-otlp-proto-grpc>=1.41.0
+{{< /code-block >}}
+
+## Inicializar el SDK {#initialize-the-sdk}
+
+Registre el proveedor de Datadog OpenFeature con la API de OpenFeature. El proveedor inicia la fuente de configuración seleccionada y espera hasta 10 segundos para su primera configuración.
+
+{{< code-block lang="python" >}}
+from openfeature import api
+from ddtrace.openfeature import DataDogProvider
+
+# Create and register the Datadog provider
+provider = DataDogProvider()
+api.set_provider(provider)
+
+# Create an OpenFeature client
+client = api.get_client()
+
+# Your application code here
+{{< /code-block >}}
+
+## Establecer el contexto de evaluación {#set-the-evaluation-context}
+
+Defina un contexto de evaluación que identifique al usuario o entidad para la segmentación de Feature Flags. El contexto de evaluación incluye atributos utilizados para determinar qué variaciones de Feature Flags deben devolverse:
+
+Datadog Feature Flags requiere que los atributos del contexto de evaluación sean valores primitivos planos: cadenas, números y booleanos. No pase objetos o arreglos anidados; no son compatibles y pueden causar que los datos de exposición se pierdan.
+
+{{< code-block lang="python" >}}
+from openfeature.evaluation_context import EvaluationContext
+
+eval_ctx = EvaluationContext(
+ targeting_key="user-123", # Targeting key (typically user ID)
+ attributes={
+ "email": "user@example.com",
+ "country": "US",
+ "tier": "premium",
+ "age": 25
+ }
+)
+{{< /code-block >}}
+
+La clave de segmentación se utiliza para una distribución de tráfico consistente (lanzamientos porcentuales). Los atributos adicionales permiten reglas de segmentación, como "habilitar para usuarios en EE. UU." o "habilitar para usuarios de nivel premium" en el ejemplo anterior.
+
+## Evaluar Feature Flags {#evaluate-flags}
+
+Después de configurar el proveedor y crear un cliente, puede evaluar Feature Flags en toda su aplicación. La evaluación de Feature Flags es local y rápida: el SDK utiliza datos de configuración almacenados en caché localmente, por lo que no se producen solicitudes de red durante la evaluación.
+
+Cada Feature Flag se identifica mediante una clave (una cadena única) y se puede evaluar con un método tipado que devuelve un valor del tipo esperado. Si la Feature Flag no existe o no se puede evaluar, el SDK devuelve el valor predeterminado proporcionado.
+
+### Feature Flags booleanos {#boolean-flags}
+
+Use `get_boolean_value` para Feature Flags que representan condiciones de encendido/apagado o verdadero/falso:
+
+{{< code-block lang="python" >}}
+enabled = client.get_boolean_value("new-checkout-flow", False, eval_ctx)
+
+if enabled:
+ show_new_checkout()
+else:
+ show_legacy_checkout()
+{{< /code-block >}}
+
+### Feature Flags de cadena {#string-flags}
+
+Use `get_string_value` para Feature Flags que seleccionan entre múltiples variantes o cadenas de configuración:
+
+{{< code-block lang="python" >}}
+theme = client.get_string_value("ui-theme", "light", eval_ctx)
+
+if theme == "dark":
+ set_dark_theme()
+elif theme == "light":
+ set_light_theme()
+else:
+ set_light_theme()
+{{< /code-block >}}
+
+### Feature Flags numéricos {#numeric-flags}
+
+Para Feature Flags numéricos, use `get_integer_value` o `get_float_value`. Estos son apropiados cuando una función depende de un parámetro numérico como un límite, porcentaje o multiplicador:
+
+{{< code-block lang="python" >}}
+max_items = client.get_integer_value("cart-max-items", 20, eval_ctx)
+
+discount_rate = client.get_float_value("discount-rate", 0.0, eval_ctx)
+{{< /code-block >}}
+
+### Feature Flags de objeto {#object-flags}
+
+Para datos estructurados, use `get_object_value`. Esto devuelve un diccionario con configuración compleja:
+
+{{< code-block lang="python" >}}
+config = client.get_object_value("feature-config", {
+ "maxRetries": 3,
+ "timeout": 30
+}, eval_ctx)
+
+max_retries = config.get("maxRetries", 3)
+timeout = config.get("timeout", 30)
+{{< /code-block >}}
+
+### Detalles de evaluación de Feature Flags {#flag-evaluation-details}
+
+Cuando necesite más que solo el valor de una Feature Flag, utilice los métodos `*_details`. Estos devuelven tanto el valor evaluado como los metadatos que explican la evaluación:
+
+{{< code-block lang="python" >}}
+details = client.get_boolean_details("new-feature", False, eval_ctx)
+
+print(f"Value: {details.value}")
+print(f"Variant: {details.variant}")
+print(f"Reason: {details.reason}")
+print(f"Error Code: {details.error_code}")
+print(f"Error Message: {details.error_message}")
+{{< /code-block >}}
+
+Los detalles de la bandera le ayudan a depurar el comportamiento de la evaluación y a entender por qué un usuario recibió un valor determinado.
+
+### Evaluación sin contexto {#evaluation-without-context}
+
+Puede evaluar Feature Flags sin proporcionar un contexto de evaluación. Esto es útil para Feature Flags globales que no requieren una segmentación específica del usuario:
+
+{{< code-block lang="python" >}}
+# Global feature flag - no context needed
+maintenance_mode = client.get_boolean_value("maintenance-mode", False)
+
+if maintenance_mode:
+ return "Service temporarily unavailable"
+{{< /code-block >}}
+
+## Esperando la inicialización del proveedor {#waiting-for-provider-initialization}
+
+El registro del proveedor espera hasta 10 segundos a que la fuente seleccionada entregue su primera configuración. Si llega la configuración, el proveedor emite `PROVIDER_READY`. Si se agota el tiempo de espera, el registro se completa con el proveedor en un estado de error, y las evaluaciones devuelven los valores predeterminados proporcionados por el llamador hasta que llegue la configuración. Utilice un controlador de eventos para esperar un evento de listo posterior:
+
+{{< code-block lang="python" >}}
+import threading
+from openfeature import api
+from openfeature.event import ProviderEvent
+from ddtrace.openfeature import DataDogProvider
+
+# Create an event to wait for readiness
+ready_event = threading.Event()
+
+def on_ready(event_details):
+ ready_event.set()
+
+# Register event handler
+api.add_handler(ProviderEvent.PROVIDER_READY, on_ready)
+
+# Set provider
+provider = DataDogProvider()
+api.set_provider(provider)
+
+# Wait for the provider to be ready if registration timed out
+if ready_event.wait(timeout=30):
+ print("Provider is ready")
+else:
+ print("Provider initialization timed out")
+
+# Create client and evaluate flags
+client = api.get_client()
+{{< /code-block >}}
+
+Los controladores de eventos del proveedor requieren OpenFeature SDK 0.7.0 o posterior. La mayoría de las aplicaciones pueden utilizar el tiempo de espera de inicialización predeterminado de 10 segundos y manejar los valores predeterminados proporcionados por el llamador si la configuración no está disponible.
+
+Establezca `DD_EXPERIMENTAL_FLAGGING_PROVIDER_INITIALIZATION_TIMEOUT_MS` en un número positivo de milisegundos para cambiar el tiempo de espera de inicialización.
+
+## Configuración avanzada {#advanced-configuration}
+
+Utilice [Server SDK Configuration Sources][6] como referencia canónica para la selección de fuentes y los ajustes operativos:
+
+- [Configure la entrega sin agente][10], incluyendo el sondeo, el tiempo de espera de la solicitud y los ajustes del punto de conexión
+- [Utilice un punto de conexión sin agente personalizado][7] para pruebas avanzadas, desarrollo local o un proxy gestionado por el operador
+- [Utilice Remote Configuration del Agent][9] para conservar la entrega gestionada por el Agent
+- [Migre una configuración de Remote Configuration existente][8] y elimine el ajuste `DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED` obsoleto
+
+El modo sin agente solo cambia la configuración de los flags. No configura ni habilita `feature_flag.evaluations`, el registro de exposición ni los casos de uso de experimentación. Estas funciones requieren un Datadog Agent compatible o una ruta de telemetría sin servidor.
+
+## Limpieza {#cleanup}
+
+Cuando su aplicación finalice, apague la API de OpenFeature para limpiar los recursos:
+
+{{< code-block lang="python" >}}
+api.shutdown()
+{{< /code-block >}}
+
+## Pruebas {#testing}
+
+Puede realizar pruebas en un entorno de prueba de Datadog dedicado con el proveedor real de Datadog, o cambiarlo por el `InMemoryProvider` de OpenFeature para controlar los valores de las Feature Flags directamente en el código de prueba. Esta sección muestra el enfoque en memoria, que mantiene las pruebas herméticas y sin conexión. `InMemoryProvider` se incluye con `openfeature-sdk`, por lo que no se requiere ninguna dependencia adicional.
+
+La API de OpenFeature es un singleton global (`openfeature.api.set_provider` muta el estado a nivel de módulo). Use un fixture de pytest con alcance de `function` y llame a `api.shutdown()` en el teardown para que el estado de las Feature Flags no se filtre entre las pruebas.
+
+{{< code-block lang="python" filename="test_flags.py" >}}
+import pytest
+from openfeature import api
+from openfeature.evaluation_context import EvaluationContext
+from openfeature.provider.in_memory_provider import InMemoryProvider, InMemoryFlag
+
+
+@pytest.fixture
+def client():
+ flags = {
+ "new-checkout-flow": InMemoryFlag(
+ default_variant="off",
+ variants={"on": True, "off": False},
+ ),
+ "ui-theme": InMemoryFlag(
+ default_variant="light",
+ variants={"light": "light", "dark": "dark"},
+ ),
+ }
+ api.set_provider(InMemoryProvider(flags))
+ yield api.get_client()
+ api.shutdown()
+
+
+def test_boolean_flag_returns_default_variant(client):
+ assert client.get_boolean_value("new-checkout-flow", True) is False
+
+
+def test_string_flag_with_context(client):
+ ctx = EvaluationContext(targeting_key="user-123")
+ assert client.get_string_value("ui-theme", "dark", ctx) == "light"
+
+
+def test_missing_flag_returns_default(client):
+ assert client.get_boolean_value("does-not-exist", True) is True
+{{< /code-block >}}
+
+`InMemoryFlag` toma `default_variant` (un nombre de variante de cadena) y `variants` (un diccionario que asigna nombres de variantes a valores tipados). Pasar un valor como `default_variant` en lugar de un nombre de variante es un error común. Para la lógica de segmentación, pase una devolución de llamada `context_evaluator` que reciba la Feature Flag y un `EvaluationContext` y devuelva un objeto `FlagResolutionDetails` que contenga la variante elegida.
+
+## Solución de problemas {#troubleshooting}
+
+### La configuración sin agente no funciona {#agentless-configuration-not-working}
+
+Verifique lo siguiente:
+
+- `ddtrace` es la versión 4.14.0 o posterior.
+- `DD_FEATURE_FLAGS_ENABLED` no está configurado o está establecido en `true`.
+- `DD_FEATURE_FLAGS_CONFIGURATION_SOURCE` no está configurado o está establecido en `agentless`.
+- `DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED` no está configurado. Establecerlo en `true` selecciona la Configuración Remota del Agente durante la ventana de migración cuando no se establece ninguna fuente explícita.
+- El código de la aplicación registra `DataDogProvider` con la API de OpenFeature.
+- `DD_API_KEY`, `DD_SITE` y `DD_ENV` están configurados en el proceso de la aplicación.
+- La aplicación puede realizar solicitudes HTTPS salientes a Datadog.
+
+Establezca `DD_TRACE_DEBUG=true` y verifique si hay mensajes de autenticación, tiempo de espera o carga útil mal formada desde el punto de conexión sin agente de Feature Flags.
+
+### La Configuración Remota del Agente no funciona {#agent-remote-configuration-not-working}
+
+Verifique lo siguiente:
+
+- `DD_FEATURE_FLAGS_CONFIGURATION_SOURCE=remote_config` está configurado. Durante la ventana de migración, `DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true` también selecciona Remote Configuration cuando no se establece ninguna fuente explícita.
+- Datadog Agent es la versión 7.55 o posterior.
+- [Remote Configuration][2] está habilitado en el Agent.
+- El Agent tiene una clave de API válida para la organización de destino.
+- `DD_SERVICE` y `DD_ENV` están configurados en el proceso de la aplicación.
+- El SDK puede comunicarse con el Agent.
+
+[1]: https://openfeature.dev/
+[2]: /es/agent/remote_config/
+[3]: /es/account_management/api-app-keys/#api-keys
+[4]: /es/feature_flags/guide/server_flag_evaluation_metrics/
+[5]: /es/feature_flags/concepts/flag_graphs/
+[6]: /es/feature_flags/concepts/configuration_sources/
+[7]: /es/feature_flags/concepts/configuration_sources/#use-a-custom-agentless-endpoint
+[8]: /es/feature_flags/concepts/configuration_sources/#migrate-an-existing-remote-configuration-setup
+[9]: /es/feature_flags/concepts/configuration_sources/#use-agent-remote-configuration
+[10]: /es/feature_flags/concepts/configuration_sources/#configure-agentless-delivery
+
+## Lecturas adicionales {#further-reading}
+
+{{< partial name="whats-next/whats-next.html" >}}
\ No newline at end of file
diff --git a/hugo/content/es/incident_response/incident_management/post_incident/follow-ups.md b/hugo/content/es/incident_response/incident_management/post_incident/follow-ups.md
new file mode 100644
index 00000000000..5b8199ab748
--- /dev/null
+++ b/hugo/content/es/incident_response/incident_management/post_incident/follow-ups.md
@@ -0,0 +1,117 @@
+---
+algolia:
+ tags:
+ - follow ups
+ - follow-up
+ - follow up
+aliases:
+- /es/service_management/incident_management/follow-ups/
+- /es/incident_response/incident_management/follow-ups
+description: Administre las tareas de seguimiento definidas durante su proceso de
+ respuesta a incidentes.
+further_reading:
+- link: /incident_response/incident_management/setup_and_configuration
+ tag: Documentación
+ text: Configuración de incidentes
+- link: /service_management/incident_management/integrations/slack/
+ tag: Documentación
+ text: Integre Slack con Datadog Incident Management
+title: Seguimientos de incidentes
+---
+## Resumen {#overview}
+
+Los seguimientos de incidentes son tareas realizadas después de que se resuelve un incidente. Durante una investigación de incidentes, su equipo podría identificar problemas que necesitan atención pero que no están directamente relacionados con la resolución del problema inmediato. En lugar de perder el rastro de estos elementos en la prisa por restaurar el servicio, puede capturarlos como seguimientos para abordarlos después de que se resuelva el incidente.
+
+Ejemplos comunes para crear seguimientos incluyen:
+
+- **Mejoras en la infraestructura**: registros mal configurados, alertas faltantes o cobertura de monitoreo inadecuada descubierta durante el incidente
+- **Deuda técnica**: código que necesita refactorización, sistemas frágiles que necesitan fortalecimiento o documentación que necesita actualización
+- **Mejoras en los procesos**: brechas en los manuales de procedimientos, rutas de escalamiento poco claras o permisos de acceso faltantes
+- **Correcciones de la causa raíz**: problemas subyacentes que requieren más tiempo para abordarse que la mitigación inmediata
+
+Al capturar estos elementos como seguimientos, su equipo puede mantenerse enfocado en la resolución del incidente mientras asegura que no se olviden las mejoras importantes.
+
+## Tareas de seguimiento sugeridas por IA {#ai-suggested-follow-up-tasks}
+
+{{< site-region region="gov" >}}
+Las tareas de seguimiento sugeridas por IA no son compatibles con su
sitio de Datadog seleccionado ({{< region-param key="dd_site_name" >}}).
Work Management se conocía anteriormente como Case Management. Los puntos de conexión de la API y los permisos aún utilizan la case terminología.
+
+## Descripción general {#overview}
+
+Datadog Work Management ofrece un lugar centralizado para clasificar, rastrear y remediar problemas detectados por Datadog y por integraciones de terceros. Después de crear un elemento de trabajo, puede asignarlo a un usuario, estableciendo líneas claras de propiedad que persisten durante todo el ciclo de vida del elemento de trabajo.
+
+Mientras investiga, complete el elemento de trabajo con gráficos, registros y otros datos de telemetría de todo Datadog y colabore con los miembros de su equipo en la línea de tiempo de actividad. Work Management también se integra con herramientas como Jira, ServiceNow, PagerDuty, Slack y Microsoft Teams, lo que le permite adaptar las soluciones de Work Management a los procesos de su organización.
+
+## Primeros pasos {#getting-started}
+{{< whatsnext desc="Obtenga más información sobre Work Management:">}}
+ {{< nextlink href="/incident_response/work_management/create_work_item" >}}Crear un elemento de trabajo{{< /nextlink >}}
+ {{< nextlink href="/incident_response/work_management/projects" >}}Proyectos{{< /nextlink >}}
+ {{< nextlink href="/incident_response/work_management/view_and_manage" >}}Visualizar y administrar elementos de trabajo{{< /nextlink >}}
+ {{< nextlink href="/incident_response/work_management/settings" >}}Administrar la membresía y las transiciones de estado dentro de los proyectos{{< /nextlink >}}
+ {{< nextlink href="/incident_response/work_management/approvals" >}}Aprobaciones de elementos de trabajo{{< /nextlink >}}
+{{< /whatsnext >}}
+
+## Lecturas adicionales {#further-reading}
+
+{{< partial name="whats-next/whats-next.html" >}}
\ No newline at end of file
diff --git a/hugo/content/es/incident_response/work_management/projects.md b/hugo/content/es/incident_response/work_management/projects.md
new file mode 100644
index 00000000000..61077e1da8a
--- /dev/null
+++ b/hugo/content/es/incident_response/work_management/projects.md
@@ -0,0 +1,35 @@
+---
+aliases:
+- /es/service_management/case_management/projects/
+- /es/incident_response/case_management/projects/
+disable_toc: false
+further_reading:
+- link: incident_response/work_management/create_work_item
+ tag: Documentación
+ text: Crear un elemento de trabajo
+title: Proyectos
+---
+## Descripción general {#overview}
+
+Un proyecto es un objeto contenedor que alberga un conjunto de elementos de trabajo. Organice su trabajo en torno a los grupos que tengan sentido para su organización, ya sean equipos, servicios o iniciativas. Los elementos de trabajo en cada proyecto están aislados entre sí, lo que le ayuda a concentrarse en lo que es relevante.
+
+## Crear un proyecto {#create-a-project}
+
+Para crear un proyecto:
+1. Seleccione **New Project** en el Projects view o haga clic en el icono **+** junto a *Your Projects* en la barra de navegación izquierda.
+1. Ingrese un nombre y una clave para el proyecto. Las claves de proyecto deben tener entre uno y 10 caracteres de longitud. Los números de identificación de los elementos de trabajo tienen como prefijo una combinación de letras, por ejemplo, `NOC-123`. Las claves de proyecto son inmutables.
+1. Haga clic en **Create Project**.
+
+## Eliminar un proyecto {#delete-a-project}
+
+Los elementos de trabajo eliminados no se pueden recuperar.
+
+Puede eliminar un proyecto desde la página de Settings del proyecto.
+
+Eliminar un proyecto también elimina todos los elementos de trabajo que contiene. Si desea conservar los elementos de trabajo, Datadog recomienda moverlos a otro proyecto antes de eliminarlos.
+
+Eliminar un proyecto deshabilita automáticamente cualquier patrón de correlación de eventos vinculado al proyecto. Otras automatizaciones, como la creación de elementos de trabajo a través de flujos de trabajo de Datadog o menciones de Monitor `@case`, también se interrumpen cuando elimina el proyecto vinculado.
+
+## Lecturas adicionales {#further-reading}
+
+{{< partial name="whats-next/whats-next.html" >}}
\ No newline at end of file
diff --git a/hugo/content/es/incident_response/work_management/troubleshooting.md b/hugo/content/es/incident_response/work_management/troubleshooting.md
new file mode 100644
index 00000000000..16238e594ac
--- /dev/null
+++ b/hugo/content/es/incident_response/work_management/troubleshooting.md
@@ -0,0 +1,37 @@
+---
+aliases:
+- /es/service_management/case_management/troubleshooting/
+- /es/incident_response/case_management/troubleshooting/
+title: Solución de problemas
+---
+## Resumen {#overview}
+
+Esta guía tiene como objetivo ayudarle a resolver problemas con integraciones de terceros en Work Management. Si continúa teniendo problemas, comuníquese con el [soporte de Datadog][1] para obtener más ayuda.
+
+## Jira {#jira}
+
+Los tipos de incidencias de Jira con campos personalizados, los proyectos privados de Jira y las instancias de Jira locales no son compatibles. Si tiene problemas con la creación automática de tickets de Jira con la sincronización, consulte las siguientes secciones:
+
+### Configuración {#configuration}
+
+1. Si los proyectos de Jira no aparecen en el menú desplegable en la pantalla de configuración de la integración de Jira, verifique que tenga el permiso `manage_integrations`.
+
+1. Asegúrese de haber configurado un webhook para recibir eventos de Jira.
+
+### Sincronización y actualizaciones {#syncing-and-updates}
+
+1. Si mueve un elemento de trabajo que se está sincronizando con una incidencia de Jira a un proyecto de Work Management diferente, la sincronización se detiene. Después de moverlo, el elemento de trabajo en el nuevo proyecto no tiene una incidencia de Jira adjunta.
+1. Si actualiza el estado de un elemento de trabajo de una manera que no está permitida por un flujo de trabajo de Jira, el elemento de trabajo pierde la sincronización con el mapeo de estados.
+1. Las actualizaciones de comentarios, incluidas las eliminaciones, ya sea en Work Management o en Jira, no se reflejan en el otro lado.
+1. Solo se sincronizan los elementos de trabajo creados después de que se habilitó la integración bidireccional. Datadog no sincroniza retroactivamente los elementos de trabajo que existían antes de que se habilitara la integración.
+
+### Reportero de la incidencia de Jira {#jira-issue-reporter}
+
+1. Existen algunos escenarios en los que el reportero de la incidencia de Jira se refleja como el usuario de Datadog que configuró la integración de Jira. Algunos de estos escenarios incluyen:
+ - Cuando un usuario de Datadog que crea un elemento de trabajo no tiene una cuenta de Jira
+ - Un usuario de Jira tiene la visibilidad de correo electrónico oculta
+1. Si el reportero de la incidencia de Jira reflejada se actualiza, no se refleja en Work Management, ya que el campo "creado por" no es editable.
+
+
+
+[1]: https://docs.datadoghq.com/es/help/
\ No newline at end of file
diff --git a/hugo/content/es/llm_observability/evaluations/custom_llm_as_a_judge_evaluations/_index.md b/hugo/content/es/llm_observability/evaluations/custom_llm_as_a_judge_evaluations/_index.md
new file mode 100644
index 00000000000..bcf97b69c13
--- /dev/null
+++ b/hugo/content/es/llm_observability/evaluations/custom_llm_as_a_judge_evaluations/_index.md
@@ -0,0 +1,618 @@
+---
+description: Cómo crear evaluaciones personalizadas de LLM-as-a-judge y cómo utilizar
+ estos resultados de evaluación en Agent Observability.
+further_reading:
+- link: https://www.datadoghq.com/blog/manage-ai-cost-and-performance-with-datadog/
+ tag: Blog
+ text: 'Impulsar el ROI de la IA: cómo Datadog conecta el costo, el rendimiento y
+ la infraestructura para que usted pueda escalar de manera responsable'
+- link: https://www.datadoghq.com/blog/llm-aws-strands
+ tag: Blog
+ text: Obtenga visibilidad de los flujos de trabajo de los agentes de Strands con
+ Datadog LLM Observability
+- link: https://www.datadoghq.com/blog/llm-evaluation-framework-best-practices/
+ tag: Blog
+ text: 'Creación de un marco de evaluación de LLM: mejores prácticas'
+- link: /llm_observability/terms/
+ tag: Documentación
+ text: Conozca los términos y conceptos de Agent Observability
+- link: /llm_observability/setup
+ tag: Documentación
+ text: Aprenda a configurar Agent Observability
+- link: /llm_observability/evaluations/managed_evaluations
+ tag: Documentación
+ text: Conozca las evaluaciones gestionadas
+- link: https://huggingface.co/learn/cookbook/llm_judge
+ tag: Hugging Face
+ text: Uso de LLM-as-a-judge para una evaluación automatizada y versátil
+title: Evaluaciones personalizadas de LLM-as-a-judge
+---
+Las evaluaciones personalizadas de LLM-as-a-judge utilizan un LLM para evaluar el rendimiento de otro LLM. Defina la lógica de evaluación con prompts en lenguaje natural, capture criterios subjetivos u objetivos (como el tono, la utilidad o la veracidad) y ejecute las evaluaciones a escala en:
+
+- **Contexto de tramo**—califique la entrada y la salida de una llamada a un LLM, un paso de agente o una invocación de herramienta de forma aislada.
+- **Contexto de traza**—envíe cada tramo de una traza al LLM juez en un solo prompt, para que la evaluación pueda razonar a través de los pasos. Consulte [Evaluaciones a nivel de traza][16] para ver el tutorial completo, los casos de uso y ejemplos de prompts.
+- **Contexto de sesión**—envíe cada traza en una sesión de usuario (y cada tramo en esas trazas) al LLM juez en un solo prompt, para que la evaluación pueda razonar a través de toda una interacción de varios turnos. Consulte [Evaluaciones a nivel de sesión][17] para ver el tutorial completo, los casos de uso y ejemplos de prompts.
+
+## Crear una evaluación personalizada de LLM-as-a-judge {#create-a-custom-llm-as-a-judge-evaluation}
+
+Puede crear y gestionar evaluaciones personalizadas desde la [página de Evaluaciones][1] en Agent Observability. Puede proporcionar una descripción de evaluación para generar una evaluación, utilizar y desarrollar [plantillas de evaluaciones de LLM-as-a-judge][7] que proporcionamos, o comenzar desde cero. Puede habilitar el rastreo para ver las trazas de sus evaluaciones.
+
+
+
+Obtenga más información sobre los [requisitos de compatibilidad][6].
+
+### Configure el prompt {#configure-the-prompt}
+
+1. En Datadog, navegue a la página de [Evaluaciones][1] de Agent Observability. Seleccione {{< ui >}}Create Evaluation{{< /ui >}}, luego seleccione {{< ui >}}Create your own{{< /ui >}}.
+ {{< img src="llm_observability/evaluations/EvalConfig_LLMO_1.png" alt="La página de Evaluaciones de Agent Observability después de seleccionar Crear evaluación." style="width:100%;" >}}
+1. Para habilitar el rastreo para las evaluaciones, haga clic en el botón {{< ui >}}Tracing Disabled{{< /ui >}}, luego seleccione el interruptor {{< ui >}}Trace Evaluations{{< /ui >}} para habilitar el rastreo. Cuando se ejecuta esta evaluación, sus trazas aparecen bajo `datadog-evaluations`, lo que le brinda una mayor visibilidad de sus evaluaciones. **Nota**: Habilitar el rastreo aumenta la cantidad de tramos facturados enviados a Datadog.
+ {{< img src="llm_observability/evaluations/evaluation_tracing_enabled.png" alt="Evaluaciones de traza habilitadas después de haber seleccionado el interruptor para habilitar el rastreo de evaluaciones." >}}
+1. Proporcione un {{< ui >}}evaluation name{{< /ui >}} claro y descriptivo (por ejemplo, `factuality-check` o `tone-eval`). Puede usar este nombre al consultar los resultados de la evaluación. El nombre debe ser único dentro de su aplicación.
+1. Configure el modelo:
+ 1. Seleccione el menú desplegable {{< ui >}}Account{{< /ui >}} para elegir el proveedor de LLM y la cuenta correspondiente que usará para su LLM juez. Para conectar una cuenta nueva, consulte [conectar un proveedor de LLM][2].
+ - Si selecciona una cuenta {{< ui >}}Amazon Bedrock{{< /ui >}}, elija una región para la cual esté configurada la cuenta. Luego puede seleccionar un nombre de modelo o proporcionar el ARN del perfil de inferencia.
+ - Si selecciona una cuenta {{< ui >}}Vertex{{< /ui >}}, elija un proyecto y una ubicación. El menú desplegable {{< ui >}}Location{{< /ui >}} incluye opciones de región única, multirregión y globales. Para obtener detalles sobre cada opción, consulte la [documentación de ubicaciones de Vertex AI de Google][18].
+ 1. Utilice el menú desplegable {{< ui >}}Model{{< /ui >}} para seleccionar un modelo.
+1. En {{< ui >}}Runs On{{< /ui >}}, seleccione la aplicación que desea evaluar, qué desea evaluar (tramo, traza o sesión) y la tasa de muestreo. Puede agregar más criterios de filtrado seleccionando el botón a la derecha de la tasa de muestreo.
+1. En la sección {{< ui >}}Template{{< /ui >}}, utilice el menú desplegable:
+ - {{< ui >}}Create from scratch{{< /ui >}}: Utilice su propio prompt personalizado (definido en el siguiente paso).
+ - {{< ui >}}Failure to Answer{{< /ui >}}, {{< ui >}}Prompt Injection{{< /ui >}}, {{< ui >}}Sentiment{{< /ui >}}, etc.: Complete una plantilla de prompt preexistente. Puede usar estas plantillas tal cual o modificarlas para que coincidan con su lógica de evaluación específica.
+1. En el campo {{< ui >}}System Prompt{{< /ui >}}, ingrese su prompt personalizado o modifique una plantilla de prompt.
+ Para prompts personalizados, proporcione instrucciones claras que describan lo que el evaluador debe valorar.
+ - Concéntrese en un único objetivo de evaluación
+ - Incluya 2-3 ejemplos de few-shot que muestren pares de entrada/salida, resultados esperados y razonamiento.
+
+{{% collapse-content title="Ejemplo de prompt personalizado" level="h4" expanded=false id="custom-prompt-example" %}}
+**Prompt del sistema**
+
+```
+You will be looking at interactions between a user and a budgeting AI agent. Your job is to classify the user's intent when it comes to using the budgeting AI agent.
+
+You will be given a Span Input, which represents the user's message to the agent, which you will then classify. Here are some examples.
+
+Span Input: What are the core things I should know about budgeting?
+Classification: general_financial_advice
+
+Span Input: Did I go over budget with my grocery bills last month?
+Classification: budgeting_question
+
+Span Input: What is the category for which I have the highest budget?
+Classification: budgeting_question
+
+Span Input: Based on my past months, what is my ideal budget for subscriptions?
+Classification: budgeting_advice
+
+Span Input: Raise my restaurant budget by $50
+Classification: budgeting_request
+
+Span Input: Help me plan a trip to the Maldives
+Classification: unrelated
+```
+
+**Usuario**
+
+```
+Span Input: {{span_input}}
+```
+{{% /collapse-content %}}
+
+8. En el campo {{< ui >}}User Prompt{{< /ui >}}, especifique qué partes del tramo, traza o sesión evaluar agregando variables. Puede agregar cualquier atributo de tramo, como Tramo Input (`"{{tramo_input}}`), Output (`{{tramo_output}}`), or any other span field. For trace-scoped evaluations, use `{{tramos...}}` paths to read across spans; for session-scoped evaluations, use `{{trazas...}}` rutas para leer a través de las trazas. Consulte [Plantillas de prompts][15] para obtener la referencia completa. Para editar el prompt del usuario directamente, selecciónelo y edite el texto.
+
+ También puede usar el panel de la derecha ({{< ui >}}Filtered Spans{{< /ui >}} en el ámbito del tramo, {{< ui >}}Filtered Traces{{< /ui >}} en el ámbito de la traza, {{< ui >}}Filtered Sessions{{< /ui >}} en el contexto de la sesión) para agregar datos de tramo como una variable:
+ 1. Elija una cuenta y una aplicación para que los tramos, trazas o sesiones aparezcan a la derecha.
+ 2. Seleccione uno de los tramos a la derecha para ver su JSON.
+ 3. Seleccione {{< ui >}}+{{< /ui >}} para agregar el JSON a su prompt de usuario.
+
+{{< img src="llm_observability/evaluations/custom_llm_judge_2-5.png" alt="El contenido del menú de la visualización JSON en el panel derecho de configuración de evaluación personalizada, que muestra la opción para Agregar variable al mensaje." style="width:40%;" >}}
+
+### Defina la salida de evaluación {#define-the-evaluation-output}
+
+Para modelos de OpenAI, Azure OpenAI, Vertex AI, Anthropic o Amazon Bedrock, configure [Salida estructurada](#structured-output).
+
+Para modelos de Anthropic o Amazon Bedrock, también puede configurar [Búsqueda por palabras clave](#keyword-search-output).
+
+Para AI Gateway, se admiten tanto [Salida estructurada](#structured-output) como [Búsqueda por palabras clave](#keyword-search-output). Datadog recomienda usar Salida estructurada cuando su modelo la admita y, de lo contrario, recurrir a Búsqueda por palabras clave.
+
+{{% collapse-content title="Salida estructurada (OpenAI, Azure OpenAI, Anthropic, Amazon Bedrock, AI Gateway, Vertex AI)" level="h4" expanded="true" id="structured-output" %}}
+1. Seleccione un tipo de salida de evaluación:
+
+ - {{< ui >}}Boolean{{< /ui >}}: Resultados verdadero/falso (por ejemplo, "¿El modelo siguió las instrucciones?")
+ - {{< ui >}}Score{{< /ui >}}: Calificaciones numéricas (por ejemplo, una escala del 1 al 5 para la utilidad)
+ - {{< ui >}}Categorical{{< /ui >}}: Etiquetas discretas (por ejemplo, "Bueno", "Malo", "Neutral")
+ - {{< ui >}}JSON{{< /ui >}}: JSON permite esquemas de formato libre
+
+2. Opcionalmente, seleccione {{< ui >}}Enable Reasoning{{< /ui >}}. Esto configura al juez LLM para que proporcione una breve justificación de su decisión (por ejemplo, por qué se otorgó un puntaje de 8). El razonamiento le ayuda a comprender cómo y por qué se realizan las evaluaciones, y es particularmente útil para auditar métricas subjetivas como el tono, la empatía o la utilidad. Agregar razonamiento también puede [hacer que el juez LLM sea más preciso](https://arxiv.org/abs/2504.00050).
+
+3. Edite un esquema JSON que defina el tipo de salida de sus evaluaciones:
+
+{{< tabs >}}
+{{% tab "Booleano" %}}
+Para el tipo de salida **Booleano**, edite el campo `description` para explicar mejor qué significan verdadero y falso en su caso de uso.
+{{% /tab %}}
+
+{{% tab "Puntaje" %}}
+Para el tipo de salida **Puntaje**:
+- Establezca un puntaje `min` y `max` para su evaluación.
+- Edite el campo `description` para explicar mejor la escala de su evaluación.
+{{% /tab %}}
+{{% tab "Categórico" %}}
+Para el tipo de salida **Categórico**:
+- Agregue o elimine categorías editando el esquema JSON.
+- Edite los nombres de las categorías.
+- Edite el campo `description` de las categorías para explicar mejor qué significan en el contexto de su evaluación.
+
+
+Un ejemplo de esquema para una evaluación categórica:
+
+```
+{
+ "name": "categorical_eval",
+ "schema": {
+ "type": "object",
+ "required": [
+ "categorical_eval",
+ "reasoning"
+ ],
+ "properties": {
+ "categorical_eval": {
+ "type": "string",
+ "anyOf": [
+ {
+ "const": "budgeting_question",
+ "description": "The user is asking a question about their budget. The answer can be directly determined by looking at their budget and spending."
+ },
+ {
+ "const": "budgeting_request",
+ "description": "The user is asking to change something about their budget. This should involve an action that changes their budget."
+ },
+ {
+ "const": "budgeting_advice",
+ "description": "The user is asking for advice on their budget. This should not require a change to their budget, but it should require an analysis of their budget and spending."
+ },
+ {
+ "const": "general_financial_advice",
+ "description": "The user is asking for general financial advice which is not directly related to their specific budget. However, this can include advice about budgeting in general."
+ },
+ {
+ "const": "unrelated",
+ "description": "This is a catch-all category for things not related to budgeting or financial advice."
+ }
+ ]
+ },
+ "reasoning": {
+ "type": "string",
+ "description": "Describe how you decided the category"
+ }
+ },
+ "additionalProperties": false
+ },
+ "strict": true
+}
+```
+{{% /tab %}}
+{{% tab "JSON" %}}
+Para el tipo de salida **JSON**, defina un esquema JSON de forma libre para capturar resultados de evaluación estructurados y complejos.
+
+Un esquema de ejemplo para una evaluación JSON:
+
+```
+{
+ "name": "json_eval",
+ "schema": {
+ "type": "object",
+ "required": [
+ "result",
+ "reasoning"
+ ],
+ "properties": {
+ "result": {
+ "type": "object",
+ "description": "The structured evaluation result",
+ "properties": {
+ "is_compliant": {
+ "type": "boolean",
+ "description": "Whether the response meets compliance requirements"
+ },
+ "confidence_score": {
+ "type": "number",
+ "description": "Confidence level of the evaluation from 0 to 1"
+ },
+ "issue_count": {
+ "type": "integer",
+ "description": "Number of issues identified in the response"
+ }
+ },
+ "required": ["is_compliant", "confidence_score", "issue_count"],
+ "additionalProperties": false
+ },
+ "reasoning": {
+ "type": "string",
+ "description": "Describe the reasoning behind your evaluation"
+ }
+ },
+ "additionalProperties": false
+ },
+ "strict": true
+}
+```
+{{% /tab %}}
+{{< /tabs >}}
+
+
+4. Configure {{< ui >}}Assessment Criteria{{< /ui >}}.
+ Esta flexibilidad le permite alinear los resultados de la evaluación con el estándar de calidad de su equipo. El mapeo de aprobado/reprobado también impulsa la automatización en Datadog Agent Observability, permitiendo que seguimientos y dashboards alerten sobre regresiones o hagan un seguimiento del estado general.
+
+{{< tabs >}}
+{{% tab "Booleano" %}}
+Seleccione {{< ui >}}True{{< /ui >}} para marcar un resultado como "Pass", o {{< ui >}}False{{< /ui >}} para marcar un resultado como "Fail".
+{{% /tab %}}
+
+{{% tab "Puntaje" %}}
+Defina umbrales numéricos para determinar el rendimiento de aprobación.
+{{% /tab %}}
+{{% tab "Categórico" %}}
+Seleccione las categorías que deben asignarse a un estado de aprobación. Por ejemplo, si tiene las categorías `Excellent`, `Good` y `Poor`, donde solo `Poor` debe corresponder a un estado de reprobación, seleccione `Excellent` y `Good`.
+{{% /tab %}}
+{{% tab "JSON" %}}
+Proporcione una función de JavaScript para asignar una evaluación basada en el resultado del evaluador LLM-as-a-Judge. La función debe devolver un objeto json con el siguiente formato
+
+```
+{
+ assessment: "pass", // "pass" | "fail" [REQUIRED],
+ value: "evaluation_label" // string [OPTIONAL],
+ reasoning: "explanation behind the assessment" // string [OPTIONAL]
+
+}
+```
+y la firma de la función debe ser `function __evalPostProcessing(input)` y `input` es el json del evaluador. La siguiente función es un ejemplo de una función de posprocesamiento:
+
+```
+function __evalPostProcessing(input) {
+ /*
+ * Expected input shape (from LLM evaluator [this depends on the JSON Structured Output]):
+ * {
+ * criteria: {
+ * quality_score: { score: number (0–1), category: "excellent"|"good"|"poor", reasoning: string },
+ * toxicity: { score: number (0–1), category: "safe"|"unsafe", reasoning: string },
+ * completeness: { score: number (0–1), category: "complete"|"incomplete", reasoning: string },
+ * relevance: { score: number (0–1), category: "relevant"|"irrelevant", reasoning: string },
+ * },
+ * overall_reasoning: string // (optional) top-level summary from LLM evaluator
+ * }
+ */
+
+ const SCORE_THRESHOLD = 0.7;
+
+ // Category → pass/fail mappings per criterion
+ const CATEGORY_PASS_MAP = {
+ quality_score: ["excellent", "good"],
+ toxicity: ["safe"],
+ completeness: ["complete"],
+ relevance: ["relevant"],
+ };
+
+ const criteriaResults = {};
+ const failures = [];
+ const passes = [];
+
+ for (const [criterionName, passCategories] of Object.entries(CATEGORY_PASS_MAP)) {
+ const criterion = input?.criteria?.[criterionName];
+
+ if (!criterion) {
+ failures.push(`[${criterionName}] Missing from evaluator output.`);
+ criteriaResults[criterionName] = false;
+ continue;
+ }
+
+ const { score, category, reasoning } = criterion;
+
+ const scorePass = typeof score === "number" && score >= SCORE_THRESHOLD;
+ const categoryPass = typeof category === "string" && passCategories.includes(category.toLowerCase());
+
+ // Both score AND category must pass
+ const criterionPass = scorePass && categoryPass;
+ criteriaResults[criterionName] = criterionPass;
+
+ if (criterionPass) {
+ passes.push(`[${criterionName}] PASS — score: ${score.toFixed(2)}, category: "${category}". ${reasoning ?? ""}`);
+ } else {
+ const reasons = [];
+ if (!scorePass) reasons.push(`score ${score?.toFixed(2) ?? "N/A"} below threshold (≥${SCORE_THRESHOLD})`);
+ if (!categoryPass) reasons.push(`category "${category}" not in acceptable set [${passCategories.join(", ")}]`);
+ failures.push(`[${criterionName}] FAIL — ${reasons.join("; ")}. ${reasoning ?? ""}`);
+ }
+ }
+
+ // Determine overall assessment
+ const passed = Object.values(criteriaResults).every(Boolean);
+ const failCount = failures.length;
+
+ const assessment = passed ? "pass" : "fail";
+
+ const label = passed
+ ? "high_quality_response"
+ : failCount === 1
+ ? "minor_quality_issue"
+ : failCount === 2
+ ? "moderate_quality_issue"
+ : "low_quality_response";
+
+ const reasoningParts = [
+ passed
+ ? "All criteria passed."
+ : `${failCount} criterion/criteria failed.`,
+ ...failures,
+ ...passes,
+ input?.overall_reasoning ? `Evaluator summary: ${input.overall_reasoning}` : ""
+ ].filter(Boolean);
+
+ return {
+ assessment: assessment,
+ value: label,
+ reasoning: reasoningParts.join(" | ")
+ };
+}
+```
+{{% /tab %}}
+{{< /tabs >}}
+
+
+{{% /collapse-content %}}
+
+{{% collapse-content title="Posprocesamiento (OpenAI, Azure OpenAI, Anthropic, Amazon Bedrock, AI Gateway, Vertex AI)" level="h4" expanded="true" id="post-processing" %}}
+1. Seleccione el tipo de salida {{< ui >}}JSON{{< /ui >}}.
+
+2. Proporcione una función de JavaScript para identificar la evaluación, el valor y el razonamiento del evaluador. El posprocesamiento le permite realizar una evaluación más compleja que simplemente usar una salida estructurada booleana, de puntuación o categórica.
+
+ La función de posprocesamiento debe devolver un objeto que contenga una **evaluación** con el valor "pass" o "fail" y, opcionalmente, cadenas de valor o razonamiento. La función debe devolver un objeto json con el siguiente formato:
+ ```
+ {
+ assessment: "pass", // "pass" | "fail" [REQUIRED],
+ value: "evaluation_label" // string [OPTIONAL],
+ reasoning: "explanation behind the assessment" // string [OPTIONAL]
+
+ }
+ ```
+ and the function signature must be `function __evalPostProcessing(input)` and the `input` is the json from the evaluator. The function below is an example of a post processing function:
+ ```
+ function __evalPostProcessing(input) {
+ /*
+ * Expected input shape (from LLM evaluator [this depends on the JSON Structured Output]):
+ * {
+ * criteria: {
+ * quality_score: { score: number (0–1), category: "excellent"|"good"|"poor", reasoning: string },
+ * toxicity: { score: number (0–1), category: "safe"|"unsafe", reasoning: string },
+ * completeness: { score: number (0–1), category: "complete"|"incomplete", reasoning: string },
+ * relevance: { score: number (0–1), category: "relevant"|"irrelevant", reasoning: string },
+ * },
+ * overall_reasoning: string // (optional) top-level summary from LLM evaluator
+ * }
+ */
+
+ const SCORE_THRESHOLD = 0.7;
+
+ // Category → pass/fail mappings per criterion
+ const CATEGORY_PASS_MAP = {
+ quality_score: ["excellent", "good"],
+ toxicity: ["safe"],
+ completeness: ["complete"],
+ relevance: ["relevant"],
+ };
+
+ const criteriaResults = {};
+ const failures = [];
+ const passes = [];
+
+ for (const [criterionName, passCategories] of Object.entries(CATEGORY_PASS_MAP)) {
+ const criterion = input?.criteria?.[criterionName];
+
+ if (!criterion) {
+ failures.push(`[${criterionName}] Missing from evaluator output.`);
+ criteriaResults[criterionName] = false;
+ continue;
+ }
+
+ const { score, category, reasoning } = criterion;
+
+ const scorePass = typeof score === "number" && score >= SCORE_THRESHOLD;
+ const categoryPass = typeof category === "string" && passCategories.includes(category.toLowerCase());
+
+ // Both score AND category must pass
+ const criterionPass = scorePass && categoryPass;
+ criteriaResults[criterionName] = criterionPass;
+
+ if (criterionPass) {
+ passes.push(`[${criterionName}] PASS — score: ${score.toFixed(2)}, category: "${category}". ${reasoning ?? ""}`);
+ } else {
+ const reasons = [];
+ if (!scorePass) reasons.push(`score ${score?.toFixed(2) ?? "N/A"} below threshold (≥${SCORE_THRESHOLD})`);
+ if (!categoryPass) reasons.push(`category "${category}" not in acceptable set [${passCategories.join(", ")}]`);
+ failures.push(`[${criterionName}] FAIL — ${reasons.join("; ")}. ${reasoning ?? ""}`);
+ }
+ }
+
+ // Determine overall assessment
+ const passed = Object.values(criteriaResults).every(Boolean);
+ const failCount = failures.length;
+
+ const assessment = passed ? "pass" : "fail";
+
+ const label = passed
+ ? "high_quality_response"
+ : failCount === 1
+ ? "minor_quality_issue"
+ : failCount === 2
+ ? "moderate_quality_issue"
+ : "low_quality_response";
+
+ const reasoningParts = [
+ passed
+ ? "All criteria passed."
+ : `${failCount} criterion/criteria failed.`,
+ ...failures,
+ ...passes,
+ input?.overall_reasoning ? `Evaluator summary: ${input.overall_reasoning}` : ""
+ ].filter(Boolean);
+
+ return {
+ assessment: assessment,
+ value: label,
+ reasoning: reasoningParts.join(" | ")
+ };
+ }
+ ```
+{{% /collapse-content %}}
+
+
+{{% collapse-content title="Resultado de búsqueda por palabra clave (Anthropic, Amazon Bedrock, AI Gateway)" level="h4" expanded="true" id="keyword-search-output" %}}
+1. Seleccione el tipo de salida {{< ui >}}Boolean{{< /ui >}}.
+ Para el Resultado de búsqueda por palabra clave, solo está disponible el tipo de salida Booleano.
+
+2. Proporcione {{< ui >}}True keywords{{< /ui >}} y {{< ui >}}False keywords{{< /ui >}} que definan cuándo el resultado de la evaluación es verdadero o falso, respectivamente.
+
+ Datadog busca en el texto de respuesta del LLM-as-a-judge sus palabras clave definidas y proporciona los resultados adecuados para la evaluación. Por esta razón, debe indicar al LLM que responda con las palabras clave que usted eligió.
+
+ Por ejemplo, si usted configura:
+
+ - {{< ui >}}True keywords{{< /ui >}}: Sí, sí
+ - {{< ui >}}False keywords{{< /ui >}}: No, no
+
+ Entonces, su prompt del sistema debe incluir algo como `Respond with "yes" or "no"`.
+
+3. Para {{< ui >}}Assessment Criteria{{< /ui >}}:
+ - Seleccione {{< ui >}}True{{< /ui >}} para marcar un resultado como "Aprobado"
+ - Seleccione {{< ui >}}False{{< /ui >}} para marcar un resultado como "Reprobado"
+
+ Esta flexibilidad le permite alinear los resultados de la evaluación con el estándar de calidad de su equipo. El mapeo de aprobado/reprobado también impulsa la automatización en Datadog Agent Observability, permitiendo que seguimientos y dashboards alerten sobre regresiones o hagan un seguimiento del estado general.
+{{% /collapse-content %}}
+
+{{< img src="llm_observability/evaluations/custom_llm_judge_5-2.png" alt="Configuración de la salida de evaluación personalizada en Structured Output, incluyendo el razonamiento y los criterios de evaluación." style="width:100%;" >}}
+
+### Defina el contexto de la evaluación: Filtrado y muestreo {#define-the-evaluation-scope-filtering-and-sampling}
+
+Los campos de tramo utilizados en las evaluaciones están limitados a 250 KB cada uno. Los campos que excedan este tamaño se truncan antes de enviarse al LLM-as-a-judge.
+
+En {{< ui >}}Evaluation Scope{{< /ui >}}, defina dónde y cómo se ejecuta su evaluación. Esto ayuda a controlar la cobertura (qué tramos o trazas se incluyen) y el costo (cuántos se muestrean).
+ - {{< ui >}}Application{{< /ui >}}: Seleccione la aplicación que desea evaluar.
+ - {{< ui >}}Evaluate On{{< /ui >}}: Elija una de las siguientes opciones:
+ - {{< ui >}}Trace{{< /ui >}}: Evalúe la traza completa, incluidos todos sus tramos, como una sola unidad. Use esto cuando la respuesta dependa del contexto en múltiples tramos (finalización del objetivo del Agent, cadenas de uso de herramientas, fidelidad de RAG). Consulte [Evaluaciones a nivel de traza][16] para ver ejemplos y detalles sobre cómo se determina la finalización de la traza.
+ - {{< ui >}}Span{{< /ui >}}: Evalúe los tramos coincidentes individualmente. Use el campo {{< ui >}}Query{{< /ui >}} para limitar a tramos específicos (por ejemplo, solo tramos raíz, solo tramos `llm`, o tramos con una etiqueta específica).
+ - {{< ui >}}Session{{< /ui >}}: Evalúe una sesión de usuario completa, incluyendo cada traza y sus tramos, como una sola unidad. Use esto cuando la respuesta dependa del contexto en múltiples trazas en la misma sesión (satisfacción del usuario, coherencia de múltiples turnos o comportamiento del usuario a lo largo del tiempo). Requiere tramos etiquetados con un `session_id`. Consulte [Evaluaciones a nivel de sesión][17] para ver ejemplos y detalles sobre cómo se determina la finalización de la sesión.
+ - {{< ui >}}Query{{< /ui >}}: (Opcional) Ingrese una consulta usando la sintaxis de consulta de Datadog para filtrar qué tramos o trazas se evalúan. Por ejemplo:
+ - `@name:agent.workflow` para filtrar por nombre de tramo
+ - `env:prod` para filtrar por etiqueta
+ - `@parent_id:undefined` para evaluar solo los tramos raíz (cuando {{< ui >}}Evaluate On{{< /ui >}} se establece en {{< ui >}}Span{{< /ui >}})
+ - `@name:agent.workflow AND env:prod` para filtrar por nombre de tramo y etiqueta
+ - {{< ui >}}Sampling Rate{{< /ui >}}: (Opcional) Aplique muestreo (por ejemplo, 10%) para controlar el costo de la evaluación.
+
+{{< img src="llm_observability/evaluations/evaluation_scope_1.png" alt="Configuración del contexto de la evaluación." style="width:100%;" >}}
+
+### Pruebe y previsualice {#test-and-preview}
+
+El panel de la derecha muestra {{< ui >}}Filtered Spans{{< /ui >}} (o trazas) correspondientes al alcance de evaluación configurado.
+
+Seleccione un tramo para mostrar los datos JSON disponibles para su uso en una evaluación. Luego, haga clic en {{< ui >}}Test Evaluation{{< /ui >}} para rellenar previamente las entradas de su evaluación con datos del tramo, y haga clic en {{< ui >}}Run{{< /ui >}} para probar.
+
+## Ver y utilizar resultados {#viewing-and-using-results}
+
+Después de {{< ui >}}Save and Publish{{< /ui >}} su evaluación, Datadog ejecuta automáticamente su evaluación en los tramos seleccionados. Alternativamente, puede {{< ui >}}Save as Draft{{< /ui >}} y editar o habilitar su evaluación más tarde.
+
+Los resultados están disponibles en todo Agent Observability casi en tiempo real para las evaluaciones publicadas. Puede encontrar sus resultados personalizados de LLM-as-a-judge para un tramo específico en la pestaña {{< ui >}}Evaluations{{< /ui >}}, junto con otras evaluaciones.
+
+{{< img src="llm_observability/evaluations/custom_llm_judge_3-2.png" alt="La pestaña Evaluaciones de una traza, que muestra los resultados de evaluaciones personalizadas junto con las evaluaciones administradas." style="width:100%;" >}}
+
+Cada resultado de evaluación incluye:
+
+- El valor evaluado (por ejemplo, `True`, `9` o `Neutral`)
+- El razonamiento (cuando está habilitado)
+- El indicador de aprobado/reprobado (según sus criterios de evaluación)
+
+Utilice la sintaxis `@evaluation..value` para consultar o visualizar los resultados.
+
+Por ejemplo:
+
+```
+@evaluation.helpfulness-check.value
+```
+
+{{< img src="llm_observability/evaluations/custom_llm_judge_4.png" alt="La visualización de trazas de Agent Observability. En el cuadro de búsqueda, el usuario ha ingresado `@evaluation.budget-guru-intent-classifier.value:budgeting_question` y los resultados se completan a continuación." style="width:100%;" >}}
+
+
+Usted puede:
+- Filtrar trazas por resultados de evaluación (ejemplo, `@evaluation.helpfulness-check.value`)
+- Filtrar por estado de evaluación de aprobado/reprobado (ejemplo, `@evaluation.helpfulness-check.assessment:fail`)
+- Utilizar los resultados de evaluación como [facets][3]
+- Ver resultados agregados en la sección Evaluation de la página Agent Observability Overview.
+- Crear [seguimientos][4] para alertar sobre cambios en el rendimiento o regresiones.
+
+## Uso en experimentos {#using-in-experiments}
+
+Para reutilizar una evaluación personalizada de LLM-as-a-judge en un [Experimento de LLM][8] local, haga referencia a ella por nombre usando `RemoteEvaluator` desde el SDK:
+
+{{< code-block lang="python" >}}
+from ddtrace.llmobs import LLMObs, RemoteEvaluator
+
+evaluator = RemoteEvaluator(eval_name="quality-assessment")
+
+experiment = LLMObs.experiment(
+ name="my-experiment",
+ task=my_task,
+ dataset=dataset,
+ evaluators=[evaluator],
+)
+experiment.run()
+{{< /code-block >}}
+
+Puede combinar `RemoteEvaluator` con otros evaluadores locales en el mismo experimento. Para el mapeo de entrada personalizado, el manejo de errores y más opciones, consulte [RemoteEvaluator][9] en la Guía para desarrolladores de evaluación.
+
+## Mejores prácticas para evaluaciones personalizadas confiables {#best-practices-for-reliable-custom-evaluations}
+
+- **Empiece poco a poco**: Apunte a un único modo de falla bien definido antes de escalar.
+- **Habilite el razonamiento** cuando necesite decisiones explicables y para mejorar la precisión en tareas de razonamiento complejas.
+- **Itere**: Ejecute, inspeccione los resultados y refine su prompt.
+- **Valide**: Verifique periódicamente la precisión del evaluador utilizando trazas muestreadas.
+- **Documente su rúbrica**: Defina claramente qué significan "Aprobado" y "Reprobado" para evitar desviaciones con el tiempo.
+- **Realinee su evaluador**: Reevalúe el prompt y los ejemplos de few-shot cuando el LLM subyacente se actualice.
+
+## Uso estimado de tokens {#estimated-token-usage}
+
+Puede hacer un seguimiento del uso de tokens de sus evaluaciones de LLM utilizando el [LLM Evaluations Token Usage dashboard][10].
+
+Si necesita más detalles, las siguientes métricas le permiten realizar un seguimiento de los recursos de LLM consumidos para potenciar las evaluaciones:
+
+- `ml_obs.estimated_usage.llm.input.tokens`
+- `ml_obs.estimated_usage.llm.output.tokens`
+- `ml_obs.estimated_usage.llm.total.tokens`
+
+Cada una de estas métricas tiene etiquetas `ml_app`, `model_server`, `model_provider`, `model_name` y `evaluation_name`, lo que le permite identificar aplicaciones, modelos y evaluaciones específicas que contribuyen a su uso.
+
+## Configure evaluaciones de LLM-as-a-judge desde la API {#configure-llm-as-a-judge-evaluations-from-the-api}
+
+Puede utilizar operaciones CRUD básicas para manipular configuraciones de evaluación administradas, después de tener la `DD_API_KEY` [clave de API][14] especificada en su entorno.
+
+ - [GET][11] configuraciones de evaluación existentes
+ - [PUT][12] configuraciones de evaluación existentes
+ - [DELETE][13] configuraciones de evaluación existentes
+
+## Lecturas adicionales {#further-reading}
+
+{{< partial name="whats-next/whats-next.html" >}}
+
+[1]: https://app.datadoghq.com/llm/evaluations
+[2]: /es/llm_observability/evaluations/custom_llm_as_a_judge_evaluations/connect_to_account
+[3]: /es/events/explorer/facets/
+[4]: /es/monitors/
+[5]: https://arxiv.org/abs/2504.00050
+[6]: /es/llm_observability/evaluations/evaluation_compatibility
+[7]: /es/llm_observability/evaluations/custom_llm_as_a_judge_evaluations/template_evaluations/
+[8]: /es/llm_observability/experiments
+[9]: /es/llm_observability/guide/evaluation_developer_guide/#using-managed-evaluators
+[10]: https://app.datadoghq.com/dash/integration/llm_evaluations_token_usage
+[11]: /es/api/latest/agent-observability/#get-a-custom-evaluator-configuration
+[12]: /es/api/latest/agent-observability/#create-or-update-a-custom-evaluator-configuration
+[13]: /es/api/latest/agent-observability/#delete-a-custom-evaluator-configuration
+[14]: /es/account_management/api-app-keys
+[15]: /es/llm_observability/evaluations/custom_llm_as_a_judge_evaluations/prompt_templating
+[16]: /es/llm_observability/evaluations/custom_llm_as_a_judge_evaluations/trace_level_evaluations
+[17]: /es/llm_observability/evaluations/custom_llm_as_a_judge_evaluations/session_level_evaluations
+[18]: https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/locations
\ No newline at end of file
diff --git a/hugo/content/es/logs/explorer/calculated_fields/formulas.md b/hugo/content/es/logs/explorer/calculated_fields/formulas.md
index f951e7db765..586bbd3b1e0 100644
--- a/hugo/content/es/logs/explorer/calculated_fields/formulas.md
+++ b/hugo/content/es/logs/explorer/calculated_fields/formulas.md
@@ -8,30 +8,29 @@ further_reading:
text: Campos calculados
title: Fórmulas
---
+## Descripción general {#overview}
-## Información general
+La fórmula (o expresión) define el valor del campo calculado para cada evento de registro. Puede hacer referencia a atributos de registro, otros campos calculados y funciones y operadores compatibles. A medida que escribe o edita una fórmula, el editor sugiere automáticamente campos, funciones y operadores relevantes.
-La fórmula (o expresión) define el valor del campo calculado para cada evento de log. Puedes hacer referencia a atributos de log, a otros campos calculados y a funciones y operadores compatibles. Al escribir o editar una fórmula, el editor sugiere automáticamente los campos, funciones y operadores pertinentes.
+## Sintaxis básica y construcciones de lenguaje {#basic-syntax-and-language-constructs}
-## Sintaxis básica y constructos lingüísticos
-
-| Constructo | Sintaxis y notación |
+| Construcción | Sintaxis y notación |
| --------------------------------------------------------------------------| ------------------------------------------------------------------------------------------------------------------------------------ |
-| Atributo reservado o etiqueta denominada `tag` | `tag` (no requiere prefijo)
Para etiquetas que contengan guiones, puedes usar un carácter de escape con una barra invertida.
Ejemplo: `ci\-job\-id` |
-| Atributo denominado `attr` | `@attr` (utiliza un prefijo `@` ) |
-| Campo calculado denominado `field` | `#field` (utiliza el prefijo `#` ) |
-| Cadena literal (comillas)
Por ejemplo, `text` o `Quoted "text"`. | `"text"`
`"Quoted \"text\""`
( Se aplica la sintaxis de búsqueda de logs)|
+| Atributo o etiqueta reservada con nombre `tag` | `tag` (no se requiere prefijo)
Para etiquetas que contienen guiones, escápelos con una barra invertida.
Ejemplo: `ci\-job\-id` |
+| Atributo con nombre `attr` | `@attr` (use un prefijo `@`) |
+| Campo calculado con nombre `field` | `#field` (use un prefijo `#`) |
+| Literal de cadena (comillas)
Por ejemplo, `text` o `Quoted "text"`. | `"text"`
`"Quoted \"text\""`
(se aplica Sintaxis de búsqueda de registros)|
| Literal numérico (número)
Por ejemplo, `ten`. | `10` |
-| Función denominada `func` con los parámetros `x` y `y` | `func(x, y)` |
+| Función con nombre `func` con parámetros `x` y `y` | `func(x, y)` |
| Operador
Por ejemplo, un operador binario `*` con operandos `x` y `y`. | `x*y` |
-## Operadores
+## Operadores {#operators}
-Los operadores disponibles por orden de precedencia:
+Los operadores disponibles en orden de precedencia:
| Operador | Descripción |
|----------|-------------|
-| `()` | Una agrupación o llamada de función |
+| `()` | Una agrupación o llamada a función |
| `!`, `NOT`, `-` | Una negación lógica o aritmética |
| `^`, `%` | Exponenciación, módulo|
| `*`, `/` | Multiplicación, división|
@@ -39,9 +38,9 @@ Los operadores disponibles por orden de precedencia:
| `<`, `<=`, `>`, `>=` | Menor que, menor o igual que, mayor que, mayor o igual que |
| `==`, `!=` | Coincide, no coincide |
| `&&`, `AND` | AND lógico |
-| `\|\|`, `O` | OR lógico |
+| `\|\|`, `OR` | OR lógico |
-## Funciones
+## Funciones {#functions}
Las funciones disponibles se clasifican de la siguiente manera:
- [Aritmética](#arithmetic)
@@ -49,157 +48,146 @@ Las funciones disponibles se clasifican de la siguiente manera:
- [Lógico](#logical)
-### Aritmética
+### Aritmética {#arithmetic}
abs(num value)
Devuelve el valor absoluto de un número.
-
-Ejemplo
+{{% collapse-content title="Ejemplo" level="h5" expanded=false %}}
| Ejemplo | Fórmula | Resultado |
|----------|-------------|---------|
-| Un evento de log tiene los siguientes atributos:
- `@client_latency` = 2
- `@server_latency` = 3 | `#discrepancy = abs(@client_latency - @server_latency)` | `#discrepancy` = 1 |
+| Un evento de registro tiene los siguientes atributos:
- `@client_latency` = 2
- `@server_latency` = 3 | `#discrepancy = abs(@client_latency - @server_latency)` | `#discrepancy` = 1 |
-
+{{% /collapse-content %}}
ceil(num value)
-Redondea el número al entero más próximo.
+Redondea el número hacia arriba al entero más cercano.
-
-Ejemplo
+{{% collapse-content title="Ejemplo" level="h5" expanded=false %}}
| Ejemplo | Fórmula | Resultado |
|----------|-------------|---------|
-| Un evento de log tiene el siguiente atributo:
`@value` = 2.2 | `#rounded_up = ceil(@value)` | `#rounded_up` = 3 |
+| Un evento de registro tiene el siguiente atributo:
`@value` = 2.2 | `#rounded_up = ceil(@value)` | `#rounded_up` = 3 |
-
+{{% /collapse-content %}}
floor(num value)
-Redondea el número al entero más próximo.
+Redondea el número hacia abajo al entero más cercano.
-
-Ejemplo
+{{% collapse-content title="Ejemplo" level="h5" expanded=false %}}
| Ejemplo | Fórmula | Resultado |
|----------|-------------|---------|
-| Un evento de log tiene el siguiente atributo:
`@value` = 9.99 | `#rounded_down = floor(@value)` | `#rounded_down` = 9 |
+| Un evento de registro tiene el siguiente atributo:
`@value` = 9.99 | `#rounded_down = floor(@value)` | `#rounded_down` = 9 |
-
+{{% /collapse-content %}}
-max(num value, [ num value, ...])
+max(num value, [ num value, …])
Encuentra el valor máximo entre un conjunto de números.
-
-Ejemplo
+{{% collapse-content title="Ejemplo" level="h5" expanded=false %}}
| Ejemplo | Fórmula | Resultado |
|----------|-------------|---------|
-| Un evento de log tiene el siguiente atributo:
`@CPU_temperatures` = [-1, 1, 5, 5] | `#highest_temp = max(@CPU_temperatures)` | `#highest_temp` = 5 |
+| Un evento de registro tiene el siguiente atributo:
`@CPU_temperatures` = [-1, 1, 5, 5] | `#highest_temp = max(@CPU_temperatures)` | `#highest_temp` = 5 |
-
+{{% /collapse-content %}}
-min(num value, [num value, ...])
+min(num value, [num value, …])
Encuentra el valor mínimo entre un conjunto de números.
-
-Ejemplo
+{{% collapse-content title="Ejemplo" level="h5" expanded=false %}}
| Ejemplo | Fórmula | Resultado |
|----------|-------------|---------|
-| Un evento de log tiene el siguiente atributo:
`@CPU_temperatures` = [-1, 1, 5, 5] | `#lowest_temp = min(@CPU_temperatures)` | `#lowest_temp` = -1 |
+| Un evento de registro tiene el siguiente atributo:
`@CPU_temperatures` = [-1, 1, 5, 5] | `#lowest_temp = min(@CPU_temperatures)` | `#lowest_temp` = -1 |
-
+{{% /collapse-content %}}
round(num value, int precision)
-Redondea un número. Opcionalmente, define cuántos decimales mantener.
+Redondea un número. Opcionalmente, defina cuántos decimales mantener.
-
-Ejemplo
+{{% collapse-content title="Ejemplo" level="h5" expanded=false %}}
| Ejemplo | Fórmula | Resultado |
|----------|-------------|---------|
-| Un evento de log tiene el siguiente atributo:
`@value` = -1234.01 | `#rounded_to_tens = round(@value, -1)` | `#rounded_to_tens` = -1230 |
+| Un evento de registro tiene el siguiente atributo:
`@value` = -1234.01 | `#rounded_to_tens = round(@value, -1)` | `#rounded_to_tens` = -1230 |
-
+{{% /collapse-content %}}
---
-### Cadena
+### Cadena {#string}
-concat(str string [str string, expr value, ...])
+concat(str cadena [str cadena, expr valor, …])
Combina varios valores en una sola cadena.
-
-Ejemplo
+{{% collapse-content title="Ejemplo" level="h5" expanded=false %}}
| Ejemplo | Fórmula | Resultado |
|----------|-------------|---------|
-| Un evento de log tiene los siguientes atributos:
- `@city` = "Paris"
- `@country` = "France" | `#region = concat(@city, ", ", @country)` | `#region` = "Paris, France" |
+| Un evento de registro tiene los siguientes atributos:
- `@city` = "Paris"
- `@country` = "France" | `#region = concat(@city, ", ", @country)` | `#region` = "Paris, France" |
-
+{{% /collapse-content %}}
-lower(str string)
+lower(str cadena)
Convierte la cadena a minúsculas.
-
-Ejemplo
+{{% collapse-content title="Ejemplo" level="h5" expanded=false %}}
| Ejemplo | Fórmula | Resultado |
|----------|-------------|---------|
-| Un evento de log tiene el siguiente atributo:
`@first_name` = "Bob" | `#lower_name = lower(@first_name)` | `#lower_name` = "bob" |
+| Un evento de registro tiene el siguiente atributo:
`@first_name` = "Bob" | `#lower_name = lower(@first_name)` | `#lower_name` = "bob" |
-
+{{% /collapse-content %}}
-left(str string, int num_chars)
+left(str cadena, int num_caracteres)
-Extrae un fragmento de texto del principio de una cadena.
+Extrae una porción de texto desde el principio de una cadena.
-
-Ejemplo
+{{% collapse-content title="Ejemplo" level="h5" expanded=false %}}
| Ejemplo | Fórmula | Resultado |
|----------|-------------|---------|
-| Un evento de log tiene el siguiente atributo:
`@price` = "USD10.50" | `#currency = left(@price, 3)` | `#currency` = "USD" |
+| Un evento de registro tiene el siguiente atributo:
`@price` = \"USD10.50\" | `#currency = left(@price, 3)` | `#currency` = \"USD\" |
-
+{{% /collapse-content %}}
-proper(str string)
+proper(str cadena)
-Convierte la cadena a mayúsculas o minúsculas.
+Convierte la cadena a formato de mayúsculas y minúsculas.
-
-Ejemplo
+{{% collapse-content title="Ejemplo" level="h5" expanded=false %}}
| Ejemplo | Fórmula | Resultado |
|----------|-------------|---------|
-| Un evento de log tiene el siguiente atributo:
`@address` = "123 main st" | `#formatted_address = proper(@address)` | `#formatted_address` = "123 Main St" |
+| Un evento de registro tiene el siguiente atributo:
`@address` = \"123 main st\" | `#formatted_address = proper(@address)` | `#formatted_address` = \"123 Main St\" |
-
+{{% /collapse-content %}}
-split_before(str string, str separator, int occurrence)
+split_before(str cadena, str separador, int ocurrencia)
-Extrae el fragmento de texto que precede a un determinado patrón en una cadena.
+Extrae la parte del texto que precede a un patrón determinado en una cadena.
-
-Ejemplo
+{{% collapse-content title="Ejemplo" level="h5" expanded=false %}}
@@ -208,7 +196,7 @@ Extrae el fragmento de texto que precede a un determinado patrón en una cadena.
| Resultado |
- Un evento de log tiene el siguiente atributo:
@url = "www.example.com/path/to/split" |
+ Un evento de registro tiene el siguiente atributo:
@url = "www.example.com/path/to/split" |
#url_extraction = split_before(@url, "/", 1) |
#url_extraction = "www.example.com/path" |
@@ -218,15 +206,14 @@ Extrae el fragmento de texto que precede a un determinado patrón en una cadena.
-
+{{% /collapse-content %}}
-split_after(str string, str separator, int occurrence)
+split_after(str cadena, str separador, int ocurrencia)
-Extrae el fragmento de texto que sigue un determinado patrón en una cadena.
+Extrae la porción de texto que sigue a un patrón determinado en una cadena.
-
-Ejemplo
+{{% collapse-content title="Ejemplo" level="h5" expanded=false %}}
@@ -235,7 +222,7 @@ Extrae el fragmento de texto que sigue un determinado patrón en una cadena.
| Resultado |
- Un evento de log tiene el siguiente atributo:
@url = "www.example.com/path/to/split" |
+ Un evento de registro tiene el siguiente atributo:
@url = "www.example.com/path/to/split" |
#url_extraction = split_after(@url, "/", 0) |
#url_extraction = "path/to/split" |
@@ -244,97 +231,90 @@ Extrae el fragmento de texto que sigue un determinado patrón en una cadena.
#url_extraction = "to/split"
|
-
+{{% /collapse-content %}}
-substring(str string, int start, int length)
+substring(str cadena, int inicio, int longitud)
-Extrae un fragmento de texto del centro de una cadena.
+Extrae una porción de texto desde el medio de una cadena.
-
-Ejemplo
+{{% collapse-content title="Ejemplo" level="h5" expanded=false %}}
| Ejemplo | Fórmula | Resultado |
|----------|-------------|---------|
-| Un evento de log tiene el siguiente atributo:
`@price` = "USD10.50" | `#dollar_value = substring(@price, 2, 2)` | `#dollar_value` = "10" |
-
+| Un evento de registro tiene el siguiente atributo:
`@price` = "USD10.50" | `#dollar_value = substring(@price, 2, 2)` | `#dollar_value` = "10" |
-
+{{% /collapse-content %}}
-right(str string, int num_chars)
+right(str cadena, int num_caracteres)
-Extrae un fragmento de texto del final de una cadena.
+Extrae una porción de texto del final de una cadena.
-
-Ejemplo
+{{% collapse-content title="Ejemplo" level="h5" expanded=false %}}
| Ejemplo | Fórmula | Resultado |
|----------|-------------|---------|
-| Un evento de log tiene el siguiente atributo:
`@price` = "USD10.50" | `#cent_value = right(@price, 2)` | `#cent_value` = "50" |
+| Un evento de registro tiene el siguiente atributo:
`@price` = "USD10.50" | `#cent_value = right(@price, 2)` | `#cent_value` = "50" |
-
+{{% /collapse-content %}}
-textjoin(str delimiter, bool ignore_empty, str string [str string, expr value, ...])
+textjoin(str delimitador, bool ignorar_vacíos, str cadena [str cadena, expr valor, …])
-Combina varios valores en una sola cadena con un delimitador intermedio.
+Combina múltiples valores en una sola cadena con un delimitador entre ellos.
-
-Ejemplo
+{{% collapse-content title="Ejemplo" level="h5" expanded=false %}}
| Ejemplo | Fórmula | Resultado |
|----------|-------------|---------|
-| Un evento de log tiene los siguientes atributos:
- `@city` = "Paris"
- `@country` = "France" | `#region = textjoin(", ", "false", @city, @country)` | `#region` = "Paris, France" |
+| Un registro de evento tiene los siguientes atributos:
- `@city` = "Paris"
- `@country` = "France" | `#region = textjoin(", ", "false", @city, @country)` | `#region` = "Paris, France" |
-
+{{% /collapse-content %}}
-upper(str string)
+upper(str cadena)
-Convierte la cadena a mayúsculas.
+Convierte una cadena a mayúsculas.
-
-Ejemplo
+{{% collapse-content title="Ejemplo" level="h5" expanded=false %}}
| Ejemplo | Fórmula | Resultado |
|----------|-------------|---------|
-| Un evento de log tiene el siguiente atributo: `@first_name` = "Bob" | `#upper_name = upper(@first_name)` | `#upper_name` = "BOB" |
+| Un registro de evento tiene el siguiente atributo: `@first_name` = "Bob" | `#upper_name = upper(@first_name)` | `#upper_name` = "BOB" |
-
+{{% /collapse-content %}}
---
-### Lógico
+### Lógico {#logical}
-if(expr condition, expr if_true, expr if_false)
+if(expr condición, expr si_verdadero, expr si_falso)
Evalúa una condición y devuelve un valor en consecuencia.
-
-Ejemplo
+{{% collapse-content title="Ejemplo" level="h5" expanded=false %}}
| Ejemplo | Fórmula | Resultado |
|----------|-------------|---------|
-| Un evento de log tiene los siguientes atributos:
- `@location` = "Paris, France"
- `@home` = "New York, USA" | `#abroad = if(@location == @home, "false", "true")` | `#abroad` = "true" |
+| Un registro de evento tiene los siguientes atributos:
- `@location` = "París, Francia"
- `@home` = "Nueva York, EE. UU." | `#abroad = if(@location == @home, "false", "true")` | `#abroad` = "true" |
-
+{{% /collapse-content %}}
-is_null(expr value)
+is_null(expr valor)
Comprueba si un atributo o expresión es nulo.
-
-Ejemplo
+{{% collapse-content title="Ejemplo" level="h5" expanded=false %}}
| Ejemplo | Fórmula | Resultado |
|----------|-------------|---------|
-| Un evento de log tiene los siguientes atributos:
- `@users_online` = 5
- `@max_capacity` = 0 | `is_null(@users_online / @max_capacity)` | "true" |
+| Un registro de evento tiene los siguientes atributos:
- `@users_online` = 5
- `@max_capacity` = 0 | `is_null(@users_online / @max_capacity)` | "true" |
-
+{{% /collapse-content %}}
-## Referencias adicionales
+## Lecturas adicionales {#further-reading}
{{< partial name="whats-next/whats-next.html" >}}
\ No newline at end of file
diff --git a/hugo/content/es/observability_pipelines/_index.md b/hugo/content/es/observability_pipelines/_index.md
index f02466b8354..619892ee06a 100644
--- a/hugo/content/es/observability_pipelines/_index.md
+++ b/hugo/content/es/observability_pipelines/_index.md
@@ -1,155 +1,180 @@
---
+description: Aprenda cómo Observability Pipelines le permite recopilar, procesar y
+ enrutar registros, métricas y trazas dentro de su propia infraestructura hacia destinos
+ como Datadog, Amazon S3, Splunk y Microsoft Sentinel.
disable_toc: false
further_reading:
-- link: /logs/log_collection/
- tag: documentación
- text: Recopilación de logs e integraciones
-- link: data_security/logs/
- tag: documentación
- text: Seguridad de los datos de Log Management
-- link: /sensitive_data_scanner/
- tag: documentación
- text: Sensitive Data Scanner
+- link: /observability_pipelines/configuration/explore_templates/
+ tag: Documentación
+ text: Configure Pipelines
+- link: /observability_pipelines/configuration/set_up_pipelines/
+ tag: Documentación
+ text: Explore casos de uso y plantillas
+- link: /observability_pipelines/configuration/install_the_worker/
+ tag: Documentación
+ text: Instale el Observability Pipelines Worker
- link: /agent/configuration/dual-shipping/#yaml-configuration
- tag: documentación
- text: Doble envío con Observability Pipelines
+ tag: Documentación
+ text: Envío dual con Observability Pipelines
- link: /observability_pipelines/guide/strategies_for_reducing_log_volume/
- tag: documentación
- text: Estrategias para reducir el volumen de logs
+ tag: Documentación
+ text: Estrategias para reducir el volumen de registros
+- link: https://learn.datadoghq.com/courses/course-getting-started-observability-pipelines
+ tag: Centro de aprendizaje
+ text: Primeros pasos con Observability Pipelines
+- link: https://www.datadoghq.com/blog/observability-pipelines-reference-tables-log-enrichment/
+ tag: Blog
+ text: Agregue contexto de actualización dinámica a los registros con tablas de referencia
+ y Observability Pipelines
+- link: https://www.datadoghq.com/blog/otel-ai-observability-pipelines-clickhouse/
+ tag: Blog
+ text: Envíe datos de OTel desde aplicaciones de IA a ClickHouse y Datadog usando
+ Observability Pipelines
- link: https://www.datadoghq.com/blog/observability-pipelines-sensitive-data-redaction/
- tag: blog
- text: Ocultar datos confidenciales de tus logs on-prem utilizando Observability
+ tag: Blog
+ text: Redacte datos confidenciales de sus registros de forma local usando Observability
Pipelines
- link: https://www.datadoghq.com/blog/observability-pipelines-dual-ship-logs/
- tag: blog
- text: Logs de doble envío con Observability Pipelines de Datadog
+ tag: Blog
+ text: Envío dual de registros con Datadog Observability Pipelines
- link: https://www.datadoghq.com/blog/observability-pipelines-log-volume-control/
- tag: blog
- text: Controlar tus volúmenes de logs con Observability Pipelines de Datadog
+ tag: Blog
+ text: Controle sus volúmenes de registros con Datadog Observability Pipelines
- link: https://www.datadoghq.com/blog/observability-pipelines-archiving/
- tag: blog
- text: Archivar tus logs con Observability Pipelines para una migración simple y
- rentable a Datadog
+ tag: Blog
+ text: Archive sus registros con Observability Pipelines para una migración sencilla
+ y asequible a Datadog
- link: https://www.datadoghq.com/blog/observability-pipelines/
tag: Blog
- text: Agregar, procesar y enrutar logs fácilmente con Observability Pipelines de
- Datadog
+ text: Agregue, procese y enrute registros fácilmente con Datadog Observability Pipelines
- link: https://www.datadoghq.com/blog/observability-pipelines-stream-logs-in-ocsf-format/
tag: Blog
- text: Transmitir logs en formato OCSF a tus proveedores de seguridad o data lakes
- preferidos con Observability Pipelines
+ text: Transmita registros en formato OCSF a sus proveedores de seguridad o lagos
+ de datos preferidos con Observability Pipelines
+- link: https://www.datadoghq.com/blog/observability-pipelines-route-logs-microsoft-sentinel/
+ tag: Blog
+ text: Simplifique su migración de SIEM a Microsoft Sentinel con Datadog Observability
+ Pipelines
+- link: https://www.datadoghq.com/blog/sled-observability-pipelines/
+ tag: Blog
+ text: Cómo las organizaciones estatales, locales y educativas pueden gestionar registros
+ de manera flexible y eficiente usando Datadog Observability Pipelines
+- link: https://www.datadoghq.com/blog/optimize-high-volume-logs/
+ tag: Blog
+ text: Cómo optimizar datos de registro de alto volumen sin comprometer la visibilidad
+- link: https://www.datadoghq.com/blog/archive-search/
+ tag: Blog
+ text: Busque en sus registros históricos de manera más eficiente con Datadog Archive
+ Search
+- link: https://www.datadoghq.com/blog/introducing-datadog-cloudprem/
+ tag: Blog
+ text: Almacene y busque registros a escala de petabytes en su propia infraestructura
+ con Datadog BYOC Logs
+- link: https://www.datadoghq.com/blog/manage-high-volume-logs-with-observability-pipeline-packs/
+ tag: Blog
+ text: Controle los costos de registros en cualquier SIEM o lago de datos utilizando
+ Packs con Observability Pipelines
+- link: https://www.datadoghq.com/blog/observability-pipelines-otel-cost-control/
+ tag: Blog
+ text: Utilice OpenTelemetry con Observability Pipelines para la recopilación de
+ registros y el control de costos neutrales respecto al proveedor
+- link: https://www.datadoghq.com/blog/observability-pipelines-mssp
+ tag: Blog
+ text: Simplifique la recopilación y agregación de registros para MSSP con Datadog
+ Observability Pipelines
+- link: https://www.datadoghq.com/blog/manage-metrics-cost-control-with-observability-pipelines
+ tag: Blog
+ text: Administre el volumen de métricas y las etiquetas en su entorno con Observability
+ Pipelines
title: Observability Pipelines
---
+## Descripción general {#overview}
-{{< site-region region="gov" >}}
-Observability Pipelines no está disponible en el sitio US1-FED Datadog.
-{{< /site-region >}}
+{{< img src="observability_pipelines/op_marketecture_06042025.png" alt="Un gráfico que muestra datos siendo agregados desde una variedad de fuentes, procesados y enriquecidos por el Observability Pipelines Worker en su propio entorno, y luego siendo dirigidos a los destinos de seguridad, análisis y almacenamiento de su elección" style="width:100%;" >}}
-
-Datadog recomienda actualizar Observability Pipelines Worker (OPW) con cada versión menor y de parche o, como mínimo, mensualmente.
Actualizar a una versión mayor de OPW y mantenerla actualizada es la única manera compatible de obtener las últimas funcionalidades, correcciones y actualizaciones de seguridad de OPW.
-
-
-## Información general
-
-{{< img src="observability_pipelines/op_marketecture_11042024.png" alt="Gráfico que muestra el agregado de datos de diferentes fuentes. Estos datos son procesados y enriquecidos por el Observability Pipelines Worker en tu propio entorno y luego son enrutados a los destinos de seguridad, análisis y almacenamiento elegidos." style="width:100%;" >}}
-
-Observability Pipelines te permite recopilar y procesar logs dentro de tu propia infraestructura, antes de enrutarlos a las integraciones aguas abajo. Utilza [plantillas] (#start-building-pipelines-with-out-of-the-box-templates) predefinidas para crear y desplegar pipelines basados en tu caso de uso.
-
-Observability Pipelines Worker es el software que se ejecuta en tu infraestructura. Agrega, procesa y enruta de forma centralizada tus logs en función de tu caso de uso. Esto significa que puedes ocultar datos confidenciales, preprocesar logs y determinar a qué destinos deben ir, antes de que los logs abandonen tu entorno.
-
-La interfaz de usuario de Observability Pipelines proporciona un plano de control para gestionar tus Observability Pipelines Workers. Desde allí puedes crear, editar y cambiar pipelines en tus Workers. También puedes habilitar monitores para tus pipelines de forma que puedas evaluar su estado.
-
-## Para empezar
+Datadog Observability Pipelines le permite recopilar y procesar {{< tooltip text="logs, metrics, and traces" tooltip="Comuníquese con su gerente de cuenta para analizar los casos de uso y los precios." >}} dentro de su propia infraestructura, y luego dirija los datos a diferentes destinos. Le brinda control sobre sus datos de observabilidad antes de que salgan de su entorno.
-Para crear un pipeline:
+Con plantillas listas para usar, puede crear canalizaciones que redacten datos confidenciales, enriquezcan datos, filtren eventos ruidosos y dirijan datos a destinos como Datadog, herramientas SIEM o almacenamiento en la nube.
-1. Ve a [Observability Pipelines][1].
-1. Selecciona una plantilla:
- - [Control del volumen de logs][2]
- - [Logs de doble envío][3]
- - [Logs divididos][4]
- - [Archivar logs en archivos de Datadog][5]
- - [Ocultamiento de datos confidenciales][6]
- - [Enriquecimiento de logs][7]
- - [Generar métricas][8]
-1. Selecciona y configura tu [fuente][9].
-1. Selecciona y configura tus [destinos][10].
-1. Configura tus [procesadores][11].
-1. Instala Observability Pipelines Worker.
-1. Activa monitores para tu pipeline.
+## Componentes clave {#key-components}
-Para obtener más información, consulta [Configurar pipelines][12].
+### Observability Pipelines Worker {#observability-pipelines-worker}
-Para ver las opciones de arranque y obtener más información sobre la configuración del Worker con Kubernetes, consulta [Configuraciones avanzadas][13].
+El Observability Pipelines Worker se ejecuta dentro de su infraestructura para agregar, procesar y dirigir datos.
-## Explorar Observability Pipelines
-
-### Crear pipelines con plantillas predefinidas
-
-{{< img src="observability_pipelines/templates_20241003.png" alt="Interfaz de usuario de Observability Pipelines que muestra seis plantillas" style="width:100%;" >}}
-
-Las [plantillas](#out-of-the-box-templates) se crean para los siguientes casos de uso:
-
-#### Control del volumen de logs
-
-Los logs sin procesar son ruidosos, y sólo algunos son útiles para una mayor búsqueda y análisis durante las investigaciones. Utiliza la plantilla Control del volumen de logs para determinar qué logs debes enviar a tu solución indexada, como una solución SIEM o de gestión de logs. Esto te ayudará a aumentar el valor de tus logs indexados y también a mantenerte dentro de tu presupuesto previsto.
-
-#### Logs de doble envío
+
+Datadog recomienda que actualice Observability Pipelines Worker (OPW) con cada versión menor y de parche, o, como mínimo, mensualmente.
Actualizar a una versión principal de OPW y mantenerla actualizada es la única forma admitida de obtener la funcionalidad, las correcciones y las actualizaciones de seguridad más recientes de OPW. Consulte
Actualizar el Worker para actualizar a la versión más reciente del Worker.
+
Para la gestión de secretos: Solo ingrese los identificadores para la URL del punto de conexión de Amazon OpenSearch y, si corresponde, el nombre de usuario y la contraseña. No ingrese los valores reales.
-{{% observability_pipelines/destination_settings/amazon_opensearch %}}
+Configure el destino de Amazon OpenSearch cuando [configure una canalización][6]. Puede configurar una canalización en la [interfaz de usuario][1], utilizando la [API][7] o con [Terraform][8]. Los pasos en esta sección se configuran en la interfaz de usuario.
-### Configurar las variables de entorno
+Después de seleccionar el destino de Amazon OpenSearch en la interfaz de usuario de la canalización:
+
+1. Ingrese el identificador para su URL de punto de conexión de Amazon OpenSearch. Si lo deja en blanco, se utiliza el [predeterminado](#secret-defaults).
+1. En el menú desplegable {{< ui >}}Mode{{< /ui >}}, seleccione {{< ui >}}Bulk{{< /ui >}} o {{< ui >}}Data streams{{< /ui >}}.
+ - {{< ui >}}Bulk{{< /ui >}} modo
+ - Utiliza la [Bulk API][4] de Amazon OpenSearch para enviar eventos por lotes directamente a un índice estándar.
+ - Elija este modo cuando desee un control directo sobre la nomenclatura de índices y la gestión del ciclo de vida. Los datos se añaden al índice que especifique, y usted es responsable de manejar los rollovers, eliminaciones y mapeos.
+ - Para configurar el modo {{< ui >}}Bulk{{< /ui >}}:
+ - En el campo {{< ui >}}Index{{< /ui >}}, ingrese opcionalmente el nombre del índice de Amazon OpenSearch. Puede usar [template syntax][3] para enrutar dinámicamente los registros a diferentes índices según campos específicos en sus registros, por ejemplo `logs-{{service}}`.
+ - {{< ui >}}Data streams{{< /ui >}} modo
+ - Uses [Amazon OpenSearch Data Streams][5] for log storage. Data streams automatically manage backing indexes and rollovers, making them ideal for timeseries log data.
+ - Choose this mode when you want Amazon OpenSearch to manage the index lifecycle for you. Data streams ensures smooth rollovers, Index Lifecycle Management (ILM) compatibility, and optimized handling of time-based data.
+ - To configure {{< ui >}}Data streams{{< /ui >}} modo, opcionalmente defina el nombre del flujo de datos (el predeterminado es `logs-generic-default`) by entering the following information:
+ - In the {{< ui >}}Type{{< /ui >}} campo, ingrese la categoría de los datos que se están ingiriendo, por ejemplo `logs`.
+ - In the {{< ui >}}Dataset{{< /ui >}} campo, especifique el formato o la fuente de datos que describe la estructura, por ejemplo `apache`.
+ - In the {{< ui >}}Namespace{{< /ui >}} campo, ingrese la agrupación para organizar sus flujos de datos, por ejemplo `production`.
+ - You can use [template syntax][3] for the {{< ui >}}Type{{< /ui >}}, {{< ui >}}Dataset{{< /ui >}} y {{< ui >}}Namespace{{< /ui >}} campos para construir dinámicamente el nombre del flujo de datos según campos específicos en sus registros.
+ - In the UI, there is a preview of the data stream name you configured. With the above example inputs, the data stream name that the Worker writes to is `logs-apache-production`.
+1. Opcionalmente, ingrese el nombre del índice de Amazon OpenSearch. Consulte [template syntax][3] si desea enrutar registros a diferentes índices según campos específicos en sus registros.
+1. Seleccione una estrategia de autenticación, {{< ui >}}Basic{{< /ui >}} o {{< ui >}}AWS{{< /ui >}}. Si seleccionó:
+ - {{< ui >}}Basic{{< /ui >}}:
+ - Ingrese el identificador de su nombre de usuario de Amazon OpenSearch. Si lo deja en blanco, se usa el [predeterminado](#secret-defaults).
+ - Ingrese el identificador de su contraseña de Amazon OpenSearch. Si lo deja en blanco, se usa el [predeterminado](#secret-defaults).
+ - {{< ui >}}AWS{{< /ui >}}:
+ 1. Ingrese la región de AWS.
+ 1. (Opcional) Seleccione una opción de autenticación de AWS. La opción {{< ui >}}Assume role{{< /ui >}} solo debe usarse si el usuario o rol que creó anteriormente necesita asumir un rol diferente para acceder al recurso de AWS específico y ese permiso debe definirse explícitamente.
Si selecciona {{< ui >}}Assume role{{< /ui >}}:
+ 1. Ingrese el ARN del rol de IAM que desea asumir.
+ 1. Opcionalmente, ingrese el nombre de sesión del rol asumido y el ID externo.
+
+{{% observability_pipelines/secrets_env_var_note %}}
+
+#### Búfer opcional {#optional-buffering}
+
+{{% observability_pipelines/destination_buffer %}}
+
+## Valores predeterminados de secretos {#secret-defaults}
+
+{{% observability_pipelines/set_secrets_intro %}}
+
+{{< tabs >}}
+{{% tab "Gestión de secretos" %}}
+
+- Identificador de URL del punto de conexión de Amazon OpenSearch:
+ - El identificador predeterminado es `DESTINATION_AMAZON_OPENSEARCH_ENDPOINT_URL`.
+- Identificador de nombre de usuario de autenticación de Amazon OpenSearch:
+ - El identificador predeterminado es `DESTINATION_AMAZON_OPENSEARCH_USERNAME`.
+- Identificador de contraseña de autenticación de Amazon OpenSearch:
+ - El identificador predeterminado es `DESTINATION_AMAZON_OPENSEARCH_PASSWORD`.
+
+{{% /tab %}}
+
+{{% tab "Variables de entorno" %}}
{{% observability_pipelines/configure_existing_pipelines/destination_env_vars/amazon_opensearch %}}
-## Cómo funciona el destino
+{{% /tab %}}
+{{< /tabs >}}
+
+## Métricas de estado {#health-metrics}
+
+Para [métricas de componente][9] y [métricas de búfer de destino][10] emitidas por todos los destinos, consulte la documentación de [Pipelines Usage Metrics][11]. Para filtrar o agrupar por métricas de destino de Elasticsearch, use la etiqueta `component_type:elasticsearch`.
+
+## Cómo funciona el destino {#how-the-destination-works}
-### Procesamiento de eventos por lotes
+### Procesamiento por lotes de eventos {#event-batching}
-Un lote de eventos se descarga cuando se cumple uno de estos parámetros. Consulta [procesamiento de eventos por lotes][2] para obtener más información.
+Un lote de eventos se envía cuando se cumple uno de estos parámetros. Consulte [Procesamiento por lotes de eventos de destinos][2] para obtener más información.
-| Eventos máximos | Bytes máximos | Tiempo de espera (segundos) |
-|----------------|-----------------|---------------------|
-| Ninguno | 10.000.000 | 1 |
+| Máximo de eventos | Tamaño máximo (MB) | Tiempo de espera (segundos) |
+|----------------|-------------------|---------------------|
+| Ninguno | 10 | 1 |
[1]: https://app.datadoghq.com/observability-pipelines
-[2]: /es/observability_pipelines/destinations/#event-batching
\ No newline at end of file
+[2]: /es/observability_pipelines/destinations/#event-batching
+[3]: /es/observability_pipelines/destinations/#template-syntax
+[4]: https://docs.aws.amazon.com/opensearch-service/latest/developerguide/gsgupload-data.html
+[5]: https://docs.aws.amazon.com/opensearch-service/latest/developerguide/data-streams.html
+[6]: /es/observability_pipelines/configuration/set_up_pipelines/
+[7]: /es/api/latest/observability-pipelines/
+[8]: https://registry.terraform.io/providers/datadog/datadog/latest/docs/resources/observability_pipeline
+[9]: /es/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#component-metrics
+[10]: /es/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#destination-buffer-metrics
+[11]: /es/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/
\ No newline at end of file
diff --git a/hugo/content/es/observability_pipelines/destinations/azure_storage.md b/hugo/content/es/observability_pipelines/destinations/azure_storage.md
index c1d8b8a05ed..850f9b62561 100644
--- a/hugo/content/es/observability_pipelines/destinations/azure_storage.md
+++ b/hugo/content/es/observability_pipelines/destinations/azure_storage.md
@@ -1,55 +1,138 @@
---
+description: Aprenda a enviar registros a un contenedor de Azure Storage, opcionalmente
+ para archivado y rehidratación en Datadog.
disable_toc: false
products:
- icon: logs
- name: Logs
-title: Destino Azure Storage
+ name: Registros
+ url: /observability_pipelines/configuration/?tab=logs#pipeline-types
+title: Destino de Azure Storage
---
-
{{< product-availability >}}
-Utiliza el destino Azure Storage para enviar logs a un bucket de Azure Storage. Si deseas enviar logs a Azure Storage para [archivado][1] y [rehidratación][2], debes [configurar archivos de logs](#configure-log-archives). Si no deseas rehidratar los logs en Datadog, pase a [Configurar el destino para tu pipeline](#configure-the-destination-for-your-pipeline).
+## Descripción general {#overview}
+
+Utilice el destino de Azure Storage para enviar registros a un contenedor de Azure Storage. Si desea enviar registros a Azure Storage para [archivado][1] y [rehidratación][2], debe [configurar Archivos de registro](#configure-log-archives). Si no desea rehidratar registros en Datadog, pase a [Configurar el destino para su canalización](#set-up-the-destination-for-your-pipeline).
+
+## Configurar Archivos de registro {#configure-log-archives}
+
+Este paso solo es necesario si desea enviar registros a Azure Storage en un formato rehidratable por Datadog para [archivado][1] y [rehidratación][2], y aún no tiene un Datadog Log Archive configurado para Observability Pipelines. Si ya tiene un Datadog Log Archive configurado o no desea rehidratar registros en Datadog, pase a [Configurar el destino para su canalización](#set-up-the-destination-for-your-pipeline).
+
+Necesita tener instalada la [integración de Azure][3] de Datadog para configurar Datadog Log Archives.
+
+#### Cree una cuenta de almacenamiento {#create-a-storage-account}
+
+Cree una [cuenta de almacenamiento de Azure][13] si aún no tiene una.
+
+1. Navegue a [Cuentas de almacenamiento][14].
+1. Haga clic en **Create**.
+1. Seleccione el nombre de la suscripción y el nombre del recurso que desea utilizar.
+1. Ingrese un nombre para su cuenta de almacenamiento.
+1. Seleccione una región en el menú desplegable.
+1. Seleccione el tipo de cuenta de rendimiento **Estándar** o **Premium**.
+1. Haga clic en **Next**.
+1. En la sección **Blob storage**, seleccione **Hot** o **Cool**.
+1. Haga clic en **Review + create**.
+
+#### Cree un contenedor de almacenamiento {#create-a-storage-bucket}
+
+1. En su cuenta de almacenamiento, haga clic en **Contenedores** en **Almacenamiento de datos** en el menú de navegación izquierdo.
+1. Haga clic en **+ Container** en la parte superior para crear un contenedor.
+1. Ingrese un nombre para el nuevo contenedor. Este nombre se utiliza más adelante cuando configura el destino de Azure Storage de Observability Pipelines.
+
+**Nota**: No establezca [políticas de inmutabilidad][15] porque es posible que los datos más recientes deban sobrescribirse en casos excepcionales (normalmente cuando hay un tiempo de espera).
+
+#### Conecte el contenedor de Azure a Datadog Log Archives {#connect-the-azure-container-to-datadog-log-archives}
+
+1. Navegue a [Log Forwarding][16] de Datadog.
+1. Haga clic en **New archive**.
+1. Ingrese un nombre descriptivo para el archive.
+1. Agregue una consulta que filtre todos los registros que pasan por las canalizaciones de registros para que ninguno de esos registros vaya a este archivo. Por ejemplo, agregue la consulta `observability_pipelines_read_only_archive`, asumiendo que ningún registro que pasa por la canalización tiene esa etiqueta agregada.
+1. Seleccione **Azure Storage**.
+1. Seleccione el inquilino y el cliente de Azure en los que se encuentra su cuenta de almacenamiento.
+1. Ingrese el nombre de la cuenta de almacenamiento.
+1. Ingrese el nombre del contenedor que creó anteriormente.
+1. Opcionalmente, ingrese una ruta.
+1. Opcionalmente, establezca permisos, agregue etiquetas y defina el tamaño máximo de escaneo para la rehidratación. Consulte [Configuración avanzada][17] para obtener más información.
+1. Haga clic en **Guardar**.
+
+Consulte la [documentación de Archivos de registro][1] para obtener información adicional.
-## Configurar archivos de logs
+## Configure el destino para su canalización {#set-up-the-destination-for-your-pipeline}
-Este step (UI) / paso (generic) solo es necesario si deseas enviar logs a Azure Storage en formato rehidratable de Datadog para [archivado][1] y [rehidratación][2] y aún no tienes un archivo de logs de Datadog configurado para Observability Pipelines. Si ya tienes un archivo de logs de Datadog configurado o no deseas rehidratar los logs en Datadog, ve a [Configurar el destino para tu pipeline](#set-up-the-destination-for-your-supipeline).
+Para la gestión de secretos: Solo ingrese el identificador de la cadena de conexión de Azure. No ingrese el valor real.
-Necesitas tener la [integración de Azure][3] de Datadog instalada para configurar archivos de logs de Datadog.
+Configure el destino de Azure Storage cuando [configure una canalización][4]. Puede configurar una canalización en la [UI][7], usando la [API][8] o con [Terraform][9]. Los pasos en esta sección se configuran en la UI.
-{{% observability_pipelines/configure_log_archive/azure_storage/instructions %}}
+Después de seleccionar el destino de Azure Storage en la UI de la canalización:
-## Configurar el destino de tu pipeline
+1. Ingrese el identificador de su cadena de conexión de Azure. Si lo deja en blanco, se utiliza el [default](#secret-defaults).
+1. Ingrese el nombre del contenedor de Azure que creó anteriormente.
-Configura el destino de Azure Storage y tus variables de entorno cuando [configures un pipeline de logs de archivo][4]. La siguiente información se configura en la interfaz de usuario de pipelines.
+{{% observability_pipelines/secrets_env_var_note %}}
-1. Introduce el nombre del contenedor Azure que creaste anteriormente.
-1. Si lo deseas, introduce un prefijo.
- - Los prefijos son útiles para particionar objetos. Por ejemplo, puedes utilizar un prefijo como clave de objeto para almacenar objetos en un directorio concreto. Si se utiliza un prefijo con este fin, debe terminar en `/` para que actúe como una ruta de directorio; no se añade automáticamente un `/` al final.
- - Consulta [sintaxis de plantillas][6] si deseas dirigir los logs a diferentes claves de objeto en función de campos específicos de tus logs.
- - **Nota**: Datadog recomienda empezar los prefijos con el nombre del directorio y sin barra oblicua (`/`). Por ejemplo, `app-logs/` o `service-logs/`.
-1. Opcionalmente, activa el interruptor para activar **Buffering Options** (Opciones de almacenamiento en búfer).
**Nota**: Las opciones de almacenamiento en búfer están en vista previa. Ponte en contacto con tu gestor de cuenta para solicitar acceso.
- - Si se deja desactivado, el tamaño máximo del búfer es de 500 eventos.
- - Si está activado:
- 1. Selecciona el tipo de búfer que deseas configurar (**Memoria** o **Disco**).
- 1. Introduce el tamaño del búfer y selecciona la unidad.
+### Configuración opcional {#optional-settings}
-### Configurar las variables de entorno
+#### Prefijo para aplicar a todos los objetos clave {#prefix-to-apply-to-all-key-objects}
+
+Ingrese un prefijo que desee aplicar a todos los objetos clave.
+
+- Los prefijos son útiles para particionar objetos. Por ejemplo, puede usar un prefijo como clave de objeto para almacenar objetos en un directorio en particular. Si usa un prefijo para este propósito, debe terminar en `/` para actuar como una ruta de directorio; una `/` al final no se agrega automáticamente.
+- Consulte la [sintaxis de plantilla][6] si desea enrutar registros a diferentes claves de objeto según campos específicos en sus registros.
+ - **Nota**: Datadog recomienda que comience sus prefijos con el nombre del directorio y sin una barra diagonal inicial (`/`). Por ejemplo, `app-logs/` o `service-logs/`.
+
+#### Buffering{#buffering}
+
+{{% observability_pipelines/destination_buffer %}}
+
+## Valores predeterminados de secretos {#secret-defaults}
+
+{{% observability_pipelines/set_secrets_intro %}}
+
+{{< tabs >}}
+{{% tab "Gestión de secretos" %}}
+
+- Identificador de cadena de conexión de Azure:
+ - Hace referencia a la cadena de conexión que le da al Worker acceso a su contenedor de Azure Storage.
+ - El identificador predeterminado es `DESTINATION_DATADOG_ARCHIVES_AZURE_BLOB_CONNECTION_STRING`.
+
+{{% /tab %}}
+
+{{% tab "Variables de entorno" %}}
{{% observability_pipelines/configure_existing_pipelines/destination_env_vars/datadog_archives_azure_storage %}}
-## Cómo funciona el destino
+{{% /tab %}}
+{{< /tabs >}}
+
+## Métricas de salud{#health-metrics}
+
+Para [métricas de componente][10] y [métricas de búfer de destino][11] emitidas por todos los destinos, consulte la documentación de [métricas de uso de Pipelines][12]. Para filtrar o agrupar por métricas de destino de Azure Storage, utilice la etiqueta `component_type:datadog_archives_azure_blob`.
+
+## Cómo funciona el destino {#how-the-destination-works}
-### Procesamiento de eventos por lotes
+### Procesamiento por lotes de eventos {#event-batching}
-Un lote de eventos se descarga cuando se cumple uno de estos parámetros. Consulta [lote de eventos][5] para obtener más información.
+Un lote de eventos se vacía cuando se cumple uno de estos parámetros. Consulte [Destinations event batching][5] para obtener más información.
-| Eventos máximos | Bytes máximos | Tiempo de espera (segundos) |
-|----------------| ----------------| --------------------|
-| Ninguno | 100,000,000 | 900 |
+| Maximum Events | Maximum Size (MB) | Timeout (seconds) |
+|----------------|-------------------|---------------------|
+| None | 100 | 900 |
[1]: /es/logs/log_configuration/archives/
[2]: /es/logs/log_configuration/rehydrating/
[3]: /es/integrations/azure/#setup
-[4]: /es/observability_pipelines/configuration/explore_templates/?tab=logs#archive-logs
+[4]: /es/observability_pipelines/configuration/set_up_pipelines/
[5]: /es/observability_pipelines/destinations/#event-batching
-[6]: /es/observability_pipelines/destinations/#template-syntax
\ No newline at end of file
+[6]: /es/observability_pipelines/destinations/#template-syntax
+[7]: https://app.datadoghq.com/observability-pipelines
+[8]: /es/api/latest/observability-pipelines/
+[9]: https://registry.terraform.io/providers/datadog/datadog/latest/docs/resources/observability_pipeline
+[10]: /es/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#component-metrics
+[11]: /es/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#destination-buffer-metrics
+[12]: /es/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/
+[13]: https://learn.microsoft.com/en-us/azure/storage/common/storage-account-create?tabs=azure-portal
+[14]: https://portal.azure.com/#browse/Microsoft.Storage%2FStorageAccounts
+[15]: https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blob-immutability-policies-manage
+[16]: https://app.datadoghq.com/logs/pipelines/log-forwarding
+[17]: /es/logs/log_configuration/archives/?tab=awss3#advanced-settings
\ No newline at end of file
diff --git a/hugo/content/es/observability_pipelines/destinations/datadog_apm.md b/hugo/content/es/observability_pipelines/destinations/datadog_apm.md
deleted file mode 100644
index c9d2657c109..00000000000
--- a/hugo/content/es/observability_pipelines/destinations/datadog_apm.md
+++ /dev/null
@@ -1,62 +0,0 @@
----
-description: Aprenda a enviar trazas a Datadog utilizando el Observability Pipelines
- Worker.
-disable_toc: false
-products:
-- icon: apm
- name: Trazas
- url: /observability_pipelines/configuration/?tab=traces#pipeline-types
-title: Destino de Datadog APM
----
-{{< product-availability >}}
-
-## Descripción general {#overview}
-
-Utilice Observability Pipelines' {{< tooltip text="Datadog APM destination" tooltip="Comuníquese con su administrador de cuenta para solicitar acceso." >}} para enviar trazas a Datadog.
-
-## Configuración {#setup}
-
-Configure el destino de Datadog APM cuando [configure una canalización][1] en la interfaz de usuario.
-
-### Almacenamiento en búfer opcional {#optional-buffering}
-
-{{% observability_pipelines/destination_buffer %}}
-
-## Valores predeterminados de secretos {#secret-defaults}
-
-{{% observability_pipelines/set_secrets_intro %}}
-
-{{< tabs >}}
-{{% tab "Gestión de secretos" %}}
-
-No hay identificadores de secreto para este destino.
-
-{{% /tab %}}
-
-{{% tab "Variables de entorno" %}}
-
-{{% observability_pipelines/configure_existing_pipelines/destination_env_vars/datadog %}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## AWS PrivateLink {#aws-privatelink}
-
-Para enviar trazas desde Observability Pipelines a Datadog utilizando AWS PrivateLink, consulte [Conectarse a Datadog a través de AWS PrivateLink][7] para obtener instrucciones de configuración. Los dos puntos de conexión que necesita configurar son:
-
-- Trazas: {{< region-param key=traces_endpoint_private_link code="true" >}}
-- Remote Configuration: {{< region-param key=remote_config_endpoint_private_link code="true" >}}
-
-**Nota**: El punto de conexión `obpipeline-intake.datadoghq.com` se utiliza para Live Capture y no está disponible como punto de conexión de PrivateLink.
-
-## Métricas de salud {#health-metrics}
-
-Consulte [Métricas de componentes][5] y [Métricas de búfer de destino][6] para obtener más información sobre las métricas emitidas por todos los destinos.
-
-[1]: /es/observability_pipelines/configuration/set_up_pipelines/
-[2]: https://app.datadoghq.com/observability-pipelines
-[3]: /es/api/latest/observability-pipelines/
-[4]: https://registry.terraform.io/providers/datadog/datadog/latest/docs/resources/observability_pipeline
-[5]: /es/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#component-metrics
-[6]: /es/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/?tab=destinations#buffer
-[7]: /es/agent/guide/private-link/?tab=crossregionprivatelinkendpoints
\ No newline at end of file
diff --git a/hugo/content/es/observability_pipelines/destinations/datadog_archives.md b/hugo/content/es/observability_pipelines/destinations/datadog_archives.md
new file mode 100644
index 00000000000..37afb7290a4
--- /dev/null
+++ b/hugo/content/es/observability_pipelines/destinations/datadog_archives.md
@@ -0,0 +1,218 @@
+---
+description: Aprenda a enviar registros a Amazon S3 en formato rehidratable de Datadog
+ para archivado y rehidratación.
+disable_toc: false
+products:
+- icon: logs
+ name: Registros
+ url: /observability_pipelines/configuration/?tab=logs#pipeline-types
+title: Destino de Datadog Archives
+---
+{{< product-availability >}}
+
+## Descripción general {#overview}
+
+Use el destino de Datadog Archives para enviar registros a Amazon S3 para [archivado][1] en formato rehidratable de Datadog. Luego puede consultar estos registros con [Archive Search][16]. Use el modo {{< ui >}}Search & Rehydration{{< /ui >}} de Archive Search cuando necesite volver a indexar los resultados para obtener acceso completo a la plataforma.
+
+**Notas**:
+- El destino de Datadog Archives comprime los registros usando gzip.
+- Use el destino de [Amazon S3][12] si desea enviar sus registros a Amazon S3 en formato JSON o Parquet.
+
+También puede [enviar registros a Snowflake usando el destino de Datadog Archives](#route-logs-to-snowflake-using-the-datadog-archives-destination).
+
+## Requisitos previos {#prerequisites}
+
+Para usar el destino de Datadog Archives, debe instalar la [integración de AWS][3] de Datadog para poder configurar [Datadog Log Archives](#configure-log-archives).
+
+## Configurar Log Archives {#configure-log-archives}
+
+Si ya tiene configurados Datadog Log Archives, vaya a [Configurar el destino para su canalización](#set-up-the-destination-for-your-pipeline).
+
+{{% observability_pipelines/configure_log_archive/amazon_s3/instructions %}}
+
+### Configure una política de IAM que permita a los Workers escribir en el bucket de S3 {#set-up-an-iam-policy-that-allows-workers-to-write-to-the-s3-bucket}
+
+1. Navegue a la [consola de IAM][11].
+1. Seleccione **Políticas** en el menú del lado izquierdo.
+1. Haga clic en **Crear política**.
+1. Haga clic en **JSON** en la sección **Especificar permisos**.
+1. Copie la siguiente política y péguela en el **Editor de políticas**. Reemplace `` y `/` con la información del bucket de S3 que creó en la sección anterior.
+ ```json
+ {
+ "Version": "2012-10-17",
+ "Statement": [
+ {
+ "Sid": "DatadogUploadAndRehydrateLogArchives",
+ "Effect": "Allow",
+ "Action": ["s3:PutObject", "s3:GetObject"],
+ "Resource": "arn:aws:s3::://*"
+ },
+ {
+ "Sid": "DatadogRehydrateLogArchivesListBucket",
+ "Effect": "Allow",
+ "Action": "s3:ListBucket",
+ "Resource": "arn:aws:s3:::"
+ }
+ ]
+ }
+ ```
+1. Haga clic en **Next**.
+1. Ingrese un nombre descriptivo para la política.
+1. Opcionalmente, agregue etiquetas.
+1. Haga clic en **Create policy**.
+
+{{< tabs >}}
+{{% tab "Docker" %}}
+
+{{% observability_pipelines/configure_log_archive/amazon_s3/docker %}}
+
+{{% /tab %}}
+{{% tab "Amazon EKS" %}}
+
+{{% observability_pipelines/configure_log_archive/amazon_s3/amazon_eks %}}
+
+{{% /tab %}}
+{{% tab "Linux (APT)" %}}
+
+{{% observability_pipelines/configure_log_archive/amazon_s3/linux_apt %}}
+
+{{% /tab %}}
+{{% tab "Linux (RPM)" %}}
+
+{{% observability_pipelines/configure_log_archive/amazon_s3/linux_rpm %}}
+
+{{% /tab %}}
+{{< /tabs >}}
+
+### Conecte el bucket de S3 a Datadog Log Archives {#connect-the-s3-bucket-to-datadog-log-archives}
+
+1. Vaya a Datadog [Log Forwarding][17].
+1. Haga clic en **Nuevo archivo**.
+1. Ingrese un nombre descriptivo para el archivo.
+1. Agregue una consulta que filtre todos los registros que pasan por los pipelines para que ninguno de esos registros vaya a este archive. Por ejemplo, agregue la consulta `observability_pipelines_read_only_archive`, suponiendo que a ningún registro que pase por el pipeline se le haya agregado esa etiqueta.
+1. Seleccione **AWS S3**.
+1. Seleccione la cuenta de AWS en la que se encuentra su bucket.
+1. Ingrese el nombre del bucket de S3.
+1. Opcionalmente, ingrese una ruta.
+1. Marque la declaración de confirmación.
+1. Opcionalmente, agregue etiquetas y defina el tamaño máximo de escaneo para la rehidratación. Consulte [Configuración avanzada][18] para obtener más información.
+1. Haga clic en **Save**.
+
+Consulte la [Log Archives documentation][1] para obtener información adicional.
+
+## Configure el destino para su pipeline {#set-up-the-destination-for-your-pipeline}
+
+Configure el destino de Datadog Archives cuando [set up an Archive Logs pipeline][4]. Puede configurar un pipeline en la [UI][13], usando la [API][14] o con [Terraform][15]. Los pasos en esta sección se configuran en la UI.
+
+Después de seleccionar el destino de Datadog Archives en la UI del pipeline:
+
+1. Ingrese el nombre de su bucket de S3. Si configuró Log Archives, es el nombre del bucket que creó anteriormente.
+1. Ingrese la región de AWS en la que se encuentra el bucket de S3.
+1. Ingrese el prefijo de clave.
+ - Los prefijos son útiles para particionar objetos. Por ejemplo, puede usar un prefijo como clave de objeto para almacenar objetos en un directorio en particular. Si usa un prefijo para este propósito, debe terminar en `/` para actuar como una ruta de directorio; no se agrega automáticamente una `/` al final.
+ - Consulte la [sintaxis de plantilla][8] si desea enrutar logs a diferentes claves de objeto según campos específicos en sus logs.
+ - **Nota**: Datadog recomienda que comience sus prefijos con el nombre del directorio y sin una barra diagonal inicial (`/`). Por ejemplo, `app-logs/` o `service-logs/`.
+1. Seleccione la clase de almacenamiento para su bucket de S3 en el menú desplegable {{< ui >}}Storage Class{{< /ui >}}. Si va a archivar y rehidratar sus logs:
+ - **Nota**: La rehidratación solo admite las siguientes [clases de almacenamiento][9]:
+ - Estándar
+ - Intelligent-Tiering, solo si [los niveles de acceso de archivo asíncronos opcionales][10] están ambos deshabilitados.
+ - Standard-IA
+ - One Zone-IA
+ - Si desea rehidratar desde archivos en otra clase de almacenamiento, primero debe moverlos a una de las clases de almacenamiento admitidas anteriormente.
+ - Consulte la sección [Ejemplo de configuración de destino y archivo de registros](#example-destination-and-log-archive-setup) de esta página para saber cómo configurar su Archivo de registros según la configuración de su destino de Amazon S3.
+
+### Configuración opcional {#optional-settings}
+
+#### Autenticación de AWS {#aws-authentication}
+
+Seleccione una opción de autenticación de AWS. Si solo está utilizando el [usuario o rol que creó anteriormente](#set-up-an-iam-policy-that-allows-workers-to-write-to-the-s3-bucket) para la autenticación, no seleccione {{< ui >}}Assume role{{< /ui >}}. Seleccione {{< ui >}}Assume role{{< /ui >}} solo si el usuario o rol que creó anteriormente necesita asumir un rol diferente para acceder al recurso de AWS. Los permisos del rol asumido deben estar definidos explícitamente.
Si selecciona {{< ui >}}Assume role{{< /ui >}}:
+1. Ingrese el ARN del rol de IAM que desea asumir.
+ - **Nota:** El [usuario o rol que creó anteriormente](#set-up-an-iam-policy-that-allows-workers-to-write-to-the-s3-bucket) debe tener permiso para asumir este rol para que el Worker pueda autenticarse con AWS.
+1. (Opcional) Ingrese el nombre de la sesión del rol asumido y el ID externo.
+
+#### Buffering {#buffering}
+
+{{% observability_pipelines/destination_buffer %}}
+
+### Example destination and Log Archive setup {#example-destination-and-log-archive-setup}
+
+Si ingresa los siguientes valores para su destino de Datadog Archives:
+- S3 Bucket Name: `test-op-bucket`
+- Prefix to apply to all object keys: `op-logs`
+- Storage class for the created objects: `Standard`
+
+{{< img src="observability_pipelines/setup/amazon_s3_destination.png" alt="La configuración de destino de Datadog Archives con los valores de ejemplo" style="width:40%;" >}}
+
+Entonces, estos son los valores que debe ingresar para configurar el bucket de S3 para Log Archives:
+
+- S3 bucket: `test-op-bucket`
+- Path: `op-logs`
+- Storage class: `Standard`
+
+{{< img src="observability_pipelines/setup/amazon_s3_archive.png" alt="La configuración de archivo de registros con los valores de ejemplo" style="width:70%;" >}}
+
+## Secret defaults {#secret-defaults}
+
+{{% observability_pipelines/set_secrets_intro %}}
+
+{{< tabs >}}
+{{% tab "Secrets Management" %}}
+
+There are no secret identifiers to configure.
+
+{{% /tab %}}
+
+{{% tab "Environment Variables" %}}
+
+{{% observability_pipelines/destination_env_vars/datadog_archives_amazon_s3 %}}
+
+{{% /tab %}}
+{{< /tabs >}}
+
+## Route registros to Snowflake using the Datadog Archives destination {#route-logs-to-snowflake-using-the-datadog-archives-destination}
+
+Puede enrutar registros desde Observability Pipelines a Snowflake usando el destino de Datadog Archives configurando Snowpipe en Snowflake para ingerir automáticamente esos registros. Snowpipe monitorea continuamente su bucket de S3 en busca de archivos nuevos y los ingiere automáticamente en sus tablas de Snowflake, lo que garantiza la disponibilidad de datos casi en tiempo real para análisis o procesamiento posterior. Cuando los registros son recopilados por Observability Pipelines, se escriben en un bucket de S3. Para configurar esto:
+1. Configure [Log Archives](#configure-log-archives).
+1. [Set up a pipeline][5] to use Datadog Archives as the log destination. Use the configuration detailed in [Set up the destination for your pipeline](#set-up-the-destination-for-your-pipeline).
+1. Configure Snowpipe en Snowflake. Consulte [Automatización de Snowpipe para Amazon S3][6] para obtener instrucciones.
+
+## Cómo funciona el destino {#how-the-destination-works}
+
+### AWS Authentication {#aws-authentication-1}
+
+{{% observability_pipelines/aws_authentication/instructions %}}
+
+#### Permissions {#permissions}
+
+El Observability Pipelines Worker requiere estos permisos de política para enviar registros a Amazon S3:
+
+- `s3:ListBucket`
+- `s3:PutObject`
+- `s3:GetObject`
+
+### Event batching {#event-batching}
+
+Un lote de eventos se vacía cuando se cumple uno de estos parámetros. See [Destinations event batching][7] for more information.
+
+| Maximum Events | Maximum Size (MB) | Timeout (seconds) |
+|----------------|-------------------|---------------------|
+| None | 100 | 900 |
+
+[1]: /es/logs/log_configuration/archives/
+[2]: /es/logs/log_configuration/rehydrating/
+[3]: /es/integrations/amazon_web_services/#setup
+[4]: /es/observability_pipelines/configuration/explore_templates/?tab=logs#archive-logs
+[5]: /es/observability_pipelines/configuration/set_up_pipelines/
+[6]: https://docs.snowflake.com/en/user-guide/data-load-snowpipe-auto-s3
+[7]: /es/observability_pipelines/destinations/#event-batching
+[8]: /es/observability_pipelines/destinations/#template-syntax
+[9]: /es/logs/log_configuration/archives/?tab=awss3#storage-class
+[10]: https://aws.amazon.com/s3/storage-classes/intelligent-tiering/
+[11]: https://console.aws.amazon.com/iam/
+[12]: /es/observability_pipelines/destinations/amazon_s3/
+[13]: https://app.datadoghq.com/observability-pipelines
+[14]: /es/api/latest/observability-pipelines/
+[16]: /es/logs/explorer/archive_search/
+[15]: https://registry.terraform.io/providers/datadog/datadog/latest/docs/resources/observability_pipeline
+[17]: https://app.datadoghq.com/logs/pipelines/log-forwarding
+[18]: /es/logs/log_configuration/archives/?tab=awss3#advanced-settings
\ No newline at end of file
diff --git a/hugo/content/es/observability_pipelines/destinations/datadog_logs.md b/hugo/content/es/observability_pipelines/destinations/datadog_logs.md
index 125f851c361..6ac102ce48e 100644
--- a/hugo/content/es/observability_pipelines/destinations/datadog_logs.md
+++ b/hugo/content/es/observability_pipelines/destinations/datadog_logs.md
@@ -1,70 +1,210 @@
---
+description: Aprenda a enviar registros a Datadog Log Management usando el Observability
+ Pipelines Worker.
disable_toc: false
products:
- icon: logs
- name: Logs
+ name: Registros
url: /observability_pipelines/configuration/?tab=logs#pipeline-types
-title: Destino de logs de Datadog
+title: Destino Datadog Logs
---
-
{{< product-availability >}}
-Utiliza del destino de logs de Observability Pipelines de Datadog para enviar logs a Log Management de Datadog. También puedes utilizar [AWS PrivateLink](#aws-privatelink) para enviar logs de Observability Pipelines a Datadog.
+## Descripción general {#overview}
+
+Utilice el destino Datadog Logs de Observability Pipelines para enviar registros a Datadog Log Management. También puede utilizar [AWS PrivateLink](#aws-privatelink) para enviar registros desde Observability Pipelines a Datadog.
+
+## Configuración {#setup}
+
+Configure el destino Datadog Logs cuando [configure una canalización][4]. Puede configurar una canalización en la [interfaz de usuario][1], utilizando la [API][5] o con [Terraform][6]. Los pasos de esta sección se configuran en la interfaz de usuario.
+
+Antes de enrutar los registros a través de Observability Pipelines, revise cualquier índice, canalización o filtro de exclusión que utilice el
datadog.pipelines:false etiqueta. Para los registros de una fuente de Datadog Agent, el destino Datadog Logs establece
source_type a
datadog_agent (
@source_type:datadog_agent en la búsqueda de registros). Datadog evalúa entonces esos registros como
datadog_agent registros al decidir si aplicar el
datadog.pipelines:false etiqueta. Para cambiar este comportamiento antes de que se entreguen los registros, utilice el
procesador Edit Fields o el
Custom Processor para eliminar el
source_type atributo de los registros.
**Nota**: Las opciones de almacenamiento en buffer están en vista previa. Ponte en contacto con tu gestor de cuenta para solicitar acceso.
- - Si se deja desactivado, el tamaño máximo del almacenamiento en buffer es de 500 eventos.
- - Si está activado:
- 1. Selecciona el tipo de buffer que quieres configurar (**Memoria** o **Disco**).
- 1. Introduce el tamaño del buffer y selecciona la unidad.
+#### Agregar una organización {#add-an-organization}
-### Configurar las variables de entorno
+Los registros que no coinciden con ninguno de los filtros de organización se descartan. La
métrica del componente Data dropped (intentional) muestra la cantidad de registros que no coinciden con los filtros y se descartan.
Debe utilizar una fuente de OpenTelemetry para usar el destino de trazas de OpenTelemetry.
-
-## Configure el destino {#set-up-destination}
-
-Para la gestión de secretos: solo ingrese el identificador para el URI de cliente HTTP/S y, si corresponde, la contraseña de la clave TLS. No ingrese los valores reales.
-
-Configure el destino de trazas de OpenTelemetry cuando [configure una canalización][3]. Esta sección cubre cómo hacerlo en la [UI][1], pero también puede configurar una canalización utilizando la [API][4] o con [Terraform][5].
-
-Después de seleccionar el destino de trazas de OpenTelemetry en la canalización [UI], ingrese el identificador para su clave de URI de cliente HTTP/S. Un ejemplo del punto de conexión de URI al que hace referencia el identificador: `http://localhost:4319/v1/traces`. Si deja el campo del identificador en blanco, se utiliza el [predeterminado](#secret-defaults).
-
-{{% 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 %}}
-
-## Permitir muestras fuera de orden {#allow-out-of-order-samples}
-
-El Worker no siempre envía métricas en el orden correcto para una serie determinada porque no reordena las métricas. Por ejemplo, si el primer lote de métricas contiene métricas con marcas de tiempo: `10:03`, `10:04`, `10:05` y el segundo lote contiene métricas con marcas de tiempo: `10:01`, `10:02`, `10:06`, el Worker no reordena esas métricas antes de enviarlas.
-
-Debido a que el receptor OTLP rechaza las muestras fuera de orden, el Worker registra un error de Bad Request (`400`) y todo el segundo lote de métricas se descarta, incluso si el receptor OTLP aceptó algunas de las métricas válidas en el lote.
-
-Datadog recomienda configurar su receptor OTLP para permitir muestras fuera de orden a fin de evitar que se descarten.
-
-## Solución de problemas {#troubleshooting}
-
-### Registros de error de depuración {#debug-error-logs}
-
-Si ve registros de error `400` o `500` de este destino, puede habilitar los registros de depuración para ver la respuesta devuelta por el servidor. Para habilitar los registros solo para este destino basado en HTTP y no para cada módulo del Worker, establezca `VECTOR_LOG` en `info,vector::sinks::util::http=debug`:
-
-```
-docker run -i -e DD_API_KEY= \
- -e DD_OP_PIPELINE_ID= \
- -e VECTOR_LOG=info,vector::sinks::util::http=debug \
- datadog/observability-pipelines-worker run
-```
-
-Consulte [Habilitar registros de depuración][6] para obtener instrucciones sobre cómo habilitar los registros de depuración completos.
-
-## Valores predeterminados de secretos {#secret-defaults}
-
-{{% observability_pipelines/set_secrets_intro %}}
-
-{{< tabs >}}
-{{% tab "Gestión de secretos" %}}
-
-- Identificador del punto de conexión de URI del cliente HTTP/S:
- - Hace referencia al punto de conexión de URI HTTP/S al que el Worker envía datos de OpenTelemetry. Un ejemplo del punto de conexión de URI al que hace referencia el identificador: `http://localhost:4319/v1/traces`.
- - El identificador predeterminado es `DESTINATION_OTEL_HTTP_CLIENT_URI`.
-- Identificador de frase de contraseña TLS de trazas de OpenTelemetry (cuando TLS está habilitado):
- - El identificador predeterminado es `DESTINATION_OTEL_KEY_PASS`.
-
-{{% /tab %}}
-
-{{% tab "Variables de entorno" %}}
-
-{{% observability_pipelines/configure_existing_pipelines/destination_env_vars/opentelemetry_traces %}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-[1]: https://app.datadoghq.com/observability-pipelines
-[3]: /es/observability_pipelines/configuration/set_up_pipelines/
-[4]: /es/api/latest/observability-pipelines/
-[5]: https://registry.terraform.io/providers/datadog/datadog/latest/docs/resources/observability_pipeline
-[6]: /es/observability_pipelines/monitoring_and_troubleshooting/troubleshooting/#enable-debug-logs
\ No newline at end of file
diff --git a/hugo/content/es/observability_pipelines/guide/get_started_with_the_custom_processor.md b/hugo/content/es/observability_pipelines/guide/get_started_with_the_custom_processor.md
index 8b5778af51b..b4c9bdd81be 100644
--- a/hugo/content/es/observability_pipelines/guide/get_started_with_the_custom_processor.md
+++ b/hugo/content/es/observability_pipelines/guide/get_started_with_the_custom_processor.md
@@ -1,47 +1,49 @@
---
+description: Aprenda a usar las funciones del Procesador personalizado, como la codificación
+ y decodificación Base64, y vea ejemplos de scripts para casos de uso comunes de
+ transformación de registros.
disable_toc: false
further_reading:
-- link: observability_pipelines/processors/custom_processor/
+- link: /observability_pipelines/processors/custom_processor/
tag: Documentación
- text: Más información sobre el procesador personalizado
-- link: observability_pipelines/set_up_pipelines/
+ text: Obtenga más información sobre el Procesador personalizado
+- link: /observability_pipelines/set_up_pipelines/
tag: Documentación
- text: Configurar pipelines
+ text: Configure Pipelines
- link: https://www.datadoghq.com/blog/migrate-historical-logs/
tag: Blog
- text: Migrar logs históricos de Splunk y Elasticsearch utilizando Observability
+ text: Migre registros históricos desde Splunk y Elasticsearch usando Observability
Pipelines
-title: Empezando con el procesador personalizado
+title: Comience con el Procesador personalizado
---
+## Descripción general {#overview}
-## Información general
+Observability Pipelines le permite transformar sus registros antes de enviarlos a sus destinos. Use el Procesador personalizado para crear scripts con funciones personalizadas que modifiquen condicionalmente campos, valores y eventos de registro.
-Observability Pipelines te permite transformar tus logs antes de enviarlos a tus destinos. Utiliza el procesador personalizado para crear scripts con funciones personalizadas que modifiquen condicionalmente los campos, los valores y los eventos de logs.
-
-Esta guía te explica cómo utilizar las siguientes funciones en el script de tu procesador personalizado:
+Esta guía lo orienta sobre cómo usar las siguientes funciones en su script del Procesador personalizado:
- [Decodificar Base64](#decode-base64)
- [Decodificar un evento Base64 completo](#decode-an-entire-base64-encoded-event)
- [Codificar Base64](#encode-base64)
-También incluye scripts de ejemplo que abordan casos de uso frecuentes, como:
+También revisa ejemplos de scripts que abordan casos de uso comunes, tales como:
-- [Reasignar marcas de tiempo de logs históricos)(#remap-timestamps-for-historical-logs)
-- [Extraer un campo de la matriz de etiquetas (tags) de Datadog (`ddtags`)](#extract-a-field-from-the-datadog-tags-array)
+- [Reasignar marcas de tiempo para registros históricos](#remap-timestamps-for-historical-logs)
+- [Extraer un campo de la matriz de etiquetas de Datadog (`ddtags`)](#extract-a-field-from-the-datadog-tags-array)
- [Hacer referencia al valor de otro campo](#reference-another-fields-value)
-- [Eliminar atributos que contengan valores nulos](#remove-attributes-containing-null-values)
-- [Fusionar atributos anidados en el nivel raíz](#merge-nested-attributes-to-root-level)
-- [Serializar logs salientes en formato _raw](#serialize-outbound-logs-in-_raw-format)
+- [Eliminar atributos que contienen valores nulos](#remove-attributes-containing-null-values)
+- [Fusionar atributos anidados al nivel raíz](#merge-nested-attributes-to-root-level)
+- [Serializar registros salientes en formato _raw](#serialize-outbound-logs-in-_raw-format)
-## Decodificar Base64
+## Decodificar Base64 {#decode-base64}
-Para los campos o eventos de logs entrantes codificados en Base64, utiliza la función [`decode_base64`][1] para descodificar el campo o evento. La sintaxis de esta función también funciona para [`decode_base16`][1].
+Para campos de registro o eventos entrantes codificados en Base64, use la función [`decode_base64`][1] para decodificar el campo o evento. La sintaxis de esta función también funciona para [`decode_base16`][1].
-### Ejemplo
+### Ejemplo {#example}
-#### Entrada
+#### Entrada {#input}
-Ejemplo de evento de log que contiene un campo Base64 para decodificar:
+Ejemplo de evento de registro que contiene un campo Base64 para decodificar:
```json
{
@@ -53,24 +55,24 @@ Ejemplo de evento de log que contiene un campo Base64 para decodificar:
}
```
-#### Función personalizada
+#### Función personalizada {#custom-function}
-Utiliza la función `decode_base64` para decodificar `payload` y almacenar el resultado en un nuevo campo llamado `decoded_payload`.
+Utilice la función `decode_base64` para decodificar `payload` y almacenar el resultado en un nuevo campo llamado `decoded_payload`.
```yaml
.decoded_payload = decode_base64!(.payload)
```
-Alternativamente, puedes reescribir el valor original `payload` con el valor decodificado sustituyendo `decoded_payload` en la función anterior por `payload`.
+Alternativamente, puede sobrescribir el valor original de `payload` con el valor decodificado reemplazando `decoded_payload` en la función anterior con `payload`.
```yaml
.payload = decode_base64!(.payload)
```
-#### Salida
+#### Salida {#output}
-El resultado cuando se utiliza `decoded_payload` para almacenar el valor decodificado.
+La salida cuando utiliza `decoded_payload` para almacenar el valor decodificado.
```json
{
@@ -83,11 +85,11 @@ El resultado cuando se utiliza `decoded_payload` para almacenar el valor decodif
}
```
-## Decodificar un evento completo codificado en Base64
+## Decodificar un evento completo codificado en Base64 {#decode-an-entire-base64-encoded-event}
-### Ejemplo
+### Ejemplo {#example-1}
-#### Entrada
+#### Entrada {#input-1}
Ejemplo de entrada de un evento codificado en Base64:
@@ -97,7 +99,7 @@ Ejemplo de entrada de un evento codificado en Base64:
}
```
-#### Función personalizada
+#### Función personalizada {#custom-function-1}
El script para decodificar todo el evento codificado en Base64 `raw`.
@@ -107,9 +109,9 @@ El script para decodificar todo el evento codificado en Base64 `raw`.
. = .full_event
```
-**Nota:** La sintaxis `. = .full_event` es una forma abreviada de sustituir todo el evento por el contenido de un campo.
+**Nota:** La sintaxis `. = .full_event` es una abreviatura para reemplazar todo el evento con el contenido de un campo.
-#### Salida
+#### Salida {#output-1}
```json
{
@@ -119,15 +121,15 @@ El script para decodificar todo el evento codificado en Base64 `raw`.
}
```
-## Codificar Base64
+## Codificar Base64 {#encode-base64}
-Para los campos o eventos de logs salientes codificados en Base64, utiliza la función [`encode_base64`][1] para decodificar el campo o evento. La sintaxis de esta función también funciona para [`encode_base16`][3].
+Para campos de registro salientes o eventos que desee codificar en Base64, utilice la función [`encode_base64`][2] para codificar el campo o evento. La sintaxis de esta función también funciona para [`encode_base16`][3].
-### Ejemplo
+### Ejemplo {#example-2}
-#### Entrada
+#### Entrada {#input-2}
-Ejemplo de evento de log que contiene un campo `message` que debes codificar en Base64:
+Ejemplo de evento de registro que contiene el campo `message` que desea codificar en Base64:
```json
{
@@ -139,23 +141,23 @@ Ejemplo de evento de log que contiene un campo `message` que debes codificar en
}
```
-#### Función personalizada
+#### Función personalizada {#custom-function-2}
-Utiliza la función `encode_base64` para decodificar `message` y almacenar el resultado en un nuevo campo llamado `encoded_message`.
+Utilice la función `encode_base64` para decodificar `message` y almacenar el resultado en un nuevo campo llamado `encoded_message`.
```yaml
.encoded_message = encode_base64!(.message)
```
-Alternativamente, puedes sobreescribir el campo del valor original (`message`) con el valor decodificado sustituyendo `encoded_message` en la función anterior por `message`.
+Alternativamente, puede sobrescribir el campo de mensaje original (`message`) con el valor decodificado reemplazando `encoded_message` en la función anterior con `message`.
```yaml
.message = encode_base64!(.message)
```
-#### Salida
+#### Salida {#output-2}
-El resultado cuando se utiliza `encoded_message` para almacenar el valor codificado.
+La salida cuando utiliza `encoded_message` para almacenar el valor codificado.
```json
{
@@ -167,15 +169,15 @@ El resultado cuando se utiliza `encoded_message` para almacenar el valor codific
}
```
-## Reasignación de marcas de tiempo para logs históricos
+## Reasignar marcas de tiempo para registros históricos {#remap-timestamps-for-historical-logs}
-Si quieres migrar logs archivados de otras plataformas, es esencial asegurarte de que esos logs tienen la marca de tiempo histórica correcta. La reasignación de logs con marcas de tiempo históricas te permite gestionar logs más antiguos almacenados con fines de cumplimiento, auditoría y archivado.
+Si desea migrar registros archivados de otras plataformas, es esencial asegurarse de que esos registros tengan la marca de tiempo histórica correcta. Reasignar registros con marcas de tiempo históricas le permite manejar registros más antiguos almacenados para fines de cumplimiento, auditoría y archivo.
-### Ejemplo
+### Ejemplo {#example-3}
-#### Entrada
+#### Entrada {#input-3}
-Si el Worker no encuentra el campo `timestamp` en un log, se utiliza la marca de tiempo de cuando el Worker recibió el log. Este es un ejemplo de log que muestra la marca de tiempo de cuando el Worker recibió el log, así como la marca de tiempo histórica del log (`historical_ts`), que es el valor que el Worker busca.
+Si el Worker no encuentra el campo `timestamp` en un registro, se utiliza la marca de tiempo de cuando el Worker recibió el registro. Este es un ejemplo de un registro que muestra la marca de tiempo de cuando el Worker recibió el registro, así como la marca de tiempo histórica del registro (`historical_ts`), que es el valor que el Worker está buscando.
```json
{
@@ -186,9 +188,9 @@ Si el Worker no encuentra el campo `timestamp` en un log, se utiliza la marca de
}
```
-#### Función personalizada
+#### Función personalizada {#custom-function-3}
-En el ejemplo anterior, puedes crear una función que almacene la marca de tiempo ingerida en un nuevo campo y reasigne `timestamp` al valor `historical_ts`.
+Para el ejemplo anterior, puede crear una función para almacenar la marca de tiempo ingerida en un nuevo campo y reasignar `timestamp` al valor `historical_ts`.
```yaml
#Create a new field for the ingested/processed timestamp
@@ -202,7 +204,7 @@ del(.historical_ts)
```
-#### Salida
+#### Salida {#output-3}
```json
{
@@ -213,15 +215,15 @@ del(.historical_ts)
}
```
-## Extraer un campo de la matriz de etiquetas de Datadog
+## Extraer un campo de la matriz de etiquetas de Datadog {#extract-a-field-from-the-datadog-tags-array}
-Los campos anidados dentro de la matriz de etiquetas de Datadog (`ddtags`) pueden contener información útil. Es posible que quieras extraer estos campos como pares clave-valor de nivel superior o como valores para otros campos.
+Los campos anidados dentro de la matriz de etiquetas (`ddtags`) de Datadog pueden contener información útil. Es posible que desee extraer estos campos como pares clave-valor de nivel superior, o como valores para otros campos.
-### Ejemplo
+### Ejemplo {#example-4}
-#### Entrada
+#### Entrada {#input-4}
-Log de ejemplo que contiene la matriz `ddtags` con etiquetas de Datadog.
+Registro de muestra que contiene la matriz `ddtags` con etiquetas de Datadog.
```json
{
@@ -242,7 +244,7 @@ Log de ejemplo que contiene la matriz `ddtags` con etiquetas de Datadog.
}
```
-#### Función personalizada para extraer el campo env
+#### Función personalizada para extraer el campo env {#custom-function-to-extract-the-env-field}
```yaml
#Extract a tag from ddtags array and elevate as log attribute
@@ -256,7 +258,7 @@ del(.my_tag)
```
-#### Salida
+#### Salida {#output-4}
```json
{
@@ -277,16 +279,135 @@ del(.my_tag)
"timestamp": "2025-005-27T05:26:18.205Z"
}
```
+## Agregar una etiqueta al evento de registro {#add-a-tag-to-the-log-event}
+
+Las etiquetas se utilizan para correlacionar registros con otros servicios y telemetría. Se almacenan en matrices como pares `key:value` encerrados entre comillas (por ejemplo, `"service:payments-app"`). Para los registros de Datadog específicamente, las etiquetas están anidadas dentro de la matriz de etiquetas (`ddtags`) de Datadog. Utilice los siguientes scripts a continuación para convertir una etiqueta de un atributo existente o agregar una nueva etiqueta.
+
+### Ejemplo para convertir un atributo en una etiqueta {#example-to-convert-an-attribute-to-a-tag}
+
+#### Entrada {#input-5}
+
+En este ejemplo, el registro de muestra contiene una matriz `ddtags`, y usted desea agregar el campo `service` como una etiqueta.
+
+```json
+{
+ "timestamp": "2025-005-27T05:26:18.205Z",
+ "status": "info",
+ "service": "chaos-engineering",
+ "ddsource": "python",
+ "hostname": "gke-prod-node-abc123.internal",
+ "message": "2025-05-27 05:26:17,609 -- Sending request to rails: checkout_v2",
+ "source_type": "datadog_agent",
+ "ddtags": [
+ "env:prod",
+ "team:sre",
+ "version:1.0.0",
+ "pod_name:load-generator-main-abcde"
+ ]
+}
+```
+
+#### Función personalizada para convertir el atributo `service` en una etiqueta {#custom-function-to-convert-the-service-attribute-to-a-tag}
+
+```yaml
+# First, check if the attribute 'ddtags' exists. You can replace 'ddtags' with the name of any array
+if !exists(.ddtags) {
+ .ddtags = []
+}
+
+# This example checks if 'service' exists, then adds the templatized value of service as a tag. Also, it converts the service value to a string
+if exists(.service) {
+ .ddtags = push(array!(.ddtags), "service:" + to_string!({{.service}}) )
+}
+
+```
+
+#### Salida {#output-5}
+
+```json
+{
+ "timestamp": "2025-005-27T05:26:18.205Z",
+ "status": "info",
+ "service": "chaos-engineering",
+ "ddsource": "python",
+ "hostname": "gke-prod-node-abc123.internal",
+ "message": "2025-05-27 05:26:17,609 -- Sending request to rails: checkout_v2",
+ "source_type": "datadog_agent",
+ "ddtags": [
+ "env:prod",
+ "team:sre",
+ "version:1.0.0",
+ "pod_name:load-generator-main-abcde"
+ ]
+}
+```
+### Ejemplo para crear y agregar una etiqueta {#example-to-create-and-add-a-tag}
+
+#### Entrada {#input-6}
+
+En este ejemplo, el registro de muestra contiene la matriz `ddtags`, y usted desea crear una etiqueta llamada `"system:service-mesh"` y anexarla a la matriz.
+
+```json
+{
+ "timestamp": "2025-005-27T05:26:18.205Z",
+ "status": "info",
+ "service": "chaos-engineering",
+ "ddsource": "python",
+ "hostname": "gke-prod-node-abc123.internal",
+ "message": "2025-05-27 05:26:17,609 -- Sending request to rails: checkout_v2",
+ "source_type": "datadog_agent",
+ "ddtags": [
+ "env:prod",
+ "team:sre",
+ "version:1.0.0",
+ "pod_name:load-generator-main-abcde"
+ ]
+}
+```
+
+#### Función personalizada para crear y agregar la etiqueta `system` {#custom-function-to-create-and-add-the-system-tag}
+
+```yaml
+# First, check if the attribute 'ddtags' exists. You can replace 'ddtags' with the name of any array
+if !exists(.ddtags) {
+ .ddtags = []
+}
+
+# Appends a new tag to the array by defining a separate key:value pair
+.ddtags = push(array!(.ddtags), "system:service-mesh")
+
+```
+
+#### Salida {#output-6}
+
+```json
+{
+ "ddsource": "python",
+ "ddtags": [
+ "env:prod",
+ "team:sre",
+ "version:1.0.0",
+ "pod_name:load-generator-main-abcde",
+ "system:service-mesh"
+ ],
+ "hostname": "gke-prod-node-abc123.internal",
+ "message": "2025-05-27 05:26:17,609 -- Sending request to rails: checkout_v2",
+ "service": "chaos-engineering",
+ "source_type": "datadog_agent",
+ "status": "info",
+ "timestamp": "2025-005-27T05:26:18.205Z"
+}
+```
-## Hacer referencia al valor de otro campo
+## Hacer referencia al valor de otro campo {#reference-another-fields-value}
-Si quieres que el valor de un campo se base en otro campo, puedes hacer referencia dinámicamente al valor del otro campo.
+Si desea que el valor de un campo se base en otro campo, puede hacer referencia dinámicamente al valor del otro campo.
-### Ejemplo
+### Ejemplo {#example-5}
-#### Entrada
+#### Entrada {#input-7}
-En este ejemplo, tienes un campo de servicio que contiene un nombre de servicio incorrecto y tú quieres utilizar el valor de `app_id` para el servicio.
+Para este ejemplo, usted tiene un campo de servicio que contiene un nombre de servicio incorrecto, y desea utilizar el valor de `app_id` para el servicio en su lugar.
```json
{
@@ -297,14 +418,14 @@ En este ejemplo, tienes un campo de servicio que contiene un nombre de servicio
}
```
-#### Función personalizada
+#### Función personalizada {#custom-function-4}
```yaml
#Overwrite service to be the value of app_id
.service = {{.app_id}}
```
-#### Salida
+#### Salida {#output-7}
```json
{
@@ -315,9 +436,9 @@ En este ejemplo, tienes un campo de servicio que contiene un nombre de servicio
}
```
-## Eliminar atributos que contienen valores nulos
+## Eliminar atributos que contienen valores nulos {#remove-attributes-containing-null-values}
-Los atributos con valores nulos o vacíos pueden sobrecargar innecesariamente tu log. Elimina los valores nulos para recortar el log y enviar solo los atributos que proporcionan información. En el script siguiente, la sección `empty_patterns` contiene la lista de patrones vacíos que debes comprobar en tus logs. Puedes añadir y eliminar patrones para adaptarlos a tu caso de uso.
+Los atributos con valores nulos o vacíos pueden añadir un peso innecesario a sus registros. Elimine los valores nulos para reducir el registro y enviar solo los atributos que proporcionan información. En el script a continuación, la sección `empty_patterns` contiene la lista de patrones vacíos que se deben buscar en sus registros. Puede agregar y eliminar patrones para adaptarlos a su caso de uso.
```json
# Define your empty patterns
@@ -337,11 +458,11 @@ empty_patterns = ["null", "NULL", "N/A", "n/a", "none", "NONE", "-", "undefined"
})
```
-## Fusionar atributos anidados en el nivel raíz
+## Fusionar atributos anidados al nivel raíz {#merge-nested-attributes-to-root-level}
-La selección de objetos o campos anidados en una consulta de filtro puede requerir la definición de varias rutas. Esto es habitual cuando se trabaja con el campo de mensaje, en el que el contenido analizado resultante está anidado en un objeto. Cuando se utiliza la sintaxis de filtro de Observability Pipelines' el acceso a un campo anidado requiere la notación `.`.
+Apuntar a objetos o campos anidados en una consulta de filtro puede requerir que defina múltiples rutas. Esto es común cuando se trabaja con el campo de mensaje, donde los contenidos analizados resultantes están anidados en un objeto. Cuando utiliza la sintaxis de filtro de Observability Pipelines, acceder a un campo anidado requiere la notación `.`.
-Por ejemplo, este log contiene un mensaje convertido en cadena JSON:
+Por ejemplo, este registro contiene un mensaje JSON convertido en cadena:
```json
{
@@ -359,7 +480,7 @@ Por ejemplo, este log contiene un mensaje convertido en cadena JSON:
}
```
-Este es el resultado después de analizar el campo `message`. El contenido analizado se anida en el objeto `message`.
+Esta es la salida después de que se haya analizado el campo `message`. El contenido analizado está anidado en el objeto `message`.
```json
{
@@ -384,9 +505,9 @@ Este es el resultado después de analizar el campo `message`. El contenido anali
"user_id": "12345"
}
```
-En este caso, para filtrar por `event_type`, es necesario especificar `@message.event_type`. Para filtrar directamente por `event_type` u otro campo dentro de un objeto, Datadog recomienda aplanar el objeto hasta el nivel raíz.
+En este caso, para filtrar por `event_type`, necesita especificar `@message.event_type`. Para filtrar directamente por `event_type` u otro campo dentro de un objeto, Datadog recomienda aplanar el objeto al nivel raíz.
-Para fusionar los eventos del objeto `message` en el nivel raíz, utiliza este script:
+Para fusionar los eventos del objeto `message` al nivel raíz, utilice este script:
```json
if is_object(.message) {
@@ -395,9 +516,9 @@ if is_object(.message) {
}
```
-**Nota**: Este script funciona con cualquier objeto JSON. Solo tienes que sustituir el atributo `message` por el nombre del campo que estás intentando aplanar.
+**Nota**: Este script funciona con cualquier objeto JSON. Solo necesita reemplazar el atributo `message` con el nombre del campo que intenta aplanar.
-El resultado es el log con atributos aplanados que puedes filtrar directamente:
+Esto da como resultado el registro con atributos aplanados que puede filtrar directamente:
```json
{
@@ -421,17 +542,17 @@ El resultado es el log con atributos aplanados que puedes filtrar directamente:
}
```
-**Nota**: Si aplanas el campo del mensaje, el log resultante ya no tendrá un objeto de mensaje. Esto significa que si el log se envía a Datadog, cuando veas el log en Explorador de logs, no verás una sección **Log Message** (Mensaje de log) en el panel lateral del log.
+**Nota**: Si aplana el campo de mensaje, el registro resultante ya no tiene un objeto de mensaje. Esto significa que si el registro se envía a Datadog, cuando vea el registro en Log Explorer, no verá una sección {{< ui >}}Log Message{{< /ui >}} en el panel lateral del registro.
-## Serializar logs salientes en formato _raw
+## Serialice los registros salientes en formato _raw {#serialize-outbound-logs-in-raw-format}
-Splunk y CrowdStrike prefieren un formato llamado `_raw` para la ingesta de logs. El envío de datos en `_raw` normaliza tus logs y te permite beneficiarte de sus dashboards, monitores y contenidos de detección de amenazas predefinidos. Para garantizar que se aplica el formato de log `_raw`, puedes serializar el evento saliente en `_raw`.
+Splunk y CrowdStrike prefieren un formato llamado `_raw` para la ingesta de registros. Enviar datos en `_raw` normaliza sus registros y le permite beneficiarse de sus tableros, seguimientos y contenido de detección de amenazas listos para usar. Para asegurarse de que se aplique el formato de registro `_raw`, puede serializar el evento saliente en `_raw`.
**Notas**:
-- Debes añadir otros pasos de procesamiento, reasignación y análisis antes de serializar tus logs en formato `_raw`.
-- Selecciona `Raw` como opción de codificación cuando configures el destino Splunk HEC o CrowdStrike.
+- Debe agregar otros pasos de parseo, reasignación y análisis antes de serializar sus registros en formato `_raw`.
+- Para asegurarse de que sus registros se enruten correctamente después de la serialización, configure su destino preferido con {{< ui >}}Raw{{< /ui >}} como tipo de codificación.
-Un ejemplo de log de entrada:
+Un ejemplo de registro:
```json
{
@@ -456,12 +577,12 @@ Esta función personalizada serializa el evento en formato `_raw`:
```json
# Serialize the entire event into _raw
-._raw = encode_key_value(.)
+._raw = encode_key_value!(.)
# Only keep _raw
. = { "_raw": ._raw }
```
-Este es el resultado del ejemplo de log después de haber sido procesado por el script personalizado:
+Esta es la salida del registro de ejemplo después de haber sido procesada por el script personalizado:
```json
{
@@ -469,7 +590,7 @@ Este es el resultado del ejemplo de log después de haber sido procesado por el
}
```
-## Referencias adicionales
+## Lecturas adicionales {#further-reading}
{{< partial name="whats-next/whats-next.html" >}}
diff --git a/hugo/content/es/observability_pipelines/monitoring_and_troubleshooting/worker_cli_commands.md b/hugo/content/es/observability_pipelines/monitoring_and_troubleshooting/worker_cli_commands.md
new file mode 100644
index 00000000000..e1cedbb4ce7
--- /dev/null
+++ b/hugo/content/es/observability_pipelines/monitoring_and_troubleshooting/worker_cli_commands.md
@@ -0,0 +1,49 @@
+---
+aliases:
+- /es/observability_pipelines/install_the_worker/worker_commands/
+description: Encuentre los comandos y opciones run, tap y top para la interfaz de
+ línea de comandos de Observability Pipelines Worker.
+disable_toc: false
+further_reading:
+- link: observability_pipelines/configuration/install_the_worker/
+ tag: Documentación
+ text: Instale el Worker
+title: Comandos de la CLI del Worker
+---
+## Run, tap o top el Worker {#run-tap-or-top-the-worker}
+
+Ejemplo de uso: `observability-pipelines-worker `
+
+Si está utilizando un entorno contenedorizado, use el comando `docker exec` o `kubectl exec` para obtener un shell en el contenedor y ejecutar el comando. Por ejemplo:
+
+- Para Kubernetes: `kubectl exec -it -- observability-pipelines-worker `
+- Para Docker: `docker exec -it observability-pipelines-worker `
+
+| Comando | Descripción |
+|-----------|-----------------------------------------------------------------------------------------------------------------------|
+| `run` | Ejecute el Observability Pipelines Worker. |
+| `tap` | Ejecute tap en una canalización para observar eventos desde la fuente o transformar componentes. Consulte [opciones de tap](#tap-options). |
+| `top` | Enumera los componentes de la canalización y proporciona estadísticas como las tasas de datos de entrada y salida para cada componente. Ingrese `?` para ver todas las combinaciones de teclas disponibles. |
+
+### Opciones de tap {#tap-options}
+
+Ejemplo de uso: `observability-pipelines-worker tap `
+
+Puede usar el [`top` comando ](#run-tap-or-top-the-worker) para encontrar el ID del componente al que desea `tap`.
+
+| Opciones | Descripciones |
+|----------------------------------|----------------------------------------------------------------------------------------------------------------|
+| `-i`, `--interval ` | Intervalo para muestrear eventos, en milisegundos (predeterminado: `500`). |
+| `-u`, `--url ` | Punto de conexión del servidor de la API de GraphQL. |
+| `-l`, `--limit ` | Número máximo de eventos para muestrear en cada intervalo (predeterminado: `100`). |
+| `-f`, `--format ` | Formato de codificación para los eventos impresos en pantalla.
predeterminado: `json`
valores posibles: `json`, `yaml`, `logfmt` |
+| `--outputs-of ` | IDs de fuente o procesador cuyas salidas desea observar (separados por comas; acepta patrones glob). |
+| `--inputs-of ` | IDs de procesador o destino cuyas entradas desea observar (separados por comas; acepta patrones glob). |
+| `-q`, `--quiet` | La salida silenciosa incluye solo eventos. |
+| `-m`, `--meta` | Incluye metadatos como el ID del componente asociado al evento. |
+| `-n`, `--no-reconnect` | Indica si se debe reconectar si la conexión API subyacente se interrumpe. De forma predeterminada, `tap` intenta reconectarse si la conexión se interrumpe. |
+| `-d`, `--duration-ms ` | Especifica una duración (en milisegundos) para muestrear registros (por ejemplo, especificar `10000` muestrea registros durante 10 segundos y luego sale). |
+
+## Lecturas adicionales {#further-reading}
+
+{{< partial name="whats-next/whats-next.html" >}}
\ No newline at end of file
diff --git a/hugo/content/es/observability_pipelines/packs/google_secops_aws_vpc.md b/hugo/content/es/observability_pipelines/packs/google_secops_aws_vpc.md
new file mode 100644
index 00000000000..91fe6b40b96
--- /dev/null
+++ b/hugo/content/es/observability_pipelines/packs/google_secops_aws_vpc.md
@@ -0,0 +1,15 @@
+---
+description: Obtenga más información sobre el paquete Google SecOps - AWS VPC.
+title: Google SecOps - AWS VPC
+---
+## Descripción general {#overview}
+
+{{< img src="observability_pipelines/packs/google_secops_aws_vpc.png" alt="El paquete Google SecOps - AWS VPC" style="width:25%;" >}}
+
+Este paquete asigna registros de flujo de AWS VPC al esquema UDM en Google Security Operations.
+
+Qué hace este paquete:
+
+- Asigna flujos de VPC a UDM
+- Establece la acción a partir del veredicto de flujo de VPC
+- Asigna IP, bytes y recurso de VPC
\ No newline at end of file
diff --git a/hugo/content/es/observability_pipelines/packs/mitre_attack_aws_waf_enrichment.md b/hugo/content/es/observability_pipelines/packs/mitre_attack_aws_waf_enrichment.md
new file mode 100644
index 00000000000..9b3a826e3c7
--- /dev/null
+++ b/hugo/content/es/observability_pipelines/packs/mitre_attack_aws_waf_enrichment.md
@@ -0,0 +1,16 @@
+---
+description: Obtenga más información sobre el paquete MITRE ATT&CK AWS WAF Enrichment
+ pack.
+title: MITRE ATT&CK AWS WAF Enrichment
+---
+## Descripción general {#overview}
+
+{{< img src="observability_pipelines/packs/mitre_attack_aws_waf_enrichment.png" alt="El paquete MITRE ATT&CK AWS WAF Enrichment pack" style="width:25%;" >}}
+
+Este paquete etiqueta los registros de AWS WAF con tácticas y técnicas de MITRE ATT&CK.
+
+Lo que hace este paquete:
+
+- Etiqueta eventos con técnicas de MITRE
+- Mapea exploits, fuerza bruta y eventos de bots
+- Marca eventos como relevantes para la seguridad
\ No newline at end of file
diff --git a/hugo/content/es/observability_pipelines/processors/parse_json.md b/hugo/content/es/observability_pipelines/processors/parse_json.md
index b5e9c28993e..cec440bd148 100644
--- a/hugo/content/es/observability_pipelines/processors/parse_json.md
+++ b/hugo/content/es/observability_pipelines/processors/parse_json.md
@@ -1,13 +1,83 @@
---
+description: Aprenda a utilizar el procesador Parse JSON para analizar un campo JSON
+ especificado en objetos.
disable_toc: false
+further_reading:
+- link: https://www.datadoghq.com/blog/otel-ai-observability-pipelines-clickhouse/
+ tag: Blog
+ text: Enrutar datos de OTel de aplicaciones de IA a ClickHouse y Datadog usando
+ Observability Pipelines
+- link: https://www.datadoghq.com/blog/observability-pipelines-mssp
+ tag: Blog
+ text: Simplifique la recopilación y agregación de registros para MSSP con Datadog
+ Observability Pipelines
products:
- icon: logs
- name: Logs
-title: Procesador de análisis de JSON
+ name: Registros
+ url: /observability_pipelines/configuration/?tab=logs#pipeline-types
+title: Procesador Parse JSON
---
-
{{< product-availability >}}
-{{% observability_pipelines/processors/parse_json %}}
+## Descripción general {#overview}
+
+Este procesador analiza el campo JSON especificado en objetos. Por ejemplo, si tiene un campo `message` que contiene JSON convertido en cadena:
+
+```json
+{
+ "foo": "bar",
+ "team": "my-team",
+ "message": "{\"level\":\"info\",\"timestamp\":\"2024-01-15T10:30:00Z\",\"service\":\"user-service\",\"user_id\":\"12345\",\"action\":\"login\",\"success\":true,\"ip_address\":\"192.168.1.100\"}"
+ "app_id":"streaming-services",
+ "ddtags": [
+ "kube_service:my-service",
+ "k8_deployment :your-host"
+ ]
+}
+```
+
+Utilice el procesador Parse JSON para analizar el campo `message` de modo que el campo `message` tenga todos los atributos dentro de un objeto anidado.
+
+{{< img src="observability_pipelines/processors/parse-json-example.png" alt="El procesador Parse JSON con message como el campo a analizar" style="width:60%;" >}}
+
+Esta salida contiene el campo `message` con el JSON analizado:
+
+```json
+{
+ "foo": "bar",
+ "team": "my-team",
+ "message": {
+ "action": "login",
+ "ip_address": "192.168.1.100",
+ "level": "info",
+ "service": "user-service",
+ "success": true,
+ "timestamp": "2024-01-15T10:30:00Z",
+ "user_id": "12345"
+ }
+ "app_id":"streaming-services",
+ "ddtags": [
+ "kube_service:my-service",
+ "k8_deployment :your-host"
+ ]
+}
+```
+
+## Configuración {#setup}
+
+Para configurar este procesador:
+1. Defina un {{< ui >}}filter query{{< /ui >}}. Solo se procesan los registros que coinciden con la consulta de filtro especificada. Todos los registros, independientemente de si coinciden o no con la consulta de filtro, se envían al siguiente paso en la canalización. Consulte [Sintaxis de búsqueda][1] para obtener más información.
+2. Ingrese el nombre del campo en el que desea analizar JSON.
**Nota**: El JSON analizado sobrescribe lo que originalmente contenía el campo.
+
+## Métricas de estado {#health-metrics}
+
+Para [métricas de componentes][2] y [métricas de búfer de procesador][3] emitidas por todos los procesadores, consulte la documentación de [Métricas de uso de Pipelines][4]. Para filtrar o agrupar por métricas del procesador Parse, utilice la etiqueta `component_type:parse`.
+
+[1]: /es/observability_pipelines/search_syntax/logs/
+[2]: /es/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#component-metrics
+[3]: /es/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#processor-buffer-metrics
+[4]: /es/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/
+
+## Lecturas adicionales {#further-reading}
-{{% observability_pipelines/processors/filter_syntax %}}
\ No newline at end of file
+{{< partial name="whats-next/whats-next.html" >}}
\ No newline at end of file
diff --git a/hugo/content/es/observability_pipelines/processors/quota.md b/hugo/content/es/observability_pipelines/processors/quota.md
index ef36de6f79a..b2394335709 100644
--- a/hugo/content/es/observability_pipelines/processors/quota.md
+++ b/hugo/content/es/observability_pipelines/processors/quota.md
@@ -1,13 +1,135 @@
---
+description: Aprenda a usar el procesador de cuotas para medir el tráfico de registros
+ y conservar, descartar o enrutar registros después de alcanzar su cuota diaria.
disable_toc: false
products:
- icon: logs
- name: Logs
+ name: Registros
+ url: /observability_pipelines/configuration/?tab=logs#pipeline-types
title: Procesador de cuotas
---
-
{{< product-availability >}}
-{{% observability_pipelines/processors/quota %}}
+## Descripción general {#overview}
+
+El procesador de cuotas mide el tráfico de registros para los registros que coinciden con el filtro que usted especifica. Utiliza una ventana fija de 24 horas que se restablece a la medianoche UTC. Cuando se alcanza la cuota diaria configurada dentro de la ventana, el procesador puede conservar o descartar registros adicionales, o enviarlos a un depósito de almacenamiento. Por ejemplo, puede configurar este procesador para descartar nuevos registros o activar una alerta sin descartar registros después de que el procesador haya recibido 10 millones de eventos de un determinado servicio en las últimas 24 horas.
+
+También puede usar la partición basada en campos, como `service`, `env`, `status`. Cada campo único utiliza un depósito de cuota separado con su propio límite de cuota diaria. Consulte [Ejemplo de partición](#partition-example) para obtener más información.
+
+**Nota**: La canalización utiliza el nombre de la cuota para identificar la misma cuota en múltiples implementaciones de Remote Configuration del Worker.
+
+### Límites {#limits}
+
+- Cada canalización puede tener hasta 1000 depósitos. Si necesita aumentar el límite de depósitos, [contacte a soporte][5].
+- El procesador de cuotas está sincronizado en todos los Workers de una organización de Datadog. Para la sincronización, existe un límite de tasa predeterminado de 100 Workers por organización (300 para versiones de worker 2.16+). Cuando hay más de este límite de Workers para una organización:
+ - El procesador continúa ejecutándose, pero no se sincroniza correctamente con los otros Workers, lo que puede resultar en el envío de registros después de que se haya alcanzado el límite de cuota.
+ - El Worker imprime errores `Failed to sync quota state`.
+ - [Contacte a soporte][5] si desea aumentar el número predeterminado de Workers por organización.
+- El procesador de cuotas sincroniza periódicamente los conteos entre los Workers unas pocas veces por minuto. Por lo tanto, el límite establecido en el procesador puede superarse, dependiendo del número de Workers y del rendimiento de los registros. Datadog recomienda establecer un límite que sea al menos un orden de magnitud superior al volumen de registros que se espera que reciba el procesador por minuto. Puede utilizar un procesador de limitación (throttle) con el procesador de cuota para controlar estas breves ráfagas limitando el número de registros permitidos por minuto.
+
+## Configuración {#setup}
+
+Para configurar el procesador de cuota:
+1. Ingrese un nombre para el procesador de cuota.
+1. Defina un {{< ui >}}filter query{{< /ui >}}. Solo los registros que coinciden con la consulta de filtro especificada se cuentan para el límite diario. Consulte [Sintaxis de búsqueda][6] para obtener más información.
+ - Los registros que coinciden con el filtro de cuota y están dentro de la cuota diaria se envían al siguiente paso en la canalización.
+ - Los registros que no coinciden con el filtro de cuota se envían al siguiente paso en la canalización.
+1. En el menú desplegable {{< ui >}}Unit for quota{{< /ui >}}, seleccione si desea medir la cuota por el número de `Events` o por el `Volume` en bytes.
+1. Establezca el límite de cuota diaria y seleccione la unidad de magnitud para la cuota deseada.
+1. Opcional: Haga clic en {{< ui >}}Add Field{{< /ui >}} si desea establecer una cuota en un campo de servicio o región específico.
+ 1. Ingrese el nombre del campo por el que desea realizar la partición. Consulte el [ejemplo de partición](#partition-example) para obtener más información.
+ 1. Seleccione {{< ui >}}Ignore when missing{{< /ui >}} si desea que la cuota se aplique solo a los eventos que coinciden con la partición. Consulte el [ejemplo de ignorar cuando falta](#example-for-the-ignore-when-missing-option) para obtener más información.
+ 1. Opcional: Haga clic en {{< ui >}}Overrides{{< /ui >}} si desea establecer cuotas diferentes para el campo particionado.
+ - Haga clic en {{< ui >}}Download as CSV{{< /ui >}} para ver un ejemplo de cómo estructurar el CSV.
+ - Arrastre y suelte su CSV de anulaciones para cargarlo. También puede hacer clic en {{< ui >}}Browse{{< /ui >}} para seleccionar el archivo y cargarlo. Consulte el [ejemplo de anulaciones](#overrides-example) para obtener más información.
+ 1. Haga clic en {{< ui >}}Add Field{{< /ui >}} si desea agregar otra partición.
+1. En el menú desplegable {{< ui >}}When quota is met{{< /ui >}}, seleccione si desea {{< ui >}}drop events{{< /ui >}}, {{< ui >}}keep events{{< /ui >}} o {{< ui >}}send events to overflow destination{{< /ui >}} cuando se haya alcanzado la cuota.
+ 1. Si selecciona {{< ui >}}send events to overflow destination{{< /ui >}}, se agrega un destino de desbordamiento con las siguientes opciones de almacenamiento en la nube: **Amazon S3**, **Azure Blob** y **Google Cloud**.
+ 1. Seleccione el almacenamiento en la nube al que desea enviar los registros de desbordamiento. Consulte las instrucciones de configuración para su almacenamiento en la nube: [Amazon S3][2], [Azure Blob Storage][3] o [Google Cloud Storage][4].
+
+### Ejemplos {#examples}
+
+#### Ejemplo de partición {#partition-example}
+
+Use {{< ui >}}Partition by{{< /ui >}} si desea establecer una cuota en un servicio o región específicos. Por ejemplo, si desea establecer una cuota de 10 eventos por día y agrupar los eventos por el campo `service`, ingrese `service` en el campo {{< ui >}}Partition by{{< /ui >}}.
+
+#### Ejemplo para la opción "ignorar cuando falte" {#example-for-the-ignore-when-missing-option}
+
+Seleccione {{< ui >}}Ignore when missing{{< /ui >}} si desea que la cuota se aplique solo a los eventos que coincidan con la partición. Por ejemplo, si el Worker recibe el siguiente conjunto de eventos:
+
+```
+{"service":"a", "source":"foo", "message": "..."}
+{"service":"b", "source":"bar", "message": "..."}
+{"service":"b", "message": "..."}
+{"source":"redis", "message": "..."}
+{"message": "..."}
+```
+
+Y se selecciona {{< ui >}}Ignore when missing{{< /ui >}}, entonces el Worker:
+- crea un conjunto para los registros con `service:a` y `source:foo`
+- crea un conjunto para los registros con `service:b` y `source:bar`
+- ignora los últimos tres eventos
+
+La cuota se aplica a los dos conjuntos de registros y no a los últimos tres eventos.
+
+Si no se selecciona {{< ui >}}Ignore when missing{{< /ui >}}, la cuota se aplica a los cinco eventos.
+
+#### Ejemplo de anulaciones {#overrides-example}
+
+Si realiza la partición por `service` y tiene dos servicios: `a` y `b`, puede usar anulaciones para aplicarles diferentes cuotas. Por ejemplo, si desea que `service:a` tenga un límite de cuota de 5,000 bytes y `service:b` tenga un límite de 50 eventos, las reglas de anulación se ven así:
+
+| Servicio | Tipo | Límite |
+| ------- | ------ | ----- |
+| `a` | Bytes | 5,000 |
+| `b` | Eventos | 50 |
+
+## Métricas de estado {#health-metrics}
+
+Para [métricas de componentes][7] y [métricas de búfer del procesador][8] emitidas por todos los procesadores, consulte la documentación de [métricas de uso de Pipelines][9].
+
+### Métricas de cuota {#quota-metrics}
+
+- Utilice la etiqueta `component_id` para filtrar o agrupar por componentes individuales.
+- La etiqueta `component_type` es `quota` para estas métricas.
+
+`pipelines.quota_reached_events_total`
+: **Descripción**: La cantidad de eventos descartados porque se recibieron después de alcanzar el límite de cuota configurado.
+: **Tipo de métrica**: conteo
+
+`pipelines.quota_reached_event_bytes_total`
+: **Descripción**: El tamaño, en bytes, de los eventos descartados porque se recibieron después de alcanzar el límite de cuota configurado.
+: **Tipo de métrica**: conteo
+
+`pipelines.quota_overflow_destination_sent_events_total`
+: **Descripción**: La cantidad de eventos enrutados a un destino de desbordamiento secundario cuando se alcanzó un límite de cuota.
+: **Tipo de métrica**: count
+
+`pipelines.quota_fill`
+: **Descripción**: El nivel de llenado actual de un depósito de cuota de limitación de tasa; el valor varía de `0` a `100`.
+: **Tipo de métrica**: gauge
+
+`pipelines.quotas_usage`
+: **Descripción**: Nivel de llenado agregado en todos los depósitos de cuota; el valor varía de `0` a `100`.
+: **Tipo de métrica**: gauge
+
+`pipelines.quota_limit_events`
+: **Descripción**: El rendimiento máximo de eventos configurado por intervalo para una regla de cuota.
+: **Tipo de métrica**: gauge
+
+`pipelines.quota_limit_bytes`
+: **Descripción**: El rendimiento máximo de bytes configurado por intervalo para una regla de cuota.
+: **Tipo de métrica**: gauge
+
+`pipelines.quotas_count`
+: **Descripción**: El número de depósitos de cuota de limitación de tasa activos que se están rastreando actualmente.
+: **Tipo de métrica**: gauge
-{{% observability_pipelines/processors/filter_syntax %}}
\ No newline at end of file
+[1]: /es/monitors/types/metric/?tab=threshold
+[2]: /es/observability_pipelines/destinations/datadog_archives/
+[3]: /es/observability_pipelines/destinations/azure_storage/
+[4]: /es/observability_pipelines/destinations/google_cloud_storage/
+[5]: /es/help/
+[6]: /es/observability_pipelines/search_syntax/logs/
+[7]: /es/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#component-metrics
+[8]: /es/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#processor-buffer-metrics
+[9]: /es/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/
\ No newline at end of file
diff --git a/hugo/content/es/observability_pipelines/processors/split_array.md b/hugo/content/es/observability_pipelines/processors/split_array.md
new file mode 100644
index 00000000000..1ac17f2aed3
--- /dev/null
+++ b/hugo/content/es/observability_pipelines/processors/split_array.md
@@ -0,0 +1,153 @@
+---
+description: Aprenda a utilizar el procesador Split Array para dividir matrices anidadas
+ en eventos distintos, de modo que pueda consultar, filtrar, alertar y visualizar
+ los datos.
+disable_toc: false
+products:
+- icon: logs
+ name: Registros
+ url: /observability_pipelines/configuration/?tab=logs#pipeline-types
+title: Procesador Split Array
+---
+{{< product-availability >}}
+
+## Descripción general {#overview}
+
+Este procesador divide matrices anidadas en eventos distintos para que pueda consultar, filtrar, alertar y visualizar datos dentro de una matriz. Las matrices deben estar ya analizadas. Por ejemplo, el procesador puede procesar `[item_1, item_2]`, pero no puede procesar `"[item_1, item2]"`. Los elementos de la matriz pueden ser objetos JSON, cadenas, números enteros, números de punto flotante o valores booleanos. Todos los campos no modificados se agregan a los eventos secundarios. Por ejemplo, si está enviando los siguientes elementos al Observability Pipelines Worker:
+
+```json
+{
+ "host": "my-host",
+ "env": "prod",
+ "batched_items": [item_1, item_2]
+}
+```
+
+Utilice el procesador Split Array para enviar cada elemento en `batched_items` como un evento independiente:
+
+```json
+{
+ "host": "my-host",
+ "env": "prod",
+ "batched_items": item_1
+}
+```
+
+```json
+{
+ "host": "my-host",
+ "env": "prod",
+ "batched_items": item_2
+}
+```
+
+Consulte el [ejemplo de matriz dividida](#split-array-example) para obtener un ejemplo más detallado.
+
+## Configuración {#setup}
+
+Para configurar este procesador:
+
+Haga clic en {{< ui >}}Manage arrays to split{{< /ui >}} para agregar una matriz a dividir o editar una matriz existente a dividir. Esto abre un panel lateral.
+
+- Si aún no ha creado ninguna matriz, introduzca los parámetros de la matriz como se describe en la sección [Agregar una nueva matriz](#add-a-new-array) a continuación.
+- Si ya ha creado matrices, haga clic en la fila de la matriz en la tabla para editarla o eliminarla. Utilice la barra de búsqueda para encontrar una matriz específica y, a continuación, seleccione la matriz para editarla o eliminarla. Haga clic en {{< ui >}}Add Array to Split{{< /ui >}} para agregar una nueva matriz.
+
+### Agregar una nueva matriz {#add-a-new-array}
+
+1. Defina una {{< 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 el filtro.
+ - Todos los registros, independientemente de si coinciden con la consulta de filtro, se envían al siguiente paso de la canalización.
+1. Introduzca la ruta al campo de la matriz. Utilice la notación de ruta `.` para hacer coincidir subcampos. Consulte el [ejemplo de notación de ruta](#path-notation-example-split-array) a continuación.
+1. Haga clic en {{< ui >}}Save{{< /ui >}}.
+
+### Ejemplo de división de matriz {#split-array-example}
+
+Este es un ejemplo de evento:
+
+```json
+{
+ "ddtags": ["tag1", "tag2"],
+ "host": "my-host",
+ "env": "prod",
+ "message": {
+ "isMessage": true,
+ "myfield" : {
+ "timestamp":14500000,
+ "firstarray":["one", 2]
+ },
+ },
+ "secondarray": [
+ {
+ "some":"json",
+ "Object":"works"
+ }, 44]
+}
+```
+
+Si el procesador está dividiendo las matrices `"message.myfield.firstarray"` y `"secondarray"`, genera eventos secundarios que son idénticos al evento principal, excepto por los valores de `"message.myfield.firstarray"` y `"secondarray",`, que se convierten en un solo elemento de su respectiva matriz original. Cada evento secundario es una combinación única de elementos de las dos matrices, por lo que en este ejemplo se crean cuatro eventos secundarios (2 elementos * 2 elementos = 4 combinaciones).
+
+```json
+{
+ "ddtags": ["tag1", "tag2"],
+ "host": "my-host",
+ "env": "prod",
+ "message": {
+ "isMessage": true,
+ "myfield" : {"timestamp":14500000, "firstarray":"one"},
+ },
+ "secondarray": {
+ "some":"json",
+ "Object":"works"
+ }
+}
+```
+
+```json
+{
+ "ddtags": ["tag1", "tag2"],
+ "host": "my-host",
+ "env": "prod",
+ "message": {
+ "isMessage": true,
+ "myfield" : {"timestamp":14500000, "firstarray":"one"},
+ },
+ "secondarray": 44
+}
+```
+
+```json
+{
+ "ddtags": ["tag1", "tag2"],
+ "host": "my-host",
+ "env": "prod",
+ "message": {
+ "isMessage": true,
+ "myfield" : {"timestamp":14500000, "firstarray":2},
+ },
+ "secondarray": {
+ "some":"json",
+ "object":"works"
+ }
+}
+```
+
+```json
+{
+ "ddtags": ["tag1", "tag2"],
+ "host": "my-host",
+ "env": "prod",
+ "message": {
+ "isMessage": true,
+ "myfield" : {"timestamp":14500000, "firstarray":2},
+ },
+ "secondarray": 44
+}
+```
+
+### Ejemplo de notación de ruta {#path-notation-example-split-array}
+
+{{% observability_pipelines/path_notation %}}
+
+{{% observability_pipelines/path_notation_dots %}}
+
+[1]: /es/observability_pipelines/search_syntax/logs/
\ No newline at end of file
diff --git a/hugo/content/es/observability_pipelines/sources/lambda_extension.md b/hugo/content/es/observability_pipelines/sources/lambda_extension.md
new file mode 100644
index 00000000000..dd06c0696dd
--- /dev/null
+++ b/hugo/content/es/observability_pipelines/sources/lambda_extension.md
@@ -0,0 +1,41 @@
+---
+description: Aprenda a enviar registros de Lambda Extension a Observability Pipelines
+disable_toc: false
+title: Enviar registros de Datadog Lambda Extension a Observability Pipelines
+---
+## Descripción general {#overview}
+
+Este documento describe cómo usar Datadog Lambda Extension para enviar registros proporcionados por AWS a Observability Pipelines. Los pasos de configuración son:
+
+- [Configure una canalización con el HTTP/S Server source](#set-up-a-pipeline).
+- [Implemente Datadog Lambda Extension](#deploy-the-datadog-lambda-extension)
+
+Consulte [Datadog Lambda Extension][1] para obtener más información al respecto.
+
+**Nota**: Datadog Lambda Extension envía registros etiquetados con `ddsource` y `ddtags`, no con `source` y `tags`. Cuando defina consultas o filtros de procesador para estos registros, use `ddsource` y `ddtags`.
+
+## Configure una canalización {#set-up-a-pipeline}
+
+{{% observability_pipelines/lambda_forwarder/pipeline_setup %}}
+
+**Nota**: Su Observability Pipeline debe usar {{< ui >}}HTTP Server{{< /ui >}} como source para procesar registros de Datadog Lambda Extension. No use {{< ui >}}Datadog Agent{{< /ui >}} como source.
+
+## Implemente Datadog Lambda Extension {#deploy-the-datadog-lambda-extension}
+
+### Instale Datadog Lambda Extension {#install-the-datadog-lambda-extension}
+
+Siga las instrucciones en [Instrument AWS Lambda applications][2] para configurar Datadog Lambda Library para recopilar datos de sus aplicaciones de AWS Lambda.
+
+### Establezca variables de entorno para Datadog Lambda Extension {#set-environment-variables-for-datadog-lambda-extension}
+
+{{% observability_pipelines/lambda_extension_source %}}
+
+## Métricas de estado {#health-metrics}
+
+Para [métricas de componentes][3] y [métricas de búfer de fuente][4] emitidas por todas las fuentes, consulte la documentación de [Pipelines Usage Metrics][5]. Dado que utiliza el HTTP Server source para enviar registros desde Datadog Lambda Extension a Observability Pipelines, use la etiqueta `component_type:http_server` para filtrar las métricas relevantes.
+
+[1]: https://docs.datadoghq.com/es/serverless/libraries_integrations/extension/
+[2]: https://docs.datadoghq.com/es/serverless/aws_lambda/instrumentation/
+[3]: /es/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#component-metrics
+[4]: /es/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#source-buffer-metrics
+[5]: /es/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/
\ No newline at end of file
diff --git a/hugo/content/es/security/ai_guard/_index.md b/hugo/content/es/security/ai_guard/_index.md
new file mode 100644
index 00000000000..9a608315ad1
--- /dev/null
+++ b/hugo/content/es/security/ai_guard/_index.md
@@ -0,0 +1,52 @@
+---
+further_reading:
+- link: /security/ai_guard/onboarding/
+ tag: Documentación
+ text: Comience con AI Guard
+- link: /security/ai_guard/signals/
+ tag: Documentación
+ text: AI Guard Security Signals
+- link: https://www.datadoghq.com/blog/ai-guard/
+ tag: Blog
+ text: Proteja las aplicaciones de IA agenticas con Datadog AI Guard
+- link: https://www.datadoghq.com/blog/llm-guardrails-best-practices/
+ tag: Blog
+ text: 'Guardrails de LLM: Mejores prácticas para implementar aplicaciones de LLM
+ de forma segura'
+- link: https://www.datadoghq.com/blog/securing-ai-agents-guardrail-placement/
+ tag: Blog
+ text: 'Protección de agentes de IA: Por qué la ubicación de los guardrails es una
+ decisión de diseño clave'
+title: AI Guard
+---
+{{< site-region region="gov,gov2" >}}AI Guard no está disponible en el {{< region-param key="dd_site_name" >}} sitio.
+{{< /site-region >}}
+
+{{< callout url="" btn_hidden="true" header="¡Obtenga acceso a AI Guard!">}}
+Utilice uno de estos formularios para solicitar acceso a las funciones de AI Guard:
+- Custom Agent Runtime Protection (Limited Access): Proteja sus custom AI Agents contra ataques en tiempo de ejecución.
+- Coding Agent Runtime Protection (Preview): Proteja sus Coding Agents en los flujos de trabajo de los desarrolladores, para que pueda implementar código generado por IA de forma segura.
+{{< /callout >}}
+
+Datadog AI Guard es un producto de defensa en profundidad diseñado para **inspeccionar**, **bloquear** y **gobernar** el comportamiento de la IA en tiempo real. AI Guard está diseñado para conectarse directamente con los flujos de trabajo de rastreo y observabilidad existentes de Datadog para proteger los sistemas de IA agenticos en producción. Se coloca **en línea con su aplicación/Agent de IA** y se superpone a las plantillas de prompts, guardrails y verificaciones de políticas existentes, para **proteger sus flujos de trabajo de LLM en la ruta crítica**.
+
+AI Guard protege contra la inyección de prompts, el jailbreaking y los ataques de exfiltración de datos confidenciales con Protección de Prompts, Protección de Herramientas y Protección de Datos Confidenciales. Juntas, estas capacidades protegen contra la [agentic lethal trifecta][3]:
+- Acceso privilegiado al sistema
+- Exposición a datos no confiables
+- Comunicación saliente
+
+AI Guard también detecta datos confidenciales como información de identificación personal (PII) y secretos en las entradas y salidas de LLM. Estas protecciones funcionan para cualquier modelo de IA de destino, incluidos OpenAI, Anthropic, Bedrock, VertexAI y Azure. Para ver sus AI Agents y servicios de IA mapeados, incluyendo cómo interactúan entre sí y cuáles está protegiendo AI Guard, vaya a la página [{{< ui >}}Discover{{< /ui >}}][5].
+
+Para evaluar rápidamente una conversación sin código ni configuración, utilice [{{< ui >}}AI Guard Playground{{< /ui >}}][4] para enviar la entrada del usuario, la salida del asistente y las llamadas a herramientas, y vea el resultado de la evaluación en tiempo real.
+
+Para obtener información sobre cómo configurar AI Guard, consulte [Get Started with AI Guard][1].
+
+## Lecturas adicionales {#further-reading}
+
+{{< partial name="whats-next/whats-next.html" >}}
+
+[1]: /es/security/ai_guard/onboarding/
+[2]: https://genai.owasp.org/llm-top-10/
+[3]: https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
+[4]: /es/security/ai_guard/onboarding/#playground
+[5]: https://app.datadoghq.com/security/ai-guard/discover
\ No newline at end of file
diff --git a/hugo/content/es/security/ai_guard/signals.md b/hugo/content/es/security/ai_guard/signals.md
new file mode 100644
index 00000000000..aaf61d17d88
--- /dev/null
+++ b/hugo/content/es/security/ai_guard/signals.md
@@ -0,0 +1,148 @@
+---
+further_reading:
+- link: /security/ai_guard/
+ tag: Documentación
+ text: AI Guard
+- link: /security/ai_guard/onboarding/
+ tag: Documentación
+ text: Comience con AI Guard
+- link: /security/detection_rules/
+ tag: Documentación
+ text: Reglas de detección
+title: Señales de seguridad de AI Guard
+---
+{{< site-region region="gov" >}}AI Guard no está disponible en el {{< region-param key="dd_site_name" >}} sitio.
+{{< /site-region >}}
+
+Las señales de seguridad de AI Guard proporcionan visibilidad sobre las amenazas y ataques que AI Guard detecta en sus aplicaciones. Estas señales se basan en [señales de seguridad de AAP (Protección de aplicaciones y API)][1] y se integran con los flujos de trabajo de monitoreo de seguridad de Datadog.
+
+## Comprender las señales de AI Guard {#understand-ai-guard-signals}
+
+Datadog crea señales de seguridad de AI Guard cuando detecta una amenaza basada en una regla de detección configurada. Las señales que indican amenazas como inyección de prompts, jailbreaking o uso indebido de herramientas aparecen en el explorador de señales de Datadog Security. Estas señales pueden proporcionar:
+
+- **Detección de amenazas**: contexto de ataque basado en sus reglas de detección configuradas
+- **Información sobre acción**: información sobre acciones bloqueadas o permitidas según la configuración de sus reglas
+- **Contexto de investigación enriquecido**: categorías de ataque detectadas, resultados de evaluación de AI Guard y enlaces a tramos de AI Guard relacionados para un análisis integral
+- **Runbooks personalizados**: orientación de remediación personalizada y procedimientos de respuesta para escenarios de amenazas específicos
+
+Para ayudarle a priorizar sus esfuerzos de remediación, AI Guard asigna automáticamente un nivel de gravedad a cada señal de seguridad. Puede crear [reglas de detección personalizadas](#create-detection-rules) para personalizar los niveles de gravedad y definir respuestas de seguridad específicas.
+
+## Crear reglas de detección {#create-detection-rules}
+
+Puede crear reglas de detección personalizadas definiendo umbrales para cuando desee recibir notificaciones; por ejemplo, más de 5 `DENY` acciones en 10 minutos. Cuando las evaluaciones de AI Guard superan esos umbrales, se generan señales de seguridad.
+
+Para crear reglas de detección de AI Guard:
+1. En Datadog, vaya al [explorador de reglas de detección de AI Guard][2] y haga clic en {{< ui >}}New Rule{{< /ui >}}.
+ {{< img src="security/ai_guard/ai_guard_detection_rules_1.png" alt="Explorador de reglas de detección de AI Guard" style="width:100%;" >}}
+1. En {{< ui >}}Define your Real-time rule{{< /ui >}}, elija el tipo de regla que desea crear.
+1. En {{< ui >}}Define Search Queries{{< /ui >}}, defina los tipos de etiquetas para los que desea crear señales. Puede utilizar los siguientes atributos de AI Guard para filtrar y dirigirse a patrones de amenazas específicos:
+
+
+
+ | Etiqueta |
+ Descripción |
+ Valores posibles |
+
+
+
+
+ @ai_guard.action |
+ Filtrar por el resultado de la evaluación de AI Guard |
+ ALLOW o DENY |
+
+
+ @ai_guard.attack_categories |
+ Dirigirse a tipos de ataque específicos |
+
+
+ jailbreakindirect-prompt-injectiondestructive-tool-calldenial-of-service-tool-callsecurity-exploitauthority-overriderole-playinstruction-overrideobfuscationsystem-prompt-extractiondata-exfiltration
+ |
+
+
+ @ai_guard.blocked |
+ Filtrar según si una acción en la traza fue bloqueada |
+ true o false |
+
+
+ @ai_guard.tools |
+ Filtrar por nombres de herramientas específicos involucrados en la evaluación |
+ get_user_profile, user_recent_transactions, etc. |
+
+
+ @ai_guard.sds.categories |
+ Filtrar por categorías de datos confidenciales detectadas por Sensitive Data Scanner |
+ credentials, email_address, etc. |
+
+
+ @ai_guard.sds.rule_tags |
+ Filtrar por etiquetas de regla de datos confidenciales específicas |
+ aws_access_key_id, aws_secret_access_key, claude_api_key, email_address, etc. |
+
+
+
+1. En {{< ui >}}Define Rule Conditions{{< /ui >}}:
+ 1. Defina sus condiciones de umbral, si corresponde al tipo de regla que eligió.
+ 1. Establezca el nivel de gravedad de las señales de seguridad que AI Guard genera con esta regla.
+ 1. Elija quién debe recibir notificaciones sobre nuevas señales y con qué frecuencia.
+ 1. Elija las respuestas de seguridad que se tomarán, como el bloqueo automatizado de IP o de usuario, y el marcado de IP.
+ 1. Configure ajustes adicionales, como actualizar la misma señal en lugar de crear una nueva si AI Guard detecta nuevos valores dentro de una cantidad de tiempo determinada, y disminuir la gravedad de la señal para entornos que no son de producción.
+1. En {{< ui >}}Describe your Playbook{{< /ui >}}, personalice la notificación y defina las etiquetas que se enviarán con las señales.
+1. Haga clic en {{< ui >}}Save Rule{{< /ui >}}.
+
+Para obtener capacidades de reglas de detección más completas, consulte [reglas de detección][3].
+
+## Investigar señales {#investigate-signals}
+
+Para ver e investigar las señales de seguridad de AI Guard, y correlacionarlas con otros eventos de seguridad, puede ver las señales en dos lugares:
+- [Explorador de señales de seguridad de protección de aplicaciones y API][4]
+- [Explorador de señales de seguridad de Cloud SIEM][5]
+
+ En el explorador de señales de seguridad de Cloud SIEM, junto a la barra de búsqueda, haga clic en el icono {{< ui >}}Filter{{< /ui >}} y seleccione la casilla de verificación {{< ui >}}App & API Protection{{< /ui >}} para ver las señales de AI Guard.
+
+Los exploradores de señales de seguridad le permiten filtrar, priorizar e investigar las señales de AI Guard junto con otras amenazas de seguridad de aplicaciones, proporcionando una visualización unificada de su postura de seguridad.
+
+Puede crear o vincular casos directamente desde una señal de seguridad de AI Guard, y hacer clic en cualquier señal para abrir un panel lateral que contiene contexto adicional.
+
+## Obtenga contexto adicional con tramos {#get-additional-context-with-spans}
+
+Los tramos de AI Guard ofrecen información detallada sobre las evaluaciones que realizó y por qué. Cuando abre un tramo desde la página [Investigar][6] o desde una señal, puede obtener contexto sobre los prompts específicos que utilizó su Agent, leer las entradas y salidas exactas, y ver cualquier categoría de ataque que contribuyó a que AI Guard evaluara una llamada de herramienta como insegura.
+
+### Obtenga contexto sobre un tramo {#get-context-on-a-span}
+
+Cuando hace clic en un tramo en el explorador, puede ver:
+- El servicio y el entorno en los que ocurrieron las solicitudes
+- La [política de bloqueo][7] configurada para ese servicio, la cual determina si AI Guard bloquea las solicitudes inseguras, o las detecta y etiqueta sin bloquearlas
+- El usuario que interactuó con el Agent
+- Las entradas y salidas específicas de su Agent, y si provinieron de LLM o herramientas externas
+- Si AI Guard evaluó cada solicitud como segura o insegura
+- Si AI Guard bloqueó la solicitud
+- Si AI Guard evaluó la llamada como insegura, qué categorías de ataque incluyó
+- Si la solicitud incluyó datos confidenciales, y de ser así, qué tipo de datos confidenciales
+- Etiquetas adicionales, que puede usar para filtrar tramos en el explorador
+
+Además, puede hacer clic en {{< ui >}}Explore in graph view{{< /ui >}} para ver las solicitudes de la conversación graficadas, o ver el tramo en [APM][8] o [Agent Observability][9].
+
+## Lecturas adicionales {#further-reading}
+
+{{< partial name="whats-next/whats-next.html" >}}
+
+[1]: /es/security/application_security/security_signals/
+[2]: https://app.datadoghq.com/security/ai-guard/settings/detection-rules
+[3]: /es/security/detection_rules/
+[4]: https://app.datadoghq.com/security/ai-guard/signals
+[5]: https://app.datadoghq.com/security/siem/signals
+[6]: https://app.datadoghq.com/security/ai-guard/investigate
+[7]: /es/security/ai_guard/setup/#blocking-policy
+[8]: /es/tracing/
+[9]: /es/llm_observability/
\ No newline at end of file
diff --git a/hugo/content/es/security/application_security/threat_protection/security_signals/_index.md b/hugo/content/es/security/application_security/threat_protection/security_signals/_index.md
new file mode 100644
index 00000000000..430a4759edd
--- /dev/null
+++ b/hugo/content/es/security/application_security/threat_protection/security_signals/_index.md
@@ -0,0 +1,167 @@
+---
+aliases:
+- /es/security/application_security/security_signals/
+- /es/security/application_security/threats/security_signals
+further_reading:
+- link: /security/default_rules/?category=cat-application-security#cat-application-security
+ tag: Documentación
+ text: Explore las reglas de detección de amenazas OOTB de AAP
+- link: /security/application_security/threat_protection/policies/custom_rules/
+ tag: Documentación
+ text: Configure reglas personalizadas de detección de amenazas de AAP
+- link: /security/application_security/how-it-works/threat-intelligence/
+ tag: Documentación
+ text: Inteligencia de amenazas de AAP
+title: Investigue las señales de seguridad
+---
+{{< site-region region="gov" >}}
+
+App and API Protection se encuentra en versión preliminar en el sitio de Datadog Government US1-FED.
+
+{{< /site-region >}}
+
+## Descripción general {#overview}
+
+Las señales de seguridad de AAP se crean cuando Datadog detecta una amenaza basada en una regla de detección. Vea, busque, filtre e investigue señales de seguridad en el [Explorador de señales][2], o configure [Notification Rules][8] para enviar señales a herramientas de terceros.
+
+
+
+## Columnas del Explorador de señales{#signals-explorer-columns}
+
+El Explorador de señales muestra las siguientes columnas.
+
+{{< ui >}}Severity{{< /ui >}}
+: Existen cinco estados de gravedad: {{< ui >}}Info{{< /ui >}}, {{< ui >}}Low{{< /ui >}}, {{< ui >}}Medium{{< /ui >}}, {{< ui >}}High{{< /ui >}} y {{< ui >}}Critical{{< /ui >}}. {{< ui >}}High{{< /ui >}} y {{< ui >}}Critical{{< /ui >}} indican un impacto importante en la disponibilidad del servicio o un compromiso activo.
+
+{{< ui >}}Title{{< /ui >}}
+: El nombre de la señal. Los títulos podrían actualizarse cuando se correlacionan nuevos datos, lo que altera el impacto evaluado del ataque.
+
+{{< ui >}}Service/Env{{< /ui >}}
+: El servicio y el entorno identificados en el ataque. Pase el cursor sobre el nombre del servicio para enlazar a la página del servicio y al repositorio de código, y para ver quién está de guardia para el servicio.
+
+{{< ui >}}Entities{{< /ui >}}
+: Los atacantes y las víctimas de un ataque. Los atacantes se identifican mediante direcciones IP. Las víctimas se identifican como usuarios autenticados. Pase el cursor sobre la lista de IP y luego haga clic en una IP para ver detalles como {{< ui >}}Threat Intelligence{{< /ui >}} y {{< ui >}}Security Activity{{< /ui >}}.
+
+{{< ui >}}Triage State{{< /ui >}}
+: Puede asignar un responsable y establecer un estado de clasificación para la señal. Los estados disponibles son {{< ui >}}Open{{< /ui >}}, {{< ui >}}Under Review{{< /ui >}} y {{< ui >}}Archived{{< /ui >}}.
+
+{{< ui >}}Creation Date{{< /ui >}}
+: La fecha en la que se creó la señal por primera vez. Las señales se ordenan por fecha de forma predeterminada.
+
+## Filtrar señales de seguridad {#filter-security-signals}
+
+Para filtrar las señales de seguridad en el [Explorador de señales][2], utilice la consulta de búsqueda `@workflow.triage.state:`, donde `` es el estado por el que desea filtrar (`open`, `under_review` o `archived`). También puede utilizar la faceta {{< ui >}}Signal State{{< /ui >}} en el panel de facetas.
+
+## Clasificar una señal {#triage-a-signal}
+
+Puede clasificar una señal asignándola a un usuario para una investigación más detallada. El usuario asignado puede entonces realizar un seguimiento de su revisión actualizando el estado de la señal.
+
+1. En la página [Explorador de señales][2], haga clic en el icono de perfil de usuario en la columna {{< ui >}}Triage State{{< /ui >}}.
+2. Seleccione un usuario para asignar la señal.
+3. Para actualizar el estado de la señal de seguridad, haga clic en el menú desplegable de estado de clasificación y seleccione un estado. El estado predeterminado es {{< ui >}}Open{{< /ui >}}.
+ - {{< ui >}}Open{{< /ui >}}: La señal aún no ha sido resuelta.
+ - {{< ui >}}Under Review{{< /ui >}}: La señal está siendo investigada activamente. Desde el estado {{< ui >}}Under Review{{< /ui >}}, puede mover la señal a {{< ui >}}Archived{{< /ui >}} o {{< ui >}}Open{{< /ui >}} según sea necesario.
+ - {{< ui >}}Archived{{< /ui >}}: La detección que causó la señal ha sido resuelta. Desde el estado {{< ui >}}Archived{{< /ui >}}, puede mover la señal de vuelta a {{< ui >}}Open{{< /ui >}} si se encuentra dentro de los 30 días posteriores a cuando la señal fue detectada originalmente.
+
+**Nota**: Para modificar señales de seguridad, debe tener el permiso `security_monitoring_signals_write`. Consulte [Control de acceso basado en roles][9] para obtener más información sobre los roles predeterminados de Datadog y los permisos de control de acceso basado en roles granulares disponibles para App y API Protection.
+
+## Declarar un incidente {#declare-an-incident}
+
+Utilice [Incident Management][4] para crear un incidente para una señal de seguridad.
+
+Declare un incidente si:
+
+- Un problema está afectando o podría estar afectando a los clientes.
+- Usted considera que un problema (incluso si es interno) debe abordarse como una emergencia.
+
+Si no sabe si debe declarar un incidente, notifique a otros usuarios y aumente la gravedad según corresponda.
+
+1. En la página [Explorador de señales][2], seleccione una señal de seguridad para abrir su panel de detalles.
+2. En el panel de señales, haga clic en {{< ui >}}Declare Incident{{< /ui >}} o seleccione la flecha desplegable y seleccione {{< ui >}}Add to an existing incident{{< /ui >}}.
+3. Cuando declare un nuevo incidente, en la configuración de {{< ui >}}Declare Incident{{< /ui >}}, configure el incidente especificando detalles como el nivel de gravedad y el comandante del incidente.
+ 1. Estime el impacto. Los niveles de gravedad van desde SEV-1 (crítico) hasta SEV-5 (impacto menor). En caso de duda, elija siempre la gravedad más alta.
+4. Haga clic en {{< ui >}}Declare Incident{{< /ui >}}.
+
+## Ejecute un flujo de trabajo {#run-a-workflow}
+
+Utilice [Workflow Automation][5] para activar manualmente un flujo de trabajo para una señal de seguridad.
+
+1. Asegúrese de que el flujo de trabajo que desea ejecutar tenga un activador de seguridad.
+2. En la página [Explorador de señales][2], abra una señal de seguridad.
+3. En la sección {{< ui >}}Respond{{< /ui >}}, haga clic en {{< ui >}}Run Workflow{{< /ui >}}.
+4. En {{< ui >}}Run a workflow{{< /ui >}}, seleccione el flujo de trabajo que desea ejecutar o haga clic en {{< ui >}}New Workflow{{< /ui >}}.
+ - Dependiendo del flujo de trabajo que seleccione, es posible que deba ingresar parámetros de entrada adicionales.
+ - Si seleccionó {{< ui >}}New Workflow{{< /ui >}}, se abrirá Ejecutar un flujo de trabajo de seguridad. Para obtener más información sobre los flujos de trabajo, consulte [Workflow Automation][5].
+5. Haga clic en {{< ui >}}Run{{< /ui >}}.
+
+## Revise y remedie {#review-and-remediate}
+
+1. En la página [Signals Explorer][2], abra una señal de seguridad.
+2. En los detalles de la señal, vea cada una de las secciones, como {{< ui >}}What Happened{{< /ui >}}, {{< ui >}}Activity Summary{{< /ui >}} y {{< ui >}}Detection Rule{{< /ui >}}.
+3. Revise {{< ui >}}Next Steps{{< /ui >}} y tome medidas:
+ - Haga clic en {{< ui >}}Block all Attacking IPs{{< /ui >}} (por una duración específica o de forma permanente).
+ - Haga clic en {{< ui >}}Automated Attacker Blocking{{< /ui >}} (según las reglas de [detección][10]). Esta configuración requiere el permiso `Protect Write` de App and API Protection.
+ - Haga clic en [{{< ui >}}Block with Edge WAF{{< /ui >}}][11].
+
+## Acciones masivas {#bulk-actions}
+
+Cuando selecciona una o más señales, puede usar {{< ui >}}Bulk Actions{{< /ui >}} para realizar lo siguiente.
+
+### Establecer estado {#set-state}
+
+Establezca el estado de clasificación en {{< ui >}}Open{{< /ui >}}, {{< ui >}}Under Review{{< /ui >}} o {{< ui >}}Archived{{< /ui >}}.
+
+### Asigne la señal a usuarios {#assign-the-signal-to-users}
+
+Seleccione {{< ui >}}Assign selection{{< /ui >}} y luego seleccione el o los usuarios que desea asignar a la señal.
+
+Seleccione {{< ui >}}Remove all assignments{{< /ui >}} para restablecer la asignación de la señal a ninguno.
+
+### Case Management {#case-management}
+
+Datadog [Case Management][6] ofrece un lugar centralizado para clasificar, realizar un seguimiento y solucionar problemas detectados por Datadog y por integraciones de terceros.
+
+1. En la página [Signals Explorer][2], seleccione una señal de seguridad.
+2. En {{< ui >}}Bulk Actions{{< /ui >}}, seleccione {{< ui >}}Create a case{{< /ui >}}.
+3. Seleccione {{< ui >}}Create a case{{< /ui >}} o {{< ui >}}Add to an existing case{{< /ui >}} para agregar la señal a un caso existente.
+4. Ingrese un título y una descripción opcional.
+5. Haga clic en {{< ui >}}Create Case{{< /ui >}}.
+
+Cuando hace clic en {{< ui >}}Create Case{{< /ui >}}, se le dirige a Case Management y al proyecto que seleccionó.
+
+## Vistas guardadas {#saved-views}
+
+Puede guardar diferentes configuraciones del Explorador de señales como vistas. Por ejemplo, podría filtrar el explorador para mostrar todas las señales no asignadas y luego guardarlo como una vista.
+
+Cuando una configuración se guarda como una vista, usted y sus compañeros de equipo pueden usarla más tarde.
+
+Una vista contiene las selecciones actuales del explorador para:
+
+- Tiempo y consulta
+- Columnas mostradas y ordenamiento
+- Configuración de agregación de análisis
+- Visibilidad de la línea de tiempo
+- Facetas mostradas
+- Agrupar por regla de detección
+
+1. Para guardar una vista, configure el explorador para mostrar la vista que desea y luego haga clic en {{< ui >}}Save{{< /ui >}}.
+2. Ingrese un nombre para la vista y luego seleccione los equipos con los que desea compartirla.
+3. Haga clic en {{< ui >}}Save{{< /ui >}}.
+
+Para ver todas las vistas guardadas, haga clic en {{< ui >}}Views{{< /ui >}} junto al título de la página {{< ui >}}Signals Explorer{{< /ui >}}.
+
+## Lecturas adicionales {#further-reading}
+
+{{< partial name="whats-next/whats-next.html" >}}
+
+
+[1]: https://app.datadoghq.com/services?lens=Security
+[2]: https://app.datadoghq.com/security/appsec/signals?query=%40workflow.rule.type%3A%22Application%20Security%22&column=time&order=desc&viz=stream&start=1694726477747&end=1695331277747&paused=false
+[4]: /es/incident_response/incident_management/
+[5]: /es/actions/workflows/
+[6]: /es/incident_response/work_management/
+[7]: https://app.datadoghq.com/security/appsec?
+[8]: /es/security/notifications/rules/
+[9]: /es/account_management/rbac/permissions/#cloud-security-platform
+[10]: /es/security/application_security/threat_protection/policies/#respond-to-threats-in-real-time-by-automating-attacker-blocking
+[11]: /es/security/application_security/threat_protection/policies/#blocking-attack-attempts-with-in-app-waf
\ No newline at end of file
diff --git a/hugo/content/es/security/cloud_security_management/setup/agent/kubernetes.md b/hugo/content/es/security/cloud_security_management/setup/agent/kubernetes.md
index afa14eca258..a915e126731 100644
--- a/hugo/content/es/security/cloud_security_management/setup/agent/kubernetes.md
+++ b/hugo/content/es/security/cloud_security_management/setup/agent/kubernetes.md
@@ -8,24 +8,23 @@ code_lang_weight: 60
title: Configuración de Cloud Security en Kubernetes
type: multi-code-lang
---
-
-Sigue las siguientes instrucciones para activar Misconfigurations y Vulnerability Management.
+Utilice las siguientes instrucciones para habilitar Misconfigurations y Vulnerability Management.
{{< partial name="security-platform/CSW-billing-note.html" >}}
-## Requisitos previos
+## Requisitos previos {#prerequisites}
-- Versión más reciente del Datadog Agent. Para obtener instrucciones de instalación, consulta [Empezando con el Agent][5] o instala el Agent desde la [interfaz de usuario Datadog][6].
+- Última versión del Datadog Agent. Para obtener instrucciones de instalación, consulte [Getting Started with the Agent][5] o instale el Agent desde la [Datadog UI][6].
-**Nota**: La recopilación de SBOM no es compatible con la función de transmisión de imágenes en Google Kubernetes Engine (GKE). Para desactivarla, consulta la sección [Desactivar la transmisión de imágenes][7] de la documentación de GKE.
+**Nota**: La recopilación de SBOM no es compatible con la función de transmisión de imágenes en Google Kubernetes Engine (GKE). Para deshabilitarla, consulte la sección [Deshabilitar la transmisión de imágenes][7] de la documentación de GKE.
-## Instalación
+## Instalación {#installation}
{{< tabs >}}
-{{% tab "Datadog Operador" %}}
+{{% tab "Datadog Operator" %}}
-1. Añade lo siguiente a la sección `spec` del archivo `datadog-agent.yaml`:
+1. Agregue lo siguiente a la sección `spec` del archivo `datadog-agent.yaml`:
```yaml
# datadog-agent.yaml file
@@ -35,27 +34,36 @@ Sigue las siguientes instrucciones para activar Misconfigurations y Vulnerabilit
name: datadog
spec:
features:
+ # Enables Misconfigurations
cspm:
enabled: true
hostBenchmarks:
enabled: true
- # Enables the image metadata collection and Software Bill of Materials (SBOM) collection
+
+ # Enables 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 scanning of application libraries in addition to OS packages (Agent 7.70+)
+ analyzers: ["os", "languages"]
# Enables Host Vulnerability Management
host:
enabled: true
+ # Enables scanning of application libraries in addition to OS packages (Agent 7.70+)
+ analyzers: ["os", "languages"]
+
+ # Enables runtime package prioritization (Preview, Agent 7.79+)
+ # See Runtime Package Prioritization section below.
+ enrichment:
+ usage:
+ enabled: true
```
-2. Aplica los cambios y reinicia el Agent.
+2. Aplique los cambios y reinicie el Agent.
[2]: https://github.com/DataDog/datadog-operator/blob/main/docs/configuration.v2alpha1.md
@@ -63,7 +71,7 @@ Sigue las siguientes instrucciones para activar Misconfigurations y Vulnerabilit
{{% tab "Helm" %}}
-1. Añade lo siguiente a la sección `datadog` del archivo `datadog-values.yaml`:
+1. Agregue lo siguiente a la sección `datadog` del archivo `datadog-values.yaml`:
```yaml
# datadog-values.yaml file
@@ -74,71 +82,208 @@ Sigue las siguientes instrucciones para activar Misconfigurations y Vulnerabilit
enabled: true
host_benchmarks:
enabled: true
+
+ # Enables Software Bill of Materials (SBOM) collection
sbom:
+ # Enables Container Vulnerability Management
containerImage:
enabled: true
-
- # Uncomment the following line if you are using Google Kubernetes Engine (GKE) or Amazon Elastic Kubernetes (EKS)
- # uncompressedLayersSupport: true
+ # Enables scanning of application libraries in addition to OS packages (Agent 7.70+)
+ analyzers: ["os", "languages"]
# Enables Host Vulnerability Management
host:
enabled: true
+ # Enables scanning of application libraries in addition to OS packages (Agent 7.70+)
+ analyzers: ["os", "languages"]
- # Enables Container Vulnerability Management
- # Image collection is enabled by default with Datadog Helm version `>= 3.46.0`
- # containerImageCollection:
- # enabled: true
+ # Enables runtime package prioritization (Preview, Agent 7.79+)
+ # See Runtime Package Prioritization section below.
+ enrichment:
+ usage:
+ enabled: true
```
-2. Reinicia el Agent.
+2. Reinicie el Agent.
{{% /tab %}}
{{% tab "DaemonSet" %}}
-Añade la siguiente configuración a la sección `env` de `security-agent` y `system-probe` en el archivo `daemonset.yaml`:
+1. Agregue las siguientes variables de entorno a cada contenedor del Agent en el archivo `daemonset.yaml`, incluyendo `agent`, `security-agent` y `system-probe`. Estas variables habilitan Misconfigurations, Vulnerability Management, el escaneo de imágenes de contenedores basado en montaje y la priorización de paquetes en tiempo de ejecución.
+
+ ```yaml
+ - name: DD_COMPLIANCE_CONFIG_ENABLED
+ value: "true"
+ - name: DD_COMPLIANCE_CONFIG_HOST_BENCHMARKS_ENABLED
+ value: "true"
+ - name: DD_SBOM_ENABLED
+ value: "true"
+ - name: DD_SBOM_CONTAINER_IMAGE_ENABLED
+ value: "true"
+ - name: DD_SBOM_HOST_ENABLED
+ value: "true"
+ - name: DD_SBOM_CONTAINER_IMAGE_USE_MOUNT
+ value: "true"
+ - name: DD_SBOM_ENRICHMENT_USAGE_ENABLED
+ value: "true"
+ - name: HOST_ROOT
+ value: /host/root
+ ```
+
+ Si su DaemonSet monta la raíz del servidor en una ruta diferente, establezca `HOST_ROOT` en esa ruta de montaje en cada contenedor del Agent.
+
+2. Establezca `hostPID: true` en la especificación del pod y agregue el siguiente `securityContext` al contenedor `agent`. Estos ajustes son necesarios para el escaneo de imágenes de contenedores basado en montaje con `DD_SBOM_CONTAINER_IMAGE_USE_MOUNT=true`.
-```bash
- # Source: datadog/templates/daemonset.yaml
- apiVersion:app/1
- kind: DaemonSet
- [...]
- spec:
- [...]
- spec:
+ ```yaml
+ # Source: datadog/templates/daemonset.yaml
+ apiVersion: apps/v1
+ kind: DaemonSet
[...]
- containers:
+ spec:
[...]
- - name: agent
- [...]
- - name: system-probe
- [...]
- env:
- - name: DD_COMPLIANCE_CONFIG_ENABLED
- value: "true"
- - name: DD_COMPLIANCE_CONFIG_HOST_BENCHMARKS_ENABLED
- value: "true"
- - name: DD_CONTAINER_IMAGE_ENABLED
- value: "true"
- - name: DD_SBOM_ENABLED
- value: "true"
- - name: DD_SBOM_CONTAINER_IMAGE_ENABLED
- value: "true"
- - name: DD_SBOM_HOST_ENABLED
- value: "true"
- - name: DD_SBOM_CONTAINER_IMAGE_USE_MOUNT
- value: "true"
+ template:
[...]
+ spec:
+ hostPID: true
+ containers:
+ [...]
+ - name: agent
+ [...]
+ securityContext:
+ capabilities:
+ add:
+ - SYS_ADMIN
+ readOnlyRootFilesystem: true
+ appArmorProfile:
+ type: Unconfined
+ ```
+
+3. Reinicie el Agent.
+
+{{% /tab %}}
+
+{{< /tabs >}}
+
+**Nota**: `enrichment.usage.enabled: true` requiere Datadog Agent **7.79.0 o posterior**. Consulte la sección [Priorización de paquetes en tiempo de ejecución](#runtime-package-prioritization-preview) para conocer los requisitos.
+
+**Nota**: El `languages` analyzer requiere Datadog Agent **7.70 o posterior**. Cuando está habilitado, detecta vulnerabilidades en las bibliotecas de aplicaciones administradas por los administradores de paquetes a continuación, además de los paquetes del SO. Cuando se omite el campo `analyzers`, Datadog solo escanea los paquetes del SO para las imágenes de contenedor.
+
+### Administradores de paquetes de bibliotecas de aplicaciones compatibles {#supported-application-library-package-managers}
+
+El `languages` analyzer cubre los siguientes ecosistemas de paquetes:
+
+| Ecosistema | Administrador de paquetes/formato |
+|-----------|------------------------|
+| Ruby | Bundler, GemSpec |
+| Rust | Cargo, binario de Rust |
+| PHP | Composer |
+| Java | Jar, Maven (pom.xml), Gradle lock, Sbt lock |
+| JavaScript | npm (package-lock.json), Yarn, pnpm, Node package |
+| .NET | NuGet, .NET Core, PackagesProps |
+| Python | Python package (egg), pip, Pipenv, Poetry, uv, Conda package, Conda environment |
+| Go | Go binary, Go modules |
+| C/C++ | Conan lock |
+| Swift / Objective-C | CocoaPods, Swift |
+| Dart | PubSpec lock |
+| Elixir | Mix lock |
+| Julia | Julia |
+
+## Priorización de paquetes en tiempo de ejecución (versión preliminar) {#runtime-package-prioritization-preview}
+
+La priorización de paquetes en tiempo de ejecución identifica qué paquetes en una imagen de contenedor se utilizan durante la ejecución, para que pueda priorizar las vulnerabilidades en el código que se ejecuta sobre las vulnerabilidades en los paquetes que están instalados pero nunca se ejecutan.
+
+Cuando está habilitado, el Agente utiliza eBPF para observar el acceso a archivos en sus cargas de trabajo y añade estas señales a los hallazgos de vulnerabilidad para esa imagen:
+
+| Señal | Qué le indica |
+|--------|-------------------|
+| El paquete se está ejecutando | Se observó que los archivos del paquete fueron accedidos por un proceso en ejecución. |
+| Accedido por proceso root | El paquete fue accedido por un proceso que se ejecuta como root (UID 0). |
+| Binario SUID presente | El paquete contiene un binario con el bit SUID establecido, lo cual puede permitir la escalada de privilegios. |
+
+*Package is running* alimenta la dimensión de **Reachability** del [Runtime Prioritization Engine][9]. Para consultar estas señales directamente, consulte [Filter findings by runtime signals][10].
+
+**Requisitos**:
+- Datadog Agent **7.79.0 o posterior**. En Kubernetes, utilice **7.81.0 o posterior** para obtener la cobertura de señales más completa.
+- Solo Linux (dependencia de eBPF). Consulte [Workload Protection setup][11] para conocer las distribuciones y versiones de kernel compatibles.
+
+Las señales de tiempo de ejecución se aplican a los paquetes instalados por un administrador de paquetes del sistema operativo (`apt`, `yum` o `apk`) en los hallazgos de vulnerabilidad de imágenes de contenedor.
+
+{{< tabs >}}
+
+{{% tab "Datadog Operator" %}}
+
+Añada el bloque `enrichment` a la sección `sbom` de su archivo `datadog-agent.yaml`:
+
+```yaml
+spec:
+ features:
+ sbom:
+ enabled: true
+ containerImage:
+ enabled: true
+ # Enables runtime package prioritization (Preview, Agent 7.79+)
+ enrichment:
+ usage:
+ enabled: true
+```
+
+Aplique los cambios y reinicie el Agent.
+
+{{% /tab %}}
+
+{{% tab "Helm" %}}
+
+Añada el bloque `enrichment` a la sección `sbom` de su archivo `datadog-values.yaml`:
+
+```yaml
+datadog:
+ sbom:
+ containerImage:
+ enabled: true
+ # Enables runtime package prioritization (Preview, Agent 7.79+)
+ enrichment:
+ usage:
+ enabled: true
+```
+
+Reinicie el Agent.
+
+{{% /tab %}}
+
+{{% tab "DaemonSet" %}}
+
+Establezca `hostPID: true` en la especificación del pod y añada las siguientes variables de entorno a cada contenedor de Agent en su archivo `daemonset.yaml`, incluyendo `agent`, `security-agent` y `system-probe`:
+
+```yaml
+# Pod spec
+hostPID: true
+
+# Add to each Agent container's env section.
+- name: DD_SBOM_ENABLED
+ value: "true"
+- name: DD_SBOM_CONTAINER_IMAGE_ENABLED
+ value: "true"
+- name: DD_SBOM_ENRICHMENT_USAGE_ENABLED
+ value: "true"
```
+Reinicie el Agent.
+
{{% /tab %}}
+
{{< /tabs >}}
+Para verificar la configuración, filtre los hallazgos de vulnerabilidad por [runtime signals][10].
+
[1]: /es/security/cloud_security_management/misconfigurations/
[2]: /es/security/threats
[3]: /es/security/cloud_security_management/vulnerabilities
[4]: /es/security/cloud_security_management/setup#supported-deployment-types-and-features
[5]: /es/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
+[7]: https://cloud.google.com/kubernetes-engine/docs/how-to/image-streaming#disable
+[8]: /es/security/workload_protection/
+[9]: /es/security/cloud_security_management/triage_and_prioritize/runtime_prioritization_engine/
+[10]: /es/security/cloud_security_management/triage_and_prioritize/runtime_prioritization_engine/#filter-findings-by-runtime-signals
+[11]: /es/security/workload_protection/setup/
\ No newline at end of file
diff --git a/hugo/content/es/security/cloud_siem/ingest_and_enrich/open_cybersecurity_schema_framework/_index.md b/hugo/content/es/security/cloud_siem/ingest_and_enrich/open_cybersecurity_schema_framework/_index.md
index 2a16e5add00..c3811681ed3 100644
--- a/hugo/content/es/security/cloud_siem/ingest_and_enrich/open_cybersecurity_schema_framework/_index.md
+++ b/hugo/content/es/security/cloud_siem/ingest_and_enrich/open_cybersecurity_schema_framework/_index.md
@@ -5,99 +5,107 @@ disable_toc: false
further_reading:
- link: logs/processing/pipelines
tag: Documentación
- text: Pipelines de procesamiento de logs
+ text: Canalizaciones de procesamiento de registros
+- link: https://www.datadoghq.com/blog/cloud-siem-ocsf-processor
+ tag: Blog
+ text: Normalice cualquier registro para Cloud SIEM con el procesador OCSF de Datadog
+- link: https://www.datadoghq.com/blog/cloud-siem-enterprise-security
+ tag: Blog
+ text: 'Datadog Cloud SIEM: Impulsando la innovación en las operaciones de seguridad'
- link: https://www.datadoghq.com/blog/ocsf-common-data-model/
tag: Blog
- text: Normaliza tus datos con el Modelo de datos comunes del OCSF en Cloud SIEM
- de Datadog
-title: Modelo de datos comunes del Open Cybersecurity Schema Framework (OCSF) en Datadog
+ text: Normalice sus datos con el Modelo de Datos Común OCSF en Datadog Cloud SIEM
+- link: https://www.datadoghq.com/blog/cloud-siem-claude-compliance-api-integration/
+ tag: Blog
+ text: Haga un seguimiento de la actividad de Claude Enterprise con Datadog Cloud
+ SIEM
+title: Modelo de Datos Común del Open Cybersecurity Schema Framework (OCSF) en Datadog
---
+## Descripción general {#overview}
-## Información general
-
-Cloud SIEM recopila y analiza datos de una amplia gama de fuentes, como servicios en la nube, cortafuegos, redes, aplicaciones y sistemas TI. Dado que estos servicios emiten datos en diferentes formatos, a menudo se requiere un esfuerzo considerable para normalizar y preparar los logs antes de poder realizar un análisis significativo de las amenazas.
+Cloud SIEM recopila y analiza datos de una amplia gama de fuentes, como servicios en la nube, firewalls, redes, aplicaciones y sistemas de TI. Dado que estos servicios emiten datos en diferentes formatos, a menudo se requiere un esfuerzo significativo para normalizar y preparar los registros antes de que pueda ocurrir un análisis de amenazas significativo.
-El Open Cybersecurity Schema Framework (OCSF) es un estándar de código abierto e independiente del proveedor para organizar y clasificar los datos de eventos de seguridad. Está diseñado para simplificar y unificar la forma en que se estructuran los logs de seguridad en todas las plataformas y productos, lo que permite una detección de amenazas continua y una investigación más rápida.
+El Open Cybersecurity Schema Framework (OCSF) es un estándar de código abierto y neutral respecto al proveedor para organizar y clasificar datos de eventos de seguridad. Está diseñado para simplificar y unificar cómo se estructuran los registros de seguridad en todas las plataformas y productos, lo que permite una detección de amenazas consistente y una investigación más rápida.
-En Datadog, la compatibilidad con OCSF se integra directamente en Datadog Cloud SIEM para que puedas obtener datos de logs estandarizados y normalizados sin necesidad de configuración manual. Los logs de seguridad entrantes se enriquecen automáticamente con atributos compatibles con OCSF en el momento de la ingesta a través de pipelines predefinidos. Todos los valores de OCSF están contenidos en el atributo exclusivo `OCSF` y se suman a los demás procesos que transforman y enriquecen los logs. Consulta [Pipelines OCSF compatibles predefinidos](#supported-out-of-the-box-ocsf-pipelines) para ver una lista de integraciones de Log Management compatibles con OCSF.
+En Datadog, el soporte para OCSF está integrado directamente en Datadog Cloud SIEM para que obtenga datos de registro normalizados y estandarizados sin configuración manual. Los registros de seguridad entrantes se enriquecen automáticamente con atributos compatibles con OCSF en el momento de la ingesta a través de canalizaciones listas para usar (OOTB). Todos los valores de OCSF están contenidos en el atributo `OCSF` y se suman a los otros procesos que transforman y enriquecen los registros. Consulte [Canalizaciones OCSF listas para usar compatibles](#supported-out-of-the-box-ocsf-pipelines) para ver la lista de integraciones de Log Management que admiten OCSF.
La integración de OCSF en Cloud SIEM de Datadog permite:
-* **Reglas de detección simplificadas**: Una estructura de atributos unificada significa que la lógica de detección puede escribirse una vez y aplicarse a múltiples fuentes.
-* **Investigaciones simplificadas**: Los analistas ya no tienen que recordar los formatos específicos de fuente, ya que un solo esquema permite realizar una única consulta a todos los proveedores.
-* **Correlación de fuentes cruzadas**: La lógica de detección puede correlacionar eventos a través de servicios dispares (por ejemplo, phishing y escalada de privilegios).
-* **Mantenimiento escalable de la integración**: OCSF permite expectativas de esquema continuas, incluso cuando se añaden nuevas fuentes de datos.
+* **Reglas de detección simplificadas**: una estructura de atributos unificada significa que la lógica de detección se puede escribir una vez y aplicar en múltiples fuentes.
+* **Investigaciones optimizadas**: los analistas ya no necesitan recordar formatos específicos de la fuente porque un esquema permite una clasificación de consulta única entre proveedores.
+* **Correlación entre fuentes**: La lógica de detección puede correlacionar eventos entre servicios dispares (por ejemplo, phishing y escalada de privilegios).
+* **Mantenimiento de integración escalable**: OCSF permite expectativas de esquema consistentes, incluso a medida que se agregan nuevas fuentes de datos.
-## Modelo OCSF
+## Modelo OCSF {#ocsf-model}
-Para normalizar tus datos de seguridad, OCSF reasigna tus datos basándose en los siguientes componentes:
+Para normalizar sus datos de seguridad, OCSF reasigna sus datos basándose en los siguientes componentes:
-1. [Tipos de datos, atributos, objetos y matrices](#data-types-attributes-objects-and-arrays)
+1. [Tipos de datos, atributos, objetos y arreglos](#data-types-attributes-objects-and-arrays)
1. [Clases y categorías de eventos](#event-categories-and-classes)
-1. [Perfiles](#perfiles)
+1. [Perfiles](#profiles)
1. [Extensiones](#extensions)
-### Tipos de datos, atributos, objetos y matrices
+### Tipos de datos, atributos, objetos y arreglos {#data-types-attributes-objects-and-arrays}
-Tipos de datos, atributos, objetos y matrices son los principales componentes del modelo OCSF.
+Los tipos de datos, atributos, objetos y arreglos son los componentes principales del modelo OCSF.
| Nombre | Descripción |
| ---- | ----------- |
-| Tipos de datos | Los tipos de datos definen elementos de datos como enteros, cadenas, números con coma flotante y valores booleanos. |
-| Atributos | Los atributos son los componentes básicos del marco de trabajo. Se utilizan para proporcionar el lenguaje común de tus datos, independientemente de la fuente. Consulta el [diccionario de atributos][1] para obtener una lista de todos los atributos. |
-| Objetos | Los objetos son colecciones de atributos relacionados que representan las entidades, como un proceso, dispositivo, usuario, malware o archivo. |
-| Matrices | Las matrices admiten cualquiera de los tipos de datos, incluidos los tipos complejos. |
+| Tipos de datos | Los tipos de datos definen los elementos de datos como enteros, cadenas, números de punto flotante y valores booleanos. |
+| Atributos | Los atributos son los bloques de construcción del marco de trabajo. Se utilizan para proporcionar el lenguaje común para sus datos, independientemente de la fuente. Consulte el [diccionario de atributos][1] para obtener una lista de todos los atributos. |
+| Objetos | Los objetos son colecciones de atributos relacionados que representan las entidades, tales como un proceso, dispositivo, usuario, malware o archivo. |
+| Arreglos | Los arreglos admiten cualquiera de los tipos de datos, incluidos los tipos complejos. |
-### Categorías y clases de actos
+### Categorías y clases de eventos {#event-categories-and-classes}
-Los eventos de seguridad dentro del modelo OCSF están organizados en categorías, que son agrupaciones claras que clasifican los eventos basados en su tipo de datos. Consulta [Categorías OCSF][2] para obtener más información y ver una lista de categorías disponibles. Las categorías se dividen a su vez en clases de eventos. Por ejemplo, hay [seis clases][3] para la categoría Identity & Access Management. Consulta [Clases de Eventos OCSF][4] para obtener más información.
+Los eventos de seguridad dentro del modelo OCSF se organizan en categorías, que son agrupaciones de alto nivel que clasifican los eventos según su tipo de datos. Consulte [Categorías OCSF][2] para obtener más información y una lista de las categorías disponibles. Las categorías se dividen a su vez en clases de eventos. Por ejemplo, existen [seis clases][3] para la categoría de Gestión de identidad y acceso. Consulte [Clases de eventos OCSF][4] para obtener más información.
-### Perfiles
+### Perfiles {#profiles}
-Los perfiles son una clase de atributos que se pueden superponer opcionalmente a las clases de eventos y a los objetos que hacen referencia a ellos. Añaden información adicional a una clase de evento existente y son independientes de las categorías de eventos. Consulta [Perfiles OCSF][5] para ver una lista de perfiles y la documentación [Perfiles OCSF][6] para obtener más información.
+Los perfiles son una clase de atributos que puede superponer opcionalmente a las clases de eventos y a los objetos que hacen referencia a ellos. Añaden información adicional a una clase de evento existente y son independientes de las categorías de eventos. Consulte [Perfiles OCSF][5] para obtener una lista de perfiles y la [documentación de Perfiles OCSF][6] para obtener más información.
-### Extensiones
+### Extensiones {#extensions}
-Opcionalmente puedes añadir extensiones, como nuevos atributos, objetos, categorías, perfiles y clases de eventos, a los esquemas OCSF. Consulta [Extensiones OCSF][7] para obtener más información.
+Puede añadir opcionalmente extensiones, como nuevos atributos, objetos, categorías, perfiles y clases de eventos, a los esquemas de OCSF. Consulte [Extensiones OCSF][7] para obtener más información.
-## Pipelines OCSF predefinidos compatibles
+## Canalizaciones OCSF compatibles listas para usar {#supported-out-of-the-box-ocsf-pipelines}
-Las siguientes integraciones de Log Management son compatibles con los pipelines OCSF predefinidos:
+Las siguientes integraciones de Log Management admiten canalizaciones OCSF listas para usar:
{{% cloud-siem-supported-ocsf %}}
-## Consulta Pipelines seguridad \- OCSF
+## Ver pipelines de seguridad - OCSF {#view-security-pipelines-ocsf}
-Cloud SIEM OCSF reasigna datos de logs en [pipelines de integración][8] de Log Management. Consulta [Pipelines OCSF predefinidos compatibles](#supported-out-of-the-box-ocsf-pipelines) para obtener más detalles.
+Cloud SIEM OCSF reasigna los datos de registro en las [canalizaciones de integración][8] de Log Management. Consulte [Canalizaciones OCSF compatibles listas para usar](#supported-out-of-the-box-ocsf-pipelines) para obtener más detalles.
-Para ver la biblioteca de pipelines de integración de una fuente:
+Para ver la Biblioteca de canalizaciones de integración de una fuente:
-1. Ve a [Pipelines de logs][9].
-1. Haz clic en **Browse Pipeline Library** (Buscar en la biblioteca de pipelines).
-1. Busca la integración que te interesa (por ejemplo, Okta) y haz clic en ella.
-1. Para ver los pipelines OCSF de Okta, desplázate hasta el final de la lista de procesadores para ver la integración Okta.
+1. Navegue a [Logs Pipelines][9].
+1. Haga clic en {{< ui >}}Browse Pipeline Library{{< /ui >}}.
+1. Busque y haga clic en la integración que le interesa (por ejemplo, Okta).
+1. Para ver las canalizaciones OCSF para Okta, desplácese hasta el final de la lista de procesadores para la integración de Okta.
-Para ver el pipeline OCSF de solo lectura de una integración fuente:
-1. Ve a [Pipelines de logs][9].
-1. Selecciona tu pipeline.
-1. Desplázate hasta los pipelines OCSF al final de los procesadores del pipeline.
-1. Haz clic en el pipeline OCSF para ver los procesadores de reasignación asociados.
-1. Haz clic en el icono del ojo en el pipeline OCSF para ver información como la siguiente:
+Para ver la canalización OCSF de solo lectura para una integración de fuente:
+1. Navegue a [Logs Pipelines][9].
+1. Seleccione su canalización.
+1. Desplácese hasta las canalizaciones OCSF al final de los procesadores de la canalización.
+1. Haga clic en la canalización OCSF para ver los procesadores de reasignación asociados.
+1. Haga clic en el icono de ojo en la canalización OCSF para ver información como la siguiente:
- Versión del esquema OCSF
- Clase
- Perfil
-**Nota**: La clonación del pipeline principal convierte los pipelines OCSF en pipelines de logs, en lugar de pipelines de seguridad.
+**Nota**: Clonar la canalización principal convierte las canalizaciones OCSF en canalizaciones de registro en lugar de Security pipelines.
-## Ver datos de OCSF en logs
+## Ver datos OCSF en registros {#view-ocsf-data-in-logs}
-Para ver los datos de OCSF en logs:
-1. Ve al [Explorador de logs][10].
-1. Introduce una búsqueda para tus logs.
-1. Haz clic en un log.
-1. En el panel lateral, desplázate hasta los atributos \`ocsf\` JSON para ver datos de OCSF.
+Para ver datos OCSF en registros:
+1. Navegue a [Logs Explorer][10].
+1. Ingrese una búsqueda para sus registros.
+1. Haga clic en un registro.
+1. En el panel lateral, desplácese hacia abajo hasta los atributos JSON `ocsf` para ver los datos de OCSF.
-## Referencias adicionales
+## Lecturas adicionales {#further-reading}
{{< partial name="whats-next/whats-next.html" >}}
diff --git a/hugo/content/es/security/code_security/iac_security/setup.md b/hugo/content/es/security/code_security/iac_security/setup.md
new file mode 100644
index 00000000000..8b7f7abf297
--- /dev/null
+++ b/hugo/content/es/security/code_security/iac_security/setup.md
@@ -0,0 +1,204 @@
+---
+aliases:
+- /es/security/cloud_security_management/setup/iac_scanning/
+further_reading:
+- link: /security/code_security
+ tag: Documentación
+ text: Code Security
+- link: /security/code_security/iac_security
+ tag: Documentación
+ text: IaC Security
+- link: /security/code_security/iac_security/configuration
+ tag: Documentación
+ text: Configure IaC Security
+- link: /security/code_security/iac_security/iac_rules/
+ tag: Documentación
+ text: Reglas de IaC Security
+title: Configure IaC Security
+---
+Utilice las siguientes instrucciones para habilitar IaC Security para Code Security. IaC Security admite múltiples configuraciones de IaC almacenadas en repositorios de GitHub, GitLab o Azure DevOps.
+
+{{< tabs >}}
+{{% tab "GitHub" %}}
+
+### Instale la integración de GitHub {#install-the-github-integration}
+
+Para conectar sus repositorios de GitHub y habilitar los comentarios de PR, consulte las instrucciones de configuración en [Comentarios de solicitud de extracción][1].
+
+### Habilite IaC Security para sus repositorios {#enable-iac-security-for-your-repositories}
+
+Después de configurar la integración de GitHub, habilite IaC Security para sus repositorios.
+
+1. En la [página de configuración de Code Security][2], expanda la sección {{< ui >}}Activate scanning for your repositories{{< /ui >}}.
+1. En {{< ui >}}Select your source code management provider{{< /ui >}}, seleccione {{< ui >}}GitHub{{< /ui >}}.
+1. En {{< ui >}}Select where your scans should run{{< /ui >}}, seleccione {{< ui >}}Datadog{{< /ui >}}.
+1. En {{< ui >}}Connect your GitHub repositories{{< /ui >}}, realice una de las siguientes acciones:
+ - Para conectar una cuenta de GitHub nueva, haga clic en {{< ui >}}Add GitHub Account{{< /ui >}}.
+ - Para habilitar IaC Security para una cuenta existente, haga clic en {{< ui >}}Select repositories{{< /ui >}}, o en {{< ui >}}Edit{{< /ui >}} si Code Security ya está habilitado.
+1. Para habilitar IaC Security, realice una de las siguientes acciones:
+ - Para habilitar IaC Security para todos los repositorios, cambie {{< ui >}}Enable Infrastructure as Code Scanning (IaC){{< /ui >}} a la posición de ENCENDIDO.
+ - Para habilitar IaC Security para un solo repositorio, cambie el interruptor {{< ui >}}IaC{{< /ui >}} a ENCENDIDO para ese repositorio.
+
+[1]: /es/security/code_security/dev_tool_int/pull_request_comments/?tab=github#set-up-pull-request-comments
+[2]: https://app.datadoghq.com/security/configuration/code-security/setup
+
+{{% /tab %}}
+{{% tab "GitLab" %}}
+
+### Instale la integración de GitLab {#install-the-gitlab-integration}
+
+Para conectar sus repositorios de GitLab y habilitar los comentarios en PR, consulte las instrucciones de configuración en [GitLab Source Code][1].
+
+### Habilite IaC Security para sus repositorios {#enable-iac-security-for-your-repositories-1}
+
+Después de configurar la integración de GitLab, habilite IaC Security para sus repositorios.
+
+1. En la [página de configuración de Code Security][2], expanda la sección {{< ui >}}Activate scanning for your repositories{{< /ui >}}.
+1. En {{< ui >}}Select your source code management provider{{< /ui >}}, seleccione {{< ui >}}GitLab{{< /ui >}}.
+1. En {{< ui >}}Select where your scans should run{{< /ui >}}, seleccione {{< ui >}}Datadog{{< /ui >}}.
+1. En {{< ui >}}Connect your GitLab repositories{{< /ui >}}, realice una de las siguientes acciones:
+ - Para conectar una nueva instancia de GitLab, haga clic en {{< ui >}}Connect GitLab Instance{{< /ui >}}.
+ - Para habilitar IaC Security para una cuenta existente, haga clic en {{< ui >}}Select repositories{{< /ui >}}, o en {{< ui >}}Edit{{< /ui >}} si Code Security ya está habilitado.
+1. Para habilitar IaC Security, realice una de las siguientes acciones:
+ - Para habilitar IaC Security para todos los repositorios, cambie {{< ui >}}Enable Infrastructure as Code Scanning (IaC){{< /ui >}} a la posición de ENCENDIDO.
+ - Para habilitar IaC Security para un solo repositorio, cambie el interruptor {{< ui >}}IaC{{< /ui >}} a ENCENDIDO para ese repositorio.
+
+[1]: /es/integrations/gitlab-source-code/#setup
+[2]: https://app.datadoghq.com/security/configuration/code-security/setup
+
+{{% /tab %}}
+{{% tab "Azure DevOps" %}}
+
+### Instale la integración de Azure DevOps {#install-the-azure-devops-integration}
+
+Para conectar sus repositorios de Azure DevOps y habilitar los comentarios en PR, consulte las instrucciones de configuración en [Azure DevOps Source Code][1].
+
+### Habilite IaC Security para sus repositorios {#enable-iac-security-for-your-repositories-2}
+
+Después de configurar la integración de Azure DevOps, habilite IaC Security para sus repositorios.
+
+1. En la [página de configuración de Code Security][2], expanda la sección {{< ui >}}Activate scanning for your repositories{{< /ui >}}
+1. En {{< ui >}}Select your source code management provider{{< /ui >}}, seleccione {{< ui >}}Azure DevOps{{< /ui >}}.
+1. En {{< ui >}}Select where your scans should run{{< /ui >}}, seleccione {{< ui >}}Datadog{{< /ui >}}.
+1. En {{< ui >}}Connect your Azure DevOps repositories{{< /ui >}}, realice una de las siguientes acciones:
+ - Para conectar una nueva organización de Azure DevOps, haga clic en {{< ui >}}Connect Microsoft Entra App{{< /ui >}}.
+ - Para habilitar IaC Security para una cuenta existente, haga clic en {{< ui >}}Select repositories{{< /ui >}}, o en {{< ui >}}Edit{{< /ui >}} si Code Security ya está habilitado.
+1. Para habilitar IaC Security, realice una de las siguientes acciones:
+ - Para habilitar IaC Security para todos los repositorios, cambie {{< ui >}}Enable Infrastructure as Code Scanning (IaC){{< /ui >}} a la posición de ENCENDIDO.
+ - Para habilitar IaC Security para un solo repositorio, cambie el interruptor {{< ui >}}IaC{{< /ui >}} a ENCENDIDO para ese repositorio.
+
+[1]: /es/integrations/azure-devops-source-code/#source-code-functionality
+[2]: https://app.datadoghq.com/security/configuration/code-security/setup
+
+{{% /tab %}}
+{{< /tabs >}}
+
+## Configure IaC con un proveedor de CI genérico {#set-up-iac-with-a-generic-ci-provider}
+
+### Descripción general {#overview}
+
+Si no utiliza GitHub Actions, GitLab CI/CD o Azure DevOps, puede ejecutar el [Datadog IaC Scanner][8] directamente en su canalización de CI. Cargue los resultados del escaneo de IaC a Datadog utilizando la [`datadog-ci` CLI][9].
+
+**Si está ejecutando IaC Security en un repositorio que no es de GitHub**, ejecute el primer escaneo en su rama predeterminada. Si su rama predeterminada utiliza un nombre distinto a `master`, `main`, `default`, `stable`, `source`, `prod` o `develop`, cargue un primer escaneo para su repositorio. Luego, sobrescriba manualmente la rama predeterminada en [{{< ui >}}Repository Settings{{< /ui >}}][10] para que los escaneos futuros de ramas que no sean la predeterminada se carguen y procesen correctamente.
+
+### Requisitos previos {#prerequisites}
+
+- Node.js 20 o posterior y npm
+- `curl`
+- `tar`
+- Permiso para instalar el escáner en `/usr/local/bin`
+
+Configure las siguientes variables de entorno:
+
+| Nombre | Descripción | Requerido | Predeterminado |
+| ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | --------------- |
+| `DD_API_KEY` | Su clave de API de Datadog. Cree esta clave en su [organización de Datadog][4] y almacene la clave como un secreto. | Sí | |
+| `DD_APP_KEY` | Su clave de aplicación. Cree esta clave en su [organización de Datadog][4] e incluya el contexto `code_analysis_read`. Almacene la clave como un secreto. | Sí | |
+| `DD_SITE` | El [sitio de Datadog][5] al que enviar información. Su sitio de Datadog es `datadoghq.com`. | No | `datadoghq.com` |
+
+Agregue lo siguiente a su pipeline de CI:
+
+```bash
+# Set the Datadog site to send information to
+export DD_SITE="datadoghq.com"
+
+# Install dependencies
+npm install -g @datadog/datadog-ci
+
+# Download the latest Datadog IaC Scanner (x86_64/amd64 Linux; see GitHub Releases for arm64 and other platforms)
+export IAC_SCANNER_URL="https://github.com/DataDog/datadog-iac-scanner/releases/latest/download/datadog-iac-scanner_linux_amd64.tar.gz"
+curl -L "${IAC_SCANNER_URL}" -o /tmp/datadog-iac-scanner.tar.gz
+tar xfz /tmp/datadog-iac-scanner.tar.gz -C /tmp
+mv /tmp/datadog-iac-scanner /usr/local/bin/datadog-iac-scanner
+
+# Run the Datadog IaC scanner
+exit_code=0
+/usr/local/bin/datadog-iac-scanner scan -p . -o /tmp || exit_code=$?
+if [ $exit_code -lt 20 -o $exit_code -gt 60 ]; then echo "IaC scan failed" ; exit $exit_code ; fi
+
+# Upload results
+datadog-ci sarif upload /tmp/datadog-iac-scanner-result.sarif
+```
+
+
+ Este ejemplo utiliza la versión de Linux x86_64 (amd64) del Datadog IaC Scanner. El escáner también es compatible con Linux arm64, así como con macOS y Windows. Si está utilizando un sistema operativo o una arquitectura diferente, seleccione la versión adecuada en la página de
GitHub Releases y actualice el
IAC_SCANNER_URL valor.
+
+ Puede importar resultados SARIF de escáneres de infraestructura como código (IaC) de terceros, incluido Checkov, a IaC Security. Consulte
+ Cargue resultados de análisis estático de terceros para herramientas compatibles con SARIF admitidas para SAST. Se requiere Node.js versión 14 o posterior.
+
Las supresiones descartan las violaciones silenciosamente. Si results[ ].suppressions existe, la violación se ignora por completo.
+
+## Lecturas adicionales {#further-reading}
+
+{{< partial name="whats-next/whats-next.html" >}}
+
+[1]: /es/integrations/github/#setup
+[2]: https://app.datadoghq.com/security/configuration/code-security/setup
+[3]: https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sarif
+[4]: /es/account_management/api-app-keys/
+[5]: /es/getting_started/site/
+[6]: https://docs.datadoghq.com/es/security/code_security/static_analysis/setup/?tab=github#upload-third-party-static-analysis-results-to-datadog
+[7]: https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sarif
+[8]: https://github.com/DataDog/datadog-iac-scanner
+[9]: https://github.com/DataDog/datadog-ci?tab=readme-ov-file#sarif
+[10]: https://app.datadoghq.com/source-code/repositories
\ No newline at end of file
diff --git a/hugo/content/es/security/workload_protection/detect_and_monitor/agent_rules/_index.md b/hugo/content/es/security/workload_protection/detect_and_monitor/agent_rules/_index.md
new file mode 100644
index 00000000000..c491dd4463a
--- /dev/null
+++ b/hugo/content/es/security/workload_protection/detect_and_monitor/agent_rules/_index.md
@@ -0,0 +1,38 @@
+---
+description: Aprenda cómo las reglas del Agent determinan qué actividad de tiempo
+ de ejecución recopila y envía el Datadog Agent a Datadog como Agent events.
+disable_toc: false
+title: Agent Rules
+---
+Las reglas del Agent determinan qué actividad de tiempo de ejecución recopila y envía el Datadog Agent a Datadog como Agent events. Estos eventos proporcionan la telemetría que Workload Protection utiliza para la detección de amenazas y la evaluación de la postura de seguridad en tiempo de ejecución. Las reglas de detección y las reglas de hallazgos en el backend de Datadog analizan esos eventos para generar señales y hallazgos de seguridad. Los Agent events capturan la actividad de tiempo de ejecución de bajo nivel de las cargas de trabajo y proporcionan los datos sin procesar de alta fidelidad necesarios para comprender lo que realmente sucede en un sistema, en lugar de depender únicamente de la configuración estática o de escaneos periódicos.
+
+Para reducir el ruido, el volumen de datos y el impacto en el rendimiento, el Agent filtra la actividad benigna o de bajo riesgo antes de enviar eventos a Datadog. Las Agent rules utilizan Datadog Security Language (SECL) para definir este filtrado. Las políticas implementan Agent rules a través de Remote Configuration, archivos de configuración del Agent o Terraform.
+
+## Agent rules preconfiguradas {#ootb-rules}
+
+Workload Protection incluye Agent rules preconfiguradas (OOTB), llamadas default rules, que Datadog administra. Para verlas, consulte [Agent Rules][1] en Datadog. Los ingenieros de seguridad de Datadog mantienen estas reglas. Ellos agregan reglas para comportamientos de malware emergentes, técnicas de ataque en evolución y otras actividades relevantes para la seguridad.
+
+Puede implementar default rules de forma selectiva en entornos o cargas de trabajo, clonarlas para personalizar sus expresiones, refinar su lógica de filtrado o agregar acciones. Para conocer las opciones de implementación, consulte [Policy Management][2].
+
+Las Agent rules pueden recopilar telemetría contextual o hacer coincidir actividades de alta confianza y ejecutar Agent actions. Las backend detection rules analizan Agent events y generan security signals.
+
+## Escriba custom Agent rules en SECL {#write-custom-agent-rules-in-secl}
+
+Las Workload Protection Agent rules utilizan un lenguaje de expresión personalizado llamado SecL para especificar qué eventos observar, hacer coincidir y enviar a Datadog según el contexto de tiempo de ejecución. Para obtener más información, consulte la [guía de SecL][5].
+
+Para crear una Agent rule y una threat detection rule juntas, utilice el Assisted rule creator o el manual flow. Consulte [Create the custom Agent and detection rules together][3] en la documentación de [Detection Rules][4].
+
+
+## Deploy Agent rules with policies {#deploy-agent-rules-with-policies}
+
+Las Agent rules se empaquetan e implementan en policies. Administre policies de forma centralizada en Datadog o mediante Terraform, e impleméntelas en el Agent con Remote Configuration o modificando manualmente los Agent configuration files. Para obtener más información, consulte [Policy Management][2].
+## Utilice variables y acciones {#use-variables-and-actions}
+
+Las variables y acciones extienden las Agent rules más allá de la coincidencia de eventos. Las acciones pueden recopilar telemetría adicional, como hashes de archivos, responder a amenazas u operar con variables SECL. Las variables SECL permiten la construcción de lógica de detección avanzada y con estado basada en máquinas de estado. Para obtener más información, consulte [Variables y acciones][6].
+
+[1]: https://app.datadoghq.com/security/workload-protection/agent-rules?ruleQuery=defaultRule%3Atrue
+[2]: /es/security/workload_protection/detect_and_monitor/agent_rules/policy_management
+[3]: /es/security/workload_protection/detect_and_monitor/detection_and_finding_rules/detection_rules/#create-the-custom-agent-and-detection-rules-together
+[4]: /es/security/workload_protection/detect_and_monitor/detection_and_finding_rules/detection_rules
+[5]: /es/security/workload_protection/detect_and_monitor/agent_rules/secl_guide
+[6]: /es/security/workload_protection/detect_and_monitor/agent_rules/variables_and_actions
\ No newline at end of file
diff --git a/hugo/content/es/security/workload_protection/inventory/_index.md b/hugo/content/es/security/workload_protection/inventory/_index.md
new file mode 100644
index 00000000000..183801cce19
--- /dev/null
+++ b/hugo/content/es/security/workload_protection/inventory/_index.md
@@ -0,0 +1,92 @@
+---
+aliases:
+- /es/security/workload_protection/inventory/coverage_map
+- /es/security/workload_protection/inventory/hosts_and_containers
+- /es/security/workload_protection/inventory/serverless
+description: Evalúe la cobertura de Workload Protection en hosts, ECS Fargate y cargas
+ de trabajo de EKS Fargate, incluyendo el estado de implementación de Agent, políticas
+ y reglas.
+disable_toc: false
+further_reading:
+- link: /security/detection_rules/#mitre-attck-map
+ tag: Documentación
+ text: Mapa de MITRE ATT&CK
+- link: https://app.datadoghq.com/release-notes/review-your-workload-protection-coverage-with-the-coverage-map
+ tag: Nota de la versión
+ text: Revise su cobertura de Workload Protection con el mapa de Cobertura
+title: Cobertura
+---
+Workload Protection [Cobertura][1] proporciona una vista en tiempo real de la cobertura de seguridad en sus hosts, ECS Fargate y cargas de trabajo de EKS Fargate. Utilice Cobertura para evaluar la postura de protección, identificar brechas y actuar sobre cargas de trabajo desprotegidas o mal configuradas.
+
+La cobertura refleja si las políticas y las reglas de Agent se cargaron correctamente. Para saber cómo llegan las políticas a sus Agent, consulte [Habilitar e implementar políticas][5].
+
+Para identificar y abordar las brechas de cobertura, consulte [Revisar y mejorar la cobertura][6].
+
+{{< img src="security/workload_protection/coverage_page/coverage_explorer.png" alt="Vista de explorador de la página de Cobertura que muestra los recursos en una tabla facetada" width="100%">}}
+
+## Vistas {#views}
+
+La cobertura tiene dos vistas. Utilice el interruptor en la parte superior de la página para cambiar entre ellas:
+
+- {{< ui >}}Explorer{{< /ui >}}: Una tabla facetada de sus recursos. Busque y filtre recursos por las facetas {{< ui >}}Agent{{< /ui >}}, {{< ui >}}Rule{{< /ui >}}, {{< ui >}}Policy{{< /ui >}}, {{< ui >}}Infrastructure{{< /ui >}} y {{< ui >}}Container{{< /ui >}}, luego abra un recurso para inspeccionar sus reglas de Agent y el estado de implementación de políticas.
+
+- {{< ui >}}Map{{< /ui >}}: Un mapa visual donde cada recurso aparece como un hexágono coloreado según la gravedad de su estado de cobertura.
+
+{{< img src="security/workload_protection/coverage_page/coverage_map.png" alt="Vista de mapa de la página de Cobertura que muestra los recursos como hexágonos coloreados según el estado de cobertura" width="100%">}}
+
+En ambas vistas, usted puede:
+
+- {{< ui >}}Group by{{< /ui >}} Proveedor de nube, SO, versión del Agent, gravedad o clúster de Kubernetes.
+- Actualice la vista bajo demanda.
+
+Un recurso aparece en Cobertura tan pronto como su Agent carga su conjunto de reglas. Cuando un recurso se desconecta, se elimina de Cobertura en un plazo de 15 minutos.
+
+## Estados de cobertura {#coverage-statuses}
+
+### Estado de cobertura del recurso {#resource-coverage-status}
+
+El estado de cobertura de cada recurso se clasifica en una de dos categorías de gravedad, según las reglas cargadas en él:
+
+| Gravedad | Significado |
+|----------|---------|
+| Aprobado | Todas las reglas se cargaron correctamente o se filtraron según lo esperado. |
+| Error | Una o más reglas tienen errores que deben corregirse, o el recurso informó datos incompletos. |
+
+En la vista de Mapa, los recursos se muestran como hexágonos coloreados según su gravedad. Haga clic en un hexágono para inspeccionar un recurso y ver sus políticas y reglas.
+
+### Estados de la política {#policy-statuses}
+
+Cada política cargada en un recurso tiene uno de los siguientes estados:
+
+- {{< ui >}}Loaded{{< /ui >}}: Todas las reglas de la política se aprueban.
+- {{< ui >}}Error{{< /ui >}}: Una o más reglas de la política tienen errores.
+
+### Estados de la regla {#rule-statuses}
+
+Cada regla informa uno de los siguientes estados:
+
+- {{< ui >}}Loaded{{< /ui >}}: La regla se cargó correctamente.
+- {{< ui >}}Filtered{{< /ui >}}: La regla no se aplicó intencionalmente (por ejemplo, la versión del Agent es demasiado baja o el tipo de evento está deshabilitado).
+- {{< ui >}}Error{{< /ui >}}: No se pudo cargar la regla.
+
+Cuando una regla está filtrada o presenta un error, un **veredicto** explica el motivo:
+
+| Veredicto | Significado |
+|---------|---------|
+| `syntax_error` | La expresión de la regla no es válida. |
+| `unknown` | El Agent no pudo cargar la regla. |
+| `filtered_agent_version` | La versión del Agent es demasiado baja para esta regla. |
+| `filtered_event_type_disabled` | El tipo de evento está deshabilitado en la configuración. |
+| `filtered_rule_filter` | La regla fue excluida por un filtro de reglas. |
+
+Para entender por qué falla una regla, seleccione el recurso para abrir su panel lateral. El panel lateral enumera las políticas y reglas del recurso. Para cada regla, muestra la expresión, el estado y el veredicto, así como el mensaje de error reportado por el Agent.
+
+{{< img src="security/workload_protection/coverage_page/coverage_side_panel.png" alt="Panel lateral del recurso que muestra los estados de las políticas y reglas con sus veredictos" width="100%">}}
+
+## Lecturas adicionales {#further-reading}
+
+{{< partial name="whats-next/whats-next.html" >}}
+
+[1]: https://app.datadoghq.com/security/workload-protection/inventory/coverage
+[5]: /es/security/workload_protection/detect_and_monitor/agent_rules/policy_management#enable-and-deploy-policies
+[6]: /es/security/workload_protection/inventory/review_improve_coverage
\ No newline at end of file
diff --git a/hugo/content/es/security/workload_protection/inventory/review_improve_coverage.md b/hugo/content/es/security/workload_protection/inventory/review_improve_coverage.md
new file mode 100644
index 00000000000..e7fa770f8d2
--- /dev/null
+++ b/hugo/content/es/security/workload_protection/inventory/review_improve_coverage.md
@@ -0,0 +1,69 @@
+---
+description: Identifique y solucione las brechas de cobertura de Workload Protection,
+ resuelva problemas de implementación de Agent y reglas, y revise la cobertura de
+ detección en todo su entorno.
+disable_toc: false
+title: Revise y mejore la cobertura
+---
+Utilice los procedimientos de esta página para reducir los puntos ciegos, verificar la alineación de las políticas y ayudar a Workload Protection a detectar y responder a las amenazas en todo su entorno. Puede incorporar estas comprobaciones en las revisiones de cumplimiento, CI/CD e infraestructura.
+
+Para obtener información sobre las vistas y estados de Coverage, consulte [Coverage][1].
+
+## Orden de revisión recomendada {#recommended-review-order}
+
+Utilice este orden para revisar la cobertura en todo su entorno:
+
+1. Revise el entorno completo para establecer una línea base. Valide que los recursos que parecen estar totalmente cubiertos tengan políticas, reglas y Agents en funcionamiento para descubrir fallas silenciosas antes de abordar las brechas visibles.
+2. Identifique las cargas de trabajo sin protección o parcialmente protegidas, luego priorice los recursos con el mayor impacto empresarial y exposición.
+3. Verifique la implementación de políticas y reglas en los recursos priorizados, y verifique si hay Agents obsoletos o en mal estado en todas las cargas de trabajo restantes.
+4. Mapee la cobertura de detección a MITRE ATT&CK, luego implemente o actualice las reglas de detección para cerrar las brechas.
+5. Reevalúe la cobertura para confirmar que sus cambios surtieron efecto.
+6. Registre el estado final para cumplimiento, auditorías, referencia de incidente y comparaciones futuras.
+
+## Coverage widget {#coverage-widget}
+
+El widget en la parte superior de la Coverage page muestra el porcentaje de sus recursos protegidos con Workload Protection, junto con cualquier hallazgo. Utilice sus botones para investigar cargas de trabajo sin protección y Agents obsoletos o incompletos.
+
+{{< img src="security/workload_protection/coverage_page/coverage_top_widgets.png" alt="Widgets superiores de la Coverage page que muestran la cobertura de recursos, el estado de carga de reglas, la adopción de Workload Protection y la implementación de Remote Config" width="100%">}}
+
+## Encuentre cargas de trabajo sin protección {#find-workloads-without-protection}
+
+- {{< ui >}}View without WP{{< /ui >}}: Hosts que ejecutan el Datadog Agent sin Workload Protection habilitado. Esto abre Fleet Automation, donde puede [configurar Workload Protection][3].
+- {{< ui >}}View without Agents{{< /ui >}}: Hosts que no ejecutan el Datadog Agent, los cuales no pueden ser evaluados por Workload Protection. Esto abre el Infrastructure Catalog.
+
+## Corrija los errores de implementación de políticas o reglas {#fix-policy-or-rule-deployment-errors}
+
+Para encontrar y corregir recursos con errores de reglas:
+
+1. En el explorador, filtre por gravedad {{< ui >}}Error{{< /ui >}}, o en el Map, seleccione un {{< ui >}}Error{{< /ui >}} hexágono.
+2. Seleccione un recurso con fallas para abrir su panel lateral y revisar sus políticas. Las políticas con reglas fallidas muestran un estado de {{< ui >}}Error{{< /ui >}}.
+3. Revise el veredicto de una regla fallida (por ejemplo, `syntax_error` o `unknown`) y el mensaje de error para comprender por qué falló.
+4. [Edite la regla][4] según sea necesario.
+5. Vuelva a implementar y confirme la corrección en Coverage.
+
+## Encuentre Agents obsoletos o incompletos {#find-outdated-or-incomplete-agents}
+
+- {{< ui >}}View outdated{{< /ui >}}: Recursos que ejecutan una versión del Agent anterior a la versión mínima admitida (`7.65.0`), la cual podría no ser compatible con las funciones más recientes de Workload Protection.
+- {{< ui >}}View incomplete{{< /ui >}}: Recursos que reportan datos incompletos o no válidos.
+
+Actualice o implemente el Datadog Agent, luego confirme que los recursos afectados reporten datos de cobertura completos.
+
+## Revise la cobertura de detección {#review-detection-coverage}
+
+Utilice las facetas del explorador bajo los grupos {{< ui >}}Rule{{< /ui >}} y {{< ui >}}Policy{{< /ui >}} para filtrar los recursos por contenido de detección aplicado. Filtre por tácticas y técnicas de MITRE ATT&CK para ver qué partes del marco están cubiertas en toda su infraestructura.
+
+Para obtener información sobre el mapa de MITRE ATT&CK disponible en Cloud SIEM o Workload Protection, consulte [MITRE ATT&CK map][2].
+
+## Confirme que las nuevas reglas estén cargadas {#confirm-that-new-rules-are-loaded}
+
+Puede usar Coverage para probar e iterar en reglas de seguridad personalizadas:
+
+1. Escriba e implemente una [nueva regla personalizada][4].
+2. En Coverage, busque la regla por ID de regla, ID de política o nombre de host.
+3. Confirme que el Agent haya cargado la regla correctamente.
+4. Si aparecen errores, revise el veredicto, corrija la regla y vuelva a implementarla.
+
+[1]: /es/security/workload_protection/inventory/
+[2]: /es/security/detection_rules/#mitre-attck-map
+[3]: /es/security/workload_protection/setup/
+[4]: /es/security/workload_protection/detect_and_monitor/detection_and_finding_rules/detection_rules
\ No newline at end of file
diff --git a/hugo/content/es/serverless/aws_lambda/_index.md b/hugo/content/es/serverless/aws_lambda/_index.md
index 52d2dc12053..f206f840ff3 100644
--- a/hugo/content/es/serverless/aws_lambda/_index.md
+++ b/hugo/content/es/serverless/aws_lambda/_index.md
@@ -1,96 +1,117 @@
---
+aliases:
+- /es/serverless/aws
further_reading:
- link: /serverless/configuration/
tag: Documentación
- text: Configurar la monitorización serverless
+ text: Configure Serverless Monitoring
- link: /integrations/amazon_lambda/
tag: Documentación
text: Integración de AWS Lambda
+- link: /serverless/guide/disable_serverless
+ tag: Documentación
+ text: Deshabilite Serverless Monitoring
+- link: /opentelemetry/setup/otlp_ingest/serverless/?tab=aws#lambda
+ tag: Documentación
+ text: Envíe trazas de AWS Lambda a Datadog con OTLP
- link: https://www.datadoghq.com/blog/monitoring-lambda-containers/
tag: Blog
- text: Monitorizar las funciones de AWS Lambda desplegadas con imágenes de contenedor
+ text: Haga un seguimiento de las funciones de AWS Lambda implementadas mediante
+ imágenes de contenedor
- link: https://www.datadoghq.com/blog/manage-serverless-logs-datadog/
tag: Blog
- text: Prácticas recomendadas para la recopilación y gestión de logs serverless
+ text: Prácticas recomendadas para recopilar y administrar registros sin servidor
- link: https://www.datadoghq.com/blog/aws-serverless-application-design/
tag: Blog
- text: Diseño de aplicaciones serverless de AWS listas para la producción
+ text: Diseño de aplicaciones sin servidor de AWS listas para producción
- link: https://www.datadoghq.com/blog/well-architected-serverless-applications-best-practices/
tag: Blog
- text: Prácticas recomendadas para la creación de aplicaciones serverless que sigan
- el AWS Well-Architected Framework
+ text: Prácticas recomendadas para crear aplicaciones sin servidor que sigan el Well-Architected
+ Framework de AWS
- link: https://www.datadoghq.com/blog/aws-lambda-functions-ephemeral-storage-monitoring/
tag: Blog
- text: Monitorizar el uso de almacenamiento efímero de las funciones de AWS Lambda
+ text: Haga un seguimiento del uso de almacenamiento efímero de sus funciones de
+ AWS Lambda
- link: https://www.datadoghq.com/blog/serverless-cold-start-traces/
tag: Blog
- text: Comprender el rendimiento de las funciones serverless con rastreo de arranque
- en frío
+ text: Comprenda el rendimiento de las funciones sin servidor con Cold Start Tracing
+- link: https://www.datadoghq.com/blog/identifying-deprecated-lambda-functions/
+ tag: Blog
+ text: Identifique funciones Lambda obsoletas con Datadog
+- link: https://www.datadoghq.com/blog/monitoring-lwa-with-datadog/
+ tag: Blog
+ text: Haga un seguimiento de aplicaciones web alojadas en Lambda con la integración
+ de Lambda Web Adapter
+- link: https://www.datadoghq.com/blog/lambda-managed-instances
+ tag: Blog
+ text: Haga un seguimiento de instancias administradas de AWS Lambda con Datadog
+- link: https://learn.datadoghq.com/courses/visibility-aws-lambda
+ tag: Centro de aprendizaje
+ text: Configure AWS Lambda para Serverless Monitoring con Datadog
title: Serverless Monitoring para AWS Lambda
---
+Datadog Serverless Monitoring para AWS Lambda le brinda visibilidad de sus funciones Lambda
-Datadog Serverless Monitoring para AWS Lambda te ofrece visibilidad sobre tus funciones de Lambda.
-
-Para empezar, sigue las [instrucciones de instalación][1] para recopilar las métricas, trazas (traces) y logs de tus aplicaciones serverless.
+Para comenzar, siga las [instrucciones de instalación][1] para recopilar métricas, trazas y registros de sus aplicaciones sin servidor.
-## Cómo funciona
+## Cómo funciona {#how-it-works}
{{< img src="serverless/serverless_custom_metrics.png" alt="Recopilación de métricas mejoradas de AWS Lambda" >}}
-Datadog Serverless Monitoring utiliza una biblioteca de Datadog Lambda específica del tiempo de ejecución, junto con la extensión Datadog Lambda, para enviar la telemetría de las funciones de Lambda.
+Datadog Serverless Monitoring utiliza una biblioteca Datadog Lambda específica del tiempo de ejecución, en conjunto con Datadog Lambda Extension, para enviar telemetría desde sus funciones Lambda
-La extensión Datadog Lambda recopila logs a través de CloudWatch, además de trazas, métricas mejoradas y métricas personalizadas de la librería de Datadog Lambda.
+Datadog Lambda Extension recopila registros de funciones utilizando la API de telemetría de Lambda, eliminando la necesidad de CloudWatch También genera métricas mejoradas. Unifica estas señales de telemetría con trazas de APM, tramos personalizados y métricas personalizadas de Datadog Lambda Library
-## Uso
+## Uso {#usage}
-En las siguientes páginas se describe cómo instalar y configurar Serverless Monitoring para AWS Lambda, incluido cómo utilizar métricas, trazas y logs para obtener una visibilidad completa.
+Las siguientes páginas describen cómo instalar y configurar Serverless Monitoring para AWS Lambda, incluido cómo utilizar métricas, trazas y registros para una visibilidad completa
{{< whatsnext desc=" ">}}
- {{< nextlink href="/serverless/installation" >}}Instalación: instala Serverless Monitoring para AWS Lambda.{{< /nextlink >}}
- {{< nextlink href="/serverless/enhanced_lambda_metrics" >}}Métricas de Lambda: obtén más información sobre las métricas mejoradas y aprende a enviar métricas personalizadas.{{< /nextlink >}}
- {{< nextlink href="/serverless/distributed_tracing" >}}Rastreo distribuido: utiliza APM y el rastreo distribuido para obtener una imagen contextualizada del rendimiento de tu aplicación.{{< /nextlink >}}
+ {{< nextlink href="/serverless/installation" >}}Instalación: Instale Serverless Monitoring para AWS Lambda{{< /nextlink >}}
+ {{< nextlink href="/serverless/enhanced_lambda_metrics" >}}Métricas de Lambda: Lea más sobre las métricas mejoradas y aprenda a enviar métricas personalizadas.{{< /nextlink >}}
+ {{< nextlink href="/serverless/distributed_tracing" >}}Trazado distribuido: Utilice APM y el trazado distribuido para obtener una imagen rica en contexto del rendimiento de su aplicación.{{< /nextlink >}}
{{< nextlink href="/serverless/aws_lambda/logs" >}}
- Recopilación de logs: obtén más información sobre cómo recopilar logs, cómo filtrar logs y cómo conectar logs y trazas.{{< /nextlink >}}
+ Log Collection: Read more about log collection, how to filter logs, and how to connect logs and traces.{{< /nextlink >}}
{{< /whatsnext >}}
-### Monitorizar todo el stack tecnológico serverless en la vista Serverless
+### Haga un seguimiento de toda su pila sin servidor en la Serverless view {#monitor-your-entire-serverless-stack-in-the-serverless-view}
-La vista Serverless te permite correlacionar las métricas de alto nivel de los recursos de AWS con las métricas de las funciones de Lambda, de modo que puedas detectar e investigar rápidamente cualquier problema.
+La Serverless view le permite correlacionar métricas de alto nivel de los recursos de AWS con las de las funciones Lambda, para que pueda detectar problemas rápidamente e iniciar su investigación
-De forma predeterminada, la vista Serverless agrupa los recursos serverless por servicio para que puedas visualizar el rendimiento de cada parte de tu aplicación. Puedes ver las funciones que le pertenecen cada servicio, junto con los recursos (Amazon API Gateway, SNS, SQS, DynamoDB, S3, EventBridge, Kinesis) que las invocaron.
+De forma predeterminada, Serverless view agrupa sus recursos sin servidor por servicio para ayudarle a visualizar cómo funciona cada parte de su aplicación Para cada servicio, puede ver las funciones que le pertenecen, junto con los recursos (Amazon API Gateway, SNS, SQS, DynamoDB, S3, EventBridge, Kinesis) que las invocaron.
{{< img src="serverless/serverless-view-hero.jpeg" alt="Datadog Serverless Monitoring" style="width:100%;" >}}
-### Resolver más rápidamente los errores de las funciones de AWS Lambda mediante la monitorización de las cargas útiles de las invocaciones
+### Resuelva las fallas de las funciones de AWS Lambda más rápido haciendo un seguimiento de las cargas útiles de invocación {#resolve-aws-lambda-function-failures-faster-by-monitoring-invocation-payloads}
-Datadog recopila automáticamente las solicitudes y respuestas de todas las invocaciones a funciones, lo que proporciona información clave que puede ayudar a solucionar problemas. Por ejemplo, si se te notifica que una de tus funciones de Lambda está experimentando errores, puedes analizar las cargas útiles de las solicitudes relevantes para buscar parámetros faltantes, direcciones de recursos mal escritas u otras configuraciones erróneas que puedan estar detrás de los errores.
+Datadog recopila automáticamente las solicitudes y respuestas de funciones para todas sus invocaciones de funciones, proporcionando información clave que puede ayudar a solucionar problemas. Por ejemplo, si se le notifica que una de sus funciones Lambda está experimentando fallas, puede analizar las cargas útiles de solicitud relevantes para verificar si faltan parámetros, si hay direcciones de recursos mal escritas u otras configuraciones incorrectas que puedan estar detrás de las fallas.
-Al identificar las configuraciones erróneas en las solicitudes con errores, puedes reproducir más fácilmente los problemas en tu entorno de desarrollo, y luego ejecutar tests para verificar las correcciones de los errores.
+Al identificar configuraciones incorrectas en las solicitudes fallidas, puede reproducir problemas más fácilmente en su entorno de desarrollo y luego ejecutar pruebas para verificar las correcciones de errores.
{{< img src="serverless/lambda_payload_hero.jpeg" alt="Datadog Serverless Monitoring" style="width:100%;" >}}
-### Métricas en tiempo real para crear alertas sobre problemas en el entorno de las funciones de Lambda
+### Métricas en tiempo real para alertar sobre problemas en todo su entorno de funciones Lambda {#real-time-metrics-for-alerting-on-issues-across-your-lambda-function-environment}
-Las métricas de Lambda mejoradas de Datadog, que aparecen en Datadog con el prefijo `aws.lambda.enhanced`, están disponibles con un segundo nivel de granularidad y casi en tiempo real. Puedes utilizar las métricas de Lambda mejoradas para crear alertas o SLOs sobre arranques en frío, costes estimados de AWS, tiempos de espera, errores de memoria agotada y uso de memoria en todas tus funciones de Lambda. Esto te permite ver los problemas de rendimiento en tus entornos serverless a medida que se producen y solucionarlos sin demora.
+Las métricas Lambda mejoradas de Datadog, que aparecen en Datadog con el prefijo `aws.lambda.enhanced`, están disponibles con granularidad de un segundo y casi en tiempo real. Puede utilizar las métricas Lambda mejoradas para alertas o SLO sobre arranques en frío, costos estimados de AWS, tiempos de espera, errores de falta de memoria y uso de memoria en todas sus funciones Lambda. Esto le permite ver los problemas de rendimiento en sus entornos sin servidor a medida que ocurren y solucionar problemas sin demora.
{{< img src="serverless/serverless_enhanced_metrics.jpeg" alt="Datadog Serverless Monitoring" style="width:100%;" >}}
-### Monitorizar los cambios en la configuración serverless con el seguimiento del despliegue
+### Haga un seguimiento de los cambios de configuración sin servidor con el seguimiento de implementaciones {#monitor-serverless-configuration-changes-with-deployment-tracking}
-Correlaciona fácilmente los cambios en el código, la configuración y el despliegue serverless con las métricas, trazas y logs de tus funciones para obtener información en tiempo real sobre cómo estos cambios pueden afectar el estado y el rendimiento de tus aplicaciones.
+Correlacione fácilmente los cambios de código, configuración e implementación sin servidor con métricas, trazas y registros de sus funciones para obtener información en tiempo real sobre cómo estos cambios pueden afectar la salud y el rendimiento de sus aplicaciones.
{{< img src="serverless/serverless_deployment_tracking.jpeg" alt="Datadog Serverless Monitoring" style="width:100%;" >}}
-## Capacidades adicionales
+## Capacidades adicionales {#additional-capabilities}
{{< whatsnext desc=" ">}}
- {{< nextlink href="/serverless/aws_lambda/profiling" >}}Continuous Profiler: habilita Continuous Profiler de Datadog para encontrar la línea de código exacta en tu función de Lambda que está creando cuellos de botella.{{< /nextlink >}}
- {{< nextlink href="/serverless/aws_lambda/securing_functions" >}}Protección de las funciones: utiliza Application Security Management (ASM) para proteger tus funciones de las amenazas.{{< /nextlink >}}
- {{< nextlink href="/serverless/deployment_tracking" >}}Seguimiento del despliegue: haz un seguimiento de los despliegues para ver cuándo una nueva versión de código o un cambio en la configuración provoca una regresión.{{< /nextlink >}}
+ {{< nextlink href="/serverless/aws_lambda/profiling" >}}Continuous Profiler: habilite Continuous Profiler de Datadog para encontrar la línea exacta de código en su función Lambda que está causando cuellos de botella.{{< /nextlink >}}
+ {{< nextlink href="/serverless/aws_lambda/securing_functions" >}}Funciones seguras: utilice la protección App y API (AAP) para gestionar las amenazas a sus funciones{{< /nextlink >}}
+ {{< nextlink href="/serverless/deployment_tracking" >}}Seguimiento de implementaciones: Haga un seguimiento de las implementaciones para ver cuándo una nueva versión de código o un cambio de configuración provoca una regresión{{< /nextlink >}}
{{< /whatsnext >}}
-## Referencias adicionales
+## Lecturas adicionales {#further-reading}
{{< partial name="whats-next/whats-next.html" >}}
-[1]: /es/serverless/installation
+[1]: /es/serverless/installation
\ No newline at end of file
diff --git a/hugo/content/es/serverless/aws_lambda/instrumentation/_index.md b/hugo/content/es/serverless/aws_lambda/instrumentation/_index.md
index f71deba9915..2672033228b 100644
--- a/hugo/content/es/serverless/aws_lambda/instrumentation/_index.md
+++ b/hugo/content/es/serverless/aws_lambda/instrumentation/_index.md
@@ -9,32 +9,68 @@ further_reading:
text: Configurar Serverless Monitoring
- link: /integrations/amazon_lambda/
tag: Documentación
- text: Integración de AWS Lambda
+ text: Integración con AWS Lambda
+- link: https://learn.datadoghq.com/courses/visibility-aws-lambda
+ tag: Centro de aprendizaje
+ text: Configurar AWS Lambda para Serverless Monitoring con Datadog
+- link: /mcp_server/tools/#serverless_onboarding
+ tag: Documentación
+ text: 'Datadog MCP Server: herramienta serverless_onboarding'
title: Instrumentar aplicaciones de AWS Lambda
---
## Descripción general {#overview}
-Instrumente sus aplicaciones de AWS Lambda con el Datadog Lambda Extension para recopilar trazas, métricas mejoradas y métricas personalizadas. El Datadog Lambda Extension es análogo a usar el Datadog Agent y los Datadog SDKs para infraestructura y aplicaciones basadas en host.
+Instrumente sus aplicaciones de AWS Lambda con Datadog Lambda Extension para recopilar trazas, métricas mejoradas y métricas personalizadas. Datadog Lambda Extension es análoga al uso de Datadog Agent y los SDK de Datadog para infraestructura basada en servidor y aplicaciones.
-{{< img src="serverless/serverless_tracing_installation_instructions.png" alt="Un diagrama que muestra cómo Datadog recibe telemetría de su aplicación de AWS Lambda instrumentada. Su aplicación Lambda, instrumentada con el Datadog Lambda Library, envía registros, trazas, métricas mejoradas y métricas personalizadas al Datadog Lambda Extension, que luego envía estos datos a Datadog." style="width:100%;" >}}
+{{< img src="serverless/serverless_tracing_installation_instructions.png" alt="Un diagrama que muestra cómo Datadog recibe telemetría de su aplicación de AWS Lambda instrumentada. Su aplicación Lambda, instrumentada con Datadog Lambda Library, envía registros, trazas, métricas mejoradas y métricas personalizadas a Datadog Lambda Extension, que luego envía estos datos a Datadog." style="width:100%;" >}}
## Inicio rápido {#quick-start}
-Para comenzar, [régístrese para obtener una cuenta de Datadog][1] si aún no la tiene. Luego, siga el [flujo de instalación en la aplicación en Fleet Automation][8] para AWS Lambda para instrumentar sus funciones Lambda. Esta configuración de inicio rápido permite que sus funciones envíen métricas, registros y trazas en tiempo real a Datadog.
+{{< site-region region="gov,gov2" >}}
+Esta función no es compatible con el
sitio de Datadog seleccionado ({{< region-param key="dd_site_name" >}}).
Esta función no es compatible con el
sitio de Datadog seleccionado ({{< region-param key="dd_site_name" >}}).
-SCIM est disponible avec les offres Infrastructure Pro et Infrastructure Enterprise.
+SCIM est disponible avec les plans Infrastructure Pro, Infrastructure Enterprise et Startup.
-Consultez les instructions suivantes pour synchroniser les utilisateurs Datadog avec Okta à l'aide de SCIM.
+Consultez les instructions suivantes pour synchroniser vos utilisateurs Datadog avec Okta à l'aide de SCIM.
+
+Pour connaître les capacités et les limitations de cette fonctionnalité, consultez [SCIM][1].
+
+## Prérequis {#prerequisites}
+
+SCIM dans Datadog est une fonctionnalité avancée disponible avec les plans Infrastructure Pro, Infrastructure Enterprise et Startup
+
+Cette documentation suppose que votre organisation gère les identités des utilisateurs à l'aide d'un fournisseur d'identité.
+
+Datadog recommande vivement d'utiliser une clé d'application de compte de service lors de la configuration de SCIM pour éviter toute interruption de l'accès. Pour plus de détails, consultez [l'utilisation d'un compte de service avec SCIM][2].
+
+Lorsque vous utilisez SAML et SCIM ensemble, Datadog recommande vivement de désactiver le provisionnement juste-à-temps (JIT) SAML pour éviter les divergences d'accès. Gérez le provisionnement des utilisateurs uniquement via SCIM.
-Pour en savoir plus sur les fonctionnalités et les limitations de cette fonctionnalité, consultez la page [SCIM][1].
+## Sélectionnez l'application Datadog dans la galerie d'applications Okta {#select-the-datadog-application-in-the-okta-application-gallery}
-## Prérequis
+1. Dans votre portail Okta, accédez à {{< ui >}}Applications{{< /ui >}}
+2. Cliquez sur {{< ui >}}Browse App Catalog{{< /ui >}}
+3. Saisissez « Datadog » dans la zone de recherche
+4. Sélectionnez l'application Datadog
+5. Cliquez sur {{< ui >}}Add Integration{{< /ui >}}
-La fonctionnalité SCIM dans Datadog est une option avancée disponible avec les formules Infrastructure Pro et Infrastructure Enterprise.
+**Remarque :** Si Datadog est déjà configuré avec Okta, sélectionnez votre application Datadog existante.
-Cette documentation part du principe que votre organisation gère les identités utilisateur à l'aide d'un fournisseur d'identité.
+## Configurer le provisionnement automatique des utilisateurs {#configure-automatic-user-provisioning}
-Datadog recommande fortement d'utiliser une clé d'application de compte de service lors de la configuration de SCIM afin d'éviter toute interruption d'accès. Pour plus de détails, consultez la section [Utiliser un compte de service avec SCIM][2].
+1. Dans l'écran de gestion des applications, sélectionnez {{< ui >}}Provisioning{{< /ui >}} dans le panneau de gauche
+2. Cliquez sur {{< ui >}}Configure API integration{{< /ui >}}.
+3. Sélectionnez {{< ui >}}Enable API integration{{< /ui >}}.
+4. Remplissez la section {{< ui >}}Credentials{{< /ui >}} comme suit :
+ - {{< ui >}}Base URL{{< /ui >}} : `https://{{< region-param key="dd_full_site" >}}/api/v2/scim` **Remarque :** Utilisez le sous-domaine approprié pour votre site. Pour trouver votre URL, consultez les [sites Datadog][3].
+ - {{< ui >}}API Token{{< /ui >}} : Utilisez une clé d'application Datadog valide. Vous pouvez créer une clé d'application sur [votre page de paramètres d'organisation][4]. Pour maintenir un accès continu à vos données, utilisez une clé d'application de [compte de service][5].
-Lorsque SAML et SCIM sont utilisés conjointement, Datadog recommande fortement de désactiver le provisionnement SAML juste-à-temps (JIT) afin d'éviter les incohérences d'accès. Gérez le provisionnement des utilisateurs uniquement via SCIM.
+{{< img src="/account_management/scim/okta-admin-credentials.png" alt="Écran de configuration des identifiants d'administration Okta">}}
-## Sélectionnez l'application Datadog dans la galerie d'applications Okta.
+5. Cliquez sur {{< ui >}}Test API Credentials{{< /ui >}} et attendez le message confirmant que les identifiants sont vérifiés.
+6. Cliquez sur {{< ui >}}Save{{< /ui >}}. La section des paramètres s'affiche.
+7. À côté de {{< ui >}}Provisioning to App{{< /ui >}}, sélectionnez {{< ui >}}Edit{{< /ui >}} pour activer les fonctionnalités :
+ - {{< ui >}}Create Users{{< /ui >}}
+ - {{< ui >}}Update User Attributes{{< /ui >}}
+ - {{< ui >}}Deactivate Users{{< /ui >}}
+8. Sous {{< ui >}}Datadog Attribute Mappings{{< /ui >}}, trouvez le mappage des attributs Okta vers les attributs Datadog déjà préconfigurés. Vous pouvez les remapper si nécessaire, mais mappez les valeurs Okta vers le même ensemble de valeurs Datadog.
-1. Dans votre portail Okta, allez dans **Applications**.
-2. Cliquez sur **Browse App Catalog**
-3. Saisissez « Datadog » dans la zone de recherche
-4. Sélectionnez l'application Datadog
-5. Cliquez sur **Add Integration**
+### Mappez l'attribut de rôle Datadog {#map-the-datadog-role-attribute}
-**Remarque :** si Datadog est déjà configuré avec Okta, sélectionnez votre application Datadog existante.
+Pour provisionner le rôle Datadog d'un utilisateur (intégré ou personnalisé) via SCIM, ajoutez un mappage explicite pour l'attribut `roles`. Okta ne remappe pas cet attribut par défaut.
-## Configurer le provisionnement automatique des utilisateurs
+La prise en charge des rôles SCIM par Datadog suit la convention d'attribut à valeurs multiples SCIM définie dans [RFC 7643][8], en utilisant l'UUID du rôle comme `value` et le nom du rôle comme `display` :
-1. Dans l'écran de gestion de l'application, sélectionnez **Provisioning** dans le panneau de gauche.
-2. Cliquez sur **Configure API integration**.
-3. Sélectionnez **Enable API integration**.
-4. Complétez la section **Credentials** comme suit :
- - **URL de base** : `https://{{< region-param key="dd_full_site" >}}/api/v2/scim`
-**Remarque :** utilisez le sous-domaine approprié pour votre site. Pour trouver votre URL, consultez la page [Sites Datadog][3].
- - **Jeton d'API** : utilisez une clé d’application Datadog valide. Vous pouvez créer une clé d’application depuis [la page des paramètres de votre organisation][4]. Pour garantir un accès continu à vos données, utilisez une clé d’application de [compte de service][5].
+```json
+{
+ "roles": [
+ { "value": "", "display": "" }
+ ]
+}
+```
-{{< img src="/account_management/scim/okta-admin-credentials.png" alt="Écran de configuration des identifiants administrateur Okta">}}
+1. Dans {{< ui >}}Directory{{< /ui >}} > {{< ui >}}Profile Editor{{< /ui >}}, sélectionnez le profil utilisateur pour l'application configurée pour Datadog SCIM, puis cliquez sur {{< ui >}}Add Attribute{{< /ui >}} pour créer un attribut `roles` :
+ - {{< ui >}}Data type{{< /ui >}} : **string**
+ - {{< ui >}}Display name{{< /ui >}} : **Roles**
+ - {{< ui >}}Variable name{{< /ui >}} : **roles**
+ - {{< ui >}}External name{{< /ui >}} : `roles.^[primary==true].value`
+ - {{< ui >}}External namespace{{< /ui >}} : `urn:ietf:params:scim:schemas:core:2.0:User`
+ - Pour {{< ui >}}Enum{{< /ui >}}, sélectionnez {{< ui >}}Define enumerated list of values{{< /ui >}} et ajoutez une entrée par rôle Datadog, en utilisant le nom du rôle comme nom d'affichage et l'UUID du rôle comme valeur. Vous pouvez trouver l'UUID d'un rôle dans l'URL du rôle sur votre page [Organization Settings][9]. Ajoutez tous les rôles personnalisés de la même manière.
+2. Dans les paramètres {{< ui >}}Provisioning{{< /ui >}} > {{< ui >}}To App{{< /ui >}} de votre application Datadog, mappez l'attribut Okta `roles` vers l'attribut Datadog `roles`.
+3. Dans l'onglet {{< ui >}}Assignments{{< /ui >}} de l'application, assignez à chaque utilisateur le rôle approprié depuis la liste déroulante.
-5. Cliquez sur **test API Credentials**, et attendez le message confirmant que les informations d'identification ont été vérifiées.
-6. Cliquez sur **Save**. La section des paramètres s'affiche.
-7. En regard de **Provisioning to App**, sélectionnez **Edit** pour activer les fonctionnalités :
- - **Create Users**
- - **Update User Attributes**
- - **Deactivate Users**
-8. Sous **Datadog Attribute Mappings**, identifiez les mappages préconfigurés des attributs Okta vers les attributs Datadog. Réalisez de nouveaux mappages si nécessaire, mais associez les valeurs Okta au même ensemble de valeurs Datadog.
+Si une requête SCIM envoie plusieurs rôles, Datadog provisionne uniquement les rôles qui correspondent à un rôle dans votre organisation. Si aucun ne correspond, l'utilisateur revient au rôle par défaut de l'organisation (Standard), et les rôles non correspondants sont consignés dans l'Audit Trail. Pour plus de détails, consultez [SCIM][1].
-## Configurer le provisionnement automatique des équipes
+## Configurer le provisionnement automatique des équipes {#configure-automatic-team-provisioning}
-Avec les [équipes gérées][6], vous contrôlez l'approvisionnement principal d'une équipe Datadog (son nom, son identifiant et sa composition) via le fournisseur d'identité. Le processus de configuration varie selon que l'équipe existe déjà ou non dans Datadog.
+Avec [Managed Teams][6], vous contrôlez le provisionnement principal d'une équipe Datadog — son nom, son handle et son membership — via le fournisseur d'identité. Le processus de configuration diffère selon que l'équipe existe déjà ou non dans Datadog.
-**Remarque :** les utilisateurs doivent exister dans Datadog avant de pouvoir être ajoutés à une équipe. Vous devez donc affecter les utilisateurs à l'application Datadog dans Okta afin qu'ils soient créés dans Datadog via SCIM. Affectez l'application Datadog à votre groupe Okta pour que tous les membres de l'équipe soient créés automatiquement dans Datadog.
+**Remarque :** Les utilisateurs doivent exister dans Datadog avant que vous puissiez les ajouter à une équipe. Par conséquent, vous devez affecter les utilisateurs à l'application Datadog dans Okta pour vous assurer qu'ils sont créés dans Datadog via SCIM. Affectez l'application Datadog à votre groupe Okta pour vous assurer que tous les membres de l'équipe sont créés automatiquement dans Datadog.
-### Créer une nouvelle équipe dans Datadog
+### Créer une nouvelle équipe dans Datadog {#create-a-new-team-in-datadog}
-1. Dans votre application Datadog dans Okta, naviguez jusqu'à l'onglet **Push Groups**.
-{{< img src="/account_management/scim/okta/pushed-groups.png" alt="Interface de configuration des groupes poussés dans Okta">}}
-1. Cliquez sur le bouton **Push Groups**. L'interface des groupes poussés s'ouvre.
-1. Sélectionnez le groupe Okta que vous voulez pousser vers Datadog.
-1. Dans la colonne **Match result & push action**, assurez-vous que **Create group** est sélectionné.
-1. Cliquez sur **Save**.
+1. Dans votre application Datadog dans Okta, accédez à l'onglet {{< ui >}}Push Groups{{< /ui >}}.
+{{< img src="/account_management/scim/okta/pushed-groups.png" alt="Interface de configuration des groupes poussés Okta">}}
+1. Cliquez sur le bouton {{< ui >}}Push Groups{{< /ui >}}. L'interface des groupes poussés s'ouvre.
+1. Sélectionnez le groupe Okta que vous souhaitez pousser vers Datadog.
+1. Dans la colonne {{< ui >}}Match result & push action{{< /ui >}}, assurez-vous que {{< ui >}}Create group{{< /ui >}} est sélectionné.
+1. Cliquez sur {{< ui >}}Save{{< /ui >}}.
-Pour vérifier que l'opération a bien été effectuée, accédez à la [liste des équipes][7] dans Datadog. Recherchez une équipe Datadog correspondant au groupe Okta que vous avez configuré. Vérifiez que l'équipe existe bien dans Datadog et qu'elle est gérée de manière externe. L'apparition de l'équipe dans Datadog peut prendre une à deux minutes.
+Pour vérifier que l'opération a réussi, accédez à la [liste Teams][7] dans Datadog. Recherchez une équipe Datadog correspondant au groupe Okta que vous avez configuré. Vérifiez que l'équipe existe dans Datadog et qu'elle est gérée de manière externe. Il peut s'écouler une ou deux minutes avant que l'équipe n'apparaisse dans Datadog.
-{{< img src="/account_management/scim/okta/managed-externally.png" alt="Liste des équipes Datadog affichant une équipe appelée Identity team gérée en externe" >}}
+{{< img src="/account_management/scim/okta/managed-externally.png" alt="Liste des équipes Datadog montrant une équipe appelée Identity team qui est gérée de manière externe.">}}
-### Synchroniser une équipe Datadog existante avec un groupe Okta
+### Synchronisez une équipe Datadog existante avec un groupe Okta {#synchronize-an-existing-datadog-team-with-an-okta-group}
-Vous pouvez mapper une équipe Datadog existante à un groupe Okta. L'établissement d'un lien entre le groupe Okta et l'équipe Datadog permet à l'équipe Datadog d'être gérée par Okta à l'avenir.
+Vous pouvez mapper une équipe Datadog existante à un groupe Okta. L'établissement d'un lien entre le groupe Okta et l'équipe Datadog entraîne la gestion de l'équipe Datadog par Okta à l'avenir.
-**Remarque :** pour synchroniser une équipe Datadog existante avec un groupe Okta, les deux noms doivent correspondre exactement.
+**Remarque :** Pour synchroniser une équipe Datadog existante avec un groupe Okta, le handle dérivé du nom du groupe Okta doit correspondre exactement au handle de l'équipe Datadog existante.
-1. Dans votre application Datadog dans Okta, naviguez jusqu'à l'onglet **Push Groups**.
-1. Cliquez sur le bouton **Push Groups**. L'interface des groupes poussés s'ouvre.
+1. Dans votre application Datadog dans Okta, accédez à l'onglet {{< ui >}}Push Groups{{< /ui >}}.
+1. Cliquez sur le bouton {{< ui >}}Push Groups{{< /ui >}}. L'interface des groupes poussés s'ouvre.
1. Sélectionnez le groupe Okta que vous souhaitez synchroniser avec une équipe Datadog.
-1. Dans la colonne **Match result & push action**, assurez-vous que **Create group** est sélectionné.
-1. Cliquez sur **Save**.
+1. Dans la colonne {{< ui >}}Match result & push action{{< /ui >}}, assurez-vous que {{< ui >}}Create group{{< /ui >}} est sélectionné.
+1. Cliquez sur {{< ui >}}Save{{< /ui >}}.
-**Remarque :** lorsque vous sélectionnez **Create group**, Okta affiche le message **No match found**. Vous pouvez ignorer ce message et poursuivre la création du groupe pour établir la synchronisation.
+**Remarque :** Lorsque vous sélectionnez {{< ui >}}Create group{{< /ui >}}, Okta affiche un message {{< ui >}}No match found{{< /ui >}}. Vous pouvez ignorer ce message et poursuivre la création du groupe pour établir la synchronisation.
-### Supprimer la connexion entre un groupe Okta et une équipe Datadog
+### Supprimez la connexion entre un groupe Okta et une équipe Datadog {#delete-the-connection-between-an-okta-group-and-a-datadog-team}
-Vous disposez de deux options pour déconnecter un groupe Okta d'une équipe Datadog, chacune ayant un impact différent sur la composition de l'équipe Datadog.
+Vous disposez de deux options pour déconnecter un groupe Okta d'une équipe Datadog, avec des impacts différents sur l'appartenance à l'équipe Datadog.
-#### Garder les membres de l'équipe dans Datadog
+#### Conservez les membres de l'équipe dans Datadog {#keep-team-members-in-datadog}
-Cette procédure vous permet de gérer les membres de l'équipe dans Datadog au lieu d'Okta. Les membres de l'équipe restent inchangés.
+Cette procédure vous permet de gérer l'appartenance à l'équipe dans Datadog au lieu d'Okta. Les membres de l'équipe restent inchangés.
-1. Dans votre application Datadog dans Okta, naviguez jusqu'à l'onglet **Push Groups**.
-1. Cliquez sur le bouton **Push Groups**. L'interface des groupes poussés s'ouvre.
+1. Dans votre application Datadog dans Okta, accédez à l'onglet {{< ui >}}Push Groups{{< /ui >}}.
+1. Cliquez sur le bouton {{< ui >}}Push Groups{{< /ui >}}. L'interface des groupes poussés s'ouvre.
1. Sélectionnez le groupe Okta que vous souhaitez dissocier de son équipe Datadog.
-1. Dans la colonne **Match result & push action**, sélectionnez **Unlink Pushed Group**. Une boîte de dialogue apparaît.
-1. Sélectionnez **Leave the group in the target app**.
-1. Cliquez sur **Unlink**.
-1. Cliquez sur **Save**.
+1. Dans la colonne {{< ui >}}Match result & push action{{< /ui >}}, sélectionnez {{< ui >}}Unlink Pushed Group{{< /ui >}}. Une boîte de dialogue s'affiche.
+1. Sélectionnez {{< ui >}}Leave the group in the target app{{< /ui >}}.
+1. Cliquez sur {{< ui >}}Unlink{{< /ui >}}.
+1. Cliquez sur {{< ui >}}Save{{< /ui >}}.
-#### Retirer des membres de l'équipe de Datadog
+#### Supprimez les membres de l'équipe de Datadog {#remove-team-members-from-datadog}
-Cette procédure vous permet de gérer les membres de l'équipe dans Datadog au lieu d'Okta et de supprimer les membres de l'équipe de Datadog.
+Cette procédure vous permet de gérer l'appartenance à une équipe dans Datadog au lieu d'Okta et supprime les membres de l'équipe Datadog.
-1. Dans votre application Datadog dans Okta, naviguez jusqu'à l'onglet **Push Groups**.
-1. Cliquez sur le bouton **Push Groups**. L'interface des groupes poussés s'ouvre.
+1. Dans votre application Datadog dans Okta, accédez à l'onglet {{< ui >}}Push Groups{{< /ui >}}.
+1. Cliquez sur le bouton {{< ui >}}Push Groups{{< /ui >}}. L'interface des groupes poussés s'ouvre.
1. Sélectionnez le groupe Okta que vous souhaitez dissocier de son équipe Datadog.
-1. Dans la colonne **Match result & push action**, sélectionnez **Unlink Pushed Group**. Une boîte de dialogue apparaît.
-1. Sélectionnez **Delete the group in the target app (recommended)**.
-1. Cliquez sur **Unlink**.
-1. Cliquez sur **Save**.
+1. Dans la colonne {{< ui >}}Match result & push action{{< /ui >}}, sélectionnez {{< ui >}}Unlink Pushed Group{{< /ui >}}. Une boîte de dialogue s'affiche.
+1. Sélectionnez {{< ui >}}Delete the group in the target app (recommended){{< /ui >}}.
+1. Cliquez sur {{< ui >}}Unlink{{< /ui >}}.
+1. Cliquez sur {{< ui >}}Save{{< /ui >}}.
-**Remarque ** contrairement à ce que laisse penser le nom de l'option, sélectionner **Delete the group in the target app** _ne supprime pas_ l'équipe dans Datadog. Cela supprime uniquement tous les membres de l'équipe et rompt le lien entre le groupe dans Okta et l'équipe Datadog.
+**Remarque :** Contrairement au nom de l'option, la sélection de {{< ui >}}Delete the group in the target app{{< /ui >}}_ ne supprime pas _ l'équipe dans Datadog. À la place, elle supprime tous les membres de l'équipe et supprime le lien entre le groupe Okta et l'équipe Datadog.
-## Pour aller plus loin
+## Pour aller plus loin {#further-reading}
{{< partial name="whats-next/whats-next.html" >}}
@@ -139,4 +163,6 @@ Cette procédure vous permet de gérer les membres de l'équipe dans Datadog au
[4]: https://app.datadoghq.com/organization-settings/application-keys
[5]: /fr/account_management/org_settings/service_accounts
[6]: /fr/account_management/teams/manage/#manage-teams-through-an-identity-provider
-[7]: https://app.datadoghq.com/teams
\ No newline at end of file
+[7]: https://app.datadoghq.com/teams
+[8]: https://www.rfc-editor.org/rfc/rfc7643.html#section-4.1.2
+[9]: https://app.datadoghq.com/organization-settings/roles
\ No newline at end of file
diff --git a/hugo/content/fr/agent/configuration/secrets-management.md b/hugo/content/fr/agent/configuration/secrets-management.md
index 8cbcd66a095..0fdfc7c7501 100644
--- a/hugo/content/fr/agent/configuration/secrets-management.md
+++ b/hugo/content/fr/agent/configuration/secrets-management.md
@@ -14,9 +14,9 @@ further_reading:
text: Autodiscovery
title: Gestion des secrets
---
-## Aperçu {#overview}
+## Présentation {#overview}
-L'Agent Datadog vous aide à gérer vos secrets de manière sécurisée en s'intégrant aux solutions de gestion des secrets suivantes :
+Le Datadog Agent vous aide à gérer vos secrets en toute sécurité en s'intégrant aux solutions de gestion des secrets suivantes :
- [AWS Secrets Manager](#id-for-secrets)
- [AWS SSM](#id-for-ssm)
- [Azure KeyVault](#id-for-azure)
@@ -24,23 +24,28 @@ L'Agent Datadog vous aide à gérer vos secrets de manière sécurisée en s'int
- [HashiCorp Vault](#id-for-hashicorp)
- [Kubernetes Secrets](#id-for-kubernetes)
- [Docker Secrets](#id-for-docker)
-- [Texte de fichier](#id-for-json-yaml-text)
+- [Fichier texte](#id-for-json-yaml-text)
- [Fichier JSON](#id-for-json-yaml-text)
- [Fichier YAML](#id-for-json-yaml-text)
+- [Clé de registre Windows](#id-for-windows-regkey)
-Au lieu de coder en dur des valeurs sensibles comme des clés API ou des mots de passe en texte clair dans des fichiers de configuration, l'Agent peut les récupérer dynamiquement au moment de l'exécution. Pour référencer un secret dans votre configuration, utilisez la notation `ENC[]`. Le secret est récupéré et chargé en mémoire mais n'est jamais écrit sur le disque ni envoyé au backend Datadog.
+Au lieu de coder en dur des valeurs sensibles comme des clés d'API ou des mots de passe en texte clair dans les fichiers de configuration, l'Agent peut les récupérer dynamiquement au moment de l'exécution. Pour référencer un secret dans votre configuration, utilisez la notation `ENC[]`. Le secret est récupéré et chargé en mémoire, mais n'est jamais écrit sur le disque ni envoyé au backend Datadog.
**Remarque** : Vous ne pouvez pas utiliser la syntaxe `ENC[]` dans les paramètres `secret_*` comme `secret_backend_command`.
-## Options pour récupérer des secrets {#options-for-retrieving-secrets}
+## Options pour la récupération des secrets {#options-for-retrieving-secrets}
-### Option 1 : Utiliser le support natif de l'Agent pour récupérer des secrets {#option-1-using-native-agent-support-for-fetching-secrets}
+### Option 1 : Utilisation de la prise en charge native de l'Agent pour récupérer les secrets {#option-1-using-native-agent-support-for-fetching-secrets}
-**Remarque** : À partir de la version `7.76` de l'Agent et au-delà, la gestion native des secrets est disponible pour les Agents activés FIPS.
+Remarques :
+- **Agent 7.70+** : Prise en charge native de la gestion des secrets introduite.
+- **Agent 7.76+** : gestion native des secrets disponible pour les agents compatibles FIPS.
+- **Agent 7.77+** : le [Cluster Agent](/containers/cluster_agent/) nécessite l'Agent 7.77 ou une version ultérieure dans les environnements conteneurisés. Pour les versions antérieures, utilisez [l'Option 2](#option-2-using-the-built-in-script-for-kubernetes-and-docker) ou [l'Option 3](#option-3-creating-a-custom-executable) à la place.
+- **Agent 7.80+** : prise en charge de [plusieurs backends](#multiple-backends).
-À partir de la version `7.70` de l'Agent, l'Agent Datadog prend en charge nativement plusieurs solutions de gestion des secrets. Deux nouveaux paramètres ont été introduits dans `datadog.yaml` : `secret_backend_type` et `secret_backend_config`.
+#### Backend unique {#single-backend}
-`secret_backend_type` est utilisé pour spécifier quelle solution de gestion des secrets utiliser, et `secret_backend_config` contient une configuration supplémentaire pertinente pour cette solution.
+Utilisez `secret_backend_type` et `secret_backend_config` dans `datadog.yaml` pour configurer un backend de secrets unique :
```yaml
# datadog.yaml
@@ -50,28 +55,26 @@ secret_backend_config:
:
```
-**Remarque** : Si vous exécutez Datadog dans un environnement conteneurisé, le [Cluster Agent](/containers/cluster_agent/) nécessite l'Agent 7.77 ou une version ultérieure pour prendre en charge la récupération native des secrets. Pour les versions antérieures, utilisez [Option 2](#option-2-using-the-built-in-script-for-kubernetes-and-docker) ou [Option 3](#option-3-creating-a-custom-executable) à la place.
+Des instructions de configuration plus spécifiques dépendent du type de backend utilisé. Consultez la section appropriée ci-dessous pour plus d'informations :
-Des instructions de configuration plus spécifiques dépendent du type de backend utilisé. Voir la section appropriée ci-dessous pour plus d'informations :
-
-{{% collapse-content title="AWS Secrets" level="h4" expanded=false id="id-for-secrets" %}}
+{{% collapse-content title="AWS Secrets" level="h5" expanded=false id="id-for-secrets" %}}
Les services AWS suivants sont pris en charge :
-|valeur secret_backend_type | Service AWS |
+|Valeur secret_backend_type | Service AWS |
|---------------------------------------------|-----------------------------------------|
|`aws.secrets` |[AWS Secrets Manager][1000] |
##### Configurer un profil d'instance {#set-up-an-instance-profile}
-Datadog recommande d'utiliser la méthode [profil d'instance][1006] pour récupérer les secrets, car AWS gère toutes les variables d'environnement et les profils de session pour vous. D'autres instructions sur la façon de procéder peuvent être trouvées dans la [documentation officielle d'AWS Secrets Manager][1000].
+Datadog recommande d'utiliser la [méthode du profil d'instance][1006] pour récupérer les secrets, car AWS gère toutes les variables d'environnement et les profils de session pour vous. Vous trouverez plus d'instructions sur la façon de procéder dans la [documentation officielle d'AWS Secrets Manager][1000].
##### Exemple de configuration {#configuration-example}
{{< tabs >}}
{{% tab "Fichier YAML de l'Agent" %}}
-Configurez l'Agent Datadog pour utiliser AWS Secrets afin de résoudre les secrets en utilisant la configuration suivante :
+Configurez le Datadog Agent pour utiliser AWS Secrets afin de résoudre les secrets à l'aide de la configuration suivante :
```yaml
# datadog.yaml
@@ -81,24 +84,24 @@ secret_backend_config:
aws_region: {regionName}
```
-Lors de l'utilisation de variables d'environnement, convertissez la configuration en JSON comme suit :
+Lorsque vous utilisez des variables d'environnement, convertissez la configuration au format JSON comme suit :
```sh
DD_SECRET_BACKEND_TYPE="aws.secrets"
DD_SECRET_BACKEND_CONFIG='{"aws_session":{"aws_region":""}}'
```
-Après avoir configuré l'Agent pour utiliser AWS Secrets, vous pouvez référencer n'importe quel secret dans vos configurations avec `ENC[secretId;secretKey]`.
+Une fois l'Agent configuré pour utiliser AWS Secrets, vous pouvez référencer tous les secrets dans vos configurations avec `ENC[secretId;secretKey]`.
-La notation ENC est composée de :
-* `secretId` : soit le "nom convivial" du secret (par exemple, `/DatadogAgent/Production`) ou l'ARN (par exemple, `arn:aws:secretsmanager:us-east-1:123456789012:secret:/DatadogAgent/Production-FOga1K`).
- - **Remarque** : Le format ARN complet est requis lors de l'accès aux secrets d'un autre compte où l'AWS credential ou le `sts:AssumeRole` credential est défini.
+La notation ENC est composée :
+* `secretId` : soit le « nom convivial » secret (par exemple, `/DatadogAgent/Production`), soit l'ARN (par exemple, `arn:aws:secretsmanager:us-east-1:123456789012:secret:/DatadogAgent/Production-FOga1K`).
+ - **Remarque** : Le format ARN complet est requis lors de l'accès aux secrets depuis un compte différent où le credential AWS ou `sts:AssumeRole` est défini.
* `secretKey` : la clé JSON du secret AWS que vous souhaitez utiliser.
-Le gestionnaire de secrets AWS peut stocker plusieurs paires clé-valeur au sein d'un seul secret. Une configuration backend utilisant le gestionnaire de secrets a accès à toutes les clés définies dans un secret.
+AWS Secrets Manager peut stocker plusieurs paires clé-valeur au sein d'un seul secret. Une configuration de backend utilisant Secrets Manager a accès à toutes les clés définies dans un secret.
-Par exemple, en supposant que l'ID de secret `My-Secrets` contient les 3 valeurs suivantes :
+Par exemple, en supposant que l'ID de secret `My-Secrets` contienne les 3 valeurs suivantes :
```json
{
@@ -108,7 +111,7 @@ Par exemple, en supposant que l'ID de secret `My-Secrets` contient les 3 valeurs
}
```
-Voici un exemple complet du fichier de configuration `datadog.yaml` utilisant les secrets AWS pour extraire sa clé API de `My-Secrets` :
+Voici un exemple complet du fichier de configuration `datadog.yaml` utilisant AWS Secrets pour extraire sa clé d'API de `My-Secrets` :
```yaml
api_key: ENC[My-Secrets;prodApiKey]
@@ -119,16 +122,46 @@ secret_backend_config:
aws_region: us-east-1
```
+##### Toutes les options `aws_session` {#all-aws-session-options}
+
+Les champs `aws_session` suivants configurent la manière dont l'Agent s'authentifie auprès d'AWS. Tous les champs sont facultatifs ; lorsqu'aucun n'est défini, l'Agent utilise la [default credential chain][1007] (profil d'instance, variables d'environnement, fichier de configuration partagé, etc.).
+
+| Champ | Description |
+|---|---|
+| `aws_region` | Région AWS (par exemple, `us-east-1`). |
+| `aws_access_key_id` | ID de clé d'accès AWS statique. À utiliser avec `aws_secret_access_key`. |
+| `aws_secret_access_key` | Clé d'accès secrète AWS statique. À utiliser avec `aws_access_key_id`. |
+| `aws_profile` | Profil nommé issu du fichier de configuration AWS partagé (`~/.aws/config`). |
+| `aws_role_arn` | ARN du rôle IAM à assumer avec `sts:AssumeRole`. |
+| `aws_external_id` | ID externe à transmettre lors de l'assomption d'un rôle inter-comptes. |
+
+##### `force_string` option {#force-string-option}
+
+Définissez `force_string: true` au niveau supérieur de `secret_backend_config` pour renvoyer la chaîne de caractères brute du secret au lieu de l'analyser en tant que JSON. Ceci est utile lorsqu'un secret est stocké en texte brut plutôt qu'en tant qu'objet JSON.
+
+```yaml
+secret_backend_type: aws.secrets
+secret_backend_config:
+ force_string: true
+ aws_session:
+ aws_region: us-east-1
+```
+
{{% /tab %}}
{{% tab "Helm" %}}
-Configurez l'Agent Datadog pour utiliser les secrets AWS afin de résoudre les secrets dans Helm en utilisant la configuration suivante :
+Configurez le Datadog Agent pour utiliser AWS Secrets afin de résoudre les secrets dans Helm en utilisant la configuration suivante :
-##### Vérification d'intégration {#integration-check}
+##### Check d'intégration {#integration-check}
```sh
datadog:
+ secretBackend:
+ type: "aws.secrets"
+ config:
+ aws_session:
+ aws_region: ""
confd:
# This is an example
.yaml: |-
@@ -137,11 +170,6 @@ datadog:
instances:
- [...]
password: "ENC[secretId;secretKey]"
- env:
- - name: DD_SECRET_BACKEND_TYPE
- value: "aws.secrets"
- - name: DD_SECRET_BACKEND_CONFIG
- value: '{"aws_session":{"aws_region":""}}'
agents:
rbac:
# IAM role ARN required to grant the Agent permissions to access the AWS secret
@@ -149,20 +177,20 @@ agents:
eks.amazonaws.com/role-arn:
```
- Vous devez inclure le serviceAccountAnnotations pour accorder à l'Agent les permissions d'accès au secret AWS.
+ Vous devez inclure le serviceAccountAnnotations pour accorder à l'Agent les autorisations d'accès au secret AWS.
-##### Vérification de cluster : sans les exécuteurs de vérification de cluster activés {#cluster-check-without-cluster-check-runners-enabled}
+##### Check de cluster : sans exécuteurs de check de cluster activés {#cluster-check-without-cluster-check-runners-enabled}
```sh
datadog:
- env:
- - name: DD_SECRET_BACKEND_TYPE
- value: "aws.secrets"
- - name: DD_SECRET_BACKEND_CONFIG
- value: '{"aws_session":{"aws_region":""}}'
+ secretBackend:
+ type: "aws.secrets"
+ config:
+ aws_session:
+ aws_region: ""
agents:
rbac:
# IAM role ARN required to grant the Agent permissions to access the AWS secret
@@ -178,15 +206,15 @@ clusterAgent:
password: "ENC[secretId;secretKey]"
```
-##### Vérification de cluster : avec les exécuteurs de vérification de cluster activés {#cluster-check-with-cluster-check-runners-enabled}
+##### Check de cluster : avec exécuteurs de check de cluster activés {#cluster-check-with-cluster-check-runners-enabled}
```sh
datadog:
- env:
- - name: DD_SECRET_BACKEND_TYPE
- value: "aws.secrets"
- - name: DD_SECRET_BACKEND_CONFIG
- value: '{"aws_session":{"aws_region":""}}'
+ secretBackend:
+ type: "aws.secrets"
+ config:
+ aws_session:
+ aws_region: ""
clusterAgent:
confd:
# This is an example
@@ -197,11 +225,6 @@ clusterAgent:
password: "ENC[secretId;secretKey]"
clusterChecksRunner:
enabled: true
- env:
- - name: DD_SECRET_BACKEND_TYPE
- value: "aws.secrets"
- - name: DD_SECRET_BACKEND_CONFIG
- value: '{"aws_session":{"aws_region":""}}'
rbac:
# IAM role ARN required to grant the Agent permissions to access the AWS secret
serviceAccountAnnotations:
@@ -209,15 +232,13 @@ clusterChecksRunner:
```
-**Alternativement**, avec le chart Helm v3.171.0+ et l'Agent v7.70+, vous pouvez utiliser les champs natifs `secretBackend.type` et `secretBackend.config` au lieu des variables d'environnement. Par exemple : `datadog.secretBackend.type: "aws.secrets"` et `datadog.secretBackend.config.aws_session.aws_region: ""`.
-
{{% /tab %}}
{{% tab "Opérateur" %}}
-Configurez l'Agent Datadog pour utiliser les secrets AWS afin de résoudre les secrets avec l'Opérateur Datadog en utilisant la configuration suivante :
+Configurez le Datadog Agent pour utiliser AWS Secrets afin de résoudre les secrets avec le Datadog Operator en utilisant la configuration suivante :
-##### Vérification d'intégration {#integration-check-1}
+##### Check d'intégration {#integration-check-1}
```sh
@@ -227,13 +248,14 @@ metadata:
name: datadog
spec:
[...]
+ global:
+ env:
+ - name: DD_SECRET_BACKEND_TYPE
+ value: "aws.secrets"
+ - name: DD_SECRET_BACKEND_CONFIG
+ value: '{"aws_session":{"aws_region":""}}'
override:
nodeAgent:
- env:
- - name: DD_SECRET_BACKEND_TYPE
- value: "aws.secrets"
- - name: DD_SECRET_BACKEND_CONFIG
- value: '{"aws_session":{"aws_region":""}}'
# IAM role ARN is required to grant the Agent permissions to access the AWS secret
serviceAccountAnnotations:
eks.amazonaws.com/role-arn:
@@ -249,12 +271,12 @@ spec:
```
- Vous devez inclure le serviceAccountAnnotations pour accorder à l'Agent les permissions d'accès au secret AWS.
+ Vous devez inclure le serviceAccountAnnotations pour accorder à l'Agent les autorisations d'accès au secret AWS.
-##### Vérification de cluster : sans les exécuteurs de vérification de cluster activés {#cluster-check-without-cluster-check-runners-enabled-1}
+##### Check de cluster : sans exécuteurs de check de cluster activés {#cluster-check-without-cluster-check-runners-enabled-1}
```sh
apiVersion: datadoghq.com/v2alpha1
@@ -263,13 +285,14 @@ metadata:
name: datadog
spec:
[...]
+ global:
+ env:
+ - name: DD_SECRET_BACKEND_TYPE
+ value: "aws.secrets"
+ - name: DD_SECRET_BACKEND_CONFIG
+ value: '{"aws_session":{"aws_region":""}}'
override:
nodeAgent:
- env:
- - name: DD_SECRET_BACKEND_TYPE
- value: "aws.secrets"
- - name: DD_SECRET_BACKEND_CONFIG
- value: '{"aws_session":{"aws_region":""}}'
# IAM role ARN required to grant the Agent permissions to access the AWS secret
serviceAccountAnnotations:
eks.amazonaws.com/role-arn:
@@ -286,7 +309,7 @@ spec:
-##### Vérification de cluster : avec les exécuteurs de vérification de cluster activés {#cluster-check-with-cluster-check-runners-enabled-1}
+##### Check de cluster : avec exécuteurs de check de cluster activés {#cluster-check-with-cluster-check-runners-enabled-1}
```sh
apiVersion: datadoghq.com/v2alpha1
@@ -295,18 +318,18 @@ metadata:
name: datadog
spec:
[...]
-spec:
+ global:
+ env:
+ - name: DD_SECRET_BACKEND_TYPE
+ value: "aws.secrets"
+ - name: DD_SECRET_BACKEND_CONFIG
+ value: '{"aws_session":{"aws_region":""}}'
features:
clusterChecks:
useClusterChecksRunners: true
override:
[...]
clusterChecksRunner:
- env:
- - name: DD_SECRET_BACKEND_TYPE
- value: "aws.secrets"
- - name: DD_SECRET_BACKEND_CONFIG
- value: '{"aws_session":{"aws_region":""}}'
# IAM role ARN required to grant the Agent permissions to access the AWS secret
serviceAccountAnnotations:
eks.amazonaws.com/role-arn:
@@ -322,7 +345,7 @@ spec:
```
-**Alternativement**, avec l'Opérateur Datadog v1.25.0+ et l'Agent v7.70+, vous pouvez utiliser les champs natifs `secretBackend.type` et `secretBackend.config` au lieu des variables d'environnement. Par exemple : `spec.global.secretBackend.type: "aws.secrets"` et `spec.global.secretBackend.config` avec `aws_session.aws_region: ""`.
+**Alternativement**, avec Datadog Operator v1.25.0+ et Agent v7.70+, vous pouvez utiliser les champs natifs `secretBackend.type` et `secretBackend.config` au lieu des variables d'environnement. Par exemple : `spec.global.secretBackend.type: "aws.secrets"` et `spec.global.secretBackend.config` avec `aws_session.aws_region: ""`.
{{% /tab %}}
{{< /tabs >}}
@@ -330,20 +353,20 @@ spec:
{{% /collapse-content %}}
-{{% collapse-content title="AWS SSM" level="h4" expanded=false id="id-for-ssm" %}}
+{{% collapse-content title="AWS SSM" level="h5" expanded=false id="id-for-ssm" %}}
Les services AWS suivants sont pris en charge :
-|valeur secret_backend_type | Service AWS |
+|Valeur secret_backend_type | Service AWS |
|---------------------------------------------|-----------------------------------------|
|`aws.ssm` |[AWS Systems Manager Parameter Store][1001] |
##### Configurer un profil d'instance {#set-up-an-instance-profile-1}
-Datadog recommande d'utiliser la méthode [profil d'instance][1006] pour récupérer les secrets, car AWS gère toutes les variables d'environnement et les profils de session pour vous. D'autres instructions sur la façon de procéder peuvent être trouvées dans la documentation officielle [AWS Secrets Manager][1001].
+Datadog recommande d'utiliser la [méthode du profil d'instance][1006] pour récupérer les secrets, car AWS gère toutes les variables d'environnement et les profils de session pour vous. Plus d'instructions sur la façon de procéder sont disponibles dans la [documentation officielle d'AWS Secrets Manager][1001].
##### Exemple de configuration {#configuration-example-1}
-Le AWS System Manager Parameter Store prend en charge un modèle hiérarchique. Par exemple, en supposant les chemins suivants du AWS System Manager Parameter Store :
+AWS Systems Manager Parameter Store prend en charge un modèle hiérarchique. Par exemple, en supposant les chemins AWS Systems Manager Parameter Store suivants :
```sh
/DatadogAgent/Production/ApiKey =
@@ -351,7 +374,7 @@ Le AWS System Manager Parameter Store prend en charge un modèle hiérarchique.
/DatadogAgent/Production/ParameterKey3 = ParameterStringValue3
```
-Les paramètres peuvent être récupérés de la manière suivante :
+Les paramètres peuvent être récupérés comme suit :
```yaml
# datadog.yaml
@@ -365,38 +388,63 @@ property1: "ENC[/DatadogAgent/Production/ParameterKey1]"
property2: "ENC[/DatadogAgent/Production/ParameterKey2]"
```
+##### Toutes les options `aws_session` {#all-aws-session-options-1}
+
+Les champs `aws_session` suivants configurent la manière dont l'Agent s'authentifie auprès d'AWS. Tous les champs sont facultatifs ; lorsqu'aucun n'est défini, l'Agent utilise la [default credential chain][1007] (profil d'instance, variables d'environnement, fichier de configuration partagé, etc.).
+
+| Champ | Description |
+|---|---|
+| `aws_region` | Région AWS (par exemple, `us-east-1`). |
+| `aws_access_key_id` | ID de clé d'accès AWS statique. À utiliser avec `aws_secret_access_key`. |
+| `aws_secret_access_key` | Clé d'accès secrète AWS statique. À utiliser avec `aws_access_key_id`. |
+| `aws_profile` | Profil nommé issu du fichier de configuration AWS partagé (`~/.aws/config`). |
+| `aws_role_arn` | ARN du rôle IAM à assumer avec `sts:AssumeRole`. |
+| `aws_external_id` | ID externe à transmettre lors de l'utilisation d'un rôle inter-comptes. |
+
{{% /collapse-content %}}
-{{% collapse-content title="Azure Keyvault Backend" level="h4" expanded=false id="id-for-azure" %}}
+{{% collapse-content title="Backend Azure KeyVault" level="h5" expanded=false id="id-for-azure" %}}
Les services Azure suivants sont pris en charge :
-| valeur secret_backend_type | Service Azure |
+| Valeur secret_backend_type | Azure Service |
| ----------------------------------------|------------------------|
-| `azure.keyvault` | [Azure Keyvault][2000] |
+| `azure.keyvault` | [Azure KeyVault][2000] |
-##### authentification Azure {#azure-authentication}
+##### Authentification Azure {#azure-authentication}
-Datadog recommande d'utiliser des identités gérées pour s'authentifier auprès d'Azure. Cela vous permet d'associer des ressources cloud avec des comptes AMI et supprime le besoin de mettre des informations sensibles dans votre fichier de configuration `datadog.yaml`.
+Datadog recommande d'utiliser des Managed Identities pour s'authentifier auprès d'Azure. Cela vous permet d'associer des ressources cloud à des comptes AMI et supprime le besoin d'insérer des informations sensibles dans votre fichier de configuration `datadog.yaml`.
-##### Identité gérée {#managed-identity}
+##### Managed identity {#managed-identity}
-Pour accéder à votre Key Vault, créez une identité gérée et assignez-la à votre machine virtuelle. Ensuite, configurez l'attribution de rôle appropriée sur le Key Vault pour permettre à cette identité d'accéder à ses secrets.
+Pour accéder à votre Key Vault, créez une Managed Identity et affectez-la à votre machine virtuelle. Ensuite, configurez l'attribution de rôle appropriée sur le Key Vault pour permettre à cette identité d'accéder à ses secrets.
##### Exemple de configuration {#configuration-example-2}
-La configuration de backend pour les secrets Azure Key Vault est structurée en YAML suivant ce schéma :
+{{< tabs >}}
+{{% tab "Fichier YAML de l'Agent" %}}
+
+La configuration du backend pour les secrets Azure Key Vault est structurée au format YAML selon le schéma suivant :
```yaml
# datadog.yaml
secret_backend_type: azure.keyvault
secret_backend_config:
keyvaulturl: {keyVaultURL}
+ azure_session:
+ azure_client_id: {clientID} # User-assigned managed identity client ID; omit this field for system-assigned
+```
+
+Lorsque vous utilisez des variables d'environnement, convertissez la configuration au format JSON :
+
+```sh
+DD_SECRET_BACKEND_TYPE="azure.keyvault"
+DD_SECRET_BACKEND_CONFIG='{"keyvaulturl": "", "azure_session": {"azure_client_id": ""}}'
```
-Le secret de backend est référencé dans votre fichier de configuration de l'Agent Datadog avec `ENC[ ]`. Voici un exemple où un secret en texte clair doit être récupéré :
+Le secret du backend est référencé dans votre fichier de configuration du Datadog Agent avec `ENC[ ]`. Voici un exemple où un secret en texte clair doit être récupéré :
```yaml
# datadog.yaml
@@ -404,31 +452,217 @@ Le secret de backend est référencé dans votre fichier de configuration de l'A
api_key: "ENC[secretKeyNameInKeyVault]"
```
+##### Toutes les options `azure_session` {#all-azure-session-options}
+
+Les champs `azure_session` suivants contrôlent la manière dont l'Agent s'authentifie auprès d'Azure. Tous les champs sont facultatifs — l'Agent recourt à [Default Azure Credential][2001] (variables d'environnement, Workload Identity, system-assigned Managed Identity, Azure CLI, etc.) lorsqu'aucun n'est défini.
+
+| Champ | Description |
+|---|---|
+| `azure_client_id` | Client ID d'une user-assigned Managed Identity, ou d'un service principal. |
+| `azure_tenant_id` | Tenant ID pour l'authentification par service principal. Requis avec `azure_client_id` et un secret client ou un certificat. |
+| `azure_client_secret` | Secret client pour l'authentification par principal de service. |
+| `azure_client_certificate_path` | Chemin d'accès à un fichier de certificat PEM ou PKCS12 pour l'authentification par certificat du service principal. |
+| `azure_client_certificate_password` | Mot de passe du fichier de certificat (si protégé par mot de passe). |
+| `azure_client_send_certificate_chain` | Définissez sur `true` pour envoyer la chaîne de certificats complète lors de l'utilisation de l'authentification par certificat. |
+
+L'authentification est sélectionnée en fonction des champs fournis :
+- **Service principal avec secret** : `azure_tenant_id` + `azure_client_id` + `azure_client_secret`
+- **Service principal avec certificat** : `azure_tenant_id` + `azure_client_id` + `azure_client_certificate_path`
+- **User-assigned Managed Identity** : `azure_client_id` uniquement
+- **Default Azure Credential** (recommandé) : omettez tous les champs `azure_session`
+
+{{% /tab %}}
+
+{{% tab "Helm" %}}
+
+Configurez le Datadog Agent pour utiliser Azure Key Vault afin de résoudre les secrets dans Helm en utilisant la configuration suivante :
+
+##### Check d'intégration {#integration-check-2}
+
+```sh
+datadog:
+ secretBackend:
+ type: "azure.keyvault"
+ config:
+ keyvaulturl: ""
+ azure_session:
+ azure_client_id: ""
+ confd:
+ # This is an example
+ .yaml: |-
+ ad_identifiers:
+ -
+ instances:
+ - [...]
+ password: "ENC[secretKeyNameInKeyVault]"
+```
+
+##### Check de cluster : sans exécuteurs de check de cluster activés {#cluster-check-without-cluster-check-runners-enabled-2}
+
+```sh
+datadog:
+ secretBackend:
+ type: "azure.keyvault"
+ config:
+ keyvaulturl: ""
+ azure_session:
+ azure_client_id: ""
+clusterAgent:
+ confd:
+ # This is an example
+ .yaml: |-
+ cluster_check: true
+ instances:
+ - [...]
+ password: "ENC[secretKeyNameInKeyVault]"
+```
+
+##### Check de cluster : avec exécuteurs de check de cluster activés {#cluster-check-with-cluster-check-runners-enabled-2}
+
+```sh
+datadog:
+ secretBackend:
+ type: "azure.keyvault"
+ config:
+ keyvaulturl: ""
+ azure_session:
+ azure_client_id: ""
+clusterAgent:
+ confd:
+ # This is an example
+ .yaml: |-
+ cluster_check: true
+ instances:
+ - [...]
+ password: "ENC[secretKeyNameInKeyVault]"
+clusterChecksRunner:
+ enabled: true
+```
+
+{{% /tab %}}
+
+{{% tab "Opérateur" %}}
+
+Configurez le Datadog Agent pour utiliser Azure Key Vault afin de résoudre les secrets avec le Datadog Operator en utilisant la configuration suivante :
+
+##### Check d'intégration {#integration-check-3}
+
+```sh
+apiVersion: datadoghq.com/v2alpha1
+kind: DatadogAgent
+metadata:
+ name: datadog
+spec:
+ [...]
+ global:
+ env:
+ - name: DD_SECRET_BACKEND_TYPE
+ value: "azure.keyvault"
+ - name: DD_SECRET_BACKEND_CONFIG
+ value: '{"keyvaulturl": "", "azure_session": {"azure_client_id": ""}}'
+ override:
+ nodeAgent:
+ extraConfd:
+ configDataMap:
+ # This is an example
+ .yaml: |-
+ ad_identifiers:
+ -
+ instances:
+ - [...]
+ password: "ENC[secretKeyNameInKeyVault]"
+```
+
+##### Check de cluster : sans exécuteurs de check de cluster activés {#cluster-check-without-cluster-check-runners-enabled-3}
+
+```sh
+apiVersion: datadoghq.com/v2alpha1
+kind: DatadogAgent
+metadata:
+ name: datadog
+spec:
+ [...]
+ global:
+ env:
+ - name: DD_SECRET_BACKEND_TYPE
+ value: "azure.keyvault"
+ - name: DD_SECRET_BACKEND_CONFIG
+ value: '{"keyvaulturl": "", "azure_session": {"azure_client_id": ""}}'
+ override:
+ clusterAgent:
+ extraConfd:
+ configDataMap:
+ # This is an example
+ .yaml: |-
+ cluster_check: true
+ instances:
+ - [...]
+ password: "ENC[secretKeyNameInKeyVault]"
+```
+
+##### Check de cluster : avec exécuteurs de check de cluster activés {#cluster-check-with-cluster-check-runners-enabled-3}
+
+```sh
+apiVersion: datadoghq.com/v2alpha1
+kind: DatadogAgent
+metadata:
+ name: datadog
+spec:
+ [...]
+ global:
+ env:
+ - name: DD_SECRET_BACKEND_TYPE
+ value: "azure.keyvault"
+ - name: DD_SECRET_BACKEND_CONFIG
+ value: '{"keyvaulturl": "", "azure_session": {"azure_client_id": ""}}'
+ features:
+ clusterChecks:
+ useClusterChecksRunners: true
+ override:
+ clusterAgent:
+ extraConfd:
+ configDataMap:
+ # This is an example
+ .yaml: |-
+ cluster_check: true
+ instances:
+ - [...]
+ password: "ENC[secretKeyNameInKeyVault]"
+```
+
+**Alternativement**, avec Datadog Operator v1.25.0+ et Agent v7.70+, vous pouvez utiliser les champs natifs `secretBackend.type` et `secretBackend.config` au lieu des variables d'environnement. Par exemple : `spec.global.secretBackend.type: "azure.keyvault"` et `spec.global.secretBackend.config` avec les clés `keyvaulturl` et `azure_session.azure_client_id`.
+
+{{% /tab %}}
+{{< /tabs >}}
+
{{% /collapse-content %}}
-{{% collapse-content title="GCP Secret Manager" level="h4" expanded=false id="id-for-gcp" %}}
+{{% collapse-content title="GCP Secret Manager" level="h5" expanded=false id="id-for-gcp" %}}
-**Disponible dans la version 7.74+ de l'Agent**
+*Disponible dans la version 7.74+ de l'Agent*
Les services GCP suivants sont pris en charge :
-| valeur secret_backend_type | GCP Service |
+| Valeur secret_backend_type | Service GCP |
| ------------------------------------------------------- | ------------------------------ |
| `gcp.secretmanager` | [GCP Secret Manager][5000] |
-##### politique d'authentification et d'accès GCP {#gcp-authentication-and-access-policy}
+##### Authentification GCP et politique d'accès {#gcp-authentication-and-access-policy}
-L'implémentation du Gestionnaire de Secrets GCP utilise [Identifiants par Défaut d'Application (ADC)][5001] pour l'authentification avec Google.
+L'implémentation de GCP Secret Manager utilise [Application Default Credentials (ADC)][5001] pour l'authentification auprès de Google.
-Pour interagir avec le Gestionnaire de Secrets GCP, le compte de service utilisé par l'Agent Datadog (tel que le compte de service de la VM, une identité de charge de travail ou des identifiants activés localement) nécessite la `secretmanager.versions.access` autorisation.
+Pour interagir avec GCP Secret Manager, le compte de service utilisé par le Datadog Agent (tel que le compte de service de la VM, une identité de charge de travail ou des identifiants activés localement) nécessite l'autorisation `secretmanager.versions.access`.
-Ceci peut être accordé avec le rôle prédéfini {{< ui >}}Secret Manager Secret Accessor{{< /ui >}} (`roles/secretmanager.secretAccessor`) ou un rôle personnalisé avec un [accès][5002] équivalent.
+Celle-ci peut être accordée avec le rôle prédéfini {{< ui >}}Secret Manager Secret Accessor{{< /ui >}} (`roles/secretmanager.secretAccessor`) ou un rôle personnalisé avec un [accès][5002] équivalent.
-Sur les environnements GCE ou GKE, l'ADC est configuré automatiquement via le compte de service attaché à l'instance ou au pod. Le compte de service attaché doit avoir les rôles appropriés pour accéder au Gestionnaire de Secrets GCP. De plus, l'environnement GCE ou GKE nécessite le `cloud-platform` [portée d'accès OAuth][5003].
+Sur les environnements d'exécution GCE ou GKE, l'ADC est configuré automatiquement via le compte de service associé à l'instance ou au pod. Le compte de service associé doit disposer des rôles appropriés pour accéder à GCP Secret Manager. De plus, l'environnement d'exécution GCE ou GKE nécessite `cloud-platform` [le périmètre d'accès OAuth][5003].
##### Exemple de configuration GCP {#gcp-configuration-example}
-Configurez l'Agent Datadog pour utiliser le Gestionnaire de Secrets GCP afin de résoudre les secrets avec la configuration suivante :
+{{< tabs >}}
+{{% tab "Fichier YAML de l'Agent" %}}
+
+Configurez le Datadog Agent pour utiliser GCP Secret Manager afin de résoudre les secrets avec la configuration suivante :
```yaml
# datadog.yaml
@@ -438,19 +672,26 @@ secret_backend_config:
project_id:
```
-Après avoir configuré l'Agent pour utiliser le Gestionnaire de Secrets GCP, référencez les secrets dans vos configurations avec `ENC[secret-name]` ou `ENC[secret-name;key;version;]`.
+Lorsque vous utilisez des variables d'environnement, convertissez la configuration au format JSON :
+
+```sh
+DD_SECRET_BACKEND_TYPE="gcp.secretmanager"
+DD_SECRET_BACKEND_CONFIG='{"gcp_session":{"project_id":""}}'
+```
+
+Après avoir configuré l'Agent Datadog pour utiliser GCP Secret Manager, référencez les secrets dans vos configurations avec `ENC[secret-name]` ou `ENC[secret-name;key;version;]`.
-La notation ENC est composée de :
+La notation ENC est composée :
-- `secret` : le nom du secret dans le Gestionnaire de Secrets GCP (par exemple, `datadog-api-key`).
-- `key` : (optionnel) la clé à extraire d'un secret au format JSON. Si vous utilisez des secrets en texte clair, vous pouvez omettre cela (exemple : `ENC[secret-name;;version]`).
-- `version` : (optionnel) le numéro de version du secret. Si non spécifié, la version `latest` est utilisée.
+- `secret` : le nom du secret dans GCP Secret Manager (par exemple, `datadog-api-key`).
+- `key` : (facultatif) la clé à extraire d'un secret au format JSON. Si vous utilisez des secrets en texte brut, vous pouvez omettre ceci (exemple : `ENC[secret-name;;version]`).
+- `version` : (facultatif) le numéro de version du secret. Si aucune version n'est spécifiée, la version `latest` est utilisée.
+ Exemples de syntaxe de version :
- `secret-key` - Version `latest` implicite
- `secret-key;;latest` - Version `latest` explicite
- `secret-key;;1` - Numéro de version spécifique
-Par exemple, en supposant des secrets GCP nommés `datadog-api-key` avec deux versions et `datadog-app-key` :
+Par exemple, en supposant des secrets GCP nommés `datadog-api-key` avec deux versions et `datadog-app-key` :
```yaml
# datadog.yaml
@@ -463,7 +704,7 @@ secret_backend_config:
project_id:
```
-Pour les secrets au format JSON, en supposant qu'un secret nommé `datadog-keys` contient :
+Pour les secrets au format JSON, en supposant qu'un secret nommé `datadog-keys` contienne :
```json
{
@@ -472,7 +713,7 @@ Pour les secrets au format JSON, en supposant qu'un secret nommé `datadog-keys`
}
```
-Référencez des clés spécifiques comme ceci :
+Référencez des clés spécifiques comme ceci :
```yaml
# datadog.yaml
@@ -485,39 +726,200 @@ secret_backend_config:
project_id:
```
-##### Versionnage des secrets {#secret-versioning}
+{{% /tab %}}
-GCP Secret Manager prend en charge les versions de secrets. L'implémentation de l'Agent prend également en charge le versionnage des secrets en utilisant le délimiteur `;`. Si aucune version n'est spécifiée, la version `latest` est utilisée.
+{{% tab "Helm" %}}
+Configurez le Datadog Agent pour utiliser GCP Secret Manager afin de résoudre les secrets dans Helm à l'aide de la configuration suivante :
-##### Support des secrets JSON {#json-secret-support}
+##### Check d'intégration {#integration-check-4}
-L'Agent Datadog prend en charge l'extraction de clés spécifiques à partir de secrets au format JSON en utilisant le délimiteur `;` :
+```sh
+datadog:
+ secretBackend:
+ type: "gcp.secretmanager"
+ config:
+ gcp_session:
+ project_id: ""
+ confd:
+ # This is an example
+ .yaml: |-
+ ad_identifiers:
+ -
+ instances:
+ - [...]
+ password: "ENC[secret-name]"
+```
-- `datadog;api_key` - Extrait le champ `api_key` du secret `datadog` avec une version implicite `latest`
-- `datadog;api_key;1` - Extrait le champ `api_key` du secret `datadog` de la version `1`
+##### Check de cluster : sans exécuteurs de check de cluster activés {#cluster-check-without-cluster-check-runners-enabled-4}
+
+```sh
+datadog:
+ secretBackend:
+ type: "gcp.secretmanager"
+ config:
+ gcp_session:
+ project_id: ""
+clusterAgent:
+ confd:
+ # This is an example
+ .yaml: |-
+ cluster_check: true
+ instances:
+ - [...]
+ password: "ENC[secret-name]"
+```
+
+##### Check de cluster : avec exécuteurs de check de cluster activés {#cluster-check-with-cluster-check-runners-enabled-4}
+
+```sh
+datadog:
+ secretBackend:
+ type: "gcp.secretmanager"
+ config:
+ gcp_session:
+ project_id: ""
+clusterAgent:
+ confd:
+ # This is an example
+ .yaml: |-
+ cluster_check: true
+ instances:
+ - [...]
+ password: "ENC[secret-name]"
+clusterChecksRunner:
+ enabled: true
+```
+
+{{% /tab %}}
+
+{{% tab "Opérateur" %}}
+
+Configurez le Datadog Agent pour utiliser GCP Secret Manager afin de résoudre les secrets avec le Datadog Operator à l'aide de la configuration suivante :
+
+##### Check de l'intégration {#integration-check-5}
+
+```sh
+apiVersion: datadoghq.com/v2alpha1
+kind: DatadogAgent
+metadata:
+ name: datadog
+spec:
+ [...]
+ global:
+ env:
+ - name: DD_SECRET_BACKEND_TYPE
+ value: "gcp.secretmanager"
+ - name: DD_SECRET_BACKEND_CONFIG
+ value: '{"gcp_session":{"project_id":""}}'
+ override:
+ nodeAgent:
+ extraConfd:
+ configDataMap:
+ # This is an example
+ .yaml: |-
+ ad_identifiers:
+ -
+ instances:
+ - [...]
+ password: "ENC[secret-name]"
+```
+
+##### Check de cluster : sans exécuteurs de check de cluster activés {#cluster-check-without-cluster-check-runners-enabled-5}
+
+```sh
+apiVersion: datadoghq.com/v2alpha1
+kind: DatadogAgent
+metadata:
+ name: datadog
+spec:
+ [...]
+ global:
+ env:
+ - name: DD_SECRET_BACKEND_TYPE
+ value: "gcp.secretmanager"
+ - name: DD_SECRET_BACKEND_CONFIG
+ value: '{"gcp_session":{"project_id":""}}'
+ override:
+ clusterAgent:
+ extraConfd:
+ configDataMap:
+ # This is an example
+ .yaml: |-
+ cluster_check: true
+ instances:
+ - [...]
+ password: "ENC[secret-name]"
+```
+
+##### Check de cluster : avec exécuteurs de check de cluster activés {#cluster-check-with-cluster-check-runners-enabled-5}
+
+```sh
+apiVersion: datadoghq.com/v2alpha1
+kind: DatadogAgent
+metadata:
+ name: datadog
+spec:
+ [...]
+ global:
+ env:
+ - name: DD_SECRET_BACKEND_TYPE
+ value: "gcp.secretmanager"
+ - name: DD_SECRET_BACKEND_CONFIG
+ value: '{"gcp_session":{"project_id":""}}'
+ features:
+ clusterChecks:
+ useClusterChecksRunners: true
+ override:
+ clusterAgent:
+ extraConfd:
+ configDataMap:
+ # This is an example
+ .yaml: |-
+ cluster_check: true
+ instances:
+ - [...]
+ password: "ENC[secret-name]"
+```
+
+**Alternativement**, avec Datadog Operator v1.25.0+ et Agent v7.70+, vous pouvez utiliser les champs natifs `secretBackend.type` et `secretBackend.config` au lieu des variables d'environnement. Par exemple : `spec.global.secretBackend.type: "gcp.secretmanager"` et `spec.global.secretBackend.config` avec `gcp_session.project_id: ""`.
+
+{{% /tab %}}
+{{< /tabs >}}
+
+##### Gestion des versions des secrets {#secret-versioning}
+
+GCP Secret Manager prend en charge les versions de secret. L'implémentation de l'Agent prend également en charge le versionnage des secrets à l'aide du délimiteur `;`. Si aucune version n'est spécifiée, la version `latest` est utilisée.
+
+
+##### Prise en charge des secrets JSON {#json-secret-support}
+
+Le Datadog Agent prend en charge l'extraction de clés spécifiques à partir de secrets au format JSON à l'aide du délimiteur `;` :
+
+- `datadog;api_key` - Extrait le champ `api_key` du secret `datadog` avec une version `latest` implicite
+- `datadog;api_key;1` - Extrait le champ `api_key` du secret `datadog` à partir de la version `1`
{{% /collapse-content %}}
-{{% collapse-content title="Backend HashiCorp Vault" level="h4" expanded=false id="id-for-hashicorp" %}}
+{{% collapse-content title="Backend Vault HashiCorp" level="h5" expanded=false id="id-for-hashicorp" %}}
Les services HashiCorp suivants sont pris en charge :
-| valeur secret_backend_type | Service HashiCorp |
+| Valeur de secret_backend_type | Service HashiCorp |
| ------------------------------------------ | -------------------------------------------------- |
-| `hashicorp.vault` | [HashiCorp Vault (Versions du moteur de secrets 1 et 2)][3000] |
+| `hashicorp.vault` | [HashiCorp Vault (Secrets Engine Versions 1 and 2)][3000] |
##### Comment configurer HashiCorp Vault {#how-to-set-up-hashicorp-vault}
1. Exécutez votre HashiCorp Vault. Consultez la [documentation officielle de HashiCorp Vault][3001] pour plus d'informations.
-2. Rédigez une politique qui donne la permission d'extraire des secrets de votre coffre-fort. Créez un fichier `*.hcl` et incluez la permission suivante si vous utilisez la version 1 du moteur de secrets :
+2. Rédigez une politique qui donne l'autorisation de récupérer des secrets depuis votre Vault. Créez un fichier `*.hcl` et incluez l'autorisation suivante si vous utilisez Secrets Engine Version 1 :
```
path "/" {
capabilities = ["read"]
}
```
-Si vous utilisez la version 2 du moteur de secrets, les permissions suivantes sont nécessaires :
+Si vous utilisez Secrets Engine Version 2, les autorisations suivantes sont nécessaires :
```
path "/data/" {
@@ -534,23 +936,23 @@ path "sys/mounts" {
```
3. Exécutez `vault policy write `
-4. Choisissez la méthode d'authentification à votre coffre-fort. Si vous utilisez la méthode du profil d'instance AWS, exécutez `vault auth enable aws`.
+4. Choisissez la méthode d'authentification auprès de votre Vault. Si vous utilisez la méthode de profil d'instance AWS, exécutez `vault auth enable aws`.
##### Instructions pour le profil d'instance AWS {#aws-instance-profile-instructions}
-Datadog recommande de vous authentifier en utilisant la [méthode du profil d'instance][3003] si vous exécutez votre HashiCorp Vault depuis une machine connectée à AWS.
+Datadog recommande de vous authentifier en utilisant la [méthode de profil d'instance][3003] si vous exécutez votre HashiCorp Vault depuis une machine connectée à AWS.
-Après cela, rédigez une [politique de coffre-fort spécifique à l'authentification][3004].
+Une fois cela configuré, rédigez une [politique Vault spécifique à l'authentification][3004].
##### Exemple de configuration {#configuration-example-3}
-Dans l'exemple suivant, supposons que le préfixe du chemin secret de HashiCorp Vault est `/Datadog/Production` avec une clé de paramètre de `apikey` :
+Dans l'exemple suivant, supposez que le préfixe du chemin secret HashiCorp Vault est `/Datadog/Production` avec une clé de paramètre `apikey` :
```sh
/DatadogAgent/Production/apikey: (SecureString) ""
```
-L'exemple suivant récupère la valeur de la clé API depuis HashiCorp Vault en utilisant AWS pour l'authentification.
+L'exemple suivant récupère la valeur de la clé d'API depuis HashiCorp Vault en tirant parti d'AWS pour l'authentification.
```yaml
# datadog.yaml
@@ -562,31 +964,87 @@ secret_backend_config:
vault_session:
vault_auth_type: aws
vault_aws_role: Name-of-IAM-role-attached-to-machine
- aws_region: us-east-1 // this field is optional, and will default to us-east-1 if not set
+ aws_region: us-east-1 # optional, defaults to us-east-1 if not set
```
+##### Toutes les options `vault_session` {#all-vault-session-options}
+
+Les `vault_session` champs suivants contrôlent la manière dont l'Agent s'authentifie auprès de Vault.
+
+| Champ | Description |
+|---|---|
+| `vault_auth_type` | Méthode d'authentification. Valeurs prises en charge : `aws`, `kubernetes`. S'il n'est pas défini, AppRole, userpass ou LDAP est utilisé en fonction des informations d'identification fournies. |
+| `vault_role_id` | ID de rôle AppRole. À utiliser avec `vault_secret_id`. |
+| `vault_secret_id` | ID secret AppRole. À utiliser avec `vault_role_id`. |
+| `vault_username` | Nom d'utilisateur pour l'authentification userpass. À utiliser avec `vault_password`. |
+| `vault_password` | Mot de passe pour l'authentification userpass. À utiliser avec `vault_username`. |
+| `vault_ldap_username` | Nom d'utilisateur pour l'authentification LDAP. À utiliser avec `vault_ldap_password`. |
+| `vault_ldap_password` | Mot de passe pour l'authentification LDAP. À utiliser avec `vault_ldap_username`. |
+| `vault_aws_role` | Nom du rôle Vault pour l'authentification AWS IAM. Requis lorsque `vault_auth_type: aws`. |
+| `vault_aws_iam_server_id` | Valeur pour l'en-tête `X-Vault-AWS-IAM-Server-ID`, utilisée pour empêcher les attaques par rejeu. |
+| `aws_region` | Région AWS pour les demandes d'authentification IAM. La valeur par défaut est `us-east-1`. |
+| `vault_kubernetes_role` | Nom du rôle Vault pour l'authentification Kubernetes. Requis lorsque `vault_auth_type: kubernetes`. |
+| `vault_kubernetes_jwt` | Jeton JWT du compte de service Kubernetes sous forme de chaîne. |
+| `vault_kubernetes_jwt_path` | Chemin vers le fichier de jeton JWT Kubernetes. La valeur par défaut est `/var/run/secrets/kubernetes.io/serviceaccount/token`. |
+| `vault_kubernetes_mount_path` | Chemin de montage Vault pour la méthode d'authentification Kubernetes. |
+| `implicit_auth` | Définissez sur `true` pour ignorer l'authentification et utiliser le jeton déjà défini dans l'environnement client Vault (par exemple, `VAULT_TOKEN`). |
+
+##### Autres options `secret_backend_config` pour Vault {#other-secret-backend-config-options-for-vault}
+
+Les champs de premier niveau `secret_backend_config` suivants s'appliquent également :
+
+| Champ | Description |
+|---|---|
+| `vault_address` | Adresse du serveur Vault (par exemple, `http://myvaultaddress.net`). Peut également être défini avec la variable d'environnement `VAULT_ADDR`. |
+| `vault_token` | Jeton Vault statique. À utiliser lorsqu'aucune méthode d'authentification n'est utilisée. |
+| `vault_namespace` | Espace de noms Vault pour les environnements Vault Enterprise. |
+
+##### Configuration TLS (`vault_tls_config`) {#tls-configuration-vault-tls-config}
+
+Pour activer le TLS mutuel ou une autorité de certification personnalisée, ajoutez un bloc `vault_tls_config` :
+
+```yaml
+secret_backend_type: hashicorp.vault
+secret_backend_config:
+ vault_address: https://myvaultaddress.net
+ vault_tls_config:
+ ca_cert: /path/to/ca.pem
+ client_cert: /path/to/client.pem
+ client_key: /path/to/client-key.pem
+ insecure: false
+```
+
+| Champ | Description |
+|---|---|
+| `ca_cert` | Chemin vers un fichier de certificat d'autorité de certification encodé en PEM. |
+| `ca_path` | Chemin vers un répertoire de fichiers de certificat d'autorité de certification encodés en PEM. |
+| `client_cert` | Chemin vers un fichier de certificat client encodé en PEM pour le mTLS. |
+| `client_key` | Chemin vers le fichier de clé privée du certificat client. |
+| `tls_server` | Nom de serveur attendu pour la vérification SNI TLS. |
+| `insecure` | Définissez sur `true` pour désactiver la vérification du certificat TLS. Ne pas utiliser en production. |
+
{{% /collapse-content %}}
-{{% collapse-content title="Secrets Kubernetes" level="h4" expanded=false id="id-for-kubernetes" %}}
+{{% collapse-content title="Secrets Kubernetes" level="h5" expanded=false id="id-for-kubernetes" %}}
-**Disponible dans la version 7.75+ de l'Agent**
+*Disponible dans la version 7.75+ de l'Agent*
Les services Kubernetes suivants sont pris en charge :
-| valeur secret_backend_type | Service |
+| Valeur secret_backend_type | Service |
|---------------------------|---------|
-| `k8s.secrets` | [Secrets Kubernetes][7000] |
+| `k8s.secrets` | [Kubernetes Secrets][7000] |
##### Prérequis {#prerequisites}
-Le backend des secrets Kubernetes nécessite :
+Le backend de secrets Kubernetes nécessite :
- **Identifiants ServiceAccount** : Par défaut, utilise des jetons ServiceAccount montés automatiquement (`automountServiceAccountToken: true`, voir [documentation Kubernetes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#opt-out-of-api-credential-automounting)). Des chemins personnalisés peuvent être configurés si nécessaire.
-- **Permissions RBAC** : Le ServiceAccount de l'Agent doit avoir les permissions pour lire les secrets des espaces de noms cibles.
-- **Accès au réseau** : Le pod Agent doit pouvoir atteindre le serveur API Kubernetes
+- **Autorisations RBAC** : Le ServiceAccount de l'Agent doit disposer des autorisations nécessaires pour lire les secrets des espaces de noms cibles
+- **Accès réseau** : Le pod de l'Agent doit pouvoir atteindre le serveur API Kubernetes
##### Configuration RBAC {#rbac-setup}
-Pour chaque espace de noms contenant des secrets, créez un `Role` et `RoleBinding` en utilisant l'exemple suivant avec le nom d'espace de noms correct :
+Pour chaque espace de noms contenant des secrets, créez un `Role` et un `RoleBinding` en utilisant l'exemple suivant avec le nom d'espace de noms correct :
```yaml
# Role: grants permission to read secrets
@@ -621,7 +1079,7 @@ subjects:
{{< tabs >}}
{{% tab "Fichier YAML de l'Agent" %}}
-Configurez l'Agent Datadog pour utiliser les Secrets Kubernetes avec la configuration suivante :
+Configurez le Datadog Agent pour utiliser les Secrets Kubernetes avec la configuration suivante :
```yaml
# datadog.yaml
@@ -632,12 +1090,12 @@ api_key: "ENC[secrets-prod/dd-api-key;api_key]"
app_key: "ENC[secrets-prod/dd-api-key;app_key]"
```
-Le format de notation ENC est `namespace/secret-name;key` :
-- `namespace` : L'espace de noms Kubernetes contenant le secret
-- `secret-name` : Le nom de la ressource Secret
-- `key` : La clé spécifique à extraire du champ de données du Secret
+Le format de notation ENC est `namespace/secret-name;key` :
+- `namespace` : Le Kubernetes namespace contenant le secret
+- `secret-name` : Le nom de la ressource Secret
+- `key` : La clé spécifique à extraire du champ de données du Secret
-**Exemple :** Étant donné un Secret dans l'espace de noms `secrets-ns` :
+**Exemple :** Étant donné un Secret dans le Kubernetes namespace `secrets-ns` :
```yaml
apiVersion: v1
@@ -657,8 +1115,8 @@ api_key: "ENC[secrets-ns/dd-api-key;api_key]"
app_key: "ENC[secrets-ns/dd-api-key;app_key]"
```
-**Support multi-namespace:**
-Chaque référence de secret peut spécifier un espace de noms différent (RBAC doit être configuré pour chacun) :
+**Prise en charge multi-namespace :**
+Chaque référence de secret peut spécifier un Kubernetes namespace différent (RBAC doit être configuré pour chacun) :
```yaml
api_key: "ENC[secrets-ns/dd-keys;api_key]"
@@ -669,7 +1127,7 @@ db_password: "ENC[secrets-shared/db-creds;password]"
{{% tab "Helm" %}}
-Configurez l'Agent Datadog pour utiliser les Secrets Kubernetes avec Helm :
+Configurez le Datadog Agent pour utiliser les Secrets Kubernetes avec Helm :
```yaml
# values.yaml
@@ -683,7 +1141,7 @@ datadog:
value: "ENC[secrets-ns/dd-api-key;api_key]"
```
-**Remarque :** Un espace réservé `apiKey` est requis pour la validation du chart Helm lors de l'utilisation d'un backend de secret pour résoudre la clé API. La variable d'environnement `DD_API_KEY` la remplace. Vous devez créer manuellement RBAC (Rôle + Liaison de rôle) pour chaque espace de noms contenant des secrets. Pour plus d'informations, consultez la section [Configuration RBAC](#rbac-setup).
+**Remarque :** Un espace réservé `apiKey` est requis pour la validation du chart Helm lors de l'utilisation du backend de secrets pour résoudre la clé d'API. La variable d'environnement `DD_API_KEY` la remplace. Vous devez créer manuellement le RBAC (Role + RoleBinding) pour chaque Kubernetes namespace contenant des secrets. Pour plus d'informations, consultez la section [Configuration RBAC](#rbac-setup).
**Alternativement**, avec le chart Helm v3.171.0+ et l'Agent v7.70+, vous pouvez utiliser le champ natif `datadog.secretBackend.type` au lieu des variables d'environnement.
@@ -691,7 +1149,7 @@ datadog:
{{% tab "Opérateur" %}}
-Configurez l'Agent Datadog pour utiliser les Secrets Kubernetes avec l'Opérateur Datadog :
+Configurez le Datadog Agent pour utiliser les Secrets Kubernetes avec le Datadog Operator :
```yaml
apiVersion: datadoghq.com/v2alpha1
@@ -712,18 +1170,18 @@ spec:
value: "ENC[secrets-ns/dd-api-key;api_key]"
```
-**Remarque:** Une clé API de substitution satisfait la validation de l'Opérateur lors de l'utilisation d'un backend de secret pour résoudre la clé API. La variable d'environnement `DD_API_KEY` la remplace. Vous devez créer manuellement RBAC (Rôle + Liaison de rôle) pour chaque espace de noms contenant des secrets. Pour plus d'informations, consultez la section [configuration RBAC](#rbac-setup).
+**Remarque :** Une clé API d'espace réservé satisfait la validation de l'Opérateur lors de l'utilisation du backend de secrets pour résoudre la clé d'API. La variable d'environnement `DD_API_KEY` la remplace. Vous devez créer manuellement le RBAC (Role + RoleBinding) pour chaque Kubernetes namespace contenant des secrets. Pour plus d'informations, consultez la section [Configuration RBAC](#rbac-setup).
-**Alternativement**, avec Datadog Operator v1.25.0+ et Agent v7.70+, vous pouvez utiliser le champ natif `spec.global.secretBackend.type` au lieu des variables d'environnement.
+**Alternativement**, avec Datadog Operator v1.25.0+ et l'Agent v7.70+, vous pouvez utiliser le champ natif `spec.global.secretBackend.type` au lieu des variables d'environnement.
{{% /tab %}}
{{< /tabs >}}
-##### Configuration de chemin personnalisée {#custom-path-configuration}
+##### Configuration de chemin personnalisé {#custom-path-configuration}
Si votre configuration ne suit pas les emplacements par défaut pour l'authentification basée sur ServiceAccount, vous pouvez spécifier `token_path` et `ca_path` à la place.
{{< tabs >}}
-{{% tab "Agent YAML" %}}
+{{% tab "YAML de l'Agent" %}}
```yaml
secret_backend_type: k8s.secrets
@@ -744,7 +1202,7 @@ datadog:
value: '{"token_path":"/custom/path/to/token","ca_path":"/custom/path/to/ca.crt"}'
```
-**Alternativement**, avec Helm chart v3.171.0+, vous pouvez utiliser : `datadog.secretBackend.type: "k8s.secrets"` et `datadog.secretBackend.config` avec les clés `token_path` et `ca_path`.
+**Alternativement**, avec le chart Helm v3.171.0+, vous pouvez utiliser : `datadog.secretBackend.type: "k8s.secrets"` et `datadog.secretBackend.config` avec les clés `token_path` et `ca_path`.
{{% /tab %}}
@@ -765,12 +1223,12 @@ override:
{{% /tab %}}
{{< /tabs >}}
-##### Configuration personnalisée du serveur API {#custom-api-server-configuration}
+##### Configuration de serveur API personnalisé {#custom-api-server-configuration}
Si votre configuration n'expose pas les variables d'environnement par défaut `KUBERNETES_SERVICE_HOST` et `KUBERNETES_SERVICE_PORT`, vous pouvez fournir une URL `api_server` pour interagir avec l'API REST de Kubernetes.
{{< tabs >}}
-{{% tab "Agent YAML" %}}
+{{% tab "YAML de l'Agent" %}}
```yaml
secret_backend_type: k8s.secrets
@@ -790,7 +1248,7 @@ datadog:
value: '{"api_server":"https://{KUBERNETES_SERVICE_HOST}:{KUBERNETES_SERVICE_PORT}"}'
```
-**Alternativement**, avec Helm chart v3.171.0+, vous pouvez utiliser : `datadog.secretBackend.type: "k8s.secrets"` et `datadog.secretBackend.config` avec la clé `api_server`.
+**Alternativement**, avec le chart Helm v3.171.0+, vous pouvez utiliser : `datadog.secretBackend.type: "k8s.secrets"` et `datadog.secretBackend.config` avec la clé `api_server`.
{{% /tab %}}
@@ -813,25 +1271,25 @@ override:
{{% /collapse-content %}}
-{{% collapse-content title="Secrets Docker" level="h4" expanded=false id="id-for-docker" %}}
+{{% collapse-content title="Docker Secrets" level="h5" expanded=false id="id-for-docker" %}}
-**Disponible dans la version 7.75+ de l'Agent**
+*Disponible dans la version 7.75+ de l'Agent*
-Les services Docker suivants sont pris en charge:
+Les services Docker suivants sont pris en charge :
-| valeur secret_backend_type | Service |
+| Valeur secret_backend_type | Service |
|---------------------------|---------|
-| `docker.secrets` | [Secrets Docker][6001] |
+| `docker.secrets` | [Docker Secrets][6001] |
##### Prérequis {#prerequisites-1}
-Le backend des secrets Docker prend en charge à la fois les [secrets Docker Swarm][6002] et les [secrets Docker Compose][6003]. Par défaut, à la fois Swarm et Compose montent automatiquement les secrets dans le conteneur sous forme de fichiers à `/run/secrets` (Linux) ou `C:\ProgramData\Docker\secrets` (Windows).
+Le backend de secrets Docker prend en charge à la fois les [Docker Swarm secrets][6002] et les [Docker Compose secrets][6003]. Par défaut, Swarm et Compose montent automatiquement les secrets dans le conteneur sous forme de fichiers à `/run/secrets` (Linux) ou `C:\ProgramData\Docker\secrets` (Windows).
-**Remarque**: Les secrets Compose peuvent être basés sur des fichiers (pointant vers des fichiers locaux) ou externes (référencer des secrets Swarm existants).
+**Remarque** : Les secrets Compose peuvent être basés sur des fichiers (pointant vers des fichiers locaux) ou externes (faisant référence à des secrets Swarm existants).
##### Exemple de configuration {#configuration-example-5}
-Configurez l'Agent Datadog pour utiliser les Secrets Docker avec la configuration suivante :
+Configurez le Datadog Agent pour utiliser Docker Secrets avec la configuration suivante :
```yaml
# datadog.yaml
@@ -841,11 +1299,11 @@ secret_backend_type: docker.secrets
api_key: "ENC[dd_api_key]"
```
-Le format de notation ENC est le nom du secret, qui correspond au nom de fichier dans `/run/secrets/`:
+Le format de notation ENC est le nom du secret, qui correspond au nom de fichier dans `/run/secrets/` :
- `ENC[api_key]` lit depuis `/run/secrets/api_key` (Linux) ou `C:\ProgramData\Docker\secrets\api_key` (Windows)
-**Chemin des secrets personnalisés :**
-Si Docker Swarm ou Compose sont configurés pour monter des secrets à un emplacement différent, vous pouvez le spécifier comme ceci:
+**Chemin d'accès personnalisé aux secrets :**
+Si Docker Swarm ou Docker Compose sont configurés pour monter des secrets à un emplacement différent, vous pouvez le spécifier comme suit :
```yaml
secret_backend_type: docker.secrets
@@ -855,7 +1313,7 @@ secret_backend_config:
##### Exemple Docker Swarm {#docker-swarm-example}
-[Créer][6002] et utiliser un secret Docker Swarm:
+[Créer][6002] et utiliser un secret Docker Swarm :
```bash
# Create the secret
@@ -872,11 +1330,11 @@ docker service create \
registry.datadoghq.com/agent:latest
```
-Le secret `dd_api_key` est automatiquement monté à `/run/secrets/dd_api_key`, et l'Agent le lit en utilisant le backend `docker.secrets`.
+Le secret `dd_api_key` est automatiquement monté sur `/run/secrets/dd_api_key`, et l'Agent le lit en utilisant le backend `docker.secrets`.
##### Exemple Docker Compose {#docker-compose-example}
-[Créer][6003] un `docker-compose.yml` avec des secrets basés sur des fichiers:
+[Créer][6003] un `docker-compose.yml` avec des secrets basés sur des fichiers :
```yaml
version: '3.8'
@@ -902,22 +1360,22 @@ Le fichier secret `./secrets/api_key.txt` est monté à `/run/secrets/dd_api_key
{{% /collapse-content %}}
-{{% collapse-content title="Backends de secrets de fichiers JSON, YAML ou TEXT" level="h4" expanded=false id="id-for-json-yaml-text" %}}
+{{% collapse-content title="Backends de secrets de fichiers JSON, YAML ou TEXT" level="h5" expanded=false id="id-for-json-yaml-text" %}}
-| valeur secret_backend_type | Service de fichier |
+| valeur de secret_backend_type | Service de fichiers |
|---------------------------------------------|-----------------------------------------|
|`file.json` |[JSON][4001] |
|`file.yaml` |[YAML][4002] | |
|`file.text` |[TEXT][4003] | |
-##### Permissions de fichier {#file-permissions}
-Le backend de fichier nécessite uniquement des permissions **lecture** pour les fichiers JSON, YAML ou TEXT configurés. Ces permissions doivent être accordées à l'utilisateur local de l'Agent Datadog (`dd-agent` sur Linux, `ddagentuser` sur Windows).
+##### Autorisations de fichier {#file-permissions}
+Le backend de fichier nécessite uniquement des autorisations de **lecture** pour les fichiers JSON, YAML ou TEXT configurés. Ces autorisations doivent être accordées à l'utilisateur local du Datadog Agent (`dd-agent` sous Linux, `ddagentuser` sous Windows).
{{< tabs >}}
{{% tab "Backend de fichier JSON" %}}
-**Remarque**: Un seul niveau de profondeur JSON est pris en charge (par exemple, `{"key": "value"}`)
+**Remarque** : seul un niveau de profondeur JSON est pris en charge (par exemple, `{"key": "value"}`)
##### Exemple de configuration {#configuration-example-6}
@@ -931,7 +1389,7 @@ Par exemple, avec un fichier JSON dans `/path/to/secret.json` contenant ce qui s
}
```
-Vous pouvez utiliser cette configuration pour récupérer ses secrets :
+Vous pouvez utiliser cette configuration pour en extraire les secrets :
```yaml
# datadog.yaml
@@ -946,7 +1404,7 @@ secret_backend_config:
{{% tab "Backend de fichier YAML" %}}
-**Remarque** : Un seul niveau de profondeur YAML est pris en charge (par exemple, `key: value`)
+**Remarque** : Un seul niveau de profondeur YAML est pris en charge (par exemple, `key: value`)
##### Exemple de configuration {#configuration-example-7}
@@ -958,7 +1416,7 @@ Vous pouvez utiliser un fichier YAML pour stocker des secrets localement.
datadog_api_key: your api key
```
-Vous pouvez utiliser la configuration suivante pour récupérer les secrets de celui-ci :
+Vous pouvez utiliser la configuration suivante pour en extraire des secrets :
```yaml
# datadog.yaml
@@ -969,11 +1427,11 @@ secret_backend_config:
```
{{% /tab %}}
-{{% tab "Backend de fichier TEXT" %}}
+{{% tab "Backend de fichier TEXTE" %}}
-**Disponible dans la version 7.75+ de l'Agent**
+*Disponible dans la version 7.75+ de l'Agent*
-**Remarque** : Chaque secret doit être stocké dans un fichier texte individuel.
+**Remarque** : Chaque secret doit être stocké dans son propre fichier texte individuel.
##### Exemple de configuration {#configuration-example-8}
@@ -993,7 +1451,7 @@ your_api_key_value
your_app_key_value
```
-Vous pouvez utiliser cette configuration pour récupérer les secrets de ces fichiers :
+Vous pouvez utiliser cette configuration pour en extraire les secrets :
```yaml
# datadog.yaml
@@ -1005,31 +1463,177 @@ secret_backend_config:
secrets_path: /path/to/secrets
```
-##### Sécurité des chemins : {#path-security}
+##### Sécurité du chemin : {#path-security}
-- Les chemins relatifs dans `ENC[]` sont résolus par rapport à `secrets_path` (par exemple, `ENC[dd_api_key]` avec `secret_path: /path/to/secrets` sera résolu en `/path/to/secrets/dd_api_key`)
-- Les chemins absolus dans `ENC[]` doivent être dans `secrets_path` (par exemple, `ENC[/path/to/secrets/dd_api_key]` avec `secret_path: /path/to/secrets` fonctionnera)
-- Les tentatives de traversée de chemin (par exemple, `ENC[../etc/passwd]`) sont bloquées et échoueront avec "chemin en dehors du répertoire autorisé"
+- Les chemins relatifs dans `ENC[]` sont résolus par rapport à `secrets_path` (par ex., `ENC[dd_api_key]` avec `secret_path: /path/to/secrets` sera résolu en `/path/to/secrets/dd_api_key`)
+- Les chemins absolus dans `ENC[]` doivent se trouver dans `secrets_path` (par ex., `ENC[/path/to/secrets/dd_api_key]` avec `secret_path: /path/to/secrets` fonctionnera)
+- Les tentatives de parcours de répertoire (par ex. `ENC[../etc/passwd]`) sont bloquées et échoueront avec le message « path outside allowed directory »
-**Remarque :** Certains outils ajoutent automatiquement des sauts de ligne lors de l'exportation de secrets vers des fichiers. Voir [Supprimer les sauts de ligne finaux](#remove-trailing-line-breaks) pour savoir comment gérer cela.
+**Remarque :** Certains outils ajoutent automatiquement des sauts de ligne lors de l'exportation de secrets vers des fichiers. Consultez [Supprimer les sauts de ligne de fin](#remove-trailing-line-breaks) pour savoir comment gérer cela.
{{% /tab %}}
{{< /tabs >}}
{{% /collapse-content %}}
+{{% collapse-content title="Clé de registre Windows" level="h4" expanded=false id="id-for-windows-regkey" %}}
-### Option 2 : Utiliser le script intégré pour Kubernetes et Docker {#option-2-using-the-built-in-script-for-kubernetes-and-docker}
+**Disponible dans la version 7.82+ de l'Agent**
-Pour les environnements conteneurisés, les images de conteneur de l'Agent Datadog incluent un script intégré `/readsecret_multiple_providers.sh` à partir de la version v7.32.0. Ce script prend en charge la lecture des secrets depuis :
+Les services Windows suivants sont pris en charge :
+
+| Valeur secret_backend_type | Service |
+|---------------------------|---------|
+| `windows.regkey` | Registre Windows |
+
+##### Prérequis {#prerequisites-2}
+
+Ce backend est pris en charge sur Windows uniquement. La clé de registre doit être lisible par le compte sous lequel le Datadog Agent s'exécute (par défaut `ddagentuser`). Les clés sous `HKLM` sont lisibles par tous les utilisateurs locaux par défaut. Datadog recommande de restreindre l'ACL afin que seuls `ddagentuser` et `SYSTEM` puissent lire la clé.
+
+##### Exemple de configuration {#configuration-example-9}
+
+Configurez le Datadog Agent pour utiliser le backend Windows Registry Key avec la configuration suivante :
+
+```yaml
+# datadog.yaml
+secret_backend_type: windows.regkey
+
+api_key: 'ENC[SOFTWARE\Datadog\secrets:api_key]'
+```
+
+Référencez les secrets en utilisant le format `ENC[:]`, où `registry-path` est le sous-chemin sous la clé racine et `value-name` est la valeur de registre à lire.
+
+Par défaut, la clé racine est `HKLM`. Pour utiliser une ruche différente, définissez `root_key`. Seules les valeurs suivantes sont acceptées (toute autre valeur renvoie une erreur) :
+
+`HKLM`, `HKCU`, `HKCR`, `HKU`, `HKCC` (les formes longues telles que `HKEY_LOCAL_MACHINE` sont également prises en charge)
+
+```yaml
+secret_backend_type: windows.regkey
+secret_backend_config:
+ root_key: HKCU
+```
+
+##### Configurer la clé de registre {#set-up-the-registry-key}
+
+Cet exemple de script shell PowerShell montre comment configurer un registre (à exécuter en tant qu'administrateur après l'installation) :
+
+```powershell
+# Create the key and set the secret value
+New-Item -Path "HKLM:\SOFTWARE\Datadog\secrets" -Force
+Set-ItemProperty -Path "HKLM:\SOFTWARE\Datadog\secrets" -Name "api_key" -Value ""
+
+# Restrict read access to ddagentuser and SYSTEM (recommended)
+$acl = Get-Acl "HKLM:\SOFTWARE\Datadog\secrets"
+$acl.SetAccessRuleProtection($true, $false)
+$acl.SetAccessRule((New-Object System.Security.AccessControl.RegistryAccessRule -ArgumentList "SYSTEM", "ReadKey", "Allow"))
+$acl.SetAccessRule((New-Object System.Security.AccessControl.RegistryAccessRule -ArgumentList "ddagentuser", "ReadKey", "Allow"))
+$acl.SetAccessRule((New-Object System.Security.AccessControl.RegistryAccessRule -ArgumentList "Administrators", "FullControl", "Allow"))
+Set-Acl "HKLM:\SOFTWARE\Datadog\secrets" $acl
+```
+
+{{% /collapse-content %}}
+
+#### Plusieurs backends {#multiple-backends}
+
+*Disponible dans la version 7.80+ de l'Agent*
+
+Au lieu d'un `secret_backend_type` unique, vous pouvez déclarer plusieurs backends nommés sous `multi_secret_backends`. Chaque backend possède ses propres `type` et `config`, et les secrets sont acheminés vers un backend spécifique en utilisant un préfixe `backendName;` dans le handle `ENC[]`.
+
+Si plusieurs des paramètres suivants sont définis, le paramètre ayant la priorité la plus élevée prend effet et les autres sont ignorés avec un avertissement :
+
+1. `secret_backend_command`
+2. `secret_backend_type`
+3. `multi_secret_backends`
+
+##### Configuration {#configuration}
+
+```yaml
+# datadog.yaml
+
+multi_secret_backends:
+ :
+ type:
+ config:
+ :
+```
+
+Chaque `` est un identifiant arbitraire que vous choisissez. Il ne peut pas contenir de point-virgule, car `;` est le délimiteur utilisé dans les handles `ENC[]`. Les champs `type` et `config` suivent le même schéma que `secret_backend_type` et `secret_backend_config` pour le backend correspondant.
+
+##### `ENC[]` notation {#enc-notation}
+
+Lorsque `multi_secret_backends` est actif, faites précéder les handles `ENC[]` du nom du backend suivi d'un point-virgule :
+
+```
+ENC[;]
+```
+
+Seul le **premier** point-virgule est traité comme le délimiteur de backend. Les clés secrètes qui contiennent elles-mêmes des points-virgules (par exemple, `namespace/secret-name;key` de style Kubernetes) continuent de fonctionner.
+
+##### Exemple {#example}
+
+La configuration suivante lit les secrets à partir de deux backends de fichiers simultanément :
+
+```yaml
+# datadog.yaml
+multi_secret_backends:
+ yaml_secrets:
+ type: file.yaml
+ config:
+ file_path: /etc/datadog-agent/secrets.yaml
+ aws_secrets:
+ type: aws.secrets
+ config:
+ aws_session:
+ aws_region: us-east-1
+```
+
+Référencez les secrets en les faisant précéder du nom du backend :
+
+```yaml
+# datadog.yaml
+api_key: ENC[yaml_secrets;api_key]
+app_key: ENC[aws_secrets;My-Secrets;appKey]
+```
+
+##### Migration depuis `secret_backend_type` {#migrating-from-secret-backend-type}
+
+Pour passer d'un `secret_backend_type` unique à `multi_secret_backends` :
+
+1. Déplacez `secret_backend_type` et `secret_backend_config` dans une entrée nommée sous `multi_secret_backends`.
+2. Supprimez `secret_backend_type` et `secret_backend_config` du niveau supérieur.
+3. Mettez à jour tous les handles `ENC[secretKey]` vers `ENC[backendName;secretKey]`.
+
+```yaml
+# Before
+secret_backend_type: file.yaml
+secret_backend_config:
+ file_path: /etc/datadog-agent/secrets.yaml
+
+api_key: ENC[api_key]
+
+# After
+multi_secret_backends:
+ my_yaml:
+ type: file.yaml
+ config:
+ file_path: /etc/datadog-agent/secrets.yaml
+
+api_key: ENC[my_yaml;api_key]
+```
+
+### Option 2 : Utilisation du script intégré pour Kubernetes et Docker {#option-2-using-the-built-in-script-for-kubernetes-and-docker}
+
+*Disponible dans la version 7.32+ de l'Agent*
+
+Pour les environnements conteneurisés, les images de conteneur du Datadog Agent incluent un script intégré `/readsecret_multiple_providers.sh`. Ce script prend en charge la lecture de secrets à partir de :
* Fichiers : en utilisant `ENC[file@/path/to/file]`
* Secrets Kubernetes : en utilisant `ENC[k8s_secret@namespace/secret-name/key]`
{{< tabs >}}
-{{% tab "Operator Datadog" %}}
+{{% tab "Datadog Operator" %}}
-Pour utiliser cet exécutable avec l'Opérateur Datadog, configurez-le comme suit :
+Pour utiliser cet exécutable avec le Datadog Operator, configurez-le comme suit :
```yaml
apiVersion: datadoghq.com/v2alpha1
@@ -1067,7 +1671,7 @@ DD_SECRET_BACKEND_COMMAND=/readsecret_multiple_providers.sh
#### Exemple : Lecture à partir de fichiers montés {#example-reading-from-mounted-files}
-Kubernetes prend en charge [l'exposition des Secrets en tant que fichiers][2] à l'intérieur d'un pod que l'Agent peut lire pour résoudre les secrets.
+Kubernetes prend en charge [l'exposition de secrets sous forme de fichiers][2] à l'intérieur d'un pod que l'Agent peut lire pour résoudre les secrets.
Dans Kubernetes, vous pouvez monter un Secret en tant que volume comme ceci :
@@ -1091,23 +1695,23 @@ Vous pouvez ensuite référencer le secret comme ceci :
password: ENC[file@/etc/secret-volume/password]
```
-**Remarques** :
-- Le Secret doit exister dans le même espace de noms que le pod dans lequel il est monté.
-- Le script peut accéder à tous les sous-dossiers, y compris le `/var/run/secrets/kubernetes.io/serviceaccount/token` sensible. Ainsi, Datadog recommande d'utiliser un dossier dédié au lieu de `/var/run/secrets`.
+**Remarques** :
+- Le Secret doit exister dans le même espace de nommage que le pod dans lequel il est monté.
+- Le script est capable d'accéder à tous les sous-dossiers, y compris le dossier sensible `/var/run/secrets/kubernetes.io/serviceaccount/token`. À ce titre, Datadog recommande d'utiliser un dossier dédié plutôt que `/var/run/secrets`.
-[Les secrets de Docker swarm][3] sont montés dans le dossier `/run/secrets`. Par exemple, le secret Docker `db_prod_passsword` est situé dans `/run/secrets/db_prod_password` dans le conteneur de l'Agent. Cela serait référencé dans la configuration avec `ENC[file@/run/secrets/db_prod_password]`.
+Les [secrets Docker swarm][3] sont montés dans le dossier `/run/secrets`. Par exemple, le secret Docker `db_prod_passsword` est situé dans `/run/secrets/db_prod_password` dans le conteneur de l'Agent. Celui-ci serait référencé dans la configuration avec `ENC[file@/run/secrets/db_prod_password]`.
-#### Exemple : Lecture d'un secret Kubernetes à travers les namespaces {#example-reading-a-kubernetes-secret-across-namespaces}
+#### Exemple : Lecture d'un secret Kubernetes entre différents espaces de nommage {#example-reading-a-kubernetes-secret-across-namespaces}
-Si vous souhaitez que l'Agent lise un Secret d'un namespace différent, utilisez le préfixe `k8s_secret@`. Exemple :
+Si vous souhaitez que l'Agent lise un Secret provenant d'un espace de nommage différent, utilisez le préfixe `k8s_secret@`. Exemple :
```
password: ENC[k8s_secret@database/database-secret/password]
```
-Configurez RBAC pour permettre au compte de service de l'Agent de lire le Secret. Le rôle suivant accorde l'accès en lecture au Secret `database-secret` dans le namespace `database` :
+Configurez le RBAC pour permettre au compte de service de l'Agent de lire le Secret. Le rôle suivant accorde un accès en lecture au Secret `database-secret` dans l'espace de nommage `database` :
{{< tabs >}}
-{{% tab "Operator Datadog" %}}
+{{% tab "Datadog Operator" %}}
```yaml
apiVersion: datadoghq.com/v2alpha1
@@ -1123,7 +1727,7 @@ spec:
secrets:
- "database-secret"
```
-***Remarque*** : Chaque namespace dans la liste des rôles doit également être configuré dans la variable d'environnement `WATCH_NAMESPACE` ou `DD_AGENT_WATCH_NAMESPACE` sur le déploiement de l'Opérateur Datadog.
+***Remarque*** : Chaque espace de nommage dans la liste des rôles doit également être configuré dans la variable d'environnement `WATCH_NAMESPACE` ou `DD_AGENT_WATCH_NAMESPACE` sur le déploiement du Datadog Operator.
{{% /tab %}}
{{% tab "Helm" %}}
@@ -1141,7 +1745,7 @@ datadog:
{{< /tabs >}}
-Alternativement, vous pouvez définir les ressources RBAC directement :
+Sinon, vous pouvez définir directement les ressources RBAC :
```yaml
apiVersion: rbac.authorization.k8s.io/v1
@@ -1171,15 +1775,15 @@ roleRef:
apiGroup: ""
```
-Ce `Role` donne accès au `Secret: database-secret` dans le `Namespace: database`. Le `RoleBinding` relie cette permission au `ServiceAccount: datadog-agent` dans le `Namespace: default`. Cela doit être ajouté manuellement à votre cluster en fonction de vos ressources déployées.
+Ceci `Role` donne accès au `Secret: database-secret` dans le `Namespace: database`. Le `RoleBinding` lie cette autorisation au `ServiceAccount: datadog-agent` dans le `Namespace: default`. Ceci doit être ajouté manuellement à votre cluster en fonction de vos ressources déployées.
### Option 3 : Création d'un exécutable personnalisé {#option-3-creating-a-custom-executable}
-Pour récupérer des secrets, l'Agent utilise un exécutable externe que vous fournissez. L'exécutable est utilisé lorsque de nouveaux secrets sont découverts et sont mis en cache pour le cycle de vie de l'Agent. Si vous devez mettre à jour ou faire pivoter un secret, vous devez redémarrer l'Agent pour le recharger.
+Pour récupérer des secrets, l'Agent utilise un exécutable externe que vous fournissez. L'exécutable est utilisé lorsque de nouveaux secrets sont découverts et sont mis en cache pour la durée de vie de l'Agent. Si vous devez mettre à jour ou faire pivoter un secret, vous devez redémarrer l'Agent pour le recharger.
-Cela vous permet d'utiliser n'importe quelle solution de gestion de secrets et vous donne un contrôle total sur la façon dont l'Agent accède aux secrets.
+Cela vous permet d'utiliser n'importe quelle solution de gestion des secrets et vous donne un contrôle total sur la façon dont l'Agent accède aux secrets.
-L'Agent envoie à cet exécutable une charge utile JSON via l'entrée standard contenant une liste de gestionnaires de secrets à résoudre. Ensuite, votre exécutable récupère chaque secret et les renvoie au format JSON via la sortie standard.
+L'Agent envoie à cet exécutable une charge utile JSON via l'entrée standard contenant une liste de descripteurs de secrets à résoudre. Ensuite, votre exécutable récupère chaque secret et les renvoie dans un format JSON via une sortie standard.
L'exemple suivant montre ce que l'Agent envoie à votre exécutable sur STDIN :
@@ -1190,11 +1794,11 @@ L'exemple suivant montre ce que l'Agent envoie à votre exécutable sur STDIN :
}
```
-* `version` (string) : La version du format.
-* `secrets` (liste de chaînes) : Chaque chaîne est un identifiant pour un secret à récupérer.
+* `version` (chaîne) : La version du format.
+* `secrets` (liste de chaînes) : Chaque chaîne est un descripteur pour un secret à récupérer.
-L'exécutable répond par la sortie STDOUT suivante :
+L'exécutable répond via la sortie STDOUT suivante :
```
{
@@ -1203,16 +1807,16 @@ L'exécutable répond par la sortie STDOUT suivante :
}
```
-* `value` (string) : La valeur secrète à utiliser dans les configurations. Cela peut être `null` en cas d'erreur.
-* `error` (string) : Un message d'erreur ou `null`.
+* `value` (chaîne) : La valeur du secret à utiliser dans les configurations. Cela peut être `null` en cas d'erreur.
+* `error` (chaîne) : Un message d'erreur ou `null`.
-Si un secret ne peut pas être résolu (soit en retournant un code de sortie non nul, soit une erreur non nulle), la configuration associée est ignorée par l'Agent.
+Si un secret ne peut pas être résolu (soit en renvoyant un code de sortie non nul, soit une erreur non nulle), la configuration associée est ignorée par l'Agent.
-**Ne jamais afficher d'informations sensibles sur `stderr`**. Si le binaire se termine avec un code d'état différent de `0`, l'Agent enregistre la sortie d'erreur standard de votre exécutable pour le dépannage.
+**Ne jamais afficher d'informations sensibles sur `stderr`**. Si le binaire se termine avec un code de statut différent de `0`, l'Agent enregistre la sortie d'erreur standard de votre exécutable pour le dépannage.
Vous pouvez également créer votre propre exécutable de récupération de secrets en utilisant n'importe quel langage. La seule exigence est qu'il suive le format d'entrée/sortie décrit précédemment.
-Voici un exemple en Go qui retourne des secrets fictifs :
+Voici un exemple en Go qui renvoie des secrets fictifs :
```go
package main
@@ -1255,7 +1859,7 @@ func main() {
}
```
-Cela transforme votre configuration :
+Ceci transforme votre configuration :
```yaml
instances:
@@ -1264,7 +1868,7 @@ instances:
password: ENC[db_prod_password]
```
-En ce qui suit en mémoire :
+En mémoire, cela se présente comme suit:
```yaml
instances:
@@ -1288,44 +1892,46 @@ L'Agent exécute l'exécutable fourni en tant que sous-processus. Les modèles d
Sur Linux, votre exécutable doit :
-* Appartenir au même utilisateur exécutant l'Agent (`dd-agent` par défaut, ou `root` à l'intérieur d'un conteneur).
-* N'ayez aucun droit pour `group` ou `other`.
-* Ayez au moins le droit d'exécuter **** pour le propriétaire.
+* Appartenir au même utilisateur que celui exécutant l'Agent (`dd-agent` par défaut, ou `root` dans un conteneur).
+* Ne disposer d'aucun droit pour `group` ou `other`.
+* Avoir au moins le droit **d'exécution** pour le propriétaire.
{{% /tab %}}
{{% tab "Windows" %}}
Sur Windows, votre exécutable doit :
-* Ayez **des droits de lecture** ou **d'exécution** pour `ddagentuser` (l'utilisateur utilisé pour exécuter l'Agent).
-* N'ayez aucun droit pour aucun utilisateur ou groupe, sauf pour le groupe **Administrateurs**, le compte intégré **Système local**, ou le contexte utilisateur de l'Agent (`ddagentuser` par défaut).
-* Soyez une application Win32 valide afin que l'Agent puisse l'exécuter (par exemple, un script PowerShell ou Python ne fonctionne pas).
+* Avoir les droits **de lecture** ou **d'exécution** pour `ddagentuser` (l'utilisateur utilisé pour exécuter l'Agent).
+* Ne disposer d'aucun droit pour tout utilisateur ou groupe, à l'exception du groupe **Administrators**, du compte intégré **Local System** ou du contexte utilisateur de l'Agent (`ddagentuser` par défaut).
+* Être une application Win32 valide afin que l'Agent puisse l'exécuter (par exemple, un script PowerShell ou Python ne fonctionne pas).
{{% /tab %}}
{{< /tabs >}}
**Remarque** : Votre exécutable partage les mêmes variables d'environnement que l'Agent.
-## Rafraîchissez les secrets à l'exécution {#refreshing-secrets-at-runtime}
+## Actualisation des secrets au moment de l'exécution {#refreshing-secrets-at-runtime}
-À partir de la version 7.67 de l'Agent, vous pouvez configurer l'Agent pour rafraîchir les secrets résolus sans nécessiter un redémarrage.
+*Disponible dans la version 7.67+ de l'Agent*
-Définir un intervalle de rafraîchissement :
+Vous pouvez configurer l'Agent pour actualiser les secrets résolus sans nécessiter de redémarrage.
+
+Définissez un intervalle d'actualisation :
```yaml
secret_refresh_interval: 3600 # refresh every hour
```
-Ou déclenchez un rafraîchissement manuellement :
+Ou déclenchez une actualisation manuellement :
```shell
datadog-agent secret refresh
```
-### Rafraîchissement de la clé API/APP {#apiapp-key-refresh}
-Les clés API/APP extraites en tant que secrets prennent en charge le rafraîchissement à l'exécution.
+### Actualisation de la clé API/APP {#apiapp-key-refresh}
+Les clés API/APP récupérées en tant que secrets prennent en charge l'actualisation au moment de l'exécution.
-Vous pouvez activer cela en définissant `secret_refresh_interval` (en secondes) dans `datadog.yaml` :
+Vous pouvez activer cette fonctionnalité en définissant `secret_refresh_interval` (en secondes) dans `datadog.yaml` :
```yaml
api_key: ENC[]
@@ -1333,12 +1939,12 @@ api_key: ENC[]
secret_refresh_interval: 3600 # refresh every hour
```
-Par défaut, l'Agent randomise le rafraîchissement initial dans la fenêtre `secret_refresh_interval` pour éviter qu'une flotte de
-Les Agents ne se rafraîchissent pas simultanément. La clé est résolue au démarrage, puis rafraîchie une fois dans le premier intervalle
+Par défaut, l'Agent randomise l'actualisation initiale dans la fenêtre `secret_refresh_interval` pour empêcher un parc de
+afin que les Agents ne s'actualisent pas simultanément. La clé est résolue au démarrage, puis actualisée une fois au cours du premier intervalle
et à chaque intervalle par la suite.
-Pour éviter les temps d'arrêt, invalidez les anciennes clés uniquement après que votre flotte entière a récupéré les clés mises à jour. Vous pouvez suivre l'utilisation des clés
-sur la page [Gestion de la flotte](https://app.datadoghq.com/fleet).
+Pour éviter tout downtime, n'invalidez les anciennes clés qu'une fois que l'ensemble de votre parc a récupéré les clés mises à jour. Vous pouvez suivre l'utilisation
+des clés sur la page [Gestion du parc](https://app.datadoghq.com/fleet).
Vous pouvez désactiver ce comportement en définissant :
@@ -1346,8 +1952,10 @@ Vous pouvez désactiver ce comportement en définissant :
secret_refresh_scatter: false
```
-### Vérification de l'autodécouverte des secrets {#autodiscovery-check-secrets-refresh}
-À partir de l'Agent v7.76, les vérifications programmées [Autodécouverte][1] peuvent actualiser les secrets en temps réel si le modèle utilise la syntaxe `ENC[]`.
+### Actualisation des secrets lors du check Autodiscovery {#autodiscovery-check-secrets-refresh}
+*Disponible dans la version 7.76+ de l'Agent*
+
+Les checks [Autodiscovery][1] planifiés peuvent actualiser les secrets au moment de l'exécution si le modèle utilise la syntaxe `ENC[]`.
```yaml
labels:
@@ -1372,13 +1980,15 @@ annotations:
L'Agent peut alors déclencher l'actualisation des secrets soit à l'intervalle défini dans `secret_refresh_interval`, soit manuellement avec `datadog-agent secret refresh`.
-### Actualisation automatique des secrets en cas d'échec / d'invalidation de la clé API {#automatic-secrets-refresh-on-api-key-failure-invalidation}
+### Actualisation automatique des secrets en cas d'échec / d'invalidation de la clé d'API {#automatic-secrets-refresh-on-api-key-failure-invalidation}
+
+*Disponible dans la version 7.74+ de l'Agent*
-À partir de la version v7.74 de l'Agent, l'Agent peut actualiser automatiquement les secrets lorsqu'il détecte une clé API invalide. Cela se produit lorsque l'Agent reçoit une réponse 403 Interdit de Datadog ou lorsque la vérification de santé périodique détecte une clé API invalide ou expirée.
+L'Agent peut automatiquement rafraîchir les secrets lorsqu'il détecte une clé d'API invalide. Cela se produit lorsque l'Agent reçoit une réponse 403 Forbidden de Datadog ou lorsque le check périodique de l'état détecte une clé d'API invalide ou expirée.
Pour activer cette fonctionnalité, définissez `secret_refresh_on_api_key_failure_interval` sur un intervalle en minutes dans votre fichier `datadog.yaml`. Définissez sur `0` pour désactiver (par défaut).
-Cet intervalle est le temps minimum entre 2 actualisations pour éviter de saturer votre solution de gestion des secrets lorsqu'une clé API invalide est détectée.
+Cet intervalle est la durée minimale entre 2 rafraîchissements pour éviter de spammer votre solution de gestion des secrets lorsqu'une clé d'API invalide est détectée.
```yaml
api_key: ENC[]
@@ -1388,8 +1998,8 @@ secret_refresh_on_api_key_failure_interval: 10
Ce paramètre est compatible avec `secret_refresh_interval`.
-### Activation de l'actualisation du collecteur DDOT {#enabling-ddot-collector-refresh}
-Si vous utilisez le [collecteur DDOT][6] et souhaitez activer l'actualisation API/APP, vous devez ajouter la configuration supplémentaire suivante à votre fichier `datadog.yaml` :
+### Activer le rafraîchissement du collecteur DDOT{#enabling-ddot-collector-refresh}
+Si vous utilisez le [collecteur DDOT][6] et souhaitez activer le rafraîchissement API/APP, vous devez ajouter la configuration supplémentaire suivante à votre fichier `datadog.yaml` :
```
agent_ipc:
@@ -1397,15 +2007,15 @@ agent_ipc:
config_refresh_interval: 3600
```
-Cela garantit que le collecteur DDOT reste synchronisé avec l'Agent après l'actualisation des secrets. De la même manière que l'Agent vérifie périodiquement son état de configuration, le collecteur DDOT utilise ce paramètre pour vérifier régulièrement les valeurs mises à jour de l'Agent.
+Cela garantit que le collecteur DDOT reste synchronisé avec l'Agent après le rafraîchissement des secrets. Tout comme l'Agent vérifie périodiquement l'état de sa configuration, le collecteur DDOT utilise ce paramètre pour vérifier régulièrement les valeurs mises à jour provenant de l'Agent.
## Dépannage {#troubleshooting}
-### Liste des secrets détectés {#listing-detected-secrets}
+### Lister les secrets détectés {#listing-detected-secrets}
-La commande `secret` dans l'Agent CLI affiche toutes les erreurs liées à votre configuration. Par exemple, si les droits sur l'exécutable sont incorrects. Elle affiche également tous les handles trouvés et leur emplacement.
+La commande `secret` dans l'interface de ligne de commande de l'Agent affiche toutes les erreurs liées à votre configuration. Par exemple, si les droits sur l'exécutable sont incorrects. La commande affiche également tous les descripteurs trouvés et leur emplacement.
-Sur Linux, la commande affiche le mode de fichier, le propriétaire et le groupe pour l'exécutable. Sur Windows, les droits ACL sont listés.
+Sous Linux, la commande affiche le mode de fichier, le propriétaire et le groupe de l'exécutable. Sous Windows, les droits ACL sont listés.
{{< tabs >}}
{{% tab "Linux" %}}
@@ -1467,9 +2077,9 @@ Secrets handle decrypted:
{{% /tab %}}
{{< /tabs >}}
-### Voir les configurations après l'injection des secrets {#seeing-configurations-after-secrets-were-injected}
+### Voir les configurations après l'injection des secrets{#seeing-configurations-after-secrets-were-injected}
-Pour voir rapidement comment les configurations de la vérification sont résolues, vous pouvez utiliser la commande `configcheck` :
+Pour voir rapidement comment les configurations de check sont résolues, vous pouvez utiliser la commande `configcheck` :
```shell
sudo -u dd-agent -- datadog-agent configcheck
@@ -1493,7 +2103,7 @@ password:
===
```
-**Remarque** : L'Agent doit être [redémarré][7] pour prendre en compte les modifications des fichiers de configuration.
+**Remarque** : L'Agent doit être [redémarré][7] pour prendre en compte les modifications apportées aux fichiers de configuration.
### Débogage de votre secret_backend_command {#debugging-your-secret-backend-command}
@@ -1507,7 +2117,7 @@ Pour tester une commande ou la déboguer en dehors de l'Agent, vous pouvez repro
sudo -u dd-agent bash -c "echo '{\"version\": \"1.0\", \"secrets\": [\"secret1\", \"secret2\"]}' | /path/to/the/secret_backend_command"
```
-L'utilisateur `dd-agent` est créé lorsque vous installez l'Agent Datadog.
+L'utilisateur `dd-agent` est créé lors de l'installation du Datadog Agent.
{{% /tab %}}
{{% tab "Windows" %}}
@@ -1516,22 +2126,22 @@ L'utilisateur `dd-agent` est créé lorsque vous installez l'Agent Datadog.
Les erreurs suivantes indiquent qu'il manque quelque chose dans votre configuration.
-1. Si un autre groupe ou utilisateur que celui requis a des droits sur l'exécutable, une erreur similaire à la suivante est enregistrée :
+1. Si un groupe ou un utilisateur autre que celui requis dispose de droits sur l'exécutable, une erreur similaire à la suivante est consignée :
```
error while decrypting secrets in an instance: Invalid executable 'C:\decrypt.exe': other users/groups than LOCAL_SYSTEM, Administrators or ddagentuser have rights on it
```
-2. Si `ddagentuser` n'a pas le droit de lecture et d'exécution sur le fichier, une erreur similaire est enregistrée :
+2. Si `ddagentuser` ne dispose pas des droits de lecture et d'exécution sur le fichier, une erreur similaire est consignée :
```
error while decrypting secrets in an instance: could not query ACLs for C:\decrypt.exe
```
-3. Votre exécutable doit être une application Win32 valide. Sinon, l'erreur suivante est enregistrée :
+3. Votre exécutable doit être une application Win32 valide. Si ce n'est pas le cas, l'erreur suivante est consignée :
```
error while running 'C:\decrypt.py': fork/exec C:\decrypt.py: %1 is not a valid Win32 application.
```
-Datadog dispose d'un [script Powershell][9] pour vous aider à définir les bonnes permissions sur votre exécutable. Exemple d'utilisation :
+Datadog propose un [script Powershell][9] pour vous aider à définir les autorisations correctes sur votre exécutable. Exemple d'utilisation :
```powershell
.\Set-SecretPermissions.ps1 -SecretBinaryPath C:\secrets\decrypt_secrets.exe
@@ -1560,23 +2170,23 @@ Number of secrets resolved: 0
Secrets handle resolved:
```
-##### Tester votre exécutable {#testing-your-executable}
+##### Test de votre exécutable {#testing-your-executable}
-Votre exécutable est exécuté par l'Agent lors de la récupération de vos secrets. L'Agent Datadog fonctionne en utilisant le `ddagentuser`. Cet utilisateur n'a pas de droits spécifiques, mais il fait partie du groupe `Performance Monitor Users`. Le mot de passe de cet utilisateur est généré aléatoirement au moment de l'installation et n'est jamais enregistré nulle part.
+Votre exécutable est lancé par l'Agent lors de la récupération de vos secrets. Le Datadog Agent s'exécute en utilisant le `ddagentuser`. Cet utilisateur ne dispose d'aucun droit spécifique, mais il fait partie du groupe `Performance Monitor Users`. Le mot de passe de cet utilisateur est généré de manière aléatoire lors de l'installation et n'est jamais enregistré nulle part.
-Cela signifie que votre exécutable peut fonctionner avec votre utilisateur par défaut ou utilisateur de développement, mais pas lorsqu'il est exécuté par l'Agent, car `ddagentuser` a des droits plus restreints.
+Cela signifie que votre exécutable peut fonctionner avec votre utilisateur par défaut ou votre utilisateur de développement, mais pas lorsqu'il est exécuté par l'Agent, car `ddagentuser` dispose de droits plus restreints.
-Pour tester votre exécutable dans les mêmes conditions que l'Agent, mettez à jour le mot de passe du `ddagentuser` sur votre machine de développement. De cette façon, vous pouvez vous authentifier en tant que `ddagentuser` et exécuter votre exécutable dans le même contexte que l'Agent.
+Pour tester votre exécutable dans les mêmes conditions que l'Agent, mettez à jour le mot de passe du `ddagentuser` sur votre machine de développement. De cette façon, vous pouvez vous authentifier en tant que `ddagentuser` et exécuter votre exécutable dans le même contexte que celui de l'Agent.
Pour ce faire, suivez ces étapes :
-1. Retirez `ddagentuser` de la liste `Local Policies/User Rights Assignement/Deny Log on locally` dans le `Local Security Policy`.
-2. Définissez un nouveau mot de passe pour `ddagentuser` (puisque celui généré lors de l'installation n'est jamais enregistré nulle part). Dans PowerShell, exécutez :
+1. Supprimez `ddagentuser` de la liste `Local Policies/User Rights Assignement/Deny Log on locally` dans le `Local Security Policy`.
+2. Définissez un nouveau mot de passe pour `ddagentuser` (car celui généré lors de l'installation n'est jamais enregistré nulle part). Dans PowerShell, exécutez :
```powershell
$user = [ADSI]"WinNT://./ddagentuser";
$user.SetPassword("a_new_password")
```
-3. Mettez à jour le mot de passe à utiliser par le service `DatadogAgent` dans le Gestionnaire de contrôle des services. Dans PowerShell, exécutez :
+3. Mettez à jour le mot de passe à utiliser par le service `DatadogAgent` dans le Gestionnaire de contrôle des services. Dans PowerShell, exécutez :
```powershell
sc.exe config DatadogAgent password= "a_new_password"
```
@@ -1606,21 +2216,21 @@ exit code:
### L'Agent refuse de démarrer {#agent-refusing-to-start}
-La première chose que fait l'Agent au démarrage est de charger `datadog.yaml` et de déchiffrer tous les secrets qu'il contient. Cela se fait avant la configuration de la journalisation. Cela signifie que sur des plateformes comme Windows, les erreurs survenant lors du chargement de `datadog.yaml` ne sont pas écrites dans les journaux, mais sur `stderr`. Cela peut se produire lorsque l'exécutable donné à l'Agent pour les secrets renvoie une erreur.
+La première chose que fait l'Agent au démarrage est de charger `datadog.yaml` et de déchiffrer tous les secrets qu'il contient. Cela est effectué avant la configuration de la journalisation. Cela signifie que sur des plateformes comme Windows, les erreurs survenant lors du chargement de `datadog.yaml` ne sont pas écrites dans les logs, mais sur `stderr`. Cela peut se produire lorsque l'exécutable fourni à l'Agent pour les secrets renvoie une erreur.
Si vous avez des secrets dans `datadog.yaml` et que l'Agent refuse de démarrer :
* Essayez de démarrer l'Agent manuellement pour pouvoir voir `stderr`.
-* Retirez les secrets de `datadog.yaml` et testez d'abord avec des secrets dans un fichier de configuration de vérification.
+* Supprimez les secrets de `datadog.yaml` et testez d'abord avec des secrets dans un fichier de configuration de check.
### Test des autorisations Kubernetes {#testing-kubernetes-permissions}
-Lorsque vous lisez des secrets directement depuis Kubernetes, vous pouvez vérifier vos autorisations avec la commande `kubectl auth`. La forme générale de ceci est :
+Lors de la lecture directe des secrets depuis Kubernetes, vous pouvez vérifier vos autorisations avec la commande `kubectl auth`. La forme générale de ceci est :
```
kubectl auth can-i get secret/ -n --as system:serviceaccount::
```
-Considérez l'exemple précédent [Kubernetes Secrets](#example-reading-a-kubernetes-secret-across-namespaces), où le Secret `Secret:database-secret` existe dans le `Namespace: database`, et le compte de service `ServiceAccount:datadog-agent` existe dans le `Namespace: default`.
+Considérez l'exemple précédent de [Secrets Kubernetes](#example-reading-a-kubernetes-secret-across-namespaces), où le Secret `Secret:database-secret` existe dans le `Namespace: database`, et le Compte de service `ServiceAccount:datadog-agent` existe dans le `Namespace: default`.
Pour cet exemple, utilisez la commande suivante :
@@ -1630,13 +2240,13 @@ kubectl auth can-i get secret/database-secret -n database --as system:serviceacc
Cette commande indique si l'Agent dispose des autorisations adéquates pour accéder à ce secret.
-### Supprimer les sauts de ligne finaux {#remove-trailing-line-breaks}
+### Supprimer les sauts de ligne de fin {#remove-trailing-line-breaks}
-Certains outils de gestion des secrets ajoutent automatiquement un saut de ligne lors de l'exportation des secrets via des fichiers. Vous pouvez supprimer ces sauts de ligne en définissant `secret_backend_remove_trailing_line_break: true` dans le fichier de configuration [datadog.yaml][8], ou utiliser la variable d'environnement `DD_SECRET_BACKEND_REMOVE_TRAILING_LINE_BREAK` pour faire de même, en particulier dans des environnements conteneurisés.
+Certains outils de gestion des secrets ajoutent automatiquement un saut de ligne lors de l'exportation de secrets via des fichiers. Vous pouvez supprimer ces sauts de ligne en définissant `secret_backend_remove_trailing_line_break: true` dans [le fichier de configuration datadog.yaml][8], ou utiliser la variable d'environnement `DD_SECRET_BACKEND_REMOVE_TRAILING_LINE_BREAK` pour faire de même, en particulier dans les environnements conteneurisés.
-### Variables d'autodécouverte dans les gestionnaires de secrets {#autodiscovery-variables-in-secret-handles}
+### Variables d'Autodiscovery dans secret handles {#autodiscovery-variables-in-secret-handles}
-Il est également possible d'utiliser des variables [Autodécouverte][1] dans les gestionnaires de secrets. L'Agent résout ces variables avant de résoudre le secret. Exemple :
+Il est également possible d'utiliser des variables [Autodiscovery][1] dans secret handles. L'Agent résout ces variables avant de résoudre le secret. Exemple :
```
instances:
@@ -1645,7 +2255,7 @@ instances:
password: ENC[db_prod_password_%%host%%]
```
-## Lectures complémentaires {#further-reading}
+## Pour aller plus loin {#further-reading}
{{< partial name="whats-next/whats-next.html" >}}
@@ -1660,9 +2270,11 @@ instances:
[1000]: https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html
[1001]: https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html
[1006]: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html
+[1007]: https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html
[2000]: https://docs.microsoft.com/en-us/Azure/key-vault/secrets/quick-create-portal
+[2001]: https://learn.microsoft.com/en-us/azure/developer/go/azure-sdk-authentication
[3000]: https://learn.hashicorp.com/tutorials/vault/static-secrets
diff --git a/hugo/content/fr/ai_agents_console/_index.md b/hugo/content/fr/ai_agents_console/_index.md
index d4bb965639b..76fa2564fd7 100644
--- a/hugo/content/fr/ai_agents_console/_index.md
+++ b/hugo/content/fr/ai_agents_console/_index.md
@@ -1,14 +1,13 @@
---
-description: Surveillez et analysez l'utilisation, le coût et la performance des agents
- de codage et des Bits AI agents au sein de votre organisation via Datadog Agent
- Console.
+description: Surveillez et analysez l'utilisation, le coût et les performances des
+ coding agents et des Bits AI agents dans votre organisation dans Datadog Agent Console.
further_reading:
- link: /ai_agents_console/setup/
tag: Documentation
- text: Configurez Agent Console.
+ text: Configurer Agent Console
- link: /integrations/anthropic-usage-and-costs/
tag: Documentation
- text: Intégration de l'utilisation et des coûts d'Anthropic.
+ text: Intégration de l'utilisation et des coûts d'Anthropic
- link: /integrations/cursor/
tag: Documentation
text: Intégration de Cursor
@@ -16,86 +15,89 @@ further_reading:
tag: Blog
text: Surveillez l'adoption de Claude Code dans votre organisation avec Datadog
Agent Console.
-title: Agent Console.
+- link: https://www.datadoghq.com/blog/datadog-agent-console/
+ tag: Blog
+ text: Surveillez l'adoption des agents avec Datadog Agent Console.
+title: Agent Console
---
-{{< callout url="#" btn_hidden="true" header="Aperçu">}}
-Agent Console est en preview et disponible pour tous les clients de Datadog.
+{{< callout url="#" btn_hidden="true" header="Preview">}}
+Datadog Agent Console est en Preview et disponible pour tous les clients Datadog.
{{< /callout >}}
-L'[Agent Console][1] fournit une surveillance centralisée pour les agents d'IA au sein de votre organisation. Elle collecte des logs et des métriques des coding agents et des [Bits AI agents](#bits-ai-agents) de Datadog, les affichant en temps réel pour offrir une visibilité sur l'utilisation, le coût, la latence, l'impact sur la productivité et les modèles de problèmes émergents.
+La [Agent Console][1] offre une surveillance centralisée des agents IA dans toute votre organisation. Elle collecte les logs et les métriques des agents de codage et des [agents Bits AI](#bits-ai-agents) de Datadog, et les affiche en temps réel pour vous offrir une visibilité sur l'utilisation, le coût, la latence, l'impact sur la productivité et les nouveaux modèles de problèmes.
Agent Console prend en charge les agents de codage suivants :
| Outil | Description |
|------|-------------|
-| [Claude Code][2] | Outil de codage agentic d'Anthropic|
-| [Cursor][3] | Éditeur de code alimenté par l'IA |
-| [GitHub Copilot][4] | Outil de complétion de code alimenté par l'IA de GitHub |
+| [Claude Code][2] | Outil de codage agentique d'Anthropic |
+| [Cursor][3] | Éditeur de code assisté par IA |
+| [GitHub Copilot][4] | Outil de complétion de code assisté par IA de GitHub |
## Agents de codage {#coding-agents}
-L'onglet {{< ui >}}Coding Agents{{< /ui >}} vous donne une vue d'ensemble de l'activité des agents de codage au sein de votre organisation. Par défaut, la vue agrège tous les agents de codage et peut être filtrée pour un seul agent.
+L'onglet {{< ui >}}Coding Agents{{< /ui >}} vous donne une vue d'ensemble de l'activité des agents de codage dans votre organisation. Par défaut, la vue agrège tous les agents de codage et peut être filtrée pour un seul agent.
-{{< img src="/ai_agents_console/agent_console_agent_findings.png" alt="Onglet des agents de codage de la console de l'agent montrant un résumé des résultats des agents avec des métriques et des tendances pour Claude Code, Cursor et GitHub Copilot" style="width:100%;" >}}
+{{< img src="/ai_agents_console/agent_console_agent_findings.png" alt="Onglet Coding Agents dans l'Agent Console affichant un résumé des résultats des agents avec des métriques et des tendances pour Claude Code, Cursor et GitHub Copilot" style="width:100%;" >}}
-### Agent findings {#agent-findings}
+### Résultats des agents {#agent-findings}
-Le {{< ui >}}Agent Findings{{< /ui >}} panneau résume l'activité de haut niveau pour la période sélectionnée, y compris les dépenses totales, le nombre total d'utilisateurs, les sessions, le temps de fusion, les lignes de code et le nombre moyen de tours par session. Le graphique empilé décompose l'activité par agent (par exemple, Claude Code et Cursor) afin que vous puissiez comparer l'adoption au fil du temps.
+Le panneau {{< ui >}}Agent Findings{{< /ui >}} résume l'activité de haut niveau pour la plage horaire sélectionnée, y compris les dépenses totales, le nombre total d'utilisateurs, les sessions, le temps de fusion, les lignes de code et le nombre moyen de tours par session. Le graphique empilé décompose l'activité par agent (par exemple, Claude Code et Cursor) afin que vous puissiez comparer l'adoption au fil du temps.
### Métriques d'impact {#impact-metrics}
-Le {{< ui >}}Impact Metrics{{< /ui >}} panneau mesure l'effet du développement assisté par IA sur votre cycle de livraison de logiciels en utilisant des métriques de style DORA, avec des comparaisons côte à côte entre le travail assisté par IA et le travail non assisté par IA.
+Le panneau {{< ui >}}Impact Metrics{{< /ui >}} mesure l'effet du développement assisté par IA sur votre cycle de vie de livraison de logiciels en utilisant des métriques de type DORA, avec des comparaisons côte à côte entre le travail assisté par IA et le travail non assisté par IA.
-- **Adoption** : suivez la quantité de code produite par l'IA, y compris les commits assistés par IA et les PR assistés par IA.
-- **Vitesse** : mesurez la rapidité avec laquelle les changements parviennent à la production, y compris le délai de mise en production et le temps de révision des PR.
-- **Stabilité** : suivez la fiabilité des changements après leur déploiement, y compris le taux d'échec des changements et le temps de récupération.
+- **Adoption** : suivez la quantité de code produite par l'IA, y compris les commits assistés par IA et les PR assistées par IA.
+- **Vélocité** : mesurez la rapidité avec laquelle les changements atteignent la production, y compris le délai de traitement des changements et le temps de révision des PR.
+- **Stabilité** : suivez la fiabilité des changements après leur publication, y compris le taux d'échec des changements et le temps de récupération.
-### Detected Problems {#detected-problems}
+### Problèmes détectés {#detected-problems}
-Le {{< ui >}}Detected Problems{{< /ui >}} panneau met en évidence les modèles de problèmes courants que votre équipe rencontre et recommande des solutions. Le diagramme de Sankey montre comment les modèles de problèmes (tels que les vérifications sautées, les boucles de réessai et les relises de fichiers) circulent des agents individuels vers des dépôts spécifiques, avec un coût mensuel estimé pour chaque modèle.
+Le panneau {{< ui >}}Detected Problems{{< /ui >}} met en évidence les modèles de problèmes courants rencontrés par votre équipe et recommande des correctifs. Le diagramme de Sankey montre comment les modèles de problèmes (tels que les vérifications ignorées, les boucles de nouvelle tentative et les relectures de fichiers) circulent des agents individuels vers des référentiels spécifiques, avec un coût mensuel estimé pour chaque modèle.
-{{< img src="/ai_agents_console/detected_problems_skipped_checks.png" alt="Diagramme de Sankey des problèmes détectés montrant comment les sessions de Claude Code, Cursor et GitHub Copilot se rapportent aux modèles de problèmes, mettant en évidence les vérifications sautées." style="width:90%;" >}}
+{{< img src="/ai_agents_console/detected_problems_skipped_checks.png" alt="Diagramme de Sankey des problèmes détectés montrant comment les sessions de Claude Code, Cursor et GitHub Copilot correspondent aux modèles de problèmes, en mettant en évidence les vérifications ignorées" style="width:90%;" >}}
-Cliquez sur un nœud {{< ui >}}Problem Pattern{{< /ui >}} pour ouvrir une vue détaillée qui inclut la définition du modèle, le coût mensuel estimé pour votre organisation, une liste de sessions signalées et une solution recommandée.
+Cliquez sur un nœud {{< ui >}}Problem Pattern{{< /ui >}} pour ouvrir une vue détaillée qui inclut la définition du modèle, le coût mensuel estimé pour l'ensemble de votre organisation, une liste des sessions signalées et un correctif recommandé.
### Tableaux de bord des agents individuels {#individual-agent-dashboards}
-L'onglet {{< ui >}}Coding Agents{{< /ui >}} affiche une tuile pour chaque agent de codage connecté (tels que Claude Code, GitHub Copilot et Cursor). Chaque tuile montre un résumé de l'activité de cet agent, y compris le nombre total d'utilisateurs, les dépenses totales et le coût par ligne de code.
+L'onglet {{< ui >}}Coding Agents{{< /ui >}} affiche une vignette pour chaque agent de codage connecté (tels que Claude Code, GitHub Copilot et Cursor). Chaque vignette affiche un résumé de l'activité de cet agent, y compris le nombre total d'utilisateurs, les dépenses totales et le coût par ligne de code.
-{{< img src="/ai_agents_console/coding_agent_dashboard_claude.png" alt="Le tableau de bord de Claude Code affiche des widgets pour les lignes ajoutées, les sessions, les commits et les métriques de performance." style="width:100%;" >}}
+{{< img src="/ai_agents_console/coding_agent_dashboard_claude.png" alt="Le dashboard Claude Code affiche des widgets pour les lignes ajoutées, les sessions, les commits et les métriques de performance" style="width:100%;" >}}
-Cliquez sur une tuile d'agent, ou sélectionnez dans le menu déroulant {{< ui >}}All Coding Agents{{< /ui >}} en haut de la page, pour ouvrir un tableau de bord dédié à cet agent. Le tableau de bord dédié comprend des tuiles de résumé pour les dépenses totales, les sessions, les commits et les lignes ajoutées, ainsi que des graphiques de performance couvrant le volume de demandes, la latence, les modèles d'utilisation, les lignes ajoutées par rapport aux lignes supprimées, et les acceptations par rapport aux rejets des outils.
+Cliquez sur une vignette d'agent, ou sélectionnez dans le menu déroulant {{< ui >}}All Coding Agents{{< /ui >}} en haut de la page, pour ouvrir un dashboard dédié à cet agent. Le dashboard dédié comprend des vignettes récapitulatives pour les dépenses totales, les sessions, les commits et les lignes ajoutées, ainsi que des graphiques de performance couvrant le volume de requêtes, la latence, les modèles d'utilisation, les lignes ajoutées par rapport aux lignes supprimées, et les outils acceptés par rapport aux outils rejetés.
-## Analyser l'utilisation des agents {#analyze-agent-usage}
+## Analyser l'utilisation de l'agent {#analyze-agent-usage}
-L'onglet {{< ui >}}Analytics{{< /ui >}} fournit des détails granulaires pour les individus et les équipes, vous aidant à identifier les utilisateurs experts, les valeurs aberrantes et les modèles d'adoption au niveau de l'équipe.
+L'onglet {{< ui >}}Analytics{{< /ui >}} fournit des détails granulaires pour les individus et les équipes, vous aidant à identifier les utilisateurs intensifs, les valeurs aberrantes et les modèles d'adoption au niveau de l'équipe.
-{{< img src="/ai_agents_console/agent_console_analytics.png" alt="L'onglet Agent Console Analytics affichant des analyses détaillées des utilisateurs et des équipes pour l'utilisation des agents de codage, y compris les classements et les graphiques." style="width:100%;" >}}
+{{< img src="/ai_agents_console/agent_console_analytics.png" alt="L'onglet Agent Console Analytics affiche des analyses détaillées des utilisateurs et des équipes pour l'utilisation des agents de codage, y compris des classements et des graphiques." style="width:100%;" >}}
-### Team Comparison {#team-comparison}
+### Comparaison d'équipe {#team-comparison}
-Le panneau {{< ui >}}Comparison{{< /ui >}} vous aide à identifier les équipes qui investissent trop ou pas assez dans les outils d'IA par rapport à leur production. Comparez les dépenses, le coût par ligne et l'utilisation des modèles entre les équipes et par rapport à la référence de votre organisation pour trouver où des gains d'efficacité sont possibles ou où les coûts sont anormalement élevés.
+Le panneau {{< ui >}}Comparison{{< /ui >}} vous aide à identifier les équipes qui surinvestissent ou sous-investissent dans les outils d'IA par rapport à leur production. Comparez les dépenses, le coût par ligne et l'utilisation des modèles entre les équipes et par rapport à la référence de votre organisation pour trouver où des gains d'efficacité sont possibles ou où les coûts sont anormalement élevés.
-### Analytique des utilisateurs {#user-analytics}
+### User Analytics{#user-analytics}
-{{< img src="/ai_agents_console/user_analytics_user_detail_panel.png" alt="Panneau User Analytics d'Agent Console affichant une répartition détaillée pour un utilisateur sélectionné, y compris les dépenses par agent, le mix de modèles et l'historique des PR." style="width:100%;" >}}
+{{< img src="/ai_agents_console/user_analytics_user_detail_panel.png" alt="Le panneau Agent Console User Analytics affiche une ventilation détaillée pour un utilisateur sélectionné, y compris les dépenses par agent, la combinaison de modèles et l'historique des PR." style="width:100%;" >}}
-Le panneau {{< ui >}}User Analytics{{< /ui >}} vous donne une visibilité sur la manière dont les ingénieurs individuels utilisent les outils d'IA dans votre organisation. Utilisez le panneau pour :
+Le panneau {{< ui >}}User Analytics{{< /ui >}} vous donne une visibilité sur la façon dont les ingénieurs individuels utilisent les outils d'IA dans votre organisation. Utilisez le panneau pour :
- Identifier vos plus gros dépensiers et vos contributeurs les plus productifs
-- Repérez les valeurs aberrantes en termes d'efficacité — ingénieurs avec des dépenses élevées mais une faible production, ou inversement.
-- Voir une répartition complète des coûts par utilisateur, agent et modèle
-- Examinez les dépenses, l'historique des PR et le mix de modèles de chaque individu.
+- Repérer les écarts d'efficacité — les ingénieurs avec des dépenses élevées mais une faible production, ou vice versa
+- Voir une ventilation complète des coûts par utilisateur, agent et modèle
+- Examiner les dépenses, l'historique des PR et la combinaison de modèles pour chaque individu.
-## Bits AI agents {#bits-ai-agents}
+## Bits AI agents{#bits-ai-agents}
-{{< img src="/ai_agents_console/bits_ai_agents.png" alt="Onglet Bits AI Agents affichant un graphique d'activité combiné au fil du temps et des cartes individuelles pour Bits Investigation, Bits Code et Bits Agent Builder, montrant les enquêtes, sessions et exécutions récentes." style="width:100%;" >}}
+{{< img src="/ai_agents_console/bits_ai_agents.png" alt="Onglet Bits AI Agents avec un graphique combiné de l'activité des agents au fil du temps et des cartes individuelles pour Bits Investigation, Bits Code et Bits Agent Builder montrant les enquêtes, les sessions et les exécutions récentes." style="width:100%;" >}}
-L'onglet {{< ui >}}Bits AI Agents{{< /ui >}} montre l'utilisation des AI agents intégrés de Datadog aux côtés de vos agents de codage. La vue combinée des enquêtes, sessions et exécutions à travers tous les agents Datadog vous permet de corréler l'activité AI Bits avec le reste de votre organisation.
+L'onglet {{< ui >}}Bits AI Agents{{< /ui >}} montre l'utilisation des built-in AI agents de Datadog parallèlement à vos agents de codage. La vue combinée des enquêtes, sessions et exécutions sur tous les agents Datadog vous permet de corréler l'activité de Bits AI avec le reste de votre organisation.
-Des cartes individuelles résument l'activité de chaque Bits AI agent, y compris [Bits Investigation][5], [Bits Code][6] et [Bits Agent Builder][7]. Cliquez sur {{< ui >}}View Details{{< /ui >}} une carte pour examiner cet agent.
+Des cartes individuelles résument l'activité pour chaque agent Bits AI, y compris [Bits Investigation][5], [Bits Code][6] et [Bits Agent Builder][7]. Cliquez sur {{< ui >}}View Details{{< /ui >}} sur une carte pour examiner cet agent.
-## Configurez {#set-up}
+## Set Up{#set-up}
Pour commencer à envoyer des données à Agent Console, consultez [Set Up Agent Console][8].
@@ -107,7 +109,7 @@ Pour commencer à envoyer des données à Agent Console, consultez [Set Up Agent
[2]: https://docs.claude.com/en/docs/claude-code/overview
[3]: https://www.cursor.com/
[4]: /fr/integrations/github-copilot/
-[5]: /fr/bits_ai/bits_ai_sre/
-[6]: /fr/bits_ai/bits_ai_dev_agent/
+[5]: /fr/bits_ai/bits_investigation/
+[6]: /fr/bits_ai/bits_code/
[7]: /fr/actions/agents/
[8]: /fr/ai_agents_console/setup/
\ No newline at end of file
diff --git a/hugo/content/fr/api/latest/agent-observability/search-agent-observability-experimentation/index.md b/hugo/content/fr/api/latest/agent-observability/search-agent-observability-experimentation/index.md
new file mode 100644
index 00000000000..d41f60ab1e2
--- /dev/null
+++ b/hugo/content/fr/api/latest/agent-observability/search-agent-observability-experimentation/index.md
@@ -0,0 +1,3 @@
+---
+title: Rechercher une expérimentation Agent Observability
+---
diff --git a/hugo/content/fr/api/latest/agent-observability/search-agent-observability-spans/index.md b/hugo/content/fr/api/latest/agent-observability/search-agent-observability-spans/index.md
new file mode 100644
index 00000000000..a2cf00c28a2
--- /dev/null
+++ b/hugo/content/fr/api/latest/agent-observability/search-agent-observability-spans/index.md
@@ -0,0 +1,3 @@
+---
+title: Rechercher des spans d'Agent Observability
+---
diff --git a/hugo/content/fr/api/latest/elastic-cloud-integration-accounts/list-elastic-cloud-integration-accounts/index.md b/hugo/content/fr/api/latest/elastic-cloud-integration-accounts/list-elastic-cloud-integration-accounts/index.md
new file mode 100644
index 00000000000..640f219c385
--- /dev/null
+++ b/hugo/content/fr/api/latest/elastic-cloud-integration-accounts/list-elastic-cloud-integration-accounts/index.md
@@ -0,0 +1,3 @@
+---
+title: Lister les comptes d'intégration Elastic Cloud
+---
diff --git a/hugo/content/fr/api/latest/llm-observability/create-an-agent-observability-prompt/index.md b/hugo/content/fr/api/latest/llm-observability/create-an-agent-observability-prompt/index.md
new file mode 100644
index 00000000000..3e1a75dc5ff
--- /dev/null
+++ b/hugo/content/fr/api/latest/llm-observability/create-an-agent-observability-prompt/index.md
@@ -0,0 +1,3 @@
+---
+title: Créez un prompt Agent Observability.
+---
diff --git a/hugo/content/fr/api/latest/llm-observability/push-events-for-an-agent-observability-experiment/index.md b/hugo/content/fr/api/latest/llm-observability/push-events-for-an-agent-observability-experiment/index.md
new file mode 100644
index 00000000000..ca0bddc343d
--- /dev/null
+++ b/hugo/content/fr/api/latest/llm-observability/push-events-for-an-agent-observability-experiment/index.md
@@ -0,0 +1,3 @@
+---
+title: Envoyer des événements pour une expérience Agent Observability
+---
diff --git a/hugo/content/fr/api/latest/llm-observability/restore-an-agent-observability-dataset-version/index.md b/hugo/content/fr/api/latest/llm-observability/restore-an-agent-observability-dataset-version/index.md
new file mode 100644
index 00000000000..b191eab710a
--- /dev/null
+++ b/hugo/content/fr/api/latest/llm-observability/restore-an-agent-observability-dataset-version/index.md
@@ -0,0 +1,3 @@
+---
+title: Restaurer une version du jeu de données Agent Observability
+---
diff --git a/hugo/content/fr/api/latest/product-analytics/compute-journey-funnel-analysis/index.md b/hugo/content/fr/api/latest/product-analytics/compute-journey-funnel-analysis/index.md
new file mode 100644
index 00000000000..97c4513156f
--- /dev/null
+++ b/hugo/content/fr/api/latest/product-analytics/compute-journey-funnel-analysis/index.md
@@ -0,0 +1,3 @@
+---
+title: Effectuer une analyse de l'entonnoir du parcours
+---
diff --git a/hugo/content/fr/api/latest/rum-retention-filters/get-all-rum-exclusion-filters/index.md b/hugo/content/fr/api/latest/rum-retention-filters/get-all-rum-exclusion-filters/index.md
new file mode 100644
index 00000000000..35b2a939ea0
--- /dev/null
+++ b/hugo/content/fr/api/latest/rum-retention-filters/get-all-rum-exclusion-filters/index.md
@@ -0,0 +1,3 @@
+---
+title: Récupérer tous les filtres d'exclusion RUM
+---
diff --git a/hugo/content/fr/api/latest/rum-retention-quotas/create-or-update-a-rum-retention-quota-config/index.md b/hugo/content/fr/api/latest/rum-retention-quotas/create-or-update-a-rum-retention-quota-config/index.md
new file mode 100644
index 00000000000..7890784571e
--- /dev/null
+++ b/hugo/content/fr/api/latest/rum-retention-quotas/create-or-update-a-rum-retention-quota-config/index.md
@@ -0,0 +1,3 @@
+---
+title: Créez ou mettez à jour une configuration de quota de rétention RUM
+---
diff --git a/hugo/content/fr/api/latest/rum-retention-quotas/delete-a-rum-retention-quota-configuration/index.md b/hugo/content/fr/api/latest/rum-retention-quotas/delete-a-rum-retention-quota-configuration/index.md
new file mode 100644
index 00000000000..c2a0995e3f9
--- /dev/null
+++ b/hugo/content/fr/api/latest/rum-retention-quotas/delete-a-rum-retention-quota-configuration/index.md
@@ -0,0 +1,3 @@
+---
+title: Supprimez une configuration de quota de rétention RUM
+---
diff --git a/hugo/content/fr/api/latest/security-monitoring/update-a-severity-modifier-rule/index.md b/hugo/content/fr/api/latest/security-monitoring/update-a-severity-modifier-rule/index.md
new file mode 100644
index 00000000000..e36b1efd3ba
--- /dev/null
+++ b/hugo/content/fr/api/latest/security-monitoring/update-a-severity-modifier-rule/index.md
@@ -0,0 +1,3 @@
+---
+title: Mettre à jour une règle de modification de la gravité
+---
diff --git a/hugo/content/fr/api/latest/twilio-integration-accounts/_index.md b/hugo/content/fr/api/latest/twilio-integration-accounts/_index.md
new file mode 100644
index 00000000000..e5a3a91b2a8
--- /dev/null
+++ b/hugo/content/fr/api/latest/twilio-integration-accounts/_index.md
@@ -0,0 +1,3 @@
+---
+title: Comptes d'intégration Twilio
+---
diff --git a/hugo/content/fr/api/latest/twilio-integration-accounts/create-a-twilio-integration-account/index.md b/hugo/content/fr/api/latest/twilio-integration-accounts/create-a-twilio-integration-account/index.md
new file mode 100644
index 00000000000..bea3a8c6337
--- /dev/null
+++ b/hugo/content/fr/api/latest/twilio-integration-accounts/create-a-twilio-integration-account/index.md
@@ -0,0 +1,3 @@
+---
+title: Créez un compte d'intégration Twilio
+---
diff --git a/hugo/content/fr/containers/cluster_agent/_index.md b/hugo/content/fr/containers/cluster_agent/_index.md
index 97a0b93bcfb..0d051c83407 100644
--- a/hugo/content/fr/containers/cluster_agent/_index.md
+++ b/hugo/content/fr/containers/cluster_agent/_index.md
@@ -4,64 +4,67 @@ aliases:
- /fr/agent/cluster_agent/
- /fr/containers/cluster_agent/event_collection
- /fr/containers/cluster_agent/metadata_provider
-description: Approche centralisée de la collecte des données de surveillance au niveau
- du cluster avec l'Agent de cluster de Datadog
+description: Approche centralisée de collecte des données de surveillance au niveau
+ du cluster avec le Datadog Cluster Agent
further_reading:
- link: https://www.datadoghq.com/blog/datadog-cluster-agent/
tag: Blog
text: Présentation de l'Agent de cluster Datadog
- link: https://www.datadoghq.com/blog/autoscale-kubernetes-datadog/
tag: Blog
- text: Mettre à l'échelle vos charges de travail Kubernetes en fonction d'une métrique
- Datadog
+ text: Mettre à l'échelle vos charges de travail Kubernetes avec n'importe quelle
+ métrique Datadog
- link: https://www.datadoghq.com/blog/datadog-csi-driver/
tag: Blog
- text: Apporter une observabilité haute performance aux environnements Kubernetes
- sécurisés avec le driver CSI Datadog
+ text: Apportez une observabilité haute performance aux environnements Kubernetes
+ sécurisés avec le pilote CSI de Datadog
+- link: https://www.datadoghq.com/architecture/efficient-kubernetes-monitoring-with-the-datadog-cluster-agent/
+ tag: Centre d'architecture
+ text: Surveillance efficace de Kubernetes avec le Datadog Cluster Agent
+- link: https://www.datadoghq.com/architecture/real-world-applications-of-the-datadog-cluster-agent-part-one/
+ tag: Centre d'architecture
+ text: Applications concrètes du Datadog Cluster Agent (Partie 1)
title: Agent de cluster pour Kubernetes
---
+## Présentation {#overview}
-## Présentation
-
-L'Agent de cluster Datadog fournit une méthode simplifiée et centralisée de collecte des données de surveillance au niveau des clusters. En agissant comme un proxy entre le serveur d'API et les Agents basés sur des nœuds, l'Agent de cluster permet de réduire la charge du serveur. Il transmet également les métadonnées de cluster aux Agents de nœud afin d'enrichir les métadonnées des métriques recueillies localement.
+Le Datadog Cluster Agent offre une approche rationalisée et centralisée pour collecter les données de surveillance au niveau du cluster. En agissant comme un proxy entre le serveur API et les agents basés sur les nœuds, le Cluster Agent aide à alléger la charge du serveur. Il relaie également les métadonnées au niveau du cluster aux agents basés sur les nœuds, leur permettant d'enrichir les métadonnées des métriques collectées localement.
Grâce à l'Agent de cluster Datadog, vous pouvez :
-* atténuer l'incidence des Agents sur votre infrastructure ;
-* isoler les Agents de nœud dans leurs nœuds respectifs, afin de limiter les règles RBAC à la lecture des métriques et des métadonnées du kubelet ;
-* transmettre les métadonnées de cluster qui se trouvent dans le serveur d'API aux Agents de nœud, de façon à enrichir les métadonnées des métriques recueillies localement ;
-* activer la collecte de données au niveau du cluster, telles que les données de surveillance de services, les SPOF et les événements ;
-* Utilisez l'autoscaling de pods horizontaux en vous basant sur des métriques Kubernetes personnalisées et des métriques externes. Consultez la section [Autoscaling avec des métriques custom et externes de l'Agent de cluster][1] pour en savoir plus.
+* Réduisez l'impact des agents sur votre infrastructure.
+* Isolez les agents basés sur les nœuds sur leurs nœuds respectifs, en réduisant les règles RBAC à la simple lecture des métriques et des métadonnées depuis le kubelet.
+* Fournissez aux agents de nœud les métadonnées au niveau du cluster qui ne peuvent être trouvées que dans le serveur API, afin qu'ils puissent enrichir les métadonnées des métriques collectées localement.
+* Activez la collecte de données au niveau du cluster, comme la surveillance des services ou des points de défaillance uniques (SPOF) et des événements.
+* Utilisez le dimensionnement automatique horizontal des pods (HPA) avec des métriques Kubernetes personnalisées et des métriques externes. Consultez le [guide sur le dimensionnement automatique basé sur des métriques personnalisées et externes][1] pour plus de détails.
-Si vous avez installé l'Agent Datadog à l'aide du chart Helm v2.7.0 ou de l'Operator Datadog v.1.0.0+, l'**Agent de cluster Datadog est activé par défaut**.
+Si vous avez installé le Datadog Agent à l'aide du chart Helm v2.7.0 ou du Datadog Operator v1.0.0+, le **Datadog Cluster Agent est activé par défaut**.
-Datadog publie des images de conteneur sur Google Artifact Registry, Amazon ECR, Azure ACR et Docker Hub :
+Datadog publie des images de conteneur sur le Datadog Container Registry, Google Artifact Registry (GAR), Amazon ECR, Azure ACR et Docker Hub :
-| Google Artifact Registry | Amazon ECR | Azure ACR | Docker Hub |
-| ------------------------ | ---------------------- | -------------------- | ----------------- |
-| gcr.io/datadoghq | public.ecr.aws/datadog | datadoghq.azurecr.io | docker.io/datadog |
+{{% container-images-table %}}
-Par défaut, l'image de l'Agent de cluster est extraite de Google Artifact Registry ('gcr.io/datadoghq'). Si Artifact Registry n'est pas accessible dans votre région de déploiement, utilisez un autre registre.
+Par défaut, le chart Helm du Datadog Agent détermine le registre d'images de l'Agent à partir de votre site Datadog, du type de cluster et de `registryMigrationMode`. Selon ces valeurs et les exclusions d'environnement, les images de l'Agent peuvent être extraites du Datadog Container Registry (`registry.datadoghq.com`) ou d'un registre spécifique au site. Le chart Datadog Operator est inclus par défaut en tant que dépendance du chart Helm du Datadog Agent. À partir de la version 2.19.0 du chart Datadog Operator, lorsque vous installez l'Operator via cette dépendance, le `registryMigrationMode` du chart Helm du Datadog Agent s'applique aux images de l'Agent gérées par l'Operator. Le chart Helm de l'Operator lui-même ne définit pas `registryMigrationMode` ; l'image du pod de l'Operator est contrôlée séparément par la valeur `image.repository` du chart de l'Operator.
-Docker Hub est soumis à des limites de taux d'extraction d'images. Si vous n'êtes pas client Docker Hub, Datadog recommande de mettre à jour votre configuration de l'Agent Datadog et de l'Agent de cluster pour extraire depuis GCR ou ECR. Pour obtenir des instructions, consultez la section
Modifier votre registre de conteneurs.
Docker Hub est soumis à des limites de taux de pull d'images. Si vous n'êtes pas client Docker Hub, Datadog vous recommande de mettre à jour la configuration de votre Datadog Agent et de votre Cluster Agent pour effectuer le pull depuis un autre registre. Pour obtenir des instructions, consultez
Modification de votre registre de conteneur.
-Avertissement pour les installations non privilégiées
+Avertissement pour les installations sans privilèges
-Lors de l'exécution d'une installation non privilégiée, l'Agent doit pouvoir lire les fichiers journaux dans /var/log/pods.
+Lors de l'exécution d'une installation sans privilèges, l'Agent doit être en mesure de lire les fichiers de logs dans /var/log/pods.
-Si vous utilisez le runtime containerd, les fichiers journaux dans /var/log/pods sont lisibles par les membres du root groupe. Avec les instructions ci-dessus, l'Agent s'exécute avec le root groupe. Aucune action n'est requise.
+Si vous utilisez le runtime containerd, les fichiers de log dans /var/log/pods sont lisibles par les membres du groupe root groupe. Avec les instructions ci-dessus, l'Agent s'exécute avec le root groupe. Aucune action n'est requise.
-Si vous utilisez le runtime Docker, les fichiers journaux dans /var/log/pods sont des liens symboliques vers /var/lib/docker/containers, qui n'est accessible que par le root utilisateur. Par conséquent, avec le runtime Docker, un Agent non privilégié ne peut pas lire les journaux.root Agent de lire les journaux dans /var/log/pods. Le socket Docker doit être monté dans le conteneur Agent, afin qu'il puisse obtenir les journaux des Pods via le démon Docker.
+Si vous utilisez le runtime Docker, les fichiers de log dans /var/log/pods sont des liens symboliques vers /var/lib/docker/containers, qui n'est accessible qu'au root utilisateur. Par conséquent, avec le runtime Docker, il n'est pas possible pour un Agent nonroot de lire les logs dans /var/log/pods. Le socket Docker doit être monté dans le conteneur de l'Agent, afin qu'il puisse obtenir les logs des Pods via le démon Docker.
-Pour collecter les journaux de conteneurs, lorsque le socket Docker est monté, définissez la variable d'environnement (ou dans …) sur [valeur appropriée]. Cela force l'Agent à utiliser le mode de collecte de fichiers. /var/log/pods lorsque le socket Docker est monté, définissez la variable d'environnement DD_LOGS_CONFIG_K8S_CONTAINER_USE_FILE (ou logs_config.k8s_container_use_file dans datadog.yaml) sur true. Cela force l'Agent à utiliser le mode de collecte de fichiers.
+Pour collecter les logs depuis /var/log/pods lorsque le socket Docker est monté, définissez la variable d'environnement DD_LOGS_CONFIG_K8S_CONTAINER_USE_FILE (ou logs_config.k8s_container_use_file dans datadog.yaml) sur true. Cela force l'Agent à utiliser le mode de collecte de fichiers.
-## Découverte des journaux {#log-discovery}
+## Découverte de logs {#log-discovery}
-L'Agent Datadog dans Kubernetes est déployé par un DaemonSet (géré par l'Opérateur Datadog ou Helm). Ce DaemonSet planifie une réplique du Pod Agent sur chaque nœud du cluster. Chaque Pod Agent est alors responsable de la remontée des journaux des autres Pods et conteneurs sur son nœud respectif. Lorsque la fonctionnalité "Collecter tous les conteneurs" est activée, l'Agent remonte les journaux d'un conteneur avec une étiquette et correspondant au nom d'image court du conteneur.
+Le Datadog Agent dans Kubernetes est déployé par un DaemonSet (géré par le Datadog Operator ou Helm). Ce DaemonSet planifie une réplique du Pod de l'Agent sur chaque nœud du cluster. Chaque Pod de l'Agent est ensuite responsable de rapporter les logs des autres Pods et conteneurs sur son nœud respectif. Lorsque la fonctionnalité « Container Collect All » est activée, l'Agent rapporte les logs de chaque conteneur découvert avec un ensemble par défaut de tags.
### Filtrage {#filtering}
-Lorsque "Collecter tous les conteneurs" est activé, vous pouvez configurer de quels conteneurs vous souhaitez collecter les journaux. Cela peut être utile pour empêcher la collecte des journaux de l'Agent Datadog, si désiré. Vous pouvez le faire en passant des configurations à l'Agent Datadog pour contrôler ce qu'il collecte, ou en passant des configurations au Pod Kubernetes pour exclure certains journaux de manière plus explicite.
+Lorsque « Container Collect All » est activé, vous pouvez configurer les conteneurs dont vous souhaitez collecter les logs. Cela peut être utile pour empêcher la collecte des logs du Datadog Agent, si vous le souhaitez. Vous pouvez le faire en transmettant des configurations au Datadog Agent pour contrôler ce qu'il récupère, ou en transmettant des configurations au Pod Kubernetes pour exclure certains logs de manière plus explicite.
-Lorsque vous filtrez des journaux par des méthodes comme `DD_CONTAINER_EXCLUDE_LOGS` ou `ad.datadoghq.com/logs_exclude`, l'Agent ignore la collecte de journaux, quelle que soit la configuration de collecte de journaux explicitement définie dans [les annotations d'autodécouverte][19] ou [les fichiers de configuration d'autodécouverte][20].
+Lors du filtrage des logs via des méthodes telles que `DD_CONTAINER_EXCLUDE_LOGS` ou `ad.datadoghq.com/logs_exclude`, l'Agent ignore la collecte de logs indépendamment des configurations de collecte de logs explicitement définies dans les [annotations Autodiscovery][19], la [`DatadogInstrumentation` CRD][23] ou les [fichiers de configuration Autodiscovery][20].
-Lorsque "Container Collect All" est désactivé (par défaut), vous n'avez pas besoin d'ajouter de filtrage car tout est exclu par défaut. Pour inclure la collecte uniquement pour les pods sélectionnés, vous pouvez activer la configuration des journaux par [les annotations d'autodécouverte][19] ou [les fichiers de configuration d'autodécouverte][20] pour les pods souhaités.
+Lorsque « Container Collect All » est désactivé (par défaut), vous n'avez pas besoin d'ajouter de filtrage car tout est exclu par défaut. Pour inclure la collecte uniquement pour certains pods sélectionnés, vous pouvez activer la configuration des logs via les [annotations Autodiscovery][19], la [`DatadogInstrumentation` CRD][23] ou les [fichiers de configuration Autodiscovery][20] pour les pods souhaités.
Consultez la section [Gestion de la détection des conteneurs][8] (en anglais) pour en savoir plus sur le filtrage.
-### Étiquetage {#tagging}
+### Tagging {#tagging}
-L'Agent Datadog étiquette les journaux des conteneurs Kubernetes avec les [étiquettes Kubernetes par défaut][14], ainsi que toutes les étiquettes extraites personnalisées. Lorsque "Collecter tous les conteneurs" est activé, l'Agent remonte les journaux d'un conteneur en lui associant une étiquette `source` et `service` correspondant au nom d'image court du conteneur. Par exemple, les journaux d'un conteneur utilisant l'image de conteneur `gcr.io/owner/example-image:latest` auraient `example-image` comme valeur d'étiquette `source`, `service` et `short_image`.
+Le Datadog Agent tague les logs des conteneurs Kubernetes avec les [tags Kubernetes][14] par défaut, ainsi qu'avec tous les tags personnalisés extraits. Lorsque « Container Collect All » est activé, l'Agent rapporte les logs d'un conteneur avec un tag `source` et `service` correspondant au nom d'image court du conteneur. Par exemple, les logs d'un conteneur utilisant l'image `gcr.io/owner/example-image:latest` auraient `example-image` comme valeur de tag `source`, `service` et `short_image`.
-L'étiquette `service` peut également être définie par l'étiquette de Pod `tags.datadoghq.com/service: ""` de [l'étiquetage de service unifié][4]. Pour plus d'informations sur les attributs `source` et `service`, voir [Attributs réservés][11].
+Le tag `service` peut également être défini par le label de Pod `tags.datadoghq.com/service: ""` de [Unified Service Tagging][4]. Pour plus d'informations sur les attributs `source` et `service`, consultez [Attributs réservés][11].
-L'étiquette `source` peut être importante pour vos journaux, car [les pipelines de journaux prêts à l'emploi][15] sont filtrés en utilisant cette étiquette. Cependant, ces pipelines peuvent être entièrement personnalisés selon vos souhaits. Vous pouvez voir les étapes dans la section [Journaux d'intégration](#integration-logs) ci-dessous pour personnaliser davantage les étiquettes de vos journaux.
+Le tag `source` peut être important pour vos logs, car les [pipelines de logs prêts à l'emploi][15] sont filtrés à l'aide de ce tag. Cependant, ces pipelines peuvent être entièrement personnalisés selon vos besoins. Vous pouvez consulter les étapes dans la section [Logs d'intégration](#integration-logs) ci-dessous pour personnaliser davantage les tags de vos logs.
-## Journaux d'intégration {#integration-logs}
+## Logs d'intégration {#integration-logs}
-[L'autodécouverte][10] vous permet d'utiliser des modèles pour configurer la collecte de journaux (et d'autres capacités) sur les conteneurs. Cela peut être utilisé pour activer la collecte de journaux, personnaliser l'étiquetage et ajouter des règles de collecte avancées. Pour configurer la collecte de journaux pour une intégration avec l'autodécouverte, vous pouvez soit :
+[Autodiscovery][10] vous permet d'utiliser des modèles pour configurer la collecte de logs et d'autres fonctionnalités sur les conteneurs. Utilisez l'une des méthodes suivantes pour configurer la collecte de logs :
-- Spécifier une configuration de journal en tant qu'annotations d'autodécouverte sur un Pod donné, pour configurer les règles pour un conteneur donné *(Recommandé)*
-- Spécifier une configuration de journal en tant que fichier de configuration, pour configurer les règles pour chaque conteneur correspondant par image.
+- [Annotations Autodiscovery](#autodiscovery-annotations) (recommandé)
+- [`DatadogInstrumentation` CRD](#datadoginstrumentation-crd) (nouveau)
+- [Fichiers de configuration d'Autodiscovery](#autodiscovery-configuration-files)
-Au minimum, ces configurations de journalisation nécessitent une étiquette `source` et une étiquette `service`. Vous souhaiterez peut-être faire correspondre la balise `source` à l'un des [pipelines de journalisation prêts à l'emploi de Datadog][15] pour aider à enrichir automatiquement vos journaux. Vous pouvez également trouver une [bibliothèque de pipelines dans Datadog][16].
+Il est fortement recommandé de définir un tag `source` et `service` sur ces configurations de log. Faites correspondre le tag `source` à l'un des [pipelines de logs prêts à l'emploi][15] de Datadog afin que vos logs soient automatiquement enrichis ; vous pouvez également trouver une [bibliothèque de pipelines dans Datadog][16]. Le tag `service` alimente le [Unified Service Tagging][4], reliant vos logs aux métriques et aux traces du même service. Si `source` et `service` sont omis, l'Agent revient au tag `service` du Unified Service Tagging (lorsqu'il est défini), et sinon au nom d'image court du conteneur.
-### Annotations d'autodécouverte {#autodiscovery-annotations}
+### Annotations d'Autodiscovery {#autodiscovery-annotations}
-Avec Autodiscovery, l’Agent recherche automatiquement les modèles d’intégration dans les annotations des pods.
+Avec Autodiscovery, l'Agent recherche automatiquement les modèles d'intégration dans les annotations des pods.
-Pour appliquer une configuration spécifique à un conteneur donné, ajoutez l'annotation `ad.datadoghq.com/.logs` à votre Pod avec la configuration de journalisation au format JSON.
+Pour appliquer une configuration spécifique à un conteneur donné, ajoutez l'annotation `ad.datadoghq.com/.logs` à votre Pod avec la configuration de log au format JSON.
-**Remarque** : Les annotations d'autodécouverte identifient les conteneurs par nom, **pas** par image. Il essaie de faire correspondre `` au `.spec.containers[i].name`, pas à `.spec.containers[i].image`.
+**Remarque** : Les annotations d'Autodiscovery identifient les conteneurs par leur nom, **non** par leur image. Il tente de faire correspondre `` au `.spec.containers[i].name`, et non au `.spec.containers[i].image`.
-Si vous définissez directement vos Pods Kubernetes (avec les annotations appropriées), ajoutez les annotations de chaque Pod dans leur section, comme indiqué dans la section suivante. kind:Pod), ajoutez les annotations de chaque Pod dans son metadata section, comme indiqué dans la section suivante.
+Si vous définissez vos Pods Kubernetes directement (avec kind:Pod), ajoutez les annotations de chaque Pod dans sa section metadata , comme indiqué dans la section suivante.
-Si vous définissez indirectement vos Pods Kubernetes (avec des contrôleurs de réplication, des ReplicaSets ou des Déploiements), ajoutez les annotations de Pod au modèle de Pod comme indiqué. .spec.template.metadata.
+Si vous définissez vos Pods Kubernetes indirectement (avec des contrôleurs de réplication, des ReplicaSets ou des Deployments), ajoutez les annotations de Pod au modèle de Pod sous .spec.template.metadata.
#### Configurer un seul conteneur {#configure-a-single-container}
Pour configurer la collecte des logs pour un conteneur donné dans un pod, ajoutez les annotations suivantes à votre pod :
@@ -217,9 +221,9 @@ spec:
# (...)
```
-#### Exemple d'annotations d'autodécouverte de journal {#example-log-autodiscovery-annotations}
+#### Exemple d'annotations d'Autodiscovery de logs {#example-log-autodiscovery-annotations}
-L'annotation de Pod suivante définit le modèle d'intégration pour un conteneur d'exemple. Il est défini dans les annotations du modèle de Pod, plutôt que sur le Déploiement lui-même. Cette configuration de journalisation définit tous les journaux du conteneur `app` avec les balises `source:java`, `service:example-app`, et la balise supplémentaire `foo:bar`.
+L'annotation de Pod suivante définit le modèle d'intégration pour un exemple de conteneur. Elle est définie dans les annotations du modèle de Pod, plutôt que sur le Deployment lui-même. Cette configuration de log définit tous les logs du conteneur `app` avec les tags `source:java`, `service:example-app`, et le tag supplémentaire `foo:bar`.
```yaml
apiVersion: apps/v1
@@ -244,8 +248,8 @@ spec:
image: owner/example-image:latest
```
-#### Configurer deux conteneurs différents {#configure-two-different-containers}
-Pour appliquer deux modèles d'intégration différents à deux conteneurs différents dans votre Pod, `` et ``, ajoutez les annotations suivantes à votre Pod :
+#### Configurez deux conteneurs différents {#configure-two-different-containers}
+Pour appliquer deux modèles d'intégration différents à deux conteneurs différents au sein de votre Pod, `` et ``, ajoutez les annotations suivantes à votre Pod :
```yaml
apiVersion: v1
@@ -265,12 +269,36 @@ spec:
# (...)
```
-### Fichiers de configuration d'autodécouverte {#autodiscovery-configuration-files}
-Vous pouvez fournir à l'Agent Datadog des fichiers de configuration pour que l'Agent exécute une intégration spécifiée lorsqu'il découvre un conteneur utilisant l'identifiant d'image correspondant. Cela vous permet de créer une configuration de journalisation générique qui s'applique à un ensemble d'images de conteneurs.
+### CRD DatadogInstrumentation {#datadoginstrumentation-crd}
+
+Au lieu d'annoter vos pods ou déploiements, vous pouvez utiliser une [`DatadogInstrumentation` ressource personnalisée][23] pour configurer la collecte des logs. L'exemple suivant concerne la partie conteneur `app` du Deployment `example` :
+
+```yaml
+apiVersion: datadoghq.com/v1alpha1
+kind: DatadogInstrumentation
+metadata:
+ name: example-logs
+ namespace:
+spec:
+ targetRef:
+ apiVersion: apps/v1
+ kind: Deployment
+ name: example
+ config:
+ logs:
+ - containerName: app
+ source: java
+ service: example-app
+ tags:
+ - foo:bar
+```
+
+### Fichiers de configuration d'Autodiscovery {#autodiscovery-configuration-files}
+Vous pouvez fournir au Datadog Agent des fichiers de configuration pour que l'Agent exécute une intégration spécifiée lorsqu'il découvre un conteneur utilisant l'identifiant d'image correspondant. Cela vous permet de créer une configuration de log générique qui s'applique à un ensemble d'images de conteneur.
{{< tabs >}}
-{{% tab "Operator Datadog" %}}
-Vous pouvez personnaliser la collecte des journaux par intégration avec une surcharge dans le `override.nodeAgent.extraConfd.configDataMap`. Cette méthode crée le ConfigMap et monte le fichier de configuration souhaité sur le conteneur de l'Agent.
+{{% tab "Datadog Operator" %}}
+Vous pouvez personnaliser la collecte des logs par intégration avec une surcharge dans le `override.nodeAgent.extraConfd.configDataMap`. Cette méthode crée la ConfigMap et monte le fichier de configuration souhaité sur le conteneur de l'Agent.
```yaml
apiVersion: datadoghq.com/v2alpha1
@@ -286,19 +314,19 @@ spec:
.yaml: |-
ad_identifiers:
-
-
+
logs:
- source: example-source
service: example-service
```
-Le `` doit correspondre au nom court de l'image du conteneur auquel vous souhaitez que cela s'applique. Voir le manifeste d'exemple [avec mappage ConfigMap][1] pour un exemple supplémentaire.
+Le `` doit correspondre au nom d'image court du conteneur auquel vous souhaitez appliquer cela. Consultez l'exemple de manifeste [avec mappage ConfigMap][1] pour un exemple supplémentaire.
[1]: https://github.com/DataDog/datadog-operator/blob/main/examples/datadogagent/datadog-agent-with-extraconfd.yaml
{{% /tab %}}
{{% tab "Helm" %}}
-Vous pouvez personnaliser la collecte des journaux par intégration dans `datadog.confd`. Cette méthode crée le ConfigMap et monte le fichier de configuration souhaité sur le conteneur de l'Agent.
+Vous pouvez personnaliser la collecte des logs par intégration dans `datadog.confd`. Cette méthode crée la ConfigMap et monte le fichier de configuration souhaité sur le conteneur de l'Agent.
```yaml
datadog:
@@ -307,35 +335,34 @@ datadog:
.yaml: |-
ad_identifiers:
-
-
logs:
- source: example-source
service: example-service
```
-Le `` doit correspondre au nom court de l'image du conteneur auquel vous souhaitez que cela s'applique.
+Le `` doit correspondre au nom d'image court du conteneur auquel vous souhaitez appliquer cela.
{{% /tab %}}
{{% tab "Stockage key/value" %}}
-Les commandes etcd suivantes créent un modèle d'intégration Redis avec un paramètre `password` personnalisé et étiquettent les journaux avec les attributs `source` et `service` corrects :
+Les commandes etcd suivantes créent un modèle d'intégration Redis avec un paramètre `password` personnalisé et ajoutent aux logs les tags `source` et `service` corrects :
```conf
etcdctl mkdir /datadog/check_configs/redis
etcdctl set /datadog/check_configs/redis/logs '[{"source": "redis", "service": "redis", "tags": ["env:prod"]}]'
```
-Remarquez que chacune des trois valeurs est une liste. L'autodécouverte assemble les éléments de la liste dans les configurations d'intégration en fonction des index de liste partagés. Dans ce cas, elle compose la première (et unique) configuration de vérification à partir de `check_names[0]`, `init_configs[0]` et `instances[0]`.
+Notez que chacune des trois valeurs est une liste. L'Autodiscovery assemble les éléments de liste dans les configurations d'intégration en fonction des index de liste partagés. Dans ce cas, il compose la première (et unique) configuration de check à partir de `check_names[0]`, `init_configs[0]` et `instances[0]`.
-Contrairement aux fichiers de configuration automatique, les **magasins de valeurs clés peuvent utiliser le nom d'image court OU long comme identifiants de conteneur**, par exemple, `redis` OU `redis:latest`.
+Contrairement aux fichiers auto-conf, les **magasins clé-valeur peuvent utiliser le nom court OU long de l'image comme identifiants de conteneur**, par exemple, `redis` OU `redis:latest`.
Autodiscovery peut utiliser [Consul][1], Etcd et Zookeeper comme sources de modèles d'intégration.
-Pour utiliser un magasin de valeurs clés, configurez-le dans le fichier de configuration de l'Agent `datadog.yaml` et montez ce fichier à l'intérieur de l'Agent conteneurisé. Sinon, passez votre magasin de valeurs clés en tant que variables d'environnement à l'Agent conteneurisé.
+Pour utiliser un magasin clé-valeur, configurez-le dans le fichier de configuration `datadog.yaml` de l'Agent et montez ce fichier à l'intérieur de l'Agent conteneurisé. Alternativement, transmettez votre magasin clé-valeur en tant que variables d'environnement à l'Agent conteneurisé.
#### Dans `datadog.yaml` {#in-datadogyaml}
-Dans le fichier `datadog.yaml`, définissez l'adresse `` et `` de votre magasin de valeurs clés :
+Dans le fichier `datadog.yaml`, définissez l'adresse `` et `` de votre magasin clé-valeur :
```yaml
config_providers:
@@ -370,7 +397,7 @@ Dans le fichier `datadog.yaml`, définissez l'adresse `` et
#### Dans les variables d'environnement {#in-environment-variables}
-Avec le magasin de valeurs clés activé en tant que source de modèle, l'Agent recherche des modèles sous la clé `/datadog/check_configs`. L'autodécouverte s'attend à une hiérarchie de clés-valeurs comme ceci :
+Avec le magasin clé-valeur activé comme source de modèle, l'Agent recherche les modèles sous la clé `/datadog/check_configs`. L'Autodiscovery attend une hiérarchie clé-valeur comme celle-ci :
```yaml
/datadog/
@@ -380,32 +407,32 @@ Avec le magasin de valeurs clés activé en tant que source de modèle, l'Agent
...
```
-**Remarque** : Pour appliquer une configuration spécifique à un conteneur donné, l'autodécouverte identifie les conteneurs par **image** lors de l'utilisation des magasins de valeurs clés en essayant de faire correspondre `` à `.spec.containers[0].image`.
+**Remarque** : Pour appliquer une configuration spécifique à un conteneur donné, l'Autodiscovery identifie les conteneurs par **image** lors de l'utilisation des magasins clé-valeur en essayant de faire correspondre `` à `.spec.containers[0].image`.
[1]: /fr/integrations/consul/
[2]: /fr/agent/configuration/agent-commands/
{{% /tab %}}
{{< /tabs >}}
-Pour associer une configuration de journal à un ensemble de conteneurs avec plus de granularité que le nom d'image court du conteneur, voir [Identifiants de conteneurs d'autodécouverte][22].
+Pour faire correspondre une configuration de log à un ensemble de conteneurs avec plus de granularité que le nom d'image court du conteneur, consultez [Autodiscovery Container Identifiers][22].
-## Collecte avancée des journaux {#advanced-log-collection}
+## Collecte de logs avancée {#advanced-log-collection}
Utilisez les étiquettes de log Autodiscovery afin d'appliquer la logique de processing pour la collecte de logs avancée, par exemple :
-* [Filtrer les journaux avant de les envoyer à Datadog][5].
-* [Nettoyer les données sensibles de vos journaux][6].
-* [Procéder à l'agrégation multi-lignes][7].
+* [Filtrer les logs avant de les envoyer à Datadog][5].
+* [Nettoyez les données sensibles de vos logs][6].
+* [Passez à l'agrégation multiligne de journaux][7].
-### À partir d'un fichier journal local de conteneur {#from-a-container-local-log-file}
+### À partir d'un fichier de log local au conteneur {#from-a-container-local-log-file}
-Datadog recommande d'utiliser les flux de sortie `stdout` et `stderr` pour les applications conteneurisées, afin de pouvoir configurer automatiquement la collecte des journaux.
+Datadog recommande d'utiliser les flux de sortie `stdout` et `stderr` pour les applications conteneurisées, afin de pouvoir configurer la collecte de logs plus automatiquement.
-Cependant, l'Agent peut également collecter directement des journaux à partir d'un fichier basé sur une annotation. Pour collecter ces journaux, utilisez `ad.datadoghq.com/.logs` avec une configuration `type: file` et `path`. Les journaux collectés à partir de fichiers avec une telle annotation sont automatiquement étiquetés avec le même ensemble d'étiquettes que les journaux provenant du conteneur lui-même. Datadog recommande d'utiliser les flux de sortie `stdout` et `stderr` pour les applications conteneurisées, afin de pouvoir configurer automatiquement la collecte des journaux. Pour plus d'informations, voir les [Configurations recommandées](#recommended-configurations).
+Cependant, l'Agent peut également collecter directement les logs à partir d'un fichier basé sur une annotation. Pour collecter ces logs, utilisez `ad.datadoghq.com/.logs` avec une configuration `type: file` et `path`. Les logs collectés à partir de fichiers avec une telle annotation sont automatiquement tagués avec le même ensemble de tags que les logs provenant du conteneur lui-même. Datadog recommande d'utiliser les flux de sortie `stdout` et `stderr` pour les applications conteneurisées, afin de pouvoir configurer automatiquement la collecte de logs. Pour plus d'informations, consultez les [Configurations recommandées](#recommended-configurations).
-Ces chemins de fichiers sont **relatifs** au conteneur de l'Agent. Par conséquent, le répertoire contenant le fichier journal doit être monté à la fois dans l'application et le conteneur de l'Agent afin que l'Agent puisse avoir une visibilité appropriée.
+Ces chemins de fichiers sont **relatifs** au conteneur de l'Agent. Par conséquent, le répertoire contenant le fichier de log doit être monté à la fois dans le conteneur de l'application et dans celui de l'Agent afin que l'Agent puisse avoir une visibilité appropriée.
-Par exemple, vous pouvez le faire avec un volume partagé `hostPath`. Le Pod ci-dessous émet des journaux dans le fichier `/var/log/example/app.log`. Cela se fait dans le répertoire `/var/log/example`, où un volume et un volumeMount ont défini cela comme un `hostPath`.
+Par exemple, vous pouvez le faire avec un volume `hostPath`. Le Pod ci-dessous émet des logs dans le fichier `/var/log/example/app.log`. Cela est effectué dans le répertoire `/var/log/example`, où un volume et un volumeMount ont défini ceci comme un `hostPath`.
```yaml
apiVersion: v1
@@ -452,9 +479,9 @@ Le même volume et le même chemin `volumeMount` doivent être définis dans le
# (...)
```
#### Configurations recommandées {#recommended-configurations}
-- Cette stratégie peut fonctionner pour un pod donné, mais peut devenir encombrante avec plusieurs applications utilisant cette stratégie. Vous pouvez également rencontrer des problèmes si plusieurs répliques utilisent le même chemin de journal. Si possible, Datadog recommande d'exploiter la variable de modèle [Autodiscovery template variable][17] `%%kube_pod_name%%`. Par exemple, vous pouvez définir votre `path` pour référencer cette variable : `"path": "/var/log/example/%%kube_pod_name%%/app.log"`. Votre pod d'application doit également écrire ses fichiers journaux par rapport à ce nouveau chemin. Vous pouvez utiliser l'[API Downward][18] pour aider votre application à déterminer le nom de son Pod.
+- Cette stratégie peut fonctionner pour un pod donné, mais peut devenir fastidieuse avec plusieurs applications utilisant cette stratégie. Vous pouvez également rencontrer des problèmes si plusieurs réplicas utilisent le même chemin de log. Si possible, Datadog recommande de tirer parti de la [variable de modèle Autodiscovery][17] `%%kube_pod_name%%`. Par exemple, vous pouvez définir votre `path` pour référencer cette variable : `"path": "/var/log/example/%%kube_pod_name%%/app.log"`. Votre pod d'application doit alors également écrire ses fichiers de log en respectant ce nouveau chemin. Vous pouvez utiliser l'[API Downward][18] pour aider votre application à déterminer son nom de Pod.
-- Lorsque vous utilisez ce type d'annotation avec un conteneur, `stdout` et `stderr` les journaux ne sont pas collectés automatiquement à partir du conteneur. Si la collecte à partir des deux flux de sortie du conteneur et du fichier est nécessaire, activez cela explicitement dans l'annotation. Exemple :
+- Lorsque vous utilisez ce type d'annotation avec un conteneur, les logs `stdout` et `stderr` ne sont pas collectés automatiquement depuis le conteneur. Si la collecte à la fois depuis les flux de sortie du conteneur et depuis le fichier est nécessaire, activez-la explicitement dans l'annotation. Exemple :
```yaml
ad.datadoghq.com/.logs: |
[
@@ -463,13 +490,13 @@ Le même volume et le même chemin `volumeMount` doivent être définis dans le
]
```
-- Lorsque vous utilisez ce type de combinaison, `source` et `service` n'ont pas de valeur par défaut pour les journaux collectés à partir d'un fichier et doivent être définis explicitement dans l'annotation.
+- Lorsque vous utilisez ce type de combinaison, `source` et `service` n'ont pas de valeur par défaut pour les logs collectés à partir d'un fichier et doivent être explicitement définis dans l'annotation.
## Dépannage {#troubleshooting}
-Pour les étapes de dépannage, voir [Dépannage de la collecte des journaux de conteneur][21].
+Pour les étapes de dépannage, consultez [Dépannage de la collecte des logs de conteneur][21].
-## Lectures complémentaires {#further-reading}
+## Pour aller plus loin {#further-reading}
{{< partial name="whats-next/whats-next.html" >}}
@@ -494,4 +521,5 @@ Pour les étapes de dépannage, voir [Dépannage de la collecte des journaux de
[19]: /fr/containers/kubernetes/log/?tab=helm#autodiscovery-annotations
[20]: /fr/containers/kubernetes/log/?tab=helm#autodiscovery-configuration-files
[21]: /fr/containers/troubleshooting/log-collection/?tab=datadogoperator
-[22]: /fr/containers/guide/ad_identifiers/
\ No newline at end of file
+[22]: /fr/containers/guide/ad_identifiers/
+[23]: /fr/containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd/
\ No newline at end of file
diff --git a/hugo/content/fr/containers/monitoring/kubernetes_explorer.md b/hugo/content/fr/containers/monitoring/kubernetes_explorer.md
new file mode 100644
index 00000000000..997681bbb7e
--- /dev/null
+++ b/hugo/content/fr/containers/monitoring/kubernetes_explorer.md
@@ -0,0 +1,790 @@
+---
+aliases:
+- /fr/infrastructure/containers/orchestrator_explorer
+description: Utilisez la page Kubernetes Explorer de Datadog pour surveiller vos ressources
+ Kubernetes, telles que les pods et les déploiements.
+further_reading:
+- link: https://www.datadoghq.com/blog/kubernetes-operator-performance
+ tag: Blog
+ text: Surveillez vos opérateurs Kubernetes pour assurer le bon fonctionnement de
+ vos applications.
+- link: https://learn.datadoghq.com/courses/getting-started-k8s
+ tag: Centre d'apprentissage
+ text: Premiers pas avec l'observabilité Kubernetes
+title: Kubernetes Explorer
+---
+{{< img src="infrastructure/livecontainers/orch_ex.png" alt="Kubernetes Explorer, affichant les pods Kubernetes." style="width:80%;">}}
+
+[Kubernetes Explorer][1] de Datadog vous permet de surveiller l'état des pods, des déploiements et d'autres ressources Kubernetes. Vous pouvez également afficher les spécifications des ressources pour les pods en échec au sein d'un déploiement, corréler l'activité des nœuds avec les logs associés, suivre l'utilisation des ressources, mettre à l'échelle automatiquement les workloads et corriger les erreurs.
+
+Lors de l'utilisation du Datadog Agent, Kubernetes Explorer nécessite l'Agent 7.27.0+ et le Cluster Agent 1.11.0+. Si vous utilisez Kubernetes 1.25+, le Cluster Agent 7.40.0+ est requis.
+
+
+## Configuration {#configuration}
+
+### Activer Kubernetes Explorer {#enable-kubernetes-explorer}
+
+Kubernetes Explorer est **activé par défaut** pour la plupart des installations du Datadog Agent.
+
+{{< tabs >}}
+{{% tab "Datadog Operator" %}}
+
+Lorsque vous installez le Datadog Agent à l'aide du Datadog Operator, Kubernetes Explorer est activé par défaut.
+
+Pour vérifier que Kubernetes Explorer est activé, assurez-vous que le paramètre `features.orchestratorExplorer.enabled` est défini sur `true` dans votre `datadog-agent.yaml` :
+
+```yaml
+apiVersion: datadoghq.com/v2alpha1
+kind: DatadogAgent
+metadata:
+ name: datadog
+spec:
+ global:
+ clusterName:
+ credentials:
+ apiKey:
+ appKey:
+ features:
+ orchestratorExplorer:
+ enabled: true
+```
+
+{{% /tab %}}
+{{% tab "Helm" %}}
+
+Lorsque vous installez le Datadog Agent à l'aide du [chart Helm officiel][1], Kubernetes Explorer est activé par défaut.
+
+Pour vérifier que Kubernetes Explorer est activé, assurez-vous que le paramètre `orchestratorExplorer.enabled` est défini sur `true` dans votre fichier `datadog-values.yaml` :
+
+```yaml
+datadog:
+ clusterName:
+ # (...)
+ processAgent:
+ enabled: true
+ orchestratorExplorer:
+ enabled: true
+```
+
+Mettez ensuite à niveau votre chart Helm.
+
+[1]: https://github.com/DataDog/helm-charts
+
+{{% /tab %}}
+{{% tab "Méthode manuelle" %}}
+Pour une configuration manuelle, consultez [Configurer Kubernetes Explorer avec un DaemonSet][1].
+
+[1]: /fr/infrastructure/faq/set-up-orchestrator-explorer-daemonset
+
+{{% /tab %}}
+{{% tab "Collector OpenTelemetry" %}}
+
+Vous pouvez alimenter Kubernetes Explorer à l'aide d'un pipeline OpenTelemetry natif au lieu du Datadog Agent. Cette configuration utilise le récepteur [`k8sobjects`][1] pour collecter les données des ressources Kubernetes et les transfère via la fonctionnalité Orchestrator Explorer de [Datadog Exporter][2].
+
+#### Prérequis {#prerequisites}
+
+- OpenTelemetry Collector Contrib [v0.154.0][3] ou version ultérieure.
+- OpenTelemetry Collector [Helm chart][4] v0.156.2 ou version ultérieure.
+
+#### Limitations {#limitations}
+
+Le récepteur open source `k8sobjects` peut imposer une charge importante sur le serveur API Kubernetes d'un cluster.
+
+Recommandations :
+
+- Utilisez Kubernetes 1.33 ou version ultérieure, qui inclut des [améliorations de liste en continu][5] réduisant l'impact sur le serveur API.
+- Commencez avec des clusters plus petits. Limitez le nombre d'objets par type de ressource à moins de 5 000 comme point de départ, et augmentez progressivement tout en surveillant la santé du cluster.
+
+Les étapes suivantes présentent les composants requis pour Kubernetes Explorer. Pour un exemple de référence complet qui collecte également les métriques d'infrastructure Kubernetes, consultez [Kubernetes Metrics][6].
+
+#### 1. Créez un secret de clé d'API Datadog {#1-create-a-datadog-api-key-secret}
+
+Créez un secret Kubernetes pour stocker votre clé d'API Datadog :
+
+```sh
+export DD_API_KEY=""
+kubectl create secret generic datadog-secret --from-literal api-key=$DD_API_KEY
+```
+
+#### 2. Configurez le collecteur de cluster {#2-configure-the-cluster-collector}
+
+Cette configuration déploie l'OTel Collector en tant que déploiement Kubernetes. Créez un fichier `deployment-collector.yaml` avec les blocs de configuration suivants, ou fusionnez-les dans votre fichier de valeurs OpenTelemetry Collector existant.
+
+##### Image et mode du collecteur {#collector-image-and-mode}
+
+Configurez le collecteur pour qu'il s'exécute en tant que déploiement à réplique unique utilisant la distribution Contrib :
+
+```yaml
+mode: deployment
+replicaCount: 1
+
+image:
+ repository: otel/opentelemetry-collector-contrib
+ tag: 0.154.0
+ pullPolicy: IfNotPresent
+
+extraEnvs:
+ - name: DD_API_KEY
+ valueFrom:
+ secretKeyRef:
+ name: datadog-secret
+ key: api-key
+```
+
+##### Collecte d'objets Kubernetes {#kubernetes-objects-collection}
+
+Le `kubernetesObjects` [préréglage][4] provisionne automatiquement le compte de service, les autorisations RBAC et les valeurs par défaut du récepteur `k8sobjects` nécessaires pour remplir Kubernetes Explorer. Remplacez le récepteur `interval` par `3m`, ce qui est requis pour Kubernetes Explorer :
+
+```yaml
+presets:
+ kubernetesObjects:
+ enabled: true
+ watch: true
+
+config:
+ receivers:
+ k8sobjects:
+ interval: 3m
+```
+
+##### Datadog Exporter {#datadog-exporter}
+
+Activez l'option `orchestrator_explorer` dans le Datadog Exporter. Il s'agit du paramètre qui envoie les données d'objet Kubernetes à Kubernetes Explorer. Remplacez `` par votre [site Datadog][7] :
+
+```yaml
+config:
+ exporters:
+ datadog:
+ api:
+ site:
+ key: ${env:DD_API_KEY}
+ orchestrator_explorer:
+ enabled: true
+```
+
+##### Processeurs et pipeline {#processors-and-pipeline}
+
+Ajoutez un processeur [`resourcedetection`][8] pour détecter l'UID et le nom du cluster.
+
+- Le détecteur `k8s_api` est requis pour détecter l'UID du cluster (`k8s.cluster.uid`).
+- La détection du nom du cluster dépend de votre fournisseur cloud. Consultez la [documentation du processeur `resourcedetection`][8] pour connaître les fournisseurs pris en charge (EKS, AKS, GCP) et les autorisations requises.
+- Si votre fournisseur n'est pas pris en charge, utilisez un processeur `resource/add-cluster-name` pour définir le nom du cluster manuellement. Remplacez `` par le nom de votre cluster.
+
+Connectez ensuite les composants dans un pipeline `logs`.
+
+Les exemples suivants présentent deux approches. Utilisez l'exemple du fournisseur cloud si vous utilisez EKS, AKS ou GCP. Utilisez le recours manuel si votre fournisseur n'est pas pris en charge.
+
+**Détection du fournisseur cloud (exemple EKS) :**
+
+```yaml
+ processors:
+ resourcedetection:
+ detectors: [k8s_api, eks]
+ override: false
+ eks:
+ resource_attributes:
+ k8s.cluster.name:
+ enabled: true
+
+ service:
+ pipelines:
+ logs:
+ receivers: [k8sobjects]
+ processors: [resourcedetection]
+ exporters: [datadog]
+```
+
+Remplacez `eks` par le détecteur de votre fournisseur (`aks`, `gcp`). Consultez la [`resourcedetection` documentation du processeur][8] pour la configuration spécifique au fournisseur.
+
+**Recours manuel :**
+
+Si le processeur `resourcedetection` ne prend pas en charge votre fournisseur cloud, définissez le nom du cluster manuellement. Remplacez `` par le nom de votre cluster :
+
+```yaml
+ processors:
+ resourcedetection:
+ detectors: [k8s_api]
+ override: false
+ resource/add-cluster-name:
+ attributes:
+ - key: k8s.cluster.name
+ value:
+ action: upsert
+
+ service:
+ pipelines:
+ logs:
+ receivers: [k8sobjects]
+ processors: [resourcedetection, resource/add-cluster-name]
+ exporters: [datadog]
+```
+
+#### 3. Déployez avec Helm {#3-deploy-with-helm}
+
+Installez le collecteur OpenTelemetry en utilisant votre fichier de configuration :
+
+```sh
+helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
+helm repo update
+
+helm install deployment-collector open-telemetry/opentelemetry-collector \
+ --values ./deployment-collector.yaml
+```
+
+#### 4. Vérifiez l'installation {#4-verify-the-installation}
+
+Ouvrez le [Kubernetes Explorer][9] et filtrez par le nom de votre cluster OpenTelemetry. Toutes les sections principales de ressources Kubernetes devraient se remplir, ainsi que **Custom Resources > CRD**. La section **Custom Resources > Resources** n'est pas prise en charge avec cette configuration.
+
+#### 5. Corrélez les logs, les métriques et les traces avec Kubernetes Explorer (facultatif) {#5-correlate-logs-metrics-and-traces-with-kubernetes-explorer-optional}
+
+Pour naviguer entre les ressources Kubernetes et leurs logs, métriques et traces associés, ajoutez les processeurs [`k8sattributes`][10] et [`resourcedetection`][8] à vos pipelines de collecteur existants. Pour la configuration `resourcedetection`, voir [Processeurs et pipeline](#processors-and-pipeline) ci-dessus.
+
+```yaml
+processors:
+ k8sattributes:
+ auth_type: "serviceAccount"
+ extract:
+ metadata:
+ - k8s.pod.name
+ - k8s.pod.uid
+ - k8s.deployment.name
+ - k8s.namespace.name
+ - k8s.node.name
+ - k8s.replicaset.name
+ - k8s.statefulset.name
+ - k8s.daemonset.name
+ - k8s.cronjob.name
+ - k8s.job.name
+ - k8s.container.name
+ pod_association:
+ - sources:
+ - from: resource_attribute
+ name: k8s.pod.uid
+ - sources:
+ - from: resource_attribute
+ name: k8s.pod.ip
+ - sources:
+ - from: resource_attribute
+ name: k8s.pod.name
+ - from: resource_attribute
+ name: k8s.namespace.name
+ - sources:
+ - from: connection
+
+service:
+ pipelines:
+ logs:
+ processors: [k8sattributes, resourcedetection, ...]
+ metrics:
+ processors: [k8sattributes, resourcedetection, ...]
+ traces:
+ processors: [k8sattributes, resourcedetection, ...]
+```
+
+Pour un exemple de référence complet, voir la [configuration du collecteur DaemonSet][11].
+
+[1]: https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/k8sobjectsreceiver
+[2]: https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/datadogexporter
+[3]: https://github.com/open-telemetry/opentelemetry-collector-contrib/releases/tag/v0.154.0
+[4]: https://github.com/open-telemetry/opentelemetry-helm-charts/tree/opentelemetry-collector-0.156.2/charts/opentelemetry-collector
+[5]: https://kubernetes.io/blog/2025/05/09/kubernetes-v1-33-streaming-list-responses/
+[6]: /fr/opentelemetry/integrations/kubernetes_metrics/#setup
+[7]: /fr/getting_started/site/
+[8]: https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/resourcedetectionprocessor
+[9]: https://app.datadoghq.com/orchestration/overview
+[10]: https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/k8sattributesprocessor
+[11]: https://github.com/DataDog/opentelemetry-examples/blob/main/guides/kubernetes/configuration/daemonset-collector.yaml
+
+{{% /tab %}}
+{{% tab "Pile Kube OpenTelemetry" %}}
+
+Vous pouvez remplir Kubernetes Explorer en utilisant le chart Helm `opentelemetry-kube-stack` au lieu du Datadog Agent.
+
+Le chart Helm [`opentelemetry-kube-stack`][1] installe l'opérateur OpenTelemetry et gère les collecteurs en tant que `OpenTelemetryCollector`Custom Resources (CR). Datadog maintient une référence [`values.yaml`][2] qui configure deux collecteurs :
+
+- **`cluster`** (Deployment) : récupère les métriques kube-state-metrics, surveille les objets Kubernetes et active `orchestrator_explorer` pour remplir Kubernetes Explorer.
+- **`daemon`** (DaemonSet) : collecte les métriques de l'host et du kubelet, et expose un endpoint OTLP pour les données de télémétrie des applications.
+
+#### Prérequis {#prerequisites-1}
+
+- Helm chart OpenTelemetry Kube Stack [0.20.1][3] ou version ultérieure.
+- OpenTelemetry Collector Contrib [v0.154.0][4] ou version ultérieure (épinglé par le fichier de valeurs de référence).
+- cert-manager, qui est requis pour le webhook d'admission de l'opérateur.
+
+#### Limitations {#limitations-1}
+
+Le récepteur open source `k8sobjects` peut imposer une charge importante sur le serveur API Kubernetes d'un cluster.
+
+Recommandations :
+
+- Utilisez Kubernetes 1.33 ou version ultérieure, qui inclut des [améliorations de liste en continu][5] réduisant l'impact sur le serveur API.
+- Commencez avec des clusters plus petits. Limitez le nombre d'objets par type de ressource à moins de 5 000 comme point de départ, et augmentez progressivement tout en surveillant la santé du cluster.
+
+#### Démarrage rapide (installateur interactif) {#quickstart-interactive-installer}
+
+Le dépôt [`opentelemetry-examples`][6] fournit un installateur interactif qui gère toutes les étapes ci-dessous. Depuis `guides/kubernetes/configuration/opentelemetry-kube-stack/` :
+
+```sh
+./install
+```
+
+L'installateur demande votre clé d'API Datadog, votre [site Datadog][7], votre plateforme Kubernetes et votre environnement de déploiement. Pour EKS, GKE et AKS, il active le préréglage de détection de ressources correspondant. Pour les autres plateformes, il demande le nom du cluster. Il crée ensuite l'espace de nom `opentelemetry-operator-system` et `datadog-secret`, installe cert-manager si nécessaire, et installe ou met à niveau le chart.
+
+#### Installation avec des fichiers de valeurs {#install-with-values-files}
+
+Si vous n'avez pas utilisé l'installateur interactif ci-dessus, suivez les étapes ci-dessous pour effectuer une installation manuelle.
+
+##### 1. Installez cert-manager (si ce n'est pas déjà fait) {#1-install-cert-manager-if-not-already-present}
+
+```sh
+helm repo add jetstack https://charts.jetstack.io
+helm repo update
+
+helm install cert-manager jetstack/cert-manager \
+ --namespace cert-manager --create-namespace \
+ --set crds.enabled=true
+```
+
+##### 2. Créez le secret Datadog {#2-create-the-datadog-secret}
+
+Définissez `DD_SITE` sur votre [site Datadog][7] (la valeur par défaut est `datadoghq.com`) :
+
+```sh
+export DD_API_KEY=""
+export DD_SITE="datadoghq.com" # for example us3.datadoghq.com, datadoghq.eu
+
+kubectl create namespace opentelemetry-operator-system \
+ --dry-run=client -o yaml | kubectl apply -f -
+
+kubectl create secret generic datadog-secret \
+ --namespace opentelemetry-operator-system \
+ --from-literal="api-key=$DD_API_KEY" \
+ --from-literal="dd-site=$DD_SITE" \
+ --dry-run=client -o yaml | kubectl apply -f -
+```
+
+##### 3. Créez une surcouche de déploiement {#3-create-a-deployment-overlay}
+
+La référence `values.yaml` est la base ; les paramètres spécifiques au déploiement (plateforme de cluster, environnement, nom du cluster) se trouvent dans un fichier de surcouche. Depuis `guides/kubernetes/configuration/opentelemetry-kube-stack/`, copiez l'exemple qui correspond à votre plateforme :
+
+```sh
+mkdir -p deployment
+
+# EKS, GKE, or AKS (resource detector auto-populates k8s.cluster.name):
+cp examples/eks-deployment/values.yaml deployment/values.yaml
+cp examples/gcp-deployment/values.yaml deployment/values.yaml
+cp examples/aks-deployment/values.yaml deployment/values.yaml
+
+# Other platforms (set the cluster name manually):
+cp examples/manually-set-k8s-cluster-name/values.yaml deployment/values.yaml
+```
+
+Pour les plateformes autres qu'EKS/GKE/AKS, modifiez `deployment/values.yaml` et remplacez `my_k8s_cluster` et `production` par le nom de votre cluster et votre environnement de déploiement.
+
+##### 4. Déployez les collecteurs de référence {#4-deploy-the-reference-collectors}
+
+Installez ou mettez à niveau le chart avec la base `values.yaml` et votre superposition :
+
+```sh
+helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
+helm repo update
+
+helm upgrade --install opentelemetry-kube-stack \
+ open-telemetry/opentelemetry-kube-stack \
+ --namespace opentelemetry-operator-system \
+ --values ./values.yaml \
+ --values ./deployment/values.yaml
+```
+
+Les deux collecteurs utilisent par défaut des limites de `500m` CPU et `1Gi` de mémoire, ainsi que des demandes de `200m` CPU et `500Mi` de mémoire. Effectuez une mise à l'échelle pour les grands clusters.
+
+#### Vérifiez l'installation {#verify-the-installation}
+
+Ouvrez le [Kubernetes Explorer][8] et filtrez par le nom de votre cluster. Toutes les sections principales de ressources Kubernetes devraient se remplir, ainsi que **Custom Resources > CRD**. La section **Custom Resources > Resources** n'est pas prise en charge avec cette configuration.
+
+[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
+[3]: https://github.com/open-telemetry/opentelemetry-helm-charts/releases/tag/opentelemetry-kube-stack-0.20.1
+[4]: https://github.com/open-telemetry/opentelemetry-collector-contrib/releases/tag/v0.154.0
+[5]: https://kubernetes.io/blog/2025/05/09/kubernetes-v1-33-streaming-list-responses/
+[6]: https://github.com/DataDog/opentelemetry-examples/tree/main/guides/kubernetes/configuration/opentelemetry-kube-stack
+[7]: /fr/getting_started/site/
+[8]: https://app.datadoghq.com/orchestration/overview
+
+{{% /tab %}}
+{{< /tabs >}}
+
+### Ajoutez des tags personnalisés aux ressources {#add-custom-tags-to-resources}
+
+Pour faciliter le filtrage, vous pouvez ajouter des tags personnalisés à vos ressources Kubernetes via la variable d'environnement `DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS`. **Ces tags n'apparaissent que dans [Kubernetes Explorer].**
+
+{{< tabs >}}
+{{% tab "Datadog Operator" %}}
+
+Définissez la variable d'environnement `DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS` **deux fois** dans `datadog-agent.yaml` :
+- Dans `agents.containers.processAgent.env`
+- Dans `clusterAgent.env`
+
+```yaml
+apiVersion: datadoghq.com/v2alpha1
+kind: DatadogAgent
+metadata:
+ name: datadog
+spec:
+ global:
+ credentials:
+ apiKey:
+ appKey:
+ features:
+ liveContainerCollection:
+ enabled: true
+ orchestratorExplorer:
+ enabled: true
+ override:
+ agents:
+ containers:
+ processAgent:
+ env:
+ - name: "DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS"
+ value: "tag1:value1 tag2:value2"
+ clusterAgent:
+ env:
+ - name: "DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS"
+ value: "tag1:value1 tag2:value2"
+```
+
+Ensuite, appliquez la nouvelle configuration :
+
+```bash
+kubectl apply -n $DD_NAMESPACE -f datadog-agent.yaml
+```
+
+{{% /tab %}}
+{{% tab "Helm" %}}
+
+Définissez la variable d'environnement `DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS` **deux fois** dans `datadog-agent.yaml` :
+- Dans `processAgent.env`
+- Dans `clusterAgent.env`
+
+```yaml
+agents:
+ containers:
+ processAgent:
+ env:
+ - name: "DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS"
+ value: "tag1:value1 tag2:value2"
+clusterAgent:
+ env:
+ - name: "DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS"
+ value: "tag1:value1 tag2:value2"
+```
+
+Mettez ensuite à niveau votre chart Helm.
+
+{{% /tab %}}
+{{% tab "DaemonSet" %}}
+
+Définissez la variable d'environnement sur les conteneurs de l'Agent de processus et de l'Agent de cluster :
+
+```yaml
+- name: DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS
+ value: "tag1:value1 tag2:value2"
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+## Utilisation {#usage}
+
+### Vues {#views}
+
+Basculez entre les {{< ui >}}Pods{{< /ui >}}, {{< ui >}}Clusters{{< /ui >}}, {{< ui >}}Namespaces{{< /ui >}} et d'autres ressources Kubernetes dans le menu déroulant {{< ui >}}Select Resources{{< /ui >}} situé dans le coin supérieur gauche de la page.
+
+Chacune de ces vues inclut un tableau de données. Vous pouvez ainsi organiser facilement vos données par champ (statut, nom ou encore étiquettes Kubernetes). La Cluster Map détaillée vous offre une vue d'ensemble de vos pods et clusters Kubernetes.
+
+**Consultez [Détails du filtre de requête](#query-filter-details) pour plus de détails sur la façon de filtrer ces vues.**
+
+{{< img src="infrastructure/livecontainers/orch_ex_replicasets.png" alt="Orchestrator Explorer ouvert pour afficher Workloads > Replica Sets, en mode Résumé" style="width:80%;">}}
+
+#### Grouper par fonctionnalité et facettes {#group-by-functionality-and-facets}
+
+Regroupez les pods par tags, labels Kubernetes ou annotations Kubernetes pour obtenir une vue agrégée qui vous permet de trouver des informations plus rapidement. Vous pouvez effectuer un regroupement en utilisant la barre « Group by » en haut à droite de la page ou en cliquant sur un tag ou un label particulier et en localisant la fonction de regroupement dans le menu contextuel, comme illustré ci-dessous.
+
+{{< img src="infrastructure/livecontainers/orch_ex_groupby.png" alt="Un exemple de regroupement par équipe" style="width:80%;">}}
+
+Il est également possible d'utiliser les facettes sur la partie gauche de la page pour regrouper des ressources, ou encore pour filtrer les ressources les plus importantes, comme les pods avec un statut CrashLoopBackOff.
+
+{{< img src="infrastructure/livecontainers/crashloopbackoff.mp4" alt="Un exemple de regroupement du statut de pod CrashLoopBackOff" video=true style="width:80%;">}}
+
+### Carte du cluster {#cluster-map}
+
+Une carte de cluster vous donne une vue d'ensemble de vos pods et clusters Kubernetes. Vous pouvez voir toutes vos ressources ensemble sur un seul écran avec des groupes et des filtres personnalisés, et choisir les métriques pour remplir la couleur des nœuds.
+
+Pour examiner des ressources spécifiques depuis une Cluster Map, cliquez sur un cercle ou un groupe. Les détails s'affichent alors dans un volet distinct.
+
+{{< img src="infrastructure/livecontainers/cluster-map.mp4" alt="Une carte de cluster avec des groupes et des filtres personnalisés" video=true style="width:80%;">}}
+
+### Information panel {#information-panel}
+
+Cliquez sur une ligne du tableau ou d'un objet dans une Cluster Map pour afficher des informations sur la ressource associée dans un volet latéral
+
+{{< img src="infrastructure/livecontainers/orch_ex_panel.png" alt="Une vue des ressources dans le panneau latéral, ouvert sur les processus." style="width:80%;">}}
+
+L'onglet {{< ui >}}YAML{{< /ui >}} du panneau latéral affiche la définition complète de la ressource. À partir de la **version 7.44.0 de l'Agent**, il inclut également sept jours d'historique des définitions. Vous pouvez comparer ce qui a changé au fil du temps et entre différentes versions. L'heure indiquée correspond approximativement au moment où les modifications ont été appliquées à la ressource.
+
+Pour éviter de multiplier les changements inutiles, les modifications concernant uniquement les champs suivants sont ignorées :
+
+* metadata.resourceVersion
+* metadata.managedFields
+* metadata.generation
+* metadata.annotations[\"kubernetes.io/config.seen\"]
+* status
+
+{{< img src="infrastructure/livecontainers/orch_ex_manifest_history.png" alt="Une vue des ressources dans le panneau latéral, montrant la fonctionnalité d'historique yaml" style="width:80%;">}}
+
+Les autres onglets comportent des informations supplémentaires permettant de résoudre les éventuels problèmes concernant la ressource sélectionnée :
+
+* [**Logs**][2] : Affichez les logs de votre conteneur ou ressource. Cliquez sur n'importe quel log pour afficher les logs associés dans le Log Explorer.
+* [**APM**][3] : Affichez les traces de votre conteneur ou ressource, y compris la date, le service, la durée, la méthode et le code d'état d'une trace.
+* [**Metrics**][4] : Affichez les métriques en direct pour votre conteneur ou ressource. Vous pouvez afficher n'importe quel graphique en plein écran, en partager un instantané ou l'exporter depuis cet onglet.
+* {{< ui >}}Processes{{< /ui >}} : Affichez tous les processus en cours d'exécution dans le conteneur de cette ressource.
+* {{< ui >}}Network{{< /ui >}} : Affichez les performances réseau d'un conteneur ou d'une ressource, y compris les champs source, destination, volume envoyé et reçu, et débit. Utilisez le champ {{< ui >}}Destination{{< /ui >}} pour effectuer une recherche par tags comme `DNS` ou `ip_type`, ou utilisez le filtre {{< ui >}}Group by{{< /ui >}} dans cette vue pour regrouper les données réseau par tags, comme `pod_name` ou `service`.
+* [**Événements**][5] : Affichez tous les événements Kubernetes pour votre ressource.
+* {{< ui >}}Monitors{{< /ui >}} : Affichez les monitors tagués, délimités ou regroupés pour cette ressource.
+
+Pour obtenir un dashboard détaillé de cette ressource, cliquez sur l'option View Dashboard en haut à droite de ce volet.
+
+{{< img src="infrastructure/livecontainers/view-pod-dashboard.png" alt="Un lien vers un dashboard pod depuis la vue d’ensemble de Live Containers." style="width:80%;">}}
+
+### Resource Utilization {#resource-utilization}
+
+_Pour la page Resource Utilization, consultez [Resource Utilization][6]_.
+
+Dans l'onglet Kubernetes Explorer, vous pouvez explorer une sélection de métriques d'utilisation des ressources.
+
+{{< img src="infrastructure/livecontainers/orch_ex_resource_utilization.png" alt="Container Resource Utilization" style="width:80%;">}}
+
+Toutes les colonnes de cette vue peuvent être triées, ce qui vous permet d'identifier des workloads spécifiques en fonction de leur utilisation des ressources.
+
+{{< img src="infrastructure/livecontainers/orch_ex_resource_utilization_sorted_column.png" alt="Colonnes triées de l'utilisation des ressources du conteneur" style="width:50%;">}}
+
+## Query filter details {#query-filter-details}
+
+Vous pouvez filtrer les ressources affichées en fournissant une requête dans la barre de recherche Filter by, située en haut à gauche de la page.
+
+### Syntax {#syntax}
+
+Une requête de filtre est composée de termes et d'opérateurs. Exemple :
+
+{{< img src="infrastructure/livecontainers/orch_syntax.png" alt="Syntaxe du filtre de requête d'Orchestrator Explorer." style="width:80%;">}}
+
+#### Terms {#terms}
+
+Vous pouvez utiliser plusieurs types de termes :
+
+| Type | Examples |
+|---|---|
+| **Tags**: Attached to resources by [the agent collecting them][7]. Il existe également des tags supplémentaires que Datadog génère pour les ressources Kubernetes. | `datacenter:staging`, `tag#datacenter:staging`
_(le `tag#` est facultatif)_ |
+| **Labels**: Extracted from [a resource's metadata][8]. Ils sont généralement utilisés pour organiser votre cluster et cibler des ressources spécifiques avec selectors. | `label#chart_version:2.1.0` |
+| **Annotations** : Extraites des [métadonnées d'une ressource][9]. Elles sont généralement utilisées pour prendre en charge des outils qui aident à la gestion du cluster. | `annotation#checksum/configmap:a1bc23d4` |
+| **Metrics**: ajoutées aux ressources de workloads (pods, deployments, etc.). Vous pouvez trouver des ressources en fonction de leur utilisation. Pour voir quelles métriques sont prises en charge, consultez [Resource Utilization Filters](#resource-utilization-filters). | `metric#cpu_usage_pct_limits_avg15:>80%` |
+| **String matching**: Supported by some specific resource attributes, see below.
_Note : string matching does not use the key-value format, and you cannot specify the attribute to match on._ | `"10.132.6.23"` (IP),
`"9cb4b43f-8dc1-4a0e"` (UID),
`web-api-3` (Nom) |
+| **Champs** : Extraits des [métadonnées d'une ressource][10] ou des champs indexés des ressources personnalisées. | `field#metadata.creationTimestamp:>=4wk`, `field#metadata.deletionTimestamp:<=1hr`, `field#status.currentReplicas:3`, `field#status.conditions.Active.status:True` |
+
+> ***Remarque** : Vous pourriez trouver les mêmes paires clé-valeur à la fois comme tag et comme étiquette (ou annotation)a; cela dépend de la configuration de votre cluster.*
+
+Les attributs de ressource suivants sont pris en charge dans la **Correspondance de chaîne** arbitraire :
+- `metadata.name`
+- `metadata.uid`
+- Adresses IP trouvées dans :
+ - Pods
+ - Nœuds (internes et externes)
+ - Services (IP de cluster, externes et d'équilibreur de charge)
+
+Vous n'avez pas besoin de spécifier une clé pour rechercher une ressource par nom ou par IP. Les guillemets ne sont pas requis, sauf si votre recherche de chaîne inclut certains caractères spéciaux.
+
+#### Comparators {#comparators}
+
+Tous les termes prennent en charge l'opérateur d'égalité `:`. [Metric value](#resource-utilization-filters) terms support numeric comparisons as well:
+
+- `:>` Greater than (for example, `metric#cpu_usage_avg15:>0.9`)
+- `:>=` Greater than or equal
+- `:<` Less than
+- `:<=` Less than or equal
+
+#### Operators {#operators}
+
+Pour combiner plusieurs termes dans une requête complexe, vous pouvez utiliser l'un des opérateurs booléens suivants (sensibles à la casse) :
+
+| Operator | Description | Example |
+|---|---|---|
+| `AND` | **Intersection**: Both terms are in the selected events (if nothing is added, AND is taken by default) | `a AND b` |
+| `OR` | **Union**: Either term is contained in the selected events | `a OR b` |
+| `NOT` / `-` | **Exclusion**: Le terme suivant n'est PAS dans l'événement (s'applique à chaque recherche dans le texte brut) | `a AND NOT b` or
`a AND -b` |
+| `( )` | **Regroupement :** Spécifiez comment regrouper les termes logiquement. | `a AND (b OR c)` ou
`(a AND b) or c` |
+
+##### `OR` raccourci de valeur {#or-value-shorthand}
+
+Plusieurs termes partageant la même clé peuvent être combinés en un seul terme s'ils utilisent tous l'opérateur `OR`. Par exemple, cette requête :
+
+```
+app_name:web-server OR app_name:database OR app_name:event-consumer
+```
+
+Il est possible d'indiquer uniquement ce qui suit :
+
+```
+app_name:(web-server OR database OR event-consumer)
+```
+
+### Wildcards {#wildcards}
+
+Vous pouvez utiliser `*` wildcards dans un terme pour filtrer par correspondances partielles, aussi bien pour values que pour keys. Quelques exemples :
+
+- `kube_job:stats-*`: Find all resources with a `kube_deployment` tag value starting with `stats-`.
+- `pod_name:*canary`: Find all resources with a `pod_name` value ending in `canary`.
+- `label#release:*` : Trouver toutes les ressources avec un label `release`, quelle que soit sa valeur.
+- `-label#*.datadoghq.com/*` : Trouver les ressources qui n'ont aucun Datadog scoped label.
+- `kube_*:*stats*canary` : Trouver les ressources qui ont des tags de ressources associés (`kube_*`), avec `stats` au milieu de la valeur, se terminant également par `canary`.
+
+### Tags extraits {#extracted-tags}
+
+En plus des tags que vous avez [configurés][7] dans votre agent Datadog, Datadog injecte des tags générés basés sur les attributs des ressources qui peuvent répondre à vos besoins de recherche et de regroupement. Ces tags sont ajoutés aux ressources de manière conditionnelle, lorsqu'ils sont pertinents.
+
+#### Toutes les ressources {#all-resources}
+
+Toutes les ressources possèdent le tag `kube_cluster_name` et toutes les ressources avec un espace de nommage possèdent le tag `kube_namespace` qui leur est ajouté.
+
+De plus, les ressources contiennent un tag `kube_:`. Par exemple, un déploiement nommé `web-server-2` se verrait automatiquement attribuer le tag `kube_deployment:web-server-2`.
+
+> **Remarque** : Il existe quelques exceptions à ce modèle :
+>
+> - Les pods utilisent `pod_name` à la place.
+> - *VPA : `verticalpodautoscaler`*.
+> - *HPA : `horizontalpodautoscaler`*.
+> - *Persistent Volume Claims : `persistentvolumeclaim`*.
+
+Selon les étiquettes appliquées à la ressource, les tags suivants sont également extraits :
+
+| Tag | Label source |
+|---|---|
+| `kube_app_name` | `app.kubernetes.io/name` |
+| `kube_app_instance` | `app.kubernetes.io/instance` |
+| `kube_app_version` | `app.kubernetes.io/version` |
+| `kube_app_component` | `app.kubernetes.io/component` |
+| `kube_app_part_of` | `app.kubernetes.io/part-of` |
+| `kube_app_managed_by` | `app.kubernetes.io/managed-by` |
+| `env` | `tags.datadoghq.com/env` |
+| `version` | `tags.datadoghq.com/version` |
+| `service` | `tags.datadoghq.com/service` |
+
+#### Relations {#relationships}
+
+Les ressources associées se verront attribuer mutuellement des tags. Quelques exemples :
+
+- Un pod qui fait partie du déploiement « XYZ » aura un tag `kube_deployment:xyz`.
+- Une ingress qui pointe vers le service « A » aura un tag `kube_service:a`.
+
+Les ressources générées à partir de ressources « parent » auront les tags `kube_ownerref_kind` et `kube_ownerref_name` (tels que les pods et les jobs).
+
+> **Conseil :** Utilisez la fonction de saisie semi-automatique des requêtes de filtrage pour découvrir quels tags de ressources associés sont disponibles. Saisissez `kube_` et voyez quels résultats sont suggérés.
+
+#### Pods {#pods}
+
+Les pods possèdent les tags suivants :
+
+- `pod_name`
+- `pod_phase` (extrait du manifeste)
+- `pod_status` (calculé de la même manière que `kubectl`)
+
+#### Workloads {#workloads}
+
+Les ressources de workload (pods, déploiements, StatefulSets, etc.) possèdent les tags suivants, qui indiquent leur statut de prise en charge par la page Resources Utilization :
+
+- `resource_utilization` (`supported` ou `unsupported`)
+- `missing_cpu_requests`
+- `missing_cpu_limits`
+- `missing_memory_requests`
+- `missing_memory_limits`
+
+#### Conditions {#conditions}
+
+Certaines conditions, pour certaines ressources, sont extraites sous forme de tags. Par exemple, vous pouvez trouver le tag `kube_condition_available` sur les déploiements. Le format du tag est toujours `kube_condition_` avec une valeur `true` ou `false`.
+
+> **Conseil** : Utilisez la fonction de saisie semi-automatique pour découvrir quelles conditions sont disponibles sur un type de ressource donné en saisissant `kube_condition` et en examinant les résultats.
+
+#### Tags spécifiques aux ressources {#resource-specific-tags}
+
+Certaines ressources possèdent des tags spécifiques qui sont extraits en fonction de l'environnement de votre cluster. Les tags suivants sont disponibles en plus des tags partagés ci-dessus.
+
+| Ressource | Tags extraits |
+|---|---|
+| **Cluster** | `api_server_version`
`kubelet_version` |
+| **Custom Resource Definitions** &
**Custom Resources** | `kube_crd_kind`
`kube_crd_group`
`kube_crd_version`
`kube_crd_scope`
`kube_crd_resource` |
+| **Namespace** | `phase` |
+| **Nœud** | `kube_node_unschedulable`
`kube_node_kubelet_version`
`kube_node_kernel_version`
`kube_node_runtime_version`
`eks_fargate_node`
`node_schedulable`
`node_status` |
+| **Volume persistant** | `kube_reclaim_policy`
`kube_storage_class_name`
`pv_type`
`pv_phase` |
+| **Réclamation de volume persistant** | `pvc_phase`
`kube_storage_class_name` |
+| **Pod** | `pod_name` (au lieu de `kube_pod`)
`pod_phase` (extrait du manifeste)
`pod_status` (calculé de manière similaire à `kubectl`) |
+| **Service** | `kube_service_type`
`kube_service_port` |
+
+### Filtres d'utilisation des ressources {#resource-utilization-filters}
+
+Des métriques d'utilisation de ressources sont appliquées aux ressources de workload suivantes :
+
+- Clusters
+- Nœuds
+- Pods
+
+Ces métriques sont calculées au moment de la collecte, sur la base des valeurs moyennes des 15 dernières minutes. Vous pouvez filtrer par valeurs de métrique comme suit : `metric#`.
+
+- `metric_name` est une métrique disponible (voir ci-dessous)
+- `comparator` est un [comparateur pris en charge](#comparator)
+- et `numeric_value` est une valeur à virgule flottante.
+
+Pour les Pods, les noms de métriques suivants sont disponibles :
+
+| CPU | Mémoire |
+|---|---|
+| `cpu_limits_avg15` | `mem_limits_avg15` |
+| `cpu_requests_avg15` | `mem_requests_avg15` |
+| `cpu_usage_avg15` | `mem_usage_avg15` |
+| `cpu_usage_pct_limits_avg15` | `mem_usage_pct_limits_avg15` |
+| `cpu_usage_pct_requests_avg15` | `mem_usage_pct_requests_avg15` |
+| `cpu_waste_avg15` | `mem_waste_avg15` |
+
+De plus, les métriques suivantes sont disponibles pour les clusters et nœuds :
+
+- `cpu_usage_pct_alloc_avg15`
+- `cpu_requests_pct_alloc_avg15`
+- `mem_usage_pct_alloc_avg15`
+- `mem_requests_pct_alloc_avg15`
+
+#### Unités de mesure {#metric-units}
+
+Les métriques relatives au CPU sont stockées en tant que nombre de cœurs.
+
+Les métriques relatives à la mémoire sont stockées en tant qu'octets.
+
+Les pourcentages (`*_pct_*`) sont stockés sous forme de nombres à virgule flottante, où `0.0` correspond à 0% et `1.0` correspond à 100%. La valeur est le rapport des deux métriques indiquées - par exemple, `cpu_usage_pct_limits_avg15` est la valeur de `usage / limits`. Les valeurs des métriques peuvent être supérieures à 100%, comme le pourcentage d'utilisation du processeur par les requêtes.
+
+## Remarques et problèmes connus {#notes-and-known-issues}
+
+* Les données sont mises à jour automatiquement à intervalles constants.
+* Dans les clusters avec plus de 1000 déploiements ou ReplicaSets, vous pourriez remarquer une utilisation accrue du processeur par le Cluster Agent. Il existe une option pour désactiver le nettoyage des conteneurs dans le chart Helm. Consultez [le dépôt du chart Helm][11] pour plus de détails.
+
+## Lectures complémentaires {#further-reading}
+
+{{< partial name="whats-next/whats-next.html" >}}
+
+[1]: https://app.datadoghq.com/orchestration/overview
+[2]: /fr/logs
+[3]: /fr/tracing
+[4]: /fr/metrics
+[5]: /fr/events
+[6]: /fr/infrastructure/containers/kubernetes_resource_utilization
+[7]: /fr/getting_started/tagging/assigning_tags/?tab=containerizedenvironments
+[8]: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
+[9]: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/
+[10]: https://kubernetes.io/docs/concepts/overview/working-with-objects/field-selectors/
+[11]: https://github.com/DataDog/helm-charts/tree/master/charts/datadog
\ No newline at end of file
diff --git a/hugo/content/fr/data_streams/dead_letter_queues.md b/hugo/content/fr/data_streams/dead_letter_queues.md
new file mode 100644
index 00000000000..844e2150816
--- /dev/null
+++ b/hugo/content/fr/data_streams/dead_letter_queues.md
@@ -0,0 +1,80 @@
+---
+further_reading:
+- link: https://www.datadoghq.com/blog/data-pipeline-monitoring/
+ tag: Blog
+ text: 'Surveillance des pipelines de données : notions de base – suivi de l''état
+ et des performances dans la pile de données'
+title: Files d'attente de lettres mortes (DLQ)
+---
+Data Streams Monitoring (DSM) offre une visibilité sur vos files d'attente de lettres mortes (DLQs) non vides, vous permettant de surveiller et d'inspecter les échecs de traitement des messages. DSM vous permet également de remédier à ces échecs de traitement des messages directement dans Datadog.
+
+La surveillance des files d'attente de lettres mortes est disponible pour les files d'attente Amazon SQS.
+
+## Surveiller les DLQ {#monitor-dlqs}
+
+### Configuration {#setup}
+* Activez [Data Streams Monitoring][1] pour vos services de messagerie.
+* Installez l'[Datadog-AWS integration][2]. Utilisez cette intégration pour gérer les autorisations.
+* Pour remédier aux échecs de traitement des messages dans Datadog, une configuration supplémentaire est requise. Consultez la section [Remédier aux problèmes de DLQ](#remediate-dlq-issues).
+
+### Utilisation {#usage}
+
+#### Créer un monitor pour une file d'attente de lettres mortes {#create-a-monitor-for-a-dead-letter-queue}
+
+Pour savoir si votre file d'attente redirige des messages vers sa DLQ, vous pouvez créer un [metric monitors][8] qui alerte sur la métrique [`data_streams.sqs.dead_letter_queue.messages`][8].
+
+Pour créer un monitor pour la DLQ d'une file d'attente :
+
+1. Dans Datadog, accédez à [Data Streams Monitoring][4].
+2. Sélectionnez l'onglet {{< ui >}}Explore{{< /ui >}} (par défaut).
+3. Cliquez sur une file d'attente prise en charge pour ouvrir son panneau latéral.
+4. Sélectionnez l'onglet {{< ui >}}Dead Letter Queue{{< /ui >}}.
+5. Cliquez sur {{< ui >}}Create Monitor{{< /ui >}} pour ouvrir une page de configuration de monitor. Les entrées par défaut sont suffisantes pour créer un monitor qui vous alerte lorsque votre DLQ n'est pas vide, mais vous pouvez également effectuer des configurations supplémentaires sur cette page si vous le souhaitez.
+6. Cliquez sur {{< ui >}}Create{{< /ui >}} en bas de la page.
+
+#### Détecter les problèmes de traitement des messages {#detect-message-processing-issues}
+
+Data Streams Monitoring vous aide à détecter où les messages n'ont pas pu être traités et quels services en aval pourraient être affectés :
+
+* Le DSM [{{< ui >}}Service Map{{< /ui >}}][6] met en évidence les files d'attente contenant des messages dans leurs DLQs, vous aidant à identifier visuellement où les échecs se produisent.
+
+* La page DSM [{{< ui >}}Issues{{< /ui >}}][7] répertorie toutes les files d'attente qui rencontrent des problèmes de traitement des messages
+
+## Remédier aux problèmes de DLQ {#remediate-dlq-issues}
+Vous pouvez inspecter et résoudre les DLQ non vides directement dans Datadog en utilisant [Datadog Actions][5].
+
+### Configuration {#setup-1}
+Dans Datadog, créez une [connexion][9]. Vous avez besoin d'une entité IAM pour effectuer les actions. Cette entité IAM peut être un utilisateur IAM (avec une clé d'accès secrète) ou un rôle IAM (assumé en utilisant `sts:AssumeRole`) et doit disposer des autorisations suivantes :
+ * `sqs:ReceiveMessage` (pour _peek_)
+ * `sqs:StartMessageMoveTask` (pour _redrive_)
+ * `sqs:PurgeQueue` (pour _purge_)
+
+Ces autorisations peuvent être appliquées globalement à toutes les files d'attente SQS, ou restreintes à des files d'attente spécifiques.
+
+### Utilisation {#usage-1}
+
+Une fois la connexion configurée, vous pouvez cliquer sur une file d'attente prise en charge pour ouvrir son panneau latéral, où vous pouvez utiliser les actions suivantes :
+
+* {{< ui >}}Peek{{< /ui >}} pour inspecter le contenu des messages ayant échoué et identifier la cause première
+* {{< ui >}}Redrive{{< /ui >}} pour remettre les messages en file d'attente pour une autre tentative de traitement
+* {{< ui >}}Purge{{< /ui >}} pour effacer les messages qui n'ont plus besoin d'être traités
+
+## Dépannage {#troubleshooting}
+Si vous ne parvenez pas à voir les informations de la file d'attente de lettres mortes :
+* Confirmez que vous avez installé la [Datadog-AWS integration][2]
+* Confirmez que votre rôle AWS utilise l'AWS-managed `AmazonSQSReadOnlyAccess` policy
+* Confirmez que votre rôle dispose des autorisations `sqs:ListQueues` et `sqs:GetQueueAttributes`
+
+[1]: /fr/data_streams/setup
+[2]: /fr/integrations/amazon-web-services/
+[3]: /fr/data_streams/metrics_and_tags/#data_streamssqsdead_letter_queuemessages
+[4]: https://app.datadoghq.com/data-streams/
+[5]: https://app.datadoghq.com/actions
+[6]: https://app.datadoghq.com/data-streams/map
+[7]: https://app.datadoghq.com/data-streams/issues
+[8]: /fr/monitors/types/metric/
+[9]: https://app.datadoghq.com/actions/connections
+
+## Lectures complémentaires {#further-reading}
+
+{{< partial name="whats-next/whats-next.html" >}}
\ No newline at end of file
diff --git a/hugo/content/fr/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics.md b/hugo/content/fr/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics.md
new file mode 100644
index 00000000000..b1c1fb89788
--- /dev/null
+++ b/hugo/content/fr/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics.md
@@ -0,0 +1,438 @@
+---
+aliases:
+- /fr/observability_pipelines/monitoring/metrics/
+description: Trouvez les métriques disponibles depuis Observability Pipelines pour
+ créer des dashboards, notebooks et monitors.
+disable_toc: false
+further_reading:
+- link: /metrics/summary/
+ tag: Documentation
+ text: En savoir plus sur le Metrics Summary
+- link: /metrics/explorer/
+ tag: Documentation
+ text: Utiliser le Metrics Explorer pour explorer et analyser vos métriques
+- link: /getting_started/dashboards/
+ tag: Documentation
+ text: Bien démarrer avec dashboards
+- link: /getting_started/monitors/
+ tag: Documentation
+ text: Bien démarrer avec monitors
+- link: https://www.datadoghq.com/blog/otel-ai-observability-pipelines-clickhouse/
+ tag: Blog
+ text: Acheminer les données OTel des applications IA vers ClickHouse et Datadog
+ à l'aide d'Observability Pipelines
+title: Métriques d'utilisation des pipelines
+---
+## Présentation {#overview}
+
+Ce document répertorie certaines des métriques disponibles dans Observability Pipelines. Vous pouvez effectuer les opérations suivantes :
+
+- Créez vos propres [dashboards][1], [notebooks][2] et [monitors][3] avec ces métriques.
+- Utilisez le [Metrics Summary][5] pour voir les métadonnées et les tags disponibles pour les métriques. Vous pouvez également voir quels dashboards, notebooks, monitors et SLOs utilisent ces métriques.
+
+Consultez [Getting Started with Tags][4] pour plus d'informations sur la façon d'utiliser les tags pour regrouper les métriques par pipelines, Workers et composants spécifiques.
+
+Toutes les métriques sont taguées avec les éléments suivants :
+
+`pipeline_id`
+: L'UUID du pipeline.
+
+`worker_uuid`
+: L'UUID du Worker émettant la métrique.
+
+`op_worker_version`
+: La version du Worker émettant la métrique.
+
+`rc_version`
+: Le numéro de version de la configuration, incrémenté à chaque mise à jour du pipeline.
+
+`pipeline_name`
+: Le nom du pipeline lors de son dernier déploiement ou de sa dernière mise à jour. Disponible dans la version 2.18 du Worker et les versions ultérieures.
+
+**Remarques** :
+- Chaque Worker exécute également un pipeline interne qui collecte la télémétrie propre au Worker (métriques et logs) et l'envoie à Datadog. Les composants de ce pipeline interne possèdent un tag `component_id` dont la valeur commence par un underscore (`_`) . Pour exclure ces métriques de vos requêtes, utilisez `!component_id:_*`.
+- Les métriques se terminant par `_total` rapportent un compte pour chaque intervalle de temps, leur valeur brute n'augmente donc pas de manière monotone.
+
+## Métrique d'utilisation estimée {#estimated-usage-metric}
+
+Octets ingérés par Observability Pipelines
+: **Métrique**: `datadog.estimated_usage.observability_pipelines.ingested_bytes`
+: **Description**: Le volume de données ingérées par Observability Pipelines. Consultez [Métriques d'utilisation estimée][6] pour plus d'informations.
+
+## Métriques de le host {#host-metrics}
+
+Ces métriques fournissent des informations sur le host exécutant l'Observability Pipelines Worker.
+
+Mémoire disponible
+: **Métrique**: `pipelines.host.memory_available_bytes`
+: **Description :** Le nombre d'octets de mémoire disponibles pour de nouvelles allocations sur le host.
+
+Octets entrants
+: **Métrique**: `pipelines.host.network_receive_bytes_total`
+: **Description :** Le nombre d'octets reçus par le host sur toutes les interfaces. Utilisez la tag `device` pour filtrer par interface, par exemple `device:eth0`.
+
+Octets sortants
+: **Métrique**: `pipelines.host.network_transmit_bytes_total`
+: **Description :** Le nombre d'octets envoyés par le host sur toutes les interfaces. Utilisez la tag `device` pour filtrer par interface.
+
+CPU time
+: **Métrique**: `pipelines.host.cpu_seconds_total`
+: **Description :** Le temps CPU total consommé par le host, ventilé par mode (utilisateur, système, inactif, etc.) et par cœur de CPU.
+
+Octets lus/écrits sur le disque
+: **Métrique**: `pipelines.host.disk_read_bytes_total`, `pipelines.host.disk_written_bytes_total`
+: **Description :** Le nombre d'octets lus et écrits sur tous les disques de le host.
+
+Temps de fonctionnement de le host.
+: **Métrique**: `pipelines.host.uptime`
+: **Description :** La durée écoulée depuis le démarrage de le host, en secondes.
+
+Charge moyenne
+: **Métrique**: `pipelines.host.load1`, `pipelines.host.load5`, `pipelines.host.load15`
+: **Description :** La moyenne de charge système de le host sur les 1, 5 et 15 dernières minutes. La charge moyenne est le nombre de processus en cours d'exécution ou en attente d'exécution, et sous Linux, elle inclut également les processus bloqués sur des E/S ininterruptibles. Comparez la valeur de la moyenne de charge avec la valeur `pipelines.host.logical_cpus`: ; une valeur de moyenne de charge proche du nombre de processeurs indique une utilisation complète, et une valeur supérieure indique que le host est sursouscrit. Non émis sur les Workers s'exécutant sous Windows.
+
+CPUs logiques
+: **Métrique**: `pipelines.host.logical_cpus`
+: **Description :** Le nombre de threads CPU logiques (threads matériels) disponibles sur le host.
+
+Mémoire totale
+: **Métrique**: `pipelines.host.memory_total_bytes`
+: **Description :** La mémoire physique totale (RAM) installée sur le host.
+
+## Métriques de processus {#process-metrics}
+
+Ces métriques fournissent des informations sur le processus Observability Pipelines Worker.
+
+Cœurs CPU alloués
+: **Métrique**: `pipelines.cpu_max_cores`
+: **Description :** Le nombre de cœurs CPU alloués au Worker, tel que rapporté par les limites du conteneur ou du cgroup.
+
+Utilisation du CPU
+: **Métrique** : `pipelines.cpu_usage_seconds_total`
+ : **Description :** La quantité de temps CPU consommée par le processus Worker en secondes (dans l'espace utilisateur et système). Le taux par seconde de cette métrique indique la proportion de CPU utilisée par le Worker.
+
+Octets disponibles du répertoire de données
+ : **Métrique** : `pipelines.data_dir_available_bytes`
+: **Description :** L'espace de stockage libre restant sur le système de fichiers où le Worker stocke ses données de tampon et d'état. Utile pour surveiller les tampons disque.
+
+Capacité en octets du répertoire de données
+: **Métrique** : `pipelines.data_dir_capacity_bytes`
+: **Description :** La capacité de stockage totale du système de fichiers où le Worker stocke ses données de tampon et d'état.
+
+Limite de mémoire
+: **Métrique** : `pipelines.memory_max_bytes`
+: **Description :** La mémoire maximale que le Worker est autorisé à utiliser, telle que définie par les limites du conteneur ou du cgroup.
+
+Utilisation de la mémoire
+ : **Métrique** : `pipelines.resident_memory_used_bytes`
+ : **Description :** La quantité de mémoire RSS utilisée par le processus Worker en octets.
+
+Temps de disponibilité du Worker
+: **Métrique**: `pipelines.uptime_seconds`
+: **Description:** La durée écoulée depuis le démarrage du processus Worker, en secondes.
+
+## Métriques du cycle de vie du Worker {#worker-lifecycle-metrics}
+
+Ces métriques suivent les événements du cycle de vie de l'Observability Pipelines Worker.
+
+Rechargements du Worker
+: **Métrique**: `pipelines.reloaded_total`
+: **Description:** Le nombre de fois que l'instance du Worker a été rechargée, par exemple après une modification de configuration.
+
+## Métriques des composants {#component-metrics}
+
+Ces métriques sont disponibles pour les sources, les processeurs et les destinations.
+
+- Utilisez le tag `component_id` pour filtrer ou regrouper par composants individuels.
+- Utilisez le tag `component_type` pour filtrer ou regrouper par type de source, de processeur ou de destination, comme `quota` pour le processeur Quota.
+- Utilisez le tag `component_kind` pour filtrer ou regrouper par `source`, `transform` (processeur) ou `sink` (destination).
+
+{{< tabs >}}
+{{% tab "Sources" %}}
+
+### Débit {#throughput}
+
+Octets entrants
+: **Métrique**: `pipelines.component_received_bytes_total`
+: **Description**: Le nombre d'octets bruts lus depuis l'entrée de la source, avant tout décodage ou transformation.
+
+Événements entrants
+: **Métrique**: `pipelines.component_received_events_total`
+: **Description**: Le nombre d'événements reçus par le composant.
+
+Événements sortants
+: **Métrique**: `pipelines.component_sent_events_total`
+: **Description**: Le nombre d'événements que le composant envoie en aval.
+
+Octets d'événements entrants
+: **Métrique**: `pipelines.component_received_event_bytes_total`
+: **Description**: La taille en octets des événements reçus par le composant.
+
+Octets d'événements sortants
+: **Métrique**: `pipelines.component_sent_event_bytes_total`
+: **Description**: La taille en octets des événements que le composant envoie en aval.
+
+### Erreurs, données abandonnées et expirations de délai {#errors-data-dropped-and-timed-outs}
+
+Errors
+: **Métrique**: `pipelines.component_errors_total`
+: **Description**: Le nombre d'erreurs rencontrées par le composant. Selon le composant, cette métrique peut inclure un tag `error_code`, `error_type` ou `reason` qui décrit l'erreur.
+
+Données abandonnées intentionnellement ou non
+: **Métrique**: `pipelines.component_discarded_events_total`
+: **Description** : Le nombre d'événements abandonnés. **Remarque** : Pour ventiler cette métrique, utilisez le tag `intentional:true` pour filtrer les événements abandonnés intentionnellement ou le tag `intentional:false` pour les événements qui ne le sont pas.
+
+Événements expirés
+: **Métrique** : `pipelines.component_timed_out_events_total`
+: **Description** : Le nombre d'événements qui ont attendu plus de 5 secondes avant d'être envoyés au premier processeur et qui ont entraîné une erreur HTTP 503. Cela peut se produire lorsque la distribution des événements est bloquée.
+: **Disponible pour** : les sources basées sur HTTP qui ont un délai d'expiration configuré, comme le Datadog Agent.
+
+Requêtes expirées
+: **Métrique** : `pipelines.component_timed_out_requests_total`
+: **Description** : Le nombre de requêtes ayant expiré pour les sources qui envoient des événements au Worker par lots à l'aide de requêtes HTTP.
+: **Disponible pour** : les sources basées sur HTTP qui ont un délai d'expiration configuré, comme le Datadog Agent.
+
+### Performance {#performance}
+
+Latence d'envoi
+: **Métrique** : `pipelines.source_send_latency_seconds`
+: **Description** : Le temps nécessaire à la source pour envoyer un bloc d'événements au composant suivant. Disponible dans la version 2.16 de Worker et ultérieures.
+
+Latence du lot d'envoi
+: **Métrique** : `pipelines.source_send_batch_latency_seconds`
+: **Description** : Le temps nécessaire à la source pour envoyer un lot, qui peut contenir plusieurs blocs d'événements, au composant suivant. Disponible dans la version 2.16 de Worker et ultérieures.
+
+Temps de latence de la source
+: **Métrique** : `pipelines.source_lag_time_seconds`
+: **Description** : La différence, en secondes, entre l'horodatage propre à un événement et le moment où le Worker l'a reçu. Des valeurs élevées indiquent que des données obsolètes ou retardées arrivent dans le pipeline.
+
+### Tampon {#buffer}
+
+Utilisez ces métriques pour analyser les performances du tampon. Toutes les métriques sont émises à un intervalle d'une seconde, sauf indication contraire.
+
+{{% observability_pipelines/metrics/buffer/sources %}}
+
+{{% /tab %}}
+{{% tab "Processeurs" %}}
+
+### Débit {#throughput-1}
+
+Événements entrants
+: **Métrique**: `pipelines.component_received_events_total`
+: **Description**: Le nombre d'événements reçus par le composant.
+
+Événements sortants
+: **Métrique**: `pipelines.component_sent_events_total`
+: **Description**: Le nombre d'événements que le composant envoie en aval.
+
+Octets d'événements entrants
+: **Métrique**: `pipelines.component_received_event_bytes_total`
+: **Description**: La taille en octets des événements reçus par le composant.
+
+Octets d'événements sortants
+: **Métrique**: `pipelines.component_sent_event_bytes_total`
+: **Description**: La taille en octets des événements que le composant envoie en aval.
+
+Événements inclus
+: **Métrique**: `pipelines.included_events_total`
+: **Description**: Le nombre d'événements qui ont correspondu à la requête de filtrage du processeur et ont été traités. Les événements qui ne correspondent pas à la requête de filtrage ignorent le processeur et continuent vers le composant suivant.
+
+Octets d'événements inclus
+: **Métrique**: `pipelines.included_event_bytes_total`
+: **Description** : La taille en octets des événements qui ont correspondu à la requête de filtrage du processeur et ont été traités.
+
+### Erreurs et données abandonnées {#errors-and-data-dropped}
+
+Errors
+: **Métrique** : `pipelines.component_errors_total`
+: **Description** : Le nombre d'erreurs rencontrées par le composant. Selon le composant, cette métrique peut inclure un tag `error_code`, `error_type` ou `reason` qui décrit l'erreur.
+
+Données abandonnées intentionnellement ou non
+: **Métrique** : `pipelines.component_discarded_events_total`
+: **Description** : Le nombre d'événements abandonnés. **Remarque** : Pour ventiler cette métrique, utilisez le tag `intentional:true` pour filtrer les événements abandonnés intentionnellement ou le tag `intentional:false` pour les événements qui ne le sont pas.
+
+### Performance {#performance-1}
+
+Utilisation du CPU
+: **Métrique** : `pipelines.component_cpu_usage_ns_total`
+: **Description** : Le temps CPU consommé par un composant, en nanosecondes. Utilisez cette métrique pour attribuer le coût CPU à chaque processeur. Disponible dans la version 2.18 du Worker et dans les versions ultérieures pour Linux et MacOS.
+: **Disponible pour ces processeurs de log** :
- Processeur personnalisé
- Déduplication
- Table d'enrichissement
- Analyseur Grok
- Analyser JSON
- Analyser XML
- Réduire
- Remapper vers OCSF
- Sensitive Data Scanner
- Diviser le tableau
- Processeurs de log de limitation
+ : **Disponible pour ces processeurs de métriques** :
- Agrégat
- Métriques de limite de cardinalité des tags
+
+Utilisation
+: **Métrique** : `pipelines.utilization`
+: **Description** : L'activité du composant. Une valeur de `0` indique un composant inactif qui attend une entrée. Une valeur proche de `1` indique un composant qui n'est jamais inactif, ce qui signifie que le composant est probablement un goulot d'étranglement dans la topologie de traitement qui crée une contre-pression. Cela peut entraîner la suppression d'événements.
+
+### Tampon{#buffer-1}
+
+Utilisez ces métriques pour analyser les performances du tampon. Toutes les métriques sont émises à un intervalle d'une seconde, sauf indication contraire.
+
+{{% observability_pipelines/metrics/buffer/processors %}}
+
+{{% /tab %}}
+{{% tab "Destinations" %}}
+
+### Débit {#throughput-2}
+
+Octets sortants
+: **Métrique**: `pipelines.component_sent_bytes_total`
+: **Description**: Le nombre d'octets bruts écrits dans la sortie de la destination, après encodage et transformations.
+
+Événements entrants
+: **Métrique**: `pipelines.component_received_events_total`
+: **Description**: Le nombre d'événements reçus par le composant.
+
+Événements sortants
+: **Métrique**: `pipelines.component_sent_events_total`
+: **Description**: Le nombre d'événements que le composant envoie en aval.
+
+Octets d'événements entrants
+: **Métrique**: `pipelines.component_received_event_bytes_total`
+: **Description**: La taille en octets des événements reçus par le composant.
+
+Octets d'événements sortants
+: **Métrique** : `pipelines.component_sent_event_bytes_total`
+: **Description** : La taille en octets des événements que le composant envoie en aval.
+
+### Erreurs et données supprimées{#errors-and-data-dropped-1}
+
+Errors
+: **Métrique** : `pipelines.component_errors_total`
+: **Description** : Le nombre d'erreurs rencontrées par le composant. Selon le composant, cette métrique peut inclure un tag `error_code`, `error_type` ou `reason` qui décrit l'erreur.
+
+Données abandonnées intentionnellement ou non
+: **Métrique** : `pipelines.component_discarded_events_total`
+: **Description** : Le nombre d'événements abandonnés. **Remarque** : Pour ventiler cette métrique, utilisez le tag `intentional:true` pour filtrer les événements abandonnés intentionnellement ou le tag `intentional:false` pour les événements qui ne le sont pas.
+
+### Performances {#performance-2}
+
+Utilisation
+: **Métrique** : `pipelines.utilization`
+: **Description** : L'activité du composant. Une valeur de `0` indique un composant inactif qui attend une entrée. Une valeur proche de `1` indique un composant qui n'est jamais inactif, ce qui signifie que le composant est probablement un goulot d'étranglement dans la topologie de traitement qui crée une contre-pression. Cela peut entraîner la suppression d'événements.
+
+### Tampon {#buffer-2}
+
+Utilisez ces métriques pour analyser les performances du tampon. Toutes les métriques sont émises à un intervalle d'une seconde, sauf indication contraire.
+
+{{% observability_pipelines/metrics/buffer/destinations %}}
+
+#### Métriques de tampon obsolètes {#deprecated-buffer-metrics}
+
+{{% observability_pipelines/metrics/buffer/deprecated_destination_metrics %}}
+
+{{% /tab %}}
+{{< /tabs >}}
+
+## Métriques du serveur HTTP {#http-server-metrics}
+
+Ces métriques sont émises par les sources qui reçoivent des données via HTTP, telles que le Datadog Agent, le serveur HTTP/S, OpenTelemetry et les sources Splunk HEC.
+
+- Utilisez le tag `component_id` pour filtrer ou regrouper par composants individuels.
+- Utilisez le tag `component_type` pour filtrer ou regrouper par type de source.
+
+`pipelines.http_server_requests_received_total`
+: **Description**: Le nombre de requêtes HTTP reçues.
+: **Type de métrique**: count
+
+`pipelines.http_server_responses_sent_total`
+: **Description**: Le nombre de réponses HTTP envoyées.
+: **Type de métrique**: count
+
+`pipelines.http_server_handler_duration_seconds`
+: **Description**: Le temps passé à traiter une requête HTTP.
+: **Type de métrique**: distribution
+
+## Métriques du client HTTP {#http-client-metrics}
+
+Ces métriques sont émises par les destinations qui envoient des données via HTTP, notamment :
+
+- CrowdStrike NG-SIEM
+- Logs Datadog
+- Métriques Datadog
+- Elasticsearch
+- Google SecOps
+- Destination client HTTP
+- Microsoft Sentinel
+- New Relic
+- OpenSearch
+- SentinelOne
+- Splunk HEC
+
+**Remarque**: Les destinations basées sur AWS (telles qu'Amazon S3, Amazon OpenSearch et Amazon Security Lake) n'émettent pas ces métriques.
+
+- Utilisez le tag `component_id` pour filtrer ou regrouper par composants individuels.
+- Utilisez le tag `component_type` pour filtrer ou regrouper par type de destination.
+
+`pipelines.http_client_requests_sent_total`
+: **Description**: Le nombre de requêtes HTTP envoyées, étiquetées par méthode de requête.
+: **Type de métrique**: count
+
+`pipelines.http_client_responses_total`
+: **Description**: Le nombre de réponses HTTP reçues, étiquetées par statut de réponse.
+: **Type de métrique**: count
+
+`pipelines.http_client_errors_total`
+: **Description**: Le nombre d'erreurs client HTTP, étiquetées par type d'erreur.
+: **Type de métrique**: count
+
+`pipelines.http_client_rtt_seconds`
+: **Description**: Le temps aller-retour, en secondes, pour les requêtes HTTP, depuis l'envoi de la requête jusqu'à la réception de la réponse finale ou de l'erreur.
+: **Type de métrique**: distribution
+
+`pipelines.http_client_response_rtt_seconds`
+: **Description**: Temps d'aller-retour, en secondes, des requêtes HTTP, étiqueté par statut de réponse.
+: **Type de métrique**: distribution
+
+`pipelines.http_client_error_rtt_seconds`
+: **Description** : Le temps d'aller-retour, en secondes, des requêtes HTTP ayant abouti à une erreur, étiqueté par type d'erreur.
+: **Type de métrique** : distribution
+
+## Métriques de concurrence adaptative {#adaptive-concurrency-metrics}
+
+Ces métriques fournissent des informations sur le contrôleur de concurrence adaptative, qui ajuste automatiquement le nombre de requêtes HTTP en cours qu'une destination autorise en fonction des temps de réponse observés. Elles sont émises par les destinations qui envoient des données via HTTP, y compris les destinations basées sur AWS.
+
+- Utilisez le tag `component_id` pour filtrer ou regrouper par composants individuels.
+- Utilisez le tag `component_type` pour filtrer ou regrouper par type de destination.
+
+`pipelines.active_endpoints`
+: **Description** : Le nombre d'endpoints de destination marqués comme sains.
+: **Type de métrique** : jauge
+
+`pipelines.adaptive_concurrency_limit`
+: **Description** : La limite de concurrence pour les requêtes HTTP vers cette destination, ajustée automatiquement par le contrôleur de concurrence adaptative en fonction des temps de réponse.
+: **Type de métrique** : distribution
+
+`pipelines.adaptive_concurrency_in_flight`
+: **Description** : Le nombre de requêtes HTTP en cours vers une destination, comparé à la limite de concurrence adaptative pour déterminer quand effectuer une limitation.
+: **Type de métrique** : distribution
+
+`pipelines.adaptive_concurrency_reached_limit`
+: **Description** : Si le contrôleur de concurrence adaptative a atteint sa limite calculée (`1`) ou non (`0`) au cours du dernier intervalle de mesure.
+: **Type de métrique** : distribution
+
+`pipelines.adaptive_concurrency_back_pressure`
+: **Description** : Si le contrôleur de concurrence adaptative a détecté une contre-pression (`1`) ou non (`0`) au cours du dernier intervalle de mesure.
+: **Type de métrique** : distribution
+
+`pipelines.adaptive_concurrency_averaged_rtt`
+: **Description** : Le temps d'aller-retour (RTT) moyen lissé, en secondes, pour les requêtes HTTP vers cette destination, utilisé comme base de référence pour les calculs de concurrence adaptative.
+: **Type de métrique** : distribution
+
+`pipelines.adaptive_concurrency_observed_rtt`
+: **Description** : Le temps d'aller-retour (RTT), en secondes, observé pour la requête HTTP la plus récente vers cette destination.
+: **Type de métrique** : distribution
+
+`pipelines.adaptive_concurrency_past_rtt_mean`
+: **Description** : Le RTT moyen historique, en secondes, pour les requêtes HTTP vers cette destination, utilisé comme base de référence à long terme pour les ajustements de concurrence adaptative.
+: **Type de métrique** : distribution
+
+## Lectures complémentaires {#further-reading}
+
+{{< partial name="whats-next/whats-next.html" >}}
+
+[1]: /fr/getting_started/dashboards/
+[2]: /fr/notebooks/
+[3]: /fr/getting_started/monitors/
+[4]: /fr/getting_started/tagging/
+[5]: https://app.datadoghq.com/metric/summary
+[6]: https://docs.datadoghq.com/fr/account_management/billing/usage_metrics/
\ No newline at end of file
diff --git a/hugo/content/fr/observability_pipelines/monitoring_and_troubleshooting/worker_cli_commands.md b/hugo/content/fr/observability_pipelines/monitoring_and_troubleshooting/worker_cli_commands.md
new file mode 100644
index 00000000000..d30a86c86a2
--- /dev/null
+++ b/hugo/content/fr/observability_pipelines/monitoring_and_troubleshooting/worker_cli_commands.md
@@ -0,0 +1,49 @@
+---
+aliases:
+- /fr/observability_pipelines/install_the_worker/worker_commands/
+description: Trouvez les commandes et options run, tap et top pour l'interface de
+ ligne de commande de l'Observability Pipelines Worker.
+disable_toc: false
+further_reading:
+- link: observability_pipelines/configuration/install_the_worker/
+ tag: Documentation
+ text: Installez le Worker
+title: Commandes de l'interface de ligne de commande du Worker
+---
+## Exécutez les commandes run, tap et top sur le Worker{#run-tap-or-top-the-worker}
+
+Exemple d'utilisation : `observability-pipelines-worker `
+
+Si vous utilisez un environnement conteneurisé, utilisez la commande `docker exec` ou `kubectl exec` pour obtenir un shell dans le conteneur afin d'exécuter la commande. Exemple :
+
+- Pour Kubernetes : `kubectl exec -it -- observability-pipelines-worker `
+- Pour Docker : `docker exec -it observability-pipelines-worker `
+
+| Commande | Description |
+|-----------|-----------------------------------------------------------------------------------------------------------------------|
+| `run` | Exécutez l'Observability Pipelines Worker. |
+| `tap` | Utilisez la commande tap sur un pipeline pour observer les événements provenant des composants source ou transform. Consultez les [options de tap](#tap-options). |
+| `top` | Regroupe dans une liste les composants du pipeline et fournit des statistiques telles que les débits de données d'entrée et de sortie pour chaque composant. Saisissez `?` pour voir toutes les combinaisons de touches disponibles. |
+
+### Options de tap{#tap-options}
+
+Exemple d'utilisation : `observability-pipelines-worker tap `
+
+Vous pouvez utiliser la [`top`commande](#run-tap-or-top-the-worker) pour trouver l'ID du composant dans lequel vous souhaitez `tap`.
+
+| Options | Descriptions |
+|----------------------------------|----------------------------------------------------------------------------------------------------------------|
+| `-i`, `--interval ` | Intervalle d'échantillonnage des événements, en millisecondes (par défaut : `500`). |
+| `-u`, `--url ` | Endpoint du serveur d'API GraphQL. |
+| `-l`, `--limit ` | Nombre maximal d'événements à échantillonner par intervalle (par défaut : `100`). |
+| `-f`, `--format ` | Format d'encodage pour les événements affichés à l'écran.
par défaut : `json`
valeurs possibles : `json`, `yaml`, `logfmt` |
+| `--outputs-of ` | ID de source ou de processeur dont vous souhaitez observer les sorties (séparés par des virgules ; accepte les motifs glob). |
+| `--inputs-of ` | ID de processeur ou de destination dont vous souhaitez observer les entrées (séparés par des virgules ; accepte les motifs glob). |
+| `-q`, `--quiet` | La sortie silencieuse inclut uniquement les événements. |
+| `-m`, `--meta` | Inclure les métadonnées telles que l'ID du composant associé à l'événement.|
+| `-n`, `--no-reconnect` | Indique s'il faut se reconnecter si la connexion API sous-jacente est interrompue. Par défaut, `tap` tente de se reconnecter si la connexion est interrompue. |
+| `-d`, `--duration-ms ` | Spécifie une durée (en millisecondes) pour échantillonner les logs (par exemple, en spécifiant `10000`, le programme échantillonne les logs pendant 10 secondes puis se termine). |
+
+## Lectures complémentaires {#further-reading}
+
+{{< partial name="whats-next/whats-next.html" >}}
\ No newline at end of file
diff --git a/hugo/content/fr/observability_pipelines/packs/dns_stream.md b/hugo/content/fr/observability_pipelines/packs/dns_stream.md
new file mode 100644
index 00000000000..925e92713b3
--- /dev/null
+++ b/hugo/content/fr/observability_pipelines/packs/dns_stream.md
@@ -0,0 +1,15 @@
+---
+description: En savoir plus sur le pack DNS Stream.
+title: DNS Stream
+---
+## Présentation {#overview}
+
+{{< img src="observability_pipelines/packs/dns_stream.png" alt="Le pack DNS Stream" style="width:25%;" >}}
+
+Ce flux de requêtes/réponses DNS indépendant du fournisseur inclut des indicateurs de tunneling et de beaconing DGA.
+
+Ce que fait ce pack :
+
+- Analyse les requêtes et les réponses
+- Signale les indicateurs de tunneling
+- Échantillonne les requêtes propres
\ No newline at end of file
diff --git a/hugo/content/fr/observability_pipelines/packs/google_secops_aws_vpc.md b/hugo/content/fr/observability_pipelines/packs/google_secops_aws_vpc.md
new file mode 100644
index 00000000000..dc9cf53ad20
--- /dev/null
+++ b/hugo/content/fr/observability_pipelines/packs/google_secops_aws_vpc.md
@@ -0,0 +1,15 @@
+---
+description: En savoir plus sur le pack Google SecOps - AWS VPC.
+title: Google SecOps - AWS VPC
+---
+## Présentation {#overview}
+
+{{< img src="observability_pipelines/packs/google_secops_aws_vpc.png" alt="Le pack Google SecOps - AWS VPC" style="width:25%;" >}}
+
+Ce pack mappe les enregistrements de flux AWS VPC vers le schéma UDM dans Google Security Operations.
+
+Ce que fait ce pack :
+
+- Mappe les flux VPC vers l'UDM
+- Définit l'action à partir du verdict de flux VPC
+- Mappe les adresses IP, les octets et la ressource VPC
\ No newline at end of file
diff --git a/hugo/content/fr/observability_pipelines/packs/kube_proxy.md b/hugo/content/fr/observability_pipelines/packs/kube_proxy.md
new file mode 100644
index 00000000000..2681053324b
--- /dev/null
+++ b/hugo/content/fr/observability_pipelines/packs/kube_proxy.md
@@ -0,0 +1,15 @@
+---
+description: En savoir plus sur le pack Kube Proxy.
+title: Kube Proxy
+---
+## Présentation {#overview}
+
+{{< img src="observability_pipelines/packs/kube_proxy.png" alt="Le pack Kube Proxy" style="width:25%;" >}}
+
+Ce pack conserve uniquement les erreurs et les avertissements de kube-proxy, en éliminant le bruit de synchronisation iptables de routine généré à chaque cycle.
+
+Ce que fait ce pack :
+
+- Conserve les échecs de synchronisation
+- Élimine le bruit de synchronisation de routine
+- Extrait le niveau de journalisation
\ No newline at end of file
diff --git a/hugo/content/fr/observability_pipelines/packs/mitre_attack_aws_waf_enrichment.md b/hugo/content/fr/observability_pipelines/packs/mitre_attack_aws_waf_enrichment.md
new file mode 100644
index 00000000000..bb7f03a9919
--- /dev/null
+++ b/hugo/content/fr/observability_pipelines/packs/mitre_attack_aws_waf_enrichment.md
@@ -0,0 +1,15 @@
+---
+description: En savoir plus sur le pack d'enrichissement MITRE ATT&CK AWS WAF.
+title: MITRE ATT&CK AWS WAF Enrichment
+---
+## Présentation {#overview}
+
+{{< img src="observability_pipelines/packs/mitre_attack_aws_waf_enrichment.png" alt="Le pack d'enrichissement MITRE ATT&CK AWS WAF" style="width:25%;" >}}
+
+Ce pack marque les journaux AWS WAF avec des tactiques et techniques MITRE ATT&CK.
+
+Ce que fait ce pack :
+
+- Marque les événements avec des techniques MITRE
+- Associe les événements d'exploits, de brute force et de bot
+- Signale les événements comme pertinents pour la sécurité
\ No newline at end of file
diff --git a/hugo/content/fr/observability_pipelines/processors/sample.md b/hugo/content/fr/observability_pipelines/processors/sample.md
new file mode 100644
index 00000000000..9ff05040b66
--- /dev/null
+++ b/hugo/content/fr/observability_pipelines/processors/sample.md
@@ -0,0 +1,42 @@
+---
+disable_toc: false
+products:
+- icon: logs
+ name: Logs
+ url: /observability_pipelines/configuration/?tab=logs#pipeline-types
+title: Processeur d'échantillonnage
+---
+{{< product-availability >}}
+
+## Présentation {#overview}
+
+Ce processeur échantillonne vos logs pour obtenir un sous-ensemble représentatif au taux que vous définissez, en supprimant les événements restants. Par exemple, vous pouvez utiliser ce processeur pour échantillonner 20 % des événements provenant d'un service bruyant non critique.
+
+L'échantillonnage s'applique uniquement aux événements qui correspondent à votre requête de filtrage et n'a pas d'impact sur les autres événements. Si un événement est supprimé au niveau de ce processeur, il n'est pas envoyé aux processeurs suivants.
+
+## Configuration {#setup}
+
+Pour configurer le processeur d'échantillonnage :
+1. Définissez une {{< ui >}}filter query{{< /ui >}}. Consultez la [Syntaxe de recherche de logs][1] pour plus d'informations.
+ - Seuls les événements qui correspondent à la requête de filtrage spécifiée sont échantillonnés au taux de rétention spécifié.
+ - Les événements échantillonnés et les événements qui ne correspondent pas à la requête de filtrage sont envoyés à l'étape suivante du pipeline.
+1. Saisissez le taux d'échantillonnage souhaité dans le champ {{< ui >}}Retain{{< /ui >}}. Par exemple, saisir `2` signifie que 2 % des événements sont conservés parmi tous les événements qui correspondent à la requête de filtrage.
+1. Optionnellement, saisissez un champ {{< ui >}}Group By{{< /ui >}} pour créer des groupes d'échantillonnage distincts pour chaque valeur unique de ce champ. Par exemple, `status:error` et `status:info` sont deux valeurs de champ uniques. Chaque bucket d'événements avec le même champ est échantillonné indépendamment. Cliquez sur {{< ui >}}Add Field{{< /ui >}} si vous souhaitez ajouter d'autres champs pour le partitionnement. Consultez l'exemple [group-by](#group-by-example).
+
+### Group-by example {#group-by-example}
+
+Si vous disposez de la configuration suivante pour le processeur d'échantillonnage :
+- Requête de filtrage : `env:staging`
+- Conserver : `40%` des événements correspondants
+- Group by : `status` et `service`
+
+{{< img src="observability_pipelines/processors/group-by-example-service.png" alt="Le processeur d'échantillonnage avec des exemples de valeurs" style="width:40%;" >}}
+
+Ensuite, 40 % des événements pour chaque combinaison unique de `status` et `service` à partir de `env:staging` sont conservés. Exemple :
+
+- 40 % des événements avec `status:info` et `service:networks` sont conservés.
+- 40 % des événements avec `status:info` et `service:core-web` sont conservés.
+- 40 % des événements avec `status:error` et `service:networks` sont conservés.
+- 40 % des événements avec `status:error` et `service:core-web` sont conservés.
+
+[1]: /fr/observability_pipelines/search_syntax/logs/
\ No newline at end of file
diff --git a/hugo/content/fr/observability_pipelines/replay.md b/hugo/content/fr/observability_pipelines/replay.md
new file mode 100644
index 00000000000..7c7de716e74
--- /dev/null
+++ b/hugo/content/fr/observability_pipelines/replay.md
@@ -0,0 +1,65 @@
+---
+aliases:
+- /fr/observability_pipelines/rehydration/
+description: Découvrez comment utiliser Replay pour récupérer des logs archivés et
+ les traiter dans Observability Pipelines.
+disable_toc: false
+further_reading:
+- link: /observability_pipelines/processors/
+ tag: Documentation
+ text: En savoir plus sur les processeurs
+- link: /observability_pipelines/packs/
+ tag: Documentation
+ text: En savoir plus sur les Packs
+- link: https://www.datadoghq.com/blog/rehydrate-archived-logs-with-observability-pipelines
+ tag: Blog
+ text: Réhydratez les logs archivés dans n'importe quel SIEM ou fournisseur de journalisation
+ avec Observability Pipelines
+title: Replay
+---
+## Présentation {#overview}
+
+Replay pour Observability Pipelines vous permet d'extraire des logs archivés à partir d'un stockage d'objets et de les traiter dans Observability Pipelines, y compris avec des [Packs][1]. Cela vous donne un accès cohérent au contexte historique sans avoir à reconstruire des workflows ou à modifier les pipelines d'ingestion.
+
+Les organisations stockent souvent de grands volumes de logs dans des archives à long terme rentables pour contrôler les dépenses et répondre aux exigences de conformité. Cependant, les données historiques deviennent souvent difficiles d'accès en cas d'incident de sécurité, de demande d'audit ou d'enquête opérationnelle. La récupération de logs archivés depuis un stockage froid peut être lente, manuelle et perturbatrice, nécessitant des scripts ad hoc, une décompression ou un effort d'ingénierie dédié. Replay pour Observability Pipelines résout ces problèmes.
+
+{{< img src="observability_pipelines/replay_pipeline.png" alt="Un pipeline avec la source Replay Amazon S3." style="width:100%;" >}}
+
+## Fonctionnement de Replay {#how-replay-works}
+
+Replay fournit un workflow automatisé pour récupérer et retraiter les logs archivés stockés dans un stockage d'objets, tel qu'Amazon S3, Google Cloud Storage et Azure Blob Storage. Cela vous aide à équilibrer l'efficacité du stockage avec un accès rapide aux données historiques.
+
+Avec Replay, vous pouvez :
+
+### Récupérer des logs archivés à la demande {#retrieve-archived-logs-on-demand}
+
+Extraire uniquement les données dont vous avez besoin pour les enquêtes, les audits, le dépannage ou les tests de pipeline, et éliminer les longs délais de récupération et les étapes d'extraction manuelle.
+
+### Cibler des plages horaires ou des segments d'événements spécifiques {#target-specific-time-ranges-or-event-slices}
+
+Spécifiez la période exacte ou le sous-ensemble d'événements dont vous avez besoin pour éviter de déplacer ou de traiter des données inutilement.
+
+### Traiter les logs historiques avec Observability Pipelines {#process-historical-logs-with-observability-pipelines}
+
+Les logs rejoués passent par la même logique de parsing, d'enrichissement, de normalisation et de routage appliquée aux flux de logs en direct.
+
+Cela garantit :
+
+- Un formatage et une extraction de champs cohérents
+- Un enrichissement fiable (par exemple, métadonnées utilisateur, géo-IP et cloud)
+- Des contrôles de sécurité et de conformité uniformes
+- Un comportement identique pour les données historiques et en temps réel
+
+### Acheminez les données rejouées vers n'importe quelle destination prise en charge {#route-replayed-data-to-any-supported-destination}
+
+Vous pouvez envoyer les logs historiques traités vers des SIEM, des lacs de données, des plateformes d'analyse ou toute destination Observability Pipelines.
+
+### Éliminez la manipulation manuelle {#eliminate-manual-handling}
+
+Replay offre un moyen structuré et prévisible de réintégrer des données archivées dans votre plateforme d'observabilité, afin que vous n'ayez pas à utiliser de scripts personnalisés, de décompression manuelle ou de processus de récupération ad hoc.
+
+## Lectures complémentaires {#further-reading}
+
+{{< partial name="whats-next/whats-next.html" >}}
+
+[1]: /fr/observability_pipelines/packs/
\ No newline at end of file
diff --git a/hugo/content/fr/security/ai_guard/signals.md b/hugo/content/fr/security/ai_guard/signals.md
new file mode 100644
index 00000000000..c632f4d9e7a
--- /dev/null
+++ b/hugo/content/fr/security/ai_guard/signals.md
@@ -0,0 +1,148 @@
+---
+further_reading:
+- link: /security/ai_guard/
+ tag: Documentation
+ text: AI Guard
+- link: /security/ai_guard/onboarding/
+ tag: Documentation
+ text: Démarrez avec AI Guard
+- link: /security/detection_rules/
+ tag: Documentation
+ text: Règles de détection
+title: Signaux de sécurité AI Guard
+---
+{{< site-region region="gov" >}}AI Guard n'est pas disponible dans le {{< region-param key="dd_site_name" >}} site.
+{{< /site-region >}}
+
+Les signaux de sécurité AI Guard offrent une visibilité sur les menaces et les attaques qu'AI Guard détecte dans vos applications. Ces signaux sont construits sur les [signaux de sécurité AAP (Application and API Protection)][1] et s'intègrent aux workflows de surveillance de la sécurité de Datadog.
+
+## Comprendre les signaux AI Guard {#understand-ai-guard-signals}
+
+Datadog crée des signaux de sécurité AI Guard lorsqu'il détecte une menace basée sur une règle de détection configurée. Les signaux indiquant des menaces telles que l'injection de prompt, le jailbreak ou l'utilisation abusive d'outils apparaissent dans Datadog Security Signals Explorer. Ces signaux peuvent fournir :
+
+- **Détection des menaces** : Contexte de l'attaque basé sur vos règles de détection configurées
+- **Informations sur les actions** : Informations sur les actions bloquées ou autorisées selon les paramètres de vos règles
+- **Contexte d'investigation riche** : Catégories d'attaques détectées, résultats de l'évaluation AI Guard et liens vers les spans AI Guard associés pour une analyse complète
+- **Runbooks personnalisés** : Conseils de remédiation et procédures de réponse personnalisés pour des scénarios de menace spécifiques
+
+Pour vous aider à prioriser vos efforts de remédiation, AI Guard attribue automatiquement un niveau de gravité à chaque signal de sécurité. Vous pouvez créer des [règles de détection personnalisées](#create-detection-rules) pour personnaliser les niveaux de gravité et définir des réponses de sécurité spécifiques.
+
+## Créer des règles de détection {#create-detection-rules}
+
+Vous pouvez créer des règles de détection personnalisées en définissant des seuils pour le moment où vous souhaitez recevoir des notifications ; par exemple, plus de 5 `DENY` actions en 10 minutes. Lorsque les évaluations AI Guard dépassent ces seuils, il génère des signaux de sécurité.
+
+Pour créer des règles de détection AI Guard :
+1. Dans Datadog, accédez à [AI Guard Detection Rules Explorer][2], puis cliquez sur {{< ui >}}New Rule{{< /ui >}}.
+ {{< img src="security/ai_guard/ai_guard_detection_rules_1.png" alt="AI Guard Detection Rules Explorer" style="width:100%;" >}}
+1. Sous {{< ui >}}Define your Real-time rule{{< /ui >}}, choisissez le type de règle à créer.
+1. Sous {{< ui >}}Define Search Queries{{< /ui >}}, définissez les types de tags pour lesquels vous souhaitez créer des signaux. Vous pouvez utiliser les attributs AI Guard suivants pour filtrer et cibler des modèles de menace spécifiques :
+
+
+
+ | Tag |
+ Description |
+ Valeurs possibles |
+
+
+
+
+ @ai_guard.action |
+ Filtrer par résultat d'évaluation d'AI Guard |
+ ALLOW ou DENY |
+
+
+ @ai_guard.attack_categories |
+ Cibler des types d'attaques spécifiques |
+
+
+ jailbreakindirect-prompt-injectiondestructive-tool-calldenial-of-service-tool-callsecurity-exploitauthority-overriderole-playinstruction-overrideobfuscationsystem-prompt-extractiondata-exfiltration
+ |
+
+
+ @ai_guard.blocked |
+ Filtrer selon qu'une action dans la trace a été bloquée ou non |
+ true ou false |
+
+
+ @ai_guard.tools |
+ Filtrer par noms d'outils spécifiques impliqués dans l'évaluation |
+ get_user_profile, user_recent_transactions, etc. |
+
+
+ @ai_guard.sds.categories |
+ Filtrer par catégories de données sensibles détectées par le Sensitive Data Scanner |
+ credentials, email_address, etc. |
+
+
+ @ai_guard.sds.rule_tags |
+ Filtrer par tags de règle de données sensibles spécifiques |
+ aws_access_key_id, aws_secret_access_key, claude_api_key, email_address, etc. |
+
+
+
+1. Sous {{< ui >}}Define Rule Conditions{{< /ui >}} :
+ 1. Définissez vos conditions de seuil, le cas échéant pour le type de règle que vous avez choisi.
+ 1. Définissez le niveau de gravité des signaux de sécurité générés par AI Guard avec cette règle.
+ 1. Choisissez qui doit recevoir des notifications pour les nouveaux signaux et à quelle fréquence.
+ 1. Choisissez les réponses de sécurité à adopter, telles que le blocage automatisé des adresses IP ou des utilisateurs, et le marquage des adresses IP.
+ 1. Configurez des paramètres supplémentaires, tels que la mise à jour du même signal au lieu d'en créer un nouveau si AI Guard détecte de nouvelles valeurs dans un laps de temps défini, et la diminution de la gravité des signaux pour les environnements hors production.
+1. Sous {{< ui >}}Describe your Playbook{{< /ui >}}, personnalisez la notification et définissez les tags à envoyer avec les signaux.
+1. Cliquez sur {{< ui >}}Save Rule{{< /ui >}}.
+
+Pour des capacités de règles de détection plus complètes, consultez [règles de détection][3].
+
+## Étudiez les signaux {#investigate-signals}
+
+Pour afficher et étudier les signaux de sécurité AI Guard, et les corréler avec d'autres événements de sécurité, vous pouvez consulter les signaux à deux endroits :
+- [Application and API Protection Security Signals explorer][4]
+- [Cloud SIEM Security Signals Explorer][5]
+
+ Dans Cloud SIEM Security Signals Explorer, à côté de la barre de recherche, cliquez sur l'icône {{< ui >}}Filter{{< /ui >}} et cochez la case {{< ui >}}App & API Protection{{< /ui >}} pour afficher les signaux AI Guard.
+
+Les Security Signals Explorers vous permettent de filtrer, de hiérarchiser et d'étudier les signaux AI Guard parallèlement à d'autres menaces de sécurité des applications, offrant ainsi une vue unifiée de votre posture de sécurité.
+
+Vous pouvez créer ou lier des cas directement à partir d'un signal de sécurité AI Guard, et cliquer sur n'importe quel signal pour ouvrir un panneau latéral contenant des informations contextuelles supplémentaires.
+
+## Obtenez un contexte supplémentaire avec les spans {#get-additional-context-with-spans}
+
+Les spans AI Guard offrent des informations détaillées sur les évaluations effectuées et leurs raisons. Lorsque vous ouvrez un span depuis la page [Investigate][6] ou depuis un signal, vous pouvez obtenir du contexte sur les prompts spécifiques utilisés par votre agent AI, lire les entrées et sorties exactes, et voir toutes les catégories d'attaques ayant contribué à ce qu'AI Guard évalue un appel d'outil comme non sécurisé.
+
+### Obtenez du contexte sur un span {#get-context-on-a-span}
+
+Lorsque vous cliquez sur un span dans l'Explorer, vous pouvez voir :
+- Le service et l'environnement dans lesquels les requêtes se sont produites
+- La [politique de blocage][7] configurée pour ce service, qui détermine si AI Guard bloque les requêtes non sécurisées, ou les détecte et les tague sans les bloquer
+- L'utilisateur qui a interagi avec l'agent
+- Les entrées et sorties spécifiques de votre agent, et si elles proviennent de LLMs ou d'outils externes
+- Si AI Guard a évalué chaque requête comme sûre ou non sûre
+- Si AI Guard a bloqué la requête
+- Si AI Guard a évalué l'appel comme non sûr, quelles catégories d'attaque il incluait
+- Si la requête incluait des données sensibles, et si tel est le cas, quel type de données sensibles
+- Tags supplémentaires, que vous pouvez utiliser pour filtrer les spans dans l'Explorer
+
+De plus, vous pouvez cliquer sur {{< ui >}}Explore in graph view{{< /ui >}} pour voir les requêtes de la conversation sous forme de graphique, ou afficher le span dans [APM][8] ou [Agent Observability][9].
+
+## Lectures complémentaires {#further-reading}
+
+{{< partial name="whats-next/whats-next.html" >}}
+
+[1]: /fr/security/application_security/security_signals/
+[2]: https://app.datadoghq.com/security/ai-guard/settings/detection-rules
+[3]: /fr/security/detection_rules/
+[4]: https://app.datadoghq.com/security/ai-guard/signals
+[5]: https://app.datadoghq.com/security/siem/signals
+[6]: https://app.datadoghq.com/security/ai-guard/investigate
+[7]: /fr/security/ai_guard/setup/#blocking-policy
+[8]: /fr/tracing/
+[9]: /fr/llm_observability/
\ No newline at end of file
diff --git a/hugo/content/fr/synthetics/browser_tests/test_results.md b/hugo/content/fr/synthetics/browser_tests/test_results.md
index 7968e3529cd..b964967dbf6 100644
--- a/hugo/content/fr/synthetics/browser_tests/test_results.md
+++ b/hugo/content/fr/synthetics/browser_tests/test_results.md
@@ -1,151 +1,252 @@
---
aliases:
- /fr/synthetics/apm/browser_tests
-description: Résultats des tests Browser Synthetic
+description: Consultez les résultats des tests de navigateur synthétiques et comparez
+ les exécutions d'échantillons réussies ou échouées aux exécutions de test.
further_reading:
+- link: /synthetics/guide/explore-rum-through-synthetics/
+ tag: Documentation
+ text: Explorer des données RUM et Session Replay dans Synthetics
+- link: /synthetics/dashboards/browser_test/
+ tag: Documentation
+ text: Découvrez le dashboard des performances des tests de navigateur
+- link: https://learn.datadoghq.com/courses/getting-started-with-synthetic-browser-testing
+ tag: Centre d'apprentissage
+ text: Premiers pas avec Synthetic Monitoring et les tests de navigateur
- link: https://www.datadoghq.com/blog/core-web-vitals-monitoring-datadog-rum-synthetics/#what-are-the-core-web-vitals
tag: Blog
- text: Surveiller les signaux Web essentiels avec la surveillance Synthetic
-title: Résultats de tests Browser
+ text: Surveiller les signaux Web essentiels avec Synthetic Monitoring
+- link: https://www.datadoghq.com/blog/bits-investigation-synthetic-tests/
+ tag: Blog
+ text: Diagnostiquez plus rapidement les échecs de tests Synthetic avec Bits Investigation
+title: Résultats des tests de navigateurs
---
+## Présentation {#overview}
+
+La page des détails du test s'ouvre après l'exécution d'un test de navigateur synthétique et est organisée en quatre onglets: [{{< ui >}}Activity{{< /ui >}}](#test-activity), [{{< ui >}}Test Runs{{< /ui >}}](#test-runs), [{{< ui >}}Performance{{< /ui >}}](#test-performance) et [{{< ui >}}Properties{{< /ui >}}](#test-properties). Utilisez ces onglets pour surveiller la disponibilité, inspecter les exécutions individuelles, examiner les métriques de performance globales et gérer la configuration des tests. Lorsqu'une exécution échoue, consultez [Résultats échoués](#failed-results) pour obtenir des outils de dépannage tels que des résumés d'échec par IA et une comparaison de captures d'écran.
+
+## Activité du test {#test-activity}
+
+Dans l'onglet {{< ui >}}Activity{{< /ui >}}, vous pouvez voir:
+
+- Le graphique {{< ui >}}Global Uptime{{< /ui >}}, qui affiche la disponibilité totale de tous les emplacements de test sur un intervalle de temps donné. La visualisation de la disponibilité globale ne s'affiche en rouge que si les [conditions d'alerte][20] configurées pour un test sont déclenchées dans l'intervalle de temps donné. Étant donné que la disponibilité par emplacement est calculée en fonction du résultat final du test une fois les nouvelles tentatives terminées, les intervalles de [nouvelle tentative rapide][24] ont un impact direct sur ce qui apparaît dans votre graphique de disponibilité totale. Pour plus d'informations sur la surveillance de la disponibilité, consultez le guide [Surveillance de la disponibilité des sites Web avec des SLO][14].
+- Une {{< ui >}}Timeline{{< /ui >}} des déclenchements d'alerte, des rétablissements et des modifications de test.
+- Un panneau {{< ui >}}Summary{{< /ui >}} pour l'événement de chronologie sélectionné, montrant ce qui s'est passé, le résultat de l'échec et les prochaines étapes suggérées pour l'investigation.
+
+{{< img src="synthetics/browser_tests/synthetics_bits_investigation.png" alt="L'onglet Activité sur une page Détails du test de navigateur montrant la disponibilité globale, la chronologie des alertes et un panneau de détails d'échec avec Bits Investigation." style="width:100%;" >}}
-Les résultats des tests s'affichent après l'exécution d'un test Synthetic Datadog. Les résultats de tests Browser découlent de l'exécution de tests à un moment précis, avec un emplacement, un navigateur et un type d'appareil spécifiques.
+## Exécutions de test {#test-runs}
-La section **Sample Results** vous permet de comparer des exécutions récentes de test qui ont échoué et qui ont réussi. Faites défiler la page vers le bas jusqu'à atteindre la section **Test Results**, puis cliquez sur un résultat de test pour examiner ses détails.
+Dans l'onglet {{< ui >}}Test Runs{{< /ui >}}, vous pouvez voir toutes les exécutions individuelles de votre test. Filtrez par statut (réussi ou échoué), type d'exécution, emplacement ou appareil, et cliquez sur n'importe quelle ligne pour inspecter cette exécution en détail.
-Les [résultats des tests Browser](#resultats-des-tests) comprennent plusieurs éléments, notamment des [captures d'écran](#captures-d-ecran), des [données de performance des pages](#performances-des-pages), des [erreurs](#erreurs), des [ressources](#ressources) et des [traces backend](#traces-backend), afin que vous puissiez découvrir pourquoi [certains tests échouent](#resultat-d-un-test-ayant-echoue).
+{{< img src="synthetics/browser_tests/synthetics_test_runs.png" alt="L'onglet Exécutions de test sur une page Détails du test de navigateur affichant un tableau filtrable des exécutions de test avec des colonnes pour le statut, la date, le type d'exécution, les étapes, la durée, l'emplacement, l'appareil, le navigateur et la version du test." style="width:100%" >}}
-## Résultats des tests
+Les exécutions de test de navigateur incluent des composants tels que [des captures d'écran](#screenshots-and-actions), [des données de performance de page](#test-performance), [des erreurs](#errors-and-warnings), [des ressources](#resources) et [des traces backend](#backend-traces) pour vous aider à résoudre votre [échec de test](#failed-results).
-Les informations suivantes s'affichent en haut de chaque résultat de test Browser :
+{{% collapse-content title="Colonnes d'exécution de test" level="h3" %}}
+
+Ce qui suit décrit chaque colonne du tableau {{< ui >}}Test Runs{{< /ui >}}:
Status
-: Le statut du résultat de votre test (Alert ou OK).
+: Le statut de l'exécution du test (`PASSED` ou `FAILED`).
+
+Date
+: Le temps relatif et l'horodatage auxquels l'exécution a eu lieu.
-Starting URL
-: L'URL de votre scénario de test Browser.
+Type d'exécution
+: Le type d'exécution de test (planifiée, CI ou déclenchée manuellement).
-Completed steps
-: Le nombre d'étapes effectuées durant le test.
+Étapes
+: Le nombre d'étapes de test terminées sur le total configuré pour l'exécution.
Duration
-: La durée d'exécution du test.
+: La durée nécessaire à l'exécution du test pour se terminer.
-Location
-: L'emplacement géré ou privé à partir duquel votre test a été exécuté.
+Région
+: L'emplacement géré ou privé à partir duquel le test a été exécuté.
-Device
-: Le type d'appareil à partir duquel votre test a été exécuté.
+Appareil
+: Le type d'appareil à partir duquel le test a été exécuté.
Browser
-: Le type de navigateur à partir duquel votre test a été exécuté.
-
-Time ran
-: L'heure à laquelle votre test a été effectué.
+: Le type de navigateur à partir duquel le test a été exécuté.
-Run type
-: Le type de votre exécution de test (CI, nouvelle tentative rapide, déclenchement manuel ou programmé).
+Version du test
+: La version de la configuration de test utilisée pour l'exécution.
-### Captures d'écran
+{{% /collapse-content %}}
-Les tests Browser contiennent des captures d'écran pour chaque étape de test exécutée. Ces captures vous permettent de visualiser le parcours de votre test Browser.
+### Sessions RUM {#rum-sessions}
-### Performances des pages
+Pour afficher les sessions associées et les replays disponibles dans le [RUM Explorer][22], cliquez sur {{< ui >}}View Session in RUM{{< /ui >}}. Pour accéder à une session utilisateur pour une action ou une étape particulière dans [Session Replay][23], cliquez sur {{< ui >}}Replay Session{{< /ui >}}. Pour plus d'informations, consultez [Explorer RUM et Session Replay dans Synthetic Monitoring][16].
-Chaque étape impliquant le chargement complet d'une URL contient des informations sur les performances de la page.
+### Captures d'écran et actions {#screenshots-and-actions}
-#### Expérience utilisateur
+Chaque étape de test exécutée contient une capture d'écran de l'action de l'étape, un lien vers la session dans Session Replay, la description de l'étape, l'URL de départ pour une étape donnée, l'ID de l'étape, la durée de l'étape et des informations sur les performances de la page.
-Les [signaux Web essentiels de Google][1] désignent trois métriques visant à surveiller l'expérience utilisateur d'un site. Ces métriques sont conçues pour vous offrir une vue globale des performances de chargement, de l'interactivité et de la stabilité visuelle. Une plage de valeurs correspondant à une expérience utilisateur acceptable est fournie pour chaque métrique.
+### Erreurs et avertissements {#errors-and-warnings}
-La surveillance Synthetic inclut deux métriques expérimentales : [Largest Contentful Paint][2] et [Cumulative Layout Shift][3].
+Cliquez sur la pastille {{< ui >}}Errors{{< /ui >}} pour accéder à l'onglet {{< ui >}}Errors & Warnings{{< /ui >}} et examiner une liste d'erreurs séparées par type d'erreur (`js` ou `network`) et par statut (le code d'état réseau).
-La métrique [First Input Delay][4] est disponible avec la solution RUM (Real User Monitoring), dès lors que les données sur les utilisateurs réels ou les champs sont disponibles.
+{{< img src="synthetics/browser_tests/test_results/synthetics_errors.png" alt="Détails de l'exécution du test de navigateur avec la pastille Erreurs mise en évidence sur chaque étape, indiquant où cliquer pour ouvrir l'onglet Erreurs et avertissements" style="width:100%" >}}
-En savoir plus sur la [solution RUM et sur les signaux Web essentiels][5].
+L'onglet {{< ui >}}Errors & Warnings{{< /ui >}} affiche une liste d'erreurs séparées par type d'erreur (`js` ou `network`) et par statut (le code d'état réseau).
-{{< img src="real_user_monitoring/browser/core-web-vitals.png" alt="Visualisation de la synthèse des signaux Web essentiels" >}}
+Le type d'erreur est consigné lorsque le test de navigateur interagit avec la page. Il correspond aux erreurs collectées entre le moment où la page est ouverte et le moment où il est possible d'interagir avec la page. Le nombre maximal d'erreurs pouvant être affichées est de 8, par exemple : 2 `network` + 6 `js` erreurs.
-### Erreurs
+### Ressources {#resources}
-Le volet **Errors** affiche l'erreur, son type (`js` ou `network`) et son statut (code de statut réseau).
+Cliquez sur la pastille {{< ui >}}Resources{{< /ui >}} pour accéder à l'onglet {{< ui >}}Resources{{< /ui >}} et examiner la combinaison de requêtes et de ressources, y compris la durée totale de l'étape sous {{< ui >}}Fully Loaded{{< /ui >}} et le fournisseur CDN qui dessert les ressources.
-Le type d'erreur est enregistré lors de l'interaction avec la page. Il correspond aux erreurs recueillies entre l'ouverture de la page et l'interaction avec cette page.
+{{< img src="synthetics/browser_tests/test_results/synthetics_resources.png" alt="Détails de l'exécution du test de navigateur avec la pastille Ressources mise en évidence sur chaque étape, indiquant où cliquer pour ouvrir l'onglet Ressources" style="width:100%" >}}
-Un maximum de 8 erreurs peuvent être affichées, par exemple 2 `network` + 6 `js`.
+Vous pouvez filtrer les ressources par type et effectuer une recherche par nom dans la barre de recherche. Le nombre maximal de ressources pouvant être affichées est de 100. Les ressources sont classées par heure de début et les 100 premières sont affichées dans Datadog.
-### Ressources
+{{% collapse-content title="Colonnes de l'onglet Ressources" level="h4" %}}
-Une ressource correspond à une combinaison de requêtes et d'assets.
+Ce qui suit décrit les en-têtes de colonne de l'onglet {{< ui >}}Resources{{< /ui >}} :
-{{< img src="synthetics/browser_tests/resources_panel.png" alt="Volet Resources" >}}
+Temps relatif
+: Le moment où la ressource a commencé à se charger pendant l'étape de test.
-Les éléments suivants se trouvent au-dessus de l'onglet Resources :
-- La durée totale de l'étape
-- Les fournisseurs CDN à l'origine des ressources, avec un résumé du statut du cache pour chacune d'elles
-
-L'onglet **Resources** inclut les éléments suivants :
+CDN
+: Le fournisseur CDN qui a servi la ressource. Survolez l'icône d'un fournisseur CDN pour voir l'état brut du cache.
+Datadog détecte Akamai, Cloudflare, Fastly, Amazon Cloudfront, Netlify, Google Cloud CDN, Imperva et Sucuri.
Resource
: L'URL de la ressource.
-CDN
-: Le fournisseur CDN à l'origine de la ressource. Lorsque vous passez le curseur sur cette valeur, le statut du cache brut s'affiche.
-Datadog détecte les fournisseurs Akamai, Cloudflare, Fastly, Amazon Cloudfront, Netlify, Google Cloud CDN, Imperva et Sucuri.
-
Type
-: Le type de ressource (HTML, CSS, Image, Javascript, XHR ou Other).
+: Le type de ressource (HTML, Téléchargement, CSS, Fetch, Image, JavaScript, XHR ou Autre).
+
+Méthode
+: La méthode de la requête.
+
+Protocole
+: Le protocole de la requête.
Status
-: Le code de statut de la réponse HTTP.
+: Le code d'état de la réponse HTTP.
Duration
: Le temps nécessaire pour effectuer la requête.
-% Total Time
-: La durée de la ressource par rapport à la durée totale de l'interaction.
-
Size
: La taille de la réponse de la requête.
-Vous pouvez consulter jusqu'à 100 ressources. Les ressources sont triées en fonction de l'heure à laquelle elles commencent. Seules les 100 premières ressources sont affichées dans Datadog.
+{{% /collapse-content %}}
+
+Pour les ressources Fetch et XHR, cliquez sur une ligne de ressource pour afficher ses en-têtes et son corps de requête et de réponse. Les détails de la charge utile ne sont disponibles que lorsque {{< ui >}}Capture HTTP payloads{{< /ui >}} est activé dans les [options avancées][28] du test.
+
+### Traces backend {#backend-traces}
+
+Cliquez sur la pastille {{< ui >}}Traces{{< /ui >}} pour accéder à l'onglet {{< ui >}}Traces{{< /ui >}} et explorer les traces APM associées au test de navigateur. Bien que l'interface utilisateur soit similaire à la [Vue des traces][7] dans le Trace Explorer, une étape de test de navigateur peut effectuer plusieurs requêtes vers différentes URL ou différents endpoints. Cela entraîne plusieurs traces associées, en fonction de votre configuration de traçage et des URL que vous avez autorisées pour les tests de navigateur sur la [page Paramètres de Synthetic Monitoring][8].
+
+Pour plus d'informations sur la corrélation entre les produits, consultez le guide [Facilitez le dépannage grâce à la corrélation entre les produits][21].
+
+### Durée de l'étape {#step-duration}
+
+La durée de l'étape représente le temps nécessaire pour qu'une étape soit considérée comme entièrement chargée en utilisant le [système de localisation Datadog][9]. Pour plus d'informations, consultez [Comment la durée de l'étape est déterminée dans les tests de navigateur][25].
+
+Si votre test atteint le temps d'exécution maximal, le message de délai d'attente indique que la durée totale inclut à la fois les étapes du test et la surcharge du système. Par conséquent, la durée de test rapportée peut différer de la somme des durées des étapes individuelles.
+
+{{< img src="synthetics/browser_tests/test_results/test_execution_error.png" alt="Message d'erreur de durée d'exécution du test indiquant « Temps d'exécution maximal du test atteint. Cela inclut les étapes de test et la surcharge du système, de sorte que les durées de test rapportées peuvent varier. »" style="width:90%;" >}}
-#### Filtre et recherche
+## Performances du test{#test-performance}
-Les ressources peuvent être filtrées par type. Il est également possible d'effectuer une recherche sur les URL affichées.
+Sur l'onglet {{< ui >}}Performance{{< /ui >}}, vous pouvez voir les métriques de performance globales sur toutes les exécutions de votre test :
-### Traces backend
+Cartes - **Taux de réussite du navigateur** pour chaque type de navigateur (Chrome, Firefox, Edge), affichant le pourcentage d'exécutions réussies dans l'intervalle de temps sélectionné.
+Graphiques - **Durée moyenne du test par type de navigateur** et **Durée moyenne du test par emplacement et appareil**, qui affichent le temps que chaque navigateur, emplacement et appareil prend pour terminer le test dans un intervalle de temps donné.
+Graphiques - **p75 Largest Contentful Paint** et **p75 Cumulative Layout Shift**, qui affichent le 75e percentile de ces [métriques Core Web Vital][6] agrégés sur les exécutions.
-Le volet de traces affiche les traces associées au test Browser Synthetic. L'interface est semblable à la [vue Trace][6] de l'APM, à quelques exceptions près.
+{{< img src="synthetics/browser_tests/synthetics_browser_graphs.png" alt="L'onglet Performances sur une page Détails du test de navigateur affichant les taux de réussite de Chrome, Firefox et Edge, les graphiques de durée de test par type de navigateur et emplacement, ainsi que les métriques Core Web Vital p75 LCP et CLS" style="width=80%" >}}
-Une étape Browser peut effectuer plusieurs requêtes sur des URL ou des endpoints distincts, ce qui génère plusieurs traces connexes (en fonction de la configuration du tracing et des URL autorisées dans vos [paramètres][7]). Utilisez le menu déroulant pour choisir la trace à afficher.
+Au sein d'une exécution de test individuelle, le [Largest Contentful Paint][2] et le [Cumulative Layout Shift][3] sont affichés sous forme de pastilles à droite de l'URL de chaque étape. Le [First Input Delay][4] est disponible en tant que métrique réelle si vous utilisez le [Real User Monitoring][5] pour collecter des données utilisateur réelles. Pour plus d'informations, consultez [Monitoring Page Performance][6].
-### Durée d'une l'étape
+{{< img src="synthetics/browser_tests/test_results/page_performance_lab_metrics.png" alt="Métriques de laboratoire synthétiques" style="width:100%" >}}
-La durée d'une l'étape correspond au temps consacré à son exécution avec notre [algorithme de localisation][8]. Elle inclut non seulement l'action concernée (comme une interaction utilisateur), mais également le mécanisme d'attente et de nouvelle tentative. Les tests Browser peuvent donc vérifier qu'un élément peut faire l'objet d'une interaction.
+## Propriétés du test{#test-properties}
-## Résultat d'un test ayant échoué
+L'onglet {{< ui >}}Properties{{< /ui >}} contient les détails de configuration, les informations de propriété et les intégrations associées à votre test. Utilisez la navigation de gauche pour basculer entre les sections.
-Un résultat de test est considéré comme un échec (`FAILED`) s'il ne respecte pas ses assertions ou si une étape échoue pour une autre raison. Vous pouvez résoudre les échecs d'exécution en étudiant les captures d'écran correspondants, en vérifiant les éventuelles [erreurs](#erreurs) au niveau de l'étape et en examinant les [traces backend](#traces-backend) générées par les étapes.
+{{< img src="synthetics/browser_tests/synthetics_properties_tab.png" alt="L'onglet Propriétés sur une page Détails du test de navigateur affichant les sections Propriété, Exécution et Monitor, avec une navigation à gauche pour les configurations Continuous Testing, Parent Tests et autres" style="width=80%" >}}
-Voici la liste des erreurs les plus courantes pour les tests Browser :
+{{% collapse-content title="Sections de l'onglet Propriétés" level="h3" %}}
+
+Ce qui suit décrit chaque section disponible sur l'onglet {{< ui >}}Properties{{< /ui >}} :
+
+{{< ui >}}Ownership{{< /ui >}}
+: Affiche le propriétaire du test, l'éditeur, la date de création, la date de dernière modification, les environnements, les équipes et les tags. Les tests renvoient également à un [dashboard de test de navigateur][11] synthétique prêt à l'emploi.
+
+{{< ui >}}Execution{{< /ui >}}
+: Affiche la fréquence de test, les conditions d'alerte et le comportement de nouvelle tentative.
+
+{{< ui >}}Monitor{{< /ui >}}
+: Contient le nom du [monitor de test Synthetic][13], la priorité, les destinataires configurés et le message de notification.
+
+{{< ui >}}Continuous Testing{{< /ui >}}
+: Définit la [règle d'exécution][12] utilisée lorsque ce test s'exécute dans le cadre d'un [pipeline Continuous Testing CI][19].
+
+{{< ui >}}Parent Tests{{< /ui >}}
+: Répertorie les tests qui font référence à ce test, tels que les tests multi-étapes qui l'incluent en tant que sous-test.
+
+{{< ui >}}Parent Suites{{< /ui >}}
+: Répertorie les [suites de tests][26] auxquelles ce test appartient.
+
+{{< ui >}}Downtimes{{< /ui >}}
+: Répertorie les [indisponibilités planifiées][27] qui suspendent l'exécution de ce test, par exemple pendant les fenêtres de maintenance planifiée.
+
+{{< ui >}}Configuration as Code{{< /ui >}}
+: Exporte la configuration de test dans des formats tels que Terraform pour gérer les tests en tant que code.
+
+{{% /collapse-content %}}
+
+## Résultats ayant échoué {#failed-results}
+
+Un résultat de test est considéré comme `FAILED` s'il ne satisfait pas ses assertions ou si une étape a échoué pour une autre raison. Vous pouvez résoudre les exécutions ayant échoué en examinant leurs captures d'écran, en vérifiant les [erreurs](#errors-and-warnings) potentielles au niveau de l'étape et en consultant les [ressources][17] et les [traces backend](#backend-traces) générées par leurs étapes.
+
+### Résumés d'échec par IA {#ai-failure-summaries}
+
+Lorsqu'une exécution de test de navigateur échoue, Datadog génère un résumé d'échec par IA pour vous aider à identifier la cause et les prochaines étapes de l'investigation. Chaque résumé comprend :
+
+- Une brève explication de ce qui a échoué, basée sur les données d'exécution telles que les erreurs réseau, les assertions et les captures d'écran.
+- Une classification de l'échec en tant que **véritable échec** (un problème réel avec votre application) ou **mauvaise configuration de test** (un problème avec la configuration du test).
+- Prochaines étapes suggérées pour le dépannage.
+
+Les résumés d'échec par IA apparaissent sur la page des détails d'exécution de test pour toute exécution de test de navigateur ayant échoué. Considérez-les comme un point de départ pour l'investigation, et non comme une analyse de cause racine faisant autorité, car le contenu généré par LLM peut contenir des inexactitudes. Utilisez les boutons 👍 et 👎 sur le résumé pour partager vos commentaires et aider à améliorer les résultats futurs.
+
+{{< img src="synthetics/browser_tests/test_results/synthetics_ai_summaries_new.png" alt="Panneau de résumé d'échec par IA sur une exécution de test de navigateur ayant échoué" style="width:100%" >}}
+
+### Comparer les captures d'écran {#compare-screenshots}
+
+Pour vous aider lors de l'investigation, cliquez sur {{< ui >}}Compare Screenshots{{< /ui >}} pour recevoir des captures d'écran côte à côte du résultat ayant échoué et de la dernière exécution réussie. La comparaison vous aide à repérer les différences qui auraient pu causer l'échec du test.
+
+{{< img src="synthetics/browser_tests/test_results/compare_screenshots.png" alt="Comparer les captures d'écran entre vos exécutions ayant échoué et celles ayant réussi" style="width:90%;" >}}
+
+**Remarque**: La comparaison est effectuée entre deux exécutions de test ayant la même version, la même URL de départ, le même appareil, le même navigateur et le même type d'exécution (planifiée, déclenchement manuel, CI/CD). S'il n'y a pas d'exécution réussie antérieure avec les mêmes paramètres, aucune comparaison n'est proposée.
+### Erreurs courantes de test de navigateur {#common-browser-test-errors}
`Element located but it's invisible`
-: L'élément est présent sur la page, mais il n'est pas possible de cliquer dessus (parce qu'un autre élément est superposé par-dessus, par exemple).
+: L'élément est sur la page mais ne peut pas être cliqué — par exemple, si un autre élément est superposé par-dessus.
`Cannot locate element`
-: L'élément est introuvable sur la page HTML.
+: L'élément est introuvable dans le HTML.
`Select did not have option`
-: L'option spécifiée ne figure pas dans le menu déroulant.
+: L'option spécifiée est absente du menu déroulant.
`Forbidden URL`
-: Le test a probablement rencontré un protocole non pris en charge. Contactez l'[assistance Datadog][9] pour en savoir plus.
+: Le test a probablement rencontré un protocole non pris en charge. [Contactez le support][10] pour plus de détails.
`General test failure`
-: Message d'erreur général. [Contactez l'assistance][9] pour en savoir plus.
+: Un message d'erreur général. [Contactez le support][10] pour plus de détails.
+
+## Événements de test {#test-events}
+
+Les alertes de vos monitors de test Synthetic apparaissent sur la chronologie dans l'onglet [{{< ui >}}Activity{{< /ui >}}](#test-activity), où vous pouvez examiner les déclenchements d'alerte, les rétablissements et les modifications de test parallèlement au graphique de disponibilité global. Pour rechercher des alertes provenant de tests Synthetic dans Events Explorer, accédez à [{{< ui >}}Events{{< /ui >}} > {{< ui >}}Explorer{{< /ui >}}][18] et saisissez `@evt.type:synthetics_alert` dans la requête de recherche. Pour en savoir plus, consultez la section [Utiliser des monitors de test Synthetic][13].
-## Pour aller plus loin
+## Pour aller plus loin {#further-reading}
{{< partial name="whats-next/whats-next.html" >}}
@@ -153,8 +254,27 @@ Voici la liste des erreurs les plus courantes pour les tests Browser :
[2]: https://web.dev/lcp/
[3]: https://web.dev/cls/
[4]: https://web.dev/fid/
-[5]: /fr/real_user_monitoring/browser/monitoring_page_performance/#core-web-vitals
-[6]: /fr/tracing/visualization/trace/
-[7]: /fr/synthetics/settings/?tab=specifyvalue#apm-integration-for-browser-tests
-[8]: /fr/synthetics/guide/browser-test-self-maintenance/
-[9]: /fr/help/
\ No newline at end of file
+[5]: /fr/real_user_monitoring/
+[6]: /fr/real_user_monitoring/application_monitoring/browser/monitoring_page_performance/#event-timings-and-core-web-vitals
+[7]: /fr/tracing/trace_explorer/trace_view/
+[8]: /fr/synthetics/settings/?tab=specifyvalue#apm-integration-for-browser-tests
+[9]: /fr/synthetics/browser_tests/advanced_options/?tab=requestoptions#user-specified-locator
+[10]: /fr/help/
+[11]: /fr/synthetics/dashboards/browser_test/
+[12]: /fr/continuous_testing/cicd_integrations/configuration/?tab=npm#test-files
+[13]: /fr/synthetics/guide/synthetic-test-monitors/
+[14]: /fr/synthetics/guide/uptime-percentage-widget/
+[15]: /fr/real_user_monitoring/application_monitoring/browser/data_collected/#long-task-timing-metrics
+[16]: /fr/synthetics/guide/explore-rum-through-synthetics/
+[17]: /fr/tracing/services/resource_page/
+[18]: https://app.datadoghq.com/event/explorer
+[19]: /fr/continuous_testing/cicd_integrations
+[20]: /fr/synthetics/browser_tests/?tab=requestoptions#define-alert-conditions
+[21]: /fr/logs/guide/ease-troubleshooting-with-cross-product-correlation/#leverage-trace-correlation-to-troubleshoot-synthetic-tests
+[22]: /fr/real_user_monitoring/explorer
+[23]: /fr/real_user_monitoring/session_replay
+[24]: /fr/synthetics/browser_tests/?tab=requestoptions#fast-retry
+[25]: /fr/synthetics/guide/step-duration/
+[26]: /fr/synthetics/test_suites/
+[27]: /fr/synthetics/platform/downtime/
+[28]: /fr/synthetics/browser_tests/#advanced-options
\ No newline at end of file
diff --git a/hugo/content/fr/tests/setup/javascript.md b/hugo/content/fr/tests/setup/javascript.md
new file mode 100644
index 00000000000..794647c5407
--- /dev/null
+++ b/hugo/content/fr/tests/setup/javascript.md
@@ -0,0 +1,868 @@
+---
+aliases:
+- /fr/continuous_integration/setup_tests/javascript
+- /fr/continuous_integration/tests/javascript
+- /fr/continuous_integration/tests/setup/javascript
+code_lang: javascript
+code_lang_weight: 20
+further_reading:
+- link: /continuous_integration/tests/containers/
+ tag: Documentation
+ text: Transmettre des variables d'environnement pour des tests au sein de conteneurs
+- link: /continuous_integration/tests
+ tag: Documentation
+ text: Explorer les résultats de test et la performance
+- link: /tests/test_impact_analysis/javascript
+ tag: Documentation
+ text: Accélérez vos tâches de test avec Test Impact Analysis
+- link: /tests/troubleshooting/
+ tag: Documentation
+ text: Dépannage Test Optimization
+title: Tests JavaScript et TypeScript
+type: multi-code-lang
+---
+## Compatibilité {#compatibility}
+
+{{< tabs >}}
+{{% tab "dd-trace v6" %}}
+
+| Framework de test | Version | Notes |
+|---|---|---|
+| Jest | >= 28.0.0 | Seuls `jsdom` (dans le package `jest-environment-jsdom`) et `node` (dans le package `jest-environment-node`) sont pris en charge en tant qu'environnements de test. Les environnements personnalisés comme `@jest-runner/electron/environment` dans `jest-electron-runner` ne sont pas pris en charge.
Seul [`jest-circus`](https://github.com/facebook/jest/tree/main/packages/jest-circus) est pris en charge en tant que [`testRunner`](https://jestjs.io/docs/configuration#testrunner-string).
[`test.concurrent`](https://jestjs.io/docs/api#testconcurrentname-fn-timeout) est pris en charge à partir de `dd-trace>=6.1.0`. |
+| Mocha | >= 8.0.0 |
+| Cucumber | >= 7.0.0 |
+| Cypress | >= 12.0.0 |
+| Playwright | >= 1.38.0 |
+| Vitest | >= 1.6.0 | [`test.concurrent`](https://vitest.dev/api/#test-concurrent) est pris en charge à partir de `dd-trace>=6.1.0`. |
+
+`dd-trace` v6 nécessite Node.js 22 ou une version ultérieure.
+
+{{% /tab %}}
+{{% tab "dd-trace v5" %}}
+
+| Framework de test | Version | Notes |
+|---|---|---|
+| Jest | >= 24.8.0 | Seuls `jsdom` (dans le package `jest-environment-jsdom`) et `node` (dans le package `jest-environment-node`) sont pris en charge en tant qu'environnements de test. Les environnements personnalisés comme `@jest-runner/electron/environment` dans `jest-electron-runner` ne sont pas pris en charge.
Seul [`jest-circus`](https://github.com/facebook/jest/tree/main/packages/jest-circus) est pris en charge en tant que [`testRunner`](https://jestjs.io/docs/configuration#testrunner-string).
[`test.concurrent`](https://jestjs.io/docs/api#testconcurrentname-fn-timeout) est pris en charge à partir de `dd-trace>=5.112.0`. |
+| Mocha | >= 5.2.0 |
+| Cucumber | >= 7.0.0 |
+| Cypress | >= 6.7.0 |
+| Playwright | >= 1.18.0 |
+| Vitest | >= 1.6.0 | Pris en charge à partir de `dd-trace>=5.18.0`. [`test.concurrent`](https://vitest.dev/api/#test-concurrent) est pris en charge à partir de `dd-trace>=5.112.0`. |
+
+{{% /tab %}}
+{{< /tabs >}}
+
+L'instrumentation fonctionne à l'exécution, donc tous les transpileurs tels que TypeScript, Webpack ou Babel sont pris en charge sans configuration supplémentaire.
+
+## Configuration de la méthode de rapport {#configuring-reporting-method}
+
+Pour signaler les résultats des tests à Datadog, vous devez configurer la bibliothèque JavaScript Datadog :
+
+{{< tabs >}}
+{{% tab "Fournisseur CI avec prise en charge de l'auto-instrumentation" %}}
+{{% ci-autoinstrumentation %}}
+
+
+ Remarque : l'auto-instrumentation n'est pas prise en charge pour les tests Cypress. Pour instrumenter les tests Cypress, suivez les étapes d'instrumentation manuelle décrites ci-dessous.
+
+
+{{% /tab %}}
+
+{{% tab "Autre fournisseur CI Cloud" %}}
+{{% ci-agentless %}}
+
+{{% /tab %}}
+{{% tab "Fournisseur CI sur site" %}}
+{{% ci-agent %}}
+{{% /tab %}}
+{{< /tabs >}}
+
+## Installation du traceur JavaScript {#installing-the-javascript-tracer}
+
+Pour installer le [JavaScript Tracer][3], exécutez :
+
+```bash
+yarn add --dev dd-trace
+```
+
+Pour plus d'informations, consultez la [documentation d'installation du JavaScript Tracer][4].
+
+## Instrumentez vos tests {#instrument-your-tests}
+
+{{< tabs >}}
+{{% tab "Jest/Mocha" %}}
+Définissez la variable d'environnement `NODE_OPTIONS` sur `-r dd-trace/ci/init`. Exécutez vos tests comme vous le feriez normalement, en spécifiant éventuellement un nom pour votre session de test avec `DD_TEST_SESSION_NAME` :
+
+```bash
+NODE_OPTIONS="-r dd-trace/ci/init" DD_TEST_SESSION_NAME=unit-tests yarn test
+```
+
+**Remarque** : si vous définissez une valeur pour `NODE_OPTIONS`, assurez-vous qu'elle n'écrase pas `-r dd-trace/ci/init`. Cela peut être fait en utilisant la clause `${NODE_OPTIONS:-}` :
+
+{{< code-block lang="json" filename="package.json" >}}
+{
+ "scripts": {
+ "test": "NODE_OPTIONS=\"--max-old-space-size=12288 ${NODE_OPTIONS:-}\" jest"
+ }
+}
+{{< /code-block >}}
+
+### Ajout de tags personnalisés aux tests {#adding-custom-tags-to-tests}
+
+Vous pouvez ajouter des tags personnalisés à vos tests en utilisant la span actuellement active :
+
+```javascript
+ it('sum function can sum', () => {
+ const testSpan = require('dd-trace').scope().active()
+ testSpan.setTag('team_owner', 'my_team')
+ // test continues normally
+ // ...
+ })
+```
+
+Pour créer des filtres ou des champs `group by` pour ces tags, vous devez d'abord créer des facettes. Pour plus d'informations sur l'ajout de tags, consultez la section [Adding Tags][1] de la documentation sur l'instrumentation personnalisée de Node.js.
+
+
+### Ajout de mesures personnalisées aux tests {#adding-custom-measures-to-tests}
+
+Tout comme pour les tags, vous pouvez ajouter des mesures personnalisées à vos tests en utilisant le span actif :
+
+```javascript
+ it('sum function can sum', () => {
+ const testSpan = require('dd-trace').scope().active()
+ testSpan.setTag('memory_allocations', 16)
+ // test continues normally
+ // ...
+ })
+```
+
+Pour plus d'informations sur les mesures personnalisées, consultez le [guide d'ajout de mesures personnalisées][2].
+
+### Mocha ECMAScript modules (ESM) {#mocha-ecmascript-modules-esm}
+[Mocha >=9.0.0][3] utilise une approche axée sur l'ESM pour charger les fichiers de test. Définissez `NODE_OPTIONS` sur `-r dd-trace/ci/init --import dd-trace/register.js` pour obtenir une visibilité complète sur vos tests. Consultez [`dd-trace-js` ESM support][4] pour plus d'informations.
+
+
+[1]: /fr/tracing/trace_collection/custom_instrumentation/nodejs?tab=locally#adding-tags
+[2]: /fr/tests/guides/add_custom_measures/?tab=javascripttypescript
+[3]: https://github.com/mochajs/mocha/releases/tag/v9.0.0
+[4]: https://github.com/datadog/dd-trace-js?tab=readme-ov-file#ecmascript-modules-esm-support
+{{% /tab %}}
+
+{{% tab "Playwright" %}}
+Définissez la variable d'environnement `NODE_OPTIONS` sur `-r dd-trace/ci/init`. Exécutez vos tests comme vous le feriez normalement, en spécifiant éventuellement un nom pour votre session de test avec `DD_TEST_SESSION_NAME` :
+
+```bash
+NODE_OPTIONS="-r dd-trace/ci/init" DD_TEST_SESSION_NAME=e2e-tests yarn test:e2e
+```
+
+**Remarque** : si vous définissez une valeur pour `NODE_OPTIONS`, assurez-vous qu'elle n'écrase pas `-r dd-trace/ci/init`. Cela peut être fait en utilisant la clause `${NODE_OPTIONS:-}` :
+
+{{< code-block lang="json" filename="package.json" >}}
+{
+ "scripts": {
+ "test": "NODE_OPTIONS=\"--max-old-space-size=12288 ${NODE_OPTIONS:-}\" jest"
+ }
+}
+{{< /code-block >}}
+
+### Ajout de tags personnalisés aux tests {#adding-custom-tags-to-tests-1}
+
+Vous pouvez ajouter des tags personnalisés à vos tests en utilisant la span actuellement active :
+
+```javascript
+test('user profile', async ({ page }) => {
+ const testSpan = require('dd-trace').scope().active()
+ testSpan.setTag('team_owner', 'my_team')
+ // ...
+})
+
+test('landing page', async ({ page }) => {
+ const testSpan = require('dd-trace').scope().active()
+ testSpan.setTag('test.cpu.usage', 'high')
+ // ...
+})
+```
+
+Pour créer des filtres ou des champs `group by` pour ces tags, vous devez d'abord créer des facettes. Pour plus d'informations sur l'ajout de tags, consultez la section [Adding Tags][1] de la documentation sur l'instrumentation personnalisée de Node.js.
+
+### Ajout de mesures personnalisées aux tests {#adding-custom-measures-to-tests-1}
+
+Vous pouvez également ajouter des mesures personnalisées à vos tests en utilisant le span actif :
+
+```javascript
+test('user profile', async ({ page }) => {
+ const testSpan = require('dd-trace').scope().active()
+ testSpan.setTag('memory_allocations', 16)
+ // ...
+})
+```
+
+Pour plus d'informations sur les mesures personnalisées, consultez le [guide d'ajout de mesures personnalisées][2].
+
+### Playwright - RUM integration {#playwright-rum-integration}
+
+Si l'application de navigateur testée est instrumentée à l'aide de [Browser Monitoring][3], les résultats des tests Playwright et leurs RUM browser sessions et session replays générées sont automatiquement liés. Pour plus d'informations, consultez le [Instrumenting your browser tests with RUM guide][4].
+
+### Télécharger les captures d'écran d'échec de test {#upload-test-failure-screenshots}
+
+Lorsqu'elle est activée, Test Optimization télécharge les captures d'écran que Playwright capture lorsqu'un test échoue. Affichez les captures d'écran dans l'onglet {{< ui >}}Media{{< /ui >}} du panneau latéral des détails de test de Test Optimization. Utilisez-les pour inspecter l'état du navigateur au moment de l'échec.
+
+{{< img src="continuous_integration/tests/setup/playwright-failure-screenshot-media-tab.png" alt="Une capture d'écran d'échec Playwright affichée dans l'onglet Média du panneau latéral des détails de test de Test Optimization." style="width:100%;" >}}
+
+Utilisez [`dd-trace` v5.116.0 ou version ultérieure][5] sur la ligne de version v5, ou [`dd-trace` v6.5.0 ou version ultérieure][6] sur la ligne de version v6.
+
+Pour activer les téléchargements de captures d'écran, définissez la variable d'environnement `DD_TEST_FAILURE_SCREENSHOTS_ENABLED` sur `1`. Dans votre configuration Playwright, définissez [`screenshot`][7] sous `use` sur l'une des valeurs suivantes :
+
+- `'on'` : Capturez une capture d'écran après chaque test.
+- `'only-on-failure'` : Capturez une capture d'écran après chaque échec de test.
+- `'on-first-failure'` : Capturez une capture d'écran après le premier échec de chaque test.
+
+**Remarque** : Si vous utilisez `'on'`, Test Optimization ne télécharge que les captures d'écran des tests ayant échoué.
+
+[1]: /fr/tracing/trace_collection/custom_instrumentation/nodejs?tab=locally#adding-tags
+[2]: /fr/tests/guides/add_custom_measures/?tab=javascripttypescript
+[3]: /fr/real_user_monitoring/application_monitoring/browser/setup/
+[4]: /fr/continuous_integration/guides/rum_integration/
+[5]: https://github.com/DataDog/dd-trace-js/releases/tag/v5.116.0
+[6]: https://github.com/DataDog/dd-trace-js/releases/tag/v6.5.0
+[7]: https://playwright.dev/docs/api/class-testoptions#test-options-screenshot
+{{% /tab %}}
+
+{{% tab "Cucumber" %}}
+Définissez la variable d'environnement `NODE_OPTIONS` sur `-r dd-trace/ci/init`. Exécutez vos tests comme vous le feriez normalement, en spécifiant éventuellement un nom pour votre session de test avec `DD_TEST_SESSION_NAME` :
+
+```bash
+NODE_OPTIONS="-r dd-trace/ci/init" DD_TEST_SESSION_NAME=integration-tests yarn test:integration
+```
+
+**Remarque** : si vous définissez une valeur pour `NODE_OPTIONS`, assurez-vous qu'elle n'écrase pas `-r dd-trace/ci/init`. Cela peut être fait en utilisant la clause `${NODE_OPTIONS:-}` :
+
+{{< code-block lang="json" filename="package.json" >}}
+{
+ "scripts": {
+ "test": "NODE_OPTIONS=\"--max-old-space-size=12288 ${NODE_OPTIONS:-}\" jest"
+ }
+}
+{{< /code-block >}}
+
+### Ajout de tags personnalisés aux tests {#adding-custom-tags-to-tests-2}
+
+Vous pouvez ajouter des tags personnalisés à votre test en récupérant la span active :
+
+```javascript
+ When('the function is called', function () {
+ const stepSpan = require('dd-trace').scope().active()
+ testSpan.setTag('team_owner', 'my_team')
+ // test continues normally
+ // ...
+ })
+```
+
+Pour créer des filtres ou des champs `group by` pour ces tags, vous devez d'abord créer des facettes. Pour plus d'informations sur l'ajout de tags, consultez la section [Adding Tags][1] de la documentation sur l'instrumentation personnalisée de Node.js.
+
+
+### Ajout de mesures personnalisées aux tests {#adding-custom-measures-to-tests-2}
+
+Vous pouvez également ajouter des mesures personnalisées à votre test en utilisant le span actif :
+
+```javascript
+ When('the function is called', function () {
+ const stepSpan = require('dd-trace').scope().active()
+ testSpan.setTag('memory_allocations', 16)
+ // test continues normally
+ // ...
+ })
+```
+
+Pour plus d'informations sur les mesures personnalisées, consultez le [guide d'ajout de mesures personnalisées][2].
+
+[1]: /fr/tracing/trace_collection/custom_instrumentation/nodejs?tab=locally#adding-tags
+[2]: /fr/tests/guides/add_custom_measures/?tab=javascripttypescript
+{{% /tab %}}
+
+{{% tab "Cypress" %}}
+
+### Cypress version 10 ou ultérieure {#cypress-version-10-or-later}
+
+Utilisez la documentation de l'API Cypress pour [apprendre à utiliser les plugins][1] pour `cypress>=10`.
+
+Dans votre fichier `cypress.config.js`, définissez ce qui suit :
+
+{{< code-block lang="javascript" filename="cypress.config.js" >}}
+const { defineConfig } = require('cypress')
+
+module.exports = defineConfig({
+ e2e: {
+ setupNodeEvents: require('dd-trace/ci/cypress/plugin'),
+ supportFile: 'cypress/support/e2e.js'
+ }
+})
+{{< /code-block >}}
+
+Ajoutez la ligne suivante au **niveau supérieur** de votre `supportFile` :
+
+{{< code-block lang="javascript" filename="cypress/support/e2e.js" >}}
+// Your code can be before this line
+// require('./commands')
+require('dd-trace/ci/cypress/support')
+// Also supported:
+// import 'dd-trace/ci/cypress/support'
+// Your code can also be after this line
+// Cypress.Commands.add('login', (email, pw) => {})
+{{< /code-block >}}
+
+Si vous utilisez d'autres plugins Cypress, votre fichier `cypress.config.js` doit contenir ce qui suit :
+
+{{< code-block lang="javascript" filename="cypress.config.js" >}}
+const { defineConfig } = require('cypress')
+
+module.exports = defineConfig({
+ e2e: {
+ setupNodeEvents(on, config) {
+ // your previous code is before this line
+ return require('dd-trace/ci/cypress/plugin')(on, config)
+ }
+ }
+})
+{{< /code-block >}}
+
+#### Événement Cypress `after:run` {#cypress-afterrun-event}
+Datadog nécessite l'événement Cypress [`after:run`][2] pour fonctionner, et Cypress n'autorise pas plusieurs gestionnaires pour cet événement. Si vous avez déjà défini des gestionnaires pour `after:run`, ajoutez manuellement le gestionnaire Datadog en important `'dd-trace/ci/cypress/after-run'` :
+
+{{< code-block lang="javascript" filename="cypress.config.js" >}}
+const { defineConfig } = require('cypress')
+
+module.exports = defineConfig({
+ e2e: {
+ setupNodeEvents(on, config) {
+ require('dd-trace/ci/cypress/plugin')(on, config)
+ // other plugins
+ on('after:run', (details) => {
+ // other 'after:run' handlers
+ // important that this function call is returned
+ return require('dd-trace/ci/cypress/after-run')(details)
+ })
+ }
+ }
+})
+{{< /code-block >}}
+
+#### Événement Cypress `after:spec` {#cypress-afterspec-event}
+Datadog nécessite l'événement Cypress [`after:spec`][3] pour fonctionner, et Cypress n'autorise pas plusieurs gestionnaires pour cet événement. Si vous avez déjà défini des gestionnaires pour `after:spec`, ajoutez manuellement le gestionnaire Datadog en important `'dd-trace/ci/cypress/after-spec'` :
+
+{{< code-block lang="javascript" filename="cypress.config.js" >}}
+const { defineConfig } = require('cypress')
+
+module.exports = defineConfig({
+ e2e: {
+ setupNodeEvents(on, config) {
+ require('dd-trace/ci/cypress/plugin')(on, config)
+ // other plugins
+ on('after:spec', (...args) => {
+ // other 'after:spec' handlers
+ // Important that this function call is returned
+ // Important that all the arguments are passed
+ return require('dd-trace/ci/cypress/after-spec')(...args)
+ })
+ }
+ }
+})
+{{< /code-block >}}
+
+Exécutez vos tests comme vous le feriez normalement, en spécifiant éventuellement un nom pour votre session de test avec `DD_TEST_SESSION_NAME` :
+
+{{< code-block lang="shell" >}}
+DD_TEST_SESSION_NAME=ui-tests yarn test:ui
+{{< /code-block >}}
+
+
+### Ajout de tags personnalisés aux tests {#adding-custom-tags-to-tests-3}
+
+Pour ajouter des informations supplémentaires à vos tests, telles que le propriétaire de l'équipe, utilisez `cy.task('dd:addTags', { yourTags: 'here' })` dans votre test ou vos hooks.
+
+Exemple :
+
+```javascript
+beforeEach(() => {
+ cy.task('dd:addTags', {
+ 'before.each': 'certain.information'
+ })
+})
+it('renders a hello world', () => {
+ cy.task('dd:addTags', {
+ 'team.owner': 'ui'
+ })
+ cy.get('.hello-world')
+ .should('have.text', 'Hello World')
+})
+```
+
+Pour créer des filtres ou des champs `group by` pour ces tags, vous devez d'abord créer des facettes. Pour plus d'informations sur l'ajout de tags, consultez la section [Adding Tags][4] de la documentation sur l'instrumentation personnalisée Node.js.
+
+### Ajout de mesures personnalisées aux tests {#adding-custom-measures-to-tests-3}
+
+Pour ajouter des mesures personnalisées à vos tests, telles que les allocations de mémoire, utilisez `cy.task('dd:addTags', { yourNumericalTags: 1 })` dans votre test ou vos hooks.
+
+Exemple :
+
+```javascript
+it('renders a hello world', () => {
+ cy.task('dd:addTags', {
+ 'memory_allocations': 16
+ })
+ cy.get('.hello-world')
+ .should('have.text', 'Hello World')
+})
+```
+
+Pour plus d'informations sur les mesures personnalisées, consultez le [guide d'ajout de mesures personnalisées][5].
+
+### Intégration Cypress - RUM {#cypress-rum-integration}
+
+Si l'application de navigateur testée est instrumentée à l'aide de [Browser Monitoring][6], les résultats des tests Cypress ainsi que les sessions de navigateur RUM et les relectures de session générées sont automatiquement liés. Pour plus d'informations, consultez le [guide d'instrumentation de vos tests de navigateur avec RUM][7].
+
+### Téléversez les captures d'écran d'échec de test {#upload-test-failure-screenshots-1}
+
+Lorsqu'elle est activée, Test Optimization téléverse les captures d'écran que Cypress prend lorsqu'un test échoue. Elles apparaissent dans l'onglet {{< ui >}}Media{{< /ui >}} du panneau latéral des détails de test de Test Optimization. Utilisez-les pour inspecter l'état du navigateur au moment de l'échec.
+
+{{< img src="continuous_integration/tests/setup/cypress-failure-screenshot-media-tab.png" alt="Une capture d'écran d'échec Cypress affichée dans l'onglet Media du panneau latéral des détails de test de Test Optimization." style="width:100%;" >}}
+
+Utilisez [`dd-trace` v5.112.0 ou version ultérieure][8] sur la ligne de version v5, ou [`dd-trace` v6.1.0 ou version ultérieure][9] sur la ligne de version v6.
+
+Pour activer les téléchargements de captures d'écran, définissez la variable d'environnement `DD_TEST_FAILURE_SCREENSHOTS_ENABLED` sur `1`. Dans votre configuration Cypress, assurez-vous que [`screenshotOnRunFailure`][10] est défini sur `true` (la valeur par défaut).
+
+[1]: https://docs.cypress.io/guides/tooling/plugins-guide#Using-a-plugin
+[2]: https://docs.cypress.io/api/plugins/after-run-api
+[3]: https://docs.cypress.io/api/plugins/after-spec-api
+[4]: /fr/tracing/trace_collection/custom_instrumentation/nodejs?tab=locally#adding-tags
+[5]: /fr/tests/guides/add_custom_measures/?tab=javascripttypescript
+[6]: /fr/real_user_monitoring/application_monitoring/browser/setup/
+[7]: /fr/continuous_integration/guides/rum_integration/
+[8]: https://github.com/DataDog/dd-trace-js/releases/tag/v5.112.0
+[9]: https://github.com/DataDog/dd-trace-js/releases/tag/v6.1.0
+[10]: https://docs.cypress.io/app/references/configuration#Screenshots
+{{% /tab %}}
+
+{{% tab "Vitest" %}}
+
+
+Utilisez une version de Node.js prise en charge par votre version majeure de `dd-trace` pour l'instrumentation Vitest :
+- `dd-trace` v5 nécessite Node.js 18.19+ ou Node.js 20.6+.
+- `dd-trace` v6 nécessite Node.js 22 ou une version ultérieure.
+
+Définissez la variable d'environnement `NODE_OPTIONS` sur `--import dd-trace/register.js -r dd-trace/ci/init`. Exécutez vos tests comme vous le feriez normalement, en spécifiant éventuellement un nom pour votre session de test avec `DD_TEST_SESSION_NAME` :
+
+```bash
+NODE_OPTIONS="--import dd-trace/register.js -r dd-trace/ci/init" DD_TEST_SESSION_NAME=smoke-tests yarn test:smoke
+```
+
+**Remarque** : si vous définissez une valeur pour `NODE_OPTIONS`, assurez-vous qu'elle n'écrase pas `--import dd-trace/register.js -r dd-trace/ci/init`. Cela peut être fait en utilisant la clause `${NODE_OPTIONS:-}` :
+
+{{< code-block lang="json" filename="package.json" >}}
+{
+ "scripts": {
+ "test": "NODE_OPTIONS=\"--max-old-space-size=12288 ${NODE_OPTIONS:-}\" vitest run"
+ }
+}
+{{< /code-block >}}
+
+### Ajout de tags personnalisés ou de mesures personnalisées aux tests {#adding-custom-tags-or-measures-to-tests}
+
+Vous pouvez ajouter des tags personnalisés à vos tests en utilisant la span actuellement active :
+
+```javascript
+import tracer from 'dd-trace'
+import { expect, test } from 'vitest'
+
+test('sum function can sum', () => {
+ const testSpan = tracer.scope().active()
+ testSpan.setTag('team_owner', 'my_team')
+
+ expect(1 + 2).toBe(3)
+})
+```
+
+Pour créer des filtres ou des champs `group by` pour ces tags, vous devez d'abord créer des facettes. Pour plus d'informations sur l'ajout de tags, consultez la section [Adding Tags][1] de la documentation sur l'instrumentation personnalisée de Node.js.
+
+Vous pouvez également ajouter des mesures personnalisées à vos tests en utilisant le span actif :
+
+```javascript
+import tracer from 'dd-trace'
+import { expect, test } from 'vitest'
+
+test('sum function can sum', () => {
+ const testSpan = tracer.scope().active()
+ testSpan.setTag('memory_allocations', 16)
+
+ expect(1 + 2).toBe(3)
+})
+```
+
+Pour plus d'informations sur les mesures personnalisées, consultez le [guide d'ajout de mesures personnalisées][2].
+
+[1]: /fr/tracing/trace_collection/custom_instrumentation/nodejs?tab=locally#adding-tags
+[2]: /fr/tests/guides/add_custom_measures/?tab=javascripttypescript
+{{% /tab %}}
+
+{{< /tabs >}}
+
+### Comment corriger les erreurs « Cannot find module 'dd-trace/ci/init' » {#how-to-fix-cannot-find-module-dd-traceciinit-errors}
+
+Lorsque vous utilisez `dd-trace`, vous pourriez rencontrer le message d'erreur suivant :
+
+```text
+ Error: Cannot find module 'dd-trace/ci/init'
+```
+
+Cela peut être dû à une utilisation incorrecte de `NODE_OPTIONS`.
+
+Par exemple, si votre GitHub Action ressemble à ceci :
+
+```yml
+jobs:
+ my-job:
+ name: Run tests
+ runs-on: ubuntu-latest
+ # Invalid NODE_OPTIONS
+ env:
+ NODE_OPTIONS: -r dd-trace/ci/init
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v3
+ - name: Install node
+ uses: actions/setup-node@v3
+ - name: Install dependencies
+ run: npm install
+ - name: Run tests
+ run: npm test
+```
+
+**Remarque :** Cela ne fonctionne pas car `NODE_OPTIONS` sont interprétés par chaque processus de nœud, y compris `npm install`. Si vous essayez d'importer `dd-trace/ci/init` avant qu'il ne soit installé, cette étape échoue.
+
+Votre GitHub Action devrait plutôt ressembler à ceci :
+
+```yml
+jobs:
+ my-job:
+ name: Run tests
+ runs-on: ubuntu-latest
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v3
+ - name: Install node
+ uses: actions/setup-node@v3
+ - name: Install dependencies
+ run: npm install
+ - name: Run tests
+ run: npm test
+ env:
+ NODE_OPTIONS: -r dd-trace/ci/init
+```
+
+Suivez ces bonnes pratiques :
+
+* Assurez-vous que la variable d'environnement `NODE_OPTIONS` est uniquement définie sur le processus exécutant les tests.
+* Évitez spécifiquement de définir `NODE_OPTIONS` dans les paramètres des variables d'environnement globales de votre pipeline ou de votre définition de job.
+
+
+#### Utilisation de Yarn 2 ou version ultérieure {#using-yarn-2-or-later}
+
+Si vous utilisez `yarn>=2` et un fichier `.pnp.cjs`, vous pourriez également obtenir la même erreur :
+
+```text
+ Error: Cannot find module 'dd-trace/ci/init'
+```
+
+Vous pouvez le corriger en définissant `NODE_OPTIONS` sur ce qui suit :
+
+```bash
+NODE_OPTIONS="-r $(pwd)/.pnp.cjs -r dd-trace/ci/init" yarn test
+```
+
+## Rapport de couverture de code {#reporting-code-coverage}
+
+Lorsque les tests sont instrumentés avec [Istanbul][5], le traceur Datadog (v3.20.0 ou ultérieure) le signale sous le tag `test.code_coverage.lines_pct` pour vos sessions de test.
+
+Vous pouvez voir l'évolution de la couverture des tests dans l'onglet **Coverage** d'une session de test.
+
+Pour plus d'informations, consultez [Code Coverage][6].
+
+## Paramètres de configuration {#configuration-settings}
+
+Voici une liste des paramètres de configuration les plus importants qui peuvent être utilisés avec le SDK.
+
+`test_session.name`
+: Utilisez-le pour identifier un groupe de tests, tels que `integration-tests`, `unit-tests` ou `smoke-tests`.
+**Variable d'environnement**: `DD_TEST_SESSION_NAME`
+**Par défaut**: Pour `dd-trace` v6, l'invocation du framework, telle que `jest`, `mocha`, `playwright test` ou `cucumber-js`. Pour `dd-trace` v5, une combinaison du nom du job CI et de la commande de test.
+**Exemple**: `unit-tests`, `integration-tests`, `smoke-tests`
+
+`service`
+: Nom du service ou de la bibliothèque en cours de test.
+**Variable d'environnement** : `DD_SERVICE`
+**Par défaut** : (nom du framework de test)
+**Exemple** : `my-ui`
+
+`env`
+: Nom de l'environnement où les tests sont exécutés.
+**Variable d'environnement** : `DD_ENV`
+**Par défaut** : `none`
+**Exemples** : `local`, `ci`
+
+`url`
+: URL du Datadog Agent pour la collecte des traces sous la forme `http://hostname:port`.
+**Variable d'environnement** : `DD_TRACE_AGENT_URL`
+**Par défaut** : `http://localhost:8126`
+
+Pour plus d'informations sur les tags réservés `service` et `env`, consultez [Unified Service Tagging][7]. Toutes les autres options de [Datadog Tracer configuration][8] peuvent également être utilisées.
+
+## Collecte des métadonnées Git {#collecting-git-metadata}
+
+{{% ci-git-metadata %}}
+
+## API de test manuel {#manual-testing-api}
+
+
+ Remarque : L'API de test manuel est disponible à partir de dd-trace versions 5.23.0 et 4.47.0.
+
+
+Si vous utilisez Jest, Mocha, Cypress, Playwright, Cucumber ou Vitest, **n'utilisez pas l'API de test manuel**, car Test Optimization les instrumente automatiquement et envoie les résultats des tests à Datadog. L'API de test manuel est **incompatible** avec les frameworks de test déjà pris en charge.
+
+Utilisez l'API de test manuel uniquement si vous utilisez un framework de test non pris en charge ou si vous disposez d'un mécanisme de test différent.
+
+L'API de test manuel exploite le module `node:diagnostics_channel` de Node.js et repose sur des canaux sur lesquels vous pouvez publier :
+
+```javascript
+const { channel } = require('node:diagnostics_channel')
+
+const { describe, test, beforeEach, afterEach, assert } = require('my-custom-test-framework')
+
+const testStartCh = channel('dd-trace:ci:manual:test:start')
+const testFinishCh = channel('dd-trace:ci:manual:test:finish')
+const testSuite = __filename
+
+describe('can run tests', () => {
+ beforeEach((testName) => {
+ testStartCh.publish({ testName, testSuite })
+ })
+ afterEach((status, error) => {
+ testFinishCh.publish({ status, error })
+ })
+ test('first test will pass', () => {
+ assert.equal(1, 1)
+ })
+})
+```
+
+### Canal de début de test {#test-start-channel}
+
+Récupérez ce canal par son ID `dd-trace:ci:manual:test:start` pour publier qu'un test commence. Un bon endroit pour faire cela est un hook `beforeEach` ou similaire.
+
+```typescript
+const { channel } = require('node:diagnostics_channel')
+const testStartCh = channel('dd-trace:ci:manual:test:start')
+
+// ... code for your testing framework goes here
+ beforeEach(() => {
+ const testDefinition = {
+ testName: 'a-string-that-identifies-this-test',
+ testSuite: 'what-suite-this-test-is-from.js'
+ }
+ testStartCh.publish(testDefinition)
+ })
+// code for your testing framework continues here ...
+```
+
+La charge utile à publier possède les attributs `testName` et `testSuite`, tous deux des chaînes, qui identifient le test sur le point de commencer.
+
+### Canal de fin de test {#test-finish-channel}
+
+Récupérez ce canal par son ID `dd-trace:ci:manual:test:finish` pour publier qu'un test se termine. Un bon endroit pour faire cela est un hook `afterEach` ou similaire.
+
+```typescript
+const { channel } = require('node:diagnostics_channel')
+const testFinishCh = channel('dd-trace:ci:manual:test:finish')
+
+// ... code for your testing framework goes here
+ afterEach(() => {
+ const testStatusPayload = {
+ status: 'fail',
+ error: new Error('assertion error')
+ }
+ testStartCh.publish(testStatusPayload)
+ })
+// code for your testing framework continues here ...
+```
+
+La charge utile à publier possède les attributs `status` et `error` :
+
+* `status` est une chaîne qui prend l'une des trois valeurs suivantes :
+ * `'pass'` lorsqu'un test réussit.
+ * `'fail'` lorsqu'un test échoue.
+ * `'skip'` lorsqu'un test a été ignoré.
+
+* `error` est un objet `Error` contenant la raison pour laquelle un test a échoué.
+
+### Canal d'ajout de tags {#add-tags-channel}
+
+Récupérez ce canal par son ID `dd-trace:ci:manual:test:addTags` pour publier qu'un test nécessite des tags personnalisés. Cela peut être fait au sein de la fonction de test :
+
+```typescript
+const { channel } = require('node:diagnostics_channel')
+const testAddTagsCh = channel('dd-trace:ci:manual:test:addTags')
+
+// ... code for your testing framework goes here
+ test('can sum', () => {
+ testAddTagsCh.publish({ 'test.owner': 'my-team', 'number.assertions': 3 })
+ const result = sum(2, 1)
+ assert.equal(result, 3)
+ })
+// code for your testing framework continues here ...
+```
+
+La charge utile à publier est un dictionnaire `` de tags ou de mesures qui sont ajoutés au test.
+
+
+### Exécuter les tests {#run-the-tests}
+
+Lorsque les canaux de début et de fin de test sont dans votre code, exécutez votre framework de test comme vous le faites normalement, en incluant les variables d'environnement suivantes :
+
+```shell
+NODE_OPTIONS="-r dd-trace/ci/init" DD_TEST_SESSION_NAME=custom-tests yarn run-my-test-framework
+```
+
+
+
+## Limitations connues {#known-limitations}
+
+### Tests de navigateur {#browser-tests}
+Les tests de navigateur exécutés avec `mocha`, `jest`, `cucumber`, `cypress`, `playwright` et `vitest` sont instrumentés par `dd-trace-js`, mais la visibilité sur la session de navigateur elle-même n'est pas fournie par défaut (par exemple, les appels réseau, les actions utilisateur, les chargements de page, et plus encore).
+
+Si vous souhaitez une visibilité sur le processus de navigateur, envisagez d'utiliser [RUM & Session Replay][9]. Lors de l'utilisation de Cypress ou Playwright, les résultats des tests et leurs sessions de navigateur RUM générées ainsi que les relectures de session sont automatiquement liés. Pour plus d'informations, consultez le [guide d'instrumentation de vos tests de navigateur avec RUM][10].
+
+### Mode interactif Cypress {#cypress-interactive-mode}
+
+Le mode interactif Cypress (auquel vous pouvez accéder en exécutant `cypress open`) n'est pas pris en charge par Test Optimization car certains événements Cypress, tels que [`before:run`][11], ne sont pas déclenchés. Si vous souhaitez essayer malgré tout, transmettez `experimentalInteractiveRunEvents: true` au [fichier de configuration Cypress][12].
+
+### Les tentatives exigent l'isolation des tests Cypress {#retries-require-cypress-test-isolation}
+
+L'isolation des tests de Cypress [test isolation][13] doit être activée (par défaut) pour
+que les fonctionnalités Test Optimization basées sur les tentatives fonctionnent. Lorsque `testIsolation` est défini sur
+`false` dans votre configuration Cypress, `dd-trace` désactive toutes les tentatives
+de test—[Early Flake Detection][22], [Auto Test Retries][23], et
+[tentative de correction][24]—car ces fonctionnalités réexécutent chaque test sur place, ce qui nécessite l'isolation.
+
+Lorsque l'isolation est désactivée, le traceur enregistre l'avertissement `Test isolation is
+disabled, retries will not be enabled`, et aucune exécution de test n'est marquée avec
+`@test.test_management.is_attempt_to_fix`. Parce que le traceur lit le global
+`testIsolation` valeur, les remplacements `describe` par suite ne réactivent pas les tentatives.
+
+### Jest `--forceExit` {#jests-forceexit}
+L'option [--forceExit][15] de Jest peut entraîner une perte de données. Datadog essaie d'envoyer des données immédiatement après la fin de vos tests, mais l'arrêt brutal du processus peut entraîner l'échec de certaines requêtes. Utilisez `--forceExit` avec prudence.
+
+### Mocha `--exit` {#mochas-exit}
+L'option [--exit][16] de Mocha peut entraîner une perte de données. Datadog essaie d'envoyer des données immédiatement après la fin de vos tests, mais l'arrêt brutal du processus peut entraîner l'échec de certaines requêtes. Utilisez `--exit` avec prudence.
+
+### Le mode navigateur de Vitest {#vitests-browser-mode}
+Le [mode navigateur][17] de Vitest n'est pas pris en charge.
+
+### La surcharge de durée de test de Vitest {#vitests-test-duration-overhead}
+
+Par défaut, l'option [`isolate`][21] de Vitest est `true`, donc chaque fichier de test s'exécute dans son propre fork ou thread. Vitest est axé sur l'ESM et s'appuie sur [import-in-the-middle][20] pour l'instrumentation, ce qui entraîne un coût de configuration à chaque démarrage d'une suite. Avec l'isolation, ce coût de configuration est répété pour chaque fichier. L'effet est plus marqué lorsque vous disposez de nombreuses petites suites rapides, car le temps de configuration peut dominer le temps d'exécution global.
+
+Pour réduire la surcharge, définissez `isolate: false` dans votre fichier de configuration Vitest, ou passez `--no-isolate` à la commande de test.
+
+Pour maintenir l'isolation de Vitest activée avec une surcharge de démarrage de worker plus faible, définissez `DD_EXPERIMENTAL_TEST_OPT_VITEST_NO_WORKER_INIT=true`. Cette option est disponible dans `dd-trace` v5 (à partir de `5.111.0`) et v6 (à partir de `6.0.0`). Elle s'applique aux exécutions isolées du pool de workers Vitest avec Vitest `3.2.6` et versions ultérieures, et revient à une instrumentation de worker normale pour les configurations non prises en charge.
+
+Comme ce mode n'initialise pas `dd-trace` dans les workers Vitest, les fonctionnalités suivantes ne sont pas prises en charge :
+
+- Tags de test personnalisés
+- Spans personnalisés :
+- Corrélation de logs à partir du code de test :
+- Rejeu de test échoué
+
+## Bonnes pratiques {#best-practices}
+
+Suivez ces pratiques pour tirer pleinement parti du framework de test et de Test Optimization.
+
+### Tests paramétrés {#parameterized-tests}
+
+Dans la mesure du possible, tirez parti des outils fournis par les frameworks de test pour les tests paramétrés. Par exemple, pour `jest` :
+
+Évitez ceci :
+{{< code-block lang="javascript" >}}
+[[1,2,3], [3,4,7]].forEach((a,b,expected) => {
+ test('sums correctly', () => {
+ expect(a+b).toEqual(expected)
+ })
+})
+{{< /code-block >}}
+
+Et utilisez plutôt [`test.each`][18] :
+
+{{< code-block lang="javascript" >}}
+test.each([[1,2,3], [3,4,7]])('sums correctly %i and %i', (a,b,expected) => {
+ expect(a+b).toEqual(expected)
+})
+{{< /code-block >}}
+
+Pour `mocha`, utilisez [`mocha-each`][19] :
+
+{{< code-block lang="javascript" >}}
+const forEach = require('mocha-each');
+forEach([
+ [1,2,3],
+ [3,4,7]
+])
+.it('adds %i and %i then returns %i', (a,b,expected) => {
+ expect(a+b).to.equal(expected)
+});
+{{< /code-block >}}
+
+Lorsque vous utilisez cette approche, le framework de test et Test Optimization peuvent distinguer vos tests.
+
+### Nom de la session de test `DD_TEST_SESSION_NAME` {#test-session-name-dd-test-session-name}
+
+Utilisez `DD_TEST_SESSION_NAME` pour définir le nom de la session de test et le groupe de tests associé. Voici des exemples de valeurs pour ce tag :
+
+- `unit-tests`
+- `integration-tests`
+- `smoke-tests`
+- `flaky-tests`
+- `ui-tests`
+- `backend-tests`
+
+Si `DD_TEST_SESSION_NAME` n'est pas spécifié, la valeur par défaut est :
+
+- Pour `dd-trace` v6, l'appel du framework, tel que `jest`, `mocha`, `playwright test` ou `cucumber-js`
+- Pour `dd-trace` v5, une combinaison du nom du job CI et de la commande utilisée pour exécuter les tests (par exemple, `my-ci-job yarn test`)
+
+Le nom de la session de test doit être unique au sein d'un dépôt pour vous aider à distinguer différents groupes de tests.
+
+## Lectures complémentaires {#further-reading}
+
+{{< partial name="whats-next/whats-next.html" >}}
+
+[3]: /fr/tracing/trace_collection/dd_libraries/nodejs
+[4]: https://github.com/DataDog/dd-trace-js#version-release-lines-and-maintenance
+[5]: https://istanbul.js.org/
+[6]: /fr/tests/code_coverage/?tab=javascripttypescript
+[7]: /fr/getting_started/tagging/unified_service_tagging
+[8]: /fr/tracing/trace_collection/library_config/nodejs/?tab=containers#configuration
+[9]: /fr/real_user_monitoring/application_monitoring/browser/
+[10]: /fr/continuous_integration/guides/rum_integration/
+[11]: https://docs.cypress.io/api/plugins/before-run-api
+[12]: https://docs.cypress.io/guides/references/configuration#Configuration-File
+[13]: https://docs.cypress.io/app/core-concepts/test-isolation
+[15]: https://jestjs.io/docs/cli#--forceexit
+[16]: https://mochajs.org/running/cli/#--exit
+[17]: https://vitest.dev/guide/browser/
+[18]: https://jestjs.io/docs/api#testeachtablename-fn-timeout
+[19]: https://www.npmjs.com/package/mocha-each
+[20]: https://github.com/nodejs/import-in-the-middle
+[21]: https://vitest.dev/config/isolate
+[22]: /fr/tests/flaky_tests/early_flake_detection/
+[23]: /fr/tests/flaky_tests/auto_test_retries/
+[24]: /fr/tests/flaky_management/#confirm-fixes-for-flaky-tests
\ No newline at end of file
diff --git a/hugo/content/ja/api/latest/agent-observability/create-an-agent-observability-annotation-queue/index.md b/hugo/content/ja/api/latest/agent-observability/create-an-agent-observability-annotation-queue/index.md
new file mode 100644
index 00000000000..97a72cc3453
--- /dev/null
+++ b/hugo/content/ja/api/latest/agent-observability/create-an-agent-observability-annotation-queue/index.md
@@ -0,0 +1,3 @@
+---
+title: Agent Observabilityアノテーション・キューを作成します。
+---
diff --git a/hugo/content/ja/api/latest/agent-observability/list-agent-observability-spans/index.md b/hugo/content/ja/api/latest/agent-observability/list-agent-observability-spans/index.md
new file mode 100644
index 00000000000..7e324499499
--- /dev/null
+++ b/hugo/content/ja/api/latest/agent-observability/list-agent-observability-spans/index.md
@@ -0,0 +1,3 @@
+---
+title: Agent Observability のスパンを一覧表示します
+---
diff --git a/hugo/content/ja/api/latest/agent-observability/update-an-agent-observability-experiment/index.md b/hugo/content/ja/api/latest/agent-observability/update-an-agent-observability-experiment/index.md
new file mode 100644
index 00000000000..4b218ec7f06
--- /dev/null
+++ b/hugo/content/ja/api/latest/agent-observability/update-an-agent-observability-experiment/index.md
@@ -0,0 +1,3 @@
+---
+title: Agent Observability の実験を更新してください
+---
diff --git a/hugo/content/ja/api/latest/data-deletion/creates-a-data-deletion-request/index.md b/hugo/content/ja/api/latest/data-deletion/creates-a-data-deletion-request/index.md
new file mode 100644
index 00000000000..60d35c81ccf
--- /dev/null
+++ b/hugo/content/ja/api/latest/data-deletion/creates-a-data-deletion-request/index.md
@@ -0,0 +1,3 @@
+---
+title: データ削除リクエストを作成します
+---
diff --git a/hugo/content/ja/api/latest/elastic-cloud-integration-accounts/get-an-elastic-cloud-integration-account/index.md b/hugo/content/ja/api/latest/elastic-cloud-integration-accounts/get-an-elastic-cloud-integration-account/index.md
new file mode 100644
index 00000000000..ae50b67d142
--- /dev/null
+++ b/hugo/content/ja/api/latest/elastic-cloud-integration-accounts/get-an-elastic-cloud-integration-account/index.md
@@ -0,0 +1,3 @@
+---
+title: Elastic Cloud統合アカウントを取得してください
+---
diff --git a/hugo/content/ja/api/latest/llm-observability/create-an-agent-observability-prompt/index.md b/hugo/content/ja/api/latest/llm-observability/create-an-agent-observability-prompt/index.md
new file mode 100644
index 00000000000..635feb27e3d
--- /dev/null
+++ b/hugo/content/ja/api/latest/llm-observability/create-an-agent-observability-prompt/index.md
@@ -0,0 +1,3 @@
+---
+title: Agent Observabilityのプロンプトを作成してください。
+---
diff --git a/hugo/content/ja/api/latest/llm-observability/delete-agent-observability-datasets/index.md b/hugo/content/ja/api/latest/llm-observability/delete-agent-observability-datasets/index.md
new file mode 100644
index 00000000000..e46457707fb
--- /dev/null
+++ b/hugo/content/ja/api/latest/llm-observability/delete-agent-observability-datasets/index.md
@@ -0,0 +1,3 @@
+---
+title: Agent Observability データセットを削除してください
+---
diff --git a/hugo/content/ja/api/latest/llm-observability/get-a-specific-agent-observability-prompt-version/index.md b/hugo/content/ja/api/latest/llm-observability/get-a-specific-agent-observability-prompt-version/index.md
new file mode 100644
index 00000000000..6af29ea2cee
--- /dev/null
+++ b/hugo/content/ja/api/latest/llm-observability/get-a-specific-agent-observability-prompt-version/index.md
@@ -0,0 +1,3 @@
+---
+title: 特定の Agent Observability プロンプトバージョンを取得します
+---
diff --git a/hugo/content/ja/api/latest/rum-retention-filters/get-all-rum-exclusion-filters/index.md b/hugo/content/ja/api/latest/rum-retention-filters/get-all-rum-exclusion-filters/index.md
new file mode 100644
index 00000000000..72b2bfcbe82
--- /dev/null
+++ b/hugo/content/ja/api/latest/rum-retention-filters/get-all-rum-exclusion-filters/index.md
@@ -0,0 +1,3 @@
+---
+title: すべてのRUM除外フィルターを取得します
+---
diff --git a/hugo/content/ja/api/latest/rum-retention-quotas/create-or-update-a-rum-retention-quota-config/index.md b/hugo/content/ja/api/latest/rum-retention-quotas/create-or-update-a-rum-retention-quota-config/index.md
new file mode 100644
index 00000000000..39311f3aa2a
--- /dev/null
+++ b/hugo/content/ja/api/latest/rum-retention-quotas/create-or-update-a-rum-retention-quota-config/index.md
@@ -0,0 +1,3 @@
+---
+title: RUM保持クォータ設定を作成または更新してください
+---
diff --git a/hugo/content/ja/api/latest/security-monitoring/update-a-severity-modifier-rule/index.md b/hugo/content/ja/api/latest/security-monitoring/update-a-severity-modifier-rule/index.md
new file mode 100644
index 00000000000..ee569e7a671
--- /dev/null
+++ b/hugo/content/ja/api/latest/security-monitoring/update-a-severity-modifier-rule/index.md
@@ -0,0 +1,3 @@
+---
+title: 重大度修飾子ルールを更新してください
+---
diff --git a/hugo/content/ja/api/latest/twilio-integration-accounts/_index.md b/hugo/content/ja/api/latest/twilio-integration-accounts/_index.md
new file mode 100644
index 00000000000..1bc3a3592e4
--- /dev/null
+++ b/hugo/content/ja/api/latest/twilio-integration-accounts/_index.md
@@ -0,0 +1,3 @@
+---
+title: Twilio統合アカウント一覧
+---
diff --git a/hugo/content/ja/api/latest/twilio-integration-accounts/create-a-twilio-integration-account/index.md b/hugo/content/ja/api/latest/twilio-integration-accounts/create-a-twilio-integration-account/index.md
new file mode 100644
index 00000000000..ead6d06db4b
--- /dev/null
+++ b/hugo/content/ja/api/latest/twilio-integration-accounts/create-a-twilio-integration-account/index.md
@@ -0,0 +1,3 @@
+---
+title: Twilio統合アカウントを作成してください
+---
diff --git a/hugo/content/ja/data_observability/jobs_monitoring/databricks/_index.md b/hugo/content/ja/data_observability/jobs_monitoring/databricks/_index.md
index 87dac4b7acd..ab0063f5fc1 100644
--- a/hugo/content/ja/data_observability/jobs_monitoring/databricks/_index.md
+++ b/hugo/content/ja/data_observability/jobs_monitoring/databricks/_index.md
@@ -1,92 +1,99 @@
---
aliases:
- /ja/data_jobs/databricks
-description: 'OAuth または個人用アクセストークン認証と Datadog Agent のインストールを使用して Databricks ワークスペースの
- Data Observability: Jobs Monitoring を有効にします。'
+description: 'OAuth または Personal Access Token 認証と Datadog Agent のインストールを使用して、Databricks
+ ワークスペースの Data Observability: Jobs Monitoring を有効にします。'
further_reading:
- link: /data_jobs
tag: ドキュメント
text: 'Data Observability: Jobs Monitoring'
- link: https://www.datadoghq.com/blog/databricks-serverless-jobs-datadog/
tag: ブログ
- text: Databricks サーバーレスジョブモニタリングを使用して、問題を検出し、コストを最適化する
+ text: Databricks Serverless Jobs Monitoring で問題を検出し、コストを最適化する
title: 'Databricks の Data Observability: Jobs Monitoring を有効にする'
---
-[Data Observability: Jobs Monitoring][7] は、クラスターまたはサーバーレスコンピュート上で実行される Databricks ジョブとワークフローのパフォーマンスおよび信頼性を可視化します。
+[Data Observability: Jobs Monitoring][7] は、クラスターまたはサーバーレスコンピュートで実行される Databricks ジョブとワークフローのパフォーマンスと信頼性を可視化します。
## セットアップ {#setup}
-Databricks ワークスペースで
Networking Restrictions が有効になっている場合、Datadog の {{< region-param key="ip_ranges_url_webhooks" link="true" text="webhook IP ranges" >}} を許可リストに追加します。ワークスペースがプライベートリンクを使用している場合は、以下の
プライベートリンク接続タブを参照してください。
Databricks ワークスペースで
ネットワーク制限が有効になっている場合は、Datadog の {{< region-param key="ip_ranges_url_webhooks" link="true" text="webhook IP ranges" >}} を許可リストに追加します。ワークスペースで Private Link を使用している場合は、以下の
Private Link Connectivity タブを参照してください。
新しいワークスペースインテグレーションは、OAuth を使用して認証する必要があります。すでに個人用アクセストークンで統合されているワークスペースは引き続き機能し、いつでも OAuth に切り替えることができます。ワークスペースが OAuth の使用を開始した後は、個人用アクセストークンに戻すことができません。
+新しいワークスペースインテグレーションは、OAuth を使用して認証する必要があります。Personal Access Token ですでに統合されているワークスペースは引き続き機能し、いつでも OAuth に切り替えることができます。ワークスペースで OAuth の使用を開始すると、Personal Access Token に戻すことはできません。
#### Databricks でサービスプリンシパルを作成および構成する {#create-and-configure-the-service-principal-in-databricks}
1. **Databricks ワークスペース管理者**として、ワークスペースの右上隅にあるプロフィールをクリックして {{< ui >}}Settings{{< /ui >}} に移動します。
-1. {{< ui >}}Identity and access{{< /ui >}} タブで、{{< ui >}}Service principals{{< /ui >}} の隣にある {{< ui >}}Manage{{< /ui >}} をクリックします。
-1. {{< ui >}}Add service principal{{< /ui >}} をクリックし、その後 {{< ui >}}Add new{{< /ui >}} をクリックします。
-1. 名前を入力し、その後**追加**をクリックします。
+1. {{< ui >}}Identity and access{{< /ui >}}タブで、{{< ui >}}Service principals{{< /ui >}} の横にある {{< ui >}}Manage{{< /ui >}} をクリックします。
+1. {{< ui >}}Add service principal{{< /ui >}} をクリックし、次に {{< ui >}}Add new{{< /ui >}} をクリックします。
- Azure Databricks の場合は、「Databricks 管理」の管理タイプを選択します。Datadog は「Microsoft Entra ID 管理」サービスプリンシパルをサポートしていません。
+ Azure Databricks の場合は、[Databricks managed] 管理タイプを選択します。Datadog は [Microsoft Entra ID managed] サービスプリンシパルをサポートしていません。
+1. 名前を入力し、サービスプリンシパルに対して次のワークスペースエンタイトルメントを有効にします。
+ - {{< ui >}}Workspace access{{< /ui >}}
+ - {{< ui >}}Databricks SQL access{{< /ui >}}
+ - {{< ui >}}Admin access{{< /ui >}}: Datadog が必要とするワークスペース管理者アクセス権を付与します。これは、サービスプリンシパルを `admins` グループに追加することと同等です。
+
+ 管理者アクセスエンタイトルメントを付与できない場合は、代わりに高度な構成の
権限セクションで説明されているように、きめ細かなアクセス権をプロビジョニングします。
+1. **Add** をクリックします。
1. 新しいサービスプリンシパルの名前をクリックします。{{< ui >}}Secrets{{< /ui >}} タブで、{{< ui >}}Generate secret{{< /ui >}} をクリックします。
- 1. {{< ui >}}Lifetime (days){{< /ui >}} を最大値 (730) に設定します。
+ 1. {{< ui >}}Lifetime (days){{< /ui >}} を許可される最大値 (730) に設定します。
1. {{< ui >}}Generate{{< /ui >}} をクリックします。
- 1. クライアント ID とクライアントシークレットをメモします。
+ 1. クライアント ID とクライアントシークレットを控えておきます。
{{< img src="data_jobs/databricks/client-id-secret.png" alt="Databricks では、新しい OAuth シークレットに関連付けられたクライアント ID とシークレットを表示するモーダルが表示されます。" style="width:70%;" >}}
-1. {{< ui >}}Permissions{{< /ui >}} タブで、{{< ui >}}Grant access{{< /ui >}} をクリックします。新しいサービスプリンシパルを検索し、{{< ui >}}Manage{{< /ui >}} の権限を付与して、{{< ui >}}Save{{< /ui >}} をクリックします。
-1. {{< ui >}}Identity and access{{< /ui >}} タブに戻り、{{< ui >}}Groups{{< /ui >}} の隣にある {{< ui >}}Manage{{< /ui >}} をクリックします。
-1. {{< ui >}}admins{{< /ui >}} グループをクリックし、{{< ui >}}Add members{{< /ui >}} をクリックして新しいサービスプリンシパルを追加します。
+1. {{< ui >}}Permissions{{< /ui >}} タブで、{{< ui >}}Grant access{{< /ui >}} をクリックします。新しいサービスプリンシパルを検索し、{{< ui >}}Manage{{< /ui >}} 権限を付与して、{{< ui >}}Save{{< /ui >}} をクリックします。
-#### Databricks ワークスペースを Datadog に追加します。{#add-the-databricks-workspace-to-datadog}
+#### Databricks ワークスペースを Datadog に追加する {#add-the-databricks-workspace-to-datadog}
1. Datadog で、Databricks インテグレーションタイルを開きます。
1. {{< ui >}}Configure{{< /ui >}} タブで、{{< ui >}}Add Databricks Workspace{{< /ui >}} をクリックします。
1. ワークスペース名、Databricks ワークスペース URL、および生成したクライアント ID とシークレットを入力します。
- {{< img src="data_jobs/databricks/connect-workspace-form-m2m.png" alt="Datadog-Databricks インテグレーションタイルに Databricks ワークスペースが表示されます。このワークスペースには、名前、URL、クライアント ID、およびクライアントシークレットがあります。" style="width:100%;" >}}
-1. Data Observability: Jobs Monitoring または [Cloud Cost Management][18] で Databricks のコストを可視化するには、Datadog が[システムテーブル][20]をクエリするために使用できる [Databricks SQL Warehouse][19] の ID を提供します。
- - サービスプリンシパルは SQL Warehouse へのアクセス権を持っている必要があります。Warehouse の構成ページで、{{< ui >}}Permissions{{< /ui >}} (右上) に移動し、`CAN USE` の権限を付与します。
- - 次のコマンドを実行して、サービスプリンシパルに Unity Catalog [システムテーブル][20]への読み取りアクセス権限を付与します。
- ```sql
- GRANT USE CATALOG ON CATALOG system TO ;
- GRANT SELECT ON CATALOG system TO ;
- GRANT USE SCHEMA ON CATALOG system TO ;
- ```
- 権限を付与するユーザーは、`CATALOG system` で `MANAGE` の権限を持っている必要があります。
-
- - SQL Warehouse は Pro または Serverless である必要があります。Classic Warehouses はサポートされて**いません**。コストを削減するために、Auto Stop を 5 〜 10 分に設定した 2XS ウェアハウスを推奨します。
-1. **インテグレーションを設定する製品を選択する**セクションで、Data Observability: Jobs Monitoring が {{< ui >}}Enabled{{< /ui >}} であることを確認します。
-1. {{< ui >}}Datadog Agent Setup{{< /ui >}} セクションで、次のいずれかを選択します
- - [Datadog 管理 (推奨)](?tab=datadogmanagedglobalinitscriptrecommended#install-the-datadog-agent): Datadog は、ワークスペース内のグローバル init スクリプトで Agent をインストールおよび管理します。
- - [手動](?tab=manuallyinstallaglobalinitscript#install-the-datadog-agent): 以下の[手順](?tab=manuallyinstallaglobalinitscript#install-the-datadog-agent)に従って、Agent をグローバルにまたは特定の Databricks クラスターにインストールするための init スクリプトをインストールおよび管理します。
+ {{< img src="data_jobs/databricks/connect-workspace-form-m2m.png" alt="Datadog-Databricks インテグレーションタイルに、Databricks ワークスペースが表示されます。このワークスペースには、名前、URL、クライアント ID、およびクライアントシークレットがあります。" style="width:100%;" >}}
+1. Datadog がクエリを実行するための [Databricks SQL Warehouse][19] の ID を指定します。これにより、Jobs Monitoring または [Cloud Cost Management][18] で Databricks のコストを可視化し、[Quality Monitoring][21] を強化できます。
+ 1. Databricks で {{< ui >}}SQL Warehouses{{< /ui >}} に移動し、Datadog が使用するウェアハウスを選択します。Pro または Serverless である必要があります。Classic Warehouses はサポートされていません。コストを削減するには、Auto Stop を 5～10 分に設定した専用の 2XS ウェアハウスを使用します。
+ 1. ウェアハウスの概要ページから ID をコピーし (ウェアハウスの URL の最後のセグメントでもあります)、インテグレーションタイルに入力します。
+ 1. ウェアハウスの {{< ui >}}Permissions{{< /ui >}} タブ (右上) で、サービスプリンシパルに `CAN USE` を付与します。
+ 1. サービスプリンシパルに、Unity Catalog の [システムテーブル][20] への読み取りアクセス権を付与します。{{< ui >}}SQL Editor{{< /ui >}} で、サービスプリンシパルのクライアント ID (表示名ではありません) を使用して、次のコマンドを実行します。
+
+ ```sql
+ GRANT USE CATALOG ON CATALOG system TO ``;
+ GRANT USE SCHEMA ON CATALOG system TO ``;
+ GRANT SELECT ON CATALOG system TO ``;
+ ```
+
+ これらのコマンドを実行するユーザーには、 MANAGE ( CATALOG systemにおける) の権限が必要です。
+1. **インテグレーションを設定する製品を選択**セクションで、Data Observability: Jobs Monitoring が {{< ui >}}Enabled{{< /ui >}} になっていることを確認します。
+1. {{< ui >}}Datadog Agent Setup{{< /ui >}} セクションで、以下のいずれかを選択します。
+ - [Datadog による管理 (推奨)](?tab=datadogmanagedglobalinitscriptrecommended#install-the-datadog-agent): Datadog がワークスペース内のグローバル init script を使用して Agent をインストールおよび管理します。
+ - [手動](?tab=manuallyinstallaglobalinitscript#install-the-datadog-agent): [以下の手順](?tab=manuallyinstallaglobalinitscript#install-the-datadog-agent)に従って、Agent をグローバルまたは特定の Databricks クラスターにインストールするための init script をインストールおよび管理します。
[18]: https://docs.datadoghq.com/ja/cloud_cost_management/
[19]: https://docs.databricks.com/aws/en/compute/sql-warehouse/
[20]: https://docs.databricks.com/aws/en/admin/system-tables/
+[21]: /ja/data_observability/quality_monitoring/data_warehouses/databricks/
{{% /tab %}}
-{{% tab "プライベートリンク接続" %}}
+{{% tab "Private Link 接続" %}}
-Databricks ワークスペースが[プライベートリンク接続][25]を使用してデプロイされている場合、Datadog は Databricks API に直接アクセスできません。これには、環境にデプロイされた[プライベートアクションランナー][26]を使用する必要があります。
+Databricks ワークスペースが [Private Link 接続][25] を使用してデプロイされている場合、Datadog は Databricks API に直接アクセスできません。これには、環境内にデプロイされた [Private Action Runner][26] を使用する必要があります。
-完全なセットアップ手順については、[プライベートリンク接続 (プレビュー)][15]を参照してください。
+設定手順の詳細については、[Private Link 接続 (プレビュー)][15] を参照してください。
[15]: /ja/data_observability/jobs_monitoring/databricks/private_link
[25]: https://docs.databricks.com/aws/en/security/network/front-end/front-end-private-connect
@@ -94,37 +101,39 @@ Databricks ワークスペースが[プライベートリンク接続][25]を使
{{% /tab %}}
-{{% tab "個人用アクセストークン (レガシー) を使用する" %}}
+{{% tab "Personal Access Token (レガシー) を使用する" %}}
-このオプションは、2025 年 7 月 7 日以前に作成されたワークスペースインテグレーションにのみ利用可能です。新しいワークスペースインテグレーションは OAuth を使用して認証する必要があります。
+このオプションは、2025 年 7 月 7 日より前に作成されたワークスペースインテグレーションでのみ利用できます。新しいワークスペースインテグレーションでは、OAuth を使用して認証する必要があります。
-1. Databricks ワークスペースで、右上隅のプロフィールをクリックし、{{< ui >}}Settings{{< /ui >}} に移動します。左側のサイドバーで {{< ui >}}Developer{{< /ui >}} を選択します。{{< ui >}}Access tokens{{< /ui >}} の隣にある {{< ui >}}Manage{{< /ui >}} をクリックします。
-1. {{< ui >}}Generate new token{{< /ui >}} をクリックし、{{< ui >}}Comment{{< /ui >}} フィールドに「Datadog Integration」と入力し、{{< ui >}}Lifetime (days){{< /ui >}} の値を最大許可値 (730 日) に設定し、期限切れになる前にトークンを更新するリマインダーを作成します。その後、{{< ui >}}Generate{{< /ui >}} をクリックします。トークンをメモします。
+1. Databricks ワークスペースで、右上隅のプロフィールをクリックし、{{< ui >}}Settings{{< /ui >}} に移動します。左側のサイドバーで {{< ui >}}Developer{{< /ui >}} を選択します。{{< ui >}}Access tokens{{< /ui >}} の横にある {{< ui >}}Manage{{< /ui >}} をクリックします。
+1. {{< ui >}}Generate new token{{< /ui >}} をクリックし、{{< ui >}}Comment{{< /ui >}} フィールドに「Datadog Integration」と入力し、{{< ui >}}Lifetime (days){{< /ui >}} の値を最大許容値 (730 日) に設定して、トークンの有効期限前に更新するリマインダーを作成します。次に {{< ui >}}Generate{{< /ui >}} をクリックします。トークンを控えておきます。
**重要:**
- * Datadog 管理の init スクリプトインストール (推奨)[](?tab=datadogmanagedglobalinitscriptrecommended#install-the-datadog-agent) の場合、トークンのプリンシパルがワークスペース管理者であることを確認します。
- * 手動 init スクリプトインストールの場合、モニター対象の Databricks のジョブとクラスターに対してトークンのプリンシパルが [CAN VIEW アクセス][9]権限を持っていることを確認します。
+ * [Datadog による init script のインストール (推奨)](?tab=datadogmanagedglobalinitscriptrecommended#install-the-datadog-agent) の場合、トークンの Principal が Workspace Admin であることを確認します。
+ * 手動で init script をインストールする場合は、トークンの Principal が、監視対象の Databricks ジョブおよびクラスターに対する [CAN VIEW access][9] 権限を持っていることを確認します。
- また、[公式の Databricks ドキュメント][10]に従って[サービスプリンシパル][11]用のアクセストークンを生成することもできます。サービスプリンシパルは、[ワークスペースアクセスエンタイトルメント][17]が有効であり、上記のようにワークスペース管理者または [CAN VIEW アクセス][9]権限を持っている必要があります。
+ 代わりに、[公式の Databricks ドキュメント][10] に従って、[サービスプリンシパル][11] のアクセストークンを生成します。サービスプリンシパルでは、[Workspace access エンタイトルメント][17] が有効になっており、かつ、上記で説明した Workspace Admin または [CAN VIEW access][9] の権限が付与されている必要があります。
1. Datadog で、Databricks インテグレーションタイルを開きます。
1. {{< ui >}}Configure{{< /ui >}} タブで、{{< ui >}}Add Databricks Workspace{{< /ui >}} をクリックします。
-1. ワークスペース名、Databricks ワークスペース URL、生成した Databricks トークンを入力します。
- {{< img src="data_jobs/databricks/configure-workspace-form.png" alt="Datadog-Databricks インテグレーションタイルに Databricks ワークスペースが表示されます。このワークスペースには、名前、URL、および API トークンがあります。" style="width:100%;" >}}
-1. Data Observability: Jobs Monitoring または [Cloud Cost Management][18] で Databricks のコストを可視化するには、Datadog が[システムテーブル][20]をクエリするために使用できる [Databricks SQL Warehouse][19] の ID を提供します。
-
- - トークンのプリンシパルは、SQL Warehouse へのアクセス権を持っている必要があります。Warehouse 構成ページの右上にある**アクセス許可**から `CAN USE` の権限を付与します。
- - 次のコマンドを実行して、サービスプリンシパルに Unity Catalog [システムテーブル][20]への読み取りアクセス権限を付与します。
- ```sql
- GRANT USE CATALOG ON CATALOG system TO ;
- GRANT SELECT ON CATALOG system TO ;
- GRANT USE SCHEMA ON CATALOG system TO ;
- ```
- 権限を付与するユーザーは、`CATALOG system` で `MANAGE` の権限を持っている必要があります。
- - SQL Warehouse は Pro または Serverless である必要があります。Classic Warehouses はサポートされて**いません**。コストを最小限に抑えるために、Auto Stop を 5 〜 10 分に設定した 2XS サイズのウェアハウスを推奨します。
-1. **インテグレーションを設定する製品を選択する**セクションで、Data Observability: Jobs Monitoring 製品が**有効**であることを確認します。
-1. {{< ui >}}Datadog Agent Setup{{< /ui >}} セクションで、次のいずれかを選択します
- - [Datadog 管理 (推奨)](?tab=datadogmanagedglobalinitscriptrecommended#install-the-datadog-agent): Datadog は、ワークスペース内のグローバル init スクリプトで Agent をインストールおよび管理します。
- - [手動](?tab=manuallyinstallaglobalinitscript#install-the-datadog-agent): 以下の[手順](?tab=manuallyinstallaglobalinitscript#install-the-datadog-agent)に従って、Agent をグローバルにまたは特定の Databricks クラスターにインストールするための init スクリプトをインストールおよび管理します。
+1. ワークスペース名、Databricks ワークスペース URL、および生成した Databricks トークンを入力します。
+ {{< img src="data_jobs/databricks/configure-workspace-form.png" alt="Datadog-Databricks インテグレーションタイルに、Databricks ワークスペースが表示されます。このワークスペースには、名前、URL、および API トークンがあります。" style="width:100%;" >}}
+1. Datadog がクエリを実行するための [Databricks SQL Warehouse][19] の ID を指定します。これにより、Jobs Monitoring または [Cloud Cost Management][18] で Databricks のコストを可視化し、[Quality Monitoring][21] を強化できます。
+ 1. Databricks で {{< ui >}}SQL Warehouses{{< /ui >}} に移動し、Datadog が使用するウェアハウスを選択します。Pro または Serverless である必要があります。Classic Warehouses はサポートされていません。コストを削減するには、Auto Stop を 5～10 分に設定した専用の 2XS ウェアハウスを使用します。
+ 1. ウェアハウスの概要ページから ID をコピーし (ウェアハウスの URL の最後のセグメントでもあります)、インテグレーションタイルに入力します。
+ 1. ウェアハウスの {{< ui >}}Permissions{{< /ui >}} タブ (右上) で、トークンの Principal に `CAN USE` を付与します。
+ 1. トークンの Principal に、Unity Catalog の [システムテーブル][20] への読み取りアクセス権を付与します。{{< ui >}}SQL Editor{{< /ui >}} で、Principal のクライアント ID (表示名ではありません) を使用して、次のコマンドを実行します。
+
+ ```sql
+ GRANT USE CATALOG ON CATALOG system TO ``;
+ GRANT USE SCHEMA ON CATALOG system TO ``;
+ GRANT SELECT ON CATALOG system TO ``;
+ ```
+
+ これらのコマンドを実行するユーザーには、 MANAGE ( CATALOG systemにおける) の権限が必要です。
+1. **インテグレーションを設定する製品を選択**セクションで、Data Observability: Jobs Monitoring 製品が **Enabled** になっていることを確認します。
+1. {{< ui >}}Datadog Agent Setup{{< /ui >}} セクションで、以下のいずれかを選択します。
+ - [Datadog による管理 (推奨)](?tab=datadogmanagedglobalinitscriptrecommended#install-the-datadog-agent): Datadog がワークスペース内のグローバル init script を使用して Agent をインストールおよび管理します。
+ - [手動](?tab=manuallyinstallaglobalinitscript#install-the-datadog-agent): [以下の手順](?tab=manuallyinstallaglobalinitscript#install-the-datadog-agent)に従って、Agent をグローバルまたは特定の Databricks クラスターにインストールするための init script をインストールおよび管理します。
[9]: https://docs.databricks.com/en/security/auth-authz/access-control/index.html#job-acls
[10]: https://docs.databricks.com/en/admin/users-groups/service-principals.html#manage-personal-access-tokens-for-a-service-principal
@@ -133,6 +142,7 @@ Databricks ワークスペースが[プライベートリンク接続][25]を使
[18]: https://docs.datadoghq.com/ja/cloud_cost_management
[19]: https://docs.databricks.com/aws/en/compute/sql-warehouse/
[20]: https://docs.databricks.com/aws/en/admin/system-tables/
+[21]: /ja/data_observability/quality_monitoring/data_warehouses/databricks/
{{% /tab %}}
@@ -141,47 +151,47 @@ Databricks ワークスペースが[プライベートリンク接続][25]を使
### Datadog Agent をインストールする {#install-the-datadog-agent}
-Datadog Agent は、全用途またはジョブクラスターで実行される Databricks のジョブをモニターするために Databricks クラスターにインストールする必要があります。このステップは、[サーバーレスコンピュート][4]上のジョブをモニターすることには必要ありません。
+Datadog Agent は、All-Purpose クラスターまたは Job クラスターで実行される Databricks ジョブを監視するために、Databricks クラスターにインストールする必要があります。この手順は、[サーバーレスコンピューティング][4] 上のジョブを監視する場合には不要です。
{{< tabs >}}
-{{% tab "Datadog 管理のグローバル init スクリプト (推奨)" %}}
+{{% tab "Datadog による管理のグローバル init script (推奨)" %}}
-Datadog は、Databricks ワークスペースでグローバル init スクリプトをインストールおよび管理できます。Datadog Agent は、ワークスペース内のすべてのクラスターが起動する際にインストールされます。
+Datadog は、Databricks ワークスペース内でグローバル init script をインストールおよび管理できます。Datadog Agent は、ワークスペース内のすべてのクラスターの起動時にインストールされます。
-- このセットアップは、スタンダードアクセスモードの Databricks クラスターでは機能しません。グローバル init スクリプトはそれらのクラスターにインストールできないからです。スタンダードアクセスモードのクラスターを使用している場合、Datadog は複数のクラスターにわたってクラスターポリシーを手動で構成するまたは特定のクラスターに手動でインストールすることを推奨します。
-- このインストールオプションでは、Datadog が Datadog グローバル init スクリプトをインストールおよび管理します。Databricks アクセストークンがワークスペース管理者の権限を持っている必要があります。CAN VIEW アクセス権限を持つトークンでは、Datadog が Databricks アカウントのグローバル init スクリプトを管理することはできません。
+- この設定は、Standard アクセスモードの Databricks クラスターでは機能しません。これは、それらのクラスターにはグローバル init script をインストールできないためです。Standard アクセスモードのクラスターを使用している場合、Datadog では、複数のクラスターにわたってクラスターポリシーを手動で構成するか、特定のクラスターに手動でインストールすることを推奨しています。
+- Datadog が Datadog グローバル init script をインストールおよび管理するこのインストールオプションには、Workspace Admin 権限を持つ Databricks アクセストークンが必要です。CAN VIEW access 権限を持つトークンでは、Datadog が Databricks アカウントのグローバル init script を管理することはできません。
-#### ワークスペースを Datadog と統合する場合 {#when-integrating-a-workspace-with-datadog}
+#### ワークスペースを Datadog とインテグレーションする場合 {#when-integrating-a-workspace-with-datadog}
-1. **インテグレーションを設定する製品を選択する**セクションで、Data Observability: Jobs Monitoring 製品が**有効**であることを確認します。
+1. **インテグレーションを設定する製品を選択**セクションで、Data Observability: Jobs Monitoring 製品が **Enabled** になっていることを確認します。
1. {{< ui >}}Datadog Agent Setup{{< /ui >}} セクションで、{{< ui >}}Managed by Datadog{{< /ui >}} トグルボタンを選択します。
1. {{< ui >}}Select API Key{{< /ui >}} をクリックして、既存の Datadog API キーを選択するか、新しい Datadog API キーを作成します。
-1. (オプション) ジョブと相関させるためにドライバーおよびワーカーログを収集したくない場合は、{{< ui >}}Enable Log Collection{{< /ui >}} を無効にします。
+1. (オプション) ジョブとの関連付けに使用するドライバーおよびワーカーのログを収集しない場合は、{{< ui >}}Enable Log Collection{{< /ui >}} を無効にします。
1. {{< ui >}}Save Databricks Workspace{{< /ui >}} をクリックします。
- {{< img src="data_jobs/databricks/configure-data-jobs-monitoring-new-2.png" alt="Datadog-Databricks インテグレーションタイルにおける Databricks ワークスペースを追加する場合の Datadog Agent のセットアップ。Datadog は、グローバル init スクリプトをインストールおよび管理できます。" style="width:100%;" >}}
+ {{< img src="data_jobs/databricks/configure-data-jobs-monitoring-new-2.png" alt="Datadog-Databricks インテグレーションタイルで、Databricks ワークスペースを追加する際の Datadog Agent セットアップを行います。Datadog は、グローバル init script をインストールおよび管理できます。" style="width:100%;" >}}
-#### Datadog と統合済みの Databricks ワークスペースに init スクリプトを追加する場合 {#when-adding-the-init-script-to-a-databricks-workspace-already-integrated-with-datadog}
+#### Datadog とすでにインテグレーションされている Databricks ワークスペースに init script を追加する場合 {#when-adding-the-init-script-to-a-databricks-workspace-already-integrated-with-datadog}
-1. **構成**タブで、ワークスペースのリストからワークスペースをクリックします
-1. {{< ui >}}Configured Products{{< /ui >}} タブをクリックします
-1. Data Observability: Jobs Monitoring 製品が**有効**になっていることを確認します。
+1. **Configure** タブで、ワークスペースのリストからワークスペースをクリックします。
+1. {{< ui >}}Configured Products{{< /ui >}} タブをクリックします。
+1. Data Observability: Jobs Monitoring 製品が **Enabled** になっていることを確認します。
1. {{< ui >}}Datadog Agent Setup{{< /ui >}} セクションで、{{< ui >}}Managed by Datadog{{< /ui >}} トグルボタンを選択します。
1. {{< ui >}}Select API Key{{< /ui >}} をクリックして、既存の Datadog API キーを選択するか、新しい Datadog API キーを作成します。
-1. (オプション) ジョブと相関させるためにドライバーおよびワーカーログを収集したくない場合は、{{< ui >}}Enable Log Collection{{< /ui >}} を無効にします。
-1. ブラウザウィンドウの下部にある **Databricks Workspace を保存**をクリックします。
- {{< img src="data_jobs/databricks/configure-data-jobs-monitoring-existing.png" alt="Datadog-Databricks インテグレーションタイルにおけるインテグレーションに追加された Databricks ワークスペースの Datadog Agent のセットアップ。Datadog は、グローバル init スクリプトをインストールおよび管理できます。" style="width:100%;" >}}
+1. (オプション) ジョブとの関連付けに使用するドライバーおよびワーカーのログを収集しない場合は、{{< ui >}}Enable Log Collection{{< /ui >}} を無効にします。
+1. ブラウザウィンドウの下部にある **Save Databricks Workspace** をクリックします。
+ {{< img src="data_jobs/databricks/configure-data-jobs-monitoring-existing.png" alt="Datadog-Databricks インテグレーションタイルで、インテグレーションにすでに追加されている Databricks ワークスペースの Datadog Agent セットアップを行います。Datadog は、グローバル init script をインストールおよび管理できます。" style="width:100%;" >}}
-必要に応じて、Databricks UI のクラスターの {{< ui >}}Advanced Configuration{{< /ui >}} セクションで、または Databricks API で [Spark 環境変数][2]として以下の環境変数を構成することにより、Databricks クラスターおよび Spark パフォーマンスメトリクスにタグを追加できます。
+オプションで、Databricks UI のクラスターの {{< ui >}}Advanced Configuration{{< /ui >}} セクションで、または Databricks API を使用して [Spark env vars][2] として以下の環境変数を構成することにより、Databricks クラスターおよび Spark パフォーマンスメトリクスにタグを追加できます。
| 変数 | 説明 |
|--------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| DD_TAGS | Databricks クラスターと Spark パフォーマンスメトリクスにタグを追加します。カンマまたはスペースで区切られた key:value ペア。[Datadog タグ規約][1]に従います。例: `env:staging,team:data_engineering` |
-| DD_ENV | このクラスターからのメトリクス、トレース、およびログに `env` 環境タグを設定します。|
-| DD_LOGS_CONFIG_PROCESSING_RULES | 処理ルールで収集されたログをフィルタリングします。詳細については、[高度なログ収集][3]を参照してください。|
+| DD_TAGS | Databricks クラスターおよび Spark パフォーマンスメトリクスにタグを追加します。カンマまたはスペースで区切られた key:value ペア。[Datadog タグ規則][1] に従います。例: `env:staging,team:data_engineering` |
+| DD_ENV | このクラスターからのメトリクス、トレース、およびログの `env` 環境タグを上書きします。デフォルトでは、Databricks ワークスペース名が env として使用されます。|
+| DD_LOGS_CONFIG_PROCESSING_RULES | 処理ルールを使用して収集されたログをフィルタリングします。詳細については、[高度なログ収集][3] を参照してください。|
[1]: /ja/getting_started/tagging/
@@ -191,13 +201,13 @@ Datadog は、Databricks ワークスペースでグローバル init スクリ
{{% /tab %}}
-{{% tab "クラスターポリシーを手動で構成します。" %}}
+{{% tab "クラスターポリシーを手動で構成する" %}}
-このアプローチは**スタンダード**アクセスモードのクラスターに推奨されます。
+この方法は、**Standard** アクセスモードのクラスターに推奨されます。
-**init スクリプトを作成する**
+**init script を作成する**
-1. Databricks で、次の内容の init スクリプトファイルを [Unity Catalog ボリューム][26]に作成します。ボリュームパスをメモしておくことを忘れないでください (例: `/Volumes/catalog_name/schema_name/volume_name/datadog-init-script.sh`)。
+1. Databricks で、以下の内容を含む init script ファイルを [Unity Catalog ボリューム][26] に作成します。ボリュームパスを必ず控えておきます (例: `/Volumes/catalog_name/schema_name/volume_name/datadog-init-script.sh`)。
```shell
#!/bin/bash
@@ -209,50 +219,52 @@ Datadog は、Databricks ワークスペースでグローバル init スクリ
The script above downloads and runs the latest init script for Data Observability: Jobs Monitoring in Databricks. If you want to pin your script to a specific version, you can replace the filename in the URL with `install-databricks-0.14.0.sh` to use version `0.14.0`, for example. The source code used to generate this script, and the changes between script versions, can be found on the [Datadog Agent repository][3].
-1. init スクリプトに読み取り専用権限を付与します。
- 1. ボリュームレベルですべてのアカウントユーザーに `READ VOLUME` 権限を付与します。
- 1. カタログレベルですべてのアカウントユーザーに `USE CATALOG` 権限を付与します。
+1. init script への読み取り専用権限を付与します。
+ 1. ボリュームレベルで、すべてのアカウントユーザーに `READ VOLUME` 権限を付与します。
+ 1. カタログレベルで、すべてのアカウントユーザーに `USE CATALOG` 権限を付与します。
-1. **init スクリプトを許可リストに追加する**: **スタンダード**アクセスモードのクラスターでは、init スクリプトパスを Unity Catalog 許可リストに追加する必要があります。[Databricks のドキュメント][27]の指示に従って、init スクリプトパスを許可リストに追加します。
+ Databricks は、Unity Catalog ボリュームの権限を、クラスターを実行している Principal ではなく、クラスター所有者に対して評価します。
-**コンピュートポリシーを構成する**
+1. **init script を許可リストに追加する**: **Standard** アクセスモードのクラスターの場合、init script のパスを Unity Catalog の許可リストに追加する必要があります。[Databricks ドキュメント][27] の手順に従って、init script のパスを許可リストに追加します。
-1. {{< ui >}}Compute{{< /ui >}} で、{{< ui >}}Policies{{< /ui >}} タブに移動します。すでにクラスターに適用済みのクラスターポリシーがある場合は、その既存のポリシーに移動して編集します。このポリシーはそれを使用するすべてのクラスターに自動的に適用されるため、より簡単なアプローチとなります。そうでない場合は、{{< ui >}}Create Policy{{< /ui >}} をクリックして新しいポリシーを作成します。
-1. init スクリプトをクラスターポリシーに追加するには、{{< ui >}}Definition{{< /ui >}} セクションで {{< ui >}}Add Definition{{< /ui >}} をクリックします。開いたモーダルで、フィールドに入力します。
- 1. {{< ui >}}Field{{< /ui >}} ドロップダウンで {{< ui >}}init_scripts{{< /ui >}} を選択します。
- 1. {{< ui >}}Source{{< /ui >}} ドロップダウンで {{< ui >}}Volume{{< /ui >}} を選択します。
- 1. {{< ui >}}Destination{{< /ui >}} で init スクリプトへのボリュームパスを入力します。
+**コンピューティングポリシーを構成する**
+
+1. {{< ui >}}Compute{{< /ui >}} で、{{< ui >}}Policies{{< /ui >}} タブに移動します。クラスターにすでにクラスターポリシーが適用されている場合は、その既存のポリシーに移動して編集します。このポリシーは、それを使用するすべてのクラスターに自動的に適用されるため、こちらの方が簡単な方法です。それ以外の場合は、{{< ui >}}Create Policy{{< /ui >}} をクリックして新しいポリシーを作成します。
+1. init script をクラスターポリシーに追加するには、{{< ui >}}Definition{{< /ui >}} セクションで {{< ui >}}Add Definition{{< /ui >}} をクリックします。開いたモーダルで、各フィールドに入力します。
+ 1. {{< ui >}}Field{{< /ui >}} ドロップダウンで、{{< ui >}}init_scripts{{< /ui >}} を選択します。
+ 1. {{< ui >}}Source{{< /ui >}} ドロップダウンで、{{< ui >}}Volume{{< /ui >}} を選択します。
+ 1. {{< ui >}}Destination{{< /ui >}} の下に、init script へのボリュームパスを入力します。
1. {{< ui >}}Add{{< /ui >}} をクリックします。
-1. 環境変数を構成します。作成したクラスターポリシーに以下の環境変数を追加する必要があります。
+1. 環境変数を構成します。作成したクラスターポリシーに、以下の各環境変数を追加する必要があります。
| キー | 説明 |
|----------------------|------------------------------|
| DD_API_KEY | [Datadog API キー][1]。 |
- | DD_SITE | Your [Datadog サイト][2]。 |
- | DATABRICKS_WORKSPACE | Databricks ワークスペースの名前。[Datadog-Databricks インテグレーションステップ](#configure-the-datadog-databricks-integration)で提供された名前と一致する必要があります。名前に空白が含まれている場合は、二重引用符で囲みます。|
+ | DD_SITE | [Datadog サイト][2]。 |
+ | DATABRICKS_WORKSPACE | Databricks ワークスペースの名前。これは、[Datadog-Databricks インテグレーションの手順](#configure-the-datadog-databricks-integration)で指定した名前と一致している必要があります。|
- 1. 上記の各変数について、{{< ui >}}Definition{{< /ui >}} セクションで {{< ui >}}Add Definition{{< /ui >}} をクリックします。開いたモーダルで、フィールドに入力します。
- 1. {{< ui >}}Field{{< /ui >}} ドロップダウンで {{< ui >}}spark_env_vars{{< /ui >}} を選択します。
- 1. {{< ui >}}Key{{< /ui >}} フィールドで環境変数キーを入力します。
- 1. {{< ui >}}Value{{< /ui >}} フィールドで環境変数の値を入力します。
- 1. {{< ui >}}Type{{< /ui >}} ドロップダウンで {{< ui >}}Fixed{{< /ui >}} を選択します。
- 1. 機密性の高い値の露出を減らすために {{< ui >}}Hidden{{< /ui >}} チェックボックスをオンにします。
- 1. オプションで、他の init スクリプトパラメーターや Datadog 環境変数を設定できます。例えば、`DD_ENV` および `DD_SERVICE` などです。次のパラメーターを使用してスクリプトを構成できます。
+ 1. 上記の各変数について、{{< ui >}}Definition{{< /ui >}} セクションで {{< ui >}}Add Definition{{< /ui >}} をクリックします。開いたモーダルで、各フィールドに入力します。
+ 1. {{< ui >}}Field{{< /ui >}} ドロップダウンで、{{< ui >}}spark_env_vars{{< /ui >}} を選択します。
+ 1. {{< ui >}}Key{{< /ui >}} フィールドに、環境変数キーを入力します。
+ 1. {{< ui >}}Value{{< /ui >}} フィールドに、環境変数の値を入力します。
+ 1. {{< ui >}}Type{{< /ui >}} ドロップダウンで、{{< ui >}}Fixed{{< /ui >}} を選択します。
+ 1. 機密値の露出を減らすには、{{< ui >}}Hidden{{< /ui >}} チェックボックスをオンにします。
+ 1. 必要に応じて、その他の init script パラメータや Datadog 環境変数 (例: `DD_ENV` や `DD_SERVICE`) を設定します。以下のパラメータを使用してスクリプトを構成できます。
| 変数 | 説明 | デフォルト |
|--------------------------| ------------------------------------------------------------------------------------------------------------------------------------------------------------------| ---------|
- | DRIVER_LOGS_ENABLED | Datadog でスパークドライバーログを収集します。 | false |
- | WORKER_LOGS_ENABLED | Datadog でスパークワーカーログを収集します。 | false |
- | DD_TAGS | カンマまたはスペースで区切られた key:value ペアを使用して、Databricks クラスターおよび Spark パフォーマンスメトリクスにタグを追加します。[Datadog タグ規約][4]に従います。例: `env:staging,team:data_engineering` | |
- | DD_ENV | このクラスターからのメトリクス、トレース、およびログに `env` 環境タグを設定します。 | |
- | DD_LOGS_CONFIG_PROCESSING_RULES | 処理ルールで収集されたログをフィルタリングします。詳細については、[高度なログ収集][5]を参照してください。| |
+ | DRIVER_LOGS_ENABLED | Datadog で Spark ドライバーログを収集します。 | false |
+ | WORKER_LOGS_ENABLED | Datadog で Spark ワーカーログを収集します。 | false |
+ | DD_TAGS | Databricks クラスターおよび Spark パフォーマンスメトリクスにタグを追加します。カンマまたはスペースで区切られた key:value ペア。[Datadog タグ規則][4] に従います。例: `env:staging,team:data_engineering` | |
+ | DD_ENV | このクラスターからのメトリクス、トレース、およびログの `env` 環境タグを上書きします。デフォルトでは、Databricks ワークスペース名が env として使用されます。 | |
+ | DD_LOGS_CONFIG_PROCESSING_RULES | 処理ルールを使用して収集されたログをフィルタリングします。詳細については、[高度なログ収集][5] を参照してください。| |
-1. 新しいポリシーを作成する場合は {{< ui >}}Create{{< /ui >}} をクリックし、既存のポリシーを更新する場合は {{< ui >}}Save{{< /ui >}} をクリックします。既存のポリシーを更新する場合、そのポリシーを使用しているすべてのクラスターは次回の再起動時に自動的に変更を適用します。新しいポリシーを作成する場合は、以下の手順に従ってクラスターに適用します。
+1. 新しいポリシーを作成する場合は {{< ui >}}Create{{< /ui >}} を、既存のポリシーを更新する場合は {{< ui >}}Save{{< /ui >}} をクリックします。既存のポリシーを更新した場合、そのポリシーを使用しているすべてのクラスターに、次回の再起動時に変更が自動的に適用されます。新しいポリシーを作成した場合は、以下の手順に従ってクラスターに適用します。
-**クラスターポリシーをクラスターに適用する**
+**クラスターにクラスターポリシーを適用する**
-1. {{< ui >}}Compute{{< /ui >}}で、更新したいクラスターを選択するか、新しいクラスター用に {{< ui >}}Create Compute{{< /ui >}} をクリックします。
-1. 上部の {{< ui >}}Policy{{< /ui >}} ドロップダウンで、作成したクラスターポリシーを選択します。
+1. {{< ui >}}Compute{{< /ui >}} で、更新するクラスターを選択するか、新しいクラスターの場合は {{< ui >}}Create Compute{{< /ui >}} をクリックします。
+1. 上部の {{< ui >}}Policy{{< /ui >}} ドロップダウンで、作成したポリシーを選択します。
1. {{< ui >}}Confirm{{< /ui >}} をクリックして変更を保存します。ポリシーを有効にするには、クラスターを再起動する必要があります。
[1]: https://app.datadoghq.com/organization-settings/api-keys
@@ -265,16 +277,16 @@ Datadog は、Databricks ワークスペースでグローバル init スクリ
{{% /tab %}}
-{{% tab "グローバル init スクリプトを手動でインストールする" %}}
+{{% tab "グローバル init script を手動でインストールする" %}}
-このセットアップは、
スタンダードアクセスモードの Databricks クラスターでは機能しません。グローバル init スクリプトはそれらのクラスターにインストールできないからです。
スタンダードアクセスモードのクラスターを使用している場合、Datadog は
クラスターポリシーを手動で構成するまたは
特定のクラスターに手動でインストールすることを推奨します。
+この設定は、
Standard アクセスモードの Databricks クラスターでは機能しません。Standard アクセスモードのクラスターには、グローバル init script をインストールできないためです。
Standard アクセスモードのクラスターを使用している場合、Datadog では
クラスターポリシーを手動で構成するか
特定のクラスターに手動でインストールすることを推奨しています。
Databricks は、Unity Catalog ボリュームの権限を、クラスターを実行している Principal ではなく、クラスター所有者に対して評価します。
-1. **init スクリプトを許可リストに追加する** (**スタンダード**アクセスモードクラスターに必要): クラスターが**スタンダード**アクセスモードを使用している場合、init スクリプトのパスを Unity Catalog 許可リストに追加する必要があります。[Databricks のドキュメント][27]の指示に従って、init スクリプトパスを許可リストに追加します。
+1. **init script を許可リストに追加します** (**Standard** アクセスモードのクラスターで必須): クラスターで **Standard** アクセスモードを使用している場合は、init script のパスを Unity Catalog の許可リストに追加する必要があります。[Databricks ドキュメント][27] の手順に従って、init script のパスを許可リストに追加します。
1. クラスター構成ページで、{{< ui >}}Advanced options{{< /ui >}} トグルをクリックします。
-1. ページ下部の {{< ui >}}Init Scripts{{< /ui >}} タブに移動します。
+1. ページ下部で、{{< ui >}}Init Scripts{{< /ui >}} タブを開きます。
- {{< img src="data_jobs/databricks/init_scripts.png" alt="Databricks UI、クラスター構成の高度なオプション、Init スクリプトタブ。「Destination」ドロップダウンと「Init スクリプトパス」ファイルセレクター。" style="width:80%;" >}}
+ {{< img src="data_jobs/databricks/init_scripts.png" alt="Databricks UI、クラスター構成の高度なオプション、Init Scripts タブ。[Destination] ドロップダウンと [Init script path] ファイルセレクター。" style="width:80%;" >}}
- - {{< ui >}}Destination{{< /ui >}} ドロップダウンで {{< ui >}}Volume{{< /ui >}} を選択します。
- - {{< ui >}}Init script path{{< /ui >}} で init スクリプトへのボリュームパスを入力します。
+ - {{< ui >}}Destination{{< /ui >}} ドロップダウンで、{{< ui >}}Volume{{< /ui >}} を選択します。
+ - {{< ui >}}Init script path{{< /ui >}} の下に、init script へのボリュームパスを入力します。
- {{< ui >}}Add{{< /ui >}} をクリックします。
-#### 必要な init スクリプトパラメーターを設定する {#set-the-required-init-script-parameters-1}
+#### 必要な init script パラメータを設定する {#set-the-required-init-script-parameters-1}
1. Databricks のクラスター構成ページで、{{< ui >}}Advanced options{{< /ui >}} トグルをクリックします。
-2. ページ下部の {{< ui >}}Spark{{< /ui >}} タブに移動します。
- {{< img src="data_jobs/databricks/configure-databricks-cluster-init-script-quoted.png" alt="Databricks UI、クラスター構成の高度なオプション、Spark タブ。「環境変数」というタイトルのテキストボックスには、DD_API_KEY と DD_SITE の値が含まれます。" style="width:100%;" >}}
+2. ページ下部で、{{< ui >}}Spark{{< /ui >}} タブを開きます。
+ {{< img src="data_jobs/databricks/configure-databricks-cluster-init-script.png" alt="Databricks UI、クラスター構成の高度なオプション、Spark タブ。[Environment variables] というタイトルのテキストボックスに、DD_API_KEY と DD_SITE の値が含まれています。" style="width:100%;" >}}
- {{< ui >}}Environment variables{{< /ui >}} テキストボックスに、init スクリプトパラメーターの値を入力します。
+ {{< ui >}}Environment variables{{< /ui >}} テキストボックスに、init script パラメータの値を入力します。
```text
DD_API_KEY=
DD_SITE=
- DATABRICKS_WORKSPACE=""
+ DATABRICKS_WORKSPACE=
```
- オプションとして、ここで `DD_ENV` や `DD_SERVICE` などの他の init スクリプトパラメーターおよび Datadog 環境変数を設定することもできます。以下のパラメーターを使用してスクリプトを構成できます。
+ 必要に応じて、ここで他の init script パラメータや Datadog 環境変数 (`DD_ENV` や `DD_SERVICE` など) を設定することもできます。スクリプトは、次のパラメータを使用して構成できます。
| 変数 | 説明 | デフォルト |
|--------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------|
| DD_API_KEY | [Datadog API キー][1]。 | |
| DD_SITE | [Datadog サイト][2]。 | |
-| DATABRICKS_WORKSPACE | Databricks ワークスペースの名前。[Datadog-Databricks インテグレーションステップ](#configure-the-datadog-databricks-integration)で提供された名前と一致する必要があります。名前に空白が含まれている場合は、二重引用符で囲みます。| |
-| DRIVER_LOGS_ENABLED | Datadog でスパークドライバーログを収集します。 | false |
-| WORKER_LOGS_ENABLED | Datadog でスパークワーカーログを収集します。 | false |
-| DD_TAGS | Databricks クラスターと Spark パフォーマンスメトリクスにタグを追加します。カンマまたはスペースで区切られた key:value ペア。[Datadog タグ規約][4]に従います。例: `env:staging,team:data_engineering` | |
-| DD_ENV | このクラスターからのメトリクス、トレース、およびログに `env` 環境タグを設定します。 | |
-| DD_LOGS_CONFIG_PROCESSING_RULES | 処理ルールで収集されたログをフィルタリングします。詳細については、[高度なログ収集][5]を参照してください。| |
+| DATABRICKS_WORKSPACE | Databricks ワークスペースの名前。これは、[Datadog-Databricks インテグレーションの手順](#configure-the-datadog-databricks-integration)で指定した名前と一致している必要があります。| |
+| DRIVER_LOGS_ENABLED | Datadog で Spark ドライバーログを収集します。 | false |
+| WORKER_LOGS_ENABLED | Datadog で Spark ワーカーログを収集します。 | false |
+| DD_TAGS | Databricks クラスターおよび Spark パフォーマンスメトリクスにタグを追加します。カンマまたはスペースで区切られた key:value ペア。[Datadog タグ規則][4] に従います。例: `env:staging,team:data_engineering` | |
+| DD_ENV | このクラスターからのメトリクス、トレース、およびログの `env` 環境タグを上書きします。デフォルトでは、Databricks ワークスペース名が env として使用されます。 | |
+| DD_LOGS_CONFIG_PROCESSING_RULES | 処理ルールを使用して収集されたログをフィルタリングします。詳細については、[高度なログ収集][5] を参照してください。| |
[1]: https://app.datadoghq.com/organization-settings/api-keys
@@ -393,75 +411,109 @@ export DATABRICKS_WORKSPACE=""
{{< /tabs >}}
-### すでに実行中のクラスターを再起動する {#restart-already-running-clusters}
+### 実行中のクラスターを再起動する {#restart-already-running-clusters}
-init スクリプトは、クラスターが起動する際に Agent をインストールします。
+init script は、クラスターの起動時に Agent をインストールします。
-すでに実行中の all-purpose クラスターまたは long-lived ジョブクラスターは、init スクリプトが Datadog Agent をインストールするために手動で再起動する必要があります。
+実行中の汎用クラスターや長時間稼働するジョブクラスターは、init script で Datadog Agent をインストールするために手動で再起動する必要があります。
-ジョブクラスターで実行されるスケジュールされたジョブについては、init スクリプトが次回の実行時に自動的に Datadog Agent をインストールします。
+ジョブクラスターで実行されるスケジュール済みジョブの場合、init script は次回の実行時に Datadog Agent を自動的にインストールします。
## 検証 {#validation}
-Datadog で [Data Observability: Jobs Monitoring][6] ページを表示すると、Databricks のすべてのジョブリストが表示されます。
+Datadog で [Data Observability: Jobs Monitoring][6] ページを表示し、すべての Databricks ジョブの一覧を確認します。
-一部のジョブが表示されない場合は、[構成][9]ページに移動して理由を確認してください。このページには、Agent がクラスターにまだ構成されていないすべての Databricks ジョブがリストされており、セットアップを完了するためのガイダンスが含まれています。
+一部のジョブが表示されない場合は、[構成][9] ページを開いて、その理由を確認します。このページには、クラスターに Datadog Agent がまだ構成されていないすべての Databricks ジョブと、セットアップを完了するための手順が一覧表示されます。
## トラブルシューティング {#troubleshooting}
-製品をインストールした後、DJM にデータが表示されない場合は、以下の手順に従います。
+製品のインストール後に Jobs Monitoring にデータが表示されない場合は、次の手順に従います。
+
+### init script が実行されない、または失敗する {#init-script-not-running-or-failing}
+
+1. **クラスターを再起動する**: init script はクラスターの起動時にのみ実行されます。init script を追加してからクラスターを再起動したことを確認します。
+1. **init script が実行されたことを確認する**: Databricks でクラスターをクリックし、{{< ui >}}Event log{{< /ui >}} タブを開きます。`INIT_SCRIPTS_STARTED` が存在しない場合、このクラスターで init script が読み込まれていません。[インストール手順](#install-the-datadog-agent)に戻り、init script がクラスターに追加されていることを確認します。
+1. **init script が正常に完了したことを確認する**: イベントログで `INIT_SCRIPTS_FINISHED` アクションを見つけてクリックし、JSON を確認します。これにより、init script が失敗して終了したかどうかを確認できます。
+1. **init script の失敗を調査する**: `INIT_SCRIPTS_FINISHED` に失敗が表示される場合は、[クラスターのログ配信][29] を有効にして、init script のログを任意の送信先に送信します。ログを Unity Catalog ボリュームに送信することを推奨します。
+ {{< img src="data_jobs/databricks/compute_logging_config.png" alt="ログ配信先を構成するオプションがある [Logging] タブを表示した Databricks クラスター構成ページ。" style="width:100%;" >}}
+ ログ配信を有効にしてクラスターを再起動した後、ログの送信先を開きます。stdout および stderr のログは、次のパスにあります。
+ ```
+ //init_scripts/_/
+ ```
+
+### init script の実行が成功した後にデータが表示されない {#data-not-appearing-after-a-successful-init-script-run}
-1. **API キーの検証:** init スクリプトが手動でインストールされたもののクラスターデータが DJM 製品に表示されない場合は、[API key エンドポイントを検証する][25]を使用して、スクリプトに指定された Datadog API キーが有効であることを確認します。
-1. **エージェントの検証:** init スクリプトが Datadog Agent をインストールします。正しくインストールされていることを確認するために、SSH でクラスターに接続し、Agent ステータスコマンドを実行します。
+1. **API キーの検証:** init script を手動でインストールした場合は、[API キーの検証エンドポイント][25] を使用して、スクリプトで指定した Datadog API キーが有効であることを確認します。
+1. **Agent の検証:** init script によって Datadog Agent がインストールされます。正しくインストールされていることを確認するには、SSH でクラスターに接続し、Agent のステータスコマンドを実行します。
```shell
sudo datadog-agent status
```
## 高度な構成 {#advanced-configuration}
-### クラスターでログ収集をフィルタリングする {#filter-log-collection-on-clusters}
+### クラスターでのログ収集をフィルタリングする {#filter-log-collection-on-clusters}
-#### 個々のクラスターからすべてのログ収集を除外する {#exclude-all-log-collection-from-an-individual-cluster}
-Databricks UI のクラスターの {{< ui >}}Advanced Configuration{{< /ui >}} セクションで、または Databricks API の [Spark 環境変数][18]として、次の環境変数を構成します。
+#### 個別のクラスターからのすべてのログ収集を除外する {#exclude-all-log-collection-from-an-individual-cluster}
+Databricks UI のクラスターの {{< ui >}}Advanced Configuration{{< /ui >}} セクション、または Databricks API の [Spark 環境変数][18] として、次の環境変数を構成します。
```bash
DD_LOGS_CONFIG_PROCESSING_RULES=[{\"type\": \"exclude_at_match\",\"name\": \"drop_all_logs\",\"pattern\": \".*\"}]
```
### 権限 {#permissions}
-Databricks ワークスペースに接続するユーザーまたはサービスプリンシパルに、{{< ui >}}Workspace Admin{{< /ui >}} 権限を付与します。これにより、Datadog は init スクリプトのインストールと更新を自動的に管理でき、構成ミスのリスクが軽減されます。
+Databricks ワークスペースに接続するユーザーまたはサービスプリンシパルには、以下に説明する権限に加えて、次のワークスペースエンタイトルメントが有効になっている必要があります。
-より詳細な制御が必要な場合は、ワークスペース内のすべてのジョブ、クラスター、およびクエリを引き続きモニターできるように、次の[ワークスペースレベルのオブジェクト][19]にこれらの最小限の権限を付与します。
+- {{< ui >}}Workspace access{{< /ui >}}
+- {{< ui >}}Databricks SQL access{{< /ui >}}
-| オブジェクト | 権限 |
-|--------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| ジョブ | [CAN VIEW][20]
-| コンピュート | [CAN ATTACH TO][21]
-| Lakeflow Declarative Pipelines | [CAN VIEW][22]
-| クエリ | [CAN VIEW][23]
-| SQL ウェアハウス | [CAN MONITOR][24]
-
-さらに、Datadog が Data Observability: Jobs Monitoring または [Cloud Cost Management][26] で Databricks コストデータにアクセスするには、[システムテーブル][27]をクエリするために使用されるユーザーまたはサービスプリンシパルに次の権限が必要です。
- - `CAN USE` 権限 (SQL ウェアハウス)。
- - Unity Catalog 内の[システムテーブル][27]に対する読み取りアクセス。これは次のように付与できます。
+#### ワークスペース権限 {#workspace-permissions}
+
+ユーザーまたはサービスプリンシパルに対して、次のいずれかの方法を選択します。
+
+- **ワークスペース管理者権限** (推奨): {{< ui >}}Workspace Admin{{< /ui >}} 権限を付与します。これにより、Datadog が init script のインストールと更新を自動的に管理できるようになり、誤構成のリスクが軽減されます。
+- **詳細な権限**: より細かい制御が必要な場合は、ワークスペース内のすべてのジョブ、クラスター、クエリを監視できるように、以下の [ワークスペースレベルのオブジェクト][19] にこれらの最小限の権限を付与します。
+
+ | オブジェクト | 権限 |
+ |--------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+ | [ジョブ][20] | CAN VIEW
+ | [コンピュート][21] | CAN ATTACH TO
+ | [Lakeflow Declarative Pipelines][22] | CAN VIEW
+ | [クエリ][23] | CAN VIEW
+ | [SQL ウェアハウス][24] | CAN MONITOR
+
+#### コストデータ権限 {#cost-data-permissions}
+
+さらに、Data Observability: Jobs Monitoring または [Cloud Cost Management][26] で Datadog が Databricks のコストデータにアクセスできるようにするには、[システムテーブル][27] のクエリに使用するユーザーまたはサービスプリンシパルに、次の権限が必要です。
+ SQL ウェアハウスに対する - `CAN USE` 権限
+ - Unity Catalog 内の [システムテーブル][27] への読み取りアクセスDatabricks で {{< ui >}}SQL Editor{{< /ui >}} を開き、サービスプリンシパルのクライアント ID (表示名ではありません) を使用して、次のコマンドを実行します。
```sql
- GRANT USE CATALOG ON CATALOG system TO ;
- GRANT SELECT ON CATALOG system TO ;
- GRANT USE SCHEMA ON CATALOG system TO ;
+ GRANT USE CATALOG ON CATALOG system TO ``;
+ GRANT USE SCHEMA ON CATALOG system TO ``;
+ GRANT SELECT ON CATALOG system TO ``;
```
- 権限を付与するユーザーは、`CATALOG system` で `MANAGE` の権限を持っている必要があります。
+ これらを付与するユーザーは、`CATALOG system` に対する `MANAGE` 権限を持っている必要があります。
-### ランタイムでのタグスパン {#tag-spans-at-runtime}
+### 実行時にスパンにタグを付ける {#tag-spans-at-runtime}
{{% djm-runtime-tagging %}}
-### 1 回限りのジョブ実行からクラスターメトリクスを集約する {#aggregate-cluster-metrics-from-one-time-job-runs}
- この構成は、ジョブに関するクラスターリソース使用状況データを取得し、[1 回限りの実行 API エンドポイント][8]を介して各実行のために新しいジョブとクラスターを作成する場合に適用されます (Databricks の外部で Airflow や Azure Data Factory などのオーケストレーションツールを使用する場合によく適用されます)。
+### クラスタータグを構成する {#configure-cluster-tags}
+
+Databricks のカスタムクラスタータグは自動的に取得され、Data Observability: Jobs Monitoring および Datadog プラットフォーム全体で利用できます。唯一の例外は Azure リソースグループのタグで、これらは自動的に取得されません。
+
+タグを手動で追加するには、クラスターの Spark 環境変数で `DD_TAGS` 環境変数を構成します。これは Databricks のカスタムクラスタータグと同じ効果がありますが、手動で構成する必要があります。[Datadog タグの規則][28] に従って、カンマまたはスペースで区切った key:value ペアを使用します。
+
+```text
+DD_TAGS=env:staging,team:data_engineering
+```
+
+### 単発ジョブ実行のクラスターからメトリクスを集計する {#aggregate-cluster-metrics-from-one-time-job-runs}
+ この構成は、ジョブのクラスターリソース使用率データを取得したい場合や、[ワンタイム実行 API エンドポイント][8] を介して実行ごとに新しいジョブとクラスターを作成する場合 (Airflow や Azure Data Factory など、Databricks 外部のオーケストレーションツールを使用する場合に一般的) に適用されます。
- [1 回限りの実行 API エンドポイント][8]を介して Databricks ジョブを送信する場合、各ジョブ実行には一意のジョブ ID が付与されます。これにより、エフェメラルクラスターを使用するジョブのクラスターメトリクスをグループ化して分析することが難しくなる場合があります。同じジョブからのクラスター利用率を集約し、複数回の実行にわたるパフォーマンスを評価するには、すべての `new_cluster` の `spark_env_vars` 内に `DD_JOB_NAME` 変数を設定し、リクエストペイロードの `run_name` と同じ値にする必要があります。
+ [ワンタイム実行 API エンドポイント][8] を介して Databricks ジョブを送信する場合、各ジョブ実行には一意のジョブ ID が割り当てられます。これにより、エフェメラルクラスターを使用するジョブのクラスターのメトリクスをグループ化して分析することが難しくなる場合があります。同じジョブのクラスター使用率を集計し、複数回の実行にわたってパフォーマンスを評価するには、すべての `new_cluster` の `spark_env_vars` 内で `DD_JOB_NAME` 変数を、リクエストペイロードの `run_name` と同じ値に設定する必要があります。
- 1 回限りのジョブ実行リクエスト本文の例は次のとおりです。
+ 以下は、ワンタイムジョブ実行リクエストボディの例です。
{{< highlight json "hl_lines=2 18" >}}
{
@@ -489,16 +541,16 @@ Databricks ワークスペースに接続するユーザーまたはサービス
}
{{< /highlight >}}
-### Databricks Networking Restrictions を使用した Data Observability: Jobs Monitoring の設定 {#set-up-data-observability-jobs-monitoring-with-databricks-networking-restrictions}
-[Databricks Networking Restrictions][12] により、Datadog は Databricks API にアクセスできない場合があり、これにより、Databricks ジョブ実行のトレース、タグ、およびその他のメタデータの収集ができなくなります。
+### Databricks Networking Restrictions がある場合の Data Observability: Jobs Monitoring のセットアップ {#set-up-data-observability-jobs-monitoring-with-databricks-networking-restrictions}
+[Databricks Networking Restrictions][12] がある場合、Datadog は Databricks API にアクセスできない可能性があります。その場合、Databricks ジョブ実行のトレースやタグ、その他のメタデータを収集できません。
-[IP アクセスリスト][13]で Databricks API アクセスを制御している場合は、許可リスト Datadog の特定の {{< region-param key="ip_ranges_url_webhooks" link="true" text="webhook IP addresses" >}} を許可すると、Datadog がワークスペース内の Databricks API に接続できるようになります。Datadog API アクセスを提供するための[個別のワークスペース][16]の IP アクセスリストの構成については、Databricks のドキュメントを参照してください。
+[IP アクセスリスト][13] で Databricks API へのアクセスを制御している場合、Datadog 固有の {{< region-param key="ip_ranges_url_webhooks" link="true" text="webhook IP addresses" >}} を許可リストに追加することで、Datadog がワークスペース内の Databricks API に接続できるようになります。Datadog に API へのアクセスを許可するため、[個々のワークスペース][16] の IP アクセスリストの構成については、Databricks のドキュメントを参照してください。
-[Databricks プライベートリンク][14]接続を使用するワークスペースをモニターするには、[プライベートリンク接続 (プレビュー)][15]を参照してください。
+[Databricks Private Link][14] 接続を使用するワークスペースを監視するには、[Private Link Connectivity (プレビュー)][15] を参照してください。
[15]: /ja/data_observability/jobs_monitoring/databricks/private_link
-## 参考資料 {#further-reading}
+## 詳細情報 {#further-reading}
{{< partial name="whats-next/whats-next.html" >}}
@@ -521,4 +573,6 @@ Databricks ワークスペースに接続するユーザーまたはサービス
[24]: https://docs.databricks.com/aws/en/security/auth/access-control#sql-warehouse-acls
[25]: https://docs.datadoghq.com/ja/api/latest/authentication/?code-lang=curl#validate-api-key
[26]: https://docs.datadoghq.com/ja/cloud_cost_management
-[27]: https://docs.databricks.com/aws/en/admin/system-tables/
\ No newline at end of file
+[27]: https://docs.databricks.com/aws/en/admin/system-tables/
+[28]: /ja/getting_started/tagging/
+[29]: https://docs.databricks.com/aws/en/compute/configure#compute-log-delivery
\ No newline at end of file
diff --git a/hugo/content/ja/observability_pipelines/monitoring_and_troubleshooting/_index.md b/hugo/content/ja/observability_pipelines/monitoring_and_troubleshooting/_index.md
new file mode 100644
index 00000000000..80696b71276
--- /dev/null
+++ b/hugo/content/ja/observability_pipelines/monitoring_and_troubleshooting/_index.md
@@ -0,0 +1,16 @@
+---
+description: Observability PipelinesのWorker CLIコマンド、パイプライン監視、使用状況メトリクス、およびトラブルシューティングリソースへのリンクをご覧ください。
+disable_toc: false
+title: 監視とトラブルシューティング
+---
+パイプラインの設定とWorkerの拡張を行った後：
+
+- Observability Pipelines Workerの問題をトラブルシューティングする場合は、[Worker CLI Commands][1]を参照し、Workerに送信された生データの確認方法をご覧ください。
+- ヘルスグラフや標準のモニターを使用して、パイプラインとコンポーネントのステータスを追跡できます。詳細については、[Monitoring Pipelines][2]を参照してください。
+- 独自のモニター、ダッシュボード、ノートブックを作成して、パイプラインを監視することもできます。メトリクスのリストについては、[Pipeline Usage Metrics][3]を参照してください。
+- Observability Pipelinesで問題が発生した場合は、[Troubleshooting][4]を参照してください。
+
+[1]: /ja/observability_pipelines/monitoring_and_troubleshooting/worker_cli_commands/
+[2]: /ja/observability_pipelines/monitoring_and_troubleshooting/monitoring_pipelines/
+[3]: /ja/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/
+[4]: /ja/observability_pipelines/monitoring_and_troubleshooting/troubleshooting/
\ No newline at end of file
diff --git a/hugo/content/ja/observability_pipelines/packs/dns_stream.md b/hugo/content/ja/observability_pipelines/packs/dns_stream.md
new file mode 100644
index 00000000000..37c0bda4483
--- /dev/null
+++ b/hugo/content/ja/observability_pipelines/packs/dns_stream.md
@@ -0,0 +1,15 @@
+---
+description: DNS Streamパックの詳細について詳しくご確認いただけます。
+title: DNS Stream
+---
+## 概要 {#overview}
+
+{{< img src="observability_pipelines/packs/dns_stream.png" alt="DNS Streamパック" style="width:25%;" >}}
+
+このベンダーニュートラルなDNSクエリ/レスポンスストリームには、トンネリングおよびDGAビーコニングのインジケーターが含まれています。
+
+このパックの機能：
+
+- クエリとレスポンスを解析します
+- トンネリングのインジケーターにフラグを立てます
+- クリーンなクエリをサンプリングします
\ No newline at end of file
diff --git a/hugo/content/ja/observability_pipelines/packs/palo_alto_cortex.md b/hugo/content/ja/observability_pipelines/packs/palo_alto_cortex.md
new file mode 100644
index 00000000000..09025b17ce7
--- /dev/null
+++ b/hugo/content/ja/observability_pipelines/packs/palo_alto_cortex.md
@@ -0,0 +1,15 @@
+---
+description: Palo Alto Cortexパックの詳細をご覧ください。
+title: Palo Alto Cortex
+---
+## 概要 {#overview}
+
+{{< img src="observability_pipelines/packs/palo_alto_cortex.png" alt="Palo Alto Cortexパック" style="width:25%;" >}}
+
+Cortex XDRアラートには、重大度、MITRE ATT&CKマッピング、およびソース/送信先コンテキストが含まれます。
+
+このパックの機能：
+
+- アラートの重大度を抽出します
+- MITRE ATT&CKタグをマッピングします
+- 高/重大なアラートを保持します
\ No newline at end of file
diff --git a/hugo/content/ko/api/latest/agent-observability/create-an-agent-observability-annotation-queue/index.md b/hugo/content/ko/api/latest/agent-observability/create-an-agent-observability-annotation-queue/index.md
new file mode 100644
index 00000000000..22f835ff2fc
--- /dev/null
+++ b/hugo/content/ko/api/latest/agent-observability/create-an-agent-observability-annotation-queue/index.md
@@ -0,0 +1,3 @@
+---
+title: Agent Observability 주석 대기열을 생성하십시오.
+---
diff --git a/hugo/content/ko/api/latest/agent-observability/update-an-agent-observability-experiment/index.md b/hugo/content/ko/api/latest/agent-observability/update-an-agent-observability-experiment/index.md
new file mode 100644
index 00000000000..1102f198a6c
--- /dev/null
+++ b/hugo/content/ko/api/latest/agent-observability/update-an-agent-observability-experiment/index.md
@@ -0,0 +1,3 @@
+---
+title: Agent Observability 실험을 업데이트합니다.
+---
diff --git a/hugo/content/ko/api/latest/elastic-cloud-integration-accounts/delete-an-elastic-cloud-integration-account/index.md b/hugo/content/ko/api/latest/elastic-cloud-integration-accounts/delete-an-elastic-cloud-integration-account/index.md
new file mode 100644
index 00000000000..b0d9dedfbd4
--- /dev/null
+++ b/hugo/content/ko/api/latest/elastic-cloud-integration-accounts/delete-an-elastic-cloud-integration-account/index.md
@@ -0,0 +1,3 @@
+---
+title: Elastic Cloud 통합 계정을 삭제하십시오.
+---
diff --git a/hugo/content/ko/api/latest/elastic-cloud-integration-accounts/get-an-elastic-cloud-integration-account/index.md b/hugo/content/ko/api/latest/elastic-cloud-integration-accounts/get-an-elastic-cloud-integration-account/index.md
new file mode 100644
index 00000000000..0f92eec5263
--- /dev/null
+++ b/hugo/content/ko/api/latest/elastic-cloud-integration-accounts/get-an-elastic-cloud-integration-account/index.md
@@ -0,0 +1,3 @@
+---
+title: Elastic Cloud 통합 계정을 발급받으십시오
+---
diff --git a/hugo/content/ko/api/latest/llm-observability/delete-agent-observability-datasets/index.md b/hugo/content/ko/api/latest/llm-observability/delete-agent-observability-datasets/index.md
new file mode 100644
index 00000000000..e250cb814db
--- /dev/null
+++ b/hugo/content/ko/api/latest/llm-observability/delete-agent-observability-datasets/index.md
@@ -0,0 +1,3 @@
+---
+title: Agent Observability 데이터셋을 삭제하십시오
+---
diff --git a/hugo/content/ko/api/latest/llm-observability/restore-an-agent-observability-dataset-version/index.md b/hugo/content/ko/api/latest/llm-observability/restore-an-agent-observability-dataset-version/index.md
new file mode 100644
index 00000000000..772cf29bbff
--- /dev/null
+++ b/hugo/content/ko/api/latest/llm-observability/restore-an-agent-observability-dataset-version/index.md
@@ -0,0 +1,3 @@
+---
+title: Agent Observability 데이터 세트 버전 복원하기
+---
diff --git a/hugo/content/ko/api/latest/rum-retention-filters/get-a-rum-exclusion-filter/index.md b/hugo/content/ko/api/latest/rum-retention-filters/get-a-rum-exclusion-filter/index.md
new file mode 100644
index 00000000000..37c4a92b075
--- /dev/null
+++ b/hugo/content/ko/api/latest/rum-retention-filters/get-a-rum-exclusion-filter/index.md
@@ -0,0 +1,3 @@
+---
+title: RUM 제외 필터를 가져오십시오.
+---
diff --git a/hugo/content/ko/api/latest/rum-retention-quotas/create-or-update-a-rum-retention-quota-config/index.md b/hugo/content/ko/api/latest/rum-retention-quotas/create-or-update-a-rum-retention-quota-config/index.md
new file mode 100644
index 00000000000..2511fc0ee6f
--- /dev/null
+++ b/hugo/content/ko/api/latest/rum-retention-quotas/create-or-update-a-rum-retention-quota-config/index.md
@@ -0,0 +1,3 @@
+---
+title: RUM 보존 할당량 구성을 생성하거나 업데이트합니다.
+---
diff --git a/hugo/content/ko/api/latest/security-monitoring/delete-a-severity-modifier-rule/index.md b/hugo/content/ko/api/latest/security-monitoring/delete-a-severity-modifier-rule/index.md
new file mode 100644
index 00000000000..55e3e32607e
--- /dev/null
+++ b/hugo/content/ko/api/latest/security-monitoring/delete-a-severity-modifier-rule/index.md
@@ -0,0 +1,3 @@
+---
+title: 심각도 modifier 규칙을 삭제하십시오
+---
diff --git a/hugo/content/ko/api/latest/twilio-integration-accounts/_index.md b/hugo/content/ko/api/latest/twilio-integration-accounts/_index.md
new file mode 100644
index 00000000000..5708cd23ba5
--- /dev/null
+++ b/hugo/content/ko/api/latest/twilio-integration-accounts/_index.md
@@ -0,0 +1,3 @@
+---
+title: Twilio 통합 계정
+---
diff --git a/hugo/content/ko/api/latest/twilio-integration-accounts/list-twilio-integration-accounts/index.md b/hugo/content/ko/api/latest/twilio-integration-accounts/list-twilio-integration-accounts/index.md
new file mode 100644
index 00000000000..c2618126444
--- /dev/null
+++ b/hugo/content/ko/api/latest/twilio-integration-accounts/list-twilio-integration-accounts/index.md
@@ -0,0 +1,3 @@
+---
+title: Twilio 통합 계정을 나열하십시오
+---
diff --git a/hugo/content/ko/containers/cluster_agent/_index.md b/hugo/content/ko/containers/cluster_agent/_index.md
index ee2197ca61a..20c9397501f 100644
--- a/hugo/content/ko/containers/cluster_agent/_index.md
+++ b/hugo/content/ko/containers/cluster_agent/_index.md
@@ -4,61 +4,64 @@ aliases:
- /ko/agent/cluster_agent/
- /ko/containers/cluster_agent/event_collection
- /ko/containers/cluster_agent/metadata_provider
-description: Datadog Cluster Agent로 클러스터 수준의 모니터링 데이터를 중앙화된 방식으로 수집
+description: Datadog Cluster Agent를 통한 클러스터 수준 모니터링 데이터 수집의 중앙집중식 접근 방식
further_reading:
- link: https://www.datadoghq.com/blog/datadog-cluster-agent/
tag: 블로그
- text: Datadog 클러스터 에이전트 소개
+ text: Datadog Cluster Agent 소개
- link: https://www.datadoghq.com/blog/autoscale-kubernetes-datadog/
tag: 블로그
text: Datadog 메트릭으로 Kubernetes 워크로드 자동 확장
- link: https://www.datadoghq.com/blog/datadog-csi-driver/
tag: 블로그
- text: Datadog의 CSI 드라이버로 고성능 옵저버빌리티를 확보해 Kubernetes 환경 보안 강화
-title: Kubernetes용 클러스터 에이전트
+ text: Datadog의 CSI 드라이버로 보안 Kubernetes 환경에 고성능 관측 가능성 실현
+- link: https://www.datadoghq.com/architecture/efficient-kubernetes-monitoring-with-the-datadog-cluster-agent/
+ tag: 아키텍처 센터
+ text: Datadog Cluster Agent를 이용한 효율적인 Kubernetes 모니터링
+- link: https://www.datadoghq.com/architecture/real-world-applications-of-the-datadog-cluster-agent-part-one/
+ tag: 아키텍처 센터
+ text: Datadog Cluster Agent의 실제 활용 사례 (1부)
+title: Kubernetes용 Cluster Agent
---
+## 개요 {#overview}
-## 개요
+Datadog Cluster Agent는 클러스터 수준 모니터링 데이터를 보다 간소화되고 중앙집중식으로 수집할 수 있도록 지원합니다. API 서버와 노드 기반 Agent 사이에서 프록시 역할을 수행함으로써, Cluster Agent는 서버 부하를 완화하는 데 도움을 줍니다. 또한 클러스터 레벨 메타데이터를 노드 기반 Agent에 전달하여, 로컬에서 수집된 메트릭의 메타데이터 품질을 향상시킬 수 있도록 합니다.
-Datadog 클러스터 에이전트는 클러스터 레벨 모니터링 데이터를 수집하기 위해 간소화된 중앙 집중식 접근 방식을 제공합니다. 클러스터 에이전트는 API 서버와 노드 기반 에이전트 간의 프록시 역할을 하여, 서버 로드를 완화하는 데 도움이 됩니다. 또한 클러스터 레벨 메타데이터를 노드 기반 에이전트에 전달하여 로컬에서 수집된 메트릭의 메타데이터의 품질을 향상합니다.
+Datadog Cluster Agent를 사용하면 다음을 수행할 수 있습니다.
-Datadog Cluster Agent를 사용해 다음을 할 수 있습니다.
+* Agent가 인프라에 미치는 영향을 완화합니다.
+* 노드 기반 Agent를 각각의 노드로 격리하여 kubelet에서 메트릭 및 메타데이터만 읽도록 RBAC 규칙을 줄입니다.
+* 로컬에서 수집된 메트릭의 메타데이터 품질을 향상시키기 위해, API 서버에서만 찾을 수 있는 클러스터 레벨 메타데이터를 노드 기반 Agent에 제공합니다.
+* 서비스, SPOF 및 이벤트 모니터링과 같은 클러스터 레벨 데이터 수집을 활성화합니다.
+* 사용자 지정 Kubernetes 메트릭 및 외부 메트릭과 함께 Horizontal Pod Autoscaling(HPA)를 사용합니다. 자세한 내용은 [사용자 지정 및 외부 메트릭 기반 Autoscaling 가이드][1]를 참조하세요.
-* 에이전트가 인프라에 미치는 영향을 완화합니다.
-* 노드 기반 에이전트를 각각의 노드로 격리하여 kubelet에서 메트릭 및 메타데이터만 읽도록 RBAC 규칙을 줄입니다.
-* 로컬에서 수집된 메트릭의 메타데이터 품질을 향상시키기 위해, API 서버에서만 찾을 수 있는 클러스터 레벨 메타데이터를 노드 에이전트에 제공합니다.
-* 서비스 또는 SPOF 모니터링 및 이벤트와 같은 클러스터 레벨 데이터 수집을 활성화합니다.
-* HPA(Horizontal Pod Autoscaling)를 커스텀 Kubernetes 메트릭 및 외부 메트릭과 함께 사용하세요. 자세한 내용은 [커스텀 및 외부 메트릭으로 오토스케일링 가이드][1]를 참고하세요.
+Helm 차트 v2.7.0 또는 Datadog Operator v1.0.0+를 사용하여 Datadog Agent를 설치한 경우, **Datadog Cluster Agent가 기본적으로 활성화됩니다**.
-Helm 차트 v2.7.0 또는 Datadog Operator v1.0.0+를 사용해 Datadog Agent를 설치한 경우, **Datadog Cluster Agent가 기본적으로 활성화**되어 있습니다.
+Datadog은 Datadog Container Registry, Google Artifact Registry(GAR), Amazon ECR, Azure ACR, Docker Hub에 컨테이너 이미지를 게시합니다.
-Datadog는 컨테이너 이미지를 Google Artifact Registry, Amazon ECR, Azure ACR, Docker Hub에 게시합니다.
+{{% container-images-table %}}
-| Google Artifact Registry | Amazon ECR | Azure ACR | Docker Hub |
-| ------------------------ | ---------------------- | -------------------- | ----------------- |
-| gcr.io/datadoghq | public.ecr.aws/datadog | datadoghq.azurecr.io | docker.io/datadog |
+기본적으로 Datadog Agent Helm 차트는 Datadog 사이트, 클러스터 유형 및 `registryMigrationMode` 값을 기준으로 Agent 이미지 레지스트리를 결정합니다. 이 값과 환경별 제외 규칙에 따라 Agent 이미지는 Datadog Container Registry(`registry.datadoghq.com`) 또는 사이트별 레지스트리에서 가져옵니다. Datadog Operator 차트는 기본적으로 Datadog Agent Helm 차트의 종속성으로 포함되어 있습니다. Datadog Operator 차트 버전 2.19.0부터 해당 종속성을 통해 Operator를 설치하면 Datadog Agent Helm 차트의 `registryMigrationMode` 설정이 Operator가 관리하는 Agent 이미지에도 적용됩니다. Operator Helm 차트 자체에는 `registryMigrationMode` 설정이 정의되어 있지 않으며, Operator 포드 이미지는 Operator 차트의 `image.repository` 값으로 별도 제어됩니다.
-기본적으로 Cluster Agent 이미지를 Google Artifact Registry(`gcr.io/datadoghq`)에서 풀링합니다. 배포 환경에서 Artifact Registry를 사용할 수 없는 경우에는 다른 레지스트리를 사용하세요.
+Docker Hub에는 이미지 풀 속도 제한이 적용됩니다. Docker Hub 고객이 아니라면 Datadog은 다른 레지스트리에서 이미지를 가져오도록 Datadog Agent 및 Cluster Agent 구성을 업데이트할 것을 권장합니다. 관련 지침은
컨테이너 레지스트리 변경을 참조하세요.
Docker Hub에는 이미지 풀링 속도 제한이 있습니다. Docker Hub 고객이 아닌 경우, Datadog에서는 Datadog Agent와 Cluster Agent 구성을 업데이트하여 GCR이나 ECR에서 풀링하도록 구성할 것을 권고합니다. 예시를 보려면
컨테이너 레지스트리 변경을 참고하세요.
메트릭 상관관계는 데이터 소스가
메트릭인
시계열 위젯에서 사용할 수 있습니다.
Watchdog Explains는 데이터 소스가
메트릭인
시계열 위젯에서 사용할 수 있습니다.
이상 탐지는 데이터 소스가
메트릭인
시계열 위젯에서 사용할 수 있습니다.
삭제된 작업 항목은 복구할 수 없습니다.
+
+프로젝트의 Settings 페이지에서 프로젝트를 삭제할 수 있습니다.
+
+프로젝트를 삭제하면 해당 프로젝트 내의 모든 작업 항목도 삭제됩니다. 작업 항목을 유지하려면 삭제하기 전에 다른 프로젝트로 작업 항목을 이동하는 것이 좋습니다.
+
+프로젝트를 삭제하면 해당 프로젝트와 연결된 모든 이벤트 상관관계 패턴이 자동으로 비활성화됩니다. 연결된 프로젝트를 삭제하면 Datadog 워크플로를 통한 작업 항목 생성이나 모니터링 `@case` 멘션과 같은 다른 자동화 기능도 중단됩니다.
+
+## 추가 자료 {#further-reading}
+
+{{< partial name="whats-next/whats-next.html" >}}
\ No newline at end of file
diff --git a/hugo/content/ko/observability_pipelines/destinations/opentelemetry/metrics.md b/hugo/content/ko/observability_pipelines/destinations/opentelemetry/metrics.md
new file mode 100644
index 00000000000..91ad01e9cb3
--- /dev/null
+++ b/hugo/content/ko/observability_pipelines/destinations/opentelemetry/metrics.md
@@ -0,0 +1,97 @@
+---
+code_lang: metrics
+disable_toc: false
+title: OpenTelemetry 메트릭 목적지
+type: multi-code-lang
+weight: 1
+---
+## 개요 {#overview}
+
+Observability Pipelines의 OpenTelemetry 대상을 사용하여 {{< tooltip text=" OpenTelemetry destination" tooltip="액세스 권한을 요청하려면 계정 관리자에게 문의하세요." >}} HTTP/S를 통해 OpenTelemetry(OTel) Collector 또는 다른 OpenTelemetry Protocol(OTLP) 호환 엔드포인트로 메트릭을 전송합니다.
+
+## 목적지 설정 {#set-up-destination}
+
+시크릿 관리: HTTP/S 클라이언트 URI에 대한 식별자와 해당하는 경우 TLS 키 암호만 입력하세요. 실제 값은 입력하지 마세요.
+
+[파이프라인을 설정][3]할 때 OpenTelemetry 목적지를 구성하세요. 파이프라인은 [UI][1]에서 설정할 수 있으며, [API][4] 또는 [Terraform][5]을 사용하여 설정할 수 있습니다. 이 섹션에서는 UI를 기준으로 단계를 설명합니다.
+
+파이프라인 UI에서 OpenTelemetry 목적지를 선택한 후 HTTP/S 클라이언트 URI에 대한 식별자를 입력하세요. 식별자가 참조하는 HTTP/S URI 엔드포인트의 예: `http://localhost:4319/v1/metrics`. 식별자 필드를 비워 두면 [기본값](#secret-defaults)이 사용됩니다.
+
+**참고**:
+- Worker는 카운터, 게이지, 히스토그램 메트릭만 OpenTelemetry로 보낼 수 있습니다. OpenTelemetry는 다른 메트릭 유형을 지원하지 않으므로 Worker는 해당 메트릭을 삭제합니다. 자세한 내용은 [지원되지 않는 메트릭 필터링](#filter-out-unsupported-metrics)을 참조하세요.
+- Worker는 메트릭의 순서를 재정렬하지 않으며 일부 OTLP 수신기는 순서가 맞지 않는 샘플을 거부하므로, Datadog에서는 OTLP 수신기가 순서가 맞지 않는 샘플을 허용하도록 설정할 것을 권장합니다. 자세한 내용은 [순서가 맞지 않는 샘플 허용](#allow-out-of-order-samples)을 참조하세요.
+- 보안 식별자를 입력한 후 환경 변수 사용을 선택하면, 환경 변수는 입력한 식별자 앞에 `DD_OP_`가 추가된 형태가 됩니다. 예를 들어 암호 식별자로 `PASSWORD_1`을 입력한 경우 해당 암호의 환경 변수는 `DD_OP_PASSWORD_1`입니다.
+
+### 선택적 설정 {#optional-settings}
+
+#### TLS 활성화 {#enable-tls}
+
+{{% observability_pipelines/tls_settings %}}
+
+#### 버퍼링 {#buffering}
+
+{{% observability_pipelines/destination_buffer %}}
+
+## 지원되지 않는 메트릭 필터링 {#filter-out-unsupported-metrics}
+
+Worker는 카운터, 게이지, 히스토그램 메트릭만 OpenTelemetry로 보낼 수 있습니다. 다음 Datadog 메트릭은 OTLP 형식으로 변환할 수 없으므로 지원되지 않습니다.
+
+- StatsD 유형 메트릭
+- 분포 메트릭
+- 스케치 메트릭
+
+이러한 메트릭 중 하나가 인코딩되어 OpenTelemetry로 전송될 배치에 포함된 경우, Worker는 지원되지 않는 메트릭을 삭제하고 오류를 기록하며 `component_error_total` 메트릭을 업데이트합니다. Datadog에서는 [필터 프로세서][9]를 사용하여 지원되지 않는 메트릭 유형을 필터링할 것을 권장합니다.
+
+## 순서가 맞지 않는 샘플 허용 {#allow-out-of-order-samples}
+
+Worker는 메트릭 순서를 재조정하지 않기 때문에 특정 시리즈에 대해 항상 올바른 순서로 메트릭을 전송하지는 않습니다. 예를 들어, 첫 번째 메트릭 배치에 타임스탬프가 `10:03`, `10:04`, `10:05`인 메트릭이 포함되어 있고 두 번째 배치에 타임스탬프가 `10:01`, `10:02`, `10:06`인 메트릭이 포함되어 있는 경우, Worker는 해당 메트릭을 전송하기 전에 순서를 재조정하지 않습니다.
+
+Prometheus OTLP 수신기와 같이 일부 OTLP 수신기는 순서가 맞지 않는 샘플을 거부하므로, 두 번째 메트릭 배치가 수신기에 의해 거부됩니다. 결과적으로 Worker는 잘못된 요청(`400`) 오류를 기록하고, OTLP 수신기가 배치 내의 일부 유효한 메트릭을 수락했더라도 거부된 전체 배치가 삭제됩니다.
+
+Datadog에서는 순서가 맞지 않는 샘플이 삭제되는 것을 방지할 수 있도록 OTLP 수신기가 순서가 맞지 않는 샘플을 허용하도록 설정할 것을 권장합니다.
+
+## 시크릿 기본값 {#secret-defaults}
+
+{{% observability_pipelines/set_secrets_intro %}}
+
+{{< tabs >}}
+{{% tab "시크릿 관리" %}}
+
+- HTTP/S 클라이언트 URI 엔드포인트 식별자
+ - Worker가 OpenTelemetry 데이터를 전송하는 HTTP/S URI 엔드포인트를 참조합니다. 식별자가 참조하는 HTTP/S URI 엔드포인트의 예: `http://localhost:4319/v1/metrics`.
+ - 기본 식별자는 `DESTINATION_OTEL_HTTP_CLIENT_URI`입니다.
+- HTTP/S 클라이언트 TLS 암호 식별자(TLS가 활성화된 경우):
+ - 기본 식별자는 `DESTINATION_OTEL_HTTP_CLIENT_KEY_PASS`입니다.
+
+{{% /tab %}}
+
+{{% tab "환경 변수" %}}
+
+{{% observability_pipelines/configure_existing_pipelines/destination_env_vars/opentelemetry_metrics %}}
+
+{{% /tab %}}
+{{< /tabs >}}
+
+## 메트릭 {#metrics}
+
+모든 목적지에서 내보내는 [구성 요소 메트릭][6] 및 [목적지 버퍼 메트릭][7]에 대해서는 [Pipelines 사용량 메트릭][8] 문서를 참조하세요. OpenTelemetry 목적지 메트릭을 필터링하거나 그룹화하려면 태그 `component_type:opentelemetry`를 사용하세요.
+
+## 목적지가 작동하는 방식 {#how-the-destination-works}
+
+### 이벤트 배치 {#event-batching}
+
+이벤트 배치는 다음 조건 중 하나가 발생하면 플러시됩니다. 자세한 내용은 [이벤트 배치][2]를 참조하세요.
+
+| 최대 이벤트 | 최대 크기(MB) | 타임아웃(초) |
+|----------------|-------------------|---------------------|
+| N/A | 10 | 1 |
+
+[1]: https://app.datadoghq.com/observability-pipelines
+[2]: /ko/observability_pipelines/destinations/#event-batching
+[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
+[6]: /ko/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#component-metrics
+[7]: /ko/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#destination-buffer-metrics
+[8]: /ko/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/
+[9]: /ko/observability_pipelines/processors/filter/
\ No newline at end of file
diff --git a/hugo/content/ko/observability_pipelines/guide/_index.md b/hugo/content/ko/observability_pipelines/guide/_index.md
new file mode 100644
index 00000000000..179f34142df
--- /dev/null
+++ b/hugo/content/ko/observability_pipelines/guide/_index.md
@@ -0,0 +1,22 @@
+---
+description: 로그 볼륨 축소, 환경 변수, 워커 업그레이드 및 Observability Pipelines 프로세서 작업에 대한 가이드를
+ 확인하세요.
+disable_toc: false
+title: Observability Pipelines 가이드
+---
+{{< whatsnext desc="일반 가이드:" >}}
+ {{< nextlink href="observability_pipelines/guide/strategies_for_reducing_log_volume" >}}로그 볼륨 축소 전략{{< /nextlink >}}
+ {{< nextlink href="observability_pipelines/guide/environment_variables" >}}소스, 프로세서 및 목적지의 환경 변수{{< /nextlink >}}
+ {{< nextlink href="/byoc-logs/guides/send_otel_logs_observability_pipelines" >}}Observability Pipelines를 사용하여 OpenTelemetry 로그를 BYOC Logs로 전송{{< /nextlink >}}
+{{< /whatsnext >}}
+
+{{< whatsnext desc="Worker 업그레이드 가이드" >}}
+ {{< nextlink href="/observability_pipelines/guide/upgrade_worker" >}}Worker 업그레이드 가이드{{< /nextlink >}}
+ {{< nextlink href="observability_pipelines/guide/upgrade_your_filter_queries_to_the_new_search_syntax" >}}필터 쿼리를 새로운 검색 구문으로 업그레이드{{< /nextlink >}}
+{{< /whatsnext >}}
+
+{{< whatsnext desc="프로세서 가이드:" >}}
+ {{< nextlink href="observability_pipelines/guide/get_started_with_the_custom_processor" >}}사용자 지정 프로세서 시작하기{{< /nextlink >}}
+ {{< nextlink href="observability_pipelines/guide/remap_reserved_attributes" >}}예약된 특성 재매핑{{< /nextlink >}}
+
+{{< /whatsnext >}}
\ No newline at end of file
diff --git a/hugo/data/api/v1/translate_actions.ko.json b/hugo/data/api/v1/translate_actions.ko.json
new file mode 100644
index 00000000000..e3db8bc00bf
--- /dev/null
+++ b/hugo/data/api/v1/translate_actions.ko.json
@@ -0,0 +1,1212 @@
+{
+ "GetIPRanges": {
+ "description": "Datadog IP 범위에 대한 정보를 확인하세요.",
+ "summary": "IP 범위 나열하기"
+ },
+ "ListAPIKeys": {
+ "description": "계정에서 사용할 수 있는 API 키 전체 목록을 가져옵니다.\n\n**참고**: 이 엔드포인트는 정부 기관용 사이트(US1-FED 및 US2-FED)에서는 비활성화되어 있습니다. 대신 [V2 키 관리](https://docs.datadoghq.com/api/latest/key-management/) 엔드포인트를 사용하세요.",
+ "summary": "모든 API 키 가져오기"
+ },
+ "CreateAPIKey": {
+ "description": "지정된 이름으로 API 키를 생성합니다.\n\n**참고**: 이 엔드포인트는 정부 기관용 사이트(US1-FED 및 US2-FED)에서는 비활성화되어 있습니다. 대신 [V2 키 관리](https://docs.datadoghq.com/api/latest/key-management/) 엔드포인트를 사용하세요.",
+ "summary": "API 키 생성하기",
+ "request_description": "",
+ "request_schema_description": "Datadog API 키입니다."
+ },
+ "DeleteAPIKey": {
+ "description": "지정된 API 키를 삭제합니다.\n\n**참고**: 이 엔드포인트는 정부 기관용 사이트(US1-FED 및 US2-FED)에서는 비활성화되어 있습니다. 대신 [V2 키 관리](https://docs.datadoghq.com/api/latest/key-management/) 엔드포인트를 사용하세요.",
+ "summary": "API 키 삭제하기"
+ },
+ "GetAPIKey": {
+ "description": "지정된 API 키를 가져옵니다.\n\n**참고**: 이 엔드포인트는 정부 기관용 사이트(US1-FED 및 US2-FED)에서는 비활성화되어 있습니다. 대신 [V2 키 관리](https://docs.datadoghq.com/api/latest/key-management/) 엔드포인트를 사용하세요.",
+ "summary": "API 키 가져오기"
+ },
+ "UpdateAPIKey": {
+ "description": "API 키 이름을 편집합니다.\n\n**참고**: 이 엔드포인트는 정부 기관용 사이트(US1-FED 및 US2-FED)에서는 비활성화되어 있습니다. 대신 [V2 키 관리](https://docs.datadoghq.com/api/latest/key-management/) 엔드포인트를 사용하세요.",
+ "summary": "API 키 편집하기",
+ "request_description": "",
+ "request_schema_description": "Datadog API 키입니다."
+ },
+ "ListApplicationKeys": {
+ "description": "Datadog 계정에서 사용할 수 있는 애플리케이션 키 전체 목록을 가져옵니다.\n이 엔드포인트는 [일회성 읽기 모드](https://docs.datadoghq.com/account_management/api-app-keys/#one-time-read-mode)가 적용된 조직에서는 비활성화됩니다.\n\n**참고**: 이 엔드포인트는 정부 기관용 사이트(US1-FED 및 US2-FED)에서는 비활성화되어 있습니다. 대신 [V2 키 관리](https://docs.datadoghq.com/api/latest/key-management/) 엔드포인트를 사용하세요.",
+ "summary": "모든 애플리케이션 키 가져오기"
+ },
+ "CreateApplicationKey": {
+ "description": "지정된 이름으로 애플리케이션 키를 생성합니다.\n이 엔드포인트는 [일회성 읽기 모드](https://docs.datadoghq.com/account_management/api-app-keys/#one-time-read-mode)가 적용된 조직에서는 비활성화됩니다.\n\n**참고**: 이 엔드포인트는 정부 기관용 사이트(US1-FED 및 US2-FED)에서는 비활성화되어 있습니다. 대신 [V2 키 관리](https://docs.datadoghq.com/api/latest/key-management/) 엔드포인트를 사용하세요.",
+ "summary": "애플리케이션 키 생성하기",
+ "request_description": "",
+ "request_schema_description": "관련 메타데이터가 포함된 애플리케이션 키입니다."
+ },
+ "DeleteApplicationKey": {
+ "description": "지정된 애플리케이션 키를 삭제합니다.\n이 엔드포인트는 [일회성 읽기 모드](https://docs.datadoghq.com/account_management/api-app-keys/#one-time-read-mode)가 적용된 조직에서는 비활성화됩니다.\n\n**참고**: 이 엔드포인트는 정부 기관용 사이트(US1-FED 및 US2-FED)에서는 비활성화되어 있습니다. 대신 [V2 키 관리](https://docs.datadoghq.com/api/latest/key-management/) 엔드포인트를 사용하세요.",
+ "summary": "애플리케이션 키 삭제하기"
+ },
+ "GetApplicationKey": {
+ "description": "지정된 애플리케이션 키를 가져옵니다.\n이 엔드포인트는 [일회성 읽기 모드](https://docs.datadoghq.com/account_management/api-app-keys/#one-time-read-mode)가 적용된 조직에서는 비활성화됩니다.\n\n**참고**: 이 엔드포인트는 정부 기관용 사이트(US1-FED 및 US2-FED)에서는 비활성화되어 있습니다. 대신 [V2 키 관리](https://docs.datadoghq.com/api/latest/key-management/) 엔드포인트를 사용하세요.",
+ "summary": "애플리케이션 키 가져오기"
+ },
+ "UpdateApplicationKey": {
+ "description": "애플리케이션 키 이름을 편집합니다.\n이 엔드포인트는 [일회성 읽기 모드](https://docs.datadoghq.com/account_management/api-app-keys/#one-time-read-mode)가 적용된 조직에서는 비활성화됩니다.\n\n**참고**: 이 엔드포인트는 정부 기관용 사이트(US1-FED 및 US2-FED)에서는 비활성화되어 있습니다. 대신 [V2 키 관리](https://docs.datadoghq.com/api/latest/key-management/) 엔드포인트를 사용하세요.",
+ "summary": "애플리케이션 키 편집하기",
+ "request_description": "",
+ "request_schema_description": "관련 메타데이터가 포함된 애플리케이션 키입니다."
+ },
+ "SubmitServiceCheck": {
+ "description": "서비스 검사 목록을 제출합니다.\n\n**참고**:\n- 유효한 API 키가 필요합니다.\n- 서비스 검사는 최대 10분 전까지 제출할 수 있습니다.",
+ "summary": "서비스 검사 제출하기",
+ "request_description": "서비스 검사 요청 본문입니다.",
+ "request_schema_description": "서비스 검사입니다."
+ },
+ "GetDailyCustomReports": {
+ "description": "일일 커스텀 보고서를 가져옵니다.\n**참고:** 이 엔드포인트는 2022년 12월 1일에 완전히 지원 중단됩니다.\n관련 마이그레이션 가이드는 [Usage Attribution API v1에서 v2로 마이그레이션](https://docs.datadoghq.com/account_management/guide/usage-attribution-migration/)을 참조하세요.",
+ "summary": "사용 가능한 일일 커스텀 보고서 목록 가져오기"
+ },
+ "GetSpecifiedDailyCustomReports": {
+ "description": "지정된 일일 커스텀 보고서를 가져옵니다.\n**참고:** 이 엔드포인트는 2022년 12월 1일에 완전히 지원 중단됩니다.\n관련 마이그레이션 가이드는 [Usage Attribution API v1에서 v2로 마이그레이션](https://docs.datadoghq.com/account_management/guide/usage-attribution-migration/)을 참조하세요.",
+ "summary": "지정된 일일 커스텀 보고서 가져오기"
+ },
+ "DeleteDashboards": {
+ "description": "지정된 ID를 사용하여 대시보드를 삭제합니다. 실패가 발생하면 대시보드가 삭제되지 않습니다(부분 성공은 허용되지 않음).",
+ "summary": "대시보드 삭제하기",
+ "request_description": "대시보드 삭제 요청 본문입니다.",
+ "request_schema_description": "대시보드 일괄 삭제 요청 본문입니다."
+ },
+ "ListDashboards": {
+ "description": "모든 대시보드를 가져옵니다.\n\n**참고**: 이 쿼리는 사용자 지정으로 생성되거나 복제된 대시보드만 반환합니다.\n이 쿼리는 사전 설정된 대시보드를 반환하지 않습니다.",
+ "summary": "모든 대시보드 가져오기"
+ },
+ "RestoreDashboards": {
+ "description": "지정된 ID를 사용하여 대시보드를 복원합니다. 실패가 발생하면 대시보드가 복원되지 않습니다(부분 성공은 허용되지 않음).",
+ "summary": "삭제된 대시보드 복원하기",
+ "request_description": "대시보드 복원 요청 본문입니다.",
+ "request_schema_description": "대시보드 복원 요청 본문입니다."
+ },
+ "CreateDashboard": {
+ "description": "지정된 옵션을 사용하여 대시보드를 생성합니다. 위젯에서 쿼리를 정의할 때, 어떤 쿼리에 `as_count()` 또는 `as_rate()` 수정자를 추가해야 하는지 유의하세요.\n이러한 수정자에 대한 자세한 내용은 다음 [문서](https://docs.datadoghq.com/developers/metrics/type_modifiers/?tab=count#in-application-modifiers)를 참조하세요.",
+ "summary": "새 대시보드 생성하기",
+ "request_description": "대시보드 생성 요청 본문입니다.",
+ "request_schema_description": "대시보드는 주요 성능 메트릭을 시각적으로 추적, 분석 및 표시하는 Datadog의 도구로서,\n인프라의 상태를 모니터링할 수 있도록 지원합니다."
+ },
+ "ListDashboardLists": {
+ "description": "모든 기존 대시보드 목록 정의를 가져옵니다.",
+ "summary": "모든 대시보드 목록 가져오기"
+ },
+ "CreateDashboardList": {
+ "description": "빈 대시보드 목록을 생성합니다.",
+ "summary": "대시보드 목록 생성하기",
+ "request_description": "대시보드 목록 생성 요청 본문입니다.",
+ "request_schema_description": "Datadog 대시보드입니다."
+ },
+ "DeleteDashboardList": {
+ "description": "대시보드 목록을 삭제합니다.",
+ "summary": "대시보드 목록 삭제하기"
+ },
+ "GetDashboardList": {
+ "description": "기존 대시보드 목록의 정의를 가져옵니다.",
+ "summary": "대시보드 목록 가져오기"
+ },
+ "UpdateDashboardList": {
+ "description": "대시보드 목록의 이름을 업데이트합니다.",
+ "summary": "대시보드 목록 업데이트하기",
+ "request_description": "대시보드 목록 업데이트 요청 본문입니다.",
+ "request_schema_description": "Datadog 대시보드입니다."
+ },
+ "CreatePublicDashboard": {
+ "description": "지정된 비공개 대시보드를 공유하여 공개적으로 볼 수 있는 URL을 생성합니다.",
+ "summary": "공유 대시보드 생성하기",
+ "request_description": "공유 대시보드 생성 요청 본문입니다.",
+ "request_schema_description": "대시보드가 공유된 방식 또는 공유될 방식과 관련된 메타데이터 객체입니다."
+ },
+ "DeletePublicDashboard": {
+ "description": "지정된 토큰과 연결된 대시보드의 공개 URL을 취소합니다(비공개로 전환).",
+ "summary": "공유 대시보드 URL 취소하기"
+ },
+ "GetPublicDashboard": {
+ "description": "지정된 토큰과 연결된 기존 공유 대시보드의 공유 메타데이터를 가져옵니다.",
+ "summary": "공유 대시보드 가져오기"
+ },
+ "UpdatePublicDashboard": {
+ "description": "지정된 토큰과 연결된 공유 대시보드를 업데이트합니다.",
+ "summary": "공유 대시보드 업데이트하기",
+ "request_description": "대시보드 업데이트 요청 본문입니다.",
+ "request_schema_description": "공유 대시보드의 설정을 업데이트합니다."
+ },
+ "DeletePublicDashboardInvitation": {
+ "description": "특정 이메일 주소에 주어진 공유 대시보드에 액세스하기 위해 사용된 과거에 보낸 초대 이메일 및 활성 세션을 취소합니다.",
+ "summary": "공유 대시보드 초대 취소하기",
+ "request_description": "공유 대시보드 초대 삭제 요청 본문입니다.",
+ "request_schema_description": "API가 반환하는 공유 대시보드에 존재하는 초대 데이터 및 메타데이터입니다."
+ },
+ "GetPublicDashboardInvitations": {
+ "description": "지정된 공유 대시보드에 존재하는 초대를 설명합니다(페이지별로 표시됨).",
+ "summary": "공유 대시보드의 모든 초대 가져오기"
+ },
+ "SendPublicDashboardInvitation": {
+ "description": "인증된 공유 대시보드에 액세스할 수 있는 링크가 포함된 이메일을 지정된 이메일 주소로 보냅니다. 이메일 주소는 이미 인증된 공유 대시보드의 share_list에 포함되어 있어야 합니다.",
+ "summary": "공유 대시보드 초대 이메일 보내기",
+ "request_description": "공유 대시보드 초대 요청 본문입니다.",
+ "request_schema_description": "API가 반환하는 공유 대시보드에 존재하는 초대 데이터 및 메타데이터입니다."
+ },
+ "DeleteDashboard": {
+ "description": "지정된 ID를 사용하여 대시보드를 삭제합니다.",
+ "summary": "대시보드 삭제하기"
+ },
+ "GetDashboard": {
+ "description": "지정된 ID를 사용하여 대시보드를 가져옵니다.",
+ "summary": "대시보드 가져오기"
+ },
+ "UpdateDashboard": {
+ "description": "지정된 ID를 사용하여 대시보드를 업데이트합니다.",
+ "summary": "대시보드 업데이트하기",
+ "request_description": "대시보드 업데이트 요청 본문입니다.",
+ "request_schema_description": "대시보드는 주요 성능 메트릭을 시각적으로 추적, 분석 및 표시하는 Datadog의 도구로서,\n인프라의 상태를 모니터링할 수 있도록 지원합니다."
+ },
+ "SubmitDistributionPoints": {
+ "description": "분포 포인트 엔드포인트를 사용하면 Datadog 대시보드에 그래프로 표시할 수 있는 분포 데이터를 게시할 수 있습니다.",
+ "summary": "분포 포인트 제출하기",
+ "request_description": "",
+ "request_schema_description": "분포 포인트 페이로드입니다."
+ },
+ "ListDowntimes": {
+ "description": "모든 예정된 가동 중지를 가져옵니다. **참고:** 이 엔드포인트는 지원이 중단되었습니다. v2 엔드포인트를 사용하세요.",
+ "summary": "모든 가동 중지 가져오기"
+ },
+ "CreateDowntime": {
+ "description": "가동 중지를 예약하세요. **참고:** 이 엔드포인트는 지원이 중단되었습니다. v2 엔드포인트를 사용하세요.",
+ "summary": "가동 중지 예약하기",
+ "request_description": "가동 중지 예약 요청 본문입니다.",
+ "request_schema_description": "가동 중지 예약을 사용하면 전역적으로 범위를 알림에서 제외하여\n모니터링 경보를 더 효과적으로 제어할 수 있습니다.\n시작 및 종료 시간을 예약할 수 있는 가동 중지 설정은\n지정된 Datadog 태그와 관련된 모든 경보를 차단합니다."
+ },
+ "CancelDowntimesByScope": {
+ "description": "`X` 범위와 일치하는 모든 가동 중지를 삭제합니다. **참고:** 이 기능은 v1 엔드포인트를 사용하여 생성된 가동 중지와만 상호 작용합니다. 이 엔드포인트는 지원이 중단되었으며, 대체되지 않을 예정입니다. v2 엔드포인트를 사용하여 가동 중지를 찾고 취소하세요.",
+ "summary": "범위별로 가동 중지 취소하기",
+ "request_description": "가동 중지를 취소할 범위입니다.",
+ "request_schema_description": "범위에 따라 가동 중지를 취소합니다."
+ },
+ "CancelDowntime": {
+ "description": "가동 중지를 취소합니다. **참고:** 이 엔드포인트는 지원이 중단되었습니다. v2 엔드포인트를 사용하세요.",
+ "summary": "가동 중지 취소하기"
+ },
+ "GetDowntime": {
+ "description": "`downtime_id`로 가동 중지 세부 정보를 가져옵니다. **참고:** 이 엔드포인트는 지원이 중단되었습니다. v2 엔드포인트를 사용하세요.",
+ "summary": "가동 중지 가져오기"
+ },
+ "UpdateDowntime": {
+ "description": "`downtime_id`로 단일 가동 중지를 업데이트합니다. **참고:** 이 엔드포인트는 지원이 중단되었습니다. v2 엔드포인트를 사용하세요.",
+ "summary": "가동 중지 업데이트하기",
+ "request_description": "가동 중지 요청 본문을 업데이트합니다.",
+ "request_schema_description": "가동 중지 예약을 사용하면 전역적으로 범위를 알림에서 제외하여\n모니터링 경보를 더 효과적으로 제어할 수 있습니다.\n시작 및 종료 시간을 예약할 수 있는 가동 중지 설정은\n지정된 Datadog 태그와 관련된 모든 경보를 차단합니다."
+ },
+ "ListEvents": {
+ "description": "이벤트 스트림은 시간, 우선순위, 소스 및 태그별로 쿼리하고 필터링할 수 있습니다.\n\n**참고**:\n- 쿼리 중인 이벤트에 종류를 불문한 마크다운 서식이 포함되어 있는 경우,\n출력에서 `%`, `\\`, `n`과 같은 문자가 표시될 수 있습니다.\n\n- 이 엔드포인트는 최대 `1000`개의 가장 최근 결과를 반환합니다. 결과를 추가로 반환하려면\n마지막 결과의 마지막 타임스탬프를 식별하고 이를 `end` 쿼리 시간으로 설정하여\n결과를 페이지화하세요. page 파라미터를 사용하여 반환할 `1000`개 결과 세트를 지정할 수도 있습니다.",
+ "summary": "이벤트 목록 확인"
+ },
+ "CreateEvent": {
+ "description": "이 엔드포인트를 사용하면 스트림에 이벤트를 게시할 수 있습니다.\n태그를 지정하고, 우선순위를 설정한 후 다른 이벤트와 함께 집계하세요.",
+ "summary": "이벤트 게시하기",
+ "request_description": "이벤트 요청 객체",
+ "request_schema_description": "이벤트를 나타내는 객체입니다."
+ },
+ "GetEvent": {
+ "description": "이 엔드포인트를 통해 이벤트 세부 정보를 쿼리할 수 있습니다.\n\n**참고**: 쿼리 중인 이벤트에 종류를 불문하고 마크다운 서식이 포함되어 있는 경우,\n출력에서 `%`, `\\`, `n`과 같은 문자가 표시될 수 있습니다.",
+ "summary": "이벤트 가져오기"
+ },
+ "ListEmbeddableGraphs": {
+ "description": "이전에 생성된 임베드 가능한 그래프 목록을 가져옵니다.",
+ "summary": "모든 임베드 가져오기"
+ },
+ "CreateEmbeddableGraph": {
+ "description": "임베드 가능한 그래프를 새로 만듭니다.\n\n참고: 특정 조직 내에서 동일한 쿼리에 대한 임베드가 이미 존재하는 경우,\n새 임베드를 생성하는 대신 이전 임베드가 반환됩니다.\n\n템플릿 변수 사용에 관심이 있다면\n[템플릿 변수가 있는 임베드 가능한 그래프](https://docs.datadoghq.com/dashboards/faq/embeddable-graphs-with-template-variables).",
+ "summary": "임베드 생성하기",
+ "request_description": "임베드 가능한 그래프 본문",
+ "request_schema_description": "임베드 가능한 그래프를 새로 생성하기 위한 페이로드입니다."
+ },
+ "GetEmbeddableGraph": {
+ "description": "`embed_id`를 사용하여 이전에 생성된 임베드에 대한 HTML 조각을 가져옵니다.",
+ "summary": "특정 임베드 가져오기"
+ },
+ "EnableEmbeddableGraph": {
+ "description": "지정된 임베드를 활성화합니다.",
+ "summary": "임베드 활성화하기"
+ },
+ "RevokeEmbeddableGraph": {
+ "description": "지정된 임베드를 취소합니다.",
+ "summary": "임베드 취소하기"
+ },
+ "GetGraphSnapshot": {
+ "description": "그래프 스냅샷을 찍습니다. 스냅샷은 웹 페이지에서 지정된 위젯을 렌더링하고 데이터를 사용할 수 있게 되면 캡처하여 생성된 PNG 이미지입니다. 이미지는 이후 클라우드 스토리지에 업로드됩니다.\n\n**참고**: 스냅샷이 생성되면 사용할 수 있게 되기까지 약간의 지연이 발생합니다.",
+ "summary": "그래프 스냅샷 찍기"
+ },
+ "MuteHost": {
+ "description": "호스트를 음소거합니다. **참고:** 이는 호스트에 대한 [Downtime V2](https://docs.datadoghq.com/api/latest/downtimes/#schedule-a-downtime)를 생성합니다.",
+ "summary": "호스트 음소거하기",
+ "request_description": "호스트 음소거 요청 본문입니다.",
+ "request_schema_description": "호스트를 음소거하기 위한 설정 조합입니다."
+ },
+ "UnmuteHost": {
+ "description": "호스트의 음소거를 해제합니다. 이 엔드포인트는 JSON 인수를 사용하지 않습니다.",
+ "summary": "호스트 음소거 해제하기"
+ },
+ "ListHosts": {
+ "description": "이 엔드포인트를 사용하면 이름, 별칭 또는 태그별로 호스트를 검색할 수 있습니다.\n기본적으로 지난 3시간 이내에 활성화된 호스트가 포함됩니다.\n보존 기간은 7일입니다.\n결과는 페이지별로 표시되며 한 번에 최대 1000개의 결과가 표시됩니다.\n**참고:** 호스트가 Amazon EC2 인스턴스인 경우 응답에서 `id`가 `aws_id`로 대체됩니다.\n**참고**: 이 엔드포인트에서 반환된 데이터를 보안 검사로 보강하려면 새로운 [api/v2/security/scanned-assets-metadata](https://docs.datadoghq.com/api/latest/security-monitoring/#list-scanned-assets-metadata) 엔드포인트를 참조하세요.",
+ "summary": "조직의 모든 호스트 가져오기"
+ },
+ "GetHostTotals": {
+ "description": "이 엔드포인트는 Datadog 계정의 활성 및 활성화된 상태의 호스트의 총 수를 반환합니다.\n활성이란 호스트가 지난 1시간 동안 보고했음을 의미하며, 활성화된 상태란 지난 2시간 동안 보고했음을 의미합니다.",
+ "summary": "총 활성 호스트 수 가져오기"
+ },
+ "DeleteAWSAccount": {
+ "description": "**이 엔드포인트는 지원이 중단되었습니다. 대신 V2 엔드포인트를 사용하세요.** 지정된 `account_id` 및 `role_name parameters`와 일치하는 Datadog-AWS 통합을 삭제합니다.",
+ "summary": "AWS 통합 삭제하기",
+ "request_description": "AWS 요청 객체",
+ "request_schema_description": "삭제할 AWS 계정의 목록입니다."
+ },
+ "ListAWSAccounts": {
+ "description": "**이 엔드포인트는 지원이 중단되었습니다. 대신 V2 엔드포인트를 사용하세요.** Datadog 조직에서 사용할 수 있는 모든 Datadog-AWS 통합을 나열합니다.",
+ "summary": "모든 AWS 통합 나열하기"
+ },
+ "CreateAWSAccount": {
+ "description": "**이 엔드포인트는 지원이 중단되었습니다. 대신 V2 엔드포인트를 사용하세요.** Datadog-Amazon Web Services 통합을 생성합니다.\n`POST` 메서드를 사용하면 Datadog 조직의 기존 구성에 새 구성을 추가하여\n통합 구성을 업데이트합니다.\n역할 기반 인증을 위한 고유한 AWS 계정 ID입니다.",
+ "summary": "AWS 통합 생성하기",
+ "request_description": "AWS 요청 객체",
+ "request_schema_description": "이 통합과 연결된 AWS 계정을 반환합니다."
+ },
+ "UpdateAWSAccount": {
+ "description": "**이 엔드포인트는 지원이 중단되었습니다. 대신 V2 엔드포인트를 사용하세요.** Datadog-Amazon Web Services 통합을 업데이트합니다.",
+ "summary": "AWS 통합 업데이트하기",
+ "request_description": "AWS 요청 객체",
+ "request_schema_description": "이 통합과 연결된 AWS 계정을 반환합니다."
+ },
+ "ListAvailableAWSNamespaces": {
+ "description": "**이 엔드포인트는 지원이 중단되었습니다. 대신 V2 엔드포인트를 사용하세요.** 지정된 Datadog-AWS 통합에 대한 모든 네임스페이스 규칙을 나열합니다. 이 엔드포인트는 인수를 사용하지 않습니다.",
+ "summary": "네임스페이스 규칙 나열하기"
+ },
+ "DeleteAWSEventBridgeSource": {
+ "description": "**이 엔드포인트는 지원이 중단되었습니다. 대신 V2 엔드포인트를 사용하세요.** Amazon EventBridge 소스를 삭제합니다.",
+ "summary": "Amazon EventBridge 소스 삭제하기",
+ "request_description": "지정된 이름, 리전 및 연결된 AWS 계정으로 Amazon EventBridge 소스를 삭제합니다.",
+ "request_schema_description": "EventBridge 소스를 삭제하는 데 사용되는 객체입니다."
+ },
+ "ListAWSEventBridgeSources": {
+ "description": "**이 엔드포인트는 지원이 중단되었습니다. 대신 V2 엔드포인트를 사용하세요.** 모든 Amazon EventBridge 소스를 가져옵니다.",
+ "summary": "모든 Amazon EventBridge 소스 가져오기"
+ },
+ "CreateAWSEventBridgeSource": {
+ "description": "**이 엔드포인트는 지원이 중단되었습니다. 대신 V2 엔드포인트를 사용하세요.** Amazon EventBridge 소스를 생성합니다.",
+ "summary": "Amazon EventBridge 소스 생성하기",
+ "request_description": "지정된 이름과 리전을 사용하여 AWS 계정에 대한 Amazon EventBridge 소스를 생성합니다.",
+ "request_schema_description": "EventBridge 소스를 생성하는 데 사용되는 객체입니다."
+ },
+ "DeleteAWSTagFilter": {
+ "description": "태그 필터링 항목을 삭제합니다.",
+ "summary": "태그 필터링 항목 삭제하기",
+ "request_description": "지정된 AWS 계정 및 `dd-aws` 네임스페이스에 대한 태그 필터링 항목을 삭제합니다.",
+ "request_schema_description": "AWS 태그 필터 항목을 삭제하는 데 사용되는 객체입니다."
+ },
+ "ListAWSTagFilters": {
+ "description": "모든 AWS 태그 필터를 가져옵니다.",
+ "summary": "모든 AWS 태그 필터 가져오기"
+ },
+ "CreateAWSTagFilter": {
+ "description": "AWS 태그 필터를 설정합니다.",
+ "summary": "AWS 태그 필터 설정하기",
+ "request_description": "`aws_account_identifier`, `namespace` 및 필터링 문자열을 사용하여 AWS 태그 필터를 설정합니다.\n네임스페이스 옵션은 `application_elb`, `elb`, `lambda`, `network_elb`, `rds`, `sqs` 및 `custom`입니다.",
+ "request_schema_description": "AWS 태그 필터를 설정하는 데 사용되는 객체입니다."
+ },
+ "CreateNewAWSExternalID": {
+ "description": "**이 엔드포인트는 지원이 중단되었습니다. 대신 V2 엔드포인트를 사용하세요.** 지정된 AWS 계정 ID 및 역할 이름 쌍에 대한 새로운 AWS 외부 ID를 생성합니다.",
+ "summary": "새 외부 ID 생성하기",
+ "request_description": "Datadog 역할 위임 이름입니다.\nAWS 계정 역할 이름에 대한 자세한 내용은\n[Datadog AWS 통합 구성 정보](https://docs.datadoghq.com/integrations/amazon_web_services/#setup)를 참조하세요.",
+ "request_schema_description": "이 통합과 연결된 AWS 계정을 반환합니다."
+ },
+ "DeleteAWSLambdaARN": {
+ "description": "**이 엔드포인트는 지원이 중단되었습니다.** 특정 AWS 계정과 연결된 특정 Lambda ARN을 제거하여 Datadog-AWS 로그 구성을 삭제합니다.",
+ "summary": "AWS 로그 통합 삭제하기",
+ "request_description": "AWS Lambda ARN 요청 본문을 삭제합니다.",
+ "request_schema_description": "AWS 계정 ID 및 Lambda ARN입니다."
+ },
+ "ListAWSLogsIntegrations": {
+ "description": "Datadog 계정에 구성된 모든 Datadog-AWS 로그 통합을 나열합니다.",
+ "summary": "모든 AWS 로그 통합 나열하기"
+ },
+ "CreateAWSLambdaARN": {
+ "description": "**이 엔드포인트는 지원이 중단되었습니다.** 로그 수집을 활성화하기 위해 Datadog-AWS 로그 수집을 위해 생성된 Lambda의 Lambda ARN을 AWS 계정 ID에 연결합니다.",
+ "summary": "AWS 로그 Lambda ARN 추가하기",
+ "request_description": "AWS 로그 Lambda Async 요청 본문입니다.",
+ "request_schema_description": "AWS 계정 ID 및 Lambda ARN입니다."
+ },
+ "CheckAWSLogsLambdaAsync": {
+ "description": "**이 엔드포인트는 지원이 중단되었습니다.** 지정된 서비스 및 AWS 계정에 대한 로그 포워딩 트리거를 추가할 권한이 있는지 테스트하세요. 입력값은\nAWS 서비스 로그 수집 활성화와 동일합니다. 후속 요청은 항상 위 절차를 반복하므로 이\n엔드포인트는 차단하는 대신 간헐적으로 폴링될 수 있습니다.\n\n- 계정에 Lambda가 존재하는지 검사하고 있을 때 'created' 상태를 반환합니다.\n- 검사하는 동안 'waiting' 상태를 반환합니다.\n- Lambda가 존재하면 'checked and ok' 상태를 반환합니다.\n- Lambda가 존재하지 않으면 'error' 상태를 반환합니다.",
+ "summary": "AWS Lambda 함수가 존재하는지 검사하기",
+ "request_description": "AWS 로그 Lambda Async 요청 본문을 검사합니다.",
+ "request_schema_description": "AWS 계정 ID 및 Lambda ARN입니다."
+ },
+ "ListAWSLogsServices": {
+ "description": "**이 엔드포인트는 지원이 중단되었습니다. 대신 V2 엔드포인트를 사용하세요.** Datadog이 자동 로그 수집을 제공하는 현재 AWS 서비스 목록을 가져옵니다. 반환된 서비스 ID를 AWS 서비스 로그 수집 활성화 API 엔드포인트의 services 파라미터와 함께 사용합니다.",
+ "summary": "AWS 로그 지원 서비스 목록 가져오기"
+ },
+ "EnableAWSLogServices": {
+ "description": "서비스 목록에 대해 자동 로그 수집을 활성화합니다. 구성을 저장하려면 `CreateAWSLambdaARN`을 실행한 후 이 작업을 실행해야 합니다.",
+ "summary": "AWS 로그 통합 활성화하기",
+ "request_description": "AWS Log Services 요청 본문을 활성화합니다.",
+ "request_schema_description": "Datadog에서 자동 로그 수집을 제공하는 현재 AWS 서비스 목록입니다."
+ },
+ "CheckAWSLogsServicesAsync": {
+ "description": "**이 엔드포인트는 지원이 중단되었습니다.** 지정된 서비스 및 AWS 계정에 대한 로그 포워딩 트리거를 추가할\n권한이 있는지 테스트합니다. 입력값은 `EnableAWSLogServices`와 동일합니다.\n비동기식으로 완료되므로 비동기 요청이 완료될 때까지 비차단 방식으로 반복적으로\n폴링될 수 있습니다.\n\n- AWS 계정에 권한이 있는지 검사하고 있을 때 `created` 상태를\n 반환합니다.\n- 검사하는 동안 `waiting` 상태를 반환합니다.\n- Lambda가 존재하면 `checked and ok` 상태를 반환합니다.\n- Lambda가 존재하지 않으면 `error` 상태를 반환합니다.",
+ "summary": "로그 서비스에 대한 권한 검사하기",
+ "request_description": "AWS Logs Async Services 요청 본문을 검사합니다.",
+ "request_schema_description": "Datadog에서 자동 로그 수집을 제공하는 현재 AWS 서비스 목록입니다."
+ },
+ "DeleteAzureIntegration": {
+ "description": "Datadog 계정에서 지정된 Datadog-Azure 통합을 삭제합니다.",
+ "summary": "Azure 통합 삭제하기",
+ "request_description": "지정된 Datadog-Azure 통합 요청 본문을 삭제합니다.",
+ "request_schema_description": "조직에 대해 구성된 Datadog-Azure 통합입니다."
+ },
+ "ListAzureIntegration": {
+ "description": "Datadog 계정에 구성된 모든 Datadog-Azure 통합을 나열합니다.",
+ "summary": "모든 Azure 통합 나열하기"
+ },
+ "CreateAzureIntegration": {
+ "description": "Datadog-Azure 통합을 생성합니다.\n\n`POST` 메서드를 사용하면 Datadog 조직의 기존 구성에 새 구성을 추가하여\n통합 구성을 업데이트합니다.\n\n`PUT` 메서드를 사용하면 현재 구성을 Datadog 조직에 전송된 새 구성으로 대체하여\n통합 구성을 업데이트합니다.",
+ "summary": "Azure 통합 생성하기",
+ "request_description": "Datadog 계정 요청 본문에 대한 Datadog-Azure 통합을 생성합니다.",
+ "request_schema_description": "조직에 대해 구성된 Datadog-Azure 통합입니다."
+ },
+ "UpdateAzureIntegration": {
+ "description": "Datadog-Azure 통합을 업데이트합니다. 기존 `tenant_name` 및 `client_id`가 필요합니다.\n제공된 다른 모든 필드는 기존 값을 덮어씁니다. `tenant_name` 또는 `client_id`를 덮어쓰려면\n`new_tenant_name` 및 `new_client_id`를 사용하세요. 필드를 변경하지 않고 그대로 두려면 페이로드에 해당 필드를 제공하지 마세요.",
+ "summary": "Azure 통합 업데이트하기",
+ "request_description": "Datadog-Azure 통합 요청 본문을 업데이트합니다.",
+ "request_schema_description": "조직에 대해 구성된 Datadog-Azure 통합입니다."
+ },
+ "UpdateAzureHostFilters": {
+ "description": "지정된 Datadog-Azure 통합에 대해 정의된 호스트 필터 목록을 업데이트합니다.",
+ "summary": "Azure 통합 호스트 필터 업데이트하기",
+ "request_description": "Datadog-Azure 통합의 호스트 필터 요청 본문을 업데이트합니다.",
+ "request_schema_description": "조직에 대해 구성된 Datadog-Azure 통합입니다."
+ },
+ "DeleteGCPIntegration": {
+ "description": "이 엔드포인트는 지원이 중단되었습니다. 대신 V2 엔드포인트를 사용하세요. 지정된 Datadog GCP 통합을 삭제합니다.",
+ "summary": "GCP 통합 삭제하기",
+ "request_description": "지정된 Datadog GCP 통합을 삭제합니다.",
+ "request_schema_description": "Google Cloud Platform 계정입니다."
+ },
+ "ListGCPIntegration": {
+ "description": "이 엔드포인트는 지원이 중단되었습니다. 대신 V2 엔드포인트를 사용하세요. Datadog 계정에 구성된 모든 Datadog GCP 통합의 목록을 나열합니다.",
+ "summary": "모든 GCP 통합 목록 나열하기"
+ },
+ "CreateGCPIntegration": {
+ "description": "이 엔드포인트는 지원이 중단되었습니다. 대신 V2 엔드포인트를 사용하세요. Datadog GCP 통합을 생성합니다.",
+ "summary": "GCP 통합 생성하기",
+ "request_description": "Datadog GCP 통합을 생성합니다.",
+ "request_schema_description": "Google Cloud Platform 계정입니다."
+ },
+ "UpdateGCPIntegration": {
+ "description": "이 엔드포인트는 지원이 중단되었습니다. 대신 V2 엔드포인트를 사용하세요. Datadog GCP 통합의 host_filters 및/또는 auto-mute를 업데이트합니다.\n`project_id` 및 `client_email`이 필요하지만, 해당 필드는 업데이트할 수 없습니다.\n이 필드들을 업데이트해야 하는 경우, 삭제한 뒤 생성(`POST`) 엔드포인트를 사용하세요.\n지정되지 않은 필드는 원래 값을 유지합니다.",
+ "summary": "GCP 통합 업데이트하기",
+ "request_description": "Datadog-GCP 통합을 업데이트합니다.",
+ "request_schema_description": "Google Cloud Platform 계정입니다."
+ },
+ "CreatePagerDutyIntegrationService": {
+ "description": "PagerDuty 통합 내 신규 서비스 객체를 생성합니다.",
+ "summary": "신규 서비스 객체 생성하기",
+ "request_description": "신규 서비스 객체 요청 본문을 생성합니다.",
+ "request_schema_description": "Datadog과 통합할 수 있는 PagerDuty 서비스입니다."
+ },
+ "DeletePagerDutyIntegrationService": {
+ "description": "Datadog-PagerDuty 통합의 단일 서비스 객체를 삭제합니다.",
+ "summary": "단일 서비스 객체 삭제하기"
+ },
+ "GetPagerDutyIntegrationService": {
+ "description": "Datadog-PagerDuty 통합의 서비스 이름을 가져옵니다.",
+ "summary": "단일 서비스 객체 가져오기"
+ },
+ "UpdatePagerDutyIntegrationService": {
+ "description": "Datadog-PagerDuty 통합의 단일 서비스 객체를 업데이트합니다.",
+ "summary": "단일 서비스 객체 업데이트하기",
+ "request_description": "기존 서비스 객체 요청 본문을 업데이트합니다.",
+ "request_schema_description": "PagerDuty 서비스 객체 키입니다."
+ },
+ "DeleteSlackIntegration": {
+ "description": "Datadog-Slack 통합을 삭제합니다.",
+ "summary": "Slack 통합 삭제하기"
+ },
+ "GetSlackIntegration": {
+ "description": "Datadog-Slack 통합에 대한 모든 정보를 가져옵니다.",
+ "summary": "Slack 통합 관련 정보 가져오기"
+ },
+ "CreateSlackIntegration": {
+ "description": "Datadog-Slack 통합을 생성합니다. 생성한 후에는\n[Slack 통합 엔드포인트에 채널 추가](https://docs.datadoghq.com/api/?lang=bash#add-channels-to-slack-integration)를 통해 채널에 추가하세요.\n\n이 메서드는 Datadog 조직의 기존 구성에 새 구성을 **추가**하여\n통합 구성을 업데이트합니다.",
+ "summary": "Slack 통합 생성하기",
+ "request_description": "Datadog-Slack 통합 요청 본문을 생성합니다.",
+ "request_schema_description": "새로운 Datadog-Slack 통합입니다."
+ },
+ "UpdateSlackIntegration": {
+ "description": "**지원 중단됨**: 이 엔드포인트는 지원이 중단되었습니다.\n\n이 메서드는 Datadog 조직에 전송된 새 구성으로 현재 구성을 **대체**하여\n통합 구성을 **완전히 재작성**합니다.\nSlack 웹훅 URL을 포함한 모든 필드가 유효한지 확인하세요.\n유효하지 않은 URL은 Slack 알림을 중단시킬 수 있기 때문입니다.",
+ "summary": "Slack 통합에 채널 추가하기",
+ "request_description": "기존 Datadog-Slack 통합 요청 본문을 업데이트합니다.",
+ "request_schema_description": "Slack 채널의 구성입니다."
+ },
+ "GetSlackIntegrationChannels": {
+ "description": "Datadog-Slack 통합을 위해 구성된 모든 채널 목록을 가져옵니다.",
+ "summary": "Slack 통합에서 모든 채널 가져오기"
+ },
+ "CreateSlackIntegrationChannel": {
+ "description": "Datadog-Slack 통합에 채널을 추가합니다.",
+ "summary": "Slack 통합 채널 생성하기",
+ "request_description": "생성할 Slack 채널을 설명하는 페이로드입니다.",
+ "request_schema_description": "Slack 채널 구성입니다."
+ },
+ "RemoveSlackIntegrationChannel": {
+ "description": "Datadog-Slack 통합에서 채널을 제거합니다.",
+ "summary": "Slack 통합 채널 제거하기"
+ },
+ "GetSlackIntegrationChannel": {
+ "description": "Datadog-Slack 통합에 구성된 채널을 가져옵니다.",
+ "summary": "Slack 통합 채널 가져오기"
+ },
+ "UpdateSlackIntegrationChannel": {
+ "description": "Datadog-Slack 통합에 사용되는 채널을 업데이트합니다.",
+ "summary": "Slack 통합 채널 업데이트하기",
+ "request_description": "업데이트할 필드와 값을 설명하는 페이로드입니다.",
+ "request_schema_description": "Slack 채널 구성입니다."
+ },
+ "CreateWebhooksIntegrationCustomVariable": {
+ "description": "이름이 ``인 엔드포인트를 생성합니다.",
+ "summary": "사용자 지정 변수 생성하기",
+ "request_description": "사용자 지정 변수 요청 본문을 정의합니다.",
+ "request_schema_description": "웹훅 통합을 위한 사용자 지정 변수입니다."
+ },
+ "DeleteWebhooksIntegrationCustomVariable": {
+ "description": "이름이 ``인 엔드포인트를 삭제합니다.",
+ "summary": "사용자 지정 변수 삭제하기"
+ },
+ "GetWebhooksIntegrationCustomVariable": {
+ "description": "이름이 ``인 사용자 지정 변수의 내용을 표시합니다.\n\n사용자 지정 변수가 시크릿인 경우, 응답 페이로드에서 해당 값이\n반환되지 않습니다.",
+ "summary": "사용자 지정 변수 가져오기"
+ },
+ "UpdateWebhooksIntegrationCustomVariable": {
+ "description": "이름이 ``인 엔드포인트를 업데이트합니다.",
+ "summary": "사용자 지정 변수 업데이트하기",
+ "request_description": "기존 사용자 지정 변수 요청 본문을 업데이트합니다.",
+ "request_schema_description": "사용자 지정 변수 객체의 업데이트 요청입니다.\n\n*모든 속성은 선택 사항입니다.*"
+ },
+ "CreateWebhooksIntegration": {
+ "description": "이름이 ``인 엔드포인트를 생성합니다.",
+ "summary": "Webhooks 통합 생성하기",
+ "request_description": "Webhooks 통합 요청 본문을 생성합니다.",
+ "request_schema_description": "Datadog-Webhooks 통합입니다."
+ },
+ "DeleteWebhooksIntegration": {
+ "description": "이름이 ``인 엔드포인트를 삭제합니다. 이 액션은 되돌릴 수 없습니다.",
+ "summary": "웹훅 삭제하기"
+ },
+ "GetWebhooksIntegration": {
+ "description": "이름이 ``인 웹훅의 내용을 가져옵니다.",
+ "summary": "웹훅 통합 가져오기"
+ },
+ "UpdateWebhooksIntegration": {
+ "description": "이름이 ``인 엔드포인트를 업데이트합니다.",
+ "summary": "웹훅 업데이트하기",
+ "request_description": "기존 Datadog-Webhooks 통합을 업데이트합니다.",
+ "request_schema_description": "Webhooks 통합 객체의 업데이트 요청입니다.\n\n*모든 속성은 선택 사항입니다.*"
+ },
+ "ListLogs": {
+ "description": "목록 엔드포인트는 로그 검색 쿼리와 일치하는 로그를 반환합니다.\n[결과는 페이지별로 표시됩니다][1].\n\n**조직의 로그 보관을 고려 중이라면\n로그 목록 API 대신 Datadog 보관 기능을 사용해 보세요.\n[Datadog 로그 아카이브 설명서][2]를 참조하시기 바랍니다.**\n\n**참고**: 이 엔드포인트는 기본적으로 로그 고객을 대상으로 활성화되어 있습니다. 비활성화하려면 [Datadog 지원팀](https://docs.datadoghq.com/help/)에 문의하세요.\n\n[1]: /logs/guide/collect-multiple-logs-with-pagination\n[2]: https://docs.datadoghq.com/logs/archives",
+ "summary": "로그 검색하기",
+ "request_description": "로그 필터",
+ "request_schema_description": "조직에서 로그 목록을 가져오기 위한 요청과 함께 전송할 객체입니다."
+ },
+ "GetLogsIndexOrder": {
+ "description": "로그 인덱스의 현재 순서를 가져옵니다. 이 엔드포인트는 JSON 인수를 사용하지 않습니다.",
+ "summary": "인덱스 순서 가져오기"
+ },
+ "UpdateLogsIndexOrder": {
+ "description": "이 엔드포인트는 조직의 인덱스 순서를 업데이트합니다.\n요청이 성공하면 요청 본문에 전달된 인덱스 순서 객체를 반환합니다.",
+ "summary": "인덱스 순서 업데이트하기",
+ "request_description": "인덱스 이름의 새롭게 순서가 지정된 목록을 포함한 객체입니다.",
+ "request_schema_description": "로그 인덱스 이름의 순서가 지정된 목록을 포함한 객체입니다."
+ },
+ "ListLogIndexes": {
+ "description": "인덱스 객체는 로그 인덱스의 구성을 설명합니다.\n이 엔드포인트는 조직의 `LogIndex` 객체 배열을 반환합니다.",
+ "summary": "모든 인덱스 가져오기"
+ },
+ "CreateLogsIndex": {
+ "description": "새 인덱스를 생성합니다. 요청이 성공하면 요청 본문에 전달된 인덱스 객체를 반환합니다.",
+ "summary": "인덱스 생성하기",
+ "request_description": "새 인덱스를 포함한 객체입니다.",
+ "request_schema_description": "Datadog 로그 인덱스를 설명하는 객체입니다."
+ },
+ "DeleteLogsIndex": {
+ "description": "조직의 기존 인덱스를 삭제합니다. 인덱스 삭제는 영구적이며 되돌릴 수 없습니다.\n삭제된 인덱스와 이름이 동일한 인덱스는 다시 생성할 수 없습니다.",
+ "summary": "인덱스 삭제하기"
+ },
+ "GetLogsIndex": {
+ "description": "소속 조직에서 로그 인덱스 하나를 가져옵니다. 이 엔드포인트는 JSON 인수를 사용하지 않습니다.",
+ "summary": "인덱스 가져오기"
+ },
+ "UpdateLogsIndex": {
+ "description": "이름으로 식별되는 인덱스를 업데이트합니다.\n요청이 성공하면 요청 본문에 전달된 인덱스 객체를 반환합니다.\n\n`PUT` 메서드를 사용하면 현재 구성을 Datadog 조직에 전송된 새 구성으로 **대체**하여\n인덱스의 구성을 업데이트합니다.",
+ "summary": "인덱스 업데이트하기",
+ "request_description": "새로운 `LogsIndexUpdateRequest`를 포함한 객체입니다.",
+ "request_schema_description": "Datadog 로그 인덱스를 업데이트하기 위한 객체입니다."
+ },
+ "GetLogsPipelineOrder": {
+ "description": "현재 파이프라인 순서를 가져옵니다.\n이 엔드포인트는 JSON 인수를 사용하지 않습니다.",
+ "summary": "파이프라인 순서 가져오기"
+ },
+ "UpdateLogsPipelineOrder": {
+ "description": "파이프라인 순서를 업데이트합니다. 로그는 순차적으로 처리되므로 파이프라인 순서를 변경하면\n다른 파이프라인 및 해당 프로세서에서 처리되는 데이터의 구조와 내용이 변경될 수 있습니다.\n\n**참고**: `PUT` 메서드를 사용하면 현재 순서를 Datadog 조직에 전송된 새 순서로 대체하여\n파이프라인 순서를 업데이트합니다.",
+ "summary": "파이프라인 순서 업데이트하기",
+ "request_description": "새로 순서가 지정된 파이프라인 ID 목록을 포함한 객체입니다.",
+ "request_schema_description": "순서가 지정된 파이프라인 ID 목록을 포함한 객체입니다."
+ },
+ "ListLogsPipelines": {
+ "description": "조직의 모든 파이프라인을 가져옵니다.\n이 엔드포인트는 JSON 인수를 사용하지 않습니다.",
+ "summary": "모든 파이프라인 가져오기"
+ },
+ "CreateLogsPipeline": {
+ "description": "조직에서 파이프라인을 생성합니다.",
+ "summary": "파이프라인 생성하기",
+ "request_description": "새로운 파이프라인의 정의입니다.",
+ "request_schema_description": "파이프라인과 프로세서는 수신 로그에서 작동하며,\n더 쉽게 쿼리할 수 있도록 로그를 구문 분석하고 구조화된 속성으로 변환합니다.\n\n**참고**: 이 엔드포인트는 관리자 사용자만 사용할 수 있습니다.\n관리자가 생성한 애플리케이션 키를 사용해야 합니다."
+ },
+ "DeleteLogsPipeline": {
+ "description": "조직의 지정된 파이프라인을 삭제합니다.\n이 엔드포인트는 JSON 인수를 사용하지 않습니다.",
+ "summary": "파이프라인 삭제하기"
+ },
+ "GetLogsPipeline": {
+ "description": "조직의 특정 파이프라인을 불러옵니다.\n이 엔드포인트는 JSON 인수를 사용하지 않습니다.",
+ "summary": "파이프라인 가져오기"
+ },
+ "UpdateLogsPipeline": {
+ "description": "지정된 파이프라인 구성을 업데이트하여 프로세서나 해당 순서를 변경합니다.\n\n**참고**: 이 메서드를 사용하면 현재 구성을 Datadog 조직에 전송된 새 구성으로 **대체**하여\n파이프라인 구성을 업데이트합니다.",
+ "summary": "파이프라인 업데이트하기",
+ "request_description": "파이프라인의 새로운 정의입니다.",
+ "request_schema_description": "파이프라인과 프로세서는 수신 로그에서 작동하며,\n더 쉽게 쿼리할 수 있도록 로그를 구문 분석하고 구조화된 속성으로 변환합니다.\n\n**참고**: 이 엔드포인트는 관리자 사용자만 사용할 수 있습니다.\n관리자가 생성한 애플리케이션 키를 사용해야 합니다."
+ },
+ "ListActiveMetrics": {
+ "description": "지정된 시간부터 현재까지 보고 중인 활성 메트릭 목록을 가져옵니다.",
+ "summary": "활성 메트릭 목록 가져오기"
+ },
+ "GetMetricMetadata": {
+ "description": "특정 메트릭에 대한 메타데이터를 가져옵니다.",
+ "summary": "메트릭 메타데이터 가져오기"
+ },
+ "UpdateMetricMetadata": {
+ "description": "특정 메트릭의 메타데이터를 편집합니다. [지원되는 유형](https://docs.datadoghq.com/developers/metrics)에 대해 자세히 알아보세요.",
+ "summary": "메트릭 메타데이터 수정하기",
+ "request_description": "새로운 메타데이터입니다.",
+ "request_schema_description": "모든 메트릭 관련 메타데이터가 포함된 객체입니다."
+ },
+ "ListMonitors": {
+ "description": "조직의 모든 모니터 목록을 가져옵니다.",
+ "summary": "모든 모니터 가져오기"
+ },
+ "CreateMonitor": {
+ "description": "지정된 옵션을 사용하여 모니터를 생성합니다.\n\n#### 모니터 유형\n\n다음 중에서 선택한 모니터 유형입니다.\n\n- anomaly: `query alert`\n- APM: `query alert` 또는 `trace-analytics alert`\n- composite: `composite`\n- custom: `service check`\n- forecast: `query alert`\n- host: `service check`\n- integration: `query alert` 또는 `service check`\n- live process: `process alert`\n- logs: `log alert`\n- metric: `query alert`\n- network: `service check`\n- outlier: `query alert`\n- process: `service check`\n- rum: `rum alert`\n- SLO: `slo alert`\n- watchdog: `event-v2 alert`\n- event-v2: `event-v2 alert`\n- audit: `audit alert`\n- error-tracking: `error-tracking alert`\n- database-monitoring: `database-monitoring alert`\n- network-performance: `network-performance alert`\n- cloud cost: `cost alert`\n- network-path: `network-path alert`\n\n**참고**:\n- Synthetic 모니터는 Synthetics API를 통해 생성됩니다. 자세한 내용은 [Synthetics API](https://docs.datadoghq.com/api/latest/synthetics/) 설명서를 참조하세요.\n- 로그 모니터에는 범위가 지정되지 않은 App Key가 필요합니다.\n\n#### 쿼리 유형\n\n##### 메트릭 경보 쿼리\n\n예: `time_aggr(time_window):space_aggr:metric{tags} [by {key}] operator #`\n\n- `time_aggr`: avg, sum, max, min, change 또는 pct_change\n- `time_window`: `last_#m`(모니터 유형에 따라 `#`은 1에서 10080 사이), `last_#h`(모니터 유형에 따라 `#`은 1에서 168 사이), `last_1d` 또는 `last_1w`\n- `space_aggr`: avg, sum, min 또는 max\n- `tags`: 하나 이상의 태그(쉼표로 구분) 또는 *\n- `key`: key:value 태그 구문의 'key', 그룹 내 각 태그에 대해 별도의 경보를 정의함(다중 경보)\n- `operator`: <, <=, >, >=, == 또는 !=\n- `#`: 임계값을 설정하는 데 사용되는 정수 또는 십진수\n\n수식 쿼리가 있는 메트릭 모니터에서 동적 임계값을 사용하려면 `#`을 `threshold` 키워드\n(예: `... > threshold`)로 교체하고 `options.thresholds`의 `critical_query`를 통해 쿼리로 임계값을 제공하세요.\n이 기능은 미리 보기로 제공되고 있습니다.\n\n`_change_` 또는 `_pct_change_` 시간 애그리게이터를 사용하는 경우 대신 다음과 함께 `change_aggr(time_aggr(time_window),\ntimeshift):space_aggr:metric{tags} [by {key}] operator #`을 사용하세요.\n\n- `change_aggr` change, pct_change\n- `time_aggr` avg, sum, max, min [자세히 알아보기](https://docs.datadoghq.com/monitors/create/types/#define-the-conditions)\n- `time_window` last\\\\_#m(모니터 유형에 따라 1~2880), last\\\\_#h(모니터 유형에 따라 1~48) 또는 last_#d(1 또는 2)\n- `timeshift` #m_ago (5, 10, 15, 30), #h_ago (1, 2, 4), 또는 1d_ago\n\n이 항목을 사용하여 다음 쿼리로 이상치 모니터를 생성합니다.\n`avg(last_30m):outliers(avg:system.cpu.user{role:es-events-data} by {host}, 'dbscan', 7) > 0`\n\n##### 서비스 검사 쿼리\n\n예: `\"check\".over(tags).last(count).by(group).count_by_status()`\n\n- `check` 검사 이름(예: `datadog.agent.up`)\n- `tags` 하나 이상의 따옴표로 묶인 태그(쉼표로 구분), 또는 \"*\" (예: `.over(\"env:prod\", \"role:db\")`), `over`는 비워둘 수 없습니다.\n- `count`는 최대 임계값(`options`에 정의됨)보다 크거나 같아야 합니다. 이 값은 100으로 제한됩니다.\n예를 들어, 1개의 critical, 3개의 ok, 2개의 warn 상태를 지정한 경우 `count`는 최소 3이어야 합니다.\n- `group`은 검사 모니터에 대해 지정해야 합니다. 검사별 그룹화는 일부 서비스 검사에 대해 이미 명시적으로 알려져 있습니다.\n예를 들어, Postgres 통합 모니터는 `db`, `host`, `port`로 태그가 지정되고, 네트워크 모니터는 `host`, `instance`, `url`로 태그가 지정됩니다. 자세한 내용은 [서비스 검사](https://docs.datadoghq.com/api/latest/service-checks/) 설명서를 참조하세요.\n\n##### 이벤트 경보 쿼리\n\n**참고:** 이벤트 경보 쿼리는 이벤트 V2 경보 쿼리로 대체되었습니다. 자세한 내용은 [이벤트 마이그레이션 가이드](https://docs.datadoghq.com/service_management/events/guides/migrating_to_new_events_features/)를 참조하세요.\n\n##### 이벤트 V2 경보 쿼리\n\n예: `events(query).rollup(rollup_method[, measure]).last(time_window) operator #`\n\n- `query` 검색 쿼리, [로그 검색 구문](https://docs.datadoghq.com/logs/search_syntax/)을 따릅니다.\n- `rollup_method` 통계 롤업 메서드, `count`, `avg` 및 `cardinality`를 지원합니다.\n- `measure` `avg` 및 카디널리티 `rollup_method` 대상, 사용할 측정값 또는 패싯 이름을 지정합니다.\n- `time_window` #m(1에서 2880 사이), #h(1에서 48 사이)입니다.\n- `operator` `<`, `<=`, `>`, `>=`, `==` 또는 `!=`입니다.\n- `#` 임계값을 설정하는 데 사용되는 정수 또는 십진수입니다.\n\n##### 프로세스 경보 쿼리\n\n예: `processes(search).over(tags).rollup('count').last(timeframe) operator #`\n\n- `search` 프로세스를 쿼리하기 위한 자유 텍스트 검색 문자열입니다.\n일치하는 프로세스는 [Live Processes](https://docs.datadoghq.com/infrastructure/process/?tab=linuxwindows) 페이지의 결과와 일치합니다.\n- `tags` 하나 이상의 태그(쉼표로 구분)\n- `timeframe` 개수를 롤업할 타임프레임 (예: 10m, 4h) 지원되는 타임프레임: s, m, h, d\n- `operator` <, <=, >, >=, == 또는 !=\n- `#` 임계값을 설정하는 데 사용되는 정수 또는 십진수\n\n##### 로그 경보 쿼리\n\n예: `logs(query).index(index_name).rollup(rollup_method[, measure]).last(time_window) operator #`\n\n- `query` 검색 쿼리, [로그 검색 구문](https://docs.datadoghq.com/logs/search_syntax/)을 따릅니다.\n- `index_name` 다중 인덱스 조직의 경우, 요청이 수행되는 로그 인덱스입니다.\n- `rollup_method` 통계 롤업 메서드, `count`, `avg` 및 `cardinality`를 지원합니다.\n- `measure` `avg` 및 카디널리티 `rollup_method` 대상, 사용할 측정값 또는 패싯 이름을 지정합니다.\n- `time_window` #m(1에서 2880 사이), #h(1에서 48 사이)입니다.\n- `operator` `<`, `<=`, `>`, `>=`, `==` 또는 `!=`입니다.\n- `#` 임계값을 설정하는 데 사용되는 정수 또는 십진수입니다.\n\n##### 복합 조건 쿼리\n\n예: `12345 && 67890`(`12345`와 `67890`은 복합 조건이 아닌 모니터의 ID)\n\n* `name` [*필수*, *기본값* = **동적, 쿼리 기반**]: 경보의 이름입니다.\n* `message` [*필수*, *기본값* = **동적, 쿼리 기반**]: 이 모니터에 대한 알림에 포함할 메시지입니다.\n이메일 알림은 이벤트와 동일한 '@username' 표기법을 사용하여 특정 사용자에게 보낼 수 있습니다.\n* `tags` [*선택 사항*, *기본값* = **빈 목록**]: 모니터와 연결할 태그 목록입니다.\nAPI를 통해 모든 모니터 세부 정보를 가져올 때 `monitor_tags` 인수를 사용하여 이러한 태그별로 결과를 필터링하세요.\nAPI를 통해서만 사용할 수 있으며 Datadog UI에서는 표시하거나 편집할 수 없습니다.\n\n##### SLO 경보 쿼리\n\n예시: `error_budget(\"slo_id\").over(\"time_window\") operator #`\n\n- `slo_id`: 경보를 구성하려는 SLO의 영숫자 SLO ID입니다.\n- `time_window`: 경보를 보낼 SLO 대상의 시간 범위입니다. 유효한 옵션: `7d`, `30d`, `90d`.\n- `operator`: `>=` or `>`\n\n##### 감사 경보 쿼리\n\n예: `audits(query).rollup(rollup_method[, measure]).last(time_window) operator #`\n\n- `query` 검색 쿼리, [로그 검색 구문](https://docs.datadoghq.com/logs/search_syntax/)을 따릅니다.\n- `rollup_method` 통계 롤업 메서드, `count`, `avg` 및 `cardinality`를 지원합니다.\n- `measure` `avg` 및 카디널리티 `rollup_method` 대상, 사용할 측정값 또는 패싯 이름을 지정합니다.\n- `time_window` #m(1에서 2880 사이), #h(1에서 48 사이)입니다.\n- `operator` `<`, `<=`, `>`, `>=`, `==` 또는 `!=`입니다.\n- `#` 임계값을 설정하는 데 사용되는 정수 또는 십진수입니다.\n\n##### CI Pipelines 경보 쿼리\n\n예: `ci-pipelines(query).rollup(rollup_method[, measure]).last(time_window) operator #`\n\n- `query` 검색 쿼리, [로그 검색 구문](https://docs.datadoghq.com/logs/search_syntax/)을 따릅니다.\n- `rollup_method` 통계 롤업 메서드, `count`, `avg`, `cardinality`를 지원합니다.\n- `measure` `avg` 및 카디널리티 `rollup_method` 대상, 사용할 측정값 또는 패싯 이름을 지정합니다.\n- `time_window` #m(1에서 2880 사이), #h(1에서 48 사이)입니다.\n- `operator` `<`, `<=`, `>`, `>=`, `==` 또는 `!=`입니다.\n- `#` 임계값을 설정하는 데 사용되는 정수 또는 십진수입니다.\n\n##### CI Tests 경보 쿼리\n\n예: `ci-tests(query).rollup(rollup_method[, measure]).last(time_window) operator #`\n\n- `query` 검색 쿼리, [로그 검색 구문](https://docs.datadoghq.com/logs/search_syntax/)을 따릅니다.\n- `rollup_method` 통계 롤업 메서드, `count`, `avg`, `cardinality`를 지원합니다.\n- `measure` `avg` 및 카디널리티 `rollup_method` 대상, 사용할 측정값 또는 패싯 이름을 지정합니다.\n- `time_window` #m(1에서 2880 사이), #h(1에서 48 사이)입니다.\n- `operator` `<`, `<=`, `>`, `>=`, `==` 또는 `!=`입니다.\n- `#` 임계값을 설정하는 데 사용되는 정수 또는 십진수입니다.\n\n##### Error Tracking 경보 쿼리\n\n\"새로운 이슈\" 예: `error-tracking(query).source(issue_source).new().rollup(rollup_method[, measure]).by(group_by).last(time_window) operator #`\n\"영향이 큰 이슈\" 예: `error-tracking(query).source(issue_source).impact().rollup(rollup_method[, measure]).by(group_by).last(time_window) operator #`\n\n- `query` 검색 쿼리, [로그 검색 구문](https://docs.datadoghq.com/logs/search_syntax/)을 따릅니다.\n- `issue_source` 이슈 소스, `all`, `browser`, `mobile`, `backend`를 지원하며 생략 시 기본값은 `all`입니다.\n- `rollup_method` 통계 롤업 메서드, `count`, `avg`, `cardinality`를 지원하며 생략 시 기본값은 `count`입니다.\n- `measure` `avg` 및 카디널리티 `rollup_method` 대상, 사용할 측정값 또는 패싯 이름을 지정합니다.\n- `group by` 그룹화할 속성의 쉼표로 구분된 목록, 최소한 `issue.id`를 포함해야 합니다.\n- `time_window` #m(1에서 2880 사이), #h(1에서 48 사이)입니다.\n- `operator` `<`, `<=`, `>`, `>=`, `==` 또는 `!=`입니다.\n- `#` 임계값을 설정하는 데 사용되는 정수 또는 십진수입니다.\n\n**Database Monitoring 경보 쿼리**\n\n예: `database-monitoring(query).rollup(rollup_method[, measure]).last(time_window) operator #`\n\n- `query` 검색 쿼리, [로그 검색 구문](https://docs.datadoghq.com/logs/search_syntax/)을 따릅니다.\n- `rollup_method` 통계 롤업 메서드, `count`, `avg`, `cardinality`를 지원합니다.\n- `measure` `avg` 및 카디널리티 `rollup_method` 대상, 사용할 측정값 또는 패싯 이름을 지정합니다.\n- `time_window` #m(1에서 2880 사이), #h(1에서 48 사이)입니다.\n- `operator` `<`, `<=`, `>`, `>=`, `==` 또는 `!=`입니다.\n- `#` 임계값을 설정하는 데 사용되는 정수 또는 십진수입니다.\n\n**네트워크 성능 경보 쿼리**\n\n예: `network-performance(query).rollup(rollup_method[, measure]).last(time_window) operator #`\n\n- `query` 검색 쿼리, [로그 검색 구문](https://docs.datadoghq.com/logs/search_syntax/)을 따릅니다.\n- `rollup_method` 통계 롤업 메서드, `count`, `avg`, `cardinality`를 지원합니다.\n- `measure` `avg` 및 카디널리티 `rollup_method` 대상, 사용할 측정값 또는 패싯 이름을 지정합니다.\n- `time_window` #m(1에서 2880 사이), #h(1에서 48 사이)입니다.\n- `operator` `<`, `<=`, `>`, `>=`, `==` 또는 `!=`입니다.\n- `#` 임계값을 설정하는 데 사용되는 정수 또는 십진수입니다.\n\n**비용 경보 쿼리**\n\n예: `formula(query).timeframe_type(time_window).function(parameter) operator #`\n\n- `query` 검색 쿼리, [로그 검색 구문](https://docs.datadoghq.com/logs/search_syntax/)을 따릅니다.\n- `timeframe_type` 비용을 평가할 타임프레임 유형\n - `forecast`의 경우 `current`를 지원합니다.\n - `change`, `anomaly`, `threshold`의 경우 `last`를 지원합니다.\n- `time_window` - 일일 롤업을 지원합니다(예: `7d`).\n- `function` - [선택 사항, 생략 시 기본값은 `threshold` 모니터] `change`, `anomaly`, `forecast`를 지원합니다.\n- `parameter` 해당 유형의 파라미터를 지정합니다.\n - `change`의 경우\n - `relative`, `absolute`를 지원합니다.\n - [선택 사항] `#`을 지원하며, 여기서 `#`은 임계값을 설정하는 데 사용되는 정수 또는 십진수입니다.\n - `anomaly`의 경우\n - `direction=both`, `direction=above`, `direction=below`를 지원합니다.\n - [선택 사항] `threshold=#`을 지원하며, 여기서 `#`은 임계값을 설정하는 데 사용되는 정수 또는 십진수입니다.\n- `operator`\n - `threshold`의 경우 `<`, `<=`, `>`, `>=`, `==` 또는 `!=`를 지원합니다.\n - `change`의 경우 `>`, `<`를 지원합니다.\n - `anomaly`의 경우 `>=`를 지원합니다.\n - `forecast`의 경우 `>`를 지원합니다.\n- `#` 임계값을 설정하는 데 사용되는 정수 또는 십진수입니다.\n\n**Network Path 경보 쿼리**\n\n예 `network-path(query).index(index_name).rollup(rollup_method[, measure]).last(time_window) operator #`\n\n- `query` 검색 쿼리, [로그 검색 구문](https://docs.datadoghq.com/logs/search_syntax/)을 따릅니다.\n- `index_name` 모니터링할 데이터 유형으로, `netpath-path` 및 `netpath-hop`을 지원합니다.\n- `rollup_method` 통계 롤업 메서드, `count`, `avg`, `cardinality`를 지원합니다.\n- `measure` `avg` 및 카디널리티 `rollup_method` 대상, 사용할 측정값 또는 패싯 이름을 지정합니다.\n- `time_window` #m(1에서 2880 사이), #h(1에서 48 사이)입니다.\n- `operator` `<`, `<=`, `>`, `>=`, `==` 또는 `!=`입니다.\n- `#` 임계값을 설정하는 데 사용되는 정수 또는 십진수입니다.",
+ "summary": "모니터 생성하기",
+ "request_description": "모니터 요청 본문을 생성합니다.",
+ "request_schema_description": "모니터를 설명하는 객체입니다."
+ },
+ "CheckCanDeleteMonitor": {
+ "description": "지정된 모니터를 삭제할 수 있는지 검사합니다.",
+ "summary": "모니터 삭제 가능 여부 검사하기"
+ },
+ "SearchMonitorGroups": {
+ "description": "모니터 그룹 세부 정보를 검색하고 필터링합니다.",
+ "summary": "모니터 그룹 검색"
+ },
+ "SearchMonitors": {
+ "description": "모니터 세부 정보를 검색하고 필터링합니다.",
+ "summary": "모니터 검색"
+ },
+ "ValidateMonitor": {
+ "description": "요청에 제공된 모니터를 검증합니다.\n\n**참고**: 로그 모니터에는 범위가 지정되지 않은 App Key와 `logs_read_data` 권한이 필요합니다.",
+ "summary": "모니터 검증하기",
+ "request_description": "모니터 요청 객체",
+ "request_schema_description": "모니터를 설명하는 객체입니다."
+ },
+ "DeleteMonitor": {
+ "description": "지정된 모니터 삭제하기",
+ "summary": "모니터 삭제하기"
+ },
+ "GetMonitor": {
+ "description": "조직에서 지정된 모니터에 대한 세부 정보를 가져옵니다.",
+ "summary": "모니터 세부 정보 가져오기"
+ },
+ "UpdateMonitor": {
+ "description": "지정된 모니터를 편집합니다.",
+ "summary": "모니터 편집하기",
+ "request_description": "모니터 요청 본문을 편집합니다.",
+ "request_schema_description": "모니터 업데이트 요청을 설명하는 객체입니다."
+ },
+ "ListMonitorDowntimes": {
+ "description": "지정된 모니터에 대한 모든 활성 v1 가동 중지를 가져옵니다. **참고:** 이 엔드포인트는 지원이 중단되었습니다. v2 엔드포인트를 사용하세요.",
+ "summary": "모니터에 대한 활성 가동 중지 가져오기"
+ },
+ "MuteMonitor": {
+ "description": "지정된 모니터를 음소거합니다.",
+ "summary": "모니터 음소거하기"
+ },
+ "UnmuteMonitor": {
+ "description": "지정된 모니터의 음소거를 해제합니다.",
+ "summary": "모니터 음소거 해제하기"
+ },
+ "ValidateExistingMonitor": {
+ "description": "요청에 제공된 모니터를 검증합니다.\n\n**참고**: 로그 모니터에는 범위가 지정되지 않은 App Key와 `logs_read_data` 권한이 필요합니다.",
+ "summary": "기존 모니터 검증하기",
+ "request_description": "모니터 요청 객체",
+ "request_schema_description": "모니터를 설명하는 객체입니다."
+ },
+ "GetMonthlyCustomReports": {
+ "description": "월간 커스텀 보고서를 가져옵니다.\n**참고:** 이 엔드포인트는 2022년 12월 1일에 완전히 지원 중단됩니다.\n관련 마이그레이션 가이드는 [Usage Attribution API v1에서 v2로 마이그레이션](https://docs.datadoghq.com/account_management/guide/usage-attribution-migration/)을 참조하세요.",
+ "summary": "사용 가능한 월별 커스텀 보고서 목록 가져오기"
+ },
+ "GetSpecifiedMonthlyCustomReports": {
+ "description": "지정된 월별 커스텀 보고서를 가져옵니다.\n**참고:** 이 엔드포인트는 2022년 12월 1일에 완전히 지원 중단됩니다.\n관련 마이그레이션 가이드는 [Usage Attribution API v1에서 v2로 마이그레이션](https://docs.datadoghq.com/account_management/guide/usage-attribution-migration/)을 참조하세요.",
+ "summary": "지정된 월별 커스텀 보고서 가져오기"
+ },
+ "ListNotebooks": {
+ "description": "모든 노트북을 가져옵니다. 이는 노트북\n`name` 또는 작성자 `handle`에서 특정 `query`를 검색하는 데에도 사용할 수 있습니다.",
+ "summary": "모든 노트북 가져오기"
+ },
+ "CreateNotebook": {
+ "description": "지정된 옵션을 사용하여 노트북을 생성합니다.",
+ "summary": "노트북 생성하기",
+ "request_description": "생성하려는 노트북의 JSON 설명입니다.",
+ "request_schema_description": "노트북 생성 요청에 대한 설명입니다."
+ },
+ "DeleteNotebook": {
+ "description": "지정된 ID를 사용하여 노트북을 삭제합니다.",
+ "summary": "노트북 삭제하기"
+ },
+ "GetNotebook": {
+ "description": "지정된 노트북 ID를 사용하여 노트북을 가져옵니다.",
+ "summary": "노트북 가져오기"
+ },
+ "UpdateNotebook": {
+ "description": "지정된 ID를 사용하여 노트북을 업데이트합니다.",
+ "summary": "노트북 업데이트하기",
+ "request_description": "노트북 요청 본문을 업데이트합니다.",
+ "request_schema_description": "노트북 업데이트 요청에 대한 설명입니다."
+ },
+ "ListOrgs": {
+ "description": "이 엔드포인트는 최상위 조직에 대한 데이터를 반환합니다.",
+ "summary": "관리 조직 나열하기"
+ },
+ "CreateChildOrg": {
+ "description": "하위 조직을 생성합니다.\n\n이 엔드포인트는\n[다중 조직 계정](https://docs.datadoghq.com/account_management/multi_organization/)\n기능이 필요하며,\n[지원팀에 문의](https://docs.datadoghq.com/help/)하여 활성화해야 합니다.\n\n새 하위 조직이 생성되면\n`org.public_id`, `api_key.key` 및\n응답에 제공된 `application_key.hash`를 사용하여 상호작용할 수 있습니다.",
+ "summary": "하위 조직 생성하기",
+ "request_description": "생성해야 하는 조직 객체",
+ "request_schema_description": "생성할 조직을 설명하는 객체입니다."
+ },
+ "GetOrg": {
+ "description": "조직 정보를 가져옵니다.",
+ "summary": "조직 정보 가져오기"
+ },
+ "UpdateOrg": {
+ "description": "조직을 업데이트합니다.",
+ "summary": "조직 업데이트하기",
+ "request_description": "",
+ "request_schema_description": "조직을 만들고 편집하고 관리합니다."
+ },
+ "DowngradeOrg": {
+ "description": "MSP 고객만 사용할 수 있습니다. 마스터 조직의 계층 구조에서 하위 조직을 제거하고 해당 하위 조직을 30일 평가판으로 전환합니다.",
+ "summary": "스핀오프 하위 조직"
+ },
+ "UploadIdPForOrg": {
+ "description": "SAML IdP의 ID 공급자(IdP)\n메타데이터를 업데이트하는 몇 가지 옵션이 있습니다.\n\n* **다중 파트 양식 데이터**: 양식 게시를 사용하여 IdP 메타데이터 파일을 게시합니다.\n\n* **XML 본문:** 요청 본문으로 IdP 메타데이터 파일을 게시합니다.",
+ "summary": "IdP 메타데이터 업로드하기",
+ "request_description": "",
+ "request_schema_description": "IdP 구성을 설명하는 객체입니다."
+ },
+ "QueryMetrics": {
+ "description": "시계열 포인트를 쿼리합니다.",
+ "summary": "시계열 포인트 쿼리하기"
+ },
+ "ListMetrics": {
+ "description": "**참고**: 이 엔드포인트는 지원이 중단되었습니다. 대신 `/api/v2/metrics`를 사용하세요.\n\nDatadog에서 지난 24시간 동안의 메트릭을 검색합니다.",
+ "summary": "메트릭 검색하기"
+ },
+ "AddSecurityMonitoringSignalToIncident": {
+ "description": "인시던트에 보안 신호를 추가합니다. 이를 통해 신호 탐색기 내에서 인시던트별로 신호를 검색하고 인시던트 타임라인으로 신호를 조회할 수 있습니다.",
+ "summary": "인시던트에 보안 신호 추가하기",
+ "request_description": "신호 업데이트를 설명하는 특성입니다.",
+ "request_schema_description": "신호를 추가할 인시던트를 설명하는 특성입니다."
+ },
+ "EditSecurityMonitoringSignalAssignee": {
+ "description": "이 엔드포인트는 지원이 중단되었습니다. 보안 신호의 분류 담당자를 수정합니다.",
+ "summary": "보안 신호 분류 담당자 수정하기",
+ "request_description": "신호 업데이트를 설명하는 특성입니다.",
+ "request_schema_description": "보안 신호에 대한 담당자 업데이트 작업을 설명하는 특성입니다."
+ },
+ "EditSecurityMonitoringSignalState": {
+ "description": "이 엔드포인트는 지원이 중단되었습니다. 보안 신호의 분류 상태를 변경합니다.",
+ "summary": "보안 신호에 대한 분류 상태 변경하기",
+ "request_description": "신호 업데이트를 설명하는 특성입니다.",
+ "request_schema_description": "주어진 상태에 대한 상태 변경을 설명하는 특성입니다."
+ },
+ "SubmitMetrics": {
+ "description": "메트릭 엔드포인트를 사용하면 Datadog 대시보드에서 그래프로 표시할 수 있는 시계열 데이터를 게시할 수 있습니다.\n최대 페이로드 크기는 3.2메가바이트(3,200,000바이트)입니다. 압축된 페이로드는 압축 해제 시 크기가 62메가바이트(62,914,560바이트) 미만이어야 합니다.\n\nDogStatsD를 사용하지 않고 Datadog API에 직접 메트릭을 제출하는 경우 각 데이터는 다음과 같습니다.\n\n- 타임스탬프의 경우 64비트\n- 값의 경우 64비트\n- 메트릭 이름의 경우 40바이트\n- 시계열의 경우 50바이트\n- 전체 페이로드는 약 100바이트입니다. 하지만 DogStatsD API를 사용하면\n압축이 적용되어 페이로드 크기가 줄어듭니다.",
+ "summary": "메트릭 제출하기",
+ "request_description": "",
+ "request_schema_description": "메트릭의 페이로드입니다."
+ },
+ "ListServiceDependencies": {
+ "description": "APM에서 서비스 목록과 해당 종속성을 가져옵니다. 검색된 서비스는 환경 및\n기본 태그(정의된 경우)별로 필터링됩니다.",
+ "summary": "모든 APM 서비스 종속성 가져오기"
+ },
+ "ListSingleServiceDependencies": {
+ "description": "특정 서비스의 즉각적인 업스트림 및 다운스트림 서비스를 가져옵니다.\n검색된 서비스는 환경 및 기본 태그(정의된 경우)별로 필터링됩니다.",
+ "summary": "단일 APM 서비스의 종속성 가져오기"
+ },
+ "ListSLOs": {
+ "description": "조직의 서비스 수준 목표 객체 목록을 가져옵니다.",
+ "summary": "모든 SLO 가져오기"
+ },
+ "CreateSLO": {
+ "description": "서비스 수준 목표 객체를 생성합니다.",
+ "summary": "SLO 개체 생성하기",
+ "request_description": "서비스 수준 목표 요청 객체입니다.",
+ "request_schema_description": "서비스 수준 목표 객체에는 서비스 수준 지표, 하나 이상의 타임프레임에 대한\n임계값과 메타데이터(`name`, `description`, `tags` 등)가 포함됩니다."
+ },
+ "DeleteSLOTimeframeInBulk": {
+ "description": "여러 서비스 수준 목표 객체를 삭제(또는 부분 삭제)합니다.\n\n이 엔드포인트는 하나 이상의 서비스 수준 목표 객체에 대해 하나 이상의\n임계값 삭제를 용이하게 합니다. 모든 임계값이 삭제되면 서비스 수준\n목표 객체도 삭제됩니다.",
+ "summary": "SLO 타임프레임 일괄 삭제하기",
+ "request_description": "여러 서비스 수준 목표 객체 요청 본문을 삭제합니다.",
+ "request_schema_description": "타임프레임 배열에 대한 서비스 수준 목표 객체 ID의 맵으로,\n각 ID에 대해 삭제할 임계값을 나타냅니다."
+ },
+ "CheckCanDeleteSLO": {
+ "description": "SLO를 안전하게 삭제할 수 있는지 검사합니다. 예를 들어,\n대시보드에 지장을 주지 않고 SLO를 삭제할 수 있는지 확인합니다.",
+ "summary": "SLO의 안전한 삭제 여부 검사하기"
+ },
+ "ListSLOCorrection": {
+ "description": "모든 서비스 수준 목표 수정 사항을 가져옵니다.",
+ "summary": "모든 SLO 수정 사항 가져오기"
+ },
+ "CreateSLOCorrection": {
+ "description": "SLO 수정 사항을 생성합니다. `slo_id`를 사용하여 단일 SLO에 수정 사항을 적용하거나 `slo_query`를 사용하여\n쿼리와 일치하는 SLO에 수정 사항을 적용합니다. `slo_id` 또는 `slo_query` 중 하나가 반드시 필요합니다.",
+ "summary": "SLO 수정 사항 생성하기",
+ "request_description": "SLO 수정 사항 생성하기",
+ "request_schema_description": "하나 이상의 SLO에 적용할 수정 사항을 정의하는 객체입니다."
+ },
+ "DeleteSLOCorrection": {
+ "description": "지정된 SLO 수정 사항 객체를 영구적으로 삭제합니다.",
+ "summary": "SLO 수정 사항 삭제하기"
+ },
+ "GetSLOCorrection": {
+ "description": "SLO 수정 사항을 가져옵니다.",
+ "summary": "SLO에 대한 SLO 수정 사항 가져오기"
+ },
+ "UpdateSLOCorrection": {
+ "description": "지정된 SLO 수정 사항 객체를 업데이트합니다.",
+ "summary": "SLO 수정 사항 업데이트하기",
+ "request_description": "편집된 SLO 수정 사항 객체입니다.",
+ "request_schema_description": "SLO에 적용할 수정 사항을 정의하는 객체입니다."
+ },
+ "SearchSLO": {
+ "description": "조직의 서비스 수준 목표 객체 목록을 가져옵니다.",
+ "summary": "SLO 검색하기"
+ },
+ "DeleteSLO": {
+ "description": "지정된 서비스 수준 목표 객체를 영구적으로 삭제합니다.\n\nSLO가 대시보드에서 사용되는 경우, SLO가 대시보드에서 참조되므로 `DELETE /v1/slo/` 엔드포인트가\n409 충돌 오류를 반환합니다.",
+ "summary": "SLO 삭제하기"
+ },
+ "GetSLO": {
+ "description": "서비스 수준 목표 객체를 가져옵니다.",
+ "summary": "SLO 세부 정보 가져오기"
+ },
+ "UpdateSLO": {
+ "description": "지정된 서비스 수준 목표 객체를 업데이트합니다.",
+ "summary": "SLO 업데이트하기",
+ "request_description": "편집된 서비스 수준 목표 요청 객체입니다.",
+ "request_schema_description": "서비스 수준 목표 객체에는 서비스 수준 지표, 하나 이상의 타임프레임에 대한\n임계값과 메타데이터(`name`, `description`, `tags` 등)가 포함됩니다."
+ },
+ "GetSLOCorrections": {
+ "description": "SLO에 적용된 수정 사항을 가져옵니다.",
+ "summary": "SLO에 대한 수정 사항 가져오기"
+ },
+ "GetSLOHistory": {
+ "description": "SLO 유형에 관계없이 특정 SLO의 기록을 가져옵니다.\n\n상세 기록 데이터는 소스 데이터 유형에 따라 구조화됩니다.\n예를 들어, 메트릭 소스를 사용하는 이벤트 SLO에는 메트릭 데이터가 포함되며,\n모니터 SLO 유형에는 모니터 전환 기록이 포함됩니다.\n\n**참고:** 이벤트 기반 SLO와 시간 기반 SLO에 대한 응답 형식은 서로 다릅니다.\n두 가지 형식의 예가 모두 나와 있습니다.",
+ "summary": "SLO 기록 가져오기"
+ },
+ "GetSyntheticsCIBatch": {
+ "description": "배치의 업데이트된 세부 정보를 가져옵니다.",
+ "summary": "배치 세부 정보 가져오기"
+ },
+ "ListLocations": {
+ "description": "Synthetic 테스트에 사용할 수 있는 공용 및 전용 위치 목록을\n가져옵니다. 인수는 필요하지 않습니다.",
+ "summary": "모든 위치 가져오기(퍼블릭 및 프라이빗)"
+ },
+ "CreatePrivateLocation": {
+ "description": "새 Synthetic 프라이빗 위치를 생성합니다.",
+ "summary": "프라이빗 위치 생성하기",
+ "request_description": "생성할 프라이빗 위치의 세부 정보입니다.",
+ "request_schema_description": "생성할 프라이빗 위치에 대한 정보를 포함하는 객체입니다."
+ },
+ "DeletePrivateLocation": {
+ "description": "Synthetic 프라이빗 위치를 삭제합니다.",
+ "summary": "프라이빗 위치 삭제하기"
+ },
+ "GetPrivateLocation": {
+ "description": "Synthetic 프라이빗 위치를 가져옵니다.",
+ "summary": "프라이빗 위치 가져오기"
+ },
+ "UpdatePrivateLocation": {
+ "description": "Synthetic 프라이빗 위치를 편집합니다.",
+ "summary": "프라이빗 위치 편집하기",
+ "request_description": "업데이트할 프라이빗 위치의 세부 정보입니다.",
+ "request_schema_description": "생성할 프라이빗 위치에 대한 정보를 포함하는 객체입니다."
+ },
+ "GetSyntheticsDefaultLocations": {
+ "description": "기본 위치 설정을 가져옵니다.",
+ "summary": "기본 위치 가져오기"
+ },
+ "ListTests": {
+ "description": "모든 Synthetic 테스트의 목록을 가져옵니다.",
+ "summary": "모든 Synthetic 테스트의 목록 가져오기"
+ },
+ "CreateTest": {
+ "description": "이 엔드포인트는 지원이 중단되었습니다. 테스트를 생성하려면 [API 테스트 생성](https://docs.datadoghq.com/api/latest/synthetics/#create-an-api-test) 또는 [브라우저 테스트 생성](https://docs.datadoghq.com/api/latest/synthetics/#create-a-browser-test)을 사용하세요.",
+ "summary": "테스트 생성하기",
+ "request_description": "생성할 테스트의 세부 정보입니다.",
+ "request_schema_description": "Synthetic 테스트에 대한 세부 정보를 포함하는 객체입니다."
+ },
+ "CreateSyntheticsAPITest": {
+ "description": "Synthetic API 테스트를 생성합니다.",
+ "summary": "API 테스트 생성하기",
+ "request_description": "생성할 테스트의 세부 정보입니다.",
+ "request_schema_description": "Synthetic API 테스트에 대한 세부 정보를 포함하는 객체입니다."
+ },
+ "GetAPITest": {
+ "description": "Synthetic API 테스트와 연결된 상세 구성을\n가져옵니다.",
+ "summary": "API 테스트 가져오기"
+ },
+ "UpdateAPITest": {
+ "description": "Synthetic API 테스트의 구성을 편집합니다.",
+ "summary": "API 테스트 편집하기",
+ "request_description": "저장할 새 테스트 세부 정보입니다.",
+ "request_schema_description": "Synthetic API 테스트에 대한 세부 정보를 포함하는 객체입니다."
+ },
+ "CreateSyntheticsBrowserTest": {
+ "description": "Synthetic 브라우저 테스트를 생성합니다.",
+ "summary": "브라우저 테스트 생성하기",
+ "request_description": "생성할 테스트의 세부 정보입니다.",
+ "request_schema_description": "Synthetic 브라우저 테스트에 대한 세부 정보가 포함된 객체입니다."
+ },
+ "GetBrowserTest": {
+ "description": "Synthetic 브라우저 테스트와 연결된 상세 구성(단계 포함)을\n가져옵니다.",
+ "summary": "브라우저 테스트 가져오기"
+ },
+ "UpdateBrowserTest": {
+ "description": "Synthetic 브라우저 테스트의 구성을 편집합니다.",
+ "summary": "브라우저 테스트 편집하기",
+ "request_description": "저장할 새 테스트 세부 정보입니다.",
+ "request_schema_description": "Synthetic 브라우저 테스트에 대한 세부 정보가 포함된 객체입니다."
+ },
+ "GetBrowserTestLatestResults": {
+ "description": "특정 Synthetic 브라우저 테스트에 대한 최근 150개의 테스트 결과 요약을 가져옵니다.",
+ "summary": "브라우저 테스트 최신 결과 요약 가져오기"
+ },
+ "GetBrowserTestResult": {
+ "description": "특정 Synthetic 브라우저 테스트에서 특정 전체 결과를 가져옵니다.",
+ "summary": "브라우저 테스트 결과 가져오기"
+ },
+ "DeleteTests": {
+ "description": "ID별로 여러 Synthetic 테스트를 삭제합니다.",
+ "summary": "테스트 삭제하기",
+ "request_description": "삭제할 Synthetic 테스트의 공개 ID 목록입니다.",
+ "request_schema_description": "삭제하려는 Synthetic 테스트의 ID가 포함된 JSON\n목록입니다."
+ },
+ "CreateSyntheticsMobileTest": {
+ "description": "Synthetic 모바일 테스트를 생성합니다.",
+ "summary": "모바일 테스트 생성하기",
+ "request_description": "생성할 테스트의 세부 정보입니다.",
+ "request_schema_description": "Synthetic 모바일 테스트에 대한 세부 정보가 포함된 객체입니다."
+ },
+ "GetMobileTest": {
+ "description": "Synthetic 모바일 테스트와 연결된 상세 구성을\n가져옵니다.",
+ "summary": "모바일 테스트 가져오기"
+ },
+ "UpdateMobileTest": {
+ "description": "Synthetic 모바일 테스트의 구성을 편집합니다.",
+ "summary": "모바일 테스트 편집하기",
+ "request_description": "저장할 새 테스트 세부 정보입니다.",
+ "request_schema_description": "Synthetic 모바일 테스트에 대한 세부 정보가 포함된 객체입니다."
+ },
+ "SearchTests": {
+ "description": "Synthetic 테스트를 검색합니다.",
+ "summary": "Synthetic 테스트 검색하기"
+ },
+ "TriggerTests": {
+ "description": "Synthetic 테스트 세트를 트리거합니다.",
+ "summary": "Synthetic 테스트 트리거하기",
+ "request_description": "트리거할 테스트의 식별자입니다.",
+ "request_schema_description": "트리거할 Synthetic 테스트를 설명하는 객체입니다."
+ },
+ "TriggerCITests": {
+ "description": "지속적 통합을 위해 Synthetic 테스트 세트를 트리거합니다.",
+ "summary": "CI/CD 파이프라인에서 테스트 트리거하기",
+ "request_description": "트리거할 테스트의 세부 정보입니다.",
+ "request_schema_description": "트리거할 Synthetic 테스트를 설명하는 객체입니다."
+ },
+ "FetchUptimes": {
+ "description": "ID별로 여러 Synthetic 테스트의 가동 시간을 가져옵니다.",
+ "summary": "여러 테스트의 가동 시간 가져오기",
+ "request_description": "Synthetic 테스트의 공개 ID 목록 및 타임프레임입니다.",
+ "request_schema_description": "Synthetic 테스트의 ID와 타임프레임을 포함하는 객체입니다."
+ },
+ "GetTest": {
+ "description": "Synthetic 테스트와 연결된 상세 구성을 가져옵니다.",
+ "summary": "테스트 구성 가져오기"
+ },
+ "PatchTest": {
+ "description": "부분 데이터로 Synthetic 테스트의 구성을 패치합니다.",
+ "summary": "Synthetic 테스트 패치하기",
+ "request_description": "[JSON Patch](https://jsonpatch.com/) 호환 작업 목록",
+ "request_schema_description": "테스트에서 수행할 [JSON Patch](https://jsonpatch.com) 작업 배열의 래퍼"
+ },
+ "UpdateTest": {
+ "description": "이 엔드포인트는 지원이 중단되었습니다. 테스트를 편집하려면 [API 테스트 편집](https://docs.datadoghq.com/api/latest/synthetics/#edit-an-api-test) 또는 [브라우저 테스트 편집](https://docs.datadoghq.com/api/latest/synthetics/#edit-a-browser-test)을 사용하세요.",
+ "summary": "테스트 편집하기",
+ "request_description": "저장할 새 테스트 세부 정보입니다.",
+ "request_schema_description": "Synthetic 테스트에 대한 세부 정보를 포함하는 객체입니다."
+ },
+ "GetAPITestLatestResults": {
+ "description": "지정된 Synthetic API 테스트에 대한 최근 150개의 테스트 결과 요약을 가져옵니다.",
+ "summary": "API 테스트의 최신 결과 요약 가져오기"
+ },
+ "GetAPITestResult": {
+ "description": "지정된 Synthetic API 테스트에서 특정 전체 결과를 가져옵니다.",
+ "summary": "API 테스트 결과 가져오기"
+ },
+ "UpdateTestPauseStatus": {
+ "description": "상태를 변경하여 Synthetic 테스트를 일시 중지하거나 시작합니다.",
+ "summary": "테스트 시작 또는 일시 중지하기",
+ "request_description": "지정된 Synthetic 테스트에 설정할 상태입니다.",
+ "request_schema_description": "기존 Synthetic 테스트를 시작하거나 일시 중지하기 위한 객체입니다."
+ },
+ "ListGlobalVariables": {
+ "description": "모든 Synthetic 전역 변수 목록을 가져옵니다.",
+ "summary": "모든 전역 변수 가져오기"
+ },
+ "CreateGlobalVariable": {
+ "description": "Synthetic 전역 변수를 생성합니다.",
+ "summary": "전역 변수 생성하기",
+ "request_description": "생성할 전역 변수의 세부 정보입니다.",
+ "request_schema_description": "생성할 전역 변수의 세부 정보입니다."
+ },
+ "DeleteGlobalVariable": {
+ "description": "Synthetic 전역 변수를 삭제합니다.",
+ "summary": "전역 변수 삭제하기"
+ },
+ "GetGlobalVariable": {
+ "description": "전역 변수의 상세 구성을 가져옵니다.",
+ "summary": "전역 변수 가져오기"
+ },
+ "EditGlobalVariable": {
+ "description": "Synthetic 전역 변수를 편집합니다.",
+ "summary": "전역 변수 편집하기",
+ "request_description": "업데이트할 전역 변수의 세부 정보입니다.",
+ "request_schema_description": "생성할 전역 변수의 세부 정보입니다."
+ },
+ "ListHostTags": {
+ "description": "태그와 호스트의 매핑을 반환합니다. 각 태그에 대해 응답은 이 태그를 포함하는 호스트 이름 목록을 반환합니다. 태그에 연결되어 반환될 수 있는 조직의 호스트 이름은 총 1만 개로 제한됩니다.",
+ "summary": "모든 호스트 태그 가져오기"
+ },
+ "DeleteHostTags": {
+ "description": "이 엔드포인트를 사용하면 단일 호스트의 모든 태그를\n제거할 수 있습니다. 소스가 지정되어 있지 않은 경우 \"User\" 소스에서만 삭제됩니다.",
+ "summary": "호스트 태그 제거하기"
+ },
+ "GetHostTags": {
+ "description": "지정된 호스트에 적용되는 태그 목록을 반환합니다.",
+ "summary": "호스트 태그 가져오기"
+ },
+ "CreateHostTags": {
+ "description": "이 엔드포인트를 사용하면 호스트에 새 태그를 추가할 수 있으며,\n필요에 따라 이러한 태그가 발생한 소스를 지정합니다. 태그가 이미 존재하는 경우 태그 목록에 새 태그를 추가합니다. 소스가 지정되어 있지 않은 경우 기본값은 \"user\"입니다.",
+ "summary": "호스트에 태그 추가하기",
+ "request_description": "호스트 태그 업데이트 요청 본문입니다.",
+ "request_schema_description": "호스트 이름 및 해당 태그 배열"
+ },
+ "UpdateHostTags": {
+ "description": "이 엔드포인트를 사용하면 통합 소스의 모든 태그를\n요청에 제공된 태그로 업데이트/교체할 수 있습니다.",
+ "summary": "호스트 태그 업데이트하기",
+ "request_description": "호스트에 태그 추가하기",
+ "request_schema_description": "호스트 이름 및 해당 태그 배열"
+ },
+ "GetUsageAnalyzedLogs": {
+ "description": "분석된 로그(보안 모니터링)의 시간당 사용량을 가져옵니다.\n**참고:** 이 엔드포인트는 지원이 중단되었습니다. 모든 제품의 시간당 사용량 데이터는 이제 [제품군 API별 시간당 사용량 가져오기](https://docs.datadoghq.com/api/latest/usage-metering/#get-hourly-usage-by-product-family)에서 확인할 수 있습니다. 관련 마이그레이션 가이드는 [V1 시간당 사용량 API에서 V2로 마이그레이션하기](https://docs.datadoghq.com/account_management/guide/hourly-usage-migration/)를 참조하세요.",
+ "summary": "분석된 로그의 시간당 사용량 가져오기"
+ },
+ "GetUsageAuditLogs": {
+ "description": "감사 로그의 시간당 사용량을 가져옵니다.\n**참고:** 이 엔드포인트는 지원이 중단되었습니다.",
+ "summary": "감사 로그의 시간당 사용량 가져오기"
+ },
+ "GetUsageLambda": {
+ "description": "Lambda의 시간당 사용량을 가져옵니다.\n**참고:** 이 엔드포인트는 지원이 중단되었습니다. 모든 제품의 시간당 사용량 데이터는 이제 [제품군 API별 시간당 사용량 가져오기](https://docs.datadoghq.com/api/latest/usage-metering/#get-hourly-usage-by-product-family)에서 확인할 수 있습니다. 관련 마이그레이션 가이드는 [V1 시간당 사용량 API에서 V2로 마이그레이션하기](https://docs.datadoghq.com/account_management/guide/hourly-usage-migration/)를 참조하세요.",
+ "summary": "Lambda의 시간당 사용량 가져오기"
+ },
+ "GetUsageBillableSummary": {
+ "description": "계정 전체에 대한 청구 가능한 사용량을 가져옵니다.\n\n이 엔드포인트는 [상위 수준 조직](https://docs.datadoghq.com/account_management/multi_organization/)에서만 액세스할 수 있습니다.",
+ "summary": "계정 전체에 대한 청구 가능한 사용량 가져오기"
+ },
+ "GetUsageCIApp": {
+ "description": "CI Visibility(테스트, 파이프라인, 스팬)의 시간당 사용량을 가져옵니다.\n**참고:** 이 엔드포인트는 지원이 중단되었습니다. 모든 제품의 시간당 사용량 데이터는 이제 [제품군 API별 시간당 사용량 가져오기](https://docs.datadoghq.com/api/latest/usage-metering/#get-hourly-usage-by-product-family)에서 확인할 수 있습니다. 관련 마이그레이션 가이드는 [V1 시간당 사용량 API에서 V2로 마이그레이션하기](https://docs.datadoghq.com/account_management/guide/hourly-usage-migration/)를 참조하세요.",
+ "summary": "CI Visibility의 시간당 사용량 가져오기"
+ },
+ "GetUsageCloudSecurityPostureManagement": {
+ "description": "CSM Pro의 시간당 사용량 가져오기\n**참고:** 이 엔드포인트는 지원이 중단되었습니다. 모든 제품의 시간당 사용량 데이터는 이제 [제품군 API별 시간당 사용량 가져오기](https://docs.datadoghq.com/api/latest/usage-metering/#get-hourly-usage-by-product-family)에서 확인할 수 있습니다. 관련 마이그레이션 가이드는 [V1 시간당 사용량 API에서 V2로 마이그레이션하기](https://docs.datadoghq.com/account_management/guide/hourly-usage-migration/)를 참조하세요.",
+ "summary": "CSM Pro의 시간당 사용량 가져오기"
+ },
+ "GetUsageCWS": {
+ "description": "클라우드 워크로드 보안의 시간당 사용량을 가져옵니다.\n**참고:** 이 엔드포인트는 지원이 중단되었습니다. 모든 제품의 시간당 사용량 데이터는 이제 [제품군 API별 시간당 사용량 가져오기](https://docs.datadoghq.com/api/latest/usage-metering/#get-hourly-usage-by-product-family)에서 확인할 수 있습니다. 관련 마이그레이션 가이드는 [V1 시간당 사용량 API에서 V2로 마이그레이션하기](https://docs.datadoghq.com/account_management/guide/hourly-usage-migration/)를 참조하세요.",
+ "summary": "클라우드 워크로드 보안의 시간당 사용량 가져오기"
+ },
+ "GetUsageDBM": {
+ "description": "데이터베이스 모니터링의 시간당 사용량 가져오기\n**참고:** 이 엔드포인트는 지원이 중단되었습니다. 모든 제품의 시간당 사용량 데이터는 이제 [제품군 API별 시간당 사용량 가져오기](https://docs.datadoghq.com/api/latest/usage-metering/#get-hourly-usage-by-product-family)에서 확인할 수 있습니다. 관련 마이그레이션 가이드는 [V1 시간당 사용량 API에서 V2로 마이그레이션하기](https://docs.datadoghq.com/account_management/guide/hourly-usage-migration/)를 참조하세요.",
+ "summary": "데이터베이스 모니터링의 시간당 사용량 가져오기"
+ },
+ "GetUsageFargate": {
+ "description": "[Fargate](https://docs.datadoghq.com/integrations/ecs_fargate/)의 시간당 사용량을 가져옵니다.\n**참고:** 이 엔드포인트는 지원이 중단되었습니다. 모든 제품의 시간당 사용량 데이터는 이제 [제품군 API별 시간당 사용량 가져오기](https://docs.datadoghq.com/api/latest/usage-metering/#get-hourly-usage-by-product-family)에서 확인할 수 있습니다. 관련 마이그레이션 가이드는 [V1 시간당 사용량 API에서 V2로 마이그레이션하기](https://docs.datadoghq.com/account_management/guide/hourly-usage-migration/)를 참조하세요.",
+ "summary": "Fargate의 시간당 사용량 가져오기"
+ },
+ "GetUsageHosts": {
+ "description": "호스트 및 컨테이너의 시간당 사용량을 가져옵니다.\n**참고:** 이 엔드포인트는 지원이 중단되었습니다. 모든 제품의 시간당 사용량 데이터는 이제 [제품군 API별 시간당 사용량 가져오기](https://docs.datadoghq.com/api/latest/usage-metering/#get-hourly-usage-by-product-family)에서 확인할 수 있습니다. 관련 마이그레이션 가이드는 [V1 시간당 사용량 API에서 V2로 마이그레이션하기](https://docs.datadoghq.com/account_management/guide/hourly-usage-migration/)를 참조하세요.",
+ "summary": "호스트 및 컨테이너의 시간당 사용량 가져오기"
+ },
+ "GetHourlyUsageAttribution": {
+ "description": "시간당 사용량 속성을 가져옵니다. 다중 리전 데이터는 2023년 3월 1일부터 사용할 수 있습니다.\n\n이 API 엔드포인트는 페이지 지정을 지원합니다. 모든 레코드를 수신하도록 `next_record_id` 값이\n응답에 설정되어 있는지 검사하세요. 해당 값이 설정되어 있다면 다른 요청을 수행하고 `next_record_id`를 파라미터로 전달하세요.\n의사 코드 예시:\n\n```\nresponse := GetHourlyUsageAttribution(start_month)\ncursor := response.metadata.pagination.next_record_id\nWHILE cursor != null BEGIN\n sleep(5 seconds) # 속도 제한에 걸리지 않도록 방지\n response := GetHourlyUsageAttribution(start_month, next_record_id=cursor)\n cursor := response.metadata.pagination.next_record_id\nEND\n```",
+ "summary": "시간당 사용량 속성 가져오기"
+ },
+ "GetIncidentManagement": {
+ "description": "인시던트 관리의 시간당 사용량을 가져옵니다.\n**참고:** 이 엔드포인트는 지원이 중단되었습니다. 모든 제품의 시간당 사용량 데이터는 이제 [제품군 API별 시간당 사용량 가져오기](https://docs.datadoghq.com/api/latest/usage-metering/#get-hourly-usage-by-product-family)에서 확인할 수 있습니다. 관련 마이그레이션 가이드는 [V1 시간당 사용량 API에서 V2로 마이그레이션하기](https://docs.datadoghq.com/account_management/guide/hourly-usage-migration/)를 참조하세요.",
+ "summary": "인시던트 관리의 시간당 사용량 가져오기"
+ },
+ "GetUsageIndexedSpans": {
+ "description": "인덱싱된 스팬의 시간당 사용량을 가져옵니다.\n**참고:** 이 엔드포인트는 지원이 중단되었습니다. 모든 제품의 시간당 사용량 데이터는 이제 [제품군 API별 시간당 사용량 가져오기](https://docs.datadoghq.com/api/latest/usage-metering/#get-hourly-usage-by-product-family)에서 확인할 수 있습니다. 관련 마이그레이션 가이드는 [V1 시간당 사용량 API에서 V2로 마이그레이션하기](https://docs.datadoghq.com/account_management/guide/hourly-usage-migration/)를 참조하세요.",
+ "summary": "인덱싱된 스팬의 시간당 사용량 가져오기"
+ },
+ "GetIngestedSpans": {
+ "description": "수집된 스팬의 시간당 사용량을 가져옵니다.\n**참고:** 이 엔드포인트는 지원이 중단되었습니다. 모든 제품의 시간당 사용량 데이터는 이제 [제품군 API별 시간당 사용량 가져오기](https://docs.datadoghq.com/api/latest/usage-metering/#get-hourly-usage-by-product-family)에서 확인할 수 있습니다. 관련 마이그레이션 가이드는 [V1 시간당 사용량 API에서 V2로 마이그레이션하기](https://docs.datadoghq.com/account_management/guide/hourly-usage-migration/)를 참조하세요.",
+ "summary": "수집된 스팬 시간당 사용량 가져오기"
+ },
+ "GetUsageInternetOfThings": {
+ "description": "IoT의 시간당 사용량 API를 가져옵니다.\n**참고:** 이 엔드포인트는 지원이 중단되었습니다. 모든 제품의 시간당 사용량 데이터는 이제 [제품군 API별 시간당 사용량 가져오기](https://docs.datadoghq.com/api/latest/usage-metering/#get-hourly-usage-by-product-family)에서 확인할 수 있습니다. 관련 마이그레이션 가이드는 [V1 시간당 사용량 API에서 V2로 마이그레이션하기](https://docs.datadoghq.com/account_management/guide/hourly-usage-migration/)를 참조하세요.",
+ "summary": "IoT의 시간당 사용량 가져오기"
+ },
+ "GetUsageLogs": {
+ "description": "로그의 시간당 사용량 API를 가져옵니다.\n**참고:** 이 엔드포인트는 지원이 중단되었습니다. 모든 제품의 시간당 사용량 데이터는 이제 [제품군 API별 시간당 사용량 가져오기](https://docs.datadoghq.com/api/latest/usage-metering/#get-hourly-usage-by-product-family)에서 확인할 수 있습니다. 관련 마이그레이션 가이드는 [V1 시간당 사용량 API에서 V2로 마이그레이션하기](https://docs.datadoghq.com/account_management/guide/hourly-usage-migration/)를 참조하세요.",
+ "summary": "로그의 시간당 사용량 가져오기"
+ },
+ "GetUsageLogsByRetention": {
+ "description": "보존 기간별로 인덱싱된 로그의 시간당 사용량 API를 가져옵니다.\n**참고:** 이 엔드포인트는 지원이 중단되었습니다. 모든 제품의 시간당 사용량 데이터는 이제 [제품군 API별 시간당 사용량 가져오기](https://docs.datadoghq.com/api/latest/usage-metering/#get-hourly-usage-by-product-family)에서 확인할 수 있습니다. 관련 마이그레이션 가이드는 [V1 시간당 사용량 API에서 V2로 마이그레이션하기](https://docs.datadoghq.com/account_management/guide/hourly-usage-migration/)를 참조하세요.",
+ "summary": "보존 기준 시간당 로그 사용량 가져오기"
+ },
+ "GetUsageLogsByIndex": {
+ "description": "인덱스 기준 로그의 시간당 사용량 API를 가져옵니다.",
+ "summary": "인덱스 기준 로그의 시간당 사용량 가져오기"
+ },
+ "GetMonthlyUsageAttribution": {
+ "description": "월별 사용량 속성을 가져옵니다. 다중 리전 데이터는 2023년 3월 1일부터 사용할 수 있습니다.\n\n이 API 엔드포인트는 페이지 지정을 지원합니다. 모든 레코드를 수신하도록 `next_record_id` 값이\n응답에 설정되어 있는지 검사하세요. 해당 값이 설정되어 있다면 다른 요청을 수행하고 `next_record_id`를 파라미터로 전달하세요.\n의사 코드 예시:\n\n```\nresponse := GetMonthlyUsageAttribution(start_month)\ncursor := response.metadata.pagination.next_record_id\nWHILE cursor != null BEGIN\n sleep(5 seconds) # 속도 제한에 걸리지 않도록 방지\n response := GetMonthlyUsageAttribution(start_month, next_record_id=cursor)\n cursor := response.metadata.pagination.next_record_id\nEND\n```",
+ "summary": "월별 사용량 속성 가져오기"
+ },
+ "GetUsageNetworkFlows": {
+ "description": "네트워크 플로우의 시간당 사용량 API를 가져옵니다.\n**참고:** 이 엔드포인트는 지원이 중단되었습니다. 모든 제품의 시간당 사용량 데이터는 이제 [제품군 API별 시간당 사용량 가져오기](https://docs.datadoghq.com/api/latest/usage-metering/#get-hourly-usage-by-product-family)에서 확인할 수 있습니다. 관련 마이그레이션 가이드는 [V1 시간당 사용량 API에서 V2로 마이그레이션하기](https://docs.datadoghq.com/account_management/guide/hourly-usage-migration/)를 참조하세요.",
+ "summary": "네트워크 플로우의 시간당 사용량 가져오기"
+ },
+ "GetUsageNetworkHosts": {
+ "description": "네트워크 호스트의 시간당 사용량을 가져옵니다.\n**참고:** 이 엔드포인트는 지원이 중단되었습니다. 모든 제품의 시간당 사용량 데이터는 이제 [제품군 API별 시간당 사용량 가져오기](https://docs.datadoghq.com/api/latest/usage-metering/#get-hourly-usage-by-product-family)에서 확인할 수 있습니다. 관련 마이그레이션 가이드는 [V1 시간당 사용량 API에서 V2로 마이그레이션하기](https://docs.datadoghq.com/account_management/guide/hourly-usage-migration/)를 참조하세요.",
+ "summary": "네트워크 호스트의 시간당 사용량 가져오기"
+ },
+ "GetUsageOnlineArchive": {
+ "description": "온라인 아카이브의 시간당 사용량을 가져옵니다.\n**참고:** 이 엔드포인트는 지원이 중단되었습니다. 모든 제품의 시간당 사용량 데이터는 이제 [제품군 API별 시간당 사용량 가져오기](https://docs.datadoghq.com/api/latest/usage-metering/#get-hourly-usage-by-product-family)에서 확인할 수 있습니다. 관련 마이그레이션 가이드는 [V1 시간당 사용량 API에서 V2로 마이그레이션하기](https://docs.datadoghq.com/account_management/guide/hourly-usage-migration/)를 참조하세요.",
+ "summary": "온라인 아카이브의 시간당 사용량 가져오기"
+ },
+ "GetUsageProfiling": {
+ "description": "프로파일링된 호스트의 시간당 사용량을 가져옵니다.\n**참고:** 이 엔드포인트는 지원이 중단되었습니다. 모든 제품의 시간당 사용량 데이터는 이제 [제품군 API별 시간당 사용량 가져오기](https://docs.datadoghq.com/api/latest/usage-metering/#get-hourly-usage-by-product-family)에서 확인할 수 있습니다. 관련 마이그레이션 가이드는 [V1 시간당 사용량 API에서 V2로 마이그레이션하기](https://docs.datadoghq.com/account_management/guide/hourly-usage-migration/)를 참조하세요.",
+ "summary": "프로파일링된 호스트의 시간당 사용량 가져오기"
+ },
+ "GetUsageRumUnits": {
+ "description": "[RUM](https://docs.datadoghq.com/real_user_monitoring/) 단위의 시간당 사용량을 가져옵니다.\n**참고:** 이 엔드포인트는 지원이 중단되었습니다. 모든 제품의 시간당 사용량 데이터는 이제 [제품군 API별 시간당 사용량 가져오기](https://docs.datadoghq.com/api/latest/usage-metering/#get-hourly-usage-by-product-family)에서 확인할 수 있습니다. 관련 마이그레이션 가이드는 [V1 시간당 사용량 API에서 V2로 마이그레이션하기](https://docs.datadoghq.com/account_management/guide/hourly-usage-migration/)를 참조하세요.",
+ "summary": "RUM 단위의 시간당 사용량 가져오기"
+ },
+ "GetUsageRumSessions": {
+ "description": "[RUM](https://docs.datadoghq.com/real_user_monitoring/) 세션의 시간당 사용량을 가져옵니다.\n**참고:** 이 엔드포인트는 지원이 중단되었습니다. 모든 제품의 시간당 사용량 데이터는 이제 [제품군 API별 시간당 사용량 가져오기](https://docs.datadoghq.com/api/latest/usage-metering/#get-hourly-usage-by-product-family)에서 확인할 수 있습니다. 관련 마이그레이션 가이드는 [V1 시간당 사용량 API에서 V2로 마이그레이션하기](https://docs.datadoghq.com/account_management/guide/hourly-usage-migration/)를 참조하세요.",
+ "summary": "RUM 세션의 시간당 사용량 가져오기"
+ },
+ "GetUsageSDS": {
+ "description": "민감한 데이터 스캐너의 시간당 사용량을 가져옵니다.\n**참고:** 이 엔드포인트는 지원이 중단되었습니다. 모든 제품의 시간당 사용량 데이터는 이제 [제품군 API별 시간당 사용량 가져오기](https://docs.datadoghq.com/api/latest/usage-metering/#get-hourly-usage-by-product-family)에서 확인할 수 있습니다. 관련 마이그레이션 가이드는 [V1 시간당 사용량 API에서 V2로 마이그레이션하기](https://docs.datadoghq.com/account_management/guide/hourly-usage-migration/)를 참조하세요.",
+ "summary": "민감한 데이터 스캐너의 시간당 사용량 가져오기"
+ },
+ "GetUsageSNMP": {
+ "description": "SNMP 기기의 시간당 사용량을 가져옵니다.\n**참고:** 이 엔드포인트는 지원이 중단되었습니다. 모든 제품의 시간당 사용량 데이터는 이제 [제품군 API별 시간당 사용량 가져오기](https://docs.datadoghq.com/api/latest/usage-metering/#get-hourly-usage-by-product-family)에서 확인할 수 있습니다. 관련 마이그레이션 가이드는 [V1 시간당 사용량 API에서 V2로 마이그레이션하기](https://docs.datadoghq.com/account_management/guide/hourly-usage-migration/)를 참조하세요.",
+ "summary": "SNMP 기기의 시간당 사용량 가져오기"
+ },
+ "GetUsageSummary": {
+ "description": "계정 전체의 모든 사용량을 가져옵니다.\n\nSDK 사용자 전용: `UsageSummaryResponse`, `UsageSummaryDate` 및\n`UsageSummaryDateOrg`의 모든 필드는 각 객체의 `additionalProperties` 맵을 통해 액세스할 수 있습니다.\n기존의 유형 지정 필드 게터는 변경되지 않습니다. 새로운 청구 기준에는\n유형 지정 필드 게터가 없습니다. 각 응답 수준에서 이용 가능한 모든 키를 열거하려면\n[사용량 요약에 사용 가능한 필드 가져오기](https://docs.datadoghq.com/api/latest/usage-metering/get-available-fields-for-usage-summary/)를\n사용하세요.\n\n이 엔드포인트는 [상위 수준 조직](https://docs.datadoghq.com/account_management/multi_organization/)에서만 액세스할 수 있습니다.",
+ "summary": "계정 전체 사용량 가져오기"
+ },
+ "GetUsageSynthetics": {
+ "description": "[Synthetics 검사](https://docs.datadoghq.com/synthetics/)의 시간당 사용량을 가져옵니다.\n**참고:** 이 엔드포인트는 지원이 중단되었습니다. 모든 제품의 시간당 사용량 데이터는 이제 [제품군 API별 시간당 사용량 가져오기](https://docs.datadoghq.com/api/latest/usage-metering/#get-hourly-usage-by-product-family)에서 확인할 수 있습니다. 관련 마이그레이션 가이드는 [V1 시간당 사용량 API에서 V2로 마이그레이션하기](https://docs.datadoghq.com/account_management/guide/hourly-usage-migration/)를 참조하세요.",
+ "summary": "Synthetic 검사의 시간당 사용량 가져오기"
+ },
+ "GetUsageSyntheticsAPI": {
+ "description": "[Synthetics API 검사](https://docs.datadoghq.com/synthetics/) 시간당 사용량을 가져옵니다.\n**참고:** 이 엔드포인트는 지원이 중단되었습니다. 모든 제품의 시간당 사용량 데이터는 이제 [제품군 API별 시간당 사용량 가져오기](https://docs.datadoghq.com/api/latest/usage-metering/#get-hourly-usage-by-product-family)에서 확인할 수 있습니다. 관련 마이그레이션 가이드는 [V1 시간당 사용량 API에서 V2로 마이그레이션하기](https://docs.datadoghq.com/account_management/guide/hourly-usage-migration/)를 참조하세요.",
+ "summary": "Synthetic API 검사의 시간당 사용량 가져오기"
+ },
+ "GetUsageSyntheticsBrowser": {
+ "description": "Synthetic 브라우저 검사의 시간당 사용량을 가져옵니다.\n**참고:** 이 엔드포인트는 지원이 중단되었습니다. 모든 제품의 시간당 사용량 데이터는 이제 [제품군 API별 시간당 사용량 가져오기](https://docs.datadoghq.com/api/latest/usage-metering/#get-hourly-usage-by-product-family)에서 확인할 수 있습니다. 관련 마이그레이션 가이드는 [V1 시간당 사용량 API에서 V2로 마이그레이션하기](https://docs.datadoghq.com/account_management/guide/hourly-usage-migration/)를 참조하세요.",
+ "summary": "Synthetic 브라우저 검사의 시간당 사용량 가져오기"
+ },
+ "GetUsageTimeseries": {
+ "description": "[사용자 지정 메트릭](https://docs.datadoghq.com/developers/metrics/custom_metrics/)의 시간당 사용량을 가져옵니다.\n**참고:** 이 엔드포인트는 지원이 중단되었습니다. 모든 제품의 시간당 사용량 데이터는 이제 [제품군 API별 시간당 사용량 가져오기](https://docs.datadoghq.com/api/latest/usage-metering/#get-hourly-usage-by-product-family)에서 확인할 수 있습니다. 관련 마이그레이션 가이드는 [V1 시간당 사용량 API에서 V2로 마이그레이션하기](https://docs.datadoghq.com/account_management/guide/hourly-usage-migration/)를 참조하세요.",
+ "summary": "사용자 지정 메트릭 시간당 사용량 가져오기"
+ },
+ "GetUsageTopAvgMetrics": {
+ "description": "시간당 평균으로 모든 [사용자 지정 메트릭](https://docs.datadoghq.com/developers/metrics/custom_metrics/)을 가져옵니다. month 파라미터를 사용하여 월간 누계 데이터 분석 정보를 가져오거나 day 파라미터를 사용하여 일간 분석 정보를 가져옵니다. 둘 중 하나의 파라미터를 반드시 사용해야 하며, 둘 중 하나만 허용됩니다.",
+ "summary": "시간별 평균 기준 모든 사용자 지정 메트릭 가져오기"
+ },
+ "ListUsers": {
+ "description": "조직의 모든 사용자를 나열합니다.",
+ "summary": "모든 사용자 나열하기"
+ },
+ "CreateUser": {
+ "description": "조직의 사용자를 생성합니다.\n\n**참고**: 사용자는 애플리케이션 키가 관리자에 속한 경우\n관리자 액세스 역할로만 생성할 수 있습니다.",
+ "summary": "사용자 생성하기",
+ "request_description": "생성해야 하는 사용자 객체입니다.",
+ "request_schema_description": "사용자를 생성하고 편집하고 비활성화합니다."
+ },
+ "DisableUser": {
+ "description": "조직에서 사용자를 삭제합니다.\n\n**참고:** 이 엔드포인트는 관리자에 속한 애플리케이션 키로만\n사용할 수 있습니다.",
+ "summary": "사용자 비활성화하기"
+ },
+ "GetUser": {
+ "description": "사용자의 세부 정보를 가져옵니다.",
+ "summary": "사용자 정보 가져오기"
+ },
+ "UpdateUser": {
+ "description": "사용자 정보를 업데이트합니다.\n\n**참고**: 관리자에게 속한 애플리케이션 키로만 사용할 수 있습니다.",
+ "summary": "사용자 업데이트하기",
+ "request_description": "업데이트 설명입니다.",
+ "request_schema_description": "사용자를 생성하고 편집하고 비활성화합니다."
+ },
+ "Validate": {
+ "description": "API 키(APP 키 아님)가 유효한지 검사합니다. 유효하지 않은 경우 403이 반환됩니다.",
+ "summary": "API 키 검증하기"
+ },
+ "SubmitLog": {
+ "description": "HTTP를 통해 Datadog 플랫폼으로 로그를 전송합니다. HTTP 요청당 제한은 다음과 같습니다.\n\n- 페이로드당 최대 콘텐츠 크기(압축되지 않음): 5MB\n- 단일 로그의 최대 크기: 1MB\n- 여러 로그를 배열로 전송할 경우의 최대 배열 크기: 1000개 항목\n\n1MB를 초과하는 모든 로그는 허용되며 Datadog가 로그를 자릅니다.\n- 단일 로그 요청의 경우, API는 1MB 크기부터 로그를 자르고 2xx를 반환합니다.\n- 다중 로그 요청의 경우, API는 모든 로그를 처리하고 1MB보다 큰 로그만 잘라낸 후 2xx를 반환합니다.\n\nDatadog은 로그를 압축하여 전송할 것을 권장합니다.\n압축된 로그를 전송할 경우 요청에 `Content-Encoding: gzip` 헤더를 추가하세요.\n\nHTTP API가 응답하는 상태 코드는 다음과 같습니다.\n- 200: 양호\n- 400: 잘못된 요청(페이로드 형식 문제일 가능성이 높음)\n- 403: 권한 문제(유효하지 않은 API 키를 사용 중일 가능성이 높음)\n- 413: 페이로드가 너무 큼(배치가 압축 해제 상태에서 5MB를 초과함)\n- 5xx: 내부 오류, 일정 시간 후 요청을 재시도해야 함",
+ "summary": "로그 전송하기",
+ "request_description": "전송할 로그(JSON 포맷)입니다.",
+ "request_schema_description": "구조화된 로그 메시지입니다."
+ },
+ "MuteAllMonitors": {
+ "description": "음소거를 설정하면 모든 모니터가 이메일을 통해 알림을 보내고\n[이벤트 스트림](https://docs.datadoghq.com/events)에 게시하는 것을 방지합니다.\n상태 변경은 경보 페이지를 확인해야만 볼 수 있습니다.",
+ "summary": "모든 모니터 음소거하기"
+ },
+ "UnmuteAllMonitors": {
+ "description": "모든 모니터의 음소거를 비활성화합니다. 전체 음소거가 이전에 활성화되지 않은 경우\n오류가 발생합니다.",
+ "summary": "모든 모니터 음소거 해제하기"
+ }
+}
\ No newline at end of file
diff --git a/hugo/data/partials/home.fr.yaml b/hugo/data/partials/home.fr.yaml
index ddac52214e8..a4bfd963f5f 100644
--- a/hugo/data/partials/home.fr.yaml
+++ b/hugo/data/partials/home.fr.yaml
@@ -7,7 +7,7 @@ guides:
link_text: "Débuter avec l'Agent"
link: getting_started/agent/
- title: Configurer des intégrations
- desc: "Rassemblez des métriques, des traces et des journaux grâce à plus de 1 000 intégrations natives pour les envoyer à Datadog."
+ desc: "Collectez des métriques, des traces et des logs grâce à plus de 1 000 intégrations natives pour les envoyer à Datadog."
link_text: Débuter avec les intégrations
link: getting_started/integrations/
- title: Débuter avec Datadog
@@ -16,309 +16,281 @@ guides:
link: getting_started/application/
nav_sections:
-- nav_section:
- - name: Observabilité
- - navtiles:
- - desc: Afficher l'état de santé et les performances de vos hosts et composants
- d'infrastructure
- icon: host-map
- link: infrastructure/
- title: Infrastructure
- - desc: Explorez, recherchez et créez des distributions pour vos métriques.
- icon: metric
- link: metrics/
- title: Métriques
- - desc: Surveiller l'état de santé, les performances et la sécurité de vos environnements
- conteneurisés
- icon: container
- link: containers/
- title: Surveillance des conteneurs
- - desc: Détectez et résolvez les problèmes de performance de vos applications
- sans serveur.
- icon: serverless
- link: serverless/
- title: Serverless
- - desc: Utilisez des objets tagués pour recueillir et représenter des données
- à propos de votre trafic réseau.
- icon: network
- link: network_monitoring/
- title: Surveillance du réseau
- - desc: Maîtrisez vos dépenses liées au cloud avec l'observabilité unifiée et
- les données de coût.
- icon: cloud-cost-management
- link: cloud_cost_management/
- title: Cloud Cost Management
- - desc: Visualiser et représenter votre infrastructure cloud en temps réel
- icon: cloudcraft
- link: cloudcraft/
- title: Cloudcraft
- - desc: Optimisez et résolvez les problèmes liés aux coûts, à l'utilisation et
- à la fraîcheur des données de votre stockage cloud.
- icon: file-wui
- link: infrastructure/storage_management/
- title: Gestion du stockage
- - desc: Explorez des dashboards prêts à l'emploi sur les performances et activez
- le tracing distribué.
- icon: apm
- link: tracing/
- title: APM
- - desc: Découvrez, mappez et surveillez des services sans modification du code.
- icon: usm
- link: universal_service_monitoring/
- title: Universal Service Monitoring
- - desc: Comparez des snapshots des performances et analysez les goulots d'étranglement.
- icon: profiling-1
- link: profiler/
- title: Profileur en continu
- - desc: Parcourez des dashboards enrichis, des métriques de requête et des échantillons
- de requêtes.
- icon: database-2
- link: database_monitoring/
- title: Database Monitoring
- - desc: Surveillez et optimisez les performances de vos pipelines de diffusion
- de données.
- icon: datastreams-monitoring
- link: data_streams/
- title: Data Streams Monitoring
- - desc: Surveiller la qualité des données, les performances et les coûts pour
- détecter les anomalies et éviter les problèmes en aval
- icon: data-observability-wui
- link: data_observability/
- title: Observabilité des données
- - desc: Traitez, surveillez et archivez vos logs ingérés.
- icon: log
- link: logs/
- title: Log Management
- - desc: Détecter et masquer les données sensibles telles que les informations
- personnelles, les clés d'API et les numéros de carte de crédit dans vos données
- de télémétrie
- icon: sensitive-data-scanner
- link: security/sensitive_data_scanner/
- title: Scanner de données sensibles
- - desc: Gérez et surveillez vos pipelines de télémétrie.
- icon: pipelines
- link: observability_pipelines/
- title: Observability Pipelines
- - desc: Identifier les erreurs critiques et accélérer leur résolution sur le web,
- les applications mobiles et le backend
- icon: error-tracking
- link: error_tracking/
- title: Error Tracking
-- nav_section:
- - name: AI
- - navtiles:
- - desc: Votre coéquipier agentique qui automatise les workflows de développement,
- de sécurité et opérationnels
- icon: bits-ai
- link: bits_ai/
- title: Bits AI Agents
- - desc: Détectez et visualisez des anomalies liées à vos applications et votre
- infrastructure.
- icon: watchdog
- link: watchdog/
- title: Watchdog
- - desc: Tracer, surveiller et sécuriser vos applications LLM
- icon: llm-observability
- link: llm_observability/
- title: LLM Observability
-- nav_section:
- - name: Digital Experience
- - navtiles:
- - desc: Enregistrez, observez et analysez l'expérience utilisateur de vos applications.
- icon: rum
- link: real_user_monitoring/
- title: Real User Monitoring
- - desc: Obtenez des informations pertinentes sur le comportement de vos utilisateurs
- et prenez des décisions éclairées pour vos produits.
- icon: product-analytics
- link: product_analytics/
- title: Analyse des produits
- - desc: Capturer et rejouer visuellement l'expérience utilisateur de vos utilisateurs
- icon: session-replay
- link: session_replay/
- title: Session Replay
- - desc: Vérifiez la disponibilité de vos services, identifiez les problèmes régionaux
- et testez les performances de vos applications.
- icon: synthetics
- link: synthetics/
- title: Surveillance Synthetic
- - desc: Surveillez des parcours utilisateur et des transactions opérationnelles
- dans des applications mobiles.
- icon: mobile
- link: mobile_app_testing/
- title: Tests d'application mobile
-- nav_section:
- - name: Software Delivery
- - navtiles:
- - desc: Unifier les données de télémétrie, les métadonnées et les workflows pour
- accélérer la livraison
- icon: internal-developer-portal-wui
- link: internal_developer_portal/
- title: Portail interne des développeurs
- - desc: Surveillez les performances et la santé de vos pipelines de CI.
- icon: ci
- link: continuous_integration/
- title: CI Visibility
- - desc: Détecter les tests défaillants et identifier les commits introduisant
- des tests défaillants
- icon: flaky-test-wui
- link: tests/
- title: Test Optimization
- - desc: Mettez en place des intégrations sans code et des tests en continu grâce
- aux fournisseurs CI/CD.
- icon: continuous-testing
- link: continuous_testing/
- title: Tests continus
- - desc: Interagir avec les services Datadog directement depuis votre IDE pendant
- le développement
- icon: ide
- link: ide_plugins/
- title: Plugins IDE
- - desc: Mesurer et améliorer les processus de livraison logicielle de votre organisation
- icon: ci
- link: delivery_performance/dora_metrics/
- title: Métriques DORA
- - desc: Activer ou désactiver des fonctionnalités, exécuter des tests A/B et déployer
- progressivement des fonctionnalités sans déploiement de code
- icon: signpost
- link: feature_flags/
- title: Feature Flags
- - desc: Visualiser les tendances des données de couverture et bloquer les fusions
- de PR en fonction des seuils de couverture
- icon: code-3
- link: code_coverage/
- title: Couverture du code
-- nav_section:
- - name: Sécurité
- - navtiles:
- - desc: Détecter, investiguer et répondre aux menaces de sécurité sur vos systèmes
- cloud et on-premises
- icon: siem
- link: security/cloud_siem/
- title: Cloud SIEM
- - desc: Détecter et corriger les vulnérabilités dans votre code, vos dépendances
- et votre infrastructure as code
- icon: security-code-security
- link: security/code_security/
- title: Sécurité du code
- - desc: Auditer en continu les configurations, évaluer les risques d'identité
- et détecter les menaces sur l'ensemble de votre infrastructure cloud
- icon: cloud-security-management
- link: security/cloud_security_management/
- title: Cloud Security
- - desc: Détecter et bloquer les menaces ciblant vos applications de production
- et vos API en temps réel
- icon: app-sec
- link: security/application_security/
- title: Protection des applications et des API
- - desc: Surveiller l'activité des fichiers, du réseau et des processus pour détecter
- les menaces en temps réel pesant sur votre infrastructure
- icon: security-workload-security
- link: security/workload_protection/
- title: Workload Protection
- - desc: Détecter et masquer les données sensibles telles que les informations
- personnelles, les clés d'API et les numéros de carte de crédit dans vos données
- de télémétrie
- icon: sensitive-data-scanner
- link: security/sensitive_data_scanner/
- title: Scanner de données sensibles
-- nav_section:
- - name: Gestion des services
- - navtiles:
- - desc: Identifier, analyser et atténuer les incidents perturbateurs dans votre
- organisation
- icon: incidents
- link: service_management/incident_management
- title: Incident Management
- - desc: Acheminer et escalader les alertes vers les bons membres de l'équipe avec
- des programmes d'astreinte et des notifications
- icon: on-call
- link: incident_response/on-call/
- title: On-Call
- - desc: Communiquer la disponibilité des services et les mises à jour d'incidents
- à vos utilisateurs et parties prenantes
- icon: status-page-wui
- link: incident_response/status_pages/
- title: Pages d'état
- - desc: Définir et suivre les objectifs de performance pour offrir une expérience
- client cohérente
- icon: slos
- link: service_level_objectives/
- title: Service Level Objectives
- - desc: Trier, suivre et corriger les problèmes avec une propriété centralisée
- et la collaboration d'équipe
- icon: case-management
- link: incident_response/case_management/
- title: Case Management
- - desc: Automatisez et orchestrez des processus dans toute votre pile technologique.
- icon: workflows
- link: service_management/workflows/
- title: Automatisation de workflows
- - desc: Créer des applications low-code pour rationaliser vos outils internes
- icon: app-builder
- link: service_management/app_builder/
- title: App Builder
-- nav_section:
- - name: Fonctionnalités de la plateforme et extension de Datadog
- - navtiles:
- - desc: Créez, modifiez et gérez vos monitors et notifications.
- icon: monitor
- link: monitors/
- title: Monitors et alertes
- - desc: Visualisez, analysez et générez des insights à propos de vos données.
- icon: dashboard
- link: dashboards/
- title: Dashboards
- - desc: Créer des documents en texte enrichi avec des graphiques en direct pour
- les investigations, les post-mortems et les runbooks
- icon: notebook
- link: notebooks/
- title: Notebooks
- - desc: Consultez les alertes, les incidents et d'autres insights Datadog depuis
- votre appareil mobile.
- icon: mobile
- link: mobile/
- title: Application mobile
- - desc: Configurer, mettre à niveau et gérer vos Agents à distance et à grande
- échelle
- icon: fleet-automation-wui
- link: agent/fleet_automation/
- title: Fleet Automation
- - desc: Gérer les paramètres organisationnels, la facturation et les contrôles
- d'accès aux données
- icon: cog-2
- link: account_management/
- title: Gestion de compte
- - desc: Recevez une alerte en cas de changement important dans vos applications
- et votre infrastructure.
- icon: events
- link: events/
- title: Gestion des événements
- - desc: Acheminez vos métriques, logs et traces OpenTelemetry vers Datadog.
- icon: open-telemetry
- link: opentelemetry/
- title: OpenTelemetry
- - desc: Recueillez des données à propos de vos applications, services et systèmes.
- icon: integrations
- link: integrations/
- title: Intégrations
- - desc: Testez l'API Datadog.
- icon: api
- link: api/latest/
- title: API
- - desc: Découvrez comment Datadog protège vos données.
- icon: security-lock
- link: data_security/
- title: Sécurité des données
- - desc: Étendre la plateforme Datadog
- icon: dev-code
- link: extend/
- title: Étendre Datadog
- - desc: Découvrez les meilleures pratiques et commencez à surveiller les environnements
- de vos clients.
- icon: colab
- link: partners/
- title: Partenaires
+ # For a better rendering, sections should include sub-sections with multiple of 4.
+ - nav_section:
+ - name: 'Observabilité'
+ - navtiles:
+ - title: Infrastructure
+ link: infrastructure/
+ icon: host-map
+ desc: "Visualisez l'état de santé et les performances de vos hosts et composants d'infrastructure."
+ - title: Métriques
+ link: metrics/
+ icon: metric
+ desc: "Explorez, recherchez et créez des distributions pour vos métriques."
+ - title: Container Monitoring
+ link: containers/
+ icon: container
+ desc: "Surveillez l'état de santé, les performances et la sécurité de vos environnements conteneurisés."
+ - title: Serverless
+ link: serverless/
+ icon: serverless
+ desc: Détectez et résolvez les problèmes de performance de vos applications serverless.
+ - title: Network Monitoring
+ link: network_monitoring/
+ icon: network
+ desc: Utilisez des objets tagués pour recueillir et représenter des données à propos de votre trafic réseau.
+ - title: Cloud Cost Management
+ link: cloud_cost_management/
+ icon: cloud-cost-management
+ desc: "Maîtrisez vos dépenses liées au cloud avec l'observabilité unifiée et les données de coût."
+ - title: Cloudcraft
+ link: cloudcraft/
+ icon: cloudcraft
+ desc: Visualisez et schématisez votre infrastructure cloud en temps réel.
+ - title: Gestion du stockage
+ link: infrastructure/storage_management/
+ icon: file-wui
+ desc: "Optimisez et dépannez vos dépenses, votre utilisation et la fraîcheur des données de votre stockage cloud."
+ - title: APM
+ link: tracing/
+ icon: apm
+ desc: "Explorez des dashboards prêts à l'emploi sur les performances et activez le tracing distribué."
+ - title: Universal Service Monitoring
+ link: universal_service_monitoring/
+ icon: usm
+ desc: "Découvrez, mappez et surveillez des services sans modification du code."
+ - title: Continuous Profiler
+ link: profiler/
+ icon: profiling-1
+ desc: "Comparez des snapshots des performances et analysez les goulots d'étranglement."
+ - title: Database Monitoring
+ link: database_monitoring/
+ icon: database-2
+ desc: "Parcourez des dashboards enrichis, des métriques de requête et des échantillons de requêtes."
+ - title: Data Streams Monitoring
+ link: data_streams/
+ icon: datastreams-monitoring
+ desc: Surveillez et optimisez les performances de vos pipelines de diffusion de données.
+ - title: Data Observability
+ link: data_observability/
+ icon: data-observability-wui
+ desc: "Surveillez la qualité, les performances et le coût des données pour détecter les anomalies et prévenir les problèmes en aval."
+ - title: Log Management
+ link: logs/
+ icon: log
+ desc: "Traitez, surveillez et archivez vos logs ingérés."
+ - title: Sensitive Data Scanner
+ link: security/sensitive_data_scanner/
+ icon: sensitive-data-scanner
+ desc: "Détectez et masquez les données sensibles telles que les PII, les clés d'API et les numéros de carte de crédit dans l'ensemble de votre télémétrie."
+ - title: Observability Pipelines
+ link: observability_pipelines/
+ icon: pipelines
+ desc: Gérez et surveillez vos pipelines de télémétrie.
+ - title: Error Tracking
+ link: error_tracking/
+ icon: error-tracking
+ desc: "Identifiez les erreurs critiques et accélérez leur résolution sur le Web, le mobile et le backend."
+ - nav_section:
+ - name: 'IA'
+ - navtiles:
+ - title: Agents Bits AI
+ link: bits_ai/
+ icon: bits-ai
+ desc: "Votre coéquipier agentique qui automatise les workflows de développement, de sécurité et opérationnels."
+ - title: Watchdog
+ link: watchdog/
+ icon: watchdog
+ desc: Détectez et visualisez des anomalies liées à vos applications et votre infrastructure.
+ - title: Agent Observability
+ link: llm_observability/
+ icon: llm-observability
+ desc: "Tracez, surveillez et sécurisez vos applications LLM."
+ - title: Serveur MCP
+ link: mcp_server/
+ icon: bits-ai
+ desc: "Connectez des agents IA à vos données d'observabilité pour interroger des métriques, des logs, des traces, et plus encore."
+ - nav_section:
+ - name: 'Digital Experience'
+ - navtiles:
+ - title: Real User Monitoring
+ link: real_user_monitoring/
+ icon: rum
+ desc: "Enregistrez, observez et analysez l'expérience utilisateur de vos applications."
+ - title: Product Analytics
+ link: product_analytics/
+ icon: product-analytics
+ desc: Obtenez des informations pertinentes sur le comportement de vos utilisateurs et prenez des décisions éclairées pour vos produits.
+ - title: Session Replay
+ link: session_replay/
+ icon: session-replay
+ desc: "Capturez et rejouez visuellement l'expérience de vos utilisateurs."
+ - title: Synthetic Monitoring
+ link: synthetics/
+ icon: synthetics
+ desc: "Vérifiez la disponibilité de vos services, identifiez les problèmes régionaux et testez les performances de vos applications."
+ - title: Mobile App Testing
+ link: mobile_app_testing/
+ icon: mobile
+ desc: Surveillez des parcours utilisateur et des transactions opérationnelles dans des applications mobiles.
+ - title: Expérimentations
+ link: experiments/
+ icon: experiment-wui
+ desc: "Planifiez, exécutez et analysez des tests A/B pour mesurer l'impact des changements de produit."
+ - nav_section:
+ - name: 'Software Delivery'
+ - navtiles:
+ - title: Internal Developer Portal
+ link: internal_developer_portal/
+ icon: internal-developer-portal-wui
+ desc: "Unifiez la télémétrie, les métadonnées et les workflows pour accélérer la livraison."
+ - title: CI Visibility
+ link: continuous_integration/
+ icon: ci
+ desc: Surveiller les performances et la santé de vos pipelines CI
+ - title: Test Optimization
+ link: tests/
+ icon: flaky-test-wui
+ desc: Détecter les tests défaillants et identifier les commits introduisant des tests défaillants
+ - title: Continuous Testing
+ link: continuous_testing/
+ icon: continuous-testing
+ desc: Mettez en place des intégrations sans code et des tests en continu grâce aux fournisseurs CI/CD.
+ - title: IDE Plugins
+ link: ide_plugins/
+ icon: ide
+ desc: Interagissez avec les services Datadog directement depuis votre IDE pendant que vous codez.
+ - title: DORA Metrics
+ link: delivery_performance/dora_metrics/
+ icon: ci
+ desc: Mesurez et améliorez les processus de livraison logicielle de votre organisation.
+ - title: Feature Flags
+ link: feature_flags/
+ icon: signpost
+ desc: "Activez ou désactivez des fonctionnalités, exécutez des tests A/B et déployez progressivement des fonctionnalités sans déploiement de code"
+ - title: Code Coverage
+ link: code_coverage/
+ icon: code-3
+ desc: Visualisez les tendances des données de couverture et bloquez les fusions de PR en fonction des seuils de couverture
+ - nav_section:
+ - name: 'Security'
+ - navtiles:
+ - title: Cloud SIEM
+ link: security/cloud_siem/
+ icon: siem
+ desc: "Détectez, enquêtez et répondez aux menaces de sécurité sur vos systèmes cloud et sur site"
+ - title: Code Security
+ link: security/code_security/
+ icon: security-code-security
+ desc: "Détectez et corrigez les vulnérabilités dans votre code, vos dépendances et votre infrastructure en tant que code"
+ - title: Cloud Security
+ link: security/cloud_security_management/
+ icon: cloud-security-management
+ desc: "Auditez en continu les configurations, évaluez les risques liés aux identités et détectez les menaces sur votre infrastructure cloud"
+ - title: Protection des applications et des API
+ link: security/application_security/
+ icon: app-sec
+ desc: Détectez et bloquez les menaces ciblant vos applications de production et vos API en temps réel
+ - title: Workload Protection
+ link: security/workload_protection/
+ icon: security-workload-security
+ desc: "Surveillez l'activité des fichiers, du réseau et des processus pour détecter les menaces en temps réel sur votre infrastructure"
+ - title: Sensitive Data Scanner
+ link: security/sensitive_data_scanner/
+ icon: sensitive-data-scanner
+ desc: "Détectez et masquez les données sensibles telles que les PII, les clés d'API et les numéros de carte de crédit dans l'ensemble de votre télémétrie."
+ - nav_section:
+ - name: 'Service Management'
+ - navtiles:
+ - title: Incident Management
+ link: service_management/incident_management
+ icon: incidents
+ desc: "Identifier, analyser et atténuer les incidents perturbateurs dans votre organisation"
+ - title: On-Call
+ link: incident_response/on-call/
+ icon: on-call
+ desc: "Acheminez et escaladez les alertes vers les bons membres de l'équipe via des plannings d'astreinte et le paging."
+ - title: Pages de statut
+ link: incident_response/status_pages/
+ icon: status-page-wui
+ desc: Communiquez la disponibilité des services et les mises à jour des incidents à vos utilisateurs et parties prenantes
+ - title: Service Level Objectives
+ link: service_level_objectives/
+ icon: slos
+ desc: Définissez et suivez des objectifs de performance pour offrir une expérience client cohérente
+ - title: Case Management
+ link: incident_response/case_management/
+ icon: case-management
+ desc: "Triez, suivez et corrigez les problèmes grâce à une gestion centralisée et à la collaboration d'équipe"
+ - title: Workflow Automation
+ link: service_management/workflows/
+ icon: workflows
+ desc: Automatisez et orchestrez des processus dans toute votre pile technologique.
+ - title: App Builder
+ link: service_management/app_builder/
+ icon: app-builder
+ desc: Créez des applications low-code pour rationaliser vos outils internes
+ - nav_section:
+ - name: 'Fonctionnalités de la plateforme et extension de Datadog'
+ - navtiles:
+ - title: Monitors et alerting
+ link: monitors/
+ icon: monitor
+ desc: "Créez, modifiez et gérez vos monitors et notifications."
+ - title: Dashboards
+ link: dashboards/
+ icon: dashboard
+ desc: "Visualisez, analysez et générez des insights à propos de vos données."
+ - title: Notebooks
+ link: notebooks/
+ icon: notebook
+ desc: "Créez des documents en texte enrichi avec des graphiques en direct pour les enquêtes, les post-mortems et les runbooks"
+ - title: Application mobile
+ link: mobile/
+ icon: mobile
+ desc: "Consultez les alertes, les incidents et d'autres insights Datadog depuis votre appareil mobile."
+ - title: Fleet Automation
+ link: agent/fleet_automation/
+ icon: fleet-automation-wui
+ desc: "Configurez, mettez à niveau et gérez vos Agents à distance et à grande échelle."
+ - title: Gestion de compte
+ link: account_management/
+ icon: cog-2
+ desc: "Gérez les paramètres de l'organisation, la facturation et les contrôles d'accès aux données"
+ - title: Event Management
+ link: events/
+ icon: events
+ desc: Recevez une alerte en cas de changement important dans vos applications et votre infrastructure.
+ - title: OpenTelemetry
+ link: opentelemetry/
+ icon: open-telemetry
+ desc: "Acheminez vos métriques, logs et traces OpenTelemetry vers Datadog."
+ - title: Integrations
+ link: integrations/
+ icon: integrations
+ desc: "Recueillez des données à propos de vos applications, services et systèmes."
+ - title: API
+ link: api/latest/
+ icon: api
+ desc: Tester la Datadog API
+ - title: Sécurité des données
+ link: data_security/
+ icon: security-lock
+ desc: Découvrez comment Datadog protège vos données.
+ - title: Client SDKs
+ link: client_sdks/
+ icon: building-block
+ desc: Installez et configurez le SDK Datadog pour votre plateforme
+ - title: Étendre Datadog
+ link: extend/
+ icon: dev-code
+ desc: Étendre la plateforme Datadog
+ - title: Partenaires
+ link: partners/
+ icon: colab
+ desc: Découvrez les meilleures pratiques et commencez à surveiller les environnements de vos clients.
+
popular_searches:
- title: "Documentation sur l'API"
link: api/
diff --git a/hugo/static/images/account_management/mobile_third_party_access/scope-restrictions-enable-2.png b/hugo/static/images/account_management/mobile_third_party_access/scope-restrictions-enable-2.png
new file mode 100644
index 00000000000..bbbdff78f84
Binary files /dev/null and b/hugo/static/images/account_management/mobile_third_party_access/scope-restrictions-enable-2.png differ
diff --git a/hugo/static/images/security/manual_severity_adjustment/finding_side_panel_button.png b/hugo/static/images/security/manual_severity_adjustment/finding_side_panel_button.png
new file mode 100644
index 00000000000..e47fccb220a
Binary files /dev/null and b/hugo/static/images/security/manual_severity_adjustment/finding_side_panel_button.png differ
diff --git a/hugo/static/images/security/manual_severity_adjustment/severity_breakdown.png b/hugo/static/images/security/manual_severity_adjustment/severity_breakdown.png
new file mode 100644
index 00000000000..d4bce154ded
Binary files /dev/null and b/hugo/static/images/security/manual_severity_adjustment/severity_breakdown.png differ
diff --git a/hugo/static/images/security/manual_severity_adjustment/severity_pill_popover.png b/hugo/static/images/security/manual_severity_adjustment/severity_pill_popover.png
new file mode 100644
index 00000000000..8285b61671e
Binary files /dev/null and b/hugo/static/images/security/manual_severity_adjustment/severity_pill_popover.png differ
diff --git a/hugo/static/images/tracing/software_catalog/idp_homepage_2.png b/hugo/static/images/tracing/software_catalog/idp_homepage_2.png
new file mode 100644
index 00000000000..b3486c06f8e
Binary files /dev/null and b/hugo/static/images/tracing/software_catalog/idp_homepage_2.png differ
diff --git a/hugo/static/images/tracing/software_catalog/services_entities_table_2.png b/hugo/static/images/tracing/software_catalog/services_entities_table_2.png
new file mode 100644
index 00000000000..62a478fb58b
Binary files /dev/null and b/hugo/static/images/tracing/software_catalog/services_entities_table_2.png differ
diff --git a/hugo/static/images/tracing/software_catalog/your_prs_table.png b/hugo/static/images/tracing/software_catalog/your_prs_table.png
new file mode 100644
index 00000000000..00654765ca2
Binary files /dev/null and b/hugo/static/images/tracing/software_catalog/your_prs_table.png differ
diff --git a/hugo/static/images/tracing/software_catalog/your_tickets_table.png b/hugo/static/images/tracing/software_catalog/your_tickets_table.png
new file mode 100644
index 00000000000..8335903a339
Binary files /dev/null and b/hugo/static/images/tracing/software_catalog/your_tickets_table.png differ