diff --git a/hugo/content/es/actions/connections/http.md b/hugo/content/es/actions/connections/http.md index f32ef6d6a0f..412a39543a6 100644 --- a/hugo/content/es/actions/connections/http.md +++ b/hugo/content/es/actions/connections/http.md @@ -3,193 +3,193 @@ aliases: - /es/service_management/app_builder/http_request/ - /es/service_management/workflows/connections/http/ - /es/service_management/app_builder/connections/http_request/ -description: Realiza solicitudes HTTP personalizadas a endpoints con autenticación, - métodos, encabezados y gestión de respuestas configurables para procesos y aplicaciones. +description: Realice solicitudes HTTP personalizadas a puntos de conexión con autenticación, + métodos, encabezados y manejo de respuestas configurables para flujos de trabajo + y aplicaciones. disable_toc: false further_reading: - link: /actions/connections/ tag: Documentación - text: Más información sobre las credenciales de conexión + text: Obtenga más información sobre las credenciales de conexión title: Solicitudes HTTP --- +Utilice la acción {{< ui >}}Make request{{< /ui >}} para realizar una solicitud personalizada a un punto de conexión HTTP. Puede controlar el método de solicitud y su contenido, cómo se autentica y procesa, y cómo debe responder a escenarios como certificados caducados o redirecciones. Si necesita agregar rangos de direcciones IP de Datadog a su lista de permitidos para que la acción HTTP funcione como se espera, utilice las IP enumeradas en el objeto `webhooks`. Consulte la [API de rangos de IP][1] para obtener más detalles. -Utiliza la acción **Make request** (Hacer solicitud) para realizar una solicitud personalizada a un endpoint HTTP. Puedes controlar el método de solicitud y su contenido, cómo se autentica y procesa, y cómo debería responder a escenarios como certificados caducados o redirecciones. Si necesitas añadir rangos de direcciones IP de Datadog a tu lista de permitidos para que la acción HTTP funcione como se espera, utiliza las IPs listadas en el objeto `webhooks`. Consulta la [API de rangos de IP][1] para más detalles. - -Para añadir una solicitud HTTP: +Para agregar una solicitud HTTP: {{< tabs >}} {{% tab "Workflow Automation" %}} -- En un nuevo proceso, haz clic en **Añadir step** (Añadir paso) y busca `Make request`. Selecciona la acción **Make request** (Hacer solicitud) para añadirla a tu proceso. -- En un proceso existente, haz clic en **+** y busca `Make request`. Selecciona la acción **Make request** (Hacer solicitud) para añadirla a tu proceso. +- En un nuevo flujo de trabajo, haga clic en {{< ui >}}Add step{{< /ui >}} y busque `Make request`. Seleccione la acción {{< ui >}}Make request{{< /ui >}} para agregarla a su flujo de trabajo. +- En un flujo de trabajo existente, haga clic en {{< ui >}}+{{< /ui >}} y busque `Make request`. Seleccione la acción {{< ui >}}Make request{{< /ui >}} para agregarla a su flujo de trabajo. -Especifica el método de solicitud y cualquier [autenticación][1] necesaria. Lee las secciones siguientes para obtener más información sobre las opciones de configuración disponibles. Opcionalmente, la solicitud puede esperar en las condiciones que especifiques en la sección **Conditional wait** (Espera condicional), y reintentar en un intervalo dado si la condición no se cumple. +Especifique el método de solicitud y cualquier [autenticación][1] necesaria. Lea las secciones a continuación para obtener más información sobre las opciones de configuración disponibles. Opcionalmente, la solicitud puede esperar a que se cumplan las condiciones que especifique en la sección {{< ui >}}Conditional wait{{< /ui >}} y reintentar en un intervalo determinado si la condición no se cumple. [1]: /es/actions/workflows/access_and_auth/ {{% /tab %}} {{% tab "App Builder" %}} -1. En tu aplicación, en **Data** (Datos), haz clic en **+ New** (+ Nuevo) y selecciona **Query** (Consulta). -1. Busca `HTTP` y selecciona la acción **Make request** (Hacer solicitud) para añadirla a tu aplicación. +1. En su aplicación, en {{< ui >}}Data{{< /ui >}}, haga clic en {{< ui >}}+ New{{< /ui >}} y seleccione {{< ui >}}Query{{< /ui >}} +1. Busque `HTTP`, luego seleccione la acción {{< ui >}}Make request{{< /ui >}} para agregarla a su aplicación. -Especifica el método de solicitud y cualquier [autenticación][1] necesaria. Lee las secciones siguientes para obtener más información sobre las opciones de configuración disponibles. +Especifique el método de solicitud y cualquier [autenticación][1] necesaria. Lea las secciones a continuación para obtener más información sobre las opciones de configuración disponibles. [1]: /es/actions/app_builder/access_and_auth/ {{% /tab %}} {{< /tabs >}} -## Autenticación +## Autenticación {#authentication} -Si necesitas autenticar tu solicitud, utiliza la **Connection** (Conexión) de la acción para configurar el método de autenticación. Puedes seleccionar una conexión preconfigurada del menú desplegable o crear una conexión. +Si necesita autenticar su solicitud, utilice el {{< ui >}}Connection{{< /ui >}} de la acción para configurar el método de autenticación. Puede seleccionar una conexión preconfigurada del menú desplegable o crear una conexión. -### Crear una conexión de AWS +### Crear una conexión de AWS {#create-an-aws-connection} -1. En la sección **Connection** (Conexión), haz clic en el icono más (**+**). -1. Selecciona **AWS**. -1. Introduce un **Connection name** (Nombre de conexión), **Account ID** (Identificación de cuenta) y **AWS Role Name** (Nombre de rol de AWS). -1. Haz clic en **Create** (Crear). +1. En la sección {{< ui >}}Connection{{< /ui >}}, haga clic en el icono de más ({{< ui >}}+{{< /ui >}}). +1. Seleccione {{< ui >}}AWS{{< /ui >}}. +1. Ingrese un {{< ui >}}Connection Name{{< /ui >}}, {{< ui >}}Account ID{{< /ui >}} y {{< ui >}}AWS Role Name{{< /ui >}}. +1. Haga clic en {{< ui >}}Create{{< /ui >}}. -### Crear una conexión de Azure +### Crear una conexión de Azure {#create-an-azure-connection} -1. En la sección **Connection** (Conexión), haz clic en el icono más (**+**). -1. Selecciona **Azure**. -1. Introduce un **Connection Name** (Nombre de conexión), **Tenant ID** (ID de inquilino), **Client ID** (ID de cliente) y **Client Secret** (Secreto de cliente). -1. Opcionalmente, introduce el **Custom Scope** (Ámbito personalizado) que se solicitará a Microsoft al adquirir un token de acceso OAuth 2. El ámbito de un recurso se construye utilizando el identificador URI del recurso y `.default`, separados por una barra oblicua (`/`). Por ejemplo, `{identifierURI}/.default`. Para obtener más información, consulta [la documentación de Microsoft sobre .default scope][3]. -1. Haz clic en **Create** (Crear). +1. En la sección {{< ui >}}Connection{{< /ui >}}, haga clic en el icono de más ({{< ui >}}+{{< /ui >}}). +1. Seleccione {{< ui >}}Azure{{< /ui >}}. +1. Ingrese un {{< ui >}}Connection Name{{< /ui >}}, {{< ui >}}Tenant ID{{< /ui >}}, {{< ui >}}Client ID{{< /ui >}} y {{< ui >}}Client Secret{{< /ui >}}. +1. Opcionalmente, ingrese el {{< ui >}}Custom Scope{{< /ui >}} que se solicitará a Microsoft al adquirir un token de acceso OAuth 2.0. El contexto de un recurso se construye utilizando el URI del identificador para el recurso y `.default`, separados por una barra diagonal (`/`). Por ejemplo, `{identifierURI}/.default`. Para obtener más información, consulte [la documentación de Microsoft sobre el contexto .default][3]. +1. Haga clic en {{< ui >}}Create{{< /ui >}}. -### Crear una conexión de autenticación de token HTTP +### Crear una conexión de autenticación de token HTTP {#create-an-http-token-authentication-connection} -La conexión de autorización de token utiliza un token de portador para autenticar la solicitud HTTP. +La conexión de autenticación de token utiliza un token de portador para autenticar la solicitud HTTP. -1. En la sección **Connection** (Conexión), haz clic en el icono más (**+**). -1. Selecciona **HTTP**. -1. Introduce un **Connection Name** (Nombre de conexión). -1. Introduce la **Base URL** (URL de base) para la autenticación. -1. En el menú desplegable **Authentication Type** (Tipo de autenticación), selecciona **Token Auth** (Autorización de token). -1. Introduce un **Token Name** (Nombre de token) y un **Token Value** (Valor de token). Puedes introducir varios tokens. Para hacer referencia a tu token en un encabezado, parámetro o en el cuerpo de la solicitud, utiliza la sintaxis `{{ secretTokenName }}`. -1. Si lo deseas, puedes añadir **Request Headers** (Encabezados de solicitud), **URL parameters** (Parámetros de URL) y **Body** (Cuerpo) a tu solicitud. -1. Haz clic en **Create** (Crear). +1. En la sección {{< ui >}}Connection{{< /ui >}}, haga clic en el icono de más ({{< ui >}}+{{< /ui >}}). +1. Seleccione {{< ui >}}HTTP{{< /ui >}}. +1. Ingrese un {{< ui >}}Connection Name{{< /ui >}}. +1. Ingrese el {{< ui >}}Base URL{{< /ui >}} para la autenticación. +1. En el menú desplegable {{< ui >}}Authentication Type{{< /ui >}}, seleccione {{< ui >}}Token Auth{{< /ui >}}. +1. Ingrese un {{< ui >}}Token Name{{< /ui >}} y {{< ui >}}Token Value{{< /ui >}}. Puede ingresar múltiples tokens. Para hacer referencia a su token en un encabezado, parámetro o en el cuerpo de la solicitud, use la sintaxis `{{ secretTokenName }}`. +1. Opcionalmente, agregue {{< ui >}}Request Headers{{< /ui >}}, {{< ui >}}URL parameters{{< /ui >}} y un {{< ui >}}Body{{< /ui >}} adicionales a su solicitud. +1. Haga clic en {{< ui >}}Create{{< /ui >}}. -### Crear una conexión de autenticación básica HTTP +### Cree una conexión de autenticación básica HTTP {#create-an-http-basic-authentication-connection} La conexión de autenticación básica utiliza un encabezado de autorización con un nombre de usuario y una contraseña para autenticar la solicitud HTTP. -1. En la sección **Connection** (Conexión), haz clic en el icono más (**+**). -1. Selecciona **HTTP**. -1. Introduce un **Connection Name** (Nombre de conexión). -1. Introduce la **Base URL** (URL de base) para la autenticación. -1. En el menú desplegable **Authentication Type** (Tipo de autenticación), selecciona **Basic Auth** (Autorización básica). -1. Introduce un **Username** (Nombre de usuario) y una **Password** (Contraseña). El encabezado de la solicitud de autorización requerida se rellena automáticamente utilizando tu nombre de usuario y contraseña. -1. Haz clic en **Create** (Crear). +1. En la sección {{< ui >}}Connection{{< /ui >}}, haga clic en el icono de más ({{< ui >}}+{{< /ui >}}). +1. Seleccione {{< ui >}}HTTP{{< /ui >}}. +1. Ingrese un {{< ui >}}Connection Name{{< /ui >}}. +1. Ingrese el {{< ui >}}Base URL{{< /ui >}} para la autenticación. +1. En el menú desplegable {{< ui >}}Authentication Type{{< /ui >}}, seleccione {{< ui >}}Basic Auth{{< /ui >}}. +1. Ingrese un {{< ui >}}Username{{< /ui >}} y {{< ui >}}Password{{< /ui >}}. El encabezado de solicitud de autorización requerido se completa automáticamente usando su nombre de usuario y contraseña. +1. Haga clic en {{< ui >}}Create{{< /ui >}}. -### Crear una conexión de autenticación HTTP de 2 pasos +### Cree una conexión de autenticación HTTP de 2 pasos {#create-a-2-step-http-authentication-connection} -La conexión HTTP de 2 pasos te permite realizar una solicitud preliminar para recuperar un token de acceso con el que autenticar la solicitud HTTP. Esto es útil para autenticar aplicaciones JSON Web Token (JWT) y OAuth. +La conexión HTTP de 2 pasos le permite realizar una solicitud preliminar para recuperar un token de acceso con el cual autenticar la solicitud HTTP. Esto es útil para autenticar aplicaciones de JSON Web Token (JWT) y OAuth. -1. En la sección **Connection** (Conexión), haz clic en el icono más (**+**). -1. Selecciona **HTTP**. -1. Introduce un **Connection Name** (Nombre de conexión). -1. Introduce la **Base URL** (URL de base) para la autenticación. -1. En el menú desplegable **Authentication Type** (Tipo de autenticación), selecciona **2 Step Auth** (Autenticación de 2 pasos). +1. En la sección {{< ui >}}Connection{{< /ui >}}, haga clic en el icono de más ({{< ui >}}+{{< /ui >}}). +1. Seleccione {{< ui >}}HTTP{{< /ui >}}. +1. Ingrese un {{< ui >}}Connection Name{{< /ui >}}. +1. Ingrese el {{< ui >}}Base URL{{< /ui >}} para la autenticación. +1. En el menú desplegable {{< ui >}}Authentication Type{{< /ui >}}, seleccione {{< ui >}}2 Step Auth{{< /ui >}}. {{< tabs >}} -{{% tab "Token auth" %}} -Configura la consulta preliminar del token de acceso: -1. En el menú desplegable **Secret Type** (Tipo de secreto), selecciona **Token Auth** (Autorización de token). -1. Introduce un nombre de token y un valor de token -1. Introduce la **Request URL** (URL de la solicitud) y especifica el tipo de solicitud como **GET** o **POST**. -1. Si lo deseas, puedes añadir **Request Headers** (Encabezados de solicitud), **URL parameters** (Parámetros de URL) y **Body** (Cuerpo) a la solicitud. - -Obtener el token de acceso de la respuesta: -1. En **Variable Path to Access Token** (Ruta variable al token de acceso), introduce la ruta al token de acceso en la respuesta. Esta es la ruta a través de la cual se devuelve el token de acceso después de realizar la llamada de autenticación. Por ejemplo, si el token de acceso se devuelve como cuerpo de la solicitud de acceso, utiliza `body`. Si el token de acceso se devuelve en una propiedad denominada `token` de la respuesta `body`, utiliza `body.token`. Las rutas distinguen mayúsculas y minúsculas. -1. Opcionalmente, introduce un **Refresh Interval** (Intervalo de actualización). Se trata del tiempo que debe transcurrir hasta que caduque el token de acceso, especificado en segundos. Cuando caduca, la conexión solicita automáticamente un nuevo token de acceso. Establecer un intervalo de `0` desactiva la actualización del token. - -Utiliza el token recuperado para autenticar tu conexión: -1. En **Request Detail** (Detalle de solicitud), introduce **Request Headers** (Encabezados de solicitud), **URL parameters** (Parámetros de URL) y un **Body** (Cuerpo) para completar tu solicitud utilizando el token de acceso recuperado. -1. Haz clic en **Create** (Crear). +{{% tab "Autenticación de token" %}} +Configure la consulta de token de acceso preliminar: +1. En el menú desplegable {{< ui >}}Secret Type{{< /ui >}}, seleccione {{< ui >}}Token Auth{{< /ui >}}. +1. Ingrese un Nombre de token y un Valor de token +1. Ingrese el {{< ui >}}Request URL{{< /ui >}} y especifique el tipo de solicitud como {{< ui >}}GET{{< /ui >}} o {{< ui >}}POST{{< /ui >}}. +1. Opcionalmente, agregue {{< ui >}}Request Headers{{< /ui >}}, {{< ui >}}URL parameters{{< /ui >}} y un {{< ui >}}Body{{< /ui >}} adicionales a la solicitud. + +Obtenga el token de acceso de la respuesta: +1. En {{< ui >}}Variable Path to Access Token{{< /ui >}}, ingrese la ruta al token de acceso en la respuesta. Esta es la ruta a través de la cual se devuelve su token de acceso después de realizar la llamada de autenticación. Por ejemplo, si el token de acceso se devuelve como el cuerpo de la solicitud de acceso, use `body`. Si el token de acceso se devuelve en una propiedad llamada `token` de la respuesta `body`, use `body.token`. Las rutas distinguen entre mayúsculas y minúsculas. +1. Opcionalmente, ingrese un {{< ui >}}Refresh Interval{{< /ui >}}. Esta es la duración hasta que el token de acceso caduque, especificada en segundos. Cuando el token caduca, la conexión solicita automáticamente un nuevo token de acceso. Establecer un intervalo de `0` deshabilita la actualización del token. + +Use su token recuperado para autenticar su conexión: +1. En {{< ui >}}Request Detail{{< /ui >}}, ingrese {{< ui >}}Request Headers{{< /ui >}}, {{< ui >}}URL parameters{{< /ui >}} y un {{< ui >}}Body{{< /ui >}} para completar su solicitud usando el token de acceso recuperado. +1. Haga clic en {{< ui >}}Create{{< /ui >}}. {{% /tab %}} -{{% tab "Basic auth" %}} -Configura la consulta de autenticación preliminar: -1. En el menú desplegable **Secret Type** (Tipo de secreto), selecciona **Basic Auth** (Autorización básica). -1. Introduce un **Username** (Nombre de usuario) y una **Password** (Contraseña). La sección **Request Headers** (Encabezados de solicitud) se rellena automáticamente con tu nombre de usuario y contraseña. +{{% tab "Autenticación básica" %}} +Configure la consulta de autenticación preliminar: +1. En el menú desplegable {{< ui >}}Secret Type{{< /ui >}}, seleccione {{< ui >}}Basic Auth{{< /ui >}}. +1. Ingrese un {{< ui >}}Username{{< /ui >}} y {{< ui >}}Password{{< /ui >}}. La sección {{< ui >}}Request Headers{{< /ui >}} se completa automáticamente usando su nombre de usuario y contraseña. -Configura la solicitud de autenticación: -1. Introduce la **Request URL** (URL de la solicitud) y especifica el tipo de solicitud como **GET** o **POST**. -1. Si lo deseas, puedes añadir **Request Headers** (Encabezados de solicitud), **URL parameters** (Parámetros de URL) y **Body** (Cuerpo) a la solicitud. +Configure la solicitud de autenticación: +1. Ingrese el {{< ui >}}Request URL{{< /ui >}} y especifique el tipo de solicitud como {{< ui >}}GET{{< /ui >}} o {{< ui >}}POST{{< /ui >}}. +1. Opcionalmente, agregue {{< ui >}}Request Headers{{< /ui >}}, {{< ui >}}URL parameters{{< /ui >}} y un {{< ui >}}Body{{< /ui >}} adicionales a la solicitud. -Obtener el token de acceso de la respuesta: -1. En **Variable Path to Access Token** (Ruta variable al token de acceso), introduce la ruta al token de acceso en la respuesta. Esta es la ruta a través de la cual se devuelve el token de acceso después de realizar la llamada de autenticación. Por ejemplo, si el token de acceso se devuelve como cuerpo de la solicitud de acceso, utiliza `body`. Si el token de acceso se devuelve en una propiedad denominada `token` de la respuesta `body`, utiliza `body.token`. Las rutas distinguen mayúsculas y minúsculas. -1. Opcionalmente, introduce un **Refresh Interval** (Intervalo de actualización). Se trata del tiempo que debe transcurrir hasta que caduque el token de acceso, especificado en segundos. Cuando caduca, la conexión solicita automáticamente un nuevo token de acceso. Establecer un intervalo de `0` desactiva la actualización del token. +Obtenga el token de acceso de la respuesta: +1. En {{< ui >}}Variable Path to Access Token{{< /ui >}}, ingrese la ruta al token de acceso en la respuesta. Esta es la ruta a través de la cual se devuelve su token de acceso después de realizar la llamada de autenticación. Por ejemplo, si el token de acceso se devuelve como el cuerpo de la solicitud de acceso, use `body`. Si el token de acceso se devuelve en una propiedad llamada `token` de la respuesta `body`, use `body.token`. Las rutas distinguen entre mayúsculas y minúsculas. +1. Opcionalmente, ingrese un {{< ui >}}Refresh Interval{{< /ui >}}. Esta es la duración hasta que el token de acceso caduque, especificada en segundos. Cuando el token caduca, la conexión solicita automáticamente un nuevo token de acceso. Establecer un intervalo de `0` deshabilita la actualización del token. -Utiliza el token recuperado para autenticar tu conexión: -1. En **Request Detail** (Detalle de solicitud), introduce **Request Headers** (Encabezados de solicitud), **URL parameters** (Parámetros de URL) y un **Body** (Cuerpo) para completar tu solicitud utilizando el token de acceso recuperado. -1. Haz clic en **Create** (Crear). +Use su token recuperado para autenticar su conexión: +1. En {{< ui >}}Request Detail{{< /ui >}}, ingrese {{< ui >}}Request Headers{{< /ui >}}, {{< ui >}}URL parameters{{< /ui >}} y un {{< ui >}}Body{{< /ui >}} para completar su solicitud usando el token de acceso recuperado. +1. Haga clic en {{< ui >}}Create{{< /ui >}}. {{% /tab %}} {{< /tabs >}} -### Crear una conexión HTTP mTLS +### Crear una conexión HTTP mTLS {#create-an-http-mtls-connection} -La conexión de autenticación TLS mutua (mTLS) permite utilizar una clave privada y un certificado TLS para autenticar la solicitud HTTP. +La conexión TLS mutua (mTLS) le permite usar una clave privada y un certificado TLS para autenticar la solicitud HTTP. -
El certificado del cliente (.crt, .pem) y la clave privada (.key, .pem) deben utilizar el formato PEM.
+
El certificado de cliente (.crt, .pem) y la clave privada (.key, .pem) deben usar el formato PEM.
-1. En la sección **Connection** (Conexión), haz clic en el icono más (**+**). -1. Selecciona **HTTP**. -1. Introduce un **Connection Name** (Nombre de conexión). -1. Introduce la **Base URL** (URL de base) para la autenticación. -1. En el menú desplegable **Authentication Type** (Tipo de autenticación), selecciona **mTLS Auth** (Autenticación mTLS). -1. Haz clic en **Upload File** (Cargar archivo) para cargar tu **Private Key** (Clave privada). -1. Haz clic en **Upload File** (Cargar archivo) para cargar tu **Certificate** (Certificado). -1. Haz clic en **Create** (Crear). +1. En la sección {{< ui >}}Connection{{< /ui >}}, haga clic en el icono de más ({{< ui >}}+{{< /ui >}}). +1. Seleccione {{< ui >}}HTTP{{< /ui >}}. +1. Ingrese un {{< ui >}}Connection Name{{< /ui >}}. +1. Ingrese el {{< ui >}}Base URL{{< /ui >}} para la autenticación. +1. En el menú desplegable {{< ui >}}Authentication Type{{< /ui >}}, seleccione {{< ui >}}mTLS Auth{{< /ui >}}. +1. Haga clic en {{< ui >}}Upload File{{< /ui >}} para cargar su {{< ui >}}Private Key{{< /ui >}}. +1. Haga clic en {{< ui >}}Upload File{{< /ui >}} para cargar su {{< ui >}}Certificate{{< /ui >}}. +1. Haga clic en {{< ui >}}Create{{< /ui >}}. -## Entradas +## Entradas {#inputs} -Tu solicitud requiere una URL y un método. Opcionalmente, puedes introducir: -- parámetros URL +Se requieren una URL y un método de solicitud para su solicitud. Opcionalmente, puede ingresar: +- Parámetros de URL - encabezados -- tipo de contenido +- el tipo de contenido - un cuerpo de solicitud - cookies -También puedes seleccionar si quieres permitir certificados caducados o seguir redireccionamientos. +También puede seleccionar si desea permitir certificados caducados o seguir redirecciones. -### Opciones de respuestas +### Opciones de respuesta {#response-options} -En **Error on Status** (Error de estado), introduce una lista delimitada por comas de cualquier código de estado sobre el cual devolver un error. Utiliza el menú desplegable **Response Parsing** (Clasificación de respuestas) para anular el método de clasificación de respuestas predeterminado, deducido de los encabezados, y **Response Encoding** (Codificación de respuestas), si el servidor de destino especifica una codificación incorrecta en sus encabezados de respuestas. +En {{< ui >}}Error on Status{{< /ui >}}, ingrese una lista separada por comas de cualquier código de estado en el que se deba devolver un error. Utilice el menú desplegable {{< ui >}}Response Parsing{{< /ui >}} para anular el método de parseo de respuesta predeterminado inferido a partir de los encabezados, y {{< ui >}}Response Encoding{{< /ui >}} si el servidor de destino especifica la codificación incorrecta en sus encabezados de respuesta. -## Acciones privadas +## Private Actions {#private-actions} -{{< callout url="https://www.datadoghq.com/product-preview/private-actions/" btn_hidden="false" header="Únete a la vista previa">}} -Las Acciones privadas están en vista previa. Utiliza este formulario para solicitar acceso hoy mismo. +{{< callout url="https://www.datadoghq.com/product-preview/private-actions/" btn_hidden="false" header="¡Únase a la vista previa!">}} +Las Private Actions están en vista previa. Utilice este formulario para solicitar acceso hoy mismo. {{< /callout >}} -Puedes utilizar una acción HTTP privada para interactuar con servicios alojados en tu red privada, sin exponer tus servicios a la Internet pública. Las acciones privadas utilizan un ejecutor de acciones privadas que instalas en un host de tu red utilizando Docker y emparejándolo con una conexión Datadog. Para obtener más información, consulta [Acciones privadas][5]. +Puede utilizar una acción HTTP privada para interactuar con servicios alojados en su red privada sin exponer sus servicios a la internet pública. Las Private Actions utilizan un ejecutor de acciones privadas que usted instala en un servidor de su red mediante Docker y lo vincula con una conexión de Datadog. Para obtener más información, consulte [Private Actions][5]. Para configurar una solicitud HTTP privada: -1. Añade una acción HTTP a tu aplicación. -1. En la sección **Connection** (Conexión), haz clic en el icono más (**+**). -1. Selecciona **HTTP**. -1. Introduce un **Connection Name** (Nombre de conexión). -1. Introduce la **URL de base** para el host de tu red privada. -1. En **Tipo**, asegúrate de que el **Ejecutor de acciones privadas** está seleccionado. -1. En el menú desplegable **Ejecutor de acciones privadas**, selecciona tu [ejecutor de acciones privadas][5]. -1. En el menú desplegable **Tipo de autenticación**, selecciona un tipo de autenticación y rellena los campos requeridos. Las solicitudes HTTP privadas admiten los siguientes tipos de autenticación: +1. Agregue una acción HTTP a su aplicación. +1. En la sección {{< ui >}}Connection{{< /ui >}}, haga clic en el icono de más ({{< ui >}}+{{< /ui >}}). +1. Seleccione {{< ui >}}HTTP{{< /ui >}}. +1. Ingrese un {{< ui >}}Connection Name{{< /ui >}}. +1. Ingrese el {{< ui >}}Base URL{{< /ui >}} para el servidor en su red privada. +1. Para {{< ui >}}Type{{< /ui >}}, asegúrese de que {{< ui >}}Private Action Runner{{< /ui >}} esté seleccionado. +1. En el menú desplegable {{< ui >}}Private Action Runner{{< /ui >}}, seleccione su [ejecutor de acciones privadas][5]. +1. En el menú desplegable {{< ui >}}Authentication Type{{< /ui >}}, seleccione un tipo de Autenticación y complete los campos obligatorios. Las solicitudes HTTP privadas admiten los siguientes tipos de autenticación: - Sin autenticación - [Autenticación básica](#create-an-http-basic-authentication-connection) - [Autenticación por token](#create-an-http-token-authentication-connection) - Para obtener información sobre la configuración de credenciales para la autenticación de tokens, consulta [Gestión de credenciales de acciones privadas][6]. -1. Haz clic en **Next, Confirm Access** (Siguiente, confirmar acceso) y configura el acceso a la consulta. -1. Haz clic en **Create** (Crear). + Para obtener información sobre cómo configurar las credenciales para la Autenticación por token, consulte [Gestión de credenciales de acciones privadas][6]. +1. Haga clic en {{< ui >}}Next, Confirm Access{{< /ui >}} y configure el acceso a la consulta. +1. Haga clic en {{< ui >}}Create{{< /ui >}}. -## Referencias adicionales +## Lecturas adicionales {#further-reading} {{< partial name="whats-next/whats-next.html" >}} -
¿Tienes preguntas o comentarios? Únete al canal **#workflows** o **#app-builder** en [Datadog Community Slack][4]. +
¿Tiene preguntas o comentarios? Únase al canal **#workflows** o **#app-builder** en el [Datadog Community Slack][4]. [1]: https://docs.datadoghq.com/es/api/latest/ip-ranges/#list-ip-ranges [3]: https://learn.microsoft.com/en-us/azure/active-directory/develop/scopes-oidc#the-default-scope [4]: https://chat.datadoghq.com/ [5]: /es/actions/private_actions -[6]: /es/actions/private_actions/private_action_credentials/?tab=httpsaction#credential-files \ No newline at end of file +[6]: /es/actions/connections/private_action_credentials/?tab=httpsaction#credential-files \ No newline at end of file diff --git a/hugo/content/es/actions/private_actions/reference.md b/hugo/content/es/actions/private_actions/reference.md new file mode 100644 index 00000000000..d6dd6207181 --- /dev/null +++ b/hugo/content/es/actions/private_actions/reference.md @@ -0,0 +1,82 @@ +--- +description: Tablas de referencia para los ajustes de configuración del ejecutor de + Private Actions, las acciones e integraciones admitidas y los formatos de archivo + de credenciales. +further_reading: +- link: actions/private_actions/ + tag: Documentación + text: Descripción general de Private Actions +- link: actions/private_actions/set_up_agent_based/ + tag: Documentación + text: Configurar un ejecutor de Private Actions +- link: actions/private_actions/execution_policies/ + tag: Documentación + text: Políticas de ejecución +- link: actions/connections/private_action_credentials/ + tag: Documentación + text: Manejo de credenciales de Private Actions +title: Referencia del ejecutor de Private Actions +--- +## Descripción general {#overview} + +Esta página es la referencia para los ejecutores de Private Actions y cubre los ajustes de configuración, las acciones e integraciones que admite cada ejecutor y los formatos de archivo de credenciales. Para obtener más información sobre los conceptos y la configuración de Private Actions, consulte [Descripción general de Private Actions][1]. + +## Configuración del ejecutor {#runner-configuration} + +El ejecutor lee sus ajustes desde la sección `private_action_runner` de su [configuración][2]. + +Para saber cómo encajan los ajustes de inscripción (`self_enroll` y `api_key_only_enrollment`) en la inscripción del ejecutor, consulte [Inscripción y propiedad][3]. + +El mismo ajuste tiene nombres diferentes según cómo instale el ejecutor. Las instalaciones de Host usan variables de entorno, Helm usa claves en camelCase bajo `privateActionRunner`, y el Datadog Operator usa claves en snake_case bajo `private_action_runner`. Utilice esta tabla para traducir los ajustes comunes entre los métodos de instalación. + +| Ajuste | Host (variable de entorno) | Helm (`privateActionRunner.*`) | Datadog Operator (`private_action_runner.*`) | +|---|---|---|---| +| Habilitar | `DD_PRIVATE_ACTION_RUNNER_ENABLED` | `enabled` | `enabled` | +| Auto-inscripción | `DD_PRIVATE_ACTION_RUNNER_SELF_ENROLL` | `selfEnroll` | `self_enroll` | +| Lista de permitidos de acciones | `DD_PRIVATE_ACTION_RUNNER_ACTIONS_ALLOWLIST` (separado por comas) | `actionsAllowlist` (lista) | `actions_allowlist` (lista) | + +## Acciones e integraciones admitidas {#supported-actions-and-integrations} + +Esta matriz muestra, para cada integración, su disponibilidad en cada tipo de ejecutor y si se puede autorizar a través de [Políticas de ejecución][4]. + +
La disponibilidad en el Agent y la autorización a través de Políticas de ejecución son independientes. Una integración puede ejecutarse en el Agent sin ser autorizable a través de una Política de ejecución.
+ +| Integración | Runner en el Agent | Autorizable a través de
Políticas de ejecución | Runner independiente | +|---|:---:|:---:|:---:| +| Kubernetes | {{< X >}} | {{< X >}} | {{< X >}} | +| Remote Action (por ejemplo, rshell) | {{< X >}} | {{< X >}} | {{< X >}} | +| Script | {{< X >}} | {{< X >}} | {{< X >}} | +| HTTP | {{< X >}} | | {{< X >}} | +| GitLab | {{< X >}} | | {{< X >}} | +| Jenkins | {{< X >}} | | {{< X >}} | +| MongoDB | {{< X >}} | | {{< X >}} | +| PostgreSQL | | | {{< X >}} | +| Temporal | {{< X >}} | | {{< X >}} | + +- **Remote Action** es la familia de integraciones bajo el prefijo `com.datadoghq.remoteaction`. Incluye el paquete rshell, cuya acción `runCommand` ejecuta comandos de shell a través de una shell restringida. Consulte [Agent Restricted Shell (rshell)][8] +Las acciones - **Script** están limitadas a scripts *predefinidos* declarados en el `script-config.yaml` del ejecutor. Para configurar acciones de script (`runPredefinedScript` para Linux o `runPredefinedPowershellScript` para Windows), consulte [Ejecutar un script con un ejecutor de Private Actions][5]. + +{{% collapse-content title="Acciones disponibles por tipo de runner" level="h3" %}} + +{{< partial name="actions/private_actions_allowlist.html" >}} + +{{% /collapse-content %}} + +## Formatos de archivo de credenciales {#credential-file-formats} + +Algunas integraciones, como HTTP, Jenkins, PostgreSQL, MongoDB y Temporal, requieren credenciales para ejecutarse. Las credenciales se proporcionan al ejecutor como archivos JSON a los que usted hace referencia desde una [conexión][6]. Cada integración tiene su propia estructura de archivo de credenciales y métodos de autenticación admitidos. + +Para ver el conjunto completo de formatos de archivo de credenciales y ejemplos, consulte [Manejo de credenciales de Private Actions][7]. + +## Lecturas adicionales {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /es/actions/private_actions/ +[2]: https://github.com/DataDog/datadog-agent/blob/main/pkg/config/schema/yaml/private_action_runner.yaml +[3]: /es/actions/private_actions/enroll_runner/ +[4]: /es/actions/private_actions/execution_policies/ +[5]: /es/actions/private_actions/run_script/ +[6]: /es/actions/connections/ +[7]: /es/actions/connections/private_action_credentials/ +[8]: /es/agent/guide/rshell/ \ No newline at end of file diff --git a/hugo/content/es/actions/private_actions/run_script.md b/hugo/content/es/actions/private_actions/run_script.md new file mode 100644 index 00000000000..ffcd651a05e --- /dev/null +++ b/hugo/content/es/actions/private_actions/run_script.md @@ -0,0 +1,356 @@ +--- +description: Utilice el runner de acciones privadas para ejecutar scripts predefinidos + en su red privada, incluida la configuración necesaria para runners sin propietario + autorizados por la Directiva de ejecución. +further_reading: +- link: actions/private_actions/set_up_agent_based + tag: Documentación + text: Configure un runner de acciones privadas en el Agente de Datadog +- link: actions/private_actions/execution_policies + tag: Documentación + text: Políticas de ejecución +- link: actions/private_actions/reference + tag: Documentación + text: Referencia +title: Ejecutar un script con el runner de acciones privadas +--- +## Descripción general {#overview} + +El runner de acciones privadas puede ejecutar **scripts predefinidos**, que son comandos de shell, herramientas de línea de comandos y scripts que usted declara con antelación en un archivo de configuración de scripts. Solo se puede ejecutar lo que usted predefine, por lo que el runner nunca ejecuta comandos en línea arbitrarios desde un flujo de trabajo o aplicación. + +
Usted decide qué comandos y binarios tiene permitido ejecutar el runner. Revise cada comando que agregue a la configuración del script, especialmente aquellos que aceptan parámetros, otorgue al runner solo los privilegios que necesita y revise cuidadosamente los permisos que comparte a través de las conexiones. Consulte consideraciones de seguridad de la conexión.
+ +## Casos de uso {#use-cases} + +| Caso de uso | Basado en Agent | Independiente | Notas | +|---|:---:|:---:|---| +| Ejecución de binarios de Linux (`ls`, `rm`, `find`, `curl`) | {{< X >}} | {{< X >}} | Para runners independientes, los archivos relevantes deben ser accesibles para el contenedor. | +| Ejecución de CLI (`aws`, `terraform`, `kubectl`) | {{< X >}} | {{< X >}} | Para runners independientes, la CLI y las credenciales deben estar disponibles en la imagen. Para runners basados en Agent, las herramientas deben estar instaladas en el servidor. | +| Ejecución de scripts bash | {{< X >}} | {{< X >}} | Para runners independientes, los scripts pueden montarse dentro del contenedor. Utilice la [imagen grande](#large-image) para un intérprete de Python. | +| Ejecución de scripts de PowerShell | {{< X >}} | | Compatible solo con runners de Windows basados en el Agente. | +| Ejecución de comandos privilegiados (`systemctl restart`) | {{< X >}} | | Para runners basados en el Agente, otorgue permisos al usuario del runner. El sandboxing de contenedores evita que los runners independientes tengan acceso privilegiado al servidor. | + +## Requisitos previos {#prerequisites} + +**Para runners basados en el Agente:** +- Datadog Agent 7.81.0 o superior. Consulte [Configurar un runner de acciones privado en el Datadog Agent][1]. +- Agregue `com.datadoghq.script.runPredefinedScript` (Linux) o `com.datadoghq.script.runPredefinedPowershellScript` (Windows) a la lista de permitidos de acciones del runner. + +**Para runners independientes:** +- Un runner independiente. Consulte [Configurar un runner de acciones privado independiente][2]. +- Para herramientas de CLI no incluidas en la imagen base o [imagen grande](#large-image), una imagen de Docker personalizada. Consulte [Imágenes personalizadas](#custom-images). + +## Basado en Agent {#agent-based} + +### Configurar scripts {#configure-scripts} + +{{< tabs >}} +{{% tab "Linux" %}} + +Edite el archivo `/etc/datadog-agent/private-action-runner/script-config.yaml`: + +```yaml +schemaId: script-credentials-v1 +runPredefinedScript: + echo: + command: ["echo", "Hello world!"] + echo-parametrized: + command: ["echo", "{{ parameters.echoValue }}"] + restart-service: + command: ["sudo", "systemctl", "restart", "{{ parameters.service }}"] +``` + +{{% /tab %}} +{{% tab "Windows" %}} + +Edite el archivo `C:\ProgramData\Datadog\private-action-runner\powershell-script-config.yaml`: + +```yaml +schemaId: script-credentials-v1 +runPredefinedPowershellScript: + helloWorld: + script: | + Write-Output "Hello world!" + greet: + script: | + Write-Output "Run script from workflow called {{ parameters.name }} !" + parameterSchema: + properties: + name: + type: string + required: + - name + restartService: + script: | + Restart-Service -Name {{ parameters.serviceName }} -Force + parameterSchema: + properties: + serviceName: + type: string + required: + - serviceName +``` + +{{% /tab %}} +{{< /tabs >}} + +En un flujo de trabajo o aplicación, haga referencia a un script por el nombre que definió (por ejemplo, `echo`). Use `runPredefinedScript` en runners de Linux y `runPredefinedPowershellScript` en runners de Windows. + +### Otorgar permisos {#grant-permissions} + +{{< tabs >}} +{{% tab "Linux" %}} + +El runner ejecuta scripts como el usuario `dd-agent`. Si sus scripts requieren permisos elevados, otórguelos al usuario `dd-agent`: + +```bash +echo "dd-agent ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx" > /etc/sudoers.d/dd-agent +chmod 440 /etc/sudoers.d/dd-agent +``` + +{{% /tab %}} +{{% tab "Windows" %}} + +El runner ejecuta scripts como `ddagentuser`. Si sus scripts requieren acceso a ciertos recursos, otorgue a `ddagentuser` permisos elevados para ellos: + +```powershell +icacls "C:\" /grant "ddagentuser:(OI)(CI)RX" /T + +# Verify permissions +icacls "C:\" +``` + +{{% /tab %}} +{{< /tabs >}} + +### Runner sin propietario (Execution Policy-authorized) {#ownerless-runner-execution-policy-authorized} + +Cuando un runner se registra como sin propietario y es autorizado por [Políticas de ejecución][3], se requieren dos cosas además de los pasos anteriores: + +- La integración **Script** debe estar autorizada para el runner a través de una Política de ejecución, además de que la acción predefined-script esté en la lista de permitidos de acciones del runner. +- El runner lee sus scripts predefinidos desde una **ruta fija**, la misma ruta utilizada en [Configurar scripts](#configure-scripts) arriba: + +{{< tabs >}} +{{% tab "Linux" %}} + +`/etc/datadog-agent/private-action-runner/script-config.yaml` + +{{% /tab %}} +{{% tab "Windows" %}} + +`C:\ProgramData\Datadog\private-action-runner\powershell-script-config.yaml` + +{{% /tab %}} +{{< /tabs >}} + +#### Entrega de la configuración en Kubernetes {#delivering-the-config-on-kubernetes} + +En Kubernetes, proporcione el archivo de configuración de scripts al runner en el Datadog Agent como un ConfigMap. Móntelo en el contenedor del runner en la ruta fija. El runner del Cluster Agent utiliza la ruta de Linux anterior. + +Primero, cree un ConfigMap que contenga su configuración de scripts: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: par-script-config + namespace: datadog +data: + script-config.yaml: | + schemaId: script-credentials-v1 + runPredefinedScript: + echo: + command: ["echo", "Hello world!"] +``` + +Luego, en el recurso `DatadogAgent`, permita la acción predefined-script y monte el ConfigMap en el contenedor del runner en la ruta fija: + +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog + annotations: + agent.datadoghq.com/private-action-runner-enabled: "true" + agent.datadoghq.com/private-action-runner-configdata: | + private_action_runner: + enabled: true + api_key_only_enrollment: true + actions_allowlist: + - "com.datadoghq.script.runPredefinedScript" + - "com.datadoghq.kubernetes.*" + - "com.datadoghq.remoteaction.*" +spec: + override: + nodeAgent: + volumes: + - name: par-script-config + configMap: + name: par-script-config + containers: + private-action-runner: + volumeMounts: + - name: par-script-config + mountPath: /etc/datadog-agent/private-action-runner/script-config.yaml + subPath: script-config.yaml + readOnly: true +``` + +Finalmente, aplique el manifiesto: + +```bash +kubectl apply -f datadog-agent.yaml +``` + +### Runner con propietario (basado en conexión) {#owned-runner-connection-based} + +{{< tabs >}} +{{% tab "Linux" %}} + +#### Configurar la conexión {#configure-the-connection} + +Si seleccionó `com.datadoghq.script.runPredefinedScript` en la lista de permitidos de acciones del runner, ya debería tener una conexión **Script** vinculada a su runner. De lo contrario, cree una conexión y especifique `/etc/datadog-agent/private-action-runner/script-config.yaml` como la **ruta al archivo**. Para obtener más información, consulte [Handling private action credentials][4]. + +{{% /tab %}} +{{% tab "Windows" %}} + +#### Configurar la conexión {#configure-the-connection-1} + +Si seleccionó `com.datadoghq.script.runPredefinedPowershellScript` en la lista de permitidos de acciones del runner, ya debería tener una conexión **Script** vinculada a su runner. De lo contrario, cree una conexión y especifique `C:\ProgramData\Datadog\private-action-runner\powershell-script-config.yaml` como la **ruta al archivo**. Para obtener más información, consulte [Handling private action credentials][4]. + +{{% /tab %}} +{{< /tabs >}} + +## Independiente {#standalone} + +Un runner independiente siempre es propiedad de y está autorizado con [Conexiones][5]. + +{{< tabs >}} +{{% tab "Docker" %}} + +1. Después de [configurar un runner][2], navegue a **Conexiones**. +1. Haga clic en **Nueva conexión** y seleccione **Script**. +1. Ingrese un nombre de conexión y, en el menú desplegable **Runner de acción privada**, seleccione su runner. +1. Copie la plantilla del archivo de credenciales en el directorio de configuración de su runner con los comandos que desea ejecutar. +1. En **Ruta al archivo**, confirme que la ruta del archivo coincida con la ruta en el sistema de archivos de su runner (la predeterminada es suficiente en la mayoría de los casos). +1. Haga clic en **Siguiente, Confirmar acceso**, configure los permisos y luego haga clic en **Crear**. +1. Seleccione esta conexión al usar la acción de script en sus flujos de trabajo o aplicaciones. + +Configure las acciones de script a través del archivo `config.yaml` de su runner y la conexión de script +(`credentials/script.yaml` de forma predeterminada): + +```yaml +# Add the script action to the allowlist (config.yaml) +actionsAllowlist: + - com.datadoghq.script.runPredefinedScript +``` + +```yaml +# Configure your script connection (credentials/script.yaml) +schemaId: script-credentials-v1 +runPredefinedScript: + echo: + command: ["echo", "Hello world"] + echo-parametrized: + command: ["echo", "{{ parameters.echoValue }}"] + parameterSchema: + properties: + echoValue: + type: string + required: + - echoValue +``` + +{{% /tab %}} +{{% tab "Kubernetes (Helm)" %}} + +Al implementar el runner con Helm, configure los scripts a través de su archivo `values.yaml`: + +```yaml +common: + actionsAllowlist: + - com.datadoghq.script.runPredefinedScript + +credentials: + script: + schemaId: script-credentials-v1 + runPredefinedScript: + echo: + command: ["echo", "Hello world"] + echo-parametrized: + command: ["echo", "{{ parameters.echoValue }}"] + parameterSchema: + properties: + echoValue: + type: string + required: + - echoValue +``` + +Implemente o actualice el runner: + +```bash +helm upgrade --install datadog/private-action-runner -f ./values.yaml +``` + +{{% /tab %}} +{{< /tabs >}} + +### Opciones de imagen del runner {#runner-image-options} + +Las siguientes opciones están disponibles solo para runners independientes. + +#### Imagen grande {#large-image} + +Si desea utilizar herramientas como Python, SSH, la CLI de AWS, Terraform o la CLI de gcloud, utilice la imagen `gcr.io/datadoghq/private-action-runner:v`,translation_2:{{< private-action-runner-version "private-action-runner" >}}-large` en lugar de la imagen predeterminada. + +#### Imágenes personalizadas {#custom-images} + +Para binarios que no están disponibles en las imágenes proporcionadas por Datadog, cree una imagen personalizada: + +```dockerfile +FROM gcr.io/datadoghq/private-action-runner:v{{< private-action-runner-version "private-action-runner" >}} +USER root +# Change the line below to install the tool of your choice +RUN apt update && apt install -y python3 +USER dog +``` + +Puede montar scripts complejos dentro del runner: + +```yaml +# docker-compose example +services: + runner: + build: . # if you are using a local Dockerfile + volumes: + - "./config:/etc/dd-action-runner/config" # contains credentials for actions + - "./scripts:/etc/dd-action-runner-script/scripts" # contains dependencies for script actions +``` + +```yaml +# credentials/script.yaml +schemaId: script-credentials-v1 +runPredefinedScript: + python: + command: ["python3", "/etc/dd-action-runner-script/scripts/script.py"] + shell: + command: ["bash", "/etc/dd-action-runner-script/scripts/script.sh"] +``` + +## Uso de los scripts configurados {#using-the-configured-scripts} + +En su flujo de trabajo o aplicación, configure la acción para usar el nombre de script que definió (por ejemplo, `echo` o `echo-parametrized`). Para runners de Linux, use `runPredefinedScript`. Para runners de Windows, use `runPredefinedPowershellScript`. + +Existen dos niveles de resolución de variables: uno a nivel de flujo de trabajo y otro a nivel de acción +dentro del runner. + +## Lecturas adicionales {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /es/actions/private_actions/set_up_agent_based/ +[2]: /es/actions/private_actions/set_up_standalone/ +[3]: /es/actions/private_actions/execution_policies/ +[4]: /es/actions/connections/private_action_credentials/ +[5]: /es/actions/connections/ \ No newline at end of file diff --git a/hugo/content/es/actions/private_actions/set_up_agent_based.md b/hugo/content/es/actions/private_actions/set_up_agent_based.md new file mode 100644 index 00000000000..2cbaeab9d5b --- /dev/null +++ b/hugo/content/es/actions/private_actions/set_up_agent_based.md @@ -0,0 +1,445 @@ +--- +aliases: +- /es/service_management/workflows/private_actions/use_private_actions +- /es/service_management/app_builder/private_actions/use_private_actions +- /es/actions/private_actions/use_private_actions/ +- /es/actions/private_actions/update_private_action_runner/ +description: Instale, registre, administre y actualice un ejecutor de acciones privado + que se ejecuta dentro del Datadog Agent. +disable_toc: false +further_reading: +- link: actions/private_actions/ + tag: Documentación + text: Private Actions +- link: actions/private_actions/enroll_runner + tag: Documentación + text: Inscripción y propiedad +- link: actions/private_actions/execution_policies + tag: Documentación + text: Políticas de ejecución +- link: actions/private_actions/set_up_standalone + tag: Documentación + text: Configure un ejecutor de acciones privado independiente +title: Configure un ejecutor de acciones privado en el Datadog Agent +--- +## Descripción general {#overview} + +Ejecutar el ejecutor de acciones privado en el Datadog Agent es la ruta recomendada para nuevas implementaciones. Si ya ejecuta el Datadog Agent, habilite el ejecutor con una sola bandera de configuración y adminístrelo a través del ciclo de vida del Agent. + +La configuración del ejecutor requiere tres pasos: + +1. [**Instale**](#install-the-runner) el ejecutor, utilizando la opción de implementación que se ajuste a su entorno. +1. [**Inscriba**](#enroll-the-runner) el ejecutor, lo cual establece su propiedad y el modelo de autorización que utiliza. +1. [**Actualice**](#update-the-runner) el ejecutor como parte de las actualizaciones de su Agent. + +Para implementar el ejecutor como un binario independiente, consulte [Set up a standalone private action runner][1]. + +## Requisitos previos {#prerequisites} + +- Un servidor Linux o Windows con **Datadog Agent 7.81.0 o posterior**, o un clúster de Kubernetes con **Datadog Operator v1.28.0 o posterior** o el **Datadog Helm chart 3.231.6 o posterior**. +- [Remote Configuration][2] habilitada para su organización. +- Acceso de red a Datadog en `https://{{< region-param key=dd_site >}}`. + +## Instale el ejecutor {#install-the-runner} + +El ejecutor en el Datadog Agent tiene tres opciones de implementación, según dónde necesite actuar el ejecutor: + +| Opción de implementación | Cómo se ejecuta | Implementar con | Ideal para | +|---|---|---|---| +| **Servidor** | Un proceso independiente junto al Datadog Agent en un servidor Linux o Windows. | Instalación en servidor | Acciones dirigidas a un servidor específico. | +| **Un contenedor en el Agent de nodo, que utiliza el mismo binario de ejecución que el proceso del servidor.** | | Helm, Operator | Acciones locales al nodo en un clúster de Kubernetes. | +| **Kubernetes Cluster Agent** | En proceso dentro del Cluster Agent, sin un binario independiente. Un ejecutor sirve a todo el clúster. | Helm, Operator | Acciones de Kubernetes en todo el clúster. | + +Tiene la opción de instalar con **Fleet Automation**, un flujo basado en la interfaz de usuario que inscribe al ejecutor como propiedad, o **Instalación manual**, donde usted elige el tipo de inscripción. + +### Uso de Fleet Automation (recomendado) {#using-fleet-automation-recommended} + +El flujo de instalación de Fleet Automation es el mismo en todas las plataformas. + +1. Vaya a la [página de instalación de Fleet Automation][3] y seleccione su plataforma. Para Kubernetes, seleccione también **Helm Chart** o **Datadog Operator** como método de instalación, para que coincida con la pestaña de [Instalación manual](#manual-installation) que planea seguir. +1. En **Personalice la cobertura de su Agent**, vaya a la sección **Optimización y corrección** y active **Habilitar al Agent para realizar acciones**. Esto crea una clave de aplicación con el contexto `on_prem_runner_write` e inscribe al ejecutor como **propiedad**, autorizado con [Conexiones][4]. Para inscribir un ejecutor sin propietario, autorizado con [Políticas de ejecución][5], utilice la [Instalación manual](#manual-installation). +1. Siga las instrucciones restantes en el panel de instalación para agregar una clave de API y completar la instalación. +1. Después de la instalación, vaya a [Private Action Runners][6] para verificar que su ejecutor aparezca en la lista. + +### Instalación manual {#manual-installation} + +{{< tabs >}} +{{% tab "Linux" %}} +Establezca las siguientes variables de entorno cuando instale o ejecute el Agent. En el servidor, la configuración del ejecutor de acciones privadas utiliza el prefijo `DD_PRIVATE_ACTION_RUNNER_*`: + +```bash +DD_API_KEY= \ +DD_APP_KEY= \ +DD_SITE="{{< region-param key=dd_site >}}" \ +DD_PRIVATE_ACTION_RUNNER_ENABLED=true \ +DD_PRIVATE_ACTION_RUNNER_ACTIONS_ALLOWLIST=com.datadoghq.kubernetes.*,com.datadoghq.remoteaction.* \ +bash -c "$(curl -L https://install.datadoghq.com/scripts/install_script_agent7.sh)" +``` + +`DD_APP_KEY` inscribe al ejecutor como propiedad, igual que Fleet Automation. La clave de aplicación necesita el contexto `on_prem_runner_write`. `DD_PRIVATE_ACTION_RUNNER_ACTIONS_ALLOWLIST` acepta una lista separada por comas. Utilice comodines de bundle para permitir las acciones que puede ejecutar un ejecutor en el Datadog Agent: `com.datadoghq.kubernetes.*` y `com.datadoghq.remoteaction.*`. Para depender de las acciones predeterminadas integradas del ejecutor (acciones de Remote Action de solo lectura, además de un conjunto de acciones de Kubernetes de solo lectura en el Cluster Agent), deje la lista de permitidos sin configurar. + +Después de la instalación, vaya a [Private Action Runners][1] para verificar que su ejecutor aparezca en la lista. + +[1]: https://app.datadoghq.com/actions/action-catalog + +{{% /tab %}} +{{% tab "Windows" %}} + +Instale o actualice a Datadog Agent 7.81.0 o posterior, luego edite `C:\ProgramData\Datadog\datadog.yaml`: + +```yaml +app_key: + +private_action_runner: + enabled: true + self_enroll: true + actions_allowlist: + - "com.datadoghq.kubernetes.*" + - "com.datadoghq.remoteaction.*" +``` + +`app_key` inscribe al ejecutor como propiedad, igual que Fleet Automation anteriormente; la clave de aplicación necesita el contexto `on_prem_runner_write`. + +Reinicie el Agente para aplicar la configuración: + +```powershell +Restart-Service -Force datadogagent +``` + +Después de reiniciar el Agente, vaya a [Private Action Runners][1] para verificar que su ejecutor aparezca en la lista. + +El proceso del servidor ejecuta el ejecutor de **Agente de nodo**. Para ejecutar un ejecutor en el Agente de clúster, utilice la pestaña de Kubernetes (Helm) o Kubernetes (Operator). + +[1]: https://app.datadoghq.com/actions/action-catalog + +{{% /tab %}} +{{% tab "Kubernetes (Helm)" %}} + +El chart de Helm de Datadog puede habilitar el ejecutor en dos lugares: + +- El ejecutor de **Agente de nodo**, como contenedor sidecar. El ejecutor del Agente de nodo es **solo para Linux**. +- El ejecutor de **Agente de clúster**, en proceso. El ejecutor del Agente de clúster solo está disponible a través de Helm o del Operator (no existe un binario independiente) y requiere una elección de líder para que la identidad se coordine entre las réplicas del Agente de clúster. + +Cree una clave de API con la capacidad de Private Action Runner en [Organization Settings][1], luego guárdela en un secreto de Kubernetes que el chart lea a través de `apiKeyExistingSecret`: + +```bash +kubectl create secret generic datadog-secret \ + --from-literal api-key= +``` + +Este ejemplo inscribe al ejecutor como **sin propietario** (`apiKeyOnlyEnrollment: true`, usando solo la clave de API), lo cual lo autoriza con Execution Policies. Para otras opciones de inscripción y cómo funciona la propiedad, consulte [Enrollment and ownership][2]. + +La configuración de Helm utiliza la clave `privateActionRunner.*` en camelCase. Cree un `values.yaml`: + +```yaml +datadog: + apiKeyExistingSecret: datadog-secret + site: {{< region-param key=dd_site >}} + clusterName: + remoteConfiguration: + enabled: true + privateActionRunner: + enabled: true + apiKeyOnlyEnrollment: true + actionsAllowlist: + - "com.datadoghq.remoteaction.*" + - "com.datadoghq.script.*" +clusterAgent: + enabled: true + privateActionRunner: + enabled: true + apiKeyOnlyEnrollment: true + actionsAllowlist: + - "com.datadoghq.kubernetes.*" + - "com.datadoghq.script.*" +``` + +Para conocer todas las opciones de configuración del ejecutor disponibles, consulte [`datadog.privateActionRunner`][3] y [`clusterAgent.privateActionRunner`][4] en el chart de Helm. Instale el chart: + +```bash +helm repo add datadog https://helm.datadoghq.com +helm repo update +helm install datadog-agent datadog/datadog -f values.yaml +``` + +Después de la instalación, vaya a [Private Action Runners][5] para verificar que su ejecutor aparezca en la lista. + +[1]: https://app.datadoghq.com/organization-settings/api-keys +[2]: /es/actions/private_actions/enroll_runner/ +[3]: https://github.com/DataDog/helm-charts/blob/main/charts/datadog/values.yaml#L523 +[4]: https://github.com/DataDog/helm-charts/blob/main/charts/datadog/values.yaml#L1842 +[5]: https://app.datadoghq.com/actions/action-catalog + +{{% /tab %}} +{{% tab "Kubernetes (Operator)" %}} + +El Datadog Operator habilita el ejecutor a través de anotaciones en el recurso `DatadogAgent`. La configuración del ejecutor en la anotación `-configdata` utiliza la clave `private_action_runner.*` en snake_case. El Operator puede habilitar tanto el ejecutor del Agente de nodo como el ejecutor del Agente de clúster en proceso. + +Cree una clave de API con la capacidad de Private Action Runner en [Organization Settings][1], luego guárdela en un secreto de Kubernetes que el recurso `DatadogAgent` lea a través de su `credentials`: + +```bash +kubectl create secret generic datadog-secret \ + --from-literal api-key= +``` + +Este ejemplo inscribe al ejecutor como **sin propietario** (`api_key_only_enrollment: true`, usando solo la clave de API), lo cual lo autoriza con Execution Policies. Para otras opciones de inscripción y cómo funciona la propiedad, consulte [Enrollment and ownership][2]. + +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog + annotations: + agent.datadoghq.com/private-action-runner-enabled: "true" + agent.datadoghq.com/private-action-runner-configdata: | + private_action_runner: + enabled: true + api_key_only_enrollment: true + actions_allowlist: + - "com.datadoghq.remoteaction.*" + - "com.datadoghq.script.*" + cluster-agent.datadoghq.com/private-action-runner-enabled: "true" + cluster-agent.datadoghq.com/private-action-runner-configdata: | + private_action_runner: + enabled: true + api_key_only_enrollment: true + actions_allowlist: + - "com.datadoghq.kubernetes.*" + - "com.datadoghq.script.*" +spec: + global: + clusterName: + site: {{< region-param key=dd_site >}} + credentials: + apiSecret: + secretName: datadog-secret + keyName: api-key +``` + +Aplique el manifiesto: + +```bash +kubectl apply -f datadog-agent.yaml +``` + +Al igual que con Helm, el ejecutor del Cluster Agent requiere una elección de líder, y el ejecutor del Agente de nodo solo está disponible para Linux. Después de aplicar el manifiesto, vaya a [Private Action Runners][3] para verificar que su ejecutor aparezca en la lista. + +[1]: https://app.datadoghq.com/organization-settings/api-keys +[2]: /es/actions/private_actions/enroll_runner/ +[3]: https://app.datadoghq.com/actions/action-catalog + +{{% /tab %}} +{{< /tabs >}} + +### Nombres de los campos de configuración {#configuration-field-names} + +La configuración del ejecutor sigue las convenciones estándar de configuración del Datadog Agent para cada método de instalación: +- Variables de entorno en un servidor. +- Claves en CamelCase bajo `privateActionRunner` en Helm. +- Claves en snake_case bajo `private_action_runner` en el Operator. + +Para ver la tabla de equivalencias de nombres de campos en los tres métodos de instalación y la lista completa de claves de configuración y valores predeterminados, consulte la [referencia de private action runner][7]. + +## Inscribir al runner {#enroll-the-runner} + +La inscripción registra el runner en su organización de Datadog y establece su **propiedad**, lo que determina el modelo de autorización. Un runner sin propietario, inscrito con una clave de API que tiene la capacidad de Private Action Runner, utiliza [Execution Policies][5]. Un runner con propietario, inscrito con una clave de aplicación, utiliza [Connections][4]. Debido a que el modelo se fija al momento de la inscripción, decida cuál desea antes de implementar. + +Para obtener más información sobre el proceso, consulte [Enrollment and ownership][8]. + +## Administrar el runner {#manage-the-runner} + +### Cambiar la lista de permitidos {#change-the-allowlist} + +Para editar la lista de permitidos de un runner en el Datadog Agent: + +{{< tabs >}} +{{% tab "Linux" %}} +1. Edite la sección `private_action_runner.actions_allowlist` en `/etc/datadog-agent/datadog.yaml`. +1. Reinicie el Agent: `sudo systemctl restart datadog-agent`. +{{% /tab %}} +{{% tab "Windows" %}} +1. Edite la sección `private_action_runner.actions_allowlist` en `C:\ProgramData\Datadog\datadog.yaml`. +1. Reinicie el Agent: `Restart-Service -Force datadogagent`. +{{% /tab %}} +{{% tab "Kubernetes (Operator)" %}} +1. Actualice `actions_allowlist` en ambas anotaciones del manifiesto `DatadogAgent`: `agent.datadoghq.com/private-action-runner-configdata` y `cluster-agent.datadoghq.com/private-action-runner-configdata`. +1. Aplique el manifiesto actualizado: `kubectl apply -f datadog-agent.yaml`. +{{% /tab %}} +{{% tab "Kubernetes (Helm)" %}} +1. Actualice `privateActionRunner.actionsAllowlist` (node Agent) o `clusterAgent.privateActionRunner.actionsAllowlist` (Cluster Agent) en `values.yaml`. +1. Aplique el chart actualizado: `helm upgrade datadog-agent datadog/datadog -f values.yaml`. +{{% /tab %}} +{{< /tabs >}} + +### Eliminación automática de runners inactivos {#automatic-deletion-of-inactive-runners} + +Para liberar recursos no utilizados, Datadog elimina automáticamente los private action runners basados en node Agent que utilizan una configuración solo con clave de API (sin propietario) después de 35 días de inactividad. Esta limpieza automática no se aplica a los runners con propietario ni al runner del Cluster Agent. + +Si su runner se elimina debido a la inactividad, reiniciarlo resultará en un error. Debe volver a inscribir el runner repitiendo los pasos de instalación. + +## Depuración con logs {#debugging-with-logs} + +{{< tabs >}} +{{% tab "Linux" %}} + +```bash +cat /var/log/datadog/private-action-runner.log +``` + +{{% /tab %}} +{{% tab "Windows" %}} + +```powershell +Get-Content C:\ProgramData\Datadog\logs\private-action-runner.log +``` + +{{% /tab %}} +{{% tab "Kubernetes" %}} + +```bash +kubectl logs -l app.kubernetes.io/component=cluster-agent --tail=1000 | grep private +``` + +{{% /tab %}} +{{< /tabs >}} + +## Actualice el runner {#update-the-runner} + +Actualice el runner en el Datadog Agent para mantenerse al día con cualquier actualización del Agent. + +{{< tabs >}} +{{% tab "Linux" %}} + +Actualice el Datadog Agent a la versión más reciente. El runner viene incluido con el Agent. + +```bash +sudo apt-get update && sudo apt-get install datadog-agent +``` + +O para RHEL/CentOS: + +```bash +sudo yum update datadog-agent +``` + +Reinicie el Agent después de la actualización: + +```bash +sudo systemctl restart datadog-agent +``` + +Para obtener instrucciones detalladas de actualización, consulte [Upgrade to Agent v7][1]. + +[1]: /es/agent/versions/upgrade_to_agent_v7/ + +{{% /tab %}} +{{% tab "Windows" %}} + +Descargue el instalador MSI del Agent más reciente desde la [página de descarga del Datadog Agent][1] y ejecute el instalador, o utilice PowerShell: + +```powershell +# Download the latest installer +Invoke-WebRequest -Uri "https://s3.amazonaws.com/ddagent-windows-stable/ddagent-cli-latest.msi" -OutFile ddagent-cli-latest.msi + +# Run the installer +Start-Process -Wait -PassThru msiexec -ArgumentList '/qn /i ddagent-cli-latest.msi' +``` + +Reinicie el Agent después de la actualización: + +```powershell +Restart-Service -Force datadogagent +``` + +[1]: https://app.datadoghq.com/account/settings#agent/windows + +{{% /tab %}} +{{% tab "Kubernetes (Operator)" %}} + +Actualice las versiones de imagen del Datadog Operator y del Agent en su manifiesto `DatadogAgent`. + +1. Actualice el Datadog Operator: + + ```bash + helm repo update + helm upgrade datadog-operator datadog/datadog-operator \ + --set image.repository=registry.datadoghq.com/operator \ + --set image.tag=latest + ``` + + Puede fijar una versión específica. Para explorar las etiquetas disponibles, utilice [Docker Hub][1]. + +1. Actualice las versiones de imagen del Agent en su manifiesto `datadog-agent.yaml`: + + ```yaml + override: + nodeAgent: + image: + name: registry.datadoghq.com/agent: + clusterAgent: + image: + name: registry.datadoghq.com/cluster-agent: + ``` + +1. Aplique el manifiesto actualizado: `kubectl apply -f datadog-agent.yaml`. +1. Verifique la actualización: + + ```bash + kubectl get pods + kubectl logs -l app.kubernetes.io/component=cluster-agent --tail=100 | grep private + ``` + +El runner del Cluster Agent mantiene su identidad durante la actualización, ya que la almacena en un secreto de Kubernetes compartido. El runner del Agent de nodo almacena su identidad en un archivo: si esa ruta no está respaldada por un volumen persistente, una actualización puede borrar la identidad y obligar al runner a volver a inscribirse. Consulte [Identity storage on Kubernetes][2]. + +[1]: https://hub.docker.com/r/datadog/operator/tags +[2]: /es/actions/private_actions/enroll_runner/#identity-storage-on-kubernetes + +{{% /tab %}} +{{% tab "Kubernetes (Helm)" %}} + +La actualización del runner es parte del proceso estándar de actualización del chart de Helm del Datadog Agent. + +```bash +helm repo update +helm upgrade datadog-agent datadog/datadog -f values.yaml +``` + +Para obtener instrucciones detalladas sobre la actualización, consulte [Upgrading Datadog Helm][1]. + +[1]: https://github.com/DataDog/helm-charts/blob/main/charts/datadog/README.md#upgrading + +{{% /tab %}} +{{% tab "Terraform (Operator)" %}} + +Actualice las variables de versión en su configuración de Terraform: + +```hcl +locals { + helm_operator_version = "" + agent_version = "" + # ... +} +``` + +Aplique los cambios: + +```bash +terraform plan +terraform apply -var="datadog_api_key=" -var="datadog_app_key=" +``` + +{{% /tab %}} +{{< /tabs >}} + +## Lecturas adicionales {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /es/actions/private_actions/set_up_standalone/ +[2]: /es/remote_configuration +[3]: https://app.datadoghq.com/fleet/install-agent/latest +[4]: /es/actions/connections/ +[5]: /es/actions/private_actions/execution_policies/ +[6]: https://app.datadoghq.com/actions/action-catalog +[7]: /es/actions/private_actions/reference/ +[8]: /es/actions/private_actions/enroll_runner/ \ No newline at end of file diff --git a/hugo/content/es/agent/configuration/dual-shipping.md b/hugo/content/es/agent/configuration/dual-shipping.md index fde3f2a2b10..e2e64d14ab7 100644 --- a/hugo/content/es/agent/configuration/dual-shipping.md +++ b/hugo/content/es/agent/configuration/dual-shipping.md @@ -1,81 +1,91 @@ --- aliases: - /es/agent/guide/dual-shipping +description: Configure el Datadog Agent para enviar métricas, registros y trazas a + múltiples organizaciones de Datadog simultáneamente. further_reading: +- link: https://www.datadoghq.com/blog/ddot-gateway + tag: Blog + text: Centralice y gobierne su canalización de OpenTelemetry con el gateway DDOT - link: /agent/configuration/network/ tag: Guía text: Tráfico de red +- link: /observability_pipelines/ + tag: Documentación + text: Envíe registros a destinos externos con Observability Pipelines title: Envío doble --- -
-El envío doble puede afectar la facturación si estás enviando datos a múltiples organizaciones de Datadog. Para obtener más información sobre cómo afecta esta configuración, contacta con el equipo de asistencia de Datadog. +El envío doble puede afectar la facturación si está enviando datos a múltiples organizaciones de Datadog. Para obtener más información sobre el impacto de esta configuración, comuníquese con Soporte de Datadog.
-## Información general +## Descripción general {#overview} + +Esta guía proporciona ejemplos de configuraciones del Agent para el envío doble de diferentes tipos de datos (por ejemplo, APM, registros, métricas del Clúster Agent) a múltiples organizaciones y sitios de Datadog. Para obtener más información sobre los sitios de Datadog, consulte [Introducción a los sitios de Datadog][3]. -Si quieres enviar datos a más de un destino (p. ej., una segunda organización de Datadog u otra infraestructura interna) puedes configurar el Agent para que envíe datos a endpoints adicionales. Si deseas configurarlo para enviar distintos tipos de datos a varios endpoints o claves de API, utiliza las configuraciones que se indican a continuación. +**Nota**: Utilice [Observability Pipelines][1] si desea realizar un envío doble de registros o dividir el tráfico de registros entre diferentes proveedores de registro, almacenamientos en la nube o proveedores de SIEM. -Para ver una lista de destinos de tráfico de red, consulta [Network Traffic (tráfico de red)][1]. +Para obtener una lista completa de los destinos del tráfico de red, consulte [Tráfico de red][2]. -## Métricas y checks de servicio +## Métricas y comprobaciones de servicio {#metrics-and-service-checks} -Puedes añadir la configuración YAML a tu `datadog.yaml` o iniciar el Agent con las variables de entorno adecuadas. +Puede agregar la configuración YAML a su `datadog.yaml` o iniciar el Agent con las variables de entorno adecuadas. -### Configuración YAML +### Configuración YAML {#yaml-configuration} -Es necesaria la versión 6.17 o 7.17 del Agent o una posterior. +Requiere la versión del Agent >= 6.17 o 7.17. En `datadog.yaml`: ```yaml additional_endpoints: - "https://app.datadoghq.com": + "https://app.{{< region-param key="dd_site">}}": - apikey2 - apikey3 - "https://app.datadoghq.eu": + "https://app.": # Replace with your Datadog site parameter (for example, datadoghq.eu). - apikey4 ``` -### Configuración de la variable de entorno +### Configuración de variables de entorno {#environment-variable-configuration} -Es necesaria la versión 6.18 o 7.18 del Agent o una posterior. +Requiere la versión del Agent >= 6.18 o 7.18. ```bash -DD_ADDITIONAL_ENDPOINTS='{\"https://app.datadoghq.com\": [\"apikey2\", \"apikey3\"], \"https://app.datadoghq.eu\": [\"apikey4\"]}' +DD_ADDITIONAL_ENDPOINTS='{\"https://app.{{< region-param key="dd_site">}}\": [\"apikey2\", \"apikey3\"], \"https://app.\": [\"apikey4\"]}' # Replace with your Datadog site parameter (for example, datadoghq.eu). ``` -## APM +## APM {#apm} -### Configuración YAML +### Configuración YAML {#yaml-configuration-1} -Es necesaria la versión 6.7.0 del Agent o una posterior. +Requiere la versión del Agent >= 6.7.0. En `datadog.yaml`: + ```yaml apm_config: [...] additional_endpoints: - "https://trace.agent.datadoghq.com": + "https://trace.agent.{{< region-param key="dd_site">}}": - apikey2 - apikey3 - "https://trace.agent.datadoghq.eu": + "https://trace.agent.": # Replace with your Datadog site parameter (for example, datadoghq.eu). - apikey4 ``` -### Configuración de la variable de entorno +### Configuración de variables de entorno {#environment-variable-configuration-1} -Es necesaria la versión 6.19 o 7.19 del Agent o una posterior. +Requiere la versión del Agent >= 6.19 o 7.19. ```bash -DD_APM_ADDITIONAL_ENDPOINTS='{\"https://trace.agent.datadoghq.com\": [\"apikey2\", \"apikey3\"], \"https://trace.agent.datadoghq.eu\": [\"apikey4\"]}' +DD_APM_ADDITIONAL_ENDPOINTS='{\"https://trace.agent.{{< region-param key="dd_site">}}\": [\"apikey2\", \"apikey3\"], \"https://trace.agent.\": [\"apikey4\"]}' # Replace with your Datadog site parameter (for example, datadoghq.eu). ``` -## Continuous Profiler +## Continuous Profiler {#continuous-profiler} -### Configuración YAML +### Configuración YAML {#yaml-configuration-2} -Es necesaria la versión 6.7.0 del Agent o una posterior. +Requiere la versión del Agent >= 6.7.0. En `datadog.yaml`: @@ -83,303 +93,341 @@ En `datadog.yaml`: apm_config: [...] profiling_additional_endpoints: - "https://intake.profile.datadoghq.com/api/v2/profile": + "https://intake.profile.{{< region-param key="dd_site">}}/api/v2/profile": - apikey2 - apikey3 - "https://intake.profile.datadoghq.eu/api/v2/profile": + "https://intake.profile./api/v2/profile": # Replace "" with your Datadog site parameter (for example, datadoghq.eu). - apikey4 ``` -### Configuración de la variable de entorno +### Configuración de variables de entorno {#environment-variable-configuration-2} -Es necesaria la versión 6.19 o 7.19 del Agent o una posterior. +Requiere la versión del Agent >= 6.19 o 7.19. ```bash -DD_APM_PROFILING_ADDITIONAL_ENDPOINTS='{\"https://intake.profile.datadoghq.com/api/v2/profile\": [\"apikey2\", \"apikey3\"], \"https://intake.profile.datadoghq.eu/api/v2/profile\": [\"apikey4\"]}' +DD_APM_PROFILING_ADDITIONAL_ENDPOINTS='{\"https://intake.profile.{{< region-param key="dd_site">}}/api/v2/profile\": [\"apikey2\", \"apikey3\"], \"https://intake.profile./api/v2/profile\": [\"apikey4\"]}' # Replace with your Datadog site parameter (for example, datadoghq.eu). ``` -**Nota:** Las cargas a endpoints adicionales para el producto Continuous Profiler se realizan mediante el servicio de entrega con el mejor esfuerzo posible. -* El endpoint principal tiene la máxima prioridad. Las cargas a endpoints adicionales solo se gestionan después de que se hayan completado con éxito las cargas al endpoint principal. -* Las respuestas de endpoints adicionales no se reenvían de vuelta al generador de perfiles. Los errores que se producen durante la entrega a endpoints adicionales se registran en los logs de errores del Agent. +**Nota:** Las cargas a puntos de conexión adicionales para el producto Continuous Profiler se realizan mediante entrega de mejor esfuerzo. +* El punto de conexión principal tiene la prioridad más alta. Las cargas a puntos de conexión adicionales solo se gestionan después de que las cargas al punto de conexión principal se hayan completado correctamente. +* Las respuestas de los puntos de conexión adicionales no se reenvían al profiler. Cualquier error durante la entrega a puntos de conexión adicionales se registra en los registros de errores del Agente. -## Live Processes +## Live Processes {#live-processes} -### Configuración YAML +### Configuración YAML {#yaml-configuration-3} -Es necesaria la versión 6.4.0 del Agent o una posterior. +Requiere la versión del Agent >= 6.4.0. En `datadog.yaml`: + ```yaml process_config: [...] additional_endpoints: - "https://process.datadoghq.com": + "https://process.{{< region-param key="dd_site">}}": - apikey2 - apikey3 - "https://process.datadoghq.eu": + "https://process.": # Replace with your Datadog site parameter (for example, datadoghq.eu). - apikey4 ``` -### Configuración de la variable de entorno +### Configuración de variables de entorno {#environment-variable-configuration-3} -Es necesaria la versión 6.20 o 7.20 del Agent o una posterior. +Requiere la versión del Agente >= 6.20 o 7.20. ```bash -DD_PROCESS_ADDITIONAL_ENDPOINTS='{\"https://process.datadoghq.com\": [\"apikey2\", \"apikey3\"], \"https://process.datadoghq.eu\": [\"apikey4\"]}' +DD_PROCESS_ADDITIONAL_ENDPOINTS='{\"https://process.{{< region-param key="dd_site">}}\": [\"apikey2\", \"apikey3\"], \"https://process.\": [\"apikey4\"]}' # Replace with your Datadog site parameter (for example, datadoghq.eu). ``` -## Métricas de Cluster Agent +## Métricas del Cluster Agent {#cluster-agent-metrics} -Configurar el Agent para enviar métricas de Cluster Agent, como Centro de métricas de estado de Kubernetes, a endpoints adicionales. +Configure el Agent para enviar métricas del Cluster Agent, como Kubernetes State Metrics Core, a puntos de conexión adicionales. + +### Configuración de HELM {#helm-configuration} +En Datadog `values.yaml`: -### Configuración de HELM -En `valores.yaml` de Datadog: ```yaml clusterAgent: env: - name: DD_ADDITIONAL_ENDPOINTS - value: '{"https://app.datadoghq.com": ["apikey2"]}' + value: '{"https://app.{{< region-param key="dd_site">}}": ["apikey2"]}' ``` -### Proveedor de métricas de Cluster Agent +### Proveedor de métricas del Cluster Agent {#cluster-agent-metrics-provider} -Para asegurar que el autoescalado es resistente a fallos, configura el Cluster Agent para ejecutar tus consultas de métricas para el HPA contra tus múltiples regiones de Datadog con datos de doble envío. Configura el manifiesto de Cluster Agent de Datadog con varios endpoints: +Para garantizar que el escalado automático sea resistente a fallos, configure el Cluster Agent para ejecutar sus consultas de métricas para el HPA en sus múltiples regiones de Datadog con datos enviados por duplicado. Configure el manifiesto del Datadog Cluster Agent con varios puntos de conexión: {{< code-block lang="yaml" filename="cluster-agent-deployment.yaml" collapsible="true" >}} external_metrics_provider: endpoints: - api_key: app_key: - url: https://app.datadoghq.eu + url: https://app. - api_key: app_key: - url: https://app.datadoghq.com + url: https://app. {{< /code-block >}} -## Orquestador +## Orchestrator {#orchestrator} + +### Configuración de HELM {#helm-configuration-1} +En Datadog `values.yaml`: -### Configuración de HELM -En `valores.yaml` de Datadog: ```yaml agents: customAgentConfig: process_config: additional_endpoints: - "https://process.datadoghq.com": + "https://process.{{< region-param key="dd_site">}}": - apikey2 orchestrator_explorer: orchestrator_additional_endpoints: - "https://orchestrator.datadoghq.com": - - apikey2 + "https://orchestrator.{{< region-param key="dd_site">}}": + - apikey3 clusterAgent: ... datadog_cluster_yaml: orchestrator_explorer: orchestrator_additional_endpoints: - "https://orchestrator.ddog-gov.com": - - apikey2 + "https://orchestrator.": # Replace with your Datadog site parameter (for example, ddog-gov.com). + - apikey4 ``` - -### Configuración de la variable de entorno +### Configuración de variables de entorno {#environment-variable-configuration-4} ```bash -DD_ORCHESTRATOR_EXPLORER_ORCHESTRATOR_ADDITIONAL_ENDPOINTS='{\"https://orchestrator.datadoghq.com\": [\"apikey2\", \"apikey3\"], \"https://orchestrator.datadoghq.eu\": [\"apikey4\"]}' +DD_ORCHESTRATOR_EXPLORER_ORCHESTRATOR_ADDITIONAL_ENDPOINTS='{\"https://orchestrator.{{< region-param key="dd_site">}}\": [\"apikey2\", \"apikey3\"], \"https://orchestrator.\": [\"apikey4\"]}' # Replace with your Datadog site parameter (for example, ddog-gov.com). ``` -## CI Visibility +## CI Visibility {#ci-visibility} -### Configuración YAML +### Configuración YAML {#yaml-configuration-4} -Es necesaria la versión 6.38 o 7.38 del Agent o una posterior. +Requiere el Agent >= 6.38 o 7.38. En `datadog.yaml`: + ```yaml evp_proxy_config: [...] additional_endpoints: - "https://-app.agent.datadoghq.com": + "https://-app.agent.{{< region-param key="dd_site">}}": - apikey2 - apikey3 - "https://-app.agent.datadoghq.eu": + "https://-app.agent.": # Replace and with your Agent version and Datadog site parameter (for example, 7-38-0 and datadoghq.eu). - apikey4 ``` -### Configuración de la variable de entorno +### Configuración de variables de entorno {#environment-variable-configuration-5} ```bash -DD_EVP_PROXY_CONFIG_ADDITIONAL_ENDPOINTS='{\"https://-app.agent.datadoghq.com\": [\"apikey2\", \"apikey3\"], \"https://-app.agent.datadoghq.eu\": [\"apikey4\"]}' +DD_EVP_PROXY_CONFIG_ADDITIONAL_ENDPOINTS='{\"https://-app.agent.{{< region-param key="dd_site">}}\": [\"apikey2\", \"apikey3\"], \"https://-app.agent.\": [\"apikey4\"]}' # Replace and with your Agent version and Datadog site parameter (for example, 7-38-0 and datadoghq.eu). ``` -## Logs +## Logs {#logs} + +Utilice el Agent si desea enviar registros mediante envío doble a varias organizaciones de Datadog. Utilice [Observability Pipelines][2] si desea enviar registros a Datadog y a destinos externos. -TCP necesita la versión 6.6 del Agent o una posterior.
-HTTPS necesita la versión 6.13 del Agent o una posterior. +TCP requiere la versión del Agent >= 6.6.
+HTTPS requiere la versión del Agent >= 6.13. -### Configuración YAML +### Configuración YAML {#yaml-configuration-5} En `datadog.yaml`: + ```yaml logs_config: - use_http: true + force_use_http: true additional_endpoints: - api_key: "apiKey2" - Host: "agent-http-intake.logs.datadoghq.com" + Host: "agent-http-intake.logs.{{< region-param key="dd_site">}}" Port: 443 is_reliable: true ``` -### Configuración de la variable de entorno +### Configuración de variables de entorno {#environment-variable-configuration-6} -Es necesaria la versión 6.18 o 7.18 del Agent o una posterior. +Requiere el Agent >= 6.18 o 7.18. ```bash -DD_LOGS_CONFIG_USE_HTTP=true -DD_LOGS_CONFIG_ADDITIONAL_ENDPOINTS="[{\"api_key\": \"apiKey2\", \"Host\": \"agent-http-intake.logs.datadoghq.com\", \"Port\": 443, \"is_reliable\": true}]" +DD_LOGS_CONFIG_FORCE_USE_HTTP=true +DD_LOGS_CONFIG_ADDITIONAL_ENDPOINTS="[{\"api_key\": \"apiKey2\", \"Host\": \"agent-http-intake.logs.{{< region-param key="dd_site">}}\", \"Port\": 443, \"is_reliable\": true}]" ``` {{% agent-dual-shipping %}} -## Monitorización de base de datos +## Database Monitoring {#database-monitoring} -### Configuración YAML +### Configuración YAML {#yaml-configuration-6} -Es necesaria la versión 6.29 o 7.29 del Agent o una posterior. +Requiere el Agent >= 6.29 o 7.29. En `datadog.yaml`: + ```yaml database_monitoring: samples: - use_http: true + force_use_http: true additional_endpoints: - api_key: "apiKey2" - Host: "dbm-metrics-intake.datadoghq.com" + Host: "dbm-metrics-intake.{{< region-param key="dd_site">}}" Port: 443 is_reliable: true activity: - use_http: true + force_use_http: true additional_endpoints: - api_key: "apiKey2" - Host: "dbquery-intake.datadoghq.com" + Host: "dbquery-intake.{{< region-param key="dd_site">}}" Port: 443 is_reliable: true metrics: - use_http: true + force_use_http: true additional_endpoints: - api_key: "apiKey2" - Host: "dbm-metrics-intake.datadoghq.com" + Host: "dbm-metrics-intake.{{< region-param key="dd_site">}}" Port: 443 is_reliable: true ``` -### Configuración de la variable de entorno +### Configuración de variables de entorno {#environment-variable-configuration-7} ```bash DD_DATABASE_MONITORING_SAMPLES_USE_HTTP=true -DD_DATABASE_MONITORING_SAMPLES_ADDITIONAL_ENDPOINTS="[{\"api_key\": \"apiKey2\", \"Host\": \"dbm-metrics-intake.datadoghq.com\", \"Port\": 443, \"is_reliable\": true}]" +DD_DATABASE_MONITORING_SAMPLES_ADDITIONAL_ENDPOINTS="[{\"api_key\": \"apiKey2\", \"Host\": \"dbm-metrics-intake.{{< region-param key="dd_site">}}\", \"Port\": 443, \"is_reliable\": true}]" DD_DATABASE_MONITORING_ACTIVITY_USE_HTTP=true -DD_DATABASE_MONITORING_ACTIVITY_ADDITIONAL_ENDPOINTS="[{\"api_key\": \"apiKey2\", \"Host\": \"dbquery-intake.datadoghq.com\", \"Port\": 443, \"is_reliable\": true}]" +DD_DATABASE_MONITORING_ACTIVITY_ADDITIONAL_ENDPOINTS="[{\"api_key\": \"apiKey2\", \"Host\": \"dbquery-intake.{{< region-param key="dd_site">}}\", \"Port\": 443, \"is_reliable\": true}]" DD_DATABASE_MONITORING_METRICS_USE_HTTP=true -DD_DATABASE_MONITORING_METRICS_ADDITIONAL_ENDPOINTS="[{\"api_key\": \"apiKey2\", \"Host\": \"dbm-metrics-intake.datadoghq.com\", \"Port\": 443, \"is_reliable\": true}]" +DD_DATABASE_MONITORING_METRICS_ADDITIONAL_ENDPOINTS="[{\"api_key\": \"apiKey2\", \"Host\": \"dbm-metrics-intake.{{< region-param key="dd_site">}}\", \"Port\": 443, \"is_reliable\": true}]" ``` {{% agent-dual-shipping %}} -## Dispositivos de red +## Network Devices {#network-devices} -### Configuración YAML +### Configuración YAML {#yaml-configuration-7} -Es necesaria la versión 6.29 o 7.29 del Agent o una posterior. +Requiere el Agent >= 6.29 o 7.29. En `datadog.yaml`: + ```yaml network_devices: metadata: - use_http: true + force_use_http: true additional_endpoints: - api_key: "apiKey2" - Host: "ndm-intake.datadoghq.com" + Host: "ndm-intake.{{< region-param key="dd_site">}}" Port: 443 is_reliable: true snmp_traps: forwarder: - use_http: true + force_use_http: true additional_endpoints: - api_key: "apiKey2" - Host: "ndm-intake.datadoghq.com" + Host: "ndm-intake.{{< region-param key="dd_site">}}" Port: 443 is_reliable: true netflow: forwarder: - use_http: true + force_use_http: true additional_endpoints: - api_key: "apiKey2" - Host: "ndm-intake.datadoghq.com" + Host: "ndm-intake.{{< region-param key="dd_site">}}" Port: 443 is_reliable: true ``` -### Configuración de la variable de entorno +### Configuración de variables de entorno {#environment-variable-configuration-8} ```bash DD_NETWORK_DEVICES_METADATA_USE_HTTP=true -DD_NETWORK_DEVICES_METADATA_ADDITIONAL_ENDPOINTS="[{\"api_key\": \"apiKey2\", \"Host\": \"ndm-intake.datadoghq.com\", \"Port\": 443, \"is_reliable\": true}]" +DD_NETWORK_DEVICES_METADATA_ADDITIONAL_ENDPOINTS="[{\"api_key\": \"apiKey2\", \"Host\": \"ndm-intake.{{< region-param key="dd_site">}}\", \"Port\": 443, \"is_reliable\": true}]" ``` {{% agent-dual-shipping %}} -## Errores en la gestión de la seguridad en la nube +## Network Path {#network-path} -### Configuración YAML +### Configuración YAML {#yaml-configuration-8} + +Requiere Agent >= 6.55 o 7.55. En `datadog.yaml`: + ```yaml -compliance_config: - endpoints: +network_path: + forwarder: use_http: true additional_endpoints: - api_key: "apiKey2" - Host: "https://-app.agent.datadoghq.eu" + Host: "netpath-intake.{{< region-param key="dd_site">}}" Port: 443 is_reliable: true ``` -### Configuración de la variable de entorno +### Configuración de variables de entorno {#environment-variable-configuration-9} + +```bash +DD_NETWORK_PATH_FORWARDER_USE_HTTP=true +DD_NETWORK_PATH_FORWARDER_ADDITIONAL_ENDPOINTS="[{\"api_key\": \"apiKey2\", \"Host\": \"netpath-intake.{{< region-param key="dd_site">}}\", \"Port\": 443, \"is_reliable\": true}]" +``` + +{{% agent-dual-shipping %}} + +## Cloud Security Misconfigurations {#cloud-security-misconfigurations} + +### Configuración YAML {#yaml-configuration-9} + +En `datadog.yaml`: + +```yaml +compliance_config: + endpoints: + force_use_http: true + additional_endpoints: + - api_key: "apiKey2" + host: "cspm-intake.{{< region-param key="dd_site">}}.:443" + is_reliable: true +``` + +### Configuración de variables de entorno {#environment-variable-configuration-10} ```bash DD_COMPLIANCE_CONFIG_ENDPOINTS_USE_HTTP=true -DD_COMPLIANCE_CONFIG_ENDPOINTS_ADDITIONAL_ENDPOINTS="[{\"api_key\": \"apiKey2\", \"Host\": \"https://-app.agent.datadoghq.eu\", \"Port\": 443, \"is_reliable\": true}]" +DD_COMPLIANCE_CONFIG_ENDPOINTS_ADDITIONAL_ENDPOINTS="[{\"api_key\": \"apiKey2\", \"host\": \"cspm-intake.{{< region-param key="dd_site">}}.:443\", \"is_reliable\": true}]" ``` {{% agent-dual-shipping %}} -## Amenazas para la gestión de la seguridad en la nube +## Workload Protection {#workload-protection} -### Configuración YAML +### Configuración YAML {#yaml-configuration-10} En `datadog.yaml`: + ```yaml runtime_security_config: endpoints: - use_http: true + force_use_http: true additional_endpoints: - api_key: "apiKey2" - Host: "https://-app.agent.datadoghq.eu" - Port: 443 + host: "cws-intake.{{< region-param key="dd_site">}}.:443" is_reliable: true ``` -### Configuración de la variable de entorno +### Configuración de variables de entorno {#environment-variable-configuration-11} ```bash DD_RUNTIME_SECURITY_CONFIG_ENDPOINTS_USE_HTTP=true -DD_RUNTIME_SECURITY_CONFIG_ENDPOINTS_ADDITIONAL_ENDPOINTS="[{\"api_key\": \"apiKey2\", \"Host\": \"https://-app.agent.datadoghq.eu\", \"Port\": 443, \"is_reliable\": true}]" +DD_RUNTIME_SECURITY_CONFIG_ENDPOINTS_ADDITIONAL_ENDPOINTS="[{\"api_key\": \"apiKey2\", \"host\": \"cws-intake.{{< region-param key="dd_site">}}.:443\", \"is_reliable\": true}]" ``` {{% agent-dual-shipping %}} -## Envío doble en Kubernetes +## Envío doble en Kubernetes {#dual-shipping-in-kubernetes} -Si estás utilizando el [Datadog Agent Helm chart][2], debes configurar estos ajustes con un configmap. En `valores.yaml`, configura `useConfigMap: verdadero` -y añade los ajustes pertinentes a `customAgentConfig`. +{{< tabs >}} {{% tab "Helm" %}} + +Si utiliza el [Datadog Agent Helm chart][1], puede configurar estos ajustes con un configmap. En `values.yaml`, establezca `useConfigMap: true` +y agregue la configuración relevante a `customAgentConfig`. ```yaml # agents.useConfigMap -- Configures a configmap to provide the agent configuration. Use this in combination with the `agents.customAgentConfig` parameter. @@ -387,33 +435,111 @@ y añade los ajustes pertinentes a `customAgentConfig`. # agents.customAgentConfig -- Specify custom contents for the datadog agent config (datadog.yaml) ## ref: https://docs.datadoghq.com/agent/configuration/agent-configuration-files/?tab=agentv6 - ## ref: https://github.com/DataDog/datadog-agent/blob/main/pkg/config/config_template.yaml + ## ref: https://github.com/DataDog/datadog-agent/tree/main/pkg/config/example ## Note the `agents.useConfigMap` needs to be set to `true` for this parameter to be taken into account. customAgentConfig: additional_endpoints: - "https://app.datadoghq.com": + "https://app.": # Replace with your Datadog site parameter (for example, datadoghq.com). - apikey2 - apikey3 - "https://app.datadoghq.eu": + "https://app.": # Replace with your Datadog site parameter (for example, datadoghq.eu). - apikey4 logs_config: - use_http: true + force_use_http: true additional_endpoints: - api_key: "apiKey2" - Host: "{{< region-param key=agent_http_endpoint >}}" + Host: "agent-http-intake.logs." # Replace with your Datadog site parameter (for example, datadoghq.com). Port: 443 is_reliable: true ``` -Si utilizas el [Datadog Agent operator (operador de Datadog Agent)][3], también puedes configurar la tecla `agent.customConfig.configData`. Todas las claves configurables están documentadas en [v1][4] y [v2][5]. +Para evitar exponer su(s) clave(s) de API en texto plano dentro del `ConfigMap`, también puede utilizar la configuración de variables de entorno y hacer referencia a un secreto de Kubernetes. Aquí tiene un ejemplo para enviar métricas a una región adicional: + +1. Cree un secreto de Kubernetes con el valor de configuración de su variable de entorno de esta guía: + ```bash + kubectl create -n secret generic dual-shipping --from-literal metrics='{"https://app.": ["apikey4"]}' # Replace with your Datadog site parameter (for example, datadoghq.eu). + ``` +2. Utilice los [parámetros del Helm chart][2] `datadog.env` o `datadog.envFrom` para hacer referencia a este secreto en su configuración: + ```yaml + datadog: + [...] + env: + - name: DD_ADDITIONAL_ENDPOINTS + valueFrom: + secretKeyRef: + name: dual-shipping + key: metrics + ``` + +[1]: https://github.com/DataDog/helm-charts +[2]: https://github.com/DataDog/helm-charts/blob/e1ec85127de74c8b876eef6a81bb1579d17b49bf/charts/datadog/values.yaml#L563-L578 + +{{% /tab %}} + +{{% tab "Datadog Operator" %}} + +Si está utilizando el [operador de Datadog Agent][1], puede establecer la clave `[key].customConfigurations.[key].configData` [override][2] para configurar estos ajustes. El siguiente ejemplo reemplaza el archivo de configuración `datadog.yaml` del node Agent para enviar métricas y registros a regiones adicionales. + +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + override: + nodeAgent: + customConfigurations: + datadog.yaml: + ## Replace with your Datadog site parameter (for example, datadoghq.com (US1) for `apikey2` and `apikey3`, and datadoghq.eu (EU) for `apikey4`). + configData: |- + additional_endpoints: + "https://app.": + - apikey2 + - apikey3 + "https://app.": + - apikey4 + logs_config: + force_use_http: true + additional_endpoints: + - api_key: "apiKey2" + Host: "agent-http-intake.logs." + Port: 443 + is_reliable: true +``` -## Leer más +Para evitar exponer su(s) clave(s) de API en texto plano dentro del `ConfigMap`, también puede utilizar la configuración de variables de entorno y hacer referencia a un secreto de Kubernetes. Aquí tiene un ejemplo para enviar métricas a una región adicional: + +1. Cree un secreto de Kubernetes con el valor de configuración de su variable de entorno de esta guía: + ```bash + kubectl create -n secret generic dual-shipping --from-literal metrics='{"https://app.": ["apikey4"]}' # Replace with your Datadog site parameter (for example, datadoghq.eu). + ``` +2. Utilice el parámetro `[key].env` para hacer referencia a este secreto en su configuración: + ```yaml + apiVersion: datadoghq.com/v2alpha1 + kind: DatadogAgent + metadata: + name: datadog + spec: + override: + nodeAgent: + env: + - name: DD_ADDITIONAL_ENDPOINTS + valueFrom: + secretKeyRef: + name: dual-shipping + key: metrics + ``` + +[1]: https://github.com/DataDog/datadog-operator +[2]: https://github.com/DataDog/datadog-operator/blob/main/docs/configuration.v2alpha1.md + +{{% /tab %}} {{< /tabs >}} + +## Lecturas adicionales {#further-reading} {{< partial name="whats-next/whats-next.html" >}} -[1]: /es/agent/configuration/network/ -[2]: https://github.com/DataDog/helm-charts -[3]: https://github.com/DataDog/datadog-operator -[4]: https://github.com/DataDog/datadog-operator/blob/main/docs/configuration.v1alpha1.md -[5]: https://github.com/DataDog/datadog-operator/blob/main/docs/configuration.v2alpha1.md \ No newline at end of file +[1]: /es/observability_pipelines/ +[2]: /es/agent/configuration/network/ +[3]: /es/getting_started/site/#access-the-datadog-site \ No newline at end of file diff --git a/hugo/content/es/agent/logs/_index.md b/hugo/content/es/agent/logs/_index.md index c0bcee3850c..222437fef7d 100644 --- a/hugo/content/es/agent/logs/_index.md +++ b/hugo/content/es/agent/logs/_index.md @@ -1,36 +1,36 @@ --- -description: Utiliza el Agente de Datadog para recopilar tus registros y enviarlos - a Datadog +description: Utilice el Datadog Agent para recopilar sus registros y enviarlos a Datadog further_reading: - link: agent/logs/agent_tags/ tag: Documentación - text: Etiquetas del agente añadidas automáticamente a los registros + text: Etiquetas del Agent añadidas automáticamente a los registros - link: agent/logs/advanced_log_collection/#filter-logs tag: Documentación - text: Filtrar registros enviados a Datadog + text: Filtrar los registros enviados a Datadog - link: agent/logs/advanced_log_collection/#scrub-sensitive-data-from-your-logs tag: Documentación - text: Eliminar datos sensibles de tus registros + text: Eliminar datos confidenciales de sus registros - link: agent/logs/advanced_log_collection/#multi-line-aggregation tag: Documentación - text: Agregación de registros de múltiples líneas + text: Agregación de registros multilínea - link: agent/logs/advanced_log_collection/#tail-directories-using-wildcards tag: Documentación - text: Realiza el seguimiento de directorios utilizando comodines + text: Realice el seguimiento de las últimas líneas en directorios mediante el uso + de comodines. - link: agent/logs/advanced_log_collection/#global-processing-rules tag: Documentación - text: Reglas de procesamiento globales -title: Recopilación de registros del Agente del servidor + text: Reglas de procesamiento global +title: Recopilación de registros del Agent de host --- -La recopilación de registros requiere el Agente de Datadog v6.0 o superior. Las versiones anteriores del Agente no incluyen la interfaz `log collection`. Si aún no utilizas el Agente, sigue las [instrucciones de instalación del Agente][1]. +La recopilación de registros requiere Datadog Agent v6.0+. Las versiones anteriores del Agent no incluyen la interfaz `log collection`. Si aún no utiliza el Agent, siga las [instrucciones de instalación del Agent][1]. -Consulta [Pipelines de Observabilidad][2] si deseas enviar registros utilizando el colector o reenvío de otro proveedor, o si deseas preprocesar tus datos de registro dentro de tu entorno antes de enviarlos. +Consulte [Observability Pipelines][2] si desea enviar registros utilizando el recopilador o reenviador de otro proveedor, o si desea preprocesar sus datos de registro dentro de su entorno antes de enviarlos. -## Activa la recopilación de registros {#activate-log-collection} +## Activar la recopilación de registros {#activate-log-collection} -La recopilación de registros **no está habilitada** por defecto en el Agente de Datadog. Si estás ejecutando el Agente en un entorno de Kubernetes o Docker, consulta la documentación dedicada de [Recopilación de Registros de Kubernetes][3] o [Recopilación de Registros de Docker][4]. +La recopilación de registros **no está habilitada** de forma predeterminada en el Datadog Agent. Si está ejecutando el Agent en un entorno de Kubernetes o Docker, consulte la documentación dedicada de [Recopilación de registros de Kubernetes][3] o [Recopilación de registros de Docker][4]. -Para habilitar la recopilación de registros con un Agente que se ejecuta en tu servidor, cambia `logs_enabled: false` a `logs_enabled: true` en el [archivo de configuración principal][5] del Agente (`datadog.yaml`). +Para habilitar la recopilación de registros con un Agent ejecutándose en su host, cambie `logs_enabled: false` a `logs_enabled: true` en el [archivo de configuración principal][5] del Agent (`datadog.yaml`). {{< code-block lang="yaml" filename="datadog.yaml" disable_copy="false" collapsible="true" >}} logs_enabled: true @@ -39,9 +39,9 @@ logs_config: force_use_http: true {{< /code-block >}} -Consulta el [archivo de configuración config_template.yaml de ejemplo][6] para todas las opciones de configuración disponibles. +Para conocer todas las opciones de configuración disponibles, consulte los [ejemplos de archivos de configuración del Agent][6] para su sistema operativo. -
A partir del Agente v6.19+/v7.19+, el transporte HTTPS es el transporte predeterminado utilizado. Para más detalles, consulta Transporte del Agente.
+
A partir del Agent v6.19+/v7.19+, el transporte HTTPS es el transporte predeterminado utilizado. Para obtener más detalles, consulte transporte del Agent.
Para enviar registros con **variables de entorno**, configure lo siguiente: @@ -49,26 +49,28 @@ Para enviar registros con **variables de entorno**, configure lo siguiente: DD_LOGS_ENABLED=true ``` -Después de activar la recopilación de registros, el Agente está listo para enviar registros a Datadog. A continuación, configure el Agente para indicar desde dónde recopilar registros. +Después de activar la recopilación de registros, el Agent está listo para reenviar registros a Datadog. A continuación, configure el Agent indicando de dónde recopilar los registros. -## Recolección de registros personalizada {#custom-log-collection} +## Recopilación de registros personalizados {#custom-log-collection} -El Agente de Datadog v6 puede recopilar registros y enviarlos a Datadog desde archivos, la red (TCP o UDP), journald y canales de Windows: +El Datadog Agent v6 puede recopilar registros y reenviarlos a Datadog desde archivos, la red (TCP o UDP), journald y canales de Windows: -1. En el directorio `conf.d/` en la raíz de tu [directorio de configuración del Agente][5], crea una nueva carpeta `.d/` que sea accesible por el usuario de Datadog. -2. Crea un nuevo archivo `conf.yaml` en esta nueva carpeta. -3. Agrega un grupo de configuración de recolección de registros personalizada con los parámetros a continuación. -4. [Reinicia tu Agente][8] para tener en cuenta esta nueva configuración. -5. Ejecuta el [subcomando de estado del Agente][9] y busca `` en la sección de Comprobaciones. +1. En el directorio `conf.d/` en la raíz de su [directorio de configuración del Agent][5], cree una nueva carpeta `.d/` a la que pueda acceder el usuario de Datadog. +2. Cree un nuevo archivo `conf.yaml` en esta nueva carpeta. +3. Agregue un grupo de configuración de recopilación de registros personalizados con los parámetros a continuación. +4. [Reinicie el Agent][8] para tener en cuenta esta nueva configuración. +5. Ejecute el [subcomando de estado del Agent][9] y busque `` en la sección Checks. -Si hay errores de permisos, consulta [Problemas de permisos al seguir archivos de registro][10] para solucionar problemas. +Si hay errores de permisos, consulte [Problemas de permisos al seguimiento de las últimas líneas de archivos de registro][10] para solucionar el problema. -A continuación se presentan ejemplos de configuración de recopilación de registros personalizada: +Para implementar la configuración de recopilación de registros personalizados en varios Agentes a la vez sin editar archivos en cada host, consulte [Configurar registros personalizados][15] con Fleet Automation. + +A continuación, se muestran ejemplos de configuración de recopilación de registros personalizados: {{< tabs >}} {{% tab "Seguimiento de las últimas líneas de archivos" %}} -Para recopilar registros de tu `` aplicación almacenada en `/.log`, crea un archivo `.d/conf.yaml` en la raíz de tu [directorio de configuración del Agente][1] con el siguiente contenido: +Para recopilar registros de su `` aplicación almacenados en `/.log`, cree un archivo `.d/conf.yaml` en la raíz de su [directorio de configuración del Agent][1] con el siguiente contenido: ```yaml logs: @@ -78,22 +80,22 @@ logs: source: "" ``` -En **Windows**, usa la ruta `:\\\\.log` y verifica que el usuario `ddagentuser` tenga acceso de lectura al archivo de registro. +En **Windows**, utilice la ruta `:\\\\.log` y verifique que el usuario `ddagentuser` tenga acceso de lectura al archivo de registro. -**Nota**: Una línea de registro debe terminar con un carácter de nueva línea, `\n` o `\r\n`, de lo contrario, el Agente espera indefinidamente y no envía la línea de registro. +**Nota**: Una línea de registro debe terminar con un carácter de nueva línea, `\n` o `\r\n`; de lo contrario, el Agente espera indefinidamente y no envía la línea de registro. [1]: /es/agent/configuration/agent-configuration-files/ {{% /tab %}} {{% tab "TCP/UDP" %}} -Para capturar la dirección IP del remitente e incluirla en la carga del mensaje de registro, agrega la siguiente configuración a tu archivo `datadog.yaml`: +Para capturar la dirección IP del remitente e incluirla en la carga útil del mensaje de registro, agregue la siguiente configuración a su archivo `datadog.yaml`: ```yaml logs_config: use_sourcehost_tag: true ``` -Para recopilar registros de tu `` aplicación que envía sus registros al puerto TCP **10518**, crea un archivo `.d/conf.yaml` en la raíz de tu [directorio de configuración del Agente][1] con el siguiente contenido: +Para recopilar registros de su `` aplicación que reenvía sus registros al puerto TCP **10518**, cree un archivo `.d/conf.yaml` en la raíz de su [directorio de configuración del Agent][1] con el siguiente contenido: ```yaml logs: @@ -103,19 +105,19 @@ logs: source: "" ``` -Si estás utilizando Serilog, `Serilog.Sinks.Network` es una opción para conectarte con UDP. +Si está utilizando Serilog, `Serilog.Sinks.Network` es una opción para conectarse con UDP. -En la versión 7.31.0+ del Agente, la conexión TCP permanece abierta indefinidamente incluso cuando está inactiva. +En la versión 7.31.0+ del Agent, la conexión TCP permanece abierta indefinidamente incluso cuando está inactiva. **Notas**: -- El Agente soporta registros en formato de cadena sin procesar, JSON y Syslog. Si estás enviando registros en lotes, utiliza caracteres de salto de línea para separar tus registros. -- Una línea de registro debe terminar con un carácter de nueva línea, `\n` o `\r\n`, de lo contrario, el Agente espera indefinidamente y no envía la línea de registro. +- El Agent admite registros con formato de cadena sin procesar, JSON y Syslog. Si está enviando registros por lotes, utilice caracteres de salto de línea para separar sus registros. +- Una línea de registro debe terminar con un carácter de nueva línea, `\n` o `\r\n`; de lo contrario, el Agent espera indefinidamente y no envía la línea de registro. [1]: /es/agent/configuration/agent-configuration-files/ {{% /tab %}} {{% tab "journald" %}} -Para recopilar registros de journald, crea un archivo `journald.d/conf.yaml` en la raíz de tu [directorio de configuración del Agente][1] con el siguiente contenido: +Para recopilar registros de journald, cree un archivo `journald.d/conf.yaml` en la raíz de su [directorio de configuración del Agent][1] con el siguiente contenido: ```yaml logs: @@ -123,28 +125,28 @@ logs: path: /var/log/journal/ ``` -Consulta la documentación de la [integración de journald][2] para más detalles sobre la configuración para entornos en contenedores y filtrado de unidades. +Consulte la documentación de la [integración de journald][2] para obtener más detalles sobre la configuración para entornos en contenedores y el filtrado de unidades. [1]: /es/agent/configuration/agent-configuration-files/ [2]: /es/integrations/journald/ {{% /tab %}} {{% tab "Eventos de Windows" %}} -Para enviar eventos de Windows como registros a Datadog, agrega los canales a `conf.d/win32_event_log.d/conf.yaml` manualmente o utiliza el Administrador del Agente de Datadog. +Para enviar eventos de Windows como logs a Datadog, agregue los canales a `conf.d/win32_event_log.d/conf.yaml` manualmente o utilice el Datadog Agent Manager. -Para ver tu lista de canales, ejecuta el siguiente comando en PowerShell: +Para ver su lista de canales, ejecute el siguiente comando en PowerShell: ```text Get-WinEvent -ListLog * ``` -Para ver los canales más activos, ejecuta el siguiente comando en PowerShell: +Para ver los canales más activos, ejecute el siguiente comando en PowerShell: ```text Get-WinEvent -ListLog * | sort RecordCount -Descending ``` -Luego agrega los canales a tu archivo de configuración `win32_event_log.d/conf.yaml`: +Luego, agregue los canales a su archivo de configuración `win32_event_log.d/conf.yaml`: ```yaml logs: @@ -161,22 +163,22 @@ logs: sourcecategory: windowsevent ``` -Edita los parámetros de `` con el nombre del canal de Windows del cual deseas recopilar eventos. -Establece el parámetro correspondiente `source` al mismo nombre de canal para beneficiarte de la [configuración del pipeline de procesamiento automático de integración][1]. +Edite los parámetros de `` con el nombre del canal de Windows del cual desea recopilar eventos. +Establezca el parámetro `source` correspondiente con el mismo nombre de canal para beneficiarse de la [configuración de la canalización de procesamiento automático de la integración][1]. -Finalmente, [reinicia el Agente][2]. +Finalmente, [reinicie el Agent][2]. [1]: /es/logs/log_configuration/pipelines/#integration-pipelines [2]: /es/agent/basic_agent_usage/windows/ {{% /tab %}} -{{% tab "Ubicación Privada de Windows" %}} -Sigue los pasos en estas secciones para enviar los registros de Windows Private Location a Datadog: +{{% tab "Ubicación privada de Windows" %}} +Siga los pasos en estas secciones para enviar registros de Ubicación privada de Windows a Datadog: -### Configura el Agente {#configure-the-agent} +### Configure el Agent {#configure-the-agent} -1. Habilita la recolección de registros del Agente configurando `logs_enabled: true` en el archivo de configuración del Agente. -2. Navega a `C:\ProgramData\Datadog\conf.d` y crea una carpeta llamada `synthetics_worker.d`. -3. Dentro de la carpeta `synthetics_worker.d`, crea un archivo llamado `conf.yaml` utilizando el siguiente ejemplo como plantilla: +1. Habilite la recopilación de registro del Agent configurando `logs_enabled: true` en el archivo de configuración del Agent. +2. Navegue a `C:\ProgramData\Datadog\conf.d` y cree una carpeta llamada `synthetics_worker.d`. +3. Dentro de la carpeta `synthetics_worker.d`, cree un archivo llamado `conf.yaml` usando el siguiente ejemplo como plantilla: ```yaml logs: @@ -189,23 +191,23 @@ logs: - private_location: ``` -### Verifica el usuario que ejecuta el Agente {#verify-the-user-running-the-agent} +### Verifique el usuario que ejecuta el Agent {#verify-the-user-running-the-agent} -Dado que la carpeta de instalación de Ubicación Privada está restringida al acceso de administrador, el Agente de Datadog necesita permiso para acceder al archivo de registro. Sigue estos pasos para verificar el usuario que ejecuta el Agente de Datadog: +Dado que la carpeta de instalación de la Ubicación privada está restringida al acceso de administrador, el Datadog Agent necesita permiso para acceder al archivo de registro. Siga estos pasos para verificar el usuario que ejecuta el Datadog Agent: -1. Presiona la tecla de Windows y `R`, y busca {{< ui >}}Run{{< /ui >}}. -2. Encuentra el Agente de Datadog, haz clic derecho sobre él y selecciona {{< ui >}}Properties{{< /ui >}}. -3. En la pestaña {{< ui >}}Log On{{< /ui >}}, verifica la cuenta (el predeterminado es `ddagentuser`). -4. Cierra la ventana. +1. Presione la tecla Windows y `R`, y busque {{< ui >}}Run{{< /ui >}}. +2. Busque el Datadog Agent, haga clic derecho en él y seleccione {{< ui >}}Properties{{< /ui >}}. +3. En la pestaña {{< ui >}}Log On{{< /ui >}}, verifique la cuenta (la predeterminada es `ddagentuser`). +4. Cierre la ventana. -### Otorga permiso al usuario que ejecuta el Agente {#grant-permission-to-the-user-running-the-agent} +### Otorgue permiso al usuario que ejecuta el Agent {#grant-permission-to-the-user-running-the-agent} -1. Ve a `C:\Program Files` y encuentra la carpeta `synthetics_worker.d`. -2. Haz clic derecho en la carpeta `synthetics_worker.d` y selecciona {{< ui >}}Properties{{< /ui >}}. -3. Ve a la pestaña {{< ui >}}Security{{< /ui >}}. -4. Haz clic en {{< ui >}}Edit{{< /ui >}} y agrega `ddagentuser`. -5. Concede los permisos necesarios. -6. Reinicia el Agente de Datadog a través de la pantalla de Servicios o la línea de comandos para aplicar los cambios y comenzar a enviar registros a Datadog. +1. Vaya a `C:\Program Files` y busque la carpeta `synthetics_worker.d`. +2. Haga clic derecho en la carpeta `synthetics_worker.d` y seleccione {{< ui >}}Properties{{< /ui >}}. +3. Vaya a la pestaña {{< ui >}}Security{{< /ui >}}. +4. Haga clic en {{< ui >}}Edit{{< /ui >}} y agregue `ddagentuser`. +5. Otorgue los permisos necesarios. +6. Reinicie el Datadog Agent a través de la pantalla de Servicios o la línea de comandos para aplicar los cambios y comenzar a enviar registros a Datadog. {{% /tab %}} {{< /tabs >}} @@ -213,42 +215,42 @@ Lista de todos los parámetros disponibles para la recopilación de registros: | Parámetro | Requerido | Descripción | |------------------|----------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| `type` | Sí | El tipo de fuente de entrada de registros. Los valores válidos son: `tcp`, `udp`, `file`, `windows_event`, `docker` o `journald`. | -| `port` | Sí | Si `type` es **tcp** o **udp**, establece el puerto para escuchar los registros. | -| `path` | Sí | Si `type` es **file** o **journald**, establece la ruta del archivo para recopilar registros. | -| `channel_path` | Sí | Si `type` es **windows_event**, enumera los canales de eventos de Windows para recopilar registros. | -| `service` | Sí | El nombre del servicio que posee el registro. Si instrumentaste tu servicio con [Datadog APM][11], este debe ser el mismo nombre del servicio. Consulta las instrucciones de [unified service tagging][12] al configurar `service` a través de múltiples tipos de datos. | -| `source` | Sí | El atributo que define qué integración está enviando los registros. Si los registros no provienen de una integración existente, entonces este campo puede incluir un nombre de fuente personalizado. Sin embargo, se recomienda que configure este valor para que coincida con el espacio de nombres de las métricas personalizadas relacionadas que esté recopilando, por ejemplo: `myapp` de `myapp.request.count`. | -| `include_units` | No | Si `type` es **journald**, lista de las unidades específicas de journald a incluir. | -| `exclude_paths` | No | Si `type` es **file**, y `path` contiene un carácter comodín, lista el archivo o archivos que coincidan para excluir de la recopilación de registros. Esto está disponible para la versión del Agente >= 6.18. | -| `exclude_units` | No | Si `type` es **journald**, lista de las unidades específicas de journald a excluir. | +| `type` | Sí | El tipo de fuente de entrada de registro. Los valores válidos son: `tcp`, `udp`, `file`, `windows_event`, `docker` o `journald`. | +| `port` | Sí | Si `type` es **tcp** o **udp**, establezca el puerto para escuchar los registros. | +| `path` | Sí | Si `type` es **file** o **journald**, establezca la ruta del archivo para recopilar registros. | +| `channel_path` | Sí | Si `type` es **windows_event**, enumere los canales de eventos de Windows para recopilar registros. | +| `service` | Sí | El nombre del servicio al que pertenece el registro. Si instrumentó su servicio con [Datadog APM][11], este debe ser el mismo nombre de servicio. Consulte las instrucciones de [unified service tagging][12] al configurar `service` en varios tipos de datos. | +| `source` | Sí | El atributo que define qué integración está enviando los registros. Si los registros no provienen de una integración existente, este campo puede incluir un nombre de fuente personalizado. Sin embargo, se recomienda que haga coincidir este valor con el espacio de nombres de cualquier [métricas personalizadas][13] relacionadas que esté recopilando, por ejemplo: `myapp` de `myapp.request.count`. | +| `include_units` | No | Si `type` es **journald**, lista las unidades específicas de journald a incluir. | +| `exclude_paths` | Si | `type` es **file**, y `path` contiene un carácter comodín, liste el archivo o los archivos coincidentes a excluir de la recopilación de registros. Esto está disponible para la versión del Agent >= 6.18. | +| `exclude_units` | No | Si `type` es **journald**, lista las unidades específicas de journald a excluir. | | `sourcecategory` | No | El atributo utilizado para definir la categoría a la que pertenece un atributo de fuente, por ejemplo: `source:postgres, sourcecategory:database` o `source: apache, sourcecategory: http_web_access`. | -| `start_position` | No | Vea [Posición de inicio](#start-position) para más información.| -| `encoding` | No | Si `type` es **file**, establezca la codificación para que el Agente lea el archivo. Establezca en `utf-16-le` para UTF-16 little-endian, `utf-16-be` para UTF-16 big-endian, o `shift-jis` para Shift JIS. Si se establece en cualquier otro valor, el Agente lee el archivo como UTF-8. _Agregado `utf-16-le` y `utf-16be` en la versión 6.23/7.23 del Agente, `shift-jis` en la versión 6.34/7.34 del Agente_ | -| `tags` | No | Una lista de etiquetas añadidas a cada registro recopilado ([aprenda más sobre etiquetado][14]). | +| `start_position` | No | Consulte [Posición inicial](#start-position) para obtener más información.| +| `encoding` | No | Si `type` es **file**, establezca la codificación para que el Agent lea el archivo. Establézcalo en `utf-16-le` para UTF-16 little-endian, `utf-16-be` para UTF-16 big-endian o `shift-jis` para Shift JIS. Si se establece en cualquier otro valor, el Agent lee el archivo como UTF-8. _Se agregó `utf-16-le` y `utf-16be` en Agent v6.23/v7.23, `shift-jis` en Agent v6.34/v7.34_ | +| `tags` | No | Una lista de etiquetas agregadas a cada registro recopilado ([obtenga más información sobre el etiquetado][14]). | -### Posición de inicio {#start-position} +### Posición inicial {#start-position} -El parámetro `start_position` es compatible con **file** y **journald** tipos de tailer. El `start_position` siempre es `beginning` al seguir un contenedor. +El parámetro `start_position` es compatible con los tipos de tailer **file** y **journald**. El `start_position` siempre es `beginning` al realizar el seguimiento de un contenedor. Soporte: -- **File**: Agente 6.19+/7.19+ -- **Journald**: Agente 6.38+/7.38+ +- **File**: Agent 6.19+/7.19+ +- **Journald**: Agent 6.38+/7.38+ Si `type` es **file**: -- Establezca la posición para que el Agente comience a leer el archivo. +- Establezca la posición para que el Agent comience a leer el file. - Los valores válidos son `beginning`, `end`, `forceBeginning` y `forceEnd` (predeterminado: `end`). -- La `beginning` posición no admite rutas con comodines. +- La posición `beginning` no admite rutas con comodines. Si `type` es **journald**: -- Establezca la posición para que el Agente comience a leer el diario. +- Establezca la posición para que el Agent comience a leer el journal. - Los valores válidos son `beginning`, `end`, `forceBeginning` y `forceEnd` (predeterminado: `end`). #### Precedencia {#precedence} -Para ambos tipos de tailer, file y journald, si se especifica una posición `end` o `beginning`, pero se almacena un desplazamiento, el desplazamiento tiene prioridad. Usar `forceBeginning` o `forceEnd` obliga al Agente a usar el valor especificado incluso si hay un desplazamiento almacenado. +Para ambos tipos de tailer, file y journald, si se especifica una posición `end` o `beginning`, pero se almacena un desplazamiento, el desplazamiento tiene precedencia. El uso de `forceBeginning` o `forceEnd` obliga al Agent a utilizar el valor especificado, incluso si hay un desplazamiento almacenado. -## Lectura Adicional {#further-reading} +## Lecturas adicionales {#further-reading} {{< partial name="whats-next/whats-next.html" >}} @@ -257,7 +259,7 @@ Para ambos tipos de tailer, file y journald, si se especifica una posición `end [3]: /es/containers/kubernetes/log/ [4]: /es/containers/docker/log/ [5]: /es/agent/configuration/agent-configuration-files/ -[6]: https://github.com/DataDog/datadog-agent/blob/master/pkg/config/config_template.yaml +[6]: https://github.com/DataDog/datadog-agent/tree/main/pkg/config/example [7]: /es/agent/logs/log_transport/ [8]: /es/agent/configuration/agent-commands/#restart-the-agent [9]: /es/agent/configuration/agent-commands/#agent-status-and-information @@ -265,4 +267,5 @@ Para ambos tipos de tailer, file y journald, si se especifica una posición `end [11]: /es/tracing/ [12]: /es/getting_started/tagging/unified_service_tagging [13]: /es/metrics/custom_metrics/#overview -[14]: /es/getting_started/tagging/ \ No newline at end of file +[14]: /es/getting_started/tagging/ +[15]: /es/agent/fleet_automation/configure_logs/ \ No newline at end of file diff --git a/hugo/content/es/agent/supported_platforms/windows.md b/hugo/content/es/agent/supported_platforms/windows.md index f221fab5764..35bfd3b6a7f 100644 --- a/hugo/content/es/agent/supported_platforms/windows.md +++ b/hugo/content/es/agent/supported_platforms/windows.md @@ -9,149 +9,149 @@ algolia: aliases: - /es/guides/basic_agent_usage/windows/ - /es/agent/basic_agent_usage/windows/ -description: Funcionalidad básica del Agente de Datadog en la plataforma Windows. +description: Funcionalidad básica del Datadog Agent en la plataforma Windows. further_reading: - link: /logs/ tag: Documentación - text: Recopila tus registros + text: Recopile sus registros - link: /infrastructure/process/ tag: Documentación - text: Recopila tus procesos + text: Recopile sus procesos - link: /tracing/ tag: Documentación - text: Recopila tus trazas + text: Recopile sus trazas - link: /agent/architecture/#agent-architecture tag: Documentación - text: Descubre más sobre la arquitectura del Agente + text: Obtenga más información sobre la arquitectura del Agent - link: /agent/configuration/network#configure-ports tag: Documentación - text: Configura los puertos de entrada + text: Configurar puertos de entrada - link: /agent/guide/windows-agent-ddagent-user tag: Documentación - text: Aprende más sobre el Usuario del Agente de Datadog para Windows + text: Obtenga más información sobre el Datadog Windows Agent User platform: Windows title: Windows --- -## Resumen {#overview} +## Descripción general {#overview} -Esta página describe las características básicas del Agente de Datadog para Windows. Si aún no has instalado el Agente, consulta las instrucciones de instalación a continuación o [sigue las instrucciones en la aplicación][1]. +Esta página describe las características básicas del Datadog Agent para Windows. Si aún no ha instalado el Agent, consulte las instrucciones de instalación a continuación o [siga las instrucciones en la aplicación][1]. -Consulta [Plataformas Soportadas][15] para la lista completa de versiones de Windows soportadas. +Consulte [Plataformas compatibles][15] para obtener la lista completa de versiones de Windows compatibles. ## Instalación {#installation} -Para instalar el Agente de Datadog en tus hosts de Windows, sigue el [flujo guiado en la aplicación dentro de Fleet Automation][16], luego copia y ejecuta el comando de instalación. Los Agentes de Datadog se ejecutan bajo el `ddagentuser`. Consulta la documentación del [Usuario del Agente de Datadog para Windows][17] para más información. +Para instalar el Datadog Agent en sus hosts de Windows, siga el [flujo guiado en la aplicación dentro de Fleet Automation][16], luego copie y ejecute el comando de instalación. Los Datadog Agents se ejecutan bajo el `ddagentuser`. Consulte la documentación de [Datadog Windows Agent User][17] para obtener más información. -{{< img src="/agent/basic_agent_usage/windows_img2_july_25.png" alt="Pasos de instalación en la aplicación para el Agente de Datadog en un host de Windows." style="width:90%;">}} +{{< img src="/agent/basic_agent_usage/windows_img2_july_25.png" alt="Pasos de instalación en la aplicación para el Datadog Agent en un host de Windows." style="width:90%;">}} -## Métodos alternativos de instalación {#alternative-installation-methods} +## Métodos de instalación alternativos {#alternative-installation-methods} -### Instalar con la GUI del Administrador de Agentes {#install-with-the-agent-manager-gui} +### Instalar con la GUI del Agent Manager {#install-with-the-agent-manager-gui} -
La ubicación de instalación predeterminada para el Agente es %ProgramFiles%\Datadog\Datadog Agent. Si eliges usar una ubicación de instalación personalizada, asegúrate de especificar un Datadog subdirectorio para los archivos de Datadog.
+
La ubicación de instalación predeterminada para el Agent es %ProgramFiles%\Datadog\Datadog Agent. Si elige utilizar una ubicación de instalación personalizada, asegúrese de especificar un Datadog subdirectorio para los archivos de Datadog.
-1. Descarga el [instalador del Agente de Datadog][400] para instalar la última versión del Agente. -2. Ejecuta el instalador abriendo `datadog-agent-7-latest.amd64.msi`. Cuando se te solicite, ingresa tus credenciales de Administrador. -3. Sigue las instrucciones, acepta el acuerdo de licencia e ingresa tu [clave de API de Datadog][500]. +1. Descargue el [instalador del Datadog Agent][400] para instalar la versión más reciente del Agent. +2. Ejecute el instalador abriendo `datadog-agent-7-latest.amd64.msi`. Cuando se le solicite, ingrese sus credenciales de administrador. +3. Siga las instrucciones, acepte el acuerdo de licencia e ingrese su [clave de API de Datadog][500]. -Cuando la instalación finalice, se te dará la opción de iniciar el Administrador del Agente de Datadog. +Cuando finalice la instalación, se le dará la opción de iniciar el Datadog Agent Manager. #### Opciones de configuración de instalación {#installation-configuration-options} -Cada una de las siguientes opciones de configuración puede ser añadida como una propiedad a la línea de comandos al instalar el Agente en Windows. Para opciones adicionales de configuración del Agente, consulta [más opciones de configuración del Agente](#more-agent-configuration-options). +Cada una de las siguientes opciones de configuración se puede agregar como una propiedad a la línea de comandos al instalar el Agent en Windows. Para obtener opciones de configuración adicionales del Agent, consulte [más opciones de configuración del Agent](#more-agent-configuration-options). | Variable | Tipo | Descripción | |---------------------------- |---------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| `APIKEY` | Cadena | Agrega la clave de API de Datadog al archivo de configuración. | -| `SITE` | Cadena | Establece el sitio de recepción de Datadog, por ejemplo: `SITE=datadoghq.com` | +| `APIKEY` | Cadena | Agrega la CLAVE DE API de Datadog al archivo de configuración. | +| `SITE` | Cadena | Establece el sitio de ingesta de Datadog, por ejemplo: `SITE=datadoghq.com` | | `TAGS` | Cadena | Lista de etiquetas separadas por comas para asignar en el archivo de configuración. Ejemplo: `TAGS="key_1:val_1,key_2:val_2"` | -| `HOSTNAME` | Cadena | Configura el nombre de host reportado por el Agente a Datadog (anula cualquier nombre de host calculado en tiempo de ejecución). | -| `DDAGENTUSER_NAME` | Cadena | Sobrescribir el nombre de usuario predeterminado utilizado durante la instalación del Agente `ddagentuser`(v6.11.0+)__. [Aprende más sobre el usuario del Agente de Datadog para Windows][3]. | -| `DDAGENTUSER_PASSWORD` | Cadena | Sobrescribir la contraseña criptográficamente segura generada para el `ddagentuser` usuario durante la instalación del Agente _(v6.11.0+)_. Debe ser proporcionado para instalaciones en servidores de dominio. [Aprende más sobre el usuario del Agente de Datadog para Windows][3]. | -| `APPLICATIONDATADIRECTORY` | Ruta | Sobrescribir el directorio a utilizar para el árbol de directorios del archivo de configuración. Solo puede ser proporcionado en la instalación inicial; no es válido para actualizaciones. Predeterminado: `C:\ProgramData\Datadog`. _(v6.11.0+)_ | -| `PROJECTLOCATION` | Ruta | Sobrescribir el directorio a utilizar para el árbol de directorios del archivo binario. Solo puede ser proporcionado en la instalación inicial; no es válido para actualizaciones. Predeterminado: `%ProgramFiles%\Datadog\Datadog Agent`. _(v6.11.0+)_

Si decides sobrescribir el directorio predeterminado, asegúrate de especificar un `Datadog` subdirectorio para los archivos de Datadog. | +| `HOSTNAME` | Cadena | Configura el nombre de host reportado por el Agent a Datadog (anula cualquier nombre de host calculado en tiempo de ejecución). | +| `DDAGENTUSER_NAME` | Cadena | Anula el nombre de usuario `ddagentuser` predeterminado utilizado durante la instalación del Agent _(v6.11.0+)_. [Obtenga más información sobre el Datadog Windows Agent User][3]. | +| `DDAGENTUSER_PASSWORD` | Cadena | Anula la contraseña criptográficamente segura generada para el usuario `ddagentuser` durante la instalación del Agent _(v6.11.0+)_. Debe proporcionarse para instalaciones en servidores de dominio. [Obtenga más información sobre el Datadog Windows Agent User][3]. | +| `APPLICATIONDATADIRECTORY` | Ruta | Anula el directorio que se utilizará para el árbol de directorios del archivo de configuración. Solo puede proporcionarse en la instalación inicial; no es válido para actualizaciones. Predeterminado: `C:\ProgramData\Datadog`. _(v6.11.0+)_ | +| `PROJECTLOCATION` | Ruta | Anula el directorio que se utilizará para el árbol de directorios del archivo binario. Solo puede proporcionarse en la instalación inicial; no es válido para actualizaciones. Predeterminado: `%ProgramFiles%\Datadog\Datadog Agent`. _(v6.11.0+)_

Si decide anular el directorio predeterminado, asegúrese de especificar un subdirectorio `Datadog` para los archivos de Datadog. | **Notas** -- La `/qn` opción ejecuta una instalación silenciosa. Para ver los mensajes de la GUI, elimínalo. -- Algunas versiones del Agente pueden causar un reinicio forzado. Para prevenir esto, agrega el parámetro: `REBOOT=ReallySuppress`. -- Algunos componentes del Agente requieren un controlador de kernel para recopilar datos. Para saber si se requiere un controlador de kernel para su componente, consulte su página de documentación o busque `kernel driver` en los archivos de configuración del Agente asociados. +- La opción `/qn` ejecuta una instalación silenciosa. Para ver las indicaciones de la GUI, elimínela. +- Algunas versiones del Agent pueden causar un reinicio forzado. Para evitar esto, agregue el parámetro: `REBOOT=ReallySuppress`. +- Algunos componentes del Agent requieren un controlador de kernel para recopilar datos. Para saber si se requiere un controlador de kernel para su componente, consulte su página de documentación o busque `kernel driver` en los archivos de configuración del Agent asociados. - Si se encuentra un `datadog.yaml` válido, ese archivo tiene prioridad sobre todas las opciones de línea de comandos especificadas. -#### Más opciones de configuración del Agente {#more-agent-configuration-options} +#### Más opciones de configuración del Agent {#more-agent-configuration-options} -Cada una de las siguientes opciones de configuración puede ser añadida como una propiedad a la línea de comandos al instalar el Agente en Windows. +Cada una de las siguientes opciones de configuración se puede agregar como una propiedad a la línea de comandos al instalar el Agent en Windows. **Nota**: Si se encuentra un `datadog.yaml` válido, ese archivo tiene prioridad sobre todas las opciones de línea de comandos especificadas. | Variable | Tipo | Descripción | |---------------------------- |---------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| `LOGS_ENABLED` | Cadena | Habilitar (`"true"`) o deshabilitar (`"false"`) la función de recopilación de registros en el archivo de configuración. Los registros están deshabilitados por defecto. | -| `APM_ENABLED` | Cadena | Habilitar (`"true"`) o deshabilitar (`"false"`) el APM Agent en el archivo de configuración. APM está habilitado por defecto. | -| `PROCESS_ENABLED` | Cadena | Habilitar (`"true"`) o deshabilitar (`"false"`) el Agente de Procesos en el archivo de configuración. El Agente de Procesos está deshabilitado por defecto. | -| `HOSTNAME_FQDN_ENABLED` | Cadena | Habilitar (`"true"`) o deshabilitar (`"false"`) el uso de FQDN para el nombre de host del Agente. Es equivalente a establecer `hostname_fqdn` en el archivo de configuración del Agente. El uso de FQDN para el nombre de host está deshabilitado por defecto. _(v6.20.0+)_ | -| `CMD_PORT` | Número | Un número de puerto válido entre 0 y 65534. El Agente de Datadog expone una API de comandos en el puerto 5001. Si ese puerto ya está en uso por otro programa, el valor predeterminado puede ser sobrescrito aquí. | -| `PROXY_HOST` | Cadena | (Si utiliza un proxy) establece su host de proxy. [Aprende más sobre el uso de un proxy con el Agente de Datadog][4]. | -| `PROXY_PORT` | Número | (Si utiliza un proxy) establece su puerto de proxy. [Aprende más sobre el uso de un proxy con el Agente de Datadog][4]. | -| `PROXY_USER` | Cadena | (Si utiliza un proxy) establece su usuario de proxy. [Aprende más sobre el uso de un proxy con el Agente de Datadog][4]. | -| `PROXY_PASSWORD` | Cadena | (Si utiliza un proxy) establece su contraseña de proxy. Para el Agente de procesos y contenedores, esta variable es necesaria para proporcionar una contraseña de autenticación y no puede ser renombrada. [Aprende más sobre el uso de un proxy con el Agente de Datadog][4]. | -| `EC2_USE_WINDOWS_PREFIX_DETECTION` | Booleano | Utilizar el id de instancia de EC2 para hosts de Windows en EC2. _(v7.28.0+)_ | +| `LOGS_ENABLED` | Cadena | Habilite (`"true"`) o deshabilite (`"false"`) la función de recopilación de registro en el archivo de configuración. Los registros están deshabilitados de forma predeterminada. | +| `APM_ENABLED` | Cadena | Habilite (`"true"`) o deshabilite (`"false"`) el APM Agent en el archivo de configuración. APM está habilitado de forma predeterminada. | +| `PROCESS_ENABLED` | Cadena | Habilite (`"true"`) o deshabilite (`"false"`) el Process Agent en el archivo de configuración. El Process Agent está deshabilitado de forma predeterminada. | +| `HOSTNAME_FQDN_ENABLED` | Cadena | Habilite (`"true"`) o deshabilite (`"false"`) el uso de FQDN para el nombre de host del Agent. Es equivalente a establecer `hostname_fqdn` en el archivo de configuración del Agent. El uso de FQDN para el nombre de host está deshabilitado de forma predeterminada. _(v6.20.0+)_ | +| `CMD_PORT` | Número | Un número de puerto válido entre 0 y 65534. El Datadog Agent expone una API de comandos en el puerto 5001. Si ese puerto ya está en uso por otro programa, el valor predeterminado puede anularse aquí. | +| `PROXY_HOST` | Cadena | (Si usa un proxy) establece su servidor proxy. [Obtenga más información sobre el uso de un proxy con el Datadog Agent][4]. | +| `PROXY_PORT` | Número | (Si usa un proxy) establece su puerto de proxy. [Obtenga más información sobre el uso de un proxy con el Datadog Agent][4]. | +| `PROXY_USER` | Cadena | (Si usa un proxy) establece su usuario de proxy. [Obtenga más información sobre el uso de un proxy con el Datadog Agent][4]. | +| `PROXY_PASSWORD` | Cadena | (Si usa un proxy) establece su contraseña de proxy. Para el Agente de procesos/contenedores, esta variable es necesaria para ingresar una contraseña de autenticación y no se puede cambiar de nombre. [Obtenga más información sobre el uso de un proxy con el Datadog Agent][4]. | +| `EC2_USE_WINDOWS_PREFIX_DETECTION` | Booleano | Use el ID de instancia de EC2 para hosts de Windows en EC2. _(v7.28.0+)_ | #### Archivos de registro de instalación {#installation-log-files} -Establezca la opción `/log ` msiexec para configurar un archivo de registro de instalación. Si esta opción no se establece, msiexec escribe el registro en `%TEMP%\MSI*.LOG` por defecto. +Establezca la opción `/log ` de msiexec para configurar un archivo de registro de instalación. Si esta opción no está establecida, msiexec escribe el registro en `%TEMP%\MSI*.LOG` de forma predeterminada. ## Configuración {#configuration} -El archivo de configuración principal del Agente se encuentra en -`C:\ProgramData\Datadog\datadog.yaml`. Este archivo se utiliza para configuraciones a nivel de servidor, como la clave de API, el sitio de Datadog seleccionado, parámetros de proxy, etiquetas de host y nivel de registro. +El archivo de configuración principal del Agent se encuentra en +`C:\ProgramData\Datadog\datadog.yaml`. Este archivo se utiliza para configuraciones a nivel de host, como la clave de API, el sitio de Datadog seleccionado, los parámetros de proxy, las etiquetas del host y el nivel de registro. -También hay un archivo `datadog.yaml.example` en el mismo directorio, que es una referencia completamente comentada con todas las opciones de configuración disponibles, útil para referencia y copia de configuraciones específicas. +También hay un archivo `datadog.yaml.example` en el mismo directorio, que es una referencia completamente comentada con todas las opciones de configuración disponibles, útil para consultar y copiar configuraciones específicas. Alternativamente, consulte el [archivo de configuración de ejemplo del Agent para Windows][19] en GitHub. -Los archivos de configuración para integraciones se encuentran en: -`C:\ProgramData\Datadog\conf.d\` También puede haber una ubicación alternativa heredada: `C:\Documents and Settings\All Users\Application Data\Datadog\conf.d\`. +Los archivos de configuración para las integraciones se encuentran en: +`C:\ProgramData\Datadog\conf.d\` También puede haber una ubicación heredada alternativa: `C:\Documents and Settings\All Users\Application Data\Datadog\conf.d\`. Cada integración tiene un subdirectorio `.d\` que contiene: - `conf.yaml`: La configuración activa para la integración * `conf.yaml.example`: Un archivo de muestra que muestra qué claves de configuración son compatibles -Al realizar cambios en la configuración, asegúrese de reiniciar el Agente para garantizar que los cambios surtan efecto. +Al realizar cambios en la configuración, asegúrese de reiniciar el Agent para garantizar que los cambios surtan efecto. -La [Interfaz Gráfica del Administrador del Agente de Datadog][6] se puede utilizar para habilitar, deshabilitar y configurar verificaciones. Debe reiniciar el Agente para que sus cambios surtan efecto. +La [GUI del Administrador del Datadog Agent][6] se puede utilizar para habilitar, deshabilitar y configurar comprobaciones. Debe reiniciar el Agent para que los cambios surtan efecto. **Nota**: `ProgramData` es una carpeta oculta. -## Comandos del Agente {#agent-commands} +## Comandos del Agent {#agent-commands} -La ejecución del Agente es controlada por el Administrador de Control de Servicios de Windows. +La ejecución del Agent es controlada por el Windows Service Control Manager. * El nombre del ejecutable principal es `agent.exe`. -* La interfaz gráfica de configuración es una aplicación de configuración basada en navegador (solo para Windows de 64 bits). -* Los comandos se pueden ejecutar desde la **línea de comandos elevada (ejecutar como Administrador)** utilizando la sintaxis ` `. -* Las opciones de línea de comandos son las siguientes: +* La GUI de configuración es una aplicación de configuración basada en navegador (solo para Windows de 64 bits). +* Los comandos se pueden ejecutar desde la línea de comandos **elevada (ejecutar como administrador)** (PowerShell o Símbolo del sistema) usando la sintaxis ` `. +* Las opciones de la línea de comandos se muestran a continuación: | Comando | Descripción | |-----------------|----------------------------------------------------------------------------------| -| check | Ejecuta la verificación especificada. | +| check | Ejecuta la verificación especificada. | | diagnose | Ejecuta un diagnóstico de conectividad en su sistema. | -| flare | Recoge un flare y lo envía a Datadog. | +| flare | Recopila un flare y lo envía a Datadog. | | help | Obtiene ayuda sobre cualquier comando. | -| hostname | Imprime el nombre de host utilizado por el Agente. | -| import | Importa y convierte archivos de configuración de versiones anteriores del Agente. | -| launch-gui | Inicia el Administrador del Agente de Datadog. | -| restart-service | Reinicia el Agente dentro del administrador de control de servicios. | -| run | Inicia el Agente. | -| start | Inicia el Agente. (Está siendo desaprobado, pero aceptado.) Utiliza `run` como alternativa.) | -| start-service | Inicia el Agente dentro del administrador de control de servicios. | +| hostname | Imprime el nombre de host utilizado por el Agent. | +| import | Importa y convierte archivos de configuración de versiones anteriores del Agent. | +| launch-gui | Inicia el Datadog Agent Manager. | +| restart-service | Reinicia el Agent dentro del administrador de control de servicios. | +| run | Inicia el Agent. | +| start | Inicia el Agent. (Está en desuso, pero se acepta. Utilice `run` como alternativa.) | +| start-service | Inicia el Agent dentro del Windows Service Control Manager. | | status | Imprime el estado actual. | -| stopservice | Detiene el Agente dentro del administrador de control de servicios. | +| stopservice | Detiene el Agent dentro del Windows Service Control Manager. | | version | Imprime la información de la versión. | **Ejemplos**: @@ -163,7 +163,7 @@ La ejecución del Agente es controlada por el Administrador de Control de Servic & "$env:ProgramFiles\Datadog\Datadog Agent\bin\agent.exe" flare ``` - - Símbolo del sistema (`cmd.exe`) + - Command Prompt (`cmd.exe`) ```cmd "%ProgramFiles%\Datadog\Datadog Agent\bin\agent.exe" status @@ -171,13 +171,13 @@ La ejecución del Agente es controlada por el Administrador de Control de Servic "%ProgramFiles%\Datadog\Datadog Agent\bin\agent.exe" flare ``` -## Desinstalar el Agente {#uninstall-the-agent} +## Desinstale el Agent {#uninstall-the-agent} -Existen dos métodos diferentes para desinstalar el Agente en Windows. Ambos métodos eliminan el Agente, pero no eliminan la carpeta de configuración `C:\ProgramData\Datadog` en el servidor. +Existen dos métodos diferentes para desinstalar el Agent en Windows. Ambos métodos eliminan el Agent, pero no eliminan la carpeta de configuración `C:\ProgramData\Datadog` en el servidor. ### Agregar o quitar programas {#add-or-remove-programs} -1. Presione **CTRL** y **Esc** o use la tecla de Windows para ejecutar la búsqueda de Windows. +1. Presione **CTRL** y **Esc** o use la tecla de Windows para ejecutar la Búsqueda de Windows. 1. Busque `add` y haga clic en {{< ui >}}Add or remove programs{{< /ui >}}. 1. Busque `Datadog Agent` y haga clic en {{< ui >}}Uninstall{{< /ui >}}. @@ -185,7 +185,7 @@ Existen dos métodos diferentes para desinstalar el Agente en Windows. Ambos mé **Nota:** Habilite WinRM para usar los comandos a continuación. -Utilice el siguiente comando de PowerShell para desinstalar el Agente sin reiniciar: +Utilice el siguiente comando de PowerShell para desinstalar el Agent sin reiniciar: {{< code-block lang="powershell" >}} $productCode = (@(Get-ChildItem -Path "HKLM:SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" -Recurse) | Where {$_.GetValue("DisplayName") -like "Datadog Agent" }).PSChildName @@ -194,24 +194,24 @@ start-process msiexec -Wait -ArgumentList ('/log', 'C:\uninst.log', '/q', '/x', ## Solución de problemas {#troubleshooting} -Para los pasos de solución de problemas, consulte la [documentación de Solución de problemas del Agente][18]. +Para conocer los pasos de solución de problemas, consulte la [documentación de solución de problemas del Agent][18] . -### Estado e información del Agente {#agent-status-and-information} +### Estado e información del Agent {#agent-status-and-information} -Para verificar que el Agente esté en ejecución, verifique si el servicio `DatadogAgent` en el panel de Servicios está listado como *Iniciado*. Un proceso llamado *Datadog Metrics Agent* (`agent.exe`) también debería existir en el Administrador de tareas. +Para verificar que el Agent se esté ejecutando, compruebe si el servicio `DatadogAgent` en el panel de Servicios aparece como *Iniciado*. Un proceso llamado *Datadog Metrics Agent* (`agent.exe`) también debería existir en el Administrador de tareas. -Para recibir más información sobre el estado del Agente, inicie el Administrador del Agente de Datadog: +Para recibir más información sobre el estado del Agent, inicie el Datadog Agent Manager: -* Haga clic derecho en el ícono del sistema del Agente de Datadog > {{< ui >}}Configure{{< /ui >}}, o -* Run `launch-gui` el comando desde una **línea de comandos elevada (ejecutar como Administrador)** +* Haga clic derecho en el icono de la bandeja del sistema del Datadog Agent > {{< ui >}}Configure{{< /ui >}}, o +* Ejecute el comando `launch-gui` desde una línea de comandos **elevada (ejecutar como administrador)** - PowerShell: `& "" launch-gui` - cmd: `"" launch-gui` Luego, abra la página de estado yendo a {{< ui >}}Status{{< /ui >}} > {{< ui >}}General{{< /ui >}}. -Obtenga más información sobre la ejecución de checks en {{< ui >}}Status{{< /ui >}} > {{< ui >}}Collector{{< /ui >}} y {{< ui >}}Checks{{< /ui >}} > {{< ui >}}Summary{{< /ui >}}. +Obtenga más información sobre cómo ejecutar verificaciones en {{< ui >}}Status{{< /ui >}} > {{< ui >}}Collector{{< /ui >}} y {{< ui >}}Checks{{< /ui >}} > {{< ui >}}Summary{{< /ui >}}. -El comando status está disponible para PowerShell: +El comando de estado está disponible para PowerShell: ```powershell & "$env:ProgramFiles\Datadog\Datadog Agent\bin\agent.exe" status @@ -225,37 +225,37 @@ o cmd.exe: ### Ubicación de los registros {#logs-location} -Los registros del Agente se encuentran en `C:\ProgramData\Datadog\logs\agent.log`. +Los registros del Agent se encuentran en `C:\ProgramData\Datadog\logs\agent.log`. **Nota**: `ProgramData` es una carpeta oculta. ## Casos de uso {#use-cases} -### Monitoreo de un servicio de Windows {#monitoring-a-windows-service} +### Seguimiento de un servicio de Windows {#monitoring-a-windows-service} -En su servidor objetivo, inicie el Administrador del Agente de Datadog y seleccione la integración {{< ui >}}Windows Service{{< /ui >}} de la lista. Hay un ejemplo listo para usar; sin embargo, este ejemplo utiliza DHCP. +En su host de destino, inicie el Datadog Agent Manager y seleccione la integración {{< ui >}}Windows Service{{< /ui >}} de la lista. Existe un ejemplo predeterminado; sin embargo, este ejemplo utiliza DHCP. -Para obtener el nombre del servicio, abra `services.msc` y localice su servicio objetivo. Usando DHCP como objetivo, puede ver el nombre del servicio en la parte superior de la ventana de propiedades del servicio: +Para obtener el nombre del servicio, abra `services.msc` y localice su servicio de destino. Usando DHCP como destino, puede ver el nombre del servicio en la parte superior de la ventana de propiedades del servicio: {{< img src="agent/faq/DHCP.png" alt="DHCP" style="width:75%;">}} -Al agregar sus propios servicios, asegúrese de seguir el formato exactamente como se muestra. Si el formato no es correcto, la integración falla. **Nota**: Los caracteres especiales en un nombre de servicio deben ser escapados. Por ejemplo, el nombre `MSSQL$BILLING` se puede agregar con `MSSQL\$BILLING`. +Al agregar sus propios servicios, asegúrese de seguir el formato exactamente como se muestra. Si el formato no es correcto, la integración fallará. **Nota**: Los caracteres especiales en un nombre de servicio deben escaparse. Por ejemplo, el nombre `MSSQL$BILLING` puede agregarse con `MSSQL\$BILLING`. {{< img src="agent/faq/windows_DHCP_service.png" alt="Servicio DHCP de Windows" style="width:75%;">}} -Además, cada vez que modifique una integración, el servicio de Datadog necesita ser reiniciado. Puede hacer esto desde services.msc o desde la barra lateral de la interfaz de usuario. +Además, siempre que modifique una integración, es necesario reiniciar el servicio de Datadog. Puede hacer esto desde services.msc o desde la barra lateral de la interfaz de usuario. -Para los servicios, Datadog no rastrea las métricas, solo su disponibilidad. (Para métricas, use la [Process](#monitoring-windows-processes) o [WMI][7]). Para configurar un Monitor, seleccione el [tipo de monitor de integración][8] y luego busque {{< ui >}}Windows Service{{< /ui >}}. Desde {{< ui >}}Integration Status{{< /ui >}} > {{< ui >}}Pick Monitor Scope{{< /ui >}}, elija el servicio que desea monitorear. +Para los servicios, Datadog no rastrea las métricas, solo su disponibilidad. (Para métricas, use la integración [Process](#monitoring-windows-processes) o [WMI][7]). Para configurar un Monitor, seleccione el [Integration monitor type][8] y luego busque {{< ui >}}Windows Service{{< /ui >}}. Desde {{< ui >}}Integration Status{{< /ui >}} > {{< ui >}}Pick Monitor Scope{{< /ui >}}, elija el servicio al que desea hacer un seguimiento. -### Monitoreo de carga del sistema para Windows {#monitoring-system-load-for-windows} +### Seguimiento de la carga del sistema para Windows {#monitoring-system-load-for-windows} -El Agente de Datadog recopila un gran número de métricas del sistema por defecto. Las métricas del sistema más comúnmente utilizadas son `system.load.*`, pero estas métricas son **específicas de Unix**. +El Datadog Agent recopila una gran cantidad de métricas del sistema de forma predeterminada. Las métricas del sistema más utilizadas son `system.load.*`, pero estas métricas son específicas de **Unix**. -Aunque Windows no ofrece las métricas `system.load.*`, una opción equivalente que está disponible por defecto es `system.proc.queue.length`. Esta métrica muestra el número de hilos observados como retrasados en la cola de listos del procesador que están esperando ser ejecutados. +Aunque Windows no ofrece las métricas `system.load.*`, una opción equivalente disponible de forma predeterminada es `system.proc.queue.length`. Esta métrica muestra la cantidad de subprocesos observados como retrasados en la cola de preparación del procesador que están esperando ser ejecutados. -### Monitoreando procesos de Windows {#monitoring-windows-processes} +### Seguimiento de procesos de Windows {#monitoring-windows-processes} -Puedes monitorear procesos de Windows con [Live Process Monitoring][9]. Para habilitar esto en Windows, edita el [archivo de configuración principal del Agente][10] estableciendo el siguiente parámetro en verdadero: +Puede hacer un seguimiento de los procesos de Windows con [Live Process Monitoring][9]. Para habilitar esto en Windows, edite el [archivo de configuración principal del Agent][10] estableciendo el siguiente parámetro en true: `datadog.yaml`: @@ -264,9 +264,9 @@ process_config: enabled: "true" ``` -Después de completar la configuración, [reinicia el Agente][11]. +Una vez completada la configuración, [reinicie el Agente][11]. -## Lectura adicional {#further-reading} +## Lecturas adicionales {#further-reading} {{< partial name="whats-next/whats-next.html" >}} @@ -289,5 +289,6 @@ Después de completar la configuración, [reinicia el Agente][11]. [16]: https://app.datadoghq.com/fleet/install-agent/latest?platform=windows [17]: /es/agent/faq/windows-agent-ddagent-user/ [18]: https://docs.datadoghq.com/es/agent/troubleshooting/ +[19]: https://github.com/DataDog/datadog-agent/blob/main/pkg/config/example/datadog-agent_windows.yaml.example [400]: https://windows-agent.datadoghq.com/datadog-agent-7-latest.amd64.msi [500]: https://app.datadoghq.com/organization-settings/api-keys \ No newline at end of file diff --git a/hugo/content/es/api/latest/agent-observability/create-or-update-a-custom-evaluator-configuration/index.md b/hugo/content/es/api/latest/agent-observability/create-or-update-a-custom-evaluator-configuration/index.md new file mode 100644 index 00000000000..4ebfe41f6e1 --- /dev/null +++ b/hugo/content/es/api/latest/agent-observability/create-or-update-a-custom-evaluator-configuration/index.md @@ -0,0 +1,3 @@ +--- +title: Cree o actualice una configuración de evaluador personalizada +--- diff --git a/hugo/content/es/api/latest/agent-observability/get-a-custom-evaluator-configuration/index.md b/hugo/content/es/api/latest/agent-observability/get-a-custom-evaluator-configuration/index.md new file mode 100644 index 00000000000..22a34e3e2c5 --- /dev/null +++ b/hugo/content/es/api/latest/agent-observability/get-a-custom-evaluator-configuration/index.md @@ -0,0 +1,3 @@ +--- +title: Obtenga una configuración personalizada de evaluador +--- diff --git a/hugo/content/es/api/latest/agent-observability/list-agent-observability-dataset-versions/index.md b/hugo/content/es/api/latest/agent-observability/list-agent-observability-dataset-versions/index.md new file mode 100644 index 00000000000..27958b2f3b9 --- /dev/null +++ b/hugo/content/es/api/latest/agent-observability/list-agent-observability-dataset-versions/index.md @@ -0,0 +1,3 @@ +--- +title: Liste las versiones del conjunto de datos de Agent Observability +--- diff --git a/hugo/content/es/api/latest/llm-observability/list-agent-observability-datasets/index.md b/hugo/content/es/api/latest/llm-observability/list-agent-observability-datasets/index.md new file mode 100644 index 00000000000..6fde0c0c5da --- /dev/null +++ b/hugo/content/es/api/latest/llm-observability/list-agent-observability-datasets/index.md @@ -0,0 +1,3 @@ +--- +title: Liste los datasets de Agent Observability +--- diff --git a/hugo/content/es/api/latest/llm-observability/unlock-agent-observability-dataset-draft-state/index.md b/hugo/content/es/api/latest/llm-observability/unlock-agent-observability-dataset-draft-state/index.md new file mode 100644 index 00000000000..ec3952a583c --- /dev/null +++ b/hugo/content/es/api/latest/llm-observability/unlock-agent-observability-dataset-draft-state/index.md @@ -0,0 +1,3 @@ +--- +title: Desbloquee el draft state del dataset de Agent Observability +--- diff --git a/hugo/content/es/api/latest/rum-retention-quotas/get-a-rum-retention-quota-configuration/index.md b/hugo/content/es/api/latest/rum-retention-quotas/get-a-rum-retention-quota-configuration/index.md new file mode 100644 index 00000000000..7f91bf1e0ce --- /dev/null +++ b/hugo/content/es/api/latest/rum-retention-quotas/get-a-rum-retention-quota-configuration/index.md @@ -0,0 +1,3 @@ +--- +title: Obtenga una configuración de cuota de retención RUM +--- diff --git a/hugo/content/es/byoc-logs/introduction/network.md b/hugo/content/es/byoc-logs/introduction/network.md new file mode 100644 index 00000000000..1de999e560b --- /dev/null +++ b/hugo/content/es/byoc-logs/introduction/network.md @@ -0,0 +1,49 @@ +--- +aliases: +- /es/cloudprem/introduction/network/ +further_reading: +- link: /byoc-logs/configure/ingress/ + tag: Documentación + text: Configuración de ingreso de BYOC Logs +title: Red +--- +Este documento proporciona una descripción general de cómo BYOC Logs (Bring Your Own Cloud) y Datadog se comunican entre sí. + +## Conexión inversa (predeterminada) {#reverse-connection-default} + +De forma predeterminada, los pods **searcher** de BYOC Logs inician una conexión WebSocket saliente a Datadog utilizando su clave de API. Cada pod searcher mantiene su propia conexión a `wss:///api/unstable/cloudprem-connection-gateway/connect`. + +Datadog recomienda esta configuración porque: +- **No es necesario abrir puertos de entrada** en su red. +- **No se requiere ningún registro DNS ni ingreso público.** +- La conexión se inicia desde su infraestructura, lo que simplifica las políticas de firewall y seguridad. + +### Qué fluye a través de la conexión inversa {#what-flows-through-the-reverse-connection} + +| Datos | Dirección | Descripción | +|------|-----------|-------------| +| Consultas de búsqueda | Datadog → BYOC Logs | Consultas desde Log Explorer, tableros, monitores | +| Resultados de la consulta | BYOC Logs → Datadog | Entradas de registro coincidentes devueltas para su visualización | +| Gestión de índices | Datadog → BYOC Logs | Creación, actualizaciones y eliminación de índices | + +### Requisitos de red {#network-requirements} + +Los pods searcher requieren acceso **HTTPS de salida (puerto 443)** a su sitio de Datadog (por ejemplo, `app.datadoghq.com`). No se requiere conectividad de entrada. + +Si su entorno utiliza un proxy HTTP, BYOC Logs admite la configuración de proxy estándar con las variables de entorno `HTTPS_PROXY`, `ALL_PROXY` y `NO_PROXY`. + +### ¿Qué pods se conectan a Datadog? {#which-pods-connect-to-datadog} + +Solo los pods **searcher** establecen la conexión inversa. Los indexadores, el plano de control, el metastore y el janitor no inician ninguna conexión con Datadog. + +
Mantenga al menos un pod searcher en ejecución cuando utilice la conexión inversa. Si todos los pods searcher no están disponibles o se escalan a 0, Datadog no puede enrutar consultas ni solicitudes de gestión de índices a través de la conexión inversa hasta que un pod searcher se inicie y se vuelva a conectar.
+ +## Ingreso público (opcional) {#public-ingress-optional} + +También es posible configurar BYOC Logs para implementar un ingreso público de modo que Datadog pueda establecer la conexión en la otra dirección. + +El ingreso público permite que el plano de control y el servicio de consultas de Datadog gestionen y consulten los clústeres de BYOC Logs a través de internet pública. Proporciona acceso seguro a la API de gRPC de BYOC Logs mediante autenticación mTLS. Puede encontrar más información sobre el ingreso de BYOC Logs en su [página de configuración](/byoc-logs/configure/ingress/). + +## Lecturas adicionales {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} \ No newline at end of file diff --git a/hugo/content/es/byoc-logs/operate/_index.md b/hugo/content/es/byoc-logs/operate/_index.md new file mode 100644 index 00000000000..8076fa833c9 --- /dev/null +++ b/hugo/content/es/byoc-logs/operate/_index.md @@ -0,0 +1,21 @@ +--- +aliases: +- /es/cloudprem/operate/ +description: Aprenda cómo hacer un seguimiento y solucionar problemas de su implementación + de BYOC Logs +title: Operar BYOC Logs +--- +## Descripción general {#overview} + +Administre su implementación de BYOC Logs (Bring Your Own Cloud) con guías sobre dimensionamiento, escalado automático, seguimiento y solución de problemas. + +{{< whatsnext desc="Operar BYOC Logs:">}} + {{< nextlink href="/byoc-logs/operate/sizing/" >}}Guía de dimensionamiento{{< /nextlink >}} + {{< nextlink href="/byoc-logs/operate/autoscaling/" >}}Escalar automáticamente indexadores y compactadores{{< /nextlink >}} + {{< nextlink href="/byoc-logs/operate/monitoring/" >}}Hacer un seguimiento de BYOC Logs{{< /nextlink >}} + {{< nextlink href="/byoc-logs/operate/search_logs/" >}}Buscar registros{{< /nextlink >}} + {{< nextlink href="/byoc-logs/operate/best_practices/" >}}Mejores prácticas de producción{{< /nextlink >}} + {{< nextlink href="/byoc-logs/operate/disk_buffer_durability/" >}}Configurar la durabilidad del búfer de disco{{< /nextlink >}} + {{< nextlink href="/byoc-logs/operate/updates/" >}}Lanzamientos y actualizaciones{{< /nextlink >}} + {{< nextlink href="/byoc-logs/operate/troubleshooting/" >}}Solución de problemas{{< /nextlink >}} +{{< /whatsnext >}} \ No newline at end of file diff --git a/hugo/content/es/cloud_cost_management/allocation/tag_pipelines.md b/hugo/content/es/cloud_cost_management/allocation/tag_pipelines.md new file mode 100644 index 00000000000..5f8a929579d --- /dev/null +++ b/hugo/content/es/cloud_cost_management/allocation/tag_pipelines.md @@ -0,0 +1,123 @@ +--- +aliases: +- /es/cloud_cost_management/tag_pipelines/ +- /es/cloud_cost_management/tags/tag_pipelines/ +further_reading: +- link: /cloud_cost_management/ + tag: Documentación + text: Obtenga información sobre Cloud Cost Management +- link: /getting_started/tagging/ + tag: Documentación + text: Primeros pasos con las etiquetas +- link: /integrations/guide/reference-tables + tag: Documentación + text: Obtenga información sobre las Reference Tables +- link: https://www.datadoghq.com/blog/cloud-cost-management-ai-costs/ + tag: Blog + text: Atribuya los costos de IA entre proveedores con Datadog Cloud Cost Management +- link: https://www.datadoghq.com/blog/cloud-cost-management-oci + tag: Blog + text: Administre y optimice sus costos de OCI con Datadog Cloud Cost Management +title: Tag Pipelines +--- +## Descripción general {#overview} + +Las etiquetas son la base para todo el análisis y la asignación de Cloud Cost Management. Le permiten desglosar los gastos por servicio, equipo, proyecto, entorno o cualquier dimensión relevante para su negocio. Tag Pipelines aplican el uso de etiquetas estandarizadas en sus recursos en la nube y ayudan a garantizar una atribución de costos precisa y coherente en toda su organización. + +Con [Tag Pipelines][1], puede crear reglas de etiquetas para solucionar las etiquetas faltantes o incorrectas en sus facturas de la nube. También puede crear nuevas etiquetas inferidas que se alineen con una lógica de negocio específica para mejorar la precisión de su seguimiento de costos. Estas etiquetas estandarizadas potencian todas las capacidades de análisis de costos, incluida la asignación de costos de contenedor, las reglas de asignación personalizadas y las recomendaciones de costos. + +Tag Pipelines se aplican a las métricas de Cloud Cost de todos los proveedores. Las reglas que cree afectan a todos los datos de costos y recomendaciones de costos, garantizando la coherencia en los dashboards, monitores y los informes de asignación. + +Cuando se modifican las Tag Pipelines, las nuevas reglas se aplican automáticamente a los datos de los últimos tres meses. La actualización de los datos históricos puede tardar hasta 24 horas en completarse después de agregar o modificar reglas. + +Todos los usuarios nuevos tienen habilitada de forma predeterminada la regla recomendada para [activar la normalización de etiquetas][6]. + +## Crear un conjunto de reglas {#create-a-ruleset} + +Puede administrar los conjuntos de reglas de Tag Pipelines mediante la [API][7], [Terraform][8] o directamente en Datadog siguiendo las instrucciones a continuación. + +Para crear un conjunto de reglas, navegue a [{{< ui >}}Cloud Cost{{< /ui >}} > {{< ui >}}Settings{{< /ui >}} > {{< ui >}}Tag Pipelines{{< /ui >}}][1]. + +
Puede crear hasta 100 reglas. Las tablas de referencia basadas en API no son compatibles.
+ +Antes de crear reglas individuales, cree un conjunto de reglas (una carpeta para sus reglas) haciendo clic en {{< ui >}}+ New Ruleset{{< /ui >}}. + +Dentro de cada conjunto de reglas, haga clic en {{< ui >}}+ Add New Rule{{< /ui >}} y seleccione un tipo de regla: {{< ui >}}Add tag{{< /ui >}}, {{< ui >}}Alias tag keys{{< /ui >}} o {{< ui >}}Map multiple tags{{< /ui >}}. Estas reglas se ejecutan en un orden secuencial y determinista de arriba a abajo. + +{{< img src="cloud_cost/pipelines-create-ruleset-1.png" alt="Una lista de reglas de etiquetas en la página de Tag Pipelines que muestra varias categorías como equipo, cuenta, servicio, departamento, unidad de negocio y más" style="width:60%;" >}} + +Puede organizar las reglas y los conjuntos de reglas para ayudar a garantizar que el orden de ejecución coincida con su lógica de negocio. + +### Agregar etiqueta {#add-tag} + +Agregue una nueva etiqueta (clave + valor) basada en la presencia de etiquetas existentes en sus datos de Cloud Cost. + +Por ejemplo, puede crear una regla para etiquetar todos los recursos con su unidad de negocio según los servicios de los que forman parte esos recursos. + +{{< img src="cloud_cost/pipelines-add-tag-2.png" alt="Agregue una nueva etiqueta de unidad de negocio a los recursos con servicio:process-agent o servicio:process-billing." style="width:60%;" >}} + +En la sección {{< ui >}}Additional options{{< /ui >}}, tiene las siguientes opciones: + +- {{< ui >}}Action when tag `{tag}` exists{{< /ui >}} - Elija qué hacer si la etiqueta especificada (`business-unit` en el ejemplo anterior) ya existe: + - {{< ui >}}Don't apply the rule{{< /ui >}} - Omite la regla si la etiqueta ya existe, conservando el valor original. + - {{< ui >}}Append the tag{{< /ui >}} - Agrega el nuevo valor a la etiqueta existente sin eliminar el valor original. + - {{< ui >}}Replace the tag{{< /ui >}} - Reemplaza el valor de la etiqueta existente con el nuevo valor.
El reemplazo de etiquetas puede sobrescribir los datos existentes. Use esta opción con precaución.
+- {{< ui >}}Apply case-insensitive matching to resource tags{{< /ui >}} - Permite que las etiquetas definidas en el campo `To resources with tag(s)` y las etiquetas de los datos de costos no distingan entre mayúsculas y minúsculas. Por ejemplo, si las etiquetas de recursos de la interfaz de usuario son: `foo:bar` y la etiqueta de los datos de costos es `Foo:bar`, entonces ambas pueden coincidir. + +### Alias de claves de etiqueta {#alias-tag-keys} + +Asigne los valores de etiqueta existentes a una etiqueta más estandarizada. + +Por ejemplo, si su organización desea utilizar la clave de etiqueta `application` estándar, pero varios equipos tienen una variación de esa etiqueta (como `app`, `webapp` o `apps`), puede crear un alias de `apps` a `application`. Cada regla de etiqueta de alias le permite asignar un máximo de 25 claves de etiqueta a una nueva etiqueta. + +{{< img src="cloud_cost/pipelines-alias-tag-4.png" alt="Agregue la etiqueta de aplicación a los recursos con la etiqueta app, webapp o apps." style="width:60%;" >}} + +Agregue la etiqueta de aplicación a los recursos con las etiquetas `app`, `webapp` o `apps`. La regla deja de ejecutarse para cada recurso después de encontrar la primera coincidencia. Por ejemplo, si un recurso ya tiene una etiqueta `app`, entonces la regla ya no intenta identificar una etiqueta `webapp` o `apps`. + +En la sección {{< ui >}}Additional options{{< /ui >}}, tiene las siguientes opciones: + +- {{< ui >}}Action when tag `{tag}` exists{{< /ui >}} - Elija qué hacer si la etiqueta especificada (`application` en el ejemplo anterior) ya existe: + - {{< ui >}}Don't apply the rule{{< /ui >}} - Omite la regla si la etiqueta ya existe, conservando el valor original. + - {{< ui >}}Append the tag{{< /ui >}} - Agrega el nuevo valor a la etiqueta existente sin eliminar el valor original. + - {{< ui >}}Replace the tag{{< /ui >}} - Reemplaza el valor de la etiqueta existente con el nuevo valor.
El reemplazo de etiquetas puede sobrescribir los datos existentes. Use esta opción con precaución.
+- {{< ui >}}Apply case-insensitive matching to resource tags{{< /ui >}} - Permite que las etiquetas definidas en las claves de etiqueta de alias y las etiquetas de los datos de costos no distingan entre mayúsculas y minúsculas. Por ejemplo, si las etiquetas de recursos de la interfaz de usuario son: `app:bar` y la etiqueta de los datos de costos es `App:bar`, entonces ambas pueden coincidir. + +### Asignar varias etiquetas {#map-multiple-tags} + +Use [Reference Tables][2] para agregar varias etiquetas a los datos de costos sin crear varias reglas. Esto asigna los valores de la columna de clave principal de su Reference Table a los valores de las etiquetas de costos. Si se encuentra, la canalización agrega las columnas de la Reference Table seleccionada como etiquetas a los datos de costos. + +Por ejemplo, si desea agregar información sobre a qué vicepresidencias, organizaciones y unidades de negocio pertenecen las diferentes cuentas de AWS y Azure, puede crear una tabla y asignar las etiquetas. + +{{< img src="cloud_cost/pipelines-map-multiple-tags-2.png" alt="Agregue metadatos de cuenta como customer_name usando Reference Tables para Tag Pipelines" style="width:60%;" >}} + +Similar a [Alias tag keys](#alias-tag-keys), la regla deja de ejecutarse para cada recurso después de encontrar la primera coincidencia. Por ejemplo, si se encuentra un `application`, entonces la regla ya no intenta encontrar un `subscription_id`. + +En la sección {{< ui >}}Additional options{{< /ui >}}, tiene las siguientes opciones: + +- {{< ui >}}Action when column exists{{< /ui >}} - Elija qué hacer si las columnas especificadas ya existen: + - {{< ui >}}Don't apply the rule{{< /ui >}} - Omite la regla si las columnas ya existen, conservando los valores originales. + - {{< ui >}}Append the column{{< /ui >}} - Agrega los nuevos valores a las columnas existentes sin eliminar los valores originales. + - {{< ui >}}Replace the column{{< /ui >}} - Reemplaza los valores de columna existentes con los nuevos valores.
Reemplazar columnas puede sobrescribir datos existentes. Use esta opción con precaución.
+- {{< ui >}}Apply case-insensitive matching for primary key values{{< /ui >}} - Habilita la coincidencia sin distinción entre mayúsculas y minúsculas entre el valor de la clave principal de la tabla de referencia y el valor de la etiqueta en los datos de costos donde la clave de etiqueta coincide con la clave principal. Por ejemplo, si el par de valores de clave principal de la interfaz de usuario es `foo:Bar` y la etiqueta de los datos de costos es `foo:bar`, entonces ambos pueden coincidir. + +## Reserved tags {#reserved-tags} + +Ciertas etiquetas como `env` y `host` son [reserved tags][4] y forman parte del [Unified Service Tagging][3]. La etiqueta `host` no se puede agregar en Tag Pipelines. + +El uso de etiquetas ayuda a correlacionar sus métricas, traces, procesos y logs. Reserved tags como `host` brindan visibilidad y un monitoreo efectivo en toda su infraestructura. Para obtener una correlación óptima y insights accionables, utilice estas etiquetas reservadas como parte de su tagging strategy en Datadog. + +## Eliminar etiquetas {#delete-tags} +Para eliminar una etiqueta creada mediante Tag Pipelines, elimine la regla que la creó. En un plazo de 24 horas, la etiqueta se elimina automáticamente de los datos de los últimos tres meses. Para eliminar la etiqueta de datos más antiguos, comuníquese con el [soporte de Datadog][5]. + +## Lecturas adicionales {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://app.datadoghq.com/cost/tag-pipelines +[2]: /es/integrations/guide/reference-tables/?tab=manualupload +[3]: /es/getting_started/tagging/unified_service_tagging/ +[4]: /es/getting_started/tagging/ +[5]: /es/help/ +[6]: /es/cloud_cost_management/tags#how-tags-are-normalized +[7]: /es/api/latest/cloud-cost-management/#create-tag-pipeline-ruleset +[8]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/tag_pipeline_ruleset \ No newline at end of file diff --git a/hugo/content/es/cloud_cost_management/setup/azure.md b/hugo/content/es/cloud_cost_management/setup/azure.md index a2f3f585a62..a8a7fb5a494 100644 --- a/hugo/content/es/cloud_cost_management/setup/azure.md +++ b/hugo/content/es/cloud_cost_management/setup/azure.md @@ -7,251 +7,348 @@ further_reading: text: Cloud Cost Management - link: /cloud_cost_management/setup/aws tag: Documentación - text: Obtener información sobre tu factura de AWS + text: Obtenga información sobre su factura de AWS - link: /cloud_cost_management/setup/google_cloud tag: Documentación - text: Obtener información sobre tu factura de Google Cloud + text: Obtenga información sobre su factura de Google Cloud - link: /cloud_cost_management/oracle tag: Documentación - text: Obtén información sobre tu factura de Oracle + text: Obtenga información sobre su factura de Oracle title: Azure --- +## Descripción general {#overview} +Para usar Azure Cloud Cost Management en Datadog, debe configurar la integración de Datadog Azure y crear exportaciones de **Costo amortizado** y **Costo real** en Azure. Además, Datadog debe tener permisos para leer las exportaciones del contenedor. -## Información general +Datadog proporciona visibilidad de costos a nivel de suscripción, grupo de recursos y cuenta de facturación. Los acuerdos de cliente de Microsoft (MCA) se pueden configurar en los tres contextos. Para determinar su tipo de cuenta, consulte la [documentación de Azure][10]. -Para utilizar Azure Cloud Cost Management en Datadog, debes configurar la integración de Azure y Datadog y crear exportaciones **amortizadas** y **actuales** en Azure. Además, Datadog debe tener permisos para leer las exportaciones del contenedor. +
+Cuentas de pago por uso (PAYG) +

Datadog Cloud Cost Management requiere exportaciones de Costo real y Costo amortizado desde Azure. Las suscripciones PAYG (Microsoft Online Services Program) generalmente solo proporcionan exportaciones de Detalles de uso (solo uso), por lo que no se pueden configurar para CCM. Para conocer los tipos de exportación disponibles para cada tipo de cuenta de Azure, consulte la documentación de exportaciones de Cost Management de Microsoft.

+

Si su suscripción es PAYG, considere una de las siguientes opciones:

+
    +
  • Migre a un Contrato de cliente de Microsoft (MCA) o un Contrato Enterprise (EA), los cuales admiten los tipos de exportación requeridos.
    • +
  • Comuníquese con el soporte de Microsoft Azure para confirmar los tipos de exportación disponibles para su suscripción.
    • +
+

Para obtener ayuda con la configuración de Datadog CCM o para discutir opciones, comuníquese con el soporte de Datadog.

+
-Datadog proporciona visibilidad de costes a nivel de suscripción, grupo de recursos y cuenta de facturación. Los contratos de cliente de Microsoft (MCA) pueden establecerse en los tres ámbitos. Las cuentas de pago por uso (PAYG) están en fase de vista previa. Ponte en contacto con el [soporte de Datadog][11] si tienes algún problema con la configuración. +## Configuración {#setup} -Para determinar tu tipo de cuenta, consulta la [documentación de Azure][10]. **Nota:** Si tu tipo de cuenta aparece como "Microsoft Online Services Program", entonces tu cuenta es de pago por uso (PAYG). - -## Configuración - -Puedes configurarlo utilizando la [API][13], [Terraform][14], o directamente en Datadog siguiendo las instrucciones que se indican a continuación. +Puede realizar la configuración mediante la [API][13], [Terraform][14] o directamente en Datadog siguiendo las instrucciones a continuación. {{% site-region region="us3" %}} -**Nota**: Si estás utilizando el sitio **US3**, es posible que hayas configurado la integración de Datadog Azure Native utilizando el [método de recurso de Datadog][1] a través del portal de Azure. Para admitir Cloud Cost Management, necesitas [crear un registro de aplicación][2]. +**Nota**: Si está utilizando el sitio **US3** de Datadog, es posible que haya configurado la integración nativa de Datadog Azure mediante el [método de recursos de Datadog][1] a través de Azure Portal. Para admitir Cloud Cost Management, debe [crear un registro de aplicación][2]. [1]: https://www.datadoghq.com/blog/azure-datadog-partnership/ [2]: /es/integrations/azure/?tab=azurecliv20#setup {{% /site-region %}} -### Configurar la integración de Azure -Ve a [Ajustes y configuración][3] y selecciona una cuenta de Azure en el menú para obtener los costes. Si no ves tu cuenta de Azure en la lista, consulta [integración de Azure][4] para añadirla. +### Configure la integración de Azure {#configure-the-azure-integration} +Navegue a [Setup & Configuration][3], agregue una cuenta de Azure y siga los pasos para configurar la integración de Azure. -### Generar exportaciones de costes +{{< tabs >}} -Necesitas generar exportaciones para dos tipos de datos: **actual** y **amortizado**. Datadog recomienda utilizar el mismo contenedor de almacenamiento para ambas exportaciones. +{{% tab "Terraform" %}} -1. Ve a [Cost Management | Configuration][5] (Gestión de costes | Configuración) en **Tools** > **Cost Management** > **Settings** > **Configuration** (Herramientas > Gestión de costes > Ajustes > Configuración) en el portal de Azure y, luego, haz clic en **Exports** (Exportaciones). - {{< img src="cloud_cost/azure_export_path.png" alt="En el portal de Azure la opción Exportaciones resaltada en la navegación" style="width:100%" >}} -2. Selecciona el ámbito de exportación situado junto al filtro de búsqueda. +{{< img src="cloud_cost/setup/azure_terraform_setup.png" alt="Página de configuración de CCM con la opción Terraform seleccionada, mostrando el paso 1 y el paso 2 expandidos para configurar el contexto y los detalles de exportación" style="width:100%" >}} - **Nota:** El ámbito debe ser **cuenta de facturación**, **suscripción** o **grupo de recursos**. -3. Una vez seleccionado el ámbito, haz clic en **Schedule export** (Programar horario de exportación). +### Seleccione el tipo de contexto {#select-scope-type} - {{< img src="cloud_cost/azure_exports_page.png" alt="En el portal de Azure, el botón de ámbito de exportación y programar horario resaltado" style="width:100%" >}} +Use el menú desplegable para seleccionar el tipo de contexto para su cuenta. CCM admite los tipos de contexto de cuenta de facturación, suscripción y grupo de recursos. -4. Selecciona la plantilla **Cost and usage (actual + amortized)** (Coste y uso (real + amortizado)). - {{< img src="cloud_cost/azure_new_export.png" alt="Nueva página de exportación con la plantilla y las opciones manuales resaltadas" style="width:100%" >}} +### Seleccione los recursos a crear {#select-the-resources-to-create} -5. Haz clic en **Edit** (Editar) en cada exportación y confirma los siguientes datos: - - Frecuencia: **Exportación diaria de los costes del mes hasta la fecha** - - Versión del conjunto de datos: - - Versiones compatibles: `2021-10-01`, `2021-01-01`, `2020-01-01` - - Versiones no compatibles: `2019-10-01` - {{< img src="cloud_cost/improved_export.png" alt="Detalles de exportación con Métrica: Actual, Tipo de exportación: Diaria y Versión del conjunto de datos" style="width:100%" >}} +La configuración de Terraform admite tres configuraciones según sus recursos de Azure existentes: -6. Introduce un "Prefijo de exportación" para las nuevas exportaciones. Por ejemplo, introduce `datadog` para evitar conflictos con las exportaciones existentes. +* **Nueva configuración**: Seleccione {{< ui >}}Create storage account and container{{< /ui >}} para crear una cuenta de almacenamiento, un contenedor y exportaciones de costos. +* **Cuenta de almacenamiento y contenedor existentes**: Deseleccione {{< ui >}}Create storage account and container{{< /ui >}} y seleccione {{< ui >}}Create cost exports{{< /ui >}} para usar el almacenamiento existente pero crear nuevas exportaciones de costos. +* **Cuenta de almacenamiento, contenedor y exportaciones de costos existentes**: Deseleccione ambas opciones para usar el almacenamiento y las exportaciones de costos existentes. -7. En la pestaña **Destination** (Destino), selecciona los siguientes detalles: - - Elige **Azure blob storage** como tipo de almacenamiento. - - Elige una cuenta de almacenamiento, contenedor y un directorio para las exportaciones. - - **Nota:** No utilices caracteres especiales como `.` en estos campos. - - **Nota:** Las exportaciones de facturación pueden almacenarse en cualquier suscripción. Si creas exportaciones para varias suscripciones, Datadog recomienda almacenarlas en la misma cuenta de almacenamiento. Los nombres de las exportaciones deben ser únicos. - - Elige **CSV** o **Parquet** como formato. - - Elige el tipo de compresión. Para **CSV**: **Gzip** y **None** (Ninguno) son compatibles. Para **Parquet**: **Snappy** y **None** (Ninguno). - - Asegúrate de que está marcada la opción **File partitioning** (Partición de archivos). - - Asegúrate de que **Overwrite data** (Sobrescribir datos) no está marcado. - - **Nota:** Datadog no es compatible con el ajuste Sobrescribir datos. Si el ajuste estaba marcado anteriormente, asegúrate de limpiar los archivos del directorio o moverlos a otro. +### Configure el contexto y los detalles de exportación {#configure-the-scope-and-export-details} - {{< img src="cloud_cost/improved_export_destination_2.png" alt="Destino de exportación con partición de archivos y los ajustes de Sobreescribir datos" >}} +Ingrese los siguientes detalles para su configuración: -8. En la pestaña **Review + create** (Revisar+ crear), selecciona **Create** (Crear). -9. Para procesar más rápido, genera las primeras exportaciones manualmente haciendo clic en **Run Now** (Ejecutar ahora). +* {{< ui >}}Billing account or Subscription ID{{< /ui >}}: Dependiendo del contexto seleccionado en el paso 1, el ID de cuenta de facturación o el ID de suscripción correspondiente. +* {{< ui >}}Resource group name{{< /ui >}}: El nombre de su grupo de recursos existente en el contexto seleccionado. Se requiere un grupo de recursos preexistente para la configuración de Terraform. +* {{< ui >}}Location{{< /ui >}}: La ubicación de Azure de su grupo de recursos. Por ejemplo, `East US 2`. +* {{< ui >}}Storage account and container name{{< /ui >}}: Dependiendo de los recursos que haya seleccionado crear, los nombres de su cuenta de almacenamiento y contenedor nuevos o preexistentes. +* {{< ui >}}Actual cost export name and path{{< /ui >}}: El nombre y la ruta de su exportación de costos reales. +* {{< ui >}}Amortized cost export name and path{{< /ui >}}: El nombre y la ruta de su exportación de costos amortizados. + * **Nota:** Los siguientes formatos de prefijo no son compatibles: vacío, que comience con `/` (como `/` o `/cost`), o que termine con `/` (como `cost/`). Los prefijos que contienen `/` en el medio son compatibles (como `cost/hourly`). -{{< img src="cloud_cost/run_now.png" alt="Haz clic en el botón Ejecutar ahora en el panel lateral de exportación para generar exportaciones" style="width:50%" >}} +### Copie el HCL de Terraform del recurso de Azure generado y aplique los cambios {#copy-generated-azure-resource-terraform-hcl-and-apply-changes} -### Proporcionar acceso a tus exportaciones en Datadog +Después de completar los campos en el Paso 2, el Paso 3 habilita y muestra el HCL de Terraform generado. Siga las instrucciones para configurar sus archivos de configuración de Terraform con este código. Resuelva cualquier problema que aparezca al ejecutar `terraform plan` o `terraform apply` antes de regresar a CCM para configurar las exportaciones de costos. + +### Acceda a la consola de Azure para configurar las exportaciones {#access-azure-console-to-configure-exports} + +{{< img src="cloud_cost/setup/azure_toggle_file_partitioning.png" alt="Active la partición de archivos para ambas exportaciones" style="width:50%" >}} + +Abra el enlace de la consola de Azure para localizar sus exportaciones de costos. Si es necesario, cambie el contexto actual al correcto para sus exportaciones. Para ambas exportaciones, la real y la amortizada, selecciónelas y haga clic en {{< ui >}}Edit{{< /ui >}} para activar la partición de archivos si aún no está habilitada. + +{{< img src="cloud_cost/run_now.png" alt="Haga clic en el botón Ejecutar ahora en el panel lateral de exportación para generar las exportaciones" style="width:50%" >}} + +Guarde los cambios de la partición de archivos y haga clic en {{< ui >}}Run Now{{< /ui >}}. Regrese a CCM una vez que ambas ejecuciones de exportación se hayan realizado correctamente. + +### Copie el HCL de Datadog generado y aplique los cambios {#copy-generated-datadog-hcl-and-apply-changes} + +Siga las instrucciones en el paso {{< ui >}}Apply Datadog Terraform HCL{{< /ui >}}. Resuelva cualquier problema que aparezca al ejecutar `terraform plan` o `terraform apply` antes de regresar a CCM para confirmar la creación de la cuenta. -{{< tabs >}} -{{% tab "Facturación Cuentas" %}} - -1. En la pestaña Exportaciones, haz clic en la Cuenta de almacenamiento de la exportación para navegar hasta ella. -2. Haz clic en la pestaña Containers (Contenedores). -3. Elige el contenedor de almacenamiento en el que se encuentran tus facturas. -4. Selecciona la pestaña Control de acceso (IAM) y haz clic en **Add** (Añadir). -5. Selecciona **Add role assignment** (Añadir la asignación de roles). -6. Elige **Storage Blob Data Reader** (Lector de datos de bloque de almacenamiento) y haz clic en Next (Siguiente). -7. Asigna estos permisos a uno de los Registros de aplicaciones que hayas conectado con Datadog. - - Haz clic en **Select members** (Seleccionar miembros), elige el nombre del registro de aplicación y haz clic en **Select** (Seleccionar). **Nota**: Si no ves tu registro de aplicación en la lista, empieza a escribir el nombre para que la interfaz de usuario se actualice y la muestre, si está disponible. - - Selecciona **Review + assign** (Revisar + asignar). - -Si tus exportaciones se encuentran en contenedores de almacenamiento diferentes, repite los pasos del uno al siete para el otro contenedor de almacenamiento. {{% /tab %}} -{{% tab "Suscripciones y grupos de recursos" %}} +{{% tab "Manual" %}} + +{{< img src="cloud_cost/setup/azure_manual_setup.png" alt="Página de configuración de CCM con la opción Manual seleccionada, mostrando el Paso 1 y el Paso 2 expandidos para configurar el tipo de contexto y seleccionar las exportaciones existentes" style="width:100%" >}} + +### Genere exportaciones de costos {#generate-cost-exports} + +Debe generar exportaciones para dos tipos de datos: **real** y **amortizado**. Datadog recomienda usar el mismo contenedor de almacenamiento para ambas exportaciones. + +1. Navegue a [Cost Management | Configuration][5] en {{< ui >}}Tools{{< /ui >}} > {{< ui >}}Cost Management{{< /ui >}} > {{< ui >}}Settings{{< /ui >}} > {{< ui >}}Configuration{{< /ui >}} del portal de Azure y haga clic en {{< ui >}}Exports{{< /ui >}}. + {{< img src="cloud_cost/azure_export_path.png" alt="En el portal de Azure resaltando la opción Exportaciones en la navegación" style="width:100%" >}} +2. Seleccione el contexto de exportación ubicado junto al filtro de búsqueda. + + **Nota:** El contexto debe ser {{< ui >}}billing account{{< /ui >}}, {{< ui >}}subscription{{< /ui >}} o {{< ui >}}resource group{{< /ui >}}. +3. Después de seleccionar el contexto, haga clic en {{< ui >}}Schedule export{{< /ui >}}. + + {{< img src="cloud_cost/azure_exports_page.png" alt="En el portal de Azure resaltando el contexto de exportación y el botón de programación" style="width:100%" >}} + +4. Seleccione la plantilla {{< ui >}}Cost and usage (actual + amortized){{< /ui >}} + {{< img src="cloud_cost/azure_new_export.png" alt="Página de nueva exportación con las opciones de plantilla y manual resaltadas" style="width:100%" >}} + +5. Haga clic en {{< ui >}}Edit{{< /ui >}} en cada exportación y confirme los siguientes detalles: + - Frecuencia: {{< ui >}}Daily export of month-to-date costs{{< /ui >}} + - Control de versiones de conjuntos de datos: + - Versiones admitidas: `2021-10-01`, `2021-01-01`, `2020-01-01` + - Versiones no admitidas: `2019-10-01` + {{< img src="cloud_cost/improved_export.png" alt="Detalles de exportación con métrica: Actual, tipo de exportación: diaria y control de versiones de conjuntos de datos" style="width:100%" >}} + +6. Ingrese un "Prefijo de exportación" para las nuevas exportaciones. Por ejemplo, ingrese `datadog` para evitar conflictos con exportaciones existentes. -1. En la pestaña Exportaciones, haz clic en la Cuenta de almacenamiento de la exportación para navegar hasta ella. -2. Haz clic en la pestaña Containers (Contenedores). -3. Elige el contenedor de almacenamiento en el que se encuentran tus facturas. -4. Selecciona la pestaña Control de acceso (IAM) y haz clic en **Add** (Añadir). -5. Selecciona **Add role assignment** (Añadir la asignación de roles). -6. Elige **Storage Blob Data Reader** (Lector de datos de bloque de almacenamiento) y haz clic en Next (Siguiente). -7. Asigna estos permisos a uno de los Registros de aplicaciones que hayas conectado con Datadog. - - Haz clic en **Select members** (Seleccionar miembros), elige el nombre de Registro de la aplicación y haz clic en **Select** (Seleccionar). - - Selecciona **Review + assign** (Revisar + asignar). +7. En la pestaña {{< ui >}}Destination{{< /ui >}}, seleccione los siguientes detalles: + - Elija {{< ui >}}Azure blob storage{{< /ui >}} como tipo de almacenamiento. + - Elija una cuenta de almacenamiento, un contenedor y un directorio para las exportaciones. + - **Nota:** No utilice caracteres especiales como `.` en estos campos. + - **Nota:** Las exportaciones de facturación pueden almacenarse en cualquier suscripción. Si está creando exportaciones para varias suscripciones, Datadog recomienda almacenarlas en la misma cuenta de almacenamiento. Los nombres de las exportaciones deben ser únicos. + - Elija {{< ui >}}CSV{{< /ui >}} o {{< ui >}}Parquet{{< /ui >}} como formato. + - Elija el tipo de compresión. Para {{< ui >}}CSV{{< /ui >}}: se admiten {{< ui >}}Gzip{{< /ui >}} y {{< ui >}}None{{< /ui >}}. Para {{< ui >}}Parquet{{< /ui >}}: se admiten {{< ui >}}Snappy{{< /ui >}} y {{< ui >}}None{{< /ui >}}. + - Asegúrese de que {{< ui >}}File partitioning{{< /ui >}} esté marcado. + - Asegúrese de que {{< ui >}}Overwrite data{{< /ui >}} no esté marcado. + - **Nota:** Datadog no admite la configuración {{< ui >}}Overwrite data{{< /ui >}}. Si la configuración estaba marcada anteriormente, asegúrese de limpiar los archivos en el directorio o moverlos a otro. -Si tus exportaciones se encuentran en contenedores de almacenamiento diferentes, repite los pasos del uno al siete para el otro contenedor de almacenamiento. + {{< img src="cloud_cost/improved_export_destination_2.png" alt="Destino de exportación con configuraciones de partición de archivos y sobrescritura de datos" >}} -### Configura el Acceso de lector de gestión de costes -**Nota:** No necesitas configurar este acceso si tu contexto es **Cuenta de facturación**. +8. En la pestaña {{< ui >}}Review + create{{< /ui >}}, seleccione {{< ui >}}Create{{< /ui >}}. +9. Genere los primeros exports manualmente haciendo clic en {{< ui >}}Run Now{{< /ui >}}. Espere a que se complete correctamente antes de continuar. -1. Navega hasta tus [suscripciones][1] y haz clic en el nombre de tu suscripción. -2. Selecciona la pestaña Control de acceso (IAM). -3. Haz clic en **Add** (Añadir) y, a continuación, en **Add role assignment** (Añadir asignación de roles). -4. Selecciona **Cost Management Reader** (Lector de gestión de costes) y, a continuación, haz clic en Next (Siguiente). -5. Asigna estos permisos al registro de la aplicación. +{{< img src="cloud_cost/run_now.png" alt="Haga clic en el botón Ejecutar ahora en el panel lateral de exportación para generar las exportaciones" style="width:50%" >}} -De este modo se garantiza la total exactitud de los costes al permitir cálculos periódicos de costes con Microsoft Cost Management. +### Proporcione a Datadog acceso a sus exports {#provide-datadog-access-to-your-exports} +Otorgue a Datadog acceso de lectura a la cuenta de almacenamiento donde se guardan sus exports. -**Nota**: Los datos pueden tardar entre 48 y 72 horas en estabilizarse en Datadog. +{{% collapse-content title="Cuentas de facturación" level="h4" %}} + +1. En la pestaña Exports, haga clic en la cuenta de almacenamiento de la exportación para navegar a ella. +2. Haga clic en la pestaña Containers. +3. Elija el contenedor en el que se encuentran sus facturas. +4. Seleccione la pestaña {{< ui >}}Access Control (IAM){{< /ui >}} y haga clic en {{< ui >}}Add{{< /ui >}}. +5. Elija {{< ui >}}Add role assignment{{< /ui >}}. +6. Elija {{< ui >}}Storage Blob Data Reader{{< /ui >}}, luego haga clic en {{< ui >}}Next{{< /ui >}}. +7. Asigne estos permisos a uno de los registros de la aplicación que haya conectado con Datadog. + - Haga clic en {{< ui >}}Select members{{< /ui >}}, seleccione el nombre del registro de la aplicación y haga clic en {{< ui >}}Select{{< /ui >}}. **Nota**: Si no ve su registro de la aplicación en la lista, comience a escribir el nombre para que la interfaz se actualice y lo muestre, si está disponible. + - Seleccione {{< ui >}}Review + assign{{< /ui >}}. + +Si sus exports están en diferentes contenedores de almacenamiento, repita los pasos del uno al siete para el otro contenedor de almacenamiento. + +{{% /collapse-content %}} +{{% collapse-content title="Suscripciones y grupos de recursos" level="h4" %}} +1. En la pestaña Exports, haga clic en la cuenta de almacenamiento de la exportación para navegar a ella. +2. Haga clic en la pestaña Containers. +3. Elija el contenedor en el que se encuentran sus facturas. +4. Seleccione la pestaña {{< ui >}}Access Control (IAM){{< /ui >}} y haga clic en {{< ui >}}Add{{< /ui >}}. +5. Elija {{< ui >}}Add role assignment{{< /ui >}}. +6. Elija {{< ui >}}Storage Blob Data Reader{{< /ui >}}, luego haga clic en {{< ui >}}Next{{< /ui >}}. +7. Asigne estos permisos a uno de los registros de la aplicación que haya conectado con Datadog. + - Haga clic en {{< ui >}}Select members{{< /ui >}}, seleccione el nombre del registro de la aplicación y haga clic en {{< ui >}}Select{{< /ui >}}. + - Seleccione {{< ui >}}Review + assign{{< /ui >}}. + +Si sus exports están en diferentes contenedores de almacenamiento, repita los pasos del uno al siete para el otro contenedor de almacenamiento. +{{% /collapse-content %}} + +### Configure el acceso de lector de Cloud Cost Management {#configure-cost-management-reader-access} +**Nota:** No necesita configurar este acceso si su contexto es {{< ui >}}Billing Account{{< /ui >}}. + +1. Vaya a sus [suscripciones][1] y haga clic en el nombre de su suscripción. +2. Seleccione la pestaña {{< ui >}}Access Control (IAM){{< /ui >}}. +3. Haga clic en {{< ui >}}Add{{< /ui >}}, luego en {{< ui >}}Add role assignment{{< /ui >}}. +4. Elija {{< ui >}}Cost Management Reader{{< /ui >}}, luego haga clic en {{< ui >}}Next{{< /ui >}}. +5. Asigne estos permisos al registro de la aplicación. + +Esto ayuda a garantizar una precisión total de los costos al permitir cálculos de costos periódicos en Microsoft Cost Management. + +**Nota**: Los datos pueden tardar entre 48 y 72 horas después de la configuración en estabilizarse en Datadog. [1]: https://portal.azure.com/#view/Microsoft_Azure_Billing/SubscriptionsBlade {{% /tab %}} {{< /tabs >}} -**Nota**: Si tienes los permisos adecuados en el registro de la aplicación, pero tu red está bloqueando las IPs de webhook de Datadog, puedes encontrar errores que parecen estar relacionados con el permiso. -Para resolver esto, añade las IPs de webhook de Datadog a tu lista de permisos de red visitando la sección `Webhooks` en `https://ip-ranges.`{{< region-param key="dd_site" code="true" >}}. -### Configurar el coste de nube en Datadog -Ve a [Configuración][3] y sigue los pasos. +**Nota**: Si tiene los permisos adecuados en el registro de la aplicación pero su red está bloqueando las IP de webhook de Datadog, es posible que encuentre errores que parecen estar relacionados con los permisos. + +Para resolver esto, agregue las IP de webhook de Datadog a su lista de permitidos de red visitando la sección `Webhooks` en `https://ip-ranges.`{{< region-param key="dd_site" code="true" >}}. + +### Configure Cloud Cost en Datadog {#configure-cloud-cost-in-datadog} +Vaya a [Setup & Configuration][3] y siga los pasos. + +### Realice la migración de exports de un EA a un MCA {#migrate-exports-from-an-ea-to-an-mca} + +Azure no migra automáticamente las definiciones de exports de costos de un Contrato Enterprise (EA) a un Contrato de Cliente de Microsoft (MCA). Para obtener más información, consulte la [documentación de incorporación de MCA][15] de Microsoft. + +El siguiente proceso conserva los datos históricos de EA para las configuraciones de Datadog que utilizan un contexto de cuenta de facturación, suscripción o grupo de recursos. + +1. Registre la siguiente configuración para los exports de EA tanto reales como amortizados: + * Nombre del export, incluyendo mayúsculas y minúsculas + * Cuenta de almacenamiento + * Contenedor + * Directorio de almacenamiento y prefijo del export + * Versión del conjunto de datos, formato y tipo de compresión +1. Después de que se ejecuten los exports finales del período de EA, deshabilite los exports programados de EA, pero mantenga sus definiciones. No permita que los exports programados de EA y MCA escriban en el mismo destino al mismo tiempo. +1. Deje la configuración de Azure Cloud Cost Management en Datadog habilitada y sin cambios. Para un contexto de cuenta de facturación, Datadog conserva el ID de EA. +1. Después de que el MCA se vuelva activo, vuelva a crear los exports reales y amortizados en el contexto de MCA correspondiente utilizando Terraform o el portal de Azure. Utilice los nombres del export, la cuenta de almacenamiento, el contenedor, el directorio y el prefijo registrados de los exports de EA. + * Para Terraform, siga el [flujo de configuración de Terraform][19] a través de los pasos de HCL de recursos de Azure. No aplique nuevo HCL de Datadog ni reemplace la configuración existente de Cloud Cost Management. + * Para el portal de Azure, siga las [instrucciones de export de costos manuales][17]. + +Datadog continúa leyendo los archivos históricos de EA desde el destino existente y agrega datos de MCA al mismo historial de costos. + +
+No complete fechas de EA desde un contexto de MCA +

Un export de MCA no incluye costos del EA anterior. Ejecutar un export de MCA único para un rango de fechas de EA puede escribir un manifiesto vacío más reciente en el destino compartido. Datadog lee el export más reciente de cada mes, por lo que el manifiesto vacío puede poner en cero los datos de EA que se ingirieron anteriormente.

+
+ +Para completar datos después de una migración de EA a MCA, utilice el acuerdo que cubrió las fechas solicitadas: + +* Para fechas anteriores a la fecha de vigencia de MCA, ejecute los exports únicos reales y amortizados desde el contexto de EA anterior. +* Para fechas en o después de la fecha de vigencia de MCA, ejecute las exportaciones únicas reales y amortizadas desde el contexto de MCA. + +Si el contexto de EA anterior no está disponible, comuníquese con el Soporte de Microsoft para solicitar los exports históricos. Si cambió un nombre o destino de export, o eliminó y volvió a crear la configuración de Datadog, comuníquese con [Soporte de Datadog][16]. No cree exports adicionales únicos o programados hasta que el Soporte de Datadog revise la configuración. + +### Obtención de datos históricos {#getting-historical-data} -### Obtener datos históricos +Azure exporta datos de costos a partir del mes en que creó el export. Datadog ingiere automáticamente hasta 15 meses de datos de costos históricos disponibles de estos exports. Puede rellenar manualmente hasta 12 meses de datos de costos de Azure utilizando la interfaz de usuario de Azure Cost Exports. -Azure exporta datos de costes a partir del mes en que se creó la exportación. Datadog incorpora automáticamente hasta 15 meses de datos de costes históricos disponibles a partir de estas exportaciones. Puedes rellenar manualmente hasta 12 meses de datos de costes de Azure mediante la interfaz de usuario de Azure Cost Exports. +**Nota**: Si migró de un EA a un MCA, siga las [instrucciones de migración][18] antes de ejecutar un export histórico. -1. Completa las instrucciones de las secciones **Setup** (Configuración) y **Configure Cloud Cost in Datadog** (Configurar el coste de nube en Datadog) anteriores. -1. Espera hasta 24 horas a que los datos de costes aparezcan en Datadog para asegurarte de que la integración funciona de principio a fin antes de iniciar el proceso de relleno. **Nota:** Si ya has completado la configuración y los datos de costes aparecen en Datadog, puedes continuar directamente con los pasos de relleno que se indican a continuación. -1. Exporta manualmente un informe **real** y **amortizado** para cada mes calendario. Por ejemplo, para junio de 2025: - 1. Editar la exportación - 2. Cambiar el tipo de exportación a "Exportación única" - 3. Establecer Desde en 06-01-2025 **Nota:** Este debe ser el primer día del mes. - 4. Fijar Fin en 30-06-2025 **Nota:** Debe ser el último día del mes. - 5. Guardar la exportación **Nota:** Esto ejecuta automáticamente la exportación - 6. Esperar a que finalice la exportación -1. Revertir tanto las exportaciones **actuales** como las **amortizadas** a su estado original para reanudar las exportaciones diarias: - 1. Editar la exportación - 2. Cambiar el tipo de exportación a "Exportación diaria de los costes del mes hasta la fecha" - 3. Guardar la exportación +1. Complete las instrucciones en las secciones **Configuración** y **Configurar Cloud Cost en Datadog** anteriores. +1. Espere hasta 24 horas para que los datos de costos aparezcan en Datadog y asegúrese de que la integración funcione de principio a fin antes de comenzar el proceso de backfill. **Nota:** Si ya completó la configuración y los datos de costos aparecen en Datadog, puede proceder directamente a los pasos de backfill a continuación. +1. Exporte manualmente un informe **real** y **amortizado** para cada mes calendario. Por ejemplo, para junio de 2025: + 1. Editar el export + 2. Cambie el tipo de export a {{< ui >}}One-time export{{< /ui >}} + 3. Establezca {{< ui >}}From{{< /ui >}} en 06-01-2025 **Nota:** Este debe ser el primer día del mes. + 4. Establezca {{< ui >}}End{{< /ui >}} en 06-30-2025 **Nota:** Este debe ser el último día del mes. + 5. Guarde el export **Nota:** Esto ejecuta el export automáticamente + 6. Espere a que el export termine de ejecutarse +1. Revierta tanto los exports **reales** como los **amortizados** a su estado original para reanudar los exports diarios: + 1. Editar el export + 2. Cambie el tipo de export a {{< ui >}}Daily export of month-to-date costs{{< /ui >}} + 3. Guarde el export -Datadog detecta e ingiere automáticamente estos datos, que deberían aparecer en Datadog en un plazo de 24 horas. +Datadog descubre e ingiere automáticamente estos datos, y deberían aparecer en Datadog en un plazo de 24 horas. -También puedes crear datos históricos en tu cuenta de almacenamiento utilizando la [API de Microsoft][6] o creando un [tique de soporte con Microsoft][7]. Asegúrate de que la estructura de archivos y la partición siguen el formato de las exportaciones programadas. +También puede crear datos históricos en su cuenta de almacenamiento utilizando el [Microsoft API][6] o creando un [ticket de soporte con Microsoft][7]. Asegúrese de que la estructura de archivos y la partición sigan el formato de las exportaciones programadas. -### Tipos de costes +### Tipos de costo {#cost-types} -Puedes visualizar tus datos ingeridos utilizando los siguientes tipos de costes: +Puede visualizar sus datos ingeridos utilizando los siguientes tipos de costo: -| Tipo de coste | Descripción | +| Tipo de costo | Descripción | | -------------------- | --------------------- | -| `azure.cost.amortized` | Coste basado en los índices de descuento aplicados más la distribución de los prepagos en función del uso durante el plazo de descuento (base devengada).| -| `azure.cost.actual` | El coste se muestra como el importe facturado en el momento del uso (base de efectivo). Los costes reales incluyen descuentos privados, así como descuentos de instancias reservadas y planes de ahorro como tipos de cargos independientes.| -| `azure.cost.discounted.ondemand` | Coste basado en la tarifa de lista proporcionada por Azure, tras descuentos negociados de forma privada. Para obtener el verdadero coste bajo demanda, divide esta métrica por (1 - ). Por ejemplo, si tienes un descuento de tarifa plana del 5% en todos los productos Azure, si tomas esta métrica y la divides por 0,95 (1-,05) obtendrás el verdadero precio bajo demanda.| +| `azure.cost.amortized` | Costo basado en las tasas de descuento aplicadas más la distribución de los pagos anticipados a lo largo del uso durante el plazo del descuento (base de devengo).| +| `azure.cost.actual` | Costo mostrado como el monto cobrado en el momento del uso (base de efectivo). Los costos reales incluyen descuentos privados, así como descuentos de instancias reservadas y planes de ahorro como tipos de cargo separados.| +| `azure.cost.discounted.ondemand` | Costo basado en la tarifa de lista proporcionada por Azure, después de los descuentos negociados de forma privada. Para obtener el costo real bajo demanda, divida esta métrica por (1 - ). Por ejemplo, si tiene un descuento de tarifa plana del 5% en todos los productos de Azure, tomar esta métrica y dividirla por .95 (1-.05) proporciona el precio real bajo demanda.| -### Etiquetas predefinidas +### Etiquetas predeterminadas {#out-of-the-box-tags} -Datadog enriquece automáticamente tus datos de costes de Azure con etiquetas de múltiples fuentes. Para obtener una visión general de cómo se aplican las etiquetas a los datos de costes, consulta [Etiquetas][12]. +Datadog enriquece automáticamente sus datos de costos de Azure con etiquetas de múltiples fuentes. Para obtener una descripción general completa de cómo se aplican las etiquetas a los datos de costos, consulte [Tags][12]. -Las siguientes etiquetas predefinidas se derivan de tu [informe de costes de uso][9] y facilitan la detección y la comprensión de los datos de costes: +Las siguientes etiquetas predeterminadas se derivan de su [informe de costos de uso][9] y facilitan la detección y comprensión de los datos de costos: | Nombre de la etiqueta | Descripción de la etiqueta | | ---------------------------- | ----------------- | -| `accountname` | Nombre de la cuenta asociada a la partida. | -| `accountownerid` | ID del propietario asociado a la partida. | -| `billingaccountid` | ID de la cuenta de facturación asociada a la partida. | -| `billingaccountname` | Nombre de la cuenta de facturación asociada a la partida. | -| `billingcurrency` | Moneda asociada a la cuenta de facturación. | -| `billingperiod` | Periodo de facturación del cargo. | -| `billingperiodenddate` | Fecha de finalización del periodo de facturación. | -| `billingperiodstartdate` | Fecha de inicio del periodo de facturación. | -| `billingprofileid` | ID único de la inscripción al Enterprise Agreement. | -| `billingprofilename` | Nombre de la inscripción al Enterprise Agreement. | -| `chargetype` | Tipo de cargo que cubre la partida: `Usage`, `Purchase` o `Refund`. | -| `consumedservice` | Nombre del servicio al que está asociada la partida. | -| `costcenter` | Centro de costes definido para la suscripción al seguimiento de los costes. | -| `costinbillingcurrency` | Coste en la moneda de facturación antes de créditos o impuestos. | -| `costinpricingcurrency` | Coste en la moneda de fijación del precio antes de créditos o impuestos. | -| `currency` | Moneda asociada a la cuenta de facturación. | -| `date` | Fecha de uso o compra del cargo. | -| `effectiveprice` | Precio unitario combinado del periodo. Los precios combinados compensan cualquier fluctuación en el precio unitario, como el escalonamiento gradual, que reduce el precio a medida que aumenta la cantidad. | -| `exchangeratedate` | Fecha en la que se definió el tipo de cambio. | -| `exchangeratepricingtobilling` | Tipo de cambio utilizado para convertir el coste en la moneda de fijación del precio a la moneda de facturación. | -| `frequency` | Indica si se espera que un cargo se repita. Los cargos pueden producirse una sola vez (`OneTime`), repetirse mensual o anualmente (`Recurring`) o basarse en el uso (`Usage`). | -| `InvoiceId` | ID único del documento que aparece en el PDF de la factura. | -| `invoicesectionid` | ID de la sección de la factura MCA. | -| `invoicesectionname` | El nombre del departamento de Enterprise Agreement (EA). | -| `isazurecrediteligible` | `true` si el cargo puede pagarse con créditos Azure. | -| `location` | Localización del centro de datos donde se ejecuta el recurso. | -| `metercategory` | Servicio de nivel superior al que pertenece este uso (como `Networking`). | -| `meterid` | Identificador único del contador. | -| `metername` | Información de uso de la partida (como `L8s v2` o `General Purpose Data Stored`). | -| `meterregion` | La localización del centro de datos para la servicios con precios basados en la localización (como `West US 2`). Utiliza `resourcelocation` para ver los datos de localización sin `N/A`. | -| `metersubcategory` | Nombre de la categoría de subclasificación del contador (como `General Purpose - Storage`). Utiliza `metername` o `metercategory` para ver la clasificación de nivel superior sin `N/A`. | -| `offerid` | Nombre de la oferta adquirida. | -| `partnumber` | ID utilizado para obtener la tarificación específica del contador. | -| `planname` | Nombre del plan del marketplace si se adquirió a través del marketplace. | +| `accountname` | El nombre de la cuenta asociada con la partida. | +| `accountownerid` | El ID del propietario asociado con la partida. | +| `billingaccountid` | El ID de la cuenta de facturación asociada con la partida. | +| `billingaccountname` | El nombre de la cuenta de facturación asociada con la partida. | +| `billingcurrency` | La moneda asociada con la cuenta de facturación. | +| `billingperiod` | El período de facturación del cargo. | +| `billingperiodenddate` | La fecha de finalización del período de facturación. | +| `billingperiodstartdate` | La fecha de inicio del período de facturación. | +| `billingprofileid` | El identificador único de la inscripción del Contrato Enterprise. | +| `billingprofilename` | El nombre de la inscripción del Contrato Enterprise. | +| `chargetype` | El tipo de cargo que cubre la partida: `Usage`, `Purchase` o `Refund`. | +| `consumedservice` | El nombre del servicio con el que está asociada la partida. | +| `costcenter` | El centro de costos definido para la suscripción para el seguimiento de costos. | +| `costinbillingcurrency` | El costo en la moneda de facturación antes de créditos o impuestos. | +| `costinpricingcurrency` | El costo en la moneda de precios antes de créditos o impuestos. | +| `currency` | La moneda asociada con la cuenta de facturación. | +| `date` | La fecha de uso o compra del cargo. | +| `effectiveprice` | El precio unitario combinado para el período. Los precios combinados promedian cualquier fluctuación en el precio unitario, como la escala gradual, que reduce el precio a medida que aumenta la cantidad. | +| `exchangeratedate` | La fecha en la que se estableció el tipo de cambio. | +| `exchangeratepricingtobilling` | El tipo de cambio utilizado para convertir el costo en la moneda de precios a la moneda de facturación. | +| `frequency` | Indica si se espera que un cargo se repita. Los cargos pueden ocurrir una vez (`OneTime`), repetirse de forma mensual o anual (`Recurring`), o basarse en el uso (`Usage`) | +| `InvoiceId` | El ID de documento único que aparece en el PDF de la factura. | +| `invoicesectionid` | El ID de la sección de factura de MCA. | +| `invoicesectionname` | El nombre del departamento del Contrato Enterprise (EA). | +| `isazurecrediteligible` | `true` si el cargo es elegible para pagarse mediante créditos de Azure. | +| `location` | La ubicación del centro de datos donde se ejecuta el recurso. | +| `metercategory` | El servicio de nivel superior al que pertenece este uso (como `Networking`). | +| `meterid` | El ID único del medidor. | +| `metername` | Los detalles de uso de la partida (como `L8s v2` o `General Purpose Data Stored`). | +| `meterregion` | La ubicación del centro de datos para los servicios con precios basados en la ubicación (como `West US 2`). Use `resourcelocation` para ver los datos de ubicación sin `N/A`. | +| `metersubcategory` | El nombre de la categoría de subclasificación del medidor (como `General Purpose - Storage`). Use `metername` o `metercategory` para ver la clasificación de nivel superior sin `N/A`. | +| `offerid` | El nombre de la oferta adquirida. | +| `partnumber` | El ID utilizado para obtener precios específicos del medidor. | +| `planname` | El nombre del plan de marketplace si se adquirió a través de marketplace. | | `PreviousInvoiceId` | Referencia a una factura original si esta partida es un reembolso. | -| `PricingCurrency` | Moneda utilizada en la tarificación basada en precios negociados. | -| `pricingmodel` | Tipo de uso (como `Reservation`). | -| `ProductId` | ID de un producto Azure específico. | -| `productname` | Nombre del producto Azure a nivel granular, como tipo de máquina virtual o disco y región. | -| `productorderid` | ID del pedido del producto. Utiliza `productname` para ver información clara del productor sin `N/A`. | -| `productordername` | Nombre del pedido del producto. Utiliza `productname` para ver información clara del producto sin `N/A`. | -| `publishername` | Editor de servicios del marketplace. | -| `publishertype` | Tipo de editor: `Microsoft` para cuentas Microsoft Customer Agreement y `Azure` para cuentas Enterprise Agreement. | -| `reservationid` | ID de la instancia de reserva adquirida. Si ves valores `N/A`, se trata de recursos `OnDemand`, que pueden comprobarse utilizando la etiqueta `pricingmodel`. | -| `reservationname` | Nombre de la instancia de reserva adquirida. Si ves valores `N/A`, se trata de recursos `OnDemand`, que pueden comprobarse utilizando la etiqueta `pricingmodel`. | -| `resourcegroup` | Nombre del grupo de recursos en el que se encuentra el recurso. No todos los cargos proceden de recursos desplegados en grupos de recursos. | -| `resourceid` | ID del recurso Azure. | -| `resourcelocation` | Localización del centro de datos donde se ejecuta el recurso (como `westus2`). | -| `resourcename` | Nombre del recurso. No todos los cargos proceden de recursos desplegados. | -| `resourcetype` | Tipo de recurso de Azure. | -| `servicefamily` | Familia de servicios a la que pertenece el servicio (como `Compute`). La etiqueta `consumedservice` tiene mayor información sobre los tipos de infraestructuras. | -| `ServicePeriodEndDate` | Fecha de finalización del periodo del servicio de Azure. | -| `ServicePeriodStartDate` | Fecha de inicio del periodo del servicio de Azure. | -| `subscriptionid` | ID de la suscripción a Azure. | -| `subscriptionname` | Nombre de la suscripción a Azure. | -| `term` | Describe la duración o plazo del Plan de Ahorro en meses (como `12`). | -| `unitofmeasure` | Unidad de medida de facturación del servicio. Por ejemplo, los servicios de cálculo se facturan por hora. | - - -#### Correlación entre costes y observabilidad - -Visualizar los costes en el contexto de los datos de observabilidad es importante para entender cómo los cambios en la infraestructura afectan a los costes, identificar por qué cambian los costes y optimizar la infraestructura tanto para los costes como para el rendimiento. Datadog añade la etiqueta `name` en los datos de costes de los principales productos Azure para simplificar la correlación entre observabilidad y métricas de costes. - -Por ejemplo, para ver el coste y la utilización de cada máquina virtual Azure, puedes hacer una tabla con `azure.cost.amortized` y `azure.vm.network_in_total` (o cualquier otra métrica de máquina virtual) y agrupar por `name`. O, para ver el uso y los costes de almacenamiento uno al lado del otro, puedes filtrar en `metercategory:Storage` y hacer un gráfico con `azure.storage.transactions` y `azure.cost.amortized` agrupados por `name`. - -## Referencias adicionales +| `PricingCurrency` | La moneda utilizada al realizar la valoración basada en precios negociados. | +| `pricingmodel` | El tipo de uso (como `Reservation`). | +| `ProductId` | El identificador de un producto de Azure específico. | +| `productname` | El nombre del producto de Azure a un nivel granular, como el tipo de VM o disco y la región. | +| `productorderid` | El ID del pedido de producto. Use `productname` para ver información de productos de nivel superior sin `N/A`. | +| `productordername` | El nombre del pedido de producto. Use `productname` para ver información de productos de nivel superior sin `N/A`. | +| `publishername` | El editor de servicios de marketplace. | +| `publishertype` | El tipo de editor: `Microsoft` para cuentas de Contrato de cliente de Microsoft y `Azure` para cuentas de Contrato Enterprise. | +| `reservationid` | El ID de la instancia de reserva comprada. Si ve valores `N/A`, estos son recursos `OnDemand`, que se pueden verificar mediante la etiqueta `pricingmodel`. | +| `reservationname` | El nombre de la instancia de reserva comprada. Si ve valores `N/A`, estos son recursos `OnDemand`, que se pueden verificar mediante la etiqueta `pricingmodel`. | +| `resourcegroup` | El nombre del grupo de recursos en el que se encuentra el recurso. No todos los cargos provienen de recursos implementados en grupos de recursos. | +| `resourceid` | El ID del recurso de Azure. | +| `resourcelocation` | La ubicación del centro de datos donde se ejecuta el recurso (como `westus2`). | +| `resourcename` | El nombre del recurso. No todos los cargos provienen de recursos implementados. | +| `resourcetype` | El tipo de recurso de Azure. | +| `servicefamily` | La familia de servicios a la que pertenece el servicio (como `Compute`). La etiqueta `consumedservice` tiene información más detallada sobre los tipos de infraestructura. | +| `ServicePeriodEndDate` | La fecha de finalización del período de servicio de Azure. | +| `ServicePeriodStartDate` | La fecha de inicio del período de servicio de Azure. | +| `subscriptionid` | El ID de la suscripción de Azure. | +| `subscriptionname` | El nombre de la suscripción de Azure. | +| `term` | Describe la duración o el plazo del Plan de ahorro en meses (como `12`). | +| `unitofmeasure` | La unidad de medida para la facturación del servicio. Por ejemplo, los servicios de cómputo se facturan por hora. | + + +#### Correlación de costos y observabilidad {#cost-and-observability-correlation} + +Ver los costos en el contexto de los datos de observabilidad es importante para entender cómo los cambios en la infraestructura afectan los costos, identificar por qué cambian los costos y optimizar la infraestructura tanto para los costos como para el rendimiento. Datadog agrega la etiqueta `name` en los datos de costos para los principales productos de Azure a fin de simplificar la correlación de las métricas de observabilidad y costos. + +Por ejemplo, para ver el costo y la utilización de cada VM de Azure, puede crear una tabla con `azure.cost.amortized` y `azure.vm.network_in_total` (o cualquier otra métrica de VM) y agrupar por `name`. O, para ver el uso y los costos de almacenamiento lado a lado, puede filtrar por `metercategory:Storage` y graficar `azure.storage.transactions` y `azure.cost.amortized` agrupados por `name`. + +## Lecturas adicionales {#further-reading} {{< partial name="whats-next/whats-next.html" >}} [1]: https://www.datadoghq.com/blog/azure-datadog-partnership/ [2]: https://docs.datadoghq.com/es/integrations/azure/?tab=azurecliv20#setup -[3]: https://app.datadoghq.com/cost/setup?cloud=azure +[3]: https://app.datadoghq.com/cost/setup [4]: https://app.datadoghq.com/integrations/azure [5]: https://portal.azure.com/#view/Microsoft_Azure_CostManagement/Menu/~/config [6]: https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/tutorial-export-acm-data?tabs=azure-cli @@ -259,7 +356,11 @@ Por ejemplo, para ver el coste y la utilización de cada máquina virtual Azure, [8]: https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/tutorial-improved-exports [9]: https://learn.microsoft.com/en-us/azure/cost-management-billing/understand/download-azure-daily-usage [10]: https://docs.azure.cn/en-us/cost-management-billing/manage/resolve-past-due-balance#check-the-type-of-your-account -[11]: /es/help/ [12]: /es/cloud_cost_management/tags [13]: /es/api/latest/cloud-cost-management/#create-cloud-cost-management-azure-configs -[14]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/azure_uc_config \ No newline at end of file +[14]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/azure_uc_config +[15]: https://learn.microsoft.com/en-us/azure/cost-management-billing/microsoft-customer-agreement/onboard-microsoft-customer-agreement +[16]: /es/help/ +[17]: ?tab=manual#generate-cost-exports +[18]: #migrate-exports-from-an-ea-to-an-mca +[19]: ?tab=terraform \ No newline at end of file diff --git a/hugo/content/es/containers/monitoring/kubernetes_explorer.md b/hugo/content/es/containers/monitoring/kubernetes_explorer.md index 927be0f96a4..eba9cbfc2e8 100644 --- a/hugo/content/es/containers/monitoring/kubernetes_explorer.md +++ b/hugo/content/es/containers/monitoring/kubernetes_explorer.md @@ -1,35 +1,37 @@ --- aliases: - /es/infrastructure/containers/orchestrator_explorer -description: Uso de la página del Kubernetes Explorer de Datadog para monitorizar - tus recursos Kubernetes, como pods y despliegues. +description: Uso de la página Kubernetes Explorer de Datadog para hacer un seguimiento + de sus recursos de Kubernetes, como pods y despliegues. further_reading: - link: https://www.datadoghq.com/blog/kubernetes-operator-performance tag: Blog - text: Monitorizar tus operadores de Kubernetes para que las aplicaciones funcionen - sin problemas + text: Haga un seguimiento de sus operadores de Kubernetes para mantener las aplicaciones + funcionando sin problemas +- link: https://learn.datadoghq.com/courses/getting-started-k8s + tag: Centro de aprendizaje + text: Introducción a la observabilidad de Kubernetes title: Kubernetes Explorer --- +{{< img src="infrastructure/livecontainers/orch_ex.png" alt="Kubernetes Explorer, mostrando pods de Kubernetes." style="width:80%;">}} -{{< img src="infrastructure/livecontainers/orch_ex.png" alt="Kubernetes Explorer que muestra pods de Kubernetes." style="width:80%;">}} +El [Kubernetes Explorer][1] de Datadog le permite hacer un seguimiento del estado de los pods, despliegues y otros recursos de Kubernetes. También puede visualizar las especificaciones de recursos para pods con errores dentro de un despliegue, correlacionar la actividad de los nodos con los registros relacionados, hacer un seguimiento de la utilización de recursos, escalar cargas de trabajo automáticamente y solucionar errores. -El [Kubernetes Explorer][1] de Datadog te permite monitorizar el estado de pods, despliegues y otros recursos Kubernetes. También puedes ver las especificaciones de recursos de pods fallidos en un despliegue, correlacionar la actividad de los nodos con logs relacionados, realizar un seguimiento del uso de recursos, escalar automáticamente cargas de trabajo y corregir errores. +
Al usar el Datadog Agent, Kubernetes Explorer requiere el Agent 7.27.0+ y el Clúster Agent 1.11.0+. Si está utilizando Kubernetes 1.25+, entonces se requiere el Clúster Agent 7.40.0+.
-
El Kubernetes Explorer requiere el Datadog Agent v7.27.0 o posterior y Datadog Cluster Agent v1.11.0 o posterior.
Si utilizas Kubernetes v1.25 o posterior, necesitarás Cluster Agent v7.40.0 o posterior.
+## Configuración {#configuration} -## Configuración +### Habilitar Kubernetes Explorer {#enable-kubernetes-explorer} -### Activar el Kubernetes Explorer - -El Kubernetes Explorer está **activado por defecto** en la mayoría de las instalaciones de Datadog Agents. +Kubernetes Explorer está **habilitado de forma predeterminada** para la mayoría de las instalaciones del Datadog Agent. {{< tabs >}} {{% tab "Datadog Operator" %}} -Cuando se instala el Datadog Agent utilizando el Datadog Operator, el Kubernetes Explorer se activa por defecto. +Cuando instala el Datadog Agent mediante el Datadog Operator, Kubernetes Explorer se habilita de forma predeterminada. -Para comprobar que el Kubernetes Explorer está activado, asegúrate de que el parámetro `features.orchestratorExplorer.enabled` está configurado como `true` en tu `datadog-agent.yaml`: +Para verificar que Kubernetes Explorer esté habilitado, asegúrese de que el parámetro `features.orchestratorExplorer.enabled` esté configurado en `true` en su `datadog-agent.yaml`: ```yaml apiVersion: datadoghq.com/v2alpha1 @@ -50,9 +52,9 @@ spec: {{% /tab %}} {{% tab "Helm" %}} -Cuando se instala el Datadog Agent utilizando el [Helm chart oficial][1], el Kubernetes Explorer está activado por defecto. +Cuando instala el Datadog Agent mediante el [official Helm chart][1], Kubernetes Explorer se habilita de forma predeterminada. -Para comprobar que el Kubernetes Explorer está activado, asegúrate de que el parámetro `orchestratorExplorer.enabled` está configurado como `true` en tu archivo `datadog-values.yaml`: +Para verificar que Kubernetes Explorer esté habilitado, asegúrese de que el parámetro `orchestratorExplorer.enabled` esté configurado en `true` en su archivo `datadog-values.yaml`: ```yaml datadog: @@ -64,28 +66,366 @@ datadog: enabled: true ``` -Luego, actualiza tu Helm chart. +Luego, actualice su Helm chart. [1]: https://github.com/DataDog/helm-charts {{% /tab %}} {{% tab "Manual" %}} -Para la configuración manual, consulta [Configurar el Kubernetes Explorer con un DaemonSet][5]. +Para la configuración manual, consulte [Set up Kubernetes Explorer with a DaemonSet][1]. + +[1]: /es/infrastructure/faq/set-up-orchestrator-explorer-daemonset -[5]: /es/infrastructure/faq/set-up-orchestrator-explorer-daemonset {{% /tab %}} -{{< /tabs >}} +{{% tab "OpenTelemetry Collector" %}} + +Puede completar el explorador de Kubernetes utilizando una canalización nativa de OpenTelemetry en lugar del Datadog Agent. Esta configuración utiliza el receptor [`k8sobjects`][1] para recopilar datos de recursos de Kubernetes y los reenvía a través de la funcionalidad de explorador de orquestadores del [Datadog Exporter][2]. + +{{< site-region region="gov,gov2" >}}
Esta función no está disponible para {{< region-param key="dd_site_name" >}}.
{{< /site-region >}} + +#### Requisitos previos {#prerequisites} + +- OpenTelemetry Collector Contrib [v0.154.0][3] o posterior. +- OpenTelemetry Collector [Helm chart][4] v0.156.2 o posterior. + +#### Limitaciones {#limitations} + +El receptor de fuente abierta `k8sobjects` puede generar una carga significativa en el servidor de API de Kubernetes de un clúster. + +Recomendaciones: + +- Utilice Kubernetes 1.33 o posterior, que incluye [mejoras de lista][5] que reducen el impacto en el servidor de API. +- Comience con clústeres más pequeños. Limite la cantidad de objetos por tipo de recurso a menos de 5,000 como punto de partida y escale gradualmente mientras monitorea el estado del clúster. + +Los siguientes pasos describen los componentes necesarios para Kubernetes Explorer. Para obtener un ejemplo de referencia completo que también recopile métricas de infraestructura de Kubernetes, consulte [Métricas de Kubernetes][6]. + +#### 1. Cree un secreto de clave de Datadog API {#1-create-a-datadog-api-key-secret} + +Cree un secreto de Kubernetes para almacenar su clave de Datadog API: + +```sh +export DD_API_KEY="" +kubectl create secret generic datadog-secret --from-literal api-key=$DD_API_KEY +``` + +#### 2. Configure el recopilador del clúster {#2-configure-the-cluster-collector} + +Esta configuración implementa el recopilador de OTel como un Deployment de Kubernetes. Cree un archivo `deployment-collector.yaml` con los siguientes bloques de configuración, o combínelos en su archivo de valores de OpenTelemetry Collector existente. + +##### Imagen y modo del recopilador {#collector-image-and-mode} + +Configure el recopilador para que se ejecute como un Deployment de una sola réplica utilizando la distribución 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 +``` + +##### Colección de objetos de Kubernetes {#kubernetes-objects-collection} + +El `kubernetesObjects` [preset][4] aprovisiona automáticamente la cuenta de servicio, los permisos RBAC y los valores predeterminados del receptor `k8sobjects` necesarios para completar Kubernetes Explorer. Anule el receptor `interval` a `3m`, lo cual es necesario para Kubernetes Explorer: + +```yaml +presets: + kubernetesObjects: + enabled: true + watch: true -### Recopilar recursos personalizados +config: + receivers: + k8sobjects: + interval: 3m +``` + +##### Datadog Exporter {#datadog-exporter} + +Habilite la opción `orchestrator_explorer` en el Datadog Exporter. Esta es la configuración que envía datos de objetos de Kubernetes a Kubernetes Explorer. Reemplace `` con su [sitio de Datadog][7]: + +```yaml +config: + exporters: + datadog: + api: + site: + key: ${env:DD_API_KEY} + orchestrator_explorer: + enabled: true +``` + +##### Procesadores y canalización {#processors-and-pipeline} + +Agregue un procesador [`resourcedetection`][8] para detectar el UID y el nombre del clúster. + +- El detector `k8s_api` es necesario para detectar el UID del clúster (`k8s.cluster.uid`). +- La detección del nombre del clúster depende de su proveedor de nube. Verifique la [documentación del procesador `resourcedetection`][8] para conocer los proveedores compatibles (EKS, AKS, GCP) y los permisos necesarios. +- Si su proveedor no es compatible, utilice un procesador `resource/add-cluster-name` para establecer el nombre del clúster manualmente. Reemplace `` con el nombre de su clúster. + +Luego, conecte los componentes en una canalización `logs`. + +Los siguientes ejemplos muestran dos enfoques. Utilice el ejemplo del proveedor de nube si ejecuta en EKS, AKS o GCP. Utilice la alternativa manual si su proveedor no es compatible. + +**Detección del proveedor de nube (ejemplo de 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] +``` + +Reemplace `eks` con el detector de su proveedor (`aks`, `gcp`). Consulte la [documentación del procesador `resourcedetection`][8] para obtener la configuración específica del proveedor. + +**Alternativa manual:** + +Si el procesador `resourcedetection` no es compatible con su proveedor de nube, establezca el nombre del clúster manualmente. Reemplace `` con el nombre de su clúster: + +```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. Implementar con Helm {#3-deploy-with-helm} -### Añadir etiquetas (tags) personalizadas a los recursos +Instale el recopilador de OpenTelemetry usando su archivo de configuración: -Para facilitar el filtrado, puedes añadir etiquetas (tags) personalizadas a tus recursos Kubernetes a través de la variable de entorno `DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS`. **Estas etiquetas solo aparecen en el Kubernetes Explorer.** +```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. Verifique la instalación {#4-verify-the-installation} + +Abra el [Kubernetes Explorer][9] y filtre por el nombre de su clúster de OpenTelemetry. Todas las secciones de recursos principales de Kubernetes deberían llenarse, junto con **Custom Resources > CRD**. La sección **Custom Resources > Resources** no es compatible con esta configuración. + +#### 5. Correlacione registros, métricas y trazas con Kubernetes Explorer (opcional) {#5-correlate-logs-metrics-and-traces-with-kubernetes-explorer-optional} + +Para desplazarse entre los recursos de Kubernetes y sus registros, métricas y trazas relacionados, agregue los procesadores [`k8sattributes`][10] y [`resourcedetection`][8] a sus canalizaciones del recopilador existentes. Para la configuración de `resourcedetection`, consulte [Procesadores y canalización](#processors-and-pipeline) arriba. + +```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, ...] +``` + +Para obtener un ejemplo de referencia completo, consulte la [configuración del recopilador 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]: /es/opentelemetry/integrations/kubernetes_metrics/#setup +[7]: /es/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 "OpenTelemetry Kube Stack" %}} + +Puede completar Kubernetes Explorer utilizando el `opentelemetry-kube-stack` Helm chart en lugar del Datadog Agent. + +El [`opentelemetry-kube-stack`][1] Helm chart instala el Operador de OpenTelemetry y gestiona los colectores como Custom Resources `OpenTelemetryCollector`. Datadog mantiene una referencia [`values.yaml`][2] que configura dos colectores: + +- **`cluster`** (Deployment): Extrae métricas de kube-state-metrics, observa objetos de Kubernetes y permite que `orchestrator_explorer` complete Kubernetes Explorer. +- **`daemon`** (DaemonSet): Recopila métricas del servidor y del kubelet, y expone un punto de conexión OTLP para los datos de telemetría de la aplicación. + +{{< site-region region="gov,gov2" >}}
Esta función no está disponible para {{< region-param key="dd_site_name" >}}.
{{< /site-region >}} + +#### Requisitos previos {#prerequisites-1} + +- Helm chart OpenTelemetry Kube Stack [0.20.1][3] o posterior. +- OpenTelemetry Collector Contrib [v0.154.0][4] o posterior (fijado por el archivo de valores de referencia). +- cert-manager, que es necesario para el webhook de admisión del operador. + +#### Limitaciones {#limitations-1} + +El receptor de fuente abierta `k8sobjects` puede generar una carga significativa en el servidor de API de Kubernetes de un clúster. + +Recomendaciones: + +- Utilice Kubernetes 1.33 o posterior, que incluye [mejoras de lista][5] que reducen el impacto en el servidor de API. +- Comience con clústeres más pequeños. Limite la cantidad de objetos por tipo de recurso a menos de 5,000 como punto de partida y escale gradualmente mientras monitorea el estado del clúster. + +#### Inicio rápido (instalador interactivo) {#quickstart-interactive-installer} + +El repositorio [`opentelemetry-examples`][6] incluye un instalador interactivo que gestiona todos los pasos a continuación. Desde `guides/kubernetes/configuration/opentelemetry-kube-stack/`: + +```sh +./install +``` + +El instalador solicita su clave de Datadog API, [sitio de Datadog][7], plataforma de Kubernetes y entorno de implementación. Para EKS, GKE y AKS, habilita el ajuste preestablecido de detección de recursos correspondiente. Para otras plataformas, solicita el nombre del clúster. Luego crea el espacio de nombres `opentelemetry-operator-system` y `datadog-secret`, instala cert-manager si es necesario, e instala o actualiza el chart. + +#### Instalar con archivos de valores {#install-with-values-files} + +Si no utilizó el instalador interactivo anterior, siga los pasos a continuación para realizar la instalación manualmente. + +##### 1. Instale cert-manager (si aún no está presente) {#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. Cree el secreto de Datadog {#2-create-the-datadog-secret} + +Establezca `DD_SITE` en su [sitio de Datadog][7] (el valor predeterminado es `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. Cree una superposición de implementación {#3-create-a-deployment-overlay} + +La referencia `values.yaml` es la base; la configuración específica de la implementación (plataforma de clúster, entorno, nombre del clúster) reside en un archivo de superposición. Desde `guides/kubernetes/configuration/opentelemetry-kube-stack/`, copie el ejemplo que coincida con su plataforma: + +```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 +``` + +Para plataformas que no sean EKS/GKE/AKS, edite `deployment/values.yaml` y reemplace `my_k8s_cluster` y `production` con el nombre de su clúster y el entorno de implementación. + +##### 4. Implemente los recolectores de referencia {#4-deploy-the-reference-collectors} + +Instale o actualice el chart con la base `values.yaml` y su superposición: + +```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 +``` + +Ambos recolectores tienen límites predeterminados de `500m` de CPU y `1Gi` de memoria, y solicitudes de `200m` de CPU y `500Mi` de memoria. Aumente la escala para clústeres grandes. + +#### Verifique la instalación {#verify-the-installation} + +Abra el [Explorador de Kubernetes][8] y filtre por el nombre de su clúster. Todas las secciones de recursos principales de Kubernetes deberían llenarse, junto con **Custom Resources > CRD**. La sección **Custom Resources > Resources** no es compatible con esta configuración. + +[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]: /es/getting_started/site/ +[8]: https://app.datadoghq.com/orchestration/overview + +{{% /tab %}} +{{< /tabs >}} + +### Agregue etiquetas personalizadas a los recursos {#add-custom-tags-to-resources} + +Para facilitar el filtrado, puede agregar etiquetas personalizadas a sus recursos de Kubernetes a través de la variable de entorno `DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS`. **Estas etiquetas solo aparecen en el Explorador de Kubernetes.** {{< tabs >}} {{% tab "Datadog Operator" %}} -Define la variable de entorno `DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS` **dos veces** en `datadog-agent.yaml`: + +Establezca la variable de entorno `DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS` **dos veces** en `datadog-agent.yaml`: - En `agents.containers.processAgent.env` - En `clusterAgent.env` @@ -117,7 +457,7 @@ spec: value: "tag1:value1 tag2:value2" ``` -Luego, aplica la configuración nueva: +Luego aplique la nueva configuración: ```bash kubectl apply -n $DD_NAMESPACE -f datadog-agent.yaml @@ -126,7 +466,7 @@ kubectl apply -n $DD_NAMESPACE -f datadog-agent.yaml {{% /tab %}} {{% tab "Helm" %}} -Configura la variable de entorno `DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS` **dos veces** en `datadog-agent.yaml`: +Establezca la variable de entorno `DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS` **dos veces** en `datadog-agent.yaml`: - En `processAgent.env` - En `clusterAgent.env` @@ -143,12 +483,12 @@ clusterAgent: value: "tag1:value1 tag2:value2" ``` -Luego, actualiza tu Helm chart. +Luego, actualice su Helm chart. {{% /tab %}} {{% tab "DaemonSet" %}} -Establece la variable de entorno en los contenedores del Process Agent y Cluster Agent: +Establezca la variable de entorno tanto en los contenedores del Process Agent como del Cluster Agent: ```yaml - name: DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS @@ -158,179 +498,179 @@ Establece la variable de entorno en los contenedores del Process Agent y Cluster {{% /tab %}} {{< /tabs >}} -## Utilización +## Uso {#usage} -### Vistas +### Views {#views} -Alterna entre **Pods**, **Clusters** (Clústeres), **Namespaces** (Espacios de nombres) y otros recursos de Kubernetes en el menú desplegable **Select Resources** (Seleccionar recursos) en la esquina superior izquierda de la página. +Alterne entre {{< ui >}}Pods{{< /ui >}}, {{< ui >}}Clusters{{< /ui >}}, {{< ui >}}Namespaces{{< /ui >}} y otros recursos de Kubernetes en el menú desplegable {{< ui >}}Select Resources{{< /ui >}} en la esquina superior izquierda de la página. -Cada una de estas vistas incluye una tabla de datos para ayudarte a organizar mejor tus datos por campo, como estado, nombre y etiquetas (labels) de Kubernetes, y un mapa de clústeres detallado para brindarte panorama más amplio de tus pods y clústeres de Kubernetes. +Cada una de estas vistas incluye una tabla de datos para ayudarle a organizar mejor sus datos por campo, como estado, nombre y etiquetas de Kubernetes, y un Mapa de clúster detallado para brindarle una visión más amplia de sus pods y clústeres de Kubernetes. -**Consulta los [Detalles del filtro de consulta](#query-filter-details) para obtener más detalles sobre cómo filtrar estas vistas.** +**Consulte [Detalles del filtro de consulta](#query-filter-details) para obtener más información sobre cómo filtrar estas vistas.** -{{< img src="infrastructure/livecontainers/orch_ex_replicasets.png" alt="Orchestrator Explorer abierto para mostrar Cargas de trabajo > Conjuntos de réplicas, en el modo Resumen" style="width:80%;">}} +{{< img src="infrastructure/livecontainers/orch_ex_replicasets.png" alt="Orchestrator Explorer abierto para mostrar Workloads > Replica Sets, en modo Resumen" style="width:80%;">}} -#### Agrupar por funcionalidad y facetas +#### Agrupar por funcionalidad y facetas {#group-by-functionality-and-facets} -Agrupa los pods por etiquetas (tags), etiquetas (labels) de Kubernetes o anotaciones de Kubernetes para obtener una vista agregada que te permita encontrar información con mayor rapidez. Puedes crear un grupo con la barra «Group by» (Agrupar por) en la parte superior derecha de la página o al hacer clic en una etiqueta (tag) o etiqueta (label) en particular y ubicar la función agrupar por en el menú contextual como se muestra a continuación. +Agrupe pods por etiquetas, etiquetas de Kubernetes o anotaciones de Kubernetes para obtener una visualización agregada que le permita encontrar información más rápidamente. Puede realizar una agrupación utilizando la barra "Agrupar por" en la parte superior derecha de la página o haciendo clic en una etiqueta en particular y localizando la función de agrupar por en el menú contextual, como se muestra a continuación. {{< img src="infrastructure/livecontainers/orch_ex_groupby.png" alt="Un ejemplo de agrupación por equipo" style="width:80%;">}} -También puedes utilizar facetas en el lado izquierdo de la página para agrupar recursos o filtrar los recursos que más te interesen, como pods con un estado de pod CrashLoopBackOff. +También puede usar facetas en el lado izquierdo de la página para agrupar recursos o filtrar los recursos que más le interesan, como los pods con un estado de pod CrashLoopBackOff. -{{< img src="infrastructure/livecontainers/crashloopbackoff.mp4" alt="Un ejemplo de cómo agrupar el estado de pod CrashLoopBackOff" video=true style="width:80%;">}} +{{< img src="infrastructure/livecontainers/crashloopbackoff.mp4" alt="Un ejemplo de agrupación del estado de pod CrashLoopBackOff" video=true style="width:80%;">}} -### Mapa de clústeres +### Mapa de clúster {#cluster-map} -Un mapa de clústeres te brinda un panorama más amplio de tus pods y clústeres de Kubernetes. Puedes ver todos tus recursos juntos en una pantalla con grupos y filtros personalizados, y elegir las métricas para rellenar el color de los nodos. +Un mapa de clúster le brinda una visión más amplia de sus pods y clústeres de Kubernetes. Puede ver todos sus recursos juntos en una sola pantalla con grupos y filtros personalizados, y elegir qué métricas utilizar para rellenar el color de los nodos. -Examina los recursos de los mapas de clústeres al hacer clic en cualquier círculo o grupo para completar un panel detallado. +Examine los recursos desde los mapas de clúster haciendo clic en cualquier círculo o grupo para completar un panel detallado. -{{< img src="infrastructure/livecontainers/cluster-map.mp4" alt="Un mapa de clústeres con grupos y filtros personalizados" video=true style="width:80%;">}} +{{< img src="infrastructure/livecontainers/cluster-map.mp4" alt="Un mapa de clúster con grupos y filtros personalizados" video=true style="width:80%;">}} -### Panel de información +### Panel de información {#information-panel} -Haz clic en cualquier fila de la tabla o en cualquier objeto en un mapa de clústeres para ver información sobre un recurso específico en un panel lateral. +Haga clic en cualquier fila de la tabla o en cualquier objeto de un mapa de clúster para ver información sobre un recurso específico en un panel lateral. -{{< img src="infrastructure/livecontainers/orch_ex_panel.png" alt="Una vista de recursos en el panel lateral, abierta en procesos." style="width:80%;">}} +{{< img src="infrastructure/livecontainers/orch_ex_panel.png" alt="Una vista de los recursos en el panel lateral, abierta en procesos." style="width:80%;">}} -La pestaña **YAML** del panel lateral muestra la definición completa del recurso. A partir de la **versión del Agent 7.44.0**, también incluye siete días de historial de definiciones. Puedes comparar lo que cambió con el tiempo y en diferentes versiones. La hora indicada es aproximada a cuando se aplicaron los cambios al recurso. +La pestaña {{< ui >}}YAML{{< /ui >}} del panel lateral muestra la definición completa del recurso. A partir de la **Agent version 7.44.0**, también incluye siete días de historial de definiciones. Puede comparar lo que cambió con el tiempo y entre diferentes versiones. La hora indicada es aproximadamente cuando se aplicaron los cambios al recurso. Para evitar mostrar una gran cantidad de cambios irrelevantes, se ignoran las actualizaciones que afectan solo a los siguientes campos: * metadata.resourceVersion * metadata.managedFields * metadata.generation -* metadata.annotations["kubernetes.io/config.seen"] +* metadata.annotations[\"kubernetes.io/config.seen\"] * status {{< img src="infrastructure/livecontainers/orch_ex_manifest_history.png" alt="Una vista de los recursos en el panel lateral, que muestra la función de historial de yaml" style="width:80%;">}} -Las demás pestañas muestran más información para solucionar problemas del recurso seleccionado: +Las otras pestañas muestran más información para la solución de problemas del recurso seleccionado: -* [**Logs**][9]: visualiza los logs desde tu contenedor o recurso. Haz clic en cualquier log para ver los logs relacionados en el Log Explorer. -* [**APM**][11]: consulta trazas (traces) de tu contenedor o recurso, incluida la fecha, el servicio, la duración, el método y el código de estado de una traza. -* [**Metrics**][10] (Métricas): consulta métricas en directo para tu contenedor o recurso. Puedes ver cualquier gráfica en pantalla completa, compartir una snapshot de esta o exportarla desde esta pestaña. -* **Processes** (Procesos): consulta todos los procesos que se ejecutan en el contenedor de este recurso. -* **Network** (Red): consulta el rendimiento de la red de un contenedor o recurso, incluidos los campos de origen, destino, volumen enviado y recibido, y rendimiento. Utiliza el campo **Destination** (Destino) para buscar por etiquetas como `DNS` o `ip_type`, o utiliza el filtro **Group by** (Agrupar por) en esta vista a fin de agrupar datos de red por etiquetas, como `pod_name` o `service`. -* [**Events**][12] (Eventos): consulta todos los eventos de Kubernetes para tu recurso. -* **Monitors** (Monitores): consulta los monitores etiquetados, con contexto o agrupados para este recurso. +* [**Registros**][2]: Visualice los registros de su contenedor o recurso. Haga clic en cualquier registro para visualizar registros relacionados en el Explorador de registros. +* [**APM**][3]: Visualice las trazas de su contenedor o recurso, incluyendo la fecha, el servicio, la duración, el método y el código de estado de una traza. +* [**Métricas**][4]: Visualice métricas en tiempo real para su contenedor o recurso. Puede ver cualquier gráfico en pantalla completa, compartir una instantánea del mismo o exportarlo desde esta pestaña. +* {{< ui >}}Processes{{< /ui >}}: Visualice todos los procesos que se ejecutan en el contenedor de este recurso. +* {{< ui >}}Network{{< /ui >}}: Visualice el rendimiento de red de un contenedor o recurso, incluyendo los campos de fuente, destino, volumen enviado y recibido, y rendimiento. Use el campo {{< ui >}}Destination{{< /ui >}} para buscar por etiquetas como `DNS` o `ip_type`, o use el filtro {{< ui >}}Group by{{< /ui >}} en esta vista para agrupar datos de red por etiquetas, como `pod_name` o `service`. +* [**Eventos**][5]: Visualice todos los eventos de Kubernetes para su recurso. +* {{< ui >}}Monitors{{< /ui >}}: Vea los monitores etiquetados, con alcance o agrupados para este recurso. -Para obtener un dashboard detallado de este recurso, haz clic en View Dashboard (Ver dashboard) en la esquina superior derecha de este panel. +Para obtener un Dashboard detallado de este recurso, haga clic en Ver Dashboard en la esquina superior derecha de este panel. -{{< img src="infrastructure/livecontainers/view-pod-dashboard.png" alt="Un enlace a un dashboard de pod desde la información general sobre Live Containers" style="width:80%;">}} +{{< img src="infrastructure/livecontainers/view-pod-dashboard.png" alt="Un enlace a un pod Dashboard desde la visualización general de Containers en vivo." style="width:80%;">}} -### Utilización de recursos +### Utilización de recursos {#resource-utilization} -_Para ver la página de utilización de recursos, consulta [Utilización de recursos][13]_. +_Para la página de Utilización de recursos, consulte [Utilización de recursos][6]_. -En la pestaña del Kubernetes Explorer, puedes explorar una selección de métricas de utilización de recursos. +Dentro de la pestaña Explorador de Kubernetes, puede explorar una selección de métricas de utilización de recursos. -{{< img src="infrastructure/livecontainers/orch_ex_resource_utilization.png" alt="Utilización de recursos de contenedor" style="width:80%;">}} +{{< img src="infrastructure/livecontainers/orch_ex_resource_utilization.png" alt="Utilización de recursos del contenedor" style="width:80%;">}} -Todas estas columnas admiten la clasificación, lo que te ayuda a identificar cargas de trabajo individuales en función de su utilización de recursos. +Todas estas columnas admiten la ordenación, lo que le ayuda a identificar cargas de trabajo individuales según su utilización de recursos. -{{< img src="infrastructure/livecontainers/orch_ex_resource_utilization_sorted_column.png" alt="Columnas ordenadas por utilización de recursos de contenedor" style="width:50%;">}} +{{< img src="infrastructure/livecontainers/orch_ex_resource_utilization_sorted_column.png" alt="Columnas ordenadas de utilización de recursos del contenedor" style="width:50%;">}} -## Detalles del filtro de consulta +## Detalles del filtro de consulta {#query-filter-details} -Puedes limitar los recursos que se muestran al proporcionar una consulta en la barra de búsqueda «Filter by» (Filtrar por) en la parte superior izquierda de la página. +Puede restringir los recursos mostrados proporcionando una consulta dentro de la barra de búsqueda \"Filtrar por\" en la parte superior izquierda de la página. -### Sintaxis +### Sintaxis {#syntax} -Un filtro de consulta se compone de términos y operadores. Por ejemplo: +Un filtro de consulta se compone de términos y operadores. Ejemplo: -{{< img src="infrastructure/livecontainers/orch_syntax.png" alt="Sintaxis del filtro de consultas de Orchestrator Explorer." style="width:80%;">}} +{{< img src="infrastructure/livecontainers/orch_syntax.png" alt="Sintaxis del filtro de consulta del Explorador de orquestadores." style="width:80%;">}} -#### Términos +#### Términos {#terms} -Existen varios tipos de términos: +Hay varios tipos de términos disponibles: | Tipo | Ejemplos | |---|---| -| **Etiquetas (tags)**: adjuntas a los recursos por [el Agent que las recopila][20]. También existen etiquetas adicionales que genera Datadog para los recursos de Kubernetes. | `datacenter:staging`, `tag#datacenter:staging`
_(la `tag#` es opcional)_ | -| **Etiquetas (labels)**: Extraídas de [metadatos de un recurso][25]. Por lo general, se utilizan para organizar tu clúster y dirigirte a recursos específicos con selectores. | `label#chart_version:2.1.0` | -| **Anotaciones**: extraídas de [metadatos de un recurso][26]. Por lo general, se utilizan para respaldar herramientas que ayudan en la gestión de clústeres. | `annotation#checksum/configmap:a1bc23d4` | -| **Métricas**: añadidas a los recursos de carga de trabajo (pods y despliegues, entre otros). Puedes encontrar recursos en función de su utilización. Para ver qué métricas se admiten, consulta [Filtros de utilización de recursos](#resource-utilization-filters). | `metric#cpu_usage_pct_limits_avg15:>80%` | -| **Coincidencia de cadenas**: Compatible con algunos atributos de recursos específicos, consulta más abajo.
_Nota: La correspondencia de cadenas no utiliza el formato clave-valor, y no se puede especificar el atributo utilizado en la coincidencia._ | `"10.132.6.23"` (IP),
`"9cb4b43f-8dc1-4a0e"` (UID),
`web-api-3` (nombre) | -| **Campos**: Extraídos de [los metadatos de un recurso][27] o de los campos indexados de recursos personalizados. | `field#metadata.creationTimestamp:>=4wk`, `field#metadata.deletionTimestamp:<=1hr`, `field#status.currentReplicas:3`, `field#status.conditions.Active.status:True` | +| **Etiquetas**: Adjuntas a los recursos por [el agente que los recopila][7]. También hay etiquetas adicionales que Datadog genera para los recursos de Kubernetes. | `datacenter:staging`, `tag#datacenter:staging`
_(el `tag#` es opcional)_ | +| **Etiquetas**: Extraídas de [los metadatos de un recurso][8]. Por lo general, se utilizan para organizar su clúster y seleccionar recursos específicos con selectores. | `label#chart_version:2.1.0` | +| **Anotaciones**: Extraídas de [los metadatos de un recurso][9]. Generalmente se utilizan para dar soporte a herramientas que ayudan en la gestión del clúster. | `annotation#checksum/configmap:a1bc23d4` | +| **Métricas**: Agregadas a los recursos de carga de trabajo (pods, despliegues, etc.). Puede encontrar recursos según su utilización. Para ver qué métricas son compatibles, consulte [Filtros de utilización de recursos](#resource-utilization-filters). | `metric#cpu_usage_pct_limits_avg15:>80%` | +| **Coincidencia de cadenas**: Admitida por algunos atributos de recursos específicos, consulte a continuación.
_Nota: la coincidencia de cadenas no utiliza el formato clave-valor y no puede especificar el atributo con el que realizar la coincidencia._ | `"10.132.6.23"` (IP),
`"9cb4b43f-8dc1-4a0e"` (UID),
`web-api-3` (Nombre) | +| **Campos**: Extraídos de los [metadatos de un recurso][10] o de los campos indexados de recursos personalizados. | `field#metadata.creationTimestamp:>=4wk`, `field#metadata.deletionTimestamp:<=1hr`, `field#status.currentReplicas:3`, `field#status.conditions.Active.status:True` | -> ***Nota**: Es posible que encuentres los mismos pares clave-valor como etiqueta (tag) y etiqueta (label) (o anotación); esto depende de cómo se haya configurado tu clúster.* +> ***Es posible que encuentre los mismos pares clave-valor tanto como etiqueta como label (o anotación)**; esto depende de cómo esté configurado su clúster.* -Los siguientes atributos de recursos se admiten en la **coincidencia de cadenas** arbitraria: +Los siguientes atributos de recursos son compatibles con la **coincidencia de cadenas** arbitraria: - `metadata.name` - `metadata.uid` - Direcciones IP encontradas en: - Pods - Nodos (internos y externos) - - Servicios (IPs de clúster, externas y de equilibrador de carga) + - Servicios (IP de clúster, externas y de balanceador de carga) -No es necesario que especifiques una clave para buscar un recurso por nombre o IP. No se requieren comillas a menos que tu búsqueda de cadenas incluya ciertos caracteres especiales. +No necesita especificar una clave para buscar un recurso por nombre o IP. No se requieren comillas a menos que su búsqueda de cadena incluya ciertos caracteres especiales. -#### Comparadores +#### Comparadores {#comparators} -Todos los términos respaldan el operador de igualdad `:`. Los términos de [valor de métrica](#resource-utilization-filters) también admiten comparaciones numéricas: +Todos los términos admiten el operador de igualdad `:`. Los términos de [valor de métrica](#resource-utilization-filters) también admiten comparaciones numéricas: - `:>` Mayor que (por ejemplo, `metric#cpu_usage_avg15:>0.9`) - `:>=` Mayor o igual que - `:<` Menor que - `:<=` Menor o igual que -#### Operadores +#### Operadores {#operators} -Para combinar varios términos en una consulta compleja, puedes utilizar cualquiera de los siguientes operadores booleanos que distinguen entre mayúsculas y minúsculas: +Para combinar varios términos en una consulta compleja, puede usar cualquiera de los siguientes operadores booleanos que distinguen entre mayúsculas y minúsculas: | Operador | Descripción | Ejemplo | |---|---|---| -| `AND` | **Intersección**: ambos términos están en los eventos seleccionados (si no se añade nada, AND se toma de manera predeterminada) | `a AND b` | -| `OR` | **Unión**: cualquiera de los términos está en los eventos seleccionados | `a OR b` | -| `NOT` / `-` | **Exclusión**: el siguiente término NO está en el evento (se aplica a cada búsqueda individual de texto sin formato) | `a AND NOT b` o
`a AND -b` | -| `( )` | **Agrupación:** especifica cómo agrupar los términos de manera lógica | `a AND (b OR c)` o
`(a AND b) or c` | +| `AND` | **Intersección**: Ambos términos están en los eventos seleccionados (si no se agrega nada, se toma AND de forma predeterminada) | `a AND b` | +| `OR` | **Unión**: Cualquiera de los términos está contenido en los eventos seleccionados | `a OR b` | +| `NOT` / `-` | **Exclusión**: El siguiente término NO está en el evento (se aplica a cada búsqueda de texto sin formato individual) | `a AND NOT b` o
`a AND -b` | +| `( )` | **Agrupación:** Especifique cómo agrupar términos lógicamente. | `a AND (b OR c)` o
`(a AND b) or c` | -##### `OR` abreviatura del valor +##### `OR` abreviatura de valor {#or-value-shorthand} -Se pueden combinar varios términos que comparten la misma clave en un solo término si todos utilizan el operador `OR`. Por ejemplo, esta consulta: +Se pueden combinar varios términos que comparten la misma clave en un solo término si todos usan el operador `OR`. Por ejemplo, esta consulta: ``` app_name:web-server OR app_name:database OR app_name:event-consumer ``` -Puede reducirse a: +Se puede reducir a: ``` app_name:(web-server OR database OR event-consumer) ``` -### Comodines +### Comodines {#wildcards} -Puedes utilizar comodines `*` como parte de un término a fin de filtrar por coincidencias parciales, tanto para valores como para claves. Algunos ejemplos: +Puede usar `*` comodines como parte de un término para filtrar por coincidencias parciales, tanto para valores como para claves. Algunos ejemplos: -- `kube_job:stats-*`: encuentra todos los recursos con un valor de etiqueta (tag) `kube_deployment` que comience con `stats-`. -- `pod_name:*canary`: encuentra todos los recursos con un valor `pod_name` que termine en `canary`.. -- `label#release:*`: encuentra todos los recursos con una etiqueta (label) `release`, independientemente de su valor. -- `-label#*.datadoghq.com/*`: encuentra recursos que no tengan ninguna etiqueta (label) con contexto de Datadog. -- `kube_*:*stats*canary`: encuentra recursos que tengan etiquetas (tags) de recursos relacionados (`kube_*`), con `stats` en el medio del valor y que también terminen en `canary`. +- `kube_job:stats-*`: Encuentre todos los recursos con una etiqueta `kube_deployment` cuyo valor comience con `stats-`. +- `pod_name:*canary`: Encuentre todos los recursos con una etiqueta `pod_name` cuyo valor termine en `canary`. +- `label#release:*`: Encuentre todos los recursos con una etiqueta `release`, independientemente de su valor. +- `-label#*.datadoghq.com/*`: Encuentre recursos que no tengan ninguna etiqueta con ámbito de Datadog. +- `kube_*:*stats*canary`: Encuentre recursos que tengan etiquetas de recursos relacionadas (`kube_*`), con `stats` en medio del valor, y que también terminen con `canary`. -### Etiquetas (tags) extraídas +### Etiquetas extraídas {#extracted-tags} -Además de las etiquetas (tags) que has [configurado][20] dentro del Datadog Agent, Datadog inyecta etiquetas (tags) generadas basadas en atributos de recursos que pueden ayudarte con tus necesidades de búsqueda y agrupación. Estas etiquetas (tags) se añaden a los recursos de manera condicional, cuando son relevantes. +Además de las etiquetas que ha [configurado][7] en su agente de Datadog, Datadog inyecta etiquetas generadas basadas en atributos de recursos que pueden ayudarle con sus necesidades de búsqueda y agrupación. Estas etiquetas se añaden a los recursos de forma condicional, cuando son relevantes. -#### Todos los recursos +#### Todos los recursos {#all-resources} -Todos los recursos tienen la etiqueta (tag) `kube_cluster_name` y todos los recursos con espacios de nombres tienen añadida la etiqueta (tag) `kube_namespace`. +Todos los recursos tienen la etiqueta `kube_cluster_name` y todos los recursos con espacio de nombres tienen la etiqueta `kube_namespace` añadida. -Además, los recursos contienen una etiqueta (tag) `kube_:`. Por ejemplo, a un despliegue denominado `web-server-2` se le añadiría de manera automática la etiqueta (tag) `kube_deployment:web-server-2`. +Además, los recursos contienen una etiqueta `kube_:`. Por ejemplo, a un despliegue llamado `web-server-2` se le añadiría automáticamente la etiqueta `kube_deployment:web-server-2`. -> **Nota**: Hay algunas excepciones a este patrón: +> **Nota**: Existen algunas excepciones a este patrón: > > - Los pods utilizan `pod_name` en su lugar. -> - *VPAs: `verticalpodautoscaler`*. -> - *HPAs: `horizontalpodautoscaler`*. -> - *Demandas de volumen persistentes: `persistentvolumeclaim`*. +> - *VPA: `verticalpodautoscaler`*. +> - *HPA: `horizontalpodautoscaler`*. +> - *Reclamaciones de volúmenes persistentes: `persistentvolumeclaim`*. -En función de las etiquetas (labels) adjuntas al recurso, también se extraerán las siguientes etiquetas (tags): +Según las etiquetas adjuntas al recurso, también se extraerán las siguientes etiquetas: -| Etiqueta (tag) | Etiqueta (label) de origen | +| Etiqueta | Etiqueta fuente | |---|---| | `kube_app_name` | `app.kubernetes.io/name` | | `kube_app_instance` | `app.kubernetes.io/instance` | @@ -342,28 +682,28 @@ En función de las etiquetas (labels) adjuntas al recurso, también se extraerá | `version` | `tags.datadoghq.com/version` | | `service` | `tags.datadoghq.com/service` | -#### Relaciones +#### Relaciones {#relationships} -Los recursos relacionados se etiquetarán entre sí. Algunos ejemplos son: +Los recursos relacionados se etiquetarán entre sí. Algunos ejemplos: -- Un pod que sea parte del despliegue «XYZ» tendrá una etiqueta (tag) `kube_deployment:xyz`. -- Una entrada que se dirija al servicio "A" tendrá una etiqueta (tag) `kube_service:a`. +- Un pod que forma parte del despliegue "XYZ" tendrá una etiqueta `kube_deployment:xyz`. +- Un ingress que apunta al servicio "A" tendrá una etiqueta `kube_service:a`. -Los recursos que se generan a partir de recursos «principales» tendrán las etiquetas (tags) `kube_ownerref_kind` y `kube_ownerref_name` (como pods y trabajos). +Los recursos que se generan a partir de recursos "padre" tendrán las etiquetas `kube_ownerref_kind` y `kube_ownerref_name` (como pods y jobs). -> **Consejo:** Utiliza la función de autocompletar consultas de filtro para descubrir qué etiquetas (tags) de recursos relacionados se encuentran disponibles. Escribe `kube_` y conoce qué resultados se sugieren. +> **Consejo:** Utilice la función de autocompletado de consultas de filtro para descubrir qué etiquetas de recursos relacionados están disponibles. Escriba `kube_` y vea qué resultados se sugieren. -#### Pods +#### Pods {#pods} -Los pods reciben las siguientes etiquetas (tags): +A los pods se les asignan las siguientes etiquetas: - `pod_name` - `pod_phase` (extraído del manifiesto) - `pod_status` (calculado de forma similar a `kubectl`) -#### Cargas de trabajo +#### Cargas de trabajo {#workloads} -Los recursos de carga de trabajo (pods, despliegues, conjuntos con estado, etc.) tendrán las siguientes etiquetas (tags), que indican su compatibilidad dentro de la página de utilización de recursos: +Los recursos de carga de trabajo (pods, despliegues, conjuntos con estado, etc.) tendrán las siguientes etiquetas, que indican su compatibilidad dentro de la página de Utilización de recursos: - `resource_utilization` (`supported` o `unsupported`) - `missing_cpu_requests` @@ -371,42 +711,42 @@ Los recursos de carga de trabajo (pods, despliegues, conjuntos con estado, etc.) - `missing_memory_requests` - `missing_memory_limits` -#### Condiciones +#### Condiciones {#conditions} -Algunas condiciones, para algunos recursos, se extraen como etiquetas (tags). Por ejemplo, puedes encontrar la etiqueta (tag) `kube_condition_available` en los despliegues. El formato de la etiqueta (tag) siempre es `kube_condition_` con un valor `true` o `false`. +Algunas condiciones, para algunos recursos, se extraen como etiquetas. Por ejemplo, puede encontrar la etiqueta `kube_condition_available` en los despliegues. El formato de etiqueta es siempre `kube_condition_` con un valor de `true` o `false`. -> **Consejo**: Utiliza la función de autocompletar para descubrir qué condiciones se encuentran disponibles en un tipo de recurso determinado al ingresar `kube_condition` y revisar los resultados. +> **Consejo**: utilice la función de autocompletar para descubrir qué condiciones están disponibles en un tipo de recurso determinado ingresando `kube_condition` y revisando los resultados. -#### Etiquetas (tags) específicas de recursos +#### Etiquetas específicas de recursos {#resource-specific-tags} -Algunos recursos tienen etiquetas (tags) específicas que se extraen en función del entorno de tu clúster. Las siguientes etiquetas (tags) se encuentran disponibles junto con las etiquetas (tags) que se compartieron anteriormente. +Algunos recursos tienen etiquetas específicas que se extraen según el entorno de su clúster. Las siguientes etiquetas están disponibles además de las etiquetas compartidas anteriores. -| Recurso | Etiquetas (tags) extraídas | +| Recurso | Etiquetas extraídas | |---|---| | **Clúster** | `api_server_version`
`kubelet_version` | -| **Definiciones de recursos personalizados** y
**Recursos personalizados** | `kube_crd_kind`
`kube_crd_group`
`kube_crd_version`
`kube_crd_scope`
`kube_crd_resource` | +| **Definiciones de recursos personalizados** &
**Recursos personalizados** | `kube_crd_kind`
`kube_crd_group`
`kube_crd_version`
`kube_crd_scope`
`kube_crd_resource` | | **Espacio de nombres** | `phase` | -| **Node** | `kube_node_unschedulable`
`kube_node_kubelet_version`
`kube_node_kernel_version`
`kube_node_runtime_version`
`eks_fargate_node`
`node_schedulable`
`node_status` | +| **Nodo** | `kube_node_unschedulable`
`kube_node_kubelet_version`
`kube_node_kernel_version`
`kube_node_runtime_version`
`eks_fargate_node`
`node_schedulable`
`node_status` | | **Volumen persistente** | `kube_reclaim_policy`
`kube_storage_class_name`
`pv_type`
`pv_phase` | -| **Demanda de volumen persistente** | `pvc_phase`
`kube_storage_class_name` | +| **Solicitud de volumen persistente** | `pvc_phase`
`kube_storage_class_name` | | **Pod** | `pod_name` (en lugar de `kube_pod`)
`pod_phase` (extraído del manifiesto)
`pod_status` (calculado de forma similar a `kubectl`) | | **Servicio** | `kube_service_type`
`kube_service_port` | -### Filtros de utilización de recursos +### Filtros de utilización de recursos {#resource-utilization-filters} -Los siguientes recursos de carga de trabajo están enriquecidos con métricas de utilización de recursos: +Los siguientes recursos de carga de trabajo se enriquecen con métricas de utilización de recursos: - Clústeres - Nodos - Pods -Estas métricas se calculan en el momento de la recopilación, en función de los valores promedio de los últimos 15 minutos. Puedes filtrar por valores de métrica de esta manera:`metric#`. +Estas métricas se calculan en el momento de la recopilación, según los valores promedio de los últimos 15 minutos. Puede filtrar por valores de métricas de la siguiente manera: `metric#`. -- `metric_name` es una métrica disponible (consulta más abajo) -- `comparator` es un [comparador](#comparator) compatible -- y `numeric_value` es un valor de coma flotante. +- `metric_name` es una métrica disponible (vea a continuación) +- `comparator` es un [comparador](#comparator) admitido +- y `numeric_value` es un valor de punto flotante. -Para los pods, están disponibles los siguientes nombres de métricas: +Para los Pods, están disponibles los siguientes nombres de métricas: | CPU | Memoria | |---|---| @@ -417,39 +757,38 @@ Para los pods, están disponibles los siguientes nombres de métricas: | `cpu_usage_pct_requests_avg15` | `mem_usage_pct_requests_avg15` | | `cpu_waste_avg15` | `mem_waste_avg15` | -Además, los clústeres y nodos tienen disponibles las siguientes métricas: +Además, los clústeres y los nodos tienen las siguientes métricas disponibles: - `cpu_usage_pct_alloc_avg15` - `cpu_requests_pct_alloc_avg15` - `mem_usage_pct_alloc_avg15` - `mem_requests_pct_alloc_avg15` -#### Unidades de métrica +#### Unidades de medida {#metric-units} -Las métricas de CPU se almacenan como varios núcleos. +Las métricas de CPU se almacenan como un número de núcleos. -Las métricas de memoria se almacenan como bytes. +Las métricas de memoria se almacenan en bytes. -Los porcentajes (`*_pct_*`) se almacenan como flotantes, donde `0.0` es 0 % y `1.0` es 100 %. El valor es la relación de las dos métricas indicadas; por ejemplo, `cpu_usage_pct_limits_avg15` es el valor de `usage / limits`. Los valores de métrica pueden estar por encima del 100 %, como el porcentaje de uso de CPU de las solicitudes. +Los porcentajes (`*_pct_*`) se almacenan como números de punto flotante, donde `0.0` es 0% y `1.0` es 100%. El valor es la proporción de las dos métricas indicadas; por ejemplo, `cpu_usage_pct_limits_avg15` es el valor de `usage / limits`. Los valores de las métricas pueden estar por encima del 100%, como el porcentaje de uso de CPU de las solicitudes. -## Notas y problemas conocidos +## Notas y problemas conocidos {#notes-and-known-issues} -* Los datos se actualizan automáticamente a intervalos constantes. -* En clústeres con más de 1000 despliegues o ReplicaSets, es posible que observes un uso elevado de CPU por parte del Cluster Agent. Hay una opción para deshabilitar la limpieza de contenedores en el Helm chart. Consulta [el repositorio de Helm chart][15] para obtener más detalles. +* Los datos se actualizan automáticamente en intervalos constantes. +* En clústeres con más de 1000 implementaciones (Deployments) o conjuntos de réplicas (ReplicaSets), es posible que note un mayor uso de CPU por parte del agente de clúster. Existe una opción para deshabilitar la limpieza de contenedor en el gráfico de Helm. Consulte [el repositorio del gráfico de Helm][11] para obtener más detalles. -## Referencias adicionales +## Lecturas adicionales {#further-reading} {{< partial name="whats-next/whats-next.html" >}} [1]: https://app.datadoghq.com/orchestration/overview -[2]: /es/infrastructure/containers/?tab=datadogoperator#setup -[9]: /es/logs -[10]: /es/metrics -[11]: /es/tracing -[12]: /es/events -[13]: /es/infrastructure/containers/kubernetes_resource_utilization -[15]: https://github.com/DataDog/helm-charts/tree/master/charts/datadog -[20]: /es/getting_started/tagging/assigning_tags/?tab=containerizedenvironments -[25]: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/ -[26]: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/ -[27]: https://kubernetes.io/docs/concepts/overview/working-with-objects/field-selectors/ \ No newline at end of file +[2]: /es/logs +[3]: /es/tracing +[4]: /es/metrics +[5]: /es/events +[6]: /es/infrastructure/containers/kubernetes_resource_utilization +[7]: /es/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/es/delivery_performance/dora_metrics/change_failure_detection/_index.md b/hugo/content/es/delivery_performance/dora_metrics/change_failure_detection/_index.md new file mode 100644 index 00000000000..fc57ea9d7ef --- /dev/null +++ b/hugo/content/es/delivery_performance/dora_metrics/change_failure_detection/_index.md @@ -0,0 +1,195 @@ +--- +aliases: +- /es/dora_metrics/change_failure_detection/ +description: Aprenda a configurar la detección de fallos en cambios en DORA Metrics + mediante rollbacks, revert PRs y filtros de PR personalizados. +further_reading: +- link: /delivery_performance/dora_metrics/ + tag: Documentación + text: Obtenga información sobre DORA Metrics +- link: /delivery_performance/dora_metrics/setup/ + tag: Documentación + text: Configure fuentes de datos para DORA Metrics +title: Detección de fallos en cambios +--- +{{< jqmath-vanilla >}} + +## Descripción general {#overview} + +La detección de fallos en cambios de Datadog identifica automáticamente las implementaciones que corrigen implementaciones fallidas anteriormente. Al vincular los fallos en cambios con las implementaciones de corrección, proporciona una visualización completa del rendimiento de entrega, ayudando a los equipos a equilibrar la velocidad de lanzamiento con la estabilidad operativa. + +Un **fallo en cambios** es una implementación que causa problemas en producción y requiere corrección. Los fallos en cambios se utilizan para calcular las siguientes métricas: + +- [Tasa de fallos en cambios][2] +: El porcentaje de implementaciones que causan problemas en producción, calculado de la siguiente manera: + + $$\\text\"Tasa de fallos en cambios\" = \\text\"Número de fallos en cambios\" / \\text\"Número total de implementaciones\"$$ + +- [Tiempo de recuperación de implementaciones fallidas][3] +: La duración mediana entre una implementación fallida y su corrección, ya sea mediante una implementación de reversión o de avance. + +La detección de fallos en cambios identifica dos tipos de implementaciones de corrección: +- **Reversiones**: Se detectan automáticamente cuando se vuelve a implementar una versión implementada anteriormente +- **Avances**: Se detectan mediante reglas personalizadas que coinciden con patrones de metadatos (como solicitudes de extracción de reversión y etiquetas de corrección rápida) + + +## Reversiones {#rollbacks} + +Una reversión ocurre cuando se vuelve a implementar una versión implementada anteriormente para restaurar el sistema después de un cambio fallido o defectuoso. + +### Cómo funciona la clasificación de reversiones {#how-rollback-classification-works} + +Una implementación se clasifica como reversión cuando implementa una versión que coincide con una versión implementada anteriormente pero que difiere de la implementación inmediatamente anterior. + +- Si los metadatos de Git están presentes, la coincidencia se basa en el SHA de la confirmación. +- Si los metadatos de Git no están presentes, la coincidencia se basa en la etiqueta de versión. + +Cuando se detecta una reversión, el fallo del cambio es la primera implementación después del objetivo de reversión (la versión a la que volvió). + +### Ejemplo: Detección de reversión {#example-rollback-detection} + +Para la secuencia V1 → V2 → V3 → V1, el objetivo de reversión es la V1 original, por lo que V2 se marca como el fallo del cambio y V1 como una implementación de reversión. + +{{< img src="delivery_performance/dora_metrics/rollback_example.png" alt="Un ejemplo de una implementación de reversión detectada" style="width:100%;" >}} + +**Nota**: Volver a implementar la misma versión consecutivamente (por ejemplo, V1 → V1) no se considera una reversión. + +## Avances {#rollforwards} + +Un avance ocurre cuando se realiza una nueva implementación para corregir o anular un cambio fallido o defectuoso. A diferencia de las reversiones (que vuelven a implementar una versión anterior), los avances implementan código nuevo para solucionar problemas. Esto puede incluir pull requests de revertir que restauran el comportamiento anterior a través de una nueva versión. + +Los avances se detectan mediante reglas personalizadas que coinciden con los patrones de metadatos de implementación. Las reglas personalizadas se configuran en la [página de configuración de DORA][1]. + +## Reglas personalizadas {#custom-rules} + +Puede definir reglas personalizadas para clasificar automáticamente las implementaciones de avance según los metadatos del repositorio o de la versión. Las reglas pueden funcionar de dos maneras: +- **Vinculación de implementaciones**: Coincidir implementaciones a través de valores de variables compartidos (por ejemplo, número de PR o versión) +- **Patrones estáticos**: Coincidir patrones de metadatos sin variables (por ejemplo, etiquetas o nombres de rama) + +### Reglas vinculadas a implementaciones fallidas {#rules-linked-to-failed-deployments} + +Utilice estas reglas para identificar las implementaciones rollforward que deben vincularse a una implementación fallida anterior específica. Estas reglas utilizan patrones de expresiones regulares (regex) con variables para hacer coincidir implementaciones a través de referencias compartidas. + +Puede ingresar reglas de regex que incluyan una de estas variables: +| Variable | Descripción | +|---------------|-----------------------| +| `$pr_title` | Coincide con títulos de PR | +| `$pr_number` | Coincide con números de PR | +| `$version` | Coincide con etiquetas de versión | + +#### Cómo funciona la clasificación basada en variables {#how-variable-based-classification-works} + +Cuando una regla coincide con una implementación, ocurren las siguientes acciones: +1. El valor de la variable se extrae de la implementación actual. +2. El sistema encuentra la implementación anterior con el mismo valor extraído. +3. La implementación actual se marca como un avance vinculado a esa implementación anterior. +4. La implementación anterior se marca como el fallo de cambio. + +Estas reglas funcionan mejor cuando la implementación fallida puede identificarse mediante un SHA de confirmación, una etiqueta de versión o una referencia de PR compartidos. + +#### Ejemplo: Revertir solicitudes de extracción {#example-revert-pull-requests} + +Las solicitudes de extracción de reversión son un patrón de recuperación común. Por ejemplo, una PR titulada `Revert "Add feature X"` hace referencia a la PR original. + +``` +Revert "$pr_title" +``` + +Cuando el título de una PR coincide con este patrón, ocurren las siguientes acciones: +1. El sistema extrae el título de la PR original de la PR de reversión (el valor de `$pr_title`). +2. Encuentra la implementación anterior que incluye ese título de PR original. +3. El despliegue actual (con la reversión) está marcado como el avance. +4. La implementación anterior se marca como el fallo de cambio. + +**Nota**: Si el PR original no se encuentra en ningún despliegue anterior, o si tanto el PR original como su reversión están en el mismo despliegue, no se aplica ninguna clasificación. + +### Reglas estáticas {#static-rules} + +Las reglas estáticas clasifican los despliegues de avance (rollforward) basándose en patrones de metadatos sin utilizar variables. Estas reglas coinciden con indicadores generales de remediación. + +Puede definir reglas de expresiones regulares que coincidan con tipos específicos de metadatos. La siguiente tabla muestra algunos patrones de ejemplo que puede utilizar, pero puede ajustarlos para que se adapten a sus procesos: + +| Tipo de metadatos | Patrón de Regex de ejemplo | Descripción | +|------------------|------------------------|-------------------------------------| +| **Título de PR** | `.*rollforward.*` | Coincide con títulos de PR que contienen `rollforward` | +| **Etiqueta de PR** | `.*hotfix.*` | Coincide con etiquetas de PR que contienen `hotfix` | +| **Nombre de rama de PR** | `recovery/.*` | Coincide con nombres de rama que comienzan con `recovery/`| +| **Mensaje de confirmación** | `^Revert ".*"$ ` | Coincide con mensajes de confirmación que comienzan con `Revert` y terminan con `"`| +| **Etiqueta de versión** | `.*_hotfix` | Coincide con etiquetas de versión que terminan con `_hotfix` | + +#### Cómo funciona la clasificación de reglas estáticas {#how-static-rule-classification-works} + +Cuando una regla estática coincide con un despliegue, ocurren las siguientes acciones: +1. El despliegue actual está marcado como un avance. +2. El despliegue inmediatamente anterior está marcado como el fallo de cambio. + +Utilice reglas estáticas para indicadores generales de remediación como etiquetas de hotfix, prefijos de rama o convenciones de etiquetas de versión. + + +### Reglas predeterminadas {#default-rules} + +Datadog proporciona reglas predeterminadas que se habilitan automáticamente: + +- **Revertir PRs**: Los títulos de PR que siguen las convenciones de nomenclatura de reversión (por ejemplo, "Revert" haciendo referencia a un PR anterior) se tratan como avances. La implementación anterior que contiene el cambio original está marcada como el fallo de cambio, utilizando las reglas de vinculación basadas en variables descritas anteriormente. +- **Indicadores de corrección rápida**: Las etiquetas, títulos o nombres de rama de PR que contienen "hotfix" se tratan como avances, y la implementación anterior se marca como la falla de cambio. + +Estas reglas predeterminadas son totalmente configurables en la página de [configuración de DORA Metrics][1]. Están pensadas como puntos de partida basados en opiniones que interpretan señales comunes como una actividad probable de avance. Debe adaptar los patrones (como convenciones de nomenclatura, etiquetas o etiquetas de versión) según sea necesario para reflejar sus propios flujos de trabajo y mejorar la precisión con el tiempo. + +## Actualizar el estado de la implementación {#update-deployment-status} + +Aunque la detección automática y las reglas personalizadas manejan la mayoría de los casos, aún puede actualizar manualmente el estado de una implementación para marcarla como una falla de cambio o marcar una falla de cambio como estable. + +### Cuándo actualizar el estado de la implementación {#when-to-update-deployment-status} + +Considere actualizar manualmente el estado de una implementación en los siguientes escenarios: +- Una implementación causó problemas en producción pero no se detectó como una falla de cambio. +- Una implementación se clasificó incorrectamente como una falla de cambio (falso positivo). +- Necesita reflejar inmediatamente el estado correcto para fines de informes. + +### Actualizar el estado a través de la API {#update-status-through-the-api} + +Utilice la [DORA Metrics API][4] para actualizar el estado de una implementación mediante programación. El siguiente ejemplo marca una implementación como una falla de cambio y la vincula a una corrección de reversión: + +```shell +curl -X PATCH "https://api.datadoghq.com/api/v2/dora/deployment/{deployment_id}" \ +-H "Accept: application/json" \ +-H "Content-Type: application/json" \ +-H "DD-API-KEY: ${DD_API_KEY}" \ +-d @- << EOF +{ + "data": { + "attributes": { + "change_failure": true, + "remediation": { + "id": "eG42zNIkVjM", + "type": "rollback" + } + }, + "id": "z_RwVLi7v4Y", + "type": "dora_deployment_patch_request" + } +} +EOF +``` + +El campo `remediation` es opcional, pero es necesario para calcular el tiempo de recuperación de una implementación fallida. + +### Actualizar el estado a través de la UI {#update-status-through-the-ui} + +Para actualizar el estado de una implementación desde la Datadog UI: + +1. Vaya a {{< ui >}}Software Delivery{{< /ui >}} > {{< ui >}}DORA Metrics{{< /ui >}} y haga clic en [{{< ui >}}View Deployments{{< /ui >}}][5]. +2. Haga clic en una implementación para abrir el panel de detalles de la implementación. +3. En el panel de detalles de la implementación, seleccione el {{< ui >}}Deployment status{{< /ui >}} del dropdown para marcar la implementación como fallida o estable. + +{{< img src="delivery_performance/dora_metrics/deployment_status_update.mp4" alt="Actualización del estado de falla de cambio de una implementación desde la Datadog UI" video="true" >}} + +## Lecturas adicionales {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://app.datadoghq.com/ci/settings/dora +[2]: /es/delivery_performance/dora_metrics/calculation/#change-failure-rate +[3]: /es/delivery_performance/dora_metrics/calculation/#failed-deployment-recovery-time +[4]: /es/api/latest/dora-metrics/#patch-a-deployment-event +[5]: https://app.datadoghq.com/ci/dora?detail=deployments \ No newline at end of file diff --git a/hugo/content/es/feature_flags/guide/apm_trace_enrichment.md b/hugo/content/es/feature_flags/guide/apm_trace_enrichment.md new file mode 100644 index 00000000000..4aef39be93b --- /dev/null +++ b/hugo/content/es/feature_flags/guide/apm_trace_enrichment.md @@ -0,0 +1,208 @@ +--- +description: Adjunte automáticamente datos de evaluación de feature flags a las trazas + de APM para que pueda inspeccionar y filtrar trazas por variante de feature flag. +further_reading: +- link: /feature_flags/server/ + tag: Documentación + text: Feature Flags del lado del servidor +- link: /feature_flags/guide/server_flag_evaluation_metrics/ + tag: Guía + text: Configure las métricas de evaluación de flags del lado del servidor +- link: /tracing/trace_explorer/ + tag: Documentación + text: Trace Explorer +title: Configure el enriquecimiento de trazas de APM para Feature Flags +--- +## Descripción general {#overview} + +El enriquecimiento de trazas de APM adjunta automáticamente datos de evaluación de feature flags a sus trazas de APM. Cuando se evalúa una feature flag durante una solicitud rastreada, el SDK registra qué feature flags se evaluaron y qué variantes se devolvieron. Estos datos se escriben en el tramo raíz y se procesan en el lado del servidor para que usted pueda: + +- **Filtrar trazas por variante de feature flag** en [Trace Explorer][1] usando `@feature_flags.:` facetas. +- **Depurar problemas relacionados con feature flags** al ver qué feature flags estaban activas cuando ocurrió un error. + +
El enriquecimiento de trazas de APM es experimental y puede cambiar en una versión futura.
+ +El enriquecimiento de trazas de APM está disponible en los siguientes SDKs: + +| Lenguaje | Versión mínima | +| -------- | --------------- | +| Go | 2.8.0 | +| Java | 1.64.1 | +| Node.js | 5.105.0 | + +## Requisitos previos {#prerequisites} + +Antes de configurar el enriquecimiento de trazas de APM, confirme lo siguiente: + +- Las feature flags del lado del servidor ya están configuradas y las feature flags se están evaluando en su aplicación. +- [APM tracing][3] está habilitado y las trazas están llegando a Datadog. + +## Cómo funciona el enriquecimiento de trazas de APM {#how-apm-trace-enrichment-works} + +Cuando el enriquecimiento de trazas de APM está habilitado, el proveedor de OpenFeature de Datadog se conecta al ciclo de vida de evaluación: + +1. Cada vez que se evalúa una feature flag, el SDK captura los metadatos de evaluación (ID de serie de la feature flag, clave de segmentación y valor de respaldo predeterminado). +2. Los metadatos se acumulan en el tramo raíz de la traza actual. +3. Cuando el tramo raíz finaliza, el SDK escribe los datos acumulados como etiquetas de tramo compactas (`ffe_flags_enc`, `ffe_subjects_enc`, `ffe_runtime_defaults`). +4. El backend de Datadog decodifica estas etiquetas y escribe `@feature_flags.` facetas legibles por humanos en el tramo, haciéndolas buscables en Trace Explorer. + +Las etiquetas del lado del SDK son solo para transporte y se eliminan en el lado del servidor. Las etiquetas visibles para usted en Trace Explorer son las `@feature_flags.` facetas decodificadas. + +## Habilitar el enriquecimiento de trazas de APM {#enable-apm-trace-enrichment} + +Establezca la siguiente variable de entorno para habilitar el enriquecimiento de tramos: + +{{< code-block lang="bash" >}} +DD_EXPERIMENTAL_FLAGGING_PROVIDER_SPAN_ENRICHMENT_ENABLED=true +{{< /code-block >}} + +La variable de entorno de enriquecimiento es compatible con todos los SDK del lado del servidor admitidos. No se requieren cambios en el código. Habilitar la variable activa el gancho de enriquecimiento automáticamente cuando se inicializa el proveedor de OpenFeature de Datadog. Node.js también admite la configuración a nivel de código como se muestra en las pestañas de lenguaje a continuación. + +### Configuración específica del lenguaje {#language-specific-configuration} + +{{< tabs >}} +{{% tab "Go" %}} + +No se necesita configuración de código adicional. La variable de entorno `DD_EXPERIMENTAL_FLAGGING_PROVIDER_SPAN_ENRICHMENT_ENABLED` habilita el enriquecimiento de tramos cuando se inicializa `DatadogProvider`. + +{{< code-block lang="go" filename="main.go" >}} +package main + +import ( + "log" + + "github.com/DataDog/dd-trace-go/v2/ddtrace/tracer" + ddopenfeature "github.com/DataDog/dd-trace-go/v2/openfeature" + "github.com/open-feature/go-sdk/openfeature" +) + +func main() { + tracer.Start() + defer tracer.Stop() + + provider, err := ddopenfeature.NewDatadogProvider(ddopenfeature.ProviderConfig{}) + if err != nil { + log.Fatalf("Failed to create provider: %v", err) + } + if ddProvider, ok := provider.(*ddopenfeature.DatadogProvider); ok { + defer ddProvider.Shutdown() + } + + if err := openfeature.SetProviderAndWait(provider); err != nil { + log.Fatalf("Failed to set provider: %v", err) + } + + client := openfeature.NewClient("my-service") + // Flag evaluations now enrich APM spans automatically +} +{{< /code-block >}} + +{{% /tab %}} +{{% tab "Java" %}} + +No se necesita configuración de código adicional. La variable de entorno `DD_EXPERIMENTAL_FLAGGING_PROVIDER_SPAN_ENRICHMENT_ENABLED` habilita el enriquecimiento de tramos. Java también admite la propiedad del sistema `-Ddd.experimental.flagging.provider.span.enrichment.enabled=true` como alternativa. + +{{< code-block lang="java" filename="Main.java" >}} +import dev.openfeature.sdk.OpenFeatureAPI; +import dev.openfeature.sdk.Client; +import datadog.trace.api.openfeature.Provider; + +OpenFeatureAPI api = OpenFeatureAPI.getInstance(); +api.setProviderAndWait(new Provider()); +Client client = api.getClient("my-app"); +// Flag evaluations now enrich APM spans automatically +{{< /code-block >}} + +{{% /tab %}} +{{% tab "Node.js" %}} + +También puede habilitar el enriquecimiento de tramos en el código: + +{{< code-block lang="javascript" filename="app.js" >}} +import tracer from 'dd-trace'; + +tracer.init({ + experimental: { + flaggingProvider: { + enabled: true, + spanEnrichment: { + enabled: true, + }, + }, + }, +}); +{{< /code-block >}} + +{{% /tab %}} +{{< /tabs >}} + +## Verificar el enriquecimiento de trazas de APM {#verify-apm-trace-enrichment} + +Después de implementar con el enriquecimiento de tramos habilitado: + +1. Genere solicitudes en su aplicación que evalúen las feature flags. +2. Vaya a [Trace Explorer][1] y busque una traza reciente de su servicio. +3. Abra una traza y busque los atributos `@feature_flags.` en el tramo raíz. + +El SDK escribe etiquetas codificadas compactas (`ffe_flags_enc`, `ffe_subjects_enc`, `ffe_runtime_defaults`) en el tramo raíz. El backend de Datadog decodifica estos y produce facetas `@feature_flags.` legibles por humanos. Este procesamiento toma unos segundos después de que se ingiere el tramo. + +Después del procesamiento del backend, el tramo raíz contiene atributos como los siguientes ejemplos: + +| Atributo de ejemplo | Valor de ejemplo | +| --------- | ------------- | +| `@feature_flags.checkout-flow` | `treatment` | +| `@feature_flags.dark-mode` | `control` | + +Cada clave de atributo es `@feature_flags.` y el valor es la variante devuelta por la evaluación. + +### Solución de problemas {#troubleshooting} + +Si los atributos `@feature_flags.` no aparecen en sus trazas: + +- Confirme que el enriquecimiento de tramo esté habilitado (`DD_EXPERIMENTAL_FLAGGING_PROVIDER_SPAN_ENRICHMENT_ENABLED=true`). +- Verifique que su aplicación esté evaluando feature flags durante las solicitudes rastreadas. El enriquecimiento solo ocurre cuando se evalúa una feature flag mientras una traza está activa. +- Espere unos segundos después de que se ingiera el tramo. Las facetas `@feature_flags.` se derivan del procesamiento del backend y no aparecen en los metadatos sin procesar del tramo. +- Para depurar, inspeccione los metadatos sin procesar del tramo para buscar la etiqueta `ffe_flags_enc`. Si esta etiqueta está presente, el SDK está emitiendo datos de enriquecimiento. O el backend aún no lo ha procesado, o la feature flag gate no está habilitada para su organización. +- Si las feature flags no se están evaluando en absoluto, consulte [Server-Side Feature Flags][2] para obtener información sobre la configuración y la solución de problemas específica del lenguaje. + +## Buscar y filtrar por variante de Feature Flag {#search-and-filter-by-flag-variant} + +Estos ejemplos utilizan las facetas `@feature_flags.` para filtrar trazas en Trace Explorer: + +| Incidencia | Ejemplo de consulta | +| -------- | ------------- | +| Trazas para una variante específica de Feature Flag | `@feature_flags.checkout-flow:treatment` | +| Errores bajo una variante de Feature Flag | `@feature_flags.checkout-flow:treatment status:error` | +| Cualquier traza donde se evaluó una Feature Flag | `@feature_flags.checkout-flow:*` | +| Múltiples Feature Flags en la misma solicitud | `@feature_flags.checkout-flow:treatment @feature_flags.new-search:enabled` | +| Con alcance a servicio y entorno | `env:production service:api-gateway @feature_flags.rate-limit-v2:enabled` | + +## Utilice trazas enriquecidas en todo Datadog {#use-enriched-traces-across-datadog} + +Los atributos de las Feature Flags en las trazas están disponibles en todo Datadog: + +- **Monitores**: Alertar cuando el recuento de errores para una variante específica supere un umbral para detectar regresiones específicas de la variante. +- **Dashboards**: Agregue un widget de series temporales que compare la latencia p99 entre variantes utilizando `@feature_flags.` como dimensión de agrupación. +- **Notebooks**: Cree un notebook de investigación que compare el rendimiento entre variantes de Feature Flag. +- **Visualizaciones**: Utilice la Top List view en Trace Explorer para verificar que la distribución del tráfico de despliegue coincida con sus reglas de segmentación. + +## Límites {#limits} + +El SDK aplica los siguientes límites por tramo para restringir el tamaño de la carga útil: + +| Límite | Valor | +| ----- | ----- | +| IDs de serie de Feature Flag por tramo | 128 a 200 (varía según el SDK) | +| Asuntos por tramo | 10 a 25 (varía según el SDK) | +| Claves predeterminadas de tiempo de ejecución por tramo | 5 | +| Longitud predeterminada del valor de tiempo de ejecución | 64 caracteres (truncado) | + +Las evaluaciones que excedan estos límites se descartarán para ese tramo. + +## Lecturas adicionales {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /es/tracing/trace_explorer/ +[2]: /es/feature_flags/server/ +[3]: /es/tracing/ \ No newline at end of file diff --git a/hugo/content/es/incident_response/incident_management/investigate/declare.md b/hugo/content/es/incident_response/incident_management/investigate/declare.md new file mode 100644 index 00000000000..5cb5ec11837 --- /dev/null +++ b/hugo/content/es/incident_response/incident_management/investigate/declare.md @@ -0,0 +1,133 @@ +--- +aliases: +- /es/service_management/incident_management/declare/ +- /es/incident_response/incident_management/declare +title: Declarar un incidente +--- +## Descripción general {#overview} + +En el paradigma de Datadog, cualquiera de las siguientes son situaciones apropiadas para declarar un incidente: +- Un problema está afectando o podría estar afectando a los clientes. +- Usted considera que un problema (incluido uno interno) debe abordarse como una emergencia. +- No sabe si debe declarar un incidente: notifique a otras personas y aumente la gravedad según corresponda. + +Puede declarar un incidente desde varios lugares dentro de la plataforma Datadog, como un widget de gráfico en un tablero, la interfaz de usuario de Incidentes o cualquier alerta que se informe en Datadog. + +## Modal de declaración {#declaration-modal} + +Cuando declara un incidente, aparece un modal de declaración. Este modal tiene varios elementos principales: + +| Elementos del incidente | Descripción | +| ------------------ | ----------- | +| Título | (Obligatorio) Un título descriptivo para el incidente. | +| Nivel de gravedad | (Obligatorio) De forma predeterminada, la gravedad varía de SEV-1 (la más grave) a SEV-5 (la menos grave). Puede personalizar el número de niveles de gravedad y sus descripciones en la configuración de Incident Management. +| Comandante de incidentes | La persona asignada para dirigir la respuesta al incidente. | + +Puede configurar [Incident Management Settings][2] para incluir más campos en el modal de declaración de incidentes o requerir ciertos campos. + + +## Desde la página de Incidentes {#from-the-incident-page} + +En la [Datadog UI][1], haga clic en **Declare Incident** para crear un incidente. + +El modal *Declare Incident* muestra un panel lateral plegable que contiene texto auxiliar y descripciones de los niveles de gravedad y estados utilizados por su organización. El texto de ayuda y las descripciones se pueden personalizar en [Incident Settings][2]. + +## Desde un monitor {#from-a-monitor} + +Puede declarar un incidente directamente desde un monitor. Seleccione **Declare incident** para abrir un modal de creación de incidentes, y el monitor se agregará al incidente como una señal. También puede agregar un monitor a un incidente existente. + +{{< img src="incident_response/incident_management/investigate/declare/declare_monitor.png" alt="Menú desplegable de acciones en los monitores donde puede seleccionar la opción Declarar incidente." style="width:50%;" >}} + +Alternativamente, puede hacer que un monitor cree automáticamente un incidente cuando pase a un estado de `warn`, `alert` o `no data`. Para habilitar esto, haga clic en **Add Incident** en la sección **Configure notifications and automations** de un monitor y seleccione una opción de `@incident-`. Los administradores pueden crear opciones de `@incident-` en [Incident Settings][9]. + +Los incidentes creados desde un monitor heredarán [field values][10] de las etiquetas del monitor. Para enviar notificaciones automatizadas desde incidentes, agregue etiquetas a un monitor para que los incidentes creados coincidan con los criterios de [notification rules][11]. + +## Desde una señal de Security {#from-a-security-signal} + +Declare un incidente directamente desde el panel lateral de una señal de Cloud SIEM o Workload Protection, haciendo clic en **Declarar incidente** o **Escalar investigación**. Para obtener más información, consulte [Investigate Security Signals][3]. + +Declare un incidente desde una señal de App and API Protection a través de las acciones enumeradas en el panel lateral de la señal. Haga clic en **Mostrar todas las acciones** y haga clic en **Declarar incidente**. +Para obtener más información, consulte [Investigate Security Signals][4] para App and API Protection. + +{{< img src="/incident_response/incident_management/investigate/declare/declare_asm.png" alt="Descripción de su imagen" style="width:90%;" >}} + +## Desde un secreto filtrado {#from-a-leaked-secret} + +Declare un incidente desde [Secret Scanning][15] haciendo clic en **Declarar incidente** en el panel lateral de detección. El incidente se pre-llena con todos los metadatos de detección. + +{{< img src="/incident_response/incident_management/investigate/declare/declare-secrets.png" alt="Descripción de su imagen" style="width:90%;" >}} + +## Desde un elemento de trabajo {#from-a-work-item} + +Declare un incidente desde [Work Management][5]. Desde la página de detalles del elemento de trabajo individual, haga clic en **Declarar incidente** para escalar un elemento de trabajo a un incidente. + +## Desde un gráfico {#from-a-graph} +Puede declarar un incidente directamente desde un gráfico haciendo clic en el botón de exportación en el gráfico y luego haciendo clic en **Declarar incidente**. Aparece el modal de creación de incidentes y el gráfico se añade al incidente como una señal. + +{{< img src="incident_response/incident_management/from-a-graph.png" alt="Cree un incidente desde un gráfico" style="width:80%;">}} + +## Desde una prueba Synthetic {#from-a-synthetic-test} + +Cree incidentes directamente desde una [prueba Synthetic][8] a través del menú desplegable Acciones. Seleccione **Declarar incidente** para abrir un modal de creación de incidentes, donde se añade un resumen de la prueba a la línea de tiempo de su incidente, lo que le permite continuar la investigación desde allí. + +{{< img src="incident_response/incident_management/investigate/declare/synthetics_declare_incident.png" alt="Declare un incidente desde una prueba Synthetic." style="width:90%;" >}} + +## Desde el portapapeles de Datadog {#from-the-datadog-clipboard} +Utilice el [portapapeles de Datadog][6] para recopilar varios monitores y gráficos y generar un incidente. Para declarar un incidente desde el portapapeles, copie un gráfico que desee investigar y abra el portapapeles con el comando `Cmd/Ctrl + Shift + K`. Haga clic en **Declarar incidente** o en el icono de exportación para añadirlo al incidente como una señal. + +{{< img src="incident_response/incident_management/investigate/declare/declare_clipboard.png" alt="Declare un incidente desde el portapapeles de Datadog" style="width:90%;" >}} + +## Desde una página de Datadog On-Call {#from-a-datadog-on-call-page} + +Puede declarar un incidente directamente desde una [página de Datadog On-Call][12]. Desde la [lista de páginas de On-Call][13], seleccione una página y haga clic en **Declare Incident** para crear un incidente y asociarlo automáticamente con el equipo de On-Call correspondiente. + +## Desde Slack {#from-slack} + +Si tiene la [integración de Datadog habilitada en Slack][7], puede declarar un nuevo incidente con el comando de barra diagonal `/datadog incident` desde cualquier canal de Slack. + +Si el usuario que declara el incidente conectó su Slack a su cuenta de Datadog, de forma predeterminada, ese usuario aparece como el Comandante del Incidente. El Comandante del Incidente (IC) puede cambiarse más tarde en la aplicación si es necesario. Si el usuario que declara un incidente no es miembro de una cuenta de Datadog, entonces el IC se asigna a un `Slack app user` genérico y puede asignarse a otro IC en la aplicación. + +{{< img src="incident_response/incident_management/from-slack.png" alt="Cree un incidente desde Slack." style="width:60%;">}} + +Después de declarar un incidente desde Slack, se genera un canal de incidentes. + +## Desde Google Chat {#from-google-chat} + +Si ha configurado la [integración de Datadog para Google Chat][14], puede declarar un incidente con el comando de barra diagonal `/dd_incident` desde cualquier espacio de Google Chat. + +## Desde Notifications de transferencia {#from-handoff-notifications} + +La Notifications de transferencia muestra tarjetas de aviso cuando se le página o se le agrega a incidentes activos. Estas tarjetas le permiten: + +- Ver y reconocer páginas de On-Call +- Navegar a los recursos relevantes del incidente +- Previsualizar mensajes de Slack de los canales de incidentes +- Tomar medidas directas sobre los incidentes + +{{< img src="/incident_response/incident_management/investigate/declare/handoff_notification_card.png" alt="Tarjeta de Notifications de transferencia que muestra los detalles del incidente con opciones para ver, reconocer y tomar medidas" style="width:100%;" >}} + +Las tarjetas de Notifications de transferencia permanecen visibles hasta que se descartan o hasta que cambia el estado del incidente. Puede expandir, contraer o descartar todo el contenedor de transferencia en lugar de tarjetas individuales. + +Puede declarar un incidente desde tarjetas individuales de Notifications de transferencia. + +## ¿Qué sigue? {#whats-next} + +{{< whatsnext desc="Agregue información útil a su incidente y proporcione contexto a todos los involucrados en la investigación.">}} + {{< nextlink href="/incident_response/incident_management/investigate/describe" >}}Describa el incidente: agregue contexto y detalles{{< /nextlink >}} +{{< /whatsnext >}} + +[1]: https://app.datadoghq.com/incidents +[2]: /es/incident_response/incident_management/setup_and_configuration/information +[3]: /es/security/workload_protection/investigate_and_triage/security_signals/actions/#declare-an-incident +[4]: /es/security/application_security/threat_protection/security_signals/#declare-an-incident +[5]: /es/incident_response/work_management/view_and_manage +[6]: /es/dashboards/guide/datadog_clipboard +[7]: /es/integrations/slack/?tab=slackapplicationbeta#using-the-slack-app +[8]: https://app.datadoghq.com/synthetics/tests +[9]: https://app.datadoghq.com/incidents/settings?section=global-settings +[10]: /es/incident_response/incident_management/setup_and_configuration/property_fields +[11]: /es/incident_response/incident_management/setup_and_configuration/notification_rules +[12]: /es/incident_response/on-call/ +[13]: https://app.datadoghq.com/on-call/pages +[14]: /es/integrations/google-hangouts-chat/ +[15]: /es/security/code_security/secret_scanning/ \ No newline at end of file diff --git a/hugo/content/es/incident_response/work_management/_index.md b/hugo/content/es/incident_response/work_management/_index.md index 73c0d4432e6..6eb2c2c3c47 100644 --- a/hugo/content/es/incident_response/work_management/_index.md +++ b/hugo/content/es/incident_response/work_management/_index.md @@ -31,6 +31,9 @@ further_reading: - link: https://www.datadoghq.com/blog/datadog-service-management/ tag: Blog text: Garantice una alta disponibilidad del servicio con Datadog Service Management +- link: https://www.datadoghq.com/blog/work-management/ + tag: Blog + text: Centralice el trabajo humano y de agent con Datadog Work Management title: Work Management ---
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.
diff --git a/hugo/content/es/llm_observability/build_with_ai/mcp_server.md b/hugo/content/es/llm_observability/build_with_ai/mcp_server.md new file mode 100644 index 00000000000..c14c4c96803 --- /dev/null +++ b/hugo/content/es/llm_observability/build_with_ai/mcp_server.md @@ -0,0 +1,534 @@ +--- +aliases: +- /es/llm_observability/mcp_server/ +description: Conecte agentes de IA a sus trazas y experimentos de Agent Observability + mediante el Datadog MCP Server. +further_reading: +- link: mcp_server + tag: Documentación + text: Datadog MCP Server +- link: /llm_observability/improve/experiments + tag: Documentación + text: Configurar y utilizar experimentos de Agent Observability +- link: /llm_observability/investigate + tag: Documentación + text: Monitoree su aplicación con Agent Observability +- link: /llm_observability/build_with_ai/claude_code_skills + tag: Guía + text: Analizar aplicaciones de LLM con habilidades de Claude Code +- link: https://www.datadoghq.com/blog/debug-and-evaluate-your-ai-app-from-your-coding-agent/ + tag: Blog + text: Depure y evalúe su aplicación de IA desde su agente de codificación con Datadog + Agent Observability +- link: https://www.datadoghq.com/blog/bits-evals/ + tag: Blog + text: Mejore la calidad de los agentes de IA con Bits Evals +title: MCP y habilidades de Agent Observability +--- +## Descripción general {#overview} + +El [Datadog MCP Server][1] permite que los agentes de IA accedan a sus datos de [Agent Observability][2] a través del Model Context Protocol (MCP). El conjunto de herramientas `llmobs` proporciona herramientas para buscar y analizar trazas, inspeccionar detalles y contenido de tramos, y evaluar resultados de experimentos directamente desde clientes basados en IA como Cursor, Claude Code u OpenAI Codex. + +## Configuración {#setup} + +Conecte un cliente compatible con MCP al Datadog MCP Server con el conjunto de herramientas `llmobs` habilitado. + +
Para obtener instrucciones de configuración completas, incluida la configuración de la extensión de Cursor y VS Code, consulte Configurar el Datadog MCP Server.
+ +### Requisitos previos {#prerequisites} + +- Una cuenta de Datadog con permiso para acceder a los datos de Agent Observability. +- Un cliente compatible con MCP (por ejemplo, Claude Code, Codex CLI, Cursor, Gemini CLI o Kiro CLI). + +### Punto de conexión {#endpoint} + +El punto de conexión del servidor MCP depende de su [sitio de Datadog][5]. Utilice el selector {{< ui >}}Datadog Site{{< /ui >}} para mostrar el punto de conexión de su sitio. Agregue `?toolsets=llmobs,core` para habilitar Agent Observability y los conjuntos de herramientas principales. + +{{< site-region region="us,us3,us5,eu,ap1,ap2,uk1" >}} +Punto de conexión para el sitio seleccionado ({{< region-param key="dd_site_name" >}}): +
{{< region-param key="mcp_server_endpoint" >}}?toolsets=llmobs,core
+{{< /site-region >}} + +{{< site-region region="gov,gov2" >}} +
Este producto no es compatible con el sitio seleccionado ({{< region-param key="dd_site_name" >}}).
+{{< /site-region >}} + +### Conectar {#connect} + +Elija la autenticación remota cuando sea posible. Utilice la autenticación binaria local si su entorno bloquea el flujo de OAuth remoto. + +{{< tabs >}} +{{% tab "Autenticación remota" %}} + +{{< site-region region="us,us3,us5,eu,ap1,ap2,uk1" >}} +La autenticación remota utiliza el transporte [Streamable HTTP][1] de la especificación MCP. + +**Claude Code** (línea de comandos): + +
claude mcp add --transport http datadog-mcp "{{< region-param key="mcp_server_endpoint" >}}?toolsets=llmobs,core"
+ +**Codex CLI** (`~/.codex/config.toml`): + +
[mcp_servers.datadog]
+url = "{{< region-param key="mcp_server_endpoint" >}}"
+http_headers = { "X-Datadog-MCP-Toolsets" = "llmobs,core" }
+
+ +Después de agregar la configuración, ejecute `codex mcp login datadog` para completar el flujo de OAuth. + +**Gemini CLI, Kiro CLI y otros clientes compatibles con MCP**: + +
{
+  "mcpServers": {
+    "datadog": {
+      "type": "http",
+      "url": "{{< region-param key="mcp_server_endpoint" >}}?toolsets=llmobs,core"
+    }
+  }
+}
+
+ +[1]: https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#streamable-http +{{< /site-region >}} + +{{< site-region region="gov,gov2" >}} +
Este producto no es compatible con el sitio seleccionado ({{< region-param key="dd_site_name" >}}).
+{{< /site-region >}} + +{{% /tab %}} + +{{% tab "Autenticación binaria local" %}} + +La autenticación binaria local utiliza el transporte [stdio][2] de la especificación MCP. Utilice este método si la autenticación remota no está disponible. + +1. Instale el binario de Datadog MCP Server: + + ```bash + curl -sSL https://coterm.datadoghq.com/mcp-cli/install.sh | bash + ``` + + The binary installs to `~/.local/bin/datadog_mcp_cli`. + +2. Complete el flujo de inicio de sesión de OAuth: + + ```bash + datadog_mcp_cli login + ``` + +3. Configure su cliente de IA. Para Claude Code, agregue lo siguiente a `~/.claude.json`, reemplazando `` en la ruta del comando: + + ```json + { + "mcpServers": { + "datadog": { + "type": "stdio", + "command": "/Users//.local/bin/datadog_mcp_cli", + "args": [], + "env": {} + } + } + } + ``` + + Alternatively, add the server with the Claude Code CLI: + + ```bash + claude mcp add datadog --scope user -- ~/.local/bin/datadog_mcp_cli + ``` + +[2]: https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#stdio +{{% /tab %}} +{{< /tabs >}} + +### Autentíquese con claves de API {#authenticate-with-api-keys} + +El servidor MCP utiliza OAuth 2.0 de forma predeterminada. Si OAuth no está disponible, envíe una [clave de API y clave de aplicación][6] de Datadog como los encabezados HTTP `DD_API_KEY` y `DD_APPLICATION_KEY`: + +{{< site-region region="us,us3,us5,eu,ap1,ap2,uk1" >}} +
{
+  "mcpServers": {
+    "datadog": {
+      "type": "http",
+      "url": "{{< region-param key="mcp_server_endpoint" >}}?toolsets=llmobs,core",
+      "headers": {
+          "DD_API_KEY": "<YOUR_API_KEY>",
+          "DD_APPLICATION_KEY": "<YOUR_APPLICATION_KEY>"
+      }
+    }
+  }
+}
+
+{{< /site-region >}} + +{{< site-region region="gov,gov2" >}} +
Este producto no es compatible con el sitio seleccionado ({{< region-param key="dd_site_name" >}}).
+{{< /site-region >}} + +Por seguridad, limite la clave de API y la clave de aplicación a una [cuenta de servicio][7] con solo los permisos necesarios. + +## Agent skills {#agent-skills} + +Agent skills son conjuntos de instrucciones predefinidos para agentes de codificación de IA que automatizan los flujos de trabajo comunes de Agent Observability. El conjunto de habilidades `agent-observability` está disponible en el repositorio [Datadog agent-skills][8]. Proporciona seis habilidades para clasificar sesiones, diagnosticar fallas, analizar experimentos, generar código de experimento con el SDK `ddtrace.llmobs` y arrancar evaluadores con sus datos de producción en vivo. + +### Instalar {#install} + +Instale las habilidades `agent-observability` con el siguiente comando: + +```shell +npx skills add datadog-labs/agent-skills/agent-observability --full-depth -y +``` + +Las habilidades requieren que el `llmobs` conjunto de herramientas MCP esté conectado. Si aún no lo ha conectado, ejecute: + +{{< site-region region="us,us3,us5,eu,ap1,ap2,uk1" >}} +
claude mcp add --scope user --transport http "datadog-llmo-mcp" \
+  '{{< region-param key="mcp_server_endpoint" >}}?toolsets=llmobs,core'
+{{< /site-region >}} + +{{< site-region region="gov,gov2" >}} +
Este producto no es compatible con el sitio seleccionado ({{< region-param key="dd_site_name" >}}).
+{{< /site-region >}} + +Reinicie Claude Code después de ejecutar ambos comandos para que aparezcan Agent skills. + +### Habilidades disponibles {#available-skills} + +| Skill | Invoke with | What it does | +|-------|-------------|-------------| +| Clasificación de sesión | `/agent-observability-session-classify` | Clasifica si la intención del usuario fue satisfecha en una sesión, traza o lote | +| RCA de traza | `/agent-observability-trace-rca` | Análisis de causa raíz en trazas de producción fallidas | +| Analizador de experimentos | `/agent-observability-experiment-analyzer` | Analice y compare resultados de experimentos de LLM | +| Generación de código Python para experimentos | `/agent-observability-experiment-py-bootstrap` | Genere código de experimento en Python usando el `ddtrace.llmobs` SDK. Introspecciona su aplicación para conectar un `task_fn` real, autodescubre credenciales `.env` y acepta un `--purpose` de forma libre que dirige la selección del evaluador | +| Bootstrap de evaluación | `/agent-observability-eval-bootstrap` | Genere código de evaluador, publique evaluadores de LLM-judge en línea o muestree trazas en un conjunto de datos para su uso en un experimento | +| Canalización de evaluación | `/agent-observability-eval-pipeline` | Canalización guiada de seis fases desde trazas de producción hasta evaluadores, conjuntos de datos, experimentos y análisis. Detenga antes de tiempo con `--stop-after`, reanude a mitad del flujo con `--start-at` | + +#### Clasificación de sesión {#session-classification} + +`/agent-observability-session-classify` clasifica si la intención del usuario fue satisfecha en una interacción determinada. Proviene de hasta tres fuentes de señales: rastreos de Agent Observability, datos de comportamiento RUM y eventos de Audit Trail. La habilidad devuelve un veredicto `yes / partial / no` con evidencia de respaldo. La confianza mejora con cada fuente de señal adicional. + +``` +/agent-observability-session-classify session_id= +/agent-observability-session-classify trace_id= +/agent-observability-session-classify ml_app=my-chatbot --timeframe now-7d +``` + +#### Análisis de causa raíz de traza{#trace-root-cause-analysis} + +`/agent-observability-trace-rca` diagnostica por qué una aplicación de LLM está produciendo resultados deficientes. Selecciona un modo de análisis basado en la señal más fuerte disponible (veredictos de evaluación de LLM-judge, errores de tiempo de ejecución o anomalías estructurales) y compila un informe de RCA estructurado. El informe incluye una taxonomía de fallas y propuestas de solución `BEFORE` / `AFTER` concretas fundamentadas en la evidencia de traza. + +Cuando Claude Code tiene acceso a su base de código, la habilidad puede buscar los archivos fuente relevantes y proponer diferencias en línea. + +``` +/agent-observability-trace-rca ml_app=my-chatbot +/agent-observability-trace-rca ml_app=my-chatbot eval_name=faithfulness --timeframe now-24h +``` + +#### Bootstrap de evaluador{#evaluator-bootstrap} + +`/agent-observability-eval-bootstrap` analiza las trazas de producción y propone un conjunto de evaluadores dirigidos a los modos de falla observados. Genera uno de cuatro artefactos: clases de Python `BaseEvaluator` / `LLMJudge` para experimentos fuera de línea, una especificación JSON independiente del marco, evaluadores de LLM-judge en línea publicados directamente en Datadog, o — a través de `--emit-dataset ` — un `DatasetRecordRaw[]` JSON muestreado de trazas de producción y adaptado para `LLMObs.create_dataset(records=...)`. El modo dataset-emit omite el flujo de trabajo del evaluador por completo; produce un conjunto de datos adecuado para su uso como entrada de un experimento. + +``` +/agent-observability-eval-bootstrap ml_app=my-chatbot +/agent-observability-eval-bootstrap ml_app=my-chatbot --publish +/agent-observability-eval-bootstrap ml_app=my-chatbot --data-only +/agent-observability-eval-bootstrap ml_app=my-chatbot --emit-dataset ./datasets/my_chatbot_seed.json +``` + +#### Analizador de experimentos {#experiment-analyzer} + +`/agent-observability-experiment-analyzer` recupera los resultados del experimento y muestra qué cambió entre un candidato y una línea base: qué métricas mejoraron, cuáles retrocedieron y dónde el candidato tuvo un rendimiento inferior. + +``` +/agent-observability-experiment-analyzer experiment_id= +/agent-observability-experiment-analyzer experiment_id= baseline_id= +``` + +#### Genere código de experimento con el SDK de Python {#generate-experiment-code-with-the-python-sdk} + +`/agent-observability-experiment-py-bootstrap` emite un script `.py` autónomo o un cuaderno `.ipynb` de Jupyter que utiliza el `ddtrace.llmobs` SDK y coincide con el estilo del notebook de referencia canónico. + +El conjunto de datos puede ser un JSON `DatasetRecordRaw[]` local (integrado en el archivo), un CSV (cargado en tiempo de ejecución a través de `LLMObs.create_dataset_from_csv`), un conjunto de datos de Datadog existente por nombre (`LLMObs.pull_dataset`), o — de forma predeterminada — una pequeña muestra en línea de 3 registros. Cada experimento generado está etiquetado con `generated_by=claude-code` y el `--purpose` resuelto tanto en `config` como en `tags`. + +``` +/agent-observability-experiment-py-bootstrap --purpose "validate output accuracy" +/agent-observability-experiment-py-bootstrap --purpose "test tool selection" --dataset ./data/qa.json +/agent-observability-experiment-py-bootstrap --dataset-name --project-name +/agent-observability-experiment-py-bootstrap --task-source mymodule.handlers:respond +``` + +#### Canalización de evaluación de extremo a extremo {#end-to-end-eval-pipeline} + +`/agent-observability-eval-pipeline` recorre desde las trazas de producción hasta los evaluadores, conjuntos de datos, experimentos y análisis en seis fases narradas, con un punto de control para el usuario entre cada una: + +1. **Clasificar trazas de ml_app** — muestree y clasifique las trazas recientes de su `ml_app` +2. **Análisis de causa raíz** — diagnostique por qué fallan las trazas que presentan errores +3. **Inicializar evaluadores** — proponga un conjunto de evaluadores dirigido a los modos de falla observados +4. **Crear + publicar conjunto de datos** — extraiga pares de entrada / expected_output en un `DatasetRecordRaw[]` JSON y publíquelos en Datadog bajo su proyecto (creado de forma diferida) +5. **Generar + ejecutar experimento** — emita un `.py` o `.ipynb` ejecutable que extraiga el conjunto de datos y conecte la función de tarea de su aplicación, luego ejecútelo de extremo a extremo y capture `experiment.url`. Un punto de revisión en fase (`run` / `edit` / `stop`) se sitúa entre la generación de código y la ejecución para que pueda inspeccionar el archivo generado antes de su ejecución +6. **Analizar experimento** — produzca un informe de análisis con desgloses de métricas y recomendaciones + +Cada fase tiene un nombre corto canónico: el mismo valor aceptado por `--start-at` y `--stop-after`. La tabla a continuación enumera, por fase, qué herramientas MCP puede invocar la canalización y una descripción de una línea de la lógica: + +| # | Título de la fase | Nombre de la etapa | Herramientas MCP llamadas | Resumen | +|---|-------------|----------------------------------------------------------------------------------------|------------------|---------| +| 1 | Clasificar trazas de ml_app | `classify` | `search_llmobs_spans` | Muestrea tramos raíz recientes para la `ml_app`, clasifica cada uno como éxito / parcial / falla, muestra patrones comunes. | +| 2 | Análisis de causa raíz | `rca` | `search_llmobs_spans` | Extrae trazas completas para los tramos fallidos de la Fase 1 y recorre el árbol de trazas para atribuir cada falla a un tramo raíz y un modo de falla. | +| 3 | Inicializar evaluadores | `eval-bootstrap` | Ninguno (razonamiento local sobre el informe de la Fase 2); llamada opcional a la Datadog API para publicar evaluadores de jueces LLM en línea cuando `--publish` está configurado | Emite un conjunto de evaluadores de Python (`sdk_code`), una especificación JSON agnóstica al marco (`data_only`), o publica evaluadores en línea (`publish`). | +| 4 | Crear y publicar conjunto de datos | `dataset` | `search_llmobs_spans` para muestreo; `LLMObs.create_dataset()` a través del SDK de ddtrace (no MCP) para publicar | Muestrea tramos raíz, extrae pares de entrada / expected_output, limpia PII, escribe un JSON local, luego publica en Datadog. | +| 5 | Generar y ejecutar experimento | `experiment` | `list_llmobs_evals` (beacon de inicio de un solo intento — conectividad + telemetría); el tiempo de ejecución utiliza el SDK de ddtrace | Introspecciona su aplicación en busca de sitios de llamadas a LLM, emite un `.py` autónomo o `.ipynb` conecta `task_fn` a un punto de entrada real, luego lo ejecuta. | +| 6 | Analizar experimento | `analyze` | `get_llmobs_experiment_summary`, `get_llmobs_experiment_metric_values`, `list_llmobs_experiment_events`, `get_llmobs_experiment_event`, `get_llmobs_experiment_dimension_values` | Extrae métricas generales, puntuaciones por registro, dimensiones de segmento y eventos de desglose; sintetiza un informe de análisis estructurado. | + +Deténgase de forma ordenada `stop` en cualquier punto de control y reanude más tarde con `--start-at ` — sin necesidad de volver a ejecutar. Pase `--stop-after eval-bootstrap` para preservar el comportamiento clásico de solo evaluación de tres fases. + +``` +/agent-observability-eval-pipeline my-chatbot --project-name my-chatbot +/agent-observability-eval-pipeline my-chatbot --stop-after eval-bootstrap # classic 3-phase +/agent-observability-eval-pipeline my-chatbot --start-at experiment # resume mid-flow +/agent-observability-eval-pipeline my-chatbot --start-at analyze --experiment-id +``` + +Para obtener una guía completa sobre estas habilidades y un flujo de trabajo de extremo a extremo recomendado, consulte [Analizar LLM Applications with Claude Code Skills][9]. + +## Casos de uso {#use-cases} + +Las herramientas MCP de Agent Observability permiten flujos de trabajo asistidos por IA para: + +- **Depuración de la ejecución del agente**: Busque trazas por aplicación de ML, estado de error o etiquetas personalizadas, luego examine las jerarquías y el contenido de los tramos para identificar fallas. +- **Analizando la estructura de trazas**: Visualice el árbol completo de tramos de una traza para comprender cómo interactúan los agentes, LLMs, herramientas y recuperaciones. +- **Investigando bucles de agentes**: Revise el bucle de ejecución paso a paso de un agente para comprender la toma de decisiones y los patrones de invocación de herramientas. +- **Evaluando experimentos**: Obtenga estadísticas resumidas para las métricas de experimentos, compare resultados entre segmentos de dimensiones e inspeccione eventos individuales. +- **Creando experimentos**: Registre un nuevo objeto de experimento con `create_llmobs_experiment` para registrar metadatos del experimento (proyecto, conjunto de datos, descripción, configuración) sin ejecutar la inferencia del modelo. Adjunte métricas de evaluación posteriormente con `submit_llmobs_experiment_events`. +- **Descubriendo patrones de experimentos**: Filtre y ordene eventos de experimentos por rendimiento de métricas para encontrar los casos con mejor y peor rendimiento. +- **Gestionando evaluadores**: Enumere, inspeccione, cree, actualice y elimine configuraciones de evaluadores en una aplicación de ML o en toda la organización. +- **Explorando patrones**: Enumere configuraciones de patrones, verifique el estado de ejecución y explore la jerarquía de temas descubierta para comprender qué están preguntando los usuarios y cómo se distribuye el tráfico. +- **Gestionando conjuntos de datos**: Busque proyectos y conjuntos de datos, explore e inspeccione registros de conjuntos de datos y agregue nuevos registros a un conjunto de datos para su uso en experimentos. + +## Herramientas disponibles {#available-tools} + +El conjunto de herramientas `llmobs` incluye las siguientes herramientas: + +### Herramientas de traza y tramo {#trace-and-span-tools} + +`search_llmobs_spans` +: Busque tramos que coincidan con filtros o una consulta sin procesar. + +`get_llmobs_trace` +: Obtenga la estructura completa de una traza como un árbol de jerarquía de tramos, incluyendo conteos de tramos por tipo, indicadores de error y duración total. + +`get_llmobs_span_details` +: Obtenga metadatos detallados de uno o más tramos, incluyendo tiempos, información de errores, detalles de LLM (modelo, conteo de tokens), métricas y evaluaciones. + +`get_llmobs_span_content` +: Recupere el contenido real de un campo de tramo (entrada, salida, mensajes, documentos o metadatos) con extracción JSONPath opcional. + +`find_llmobs_error_spans` +: Encuentre todos los tramos de error en una traza con contexto de propagación, agrupados por tipo de tramo con mensajes de error y trazas de pila. + +`expand_llmobs_spans` +: Cargue los hijos de tramos específicos para la exploración progresiva del árbol cuando `get_llmobs_trace` devuelva nodos contraídos. + +`get_llmobs_agent_loop` +: Obtenga una vista cronológica del bucle de ejecución de un agente, mostrando cada paso (llamadas a LLM, invocaciones de herramientas, decisiones) en orden. + +### Herramientas de experimento {#experiment-tools} + +`create_llmobs_experiment` +: Cree un nuevo objeto de experimento de Agent Observability en un proyecto. Registra el experimento (para que los eventos y métricas puedan reportarse en relación con él) sin ejecutar ninguna inferencia de modelo. Requiere `project_id` y `experiment_name`. Devuelve el `experiment_id` creado y su nombre resuelto. Use `submit_llmobs_experiment_events` para adjuntar métricas de evaluación, o `update_llmobs_experiment` para cambiar sus propiedades. + +`get_llmobs_experiment_summary` +: Obtenga un resumen de experimento de alto nivel con estadísticas precalculadas para todas las métricas de evaluación. Comience aquí antes de usar otras herramientas de experimento. + +`list_llmobs_experiment_events` +: Enumere los eventos de experimento con filtrado por dimensión o métrica y ordenamiento por valor de métrica. + +`get_llmobs_experiment_event` +: Obtenga detalles completos de un solo evento de experimento, incluyendo entrada, salida, expected_output, todas las métricas y dimensiones. + +`get_llmobs_experiment_metric_values` +: Obtenga análisis estadístico para una métrica de evaluación específica, opcionalmente segmentado por una dimensión para comparación. + +`get_llmobs_experiment_dimension_values` +: Obtenga valores únicos para una dimensión con conteos, útil para descubrir valores válidos de filtro y segmento. + +### Herramientas de evaluación {#evaluator-tools} + +`list_llmobs_evals` +: Enumere todos los evaluadores de LLM-judge configurados en todas las aplicaciones de ML. Devuelve el nombre, ml_app y estado habilitado de cada evaluador. + +`list_llmobs_evals_by_ml_app` +: Enumere todos los evaluadores de LLM-judge configurados para una aplicación de ML específica. + +`get_llmobs_evaluator` +: Recupere una configuración de evaluador de LLM-judge por nombre, incluyendo su objetivo (ml_app, muestreo, filtro), proveedor de LLM y plantilla de prompt del evaluador. + +`create_or_update_llmobs_evaluator` +: Cree o actualice una configuración de evaluador de LLM-judge. Dirigido a una aplicación de ML específica y opcionalmente a un filtro o porcentaje de muestreo; el modelo del evaluador y la plantilla de prompt definen cómo califica cada tramo. + +`delete_llmobs_evaluator` +: Elimine una configuración de evaluador de LLM-judge por nombre. + +### Herramientas de proyecto y conjunto de datos {#project-and-dataset-tools} + +`list_llmobs_projects` +: Listar todos los proyectos de experimentos de Agent Observability para la organización, ordenados por fecha de creación (los más recientes primero). Devuelve el `id`, `name` y las marcas de tiempo de cada proyecto, además de los campos de paginación (`next_cursor`, `truncated`). Utilice esto para descubrir nombres e identificadores de proyectos cuando aún no los conozca. + +`get_llmobs_project` +: Busque un proyecto de experimentos de Agent Observability por ID o nombre. Use esto para resolver un `project_id` UUID antes de llamar a las herramientas de conjuntos de datos. + +`list_llmobs_datasets` +: Listar los conjuntos de datos dentro de un proyecto, con filtro opcional de ID o nombre. Devuelve los metadatos del conjunto de datos y los campos de paginación. Use esto antes de `get_llmobs_dataset_records` o `add_llmobs_dataset_records`; esas herramientas requieren un UUID de conjunto de datos. + +`get_llmobs_dataset_records` +: Lea registros de conjuntos de datos con vistas previas estructuradas y un resumen del esquema. Da forma a campos JSON arbitrarios (`input`, `expected_output`, `metadata`) en vistas previas legibles. Use `compute_schema=true` para obtener un esquema de la estructura de registros con reconocimiento de tipos antes de crear nuevos registros. + +`get_llmobs_full_dataset_records` +: Obtenga hasta 3 registros específicos con contenido completo y sin recortar. Use esto para inspeccionar registros individuales en detalle después de encontrar los ID de registro con `get_llmobs_dataset_records`. + +`add_llmobs_dataset_records` +: Cree registros en un conjunto de datos utilizando un flujo de dos pasos de vista previa y confirmación. Llame con `confirmed=false` para obtener una vista previa de la escritura planificada, luego `confirmed=true` para confirmar después de la aprobación del usuario. + +### Herramientas de patrones {#patterns-tools} + +`list_llmobs_pattern_configs` +: Listar todas las configuraciones de Patterns para la organización. Devuelve el `id`, `name`, `evp_query`, la configuración de muestreo y las marcas de tiempo de cada configuración. Comience aquí para encontrar un `config_id`. + +`get_llmobs_pattern_config` +: Obtenga la configuración de Patterns modificada más recientemente para la organización. + +`get_llmobs_pattern_run_status` +: Obtenga el estado y el progreso por actividad de la ejecución de Patterns más reciente para una configuración. Use esto para verificar si el clúster se está ejecutando, se completó o falló antes de leer los temas. + +`list_llmobs_pattern_runs` +: Listar todas las ejecuciones de Patterns completadas para una configuración, de la más nueva a la más antigua. Devuelve el `id`, `status`, las marcas de tiempo y el `config_snapshot` utilizado de cada ejecución. + +`get_llmobs_patterns` +: Obtenga la jerarquía de temas descubierta por una ejecución de Patterns. Los temas están organizados en niveles, cada uno con un `name`, `description` y `point_count`. Omita `run_id` para leer la ejecución completada más reciente. + +`get_llmobs_patterns_with_points` +: Obtenga la jerarquía de temas para una ejecución con IDs de tramo integrados en cada tema hoja. Establezca `include_metrics=true` para incluir también la duración, el costo, el conteo de tokens y las evaluaciones por tramo. + +`get_llmobs_pattern_points` +: Obtenga una página paginada por cursor de puntos de clúster (tramos individuales) asignados a un solo tema. Cada punto incluye el `span_id`, `session_id` y una vista previa de la entrada del tramo. Pase `next_page_token` de vuelta como `page_token` para continuar con la paginación. + +### Herramientas de cola de anotación {#annotation-queue-tools} + +`list_llmobs_annotation_queues` +: Listar todas las [colas de anotación][10] para la organización. + +`create_llmobs_annotation_queue` +: Crear una cola de anotación para la revisión humana de trazas, definiendo opcionalmente su esquema de etiquetas en el momento de la creación. + +`update_llmobs_annotation_queue` +: Actualizar el nombre, la descripción o el esquema de etiquetas de una cola de anotación. + +`delete_llmobs_annotation_queue` +: Eliminar una cola de anotación. + +`get_llmobs_annotation_label_schema` +: Obtener el esquema de etiquetas para una cola de anotación, el cual define las etiquetas que los anotadores aplican durante la revisión. + +`update_llmobs_annotation_label_schema` +: Cree o reemplace el esquema de etiquetas para una cola de anotación. + +`add_llmobs_annotation_queue_interactions` +: Agregue una o más trazas a una cola de anotación para su revisión. + +`delete_llmobs_annotation_queue_interactions` +: Elimine trazas de una cola de anotación. + +`get_llmobs_annotated_interactions` +: Obtenga las interacciones anotadas en una cola de anotación junto con las etiquetas que los anotadores les aplicaron. + +`get_llmobs_annotations_by_content_ids` +: Obtenga las anotaciones aplicadas a trazas o sesiones específicos mediante sus ID de contenido. + +`upsert_llmobs_annotations` +: Cree o actualice las anotaciones aplicadas a las interacciones en una cola. + +`delete_llmobs_annotations` +: Elimine las anotaciones aplicadas a las interacciones en una cola. + +## Flujos de trabajo recomendados {#recommended-workflows} + +### Análisis de trazas {#trace-analysis} + +1. **Buscar**: Use `search_llmobs_spans` para encontrar trazas por aplicación de ML, estado, tipo de tramo o etiquetas personalizadas. +2. **Visualizar**: Use `get_llmobs_trace` para ver el árbol de jerarquía de tramos completo. +3. **Inspeccionar**: Use `get_llmobs_span_details` para obtener metadatos, tiempos y evaluaciones para tramos específicos. +4. **Leer contenido**: Use `get_llmobs_span_content` para recuperar la E/S, los mensajes o los documentos reales. +5. **Depurar errores**: Use `find_llmobs_error_spans` para localizar todos los errores en una traza con contexto de propagación. +6. **Expandir**: Use `expand_llmobs_spans` para cargar los hijos de los tramos contraídos para una exploración más profunda. +7. **Revisión de Agent**: Use `get_llmobs_agent_loop` para ver el flujo de ejecución paso a paso de un tramo de Agent. + +### Análisis de experimentos {#experiment-analysis} + +1. **Resumir**: Use `get_llmobs_experiment_summary` para obtener estadísticas generales y descubrir las métricas y dimensiones disponibles. +2. **Explorar eventos**: Use `list_llmobs_experiment_events` para encontrar eventos de interés, filtrando por dimensión u ordenando por métrica. +3. **Inspeccionar eventos**: Use `get_llmobs_experiment_event` para ver los detalles completos de un evento específico. +4. **Analizar métricas**: Use `get_llmobs_experiment_metric_values` para obtener distribuciones de percentiles, tasas de verdadero/falso o comparar entre segmentos de dimensión. +5. **Descubrir dimensiones**: Use `get_llmobs_experiment_dimension_values` para encontrar valores válidos de filtro y segmento. + +### Gestión de conjuntos de datos {#dataset-management} + +1. **Encuentre su proyecto**: Use `list_llmobs_projects` para explorar proyectos; cada resultado incluye el `id` UUID que necesita para llamadas posteriores. Si ya conoce el nombre del proyecto pero no su UUID, use `get_llmobs_project` para resolverlo directamente. +2. **Encuentre su conjunto de datos**: Use `list_llmobs_datasets` con el `project_id` para listar conjuntos de datos y obtener sus UUIDs. +3. **Entienda los datos**: Use `get_llmobs_dataset_records` con `compute_schema=true` para explorar registros y obtener un esquema de tipos de los campos antes de leer o escribir. +4. **Leer registros específicos**: Use `get_llmobs_full_dataset_records` para recuperar el contenido completo de hasta 3 registros por ID. +5. **Agregar registros**: Use `add_llmobs_dataset_records` con `confirmed=false` para obtener una vista previa de una escritura, luego `confirmed=true` después de la aprobación del usuario. + +### Análisis de patrones {#patterns-analysis} + +1. **Listar configuraciones**: Use `list_llmobs_pattern_configs` para encontrar las configuraciones de Patrones disponibles y sus valores de `config_id`. +2. **Verificar el estado de ejecución**: Use `get_llmobs_pattern_run_status` para verificar que la ejecución más reciente esté completa. +3. **Leer temas**: Use `get_llmobs_patterns` para obtener la jerarquía completa de temas con nombres, descripciones y puntuaciones de coherencia. +4. **Inspeccionar tramos**: Use `get_llmobs_patterns_with_points` para obtener temas con IDs de tramo integrados, o `get_llmobs_pattern_points` para navegar por los tramos de un tema específico. +5. **Analizar el contenido del tramo**: Use `get_llmobs_span_details` o `get_llmobs_span_content` con los valores de `span_id` del paso anterior para inspeccionar las entradas, salidas y metadatos reales de tramos individuales dentro de un tema. +6. **Explorar ejecuciones pasadas**: Use `list_llmobs_pattern_runs` para ver ejecuciones históricas y pase un `run_id` específico para comparar las distribuciones de temas a lo largo del tiempo. + +## Ejemplos de prompts {#example-prompts} + +Después de conectarse, pruebe prompts como: + +- Revise las trazas de errores de mi aplicación `customer-support-bot` durante la última semana. Resuma los patrones de falla más comunes, con qué frecuencia ocurren y recomiende cuáles corregir primero. +- Encuentre trazas donde las respuestas de mi Agent fueron marcadas por las evaluaciones como de baja calidad. Examine las entradas y salidas, luego sugiera cambios específicos en mi prompt del sistema para mejorar la calidad de la respuesta. +- Examine las trazas recientes del Agent para mi aplicación y encuentre casos donde el Agent entró en bucle más de lo necesario. Analice la toma de decisiones en cada paso y sugiera cómo mejorar las descripciones de mis herramientas para reducir las llamadas innecesarias a herramientas. +- Un usuario informó una mala respuesta. Aquí está el ID de traza: `trace-123`. Explíqueme exactamente qué sucedió: qué preguntó el usuario, qué hizo el Agent en cada paso y dónde salieron mal las cosas. Sugiera una corrección de código. +- Analice el experimento `exp-456` y genere una tabla en formato markdown de las dimensiones con peor rendimiento desglosadas por puntuaciones de evaluación. Incluya cualquier otra columna relevante que me ayude a entender dónde y por qué está disminuyendo el rendimiento. +- Compare el experimento `exp-123` (línea base) con el experimento `exp-456`. Resuma qué mejoró, qué empeoró y en qué medida. Deme una recomendación sobre si vale la pena implementar los cambios. +- Resuma el experimento `exp-456` e identifique los 5 eventos con la puntuación más baja. Para cada uno, muestre la entrada, la salida y qué evaluaciones fallaron. +- Cree un nuevo experimento llamado \"prompt-v2-test\" en mi proyecto `my-chatbot-project` y devuelva su ID de experimento para que pueda adjuntarle métricas de evaluación. +- Listar los conjuntos de datos en mi proyecto `my-project` y muéstreme una muestra de registros del conjunto de datos llamado `qa-golden-set`, incluido su esquema. +- Tengo un archivo CSV con nuevos casos de prueba. Agréguelos al conjunto de datos `qa-golden-set` en `my-project` como una nueva versión. Muéstreme una vista previa primero. + +## Combine con otras herramientas de Datadog {#combine-with-other-datadog-tools} + +El conjunto de herramientas `core` incluido en la URL de configuración le da a su Agent de IA acceso a herramientas adicionales de Datadog que se combinan naturalmente con el análisis de Agent Observability. + +### Exporte el análisis a Datadog Notebooks {#export-analysis-to-datadog-notebooks} + +El conjunto de herramientas `core` incluye `create_datadog_notebook` y `edit_datadog_notebook`, que permiten a su Agent de IA crear [Datadog Notebooks][3] directamente a partir de los resultados del análisis. Puede exportar los hallazgos de los chats del Agent a un notebook colaborativo y compartible que reside en Datadog junto con sus trazas y experimentos. + +Pruebe con sugerencias como: + +- Analice el experimento `exp-456`, identifique las dimensiones con peor rendimiento y exporte un informe resumido a un Datadog Notebook con un desglose por puntuaciones de evaluación. +- Revise las trazas de error de mi `customer-support-bot` durante la última semana y cree un Datadog Notebook con los hallazgos, incluyendo patrones de falla comunes y soluciones recomendadas. + +Para visualizaciones personalizadas que van más allá de los widgets estándar de Datadog, como gráficos de comparación o diagramas de cuadrantes, los Notebooks también renderizan [diagramas Mermaid][4] de forma nativa. Pruebe con sugerencias como: + +- Analice el experimento `exp-456`, compare las puntuaciones de `accuracy` en cada versión del prompt y exporte los resultados a un Datadog Notebook que incluya un gráfico de barras Mermaid del promedio de puntuación para cada versión. +- Analice el experimento `exp-456` y exporte un Datadog Notebook que grafique cada versión del prompt en un diagrama de cuadrantes Mermaid con `relevance` en un eje y `accuracy` en el otro. Identifique qué versiones tienen un rendimiento inferior en ambas dimensiones. + +## Lecturas adicionales {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /es/mcp_server/setup/ +[2]: /es/llm_observability/ +[3]: /es/notebooks/ +[4]: /es/notebooks/guide/build_diagrams_with_mermaidjs/ +[5]: /es/getting_started/site/ +[6]: /es/account_management/api-app-keys/ +[7]: /es/account_management/org_settings/service_accounts/ +[8]: https://github.com/datadog-labs/agent-skills +[9]: /es/llm_observability/build_with_ai/claude_code_skills +[10]: /es/llm_observability/investigate/annotation_queues \ No newline at end of file diff --git a/hugo/content/es/logs/explorer/search.md b/hugo/content/es/logs/explorer/search.md index d74621360a0..90a98f7c35b 100644 --- a/hugo/content/es/logs/explorer/search.md +++ b/hugo/content/es/logs/explorer/search.md @@ -1,118 +1,99 @@ --- aliases: - /es/logs/search -description: Filtra logs para reducir, ampliar o cambiar tu enfoque en el subconjunto - de logs de interés actual. +description: Filtre los registros para limitar, ampliar o cambiar su enfoque en el + subconjunto de registros de interés actual. further_reading: - link: logs/explorer/analytics tag: Documentación - text: Aprende a agrupar logs -- link: logs/explorador/visualizar + text: Aprenda a agrupar registros +- link: logs/explorer/visualize tag: Documentación - text: Crear visualizaciones a partir de logs + text: Cree visualizaciones a partir de registros - link: /logs/explorer/export tag: Documentación - text: Exportar vistas desde el Log Explorer -title: Buscar logs + text: Exporte visualizaciones desde el Log Explorer +title: Buscar registros --- +## Descripción general {#overview} -## Información general +El [Log Explorer][1] le permite buscar y ver registros individuales como una lista. Sin embargo, los conocimientos más valiosos a menudo provienen de la agregación de registros a escala. Al utilizar la función de búsqueda, puede filtrar registros y visualizarlos como gráficos de series temporales, listas principales, mapas de árbol, gráficos circulares o tablas para comprender mejor las tendencias, los patrones y los valores atípicos en sus datos de registros. -El [Log Explorer][5] te permite buscar y ver logs individualmente como una lista. Sin embargo, las perspectivas más valiosas a menudo provienen de la agregación de logs a escala. Utilizando la función de búsqueda, puedes filtrar los logs y visualizarlos como gráficos de series temporales, listas principales, mapas de árbol, gráficos circulares o tablas para comprender mejor las tendencias, los patrones y los valores atípicos de tus datos de log. +## Consultas en lenguaje natural {#natural-language-queries} -## Consultas en lenguaje natural - -{{% site-region region="gov" %}} +{{% site-region region="gov,gov2" %}}
-Las consultas en lenguaje natural no están disponibles en el sitio Datadog ({{< region-param key="dd_site_name" >}}). +Las consultas en lenguaje natural no están disponibles en el sitio de Datadog ({{< region-param key="dd_site_name" >}}).
{{% /site-region %}} +Utilice Natural Language Queries (NLQ) para describir lo que busca en inglés sencillo. Datadog traduce automáticamente su solicitud a una consulta de registro estructurada, lo que facilita la exploración de registros sin necesidad de escribir una sintaxis compleja. Para acceder a esta función, haga clic en {{< ui >}}Ask{{< /ui >}} en el campo de búsqueda. -
Las consultas en lenguaje natural (NLQ) para logs se crean con Llama.
- -Utiliza las consultas en lenguaje natural (NLQ) para describir lo que buscas en inglés sencillo. Datadog traduce automáticamente tu solicitud en una consulta estructurada de logs, lo que facilita la exploración de logs sin necesidad de escribir una sintaxis compleja. Para acceder a esta función, haz clic en **Ask** (Preguntar) en el campo de búsqueda. - -{{< img src="/logs/explorer/search/log_explorer_nlq.mp4" alt="Consulta en lenguaje natural en el Log Explorer que muestra cómo buscar logs usando frases en inglés sencillo" video=true >}} - -El sistema traduce las entradas en lenguaje natural en consultas a Datadog y entiende contextos como servicios, atributos, etiquetas y rangos temporales. También detecta automáticamente los campos relevantes y permite a los usuarios crear visualizaciones con descripciones sencillas, por ejemplo, "Los 20 principales servicios por errores" o "Mostrar errores del servicio X en las últimas 24 horas". - -Para desactivar NLQ, debes tener [permisos `org_management`][8]. Ve a [Organization Settings > Preferences][7] (Configuración de la organización > Preferencias) y desactiva la función de consultas en lenguaje natural. - -## Consulta de búsqueda - -Una búsqueda en el Log Explorer consiste en un intervalo de tiempo y una consulta de búsqueda, mezclando `key:value` y una [búsqueda de texto completo][6]. +{{< img src="/logs/explorer/search/log_explorer_nlq.mp4" alt="Consulta en lenguaje natural en el Log Explorer que muestra cómo buscar registros mediante frases en inglés sencillo." video=true >}} -Para filtrar en logs producidos por un servicio de tienda web, con un estado de error, durante los últimos quince minutos, crea una consulta personalizada como `service:payment status:error rejected` y establece el intervalo de tiempo en `Past 15 minutes`: +El sistema traduce la entrada en lenguaje natural a consultas de Datadog y comprende el contexto, como servicios, atributos, etiquetas y rangos de tiempo. También detecta campos relevantes automáticamente y permite a los usuarios crear visualizaciones mediante descripciones sencillas; por ejemplo, "Top 20 servicios por errores" o "Mostrar errores del servicio X en las últimas 24 horas". -{{< img src="logs/explorer/search_filter.png" alt="Crear una consulta de búsqueda en el Log Explorer que filtre los logs de error de pagos rechazados de un servicio de tienda web" style="width:100%;" >}} +Para deshabilitar NLQ, debe tener [`org_management` permisos][2]. Navegue a [{{< ui >}}Organization Settings{{< /ui >}} > {{< ui >}}Preferences{{< /ui >}}][3] y desactive la función de Natural Language Queries. -Los [logs indexados][1] admiten tanto [consultas de texto completo][6] como búsquedas de `key:value`. +## Consulta de búsqueda {#search-query} -**Nota**: Las consultas a `key:value` **no** requieren que se [declare una faceta][2] de antemano. +Una búsqueda en Log Explorer consiste en un intervalo de tiempo y una consulta de búsqueda, combinando `key:value` y [búsqueda de texto completo][4]. Puede elegir una ventana de tiempo para su búsqueda utilizando el selector de intervalo de tiempo en la parte superior derecha de Log Explorer. Para obtener detalles sobre cómo configurar un intervalo de tiempo personalizado, consulte la [documentación de intervalo de tiempo personalizado][5]. -## Autocompletar +Para filtrar los registros producidos por un servicio de tienda web, con un estado de error, durante los últimos quince minutos, cree una consulta personalizada como `service:payment status:error rejected` y establezca el intervalo de tiempo en `Past 15 minutes`: -Utiliza la función de autocompletar de la barra de búsqueda para completar tu consulta: -- Claves y valores existentes en tus logs -- Tus búsquedas recientes (no se muestran las búsquedas recientes de otros usuarios) -- Vistas guardadas +{{< img src="logs/explorer/search_filter.png" alt="Cree una consulta de búsqueda en Log Explorer que filtre los registros de error de pagos rechazados para un servicio de tienda web." style="width:100%;" >}} -{{< img src="logs/explorer/search/log_search_bar_autocomplete.png" alt="La barra de búsqueda de logs muestra service como consulta y el remitente, el balance, el servidor de avisos y la VPC como opciones a autocompletar" style="width:80%;">}} +[Indexed Logs][6] admiten tanto [búsqueda de texto completo][4] como `key:value` consultas de búsqueda. -### Facetas y valores de autocompletar +**Nota**: las consultas `key:value` **no** requieren que [declare una faceta][7] de antemano. -La barra de búsqueda sugiere automáticamente facetas en función de lo que introduzcas en la barra de búsqueda. Estas facetas se muestran en el mismo orden en que aparecen en el [panel de facetas][5]. Si una faceta tiene un nombre definido, se muestra a la derecha del menú desplegable. +Para obtener una referencia completa de la sintaxis de consulta, consulte la [documentación de Sintaxis de búsqueda][8]. -{{< img src="logs/explorer/search/log_facet_autocomplete.png" alt="La barra de búsqueda de logs que muestra `network` como consulta y las facetas @network.bytes_written, @network.client.ip y @network.interface como opciones para autocompletar" style="width:80%;">}} +## Funciones de la barra de búsqueda {#search-bar-features} -Después de seleccionar una faceta e introducir el carácter `:`, la barra de búsqueda sugiere valores. Estos se muestran en orden descendente según el número de logs que contienen ese par `facet:value` en los últimos 15 minutos. El número estimado de logs que contienen ese valor se muestra a la derecha del desplegable. Por ejemplo, el servicio `balance-checker` se sitúa en primer lugar en la lista de valores autosugeridos para la faceta `service`, indicada por `2.66M`, que representa el recuento de logs más elevado: +La barra de búsqueda de Log Explorer incluye varias funciones para ayudarle a escribir consultas de manera más eficiente y precisa. -{{< img src="logs/explorer/search/log_value_autocomplete.png" alt="La barra de búsqueda de logs que muestra `service:` como consulta y los valores balance, servidor de avisos, detector de fraude y ejecutor de intercambios como opciones para autocompletar" style="width:80%;">}} +### Resaltado de sintaxis y validación de errores {#syntax-highlighting-and-error-validation} -### Autocompletar búsquedas recientes +El resaltado de sintaxis diferencia claramente los tipos de entrada: claves, valores, texto libre y caracteres de control. Por ejemplo, `service` y `status` son claves, `auth-dotnet` y `error` son valores, `500` y `check-token` son texto libre, y los paréntesis son caracteres de control. Los atributos de estado están codificados por colores según el estado (rojo para `error`, azul para `info`). -Se conservan tus 100 búsquedas más recientes en el Log Explorer. Las búsquedas recientes de otros usuarios no se conservan ni se muestran. La barra de búsqueda autosugiere las cuatro búsquedas más recientes que coinciden con lo introducido en la barra de búsqueda, mostrando en primer lugar la búsqueda más reciente. La barra de búsqueda también muestra cuánto tiempo hace que se ejecutó cada búsqueda reciente. Por ejemplo, si introduces `service:web-store status:error`, las cuatro búsquedas más recientes que contienen estos términos se muestran por orden de antigüedad, cada una especificando un error diferente: +{{< img src="logs/explorer/search/log_syntax_highlighting.png" alt="La barra de búsqueda de Log Explorer muestra `service:auth-dotnet status:error 500 (check-token OR create-user)` como la consulta con resaltado de sintaxis diferenciable." style="width:100%;">}} -{{< img src="logs/explorer/search/log_recent_searches.png" alt="La barra de búsqueda de logs que muestra `service:web-store status:error` como consulta y búsquedas recientes de diferentes errores de servicio de tienda web como opciones para autocompletar" style="width:80%;">}} +La validación de errores identifica errores de sintaxis y sugiere correcciones, como valores faltantes en pares `key:value`, consultas de rango incompletas o paréntesis sin cerrar. -### Autocompletar vistas guardadas +{{< img src="logs/explorer/search/log_error_states.png" alt="La barra de búsqueda del Explorador de registros muestra `service:(web-store OR auth-dotnet` como la consulta con el mensaje `Falta el carácter de paréntesis de cierre`" style="width:50%;">}} -Puedes crear vistas guardadas en el Log Explorer para guardar consultas y contexto adicional para el futuro y para un acceso centralizado. La barra de búsqueda te sugiere automáticamente las vistas guardadas que coinciden con tu entrada en la barra de búsqueda. Las vistas guardadas se muestran en el mismo orden en el que están situadas en el panel de vistas guardadas, mostrándose en primer lugar las destacadas. El nombre de la vista guardada, la consulta guardada y la imagen de perfil del usuario que la actualizó por última vez aparecen en el desplegable. Si la consulta de una vista guardada es demasiado larga para mostrarse en el desplegable, aparecerá la consulta completa en la información emergente al pasar el cursor por encima. El correo electrónico del usuario que actualizó por última vez una vista guardada también se muestra en la información emergente al pasar el cursor por encima de su foto de perfil. +### Autocompletado {#autocomplete} -{{< img src="logs/explorer/search/log_autocomplete_saved_views.png" alt="La barra de búsqueda de logs que muestra `service:web-store status:error` como consulta y vistas guardadas de errores de servicio de diferentes tiendas web como opciones para autocompletar" style="width:80%;">}} +La función de autocompletado de la barra de búsqueda le ayuda a completar consultas utilizando claves y valores existentes en sus registros, búsquedas recientes y Saved Views. -## Sintaxis de búsqueda +{{< img src="logs/explorer/search/log_search_bar_autocomplete.png" alt="La barra de búsqueda de Log Explorer que muestra service: como consulta y emailer, balancer-checker, ad-server y vpc como opciones de autocompletado." style="width:80%;">}} -El resaltado de la sintaxis diferencia claramente los tipos de entrada, como claves (por ejemplo, un atributo como `@merchant_name`), valores (por ejemplo, el nombre de un determinado comerciante), texto libre (por ejemplo, palabras clave en un mensaje de log como `responded 500`) y caracteres de control (por ejemplo, paréntesis y dos puntos). Los atributos de estado también se resaltan con colores que representan el estado, como rojo para `error` y azul para `info`. +El autocompletado sugiere facetas y valores según su entrada, los cuales se muestran en el orden en que aparecen en el [panel de facetas][7]. Después de seleccionar una faceta e ingresar `:`, los valores aparecen en orden descendente según el recuento de registros de los últimos 15 minutos. -{{< img src="logs/explorer/search/log_syntax_highlighting.png" alt="La barra de búsqueda de logs que muestra `service:auth-dotnet status:error 500 (check-token OR create-user)` como consulta con una sistaxis distinguible resaltada" style="width:100%;">}} +{{< img src="logs/explorer/search/log_facet_autocomplete.png" alt="La barra de búsqueda de Log Explorer que muestra `network` como consulta y las facetas @network.bytes_written, @network.client.ip y @network.interface como opciones de autocompletado." style="width:80%;">}} -Los estados de error claros te informan qué parte de la consulta contiene errores de sintaxis y cómo corregirlos. Por ejemplo: -- Si introduces la consulta `service:` sin ningún valor, aparecerá el mensaje "Missing value in key:value pair" (Falta valor en el par clave:valor) al pasar el cursor por encima de la consulta. -- Si introduces paréntesis para una consulta de rango, pero no rellenas los valores superior e inferior, aparecerá el mensaje "Expected term but end of input found" (Término encontrado, pero se ha llegado al final de la entrada). -- Si introduces varios valores para un campo de log, pero omites el carácter de paréntesis de cierre, como `service:(web-store OR auth-dotnet`, aparecerá el mensaje `Missing closing parenthesis character`. +Sus 100 búsquedas más recientes se conservan y se sugieren a medida que escribe. Las Saved Views que coinciden con su consulta también se sugieren, mostradas en el mismo orden que el panel de Saved Views. -{{< img src="logs/explorer/search/log_error_states.png" alt="La barra de búsqueda de logs que muestra `service:(web-store OR auth-dotnet` como consulta con el mensaje `Missing closing parenthesis character`" style="width:50%;">}} +{{< img src="logs/explorer/search/log_recent_searches.png" alt="La barra de búsqueda de registros que muestra `service:web-store status:error` como consulta y búsquedas recientes de diferentes errores del servicio web-store como opciones de autocompletado" style="width:80%;">}} -Para empezar a buscar logs y personalizar el marco temporal en el Log Explorer, lee la [documentación sobre Sintaxis de búsqueda][3] y la [documentación sobre Marcos temporales personalizados][4]. -## Desactivar estilo y autocompletar para la barra de búsqueda +## Deshabilitar el estilo y el autocompletado para la barra de búsqueda {#disable-styling-and-autocomplete-for-search-bar} -Alterna el botón situado a la derecha de la barra de búsqueda para buscar en modo sin procesar, en el que se eliminan el resaltado de sintaxis, el estilo de píldoras de búsqueda y la función de autocompletar: +Active el botón a la derecha de la barra de búsqueda para buscar en modo sin formato, donde se eliminan el resaltado de sintaxis, el estilo de las píldoras de búsqueda y el autocompletado: -{{< img src="logs/explorer/search/log_raw_search_mode.png" alt="La barra de búsqueda de logs que muestra `service:auth-dotnet status:error 500 (check-token OR create-user)` como consulta en el modo de búsqueda sin formato" style="width:100%;">}} +{{< img src="logs/explorer/search/log_raw_search_mode.png" alt="La barra de búsqueda de registros que muestra `service:auth-dotnet status:error 500 (check-token OR create-user)` como consulta en modo de búsqueda sin formato." style="width:100%;">}} -Puedes interactuar con la barra de búsqueda con el ratón, así como utilizando comandos del teclado. Por ejemplo, utiliza `CMD-A` para seleccionar texto, `CMD-C` para copiar texto, `CMD-X` para cortar texto y `CMD-V` para pegar texto. +Puede interactuar con la barra de búsqueda con el mouse, así como mediante comandos de teclado. Por ejemplo, use `CMD-A` para seleccionar texto, `CMD-C` para copiar texto, `CMD-X` para cortar texto y `CMD-V` para pegar texto. -## Referencias adicionales +## Lecturas adicionales {#further-reading} {{< partial name="whats-next/whats-next.html" >}} -[1]: /es/logs/indexes -[2]: /es/logs/explorer/facets/ -[3]: /es/logs/search-syntax -[4]: /es/dashboards/guide/custom_time_frames -[5]: /es/logs/explorer/ -[6]: /es/logs/explorer/search_syntax/#full-text-search -[7]: https://app.datadoghq.com/organization-settings/preferences -[8]: /es/account_management/rbac/permissions/#access-management \ No newline at end of file +[1]: /es/logs/explorer/ +[2]: /es/account_management/rbac/permissions/#access-management +[3]: https://app.datadoghq.com/organization-settings/preferences +[4]: /es/logs/explorer/search_syntax/#full-text-search +[5]: /es/dashboards/guide/custom_time_frames +[6]: /es/logs/indexes +[7]: /es/logs/explorer/facets/ +[8]: /es/logs/search-syntax \ No newline at end of file diff --git a/hugo/content/es/logs/guide/increase-number-of-log-files-tailed.md b/hugo/content/es/logs/guide/increase-number-of-log-files-tailed.md index f66c50e9674..2ce0c7d07ba 100644 --- a/hugo/content/es/logs/guide/increase-number-of-log-files-tailed.md +++ b/hugo/content/es/logs/guide/increase-number-of-log-files-tailed.md @@ -3,26 +3,29 @@ aliases: - /es/logs/faq/how-to-increase-the-number-of-log-files-tailed-by-the-agent further_reading: - link: /logs/faq/how-to-send-logs-to-datadog-via-external-log-shippers/ - tag: FAQ - text: ¿Cómo enviar logs a Datadog a través de cargadores de log externos? + tag: PREGUNTAS FRECUENTES + text: ¿Cómo enviar registros a Datadog a través de transportadores de registros + externos? - link: /logs/log_configuration/parsing tag: Documentación - text: Obtén más información sobre el parseo + text: Obtenga más información sobre el parseo - link: /logs/faq/how-to-investigate-a-log-parsing-issue/ - tag: FAQ - text: ¿Cómo investigar un problema de parseo de logs? -title: Aumentar el número de archivos de log supervisados por el Agent + tag: PREGUNTAS FRECUENTES + text: ¿Cómo investigar un problema de parseo de registros? +title: Aumentar el número de archivos de registro que son objeto de seguimiento de + las últimas líneas por el Agent --- - -Por defecto, el Agent puede almacenar hasta 200 archivos de log en Windows y MacOS, y 500 archivos de log en otros sistemas operativos. Este límite se coloca para evitar problemas de rendimiento cuando se establecen comodines en directorios enormes. - -Para aumentar este límite, ajusta el valor de `open_files_limit` en el archivo de configuración del Agent (`/etc/datadog-agent/datadog.yaml`) en la sección `logs_config`: +El parámetro `logs_config.open_files_limit` en el archivo de configuración del Agent (`/etc/datadog-agent/datadog.yaml`) determina la cantidad máxima de archivos de registro en seguimiento de las últimas líneas que el Agent puede manejar simultáneamente. Este límite se establece para evitar problemas de rendimiento cuando se utilizan comodines en directorios enormes. Puede aumentar el límite ajustando este parámetro. ```yaml logs_config: open_files_limit: 500 ``` -Para los entornos en contenedores, puedes establecer la variable de entorno `DD_logs_CONFIG_OPEN_FILES_LIMIT`. +Para entornos en contenedores, puede configurar la variable de entorno `DD_LOGS_CONFIG_OPEN_FILES_LIMIT`. + +El valor predeterminado varía según la versión del Agent y el sistema operativo. Para verificar el valor predeterminado de su versión del Agent, consulte los [archivos de configuración de ejemplo del Agent][1] en el repositorio del Datadog Agent. Abra el archivo correspondiente a su sistema operativo. Asegúrese de seleccionar la etiqueta correspondiente a su versión del Agent para ver los valores predeterminados correctos. + +**Nota**: Aumentar el límite de archivos de registro en seguimiento de las últimas líneas podría incrementar el consumo de recursos del Agent. -**Nota**: Aumentar el límite de archivos de logs supervisados podría incrementar el consumo de recursos del Agent. \ No newline at end of file +[1]: https://github.com/DataDog/datadog-agent/tree/main/pkg/config/example \ No newline at end of file diff --git a/hugo/content/es/metrics/types.md b/hugo/content/es/metrics/types.md index 544882ffe34..36754b31cc3 100644 --- a/hugo/content/es/metrics/types.md +++ b/hugo/content/es/metrics/types.md @@ -12,101 +12,105 @@ aliases: - /es/developers/metrics_type/ - /es/developers/metrics/metrics_type/ - /es/developers/metrics/types/ +description: Conozca los tipos de envío de métricas de Datadog (recuento, tasa, gauge, + histograma, distribución) y cómo se asignan a los tipos dentro de la aplicación. further_reading: - link: extend/dogstatsd tag: Documentación - text: Aprende más sobre DogStatsD + text: Obtenga más información sobre DogStatsD - link: /metrics/units tag: Documentación - text: Unidades de Métricas + text: Unidades de métricas - link: extend/libraries tag: Documentación - text: Bibliotecas cliente de API y DogStatsD, creadas oficialmente y por la comunidad -title: Tipos de Métricas + text: Bibliotecas de cliente para API y DogStatsD oficiales y creadas por la comunidad +title: Tipos de métricas --- -## Resumen {#overview} +## Descripción general {#overview} -Cada métrica enviada a Datadog debe tener un tipo. El tipo de una métrica afecta cómo se muestran los valores de la métrica al consultarlos, así como las posibilidades de graficación asociadas dentro de Datadog utilizando [modificadores][1] y [funciones][2]. El tipo de una métrica se muestra en el panel lateral de detalles para la métrica dada en la [Metrics Summary page][3]. +Cada métrica enviada a Datadog debe tener un tipo. El tipo de una métrica afecta cómo se muestran los valores de la métrica al realizar consultas, así como las posibilidades de graficado asociadas dentro de Datadog mediante el uso de [modificadores][1] y [funciones][2] adicionales. El tipo de una métrica se muestra en el panel lateral de detalles de la métrica dada en la [página de Metrics Summary][3]. -**Nota**: Cambiar el tipo de métrica en este panel lateral de detalles puede cambiar el comportamiento de la métrica en todas las visualizaciones y monitores existentes, lo que potencialmente puede hacer que los datos históricos sean incomprensibles. +**Nota**: Cambiar el tipo de métrica en este panel lateral de detalles puede cambiar el comportamiento de la métrica en todas las visualizaciones y monitores existentes, lo que podría hacer que los datos históricos carezcan de sentido. -Los siguientes tipos de envío de métricas son aceptados: +Se aceptan los siguientes tipos de envío de métricas: -- [COUNT](?tab=count#metric-types) +- [RECUENTO](?tab=count#metric-types) - [TASA](?tab=rate#metric-types) - [GAUGE](?tab=gauge#metric-types) -- [CONJUNTO][4] +- [SET][4] - [HISTOGRAMA](?tab=histogram#metric-types) - [DISTRIBUCIÓN](?tab=distribution#metric-types) -Estos diferentes tipos de envío de métricas se asignan a cuatro tipos de métricas en la aplicación que se encuentran dentro de la aplicación web de Datadog: +Estos diferentes tipos de envío de métricas se asignan a cinco tipos de métricas dentro de la aplicación que se encuentran en la aplicación web de Datadog: -- CUENTA +- RECUENTO - TASA - GAUGE - DISTRIBUCIÓN +- HISTOGRAMA (Explícito, Exponencial) -**Nota**: Si envías una métrica a Datadog sin un tipo, el tipo de métrica aparece como `Not Assigned` dentro de Datadog. El tipo de métrica `Not Assigned` no puede ser cambiado a otro tipo en la aplicación hasta que se envíe un tipo de métrica inicial. +**Nota**: Si envía una métrica a Datadog sin un tipo, el tipo de métrica aparece como {{< ui >}}Not Assigned{{< /ui >}} dentro de Datadog. El tipo de métrica {{< ui >}}Not Assigned{{< /ui >}} no puede cambiarse a otro tipo en la aplicación hasta que se envíe un tipo de métrica inicial. -## Envío vs. tipo en la aplicación {#submission-vs-in-app-type} +## Envío frente al tipo en la aplicación {#submission-vs-in-app-type} -Las métricas se envían a Datadog de tres maneras principales: +Las métricas se envían a Datadog de cuatro formas principales: -- [Verificación del agente][5] +- [Agent check][5] - [DogStatsD][6] -- [API HTTP de Datadog][7] +- [Datadog's HTTP API][7] +- [OTLP Metrics API][20] -La mayoría de los datos que Datadog recibe son enviados por el Agente, ya sea a través de una verificación del Agente o DogStatsD. Para estos métodos de envío, el tipo de una métrica determina cómo se agregan múltiples valores recolectados en un Agente en [a flush time interval][8]. El Agente combina estos valores en un único valor métrico representativo para ese intervalo. Este valor combinado se almacena con una única marca de tiempo en Datadog. +La mayor parte de los datos que recibe Datadog se envían a través del Agent, ya sea mediante una comprobación del Agent o DogStatsD. Para estos métodos de envío, el tipo de métrica determina cómo se agregan los múltiples valores recopilados en un Agent en [un intervalo de tiempo de vaciado][8]. El Agent combina estos valores en un único valor de métricas representativo para ese intervalo. Este valor combinado se almacena con una única marca de tiempo en Datadog. -Los datos enviados directamente a la API de Datadog no son agregados por Datadog, con la excepción de las métricas de distribución. Los valores crudos enviados a Datadog se almacenan tal como están. +Los datos enviados directamente a la Datadog API no son agregados por Datadog, con la excepción de las métricas de distribución. Los valores sin procesar enviados a Datadog se almacenan tal cual. -Lee la sección [Tipos de envío y tipos en la aplicación de Datadog](#submission-types-and-datadog-in-app-types) para aprender cómo se mapean los diferentes tipos de envío de métricas a sus tipos correspondientes en la aplicación. +Lea la sección [Tipos de envío y tipos de métricas en la aplicación de Datadog](#submission-types-and-datadog-in-app-types) para obtener información sobre cómo se asignan los diferentes tipos de envío de métricas a sus tipos correspondientes en la aplicación. ## Tipos de métricas {#metric-types} ### Definición {#definition} {{< tabs >}} -{{% tab "COUNT" %}} +{{% tab "RECUENTO" %}} -El tipo de envío de métrica COUNT representa el número total de ocurrencias de eventos en un intervalo de tiempo. Un COUNT se puede utilizar para rastrear el número total de conexiones realizadas a una base de datos o el número total de solicitudes a un punto de conexión. Este número de eventos puede acumularse o disminuir con el tiempo; no es monotónicamente creciente. +El tipo de envío de métrica COUNT representa el número total de ocurrencias de eventos en un intervalo de tiempo. Un COUNT se puede utilizar para realizar un seguimiento del número total de conexiones realizadas a una base de datos o del número total de solicitudes a un punto de conexión. Este número de eventos puede acumularse o disminuir con el tiempo; no aumenta de forma monótona. -**Nota**: Un COUNT es diferente del tipo de métrica RATE, que representa el número de ocurrencias de eventos normalizadas por segundo según el intervalo de tiempo definido. +**Nota**: Un COUNT es diferente del tipo de métrica RATE, que representa el número de ocurrencias de eventos normalizado por segundo dado el intervalo de tiempo definido. {{% /tab %}} {{% tab "RATE" %}} -El tipo de envío de métrica RATE representa el número total de ocurrencias de eventos por segundo en un intervalo de tiempo. Un RATE se puede utilizar para rastrear con qué frecuencia ocurre algo, como la frecuencia de conexiones realizadas a una base de datos o el flujo de solicitudes realizadas a un punto de conexión. +El tipo de envío de métrica RATE representa el número total de ocurrencias de eventos por segundo en un intervalo de tiempo. Un RATE se puede utilizar para realizar un seguimiento de la frecuencia con la que sucede algo, como la frecuencia de las conexiones realizadas a una base de datos o el flujo de solicitudes realizadas a un punto de conexión. **Nota**: Un RATE es diferente del tipo de envío de métrica COUNT, que representa el número total de ocurrencias de eventos en el intervalo de tiempo dado. {{% /tab %}} {{% tab "GAUGE" %}} -El tipo de envío de métrica GAUGE representa una instantánea de eventos en un intervalo de tiempo. Este valor de instantánea representativa es el último valor enviado al Agente durante un intervalo de tiempo. Un GAUGE se puede utilizar para medir algo que reporta continuamente, como el espacio en disco disponible o la memoria utilizada. +El tipo de envío de métrica GAUGE representa una instantánea de eventos en un intervalo de tiempo. Este valor de instantánea representativo es el último valor enviado al Agent durante un intervalo de tiempo. Un GAUGE se puede utilizar para tomar una medida de algo que se informa continuamente, como el espacio en disco disponible o la memoria utilizada. {{% /tab %}} -{{% tab "HISTOGRAMA" %}} +{{% tab "HISTOGRAM" %}} -El tipo de envío de métrica HISTOGRAMA representa la distribución estadística de un conjunto de valores calculados del lado del Agente en un intervalo de tiempo. El tipo de métrica HISTOGRAMA de Datadog es una extensión del tipo de métrica de tiempo StatsD. El Agente agrega los valores que se envían en un intervalo de tiempo definido y produce diferentes métricas que representan el conjunto de valores. +El tipo de envío de métrica HISTOGRAM representa la distribución estadística de un conjunto de valores calculados en el lado del Agent en un intervalo de tiempo. El tipo de métrica HISTOGRAM de Datadog es una extensión del tipo de métrica de temporización StatsD. El Agent agrega los valores que se envían en un intervalo de tiempo definido y produce diferentes métricas que representan el conjunto de valores. -Si envías `X` valores para una métrica HISTOGRAMA `` en un intervalo de tiempo dado, las siguientes métricas son producidas por el Agente por defecto: +Si envía `X` valores para una métrica HISTOGRAM `` en un intervalo de tiempo determinado, el Agent produce las siguientes métricas de forma predeterminada: `.avg` : Representa el promedio de esos `X` valores en el intervalo de tiempo.
-**Datadog In-App Type**: GAUGE +**Tipo en la aplicación de Datadog**: GAUGE `.count` -: Representa el número de valores enviados durante el intervalo, `X`. El Agente envía este número como un RATE para que se muestre en la aplicación el valor de `X/interval`.
-**Datadog In-App Type**: RATE +: Representa la cantidad de valores enviados durante el intervalo, `X`. El Agent envía este número como RATE, por lo que mostraría en la aplicación el valor de `X/interval`.
+**Tipo en la aplicación de Datadog**: RATE `.median` : Representa la mediana de esos `X` valores en el intervalo de tiempo.
-**Tipo In-App de Datadog**: GAUGE +**Tipo en la aplicación de Datadog**: GAUGE `.95percentile` : Representa el percentil 95 de esos `X` valores en el intervalo de tiempo.
-**Tipo In-App de Datadog**: GAUGE +**Tipo en la aplicación de Datadog**: GAUGE `.max` : Representa el valor máximo de esos `X` valores enviados durante el intervalo de tiempo.
@@ -114,30 +118,29 @@ Si envías `X` valores para una métrica HISTOGRAMA `` en un interv **Notas**: -- Configura qué agregaciones deseas enviar a Datadog con el parámetro `histogram_aggregates` en tu [`datadog.yaml` archivo de configuración][1]. Por defecto, solo se envían a Datadog las agregaciones `max`, `median`, `avg` y `count`. `sum` y `min` también están disponibles. -- Configura qué agregación de percentil deseas enviar a Datadog con el parámetro `histogram_percentiles` en tu [`datadog.yaml` archivo de configuración][2]. Por defecto, solo se envía a Datadog el `95percentile`. +- Configure qué agregaciones desea enviar a Datadog con el parámetro `histogram_aggregates` en su [archivo de configuración `datadog.yaml`][1]. De forma predeterminada, solo se envían a Datadog las agregaciones `max`, `median`, `avg` y `count`. `sum` y `min` también están disponibles. +- Configure qué agregación de percentil desea enviar a Datadog con el parámetro `histogram_percentiles` en su [archivo de configuración `datadog.yaml`][1]. De forma predeterminada, solo se envía `95percentile` a Datadog. -[1]: https://github.com/DataDog/datadog-agent/blob/04d8ae9dd4bc6c7a64a8777e8a38127455ae3886/pkg/config/config_template.yaml#L106-L114 -[2]: https://github.com/DataDog/datadog-agent/blob/04d8ae9dd4bc6c7a64a8777e8a38127455ae3886/pkg/config/config_template.yaml#L116-L121 +[1]: https://github.com/DataDog/datadog-agent/blob/main/pkg/config/example/datadog-agent_linux.yaml.example {{% /tab %}} -{{% tab "DISTRIBUCIÓN" %}} +{{% tab "DISTRIBUTION" %}} -El tipo de envío de métrica de DISTRIBUCIÓN representa la distribución estadística global de un conjunto de valores calculados a través de toda su infraestructura distribuida en un intervalo de tiempo. Una DISTRIBUTION puede ser utilizada para instrumentar objetos lógicos, como servicios, independientemente de los servidores subyacentes. +El tipo de envío de métricas DISTRIBUTION representa la distribución estadística global de un conjunto de valores calculados en toda su infraestructura distribuida en un intervalo de tiempo. Una DISTRIBUTION se puede utilizar para instrumentar objetos lógicos, como servicios, independientemente de los hosts subyacentes. -A diferencia del tipo de métrica HISTOGRAM, que agrega en el Agente durante un intervalo de tiempo dado, una métrica de DISTRIBUTION envía todos los datos en bruto durante un intervalo de tiempo a Datadog. Las agregaciones ocurren del lado del servidor. Debido a que la estructura de datos subyacente representa datos en bruto, no agregados, las distribuciones proporcionan dos características principales: +A diferencia del tipo de métrica HISTOGRAM, que se agrega en el Agent durante un intervalo de tiempo determinado, una métrica DISTRIBUTION envía todos los datos sin procesar durante un intervalo de tiempo a Datadog. Las agregaciones ocurren en el lado del servidor. Debido a que la estructura de datos subyacente representa datos sin procesar y no agregados, las distribuciones ofrecen dos características principales: -- Cálculo de agregaciones percentiles -- Personalización de etiquetado +- Cálculo de agregaciones de percentiles +- Personalización de etiquetas -Si envía `X` valores para una métrica de DISTRIBUCIÓN `` en un intervalo de tiempo dado, las siguientes agregaciones están disponibles para consulta por defecto: +Si envía `X` valores para una métrica DISTRIBUTION `` en un intervalo de tiempo determinado, las siguientes agregaciones están disponibles para consulta de forma predeterminada: `avg:` : Representa el promedio de esos `X` valores en el intervalo de tiempo.
**Tipo en la aplicación de Datadog**: GAUGE `count:` -: Representa el número de puntos enviados en el intervalo de tiempo, `X`. El Agente luego lo envía como un COUNT.
+: Representa la cantidad de puntos enviados en el intervalo de tiempo, `X`. El Agent luego lo envía como un COUNT.
**Tipo en la aplicación de Datadog**: COUNT `max:` @@ -145,14 +148,14 @@ Si envía `X` valores para una métrica de DISTRIBUCIÓN `` en un i **Tipo en la aplicación de Datadog**: GAUGE `min:` -: Representa el valor mínimo de aquellos `X` enviados en el intervalo de tiempo.
+: Representa el valor mínimo de esos `X` enviados en el intervalo de tiempo.
**Tipo en la aplicación de Datadog**: GAUGE `sum:` : Representa la suma de todos los valores `X` enviados en el intervalo de tiempo.
**Tipo en la aplicación de Datadog**: COUNT -**Nota**: Mientras que las diferentes agregaciones de los valores de métricas de distribución están _representadas_ como GAUGE o COUNT en la aplicación, la métrica en sí mantiene el tipo `DISTRIBUTION`. +**Nota**: Si bien las diferentes agregaciones de valores de métricas de distribución se _representan_ como gauges o counts en la aplicación, la métrica en sí conserva el tipo `DISTRIBUTION`. {{% /tab %}} {{< /tabs >}} @@ -160,32 +163,32 @@ Si envía `X` valores para una métrica de DISTRIBUCIÓN `` en un i ### Ejemplo {#example} {{< tabs >}} -{{% tab "COUNT" %}} +{{% tab "RECUENTO" %}} -Supongamos que estás enviando una métrica de COUNT, `notifications.sent`, desde un único servidor que ejecuta el Datadog Agent. Este host emite los siguientes valores en un intervalo de tiempo de flush: `[1,1,1,2,2,2,3,3]`. +Suponga que está enviando una métrica COUNT, `notifications.sent`, desde un solo servidor que ejecuta el Datadog Agent. Este servidor emite los siguientes valores en un intervalo de tiempo de vaciado: `[1,1,1,2,2,2,3,3]`. -El Agente suma todos los valores recibidos en un intervalo de tiempo. Luego, envía el número total, en este caso `15`, como el valor de la métrica CUENTA. +El Agent suma todos los valores recibidos en un intervalo de tiempo. Luego, envía el número total, en este caso `15`, como el valor de la métrica COUNT. {{% /tab %}} {{% tab "RATE" %}} -Supongamos que estás enviando una métrica TASA, `queue_messages.rate`, desde un único host que ejecuta el Datadog Agent. Este host emite los siguientes valores en un intervalo de tiempo de flush: `[1,1,1,2,2,2,3,3]`. +Suponga que está enviando una métrica RATE, `queue_messages.rate`, desde un solo servidor que ejecuta el Datadog Agent. Este servidor emite los siguientes valores en un intervalo de tiempo de vaciado: `[1,1,1,2,2,2,3,3]`. -El Agente suma todos los valores recibidos en un intervalo de tiempo. Luego, envía el número total dividido por el número total de segundos en este intervalo de tiempo. En este caso, si el intervalo de flush es de 10 segundos, el valor enviado sería `1.5` como el valor de la métrica TASA. +El Agent suma todos los valores recibidos en un intervalo de tiempo. Luego, envía el número total dividido por el número total de segundos en este intervalo de tiempo. En este caso, si el intervalo de vaciado es de 10 segundos, el valor enviado sería `1.5` como el valor de la métrica RATE. {{% /tab %}} {{% tab "GAUGE" %}} -Supongamos que estás enviando una métrica GAUGE, `temperature`, desde un único host que ejecuta el Datadog Agent. Este host emite los siguientes valores en un intervalo de tiempo de flush: `[71,71,71,71,71,71,71.5]`. +Suponga que está enviando una métrica GAUGE, `temperature`, desde un solo servidor que ejecuta el Datadog Agent. Este servidor emite los siguientes valores en un intervalo de tiempo de vaciado: `[71,71,71,71,71,71,71.5]`. -El Agente envía el último número reportado, en este caso `71.5`, como el valor de la métrica GAUGE. +El Agent envía el último número reportado, en este caso `71.5`, como el valor de la métrica GAUGE. {{% /tab %}} -{{% tab "HISTOGRAMA" %}} +{{% tab "HISTOGRAM" %}} -Por ejemplo, supongamos que estás enviando una métrica HISTOGRAM, `request.response_time.histogram`, desde un servidor web que reporta los valores `[1,1,1,2,2,2,3,3]` en un intervalo de tiempo de flush de 10 segundos. Por defecto, el Agente envía las siguientes métricas a Datadog que representan la distribución estadística de estos valores en este intervalo de tiempo: +Por ejemplo, suponga que está enviando una métrica HISTOGRAM, `request.response_time.histogram`, desde un servidor web que reporta los valores `[1,1,1,2,2,2,3,3]` en un intervalo de tiempo de vaciado de 10 segundos. De forma predeterminada, el Agent envía las siguientes métricas a Datadog, las cuales representan la distribución estadística de estos valores en este intervalo de tiempo: -| Nombre de la Métrica | Valor | Tipo de In-App de Datadog | +| Nombre de la métrica | Valor | Tipo en la aplicación de Datadog | | ---------------------------------------------- | ------ | ------------------- | | `request.response_time.histogram.avg` | `1.88` | GAUGE | | `request.response_time.histogram.count` | `0.8` | RATE | @@ -194,25 +197,25 @@ Por ejemplo, supongamos que estás enviando una métrica HISTOGRAM, `request.res | `request.response_time.histogram.max` | `3` | GAUGE | {{% /tab %}} -{{% tab "DISTRIBUCIÓN" %}} +{{% tab "DISTRIBUTION" %}} -Supongamos que estás enviando una métrica DISTRIBUCIÓN, `request.response_time.distribution`, desde dos servidores web: `webserver:web_1` y `webserver:web_2`. Supongamos que en un intervalo de tiempo de flush dado, `webserver:web_1` informa la métrica con los valores `[1,1,1,2,2,2,3,3]`, y `webserver:web_2` informa la misma métrica con los valores `[1,1,2]`. Durante este intervalo de tiempo, las siguientes cinco agregaciones representarán la distribución estadística global de todos los valores recopilados de ambos servidores web: +Suponga que está enviando una métrica de DISTRIBUCIÓN, `request.response_time.distribution`, desde dos servidores web: `webserver:web_1` y `webserver:web_2`. Suponga que en un intervalo de tiempo de vaciado determinado, `webserver:web_1` informa la métrica con los valores `[1,1,1,2,2,2,3,3]`, y `webserver:web_2` informa la misma métrica con los valores `[1,1,2]`. Durante este intervalo de tiempo, las siguientes cinco agregaciones representarán la distribución estadística global de todos los valores recopilados de ambos servidores web: -| Nombre de la métrica | Valor | Tipo In-App de Datadog | +| Nombre de la métrica | Valor | Tipo en la aplicación de Datadog | | ------------------------------------------ | ------ | ------------------- | | `avg:request.response_time.distribution` | `1.73` | GAUGE | -| `count:request.response_time.distribution` | `11` | COUNT | +| `count:request.response_time.distribution` | `11` | RECUENTO | | `max:request.response_time.distribution` | `3` | GAUGE | | `min:request.response_time.distribution` | `1` | GAUGE | -| `sum:request.response_time.distribution` | `19` | COUNT | +| `sum:request.response_time.distribution` | `19` | RECUENTO | -#### Cálculo de agregaciones percentiles {#calculation-of-percentile-aggregations} +#### Cálculo de agregaciones de percentiles {#calculation-of-percentile-aggregations} -Al igual que otros tipos de métricas, como GAUGE o HISTOGRAMA, el tipo de métrica de DISTRIBUCIÓN tiene las siguientes agregaciones disponibles: `count`, `min`, `max`, `sum` y `avg`. Las métricas de distribución se etiquetan inicialmente de la misma manera que otras métricas (con etiquetas personalizadas establecidas en el código). +Al igual que otros tipos de métricas, como GAUGE o HISTOGRAM, el tipo de métrica DISTRIBUTION tiene disponibles las siguientes agregaciones: `count`, `min`, `max`, `sum` y `avg`. Las métricas de distribución se etiquetan inicialmente de la misma manera que otras métricas (con etiquetas personalizadas configuradas en el código). -Agregaciones percentiles adicionales (`p50`, `p75`, `p90`, `p95`, `p99`) se pueden agregar a las métricas de distribución desde el [panel lateral de detalles][2] de la métrica. Si agregas agregaciones percentiles a tu métrica DISTRIBUCIÓN en la aplicación, las siguientes cinco agregaciones adicionales están disponibles para consulta: +Se pueden agregar agregaciones de percentiles adicionales (`p50`, `p75`, `p90`, `p95`, `p99`) a las métricas de distribución desde el [panel lateral de detalles][2] de la métrica. Si agregara agregaciones de percentiles a su métrica de distribución en la aplicación, las siguientes cinco agregaciones adicionales estarían disponibles para consulta: -| Nombre de Métrica | Valor | Tipo In-app de Datadog | +| Nombre de la métrica | Valor | Tipo en la aplicación de Datadog | | ---------------------------------------- | ----- | ------------------- | | `p50:request.response_time.distribution` | `2` | GAUGE | | `p75:request.response_time.distribution` | `2` | GAUGE | @@ -220,15 +223,15 @@ Agregaciones percentiles adicionales (`p50`, `p75`, `p90`, `p95`, `p99`) se pued | `p95:request.response_time.distribution` | `3` | GAUGE | | `p99:request.response_time.distribution` | `3` | GAUGE | -Es decir, para una métrica de distribución con agregaciones percentiles añadidas durante un intervalo de tiempo dado, las siguientes 10 agregaciones están disponibles: `count`, `sum`, `min`, `max`, `avg`, `p50`, `p75`, `p90`, `p95` y `p99`. +Es decir, para una métrica de distribución con agregaciones de percentiles añadidas durante un intervalo de tiempo determinado, están disponibles las siguientes 10 agregaciones: `count`, `sum`, `min`, `max`, `avg`, `p50`, `p75`, `p90`, `p95` y `p99`. -**Nota**: Mientras que las diferentes agregaciones de los valores de la métrica de distribución están _representadas_ como gauges o cuentas en la aplicación, la métrica en sí mantiene el tipo `DISTRIBUTION`. +**Nota**: Si bien las diferentes agregaciones de valores de métricas de distribución se _representan_ como gauges o counts en la aplicación, la métrica en sí conserva el tipo `DISTRIBUTION`. #### Personalización de etiquetas {#customization-of-tagging} -Esta funcionalidad te permite controlar las etiquetas para métricas donde la granularidad a nivel de host no es necesaria. Aprende más sobre [Métricas sin Límites™][1]. +Esta funcionalidad le permite controlar el etiquetado de métricas donde no es necesaria la granularidad a nivel de servidor. Obtenga más información sobre [Metrics without Limits™][1]. -**Nota**: La exclusión de etiquetas no es compatible en la personalización de etiquetas basada en la lista permitida. No se aceptan etiquetas que comiencen con `!`. +**Nota**: La exclusión de etiquetas no es compatible con la personalización de etiquetas basada en listas de permitidos. No se aceptan etiquetas que comiencen con `!`. [1]: /es/metrics/metrics-without-limits/ [2]: /es/metrics/summary/#metric-details-sidepanel @@ -238,20 +241,20 @@ Esta funcionalidad te permite controlar las etiquetas para métricas donde la gr ### Envío {#submission} {{< tabs >}} -{{% tab "CUENTA" %}} +{{% tab "RECUENTO" %}} -Envía tus métricas de tipo CUENTA desde una de las siguientes fuentes: +Envíe sus métricas de tipo COUNT desde una de las siguientes fuentes: -| Fuente de Envío | Método de Envío (python) | Tipo de Envío | Tipo In-App de Datadog | +| Fuente de envío | Método de envío (python) | Tipo de envío | Tipo en la aplicación de Datadog | | ----------------- | ------------------------------------ | --------------- | ------------------- | -| [Verificación de agente][1] | `self.count(...)` | CUENTA | CUENTA | -| [Verificación de agente][2] | `self.monotonic_count(...)` | CUENTA | CUENTA | -| [API][3] | `api.Metric.send(type="count", ...)` | CUENTA | CUENTA | -| [DogStatsD][4] | `dog.count(...)` | CUENTA | TASA | -| [DogStatsD][4] | `dog.increment(...)` | CUENTA | TASA | -| [DogStatsD][4] | `dog.decrement(...)` | CUENTA | TASA | +| [Verificación del agente][1] | `self.count(...)` | COUNT | COUNT | +| [Verificación del agente][2] | `self.monotonic_count(...)` | COUNT | COUNT | +| [API][3] | `api.Metric.send(type="count", ...)` | COUNT | COUNT | +| [DogStatsD][4] | `dog.count(...)` | COUNT | RATE | +| [DogStatsD][4] | `dog.increment(...)` | COUNT | RATE | +| [DogStatsD][4] | `dog.decrement(...)` | COUNT | RATE | -**Nota**: Al enviar un tipo de métrica de CUENTA a través de DogStatsD, la métrica aparece como una TASA en la aplicación para asegurar una comparación relevante entre diferentes Agentes. En consecuencia, los conteos de StatsD pueden aparecer con un valor decimal dentro de Datadog (ya que están normalizados sobre un intervalo de tiempo para reportar unidades por segundo). +**Nota**: Al enviar un tipo de métrica de COUNT a través de DogStatsD, la métrica aparece como una RATE en la aplicación para garantizar una comparación relevante entre diferentes agentes. En consecuencia, los COUNT de StatsD pueden aparecer con un valor decimal dentro de Datadog (ya que se normalizan durante un intervalo de tiempo para informar unidades por segundo). [1]: /es/metrics/custom_metrics/agent_metrics_submission/?tab=count#count @@ -259,16 +262,16 @@ Envía tus métricas de tipo CUENTA desde una de las siguientes fuentes: [3]: /es/api/latest/metrics/#submit-metrics [4]: /es/metrics/custom_metrics/dogstatsd_metrics_submission/#count {{% /tab %}} -{{% tab "TASA" %}} +{{% tab "RATE" %}} -Envía tus métricas de tipo TASA desde una de las siguientes fuentes: +Envíe sus métricas de tipo RATE desde una de las siguientes fuentes: -| Fuente de envío | Método de envío (python) | Tipo de envío | Tipo en la aplicación de Datadog | +| Fuente | Método de envío (python) | Tipo de envío | Tipo en la aplicación Datadog | | ----------------- | ----------------------------------- | --------------- | ------------------- | -| [Verificación de agente][1] | `self.rate(...)` | TASA | GAUGE | -| [API][2] | `api.Metric.send(type="rate", ...)` | TASA | TASA | +| [Verificación del Agent][1] | `self.rate(...)` | RATE | GAUGE | +| [API][2] | `api.Metric.send(type="rate", ...)` | RATE | RATE | -**Nota**: Para obtener métricas de TASA a través de DogStatsD, envía ya sea una métrica CUENTA [16] o HISTOGRAMA [18]. Los valores de la métrica CUENTA y los valores de `.count` son deltas normalizados en el tiempo del valor de la métrica durante el período de vaciado de StatsD. +**Nota**: Para obtener métricas de RATE a través de DogStatsD, envíe una métrica de [COUNT][16] o [HISTOGRAM][18]. Los valores de las métricas COUNT y `.count` son deltas normalizados por tiempo del valor de la métrica durante el período de vaciado de StatsD. [1]: /es/metrics/custom_metrics/agent_metrics_submission/?tab=rate @@ -276,11 +279,11 @@ Envía tus métricas de tipo TASA desde una de las siguientes fuentes: {{% /tab %}} {{% tab "GAUGE" %}} -Envía tus métricas de tipo GAUGE desde una de las siguientes fuentes: +Envíe sus métricas de tipo GAUGE desde una de las siguientes fuentes: -| Fuente de envío | Método de envío (Python) | Tipo de envío | Tipo en la aplicación de Datadog | +| Fuente | Método de envío (Python) | Tipo de envío | Tipo en la aplicación Datadog | | ----------------- | ------------------------------------ | --------------- | ------------------- | -| [Verificación de agente][1] | `self.gauge(...)` | GAUGE | GAUGE | +| [Verificación del Agent][1] | `self.gauge(...)` | GAUGE | GAUGE | | [API][2] | `api.Metric.send(type="gauge", ...)` | GAUGE | GAUGE | | [DogStatsD][3] | `dog.gauge(...)` | GAUGE | GAUGE | @@ -289,63 +292,63 @@ Envía tus métricas de tipo GAUGE desde una de las siguientes fuentes: [2]: /es/api/latest/metrics/#submit-metrics [3]: /es/metrics/custom_metrics/dogstatsd_metrics_submission/#gauge {{% /tab %}} -{{% tab "HISTOGRAMA" %}} +{{% tab "HISTOGRAM" %}} -Envía tus métricas de tipo HISTOGRAMA desde una de las siguientes fuentes: +Envíe sus métricas de tipo HISTOGRAM desde una de las siguientes fuentes: -| Fuente de envío | Método de envío (Python) | Tipo de envío | Tipo In-App de Datadog | +| Fuente | Método de envío (Python) | Tipo de envío | Tipos de Datadog en la aplicación | | ----------------- | -------------------------- | --------------- | -------------------- | -| [Verificación de agente][1] | `self.histogram(...)` | HISTOGRAMA | GAUGE, RATE | -| [DogStatsD][2] | `dog.histogram(...)` | HISTOGRAMA | GAUGE, RATE | +| [Agent check][1] | `self.histogram(...)` | HISTOGRAM | GAUGE, RATE | +| [DogStatsD][2] | `dog.histogram(...)` | HISTOGRAM | GAUGE, RATE | -Enviar una métrica TIMER al Agente de Datadog es equivalente a enviar una métrica HISTOGRAMA dentro de DogStatsD (no debe confundirse con los temporizadores en el StatsD estándar). [DogStatsD `TIMER`][3] representa solo datos de duración. Por ejemplo, la cantidad de tiempo que tarda una sección de código en ejecutarse o cuánto tiempo toma renderizar completamente una página. +El envío de una métrica TIMER al Datadog Agent es equivalente al envío de un tipo de métrica HISTOGRAM dentro de DogStatsD (no confundir con los timers en el StatsD estándar). [DogStatsD `TIMER`][3] representa solo datos de duración. Por ejemplo, la cantidad de tiempo que tarda en ejecutarse una sección de código o cuánto tiempo tarda en renderizarse completamente una página. [1]: /es/metrics/custom_metrics/agent_metrics_submission/?tab=histogram [2]: /es/metrics/custom_metrics/dogstatsd_metrics_submission/#histogram [3]: /es/metrics/custom_metrics/dogstatsd_metrics_submission/#timer {{% /tab %}} -{{% tab "DISTRIBUCIÓN" %}} +{{% tab "DISTRIBUTION" %}} -Envía tus métricas de tipo DISTRIBUCIÓN desde la siguiente fuente: +Envíe sus métricas de tipo DISTRIBUTION desde la siguiente fuente: -| Fuente de envío | Método de envío (Python) | Tipo de envío | Tipo In-App de Datadog | +| Fuente | Método de envío (Python) | Tipo de envío | Tipos de Datadog en la aplicación | | ----------------- | -------------------------- | --------------- | -------------------- | -| [DogStatsD][1] | `dog.distribution(...)` | DISTRIBUCIÓN | GAUGE, COUNT | -| [API][2] | `api_instance.submit_distribution_points(...)` | DISTRIBUCIÓN | GAUGE, COUNT | +| [DogStatsD][1] | `dog.distribution(...)` | DISTRIBUTION | GAUGE, COUNT | +| [API][2] | `api_instance.submit_distribution_points(...)` | DISTRIBUTION | GAUGE, COUNT | -**Nota**: Mientras que las diferentes agregaciones de los valores de métrica de distribución se _representan_ como gauges o COUNT en la aplicación, la métrica en sí retiene el tipo `DISTRIBUTION`. +**Nota**: Si bien las diferentes agregaciones de valores de métricas de distribución se _representan_ como gauges o counts en la aplicación, la métrica en sí conserva el tipo `DISTRIBUTION`. [1]: /es/metrics/custom_metrics/dogstatsd_metrics_submission/#distribution [2]: /es/api/latest/metrics/#submit-distribution-points {{% /tab %}} {{< /tabs >}} -## Tipos de envío y tipos en la aplicación de Datadog {#submission-types-and-datadog-in-app-types} +## Tipos de envío y tipos de Datadog en la aplicación {#submission-types-and-datadog-in-app-types} -A continuación se presenta un resumen de todas las fuentes y métodos de envío de métricas disponibles. Esta tabla muestra la correspondencia entre el tipo de envío métrico correspondiente y los tipos en la aplicación: +A continuación se presenta un resumen de todas las fuentes y métodos de envío de métricas disponibles. Esta tabla muestra la correspondencia entre el tipo de envío de métricas correspondiente y los tipos en la aplicación: -| Fuente de Envío | Método de Envío (Python) | Tipo de Envío | Tipos en la Aplicación de Datadog | +| Fuente de envío | Método de envío (Python) | Tipo de envío | Tipos de Datadog en la aplicación | | ----------------- | ------------------------------------ | --------------- | -------------------- | | [Agent check][9] | `self.count(...)` | COUNT | COUNT | | [Agent check][10] | `self.monotonic_count(...)` | COUNT | COUNT | | [Agent check][11] | `self.gauge(...)` | GAUGE | GAUGE | | [Agent check][12] | `self.histogram(...)` | HISTOGRAM | GAUGE, RATE | | [Agent check][13] | `self.rate(...)` | RATE | GAUGE | -| [API][7] | `api.Metric.send(type="count", ...)` | COUNT | COUNT | +| [API][7] | `api.Metric.send(type="count", ...)` | CONTADOR | CONTADOR | | [API][7] | `api.Metric.send(type="gauge", ...)` | GAUGE | GAUGE | | [API][7] | `api.Metric.send(type="rate", ...)` | RATE | RATE | | [DogStatsD][14] | `dog.gauge(...)` | GAUGE | GAUGE | -| [DogStatsD][15] | `dog.distribution(...)` | DISTRIBUCIÓN | DISTRIBUCIÓN | +| [DogStatsD][15] | `dog.distribution(...)` | DISTRIBUTION | DISTRIBUTION | | [DogStatsD][16] | `dog.count(...)` | COUNT | RATE | | [DogStatsD][16] | `dog.increment(...)` | COUNT | RATE | | [DogStatsD][16] | `dog.decrement(...)` | COUNT | RATE | | [DogStatsD][17] | `dog.set(...)` | SET | GAUGE | | [DogStatsD][18] | `dog.histogram(...)` | HISTOGRAM | GAUGE, RATE | -**Nota**: Mientras que las diferentes agregaciones de los valores métricos de distribución se _representan_ como gauges o COUNT en la aplicación, la métrica en sí mantiene el tipo `DISTRIBUTION`. Consulte la sección de [Definiciones][19] de esta página para más información. +**Nota**: Si bien las diferentes agregaciones de valores de métricas de distribución se _representan_ como gauges o counts en la aplicación, la métrica en sí conserva el tipo `DISTRIBUTION`. Consulte la sección [Definiciones][19] de esta página para obtener más información. -## Lectura adicional {#further-reading} +## Lecturas adicionales {#further-reading} {{< partial name="whats-next/whats-next.html" >}} @@ -367,4 +370,5 @@ A continuación se presenta un resumen de todas las fuentes y métodos de envío [16]: /es/metrics/custom_metrics/dogstatsd_metrics_submission/#count [17]: /es/metrics/custom_metrics/dogstatsd_metrics_submission/#set [18]: /es/metrics/custom_metrics/dogstatsd_metrics_submission/#histogram -[19]: /es/metrics/types/?tab=distribution#definition \ No newline at end of file +[19]: /es/metrics/types/?tab=distribution#definition +[20]: /es/opentelemetry/setup/otlp_ingest/metrics/ \ No newline at end of file diff --git a/hugo/content/es/monitors/guide/on_missing_data.md b/hugo/content/es/monitors/guide/on_missing_data.md index 1b0955636b2..9c9c306ed17 100644 --- a/hugo/content/es/monitors/guide/on_missing_data.md +++ b/hugo/content/es/monitors/guide/on_missing_data.md @@ -1,46 +1,45 @@ --- -description: Migra de las configuraciones heredadas Sin datos a las opciones Datos - perdidos para una mejor gestión de los datos perdidos en los monitores de métricas. +description: Migre de las configuraciones heredadas No Data a las opciones On Missing + Data para un mejor manejo de datos faltantes en metric monitors. further_reading: - link: /api/latest/monitors/ tag: API - text: Documentación de la API de monitores -title: Migración a la configuración de On Missing Data + text: Documentación de la API de monitors. +title: Migración a la configuración On Missing Data --- +## Descripción general {#overview} -## Información general +Los metric monitors ofrecen opciones mejoradas para el manejo de datos faltantes, lo que le permite diferenciar entre los datos faltantes como un modo de falla y un estado saludable. -Los monitores de métricas ofrecen opciones mejoradas para gestionar los datos faltantes, lo que permite diferenciar entre los datos faltantes como un modo de fallo y un buen estado de mantenimiento. +Estas opciones se alinean con lo que está disponible en otros tipos de monitors como Logs, Events, CI, Database, Error Tracking y más. -Estas opciones coinciden con lo que está disponible en otros tipos de monitores como logs, eventos, CI, base de datos, rastreo de errores y más. +## Beneficios de usar las opciones On Missing Data {#benefits-of-using-on-missing-data-options} -## Ventajas de utilizar las opciones de On Missing Data +Al medir la cantidad de eventos incorrectos, como errores, los monitors deben reflejar un estado "OK" cuando no se detectan datos. Con las configuraciones heredadas No Data, los monitors informaban No Data. Las opciones de configuración On Missing Data permiten que los monitors reflejen los estados de salud con mayor precisión, mejorando la claridad. -Cuando se mide el número de eventos incorrectos, como errores, los monitores deben reflejar un "OK" cuando no se detectan datos. Con las configuraciones legacy No Data, los monitores informarían No Data. Las opciones de configuración de On Missing Data permiten a los monitores reflejar los estados de mantenimiento con mayor precisión y mejora así la claridad. +## Monitors gestionados a través de la interfaz de usuario {#monitors-managed-through-the-ui} -## Monitores gestionados a través de la interfaz de usuario +Si gestiona sus monitors desde la interfaz de usuario, la configuración se actualiza automáticamente la próxima vez que los edite. Para actualizar la configuración On Missing Data antes, consulte las siguientes secciones sobre cómo realizar ajustes a través de la API. -Si gestionas tus monitores desde la interfaz de usuario, la configuración se actualizará automáticamente la próxima vez que los edites. Para actualizar antes la configuración de On Missing Data, consulta las siguientes secciones sobre ajustes a través de la API. +## Monitors gestionados a través de la API o Terraform {#monitors-managed-through-the-api-or-terraform} -## Monitores gestionados a través de la API o Terraform +Si gestiona sus monitors con la API o Terraform, reemplace `notify_no_data` y `no_data_timeframe` con `on_missing_data`. El parámetro `no_data_timeframe` no es necesario ya que `on_missing_data` utiliza el mismo marco de tiempo que la ventana de tiempo. -Si gestionas tus monitores con la API o Terraform, sustituye `notify_no_data` y `no_data_timeframe` con `on_missing_data`. El parámetro `no_data_timeframe` no es necesario, ya que `on_missing_data` utiliza el mismo período de tiempo que la ventana de tiempo. +### Parámetros de la API {#api-parameters} -### Parámetros de la API +El parámetro anterior No Data, `notify_no_data`, sigue estando disponible en los monitors existentes y no se actualiza automáticamente a las nuevas funciones `on_missing_data`. -El parámetro anterior No Data, `notify_no_data`, sigue estando disponible en los monitores existentes y no se actualizan automáticamente a las nuevas funciones de `on_missing_data`. - -| Parámetro | Descripción de la interfaz de usuario | +| Parámetro | Descripción en la interfaz de usuario | |-----------------------------------------|----------------------------------------------------------------------------------------------------| -| `"on_missing_data": "show_and_notify_no_data"` | Si faltan datos Mostrar NO DATA y notificar a
(Anteriormente, "Notificar si faltan datos") | -| `"on_missing_data": "show_no_data"` | Si faltan datos Mostrar NO DATA
(Anteriormente, "No notificar si faltan datos") | -| `"on_missing_data": "resolve"` | Si faltan datos Mostrar OK | -| `"on_missing_data": "default"` si se utiliza la agregación por suma o por cuenta | Si faltan datos Evaluar como 0 (u otro valor predeterminado) | -| `"on_missing_data": "default"` si se utilizan todos los demás tipos de agregación | Si faltan datos Mostrar el último estado conocido | +| `"on_missing_data": "show_and_notify_no_data"` | Si faltan datos {{< ui >}}Show NO DATA and notify{{< /ui >}}
(Anteriormente, "{{< ui >}}Notify if data is missing{{< /ui >}}") | +| `"on_missing_data": "show_no_data"` | Si faltan datos {{< ui >}}Show NO DATA{{< /ui >}}
(Anteriormente, "{{< ui >}}Do not notify if data is missing{{< /ui >}}") | +| `"on_missing_data": "resolve"` | Si faltan datos {{< ui >}}Show OK{{< /ui >}} | +| `"on_missing_data": "default"` si se utiliza la agregación de suma o recuento | Si faltan datos {{< ui >}}Evaluate as 0{{< /ui >}} (u otro valor predeterminado) | +| `"on_missing_data": "default"` si se utilizan todos los demás tipos de agregación | Si faltan datos {{< ui >}}Show last known status{{< /ui >}} | -Para conocer todos los campos disponibles, consulta la [Documentación de la API][1]. +Para ver todos los campos disponibles, consulte la [Documentación de la API][1]. -He aquí un ejemplo del antes y el después de un monitor de JSON con esos campos: +Aquí hay un ejemplo de antes y después de un JSON monitor con esos campos: **Antes** {{< highlight yaml "hl_lines=11-12" >}}{ @@ -76,19 +75,19 @@ He aquí un ejemplo del antes y el después de un monitor de JSON con esos campo } {{< /highlight >}} -## Monitores de SLO +## SLO basados en monitors {#monitor-based-slos} -Los SLOs tratan el tiempo de actividad y caída del sistema de acuerdo con esta asignación: +Los SLO tratan el uptime y el tiempo de inactividad de acuerdo con este mapeo: -| Configuración de On Missing Data | Estado del monitor | Tratamiento de SLO | +| On Missing Data Configuration | Monitor Status | SLO Treatment | |-------------------------------|--------------------------------|-----------------------------| -| Mostrar OK | OK | Tiempo de actividad | -| Mostrar No Data | Sin datos | Tiempo de actividad | -| Mostrar No Data y notificar | Sin datos | Caída del sistema | -| Mostrar el último estado conocido | Sea cual fuere el último estado | Si es OK, tiempo de actividad
si es alerta, caída del sistema | -| Evaluar como cero | Depende de la configuración del umbral | Si es OK, tiempo de actividad
si es alerta, caída del sistema | +| {{< ui >}}Show OK{{< /ui >}} | OK | Uptime | +| {{< ui >}}Show No Data{{< /ui >}} | No Data | Uptime | +| {{< ui >}}Show No Data and Notify{{< /ui >}} | No Data | Downtime | +| {{< ui >}}Show last known status{{< /ui >}} | Cualquiera que haya sido el último estado | If OK, Uptime
If Alert, Downtime | +| {{< ui >}}Evaluate as zero{{< /ui >}} | Depende de la configuración del umbral | If OK, Uptime
If Alert, Downtime | -## Referencias adicionales +## Lecturas adicionales {#further-reading} {{< partial name="whats-next/whats-next.html" >}} diff --git a/hugo/content/es/network_monitoring/netflow/_index.md b/hugo/content/es/network_monitoring/netflow/_index.md index 7a8bbaedf37..07f9e8866fc 100644 --- a/hugo/content/es/network_monitoring/netflow/_index.md +++ b/hugo/content/es/network_monitoring/netflow/_index.md @@ -5,45 +5,48 @@ further_reading: - link: /network_monitoring/devices/profiles tag: Documentación text: Uso de perfiles con Network Device Monitoring +- link: /network_monitoring/network_path/setup/#dynamic-tests-for-netflow-experimental + tag: Documentación + text: Configuración de pruebas dinámicas para NetFlow - link: https://www.datadoghq.com/blog/monitor-netflow-with-datadog/ tag: Blog - text: Monitorear datos de tráfico NetFlow con Datadog + text: Monitoree los datos de tráfico de NetFlow con Datadog - link: https://www.datadoghq.com/blog/diagnose-network-performance-with-snmp-trap-monitoring/ tag: Blog - text: Monitorear y diagnosticar problemas de rendimiento de red con SNMP Traps + text: Monitoree y diagnostique problemas de rendimiento de la red con capturas SNMP title: NetFlow Monitoring --- -## Resumen {#overview} +## Descripción general {#overview} -La vista de NetFlow en Network Device Monitoring proporciona visibilidad sobre los flujos de tráfico de red recopilados de dispositivos que exportan datos de flujo (por ejemplo, enrutadores, cortafuegos o conmutadores). Puede analizar el volumen de tráfico, identificar los principales emisores y comprender cómo se mueve la información a través de su red. +La vista de NetFlow en Network Device Monitoring proporciona visibilidad de los flujos de tráfico de red recopilados de dispositivos que exportan datos de flujo (por ejemplo, enrutadores, firewalls o interruptores). Puede analizar el volumen de tráfico, identificar a los principales emisores y comprender cómo se mueven los datos a través de su red. -La vista de NetFlow muestra métricas de tráfico agregadas por dispositivo e interfaz. Úselo para identificar qué dispositivos o interfaces están consumiendo más ancho de banda, generando más paquetes o contribuyendo a picos de tráfico. +La vista de NetFlow muestra métricas de tráfico agregadas por dispositivo e interfaz. Úsela para identificar qué dispositivos o interfaces están consumiendo la mayor cantidad de ancho de banda, generando la mayor cantidad de paquetes o contribuyendo a los picos de tráfico. -{{< img src="network_device_monitoring/netflow/netflow.png" alt="La página NetFlow Monitoring contiene una leyenda colapsable para el volumen de tráfico, la salud del dispositivo, flujos y más." style="width:100%;" >}} +{{< img src="network_device_monitoring/netflow/netflow.png" alt="La página de NetFlow Monitoring que contiene una leyenda plegable para el volumen de tráfico, el estado del dispositivo, los flujos y más." style="width:100%;" >}} ## Navegación lateral {#side-navigation} Utilice la navegación de la izquierda para explorar vistas adicionales de NetFlow: -- **Volumen de tráfico**: Métricas de flujo generales por dispositivo e interfaz. -- **Salud del dispositivo**: Estado y utilización de los dispositivos monitoreados. -- **Flujos**: Registros de flujo individuales detallados. -- **Conversaciones**: Pares de origen-destino agregados. -- **Sistemas autónomos**: Datos de flujo agrupados por Números de Sistemas Autónomos (ASNs). -- **Geo IP**: Datos de flujo agrupados por origen/destino geográfico. -- **Puertos de origen / Puertos de destino / Protocolos / Banderas**: Desglose del tráfico por metadatos de paquetes. +- {{< ui >}}Traffic Volume{{< /ui >}}: Métricas generales de flujo por dispositivo e interfaz. +- {{< ui >}}Device Health{{< /ui >}}: Estado y utilización de los dispositivos monitoreados. +- {{< ui >}}Flows{{< /ui >}}: Registros detallados de flujos individuales. +- {{< ui >}}Conversations{{< /ui >}}: Pares de fuente-destino agregados. +- {{< ui >}}Autonomous Systems{{< /ui >}}: Datos de flujo agrupados por números de sistema autónomo (ASN). +- {{< ui >}}Geo IP{{< /ui >}}: Datos de flujo agrupados por fuente/destino geográfico. +- {{< ui >}}Source Ports / Destination Ports / Protocols / Flags{{< /ui >}}: Desglose del tráfico por metadatos de paquetes. ## Instalación {#installation} -Para utilizar NetFlow Monitoring con Network Device Monitoring, asegúrese de estar utilizando la versión 7.45 o más reciente del [Agent][1]. +Para usar NetFlow Monitoring con Network Device Monitoring, asegúrese de usar la versión 7.45 o más reciente del [Agent][1]. -**Nota:** Configurar [la recolección de métricas de Network Device Monitoring][2] no es un requisito para enviar datos de NetFlow, aunque se recomienda encarecidamente, ya que estos datos adicionales pueden utilizarse para enriquecer sus registros de flujo con información como el nombre del dispositivo, modelo y proveedor, así como el nombre de la interfaz de entrada/salida. +**Nota:** Configurar [la recopilación de métricas de Network Device Monitoring][2] no es un requisito para enviar datos de NetFlow, aunque se recomienda encarecidamente, ya que estos datos adicionales pueden utilizarse para enriquecer sus registros de flujo con información como el nombre, el modelo y el proveedor del dispositivo, así como el nombre de la interfaz de entrada/salida. ## Configuración {#configuration} -Para configurar sus dispositivos para enviar tráfico de NetFlow, jFlow, sFlow o IPFIX al servidor NetFlow del Agent, sus dispositivos deben estar configurados para enviar tráfico a la dirección IP en la que está instalado el Datadog Agent, específicamente a `flow_type` y `port`. +Para configurar sus dispositivos para enviar tráfico NetFlow, jFlow, sFlow o IPFIX al servidor NetFlow del Agent, sus dispositivos deben estar configurados para enviar tráfico a la dirección IP en la que está instalado el Datadog Agent, específicamente el `flow_type` y el `port`. -1. Edite su archivo de configuración del [`datadog.yaml`][3] Agent para habilitar NetFlow: +1. Edite su archivo de configuración del Agent [`datadog.yaml`][3] para habilitar NetFlow: ```yaml network_devices: @@ -68,76 +71,82 @@ network_devices: ## Agregación {#aggregation} -El Datadog Agent agrega automáticamente los datos recibidos en NetFlow para limitar el número de registros enviados a la plataforma mientras mantiene la mayor parte de la información. Por defecto, las grabaciones de flujo que tienen los mismos identificadores, como `source`, `destination address`, `port` y `protocol`, se agregan juntas en intervalos de cinco minutos. Además, el Datadog Agent puede detectar puertos efímeros y eliminarlos. Como resultado, puede ver Flujos con `port:*`. +El Datadog Agent agrega automáticamente los datos recibidos en NetFlow para limitar la cantidad de registros enviados a la plataforma mientras mantiene la mayor parte de la información. De forma predeterminada, los flujos que tienen los mismos identificadores, como `source`, `destination address`, `port` y `protocol`, se agregan juntos en intervalos de cinco minutos. Además, el Datadog Agent puede detectar puertos efímeros y eliminarlos. Como resultado, es posible que vea flujos con `port:*`. ## Enriquecimiento {#enrichment} -Sus datos de NetFlow son procesados por el backend de Datadog y enriquecidos con los metadatos disponibles de sus dispositivos e interfaces. El enriquecimiento se basa en la IP del exportador de NetFlow y los índices de interfaz. Para desambiguar posibles colisiones entre IPs privadas reutilizadas, puede configurar un `namespace` diferente para cada archivo de configuración del Agent (con la configuración `network_devices.namespace`). +Sus datos de NetFlow son procesados por el backend de Datadog y enriquecidos con los metadatos disponibles de sus dispositivos e interfaces. El enriquecimiento se basa en la IP del exportador de NetFlow y los índices de las interfaces. Para eliminar posibles ambigüedades entre colisiones de IPs privadas reutilizadas, puede configurar un `namespace` diferente para cada archivo de configuración del Agent (con el ajuste `network_devices.namespace`). -Si la IP del exportador de NetFlow es una de las IPs del dispositivo, pero no la que está configurada en la integración SNMP, Datadog intenta localizar el dispositivo al que pertenece la IP del exportador y enriquece sus datos de NetFlow con ella siempre que la coincidencia sea única. +Si la IP del exportador de NetFlow es una de las IPs del dispositivo, pero no la configurada en la integración de SNMP, Datadog intenta localizar el dispositivo al que pertenece la IP del exportador y enriquece sus datos de NetFlow con él, siempre y cuando la coincidencia sea única. -### Enriquecimiento de IP del proveedor de la nube {#cloud-provider-ip-enrichment} +### Enriquecimiento de IP de proveedor de nube {#cloud-provider-ip-enrichment} -Datadog enriquece las IPs con el servicio y la región del proveedor de nube pública para direcciones IPv4, de modo que pueda filtrar los registros de flujo de un servicio y región específicos. +Datadog enriquece las IPs con el servicio y la región del proveedor de nube pública para direcciones IPv4, de modo que pueda filtrar los registros de flujo de un servicio y una región específicos. {{< img src="network_device_monitoring/netflow/netflow_cloud_provider_enrichment_2.png" alt="Menú de filtro de NetFlow que muestra el nombre del proveedor de nube, la región y el servicio" width="100%" >}} ### Enriquecimiento de puertos {#port-enrichment} -Datadog enriquece los puertos en NetFlow con datos de IANA (Autoridad de Números Asignados de Internet) para resolver asignaciones de puertos bien conocidos (como Postgres en 5432 y HTTPS en 443). +Datadog enriquece los puertos en NetFlow con datos de IANA (Internet Assigned Numbers Authority) para resolver asignaciones de puertos conocidos (como Postgres en 5432 y HTTPS en 443). -### Enriquecimiento de puerto personalizado {#custom-port-enrichment} +### Enriquecimiento de puertos personalizados {#custom-port-enrichment} -También puede agregar sus propios enriquecimientos personalizados para mapear puertos y protocolos a aplicaciones específicas (por ejemplo, si un servicio personalizado se ejecuta en un puerto específico). Esto facilita a los ingenieros de red y sus equipos interpretar y consultar los datos de NetFlow con nombres legibles para humanos. +También puede agregar sus propios enriquecimientos personalizados para asignar puertos y protocolos a aplicaciones específicas (por ejemplo, si un servicio personalizado se ejecuta en un puerto específico). Esto facilita que los ingenieros de red y sus equipos interpreten y consulten los datos de NetFlow con nombres legibles por humanos. -Desde la pestaña **Configuración** en NetFlow, haga clic en **+ Agregar Enriquecimiento** para subir el archivo CSV que contiene sus enriquecimientos personalizados. +Desde la pestaña {{< ui >}}Configuration{{< /ui >}} en NetFlow, haga clic en {{< ui >}}+ Add Enrichment{{< /ui >}} para cargar el archivo CSV que contiene sus enriquecimientos personalizados. -{{< img src="network_device_monitoring/netflow/new_enrichment_2.png" alt="El modal de Mapeo de Nuevos Enriquecimientos en la pestaña de configuración de NetFlow" width="100%" >}} +{{< img src="network_device_monitoring/netflow/new_enrichment_2.png" alt="El modal de Nueva asignación de enriquecimiento en la pestaña de configuración de NetFlow" width="100%" >}} ### Enriquecimiento de IP personalizado {#custom-ip-enrichment} -También puede agregar sus propios enriquecimientos personalizados para mapear IPs y CIDRs a etiquetas personalizadas (por ejemplo, para categorizar servicios que se ejecutan en direcciones IP específicas). Esto facilita a los ingenieros de red y sus equipos interpretar y consultar los datos de NetFlow con nombres legibles para humanos. +También puede agregar sus propios enriquecimientos personalizados para asignar IP y CIDR a etiquetas personalizadas (por ejemplo, para categorizar servicios que se ejecutan en direcciones IP específicas). Esto facilita que los ingenieros de red y sus equipos interpreten y consulten los datos de NetFlow con nombres legibles por humanos. -Desde la página de configuración de [**Enriquecimiento**][10], haga clic en **+ Agregar Enriquecimiento** para agregar mapeos manualmente o subir un archivo CSV para agregar mapeos en bloque. +Desde la [{{< ui >}}Enrichment{{< /ui >}} página de configuración][10], haga clic en {{< ui >}}+ Add Enrichment{{< /ui >}} para agregar asignaciones manualmente o cargar un archivo CSV para agregar asignaciones de forma masiva. ### Enriquecimiento de IP privada de DNS inverso {#reverse-dns-private-ip-enrichment} -Habilite el enriquecimiento de IP privada de DNS inverso para realizar búsquedas DNS de nombres de host asociados con direcciones IP de origen o destino. Cuando está habilitado, el Datadog Agent realiza búsquedas DNS inversas en las IPs de origen y destino dentro de rangos de direcciones privadas, enriqueciendo los registros de NetFlow con los nombres de host correspondientes. +Habilite el enriquecimiento de IP privada de DNS inverso para realizar búsquedas de DNS de nombres de host asociados con direcciones IP de fuente o destino. Cuando está habilitado, el Agent realiza búsquedas de DNS inverso en las IP de fuente y destino dentro de rangos de direcciones privadas, enriqueciendo los registros de NetFlow con los nombres de host correspondientes. -Por [defecto][7], el enriquecimiento de IP de DNS inverso en su archivo `datadog.yaml` está deshabilitado. Para habilitar, consulte la sección [Configuración](#configuration) de esta página. +De forma predeterminada, el enriquecimiento de IP de DNS inverso en su [`datadog.yaml` archivo][7] está deshabilitado. Para habilitarlo, consulte la sección [Configuración](#configuration) de esta página. -Busque **DNS** en el menú **+ Filtro** para localizar flujos asociados con el enriquecimiento de IP de DNS inverso: +Busque DNS en el menú {{< ui >}}+ Filter{{< /ui >}} para localizar flujos asociados con el enriquecimiento de IP de DNS inverso: -{{< img src="network_device_monitoring/netflow/dns_ip_enrichmen_2.png" alt="Menú de filtro mejorado para mostrar las facetas de destino y origen de DNS inverso" width="100%" >}} +{{< img src="network_device_monitoring/netflow/dns_ip_enrichmen_2.png" alt="Menú de filtro mejorado para mostrar las facetas de destino y fuente de DNS inverso" width="100%" >}} -**Nota**: Las entradas de DNS inverso se almacenan en caché y están sujetas a limitaciones de tasa para minimizar las consultas DNS y reducir la carga en los servidores DNS. Para más opciones de configuración, incluyendo la modificación de la caché predeterminada y la limitación de tasa, consulte el [archivo de configuración completo][8]. +**Nota**: Las entradas de DNS inverso se almacenan en caché y están sujetas a limitación de velocidad para minimizar las consultas de DNS y reducir la carga en los servidores DNS. Para obtener más opciones de configuración, incluida la modificación del almacenamiento en caché predeterminado y la limitación de velocidad, consulte la sección `reverse_dns_enrichment` del [archivo de configuración de ejemplo del Agent][7]. ## Detalles de IP {#ip-details} -En la vista de **Conversaciones**, puede ver la dirección IP pública de la IP de destino. Pase el cursor sobre la IP para mostrar metadatos enriquecidos sobre la IP y un enlace a **Ver Conexiones de Red Relacionadas** donde puede inspeccionar la conectividad con más detalle. +En la vista **Conversaciones**, puede ver la dirección IP pública de la IP de destino. Pase el cursor sobre la IP para mostrar metadatos enriquecidos sobre la IP y un enlace a {{< ui >}}View Related Network Connections{{< /ui >}} donde puede inspeccionar la conectividad con más detalle. -{{< img src="network_device_monitoring/netflow/NetFlow_IP_pill.png" alt="Pase el cursor sobre una dirección IP para mostrar los detalles de la IP y Ver Conexiones de Red Relacionadas" width="100%" >}} +{{< img src="network_device_monitoring/netflow/NetFlow_IP_pill.png" alt="Pase el cursor sobre una dirección IP para mostrar los detalles de la IP y visualizar conexiones de red relacionadas." width="100%" >}} ## Diagrama de flujo {#flow-diagram} -Puede visualizar los flujos en NetFlow Monitoring haciendo clic en el menú **Flujos** y pasando el cursor sobre un flujo de la lista para ver información adicional sobre la IP de origen, el nombre de la interfaz de entrada, el nombre del dispositivo y la IP de destino a través de conexiones de red relacionadas. +Puede visualizar los flujos en NetFlow Monitoring haciendo clic en el menú {{< ui >}}Flows{{< /ui >}} y pasando el cursor sobre un flujo de la lista para ver información adicional sobre la IP de fuente, el nombre de la interfaz de entrada, el nombre del dispositivo y la IP de destino en las conexiones de red relacionadas. + +{{< img src="network_device_monitoring/netflow/flows.png" alt="Pase el cursor sobre un flujo agregado desde un dispositivo que emite NetFlow para acceder a las conexiones de red relacionadas" width="100%" >}} + +## Network Path para NetFlow {#network-path-for-netflow} -{{< img src="network_device_monitoring/netflow/flows.png" alt="Pase el cursor sobre un flujo agregado de un dispositivo que emite NetFlow para acceder a conexiones de red relacionadas." width="100%" >}} +Las pruebas dinámicas para NetFlow pueden ejecutar automáticamente pruebas de Network Path desde el Agent que recopila el tráfico de NetFlow hacia las IP de destino observadas en los registros de NetFlow. Utilice las pruebas dinámicas para NetFlow para agregar contexto de Network Path salto a salto y latencia a sus destinos de NetFlow. -## Monitor de NetFlow {#netflow-monitor} +Las pruebas dinámicas para NetFlow son experimentales y requieren Agent `v7.81+`. Para configurar las pruebas dinámicas para NetFlow, consulte [Network Path setup][11]. -Haga clic en el ícono **Crear Monitor** desde cualquiera de las vistas para crear un [NetFlow monitor][6]. Al crear el monitor, considere los siguientes campos con respecto a la IP de origen o la IP de destino desde la perspectiva del dispositivo. Estos campos proporcionan información sobre los patrones de tráfico de red y ayudan a optimizar el rendimiento y la seguridad. +## NetFlow Monitor {#netflow-monitor} -{{< img src="network_device_monitoring/netflow/create_monitor.png" alt="Vista de flujos en NetFlow Monitoring con el enlace para crear un NetFlow monitor resaltado." width="100%" >}} +Haga clic en el icono {{< ui >}}Create Monitor{{< /ui >}} desde cualquiera de las vistas para crear un [NetFlow Monitor][6]. Al crear el monitor, considere los siguientes campos con respecto a la IP de fuente o la IP de destino desde la perspectiva del dispositivo. Estos campos proporcionan información sobre los patrones de tráfico de red y ayudan a optimizar el rendimiento y la seguridad. -### Información de interfaz {#interface-information} +{{< img src="network_device_monitoring/netflow/create_monitor.png" alt="Vista de flujos en NetFlow Monitoring con el enlace para crear NetFlow Monitor resaltado." width="100%" >}} + +### Información de la interfaz {#interface-information} Los siguientes campos representan detalles sobre las interfaces de entrada y salida. -| Nombre del Campo | Descripción del Campo | +| Nombre del campo | Descripción del campo | |---|---| -| Alias de la Interfaz de Salida | Alias de la interfaz de salida. | -| Índice de la Interfaz de Salida | Índice de la interfaz de salida. | +| Alias de la interfaz de salida | Alias de la interfaz de salida. | +| Índice de la interfaz de salida | Índice de la interfaz de salida. | | Nombre de la interfaz de salida | Nombre de la interfaz de salida. | | Alias de la interfaz de entrada | Alias de la interfaz de entrada. | | Índice de la interfaz de entrada | Índice de la interfaz de entrada. | @@ -145,11 +154,11 @@ Los siguientes campos representan detalles sobre las interfaces de entrada y sal ### Información del dispositivo {#device-information} -Los siguientes campos representan detalles relacionados con el dispositivo que genera registros de NetFlow. +Los siguientes campos representan detalles relacionados con el dispositivo que genera los registros de NetFlow. | Nombre del campo | Descripción del campo | |---|---| -| IP del dispositivo | Dirección IP utilizada para mapear a un dispositivo en NDM con fines de enriquecimiento. | +| IP del dispositivo | Dirección IP utilizada para asignar a un dispositivo en NDM con fines de enriquecimiento. | | IP del exportador | Dirección IP desde la cual se originan los paquetes de NetFlow. | | Modelo del dispositivo | Modelo del dispositivo. | | Nombre del dispositivo | Nombre del dispositivo. | @@ -158,117 +167,117 @@ Los siguientes campos representan detalles relacionados con el dispositivo que g ### Detalles del flujo {#flow-details} -Los siguientes campos representan características del flujo de red. +Los siguientes campos representan las características del flujo de red. | Nombre del campo | Descripción del campo | |---|---| | Dirección | Indica si el flujo es entrante o saliente. | -| Hora de Inicio | Marca de tiempo del primer paquete de red entre las direcciones IP de origen y destino. | -| Hora de Fin | Marca de tiempo del último paquete de red entre las direcciones IP de origen y destino. | -| Tipo de Éter | Tipo de encapsulación de tramas Ethernet (IPv4 o IPv6). | -| Tipo de Flujo | Tipo de formato de datos de NetFlow (IPFIX, sFlow5, NetFlow5, NetFlow9 o Desconocido). | +| Hora de inicio | Marca de tiempo del primer paquete de red entre las direcciones IP de fuente y destino. | +| Hora de finalización | Marca de tiempo del último paquete de red entre las direcciones IP de fuente y destino. | +| Tipo de Ethernet | Tipo de encapsulación de trama Ethernet (IPv4 o IPv6). | +| Tipo de flujo | Tipo de formato de datos de NetFlow (IPFIX, sFlow5, NetFlow5, NetFlow9 o Desconocido). | | Protocolo IP | Protocolo utilizado para la comunicación (como ICMP, TCP o UDP). | -| IP del siguiente salto | Dirección IP del siguiente salto en la ruta de la red. | -| Bandera TCP | Unión de todas las banderas TCP observadas durante la vida del flujo. | +| IP del siguiente salto | Dirección IP del siguiente salto en la ruta de red. | +| Indicador TCP | Unión de todos los indicadores TCP observados durante la vida del flujo. | | Bytes | Número total de bytes transferidos. | | Paquetes | Número total de paquetes transferidos. | -Además de los campos, también puede utilizar facetas listas para usar para comenzar a analizar patrones de tráfico basados en las direcciones IP de destino y origen de NetFlow. +Además de los campos, también puede utilizar facetas listas para usar para comenzar a analizar los patrones de tráfico basados en las direcciones IP de destino y fuente de NetFlow. -### Facetas de IP de destino de NetFlow {#netflow-destination-ip-facets} +### Faceta de IP de destino de NetFlow {#netflow-destination-ip-facets} | Nombre de la faceta | Descripción de la faceta | |---|---| -| Dominio AS de destino | El dominio asociado con el Sistema Autónomo (AS) al que pertenece la IP de destino. | -| Nombre AS de destino | El nombre del Sistema Autónomo (AS) al que pertenece la IP de destino. | -| Número AS de destino | El número asignado al Sistema Autónomo (AS) al que pertenece la IP de destino. | -| Ruta AS de destino | La información de ruta asociada con el Sistema Autónomo (AS) al que pertenece la IP de destino. | +| Dominio de AS de destino | El dominio asociado con el Sistema Autónomo (AS) al que pertenece la IP de destino. | +| Nombre de AS de destino | El nombre del Sistema Autónomo (AS) al que pertenece la IP de destino. | +| Número de AS de destino | El número asignado al Sistema Autónomo (AS) al que pertenece la IP de destino. | +| Ruta de AS de destino | La información de ruta asociada con el Sistema Autónomo (AS) al que pertenece la IP de destino. | | Tipo de AS de destino | El tipo de Sistema Autónomo (AS) al que pertenece la IP de destino (como tránsito, cliente, par). | -| Nombre de la Aplicación de Destino | El nombre de la aplicación asociada con la IP de destino. | -| Nombre de la Ciudad de Destino | El nombre de la ciudad asociada con la IP de destino. | -| Nombre del Proveedor de Nube de Destino | El nombre del proveedor de nube asociado con la IP de destino. | -| Región del Proveedor de Nube de Destino | La región del proveedor de nube asociada con la IP de destino. | -| Servicio del Proveedor de Nube de Destino | El servicio proporcionado por el proveedor de nube asociado con la IP de destino. | -| Código del Continente de Destino | El código que representa el continente asociado con la IP de destino. | -| Nombre del Continente de Destino | El nombre del continente asociado con la IP de destino. | -| Código ISO del País de Destino | El código ISO que representa el país asociado con la IP de destino. | -| Nombre del País de Destino | El nombre del país asociado con la IP de destino. | -| Dirección IP de destino | La dirección IP de destino. | -| Latitud de destino | La coordenada de latitud asociada con la dirección IP de destino. | -| Longitud de destino | La coordenada de longitud asociada con la dirección IP de destino. | -| MAC de destino | La dirección de Control de Acceso de Medios (MAC) asociada con la dirección IP de destino. | -| Máscara de destino | La máscara de subred asociada con la dirección IP de destino. | +| Nombre de la aplicación de destino | El nombre de la aplicación asociada con la IP de destino. | +| Nombre de la ciudad de destino | El nombre de la ciudad asociada con la IP de destino. | +| Nombre del proveedor de nube de destino | El nombre del proveedor de nube asociado con la IP de destino. | +| Región del proveedor de nube de destino | La región del proveedor de nube asociada con la IP de destino. | +| Servicio del proveedor de nube de destino | El servicio proporcionado por el proveedor de nube asociado con la IP de destino. | +| Código de continente de destino | El código que representa el continente asociado con la IP de destino. | +| Nombre del continente de destino | El nombre del continente asociado con la IP de destino. | +| Código ISO del país de destino | El código ISO que representa el país asociado con la IP de destino. | +| Nombre del país de destino | El nombre del país asociado con la IP de destino. | +| IP de destino | La dirección IP de destino. | +| Latitud de destino | La coordenada de latitud asociada con la IP de destino. | +| Longitud de destino | La coordenada de longitud asociada con la IP de destino. | +| MAC de destino | La dirección de Access Control al Medio (MAC) asociada con la IP de destino. | +| Máscara de destino | La máscara de subred asociada con la IP de destino. | | Puerto de destino | El número de puerto de destino. | -| Nombre de host DNS inverso de destino | El nombre de host DNS asociado con la dirección IP de destino. | -| Código ISO de subdivisión de destino | El código ISO que representa la subdivisión (como estado o provincia) asociada con la dirección IP de destino. | -| Nombre de subdivisión de destino | El nombre de la subdivisión (como estado o provincia) asociada con la dirección IP de destino. | -| Zona horaria de destino | La zona horaria asociada con la dirección IP de destino. | +| Nombre de host DNS inverso de destino | El nombre de host DNS asociado con la IP de destino. | +| Código ISO de la subdivisión de destino | El código ISO que representa la subdivisión (como estado o provincia) asociada con la IP de destino. | +| Nombre de la subdivisión de destino | El nombre de la subdivisión (como estado o provincia) asociada con la IP de destino. | +| Zona horaria de destino | La zona horaria asociada con la IP de destino. | -### Facetas de IP de origen de NetFlow {#netflow-source-ip-facets} +### Faceta de fuente de NetFlow {#netflow-source-ip-facets} | Nombre de la faceta | Descripción de la faceta | |---|---| -| Dominio AS de origen | El dominio asociado con el Sistema Autónomo (AS) al que pertenece la IP de origen. | -| Nombre AS de origen | El nombre del Sistema Autónomo (AS) al que pertenece la IP de origen. | -| Número AS de origen | El número asignado al Sistema Autónomo (AS) al que pertenece la IP de origen. | -| Ruta AS de origen | La información de ruta asociada con el Sistema Autónomo (AS) al que pertenece la IP de origen. | -| Tipo AS de origen | El tipo de Sistema Autónomo (AS) al que pertenece la IP de origen (como tránsito, cliente, par). | -| Nombre de la aplicación de origen | El nombre de la aplicación asociada con la IP de origen. | -| Nombre de la ciudad de origen | El nombre de la ciudad asociada con la IP de origen. | -| Nombre del proveedor de nube de origen | El nombre del proveedor de nube asociado con la IP de origen. | -| Región del proveedor de nube de origen | La región del proveedor de nube asociada con la IP de origen. | -| Servicio del proveedor de nube de origen | El servicio proporcionado por el proveedor de nube asociado con la IP de origen. | -| Código de continente de origen | El código que representa el continente asociado con la IP de origen. | -| Nombre del continente de origen | El nombre del continente asociado con la IP de origen. | -| Código ISO del país de origen | El código ISO que representa el país asociado con la IP de origen. | -| Nombre del país de origen | El nombre del país asociado con la IP de origen. | -| IP de origen | La dirección IP de origen. | -| Latitud de origen | La coordenada de latitud asociada con la IP de origen. | -| Longitud de origen | La coordenada de longitud asociada con la IP de origen. | -| MAC de origen | La dirección de Control de Acceso de Medios (MAC) asociada con la IP de origen. | -| Máscara de origen | La máscara de subred asociada con la IP de origen. | -| Puerto de origen | El número de puerto de origen. | -| Nombre de host DNS inverso de origen | El nombre de host DNS asociado con la IP de origen. | -| Código ISO de subdivisión de origen | El código ISO que representa la subdivisión (como estado o provincia) asociada con la IP de origen. | -| Nombre de subdivisión de origen | El nombre de la subdivisión (como estado o provincia) asociada con la IP de origen. | -| Zona horaria de origen | La zona horaria asociada con la IP de origen. | - -## Unificación de conversaciones {#conversation-stitching} - -Por defecto, NetFlow registra flujos unidireccionales separados para cada dirección de tráfico entre dos puntos de conexión (A → B y B → A). La unificación de conversaciones combina estos en un solo registro bidireccional, brindando una vista completa del tráfico total intercambiado entre dos puntos de conexión (A ↔ B). - -Con la unificación de conversaciones, puede: +| Dominio del AS de fuente | El dominio asociado con el Sistema Autónomo (AS) al que pertenece la IP de origen. | +| Nombre del AS de fuente | El nombre del Sistema Autónomo (AS) al que pertenece la IP de fuente. | +| Número del AS de fuente | El número asignado al Sistema Autónomo (AS) al que pertenece la IP de origen. | +| Ruta del AS de fuente | La información de ruta asociada con el Sistema Autónomo (AS) al que pertenece la IP de fuente. | +| Tipo de AS de fuente | El tipo de Sistema Autónomo (AS) al que pertenece la IP de origen (como tránsito, cliente, par). | +| Nombre de la aplicación de fuente | El nombre de la aplicación asociada con la IP de origen. | +| Nombre de la ciudad de fuente | El nombre de la ciudad asociada con la IP de origen. | +| Nombre del proveedor de nube de fuente | El nombre del proveedor de nube asociado con la IP de origen. | +| Región del proveedor de nube de fuente | La región del proveedor de nube asociada con la IP de origen. | +| Servicio del proveedor de nube de fuente | El servicio proporcionado por el proveedor de nube asociado con la IP de origen. | +| Código de continente de fuente | El código que representa el continente asociado con la IP de origen. | +| Nombre de continente de fuente | El nombre del continente asociado con la IP de origen. | +| Código ISO de país de fuente | El código ISO que representa el país asociado con la IP de origen. | +| Nombre de país de fuente | El nombre del país asociado con la IP de origen. | +| IP de fuente | La dirección IP de fuente. | +| Latitud de fuente | La coordenada de latitud asociada con la IP de fuente. | +| Longitud de fuente | La coordenada de longitud asociada con la IP de fuente. | +| MAC de fuente | La dirección de Control de Acceso al Medio (MAC) asociada con la IP de fuente. | +| Máscara de fuente | La máscara de subred asociada con la IP de fuente. | +| Puerto de fuente | El número de puerto de fuente. | +| Nombre de host DNS inverso de fuente | El nombre de host DNS asociado con la IP de fuente. | +| Código ISO de subdivisión de fuente | El código ISO que representa la subdivisión (como estado o provincia) asociada con la IP de fuente. | +| Nombre de subdivisión de fuente | El nombre de la subdivisión (como estado o provincia) asociada con la IP de fuente. | +| Zona horaria de fuente | La zona horaria asociada con la IP de fuente. | + +## Unión de conversaciones {#conversation-stitching} + +De forma predeterminada, los registros de NetFlow separan los flujos unidireccionales para cada dirección del tráfico entre dos puntos de conexión (A → B y B → A). La unión de conversaciones combina estos en un solo registro bidireccional, brindándole una vista completa del tráfico total intercambiado entre dos puntos de conexión (A ↔ B). + +Con la unión de conversaciones, puede: - Ver el tráfico total intercambiado entre dos puntos de conexión como una sola conversación en lugar de flujos direccionales separados -- Identificar verdaderos iniciadores y respondedores para que los widgets de fuente y destino reflejen roles precisos -- Eliminar ruido donde los servidores aparecen incorrectamente como principales fuentes +- Identifique a los iniciadores y respondedores reales para que los widgets de fuente y destino reflejen roles precisos +- Elimine el ruido donde los servidores aparecen incorrectamente como fuentes principales -Para alternar entre vistas unificadas (bidireccionales) y no unificadas (unidireccionales), navegue a cualquier vista de NetFlow basada en puntos de conexión y utilice el interruptor **Bidireccional** bajo el selector de tiempo. +Para alternar entre las vistas unidas (bidireccionales) y no unidas (unidireccionales), navegue a cualquier vista de NetFlow basada en puntos de conexión y use el interruptor {{< ui >}}Bidirectional{{< /ui >}} debajo del selector de tiempo. -{{< img src="network_device_monitoring/netflow/conversation_stitching.png" alt="Interruptor de unificación de conversaciones en la vista de NetFlow" width="100%" >}} +{{< img src="network_device_monitoring/netflow/conversation_stitching.png" alt="Interruptor de unión de conversaciones en la vista de NetFlow" width="100%" >}} ## Tasa de muestreo {#sampling-rate} -La tasa de muestreo de NetFlow se toma en cuenta en el cálculo de bytes y paquetes por defecto. Los valores mostrados para bytes y paquetes se calculan con la tasa de muestreo aplicada. -Además, puede consultar **Bytes (Ajustados) (@adjusted_bytes)** y **Paquetes (Ajustados) (@adjusted_packets)** en tableros y notebooks para visualizarlos. +La tasa de muestreo de NetFlow se tiene en cuenta en el cálculo de bytes y paquetes de forma predeterminada. Los valores mostrados para bytes y paquetes se calculan con la tasa de muestreo aplicada. +Además, puede consultar **Bytes (ajustados) (@adjusted_bytes)** y **Paquetes (ajustados) (@adjusted_packets)** en paneles y cuadernos para visualizarlos. -Para visualizar los bytes/paquetes crudos (muestreados) enviados por sus dispositivos, puede consultar **Bytes (Muestreados) (@bytes)** y **Paquetes (Muestreados) (@packets)** en tableros y notebooks. +Para visualizar los bytes/paquetes sin procesar (muestreados) enviados por sus dispositivos, puede consultar **Bytes (muestreados) (@bytes)** y **Paquetes (muestreados) (@packets)** en paneles y cuadernos. ## Retención {#retention} -Los datos de NetFlow se retienen durante 30 días por defecto, con opciones para retención de 15, 30, 60 y 90 días. +Los datos de NetFlow se conservan durante 30 días de forma predeterminada, con opciones de retención de 15, 30, 60 y 90 días. -
Para retener los datos de NetFlow por períodos de tiempo más largos, comuníquese con su representante de cuenta.
+
Para conservar los datos de NetFlow durante períodos más largos, comuníquese con su representante de cuenta.
-## Limitar el volumen de flujo por intervalo de descarga {#limit-flow-volume-per-flush-interval} +## Limitar el volumen de flujo por intervalo de vaciado {#limit-flow-volume-per-flush-interval} -Para controlar el volumen de NetFlow y los costos asociados, configure Agent para limitar el número de registros de flujo enviados por intervalo de descarga. El intervalo de descarga es el período durante el cual los flujos se agregan antes de ser enviados a Datadog. +Para controlar el volumen de NetFlow y los costos asociados, configure el Agent para limitar la cantidad de registros de flujo enviados por intervalo de vaciado. El intervalo de vaciado es el período durante el cual los flujos se agregan antes de enviarse a Datadog. -Cuando este límite está habilitado, Agent retiene solo los **flujos principales por conteo de bytes** hasta el máximo configurado, y descarta flujos de menor volumen para ese intervalo de descarga. +Cuando este límite está habilitado, el Agent conserva solo los **flujos principales por recuento de bytes** hasta el máximo configurado y descarta los flujos de menor volumen para ese intervalo de vaciado. ### Configuración {#configuration-1} -**Nota**: Requiere la versión de Agent `7.75.1` o posterior. +**Nota**: Requiere la versión `7.75.1` del Agent o posterior. Configure lo siguiente en su `datadog.yaml`: @@ -279,27 +288,27 @@ network_devices: aggregator_max_flows_per_flush_interval: 10000 ``` -Con esta configuración, Agent envía como máximo 10,000 registros de NetFlow por intervalo de descarga (5 minutos por defecto). Agent prioriza los flujos de mayor volumen y descarta el resto. +Con esta configuración, el Agent envía como máximo 10,000 registros de NetFlow por intervalo de vaciado (5 minutos de forma predeterminada). El Agent prioriza los flujos de mayor volumen y descarta el resto. -### Estimando el volumen diario {#estimating-daily-volume} +### Estimación del volumen diario {#estimating-daily-volume} -Su conteo máximo aproximado de flujo diario es: +Su conteo máximo de flujos diario aproximado es: `max_flows_per_flush_interval * (minutes_per_day / flush_interval_minutes)` -Por ejemplo, con `10,000` flujos por descarga y un intervalo de descarga de 5 minutos: +Por ejemplo, con `10,000` flujos por vaciado y un intervalo de vaciado de 5 minutos: `10,000 * (1440 / 5) = 2,880,000 flows/day` ### Comportamiento esperado {#expected-behavior} -- **Se priorizan los principales generadores de tráfico:** Esto es lo mejor para flujos de trabajo enfocados en tráfico de alto volumen (por ejemplo, impulsores de ancho de banda y enlaces ruidosos). -- **Visibilidad reducida para flujos de bajo volumen:** Los pares de origen/destino de menor tráfico pueden no aparecer cuando se alcanza el límite. -- **Comportamiento por Agent:** El límite se aplica a cada Agent de manera independiente. Si múltiples Agents ven tráfico para las mismas conversaciones, no se agregan globalmente antes de la truncación. +- **Se da prioridad a los emisores principales:** Esto es ideal para flujos de trabajo centrados en tráfico de alto volumen (por ejemplo, controladores de ancho de banda y enlaces ruidosos). +- **Visibilidad reducida para flujos de bajo volumen:** Es posible que los pares de fuente/destino con menor tráfico no aparezcan cuando se alcanza el límite. +- **Comportamiento por Agent:** El límite se aplica a cada Agent de forma independiente. Si varios Agent ven tráfico para las mismas conversaciones, estos no se agregan globalmente antes del truncamiento. -### Monitoreo de truncación {#monitoring-truncation} +### Monitoreo del truncamiento {#monitoring-truncation} -Cuando se habilita la limitación de flujo, Agent emite métricas que puede usar para entender cuánto dato se está manteniendo frente a lo que se está descartando: +Cuando la limitación de flujo está habilitada, el Agent emite métricas que puede utilizar para comprender cuántos datos se conservan frente a los que se descartan: - `ndm.flow_truncation.flows_total` - `ndm.flow_truncation.flows_kept` @@ -308,16 +317,16 @@ Cuando se habilita la limitación de flujo, Agent emite métricas que puede usar - `ndm.flow_truncation.threshold_value` - `ndm.flow_truncation.runtime_ms` -Utilice estas métricas para validar su límite elegido y para detectar cuándo la truncación está ocurriendo con frecuencia (lo que puede indicar que debe ajustar el límite o el intervalo de descarga). +Utilice estas métricas para validar el límite elegido y para detectar cuándo ocurre el truncamiento con frecuencia (lo que puede indicar que debe ajustar el límite o el intervalo de vaciado). ## Solución de problemas {#troubleshooting} -### Caídas de paquetes de NetFlow {#netflow-packet-drops} -Las caídas de paquetes de NetFlow pueden ocurrir cuando hay un alto número de paquetes de NetFlow por segundo, típicamente mayor a 50,000. Los siguientes pasos pueden ayudar a identificar y mitigar las caídas de paquetes de NetFlow: +### Pérdidas de paquetes NetFlow {#netflow-packet-drops} +Las pérdidas de paquetes NetFlow pueden ocurrir cuando hay una gran cantidad de paquetes NetFlow por segundo, generalmente superior a 50,000. Los siguientes pasos pueden ayudar a identificar y mitigar las pérdidas de paquetes NetFlow: -#### Identificación de caídas de paquetes {#identifying-packet-drops} +#### Identificación de pérdidas de paquetes {#identifying-packet-drops} -Utilice el comando `netstat -s` para ver si hay paquetes UDP descartados: +Utilice el comando `netstat -s` para ver si hay paquetes UDP perdidos: ```bash netstat -s @@ -340,23 +349,23 @@ Utilice el comando `netstat -s` para ver si hay paquetes UDP descartados: 2. Aumentar la longitud de la cola UDP (solo Linux) - Ajustar la longitud de la cola UDP de su sistema puede ayudar a acomodar el mayor volumen de paquetes NetFlow. Aumente el tamaño del búfer de recepción UDP a 25 MB ejecutando los siguientes comandos: + Ajustar la longitud de la cola UDP de su sistema puede ayudar a acomodar el mayor volumen de paquetes NetFlow. Aumente el tamaño del búfer de recepción UDP a 25MB ejecutando los siguientes comandos: ```bash sudo sysctl -w net.core.rmem_max=26214400 sudo sysctl -w net.core.rmem_default=26214400 ``` -3. Persistiendo la configuración (solo Linux) +3. Persistencia de la configuración (solo Linux) - Para hacer estos cambios permanentes, agregue las siguientes líneas a su archivo `/etc/sysctl.conf`: + Para hacer que estos cambios sean permanentes, agregue las siguientes líneas a su archivo `/etc/sysctl.conf`: ```bash net.core.rmem_max=26214400 net.core.rmem_default=26214400 ``` -## Lectura adicional {#further-reading} +## Lecturas adicionales {#further-reading} {{< partial name="whats-next/whats-next.html" >}} @@ -366,7 +375,7 @@ Utilice el comando `netstat -s` para ver si hay paquetes UDP descartados: [4]: /es/agent/configuration/agent-commands/?tab=agentv6v7#start-stop-and-restart-the-agent [5]: https://app.datadoghq.com/devices/netflow [6]: /es/monitors/types/netflow/ -[7]: https://github.com/DataDog/datadog-agent/blob/f6ae461a7d22aaf398de5a94d9330694d69560d6/pkg/config/config_template.yaml#L4201 -[8]: https://github.com/DataDog/datadog-agent/blob/f6ae461a7d22aaf398de5a94d9330694d69560d6/pkg/config/config_template.yaml#L4203-L4275 +[7]: https://github.com/DataDog/datadog-agent/blob/main/pkg/config/example/datadog-agent_linux.yaml.example [9]: /es/network_monitoring/devices/troubleshooting#traps-or-flows-not-being-received-at-all -[10]: https://app.datadoghq.com/devices/settings/enrichment/ip \ No newline at end of file +[10]: https://app.datadoghq.com/devices/settings/enrichment/ip +[11]: /es/network_monitoring/network_path/setup/#dynamic-tests-for-netflow-experimental \ No newline at end of file diff --git a/hugo/content/es/observability_pipelines/destinations/sentinelone.md b/hugo/content/es/observability_pipelines/destinations/sentinelone.md index 9a02a3f8d87..c85ff0db2ce 100644 --- a/hugo/content/es/observability_pipelines/destinations/sentinelone.md +++ b/hugo/content/es/observability_pipelines/destinations/sentinelone.md @@ -1,49 +1,92 @@ --- +description: Aprenda a enviar registros a SentinelOne usando el Observability Pipelines + Worker. disable_toc: false further_reading: - link: https://www.datadoghq.com/blog/observability-pipelines-sentinelone/ tag: Blog - text: Optimizar los logs de EDR y enviarlos a SentinelOne con Observability Pipelines -title: Destino SentinelOne + text: Optimice los registros EDR y diríjalos a SentinelOne con Observability Pipelines. +products: +- icon: logs + name: Registros + url: /observability_pipelines/configuration/?tab=logs#pipeline-types +title: Destino de SentinelOne --- +{{< product-availability >}} -Utiliza el destino SentinelOne de Observability Pipelines para enviar logs a SentinelOne. +## Descripción general {#overview} -## Configuración +Utilice el destino de SentinelOne de Observability Pipelines para enviar registros a SentinelOne. -Configura el destino SentinelOne y sus variables de entorno cuando [configures un pipeline][1]. La información a continuación se configura en la interfaz de usuario de los pipelines. +## Configuración {#setup} -### Configurar el destino +
Para la administración de secretos: solo ingrese el identificador del token. No ingrese el valor real.
-{{% observability_pipelines/destination_settings/sentinelone %}} +Configure el destino de SentinelOne cuando [configure a pipeline][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. -### Configurar las variables de entorno +Después de seleccionar el destino de SentinelOne en la UI del pipeline: + +1. Ingrese el identificador de su token. Si lo deja en blanco, se utiliza el [predeterminado](#secret-defaults). +1. Seleccione su entorno de registros de SentinelOne en el menú desplegable. + +{{% observability_pipelines/secrets_env_var_note %}} + +### Almacenamiento en búfer opcional {#optional-buffering} + +{{% observability_pipelines/destination_buffer %}} + +## Valores predeterminados de Secret {#secret-defaults} + +{{% observability_pipelines/set_secrets_intro %}} + +{{< tabs >}} +{{% tab "Gestión de secretos" %}} + +- Identificador del token de acceso de escritura de SentinelOne: + - El identificador predeterminado es `DESTINATION_SENTINEL_ONE_TOKEN`. + +{{% /tab %}} + +{{% tab "Variables de entorno" %}} {{% observability_pipelines/configure_existing_pipelines/destination_env_vars/sentinelone %}} -## Visualizar logs en un clúster SentinelOne +{{% /tab %}} +{{< /tabs >}} + +## Ver registros en un clúster de SentinelOne {#view-logs-in-a-sentinelone-cluster} + +Después de configurar el pipeline para enviar registros al destino de SentinelOne, puede ver los registros en un clúster de SentinelOne: + +1. Inicie sesión en la [consola de S1][2]. +2. Navegue a la página de Singularity Data Lake (SDL) {{< ui >}}Search{{< /ui >}}. Para acceder a ella desde la consola, haga clic en {{< ui >}}Visibility{{< /ui >}} en el menú de la izquierda para ir a SDL y asegúrese de estar en la pestaña {{< ui >}}Search{{< /ui >}}. +3. Asegúrese de que el filtro junto a la barra de búsqueda esté configurado en {{< ui >}}All Data{{< /ui >}}. +4. Esta página muestra los registros que envió desde Observability Pipelines a SentinelOne. -Una vez configurado el pipeline para el envío de logs al destino SentinelOne, podrás visualizar los logs en un clúster SentinelOne: +## Métricas de salud {#health-metrics} -1. Inicia sesión en la [consola S1][2]. -2. Ve a la página "Buscar" de Singularity Data Lake (SDL). Para acceder a ella desde la consola, haz clic en "Visibility" (Visibilidad) en el menú de la izquierda para ir a SDL y asegúrate de que estás en la pestaña "Buscar". -3. Asegúrate de que el filtro situado junto a la barra de búsqueda está configurado como **Todos los datos**. -4. Esta página muestra los logs que enviaste desde Observability Pipelines a SentinelOne. +Para [métricas de componentes][7] y [métricas de búfer de destino][8] emitidas por todos los destinos, consulte la documentación de [Métricas de uso de Pipelines][9]. Para filtrar o agrupar por métricas de destino de Splunk HEC, utilice la etiqueta `component_type:splunk_hec_logs`. -## Cómo funciona el destino +## Cómo funciona el destino {#how-the-destination-works} -### Colocación de eventos en lotes +### Procesamiento por lotes de eventos {#event-batching} -Un lote de eventos se descarga cuando se cumple uno de estos parámetros. Para obtener más información, consulta [lotes de eventos][3]. +Un lote de eventos se vacía cuando se cumple uno de estos parámetros. Consulte [Agrupamiento de eventos de destino][3] para obtener más información. -| Eventos máximos | Bytes máximos | Tiempo de espera (segundos) | -|----------------|-----------------|---------------------| -| Ninguno | 1,000,000 | 1 | +| Máximo de eventos | Tamaño máximo (MB) | Tiempo de espera (segundos) | +|----------------|-------------------|---------------------| +| Ninguno | 1 | 1 | -## Referencias adicionales +## Lecturas adicionales {#further-reading} {{< partial name="whats-next/whats-next.html" >}} [1]: https://app.datadoghq.com/observability-pipelines [2]: https://usea1-partners.sentinelone.net/login -[3]: /es/observability_pipelines/destinations/#event-batching \ No newline at end of file +[3]: /es/observability_pipelines/destinations/#event-batching +[4]: /es/observability_pipelines/configuration/set_up_pipelines/ +[5]: /es/api/latest/observability-pipelines/ +[6]: https://registry.terraform.io/providers/datadog/datadog/latest/docs/resources/observability_pipeline +[7]: /es/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#component-metrics +[8]: /es/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#destination-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/reduce.md b/hugo/content/es/observability_pipelines/processors/reduce.md index ad075e978d6..73b297d51d5 100644 --- a/hugo/content/es/observability_pipelines/processors/reduce.md +++ b/hugo/content/es/observability_pipelines/processors/reduce.md @@ -1,13 +1,64 @@ --- +description: Aprenda a utilizar el procesador Reduce para agrupar varios eventos de + registro en un solo registro según los campos y las estrategias de combinación especificados. disable_toc: false products: - icon: logs - name: Logs -title: Reducir procesador + name: Registros + url: /observability_pipelines/configuration/?tab=logs#pipeline-types +title: Procesador Reduce --- - {{< product-availability >}} -{{% observability_pipelines/processors/reduce %}} +## Descripción general {#overview} + +El procesador Reduce agrupa varios eventos de registro en un solo registro, según los campos especificados y las estrategias de combinación seleccionadas. Los registros se agrupan en intervalos de 10 segundos. Una vez transcurrido el intervalo para el grupo, el registro reducido para ese grupo se envía al siguiente paso en el Pipeline. + +## Configuración {#setup} + +Para configurar el procesador Reduce: +1. Defina un {{< ui >}}filter query{{< /ui >}}. Solo se procesan los registros que coinciden con la consulta de filtro especificada. Los registros reducidos y los registros que no coinciden con la consulta de filtro se envían al siguiente paso en el Pipeline. Consulte [Sintaxis de búsqueda][1] para obtener más información. +2. En la sección {{< ui >}}Group By{{< /ui >}}, ingrese el campo por el cual desea agrupar los registros. +3. Haga clic en {{< ui >}}Add Group by Field{{< /ui >}} para agregar campos adicionales. +4. En la sección {{< ui >}}Merge Strategy{{< /ui >}}: + - En {{< ui >}}On Field{{< /ui >}}, ingrese el nombre del campo con el que desea combinar los registros. + - Seleccione la estrategia de combinación en el menú desplegable {{< ui >}}Apply{{< /ui >}}. Esta es la estrategia utilizada para combinar eventos. Consulte la sección [Estrategias de combinación](#merge-strategies) para ver las descripciones de las estrategias disponibles. + - Haga clic en {{< ui >}}Add Merge Strategy{{< /ui >}} para agregar estrategias adicionales. + +### Estrategias de combinación {#merge-strategies} + +Estas son las estrategias de combinación disponibles para combinar eventos de registro. + + +| Nombre | Descripción | +| -------------- | ------------------------------------------------------------------------------------------------------------------ | +| Array | Anexa cada valor a un array. | +| Concat | Concatena cada valor de cadena, delimitado con un espacio. | +| Concat newline | Concatena cada valor de cadena, delimitado por un salto de línea. | +| Concat raw | Concatena cada valor de cadena, sin un delimitador. | +| Discard | Descarta todos los valores excepto el primer valor que se recibió. | +| Flat unique | Crea un array aplanado de todos los valores únicos que se recibieron. | +| Longest array | Conserva el array más largo que se recibió. | +| Max | Conserva el valor numérico máximo que se recibió. | +| Min | Conserva el valor numérico mínimo que se recibió. | +| Retain | Descarta todos los valores excepto el último valor recibido. Funciona como una forma de coalescer al no retener `null`. | +| Shortest array | Conserva el array más corto que se recibió. | +| Sum | Suma todos los valores numéricos que se recibieron. | + +## Métricas de salud {#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]. + +### Reduce métricas {#reduce-metrics} + +- Utilice la etiqueta `component_id` para filtrar o agrupar por componentes individuales. +- La etiqueta `component_type` es `reduce` para estas métricas. + +`pipelines.stale_events_flushed_total` +: **Descripción**: El número de eventos obsoletos que el procesador ha vaciado. +: **Tipo de métrica**: count -{{% observability_pipelines/processors/filter_syntax %}} \ No newline at end of file +[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/ \ No newline at end of file diff --git a/hugo/content/es/observability_pipelines/processors/sensitive_data_scanner.md b/hugo/content/es/observability_pipelines/processors/sensitive_data_scanner.md new file mode 100644 index 00000000000..fe1df8a1a1c --- /dev/null +++ b/hugo/content/es/observability_pipelines/processors/sensitive_data_scanner.md @@ -0,0 +1,414 @@ +--- +description: Aprenda a utilizar el procesador Sensitive Data Scanner para detectar + y redactar o hashear información sensible, como la Información de Identificación + Personal (PII) y los datos de la Industria de Tarjetas de Pago (PCI) en registros + o trazas. +disable_toc: false +further_reading: +- link: /logs/guide/regex_log_parsing/ + tag: guía + text: Cómo escribir reglas de parseo Grok efectivas con expresiones regulares +- 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 +products: +- icon: logs + name: Registros + url: /observability_pipelines/configuration/?tab=logs#pipeline-types +title: El procesador Sensitive Data Scanner +--- +{{< product-availability >}} + +## Descripción general {#overview} + +El procesador Sensitive Data Scanner escanea los registros para detectar y redactar o hashear información sensible, como PII, PCI y datos sensibles personalizados. Puede elegir entre la biblioteca de reglas predefinidas de Datadog o ingresar reglas de expresiones regulares (Regex) personalizadas para buscar datos confidenciales. + +Puede configurar el pipeline y el procesador en la [UI](#set-up-the-processor-in-the-ui), [API][10] o [Terraform](#set-up-the-processor-using-terraform). + +Consulte [Mejores prácticas para optimizar el rendimiento](#best-practices-to-optimize-performance) para obtener consejos sobre cómo reducir el uso de recursos. + +## Configure el procesador en la UI {#set-up-the-processor-in-the-ui} + +Para configurar el procesador: + +1. Defina un {{< ui >}}filter query{{< /ui >}}. Consulte [Sintaxis de búsqueda de registros][1] para obtener más información. + - Solo los eventos que coinciden con el filtro se escanean y procesan. + - Todos los eventos, independientemente de si coinciden con la consulta de filtro, se envían al siguiente paso del pipeline. +1. Haga clic en {{< ui >}}Add Scanning Rule{{< /ui >}}. +1. Seleccione una de las siguientes opciones: + +{{< tabs >}} +{{% tab "Reglas de biblioteca" %}} + +1. En el menú desplegable, seleccione la regla de biblioteca que desea utilizar. +1. Las palabras clave recomendadas se agregan automáticamente según la regla de biblioteca seleccionada. Después de agregar la regla de escaneo, puede [agregar palabras clave adicionales o eliminar las palabras clave recomendadas](#add-additional-keywords). +1. En la sección {{< ui >}}Define rule target and conditions{{< /ui >}}, seleccione si desea escanear {{< ui >}}Entire Event{{< /ui >}}, {{< ui >}}Specific Attributes{{< /ui >}} o {{< ui >}}Exclude Attributes{{< /ui >}} en el menú desplegable. + - Si está escaneando todo el evento, puede excluir opcionalmente atributos específicos del escaneo. Utilice [notación de ruta](#path-notation-example) (`outer_key.inner_key`) para acceder a claves anidadas. Para los atributos especificados con datos anidados, se excluyen todos los datos anidados. + - Si está escaneando atributos específicos, especifique qué atributos desea escanear. Utilice [notación de ruta](#path-notation-example) (`outer_key.inner_key`) para acceder a claves anidadas. Para atributos especificados con datos anidados, se escanean todos los datos anidados. +1. Para {{< ui >}}Define actions on match{{< /ui >}}, seleccione la acción que desea realizar para la información coincidente. **Nota**: La redacción, la redacción parcial y el hashing son acciones irreversibles. + - {{< ui >}}Redact{{< /ui >}}: Reemplaza todos los valores coincidentes con el texto que especifique en el campo {{< ui >}}Replacement text{{< /ui >}}. + - {{< ui >}}Partially Redact{{< /ui >}}: Reemplaza una porción especificada de todos los datos coincidentes. En la sección {{< ui >}}Redact{{< /ui >}}, especifique la cantidad de caracteres que desea redactar y qué parte de los datos coincidentes desea redactar. + - {{< ui >}}Hash{{< /ui >}}: Reemplaza todos los datos coincidentes con un identificador único. Los bytes UTF-8 de la coincidencia se hashean con la huella digital de 64 bits de FarmHash. +1. Opcionalmente, haga clic en {{< ui >}}Add Field{{< /ui >}} para agregar etiquetas que desee asociar con los eventos coincidentes. +1. Agregue un nombre para la regla de escaneo. +1. Opcionalmente, agregue una descripción para la regla. +1. Haga clic en {{< ui >}}Save{{< /ui >}}. + +### Agregue palabras clave adicionales {#add-additional-keywords} + +Después de agregar reglas de escaneo de la biblioteca, puede editar cada regla por separado y agregar palabras clave adicionales al diccionario de palabras clave. + +1. Navegue a su [pipeline][1]. +1. En el procesador Sensitive Data Scanner con la regla que desea editar, haga clic en {{< ui >}}Manage Scanning Rules{{< /ui >}}. +1. Active {{< ui >}}Use recommended keywords{{< /ui >}} si desea que la regla los utilice. De lo contrario, agregue sus propias palabras clave al campo {{< ui >}}Create keyword dictionary{{< /ui >}}. También puede requerir que estas palabras clave estén dentro de un número especificado de caracteres de una coincidencia. De forma predeterminada, las palabras clave deben estar dentro de los 30 caracteres antes de un valor coincidente. +1. Haga clic en {{< ui >}}Update{{< /ui >}}. + +[1]: https://app.datadoghq.com/observability-pipelines + +{{% /tab %}} +{{% tab "Reglas personalizadas" %}} + +1. En la sección {{< ui >}}Define match conditions{{< /ui >}}, especifique el patrón regex que se utilizará para buscar coincidencias con eventos en el campo {{< ui >}}Define the regex{{< /ui >}}. Consulte [Writing Effective Grok Parseo Rules with Regular Expressions][1] para obtener más información. + Sensitive Data Scanner admite expresiones regulares compatibles con Perl (PCRE), pero no se admiten los siguientes patrones: + - Referencias inversas y subexpresiones de captura (lookarounds) + - Aserciones arbitrarias de ancho cero + - Referencias de subrutinas y patrones recursivos + - Patrones condicionales + - Verbos de control de backtracking + - La directiva `\C` "single-byte" (que rompe secuencias UTF-8) + - La coincidencia de nueva línea `\R` + - La directiva de reinicio de coincidencia `\K` + - Callouts y código incrustado + - Agrupación atómica y cuantificadores posesivos +1. Ingrese datos de muestra en el campo {{< ui >}}Add sample data{{< /ui >}} para verificar que su patrón regex sea válido. +1. Para {{< ui >}}Create keyword dictionary{{< /ui >}}, agregue palabras clave para refinar la precisión de la detección al hacer coincidir condiciones regex. Por ejemplo, si está escaneando un número de tarjeta de crédito Visa de dieciséis dígitos, puede agregar palabras clave como `visa`, `credit` y `card`. También puede requerir que estas palabras clave estén dentro de un número especificado de caracteres de una coincidencia. De forma predeterminada, las palabras clave deben estar dentro de los 30 caracteres antes de un valor coincidente. +1. En la sección {{< ui >}}Define rule target and conditions{{< /ui >}}, seleccione si desea escanear {{< ui >}}Entire Event{{< /ui >}}, {{< ui >}}Specific Attributes{{< /ui >}} o {{< ui >}}Exclude Attributes{{< /ui >}} en el menú desplegable. + - Si está escaneando todo el evento, puede excluir opcionalmente atributos específicos del escaneo. Utilice [notación de ruta](#path-notation-example) (`outer_key.inner_key`) para acceder a claves anidadas. Para los atributos especificados con datos anidados, se excluyen todos los datos anidados. + - Si está escaneando atributos específicos, especifique qué atributos desea escanear. Utilice [notación de ruta](#path-notation-example-custom) (`outer_key.inner_key`) para acceder a claves anidadas. Para atributos especificados con datos anidados, se escanean todos los datos anidados. +1. Para {{< ui >}}Define actions on match{{< /ui >}}, seleccione la acción que desea realizar para la información coincidente. **Nota**: La redacción, la redacción parcial y el hashing son acciones irreversibles. + - {{< ui >}}Redact{{< /ui >}}: Reemplaza todos los valores coincidentes con el texto que especifique en el campo {{< ui >}}Replacement text{{< /ui >}}. + - {{< ui >}}Partially Redact{{< /ui >}}: Reemplaza una porción especificada de todos los datos coincidentes. En la sección {{< ui >}}Redact{{< /ui >}}, especifique la cantidad de caracteres que desea redactar y qué parte de los datos coincidentes desea redactar. + - {{< ui >}}Hash{{< /ui >}}: Reemplaza todos los datos coincidentes con un identificador único. Los bytes UTF-8 de la coincidencia se hashean con la huella digital de 64 bits de FarmHash. +1. Opcionalmente, haga clic en {{< ui >}}Add Field{{< /ui >}} para agregar etiquetas que desee asociar con los eventos coincidentes. +1. Agregue un nombre para la regla de escaneo. +1. Opcionalmente, agregue una descripción para la regla. +1. Haga clic en {{< ui >}}Add Rule{{< /ui >}}. + +[1]: /es/logs/guide/regex_log_parsing/ + +{{% /tab %}} +{{< /tabs >}} + +### Eliminar una regla {#delete-a-rule} + +Para eliminar una regla en el Sensitive Data Scanner: + +1. Navegue a [Observability Pipelines][2]. +1. Seleccione su canalización. +1. Haga clic en el procesador Sensitive Data Scanner para expandirlo. +1. Haga clic en {{< ui >}}Manage Scanning Rules{{< /ui >}}. +1. Seleccione la regla que desea eliminar. +1. Haga clic en {{< ui >}}Delete{{< /ui >}}. + +### Ejemplo de notación de ruta {#path-notation-example} + +{{% observability_pipelines/path_notation %}} + +{{% observability_pipelines/path_notation_dots %}} + +## Configure el procesador usando Terraform {#set-up-the-processor-using-terraform} + +Puede utilizar el [Datadog Observability Pipeline Terraform resource][4] para configurar una pipeline con el procesador Sensitive Data Scanner. Para agregar una regla al procesador Sensitive Data Scanner usando Terraform: + +1. Utilice la fuente de datos [Datadog Sensitive Data Scanner Standard Pattern][5] para recuperar el ID de regla de la [library rule][6] de Sensitive Data Scanner. + + {{< code-block lang="terraform" >}} +data "datadog_sensitive_data_scanner_standard_pattern" "" { + filter = "" +} + {{< /code-block >}} + + Reemplace los marcadores de posición: + + - `` con un nombre para usar cuando configure posteriormente el procesador Sensitive Data Scanner en el recurso de Observability Pipelines. + - `` con el nombre exacto de la regla. Consulte [Library Rules][6] para ver la lista completa de reglas. + + Por ejemplo, si desea utilizar el [AWS Access Key ID Scanner][7], configure la fuente de datos como sigue: + + {{< code-block lang="terraform" >}} +data "datadog_sensitive_data_scanner_standard_pattern" "aws_access_key" { + filter = "AWS Access Key ID Scanner" +} + {{< /code-block >}} + Consulte el [ejemplo de configuración completa](#full-configuration-example) sobre cómo agregar fuentes de datos para varias reglas. + +1. Agregue un bloque [rule][9] en su recurso de Observability Pipeline para la regla de biblioteca. + + {{< code-block lang="terraform" >}} +... + sensitive_data_scanner { + rule { + name = "" + tags = [] + on_match { + redact { + replace = "***" + } + } + pattern { + library { + id = data.datadog_sensitive_data_scanner_standard_pattern..id + use_recommended_keywords = true + } + } + scope { + all = true + } + } + } + {{< /code-block >}} + + Reemplace los marcadores de posición: + + - `` con un nombre para la regla. Este nombre se muestra en la Pipelines UI. + - `` con el identificador de regla que utilizó en la fuente de datos en el paso 1. + + Por ejemplo, si utiliza la fuente de datos [AWS Access Key ID Scanner][7] del paso 1, configure el bloque de regla como sigue: + + {{< code-block lang="terraform" >}} +... + sensitive_data_scanner { + rule { + name = "Redact AWS Access Key IDs" + tags = [] + on_match { + redact { + replace = "***" + } + } + pattern { + library { + id = data.datadog_sensitive_data_scanner_standard_pattern.aws_access_key.id + use_recommended_keywords = true + } + } + scope { + all = true + } + } + } + {{< /code-block >}} + + Consulte el [ejemplo de configuración completa](#full-configuration-example) sobre cómo agregar varias reglas. + +1. Repita los pasos 1 y 2 para todas las reglas de biblioteca que desee agregar. + +### Ejemplo de configuración completa {#full-configuration-example} + +{{< img src="observability_pipelines/processors/sds_tf_ui.png" alt="El panel del procesador Sensitive Data Scanner que muestra dos reglas de escaneo: Redactar ID de clave de acceso de AWS y Redactar SSN de EE. UU." style="width:60%;" >}} + +Si desea utilizar el procesador Sensitive Data Scanner para buscar ID de clave de acceso de AWS y números de Seguro Social de EE. UU., y redactarlos reemplazándolos con la cadena `***`: + +1. Utilice la fuente de datos [Datadog Sensitive Data Scanner Standard Pattern][5] para recuperar los ID de regla para el [Escáner de ID de clave de acceso de AWS][7] y el [Escáner de número de Seguro Social de EE. UU.][8]. +1. En el procesador Sensitive Data Scanner de su recurso [Datadog Observability Pipeline][4], utilice las reglas de Sensitive Data Scanner definidas en las fuentes de datos. + +{{< code-block lang="terraform" >}} +data "datadog_sensitive_data_scanner_standard_pattern" "aws_access_key" { + filter = "AWS Access Key ID Scanner" +} +data "datadog_sensitive_data_scanner_standard_pattern" "us_ssn" { + filter = "US Social Security Number Scanner" +} + +resource "datadog_observability_pipeline" "sensitive_data_pipeline" { + name = "Sensitive Data Pipeline" + + config { + source { + id = "source-0" + datadog_agent {} + } + + processor_group { + display_name = "Processors" + enabled = true + id = "group-0" + include = "*" + inputs = ["source-0"] + + processor { + display_name = "Sensitive Data Scanner" + enabled = true + id = "processor-sds-0" + include = "*" + + sensitive_data_scanner { + rule { + name = "Redact AWS Access Key IDs" + tags = [] + on_match { + redact { + replace = "***" + } + } + pattern { + library { + id = data.datadog_sensitive_data_scanner_standard_pattern.aws_access_key.id + use_recommended_keywords = true + } + } + scope { + all = true + } + } + rule { + name = "Redact US SSNs" + tags = [] + on_match { + redact { + replace = "***" + } + } + pattern { + library { + id = data.datadog_sensitive_data_scanner_standard_pattern.us_ssn.id + use_recommended_keywords = true + } + } + scope { + all = true + } + } + } + } + } + + destination { + id = "destination-0" + inputs = ["group-0"] + datadog_logs {} + } + } +} +{{< /code-block >}} + +## Mejores prácticas para optimizar el rendimiento {#best-practices-to-optimize-performance} + +El procesador Sensitive Data Scanner consume muchos recursos de CPU. Utilice las siguientes mejores prácticas para optimizar el rendimiento. + +### Visualice el uso de las reglas de escaneo con el tablero Observability Pipelines Overview {#view-scanning-rule-usage-with-the-observability-pipelines-overview-dashboard} + +Observability Pipelines incluye un tablero [Observability Pipelines Overview][16] preconfigurado con una sección de **Datos confidenciales encontrados por Observability Pipelines**. Utilice los widgets de esa sección para ver qué reglas de escaneo están coincidiendo con los datos. + +1. Navegue a Dashboards > [Observability Pipelines Overview][16]. +1. Utilice las variables de plantilla (`pipeline_id`, `host`, `worker_uuid`, `component_type`, `component_kind`, `component_id`) en la parte superior del tablero para definir el contexto de la vista a una canalización o Worker específico. +1. Utilice el selector de tiempo para definir el contexto a un marco temporal más amplio. + +Utilice los siguientes widgets para evaluar el uso de las reglas de escaneo de sus procesadores Sensitive Data Scanner: + +- **Registros que contienen datos confidenciales por regla de escaneo**: Enumera cada regla por nombre (por ejemplo, `visa_card_scanner_1x16_1x19_digits` o `redact_ipv4`) con la cantidad de coincidencias durante el marco de tiempo seleccionado. Las reglas con recuentos altos están coincidiendo activamente con datos. Este es el widget principal para visualizar qué reglas están en uso. +- **Recuento total de registros que contienen datos confidenciales**: Muestra el volumen total de datos confidenciales que coinciden en todas las reglas. +- **Registros que contienen datos confidenciales por Pipeline**: Muestra los registros coincidentes que contienen datos confidenciales. Puede definir el contexto de las coincidencias por `pipeline_id`, lo que le ayuda a ver si los registros que contienen datos confidenciales se encuentran en todos los pipelines o solo en pipelines específicos. +- **Registros que contienen datos confidenciales por servidor**: Desglosa las coincidencias de datos confidenciales por servidor de Worker. Utilice este widget para confirmar la cobertura en toda su implementación. +- **Patrones que contienen información confidencial** y **Lista de registros que contienen datos confidenciales**: Muestra los patrones de registro y los eventos de muestra donde se encontraron datos confidenciales. + +Después de identificar las reglas sin coincidencias durante un período de tiempo representativo, confirme que no son necesarias y elimínelas. Consulte [Eliminar una regla](#delete-a-rule). + +**Nota**: Una regla con cero coincidencias significa que la regla no coincidió en el período de tiempo seleccionado, no que la regla sea inválida. + +### Habilite solo las reglas que necesita {#only-enable-rules-you-need} + +Las reglas que están habilitadas pero no se utilizan consumen recursos innecesarios. Verifique el procesador Sensitive Data Scanner para visualizar cuántas coincidencias ha tenido cada regla en las últimas 24 horas. + +1. Navegue a [Observability Pipelines][2]. +1. Seleccione su canalización. +1. Haga clic en el procesador Sensitive Data Scanner para expandirlo. +1. Haga clic en {{< ui >}}View Scanning Rules{{< /ui >}} para abrir el panel lateral y visualizar {{< ui >}}Matches in the last 24 hours{{< /ui >}} para cada regla. + +Consulte [Eliminar una regla](#delete-a-rule) para eliminar una regla que no se utiliza. + +### Escanee solo los eventos y campos que necesitan ser escaneados en busca de datos confidenciales {#only-scan-the-events-and-fields-that-need-to-be-scanned-for-sensitive-data} + +El tiempo que le toma al Sensitive Data Scanner escanear un evento escala aproximadamente con el tamaño del evento. Para optimizar el rendimiento del procesador: + +- Si conoce los tipos de eventos que desea escanear, defina una consulta de procesador que solo envíe al procesador los eventos que desea. + +- Reduzca el tiempo de escaneo seleccionando atributos de evento específicos para escanear o excluyendo atributos de evento del escaneo. Consulte el paso {{< ui >}}Define rule target and conditions{{< /ui >}} en [Configurar el procesador](#set-up-the-processor-in-the-ui). + +### Evalúe y compare las optimizaciones de rendimiento {#evaluate-and-benchmark-performance-optimizations} + +Utilice la métrica `pipelines.component_latency_seconds` para: + +- Compare el rendimiento del procesador al agregar una regla +- Evalúe el rendimiento después de realizar cambios de optimización, como reducir la cantidad de campos escaneados y eliminar reglas no utilizadas + +Para visualizar la métrica `pipelines.component_latency_seconds`: + +1. Navegue a [Metrics Explorer][11]. +1. En el campo de métrica, ingrese `pipelines.component_latency_seconds`. +1. En el campo {{< ui >}}from{{< /ui >}}, ingrese la etiqueta `component_id:`, donde `` es el ID de su procesador Sensitive Data Scanner. + +**Nota**: `pipelines.component_latency_seconds` es una métrica de distribución, por lo que debe habilitar los percentiles para esa métrica. Consulte [Habilitar la funcionalidad de consulta avanzada][12] para obtener instrucciones. + +## Métricas de estado {#health-metrics} + +Para [component metrics][13] y [processor buffer metrics][14] emitidas por todos los procesadores, consulte la documentación de [Pipelines Usage Metrics][15]. + +### Métricas de Sensitive Data Scanner {#sensitive-data-scanner-metrics} + +- Utilice la etiqueta `component_id` para filtrar o agrupar por componentes individuales. +- La etiqueta `component_type` es `sensitive_data_scanner` para las métricas del procesador Sensitive Data Scanner. + +`pipelines.sds_rule_matched_total` +: **Descripción**: La cantidad de eventos que coincidieron con una regla de Sensitive Data Scanner. Etiquetado con el nombre de la regla correspondiente. +: **Tipo de métrica**: conteo + +`pipelines.scanned_events` +: **Descripción**: La cantidad de eventos escaneados por el motor de Sensitive Data Scanner. +: **Tipo de métrica**: conteo + +`pipelines.scanning.match_count` +: **Descripción**: El número de coincidencias encontradas por el Sensitive Data Scanner. +: **Tipo de métrica**: count + +`pipelines.scanning.suppressed_match_count` +: **Descripción**: El número de coincidencias suprimidas por el Sensitive Data Scanner. +: **Tipo de métrica**: count + +`pipelines.scanning.duration` +: **Descripción**: Tiempo de reloj acumulado, en segundos, dedicado al escaneo de eventos. Utilice esta métrica para comparar el rendimiento del procesador y evaluar las optimizaciones. +: **Tipo de métrica**: count + +`pipelines.scanning.cpu_duration` +: **Descripción**: Tiempo de CPU acumulado, en segundos, dedicado al escaneo de eventos. +: **Tipo de métrica**: count + +`pipelines.scanner.total_count` +: **Descripción**: El número de procesadores de Sensitive Data Scanner que se están ejecutando actualmente. +: **Tipo de métrica**: gauge + +`pipelines.scanner.total_regexes` +: **Descripción**: El número de expresiones regulares almacenadas en todos los Sensitive Data Scanner. +: **Tipo de métrica**: gauge + +## Lecturas adicionales {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /es/observability_pipelines/search_syntax/logs/ +[2]: https://app.datadoghq.com/observability-pipelines +[3]: /es/logs/guide/regex_log_parsing/ +[4]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/observability_pipeline +[5]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/data-sources/sensitive_data_scanner_standard_pattern +[6]: /es/security/sensitive_data_scanner/scanning_rules/library_rules/ +[7]: /es/security/sensitive_data_scanner/scanning_rules/library_rules/?search=AWS+Access+Key+ID+Scanner +[8]: /es/security/sensitive_data_scanner/scanning_rules/library_rules/?search=US+Social+Security+Number+Scanner +[9]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/observability_pipeline#nested-schema-for-configprocessor_groupprocessorsensitive_data_scanner +[10]: /es/api/latest/observability-pipelines/#create-a-new-pipeline +[11]: https://app.datadoghq.com/metric/explorer +[12]: /es/metrics/distributions/#enabling-advanced-query-functionality +[13]: /es/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#component-metrics +[14]: /es/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#processor-buffer-metrics +[15]: /es/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/ +[16]: https://app.datadoghq.com/dash/integration/32326/observability-pipelines-overview \ No newline at end of file diff --git a/hugo/content/es/opentelemetry/setup/otlp_ingest/managed_platforms.md b/hugo/content/es/opentelemetry/setup/otlp_ingest/managed_platforms.md new file mode 100644 index 00000000000..2c7908ef5cf --- /dev/null +++ b/hugo/content/es/opentelemetry/setup/otlp_ingest/managed_platforms.md @@ -0,0 +1,124 @@ +--- +aliases: +- /es/opentelemetry/setup/agentless/managed_platforms +description: Envíe trazas, métricas y registros desde plataformas administradas como + Cloudflare, Vercel y Heroku directamente a Datadog a través de puntos de conexión + OTLP dedicados. +further_reading: +- link: /opentelemetry/compatibility/ + tag: Documentación + text: Compatibilidad con OpenTelemetry en Datadog +- link: /opentelemetry/setup/otlp_ingest/ + tag: Documentación + text: Punto de conexión de ingesta OTLP de Datadog +title: Ingesta OTLP para plataformas administradas +--- +## Descripción general {#overview} + +Datadog proporciona puntos de conexión de ingesta OTLP dedicados para plataformas administradas, lo que le permite enviar trazas, métricas y registros directamente a Datadog con una configuración mínima. Cada plataforma compatible tiene su propio subdominio OTLP (por ejemplo, `cloudflare.integrations.otlp.datadoghq.com`). Estos puntos de conexión dedicados permiten a Datadog identificar la fuente del tráfico y aplicar procesamiento y atribución específicos de la plataforma. El punto de conexión OTLP genérico asume que hay un servidor presente, lo que puede causar un comportamiento inesperado para el tráfico de plataformas administradas. + +Utilice esta opción cuando ejecute cargas de trabajo en una plataforma administrada donde no sea factible instalar un [Datadog Agent][1] o un [OpenTelemetry Collector][2]. Si su plataforma no se encuentra en la tabla a continuación y usted ejecuta en cómputo sin servidor de AWS, Azure o GCP, consulte [Serverless][5]. + +
Los metadatos de host enviados a los puntos de conexión de plataformas administradas no completan la Lista de hosts de infraestructura.
+ +Cada punto de conexión admite las siguientes rutas de señal: + +| Señal | Ruta | +|---------|---------------| +| Trazas | `/v1/traces` | +| Métricas | `/v1/metrics` | +| Registros | `/v1/logs` | + +Para la configuración específica de la señal (traducción de métricas, procesamiento de registros), consulte las páginas de los puntos de conexión de [Logs][6] y [Metrics][7]. + +## Configuración {#configuration} + +Para enviar datos OTLP a Datadog a través de un punto de conexión de plataforma administrada, configure su exportador de OpenTelemetry con las siguientes variables de entorno. Reemplace `{platform}` con el subdominio de su plataforma de la tabla de [plataformas compatibles](#supported-platforms). + +```shell +export OTEL_EXPORTER_OTLP_PROTOCOL="http/protobuf" +export OTEL_EXPORTER_OTLP_ENDPOINT="https://{platform}.integrations.otlp.{{< region-param key="dd_site" >}}" +export OTEL_EXPORTER_OTLP_HEADERS="dd-api-key=${DD_API_KEY}" +``` + +Para enviar solo trazas: + +```shell +export OTEL_EXPORTER_OTLP_TRACES_PROTOCOL="http/protobuf" +export OTEL_EXPORTER_OTLP_TRACES_ENDPOINT="https://{platform}.integrations.otlp.{{< region-param key="dd_site" >}}/v1/traces" +export OTEL_EXPORTER_OTLP_TRACES_HEADERS="dd-api-key=${DD_API_KEY}" +``` + +
Los puntos de conexión de plataformas administradas no utilizan el dd-otlp-source encabezado. Si migra desde el punto de conexión OTLP genérico, elimine este encabezado de su configuración.
+ +## Plataformas compatibles {#supported-platforms} + +Todos los puntos de conexión siguen el patrón `https://{subdomain}.integrations.otlp.{{< region-param key="dd_site" >}}/`. + +| Plataforma | Subdominio | Guía de configuración | +|---|---|---| +| AWX | `awx` | — | +| Claude | `claude` | — | +| Cloudflare | `cloudflare` | [Observabilidad de Cloudflare Workers][11] | +| Cribl | `cribl` | — | +| GitHub Actions | `github-actions` | — | +| Grafbase | `grafbase` | [Observabilidad de Grafbase][12] | +| Heroku | `heroku` | [Telemetría de Heroku][13] | +| IBM | `ibm` | — | +| LangSmith | `langsmith` | — | +| LiveCloudKit | `livekit` | — | +| Modal | `modal` | [Modal OpenTelemetry][14] | +| MuleSoft | `mulesoft` | [MuleSoft Telemetry Exporter][15] | +| Netlify | `netlify` | — | +| OpenTofu | `opentofu` | — | +| Retool | `retool` | [Monitoreo de rendimiento de Retool][16] | +| RWX | `rwx` | [RWX OpenTelemetry][17] | +| Salesforce | `sfdc` | — | +| Shopify | `shopify` | — | +| Solace | `solace` | — | +| Spacelift | `spacelift` | — | +| Supabase | `supabase` | — | +| Svix | `svix` | — | +| Trigger.dev | `triggerdev` | — | +| Vercel | `vercel` | [Vercel Marketplace][18] | + +Para habilitar la exportación OTLP desde una plataforma administrada que no aparezca en la lista anterior, comuníquese con su Customer Success Manager. + +## Limitaciones {#limitations} + +### Sin enriquecimiento de metadatos {#no-metadata-enrichment} + +Sin un Collector o Agent, la telemetría no se enriquece con metadatos de host. Las funciones que dependen de estos metadatos (por ejemplo, la [Lista de hosts de infraestructura][8]) no están disponibles. Consulte la [lista de compatibilidad de OpenTelemetry][4] para ver la lista completa de funciones afectadas. + +### Normalización limitada {#limited-normalization} + +Cierto procesamiento de señales que un Collector o Agent realiza automáticamente no ocurre con la ingesta directa. Por ejemplo, la conversión de métricas de acumulativo a delta requiere un componente con estado. Si su plataforma exporta métricas acumulativas, configure su SDK o pipeline para exportar temporalidad delta. + +### Métricas de traza {#trace-metrics} + +Las [métricas de traza][3] se calculan de forma predeterminada para los puntos de conexión de plataformas administradas. Las plataformas administradas pueden muestrear el tráfico antes de la exportación, lo cual puede afectar la precisión de las métricas de traza. + +### Muestreo {#sampling} + +Los controles de muestreo disponibles en el Collector (muestreo basado en el seguimiento de las últimas líneas, muestreo probabilístico) no están disponibles con la ingesta directa. Las plataformas administradas pueden aplicar su propio muestreo antes de la exportación. + +## Lecturas adicionales {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /es/opentelemetry/otlp_ingest_in_the_agent/ +[2]: /es/opentelemetry/setup/collector_exporter/ +[3]: /es/tracing/metrics/ +[4]: /es/opentelemetry/compatibility/ +[5]: /es/opentelemetry/setup/otlp_ingest/serverless/ +[6]: /es/opentelemetry/setup/otlp_ingest/logs/ +[7]: /es/opentelemetry/setup/otlp_ingest/metrics/ +[8]: /es/infrastructure/list/ +[11]: https://developers.cloudflare.com/workers/observability/exporting-opentelemetry-data/ +[12]: https://grafbase.com/docs/gateway/observability +[13]: https://devcenter.heroku.com/articles/heroku-telemetry +[14]: https://modal.com/docs/guide/otel-integration +[15]: https://docs.mulesoft.com/monitoring/telemetry-exporter +[16]: https://docs.retool.com/apps/guides/observability/performance-monitoring +[17]: https://www.rwx.com/docs/observability/datadog +[18]: https://vercel.com/marketplace/datadog \ No newline at end of file diff --git a/hugo/content/es/product_analytics/charts/analytics_explorer/_index.md b/hugo/content/es/product_analytics/charts/analytics_explorer/_index.md index a44b20a8fab..54038af6439 100644 --- a/hugo/content/es/product_analytics/charts/analytics_explorer/_index.md +++ b/hugo/content/es/product_analytics/charts/analytics_explorer/_index.md @@ -6,36 +6,38 @@ description: '' further_reading: - link: /real_user_monitoring/explorer/search/ tag: Documentación - text: Explorar tus vistas en Datadog + text: Explore sus visualizaciones dentro de Datadog - link: /dashboards/functions/ tag: Documentación - text: Añadir una función a tu consulta + text: Agregue una función a su consulta +- link: https://www.datadoghq.com/blog/product-analytics-faster-decisions + tag: Blog + text: Tome decisiones de producto más rápidas y mejores con Datadog Product Analytics - link: https://www.datadoghq.com/blog/datadog-geomaps/ tag: Blog - text: Utiliza geomapas para ver los datos de tu aplicación por ubicación + text: Utilice mapas geográficos para visualizar los datos de su aplicación por ubicación - link: https://www.datadoghq.com/blog/reduce-customer-friction-funnel-analysis/ tag: Blog - text: Utilizar el análisis del embudo para comprender y optimizar los flujos de - usuarios clave -title: Analytics Explorer + text: Utilice el análisis de embudo para entender y optimizar los flujos clave de + usuario +title: Analytics --- +## Descripción general {#overview} -## Información general - -La page (página) [Analytics Explorer][1] contiene vistas de agregación de datos para comprender cómo se está utilizando tu producto. Puedes controlar: +La página [Analytics Explorer][1] contiene la agregación de datos de visualizaciones para entender cómo se está utilizando su producto Puede controlar: -* El tipo de evento (Sesiones, Vistas o Acciones) por el cual ver las vistas. -* La consulta que filtra el conjunto de vistas que se van a analizar. -* Las dimensiones sobre las que dividir los datos. -* El método de visualización de agregados y divisiones. +* Seleccione un tipo de evento (Sessions, Visualizar o Acciones) para visualizar +* La consulta que filtra el conjunto de visualizaciones a analizar. +* Las dimensiones sobre las cuales dividir los datos. +* El método de visualización para agregados y divisiones. -Con las visualizaciones de Analytics, puedes: +Con las visualizaciones de Analytics, puede: -* Crear un widget en un dashboard a partir de esa visualización. -* Profundizar en subconjuntos de la lista de eventos en función de las interacciones que permite la visualización. +* Cree un widget en un dashboard a partir de esa visualización +* Profundice en subconjuntos de la lista de eventos dependiendo de las interacciones que la visualización permita -## Utilizar el gráfico de análisis -{{< whatsnext desc="Follow these links here to learn how to use the analytics search syntax, view events, and vizualise, group, and export views. " >}} +## Utilice el gráfico de analytics {#using-the-analytics-chart} +{{< whatsnext desc="Siga estos enlaces aquí para aprender cómo usar la sintaxis de búsqueda de analytics, ver eventos y visualizar, agrupar y exportar visualizaciones " >}} {{< nextlink href="product_analytics/charts/analytics_explorer/search_syntax" >}}Sintaxis de búsqueda{{< /nextlink >}} {{< nextlink href="product_analytics/charts/analytics_explorer/events" >}} Eventos {{< /nextlink >}} {{< nextlink href="product_analytics/charts/analytics_explorer/visualize" >}}Visualizar{{< /nextlink >}} @@ -43,30 +45,43 @@ Con las visualizaciones de Analytics, puedes: {{< nextlink href="product_analytics/charts/analytics_explorer/export" >}}Exportar{{< /nextlink >}} {{< /whatsnext >}} -## Crear una consulta +## Cree una consulta {#build-a-query} + +En [Analytics][1], personalice su visualización agregando facetas y medidas a su consulta de búsqueda + +1. Seleccione un [tipo de evento de Visualizar][2]. + + {{< img src="product_analytics/analytics/view_type_selection1.png" alt="Menú desplegable en Product Analytics limitado a la selección del tipo de Visualizar" style="width:70%;">}} + +1. Elija una medida para graficar el conteo único. + + {{< img src="product_analytics/analytics/measure_selection1.png" alt="Menú desplegable en Product Analytics para elegir una medida para graficar el conteo único." style="width:70%;">}} + +1. Filtre por atributos de evento o atributos de [integraciones de terceros][6]. -En [Analytics][1], personaliza tu visualización añadiendo facetas y medidas a tu consulta de búsqueda. + {{< img src="product_analytics/analytics/pana_analytics_filter_by.png" alt="Menú desplegable en Product Analytics para filtrar eventos por sus propios atributos o por atributos obtenidos de integraciones de terceros." style="width:70%;">}} -1. Selecciona un [tipo de evento de vista][2]. +1. Elija un atributo de evento para desglosar aún más los resultados. - {{< img src="product_analytics/analytics/view_type_selection.png" alt="Selección del tipo de vista." style="width:50%;">}} + {{< img src="product_analytics/analytics/pana_analytics_breakdown_by1.png" alt="Menú desplegable en Product Analytics para desglosar aún más los eventos por sus propios atributos o por atributos obtenidos de integraciones de terceros." style="width:70%;">}} -2. Elige una medida para representar gráficamente el recuento único. +1. Aplique una [función][4] para modificar cómo se devuelven los resultados de la consulta para las visualizaciones. - {{< img src="product_analytics/analytics/measure_selection.png" alt="Elige una medida para representar gráficamente el recuento único." style="width:50%;">}} + {{< img src="product_analytics/analytics/pana_analytics_functions.png" alt="Botón en Product Analytics para agregar una función que modifique cómo se devuelven los resultados de una consulta de métricas para las visualizaciones." style="width:70%;">}} -3. Elige un campo por el que [agrupar][3] la medida. +1. Elija el [tipo de gráfico][5] y el intervalo de tiempo para su gráfico. Cambiar el marco de tiempo global cambia la lista de valores de intervalo de tiempo disponibles. - {{< img src="product_analytics/analytics/pana_analytics_group_by.png" alt="Agrupar la medida por campos específicos." style="width:50%;">}} + {{< img src="product_analytics/analytics/pana_analytics_time_interval2.png" alt="Elija un tipo de gráfico y un intervalo de tiempo para su gráfico." style="width:50%;">}} -4. Elige el intervalo de tiempo para tu gráfico. Al cambiar el marco temporal global, cambia la lista de los valores de marca de tiempo disponibles. - {{< img src="product_analytics/analytics/pana_analytics_time_imterval.png" alt="Selecciona un intervalo de tiempo para tu gráfico." style="width:50%;">}} -## Referencias adicionales +## Lecturas adicionales {#further-reading} {{< partial name="whats-next/whats-next.html" >}} [1]: https://app.datadoghq.com/product-analytics/explorer [2]: /es/real_user_monitoring/guide/understanding-the-rum-event-hierarchy/ -[3]: /es/product_analytics/charts/analytics_explorer/group \ No newline at end of file +[3]: /es/product_analytics/charts/analytics_explorer/group +[4]: /es/dashboards/functions/#overview +[5]: /es/product_analytics/charts/analytics_explorer/visualize/ +[6]: https://app.datadoghq.com/product-analytics/integrations/custom-attributes \ No newline at end of file diff --git a/hugo/content/es/real_user_monitoring/_index.md b/hugo/content/es/real_user_monitoring/_index.md index 0c6ae0b8bef..4e0a0729eb0 100644 --- a/hugo/content/es/real_user_monitoring/_index.md +++ b/hugo/content/es/real_user_monitoring/_index.md @@ -9,156 +9,160 @@ aliases: cascade: algolia: rank: 70 -description: Visualiza, observa y analiza el rendimiento de tus aplicaciones de front-end - tal como las ven tus usuarios. +description: Visualice, observe y analice el rendimiento de sus aplicaciones front-end + tal como lo ven sus usuarios. disable_sidebar: true further_reading: - link: /real_user_monitoring/application_monitoring/browser/data_collected/ tag: Documentación - text: Datos de RUM del navegador recopilados + text: Datos de navegador de RUM recopilados - link: https://dtdg.co/fe - tag: Habilitación de la fundación - text: Únete a una sesión interactiva para obtener información a través de RUM + tag: Foundation Enablement + text: Únase a una sesión interactiva para obtener información a través de Real User + Monitoring (RUM) +- link: https://learn.datadoghq.com/courses/intro-to-rum + tag: Centro de aprendizaje + text: Introducción a Real User Monitoring (RUM) +- link: https://www.datadoghq.com/blog/ai-summaries-and-smart-chapters/ + tag: Blog + text: Comprenda las sesiones de Session Replay más rápido con resúmenes de IA y + capítulos inteligentes - link: https://www.datadoghq.com/blog/real-user-monitoring-with-datadog/ tag: Blog - text: Presentando Real User Monitoring de Datadog + text: Presentación de Datadog Real User Monitoring (RUM) - link: https://www.datadoghq.com/blog/datadog-mobile-rum/ tag: Blog - text: Mejora la experiencia del usuario móvil con Datadog Mobile Real User Monitoring + text: Mejore la experiencia del usuario móvil con Datadog Mobile Real User Monitoring + (RUM) - link: https://www.datadoghq.com/blog/mobile-monitoring-best-practices/ tag: Blog - text: Mejores prácticas para monitorear el rendimiento de aplicaciones móviles + text: Mejores prácticas para el seguimiento del rendimiento de aplicaciones móviles - link: https://www.datadoghq.com/blog/error-tracking/ tag: Blog - text: Comprende los problemas de la aplicación con Datadog Error Tracking + text: Entienda los problemas de las aplicaciones con Datadog Error Tracking - link: https://www.datadoghq.com/blog/unify-apm-rum-datadog/ tag: Blog - text: Unifica los datos de APM y RUM para una visibilidad de pila completa + text: Unifique los datos de APM y RUM para obtener visibilidad full-stack - link: https://www.datadoghq.com/blog/datadog-geomaps/ tag: Blog - text: Utiliza geomapas para visualizar los datos de tu aplicación por ubicación + text: Utilice mapas geográficos para visualizar los datos de su aplicación por ubicación - link: https://www.datadoghq.com/blog/datadog-rum-react-components/#tune-up-your-react-data-collection tag: Blog - text: Obtén mejores datos de RUM con nuestros componentes personalizados de React + text: Obtenga mejores datos de RUM con nuestros componentes personalizados de React - link: https://www.datadoghq.com/blog/hybrid-app-monitoring/ tag: Blog - text: Monitorea tus aplicaciones móviles híbridas con Datadog + text: Haga un seguimiento de sus aplicaciones móviles híbridas con Datadog - link: https://www.datadoghq.com/blog/how-datadogs-tech-solutions-team-rum-session-replay/ tag: Blog text: Cómo el equipo de Soluciones Técnicas de Datadog utiliza RUM, Session Replay - y Error Tracking para resolver problemas de clientes + y Error Tracking para resolver problemas de los clientes - link: https://www.datadoghq.com/blog/static-web-application-monitoring-best-practices/ tag: Blog - text: Mejores prácticas para monitorear aplicaciones web estáticas + text: Mejores prácticas para el seguimiento de aplicaciones web estáticas - link: https://www.datadoghq.com/blog/progressive-web-application-monitoring/ tag: Blog - text: Mejores prácticas para monitorear aplicaciones web progresivas + text: Mejores prácticas para el seguimiento de aplicaciones web progresivas - link: https://www.datadoghq.com/blog/datadog-executive-dashboards tag: Blog - text: Diseña tableros ejecutivos efectivos con Datadog + text: Diseñe dashboards ejecutivos efectivos con Datadog - link: https://www.datadoghq.com/blog/rum-product-analytics-bridging-teams tag: Blog - text: 'Del rendimiento al impacto: Conectando equipos de frontend a través de un - contexto compartido' + text: 'Del rendimiento al impacto: conectando a los equipos de frontend a través + de un contexto compartido.' - link: https://app.datadoghq.com/release-notes?category=Real%20User%20Monitoring tag: Notas de la versión - text: ¡Consulta las últimas versiones de Datadog RUM! (Se requiere inicio de sesión - en la aplicación) -- link: https://learn.datadoghq.com/courses/intro-to-rum - tag: Centro de Aprendizaje - text: Introducción a Real User Monitoring (RUM) + text: ¡Eche un vistazo a los últimos lanzamientos de Datadog RUM! (Se requiere inicio + de sesión en la aplicación). title: RUM y Session Replay --- -{{< learning-center-callout header="Únete a una sesión de seminario web de habilitación" hide_image="true" btn_title="Regístrate" btn_url="https://www.datadoghq.com/technical-enablement/sessions/?tags.topics-0=RUM">}} - Descubre cómo crear acciones de usuario personalizadas adaptadas a necesidades comerciales específicas, lo que permite un seguimiento preciso del comportamiento del usuario. +{{< learning-center-callout header="Únase a una sesión de seminario web de habilitación" hide_image="true" btn_title="Registrarse" btn_url="https://www.datadoghq.com/technical-enablement/sessions/?tags.topics-0=RUM">}} + Descubra cómo crear acciones de usuario personalizadas adaptadas a necesidades comerciales específicas, lo que permite un seguimiento preciso del comportamiento del usuario. {{< /learning-center-callout >}} -## ¿Qué es RUM? {#what-is-real-user-monitoring} +## ¿Qué es Real User Monitoring? {#what-is-real-user-monitoring} -{{< img src="real_user_monitoring/performance-summary-browser.png" alt="Tablero de RUM" >}} +{{< img src="real_user_monitoring/performance-summary-browser.png" alt="RUM Dashboard" >}} -*Real User Monitoring (RUM)* de Datadog te brinda visibilidad de extremo a extremo sobre la actividad y experiencia en tiempo real de usuarios individuales. RUM resuelve cuatro tipos de casos de uso para la monitorización de aplicaciones web y móviles: +*Real User Monitoring (RUM)* de Datadog le brinda visibilidad de extremo a extremo sobre la actividad y la experiencia en tiempo real de los usuarios individuales. RUM resuelve cuatro tipos de casos de uso para el seguimiento de aplicaciones web y móviles: -* **Rendimiento**: Realiza un seguimiento del rendimiento de las páginas web, pantallas de aplicaciones móviles, acciones de usuario, solicitudes de red y tu código frontend. -* **Gestión de Errores**: Monitorea los errores y problemas en curso y haz un seguimiento de ellos a lo largo del tiempo y las versiones. -* **Analítica / Uso**: Comprende quién está utilizando tu aplicación (país, dispositivo, SO), monitorea los recorridos de usuarios individuales y analiza cómo los usuarios interactúan con tu aplicación (página más visitada, clics, interacciones y uso de funciones). -* **Soporte**: Recupera toda la información relacionada con una sesión de usuario para solucionar un problema (duración de la sesión, páginas visitadas, interacciones, recursos cargados y errores). +* **Rendimiento**: Realice un seguimiento del rendimiento de páginas web, pantallas de aplicaciones móviles, acciones de usuario, solicitudes de red y su código frontend. +* **Gestión de errores**: Haga un seguimiento de los errores y problemas en curso, y realice un seguimiento de ellos a lo largo del tiempo y las versiones. +* **Análisis / Uso**Comprenda quién está utilizando su aplicación (país, dispositivo, sistema operativo), haga un seguimiento de los recorridos individuales de los usuarios y analice cómo interactúan los usuarios con su aplicación (página más visitada, clics, interacciones y uso de funciones). +* **Soporte**: Recupere toda la información relacionada con una sesión de usuario para solucionar un problema (duración de la sesión, páginas visitadas, interacciones, recursos cargados y errores). ### Definición de sesión {#session-definition} -Una sesión de usuario es un recorrido de usuario en tu aplicación web o móvil. Una sesión incluye todos los eventos de navegación relacionados (Vistas RUM), acciones de usuario (Acciones RUM), solicitudes de red (Recursos RUM), fallos y errores (Errores RUM), y otros eventos y señales que producen colectivamente una representación fiel de la experiencia del usuario. +Una sesión de usuario es el recorrido de un usuario en su aplicación web o móvil. Una sesión incluye todos los eventos de navegación relacionados (RUM Views), acciones de usuario (RUM Actions), solicitudes de red (RUM Resources), bloqueos y errores (RUM Errors), y otros eventos y señales que colectivamente producen una representación fiel de la experiencia del usuario. -Una sesión RUM puede durar hasta 4 horas y expira después de 15 minutos de inactividad. Si el usuario interactúa con la aplicación después de cualquiera de los límites, una nueva sesión comienza automáticamente. +Una sesión de RUM puede durar hasta 4 horas y expira después de 15 minutos de inactividad. Si el usuario interactúa con la aplicación después de cualquiera de los dos límites, se inicia una nueva sesión automáticamente. ### Limitaciones técnicas {#technical-limitations} | Propiedad | Limitación | | ------------------------------------------ | ------------------------ | | Duración máxima de una sesión | 4 horas | -| Tiempo de espera de una sesión | 15 minutos de inactividad | -| Número máximo de eventos por sesión | 10 millones | -| Número máximo de atributos por evento | 1,000 | -| Profundidad máxima de atributos por evento | 20 | -| Tamaño máximo de evento | 1 MB | -| Tamaño máximo de carga útil de entrada | 5 MB | -| Tamaño máximo de mapas del código fuente y archivos de mapeo | 500 MB por archivo | -| Tamaño máximo de archivos dSYM | 2 GB por archivo | -| Retraso máximo en la ingestión | 24 horas | - -Si un evento supera cualquiera de las limitaciones técnicas mencionadas anteriormente, es rechazado por el sistema de ingestión de Datadog. +| Tiempo de espera de una sesión | 15 minutos de inactividad | +| Número máximo de eventos por sesión | 10 millones | +| Número máximo de atributos por evento | 1,000 | +| Profundidad máxima de atributos por evento | 20 | +| Tamaño máximo de evento | 1 MB | +| Tamaño máximo de carga útil de ingesta | 5 MB | +| Tamaño máximo de mapas de origen y archivos de mapeo | 500 MB por archivo | +| Tamaño máximo de archivos dSYM | 2 GB por archivo | +| Retraso máximo en la ingesta | 24 horas | + +Si un evento supera cualquiera de las limitaciones técnicas enumeradas anteriormente, es rechazado por la ingesta de Datadog. ## ¿Qué es Session Replay? {#what-is-session-replay} -El *Session Replay* de Datadog te permite capturar y reproducir visualmente la experiencia de navegación web de tus usuarios. +*Session Replay* de Datadog le permite capturar y reproducir visualmente la experiencia de navegación web de sus usuarios. -Combinado con los datos de rendimiento de RUM, Session Replay es beneficioso para la identificación, reproducción y resolución de errores, y proporciona información sobre los patrones de uso y fallas de diseño en tu aplicación web. +Combinado con los datos de rendimiento de RUM, Session Replay es beneficioso para la identificación, reproducción y resolución de errores, y proporciona información sobre los patrones de uso y las deficiencias en el diseño de su aplicación web. -## Comenzar {#get-started} +## Comience {#get-started} Seleccione un tipo de aplicación para comenzar a recopilar datos de RUM: {{< card-grid card_width="210" >}} - {{< image-card href="/real_user_monitoring/application_monitoring/browser/" src="integrations_logos/javascript_large.svg" alt="browser" >}} - {{< image-card href="/real_user_monitoring/application_monitoring/android/setup" src="integrations_logos/android_large.svg" alt="android" >}} - {{< image-card href="/real_user_monitoring/application_monitoring/ios/setup" src="integrations_logos/ios_large.svg" alt="ios" >}} - {{< image-card href="/real_user_monitoring/application_monitoring/react_native/setup" src="integrations_logos/react-native_large.svg" alt="react native" >}} - {{< image-card href="/real_user_monitoring/application_monitoring/flutter/setup" src="integrations_logos/flutter_large.svg" alt="flutter" >}} - {{< image-card href="/real_user_monitoring/application_monitoring/android/setup" src="integrations_logos/android_tv_large.svg" alt="android tv" >}} - {{< image-card href="/real_user_monitoring/application_monitoring/ios/setup" src="integrations_logos/tv_os_large.svg" alt="tv OS" >}} + {{< image-card href="/real_user_monitoring/application_monitoring/browser/" src="integrations_logos/javascript_large.svg" alt="Navegador" >}} + {{< image-card href="/real_user_monitoring/application_monitoring/android/setup" src="integrations_logos/android_large.svg" alt="Android" >}} + {{< image-card href="/real_user_monitoring/application_monitoring/ios/setup" src="integrations_logos/ios_large.svg" alt="iOS" >}} + {{< image-card href="/real_user_monitoring/application_monitoring/react_native/setup" src="integrations_logos/react-native_large.svg" alt="React Native" >}} + {{< image-card href="/real_user_monitoring/application_monitoring/flutter/setup" src="integrations_logos/flutter_large.svg" alt="Flutter" >}} + {{< image-card href="/real_user_monitoring/application_monitoring/android/setup" src="integrations_logos/android_tv_large.svg" alt="Android TV" >}} + {{< image-card href="/real_user_monitoring/application_monitoring/ios/setup" src="integrations_logos/tv_os_large.svg" alt="tvOS" >}} {{< image-card href="/real_user_monitoring/application_monitoring/roku/setup" src="integrations_logos/roku_large.svg" alt="Roku" >}} {{< image-card href="/real_user_monitoring/application_monitoring/unity/setup" src="integrations_logos/rum-unity_large.svg" alt="rum-unity" >}} {{< image-card href="/real_user_monitoring/application_monitoring/kotlin_multiplatform/setup" src="integrations_logos/kotlin-multiplatform_large.svg" alt="Kotlin Multiplatform" >}} {{< /card-grid >}} -
- ### Capacidades y soporte de plataforma {#capabilities-and-platform-support} -**Nota**: El SDK de Datadog Flutter no es compatible con MacOS, Windows o Linux. +**Nota**: El SDK de Datadog para Flutter no es compatible con MacOS, Windows o Linux. La siguiente tabla muestra qué capacidades de RUM son compatibles en cada plataforma: -| Característica | Navegador | Android | iOS | Flutter | React Native | Roku | KMP | Unity | Notas | +| Feature | Browser | Android | iOS | Flutter | React Native | Roku | KMP | Unity | Notes | | ------------------------------------- | --------|---------|---------|---------|--------------|------|-----|-------|--------| | Enviar registros a Datadog | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | -| Trazado distribuido de solicitudes de red | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | - **Roku** solo puede rastrear algunos tipos de solicitudes HTTP.
- **Unity** utiliza un envoltorio alrededor de `UnityWebRequest` para realizar el rastreo de solicitudes. | -| Rastrear Visualizaciones y Acciones (RUM) | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | - Todas las acciones rastreadas en **Flutter Web** se registran como `custom`.
- **Roku** y **Unity** solo admiten el rastreo manual de acciones. | -| Seguimiento de Feature Flags y lanzamientos | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | {{< X >}} | {{< X >}} | | -| Seguimiento de errores y mapa del código fuente | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | Solo parcialmente compatible con **React Native**. | -| Rastrear fallos, simbolización y desofuscación | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | -| Detener sesiones (Monitoreo de Kiosco) | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | {{< X >}} | {{< X >}} | | -| Rastrear eventos en WebViews | | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | {{< X >}} | | | -| Monitorear métricas específicas de la plataforma | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | {{< X >}} | | | -| Seguimiento global de contexto/atributos en los registros | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | {{< X >}} | {{< X >}} | | -| Trazado del lado del cliente | | {{< X >}} | {{< X >}}| | | | | | | | -| Session Replay | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | {{< X >}} | | **Flutter** Session Replay está en vista previa. | -| Señales de frustración | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | Solo parcialmente compatible con todos los dispositivos **móviles** y **Roku**. | - -## Puntos de conexión compatibles para dominios de SDK {#supported-endpoints-for-sdk-domains} - -Todo el tráfico de los SDK de Datadog se transmite a través de SSL (puerto 443 por defecto) a los siguientes dominios: - -| Sitio | URL del sitio | +| Rastreo distribuido de solicitudes de red | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | - **Roku** solo puede rastrear algunos tipos de solicitudes HTTP.
- **Unity** utiliza un contenedor alrededor de `UnityWebRequest` para realizar el rastreo de solicitudes. | +| Track Views and Actions (RUM) | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | - Todas las acciones rastreadas en **Flutter Web** se registran como `custom`.
- **Roku** y **Unity** solo admiten el seguimiento manual de acciones. | +| Feature Flags tracking and release tracking | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | {{< X >}} | {{< X >}} | | +| Error Tracking and source mapping | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | +| Crash tracking, symbolication, and deobfuscation | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | +| Stop sessions (Kiosk Monitoring) | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | {{< X >}} | {{< X >}} | | +| Track Events in WebViews | | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | {{< X >}} | | | +| Monitor platform-specific vitals | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | {{< X >}} | | | +| Global context/attribute tracking in Logs | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | {{< X >}} | {{< X >}} | | +| Client side tracing | | {{< X >}} | {{< X >}}| | | | | | | | +| Session Replay | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | {{< X >}} | | **Flutter** Session Replay is in Preview. | +| Frustration signals | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | | Only partially supported for all **mobile** and **Roku** devices. | + +## Supported endpoints for SDK domains {#supported-endpoints-for-sdk-domains} + +Todo el tráfico de los SDK de Datadog se transmite a través de SSL (443 por defecto) a los siguientes dominios: + +| Site | Site URL | |------|-----------------------------------------------| | US1 | `https://browser-intake-datadoghq.com` | | US3 | `https://browser-intake-us3-datadoghq.com` | @@ -168,102 +172,121 @@ Todo el tráfico de los SDK de Datadog se transmite a través de SSL (puerto 443 | US2-FED | `https://browser-intake-us2-ddog-gov.com` | | AP1 | `https://browser-intake-ap1-datadoghq.com` | | AP2 | `https://browser-intake-ap2-datadoghq.com` | +| UK1 | `https://browser-intake-uk1-datadoghq.com` | + +### Additional endpoints for Browser Profiling {#additional-endpoints-for-browser-profiling} + +Cuando [Browser Profiling][19] está habilitado, el SDK también contacta a una API de cuota para determinar si el perfilado está permitido para la sesión actual. Esto utiliza un `quota.` subdominio del origen de ingesta estándar: + +| Site | Quota API URL | +|------|-----------------------------------------------------------| +| US1 | `https://quota.browser-intake-datadoghq.com` | +| US3 | `https://quota.browser-intake-us3-datadoghq.com` | +| US5 | `https://quota.browser-intake-us5-datadoghq.com` | +| EU1 | `https://quota.browser-intake-datadoghq.eu` | +| US1-FED | `https://quota.browser-intake-ddog-gov.com` | +| US2-FED | `https://quota.browser-intake-us2-ddog-gov.com` | +| AP1 | `https://quota.browser-intake-ap1-datadoghq.com` | +| AP2 | `https://quota.browser-intake-ap2-datadoghq.com` | +| UK1 | `https://quota.browser-intake-uk1-datadoghq.com` | + +Si utiliza un [proxy][20] o tiene una [Política de Seguridad de Contenido (CSP)][21], asegúrese de que estos dominios `quota.` también estén permitidos. Consulte la página [Browser Profiling setup][19] para obtener más detalles. -## Explorar Datadog RUM {#explore-datadog-rum} +## Explore Datadog RUM {#explore-datadog-rum} -Acceda a RUM navegando a [**Experiencia Digital > Resumen de Rendimiento**][1]. +Acceda a RUM navegando a [{{< ui >}}Digital Experience{{< /ui >}} > {{< ui >}}Performance Summary{{< /ui >}}][1]. -Seleccione una aplicación desde la navegación superior, o siga las instrucciones de configuración para [browser][15] o [mobile][16] para agregar su primera aplicación. +Seleccione una aplicación en la navegación superior o siga las instrucciones de configuración para [browser][15] o [mobile][16] para agregar su primera aplicación. {{< img src="real_user_monitoring/rum-performance-application-selector.png" alt="Seleccione una aplicación RUM" >}} **Consejo**: Para abrir RUM desde la búsqueda global de Datadog, presione Cmd/Ctrl + K y busque `real user monitoring`. -## Resumen de seguimiento de rendimiento {#performance-monitoring-summary} +## Resumen de monitoreo de rendimiento {#performance-monitoring-summary} -| Resumen de seguimiento de rendimiento del navegador | Resumen de seguimiento de rendimiento móvil | +| Resumen de rendimiento del navegador | Resumen de rendimiento móvil | |---------|---------| -| {{< img src="real_user_monitoring/performance-summary-browser.png" alt="Página de resumen de seguimiento de rendimiento RUM para una aplicación de navegador" >}} | {{< img src="real_user_monitoring/performance-summary-mobile-2.png" alt="Página de resumen de seguimiento de rendimiento RUM para una aplicación móvil" >}} | +| {{< img src="real_user_monitoring/performance-summary-browser.png" alt="Página de resumen de monitoreo de rendimiento de RUM para una aplicación de navegador" >}} | {{< img src="real_user_monitoring/performance-summary-mobile-2.png" alt="Página de resumen de monitoreo de rendimiento de RUM para una aplicación móvil" >}} | -La página de [Resumen de Seguimiento de Rendimiento RUM][1] proporciona información relevante y procesable para aplicaciones web y móviles. Usted tiene una experiencia personalizada para cada plataforma que le ayuda a: +La página [Resumen de monitoreo de rendimiento de RUM][1] proporciona información relevante y procesable tanto para aplicaciones web como móviles. Tiene una experiencia personalizada para cada plataforma que le ayuda a: -- **Concéntrese en puntos de datos clave** por plataforma, como la latencia de la UI para web o fallos en móviles. -- **Monitoree la salud de la aplicación** a través de KPIs familiares, como Core Web Vitals para aplicaciones web o tasa de cuelgues para iOS, para evaluar la confiabilidad de la aplicación. -- **Profundice en las investigaciones directamente** desde widgets interactivos sin salir de la página. +- **Céntrese en los puntos de datos clave** por plataforma, como la latencia de la interfaz de usuario para web o los bloqueos móviles +- **Monitoree el estado de la aplicación** a través de KPI conocidos, como Core Web Vitals para aplicaciones web o la tasa de bloqueos para iOS, para evaluar la confiabilidad de la aplicación +- **Profundice en las investigaciones directamente** desde widgets interactivos sin salir de la página -Para **aplicaciones web**, use la barra de búsqueda para filtrar datos, identificar páginas lentas y seguir la UI hasta la página de [RUM Optimization Inspect][17]. +Para **aplicaciones web**, utilice la barra de búsqueda para filtrar datos, identificar páginas lentas y seguir la interfaz de usuario hasta la página [RUM Optimization Inspect][17]. -Para **aplicaciones móviles**, Revise los fallos recientes en la parte inferior de la página y use el panel lateral de [Error Tracking][6] para solucionar problemas. +Para **aplicaciones móviles**, revise los bloqueos recientes en la parte inferior de la página y utilice el panel lateral [Error Tracking][6] para la resolución de problemas. -### Tableros listos para usar {#out-of-the-box-dashboards} +### Tableros preconfigurados {#out-of-the-box-dashboards} -Analiza información sobre las sesiones de usuario, rendimiento, aplicaciones móviles, señales de frustración, recursos de red y errores recopilados automáticamente con [tableros RUM listos para usar][2]. +Analice información sobre sus sesiones de usuario, rendimiento, aplicaciones móviles, señales de frustración, recursos de red y errores recopilados automáticamente con [tableros de RUM preconfigurados][2]. -{{< img src="real_user_monitoring/rum-out-of-the-box-dashboard.png" alt="Tablero RUM" >}} +{{< img src="real_user_monitoring/rum-out-of-the-box-dashboard.png" alt="Tablero de RUM" >}} -### Explorador RUM y visualizaciones {#rum-explorer-and-visualizations} +### Explorador de RUM y visualizaciones {#rum-explorer-and-visualizations} -Visualice las sesiones de usuario en segmentos, como verificar cuándo la latencia impacta a sus clientes premium, con [visualizations][3]. Explore datos, guarde vistas y cree [monitors][4] en sus búsquedas personalizadas. +Vea las sesiones de usuario en segmentos, como verificar cuándo la latencia afecta a sus clientes premium, con [visualizaciones][3]. Explore datos, guarde vistas y cree [monitors][4] en sus búsquedas personalizadas. -{{< img src="real_user_monitoring/explorer/analytics/rum_analytics.mp4" alt="Analítica RUM" video=true >}} +{{< img src="real_user_monitoring/explorer/analytics/rum_analytics.mp4" alt="Análisis de RUM" video=true >}} -### Integración con registros, APM y perfilador {#integration-with-logs-apm-and-profiler} +### Integración con registros, APM y profiler {#integration-with-logs-apm-and-profiler} -Visualice sus [trazas de backend, registros y métricas de infraestructura][5] hasta la línea exacta de código que impacta el rendimiento de su aplicación, correspondiente a las experiencias de usuario y problemas reportados. +Vea sus trazas de backend, registros y métricas de infraestructura hasta la línea exacta de código que afecta el rendimiento de su aplicación, correspondiente a las experiencias de los usuarios y los problemas reportados. {{< img src="real_user_monitoring/connect_rum_and_traces/rum_apm_logs-2.png" alt="RUM y APM" >}} -### Seguimiento de errores e informes de fallos {#error-tracking-and-crash-reporting} +### Error Tracking y reportes de fallos {#error-tracking-and-crash-reporting} -Reciba alertas automáticas sobre valores anómalos y grupos de errores, tiempos de espera y fallos para reducir significativamente su MTTR con [Error Tracking][6]. +Reciba alertas automatizadas sobre valores atípicos y grupos de errores, tiempos de espera y fallos para reducir significativamente su MTTR con [Error Tracking][6]. -{{< img src="real_user_monitoring/error_tracking/errors_rum.mp4" alt="RUM Error Tracking" video=true >}} +{{< img src="real_user_monitoring/error_tracking/errors_rum.mp4" alt="Error Tracking de RUM" video=true >}} -### Vitales web y móviles {#web-and-mobile-vitals} +### Vitals web y móviles {#web-and-mobile-vitals} -Visualice puntajes de rendimiento y telemetría para [aplicaciones de navegador][7] como Core Web Vitals y Mobile Vitals para [iOS y tvOS][8] o [aplicaciones de Android y Android TV][9]. +Vea las puntuaciones de rendimiento y la telemetría de [browser applications][7], como Core Web Vitals y Mobile Vitals para [iOS, iPadOS, tvOS, and visionOS][8] o [Android and Android TV applications][9]. -### Seguimiento de visualización web{#web-view-tracking} +### Seguimiento de vistas web {#web-view-tracking} -Recopile información de sus aplicaciones web nativas y explore vistas híbridas con seguimiento de visualización web para [iOS y tvOS][10] o [Android y Android TV][11]. +Recopile información de sus aplicaciones web nativas y explore vistas híbridas con el seguimiento de vistas web para [iOS, iPadOS, and visionOS][10] o [Android and Android TV][11]. -{{< img src="real_user_monitoring/webview_tracking/webview_tracking_light.png" alt="Visualizaciones web capturadas en una sesión de usuario en el Explorador RUM" >}} +{{< img src="real_user_monitoring/webview_tracking/webview_tracking_light.png" alt="Vistas web capturadas en una sesión de usuario en el RUM Explorer" >}} -## Explore la reproducción de sesión de Datadog{#explore-datadog-session-replay} +## Explore Datadog Session Replay {#explore-datadog-session-replay} -### Reproducciones de sesión{#session-replays} +### Reproducciones de sesiones {#session-replays} -Mire [grabaciones de navegador][12] de usuarios reales interactuando con su sitio web y establezca [controles de privacidad][13] para su organización. +Vea [browser recordings][12] de usuarios reales interactuando con su sitio web y establezca [privacy controls][13] para su organización. -### Herramientas para desarrolladores{#developer-tools} +### Developer Tools {#developer-tools} -Acceda a los registros, errores e información de rendimiento al solucionar problemas de la aplicación utilizando [Browser Dev Tools][14]. +Acceda a registros, errores e información de rendimiento activados al solucionar problemas de la aplicación mediante [Browser Dev Tools][14]. ## Permisos {#permissions} -Por defecto, todos los usuarios pueden cambiar la configuración de RUM de una aplicación. +De forma predeterminada, todos los usuarios pueden cambiar la configuración de RUM de una aplicación. Utilice controles de acceso granulares para limitar los [roles][18] que pueden editar la configuración de RUM de una aplicación en particular: -1. Mientras visualiza la configuración de RUM de una aplicación, haga clic en el botón **Editar aplicación** en la parte superior de la pantalla. Aparece un menú desplegable. -1. Seleccione **Administrar permisos de la aplicación**. -1. Haga clic en **Restringir acceso**. -1. El cuadro de diálogo se actualiza para mostrar que los miembros de su organización tienen **[Viewer]** acceso por defecto. -1. Utilice el menú desplegable para seleccionar uno o más roles, equipos o usuarios que pueden editar el notebook. -1. Haga clic en **Agregar**. -1. El cuadro de diálogo se actualiza para mostrar que el rol que seleccionó tiene el permiso de **Editor**. -1. Haga clic en **Guardar**. +1. Mientras visualiza la configuración de RUM de una aplicación, haga clic en el botón {{< ui >}}Edit application{{< /ui >}} en la parte superior de la pantalla. Aparece un menú desplegable. +1. Seleccione {{< ui >}}Manage App Permissions{{< /ui >}}. +1. Haga clic en {{< ui >}}Restrict Access{{< /ui >}}. +1. El cuadro de diálogo se actualiza para mostrar que los miembros de su organización tienen acceso {{< ui >}}Viewer{{< /ui >}} de forma predeterminada. +1. Utilice el menú desplegable para seleccionar uno o más roles, equipos o usuarios que puedan editar el notebook. +1. Haga clic en {{< ui >}}Add{{< /ui >}}. +1. El cuadro de diálogo se actualiza para mostrar que el rol que seleccionó tiene el permiso {{< ui >}}Editor{{< /ui >}}. +1. Haga clic en {{< ui >}}Save{{< /ui >}}. -**Nota:** Para mantener su acceso de edición a la aplicación, el sistema requiere que incluya al menos un rol del cual sea miembro antes de guardar. +**Nota:** Para mantener su acceso de edición a la aplicación, el sistema requiere que incluya al menos un rol del cual usted sea miembro antes de guardar. Debe tener acceso de edición para restaurar el acceso general a una aplicación restringida. Complete los siguientes pasos: -1. Mientras visualiza la configuración de RUM de una aplicación, haga clic en el botón **Editar aplicación** en la parte superior de la pantalla. Aparece un menú desplegable. -1. Seleccione **Administrar permisos de la aplicación**. -1. Haga clic en **Restaurar acceso completo**. -1. Haga clic en **Guardar**. +1. Mientras visualiza la configuración de RUM de una aplicación, haga clic en el botón {{< ui >}}Edit application{{< /ui >}} en la parte superior de la pantalla. Aparece un menú desplegable. +1. Seleccione {{< ui >}}Manage App Permissions{{< /ui >}}. +1. Haga clic en {{< ui >}}Restore Full Access{{< /ui >}}. +1. Haga clic en {{< ui >}}Save{{< /ui >}}. -## Lectura adicional{#further-reading} +## Lecturas adicionales {#further-reading} {{< partial name="whats-next/whats-next.html" >}} @@ -279,9 +302,12 @@ Debe tener acceso de edición para restaurar el acceso general a una aplicación [10]: /es/real_user_monitoring/application_monitoring/ios/web_view_tracking/ [11]: /es/real_user_monitoring/application_monitoring/android/web_view_tracking/ [12]: /es/session_replay/browser/ -[13]: /es/session_replay/browser/privacy_options/ -[14]: /es/session_replay/browser/dev_tools/ +[13]: /es/session_replay/privacy_options?platform=browser +[14]: /es/session_replay/dev_tools [15]: /es/real_user_monitoring/application_monitoring/browser/setup/ [16]: /es/real_user_monitoring/application_monitoring/ [17]: https://app.datadoghq.com/rum/optimization/inspect -[18]: /es/account_management/rbac/ \ No newline at end of file +[18]: /es/account_management/rbac/ +[19]: /es/real_user_monitoring/correlate_with_other_telemetry/profiling +[20]: /es/real_user_monitoring/guide/proxy-rum-data +[21]: /es/integrations/content_security_policy_logs \ No newline at end of file diff --git a/hugo/content/es/security/application_security/setup/aws/fargate/_index.md b/hugo/content/es/security/application_security/setup/aws/fargate/_index.md new file mode 100644 index 00000000000..b2353335e34 --- /dev/null +++ b/hugo/content/es/security/application_security/setup/aws/fargate/_index.md @@ -0,0 +1,46 @@ +--- +disable_sidebar: true +further_reading: +- link: /security/application_security/ + tag: Documentación + text: Protéjase contra amenazas con la protección de aplicaciones y API de Datadog +- link: /security/application_security/add-user-info/ + tag: Documentación + text: Seguimiento de la actividad del usuario +- link: /security/default_rules/?category=cat-application-security + tag: Documentación + text: Reglas de protección de aplicaciones y API listas para usar +- link: /security/application_security/troubleshooting + tag: Documentación + text: Solución de problemas de protección de aplicaciones y API +- link: /security/application_security/how-it-works/ + tag: Documentación + text: Cómo funciona la protección de aplicaciones y API en Datadog +title: Configuración de la protección de aplicaciones y API en AWS Fargate +--- +{{< site-region region="gov" >}} +
+App and API Protection se encuentra en versión preliminar en el sitio de Datadog Government US1-FED. +
+{{< /site-region >}} + +Aprenda a configurar la protección de aplicaciones y API (AAP) en sus tareas de AWS Fargate seleccionando el lenguaje de programación de su tarea. + +
+

¿No encuentra su entorno?

+ Envíenos una solicitud para el entorno que falta aquí. +
+ +{{< appsec-integrations >}} + {{< appsec-integration name="Python" avatar="python" link="/security/application_security/setup/python/aws-fargate" >}} + {{< appsec-integration name="Node.js" avatar="node" link="/security/application_security/setup/nodejs/aws-fargate" >}} + {{< appsec-integration name="Java" avatar="java" link="/security/application_security/setup/java/aws-fargate" >}} + {{< appsec-integration name="Go" avatar="go" link="/security/application_security/setup/go/aws-fargate" >}} + {{< appsec-integration name="Ruby" avatar="ruby" link="/security/application_security/setup/ruby/aws-fargate" >}} + {{< appsec-integration name=".NET" avatar="dotnet" link="/security/application_security/setup/dotnet/aws-fargate" >}} + {{< appsec-integration name="PHP" avatar="php" link="/security/application_security/setup/php/aws-fargate" >}} +{{< /appsec-integrations >}} + +## Lecturas adicionales {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} \ No newline at end of file diff --git a/hugo/content/es/security/application_security/setup/gcp/cloud-run/_index.md b/hugo/content/es/security/application_security/setup/gcp/cloud-run/_index.md index a31980b00e8..5ece8f5dc91 100644 --- a/hugo/content/es/security/application_security/setup/gcp/cloud-run/_index.md +++ b/hugo/content/es/security/application_security/setup/gcp/cloud-run/_index.md @@ -3,28 +3,32 @@ disable_sidebar: true further_reading: - link: /security/application_security/ tag: Documentación - text: Protégete contra las amenazas con la protección de aplicaciones y API de Datadog + text: Proteja contra amenazas con Datadog App and API Protection - link: /security/application_security/add-user-info/ tag: Documentación - text: Seguimiento de la actividad de los usuarios + text: Seguimiento de la actividad del usuario - link: /security/default_rules/?category=cat-application-security tag: Documentación - text: Reglas de protección de aplicaciones y API predefinidas + text: Reglas predefinidas de App and API Protection - link: /security/application_security/troubleshooting tag: Documentación - text: Solución de problemas de protección de aplicaciones y API + text: Resolución de problemas de App and API Protection - link: /security/application_security/how-it-works/ tag: Documentación - text: Cómo funciona la protección de aplicaciones y API en Datadog -title: Configuración de las funciones de protección de aplicaciones y API en Google - Cloud Run + text: Cómo funciona App and API Protection en Datadog +title: Configurar App and API Protection en funciones de Google Cloud Run --- +{{< site-region region="gov" >}} +
+App and API Protection se encuentra en versión preliminar en el sitio de Datadog Government US1-FED. +
+{{< /site-region >}} -Aprende a configurar la protección de aplicaciones y API (AAP) en tus funciones de Google Cloud Run seleccionando el lenguaje de programación con el que está escrita tu función. +Aprenda cómo configurar App and API Protection (AAP) en sus funciones de Google Cloud Run seleccionando el lenguaje de programación con el que está escrita su función.
-

¿Te falta tu entorno?

- Envíanos una solicitud para tu entorno faltante aquí. +

¿Le falta su entorno?

+ Envíenos una solicitud para su entorno faltante aquí.
{{< appsec-integrations >}} @@ -37,6 +41,6 @@ Aprende a configurar la protección de aplicaciones y API (AAP) en tus funciones {{< appsec-integration name="PHP" avatar="php" link="./php" >}} {{< /appsec-integrations >}} -## 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/security/application_security/setup/kubernetes/_index.md b/hugo/content/es/security/application_security/setup/kubernetes/_index.md new file mode 100644 index 00000000000..afb29599975 --- /dev/null +++ b/hugo/content/es/security/application_security/setup/kubernetes/_index.md @@ -0,0 +1,44 @@ +--- +disable_sidebar: true +further_reading: +- link: /security/application_security/ + tag: Documentación + text: Protéjase contra amenazas con Datadog App and API Protection +- link: /security/application_security/add-user-info/ + tag: Documentación + text: Seguimiento de la actividad del usuario +- link: /security/default_rules/?category=cat-application-security + tag: Documentación + text: Reglas OOTB de App and API Protection +- link: /security/application_security/troubleshooting + tag: Documentación + text: Solución de problemas de App and API Protection +- link: /security/application_security/how-it-works/ + tag: Documentación + text: Cómo funciona App and API Protection en Datadog +title: Configure App and API Protection en Kubernetes +--- +{{< site-region region="gov" >}} +
+App and API Protection se encuentra en versión preliminar en el sitio de Datadog Government US1-FED. +
+{{< /site-region >}} + +Aprenda a configurar App and API Protection (AAP) en sus clústeres de Kubernetes seleccionando la integración de Kubernetes que mejor se adapte a sus necesidades. + +
+

¿No encuentra su entorno?

+ Envíenos una solicitud para su entorno faltante aquí. +
+ +{{< appsec-integrations >}} + {{< appsec-integration name="Istio" avatar="istio" link="./istio" >}} + {{< appsec-integration name="Envoy Gateway" avatar="envoy" link="./envoy-gateway" >}} + {{< appsec-integration name="Gateway API" src="integrations_logos/gateway-api_avatar.svg" link="./gateway-api" >}} + {{< appsec-integration name="Ingress NGINX Controller" avatar="nginx" link="../nginx/ingress-controller" >}} + {{< appsec-integration name="Google Kubernetes Engine (GKE)" src="integrations_logos/google_kubernetes_engine.png" link="./gke" >}} +{{< /appsec-integrations >}} + +## Lecturas adicionales {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} \ No newline at end of file diff --git a/hugo/content/es/security/application_security/setup/macos/_index.md b/hugo/content/es/security/application_security/setup/macos/_index.md new file mode 100644 index 00000000000..742984bf4b2 --- /dev/null +++ b/hugo/content/es/security/application_security/setup/macos/_index.md @@ -0,0 +1,46 @@ +--- +disable_sidebar: true +further_reading: +- link: /security/application_security/ + tag: Documentación + text: Protéjase contra amenazas con Datadog App and API Protection +- link: /security/application_security/add-user-info/ + tag: Documentación + text: Seguimiento de la actividad del usuario +- link: /security/default_rules/?category=cat-application-security + tag: Documentación + text: Reglas OOTB de App and API Protection +- link: /security/application_security/troubleshooting + tag: Documentación + text: Solución de problemas de App and API Protection +- link: /security/application_security/how-it-works/ + tag: Documentación + text: Cómo funciona App and API Protection en Datadog +title: Configurar App and API Protection en macOS +--- +{{< site-region region="gov" >}} +
+App and API Protection se encuentra en versión preliminar en el sitio de Datadog Government US1-FED. +
+{{< /site-region >}} + +Aprenda a configurar App and API Protection (AAP) en sus servicios de macOS seleccionando el lenguaje de programación del servicio. + +
+

¿No encuentra su entorno?

+ Envíenos una solicitud para su entorno faltante aquí. +
+ +{{< appsec-integrations >}} + {{< appsec-integration name="Python" avatar="python" link="/security/application_security/setup/python/macos" >}} + {{< appsec-integration name="Node.js" avatar="node" link="/security/application_security/setup/nodejs/macos" >}} + {{< appsec-integration name="Java" avatar="java" link="/security/application_security/setup/java/macos" >}} + {{< appsec-integration name="Go" avatar="go" link="/security/application_security/setup/go/" >}} + {{< appsec-integration name="Ruby" avatar="ruby" link="/security/application_security/setup/ruby/macos" >}} + {{< appsec-integration name=".NET" avatar="dotnet" link="/security/application_security/setup/dotnet" >}} + {{< appsec-integration name="PHP" avatar="php" link="/security/application_security/setup/php" >}} +{{< /appsec-integrations >}} + +## Lecturas adicionales {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} \ No newline at end of file diff --git a/hugo/content/es/security/cloud_siem/guide/ingest-stix-threat-intelligence.md b/hugo/content/es/security/cloud_siem/guide/ingest-stix-threat-intelligence.md new file mode 100644 index 00000000000..05efc58ae3e --- /dev/null +++ b/hugo/content/es/security/cloud_siem/guide/ingest-stix-threat-intelligence.md @@ -0,0 +1,234 @@ +--- +description: Envíe su propia inteligencia de amenazas a Cloud SIEM como paquetes STIX + 2.1. Cubre el punto de conexión de ingesta, la autenticación, los tipos y patrones + de indicadores admitidos, las tablas de referencia que Datadog genera para cada + tipo de indicador y cómo configurarlas o eliminarlas. +disable_toc: false +further_reading: +- link: /security/cloud_siem/ingest_and_enrich/threat_intelligence/ + tag: Documentación + text: Traiga su propia inteligencia de amenazas a Cloud SIEM +- link: /security/threat_intelligence/ + tag: Documentación + text: Inteligencia de amenazas en Datadog Security +- link: /security/cloud_siem/triage_and_investigate/ioc_explorer/ + tag: Documentación + text: Investigue indicadores con el explorador de IOC +- link: /reference_tables/ + tag: Documentación + text: Cree y administre tablas de referencia +title: Ingiera inteligencia de amenazas STIX +--- +## Descripción general {#overview} + +Si su organización mantiene inteligencia de amenazas en una Plataforma de Inteligencia de Amenazas (TIP), puede enviarla a Cloud SIEM como paquetes [STIX 2.1][1]. Cloud SIEM utiliza los indicadores ingeridos para [enriquecer sus registros][2] y los muestra en el [Explorador de IOC][3]. + +Utilice la ingesta STIX cuando su plataforma ya produzca STIX, o cuando desee que un script o trabajo programado envíe actualizaciones incrementales. Para cargar indicadores como archivos CSV o sincronizarlos desde el almacenamiento en la nube, consulte [Bring your own threat intelligence to Cloud SIEM][2]. + +## Cómo funciona {#how-it-works} + +Después de enviar un paquete STIX 2.1 al [punto de conexión de ingesta](#send-indicators), Datadog lo procesa de la siguiente manera. No se requiere configuración previa en Datadog. + +1. Datadog identifica la fuente a partir del encabezado `ti_vendor` requerido. +2. Datadog genera una [tabla de referencia][4] para cada tipo de indicador en su fuente, llamada `threat_intel_stix__`. Debido a que un paquete puede contener varios tipos de indicadores, una sola solicitud puede completar varias tablas. +3. Datadog registra cada tabla generada y la habilita automáticamente para el enriquecimiento de Cloud SIEM. +4. Las solicitudes posteriores para la misma `ti_vendor` actualizan las tablas existentes y conservan las opciones de configuración que realice. + +Por ejemplo, una fuente enviada con `ti_vendor: acme` que contiene indicadores de dirección IP, dominio y SHA-256 produce las siguientes tablas: + +| Tipo de indicador | Tabla de referencia generada | +|---|---| +| Dirección IP | `threat_intel_stix_acme_ip_address` | +| Dominio | `threat_intel_stix_acme_domain` | +| Hash de archivo SHA-256 | `threat_intel_stix_acme_sha256` | + +Las tablas estarán disponibles unos minutos después de su primera solicitud. El enriquecimiento se aplica a los logs que Cloud SIEM recibe después de habilitar una tabla, por lo que no se aplica a los logs recibidos anteriormente. + +## Requisitos previos {#prerequisites} + +- Cloud SIEM está habilitado para su organización. +- Una [API key][5] de Datadog y una [clave de aplicación][6]. La clave de aplicación debe tener el permiso de escritura en tablas de referencia. + +## Enviar indicadores {#send-indicators} + +`POST https://api.{{< region-param key="dd_site" >}}/api/v2/security/threat-intel/stix` + +
La URL del punto de conexión varía según el sitio. Utilice el sitio de Datadog correcto para su organización.
+ +### Encabezados {#headers} + +| Encabezado | Requerido | Descripción | +|---|---|---| +| `DD-API-KEY` | Sí | Su clave de API de Datadog. | +| `DD-APPLICATION-KEY` | Sí | Una clave de aplicación con el permiso de escritura en tablas de referencia. | +| `ti_vendor` | Sí | Identifica la fuente; por ejemplo, el nombre de su plataforma. Utilice 10 caracteres o menos, solo con letras minúsculas y dígitos. | +| `Content-Type` | Sí | `application/json` | +| `Content-Encoding` | No | Establecer en `gzip` para enviar un cuerpo comprimido. No se admiten otras codificaciones. | + +### Cuerpo de la solicitud {#request-body} + +El cuerpo es un `bundle` de STIX 2.1 de objetos STIX. Cada solicitud es un lote incremental, y un paquete puede mezclar indicadores de diferentes tipos. + +```json +{ + "type": "bundle", + "id": "bundle--0cde353c-ea5b-4668-9f68-9c3a0e2a0a0e", + "objects": [ + { + "type": "indicator", + "spec_version": "2.1", + "id": "indicator--a932fcc6-e032-476c-826f-cb970a5a1fff", + "pattern_type": "stix", + "pattern": "[ipv4-addr:value = '198.51.100.1']", + "indicator_types": ["malicious-activity"], + "valid_from": "2026-01-01T00:00:00Z", + "valid_until": "2026-12-31T00:00:00Z" + } + ] +} +``` + +El punto de conexión tiene los siguientes requisitos y límites: + +- El paquete debe ser STIX 2.1. Si el paquete contiene un `spec_version` distinto de `2.1`, Datadog rechaza la solicitud. Si un objeto individual contiene un `spec_version` distinto de `2.1`, Datadog omite ese objeto. +- El tamaño máximo del cuerpo de la solicitud es de 50 MB. + +### Tipos de indicadores y patrones admitidos {#supported-indicator-types-and-patterns} + +Datadog lee el `pattern` de STIX en cada indicador para determinar su tipo y valor. Cloud SIEM ingiere direcciones IP (tanto IPv4 como IPv6), dominios y hashes de archivo SHA-256. + +Datadog extrae valores exactos de las comparaciones `=` y `IN`. También acepta expresiones `OR` e importa cada valor como un indicador independiente. `AND` entre expresiones entre corchetes no es compatible. + +```json +"pattern": "[ipv4-addr:value = '198.51.100.1'] OR [domain-name:value IN ('example.com', 'example.net')]" +``` + +Los patrones que utilizan negación, rangos, coincidencia con comodines, coincidencia con expresiones regulares, relaciones de subred, verificaciones de existencia, calificadores temporales o `FOLLOWEDBY` no son compatibles. Si alguna parte de un patrón utiliza una expresión no compatible, Datadog omite el objeto indicador. + +La respuesta cuenta los objetos no compatibles como `unsupported` y los patrones que no se pueden analizar como `invalid`. Verifique estos conteos para confirmar cuánto de su fuente se ingirió. + +### Cómo se asignan los campos STIX a las columnas de la tabla de referencia {#how-stix-fields-map-to-reference-table-columns} + +| Columna de la tabla de referencia | Completada desde | +|---|---| +| Valor del indicador | El valor extraído del `pattern` del indicador. | +| `intention` | El campo `indicator_types`. `malicious-activity` se asigna a `malicious`; `benign` se asigna a `benign`; y cualquier otro valor, o un campo ausente, se asigna a `suspicious`. | +| `source` | El encabezado `ti_vendor`, almacenado como `{"name": ""}`. | +| `category` | Establecer en `custom`. | +| `additional_data` | Los campos STIX que no tienen una columna dedicada, incluidos `stix_id`, `created`, `modified`, `valid_from`, `confidence`, `labels`, `indicator_types`, `object_marking_refs`, `kill_chain_phases` y `external_references`. | + +El campo opcional `valid_until` establece una caducidad para el indicador, y Datadog elimina el indicador después de ese tiempo. Un indicador enviado sin `valid_until` no caduca automáticamente. + +### Actualizar y revocar indicadores {#update-and-revoke-indicators} + +- Para actualizar los detalles de un indicador, envíe el indicador nuevamente con los campos actualizados. Datadog sobrescribe la fila existente para ese valor de indicador. +- Para eliminar un indicador, envíelo con `"revoked": true`. Datadog elimina el indicador de la tabla de referencia. + +Enviar el mismo paquete más de una vez no crea filas duplicadas. + +### Respuesta {#response} + +Una solicitud exitosa devuelve `200 OK` y un resumen de cómo Datadog procesó el paquete: + +```json +{ + "data": { + "type": "threat-intel-stix-ingest", + "id": "acme", + "attributes": { + "accepted": 3, + "unsupported": 1, + "invalid": 0 + } + } +} +``` + +| Atributo | Descripción | +|---|---| +| `accepted` | La cantidad de objetos de indicador admitidos que Datadog aceptó para su procesamiento. Este conteo incluye nuevos indicadores, actualizaciones y revocaciones. Un objeto puede producir más de un indicador cuando su patrón utiliza `IN` o `OR`. | +| `unsupported` | La cantidad de objetos indicadores que Datadog omitió porque su tipo, patrón o versión de STIX a nivel de objeto no es compatible. | +| `invalid` | La cantidad de objetos indicadores cuyo patrón Datadog no pudo analizar. | + +Una respuesta `200` significa que Datadog aceptó el paquete. Los indicadores no compatibles e inválidos aparecen en estos conteos en lugar de causar que la solicitud falle. Verifique los conteos para confirmar que su fuente se ingirió como se esperaba. + +### Ejemplo de solicitud {#example-request} + +```shell +curl -X POST "https://api.{{< region-param key="dd_site" code="true" >}}/api/v2/security/threat-intel/stix" \ + --header "DD-API-KEY: " \ + --header "DD-APPLICATION-KEY: " \ + --header "Content-Type: application/json" \ + --header "ti_vendor: acme" \ + --data '{ + "type": "bundle", + "id": "bundle--0cde353c-ea5b-4668-9f68-9c3a0e2a0a0e", + "objects": [ + { + "type": "indicator", + "spec_version": "2.1", + "id": "indicator--a932fcc6-e032-476c-826f-cb970a5a1fff", + "pattern_type": "stix", + "pattern": "[ipv4-addr:value = '198.51.100.1']", + "indicator_types": ["malicious-activity"], + "valid_from": "2026-01-01T00:00:00Z" + } + ] + }' +``` + +Para enviar una fuente grande de manera más eficiente, comprima el cuerpo y establezca `Content-Encoding: gzip`. + +### Límites de tasa {#rate-limits} + +El punto de conexión acepta 10 solicitudes por segundo para cada clave de API. Las solicitudes que exceden ese límite reciben una respuesta `429 Too Many Requests`. + +### Respuestas de error {#error-responses} + +| Estado | Motivo | +|---|---| +| `400 Bad Request` | El cuerpo no es un JSON válido, el paquete contiene un `spec_version` distinto de `2.1`, falta el encabezado `ti_vendor` o no es válido, o el `Content-Encoding` no es compatible. | +| `401 Unauthorized` | La solicitud no contiene credenciales válidas. | +| `403 Forbidden` | La clave de aplicación no tiene el permiso de escritura en tablas de referencia. | +| `413 Request Entity Too Large` | El cuerpo de la solicitud es mayor a 50 MB. | +| `429 Too Many Requests` | La solicitud excedió el límite de tasa para la clave de API. | + +## Configure las tablas de referencia generadas {#configure-the-generated-reference-tables} + +Administre las tablas que genera la ingesta en la página de configuración de [Threat Intelligence][7]. Cada tabla tiene un interruptor que controla si Cloud SIEM la utiliza para enriquecer los registros. Utilice esa página para revisar qué fuentes están activas, para deshabilitar una fuente temporalmente o para habilitar una tabla que la ingesta dejó deshabilitada. + +Sus configuraciones de enriquecimiento tienen prioridad sobre la ingesta. Después de que existe una tabla, las solicitudes posteriores agregan y actualizan indicadores, pero nunca cambian el interruptor de enriquecimiento. Una tabla que usted deshabilita permanece deshabilitada hasta que la habilite de nuevo. + +La ingesta de STIX administra las filas en las tablas de referencia generadas. Los cambios manuales en esas filas no se conservan y se sobrescriben mediante solicitudes de ingesta posteriores. Para agregar, actualizar o eliminar indicadores, envíe los cambios a través del punto de conexión de ingesta de STIX. + +Para inspeccionar los indicadores ingeridos, abra la tabla desde [Reference Tables][8] o busque los indicadores en el [IOC Explorador][3]. + +### Si alcanza el límite de tablas de referencia {#if-you-reach-the-reference-table-limit} + +Cloud SIEM enriquece los registros con hasta 10 tablas de referencia de inteligencia de amenazas a la vez. Si la ingesta genera una tabla mientras su organización ya alcanzó ese límite, Datadog crea y completa la tabla de todos modos. No habilita la tabla para el enriquecimiento automáticamente, y la tabla aparece en la página [Threat Intelligence][7] en un estado deshabilitado. + +Para habilitar dicha tabla, deshabilite una tabla que ya no necesite en la página [Threat Intelligence][7] y luego habilite la nueva. + +## Deje de ingerir una fuente {#stop-ingesting-a-feed} + +Sus solicitudes dirigen la ingesta, por lo que eliminar una fuente requiere dos pasos, en este orden: + +1. Deje de enviar paquetes para esa `ti_vendor`. +2. Elimine las tablas de referencia que Datadog generó para la fuente desde [Reference Tables][8]. + +Complete los pasos en ese orden. Si elimina una tabla mientras siguen llegando solicitudes para la misma `ti_vendor`, la siguiente solicitud genera la tabla nuevamente. + +Para dejar de enriquecer registros sin eliminar nada, deshabilite las tablas en la página de [Threat Intelligence][7] en su lugar. Esto mantiene los indicadores ingeridos disponibles para el IOC Explorador y le permite reanudar el enriquecimiento más tarde. + +## Lecturas adicionales {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://docs.oasis-open.org/cti/stix/v2.1/os/stix-v2.1-os.html +[2]: /es/security/cloud_siem/ingest_and_enrich/threat_intelligence/ +[3]: /es/security/cloud_siem/triage_and_investigate/ioc_explorer/ +[4]: /es/reference_tables/ +[5]: /es/account_management/api-app-keys/#api-keys +[6]: /es/account_management/api-app-keys/#application-keys +[7]: https://app.datadoghq.com/security/configuration/threat-intel +[8]: https://app.datadoghq.com/reference-tables \ No newline at end of file diff --git a/hugo/content/es/security/code_security/static_analysis/setup/_index.md b/hugo/content/es/security/code_security/static_analysis/setup/_index.md index 3f94c7eefdd..f2ec766dfb7 100644 --- a/hugo/content/es/security/code_security/static_analysis/setup/_index.md +++ b/hugo/content/es/security/code_security/static_analysis/setup/_index.md @@ -10,11 +10,11 @@ aliases: - /es/static_analysis - /es/security/code_security/static_analysis/circleci_orbs/ - /es/code_analysis/static_analysis/setup/ -description: Aprenda sobre el Análisis de Código Estático de Datadog para escanear - el código en busca de problemas de calidad y vulnerabilidades de seguridad antes - de que su código llegue a producción. +description: Conozca Datadog Static Code Analysis para escanear el código en busca + de problemas de calidad y vulnerabilidades de seguridad antes de que su código llegue + a producción. is_beta: false -title: Configure el Análisis de Código Estático (SAST) +title: Configure Datadog Static Code Analysis (SAST) --- {{% site-region region="gov,gov2" %}}
@@ -23,43 +23,44 @@ title: Configure el Análisis de Código Estático (SAST) {{% /site-region %}} ## Descripción general {#overview} -Para configurar SAST de Datadog en la aplicación, navegue a [**Seguridad** > **Code Security**][1]. +Para configurar Datadog SAST en la aplicación, navegue a [{{< ui >}}Security{{< /ui >}} > {{< ui >}}Code Security{{< /ui >}}][1]. -## Seleccione dónde ejecutar los escaneos de Análisis de Código Estático {#select-where-to-run-static-code-analysis-scans} -### Escanear con escaneo alojado en Datadog {#scan-with-datadog-hosted-scanning} +## Seleccione dónde ejecutar los escaneos de Datadog Static Code Analysis {#select-where-to-run-static-code-analysis-scans} +### Analizar con escaneo alojado por Datadog {#scan-with-datadog-hosted-scanning} -Puede ejecutar escaneos de Análisis de Código Estático (SAST) de Datadog directamente en la infraestructura de Datadog. Los tipos de repositorios compatibles incluyen: +Puede ejecutar escaneos de Datadog Static Code Analysis (SAST) directamente en la infraestructura de Datadog. Los tipos de repositorio admitidos incluyen: - [GitHub][18] (excluyendo repositorios que utilizan [Git Large File Storage][17]) -- [GitLab.com and GitLab Self-Managed][20] +- [GitLab.com y GitLab Self-Managed][20] - [Azure DevOps][19] +- [Bitbucket Cloud][21] -Para comenzar, navegue a la página de [**Code Security**][1]. +Para comenzar, navegue a la [{{< ui >}}Code Security{{< /ui >}} página][1]. -### Escanear en pipelines de CI {#scan-in-ci-pipelines} -El Análisis de Código Estático de Datadog se ejecuta en sus pipelines de CI utilizando el [`datadog-ci` CLI][8]. +### Analizar en pipelines de CI {#scan-in-ci-pipelines} +Datadog Static Code Analysis se ejecuta en sus pipelines de CI utilizando la [`datadog-ci` CLI][8]. -Primero, configure sus claves de API y de aplicación de Datadog. Agregue `DD_APP_KEY` y `DD_API_KEY` como secretos. Por favor, asegúrese de que su clave de aplicación de Datadog tenga el `code_analysis_read` contexto. +Primero, configure su Datadog API y sus claves de aplicación. Agregue `DD_APP_KEY` y `DD_API_KEY` como secretos. Por favor, asegúrese de que su clave de aplicación de Datadog tenga el contexto `code_analysis_read`. -A continuación, ejecute el Análisis de Código Estático siguiendo las instrucciones para su proveedor de CI elegido a continuación. +A continuación, ejecute Datadog Static Code Analysis siguiendo las instrucciones para el proveedor de CI que eligió a continuación. -{{< whatsnext desc="Vea las instrucciones según su proveedor de CI:">}} +{{< whatsnext desc="Consulte las instrucciones según su proveedor de CI:">}} {{< nextlink href="security/code_security/static_analysis/setup/github_actions" >}}GitHub Actions{{< /nextlink >}} - {{< nextlink href="security/code_security/static_analysis/setup/generic_ci_providers" >}}Proveedores de CI Genéricos{{< /nextlink >}} + {{< nextlink href="security/code_security/static_analysis/setup/generic_ci_providers" >}}Proveedores de CI genéricos{{< /nextlink >}} {{< /whatsnext >}} ## Seleccione su proveedor de gestión de código fuente {#select-your-source-code-management-provider} -El Análisis de Código Estático de Datadog es compatible con todos los proveedores de gestión de código fuente, con soporte nativo para GitHub, GitLab y Azure DevOps. +Datadog Static Code Analysis es compatible con todos los proveedores de gestión de código fuente, con soporte nativo para GitHub, GitLab, Azure DevOps y Bitbucket Cloud Premium. {{< tabs >}} {{% tab "GitHub" %}} -Configure una GitHub App con el [GitHub integration tile][1] y configure la [integración de código fuente][2] para habilitar fragmentos de código en línea y [comentarios de solicitudes de extracción][3]. +Configure una aplicación de GitHub con el [mosaico de integración de GitHub][1] y configure la [integración del código fuente][2] para habilitar fragmentos de código en línea y [comentarios en solicitudes de extracción][3]. -Al instalar una Aplicación de GitHub, se requieren los siguientes permisos para habilitar ciertas funciones: +Al instalar una aplicación de GitHub, se requieren los siguientes permisos para habilitar ciertas funciones: - `Content: Read`, que le permite ver fragmentos de código mostrados en Datadog -- `Pull Request: Read & Write`, que permite a Datadog agregar comentarios sobre violaciones directamente en sus solicitudes de extracción utilizando [comentarios de solicitudes de extracción][3], así como abrir solicitudes de extracción para [corregir vulnerabilidades][4] -- `Checks: Read & Write`, que le permite crear verificaciones sobre violaciones de SAST para bloquear solicitudes de extracción +- `Pull Request: Read & Write`, que permite a Datadog agregar comentarios sobre infracciones directamente en sus solicitudes de extracción mediante [comentarios en solicitudes de extracción][3], así como abrir solicitudes de extracción para [corregir vulnerabilidades][4] +- `Checks: Read & Write`, que le permite crear comprobaciones en infracciones de SAST para bloquear solicitudes de extracción [1]: /es/integrations/github/#link-a-repository-in-your-organization-or-personal-account [2]: /es/integrations/guide/source-code-integration @@ -69,7 +70,7 @@ Al instalar una Aplicación de GitHub, se requieren los siguientes permisos para {{% /tab %}} {{% tab "GitLab" %}} -Vea las [instrucciones de configuración del código fuente de GitLab][1] para conectar repositorios de GitLab a Datadog. Se admiten tanto GitLab.com como instancias Self-Managed. +Consulte las [instrucciones de configuración del código fuente de GitLab][1] para conectar los repositorios de GitLab a Datadog. Se admiten tanto GitLab.com como las instancias autogestionadas. [1]: /es/integrations/gitlab-source-code/#setup @@ -86,33 +87,40 @@ Consulte las [instrucciones de configuración del código fuente de Azure][4] pa [4]: /es/integrations/azure-devops-source-code/#setup [5]: /es/getting_started/site/ +{{% /tab %}} +{{% tab "Bitbucket Cloud" %}} + +Consulte las [instrucciones de configuración del código fuente de Bitbucket][1] para conectar los espacios de trabajo de Bitbucket Cloud a Datadog. + +[1]: /es/integrations/bitbucket-source-code/#setup + {{% /tab %}} {{% tab "Otro" %}} -Si está utilizando otro proveedor de gestión de código fuente, configure el Análisis de Código Estático para ejecutarse en sus pipelines de CI utilizando la herramienta `datadog-ci` CLI y [ subir los resultados](#upload-third-party-static-analysis-results-to-datadog) a Datadog. -Usted **debe** ejecutar un análisis de su repositorio en la rama predeterminada antes de que los resultados puedan comenzar a aparecer en la página de **Code Security**. +Si utiliza otro proveedor de gestión de código fuente, configure Static Code Analysis para que se ejecute en sus pipelines de CI utilizando la herramienta CLI `datadog-ci` y [ cargue los resultados](#upload-third-party-static-analysis-results-to-datadog) a Datadog. +**Debe** ejecutar un análisis de su repositorio en la rama predeterminada antes de que los resultados puedan comenzar a aparecer en la página {{< ui >}}Code Security{{< /ui >}}. {{% /tab %}} {{< /tabs >}} ## Personalice su configuración {#customize-your-configuration} -Por defecto, el Análisis de Código Estático de Datadog (SAST) escanea sus repositorios con [los conjuntos de reglas predeterminados de Datadog][6] para cada lenguaje de programación. Puede personalizar qué conjuntos de reglas o reglas se ejecutan, junto con otros parámetros, en Datadog o en un `code-security.datadog.yaml` archivo. Para la referencia completa de configuración, consulte [Configuración del Análisis de Código Estático (SAST)][27]. +De forma predeterminada, Datadog Static Code Analysis (SAST) escanea sus repositorios con los [conjuntos de reglas predeterminados de Datadog][6] para cada lenguaje de programación. Puede personalizar qué conjuntos de reglas o reglas se ejecutan, junto con otros parámetros, en Datadog o en un archivo `code-security.datadog.yaml`. Para obtener la referencia de configuración completa, consulte [Configuración de análisis de código estático (SAST)][27]. -## Vincule hallazgos a los servicios y equipos de Datadog {#link-findings-to-datadog-services-and-teams} +## Vincule los hallazgos a los servicios y equipos de Datadog {#link-findings-to-datadog-services-and-teams} {{% security-products/link-findings-to-datadog-services-and-teams %}} -## Escaneo consciente de diferencias {#diff-aware-scanning} +## Escaneo con reconocimiento de diferencias {#diff-aware-scanning} -El escaneo consciente de diferencias permite que el analizador estático de Datadog solo escanee los archivos modificados por un commit en una rama de características. Acelera significativamente el tiempo de escaneo al no tener que ejecutar el análisis en cada archivo del repositorio para cada escaneo. Para habilitar el escaneo consciente de diferencias en su pipeline de CI, siga estos pasos: +El escaneo con reconocimiento de diferencias permite que el analizador estático de Datadog escanee solo los archivos modificados por una confirmación en una rama de funciones. Acelera significativamente el tiempo de escaneo al no ejecutar el análisis en cada archivo del repositorio para cada escaneo. Para habilitar el escaneo con reconocimiento de diferencias en su canalización de CI, siga estos pasos: -1. Asegúrese de que sus variables `DD_APP_KEY`, `DD_SITE` y `DD_API_KEY` estén configuradas en su pipeline de CI. -2. Agregue una llamada a `datadog-ci git-metadata upload` antes de invocar el analizador estático. Este comando asegura que los metadatos de Git estén disponibles para el backend de Datadog. Se requieren los metadatos de Git para calcular el número de archivos a analizar. -3. Asegúrese de que el analizador estático de datadog se invoque con la bandera `--diff-aware`. +1. Asegúrese de que sus variables `DD_APP_KEY`, `DD_SITE` y `DD_API_KEY` estén configuradas en su canalización de CI. +2. Agregue una llamada a `datadog-ci git-metadata upload` antes de invocar el analizador estático. Este comando garantiza que los metadatos de Git estén disponibles para el backend de Datadog. Los metadatos de Git son necesarios para calcular la cantidad de archivos a analizar. +3. Asegúrese de que datadog-static-analyzer se invoque con la bandera `--diff-aware`. -Ejemplo de secuencia de comandos (estos comandos deben ser invocados en su repositorio de Git): +Ejemplo de secuencia de comandos (estos comandos deben invocarse en su repositorio Git): ```bash datadog-ci git-metadata upload @@ -120,46 +128,46 @@ datadog-ci git-metadata upload datadog-static-analyzer -i /path/to/directory -g -o sarif.json -f sarif –-diff-aware <...other-options...> ``` -**Nota:** Cuando no se puede completar un escaneo consciente de diferencias, se escanea todo el directorio. +**Nota:** Cuando no se puede completar un escaneo que reconoce diferencias, se escanea todo el directorio. -## Suba los resultados del análisis estático de terceros a Datadog {#upload-third-party-static-analysis-results-to-datadog} +## Cargue resultados de análisis estático de terceros a Datadog {#upload-third-party-static-analysis-results-to-datadog}
- La importación de SARIF ha sido probada para Snyk, CodeQL, Semgrep, Gitleaks y Sysdig. Póngase en contacto con Soporte de Datadog si experimenta algún problema con otras herramientas compatibles con SARIF. + La importación de SARIF ha sido probada para Snyk, CodeQL, Semgrep, Gitleaks y Sysdig. Comuníquese con Soporte de Datadog si experimenta algún problema con otras herramientas compatibles con SARIF.
-Puede enviar resultados de herramientas de análisis estático de terceros a Datadog, siempre que estén en el formato interoperable [Formato de Intercambio de Resultados de Análisis Estático (SARIF)][2]. Se requiere la versión 14 o posterior de Node.js. +Puede enviar resultados de herramientas de análisis estático de terceros a Datadog, siempre que estén en el [Formato de intercambio de resultados de análisis estático (SARIF)][2] interoperable. Se requiere Node.js versión 14 o posterior. -Para subir un informe SARIF: +Para cargar un informe SARIF: 1. Asegúrese de que las variables [`DD_API_KEY` y `DD_APP_KEY` estén definidas][4]. -2. Opcionalmente, establezca una [`DD_SITE` variable][7] (esto tiene como valor predeterminado `datadoghq.com`). +2. Opcionalmente, establezca una [`DD_SITE` variable][7] (el valor predeterminado es `datadoghq.com`). 3. Instale la utilidad `datadog-ci`: ```bash npm install -g @datadog/datadog-ci ``` -4. Ejecute la herramienta de análisis estático de terceros en su código y genere los resultados en el formato SARIF. -5. Suba los resultados a Datadog: +4. Ejecute la herramienta de análisis estático de terceros en su código y genere los resultados en formato SARIF. +5. Cargue los resultados en Datadog: ```bash datadog-ci sarif upload $OUTPUT_LOCATION ``` -## Directrices de Soporte de SARIF {#sarif-support-guidelines} +## Pautas de soporte para SARIF {#sarif-support-guidelines} -Datadog admite la ingestión de archivos SARIF de terceros que son compatibles con [el esquema SARIF 2.1.0][15]. El SARIF -El esquema se utiliza de manera diferente por las herramientas de análisis estático. Si desea enviar archivos SARIF de terceros a Datadog, por favor +Datadog admite la ingesta de archivos SARIF de terceros que cumplan con [el esquema SARIF 2.1.0][15]. El SARIF +esquema es utilizado de manera diferente por las herramientas de análisis estático. Si desea enviar archivos SARIF de terceros a Datadog, por favor asegúrese de que cumplan con los siguientes detalles: - - La ubicación de la violación se especifica a través del objeto `physicalLocation` de un resultado. + - La ubicación de la infracción se especifica a través del objeto `physicalLocation` de un resultado. - El `artifactLocation` y su `uri` **deben ser relativos** a la raíz del repositorio. - El objeto `region` es la parte del código resaltada en la interfaz de usuario de Datadog. - - El `partialFingerprints` se utiliza para identificar de manera única un hallazgo en un repositorio. + - El `partialFingerprints` se utiliza para identificar de forma única un hallazgo en un repositorio. - `properties` y `tags` añaden más información: - La etiqueta `DATADOG_CATEGORY` especifica la categoría del hallazgo. Los valores aceptables son `SECURITY`, `PERFORMANCE`, `CODE_STYLE`, `BEST_PRACTICES`, `ERROR_PRONE`. - - Las violaciones anotadas con la categoría `SECURITY` se muestran en el explorador de vulnerabilidades y en la pestaña de seguridad de la vista del repositorio. + - Las infracciones anotadas con la categoría `SECURITY` se muestran en el explorador de vulnerabilidades y en la pestaña Security de la vista del repositorio. - La sección `tool` debe tener una sección `driver` válida con atributos `name` y `version`. Por ejemplo, aquí hay un ejemplo de un archivo SARIF procesado por Datadog: @@ -234,27 +242,27 @@ Por ejemplo, aquí hay un ejemplo de un archivo SARIF procesado por Datadog: } ``` -## Mapeo de severidad de SARIF a CVSS {#sarif-to-cvss-severity-mapping} +## Asignación de gravedad de SARIF a CVSS {#sarif-to-cvss-severity-mapping} -El [formato SARIF][15] define cuatro severidades: ninguna, nota, advertencia y error. -Sin embargo, Datadog informa sobre la severidad de violaciones y vulnerabilidades utilizando el [Sistema Común de Puntuación de Vulnerabilidades][16] (CVSS), -que define cinco severidades: crítica, alta, media, baja y ninguna. +El [formato SARIF][15] define cuatro gravedades: ninguna, nota, advertencia y error. +Sin embargo, Datadog informa la gravedad de las infracciones y vulnerabilidades utilizando el [Sistema de puntuación de vulnerabilidad común][16] (CVSS), +que define cinco gravedades: crítica, alta, media, baja y ninguna. -Al ingerir archivos SARIF, Datadog mapea las severidades de SARIF a las severidades de CVSS utilizando las reglas de mapeo a continuación. +Al ingerir archivos SARIF, Datadog asigna las gravedades de SARIF a las gravedades de CVSS utilizando las reglas de asignación a continuación. -| Severidad SARIF | Severidad CVSS | +| Gravedad SARIF | Gravedad CVSS | |----------------|---------------| -| Error | Crítica | +| Error | Crítico | | Advertencia | Alta | -| Nota | Medio | -| Ninguno | Bajo | +| Nota | Media | +| Ninguno | Baja | ## Retención de datos {#data-retention} -Datadog almacena hallazgos de acuerdo con nuestros [Períodos de retención de datos](https://docs.datadoghq.com/es/data_security/data_retention_periods/). Datadog no almacena ni retiene el código fuente del cliente. +Datadog almacena los hallazgos de acuerdo con nuestros [Periodos de retención de datos](https://docs.datadoghq.com/es/data_security/data_retention_periods/). Datadog no almacena ni conserva el código fuente del cliente. -## @@ -276,10 +284,11 @@ Datadog almacena hallazgos de acuerdo con nuestros [Períodos de retención de d [18]: /es/security/code_security/static_analysis/setup/?tab=github#select-your-source-code-management-provider [19]: /es/security/code_security/static_analysis/setup/?tab=azuredevops#select-your-source-code-management-provider [20]: /es/security/code_security/static_analysis/setup/?tab=gitlab#select-your-source-code-management-provider -[22]: https://docs.datadoghq.com/es/internal_developer_portal/software_catalog/entity_model/?tab=v30#migrating-to-v30 +[21]: /es/security/code_security/static_analysis/setup/?tab=bitbucketcloud#select-your-source-code-management-provider +[22]: https://docs.datadoghq.com/es/internal_developer_portal/catalog/entity_model/?tab=v30#migrating-to-v30 [24]: https://docs.datadoghq.com/es/account_management/teams/ [25]: https://github.com/DataDog/datadog-static-analyzer/blob/main/doc/legacy_config.md [27]: /es/security/code_security/static_analysis/configuration/ -[101]: https://docs.datadoghq.com/es/software_catalog/service_definitions/v3-0/ -[102]: https://docs.datadoghq.com/es/internal_developer_portal/software_catalog/entity_model/?tab=v30#codelocations +[101]: https://docs.datadoghq.com/es/internal_developer_portal/catalog/entity_model/ +[102]: https://docs.datadoghq.com/es/internal_developer_portal/catalog/entity_model/?tab=v30#codelocations [103]: https://docs.datadoghq.com/es/data_security/data_retention_periods/ \ No newline at end of file diff --git a/hugo/content/es/security/sensitive_data_scanner/guide/investigate_sensitive_data_findings.md b/hugo/content/es/security/sensitive_data_scanner/guide/investigate_sensitive_data_findings.md index ef81e5f2708..34bb5b50ba1 100644 --- a/hugo/content/es/security/sensitive_data_scanner/guide/investigate_sensitive_data_findings.md +++ b/hugo/content/es/security/sensitive_data_scanner/guide/investigate_sensitive_data_findings.md @@ -3,103 +3,128 @@ aliases: - /es/sensitive_data_scanner/investigate_sensitive_data_issues/ - /es/sensitive_data_scanner/guide/investigate_sensitive_data_issues/ - /es/security/sensitive_data_scanner/guide/investigate_sensitive_data_issues/ +description: Realice el triaje e investigue los hallazgos de Sensitive Data Scanner + en la página de Hallazgos, incluyendo el análisis de Blast Radius, los servicios + afectados, Case Management y la integración con Incident Management. further_reading: - link: sensitive_data_scanner/setup/telemetry_data/ tag: Documentación - text: Configurar Sensitive Data Scanner para datos de telemetría + text: Configure Sensitive Data Scanner para Datos de Telemetría - link: sensitive_data_scanner/setup/cloud_storage/ tag: Documentación - text: Configurar Sensitive Data Scanner para el almacenamiento en la nube + text: Configure Sensitive Data Scanner para Almacenamiento en la Nube - link: https://www.datadoghq.com/blog/scaling-sensitive-data-scanner/ tag: Blog - text: Descubre, clasifica y corrige los problemas de datos confidenciales a escala - con Sensitive Data Scanner. -title: Investigar los hallazgos de datos confidenciales + text: Descubra, clasifique y remedie problemas de datos confidenciales a escala + con Sensitive Data Scanner +title: Investigue los hallazgos de Sensitive Data Scanner --- +## Descripción general {#overview} -## Información general +Sensitive Data Scanner de Datadog puede ayudar a prevenir fugas de datos sensibles y limitar los riesgos de incumplimiento al identificar, clasificar y, opcionalmente, redactar datos sensibles. Cuando se encuentra un hallazgo de Sensitive Data Scanner, es posible que tenga las siguientes preguntas: -Sensitive Data Scanner de Datadog puede ayudar a evitar fugas de datos confidenciales y a limitar los riesgos de incumplimiento mediante la identificación, la clasificación y, opcionalmente, la redacción de los datos confidenciales. Cuando se encuentra un dato confidencial, pueden surgir las siguientes preguntas: +- ¿Qué datos sensibles han sido expuestos? +- ¿Cuál es la prioridad de la exposición de datos sensibles? +- ¿Qué tan grave es el hallazgo en términos de propagación y volumen? +- ¿De dónde provienen los datos sensibles? -- ¿Qué datos confidenciales se han expuesto? -- ¿Cuál es la prioridad de la exposición de datos confidenciales? -- ¿Cuál es la gravedad del hallazgo en términos de difusión y volumen? -- ¿De dónde proceden los datos confidenciales? +La página de [Hallazgos][1] de Sensitive Data Scanner categoriza y prioriza los hallazgos de datos sensibles para que usted pueda investigar, colaborar y documentar sus hallazgos, y responder a esas preguntas. -La page (página) [Hallazgos][1] de Sensitive Data Scanner categoriza y prioriza los hallazgos de datos confidenciales para que puedas investigar, colaborar y documentar tus hallazgos y responder a esas preguntas. +{{< img src="sensitive_data_scanner/sds_findings_explorer.png" alt="Explorador de hallazgos de Sensitive Data Scanner agrupado por regla, con la US Passport Scanner rule expandida para mostrar hallazgos críticos, conteos de coincidencias y gráficos de tendencias semanales." style="width:100%;" >}} -{{< img src="sensitive_data_scanner/findings_20251014.png" alt="La page (página) Hallazgos en la que se muestra la información general de los datos confidenciales desglosados por prioridad" style="width:100%;" >}} +## Realice el triaje de los hallazgos de datos sensibles {#triage-sensitive-data-findings} -## Triaje de los datos confidenciales - -Ve a la page (página) [Hallazgos][1] para ver todos los hallazgos de datos confidenciales en el período de tiempo seleccionado y empezar a investigarlos. +Navegue a la página de [Hallazgos][1] para ver todos los hallazgos de datos sensibles dentro del marco de tiempo seleccionado y comience a investigarlos. {{< tabs >}} -{{% tab "Datos de telemetría" %}} +{{% tab "Registros" %}} + +El explorador de hallazgos de registros es una experiencia actualizada para investigar hallazgos de registros. Si tiene al menos un hallazgo de registro, este explorador se abre de forma predeterminada. Los hallazgos de APM, RUM y Eventos no están disponibles en este explorador. Para ver esos hallazgos, haga clic en {{< ui >}}Go back{{< /ui >}} en el banner en la parte superior de la página. + +Para investigar un hallazgo de registro: + +1. Use {{< ui >}}Group by{{< /ui >}} para organizar los hallazgos por {{< ui >}}Rule{{< /ui >}}, {{< ui >}}Logs Pattern{{< /ui >}} o {{< ui >}}Service{{< /ui >}}. Para mostrar los hallazgos donde los datos sensibles están expuestos activamente, filtre por {{< ui >}}Leaking{{< /ui >}} en la faceta {{< ui >}}Match State{{< /ui >}}. +2. Haga clic en un hallazgo para abrir el panel de detalles. +3. En la parte superior del panel, verifique {{< ui >}}First Detected{{< /ui >}} y {{< ui >}}Last Detected{{< /ui >}} para comprender cuánto tiempo ha estado activa la exposición. +4. En la sección de resumen, revise {{< ui >}}Match State{{< /ui >}}, {{< ui >}}Service{{< /ui >}}, {{< ui >}}Environment{{< /ui >}} y {{< ui >}}Total matches{{< /ui >}} para comprender el alcance de la exposición. +5. Revise el {{< ui >}}Logs Pattern{{< /ui >}} para comprender el formato de la línea de registro donde se detectaron datos sensibles. +6. En la sección {{< ui >}}Example Logs{{< /ui >}}, revise hasta cinco ejemplos representativos de registros afectados. Cuando un registro de ejemplo caduca, se reemplaza por el siguiente evento coincidente. Haga clic en {{< ui >}}Show log{{< /ui >}} para expandir un ejemplo e inspeccionar su mensaje de registro, campos y atributos en línea. De forma predeterminada, los registros de ejemplo se almacenan durante 7 días y son accesibles para todos los usuarios con el permiso Data Scanner Read. Para almacenar estos registros representativos durante un período diferente, comuníquese con [Support][1]. +7. Revise {{< ui >}}Matches Trend{{< /ui >}} para ver cómo ha cambiado el volumen de coincidencias durante la última semana. Utilice {{< ui >}}Related Access and Configuration Events{{< /ui >}} para verificar si los eventos de acceso recientes o los cambios en el grupo de escaneo o en la regla de escaneo coinciden con los cambios en el volumen de coincidencias. + +Además, puede: +- Utilice {{< ui >}}Apply Targeted Obfuscation{{< /ui >}} para ofuscar futuras coincidencias de datos sensibles en nuevos registros para este hallazgo, o extienda la ofuscación a todo el servicio. Si la redacción ya está habilitada, utilice esta sección para verificar cómo se ofuscan los registros coincidentes. +- Utilice {{< ui >}}Tune Detection Logic{{< /ui >}} para editar las palabras clave de la regla de escaneo o aplicar supresiones para falsos positivos o datos con riesgo aceptado. +- Utilice {{< ui >}}Generate Code Fix{{< /ui >}} para iniciar una sesión de [Bits Code][2] que identifique el patrón de registro que causa la fuga y proponga una solución. Revise la solución y cree una solicitud de extracción directamente desde la sesión. El repositorio fuente ya debe estar integrado en Bits Code. + +[1]: /es/help +[2]: /es/bits_ai/bits_code/ + +{{% /tab %}} +{{% tab "APM, RUM y Eventos" %}} -En la pestaña **Sensitive Data Rule Findings** (Hallazgos de reglas de datos confidenciales), puedes filtrar tus hallazgos de datos confidenciales por estado de prioridad, estado de case (incidencia) y dominio. +En la pestaña {{< ui >}}Sensitive Data Rule Findings{{< /ui >}}, puede filtrar sus hallazgos de datos sensibles por estado de prioridad, estado de la incidencia y dominio. -Investigar un hallazgo: +Para investigar un hallazgo: -1. Haz clic en el hallazgo de la lista. -2. En el panel de hallazgos, haz clic en **View Recent Changes** (Ver cambios recientes) para ir a [Audit Trail][3] y ver si hay algún cambio de configuración reciente que haya causado el hallazgo de datos confidenciales. -3. Utiliza las siguientes opciones para explorar diferentes tipos de datos que coincidan con la consulta: - 1. Para ver todos los logs relacionados con la consulta en el Explorer de logs, haz clic en **View All Logs** (Ver todos los logs). - 1. Para ver todas las traces (trazas) que coinciden con la consulta en Trace Explorer, haz clic en **View All APM Spans** (Ver todos los spans (tramos) de APM **. - 1. Para ver todos los eventos de RUM que coincidan con la consulta, haz clic en **View All RUM Events** (Ver todos los eventos de RUM). - 1. Para ver todos los eventos que coinciden con la consulta, haz clic en **View All Events** (Ver todos los eventos). - {{< img src="sensitive_data_scanner/investigate_sensitive_data_issues/findings_panel_20251015.png" alt="El panel de hallazgos en el que se muestra un dato del explorador de tarjetas Visa" style="width:50%;">}} -4. En la sección **Blast Radius** (Radio de explosión): - 1. Mira los 10 principales servicios, hosts y entornos afectados por este hallazgo de datos confidenciales. - 1. Haz clic en un servicio para ver más información sobre él en **Software Catalog** (Catálogo de software). - 1. Haz clic en un host para ver más información sobre él en la page (página) Lista de infraestructuras. - {{< img src="sensitive_data_scanner/investigate_sensitive_data_issues/blast_radius_02_01_2024.png" alt="El panel de hallazgos en el que se muestran los 10 principales servicios afectados" style="width:50%;">}} +1. Haga clic en el hallazgo en la lista. +2. En el panel de hallazgos, haga clic en {{< ui >}}View Recent Changes{{< /ui >}} para navegar a [Audit Trail][3] y ver si hubo cambios de configuración recientes que causaron el hallazgo de datos sensibles. +3. Utilice las siguientes opciones para explorar diferentes tipos de datos que coincidan con la consulta: + 1. Para ver todos los registros relacionados con la consulta en el Explorador de registros, haga clic en {{< ui >}}View All Logs{{< /ui >}}. + 1. Para ver todos los traces que coincidan con la consulta en Trace Explorer, haga clic en {{< ui >}}View All APM Spans{{< /ui >}}. + 1. Para ver todos los eventos de RUM que coincidan con la consulta, haga clic en {{< ui >}}View All RUM Events{{< /ui >}}. + 1. Para ver todos los eventos que coincidan con la consulta, haga clic en {{< ui >}}View All Events{{< /ui >}}. + {{< img src="sensitive_data_scanner/investigate_sensitive_data_issues/findings_panel_20251015.png" alt="El panel de hallazgos que muestra un hallazgo crítico del escáner de tarjetas Visa" style="width:50%;">}} +4. En la sección {{< ui >}}Blast Radius{{< /ui >}}: + 1. Vea los 10 principales servicios, servidores y entornos afectados por estos hallazgos de datos sensibles. + 1. Haga clic en un servicio para ver más información sobre el servicio en {{< ui >}}Catalog{{< /ui >}}. + 1. Haga clic en un servidor para ver más información sobre el servidor en la página de la lista de infraestructura. + {{< img src="sensitive_data_scanner/investigate_sensitive_data_issues/blast_radius_02_01_2024.png" alt="El panel de hallazgos que muestra los 10 principales servicios afectados" style="width:50%;">}} - Si deseas modificar la regla de exploración que se utilizó para detectar el hallazgo de datos confidenciales, haz clic en **Modify Rule** (Modificar la regla) en la parte superior del panel. + Para modificar la Regla de escaneo que se utilizó para detectar el hallazgo de datos sensibles, haga clic en {{< ui >}}Modify Rule{{< /ui >}} en la parte superior del panel. -Además, también puedes: -- Utiliza [Case Management][1] para rastrear, clasificar e investigar el hallazgo, haz clic en **Create Case** (Crear case (incidencia)) en la parte superior del panel. Los cases (incidencias) asociados aparecerán en la page (página) de Hallazgos. -- Utiliza [Incident Management][2] para crear un incident (incidente), puedes añadir el hallazgo a un incident (incidente) existente o declarar un nuevo incident (incidente). Haz clic en el menú desplegable **Declare Incident** (Declarar un incident (incidente)) para añadir el hallazgo a un incident (incidente) existente. Haz clic en **Declare Incident** (Declarar un incident (incidente)) para declarar un nuevo incident (incidente). -- Utiliza [Audit Trail][3] para ver quién puede haber accedido a estos datos confidenciales en Datadog, **View in Audit Trail** (Ver en Audit Trail) en la sección **Users who accessed these events** (Usuarios que accedieron a estos eventos). +Además, también puede: +- Utilice [Case Management][1] para realizar el seguimiento, la clasificación y la investigación del hallazgo; haga clic en {{< ui >}}Create Case{{< /ui >}} en la parte superior del panel. Los incidentes asociados aparecen en la página de Hallazgos. +- Use [Incident Management][2] para crear un incidente; puede agregar el hallazgo a un incidente existente o declarar un nuevo incidente. Haga clic en el menú desplegable {{< ui >}}Declare Incident{{< /ui >}} para agregar el hallazgo a un incidente existente. Haga clic en {{< ui >}}Declare Incident{{< /ui >}} para declarar un nuevo incidente. +- Use [Audit Trail][3] para ver quién pudo haber accedido a estos datos sensibles dentro de Datadog, {{< ui >}}View in Audit Trail{{< /ui >}} en la sección {{< ui >}}Users who accessed these events{{< /ui >}}. -{{< img src="sensitive_data_scanner/investigate_sensitive_data_issues/case_mgmt_02_01_2024.png" alt="La page (página) de case (incidencia) en la que se muestra información acerca del hallazgo de seguridad, el cesionario y el creador del case (incidencia) y una escala de tiempo de eventos" style="width:60%;">}} +{{< img src="sensitive_data_scanner/investigate_sensitive_data_issues/case_mgmt_02_01_2024.png" alt="La página de la incidencia que muestra información sobre el hallazgo de seguridad, la persona asignada y el creador de la incidencia, y una línea de tiempo de los eventos" style="width:60%;">}} -[1]: /es/incident_response/case_management/ +[1]: /es/incident_response/work_management/ [2]: /es/incident_response/incident_management/ [3]: /es/account_management/audit_trail {{% /tab %}} -{{% tab "Cloud Storage" %}} +{{% tab "Almacenamiento en la nube" %}} -Haz clic en la pestaña **Datastores with Sensitive Data** (Almacenes de datos con datos confidenciales) para ver todos los hallazgos de datos confidenciales para Cloud Storage. +Haga clic en la pestaña {{< ui >}}Datastores with Sensitive Data{{< /ui >}} para ver todos los hallazgos de datos sensibles para Almacenamiento en la nube. Para investigar un almacén de datos: -1. Haz clic en un almacén de datos. -1. Puede ver los archivos en los que se han encontrado datos confidenciales y, a continuación, hacer clic en un archivo para inspeccionarlo en AWS. +1. Haga clic en un almacén de datos. +1. Puede ver los archivos donde se encontraron datos sensibles y luego hacer clic en un archivo para inspeccionarlo en AWS. Datadog recomienda hacer lo siguiente: - - Revisa algunos archivos para hacerte una idea de la precisión de la clasificación. - - Ponte en contacto con el propietario del equipo o del servicio que aparece en el panel lateral para confirmar si los datos confidenciales deben estar en el bucket. - - Si no debe estar en el bucket, elimina los archivos o muévelos a un bucket apropiado. - - Si debe estar en el bucket, completa los siguientes steps (UI) / pasos (generic) para mejorar tu postura de seguridad: - 1. Haz clic en la pestaña **Security** (Seguridad) en el panel lateral y revisa la sección **Misconfiguratiions** (Errores de configuración). - 1. Haz clic en un error de configuración para ver los detalles en Cloud Security. - 1. En la sección **Next Steps** (Siguientes pasos): - 1. En **Triage** (Triaje), haz clic en el menú desplegable para cambiar el estado de triaje de la señal. El estado predeterminado es `OPEN`. - 1. Haz clic en **Assign Signal** (Asignar señal) para asignarte una señal a ti mismo o a otro usuario de Datadog. - 1. Haz clic en **See remediation** (Ver corrección) para obtener más información sobre cómo solucionar el problema. - 1. En **More Actions** (Más acciones), puedes añadir un problema de Jira, ejecutar workflows (UI) / procesos (generic) o añadir un comentario. - Para ejecutar un workflow (UI) / proceso (generic), selecciona **Run Workflow** (Ejecutar workflow (UI) / proceso (generic)) y, a continuación, en el explorador de workflows (UI) / procesos (generic), busca y selecciona un workflow (UI) / proceso (generic) para ejecutarlo. Consulta [Automatizar workflows (UI) / procesos (generic) de seguridad con la Workflow Automation (automatización de procesos)][1] para obtener más información. - 1. Haz clic en las distintas pestañas para ver el desglose de la gravedad, los logs relacionados y la escala de tiempo del hallazgo. - - {{< img src="sensitive_data_scanner/investigate_sensitive_data_issues/datastore_side_panel.png" alt="El panel lateral de hallazgos del almacén de datos en el que se muestra que los buckets S3 deben tener una configuración incorrecta de acceso público a bloques activado" style="width:90%;">}} + - Revise algunos archivos para tener una idea de la precisión de la clasificación. + - Haga un seguimiento con el equipo o el propietario del servicio que aparece en el panel lateral para confirmar si los datos sensibles deben estar en el bucket. + - Si no se supone que deben estar en el bucket, elimine los archivos o muévalos a un bucket apropiado. + - Si se supone que deben estar en el bucket, complete los siguientes pasos para mejorar su postura de seguridad: + 1. Haga clic en la pestaña {{< ui >}}Security{{< /ui >}} en el panel lateral y revise la sección {{< ui >}}Misconfigurations{{< /ui >}}. + 1. Haga clic en una configuración incorrecta para ver los detalles en Cloud Security. + 1. En la sección {{< ui >}}Next Steps{{< /ui >}}: + 1. En {{< ui >}}Triage{{< /ui >}}, haga clic en el menú desplegable para cambiar el estado de clasificación de la señal. El estado predeterminado es `OPEN`. + 1. Haga clic en {{< ui >}}Assign Signal{{< /ui >}} para asignarse una señal a usted mismo o a otro usuario de Datadog. + 1. Haga clic en {{< ui >}}See remediation{{< /ui >}} para ver más información sobre cómo solucionar el hallazgo. + 1. En {{< ui >}}More Actions{{< /ui >}}, puede agregar un ticket de Jira, ejecutar flujos de trabajo o agregar un comentario. + Para ejecutar un flujo de trabajo, seleccione {{< ui >}}Run Workflow{{< /ui >}} y luego, en el explorador de flujos de trabajo, busque y seleccione un flujo de trabajo para ejecutar. Consulte [Automate Security Workflows with Workflow Automation][1] para obtener más información. + 1. Haga clic en las diferentes pestañas para ver el desglose de gravedad, los registros relacionados y la línea de tiempo del hallazgo. + + {{< img src="sensitive_data_scanner/investigate_sensitive_data_issues/datastore_side_panel.png" alt="El panel lateral de hallazgos del almacén de datos que muestra los buckets de S3 debería tener habilitada la misconfiguración de Block Public Access." style="width:90%;">}} [1]: /es/security/cloud_security_management/review_remediate/workflows/ {{% /tab %}} {{< /tabs >}} -## Referencias adicionales +## Lecturas adicionales {#further-reading} {{< partial name="whats-next/whats-next.html" >}} diff --git a/hugo/content/es/security/workload_protection/detect_and_monitor/agent_rules/policy_management.md b/hugo/content/es/security/workload_protection/detect_and_monitor/agent_rules/policy_management.md new file mode 100644 index 00000000000..a8b70e9e477 --- /dev/null +++ b/hugo/content/es/security/workload_protection/detect_and_monitor/agent_rules/policy_management.md @@ -0,0 +1,195 @@ +--- +aliases: +- /es/security/workload_protection/workload_security_rules/custom_rules +- /es/security/threats/workload_security_rules/custom_rules +description: Cree, implemente y asigne el contexto a las políticas de Workload Protection, + y escriba reglas personalizadas de Agent para su infraestructura. +disable_toc: false +title: Gestión de políticas +--- +Las reglas de Agent están **organizadas en políticas**. Una política es un conjunto de reglas de Agent que usted implementa en conjunto y **asigna el contexto para una infraestructura específica** (hosts, clústeres, etcétera). + +Además de las [reglas predeterminadas de Agent][7] (OOTB), puede escribir **reglas personalizadas de Agent** para detectar eventos que Datadog no muestra solo con las reglas OOTB estándar. + +## Políticas {#policies} + +### Crear una política {#create-a-policy} + +1. Vaya a [Policies][3]. +2. Haga clic en {{< ui >}}New Policy{{< /ui >}}. También puede abrir una política existente, hacer clic en {{< ui >}}Actions{{< /ui >}} y clonarla. +3. Ingrese un nombre para la política y haga clic en {{< ui >}}Create{{< /ui >}}. + La nueva política se crea, pero no está habilitada ni implementada. +4. Haga clic en la política para abrirla. +5. En {{< ui >}}New Rule{{< /ui >}}, agregue reglas personalizadas de Agent a la política. Para crear una regla de Agent, consulte [Create a custom Agent rule][14]. +6. Haga clic en {{< ui >}}Edit{{< /ui >}} junto a {{< ui >}}Deployed on 0 agents{{< /ui >}}. +7. Agregue [etiquetas][17] a la política para dirigirse a una infraestructura específica. +8. Para implementar la política, active el interruptor junto a {{< ui >}}Policy is disabled{{< /ui >}} y confirme. Esto utiliza [Remote Configuration](#remote-configuration), como se detalla más adelante en esa página. + +### Fije una política administrada por Datadog a su versión actual {#pin-a-datadog-managed-policy-to-its-current-version} + +
La fijación de políticas es compatible con la versión 7.71.0 de Agent y posteriores. Los Agents anteriores siguen recibiendo las últimas actualizaciones de políticas automáticamente.
+ +Cuando Datadog actualiza las políticas administradas por Datadog, estas se implementan automáticamente en su infraestructura. + +Para controlar cuándo se implementa una nueva versión de política en su infraestructura, puede fijar la política a su versión actual. Fijar una versión de política evita que las actualizaciones de políticas se implementen automáticamente cuando Datadog lanza una nueva versión de política. + +Para fijar una política, haga lo siguiente: + +1. Vaya a [Policies][3]. +2. Haga clic en una política administrada por Datadog. +3. En {{< ui >}}Version{{< /ui >}}, haga clic en la opción de fijar. + Si su infraestructura ejecuta Agents con una versión anterior a la 7.71.0, aparecerá una advertencia de Agents obsoletos. Consulte y actualice su versión de Agent en [Fleet Automation][18]. +4. Haga clic en {{< ui >}}Pin{{< /ui >}}. Para desanclar la versión de la política, haga clic en la opción de fijar nuevamente. + +### Reglas en conflicto {#conflicting-rules} + +Cuando dos políticas implementadas en el mismo host contienen la misma regla con un estado diferente (activa e inactiva), la regla se considerará activa. + +### Aplicar etiquetas {#apply-tags} + +Las etiquetas definen dónde se aplica una política, como en entornos, clústeres o hosts. Agregue etiquetas a una política para limitar sus reglas a una parte de su infraestructura. + +1. Vaya a [Agent Configuration][6]. +2. Abra una política y haga clic en {{< ui >}}Edit{{< /ui >}}. +3. Ingrese etiquetas y haga clic en {{< ui >}}Apply{{< /ui >}}. Si la política está habilitada, se aplica a los objetivos de las etiquetas. + +Cuando agrega etiquetas, Datadog muestra a cuántos agentes apuntan las etiquetas, así como la infraestructura que ejecuta cada agente. Por ejemplo, `Tags match 144 agents`. + +## Crear una regla de Agent personalizada {#create-a-custom-agent-rule} + +Puede crear una regla de Agent personalizada e implementarla como parte de una política personalizada. Más tarde, al definir una [regla de detección][19] personalizada, usted hace referencia a la regla de Agent personalizada y agrega parámetros de expresión. +Las reglas de Agent personalizadas se implementan en el Agent en una política personalizada separada de las políticas predeterminadas. La política personalizada contiene solo reglas de Agent personalizadas. + +1. Vaya a [Agent Configuration][6]. +2. Cree una política o abra una existente. +3. Con la política abierta, en {{< ui >}}Actions{{< /ui >}}, seleccione {{< ui >}}Manual rule creator{{< /ui >}} para abrir el editor de reglas de Agent. El mismo editor también está disponible desde la página [Reglas de Agent][21] en Datadog. Para usar el asistente {{< ui >}}Assisted rule creator{{< /ui >}} en su lugar (que lo guía a través de la regla de Agent y la regla de detección de amenazas), consulte [Crear las reglas de Agent y de detección personalizadas juntas][20]. +4. Ingrese un {{< ui >}}Name{{< /ui >}} y una {{< ui >}}Description{{< /ui >}} para la regla. +5. En {{< ui >}}Expression{{< /ui >}}, defina la coincidencia usando [Datadog Security Language (SECL)][15]. +6. (Opcional) Agregue variables o acciones que se ejecuten cuando la regla coincida con un evento. Consulte [Variables y acciones][22]. +7. Haga clic en {{< ui >}}Create Agent Rule{{< /ui >}}. Regresará a la política. + +Después de crear una regla de Agent personalizada, el cambio se guarda junto con otras actualizaciones de reglas pendientes. Para aplicar el cambio a su entorno, implemente la política personalizada actualizada en el Agent. + +## Habilitar e implementar políticas {#enable-and-deploy-policies} + +Las políticas habilitadas aplican sus reglas a los objetivos de infraestructura identificados por sus etiquetas. Habilitar una política es lo mismo que implementarla. + +Puede usar **Remote Configuration** en la interfaz de usuario de Datadog para implementar automáticamente la política personalizada en los hosts designados por las etiquetas de política (todos los hosts o un subconjunto definido de hosts), o puede **implementar manualmente** la política en el Agent de cada host. + +### Remote Configuration {#remote-configuration} + +**Remote Configuration** es la forma en que Datadog entrega automáticamente políticas a sus agentes. Utiliza un mecanismo seguro para garantizar que solo las políticas firmadas y autenticadas se envíen a sus agentes. Para implementar una política mediante Remote Configuration, siga los pasos detallados en Crear una política. + +#### Estrategias de implementación {#deployment-strategies} + +Para implementar un cambio en las reglas o políticas del Agent con Remote Configuration, puede elegir entre dos estrategias: implementar el cambio al instante en todos sus hosts o escalonar la implementación en pasos mediante una implementación administrada. Realice el seguimiento de las implementaciones desde la [página de implementaciones][23]. + +##### Implementar al instante {#deploy-instantly} + +La implementación instantánea envía la política actualizada a todos los hosts en el contexto al mismo tiempo, sin validación por etapas. Esto generalmente toma unos minutos y es mejor cuando desea que el cambio se aplique en todas partes de inmediato. + +Seleccione {{< ui >}}Deploy instantly{{< /ui >}}, luego haga clic en {{< ui >}}Update Policy{{< /ui >}}. Siga el progreso desde la [página de implementaciones][23]. + +##### Implementación administrada {#managed-deployment} + +Una implementación administrada despliega su cambio en etapas para que pueda validarlo en un subconjunto de hosts antes de que llegue a toda su infraestructura. + +1. Al editar una política o una regla, seleccione {{< ui >}}Start a managed deployment{{< /ui >}}. Si la política o regla ya se implementó con un despliegue administrado, seleccione {{< ui >}}Start from your last deployment{{< /ui >}} para reutilizar los parámetros de la última implementación. Para un cambio de regla, los parámetros reutilizados son los de la última implementación de la política que contiene la regla. +2. En {{< ui >}}Customize deployment roll-out plan{{< /ui >}}, establezca el alcance de la implementación, luego configure hasta 10 etapas para implementar el cambio gradualmente. Defina cada etapa {{< ui >}}By percentage of hosts in scope{{< /ui >}} o {{< ui >}}By host tags{{< /ui >}}. +3. En {{< ui >}}Set up monitoring and delay time{{< /ui >}}, seleccione uno o más seguimientos para verificar durante la implementación. Si un seguimiento envía una alerta mientras la implementación está en curso, el despliegue se pausa. Luego, establezca el tiempo de retraso para esperar antes de continuar a la siguiente etapa. +4. En {{< ui >}}Set deployment window{{< /ui >}}, establezca los días, las horas y la zona horaria en los que se puede ejecutar la implementación. Si la implementación se extiende más allá de una ventana, se pausa y se reanuda en la siguiente. +5. (Opcional) En {{< ui >}}Add a description{{< /ui >}}, agregue una descripción para la implementación. +6. Haga clic en {{< ui >}}Update Policy{{< /ui >}} para iniciar el despliegue. Siga el progreso desde la [página de implementaciones][23]. + +### Implementación manual {#manual-deployment} + +Para la **implementación manual**, usted mismo instala un archivo de política en cada Agent. Puede crear la política y sus reglas en la interfaz de usuario de Datadog y **descargar** el archivo generado. Si ya conoce la sintaxis de la política, cree un archivo `.policy` manualmente. Luego, cargue o sincronice ese archivo en cada Agent donde deba ejecutarse la política, como se describe a continuación. + +1. En la página {{< ui >}}Agent Configuration{{< /ui >}}, abra una política. +2. En Actions, seleccione {{< ui >}}Download Policy{{< /ui >}}. + +A continuación, utilice las siguientes instrucciones para cargar el archivo de política en cada servidor. + +{{< tabs >}} +{{% tab "Servidor" %}} + +Copie el archivo `default.policy` al servidor de destino en la carpeta `/etc/datadog-agent/runtime-security.d` (que contendrá todos sus archivos `.policy`). El archivo debe tener acceso `read` y `write` para el usuario `root` en el servidor. + +Para aplicar los cambios, haga **una** de las siguientes opciones: + +- Recargue las políticas de tiempo de ejecución (sin un reinicio completo del Agent): + + ```bash + sudo /opt/datadog-agent/embedded/bin/system-probe runtime policy reload + ``` + +- O reinicie el [Datadog Agent][27]. + +[27]: /es/agent/configuration/agent-commands/?tab=agentv6v7#restart-the-agent + +{{% /tab %}} + +{{% tab "Helm" %}} + +1. Cree un ConfigMap que contenga `default.policy`, por ejemplo, `kubectl create configmap jdefaultpol --from-file=default.policy`. +2. Agregue el ConfigMap (`jdefaultpol`) a `values.yaml` con `datadog.securityAgent.runtime.policies.configMap`: + + ```yaml + securityAgent: + # [...] + runtime: + # datadog.securityAgent.runtime.enabled + # Set to true to enable Security Runtime Module + enabled: true + policies: + # datadog.securityAgent.runtime.policies.configMap + # Place custom policies here + configMap: jdefaultpol + # [...] + ``` + +3. Actualice el chart de Helm con `helm upgrade -f values.yaml --set datadog.apiKey= datadog/datadog`. + + **Nota:** Si necesita realizar más cambios en `default.policy`, puede usar `kubectl edit cm jdefaultpol` o reemplazar el configMap con `kubectl create configmap jdefaultpol --from-file default.policy -o yaml --dry-run=client | kubectl replace -f -`. + +{{% /tab %}} +{{< /tabs >}} + +## Deshabilite las reglas predeterminadas del Agent {#disable-default-agent-rules} + +1. Para deshabilitar una regla del Agent, navegue a la página [{{< ui >}}Agent Configuration{{< /ui >}}][6] y seleccione la política que utiliza la regla. +2. En la política, abra la regla. +3. Establezca el estado en {{< ui >}}Inactive{{< /ui >}}. +4. Haga clic en {{< ui >}}Save Changes{{< /ui >}}. + +Eliminar una regla de [Configuración de reglas][21] la elimina de **todas las políticas** que incluían esa regla. + +## RBAC para la gestión de reglas personalizadas {#rbac-for-custom-rule-management} + +Aquí hay algunos [roles y permisos][11] importantes para usar en el RBAC de reglas personalizadas: + +- El permiso `security_monitoring_cws_agent_rules_actions` se puede utilizar para activar y configurar la [Automated response][12] que se usa para habilitar el modo de bloqueo en las reglas. + - Para utilizar el permiso `security_monitoring_cws_agent_rules_actions`, un usuario con el rol de Datadog Admin debe crear un rol que contenga el permiso `security_monitoring_cws_agent_rules_actions` y, a continuación, añadir a este rol únicamente a aquellos usuarios que gestionen el Automated response. +- El rol {{< ui >}}Datadog Standard{{< /ui >}} permite a los usuarios crear/actualizar una regla personalizada de forma predeterminada, siempre y cuando la operación no cambie la configuración de **protección** de la regla. + +[3]: https://app.datadoghq.com/security/workload-protection/policies +[4]: https://app.datadoghq.com/security/configuration/agent-rules +[5]: /es/security/notifications/variables/?tab=cloudsiem +[6]: https://app.datadoghq.com/security/configuration/workload/agent-rules +[7]: /es/security/workload_protection/detect_and_monitor/agent_rules/#ootb-rules +[8]: /es/security/workload_protection/ +[9]: /es/security/cloud_siem/detect_and_monitor/custom_detection_rules/?tab=threshold#set-a-rule-case +[10]: https://app.datadoghq.com/notebook/list?type=runbook +[11]: /es/account_management/rbac/permissions/ +[12]: /es/security/workload_protection/respond_and_report/#automated-response +[13]: #disable-default-agent-rules +[14]: #create-a-custom-agent-rule +[15]: /es/security/workload_protection/detect_and_monitor/agent_rules/secl_guide/ +[16]: #prioritize-policies +[17]: #apply-tags +[18]: https://app.datadoghq.com/fleet +[19]: /es/security/workload_protection/detect_and_monitor/detection_and_finding_rules/detection_rules +[20]: /es/security/workload_protection/detect_and_monitor/detection_and_finding_rules/detection_rules/#create-the-custom-agent-and-detection-rules-together +[21]: https://app.datadoghq.com/security/workload-protection/agent-rules +[22]: /es/security/workload_protection/detect_and_monitor/agent_rules/variables_and_actions +[23]: https://app.datadoghq.com/security/workload-protection/deployments \ No newline at end of file diff --git a/hugo/content/es/serverless/google_cloud_run/containers/in_container/nodejs.md b/hugo/content/es/serverless/google_cloud_run/containers/in_container/nodejs.md new file mode 100644 index 00000000000..6f125dcd828 --- /dev/null +++ b/hugo/content/es/serverless/google_cloud_run/containers/in_container/nodejs.md @@ -0,0 +1,98 @@ +--- +aliases: +- /es/serverless/google_cloud_run/containers/in_process/nodejs +code_lang: nodejs +code_lang_weight: 20 +further_reading: +- link: /tracing/trace_collection/automatic_instrumentation/dd_libraries/nodejs/ + tag: Documentación + text: Seguimiento de aplicaciones Node.js +- link: /tracing/other_telemetry/connect_logs_and_traces/nodejs/ + tag: Documentación + text: Correlación de registros y trazas de Node.js +title: Instrumentación de un contenedor Cloud Run de Node.js +type: multi-code-lang +--- +## Configuración {#setup} + +
Una aplicación de ejemplo está disponible en GitHub.
+ +1. **Instale el SDK de Datadog para Node.js**. + + 1. En su aplicación principal, instale el paquete `dd-trace`. + + {{< code-block lang="shell" disable_copy="false" >}} +npm install dd-trace +{{< /code-block >}} + + 2. Inicialice el trazador de Node.js con la variable de entorno `NODE_OPTIONS`: + {{< code-block lang="dockerfile" disable_copy="false" >}} +ENV NODE_OPTIONS="--require dd-trace/init" +{{< /code-block >}} + + Para obtener más información, consulte [Seguimiento de aplicaciones Node.js][1]. + +2. **Instale serverless-init**. + + {{% serverless-init-install mode="in-container" cmd="\"/nodejs/bin/node", "/path/to/your/app.js"s\"" %}} + +3. **Configure los registros**. + + Para habilitar el registro, establezca la variable de entorno `DD_LOGS_ENABLED=true`. Esto permite que `serverless-init` lea los registros de stdout y stderr. + + Datadog también recomienda establecer las variables de entorno `DD_LOGS_INJECTION=true` y `DD_SOURCE=nodejs` para habilitar el parseo avanzado de registros de Datadog. + + Si desea que los registros multilínea se conserven en un solo mensaje de registro, Datadog recomienda escribir sus registros en formato JSON. Por ejemplo, puede utilizar una biblioteca de registro de terceros como `winston`: + {{< code-block lang="javascript" disable_copy="false" >}} +const { createLogger, format, transports } = require('winston'); + +const logger = createLogger({ + level: 'info', + exitOnError: false, + format: format.json(), + transports: [ + new transports.Console() + ], +}); + +logger.info('Hello world!'); +{{< /code-block >}} + + Para obtener más información, consulte [Correlación de registros y trazas de Node.js][2]. + +4. **Configure su aplicación**. + +{{% serverless-init-configure cloudrun="true" %}} + +5. {{% gcr-service-label %}} + +6. **Enviar métricas personalizadas**. + + Para enviar métricas personalizadas, [vea ejemplos de código][3]. En serverless, solo se admite el tipo de métrica *distribution*. + +7. **Habilite el perfilado (vista previa)**. + + Para habilitar el [Continuous Profiler][6], establezca la variable de entorno `DD_PROFILING_ENABLED=true`. + +
El Continuous Profiler de Datadog está disponible en vista previa para los servicios de Google Cloud Run.
+ +{{% serverless-init-env-vars-in-container language="nodejs" defaultSource="cloudrun" %}} + +{{% svl-tracing-env %}} + +## Seguimiento distribuido con Pub/Sub {#distributed-tracing-with-pubsub} + +{{% gcr-pubsub-push-tracing %}} + +## Solución de problemas {#troubleshooting} + +{{% serverless-init-troubleshooting productNames="Cloud Run services" in_container="true" %}} + +## Lecturas adicionales {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /es/tracing/trace_collection/automatic_instrumentation/dd_libraries/nodejs/ +[2]: /es/tracing/other_telemetry/connect_logs_and_traces/nodejs/ +[3]: /es/metrics/custom_metrics/dogstatsd_metrics_submission/?tab=nodejs#code-examples-5 +[6]: /es/profiler/ \ No newline at end of file diff --git a/hugo/content/es/serverless/google_cloud_run/containers/in_container/python.md b/hugo/content/es/serverless/google_cloud_run/containers/in_container/python.md new file mode 100644 index 00000000000..d315faa1e6b --- /dev/null +++ b/hugo/content/es/serverless/google_cloud_run/containers/in_container/python.md @@ -0,0 +1,117 @@ +--- +aliases: +- /es/serverless/google_cloud_run/containers/in_process/python +code_lang: python +code_lang_weight: 10 +further_reading: +- link: /tracing/trace_collection/automatic_instrumentation/dd_libraries/python/ + tag: Documentación + text: Trazas de aplicaciones Python +- link: /tracing/other_telemetry/connect_logs_and_traces/python/ + tag: Documentación + text: Correlación de registros y trazas de Python +title: Instrumentación de un contenedor de Python en Cloud Run +type: multi-code-lang +--- +## Configuración {#setup} + +
Una aplicación de muestra está disponible en GitHub.
+ +1. **Instale el SDK de Python de Datadog**. + + Agregue `ddtrace` a su `requirements.txt` o `pyproject.toml`. Puede encontrar la versión más reciente en [PyPI][1]: + {{< code-block lang="text" filename="requirements.txt" disable_copy="false" collapsible="true" >}} +ddtrace== +{{< /code-block >}} + + Alternativamente, puede instalar el SDK en su Dockerfile: + {{< code-block lang="dockerfile" filename="Dockerfile" disable_copy="false" collapsible="true" >}} +RUN pip install ddtrace +{{< /code-block >}} + + Luego, envuelva su comando de inicio con `ddtrace-run`: + {{< code-block lang="dockerfile" filename="Dockerfile" disable_copy="false" collapsible="true" >}} +CMD ["ddtrace-run", "python", "app.py"] +{{< /code-block >}} + + Para obtener más información, consulte [Trazas de aplicaciones Python][2]. + +2. **Instale serverless-init**. + + {{% serverless-init-install mode="in-container" cmd="\"ddtrace-run", "python", "path/to/your/python/app.py".py\"" %}} + +3. **Configure los registros**. + + Para habilitar el registro, establezca la variable de entorno `DD_LOGS_ENABLED=true`. Esto permite que `serverless-init` lea los registros de stdout y stderr. + + Datadog también recomienda las siguientes variables de entorno: + - `ENV PYTHONUNBUFFERED=1`: Asegúrese de que las salidas de Python aparezcan inmediatamente en los registros del contenedor en lugar de almacenarse en búfer. + - `ENV DD_LOGS_INJECTION=true`: Habilite la correlación de registros y trazas para los registradores compatibles. + - `ENV DD_SOURCE=python`: Habilite el parseo avanzado de registros de Datadog. + + Si desea que los registros multilínea se conserven en un solo mensaje de registro, Datadog recomienda escribir sus registros en formato JSON. Por ejemplo, puede utilizar una biblioteca de registro de terceros como `structlog`: + {{< code-block lang="python" disable_copy="false" >}} +import structlog + +def tracer_injection(logger, log_method, event_dict): + event_dict.update(tracer.get_log_correlation_context()) + return event_dict + +structlog.configure( + processors=[ + tracer_injection, + structlog.processors.EventRenamer("msg"), + structlog.processors.JSONRenderer() + ], + logger_factory=structlog.WriteLoggerFactory(file=sys.stdout), +) + +logger = structlog.get_logger() + +logger.info("Hello world!") +{{< /code-block >}} + + Para obtener más información, consulte [Correlación de registros y trazas de Python][3]. + +4. **Configure su aplicación**. + +{{% serverless-init-configure cloudrun="true" %}} + +5. {{% gcr-service-label %}} + +6. **Enviar métricas personalizadas**. + + Para enviar métricas personalizadas, [instale el cliente DogStatsD][4] y [vea ejemplos de código][5]. En serverless, solo se admite el tipo de métrica *distribution*. + +7. **Habilite el perfilado (vista previa)**. + + Para habilitar el [Continuous Profiler][6], establezca la variable de entorno `DD_PROFILING_ENABLED=true`. + +
El Continuous Profiler de Datadog está disponible en vista previa para los servicios de Google Cloud Run.
+ +{{% serverless-init-env-vars-in-container language="python" defaultSource="cloudrun" %}} + +{{% svl-tracing-env %}} + +## Seguimiento distribuido con Pub/Sub {#distributed-tracing-with-pubsub} + +Establezca `DD_TRACE_INFERRED_PROXY_SERVICES_ENABLED=true`. Esto crea un tramo `gcp.pubsub.receive` inferido para la solicitud push. + +La traza de suscripciones push de Google Cloud Pub/Sub requiere la versión 4.8.0 o posterior de `ddtrace`. + +{{% gcr-pubsub-push-tracing %}} + +## Solución de problemas {#troubleshooting} + +{{% serverless-init-troubleshooting productNames="Cloud Run services" in_container="true" %}} + +## Lecturas adicionales {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://pypi.org/project/ddtrace/ +[2]: /es/tracing/trace_collection/automatic_instrumentation/dd_libraries/python +[3]: /es/tracing/other_telemetry/connect_logs_and_traces/python/ +[4]: /es/extend/dogstatsd/?tab=python#install-the-dogstatsd-client +[5]: /es/metrics/custom_metrics/dogstatsd_metrics_submission/?tab=python#code-examples-5 +[6]: /es/profiler/ \ No newline at end of file diff --git a/hugo/content/es/serverless/google_cloud_run/functions/python.md b/hugo/content/es/serverless/google_cloud_run/functions/python.md new file mode 100644 index 00000000000..18249346a5d --- /dev/null +++ b/hugo/content/es/serverless/google_cloud_run/functions/python.md @@ -0,0 +1,122 @@ +--- +code_lang: python +code_lang_weight: 10 +further_reading: +- link: /tracing/trace_collection/automatic_instrumentation/dd_libraries/python/ + tag: Documentación + text: Trazas de aplicaciones Python +- link: /tracing/other_telemetry/connect_logs_and_traces/python/ + tag: Documentación + text: Correlación de registros y trazas de Python +title: Instrumentación de una función de Cloud Run en Python +type: multi-code-lang +--- +
Una aplicación de muestra está disponible en GitHub.
+ +## Configuración {#setup} + +1. **Instale el SDK de Python de Datadog**. + + Agregue `ddtrace` a su `requirements.txt` o `pyproject.toml`. Esto garantiza que el SDK se incluya en la imagen de su contenedor cuando se compile y se implemente. Puede encontrar la versión más reciente en [PyPI][1]: + {{< code-block lang="text" filename="requirements.txt" disable_copy="false" collapsible="true" >}} +ddtrace== +{{< /code-block >}} + + Para obtener más información, consulte [Trazas de aplicaciones Python][2]. + +2. **Instale serverless-init como sidecar**. + + {{< tabs >}} + + {{% tab "CLI de Datadog" %}} + {{% gcr-install-sidecar-datadog-ci %}} + {{% /tab %}} + + {{% tab "Terraform" %}} + {{% gcr-install-sidecar-terraform function="true" %}} + {{% /tab %}} + + {{% tab "Otro" %}} + {{% gcr-install-sidecar-other function="true" %}} + {{% /tab %}} + + {{< /tabs >}} + +3. **Configure los registros**. + + En el paso anterior, creó un volumen compartido. Es posible que también haya configurado la variable de entorno `DD_SERVERLESS_LOG_PATH`, que tiene como valor predeterminado `/shared-volume/logs/app.log`. + + En este paso, configure su biblioteca de registro para escribir registros en el archivo establecido en `DD_SERVERLESS_LOG_PATH`. También puede establecer un formato personalizado para la correlación de registros/trazas y otras funciones. Datadog recomienda configurar las siguientes variables de entorno: + - `PYTHONUNBUFFERED=1`: En su contenedor principal. Asegúrese de que las salidas de Python aparezcan inmediatamente en los registros del contenedor en lugar de almacenarse en búfer. + - `DD_LOGS_INJECTION=true`: En su contenedor principal. Habilite la correlación de registros/trazas para los registradores compatibles. + - `DD_SOURCE=python`: En su contenedor sidecar. Habilite el parseo avanzado de registros de Datadog. + + Luego, actualice su biblioteca de registro. Por ejemplo, puede usar la biblioteca nativa `logging` de Python: + {{< code-block lang="python" disable_copy="false" >}} +LOG_FILE = "/shared-volume/logs/app.log" +os.makedirs(os.path.dirname(LOG_FILE), exist_ok=True) + +FORMAT = ('%(asctime)s %(levelname)s [%(name)s] [%(filename)s:%(lineno)d] ' + '[dd.service=%(dd.service)s dd.env=%(dd.env)s dd.version=%(dd.version)s dd.trace_id=%(dd.trace_id)s dd.span_id=%(dd.span_id)s] ' + '- %(message)s') + +logging.basicConfig( + level=logging.INFO, + format=FORMAT, + handlers=[ + logging.FileHandler(LOG_FILE), + logging.StreamHandler(sys.stdout) + ] +) +logger = logging.getLogger(__name__) +logger.level = logging.INFO + +logger.info('Hello world!') +{{< /code-block >}} + + Para obtener más información, consulte [Correlación de registros y trazas de Python][3]. + +4. {{% gcr-service-label %}} + +5. **Enviar métricas personalizadas**. + + Para enviar métricas personalizadas, [instale el cliente DogStatsD][4] y [vea ejemplos de código][5]. En Serverless Monitoring, solo se admite el tipo de métrica *distribution*. + +6. **Habilite la generación de perfiles (vista previa)**. + + Para habilitar el [Continuous Profiler][6], establezca la variable de entorno `DD_PROFILING_ENABLED=true` en el contenedor de su aplicación y agregue `import ddtrace.auto` en la parte superior de su archivo de función: + + {{< code-block lang="python" disable_copy="false" >}} +import ddtrace.auto + +# ... rest of your function code +{{< /code-block >}} + +
El Continuous Profiler de Datadog está disponible en vista previa para las funciones de Cloud Run de segunda generación.
+ +{{% serverless-init-env-vars-sidecar language="python" function="true" defaultSource="cloudrun" %}} + +{{% svl-tracing-env %}} + +## Seguimiento distribuido con Pub/Sub {#distributed-tracing-with-pubsub} + +Establezca `DD_TRACE_INFERRED_PROXY_SERVICES_ENABLED=true` en el contenedor de la aplicación. Esto crea un tramo `gcp.pubsub.receive` inferido para la solicitud push. + +La traza de suscripciones push de Google Cloud Pub/Sub requiere la versión 4.8.0 o posterior de `ddtrace`. + +{{% gcr-pubsub-push-tracing %}} + +## Solución de problemas {#troubleshooting} + +{{% serverless-init-troubleshooting productNames="Cloud Run services" %}} + +## Lecturas adicionales {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://pypi.org/project/ddtrace/ +[2]: /es/tracing/trace_collection/automatic_instrumentation/dd_libraries/python +[3]: /es/tracing/other_telemetry/connect_logs_and_traces/python/ +[4]: /es/extend/dogstatsd/?tab=python#install-the-dogstatsd-client +[5]: /es/metrics/custom_metrics/dogstatsd_metrics_submission/?tab=python#code-examples-5 +[6]: /es/profiler/ \ No newline at end of file diff --git a/hugo/content/es/session_replay/_index.md b/hugo/content/es/session_replay/_index.md index 5a320051b39..38ddd05d0b7 100644 --- a/hugo/content/es/session_replay/_index.md +++ b/hugo/content/es/session_replay/_index.md @@ -9,131 +9,166 @@ aliases: description: Aprenda cómo capturar y reproducir visualmente la experiencia de navegación web o de aplicaciones móviles de sus usuarios con Session Replay. further_reading: -- link: https://www.datadoghq.com/blog/session-replay-datadog/ - tag: Blog - text: Utilice Datadog Session Replay para ver los recorridos de los usuarios en - tiempo real. -- link: https://www.datadoghq.com/blog/reduce-customer-friction-funnel-analysis/ - tag: Blog - text: Utilice el análisis de embudo para comprender y optimizar los flujos clave - de los usuarios -- link: https://www.datadoghq.com/blog/zendesk-session-replay-integration/ - tag: Blog - text: Reproduzca visualmente los problemas que afectan a los usuarios con Zendesk - y Datadog Session Replay. - link: /real_user_monitoring/explorer tag: Documentación - text: Visualice sus datos de RUM en el Explorer. + text: Visualice sus datos de RUM en el Explorer - link: /integrations/content_security_policy_logs tag: Documentación text: Detecte y agregue violaciones de CSP con Datadog - link: https://learn.datadoghq.com/courses/intro-to-rum tag: Centro de aprendizaje text: Introducción a Real User Monitoring (RUM) +- link: https://www.datadoghq.com/blog/session-replay-custom-heatmap-backgrounds/ + tag: Blog + text: Capture y analice mapas de calor personalizados en Session Replay +- link: https://www.datadoghq.com/blog/ai-summaries-and-smart-chapters/ + tag: Blog + text: Comprenda Session Replay más rápido con resúmenes de IA y capítulos inteligentes +- link: https://www.datadoghq.com/blog/session-replay-datadog/ + tag: Blog + text: Utilice Datadog Session Replay para visualizar los recorridos de usuario en + tiempo real +- link: https://www.datadoghq.com/blog/reduce-customer-friction-funnel-analysis/ + tag: Blog + text: Utilice el análisis de embudo para comprender y optimizar los flujos clave + de usuario +- link: https://www.datadoghq.com/blog/zendesk-session-replay-integration/ + tag: Blog + text: Reproduzca visualmente problemas orientados al usuario con Zendesk y Datadog + Session Replay +- link: https://www.datadoghq.com/blog/session-replay-investigate-collaborate/ + tag: Blog + text: Encuentre, analice y colabore en sesiones de usuario en Datadog Session Replay title: Session Replay --- -## Descripción general\r {#overview} +## Descripción general + {#overview} -Session Replay amplía el seguimiento de la experiencia del usuario al permitirle capturar y reproducir visualmente la experiencia de navegación web o de aplicaciones móviles de sus usuarios. Session Replay está disponible tanto en [RUM][1] como en [Product Analytics][2], lo que le ayuda a identificar y reproducir errores, comprender los recorridos de los usuarios y obtener información sobre los patrones de uso y los errores de diseño de su aplicación. +Session Replay amplía su monitoreo de experiencia de usuario al permitirle capturar y reproducir visualmente la experiencia de navegación web o de aplicaciones móviles de sus usuarios. Session Replay está disponible tanto en [RUM][1] como en [Product Analytics][2], lo que le ayuda a identificar y reproducir errores, comprender los recorridos de usuario y obtener información sobre los patrones de uso y los errores de diseño de su aplicación. -## Browser Session Replay\r {#browser-session-replay} +## Browser Session Replay + {#browser-session-replay} -Browser Session Replay amplía el seguimiento de la experiencia del usuario al permitirle capturar y reproducir visualmente la experiencia de navegación web de sus usuarios. Combinado con los datos de rendimiento de RUM, Session Replay es beneficioso para la identificación, reproducción y resolución de errores, y proporciona información sobre los patrones de uso y los errores de diseño de su aplicación web. +Browser Session Replay amplía su monitoreo de experiencia de usuario al permitirle capturar y reproducir visualmente la experiencia de navegación web de sus usuarios. Combinado con los datos de rendimiento de RUM, Session Replay es beneficioso para la identificación, reproducción y resolución de errores, y proporciona información sobre los patrones de uso y los errores de diseño de su aplicación web. -RUM Browser SDK es [open source][3] y aprovecha el proyecto open source [rrweb][4]. +El SDK de RUM para navegador es [open source][3] y aprovecha el proyecto de código abierto [rrweb][4]. Obtenga más información sobre [Session Replay for Browsers][5]. -## Mobile Session Replay\r {#mobile-session-replay} +## Mobile Session Replay + {#mobile-session-replay} -Mobile Session Replay amplía la visibilidad de sus aplicaciones móviles al reproducir visualmente cada interacción del usuario, como toques, deslizamientos y desplazamientos. Está disponible para aplicaciones nativas tanto en Android como en iOS. Reproducir visualmente las interacciones del usuario en sus aplicaciones facilita la reproducción de fallos y errores, así como comprender el recorrido del usuario para realizar mejoras en la interfaz de usuario. +Mobile Session Replay amplía la visibilidad de sus aplicaciones móviles al reproducir visualmente cada interacción de usuario, como toques, deslizamientos y desplazamientos. Está disponible para aplicaciones nativas tanto en Android como en iOS. Reproducir visualmente las interacciones de usuario en sus aplicaciones facilita la reproducción de fallos y errores, así como comprender el recorrido de usuario para realizar mejoras en la interfaz de usuario. Obtenga más información sobre [Session Replay for Mobile][6]. -## Resúmenes con tecnología de IA y smart chapters\r {#ai-powered-summaries-and-smart-chapters} +## Resúmenes con tecnología de IA y capítulos inteligentes + {#ai-powered-summaries-and-smart-chapters} -{{< site-region region="gov,gov2" >}}
Esta función no es compatible con su sitio de Datadog seleccionado ({{< region-param key="dd_site_name" >}}).
{{< /site-region >}} +{{< site-region region="gov,gov2" >}}
Esta función no es compatible con el sitio de Datadog seleccionado ({{< region-param key="dd_site_name" >}}).
{{< /site-region >}} -Los resúmenes y los smart chapters le brindan contexto sobre lo que sucedió en una sesión antes de que la vea. +Los resúmenes y los capítulos inteligentes le brindan contexto sobre lo que sucedió en una sesión antes de verla. -**Los resúmenes** describen la intención del usuario, las acciones clave, las señales de fricción y el resultado. Momentos específicos en el resumen están hipervinculados para que pueda saltar directamente a ese punto en el Session Replay. En la lista de sesiones, pase el cursor sobre un Session Replay para obtener una vista previa del resumen, o ábralo directamente. Si una sesión se ha resumido anteriormente, el resumen aparece al instante cuando abre el Session Replay. +**Los resúmenes** describen la intención del usuario, las acciones clave, las señales de fricción y el resultado. Los momentos específicos en el resumen tienen hipervínculos para que pueda saltar directamente a ese punto en Session Replay. En la lista de sesiones, pase el cursor sobre una Session Replay para obtener una vista previa del resumen o abra la Session Replay directamente. Si una sesión se ha resumido anteriormente, el resumen aparece al instante cuando abre la Session Replay. -{{< img src="real_user_monitoring/session_replay/session-replay-ai-summary.png" alt="Resumen con tecnología de IA en el reproductor de Session Replay, que muestra la intención del usuario, acciones de usuario clave, señales de fricción y momentos hipervinculados." style="width:100%;" >}} +{{< img src="real_user_monitoring/session_replay/session-replay-ai-summary.png" alt="Resumen con tecnología de IA en el reproductor de Session Replay, que muestra la intención del usuario, acciones clave, señales de fricción y momentos con hipervínculos" style="width:100%;" >}} -**Smart chapters** segmentan automáticamente la línea de tiempo del Session Replay en etapas etiquetadas del recorrido del usuario. Por ejemplo, en una sesión de comercio electrónico, los capítulos podrían incluir "Explorar iluminación", "Comprar ropa de cama y sillas" y "Revisar carrito y finalizar compra". Los capítulos aparecen cuando pasa el cursor sobre la línea de tiempo y en el menú desplegable de los controles del Session Replay, lo que le permite saltar directamente entre ellos. +**Capítulos inteligentes** segmenta automáticamente la línea de tiempo de Session Replay en etapas etiquetadas del recorrido del usuario. Por ejemplo, en una sesión de comercio electrónico, los capítulos podrían incluir "Explorar iluminación", "Comprar ropa de cama y sillas" y "Revisar carrito y finalizar compra". Los capítulos aparecen cuando pasa el cursor sobre la línea de tiempo y en el menú desplegable de los controles de Session Replay, lo que le permite saltar directamente entre ellos. -{{< img src="real_user_monitoring/session_replay/session-replay-smart-chapters.png" alt="Menú desplegable de Smart chapters en el reproductor de Session Replay que muestra etapas etiquetadas del recorrido del usuario." style="width:100%;" >}} +{{< img src="real_user_monitoring/session_replay/session-replay-smart-chapters.png" alt="Menú desplegable de capítulos inteligentes en Session Replay que muestra las etapas etiquetadas del recorrido del usuario" style="width:100%;" >}} -Los resúmenes con IA y los Smart chapters se generan para sesiones con al menos cuatro acciones de usuario y una duración de al menos 45 segundos. +Los resúmenes de IA y los capítulos inteligentes se generan para sesiones con al menos cuatro acciones de usuario y una duración de al menos 45 segundos. -## Comentarios {#comments} +## Comentarios + {#comments} -{{< site-region region="gov,gov2" >}}
Esta función no es compatible con su sitio seleccionado de Datadog ({{< region-param key="dd_site_name" >}}). Si requiere esta capacidad, comuníquese con Datadog Support.
{{< /site-region >}} +{{< site-region region="gov,gov2" >}}
Esta función no es compatible con el sitio de Datadog seleccionado ({{< region-param key="dd_site_name" >}}). Si requiere esta capacidad, comuníquese con Datadog Support.
{{< /site-region >}} -Los comentarios de Session Replay permiten que su equipo colabore en errores, problemas de usabilidad y otras observaciones directamente dentro de un Session Replay. +Los comentarios de Session Replay permiten a su equipo colaborar en errores, problemas de usabilidad y otras observaciones directamente dentro de Session Replay. Con los comentarios, usted puede: -- Agregar un comentario en una marca de tiempo específica en la línea de tiempo del Session Replay. Los marcadores de comentarios aparecen en la línea de tiempo y en la pestaña {{< ui >}}Comments{{< /ui >}}. -- @mencionar a un compañero de equipo o a un equipo en un comentario. Los usuarios etiquetados reciben una notificación por correo electrónico con un enlace que abre el Session Replay en la marca de tiempo comentada. -- Copiar un enlace a cualquier comentario y compartirlo externamente. El enlace abre el Session Replay en el momento anotado con ese hilo de comentarios abierto. -- Responda en el hilo para colaborar dentro de un Session Replay, y edite o elimine sus propios comentarios según sea necesario. +- Agregue un comentario en una marca de tiempo específica en la línea de tiempo de Session Replay. Los marcadores de comentarios aparecen en la línea de tiempo y en la pestaña {{< ui >}}Comments{{< /ui >}}. +- @mencione a un compañero de equipo o equipo en un comentario. Los usuarios etiquetados reciben una notificación por correo electrónico con un enlace que abre Session Replay en la marca de tiempo comentada. +- Copie un enlace a cualquier comentario y compártalo externamente. El enlace abre Session Replay en el momento anotado con ese hilo de comentarios abierto. +- Responda en el hilo para colaborar dentro de Session Replay, y edite o elimine sus propios comentarios según sea necesario. {{< img src="real_user_monitoring/session_replay/session-replay-comments.png" alt="Reproductor de Session Replay con comentarios con marca de tiempo en la línea de tiempo y una pestaña de Comentarios abierta con respuestas en hilo." style="width:100%;" >}} -Para encontrar los Session Replays que necesitan su atención, utilice las listas de reproducción predeterminadas {{< ui >}}All mentions to me{{< /ui >}} y {{< ui >}}Commented replays{{< /ui >}}. Consulte [Session Replay Playlists][7] para obtener más detalles. +Para encontrar Session Replays que necesiten su atención, utilice las listas de reproducción predeterminadas {{< ui >}}All mentions to me{{< /ui >}} y {{< ui >}}Commented replays{{< /ui >}}. Consulte [Listas de reproducción de Session Replay][7] para obtener más detalles. -## Extender la retención de datos {#extend-data-retention} +## Extender la retención de datos + {#extend-data-retention} -De forma predeterminada, los datos de Session Replay se conservan durante 30 días. +De forma predeterminada, los datos de Session Replay se conservan durante 30 días. Para establecer el período de retención predeterminado para todos los Session Replay a más de 30 días, comuníquese con su equipo de cuenta. -Para extender la retención de datos de Session Replay a 15 meses, puede habilitar {{< ui >}}Extended Retention{{< /ui >}} en los Session Replays individuales. Estas sesiones deben estar inactivas (el usuario ha completado su experiencia). +Para extender la retención de datos de Session Replay a 15 meses, puede habilitar {{< ui >}}Extended Retention{{< /ui >}} en Session Replay individuales. Estas sesiones deben estar inactivas (el usuario ha completado su experiencia). Para acceder a cualquier Session Replay en un momento posterior, Datadog recomienda guardar la URL o agregarla a una [Playlist][7]. -La retención extendida solo se aplica a Session Replay y no incluye los eventos asociados. Los 15 meses comienzan cuando se habilita la retención extendida, no cuando se recopila el Session Replay. +Datadog también extiende la retención a 15 meses automáticamente cuando una Session Replay se utiliza en otra parte del producto: + +- Agregar una Session Replay a una [Playlist][7]. +- Guardar una Session Replay como una captura de pantalla de mapa de calor. Consulte [Análisis de mapas de calor más allá de la retención de Session Replay][12]. + +La Retención extendida solo se aplica a Session Replay y no incluye los eventos asociados. Los 15 meses comienzan cuando se habilita la Retención extendida, no cuando se recopila la sesión. -Puede desactivar la Retención extendida en cualquier momento. Si el Session Replay aún se encuentra dentro de sus 30 días de retención predeterminados, éste caduca al final del período inicial de 30 días. Si desactiva la Retención extendida en un Session Replay que tenga más de 30 días, éste caduca inmediatamente. +Puede deshabilitar la Retención extendida en cualquier momento. Si la Session Replay aún se encuentra dentro de sus 30 días de retención predeterminados, la Session Replay caduca al final del período inicial de 30 días. Si deshabilita la Retención extendida en una Session Replay que tiene más de 30 días, la Session Replay caduca inmediatamente. -{{< img src="real_user_monitoring/session_replay/extended-retention-1.png" alt="Habilitar la retención extendida" style="width:100%;" >}} +{{< img src="real_user_monitoring/session_replay/extended-retention-1.png" alt="Habilitar retención extendida" style="width:100%;" >}} Consulte el siguiente diagrama para comprender qué datos se conservan con la retención extendida. {{< img src="real_user_monitoring/session_replay/replay-extended-retention-1.png" alt="Diagrama de qué datos se conservan con la retención extendida" style="width:100%;" >}} -## Historial de reproducción\r {#playback-history} +## Historial de reproducción + {#playback-history} -Puede ver quién ha visto un Session Replay determinado haciendo clic en el recuento de **vistas** que se muestra en la página del reproductor. Esta función le permite verificar si alguien con quien desea compartir la grabación ya la ha visto. +Puede ver quién ha visto una determinada Session Replay haciendo clic en el recuento de **watched** que se muestra en la página del reproductor. Esta función le permite verificar si alguien con quien desea compartir la grabación ya la ha visto. -{{< img src="real_user_monitoring/session_replay/session-replay-playback-history.png" alt="Verifique quién ha visto la grabación de un Session Replay." style="width:100%;" >}} +{{< img src="real_user_monitoring/session_replay/session-replay-playback-history.png" alt="Verifique quién ha visto la grabación de una Session Replay" style="width:100%;" >}} -El historial solo incluye los Session Replays que ocurrieron en la página del reproductor o en un reproductor incrustado, como en un [Notebook][8] o panel lateral. Los Session Replays incluidos también generan un evento de [Audit Trail][9]. Las vistas previas en miniatura no se incluyen en el historial. +El historial incluye solo las reproducciones que ocurrieron en la página del reproductor o en un reproductor incrustado, como en un [Notebook][8] o panel lateral. Las reproducciones incluidas también generan un evento de [Audit Trail][9]. Las vistas previas en miniatura no se incluyen en el historial. -Para ver su propio historial de Session Replay, consulte la lista de reproducción [{{< ui >}}My Watch History{{< /ui >}}][10]. +Para ver su propio historial de reproducción, consulte la [{{< ui >}}My Watch History{{< /ui >}}Playlist][10]. -## Listas de reproducción\r {#playlists} +## Playlists + {#playlists} -Puede crear una lista de reproducción de Session Replays para organizarlas según cualquier patrón que observe. Obtenga más información sobre [Session Replay Playlists][7]. +Puede crear una Playlist de Session Replay para organizarlas según los patrones que observe. Obtenga más información sobre [Session Replay Playlists][7]. -## Dev Tools\r {#dev-tools} +## Dev Tools + {#dev-tools} Dev Tools es un panel de depuración integrado en Session Replay que expone información clave durante la reproducción. Úselo para identificar problemas, rastrear solicitudes y comprender los cuellos de botella en el rendimiento, todo sin tener que reproducir el problema usted mismo. Dev Tools están disponibles para sesiones de [RUM][1]. -Obtenga más información sobre Dev Tools para [browser][11] y [mobile][12]. +Obtenga más información sobre [Dev Tools][11]. -## Lecturas adicionales\r {#further-reading} +## Lecturas adicionales + {#further-reading} {{< partial name="whats-next/whats-next.html" >}} -[1]: /es/real_user_monitoring/\r -[2]: /es/product_analytics/\r -[3]: https://github.com/DataDog/browser-sdk\r -[4]: https://www.rrweb.io/\r -[5]: /es/session_replay/browser/\r -[6]: /es/session_replay/mobile/\r -[7]: /es/session_replay/playlists\r -[8]: /es/notebooks/\r -[9]: /es/account_management/audit_trail/\r -[10]: /es/rum/replay/playlists/my-watch-history\r -[11]: /es/session_replay/browser/dev_tools/\r -[12]: /es/session_replay/mobile/dev_tools/ \ No newline at end of file +[1]: /es/real_user_monitoring/ + +[2]: /es/product_analytics/ + +[3]: https://github.com/DataDog/browser-sdk + +[4]: https://www.rrweb.io/ + +[5]: /es/session_replay/browser/ + +[6]: /es/session_replay/mobile/ + +[7]: /es/session_replay/playlists + +[8]: /es/notebooks/ + +[9]: /es/account_management/audit_trail/ + +[10]: /es/rum/replay/playlists/my-watch-history + +[11]: /es/session_replay/dev_tools + +[12]: /es/session_replay/heatmaps/#analyzing-heatmaps-beyond-replay-retention \ No newline at end of file diff --git a/hugo/content/es/tracing/error_tracking/_index.md b/hugo/content/es/tracing/error_tracking/_index.md index 651a3d51a39..e8995e4fc13 100644 --- a/hugo/content/es/tracing/error_tracking/_index.md +++ b/hugo/content/es/tracing/error_tracking/_index.md @@ -1,63 +1,81 @@ --- algolia: tags: - - seguimiento de errores -description: Aprende a buscar y gestionar los errores de los servicios de backend. + - error tracking +description: Aprenda a buscar y gestionar los errores recopilados de sus servicios + de backend. further_reading: - link: https://www.datadoghq.com/blog/service-page/ tag: Blog - text: Explorar una vista centralizada de la telemetría de los servicios, el seguimiento - de errores, los SLOs y más + text: Explore una vista centralizada de la telemetría de servicios, Error Tracking, + SLOs, y más - link: /tracing/trace_explorer/trace_view/ tag: Documentación - text: Más información sobre Trace Explorer + text: Aprenda sobre el Trace Explorer - link: /tracing/error_tracking/explorer tag: Documentación - text: Más información sobre Error Tracking Explorer + text: Aprenda sobre Error Tracking Explorer - link: /monitors/types/error_tracking/ tag: Documentación - text: Crear un monitor de seguimiento de errores -title: Seguimiento de errores para servicios de backend + text: Cree un monitor de Error Tracking +title: Error Tracking para servicios de backend --- +## Descripción general {#overview} -## Información general - -{{< img src="error_tracking/error-tracking-overview-3.png" alt="Información detallada de un problema en el Explorador de seguimiento de errores" style="width:100%;" >}} +{{< img src="error_tracking/error-tracking-overview-3.png" alt="Los detalles de un problema en Error Tracking Explorer" style="width:100%;" >}} {{% error-tracking-description %}} -## Configuración +## Configuración {#setup} -Error Tracking está disponible para todos los lenguajes compatibles con APM. No requiere un SDK adicional ni cambios de configuración. +Error Tracking está disponible para todos los lenguajes compatibles con APM. No requiere SDK adicional ni cambios de configuración. -Opcionalmente, para ver fragmentos de código en trazas (traces) de stack tecnológico, configura la [integración de GitHub][4]. +Opcionalmente, para ver fragmentos de código en sus trazas de pila, configure la [integración con GitHub][4]. -{{< img src="tracing/error_tracking/inline_code_snippet_2.png" alt="Un fragmento de código en línea en una traza de stack tecnológico," style="width:70%;" >}} +{{< img src="tracing/error_tracking/inline_code_snippet_2.png" alt="Un fragmento de código en línea en una traza de pila" style="width:70%;" >}} -Para empezar a configurar tu repositorio, consulta la [documentación sobre la integración del código fuente][6]. +Para comenzar a configurar su repositorio, consulte la [documentación de integración de código fuente][6]. -## Uso de los atributos de tramos (spans) para realizar el seguimiento de tramos de errores +## Utilice atributos de tramo para realizar el seguimiento de tramos de error {#use-span-attributes-to-track-error-spans} -Los rastreadores de Datadog recopilan errores a través de las integraciones y de la instrumentación manual del código fuente de tus servicios backend. Un tramo de error debe contener los [atributos de tramo][1] `error.stack`, `error.message` y `error.type` para ser rastreado. Si un error se notifica varias veces dentro de un servicio, solo se conserva el error más destacado. +Los SDK de Datadog recopilan errores a través de integraciones y la instrumentación manual del código fuente de sus servicios de backend. Un tramo de error debe contener los [atributos de tramo][1] `error.stack`, `error.message` y `error.type`, y pertenecer a una traza completa para ser rastreado. Si un error se reporta varias veces dentro de un servicio, solo se conserva el error superior. -{{< img src="tracing/error_tracking/flamegraph_with_errors.png" alt="Gráfica de llamas con errores." style="width:100%;" >}} +
+El tracer de Go introdujo un cambio en los atributos utilizados para reportar trazas de pila en su versión v2.7.0. +Para versiones anteriores del tracer de Go (anteriores a la v2.7.0), la traza de pila se reporta en el error.stack atributo de tramo. +A partir de la versión v2.7.0, el tracer de Go reporta la traza de pila de manejo en el error.handling_stack atributo de tramo (con error.stack ahora transporta la traza de pila de lanzamiento cuando está disponible). +Consulte Stack Traces in Error Tracking para obtener más detalles. +
-El seguimiento de errores computa una huella digital para cada tramo de error. Procesa el tipo de error, el mensaje de error y los marcos que forman la traza de stack tecnológico,. Los errores con la misma huella digital se agrupan y pertenecen al mismo problema. Para obtener más información, consulta la [documentación de Trace Explorer][2]. +{{< img src="tracing/error_tracking/flamegraph_with_errors.png" alt="Flame graph con errores" style="width:100%;" >}} -## Examinar los problemas para comenzar a solucionarlos o a depurar +Error Tracking calcula una huella digital para cada tramo de error que procesa. La huella digital utiliza el tipo de error, el mensaje de error y los marcos que forman la traza de pila. Los errores con la misma huella digital se agrupan y pertenecen al mismo problema. Para obtener más información, consulte la [documentación de Trace Explorer][2]. -El seguimiento de errores categoriza automáticamente los errores de los problemas de los servicios de backend en [Error Tracking Explorer][5]. Consulta la [documentación de Error Tracking Explorer][3] para conocer las principales funciones. +## Controle qué errores se rastrean {#control-which-errors-are-tracked} -Los problemas creados a partir de APM incluyen la distribución de los tramos afectados, la última traza de stack tecnológico más relevante, los atributos de tramos, las etiquetas (tags) de hosts, las etiquetas de contenedores y las métricas. +Error Tracking procesa automáticamente todos los tramos de error, pero usted puede controlar qué errores se ingieren y cómo se gestionan: -## Referencias adicionales +- **Filtre errores con reglas de inclusión y exclusión**: Defina reglas para incluir o excluir errores según atributos como servicio, entorno o tipo de error. Consulte [Manage Data Collection][7]. +- **Establezca límites de tasa**: Controle el volumen de errores ingeridos por día para gestionar los costos. Consulte [Manage Data Collection][7]. +- **Excluya problemas específicos**: Marque los problemas recurrentes que no requieren acción como `EXCLUDED` para dejar de recopilarlos. Consulte [Issue States][8]. +- **Filtre trazas completas**: Evite que las trazas se envíen a Datadog (en lugar de filtrar errores). Consulte [Ignoring Unwanted Resources in APM][9]. -{{< partial name="whats-next/whats-next.html" >}} +## Examine los problemas para comenzar a solucionar o depurar {#examine-issues-to-start-troubleshooting-or-debugging} + +Error Tracking categoriza automáticamente los errores en problemas recopilados de sus servicios de backend en el [Error Tracking Explorer][5]. Consulte la [documentación del Error Tracking Explorer][3] para obtener un recorrido por las funciones clave. +Los problemas creados a partir de APM incluyen la distribución de los tramos afectados, la traza de pila más relevante y reciente, los atributos de tramo, las etiquetas de servidor, las etiquetas de contenedor y las métricas. + +## Lecturas adicionales {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} [1]: /es/tracing/visualization/trace/?tab=spantags#more-information [2]: /es/tracing/trace_explorer/trace_view/?tab=spantags [3]: /es/tracing/error_tracking/explorer [4]: /es/tracing [5]: https://app.datadoghq.com/apm/error-tracking -[6]: /es/integrations/guide/source-code-integration \ No newline at end of file +[6]: /es/integrations/guide/source-code-integration +[7]: /es/error_tracking/manage_data_collection/ +[8]: /es/error_tracking/issue_states/ +[9]: /es/tracing/guide/ignoring_apm_resources/ \ No newline at end of file diff --git a/hugo/content/fr/account_management/service-access-tokens.md b/hugo/content/fr/account_management/service-access-tokens.md new file mode 100644 index 00000000000..08cde378f14 --- /dev/null +++ b/hugo/content/fr/account_management/service-access-tokens.md @@ -0,0 +1,184 @@ +--- +description: Créez et gérez des jetons d'accès de service pour authentifier les appels + de Datadog API au nom d'un compte de service, sans dépendre des identifiants d'utilisateurs + individuels. +further_reading: +- link: /account_management/org_settings/service_accounts/ + tag: Documentation + text: Comptes de service +- link: /account_management/personal-access-tokens/ + tag: Documentation + text: Jetons d'accès personnels +- link: /account_management/workload_identity_federation/ + tag: Documentation + text: Fédération d'identités de charges de travail +- link: https://www.datadoghq.com/blog/datadog-api-authentication/ + tag: Blog + text: Modernisez l’authentification à la Datadog API avec des identifiants à portée + définie. +title: Les Jetons d'accès de service +--- +## Présentation {#overview} + +Les jetons d'accès de service sont des identifiants qui authentifient les appels de Datadog API au nom d'un +[compte de service][1]. Contrairement aux [jetons d'accès personnels (PAT)][2], les SAT appartiennent à un compte de service +plutôt qu'à un utilisateur individuel — ils restent valides lorsque des membres de l'équipe rejoignent ou quittent l'organisation. + +Avec les SAT, vous pouvez : +- Authentifier des workflows et des scripts automatisés avec des identifiants qui restent valides après le départ de membres de l'équipe de l'organisation. +- Créez des jetons à longue durée de vie pour des intégrations stables qui ne nécessitent pas de rotation périodique. +- Limitez les jetons aux autorisations minimales requises par votre workflow. +- Attribuez toute activité d'API au compte de service propriétaire pour une responsabilité d'audit claire. + +### Comparaison des SAT avec d'autres types d'identifiants {#sats-compared-to-other-credential-types} + +| | Jetons d'accès de service | Jetons d'accès personnels | Clés d'application | +|---|---|---|---| +| Propriétaire | Compte de service | Utilisateur individuel | Utilisateur individuel ou compte de service | +| Durée de vie (TTL) | Optionnel ; 1 jour, 1 mois, 1 an, Jamais ou Personnalisé | Requis ; 1 jour à 1 an | Aucune expiration | +| À portée définie par défaut | Oui ; les portées sont obligatoires | Oui ; les portées sont obligatoires | Optionnel ; sans portée par défaut | +| Authentification autonome | Oui ; aucune association de clé d'API nécessaire | Oui ; aucune association de clé d'API nécessaire | Non ; nécessite une clé d'API | +| Préfixe identifiable | `ddsat_` | `ddpat_` | `ddapp_` (nouveau) | +| Visible dans | Détails du compte de service, Paramètres de l'organisation > Jetons d'accès | Paramètres personnels > Jetons d'accès, Paramètres de l'organisation > Jetons d'accès | Paramètres personnels > Clés d'application, Paramètres de l'organisation > Clés d'application | + +Pour les jetons d'accès personnels, consultez [Jetons d'accès personnels][2]. + +## Prérequis {#prerequisites} + +- Un compte de service Datadog. Pour en créer un, consultez [Comptes de service][1]. +- L'autorisation `service_account_write` de créer des jetons d'accès de service pour un compte de service que vous gérez. +- L'autorisation `org_app_keys_write` de gérer des jetons d'accès de service pour tout compte de service dans l'organisation. + +## Créer un jeton d'accès de service {#create-a-service-access-token} + +1. Accédez à [**Paramètres de l'organisation** > **Comptes de service**][3] et cliquez sur un compte de service. +2. Dans le panneau des détails, sous **Jetons d'accès**, cliquez sur {{< ui >}}+ New Token{{< /ui >}}. +3. Saisissez un {{< ui >}}Name{{< /ui >}} pour le jeton. +4. Sélectionnez un {{< ui >}}Expiration Date{{< /ui >}} : **1 jour**, **1 mois**, **1 an**, **Jamais**, + ou **Personnalisé**. Sélectionnez **Jamais** pour un jeton sans expiration. +5. Cliquez sur {{< ui >}}Select Scopes{{< /ui >}} pour définir ce à quoi le jeton peut accéder. N'accordez que les + autorisations requises par votre workflow, puis cliquez sur {{< ui >}}Save{{< /ui >}}. + +
Datadog affiche le secret du jeton une seule fois au moment de la création. +Copiez-le et stockez-le en toute sécurité. Vous ne pourrez pas le récupérer ultérieurement.
+ +Après l'enregistrement, un panneau de détails affiche le secret du jeton, le nom, l'ID du jeton, le propriétaire, les rôles du propriétaire, +la date d'expiration et les portées. + +Si vous configurez un SAT avec une longue expiration ou si vous sélectionnez **Jamais**, stockez le secret dans un gestionnaire de secrets +tel qu'AWS Secrets Manager, HashiCorp Vault ou Azure Key Vault, au lieu de le stocker dans le code source +ou dans des fichiers d'environnement. AWS Secrets Manager prend en charge la [rotation gérée pour les identifiants de compte de service Datadog][8]. +identifiants de compte de service Datadog][8]. + +## Utiliser un jeton d'accès de service {#use-a-service-access-token} + +Les SAT prennent en charge deux méthodes d'authentification. + +### En-tête d'autorisation (recommandé) {#authorization-header-recommended} + +Transmettez le jeton d'accès de service en tant que jeton Bearer dans l'en-tête `Authorization`. Cette méthode ne nécessite pas de +Clé d'API : + +```bash +curl -X GET "https://api.datadoghq.com/api/v2/users" \ + -H "Authorization: Bearer " +``` + +### En-tête de clé d'application {#application-key-header} + +Transmettez le SAT dans l'en-tête `dd-application-key` : + +```bash +curl -X GET "https://api.datadoghq.com/api/v2/users" \ + -H "dd-application-key: " +``` + +**Remarque :** Lorsqu'un jeton d'accès de service valide est fourni dans l'en-tête `dd-application-key`, Datadog s'authentifie +uniquement avec le SAT. L'en-tête `dd-api-key` est facultatif et sa valeur n'est pas évaluée. + +## Restrictions sur les appels d'API authentifiés par SAT {#restrictions-on-sat-authenticated-api-calls} + +Pour empêcher l'élévation de privilèges, Datadog restreint les actions possibles pour un appel d'API authentifié avec un SAT. Ces restrictions s'appliquent quel que soit le client API effectuant l'appel : + +- **Clés d'application** : un jeton d'accès de service ne peut pas créer ni mettre à jour de clés d'application. La révocation des clés d'application est autorisée. +- **Portées sur les nouveaux jetons** : un jeton d'accès de service peut créer ou mettre à jour un autre jeton d'accès de service uniquement si les portées du nouveau jeton sont un sous-ensemble de ses propres portées. +- **Durée de vie (TTL) sur les nouveaux jetons** : un jeton d'accès de service ne peut pas créer un jeton d'accès de service avec une durée de vie qui dépasse sa propre expiration. + +Un appel qui enfreint l'une de ces restrictions renvoie une réponse `403 Forbidden`. + +## Gérer les jetons d'accès de service {#manage-service-access-tokens} + +### Afficher les jetons {#view-tokens} + +Les jetons d'un compte de service apparaissent dans le panneau des détails sous +[**Paramètres de l'organisation** > **Comptes de service**][3]. + +{{< img src="account_management/service-access-tokens/sat-service-account-panel.png" alt="Panneau des détails du compte de service affichant la section Jetons d'accès avec deux jetons d'accès de service listés." style="width:80%;" >}} + +Les administrateurs de l'organisation disposant de l'autorisation `org_app_keys_read` peuvent également afficher tous les jetons d'accès de service +ainsi que les jetons d'accès personnels depuis [**Paramètres de l'organisation** > **Jetons d'accès**][4]. + +### Révoquer un jeton {#revoke-a-token} + +1. Accédez à [**Paramètres de l'organisation** > **Comptes de service**][3] et cliquez sur le compte de service. +2. Dans le panneau des détails, survolez le jeton et cliquez sur {{< ui >}}Revoke{{< /ui >}}. + +Sinon, révoquez un SAT depuis [**Paramètres de l'organisation** > **Jetons d'accès**][4]. + +Les jetons révoqués ne peuvent plus authentifier les appels d'API. La révocation prend effet en quelques secondes. + +### Modifier un jeton {#edit-a-token} + +Vous pouvez mettre à jour le nom et les portées d'un SAT existant. Vous ne pouvez pas modifier la date d'expiration +après la création. Pour modifier l'expiration, révoquez le jeton et créez-en un nouveau. + +## Autorisations {#permissions} + +| Autorisation | Description | +|------------|-------------| +| `service_account_write` | Créer des jetons d'accès de service pour les comptes de service que vous gérez | +| `org_app_keys_read` | Afficher les jetons d'accès de service pour tous les comptes de service de l'organisation | +| `org_app_keys_write` | Créer, modifier et révoquer des jetons d'accès de service pour n'importe quel compte de service | + +Pour plus d'informations, consultez [Access Control basé sur les rôles][5]. + +## Audit Trail {#audit-trail} + +Si [Audit Trail][6] est activé, il enregistre toutes les créations, utilisations et révocations de SAT +événements. Chaque appel d'API authentifié avec un SAT est attribué au compte de service propriétaire. +Cela donne aux administrateurs une visibilité sur l'utilisation automatisée des identifiants dans toute l'organisation. + +Pour examiner l'activité des SAT, accédez à [**Security** > **Compliance** > **Audit Trail**][7] et +filtrez par la méthode d'authentification Service Access Token. + +## Référence de l'API {#api-reference} + +Gérez les SAT par programmation via Datadog API : + +| Opération | Endpoint | +|-----------|----------| +| Lister les jetons d'accès de service | `GET /api/v2/service_accounts//access_tokens` | +| Créer un jeton d'accès de service | `POST /api/v2/service_accounts//access_tokens` | +| Obtenir un jeton d'accès de service spécifique | `GET /api/v2/service_accounts//access_tokens/` | +| Mettre à jour un jeton d'accès de service | `PATCH /api/v2/service_accounts//access_tokens/` | +| Révoquer un jeton d'accès de service | `DELETE /api/v2/service_accounts//access_tokens/` | + +Pour récupérer tous les PAT et les jetons d'accès de service de l'ensemble des utilisateurs et des comptes de service en un seul appel, utilisez l'endpoint +unifié : + +``` +GET /api/v2/personal_access_tokens +``` + +## Lectures complémentaires {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /fr/account_management/org_settings/service_accounts/ +[2]: /fr/account_management/personal-access-tokens/ +[3]: https://app.datadoghq.com/organization-settings/service-accounts +[4]: https://app.datadoghq.com/organization-settings/access-tokens +[5]: /fr/account_management/rbac/permissions/ +[6]: /fr/account_management/audit_trail/ +[7]: https://app.datadoghq.com/audit-trail +[8]: https://aws.amazon.com/about-aws/whats-new/2026/05/secrets-manager-managed-external-secrets-datadog-snowflake/ \ No newline at end of file diff --git a/hugo/content/fr/actions/private_actions/authorize_private_actions.md b/hugo/content/fr/actions/private_actions/authorize_private_actions.md new file mode 100644 index 00000000000..d243e68c668 --- /dev/null +++ b/hugo/content/fr/actions/private_actions/authorize_private_actions.md @@ -0,0 +1,74 @@ +--- +description: Découvrez comment Datadog autorise les Private Actions à l'aide de politiques + d'exécution et de connexions. +disable_toc: false +further_reading: +- link: actions/private_actions/ + tag: Documentation + text: Présentation des Private Actions +- link: actions/private_actions/enroll_runner/ + tag: Documentation + text: Inscription et propriété +- link: actions/private_actions/set_up_agent_based/ + tag: Documentation + text: Configurez un exécuteur d'actions privé +- link: actions/private_actions/execution_policies/ + tag: Documentation + text: Politiques d'exécution +- link: actions/connections/ + tag: Documentation + text: Connexions +title: Autoriser les Private Actions +--- +## Présentation {#overview} + +Lorsque vos workflows et applications utilisent des Private Actions, Datadog décide si l'action est autorisée, puis votre **runner d'action privée** l'exécute. Avant qu'une tâche ne soit envoyée à un runner, Datadog vérifie si l'utilisateur demandeur est autorisé à agir sur ce runner. Si elle n'est pas autorisée, la tâche n'est jamais envoyée. + +Cette page explique comment cette décision d'autorisation est prise. Elle couvre les modèles que Datadog utilise pour autoriser ou refuser une action, et le modèle qui s'applique à votre runner. + +## Trouvez votre modèle d'autorisation {#find-your-authorization-model} + +Un runner est autorisé à l'aide de l'un des deux modèles : [**politiques d'exécution**](#execution-policies) ou [**connexions**](#connections). Le modèle est déterminé par la propriété du runner, définie une fois lors de l'inscription du runner. Un runner donné utilise exactement l'un de ces modèles pendant toute sa durée de vie ; vous ne pouvez pas combiner les deux sur le même runner. Comme la propriété est définie pour chaque runner, un seul parc basé sur l'Agent peut inclure à la fois des runners sans propriétaire et des runners avec propriétaire, chacun étant autorisé selon son propre modèle. + +- **Le runner dans le Datadog Agent** dépend de la manière dont il a été inscrit. Un runner d'Agent sans propriétaire utilise des [politiques d'exécution](#execution-policies) ; un runner d'Agent avec propriétaire utilise des [connexions](#connections). +- **Le runner autonome** est toujours avec propriétaire, il utilise donc toujours [Connections](#connections). + +Pour savoir comment l'inscription définit la propriété d'un runner, consultez [Inscription et propriété][1]. + +## Comparez les deux modèles {#compare-the-two-models} + +| | Politiques d'exécution | Connexions | +|---|---|---| +| **Fonctionne avec** | Runners dans le Datadog Agent uniquement | Runners autonomes et runners dans le Datadog Agent | +| **Comment l'accès est accordé** | Les tags de l'Agent ciblent un ou plusieurs ensembles de runners, de sorte qu'une politique gère l'accès à l'ensemble d'un parc au lieu d'une connexion distincte par intégration et par runner | Une connexion stocke des identifiants et les associe à un seul runner | +| **Credentials** | Les politiques d'exécution ne stockent aucun identifiant ; l'accès est accordé par les tags de l'Agent. Les actions nécessitant des identifiants (par exemple HTTP, GitLab et MongoDB) ne sont pas prises en charge. | La connexion contient les identifiants utilisés pour exécuter l'action | +| **Control** | Granulaire : autorisez ou refusez des actions spécifiques ou des ensembles d'actions, de même que des périmètres spécifiques à l'intégration, tels que les espaces de noms Kubernetes cibles pour une action Kubernetes | Par runner : une connexion cible un runner spécifique | + +## Politiques d'exécution {#execution-policies} + +Les **politiques d'exécution** sont un modèle d'autorisation pour les runners dans le Datadog Agent. Chaque politique gère l'accès à un ou plusieurs ensembles de runners à la fois. Au lieu d'une connexion distincte par intégration et par runner, vous utilisez des **tags de l'Agent** pour définir les Agents cibles. Vous leur associez ensuite une règle d'autorisation ou de refus. + +Les politiques d'exécution offrent également un contrôle granulaire. Une politique peut autoriser ou refuser des actions spécifiques ou des ensembles d'actions. Elle peut également appliquer des périmètres spécifiques à l'intégration, tels que les espaces de noms Kubernetes cibles pour une action Kubernetes. L'accès est accordé via des tags de l'Agent plutôt que par des identifiants stockés ; ainsi, les politiques d'exécution ne stockent aucun identifiant et sont utilisées par des runners sans propriétaire dans l'Agent. + +Pour en savoir plus sur les politiques d'exécution et leur configuration (cibles, règles, contrôle d'accès et utilisation de politiques d'exécution dans les workflows), consultez [Politiques d'exécution][2]. + +## Connexions {#connections} + +Les connexions fonctionnent à la fois pour les runners autonomes et les runners dans le Datadog Agent, et constituent le modèle utilisé par les runners avec propriétaire. + +Une connexion remplit deux fonctions : + +- **Elle fait référence aux identifiants** nécessaires pour exécuter une action sur votre service. Les identifiants eux-mêmes (par exemple un API token, ou un nom d'utilisateur et un mot de passe) sont stockés localement avec le runner, dans un fichier d'identifiants sur son host ou conteneur ; la connexion y fait référence. +- **Elle associe ces identifiants à un seul runner.** Une connexion cible un seul runner, de sorte que les identifiants ne sont utilisés que par le runner que vous avez prévu. + +Pour utiliser une connexion dans un workflow ou une application, vous devez disposer de l'autorisation appropriée pour cette connexion. L'accès à une connexion peut être restreint afin que seules les personnes qui en ont besoin puissent l'utiliser dans leurs workflows et leurs applications. + +Pour obtenir les instructions de configuration complètes (création, modification et restriction des connexions, tags d'identifiant de connexion et groupes de connexion), consultez [Connexions][3]. + +## Pour aller plus loin {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /fr/actions/private_actions/enroll_runner/ +[2]: /fr/actions/private_actions/execution_policies/ +[3]: /fr/actions/connections/ \ No newline at end of file diff --git a/hugo/content/fr/actions/private_actions/run_script.md b/hugo/content/fr/actions/private_actions/run_script.md new file mode 100644 index 00000000000..0d9c1f97c8f --- /dev/null +++ b/hugo/content/fr/actions/private_actions/run_script.md @@ -0,0 +1,356 @@ +--- +description: Utilisez l'exécuteur d'actions privé pour exécuter des scripts prédéfinis + dans votre réseau privé, y compris la configuration requise pour les exécuteurs + sans propriétaire autorisés par une stratégie d'exécution. +further_reading: +- link: actions/private_actions/set_up_agent_based + tag: Documentation + text: Mettez en place un exécuteur d'actions privé dans le Datadog Agent +- link: actions/private_actions/execution_policies + tag: Documentation + text: Politiques d'exécution +- link: actions/private_actions/reference + tag: Documentation + text: Références +title: Exécuter un script avec l'exécuteur d'actions privé +--- +## Présentation {#overview} + +L'exécuteur d'actions privé peut exécuter des **scripts prédéfinis**, qui sont des commandes shell, des outils de ligne de commande et des scripts que vous déclarez à l'avance dans un fichier de configuration de script. Seul ce que vous prédéfinissez peut être exécuté, de sorte que l'exécuteur n'exécute jamais de commandes en ligne arbitraires provenant d'un workflow ou d'une application. + +
Vous décidez quelles commandes et quels binaires l'exécuteur est autorisé à exécuter. Examinez chaque commande que vous ajoutez à la configuration du script, en particulier celles qui acceptent des paramètres, n'accordez à l'exécuteur que les privilèges dont il a besoin, et examinez attentivement les autorisations que vous partagez via les connexions. Voir les considérations de sécurité des connexions.
+ +## Cas d'utilisation {#use-cases} + +| Cas d'utilisation | Basé sur l'Agent | Autonome | Notes | +|---|:---:|:---:|---| +| Exécution de binaires Linux (`ls`, `rm`, `find`, `curl`) | {{< X >}} | {{< X >}} | Pour les exécuteurs autonomes, les fichiers pertinents doivent être accessibles au conteneur. | +| Exécution d'interfaces de ligne de commande (`aws`, `terraform`, `kubectl`) | {{< X >}} | {{< X >}} | Pour les exécuteurs autonomes, l'interface de ligne de commande et les identifiants doivent être disponibles dans l'image. Pour les exécuteurs basés sur l'Agent, les outils doivent être installés sur le host. | +| Exécution de scripts bash | {{< X >}} | {{< X >}} | Pour les exécuteurs autonomes, les scripts peuvent être montés à l'intérieur du conteneur. Utilisez la [grande image](#large-image) pour un interpréteur Python. | +| Exécution de scripts PowerShell | {{< X >}} | | Pris en charge uniquement sur les exécuteurs Windows basés sur l'Agent. | +| Exécution de commandes privilégiées (`systemctl restart`) | {{< X >}} | | Pour les exécuteurs basés sur l'Agent, accordez des autorisations à l'utilisateur de l'exécuteur. Le sandboxing de conteneur empêche les exécuteurs autonomes d'accéder au host avec des privilèges. | + +## Prérequis {#prerequisites} + +**Pour les exécuteurs basés sur l'Agent :** +- Datadog Agent 7.81.0 ou version ultérieure. Consultez [Configurer un exécuteur d'actions privé dans le Datadog Agent][1]. +- Ajoutez `com.datadoghq.script.runPredefinedScript` (Linux) ou `com.datadoghq.script.runPredefinedPowershellScript` (Windows) à la liste d'autorisation des actions de l'exécuteur. + +**Pour les exécuteurs autonomes :** +- Un exécuteur autonome. Consultez [Configurer un exécuteur d'actions privé autonome][2]. +- Pour les outils CLI non inclus dans l'image de base ou dans la [grande image](#large-image), une image Docker personnalisée. Consultez [Images personnalisées](#custom-images). + +## Basé sur l'Agent {#agent-based} + +### Configurer les scripts {#configure-scripts} + +{{< tabs >}} +{{% tab "Linux" %}} + +Modifiez le fichier `/etc/datadog-agent/private-action-runner/script-config.yaml` : + +```yaml +schemaId: script-credentials-v1 +runPredefinedScript: + echo: + command: ["echo", "Hello world!"] + echo-parametrized: + command: ["echo", "{{ parameters.echoValue }}"] + restart-service: + command: ["sudo", "systemctl", "restart", "{{ parameters.service }}"] +``` + +{{% /tab %}} +{{% tab "Windows" %}} + +Modifiez le fichier `C:\ProgramData\Datadog\private-action-runner\powershell-script-config.yaml` : + +```yaml +schemaId: script-credentials-v1 +runPredefinedPowershellScript: + helloWorld: + script: | + Write-Output "Hello world!" + greet: + script: | + Write-Output "Run script from workflow called {{ parameters.name }} !" + parameterSchema: + properties: + name: + type: string + required: + - name + restartService: + script: | + Restart-Service -Name {{ parameters.serviceName }} -Force + parameterSchema: + properties: + serviceName: + type: string + required: + - serviceName +``` + +{{% /tab %}} +{{< /tabs >}} + +Dans un workflow ou une application, référencez un script par le nom que vous avez défini (par exemple, `echo`). Utilisez `runPredefinedScript` sur les exécuteurs Linux et `runPredefinedPowershellScript` sur les exécuteurs Windows. + +### Accorder des autorisations {#grant-permissions} + +{{< tabs >}} +{{% tab "Linux" %}} + +L'exécuteur exécute les scripts en tant qu'utilisateur `dd-agent`. Si vos scripts nécessitent des autorisations élevées, accordez-les à l'utilisateur `dd-agent` : + +```bash +echo "dd-agent ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx" > /etc/sudoers.d/dd-agent +chmod 440 /etc/sudoers.d/dd-agent +``` + +{{% /tab %}} +{{% tab "Windows" %}} + +L'exécuteur exécute les scripts en tant que `ddagentuser`. Si vos scripts nécessitent l'accès à certaines ressources, accordez à l'utilisateur `ddagentuser` des autorisations élevées pour y accéder : + +```powershell +icacls "C:\" /grant "ddagentuser:(OI)(CI)RX" /T + +# Verify permissions +icacls "C:\" +``` + +{{% /tab %}} +{{< /tabs >}} + +### Exécuteur sans propriétaire (autorisé par la politique d'exécution) {#ownerless-runner-execution-policy-authorized} + +Lorsqu'un exécuteur est inscrit en mode sans propriétaire et autorisé par [Politiques d'exécution][3], deux éléments supplémentaires sont requis en plus des étapes ci-dessus : + +- L'intégration **Script** doit être autorisée pour l'exécuteur via une politique d'exécution, en plus de ce que l'action predefined-script figure dans la liste d'autorisation des actions de l'exécuteur. +- L'exécuteur lit ses scripts prédéfinis à partir d'un **chemin fixe**, le même chemin utilisé dans [Configurer les scripts](#configure-scripts) ci-dessus : + +{{< tabs >}} +{{% tab "Linux" %}} + +`/etc/datadog-agent/private-action-runner/script-config.yaml` + +{{% /tab %}} +{{% tab "Windows" %}} + +`C:\ProgramData\Datadog\private-action-runner\powershell-script-config.yaml` + +{{% /tab %}} +{{< /tabs >}} + +#### Livraison de la configuration sur Kubernetes {#delivering-the-config-on-kubernetes} + +Sur Kubernetes, fournissez le fichier de configuration de script à l'exécuteur dans le Datadog Agent sous forme de ConfigMap. Montez-le dans le conteneur de l'exécuteur au chemin fixe. L'exécuteur du Cluster Agent utilise le chemin Linux ci-dessus. + +Tout d'abord, créez une ConfigMap contenant votre configuration de script : + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: par-script-config + namespace: datadog +data: + script-config.yaml: | + schemaId: script-credentials-v1 + runPredefinedScript: + echo: + command: ["echo", "Hello world!"] +``` + +Ensuite, sur la ressource `DatadogAgent`, autorisez l'action predefined-script et montez la ConfigMap dans le conteneur de l'exécuteur au chemin fixe : + +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog + annotations: + agent.datadoghq.com/private-action-runner-enabled: "true" + agent.datadoghq.com/private-action-runner-configdata: | + private_action_runner: + enabled: true + api_key_only_enrollment: true + actions_allowlist: + - "com.datadoghq.script.runPredefinedScript" + - "com.datadoghq.kubernetes.*" + - "com.datadoghq.remoteaction.*" +spec: + override: + nodeAgent: + volumes: + - name: par-script-config + configMap: + name: par-script-config + containers: + private-action-runner: + volumeMounts: + - name: par-script-config + mountPath: /etc/datadog-agent/private-action-runner/script-config.yaml + subPath: script-config.yaml + readOnly: true +``` + +Enfin, appliquez le manifeste : + +```bash +kubectl apply -f datadog-agent.yaml +``` + +### Exécuteur détenu (basé sur une connexion) {#owned-runner-connection-based} + +{{< tabs >}} +{{% tab "Linux" %}} + +#### Configurer la connexion {#configure-the-connection} + +Si vous avez sélectionné `com.datadoghq.script.runPredefinedScript` dans la liste d'autorisation des actions de l'exécuteur, vous devriez déjà avoir une connexion **Script** liée à votre exécuteur. Sinon, créez une connexion et spécifiez `/etc/datadog-agent/private-action-runner/script-config.yaml` comme **chemin vers le fichier**. Pour plus d'informations, consultez [Gestion des identifiants d'action privés][4]. + +{{% /tab %}} +{{% tab "Windows" %}} + +#### Configurer la connexion {#configure-the-connection-1} + +Si vous avez sélectionné `com.datadoghq.script.runPredefinedPowershellScript` dans la liste d'autorisation des actions de l'exécuteur, vous devriez déjà avoir une connexion **Script** liée à votre exécuteur. Sinon, créez une connexion et spécifiez `C:\ProgramData\Datadog\private-action-runner\powershell-script-config.yaml` comme **chemin vers le fichier**. Pour plus d'informations, consultez [Gestion des identifiants d'action privés][4]. + +{{% /tab %}} +{{< /tabs >}} + +## Autonome {#standalone} + +Un exécuteur autonome est toujours détenu et autorisé avec des [Connexions][5]. + +{{< tabs >}} +{{% tab "Docker" %}} + +1. Après avoir [configuré un exécuteur][2], accédez à **Connections**. +1. Cliquez sur **New Connection** et sélectionnez **Script**. +1. Saisissez un nom de connexion et, dans la liste déroulante **Private Action Runner**, sélectionnez votre exécuteur. +1. Copiez le modèle de fichier d'identification dans le répertoire de configuration de votre exécuteur avec les commandes que vous souhaitez exécuter. +1. Dans **Path to file**, confirmez que le chemin d'accès au fichier correspond au chemin sur le système de fichiers de votre exécuteur (la valeur par défaut suffit dans la plupart des cas). +1. Cliquez sur **Next, Confirm Access**, configurez les autorisations, puis cliquez sur **Create**. +1. Sélectionnez cette connexion lors de l'utilisation de l'action de script dans vos workflows ou applications. + +Configurez les actions de script via le fichier `config.yaml` de votre exécuteur et la connexion de script +(`credentials/script.yaml` par défaut) : + +```yaml +# Add the script action to the allowlist (config.yaml) +actionsAllowlist: + - com.datadoghq.script.runPredefinedScript +``` + +```yaml +# Configure your script connection (credentials/script.yaml) +schemaId: script-credentials-v1 +runPredefinedScript: + echo: + command: ["echo", "Hello world"] + echo-parametrized: + command: ["echo", "{{ parameters.echoValue }}"] + parameterSchema: + properties: + echoValue: + type: string + required: + - echoValue +``` + +{{% /tab %}} +{{% tab "Kubernetes (Helm)" %}} + +Lors du déploiement de l'exécuteur avec Helm, configurez les scripts via votre fichier `values.yaml` : + +```yaml +common: + actionsAllowlist: + - com.datadoghq.script.runPredefinedScript + +credentials: + script: + schemaId: script-credentials-v1 + runPredefinedScript: + echo: + command: ["echo", "Hello world"] + echo-parametrized: + command: ["echo", "{{ parameters.echoValue }}"] + parameterSchema: + properties: + echoValue: + type: string + required: + - echoValue +``` + +Déployez ou mettez à niveau l'exécuteur : + +```bash +helm upgrade --install datadog/private-action-runner -f ./values.yaml +``` + +{{% /tab %}} +{{< /tabs >}} + +### Options d'image de l'exécuteur {#runner-image-options} + +Les options suivantes sont disponibles uniquement pour les exécuteurs autonomes. + +#### Grande image {#large-image} + +Si vous souhaitez utiliser des outils tels que Python, SSH, l'AWS CLI, Terraform ou la gcloud CLI, utilisez l'image `gcr.io/datadoghq/private-action-runner:v`{{< private-action-runner-version "private-action-runner" >}}-large au lieu de l'image par défaut. + +#### Images personnalisées {#custom-images} + +Pour les binaires non disponibles dans les images fournies par Datadog, créez une image personnalisée : + +```dockerfile +FROM gcr.io/datadoghq/private-action-runner:v{{< private-action-runner-version "private-action-runner" >}} +USER root +# Change the line below to install the tool of your choice +RUN apt update && apt install -y python3 +USER dog +``` + +Vous pouvez monter des scripts complexes à l'intérieur de l'exécuteur : + +```yaml +# docker-compose example +services: + runner: + build: . # if you are using a local Dockerfile + volumes: + - "./config:/etc/dd-action-runner/config" # contains credentials for actions + - "./scripts:/etc/dd-action-runner-script/scripts" # contains dependencies for script actions +``` + +```yaml +# credentials/script.yaml +schemaId: script-credentials-v1 +runPredefinedScript: + python: + command: ["python3", "/etc/dd-action-runner-script/scripts/script.py"] + shell: + command: ["bash", "/etc/dd-action-runner-script/scripts/script.sh"] +``` + +## Utilisation des scripts configurés {#using-the-configured-scripts} + +Dans votre workflow ou application, configurez l'action pour utiliser le nom de script que vous avez défini (par exemple, `echo` ou `echo-parametrized`). Pour les exécuteurs Linux, utilisez `runPredefinedScript`. Pour les exécuteurs Windows, utilisez `runPredefinedPowershellScript`. + +Il existe deux niveaux de résolution de variable : un au niveau du workflow et un au niveau de l'action +à l'intérieur de l'exécuteur. + +## Pour aller plus loin {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /fr/actions/private_actions/set_up_agent_based/ +[2]: /fr/actions/private_actions/set_up_standalone/ +[3]: /fr/actions/private_actions/execution_policies/ +[4]: /fr/actions/connections/private_action_credentials/ +[5]: /fr/actions/connections/ \ No newline at end of file diff --git a/hugo/content/fr/actions/private_actions/set_up_agent_based.md b/hugo/content/fr/actions/private_actions/set_up_agent_based.md new file mode 100644 index 00000000000..e5366203ac7 --- /dev/null +++ b/hugo/content/fr/actions/private_actions/set_up_agent_based.md @@ -0,0 +1,445 @@ +--- +aliases: +- /fr/service_management/workflows/private_actions/use_private_actions +- /fr/service_management/app_builder/private_actions/use_private_actions +- /fr/actions/private_actions/use_private_actions/ +- /fr/actions/private_actions/update_private_action_runner/ +description: Installez, enrôlez, gérez et mettez à jour un private action runner qui + s'exécute au sein du Datadog Agent. +disable_toc: false +further_reading: +- link: actions/private_actions/ + tag: Documentation + text: Private Actions +- link: actions/private_actions/enroll_runner + tag: Documentation + text: Inscription et propriété +- link: actions/private_actions/execution_policies + tag: Documentation + text: Politiques d'exécution +- link: actions/private_actions/set_up_standalone + tag: Documentation + text: Configurez un private action runner autonome. +title: Configurez un private action runner dans le Datadog Agent. +--- +## Présentation {#overview} + +L'exécution du private action runner dans le Datadog Agent est la méthode recommandée pour les nouveaux déploiements. Si vous exécutez déjà le Datadog Agent, activez le runner avec un seul configuration flag et gérez-le via le cycle de vie de l'Agent. + +La configuration du runner se fait en trois étapes : + +1. [**Installez**](#install-the-runner) le runner, en utilisant l'option de déploiement adaptée à votre environnement. +1. [**Enrôlez**](#enroll-the-runner) le runner, ce qui définit sa propriété et le modèle d'autorisation qu'il utilise. +1. [**Mettez à jour**](#update-the-runner) le runner dans le cadre de vos mises à niveau de l'Agent. + +Pour déployer le runner en tant que binaire séparé à la place, consultez [Configurez un private action runner autonome][1]. + +## Prérequis {#prerequisites} + +- Un host Linux ou Windows avec **Datadog Agent 7.81.0 ou version ultérieure**, ou un cluster Kubernetes avec **Datadog Operator v1.28.0 ou version ultérieure** ou le **Datadog Helm chart 3.231.6 ou version ultérieure**. +- [Remote Configuration][2] activée pour votre organisation. +- Accès réseau à Datadog sur `https://{{< region-param key=dd_site >}}`. + +## Installez le runner {#install-the-runner} + +Le runner dans le Datadog Agent offre trois options de déploiement, selon l'endroit où il doit agir : + +| Option de déploiement | Mode d'exécution | Déployer avec | Idéal pour | +|---|---|---|---| +| **Host** | Un processus séparé à côté du Datadog Agent sur un host Linux ou Windows. | Installation sur le host | Actions ciblant un host spécifique. | +| **Agent de nœud Kubernetes** | Un conteneur dans l'Agent de nœud, utilisant le même binaire de runner que le processus du host. | Helm, Operator | Actions locales au nœud dans un cluster Kubernetes. | +| **Kubernetes Cluster Agent** | Exécuté in-process à l'intérieur du Cluster Agent, sans binaire séparé. Un runner dessert l'ensemble du cluster. | Helm, Opérateur | Actions Kubernetes à l'échelle du cluster. | + +Vous avez la possibilité d'installer avec **Fleet Automation**, un flux piloté par l'interface utilisateur qui enrôle le runner comme détenu, ou **Installation manuelle**, où vous choisissez vous-même le type d'enrôlement. + +### Utilisation de Fleet Automation (recommandé) {#using-fleet-automation-recommended} + +Le flux d'installation de Fleet Automation est le même sur toutes les plateformes. + +1. Accédez à la [page d'installation de Fleet Automation][3] et sélectionnez votre plateforme. Pour Kubernetes, sélectionnez également **Helm Chart** ou **Datadog Operator** comme méthode d'installation, afin de correspondre à l'onglet [Installation manuelle](#manual-installation) que vous prévoyez de suivre. +1. Dans **Personnalisez votre couverture d'Agent**, accédez à la section **Optimisation et remédiation** et activez **Autoriser l'Agent à effectuer des actions**. Cela crée une clé d'application avec le périmètre `on_prem_runner_write` et enrôle le runner comme **détenu**, autorisé avec [Connections][4]. Pour inscrire plutôt un runner sans propriétaire, autorisé avec [Politiques d'exécution][5], utilisez [Installation manuelle](#manual-installation). +1. Suivez les instructions restantes dans le panneau d'installation pour ajouter une clé d'API et terminer l'installation. +1. Après l'installation, accédez à [Private Action Runners][6] pour vérifier que votre runner apparaît dans la liste. + +### Installation manuelle {#manual-installation} + +{{< tabs >}} +{{% tab "Linux" %}} +Définissez les variables d'environnement suivantes lors de l'installation ou de l'exécution de l'Agent. Sur le host, les paramètres du runner utilisent le préfixe `DD_PRIVATE_ACTION_RUNNER_*` : + +```bash +DD_API_KEY= \ +DD_APP_KEY= \ +DD_SITE="{{< region-param key=dd_site >}}" \ +DD_PRIVATE_ACTION_RUNNER_ENABLED=true \ +DD_PRIVATE_ACTION_RUNNER_ACTIONS_ALLOWLIST=com.datadoghq.kubernetes.*,com.datadoghq.remoteaction.* \ +bash -c "$(curl -L https://install.datadoghq.com/scripts/install_script_agent7.sh)" +``` + +`DD_APP_KEY` enrôle le runner comme détenu, tout comme Fleet Automation. La clé d'application nécessite le périmètre `on_prem_runner_write`. `DD_PRIVATE_ACTION_RUNNER_ACTIONS_ALLOWLIST` accepte une liste séparée par des virgules. Utilisez des caractères génériques de bundle pour autoriser les actions qu'un runner dans le Datadog Agent peut exécuter : `com.datadoghq.kubernetes.*` et `com.datadoghq.remoteaction.*`. Pour utiliser plutôt les actions par défaut intégrées du runner (actions Remote Action en lecture seule, ainsi qu'un ensemble d'actions Kubernetes en lecture seule sur le Cluster Agent), laissez la liste d'autorisation non définie. + +Après l'installation, accédez à [Private Action Runners][1] pour vérifier que votre runner apparaît dans la liste. + +[1]: https://app.datadoghq.com/actions/action-catalog + +{{% /tab %}} +{{% tab "Windows" %}} + +Installez ou mettez à niveau vers le Datadog Agent 7.81.0 ou une version ultérieure, puis modifiez `C:\ProgramData\Datadog\datadog.yaml` : + +```yaml +app_key: + +private_action_runner: + enabled: true + self_enroll: true + actions_allowlist: + - "com.datadoghq.kubernetes.*" + - "com.datadoghq.remoteaction.*" +``` + +`app_key` enrôle le runner comme détenu, de la même manière que Fleet Automation ci-dessus ; la clé d'application nécessite le périmètre `on_prem_runner_write`. + +Redémarrez l'Agent pour appliquer la configuration : + +```powershell +Restart-Service -Force datadogagent +``` + +Une fois l'Agent redémarré, accédez à [Private Action Runners][1] pour vérifier que votre runner apparaît dans la liste. + +Le processus du host exécute le runner **node Agent**. Pour exécuter un runner dans le Cluster Agent, utilisez l'onglet Kubernetes (Helm) ou Kubernetes (Operator). + +[1]: https://app.datadoghq.com/actions/action-catalog + +{{% /tab %}} +{{% tab "Kubernetes (Helm)" %}} + +Le Datadog Helm chart peut activer le runner à deux endroits : + +- Le runner **node Agent**, en tant que conteneur sidecar. Le runner node Agent est **uniquement disponible sur Linux**. +- Le runner **Cluster Agent**, en cours d'exécution. Le runner Cluster Agent est disponible uniquement via Helm ou l'Operator (il n'existe pas de binaire autonome), et il nécessite une élection de leader afin que l'identité soit coordonnée entre les réplicas du Cluster Agent. + +Créez une clé d'API avec la fonctionnalité Private Action Runner dans [Organization Settings][1], puis stockez-la dans un secret Kubernetes que le chart lit via `apiKeyExistingSecret` : + +```bash +kubectl create secret generic datadog-secret \ + --from-literal api-key= +``` + +Cet exemple enrôle le runner comme **sans propriétaire** (`apiKeyOnlyEnrollment: true`, en utilisant uniquement la clé d'API), ce qui l'autorise avec des [politiques d'exécution][5]. Pour d'autres options d'enrôlement et pour savoir comment fonctionne la propriété, consultez [Enrollment and ownership][2]. + +Les paramètres Helm utilisent la clé `privateActionRunner.*` en camelCase. Créez un `values.yaml` : + +```yaml +datadog: + apiKeyExistingSecret: datadog-secret + site: {{< region-param key=dd_site >}} + clusterName: + remoteConfiguration: + enabled: true + privateActionRunner: + enabled: true + apiKeyOnlyEnrollment: true + actionsAllowlist: + - "com.datadoghq.remoteaction.*" + - "com.datadoghq.script.*" +clusterAgent: + enabled: true + privateActionRunner: + enabled: true + apiKeyOnlyEnrollment: true + actionsAllowlist: + - "com.datadoghq.kubernetes.*" + - "com.datadoghq.script.*" +``` + +Pour toutes les options de configuration disponibles du runner, consultez [`datadog.privateActionRunner`][3] et [`clusterAgent.privateActionRunner`][4] dans le Datadog Helm chart. Installez le chart : + +```bash +helm repo add datadog https://helm.datadoghq.com +helm repo update +helm install datadog-agent datadog/datadog -f values.yaml +``` + +Après l'installation, accédez à [Private Action Runners][5] pour vérifier que votre runner apparaît dans la liste. + +[1]: https://app.datadoghq.com/organization-settings/api-keys +[2]: /fr/actions/private_actions/enroll_runner/ +[3]: https://github.com/DataDog/helm-charts/blob/main/charts/datadog/values.yaml#L523 +[4]: https://github.com/DataDog/helm-charts/blob/main/charts/datadog/values.yaml#L1842 +[5]: https://app.datadoghq.com/actions/action-catalog + +{{% /tab %}} +{{% tab "Kubernetes (Operator)" %}} + +Le Datadog Operator active le runner via des annotations sur la ressource `DatadogAgent`. La configuration du runner dans l'annotation `-configdata` utilise la clé `private_action_runner.*` en snake_case. L'Operator peut activer à la fois le node Agent runner et le Cluster Agent runner. + +Créez une clé d'API avec la fonctionnalité Private Action Runner dans [Organization Settings][1], puis stockez-la dans un secret Kubernetes que la ressource `DatadogAgent` lit via son `credentials` : + +```bash +kubectl create secret generic datadog-secret \ + --from-literal api-key= +``` + +Cet exemple enrôle le runner comme **sans propriétaire** (`api_key_only_enrollment: true`, en utilisant uniquement la clé d'API), ce qui l'autorise avec des [politiques d'exécution][5]. Pour d'autres options d'enrôlement et pour savoir comment fonctionne la propriété, consultez [Enrollment and ownership][2]. + +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog + annotations: + agent.datadoghq.com/private-action-runner-enabled: "true" + agent.datadoghq.com/private-action-runner-configdata: | + private_action_runner: + enabled: true + api_key_only_enrollment: true + actions_allowlist: + - "com.datadoghq.remoteaction.*" + - "com.datadoghq.script.*" + cluster-agent.datadoghq.com/private-action-runner-enabled: "true" + cluster-agent.datadoghq.com/private-action-runner-configdata: | + private_action_runner: + enabled: true + api_key_only_enrollment: true + actions_allowlist: + - "com.datadoghq.kubernetes.*" + - "com.datadoghq.script.*" +spec: + global: + clusterName: + site: {{< region-param key=dd_site >}} + credentials: + apiSecret: + secretName: datadog-secret + keyName: api-key +``` + +Appliquez le manifeste : + +```bash +kubectl apply -f datadog-agent.yaml +``` + +Comme pour Helm, le Cluster Agent runner nécessite une élection de leader, et le node Agent runner est réservé à Linux. Après avoir appliqué le manifeste, accédez à [Private Action Runners][3] pour vérifier que votre runner apparaît dans la liste. + +[1]: https://app.datadoghq.com/organization-settings/api-keys +[2]: /fr/actions/private_actions/enroll_runner/ +[3]: https://app.datadoghq.com/actions/action-catalog + +{{% /tab %}} +{{< /tabs >}} + +### Noms des champs de configuration {#configuration-field-names} + +Les paramètres du runner suivent les conventions de configuration standard du Datadog Agent pour chaque méthode d'installation : +- Variables d'environnement sur un host. +- Clés CamelCase sous `privateActionRunner` dans Helm. +- Clés snake_case sous `private_action_runner` dans l'Operator. + +Pour le tableau de correspondance des noms de champs pour les trois méthodes d'installation et la liste complète des clés de configuration et des valeurs par défaut, consultez la [Référence du Private Action Runner][7]. + +## Enregistrez le runner {#enroll-the-runner} + +L'enrôlement enregistre le runner auprès de votre organisation Datadog et définit sa **propriété**, ce qui détermine le modèle d'autorisation. Un runner sans propriétaire, enrôlé avec une clé d'API disposant de la fonctionnalité Private Action Runner, utilise des [politiques d'exécution][5]. Un runner possédé, enrôlé avec une clé d'application, utilise [Connections][4]. Comme le modèle est fixé lors de l'enrôlement, décidez lequel vous souhaitez avant de déployer. + +Pour plus d'informations sur le processus, consultez [Inscription et propriété][8]. + +## Gérer le runner {#manage-the-runner} + +### Modifier la liste d'autorisation {#change-the-allowlist} + +Pour modifier la liste d'autorisation d'un runner dans le Datadog Agent : + +{{< tabs >}} +{{% tab "Linux" %}} +1. Modifiez la section `private_action_runner.actions_allowlist` dans `/etc/datadog-agent/datadog.yaml`. +1. Redémarrez l'Agent : `sudo systemctl restart datadog-agent`. +{{% /tab %}} +{{% tab "Windows" %}} +1. Modifiez la section `private_action_runner.actions_allowlist` dans `C:\ProgramData\Datadog\datadog.yaml`. +1. Redémarrez l'Agent : `Restart-Service -Force datadogagent`. +{{% /tab %}} +{{% tab "Kubernetes (Operator)" %}} +1. Mettez à jour `actions_allowlist` dans les deux annotations du manifeste `DatadogAgent` : `agent.datadoghq.com/private-action-runner-configdata` et `cluster-agent.datadoghq.com/private-action-runner-configdata`. +1. Appliquez le manifeste mis à jour : `kubectl apply -f datadog-agent.yaml`. +{{% /tab %}} +{{% tab "Kubernetes (Helm)" %}} +1. Mettez à jour `privateActionRunner.actionsAllowlist` (node Agent) ou `clusterAgent.privateActionRunner.actionsAllowlist` (Cluster Agent) dans `values.yaml`. +1. Appliquez le chart mis à jour : `helm upgrade datadog-agent datadog/datadog -f values.yaml`. +{{% /tab %}} +{{< /tabs >}} + +### Suppression automatique des runners inactifs {#automatic-deletion-of-inactive-runners} + +Pour libérer des ressources inutilisées, Datadog supprime automatiquement les private action runners basés sur le node Agent qui utilisent une configuration à clé d'API uniquement (sans propriétaire) après 35 jours d'inactivité. Ce nettoyage automatique ne s'applique pas aux runners avec propriétaire ni au Cluster Agent runner. + +Si votre runner est supprimé en raison d'une inactivité, le redémarrer entraîne une erreur. Vous devez réinscrire le runner en répétant les étapes d'installation. + +## Débogage avec les logs {#debugging-with-logs} + +{{< tabs >}} +{{% tab "Linux" %}} + +```bash +cat /var/log/datadog/private-action-runner.log +``` + +{{% /tab %}} +{{% tab "Windows" %}} + +```powershell +Get-Content C:\ProgramData\Datadog\logs\private-action-runner.log +``` + +{{% /tab %}} +{{% tab "Kubernetes" %}} + +```bash +kubectl logs -l app.kubernetes.io/component=cluster-agent --tail=1000 | grep private +``` + +{{% /tab %}} +{{< /tabs >}} + +## Mettez à jour le runner {#update-the-runner} + +Mettez à jour le runner dans le Datadog Agent pour rester à jour avec toutes les mises à niveau de l'Agent. + +{{< tabs >}} +{{% tab "Linux" %}} + +Mettez à niveau le Datadog Agent vers la dernière version. Le runner est fourni avec l'Agent. + +```bash +sudo apt-get update && sudo apt-get install datadog-agent +``` + +Ou pour RHEL/CentOS : + +```bash +sudo yum update datadog-agent +``` + +Redémarrez l'Agent après la mise à niveau : + +```bash +sudo systemctl restart datadog-agent +``` + +Pour des instructions de mise à niveau détaillées, consultez [Mise à niveau vers l'Agent v7][1]. + +[1]: /fr/agent/versions/upgrade_to_agent_v7/ + +{{% /tab %}} +{{% tab "Windows" %}} + +Téléchargez le dernier programme d'installation MSI de l'Agent depuis la [page de téléchargement du Datadog Agent][1] et exécutez-le, ou utilisez PowerShell : + +```powershell +# Download the latest installer +Invoke-WebRequest -Uri "https://s3.amazonaws.com/ddagent-windows-stable/ddagent-cli-latest.msi" -OutFile ddagent-cli-latest.msi + +# Run the installer +Start-Process -Wait -PassThru msiexec -ArgumentList '/qn /i ddagent-cli-latest.msi' +``` + +Redémarrez l'Agent après la mise à niveau : + +```powershell +Restart-Service -Force datadogagent +``` + +[1]: https://app.datadoghq.com/account/settings#agent/windows + +{{% /tab %}} +{{% tab "Kubernetes (Operator)" %}} + +Mettez à jour les versions de l'image du Datadog Operator et de l'Agent dans votre manifeste `DatadogAgent`. + +1. Mettez à jour le Datadog Operator : + + ```bash + helm repo update + helm upgrade datadog-operator datadog/datadog-operator \ + --set image.repository=registry.datadoghq.com/operator \ + --set image.tag=latest + ``` + + Vous pouvez fixer une version spécifique. Pour parcourir les tags disponibles, utilisez [Docker Hub][1]. + +1. Mettez à jour les versions de l'image de l'Agent dans votre manifeste `datadog-agent.yaml` : + + ```yaml + override: + nodeAgent: + image: + name: registry.datadoghq.com/agent: + clusterAgent: + image: + name: registry.datadoghq.com/cluster-agent: + ``` + +1. Appliquez le manifeste mis à jour : `kubectl apply -f datadog-agent.yaml`. +1. Vérifiez la mise à jour : + + ```bash + kubectl get pods + kubectl logs -l app.kubernetes.io/component=cluster-agent --tail=100 | grep private + ``` + +Le Cluster Agent runner conserve son identité lors de la mise à jour, car il la stocke dans un secret Kubernetes partagé. Le node Agent runner stocke son identité dans un fichier : si ce chemin n'est pas supporté par un volume persistant, une mise à jour peut effacer l'identité et forcer le runner à se réinscrire. Consultez [Stockage de l'identité sur Kubernetes][2]. + +[1]: https://hub.docker.com/r/datadog/operator/tags +[2]: /fr/actions/private_actions/enroll_runner/#identity-storage-on-kubernetes + +{{% /tab %}} +{{% tab "Kubernetes (Helm)" %}} + +La mise à jour du runner fait partie du processus standard de mise à niveau du Datadog Agent Helm chart. + +```bash +helm repo update +helm upgrade datadog-agent datadog/datadog -f values.yaml +``` + +Pour des instructions de mise à niveau détaillées, consultez [Mise à niveau de Datadog Helm][1]. + +[1]: https://github.com/DataDog/helm-charts/blob/main/charts/datadog/README.md#upgrading + +{{% /tab %}} +{{% tab "Terraform (Operator)" %}} + +Mettez à jour les variables de version dans votre configuration Terraform : + +```hcl +locals { + helm_operator_version = "" + agent_version = "" + # ... +} +``` + +Appliquez les changements : + +```bash +terraform plan +terraform apply -var="datadog_api_key=" -var="datadog_app_key=" +``` + +{{% /tab %}} +{{< /tabs >}} + +## Pour aller plus loin {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /fr/actions/private_actions/set_up_standalone/ +[2]: /fr/remote_configuration +[3]: https://app.datadoghq.com/fleet/install-agent/latest +[4]: /fr/actions/connections/ +[5]: /fr/actions/private_actions/execution_policies/ +[6]: https://app.datadoghq.com/actions/action-catalog +[7]: /fr/actions/private_actions/reference/ +[8]: /fr/actions/private_actions/enroll_runner/ \ No newline at end of file diff --git a/hugo/content/fr/actions/workflows/mcp_tools.md b/hugo/content/fr/actions/workflows/mcp_tools.md new file mode 100644 index 00000000000..a8f448dbf63 --- /dev/null +++ b/hugo/content/fr/actions/workflows/mcp_tools.md @@ -0,0 +1,122 @@ +--- +description: Utilisez des agents IA pour créer, gérer, exécuter et déboguer des workflows + avec la suite d'outils de workflows de Datadog MCP Server. +further_reading: +- link: mcp_server/setup + tag: Documentation + text: Configurer Datadog MCP Server +- link: mcp_server + tag: Documentation + text: Présentation de Datadog MCP Server +- link: mcp_server/tools + tag: Documentation + text: Outils de Datadog MCP Server +- link: actions/workflows/ + tag: Documentation + text: Workflow Automation +title: Outils MCP de Workflow Automation +--- +## Présentation {#overview} + +Le [Datadog MCP Server][1] permet aux agents IA de créer et de gérer des workflows via le [Model Context Protocol (MCP)][2]. + +La suite d'outils `workflows` donne aux clients IA tels que Claude Code, Cursor et OpenAI Codex accès à vos workflows, à Action Catalog, au workflow schema et aux données d'exécution. En utilisant le langage naturel, vous pouvez créer et mettre à jour des workflows, valider leurs spécifications, exécuter des workflows publiés et étudier les résultats d'exécution. + +## Cas d'utilisation {#use-cases} + +Utilisez la suite d'outils `workflows` pour créer des automatisations qui : + +- **Étudier les alertes de monitor** : lorsqu'un monitor de taux d'erreur de service émet une alerte, exécutez Bits Investigation pour corréler la latence, les déploiements récents et l'état de santé des services en aval, puis envoyez les résultats à l'équipe responsable sur Slack. +- **Utiliser des agents personnalisés** : créez un agent Bits Agent Builder personnalisé pour un système spécialisé, tel que les paiements, les pipelines de données ou Kubernetes, et invoquez-le depuis un workflow chaque fois qu'une alerte nécessite cette expertise de domaine. +- **Automatiser l'escalade d'incidents** : lorsqu'un incident critique est déclaré, rassemblez le contexte de service pertinent, contactez l'équipe d'astreinte appropriée, créez un cas et informez les parties prenantes. +- **Étudier les régressions de déploiement** : après un déploiement, comparez le comportement actuel du service avec les changements récents et, lorsqu'une régression probable est détectée, démarrez une session Bits Code pour étudier le code pertinent et proposer une correction. +- **Déclencher une remédiation à partir d'une alerte** : lorsqu'un monitor détecte une condition de défaillance connue, exécutez une action de remédiation telle que le redémarrage d'un service, l'invocation d'une fonction AWS Lambda ou l'appel d'un endpoint de remédiation interne. +- **Créer des correctifs de code** : étudiez un problème, demandez à Bits Code de proposer une modification de code, exigez une révision humaine et implémentez la modification une fois le correctif proposé approuvé. +- **Escalader les résultats de sécurité de haute gravité** : lorsqu'une découverte critique est détectée, créez un cas ou un ticket, informez l'équipe responsable et contactez le répondant approprié. + +## Démarrage rapide {#quickstart} + +
Le workflows La suite d'outils n'est pas activée par défaut pour les clients MCP externes.
+ +1. [Configurer Datadog MCP Server][1]. +1. Lors de la connexion de votre client IA à Datadog MCP Server, ajoutez `workflows` au paramètre `toolsets`. Par exemple, pour le site Datadog US1 : + + {{< code-block lang="none" >}} +https://mcp.datadoghq.com/v1/mcp?toolsets=core,workflows +{{< /code-block >}} + + **Remarque** : Si vous vous authentifiez à l'aide d'une clé d'application, activez l'[accès à l'API Actions][3] pour cette clé depuis [**Paramètres de l'organisation > Clés d'application**][4]. L'accès à l'API Actions est désactivé par défaut pour les clés d'application et est requis pour accéder aux Workflow Automation APIs. + +1. Après la connexion, vous pouvez effectuer des demandes, et votre client IA appelle les outils appropriés en votre nom. + - « Trouver les workflows appartenant à mon équipe qui sont déclenchés par des alertes de monitor. » + - « Créer un workflow qui exécute Bits Investigation lorsque ce monitor émet une alerte, puis publie les résultats sur Slack. » + - « Déboguer ma dernière exécution de workflow ayant échoué. » + +## Autorisations {#permissions} + +Les outils MCP de Workflow Automation utilisent les autorisations Datadog existantes de l'utilisateur. Les opérations sont effectuées dans l'organisation Datadog utilisée pour authentifier le MCP. + +| Autorisation | Capacités | +|------------------|----------------------------------------------------------------------------------------| +| Workflows Read | Rechercher et récupérer des workflows, des schémas et des actions, valider des spécifications et inspecter des exécutions | +| Workflows Write | Créer, mettre à jour, publier, dépublier et supprimer définitivement des workflows | +| Workflows Run | Démarrer des workflows et annuler des exécutions en cours | + +## Outils disponibles {#available-tools} + +L'ensemble d'outils `workflows` expose les outils suivants, regroupés par la partie du cycle de vie du workflow qu'ils prennent en charge. Cela inclut la recherche et l'inspection de workflows, la découverte de spécifications et d'actions, la création et la gestion de workflows, la validation de spécifications, l'exécution et l'inspection d'exécutions, ainsi que le débogage d'étapes. Lorsque vous effectuez une demande d'automatisation en langage naturel, votre client IA appelle ces outils en votre nom. Il enchaîne leurs résultats pour produire le résultat souhaité. Consultez la [Datadog MCP Server tools reference][5] pour obtenir tous les détails sur chaque outil, y compris les autorisations et des exemples de demandes. + +### Découverte de workflows {#workflow-discovery} + +- [`list_datadog_workflows`][6] +- [`get_datadog_workflow`][7] + +### Spécification et découverte d'actions {#specification-and-action-discovery} + +- [`get_datadog_workflow_spec_schema`][8] +- [`search_datadog_workflow_actions`][9] +- [`get_datadog_workflow_action`][10] + +### Création et gestion de workflows {#workflow-creation-and-management} + +- [`create_datadog_workflow`][11] +- [`update_datadog_workflow`][12] +- [`publish_datadog_workflow`][13] +- [`unpublish_datadog_workflow`][14] +- [`delete_datadog_workflow`][15] +- [`validate_datadog_workflow`][16] + +### Exécution de workflows {#workflow-execution} + +- [`execute_datadog_workflow`][17] +- [`get_datadog_workflow_instance`][18] +- [`list_datadog_workflow_instances`][19] +- [`cancel_datadog_workflow_instance`][20] +- [`get_datadog_workflow_step_data`][21] + +## Lectures complémentaires {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /fr/mcp_server/setup/ +[2]: https://modelcontextprotocol.io/ +[3]: /fr/account_management/api-app-keys/#actions-api-access +[4]: https://app.datadoghq.com/organization-settings/application-keys +[5]: /fr/mcp_server/tools/#workflows +[6]: /fr/mcp_server/tools/#list_datadog_workflows +[7]: /fr/mcp_server/tools/#get_datadog_workflow +[8]: /fr/mcp_server/tools/#get_datadog_workflow_spec_schema +[9]: /fr/mcp_server/tools/#search_datadog_workflow_actions +[10]: /fr/mcp_server/tools/#get_datadog_workflow_action +[11]: /fr/mcp_server/tools/#create_datadog_workflow +[12]: /fr/mcp_server/tools/#update_datadog_workflow +[13]: /fr/mcp_server/tools/#publish_datadog_workflow +[14]: /fr/mcp_server/tools/#unpublish_datadog_workflow +[15]: /fr/mcp_server/tools/#delete_datadog_workflow +[16]: /fr/mcp_server/tools/#validate_datadog_workflow +[17]: /fr/mcp_server/tools/#execute_datadog_workflow +[18]: /fr/mcp_server/tools/#get_datadog_workflow_instance +[19]: /fr/mcp_server/tools/#list_datadog_workflow_instances +[20]: /fr/mcp_server/tools/#cancel_datadog_workflow_instance +[21]: /fr/mcp_server/tools/#get_datadog_workflow_step_data +[22]: /fr/actions/actions_catalog/ \ No newline at end of file diff --git a/hugo/content/fr/administrators_guide/getting_started.md b/hugo/content/fr/administrators_guide/getting_started.md index 4723ff757ea..fe6c5f9684d 100644 --- a/hugo/content/fr/administrators_guide/getting_started.md +++ b/hugo/content/fr/administrators_guide/getting_started.md @@ -1,123 +1,122 @@ --- -description: Découvrir des stratégies pour débuter avec votre nouvelle installation +description: Apprenez des stratégies pour bien démarrer avec votre nouvelle installation Datadog. further_reading: - link: /getting_started/support/ tag: Documentation - text: Débuter avec l'assistance Datadog -title: Prise en main + text: Premiers pas avec le support Datadog +title: Débuter --- +## Présentation {#overview} -## Section Overview +Ce guide de démarrage propose des stratégies pour mettre en œuvre efficacement Datadog dans votre organisation. Explorez les ressources d'assistance, les cours du Learning Center pour approfondir vos connaissances et les instructions pour configurer un environnement de test. -Ce guide de démarrage propose des stratégies pour implémenter efficacement Datadog dans votre organisation. Explorez les ressources d'assistance, les cours du centre d'apprentissage pour approfondir vos connaissances et les instructions pour configurer un environnement de test. +## Obtenir de l'aide {#getting-help} -## Obtenir de l'aide +### Ressources en libre-service {#self-service-resources} -### Ressources en libre-service +Au fil de ce guide, vous pouvez vous référer aux ressources en libre-service suivantes : -Au fur et à mesure que vous progressez dans ce guide, vous pouvez consulter les ressources en libre-service suivantes : +* [Datadog training](#learn-datadog-basics) courses. +* La [documentation][16] Datadog, en particulier les pages [Démarrage][17], pour vous familiariser davantage avec la plateforme. +* [Datadog UI][18], qui fournit une aide contextuelle, des informations sur des champs de configuration spécifiques, des notes de version et d'autres ressources ; cliquez sur l'icône ? présente dans toute l'application ou en bas de la navigation du produit. -* Les cours de [formation Datadog](#decouvrir-les-bases-de-datadog). -* La [documentation][16] Datadog, en particulier les pages [Débuter][17], pour vous familiariser davantage avec la plateforme. -* L'[interface utilisateur Datadog][18], qui fournit une aide contextuelle, des informations sur des champs de configuration spécifiques, des notes de version et d'autres ressources. Cliquez sur l'icône ? dans toute l'application ou en bas de la navigation des produits. +{{< img src="/administrators_guide/help_center.png" alt="Capture d'écran du centre d'aide dans Datadog UI" style="width:90%;">}} -{{< img src="/administrators_guide/help_center.png" alt="Capture d'écran du centre d'aide dans l'interface utilisateur Datadog" style="width:90%;">}} +### Ouvrir un ticket de support {#file-a-support-ticket} -### Créer un ticket d'assistance +Pour obtenir de l'aide lorsque vous rencontrez un problème : -Pour obtenir de l'assistance lorsque vous rencontrez un problème : +* [**Datadog Support**][20] : Disponible pour vous aider avec des problèmes complexes, guider votre installation, traduire les problèmes en conditions locales, identifier les bugs et enregistrer les demandes de fonctionnalités. +* [**Datadog Agent flare**][21] : Cet outil CLI crée automatiquement un nouveau ticket de support et envoie un fichier compressé contenant les logs pertinents expurgés, les paramètres de niveau de débogage et les configurations locales au support Datadog, sans connexion requise. Pour plus d'informations sur la façon d'utiliser et d'envoyer le flare à Datadog support, consultez [Envoyer un flare][21]. +* [**Fleet Automation**][5] : Permet la génération de flare à distance depuis le Platform UI. -* [**Assistance Datadog**][20] : disponible pour vous aider avec des problèmes difficiles, guider votre installation, traduire les problèmes en conditions locales, identifier les bugs et consigner les demandes de fonctionnalités. -* [**Flare de l'Agent Datadog**][21] : cet outil CLI crée automatiquement un nouveau ticket d'assistance et envoie un fichier compressé de fichiers logs pertinents expurgés, de paramètres de niveau de débogage et de configurations locales à l'assistance Datadog, sans connexion requise. Pour plus d'informations sur l'utilisation et l'envoi du flare à l'assistance Datadog, consultez la section [envoi d'un flare][21]. -* [**Fleet Automation**][5] : permet la génération de flare à distance depuis l'interface utilisateur de la plateforme. +## Apprendre les bases de Datadog {#learn-datadog-basics} -## Découvrir les bases de Datadog +Familiarisez-vous rapidement avec les parties de Datadog les plus importantes pour votre cas d'utilisation. Commencez par vous inscrire à nos cours gratuits du [Learning Center][1]. Intégrez les cours suivants à vos workflows d'intégration : -Familiarisez-vous avec les éléments de Datadog qui sont les plus importants pour votre cas d'usage. Commencez par vous inscrire à nos cours gratuits du [centre d'apprentissage][1]. Intégrez les cours suivants dans vos workflows d'onboarding : - -**Débuter** : +**Mise en route** : {{< whatsnext desc=" " >}} - {{< nextlink href="https://learn.datadoghq.com/courses/datadog-foundation" >}}Datadog Foundation{{< /nextlink >}} - {{< nextlink href="https://learn.datadoghq.com/courses/tagging-best-practices" >}}Tagging Best Practices{{< /nextlink >}} - {{< nextlink href="https://learn.datadoghq.com/courses/managing-software-catalog" >}}Managing the Software Catalog{{< /nextlink >}} + {{< nextlink href="https://learn.datadoghq.com/courses/datadog-foundation" >}}Fondamentaux de Datadog{{< /nextlink >}} + {{< nextlink href="https://learn.datadoghq.com/courses/tagging-best-practices" >}}Bonnes pratiques de tagging{{< /nextlink >}} + {{< nextlink href="https://learn.datadoghq.com/courses/managing-software-catalog" >}}Gestion du catalogue{{< /nextlink >}} {{< /whatsnext >}} -**Administrateurs** : +**Administrateurs** : {{< whatsnext desc=" " >}} - {{< nextlink href="https://learn.datadoghq.com/courses/agent-on-host" >}}The Agent on a Host{{< /nextlink >}} - {{< nextlink href="https://learn.datadoghq.com/courses/monitoring-k8s-cluster-agent" >}}Monitoring a Kubernetes Cluster{{< /nextlink >}} - {{< nextlink href="https://learn.datadoghq.com/courses/dd-api-automation-iac" >}}Datadog API: Automation and Infrastructure as Code{{< /nextlink >}} + {{< nextlink href="https://learn.datadoghq.com/courses/agent-on-host" >}}L'Agent sur un host{{< /nextlink >}} + {{< nextlink href="https://learn.datadoghq.com/courses/monitoring-k8s-cluster-agent" >}}Surveillance d'un cluster Kubernetes{{< /nextlink >}} + {{< nextlink href="https://learn.datadoghq.com/courses/dd-api-automation-iac" >}}Datadog API : automatisation et infrastructure en tant que code{{< /nextlink >}} {{< /whatsnext >}} -**Interface utilisateur** : +**Interface utilisateur** : {{< whatsnext desc=" " >}} - {{< nextlink href="https://learn.datadoghq.com/courses/intro-dashboards" >}}Introduction to Dashboards{{< /nextlink >}} - {{< nextlink href="https://learn.datadoghq.com/courses/dashboard-graph-widgets" >}}Discovering Graph Widgets{{< /nextlink >}} - {{< nextlink href="https://learn.datadoghq.com/courses/dashboards-slos" >}}Using Dashboards and SLOs{{< /nextlink >}} + {{< nextlink href="https://learn.datadoghq.com/courses/intro-dashboards" >}}Introduction aux dashboards{{< /nextlink >}} + {{< nextlink href="https://learn.datadoghq.com/courses/dashboard-graph-widgets" >}}Découverte des Graph Widgets{{< /nextlink >}} + {{< nextlink href="https://learn.datadoghq.com/courses/dashboards-slos" >}}Utilisation des dashboards et des SLO{{< /nextlink >}} {{< /whatsnext >}} -**Ingénieurs de fiabilité des sites** : +**Ingénieurs de fiabilité de site** : {{< whatsnext desc=" " >}} - {{< nextlink href="https://learn.datadoghq.com/courses/dd-101-sre" >}}Datadog 101: Site Reliability Engineer{{< /nextlink >}} - {{< nextlink href="https://learn.datadoghq.com/courses/apm-monitors-and-alerting" >}}APM Monitors and Alerting{{< /nextlink >}} - {{< nextlink href="https://learn.datadoghq.com/courses/core-web-vitals-lab" >}}Using Datadog RUM to track core web vitals{{< /nextlink >}} + {{< nextlink href="https://learn.datadoghq.com/courses/dd-101-sre" >}}Datadog 101 : Ingénieur en fiabilité de site{{< /nextlink >}} + {{< nextlink href="https://learn.datadoghq.com/courses/apm-monitors-and-alerting" >}}Monitors et alertes APM{{< /nextlink >}} + {{< nextlink href="https://learn.datadoghq.com/courses/core-web-vitals-lab" >}}Utilisation de Datadog RUM pour suivre les indicateurs Web essentiels{{< /nextlink >}} {{< /whatsnext >}} -**Développeurs** : +**Développeurs** : {{< whatsnext desc=" " >}} - {{< nextlink href="https://learn.datadoghq.com/courses/apm-java-host" >}}Setup APM for Java applications{{< /nextlink >}} - {{< nextlink href="https://learn.datadoghq.com/courses/dd-101-dev" >}}Datadog 101: Developer{{< /nextlink >}} - {{< nextlink href="https://learn.datadoghq.com/courses/tracking-errors-rum-javascript" >}}Tracking errors with RUM for javascript web applications{{< /nextlink >}} + {{< nextlink href="https://learn.datadoghq.com/courses/apm-java-host" >}}Configuration de l'APM pour les applications Java{{< /nextlink >}} + {{< nextlink href="https://learn.datadoghq.com/courses/dd-101-dev" >}}Datadog 101 : Développeur{{< /nextlink >}} + {{< nextlink href="https://learn.datadoghq.com/courses/tracking-errors-rum-javascript" >}}Suivi des erreurs avec RUM pour les applications web JavaScript{{< /nextlink >}} {{< /whatsnext >}} -## Créer un environnement de test +## Créez un environnement de test {#create-a-test-environment} -Après avoir terminé quelques cours, appliquez ce que vous avez appris à vos conditions locales. Installez et expérimentez Datadog dans un bac à sable à faible risque pour vous familiariser avec l'environnement. Créez un environnement simple et accessible pour développer votre configuration de surveillance avant une installation plus large. +Après avoir suivi certains cours, appliquez ce que vous avez appris à vos conditions locales. Installez et expérimentez Datadog dans un bac à sable à faible risque, afin de vous familiariser avec l'environnement. Créez un environnement simple et accessible pour développer votre configuration de monitoring avant une installation plus large. -### Configuration de votre environnement de test +### Configuration de votre environnement de test {#configuring-your-test-environment} -#### Dans l'application +#### Dans l'application {#in-app} -L'[interface utilisateur Datadog][18] est le meilleur endroit pour commencer à créer votre environnement de test. La plateforme fournit une assistance à la configuration, des analyseurs automatiques de données en direct, des suggestions contextuelles et de nombreux autres outils. L'interface utilisateur Datadog fournit des ressources utiles pour accomplir certaines de ces tâches. +L'[interface utilisateur Datadog][18] est le meilleur endroit pour commencer à construire votre environnement de test. La plateforme fournit une assistance à la configuration, des analyseurs automatiques de données en temps réel, des suggestions contextuelles et de nombreux autres outils. L'interface utilisateur Datadog fournit des ressources utiles pour accomplir certaines de ces tâches. -Voici quelques exemples : +Voici quelques exemples : -* Créer un [test Synthetic Monitoring][14] pour commencer à tester des transactions commerciales critiques sur vos applications. -* Créer quelques [Service Level Objectives][15] (SLO) pour définir des cibles de performance d'application. -* Consulter la page [Configuration du service APM][9] et suivre les instructions étape par étape pour commencer à instrumenter vos services. -* Configurer et tester les [pipelines de logs][8] pour déterminer comment vous souhaitez ingérer différents ensembles de logs provenant de l'infrastructure et des applications. -* Consulter la page [Modèles de monitors][10] pour commencer à ajouter des alertes sur votre environnement de test. +* Créez un [Synthetic Monitoring test][14] pour commencer à tester les transactions métier critiques sur vos applications. +* Créez quelques [Service Level Objectives][15] (SLOs) pour définir des cibles de performance applicative. +* Consultez la page [APM Service Setup][9] et suivez les instructions étape par étape pour commencer à instrumenter vos services. +* Configurez et testez des [Log Pipelines][8] pour déterminer comment vous souhaitez ingérer différents ensembles de logs provenant de l'infrastructure et des applications. +* Consultez la page [Monitor Templates][10] pour commencer à ajouter des alertes sur votre environnement de test. -#### Modèles de configuration du host de l'Agent +#### Host Agent Config Templates {#host-agent-config-templates} -L'[Agent Datadog][2] est open source et publié sur GitHub. Le référentiel GitHub de l'Agent est une ressource utile pour consulter les modèles de configuration et les spécifications afin de vous aider à créer votre environnement. +Le [Datadog Agent][2] est open source et publié sur GitHub. Le dépôt GitHub du [Datadog Agent] est une ressource utile pour consulter les modèles de configuration et les spécifications afin de vous aider à construire votre environnement. -Voici quelques exemples : +Voici quelques exemples : -* [Modèle de configuration de l'Agent][3] -* [Spécifications de configuration d'intégration][4] +* [Agent Config Examples][3] +* [Integration Config Specs][4] * [Fleet Automation][5] -## Étapes suivantes +## Prochaines étapes {#next-steps} -Pour créer avec succès une nouvelle installation Datadog, consultez la page de [planification][11]. Vous apprendrez à créer un exercice de cadrage, à configurer le [tagging de ressources][12], à découvrir les meilleures pratiques des produits, à ajouter d'autres produits et à optimiser votre collecte de données pour assurer une installation fluide. +Pour réussir la création d'une nouvelle installation Datadog, consultez la page [plan][11]. Vous apprendrez à créer un exercice de définition de périmètre, à configurer le [tagging de ressource][12], à découvrir les meilleures pratiques produit, à ajouter d'autres produits et à optimiser votre collecte de données pour garantir une installation fluide. -## Pour aller plus loin +## Pour aller plus loin {#further-reading} {{< partial name="whats-next/whats-next.html" >}} [1]: https://learn.datadoghq.com/ [2]: https://github.com/DataDog/datadog-agent -[3]: https://github.com/DataDog/datadog-agent/blob/main/pkg/config/config_template.yaml +[3]: https://github.com/DataDog/datadog-agent/tree/main/pkg/config/example [4]: https://github.com/DataDog/integrations-core [5]: https://app.datadoghq.com/fleet [6]: /fr/getting_started/tagging/unified_service_tagging/ [7]: /fr/getting_started/tagging/ [8]: https://app.datadoghq.com/logs/pipelines/pipeline/add [9]: https://app.datadoghq.com/apm/service-setup -[10]: https://app.datadoghq.com/monitors/recommended +[10]: https://app.datadoghq.com/monitors/templates [11]: /fr/administrators_guide/plan [12]: /fr/administrators_guide/plan/#resource-tagging [13]: https://github.com/DataDog/datadog-agent/tree/main/examples diff --git a/hugo/content/fr/agent/configuration/dual-shipping.md b/hugo/content/fr/agent/configuration/dual-shipping.md index 97d294d0fb0..462dac9107e 100644 --- a/hugo/content/fr/agent/configuration/dual-shipping.md +++ b/hugo/content/fr/agent/configuration/dual-shipping.md @@ -1,88 +1,91 @@ --- aliases: - /fr/agent/guide/dual-shipping -description: Configurez le site Datadog Agent pour qu'il envoie simultanément des - métriques, des loget des traceà plusieurs organisations Datadog. +description: Configurez le Datadog Agent pour envoyer simultanément des métriques, + des logs et des traces vers plusieurs organisations Datadog. further_reading: -- link: /agent/configuration/réseau/ +- link: https://www.datadoghq.com/blog/ddot-gateway + tag: Blog + text: Centralisez et gérez votre pipeline OpenTelemetry avec la passerelle DDOT +- link: /agent/configuration/network/ tag: Guide text: Trafic réseau - link: /observability_pipelines/ - tag: documentation - text: Envoyer logs à des destinations externes avec Observability Pipelines + tag: Documentation + text: Envoyez des logs vers des destinations externes avec Observability Pipelines title: Transmission multiple --- -
-Si vous envoyez des données à plusieurs organisations Datadog, la fonctionnalité de transmission multiple peut avoir une incidence sur vos coûts. Pour en savoir plus sur les frais supplémentaires engendrés par cette configuration, contactez l'assistance Datadog. +Le double envoi peut avoir une incidence sur la facturation si vous envoyez des données vers plusieurs organisations Datadog. Pour en savoir plus sur l'impact de cette configuration, contactez Datadog Support.
-## Présentation +## Présentation {#overview} -Ce document fournit des exemples de configurations de l'Agent pour l'envoi double de différents types de données (par exemple, APM, logs, métriques du Cluster Agent, etc.) vers plusieurs organisations Datadog. +Ce guide fournit des exemples de configurations d'Agent pour le double envoi de différents types de données (par exemple, APM, logs, métriques du Cluster Agent) vers plusieurs organisations et sites Datadog. Pour en savoir plus sur les sites Datadog, consultez [Débuter avec les sites Datadog][3]. -**Remarque** : utilisez [Observability Pipelines][1] si vous souhaitez effectuer un envoi double de logs ou répartir le trafic de logs entre différents fournisseurs de journalisation, stockages cloud ou fournisseurs SIEM. +**Remarque** : utilisez [Observability Pipelines][1] si vous souhaitez effectuer un double envoi de logs ou répartir le trafic de logs entre différents fournisseurs de logs, stockages cloud ou fournisseurs SIEM. -Pour obtenir une liste complète des destinations du trafic réseau, consultez la section [Trafic réseau][2]. +Pour obtenir la liste complète des destinations du trafic réseau, consultez [Trafic réseau][2]. -## Métriques et checks de service +## Métriques et checks de service {#metrics-and-service-checks} Vous pouvez ajouter la configuration YAML à votre `datadog.yaml` ou lancer l'Agent avec les variables d'environnement appropriées. -### Configuration YAML +### Configuration YAML {#yaml-configuration} -Nécessite la version >= 6.17 ou 7.17 de l'Agent. +Nécessite l'Agent version >= 6.17 ou 7.17. Dans `datadog.yaml` : ```yaml additional_endpoints: - "https://app.datadoghq.com": + "https://app.{{< region-param key="dd_site">}}": - apikey2 - apikey3 - "https://app.datadoghq.eu": + "https://app.": # Replace with your Datadog site parameter (for example, datadoghq.eu). - apikey4 ``` -### Configuration des variables d'environnement +### Configuration par variable d'environnement {#environment-variable-configuration} -Nécessite la version >= 6.18 ou 7.18 de l'Agent. +Nécessite l'Agent version >= 6.18 ou 7.18. ```bash -DD_ADDITIONAL_ENDPOINTS='{\"https://app.datadoghq.com\": [\"apikey2\", \"apikey3\"], \"https://app.datadoghq.eu\": [\"apikey4\"]}' +DD_ADDITIONAL_ENDPOINTS='{\"https://app.{{< region-param key="dd_site">}}\": [\"apikey2\", \"apikey3\"], \"https://app.\": [\"apikey4\"]}' # Replace with your Datadog site parameter (for example, datadoghq.eu). ``` -## APM +## APM {#apm} -### Configuration YAML +### Configuration YAML {#yaml-configuration-1} -Nécessite la version >= 6.7.0 de l'Agent. +Nécessite l'Agent version >= 6.7.0. Dans `datadog.yaml` : + ```yaml apm_config: [...] additional_endpoints: - "https://trace.agent.datadoghq.com": + "https://trace.agent.{{< region-param key="dd_site">}}": - apikey2 - apikey3 - "https://trace.agent.datadoghq.eu": + "https://trace.agent.": # Replace with your Datadog site parameter (for example, datadoghq.eu). - apikey4 ``` -### Configuration des variables d'environnement +### Configuration par variable d'environnement {#environment-variable-configuration-1} -Nécessite la version >= 6.19 ou 7.19 de l'Agent. +Nécessite l'Agent version >= 6.19 ou 7.19. ```bash -DD_APM_ADDITIONAL_ENDPOINTS='{\"https://trace.agent.datadoghq.com\": [\"apikey2\", \"apikey3\"], \"https://trace.agent.datadoghq.eu\": [\"apikey4\"]}' +DD_APM_ADDITIONAL_ENDPOINTS='{\"https://trace.agent.{{< region-param key="dd_site">}}\": [\"apikey2\", \"apikey3\"], \"https://trace.agent.\": [\"apikey4\"]}' # Replace with your Datadog site parameter (for example, datadoghq.eu). ``` -## Profileur en continu +## Continuous Profiler {#continuous-profiler} -### Configuration YAML +### Configuration YAML {#yaml-configuration-2} -Nécessite la version >= 6.7.0 de l'Agent. +Nécessite l'Agent version >= 6.7.0. Dans `datadog.yaml` : @@ -90,223 +93,229 @@ Dans `datadog.yaml` : apm_config: [...] profiling_additional_endpoints: - "https://intake.profile.datadoghq.com/api/v2/profile": + "https://intake.profile.{{< region-param key="dd_site">}}/api/v2/profile": - apikey2 - apikey3 - "https://intake.profile.datadoghq.eu/api/v2/profile": + "https://intake.profile./api/v2/profile": # Replace "" with your Datadog site parameter (for example, datadoghq.eu). - apikey4 ``` -### Configuration des variables d'environnement +### Configuration par variable d'environnement {#environment-variable-configuration-2} -Nécessite la version >= 6.19 ou 7.19 de l'Agent. +Nécessite l'Agent version >= 6.19 ou 7.19. ```bash -DD_APM_PROFILING_ADDITIONAL_ENDPOINTS='{\"https://intake.profile.datadoghq.com/api/v2/profile\": [\"apikey2\", \"apikey3\"], \"https://intake.profile.datadoghq.eu/api/v2/profile\": [\"apikey4\"]}' +DD_APM_PROFILING_ADDITIONAL_ENDPOINTS='{\"https://intake.profile.{{< region-param key="dd_site">}}/api/v2/profile\": [\"apikey2\", \"apikey3\"], \"https://intake.profile./api/v2/profile\": [\"apikey4\"]}' # Replace with your Datadog site parameter (for example, datadoghq.eu). ``` -**Remarque** : les uploads vers des endpoints supplémentaires pour le produit Continuous Profiler sont effectués via une livraison au mieux. -* L'endpoint principal a la priorité la plus élevée. Les uploads vers des endpoints supplémentaires ne sont gérés qu'après que les uploads vers l'endpoint principal ont été terminés avec succès. -* Les réponses des endpoints supplémentaires ne sont pas renvoyées au profileur. Toutes les erreurs survenues lors de la livraison vers des endpoints supplémentaires sont enregistrées dans les logs d'erreur de l'Agent. +**Remarque :** Les chargements vers des endpoints supplémentaires pour le produit Continuous Profiler sont effectués via une livraison au mieux. +* L'endpoint principal a la priorité la plus élevée. Les chargements vers des endpoints supplémentaires ne sont traités qu'une fois que les chargements vers l'endpoint principal ont été effectués avec succès. +* Les réponses des endpoints supplémentaires ne sont pas renvoyées vers le profileur. Toute erreur lors de la livraison vers des endpoints supplémentaires est consignée dans les logs d'erreurs de l'Agent. -## Live processes +## Live Processes {#live-processes} -### Configuration YAML +### Configuration YAML {#yaml-configuration-3} -Nécessite la version >= 6.4.0 de l'Agent. +Nécessite la version de l'Agent >= 6.4.0. Dans `datadog.yaml` : + ```yaml process_config: [...] additional_endpoints: - "https://process.datadoghq.com": + "https://process.{{< region-param key="dd_site">}}": - apikey2 - apikey3 - "https://process.datadoghq.eu": + "https://process.": # Replace with your Datadog site parameter (for example, datadoghq.eu). - apikey4 ``` -### Configuration des variables d'environnement +### Configuration par variable d'environnement {#environment-variable-configuration-3} -Nécessite la version >= 6.20 ou 7.20 de l'Agent. +Nécessite la version de l'Agent >= 6.20 ou 7.20. ```bash -DD_PROCESS_ADDITIONAL_ENDPOINTS='{\"https://process.datadoghq.com\": [\"apikey2\", \"apikey3\"], \"https://process.datadoghq.eu\": [\"apikey4\"]}' +DD_PROCESS_ADDITIONAL_ENDPOINTS='{\"https://process.{{< region-param key="dd_site">}}\": [\"apikey2\", \"apikey3\"], \"https://process.\": [\"apikey4\"]}' # Replace with your Datadog site parameter (for example, datadoghq.eu). ``` -## Métriques de l'Agent de cluster +## Métriques du Cluster Agent {#cluster-agent-metrics} -Configurez l'Agent pour envoyer les métriques de l'Agent de cluster, telles que Kubernetes State Metrics Core, vers des endpoints supplémentaires. +Configurez l'Agent pour envoyer les métriques du Cluster Agent, telles que Kubernetes State Metrics Core, vers des endpoints supplémentaires. + +### Configuration HELM {#helm-configuration} +Dans Datadog `values.yaml` : -### Configuration HELM -Dans le fichier `values.yaml` de Datadog : ```yaml clusterAgent: env: - name: DD_ADDITIONAL_ENDPOINTS - value: '{"https://app.datadoghq.com": ["apikey2"]}' + value: '{"https://app.{{< region-param key="dd_site">}}": ["apikey2"]}' ``` -### Fournisseur de métriques de l'Agent de cluster +### Fournisseur de métriques du Cluster Agent {#cluster-agent-metrics-provider} -Pour garantir que l'autoscaling est résilient aux défaillances, configurez l'Agent de cluster pour exécuter vos requêtes de métriques pour le HPA sur vos plusieurs régions Datadog avec des données envoyées en double. Configurez le manifeste de l'Agent de cluster Datadog avec plusieurs endpoints : +Pour garantir que la mise à l'échelle automatique résiste aux pannes, configurez le Cluster Agent pour exécuter vos requêtes de métriques pour le HPA sur vos multiples régions Datadog avec un double envoi de données. Configurez le manifeste du Datadog Cluster Agent avec plusieurs endpoints : {{< code-block lang="yaml" filename="cluster-agent-deployment.yaml" collapsible="true" >}} external_metrics_provider: endpoints: - api_key: app_key: - url : https://app.datadoghq.eu + url: https://app. - api_key: app_key: - url: https://app.datadoghq.com + url: https://app. {{< /code-block >}} -## Orchestrateur +## Orchestrator {#orchestrator} + +### Configuration HELM {#helm-configuration-1} +Dans Datadog `values.yaml` : -### Configuration HELM -Dans le fichier `values.yaml` de Datadog : ```yaml agents: customAgentConfig: process_config: additional_endpoints: - "https://process.datadoghq.com": + "https://process.{{< region-param key="dd_site">}}": - apikey2 orchestrator_explorer: orchestrator_additional_endpoints: - "https://orchestrator.datadoghq.com": - - apikey2 + "https://orchestrator.{{< region-param key="dd_site">}}": + - apikey3 clusterAgent: ... datadog_cluster_yaml: orchestrator_explorer: orchestrator_additional_endpoints: - "https://orchestrator.ddog-gov.com": - - apikey2 + "https://orchestrator.": # Replace with your Datadog site parameter (for example, ddog-gov.com). + - apikey4 ``` - -### Configuration des variables d'environnement +### Configuration par variable d'environnement {#environment-variable-configuration-4} ```bash -DD_ORCHESTRATOR_EXPLORER_ORCHESTRATOR_ADDITIONAL_ENDPOINTS='{\"https://orchestrator.datadoghq.com\": [\"apikey2\", \"apikey3\"], \"https://orchestrator.datadoghq.eu\": [\"apikey4\"]}' +DD_ORCHESTRATOR_EXPLORER_ORCHESTRATOR_ADDITIONAL_ENDPOINTS='{\"https://orchestrator.{{< region-param key="dd_site">}}\": [\"apikey2\", \"apikey3\"], \"https://orchestrator.\": [\"apikey4\"]}' # Replace with your Datadog site parameter (for example, ddog-gov.com). ``` -## CI Visibility +## CI Visibility {#ci-visibility} -### Configuration YAML +### Configuration YAML {#yaml-configuration-4} Nécessite l'Agent >= 6.38 ou 7.38. Dans `datadog.yaml` : + ```yaml evp_proxy_config: [...] additional_endpoints: - "https://-app.agent.datadoghq.com": + "https://-app.agent.{{< region-param key="dd_site">}}": - apikey2 - apikey3 - "https://-app.agent.datadoghq.eu": + "https://-app.agent.": # Replace and with your Agent version and Datadog site parameter (for example, 7-38-0 and datadoghq.eu). - apikey4 ``` -### Configuration des variables d'environnement +### Configuration par variable d'environnement {#environment-variable-configuration-5} ```bash -DD_EVP_PROXY_CONFIG_ADDITIONAL_ENDPOINTS='{\"https://-app.agent.datadoghq.com\": [\"apikey2\", \"apikey3\"], \"https://-app.agent.datadoghq.eu\": [\"apikey4\"]}' +DD_EVP_PROXY_CONFIG_ADDITIONAL_ENDPOINTS='{\"https://-app.agent.{{< region-param key="dd_site">}}\": [\"apikey2\", \"apikey3\"], \"https://-app.agent.\": [\"apikey4\"]}' # Replace and with your Agent version and Datadog site parameter (for example, 7-38-0 and datadoghq.eu). ``` -## Logs +## Logs {#logs} -Utilisez l'Agent si vous souhaitez effectuer un envoi double de logs vers plusieurs organisations Datadog. Utilisez [Observability Pipelines][2] si vous souhaitez envoyer des logs à Datadog et vers des destinations externes. +Utilisez l'Agent si vous souhaitez effectuer un double envoi de logs vers plusieurs organisations Datadog. Utilisez [Observability Pipelines][2] si vous souhaitez envoyer des logs vers Datadog et des destinations externes. -TCP nécessite la version >= 6.6 de l'Agent.
-HTTPS nécessite la version >= 6.13 de l'Agent. +TCP nécessite l'Agent version >= 6.6.
+HTTPS nécessite l'Agent version >= 6.13. -### Configuration YAML +### Configuration YAML {#yaml-configuration-5} Dans `datadog.yaml` : + ```yaml logs_config: force_use_http: true additional_endpoints: - api_key: "apiKey2" - Host: "agent-http-intake.logs.datadoghq.com" + Host: "agent-http-intake.logs.{{< region-param key="dd_site">}}" Port: 443 is_reliable: true ``` -### Configuration des variables d'environnement +### Configuration par variable d'environnement {#environment-variable-configuration-6} Nécessite l'Agent >= 6.18 ou 7.18. ```bash DD_LOGS_CONFIG_FORCE_USE_HTTP=true -DD_LOGS_CONFIG_ADDITIONAL_ENDPOINTS="[{\"api_key\": \"apiKey2\", \"Host\": \"agent-http-intake.logs.datadoghq.com\", \"Port\": 443, \"is_reliable\": true}]" +DD_LOGS_CONFIG_ADDITIONAL_ENDPOINTS="[{\"api_key\": \"apiKey2\", \"Host\": \"agent-http-intake.logs.{{< region-param key="dd_site">}}\", \"Port\": 443, \"is_reliable\": true}]" ``` {{% agent-dual-shipping %}} -## Database Monitoring +## Database Monitoring {#database-monitoring} -### Configuration YAML +### Configuration YAML {#yaml-configuration-6} Nécessite l'Agent >= 6.29 ou 7.29. Dans `datadog.yaml` : + ```yaml database_monitoring: samples: force_use_http: true additional_endpoints: - api_key: "apiKey2" - Host: "dbm-metrics-intake.datadoghq.com" + Host: "dbm-metrics-intake.{{< region-param key="dd_site">}}" Port: 443 is_reliable: true activity: force_use_http: true additional_endpoints: - api_key: "apiKey2" - Host: "dbquery-intake.datadoghq.com" + Host: "dbquery-intake.{{< region-param key="dd_site">}}" Port: 443 is_reliable: true metrics: force_use_http: true additional_endpoints: - api_key: "apiKey2" - Host: "dbm-metrics-intake.datadoghq.com" + Host: "dbm-metrics-intake.{{< region-param key="dd_site">}}" Port: 443 is_reliable: true ``` -### Configuration des variables d'environnement +### Configuration par variable d'environnement {#environment-variable-configuration-7} ```bash DD_DATABASE_MONITORING_SAMPLES_USE_HTTP=true -DD_DATABASE_MONITORING_SAMPLES_ADDITIONAL_ENDPOINTS="[{\"api_key\": \"apiKey2\", \"Host\": \"dbm-metrics-intake.datadoghq.com\", \"Port\": 443, \"is_reliable\": true}]" +DD_DATABASE_MONITORING_SAMPLES_ADDITIONAL_ENDPOINTS="[{\"api_key\": \"apiKey2\", \"Host\": \"dbm-metrics-intake.{{< region-param key="dd_site">}}\", \"Port\": 443, \"is_reliable\": true}]" DD_DATABASE_MONITORING_ACTIVITY_USE_HTTP=true -DD_DATABASE_MONITORING_ACTIVITY_ADDITIONAL_ENDPOINTS="[{\"api_key\": \"apiKey2\", \"Host\": \"dbquery-intake.datadoghq.com\", \"Port\": 443, \"is_reliable\": true}]" +DD_DATABASE_MONITORING_ACTIVITY_ADDITIONAL_ENDPOINTS="[{\"api_key\": \"apiKey2\", \"Host\": \"dbquery-intake.{{< region-param key="dd_site">}}\", \"Port\": 443, \"is_reliable\": true}]" DD_DATABASE_MONITORING_METRICS_USE_HTTP=true -DD_DATABASE_MONITORING_METRICS_ADDITIONAL_ENDPOINTS="[{\"api_key\": \"apiKey2\", \"Host\": \"dbm-metrics-intake.datadoghq.com\", \"Port\": 443, \"is_reliable\": true}]" +DD_DATABASE_MONITORING_METRICS_ADDITIONAL_ENDPOINTS="[{\"api_key\": \"apiKey2\", \"Host\": \"dbm-metrics-intake.{{< region-param key="dd_site">}}\", \"Port\": 443, \"is_reliable\": true}]" ``` {{% agent-dual-shipping %}} -## Network Devices +## Network Devices {#network-devices} -### Configuration YAML +### Configuration YAML {#yaml-configuration-7} Nécessite l'Agent >= 6.29 ou 7.29. Dans `datadog.yaml` : + ```yaml network_devices: metadata: force_use_http: true additional_endpoints: - api_key: "apiKey2" - Host: "ndm-intake.datadoghq.com" + Host: "ndm-intake.{{< region-param key="dd_site">}}" Port: 443 is_reliable: true snmp_traps: @@ -314,7 +323,7 @@ network_devices: force_use_http: true additional_endpoints: - api_key: "apiKey2" - Host: "ndm-intake.datadoghq.com" + Host: "ndm-intake.{{< region-param key="dd_site">}}" Port: 443 is_reliable: true netflow: @@ -322,101 +331,103 @@ network_devices: force_use_http: true additional_endpoints: - api_key: "apiKey2" - Host: "ndm-intake.datadoghq.com" + Host: "ndm-intake.{{< region-param key="dd_site">}}" Port: 443 is_reliable: true ``` -### Configuration des variables d'environnement +### Configuration par variable d'environnement {#environment-variable-configuration-8} ```bash DD_NETWORK_DEVICES_METADATA_USE_HTTP=true -DD_NETWORK_DEVICES_METADATA_ADDITIONAL_ENDPOINTS="[{\"api_key\": \"apiKey2\", \"Host\": \"ndm-intake.datadoghq.com\", \"Port\": 443, \"is_reliable\": true}]" +DD_NETWORK_DEVICES_METADATA_ADDITIONAL_ENDPOINTS="[{\"api_key\": \"apiKey2\", \"Host\": \"ndm-intake.{{< region-param key="dd_site">}}\", \"Port\": 443, \"is_reliable\": true}]" ``` {{% agent-dual-shipping %}} -## Chemin réseau +## Network Path {#network-path} -### Configuration YAML +### Configuration YAML {#yaml-configuration-8} Nécessite l'Agent >= 6.55 ou 7.55. Dans `datadog.yaml` : + ```yaml network_path: forwarder: use_http: true additional_endpoints: - api_key: "apiKey2" - Host: "netpath-intake.datadoghq.com" + Host: "netpath-intake.{{< region-param key="dd_site">}}" Port: 443 is_reliable: true ``` -### Configuration des variables d'environnement +### Configuration par variable d'environnement {#environment-variable-configuration-9} ```bash DD_NETWORK_PATH_FORWARDER_USE_HTTP=true -DD_NETWORK_PATH_FORWARDER_ADDITIONAL_ENDPOINTS="[{\"api_key\": \"apiKey2\", \"Host\": \"netpath-intake.datadoghq.com\", \"Port\": 443, \"is_reliable\": true}]" +DD_NETWORK_PATH_FORWARDER_ADDITIONAL_ENDPOINTS="[{\"api_key\": \"apiKey2\", \"Host\": \"netpath-intake.{{< region-param key="dd_site">}}\", \"Port\": 443, \"is_reliable\": true}]" ``` {{% agent-dual-shipping %}} -## Cloud Security Misconfigurations +## Cloud Security Misconfigurations {#cloud-security-misconfigurations} -### Configuration YAML +### Configuration YAML {#yaml-configuration-9} Dans `datadog.yaml` : + ```yaml compliance_config: endpoints: force_use_http: true additional_endpoints: - api_key: "apiKey2" - Host: "https://-app.agent.datadoghq.eu" - Port: 443 + host: "cspm-intake.{{< region-param key="dd_site">}}.:443" is_reliable: true ``` -### Configuration des variables d'environnement +### Configuration par variable d'environnement {#environment-variable-configuration-10} ```bash DD_COMPLIANCE_CONFIG_ENDPOINTS_USE_HTTP=true -DD_COMPLIANCE_CONFIG_ENDPOINTS_ADDITIONAL_ENDPOINTS="[{\"api_key\": \"apiKey2\", \"Host\": \"https://-app.agent.datadoghq.eu\", \"Port\": 443, \"is_reliable\": true}]" +DD_COMPLIANCE_CONFIG_ENDPOINTS_ADDITIONAL_ENDPOINTS="[{\"api_key\": \"apiKey2\", \"host\": \"cspm-intake.{{< region-param key="dd_site">}}.:443\", \"is_reliable\": true}]" ``` {{% agent-dual-shipping %}} -## Workload Protection +## Workload Protection {#workload-protection} -### Configuration YAML +### Configuration YAML {#yaml-configuration-10} Dans `datadog.yaml` : + ```yaml runtime_security_config: endpoints: force_use_http: true additional_endpoints: - api_key: "apiKey2" - Host: "https://-app.agent.datadoghq.eu" - Port: 443 + host: "cws-intake.{{< region-param key="dd_site">}}.:443" is_reliable: true ``` -### Configuration des variables d'environnement +### Configuration par variable d'environnement {#environment-variable-configuration-11} ```bash DD_RUNTIME_SECURITY_CONFIG_ENDPOINTS_USE_HTTP=true -DD_RUNTIME_SECURITY_CONFIG_ENDPOINTS_ADDITIONAL_ENDPOINTS="[{\"api_key\": \"apiKey2\", \"Host\": \"https://-app.agent.datadoghq.eu\", \"Port\": 443, \"is_reliable\": true}]" +DD_RUNTIME_SECURITY_CONFIG_ENDPOINTS_ADDITIONAL_ENDPOINTS="[{\"api_key\": \"apiKey2\", \"host\": \"cws-intake.{{< region-param key="dd_site">}}.:443\", \"is_reliable\": true}]" ``` {{% agent-dual-shipping %}} -## Transmission multiple dans Kubernetes +## Double envoi dans Kubernetes {#dual-shipping-in-kubernetes} {{< tabs >}} {{% tab "Helm" %}} -Si vous utilisez le [chart Helm de l'Agent Datadog][1], vous pouvez configurer ces paramètres avec une configmap. Dans le fichier `values.yaml`, définissez `useConfigMap: true` et ajoutez les paramètres pertinents à `customAgentConfig`. et ajoutez les paramètres appropriés à `customAgentConfig`. +Si vous utilisez le [Datadog Agent Helm chart][1], vous pouvez configurer ces paramètres avec une configmap. Dans le `values.yaml`, définissez `useConfigMap: true` +et ajoutez les paramètres pertinents à `customAgentConfig`. ```yaml # agents.useConfigMap -- Configures a configmap to provide the agent configuration. Use this in combination with the `agents.customAgentConfig` parameter. @@ -424,30 +435,30 @@ Si vous utilisez le [chart Helm de l'Agent Datadog][1], vous pouvez configurer c # agents.customAgentConfig -- Specify custom contents for the datadog agent config (datadog.yaml) ## ref: https://docs.datadoghq.com/agent/configuration/agent-configuration-files/?tab=agentv6 - ## ref: https://github.com/DataDog/datadog-agent/blob/main/pkg/config/config_template.yaml + ## ref: https://github.com/DataDog/datadog-agent/tree/main/pkg/config/example ## Note the `agents.useConfigMap` needs to be set to `true` for this parameter to be taken into account. customAgentConfig: additional_endpoints: - "https://app.datadoghq.com": + "https://app.": # Replace with your Datadog site parameter (for example, datadoghq.com). - apikey2 - apikey3 - "https://app.datadoghq.eu": + "https://app.": # Replace with your Datadog site parameter (for example, datadoghq.eu). - apikey4 logs_config: force_use_http: true additional_endpoints: - api_key: "apiKey2" - Host: "agent-http-intake.logs.datadoghq.com" + Host: "agent-http-intake.logs." # Replace with your Datadog site parameter (for example, datadoghq.com). Port: 443 is_reliable: true ``` -Pour éviter d'exposer votre ou vos clés d'API en clair à l'intérieur de la `ConfigMap`, vous pouvez également utiliser la configuration de variable d'environnement et référencer un secret Kubernetes. Voici un exemple pour envoyer des métriques vers une région supplémentaire : +Pour éviter d'exposer votre ou vos clés d'API en texte clair dans le `ConfigMap`, vous pouvez également utiliser la configuration par variable d'environnement et référencer un secret Kubernetes. Voici un exemple pour envoyer des métriques vers une région supplémentaire : -1. Créez un secret Kubernetes avec la valeur de configuration de votre variable d'environnement issue de ce guide : +1. Créez un secret Kubernetes avec la valeur de configuration de votre variable d'environnement à partir de ce guide : ```bash - kubectl create -n secret generic dual-shipping --from-literal metrics='{"https://app.datadoghq.eu": ["apikey4"]}' + kubectl create -n secret generic dual-shipping --from-literal metrics='{"https://app.": ["apikey4"]}' # Replace with your Datadog site parameter (for example, datadoghq.eu). ``` 2. Utilisez les [paramètres du chart Helm][2] `datadog.env` ou `datadog.envFrom` pour référencer ce secret dans votre configuration : ```yaml @@ -468,7 +479,7 @@ Pour éviter d'exposer votre ou vos clés d'API en clair à l'intérieur de la ` {{% tab "Datadog Operator" %}} -Si vous utilisez l'[opérateur de l'Agent Datadog][1], vous pouvez définir la clé de [remplacement][2] `[key].customConfigurations.[key].configData` pour définir ces paramètres. L'exemple ci-dessous remplace le fichier de configuration `datadog.yaml` du node Agent pour envoyer des métriques et des logs vers des régions supplémentaires. +Si vous utilisez l'[opérateur Datadog Agent][1], vous pouvez définir la clé `[key].customConfigurations.[key].configData` [override][2] pour configurer ces paramètres. L'exemple ci-dessous remplace le fichier de configuration `datadog.yaml` de l'Agent de nœud pour envoyer des métriques et des logs vers des régions supplémentaires. ```yaml apiVersion: datadoghq.com/v2alpha1 @@ -480,27 +491,28 @@ spec: nodeAgent: customConfigurations: datadog.yaml: + ## Replace with your Datadog site parameter (for example, datadoghq.com (US1) for `apikey2` and `apikey3`, and datadoghq.eu (EU) for `apikey4`). configData: |- additional_endpoints: - "https://app.datadoghq.com": + "https://app.": - apikey2 - apikey3 - "https://app.datadoghq.eu": + "https://app.": - apikey4 logs_config: force_use_http: true additional_endpoints: - api_key: "apiKey2" - Host: "agent-http-intake.logs.datadoghq.com" + Host: "agent-http-intake.logs." Port: 443 is_reliable: true ``` -Pour éviter d'exposer votre ou vos clés d'API en clair à l'intérieur de la `ConfigMap`, vous pouvez également utiliser la configuration de variable d'environnement et référencer un secret Kubernetes. Voici un exemple pour envoyer des métriques vers une région supplémentaire : +Pour éviter d'exposer votre ou vos clés d'API en texte clair dans le `ConfigMap`, vous pouvez également utiliser la configuration par variable d'environnement et référencer un secret Kubernetes. Voici un exemple pour envoyer des métriques vers une région supplémentaire : -1. Créez un secret Kubernetes avec la valeur de configuration de votre variable d'environnement issue de ce guide : +1. Créez un secret Kubernetes avec la valeur de configuration de votre variable d'environnement à partir de ce guide : ```bash - kubectl create -n secret generic dual-shipping --from-literal metrics='{"https://app.datadoghq.eu": ["apikey4"]}' + kubectl create -n secret generic dual-shipping --from-literal metrics='{"https://app.": ["apikey4"]}' # Replace with your Datadog site parameter (for example, datadoghq.eu). ``` 2. Utilisez le paramètre `[key].env` pour référencer ce secret dans votre configuration : ```yaml @@ -524,9 +536,10 @@ Pour éviter d'exposer votre ou vos clés d'API en clair à l'intérieur de la ` {{% /tab %}} {{< /tabs >}} -## Pour aller plus loin +## Pour aller plus loin {#further-reading} {{< partial name="whats-next/whats-next.html" >}} [1]: /fr/observability_pipelines/ -[2]: /fr/agent/configuration/network/ \ No newline at end of file +[2]: /fr/agent/configuration/network/ +[3]: /fr/getting_started/site/#access-the-datadog-site \ No newline at end of file diff --git a/hugo/content/fr/agent/guide/datadog-agent-manager-windows.md b/hugo/content/fr/agent/guide/datadog-agent-manager-windows.md index 76b65da4118..c6765d7b546 100644 --- a/hugo/content/fr/agent/guide/datadog-agent-manager-windows.md +++ b/hugo/content/fr/agent/guide/datadog-agent-manager-windows.md @@ -1,26 +1,28 @@ --- +description: Utilisez l'interface graphique du Datadog Agent Manager basée sur le + navigateur pour configurer et gérer l'Agent Windows avec les navigateurs et l'authentification + pris en charge. further_reading: - link: /agent/basic_agent_usage/windows/ tag: Documentation text: Utilisation de base de l'Agent pour l'Agent Windows title: Datadog Agent Manager pour Windows --- +## Présentation {#overview} -## Présentation +L'interface graphique du Datadog Agent Manager est basée sur le navigateur. Le port sur lequel l'interface graphique s'exécute peut être configuré dans votre fichier `datadog.yaml`. Définir le port sur `-1` désactive l'interface graphique. Par défaut, elle est activée sur le port 5002 pour Windows et Mac et est désactivée sur Linux. -L'interface graphique de Datadog Agent Manager repose sur l'utilisation d'un navigateur. Vous pouvez configurer le port sur lequel elle s'exécute dans votre fichier `datadog.yaml`. L'interface graphique est désactivée lorsque le port est défini sur `-1`. Par défaut, elle est activée sur le port 5002, pour Windows et Mac, et désactivée sur Linux. +### Prérequis {#requirements} -### Exigences +1. Les cookies doivent être activés dans votre navigateur. L'interface graphique génère et enregistre un jeton dans votre navigateur qui est utilisé pour authentifier toutes les communications avec le serveur de l'interface graphique. -1. Les cookies doivent être activés dans votre navigateur. L'interface graphique génère et enregistre un token dans votre navigateur, qui est utilisé pour authentifier toutes les communications effectuées avec le serveur de l'interface graphique. +2. L'interface graphique n'est lancée que si l'utilisateur qui la lance dispose des autorisations utilisateur appropriées. Si vous êtes en mesure d'ouvrir `datadog.yaml`, vous êtes en mesure d'utiliser l'interface graphique. -2. L'interface graphique se lance uniquement si l'utilisateur dispose des autorisations nécessaires. Si vous parvenez à ouvrir `datadog.yaml`, vous pouvez utiliser l'interface graphique. +3. Pour des raisons de sécurité, l'interface graphique ne peut être accessible qu'à partir de l'interface réseau locale (localhost/127.0.0.1), vous devez donc être sur le même host que celui sur lequel l'Agent s'exécute pour l'utiliser. En d'autres termes, vous ne pouvez pas exécuter l'Agent sur une VM ou un conteneur et y accéder depuis la machine du host. -3. Pour des raisons de sécurité, l'interface graphique est uniquement accessible à partir de l'interface réseau locale (localhost/127.0.0.1). Vous devez donc utiliser le même host que celui exécuté par l'Agent. Ainsi, vous ne pouvez pas exécuter l'Agent sur une machine virtuelle ou un conteneur et y accéder à partir de la machine du host. +#### Navigateurs pris en charge {#supported-browsers} -#### Navigateurs pris en charge - -| Browser | Version prise en charge (ou ultérieure) | Publier des commentaires | +| Navigateur | Version prise en charge (ou ultérieure) | Commentaire | |---------------|------------------------------|-------------------------| | IE | 11 | | | Edge | 12 | Edge pré-Chromium | @@ -28,49 +30,50 @@ L'interface graphique de Datadog Agent Manager repose sur l'utilisation d'un nav | Firefox | 38 | | | Chrome | 60 | | | Safari | 8 | | -| iOS | 12 | Safari mobile | +| iOS | 12 | Mobile Safari | -### Démarrer Datadog Agent Manager +### Démarrez le Datadog Agent Manager {#start-the-datadog-agent-manager} Une fois l'Agent [installé][1] sur votre host Windows, lancez Datadog Agent Manager pour gérer graphiquement l'Agent. À partir du menu Démarrer de Windows : -* Cliquez sur le dossier Datadog. -* Faites un clic droit sur Datadog Agent Manager. -* Choisissez `Exécuter en tant qu'administrateur`. +* Cliquez sur le dossier {{< ui >}}Datadog{{< /ui >}}. +* Faites un clic droit sur {{< ui >}}Datadog Agent Manager{{< /ui >}}. +* Choisissez {{< ui >}}Run as Administrator{{< /ui >}}. Depuis une invite PowerShell avec élévation de privilèges : + ```powershell & "$env:ProgramFiles\Datadog\Datadog Agent\bin\agent.exe" launch-gui ``` -Datadog Agent Manager se lance dans votre navigateur Web par défaut. L'adresse Web est `http://127.0.0.1:5002`. +Le Datadog Agent Manager se lance dans votre navigateur web par défaut. L'adresse web est `http://127.0.0.1:5002`. -## Options +## Options {#options} Les sections suivantes décrivent les options de la barre de navigation de gauche. -### Status +### État {#status} -#### General +#### Général {#general} -La page de statut General s'affiche par défaut lors du lancement de Datadog Agent Manager. Elle contient les sections suivantes : +La page d'état général s'affiche par défaut lors du lancement du Datadog Agent Manager. Elle contient les sections suivantes : | Section | Description | |-------------|---------------------------------------------------------------------------------| -| Agent Info | Informations sur l'Agent, notamment sa version, le niveau de log et les chemins de fichiers. | -| System Info | Informations sur l'heure système, le décalage NTP et les versions Go et Python. | -| Host Info | Informations sur le host, notamment le système d'exploitation, la plateforme, les processus et la disponibilité. | -| Hostnames | Hostnames et tags de host trouvés par l'Agent. | -| JMX Status | Liste des checks JMX et de leur statut. | -| Forwarder | Informations sur le Forwarder de l'Agent, y compris le statut de votre clé d'API. | -| Endpoints | Endpoints utilisés par l'Agent. | -| Logs Agent | Informations sur l'Agent de logs (lorsque celui-ci est activé). | -| Aggregator | Informations sur l'agrégateur de données de l'Agent. | -| DogStatsD | Statistiques sur les données envoyées via DogStatsD. | - -#### Collector +| {{< ui >}}Agent Info{{< /ui >}} | Fournit des informations sur l'Agent, notamment la version, le niveau de log et les chemins d'accès aux fichiers. | +| {{< ui >}}System Info{{< /ui >}} | Inclut des informations sur l'heure système, le décalage NTP, ainsi que les versions de Go et de Python. | +| {{< ui >}}Host Info{{< /ui >}} | Fournit des informations sur le host, notamment le système d'exploitation, la plateforme, les processus et la durée de fonctionnement. | +| {{< ui >}}Hostnames{{< /ui >}} | Affiche les noms de host et les tags de host détectés par l'Agent. | +| {{< ui >}}JMX Status{{< /ui >}} | Une liste des checks JMX avec leur état. | +| {{< ui >}}Forwarder{{< /ui >}} | Informations sur le forwarder de l'Agent, y compris l'état de votre clé d'API. | +| {{< ui >}}Endpoints{{< /ui >}} | Endpoints utilisés par l'Agent. | +| {{< ui >}}Logs Agent{{< /ui >}} | Informations sur l'Agent de logs (si activé). | +| {{< ui >}}Aggregator{{< /ui >}} | Informations sur l'agrégateur de données de l'Agent. | +| {{< ui >}}DogStatsD{{< /ui >}} | Statistiques sur les données envoyées avec DogStatsD. | + +#### Collecteur {#collector} La page de statut Collector affiche des détails sur les checks de l'Agent en cours d'exécution, par exemple : @@ -84,9 +87,9 @@ cpu Average Execution Time: 4ms ``` -### Log +### Log {#log} -La page Log affiche les logs de l'Agent renvoyés au sein de `agent.log`. Les logs peuvent être triés du plus récent au plus ancien et vice-versa. +La page des logs affiche les logs de l'Agent envoyés vers `agent.log`. Les logs peuvent être triés du plus récent au plus ancien ou inversement. ```text 2019-07-10 17:46:04 EDT | INFO | (runner.go:246 in work) | Running check cpu @@ -110,38 +113,38 @@ La page Log affiche les logs de l'Agent renvoyés au sein de `agent.log`. Les lo 2019-07-10 17:48:02 EDT | INFO | (transaction.go:114 in Process) | Successfully posted payload to "https://6-2-1-app.agent.datadoghq.com/api/v1/check_run?api_key=*************************12345" ``` -### Paramètres +### Paramètres {#settings} -La page Settings affiche le contenu du fichier de configuration principal de l'Agent, `datadog.yaml`. Vous pouvez modifier directement ce fichier depuis Datadog Agent Manager. Après l'avoir modifié, cliquez sur **Save** dans le coin supérieur droit, puis [redémarrez l'Agent](#redemarrer-l-agent). +La page des paramètres affiche le contenu du fichier de configuration principal de l'Agent `datadog.yaml`. Vous pouvez modifier ce fichier directement depuis le Datadog Agent Manager. Après avoir effectué une modification, cliquez sur {{< ui >}}Save{{< /ui >}} dans le coin supérieur droit, puis [redémarrez l'Agent](#restart-agent). -Consultez le [fichier d'exemple config_template.yaml][2] pour découvrir toutes les options de configuration disponibles. +Pour obtenir une liste complète des options disponibles, consultez le [fichier `datadog.yaml` exemple pour Windows][6]. -### Checks +### Checks {#checks} -#### Manage checks +#### Gérer les checks {#manage-checks} -La page Manage checks affiche le contenu des fichiers de configuration de check activés. Vous pouvez modifier directement ces fichiers depuis Datadog Agent Manager. Après avoir effectué une modification, cliquez sur **Save** dans le coin supérieur droit, puis [redémarrez l'Agent](#redemarrer-l-agent). +La page de gestion des checks affiche le contenu des fichiers de configuration des checks activés. Vous pouvez modifier ces fichiers directement depuis le Datadog Agent Manager. Après avoir effectué une modification, cliquez sur {{< ui >}}Save{{< /ui >}} dans le coin supérieur droit, puis [redémarrez l'Agent](#restart-agent). -Pour ajouter un check, sélectionnez **Add a Check** dans le menu déroulant. La liste de tous les checks pouvant être installés s'affiche alors. Consultez la page d'[intégration][3] du check de votre choix pour obtenir des détails sur sa configuration. +Pour ajouter un check, sélectionnez {{< ui >}}Add a Check{{< /ui >}} dans le menu déroulant. Cela affiche une liste des checks disponibles à installer. Consultez la page d'[intégration][3] du check spécifique pour obtenir des détails sur la configuration. -#### Sommaire des checks +#### Résumé des checks {#checks-summary} Le sommaire des checks contient la liste des checks en cours d'exécution, le nombre d'instances pour chaque check, ainsi que le statut du check. -### Flare +### Flare {#flare} -Si vous rencontrez des difficultés avec l'Agent, la page Flare facilite le dépannage avec l'équipe d'[assistance Datadog][4]. Entrez votre numéro de ticket (facultatif) et votre adresse e-mail, puis cliquez sur **Submit**. Une copie des logs et des fichiers de configuration de votre Agent est alors envoyée à l'assistance Datadog. Pour en savoir plus sur la fonctionnalité Flare de l'Agent, consultez la [documentation dédiée][5]. +Si vous rencontrez des problèmes avec l'Agent, la page flare vous aide à effectuer le dépannage avec l'équipe du [support Datadog][4]. Saisissez votre numéro de ticket (facultatif) et votre adresse e-mail, puis cliquez sur {{< ui >}}Submit{{< /ui >}}. Ceci transmet une copie des logs et des fichiers de configuration de votre Agent au support Datadog. Plus d'informations sur les flares sont disponibles dans la documentation [Agent Flare][5]. -### Redémarrer l'Agent +### Redémarrer l'Agent {#restart-agent} -Cliquez sur **Restart Agent** dans la barre de navigation de gauche pour redémarrer immédiatement l'Agent. Aucune page ni aucun message de confirmation ne s'affiche. Après avoir redémarré l'Agent, la page de [statut General](#general) s'affiche. +Cliquer sur {{< ui >}}Restart Agent{{< /ui >}} dans la barre de navigation de gauche redémarre l'Agent immédiatement. Il n'y a ni page ni invite de confirmation. Après le redémarrage de l'Agent, vous êtes redirigé vers la page [d'état général](#general) -## Pour aller plus loin +## Pour aller plus loin {#further-reading} {{< partial name="whats-next/whats-next.html" >}} [1]: /fr/agent/basic_agent_usage/windows/#installation -[2]: https://github.com/DataDog/datadog-agent/blob/master/pkg/config/config_template.yaml [3]: /fr/integrations/ [4]: /fr/help/ -[5]: /fr/agent/troubleshooting/send_a_flare/ \ No newline at end of file +[5]: /fr/agent/troubleshooting/send_a_flare/ +[6]: https://github.com/DataDog/datadog-agent/blob/main/pkg/config/example/datadog-agent_windows.yaml.example \ No newline at end of file diff --git a/hugo/content/fr/agent/supported_platforms/windows.md b/hugo/content/fr/agent/supported_platforms/windows.md index 4011f5e2e64..85ce397e259 100644 --- a/hugo/content/fr/agent/supported_platforms/windows.md +++ b/hugo/content/fr/agent/supported_platforms/windows.md @@ -9,7 +9,7 @@ algolia: aliases: - /fr/guides/basic_agent_usage/windows/ - /fr/agent/basic_agent_usage/windows/ -description: Fonctionnalité de base de l'Agent Datadog sur la plateforme Windows. +description: Fonctionnalités de base du Datadog Agent sur la plateforme Windows. further_reading: - link: /logs/ tag: Documentation @@ -22,62 +22,62 @@ further_reading: text: Recueillir vos traces - link: /agent/architecture/#agent-architecture tag: Documentation - text: Découvrez-en plus sur l'architecture de l'Agent. + text: En savoir plus sur l'architecture de l'Agent - link: /agent/configuration/network#configure-ports tag: Documentation - text: Configurez les ports entrants. + text: Configurer les ports entrants - link: /agent/guide/windows-agent-ddagent-user tag: Documentation - text: En savoir plus sur l'utilisateur de l'Agent Datadog pour Windows. + text: En savoir plus sur l'utilisateur du Datadog Agent pour Windows platform: Windows title: Windows --- -## Aperçu {#overview} +## Présentation {#overview} -Cette page décrit les fonctionnalités de base de l'Agent Datadog pour Windows. Si vous n'avez pas encore installé l'Agent, consultez les instructions d'installation ci-dessous ou [suivez les instructions dans l'application][1]. +Cette page présente les fonctionnalités de base du Datadog Agent pour Windows. Si vous n'avez pas encore installé l'Agent, consultez les instructions d'installation ci-dessous ou [suivez les instructions dans l'application][1]. -Voir [Plateformes prises en charge][15] pour la liste complète des versions de Windows prises en charge. +Consultez [Plateformes prises en charge][15] pour obtenir la liste complète des versions de Windows prises en charge. ## Installation {#installation} -Pour installer l'Agent Datadog sur vos hôtes Windows, suivez le [flux guidé dans l'application au sein de Fleet Automation][16], puis copiez et exécutez la commande d'installation. Les Agents Datadog s'exécutent sous le `ddagentuser`. Consultez la documentation [Utilisateur de l'Agent Datadog pour Windows][17] pour plus d'informations. +Pour installer le Datadog Agent sur vos hosts Windows, suivez le [flux guidé dans l'application au sein de Fleet Automation][16], puis copiez et exécutez la commande d'installation. Les Agents Datadog s'exécutent sous le `ddagentuser`. Consultez la documentation de l'utilisateur Datadog Windows Agent [17] pour plus d'informations. -{{< img src="/agent/basic_agent_usage/windows_img2_july_25.png" alt="Étapes d'installation dans l'application pour l'Agent Datadog sur un hôte Windows." style="width:90%;">}} +{{< img src="/agent/basic_agent_usage/windows_img2_july_25.png" alt="Étapes d'installation dans l'application pour le Datadog Agent sur un host Windows." style="width:90%;">}} ## Méthodes d'installation alternatives {#alternative-installation-methods} -### Installer avec l'interface graphique du Gestionnaire d'Agent {#install-with-the-agent-manager-gui} +### Installer avec l'interface graphique de l'Agent Manager {#install-with-the-agent-manager-gui}
L'emplacement d'installation par défaut de l'Agent est %ProgramFiles%\Datadog\Datadog AgentSi vous choisissez d'utiliser un emplacement d'installation personnalisé, assurez-vous de spécifier un Datadog sous-répertoire pour les fichiers Datadog.
-1. Téléchargez le [programme d'installation de l'Agent Datadog][400] pour installer la dernière version de l'Agent. +1. Téléchargez le [programme d'installation du Datadog Agent][400] pour installer la dernière version de l'Agent. 2. Exécutez le programme d'installation en ouvrant `datadog-agent-7-latest.amd64.msi`. Lorsque vous y êtes invité, saisissez vos identifiants d'administrateur. -3. Suivez les instructions, acceptez le contrat de licence et saisissez votre [clé API Datadog][500]. +3. Suivez les instructions, acceptez le contrat de licence et saisissez votre [clé d'API Datadog][500]. Une fois l'installation terminée, vous avez la possibilité de lancer Datadog Agent Manager. -#### Options de configuration d'installation {#installation-configuration-options} +#### Options de configuration de l'installation {#installation-configuration-options} -Chacune des options de configuration suivantes peut être ajoutée en tant que propriété dans la ligne de commande lors de l'installation de l'Agent sur Windows. Pour des options de configuration supplémentaires de l'Agent, consultez [plus d'options de configuration de l'Agent](#more-agent-configuration-options). +Chacune des options de configuration suivantes peut être ajoutée en tant que propriété dans la ligne de commande lors de l'installation de l'Agent sur Windows. Pour des options de configuration de l'Agent supplémentaires, consultez [plus d'options de configuration de l'Agent](#more-agent-configuration-options). | Variable | Type | Description | |---------------------------- |---------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| `APIKEY` | Chaîne | Ajoute la clé API Datadog au fichier de configuration. | -| `SITE` | Chaîne | Définit le site d'entrée Datadog, par exemple : `SITE=datadoghq.com` | -| `TAGS` | Chaîne | Liste de tags séparés par des virgules à attribuer dans le fichier de configuration. Exemple : `TAGS="key_1:val_1,key_2:val_2"` | -| `HOSTNAME` | Chaîne | Configure le nom d'hôte rapporté par l'Agent à Datadog (remplace tout nom d'hôte calculé à l'exécution). | -| `DDAGENTUSER_NAME` | Chaîne | Remplace le `ddagentuser` nom d'utilisateur par défaut utilisé lors de l'installation de l'Agent _(v6.11.0+)_. [En savoir plus sur l'utilisateur de l'Agent Datadog pour Windows][3]. | -| `DDAGENTUSER_PASSWORD` | Chaîne | Remplace le mot de passe cryptographiquement sécurisé généré pour le `ddagentuser` utilisateur lors de l'installation de l'Agent _(v6.11.0+)_. Doit être fourni pour les installations sur des serveurs de domaine. [En savoir plus sur l'utilisateur de l'Agent Datadog pour Windows][3]. | -| `APPLICATIONDATADIRECTORY` | Chemin | Remplacer le répertoire à utiliser pour l'arborescence du répertoire du fichier de configuration. Ne peut être fourni que lors de l'installation initiale; non valide pour les mises à niveau. Par défaut : `C:\ProgramData\Datadog`. _(v6.11.0+)_ | -| `PROJECTLOCATION` | Chemin | Remplacer le répertoire à utiliser pour l'arborescence du répertoire binaire. Ne peut être fourni que lors de l'installation initiale; non valide pour les mises à niveau. Par défaut : `%ProgramFiles%\Datadog\Datadog Agent`. _(v6.11.0+)_

Si vous choisissez de remplacer le répertoire par défaut, assurez-vous de spécifier un `Datadog` sous-répertoire pour les fichiers Datadog. | - -**Notes** - -- L'option `/qn` exécute une installation silencieuse. Pour voir les invites de l'interface graphique, retirez-le. +| `APIKEY` | Chaîne | Ajoute la clé d'API Datadog API au fichier de configuration. | +| `SITE` | Chaîne | Définit le site d'ingestion Datadog, par exemple : `SITE=datadoghq.com` | +| `TAGS` | Chaîne | Liste séparée par des virgules de tags à attribuer dans le fichier de configuration. Exemple : `TAGS="key_1:val_1,key_2:val_2"` | +| `HOSTNAME` | Chaîne | Configure le nom de host rapporté par l'Agent à Datadog (remplace tout nom de host calculé au moment de l'exécution). | +| `DDAGENTUSER_NAME` | Chaîne | Remplace le nom d'utilisateur `ddagentuser` par défaut utilisé lors de l'installation de l'Agent _(v6.11.0+)_. [En savoir plus sur l'utilisateur du Datadog Agent pour Windows][3]. | +| `DDAGENTUSER_PASSWORD` | Chaîne | Remplace le mot de passe sécurisé cryptographiquement généré pour l'utilisateur `ddagentuser` lors de l'installation de l'Agent _(v6.11.0+)_. Doit être fourni pour les installations sur des serveurs de domaine. [En savoir plus sur l'utilisateur du Datadog Agent pour Windows][3]. | +| `APPLICATIONDATADIRECTORY` | Chemin | Remplace le répertoire à utiliser pour l'arborescence du fichier de configuration. Ne peut être fourni que lors de l'installation initiale ; non valide pour les mises à niveau. Par défaut : `C:\ProgramData\Datadog`. _(v6.11.0+)_ | +| `PROJECTLOCATION` | Chemin | Remplace le répertoire à utiliser pour l'arborescence du fichier binaire. Ne peut être fourni que lors de l'installation initiale ; non valide pour les mises à niveau. Par défaut : `%ProgramFiles%\Datadog\Datadog Agent`. _(v6.11.0+)_

Si vous choisissez de remplacer le répertoire par défaut, assurez-vous de spécifier un sous-répertoire `Datadog` pour les fichiers Datadog. | + +**Remarques** + +- L'option `/qn` exécute une installation silencieuse. Pour voir les invites de l'interface graphique, supprimez-la. - Certaines versions de l'Agent peuvent provoquer un redémarrage forcé. Pour éviter cela, ajoutez le paramètre : `REBOOT=ReallySuppress`. - Certains composants de l'Agent nécessitent un pilote de noyau pour collecter des données. Pour savoir si un pilote de noyau est requis pour votre composant, consultez sa page de documentation ou recherchez `kernel driver` dans les fichiers de configuration de l'Agent associés. - Si un `datadog.yaml` valide est trouvé, ce fichier prévaut sur toutes les options de ligne de commande spécifiées. @@ -91,42 +91,42 @@ Chacune des options de configuration suivantes peut être ajoutée en tant que p | Variable | Type | Description | |---------------------------- |---------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| `LOGS_ENABLED` | Chaîne | Activez (`"true"`) ou désactivez (`"false"`) la fonctionnalité de collecte de journaux dans le fichier de configuration. Les journaux sont désactivés par défaut. | -| `APM_ENABLED` | Chaîne | Activez (`"true"`) ou désactivez (`"false"`) l'Agent APM dans le fichier de configuration. APM est activé par défaut. | -| `PROCESS_ENABLED` | Chaîne | Activez (`"true"`) ou désactivez (`"false"`) l'Agent de Processus dans le fichier de configuration. L'Agent de Processus est désactivé par défaut. | -| `HOSTNAME_FQDN_ENABLED` | Chaîne | Activez (`"true"`) ou désactivez (`"false"`) l'utilisation de FQDN pour le nom d'hôte de l'Agent. Il est équivalent à définir `hostname_fqdn` dans le fichier de configuration de l'Agent. L'utilisation de FQDN pour le nom d'hôte est désactivée par défaut. _(v6.20.0+)_ | -| `CMD_PORT` | Numéro | Un numéro de port valide entre 0 et 65534. L'Agent Datadog expose une API de commande sur le port 5001. Si ce port est déjà utilisé par un autre programme, la valeur par défaut peut être remplacée ici. | -| `PROXY_HOST` | Chaîne | (Si vous utilisez un proxy) définit votre hôte proxy. [En savoir plus sur l'utilisation d'un proxy avec l'Agent Datadog][4]. | -| `PROXY_PORT` | Numéro | (Si vous utilisez un proxy) définit votre port proxy. [En savoir plus sur l'utilisation d'un proxy avec l'Agent Datadog][4]. | -| `PROXY_USER` | Chaîne | (Si vous utilisez un proxy) définit votre utilisateur proxy. [En savoir plus sur l'utilisation d'un proxy avec l'Agent Datadog][4]. | -| `PROXY_PASSWORD` | Chaîne | (Si vous utilisez un proxy) définit votre mot de passe proxy. Pour l'Agent de processus/conteneur, cette variable est requise pour passer un mot de passe d'authentification et ne peut pas être renommée. [En savoir plus sur l'utilisation d'un proxy avec l'Agent Datadog][4]. | -| `EC2_USE_WINDOWS_PREFIX_DETECTION` | Booléen | Utilisez l'identifiant de l'instance EC2 pour les hôtes Windows sur EC2. _(v7.28.0+)_ | +| `LOGS_ENABLED` | Chaîne | Active (`"true"`) ou désactive (`"false"`) la fonctionnalité de collecte des logs dans le fichier de configuration. Les logs sont désactivés par défaut. | +| `APM_ENABLED` | Chaîne | Active (`"true"`) ou désactive (`"false"`) l'Agent APM dans le fichier de configuration. L'APM est activé par défaut. | +| `PROCESS_ENABLED` | Chaîne | Active (`"true"`) ou désactive (`"false"`) l'Agent de processus dans le fichier de configuration. L'Agent de processus est désactivé par défaut. | +| `HOSTNAME_FQDN_ENABLED` | Chaîne | Active (`"true"`) ou désactive (`"false"`) l'utilisation du FQDN pour le nom de host de l'Agent. Cela équivaut à définir `hostname_fqdn` dans le fichier de configuration de l'Agent. L'utilisation du FQDN pour le nom de host est désactivée par défaut. _(v6.20.0+)_ | +| `CMD_PORT` | Nombre | Un numéro de port valide compris entre 0 et 65534. Le Datadog Agent expose une API de commande sur le port 5001. Si ce port est déjà utilisé par un autre programme, la valeur par défaut peut être remplacée ici. | +| `PROXY_HOST` | Chaîne | (Si vous utilisez un proxy) définit votre host de proxy. [En savoir plus sur l'utilisation d'un proxy avec le Datadog Agent][4]. | +| `PROXY_PORT` | Nombre | (Si vous utilisez un proxy) définit votre port de proxy. [En savoir plus sur l'utilisation d'un proxy avec le Datadog Agent][4]. | +| `PROXY_USER` | Chaîne | (Si vous utilisez un proxy) définit votre utilisateur de proxy. [En savoir plus sur l'utilisation d'un proxy avec le Datadog Agent][4]. | +| `PROXY_PASSWORD` | Chaîne | (Si vous utilisez un proxy) définit votre mot de passe de proxy. Pour l'Agent de processus/conteneur, cette variable est requise pour transmettre un mot de passe d'authentification et ne peut pas être renommée. [En savoir plus sur l'utilisation d'un proxy avec le Datadog Agent][4]. | +| `EC2_USE_WINDOWS_PREFIX_DETECTION` | Booléen | Utilisez l'identifiant d'instance EC2 pour les hosts Windows sur EC2. _(v7.28.0+)_ | -#### Fichiers journaux d'installation {#installation-log-files} +#### Fichiers logs d'installation {#installation-log-files} -Définissez l'option `/log ` msiexec pour configurer un fichier journal d'installation. Si cette option n'est pas définie, msiexec écrit le journal par défaut dans `%TEMP%\MSI*.LOG`. +Définissez l'option `/log ` msiexec pour configurer un fichier log d'installation. Si cette option n'est pas définie, msiexec écrit le log dans `%TEMP%\MSI*.LOG` par défaut. ## Configuration {#configuration} -Le fichier de configuration principal de l'Agent se trouve à -`C:\ProgramData\Datadog\datadog.yaml`. Ce fichier est utilisé pour les paramètres globaux tels que la clé API, le site Datadog sélectionné, les paramètres du proxy, les balises d'hôte et le niveau de journalisation. +Le fichier de configuration principal de l'Agent se trouve à l'emplacement suivant : +`C:\ProgramData\Datadog\datadog.yaml`. Ce fichier est utilisé pour les paramètres à l'échelle du host, tels que la clé d'API, le site Datadog sélectionné, les paramètres de proxy, les tags de host et le niveau de log. -Il y a aussi un fichier `datadog.yaml.example` dans le même répertoire, qui est une référence entièrement commentée avec toutes les options de configuration disponibles, utile pour référence et pour copier des paramètres spécifiques. +Il existe également un fichier `datadog.yaml.example` dans le même répertoire, qui est une référence entièrement commentée contenant toutes les options de configuration disponibles, utile pour consulter et copier des paramètres spécifiques. Sinon, consultez l'[exemple de fichier de configuration de l'Agent pour Windows][19] sur GitHub. Les fichiers de configuration pour les intégrations se trouvent dans : -`C:\ProgramData\Datadog\conf.d\` Il peut également y avoir un emplacement alternatif hérité : `C:\Documents and Settings\All Users\Application Data\Datadog\conf.d\`. +`C:\ProgramData\Datadog\conf.d\` Il peut également y avoir un autre emplacement hérité : `C:\Documents and Settings\All Users\Application Data\Datadog\conf.d\`. -Chaque intégration a un sous-répertoire `.d\` qui contient : -- `conf.yaml` : Les paramètres actifs pour l'intégration -* `conf.yaml.example` : Un fichier d'exemple montrant quelles clés de configuration sont prises en charge +Chaque intégration possède un sous-répertoire `.d\` qui contient : +- `conf.yaml` : Les paramètres actifs pour l'intégration +* `conf.yaml.example` : Un exemple de fichier montrant quelles clés de configuration sont prises en charge -Lors de la modification des configurations, assurez-vous de redémarrer l'Agent pour que les modifications prennent effet. +Lorsque vous effectuez des modifications de configuration, assurez-vous de redémarrer l'Agent pour que les modifications prennent effet. -L'[interface graphique du gestionnaire d'Agent Datadog][6] peut être utilisée pour activer, désactiver et configurer des vérifications. Vous devez redémarrer l'Agent pour que vos modifications prennent effet. +L'[interface graphique du Datadog Agent Manager][6] peut être utilisée pour activer, désactiver et configurer les checks. Vous devez redémarrer l'Agent pour que vos modifications prennent effet. -**Note** : `ProgramData` est un dossier caché. +**Remarque** : `ProgramData` est un dossier masqué. ## Commandes de l'Agent {#agent-commands} @@ -134,27 +134,27 @@ L'exécution de l'Agent est contrôlée par le gestionnaire de contrôle des ser * Le nom de l'exécutable principal est `agent.exe`. * L'interface graphique de configuration est une application de configuration basée sur un navigateur (pour Windows 64 bits uniquement). -* Les commandes peuvent être exécutées depuis la **ligne de commande élevée (exécuter en tant qu'Admin)** en utilisant la syntaxe ` `. -* Les options de ligne de commande sont ci-dessous : +* Les commandes peuvent être exécutées depuis la ligne de commande **élevée (exécutée en tant qu'administrateur)** (PowerShell ou invite de commande) en utilisant la syntaxe ` `. +* Les options de ligne de commande sont ci-dessous : | Commande | Description | |-----------------|----------------------------------------------------------------------------------| -| check | Exécute la vérification spécifiée. | -| diagnostiquer | Exécute un diagnostic de connectivité sur votre système. | +| Exécute le check spécifié.| | +| diagnose | Exécute un diagnostic de connectivité sur votre système. | | flare | Collecte un flare et l'envoie à Datadog. | -| aide | Obtient de l'aide sur n'importe quelle commande. | -| nom d'hôte | Affiche le nom d'hôte utilisé par l'Agent. | -| importer | Importe et convertit les fichiers de configuration des versions précédentes de l'Agent. | -| lancer-gui | Démarre le Datadog Agent Manager. | -| redémarrer-service | Redémarre l'Agent dans le gestionnaire de contrôle des services. | -| exécuter | Démarre l'Agent. | -| démarrer | Démarre l'Agent. (En cours de dépréciation, mais accepté. Utilisez `run` comme alternative.) | -| démarrer-service | Démarre l'Agent dans le gestionnaire de contrôle des services. | -| statut | Affiche le statut actuel. | -| arrêter-service | Arrête l'Agent dans le gestionnaire de contrôle des services. | -| version | Affiche les informations de version. | - -**Exemples**: +| help | Obtient de l'aide sur n'importe quelle commande. | +| hostname | Affiche le nom de host utilisé par l'Agent. | +| import | Importe et convertit les fichiers de configuration des versions précédentes de l'Agent. | +| launch-gui | Démarre le Datadog Agent Manager. | +| restart-service | Redémarre l'Agent au sein du gestionnaire de contrôle des services. | +| run | Démarre l'Agent. | +| start | Démarre l'Agent. (Obsolète, mais accepté. Utilisez `run` comme alternative.) | +| start-service | Démarre l'Agent au sein du gestionnaire de contrôle des services. | +| status | Affiche le statut actuel. | +| stopservice | Arrête l'Agent au sein du gestionnaire de contrôle des services. | +| version | Affiche les informations de version. | + +**Exemples** : - PowerShell (`powershell.exe`) ```powershell @@ -163,7 +163,7 @@ L'exécution de l'Agent est contrôlée par le gestionnaire de contrôle des ser & "$env:ProgramFiles\Datadog\Datadog Agent\bin\agent.exe" flare ``` - - Invite de commandes (`cmd.exe`) + - Command Prompt (`cmd.exe`) ```cmd "%ProgramFiles%\Datadog\Datadog Agent\bin\agent.exe" status @@ -171,19 +171,19 @@ L'exécution de l'Agent est contrôlée par le gestionnaire de contrôle des ser "%ProgramFiles%\Datadog\Datadog Agent\bin\agent.exe" flare ``` -## Désinstaller l'Agent {#uninstall-the-agent} +## Désinstalle l'Agent {#uninstall-the-agent} -Il existe deux méthodes différentes pour désinstaller l'Agent sur Windows. Les deux méthodes suppriment l'Agent, mais ne suppriment pas le dossier de configuration `C:\ProgramData\Datadog` sur l'hôte. +Il existe deux méthodes différentes pour désinstaller l'Agent sur Windows. Les deux méthodes suppriment l'Agent, mais ne suppriment pas le dossier de configuration `C:\ProgramData\Datadog` sur le host. ### Ajouter ou supprimer des programmes {#add-or-remove-programs} -1. Appuyez sur **CTRL** et **Esc** ou utilisez la touche Windows pour exécuter la recherche Windows. +1. Appuyez sur **CTRL** et **Esc** ou utilisez la touche Windows pour lancer la recherche Windows. 1. Recherchez `add` et cliquez sur {{< ui >}}Add or remove programs{{< /ui >}}. 1. Recherchez `Datadog Agent` et cliquez sur {{< ui >}}Uninstall{{< /ui >}}. ### PowerShell {#powershell} -**Remarque :** Activez WinRM pour utiliser les commandes ci-dessous. +**Remarque0:** Activez WinRM pour utiliser les commandes ci-dessous. Utilisez la commande PowerShell suivante pour désinstaller l'Agent sans redémarrage : @@ -194,22 +194,22 @@ start-process msiexec -Wait -ArgumentList ('/log', 'C:\uninst.log', '/q', '/x', ## Dépannage {#troubleshooting} -Pour les étapes de dépannage, consultez la [documentation de dépannage de l'Agent][18]. +Pour les étapes de dépannage, consultez la [documentation de dépannage de l'Agent][18] . -### Statut et informations de l'Agent {#agent-status-and-information} +### État et informations de l'Agent {#agent-status-and-information} -Pour vérifier que l'Agent fonctionne, vérifiez si le service `DatadogAgent` dans le panneau des Services est listé comme *Démarré*. Un processus appelé *Datadog Metrics Agent* (`agent.exe`) devrait également exister dans le Gestionnaire des tâches. +Pour vérifier que l'Agent est en cours d'exécution, vérifiez si le service `DatadogAgent` dans le panneau Services est indiqué comme *Démarré*. Un processus appelé *Datadog Metrics Agent* (`agent.exe`) devrait également exister dans le Gestionnaire des tâches. -Pour obtenir davantage d'informations sur l'état de l'agent, démarrez Datadog Agent Manager : +Pour obtenir davantage d'informations sur l'état de l'Agent, démarrez Datadog Agent Manager : -* Cliquez avec le bouton droit sur l'icône de la barre d'état système du Datadog Agent > {{< ui >}}Configure{{< /ui >}}, ou -* Exécutez `launch-gui` la commande depuis une **invite de commande élevée (exécuter en tant qu'Admin)** - - PowerShell : `& "" launch-gui` - - cmd : `"" launch-gui` +* Faites un clic droit sur l'icône de la barre d'état système du Datadog Agent > {{< ui >}}Configure{{< /ui >}}, ou +* Exécutez la commande `launch-gui` depuis une ligne de commande **élevée (exécuter en tant qu'administrateur)** + - PowerShell: `& "" launch-gui` + - cmd: `"" launch-gui` -Ensuite, ouvrez la page de statut en allant à {{< ui >}}Status{{< /ui >}} > {{< ui >}}General{{< /ui >}}. -Obtenez plus d'informations sur l'exécution des vérifications dans {{< ui >}}Status{{< /ui >}} > {{< ui >}}Collector{{< /ui >}} et {{< ui >}}Checks{{< /ui >}} > {{< ui >}}Summary{{< /ui >}}. +Ensuite, ouvrez la page d'état en allant sur {{< ui >}}Status{{< /ui >}} > {{< ui >}}General{{< /ui >}}. +Obtenez plus d'informations sur l'exécution des checks dans {{< ui >}}Status{{< /ui >}} > {{< ui >}}Collector{{< /ui >}} et {{< ui >}}Checks{{< /ui >}} > {{< ui >}}Summary{{< /ui >}}. La commande status est disponible pour PowerShell : @@ -223,41 +223,41 @@ ou cmd.exe : "%ProgramFiles%\Datadog\Datadog Agent\bin\agent.exe" status ``` -### Emplacement des journaux {#logs-location} +### Emplacement des logs {#logs-location} -Les journaux de l'Agent se trouvent dans `C:\ProgramData\Datadog\logs\agent.log`. +Les logs de l'Agent se trouvent dans `C:\ProgramData\Datadog\logs\agent.log`. -**Remarque** : `ProgramData` est un dossier caché. +**Remarque** : `ProgramData` est un dossier masqué. ## Cas d'utilisation {#use-cases} ### Surveillance d'un service Windows {#monitoring-a-windows-service} -Sur votre hôte cible, lancez le Gestionnaire de l'Agent Datadog et sélectionnez l'intégration {{< ui >}}Windows Service{{< /ui >}} dans la liste. Il existe un exemple prêt à l'emploi ; cependant, cet exemple utilise DHCP. +Sur votre host cible, lancez le Datadog Agent Manager et sélectionnez l'intégration {{< ui >}}Windows Service{{< /ui >}} dans la liste. Il existe un exemple prêt à l'emploi ; cependant, cet exemple utilise DHCP. Pour obtenir le nom du service, ouvrez `services.msc` et localisez votre service cible. En utilisant DHCP comme cible, vous pouvez voir le nom du service en haut de la fenêtre des propriétés du service : {{< img src="agent/faq/DHCP.png" alt="DHCP" style="width:75%;">}} -Lorsque vous ajoutez vos propres services, assurez-vous de suivre le format exactement comme indiqué. Si le format n'est pas correct, l'intégration échoue. **Remarque**: Les caractères spéciaux dans un nom de service doivent être échappés. Par exemple, le nom `MSSQL$BILLING` peut être ajouté avec `MSSQL\$BILLING`. +Lorsque vous ajoutez vos propres services, assurez-vous de respecter exactement le formatage indiqué. Si le formatage n'est pas correct, l'intégration échoue. **Remarque** : Les caractères spéciaux dans un nom de service doivent être échappés. Par exemple, le nom `MSSQL$BILLING` peut être ajouté avec `MSSQL\$BILLING`. {{< img src="agent/faq/windows_DHCP_service.png" alt="Windows DHCP Service" style="width:75%;">}} -De plus, chaque fois que vous modifiez une intégration, le service Datadog doit être redémarré. Vous pouvez le faire depuis services.msc ou depuis la barre latérale de l'interface utilisateur. +De plus, chaque fois que vous modifiez une intégration, le service Datadog doit être redémarré. Vous pouvez effectuer cette opération depuis services.msc ou depuis la barre latérale de l'interface utilisateur. -Pour les services, Datadog ne suit pas les métriques, seulement leur disponibilité. (Pour les métriques, utilisez l'intégration [Process](#monitoring-windows-processes) ou [WMI][7]). Pour configurer un Moniteur, sélectionnez le [type de moniteur d'intégration][8] puis recherchez {{< ui >}}Windows Service{{< /ui >}}. Depuis {{< ui >}}Integration Status{{< /ui >}} > {{< ui >}}Pick Monitor Scope{{< /ui >}}, choisissez le service que vous souhaitez surveiller. +Pour les Services, Datadog ne suit pas les métriques, seulement leur disponibilité. (Pour les métriques, utilisez l'intégration [Process](#monitoring-windows-processes) ou [WMI][7]). Pour configurer un Monitor, sélectionnez le [Integration monitor type][8], puis recherchez {{< ui >}}Windows Service{{< /ui >}}. Depuis {{< ui >}}Integration Status{{< /ui >}} > {{< ui >}}Pick Monitor Scope{{< /ui >}}, choisissez le service que vous souhaitez surveiller. ### Surveillance de la charge système pour Windows {#monitoring-system-load-for-windows} -Le Datadog Agent collecte par défaut un grand nombre de métriques système. Les métriques système les plus couramment utilisées sont `system.load.*`, mais ces métriques sont **Unix** spécifiques. +Le Datadog Agent collecte par défaut un grand nombre de métriques système. Les métriques système les plus couramment utilisées sont `system.load.*`, mais ces métriques sont spécifiques à **Unix**. -Bien que Windows n'offre pas les métriques `system.load.*`, une option équivalente disponible par défaut est `system.proc.queue.length`. Cette métrique montre le nombre de threads observés comme retardés dans la file d'attente prête du processeur qui attendent d'être exécutés. +Bien que Windows ne propose pas les métriques `system.load.*`, une option équivalente disponible par défaut est `system.proc.queue.length`. Cette métrique indique le nombre de threads observés comme étant retardés dans la file d'attente du processeur et en attente d'exécution. ### Surveillance des processus Windows {#monitoring-windows-processes} -Vous pouvez surveiller les processus Windows avec [Live Process Monitoring][9]. Pour activer ceci sur Windows, modifiez le [fichier de configuration principal de l'agent][10] en définissant le paramètre suivant sur vrai : +Vous pouvez surveiller les processus Windows avec [Live Process Monitoring][9]. Pour activer cette fonctionnalité sur Windows, modifiez le [fichier de configuration principal de l'Agent][10] en définissant le paramètre suivant sur true : -`datadog.yaml`: +`datadog.yaml` : ```yaml process_config: @@ -266,7 +266,7 @@ process_config: Une fois la configuration effectuée, [redémarrez l'Agent][11]. -## Lectures complémentaires {#further-reading} +## Pour aller plus loin {#further-reading} {{< partial name="whats-next/whats-next.html" >}} @@ -289,5 +289,6 @@ Une fois la configuration effectuée, [redémarrez l'Agent][11]. [16]: https://app.datadoghq.com/fleet/install-agent/latest?platform=windows [17]: /fr/agent/faq/windows-agent-ddagent-user/ [18]: https://docs.datadoghq.com/fr/agent/troubleshooting/ +[19]: https://github.com/DataDog/datadog-agent/blob/main/pkg/config/example/datadog-agent_windows.yaml.example [400]: https://windows-agent.datadoghq.com/datadog-agent-7-latest.amd64.msi [500]: https://app.datadoghq.com/organization-settings/api-keys \ No newline at end of file diff --git a/hugo/content/fr/api/latest/agent-observability/get-a-custom-evaluator-configuration/index.md b/hugo/content/fr/api/latest/agent-observability/get-a-custom-evaluator-configuration/index.md new file mode 100644 index 00000000000..3c774ae44ed --- /dev/null +++ b/hugo/content/fr/api/latest/agent-observability/get-a-custom-evaluator-configuration/index.md @@ -0,0 +1,3 @@ +--- +title: Obtenez une configuration d'évaluateur personnalisée +--- diff --git a/hugo/content/fr/api/latest/agent-observability/list-agent-observability-dataset-versions/index.md b/hugo/content/fr/api/latest/agent-observability/list-agent-observability-dataset-versions/index.md new file mode 100644 index 00000000000..61f770408c6 --- /dev/null +++ b/hugo/content/fr/api/latest/agent-observability/list-agent-observability-dataset-versions/index.md @@ -0,0 +1,3 @@ +--- +title: Lister les versions du jeu de données d'Agent Observability +--- diff --git a/hugo/content/fr/api/latest/agent-observability/list-patterns-clustered-points/index.md b/hugo/content/fr/api/latest/agent-observability/list-patterns-clustered-points/index.md new file mode 100644 index 00000000000..aa94aea48e8 --- /dev/null +++ b/hugo/content/fr/api/latest/agent-observability/list-patterns-clustered-points/index.md @@ -0,0 +1,3 @@ +--- +title: Liste des motifs de points groupés +--- diff --git a/hugo/content/fr/api/latest/llm-observability/unlock-agent-observability-dataset-draft-state/index.md b/hugo/content/fr/api/latest/llm-observability/unlock-agent-observability-dataset-draft-state/index.md new file mode 100644 index 00000000000..d9e12e27f6e --- /dev/null +++ b/hugo/content/fr/api/latest/llm-observability/unlock-agent-observability-dataset-draft-state/index.md @@ -0,0 +1,3 @@ +--- +title: Déverrouillez l'état de brouillon du jeu de données Agent Observability +--- diff --git a/hugo/content/fr/api/latest/rum-retention-quotas/get-a-rum-retention-quota-configuration/index.md b/hugo/content/fr/api/latest/rum-retention-quotas/get-a-rum-retention-quota-configuration/index.md new file mode 100644 index 00000000000..0fa16dbdc14 --- /dev/null +++ b/hugo/content/fr/api/latest/rum-retention-quotas/get-a-rum-retention-quota-configuration/index.md @@ -0,0 +1,3 @@ +--- +title: Obtenez une configuration de quota de rétention RUM. +--- diff --git a/hugo/content/fr/bits_ai/bits_investigation/chat_bits_investigation.md b/hugo/content/fr/bits_ai/bits_investigation/chat_bits_investigation.md new file mode 100644 index 00000000000..49d35b64ec4 --- /dev/null +++ b/hugo/content/fr/bits_ai/bits_investigation/chat_bits_investigation.md @@ -0,0 +1,34 @@ +--- +aliases: +- /fr/bits_ai/bits_ai_sre/chat_bits_ai_sre/ +title: Discussion avec Bits Investigation +--- +Dans le cadre d'une investigation, vous pouvez discuter avec Bits pour recueillir des informations supplémentaires sur l'investigation, la télémétrie associée, et plus encore. + +{{< img src="bits_ai/bits_ai_sre_chat_example.png" alt="Exemple de discussion où un utilisateur interroge Bits AI au sujet d'incidents en cours liés, et où Bits AI répond avec une liste d'incidents liés et une explication de ce qui les relie." style="width:100%;" >}} + +## Sources de données {#data-sources} + +Le chatbot Bits Investigation a accès à : +- **Détails de l'investigation** : Détails sur l'alerte du monitor, les requêtes exploratoires exécutées, les hypothèses et leurs évaluations, ainsi que la conclusion sur la cause racine +- **Télémétrie** : Détails sur les métriques, les logs, les traces, les événements, les monitors, les événements RUM, les dashboards, les notebooks et les hosts +- **Incidents** : Détails sur les incidents et leur statut, leur gravité, et plus encore +- **Services** : Détails sur les services in Catalog, leurs dépendances, leurs propriétaires, et plus encore +- **Documentation Datadog** : Informations documentées sur les produits Datadog +- **Documentation Confluence** : Documentation ou runbooks pertinents issus de votre documentation Confluence (si l'[intégration Confluence est configurée pour permettre l'exploration du compte][1]) + +## Exemples de questions {#example-questions} + +| Fonctionnalité | Exemple de prompt | Source de données | +|------------------------------------------------|-------------------------------------------------------------------|-----------------------------------| +| Demander des précisions sur les détails de l'investigation | `Why do you think there's database query slowness?` | Bits Investigation details | +| Demander des approfondissements sur les conclusions de l'investigation | `Tell me more about the increased 500s on .` | Bits Investigation details | +| Apprendre à améliorer le fonctionnement de Bits | `How can I make the investigation more effective next time?` | Bits Investigation details | +| Rechercher des informations sur un service | `Are there any ongoing incidents for ?` | Catalog and Incidents | +| Trouver les changements récents pour un service | `Were there any recent changes on ?` | Change Tracking | +| Interroger les métriques de requête, d'erreur et de durée APM | `What's the current error rate for ?` | APM | +| Interroger et analyser les données de profilage | `What performance bottlenecks do you see for ?` | Continuous Profiler | +| Se renseigner sur les produits Datadog | `Does Bits Investigation connect to Datadog Work Management?` | Documentation Datadog | +| Créer un Notebook | `Can you create a notebook with a summary of this investigation?` | Notebooks | + +[1]: bits_ai/bits_investigation/configure#confluence \ No newline at end of file diff --git a/hugo/content/fr/byoc-logs/operate/_index.md b/hugo/content/fr/byoc-logs/operate/_index.md new file mode 100644 index 00000000000..20f81e6fbca --- /dev/null +++ b/hugo/content/fr/byoc-logs/operate/_index.md @@ -0,0 +1,20 @@ +--- +aliases: +- /fr/cloudprem/operate/ +description: Apprenez à surveiller et à dépanner votre déploiement de BYOC Logs +title: Exploiter BYOC Logs +--- +## Présentation {#overview} + +Gérez votre déploiement de BYOC Logs (Bring Your Own Cloud) grâce à des guides sur le dimensionnement, la mise à l'échelle automatique, la surveillance et le dépannage. + +{{< whatsnext desc="Exploiter BYOC Logs :">}} + {{< nextlink href="/byoc-logs/operate/sizing/" >}}Guide de dimensionnement{{< /nextlink >}} + {{< nextlink href="/byoc-logs/operate/autoscaling/" >}}Mise à l'échelle automatique des indexers et des compactors{{< /nextlink >}} + {{< nextlink href="/byoc-logs/operate/monitoring/" >}}Surveiller BYOC Logs{{< /nextlink >}} + {{< nextlink href="/byoc-logs/operate/search_logs/" >}}Rechercher des logs{{< /nextlink >}} + {{< nextlink href="/byoc-logs/operate/best_practices/" >}}Meilleures pratiques de production{{< /nextlink >}} + {{< nextlink href="/byoc-logs/operate/disk_buffer_durability/" >}}Configurer la durabilité de la mémoire tampon du disque{{< /nextlink >}} + {{< nextlink href="/byoc-logs/operate/updates/" >}}Versions et mises à jour{{< /nextlink >}} + {{< nextlink href="/byoc-logs/operate/troubleshooting/" >}}Dépannage{{< /nextlink >}} +{{< /whatsnext >}} \ No newline at end of file diff --git a/hugo/content/fr/cloud_cost_management/allocation/tag_pipelines.md b/hugo/content/fr/cloud_cost_management/allocation/tag_pipelines.md new file mode 100644 index 00000000000..a972cc1d2a5 --- /dev/null +++ b/hugo/content/fr/cloud_cost_management/allocation/tag_pipelines.md @@ -0,0 +1,124 @@ +--- +aliases: +- /fr/cloud_cost_management/tag_pipelines/ +- /fr/cloud_cost_management/tags/tag_pipelines/ +further_reading: +- link: /cloud_cost_management/ + tag: Documentation + text: Découvrez Cloud Cost Management. +- link: /getting_started/tagging/ + tag: Documentation + text: Débuter avec les tags +- link: /integrations/guide/reference-tables + tag: Documentation + text: En savoir plus sur les tables de référence +- link: https://www.datadoghq.com/blog/cloud-cost-management-ai-costs/ + tag: Blog + text: Répartissez les coûts de l'IA entre les fournisseurs avec Datadog Cloud Cost + Management +- link: https://www.datadoghq.com/blog/cloud-cost-management-oci + tag: Blog + text: Gérez et optimisez vos coûts OCI avec Datadog Cloud Cost Management +title: Pipelines de tags +--- +## Présentation {#overview} + +Les tags sont la base de toute analyse et allocation dans Cloud Cost Management. Ils vous permettent de ventiler les dépenses par service, équipe, projet, environnement ou toute dimension pertinente pour votre entreprise. Les pipelines de tags imposent l'utilisation de tags standardisés sur vos ressources cloud et aident à garantir une attribution des coûts cohérente et précise dans toute votre organisation. + +Avec les [pipelines de tags][1], vous pouvez créer des règles de tag pour corriger les tags manquants ou incorrects sur vos factures cloud. Vous pouvez également créer de nouveaux tags déduits qui s'alignent sur une logique métier spécifique pour améliorer la précision de votre suivi des coûts. Ces tags standardisés alimentent toutes les capacités d'analyse des coûts, y compris l'allocation des coûts des conteneurs, les règles d'allocation personnalisées et les recommandations de coûts. + +Les pipelines de tags s'appliquent aux métriques Cloud Cost de tous les fournisseurs. Les règles que vous créez affectent toutes les données de coût et les recommandations de coût, garantissant ainsi la cohérence entre les dashboards, les monitors et les rapports d'allocation. + +Lorsque les pipelines de tags changent, les nouvelles règles sont automatiquement appliquées aux trois derniers mois de données. La mise à jour des données historiques peut prendre jusqu'à 24 heures après l'ajout ou la modification de règles. + +Tous les nouveaux utilisateurs ont la règle recommandée pour [activer la normalisation des tags][6] activée par défaut. + +## Créer un ensemble de règles {#create-a-ruleset} + +Vous pouvez gérer les ensembles de règles de pipeline de tags via l'[API][7], [Terraform][8], ou directement dans Datadog en suivant les instructions ci-dessous. + +Pour créer un ensemble de règles, accédez à [{{< ui >}}Cloud Cost{{< /ui >}} > {{< ui >}}Settings{{< /ui >}} > {{< ui >}}Tag Pipelines{{< /ui >}}][1]. + +
Vous pouvez créer jusqu'à 100 règles. Les tables de référence basées sur l'API ne sont pas prises en charge.
+ +Avant de créer des règles individuelles, créez un ensemble de règles (un dossier pour vos règles) en cliquant sur {{< ui >}}+ New Ruleset{{< /ui >}}. + +Au sein de chaque ensemble de règles, cliquez sur {{< ui >}}+ Add New Rule{{< /ui >}} et sélectionnez un type de règle : {{< ui >}}Add tag{{< /ui >}}, {{< ui >}}Alias tag keys{{< /ui >}} ou {{< ui >}}Map multiple tags{{< /ui >}}. Ces règles s'exécutent dans un ordre séquentiel et déterministe, de haut en bas. + +{{< img src="cloud_cost/pipelines-create-ruleset-1.png" alt="Une liste de règles de tag sur la page Tag Pipelines affichant diverses catégories telles que l'équipe, le compte, le service, le département, l'unité commerciale, et plus encore" style="width:60%;" >}} + +Vous pouvez organiser les règles et les ensembles de règles pour vous assurer que l'ordre d'exécution correspond à votre logique métier. + +### Ajouter un tag {#add-tag} + +Ajoutez un nouveau tag (clé + valeur) en fonction de la présence de tags existants sur vos données de coûts Cloud. + +Vous pouvez par exemple créer une règle qui applique à toutes les ressources un tag, dont la valeur correspond à l'unité commerciale liée aux services dont ces ressources font partie. + +{{< img src="cloud_cost/pipelines-add-tag-2.png" alt="Ajoutez un nouveau tag d'unité commerciale aux ressources avec service:process-agent ou service:process-billing." style="width:60%;" >}} + +Sous la section {{< ui >}}Additional options{{< /ui >}}, vous disposez des options suivantes : + +- {{< ui >}}Action when tag `{tag}` exists{{< /ui >}} - Choisissez quoi faire si le tag spécifié (`business-unit` dans l'exemple ci-dessus) existe déjà : + - {{< ui >}}Don't apply the rule{{< /ui >}} - Ignorez le tag si celui-ci existe déjà, en préservant la valeur d'origine. + - {{< ui >}}Append the tag{{< /ui >}} - Ajoutez la nouvelle valeur au tag existant sans supprimer la valeur d'origine. + - {{< ui >}}Replace the tag{{< /ui >}} - Remplacez la valeur du tag existant par la nouvelle valeur.
Le remplacement des tags peut écraser les données existantes. Utilisez cette option avec précaution.
+- {{< ui >}}Apply case-insensitive matching to resource tags{{< /ui >}} - Permet aux tags définis dans le champ `To resources with tag(s)` et aux tags issus des données de coût d'être insensibles à la casse. Par exemple, si les tags de ressource de l'interface utilisateur sont : `foo:bar` et que le tag issu des données de coût est `Foo:bar`, alors les deux peuvent être mis en correspondance. + +### Alias de clés de tag {#alias-tag-keys} + +Mappez des valeurs de tags existants à un tag plus standard. + +Par exemple, si votre organisation souhaite utiliser la clé de tag standard `application`, mais que plusieurs équipes utilisent une variante de ce tag (comme `app`, `webapp` ou `apps`), vous pouvez créer un alias de `apps` vers `application`. Chaque règle de tag d'alias vous permet de créer un alias pour un maximum de 25 clés de tag vers un nouveau tag. + +{{< img src="cloud_cost/pipelines-alias-tag-4.png" alt="Ajoutez un tag d'application aux ressources avec le tag app, webapp ou apps." style="width:60%;" >}} + +Ajoutez le tag d'application aux ressources avec les tags `app`, `webapp` ou `apps`. La règle cesse de s'exécuter pour chaque ressource après la première correspondance trouvée. Par exemple, si une ressource possède déjà un tag `app`, alors la règle ne tente plus d'identifier un tag `webapp` ou `apps`. + +Sous la section {{< ui >}}Additional options{{< /ui >}}, vous disposez des options suivantes : + +- {{< ui >}}Action when tag `{tag}` exists{{< /ui >}} - Choisissez quoi faire si le tag spécifié (`application` dans l'exemple ci-dessus) existe déjà : + - {{< ui >}}Don't apply the rule{{< /ui >}} - Ignorez le tag si celui-ci existe déjà, en préservant la valeur d'origine. + - {{< ui >}}Append the tag{{< /ui >}} - Ajoutez la nouvelle valeur au tag existant sans supprimer la valeur d'origine. + - {{< ui >}}Replace the tag{{< /ui >}} - Remplacez la valeur du tag existant par la nouvelle valeur.
Le remplacement des tags peut écraser les données existantes. Utilisez cette option avec précaution.
+- {{< ui >}}Apply case-insensitive matching to resource tags{{< /ui >}} - Permet aux tags définis dans les clés de tag d'alias et aux tags issus des données de coût d'être insensibles à la casse. Par exemple, si les tags de ressource de l'interface utilisateur sont : `app:bar` et que le tag issu des données de coût est `App:bar`, alors les deux peuvent être mis en correspondance. + +### Mapper plusieurs tags {#map-multiple-tags} + +Utilisez les [Tables de référence][2] pour ajouter plusieurs tags aux données de coût sans créer plusieurs règles. Ceci mappe les valeurs de la colonne de clé primaire de votre Reference Table aux valeurs des tags de coût. Si elle est trouvée, le pipeline ajoute les colonnes de Reference Table sélectionnées en tant que tags aux données de coût. + +Par exemple, si vous souhaitez ajouter des informations sur les vice-présidents, les organisations et les business_units auxquels appartiennent différents comptes AWS et Azure, vous pouvez créer un tableau et mapper les tags. + +{{< img src="cloud_cost/pipelines-map-multiple-tags-2.png" alt="Ajoutez des métadonnées de compte comme customer_name en utilisant des tables de référence pour les pipelines de tags" style="width:60%;" >}} + +Similaire aux [clés de tag d'alias](#alias-tag-keys), la règle cesse de s'exécuter pour chaque ressource après la première correspondance trouvée. Par exemple, si un `application` est trouvé, alors la règle ne tente plus de trouver un `subscription_id`. + +Sous la section {{< ui >}}Additional options{{< /ui >}}, vous disposez des options suivantes : + +- {{< ui >}}Action when column exists{{< /ui >}} - Choisissez quoi faire si les colonnes spécifiées existent déjà : + - {{< ui >}}Don't apply the rule{{< /ui >}} - Ignore la règle si les colonnes existent déjà, en préservant les valeurs d'origine. + - {{< ui >}}Append the column{{< /ui >}} - Ajoute les nouvelles valeurs aux colonnes existantes sans supprimer les valeurs d'origine. + - {{< ui >}}Replace the column{{< /ui >}} - Remplace les valeurs de colonne existantes par les nouvelles valeurs.
Le remplacement de colonnes peut écraser les données existantes. Utilisez cette option avec précaution.
+- {{< ui >}}Apply case-insensitive matching for primary key values{{< /ui >}} - Active la correspondance insensible à la casse entre la valeur de la clé primaire de la Reference Table et la valeur du tag dans les données de coût lorsque la clé de tag correspond à la clé primaire. Par exemple, si la paire de valeurs de clé primaire de l'interface utilisateur est `foo:Bar` et que le tag des données de coût est `foo:bar`, alors les deux peuvent être mis en correspondance. + +## Tags réservés {#reserved-tags} + +Certains tags tels que `env` et `host` sont des [tags réservés][4] et font partie du [Unified Service Tagging][3]. Le tag `host` ne peut pas être ajouté dans les pipelines de tags. + +L'utilisation de tags aide à corréler vos métriques, traces, processus et logs. Les tags réservés comme `host` offrent une visibilité et une surveillance efficace sur l'ensemble de votre infrastructure. Pour une corrélation optimale et des informations exploitables, utilisez ces tags réservés dans le cadre de votre stratégie de balisage dans Datadog. + +## Supprimer des tags {#delete-tags} +Pour supprimer un tag créé à l'aide des pipelines de tags, supprimez la règle qui l'a créé. Dans les 24 heures, le tag est automatiquement supprimé des données des trois derniers mois. Pour supprimer le tag des anciennes données, contactez le [support Datadog][5]. + +## Pour aller plus loin {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://app.datadoghq.com/cost/tag-pipelines +[2]: /fr/integrations/guide/reference-tables/?tab=manualupload +[3]: /fr/getting_started/tagging/unified_service_tagging/ +[4]: /fr/getting_started/tagging/ +[5]: /fr/help/ +[6]: /fr/cloud_cost_management/tags#how-tags-are-normalized +[7]: /fr/api/latest/cloud-cost-management/#create-tag-pipeline-ruleset +[8]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/tag_pipeline_ruleset \ No newline at end of file diff --git a/hugo/content/fr/cloud_cost_management/setup/azure.md b/hugo/content/fr/cloud_cost_management/setup/azure.md index 29e25946c56..cc015d007e8 100644 --- a/hugo/content/fr/cloud_cost_management/setup/azure.md +++ b/hugo/content/fr/cloud_cost_management/setup/azure.md @@ -7,251 +7,348 @@ further_reading: text: Cloud Cost Management - link: /cloud_cost_management/setup/aws tag: Documentation - text: Mieux comprendre votre facture AWS + text: Obtenez des informations sur votre facture AWS - link: /cloud_cost_management/setup/google_cloud tag: Documentation - text: Mieux comprendre votre facture Google Cloud + text: Obtenez des informations sur votre facture Google Cloud - link: /cloud_cost_management/oracle tag: Documentation - text: Mieux comprendre votre facture Oracle + text: Obtenez des informations sur votre facture Oracle title: Azure --- +## Présentation {#overview} +Pour utiliser Azure Cloud Cost Management dans Datadog, vous devez configurer l'intégration Datadog Azure et créer des exports **amortized** et **actual** dans Azure. De plus, Datadog doit disposer des autorisations nécessaires pour lire les exports depuis le conteneur. -## Présentation +Datadog offre une visibilité sur les coûts au niveau de l'abonnement, du groupe de ressources et du compte de facturation. Les contrats client Microsoft (MCA) peuvent être configurés aux trois niveaux. Pour déterminer votre type de compte, consultez la [documentation Azure][10]. -Pour utiliser la solution Cloud Cost Management pour Azure dans Datadog, vous devez configurer l'intégration Datadog/Azure et créer des exportations des coûts **amortis** et **réels** dans Azure. En outre, Datadog doit disposer des autorisations nécessaires pour lire les exportations à partir du conteneur. +
+Comptes Pay as you go (PAYG) +

Datadog Cloud Cost Management nécessite des exports Actual Cost et Amortized Cost depuis Azure. Les abonnements PAYG (Microsoft Online Services Program) ne fournissent généralement que des exports Usage details (usage only), ils ne peuvent donc pas être configurés pour CCM. Pour connaître les types d'export disponibles pour chaque type de compte Azure, consultez la documentation sur les exports Cost Management de Microsoft.

+

Si votre abonnement est de type PAYG, envisagez l'une des options suivantes :

+
    +
  • Migrez vers un Microsoft Customer Agreement (MCA) ou un Enterprise Agreement (EA), qui prennent en charge les types d'export requis.
    • +
  • Contactez le support Microsoft Azure pour confirmer les types d'export disponibles pour votre abonnement.
    • +
+

Pour obtenir de l'aide sur la configuration de Datadog CCM ou pour discuter des options, contactez le support Datadog.

+
-Datadog vous permet de visualiser vos coûts au niveau des abonnements, des groupes de ressources et des comptes de facturation. Les contrats client Microsoft peuvent être configurés pour ces trois portées. Les comptes avec paiement au fur et à mesure sont disponibles en préversion. Contactez l'[assistance Datadog][11] si vous rencontrez le moindre problème lors de la configuration. - -Pour déterminer votre type de compte, consultez la [documentation Azure][10]. **Remarque :** si la mention « Microsoft Online Services Program » est indiquée pour votre type de compte, il s'agit d'un compte avec paiement au fur et à mesure. - -## Configuration +## Configuration {#setup} +Vous pouvez effectuer la configuration en utilisant l'[API][13], [Terraform][14], ou directement dans Datadog en suivant les instructions ci-dessous. {{% site-region region="us3" %}} -**Remarque** : si vous utilisez le site **US3** de Datadog, vous avez peut-être configuré l'intégration Datadog/Azure native à l'aide de la [méthode basée sur la ressource Datadog][1] via le portail Azure. Pour prendre en charge Cloud Cost Management, vous devez [créer un enregistrement d'application][2]. +**Remarque** : Si vous utilisez le site **US3** de Datadog, vous avez peut-être configuré l'intégration native Azure de Datadog en utilisant la [méthode de ressource Datadog][1] via le portail Azure. Pour prendre en charge Cloud Cost Management, vous devez [créer une app registration][2]. [1]: https://www.datadoghq.com/blog/azure-datadog-partnership/ [2]: /fr/integrations/azure/?tab=azurecliv20#setup -{{< /site-region >}} +{{% /site-region %}} -### Configurer l'intégration Azure -Accédez à [Setup & Configuration][3] et sélectionnez un compte Azure depuis le menu pour récupérer les coûts associés. Si votre compte Azure n'apparaît pas dans la liste, accédez à votre [Intégration Azure][4] pour ajouter le compte. +### Configurez l'intégration Azure {#configure-the-azure-integration} +Accédez à [Setup & Configuration][3], ajoutez un compte Azure et suivez les étapes pour configurer l'intégration Azure. -### Générer des exportations de coûts +{{< tabs >}} -Vous devez générer des exportations pour deux types de données : les coûts **réels** et les coûts **amortis**. Datadog recommande d'utiliser le même conteneur de stockage pour les deux exportations. +{{% tab "Terraform" %}} -1. Sur le portail Azure, sous **Tools** > **Cost Management** > **Settings** > **Configuration**, accédez à [Cost Management | Configuration][5], puis cliquez sur **Exports**. - {{< img src="cloud_cost/azure_export_path.png" alt="Le portail Azure, avec l'option Exports mise en évidence dans la navigation" style="width:100%" >}} -2. Sélectionnez la portée de l'exportation en regard du filtre de recherche. +{{< img src="cloud_cost/setup/azure_terraform_setup.png" alt="Page de configuration CCM avec l'option Terraform sélectionnée, montrant l'étape 1 et l'étape 2 développées pour configurer le périmètre et les détails d'exportation" style="width:100%" >}} - **Remarque :** la portée doit être définie sur un **compte de facturation**, un **abonnement** ou un **groupe de ressources**. -3. Une fois la portée sélectionnée, cliquez sur **Schedule export**. +### Sélectionnez le type de périmètre {#select-scope-type} - {{< img src="cloud_cost/azure_exports_page.png" alt="Le portail Azure, avec la portée d'exportation et le bouton Schedule export mis en évidence" style="width:100%" >}} +Utilisez la liste déroulante pour sélectionner le type de périmètre pour votre compte. CCM prend en charge les types de périmètre compte de facturation, abonnement et groupe de ressources. -4. Sélectionnez le modèle **Cost and usage (actual + amortized)**. - {{< img src="cloud_cost/azure_new_export.png" alt="Nouvelle page d'exportation avec le modèle et les options manuelles mis en évidence" style="width:100%" >}} +### Sélectionnez les ressources à créer {#select-the-resources-to-create} -5. Cliquez sur **Edit** pour chaque exportation et confirmez les détails suivants : - - Frequency : **Daily export of month-to-date costs** - - Dataset version : - - Versions prises en charge : `2021-10-01`, `2021-01-01`, `2020-01-01` - - Versions non prises en charge : `2019-10-01` - {{< img src="cloud_cost/improved_export.png" alt="Détails de l'exportation avec la métrique définie sur Actual, le type d'exportation défini sur Daily et la version de l'ensemble de données" style="width:100%" >}} +La configuration Terraform prend en charge trois configurations en fonction de vos ressources Azure existantes : -6. Saisissez un préfixe d'exportation pour les nouvelles exportations, comme `datadog`, pour éviter les conflits avec les exportations existantes. +* **Nouvelle configuration** : Sélectionnez {{< ui >}}Create storage account and container{{< /ui >}} pour créer un compte de stockage, un conteneur et des exportations de coûts. +* **Compte de stockage et conteneur existants** : Désélectionnez {{< ui >}}Create storage account and container{{< /ui >}} et sélectionnez {{< ui >}}Create cost exports{{< /ui >}} pour utiliser le stockage existant mais créer de nouvelles exportations de coûts. +* **Compte de stockage, conteneur et exportations de coûts existants** : Désélectionnez les deux options pour utiliser le stockage et les exportations de coûts existants. -7. Dans l'onglet **Destination**, procédez comme suit : - - Sélectionnez le type de stockage **Azure blob storage**. - - Choisissez un compte de stockage, un conteneur et un répertoire pour les exportations. - - **Remarque :** n'utilisez pas de caractères spéciaux, comme `.`, dans ces champs. - - **Remarque :** les exportations de facturation peuvent être stockées dans n'importe quel abonnement. Si vous créez des exportations pour plusieurs abonnements, Datadog recommande de les stocker dans le même compte de stockage. Les noms des exportations doivent être uniques. - - Choisissez le format **CSV** ou **Parquet**. - - Choisissez le type de compression. Pour **CSV**, les options **Gzip** et **None** sont prises en charge. Pour **Parquet**, les options **Snappy** et **None** sont prises en charge. - - Vérifiez que la case **File partitioning** est cochée. - - Vérifiez que la case **Overwrite data** n'est pas cochée. - - **Remarque :** Datadog ne prend pas en charge le paramètre Overwrite Data. S'il a été précédemment coché, assurez-vous de nettoyer les fichiers dans le répertoire ou de les déplacer vers un autre répertoire. +### Configurer le périmètre et les détails de l'exportation {#configure-the-scope-and-export-details} - {{< img src="cloud_cost/improved_export_destination_2.png" alt="Destination des exportations, avec les paramètres File partitioning et Overwrite data" >}} +Saisissez les détails suivants pour votre configuration : -8. Dans l'onglet **Review + create**, sélectionnez **Create**. -9. Pour accélérer le traitement, générez les premières exportations manuellement en cliquant sur **Run Now**. +* {{< ui >}}Billing account or Subscription ID{{< /ui >}} : Selon le périmètre sélectionné à l'étape 1, l'ID de compte de facturation ou l'ID d'abonnement correspondant. +* {{< ui >}}Resource group name{{< /ui >}} : Le nom de votre groupe de ressources existant dans le périmètre sélectionné. Un groupe de ressources préexistant est requis pour la configuration Terraform. +* {{< ui >}}Location{{< /ui >}} : L'emplacement Azure de votre groupe de ressources. Par exemple, `East US 2`. +* {{< ui >}}Storage account and container name{{< /ui >}} : Selon les ressources que vous avez choisi de créer, les noms de votre compte de stockage et de votre conteneur, nouveaux ou préexistants. +* {{< ui >}}Actual cost export name and path{{< /ui >}} : Le nom et le chemin d'accès de votre exportation de coûts réelle. +* {{< ui >}}Amortized cost export name and path{{< /ui >}} : Le nom et le chemin d'accès de votre exportation de coûts amortis. + * **Remarque :** Les formats de préfixe suivants ne sont pas pris en charge : vide, commençant par `/` (tel que `/` ou `/cost`), ou se terminant par `/` (tel que `cost/`). Les préfixes contenant `/` au milieu sont pris en charge (tel que `cost/hourly`). -{{< img src="cloud_cost/run_now.png" alt="Cliquez sur Run Now button dans le volet latéral des exportations pour générer des exportations" style="width:50%" >}} +### Copiez le HCL de ressource Azure Terraform généré et appliquez les modifications {#copy-generated-azure-resource-terraform-hcl-and-apply-changes} -### Fournir à Datadog un accès à vos exportations +Une fois les champs de l'étape 2 remplis, l'étape 3 s'active et affiche le HCL Terraform généré. Suivez les instructions pour configurer vos fichiers de configuration Terraform avec ce code. Résolvez tous les problèmes qui apparaissent lors de l'exécution de `terraform plan` ou `terraform apply` avant de revenir à CCM pour configurer les exportations de coûts. -{{< tabs >}} -{{% tab "Comptes de facturation" %}} +### Accédez à la console Azure pour configurer les exportations {#access-azure-console-to-configure-exports} + +{{< img src="cloud_cost/setup/azure_toggle_file_partitioning.png" alt="Activez le partitionnement de fichiers pour les deux exportations" style="width:50%" >}} + +Ouvrez le lien de la console Azure pour localiser vos exportations de coûts. Si nécessaire, remplacez le périmètre actuel par celui qui convient à vos exportations. Pour les exportations réelles et amorties, sélectionnez-les et cliquez sur {{< ui >}}Edit{{< /ui >}} pour activer le partitionnement de fichiers s'il ne l'est pas déjà. + +{{< img src="cloud_cost/run_now.png" alt="Cliquez sur le bouton \"Exécuter maintenant\" dans le panneau latéral d'export pour générer des exports." style="width:50%" >}} + +Enregistrez les modifications de partitionnement de fichiers et cliquez sur {{< ui >}}Run Now{{< /ui >}}. Revenez à CCM une fois que les deux exécutions d'exportation ont réussi. + +### Copiez le HCL Datadog généré et appliquez les modifications {#copy-generated-datadog-hcl-and-apply-changes} + +Suivez les instructions de l'étape {{< ui >}}Apply Datadog Terraform HCL{{< /ui >}}. Résolvez tous les problèmes qui apparaissent lors de l'exécution de `terraform plan` ou `terraform apply` avant de revenir à CCM pour confirmer la création du compte. -1. Dans l'onglet Exports, cliquez sur le compte de stockage de l'exportation pour y accéder. -2. Cliquez sur l'onglet Containers. -3. Choisissez le conteneur de stockage dans lequel se trouvent vos factures. -4. Sélectionnez l'onglet Access Control (IAM), puis cliquez sur **Add**. -5. Sélectionnez **Add role assignment**. -6. Sélectionnez **Storage Blob Data Reader**, puis cliquez sur Next. -7. Accordez ces autorisations à l'une des inscriptions d'application associées à Datadog. - - Cliquez sur **Select members**, choisissez le nom de l'inscription d'application, puis cliquez sur **Select**. **Remarque** : si votre enregistrement d'application ne figure pas dans la liste, commencez à saisir son nom pour que l'interface se mette à jour et l'affiche, s'il est disponible. - - Sélectionnez **Review + assign**. - -Si vos exportations se trouvent dans des conteneurs de stockage différents, répétez les étapes 1 à 7 pour l'autre conteneur de stockage. {{% /tab %}} -{{% tab "Abonnements et groupes de ressources" %}} +{{% tab "Méthode manuelle" %}} + +{{< img src="cloud_cost/setup/azure_manual_setup.png" alt="Page de configuration CCM avec l'option Manuel sélectionnée, montrant l'étape 1 et l'étape 2 développées pour configurer le type de périmètre et sélectionner les exportations existantes" style="width:100%" >}} + +### Générer des exportations de coûts {#generate-cost-exports} + +Vous devez générer des exportations pour deux types de données : **Actual Cost** et **Amortized Cost**. Datadog recommande d'utiliser le même conteneur de stockage pour les deux exportations. + +1. Accédez à [Gestion des coûts | Configuration][5] sous {{< ui >}}Tools{{< /ui >}} > {{< ui >}}Cost Management{{< /ui >}} > {{< ui >}}Settings{{< /ui >}} > {{< ui >}}Configuration{{< /ui >}} du portail Azure et cliquez sur {{< ui >}}Exports{{< /ui >}}. + {{< img src="cloud_cost/azure_export_path.png" alt="Dans le portail Azure, mise en évidence de l'option Exportations dans la navigation" style="width:100%" >}} +2. Sélectionnez le périmètre d'exportation situé à côté du filtre de recherche. + + **Remarque :** Le périmètre doit être {{< ui >}}billing account{{< /ui >}}, {{< ui >}}subscription{{< /ui >}} ou {{< ui >}}resource group{{< /ui >}}. +3. Une fois le périmètre sélectionné, cliquez sur {{< ui >}}Schedule export{{< /ui >}}. + + {{< img src="cloud_cost/azure_exports_page.png" alt="Dans le portail Azure, mise en évidence du périmètre d'exportation et du bouton de planning" style="width:100%" >}} + +4. Sélectionnez le modèle {{< ui >}}Cost and usage (actual + amortized){{< /ui >}} + {{< img src="cloud_cost/azure_new_export.png" alt="Nouvelle page d'exportation avec les options de modèle et manuelles mises en évidence" style="width:100%" >}} + +5. Cliquez sur {{< ui >}}Edit{{< /ui >}} sur chaque exportation et confirmez les détails suivants : + - Fréquence : {{< ui >}}Daily export of month-to-date costs{{< /ui >}} + - Version du jeu de données : + - Versions prises en charge : `2021-10-01`, `2021-01-01`, `2020-01-01` + - Versions non prises en charge : `2019-10-01` + {{< img src="cloud_cost/improved_export.png" alt="Détails de l'exportation avec Métrique : Actual, Type d'exportation : Daily, et Version du jeu de données" style="width:100%" >}} + +6. Saisissez un « préfixe d'exportation » pour les nouvelles exportations. Par exemple, saisissez `datadog` pour éviter les conflits avec les exportations existantes. -1. Dans l'onglet Exports, cliquez sur le compte de stockage de l'exportation pour y accéder. +7. Dans l'onglet {{< ui >}}Destination{{< /ui >}}, sélectionnez les détails suivants : + - Choisissez {{< ui >}}Azure blob storage{{< /ui >}} comme type de stockage. + - Choisissez un compte de stockage, un conteneur et un répertoire pour les exportations. + - **Remarque :** N'utilisez pas de caractères spéciaux comme `.` dans ces champs. + - **Remarque :** Les exportations de facturation peuvent être stockées dans n'importe quel abonnement. Si vous créez des exportations pour plusieurs abonnements, Datadog recommande de les stocker dans le même compte de stockage. Les noms d'exportation doivent être uniques. + - Choisissez {{< ui >}}CSV{{< /ui >}} ou {{< ui >}}Parquet{{< /ui >}} comme format. + - Choisissez le type de compression. Pour {{< ui >}}CSV{{< /ui >}} : {{< ui >}}Gzip{{< /ui >}} et {{< ui >}}None{{< /ui >}} sont pris en charge. Pour {{< ui >}}Parquet{{< /ui >}} : {{< ui >}}Snappy{{< /ui >}} et {{< ui >}}None{{< /ui >}} sont pris en charge. + - Assurez-vous que {{< ui >}}File partitioning{{< /ui >}} est coché. + - Assurez-vous que {{< ui >}}Overwrite data{{< /ui >}} n'est pas coché. + - **Remarque :** Datadog ne prend pas en charge le paramètre {{< ui >}}Overwrite data{{< /ui >}}. Si le paramètre était précédemment coché, assurez-vous de nettoyer les fichiers dans le répertoire ou de les déplacer vers un autre. + + {{< img src="cloud_cost/improved_export_destination_2.png" alt="Destination d'exportation avec les paramètres de partitionnement de fichiers et d'écrasement des données" >}} + +8. Dans l'onglet {{< ui >}}Review + create{{< /ui >}}, sélectionnez {{< ui >}}Create{{< /ui >}}. +9. Générez manuellement les premières exportations en cliquant sur {{< ui >}}Run Now{{< /ui >}}. Attendez que l'opération se termine avec succès avant de continuer. + +{{< img src="cloud_cost/run_now.png" alt="Cliquez sur le bouton \"Exécuter maintenant\" dans le panneau latéral d'export pour générer des exports." style="width:50%" >}} + +### Donnez à Datadog accès à vos exportations {#provide-datadog-access-to-your-exports} +Accordez à Datadog un accès en lecture au compte de stockage où vos exportations sont enregistrées. + +{{% collapse-content title="Comptes de facturation" level="h4" %}} + +1. Dans l'onglet Exportations, cliquez sur le compte de stockage de l'exportation pour y accéder. +2. Cliquez sur l'onglet Containers. +3. Choisissez le conteneur de stockage dans lequel se trouvent vos factures. +4. Sélectionnez l'onglet {{< ui >}}Access Control (IAM){{< /ui >}}, puis cliquez sur {{< ui >}}Add{{< /ui >}}. +5. Choisissez {{< ui >}}Add role assignment{{< /ui >}}. +6. Choisissez {{< ui >}}Storage Blob Data Reader{{< /ui >}}, puis cliquez sur {{< ui >}}Next{{< /ui >}}. +7. Attribuez ces autorisations à l'une des App Registrations que vous avez connectées à Datadog. + - Cliquez sur {{< ui >}}Select members{{< /ui >}}, choisissez le nom de l'App Registration, puis cliquez sur {{< ui >}}Select{{< /ui >}}. **Remarque** : Si vous ne voyez pas votre App Registration dans la liste, commencez à saisir son nom pour que l'interface utilisateur se mette à jour et l'affiche, si elle est disponible. + - Sélectionnez {{< ui >}}Review + assign{{< /ui >}}. + +Si vos exportations se trouvent dans des conteneurs de stockage différents, répétez les étapes un à sept pour l'autre conteneur de stockage. + +{{% /collapse-content %}} +{{% collapse-content title="Abonnements et groupes de ressources" level="h4" %}} +1. Dans l'onglet Exportations, cliquez sur le compte de stockage de l'exportation pour y accéder. 2. Cliquez sur l'onglet Containers. 3. Choisissez le conteneur de stockage dans lequel se trouvent vos factures. -4. Sélectionnez l'onglet Access Control (IAM), puis cliquez sur **Add**. -5. Sélectionnez **Add role assignment**. -6. Sélectionnez **Storage Blob Data Reader**, puis cliquez sur Next. -7. Accordez ces autorisations à l'une des inscriptions d'application associées à Datadog. - - Cliquez sur **Select members**, choisissez le nom de l'inscription d'application, puis cliquez sur **Select**. - - Sélectionnez **Review + assign**. +4. Sélectionnez l'onglet {{< ui >}}Access Control (IAM){{< /ui >}}, puis cliquez sur {{< ui >}}Add{{< /ui >}}. +5. Choisissez {{< ui >}}Add role assignment{{< /ui >}}. +6. Choisissez {{< ui >}}Storage Blob Data Reader{{< /ui >}}, puis cliquez sur {{< ui >}}Next{{< /ui >}}. +7. Attribuez ces autorisations à l'une des App Registrations que vous avez connectées à Datadog. + - Cliquez sur {{< ui >}}Select members{{< /ui >}}, choisissez le nom de l'App Registration, puis cliquez sur {{< ui >}}Select{{< /ui >}}. + - Sélectionnez {{< ui >}}Review + assign{{< /ui >}}. -Si vos exportations se trouvent dans des conteneurs de stockage différents, répétez les étapes 1 à 7 pour l'autre conteneur de stockage. +Si vos exportations se trouvent dans des conteneurs de stockage différents, répétez les étapes un à sept pour l'autre conteneur de stockage. +{{% /collapse-content %}} -### Configurer l'accès en lecture de Cost Management -**Remarque :** vous n'avez pas besoin de configurer cet accès si votre portée est définie sur un **compte de facturation**. +### Configurez l'accès Cost Management Reader {#configure-cost-management-reader-access} +**Remarque** : Vous n'avez pas besoin de configurer cet accès si votre périmètre est {{< ui >}}Billing Account{{< /ui >}}. -1. Accédez à vos [abonnements][1], puis cliquez sur le nom de votre abonnement. -2. Sélectionnez l'onglet Access Control (IAM). -3. Cliquez sur **Add**, puis sur **Add role assignment**. -4. Sélectionnez **Cost Management Reader**, puis cliquez sur Next. -5. Attribuez ces permissions à l'enregistrement d'application. +1. Accédez à vos [abonnements][1] et cliquez sur le nom de votre abonnement. +2. Sélectionnez l'onglet {{< ui >}}Access Control (IAM){{< /ui >}}. +3. Cliquez sur {{< ui >}}Add{{< /ui >}}, puis sur {{< ui >}}Add role assignment{{< /ui >}}. +4. Choisissez {{< ui >}}Cost Management Reader{{< /ui >}}, puis cliquez sur {{< ui >}}Next{{< /ui >}}. +5. Attribuez ces autorisations à l'App Registration. -En procédant de la sorte, vous pouvez calculer les coûts périodiques et les comparer à ceux de Microsoft Cost Management, afin de garantir la précision des coûts. +Cela permet de garantir une précision totale des coûts en autorisant des calculs de coûts périodiques par rapport à Microsoft Cost Management. -**Remarque :** une fois la configuration effectuée, les données peuvent mettre 48 à 72 heures à se stabiliser dans Datadog. +**Remarque** : Les données peuvent mettre jusqu'à 48 à 72 heures après la configuration pour se stabiliser dans Datadog. [1]: https://portal.azure.com/#view/Microsoft_Azure_Billing/SubscriptionsBlade {{% /tab %}} {{< /tabs >}} -**Remarque** : si vous avez accordé les autorisations nécessaires à l'enregistrement d'application, mais que votre réseau bloque les adresses IP des webhooks de Datadog, il se peut que cela génère des erreurs qui semblent provenir des autorisations. -Pour résoudre ce problème, ajoutez les adresses IP des webhooks de Datadog à la liste d'autorisation de votre réseau, en accédez à la section `Webhooks` à l'adresse `https://ip-ranges.`{{< region-param key="dd_site" code="true" >}}. -### Configurer Cloud Cost dans Datadog -Accédez à [Setup & Configuration][3] et suivez les étapes indiquées. +**Remarque** : Si vous disposez des autorisations appropriées sur l'enregistrement de l'application mais que votre réseau bloque les adresses IP du webhook de Datadog, vous pourriez rencontrer des erreurs qui semblent liées aux autorisations. + +Pour résoudre ce problème, ajoutez les adresses IP du webhook de Datadog à votre liste d'autorisation réseau en visitant la section `Webhooks` sur `https://ip-ranges.`{{< region-param key="dd_site" code="true" >}}. + +### Configurer Cloud Cost dans Datadog {#configure-cloud-cost-in-datadog} +Accédez à [Setup & Configuration][3] et suivez les étapes. + +### Migrer les exportations d'un EA vers un MCA {#migrate-exports-from-an-ea-to-an-mca} + +Azure ne migre pas automatiquement les définitions d'exportation de coûts d'un Enterprise Agreement (EA) vers un Microsoft Customer Agreement (MCA). Pour plus d'informations, consultez la [documentation d'intégration MCA][15] de Microsoft. + +Le processus suivant préserve les données historiques EA pour les configurations Datadog qui utilisent un périmètre de compte de facturation, d'abonnement ou de groupe de ressources. + +1. Notez les paramètres suivants pour les exportations EA réelles et amorties : + * Nom de l'exportation, y compris les majuscules + * Compte de stockage + * Conteneur de stockage + * Répertoire de stockage et préfixe d'exportation + * Version du jeu de données, format et type de compression +1. Une fois les dernières exportations de la période EA terminées, désactivez les exportations EA planifiées, mais conservez leurs définitions. Ne permettez pas aux exportations planifiées EA et MCA d'écrire vers la même destination en même temps. +1. Laissez la configuration Azure Cloud Cost Management dans Datadog activée et inchangée. Pour un périmètre de compte de facturation, Datadog conserve l'ID EA. +1. Une fois le MCA activé, recréez les exportations réelles et amorties au périmètre MCA correspondant en utilisant Terraform ou le portail Azure. Utilisez les noms d'exportation, le compte de stockage, le conteneur, le répertoire et le préfixe enregistrés à partir des exportations EA. + * Pour Terraform, suivez le [flux de configuration Terraform][19] à travers les étapes HCL des ressources Azure. N'appliquez pas de nouveau HCL Datadog et ne remplacez pas la configuration existante Azure Cloud Cost Management. + * Pour le portail Azure, suivez les [instructions d'exportation manuelle des coûts][17]. + +Datadog continue de lire les fichiers EA historiques à partir de la destination existante et ajoute les données MCA au même historique des coûts. + +
+Ne complétez pas les dates EA à partir d'un périmètre MCA +

Une exportation MCA n'inclut pas les coûts de l'EA précédent. L'exécution d'une exportation MCA ponctuelle pour une plage de dates EA peut écrire un manifeste vide plus récent vers la destination partagée. Datadog lit la dernière exportation pour chaque mois, de sorte que le manifeste vide peut mettre à zéro les données EA précédemment ingérées.

+
+ +Pour compléter les données après une migration EA vers MCA, utilisez l'accord qui couvrait les dates demandées : + +* Pour les dates antérieures à la date d'entrée en vigueur du MCA, exécutez les exportations ponctuelles réelles et amorties à partir du périmètre EA précédent. +* Pour les dates à compter de la date d'entrée en vigueur du MCA, exécutez les exportations ponctuelles réelles et amorties à partir du périmètre MCA. + +Si le périmètre EA précédent n'est pas disponible, contactez le support Microsoft pour demander les exportations historiques. Si vous avez modifié un nom ou une destination d'exportation, ou supprimé et recréé la configuration Datadog, contactez le [support Datadog][16]. Ne créez pas d'exportations ponctuelles ou planifiées supplémentaires tant que le support Datadog n'a pas examiné la configuration. + +### Obtention des données historiques {#getting-historical-data} -### Obtenir des données historiques -Datadog intègre automatiquement jusqu'à 15 mois de données de coûts historiques disponibles. +Les exportations Azure des données de coût commencent à partir du mois où vous avez créé l'exportation. Datadog ingère automatiquement jusqu'à 15 mois de données de coût historiques disponibles à partir de ces exportations. Vous pouvez compléter manuellement jusqu'à 12 mois de données de coût Azure en utilisant l'interface utilisateur des exportations de coûts Azure. -Azure exporte les données de coûts à partir du mois de création de l'exportation. Vous pouvez effectuer un backfill manuel en ajoutant jusqu'à 12 mois de données de coûts Azure à l'aide de l'interface des exportations de coûts Azure. +**Remarque** : Si vous avez migré d'un EA vers un MCA, suivez les [instructions de migration][18] avant d'exécuter une exportation historique. -1. Suivez les instructions des sections **Configuration** et **Configurer Cloud Cost dans Datadog** ci-dessus. -1. Avant de commencer le processus de backfill, attendez 24 heures le temps que les données de coûts apparaissent dans Datadog, afin de vous assurer que l'intégration fonctionne de bout en bout. **Remarque :** si vous avez déjà terminé la configuration et que les données de coûts apparaissent dans Datadog, vous pouvez passer directement aux étapes de backfill ci-dessous. -1. Exportez manuellement un rapport sur les coûts **réels** et **amortis** pour chaque mois civil. Par exemple, pour juin 2025 : - 1. Modifiez l'exportation. - 2. Définissez le type d'exportation sur One-time export. - 3. Définissez la date de départ sur 06-01-2025. **Remarque :** il doit s'agir du premier jour du mois. - 4. Définissez la date de fin sur 06-30-2025 **Remarque :** il doit s'agir du dernier jour du mois. - 5. Enregistrez l'exportation. **Remarque :** cette opération lance automatiquement l'exportation. - 6. Patientez le temps que l'exportation se termine. -1. Rétablissez l'état d'origine des exportations des coûts **réels** et **amortis** pour reprendre les exportations quotidiennes : - 1. Modifiez l'exportation. - 2. Définissez le type d'exportation sur Daily export of month-to-date costs. - 3. Enregistrez l'exportation. +1. Complétez les instructions dans les sections **Setup** et **Configure Cloud Cost in Datadog** ci-dessus. +1. Attendez jusqu'à 24 heures que les données de coût apparaissent dans Datadog pour vous assurer que l'intégration fonctionne de bout en bout avant de commencer le processus de remplissage. **Remarque :** Si vous avez déjà terminé la configuration et que les données de coût apparaissent dans Datadog, vous pouvez passer directement aux étapes de remplissage ci-dessous. +1. Exportez manuellement un rapport **réel** et **amorti** pour chaque mois civil. Par exemple, pour juin 2025 : + 1. Modifiez l'exportation + 2. Modifiez le type d'exportation en {{< ui >}}One-time export{{< /ui >}} + 3. Définissez {{< ui >}}From{{< /ui >}} sur 06-01-2025 **Remarque :** Il doit s'agir du premier jour du mois. + 4. Définissez {{< ui >}}End{{< /ui >}} sur 06-30-2025 **Remarque :** Il doit s'agir du dernier jour du mois. + 5. Enregistrez l'exportation **Remarque :** Cela exécute automatiquement l'exportation. + 6. Attendez que l'exportation se termine +1. Rétablissez les exportations **réelles** et **amorties** dans leur état d'origine pour reprendre les exportations quotidiennes : + 1. Modifiez l'exportation + 2. Modifiez le type d'exportation en {{< ui >}}Daily export of month-to-date costs{{< /ui >}} + 3. Enregistrez l'exportation -Datadog découvre et ingère automatiquement ces données. En temps normal, elles apparaissent dans Datadog dans un délai de 24 heures. +Datadog découvre et ingère automatiquement ces données, qui devraient apparaître dans Datadog sous 24 heures. -Vous pouvez également créer des données historiques dans votre compte de stockage à l'aide de l'[API Microsoft][6] ou en créant un [ticket d'assistance auprès de Microsoft][7]. Assurez-vous que la structure de fichier et le partitionnement respectent le format des exportations planifiées. +Vous pouvez également créer des données historiques dans votre compte de stockage en utilisant l'[API Microsoft][6] ou en créant un [ticket de support auprès de Microsoft][7]. Assurez-vous que la structure de fichiers et le partitionnement suivent le format des exportations planifiées. -### Types de coûts +### Types de coûts {#cost-types} Vous pouvez visualiser vos données ingérées en utilisant les types de coûts suivants : -| Type de coût | Rôle | +| Type de coût | Description | | -------------------- | --------------------- | -| `azure.cost.amortized` | Coût basé sur les taux de remise appliqués, plus la répartition des prépaiements en fonction de l'utilisation pour la durée de la remise (comptabilité d'exercice).| -| `azure.cost.actual` | Coût indiqué comme le montant facturé au moment de l'utilisation (comptabilité de caisse). Les coûts réels incluent les remises privées, ainsi que les remises des instances réservées et des programmes de remise, en les indiquant comme des types de dépenses distincts.| -| `azure.cost.discounted.ondemand` | Coût basé sur le tarif fourni par Azure, après les remises négociées en privé. Pour obtenir le véritable coût à la demande, divisez cette mesure par (1 - ). Par exemple, si vous bénéficiez d'une remise forfaitaire de 5 % sur tous les produits Azure, vous obtiendrez le véritable tarif à la demande en divisant cette mesure par 0,95 (1 - 0,05).| +| `azure.cost.amortized` | Coût basé sur les taux de remise appliqués plus la répartition des prépaiements sur l'utilisation pour la durée de la remise (base de comptabilité d'exercice).| +| `azure.cost.actual` | Coût affiché comme le montant facturé au moment de l'utilisation (base de comptabilité de caisse). Les coûts réels incluent les remises privées ainsi que les remises des instances réservées et des plans d'épargne en tant que types de charge distincts.| +| `azure.cost.discounted.ondemand` | Coût basé sur le tarif catalogue fourni par Azure, après remises négociées en privé. Pour obtenir le coût réel à la demande, divisez cette métrique par (1 - ). Par exemple, si vous bénéficiez d'une remise forfaitaire de 5 % sur tous les produits Azure, divisez cette métrique par 0,95 (1 - 0,05) pour obtenir le prix réel à la demande.| -### Tags par défaut +### Tags prêts à l'emploi {#out-of-the-box-tags} -Datadog enrichit automatiquement vos données de coûts Azure en y ajoutant des tags provenant de plusieurs sources. Pour découvrir en détail comment les tags sont appliqués aux données de coûts, consultez la section [Tags][12]. +Datadog enrichit automatiquement vos données de coût Azure avec des tags provenant de sources multiples. Pour un aperçu complet de la façon dont les tags sont appliqués aux données de coût, consultez [Tags][12]. -Les tags par défaut suivants proviennent de votre [rapport sur les coûts et l'utilisation][9] et facilitent la découverte et la compréhension des données de coûts : +Les tags prêts à l'emploi suivants sont dérivés de votre [rapport de coût d'utilisation][9] et facilitent la découverte et la compréhension des données de coût : -| Nom du tag | Description de tag | +| Nom du tag | Description du tag | | ---------------------------- | ----------------- | -| `accountname` | Le nom du compte associé au poste. | -| `accountownerid` | L'ID du propriétaire associé au poste. | -| `billingaccountid` | L'ID du compte de facturation associé au poste. | -| `billingaccountname` | Le nom du compte de facturation associé au poste. | +| `accountname` | Le nom du compte associé au poste de ligne. | +| `accountownerid` | L'identifiant du propriétaire associé au poste de ligne. | +| `billingaccountid` | L'identifiant du compte de facturation associé au poste de ligne. | +| `billingaccountname` | Le nom du compte de facturation associé au poste de ligne. | | `billingcurrency` | La devise associée au compte de facturation. | -| `billingperiod` | La période de facturation de la dépense. | +| `billingperiod` | La période de facturation de la charge. | | `billingperiodenddate` | La date de fin de la période de facturation. | | `billingperiodstartdate` | La date de début de la période de facturation. | -| `billingprofileid` | L'ID unique de l'inscription au contrat d'entreprise. | -| `billingprofilename` | Le nom de l'inscription au contrat d'entreprise. | -| `chargetype` | Le type de dépense couvrant le poste : `Usage`, `Purchase` ou `Refund`. | -| `consumedservice` | Le nom du service auquel le poste est associé. | -| `costcenter` | Le centre de coûts défini pour l'abonnement, pour le suivi des coûts. | +| `billingprofileid` | L'identifiant unique de l'inscription au Contrat Entreprise. | +| `billingprofilename` | Le nom de l'inscription au Contrat Entreprise. | +| `chargetype` | Le type de charge couvrant le poste de ligne : `Usage`, `Purchase` ou `Refund`. | +| `consumedservice` | Le nom du service auquel le poste de ligne est associé. | +| `costcenter` | Le centre de coûts défini pour l'abonnement afin de suivre les coûts. | | `costinbillingcurrency` | Le coût dans la devise de facturation avant crédits ou taxes. | | `costinpricingcurrency` | Le coût dans la devise de tarification avant crédits ou taxes. | | `currency` | La devise associée au compte de facturation. | -| `date` | La date d'utilisation ou d'achat de la dépense. | -| `effectiveprice` | Le prix unitaire combiné pour la période. Les prix combinés compensent les fluctuations éventuelles du prix unitaire, par exemple lorsque différents niveaux permettent de bénéficier de différents tarifs selon la quantité. | +| `date` | La date d'utilisation ou d'achat de la charge. | +| `effectiveprice` | Le prix unitaire mixte pour la période. Les prix mixtes lissent les fluctuations du prix unitaire, comme la tarification par paliers, qui réduit le prix à mesure que la quantité augmente. | | `exchangeratedate` | La date à laquelle le taux de change a été établi. | -| `exchangeratepricingtobilling` | Le taux de change utilisé pour convertir le coût depuis la devise de tarification vers la devise de facturation. | -| `frequency` | Indique si une dépense est censée se répéter. Les dépenses peuvent se produire une seule fois (`OneTime`), se répéter sur une base mensuelle ou annuelle (`Recurring`) ou être basées sur l'utilisation (`Usage`). | -| `InvoiceId` | L'ID de document unique indiqué sur le PDF de la facture. | -| `invoicesectionid` | L'ID de la section de facturation du contrat client Microsoft. | -| `invoicesectionname` | Le nom du service lié au contrat d'entreprise. | -| `isazurecrediteligible` | `true` si la dépense peut être payée avec des crédits Azure. | -| `location` | L'emplacement du centre de données exécutant la ressource. | -| `metercategory` | Le service de premier niveau auquel appartient cette utilisation (par exemple `Networking`). | +| `exchangeratepricingtobilling` | Le taux de change utilisé pour convertir le coût dans la devise de tarification en devise de facturation. | +| `frequency` | Indique si une charge est censée se répéter. Les charges peuvent être ponctuelles (`OneTime`), se répéter sur une base mensuelle ou annuelle (`Recurring`), ou être basées sur l'utilisation (`Usage`) | +| `InvoiceId` | L'identifiant unique du document figurant sur le PDF de la facture. | +| `invoicesectionid` | L'identifiant de la section de facture MCA. | +| `invoicesectionname` | Le nom du département du Contrat Entreprise (EA). | +| `isazurecrediteligible` | `true` si la charge est éligible au paiement par crédits Azure. | +| `location` | L'emplacement du centre de données où la ressource est en cours d'exécution. | +| `metercategory` | Le service de niveau supérieur auquel appartient cette utilisation (tel que `Networking`). | | `meterid` | L'ID unique du compteur. | -| `metername` | Les détails d'utilisation du poste (par exemple `L8s v2` ou `General Purpose Data Stored`). | -| `meterregion` | L'emplacement du centre de données pour les services dont la tarification varie en fonction de la localisation (par exemple `West US 2`). Utilisez `resourcelocation` pour consulter les données de localisation sans `N/A`. | -| `metersubcategory` | Le nom de la catégorie de sous-classification du compteur (par exemple `General Purpose - Storage`). Utilisez `metername` ou `metercategory` pour consulter la classification de niveau supérieur sans `N/A`. | -| `offerid` | Le nom de l'offre souscrite. | -| `partnumber` | L'ID utilisé pour obtenir la tarification du compteur spécifique. | -| `planname` | Le nom du programme du marketplace, si l'achat est effectué sur le marketplace. | -| `PreviousInvoiceId` | Une référence à une facture originale, si ce poste concerne un remboursement. | -| `PricingCurrency` | La devise utilisée lors de l'évaluation, en fonction des tarifs négociés. | -| `pricingmodel` | Le type d'utilisation (par exemple `Reservation`). | +| `metername` | Les détails d'utilisation du poste de ligne (tels que `L8s v2` ou `General Purpose Data Stored`). | +| `meterregion` | L'emplacement du centre de données pour les services dont le prix est basé sur l'emplacement (tels que `West US 2`). Utilisez `resourcelocation` pour voir les données d'emplacement sans `N/A`. | +| `metersubcategory` | Le nom de la catégorie de sous-classification du compteur (telle que `General Purpose - Storage`). Utilisez `metername` ou `metercategory` pour voir la classification de niveau supérieur sans `N/A`. | +| `offerid` | Le nom de l'offre achetée. | +| `partnumber` | L'ID utilisé pour obtenir une tarification spécifique du compteur. | +| `planname` | Le nom du plan de la place de marché s'il a été acheté via la place de marché. | +| `PreviousInvoiceId` | Référence à une facture originale si ce poste de ligne est un remboursement. | +| `PricingCurrency` | La devise utilisée lors de l'évaluation basée sur des prix négociés. | +| `pricingmodel` | Le type d'utilisation (tel que `Reservation`). | | `ProductId` | L'identifiant d'un produit Azure spécifique. | -| `productname` | Le nom précis du produit Azure, par exemple le type de VM ou disque et la région | -| `productorderid` | L'ID de la commande de produit. Utilisez `productname` pour consultez des informations de niveau supérieur sur les produits sans `N/A`. | -| `productordername` | Le nom de la commande de produit. Utilisez `productname` pour consultez des informations de niveau supérieur sur les produits sans `N/A`. | -| `publishername` | L'éditeur des services sur le marketplace. | -| `publishertype` | Le type d'éditeur : `Microsoft` pour les comptes de contrat client Microsoft et `Azure` pour les comptes de contrat d'entreprise. | -| `reservationid` | L'ID de l'instance de réservation achetée. Si des valeurs `N/A` sont indiquées, il s'agit de ressources `OnDemand`, qui peuvent être vérifiées à l'aide du tag `pricingmodel`. | -| `reservationname` | Le nom de l'instance de réservation achetée. Si des valeurs `N/A` sont indiquées, il s'agit de ressources `OnDemand`, qui peuvent être vérifiées à l'aide du tag `pricingmodel`. | -| `resourcegroup` | Le nom du groupe de ressources dans lequel se trouve la ressource. Les dépenses ne proviennent pas toutes de ressources déployées au sein de groupes de ressources. | +| `productname` | Le nom du produit Azure à un niveau granulaire, tel que le type de VM ou de disque et la région. | +| `productorderid` | L'ID de la commande de produit. Utilisez `productname` pour voir les informations sur le produit de niveau supérieur sans `N/A`. | +| `productordername` | Le nom de la commande de produit. Utilisez `productname` pour voir les informations sur le produit de niveau supérieur sans `N/A`. | +| `publishername` | L'éditeur des services de la place de marché. | +| `publishertype` | Le type d'éditeur : `Microsoft` pour les comptes Contrat client Microsoft et `Azure` pour les comptes Contrat Entreprise. | +| `reservationid` | L'ID de l'instance de réservation achetée. Si vous voyez des valeurs `N/A`, il s'agit de ressources `OnDemand`, qui peuvent être vérifiées à l'aide du tag `pricingmodel`. | +| `reservationname` | Le nom de l'instance de réservation achetée. Si vous voyez des valeurs `N/A`, il s'agit de ressources `OnDemand`, qui peuvent être vérifiées à l'aide du tag `pricingmodel`. | +| `resourcegroup` | Le nom du groupe de ressources dans lequel se trouve la ressource. Tous les frais ne proviennent pas de ressources déployées dans des groupes de ressources. | | `resourceid` | L'ID de la ressource Azure. | -| `resourcelocation` | L'emplacement du centre de données exécutant la ressource (par exemple `westus2`). | -| `resourcename` | Le nom de la ressource. Les dépenses ne proviennent pas toutes de ressources déployées. | +| `resourcelocation` | L'emplacement du centre de données où la ressource est en cours d'exécution (tel que `westus2`). | +| `resourcename` | Le nom de la ressource. Tous les frais ne proviennent pas de ressources déployées. | | `resourcetype` | Le type de la ressource Azure. | -| `servicefamily` | La famille de services à laquelle le service appartient (par exemple `Compute`). Le tag `consumedservice` offre des informations plus approfondies sur les types d'infrastructure. | +| `servicefamily` | La famille de services à laquelle appartient le service (tel que `Compute`). Le tag `consumedservice` offre des informations plus approfondies sur les types d'infrastructure. | | `ServicePeriodEndDate` | La date de fin de la période de service Azure. | | `ServicePeriodStartDate` | La date de début de la période de service Azure. | | `subscriptionid` | L'ID de l'abonnement Azure. | | `subscriptionname` | Le nom de l'abonnement Azure. | -| `term` | La durée ou le terme du programme de remise, en mois (par exemple `12`). | -| `unitofmeasure` | L'unité de mesure pour la facturation du service. Par exemple, les services de calcul sont facturés à l'heure. | +| `term` | Décrit la durée ou le terme du plan d'économies en mois (tel que `12`). | +| `unitofmeasure` | L'unité de mesure utilisée pour la facturation du service. Par exemple, les services de calcul sont facturés à l'heure. | -#### Corrélation entre les coûts et les données d'observabilité +#### Corrélation entre coûts et observabilité : {#cost-and-observability-correlation} -Visualiser les coûts à l'aide de données d'observabilité est essentiel pour comprendre l'impact des modifications apportées à l'infrastructure sur les coûts, déterminer les raisons pour lesquelles les coûts évoluent, et optimiser les coûts et performances de l'infrastructure. Datadog ajoute le tag `name` aux données de coûts pour les principaux produits Azure, afin de simplifier la mise en corrélation des données d'observabilité et des métriques de coûts. +Visualiser les coûts dans le contexte des données d'observabilité est important pour comprendre comment les changements d'infrastructure impactent les coûts, identifier pourquoi les coûts changent et optimiser l'infrastructure à la fois pour les coûts et les performances. Datadog ajoute le tag `name` aux données de coût pour les principaux produits Azure afin de simplifier la corrélation entre les métriques d'observabilité et de coût. -Par exemple, pour consulter l'utilisation et le coût de chaque VM Azure, vous pouvez créer un tableau avec `azure.cost.amortized` et `azure.vm.network_in_total` (ou toute autre métrique de VM) et effectuer un regroupement en fonction de `name`. Pour comparer visuellement les données d'utilisation et de coûts de stockage, vous pouvez appliquer un filtre basé sur `metercategory:Storage`, représenter `azure.storage.transactions` et `azure.cost.amortized` dans un graphique et effectuer un regroupement selon `name`. +Par exemple, pour visualiser le coût et l'utilisation de chaque VM Azure, vous pouvez créer un tableau avec `azure.cost.amortized` et `azure.vm.network_in_total` (ou toute autre métrique de VM) et grouper par `name`. Ou, pour voir l'utilisation du stockage et les coûts côte à côte, vous pouvez filtrer dans `metercategory:Storage` et représenter graphiquement `azure.storage.transactions` et `azure.cost.amortized` groupés par `name`. -## Pour aller plus loin +## Pour aller plus loin {#further-reading} {{< partial name="whats-next/whats-next.html" >}} [1]: https://www.datadoghq.com/blog/azure-datadog-partnership/ [2]: https://docs.datadoghq.com/fr/integrations/azure/?tab=azurecliv20#setup -[3]: https://app.datadoghq.com/cost/setup?cloud=azure +[3]: https://app.datadoghq.com/cost/setup [4]: https://app.datadoghq.com/integrations/azure [5]: https://portal.azure.com/#view/Microsoft_Azure_CostManagement/Menu/~/config [6]: https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/tutorial-export-acm-data?tabs=azure-cli @@ -259,5 +356,11 @@ Par exemple, pour consulter l'utilisation et le coût de chaque VM Azure, vous p [8]: https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/tutorial-improved-exports [9]: https://learn.microsoft.com/en-us/azure/cost-management-billing/understand/download-azure-daily-usage [10]: https://docs.azure.cn/en-us/cost-management-billing/manage/resolve-past-due-balance#check-the-type-of-your-account -[11]: /fr/help/ -[12]: /fr/cloud_cost_management/tags \ No newline at end of file +[12]: /fr/cloud_cost_management/tags +[13]: /fr/api/latest/cloud-cost-management/#create-cloud-cost-management-azure-configs +[14]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/azure_uc_config +[15]: https://learn.microsoft.com/en-us/azure/cost-management-billing/microsoft-customer-agreement/onboard-microsoft-customer-agreement +[16]: /fr/help/ +[17]: ?tab=manual#generate-cost-exports +[18]: #migrate-exports-from-an-ea-to-an-mca +[19]: ?tab=terraform \ 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 index 997681bbb7e..59c7142c0f9 100644 --- a/hugo/content/fr/containers/monitoring/kubernetes_explorer.md +++ b/hugo/content/fr/containers/monitoring/kubernetes_explorer.md @@ -81,6 +81,8 @@ Pour une configuration manuelle, consultez [Configurer Kubernetes Explorer avec 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]. +{{< site-region region="gov,gov2" >}}
Cette fonctionnalité n'est pas disponible pour {{< region-param key="dd_site_name" >}}.
{{< /site-region >}} + #### Prérequis {#prerequisites} - OpenTelemetry Collector Contrib [v0.154.0][3] ou version ultérieure. @@ -167,7 +169,7 @@ config: 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. +- La détection du nom du cluster dépend de votre fournisseur cloud. Vérifiez 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`. @@ -303,7 +305,9 @@ Vous pouvez remplir Kubernetes Explorer en utilisant le chart Helm `opentelemetr 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. +- **`daemon`** (DaemonSet) : collecte les métriques du host et du kubelet, et expose un endpoint OTLP pour les données de télémétrie des applications. + +{{< site-region region="gov,gov2" >}}
Cette fonctionnalité n'est pas disponible pour {{< region-param key="dd_site_name" >}}.
{{< /site-region >}} #### Prérequis {#prerequisites-1} @@ -328,7 +332,7 @@ Le dépôt [`opentelemetry-examples`][6] fournit un installateur interactif qui ./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. +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 nommage `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} @@ -554,21 +558,21 @@ Les autres onglets comportent des informations supplémentaires permettant de r 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%;">}} +{{< 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} +### Utilisation des ressources {#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%;">}} +{{< img src="infrastructure/livecontainers/orch_ex_resource_utilization.png" alt="Utilisation des ressources du conteneur" 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} +## Détails du filtre de requête {#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. @@ -584,11 +588,11 @@ 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` | +| **Tags** : Appliqués aux ressources par [l'Agent qui les recueille][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)_ | +| **Étiquettes** : Extraites des [métadonnées d'une ressource][8]. Elles sont généralement utilisées pour organiser votre cluster et cibler des ressources spécifiques avec des sélecteurs. | `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) | +| **Métriques** : Ajoutées aux ressources de workloads (pods, déploiements, 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%` | +| **Correspondance de chaîne** : Prise en charge par certains d'attributs de ressource spécifiques (voir ci-dessous).
_Remarque : cette fonctionnalité ne repose pas sur un format clé-valeur, et vous ne pouvez pas spécifier l'attribut de votre choix._ | `"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.* @@ -603,25 +607,25 @@ Les attributs de ressource suivants sont pris en charge dans la **Correspondance 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} +#### Comparateurs {#comparators} -Tous les termes prennent en charge l'opérateur d'égalité `:`. [Metric value](#resource-utilization-filters) terms support numeric comparisons as well: +Tous les termes prennent en charge l'opérateur d'égalité `:`. Les termes de [valeur métrique](#resource-utilization-filters) prennent également en charge les comparaisons numériques : -- `:>` Greater than (for example, `metric#cpu_usage_avg15:>0.9`) -- `:>=` Greater than or equal -- `:<` Less than -- `:<=` Less than or equal +- `:>` Supérieur à (par exemple, `metric#cpu_usage_avg15:>0.9`) +- `:>=` Supérieur ou égal à +- `:<` Inférieur à +- `:<=` Inférieur ou égal à -#### Operators {#operators} +#### Opérateurs {#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 | +| Opérateur | Description | Exemple | |---|---|---| -| `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` | +| `AND` | **Intersection** : Les deux termes figurent dans les événements sélectionnés (si aucun opérateur n'est ajouté, AND est utilisé par défaut) | `a AND b` | +| `OR` | **Union** : Un des deux termes figure dans les événements sélectionnés | `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} @@ -639,17 +643,17 @@ 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 : +Vous pouvez utiliser des wildcards `*` dans un terme pour filtrer par correspondances partielles, aussi bien pour les valeurs que pour les clés. 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`. +- `kube_job:stats-*` : Trouver toutes les ressources avec une valeur de tag `kube_deployment` commençant par `stats-`. +- `pod_name:*canary` : Trouver toutes les ressources avec une valeur `pod_name` se terminant par `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. +- `-label#*.datadoghq.com/*` : Trouver les ressources qui n'ont aucun label Datadog. - `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. +En plus des tags que vous avez [configurés][7] dans votre Datadog Agent, 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} @@ -683,7 +687,7 @@ Selon les étiquettes appliquées à la ressource, les tags suivants sont égale 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`. +- Une entrée 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). @@ -721,7 +725,7 @@ Certaines ressources possèdent des tags spécifiques qui sont extraits en fonct |---|---| | **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` | +| **Espace de nommage** | `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` | @@ -773,7 +777,7 @@ Les pourcentages (`*_pct_*`) sont stockés sous forme de nombres à virgule flot * 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} +## Pour aller plus loin {#further-reading} {{< partial name="whats-next/whats-next.html" >}} diff --git a/hugo/content/fr/data_security/real_user_monitoring.md b/hugo/content/fr/data_security/real_user_monitoring.md index 0ba6a72a713..523e260b8aa 100644 --- a/hugo/content/fr/data_security/real_user_monitoring.md +++ b/hugo/content/fr/data_security/real_user_monitoring.md @@ -7,135 +7,134 @@ further_reading: text: Consulter les principales catégories de données envoyées à Datadog - link: /data_security/synthetics/ tag: Documentation - text: Sécurité des données liées à la surveillance Synthetic -- link: /session_replay/browser/privacy_options/ + text: Sécurité des données de Synthetic Monitoring +- link: /session_replay/privacy_options?platform=browser tag: Documentation - text: Options de confidentialité de Session Replay + text: Options de confidentialité de Session Replay - link: https://www.datadoghq.com/blog/default-privacy-session-replay/ tag: Blog text: Obfusquer les données utilisateur avec les paramètres de confidentialité par - défaut de Session Replay -title: Sécurité des données Real User Monitoring + défaut de Session Replay +title: Sécurité des données Real User Monitoring (RUM) --- +
Cette page concerne la sécurité des données envoyées à Datadog. Si vous recherchez des produits et fonctionnalités de sécurité cloud et applicative, consultez la section Sécurité.
-
Cette page est consacrée à la sécurité des données transmises à Datadog. Si vous cherchez des fonctionnalités et solutions relatives à la sécurité des applications et du cloud, consultez la section Sécurité.
+## Présentation {#overview} +Real User Monitoring (RUM) fournit des contrôles pour mettre en œuvre les exigences de confidentialité et garantir que les organisations de toute taille n'exposent pas d'informations sensibles ou personnelles. Les données sont stockées sur des instances cloud gérées par Datadog et chiffrées au repos. Les comportements par défaut et les options configurables décrits sur cette page sont conçus pour protéger la confidentialité des utilisateurs finaux et empêcher la collecte d'informations organisationnelles sensibles. En savoir plus sur [la confidentialité chez Datadog][1]. -## Présentation -Real User Monitoring (RUM) fournit des contrôles pour la mise en œuvre des exigences de confidentialité et garantit que les organisations de toute taille n'exposent pas d'informations sensibles ou personnelles. Les données sont stockées sur des instances cloud gérées par Datadog et chiffrées au repos. Les comportements par défaut et les options configurables décrits sur cette page sont conçus pour protéger la confidentialité des utilisateurs finaux et empêcher la collecte d'informations organisationnelles sensibles. Pour en savoir plus, consultez la section [Confidentialité chez Datadog][1]. +## Responsabilité partagée {#shared-responsibility} -## Responsabilité partagée +La responsabilité de maintenir la sécurité des données des utilisateurs est partagée entre Datadog et les développeurs qui utilisent les SDK RUM. -La responsabilité de la sécurité des données des utilisateurs est partagée entre Datadog et les développeurs qui utilisent les SDK RUM. +Datadog est responsable de : -Datadog est tenu : +- Fournir un produit fiable qui traite les données de manière sécurisée lorsqu'elles sont transmises à la plateforme Datadog et y sont stockées. +- Veiller à ce que les problèmes de sécurité soient identifiés conformément aux politiques internes. -- de fournir un produit fiable qui traite les données en toute sécurité lorsqu'elles sont transmises et stockées sur la plate-forme Datadog. -- de veiller à ce que les problèmes de sécurité soient identifiés conformément aux politiques internes. +Les développeurs sont responsables de : +- Exploiter les valeurs de configuration et les options de confidentialité des données fournies par Datadog. +- Assurer l'intégrité du code au sein de leurs environnements. -Les développeurs sont tenus : -- dʼexploiter les valeurs de configuration et les options pour la confidentialité des données fournies par Datadog. -- dʼassurer l'intégrité du code au sein de leur environnements. - -## Frameworks de conformité -Le RUM peut être configuré pour la conformité à de nombreuses normes et référentiels réglementaires, notamment : +## Cadres de compliance{#compliance-frameworks} +RUM peut être configuré pour assurer la conformité avec de nombreuses normes et cadres réglementaires, notamment, mais sans s'y limiter : - RGPD - HIPAA - ISO - CCPA/CPRA -## Restrictions de confidentialité -Par défaut, certaines restrictions de confidentialité sont en place pour protéger les données des utilisateurs et faciliter la conformité aux référentiels réglementaires et normatifs. +## Restrictions de confidentialité {#privacy-restrictions} +Par défaut, certaines restrictions de confidentialité sont en place pour protéger les données des utilisateurs afin d'aider à se conformer aux cadres réglementaires et normatifs. -### Utilisation des cookies par le RUM Browser -Le RUM Browser nécessite l'activation des cookies first-party dans le navigateur de l'utilisateur final pour collecter des données. Si les juridictions dans lesquelles vous opérez l'exigent, il vous incombe de configurer vos pages pour vous conformer aux lois de ces juridictions, notamment en obtenant le consentement pour la collecte des cookies avant l'initialisation de RUM. +### Utilisation des cookies par RUM pour navigateur {#browser-rum-use-of-cookies} +RUM pour navigateur nécessite que les first-party cookies soient activés sur le navigateur de l'utilisateur final pour collecter des données. Si les juridictions dans lesquelles vous opérez l'exigent, il vous incombe de configurer vos pages pour vous conformer aux lois de ces juridictions, y compris l'obtention du consentement pour collecter des cookies avant l'initialisation de RUM. -### Gestion du consentement pour le RUM mobile -Le suivi RUM mobile n'est exécuté qu'avec le consentement de l'utilisateur. Si l'utilisateur final accepte le suivi RUM, Datadog suit son activité et son expérience de session. Si l'utilisateur refuse le suivi RUM, Datadog ne suit pas son activité et son expérience de session. +### Gestion du consentement RUM pour mobile {#mobile-rum-consent-management} +Le suivi RUM pour mobile n'est exécuté qu'après le consentement de l'utilisateur. Si l'utilisateur final accepte le suivi RUM, Datadog suit son activité et son expérience de session. Si l'utilisateur refuse le suivi RUM, Datadog ne suit pas son activité ni son expérience de session. -## Options de confidentialité -Vous disposez de plusieurs options et outils pour la collecte et la suppression des données capturées par le RUM. +## Options de confidentialité {#privacy-options} +Vous disposez de plusieurs options et outils pour collecter et masquer les données capturées par RUM. -### Token client -Le [token client][2] du RUM Browser est utilisé pour associer les données du navigateur de l'utilisateur final à une application RUM spécifique dans Datadog. Il n'est pas chiffré et est visible côté client d'une application. +### Jeton client {#client-token} +Le [jeton client][2] RUM du navigateur est utilisé pour faire correspondre les données du navigateur de l'utilisateur final à une application RUM spécifique dans Datadog. Il n'est pas chiffré et est visible depuis le côté client d'une application. -Le token client étant uniquement utilisé pour envoyer des données à Datadog, ce token ne présente aucun risque de perte de données ; cependant, Datadog recommande une bonne gestion du token client pour éviter d'autres types d'utilisation abusive, notamment : +Comme le jeton client est uniquement utilisé pour envoyer des données à Datadog, il n'y a aucun risque de perte de données dû à ce jeton ; cependant, Datadog recommande une bonne gestion du jeton client pour éviter d'autres types d'utilisation abusive, notamment : -- [Faire régulièrement tourner le token client][3] pour s'assurer qu'il n'est utilisé que par votre application -- [Filtrer automatiquement les bots][4] lors de la capture des données RUM +- [Rotation régulière du jeton client][3] pour garantir qu'il n'est utilisé que par votre application +- [Filtrage automatique des bots][4] lors de la capture des données RUM -#### Proxy authentifié -L'utilisation du token client pour filtrer les bots via un proxy authentifié est l'une des méthodes disponibles. Dans cette méthode, une chaîne de remplacement est substituée au `clientToken` lors de l'initialisation du RUM Browser SDK Datadog. Le proxy connaît le vrai token client, mais pas l'utilisateur final. +#### Proxy authentifié {#authenticated-proxy} +Une méthode pour utiliser le jeton client afin de filtrer les bots est un proxy authentifié. Dans cette méthode, une chaîne d'espace réservé est substituée au `clientToken` lors de l'initialisation du SDK Datadog RUM Browser. Le proxy connaît le véritable jeton client, mais l'utilisateur final ne le connaît pas. -Le proxy est configuré pour vérifier les informations utilisateur valides avant de transmettre les données de session à Datadog, confirmant ainsi qu'un vrai utilisateur est connecté et transmet du trafic à surveiller. Lors de la réception du trafic, le proxy vérifie que les données contiennent la chaîne de remplacement et la remplace par le vrai `clientToken` avant de transmettre les données à Datadog. +Le proxy est configuré pour vérifier la validité des informations utilisateur avant de transmettre les données de session à Datadog, confirmant ainsi qu'un utilisateur réel est connecté et transmet du trafic à surveiller. Lors de la réception du trafic, le proxy vérifie que les données incluent la chaîne d'espace réservé et la remplace par le `clientToken` réel avant de transférer les données à Datadog. -### Suivi des événements -Un [événement][5] est une interaction d'un utilisateur avec des éléments spécifiques de votre site ou application. Les événements peuvent être capturés automatiquement via le SDK ou envoyés via des actions personnalisées. Vous pouvez désactiver le suivi automatique des interactions des utilisateurs et des pages vues pour ne capturer que les interactions de votre choix. Par défaut, RUM utilise le contenu cible pour générer des noms d'actions à partir des actions collectées automatiquement par le SDK. Vous pouvez [remplacer explicitement][6] ce comportement par n'importe quel nom donné. +### Suivi des événements {#event-tracking} +Un [événement][5] est une interaction utilisateur avec des éléments spécifiques de votre site ou application. Les événements peuvent être capturés automatiquement via le SDK ou envoyés via des actions personnalisées. Vous pouvez désactiver le suivi automatique des interactions utilisateur et des pages vues pour ne capturer que l'interaction de votre choix. Par défaut, RUM utilise le contenu cible pour générer automatiquement des noms d'action à partir des actions collectées par le SDK. Vous pouvez [explicitement remplacer][6] ce comportement par n'importe quel nom. -Les données que nous suivons automatiquement contiennent principalement des informations techniques, dont une grande partie ne comprend pas d'informations personnellement identifiables. Les données capturées par RUM peuvent être davantage supprimées avant d'être envoyées et stockées dans Datadog grâce à des options de configuration avancées pour les méthodes suivantes : +Les données que nous suivons automatiquement contiennent principalement des informations techniques, dont la plupart n'incluent pas d'informations personnellement identifiables. Les données capturées par RUM peuvent être davantage expurgées avant d'être envoyées et stockées dans Datadog grâce à des options de configuration avancées pour les méthodes suivantes : -- [API beforeSend][7] +- [beforeSend API][7] - [iOS][8] - [Android][9] - [Flutter][10] - [React Native][11] -### Transmettre les événements du RUM via un serveur proxy +### Transmettre les événements RUM via un serveur proxy {#transmit-rum-events-through-a-proxy-server} Vous pouvez transmettre tous les événements RUM via votre propre [serveur proxy][12] afin que les appareils des utilisateurs finaux ne communiquent jamais directement avec Datadog. -### Suivi de l'identité des utilisateurs -Par défaut, **aucun suivi de l'identité des utilisateurs** n'est effectué. Chaque session est associée à un `session.id` unique qui anonymise les données tout en vous permettant de comprendre les tendances. Vous avez la possibilité d'écrire du code pour capturer des [données utilisateur][13] telles que le nom et l'adresse e-mail, puis d'utiliser ces données pour [enrichir et modifier][13] les sessions RUM, mais cela n'est pas obligatoire. +### Suivi de l'identité des utilisateurs {#user-identity-tracking} +Par défaut, il n'y a **aucun suivi de l'identité des utilisateurs**. Chaque session est associée à un `session.id` unique, ce qui anonymise les données tout en vous permettant de comprendre les tendances. Vous avez la possibilité d'écrire du code pour capturer les [données utilisateur][13] telles que le nom et l'adresse e-mail, puis d'utiliser ces données pour [enrichir et modifier][13] les sessions RUM, mais cela n'est pas obligatoire. -### Conservation des données -Une fois la capture des événements configurée, les événements sont stockés dans Datadog. Vous pouvez décider de la durée de conservation de vos événements et propriétés capturés dans Datadog. +### Rétention des données{#data-retention} +Une fois que vous avez configuré la capture d'événements, les événements sont stockés dans Datadog. Vous pouvez décider de la durée pendant laquelle vos événements et propriétés capturés restent dans Datadog. -Par défaut, la rétention des données pour les environnements de production est : +Par défaut, la rétention des données pour les environnements de production est : -- 30 jours pour les sessions, vues, actions, erreurs et enregistrements de session. -- 15 jours pour les ressources et les tâches longues. +- 30 jours pour les sessions, les vues, les actions, les erreurs et les enregistrements de session. +- 15 jours pour les ressources et les tâches longues. -Pour prolonger la rétention de vos données afin d'analyser les comportements des utilisateurs sur des périodes plus longues (sessions, vues et actions uniquement), vous pouvez soumettre une demande pour [rejoindre Product Analytics][20]. +Pour étendre la rétention de vos données afin d'analyser les comportements des utilisateurs sur des périodes plus longues (sessions, vues et actions uniquement), vous pouvez soumettre une demande pour [rejoindre Product Analytics][20]. -#### Contrôle d'accès basé sur les rôles -Datadog fournit un contrôle d'accès basé sur les rôles (RBAC) pour gérer qui consulte les données RUM capturées. Les paramètres par défaut pour l'accès aux données dépendent du rôle auquel un utilisateur est ajouté. Il existe trois types de rôles Datadog : Administrateur, Standard et Lecture seule. Des autorisations RUM plus granulaires sont définies dans les [autorisations des rôles Datadog][15]. Par exemple, vous pouvez accorder ou révoquer l'accès à la consultation des Session Replays. +#### Contrôle d'accès basé sur les rôles{#role-based-access-control} +Datadog fournit un contrôle d'accès basé sur les rôles (RBAC) pour gérer qui peut voir les données RUM capturées. Les paramètres par défaut pour l'accès aux données dépendent du rôle auquel un utilisateur est ajouté. Il existe trois types de rôles Datadog disponibles : les rôles Administrateur, Standard et Lecture seule. Des autorisations RUM plus granulaires sont définies dans les [autorisations de rôle Datadog][15]. Par exemple, vous pouvez accorder ou révoquer l'accès à la visualisation de Session Replays. -### Suppression des données -Si vous devez supprimer des données stockées par Datadog, par exemple si des données potentiellement sensibles ont été divulguées dans des événements RUM, vous pouvez effectuer une suppression définitive des données dans un intervalle de temps donné. Avec une suppression définitive, **toutes** les données sont supprimées ; il n'est pas possible de cibler une application spécifique. Si vous avez besoin de supprimer des données, contactez [l'équipe d'assistance Datadog][14]. +### Suppression de données{#data-deletion} +Si vous devez supprimer des données stockées par Datadog, par exemple si des données potentiellement sensibles ont été divulguées dans des événements RUM, vous pouvez supprimer définitivement les données dans un intervalle de temps donné. Avec une suppression définitive, **toutes** les données sont supprimées ; elle ne peut pas être ciblée sur une application spécifique. Si vous avez besoin de supprimer des données, contactez l'[équipe de support Datadog][14]. -### Suppression des données personnelles et sensibles -Vous disposez de plusieurs options pour supprimer les informations personnellement identifiables (PII) et les données sensibles, notamment les adresses IP et la géolocalisation. Voici quelques scénarios dans lesquels des PII peuvent apparaître dans RUM : +### Suppression des données personnelles et sensibles{#personal-and-sensitive-data-removal} +Vous disposez de plusieurs options pour supprimer les informations personnellement identifiables (PII) et les données sensibles, y compris les adresses IP et la géolocalisation. Quelques scénarios où des PII pourraient apparaître dans RUM : -- Noms d'actions sur les boutons (par exemple, "Afficher le numéro complet de la carte de crédit") +- Noms d'action sur les boutons (par exemple, « Voir le numéro de carte de crédit complet ») - Noms affichés dans les URL -- Événements de suivi personnalisés instrumentés par les développeurs de l'application +- Événements suivis personnalisés instrumentés par les développeurs de l'application -#### Masquer les noms d'actions -Par défaut, pour masquer tous les noms d'actions, vous pouvez utiliser l'option `enablePrivacyForActionName` conjointement avec le paramètre de confidentialité `mask`. Cette opération substitue automatiquement tous les noms d'actions non remplacés par l'espace réservé `Masked Element`. Ce paramètre est également conçu pour être compatible avec les [attributs de remplacement HTML][16] existants. +#### Masquer les noms d'action {#mask-action-names} +Par défaut, si vous souhaitez masquer tous les noms d'action, vous pouvez utiliser l'option `enablePrivacyForActionName` conjointement avec le paramètre de confidentialité `mask`. Cette opération remplace automatiquement tous les noms d'action non remplacés par l'espace réservé `Masked Element`. Ce paramètre est également conçu pour être compatible avec les [HTML override attributes][16] existants. -#### Données non structurées -Les PII incluses par inadvertance dans des données non structurées, telles que le nom d'un individu dans une zone de texte, ne peuvent être supprimées que via une demande de suppression de données pour un intervalle de temps spécifié. +#### Données non structurées {#unstructured-data} +Les PII incluses par inadvertance dans des données non structurées, comme le nom d'une personne dans une zone de texte, ne peuvent être supprimées que par une demande de suppression de données pour une période donnée. En ce qui concerne les URL, vous avez la possibilité de suivre les pages vues manuellement pour supprimer toute PII ou d'utiliser beforeSend pour modifier le texte de l'URL. Vous pouvez également transmettre tous les événements RUM via votre propre serveur (proxy) afin que les appareils des utilisateurs finaux ne communiquent jamais directement avec Datadog. -#### Adresse IP -Après avoir initialisé votre application RUM, vous pouvez choisir d'inclure ou non les données d'adresse IP ou de géolocalisation depuis l'onglet **Collecte des données utilisateur** : +#### Adresse IP {#ip-address} +Une fois votre application RUM initialisée, vous pouvez choisir d'inclure ou non les données IP ou de géolocalisation depuis l'onglet {{< ui >}}User Data Collection{{< /ui >}} : -{{< img src="data_security/data-security-rum-privacy-compliance-user-data-collection-1.png" alt="Vous pouvez inclure ou exclure les données de géolocalisation et d'adresse IP client depuis la page de gestion de l'application RUM" style="width:100%;" >}} +{{< img src="data_security/data-security-rum-privacy-compliance-user-data-collection-1.png" alt="Vous pouvez inclure ou exclure les données de géolocalisation et l'adresse IP du client depuis la page de gestion de l'application RUM" style="width:100%;" >}} -Après avoir désactivé la collecte des données IP, la modification est appliquée immédiatement. Les événements collectés avant la désactivation ne voient pas leurs données IP supprimées. Cette opération est effectuée au niveau du backend, ce qui signifie que le Browser SDK continue d'envoyer des données, mais que les adresses IP sont omises par les pipelines backend Datadog et supprimées au moment du traitement. +Une fois que vous avez désactivé la collecte des données IP, la modification est appliquée immédiatement. Les événements collectés avant la désactivation n'entraînent pas la suppression des données IP. Cela est effectué sur le backend, ce qui signifie que le SDK Browser envoie toujours des données, mais les adresses IP sont omises par les pipelines backend de Datadog et supprimées au moment du traitement. -#### Géolocalisation -En plus de supprimer les adresses IP client, vous pouvez également choisir de désactiver la collecte de géolocalisation (pays, ville, comté), ou GeoIP, pour toutes les données collectées ultérieurement. Si vous décochez la case **Collecter les données de géolocalisation**, la modification est appliquée immédiatement. Les événements collectés avant la désactivation ne voient pas leurs données de géolocalisation supprimées. L'omission des données est effectuée au niveau du backend, ce qui signifie que le Browser SDK continue d'envoyer des données, mais que les données de géolocalisation sont omises par les pipelines backend Datadog et supprimées au moment du traitement. +#### Géolocalisation {#geolocation} +En plus de supprimer les adresses IP des clients, vous pouvez également choisir de désactiver la collecte de la géolocalisation (pays, ville, comté), ou GeoIP, pour toutes les données collectées ultérieurement. Si vous décochez la case {{< ui >}}Collect geolocation data{{< /ui >}}, la modification est appliquée immédiatement. Les événements collectés avant la désactivation n'entraînent pas la suppression des données de géolocalisation correspondantes. L'omission des données est effectuée au niveau du backend, ce qui signifie que le SDK Browser continue d'envoyer des données, mais que les données de géolocalisation sont omises par les pipelines backend de Datadog et supprimées au moment du traitement. -### Rechercher proactivement des données sensibles avec Sensitive Data Scanner -[Sensitive Data Scanner][17] vous permet de rechercher et de nettoyer proactivement les données sensibles lors de l'ingestion par Datadog. Les événements RUM sont analysés sur le flux avant que les données ne soient stockées dans Datadog. Cet outil est capable de nettoyer, hacher ou masquer partiellement les données PII avant leur stockage. Il fonctionne en appliquant des règles de correspondance de modèles prêtes à l'emploi ou développées par le client. Si vous avez activé cette fonctionnalité, vous pouvez la trouver sur la [page **Gérer les données sensibles**][18]. +### Recherchez de manière proactive les données sensibles avec Sensitive Data Scanner {#proactively-search-for-sensitive-data-with-sensitive-data-scanner} +[Sensitive Data Scanner][17] vous permet de rechercher et de nettoyer de manière proactive les données sensibles lors de leur ingestion par Datadog. Les événements RUM sont analysés sur le flux avant que toute donnée ne soit stockée dans Datadog. L'outil a la capacité de nettoyer, de hacher ou de masquer partiellement les données PII avant qu'elles ne soient stockées. Il fonctionne en appliquant des règles de correspondance de modèles prêtes à l'emploi ou développées par le client. Si vous avez activé cette fonctionnalité, vous pouvez la trouver sur la [{{< ui >}}Manage Sensitive Data{{< /ui >}} page][18]. -## Options de confidentialité spécifiques à Session Replay -Consultez la section [options de confidentialité spécifiques à Session Replay][19]. +## Options de confidentialité spécifiques à Session Replay {#session-replay-specific-privacy-options} +Consultez les [options de confidentialité spécifiques à Session Replay][19]. Le masquage dans Session Replay est permanent : les valeurs masquées ne quittent jamais l'appareil et ne peuvent pas être démasquées ultérieurement. Cela diffère du [masquage par Sensitive Data Scanner][21], qui obfusque les valeurs correspondantes lors de l'ingestion mais permet aux utilisateurs disposant de l'autorisation `Data Scanner Unmask` de voir la valeur d'origine. -### Pour aller plus loin +### Lectures complémentaires {#further-reading} {{< partial name="whats-next/whats-next.html" >}} @@ -154,8 +153,9 @@ Consultez la section [options de confidentialité spécifiques à Session Replay [13]: /fr/real_user_monitoring/application_monitoring/browser/advanced_configuration/?tab=npm#user-session [14]: /fr/help/ [15]: /fr/account_management/rbac/permissions/#real-user-monitoring -[16]: /fr/session_replay/browser/privacy_options/#override-an-html-element +[16]: /fr/session_replay/privacy_options?platform=browser#override-an-html-element [17]: /fr/security/sensitive_data_scanner/ [18]: https://app.datadoghq.com/organization-settings/sensitive-data-scanner/configuration -[19]: /fr/session_replay/browser/privacy_options -[20]: https://www.datadoghq.com/private-beta/product-analytics/ \ No newline at end of file +[19]: /fr/session_replay/privacy_options?platform=browser +[20]: https://www.datadoghq.com/private-beta/product-analytics/ +[21]: /fr/security/sensitive_data_scanner/setup/telemetry_data/?tab=logs#mask-action \ No newline at end of file diff --git a/hugo/content/fr/delivery_performance/dora_metrics/_index.md b/hugo/content/fr/delivery_performance/dora_metrics/_index.md new file mode 100644 index 00000000000..618f53d640e --- /dev/null +++ b/hugo/content/fr/delivery_performance/dora_metrics/_index.md @@ -0,0 +1,108 @@ +--- +aliases: +- /fr/continuous_integration/dora_metrics +- /fr/dora_metrics/ +description: Découvrez comment utiliser les métriques DORA pour mesurer et améliorer + les processus de livraison logicielle de votre organisation. +further_reading: +- link: /delivery_performance/dora_metrics/calculation/ + tag: Documentation + text: Découvrez comment Datadog calcule les métriques DORA +- link: /continuous_delivery/deployments + tag: Documentation + text: En savoir plus sur Deployment Visibility +- link: /events + tag: Documentation + text: En savoir plus sur Event Management +- link: /monitors/types/metric + tag: Documentation + text: En savoir plus sur les monitors de métriques +- link: /catalog + tag: Documentation + text: En savoir plus sur le Catalog +- link: https://www.datadoghq.com/blog/platform-engineering-metrics/ + tag: Blog + text: Métriques de succès pour les équipes d'ingénierie de plateforme +- link: https://www.datadoghq.com/blog/dora-metrics-software-delivery/ + tag: Blog + text: Bonnes pratiques pour utiliser les métriques DORA afin d'améliorer la livraison + logicielle +- link: https://www.datadoghq.com/blog/datadog-dora-metrics/ + tag: Blog + text: 3 façons de favoriser la réussite de la livraison logicielle avec Datadog + DORA Metrics +- link: https://www.datadoghq.com/blog/devsecops-2026-study-learnings + tag: Blog + text: Principaux enseignements de l'étude 2026 sur l'état du DevSecOps +- link: https://app.datadoghq.com/release-notes?category=Software%20Delivery + tag: Notes de version + text: Découvrez les dernières versions de Software Delivery ! (Connexion à l'application + requise) +is_beta: true +title: DORA Metrics +--- +## Présentation {#overview} + +Les métriques DORA (DevOps Research and Assessment) sont [quatre métriques clés][1] qui indiquent la vélocité et la stabilité du développement logiciel. + +Fréquence de déploiement +: La fréquence à laquelle une organisation déploie avec succès en production. + +Délai de changement +: Le temps nécessaire pour qu'un commit arrive en production. + +Taux d'échec des changements +: Le ratio de déploiements qui échouent et nécessitent une intervention immédiate. + +Temps de récupération après un déploiement échoué +: Le temps nécessaire pour se rétablir après un déploiement qui échoue et nécessite une intervention immédiate. + +Définir et suivre les métriques DORA peut vous aider à identifier les axes d'amélioration de la rapidité et de la qualité de livraison logicielle de votre équipe ou de votre organisation. + +## Configurer les métriques DORA {#set-up-dora-metrics} + +Pour commencer à configurer les sources de données afin d'envoyer des événements de déploiement à Datadog, consultez la [documentation de configuration][2]. + +## Analyser les métriques DORA {#analyze-dora-metrics} + +Une fois que vous avez configuré les sources de données pour vos événements de déploiement, accédez à [{{< ui >}}Software Delivery{{< /ui >}} > {{< ui >}}Delivery Performance{{< /ui >}} > {{< ui >}}DORA Metrics{{< /ui >}}][4] pour identifier les améliorations ou les régressions pour chaque métrique. Vous pouvez également agréger les métriques par équipe, service, dépôt, environnement, période et [tags personnalisés][8] pour comparer les tendances au fil du temps. + +{{< img src="delivery_performance/dora_metrics/dora_ui_3.png" alt="Un aperçu des calculs DORA Metrics filtrés par le tag personnalisé Language" style="width:100%;" >}} + +Cliquez sur {{< ui >}}View Deployments{{< /ui >}} pour ouvrir un nouvel onglet avec la liste des événements de déploiement. + +{{< img src="delivery_performance/dora_metrics/deployments_list.png" alt="La répartition des déploiements affichant une ventilation des métriques et une liste des événements associés" style="width:100%;" >}} + +Cliquez sur {{< ui >}}View Change Failures{{< /ui >}} pour ouvrir un panneau latéral contenant la liste des événements de déploiement marqués comme échecs de changement. + +{{< img src="delivery_performance/dora_metrics/change_failures_list.png" alt="La répartition des échecs de changement affichant une ventilation des métriques et une liste des événements associés" style="width:100%;" >}} + +## Utilisez les données de DORA Metrics {#use-dora-metrics-data} + +### Exportez les widgets DORA Metrics {#export-dora-metrics-widgets} +Exportez vos widgets de visualisation vers des dashboards ou des notebooks. + +Cliquez sur l'icône {{< ui >}}Export{{< /ui >}} sur n'importe quelle visualisation pour l'ajouter à un dashboard ou à un notebook. Pour plus d'informations sur les métriques calculées par DORA Metrics, consultez la [documentation sur les données collectées][3]. + +### Créez des dashboards personnalisés {#create-custom-dashboards} + +Créez des dashboards personnalisés à l'aide de DORA Metrics pour analyser votre workflow de livraison de bout en bout, des commits et pull requests aux déploiements en production. Par exemple, comparez les performances de revue de code entre les équipes pour identifier celles qui sont bloquées par des approbations lentes et hiérarchisez les investissements dans l'amélioration du workflow. + +{{< img src="delivery_performance/dora_metrics/dashboard.png" alt="Un exemple de Dashboard DORA Metrics personnalisé" style="width:100%;" >}} + +Dans les dashboards et les graphiques, les tags personnalisés sont traités comme des [attributs][7]. Pour filtrer ou regrouper par un tag personnalisé, il doit être précédé d'un symbole `@`. + +{{< img src="delivery_performance/dora_metrics/graph_with_custom_tag.png" alt="Un exemple de graphique DORA Metrics personnalisé regroupé par un tag personnalisé" style="width:100%;" >}} + +## Pour aller plus loin {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://www.datadoghq.com/knowledge-center/dora-metrics/ +[2]: /fr/delivery_performance/dora_metrics/setup/ +[3]: /fr/delivery_performance/dora_metrics/data_collected/ +[4]: https://app.datadoghq.com/ci/dora +[5]: /fr/monitors/types/metric/?tab=threshold +[6]: /fr/monitors/ +[7]: /fr/dashboards/guide/quick-graphs/#graphing-events +[8]: /fr/delivery_performance/dora_metrics/data_collected/#custom-tags \ No newline at end of file diff --git a/hugo/content/fr/delivery_performance/dora_metrics/change_failure_detection/_index.md b/hugo/content/fr/delivery_performance/dora_metrics/change_failure_detection/_index.md new file mode 100644 index 00000000000..be39ac990b0 --- /dev/null +++ b/hugo/content/fr/delivery_performance/dora_metrics/change_failure_detection/_index.md @@ -0,0 +1,195 @@ +--- +aliases: +- /fr/dora_metrics/change_failure_detection/ +description: Apprenez à configurer la détection des échecs de changement dans DORA + Metrics à l'aide de restaurations, de PR de réversion et de filtres de PR personnalisés. +further_reading: +- link: /delivery_performance/dora_metrics/ + tag: Documentation + text: En savoir plus sur DORA Metrics +- link: /delivery_performance/dora_metrics/setup/ + tag: Documentation + text: Configurer des sources de données pour DORA Metrics +title: Détection des échecs de changement +--- +{{< jqmath-vanilla >}} + +## Présentation {#overview} + +La détection des échecs de changement de Datadog identifie automatiquement les déploiements qui corrigent des déploiements ayant précédemment échoué. En associant les échecs de changement aux déploiements de remédiation, elle fournit une vue complète de la performance de livraison, aidant les équipes à équilibrer la vitesse de publication et la stabilité opérationnelle. + +Un **échec de changement** est un déploiement qui cause des problèmes en production et nécessite une remédiation. Les échecs de changement sont utilisés pour calculer les métriques suivantes : + +- [Taux d'échec de changement][2] +: Le pourcentage de déploiements causant des problèmes en production, calculé comme suit : + + $$\\text\"Taux d'échec de changement\" = \\text\"Nombre d'échecs de changement\" / \\text\"Nombre total de déploiements\"$$ + +- [Temps de récupération après un déploiement ayant échoué][3] +: La durée médiane entre un déploiement ayant échoué et sa remédiation, soit par un déploiement de restauration, soit par un déploiement en avant. + +La détection des échecs de changement identifie deux types de déploiements de remédiation : +- **Restaurations** : Détectées automatiquement lorsqu'une version précédemment déployée est redéployée +- **Déploiements en avant** : Détectés via des règles personnalisées qui correspondent à des modèles de métadonnées (tels que les PR de réversion et les étiquettes de correctifs) + + +## Restaurations {#rollbacks} + +Une restauration se produit lorsqu'une version précédemment déployée est redéployée pour rétablir le système après un changement ayant échoué ou défectueux. + +### Comment fonctionne la classification des restaurations {#how-rollback-classification-works} + +Un déploiement est classé comme une restauration lorsqu'il déploie une version qui correspond à une version précédemment déployée mais qui diffère du déploiement immédiatement précédent. + +- Si les métadonnées Git sont présentes, la correspondance est basée sur le SHA du commit. +- Si les métadonnées Git ne sont pas présentes, la correspondance est basée sur le tag de version. + +Lorsqu'une restauration est détectée, l'échec de changement est le premier déploiement après la cible de restauration (la version vers laquelle vous êtes revenu). + +### Exemple : Détection de restauration {#example-rollback-detection} + +Pour la séquence V1 → V2 → V3 → V1, la cible de restauration est la V1 originale, donc V2 est marqué comme l'échec de changement et V1 comme un déploiement de restauration. + +{{< img src="delivery_performance/dora_metrics/rollback_example.png" alt="Un exemple de déploiement de restauration détecté" style="width:100%;" >}} + +**Remarque** : Le redéploiement consécutif de la même version (par exemple, V1 → V1) n'est pas considéré comme une restauration. + +## Déploiements en avant {#rollforwards} + +Un déploiement en avant se produit lorsqu'un nouveau déploiement est effectué pour corriger ou outrepasser un changement ayant échoué ou défectueux. Contrairement aux restaurations (qui redéploient une version précédente), les déploiements en avant déploient du nouveau code pour remédier aux problèmes. Cela peut inclure des pull requests de réversion qui restaurent le comportement précédent via une nouvelle version. + +Les déploiements en avant sont détectés via des règles personnalisées qui correspondent aux modèles de métadonnées de déploiement. Les règles personnalisées sont configurées sur la [page Paramètres DORA][1]. + +## Règles personnalisées {#custom-rules} + +Vous pouvez définir des règles personnalisées pour classer automatiquement les déploiements en avant en fonction des métadonnées du dépôt ou de la version. Les règles peuvent fonctionner de deux manières : +- **Liaison des déploiements** : Associer les déploiements via des valeurs de variables partagées (par exemple, numéro de PR ou version) +- **Modèles statiques** : Associer les modèles de métadonnées sans variables (par exemple, étiquettes ou noms de branche) + +### Règles liées aux déploiements ayant échoué {#rules-linked-to-failed-deployments} + +Utilisez ces règles pour identifier les déploiements en avant qui doivent être liés à un déploiement ayant échoué précédemment. Ces règles utilisent des modèles d'expression régulière (regex) avec des variables pour faire correspondre les déploiements via des références partagées. + +Vous pouvez saisir des règles regex qui incluent l'une de ces variables : +| Variable | Description | +|---------------|-----------------------| +| `$pr_title` | Correspond aux titres de PR | +| `$pr_number` | Correspond aux numéros de PR | +| `$version` | Correspond aux tags de version | + +#### Comment fonctionne la classification basée sur les variables {#how-variable-based-classification-works} + +Lorsqu'une règle correspond à un déploiement, les actions suivantes se produisent : +1. La valeur de la variable est extraite du déploiement actuel. +2. Le système trouve le déploiement précédent avec la même valeur extraite. +3. Le déploiement actuel est marqué comme un déploiement en avant lié à ce déploiement précédent. +4. Le déploiement précédent est marqué comme l'échec de changement. + +Ces règles fonctionnent mieux lorsque le déploiement ayant échoué peut être identifié par un SHA de commit partagé, un tag de version ou une référence de PR. + +#### Exemple : Pull requests de réversion {#example-revert-pull-requests} + +Les pull requests de réversion sont un modèle de récupération courant. Par exemple, une PR intitulée `Revert "Add feature X"` fait référence à la PR originale. + +``` +Revert "$pr_title" +``` + +Lorsqu'un titre de PR correspond à ce modèle, les actions suivantes se produisent : +1. Le système extrait le titre de la PR originale de la PR d'annulation (la valeur de `$pr_title`). +2. Il trouve le déploiement précédent qui inclut ce titre de PR original. +3. Le déploiement actuel (avec l'annulation) est marqué comme un déploiement en avant. +4. Le déploiement précédent est marqué comme l'échec de changement. + +**Remarque** : Si la PR d'origine n'est trouvée dans aucun déploiement antérieur, ou si la PR d'origine et son annulation se trouvent dans le même déploiement, aucune classification n'est appliquée. + +### Règles statiques {#static-rules} + +Les règles statiques classent les déploiements en avant en fonction de modèles de métadonnées sans utiliser de variables. Ces règles correspondent à des indicateurs généraux de remédiation. + +Vous pouvez définir des règles regex qui correspondent à des types spécifiques de métadonnées. Le tableau suivant présente quelques exemples de modèles que vous pouvez utiliser, mais vous pouvez les ajuster pour les adapter à vos processus : + +| Type de métadonnée | Exemple de modèle Regex | Description | +|------------------|------------------------|-------------------------------------| +| **Titre de PR** | `.*rollforward.*` | Correspond aux titres de PR contenant `rollforward` | +| **Étiquette de PR** | `.*hotfix.*` | Correspond aux étiquettes de PR contenant `hotfix` | +| **Nom de branche de PR** | `recovery/.*` | Correspond aux noms de branche commençant par `recovery/`| +| **Message de commit** | `^Revert ".*"$ ` | Correspond aux messages de commit commençant par `Revert` et se terminant par `"`| +| **Tag de version** | `.*_hotfix` | Correspond aux tags de version se terminant par `_hotfix` | + +#### Fonctionnement de la classification par règles statiques {#how-static-rule-classification-works} + +Lorsqu'une règle statique correspond à un déploiement, les actions suivantes se produisent : +1. Le déploiement actuel est marqué comme un déploiement en avant. +2. Le déploiement immédiatement précédent est marqué comme étant l'échec de changement. + +Utilisez des règles statiques pour des indicateurs de remédiation généraux tels que les étiquettes de correctifs, les préfixes de branche ou les conventions de tags de version. + + +### Règles par défaut {#default-rules} + +Datadog fournit des règles par défaut qui sont automatiquement activées : + +- **PR d'annulation** : les titres de PR respectant les conventions de nommage d'annulation (par exemple, « Revert » faisant référence à une PR précédente) sont traités comme des déploiements en avant. Le déploiement précédent contenant le changement initial est marqué comme l'échec de changement, en utilisant les règles de liaison basées sur des variables décrites ci-dessus. +- **Indicateurs de correctif (hotfix)** : les étiquettes, titres ou noms de branche de PR contenant « hotfix » sont traités comme des déploiements en avant, le déploiement précédent étant marqué comme l'échec de changement. + +Ces règles par défaut sont entièrement configurables sur la page [Paramètres des métriques DORA][1]. Elles sont conçues comme des points de départ orientés qui interprètent les signaux courants comme une activité probable de déploiements en avant. Vous devez adapter les modèles (tels que les conventions de nommage, les étiquettes ou les tags de version) selon vos besoins pour refléter vos propres workflows et améliorer la précision au fil du temps. + +## Mettre à jour le statut du déploiement {#update-deployment-status} + +Bien que la détection automatique et les règles personnalisées gèrent la plupart des cas, vous pouvez toujours mettre à jour manuellement le statut d'un déploiement pour le marquer comme un échec de changement ou marquer un échec de changement comme stable. + +### Quand mettre à jour le statut du déploiement {#when-to-update-deployment-status} + +Envisagez de mettre à jour manuellement le statut d'un déploiement dans les scénarios suivants : +- Un déploiement a causé des problèmes en production mais n'a pas été détecté comme un échec de changement. +- Un déploiement a été classé à tort comme un échec de changement (faux positif). +- Vous devez immédiatement mettre à jour le statut approprié à des fins de rapport. + +### Mettre à jour le statut via l'API {#update-status-through-the-api} + +Utilisez l'[API DORA Metrics][4] pour mettre à jour le statut d'un déploiement par programmation. L'exemple suivant marque un déploiement comme un échec de changement et le lie à une remédiation par restauration : + +```shell +curl -X PATCH "https://api.datadoghq.com/api/v2/dora/deployment/{deployment_id}" \ +-H "Accept: application/json" \ +-H "Content-Type: application/json" \ +-H "DD-API-KEY: ${DD_API_KEY}" \ +-d @- << EOF +{ + "data": { + "attributes": { + "change_failure": true, + "remediation": { + "id": "eG42zNIkVjM", + "type": "rollback" + } + }, + "id": "z_RwVLi7v4Y", + "type": "dora_deployment_patch_request" + } +} +EOF +``` + +Le champ `remediation` est facultatif, mais requis pour calculer le temps de récupération d'un déploiement ayant échoué. + +### Mettre à jour le statut via l'interface utilisateur {#update-status-through-the-ui} + +Pour mettre à jour le statut d'un déploiement depuis l'interface utilisateur Datadog : + +1. Accédez à {{< ui >}}Software Delivery{{< /ui >}} > {{< ui >}}DORA Metrics{{< /ui >}} et cliquez sur [{{< ui >}}View Deployments{{< /ui >}}][5]. +2. Cliquez sur un déploiement pour ouvrir le panneau des détails du déploiement. +3. Dans le panneau des détails du déploiement, sélectionnez {{< ui >}}Deployment status{{< /ui >}} dans la liste déroulante pour marquer le déploiement comme ayant échoué ou étant stable. + +{{< img src="delivery_performance/dora_metrics/deployment_status_update.mp4" alt="Mise à jour du statut d'échec de changement d'un déploiement depuis l'interface utilisateur Datadog" video="true" >}} + +## Pour aller plus loin {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://app.datadoghq.com/ci/settings/dora +[2]: /fr/delivery_performance/dora_metrics/calculation/#change-failure-rate +[3]: /fr/delivery_performance/dora_metrics/calculation/#failed-deployment-recovery-time +[4]: /fr/api/latest/dora-metrics/#patch-a-deployment-event +[5]: https://app.datadoghq.com/ci/dora?detail=deployments \ No newline at end of file diff --git a/hugo/content/fr/deployment_gates/setup/jit.md b/hugo/content/fr/deployment_gates/setup/jit.md new file mode 100644 index 00000000000..eaef77b41a2 --- /dev/null +++ b/hugo/content/fr/deployment_gates/setup/jit.md @@ -0,0 +1,723 @@ +--- +description: Évaluez les portes de déploiement en envoyant des règles inline dans + la demande d’évaluation — aucune porte n’a besoin d’exister dans Datadog au préalable. +further_reading: +- link: /deployment_gates/setup/preconfigured + tag: Documentation + text: Configurez des portes de déploiement préconfigurées +- link: /deployment_gates/explore + tag: Documentation + text: En savoir plus sur l'explorer de portes de déploiement +- link: /api/latest/deployment-gates + tag: Référence API + text: Référence de l'API des portes de déploiement +title: Configurer des portes de déploiement Just-In-Time (JIT) +--- +{{< callout url="http://datadoghq.com/product-preview/deployment-gates" >}} +Les portes de déploiement sont en préversion. Si cette fonctionnalité vous intéresse, remplissez le formulaire pour demander l'accès. +{{< /callout >}} + +Avec les portes de déploiement **Just-In-Time (JIT)**, les règles sont définies en ligne dans la demande d'évaluation. Aucune porte n'a besoin d'exister au préalable dans Datadog, ce qui rend le JIT idéal pour les règles en tant que code et la flexibilité par déploiement. + +Vous recherchez des portes persistantes gérées dans l'interface utilisateur, l'API ou Terraform de Datadog ? Consultez [Portes de déploiement préconfigurées][5]. + +## Configuration {#configuration} + +Exemple `configuration` : + +```json +{ + "configuration": { + "dry_run": false, + "rules": [ + { + "type": "monitor", + "name": "Service monitors", + "options": { + "query": "service:transaction-backend env:production", + "duration": 300 + } + } + ] + } +} +``` + +Champs de haut niveau : + +- `rules` (obligatoire) : Une ou plusieurs entrées de règle. Toutes les règles doivent être validées pour que la porte soit validée. +- `dry_run` (facultatif) : Lorsque `true`, la porte renvoie toujours `pass` via l'API tandis que le résultat réel est enregistré dans l'interface utilisateur. Utile pour l'intégration. Consultez [Recommandation pour une première intégration](#recommendation-for-first-time-onboarding). + +Chaque règle possède ces champs : + +- `type` (obligatoire) : Le type de règle, `monitor` ou `faulty_deployment_detection`. Consultez [Types de règles](#rule-types) pour savoir ce que chacun évalue. +- `name` (requis) : Une étiquette lisible par l'homme qui apparaît sur la page [Évaluations des portes de déploiement][6]. +- `options` (requis) : Paramètres spécifiques à la règle ; consultez [Types de règles](#rule-types). +- `dry_run` (optionnel) : Remplacement de simulation par règle. Remplace le `dry_run` au niveau de la porte. + +## Types de règles {#rule-types} + +Pour le schéma complet et toutes les options disponibles, consultez la [référence de l'API des portes de déploiement][4]. + +{{< tabs >}} +{{% tab "Monitor" %}} +La règle Monitor évalue l'état d'un ensemble de monitors sur une période configurable. Elle échoue si, à tout moment pendant la période d'évaluation : + +- Aucun moniteur ne correspond à la requête. +- Plus de 50 moniteurs correspondent à la requête. +- Tout monitor correspondant est dans l'état `ALERT` ou `NO_DATA`. + +**Options** : + +- `query` : La requête de recherche de monitor, basée sur la [syntaxe de recherche de monitor][1]. Filtrer sur les tags de monitor : + - Tags statiques de monitor : `service:transaction-backend` + - Tags dans la requête du monitor : `scope:"service:transaction-backend"` + - Tags dans un [regroupement de monitors][2] : `group:"service:transaction-backend"` +- `duration` : La période de temps (en secondes) pendant laquelle les moniteurs correspondants sont évalués. La valeur par défaut est 0 (les moniteurs sont évalués instantanément). Le maximum est de 7200 secondes (2 heures). + +Exemple de règle en ligne : + +```json +{ + "type": "monitor", + "name": "Service monitors", + "options": { + "query": "service:transaction-backend env:production", + "duration": 300 + } +} +``` + +**Remarques** : +- `group`Les filtres évaluent uniquement les groupes correspondants. +- Les moniteurs mis en sourdine sont automatiquement exclus de l'évaluation (la requête inclut toujours `muted:false`). + +[1]: /fr/monitors/manage/search/ +[2]: /fr/monitors/manage/#triggered-monitors +{{% /tab %}} +{{% tab "Détection de déploiement défectueux APM" %}} +Ce type de règle utilise l'analyse [Détection de déploiement défectueux APM][1] de Watchdog pour comparer la version déployée aux versions précédentes du même service. L'analyse détecte : + +- De nouveaux types d'erreurs. +- Des augmentations significatives des taux d'erreur par rapport aux versions précédentes. + +L'analyse est effectuée automatiquement pour tous les services instrumentés par APM, et aucune configuration préalable n'est requise. + +**Options** : + +- `duration` : La période de temps (en secondes) pendant laquelle l'analyse s'exécute. Pour une confiance optimale dans l'analyse, cette valeur doit être d'au moins 900 secondes (15 minutes) après le début d'un déploiement. Le maximum est de 7200 secondes (2 heures). +- `allowed_resources` (facultatif) : [Ressources APM][2] à inclure dans l'analyse. Lorsqu'elles sont spécifiées, seules les ressources listées sont analysées. Mutuellement exclusif avec `excluded_resources`. +- `excluded_resources` (facultatif) : [Ressources APM][2] à ignorer (telles que les points de terminaison à faible volume ou à faible priorité). Mutuellement exclusif avec `allowed_resources`. + +Exemple de règle en ligne : + +```json +{ + "type": "faulty_deployment_detection", + "name": "APM Faulty Deployment Detection", + "options": { + "duration": 900, + "excluded_resources": ["GET /healthcheck"] + } +} +``` + +**Remarques** : +- La règle est évaluée pour chaque valeur de [tag principal supplémentaire][3] ainsi que pour une analyse globale. Pour ne prendre en compte qu'un seul tag principal, spécifiez-le comme `primary_tag` dans les attributs de la requête. +- De nouvelles erreurs et des augmentations du taux d'erreur sont détectées au niveau de la ressource. +- Ce type de règle ne prend pas en charge les services marqués comme `database` ou `inferred service`. + +[1]: /fr/watchdog/faulty_deployment_detection/ +[2]: /fr/tracing/services/resource_page/ +[3]: /fr/tracing/guide/setting_primary_tags_to_scope/?tab=helm#add-additional-primary-tags-in-datadog +{{% /tab %}} +{{< /tabs >}} + +## Évaluez une porte depuis votre pipeline {#evaluate-a-gate-from-your-pipeline} + +Vous pouvez demander une évaluation de porte depuis votre pipeline de déploiement de plusieurs manières. L'interface de ligne de commande `datadog-ci`, l'intégration Argo Rollouts et l'action GitHub acceptent des règles en ligne via un fichier de configuration JSON utilisant des clés en camel case (`dryRun`). Les appels API directs et le script générique envoient la même configuration dans la charge utile de la requête en utilisant des clés en snake case (`dry_run`), correspondant au schéma de l'API. + +{{< tabs >}} +{{% tab "Interface de ligne de commande datadog-ci" %}} +La commande [datadog-ci][1] `deployment gate` exécute l'évaluation en une seule commande. Transmettez un fichier de configuration JSON avec l'indicateur `--config` : + +```bash +datadog-ci deployment gate --service transaction-backend --env production --version 1.2.3 --config ./gate-config.json +``` + +Exemple `gate-config.json` : + +```json +{ + "dryRun": false, + "rules": [ + { + "type": "monitor", + "name": "Service monitors", + "options": { + "query": "service:transaction-backend env:production", + "duration": 300 + } + }, + { + "type": "faulty_deployment_detection", + "name": "APM Faulty Deployment Detection", + "options": { + "duration": 900, + "excluded_resources": ["GET /healthcheck"] + } + } + ] +} +``` + +La commande : + +- Envoie une requête pour démarrer l'évaluation de la porte et bloque jusqu'à ce que l'évaluation soit terminée. +- Fournit un délai d'expiration configurable pour la durée d'attente d'une évaluation. +- Dispose de tentatives automatiques intégrées en cas d'erreurs. +- Accepte `--fail-on-error` pour personnaliser le comportement en cas d'erreurs Datadog inattendues. + +La commande `deployment gate` est disponible dans les versions v3.17.0 et ultérieures de datadog-ci. L'indicateur `--config` nécessite la version v5.19.0 ou ultérieure. + +**Variables d'environnement requises** : + +- `DD_API_KEY` : Votre [clé d'API][2]. +- `DD_APP_KEY` : Votre [clé d'application][3]. +- `DD_BETA_COMMANDS_ENABLED=1` : La commande `deployment gate` est une commande de prévisualisation. + +Pour obtenir des options de configuration complètes et des exemples d'utilisation, consultez la [`deployment gate` documentation de la commande][4]. + +[1]: https://github.com/DataDog/datadog-ci +[2]: https://app.datadoghq.com/organization-settings/api-keys +[3]: https://app.datadoghq.com/organization-settings/application-keys +[4]: https://github.com/DataDog/datadog-ci/tree/master/packages/plugin-deployment#gate + +{{% /tab %}} +{{% tab "Argo Rollouts" %}} +Appelez les Deployment Gates depuis une ressource Kubernetes Argo Rollouts en créant un [AnalysisTemplate][1] ou un [ClusterAnalysisTemplate][1]. Le modèle exécute la [commande de porte de déploiement datadog-ci][7] pour interagir avec l'API Deployment Gates. + +Utilisez le modèle ci-dessous comme point de départ : + +- Remplacez `` par votre [nom de site Datadog][2] (par exemple, {{< region-param key="dd_site" code="true" >}}). +- Définissez la [clé d'API][5] et la [clé d'application][6] en tant que variables d'environnement. L'exemple utilise un [Secret Kubernetes][3] nommé `datadog` avec deux valeurs de données : `api-key` et `app-key`. Vous pouvez également transmettre les valeurs en texte brut avec `value` au lieu de `valueFrom`. +- Utilisez une version de l'image datadog-ci qui prend en charge l'indicateur `--config` (version v5.19.0 ou supérieure). + +Stockez la configuration de la porte dans une ConfigMap, puis montez-la dans le job et transmettez `--config` à l'interface de ligne de commande : + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: gate-config +data: + gate-config.json: | + { + "dryRun": false, + "rules": [ + { + "type": "monitor", + "name": "Service monitors", + "options": { + "query": "service:transaction-backend env:production", + "duration": 300 + } + }, + { + "type": "faulty_deployment_detection", + "name": "APM Faulty Deployment Detection", + "options": { + "duration": 900, + "excluded_resources": ["GET /healthcheck"] + } + } + ] + } +--- +apiVersion: argoproj.io/v1alpha1 +kind: ClusterAnalysisTemplate +metadata: + name: datadog-job-analysis +spec: + args: + - name: service + - name: env + - name: version + metrics: + - name: datadog-job + provider: + job: + spec: + ttlSecondsAfterFinished: 300 + backoffLimit: 0 + template: + spec: + restartPolicy: Never + containers: + - name: datadog-check + image: datadog/ci:latest + env: + - name: DD_BETA_COMMANDS_ENABLED + value: "1" + - name: DD_SITE + value: "" + - name: DD_API_KEY + valueFrom: + secretKeyRef: + name: datadog + key: api-key + - name: DD_APP_KEY + valueFrom: + secretKeyRef: + name: datadog + key: app-key + command: ["/bin/sh", "-c"] + args: + - datadog-ci deployment gate --service {{ args.service }} --env {{ args.env }} --version {{ args.version }} --config /etc/datadog/gate-config.json + volumeMounts: + - name: gate-config + mountPath: /etc/datadog + volumes: + - name: gate-config + configMap: + name: gate-config +``` + +- Le modèle d'analyse peut recevoir des arguments de la ressource Rollout (`service`, `env`, `version`). Pour plus d'informations, consultez la [documentation officielle d'Argo Rollouts][4]. +- `ttlSecondsAfterFinished` supprime les jobs terminés après 5 minutes. +- `backoffLimit` est défini sur 0 car le job ne doit pas être relancé si l'évaluation de la porte échoue. + +Après avoir créé le modèle d'analyse, référencez-le depuis la stratégie Argo Rollouts : + +```yaml +apiVersion: argoproj.io/v1alpha1 +kind: Rollout +metadata: + name: rollouts-demo + labels: + tags.datadoghq.com/service: transaction-backend + tags.datadoghq.com/env: dev +spec: + replicas: 5 + strategy: + canary: + steps: + ... + - analysis: + templates: + - templateName: datadog-job-analysis + clusterScope: true # Only needed for cluster analysis + args: + - name: env + valueFrom: + fieldRef: + fieldPath: metadata.labels['tags.datadoghq.com/env'] + - name: service + valueFrom: + fieldRef: + fieldPath: metadata.labels['tags.datadoghq.com/service'] + - name: version #Required for APM Faulty Deployment Detection rules + valueFrom: + fieldRef: + fieldPath: metadata.labels['tags.datadoghq.com/version'] + - ... +``` + +[1]: https://argo-rollouts.readthedocs.io/en/stable/features/analysis/#analysis-progressive-delivery +[2]: /fr/getting_started/site/ +[3]: https://kubernetes.io/docs/concepts/configuration/secret/ +[4]: https://argo-rollouts.readthedocs.io/en/stable/features/analysis/#analysis-template-arguments +[5]: https://app.datadoghq.com/organization-settings/api-keys +[6]: https://app.datadoghq.com/organization-settings/application-keys +[7]: https://github.com/DataDog/datadog-ci/tree/master/packages/plugin-deployment#gate + +{{% /tab %}} +{{% tab "GitHub Actions" %}} +L'[action GitHub Datadog Deployment Gate][4] exécute l'évaluation dans le cadre d'un workflow. Validez un fichier de configuration de porte dans le dépôt et transmettez son chemin avec l'entrée `config`. L'entrée `config` nécessite la version v2.1.0 ou supérieure : + +```yaml +name: Deploy with Datadog Deployment Gate +on: + push: + branches: [main] +jobs: + deploy: + runs-on: ubuntu-latest + steps: + - name: Checkout + uses: actions/checkout@v5 + + - name: Deploy Canary + run: | + echo "Deploying canary release for service:'my-service' in 'production'. Version 1.0.1" + # Your deployment commands here + + - name: Evaluate Deployment Gate + uses: DataDog/deployment-gate-github-action@v2.1.0 + env: + DD_API_KEY: ${{ secrets.DD_API_KEY }} + DD_APP_KEY: ${{ secrets.DD_APP_KEY }} + with: + service: my-service + env: production + version: 1.0.1 + config: .github/gate-config.json + + - name: Deploy + run: | + echo "Deployment Gate passed, proceeding with deployment" + # Your deployment commands here +``` + +Exemple `.github/gate-config.json` : + +```json +{ + "dryRun": false, + "rules": [ + { + "type": "monitor", + "name": "Service monitors", + "options": { + "query": "service:my-service env:production", + "duration": 300 + } + }, + { + "type": "faulty_deployment_detection", + "name": "APM Faulty Deployment Detection", + "options": { + "duration": 900, + "excluded_resources": ["GET /healthcheck"] + } + } + ] +} +``` + +L'action : + +- Envoie une requête pour démarrer l'évaluation de la porte et bloque jusqu'à ce que l'évaluation soit terminée. +- Fournit un délai d'expiration configurable pour la durée d'attente d'une évaluation. +- Dispose de tentatives automatiques intégrées en cas d'erreurs. +- Accepte `fail-on-error` pour personnaliser le comportement en cas d'erreurs Datadog inattendues. + +**Variables d'environnement requises** : + +- `DD_API_KEY` : Votre [clé d'API][2]. +- `DD_APP_KEY` : Votre [clé d'application][3]. + +Pour des options de configuration complètes et des exemples d'utilisation, consultez le [`DataDog/deployment-gate-github-action` dépôt][4]. + +[1]: https://github.com/DataDog/datadog-ci +[2]: https://app.datadoghq.com/organization-settings/api-keys +[3]: https://app.datadoghq.com/organization-settings/application-keys +[4]: https://github.com/DataDog/deployment-gate-github-action + +{{% /tab %}} +{{% tab "Script générique" %}} + +Utilisez ce script comme point de départ. Il évalue un gate en utilisant des règles JIT inline. + +Remplacez ce qui suit : + +- `` : Votre [nom du site Datadog][1] (par exemple, {{< region-param key="dd_site" code="true" >}}) +- `` : Votre [clé d'API][2] +- `` : Votre [clé d'application][3] + +```bash +#!/bin/sh + +# Configuration +MAX_RETRIES=3 +DELAY_SECONDS=5 +POLL_INTERVAL_SECONDS=15 +MAX_POLL_TIME_SECONDS=10800 # 3 hours +API_URL="https://api./api/v2/deployments/gates/evaluation" +API_KEY="" +APP_KEY="" + +PAYLOAD=$(cat <` : Votre [nom du site Datadog][1] (par exemple, {{< region-param key="dd_site" code="true" >}}) +- `` : Votre [clé d'API][2] +- `` : Votre [clé d'application][3] + +Transmettez `configuration` avec des règles en ligne (snake_case à la limite de l'API) : + +```bash +curl -X POST "https://api./api/v2/deployments/gates/evaluation" \ +-H "Content-Type: application/json" \ +-H "DD-API-KEY: " \ +-H "DD-APPLICATION-KEY: " \ +-d @- << 'EOF' +{ + "data": { + "type": "deployment_gates_evaluation_request", + "attributes": { + "service": "transaction-backend", + "env": "production", + "version": "1.2.3", + "configuration": { + "dry_run": false, + "rules": [ + { + "type": "monitor", + "name": "Service monitors", + "options": { + "query": "service:transaction-backend env:production", + "duration": 300 + } + }, + { + "type": "faulty_deployment_detection", + "name": "APM Faulty Deployment Detection", + "options": { + "duration": 900, + "excluded_resources": ["GET /healthcheck"] + } + } + ] + } + } + } +} +EOF +``` + +Si l'évaluation Deployment Gate a été lancée avec succès, un code d'état HTTP 202 est renvoyé : + +```json +{ + "data": { + "id": "", + "type": "deployment_gates_evaluation_response", + "attributes": { + "evaluation_id": "e9d2f04f-4f4b-494b-86e5-52f03e10c8e9" + } + } +} +``` + +Le champ `data.attributes.evaluation_id` contient l'identifiant unique de cette évaluation Deployment Gate. + +Récupérez le statut d'une évaluation Deployment Gate en interrogeant l'endpoint de statut avec l'identifiant d'évaluation : + +```bash +curl -X GET "https://api./api/v2/deployments/gates/evaluation/" \ +-H "DD-API-KEY: " \ +-H "DD-APPLICATION-KEY: " +``` + +**Remarque** : Si vous appelez cet endpoint trop tôt après avoir demandé l'évaluation, une réponse HTTP 404 peut être renvoyée car l'évaluation n'a pas encore commencé. Réessayez quelques secondes plus tard. + +Lorsqu'une réponse HTTP 200 est renvoyée, elle présente le format suivant : + +```json +{ + "data": { + "id": "", + "type": "deployment_gates_evaluation_result_response", + "attributes": { + "dry_run": false, + "evaluation_id": "e9d2f04f-4f4b-494b-86e5-52f03e10c8e9", + "evaluation_url": "https://app.datadoghq.com/ci/deployment-gates/evaluations?index=cdgates&query=level%3Agate+%40evaluation_id%3Ae9d2f04f-4f4b-494b-86e5-52f03e10c8e9", + "gate_id": "e140302e-0cba-40d2-978c-6780647f8f1c", + "gate_status": "pass", + "rules": [ + { + "name": "Service monitors", + "status": "fail", + "reason": "One or more monitors in ALERT state: https://app.datadoghq.com/monitors/34330981", + "dry_run": false + } + ] + } + } +} +``` + +Le champ `data.attributes.gate_status` contient le résultat de l'évaluation, avec l'une de ces valeurs : + +- `in_progress` : L'évaluation Deployment Gate est toujours en cours ; continuez à interroger. +- `pass` : L'évaluation Deployment Gate a réussi. +- `fail` : L'évaluation Deployment Gate a échoué. + +**Remarque** : Si le champ `data.attributes.dry_run` est `true`, le champ `data.attributes.gate_status` est toujours `pass`. + +[1]: /fr/getting_started/site/ +[2]: https://app.datadoghq.com/organization-settings/api-keys +[3]: https://app.datadoghq.com/organization-settings/application-keys + +{{% /tab %}} +{{< /tabs >}} + +## Recommandation pour la première intégration {#recommendation-for-first-time-onboarding} + +Lors de l'intégration des portes de déploiement dans votre workflow Continuous Delivery, une phase d'évaluation aide à confirmer que le produit fonctionne comme prévu avant qu'il n'impacte les déploiements. Utilisez le mode dry-run et la page [{{< ui >}}Deployment Gates Evaluations{{< /ui >}}][6] : + +1. Définissez `dry_run: true` sur le `configuration` (ou `dryRun: true` dans le fichier de configuration CLI). Pour marquer uniquement certaines règles en mode dry-run, définissez `dry_run` par règle. Une évaluation en mode dry-run renvoie toujours `pass` via l'API, mais le résultat réel est enregistré dans l'interface utilisateur. +2. Ajoutez l'évaluation Deployment Gate à votre processus de déploiement. Les déploiements ne sont pas impactés par le résultat de la Deployment Gate tant que le mode dry-run est activé. +3. Après une certaine période (par exemple, 1 à 2 semaines), vérifiez les exécutions de Deployment Gate et des règles sur la page {{< ui >}}Deployment Gates Evaluations{{< /ui >}}. L'interface utilisateur affiche le statut réel, vous permettant ainsi de voir quand la Deployment Gate aurait échoué et pour quelle raison. +4. Lorsque vous êtes certain que le comportement de la Deployment Gate est conforme à vos attentes, passez `dry_run` à `false`. Ensuite, l'API commence à renvoyer le statut réel et les déploiements commencent à être promus ou annulés en fonction du résultat de la Deployment Gate. + +## Lectures complémentaires {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[4]: /fr/api/latest/deployment-gates +[5]: /fr/deployment_gates/setup/preconfigured +[6]: https://app.datadoghq.com/ci/deployment-gates/evaluations \ No newline at end of file diff --git a/hugo/content/fr/deployment_gates/setup/preconfigured.md b/hugo/content/fr/deployment_gates/setup/preconfigured.md new file mode 100644 index 00000000000..6c48b0e5a12 --- /dev/null +++ b/hugo/content/fr/deployment_gates/setup/preconfigured.md @@ -0,0 +1,579 @@ +--- +description: Créez des barrières et des règles dans Datadog à l'avance, puis faites-y + référence par service et par environnement au moment du déploiement. +further_reading: +- link: /deployment_gates/setup/jit + tag: Documentation + text: Configurez des barrières de déploiement Just-In-Time (JIT) +- link: /deployment_gates/explore + tag: Documentation + text: En savoir plus sur l'explorer de portes de déploiement +- link: /api/latest/deployment-gates + tag: Référence API + text: Référence de l'API des portes de déploiement +title: Configurez des barrières de déploiement préconfigurées +--- +{{< callout url="http://datadoghq.com/product-preview/deployment-gates" >}} +Les portes de déploiement sont en préversion. Si cette fonctionnalité vous intéresse, remplissez le formulaire pour demander l'accès. +{{< /callout >}} + +Avec les barrières de déploiement **préconfigurées**, les barrières et les règles sont conservées dans Datadog et référencées par service et par environnement au moment de l'évaluation. Les barrières préconfigurées sont adaptées lorsque vous souhaitez partager des règles entre plusieurs déploiements, gérer la configuration dans Terraform ou permettre à des utilisateurs n'utilisant pas la CI de modifier les règles dans l'interface utilisateur Datadog. + +Vous cherchez à définir des règles en ligne dans votre configuration de déploiement ? Consultez [Barrières de déploiement Just-In-Time (JIT)][5]. + +## Créer une barrière {#create-a-gate} + +
En plus d'utiliser l'interface utilisateur des barrières de déploiement, vous pouvez gérer les barrières et les règles par programmation avec l'API des barrières de déploiement ou le fournisseur Terraform Datadog.
+ +1. Accédez à [{{< ui >}}Software Delivery{{< /ui >}} > {{< ui >}}Deployment Gates{{< /ui >}} > {{< ui >}}Configuration{{< /ui >}}][6]. +2. Cliquez sur {{< ui >}}Create Gate{{< /ui >}}. +3. Configurez les paramètres suivants : + - {{< ui >}}Service{{< /ui >}} : Le nom du service (exemple : `transaction-backend`). + - {{< ui >}}Environment{{< /ui >}} : L'environnement cible (exemple : `dev`). + - {{< ui >}}Identifier{{< /ui >}} (facultatif, la valeur par défaut est `default`) : Nom unique pour plusieurs barrières sur le même service/environnement. Utilisez ceci pour : + - Autoriser différentes stratégies de déploiement (exemple : `fast-deploy` vs `default`) + - Distinguer les phases de déploiement (exemple : `pre-deploy` vs `post-deploy`) + - Définir des phases de Canary (exemple : `pre-deploy` vs `canary-20pct`) + - {{< ui >}}Evaluation Mode{{< /ui >}} : Activez {{< ui >}}Dry Run{{< /ui >}} pour tester le comportement de la barrière sans impacter les déploiements. L'évaluation d'une barrière en mode Dry Run répond toujours par un statut de réussite, mais le résultat dans l'application reflète l'évaluation réelle. Ceci est utile lors de l'exécution d'une évaluation initiale du comportement de la barrière sans impacter le pipeline de déploiement. + +## Ajouter des règles à une barrière {#add-rules-to-a-gate} + +Chaque barrière nécessite une ou plusieurs règles pour être évaluée. Toutes les règles doivent réussir pour que la barrière réussisse. Pour chaque règle, spécifiez : + +1. {{< ui >}}Name{{< /ui >}} : Une étiquette descriptive qui apparaît sur la page [Évaluations des barrières de déploiement][7] (par exemple, `Check all P0 monitors`). +2. {{< ui >}}Type{{< /ui >}} : Sélectionnez {{< ui >}}Monitor{{< /ui >}} ou {{< ui >}}Faulty Deployment Detection{{< /ui >}}. +3. Paramètres supplémentaires basés sur le type de règle sélectionné. Consultez [Types de règles](#rule-types) pour connaître les options disponibles. +4. {{< ui >}}Evaluation Mode{{< /ui >}}: Lorsqu'une règle est définie comme {{< ui >}}Dry Run{{< /ui >}}, son résultat n'est pas pris en compte lors du calcul du résultat global de la porte. + +## Types de règles {#rule-types} + +Pour le schéma complet et toutes les options disponibles, consultez la [référence de l'API des portes de déploiement][4]. + +{{< tabs >}} +{{% tab "Monitor" %}} +La règle Monitor évalue l'état d'un ensemble de monitors sur une période configurable. Elle échoue si, à tout moment pendant la période d'évaluation : + +- Aucun monitor ne correspond à la requête. +- Plus de 50 monitors correspondent à la requête. +- Tout monitor correspondant est dans l'état `ALERT` ou `NO_DATA`. + +##### Paramètres de configuration {#configuration-settings} + +- {{< ui >}}Search Query{{< /ui >}}: La requête utilisée pour trouver les monitors à évaluer, basée sur la [syntaxe de recherche de monitor][1]. Filtrer sur les tags de monitor : + - Tags statiques de monitor : `service:transaction-backend` + - Tags dans la requête du monitor : `scope:"service:transaction-backend"` + - Tags dans un [regroupement de monitors][2] : `group:"service:transaction-backend"` +- {{< ui >}}Duration{{< /ui >}}: La période de temps (en secondes) pendant laquelle les monitors correspondants sont évalués. La valeur par défaut est 0 (les monitors sont évalués instantanément). Le maximum est de 7200 secondes (2 heures). + +##### Exemples de requêtes {#example-queries} + +- `env:prod service:transaction-backend` +- `env:prod (service:transaction-backend OR group:"service:transaction-backend" OR scope:"service:transaction-backend")` +- `tag:"use_deployment_gates" team:payment` +- `tag:"use_deployment_gates" AND (NOT group:("team:frontend"))` + +**Remarques** : +- `group`Les filtres évaluent uniquement les groupes correspondants. +- Les monitors mis en sourdine sont automatiquement exclus de l'évaluation (la requête inclut toujours `muted:false`). + +[1]: /fr/monitors/manage/search/ +[2]: /fr/monitors/manage/#triggered-monitors +{{% /tab %}} +{{% tab "Détection de déploiement défectueux APM" %}} +Ce type de règle utilise l'analyse [Détection de déploiement défectueux APM][1] de Watchdog pour comparer la version déployée aux versions précédentes du même service. L'analyse détecte : + +- De nouveaux types d'erreurs. +- Des augmentations significatives des taux d'erreur par rapport aux versions précédentes. + +L'analyse est effectuée automatiquement pour tous les services instrumentés par APM, et aucune configuration préalable n'est requise. + +##### Paramètres de configuration {#configuration-settings-1} + +- {{< ui >}}Operation Name{{< /ui >}}: Rempli automatiquement à partir des paramètres de [l'opération principale APM][3] du service. +- {{< ui >}}Duration{{< /ui >}}: La période de temps (en secondes) pendant laquelle l'analyse s'exécute. Pour une confiance optimale dans l'analyse, cette valeur doit être d'au moins 900 secondes (15 minutes) après le début d'un déploiement. Le maximum est de 7200 secondes (2 heures). +- {{< ui >}}Allowed Resources{{< /ui >}} (facultatif) : Une liste séparée par des virgules de [ressources APM][2] à inclure dans l'analyse. Lorsqu'elles sont spécifiées, seules les ressources listées sont analysées. Mutuellement exclusif avec {{< ui >}}Excluded Resources{{< /ui >}}. +- {{< ui >}}Excluded Resources{{< /ui >}} (facultatif) : Une liste séparée par des virgules de [ressources APM][2] à ignorer (telles que les points de terminaison à faible volume ou à faible priorité). Mutuellement exclusif avec {{< ui >}}Allowed Resources{{< /ui >}}. + +**Remarques** : +- La règle est évaluée pour chaque valeur de [tag principal supplémentaire][4] ainsi que pour une analyse globale. Pour ne prendre en compte qu'un seul tag principal, spécifiez-le lors de la [demande d'évaluation de la porte](#evaluate-a-gate-from-your-pipeline). +- De nouvelles erreurs et des augmentations du taux d'erreur sont détectées au niveau de la ressource. +- Ce type de règle ne prend pas en charge les services marqués comme `database` ou `inferred service`. + +[1]: /fr/watchdog/faulty_deployment_detection/ +[2]: /fr/tracing/services/resource_page/ +[3]: /fr/tracing/guide/configuring-primary-operation/#primary-operations +[4]: /fr/tracing/guide/setting_primary_tags_to_scope/?tab=helm#add-additional-primary-tags-in-datadog +{{% /tab %}} +{{< /tabs >}} + +## Évaluez une porte depuis votre pipeline {#evaluate-a-gate-from-your-pipeline} + +Une fois la porte configurée, demandez une évaluation lors du déploiement du service associé et décidez de bloquer ou de poursuivre le déploiement en fonction du résultat. + +{{< tabs >}} +{{% tab "Interface de ligne de commande datadog-ci" %}} +La commande [datadog-ci][1] `deployment gate` exécute l'évaluation en une seule commande : + +```bash +datadog-ci deployment gate --service transaction-backend --env staging --identifier default +``` + +Si la porte de déploiement contient des règles de détection de déploiement défectueux APM, spécifiez également la version (par exemple, `--version 1.0.1`). + +La commande : + +- Envoie une requête pour démarrer l'évaluation de la porte et bloque jusqu'à ce que l'évaluation soit terminée. +- Fournit un délai d'expiration configurable pour la durée d'attente d'une évaluation. +- Dispose de tentatives automatiques intégrées en cas d'erreurs. +- Accepte `--fail-on-error` pour personnaliser le comportement en cas d'erreurs Datadog inattendues. + +La commande `deployment gate` est disponible dans les versions v3.17.0 et ultérieures de datadog-ci. + +**Variables d'environnement requises** : + +- `DD_API_KEY` : Votre [clé d'API][2]. +- `DD_APP_KEY` : Votre [clé d'application][3]. +- `DD_BETA_COMMANDS_ENABLED=1`: La commande `deployment gate` est une commande bêta. + +Pour obtenir des options de configuration complètes et des exemples d'utilisation, consultez la [`deployment gate` documentation de la commande][4]. + +[1]: https://github.com/DataDog/datadog-ci +[2]: https://app.datadoghq.com/organization-settings/api-keys +[3]: https://app.datadoghq.com/organization-settings/application-keys +[4]: https://github.com/DataDog/datadog-ci/tree/master/packages/plugin-deployment#gate + +{{% /tab %}} +{{% tab "Argo Rollouts" %}} +Appelez les Deployment Gates depuis une ressource Kubernetes Argo Rollouts en créant un [AnalysisTemplate][1] ou un [ClusterAnalysisTemplate][1]. Le modèle exécute la [commande de porte de déploiement datadog-ci][7] pour interagir avec l'API Deployment Gates. + +Utilisez le modèle ci-dessous comme point de départ : + +- Remplacez `` par votre [nom de site Datadog][2] (par exemple, {{< region-param key="dd_site" code="true" >}}). +- Définissez la [clé d'API][5] et la [clé d'application][6] en tant que variables d'environnement. L'exemple utilise un [Secret Kubernetes][3] nommé `datadog` avec deux valeurs de données : `api-key` et `app-key`. Vous pouvez également transmettre les valeurs en texte brut avec `value` au lieu de `valueFrom`. + +```yaml +apiVersion: argoproj.io/v1alpha1 +kind: ClusterAnalysisTemplate +metadata: + name: datadog-job-analysis +spec: + args: + - name: service + - name: env + metrics: + - name: datadog-job + provider: + job: + spec: + ttlSecondsAfterFinished: 300 + backoffLimit: 0 + template: + spec: + restartPolicy: Never + containers: + - name: datadog-check + image: datadog/ci:v3.17.0 + env: + - name: DD_BETA_COMMANDS_ENABLED + value: "1" + - name: DD_SITE + value: "" + - name: DD_API_KEY + valueFrom: + secretKeyRef: + name: datadog + key: api-key + - name: DD_APP_KEY + valueFrom: + secretKeyRef: + name: datadog + key: app-key + command: ["/bin/sh", "-c"] + args: + - datadog-ci deployment gate --service {{ args.service }} --env {{ args.env }} --identifier default +``` + +- Le modèle d'analyse peut recevoir des arguments de la ressource Rollout (tels que `service`, `env` et `version`). Pour plus d'informations, consultez la [documentation officielle d'Argo Rollouts][4]. +- `ttlSecondsAfterFinished` supprime les jobs terminés après 5 minutes. +- `backoffLimit` est défini sur 0 car le job ne doit pas être relancé si l'évaluation de la porte échoue. + +Après avoir créé le modèle d'analyse, référencez-le depuis la stratégie Argo Rollouts : + +```yaml +apiVersion: argoproj.io/v1alpha1 +kind: Rollout +metadata: + name: rollouts-demo + labels: + tags.datadoghq.com/service: transaction-backend + tags.datadoghq.com/env: dev +spec: + replicas: 5 + strategy: + canary: + steps: + ... + - analysis: + templates: + - templateName: datadog-job-analysis + clusterScope: true # Only needed for cluster analysis + args: + - name: env + valueFrom: + fieldRef: + fieldPath: metadata.labels['tags.datadoghq.com/env'] + - name: service + valueFrom: + fieldRef: + fieldPath: metadata.labels['tags.datadoghq.com/service'] + - name: version #Required for APM Faulty Deployment Detection rules + valueFrom: + fieldRef: + fieldPath: metadata.labels['tags.datadoghq.com/version'] + - ... +``` + +[1]: https://argo-rollouts.readthedocs.io/en/stable/features/analysis/#analysis-progressive-delivery +[2]: /fr/getting_started/site/ +[3]: https://kubernetes.io/docs/concepts/configuration/secret/ +[4]: https://argo-rollouts.readthedocs.io/en/stable/features/analysis/#analysis-template-arguments +[5]: https://app.datadoghq.com/organization-settings/api-keys +[6]: https://app.datadoghq.com/organization-settings/application-keys +[7]: https://github.com/DataDog/datadog-ci/tree/master/packages/plugin-deployment#gate + +{{% /tab %}} +{{% tab "GitHub Actions" %}} +L'[action GitHub Datadog Deployment Gate][4] exécute l'évaluation dans le cadre d'un workflow. + +Ajoutez une étape `DataDog/deployment-gate-github-action` à votre workflow de déploiement existant : + +```yaml +name: Deploy with Datadog Deployment Gate +on: + push: + branches: [main] +jobs: + deploy: + runs-on: ubuntu-latest + steps: + - name: Deploy Canary + run: | + echo "Deploying canary release for service:'my-service' in 'production'. Version 1.0.1" + # Your deployment commands here + + - name: Evaluate Deployment Gate + uses: DataDog/deployment-gate-github-action@v2.1.0 + env: + DD_API_KEY: ${{ secrets.DD_API_KEY }} + DD_APP_KEY: ${{ secrets.DD_APP_KEY }} + with: + service: my-service + env: production + identifier: default + + - name: Deploy + run: | + echo "Deployment Gate passed, proceeding with deployment" + # Your deployment commands here +``` + +Si la porte de déploiement contient des règles de détection de déploiement défectueux APM, spécifiez également la version (par exemple, `version: 1.0.1`). + +L'action : + +- Envoie une requête pour démarrer l'évaluation de la porte et bloque jusqu'à ce que l'évaluation soit terminée. +- Fournit un délai d'expiration configurable pour la durée d'attente d'une évaluation. +- Dispose de tentatives automatiques intégrées en cas d'erreurs. +- Accepte `fail-on-error` pour personnaliser le comportement en cas d'erreurs Datadog inattendues. + +**Variables d'environnement requises** : + +- `DD_API_KEY` : Votre [clé d'API][2]. +- `DD_APP_KEY` : Votre [clé d'application][3]. + +Pour des options de configuration complètes et des exemples d'utilisation, consultez le [`DataDog/deployment-gate-github-action` dépôt][4]. + +[1]: https://github.com/DataDog/datadog-ci +[2]: https://app.datadoghq.com/organization-settings/api-keys +[3]: https://app.datadoghq.com/organization-settings/application-keys +[4]: https://github.com/DataDog/deployment-gate-github-action + +{{% /tab %}} +{{% tab "Script générique" %}} + +Utilisez ce script comme point de départ. Il évalue une porte préconfigurée sans règles en ligne. + +Remplacez ce qui suit : + +- `` : Votre [nom du site Datadog][1] (par exemple, {{< region-param key="dd_site" code="true" >}}) +- `` : Votre [clé d'API][2] +- `` : Votre [clé d'application][3] + +```bash +#!/bin/sh + +# Configuration +MAX_RETRIES=3 +DELAY_SECONDS=5 +POLL_INTERVAL_SECONDS=15 +MAX_POLL_TIME_SECONDS=10800 # 3 hours +API_URL="https://api./api/v2/deployments/gates/evaluation" +API_KEY="" +APP_KEY="" + +PAYLOAD=$(cat <` : Votre [nom du site Datadog][1] (par exemple, {{< region-param key="dd_site" code="true" >}}) +- `` : Votre [clé d'API][2] +- `` : Votre [clé d'application][3] + +Demandez une évaluation pour une porte qui existe déjà dans Datadog : + +```bash +curl -X POST "https://api./api/v2/deployments/gates/evaluation" \ +-H "Content-Type: application/json" \ +-H "DD-API-KEY: " \ +-H "DD-APPLICATION-KEY: " \ +-d @- << EOF +{ + "data": { + "type": "deployment_gates_evaluation_request", + "attributes": { + "service": "transaction-backend", + "env": "staging", + "identifier": "my-custom-identifier", + "version": "v123-456", + "primary_tag": "region:us-central-1" + } + } +} +EOF +``` + +Attributs facultatifs : + +- `identifier`: Facultatif, par défaut `default`. +- `version`: Requis pour les règles de détection de déploiement défectueux APM. +- `primary_tag`: Optionnel, restreint l'analyse de détection de déploiement défectueux APM au tag principal sélectionné. + +**Note** : Une réponse HTTP 404 peut signifier que la porte n'a pas été trouvée, ou que la porte a été trouvée mais ne contient aucune règle. + +Si l'évaluation Deployment Gate a été lancée avec succès, un code d'état HTTP 202 est renvoyé : + +```json +{ + "data": { + "id": "", + "type": "deployment_gates_evaluation_response", + "attributes": { + "evaluation_id": "e9d2f04f-4f4b-494b-86e5-52f03e10c8e9" + } + } +} +``` + +Le champ `data.attributes.evaluation_id` contient l'identifiant unique de cette évaluation Deployment Gate. + +Récupérez le statut d'une évaluation Deployment Gate en interrogeant l'endpoint de statut avec l'identifiant d'évaluation : + +```bash +curl -X GET "https://api./api/v2/deployments/gates/evaluation/" \ +-H "DD-API-KEY: " \ +-H "DD-APPLICATION-KEY: " +``` + +**Remarque** : Si vous appelez cet endpoint trop tôt après avoir demandé l'évaluation, une réponse HTTP 404 peut être renvoyée car l'évaluation n'a pas encore commencé. Réessayez quelques secondes plus tard. + +Lorsqu'une réponse HTTP 200 est renvoyée, elle présente le format suivant : + +```json +{ + "data": { + "id": "", + "type": "deployment_gates_evaluation_result_response", + "attributes": { + "dry_run": false, + "evaluation_id": "e9d2f04f-4f4b-494b-86e5-52f03e10c8e9", + "evaluation_url": "https://app.datadoghq.com/ci/deployment-gates/evaluations?index=cdgates&query=level%3Agate+%40evaluation_id%3Ae9d2f14f-4f4b-494b-86e5-52f03e10c8e9", + "gate_id": "e140302e-0cba-40d2-978c-6780647f8f1c", + "gate_status": "pass", + "rules": [ + { + "name": "Check service monitors", + "status": "fail", + "reason": "One or more monitors in ALERT state: https://app.datadoghq.com/monitors/34330981", + "dry_run": true + } + ] + } + } +} +``` + +Le champ `data.attributes.gate_status` contient le résultat de l'évaluation, avec l'une de ces valeurs : + +- `in_progress` : L'évaluation Deployment Gate est toujours en cours ; continuez à interroger. +- `pass` : L'évaluation Deployment Gate a réussi. +- `fail` : L'évaluation Deployment Gate a échoué. + +**Remarque** : Si le champ `data.attributes.dry_run` est `true`, le champ `data.attributes.gate_status` est toujours `pass`. + +[1]: /fr/getting_started/site/ +[2]: https://app.datadoghq.com/organization-settings/api-keys +[3]: https://app.datadoghq.com/organization-settings/application-keys + +{{% /tab %}} +{{< /tabs >}} + +## Recommandation pour la première intégration {#recommendation-for-first-time-onboarding} + +Lors de l'intégration des portes de déploiement dans votre workflow Continuous Delivery, une phase d'évaluation aide à confirmer que le produit fonctionne comme prévu avant qu'il n'impacte les déploiements. Utilisez le mode d'évaluation Dry Run et la page [{{< ui >}}Deployment Gates Evaluations{{< /ui >}}][7] : + +1. Créez une porte pour un service et réglez {{< ui >}}Evaluation Mode{{< /ui >}} sur {{< ui >}}Dry Run{{< /ui >}}. +2. Ajoutez l'évaluation Deployment Gate à votre processus de déploiement. Tant que la porte est en mode Dry Run, l'API renvoie toujours `pass` et les déploiements ne sont pas affectés par le résultat de la porte. +3. Après une certaine période (par exemple, 1 à 2 semaines), vérifiez les exécutions de Deployment Gate et des règles sur la page {{< ui >}}Deployment Gates Evaluations{{< /ui >}}. L'interface utilisateur affiche le statut réel, vous permettant ainsi de voir quand la Deployment Gate aurait échoué et pour quelle raison. +4. Lorsque vous êtes certain que le comportement de la porte est conforme à vos attentes, modifiez la porte et passez le mode d'évaluation de {{< ui >}}Dry Run{{< /ui >}} à {{< ui >}}Active{{< /ui >}}. Ensuite, l'API commence à renvoyer le statut réel et les déploiements commencent à être promus ou annulés en fonction du résultat de la Deployment Gate. + +## Pour aller plus loin {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /fr/getting_started/site/ +[2]: https://app.datadoghq.com/organization-settings/api-keys +[3]: https://app.datadoghq.com/organization-settings/application-keys +[4]: /fr/api/latest/deployment-gates +[5]: /fr/deployment_gates/setup/jit +[6]: https://app.datadoghq.com/ci/deployment-gates/gates +[7]: https://app.datadoghq.com/ci/deployment-gates/evaluations \ No newline at end of file diff --git a/hugo/content/fr/error_tracking/ticketing_systems/_index.md b/hugo/content/fr/error_tracking/ticketing_systems/_index.md new file mode 100644 index 00000000000..2a38bc67c3a --- /dev/null +++ b/hugo/content/fr/error_tracking/ticketing_systems/_index.md @@ -0,0 +1,38 @@ +--- +further_reading: +- link: /error_tracking/explorer/ + tag: Documentation + text: Prise en main de l'Error Tracking Explorer +- link: /error_tracking/issue_states/ + tag: Documentation + text: États des problèmes et workflows Error Tracking +- link: /incident_response/work_management/ + tag: Documentation + text: Work Management +is_beta: false +private: false +title: Intégrations du système de tickets Error Tracking +--- +## Présentation {#overview} + +Datadog Error Tracking s'intègre à vos workflows de tickets existants pour rationaliser la résolution des problèmes Liez les problèmes Error Tracking à des tickets Jira, des issues Linear ou des work items Work Management pour suivre et résoudre les erreurs dans vos processus établis + +Grâce aux intégrations du système de tickets, vous pouvez : + +- **Créer des tickets directement à partir des problèmes** : ouvrez des tickets Jira, des issues Linear ou des work items Work Management depuis le panneau des problèmes Error Tracking pour centraliser les efforts d'investigation +- **Regrouper plusieurs problèmes en un seul ticket** : associez plusieurs problèmes Error Tracking à un ticket ou work item, en consolidant les problèmes corrélés en une seule unité de travail +- **Automatiser la création de tickets** : configurez des règles pour créer automatiquement des tickets dans des tableaux Jira ou des projets Work Management spécifiques lorsque les issues correspondent à des critères précis + +Ces fonctionnalités aident vos équipes à réagir plus rapidement aux erreurs en comblant le fossé entre les workflows de détection d'erreurs et de résolution. + +## Mise en route {#getting-started} + +{{< whatsnext desc="Sélectionnez votre système de tickets pour commencer :" >}} + {{< nextlink href="error_tracking/ticketing_systems/jira" >}}Jira{{< /nextlink >}} + {{< nextlink href="error_tracking/ticketing_systems/linear" >}}Linear{{< /nextlink >}} + {{< nextlink href="error_tracking/ticketing_systems/work_management" >}}Work Management{{< /nextlink >}} +{{< /whatsnext >}} + +## Pour aller plus loin {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} \ No newline at end of file diff --git a/hugo/content/fr/incident_response/incident_management/setup_and_configuration/_index.md b/hugo/content/fr/incident_response/incident_management/setup_and_configuration/_index.md new file mode 100644 index 00000000000..940f17ea57d --- /dev/null +++ b/hugo/content/fr/incident_response/incident_management/setup_and_configuration/_index.md @@ -0,0 +1,46 @@ +--- +aliases: +- /fr/monitors/incident_management/notification_rules +- /fr/monitors/incident_management/incident_settings +- /fr/service_management/incident_management/incident_settings/ +- /fr/incident_response/incident_management/incident_settings +description: Configurer et personnaliser l'expérience Incident Management +title: Installation et configuration +--- +## Présentation {#overview} + +Utilisez [Incident Settings][1] pour personnaliser les aspects de l'expérience Incident Management pour l'ensemble de votre organisation. Ces paramètres vous permettent d'aligner votre utilisation d'Incident Management sur vos processus existants. + +## Types d'incidents {#incident-types} + +Les types d'incidents vous permettent d'appliquer différents paramètres à différentes classes d'incidents. La réponse à un incident de sécurité peut être très différente de la réponse à une interruption de service. Avec les types d'incidents, vous pouvez personnaliser chaque réponse. + +Pour créer un type d'incident : +1. Accédez à la page [Incidents Settings][1]. +1. Cliquez sur **Add Incident Type**. +1. Spécifiez un nom de type d'incident. +1. (Facultatif) Ajoutez une description. + +## Paramètres globaux {#global-settings} + +| Paramètre | Description | +| --- | ----------- | +| Dashboard Analytics | Personnalisez le dashboard pour le bouton [Analytics] sur la page d'accueil des incidents. Par défaut, cela renvoie au dashboard modèle Incident Management Overview pour [Analytics][1]. | +| Monitor Automations| Créez des mentions « @ » d'incident pouvant être utilisées dans un [message de notification du monitor][2] pour créer automatiquement des incidents lorsque le monitor se déclenche. | + +## Personnaliser la réponse aux incidents {#customize-incident-response} + +{{< whatsnext desc="Définissez des personnalisations supplémentaires sur les éléments suivants :">}} + {{< nextlink href="/incident_response/incident_management/setup_and_configuration/information" >}}Information{{< /nextlink >}} + {{< nextlink href="/incident_response/incident_management/setup_and_configuration/integrations" >}}Integrations{{< /nextlink >}} + {{< nextlink href="/incident_response/incident_management/post_incident/follow-ups" >}}Suivis{{< /nextlink >}} + {{< nextlink href="/incident_response/incident_management/setup_and_configuration/notification_rules" >}}Règles de notification{{< /nextlink >}} + {{< nextlink href="/incident_response/incident_management/setup_and_configuration/property_fields" >}}Champs de propriété{{< /nextlink >}} + {{< nextlink href="/incident_response/incident_management/setup_and_configuration/transition_forms" >}}Formulaires de transition{{< /nextlink >}} + {{< nextlink href="/incident_response/incident_management/setup_and_configuration/responder_types" >}}Responder Types{{< /nextlink >}} + {{< nextlink href="/incident_response/incident_management/setup_and_configuration/templates" >}}Templates{{< /nextlink >}} + {{< nextlink href="/incident_response/incident_management/setup_and_configuration/automations" >}}Automations{{< /nextlink >}} +{{< /whatsnext >}} + +[1]: https://app.datadoghq.com/incidents/settings +[2]: /fr/monitors/notify/ \ No newline at end of file diff --git a/hugo/content/fr/incident_response/incident_management/setup_and_configuration/integrations/slack/_index.md b/hugo/content/fr/incident_response/incident_management/setup_and_configuration/integrations/slack/_index.md new file mode 100644 index 00000000000..ce37d4c15b3 --- /dev/null +++ b/hugo/content/fr/incident_response/incident_management/setup_and_configuration/integrations/slack/_index.md @@ -0,0 +1,207 @@ +--- +aliases: +- /fr/service_management/incident_management/integrations/slack/ +- /fr/incident_response/incident_management/integrations/slack/ +description: Gérez les incidents Datadog directement depuis Slack. +further_reading: +- link: integrations/slack/ + tag: Documentation + text: Installez l'intégration Slack +- link: https://www.datadoghq.com/blog/slack-incident-management/ + tag: Blog + text: Gérez les incidents de manière transparente grâce à l'intégration Datadog + pour Slack. +- link: https://www.datadoghq.com/blog/datadog-incident-response-ai-features/ + tag: Blog + text: Accélérez vos investigations avec l'IA dans Datadog Incident Response. +- link: https://app.datadoghq.com/integrations/slack + tag: App + text: Tuile d'intégration Slack dans l'application +title: Intégrez Slack à Datadog Incident Management +--- +## Présentation {#overview} + +Slack est une plateforme de messagerie et de collaboration largement utilisée par les équipes pour communiquer en temps réel. L'intégration Datadog Slack connecte vos workflows de réponse aux incidents directement à Slack, afin que les équipes puissent déclarer, gérer et résoudre les incidents sans quitter leur environnement de chat. + +Avec l'intégration, vous pouvez : + +- Répondez plus rapidement en déclarant les incidents Datadog directement depuis Slack. +- Créez automatiquement des canaux Slack pour la collaboration lorsque des incidents Datadog sont déclarés. +- Exécutez votre réponse aux incidents dans Slack. Par exemple, alertez les équipes d'astreinte, assignez des rôles d'intervenant ou mettez à jour la gravité. + +La documentation de l'intégration Slack est organisée autour du cycle de vie typique de l'utilisation de Slack avec Incident Management : + +1. [**Installez et connectez Slack**](#setup) : configurez l'intégration entre votre espace de travail Slack et Datadog. +2. [**Déclarer des incidents**](#declaring-incidents-from-slack) : apprenez à démarrer des incidents en utilisant des commandes Slack ou des actions de message. +3. [**Gérer les incidents depuis les canaux d'incident**](#incident-channels) : utilisez des canaux Slack dédiés avec des commandes, la synchronisation et des automatisations. +4. [**Configurer les notifications globales**](#global-slack-notifications) : tenez votre organisation informée grâce à des mises à jour automatiques. +5. **[Référencer les options de configuration Slack](#additional-slack-configurations) et [les commandes Slack](#slack-incident-commands)** : explorez les options de configuration détaillées et consultez la liste complète des commandes Slack disponibles pour adapter et rationaliser vos workflows de réponse aux incidents. + +## Prérequis {#prerequisites} + +Installez l'intégration via la [Slack Integration tile][1] avec les [OAuth scopes][6] appropriées. Pour plus d'informations, consultez la documentation sur l'[Slack integration][2]. + +Une fois l'intégration installée, accédez à [**Incidents** > **Settings** > **Integrations**][3] pour activer les fonctionnalités Slack pour Incident Management. + +## Déclaration d'incidents depuis Slack {#declaring-incidents-from-slack} + +Lorsque vous connectez un espace de travail Slack à une organisation Datadog, les utilisateurs de l'espace de travail peuvent utiliser les raccourcis Slack liés à Incident Management. + +Vous pouvez déclarer un incident avec la commande slash suivante : + +``` +/datadog incident +``` + +Pour déclarer un incident à partir d'un message Slack, survolez le message, cliquez sur **More actions** (les trois points verticaux), puis sélectionnez **Declare incident**. Datadog publie un message dans le fil du message confirmant la création de l'incident. + +Par défaut, seuls les utilisateurs Slack connectés à une organisation Datadog peuvent déclarer des incidents. Les utilisateurs Slack peuvent se connecter à une organisation Datadog en exécutant `/datadog connect`. + +Pour permettre à tout utilisateur Slack de l'espace de travail de déclarer des incidents, activez **Allow Slack users to declare incidents without a connected Datadog account** dans les paramètres Incident Management. + +## Incident channels {#incident-channels} + +Vous pouvez configurer Incident Management pour créer automatiquement un canal Slack dédié pour chaque incident répondant aux critères que vous définissez. Vos intervenants peuvent ensuite gérer l'incident directement dans Slack depuis le canal d'incident. + +Pour utiliser les incident channels, accédez à **[Incident Response > Incident Management > Settings > Integrations][3]** et activez **Create Slack channels for incidents**. + +Le **channel name template** que vous définissez détermine comment Datadog nomme les canaux d'incident qu'il crée. Pour des descriptions complètes, consultez [Variables available only in channel name templates][7]. + + +### Message syncing (Slack mirroring) {#message-syncing-slack-mirroring} + +Après avoir activé la création automatique de canaux, vous pouvez configurer Incident Management pour synchroniser les messages entre un canal Slack d'incident et la chronologie de l'incident dans Datadog. + +Pour activer la synchronisation, activez **Push Slack channel messages to the incident timeline** dans les paramètres Incident Management, puis sélectionnez l'une des options suivantes : + +* **Mirror all messages in real-time** : Datadog synchronise tous les messages publiés par les utilisateurs Slack dans le canal d'incident. +* **Push message when 📌 is added as a reaction** : Datadog synchronise les messages uniquement lorsque les utilisateurs Slack y réagissent avec des punaises (📌). + +Pour les deux options, l'auteur d'un message n'a pas besoin d'être connecté à l'organisation Datadog pour que Datadog synchronise le message. Pour l'épinglage de messages, l'épingleur **doit** être connecté à l'organisation Datadog pour que le message épinglé soit synchronisé. + +Dans les organisations avec une facturation d'Incident Management basée sur l'utilisation : + +* La rédaction d'un message synchronisé avec Datadog ne fait **pas** de vous un utilisateur facturable pour le mois en cours. +* L'épinglage d'un message qui est ensuite synchronisé **fait** de vous un utilisateur facturable. + +Dans les organisations avec une facturation d'Incident Management basée sur le nombre d'utilisateurs : + +* Vous n'avez **pas** besoin d'une place pour que Datadog synchronise vos messages vers Incident Management. +* Lorsque vous épinglez un message, vous **devez** disposer d'une place pour que Datadog synchronise le message que vous avez épinglé. + +### Commandes Slack dans le canal d'incidents {#slack-commands-in-the-incident-channel} + +Dans un canal Slack d'incident, vous pouvez exécuter des commandes Slack pour modifier le statut et la gravité de l'incident, attribuer des rôles d'intervenant, alerter les équipes d'astreinte, et plus encore. + +Pour obtenir la liste complète des commandes Slack, consultez les [commandes Slack](#slack-commands). + +### Autres options de configuration du canal d'incidents {#other-incident-channel-configuration-options} + +Accédez à toutes les options de configuration de Slack dans Incident Management via la page [**Incidents** > **Settings** > **Integrations**][3]. + +| Fonctionnalité | Description et remarques | +|-----------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------| +| **Push incident timeline messages to Slack** | Envoie automatiquement les mises à jour de la chronologie d'incident de Datadog vers le canal Slack.

Permet aux participants du canal de rester synchronisés avec les mises à jour de Datadog. | +| **Add important links to channel bookmarks** | Publie les liens liés à l'incident dans les signets du canal Slack.

Cela permet d'accéder facilement aux ressources. | +| **Add team members automatically** | Lorsqu'une équipe Datadog est associée à l'incident, ses membres sont ajoutés au canal Slack. | +| **Send incident updates to the Slack channel** | : Met à jour le sujet du canal avec le statut, la gravité et l'incident commander. | +| **Send a Slack notification when a meeting starts** | Notifie the canal Slack lorsqu'une réunion est lancée, avec des participants et un lien pour y participer.

Offre un accès pratique aux appels d'incident. | +| **Activate Bits AI in incident Slack channels** | Active les fonctionnalités d'IA qui utilisent le contexte des incidents provenant de Datadog.

S'applique à tous les types d'incidents dans l'espace de travail Slack sélectionné. | +| **Automatically archive Slack channels after resolution** | Archive les canaux Slack dédiés aux incidents une fois ceux-ci résolus.

Cela permet de réduire l'encombrement des canaux. | +| **Customize incident Slack actions** | Personnalise les actions qui s'affichent dans la barre d'actions des incidents pour chaque statut.

Cela permet d'améliorer la visibilité des actions courantes. | + +## Global channel for incident updates {#global-channel-for-incident-updates} + +Vous pouvez configurer Incident Management pour publier automatiquement des mises à jour sur les incidents dans un canal Slack sélectionné. Pour activer ceci : + +1. Dans Datadog, accédez à **[Incident Response > Incident Management > Settings > Integrations][3]**. +1. Dans la section Slack, activez **Send all incident updates to a global channel**. +1. Sélectionnez l'espace de travail Slack et le canal Slack où vous souhaitez que les mises à jour d'incident soient publiées : + +Datadog notifie automatiquement le canal sélectionné de tout nouvel incident déclaré, ainsi que les changements de statut, de gravité et d'incident commander. + +En coulisses, cette fonctionnalité est une [incident notification rule][5] intégrée et masquée. Si vous souhaitez personnaliser le message ou ses déclencheurs, désactivez-la et définissez votre propre règle de notification. + +## Commandes Slack {#slack-commands} + +Vous pouvez consulter la liste complète des commandes Slack disponibles à tout moment en tapant `/datadog` (ou `/dd`) dans Slack pour ouvrir la fenêtre modale de commande afin de parcourir et d'exécuter toute action Datadog, ou `/dd help` pour afficher ces options sous forme de liste. Pour ouvrir le volet d'actions pour les actions courantes de gestion des incidents, tapez `/dd shortcuts`. + +### Commandes globales (exécutables partout) {#global-commands-run-anywhere} + +| Commande | Description | +| ------- | ----------- | +| `/datadog incident` | Déclarer un nouvel incident. | +| `/datadog incident test` | Déclarer un nouvel incident de test (si les incidents de test sont activés pour le type d'incident). | +| `/datadog incident list` | Lister tous les incidents ouverts (actifs et stables). | + +### Commandes du canal d'incident {#incident-channel-commands} + +{{< site-region region="us,us3,us5,eu,ap1,ap2,uk1" >}} +| Commande | Description | +| ------- | ----------- | +| `/datadog` | Ouvrez la fenêtre modale de commande pour afficher toutes les actions Datadog disponibles. | +| `/datadog shortcuts` | Ouvrez le volet d'actions d'incident pour effectuer des actions courantes. | +| `/datadog help` | Afficher un message éphémère listant toutes les commandes Slack disponibles. | +| `/datadog incident update` | Mettre à jour un attribut pour l'incident, tel que le statut ou la gravité. | +| `/datadog incident notify` | Notifier les `@`-handles concernant l'incident. | +| `/datadog incident private` | Rendre l'incident privé (si les incidents privés sont activés). | +| `/datadog incident public` | Rendre l'incident public. | +| `/datadog incident responders` | Gérer l'équipe d'intervention de l'incident (ajouter des intervenants et attribuer des rôles d'intervention). | +| `/datadog task` | Créer une tâche d'incident. | +| `/datadog task list` | Lister les tâches d'incident existantes. | +| `/datadog followup` | Créer un suivi pour l'incident. | +| `/datadog followup list` | Afficher et gérer les suivis existants pour l'incident. | +| `/datadog incident summary` | Obtenir un résumé de l'incident généré par IA qui n'est visible que par vous. | +{{< /site-region >}} +{{< site-region region="gov,gov2" >}} +| Commande | Description | +| ------- | ----------- | +| `/datadog` | Ouvrez la fenêtre modale de commande pour afficher toutes les actions Datadog disponibles. | +| `/datadog shortcuts` | Ouvrez le volet d'actions d'incident pour effectuer des actions courantes. | +| `/datadog help` | Afficher un message éphémère listant toutes les commandes Slack disponibles. | +| `/datadog incident update` | Mettre à jour un attribut pour l'incident, tel que le statut ou la gravité. | +| `/datadog incident notify` | Notifier les `@`-handles concernant l'incident. | +| `/datadog incident private` | Rendre l'incident privé (si les incidents privés sont activés). | +| `/datadog incident public` | Rendre l'incident public. | +| `/datadog incident responders` | Gérer l'équipe d'intervention de l'incident (ajouter des intervenants et attribuer des rôles d'intervention). | +| `/datadog task` | Créer une tâche d'incident. | +| `/datadog task list` | Lister les tâches d'incident existantes. | +| `/datadog followup` | Créer un suivi pour l'incident. | +| `/datadog followup list` | Afficher et gérer les suivis existants pour l'incident. | +{{< /site-region >}} + +### Boutons du volet d’actions {#action-tray-buttons} + +Datadog publie le volet d'actions directement dans le canal Slack de l'incident lors des changements de statut, afin que les intervenants puissent effectuer des actions courantes, telles que la mise à jour de la gravité ou du statut, sans avoir à taper une commande. Vous pouvez également ouvrir le volet d'actions en tapant `/dd shortcuts` dans Slack. + +Les boutons suivants sont disponibles dans le volet d'actions. Les types d'incidents sont initialisés avec ces boutons par défaut. Pour personnaliser les boutons qui apparaissent et leur ordre pour chaque statut d'incident, accédez à **Incidents** > **Settings** > [**Integrations**][3] > **Slack Settings** et configurez **Incident Slack Actions**. + +| Bouton | Description | Par défaut actif | Par défaut stable | Par défaut résolu | +|--------------------------------------|---------------------------------------------------------------------------|:---:|:---:|:---:| +| ⚙️ **Modifier l'incident** | Mettre à jour le statut, la gravité, l'impact et tous les autres attributs | {{< X >}} | {{< X >}} | | +| 🧑‍🚒 **Modifier les intervenants** | Assigner des rôles et ajouter des coéquipiers à l'incident | {{< X >}} | | | +| 🔍 **Voir toutes les actions** | Ouvrir la liste complète des actions Slack disponibles pour cet incident | {{< X >}} | {{< X >}} | {{< X >}} | +| 🏠 **View Web App** | Ouvrir l'incident dans Datadog Incident Management | {{< X >}} | {{< X >}} | {{< X >}} | +| ☎️ **Page On-Call** | Alerter une équipe au sujet de l'incident en cours en utilisant votre service préféré | {{< X >}} | | | +| 🔔 **Notify** | Notifier les parties prenantes d'un incident par e-mail, notification push ou services | | {{< X >}} | {{< X >}} | +| ▶️ **Create/Join Zoom** | Démarrer une nouvelle réunion, ou la rejoindre si elle existe déjà | {{< X >}} | | | +| ▶️ **Create/Join Google Meet** | Démarrer une nouvelle réunion, ou la rejoindre si elle existe déjà | {{< X >}} | | | +| ▶️ **Run Workflow** | Sélectionner et exécuter des workflows prédéfinis pour l'incident | {{< X >}} | | | +| 🟨 **Set to Stable** | Marquer l'incident comme stable après avoir atténué l'impact | {{< X >}} | | | +| ✅ **Resolve Incident** | Marquer l'incident comme résolu | | {{< X >}} | | +| ✨ **Investigate with Bits AI** | Utiliser Bits AI pour enquêter sur l'incident | {{< X >}} | | | +| 📋 **Create Follow-Up** | Créer des tâches de suivi identifiées lors de la réponse à l'incident | | {{< X >}} | {{< X >}} | +| 📋 **List Follow-Ups** | Afficher et suivre les tâches de suivi pour l'incident | | | {{< X >}} | +| 📝 **Create/View Postmortem** | Créer ou voir le post-mortem de l'incident | | | {{< X >}} | + +## Lectures complémentaires {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://app.datadoghq.com/integrations/slack/ +[2]: /fr/integrations/slack/?tab=datadogforslack +[3]: https://app.datadoghq.com/incidents/settings?section=integrations +[4]: /fr/integrations/jira/ +[5]: /fr/incident_response/incident_management/setup_and_configuration/notification_rules/ +[6]: /fr/integrations/slack/?tab=datadogforslack#permissions +[7]: /fr/incident_response/incident_management/setup_and_configuration/variables/#variables-available-only-in-channel-name-templates \ No newline at end of file diff --git a/hugo/content/fr/integrations/_index.md b/hugo/content/fr/integrations/_index.md index be9d852c6a7..d3182a8b53c 100644 --- a/hugo/content/fr/integrations/_index.md +++ b/hugo/content/fr/integrations/_index.md @@ -1,168 +1,96 @@ --- -title: Intégrations -disable_sidebar: true -aliases: - - /integrations/verisign_openhybrid/ - - /integrations/snyk/ - - /integrations/lightstep_incident_response/ - - /integrations/mainstorconcept_ziris/ - - /integrations/rookout/ - - /integrations/rookout_license/ - - /integrations/shoreline/ - - /integrations/shoreline_license/ - - /integrations/shoreline_software_license/ - - /integrations/pingdom_v3/ -description: Rassembler des données de tous vos systèmes, toutes vos applications et tous vos services algolia: - tags: ["intégration", "configuration de l'intégration"] + tags: + - integration + - integration setup +aliases: +- /fr/integrations/verisign_openhybrid/ +- /fr/integrations/snyk/ +- /fr/integrations/lightstep_incident_response/ +- /fr/integrations/mainstorconcept_ziris/ +- /fr/integrations/rookout/ +- /fr/integrations/rookout_license/ +- /fr/integrations/shoreline/ +- /fr/integrations/shoreline_license/ +- /fr/integrations/shoreline_software_license/ +- /fr/integrations/pingdom_v3/ +- /fr/integrations/perimeterx/ +- /fr/integrations/open-policy-agent/ +- /fr/integrations/open_policy_agent/ +- /fr/integrations/coreos/ +- /fr/integrations/ubuntu/ +- /fr/integrations/amazon-opsworks/ cascade: - _target: - path: /intégrations/akamai-datastream-2 - lang: fr - aliases: - - /integrations/akamai_datastream -- _target: + lang: en path: /integrations/azure - lang: fr algolia: - rank: 80 category: Documentation - subcategory: Intégrations - tags: ['azure', 'microsoft azure'] + rank: 80 + subcategory: Integrations + tags: + - azure + - microsoft azure - _target: + lang: en path: /integrations/kubernetes_state_core - lang: fr algolia: - rank: 60 category: Documentation - subcategory: Intégrations - tags: ['ksm'] + rank: 60 + subcategory: Integrations + tags: + - ksm - _target: + lang: en path: /integrations/google_cloud_platform - lang: fr algolia: - rank: 80 category: Documentation - subcategory: Intégrations - tags: ['gcp', 'google cloud platform'] + rank: 80 + subcategory: Integrations + tags: + - gcp + - google cloud platform - _target: + lang: en path: /integrations/amazon_web_services - lang: fr algolia: - rank: 80 category: Documentation - subcategory: Intégrations - tags: ['aws', 'amazon web services'] + rank: 80 + subcategory: Integrations + tags: + - aws + - amazon web services - _target: + lang: en path: /integrations/eks_fargate - lang: fr algolia: - rank: 60 category: Documentation - subcategory: Intégrations - tags: ['journalisation eks'] + rank: 60 + subcategory: Integrations + tags: + - eks logging - _target: + lang: en path: /integrations/event-viewer - lang: fr - aliases: - - /integrations/eventviewer/ algolia: - rank: 60 category: Documentation - subcategory: Intégrations - tags: ['event viewer'] -- _target: - path: /intégrations/lambdatest-software-license - lang: fr - aliases: - - /integrations/lambdatest_software_license/ -- _target: - path: /intégrations/rapdev-validator - lang: fr - aliases: - - /integrations/rapdev_dashboard_widget_pack/ -- _target: - path: /integrations/wmi_check - lang: fr - aliases: - - /integrations/wmi/ -- _target: - path: /intégrations/jfrog-platform - lang: fr - aliases: - - /integrations/jfrog_platform/ -- _target: - path: /integrations/komodor_license - lang: fr - aliases: - - /integrations/komodor_komodor/ -- _target: - path: /integrations/stormforge_license - lang: fr - aliases: - - /integrations/stormforge_stormforge_license/ -- _target: - path: /integrations/feed - lang: fr - aliases: - - /integrations/rss/ -- _target: - path: /integrations/java - lang: fr - aliases: - - /agent/faq/jmx_integrations/ - - /agent/faq/docker-jmx/ -- _target: - path: /intégrations/amazon-elb - lang: fr - aliases: - - /integrations/awselb -- _target: - path: /intégrations/amazon-es - lang: fr - aliases: - - /integrations/awses -- _target: - path: /intégrations/amazon-s3 - lang: fr - aliases: - - /integrations/awss3 -- _target: - path: /intégrations/snowflake-web - lang: fr - aliases: - - /integrations/snowflake/ -- _target: - path: /intégrations/redpeaks-sap-netweaver - lang: fr - aliases: - - /integrations/agentil_software_sap_netweaver/ -- _target: - path: /intégrations/redpeaks-sap-businessobjects - lang: fr - aliases: - - /integrations/agentil_software_sap_businessobjects/ -- _target: - path: /intégrations/redpeaks-services-5-jours - lang: fr - aliases: - - /integrations/agentil_software_services_5_days/ -- _target: - path: /intégrations/redpeaks-sap-hana - lang: fr - aliases: - - /integrations/agentil_software_sap_hana/ -- _target: - path: /intégrations/azure-virtual-network - lang: fr - aliases: - - /integrations/azure_virtual_networks + rank: 60 + subcategory: Integrations + tags: + - event viewer +- _target: + lang: en + path: /integrations/confluent-cloud + site_support_id: confluent_cloud_integration +description: Rassembler des données de tous vos systèmes, toutes vos applications + et tous vos services +disable_sidebar: true +title: Integrations --- +Plus de {{< translate key="integration_count" >}} intégrations natives. Ayez une visibilité sur l'ensemble de vos systèmes, applications et services. -Plus de {{< translate key="integration_count" >}} intégrations par défaut. Récupérez des données pour tous vos systèmes, toutes vos applications et tous vos services. - -Qu'est-ce qu'une intégration ? Consultez la [Présentation des intégrations][1]. +Qu'est-ce qu'une intégration ? Consultez [Présentation des intégrations][1]. {{< integrations >}} -[1]: /getting_started/integrations/ +[1]: /fr/getting_started/integrations/ \ No newline at end of file diff --git a/hugo/content/fr/llm_observability/build_with_ai/mcp_server.md b/hugo/content/fr/llm_observability/build_with_ai/mcp_server.md new file mode 100644 index 00000000000..5595668326c --- /dev/null +++ b/hugo/content/fr/llm_observability/build_with_ai/mcp_server.md @@ -0,0 +1,534 @@ +--- +aliases: +- /fr/llm_observability/mcp_server/ +description: Connectez les agents IA à vos traces et expériences Agent Observability + à l'aide du Datadog MCP Server. +further_reading: +- link: mcp_server + tag: Documentation + text: Datadog MCP Server +- link: /llm_observability/improve/experiments + tag: Documentation + text: Configurez et utilisez les expériences Agent Observability +- link: /llm_observability/investigate + tag: Documentation + text: Surveillez votre application avec Agent Observability +- link: /llm_observability/build_with_ai/claude_code_skills + tag: Guide + text: Analyser les applications LLM avec les compétences Claude Code +- link: https://www.datadoghq.com/blog/debug-and-evaluate-your-ai-app-from-your-coding-agent/ + tag: Blog + text: Déboguez et évaluez votre application d'IA depuis votre agent de codage avec + Datadog Agent Observability +- link: https://www.datadoghq.com/blog/bits-evals/ + tag: Blog + text: Améliorez la qualité de l'agent d'IA avec Bits Evals +title: MCP et compétences Agent Observability +--- +## Présentation {#overview} + +Le [Datadog MCP Server][1] permet aux agents IA d'accéder à vos données [Agent Observability][2] via le protocole MCP (Model Context Protocol). L'ensemble d'outils `llmobs` fournit des outils pour rechercher et analyser les traces, inspecter les détails et le contenu des spans, et évaluer les résultats des expériences directement depuis des clients basés sur l'IA comme Cursor, Claude Code ou OpenAI Codex. + +## Configuration {#setup} + +Connectez un client compatible MCP au Datadog MCP Server avec l'ensemble d'outils `llmobs` activé. + +
Pour obtenir des instructions de configuration complètes, y compris la configuration des extensions Cursor et VS Code, consultez Configurer le Datadog MCP Server.
+ +### Prérequis {#prerequisites} + +- Un compte Datadog avec l'autorisation d'accéder aux données Agent Observability. +- Un client compatible MCP (par exemple, Claude Code, Codex CLI, Cursor, Gemini CLI ou Kiro CLI). + +### Endpoint {#endpoint} + +L'endpoint du serveur MCP dépend de votre [site Datadog][5]. Utilisez le sélecteur {{< ui >}}Datadog Site{{< /ui >}} pour afficher l'endpoint de votre site. Ajoutez `?toolsets=llmobs,core` pour activer Agent Observability et les ensembles d'outils principaux. + +{{< site-region region="us,us3,us5,eu,ap1,ap2,uk1" >}} +Endpoint pour votre site sélectionné ({{< region-param key="dd_site_name" >}}): +
{{< region-param key="mcp_server_endpoint" >}}?toolsets=llmobs,core
+{{< /site-region >}} + +{{< site-region region="gov,gov2" >}} +
Ce produit n'est pas pris en charge pour le site sélectionné ({{< region-param key="dd_site_name" >}}).
+{{< /site-region >}} + +### Connectez-vous {#connect} + +Choisissez l'authentification distante lorsque cela est possible. Utilisez l'authentification binaire locale si votre environnement bloque le flux OAuth distant. + +{{< tabs >}} +{{% tab "Authentification distante" %}} + +{{< site-region region="us,us3,us5,eu,ap1,ap2,uk1" >}} +L'authentification distante utilise le transport [Streamable HTTP][1] de la spécification MCP. + +**Claude Code** (ligne de commande) : + +
claude mcp add --transport http datadog-mcp "{{< region-param key="mcp_server_endpoint" >}}?toolsets=llmobs,core"
+ +**Codex CLI** (`~/.codex/config.toml`) : + +
[mcp_servers.datadog]
+url = "{{< region-param key="mcp_server_endpoint" >}}"
+http_headers = { "X-Datadog-MCP-Toolsets" = "llmobs,core" }
+
+ +Après avoir ajouté la configuration, exécutez `codex mcp login datadog` pour terminer le flux OAuth. + +**Gemini CLI, Kiro CLI et autres clients compatibles MCP** : + +
{
+  "mcpServers": {
+    "datadog": {
+      "type": "http",
+      "url": "{{< region-param key="mcp_server_endpoint" >}}?toolsets=llmobs,core"
+    }
+  }
+}
+
+ +[1]: https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#streamable-http +{{< /site-region >}} + +{{< site-region region="gov,gov2" >}} +
Ce produit n'est pas pris en charge pour le site sélectionné ({{< region-param key="dd_site_name" >}}).
+{{< /site-region >}} + +{{% /tab %}} + +{{% tab "Authentification binaire locale" %}} + +L'authentification binaire locale utilise le transport [stdio][2] de la spécification MCP. Utilisez cette méthode si l'authentification distante n'est pas disponible. + +1. Installez le binaire du Datadog MCP Server : + + ```bash + curl -sSL https://coterm.datadoghq.com/mcp-cli/install.sh | bash + ``` + + The binary installs to `~/.local/bin/datadog_mcp_cli`. + +2. Terminez le flux de connexion OAuth : + + ```bash + datadog_mcp_cli login + ``` + +3. Configurez votre client IA. Pour Claude Code, ajoutez ce qui suit à `~/.claude.json`, en remplaçant `` dans le chemin de la commande : + + ```json + { + "mcpServers": { + "datadog": { + "type": "stdio", + "command": "/Users//.local/bin/datadog_mcp_cli", + "args": [], + "env": {} + } + } + } + ``` + + Alternatively, add the server with the Claude Code CLI: + + ```bash + claude mcp add datadog --scope user -- ~/.local/bin/datadog_mcp_cli + ``` + +[2]: https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#stdio +{{% /tab %}} +{{< /tabs >}} + +### Authentifiez-vous avec des clés d'API {#authenticate-with-api-keys} + +Le serveur MCP utilise OAuth 2.0 par défaut. Si OAuth n'est pas disponible, envoyez une [clé d'API et une clé d'application][6] Datadog en tant qu'en-têtes HTTP `DD_API_KEY` et `DD_APPLICATION_KEY` : + +{{< site-region region="us,us3,us5,eu,ap1,ap2,uk1" >}} +
{
+  "mcpServers": {
+    "datadog": {
+      "type": "http",
+      "url": "{{< region-param key="mcp_server_endpoint" >}}?toolsets=llmobs,core",
+      "headers": {
+          "DD_API_KEY": "<YOUR_API_KEY>",
+          "DD_APPLICATION_KEY": "<YOUR_APPLICATION_KEY>"
+      }
+    }
+  }
+}
+
+{{< /site-region >}} + +{{< site-region region="gov,gov2" >}} +
Ce produit n'est pas pris en charge pour le site sélectionné ({{< region-param key="dd_site_name" >}}).
+{{< /site-region >}} + +Pour des raisons de sécurité, limitez la clé d'API et la clé d'application à un [compte de service][7] disposant uniquement des autorisations requises. + +## Compétences de l'Agent{#agent-skills} + +Les compétences de l'agent sont des ensembles d'instructions prédéfinis pour les agents de codage IA qui automatisent les workflows courants Agent Observability. L'ensemble de compétences `agent-observability` est disponible dans le dépôt [Datadog agent-skills][8]. Il fournit six compétences pour classer les sessions, diagnostiquer les échecs, analyser les expérimentations, générer du code d'expérimentation avec le SDK `ddtrace.llmobs` et amorcer des évaluateurs par rapport à vos données de production réelles. + +### Installation{#install} + +Installez les compétences `agent-observability` avec la commande suivante : + +```shell +npx skills add datadog-labs/agent-skills/agent-observability --full-depth -y +``` + +Les compétences nécessitent que la boîte à outils MCP `llmobs` soit connectée. Si vous ne l'avez pas encore connectée, exécutez : + +{{< site-region region="us,us3,us5,eu,ap1,ap2,uk1" >}} +
claude mcp add --scope user --transport http "datadog-llmo-mcp" \
+  '{{< region-param key="mcp_server_endpoint" >}}?toolsets=llmobs,core'
+{{< /site-region >}} + +{{< site-region region="gov,gov2" >}} +
Ce produit n'est pas pris en charge pour le site sélectionné ({{< region-param key="dd_site_name" >}}).
+{{< /site-region >}} + +Redémarrez Claude Code après avoir exécuté les deux commandes pour que les compétences apparaissent. + +### Compétences disponibles{#available-skills} + +| Compétence| Invoquer avec| Ce qu'elle fait| +|-------|-------------|-------------| +| Classification de session| `/agent-observability-session-classify` | Détermine si l'intention de l'utilisateur a été satisfaite dans une session, une trace ou un lot| +| Analyse de cause racine de trace| `/agent-observability-trace-rca` | Analyse de cause racine sur les traces de production défaillantes| +| Analyseur d'expérimentation| `/agent-observability-experiment-analyzer` | Analyser et comparer les résultats d'expérimentation LLM| +| Génération de code Python d'expérimentation| `/agent-observability-experiment-py-bootstrap` | Générer du code d'expérimentation Python en utilisant le SDK `ddtrace.llmobs`. Introspection de votre application pour connecter un `task_fn` réel, découverte automatique des identifiants `.env`, et acceptation d'un `--purpose` libre qui dirige la sélection de l'évaluateur | +| Amorçage d'évaluation| `/agent-observability-eval-bootstrap` | Générer du code d'évaluateur, publier des évaluateurs LLM-judge en ligne, ou échantillonner des traces dans un jeu de données pour une utilisation dans une expérimentation| +| Pipeline d'évaluation | `/agent-observability-eval-pipeline` | Pipeline guidé en six phases, depuis les traces de production jusqu'aux évaluateurs, jeux de données, expériences et analyses. Arrêtez prématurément avec `--stop-after`, reprenez en cours de flux avec `--start-at` | + +#### Classification de session {#session-classification} + +`/agent-observability-session-classify` classifie si l'intention de l'utilisateur a été satisfaite dans une interaction donnée. Il s'appuie sur jusqu'à trois sources de signaux : : traces Agent Observability, données comportementales RUM et événements Audit Trail. La compétence renvoie un verdict `yes / partial / no` avec des preuves à l'appui. La confiance s'améliore avec chaque source de signal supplémentaire. + +``` +/agent-observability-session-classify session_id= +/agent-observability-session-classify trace_id= +/agent-observability-session-classify ml_app=my-chatbot --timeframe now-7d +``` + +#### Analyse des causes profondes des traces {#trace-root-cause-analysis} + +`/agent-observability-trace-rca` diagnostique pourquoi une application LLM produit de mauvais résultats. Il sélectionne un mode d'analyse basé sur le signal le plus fort disponible (verdicts d'évaluation LLM-judge, erreurs d'exécution ou anomalies structurelles) et compile un rapport d'analyse des causes profondes (RCA) structuré. Le rapport inclut une taxonomie des échecs et des propositions de correction concrètes `BEFORE` / `AFTER` fondées sur les preuves issues des traces. + +Lorsque Claude Code a accès à votre base de code, la compétence peut rechercher les fichiers sources pertinents et proposer des diffs en ligne. + +``` +/agent-observability-trace-rca ml_app=my-chatbot +/agent-observability-trace-rca ml_app=my-chatbot eval_name=faithfulness --timeframe now-24h +``` + +#### Amorçage d'évaluateur {#evaluator-bootstrap} + +`/agent-observability-eval-bootstrap` analyse les traces de production et propose une suite d'évaluateurs ciblant les modes de défaillance observés. Il génère l'un des quatre artefacts suivants : : classes `BaseEvaluator` Python / `LLMJudge` pour les expériences hors ligne, une spécification JSON indépendante du framework, des évaluateurs LLM-judge en ligne publiés directement sur Datadog, ou — via `--emit-dataset ` — un `DatasetRecordRaw[]` JSON échantillonné à partir des traces de production et mis en forme pour `LLMObs.create_dataset(records=...)`. Le mode dataset-emit ignore entièrement le workflow de l'évaluateur ; il produit un jeu de données adapté à une utilisation comme entrée pour une expérience. + +``` +/agent-observability-eval-bootstrap ml_app=my-chatbot +/agent-observability-eval-bootstrap ml_app=my-chatbot --publish +/agent-observability-eval-bootstrap ml_app=my-chatbot --data-only +/agent-observability-eval-bootstrap ml_app=my-chatbot --emit-dataset ./datasets/my_chatbot_seed.json +``` + +#### Analyseur d'expérience {#experiment-analyzer} + +`/agent-observability-experiment-analyzer` récupère les résultats de l'expérience et met en évidence ce qui a changé entre un candidat et une référence : : quelles métriques se sont améliorées, lesquelles ont régressé et où le candidat a été moins performant. + +``` +/agent-observability-experiment-analyzer experiment_id= +/agent-observability-experiment-analyzer experiment_id= baseline_id= +``` + +#### Générer du code d'expérience avec le SDK Python {#generate-experiment-code-with-the-python-sdk} + +`/agent-observability-experiment-py-bootstrap` émet un script `.py` autonome ou un notebook `.ipynb` Jupyter qui utilise le SDK `ddtrace.llmobs` et correspond au style du notebook de référence canonique. + +Le jeu de données peut être un fichier `DatasetRecordRaw[]` JSON local (intégré au fichier), un CSV (chargé à l'exécution via `LLMObs.create_dataset_from_csv`), un jeu de données Datadog existant par son nom (`LLMObs.pull_dataset`), ou — par défaut — un petit échantillon en ligne de 3 enregistrements. Chaque expérience générée est marquée avec `generated_by=claude-code` et le `--purpose` résolu dans `config` et `tags`. + +``` +/agent-observability-experiment-py-bootstrap --purpose "validate output accuracy" +/agent-observability-experiment-py-bootstrap --purpose "test tool selection" --dataset ./data/qa.json +/agent-observability-experiment-py-bootstrap --dataset-name --project-name +/agent-observability-experiment-py-bootstrap --task-source mymodule.handlers:respond +``` + +#### Pipeline d'évaluation de bout en bout {#end-to-end-eval-pipeline} + +`/agent-observability-eval-pipeline` parcourt les traces de production via des évaluateurs, des jeux de données, des expériences et des analyses en six phases narrées, avec un point de contrôle utilisateur entre chacune : + +1. **Classifier les traces ml_app** — échantillonner et classifier les traces récentes de votre `ml_app` +2. **Analyse de la cause racine** — diagnostiquer pourquoi les traces en échec échouent +3. **Amorcer les évaluateurs** — proposer une suite d'évaluateurs ciblant les modes de défaillance observés +4. **Créer + publier le jeu de données** — extraire les paires entrée / sortie attendue dans un `DatasetRecordRaw[]` JSON et publier sur Datadog sous votre projet (créé de manière paresseuse). +5. **Générer + exécuter l'expérience** — émettre un `.py` ou `.ipynb` exécutable qui récupère le jeu de données et connecte la fonction de tâche de votre application, puis l'exécuter de bout en bout et capturer `experiment.url`. Un rythme de revue en phase (`run` / `edit` / `stop`) se situe entre la génération de code et l'exécution afin que vous puissiez inspecter le fichier généré avant qu'il ne s'exécute +6. **Analyser l'expérience** — produire un rapport d'analyse avec des ventilations de métriques et des recommandations + +Chaque phase possède un nom court canonique — la même valeur acceptée par `--start-at` et `--stop-after`. Le tableau ci-dessous liste, par phase, quels outils MCP le pipeline peut invoquer et une description en une ligne de la logique : + +| # | Titre de la phase | Nom de l'étape | Outils MCP appelés | Résumé | +|---|-------------|----------------------------------------------------------------------------------------|------------------|---------| +| 1 | Classifier les traces ml_app | `classify` | `search_llmobs_spans` | Échantillonne les spans racines récents pour `ml_app`, classe chacun comme succès / partiel / échec, met en évidence les schémas courants. | +| 2 | Analyse de la cause racine | `rca` | `search_llmobs_spans` | Récupère les traces complètes pour les spans en échec de la Phase 1 et parcourt l'arborescence des traces pour attribuer chaque échec à un span racine et à un mode de défaillance. | +| 3 | Amorcer les évaluateurs | `eval-bootstrap` | Aucun (raisonnement local sur le rapport de la Phase 2) ; appel Datadog API optionnel pour publier des évaluateurs LLM-judge en ligne lorsque `--publish` est défini | Émet une suite d'évaluateurs Python (`sdk_code`), une spécification JSON agnostique au framework (`data_only`), ou publie des évaluateurs en ligne (`publish`). | +| 4 | Créer et publier le jeu de données | `dataset` | `search_llmobs_spans` pour l'échantillonnage ;`LLMObs.create_dataset()` via le SDK ddtrace (pas MCP) pour la publication | Échantillonne les spans racines, extrait les paires entrée / expected_output, nettoie les PII, écrit un JSON local, puis publie sur Datadog. | +| 5 | Générer et exécuter l'expérience | `experiment` | `list_llmobs_evals` (balise de démarrage one-shot — connectivité + télémétrie) ; l'exécution utilise le SDK ddtrace | Effectue une introspection de votre application pour les sites d'appel LLM, émet un câblage autonome (`.py` ou `.ipynb`) `task_fn` vers un point d'entrée réel, puis l'exécute. | +| 6 | Analyser l'expérience | `analyze` | `get_llmobs_experiment_summary`, `get_llmobs_experiment_metric_values`, `list_llmobs_experiment_events`, `get_llmobs_experiment_event`, `get_llmobs_experiment_dimension_values` | Récupère les métriques de haut niveau, les scores par enregistrement, les dimensions de segment et les événements de drill-down, synthétise un rapport d'analyse structuré. | + +Vous pouvez `stop` proprement à n'importe quel point de contrôle et reprendre plus tard avec `--start-at ` — aucune réexécution n'est nécessaire. Passez `--stop-after eval-bootstrap` pour préserver le comportement classique à trois phases d'évaluation uniquement. + +``` +/agent-observability-eval-pipeline my-chatbot --project-name my-chatbot +/agent-observability-eval-pipeline my-chatbot --stop-after eval-bootstrap # classic 3-phase +/agent-observability-eval-pipeline my-chatbot --start-at experiment # resume mid-flow +/agent-observability-eval-pipeline my-chatbot --start-at analyze --experiment-id +``` + +Pour un guide complet sur ces compétences et un workflow de bout en bout recommandé, consultez [Analyser les applications LLM avec les compétences Claude Code][9]. + +## Cas d'utilisation {#use-cases} + +Les outils MCP Agent Observability permettent des workflows assistés par IA pour : + +- **Débogage de l'exécution de l'agent**: Recherchez des traces par application ML, statut d'erreur ou tags personnalisés, puis examinez les hiérarchies de spans et le contenu pour identifier les échecs. +- **Analyse de la structure de trace**: Visualisez l'arborescence complète des spans d'une trace pour comprendre comment les agents, les LLM, les outils et les récupérations interagissent. +- **Enquête sur les boucles d'agent**: Examinez la boucle d'exécution étape par étape d'un agent pour comprendre la prise de décision et les modèles d'invocation d'outils. +- **Évaluation d'expériences**: Obtenez des statistiques récapitulatives pour les métriques d'expérience, comparez les résultats entre les segments de dimension et inspectez les événements individuels. +- **Création d'expériences**: Enregistrez un nouvel objet d'expérience avec `create_llmobs_experiment` pour consigner les métadonnées de l'expérience (projet, jeu de données, description, configuration) sans exécuter d'inférence de modèle. Attachez ensuite les métriques d'évaluation avec `submit_llmobs_experiment_events`. +- **Découverte de modèles d'expérience**: Filtrez et triez les événements d'expérience par performance de métrique pour trouver les cas les plus et les moins performants. +- **Gestion des évaluateurs**: Listez, inspectez, créez, mettez à jour et supprimez les configurations d'évaluateur pour une application ML ou pour l'ensemble de l'organisation. +- **Exploration de modèles**: Listez les configurations de modèles, vérifiez le statut d'exécution et parcourez la hiérarchie des sujets découverte pour comprendre ce que demandent les utilisateurs et comment le trafic est distribué. +- **Gestion des jeux de données**: Recherchez des projets et des jeux de données, parcourez et inspectez les enregistrements de jeux de données, et ajoutez de nouveaux enregistrements à un jeu de données pour les utiliser dans des expériences. + +## Outils disponibles {#available-tools} + +L'ensemble d'outils `llmobs` comprend les outils suivants : + +### Trace and span tools → Outils de trace et de span{#trace-and-span-tools} + +`search_llmobs_spans` +: Search for spans matching filters or a raw query. → Recherchez des spans correspondant à des filtres ou à une requête brute. + +`get_llmobs_trace` +: Get the full structure of a trace as a span hierarchy tree, including span counts by kind, error indicators, and total duration. → Obtenez la structure complète d'une trace sous forme d'arborescence hiérarchique de spans, incluant le nombre de spans par type, les indicateurs d'erreur et la durée totale. + +`get_llmobs_span_details` +: Obtenez des métadonnées détaillées pour un ou plusieurs spans, incluant le timing, les informations d'erreur, les détails LLM (modèle, nombre de jetons), les métriques et les évaluations. + +`get_llmobs_span_content` +: Récupérez le contenu réel d'un champ de span (entrée, sortie, messages, documents ou métadonnées) avec extraction JSONPath optionnelle. + +`find_llmobs_error_spans` +: Trouvez tous les spans d'erreur dans une trace avec contexte de propagation, regroupés par type de span avec messages d'erreur et traces de pile. + +`expand_llmobs_spans` +: Chargez les enfants de spans spécifiques pour une exploration progressive de l'arborescence lorsque `get_llmobs_trace` renvoie des nœuds réduits. + +`get_llmobs_agent_loop` +: Obtenez une vue chronologique de la boucle d'exécution d'un agent, montrant chaque étape (appels LLM, invocations d'outils, décisions) dans l'ordre. + +### Outils d'expérimentation {#experiment-tools} + +`create_llmobs_experiment` +: Créez un nouvel objet d'expérience Agent Observability dans un projet. Enregistre l'expérience (afin que les événements et les métriques puissent être rapportés par rapport à celle-ci) sans exécuter d'inférence de modèle. Nécessite `project_id` et `experiment_name`. Renvoie l'`experiment_id` créé et son nom résolu. Utilisez `submit_llmobs_experiment_events` pour joindre des métriques d'évaluation, ou `update_llmobs_experiment` pour modifier ses propriétés. + +`get_llmobs_experiment_summary` +: Obtenez un résumé de haut niveau de l'expérience avec des statistiques précalculées pour toutes les métriques d'évaluation. Commencez ici avant d'utiliser d'autres outils d'expérimentation. + +`list_llmobs_experiment_events` +: Listez les événements d'expérience avec filtrage par dimension ou métrique et tri par valeur de métrique. + +`get_llmobs_experiment_event` +: Obtenez les détails complets d'un seul événement d'expérience, incluant l'entrée, la sortie, la sortie attendue, toutes les métriques et les dimensions. + +`get_llmobs_experiment_metric_values` +: Obtenez une analyse statistique pour une métrique d'évaluation spécifique, éventuellement segmentée par une dimension pour comparaison. + +`get_llmobs_experiment_dimension_values` +: Obtenez les valeurs uniques pour une dimension avec les dénombrements, utiles pour découvrir des valeurs de filtre et de segment valides. + +### Outils d'évaluation {#evaluator-tools} + +`list_llmobs_evals` +: Listez chaque évaluateur LLM-judge configuré dans toutes les applications ML. Renvoie le nom, l'application ml_app et le statut activé de chaque évaluateur. + +`list_llmobs_evals_by_ml_app` +: List all LLM-judge evaluators configured for a specific ML application. → Listez tous les évaluateurs LLM-judge configurés pour une application ML spécifique. + +`get_llmobs_evaluator` +: Retrieve an LLM-judge evaluator configuration by name, including its target (ml_app, sampling, filter), LLM provider, and judge prompt template. → Récupérez la configuration d'un évaluateur LLM-judge par son nom, incluant sa cible (ml_app, échantillonnage, filtre), le fournisseur LLM et le modèle de prompt de l'évaluateur. + +`create_or_update_llmobs_evaluator` +: Create or update an LLM-judge evaluator configuration. → Créez ou mettez à jour la configuration d'un évaluateur LLM-judge. Targets a specific ML application and optionally a filter or sampling percentage; the judge's model and prompt template define how it scores each span. → Cible une application ML spécifique et, optionnellement, un filtre ou un pourcentage d'échantillonnage ; le modèle et le modèle de prompt de l'évaluateur définissent la manière dont il évalue chaque span. + +`delete_llmobs_evaluator` +: Delete an LLM-judge evaluator configuration by name. → Supprimez la configuration d'un évaluateur LLM-judge par son nom. + +### Outils de projet et de jeu de données {#project-and-dataset-tools} + +`list_llmobs_projects` +: Listez tous les projets d'expériences Agent Observability pour l'organisation, triés par date de création (du plus récent au plus ancien). Renvoie le `id`, le `name` et les horodatages de chaque projet, ainsi que les champs de pagination (`next_cursor`, `truncated`). Utilisez ceci pour découvrir les noms et les ID de projet lorsque vous ne les connaissez pas déjà. + +`get_llmobs_project` +: Recherchez un projet d'expériences Agent Observability par ID ou par nom. Utilisez ceci pour résoudre un UUID `project_id` avant d'appeler les outils de jeu de données. + +`list_llmobs_datasets` +: Listez les jeux de données au sein d'un projet, avec un filtre optionnel par ID ou par nom. Renvoie les métadonnées du jeu de données et les champs de pagination. Utilisez ceci avant `get_llmobs_dataset_records` ou `add_llmobs_dataset_records` — ces outils nécessitent un UUID de jeu de données. + +`get_llmobs_dataset_records` +: Lisez les enregistrements de jeux de données avec des aperçus structurés et un résumé du schéma. Met en forme des champs JSON arbitraires (`input`, `expected_output`, `metadata`) en aperçus lisibles. Utilisez `compute_schema=true` pour obtenir un aperçu typé de la structure des enregistrements avant de construire de nouveaux enregistrements. + +`get_llmobs_full_dataset_records` +: Récupérez jusqu'à 3 enregistrements spécifiques avec un contenu complet et non tronqué. Utilisez ceci pour inspecter individuellement les enregistrements en détail après avoir trouvé les ID d'enregistrement avec `get_llmobs_dataset_records`. + +`add_llmobs_dataset_records` +: Créez des enregistrements dans un jeu de données en utilisant un flux en deux étapes de prévisualisation puis de confirmation. Appelez `confirmed=false` pour prévisualiser l'écriture prévue, puis `confirmed=true` pour valider après approbation de l'utilisateur. + +### Outils Patterns {#patterns-tools} + +`list_llmobs_pattern_configs` +: Listez toutes les configurations de Patterns pour l'organisation. Renvoie le `id`, le `name`, le `evp_query`, les paramètres d'échantillonnage et les horodatages de chaque configuration. Commencez ici pour trouver un `config_id`. + +`get_llmobs_pattern_config` +: Obtenez la configuration de Patterns la plus récemment modifiée pour l'organisation. + +`get_llmobs_pattern_run_status` +: Obtenez le statut et la progression par activité de la plus récente exécution de Patterns pour une configuration. Utilisez ceci pour vérifier si le clustering est en cours d'exécution, terminé ou a échoué avant de lire les sujets. + +`list_llmobs_pattern_runs` +: Listez toutes les exécutions de Patterns terminées pour une configuration, de la plus récente à la plus ancienne. Renvoie l'`id`, le `status`, les horodatages et le `config_snapshot` utilisé pour chaque exécution. + +`get_llmobs_patterns` +: Obtenez la hiérarchie des sujets découverte par une exécution de Patterns. Les sujets sont organisés en niveaux, chacun avec un `name`, un `description` et un `point_count`. Omettez `run_id` pour lire l'exécution terminée la plus récente. + +`get_llmobs_patterns_with_points` +: Obtenez la hiérarchie des sujets pour une exécution avec les ID de span intégrés sur chaque sujet terminal. Définissez `include_metrics=true` pour inclure également la durée, le coût, le nombre de jetons et les évaluations par span. + +`get_llmobs_pattern_points` +: Obtenez une page paginée par curseur de points de clustering (spans individuels) assignés à un seul sujet. Chaque point inclut le `span_id`, le `session_id` et un aperçu de l'entrée du span. Transmettez `next_page_token` en tant que `page_token` pour continuer la pagination. + +### Outils de file d'attente d'annotation {#annotation-queue-tools} + +`list_llmobs_annotation_queues` +: Listez toutes les [files d'attente d'annotation][10] pour l'organisation. + +`create_llmobs_annotation_queue` +: Créez une file d'attente d'annotation pour la révision humaine des traces, en définissant éventuellement son schéma d'étiquetage lors de la création. + +`update_llmobs_annotation_queue` +: Mettez à jour le nom, la description ou le schéma d'étiquetage d'une file d'attente d'annotation. + +`delete_llmobs_annotation_queue` +: Supprimez une file d'attente d'annotation. + +`get_llmobs_annotation_label_schema` +: Obtenez le schéma d'étiquetage d'une file d'attente d'annotation, qui définit les étiquettes que les annotateurs appliquent lors de la révision. + +`update_llmobs_annotation_label_schema` +: Créez ou remplacez le schéma d'étiquetage d'une file d'attente d'annotation. + +`add_llmobs_annotation_queue_interactions` +: Ajoutez une ou plusieurs traces à une file d'attente d'annotation pour révision. + +`delete_llmobs_annotation_queue_interactions` +: Supprimez des traces d'une file d'attente d'annotation. + +`get_llmobs_annotated_interactions` +: Obtenez les interactions annotées dans une file d'attente d'annotation ainsi que les étiquettes que les annotateurs leur ont appliquées. + +`get_llmobs_annotations_by_content_ids` +: Obtenez les annotations appliquées à des traces ou sessions spécifiques par leurs identifiants de contenu. + +`upsert_llmobs_annotations` +: Créez ou mettez à jour les annotations appliquées aux interactions dans une file d'attente. + +`delete_llmobs_annotations` +: Supprimez les annotations appliquées aux interactions dans une file d'attente. + +## Workflows recommandés {#recommended-workflows} + +### Analyse de trace {#trace-analysis} + +1. **Rechercher** : utilisez `search_llmobs_spans` pour trouver des traces par application ML, statut, type de span ou tags personnalisés. +2. **Visualiser** : utilisez `get_llmobs_trace` pour voir l'arborescence complète de la hiérarchie des spans. +3. **Inspecter** : utilisez `get_llmobs_span_details` pour obtenir des métadonnées, le timing et les évaluations pour des spans spécifiques. +4. **Lire le contenu** : utilisez `get_llmobs_span_content` pour récupérer les E/S réelles, les messages ou les documents. +5. **Déboguer les erreurs** : utilisez `find_llmobs_error_spans` pour localiser toutes les erreurs dans une trace avec le contexte de propagation. +6. **Développer** : utilisez `expand_llmobs_spans` pour charger les enfants des spans réduits pour une exploration plus approfondie. +7. **Examen de l'Agent** : utilisez `get_llmobs_agent_loop` pour voir le flux d'exécution étape par étape d'un span d'agent. + +### Analyse d'expérience {#experiment-analysis} + +1. **Résumer** : utilisez `get_llmobs_experiment_summary` pour obtenir des statistiques globales et découvrir les métriques et dimensions disponibles. +2. **Parcourir les événements** : utilisez `list_llmobs_experiment_events` pour trouver des événements d'intérêt, en filtrant par dimension ou en triant par métrique. +3. **Inspecter les événements** : utilisez `get_llmobs_experiment_event` pour afficher les détails complets d'un événement spécifique. +4. **Analyser les métriques** : utilisez `get_llmobs_experiment_metric_values` pour obtenir des distributions de centiles, des taux vrai/faux, ou comparer entre des segments de dimension. +5. **Découvrir les dimensions** : utilisez `get_llmobs_experiment_dimension_values` pour trouver des valeurs de filtre et de segment valides. + +### Gestion des jeux de données {#dataset-management} + +1. **Trouver votre projet** : utilisez `list_llmobs_projects` pour parcourir les projets — chaque résultat inclut l'UUID `id` dont vous avez besoin pour les appels ultérieurs. Si vous connaissez déjà le nom du projet mais pas son UUID, utilisez `get_llmobs_project` pour le résoudre directement. +2. **Trouver votre jeu de données** : utilisez `list_llmobs_datasets` avec `project_id` pour lister les jeux de données et obtenir leurs UUID. +3. **Comprendre les données** : utilisez `get_llmobs_dataset_records` avec `compute_schema=true` pour parcourir les enregistrements et obtenir un aperçu du type des champs avant de lire ou d'écrire. +4. **Lire des enregistrements spécifiques** : utilisez `get_llmobs_full_dataset_records` pour récupérer le contenu complet de jusqu'à 3 enregistrements par ID. +5. **Ajouter des enregistrements** : utilisez `add_llmobs_dataset_records` avec `confirmed=false` pour prévisualiser une écriture, puis `confirmed=true` après approbation de l'utilisateur. + +### Analyse Patterns {#patterns-analysis} + +1. **Lister les configurations** : utilisez `list_llmobs_pattern_configs` pour trouver les configurations Patterns disponibles et leurs valeurs `config_id`. +2. **Vérifier le statut d'exécution** : utilisez `get_llmobs_pattern_run_status` pour vérifier que l'exécution la plus récente est terminée. +3. **Lire les sujets** : utilisez `get_llmobs_patterns` pour obtenir la hiérarchie complète des sujets avec les noms, les descriptions et les scores de cohérence. +4. **Inspect spans** : utilisez `get_llmobs_patterns_with_points` pour obtenir les sujets avec les span IDs intégrés, ou `get_llmobs_pattern_points` pour parcourir les spans d'un sujet spécifique. +5. **Analyser le contenu des spans** : utilisez `get_llmobs_span_details` ou `get_llmobs_span_content` avec les valeurs `span_id` de l'étape précédente pour inspecter les entrées, sorties et métadonnées réelles des spans individuels au sein d'un sujet. +6. **Parcourir les exécutions passées** : utilisez `list_llmobs_pattern_runs` pour voir les exécutions historiques et transmettez un `run_id` spécifique pour comparer les distributions de sujets au fil du temps. + +## Exemples d'invites {#example-prompts} + +Après la connexion, essayez des invites telles que : + +- Examinez les traces d'erreurs de mon application `customer-support-bot` au cours de la semaine passée. Résumez les modèles de défaillance les plus courants, leur fréquence d'apparition, et recommandez ceux à corriger en priorité. +- Trouvez les traces où les réponses de mon agent ont été signalées par les évaluations comme étant de faible qualité. Examinez les entrées et les sorties, puis suggérez des modifications spécifiques à mon invite système pour améliorer la qualité des réponses. +- Examinez les traces récentes de l'agent pour mon application et trouvez les cas où l'agent a bouclé plus que nécessaire. Analysez la prise de décision à chaque étape et suggérez comment améliorer mes descriptions d'outils pour réduire les appels d'outils inutiles. +- Un utilisateur a signalé une mauvaise réponse. Voici l'ID de trace : `trace-123`. Expliquez-moi exactement ce qui s'est passé : ce que l'utilisateur a demandé, ce que l'agent a fait à chaque étape, et où les choses ont mal tourné. Proposez une correction de code. +- Analysez l'expérience `exp-456` et générez un tableau markdown des dimensions les moins performantes ventilées par scores d'évaluation. Incluez toute autre colonne pertinente qui m'aide à comprendre où et pourquoi les performances se dégradent. +- Comparez l'expérience `exp-123` (référence) avec l'expérience `exp-456`. Résumez ce qui s'est amélioré, ce qui a régressé et de combien. Recommandez-moi si les changements valent la peine d'être déployés. +- Résumez l'expérience `exp-456` et identifiez les 5 événements ayant obtenu les scores les plus bas. Pour chacun, montrez l'entrée, la sortie et les évaluations qui ont échoué. +- Créez une nouvelle expérience appelée « prompt-v2-test » dans mon projet `my-chatbot-project` et renvoyez son ID d'expérience afin que je puisse y joindre des métriques d'évaluation. +- Listez les jeux de données dans mon projet `my-project` et montrez-moi un échantillon d'enregistrements du jeu de données nommé `qa-golden-set`, y compris son schéma. +- J'ai un CSV de nouveaux cas de test. Ajoutez-les au jeu de données `qa-golden-set` dans `my-project` en tant que nouvelle version. Montrez-moi d'abord un aperçu. + +## Combiner avec d'autres outils Datadog {#combine-with-other-datadog-tools} + +L'ensemble d'outils `core` inclus dans l'URL de configuration donne à votre agent IA accès à des outils Datadog supplémentaires qui se marient naturellement avec l'analyse de Agent Observability. + +### Exporter l'analyse vers les Datadog Notebooks {#export-analysis-to-datadog-notebooks} + +L'ensemble d'outils `core` inclut `create_datadog_notebook` et `edit_datadog_notebook`, qui permettent à votre agent IA de créer [Datadog Notebooks][3] directement à partir des résultats d'analyse. Vous pouvez exporter les résultats des discussions avec l'agent dans un notebook collaboratif et partageable qui réside dans Datadog aux côtés de vos traces et expériences. + +Essayez des invites comme : + +- Analysez l'expérience `exp-456`, identifiez les dimensions les moins performantes et exportez un rapport récapitulatif vers un Notebook Datadog avec une ventilation par scores d'évaluation. +- Examinez les traces d'erreur pour mon `customer-support-bot` au cours de la semaine passée et créez un Notebook Datadog avec les résultats, y compris les modèles de défaillance courants et les correctifs recommandés. + +Pour les visualisations personnalisées qui vont au-delà des widgets Datadog standard, comme les graphiques de comparaison ou les diagrammes de quadrant, les Notebooks affichent également nativement les [diagrammes Mermaid][4]. Essayez des invites comme : + +- Analysez l'expérience `exp-456`, comparez les scores `accuracy` pour chaque version de prompt et exportez les résultats vers un Notebook Datadog incluant un graphique à barres Mermaid du score moyen pour chaque version. +- Analysez l'expérience `exp-456` et exportez un Notebook Datadog qui trace chaque version de prompt sur un graphique à quadrants Mermaid avec `relevance` sur un axe et `accuracy` sur l'autre. Identifiez les versions qui présentent des performances insuffisantes sur les deux dimensions. + +## Pour aller plus loin {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /fr/mcp_server/setup/ +[2]: /fr/llm_observability/ +[3]: /fr/notebooks/ +[4]: /fr/notebooks/guide/build_diagrams_with_mermaidjs/ +[5]: /fr/getting_started/site/ +[6]: /fr/account_management/api-app-keys/ +[7]: /fr/account_management/org_settings/service_accounts/ +[8]: https://github.com/datadog-labs/agent-skills +[9]: /fr/llm_observability/build_with_ai/claude_code_skills +[10]: /fr/llm_observability/investigate/annotation_queues \ No newline at end of file diff --git a/hugo/content/fr/logs/reports/_index.md b/hugo/content/fr/logs/reports/_index.md new file mode 100644 index 00000000000..3545dd1dc5d --- /dev/null +++ b/hugo/content/fr/logs/reports/_index.md @@ -0,0 +1,58 @@ +--- +title: Rapports CSV planifiés +--- +## Présentation {#overview} + +Les rapports CSV planifiés vous permettent de recevoir automatiquement des exportations de données structurées et récurrentes par e-mail, Slack ou Microsoft Teams. Cette fonctionnalité soutient les parties prenantes opérationnelles, de conformité et de direction en fournissant des instantanés périodiques des métriques clés sans avoir à se connecter à Datadog. + +## Définissez une requête {#define-a-query} + +Pour planifier un rapport CSV, la requête doit remplir les conditions suivantes : + +* La requête doit être créée à partir de [Log Explorer][1] +* Le résultat de la requête s'affiche sous forme de {{< ui >}}List{{< /ui >}} ou {{< ui >}}Table{{< /ui >}} (aucun autre type de visualisation n'est pris en charge) +* La requête n'est pas une requête composite (pas de [sous-requêtes][2]) +* La requête n'utilise pas de [calculated fields][3] ou de [Reference Tables][4] +* Le fichier CSV est limité à 50 000 lignes + +## Planifiez un rapport CSV {#schedule-a-csv-report} + +1. Dans [Log Explorer][1], exécutez la requête que vous souhaitez exporter. +2. Au-dessus des résultats de la requête, cliquez sur la flèche vers le bas à côté de {{< ui >}}Download as CSV{{< /ui >}}, puis sélectionnez {{< ui >}}Schedule CSV Report{{< /ui >}}. + + + {{< img src="logs/reports/schedule_csv_report_menu.png" alt="La barre d'outils des résultats du Log Explorer avec le menu déroulant à côté de Télécharger au format CSV développé, affichant les options Copier, Copier en tant que cURL, Partager l'événement et Planifier un rapport CSV" style="width:80%;" >}} + +3. Dans la fenêtre de configuration qui s'ouvre, définissez le planning du rapport afin de déterminer quand et à quelle fréquence le rapport est envoyé. +4. Configurez le rapport : définissez le titre du rapport et configurez une période pour déterminer l'intervalle de temps affiché dans le rapport résultant. La période du rapport peut être différente de la période affichée dans [Log Explorer]. +5. Ajoutez des destinataires : + 1. {{< ui >}}Email recipients{{< /ui >}} : Pour ajouter des destinataires par e-mail à votre rapport, saisissez leurs adresses e-mail. L'e-mail associé à votre compte Datadog est automatiquement ajouté en tant que destinataire. Vous pouvez vous retirer en tant que destinataire en survolant votre e-mail et en cliquant sur l'icône de corbeille qui apparaît à côté. + 2. {{< ui >}}Slack recipients{{< /ui >}} : Pour ajouter des destinataires Slack, sélectionnez l'espace de travail et le canal Slack dans les menus déroulants disponibles. Si vous ne voyez aucun espace de travail Slack disponible, assurez-vous que l'intégration [Slack Integration][5] de Datadog est installée. Tous les canaux publics au sein de l'espace de travail Slack devraient être listés automatiquement. Pour sélectionner un canal Slack privé, assurez-vous d'inviter le Datadog Slack bot dans le canal sur Slack. Pour envoyer un message de test sur Slack, ajoutez un destinataire de canal et cliquez sur {{< ui >}}Send Test Message{{< /ui >}}. + 3. {{< ui >}}Microsoft Teams recipients{{< /ui >}} : Sélectionnez l'onglet {{< ui >}}Microsoft Teams{{< /ui >}}, puis choisissez un {{< ui >}}Tenant{{< /ui >}}, un {{< ui >}}Team{{< /ui >}} et un {{< ui >}}Channel{{< /ui >}} dans les menus déroulants disponibles. Assurez-vous que l'intégration [Microsoft Teams][7] est installée dans votre organisation Datadog et que l'application Datadog est ajoutée à l'équipe cible dans Microsoft Teams. Pour envoyer un message de test, ajoutez un destinataire de canal et cliquez sur {{< ui >}}Send Test Message{{< /ui >}}. + +## Gestion des rapports {#managing-reports} + +Pour afficher les rapports CSV, accédez à [Log Explorer][1] et cliquez sur l'onglet {{< ui >}}Reports{{< /ui >}}. + +**Remarque** : Les rapports ne sont pas liés aux [Saved Views][6] et ne sont accessibles que via l'onglet Reports. + +* Vous devez disposer de l'autorisation `CSV Report Schedules Write` pour créer vos propres planifications de rapport. +* Vous devez disposer de l'autorisation `CSV Report Schedules Manage` pour modifier les planifications de rapport d'autres utilisateurs. + +Une fois un rapport créé, vous pouvez vous abonner, vous désabonner, modifier un planning et supprimer un rapport si vous disposez des autorisations appropriées. Si vous ne disposez pas des autorisations `CSV Report Schedules Write` ou `CSV Report Schedules Manage`, vous pouvez vous désabonner du rapport directement depuis un e-mail. + +## Vues des rapports {#reports-views} + +| Vue des rapports | Description | Permission requise | +| ----------------------------------- | ------------------------------------------------------------------------------- | ----------------------------- | +| {{< ui >}}Created by you{{< /ui >}} | Affiche tous les Scheduled CSV Reports que vous avez créés depuis [Log Explorer] | `CSV Report Schedules Write` | +| {{< ui >}}All Reports{{< /ui >}} | Affiche tous les Scheduled CSV Reports dans [Log Explorer] pour l'organisation dans laquelle vous vous trouvez | `CSV Report Schedules Manage` | +| {{< ui >}}Subscribed{{< /ui >}} | Affiche tous les Scheduled CSV Reports auxquels vous êtes abonnés | `CSV Report Schedules Write` | + +[1]: https://app.datadoghq.com/logs +[2]: /fr/logs/explorer/advanced_search/#filter-logs-with-subqueries +[3]: /fr/logs/explorer/calculated_fields/ +[4]: /fr/reference_tables/?tab=manualupload +[5]: /fr/integrations/slack/?tab=datadogforslack +[6]: /fr/logs/explorer/saved_views/#saved-views +[7]: /fr/integrations/microsoft_teams/ \ No newline at end of file diff --git a/hugo/content/fr/metrics/summary.md b/hugo/content/fr/metrics/summary.md index ac8f49fe403..4966effc6bd 100644 --- a/hugo/content/fr/metrics/summary.md +++ b/hugo/content/fr/metrics/summary.md @@ -12,158 +12,266 @@ further_reading: text: Distributions de métriques title: Metrics Summary --- +## Présentation {#overview} -## Présentation +La [page Metrics Summary][1] affiche la liste des métriques transmises à Datadog pendant un intervalle précis, à savoir l'heure précédente, le jour précédent ou la semaine précédente. -La [page Metrics Summary][1] affiche la liste des métriques transmises à Datadog pendant un intervalle précis, à savoir l'heure précédente, le jour précédent ou la semaine précédente. +Recherchez vos métriques par nom de métrique ou par tag en utilisant les champs de recherche {{< ui >}}Metric{{< /ui >}} ou {{< ui >}}Tag{{< /ui >}} : -Recherchez vos métriques par nom ou par tag à l'aide des champs de recherche **Metric** ou **Tag** : +{{< img src="metrics/summary/tag_advanced_filtering.png" alt="La page de résumé des métriques avec NOT team:* saisi dans la barre de recherche de tags" style="width:75%;">}} -{{< img src="metrics/summary/tagexplorer2.mp4" alt="Filtrer par tag" video=true style="width:75%;">}} +**Remarque** : Les valeurs de tag sont conservées dans le champ de recherche {{< ui >}}Tag{{< /ui >}} pendant 28 heures. Les valeurs non soumises au cours des 28 dernières heures n'apparaissent pas comme options de recherche, même si elles restent visibles dans le panneau latéral des détails de la métrique. -## Volet des facettes +Vous pouvez également découvrir des métriques pertinentes en utilisant la prise en charge améliorée de la recherche approximative (fuzzy matching) dans le champ de recherche Metrics : -Grâce aux barres de recherche, vous bénéficiez d'un vaste choix d'options vous permettant de filtrer la liste des métriques. Les facettes vous aident également à filtrer rapidement vos métriques en fonction des éléments suivants : -* **Configuration** : identifiez rapidement les métriques qui possèdent certaines configurations de tag ou des agrégations par centile supplémentaires. -* **Metric Type** : distinguez rapidement les métriques de distribution des autres métriques (counts, gauges, rates). -* **Distribution Metric Origin** : identifiez rapidement le produit qui a généré les métriques de distribution (par exemple, les logs, les spans, etc.). +{{< img src="metrics/summary/metric_advanced_filtering_fuzzy.png" alt="La page de résumé des métriques avec une recherche approximative sur shopist checkout" style="width:75%;">}} -{{< img src="metrics/summary/facets2.jpg" alt="Volet de facettes des métriques" style="width:75%;">}} +Le filtrage par tag prend en charge la syntaxe booléenne et les caractères génériques afin que vous puissiez identifier : +* Les métriques marquées avec une clé de tag particulière, par exemple, `team` : `team:*` +* Les métriques auxquelles il manque une clé de tag particulière, par exemple, `team` : `NOT team:*` +## Panneau de facettes {#facet-panel} -## Configuration de plusieurs métriques -Vous pouvez configurer plusieurs métriques à la fois à l'aide de deux boutons : +Les barres de recherche offrent l'ensemble d'actions le plus complet pour filtrer la liste des métriques. Mais les facettes peuvent également filtrer vos métriques par : -{{< img src="metrics/summary/configurationbuttons.jpg" alt="Boutons de configuration groupée" style="width:75%;">}} +- {{< ui >}}Configuration{{< /ui >}} : Métriques avec configurations de tags +- {{< ui >}}Percentiles{{< /ui >}} : Métriques de distribution activées par des centiles/capacités de requête avancées +- {{< ui >}}Historical Metrics{{< /ui >}} : Métriques pour lesquelles l'ingestion de métriques historiques est activée +- {{< ui >}}Query Activity{{< /ui >}} : Métriques non interrogées dans Datadog ou par l'API au cours des 30, 60 ou 90 derniers jours +- {{< ui >}}Related Assets{{< /ui >}} : Métriques utilisées dans des dashboards, notebooks, monitors et SLOs. +- {{< ui >}}Metric Type{{< /ui >}} : Différencier les métriques de distribution des métriques non liées à la distribution (comptes, jauges, taux) +- {{< ui >}}Metric Origin{{< /ui >}} : Le produit dont provient la métrique (par exemple, les métriques générées à partir de Logs ou d'APM Spans). Pour en savoir plus sur les différents types d'origine des métriques, consultez [Définitions de l'origine des métriques][12] -* **Calculate Percentiles** : cette option vous permet d'ajouter des agrégations par centile à plusieurs métriques de distribution. +### Définitions {#definitions} -{{< img src="metrics/summary/bulkpercentiles.jpg" alt="Centiles groupés" style="width:75%;">}} +Une métrique est **non interrogée** si elle n'a pas fait l'objet d'un accès dans des moniteurs, des SLO, des notebooks exécutés, des tableaux de bord ouverts, utilisée dans des requêtes Metrics Explorer ou accédée via des appels API au cours des 30, 60 ou 90 derniers jours. -* **Configure Tags** : cette option vous permet de configurer des tags pour plusieurs métriques custom partageant un espace de nommage commun à l'aide de la solution Metrics without Limits™. +Une métrique est considérée comme **utilisée** tant qu'elle existe sur une ressource, indépendamment du fait qu'elle ait été activement interrogée. -{{< img src="metrics/summary/bulkconfig.mp4" alt="Configuration groupée de tags pour les métriques" video=true style="width:75%;">}} +{{< img src="metrics/summary/facet_panel_2025-02-26.png" alt="Panneau de facettes des métriques" style="width:75%;">}} -## Volet latéral d'une métrique +## Configuration de plusieurs métriques {#configuration-of-multiple-metrics} -Cliquez sur un nom de métrique pour afficher dans son volet latéral des détails concernant les métadonnées et les tags de cette métrique : +Cliquer sur {{< ui >}}Configure Metrics{{< /ui >}} vous donne plusieurs options pour configurer plus d'une métrique à la fois : -{{< img src="metrics/summary/mwl_sidepanel.jpg" alt="Volet d'une métrique" style="width:75%;">}} +{{< img src="metrics/summary/configurationbuttons10-11-2024.png" alt="Boutons de configuration groupée" style="width:100%;">}} -### Metric name +* {{< ui >}}Manage tags{{< /ui >}} : Configurer des tags sur plusieurs métriques personnalisées correspondant à un espace de noms en utilisant Metrics without Limits™. -Le nom de votre métrique dans le [Metrics Explorer][2], les [dashboards][3], etc. +{{< img src="metrics/summary/tags-bulk-config.mp4" alt="Configuration groupée des tags de métrique" video="true" style="width:100%;" >}} -### Ingested Custom Metrics +* {{< ui >}}Enable or disable percentiles{{< /ui >}} : Gérer les agrégations de centiles sur plusieurs métriques de distribution. Consultez la [page Distributions][31] pour plus d'informations. -Un nom de métrique peut générer plusieurs métriques custom ingérées, en fonction de la combinaison de valeurs de tag qui lui est associée. Les métriques custom ingérées représentent toutes les données envoyées initialement avec le code. +{{< img src="metrics/summary/percentile_aggregations_toggle_2025-04-16.png" alt="Basculer pour gérer les agrégations de centiles" style="width:100%;">}} + +* {{< ui >}}Enable or disable historical metrics ingestion{{< /ui >}} : Gérer l'ingestion de données de métriques historiques. Consultez la [page Ingestion de métriques historiques][30] pour plus d'informations. + +## Panneau latéral des détails de la métrique {#metric-details-sidepanel} + +Cliquez sur un nom de métrique pour afficher dans son volet latéral des détails concernant les métadonnées et les tags de cette métrique : + +{{< img src="metrics/summary/mwl_sidepanel.jpg" alt="Volet de métrique" style="width:75%;">}} + +### Nom de la métrique {#metric-name} + +Le nom de votre métrique dans le [Metrics Explorer][2], les [dashboards][3], etc. + +### Métriques personnalisées ingérées {#ingested-custom-metrics} + +Un nom de métrique peut émettre plusieurs métriques personnalisées ingérées en fonction de ses combinaisons de valeurs de tags associées. Les métriques personnalisées ingérées représentent toutes les données soumises à l'origine avec le code. Pour en savoir plus, consultez la documentation relative aux [métriques custom][4]. -### Indexed Custom Metrics +### Métriques personnalisées indexées {#indexed-custom-metrics} -Contrairement aux métriques custom ingérées, les métriques custom indexées représentent les métriques qui peuvent être interrogées sur toute la plateforme Datadog. L'ajout ou la suppression d'agrégations par centile et l'utilisation de la solution Metrics without Limits™ sont susceptibles d'augmenter ou de diminuer le nombre de métriques custom ingérées. Pour en savoir plus, consultez la section [Metrics without Limits™][10]. +Contrairement aux métriques personnalisées ingérées, les métriques personnalisées indexées représentent celles qui restent interrogeables sur l'ensemble de la plateforme Datadog. Ce nombre peut être impacté par l'ajout ou la suppression d'agrégations de centiles ou par l'utilisation de Metrics without Limits™. En savoir plus dans la documentation [Metrics without Limits™][0]. -### Hosts +### Hôtes {#hosts} -Le nombre total de hosts qui transmettent une métrique. +Le nombre total de hosts qui transmettre une métrique. -### Valeurs de tag +### Valeurs de tag {#tag-values} Le nombre total de valeurs de tag uniques associées à une métrique. [En savoir plus sur le tagging][5]. -### Métadonnées de la métrique +### Métadonnées de métrique {#metrics-metadata} -Les métadonnées associées à votre métrique. La plupart des métadonnées peuvent être modifiées sur la page Metrics Summary ou avec l'[API Datadog][6]. +Les métadonnées associées à votre métrique. La plupart des métadonnées peuvent être modifiées sur la page de résumé des métriques ou avec la [Datadog API][6]. -#### Unité de la métrique +#### Unité de métrique {#metric-unit} -L'unité de votre métrique (byte, second, request, query, etc.). Consultez la page relative aux [unités de métriques][7] pour en savoir plus. +L'unité de votre métrique (octet, seconde, requête, interrogation, etc.). Consultez la page [metric unit][7] pour plus de détails. Lors de l'envoi de métriques custom à Datadog, vous pouvez modifier l'[unité de mesure][1] affichée lorsque vous passez votre curseur sur une métrique dans un graphique. -**Remarque** : ce changement n'a aucune incidence sur la représentation des métriques. Il affecte uniquement les unités de mesure utilisées pour les données brutes lorsque vous passez le curseur sur une métrique. Des règles de mise en forme sont automatiquement appliquées pour améliorer la lisibilité : par exemple, les octets (`B`) peuvent être affichés en tant que kibioctets (`KiB`). +**Remarque** : cela ne modifie pas la façon dont un graphique de métrique est affiché. Cela modifie uniquement les unités de mesure considérées pour les valeurs brutes lorsque vous survolez une métrique. Le formatage est automatiquement appliqué pour la lisibilité. Par exemple, les octets (`B`) peuvent être affichés en kilo-octets (`KiB`). + +#### Type de métrique {#metric-type} + +Le type de votre métrique (jauge, taux, compte, distribution). Consultez la page [metric type][8] pour plus de détails. + +**Avertissement** : La modification du type de métrique change le comportement de cette métrique pour **TOUS** vos dashboards et monitors. + +#### Nom de l'intégration {#integration-name} + +Si la métrique provient d'une [intégration][9] prise en charge, les métadonnées indiquent le nom de l'intégration. Ces informations ne peuvent pas être modifiées. + +#### Intervalle {#interval} + +L'intervalle de collecte pour la métrique en secondes. + +#### Description de la métrique {#metric-description} -#### Type de la métrique +La description de la métrique vous aide à comprendre ce qu'elle représente, pourquoi elle existe et comment elle est généralement utilisée. Utilisez ce champ pour générer une vue et mettre à jour les descriptions de vos [métriques personnalisées][4]. Les descriptions sont pré-remplies pour les métriques provenant d'[intégrations][9] prises en charge. -Le type de votre métrique (gauge, rate, count ou distribution). Consultez la page relative aux [types de métrique][8] pour en savoir plus. +#### Description générée par IA {#ai-generated-description} -**Attention** : tout changement de type de métrique entraîne la modification du comportement de cette métrique pour **TOUS** vos dashboards et monitors. +{{< site-region region="gov,gov2" >}} +
Les descriptions de métriques générées par IA ne sont pas disponibles pour le site Datadog sélectionné ({{< region-param key="dd_site_name" >}}).
+{{< /site-region >}} -#### Nom de l'intégration +Pour les métriques personnalisées, Datadog peut générer automatiquement des descriptions en utilisant le contexte disponible, notamment le nom de la métrique, les tags pertinents, l'activité des requêtes et le code source associé. Pour utiliser le code source comme contexte supplémentaire, installez l'intégration [GitHub][36], [GitLab][37] ou [Azure DevOps][38] de Datadog et connectez vos [dépôts][39]. -Si la métrique provient d'une [intégration][9] prise en charge, les métadonnées répertorient le nom de l'intégration. Cette information ne peut pas être modifiée. +{{< img src="metrics/summary/metric_ai_generated_descriptions_03062026.png" alt="Descriptions générées par IA dans le panneau latéral des métriques" style="width:80%;">}} -#### Intervalle -L'intervalle de collecte de la métrique en secondes. +## Code source {#source-code} -#### Description de la métrique +{{< site-region region="gov,gov2" >}} +
Le code source de la métrique n'est pas disponible pour le site Datadog sélectionné ({{< region-param key="dd_site_name" >}}).
+{{< /site-region >}} -La description de la métrique vous aide à mieux comprendre son utilité. Les descriptions sont prédéfinies pour les métriques provenant d'[intégrations][9] prises en charge. Utilisez ce champ pour mettre à jour les descriptions de vos [métriques custom][4]. +La section Code source du panneau latéral des métriques offre une vue centralisée de chaque métrique personnalisée et de son contexte sous-jacent. -### Tableau des tags +Utilisez la section Code source du panneau latéral des métriques pour identifier le code source d'une métrique, comprendre comment elle est générée et déterminer qui en est responsable. Elle offre une visibilité sur le contexte et la responsabilité, ce qui vous aide à résoudre les problèmes et à optimiser plus rapidement en établissant un lien direct vers le fichier source, l'historique des commits et les données de blame de la métrique. + +{{< img src="metrics/summary/metric_source_code_03262026.png" alt="Exemple de code source dans le panneau latéral des métriques" style="width:80%;">}} + +### Dépannage des métriques manquantes {#troubleshooting-missing-metrics} + +Si une métrique n'apparaît pas dans le code source, cela peut être dû à la manière dont elle est définie. + +Datadog détecte mieux les métriques lorsque les noms sont écrits sous forme de chaînes explicites. Les métriques créées à l'aide de variables, de constantes ou d'assistants personnalisés peuvent ne pas être détectées. + +Raisons courantes pour lesquelles des métriques sont manquantes : +- Le nom de la métrique est généré dynamiquement +- La métrique est émise via des wrappers personnalisés +- Le dépôt n'est pas entièrement indexé + +Bonne pratique : +- Définissez les noms de métriques sous forme de chaînes explicites lorsque cela est possible + +Exemple : + +Envoi d'une métrique à l'aide d'une variable (non recommandé) + +```java +public static final String METRIC_NAME = "my.metric.name"; +statsEmitter.distribution(METRIC_NAME, value, tags); +``` + +Envoi d'une métrique sous forme de chaîne explicite (recommandé) : + +```java +timer = meterRegistry.timer("my.metric.name"); +``` + +Pour garantir une couverture complète du code source de votre métrique, assurez-vous d'avoir installé l'intégration Datadog [GitHub][36], [GitLab][37] ou [Azure DevOps][38] et que tous vos [dépôts][39] sont connectés. + +### Tableau des tags {#tags-table} Le tableau des tags vous permet d'explorer de plusieurs façons toutes les clés et toutes les valeurs des tags qui sont activement transmises dans les données de votre métrique. Grâce au tableau des tags, vous pouvez accomplir les actions suivantes : -- Trier les clés de tag en fonction de la **colonne Count** (qui compte le nombre de valeurs de tag uniques) -- Rechercher une clé de tag spécifique dans le tableau des tags paginé -- Exporter le tableau des tags sous la forme d'un fichier CSV téléchargeable -- Basculer entre les tags que vous avez configurés pour votre métrique et ceux initialement envoyés avec la métrique +- Triez les clés de tag par la colonne {{< ui >}}Count{{< /ui >}} (nombre de valeurs de tag uniques). +- Recherchez une clé de tag particulière dans le tableau paginé des tags. +- Exportez le tableau des tags sous forme de fichier CSV téléchargeable. +- Basculez entre les tags que vous avez configurés sur votre métrique et les tags soumis à l'origine pour la métrique Pour chaque clé de tag spécifique, vous pouvez également effectuer les opérations suivantes : -- Passer en revue toutes les valeurs de tag de cette clé de tag -- Utiliser un tag spécifique au format `key:value` pour restreindre le nombre de métriques affichées sur la page Metrics Summary -- Ouvrir un graphique de votre métrique dans le Metrics Explorer, en appliquant un filtre basé sur la combinaison `key:value` de votre tag -- Copier la combinaison `key:value` d'un tag afin d'appliquer un filtre dans l'ensemble de l'application +- Inspectez toutes les valeurs de tag de cette clé de tag. +- Utilisez un tag spécifique `key:value` pour filtrer davantage la liste des métriques affichées sur la page Metrics Summary. +- Ouvrez un graphique de cette métrique filtré par votre paire `key:value` de tags dans Metrics Explorer. +- Copiez n'importe quel tag `key:value` pour filtrer dans l'ensemble de l'application. {{< img src="metrics/summary/updated_tags_table.mp4" alt="Tableau des tags" video=true style="width:75%;">}} [En savoir plus sur le tagging][5]. -## Metrics without Limits\* -La solution Metrics without Limits\* vous permet de contrôler le volume de vos métriques custom sans avoir à modifier vos Agents ou votre code. +### Ressources associées aux métriques {#metrics-related-assets} + +{{< img src="metrics/summary/related_assets_dashboards_08_05_2025.png" alt="Ressources associées pour un nom de métrique spécifié" style="width:80%;">}} + +Pour déterminer la valeur de n'importe quel nom de métrique pour votre organisation, utilisez les Ressources associées aux métriques. Les ressources associées aux métriques désignent tout dashboard, notebook, monitor ou SLO qui interroge une métrique particulière. -**Remarque :** Metrics without Limits\* fonctionne uniquement avec les métriques custom. +1. Faites défiler jusqu'au bas du panneau latéral des détails de la métrique vers la section {{< ui >}}Related Assets{{< /ui >}}. +2. Cliquez sur le bouton déroulant pour afficher le type de ressource associée qui vous intéresse (tableaux de bord, monitors, notebooks, SLO). Vous pouvez également utiliser la barre de recherche pour valider des ressources spécifiques. +3. La colonne {{< ui >}}Tags{{< /ui >}} indique exactement quelles balises sont utilisées dans chaque ressource. + +## Custom Metrics Tags Cardinality Explorer {#custom-metrics-tags-cardinality-explorer} -Vous pouvez configurer des tags à l'aide du bouton de configuration groupée de tags pour les métriques ou du bouton **Manage Tags**, situé dans le volet latéral des détails de la métrique. +{{< img src="metrics/tagsexplorer.png" alt="Custom Metrics Tags Cardinality Explorer pour un nom de métrique en pic" style="width:80%;">}} +Pour déterminer pourquoi un nom de métrique particulier émet un grand nombre de métriques personnalisées, ou présente un pic, utilisez Custom Metrics Tags Cardinality Explorer. Cela vous aide à identifier les clés de tags à l'origine du pic, que vous pouvez immédiatement exclure en utilisant Metrics without Limits™ pour réaliser des économies. -{{< img src="metrics/distributions/managetags.png" alt="Configuration des tags pour une distribution" style="width:80%;">}} +## Metrics without Limits™ {#metrics-without-limits} +Metrics without Limits™ vous permet de contrôler la taille de vos métriques personnalisées sans nécessiter de modifications au niveau de l'agent ou du code. -1. Cliquez sur le nom de la métrique de distribution custom dans le tableau **Metrics Summary** afin d'ouvrir le volet latéral des détails de la métrique. -2. Cliquez sur le bouton **Manage Tags** pour ouvrir une fenêtre de configuration des tags. -3. Cliquez sur l'onglet **Custom…** pour personnaliser les tags que vous souhaitez utiliser dans vos requêtes. Pour définir les tags à conserver, utilisez des _listes d'autorisation_. -4. Avant d'enregistrer vos modifications à l'aide de l'option **Save**, vérifiez l'impact de votre liste d'autorisation grâce à une estimation de la cardinalité. +**Remarque** : Metrics without Limits™ est uniquement disponible pour les métriques personnalisées. -**Remarque** : la personnalisation de tags via cette liste ne permet pas d'exclure de tags. L'ajout de tags débutant par `!` n'est pas accepté. De plus, pour obtenir une estimation de la cardinalité, la métrique doit exister depuis plus de 48 heures. +Vous pouvez [configurer des balises en masse](#configuration-of-multiple-metrics) en accédant à {{< ui >}}Configure Metrics{{< /ui >}} > {{< ui >}}Manage tags{{< /ui >}} sur la [page Métriques][34], ou en cliquant sur le bouton {{< ui >}}Manage Tags{{< /ui >}} dans le panneau latéral des détails d'une métrique. -### Tags interrogeables +{{< img src="metrics/distributions/managetags.png" alt="Configuration des balises sur une distribution" style="width:80%;">}} -Une fois votre métrique configurée via Metrics without Limits\*, vous pouvez visualiser les tags pouvant être interrogées, à savoir les tags qui rentrent en compte dans le calcul du volume des _métriques custom indexées_. Il est également possible de rétablir l'affichage de tous les tags qui ont été initialement envoyés et ingérés et qui rentrent dans le calcul des _métriques custom ingérées_. +1. Cliquez sur le nom de votre métrique de distribution personnalisée dans le tableau {{< ui >}}Metrics Summary{{< /ui >}} pour ouvrir le panneau latéral des détails des métriques. +2. Cliquez sur le bouton {{< ui >}}Manage Tags{{< /ui >}} pour ouvrir la modale de configuration des tags. +3. Sélectionnez {{< ui >}}Include tags...{{< /ui >}} ou {{< ui >}}Exclude tags...{{< /ui >}} pour personnaliser les tags que vous souhaitez ou ne souhaitez pas interroger. Pour plus d'informations sur la configuration des tags, consultez la documentation [Metrics without Limits][10]. +4. Prévisualisez les effets de votre configuration de tags proposée avec l'estimateur de cardinalité avant de sélectionner {{< ui >}}Save{{< /ui >}}. -### Optimiser votre métrique avec des agrégations grâce au mode Avancé +**Remarque** : L'estimateur de cardinalité nécessite que la métrique date de plus de 48 heures. -Vous pouvez ajuster les configurations des métriques custom de type count, gauge ou rate en ajoutant des agrégations supplémentaires facultatives. Pour ce faire, utilisez le mode Avancé de Metrics without Limits\*. Par défaut, pour veiller à la précision mathématique des requêtes de vos métriques configurées, Datadog stocke de la façon suivante la combinaison des agrégations les plus souvent interrogées en fonction du type de la métrique : +### Tags interrogeables {#queryable-tags} -- Les métriques count/rate configurées peuvent être interrogées à l'aide d'agrégations temporelles/spatiales de type `SUM`. -- Les métriques gauge configurées peuvent être interrogées à l'aide d'agrégations temporelles/spatiales de type `AVG`. +Une fois votre métrique configurée avec Metrics without Limits™, vous pouvez voir quels tags restent interrogeables, c'est-à-dire ceux qui contribuent au volume d'_Indexed Custom Metrics_. Et vous pouvez revenir à tous les tags initialement soumis et ingérés qui contribuent à votre volume d'_Ingested Custom Metrics_. -{{< img src="metrics/summary/customize_aggr_docs.jpg" alt="Ajuster les agrégations pour les métriques count, rate et gauge" style="width:80%;">}} +### Définitions de l'origine des métriques {#metric-origin-definitions} -D'autres agrégations sont disponibles en cas de besoin. Vous pouvez ajouter ou supprimer des agrégations à tout moment, sans avoir à modifier vos Agents ou votre code. +Ce tableau présente la correspondance entre l'origine de la métrique telle qu'elle apparaît dans la facette et sa source d'envoi : -**Remarque** : toute configuration d'une métrique count, rate ou gauge et toute suppression d'une agrégation peuvent entraîner la modification de vos monitors et dashboards existants. +| Origine de la métrique | Envoyé depuis | +| ------------------------| ----------------------------------------------------------------------------- | +| API Catalog | Séries temporelles envoyées par le produit [API Catalog][13] de Datadog depuis l'endpoint APIM. +| APM | Séries temporelles envoyées par le produit Datadog APM pour les métriques générées à partir de traces et de métriques de span. +| Agent | Séries temporelles envoyées par le Datadog Agent, collectées à partir des [Agent integrations][10], des [built-in integrations][9], de [DogStatsD][32] ou des [custom Agent checks][33]. +| Cloud Security | Séries temporelles envoyées par le produit [Cloud Security][14] de Datadog. +| Cloud Integrations | Séries temporelles collectées auprès de fournisseurs cloud comme AWS, Azure et Google Cloud, etc., à partir de leurs intégrations respectives. +| DBM | Séries temporelles envoyées par le produit [Database Monitoring][15] de Datadog, incluant des informations sur les activités/requêtes/verrous MySQL, Oracle et Postgres. +| DSM | Séries temporelles envoyées par le produit [Data Streams Monitoring][16] de Datadog, pour les métriques générées à partir des spans et traces DSM. +| Datadog Exporter | Séries temporelles envoyées par le [OpenTelemetry Collector][17] ou par le [Datadog Exporter][18]. +| Datadog Platform | Séries temporelles envoyées par l'ingestion de métriques qui sont utilisées pour [signaler l'utilisation des métriques][11]. +| Events | Séries temporelles générées à partir de la Datadog Events platform. +| Agent Observability | Séries temporelles émises par le produit Agent Observability utilisant le `lmobs_to_metrics` service. +| Logs | Séries temporelles générées à partir de la plateforme [Logs][28] de Datadog. +| Metrics API | Séries temporelles envoyées via le [OTLP Ingestion endpoint][21] de Datadog et le récepteur OTel avec des équivalents d'intégration Datadog ou des points pour les métriques d'utilisation estimées ou le Datadog API Client. +| CNM | Séries temporelles envoyées par le produit [Cloud Network Monitoring][19] de Datadog. +| Observability Pipelines | Séries temporelles envoyées par le produit [Observability Pipelines][20] de Datadog, incluant les métriques d'erreur et de performance. +| Autre | Séries temporelles qui n'ont pas d'équivalent d'intégration DD. +| Processes | Séries temporelles générées à partir du produit [Processes][22] de Datadog. +| RUM | Séries temporelles générées à partir du produit [Real User Monitoring][23] de Datadog. +| SAAS Integrations | Séries temporelles collectées à partir de plateformes SaaS populaires telles que Slack, Docker, PagerDuty, etc. +| Serverless | Séries temporelles envoyées par la plateforme [Serverless][24] de Datadog, incluant les métriques de Function, App Services, Cloud Run et Container App Metrics. +| Catalog | Séries temporelles envoyées par le produit [Catalog][25] de Datadog, incluant les métriques [Scorecard][29]. +| Synthetic Monitoring | Métriques de surveillance synthétique et de tests continus générées à partir du produit [Synthetic Monitoring][26] de Datadog. +| USM | Séries temporelles générées à partir du produit [Universal Service Monitoring][27] de Datadog. -## Pour aller plus loin +## Lectures complémentaires {#further-reading} {{< partial name="whats-next/whats-next.html" >}} -[10]:/fr/metrics/metrics-without-limits +[0]: /fr/metrics/metrics-without-limits [1]: https://app.datadoghq.com/metric/summary [2]: /fr/metrics/explorer/ [3]: /fr/dashboards/ @@ -172,4 +280,35 @@ D'autres agrégations sont disponibles en cas de besoin. Vous pouvez ajouter ou [6]: /fr/api/v1/metrics/#edit-metric-metadata [7]: /fr/metrics/units/ [8]: /fr/metrics/types/ -[9]: /fr/integrations/ \ No newline at end of file +[9]: /fr/integrations/ +[10]: /fr/integrations/agent_metrics/ +[11]: /fr/account_management/billing/usage_metrics/ +[12]: /fr/metrics/summary/#metric-origin-definitions +[13]: /fr/internal_developer_portal/catalog/endpoints/ +[14]: /fr/security/cloud_security_management/ +[15]: /fr/database_monitoring/ +[16]: /fr/data_streams/ +[17]: /fr/opentelemetry/setup/collector_exporter/ +[18]: /fr/opentelemetry/collector_exporter/ +[19]: /fr/network_monitoring/cloud_network_monitoring/ +[20]: /fr/observability_pipelines/ +[21]: /fr/opentelemetry/setup/otlp_ingest_in_the_agent/ +[22]: /fr/integrations/process/ +[23]: /fr/monitors/types/real_user_monitoring/ +[24]: /fr/serverless/ +[25]: /fr/internal_developer_portal/catalog/ +[26]: /fr/synthetics/ +[27]: /fr/universal_service_monitoring/ +[28]: /fr/logs/ +[29]: /fr/internal_developer_portal/scorecards/ +[30]: /fr/metrics/custom_metrics/historical_metrics/#bulk-configuration-for-multiple-metrics +[31]: /fr/metrics/distributions/#bulk-configuration-for-multiple-metrics +[32]: /fr/metrics/custom_metrics/dogstatsd_metrics_submission/ +[33]: /fr/metrics/custom_metrics/agent_metrics_submission/ +[34]: https://app.datadoghq.com/metric/overview +[35]: https://app.datadoghq.com/integrations?category=Source%20Control +[36]: https://app.datadoghq.com/integrations/github/configuration +[37]: https://app.datadoghq.com/integrations/gitlab-source-code +[38]: https://app.datadoghq.com/integrations/azure-devops-source-code?subPath=configuration +[39]: https://app.datadoghq.com/source-code/repositories +[40]: https://www.datadoghq.com/product-preview/metrics-source-code-attribution/ \ No newline at end of file diff --git a/hugo/content/fr/metrics/types.md b/hugo/content/fr/metrics/types.md index 7048f447aa4..fb63f03507e 100644 --- a/hugo/content/fr/metrics/types.md +++ b/hugo/content/fr/metrics/types.md @@ -12,6 +12,9 @@ aliases: - /fr/developers/metrics_type/ - /fr/developers/metrics/metrics_type/ - /fr/developers/metrics/types/ +description: Découvrez les types de soumission de métriques Datadog (nombre, taux, + jauge, histogramme, distribution) et la manière dont ils correspondent aux types + dans l'application. further_reading: - link: extend/dogstatsd tag: Documentation @@ -24,11 +27,11 @@ further_reading: text: Bibliothèques client de Datadog et sa communauté pour DogStatsD et les API title: Types de métriques --- -## Aperçu {#overview} +## Présentation {#overview} -Chaque métrique soumise à Datadog doit avoir un type. Le type d'une métrique influe sur la manière dont les valeurs de la métrique sont affichées lors des requêtes, ainsi que sur les possibilités de création de graphiques dans Datadog en utilisant des [modificateurs][1] et des [fonctions][2]. Le type d'une métrique est affiché dans le panneau latéral des détails pour la métrique donnée sur la [page Résumé des métriques][3]. +Chaque métrique soumise à Datadog doit avoir un type. Le type d'une métrique affecte la manière dont les valeurs de la métrique sont affichées lors d'une requête, ainsi que les possibilités de représentation graphique associées dans Datadog à l'aide de [modificateurs][1] et de [fonctions][2] supplémentaires. Le type d'une métrique est affiché dans le panneau latéral des détails pour la métrique donnée sur la [page Metrics Summary][3]. -**Remarque** : Modifier le type de métrique dans ce panneau latéral des détails peut modifier le comportement de la métrique dans toutes les visualisations et monitors existants, rendant potentiellement les données historiques incohérentes. +**Note** : La modification du type de métrique dans ce panneau latéral de détails peut modifier le comportement de la métrique dans toutes les visualisations et tous les monitors existants, rendant potentiellement les données historiques dénuées de sens. Les types d'envoi de métrique suivants sont acceptés : @@ -39,28 +42,30 @@ Les types d'envoi de métrique suivants sont acceptés : - [HISTOGRAM](?tab=histogram#metric-types) - [DISTRIBUTION](?tab=distribution#metric-types) -Ces différents types de métriques envoyés correspondent à quatre types de métriques stockés dans l'application Web Datadog : +Ces différents types de soumission de métriques sont mappés sur cinq types de métriques stockés dans l'application Web Datadog : -- COMPTE -- TAUX -- JAUGE +- COUNT +- RATE +- GAUGE - DISTRIBUTION +- HISTOGRAM (Explicit, Exponential) -**Remarque** : Si vous soumettez une métrique à Datadog sans type, le type de métrique apparaît comme `Not Assigned` dans Datadog. Le type de métrique `Not Assigned` ne peut pas être changé en un autre type dans l'application tant qu'un type de métrique initial n'est pas soumis. +**Remarque** : Si vous soumettez une métrique à Datadog sans type, le type de métrique apparaît comme {{< ui >}}Not Assigned{{< /ui >}} dans Datadog. Le type de métrique {{< ui >}}Not Assigned{{< /ui >}} ne peut pas être modifié en un autre type intégré tant qu'un type de métrique initial n'a pas été soumis. -## Soumission vs. type dans l'application {#submission-vs-in-app-type} +## Type envoyé et type stocké {#submission-vs-in-app-type} -Les métriques sont envoyées à Datadog de trois façons différentes : +Les métriques sont envoyées à Datadog de quatre manières principales : -- [Vérification de l'agent][5] +- [Check de l'Agent][5] - [DogStatsD][6] -- [Datadog's HTTP API][7] +- [API HTTP de Datadog][7] +- [API OTLP Metrics][20] -La majorité des données que Datadog reçoit est soumise par l'Agent, soit par le biais d'un [Agent check], soit par DogStatsD. Pour ces méthodes de soumission, le type d'une métrique détermine comment plusieurs valeurs collectées sur un Agent dans [un intervalle de temps de vidage][8] sont agrégées. L'Agent combine ces valeurs en une seule valeur métrique représentative pour cet intervalle. Cette valeur combinée est stockée avec un seul horodatage dans Datadog. +La majorité des données reçues par Datadog sont soumises par l'Agent, soit via [Agent check], soit via DogStatsD. Pour ces méthodes de soumission, le type d'une métrique détermine comment les valeurs multiples collectées sur un Agent dans [a flush time interval][8] sont agrégées. L'Agent combine ces valeurs en une seule valeur de métrique représentative pour cet intervalle. Cette valeur combinée est stockée avec un horodatage unique dans Datadog. -Les données soumises directement à l'API Datadog ne sont pas agrégées par Datadog, à l'exception des métriques de distribution. Les valeurs brutes envoyées à Datadog sont stockées telles quelles. +Les données envoyées directement à la Datadog API ne sont pas agrégées par Datadog, à l'exception des métriques de distribution. Les valeurs brutes envoyées à Datadog sont stockées telles quelles. -Lisez la section [Types de soumission et types dans l'application Datadog](#submission-types-and-datadog-in-app-types) pour en savoir plus sur la façon dont différents types de soumission de métriques sont mappés à leurs types correspondants dans l'application. +Lisez la section [Types envoyés et types stockés dans Datadog](#submission-types-and-datadog-in-app-types) pour en savoir plus sur la manière dont les différents types de soumission de métriques sont mappés à leurs types correspondants dans l'application. ## Types de métriques {#metric-types} @@ -69,90 +74,89 @@ Lisez la section [Types de soumission et types dans l'application Datadog](#subm {{< tabs >}} {{% tab "NOMBRE" %}} -Le type de soumission de métriques COUNT représente le nombre total d'occurrences d'événements dans un intervalle de temps. Un COUNT peut être utilisé pour suivre le nombre total de connexions établies à une base de données ou le nombre total de requêtes à un point de terminaison. Ce nombre d'événements peut s'accumuler ou diminuer au fil du temps—il n'est pas monotoniquement croissant. +Le type de soumission de métrique COUNT représente le nombre total d'occurrences d'événements dans un intervalle de temps. Un COUNT peut être utilisé pour suivre le nombre total de connexions établies vers une base de données ou le nombre total de requêtes vers un endpoint. Ce nombre d'événements peut augmenter ou diminuer au fil du temps ; il n'est pas strictement croissant. -**Remarque** : Un COUNT est différent du type de métrique RATE, qui représente le nombre d'occurrences d'événements normalisées par seconde compte tenu de l'intervalle de temps défini. +**Remarque** : Un COUNT est différent du type de métrique RATE, qui représente le nombre d'occurrences d'événements normalisé par seconde sur l'intervalle de temps défini. {{% /tab %}} {{% tab "RATE" %}} -Le type de soumission de métriques RATE représente le nombre total d'occurrences d'événements par seconde dans un intervalle de temps. Un RATE peut être utilisé pour suivre la fréquence à laquelle quelque chose se produit — par exemple, le nombre de connexions établies à une base de données ou le flux de requêtes adressées à un point de terminaison. +Le type de soumission de métrique RATE représente le nombre total d'occurrences d'événements par seconde dans un intervalle de temps. Un RATE peut être utilisé pour suivre la fréquence à laquelle quelque chose se produit, comme la fréquence des connexions établies vers une base de données ou le flux de requêtes effectuées vers un endpoint. -**Remarque** : Un RATE est différent du type de soumission de métriques COUNT, qui représente le nombre total d'occurrences d'événements dans l'intervalle de temps donné. +**Remarque** : Un RATE est différent du type de soumission de métrique COUNT, qui représente le nombre total d'occurrences d'événements dans l'intervalle de temps donné. {{% /tab %}} {{% tab "GAUGE" %}} -Le type de soumission de métriques GAUGE représente un instantané d'événements dans un intervalle de temps. Cette valeur d'instantané représentative est la dernière valeur soumise à l'Agent pendant un intervalle de temps. Un GAUGE peut être utilisé pour mesurer quelque chose qui rapporte en continu—comme l'espace disque disponible ou la mémoire utilisée. +Le type de soumission de métrique GAUGE représente un instantané des événements dans un intervalle de temps. Cette valeur instantanée représentative est la dernière valeur soumise à l'Agent pendant un intervalle de temps. Une GAUGE peut être utilisée pour prendre une mesure de quelque chose qui fait rapport en continu, comme l'espace disque disponible ou la mémoire utilisée. {{% /tab %}} {{% tab "HISTOGRAM" %}} -Le type de soumission de métriques HISTOGRAM représente la distribution statistique d'un ensemble de valeurs calculées côté Agent dans un intervalle de temps. Le type de métrique HISTOGRAM de Datadog est une extension du type de métrique de timing StatsD. L'Agent agrège les valeurs qui sont envoyées dans un intervalle de temps défini et produit différentes métriques qui représentent l'ensemble des valeurs. +Le type de soumission de métrique HISTOGRAM représente la distribution statistique d'un ensemble de valeurs calculées côté Agent dans un intervalle de temps. Le type de métrique HISTOGRAM de Datadog est une extension du type de métrique de timing StatsD. L'Agent agrège les valeurs envoyées dans un intervalle de temps défini et produit différentes métriques qui représentent l'ensemble des valeurs. -Si vous envoyez `X` valeurs pour une métrique HISTOGRAM `` dans un intervalle de temps donné, les métriques suivantes sont produites par défaut par l'Agent : +Si vous envoyez `X` valeurs pour une métrique HISTOGRAM `` dans un intervalle de temps donné, les métriques suivantes sont produites par l'Agent par défaut : `.avg` : Représente la moyenne de ces `X` valeurs dans l'intervalle de temps.
-**Type In-App de Datadog**: GAUGE +**Type dans l'application Datadog**: GAUGE `.count` -: Représente le nombre de valeurs soumises pendant l'intervalle, `X`. L'Agent soumet ce nombre en tant que RATE afin qu'il affiche dans l'application la valeur de `X/interval`.
-**Type In-App de Datadog**: RATE +: Représente le nombre de valeurs soumises pendant l'intervalle, `X`. L'Agent soumet ce nombre en tant que TAUX, de sorte qu'il affiche dans l'application la valeur de `X/interval`.
+**Type dans l'application Datadog**: RATE `.median` : Représente la médiane de ces `X` valeurs dans l'intervalle de temps.
-**Type In-App de Datadog** : GAUGE +**Type dans l'application Datadog** : GAUGE `.95percentile` -: Représente le 95ème percentile de ces `X` valeurs dans l'intervalle de temps.
-**Type In-App de Datadog** : GAUGE +: Représente le 95e percentile de ces `X` valeurs dans l'intervalle de temps.
+**Type dans l'application Datadog** : GAUGE `.max` : Représente la valeur maximale de ces `X` valeurs envoyées pendant l'intervalle de temps.
-**Type In-App de Datadog** : GAUGE +**Type dans l'application Datadog** : GAUGE **Remarques** : - Configurez les agrégations que vous souhaitez envoyer à Datadog avec le paramètre `histogram_aggregates` dans votre [`datadog.yaml` fichier de configuration][1]. Par défaut, seules les agrégations `max`, `median`, `avg` et `count` sont envoyées à Datadog. `sum` et `min` sont également disponibles. -- Configurez l'agrégation de percentile que vous souhaitez envoyer à Datadog avec le paramètre `histogram_percentiles` dans votre [`datadog.yaml` fichier de configuration][2]. Par défaut, seul le `95percentile` est envoyé à Datadog. +- Configurez l'agrégation de centiles que vous souhaitez envoyer à Datadog avec le paramètre `histogram_percentiles` dans votre [`datadog.yaml` fichier de configuration][1]. Par défaut, seule la `95percentile` est envoyée à Datadog. -[1]: https://github.com/DataDog/datadog-agent/blob/04d8ae9dd4bc6c7a64a8777e8a38127455ae3886/pkg/config/config_template.yaml#L106-L114 -[2]: https://github.com/DataDog/datadog-agent/blob/04d8ae9dd4bc6c7a64a8777e8a38127455ae3886/pkg/config/config_template.yaml#L116-L121 +[1]: https://github.com/DataDog/datadog-agent/blob/main/pkg/config/example/datadog-agent_linux.yaml.example {{% /tab %}} {{% tab "DISTRIBUTION" %}} -Le type de soumission de métriques DISTRIBUTION représente la distribution statistique globale d'un ensemble de valeurs calculées sur l'ensemble de votre infrastructure distribuée dans un intervalle de temps. Une DISTRIBUTION peut être utilisée pour instrumenter des objets logiques, comme des services, indépendamment des hôtes sous-jacents. +Le type de soumission de métrique DISTRIBUTION représente la distribution statistique globale d'un ensemble de valeurs calculées sur l'ensemble de votre infrastructure distribuée dans un intervalle de temps. Une DISTRIBUTION peut être utilisée pour instrumenter des objets logiques, comme des services, indépendamment des hosts sous-jacents. -Contrairement au type de métrique HISTOGRAM, qui agrège sur l'Agent pendant un intervalle de temps donné, une métrique DISTRIBUTION envoie toutes les données brutes pendant un intervalle de temps à Datadog. Les agrégations se produisent côté serveur. Parce que la structure de données sous-jacente représente des données brutes, non agrégées, les distributions offrent deux fonctionnalités majeures : +Contrairement au type de soumission de métrique HISTOGRAM, qui agrège les valeurs sur l'Agent durant un intervalle de temps donné, une métrique DISTRIBUTION envoie toutes les données brutes à Datadog pendant un intervalle de temps. Les agrégations se produisent côté serveur. Comme la structure de données sous-jacente représente des données brutes non agrégées, les distributions offrent deux fonctionnalités majeures : -- Calcul des agrégations de percentile -- Personnalisation des tags +- Calcul des agrégations de centiles +- Personnalisation du marquage -Si vous envoyez `X` valeurs pour une métrique DISTRIBUTION `` dans un intervalle de temps donné, les agrégations suivantes sont disponibles par défaut pour la requête : +Si vous envoyez `X` valeurs pour une métrique DISTRIBUTION `` dans un intervalle de temps donné, les agrégations suivantes sont disponibles par défaut pour les requêtes : `avg:` : Représente la moyenne de ces `X` valeurs dans l'intervalle de temps.
-**Type In-App de Datadog**: GAUGE +**Type dans l'application Datadog**: GAUGE `count:` : Représente le nombre de points soumis dans l'intervalle de temps, `X`. L'Agent l'envoie ensuite en tant que COUNT.
-**Type In-App Datadog**: COUNT +**Type dans l'application Datadog**: COUNT `max:` : Représente la valeur maximale de ces `X` valeurs envoyées dans l'intervalle de temps.
-**Type In-App Datadog** : GAUGE +**Type dans l'application Datadog** : GAUGE `min:` -: Représente la valeur minimale de ces `X` envoyées dans l'intervalle de temps.
-**Type In-App Datadog** : GAUGE +: Représente la valeur minimale de ces `X` valeurs envoyées dans l'intervalle de temps.
+**Type dans l'application Datadog** : GAUGE `sum:` -: Représente la somme de toutes les `X` valeurs envoyées dans l'intervalle de temps.
-**Type In-App Datadog** : COUNT +: Représente la somme de toutes les valeurs `X` envoyées dans l'intervalle de temps.
+**Type dans l'application Datadog** : COUNT -**Remarque** : Bien que les différentes agrégations des valeurs des métriques de distribution soient représentées sous forme de GAUGE ou de COUNT dans l'application, la métrique elle-même conserve le type `DISTRIBUTION`. +**Remarque** : Bien que les différentes agrégations des valeurs de métriques de distribution soient _représentées_ en tant que GAUGE ou COUNT dans l'application, la métrique elle-même conserve le type `DISTRIBUTION`. {{% /tab %}} {{< /tabs >}} @@ -162,30 +166,30 @@ Si vous envoyez `X` valeurs pour une métrique DISTRIBUTION `` dans {{< tabs >}} {{% tab "NOMBRE" %}} -Supposons que vous soumettiez une métrique COUNT, `notifications.sent`, depuis un seul hôte exécutant l'Agent Datadog. Cet hôte émet les valeurs suivantes dans un intervalle de temps de vidage : `[1,1,1,2,2,2,3,3]`. +Supposons que vous soumettiez une métrique COUNT, `notifications.sent`, depuis un seul host exécutant le Datadog Agent. Cet host émet les valeurs suivantes dans un intervalle de temps de vidage : `[1,1,1,2,2,2,3,3]`. -L'Agent additionne toutes les valeurs reçues dans un intervalle de temps. Ensuite, il soumet le nombre total, dans ce cas `15`, comme valeur de la métrique COUNT. +L'Agent ajoute toutes les valeurs reçues dans un intervalle de temps. Ensuite, il soumet le nombre total, dans ce cas `15`, en tant que valeur de la métrique COUNT. {{% /tab %}} {{% tab "RATE" %}} -Supposons que vous soumettiez une métrique RATE, `queue_messages.rate`, depuis un seul hôte exécutant l'Agent Datadog. Cet hôte émet les valeurs suivantes dans un intervalle de temps de vidage : `[1,1,1,2,2,2,3,3]`. +Supposons que vous soumettiez une métrique RATE, `queue_messages.rate`, depuis un seul host exécutant le Datadog Agent. Cet host émet les valeurs suivantes dans un intervalle de temps de vidage : `[1,1,1,2,2,2,3,3]`. -L'Agent additionne toutes les valeurs reçues dans un intervalle de temps. Ensuite, il soumet le nombre total divisé par le nombre total de secondes dans cet intervalle de temps. Dans ce cas, si l'intervalle de vidage est de 10 secondes, la valeur soumise serait `1.5` comme valeur de la métrique RATE. +L'Agent ajoute toutes les valeurs reçues dans un intervalle de temps. Ensuite, il soumet le nombre total divisé par le nombre total de secondes dans cet intervalle de temps. Dans ce cas, si l'intervalle de vidage est de 10 secondes, la valeur soumise serait `1.5` en tant que valeur de la métrique RATE. {{% /tab %}} {{% tab "GAUGE" %}} -Supposons que vous soumettiez une métrique GAUGE, `temperature`, depuis un seul hôte exécutant l'Agent Datadog. Cet hôte émet les valeurs suivantes dans un intervalle de temps de vidage : `[71,71,71,71,71,71,71.5]`. +Supposons que vous soumettiez une métrique GAUGE, `temperature`, depuis un seul host exécutant le Datadog Agent. Cet host émet les valeurs suivantes dans un intervalle de temps de vidage : `[71,71,71,71,71,71,71.5]`. -L'Agent soumet le dernier nombre rapporté, dans ce cas `71.5`, comme valeur de la métrique GAUGE. +L'Agent soumet le dernier nombre rapporté, dans ce cas `71.5`, en tant que valeur de la métrique GAUGE. {{% /tab %}} {{% tab "HISTOGRAM" %}} -Par exemple, supposons que vous soumettiez une métrique HISTOGRAM, `request.response_time.histogram`, depuis un serveur web qui rapporte les valeurs `[1,1,1,2,2,2,3,3]` pendant une période de flush de 10 secondes. Par défaut, l'Agent soumet les métriques suivantes à Datadog qui représentent la distribution statistique de ces valeurs dans cet intervalle de temps : +Par exemple, supposons que vous soumettiez une métrique HISTOGRAM, `request.response_time.histogram`, depuis un serveur web qui rapporte les valeurs `[1,1,1,2,2,2,3,3]` dans un intervalle de vidage de 10 secondes. Par défaut, l'Agent soumet les métriques suivantes à Datadog, qui représentent la distribution statistique de ces valeurs dans cet intervalle de temps : -| Nom de la métrique | Valeur | Type dans l’application Datadog | +| Nom de la métrique | Valeur | Type dans l'application Datadog | | ---------------------------------------------- | ------ | ------------------- | | `request.response_time.histogram.avg` | `1.88` | GAUGE | | `request.response_time.histogram.count` | `0.8` | RATE | @@ -196,9 +200,9 @@ Par exemple, supposons que vous soumettiez une métrique HISTOGRAM, `request.res {{% /tab %}} {{% tab "DISTRIBUTION" %}} -Supposons que vous soumettiez une métrique DISTRIBUTION, `request.response_time.distribution`, depuis deux serveurs web : `webserver:web_1` et `webserver:web_2`. Supposons que dans un intervalle de temps de flush donné, `webserver:web_1` rapporte la métrique avec les valeurs `[1,1,1,2,2,2,3,3]`, et `webserver:web_2` rapporte la même métrique avec les valeurs `[1,1,2]`. Au cours de cet intervalle de temps, les cinq agrégations suivantes représenteront la distribution statistique globale de toutes les valeurs collectées à partir des deux serveurs web : +Supposons que vous soumettiez une métrique DISTRIBUTION, `request.response_time.distribution`, depuis deux serveurs web : `webserver:web_1` et `webserver:web_2`. Supposons que dans un intervalle de temps de vidage donné, `webserver:web_1` rapporte la métrique avec les valeurs `[1,1,1,2,2,2,3,3]`, et `webserver:web_2` rapporte la même métrique avec les valeurs `[1,1,2]`. Sur cet intervalle de temps, les cinq agrégations suivantes représenteront la distribution statistique globale de toutes les valeurs collectées à partir des deux serveurs web : -| Nom de la métrique | Valeur | Type dans l’application Datadog | +| Nom de la métrique | Valeur | Type dans l'application Datadog | | ------------------------------------------ | ------ | ------------------- | | `avg:request.response_time.distribution` | `1.73` | GAUGE | | `count:request.response_time.distribution` | `11` | COUNT | @@ -206,13 +210,13 @@ Supposons que vous soumettiez une métrique DISTRIBUTION, `request.response_time | `min:request.response_time.distribution` | `1` | GAUGE | | `sum:request.response_time.distribution` | `19` | COUNT | -#### Calcul des agrégations de percentile {#calculation-of-percentile-aggregations} +#### Calcul des agrégations de centiles {#calculation-of-percentile-aggregations} -Comme d'autres types de métriques, tels que GAUGE ou HISTOGRAM, le type de métrique DISTRIBUTION a les agrégations suivantes disponibles : `count`, `min`, `max`, `sum`, et `avg`. Les métriques de distribution sont initialement étiquetées de la même manière que les autres métriques (avec des étiquettes personnalisées définies dans le code). +Comme pour les autres types de métriques, tels que GAUGE ou HISTOGRAM, le type de métrique DISTRIBUTION propose les agrégations suivantes : `count`, `min`, `max`, `sum` et `avg`. Les métriques de distribution sont initialement taguées de la même manière que les autres métriques (avec des tags personnalisés définis dans le code). -Des agrégations de percentile supplémentaires (`p50`, `p75`, `p90`, `p95`, `p99`) peuvent être ajoutées aux métriques de distribution depuis le [panneau latéral des détails][2] de la métrique. Si vous deviez ajouter des agrégations de percentile à votre métrique de distribution dans l'application, les cinq agrégations supplémentaires suivantes sont disponibles pour la requête : +Des agrégations de centiles supplémentaires (`p50`, `p75`, `p90`, `p95`, `p99`) peuvent être ajoutées aux métriques de distribution depuis le [panneau latéral des détails][2] de la métrique. Si vous ajoutiez des agrégations de centiles à votre métrique de distribution dans l'application, les cinq agrégations supplémentaires suivantes seraient disponibles pour la requête : -| Nom de la métrique | Valeur | Type dans l’application Datadog | +| Nom de la métrique | Valeur | Type dans l'application Datadog | | ---------------------------------------- | ----- | ------------------- | | `p50:request.response_time.distribution` | `2` | GAUGE | | `p75:request.response_time.distribution` | `2` | GAUGE | @@ -220,15 +224,15 @@ Des agrégations de percentile supplémentaires (`p50`, `p75`, `p90`, `p95`, `p9 | `p95:request.response_time.distribution` | `3` | GAUGE | | `p99:request.response_time.distribution` | `3` | GAUGE | -C'est-à-dire que pour une métrique de distribution avec des agrégations de percentile ajoutées pendant un intervalle de temps donné, les 10 agrégations suivantes sont disponibles : `count`, `sum`, `min`, `max`, `avg`, `p50`, `p75`, `p90`, `p95`, et `p99`. +C'est-à-dire que pour une métrique de distribution avec des agrégations de centiles ajoutées au cours d'un intervalle de temps donné, les 10 agrégations suivantes sont disponibles : `count`, `sum`, `min`, `max`, `avg`, `p50`, `p75`, `p90`, `p95` et `p99`. -**Remarque** : Bien que les différentes agrégations des valeurs métriques de distribution soient _représentées_ sous forme de jauges ou de comptes dans l'application, la métrique elle-même conserve le type `DISTRIBUTION`. +**Remarque** : Bien que les différentes agrégations des valeurs de métriques de distribution soient _représentées_ en tant que GAUGE ou COUNT dans l'application, la métrique elle-même conserve le type `DISTRIBUTION`. -#### Personnalisation des étiquettes {#customization-of-tagging} +#### Personnalisation du tagging {#customization-of-tagging} -Cette fonctionnalité vous permet de contrôler l'étiquetage pour les métriques où la granularité au niveau de l'hôte n'est pas nécessaire. En savoir plus sur [Metrics without Limits™][1]. +Cette fonctionnalité vous permet de contrôler le tagging pour les métriques où une granularité au niveau du host n'est pas nécessaire. En savoir plus sur [Metrics without Limits™][1]. -**Remarque** : L'exclusion des étiquettes n'est pas prise en charge dans la personnalisation des étiquettes basée sur la liste autorisée. L'ajout d'étiquettes commençant par `!` n'est pas accepté. +**Remarque** : L'exclusion de tags n'est pas prise en charge dans la personnalisation des tags basée sur une liste d'autorisation. L'ajout de tags commençant par `!` n'est pas accepté. [1]: /fr/metrics/metrics-without-limits/ [2]: /fr/metrics/summary/#metric-details-sidepanel @@ -244,14 +248,14 @@ Envoyez vos métriques de type COUNT depuis l'une des sources suivantes : | Source de soumission | Méthode de soumission (python) | Type de soumission | Type dans l'application Datadog | | ----------------- | ------------------------------------ | --------------- | ------------------- | -| [Vérification de l'agent][1] | `self.count(...)` | COUNT | COUNT | -| [Vérification de l'agent][2] | `self.monotonic_count(...)` | COUNT | COUNT | +| [Check de l'Agent][1] | `self.count(...)` | COUNT | COUNT | +| [Check de l'Agent][2] | `self.monotonic_count(...)` | COUNT | COUNT | | [API][3] | `api.Metric.send(type="count", ...)` | COUNT | COUNT | | [DogStatsD][4] | `dog.count(...)` | COUNT | RATE | | [DogStatsD][4] | `dog.increment(...)` | COUNT | RATE | | [DogStatsD][4] | `dog.decrement(...)` | COUNT | RATE | -**Remarque** : Lors de la soumission d'une métrique de type COUNT via DogStatsD, la métrique apparaît comme un RATE dans l'application pour garantir une comparaison pertinente entre différents agents. Par conséquent, les COUNT StatsD peuvent apparaître avec une valeur décimale dans Datadog (puisqu'ils sont normalisés sur un intervalle de temps pour rapporter des unités par seconde). +**Remarque** : Lors de la soumission d'un type de métrique COUNT via DogStatsD, la métrique apparaît comme un RATE dans l'application pour garantir une comparaison pertinente entre différents Agents. Par conséquent, les comptes StatsD peuvent apparaître avec une valeur décimale dans Datadog (puisqu'ils sont normalisés sur un intervalle de temps pour rapporter des unités par seconde). [1]: /fr/metrics/custom_metrics/agent_metrics_submission/?tab=count#count @@ -265,10 +269,10 @@ Envoyez vos métriques de type RATE depuis l'une des sources suivantes : | Source de soumission | Méthode de soumission (python) | Type de soumission | Type dans l'application Datadog | | ----------------- | ----------------------------------- | --------------- | ------------------- | -| [Vérification de l'agent][1] | `self.rate(...)` | TAUX | JAUGE | -| [API][2] | `api.Metric.send(type="rate", ...)` | TAUX | TAUX | +| [Check de l'Agent][1] | `self.rate(...)` | RATE | GAUGE | +| [API][2] | `api.Metric.send(type="rate", ...)` | RATE | RATE | -**Remarque** : Pour obtenir des métriques de RATE via DogStatsD, soumettez soit une métrique COUNT soit une métrique HISTOGRAM. Les valeurs de la métrique COUNT et `.count` sont des deltas normalisés dans le temps de la valeur de la métrique sur la période de flush de StatsD. +**Remarque** : Pour obtenir des métriques de type RATE via DogStatsD, soumettez soit une métrique [COUNT][16], soit une métrique [HISTOGRAM][18]. Les valeurs des métriques COUNT et `.count` sont des deltas normalisés dans le temps de la valeur de la métrique sur la période de flush de StatsD. [1]: /fr/metrics/custom_metrics/agent_metrics_submission/?tab=rate @@ -280,7 +284,7 @@ Envoyez vos métriques de type GAUGE depuis l'une des sources suivantes : | Source de soumission | Méthode de soumission (Python) | Type de soumission | Type dans l'application Datadog | | ----------------- | ------------------------------------ | --------------- | ------------------- | -| [Vérification de l'agent][1] | `self.gauge(...)` | GAUGE | GAUGE | +| [Check de l'Agent][1] | `self.gauge(...)` | GAUGE | GAUGE | | [API][2] | `api.Metric.send(type="gauge", ...)` | GAUGE | GAUGE | | [DogStatsD][3] | `dog.gauge(...)` | GAUGE | GAUGE | @@ -293,12 +297,12 @@ Envoyez vos métriques de type GAUGE depuis l'une des sources suivantes : Envoyez vos métriques de type HISTOGRAM depuis l'une des sources suivantes : -| Source de soumission | Méthode de soumission (Python) | Type de soumission | Types dans l'application Datadog | +| Source de soumission | Méthode de soumission (Python) | Type de soumission | Types Datadog dans l'application | | ----------------- | -------------------------- | --------------- | -------------------- | -| [Vérification de l'agent][1] | `self.histogram(...)` | HISTOGRAM | GAUGE, RATE | +| [Check de l'Agent][1] | `self.histogram(...)` | HISTOGRAM | GAUGE, RATE | | [DogStatsD][2] | `dog.histogram(...)` | HISTOGRAM | GAUGE, RATE | -Soumettre une métrique TIMER à l'Agent Datadog équivaut à soumettre une métrique de type HISTOGRAM via DogStatsD (à ne pas confondre avec les timers du StatsD standard). [DogStatsD `TIMER`][3] représente uniquement des données de durée. Par exemple, le temps qu'une section de code met à s'exécuter ou combien de temps il faut pour rendre complètement une page. +La soumission d'une métrique TIMER au Datadog Agent équivaut à la soumission d'un type de métrique HISTOGRAM dans DogStatsD (à ne pas confondre avec les timers dans le StatsD standard). [DogStatsD `TIMER`][3] représente uniquement des données de durée. Par exemple, le temps qu'une section de code met à s'exécuter ou le temps nécessaire pour rendre entièrement une page. [1]: /fr/metrics/custom_metrics/agent_metrics_submission/?tab=histogram @@ -309,29 +313,29 @@ Soumettre une métrique TIMER à l'Agent Datadog équivaut à soumettre une mét Envoyez vos métriques de type DISTRIBUTION depuis la source suivante : -| Source de soumission | Méthode de soumission (Python) | Type de soumission | Types dans l'application Datadog | +| Source de soumission | Méthode de soumission (Python) | Type de soumission | Types Datadog dans l'application | | ----------------- | -------------------------- | --------------- | -------------------- | | [DogStatsD][1] | `dog.distribution(...)` | DISTRIBUTION | GAUGE, COUNT | | [API][2] | `api_instance.submit_distribution_points(...)` | DISTRIBUTION | GAUGE, COUNT | -**Remarque**: Bien que les différentes agrégations des valeurs métriques de distribution soient _représentées_ sous forme de gauges ou de counts dans l'application, la métrique elle-même conserve le type `DISTRIBUTION`. +**Remarque** : Bien que les différentes agrégations des valeurs de métriques de distribution soient _représentées_ en tant que GAUGE ou COUNT dans l'application, la métrique elle-même conserve le type `DISTRIBUTION`. [1]: /fr/metrics/custom_metrics/dogstatsd_metrics_submission/#distribution [2]: /fr/api/latest/metrics/#submit-distribution-points {{% /tab %}} {{< /tabs >}} -## Types de soumission et types dans l'application Datadog {#submission-types-and-datadog-in-app-types} +## Types envoyés et types stockés dans Datadog {#submission-types-and-datadog-in-app-types} -Ci-dessous se trouve un résumé de toutes les sources et méthodes de soumission de métriques disponibles. Ce tableau montre la correspondance entre le type de soumission de métrique correspondant et les types dans l'application : +Vous trouverez ci-dessous un résumé de toutes les sources et méthodes de soumission de métriques disponibles. Ce tableau présente le mappage entre le type de soumission de métrique correspondant et les types dans l'application : -| Source de soumission | Méthode de soumission (Python) | Type de soumission | Types dans l'application Datadog | +| Source de soumission | Méthode de soumission (Python) | Type de soumission | Type dans l'application Datadog | | ----------------- | ------------------------------------ | --------------- | -------------------- | -| [Vérification de l'agent][9] | `self.count(...)` | COUNT | COUNT | -| [Vérification de l'agent][10] | `self.monotonic_count(...)` | COUNT | COUNT | -| [Vérification de l'agent][11] | `self.gauge(...)` | GAUGE | GAUGE | -| [Agent check][12] | `self.histogram(...)` | HISTOGRAM | GAUGE, RATE | -| [Vérification de l'agent][13] | `self.rate(...)` | RATE | GAUGE | +| [Check de l'Agent][9] | `self.count(...)` | COUNT | COUNT | +| [Check de l'Agent][10] | `self.monotonic_count(...)` | COUNT | COUNT | +| [Check de l'Agent][11] | `self.gauge(...)` | GAUGE | GAUGE | +| [Check de l'Agent][12] | `self.histogram(...)` | HISTOGRAM | GAUGE, RATE | +| [Check de l'Agent][13] | `self.rate(...)` | RATE | GAUGE | | [API][7] | `api.Metric.send(type="count", ...)` | COUNT | COUNT | | [API][7] | `api.Metric.send(type="gauge", ...)` | GAUGE | GAUGE | | [API][7] | `api.Metric.send(type="rate", ...)` | RATE | RATE | @@ -343,9 +347,9 @@ Ci-dessous se trouve un résumé de toutes les sources et méthodes de soumissio | [DogStatsD][17] | `dog.set(...)` | SET | GAUGE | | [DogStatsD][18] | `dog.histogram(...)` | HISTOGRAM | GAUGE, RATE | -**Remarque :** Bien que les différentes agrégations des valeurs de distribution soient _représentées_ sous forme de GAUGE ou de COUNT dans l'application, la métrique elle-même conserve le type `DISTRIBUTION`. Consultez la section [Définitions][19] de cette page pour plus d'informations. +**Remarque** : Bien que les différentes agrégations des valeurs de métriques de distribution soient _représentées_ en tant que GAUGE ou COUNT dans l'application, la métrique elle-même conserve le type `DISTRIBUTION`. Consultez la section [Définitions][19] de cette page pour plus d'informations. -## Lectures complémentaires {#further-reading} +## Pour aller plus loin {#further-reading} {{< partial name="whats-next/whats-next.html" >}} @@ -367,4 +371,5 @@ Ci-dessous se trouve un résumé de toutes les sources et méthodes de soumissio [16]: /fr/metrics/custom_metrics/dogstatsd_metrics_submission/#count [17]: /fr/metrics/custom_metrics/dogstatsd_metrics_submission/#set [18]: /fr/metrics/custom_metrics/dogstatsd_metrics_submission/#histogram -[19]: /fr/metrics/types/?tab=distribution#definition \ No newline at end of file +[19]: /fr/metrics/types/?tab=distribution#definition +[20]: /fr/opentelemetry/setup/otlp_ingest/metrics/ \ No newline at end of file diff --git a/hugo/content/fr/monitors/guide/on_missing_data.md b/hugo/content/fr/monitors/guide/on_missing_data.md new file mode 100644 index 00000000000..bcdef8ecaf7 --- /dev/null +++ b/hugo/content/fr/monitors/guide/on_missing_data.md @@ -0,0 +1,95 @@ +--- +description: Migrez des anciennes configurations « No Data » vers les options « On + Missing Data » pour une meilleure gestion des données manquantes dans les monitors + de métriques. +further_reading: +- link: /api/latest/monitors/ + tag: API + text: Documentation de l'API Monitors +title: Migration vers la configuration « On Missing Data » +--- +## Présentation {#overview} + +Les monitors de métriques offrent des options améliorées pour la gestion des données manquantes, vous permettant de différencier les données manquantes en tant que mode de défaillance et en tant qu'état sain. + +Ces options s'alignent sur ce qui est disponible dans d'autres types de monitors comme les logs, les événements, la CI, les bases de données, Error Tracking, et plus encore. + +## Avantages de l'utilisation des options « On Missing Data » {#benefits-of-using-on-missing-data-options} + +Lors de la mesure du nombre d'événements indésirables, tels que des erreurs, les monitors doivent indiquer « OK » lorsqu'aucune donnée n'est détectée. Avec les anciennes configurations « No Data », les monitors signalaient « No Data ». Les options de configuration « On Missing Data » permettent aux monitors de refléter plus précisément les états de santé, améliorant ainsi la clarté. + +## Monitors gérés via l'interface utilisateur {#monitors-managed-through-the-ui} + +Si vous gérez vos monitors depuis l'interface utilisateur, la configuration se met automatiquement à jour la prochaine fois que vous les modifiez. Pour mettre à jour la configuration « On Missing Data » plus rapidement, consultez les sections suivantes sur l'ajustement via l'API. + +## Monitors gérés via l'API ou Terraform {#monitors-managed-through-the-api-or-terraform} + +Si vous gérez vos monitors avec l'API ou Terraform, remplacez `notify_no_data` et `no_data_timeframe` par `on_missing_data`. Le paramètre `no_data_timeframe` n'est pas requis car `on_missing_data` utilise la même période que la fenêtre temporelle. + +### Paramètres de l'API {#api-parameters} + +L'ancien paramètre « No Data », `notify_no_data`, reste disponible sur les monitors existants et n'est pas automatiquement mis à niveau vers les nouvelles fonctionnalités `on_missing_data`. + +| Paramètre | Description dans l'interface utilisateur | +|-----------------------------------------|----------------------------------------------------------------------------------------------------| +| `"on_missing_data": "show_and_notify_no_data"` | Si des données sont manquantes {{< ui >}}Show NO DATA and notify{{< /ui >}}
(Auparavant, « {{< ui >}}Notify if data is missing{{< /ui >}} ») | +| `"on_missing_data": "show_no_data"` | Si des données sont manquantes {{< ui >}}Show NO DATA{{< /ui >}}
(Auparavant, « {{< ui >}}Do not notify if data is missing{{< /ui >}} ») | +| `"on_missing_data": "resolve"` | Si des données sont manquantes {{< ui >}}Show OK{{< /ui >}} | +| `"on_missing_data": "default"` en cas d'utilisation de l'agrégation somme ou compte | Si des données sont manquantes {{< ui >}}Evaluate as 0{{< /ui >}} (ou autre valeur par défaut) | +| `"on_missing_data": "default"` en cas d'utilisation de tous les autres types d'agrégation | Si des données sont manquantes {{< ui >}}Show last known status{{< /ui >}} | + +Pour tous les champs disponibles, consultez la [Documentation de l'API][1]. + +Voici un exemple avant et après d'un monitor JSON avec ces champs: + +**Avant** +{{< highlight yaml "hl_lines=11-12" >}}{ + "name": "CPU usage is high for host $host.value", + "type": "query alert", + "query": "avg(last_5m):100 - avg:system.cpu.idle{$host} > 90", + "message": "A high CPU usage has been detected for host $host.value, which can impact the system performance.", + "tags": [], + "options": { + "thresholds": { "critical": 90 }, + "notify_audit": false, + "include_tags": false, + "notify_no_data": true, + "no_data_timeframe": 10 + } +} +{{< /highlight >}} + + +**Après** +{{< highlight yaml "hl_lines=11" >}}{ + "name": "CPU usage is high for host $host.value", + "type": "query alert", + "query": "avg(last_5m):100 - avg:system.cpu.idle{$host} > 90", + "message": "A high CPU usage has been detected for host $host.value, which can impact the system performance.", + "tags": [], + "options": { + "thresholds": { "critical": 90 }, + "notify_audit": false, + "include_tags": false, + "on_missing_data": "show_and_notify_no_data" + } +} +{{< /highlight >}} + +## SLO basés sur des monitors {#monitor-based-slos} + +Les SLO traitent la disponibilité et le downtime selon cette correspondance : + +| Configuration « On Missing Data » | Statut du monitor | Traitement SLO | +|-------------------------------|--------------------------------|-----------------------------| +| {{< ui >}}Show OK{{< /ui >}} | OK | Disponibilité | +| {{< ui >}}Show No Data{{< /ui >}} | No Data | Disponibilité | +| {{< ui >}}Show No Data and Notify{{< /ui >}} | No Data | Downtime | +| {{< ui >}}Show last known status{{< /ui >}} | Quel que soit le dernier statut | Si OK, Disponibilité
Si Alerte, Downtime | +| {{< ui >}}Evaluate as zero{{< /ui >}} | Dépend de la configuration du seuil | Si OK, Disponibilité
Si Alerte, Downtime | + +## Pour aller plus loin {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://docs.datadoghq.com/fr/api/latest/monitors/ \ No newline at end of file diff --git a/hugo/content/fr/network_monitoring/netflow/_index.md b/hugo/content/fr/network_monitoring/netflow/_index.md index 7bf94ed8000..70318af3738 100644 --- a/hugo/content/fr/network_monitoring/netflow/_index.md +++ b/hugo/content/fr/network_monitoring/netflow/_index.md @@ -5,46 +5,49 @@ further_reading: - link: /network_monitoring/devices/profiles tag: Documentation text: Utiliser des profils avec le Network Device Monitoring +- link: /network_monitoring/network_path/setup/#dynamic-tests-for-netflow-experimental + tag: Documentation + text: Configurer des tests dynamiques pour NetFlow - link: https://www.datadoghq.com/blog/monitor-netflow-with-datadog/ tag: Blog - text: Surveillez les données de trafic NetFlow avec Datadog + text: Surveiller les données de trafic NetFlow avec Datadog - link: https://www.datadoghq.com/blog/diagnose-network-performance-with-snmp-trap-monitoring/ tag: Blog text: Surveiller et résoudre des problèmes de performances réseau avec des interruptions SNMP title: NetFlow Monitoring --- -## Aperçu {#overview} +## Présentation {#overview} -La vue NetFlow dans la surveillance des dispositifs réseau offre une visibilité sur les flux de trafic réseau collectés à partir des dispositifs qui exportent des données de flux (par exemple, des routeurs, des pare-feu ou des commutateurs). Vous pouvez analyser le volume de trafic, identifier les principaux émetteurs et comprendre comment les données circulent dans votre réseau. +La vue NetFlow dans Network Device Monitoring offre une visibilité sur les flux de trafic réseau collectés à partir des appareils qui exportent des données de flux (par exemple, des routeurs, des pare-feux ou des commutateurs). Vous pouvez analyser le volume de trafic, identifier les principaux consommateurs de bande passante et comprendre comment les données circulent dans votre réseau. -La vue NetFlow affiche des métriques de trafic agrégées par dispositif et par interface. Utilisez-la pour identifier quels dispositifs ou interfaces consomment le plus de bande passante, génèrent le plus de paquets ou contribuent aux pics de trafic. +La vue NetFlow affiche les métriques de trafic agrégées par appareil et par interface. Utilisez-la pour identifier quels appareils ou interfaces consomment le plus de bande passante, génèrent le plus de paquets ou contribuent aux pics de trafic. -{{< img src="network_device_monitoring/netflow/netflow.png" alt="La page de surveillance NetFlow contient une légende repliable pour le volume de trafic, la santé des dispositifs, les flux et plus encore." style="width:100%;" >}} +{{< img src="network_device_monitoring/netflow/netflow.png" alt="La page NetFlow Monitoring contenant une légende repliable pour le volume de trafic, l'état des appareils, les flux et plus encore." style="width:100%;" >}} ## Navigation latérale {#side-navigation} -Utilisez la navigation à gauche pour explorer d'autres vues NetFlow : +Utilisez la navigation de gauche pour explorer d'autres vues NetFlow : -- **Volume de trafic** : Métriques de flux globales par dispositif et par interface. -- **Santé des dispositifs** : État et utilisation des dispositifs surveillés. -- **Flux** : Enregistrements de flux individuels détaillés. -- **Conversations** : Paires source-destination agrégées. -- **Systèmes autonomes** : Données de flux regroupées par numéros de systèmes autonomes (ASN). -- **Géolocalisation IP** : Données de flux regroupées par origine/destination géographique. -- **Ports source / Ports de destination / Protocoles / Drapeaux** : Répartition du trafic par métadonnées de paquets. +- {{< ui >}}Traffic Volume{{< /ui >}} : Métriques de flux globales par appareil et interface. +- {{< ui >}}Device Health{{< /ui >}} : État et utilisation des appareils surveillés. +- {{< ui >}}Flows{{< /ui >}} : Enregistrements de flux individuels détaillés. +- {{< ui >}}Conversations{{< /ui >}} : Paires source-destination agrégées. +- {{< ui >}}Autonomous Systems{{< /ui >}} : Données de flux regroupées par numéros de système autonome (ASN). +- {{< ui >}}Geo IP{{< /ui >}} : Données de flux regroupées par origine/destination géographique. +- {{< ui >}}Source Ports / Destination Ports / Protocols / Flags{{< /ui >}} : Répartition du trafic par métadonnées de paquets. ## Installation {#installation} -Pour utiliser la surveillance NetFlow avec la surveillance des dispositifs réseau, assurez-vous d'utiliser la version [Agent][1] 7.45 ou plus récente. +Pour utiliser NetFlow Monitoring avec Network Device Monitoring, assurez-vous d'utiliser la version 7.45 ou ultérieure de l'[Agent][1]. -**Remarque :** La configuration de [la collecte de métriques à partir de la surveillance des dispositifs réseau][2] n'est pas une exigence pour l'envoi de données NetFlow, bien qu'elle soit fortement recommandée car ces données supplémentaires peuvent être utilisées pour enrichir vos enregistrements de flux avec des informations telles que le nom du dispositif, le modèle et le fournisseur, ainsi que le nom de l'interface entrante/sortante. +**Remarque :** La configuration de la [collecte de métriques à partir de Network Device Monitoring][2] n'est pas une exigence pour l'envoi de données NetFlow, bien qu'elle soit fortement recommandée car ces données supplémentaires peuvent être utilisées pour enrichir vos enregistrements de flux avec des informations telles que le nom de l'appareil, le modèle et le fournisseur, ainsi que le nom de l'interface entrante/sortante. ## Configuration {#configuration} -Pour configurer vos dispositifs afin d'envoyer du trafic NetFlow, jFlow, sFlow ou IPFIX au serveur Agent NetFlow, vos dispositifs doivent être configurés pour envoyer le trafic à l'adresse IP sur laquelle l'Agent Datadog est installé, spécifiquement les `flow_type` et `port`. +Pour configurer vos appareils afin d'envoyer du trafic NetFlow, jFlow, sFlow ou IPFIX vers le serveur NetFlow de l'Agent, vos appareils doivent être configurés pour envoyer du trafic vers l'adresse IP sur laquelle le Datadog Agent est installé, spécifiquement le `flow_type` et le `port`. -1. Modifiez votre fichier de configuration de l'Agent [`datadog.yaml`][3] pour activer NetFlow : +1. Modifiez votre fichier de configuration d'Agent [`datadog.yaml`][3] pour activer NetFlow : ```yaml network_devices: @@ -65,75 +68,81 @@ network_devices: 2. Après avoir enregistré vos modifications, [redémarrez l'Agent][4]. - **Remarque** : Assurez-vous que vos [règles de pare-feu][9] permettent le trafic UDP entrant sur les ports configurés. + **Remarque** : assurez-vous que vos [règles de pare-feu][9] autorisent le trafic UDP entrant sur les ports configurés. ## Agrégation {#aggregation} -L'Agent Datadog agrège automatiquement les données reçues dans NetFlow pour limiter le nombre d'enregistrements envoyés à la plateforme tout en maintenant la plupart des informations. Par défaut, les enregistrements de flux ayant les mêmes identifiants, tels que `source`, `destination address`, `port` et `protocol`, sont agrégés ensemble par intervalles de cinq minutes. De plus, l'Agent Datadog peut détecter les ports éphémères et les supprimer. En conséquence, vous pouvez voir des flux avec `port:*`. +Le Datadog Agent agrège automatiquement les données reçues dans NetFlow pour limiter le nombre d'enregistrements envoyés à la plateforme tout en conservant la majeure partie des informations. Par défaut, les enregistrements de flux qui ont les mêmes identifiants, tels que `source`, `destination address`, `port` et `protocol`, sont agrégés ensemble par intervalles de cinq minutes. De plus, le Datadog Agent peut détecter les ports éphémères et les supprimer. Par conséquent, vous pouvez voir des flux avec `port:*`. ## Enrichissement {#enrichment} -Vos données NetFlow sont traitées par le backend Datadog et enrichies avec les métadonnées disponibles de vos appareils et interfaces. L'enrichissement est basé sur l'adresse IP de l'exportateur NetFlow et les index des interfaces. Pour désambiguïser les collisions possibles entre les adresses IP privées réutilisées, vous pouvez configurer un `namespace` différent pour chaque fichier de configuration d'Agent (avec le paramètre `network_devices.namespace`). +Vos données NetFlow sont traitées par le backend Datadog et enrichies avec les métadonnées disponibles provenant de vos appareils et interfaces. L'enrichissement est basé sur l'adresse IP de l'exportateur NetFlow et les index d'interface. Pour lever toute ambiguïté sur d'éventuelles collisions entre des adresses IP privées réutilisées, vous pouvez configurer un `namespace` différent pour chaque fichier de configuration de l'Agent (avec le paramètre `network_devices.namespace`). -Si l'adresse IP de l'exportateur NetFlow correspond à l'une des adresses IP du dispositif, mais pas à celle configurée dans l'intégration SNMP, Datadog tente de localiser le dispositif auquel appartient l'adresse IP de l'exportateur et enrichit vos données NetFlow avec celle-ci tant que la correspondance est unique. +Si l'adresse IP de l'exportateur NetFlow est l'une des adresses IP de l'appareil, mais pas celle configurée dans l'intégration SNMP, Datadog tente de localiser l'appareil auquel appartient l'adresse IP de l'exportateur et enrichit vos données NetFlow avec celle-ci tant que la correspondance est unique. -### Enrichissement IP du fournisseur de cloud {#cloud-provider-ip-enrichment} +### Enrichissement par adresse IP de fournisseur cloud {#cloud-provider-ip-enrichment} -Datadog enrichit les IP avec le service et la région du fournisseur de cloud public pour les adresses IPv4, afin que vous puissiez filtrer les enregistrements de flux d'un service et d'une région spécifiques. +Datadog enrichit les adresses IP avec le service et la région du fournisseur cloud public pour les adresses IPv4, afin que vous puissiez filtrer les enregistrements de flux par service et région spécifiques. -{{< img src="network_device_monitoring/netflow/netflow_cloud_provider_enrichment_2.png" alt="Menu de filtre Netflow affichant le nom du fournisseur de cloud, la région et le service" width="100%" >}} +{{< img src="network_device_monitoring/netflow/netflow_cloud_provider_enrichment_2.png" alt="Menu Filtre Netflow affichant le nom du fournisseur cloud, la région et le service." width="100%" >}} ### Enrichissement des ports {#port-enrichment} -Datadog enrichit les ports dans NetFlow avec les données de l'IANA (Internet Assigned Numbers Authority) pour résoudre les mappages de ports bien connus (comme Postgres sur 5432 et HTTPS sur 443). +Datadog enrichit les ports dans NetFlow avec les données de l'IANA (Internet Assigned Numbers Authority) pour résoudre les mappages de ports connus (tels que Postgres sur 5432 et HTTPS sur 443). -### Enrichissement des ports personnalisés {#custom-port-enrichment} +### Enrichissement personnalisé des ports {#custom-port-enrichment} -Vous pouvez également ajouter vos propres enrichissements personnalisés pour mapper les ports et les protocoles à des applications spécifiques (par exemple, si un service personnalisé fonctionne sur un port spécifique). Cela facilite l'interprétation et l'interrogation des données NetFlow par les ingénieurs réseau et leurs équipes avec des noms lisibles par l'homme. +Vous pouvez également ajouter vos propres enrichissements personnalisés pour mapper les ports et les protocoles à des applications spécifiques (par exemple, si un service personnalisé s'exécute sur un port spécifique). Cela permet aux ingénieurs réseau et à leurs équipes d'interpréter et d'interroger plus facilement les données NetFlow avec des noms lisibles par l'homme. -Dans l'onglet **Configuration** de NetFlow, cliquez sur **+ Ajouter un enrichissement** pour télécharger le fichier CSV contenant vos enrichissements personnalisés. +Depuis l'onglet {{< ui >}}Configuration{{< /ui >}} dans NetFlow, cliquez sur {{< ui >}}+ Add Enrichment{{< /ui >}} pour télécharger le fichier CSV contenant vos enrichissements personnalisés. -{{< img src="network_device_monitoring/netflow/new_enrichment_2.png" alt="La fenêtre modale de mappage des nouveaux enrichissements dans l'onglet de configuration de NetFlow" width="100%" >}} +{{< img src="network_device_monitoring/netflow/new_enrichment_2.png" alt="La nouvelle fenêtre modale de mappage d'enrichissement dans l'onglet de configuration NetFlow." width="100%" >}} ### Enrichissement IP personnalisé {#custom-ip-enrichment} -Vous pouvez également ajouter vos propres enrichissements personnalisés pour mapper les IP et les CIDR à des tags personnalisés (par exemple, pour catégoriser les services fonctionnant sur des adresses IP spécifiques). Cela facilite l'interprétation et l'interrogation des données NetFlow par les ingénieurs réseau et leurs équipes avec des noms lisibles par l'homme. +Vous pouvez également ajouter vos propres enrichissements personnalisés pour mapper les IP et les CIDR à des tags personnalisés (par exemple, pour catégoriser les services s'exécutant sur des adresses IP spécifiques). Cela permet aux ingénieurs réseau et à leurs équipes d'interpréter et d'interroger plus facilement les données NetFlow avec des noms lisibles par l'homme. -Depuis la page des paramètres [**Enrichissement**][10], cliquez sur **+ Ajouter un enrichissement** pour ajouter des mappages manuellement ou télécharger un fichier CSV pour ajouter des mappages en masse. +Depuis la [{{< ui >}}Enrichment{{< /ui >}} page des paramètres][10], cliquez sur {{< ui >}}+ Add Enrichment{{< /ui >}} pour ajouter des mappages manuellement ou téléchargez un fichier CSV pour ajouter des mappages en masse. -### Enrichissement IP privé DNS inversé {#reverse-dns-private-ip-enrichment} +### Enrichissement IP privé DNS inverse {#reverse-dns-private-ip-enrichment} -Activez l'enrichissement IP privé DNS inversé pour effectuer des recherches DNS pour les noms d'hôtes associés aux adresses IP source ou destination. Lorsqu'il est activé, l'Agent effectue des recherches DNS inversées sur les IP source et destination dans les plages d'adresses privées, enrichissant les enregistrements NetFlow avec les noms d'hôtes correspondants. +Activez l'enrichissement IP privé DNS inverse pour effectuer des recherches DNS pour les noms de host associés aux adresses IP source ou de destination. Une fois activé, l'Agent effectue des recherches DNS inverses sur les IP source et de destination au sein des plages d'adresses privées, enrichissant les enregistrements NetFlow avec les noms de host correspondants. -Par [défaut][7], l'enrichissement IP DNS inversé dans votre fichier `datadog.yaml` est désactivé. Pour activer, consultez la section [Configuration](#configuration) de cette page. +Par défaut, l'enrichissement IP DNS inverse dans votre [`datadog.yaml` fichier][7] est désactivé. Pour l'activer, consultez la section [Configuration](#configuration) de cette page. -Recherchez **DNS** dans le menu **+ Filtrer** pour localiser les flux associés à l'enrichissement IP DNS inversé : +Recherchez DNS dans le menu {{< ui >}}+ Filter{{< /ui >}} pour localiser les flux associés à l'enrichissement IP DNS inverse : -{{< img src="network_device_monitoring/netflow/dns_ip_enrichmen_2.png" alt="Menu de filtrage amélioré pour afficher les facettes de destination et de source DNS inversé" width="100%" >}} +{{< img src="network_device_monitoring/netflow/dns_ip_enrichmen_2.png" alt="Menu de filtrage amélioré pour afficher les facettes de destination et de source DNS inverse" width="100%" >}} -**Remarque** : Les entrées DNS inversées sont mises en cache et soumises à une limitation de débit pour minimiser les requêtes DNS et réduire la charge sur les serveurs DNS. Pour plus d'options de configuration, y compris la modification de la mise en cache par défaut et de la limitation de débit, consultez le [fichier de configuration complet][8]. +**Remarque** : Les entrées DNS inverses sont mises en cache et soumises à une limitation de débit afin de minimiser les requêtes DNS et de réduire la charge sur les serveurs DNS. Pour plus d'options de configuration, notamment la modification de la mise en cache par défaut et de la limitation de débit, consultez la `reverse_dns_enrichment` section du [fichier de configuration de l'Agent exemple][7]. ## Détails IP {#ip-details} -Dans la vue **Conversations**, vous pouvez voir l'adresse IP publique de l'adresse IP de destination. Survolez l'IP pour afficher des métadonnées riches sur l'IP et un lien vers **Voir les connexions réseau associées** où vous pouvez inspecter la connectivité plus en détail. +Dans la vue **Conversations**, vous pouvez afficher l'adresse IP publique de l'IP de destination. Survolez l'IP pour afficher des métadonnées enrichies sur l'IP et un lien vers {{< ui >}}View Related Network Connections{{< /ui >}} où vous pouvez inspecter la connectivité plus en détail. {{< img src="network_device_monitoring/netflow/NetFlow_IP_pill.png" alt="Survolez une adresse IP pour afficher les détails de l'IP et voir les connexions réseau associées." width="100%" >}} ## Diagramme de flux {#flow-diagram} -Vous pouvez visualiser les flux dans la surveillance NetFlow en cliquant sur le menu **Flux** et en survolant un flux de la liste pour voir des informations supplémentaires sur l'adresse IP source, le nom de l'interface d'entrée, le nom de l'appareil et l'adresse IP de destination à travers les connexions réseau associées. +Vous pouvez visualiser les flux dans NetFlow Monitoring en cliquant sur le {{< ui >}}Flows{{< /ui >}} menu et en survolant un flux de la liste pour afficher des informations supplémentaires sur l'IP source, le nom de l'interface d'entrée, le nom de l'appareil et l'IP de destination à travers les connexions réseau associées. + +{{< img src="network_device_monitoring/netflow/flows.png" alt="Survolez un flux agrégé à partir d'un appareil émettant du netflow pour accéder aux connexions réseau associées" width="100%" >}} + +## Network Path pour NetFlow {#network-path-for-netflow} + +Les tests dynamiques pour NetFlow peuvent exécuter automatiquement des tests Network Path depuis l'Agent qui collecte le trafic NetFlow vers les adresses IP de destination observées dans les enregistrements NetFlow. Utilisez les tests dynamiques pour NetFlow afin d'ajouter un contexte de route et de latence saut par saut à vos destinations NetFlow. -{{< img src="network_device_monitoring/netflow/flows.png" alt="Survolez un flux agrégé d'un appareil émettant du netflow pour accéder aux connexions réseau associées" width="100%" >}} +Les tests dynamiques pour NetFlow sont expérimentaux et nécessitent l'Agent `v7.81+`. Pour configurer les tests dynamiques pour NetFlow, consultez [Configuration de Network Path][11]. -## Moniteur NetFlow {#netflow-monitor} +## Monitor NetFlow {#netflow-monitor} -Cliquez sur l'icône **Créer un moniteur** depuis n'importe quelle vue pour créer un [moniteur NetFlow][6]. Lors de la création du moniteur, considérez les champs suivants par rapport à l'adresse IP source ou à l'adresse IP de destination du point de vue de l'appareil. Ces champs fournissent des informations sur les modèles de trafic réseau et aident à optimiser les performances et la sécurité. +Cliquez sur l'icône {{< ui >}}Create Monitor{{< /ui >}} depuis l'une des vues pour créer un [monitor NetFlow][6]. Lors de la création du monitor, prenez en compte les champs suivants par rapport à l'adresse IP source ou à l'adresse IP de destination du point de vue du périphérique. Ces champs fournissent des informations sur les modèles de trafic réseau et aident à optimiser les performances et la sécurité. -{{< img src="network_device_monitoring/netflow/create_monitor.png" alt="Vue des flux dans la surveillance NetFlow avec le lien de création de moniteur mis en évidence." width="100%" >}} +{{< img src="network_device_monitoring/netflow/create_monitor.png" alt="Vue des flux dans la surveillance NetFlow avec le lien de création de monitor mis en surbrillance." width="100%" >}} ### Informations sur l'interface {#interface-information} -Les champs suivants représentent des détails sur les interfaces d'entrée et de sortie. +Les champs suivants représentent les détails concernant les interfaces d'entrée et de sortie. | Nom du champ | Description du champ | |---|---| @@ -144,18 +153,18 @@ Les champs suivants représentent des détails sur les interfaces d'entrée et d | Index de l'interface d'entrée | Index de l'interface d'entrée. | | Nom de l'interface d'entrée | Nom de l'interface d'entrée. | -### Informations sur le dispositif {#device-information} +### Informations sur le périphérique {#device-information} -Les champs suivants représentent des détails liés au dispositif générant des enregistrements NetFlow. +Les champs suivants représentent les détails relatifs au périphérique générant les enregistrements NetFlow. | Nom du champ | Description du champ | |---|---| -| Adresse IP du dispositif | | -| Adresse IP de l'exportateur | Adresse IP à partir de laquelle proviennent les paquets NetFlow. | -| Modèle de l'appareil | Modèle de l'appareil. | -| Nom de l'appareil | Nom de l'appareil. | -| Espace de noms de l'appareil | Espace de noms de l'appareil. | -| Fournisseur de l'appareil | Fournisseur de l'appareil. | +| IP du périphérique | Adresse IP utilisée pour mapper un périphérique dans NDM à des fins d'enrichissement. | +| IP de l'exportateur | Adresse IP à partir de laquelle les paquets NetFlow proviennent. | +| Modèle du périphérique | Modèle du périphérique. | +| Nom du périphérique | Nom du périphérique. | +| Espace de noms du périphérique | Espace de noms du périphérique. | +| Fournisseur du périphérique | Fournisseur du périphérique. | ### Détails du flux {#flow-details} @@ -166,112 +175,112 @@ Les champs suivants représentent les caractéristiques du flux réseau. | Direction | Indique si le flux est entrant ou sortant. | | Heure de début | Horodatage du premier paquet réseau entre les adresses IP source et destination. | | Heure de fin | Horodatage du dernier paquet réseau entre les adresses IP source et destination. | -| Type d’Ether | Type d’encapsulation de trame Ethernet (IPv4 ou IPv6). | +| Type Ethernet | Type d'encapsulation de trame Ethernet (IPv4 ou IPv6). | | Type de flux | Type de format de données NetFlow (IPFIX, sFlow5, NetFlow5, NetFlow9 ou Inconnu). | | Protocole IP | Protocole utilisé pour la communication (tel que ICMP, TCP ou UDP). | -| Adresse IP du prochain saut | Adresse IP du prochain saut dans le chemin réseau. | -| Drapeau TCP | Union de tous les drapeaux TCP observés pendant la durée du flux. | +| IP du prochain saut | Adresse IP du prochain saut dans le chemin réseau. | +| Indicateur TCP | Union de tous les indicateurs TCP observés pendant la durée de vie du flux. | | Octets | Nombre total d'octets transférés. | | Paquets | Nombre total de paquets transférés. | -En plus des champs, vous pouvez également utiliser des facettes prêtes à l'emploi pour commencer à analyser les modèles de trafic en fonction des adresses IP de destination et de source NetFlow. +En plus des champs, vous pouvez également utiliser des facettes prêtes à l'emploi pour commencer à analyser les modèles de trafic basés sur les adresses IP de destination et de source NetFlow. ### Facettes IP de destination NetFlow {#netflow-destination-ip-facets} | Nom de la facette | Description de la facette | |---|---| -| Domaine AS de destination | Le domaine associé au Système Autonome (AS) auquel appartient l'IP de destination. | -| Nom AS de destination | Le nom du Système Autonome (AS) auquel appartient l'IP de destination. | -| Numéro AS de destination | Le numéro attribué au Système Autonome (AS) auquel appartient l'IP de destination. | -| Route AS de destination | Les informations de route associées au Système Autonome (AS) auquel appartient l'IP de destination. | -| Type AS de destination | Le type de Système Autonome (AS) auquel appartient l'IP de destination (tel que transit, client, pair). | -| Nom de l'application de destination | Le nom de l'application associée à l'IP de destination. | -| Nom de la ville de destination | Le nom de la ville associée à l'IP de destination. | -| Nom du fournisseur de cloud de destination | Le nom du fournisseur de cloud associé à l'IP de destination. | -| Région du fournisseur de cloud de destination | La région du fournisseur de cloud associée à l'IP de destination. | -| Service du fournisseur de cloud de destination | Le service fourni par le fournisseur de cloud associé à l'IP de destination. | -| Code de continent de destination | Le code représentant le continent associé à l'IP de destination. | -| Nom de continent de destination | Le nom du continent associé à l'IP de destination. | -| Code ISO du pays de destination | Le code ISO représentant le pays associé à l'IP de destination. | -| Nom du pays de destination | Le nom du pays associé à l'IP de destination. | +| Domaine AS de destination | Le domaine associé au système autonome (AS) auquel appartient l'adresse IP de destination. | +| Nom AS de destination | Le nom du système autonome (AS) auquel appartient l'adresse IP de destination. | +| Numéro AS de destination | Le numéro attribué au système autonome (AS) auquel appartient l'adresse IP de destination. | +| Route AS de destination | Les informations de route associées au système autonome (AS) auquel appartient l'adresse IP de destination. | +| Type AS de destination | Le type de système autonome (AS) auquel appartient l'adresse IP de destination (tel que transit, client, pair). | +| Nom de l'application de destination | Le nom de l'application associée à l'adresse IP de destination. | +| Nom de la ville de destination | Le nom de la ville associée à l'adresse IP de destination. | +| Nom du fournisseur cloud de destination | Le nom du fournisseur cloud associé à l'adresse IP de destination. | +| Région du fournisseur cloud de destination | La région du fournisseur cloud associée à l'adresse IP de destination. | +| Service du fournisseur cloud de destination | Le service fourni par le fournisseur cloud associé à l'adresse IP de destination. | +| Code du continent de destination | Le code représentant le continent associé à l'adresse IP de destination. | +| Nom du continent de destination | Le nom du continent associé à l'adresse IP de destination. | +| Code ISO du pays de destination | Le code ISO représentant le pays associé à l'adresse IP de destination. | +| Nom du pays de destination | Le nom du pays associé à l'adresse IP de destination. | | IP de destination | L'adresse IP de destination. | -| Latitude de destination | La coordonnée de latitude associée à l'IP de destination. | -| Longitude de destination | La coordonnée de longitude associée à l'IP de destination. | -| MAC de destination | L'adresse de contrôle d'accès au média (MAC) associée à l'IP de destination. | +| Latitude de destination | La coordonnée de latitude associée à l'adresse IP de destination. | +| Longitude de destination | La coordonnée de longitude associée à l'adresse IP de destination. | +| MAC de destination | L'adresse de contrôle d'accès au support (MAC) associée à l'adresse IP de destination. | | Masque de destination | Le masque de sous-réseau associé à l'adresse IP de destination. | | Port de destination | Le numéro de port de destination. | -| Nom d'hôte DNS inverse de destination | Le nom d'hôte DNS associé à l'adresse IP de destination. | -| Code ISO de la sous-division de destination | Le code ISO représentant la sous-division (comme l'état ou la province) associée à l'adresse IP de destination. | -| Nom de la sous-division de destination | Le nom de la sous-division (comme l'état ou la province) associée à l'adresse IP de destination. | +| Nom de host DNS inverse de destination | Le nom de host DNS associé à l'adresse IP de destination. | +| Code ISO de la subdivision de destination | Le code ISO représentant la subdivision (telle qu'un État ou une province) associée à l'adresse IP de destination. | +| Nom de la subdivision de destination | Le nom de la subdivision (telle qu'un État ou une province) associée à l'adresse IP de destination. | | Fuseau horaire de destination | Le fuseau horaire associé à l'adresse IP de destination. | -### Facettes de l'IP Source NetFlow {#netflow-source-ip-facets} +### Facettes IP source NetFlow {#netflow-source-ip-facets} | Nom de la facette | Description de la facette | |---|---| -| Domaine AS de source | Le domaine associé au Système Autonome (AS) auquel appartient l'adresse IP source. | -| Nom AS de source | Le nom du Système Autonome (AS) auquel appartient l'adresse IP source. | -| Numéro AS de source | Le numéro attribué au Système Autonome (AS) auquel appartient l'adresse IP source. | -| Route AS de source | Les informations de route associées au Système Autonome (AS) auquel appartient l'adresse IP source. | -| Type AS de source | Le type de Système Autonome (AS) auquel appartient l'adresse IP source (comme transit, client, pair). | -| Nom de l'application de source | Le nom de l'application associée à l'adresse IP source. | -| Nom de la ville de source | Le nom de la ville associée à l'adresse IP source. | -| Nom du fournisseur de cloud de source | Le nom du fournisseur de cloud associé à l'adresse IP source. | -| Région du fournisseur de cloud de source | La région du fournisseur de cloud associée à l'adresse IP source. | -| Service du fournisseur de cloud de source | Le service fourni par le fournisseur de cloud associé à l'adresse IP source. | -| Code de continent de source | Le code représentant le continent associé à l'adresse IP source. | -| Nom du continent de source | Le nom du continent associé à l'adresse IP source. | -| Code ISO du pays de source | Le code ISO représentant le pays associé à l'adresse IP source. | -| Nom du pays de source | Le nom du pays associé à l'adresse IP source. | -| IP de source | L'adresse IP de source. | -| Latitude de source | La coordonnée de latitude associée à l'adresse IP source. | -| Longitude de source | La coordonnée de longitude associée à l'adresse IP source. | -| MAC de source | L'adresse MAC associée à l'adresse IP source. | -| Masque de source | Le masque de sous-réseau associé à l'adresse IP source. | -| Port de source | Le numéro de port source. | -| Nom d'hôte DNS inverse de source | Le nom d'hôte DNS associé à l'adresse IP source. | -| Code ISO de la subdivision de source | Le code ISO représentant la subdivision (comme l'état ou la province) associée à l'adresse IP source. | -| Nom de la subdivision de source | Le nom de la subdivision (comme l'état ou la province) associée à l'adresse IP source. | -| Fuseau horaire de source | Le fuseau horaire associé à l'adresse IP source. | +| Domaine AS source | Le domaine associé au système autonome (AS) auquel appartient l'adresse IP source. | +| Nom AS source | Le nom du système autonome (AS) auquel appartient l'adresse IP source. | +| Numéro AS source | Le numéro attribué au système autonome (AS) auquel appartient l'adresse IP source. | +| Route AS source | Les informations de routage associées au système autonome (AS) auquel appartient l'adresse IP source. | +| Type AS source | Le type de système autonome (AS) auquel appartient l'adresse IP source (tel que transit, client, pair). | +| Nom de l'application source | Le nom de l'application associée à l'adresse IP source. | +| Nom de la ville source | Le nom de la ville associée à l'adresse IP source. | +| Nom du fournisseur Cloud source | Le nom du fournisseur Cloud associé à l'adresse IP source. | +| Région du fournisseur Cloud source | La région du fournisseur Cloud associée à l'adresse IP source. | +| Service du fournisseur Cloud source | Le service fourni par le fournisseur Cloud associé à l'adresse IP source. | +| Code du continent source | Le code représentant le continent associé à l'adresse IP source. | +| Nom du continent source | Le nom du continent associé à l'adresse IP source. | +| Code ISO du pays source | Le code ISO représentant le pays associé à l'adresse IP source. | +| Nom du pays source | Le nom du pays associé à l'adresse IP source. | +| IP source | L'adresse IP source. | +| Latitude source | La coordonnée de latitude associée à l'adresse IP source. | +| Longitude source | La coordonnée de longitude associée à l'adresse IP source. | +| MAC source | L'adresse de contrôle d'accès au support (MAC) associée à l'adresse IP source. | +| Masque source | Le masque de sous-réseau associé à l'adresse IP source. | +| Port source | Le numéro de port source. | +| Nom de host DNS inverse source | Le nom de host DNS associé à l'adresse IP source. | +| Code ISO de la subdivision source | Le code ISO représentant la subdivision (telle qu'un État ou une province) associée à l'adresse IP source. | +| Nom de la subdivision source | Le nom de la subdivision (telle qu'un État ou une province) associée à l'adresse IP source. | +| Fuseau horaire source | Le fuseau horaire associé à l'adresse IP source. | ## Assemblage de conversations {#conversation-stitching} -Par défaut, les enregistrements NetFlow séparent les flux unidirectionnels pour chaque direction de trafic entre deux points de terminaison (A → B et B → A). L'assemblage de conversations combine ceux-ci en un seul enregistrement bidirectionnel, vous offrant une vue complète du trafic total échangé entre deux points de terminaison (A ↔ B). +Par défaut, les enregistrements NetFlow séparent les flux unidirectionnels pour chaque direction du trafic entre deux endpoints (A → B et B → A). L'assemblage de conversations combine ceux-ci en un seul enregistrement bidirectionnel, vous donnant une vue complète du trafic total échangé entre deux endpoints (A ↔ B). Avec l'assemblage de conversations, vous pouvez : -- Voir le trafic total échangé entre deux points de terminaison comme une seule conversation au lieu de flux directionnels séparés -- Identifier les véritables initiateurs et répondants afin que les widgets source et destination reflètent des rôles précis -- Éliminer le bruit où les serveurs apparaissent incorrectement comme principales sources +- Voir le trafic total échangé entre deux endpoints comme une seule conversation au lieu de flux directionnels séparés +- Identifier les véritables initiateurs et répondeurs afin que les widgets de source et de destination reflètent des rôles précis +- Supprimer le bruit lorsque des serveurs apparaissent incorrectement comme sources principales -Pour basculer entre les vues assemblées (bidirectionnelles) et non assemblées (unidirectionnelles), naviguez vers n'importe quelle vue NetFlow basée sur un point de terminaison et utilisez le commutateur **Bidirectionnel** sous le sélecteur de temps. +Pour basculer entre les vues assemblées (bidirectionnelles) et non assemblées (unidirectionnelles), accédez à n'importe quelle vue NetFlow basée sur un endpoint et utilisez le bouton {{< ui >}}Bidirectional{{< /ui >}} sous le sélecteur de temps. -{{< img src="network_device_monitoring/netflow/conversation_stitching.png" alt="Basculer l'assemblage de conversations dans la vue NetFlow" width="100%" >}} +{{< img src="network_device_monitoring/netflow/conversation_stitching.png" alt="Bouton d'assemblage des conversations dans la vue NetFlow" width="100%" >}} ## Taux d'échantillonnage {#sampling-rate} -Le taux d'échantillonnage de NetFlow est pris en compte dans le calcul des octets et des paquets par défaut. Les valeurs affichées pour les octets et les paquets sont calculées avec le taux d'échantillonnage appliqué. -De plus, vous pouvez interroger **Octets (Ajustés) (@adjusted_bytes)** et **Paquets (Ajustés) (@adjusted_packets)** dans les tableaux de bord et les carnets pour les visualiser. +Le taux d'échantillonnage de NetFlow est pris en compte par défaut dans le calcul des octets et des paquets. Les valeurs affichées pour les octets et les paquets sont calculées avec le taux d'échantillonnage appliqué. +De plus, vous pouvez interroger **Bytes (Adjusted) (@adjusted_bytes)** et **Packets (Adjusted) (@adjusted_packets)** dans les dashboards et notebooks pour les visualiser. -Pour visualiser les octets/paquets bruts (échantillonnés) envoyés par vos appareils, vous pouvez interroger **Octets (Échantillonnés) (@bytes)** et **Paquets (Échantillonnés) (@packets)** dans les tableaux de bord et les carnets. +Pour visualiser les octets/paquets bruts (Sampled) envoyés par vos appareils, vous pouvez interroger **Bytes (Sampled) (@bytes)** et **Packets (Sampled) (@packets)** dans dashboards et notebooks. -## Conservation {#retention} +## Rétention {#retention} -Les données NetFlow sont conservées pendant 30 jours par défaut, avec des options pour une conservation de 15, 30, 60 et 90 jours. +Les données NetFlow sont conservées par défaut pendant 30 jours, avec des options de rétention de 15, 30, 60 et 90 jours. -
Pour conserver les données NetFlow pendant de plus longues périodes, contactez votre représentant commercial.
+
Pour conserver les données NetFlow pendant des périodes plus longues, contactez votre responsable de compte.
## Limiter le volume de flux par intervalle de vidage {#limit-flow-volume-per-flush-interval} -Pour contrôler le volume NetFlow et les coûts associés, configurez l'Agent pour limiter le nombre d'enregistrements de flux soumis par intervalle de vidage. L'intervalle de vidage est la période pendant laquelle les flux sont agrégés avant d'être transmis à Datadog. +Pour contrôler le volume NetFlow et les coûts associés, configurez l'Agent pour plafonner le nombre d'enregistrements de flux soumis par intervalle de vidage. L'intervalle de vidage est la période pendant laquelle les flux sont agrégés avant d'être transférés à Datadog. -Lorsque cette limite est activée, l'Agent conserve uniquement les **meilleurs flux par nombre d'octets** jusqu'au maximum configuré, et rejette les flux de volume inférieur pour cet intervalle de vidage. +Lorsque cette limite est activée, l'Agent ne conserve que les **flux principaux par nombre d'octets** jusqu'au maximum configuré, et ignore les flux à faible volume pour cet intervalle de vidage. ### Configuration {#configuration-1} -**Remarque** : Nécessite la version de l'Agent `7.75.1` ou ultérieure. +**Remarque** : Nécessite la version `7.75.1` de l'Agent ou une version ultérieure. -Configurez ce qui suit dans votre `datadog.yaml` : +Configurez les éléments suivants dans votre `datadog.yaml` : ```yaml network_devices: @@ -280,27 +289,27 @@ network_devices: aggregator_max_flows_per_flush_interval: 10000 ``` -Avec cette configuration, l'Agent soumet au maximum 10 000 enregistrements NetFlow par intervalle de vidage (5 minutes par défaut). L'Agent priorise les flux de plus haut volume et rejette le reste. +Avec cette configuration, l'Agent soumet au maximum 10 000 enregistrements NetFlow par intervalle de vidage (5 minutes par défaut). L'Agent donne la priorité aux flux à volume élevé et ignore le reste. ### Estimation du volume quotidien {#estimating-daily-volume} -Votre nombre maximum approximatif de flux quotidien est : +Votre nombre approximatif de flux maximum quotidien est : `max_flows_per_flush_interval * (minutes_per_day / flush_interval_minutes)` -Par exemple, avec `10,000` flux par intervalle de vidage et un intervalle de vidage de 5 minutes : +Par exemple, avec `10,000` flux par intervalle de vidage et un intervalle de vidage de 5 minutes : `10,000 * (1440 / 5) = 2,880,000 flows/day` ### Comportement attendu {#expected-behavior} -- **Les principaux émetteurs sont prioritaires :** Cela est préférable pour les flux de travail axés sur un trafic à fort volume (par exemple, les pilotes de bande passante et les liens bruyants). -- **Visibilité réduite pour les flux à faible volume :** Les paires source/destination à faible trafic peuvent ne pas apparaître lorsque le plafond est atteint. -- **Comportement par Agent :** La limite est appliquée à chaque Agent de manière indépendante. Si plusieurs Agents voient du trafic pour les mêmes conversations, ils ne sont pas agrégés globalement avant la troncature. +- **Les principaux consommateurs de bande passante sont prioritaires :** Ceci est idéal pour les workflows axés sur le trafic à haut volume (par exemple, les générateurs de trafic et les liens bruyants). +- **Visibilité réduite pour les flux à faible volume :** Les paires source/destination à faible trafic peuvent ne pas apparaître lorsque le plafond est atteint. +- **Comportement par Agent :** La limite est appliquée à chaque Agent indépendamment. Si plusieurs Agents voient du trafic pour les mêmes conversations, ils ne sont pas globalement agrégés avant la troncature. -### Suivi de la troncature {#monitoring-truncation} +### Surveillance de la troncature {#monitoring-truncation} -Lorsque la limitation de flux est activée, l'Agent émet des métriques que vous pouvez utiliser pour comprendre combien de données sont conservées par rapport à celles qui sont rejettées : +Lorsque la limitation de flux est activée, l'Agent émet des métriques que vous pouvez utiliser pour comprendre quelle quantité de données est conservée par rapport à celle qui est supprimée : - `ndm.flow_truncation.flows_total` - `ndm.flow_truncation.flows_kept` @@ -309,16 +318,16 @@ Lorsque la limitation de flux est activée, l'Agent émet des métriques que vou - `ndm.flow_truncation.threshold_value` - `ndm.flow_truncation.runtime_ms` -Utilisez ces métriques pour valider votre plafond choisi et pour détecter quand la troncature se produit fréquemment (ce qui peut indiquer que vous devriez ajuster le plafond ou l'intervalle de vidage). +Utilisez ces métriques pour valider le plafond choisi et pour détecter quand la troncature se produit fréquemment (ce qui peut indiquer que vous devriez ajuster le plafond ou l'intervalle de vidage). ## Dépannage {#troubleshooting} -### Pertes de paquets NetFlow {#netflow-packet-drops} -Des pertes de paquets NetFlow peuvent se produire lorsqu'il y a un nombre élevé de paquets NetFlow par seconde, généralement supérieur à 50 000. Les étapes suivantes peuvent aider à identifier et à atténuer les pertes de paquets NetFlow : +### Perte de paquets NetFlow {#netflow-packet-drops} +Des pertes de paquets NetFlow peuvent se produire lorsqu'il y a un nombre élevé de paquets NetFlow par seconde, généralement supérieur à 50 000. Les étapes suivantes peuvent aider à identifier et à atténuer les pertes de paquets NetFlow : #### Identification des pertes de paquets {#identifying-packet-drops} -Utilisez la commande `netstat -s` pour voir s'il y a des paquets UDP perdus : +Utilisez la commande `netstat -s` pour voir s'il y a des paquets UDP perdus : ```bash netstat -s @@ -341,7 +350,7 @@ Utilisez la commande `netstat -s` pour voir s'il y a des paquets UDP perdus : 2. Augmenter la longueur de la file d'attente UDP (Linux uniquement) - Ajuster la longueur de la file d'attente UDP de votre système peut aider à gérer le volume plus élevé de paquets NetFlow. Augmentez la taille du tampon de réception UDP à 25 Mo en exécutant les commandes suivantes : + L'ajustement de la longueur de la file d'attente UDP de votre système peut aider à gérer le volume plus élevé de paquets NetFlow. Augmentez la taille du tampon de réception UDP à 25 Mo en exécutant les commandes suivantes : ```bash sudo sysctl -w net.core.rmem_max=26214400 @@ -350,14 +359,14 @@ Utilisez la commande `netstat -s` pour voir s'il y a des paquets UDP perdus : 3. Persistance de la configuration (Linux uniquement) - Pour rendre ces changements permanents, ajoutez les lignes suivantes à votre fichier `/etc/sysctl.conf` : + Pour rendre ces changements permanents, ajoutez les lignes suivantes à votre fichier `/etc/sysctl.conf` : ```bash net.core.rmem_max=26214400 net.core.rmem_default=26214400 ``` -## Lectures complémentaires {#further-reading} +## Pour aller plus loin {#further-reading} {{< partial name="whats-next/whats-next.html" >}} @@ -367,7 +376,7 @@ Utilisez la commande `netstat -s` pour voir s'il y a des paquets UDP perdus : [4]: /fr/agent/configuration/agent-commands/?tab=agentv6v7#start-stop-and-restart-the-agent [5]: https://app.datadoghq.com/devices/netflow [6]: /fr/monitors/types/netflow/ -[7]: https://github.com/DataDog/datadog-agent/blob/f6ae461a7d22aaf398de5a94d9330694d69560d6/pkg/config/config_template.yaml#L4201 -[8]: https://github.com/DataDog/datadog-agent/blob/f6ae461a7d22aaf398de5a94d9330694d69560d6/pkg/config/config_template.yaml#L4203-L4275 +[7]: https://github.com/DataDog/datadog-agent/blob/main/pkg/config/example/datadog-agent_linux.yaml.example [9]: /fr/network_monitoring/devices/troubleshooting#traps-or-flows-not-being-received-at-all -[10]: https://app.datadoghq.com/devices/settings/enrichment/ip \ No newline at end of file +[10]: https://app.datadoghq.com/devices/settings/enrichment/ip +[11]: /fr/network_monitoring/network_path/setup/#dynamic-tests-for-netflow-experimental \ No newline at end of file diff --git a/hugo/content/fr/observability_pipelines/monitoring_and_troubleshooting/monitoring_pipelines.md b/hugo/content/fr/observability_pipelines/monitoring_and_troubleshooting/monitoring_pipelines.md new file mode 100644 index 00000000000..f99b3825ef2 --- /dev/null +++ b/hugo/content/fr/observability_pipelines/monitoring_and_troubleshooting/monitoring_pipelines.md @@ -0,0 +1,87 @@ +--- +aliases: +- /fr/observability_pipelines/monitoring/ +description: Apprenez à suivre le statut des pipelines, des Workers et des composants + grâce à des graphiques d'état et des monitors prêts à l'emploi. +disable_toc: false +further_reading: +- link: observability_pipelines/set_up_pipelines + tag: Documentation + text: Configurez un pipeline +- link: /monitors/types/metric/ + tag: Documentation + text: Configurez un monitor de métriques +- link: /observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/ + tag: Documentation + text: Métriques d'utilisation d'Observability Pipelines +- 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: Surveillance des Pipelines +--- +## Présentation {#overview} + +Un pipeline se compose de composants qui collectent, traitent et acheminent vos données d'observabilité. Vous pouvez suivre le statut de vos pipelines et composants de la manière suivante : + +- Visualisez les graphiques d'état de vos [pipelines](#view-the-status-of-your-pipelines), [Workers](#view-the-status-of-your-workers) et [composants](#view-the-status-of-your-pipeline-components) (sources, processeurs et destinations). +- Activez des [monitors prêts à l'emploi](#out-of-the-box-monitors) qui vous alertent si : + - Un Observability Pipelines Worker présente une utilisation élevée du processeur ou de la mémoire, ou perd des données. + - Un composant émet des erreurs. + - Un quota défini a été atteint. +- Créez vos propres dashboards, notebooks et monitors avec les [métriques Observability Pipelines][5] disponibles. + +{{< img src="observability_pipelines/monitoring_and_troubleshooting/pipelines_list.png" alt="La page de liste Pipelines affichant le statut, les événements/s et les octets/s pour chaque pipeline." style="width:100%;" >}} + +## Visualisez le statut de vos pipelines {#view-the-status-of-your-pipelines} + +1. Accédez à [Observability Pipelines][1] pour voir combien d'événements ou d'octets vos pipelines reçoivent et envoient. Les métriques {{< ui >}}events/s{{< /ui >}} et {{< ui >}}bytes/s{{< /ui >}} affichées sur cette page sont basées sur une moyenne sur 15 minutes. +1. Sélectionnez un pipeline. +1. Cliquez sur l'onglet {{< ui >}}Health{{< /ui >}} pour voir les détails concernant le pipeline et ses composants. Vous pouvez visualiser des graphiques de : + - Dans quelle mesure chaque composant est utilisé, et le nombre total d'événements que le composant reçoit et envoie. + - Le nombre de requêtes effectuées vers des destinations, et le nombre d'erreurs rencontrées par ces requêtes. + - Combien d'événements sont intentionnellement et involontairement abandonnés. + - Toute modification du nombre de requêtes et d'erreurs pour chaque composant au cours de la semaine précédente. + +Vous pouvez exporter un graphique d'état vers un dashboard, un notebook ou un monitor. Le graphique exporté vous montre que la métrique est regroupée par les tags spécifiques du pipeline et du composant. + +## Voir le statut de vos Workers {#view-the-status-of-your-workers} + +Pour voir les graphiques de l'utilisation des ressources et des données envoyées via les Workers Observability Pipelines : + +1. Accédez à [Observability Pipelines][1]. +1. Sélectionnez un pipeline. +1. Cliquez sur l'onglet {{< ui >}}Workers{{< /ui >}} pour voir l'utilisation de la mémoire et du processeur, les statistiques de trafic et les éventuelles erreurs des Workers. + {{< img src="observability_pipelines/monitoring_and_troubleshooting/workers_tab.png" alt="L'onglet Workers affichant l'utilisation de la mémoire, l'utilisation du processeur, les événements/s, les octets/s et les erreurs pour chaque Worker." style="width:100%;" >}} +1. Cliquez sur l'onglet {{< ui >}}Latest Deployment & Setup{{< /ui >}} pour voir le statut de déploiement de vos Workers. + {{< img src="observability_pipelines/monitoring_and_troubleshooting/worker_deployment_status.png" alt="L'onglet « Latest Deployment and Setup » affiche un statut déployé pour chaque Worker." style="width:100%;" >}} + +## Voir le statut des composants de votre pipeline {#view-the-status-of-your-pipeline-components} + +Pour voir les métriques d'une source, d'un processus ou d'une destination : + +1. Accédez à [Observability Pipelines][1]. +1. Sélectionnez un pipeline. +1. Cliquez sur la roue dentée à côté du nom de la source, du processeur ou de la destination, puis sélectionnez {{< ui >}}View details{{< /ui >}}. Datadog affiche des graphiques d'état pour le composant que vous avez sélectionné. +1. Si vous souhaitez exporter un graphique vers un [incident][2], un [dashboard][3] ou un [notebook][4], cliquez sur l'icône d'exportation sur le graphique. Le graphique exporté montre que la métrique est regroupée par les tags spécifiques du pipeline et du composant. + +{{< img src="observability_pipelines/monitoring_and_troubleshooting/pipeline_health_graphs.png" alt="Graphiques d'état affichant les événements entrants et sortants, les octets entrants et sortants, les erreurs, les données abandonnées, l'utilisation et les événements de tampon pour un pipeline." style="width:35%;" >}} + +## Monitors prêts à l'emploi {#out-of-the-box-monitors} + +Pour voir les monitors prêts à l'emploi disponibles : + +1. Accédez à [Observability Pipelines][1]. +1. Cliquez sur {{< ui >}}Enable monitors{{< /ui >}} dans la colonne {{< ui >}}Monitors{{< /ui >}} pour votre pipeline. +1. Cliquez sur {{< ui >}}Start{{< /ui >}} pour configurer un monitor pour l'un des cas d'utilisation suggérés.
+ La nouvelle page de monitor de métriques est configurée en fonction du cas d'utilisation que vous avez sélectionné. Vous pouvez mettre à jour la configuration pour la personnaliser davantage. Consultez la [documentation du monitor de métriques][3] pour plus d'informations. + +## Pour aller plus loin {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://app.datadoghq.com//observability-pipelines/ +[2]: /fr/incident_response/incident_management/ +[3]: /fr/monitors/types/metric/ +[4]: /fr/notebooks/ +[5]: /fr/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/ \ No newline at end of file diff --git a/hugo/content/fr/observability_pipelines/processors/custom_processor.md b/hugo/content/fr/observability_pipelines/processors/custom_processor.md new file mode 100644 index 00000000000..ea0b1afb55c --- /dev/null +++ b/hugo/content/fr/observability_pipelines/processors/custom_processor.md @@ -0,0 +1,97 @@ +--- +disable_toc: false +further_reading: +- link: /observability_pipelines/guide/remap_reserved_attributes/ + tag: Documentation + text: Remappez les attributs réservés +- link: /logs/guide/regex_log_parsing/ + tag: guide + text: Rédaction de règles de parsing Grok efficaces avec des expressions régulières +- 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 +products: +- icon: logs + name: Logs + url: /observability_pipelines/configuration/?tab=logs#pipeline-types +- icon: metrics + name: Métriques + url: /observability_pipelines/configuration/?tab=metrics#pipeline-types +title: Processeur personnalisé +--- +{{< product-availability >}} + +## Présentation {#overview} + +Utilisez ce processeur avec Vector Remap Language (VRL) pour modifier et enrichir vos logs ou métriques. Le VRL est un langage orienté expression, spécifique à un domaine, conçu pour transformer les données. Il propose des fonctions intégrées pour les cas d'utilisation liés à l'observabilité. Vous pouvez utiliser des fonctions personnalisées de la manière suivante : + +- Manipuler des [tableaux](#array), des [chaînes de caractères](#string) et d'autres types de données. +- Encoder et décoder des valeurs en utilisant [Codec](#codec). +- [Chiffrer](#encrypt) et [déchiffrer](#decrypt) des valeurs. +- [Convertir](#coerce) un type de données en un autre (par exemple, d'un entier vers une chaîne de caractères). +- [Convertir des valeurs syslog](#convert) en valeurs lisibles. +- Enrichir des valeurs en utilisant des [tables d'enrichissement](#enrichment). +- [Manipuler des valeurs IP](#ip). +- Calculer [des distances géographiques](#map) et des azimuts avec la formule haversine. +- [Analyser](#parse) des valeurs avec des règles personnalisées (par exemple, grok, regex, etc.) et des fonctions prêtes à l'emploi (par exemple, syslog, apache, logs de flux VPC, etc.). Consultez [Rédaction de règles de parsing Grok efficaces avec des expressions régulières][3] pour plus d'informations. +- Manipuler des [chemins d'événements](#path). + +Consultez [Fonctions personnalisées](#custom-functions) pour obtenir la liste complète des fonctions disponibles. + +Consultez [Remappage des attributs réservés][1] pour savoir comment utiliser le processeur personnalisé afin de remapper manuellement et dynamiquement les attributs. + +## Configuration {#setup} + +Pour configurer ce processeur : + +- Si vous n'avez pas encore créé de fonctions, cliquez sur {{< ui >}}Add custom processor{{< /ui >}} et suivez les instructions dans [Ajouter une fonction](#add-a-function) pour en créer une. +- Si vous avez déjà ajouté des fonctions personnalisées, cliquez sur {{< ui >}}Manage custom processors{{< /ui >}}. Cliquez sur une fonction dans la liste pour la modifier ou la supprimer. Vous pouvez utiliser la barre de recherche pour trouver une fonction par son nom. Cliquez sur {{< ui >}}Add Custom Processor{{< /ui >}} pour [ajouter une fonction](#add-a-function). + +### Ajouter une fonction {#add-a-function} + +1. Saisissez un nom pour votre processeur personnalisé. +1. Ajoutez votre script pour modifier vos données en utilisant [fonctions personnalisées][1]. Vous pouvez également cliquer sur {{< ui >}}Autofill with Example{{< /ui >}} et sélectionner l'un des cas d'utilisation courants pour commencer. Cliquez sur l'icône de copie pour l'exemple de script et collez-le dans votre script. Consultez [Commencez avec le processeur personnalisé][2] pour plus d'informations. +1. Optionnellement, cochez {{< ui >}}Drop events on error{{< /ui >}} si vous souhaitez supprimer les événements qui rencontrent une erreur lors du traitement. +1. Saisissez un événement exemple. +1. Cliquez sur {{< ui >}}Run{{< /ui >}} pour prévisualiser la façon dont les fonctions traitent l'événement. Une fois le script exécuté, vous pouvez voir le résultat pour l'événement. +1. Cliquez sur {{< ui >}}Save{{< /ui >}}. + +## Fonctions personnalisées {#custom-functions} + +{{< whatsnext desc="Les fonctions sont organisées dans les catégories suivantes :" >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#array" >}}Tableau{{< /nextlink >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#codec" >}}Codec{{< /nextlink >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#convert" >}}Convertir{{< /nextlink >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#cryptography" >}}Cryptographie{{< /nextlink >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#debug" >}}Débogage{{< /nextlink >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#enrichment" >}}Enrichissement{{< /nextlink >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#ip" >}}IP{{< /nextlink >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#map" >}}Map{{< /nextlink >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#number" >}}Numéro{{< /nextlink >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#object" >}}Objet{{< /nextlink >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#parse" >}}Analyser{{< /nextlink >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#path" >}}Chemin{{< /nextlink >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#random" >}}Aléatoire{{< /nextlink >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#string" >}}String{{< /nextlink >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#system" >}}Système{{< /nextlink >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#timestamp" >}}Timestamp{{< /nextlink >}} + {{< nextlink href="observability_pipelines/processors/custom_processor/#type" >}}Type{{< /nextlink >}} +{{< /whatsnext >}} + +{{< vrl-functions >}} + +## Métriques de santé {#health-metrics} + +Pour les [métriques de composant][4] et les [métriques de tampon de processeur][5] émis par tous les processeurs, consultez la documentation sur les [métriques d'utilisation des pipelines][6]. Pour filtrer ou grouper par métrique du processeur personnalisé, utilisez le tag `component_type:remap_vrl`. + +## Lectures complémentaires {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /fr/observability_pipelines/guide/remap_reserved_attributes +[2]: /fr/observability_pipelines/guide/get_started_with_the_custom_processor +[3]: /fr/logs/guide/regex_log_parsing/ +[4]: /fr/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#component-metrics +[5]: /fr/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#processor-buffer-metrics +[6]: /fr/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/ \ No newline at end of file diff --git a/hugo/content/fr/observability_pipelines/processors/generate_metrics.md b/hugo/content/fr/observability_pipelines/processors/generate_metrics.md new file mode 100644 index 00000000000..fc616f92f3a --- /dev/null +++ b/hugo/content/fr/observability_pipelines/processors/generate_metrics.md @@ -0,0 +1,143 @@ +--- +disable_toc: false +products: +- icon: logs + name: Logs + url: /observability_pipelines/configuration/?tab=logs#pipeline-types +title: Processeur de génération de métriques basées sur les logs +--- +{{< product-availability >}} + +## Présentation {#overview} + +De nombreux types de logs sont utilisés pour suivre des tendances, tels que les KPI, sur de longues périodes. Générer des métriques à partir de vos logs est un moyen rentable de résumer les données de logs provenant de logs volumineux, tels que les logs de CDN, les logs de flux VPC, les logs de pare-feu et les logs de réseau. Utilisez le processeur de génération de métriques pour générer des métriques de comptage, de jauge ou de distribution à partir de logs correspondant à une requête, et envoyez-les vers votre destination. + +**Remarque** : Les métriques générées à partir des logs et acheminées vers Datadog sont des [métriques personnalisées][1] et facturées en conséquence. Consultez [Facturation des Custom Metrics][2] pour plus d’informations. + +## Configuration {#setup} + +Pour configurer le processeur : + +Cliquez sur {{< ui >}}Manage Metrics{{< /ui >}} pour créer de nouvelles métriques ou modifier des métriques existantes. Cela ouvre un panneau latéral. + +- Si vous n’avez pas encore créé de métriques, saisissez les paramètres de métrique comme décrit dans la section [Ajouter une métrique](#add-a-metric) pour créer une métrique. +- Si vous avez déjà créé des métriques, cliquez sur la ligne de la métrique dans le tableau de synthèse pour la modifier ou la supprimer. Utilisez la barre de recherche pour trouver une métrique spécifique par son nom, puis sélectionnez la métrique pour la modifier ou la supprimer. Cliquez sur {{< ui >}}Add Metric{{< /ui >}} pour ajouter une autre métrique. + +### Ajouter une métrique {#add-a-metric} + +
Le processeur de génération de métriques utilise le timestamp champ sur un log pour définir l’horodatage de la métrique. Si le log timestamp est une valeur de chaîne, le temps de traitement du log est utilisé à la place. Consultez Convertir un horodatage de chaîne au format horodatage pour plus d’informations.
+ +1. Saisissez une requête de filtre. Consultez [Syntaxe de recherche de logs][5] pour plus d’informations. + - Seuls les logs correspondant au filtre sont traités. + - Tous les logs, qu’ils correspondent ou non à la requête de filtrage, sont envoyés à l’étape suivante du pipeline. + - **Remarque** : Comme un seul processeur peut générer plusieurs métriques, vous pouvez définir une requête de filtrage différente pour chaque métrique. +1. Saisissez un nom pour la métrique. +1. Dans la section {{< ui >}}Define parameters{{< /ui >}}, sélectionnez le type de métrique (compte, jauge ou distribution). Consultez l’[exemple de métrique Count](#count-metric-example) et l’[exemple de métrique Distribution](#distribution-metric-example). Consultez également [Types de métriques](#metrics-types) pour plus d’informations. + - Pour les types de métriques 'jauge' et 'distribution', sélectionnez un champ de log qui possède une valeur numérique (ou une chaîne numérique analysable) utilisée pour la valeur de la métrique générée. + - Pour le type de métrique de distribution, la valeur du champ de log peut être un tableau de valeurs numériques (analysables), qui est utilisé pour l'ensemble d'échantillons de la métrique générée. + - Le champ {{< ui >}}Group by{{< /ui >}} détermine comment les valeurs de métrique sont regroupées. Par exemple, si vous avez des centaines d'hôtes répartis dans quatre régions, le regroupement par région vous permet de représenter une ligne pour chaque région. Les champs listés dans le paramètre {{< ui >}}Group by{{< /ui >}} sont définis comme des tags sur la métrique configurée. +1. Cliquez sur {{< ui >}}Add Metric{{< /ui >}}. + +### Configurez une destination de métriques {#configure-a-metrics-destination} + +{{< callout url="#" btn_hidden="true" header="Rejoignez la Preview !">}} +L'envoi de métriques générées à partir de logs vers la destination Splunk HEC, Elasticsearch ou Client HTTP/S est en préversion. Contactez votre responsable de compte pour demander l'accès. +{{< /callout >}} + +
L'option d'envoyer des métriques générées vers une destination autre que Datadog Metrics est disponible pour les versions 2.18 et ultérieures de Worker.

Si vous effectuez une mise à niveau vers la version 2.18 ou ultérieure de Worker pour un pipeline existant qui possède déjà un processeur Generate Metrics et que vous souhaitez sélectionner une destination autre que Datadog Metrics, vous devez :
    1. Supprimer le processeur Generate Metrics précédent.
    2. Ajouter et configurer un nouveau processeur Generate Metrics.
+ +{{< img src="observability_pipelines/processors/generate_metrics_destination.png" alt="Le processeur Generate Metrics avec « Select a destination » mis en surbrillance." style="width:50%;" >}} + +1. Sur le processeur Generate Metrics, cliquez sur **Add Metrics Destination**.
**Remarque** : Si vous utilisez la simulation de pipeline, retournez à la page du pipeline pour configurer votre destination de métriques. Cliquez sur **Back to pipeline** dans le coin supérieur droit de la page de simulation de pipeline. +1. [Datadog Metrics][6] est la destination par défaut. Pour sélectionner une destination différente, cliquez sur l'icône en forme de crayon sur la destination Datadog Metrics et sélectionnez **Changer la destination des métriques**. +1. Sélectionnez votre destination et suivez les instructions de configuration pour la [destination][7] spécifique. + +## Types de métriques {#metrics-types} + +Vous pouvez générer ces types de métriques pour vos logs. Consultez la documentation sur les [Types de métriques][3] et les [Distributions][4] pour plus de détails. + +| Type de métrique | Description | Exemple | +| ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | +| COMPTE | Le nombre total d'occurrences d'événements dans un intervalle de temps. Peut être réinitialisé à zéro, mais ne peut pas être diminué. | Vous souhaitez compter le nombre de logs avec `status:error`. | +| JAUGE | Un instantané d'une valeur au moment où elle est rapportée. | Vous souhaitez suivre la dernière utilisation du processeur par host. | +| DISTRIBUTION | Valeurs brutes envoyées à Datadog afin que les agrégations de centiles (telles que p95, p99) soient calculées côté serveur, globalement sur chaque host rapportant la métrique. | Vous souhaitez obtenir le p95 global de `response_time_seconds` sur chaque host desservant un endpoint d'API. | + +### Exemple de métrique de type Count {#count-metric-example} + +Pour cet exemple de log `status:error` : + +``` +{"status": "error", "env": "prod", "host": "ip-172-25-222-111.ec2.internal"} +``` + +Pour créer une métrique de type Count qui compte le nombre de logs contenant `"status":"error"` et les regroupe par `env` et `host`, saisissez les informations suivantes : + +| Paramètres d'entrée | Valeur | +|------------------|---------------------| +| Requête de filtre | `@status:error` | +| Nom de la métrique | `status_error_total`| +| Type de métrique | Count | +| Grouper par | `env`, `prod` | + +### Exemple de métrique de distribution {#distribution-metric-example} + +Pour cet exemple de log de réponse d'API : + +``` +{ + "timestamp": "2018-10-15T17:01:33Z", + "method": "GET", + "status": 200, + "request_body": "{"information"}", + "response_time_seconds: 10 +} +``` + +Pour créer une métrique de distribution qui mesure le temps moyen nécessaire pour effectuer un appel API, saisissez les informations suivantes : + +| Paramètres d'entrée | Valeur | +|------------------------|-------------------------| +| Requête de filtre | `@method` | +| Nom de la métrique | `status_200_response` | +| Type de métrique | Distribution | +| Sélectionnez un attribut de log | `response_time_seconds` | +| Grouper par | `method` | + +## Convertir l'horodatage de chaîne au format horodatage {#convert-string-timestamp-to-timestamp-format} + +Le processeur Generate Metrics ne peut utiliser le champ de log `timestamp` pour définir l'horodatage de la métrique que si le champ de log est de type horodatage. Si le champ `timestamp` est une chaîne, l'heure à laquelle le log est traité est utilisée à la place. Pour utiliser le `timestamp` de log, vous devez convertir la chaîne en type horodatage avant d'envoyer les logs au processeur Generate Metrics. + +Pour convertir un horodatage de chaîne au format horodatage : + +1. Ajoutez un [Custom Processor][8] à votre pipeline avant le processeur Generate Metrics. +1. Ajoutez une fonction avec le script personnalisé suivant : + ``` + .timestamp = parse_timestamp!(.timestamp, format: "%+") + ``` + See [parse_timestamp][9] for more information. + +## Métriques de santé {#health-metrics} + +Pour les [métriques de composant][10] et les [métriques de tampon de processeur][11] émises par tous les processeurs, consultez la documentation [Pipelines Usage Metrics][12]. + +### Métriques du processeur Generate Metrics {#generate-metrics-processor-metrics} + +- Utilisez le tag `component_id` pour filtrer ou regrouper par composants individuels. +- Le tag `component_type` est `generate_metrics` pour les métriques de ce processeur. + +`pipelines.generated_metrics_from_logs_total` +: **Description**: Le nombre de métriques générées à partir des événements de log par le processeur. +: **Type de métrique** : count + +[1]: /fr/metrics/custom_metrics/ +[2]: /fr/account_management/billing/custom_metrics/ +[3]: /fr/metrics/types/ +[4]: /fr/metrics/distributions/ +[5]: /fr/observability_pipelines/search_syntax/logs/ +[6]: /fr/observability_pipelines/destinations/datadog_metrics/ +[7]: /fr/observability_pipelines/destinations/?tab=metrics#destinations +[8]: /fr/observability_pipelines/processors/custom_processor/#setup +[9]: /fr/observability_pipelines/processors/custom_processor/#parse_timestamp +[10]: /fr/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#component-metrics +[11]: /fr/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#processor-buffer-metrics +[12]: /fr/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/ \ No newline at end of file diff --git a/hugo/content/fr/observability_pipelines/processors/parse_xml.md b/hugo/content/fr/observability_pipelines/processors/parse_xml.md new file mode 100644 index 00000000000..60a082ae759 --- /dev/null +++ b/hugo/content/fr/observability_pipelines/processors/parse_xml.md @@ -0,0 +1,145 @@ +--- +description: Apprenez à utiliser le processeur Parse XML pour analyser des données + XML afin qu'elles puissent être traitées et envoyées vers des destinations. +disable_toc: false +further_reading: +- 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 +- link: https://www.datadoghq.com/blog/observability-pipelines-mssp + tag: Blog + text: Simplifiez la collecte et l'agrégation des logs pour les MSSP avec Datadog + Observability Pipelines +- link: https://www.datadoghq.com/blog/observability-pipelines-parsing-xml-logs/ + tag: Blog + text: Simplifiez la collecte et le traitement des logs XML avec Observability Pipelines +products: +- icon: logs + name: Logs + url: /observability_pipelines/configuration/?tab=logs#pipeline-types +title: Processeur Parse XML +--- +{{< product-availability >}} + +## Présentation {#overview} + +Ce processeur analyse le langage de balisage extensible (XML) afin que les données puissent être traitées et envoyées vers différentes destinations. Le XML est un format de log utilisé pour stocker et transporter des données structurées. Il est organisé dans une structure arborescente pour représenter des informations imbriquées et utilise des tags et des attributs pour définir les données. Par exemple, voici des données XML utilisant uniquement des tags (``, `` et ``) et aucun attribut : + +```xml + + pasta + Carbonara + +``` + +Voici un exemple XML où le tag `recipe` possède l'attribut `type` : + +```xml + + + Carbonara + +``` + +L'image suivante montre un log d'événement Windows 4625 au format XML, à côté du même log analysé et généré au format JSON. En analysant le log XML, la taille de l'événement de log a été réduite d'environ 30 %. + +{{< img src="observability_pipelines/processors/xml-side-by-side.png" alt="Le log XML et le log analysé résultant au format JSON" style="width:80%;" >}} + +## Configuration {#setup} + +Pour configurer ce processeur : + +1. Définissez un {{< ui >}}filter query{{< /ui >}}. Consultez [Logs Search Syntax][1] pour plus d'informations. + - Seuls les logs correspondant au filtre sont traités. + - Tous les logs, qu'ils correspondent ou non à la requête de filtrage, sont envoyés à l'étape suivante du pipeline. +1. Saisissez le chemin d'accès au champ de log sur lequel vous souhaitez analyser le XML. Utilisez la notation de chemin `.` pour faire correspondre les sous-champs. Consultez l'exemple de [notation de chemin](#path-notation-example-parse-xml) ci-dessous. +1. Optionnellement, dans le champ `Enter text key`, saisissez le nom de clé à utiliser pour le nœud de texte lorsque des attributs XML sont ajoutés. Consultez l'[exemple de clé de texte](#text-key-example). Si le champ est laissé vide, `value` est utilisé comme nom de clé. +1. Optionnellement, sélectionnez {{< ui >}}Always use text key{{< /ui >}} si vous souhaitez stocker du texte à l'intérieur d'un objet en utilisant la clé de texte même lorsqu'aucun attribut n'existe. +1. Optionnellement, activez {{< ui >}}Include XML attributes{{< /ui >}} si vous souhaitez inclure les attributs XML. Vous pouvez ensuite choisir d'ajouter le préfixe d'attribut que vous souhaitez utiliser. Voir [l'exemple de préfixe d'attribut](#attribute-prefix-example). Si le champ est laissé vide, la clé d'attribut d'origine est utilisée. +1. Optionnellement, sélectionnez si vous souhaitez convertir les types de données en nombres, booléens ou valeurs nulles. + - Si {{< ui >}}Numbers{{< /ui >}} est sélectionné, les nombres sont analysés en tant qu'entiers et nombres à virgule flottante. + - Si {{< ui >}}Booleans{{< /ui >}} est sélectionné, `true` et `false` sont analysés en tant que booléens. + - Si {{< ui >}}Nulls{{< /ui >}} est sélectionné, la chaîne `null` est analysée en tant que valeur nulle. + +### Exemple de notation de chemin {#path-notation-example-parse-xml} + +{{% observability_pipelines/path_notation %}} + +{{% observability_pipelines/path_notation_dots %}} + +### Toujours utiliser l'exemple de clé de texte {#always-use-text-key-example} + +Si {{< ui >}}Always use text key{{< /ui >}} est sélectionné, la clé de texte est la valeur par défaut (`value`), et vous avez le XML suivant : + +```xml + + + Carbonara + +``` + +Le XML est converti en : + +```json +{ + "recipe": { + "type": "pasta", + "value": "Carbonara" + } +} +``` + +### Exemple de clé de texte {#text-key-example} + +Si la clé est `text` et que vous avez le XML suivant : + +```xml + + + Carbonara + +``` + +Le XML est converti en : + +```json +{ + "recipe": { + "type": "pasta", + "text": "Carbonara" + } +} +``` + +### Exemple de préfixe d'attribut {#attribute-prefix-example} + +Si vous activez {{< ui >}}Include XML attributes{{< /ui >}}, l'attribut est ajouté en tant que préfixe à chaque attribut XML. Par exemple, si le préfixe d'attribut est `@` et que vous avez le XML suivant : + +```xml +Carbonara +``` + +Il est alors converti en JSON : + +```json +{ + "recipe": { + "@type": "pasta", + "": "Carbonara" + } +} +``` + +## Métriques de santé {#health-metrics} + +Pour les [métriques de composants][2] et les [métriques de tampon de processeur][3] émises par tous les processeurs, consultez la documentation sur les [Métriques d'utilisation des pipelines][4]. Pour filtrer ou grouper par métriques de processeur d'analyse, utilisez le tag `component_type:parse`. + +[1]: /fr/observability_pipelines/search_syntax/logs/ +[2]: /fr/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#component-metrics +[3]: /fr/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#processor-buffer-metrics +[4]: /fr/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/ + +## Pour aller plus loin {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} \ No newline at end of file diff --git a/hugo/content/fr/observability_pipelines/processors/sensitive_data_scanner.md b/hugo/content/fr/observability_pipelines/processors/sensitive_data_scanner.md new file mode 100644 index 00000000000..c44b915a197 --- /dev/null +++ b/hugo/content/fr/observability_pipelines/processors/sensitive_data_scanner.md @@ -0,0 +1,414 @@ +--- +description: Apprenez à utiliser le processeur Sensitive Data Scanner pour détecter + et masquer ou hacher des informations sensibles telles que les informations personnelles + identifiables (PII) et les données de Payment Card Industry (PCI) dans les logs + ou traces. +disable_toc: false +further_reading: +- link: /logs/guide/regex_log_parsing/ + tag: guide + text: Rédaction de règles de parsing Grok efficaces avec des expressions régulières +- 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 +products: +- icon: logs + name: Logs + url: /observability_pipelines/configuration/?tab=logs#pipeline-types +title: Processeur Sensitive Data Scanner +--- +{{< product-availability >}} + +## Présentation {#overview} + +Le processeur Sensitive Data Scanner analyse les logs pour détecter et masquer ou hacher des informations sensibles telles que les PII, les PCI et les données sensibles personnalisées. Vous pouvez choisir parmi la bibliothèque de règles prédéfinies de Datadog ou saisir des règles Regex personnalisées pour rechercher des données sensibles. + +Vous pouvez configurer le pipeline et le processeur dans le [UI](#set-up-the-processor-in-the-ui), l'[API][10] ou [Terraform](#set-up-the-processor-using-terraform). + +Consultez les [bonnes pratiques pour optimiser les performances](#best-practices-to-optimize-performance) pour obtenir des conseils sur la réduction de l'utilisation des ressources. + +## Configurez le processeur dans le UI {#set-up-the-processor-in-the-ui} + +Pour configurer le processeur : + +1. Définissez un {{< ui >}}filter query{{< /ui >}}. Consultez [Logs Search Syntax][1] pour plus d'informations. + - Seuls les événements correspondant au filtre sont analysés et traités. + - Tous les événements, qu'ils correspondent ou non à la requête de filtrage, sont envoyés à l'étape suivante du pipeline. +1. Cliquez sur {{< ui >}}Add Scanning Rule{{< /ui >}}. +1. Sélectionnez l'une des options suivantes: + +{{< tabs >}} +{{% tab "Règles de bibliothèque" %}} + +1. Dans le menu déroulant, sélectionnez la règle de bibliothèque que vous souhaitez utiliser. +1. Les mots-clés recommandés sont automatiquement ajoutés en fonction de la règle de bibliothèque sélectionnée. Une fois la règle d'analyse ajoutée, vous pouvez [ajouter des mots-clés supplémentaires ou supprimer des mots-clés recommandés](#add-additional-keywords). +1. Dans la section {{< ui >}}Define rule target and conditions{{< /ui >}}, sélectionnez si vous souhaitez analyser {{< ui >}}Entire Event{{< /ui >}}, {{< ui >}}Specific Attributes{{< /ui >}} ou {{< ui >}}Exclude Attributes{{< /ui >}} dans le menu déroulant. + - Si vous analysez l'événement entier, vous pouvez éventuellement exclure des attributs spécifiques de l'analyse. Utilisez la [notation de chemin](#path-notation-example) (`outer_key.inner_key`) pour accéder aux clés imbriquées. Pour les attributs spécifiés contenant des données imbriquées, toutes les données imbriquées sont exclues. + - Si vous analysez des attributs spécifiques, indiquez les attributs que vous souhaitez analyser. Utilisez la [notation de chemin](#path-notation-example) (`outer_key.inner_key`) pour accéder aux clés imbriquées. Pour les attributs spécifiés avec des données imbriquées, toutes les données imbriquées sont analysées. +1. Pour {{< ui >}}Define actions on match{{< /ui >}}, sélectionnez l'action que vous souhaitez effectuer pour les informations correspondantes. **Remarque** : La rédaction, la rédaction partielle et le hachage sont tous des actions irréversibles. + - {{< ui >}}Redact{{< /ui >}} : Remplace toutes les valeurs correspondantes par le texte que vous spécifiez dans le champ {{< ui >}}Replacement text{{< /ui >}}. + - {{< ui >}}Partially Redact{{< /ui >}} : Remplace une partie spécifiée de toutes les données correspondantes. Dans la section {{< ui >}}Redact{{< /ui >}}, spécifiez le nombre de caractères que vous souhaitez masquer et quelle partie des données correspondantes masquer. + - {{< ui >}}Hash{{< /ui >}} : Remplace toutes les données correspondantes par un identifiant unique. Les octets UTF-8 de la correspondance sont hachés avec l'empreinte 64 bits de FarmHash. +1. Facultativement, cliquez sur {{< ui >}}Add Field{{< /ui >}} pour ajouter des tags que vous souhaitez associer aux événements correspondants. +1. Ajoutez un nom pour la règle d'analyse. +1. Facultativement, ajoutez une description pour la règle. +1. Cliquez sur {{< ui >}}Save{{< /ui >}}. + +### Ajoutez des mots-clés supplémentaires {#add-additional-keywords} + +Après avoir ajouté des règles d'analyse depuis la bibliothèque, vous pouvez modifier chaque règle séparément et ajouter des mots-clés supplémentaires au dictionnaire de mots-clés. + +1. Accédez à votre [pipeline][1]. +1. Dans le processeur Sensitive Data Scanner avec la règle que vous souhaitez modifier, cliquez sur {{< ui >}}Manage Scanning Rules{{< /ui >}}. +1. Activez {{< ui >}}Use recommended keywords{{< /ui >}} si vous souhaitez que la règle les utilise. Sinon, ajoutez vos propres mots-clés dans le champ {{< ui >}}Create keyword dictionary{{< /ui >}}. Vous pouvez également exiger que ces mots-clés se trouvent à un nombre spécifié de caractères d'une correspondance. Par défaut, les mots-clés doivent se trouver dans les 30 caractères précédant une valeur correspondante. +1. Cliquez sur {{< ui >}}Update{{< /ui >}}. + +[1]: https://app.datadoghq.com/observability-pipelines + +{{% /tab %}} +{{% tab "Règles personnalisées" %}} + +1. Dans la section {{< ui >}}Define match conditions{{< /ui >}}, spécifiez le motif regex à utiliser pour la correspondance avec les événements dans le champ {{< ui >}}Define the regex{{< /ui >}}. Consultez [Rédaction de règles de parsing Grok efficaces avec des expressions régulières][1] pour plus d'informations. + Sensitive Data Scanner prend en charge les expressions régulières compatibles Perl (PCRE), mais les motifs suivants ne sont pas pris en charge : + - Rétro-références et sous-expressions de capture (lookarounds) + - Assertions arbitraires de largeur nulle + - Références de sous-routine et motifs récursifs + - Motifs conditionnels + - Verbes de contrôle de retour sur trace (backtracking) + - La directive `\C` « single-byte » (qui rompt les séquences UTF-8) + - La correspondance de nouvelle ligne `\R` + - La directive de réinitialisation du début de correspondance `\K` + - Appels et code intégré + - Groupement atomique et quantificateurs possessifs +1. Saisissez des exemples de données dans le champ {{< ui >}}Add sample data{{< /ui >}} pour vérifier que votre motif regex est valide. +1. Pour {{< ui >}}Create keyword dictionary{{< /ui >}}, ajoutez des mots-clés afin d'affiner la précision de la détection lors de la correspondance avec des conditions regex. Par exemple, si vous recherchez un numéro de carte de crédit Visa à seize chiffres, vous pouvez ajouter des mots-clés tels que `visa`, `credit` et `card`. Vous pouvez également exiger que ces mots-clés se trouvent à un nombre spécifié de caractères d'une correspondance. Par défaut, les mots-clés doivent se trouver dans les 30 caractères précédant une valeur correspondante. +1. Dans la section {{< ui >}}Define rule target and conditions{{< /ui >}}, sélectionnez si vous souhaitez analyser {{< ui >}}Entire Event{{< /ui >}}, {{< ui >}}Specific Attributes{{< /ui >}} ou {{< ui >}}Exclude Attributes{{< /ui >}} dans le menu déroulant. + - Si vous analysez l'événement entier, vous pouvez éventuellement exclure des attributs spécifiques de l'analyse. Utilisez la [notation de chemin](#path-notation-example) (`outer_key.inner_key`) pour accéder aux clés imbriquées. Pour les attributs spécifiés contenant des données imbriquées, toutes les données imbriquées sont exclues. + - Si vous analysez des attributs spécifiques, indiquez les attributs que vous souhaitez analyser. Utilisez la [notation de chemin](#path-notation-example-custom) (`outer_key.inner_key`) pour accéder aux clés imbriquées. Pour les attributs spécifiés avec des données imbriquées, toutes les données imbriquées sont analysées. +1. Pour {{< ui >}}Define actions on match{{< /ui >}}, sélectionnez l'action que vous souhaitez effectuer pour les informations correspondantes. **Remarque** : La rédaction, la rédaction partielle et le hachage sont tous des actions irréversibles. + - {{< ui >}}Redact{{< /ui >}} : Remplace toutes les valeurs correspondantes par le texte que vous spécifiez dans le champ {{< ui >}}Replacement text{{< /ui >}}. + - {{< ui >}}Partially Redact{{< /ui >}} : Remplace une partie spécifiée de toutes les données correspondantes. Dans la section {{< ui >}}Redact{{< /ui >}}, spécifiez le nombre de caractères que vous souhaitez masquer et quelle partie des données correspondantes masquer. + - {{< ui >}}Hash{{< /ui >}} : Remplace toutes les données correspondantes par un identifiant unique. Les octets UTF-8 de la correspondance sont hachés avec l'empreinte 64 bits de FarmHash. +1. Facultativement, cliquez sur {{< ui >}}Add Field{{< /ui >}} pour ajouter des tags que vous souhaitez associer aux événements correspondants. +1. Ajoutez un nom pour la règle d'analyse. +1. Facultativement, ajoutez une description pour la règle. +1. Cliquez sur {{< ui >}}Add Rule{{< /ui >}}. + +[1]: /fr/logs/guide/regex_log_parsing/ + +{{% /tab %}} +{{< /tabs >}} + +### Supprimez une règle {#delete-a-rule} + +Pour supprimer une règle dans le Sensitive Data Scanner : + +1. Accédez à [Observability Pipelines][2]. +1. Sélectionnez votre pipeline. +1. Cliquez sur le processeur Sensitive Data Scanner pour le développer. +1. Cliquez sur {{< ui >}}Manage Scanning Rules{{< /ui >}}. +1. Sélectionnez la règle que vous souhaitez supprimer. +1. Cliquez sur {{< ui >}}Delete{{< /ui >}}. + +### Exemple de notation de chemin {#path-notation-example} + +{{% observability_pipelines/path_notation %}} + +{{% observability_pipelines/path_notation_dots %}} + +## Configurez le processeur à l'aide de Terraform {#set-up-the-processor-using-terraform} + +Vous pouvez utiliser la [ressource Terraform Datadog Observability Pipeline][4] pour configurer un pipeline avec le processeur Sensitive Data Scanner. Pour ajouter une règle au processeur Sensitive Data Scanner à l'aide de Terraform : + +1. Utilisez la source de données [Datadog Sensitive Data Scanner Standard Pattern][5] pour récupérer l'ID de règle de la [règle de bibliothèque][6] Sensitive Data Scanner. + + {{< code-block lang="terraform" >}} +data "datadog_sensitive_data_scanner_standard_pattern" "" { + filter = "" +} + {{< /code-block >}} + + Remplacez les espaces réservés : + + - ``Remplacez par un nom à utiliser lors de la configuration ultérieure du processeur Sensitive Data Scanner dans la ressource Observability Pipeline. + - ``Remplacez par le nom exact de la règle. Consultez [Library Rules][6] pour obtenir la liste complète des règles. + + Par exemple, si vous souhaitez utiliser le [AWS Access Key ID Scanner][7], configurez la source de données comme suit : + + {{< code-block lang="terraform" >}} +data "datadog_sensitive_data_scanner_standard_pattern" "aws_access_key" { + filter = "AWS Access Key ID Scanner" +} + {{< /code-block >}} + Consultez l'[exemple de configuration complet](#full-configuration-example) sur la façon d'ajouter des sources de données pour plusieurs règles. + +1. Ajoutez un bloc [rule][9] dans votre ressource Observability Pipeline pour la règle de bibliothèque. + + {{< code-block lang="terraform" >}} +... + sensitive_data_scanner { + rule { + name = "" + tags = [] + on_match { + redact { + replace = "***" + } + } + pattern { + library { + id = data.datadog_sensitive_data_scanner_standard_pattern..id + use_recommended_keywords = true + } + } + scope { + all = true + } + } + } + {{< /code-block >}} + + Remplacez les espaces réservés : + + - `` par un nom pour la règle. Ce nom est affiché dans l'UI des Pipelines. + - ``Remplacez par l'identifiant de la règle que vous avez utilisé dans la source de données à l'étape 1. + + Par exemple, si vous utilisez la source de données [AWS Access Key ID Scanner][7] de l'étape 1, configurez le bloc de règle comme suit : + + {{< code-block lang="terraform" >}} +... + sensitive_data_scanner { + rule { + name = "Redact AWS Access Key IDs" + tags = [] + on_match { + redact { + replace = "***" + } + } + pattern { + library { + id = data.datadog_sensitive_data_scanner_standard_pattern.aws_access_key.id + use_recommended_keywords = true + } + } + scope { + all = true + } + } + } + {{< /code-block >}} + + Consultez l'[exemple de configuration complet](#full-configuration-example) sur la façon d'ajouter plusieurs règles. + +1. Répétez les étapes 1 et 2 pour toutes les règles de bibliothèque que vous souhaitez ajouter. + +### Exemple de configuration complet {#full-configuration-example} + +{{< img src="observability_pipelines/processors/sds_tf_ui.png" alt="Le panneau du processeur Sensitive Data Scanner affichant deux règles d'analyse : Redact AWS Access Key IDs et Redact US SSNs" style="width:60%;" >}} + +Si vous souhaitez utiliser le processeur Sensitive Data Scanner pour rechercher des identifiants de clé d'accès AWS et des numéros de sécurité sociale américains, et les masquer en les remplaçant par la chaîne `***` : + +1. Utilisez la source de données [Datadog Sensitive Data Scanner Standard Pattern][5] pour récupérer les identifiants de règle pour le [AWS Access Key ID Scanner][7] et le [US Social Security Number Scanner][8]. +1. Dans le processeur Sensitive Data Scanner de votre ressource [Datadog Observability Pipeline][4], utilisez les règles Sensitive Data Scanner définies dans les sources de données. + +{{< code-block lang="terraform" >}} +data "datadog_sensitive_data_scanner_standard_pattern" "aws_access_key" { + filter = "AWS Access Key ID Scanner" +} +data "datadog_sensitive_data_scanner_standard_pattern" "us_ssn" { + filter = "US Social Security Number Scanner" +} + +resource "datadog_observability_pipeline" "sensitive_data_pipeline" { + name = "Sensitive Data Pipeline" + + config { + source { + id = "source-0" + datadog_agent {} + } + + processor_group { + display_name = "Processors" + enabled = true + id = "group-0" + include = "*" + inputs = ["source-0"] + + processor { + display_name = "Sensitive Data Scanner" + enabled = true + id = "processor-sds-0" + include = "*" + + sensitive_data_scanner { + rule { + name = "Redact AWS Access Key IDs" + tags = [] + on_match { + redact { + replace = "***" + } + } + pattern { + library { + id = data.datadog_sensitive_data_scanner_standard_pattern.aws_access_key.id + use_recommended_keywords = true + } + } + scope { + all = true + } + } + rule { + name = "Redact US SSNs" + tags = [] + on_match { + redact { + replace = "***" + } + } + pattern { + library { + id = data.datadog_sensitive_data_scanner_standard_pattern.us_ssn.id + use_recommended_keywords = true + } + } + scope { + all = true + } + } + } + } + } + + destination { + id = "destination-0" + inputs = ["group-0"] + datadog_logs {} + } + } +} +{{< /code-block >}} + +## Bonnes pratiques pour optimiser les performances {#best-practices-to-optimize-performance} + +Le processeur Sensitive Data Scanner est intensif en termes de CPU. Utilisez les bonnes pratiques suivantes pour optimiser les performances. + +### Afficher l'utilisation des règles d'analyse avec le dashboard Observability Pipelines Overview {#view-scanning-rule-usage-with-the-observability-pipelines-overview-dashboard} + +Observability Pipelines inclut un dashboard [Observability Pipelines Overview][16] prêt à l'emploi avec une section **Données sensibles trouvées par Observability Pipelines**. Utilisez les widgets de cette section pour voir quelles règles d'analyse correspondent aux données. + +1. Accédez à Dashboards > [Observability Pipelines Overview][16]. +1. Utilisez les variables de modèle (`pipeline_id`, `host`, `worker_uuid`, `component_type`, `component_kind`, `component_id`) en haut du dashboard pour limiter la vue à un pipeline ou un Worker spécifique. +1. Utilisez le sélecteur de temps pour définir une plage temporelle plus large. + +Utilisez les widgets suivants pour évaluer l'utilisation des règles d'analyse de vos processeurs Sensitive Data Scanner: + +- **Logs contenant des données sensibles par règle d'analyse**: Liste chaque règle par nom (par exemple, `visa_card_scanner_1x16_1x19_digits` ou `redact_ipv4`) avec le nombre de correspondances sur la période sélectionnée. Les règles avec un nombre élevé correspondent activement à des données. Il s'agit du widget principal pour voir quelles règles sont utilisées. +- **Nombre total de logs contenant des données sensibles**: Affiche le volume total de données sensibles correspondant à toutes les règles. +- **Logs contenant des données sensibles par pipeline**: Affiche les logs correspondants qui contiennent des données sensibles. Vous pouvez limiter les correspondances par `pipeline_id`, ce qui vous aide à voir si les logs contenant des données sensibles sont trouvés dans tous les pipelines ou uniquement dans des pipelines spécifiques. +- **Logs contenant des données sensibles par host**: Ventile les correspondances de données sensibles par host Worker. Utilisez ce widget pour confirmer la couverture sur l'ensemble de votre déploiement. +- **Modèles contenant des informations sensibles** et **Liste des logs contenant des données sensibles**: Affiche les modèles de logs et les exemples d'événements où des données sensibles ont été trouvées. + +Après avoir identifié les règles sans correspondance sur une période représentative, confirmez qu'elles ne sont pas nécessaires et supprimez-les. Consultez [Supprimer une règle](#delete-a-rule). + +**Remarque**: Une règle avec zéro correspondance signifie que la règle n'a pas trouvé de correspondance dans la période sélectionnée, et non que la règle est invalide. + +### Activez uniquement les règles dont vous avez besoin {#only-enable-rules-you-need} + +Les règles activées mais non utilisées consomment des ressources inutiles. Vérifiez le processeur Sensitive Data Scanner pour voir combien de correspondances chaque règle a eues au cours des dernières 24 heures. + +1. Accédez à [Observability Pipelines][2]. +1. Sélectionnez votre pipeline. +1. Cliquez sur le processeur Sensitive Data Scanner pour le développer. +1. Cliquez sur {{< ui >}}View Scanning Rules{{< /ui >}} pour ouvrir le panneau latéral et voir {{< ui >}}Matches in the last 24 hours{{< /ui >}} pour chaque règle. + +Consultez [Supprimer une règle](#delete-a-rule) pour supprimer une règle inutilisée. + +### Analysez uniquement les événements et les champs qui doivent être analysés pour détecter des données sensibles {#only-scan-the-events-and-fields-that-need-to-be-scanned-for-sensitive-data} + +Le temps nécessaire au Sensitive Data Scanner pour analyser un événement est proportionnel à la taille de l'événement. Pour optimiser les performances du processeur: + +- Si vous connaissez les types d'événements que vous souhaitez analyser, définissez une requête de processeur qui n'envoie au processeur que les événements souhaités. + +- Réduisez le temps de scan en ciblant des attributs d'événement spécifiques à scanner ou en excluant des attributs d'événement du scan. Consultez l'étape {{< ui >}}Define rule target and conditions{{< /ui >}} dans [Configurer le processeur](#set-up-the-processor-in-the-ui). + +### Évaluez et comparez les optimisations de performance {#evaluate-and-benchmark-performance-optimizations} + +Utilisez la métrique `pipelines.component_latency_seconds` pour : + +- Comparez les performances du processeur lorsque vous ajoutez une règle +- Évaluez les performances après avoir effectué des changements d'optimisation, tels que la réduction du nombre de champs analysés et la suppression des règles inutilisées. + +Pour afficher la métrique `pipelines.component_latency_seconds` : + +1. Accédez à [Metrics Explorer][11]. +1. Dans le champ de la métrique, saisissez `pipelines.component_latency_seconds`. +1. Dans le champ {{< ui >}}from{{< /ui >}}, saisissez le tag `component_id:`, où `` est l'ID de votre processeur Sensitive Data Scanner. + +**Remarque**: `pipelines.component_latency_seconds` est une métrique de distribution, vous devez donc activer les percentiles pour cette métrique. Consultez [Activer les requêtes avancées][12] pour obtenir des instructions. + +## Métriques de santé {#health-metrics} + +Pour les [métriques de composants][13] et les [métriques de tampon de processeur][14] émises par tous les processeurs, consultez la documentation [Métriques d'utilisation des pipelines][15]. + +### Métriques du Sensitive Data Scanner {#sensitive-data-scanner-metrics} + +- Utilisez le tag `component_id` pour filtrer ou regrouper par composants individuels. +- Le tag `component_type` est `sensitive_data_scanner` pour les métriques du processeur Sensitive Data Scanner. + +`pipelines.sds_rule_matched_total` +: **Description**: Le nombre d'événements ayant correspondu à une règle Sensitive Data Scanner. Marqué avec le nom de la règle correspondante. +: **Type de métrique**: count + +`pipelines.scanned_events` +: **Description**: Le nombre d'événements analysés par le moteur Sensitive Data Scanner. +: **Type de métrique**: count + +`pipelines.scanning.match_count` +: **Description** : Le nombre de correspondances trouvées par le Sensitive Data Scanner. +: **Type de métrique** : count + +`pipelines.scanning.suppressed_match_count` +: **Description** : Le nombre de correspondances supprimées par le Sensitive Data Scanner. +: **Type de métrique** : count + +`pipelines.scanning.duration` +: **Description** : Temps réel accumulé, en secondes, passé à analyser les événements. Utilisez cette métrique pour évaluer les performances du processeur et mesurer les optimisations. +: **Type de métrique** : count + +`pipelines.scanning.cpu_duration` +: **Description** : Temps CPU accumulé, en secondes, passé à analyser les événements. +: **Type de métrique** : count + +`pipelines.scanner.total_count` +: **Description** : Le nombre de processeurs Sensitive Data Scanner actuellement en cours d'exécution. +: **Type de métrique** : jauge + +`pipelines.scanner.total_regexes` +: **Description** : Le nombre d'expressions régulières conservées sur tous les Sensitive Data Scanners. +: **Type de métrique** : jauge + +## Pour aller plus loin {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /fr/observability_pipelines/search_syntax/logs/ +[2]: https://app.datadoghq.com/observability-pipelines +[3]: /fr/logs/guide/regex_log_parsing/ +[4]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/observability_pipeline +[5]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/data-sources/sensitive_data_scanner_standard_pattern +[6]: /fr/security/sensitive_data_scanner/scanning_rules/library_rules/ +[7]: /fr/security/sensitive_data_scanner/scanning_rules/library_rules/?search=AWS+Access+Key+ID+Scanner +[8]: /fr/security/sensitive_data_scanner/scanning_rules/library_rules/?search=US+Social+Security+Number+Scanner +[9]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/observability_pipeline#nested-schema-for-configprocessor_groupprocessorsensitive_data_scanner +[10]: /fr/api/latest/observability-pipelines/#create-a-new-pipeline +[11]: https://app.datadoghq.com/metric/explorer +[12]: /fr/metrics/distributions/#enabling-advanced-query-functionality +[13]: /fr/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#component-metrics +[14]: /fr/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#processor-buffer-metrics +[15]: /fr/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/ +[16]: https://app.datadoghq.com/dash/integration/32326/observability-pipelines-overview \ No newline at end of file diff --git a/hugo/content/fr/observability_pipelines/sources/azure_event_hubs.md b/hugo/content/fr/observability_pipelines/sources/azure_event_hubs.md new file mode 100644 index 00000000000..53eacc7408c --- /dev/null +++ b/hugo/content/fr/observability_pipelines/sources/azure_event_hubs.md @@ -0,0 +1,190 @@ +--- +description: Apprenez à envoyer des logs Azure Event Hubs vers Observability Pipelines + en utilisant la source Kafka. +disable_toc: false +title: Envoyez des logs Azure Event Hubs vers Observability Pipelines +--- +## Présentation {#overview} + +Ce document explique comment envoyer des logs Azure Event Hubs vers Observability Pipelines en utilisant la source Kafka. Les étapes de configuration incluent la configuration d'Azure Event Hubs pour la source Kafka : + +- [Créer un espace de noms Event Hubs](#create-an-azure-event-hubs-namespace) +- [Créer un Event Hub (topic Kafka)](#create-an-event-hub-kafka-topic) +- [Configurer la stratégie d'accès partagé](#configure-shared-access-policy) +- [Configurer les paramètres de diagnostic](#set-up-diagnostic-settings) +- [Configurer la connexion compatible Kafka pour l'Event Hub](#configure-kafka-compatible-connection-for-the-event-hub) + +Une fois Azure Event Hubs configuré, vous [configurez un pipeline avec la source Kafka](#set-up-a-pipeline-with-the-kafka-source) pour envoyer les logs Azure Event Hubs vers Observability Pipelines. + +## Configurez Azure Event Hubs pour la source Kafka {#set-up-azure-event-hubs-for-the-kafka-source} + +### Créez un espace de noms Azure Event Hubs {#create-an-azure-event-hubs-namespace} + +1. Dans le portail Azure, accédez à [Event Hubs](https://portal.azure.com/#browse/Microsoft.EventHub%2Fnamespaces). +1. Cliquez sur **Créer**. +1. Remplissez les **Détails du projet** (abonnement, groupe de ressources) et les **Détails de l'instance** (nom de l'espace de noms, région, sélectionnez le niveau Standard, Premium ou Dédié). +1. Assurez-vous que la région correspond à vos ressources Azure (par exemple, `westus`). +1. Cliquez sur **Vérifier + créer**. + +**Remarque** : L'endpoint Kafka est automatiquement activé pour les niveaux standard et supérieurs. + +### Créez un Event Hub (topic Kafka) {#create-an-event-hub-kafka-topic} + +1. Dans l'espace de noms que vous avez créé, sélectionnez **Event Hubs** et cliquez sur **+ Event Hub**. +1. Entrez un nom (par exemple, `datadog-topic`) et configurez les paramètres (par exemple, 4 partitions et une durée de rétention de 7 jours). +1. Cliquez sur **Vérifier + créer**. Cet Event Hub agit comme un topic Kafka. + +### Configurez la stratégie d'accès partagé {#configure-shared-access-policy} + +1. Dans l'Event Hub que vous avez créé, accédez à **Paramètres** > **Stratégies d'accès partagé**. +1. Cliquez sur **+ Ajouter**. +1. Entrez un nom de stratégie (par exemple, `DatadogKafkaPolicy`). +1. Cochez la case **Gérer**, ce qui devrait automatiquement cocher les cases **Envoyer** et **Écouter**. +1. Cliquez sur **Créer**. +1. La **Clé primaire** et la **Chaîne de connexion principale** sont nécessaires pour l'authentification Kafka lorsque vous configurez la source Kafka d'Observability Pipelines. + +### Configurez les paramètres de diagnostic {#set-up-diagnostic-settings} + +1. Configurez les ressources Azure (par exemple, des machines virtuelles, des services d'application) ou les logs d'activité au niveau de l'abonnement pour diffuser les logs vers l'Event Hub. +1. Pour les ressources : + 1. Accédez à la ressource, puis à **Surveillance** > **Paramètres de diagnostic**. + 1. Cliquez sur **+ Ajouter un paramètre de diagnostic**. + 1. Sélectionnez les catégories de logs souhaitées (par exemple, AuditLogs, SignInLogs pour Microsoft Entra ID). + 1. Dans **Détails de la destination** : + 1. Cochez la case **Diffuser vers un Event Hub**. + 1. Sélectionnez l'espace de noms et l'Event Hub (`datadog-topic`). + 1. Cliquez sur **Enregistrer**. +1. Pour les logs d'activité : + 1. Accédez à **Microsoft Entra ID** > **Surveillance** > **Journaux d'audit** > **Paramètres d'exportation des données**. + 1. Cochez la case **Diffuser vers l'Event Hub**. +1. Répétez l'opération pour chaque région. Les logs doivent être diffusés vers des Event Hubs situés dans la même région. + +### Configurez une connexion compatible Kafka pour l'Event Hub {#configure-kafka-compatible-connection-for-the-event-hub} + +Azure Event Hubs expose un endpoint Kafka à `NAMESPACE.servicebus.windows.net:9093`, qu'Observability Pipelines utilise comme source Kafka. + +#### Obtenez l'endpoint Kafka {#get-the-kafka-endpoint} + +1. Dans le portail Azure, accédez à votre espace de noms Event Hubs (par exemple, `myeventhubns`). +1. Sur la page **Vue d'ensemble**, sous la section **Essentials**, localisez le **Nom d'host** ou le **Nom de domaine complet (FQDN)**. Il se présente sous le format : `.servicebus.windows.net` (par exemple, `myeventhubns.servicebus.windows.net`). +1. Ajoutez le port Kafka `:9093` pour former la valeur des Bootstrap Servers : `.servicebus.windows.net:9093` + - Par exemple, si votre espace de noms est `myeventhubns`, le Bootstrap Servers est `myeventhubns.servicebus.windows.net:9093`. + - Vous aurez besoin de ces informations lors de la configuration de la source Kafka d'Observability Pipelines. + +#### Configurez l'authentification {#set-up-authentication} + +1. Azure Event Hubs utilise SASL_SSL avec le mécanisme PLAIN pour l'authentification Kafka. +1. La chaîne de connexion est formatée pour Observability Pipelines : + ``` + Username: $$ConnectionString + Password: Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey= + ``` + +## Mettez en place un pipeline avec la source Kafka {#set-up-a-pipeline-with-the-kafka-source} + +Sélectionnez votre plateforme. + +{{< tabs >}} +{{% tab "Kubernetes" %}} +1. Accédez à [Observability Pipelines](https://app.datadoghq.com/observability-pipelines). +1. Sélectionnez la source Kafka. + 1. Dans le champ {{< ui >}}Group ID{{< /ui >}}, spécifiez ou créez un groupe de consommateurs unique (par exemple, `datadog-consumer-group`). + 1. Dans le {{< ui >}}Topics{{< /ui >}} champ, saisissez `datadog-topic` ou le topic que vous avez configuré précédemment pour votre Event Hub. + 1. Activez le commutateur pour autoriser l'authentification SASL. + 1. Dans le menu déroulant {{< ui >}}Mechanism{{< /ui >}}, sélectionnez {{< ui >}}PLAIN{{< /ui >}}. + 1. Activez TLS. + 1. Configurez votre fichier `values.yaml` pour utiliser le certificat qui fonctionne dans le cadre de l'image de conteneur : + ``` + initContainers: + - name: copy-config + image: gcr.io/datadoghq/observability-pipelines-worker:latest + imagePullPolicy: IfNotPresent + command: ['/bin/sh', '-c', 'mkdir -p /config-volume/observability-pipelines-worker/config/ && cp /etc/ssl/certs/ca-certificates.crt /config-volume/observability-pipelines-worker/config/ca-certificates.crt'] + volumeMounts: + - name: config-volume + mountPath: /config-volume + extraVolumes: + - name: config-volume + emptyDir: {} + extraVolumeMounts: + - name: config-volume + mountPath: /config-volume + ``` + **Note**: When install the Worker with the install command you need to add: + ``` + --set env[0].name=DD_OP_DATA_DIR,env[0].value='/config-volume/observability-pipelines-worker/' + ``` + Dans le 1. In the {{< ui >}}Certificate path{{< /ui >}} champ, saisissez `/ca-certificates.crt` si vous avez utilisé l'exemple ci-dessus. Sinon, saisissez le nom de votre certificat. + {{< img src="observability_pipelines/sources/kafka_settings.png" alt="Les paramètres de la source Kafka avec des exemples de valeurs" style="width:45%;" >}} +1. Cliquez sur {{< ui >}}Next: Select Destination{{< /ui >}}. +1. Une fois vos destinations et processeurs configurés, cliquez sur {{< ui >}}Next: Install{{< /ui >}}. +1. Sélectionnez votre plateforme dans le menu déroulant {{< ui >}}Choose your installation platform{{< /ui >}}. +1. Saisissez les variables d'environnement pour votre source Kafka : + 1. Pour {{< ui >}}Kafka Bootstrap Servers{{< /ui >}}, saisissez `.servicebus.windows.net:9093` (par exemple, `myeventhubns.servicebus.windows.net:9093`). + 1. Pour {{< ui >}}Kafka SASL Username{{< /ui >}}, saisissez `$$$$ConnectionString`. **Remarque** : Vous devez avoir `$$$$` devant `ConnectionString` car `$$$$` finit par être `$$` lorsqu'il est transposé dans l'environnement. + 1. Pour {{< ui >}}Kafka SASL Password{{< /ui >}}, saisissez la chaîne de connexion complète. Par exemple, `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=`. + - Il s'agit de la **chaîne de connexion principale** dans les [stratégies d'accès partagé](#configure-shared-access-policy) de votre instance Event Hub. + 1. Saisissez votre phrase secrète TLS Kafka. + - Il s'agit de la **clé principale** dans les [stratégies d'accès partagé](#configure-shared-access-policy) de votre instance Event Hub. + {{< img src="observability_pipelines/sources/kafka_env_vars.png" alt="La page d'installation avec des exemples de valeurs pour les variables d'environnement Kafka" style="width:60%;" >}} +1. Saisissez les variables d'environnement pour vos destinations, le cas échéant. +1. Suivez le reste des instructions sur la page pour installer le Worker en fonction de votre plateforme. +{{% /tab %}} +{{% tab "Machine virtuelle (VM)" %}} + +1. Accédez à [Observability Pipelines](https://app.datadoghq.com/observability-pipelines). +1. Sélectionnez la source Kafka. + 1. Dans le champ {{< ui >}}Group ID{{< /ui >}}, spécifiez ou créez un groupe de consommateurs unique (par exemple, `datadog-consumer-group`). + 1. Saisissez `datadog-topic` dans le champ {{< ui >}}Topics{{< /ui >}}. + 1. Activez le commutateur pour autoriser l'authentification SASL. + 1. Dans le menu déroulant {{< ui >}}Mechanism{{< /ui >}}, sélectionnez {{< ui >}}PLAIN{{< /ui >}}. + 1. Activez TLS. Pour le certificat, copiez le certificat depuis son emplacement d'origine vers le répertoire de configuration de données par défaut d'Observability Pipelines : + 1. Comme l'Observability Pipelines Worker n'a pas encore été installé, exécutez cette commande pour créer le répertoire du certificat : + ``` + sudo mkdir -p /var/lib/observability-pipelines-worker/config + ``` + 1. Run this command to copy the certificate to the directory you created: + ``` + sudo cp /etc/ssl/certs/ca-certificates.crt /var/lib/observability-pipelines-worker/config/ + ``` + 1. In the {{< ui >}}Certificate path{{< /ui >}} champ, saisissez `/ca-certificates.crt`. + {{< img src="observability_pipelines/sources/kafka_settings_vm.png" alt="Les paramètres de la source Kafka avec des exemples de valeurs" style="width:45%;" >}} +1. Cliquez sur {{< ui >}}Next: Select Destination{{< /ui >}}. +1. Une fois vos destinations et processeurs configurés, cliquez sur {{< ui >}}Next: Install{{< /ui >}}. +1. Sélectionnez votre plateforme dans le menu déroulant {{< ui >}}Choose your installation platform{{< /ui >}}. +1. Saisissez les variables d'environnement pour votre source Kafka : + 1. Pour {{< ui >}}Kafka Bootstrap Servers{{< /ui >}}, saisissez `.servicebus.windows.net:9093` (par exemple, `myeventhubns.servicebus.windows.net:9093`). + 1. Pour {{< ui >}}Kafka SASL Username{{< /ui >}}, saisissez `\$\$ConnectionString`. **Remarque** : Vous devez échapper le `$` devant `ConnectionString`, sinon la variable d'environnement ne sera pas chargée. + 1. Pour {{< ui >}}Kafka SASL Password{{< /ui >}}, saisissez la chaîne de connexion complète entre guillemets (`"`). Par exemple, `"Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey="`. + - Il s'agit de la **chaîne de connexion principale** dans les [stratégies d'accès partagé](#configure-shared-access-policy) de votre instance Event Hub. + 1. Saisissez votre phrase secrète TLS Kafka. + - Il s'agit de la **clé principale** dans les [stratégies d'accès partagé](#configure-shared-access-policy) de votre instance Event Hub. + {{< img src="observability_pipelines/sources/kafka_env_vars_vm.png" alt="La page d'installation avec des exemples de valeurs pour les variables d'environnement Kafka" style="width:60%;" >}} + +{{% /tab %}} +{{< /tabs >}} + +## Dépannage {#troubleshooting} + +Si vous rencontrez des problèmes après l'installation du Worker, vérifiez votre fichier d'environnement Observability Pipelines (`/etc/default/observability-pipelines-worker`) pour vous assurer que les variables d'environnement sont correctement définies : + +- `DD_OP_SOURCE_KAFKA_SASL_USERNAME="$$ConnectionString"` +- `DD_OP_SOURCE_KAFKA_BOOTSTRAP_SERVERS=.servicebus.windows.net:9093` +- `DD_OP_SOURCE_KAFKA_SASL_PASSWORD=.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=>` +- `DD_OP_SOURCE_KAFKA_KEY_PASS=password` + +### Variable d'environnement manquante {#missing-environment-variable} + +Si vous voyez l'erreur `Missing environment variable DD_OP_SOURCE_KAFKA_SASL_PASSWORD` et que vous exécutez le Worker dans une VM, assurez-vous que la variable est entre guillemets (`"`) lorsque vous exécutez le script d'installation du Worker. Exemple : + +``` +DD_OP_SOURCE_KAFKA_SASL_PASSWORD=`"Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey="` +``` + +## Métriques de santé {#health-metrics} + +Pour les [métriques de composant][1] et les [métriques de tampon source][2] émises par toutes les sources, consultez la documentation [Pipelines Usage Metrics][3]. Puisque vous utilisez la source Kafka pour envoyer des logs d'Azure Event Hubs vers Observability Pipelines, utilisez le tag `component_type:kafka` pour filtrer les métriques pertinentes. + +[1]: /fr/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#component-metrics +[2]: /fr/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#source-buffer-metrics +[3]: /fr/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/ \ No newline at end of file diff --git a/hugo/content/fr/observability_pipelines/sources/fluent.md b/hugo/content/fr/observability_pipelines/sources/fluent.md new file mode 100644 index 00000000000..3306d92b3d0 --- /dev/null +++ b/hugo/content/fr/observability_pipelines/sources/fluent.md @@ -0,0 +1,73 @@ +--- +description: Apprenez à collecter des logs à partir d'un agent Fluentd ou Fluent Bit + en utilisant l'Observability Pipelines Worker. +disable_toc: false +products: +- icon: logs + name: Logs + url: /observability_pipelines/configuration/?tab=logs#pipeline-types +title: Sources Fluentd et Fluent Bit +--- +{{< product-availability >}} + +## Présentation {#overview} + +Utilisez la source Fluentd ou Fluent Bit d'Observability Pipelines pour recevoir des logs de votre agent Fluentd ou Fluent Bit. + +## Prérequis {#prerequisites} + +{{% observability_pipelines/prerequisites/fluent %}} + +## Configuration {#setup} + +
Pour la gestion des secrets : saisissez uniquement les identifiants de l'adresse Fluent et, le cas échéant, du mot de passe de la clé TLS. Ne saisissez pas les valeurs réelles.
+ +Configurez cette source lorsque vous [configurez un pipeline][1]. Vous pouvez configurer un pipeline dans le [UI][3], en utilisant l'[API][4] ou avec [Terraform][5]. Les instructions de cette section concernent la configuration de la source dans l'UI. + +Après avoir sélectionné la source Fluent dans l'UI du pipeline, saisissez l'identifiant de votre adresse Fluent. Si vous le laissez vide, le [default](#secret-defaults) est utilisé. + +{{% observability_pipelines/secrets_env_var_note %}} + +### Paramètres optionnels {#optional-settings} + +{{% observability_pipelines/tls_settings %}} + +{{% observability_pipelines/tls_settings_mtls %}} + +## Valeurs par défaut des secrets {#secret-defaults} + +{{% observability_pipelines/set_secrets_intro %}} + +{{< tabs >}} +{{% tab "Gestion des secrets" %}} + +- Identifiant de l'adresse Fluent : + - Référence l'adresse sur laquelle l'Observability Pipelines Worker écoute les messages de logs entrants. + - L'identifiant par défaut est `SOURCE_FLUENT_ADDRESS`. +- Identifiant de la phrase secrète TLS Fluent (lorsque TLS est activé) : + - L'identifiant par défaut est `SOURCE_FLUENT_KEY_PASS`. + +{{% /tab %}} + +{{% tab "Variables d'environnement" %}} + +{{% observability_pipelines/configure_existing_pipelines/source_env_vars/fluent %}} + +{{% /tab %}} +{{< /tabs >}} + +## Envoyer des logs à l'Observability Pipelines Worker via Fluent {#send-logs-to-the-observability-pipelines-worker-over-fluent} + +{{% observability_pipelines/log_source_configuration/fluent %}} + +## Métriques de santé {#health-metrics} + +Pour les [métriques de composant][6] et les [métriques de tampon de source][7] émises par toutes les sources, consultez la documentation sur les [métriques d'utilisation des pipelines][8]. Pour filtrer ou regrouper par métriques de source Fluent, utilisez le tag `component_type:fluent`. + +[1]: /fr/observability_pipelines/configuration/set_up_pipelines/ +[3]: https://app.datadoghq.com/observability-pipelines +[4]: /fr/api/latest/observability-pipelines/ +[5]: https://registry.terraform.io/providers/datadog/datadog/latest/docs/resources/observability_pipeline +[6]: /fr/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#component-metrics +[7]: /fr/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/#source-buffer-metrics +[8]: /fr/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics/ \ No newline at end of file diff --git a/hugo/content/fr/observability_pipelines/sources/socket.md b/hugo/content/fr/observability_pipelines/sources/socket.md new file mode 100644 index 00000000000..0ea5a62b163 --- /dev/null +++ b/hugo/content/fr/observability_pipelines/sources/socket.md @@ -0,0 +1,164 @@ +--- +description: Apprenez à collecter les logs envoyés via une connexion socket TCP ou + UDP à l'aide de l'Observability Pipelines Worker. +disable_toc: false +products: +- icon: logs + name: Logs + url: /observability_pipelines/configuration/?tab=logs#pipeline-types +title: Socket Source +--- +{{< product-availability >}} + +## Présentation {#overview} + +Utilisez le Socket Source d'Observability Pipelines pour envoyer des logs au Worker via une connexion socket (TCP ou UDP). + +## Prérequis {#prerequisites} + +{{% observability_pipelines/prerequisites/socket %}} + +## Configuration {#setup} + +
Pour la gestion des secrets : saisissez uniquement les identifiants de l'adresse du socket et, le cas échéant, la clé TLS. Ne saisissez pas les valeurs réelles.
+ +Configurez cette source lorsque vous [configurez un pipeline][1]. Vous pouvez configurer un pipeline dans le [UI][3], en utilisant l'[API][4] ou avec [Terraform][5]. Les instructions de cette section concernent la configuration de la source dans l'UI. + +**Remarque** : Le Worker ne peut recevoir des logs que via TCP ou UDP. Si votre application écrit sur un socket de domaine UNIX, consultez [sockets de domaine UNIX](#unix-domain-sockets) pour plus d'informations. + +Après avoir sélectionné le Socket Source dans le pipeline UI : + +1. Saisissez l'identifiant de votre adresse de socket. Si vous le laissez vide, le [default](#secret-defaults) est utilisé. +1. Dans le menu déroulant {{< ui >}}Mode{{< /ui >}}, sélectionnez le type de socket à utiliser. +1. Dans le menu déroulant {{< ui >}}Framing{{< /ui >}}, sélectionnez la manière de délimiter le flux d'événements. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MÉTHODE DE DÉLIMITATIONDESCRIPTION
newline_delimitedLes trames d'octets sont délimitées par un caractère de saut de ligne.
bytesLes trames d'octets sont transmises telles quelles selon les limites d'E/S sous-jacentes (par exemple, divisées entre les messages ou les segments de flux).
character_delimitedLes trames d'octets sont délimitées par un caractère choisi.
chunked_gelfLes trames d'octets sont des messages GELF segmentés.
octet_countingLes trames d'octets sont délimitées selon le format de comptage d'octets.
+ +{{% observability_pipelines/secrets_env_var_note %}} + +### Paramètres TLS optionnels {#optional-tls-settings} + +{{% observability_pipelines/tls_settings %}} + +{{% observability_pipelines/tls_settings_mtls %}} + +## UNIX domain sockets {#unix-domain-sockets} + +Le Socket Source prend uniquement en charge la réception de logs via TCP ou UDP. Si votre application écrit sur un UNIX domain socket, utilisez `socat` pour le relier à un socket TCP ou UDP afin d'envoyer les logs au Worker. + +### Standalone bridge {#standalone-bridge} + +Exécutez `socat` aux côtés de votre application pour transférer depuis le UNIX domain socket vers le Worker : + +``` +socat UNIX-RECV:/var/run/app.sock TCP: +``` + +Remplacez par l'adresse IP de l'hôte ou l'URL de l'équilibreur de charge associé à l'Observability Pipelines Worker. + +### Kubernetes sidecar {#kubernetes-sidecar} + +Dans Kubernetes, le Worker s'exécute généralement en tant que StatefulSet derrière un Service, il n'est donc pas accessible via `localhost`. Exécutez `socat` en tant que conteneur sidecar dans le même pod que votre application, et partagez un volume pour le fichier socket. Exemple : + +```yaml +volumes: + - name: app-socket + emptyDir: {} + +initContainers: + # Remove any stale socket file before the sidecar starts + - name: socket-cleanup + image: busybox:1.36 + command: ["sh", "-c", "rm -f /var/run/app/app.sock"] + volumeMounts: + - name: app-socket + mountPath: /var/run/app + +containers: + # Your application container + - name: app + # ... + volumeMounts: + - name: app-socket + mountPath: /var/run/app + + # socat sidecar: bridges the UNIX socket to the Worker's Service + - name: socat-opw-bridge + image: alpine/socat:1.8.0.0 + args: + - UNIX-RECV:/var/run/app/app.sock,fork + - TCP:-observability-pipelines-worker..svc.cluster.local:5000 + volumeMounts: + - name: app-socket + mountPath: /var/run/app + +# Monitor and adjust resources as necessary + resources: + requests: + cpu: 10m + memory: 16Mi + securityContext: + runAsNonRoot: true + runAsUser: 1000 + allowPrivilegeEscalation: false + readOnlyRootFilesystem: true +``` + +Pointez l'argument `TCP` vers l'endpoint du Service Kubernetes du Worker au lieu de `localhost`. Il n'est pas garanti que les pods StatefulSet du Worker s'exécutent sur chaque nœud, le pod du Worker pourrait donc ne pas être accessible à `localhost`. Ceci est particulièrement vrai si vous disposez de groupes de nœuds dédiés pour le Worker et vos charges de travail. + +## Valeurs par défaut des secrets {#secret-defaults} + +{{% observability_pipelines/set_secrets_intro %}} + +{{< tabs >}} +{{% tab "Gestion des secrets" %}} + +- Identifiant de l'adresse du socket: + - Indique l'adresse et le port sur lesquels l'Observability Pipelines Worker écoute les logs entrants. + - L'identifiant par défaut est `SOURCE_SOCKET_ADDRESS`. +- Identifiant de passphrase TLS du socket (lorsque TLS est activé) : + - L'identifiant par défaut est `SOURCE_SOCKET_KEY_PASS`. + +{{% /tab %}} + +{{% tab "Variables d'environnement" %}} + +{{% observability_pipelines/configure_existing_pipelines/source_env_vars/socket %}} + +{{% /tab %}} +{{< /tabs >}} + +[1]: /fr/observability_pipelines/configuration/set_up_pipelines/ +[3]: https://app.datadoghq.com/observability-pipelines +[4]: /fr/api/latest/observability-pipelines/ +[5]: https://registry.terraform.io/providers/datadog/datadog/latest/docs/resources/observability_pipeline \ No newline at end of file diff --git a/hugo/content/fr/observability_pipelines/sources/syslog.md b/hugo/content/fr/observability_pipelines/sources/syslog.md new file mode 100644 index 00000000000..864a42056bd --- /dev/null +++ b/hugo/content/fr/observability_pipelines/sources/syslog.md @@ -0,0 +1,87 @@ +--- +description: Apprenez à collecter les logs envoyés à rsyslog ou syslog-ng à l'aide + de l'Observability Pipelines Worker. +disable_toc: false +products: +- icon: logs + name: Logs + url: /observability_pipelines/configuration/?tab=logs#pipeline-types +title: Source Syslog +--- +{{< product-availability >}} + +## Présentation {#overview} + +Utilisez rsyslog ou syslog-ng d'Observability Pipelines pour recevoir les logs envoyés à rsyslog ou syslog-ng. + +Vous pouvez également [transférer des logs tiers vers syslog](#forward-third-party-logs-to-syslog) puis les envoyer à l'Observability Pipelines Worker. + +## Prérequis {#prerequisites} + +{{% observability_pipelines/prerequisites/syslog %}} + +## Configuration {#setup} + +
Pour la gestion des secrets : saisissez uniquement les identifiants de l'adresse syslog et, le cas échéant, de la passphrase de la clé TLS. Ne saisissez pas les valeurs réelles.
+ +Configurez cette source lorsque vous [configurez un pipeline][1]. Vous pouvez configurer un pipeline dans l'[UI][7], en utilisant l'[API][8] ou avec [Terraform][9]. Les instructions de cette section concernent la configuration de la source dans l'UI. + +Après avoir sélectionné la source Syslog dans l'interface utilisateur du pipeline : + +1. Saisissez l'identifiant de votre adresse syslog. Si vous le laissez vide, le [default](#secret-defaults) est utilisé. +1. Dans le menu déroulant {{< ui >}}Socket Type{{< /ui >}}, sélectionnez le protocole de communication que vous souhaitez utiliser : {{< ui >}}TCP{{< /ui >}} ou {{< ui >}}UDP{{< /ui >}}. + +{{% observability_pipelines/secrets_env_var_note %}} + +### Paramètres TLS optionnels {#optional-tls-settings} + +{{% observability_pipelines/tls_settings %}} + +{{% observability_pipelines/tls_settings_mtls %}} + +## Valeurs par défaut des secrets {#secret-defaults} + +{{% observability_pipelines/set_secrets_intro %}} + +{{< tabs >}} +{{% tab "Gestion des secrets" %}} + +- Identifiant de l'adresse rsyslog ou syslog-ng : + - Référence l'adresse de liaison, telle que `0.0.0.0:9997`, sur laquelle l'Observability Pipelines Worker écoute pour recevoir les logs du Syslog forwarder. + - L'identifiant par défaut est `SOURCE_SYSLOG_ADDRESS`. +- Identifiant de la passphrase TLS rsyslog ou syslog-ng (lorsque TLS est activé) : + - L'identifiant par défaut est `SOURCE_SYSLOG_KEY_PASS`. + +{{% /tab %}} + +{{% tab "Variables d'environnement" %}} + +{{% observability_pipelines/configure_existing_pipelines/source_env_vars/syslog %}} + +{{% /tab %}} +{{< /tabs >}} + +## Envoyez des logs à l'Observability Pipelines Worker via syslog {#send-logs-to-the-observability-pipelines-worker-over-syslog} + +{{% observability_pipelines/log_source_configuration/syslog %}} + +## Transférez des logs tiers à l'Observability Pipelines Worker {#forward-third-party-logs-to-the-observability-pipelines-worker} + +Syslog est un protocole de journalisation largement utilisé pour envoyer des logs réseau à un serveur central. De nombreux périphériques réseau prennent en charge la sortie syslog, vous pouvez donc transférer des logs tiers vers la source syslog d'Observability Pipelines pour traitement et routage. Voici des exemples de ces services tiers : + +### Fortinet {#fortinet} +- [Configurez le transfert de logs][2] +- [Configuration des paramètres syslog][3] + +### Palo Alto Networks {#palo-alto-networks} +- [Configurez le transfert de logs][4] +- [Transférez les logs de trafic vers un serveur syslog][5] + +[1]: /fr/observability_pipelines/configuration/set_up_pipelines/ +[2]: https://help.fortinet.com/fa/faz50hlp/56/5-6-1/FMG-FAZ/2400_System_Settings/1600_Log%20Forwarding/0400_Configuring.htm +[3]: https://help.fortinet.com/fadc/4-5-1/olh/Content/FortiADC/handbook/log_remote.htm +[4]: https://docs.paloaltonetworks.com/pan-os/10-1/pan-os-admin/monitoring/configure-log-forwarding +[5]: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClRxCAK +[7]: https://app.datadoghq.com/observability-pipelines +[8]: /fr/api/latest/observability-pipelines/ +[9]: https://registry.terraform.io/providers/datadog/datadog/latest/docs/resources/observability_pipeline \ No newline at end of file diff --git a/hugo/content/fr/opentelemetry/mapping/service_entry_spans.md b/hugo/content/fr/opentelemetry/mapping/service_entry_spans.md new file mode 100644 index 00000000000..c8e6b3db16b --- /dev/null +++ b/hugo/content/fr/opentelemetry/mapping/service_entry_spans.md @@ -0,0 +1,76 @@ +--- +aliases: +- /fr/opentelemetry/guide/service_entry_spans_mapping/ +- /fr/opentelemetry/schema_semantics/service_entry_spans/ +further_reading: +- link: /opentelemetry/integrations/trace_metrics + tag: Documentation + text: Métriques de trace OpenTelemetry +title: Mappage des conventions sémantiques OpenTelemetry vers les spans d'entrée de + service +--- +## Présentation {#overview} +Datadog utilise les [spans d'entrée de service][1] dans toute la plateforme pour des fonctionnalités comme les [métriques de trace][2] et l'[APM Trace Explorer][3]. Cette convention est propre à Datadog, mais peut être mappée à partir de l'attribut [`SpanKind`][4] dans OpenTelemetry en suivant le guide d'activation ci-dessous. + +## Prérequis {#requirements} + +- OTel Collector Contrib v0.100.0 ou version ultérieure +- Datadog Agent v7.53.0 ou version ultérieure + +## Configuration {#setup} + +Activez l'option de configuration en fonction de votre chemin d'ingestion : + +{{< tabs >}} +{{% tab "OTel Collector et Datadog Exporter" %}} + +La nouvelle logique d'identification des spans d'entrée de service peut être activée en définissant l'option de configuration `traces::compute_top_level_by_span_kind` sur true dans le [Datadog exporter][2] et le [Datadog connector][1]. Cette option de configuration doit être activée à la fois dans l'exporter et dans le connector si les deux composants sont utilisés. + +[1]: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/v0.100.0/connector/datadogconnector/examples/config.yaml#L48-L53 +[2]: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/v0.100.0/exporter/datadogexporter/examples/collector.yaml#L365-L370 +{{% /tab %}} +{{% tab "Pipeline d'ingestion OTLP dans le Datadog Agent" %}} + +La nouvelle logique d'identification des spans d'entrée de service peut être activée en ajoutant `"enable_otlp_compute_top_level_by_span_kind"` à [apm_config.features][1] dans la configuration du Datadog Agent. + +[1]: https://github.com/DataDog/datadog-agent/blob/main/pkg/config/example/datadog-agent_linux.yaml.example +{{% /tab %}} +{{< /tabs >}} + +## Conventions prises en charge {#supported-conventions} + +Les [métriques de trace][2] sont générées pour les spans d'entrée de service et les spans mesurés. Ces conventions de span sont propres à Datadog, les spans OpenTelemetry sont donc identifiés avec le mappage suivant : +| Convention OpenTelemetry | Convention Datadog | +| --- | --- | +| Span racine | Span d'entrée de service | +| Span serveur (`span.kind: server`) | Span d'entrée de service | +| Span consommateur (`span.kind: consumer`) | Span d'entrée de service | +| Span client (`span.kind: client`) | Span mesuré | +| Span producteur (`span.kind: producer`) | Span mesuré | +| Span interne (`span.kind: internal`) | Aucune métrique de trace générée | + +## Migration {#migration} + +Cette nouvelle logique d'identification des spans d'entrée de service peut augmenter le nombre de spans générant des métriques de trace, ce qui peut affecter les monitors existants basés sur ces métriques de trace. Les utilisateurs qui n'ont que des spans internes verront une diminution des métriques de trace. + +Si vous avez des monitors existants basés sur des métriques de trace, vous pouvez les mettre à jour après la mise à niveau, car ce changement introduit plus de cohérence dans les métriques de trace. Si vous n'avez que des spans internes, mettez à jour votre instrumentation conformément au tableau ci-dessus pour recevoir des métriques de trace et des spans d'entrée de service. + +[`SpanKind`][4] est généralement défini lors de la création d'un span, mais peut également être mis à jour en utilisant le [transform processor][5] dans l'OpenTelemetry Collector pour contrôler le mappage ci-dessus. Par exemple, si des métriques de trace sont souhaitées pour un span interne, la configuration suivante transforme un span interne avec `http.path: "/health"` en un span client : + +```yaml + transform: + trace_statements: + - context: span + statements: + - set(kind.string, "Client") where kind.string == "Internal" and attributes["http.path"] == "/health" +``` + +## Pour aller plus loin {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://docs.datadoghq.com/fr/glossary/#service-entry-span +[2]: https://docs.datadoghq.com/fr/opentelemetry/integrations/trace_metrics/ +[3]: https://docs.datadoghq.com/fr/tracing/trace_explorer +[4]: https://opentelemetry.io/docs/specs/otel/trace/api/#spankind +[5]: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/transformprocessor/README.md \ No newline at end of file diff --git a/hugo/content/fr/opentelemetry/setup/ddot_collector/install/kubernetes_standalone.md b/hugo/content/fr/opentelemetry/setup/ddot_collector/install/kubernetes_standalone.md new file mode 100644 index 00000000000..ec78add76a5 --- /dev/null +++ b/hugo/content/fr/opentelemetry/setup/ddot_collector/install/kubernetes_standalone.md @@ -0,0 +1,916 @@ +--- +description: Déployez la distribution Datadog autonome du collecteur OpenTelemetry + (DDOT) sur Kubernetes en utilisant l'opérateur OpenTelemetry ou le chart Helm. +further_reading: +- link: /opentelemetry/setup/ddot_collector/custom_components + tag: Documentation + text: Utilisez des composants OpenTelemetry personnalisés dans DDOT +title: Installez le collecteur DDOT autonome en tant que DaemonSet Kubernetes +--- +{{< callout header="faux" btn_hidden="true" >}} +L'installation du collecteur DDOT autonome avec les outils OpenTelemetry est en préversion. +{{< /callout >}} + +## Présentation {#overview} + +Suivez ce guide pour déployer la Datadog Distribution du collecteur OpenTelemetry (DDOT) en utilisant l'opérateur OpenTelemetry ou le Helm chart. + +
+ Besoin de composants OpenTelemetry supplémentaires? Si vous avez besoin de composants au-delà de ceux inclus dans le paquet par défaut, suivez Utilisez des composants OpenTelemetry personnalisés pour étendre les capacités de DDOT. Pour obtenir une liste des composants inclus par défaut, consultez Composants du collecteur OpenTelemetry. +
+ +## Prérequis {#requirements} + +Pour compléter ce guide, vous avez besoin des éléments suivants : + +**Compte Datadog** : +1. [Créez un compte Datadog][1] si vous n'en avez pas. +1. Trouvez ou créez votre [clé d'API Datadog][2]. + +**Logiciels** : +Installez et configurez les éléments suivants sur votre machine : + +- Un cluster Kubernetes (v1.29+) +- [Helm (v4+)][54] +- [kubectl][5] + +**Réseau** : +| Protocole | Transport | Port | +|:---------|:----------|-----:| +| gRPC | TCP | 4317 | +| HTTP | TCP | 4318 | + +## Installez la distribution Datadog du collecteur OpenTelemetry {#install-the-datadog-distribution-of-the-opentelemetry-collector} + +### Sélectionnez la méthode d'installation {#select-installation-method} + +Choisissez l'une des méthodes d'installation suivantes : + +- [Opérateur OpenTelemetry][55] : une approche [native Kubernetes][56] qui réconcilie et maintient automatiquement votre configuration du collecteur OTel. +- [Helm chart][4] : un moyen simple de déployer des collecteurs OTel. + +{{< tabs >}} +{{% tab "Opérateur" %}} +### Installez l'opérateur OpenTelemetry {#install-the-opentelemetry-operator} + +Vous pouvez installer l'opérateur OpenTelemetry dans votre cluster en utilisant le [OpenTelemetry Operator Helm chart][1] : + +```shell +helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts +helm repo update +helm install opentelemetry-operator open-telemetry/opentelemetry-operator \ + --set "manager.createRbacPermissions=true" \ + --set "manager.collectorImage.repository=datadog/ddot-collector" \ + --set "manager.collectorImage.tag={{< version key="agent_version" >}}" +``` + +{{% site-region region="gov,gov2" %}} +
+Pour FED, définissez le tag sur {{< version key="agent_version" >}}-fips pour utiliser l'image DDOT conforme FIPS. +Consultez la conformité FIPS. +
+{{% /site-region %}} + +[1]: https://github.com/open-telemetry/opentelemetry-helm-charts/blob/main/charts/opentelemetry-operator/README.md +{{% /tab %}} +{{% tab "Helm" %}} +### Ajoutez le dépôt Helm OpenTelemetry {#add-the-opentelemetry-helm-repository} + +Pour ajouter le dépôt OpenTelemetry à vos dépôts Helm : + +```shell +helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts +helm repo update +``` + +{{% /tab %}} +{{< /tabs >}} + +### Configurez la clé d'API Datadog {#set-up-datadog-api-key} + +1. Obtenez la [clé d'API][2] Datadog. +1. Confirmez que le **SITE DATADOG** sélectionné à droite (Valeur actuelle : **{{< region-param key="dd_site_name" >}}**) correspond à votre [site Datadog][52]. +1. Stockez la clé d'API en tant que secret Kubernetes : + ```shell + kubectl create secret generic datadog-secret \ + --from-literal api-key= \ + --from-literal site={{< region-param key="dd_site" >}} + ``` + Replace `` with your actual Datadog API key. + +### Configure the OTel Collector + +{{< tabs >}} +{{% tab "Opérateur" %}} +Après avoir déployé l'opérateur OTel, créez la ressource `OpenTelemetryCollector` qui déclenche le déploiement du collecteur. + +1. Utilisez le fichier `node-collector.yaml` pour spécifier votre configuration de daemonset `OpenTelemetryCollector` : + +{{< code-block lang="yaml" filename="node-collector.yaml" collapsible="true" >}} +apiVersion: opentelemetry.io/v1beta1 +kind: OpenTelemetryCollector +metadata: + name: node-collector +spec: + # Deploy 1 instance per node, that will collect telemetry from that node's pods + mode: daemonset + command: ['otel-agent', 'run'] # Will no longer be necessary from 7.82.0 onwards + config: + exporters: + datadog: + api: + key: ${env:DD_API_KEY} + site: ${env:DD_SITE} + sending_queue: + batch: + flush_timeout: 10s + service: + telemetry: + resource: + k8s.cluster.name: ${env:K8S_CLUSTER_NAME} + env: + - name: DD_API_KEY + valueFrom: + secretKeyRef: + key: api-key + name: datadog-apikey + - name: DD_SITE + valueFrom: + secretKeyRef: + key: site + name: datadog-apikey + - name: DD_OTELCOLLECTOR_CONVERTER_FEATURES + value: datadog,pprof,zpages,prometheus,infraattributes + - name: K8S_CLUSTER_NAME + value: + # vvv Will no longer be necessary from 7.83.0 onwards vvv + - name: DD_OTEL_STANDALONE + value: 'true' + # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + # vvv Will no longer be necessary from 7.82.0 onwards vvv + - name: DD_OTELCOLLECTOR_ENABLED + value: 'true' + # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +{{< /code-block >}} + +Remplacez `` par un nom pour votre cluster. + +2. Ajoutez un récepteur OTLP et l'exportateur Datadog pour tous les signaux souhaités : Publiez les ports OTLP sur le nœud avec `hostPort` afin que les pods d'application puissent atteindre l'instance du Collector s'exécutant sur le même nœud : + +{{< code-block lang="yaml" filename="node-collector.yaml" collapsible="true" >}} +# [...] +spec: + # [...] + # Publish the OTLP ports on the node's network interface + ports: + - name: otlp-grpc + port: 4317 + protocol: TCP + hostPort: 4317 + - name: otlp-http + port: 4318 + protocol: TCP + hostPort: 4318 + config: + receivers: + otlp: + protocols: + grpc: + endpoint: 0.0.0.0:4317 + http: + endpoint: 0.0.0.0:4318 + # [...] + service: + # [...] + pipelines: + logs: + receivers: ['otlp'] + exporters: ['datadog'] + metrics: + receivers: ['otlp'] + exporters: ['datadog'] + traces: + receivers: ['otlp'] + exporters: ['datadog'] +{{< /code-block >}} + +3. (Facultatif) Activez des fonctionnalités supplémentaires : + +
L'activation de ces fonctionnalités peut entraîner des frais supplémentaires. Consultez la page de tarification et parlez à votre Customer Success Manager avant de continuer.
+ +{{< code-block lang="yaml" filename="node-collector.yaml" collapsible="true" >}} +spec: + config: + receivers: + host_metrics: + collection_interval: 15s + scrapers: + cpu: {} + load: {} + memory: {} + network: {} + disk: {} + kubelet_stats: + auth_type: serviceAccount + collection_interval: 15s + endpoint: ${env:K8S_NODE_NAME}:10250 + node: ${env:K8S_NODE_NAME} + metric_groups: + - pod + - container + - volume + processors: + infraattributes: + cardinality: 2 + resource/add-cluster-name: + attributes: + - key: k8s.cluster.name + value: ${env:K8S_CLUSTER_NAME} + action: upsert + connectors: + datadog/connector: + traces: + compute_top_level_by_span_kind: true + peer_tags_aggregation: true + compute_stats_by_span_kind: true + extensions: + health_check: + endpoint: "${env:K8S_POD_IP}:13133" + # [...] + service: + # [...] + extensions: ['health_check'] + pipelines: + logs: + # [...] + processors: ['resource/add-cluster-name', 'infraattributes'] + metrics: + receivers: ['host_metrics', 'otlp', 'kubelet_stats', 'datadog/connector'] + processors: ['resource/add-cluster-name', 'infraattributes'] + # [...] + traces: + # [...] + processors: ['resource/add-cluster-name', 'infraattributes'] + exporters: ['datadog', 'datadog/connector'] + env: + # [...] + - name: K8S_POD_IP + valueFrom: + fieldRef: + apiVersion: v1 + fieldPath: status.podIP + # K8S_NODE_NAME is added automatically by the operator +{{< /code-block >}} + +4. (Facultatif) Collectez les logs des conteneurs à partir du système de fichiers du nœud : + +
L'activation de la collecte des logs peut entraîner des frais supplémentaires. Consultez la page de tarification et parlez à votre Customer Success Manager avant de continuer.
+ +Le récepteur `filelog` lit les logs des conteneurs à partir du nœud. Comme l'Opérateur ne monte pas automatiquement les chemins des hosts, ajoutez les répertoires de logs en tant que volumes en lecture seule : + +{{< code-block lang="yaml" filename="node-collector.yaml" collapsible="true" >}} +spec: + config: + receivers: + filelog: + include: + - /var/log/pods/*/*/*.log + # Exclude the Collector's own logs to avoid a feedback loop + exclude: + - /var/log/pods/*_node-collector-collector-*_*/otc-container/*.log + start_at: end + include_file_path: true + include_file_name: false + retry_on_failure: + enabled: true + operators: + - id: container-parser + type: container + max_log_size: 102400 + # [...] + service: + # [...] + pipelines: + logs: + receivers: ['otlp', 'filelog'] + # [...] + # Mount the node's log directories into the Collector pod (read-only) + volumes: + - name: varlogpods + hostPath: + path: /var/log/pods + - name: varlibdockercontainers + hostPath: + path: /var/lib/docker/containers + volumeMounts: + - name: varlogpods + mountPath: /var/log/pods + readOnly: true + - name: varlibdockercontainers + mountPath: /var/lib/docker/containers + readOnly: true +{{< /code-block >}} + +{{% collapse-content title="Fichier node-collector.yaml terminé" level="p" %}} +Votre fichier `node-collector.yaml` devrait ressembler à ceci : +{{< code-block lang="yaml" filename="node-collector.yaml" collapsible="false" >}} +apiVersion: opentelemetry.io/v1beta1 +kind: OpenTelemetryCollector +metadata: + name: node-collector +spec: + # Deploy 1 instance per node, that will collect telemetry from that node's pods + mode: daemonset + command: ['otel-agent', 'run'] # Will no longer be necessary from 7.82.0 onwards + # Publish the OTLP ports on the node's network interface + ports: + - name: otlp-grpc + port: 4317 + protocol: TCP + hostPort: 4317 + - name: otlp-http + port: 4318 + protocol: TCP + hostPort: 4318 + config: + receivers: + otlp: + protocols: + grpc: + endpoint: 0.0.0.0:4317 + http: + endpoint: 0.0.0.0:4318 + host_metrics: + collection_interval: 15s + scrapers: + cpu: {} + load: {} + memory: {} + network: {} + disk: {} + kubelet_stats: + auth_type: serviceAccount + collection_interval: 15s + endpoint: ${env:K8S_NODE_NAME}:10250 + node: ${env:K8S_NODE_NAME} + metric_groups: + - pod + - container + - volume + filelog: + include: + - /var/log/pods/*/*/*.log + exclude: + - /var/log/pods/*_node-collector-collector-*_*/otc-container/*.log + start_at: end + include_file_path: true + include_file_name: false + retry_on_failure: + enabled: true + operators: + - id: container-parser + type: container + max_log_size: 102400 + processors: + infraattributes: + cardinality: 2 + resource/add-cluster-name: + attributes: + - key: k8s.cluster.name + value: ${env:K8S_CLUSTER_NAME} + action: upsert + connectors: + datadog/connector: + traces: + compute_top_level_by_span_kind: true + peer_tags_aggregation: true + compute_stats_by_span_kind: true + exporters: + datadog: + api: + key: ${env:DD_API_KEY} + site: ${env:DD_SITE} + sending_queue: + batch: + flush_timeout: 10s + extensions: + health_check: + endpoint: "${env:K8S_POD_IP}:13133" + service: + telemetry: + resource: + k8s.cluster.name: ${env:K8S_CLUSTER_NAME} + extensions: ['health_check'] + pipelines: + logs: + receivers: ['otlp', 'filelog'] + processors: ['resource/add-cluster-name', 'infraattributes'] + exporters: ['datadog'] + metrics: + receivers: ['host_metrics', 'otlp', 'kubelet_stats', 'datadog/connector'] + processors: ['resource/add-cluster-name', 'infraattributes'] + exporters: ['datadog'] + traces: + receivers: ['otlp'] + processors: ['resource/add-cluster-name', 'infraattributes'] + exporters: ['datadog', 'datadog/connector'] + env: + - name: DD_API_KEY + valueFrom: + secretKeyRef: + key: api-key + name: datadog-apikey + - name: DD_SITE + valueFrom: + secretKeyRef: + key: site + name: datadog-apikey + - name: DD_OTELCOLLECTOR_CONVERTER_FEATURES + value: datadog,pprof,zpages,prometheus,infraattributes + - name: K8S_CLUSTER_NAME + value: + - name: K8S_POD_IP + valueFrom: + fieldRef: + apiVersion: v1 + fieldPath: status.podIP + # K8S_NODE_NAME is added automatically by the operator + # vvv Will no longer be necessary from 7.83.0 onwards vvv + - name: DD_OTEL_STANDALONE + value: 'true' + # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + # vvv Will no longer be necessary from 7.82.0 onwards vvv + - name: DD_OTELCOLLECTOR_ENABLED + value: 'true' + # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + # Mount the node's log directories for the filelog receiver (read-only) + volumes: + - name: varlogpods + hostPath: + path: /var/log/pods + - name: varlibdockercontainers + hostPath: + path: /var/lib/docker/containers + volumeMounts: + - name: varlogpods + mountPath: /var/log/pods + readOnly: true + - name: varlibdockercontainers + mountPath: /var/lib/docker/containers + readOnly: true +{{< /code-block >}} + +Remplacez `` par un nom pour votre cluster. + +{{% /collapse-content %}} + +{{% /tab %}} +{{% tab "Helm" %}} +Utilisez un fichier YAML pour spécifier les paramètres du chart Helm pour le [Collector chart][1]. + +1. Créez un fichier `node-collector-values.yaml` vide : + +```shell +touch node-collector-values.yaml +``` + +
Les paramètres non spécifiés utilisent les valeurs par défaut de values.yaml.
+ +2. Choisissez le mode daemonset et utilisez DDOT comme collector : + +{{< code-block lang="yaml" filename="node-collector-values.yaml" collapsible="true" >}} +mode: daemonset +image: + repository: datadog/ddot-collector + tag: {{< version key="agent_version" >}} +ports: + jaeger-compact: + enabled: false + jaeger-grpc: + enabled: false + jaeger-thrift: + enabled: false + zipkin: + enabled: false +# Can be removed from 7.82.0 onwards +command: + name: opt/datadog-agent/embedded/bin/otel-agent +{{< /code-block >}} + +{{% site-region region="gov,gov2" %}} +
Pour FED, définissez tag: {{< version key="agent_version" >}}-fips pour utiliser l'image DDOT conforme FIPS. Consultez la conformité FIPS.
+{{% /site-region %}} + +
Le Helm chart du Collector publie les ports OTLP sur chaque nœud par défaut (hostPort: 4317 pour gRPC et hostPort: 4318 pour HTTP), afin que les pods d'application puissent atteindre l'instance du Collector s'exécutant sur le même nœud. Consultez Configurer l'application.
+ +3. Configurez l'exportateur Datadog et le secret de la clé d'API : + +{{< code-block lang="yaml" filename="node-collector-values.yaml" collapsible="true" >}} +config: + exporters: + datadog: + api: + key: ${env:DD_API_KEY} + site: ${env:DD_SITE} + sending_queue: + batch: + flush_timeout: 10s +extraEnvs: + - name: DD_API_KEY + valueFrom: + secretKeyRef: + key: api-key + name: datadog-apikey + - name: DD_SITE + valueFrom: + secretKeyRef: + key: site + name: datadog-apikey + - name: DD_OTELCOLLECTOR_CONVERTER_FEATURES + value: datadog,pprof,zpages,prometheus,infraattributes + - name: K8S_CLUSTER_NAME + value: + # vvv Will no longer be necessary from 7.83.0 onwards vvv + - name: DD_OTEL_STANDALONE + value: 'true' + # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + # vvv Will no longer be necessary from 7.82.0 onwards vvv + - name: DD_OTELCOLLECTOR_ENABLED + value: 'true' + # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +{{< /code-block >}} + +Remplacez `` par un nom pour votre cluster. + +4. Activez les préréglages : + +{{< code-block lang="yaml" filename="node-collector-values.yaml" collapsible="true" >}} +presets: + hostMetrics: + enabled: true + kubeletMetrics: + enabled: true + logsCollection: + enabled: true + includeCollectorLogs: false +{{< /code-block >}} + +5. Définissez des pipelines pour les signaux souhaités, avec un récepteur OTLP : + +{{< code-block lang="yaml" filename="node-collector-values.yaml" collapsible="true" >}} +config: + # [...] + receivers: + otlp: + protocols: + grpc: + endpoint: 0.0.0.0:4317 + http: + endpoint: 0.0.0.0:4318 + service: + pipelines: + logs: + receivers: ['otlp'] + exporters: ['datadog'] + metrics: + receivers: ['otlp'] + exporters: ['datadog'] + traces: + receivers: ['otlp'] + exporters: ['datadog'] + telemetry: + resource: + k8s.cluster.name: ${env:K8S_CLUSTER_NAME} +{{< /code-block >}} + +6. (Facultatif) Activez des fonctionnalités Datadog supplémentaires : + +
L'activation de ces fonctionnalités peut entraîner des frais supplémentaires. Consultez la page de tarification et parlez à votre Customer Success Manager avant de continuer.
+ +{{< code-block lang="yaml" filename="node-collector-values.yaml" collapsible="true" >}} +config: + # [...] + processors: + infraattributes: + cardinality: 2 + resource/add-cluster-name: + attributes: + - key: k8s.cluster.name + value: ${env:K8S_CLUSTER_NAME} + action: upsert + connectors: + datadog/connector: + traces: + compute_top_level_by_span_kind: true + peer_tags_aggregation: true + compute_stats_by_span_kind: true + service: + pipelines: + logs: + # [...] + processors: ['resource/add-cluster-name', 'infraattributes'] + metrics: + receivers: ['otlp', 'datadog/connector'] + processors: ['resource/add-cluster-name', 'infraattributes'] + # [...] + traces: + # [...] + processors: ['resource/add-cluster-name', 'infraattributes'] + exporters: ['datadog', 'datadog/connector'] +{{< /code-block >}} + +{{% collapse-content title="Fichier node-collector-values.yaml complété" level="p" %}} +Votre fichier `node-collector-values.yaml` devrait ressembler à ceci : +{{< code-block lang="yaml" filename="node-collector-values.yaml" collapsible="false" >}} +mode: daemonset +# vvv To be removed from 7.82.0 onwards vvv +command: + name: opt/datadog-agent/embedded/bin/otel-agent +# ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +image: + repository: datadog/ddot-collector + tag: {{< version key="agent_version" >}} +presets: + hostMetrics: # Add an hostmetrics receiver to the metrics pipeline + enabled: true + kubeletMetrics: # Add a kubeletstats receiver to the metrics pipeline + enabled: true + logsCollection: # Add a filelog receiver to the logs pipeline + enabled: true + includeCollectorLogs: false +config: + connectors: + datadog/connector: + traces: + compute_top_level_by_span_kind: true + peer_tags_aggregation: true + compute_stats_by_span_kind: true + exporters: + datadog: + api: + key: ${env:DD_API_KEY} + site: ${env:DD_SITE} + sending_queue: + batch: + flush_timeout: 10s + processors: + infraattributes: + cardinality: 2 + resource/add-cluster-name: + attributes: + - key: k8s.cluster.name + value: ${env:K8S_CLUSTER_NAME} + action: upsert + receivers: + otlp: + protocols: + grpc: + endpoint: 0.0.0.0:4317 + http: + endpoint: 0.0.0.0:4318 + service: + extensions: + - health_check + pipelines: + logs: + receivers: + - otlp + processors: + - resource/add-cluster-name + - infraattributes + exporters: + - datadog + metrics: + receivers: + - otlp + - datadog/connector + processors: + - resource/add-cluster-name + - infraattributes + exporters: + - datadog + traces: + receivers: + - otlp + processors: + - resource/add-cluster-name + - infraattributes + exporters: + - datadog + - datadog/connector + telemetry: + resource: + k8s.cluster.name: ${env:K8S_CLUSTER_NAME} +extraEnvs: + - name: DD_API_KEY + valueFrom: + secretKeyRef: + key: api-key + name: datadog-apikey + - name: DD_SITE + valueFrom: + secretKeyRef: + key: site + name: datadog-apikey + - name: DD_OTELCOLLECTOR_CONVERTER_FEATURES + value: datadog,pprof,zpages,prometheus,infraattributes + - name: K8S_CLUSTER_NAME + value: + # vvv Will no longer be necessary from 7.83.0 onwards vvv + - name: DD_OTEL_STANDALONE + value: 'true' + # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + # vvv Will no longer be necessary from 7.82.0 onwards vvv + - name: DD_OTELCOLLECTOR_ENABLED + value: 'true' + # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +ports: + jaeger-compact: + enabled: false + jaeger-grpc: + enabled: false + jaeger-thrift: + enabled: false + zipkin: + enabled: false +{{< /code-block >}} + +{{% /collapse-content %}} + +[1]: https://github.com/open-telemetry/opentelemetry-helm-charts/blob/main/charts/opentelemetry-collector/README.md +[2]: /fr/getting_started/site/ +[3]: /fr/containers/guide/changing_container_registry/ +{{% /tab %}} +{{< /tabs >}} + +### Déployez le Collector {#deploy-the-collector} + +{{< tabs >}} +{{% tab "Opérateur" %}} +Appliquez le fichier `node-collector.yaml` pour créer la ressource `OpenTelemetryCollector`. Le Datadog Operator déploie le Collector en tant que DaemonSet, en exécutant une instance par nœud : + +```shell +kubectl apply -f node-collector.yaml +``` +{{% /tab %}} +{{% tab "Helm" %}} +Installez le Helm chart OpenTelemetry Collector avec votre fichier de valeurs : + +```shell +helm install node-collector open-telemetry/opentelemetry-collector -f node-collector-values.yaml +``` + +Pour appliquer des modifications ultérieures, exécutez `helm upgrade node-collector open-telemetry/opentelemetry-collector -f node-collector-values.yaml`. +{{% /tab %}} +{{< /tabs >}} + +## Installez le Datadog Agent principal aux côtés de DDOT {#install-the-core-datadog-agent-alongside-ddot} + +Si vous souhaitez exécuter le Datadog Agent principal sur les mêmes nœuds que le Collector DDOT autonome — par exemple, pour collecter des métriques d'infrastructure, l'APM ou des logs via l'Agent principal pendant que DDOT gère l'ingestion OTLP — vous pouvez l'installer séparément en utilisant le [Datadog Operator][57]. + +Par défaut, le Datadog Operator Helm chart surveille DatadogAgent les ressources uniquement dans l'espace de nommage où le Datadog Operator est installé (watchNamespaces: []). Si la DatadogAgent ressource se trouve dans un espace de nommage différent de celui du Datadog Operator, par exemple pour la garder séparée du espace de nommage de la OpenTelemetryCollector ressource, définissez watchNamespaces pour inclure l'espace de nommage où la DatadogAgent la ressource est créée : +
helm upgrade datadog-operator datadog/datadog-operator \
+  -n <OPERATOR_NAMESPACE> \
+  --reuse-values \
+  --set 'watchNamespaces[0]=<DATADOG_AGENT_NAMESPACE>'
+
+Si le Datadog Operator ne surveille pas l'espace de nommage où la DatadogAgent ressource est créée, la ressource échoue silencieusement à se réconcilier, sans erreur, sans événement Kubernetes et sans mise à jour de statut pour indiquer le problème. + +## Envoyez votre télémétrie à Datadog {#send-your-telemetry-to-datadog} + +Pour envoyer vos données de télémétrie à Datadog : + +1. [Instrumentez votre application](#instrument-the-application) +2. [Configurez l'application](#configure-the-application) +3. [Corrélez les données d'observabilité](#correlate-observability-data) +4. [Exécutez votre application](#run-the-application) + +### Instrumentez l'application {#instrument-the-application} + +Instrumentez votre application [en utilisant l'API OpenTelemetry][12]. + +{{% collapse-content title="Exemple d'application instrumentée avec l'API OpenTelemetry" level="p" %}} +À titre d'exemple, vous pouvez utiliser l'[exemple d'application Calendar][9] qui est déjà instrumenté pour vous. Le code suivant instrumente la méthode [CalendarService.getDate()][10] en utilisant les annotations et l'API OpenTelemetry : + {{< code-block lang="java" filename="CalendarService.java" disable_copy="true" collapsible="false" >}} +@WithSpan(kind = SpanKind.CLIENT) +public String getDate() { + Span span = Span.current(); + span.setAttribute("peer.service", "random-date-service"); + ... +} +{{< /code-block >}} +{{% /collapse-content %}} + +### Configurez l'application {#configure-the-application} + +Le conteneur de votre application doit envoyer des données au collecteur DDOT exécuté sur le même nœud. Comme le collecteur publie les ports OTLP sur le nœud avec `hostPort`, l'application peut atteindre le collecteur local via l'adresse IP du nœud (`status.hostIP`). + +Si la variable d'environnement `OTEL_EXPORTER_OTLP_ENDPOINT` n'est pas déjà définie, ajoutez-la au fichier manifeste de déploiement de votre application : + {{< code-block lang="yaml" filename="deployment.yaml" disable_copy="true" collapsible="true" >}} +env: + ... + - name: HOST_IP + valueFrom: + fieldRef: + fieldPath: status.hostIP + - name: OTLP_GRPC_PORT + value: "4317" + - name: OTEL_EXPORTER_OTLP_ENDPOINT + value: 'http://$(HOST_IP):$(OTLP_GRPC_PORT)' + - name: OTEL_EXPORTER_OTLP_PROTOCOL + value: 'grpc' + {{< /code-block >}} + +### Corrélez les données d'observabilité {#correlate-observability-data} + +Le [Unified service tagging][14] relie les données d'observabilité dans Datadog afin que vous puissiez naviguer entre les métriques, les traces et les logs avec des tags cohérents. + +Dans les environnements conteneurisés, définissez `env`, `service` et `version` à l'aide des variables d'environnement des attributs de ressource OpenTelemetry. Le collecteur DDOT détecte cette configuration de marquage et l'applique aux données qu'il collecte à partir des conteneurs. + +Ajoutez les variables d'environnement suivantes au manifeste de déploiement de votre application : + +{{< code-block lang="yaml" filename="deployment.yaml" disable_copy="true" collapsible="true" >}} +apiVersion: apps/v1 +kind: Deployment +metadata: + name: +spec: + template: + spec: + containers: + - name: + env: + - name: OTEL_SERVICE_NAME + value: "" + - name: OTEL_RESOURCE_ATTRIBUTES + value: "service.version=,deployment.environment.name=" +{{< /code-block >}} + +### Exécutez l'application{#run-the-application} + +Redéployez votre application pour appliquer les modifications apportées au manifeste de déploiement. Une fois la configuration mise à jour active, [Unified Service Tagging] est entièrement activé pour vos métriques, traces et logs. + +## Explorez les données d'observabilité dans Datadog{#explore-observability-data-in-datadog} + +Utilisez Datadog pour explorer les données d'observabilité de votre application. + +### Automatisation du parc {#fleet-automation} + +Explorez la configuration de votre Collector. + +{{< img src="/opentelemetry/embedded_collector/fleet_automation.png" alt="Examinez la configuration de votre Collector depuis la page Fleet Automation." style="width:100%;" >}} + +### Surveillance des conteneurs en temps réel {#live-container-monitoring} + +Surveillez l'état de vos conteneurs à l'aide des fonctionnalités de Live Container Monitoring. + +{{< img src="/opentelemetry/embedded_collector/containers.png" alt="Surveillez l'état de vos conteneurs depuis la page Containers." style="width:100%;" >}} + +### État de santé des nœuds d'infrastructure {#infrastructure-node-health} + +Affichez les métriques d'exécution et d'infrastructure pour visualiser, surveiller et mesurer les performances de vos nœuds. + +{{< img src="/opentelemetry/embedded_collector/infrastructure.png" alt="Affichez les métriques d'exécution et d'infrastructure depuis la liste des hosts." style="width:100%;" >}} + +### Logs{#logs} + +Consultez les logs pour surveiller et diagnostiquer les opérations de l'application et du système. + +{{< img src="/opentelemetry/embedded_collector/logs.png" alt="Affichez les logs depuis le Log Explorer." style="width:100%;" >}} + +### Traces {#traces} + +Affichez les traces et les spans pour observer l'état et les performances des requêtes traitées par votre application, avec des métriques d'infrastructure corrélées dans la même trace. + +{{< img src="/opentelemetry/embedded_collector/traces.png" alt="Affichez les traces depuis le Trace Explorer." style="width:100%;" >}} + +### Métriques runtime {#runtime-metrics} + +Surveillez les métriques runtime (JVM) pour vos applications. + +{{< img src="/opentelemetry/embedded_collector/metrics.png" alt="Affichez les métriques JVM depuis le dashboard JVM Metrics." style="width:100%;" >}} + +### Métriques de santé du Collector {#collector-health-metrics} + +Affichez les métriques du DDOT Collector pour surveiller la santé du Collector. + +{{< img src="/opentelemetry/embedded_collector/dashboard.png" alt="Affichez les métriques de santé du Collector depuis le dashboard OTel." style="width:100%;" >}} + +## Pour aller plus loin {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://www.datadoghq.com/free-datadog-trial/ +[2]: https://app.datadoghq.com/organization-settings/api-keys/ +[3]: https://app.datadoghq.com/organization-settings/application-keys +[4]: https://opentelemetry.io/docs/platforms/kubernetes/helm/collector/ +[5]: https://kubernetes.io/docs/tasks/tools/#kubectl +[9]: https://github.com/DataDog/opentelemetry-examples/tree/main/apps/rest-services/java/calendar +[10]: https://github.com/DataDog/opentelemetry-examples/blob/main/apps/rest-services/java/calendar/src/main/java/com/otel/service/CalendarService.java#L27-L48 +[12]: /fr/tracing/trace_collection/custom_instrumentation/otel_instrumentation/ +[14]: /fr/getting_started/tagging/unified_service_tagging +[52]: /fr/getting_started/site/ +[54]: https://helm.sh +[55]: https://opentelemetry.io/docs/platforms/kubernetes/operator/ +[56]: https://kubernetes.io/docs/concepts/extend-kubernetes/operator/ +[57]: /fr/getting_started/containers/datadog_operator/ \ No newline at end of file diff --git a/hugo/content/fr/opentelemetry/setup/otlp_ingest/managed_platforms.md b/hugo/content/fr/opentelemetry/setup/otlp_ingest/managed_platforms.md new file mode 100644 index 00000000000..50971f879f7 --- /dev/null +++ b/hugo/content/fr/opentelemetry/setup/otlp_ingest/managed_platforms.md @@ -0,0 +1,124 @@ +--- +aliases: +- /fr/opentelemetry/setup/agentless/managed_platforms +description: Envoyez des traces, des métriques et des logs depuis des plateformes + gérées comme Cloudflare, Vercel et Heroku directement vers Datadog via des endpoints + OTLP dédiés. +further_reading: +- link: /opentelemetry/compatibility/ + tag: Documentation + text: Compatibilité OpenTelemetry dans Datadog +- link: /opentelemetry/setup/otlp_ingest/ + tag: Documentation + text: Endpoint d'ingestion OTLP Datadog +title: Ingestion OTLP pour les plateformes gérées +--- +## Présentation {#overview} + +Datadog fournit des endpoints d'ingestion OTLP dédiés pour les plateformes gérées, vous permettant d'envoyer des traces, des métriques et des logs directement vers Datadog avec une configuration minimale. Chaque plateforme prise en charge possède son propre sous-domaine OTLP (par exemple, `cloudflare.integrations.otlp.datadoghq.com`). Ces endpoints dédiés permettent à Datadog d'identifier la source du trafic et d'appliquer un traitement et une attribution spécifiques à la plateforme. L'endpoint OTLP générique suppose qu'un host est présent, ce qui peut entraîner un comportement inattendu pour le trafic des plateformes gérées. + +Utilisez cette option lorsque vous exécutez des charges de travail sur une plateforme gérée où l'installation d'un [Datadog Agent][1] ou d'un [OpenTelemetry Collector][2] n'est pas réalisable. Si votre plateforme ne figure pas dans le tableau ci-dessous et que vous utilisez des services de calcul serverless AWS, Azure ou GCP, consultez [Serverless][5]. + +
Les métadonnées de host envoyées aux endpoints de plateforme gérée ne remplissent pas la liste des hosts d'infrastructure.
+ +Chaque endpoint prend en charge les chemins de signal suivants : + +| Signal | Chemin | +|---------|---------------| +| Traces | `/v1/traces` | +| Métriques | `/v1/metrics` | +| Logs | `/v1/logs` | + +Pour une configuration spécifique aux signaux (traduction de métriques, traitement de logs), consultez les pages des endpoints [Logs][6] et [Metrics][7]. + +## Configuration {#configuration} + +Pour envoyer des données OTLP vers Datadog via un endpoint de plateforme gérée, configurez votre exportateur OpenTelemetry avec les variables d'environnement suivantes. Remplacez `{platform}` par le sous-domaine de votre plateforme issu du tableau des [plateformes prises en charge](#supported-platforms). + +```shell +export OTEL_EXPORTER_OTLP_PROTOCOL="http/protobuf" +export OTEL_EXPORTER_OTLP_ENDPOINT="https://{platform}.integrations.otlp.{{< region-param key="dd_site" >}}" +export OTEL_EXPORTER_OTLP_HEADERS="dd-api-key=${DD_API_KEY}" +``` + +Pour envoyer uniquement des traces : + +```shell +export OTEL_EXPORTER_OTLP_TRACES_PROTOCOL="http/protobuf" +export OTEL_EXPORTER_OTLP_TRACES_ENDPOINT="https://{platform}.integrations.otlp.{{< region-param key="dd_site" >}}/v1/traces" +export OTEL_EXPORTER_OTLP_TRACES_HEADERS="dd-api-key=${DD_API_KEY}" +``` + +
Les endpoints de plateforme gérés n'utilisent pas le dd-otlp-source en-tête. Si vous migrez depuis l'endpoint OTLP générique, supprimez cet en-tête de votre configuration.
+ +## Plateformes prises en charge {#supported-platforms} + +Tous les endpoints suivent le modèle `https://{subdomain}.integrations.otlp.{{< region-param key="dd_site" >}}/`. + +| Plateforme | Sous-domaine | Guide de configuration | +|---|---|---| +| AWX | `awx` | — | +| Claude | `claude` | — | +| Cloudflare | `cloudflare` | [Observabilité de Cloudflare Workers][11] | +| Cribl | `cribl` | — | +| GitHub Actions | `github-actions` | — | +| Grafbase | `grafbase` | [Observabilité de Grafbase][12] | +| Heroku | `heroku` | [Télémétrie Heroku][13] | +| IBM | `ibm` | — | +| LangSmith | `langsmith` | — | +| LiveCloudKit | `livekit` | — | +| Modal | `modal` | [Modal OpenTelemetry][14] | +| MuleSoft | `mulesoft` | [MuleSoft Telemetry Exporter][15] | +| Netlify | `netlify` | — | +| OpenTofu | `opentofu` | — | +| Retool | `retool` | [Retool performance monitoring][16] | +| RWX | `rwx` | [RWX OpenTelemetry][17] | +| Salesforce | `sfdc` | — | +| Shopify | `shopify` | — | +| Solace | `solace` | — | +| Spacelift | `spacelift` | — | +| Supabase | `supabase` | — | +| Svix | `svix` | — | +| Trigger.dev | `triggerdev` | — | +| Vercel | `vercel` | [Vercel Marketplace][18] | + +Pour activer l'exportation OTLP depuis une plateforme gérée non listée ci-dessus, contactez votre Customer Success Manager. + +## Limitations {#limitations} + +### Aucun enrichissement de métadonnées {#no-metadata-enrichment} + +Sans Collector ou Agent, la télémétrie n'est pas enrichie avec les métadonnées du host. Les fonctionnalités qui dépendent de ces métadonnées (par exemple, la [liste des hosts d'infrastructure][8]) sont indisponibles. Consultez la [liste de compatibilité OpenTelemetry][4] pour obtenir la liste complète des fonctionnalités concernées. + +### Normalisation limitée {#limited-normalization} + +Certains traitements de signal qu'un collecteur ou un Agent effectue automatiquement ne se produisent pas avec l'ingestion directe. Par exemple, la conversion de métriques cumulatives en delta nécessite un composant avec état. Si votre plateforme exporte des métriques cumulatives, configurez votre SDK ou votre pipeline pour exporter une temporalité delta. + +### Métriques de trace {#trace-metrics} + +Les [métriques de trace][3] sont calculées par défaut pour les endpoints de plateforme gérés. Les plateformes gérées peuvent échantillonner le trafic avant l'exportation, ce qui peut affecter la précision des métriques de trace. + +### Échantillonnage {#sampling} + +Les contrôles d'échantillonnage disponibles dans le Collecteur (échantillonnage basé sur le suivi, échantillonnage probabiliste) ne sont pas disponibles avec l'ingestion directe. Les plateformes gérées peuvent appliquer leur propre échantillonnage avant l'exportation. + +## Pour aller plus loin {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /fr/opentelemetry/otlp_ingest_in_the_agent/ +[2]: /fr/opentelemetry/setup/collector_exporter/ +[3]: /fr/tracing/metrics/ +[4]: /fr/opentelemetry/compatibility/ +[5]: /fr/opentelemetry/setup/otlp_ingest/serverless/ +[6]: /fr/opentelemetry/setup/otlp_ingest/logs/ +[7]: /fr/opentelemetry/setup/otlp_ingest/metrics/ +[8]: /fr/infrastructure/list/ +[11]: https://developers.cloudflare.com/workers/observability/exporting-opentelemetry-data/ +[12]: https://grafbase.com/docs/gateway/observability +[13]: https://devcenter.heroku.com/articles/heroku-telemetry +[14]: https://modal.com/docs/guide/otel-integration +[15]: https://docs.mulesoft.com/monitoring/telemetry-exporter +[16]: https://docs.retool.com/apps/guides/observability/performance-monitoring +[17]: https://www.rwx.com/docs/observability/datadog +[18]: https://vercel.com/marketplace/datadog \ No newline at end of file diff --git a/hugo/content/fr/product_analytics/charts/analytics_explorer/_index.md b/hugo/content/fr/product_analytics/charts/analytics_explorer/_index.md new file mode 100644 index 00000000000..bed98832a93 --- /dev/null +++ b/hugo/content/fr/product_analytics/charts/analytics_explorer/_index.md @@ -0,0 +1,89 @@ +--- +aliases: +- /fr/product_analytics/analytics_explorer/ +- /fr/product_analytics/journeys +description: '' +further_reading: +- link: /real_user_monitoring/explorer/search/ + tag: Documentation + text: Explorez vos vues dans Datadog +- link: /dashboards/functions/ + tag: Documentation + text: Ajoutez une fonction à votre requête +- link: https://www.datadoghq.com/blog/product-analytics-faster-decisions + tag: Blog + text: Prenez des décisions produit plus rapides et plus pertinentes avec Datadog + Product Analytics +- link: https://www.datadoghq.com/blog/datadog-geomaps/ + tag: Blog + text: Utilisez des coordonnées Geomap pour visualiser les données de votre application + par localisation +- link: https://www.datadoghq.com/blog/reduce-customer-friction-funnel-analysis/ + tag: Blog + text: Utiliser l'analyse de l'entonnoir pour comprendre et optimiser vos flux utilisateur + clés +title: Analytics +--- +## Présentation {#overview} + +La page [Analytics Explorer][1] contient l'agrégation des données de vues pour comprendre comment votre produit est utilisé. Vous pouvez contrôler : + +* Le type d'événement (Sessions, Vues ou Actions) selon lequel afficher les vues. +* La requête qui filtre l'ensemble des vues à analyser. +* Les dimensions sur lesquelles répartir les données. +* La méthode de visualisation pour les agrégats et les répartitions. + +Avec les visualisations Analytics, vous pouvez : + +* Créer un widget dans un dashboard à partir de cette visualisation. +* Approfondissez l'analyse de sous-ensembles de la liste d'événements en fonction des interactions permises par la visualisation. + +## Utilisation du graphique analytique {#using-the-analytics-chart} +{{< whatsnext desc="Suivez ces liens pour apprendre à utiliser la syntaxe de recherche analytique, à afficher les événements, et à visualiser, grouper et exporter les vues. " >}} + {{< nextlink href="product_analytics/charts/analytics_explorer/search_syntax" >}}Syntaxe de recherche{{< /nextlink >}} + {{< nextlink href="product_analytics/charts/analytics_explorer/events" >}} Events {{< /nextlink >}} + {{< nextlink href="product_analytics/charts/analytics_explorer/visualize" >}}Visualiser des événements{{< /nextlink >}} + {{< nextlink href="product_analytics/charts/analytics_explorer/group" >}}Enterprise Groups{{< /nextlink >}} + {{< nextlink href="product_analytics/charts/analytics_explorer/export" >}}Exportation{{< /nextlink >}} +{{< /whatsnext >}} + +## Créez une requête {#build-a-query} + +Dans [Analytics][1], personnalisez votre affichage en ajoutant des facettes et des mesures à votre requête de recherche. + +1. Sélectionnez un [type d'événement de vue][2]. + + {{< img src="product_analytics/analytics/view_type_selection1.png" alt="Menu déroulant dans Product Analytics limité à la sélection du type Vues." style="width:70%;">}} + +1. Choisissez une mesure pour représenter graphiquement le nombre unique. + + {{< img src="product_analytics/analytics/measure_selection1.png" alt="Menu déroulant dans Product Analytics pour choisir une mesure à représenter graphiquement le nombre unique." style="width:70%;">}} + +1. Filtrez par attributs d'événement ou par attributs issus d'[intégrations tierces][6]. + + {{< img src="product_analytics/analytics/pana_analytics_filter_by.png" alt="Menu déroulant dans Product Analytics pour filtrer les événements par leurs propres attributs ou par des attributs issus d'intégrations tierces." style="width:70%;">}} + +1. Choisissez un attribut d'événement pour ventiler davantage les résultats. + + {{< img src="product_analytics/analytics/pana_analytics_breakdown_by1.png" alt="Menu déroulant dans Product Analytics pour ventiler davantage les événements par leurs propres attributs ou par des attributs issus d'intégrations tierces." style="width:70%;">}} + +1. Appliquez une [fonction][4] pour modifier la manière dont les résultats de la requête sont renvoyés pour les visualisations. + + {{< img src="product_analytics/analytics/pana_analytics_functions.png" alt="Bouton dans Product Analytics pour ajouter une fonction permettant de modifier la manière dont les résultats d'une requête de métrique sont renvoyés pour les visualisations." style="width:70%;">}} + +1. Choisissez le [type de graphique][5] et l'intervalle de temps pour votre graphique. Le changement de l'intervalle de temps global modifie la liste des laps de temps disponibles. + + {{< img src="product_analytics/analytics/pana_analytics_time_interval2.png" alt="Choisissez un type de graphique et un intervalle de temps pour votre graphique." style="width:50%;">}} + + + +## Pour aller plus loin {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://app.datadoghq.com/product-analytics/explorer +[2]: /fr/real_user_monitoring/guide/understanding-the-rum-event-hierarchy/ +[3]: /fr/product_analytics/charts/analytics_explorer/group +[4]: /fr/dashboards/functions/#overview +[5]: /fr/product_analytics/charts/analytics_explorer/visualize/ +[6]: https://app.datadoghq.com/product-analytics/integrations/custom-attributes \ No newline at end of file diff --git a/hugo/content/fr/real_user_monitoring/guide/retention_filter_best_practices.md b/hugo/content/fr/real_user_monitoring/guide/retention_filter_best_practices.md new file mode 100644 index 00000000000..e3039d83617 --- /dev/null +++ b/hugo/content/fr/real_user_monitoring/guide/retention_filter_best_practices.md @@ -0,0 +1,133 @@ +--- +description: Apprenez les meilleures pratiques pour séquencer vos filtres de rétention + afin de stocker les données RUM dont vous avez besoin. +further_reading: +- link: /real_user_monitoring/rum_without_limits/retention_filters + tag: Documentation + text: Filtres de rétention +- link: /real_user_monitoring/rum_without_limits/ + tag: Documentation + text: RUM without Limits +- link: /real_user_monitoring/rum_without_limits/metrics + tag: Documentation + text: Analysez les performances avec des métriques +- link: https://www.datadoghq.com/blog/rum-apm-retention-filters + tag: Blog + text: Unifiez et corrélez les données frontend et backend avec des filtres de rétention +- link: https://learn.datadoghq.com/courses/rum-retention-filters + tag: Centre d'apprentissage + text: 'Laboratoire interactif : filtres de rétention RUM' +title: Bonnes pratiques pour les retention filter (filtre de rétention) +--- +{{< learning-center-callout header="Essayez les filtres de rétention RUM dans le centre d'apprentissage" btn_title="Inscrivez-vous maintenant" btn_url="https://learn.datadoghq.com/courses/rum-retention-filters" hide_image="false" >}} + Découvrez comment utiliser les filtres de rétention RUM pour contrôler les données de session stockées et optimiser votre budget d'observabilité. +{{< /learning-center-callout >}} + +## Présentation {#overview} + +RUM without Limits vous permet de capturer toutes les données de session tout en ne conservant que les sessions qui sont précieuses pour votre organisation. Cet outil améliore votre gestion des données en séparant l'ingestion des données de session de l'indexation. + +## Fonctionnalités clés {#key-features} + +- **Filtres de rétention dynamiques** : Ajustez les données à conserver sans modifier le code +- **Métriques complètes** : Les métriques reflètent 100 % des sessions, garantissant une visibilité totale +- **Rétention de session ciblée** : Donnez la priorité aux données de session cruciales pour l'optimisation des coûts + +Ce guide fournit des stratégies pour gérer efficacement vos volumes de sessions RUM dans le cadre de votre budget d'observabilité. + +## Comprendre le séquençage des filtres de rétention {#understanding-retention-filter-sequencing} + +Les filtres de rétention RUM vous permettent de choisir les sessions utilisateur à conserver. Voici comment ils fonctionnent : + +Chaque session contient plusieurs événements (comme des vues qui représentent la navigation, des actions utilisateur, des erreurs, des ressources qui représentent des requêtes réseau) et chacun d'eux est rempli d'attributs (comme la durée, le contexte, etc.). Le système évalue chaque événement individuellement par rapport à vos filtres de rétention : + +1. **Session conservée** : Si au moins un événement dans une session correspond à un filtre de rétention ET est échantillonné pour la rétention, alors la session entière est préservée. +2. **Session supprimée** : Si aucun événement ne correspond à un filtre de rétention à la fin de la session, la session entière est supprimée. + +{{< img src="real_user_monitoring/rum_without_limits/rum-without-limits-how-retention-filters-work-3.png" alt="Organigramme montrant le fonctionnement des filtres de rétention : 1. Les événements d'une session sont vérifiés par rapport aux filtres, 2. Si un événement correspond et est sélectionné, la session entière est conservée, 3. Si aucun événement ne correspond à un filtre, la session est supprimée" style="width:80%" >}} + +### Fonctionnement des différents types d'événements {#how-different-event-types-work} + +Certains événements (comme les erreurs et les actions) ne peuvent pas être modifiés une fois qu'ils se sont produits. Datadog appelle ces **événements immuables**. D'autres (comme les sessions et les vues) peuvent changer à mesure que l'utilisateur continue d'utiliser votre application. Datadog appelle ces **événements mutables**. + +- **Les événements immuables** (Action, Error, Resource, Long Task et Vital [events][1]) ne sont vérifiés qu'**une seule fois** par rapport à vos filtres et ne peuvent pas être modifiés une fois créés : + + 1. L'événement s'arrête au premier filtre qui correspond à ses tags et attributs. + 2. Un nombre aléatoire est généré et comparé au taux d'échantillonnage du filtre pour décider si l'événement doit être conservé ou supprimé. + 3. Si l'événement est conservé, la session entière (y compris tous les événements précédents) est conservée, et les événements futurs de la même session passent automatiquement outre les filtres de rétention. + 4. Si l'événement est supprimé, il n'est pas évalué par d'autres filtres, mais les autres événements de la même session continuent d'être traités indépendamment. + +- **Les événements mutables** (Session, View) sont revérifiés à chaque mise à jour : + - Les événements View et Session sont différents des événements immuables car ils peuvent changer au fil du temps. Ces événements reçoivent des mises à jour chaque fois que de nouveaux événements se produisent en leur sein. + - Contrairement aux [événements immuables](#immutable-events) qui ne sont évalués qu'une seule fois, les événements View et Session sont réévalués par rapport aux filtres de rétention à chaque mise à jour. Cela continue jusqu'à ce qu'ils correspondent à un filtre pour la première fois. + +## Bonnes pratiques {#best-practices} + +### Ordre des filtres de rétention {#ordering-retention-filters} + +L'ordre de vos [filtres de rétention][2] est important. Datadog recommande de placer les filtres les plus spécifiques avec les taux d'échantillonnage les plus élevés en haut de la liste, et vos filtres les plus généraux avec les taux d'échantillonnage les plus bas en bas. + +Par exemple, imaginez que vous ayez un événement de crash (un événement Error avec l'attribut `@error.is_crash:true`). Cet événement pourrait correspondre à plus d'un filtre, mais il n'est évalué que par rapport au premier filtre correspondant dans votre liste. + +- Dans l'exemple ci-dessous, le filtre de rétention « Crashes » est placé au-dessus du filtre plus général « All errors ». Cela signifie que toutes les sessions de crash sont conservées, car elles correspondent d'abord au filtre « Crashes ». + + | ✅ Recommandé | + |---------| + | {{< img src="real_user_monitoring/rum_without_limits/retention-filters-good-3.png" alt="Exemple de bon ordre de filtrage : 1. Sessions avec relectures (100 % de rétention), 2. Sessions de crash (100 % de rétention), 3. Toutes les sessions d'erreur (50 % de rétention). Cela garantit que les sessions de crash sont toujours capturées." style="width:100%" >}} | + +- Dans l'exemple suivant, le filtre plus général « All errors » est placé avant le filtre « Crashes ». Pour cette raison, les sessions de crash ne sont conservées que si elles sont sélectionnées par le filtre « All errors » (par exemple, s'il a un taux d'échantillonnage de 50 %). Si elles ne sont pas sélectionnées, elles ne sont pas évaluées par le filtre « Crashes » et ces sessions sont perdues. + + | ❌ Non recommandé | + |---------| + | {{< img src="real_user_monitoring/rum_without_limits/retention-filters-bad-3.png" alt="Exemple de mauvais ordre de filtrage : 1. Sessions avec relectures (100 % de rétention), 2. Toutes les sessions d'erreur (50 % de rétention), 3. Sessions de crash (100 % de rétention). Cela risque de perdre des sessions de crash si elles ne correspondent pas d'abord au filtre d'erreur général." style="width:100%" >}} | + +### Filtres de secours pour capturer les sessions restantes {#fallback-filters-for-capturing-remaining-sessions} + +Un filtre de secours en bas de votre liste capture un faible pourcentage de sessions qui n'ont pas été capturées par d'autres filtres. Vous devriez toujours inclure `@session.is_active:false` dans votre requête de filtre de secours. + +- **Avec `@session.is_active:false`** : Le filtre de secours n'évalue que les sessions terminées, laissant vos autres filtres capturer les sessions en premier + + | ✅ Recommandé | + |---------| + | {{< img src="real_user_monitoring/rum_without_limits/retention-filters-catchall-good-3.png" alt="Exemple de bon filtre de secours : 1. Sessions avec relectures (100 % de rétention), 2. Sessions durant plus de 5 secondes (100 % de rétention), 3. Sessions qui ne sont pas actives (10 % de rétention). Cela garantit que les autres filtres ont la priorité pour capturer les sessions." style="width:100%" >}} | + +- **Sans `@session.is_active:false`** : Le filtre de secours capture immédiatement toutes les sessions, remplaçant potentiellement vos filtres plus spécifiques + + | ❌ Non recommandé | + |---------| + | {{< img src="real_user_monitoring/rum_without_limits/retention-filters-catchall-bad-3.png" alt="Exemple de mauvais filtre de secours : 1. Sessions avec relectures (100 % de rétention), 2. Sessions durant plus de 5 secondes (100 % de rétention), 3. Toutes les sessions (10 % de rétention). Cela risque de remplacer des filtres plus spécifiques en capturant immédiatement toutes les sessions." style="width:100%" >}} | + +### Exclusion de sessions {#excluding-sessions} + +Pour éviter qu'un seul filtre ne corresponde à un sous-ensemble d'événements, ajoutez l'exclusion dans la requête de ce filtre. Voir [Exclure des sessions à l'aide de filtres de rétention][3]. + +Pour exclure des événements sur l'ensemble de vos filtres de rétention personnalisés à la fois, sans répéter la même exclusion dans chaque requête, utilisez plutôt des [filtres d'exclusion][4]. + +## Filtres de rétention suggérés et cas d'utilisation {#suggested-retention-filters-and-use-cases} +Nous décrivons ci-dessous l'ensemble des filtres par défaut, les filtres suggérés et leurs cas d'utilisation typiques. + +| Type de filtre | Exemple de requête | Quand utiliser | Taux de rétention | +|-------------|---------------|-------------|----------------| +| Sessions avec relectures | `@session.has_replay:true` | Conservez les sessions avec une relecture pour vous assurer que le système ne supprime aucune session pour laquelle des relectures de session sont disponibles. | 100 % | +| Sessions avec erreurs | `@type:error` | Un filtre par défaut qui peut être appliqué pour conserver toutes les sessions contenant au moins 1 erreur. | 100 % | +| Sessions avec plantages | `@type:error @error.is_crash:true` | Un filtre qui peut être appliqué pour conserver toutes les sessions qui se sont terminées par un plantage. | 100 % | +| Sessions | `@type:session` | Un filtre par défaut, placé en dernier dans la liste, à appliquer à toutes les sessions, qui vous permet d'en conserver ou d'en supprimer un pourcentage. | Variable | +| Versions de l'application | `@type:session version:v1.1.0-beta` | Le filtrage par version d'application (bêta, alpha ou version spécifique) garantit que toutes les sessions d'une version particulière sont enregistrées pour une analyse détaillée et un dépannage. | 100 % | +| Environnements | `@type:session environment:stage` | Lors de la collecte de sessions à partir de divers types de versions ou environnements, assurez-vous de capturer au moins 100 % des sessions des environnements de staging, tout en collectant un pourcentage plus faible des environnements de développement/test. | 100 % | +| Feature flags | `@type:session feature_flags.checkout_type:treatment_v1` | Si vous utilisez déjà des Feature Flags, vous pouvez choisir de conserver 100 % des sessions avec des traitements de Feature Flags spécifiques. | 100 % | +| Attributs personnalisés | `@type:session @context.cartValue:>=500` | Créez des filtres en utilisant presque n'importe quelle requête, y compris des attributs de session personnalisés, pour spécifier des critères de rétention. Par exemple, dans l'application de démonstration Datadog Shopist, la valeur du panier est un attribut de session personnalisé. Cela permet la rétention des sessions avec des valeurs de panier élevées, facilitant ainsi le dépannage efficace des problèmes ayant un impact sur les revenus. | Variable | +| Session avec des attributs utilisateur | `@type:session user.tier:paid` | Utilisez les informations utilisateur d'une session pour créer un filtre. Par exemple, vous pouvez conserver les sessions pour tous vos utilisateurs de niveau payant. | 100 % | +| Sessions avec un utilisateur spécifique | `@type:session user.id:XXXXX` | Ce filtre peut cibler les sessions d'utilisateurs spécifiques, tels qu'un compte de test de production ou un cadre qui teste régulièrement l'application. | 100 % | +| Sessions avec une action spécifique | `@type:action @action.name:XXXXX` | Vous pouvez conserver toutes les sessions comportant une action spécifique que le SDK suit automatiquement par défaut ou une action personnalisée que vous avez instrumentée dans votre code. | 100 % | +| Sessions avec une durée spécifique | `@session.view.count :> 3 OR @session.time_spent :> 15000000000` | Si vous remarquez de nombreuses sessions courtes, comme un utilisateur consultant une page pendant 10 secondes sans autre action ni erreur, elles ne sont généralement pas utiles. Vous pouvez utiliser un filtre de rétention par durée pour réduire ces sessions. **Remarque** : Saisissez la valeur de la durée sous forme de nombre en nanosecondes - n'incluez aucune unité (par exemple, utilisez `15000000000` pour 15 secondes). | Variable | +| Sessions avec une erreur réseau 4XX et 5XX | `@type:resource @resource.status_code:>=400` | Les applications frontend rencontrent souvent des problèmes avec des services en aval renvoyant des codes d'état 4XX ou 5XX. En utilisant ce filtre, vous pouvez capturer toutes les sessions avec des appels de ressources qui aboutissent à des codes d'erreur. | 100 % | + + +## Lectures complémentaires {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /fr/real_user_monitoring/guide/understanding-the-rum-event-hierarchy/ +[2]: /fr/real_user_monitoring/rum_without_limits/retention_filters/#how-it-works +[3]: /fr/real_user_monitoring/rum_without_limits/retention_filters#excluding-events-with-a-filter-query +[4]: /fr/real_user_monitoring/rum_without_limits/retention_filters#exclusion-filters \ No newline at end of file diff --git a/hugo/content/fr/security/application_security/setup/aws/fargate/_index.md b/hugo/content/fr/security/application_security/setup/aws/fargate/_index.md new file mode 100644 index 00000000000..dad76938213 --- /dev/null +++ b/hugo/content/fr/security/application_security/setup/aws/fargate/_index.md @@ -0,0 +1,46 @@ +--- +disable_sidebar: true +further_reading: +- link: /security/application_security/ + tag: Documentation + text: Protégez contre les menaces avec Datadog App and API Protection +- link: /security/application_security/add-user-info/ + tag: Documentation + text: Suivi de l'activité utilisateur +- link: /security/default_rules/?category=cat-application-security + tag: Documentation + text: Règles prêtes à l'emploi pour App and API Protection +- link: /security/application_security/troubleshooting + tag: Documentation + text: Dépannage d'App and API Protection +- link: /security/application_security/how-it-works/ + tag: Documentation + text: Fonctionnement d'App and API Protection dans Datadog +title: Configurer App and API Protection sur AWS Fargate +--- +{{< site-region region="gov" >}} +
+App and API Protection est en préversion sur le site Datadog Government US1-FED. +
+{{< /site-region >}} + +Apprenez à configurer App and API Protection (AAP) sur vos tâches AWS Fargate en sélectionnant le langage de programmation de votre tâche. + +
+

Votre environnement est-il manquant ?

+ Envoyez-nous une demande pour votre environnement manquant ici . +
+ +{{< appsec-integrations >}} + {{< appsec-integration name="Python" avatar="python" link="/security/application_security/setup/python/aws-fargate" >}} + {{< appsec-integration name="Node.js" avatar="node" link="/security/application_security/setup/nodejs/aws-fargate" >}} + {{< appsec-integration name="Java" avatar="java" link="/security/application_security/setup/java/aws-fargate" >}} + {{< appsec-integration name="Go" avatar="go" link="/security/application_security/setup/go/aws-fargate" >}} + {{< appsec-integration name="Ruby" avatar="ruby" link="/security/application_security/setup/ruby/aws-fargate" >}} + {{< appsec-integration name=".NET" avatar="dotnet" link="/security/application_security/setup/dotnet/aws-fargate" >}} + {{< appsec-integration name="PHP" avatar="php" link="/security/application_security/setup/php/aws-fargate" >}} +{{< /appsec-integrations >}} + +## Pour aller plus loin {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} \ No newline at end of file diff --git a/hugo/content/fr/security/application_security/setup/gcp/cloud-run/_index.md b/hugo/content/fr/security/application_security/setup/gcp/cloud-run/_index.md new file mode 100644 index 00000000000..07c53a5db89 --- /dev/null +++ b/hugo/content/fr/security/application_security/setup/gcp/cloud-run/_index.md @@ -0,0 +1,46 @@ +--- +disable_sidebar: true +further_reading: +- link: /security/application_security/ + tag: Documentation + text: Protégez contre les menaces avec Datadog App and API Protection +- link: /security/application_security/add-user-info/ + tag: Documentation + text: Suivi de l'activité des utilisateurs +- link: /security/default_rules/?category=cat-application-security + tag: Documentation + text: Règles App and API Protection prêtes à l'emploi +- link: /security/application_security/troubleshooting + tag: Documentation + text: Dépannage d'App and API Protection +- link: /security/application_security/how-it-works/ + tag: Documentation + text: Fonctionnement d'App and API Protection dans Datadog +title: Configurer App and API Protection sur les fonctions Google Cloud Run +--- +{{< site-region region="gov" >}} +
+App and API Protection est en préversion sur le site Datadog Government US1-FED. +
+{{< /site-region >}} + +Apprenez à configurer App and API Protection (AAP) sur vos fonctions Google Cloud Run en sélectionnant le langage de programmation utilisé pour votre fonction. + +
+

Votre environnement est-il manquant ?

+ Envoyez-nous une demande pour votre environnement manquant ici. +
+ +{{< appsec-integrations >}} + {{< appsec-integration name="Python" avatar="python" link="./python" >}} + {{< appsec-integration name="Node.js" avatar="node" link="./nodejs" >}} + {{< appsec-integration name="Java" avatar="java" link="./java" >}} + {{< appsec-integration name="Go" avatar="go" link="./go" >}} + {{< appsec-integration name="Ruby" avatar="ruby" link="./ruby" >}} + {{< appsec-integration name=".NET" avatar="dotnet" link="./dotnet" >}} + {{< appsec-integration name="PHP" avatar="php" link="./php" >}} +{{< /appsec-integrations >}} + +## Pour aller plus loin {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} \ No newline at end of file diff --git a/hugo/content/fr/security/application_security/setup/kubernetes/_index.md b/hugo/content/fr/security/application_security/setup/kubernetes/_index.md new file mode 100644 index 00000000000..629fb057674 --- /dev/null +++ b/hugo/content/fr/security/application_security/setup/kubernetes/_index.md @@ -0,0 +1,44 @@ +--- +disable_sidebar: true +further_reading: +- link: /security/application_security/ + tag: Documentation + text: Protégez contre les menaces avec Datadog App and API Protection +- link: /security/application_security/add-user-info/ + tag: Documentation + text: Suivi de l'activité des utilisateurs +- link: /security/default_rules/?category=cat-application-security + tag: Documentation + text: Règles App and API Protection prêtes à l'emploi +- link: /security/application_security/troubleshooting + tag: Documentation + text: Dépannage d'App and API Protection +- link: /security/application_security/how-it-works/ + tag: Documentation + text: Fonctionnement d'App and API Protection dans Datadog +title: Configurer App and API Protection sur Kubernetes +--- +{{< site-region region="gov" >}} +
+App and API Protection est en préversion sur le site Datadog Government US1-FED. +
+{{< /site-region >}} + +Apprenez à configurer App and API Protection (AAP) sur vos clusters Kubernetes en sélectionnant l'intégration Kubernetes qui vous convient le mieux. + +
+

Votre environnement manque-t-il ?

+ Envoyez-nous une demande pour votre environnement manquant ici. +
+ +{{< appsec-integrations >}} + {{< appsec-integration name="Istio" avatar="istio" link="./istio" >}} + {{< appsec-integration name="Envoy Gateway" avatar="envoy" link="./envoy-gateway" >}} + {{< appsec-integration name="Gateway API" src="integrations_logos/gateway-api_avatar.svg" link="./gateway-api" >}} + {{< appsec-integration name="Ingress NGINX Controller" avatar="nginx" link="../nginx/ingress-controller" >}} + {{< appsec-integration name="Google Kubernetes Engine (GKE)" src="integrations_logos/google_kubernetes_engine.png" link="./gke" >}} +{{< /appsec-integrations >}} + +## Pour aller plus loin {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} \ No newline at end of file diff --git a/hugo/content/fr/security/cloud_siem/guide/_index.md b/hugo/content/fr/security/cloud_siem/guide/_index.md index f6e651e17a7..937434a7b86 100644 --- a/hugo/content/fr/security/cloud_siem/guide/_index.md +++ b/hugo/content/fr/security/cloud_siem/guide/_index.md @@ -7,13 +7,16 @@ disable_toc: true private: true title: Guides sur Cloud SIEM --- - -{{< whatsnext desc="guides généraux :" >}} - {{< nextlink href="/getting_started/cloud_siem" >}}Premiers pas avec Cloud SIEM{{< /nextlink >}} - {{< nextlink href="/security/cloud_siem/guide/automate-the-remediation-of-detected-threats" >}}Automatiser la résolution de menaces détectées avec Cloud SIEM{{< /nextlink >}} - {{< nextlink href="/security/cloud_siem/guide/aws-config-guide-for-cloud-siem" >}}Guide AWS de configuration de Cloud SIEM{{< /nextlink >}} - {{< nextlink href="/security/cloud_siem/guide/google-cloud-config-guide-for-cloud-siem/" >}}Guide de configuration de Google Cloud pour Cloud SIEM{{< /nextlink >}} - {{< nextlink href="/security/cloud_siem/guide/azure-config-guide-for-cloud-siem/" >}}Guide de configuration dʼAzure pour Cloud SIEM{{< /nextlink >}} +{{< whatsnext desc="Guides généraux :" >}} + {{< nextlink href="/getting_started/cloud_siem" >}}Débuter avec Cloud SIEM{{< /nextlink >}} + {{< nextlink href="/security/cloud_siem/guide/determine-cloud-siem-product" >}}Déterminez le produit Cloud SIEM utilisé par votre organisation{{< /nextlink >}} + {{< nextlink href="/security/cloud_siem/guide/automate-the-remediation-of-detected-threats" >}}Automatisez la remédiation des menaces détectées avec Cloud SIEM{{< /nextlink >}} + {{< nextlink href="/security/cloud_siem/guide/aws-config-guide-for-cloud-siem" >}}Guide de configuration d'AWS pour Cloud SIEM{{< /nextlink >}} + {{< nextlink href="/security/cloud_siem/guide/google-cloud-config-guide-for-cloud-siem/" >}}Guide de configuration de Google Cloud pour Cloud SIEM{{< /nextlink >}} + {{< nextlink href="/security/cloud_siem/guide/azure-config-guide-for-cloud-siem/" >}}Guide de configuration Azure pour Cloud SIEM{{< /nextlink >}} + {{< nextlink href="/security/cloud_siem/guide/oci-config-guide-for-cloud-siem/" >}}Guide de configuration OCI pour Cloud SIEM{{< /nextlink >}} {{< nextlink href="security/cloud_siem/guide/monitor-authentication-logs-for-security-threats" >}}Surveillance des logs d'authentification pour identifier les menaces de sécurité{{< /nextlink >}} - {{< nextlink href="/security/cloud_siem/guide/how-to-setup-security-filters-using-cloud-siem-api" >}}Filtres de sécurité avec lʼAPI Cloud SIEM{{< /nextlink >}} + {{< nextlink href="/security/cloud_siem/guide/customize-which-logs-cloud-siem-analyzes" >}}Personnalisez les logs analysés par Cloud SIEM{{< /nextlink >}} + {{< nextlink href="/security/cloud_siem/guide/ingest-stix-threat-intelligence" >}}Ingérez des renseignements sur les menaces STIX{{< /nextlink >}} + {{< nextlink href="/security/cloud_siem/guide/troubleshoot-cribl-stream-cloud-siem" >}}Dépannez avec Cribl Stream et Cloud SIEM{{< /nextlink >}} {{< /whatsnext >}} \ No newline at end of file diff --git a/hugo/content/fr/security/cloud_siem/guide/ingest-stix-threat-intelligence.md b/hugo/content/fr/security/cloud_siem/guide/ingest-stix-threat-intelligence.md new file mode 100644 index 00000000000..bfa1e9ccc85 --- /dev/null +++ b/hugo/content/fr/security/cloud_siem/guide/ingest-stix-threat-intelligence.md @@ -0,0 +1,235 @@ +--- +description: 'Envoyez vos propres renseignements sur les menaces à Cloud SIEM sous + forme de bundles STIX 2.1 : Couvre l''endpoint d''ingestion, l''authentification, + les types d''indicateurs et modèles pris en charge, les tableaux de référence que + Datadog génère pour chaque type d''indicateur, ainsi que la manière de les configurer + ou de les supprimer.' +disable_toc: false +further_reading: +- link: /security/cloud_siem/ingest_and_enrich/threat_intelligence/ + tag: Documentation + text: Apportez vos propres renseignements sur les menaces à Cloud SIEM +- link: /security/threat_intelligence/ + tag: Documentation + text: Renseignements sur les menaces dans Datadog Security +- link: /security/cloud_siem/triage_and_investigate/ioc_explorer/ + tag: Documentation + text: Enquêtez sur les indicateurs avec l'IOC Explorer +- link: /reference_tables/ + tag: Documentation + text: Créer et gérer des tableaux de référence +title: Ingérez des renseignements sur les menaces STIX +--- +## Présentation {#overview} + +Si votre organisation gère des renseignements sur les menaces dans une plateforme de renseignements sur les menaces (TIP), vous pouvez les envoyer à Cloud SIEM sous forme de bundles [STIX 2.1][1]. Cloud SIEM utilise les indicateurs ingérés pour [enrichir vos logs][2] et les affiche dans l'[IOC Explorer][3] + +Utilisez l'ingestion STIX lorsque votre plateforme produit déjà du STIX, ou lorsque vous souhaitez qu'un script ou un job planifié envoie des mises à jour incrémentielles. Pour importer des indicateurs sous forme de fichiers CSV ou les synchroniser depuis un stockage cloud, consultez [Apportez vos propres renseignements sur les menaces à Cloud SIEM][2]. + +## Fonctionnement {#how-it-works} + +Après avoir envoyé un bundle STIX 2.1 à l'[endpoint d'ingestion](#send-indicators), Datadog le traite comme suit. Aucune configuration préalable dans Datadog n'est requise. + +1. Datadog identifie le flux à partir de l'en-tête `ti_vendor` requis. +2. Datadog génère une [Reference Table][4] pour chaque type d'indicateur dans votre flux, nommée `threat_intel_stix__`. Comme un bundle peut contenir plusieurs types d'indicateurs, une seule requête peut alimenter plusieurs tableaux. +3. Datadog enregistre chaque tableau généré et l'active automatiquement pour l'enrichissement de Cloud SIEM. +4. Les requêtes ultérieures pour le même `ti_vendor` mettent à jour les tableaux existants et conservent les choix de configuration que vous avez effectués. + +Par exemple, un flux envoyé avec `ti_vendor: acme` contenant des indicateurs d'adresse IP, de domaine et de SHA-256 produit les tableaux suivantes : + +| Type d'indicateur | Reference Table générée | +|---|---| +| Adresse IP | `threat_intel_stix_acme_ip_address` | +| Domaine | `threat_intel_stix_acme_domain` | +| Hachage de fichier SHA-256 | `threat_intel_stix_acme_sha256` | + +Les tableaux deviennent disponibles quelques minutes après votre première requête. L'enrichissement s'applique aux logs que Cloud SIEM reçoit après l'activation d'un tableau ; il ne s'applique donc pas aux logs reçus précédemment. + +## Prérequis {#prerequisites} + +- Cloud SIEM est activé pour votre organisation. +- Une [clé d'API][5] Datadog et une [clé d'application][6]. La clé d'application doit disposer de l'autorisation « Reference Tables Write ». + +## Envoyer des indicateurs {#send-indicators} + +`POST https://api.{{< region-param key="dd_site" >}}/api/v2/security/threat-intel/stix` + +
L'URL de l'endpoint varie selon le site. Utilisez le site Datadog approprié pour votre organisation.
+ +### En-têtes {#headers} + +| En-tête | Requis | Description | +|---|---|---| +| `DD-API-KEY` | Oui | Votre clé d'API Datadog. | +| `DD-APPLICATION-KEY` | Oui | Une clé d'application avec l'autorisation Reference Tables Write. | +| `ti_vendor` | Oui | Identifie le flux ; par exemple, le nom de votre plateforme. Utilisez 10 caractères ou moins, avec uniquement des lettres minuscules et des chiffres. | +| `Content-Type` | Oui | `application/json` | +| `Content-Encoding` | Non | Défini sur `gzip` pour envoyer un corps compressé. Aucun autre encodage n'est pris en charge. | + +### Corps de la requête {#request-body} + +Le corps est un bundle STIX 2.1 `bundle` d'objets STIX. Chaque requête est un lot incrémentiel, et un bundle peut mélanger des indicateurs de différents types. + +```json +{ + "type": "bundle", + "id": "bundle--0cde353c-ea5b-4668-9f68-9c3a0e2a0a0e", + "objects": [ + { + "type": "indicator", + "spec_version": "2.1", + "id": "indicator--a932fcc6-e032-476c-826f-cb970a5a1fff", + "pattern_type": "stix", + "pattern": "[ipv4-addr:value = '198.51.100.1']", + "indicator_types": ["malicious-activity"], + "valid_from": "2026-01-01T00:00:00Z", + "valid_until": "2026-12-31T00:00:00Z" + } + ] +} +``` + +L'endpoint a les exigences et limites suivantes : + +- Le bundle doit être au format STIX 2.1. Si le bundle contient un `spec_version` autre que `2.1`, Datadog rejette la requête. Si un objet individuel contient un `spec_version` autre que `2.1`, Datadog ignore cet objet. +- La taille maximale du corps de la requête est de 50 Mo. + +### Types d'indicateurs et modèles pris en charge {#supported-indicator-types-and-patterns} + +Datadog lit le `pattern` STIX sur chaque indicateur pour déterminer son type et sa valeur. Cloud SIEM ingère les adresses IP (IPv4 et IPv6), les domaines et les hachages de fichier SHA-256. + +Datadog extrait les valeurs exactes des comparaisons `=` et `IN`. Il accepte également les expressions `OR` et importe chaque valeur comme un indicateur distinct. `AND` entre crochets n'est pas pris en charge. + +```json +"pattern": "[ipv4-addr:value = '198.51.100.1'] OR [domain-name:value IN ('example.com', 'example.net')]" +``` + +Les modèles utilisant la négation, les plages, la correspondance par caractères génériques, la correspondance par expression régulière, les relations de sous-réseau, les checks d'existence, les qualificateurs temporels ou `FOLLOWEDBY` ne sont pas pris en charge. Si une partie d'un modèle utilise une expression non prise en charge, Datadog ignore l'objet indicateur. + +La réponse compte les objets non pris en charge comme `unsupported` et les modèles non analysables comme `invalid`. Vérifiez ces nombres pour confirmer que votre flux a été ingéré comme prévu. + +### Comment les champs STIX correspondent aux colonnes de la Reference Table {#how-stix-fields-map-to-reference-table-columns} + +| Colonne de la Reference Table | Remplie à partir de | +|---|---| +| Valeur de l'indicateur | La valeur extraite du `pattern` de l'indicateur. | +| `intention` | Le champ `indicator_types`. `malicious-activity` correspond à `malicious` ; `benign` correspond à `benign` ; et toute autre valeur ou un champ absent correspond à `suspicious`. | +| `source` | L'en-tête `ti_vendor`, stocké sous `{"name": ""}`. | +| `category` | Défini sur `custom`. | +| `additional_data` | Les champs STIX qui n'ont pas de colonne dédiée, y compris `stix_id`, `created`, `modified`, `valid_from`, `confidence`, `labels`, `indicator_types`, `object_marking_refs`, `kill_chain_phases` et `external_references`. | + +Le champ optionnel `valid_until` définit une expiration pour l'indicateur, et Datadog supprime l'indicateur après ce délai. Un indicateur envoyé sans `valid_until` n'expire pas automatiquement. + +### Mettre à jour et révoquer des indicateurs {#update-and-revoke-indicators} + +- Pour mettre à jour les détails d'un indicateur, renvoyez l'indicateur avec les champs mis à jour. Datadog écrase la ligne existante pour cette valeur d'indicateur. +- Pour supprimer un indicateur, envoyez-le avec `"revoked": true`. Datadog supprime l'indicateur de la Reference Table. + +L'envoi du même bundle plusieurs fois ne crée pas de lignes en double. + +### Réponse {#response} + +Une requête réussie renvoie `200 OK` et un résumé de la façon dont Datadog a traité le bundle : + +```json +{ + "data": { + "type": "threat-intel-stix-ingest", + "id": "acme", + "attributes": { + "accepted": 3, + "unsupported": 1, + "invalid": 0 + } + } +} +``` + +| Attribut | Description | +|---|---| +| `accepted` | Le nombre d'objets indicateurs pris en charge que Datadog a acceptés pour traitement. Ce décompte inclut les nouveaux indicateurs, les mises à jour et les révocations. Un objet peut produire plus d'un indicateur lorsque son modèle utilise `IN` ou `OR`. | +| `unsupported` | Nombre d'objets indicateurs que Datadog a ignorés car leur type, leur modèle ou leur version STIX au niveau de l'objet n'est pas pris en charge. | +| `invalid` | Nombre d'objets indicateurs dont le modèle n'a pas pu être analysé par Datadog. | + +Une réponse `200` signifie que Datadog a accepté le bundle. Les indicateurs non pris en charge et invalides apparaissent dans ces comptes au lieu de provoquer l'échec de la requête. Vérifiez les comptes pour confirmer que votre flux a été ingéré comme prévu. + +### Exemple de requête {#example-request} + +```shell +curl -X POST "https://api.{{< region-param key="dd_site" code="true" >}}/api/v2/security/threat-intel/stix" \ + --header "DD-API-KEY: " \ + --header "DD-APPLICATION-KEY: " \ + --header "Content-Type: application/json" \ + --header "ti_vendor: acme" \ + --data '{ + "type": "bundle", + "id": "bundle--0cde353c-ea5b-4668-9f68-9c3a0e2a0a0e", + "objects": [ + { + "type": "indicator", + "spec_version": "2.1", + "id": "indicator--a932fcc6-e032-476c-826f-cb970a5a1fff", + "pattern_type": "stix", + "pattern": "[ipv4-addr:value = '198.51.100.1']", + "indicator_types": ["malicious-activity"], + "valid_from": "2026-01-01T00:00:00Z" + } + ] + }' +``` + +Pour envoyer un flux volumineux plus efficacement, compressez le corps et définissez `Content-Encoding: gzip`. + +### Limites de débit {#rate-limits} + +L'endpoint accepte 10 requêtes par seconde pour chaque clé d'API. Les requêtes dépassant cette limite reçoivent une réponse `429 Too Many Requests`. + +### Réponses d'erreur {#error-responses} + +| Statut | Raison | +|---|---| +| `400 Bad Request` | Le corps n'est pas un JSON valide, le bundle contient un `spec_version` autre que `2.1`, l'en-tête `ti_vendor` est manquant ou invalide, ou le `Content-Encoding` n'est pas pris en charge. | +| `401 Unauthorized` | La requête ne contient pas d'identifiants valides. | +| `403 Forbidden` | La clé d'application ne dispose pas de l'autorisation Reference Tables Write. | +| `413 Request Entity Too Large` | Le corps de la requête est supérieur à 50 Mo. | +| `429 Too Many Requests` | La requête a dépassé la limite de débit pour la clé d'API. | + +## Configurer les Reference Tables générées {#configure-the-generated-reference-tables} + +Gérez les tableaux générés par l'ingestion sur la page de configuration [Threat Intelligence][7]. Chaque tableau dispose d'un interrupteur qui contrôle si Cloud SIEM l'utilise pour enrichir les logs. Utilisez cette page pour examiner quels flux sont actifs, pour désactiver temporairement un flux ou pour activer un tableau que l'ingestion a laissé désactivé. + +Vos paramètres d'enrichissement ont priorité sur l'ingestion. Une fois qu'un tableau existe, les requêtes ultérieures ajoutent et mettent à jour des indicateurs, mais ne modifient jamais le commutateur d'enrichissement. Un tableau que vous désactivez reste désactivé jusqu'à ce que vous l'activiez à nouveau. + +L'ingestion STIX gère les lignes dans les Reference Tables générées. Les modifications manuelles apportées à ces lignes ne sont pas conservées et sont écrasées par les requêtes d'ingestion ultérieures. Pour ajouter, mettre à jour ou supprimer des indicateurs, envoyez les modifications via l'endpoint d'ingestion STIX. + +Pour inspecter les indicateurs ingérés, ouvrez le tableau depuis [Reference Tables][8], ou recherchez les indicateurs dans [IOC Explorer][3]. + +### Si vous atteignez la limite de Reference Tables {#if-you-reach-the-reference-table-limit} + +Cloud SIEM enrichit les logs avec jusqu'à 10 Reference Tables de renseignement sur les menaces à la fois. Si l'ingestion génère un tableau alors que votre organisation a déjà atteint cette limite, Datadog crée et remplit tout de même le tableau. Il n'active pas automatiquement le tableau pour l'enrichissement, et le tableau apparaît sur la page [Threat Intelligence][7] dans un état désactivé. + +Pour activer un tel tableau, désactivez un tableau dont vous n'avez plus besoin sur la page [Threat Intelligence][7], puis activez la nouvelle. + +## Arrêtez l'ingestion d'un flux {#stop-ingesting-a-feed} + +Vos requêtes pilotent l'ingestion, donc la suppression d'un flux nécessite deux étapes, dans cet ordre : + +1. Arrêtez d'envoyer des bundles pour ce `ti_vendor`. +2. Supprimez les Reference Tables que Datadog a générées pour le flux depuis [Reference Tables][8]. + +Effectuez les étapes dans cet ordre. Si vous supprimez un tableau alors que des requêtes pour le même `ti_vendor` arrivent toujours, la requête suivante génère à nouveau le tableau. + +Pour arrêter d'enrichir les logs sans rien supprimer, désactivez plutôt les tableaux sur la page [Threat Intelligence][7]. Cela permet de conserver les indicateurs ingérés à la disposition de l'IOC Explorer et de reprendre l'enrichissement plus tard. + +## Pour aller plus loin {#further-reading} + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://docs.oasis-open.org/cti/stix/v2.1/os/stix-v2.1-os.html +[2]: /fr/security/cloud_siem/ingest_and_enrich/threat_intelligence/ +[3]: /fr/security/cloud_siem/triage_and_investigate/ioc_explorer/ +[4]: /fr/reference_tables/ +[5]: /fr/account_management/api-app-keys/#api-keys +[6]: /fr/account_management/api-app-keys/#application-keys +[7]: https://app.datadoghq.com/security/configuration/threat-intel +[8]: https://app.datadoghq.com/reference-tables \ No newline at end of file diff --git a/hugo/content/fr/security/code_security/iac_security/custom_rules/guide.md b/hugo/content/fr/security/code_security/iac_security/custom_rules/guide.md new file mode 100644 index 00000000000..33dc41c7f7e --- /dev/null +++ b/hugo/content/fr/security/code_security/iac_security/custom_rules/guide.md @@ -0,0 +1,296 @@ +--- +description: Référez-vous au contrat Rego, aux entrées analysées, aux bibliothèques + partagées, aux champs de résultats et aux pratiques de test pour les règles IaC + personnalisées. +title: Référence des règles IaC personnalisées +--- +Cette référence pour les règles personnalisées IaC décrit le contrat de règle, les entrées analysées et les modèles spécifiques à la plateforme. + +Pour obtenir des conseils sur la création de règles personnalisées et un exemple de création de règle à partir de zéro, consultez [Règles personnalisées IaC][2]. + +## Contrat de règle {#rule-contract} + +Datadog évalue les règles personnalisées en tant que [Rego][1] v1. Chaque règle personnalisée doit : + +- Déclarer `package datadog`. +- Définir au moins une règle d'ensemble partiel nommée `DatadogPolicy`. + + Vous pouvez définir plusieurs `DatadogPolicy` règles dans la même politique. Chaque évaluation réussie produit un résultat distinct. + +- Ajoutez un `result` objet à `DatadogPolicy` pour chaque violation. +- Définissez chaque [champ de résultat requis](#result-fields). + +Cette règle Terraform satisfait au contrat : + +```rego +package datadog + +import data.generic.terraform as tf_lib + +DatadogPolicy contains result if { + some i, name + resource := input.document[i].resource.aws_s3_bucket[name] + resource.acl == "public-read" + + result := { + "documentId": input.document[i].id, + "resourceType": "aws_s3_bucket", + "resourceName": tf_lib.resolve_s3_bucket_name(resource, name), + "searchKey": sprintf("aws_s3_bucket[%s].acl", [name]), + } +} +``` + +## Entrée analysée {#parsed-input} + +Datadog analyse le fichier exemple et l'expose à Rego sous `input.document`. Chaque élément contient un `id` et des champs spécifiques à la plateforme. Exemple : + +```rego +some i, document in input.document +``` + +Pour chaque plateforme, définissez `documentId` sur le `id` du document analysé qui a produit le résultat. La plateforme détermine comment parcourir le reste du document, et non comment dériver `documentId`. + +Rego traite une référence à un champ manquant comme indéfinie. Une expression d'égalité sur un champ indéfini ne produit pas de résultat. Utilisez `object.get`, `not` ou des assistants tels que `data.generic.common.valid_key` lorsqu'une règle doit distinguer les attributs manquants des valeurs explicites. + +## Champs de résultat {#result-fields} + +| Champ | Requis | Description | +| ----- | -------- | ----------- | +| `documentId` | Oui | La `id` du document analysé qui contient la violation. | +| `resourceType` | Oui | Le type réel de ressource signalé, tel que `aws_s3_bucket`, `Pod` ou `AWS::S3::Bucket`. | +| `resourceName` | Oui | Un nom utile pour la ressource, tel qu'une étiquette de ressource Terraform, un nom de métadonnées Kubernetes ou un ID logique CloudFormation. | +| `searchKey` | Oui | Un localisateur spécifique à la plateforme pour le contenu source à mettre en évidence. | +| `remediation` | Non | Une modification de la source applicable par machine. Définissez-le avec `remediationType`. | +| `remediationType` | Non | L'opération appliquée par la remédiation. Définissez-le avec `remediation`. | + +La section `## Remediation` dans la description de la règle est un guide lisible par l'humain. Les champs de résultat optionnels `remediation` et `remediationType` décrivent une modification automatique de la source. + +### Formats de remédiation {#remediation-formats} + +Utilisez `addition` pour insérer un attribut ou un bloc manquant. Définissez `remediation` sur le texte source à insérer : + +```rego +"remediation": "versioning {\n\tenabled = true\n}", +"remediationType": "addition", +``` + +Utilisez `replacement` pour modifier une valeur existante. Encodez la valeur actuelle acceptée et son remplacement : + +```rego +"remediation": json.marshal({ + "before": "Suspended", + "after": "Enabled", +}), +"remediationType": "replacement", +``` + +Utilisez `removal` pour supprimer le contenu identifié par l'emplacement du résultat. Définissez `remediation` sur une brève explication de ce qui est supprimé : + +```rego +"remediation": "Remove the insecure resource.", +"remediationType": "removal", +``` + +Si une règle ne permet pas de fournir une modification automatisée fiable, omettez les deux champs de remédiation et expliquez la correction manuelle dans la description de la règle. + +### Emplacements de résultat {#finding-locations} + +`searchKey` est un localisateur de source spécifique au scanner, et non un chemin Rego. Son format dépend de la plateforme. + +Sur plusieurs plateformes, les règles par défaut enveloppent les valeurs insérées dans des doubles accolades à l'intérieur de la chaîne de format, par exemple sprintf("run={{%s}}", [run]). Cela produit des localisateurs tels que `run="{{checkout}}`. The platform input patterns include equivalent `concat` or nested `sprintf` des constructions que vous pouvez coller dans l'éditeur. + +Utilisez l'emplacement stable le plus précis disponible : + +- Pointez vers l'attribut non sécurisé exact lorsqu'il existe. +- Pour un attribut manquant, pointez vers la ressource ou le bloc de propriétés contenant. +- Incluez les valeurs d'identification avec `={{...}}` lorsqu'un fichier peut contenir des clés répétées. +- Incluez l'identité de la charge de travail, de la tâche, de la phase, du job ou du conteneur lors du signalement d'un objet imbriqué. + +Des localisateurs imprécis tels que `"tasks"` ou `"metadata.name"` peuvent mettre en surbrillance la mauvaise ligne lorsqu'un fichier contient plusieurs ressources ou conteneurs. Utilisez le marqueur de l'éditeur pour vérifier l'emplacement par rapport à un échantillon représentatif. + +## Bibliothèques partagées {#shared-libraries} + +Les règles personnalisées peuvent importer des bibliothèques Datadog communes et spécifiques à la plateforme : + +```rego +import data.generic.common as common_lib +import data.generic.terraform as tf_lib +``` + +Ces paquets de plateforme sont disponibles : + +- `data.generic.ansible` +- `data.generic.cicd` +- `data.generic.cloudformation` +- `data.generic.dockerfile` +- `data.generic.k8s` +- `data.generic.terraform` + +Les bibliothèques partagées gèrent un comportement difficile à reproduire avec un accès direct aux champs. Les exemples incluent les alias de module Ansible, les formulaires de déclenchement GitHub Actions, les spécifications de pod de charge de travail Kubernetes, les noms de ressources Terraform et les références CloudFormation. + +## Modèles d'entrée de plateforme {#platform-input-patterns} + +Les exemples de cette section présentent des modèles orientés production issus de règles par défaut. Les politiques de démarrage dans l'éditeur sont volontairement plus petites et peuvent ne traiter que l'exemple fourni. Lorsqu'une règle par défaut évalue une ressource similaire, clonez-la pour préserver ses helpers de plateforme, son emplacement source et ses contraintes de corrélation de ressources. + +### Ansible {#ansible} + +Les modules Ansible peuvent apparaître sous des noms courts, des noms de collection entièrement qualifiés et d'autres alias. Utilisez la bibliothèque Ansible pour itérer sur les tâches et les variantes de module : + +```rego +import data.generic.ansible as ans_lib + +canonical := "uri" + +some id, task_index +task := ans_lib.tasks[id][task_index] +some variant in ans_lib.variants_for(canonical) +module := task[variant] +ans_lib.checkState(module) +``` + +Utilisez le nom de module canonique comme `resourceType`, `ans_lib.resource_name` pour le nom de la ressource, et incluez la tâche et la variante de module dans `searchKey`. Les règles par défaut utilisent souvent une chaîne de format unique telle que sprintf("name={{%s}}.{{%s}}.url", [task.name, variant]). La construction équivalente est : + +```rego +"searchKey": sprintf("name=%s.%s.url", [ + concat("", ["{{", task.name, "}}"]), + concat("", ["{{", variant, "}}"]), +]) +``` + +### CI/CD {#cicd} + +Les règles personnalisées CI/CD évaluent les workflows GitHub Actions. Les déclencheurs de workflow peuvent être des chaînes, des tableaux ou des objets ; utilisez donc la bibliothèque CI/CD plutôt que de supposer une forme YAML unique : + +```rego +import data.generic.cicd as cicd_lib + +some document in input.document +cicd_lib.check_provider(document) == "github" +cicd_lib.has_dangerous_trigger(document) +``` + +Les règles par défaut utilisent des types de ressources tels que `github_action`, `github_workflow`, `github_job` et `github_step`. Pour les valeurs d'étape, un localisateur littéral tel que sprintf("uses={{%s}}", [uses]) identifie la ligne source exacte. + +### AWS CloudFormation {#aws-cloudformation} + +Les ressources CloudFormation sont indexées par ID logique sous `Resources` : + +```rego +import data.generic.cloudformation as cf_lib + +some document in input.document +some logical_id, resource in document.Resources +resource.Type == "AWS::S3::Bucket" +``` + +Utilisez `resource.Type` comme type de ressource et `cf_lib.resource_name(resource, logical_id)` pour le nom. Une propriété manquante peut être ancrée à son bloc conteneur : + +```rego +"searchKey": sprintf("Resources.%s.Properties", [logical_id]) +``` + +### Dockerfile {#dockerfile} + +Les instructions Dockerfile sont regroupées sous `document.command` par phase de construction : + +```rego +import data.generic.dockerfile as dockerfile_lib + +some i, stage +instruction := input.document[i].command[stage][_] +instruction.Cmd == "add" +not dockerfile_lib.arrayContains(instruction.Value, {".tar", ".tar."}) +``` + +Incluez la phase de construction et l'instruction originale dans le localisateur. Les règles par défaut utilisent souvent sprintf("FROM={{%s}}.{{%s}}", [stage, instruction.Original]): + +```rego +"searchKey": sprintf("FROM=%s.%s", [ + concat("", ["{{", stage, "}}"]), + concat("", ["{{", instruction.Original, "}}"]), +]) +``` + +### Kubernetes {#kubernetes} + +Les vérifications Kubernetes s'appliquent souvent aux Pods et aux spécifications de pod imbriquées dans des charges de travail telles que les Deployments. Utilisez `spec_info` pour localiser la spécification de pod effective : + +```rego +import data.generic.k8s as k8s_lib + +some document in input.document +spec_info := k8s_lib.spec_info(document) +some container in spec_info.spec.containers +container.securityContext.privileged == true +``` + +Incluez le nom de la charge de travail, le chemin de la spécification du pod, le nom du conteneur et le champ non sécurisé dans `searchKey`. Les règles par défaut utilisent souvent sprintf("metadata.name={{%s}}.%s.containers.name={{%s}}.securityContext.privileged", [document.metadata.name, spec_info.path, container.name]): + +```rego +"searchKey": sprintf( + "metadata.name=%s.%s.containers.name=%s.securityContext.privileged", + [ + concat("", ["{{", document.metadata.name, "}}"]), + spec_info.path, + concat("", ["{{", container.name, "}}"]), + ], +) +``` + +Vérifiez `initContainers` séparément lorsque la même exigence s'applique aux conteneurs d'initialisation. + +### Terraform {#terraform} + +Les ressources Terraform sont regroupées par type de ressource et par étiquette : + +```rego +some i, name +resource := input.document[i].resource.aws_s3_bucket[name] +``` + +Utilisez le type de ressource du fournisseur comme `resourceType`. Les helpers de plateforme peuvent résoudre les noms des ressources qui utilisent des champs tels que `bucket`, `cluster_id` ou `name`: + +```rego +import data.generic.terraform as tf_lib + +"resourceName": tf_lib.resolve_s3_bucket_name(resource, name) +``` + +Les valeurs `searchKey` de Terraform commencent généralement par le type de ressource et l'étiquette : + +```rego +"searchKey": sprintf("aws_s3_bucket[%s].acl", [name]) +``` + +Les versions des fournisseurs peuvent déplacer la configuration dans des ressources distinctes. Utilisez une règle par défaut équivalente comme point de départ lorsque le check doit couvrir plusieurs versions de fournisseur, modules, ressources associées ou JSON de plan Terraform. Une règle qui vérifie uniquement une valeur d'attribut explicite, telle que le statut de versionnage `Suspended`, ne détecte pas les ressources manquantes. + +## Corrélation des ressources {#resource-correlation} + +Certaines vérifications comparent plusieurs ressources, modules, jobs ou charges de travail. Évitez les jointures sans contrainte dans `input.document`, car elles peuvent associer des ressources non liées et produire des résultats en double. + +Préservez les contraintes de document, d'espace de noms, de workflow, de phase de construction et de référence de ressource lors de l'adaptation d'une règle existante. + +## Couverture de test {#test-coverage} + +Testez au moins les éléments suivants : + +- Une configuration qui doit produire un résultat. +- Une configuration conforme qui ne doit pas produire de résultat. +- Valeurs manquantes et explicites lorsque les valeurs par défaut sont importantes. +- Ressources multiples dans un seul fichier. +- Syntaxe alternative prise en charge par la plateforme, telle que les alias de module Ansible ou les formulaires de déclenchement GitHub Actions. +- Ressources associées dans des portées distinctes lorsque la règle effectue une corrélation. + +## Validation {#validation} + +L'éditeur vérifie plus que la syntaxe Rego. Avant d'évaluer un échantillon, Datadog vérifie que la politique répond aux exigences de la section [Contrat de règle](#rule-contract), et en outre qu'elle : + +- Utilise le nombre correct d'arguments dans les appels `sprintf`. +- Compile avec les bibliothèques communes et celles de la plateforme sélectionnée. +- N'appelle pas de fonctions intégrées restreintes telles que `http.send` ou `opa.runtime`. + +Corrigez toutes les erreurs signalées avant d'interpréter une évaluation sans résultat. Les erreurs de validation signifient que la politique n'a pas été exécutée avec succès. + +[1]: https://www.openpolicyagent.org/docs/policy-language +[2]: /fr/security/code_security/iac_security/custom_rules/ \ No newline at end of file diff --git a/hugo/content/fr/security/code_security/static_analysis/setup/_index.md b/hugo/content/fr/security/code_security/static_analysis/setup/_index.md index 0210e203388..405a18d8fc3 100644 --- a/hugo/content/fr/security/code_security/static_analysis/setup/_index.md +++ b/hugo/content/fr/security/code_security/static_analysis/setup/_index.md @@ -10,55 +10,56 @@ aliases: - /fr/static_analysis - /fr/security/code_security/static_analysis/circleci_orbs/ - /fr/code_analysis/static_analysis/setup/ -description: Découvrez l'analyse de code statique Datadog pour scanner le code à la - recherche de problèmes de qualité et de vulnérabilités de sécurité avant que votre - code n'atteigne la production. +description: Découvrez Datadog Static Code Analysis pour analyser votre code à la + recherche de problèmes de qualité et de vulnérabilités de sécurité avant qu'il n'atteigne + la production. is_beta: false -title: Configurez l'analyse de code statique (SAST) +title: Configurer l'analyse de code statique (SAST) --- {{% site-region region="gov,gov2" %}}
- La sécurité du code n'est pas disponible pour le {{< region-param key="dd_site_name" >}} site. + Code Security n'est pas disponible pour le {{< region-param key="dd_site_name" >}} site.
{{% /site-region %}} -## Aperçu {#overview} -Pour configurer Datadog SAST dans l'application, accédez à [**Sécurité** > **Sécurité du code**][1]. +## Présentation {#overview} +Pour configurer Datadog SAST dans l'application, accédez à [{{< ui >}}Security{{< /ui >}} > {{< ui >}}Code Security{{< /ui >}}][1]. -## Sélectionnez où exécuter les analyses de code statique {#select-where-to-run-static-code-analysis-scans} -### Scannez avec le scan hébergé par Datadog {#scan-with-datadog-hosted-scanning} +## Sélectionnez l'endroit où exécuter les analyses de code statique {#select-where-to-run-static-code-analysis-scans} +### Analyser avec l'analyse hébergée par Datadog {#scan-with-datadog-hosted-scanning} -Vous pouvez exécuter des analyses de code statique Datadog (SAST) directement sur l'infrastructure Datadog. Les types de dépôts pris en charge incluent : -- [GitHub][18] (à l'exclusion des dépôts utilisant [Git Large File Storage][17]) -- [GitLab.com et GitLab auto-hébergé][20] +Vous pouvez exécuter Datadog Static Code Analysis (SAST) directement sur l'infrastructure Datadog. Les types de référentiels pris en charge incluent : +- [GitHub][18] (à l'exclusion des référentiels qui utilisent [Git Large File Storage][17]) +- [GitLab.com et GitLab Self-Managed][20] - [Azure DevOps][19] +- [Bitbucket Cloud][21] -Pour commencer, accédez à la page [**Sécurité du code**][1]. +Pour commencer, accédez à la [{{< ui >}}Code Security{{< /ui >}} page][1]. -### Scannez dans les pipelines CI {#scan-in-ci-pipelines} -L'analyse de code statique Datadog s'exécute dans vos pipelines CI en utilisant le [`datadog-ci` CLI][8]. +### Analyser dans les pipelines CI {#scan-in-ci-pipelines} +Datadog Static Code Analysis s'exécute dans vos pipelines CI à l'aide de la [`datadog-ci` CLI][8]. -Tout d'abord, configurez vos clés API et d'application Datadog. Ajoutez `DD_APP_KEY` et `DD_API_KEY` en tant que secrets. Veuillez vous assurer que votre clé d'application Datadog a le scope `code_analysis_read`. +Configurez d'abord vos clés d'API et d'application Datadog. Ajoutez `DD_APP_KEY` et `DD_API_KEY` en tant que secrets. Veuillez vous assurer que votre clé d'application Datadog dispose du périmètre `code_analysis_read`. -Ensuite, exécutez l'analyse de code statique en suivant les instructions pour votre fournisseur CI choisi ci-dessous. +Ensuite, exécutez l'analyse de code statique en suivant les instructions ci-dessous pour le fournisseur CI de votre choix. -{{< whatsnext desc="Voir les instructions en fonction de votre fournisseur CI :">}} +{{< whatsnext desc="Consultez les instructions en fonction de votre fournisseur CI :">}} {{< nextlink href="security/code_security/static_analysis/setup/github_actions" >}}GitHub Actions{{< /nextlink >}} {{< nextlink href="security/code_security/static_analysis/setup/generic_ci_providers" >}}Fournisseurs de CI génériques{{< /nextlink >}} {{< /whatsnext >}} ## Sélectionnez votre fournisseur de gestion de code source {#select-your-source-code-management-provider} -L'analyse statique de code Datadog prend en charge tous les fournisseurs de gestion de code source, avec un support natif pour GitHub, GitLab et Azure DevOps. +Datadog Static Code Analysis prend en charge tous les fournisseurs de gestion de code source, avec une prise en charge native pour GitHub, GitLab, Azure DevOps et Bitbucket Cloud Premium. {{< tabs >}} {{% tab "GitHub" %}} -Configurez une application GitHub avec le [carreau d'intégration GitHub][1] et mettez en place l'[intégration de code source][2] pour activer les extraits de code en ligne et les [commentaires sur les demandes de tirage][3]. +Configurez une application GitHub avec la [tuile d'intégration GitHub][1] et configurez l'[intégration du code source][2] pour activer les extraits de code en ligne et les [commentaires sur les demandes de tirage][3]. -Lors de l'installation d'une application GitHub, les autorisations suivantes sont requises pour activer certaines fonctionnalités : +Lors de l'installation d'une application GitHub, les autorisations suivantes sont requises pour activer certaines fonctionnalités : - `Content: Read`, ce qui vous permet de voir les extraits de code affichés dans Datadog -- `Pull Request: Read & Write`, ce qui permet à Datadog d'ajouter des commentaires pour les violations directement dans vos demandes de tirage en utilisant les [commentaires sur les demandes de tirage][3], ainsi que d'ouvrir des demandes de tirage pour [corriger les vulnérabilités][4] +- `Pull Request: Read & Write`, ce qui permet à Datadog d'ajouter des commentaires sur les violations directement dans vos demandes de tirage à l'aide de [commentaires sur les demandes de tirage][3], ainsi que d'ouvrir des demandes de tirage pour [corriger les vulnérabilités][4] - `Checks: Read & Write`, ce qui vous permet de créer des vérifications sur les violations SAST pour bloquer les demandes de tirage [1]: /fr/integrations/github/#link-a-repository-in-your-organization-or-personal-account @@ -69,16 +70,16 @@ Lors de l'installation d'une application GitHub, les autorisations suivantes son {{% /tab %}} {{% tab "GitLab" %}} -Voir les [instructions de configuration du code source GitLab][1] pour connecter les dépôts GitLab à Datadog. Les instances GitLab.com et auto-hébergées sont prises en charge. +Consultez les [instructions de configuration du code source GitLab][1] pour connecter des dépôts GitLab à Datadog. Les instances GitLab.com et autogérées sont prises en charge. [1]: /fr/integrations/gitlab-source-code/#setup {{% /tab %}} {{% tab "Azure DevOps" %}} -**Remarque :** Vos intégrations Azure DevOps doivent être connectées à un locataire Microsoft Entra. Azure DevOps Server n'est **pas** pris en charge. +**Remarque :** Vos intégrations Azure DevOps doivent être connectées à un locataire Microsoft Entra. Azure DevOps Server **n'est pas** pris en charge. -Voir les [instructions de configuration du code source Azure][4] pour connecter les dépôts Azure DevOps à Datadog. +Consultez les [instructions de configuration du code source Azure][4] pour connecter des dépôts Azure DevOps à Datadog. [1]: https://app.datadoghq.com/security/configuration/code-security/setup [2]: https://portal.azure.com/#view/Microsoft_AAD_RegisteredApps/ApplicationsListBlade @@ -86,31 +87,38 @@ Voir les [instructions de configuration du code source Azure][4] pour connecter [4]: /fr/integrations/azure-devops-source-code/#setup [5]: /fr/getting_started/site/ +{{% /tab %}} +{{% tab "Bitbucket Cloud" %}} + +Consultez les [instructions de configuration du code source Bitbucket][1] pour connecter des espaces de travail Bitbucket Cloud à Datadog. + +[1]: /fr/integrations/bitbucket-source-code/#setup + {{% /tab %}} {{% tab "Other" %}} -Si vous utilisez un autre fournisseur de gestion de code source, configurez l'analyse statique de code pour s'exécuter dans vos pipelines CI en utilisant l'outil `datadog-ci` CLI et [ téléchargez les résultats](#upload-third-party-static-analysis-results-to-datadog) sur Datadog. -Vous **devez** exécuter une analyse de votre dépôt sur la branche par défaut avant que les résultats ne commencent à apparaître sur la page **Sécurité du code**. +Si vous utilisez un autre fournisseur de gestion de code source, configurez l'analyse de code statique pour qu'elle s'exécute dans vos pipelines CI à l'aide de l'outil CLI `datadog-ci` et [téléchargez les résultats](#upload-third-party-static-analysis-results-to-datadog) vers Datadog. +Vous **devez** exécuter une analyse de votre dépôt sur la branche par défaut avant que les résultats ne puissent commencer à apparaître sur la page {{< ui >}}Code Security{{< /ui >}}. {{% /tab %}} {{< /tabs >}} ## Personnalisez votre configuration {#customize-your-configuration} -Par défaut, l'analyse statique de code Datadog (SAST) analyse vos dépôts avec les [ensembles de règles par défaut de Datadog][6] pour chaque langage de programmation. Vous pouvez personnaliser les ensembles de règles ou les règles qui s'exécutent, ainsi que d'autres paramètres, dans Datadog ou dans un fichier `code-security.datadog.yaml`. Pour la référence complète de configuration, voir [Configuration de l'analyse statique de code (SAST)][27]. +Par défaut, l'analyse de code statique (SAST) de Datadog analyse vos dépôts avec les [ensembles de règles par défaut de Datadog][6] pour chaque langage de programmation. Vous pouvez personnaliser les ensembles de règles ou les règles qui s'exécutent, ainsi que d'autres paramètres, dans Datadog ou dans un fichier `code-security.datadog.yaml`. Pour obtenir la référence complète de la configuration, consultez [Configuration de l'analyse de code statique (SAST)][27]. ## Liez les résultats aux services et équipes Datadog {#link-findings-to-datadog-services-and-teams} {{% security-products/link-findings-to-datadog-services-and-teams %}} -## Analyse sensible aux différences {#diff-aware-scanning} +## Analyse différentielle {#diff-aware-scanning} -L'analyse sensible aux différences permet à l'analyseur statique de Datadog de ne scanner que les fichiers modifiés par un commit dans une branche de fonctionnalité. Cela accélère considérablement le temps de scan en évitant d'exécuter l'analyse sur chaque fichier du dépôt pour chaque scan. Pour activer l'analyse sensible aux différences dans votre pipeline CI, suivez ces étapes : +L'analyse différentielle permet à l'analyseur statique de Datadog de n'analyser que les fichiers modifiés par un commit dans une branche de fonctionnalité. Elle accélère considérablement le temps d'analyse en évitant d'exécuter l'analyse sur chaque fichier du dépôt à chaque scan. Pour activer l'analyse différentielle dans votre pipeline CI, suivez ces étapes : 1. Assurez-vous que vos variables `DD_APP_KEY`, `DD_SITE` et `DD_API_KEY` sont définies dans votre pipeline CI. 2. Ajoutez un appel à `datadog-ci git-metadata upload` avant d'invoquer l'analyseur statique. Cette commande garantit que les métadonnées Git sont disponibles pour le backend Datadog. Les métadonnées Git sont nécessaires pour calculer le nombre de fichiers à analyser. -3. Assurez-vous que l'analyseur statique Datadog est invoqué avec le drapeau `--diff-aware`. +3. Assurez-vous que le datadog-static-analyzer est invoqué avec l'indicateur `--diff-aware`. Exemple de séquence de commandes (ces commandes doivent être invoquées dans votre dépôt Git) : @@ -120,19 +128,19 @@ datadog-ci git-metadata upload datadog-static-analyzer -i /path/to/directory -g -o sarif.json -f sarif –-diff-aware <...other-options...> ``` -**Remarque :** Lorsqu'un scan sensible aux différences ne peut pas être complété, l'ensemble du répertoire est scanné. +**Remarque :** Lorsqu'une analyse différentielle ne peut pas être effectuée, le répertoire entier est analysé. -## Téléchargez les résultats d'analyse statique tiers sur Datadog {#upload-third-party-static-analysis-results-to-datadog} +## Téléverser les résultats d'analyse statique tiers vers Datadog {#upload-third-party-static-analysis-results-to-datadog}
- L'importation SARIF a été testée pour Snyk, CodeQL, Semgrep, Gitleaks et Sysdig. Contactez le support Datadog si vous rencontrez des problèmes avec d'autres outils conformes à SARIF. + L'importation SARIF a été testée pour Snyk, CodeQL, Semgrep, Gitleaks et Sysdig. Contactez le support Datadog si vous rencontrez des problèmes avec d'autres outils compatibles SARIF.
-Vous pouvez envoyer les résultats des outils d'analyse statique tiers à Datadog, à condition qu'ils soient au format interopérable [Format d'échange des résultats d'analyse statique (SARIF)][2]. La version 14 ou ultérieure de Node.js est requise. +Vous pouvez envoyer les résultats d'outils d'analyse statique tiers à Datadog, à condition qu'ils soient au format interopérable [Static Analysis Results Interchange Format (SARIF) Format][2]. Node.js version 14 ou ultérieure est requis. Pour importer un rapport SARIF, procédez comme suit : -1. Assurez-vous que les [`DD_API_KEY` et `DD_APP_KEY` variables sont définies][4]. +1. Assurez-vous que les variables [`DD_API_KEY` et `DD_APP_KEY` sont définies][4]. 2. Optionnellement, définissez une [`DD_SITE` variable][7] (la valeur par défaut est `datadoghq.com`). 3. Installez l'utilitaire `datadog-ci` : @@ -140,29 +148,29 @@ Pour importer un rapport SARIF, procédez comme suit : npm install -g @datadog/datadog-ci ``` -4. Exécutez l'outil d'analyse statique tiers sur votre code et exportez les résultats au format SARIF. -5. Téléchargez les résultats sur Datadog : +4. Exécutez l'outil d'analyse statique tiers sur votre code et générez les résultats au format SARIF. +5. Téléversez les résultats vers Datadog : ```bash datadog-ci sarif upload $OUTPUT_LOCATION ``` -## Directives de support SARIF {#sarif-support-guidelines} +## Directives de prise en charge SARIF {#sarif-support-guidelines} Datadog prend en charge l'ingestion de fichiers SARIF tiers conformes au [schéma SARIF 2.1.0][15]. Le SARIF -le schéma est utilisé différemment par les outils d'analyse statique. Si vous souhaitez envoyer des fichiers SARIF tiers à Datadog, veuillez -vous assurer qu'ils respectent les détails suivants : +schéma est utilisé différemment par les outils d'analyse statique. Si vous souhaitez envoyer des fichiers SARIF tiers à Datadog, veuillez +vous assurer qu'ils respectent les détails suivants : - - L'emplacement de la violation est spécifié par l'objet `physicalLocation` d'un résultat. + - L'emplacement de la violation est spécifié via l'objet `physicalLocation` d'un résultat. - Le `artifactLocation` et son `uri` **doivent être relatifs** à la racine du dépôt. - L'objet `region` est la partie du code mise en évidence dans l'interface utilisateur de Datadog. - Le `partialFingerprints` est utilisé pour identifier de manière unique une découverte dans un dépôt. - - `properties` et `tags` ajoutent plus d'informations : - - L'étiquette `DATADOG_CATEGORY` spécifie la catégorie de la découverte. Les valeurs acceptables sont `SECURITY`, `PERFORMANCE`, `CODE_STYLE`, `BEST_PRACTICES`, `ERROR_PRONE`. - - Les violations annotées avec la catégorie `SECURITY` sont affichées dans l'explorateur de vulnérabilités et l'onglet Sécurité de la vue du dépôt. - - La section `tool` doit avoir une section `driver` valide avec des attributs `name` et `version`. + - `properties` et `tags` ajoutent plus d'informations : + - Le tag `DATADOG_CATEGORY` spécifie la catégorie de la découverte. Les valeurs acceptables sont `SECURITY`, `PERFORMANCE`, `CODE_STYLE`, `BEST_PRACTICES`, `ERROR_PRONE`. + - Les violations annotées avec la catégorie `SECURITY` sont affichées dans le Vulnerabilities Explorer et l'onglet Security de la vue du dépôt. + - La section `tool` doit comporter une section `driver` valide avec des attributs `name` et `version`. -Par exemple, voici un exemple d'un fichier SARIF traité par Datadog : +Par exemple, voici un exemple de fichier SARIF traité par Datadog : ```json @@ -234,25 +242,25 @@ Par exemple, voici un exemple d'un fichier SARIF traité par Datadog : } ``` -## Mapping de la sévérité SARIF à CVSS {#sarif-to-cvss-severity-mapping} +## Mappage de la sévérité SARIF vers CVSS {#sarif-to-cvss-severity-mapping} -Le [format SARIF][15] définit quatre niveaux de sévérité : aucun, note, avertissement et erreur. -Cependant, Datadog signale les violations et la gravité des vulnérabilités en utilisant le [Système de notation des vulnérabilités communes][16] (CVSS), -qui définit cinq niveaux de gravité : critique, élevé, moyen, faible et aucun. +Le [format SARIF][15] définit quatre niveaux de sévérité : none, note, warning et error. +Cependant, Datadog rapporte la sévérité des violations et des vulnérabilités en utilisant le [Common Vulnerability Scoring System][16] (CVSS), +qui définit cinq niveaux de sévérité : critical, high, medium, low et none. -Lors de l'ingestion de fichiers SARIF, Datadog mappe les niveaux de gravité SARIF aux niveaux de gravité CVSS en utilisant les règles de correspondance ci-dessous. +Lors de l'ingestion de fichiers SARIF, Datadog mappe les sévérités SARIF vers les sévérités CVSS en utilisant les règles de mappage ci-dessous. -| Niveau de gravité SARIF | Niveau de gravité CVSS | +| Sévérité SARIF | Sévérité CVSS | |----------------|---------------| | Erreur | Critique | -| Avertissement | Élevé | -| Remarque | Moyen | -| Aucun | Faible | +| Avertissement | Élevé | +| Remarque | Moyen | +| Aucun | Faible | ## Conservation des données {#data-retention} -Datadog stocke les résultats conformément à nos [Périodes de conservation des données](https://docs.datadoghq.com/fr/data_security/data_retention_periods/). Datadog ne stocke ni ne conserve le code source des clients. +Datadog conserve les résultats conformément à nos [Périodes de conservation des données](https://docs.datadoghq.com/fr/data_security/data_retention_periods/) . Datadog ne stocke ni ne conserve le code source des clients . ##