-Datadog recomienda actualizar el Datadog Agent con cada versión secundaria y de parche. O, al menos, actualizarlo una vez al mes.
+Datadog recomienda actualizar el Datadog Agent con cada versión secundaria y de parche. O bien, al menos, actualizarlo una vez al mes.
Actualizar a una versión principal del Datadog Agent y mantenerla actualizada es la única forma compatible de obtener las últimas funcionalidades y correcciones del Agent. Sin embargo, el Agent cuenta con actualizaciones frecuentes y puede ser todo un reto gestionarlas a escala empresarial. Esto no significa que debas esperar a las versiones principales para actualizarlo. La frecuencia de actualización adecuada para tu organización depende de la infraestructura y la forma de gestionar la configuración, pero lo aconsejable es que sea mensual.
+
+1. Dirígete a **Software Library** > **Overview** > **Application Management** > **Applications** (Biblioteca de software > Descripción general > Gestión de aplicaciones > Aplicaciones) y selecciona la aplicación del Datadog Agent que creaste anteriormente.
+1. En la pestaña **Home** (Inicio), en el grupo **Deployment** (Despliegue), selecciona **Deploy** (Desplegar).
+
+### Configuración del Agent
+
+Los paquetes de SCCM te permiten desplegar archivos de configuración en los Datadog Agents, lo que sobrescribe su configuración predeterminada. La configuración del Agent consta de un archivo de configuración `datadog.yaml` y de archivos `conf.yaml` opcionales para cada integración. Debes crear un paquete para cada archivo de configuración que quieras desplegar.
+
+1. Recopila los archivos `datadog.yaml` y `conf.yaml` en una carpeta de equipo de SCCM local. Consulta el [archivo `config_template.yaml` de ejemplo][4] para ver todas las opciones de configuración disponibles.
+1. Crea un paquete de SCCM y selecciona **Standard program** (Programa estándar).
+1. Selecciona la localización que contiene el archivo de configuración que quieres desplegar en los Agents.
+1. Selecciona una [colección de dispositivos][5] en la que desplegar los cambios.
+1. Configura los ajustes de despliegue para preinstalar el paquete en los destinos de inmediato.
+
+{{< img src="agent/basic_agent_usage/sccm/sccm-select-program.png" alt="La pantalla de tipo de programa. Selecciona Programa estándar" style="width:80%;" >}}
+
+### Reiniciar el Datadog Agent
+
+Reinicia el servicio del Agent para observar los cambios de configuración:
+1. Crea un script de PowerShell para reiniciar el Datadog Agent mediante los [comandos del Agent][6].
+1. Ejecuta el script para reiniciar el Datadog Agent.
+1. Busca datos nuevos en la interfaz de usuario de Datadog.
+
+## Leer más
+
+{{< partial name="whats-next/whats-next.html" >}}
+
+[1]: https://learn.microsoft.com/en-us/mem/configmgr/core/servers/deploy/configure/manage-content-and-content-infrastructure
+[2]: https://app.datadoghq.com/account/settings/agent/latest?platform=windows
+[3]: /es/agent/basic_agent_usage/windows/?tab=commandline#configuration
+[4]: https://github.com/DataDog/datadog-agent/blob/master/pkg/config/config_template.yaml
+[5]: https://learn.microsoft.com/en-us/mem/configmgr/core/clients/manage/collections/create-collections#bkmk_create
+[6]: /es/agent/basic_agent_usage/windows/#agent-commands
\ No newline at end of file
diff --git a/content/es/agent/basic_agent_usage/source.md b/content/es/agent/basic_agent_usage/source.md
index e270a95ea277f..66960369d8e65 100644
--- a/content/es/agent/basic_agent_usage/source.md
+++ b/content/es/agent/basic_agent_usage/source.md
@@ -13,8 +13,8 @@ further_reading:
text: Recopilar tus trazas
- link: /agent/basic_agent_usage/#agent-architecture
tag: Documentación
- text: Obtén más información sobre la arquitectura del Agent
-- link: /agent/guide/network#configure-ports
+ text: Más información sobre la arquitectura del Agent
+- link: /agent/configuration/network#configure-ports
tag: Documentación
text: Configurar puertos de entrada
kind: documentación
@@ -23,7 +23,7 @@ title: Uso básico del Agent para la instalación de origen
---
## Información general
-En esta página, se describen las funciones básicas del Datadog Agent. Si aún no has instalado el Agent, consulta las instrucciones [en la página sobe la integración del Datadog Agent][1].
+En esta página, se describen las funciones básicas del Datadog Agent. Si aún no has instalado el Agent, consulta las instrucciones [en la página sobre la integración del Datadog Agent][1].
Por defecto, tu Agent se instala en su propio entorno de pruebas, ubicado en `~/.datadog-agent`. Puedes mover esta carpeta a cualquier otro lugar con total libertad. Sin embargo, en este artículo se asume que el Agent está instalado en su localización predeterminada, así que asegúrate de adaptar las instrucciones según corresponda si decides moverlo.
@@ -59,7 +59,7 @@ El Datadog Agent cuenta con algunos comandos, y solo deben ejecutarse con `sudo`
## Configuración
{{< tabs >}}
-{{% tab "Agent v6 & v7" %}}
+{{% tab "Agent v6 y v7" %}}
Los archivos y carpetas de configuración del Agent se encuentran en:
* `/etc/datadog-agent/datadog.yaml`
@@ -72,7 +72,7 @@ Archivos de configuración para las [integraciones][1]:
{{% /tab %}}
{{% tab "Agent v5" %}}
-Los archivos y carpetas de configuración para el Agent se encuentran en:
+Los archivos y carpetas de configuración del Agent se encuentran en:
* `/etc/dd-agent/datadog.conf`
@@ -88,9 +88,9 @@ Archivos de configuración para las [integraciones][1]:
Consulta la [documentación sobre cómo solucionar problemas relacionados con el Agent][2].
-
+## Leer más
{{< partial name="whats-next/whats-next.html" >}}
-[1]: https://app.datadoghq.com/account/settings#agent/source
+[1]: https://app.datadoghq.com/account/settings/agent/latest?platform=source
[2]: /es/agent/troubleshooting/
\ No newline at end of file
diff --git a/content/es/agent/basic_agent_usage/suse.md b/content/es/agent/basic_agent_usage/suse.md
index 1a0f67d809be0..fed465db7e60a 100644
--- a/content/es/agent/basic_agent_usage/suse.md
+++ b/content/es/agent/basic_agent_usage/suse.md
@@ -13,8 +13,8 @@ further_reading:
text: Recopilar tus trazas
- link: /agent/basic_agent_usage/#agent-architecture
tag: Documentación
- text: Obtén más información sobre la arquitectura del Agent
-- link: /agent/guide/network#configure-ports
+ text: Más información sobre la arquitectura del Agent
+- link: /agent/configuration/network#configure-ports
tag: Documentación
text: Configurar puertos de entrada
kind: documentación
@@ -54,12 +54,12 @@ En las versiones 6 y 7 del Agent, el gestor de servicios proporcionado por el s
| Descripción | Comando |
|------------------------------------|--------------------------------------------------------|
-| Ejecutar el Agent como un servicio | `sudo service datadog-agent start` |
+| Ejecutar el Agent como servicio | `sudo service datadog-agent start` |
| Detener la ejecución del Agent como servicio | `sudo service datadog-agent stop` |
| Reiniciar la ejecución del Agent como servicio | `sudo service datadog-agent restart` |
| Estado del servicio Agent | `sudo service datadog-agent status` |
| Página de estado del Agent en ejecución | `sudo datadog-agent status` |
-| Enviar un flare | `sudo datadog-agent flare` |
+| Enviar flare | `sudo datadog-agent flare` |
| Mostrar el uso de comandos | `sudo datadog-agent --help` |
| Ejecutar un check | `sudo -u dd-agent -- datadog-agent check ` |
@@ -68,21 +68,21 @@ En las versiones 6 y 7 del Agent, el gestor de servicios proporcionado por el s
| Descripción | Comando |
|------------------------------------|---------------------------------------------------|
-| Ejecutar el Agent como un servicio | `sudo service datadog-agent start` |
+| Ejecutar el Agent como servicio | `sudo service datadog-agent start` |
| Detener la ejecución del Agent como servicio | `sudo service datadog-agent stop` |
| Reiniciar la ejecución del Agent como servicio | `sudo service datadog-agent restart` |
| Estado del servicio Agent | `sudo service datadog-agent status` |
| Página de estado del Agent en ejecución | `sudo service datadog-agent info` |
-| Enviar un flare | `sudo service datadog-agent flare` |
+| Enviar flare | `sudo service datadog-agent flare` |
| Mostrar el uso de comandos | `sudo service datadog-agent` |
| Ejecutar un check | `sudo -u dd-agent -- dd-agent check ` |
{{% /tab %}}
{{< /tabs >}}
-**Nota**: Si el contenedor de servicio `service` no está disponible en tu sistema, utiliza:
+**Nota**: Si el contenedor `service` no está disponible en tu sistema, utiliza:
-* En sistemas basados en `upstart`: `sudo start/stop/restart/status datadog-agent`
+* Para sistemas basados en `upstart`: `sudo start/stop/restart/status datadog-agent`
* Para sistemas basados en `systemd`: `sudo systemctl start/stop/restart/status datadog-agent`
[Obtén más información sobre los comandos del ciclo de vida del servicio][2]
@@ -90,7 +90,7 @@ En las versiones 6 y 7 del Agent, el gestor de servicios proporcionado por el s
## Configuración
{{< tabs >}}
-{{% tab "Agent v6 & v7" %}}
+{{% tab "Agent v6 y v7" %}}
Los archivos y carpetas de configuración del Agent se encuentran en:
* `/etc/datadog-agent/datadog.yaml`
@@ -103,7 +103,7 @@ Archivos de configuración para las [integraciones][1]:
{{% /tab %}}
{{% tab "Agent v5" %}}
-Los archivos y carpetas de configuración para el Agent se encuentran en:
+Los archivos y carpetas de configuración del Agent se encuentran en:
* `/etc/dd-agent/datadog.conf`
@@ -115,21 +115,70 @@ Archivos de configuración para las [integraciones][1]:
{{% /tab %}}
{{< /tabs >}}
+## Desinstalar el Agent
+
+{{< tabs >}}
+{{% tab "Agent v6 y v7" %}}
+```shell
+sudo zypper remove datadog-agent
+```
+
+Este comando borra el Agent, pero no elimina:
+* El archivo de configuración `datadog.yaml`
+* Los archivos que ha creado el usuario en la carpeta de configuración `/etc/datadog-agent`
+* Los archivos que ha creado el usuario en la carpeta `/opt/datadog-agent`
+* El usuario `dd-agent`
+* Archivos de log de Datadog
+
+Si también quieres eliminar estos elementos, ejecuta este comando después de eliminar el Agent:
+
+```shell
+sudo userdel dd-agent \
+&& sudo rm -rf /opt/datadog-agent/ \
+&& sudo rm -rf /etc/datadog-agent/ \
+&& sudo rm -rf /var/log/datadog/
+```
+{{% /tab %}}
+
+{{% tab "Agent v5" %}}
+
+```shell
+sudo zypper remove datadog-agent
+```
+
+Este comando borra el Agent, pero no elimina:
+* El archivo de configuración `datadog.yaml`
+* Los archivos que ha creado el usuario en la carpeta de configuración `/etc/dd-agent`
+* Los archivos que ha creado el usuario en la carpeta `/opt/datadog-agent`
+* El usuario `dd-agent`
+* Archivos de log de Datadog
+
+Si también quieres eliminar estos elementos, ejecuta este comando después de eliminar el Agent:
+
+```shell
+sudo userdel dd-agent \
+&& sudo rm -rf /opt/datadog-agent/ \
+&& sudo rm -rf /etc/dd-agent/ \
+&& sudo rm -rf /var/log/datadog/
+```
+{{% /tab %}}
+{{< /tabs >}}
+
## Solucionar problemas
-Consulta la [documentación sobre cómo solucionar problemas relacionados con el Agent][3].
+Consulta la [documentación sobre cómo solucionar problemas del Agent][3].
## Trabajar con el Agent integrado
-El Agent tiene un entorno Python integrado en `/opt/datadog-agent/embedded/`. Los sistemas binarios comunes como `python` y `pip` se encuentran dentro de `/opt/datadog-agent/embedded/bin/`.
-
-Si deseas obtener más información, consulta las instrucciones sobre cómo [añadir paquetes al Agent integrado][4].
+El Agent tiene un entorno de Python integrado en `/opt/datadog-agent/embedded/`. Los archivos binarios comunes, como `python` y `pip`, se encuentran dentro de `/opt/datadog-agent/embedded/bin/`.
+Si quieres obtener más información, consulta las instrucciones sobre cómo [añadir paquetes al Agent integrado][4].
+## Lectura adicional
{{< partial name="whats-next/whats-next.html" >}}
-[1]: https://app.datadoghq.com/account/settings#agent/suse
+[1]: https://app.datadoghq.com/account/settings/agent/latest?platform=suse
[2]: /es/agent/faq/agent-v6-changes/?tab=linux#service-lifecycle-commands
[3]: /es/agent/troubleshooting/
[4]: /es/developers/guide/custom-python-package/
\ No newline at end of file
diff --git a/content/es/agent/basic_agent_usage/ubuntu.md b/content/es/agent/basic_agent_usage/ubuntu.md
index 9cdc68197acf9..d28042d0f2bf9 100644
--- a/content/es/agent/basic_agent_usage/ubuntu.md
+++ b/content/es/agent/basic_agent_usage/ubuntu.md
@@ -13,8 +13,8 @@ further_reading:
text: Recopilar tus trazas
- link: /agent/basic_agent_usage/#agent-architecture
tag: Documentación
- text: Obtén más información sobre la arquitectura del Agent
-- link: /agent/guide/network#configure-ports
+ text: Más información sobre la arquitectura del Agent
+- link: /agent/configuration/network#configure-ports
tag: Documentación
text: Configurar puertos de entrada
kind: documentación
@@ -24,9 +24,9 @@ title: Uso básico del Agent para Ubuntu
## Información general
-En esta página se describen las funciones básicas del Datadog Agent para Ubuntu. Si aún no has instalado el Agent, consulta las instrucciones en la documentación sobre la [integración del Datadog Agent][1].
+En esta página se describen las características básicas del Datadog Agent para Ubuntu.
-Los paquetes están disponibles para arquitecturas Arm v8 y x86 de 64 bits. Para otras arquitecturas, utiliza la instalación de origen.
+Para instalar el Agent, consulta las [instrucciones de instalación][1]. Los paquetes se encuentran disponibles para arquitecturas Arm v8 y x86 de 64 bits. Para otras arquitecturas, utiliza la instalación de origen.
**Nota**: Las versiones Ubuntu 14.04 y posteriores son compatibles con la arquitectura x86 de 64 bits. Las versiones Ubuntu 16.04 y posteriores son compatibles con la arquitectura Arm v8 de 64 bits.
@@ -100,21 +100,65 @@ Archivos de configuración para las [integraciones][1]:
{{% /tab %}}
{{< /tabs >}}
+## Desinstalar el Agent
+
+{{< tabs >}}
+{{% tab "Agent v6 y v7" %}}
+```shell
+sudo apt-get remove datadog-agent -y
+```
+
+Este comando borra el Agent, pero no elimina:
+
+* El archivo de configuración `datadog.yaml`
+* Los archivos que ha creado el usuario en la carpeta de configuración `/etc/datadog-agent`
+* Los archivos que ha creado el usuario en la carpeta `/opt/datadog-agent`
+* El usuario `dd-agent`
+* Archivos de log de Datadog
+
+Si también quieres eliminar estos elementos, ejecuta este comando después de eliminar el Agent:
+
+```shell
+sudo apt-get remove --purge datadog-agent -y
+```
+{{% /tab %}}
+
+{{% tab "Agent v5" %}}
+```shell
+sudo apt-get remove datadog-agent -y
+```
+
+Este comando borra el Agent, pero no elimina:
+* El archivo de configuración `datadog.yaml`
+* Los archivos que ha creado el usuario en la carpeta de configuración `/etc/dd-agent`
+* Los archivos que ha creado el usuario en la carpeta `/opt/datadog-agent`
+* El usuario `dd-agent`
+* Archivos de log de Datadog
+
+Si también quieres eliminar estos elementos, ejecuta este comando después de eliminar el Agent:
+
+```shell
+sudo apt-get --purge remove datadog-agent -y
+```
+{{% /tab %}}
+{{< /tabs >}}
+
+
## Solucionar problemas
Consulta la [documentación sobre cómo solucionar problemas del Agent][3].
## Trabajar con el Agent integrado
-El Agent tiene un entorno Python integrado en `/opt/datadog-agent/embedded/`. Los sistemas binarios comunes como `python` y `pip` se encuentran dentro de `/opt/datadog-agent/embedded/bin/`.
-
-Si deseas obtener más información, consulta las instrucciones sobre cómo [añadir paquetes al Agent integrado][4].
+El Agent tiene un entorno de Python integrado en `/opt/datadog-agent/embedded/`. Los archivos binarios comunes, como `python` y `pip`, se encuentran dentro de `/opt/datadog-agent/embedded/bin/`.
+Si quieres obtener más información, consulta las instrucciones sobre cómo [añadir paquetes al Agent integrado][4].
+## Lectura adicional
{{< partial name="whats-next/whats-next.html" >}}
-[1]: https://app.datadoghq.com/account/settings#agent/ubuntu
+[1]: https://app.datadoghq.com/account/settings/agent/latest?platform=ubuntu
[2]: /es/agent/faq/agent-v6-changes/?tab=linux#service-lifecycle-commands
[3]: /es/agent/troubleshooting/
[4]: /es/developers/guide/custom-python-package/
\ No newline at end of file
diff --git a/content/es/agent/configuration/_index.md b/content/es/agent/configuration/_index.md
new file mode 100644
index 0000000000000..9ea13a41bc123
--- /dev/null
+++ b/content/es/agent/configuration/_index.md
@@ -0,0 +1,33 @@
+---
+aliases:
+- /es/agent/config
+disable_toc: false
+further_reading:
+- link: /agent/guide/
+ tag: Documentación
+ text: Guías del Agent
+kind: documentación
+title: Configuración del Agent
+---
+
+En esta sección se incluye información sobre la configuración de los Datadog Agents. Para obtener información sobre la configuración remota de los componentes de Datadog, consulta la [configuración remota][1]. En el caso de las instalaciones del contenedor, consulta la [monitorización del contenedor][2]. Para obtener información sobre la configuración de las integraciones de Datadog, consulta las [integraciones][3].
+
+{{< whatsnext desc="Documentación de la configuración del Agent:" >}}
+ {{< nextlink href="agent/configuration/agent-commands/" >}}Comandos del Agent{{< /nextlink >}}
+ {{< nextlink href="agent/configuration/agent-configuration-files/" >}}Archivos de configuración{{< /nextlink >}}
+ {{< nextlink href="agent/configuration/agent-log-files/" >}}Archivos de log{{< /nextlink >}}
+ {{< nextlink href="agent/configuration/agent-status-page/" >}}Página de estado{{< /nextlink >}}
+ {{< nextlink href="agent/configuration/network/" >}}Tráfico de red{{< /nextlink >}}
+ {{< nextlink href="agent/configuration/proxy/" >}}Configuración de proxy{{< /nextlink >}}
+ {{< nextlink href="agent/configuration/agent-fips-proxy/" >}}Cumplimiento de FIPS{{< /nextlink >}}
+ {{< nextlink href="agent/configuration/dual-shipping/" >}}Envío doble{{< /nextlink >}}
+ {{< nextlink href="agent/configuration/secrets-management/" >}}Gestión de secretos{{< /nextlink >}}
+{{< /whatsnext >}}
+
+## Lectura adicional
+
+{{< partial name="whats-next/whats-next.html" >}}
+
+[1]: /es/agent/remote_config/
+[2]: /es/containers/
+[3]: /es/integrations/
\ No newline at end of file
diff --git a/content/es/agent/configuration/agent-commands.md b/content/es/agent/configuration/agent-commands.md
new file mode 100644
index 0000000000000..5a4fd7074a0d1
--- /dev/null
+++ b/content/es/agent/configuration/agent-commands.md
@@ -0,0 +1,288 @@
+---
+algolia:
+ tags:
+ - comando del estado del Agent
+aliases:
+- /es/agent/faq/agent-status-and-information
+- /es/agent/faq/start-stop-restart-the-datadog-agent
+- /es/agent/faq/agent-commands
+- /es/agent/guide/agent-commands
+further_reading:
+- link: /agent/troubleshooting/
+ tag: Documentación
+ text: Solucionar problemas del Agent
+kind: guía
+title: Comandos del Agent
+---
+
+
+En sistemas basados en Linux en los que no se encuentre disponible el comando del contenedor service, consulta la lista de alternativas.
+
+
+## Iniciar, detener y reiniciar el Agent
+
+### Iniciar el Agent
+
+Lista de comandos para iniciar el Datadog Agent:
+
+{{< tabs >}}
+{{% tab "Agent v6 y v7" %}}
+
+| Plataforma | Comando |
+|------------|--------------------------------------------------------------------|
+| AIX | `startsrc -s datadog-agent` |
+| Linux | Consulta la [documentación sobre el Agent][1] para tu sistema operativo. |
+| Docker | Utiliza el [comando de instalación][2]. |
+| Kubernetes | `kubectl create -f datadog-agent.yaml` |
+| macOS | `launchctl start com.datadoghq.agent` *o* a través de la aplicación systray |
+| Origen | `sudo service datadog-agent start` |
+| Windows | Consulta la [documentación sobre el Windows Agent][3]. |
+
+[1]: /es/agent/
+[2]: /es/agent/docker/
+[3]: /es/agent/basic_agent_usage/windows/
+{{% /tab %}}
+{{% tab "Agent v5" %}}
+
+| Plataforma | Comando |
+|----------|-------------------------------------------|
+| Linux | `sudo service datadog-agent start` |
+| Docker | Consulta la [documentación sobre el Docker Agent][1]. |
+| macOS | `/usr/local/bin/datadog-agent start` |
+| Origen | `sudo ~/.datadog-agent/bin/agent start` |
+| Windows | Consulta la [documentación sobre el Windows Agent][2]. |
+
+[1]: https://github.com/DataDog/docker-dd-agent/blob/master/README.md
+[2]: /es/agent/basic_agent_usage/windows/
+{{% /tab %}}
+{{< /tabs >}}
+
+### Detener el Agent
+
+Lista de comandos para detener el Datadog Agent:
+
+{{< tabs >}}
+{{% tab "Agent v6 y v7" %}}
+
+| Plataforma | Comando |
+|------------|----------------------------------------------------------------------------------|
+| AIX | `stopsrc -s datadog-agent` |
+| Linux | Consulta la [documentación sobre el Agent][1] para tu sistema operativo. |
+| Docker | `docker exec -it agent stop` |
+| Kubernetes | `kubectl delete pod `—nota: el pod se reprograma automáticamente |
+| macOS | `launchctl stop com.datadoghq.agent` *o* a través de la aplicación systray |
+| Origen | `sudo service datadog-agent stop` |
+| Windows | Consulta la [documentación sobre el Windows Agent][2]. |
+
+[1]: /es/agent/
+[2]: /es/agent/basic_agent_usage/windows/
+{{% /tab %}}
+{{% tab "Agent v5" %}}
+
+| Plataforma | Comando |
+|----------|-------------------------------------------|
+| Linux | `sudo service datadog-agent stop` |
+| Docker | Consulta la [documentación sobre el Docker Agent][1]. |
+| macOS | `/usr/local/bin/datadog-agent stop` |
+| Origen | `sudo ~/.datadog-agent/bin/agent stop` |
+| Windows | Consulta la [documentación sobre el Windows Agent][2]. |
+
+[1]: https://github.com/DataDog/docker-dd-agent/blob/master/README.md
+[2]: /es/agent/basic_agent_usage/windows/
+{{% /tab %}}
+{{< /tabs >}}
+
+### Reiniciar el Agent
+
+Lista de comandos para reiniciar el Datadog Agent:
+
+{{< tabs >}}
+{{% tab "Agent v6 y v7" %}}
+
+| Plataforma | Comando |
+|------------|----------------------------------------------------------------------------------|
+| Linux | Consulta la [documentación sobre el Agent][1] para tu sistema operativo. |
+| Docker | Utiliza el [comando de instalación][2]. |
+| Kubernetes | `kubectl delete pod `—nota: el pod se reprograma automáticamente |
+| macOS | ejecutar `stop` y luego `start`, *o* a través de la aplicación systray |
+| Origen | *plataforma no compatible* |
+| Windows | Consulta la [documentación sobre el Windows Agent][3]. |
+
+[1]: /es/agent/
+[2]: /es/agent/docker/?tab=standard#setup
+[3]: /es/agent/basic_agent_usage/windows/
+{{% /tab %}}
+{{% tab "Agent v5" %}}
+
+| Plataforma | Comando |
+|----------|-------------------------------------------|
+| Linux | `sudo service datadog-agent restart` |
+| Docker | Consulta la [documentación sobre el Docker Agent][1]. |
+| macOS | `/usr/local/bin/datadog-agent restart` |
+| Origen | `sudo ~/.datadog-agent/bin/agent restart` |
+| Windows | Consulta la [documentación sobre el Windows Agent][2]. |
+
+[1]: https://github.com/DataDog/docker-dd-agent/blob/master/README.md
+[2]: /es/agent/basic_agent_usage/windows/
+{{% /tab %}}
+{{< /tabs >}}
+
+## Estado e información del Agent
+
+### Estado del servicio
+
+Lista de comandos para mostrar el estado del Datadog Agent:
+
+{{< tabs >}}
+{{% tab "Agent v6 y v7" %}}
+
+| Plataforma | Comando |
+|-----------------|-------------------------------------------------------------------------------|
+| AIX | `lssrc -s datadog-agent` |
+| Linux | Consulta la [documentación sobre el Agent][1] para tu sistema operativo. |
+| Docker (Debian) | `sudo docker exec -it s6-svstat /var/run/s6/services/agent/` |
+| Kubernetes | `kubectl exec -it -- s6-svstat /var/run/s6/services/agent/` |
+| macOS | `launchctl list com.datadoghq.agent` *o* a través de la aplicación systray |
+| Origen | `sudo service datadog-agent status` |
+| Windows | Consulta la [documentación sobre el Windows Agent][2]. |
+
+
+[1]: /es/agent/
+[2]: /es/agent/basic_agent_usage/windows/
+{{% /tab %}}
+{{% tab "Agent v5" %}}
+
+| Plataforma | Comando |
+|-----------------|--------------------------------------------------------------------------|
+| Linux | `sudo service datadog-agent status` |
+| Docker (Debian) | `sudo docker exec -it /etc/init.d/datadog-agent status` |
+| Kubernetes | `kubectl exec -it -- /etc/init.d/datadog-agent status` |
+| macOS | `datadog-agent status` |
+| Origen | `sudo ~/.datadog-agent/bin/agent status` |
+| Windows | Consulta la [documentación sobre el Windows Agent][1]. |
+
+[1]: /es/agent/basic_agent_usage/windows/#status-and-information
+{{% /tab %}}
+{{% tab "Cluster Agent" %}}
+
+| Plataforma | Comando |
+|------------|--------------------------------|
+| Kubernetes | `datadog-cluster-agent status` |
+
+{{% /tab %}}
+{{< /tabs >}}
+
+### Información del Agent
+
+Lista de comandos para mostrar el estado del Datadog Agent y las integraciones habilitadas.
+
+{{< tabs >}}
+{{% tab "Agent v6 y v7" %}}
+
+| Plataforma | Comando |
+|------------|------------------------------------------------------|
+| AIX | `datadog-agent status` |
+| Linux | `sudo datadog-agent status` |
+| Docker | `sudo docker exec -it agent status` |
+| Kubernetes | `kubectl exec -it -- agent status` |
+| macOS | `datadog-agent status` o a través de la [GUI web][1] |
+| Origen | `sudo datadog-agent status` |
+| Windows | Consulta la [documentación sobre el Windows Agent][2]. |
+
+Se mostrará una integración debidamente configurada en **Running Checks** (Checks en ejecución) sin que figuren avisos ni errores, tal y como aparece a continuación:
+
+```text
+Running Checks
+==============
+ network (1.6.0)
+ ---------------
+ Total Runs: 5
+ Metric Samples: 26, Total: 130
+ Events: 0, Total: 0
+ Service Checks: 0, Total: 0
+ Average Execution Time : 0ms
+```
+
+[1]: /es/agent/basic_agent_usage/#gui
+[2]: /es/agent/basic_agent_usage/windows/#status-and-information
+{{% /tab %}}
+{{% tab "Agent v5" %}}
+
+| Plataforma | Comando |
+|------------|------------------------------------------------------------------------|
+| Linux | `sudo service datadog-agent info` |
+| Docker | `sudo docker exec -it /etc/init.d/datadog-agent info` |
+| Kubernetes | `kubectl exec -it -- /etc/init.d/datadog-agent info` |
+| macOS | `datadog-agent info` |
+| Origen | `sudo ~/.datadog-agent/bin/info` |
+| Windows | Consulta la [documentación sobre el Windows Agent][1]. |
+
+Se mostrará una integración debidamente configurada en **Checks** sin que figuren avisos ni errores, tal y como se muestra a continuación:
+
+```text
+Checks
+======
+ network
+ -------
+ - instance #0 [OK]
+ - Collected 15 metrics, 0 events & 1 service check
+```
+
+[1]: /es/agent/basic_agent_usage/windows/#status-and-information
+{{% /tab %}}
+{{% tab "Cluster Agent" %}}
+
+| Plataforma | Comando |
+|------------|--------------------------------|
+| Kubernetes | `datadog-cluster-agent status` |
+
+{{% /tab %}}
+{{< /tabs >}}
+
+## Otros comandos
+
+{{< tabs >}}
+{{% tab "Agent v6 y v7" %}}
+
+La interfaz de línea de comandos del Agent v6 se basa en subcomandos. Para consultar la lista de subcomandos disponibles, ejecuta:
+```shell
+ --help
+```
+
+Para ejecutar un subcomando, se debe invocar el archivo binario del Agent:
+```shell
+
+```
+
+Algunas opciones tienen marcas y opciones detalladas en el subcomando `--help`. For example, use help with the `check`:
+```shell
+ check --help
+```
+
+| Subcomando | Notas |
+|-------------------|-----------------------------------------------------------------------------|
+| `check` | Ejecuta el check especificado. |
+| `config` | [Gestión de la configuración del tiempo de ejecución][1] |
+| `configcheck` | Muestra todas las configuraciones cargadas y resueltas de un Agent en ejecución. |
+| `diagnose` | Realiza un diagnóstico de conectividad en tu sistema. |
+| `flare` | [Recopila un flare y lo envía a Datadog][2]. |
+| `health` | Muestra el estado actual del Agent. |
+| `help` | Ofrece ayuda con cualquier comando. |
+| `hostname` | Muestra el nombre de host que utiliza el Agent. |
+| `import` | Importa y convierte archivos de configuración de versiones anteriores del Agent. |
+| `jmx` | Soluciona problemas de JMX. |
+| `launch-gui` | Inicia la GUI del Datadog Agent. |
+| `restart-service` | Reinicia el Agent en el administrador de control de servicios. Solo en Windows. |
+| `start-service` | Inicia el Agent en el administrador de control de servicios. Solo en Windows. |
+| `stream-logs` | Genera un flujo de los logs que procesa un Agent en ejecución. |
+| `stopservice` | Detiene el Agent en el administrador de control de servicios. Solo en Windows. |
+| `version` | Muestra información acerca de la versión. |
+
+[1]: /es/agent/troubleshooting/config/
+[2]: /es/agent/troubleshooting/send_a_flare/
+{{% /tab %}}
+{{< /tabs >}}
+
+## Lectura adicional
+
+{{< partial name="whats-next/whats-next.html" >}}
\ No newline at end of file
diff --git a/content/es/agent/configuration/agent-configuration-files.md b/content/es/agent/configuration/agent-configuration-files.md
new file mode 100644
index 0000000000000..10989abca1ff4
--- /dev/null
+++ b/content/es/agent/configuration/agent-configuration-files.md
@@ -0,0 +1,116 @@
+---
+algolia:
+ category: guía
+ rank: 80
+ subcategory: Archivos de configuración del Agent
+ tags:
+ - configuración del Agent
+ - configuración del Agent
+ - directorio del Agent
+aliases:
+- /es/agent/faq/agent-configuration-files
+- /es/agent/guide/agent-configuration-files
+kind: guía
+title: Archivos de configuración del Agent
+---
+
+## Archivo de configuración principal del Agent
+
+El archivo de configuración del Agent v6 utiliza **YAML** para adaptarse mejor a configuraciones complejas y garantizar la coherencia en el proceso de configuración, ya que los checks también utilizan archivos de configuración YAML. Por este motivo, `datadog.yaml` (v6) pasa a sustituir a `datadog.conf` (v5).
+
+{{< tabs >}}
+{{% tab "Agent v6 y v7" %}}
+
+| Plataforma | Comando |
+|:-------------------------------------|:-------------------------------------|
+| AIX | `/etc/datadog-agent/datadog.yaml` |
+| Linux | `/etc/datadog-agent/datadog.yaml` |
+| macOS | `~/.datadog-agent/datadog.yaml` |
+| Windows | `%ProgramData%\Datadog\datadog.yaml` |
+
+{{% /tab %}}
+{{% tab "Agent v5" %}}
+
+| Plataforma | Comando |
+|:-------------------------------------|:---------------------------------------------------------------------------|
+| Linux | `/etc/dd-agent/datadog.conf` |
+| macOS | `~/.datadog-agent/datadog.conf` | |
+| Windows Server 2008, Vista y versiones más recientes | `%ProgramData%\Datadog\datadog.conf` |
+| Windows Server 2003, XP o versiones anteriores | `\\Documents and Settings\All Users\Application Data\Datadog\datadog.conf` |
+
+{{% /tab %}}
+{{< /tabs >}}
+
+Consulta el [archivo `config_template.yaml` de ejemplo][2] para ver todas las opciones de configuración disponibles.
+
+## Directorio de configuración del Agent
+
+En versiones anteriores, el Datadog Agent almacenaba los archivos de configuración en `/dd-agent/conf.d/`. Con la versión 6.0, estos archivos pasan a guardarse en `/etc/datadog-agent/conf.d/.d/`.
+
+{{< tabs >}}
+{{% tab "Agent v6 y v7" %}}
+
+| Plataforma | Comando |
+|:-------------------------------------|:-------------------------------|
+| AIX | `/etc/datadog-agent/conf.d/` |
+| Linux | `/etc/datadog-agent/conf.d/` |
+| CentOS | `/etc/datadog-agent/conf.d/` |
+| Debian | `/etc/datadog-agent/conf.d/` |
+| Fedora | `/etc/datadog-agent/conf.d/` |
+| macOS | `~/.datadog-agent/conf.d/` |
+| RedHat | `/etc/datadog-agent/conf.d/` |
+| Origen | `/etc/datadog-agent/conf.d/` |
+| SUSE | `/etc/datadog-agent/conf.d/` |
+| Ubuntu | `/etc/datadog-agent/conf.d/` |
+| Windows | `%ProgramData%\Datadog\conf.d` |
+
+### Archivos de configuración de checks para el Agent 6
+
+En el archivo `conf.yaml.example`, en la carpeta `.d/` correspondiente, encontrarás un ejemplo de todos los archivos de configuración de checks del Agent. Cambia el nombre a `conf.yaml` para habilitar el check relacionado. **Nota**: El Agent carga los archivos YAML válidos incluidos en la carpeta: `/etc/datadog-agent/conf.d/.d/`. Con este paso, las configuraciones complejas se dividen en varios archivos. Por ejemplo, una configuración para `http_check` tendría este aspecto:
+
+```text
+/etc/datadog-agent/conf.d/http_check.d/
+├── backend.yaml
+└── frontend.yaml
+```
+
+Los archivos YAML con el sufijo `.default` son un caso especial. El Agent los carga de forma predeterminada, y sirven para ayudar a determinar el conjunto principal de checks que se habilitan siempre (CPU, memoria, tiempo de actividad…). Es seguro omitirlos porque, de hecho, se omiten si se encuentra otra configuración para un check determinado. Si quieres deshabilitar alguno de los checks predeterminados, basta con eliminar el archivo correspondiente. Para configurar estos checks, se debería utilizar `conf.yaml.example` como base.
+
+Los archivos de plantilla de Autodiscovery se almacenan en la carpeta de configuración con el archivo `auto_conf.yaml`. Por ejemplo, en el caso del check de Redis, esta es la configuración en `redisdb.d/`:
+
+```text
+/etc/datadog-agent/conf.d/redisdb.d/
+├── auto_conf.yaml
+└── conf.yaml.example
+```
+
+Para la recopilación de logs, si hay varios archivos YAML que se dirigen a una misma fuente de logs, el Agent no los acepta para evitar que se envíen duplicados a Datadog. Si se da este caso, el Agent ordena los archivos de manera alfabética y utiliza el primero de la lista.
+
+Para preservar la compatibilidad con versiones anteriores, el Agent sigue aceptando los archivos de configuración en formato `/etc/dd-agent/conf.d/.yaml`. Sin embargo, recomendamos encarecidamente utilizar el formato nuevo.
+
+{{% /tab %}}
+{{% tab "Agent v5" %}}
+
+| Plataforma | Comando |
+|:-------------------------------------|:---------------------------------------------------------------------|
+| Linux | `/etc/dd-agent/conf.d/` |
+| CentOS | `/etc/dd-agent/conf.d/` |
+| Debian | `/etc/dd-agent/conf.d/` |
+| Fedora | `/etc/dd-agent/conf.d/` |
+| macOS | `~/.datadog-agent/conf.d/` |
+| RedHat | `/etc/dd-agent/conf.d/` |
+| Origen | `/etc/dd-agent/conf.d/` |
+| SUSE | `/etc/dd-agent/conf.d/` |
+| Ubuntu | `/etc/dd-agent/conf.d/` |
+| Windows Server 2008, Vista y versiones más recientes | `%ProgramData%\Datadog\conf.d` |
+| Windows Server 2003, XP o versiones anteriores | `\\Documents and Settings\All Users\Application Data\Datadog\conf.d` |
+
+{{% /tab %}}
+{{< /tabs >}}
+
+## Archivo de configuración de JMX
+
+Los checks de JMX del Agent incluyen un archivo `metrics.yaml` adicional en la carpeta de configuración. Se trata de una lista de beans que el Datadog Agent recopila de forma predeterminada. Así, no tendrás que detallarlos de forma manual cuando configures un check a través de las [etiquetas de Docker o las anotaciones de k8s][1].
+
+[1]: /es/agent/kubernetes/integrations/#configuration
+[2]: https://github.com/DataDog/datadog-agent/blob/master/pkg/config/config_template.yaml
\ No newline at end of file
diff --git a/content/es/agent/configuration/agent-fips-proxy.md b/content/es/agent/configuration/agent-fips-proxy.md
new file mode 100644
index 0000000000000..85bd9c9784706
--- /dev/null
+++ b/content/es/agent/configuration/agent-fips-proxy.md
@@ -0,0 +1,376 @@
+---
+algolia:
+ rank: 80
+ tags:
+ - fips
+ - fips proxy
+ - conformidad
+ - fedramp
+ - govcloud
+alias:
+- /agent/guide/agent-fips-proxy
+disable_toc: false
+further_reading:
+- link: agent/configuration/proxy
+ tag: Documentación
+ text: Configuración del proxy del Agent
+- link: https://www.datadoghq.com/blog/datadog-fips-enabled-agent/
+ tag: Blog
+ text: Monitorear cargas de trabajo altamente reguladas con Agent habilitado para
+ FIPS de Datadog
+kind: Guía
+title: Cumplimiento de FIPS de Datadog
+---
+
+{{< site-region region="us,us3,us5,eu,ap1" >}}
+
El Datadog Agent FIPS Proxy solo está disponible en la región US1-FED..
+{{< /site-region >}}
+
+El Datadog Agent FIPS Proxy garantiza que la comunicación entre Datadog Agent y Datadog utiliza cifrado conforme a FIPS.
+
+El Datadog Agent FIPS Proxy es un componente distribuido por separado que se despliega en el mismo host que el Datadog Agent . El proxy actúa como intermediario entre el consumo de Agent y Datadog. El Agent se comunica con el Datadog Agent FIPS Proxy, que cifra las cargas útiles utilizando una criptografía validada por FIPS 140-2 y las retransmite a Datadog. El Datadog Agent y el Agent FIPS Proxy deben configurarse en tándem para comunicarse entre sí.
+
+## Plataformas compatibles y limitaciones
+
+La conformidad de Datadog Agent FIPS Proxy se basa en el uso del [Cryptographic Module - Certificate #4282 (Módulo criptográfico - Certificado #4282)] validado por FIPS 140-2[1]. Consulta la [security policy (política de seguridad)][2] relacionada para obtener información sobre las restricciones y los entornos operativos validados.
+
+**Es responsabilidad del usuario garantizar que el funcionamiento de entorno cumple con la política de seguridad y las directrices generales de FIPS.**
+
+Plataformas compatibles (64 bits x86):
+
+|||
+| --- | ----------- |
+| Bare metal and VMs | RHEL >= 7 Debian >= 8 Ubuntu >= 14.04 SUSE >= 12 (beta)|
+| Cloud and container| Amazon ECS AWS EKS (Helm)|
+
+**Nota**: La arquitectura arm64 está disponible en beta.
+
+Productos compatibles (Agent 7.45+):
+
+- Metrics
+- Logs
+- APM traces
+- APM profiles
+- Instrumentation Telemetry
+- Processes
+- Orchestrator Explorer
+- Runtime Security
+
+
+El proxy de FIPS de Datadog Agent **no** admite lo siguiente:
+
+- Serverless Monitoring
+- Comunicación entre Cluster Agent y el Node Agents
+- Agent integrations
+- Comunicación saliente a cualquier otra cosa que no sea GovCloud
+
+## Requisitos previos
+
+- Rango de puertos TCP disponible: 9803 a 9818
+- Versión de Datadog Agent 7.41 o posterior
+
+## Instalar el Agent con soporte FIPS
+
+{{< tabs >}}
+{{% tab "Host or VM" %}}
+
+### Instalar el Agent en un nuevo host
+
+Para instalar el Datadog Agent con el Datadog Agent FIPS Proxy, añade `DD_FIPS_MODE=1` a las instrucciones de instalación en un solo paso de la página [Datadog Agent Integration (Integración de Datadog Agent)][1]. Por ejemplo
+
+```shell
+DD_API_KEY= \
+DD_SITE="ddog-gov.com" \
+DD_FIPS_MODE=1 \
+bash -c "$(curl -L \
+ https://s3.amazonaws.com/dd-agent/scripts/install_script_agent7.sh)"
+```
+
+Establecer la variable de entorno `DD_FIPS_MODE` instala el paquete de FIPS junto con el Agent, y configura el Agent para usar el proxy. No hay pasos de configuración adicionales si estás usando este método, pero deberías [verify the installation (verificar la instalación)](#verify-your-installation).
+
+### Añadir el Datadog Agent FIPS Proxy a un Agent
+
+Sigue los pasos que se indican a continuación para añadir el Datadog Agent FIPS Proxy a una instalación existente de Agent.
+
+#### Instalar el paquete de Datadog Agent FIPS Proxy:
+
+1. Ejecuta los siguientes comandos para instalar el proxy:
+
+ Debian:
+ ```shell
+ apt-get update && apt-get install datadog-fips-proxy
+ ```
+ RHEL and Fedora:
+ ```shell
+ yum makecache && yum install datadog-fips-proxy
+ ```
+ SLES:
+ ```shell
+ zypper refresh datadog && zypper install datadog-fips-proxy
+ ```
+
+ SLES:
+ ```shell
+ zypper refresh datadog && zypper install datadog-fips-proxy
+ ```
+
+1. La primera vez que realices una actualización, copia el archivo de configuración de ejemplo en la ubicación apropiada y reinicia el proxy. No necesitas copiar la configuración en actualizaciones posteriores, a menos que haya cambios significativos en la configuración de proxy ascendente:
+ ```shell
+ sudo cp /etc/datadog-fips-proxy/datadog-fips-proxy.cfg.example \
+ /etc/datadog-fips-proxy/datadog-fips-proxy.cfg
+ sudo chown dd-agent:dd-agent \
+ /etc/datadog-fips-proxy/datadog-fips-proxy.cfg
+ sudo chmod 640 /etc/datadog-fips-proxy/datadog-fips-proxy.cfg
+ sudo systemctl restart datadog-fips-proxy
+ ```
+
+#### Configurar el Agent para utilizar el proxy de FIPS de Datadog Agent
+
+El paquete de Datadog Agent FIPS Proxy viene preconfigurado para su uso con el centro de datos US1-FED. Si estás actualizando un Datadog Agent existente, **debes** configurar el Agent para utilizar el proxy.
+
+Para eso, establece `fips.enabled` en `verdadero` y `fips.https` en `falso` en el [Agent configuration file (archivo de configuración de Agent)][2]:
+
+```yaml
+fips:
+ enabled: true
+ https: false
+```
+
+La opción `fips` está disponible en las versiones de Agent 7.41 o posteriores. Cuando la configuración está activada, Datadog Agent redirige todas sus comunicaciones a Datadog Agent FIPS Proxy para los productos compatibles. Esta configuración ignora las opciones de URL personalizadas, como `dd_url`.
+
+La opción `https` se establece en `falso` porque Agent utiliza HTTP para comunicarse con el proxy. El Datadog Agent FIPS Proxy se ejecuta en el mismo host que Agent y confía en la seguridad del host para proteger dicha comunicación.
+
+** La seguridad y el fortalecimiento de host son tu responsabilidad.**
+
+
El valor predeterminado de fips.enabled es falso en el Agent. Debe establecerse en verdadero para garantizar que todas las comunicaciones se reenvían a través del Datadog Agent FIPS Proxy.
Si fips.enabled no está establecido en verdadero, el Agent no es compatible con FIPS.
+
+### Verifica tu instalación
+
+Verifica que métricas, trazas (traces), y logs están correctamente reportados en la app.
+
+Para métricas, ejecuta el comando de diagnóstico de conectividad y comprueba que todos los checks pasen:
+
+```shell
+sudo -u dd-agent datadog-agent diagnose --include connectivity-datadog-core-endpoints
+# Para la versión de Agent anterior a 7.48, ejecuta el siguiente comando:
+# sudo -u dd-agent datadog-agent diagnose datadog-connectivity
+```
+
+Si no ves métricas, trazas o logs reportadas en la aplicación, consulta la sección [Troubleshooting (solucionar problemas)](#troubleshooting-a-bare-metal-or-vm-installation).
+
+### Ver logs
+
+```shell
+sudo journalctl -u datadog-fips-proxy
+```
+
+#### Configuración de logs de journald
+
+Si utilizas [Log Management (Gestión de logs)][3] y deseas enviar los logs Proxy de FIPS de Datadog Agent a Datadog, configura el Datadog Agent para leer logs desde journald.
+
+1. En el [configuration file (archivo de configuración)][2] de Agent, establece `logs_enabled` en `verdadero` para activar Logs Agent. En el [configuration directory (directorio de configuración)][4], crea un archivo en `fips_proxy.d/conf.yaml` con el siguiente contenido:
+
+ ```yaml
+ logs:
+ - type: journald
+ source: datadog-fips-proxy
+ include_units:
+ - datadog-fips-proxy.service
+ ```
+
+1. Asegúrate de que el usuario `dd-agent` está en el grupo `systemd-journal`. Para más información, consulta la documentación [journald integration (integración de journald)][5].
+1. [Restart the Agent (reiniciar el Agent)][6].
+
+[1]: https://app.datadoghq.com/account/settings/agent/latest
+[2]: /es/agent/configuration/agent-configuration-files/#agent-main-configuration-file
+[3]: /es/logs/
+[4]: /es/agent/configuration/agent-configuration-files/#agent-configuration-directory
+[5]: /es/integrations/journald/#configuration
+[6]: /es/agent/configuration/agent-commands/#start-stop-and-restart-the-agent
+{{% /tab %}}
+
+{{% tab "Helm on Amazon EKS" %}}
+Establece los siguientes valores en tu archivo `values.yaml`:
+
+```yaml
+fips:
+ enabled: true
+ use_https: false
+```
+
+El ajuste `fips` está disponible en las versiones Agent 7.41 o posteriores. Cuando la configuración está activada, Datadog Agent redirige todas sus comunicaciones al Proxy de FIPS de Datadog Agent para los productos compatibles. Esta configuración ignora las opciones de URL personalizadas, como `dd_url`.
+
+La opción `use_https` se establece en `falso` porque Agent utiliza HTTP para comunicarse con el proxy. El Proxy de FIPS de Datadog Agent se ejecuta en el mismo host que Datadog Agent y confía en la seguridad de host para la protección de dicha comunicación.
+
+**La seguridad y el fortalecimiento de host son tu responsabilidad.**
+
+
El ajuste fips.enabled está predeterminado como falso en el Agent. Debe establecerse en verdadero para garantizar que todas las comunicaciones se reenvíen a través del Proxy de FIPS de Datadog Agent.
Si fips.enabled no está establecido en verdadero, el Agent no es compatible con FIPS.
+
+
+{{% /tab %}}
+
+{{% tab "Amazon ECS" %}}
+
+Para obtener instrucciones sobre la instalación del proxy de FIPS en Amazon ECS, consulta [FIPS proxy for GOVCLOUD environments (entornos de FIPS proxy para GOVCLOUD)][1].
+
+[1]: /es/containers/amazon_ecs/#fips-proxy-for-govcloud-environments
+{{% /tab %}}
+
+{{< /tabs >}}
+
+## Solucionar problemas de un host o una instalación VM
+
+Para solucionar los problemas del Datadog Agent FIPS Proxy, verifica lo siguiente:
+- Se están ejecutando Datadog Agent y Datadog Agent FIPS Proxy.
+- El Datadog Agent puede comunicarse con el Datadog Agent FIPS Proxy.
+- El Datadog Agent FIPS Proxy puede comunicarse con los endpoints de admisión de Datadog.
+
+### Controlar el estado del proxy
+
+Para obtener información sobre el estado de Datadog Agent FIPS Proxy, ejecuta el siguiente comando:
+
+```shell
+sudo systemctl status datadog-fips-proxy
+```
+
+Si se está ejecutando el proxy, la salida debería ser similar a la siguiente:
+```text
+- datadog-fips-proxy.service - Datadog FIPS Proxy
+ Cargado: cargado
+ (/lib/systemd/system/datadog-fips-proxy.service;
+ enabled; vendor preset: enabled)
+ Activo: activo (ejecutando) desde martes 19-07-2022 16:21:15 UTC; hace 1 min 6 s
+```
+
+Si el estado del proxy es `inactivo (muerto)`, inicia el Datadog Agent FIPS Proxy:
+
+```shell
+sudo systemctl start datadog-fips-proxy
+```
+
+Si el estado del proxy es `fallido`, el Datadog Agent FIPS Proxy no se ha podido iniciar debido a un error. Ejecuta el siguiente comando y busca errores en los logs del proxy:
+
+```shell
+sudo journalctl -u datadog-fips-proxy --no-pager
+```
+
+### Proxy no puede enlazar el socket
+
+Si los logs del proxy muestran un error `enlazar socket`, el proxy está intentando utilizar un puerto que ya está en uso en el host. El Datadog Agent FIPS Proxy utiliza el rango de puertos TCP desde el 9803 hasta el 9818 inclusive. Los puertos de este rango deben estar disponibles en host y no ser utilizados por otros servicios.
+
+En el siguiente ejemplo, el Datadog Agent FIPS Proxy no puede enlazar un socket en el puerto `9804` porque el puerto ya está en uso:
+
+```text
+[ALERT] (4518) : Iniciando frontend métricas-forwarder: no se puede enlazar socket (Dirección ya en uso) [0.0.0.0:9804]
+[ALERT] (4518) : [/opt/Datadog-fips-proxy/embedded/sbin/haproxy.main()] Algunos protocolos fallaron al iniciar sus escuchadores. Saliendo.
+```
+
+### Agent no puede conectarse al proxy.
+
+Para controlar problemas de red, controla los logs en `/var/log/datadog/agent.log`, o ejecuta:
+
+```shell
+datadog-agent diagnose --include connectivity-datadog-core-endpoints
+# Para versiones de Agent 7.48 o anteriores, ejecuta el siguiente comando:
+# datadog-agent diagnóstico datadog-connectivity
+```
+
+Busca errores como:
+```text
+conectar: conexión denegada, fecha límite de contexto excedida (Client.Timeout excedido mientras espera cabeceras), o conexión reseteada por peer
+```
+
+- Sigue los pasos en [Check the proxy status (controla el estado del proxy)](#check-the-proxy-status) para verificar que el Datadog Agent FIPS Proxy se esté ejecutando.
+- Comprueba que el rango de puertos de proxy coincida con el de Agent.
+
+Si el proxy se está ejecutando y el rango de puertos es correcto, es posible que un cortafuegos local de la máquina esté bloqueando el acceso de Agent al proxy. Configura tu cortafuegos para permitir conexiones a los puertos TCP de 9804 a 9818.
+
+Puedes utilizar `curl` para verificar que se puede acceder al proxy:
+
+```shell
+curl http://localhost:9804/
+```
+
+Para más ayuda, consulta [Agent Troubleshooting (solucionar problemas de Agent)][3].
+
+### Datadog Agent FIPS Proxy no puede conectarse a consumo de Datadog
+
+Si se producen errores de HTTP como `502`, `503`, o si el proxy devuelve una respuesta vacía, es posible que Datadog Agent FIPS Proxy no pueda reenviar tráfico al backend de Datadog.
+
+Verifica los logs de Datadog Agent FIPS Proxy con:
+
+```shell
+sudo journalctl -u datadog-fips-proxy --no-pager
+```
+
+Controla los logs para errores como:
+
+```text
+haproxy[292759]: [WARNING (ADVERTENCIA) (292759) : Servidor
+datadog-api/mothership3 está CAÍDO, razón: Capa4 tiempo de espera, duración vcheck: 2000 ms. Quedan 0 servidores activos y 0 de backup. 0 sesiones activas, 0 en cola, 0 restantes en cola.
+[ALERT (ALERTA)] (292759): El backend 'datadog-api' no tiene servidor disponible.
+```
+
+o
+
+```text
+haproxy[1808]: [WARNING (ADVERTENCIA) (1808) : Servidor
+datadog-metrics/mothership2 está CAÍDO, razón: Capa4
+problema de conexión, info: "Conexión rechazada", duración del check: 0 ms. Quedan 0 servidores activos y 0 de backup. 0
+sesiones activas, 0 en cola, 0 restantes en cola.
+haproxy[1808]: [ALERT (ALERTA)] (1808): El backend 'datadog-metrics' no tiene servidor disponible.
+```
+
+Estos errores indican que Datadog Agent FIPS Proxy no puede ponerse en contacto con los sistemas backend, posiblemente debido al bloqueo de un cortafuegos o a otro problema de red. Datadog Agent FIPS Proxy requiere acceso a Internet a los endpoints de consumo de Datadog. Puedes encontrar las direcciones IP de estos endpoints [through the API (a través de la API)][4].
+
+Para más información sobre conexiones salientes desde el Agent, consulta la guía [Network Traffic (tráfico de red)][5].
+
+Si sigues teniendo dudas sobre tu problema, ponte en contacto con [Datadog support (asistencia de Datadog)][6].
+
+## Preguntas frecuentes
+
+**1. ¿Tienen que estar el Datadog Agent y el Datadog Agent FIPS Proxy en el mismo host?**
+
+Sí, la conformidad con FIPS no se conserva si Datadog Agent FIPS Proxy y Datadog Agent no están en el mismo host.
+Del mismo modo, la conformidad con FIPS no se mantiene si la opción `fips.enabled` no se establece en `verdadero` en `datadog.yaml`.
+
+**2. ¿Quién es responsable de fortalecer el host?**
+
+Tú, el cliente de Datadog, eres responsable de la seguridad y el fortalecimiento de host.
+
+**3. ¿Están fortalecidas las imágenes de Datadog Agent FIPS Proxy?**
+
+Aunque las imágenes proporcionadas se han construido teniendo en cuenta la seguridad, no se han evaluado con respecto a las recomendaciones de referencia del CIS ni a las normas STIG de DISA.
+
+**4. ¿Son compatibles con FIPS todas las comunicaciones entrantes y salientes de Agent?**
+
+Datadog Agent FIPS Proxy solo protege la comunicación que se origina en Agent y se dirige a los endpoints de la API de admisión Datadog. Esto significa que otras formas de comunicación que terminen en el Agent o se originen en el Agent no son conformes a FIPS gracias a esta solución.
+
+**5. ¿Se admiten todas las comunicaciones entre el FIPS de Cluster Agent y Node Agents?**
+
+Datadog Agent FIPS Proxy solo protege la comunicación que se origina en Cluster Agent y se dirige a los enpoints de la API de admisión Datadog. Esto significa que otras formas de comunicación que terminen en Cluster Agent o se originen en Cluester Agent no son conformes a FIPS gracias a esta solución.
+
+**6. ¿Se mantiene la conformidad con FIPS si reconstruimos o reconfiguramos Datadog Agent FIPS Proxy para adaptarlo a nuestras necesidades de implementación o de pruebas?**.
+
+Aunque la reconstrucción, reconfiguración o modificación de Datadog Agent FIPS Proxy pueda ser una configuración técnicamente operativa, Datadog no puede garantizar la conformidad con FIPS si Datadog Agent FIPS Proxy no se utiliza exactamente como se explica en la documentación.
+
+**7. Mi Datadog Agent está enviando datos correctamente a pesar de que no he seguido todos los pasos de instalación indicados anteriormente. ¿Mi instalación es compatible con FIPS?**
+
+Datadog no puede garantizar la conformidad con FIPS si Datadog Agent FIPS Proxy no se utiliza exactamente como está documentado.
+La configuración correcta incluye tener tu Datadog Agent configurado para comunicarte con el Datadog Agent FIPS Proxy configurando la opción `fips.enabled`, y tener un Datadog Agent FIPS Proxy en ejecución.
+
+**8. ¿Están las versiones lanzadas de Datadog Agent vinculadas a las versiones lanzadas de Datadog Agent FIPS Proxy?
+
+No, las versiones del Datadog Agent FIPS Proxy están desacopladas de las versiones Datadog Agent. Utiliza la última de las versiones Datadog Agent y Datadog Agent FIPS Proxy
+para disponer de todos los productos disponibles compatibles con Datadog Agent y Datadog Agent FIPS Proxy.
+
+## Leer más
+
+{{< partial name="whats-next/whats-next.html" >}}
+
+[1]: https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4282
+[2]: https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp4282.pdf
+[3]: /es/agent/troubleshooting/
+[4]: https://ip-ranges.ddog-gov.com/
+[5]: /es/agent/configuration/network/#destinations
+[6]: /es/help/
\ No newline at end of file
diff --git a/content/es/agent/configuration/agent-log-files.md b/content/es/agent/configuration/agent-log-files.md
new file mode 100644
index 0000000000000..2de6dc1aa85a5
--- /dev/null
+++ b/content/es/agent/configuration/agent-log-files.md
@@ -0,0 +1,86 @@
+---
+algolia:
+ tags:
+ - archivos de log del Agent
+aliases:
+- /es/agent/faq/agent-log-files
+- /es/agent/guide/agent-log-files
+further_reading:
+- link: /agent/troubleshooting/
+ tag: Documentación
+ text: Solucionar problemas del Agent
+- link: /agent/configuration/agent-configuration-files/
+ tag: Preguntas frecuentes
+ text: Archivos de configuración del Agent
+- link: /agent/configuration/agent-commands/
+ tag: Preguntas frecuentes
+ text: Comandos del Agent
+kind: guía
+title: Archivos de log del Agent
+---
+
+El Datadog Agent hace un volcado de logs cada 10 MB de manera predeterminada. Cuando esto ocurre, se guarda una copia de seguridad (`agent.log.1`) y, si ya existe alguna, esta se sobrescribe durante el proceso. Para establecer el tamaño máximo de un archivo de log y el número máximo de archivos de copia de seguridad que se desean mantener, configura el `log_file_max_size` (por defecto: 10485760 bytes) y el `log_file_max_rolls` (por defecto: 1) en el [Agent main configuration file (archivo de configuración principal del Agent)][1].
+
+## Directorio de log del Agent
+
+{{< tabs >}}
+{{% tab "Agent v6 & v7" %}}
+
+| Plataforma | Comando |
+|---------------------------------------|-------------------------------|
+| Linux | `/var/log/datadog/` |
+| macOS, Agent 7.28 y versiones posteriores y 6.28 y versiones posteriores | `/opt/datadog-agent/logs` |
+| macOS, versiones anteriores al Agent 6.28.0/7.28.0 | `/var/log/datadog` |
+| Windows | `C:\ProgramData\Datadog\logs` |
+
+{{% /tab %}}
+{{% tab "Agent v5" %}}
+
+| Plataforma | Comando |
+|--------------------------------------|----------------------------------------------------------------------|
+| Linux | `/var/log/datadog/` |
+| macOS | `/var/log/datadog/` |
+| Windows Server 2008, Vista y versiones más recientes | `C:\ProgramData\Datadog\logs\` |
+| Windows Server 2003, XP o versiones anteriores | `C:\Documents and Settings\All Users\Application Data\Datadog\logs\` |
+| SmartOS | `/opt/local/datadog/logs/supervisord/` |
+| Compilación de fuentes | `~/.datadog-agent/supervisord/logs/` |
+
+{{% /tab %}}
+{{< /tabs >}}
+
+## Archivos de log del Agent
+
+{{< tabs >}}
+{{% tab "Agent v6 & v7" %}}
+
+* `agent.log`
+* `process-agent.log`
+* `trace-agent.log`
+* `system-probe.log`
+* `jmxfetch.log` para versiones del Agent 7.24.0/6.24.0 o posteriores
+* `dogstatsd.log` para la versión del Agent 7.46.0 o posteriores
+
+{{% /tab %}}
+{{% tab "Agent v5" %}}
+
+* `collector.log`
+* `dogstatsd.log`
+* `forwarder.log`
+* `supervisord.log`
+
+{{% /tab %}}
+{{< /tabs >}}
+
+## Archivos de log de instalación del Agent
+
+| Plataforma | Localización y nombre del archivo |
+|--------------------------------------|-------------------------------|
+| Linux | `$(pwd)/ddagent-install.log` |
+| macOS | `/tmp/dd_agent.log` |
+| Windows | `%TEMP%\MSI*.LOG` |
+
+## Leer más
+
+{{< partial name="whats-next/whats-next.html" >}}
+
+[1]: https://docs.datadoghq.com/es/agent/configuration/agent-configuration-files/?tab=agentv6v7#agent-main-configuration-file
\ No newline at end of file
diff --git a/content/es/agent/configuration/agent-status-page.md b/content/es/agent/configuration/agent-status-page.md
new file mode 100644
index 0000000000000..b6536d990f121
--- /dev/null
+++ b/content/es/agent/configuration/agent-status-page.md
@@ -0,0 +1,280 @@
+---
+algolia:
+ tags:
+ - página de estado
+aliases:
+- /es/agent/guide/agent-status-page
+further_reading:
+- link: /agent/troubleshooting/
+ tag: Documentación
+ text: Solucionar problemas del Agent
+- link: /agent/configuration/agent-configuration-files/
+ tag: Guía
+ text: Archivos de configuración del Agent
+- link: /agent/configuration/agent-commands/
+ tag: Guía
+ text: Comandos del Agent
+kind: guía
+title: Página de estado del Agent v6
+---
+
+La página de estado del Agent v6 muestra información sobre el Agent en ejecución. Consulta la página [Agent Commands (Comandos del Agent)][1] para encontrar el comando de estado adecuado para tu entorno. En las siguientes secciones, encontrarás más detalles sobre el contenido de la página de estado.
+
+**Nota**: La página de estado puede variar ligeramente entre las distintas versiones del Agent.
+
+## Versión del Agent
+
+La información general del Agent se muestra debajo de la versión del Agent. Por ejemplo:
+```text
+ Status date: 2019-08-29 18:16:41.526203 UTC
+ Agent start: 2019-08-29 18:04:18.060507 UTC
+ Pid: 12141
+ Go Version: go1.11.5
+ Python Version: 2.7.16
+ Check Runners: 4
+ Log Level: info
+```
+
+### Rutas
+
+En esta sección, se indican las rutas al archivo de configuración de Datadog, al directorio `conf.d` y al directorio `checks.d`. Por ejemplo:
+```text
+ Config File: /etc/datadog-agent/datadog.yaml
+ conf.d: /etc/datadog-agent/conf.d
+ checks.d: /etc/datadog-agent/checks.d
+```
+
+### Relojes
+
+Esta sección muestra la [NTP offset (diferencia horaria con NTP)][2] y la hora UTC del sistema. Por ejemplo:
+```text
+ NTP offset: 2.095ms
+ System UTC time: 2019-08-29 18:16:41.526203 UTC
+```
+
+### Información sobre el host
+
+En esta sección, se muestra información del host en el que se está ejecutando el Agent. Por ejemplo:
+```text
+ bootTime: 2019-08-29 18:01:27.000000 UTC
+ kernelVersion: 4.4.0-109-generic
+ os: linux
+ platform: ubuntu
+ platformFamily: debian
+ platformVersion: 16.04
+ procs: 175
+ uptime: 2m53s
+ virtualizationRole: guest
+ virtualizationSystem: vbox
+```
+
+### Nombres de host
+
+En esta sección, se muestran los nombres de host que encontró el Agent (consulta los siguientes ejemplos). El `nombre de host` es el último notificado al backend. Para obtener más información, consulta [How does Datadog determine the Agent hostname (¿Cómo determina Datadog el nombre de host del Agent?)][3].
+
+```text
+ hostname: ubuntu-xenial
+ socket-fqdn: ubuntu-xenial
+ socket-hostname: ubuntu-xenial
+ hostname provider: os
+ unused hostname providers:
+ aws: not retrieving hostname from AWS: the host is not an ECS instance, and other providers already retrieve non-default hostnames
+ configuration/environment: hostname is empty
+ gce: unable to retrieve hostname from GCE: Get http://169.254.169.254/computeMetadata/v1/instance/hostname: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
+```
+
+## Collector
+
+### Checks en ejecución
+
+En esta sección, se muestra una lista de instancias de checks en ejecución. Por ejemplo:
+
+```text
+ load
+ ----
+ Instance ID: load [OK]
+ Total Runs: 4
+ Metric Samples: Last Run: 6, Total: 24
+ Events: Last Run: 0, Total: 0
+ Service Checks: Last Run: 0, Total: 0
+ Histogram Buckets: Last Run: 12, Total: 36
+ Average Execution Time : 6ms
+```
+
+Términos y descripciones:
+
+| Término | Descripción |
+|------------------------|------------------------------------------------------------------|
+| Instance ID | El ID de instancia y el estado del check. |
+| Total de ejecuciones | Número total de veces que se ejecutó la instancia. |
+| Muestras de métricas | El número de métricas obtenidas. |
+| Eventos | El número de eventos activados. |
+| Checks de servicio | El número de checks de servicio notificados. |
+| Buckets de histograma | El número de buckets de histograma enviados. |
+| Tiempo medio de ejecución | El tiempo medio transcurrido para ejecutar la instancia. |
+| Última ejecución | El número durante la última ejecución de un check. |
+| Total | El número total desde el inicio o reinicio más reciente del Agent. |
+
+### Errores de configuración
+
+En esta sección, solo se indica si hay checks con errores de configuración. Por ejemplo:
+
+```text
+ test
+ ----
+ Configuration file contains no valid instances
+```
+
+### Errores de carga
+
+En esta sección, solo se indica si hay checks con errores de carga. Por ejemplo:
+
+```text
+ test
+ ----
+ Core Check Loader:
+ Check test not found in Catalog
+
+ JMX Check Loader:
+ check is not a jmx check, or unable to determine if it's so
+
+ Python Check Loader:
+ unable to import module 'test': No module named test
+```
+
+## JMXFetch
+
+En esta sección, se muestra una lista con los checks de JMX inicializados y otra con los fallidos, incluso si no hay checks. Por ejemplo:
+
+```text
+ Initialized checks
+ ==================
+ no checks
+
+ Failed checks
+ =============
+ no checks
+```
+
+## Forwarder
+
+El forwarder utiliza varios workers para enviar cargas útiles a Datadog.
+
+Si aparece la advertencia `el forwarder descartó las transacciones, es probable que haya un problema con tu red`, significa que todos los workers están ocupados. Deberías revisar el rendimiento de tu red y ajustar las opciones `forwarder_num_workers` y `forwarder_timeout`.
+
+### Transacciones
+
+En esta sección, se muestran las transacciones realizadas por el forwarder. Por ejemplo:
+
+```text
+ CheckRunsV1: 2
+ Dropped: 0
+ DroppedOnInput: 0
+ Events: 0
+ HostMetadata: 0
+ IntakeV1: 2
+ Metadata: 0
+ Requeued: 0
+ Retried: 0
+ RetryQueueSize: 0
+ Series: 0
+ ServiceChecks: 0
+ SketchSeries: 0
+ Success: 6
+ TimeseriesV1: 2
+ Errors: 1
+```
+
+Términos y descripciones:
+
+| Término | Descripción |
+|----------------|------------------------------------------------------------------------------|
+| Correcto | El número de transacciones enviadas correctamente. |
+| Errores | El número de veces que falló el envío de una transacción y que se reintentó. |
+| RetryQueueSize | El número actual de transacciones que están en espera para reintentarse. |
+| Reintentos | El número de veces que se reintentó realizar una transacción. |
+| DroppedOnInput | El número de transacciones que se descartaron porque todos los workers estaban ocupados. |
+| Abandonos | El número de transacciones que se descartaron porque se reintentaron muchas veces. |
+
+### Estado de las claves de API
+
+En esta sección, se muestra el estado de la clave de API configurada. Por ejemplo:
+
+```text
+ API key ending with ab123: API Key valid
+```
+
+## Endpoints
+
+En esta sección, se muestra la lista de endpoints que está utilizando el Datadog Agent. Por ejemplo:
+
+```text
+ https://app.datadoghq.com - API Key ending with:
+ - ab123
+```
+
+## Logs Agent
+
+Cuando está activado el Logs Agent, esta sección muestra información sobre los logs procesados y enviados. Por ejemplo:
+
+```text
+ LogsProcessed: 10
+ LogsSent: 10
+```
+
+## Aggregator
+
+En esta sección, se muestra información sobre el aggregator del Agent. Por ejemplo:
+
+```text
+ Checks Metric Sample: 399
+ Dogstatsd Metric Sample: 123
+ Event: 1
+ Events Flushed: 1
+ Number Of Flushes: 2
+ Series Flushed: 273
+ Service Check: 20
+ Service Checks Flushed: 20
+ Sketches Flushed: 8
+ Checks Histogram Bucket Metric Sample: 24
+```
+
+Términos y descripciones:
+
+| Término | Descripción |
+|----------------------------------------------|-------------------------------------------------------------------------------------------------------|
+| Muestra de métricas de checks | El número total de métricas enviadas de los checks al aggregator. |
+| Muestra de métricas de DogStatsD | El número total de métricas enviadas del servidor de DogStatsD al aggregator. |
+| Evento | El número total de eventos enviados al aggregator. |
+| Check de servicio | El número total de checks de servicio enviados al aggregator. |
+| Vaciado | La cantidad de veces que se vaciaron las métricas agregadas al forwarder para enviarlas a Datadog. |
+| Bocetos vaciados | La cantidad de veces que se vaciaron métricas de distribución agregadas al forwarder para enviarlas a Datadog. |
+| Muestra de métricas del bucket del histograma de checks | El número de métricas del bucket del histograma enviadas de los checks al aggregator. |
+
+## DogStatsD
+
+En esta sección, se indica el número de paquetes que recibió el servidor de DogStatsD para cada tipo de datos y errores asociados. Por ejemplo:
+
+```text
+ Event Packets: 0
+ Event Parse Errors: 0
+ Metric Packets: 122
+ Metric Parse Errors: 0
+ Service Check Packets: 0
+ Service Check Parse Errors: 0
+ Udp Bytes: 7,672
+ Udp Packet Reading Errors: 0
+ Udp Packets: 123
+ Uds Bytes: 0
+ Uds Origin Detection Errors: 0
+ Uds Packet Reading Errors: 0
+ Uds Packets: 0
+```
+
+## Leer más
+
+{{< partial name="whats-next/whats-next.html" >}}
+
+[1]: /es/agent/configuration/agent-commands/#agent-information
+[2]: /es/agent/troubleshooting/ntp/
+[3]: /es/agent/faq/how-datadog-agent-determines-the-hostname/
\ No newline at end of file
diff --git a/content/es/agent/configuration/dual-shipping.md b/content/es/agent/configuration/dual-shipping.md
new file mode 100644
index 0000000000000..98d020be51057
--- /dev/null
+++ b/content/es/agent/configuration/dual-shipping.md
@@ -0,0 +1,420 @@
+---
+aliases:
+- /es/agent/guide/dual-shipping
+further_reading:
+- link: /agent/configuration/network/
+ tag: Guía
+ text: Tráfico de red
+kind: guía
+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.
+
+
+## Información general
+
+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.
+
+Para ver una lista de destinos de tráfico de red, consulta [Network Traffic (tráfico de red)][1].
+
+## Métricas y checks de servicio
+
+Puedes añadir la configuración YAML a tu `datadog.yaml` o iniciar el Agent con las variables de entorno adecuadas.
+
+### Configuración YAML
+
+Es necesaria la versión 6.17 o 7.17 del Agent o una posterior.
+
+En `datadog.yaml`:
+
+```yaml
+additional_endpoints:
+ "https://app.datadoghq.com":
+ - apikey2
+ - apikey3
+ "https://app.datadoghq.eu":
+ - apikey4
+```
+
+### Configuración de la variable de entorno
+
+Es necesaria la versión 6.18 o 7.18 del Agent o una posterior.
+
+```bash
+DD_ADDITIONAL_ENDPOINTS='{\"https://app.datadoghq.com\": [\"apikey2\", \"apikey3\"], \"https://app.datadoghq.eu\": [\"apikey4\"]}'
+```
+
+## APM
+
+### Configuración YAML
+
+Es necesaria la versión 6.7.0 del Agent o una posterior.
+
+En `datadog.yaml`:
+```yaml
+apm_config:
+ [...]
+ additional_endpoints:
+ "https://trace.agent.datadoghq.com":
+ - apikey2
+ - apikey3
+ "https://trace.agent.datadoghq.eu":
+ - apikey4
+```
+
+### Configuración de la variable de entorno
+
+Es necesaria la versión 6.19 o 7.19 del Agent o una posterior.
+
+```bash
+DD_APM_ADDITIONAL_ENDPOINTS='{\"https://trace.agent.datadoghq.com\": [\"apikey2\", \"apikey3\"], \"https://trace.agent.datadoghq.eu\": [\"apikey4\"]}'
+```
+
+## Continuous Profiler
+
+### Configuración YAML
+
+Es necesaria la versión 6.7.0 del Agent o una posterior.
+
+En `datadog.yaml`:
+
+```yaml
+apm_config:
+ [...]
+ profiling_additional_endpoints:
+ "https://intake.profile.datadoghq.com/api/v2/profile":
+ - apikey2
+ - apikey3
+ "https://intake.profile.datadoghq.eu/api/v2/profile":
+ - apikey4
+```
+
+### Configuración de la variable de entorno
+
+Es necesaria la versión 6.19 o 7.19 del Agent o una posterior.
+
+```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\"]}'
+```
+
+**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.
+
+## Live Processes
+
+### Configuración YAML
+
+Es necesaria la versión 6.4.0 del Agent o una posterior.
+
+En `datadog.yaml`:
+```yaml
+process_config:
+ [...]
+ additional_endpoints:
+ "https://process.datadoghq.com":
+ - apikey2
+ - apikey3
+ "https://process.datadoghq.eu":
+ - apikey4
+```
+
+### Configuración de la variable de entorno
+
+Es necesaria la versión 6.20 o 7.20 del Agent o una posterior.
+
+```bash
+DD_PROCESS_ADDITIONAL_ENDPOINTS='{\"https://process.datadoghq.com\": [\"apikey2\", \"apikey3\"], \"https://process.datadoghq.eu\": [\"apikey4\"]}'
+```
+
+## Métricas de Cluster Agent
+
+Configurar el Agent para enviar métricas de Cluster Agent, como Centro de métricas de estado de Kubernetes, a endpoints adicionales.
+
+### Configuración de HELM
+En `valores.yaml` de Datadog:
+```yaml
+clusterAgent:
+ env:
+ - name: DD_ADDITIONAL_ENDPOINTS
+ value: '{"https://app.datadoghq.com": ["apikey2"]}'
+```
+### Proveedor de métricas de Cluster Agent
+
+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:
+
+{{< code-block lang="yaml" filename="cluster-agent-deployment.yaml" collapsible="true" >}}
+external_metrics_provider:
+ endpoints:
+ - api_key:
+ app_key:
+ url: https://app.datadoghq.eu
+ - api_key:
+ app_key:
+ url: https://app.datadoghq.com
+{{< /code-block >}}
+
+## Orquestador
+
+### Configuración de HELM
+En `valores.yaml` de Datadog:
+```yaml
+agents:
+ customAgentConfig:
+ process_config:
+ additional_endpoints:
+ "https://process.datadoghq.com":
+ - apikey2
+ orchestrator_explorer:
+ orchestrator_additional_endpoints:
+ "https://orchestrator.datadoghq.com":
+ - apikey2
+
+clusterAgent:
+...
+ datadog_cluster_yaml:
+ orchestrator_explorer:
+ orchestrator_additional_endpoints:
+ "https://orchestrator.ddog-gov.com":
+ - apikey2
+```
+
+
+### Configuración de la variable de entorno
+
+```bash
+DD_ORCHESTRATOR_EXPLORER_ORCHESTRATOR_ADDITIONAL_ENDPOINTS='{\"https://orchestrator.datadoghq.com\": [\"apikey2\", \"apikey3\"], \"https://orchestrator.datadoghq.eu\": [\"apikey4\"]}'
+```
+
+## CI Visibility
+
+### Configuración YAML
+
+Es necesaria la versión 6.38 o 7.38 del Agent o una posterior.
+
+En `datadog.yaml`:
+```yaml
+evp_proxy_config:
+ [...]
+ additional_endpoints:
+ "https://-app.agent.datadoghq.com":
+ - apikey2
+ - apikey3
+ "https://-app.agent.datadoghq.eu":
+ - apikey4
+```
+
+### Configuración de la variable de entorno
+
+```bash
+DD_EVP_PROXY_CONFIG_ADDITIONAL_ENDPOINTS='{\"https://-app.agent.datadoghq.com\": [\"apikey2\", \"apikey3\"], \"https://-app.agent.datadoghq.eu\": [\"apikey4\"]}'
+```
+
+## Logs
+
+TCP necesita la versión 6.6 del Agent o una posterior.
+HTTPS necesita la versión 6.13 del Agent o una posterior.
+
+### Configuración YAML
+En `datadog.yaml`:
+```yaml
+logs_config:
+ use_http: true
+ additional_endpoints:
+ - api_key: "apiKey2"
+ Host: "agent-http-intake.logs.datadoghq.com"
+ Port: 443
+ is_reliable: true
+```
+
+### Configuración de la variable de entorno
+
+Es necesaria la versión 6.18 o 7.18 del Agent o una posterior.
+
+```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}]"
+```
+
+{{% agent-dual-shipping %}}
+
+## Monitorización de base de datos
+
+### Configuración YAML
+
+Es necesaria la versión 6.29 o 7.29 del Agent o una posterior.
+
+En `datadog.yaml`:
+```yaml
+database_monitoring:
+ samples:
+ use_http: true
+ additional_endpoints:
+ - api_key: "apiKey2"
+ Host: "dbm-metrics-intake.datadoghq.com"
+ Port: 443
+ is_reliable: true
+ activity:
+ use_http: true
+ additional_endpoints:
+ - api_key: "apiKey2"
+ Host: "dbquery-intake.datadoghq.com"
+ Port: 443
+ is_reliable: true
+ metrics:
+ use_http: true
+ additional_endpoints:
+ - api_key: "apiKey2"
+ Host: "dbm-metrics-intake.datadoghq.com"
+ Port: 443
+ is_reliable: true
+```
+
+### Configuración de la variable de entorno
+
+```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_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_METRICS_USE_HTTP=true
+DD_DATABASE_MONITORING_METRICS_ADDITIONAL_ENDPOINTS="[{\"api_key\": \"apiKey2\", \"Host\": \"dbm-metrics-intake.datadoghq.com\", \"Port\": 443, \"is_reliable\": true}]"
+```
+
+{{% agent-dual-shipping %}}
+
+## Dispositivos de red
+
+### Configuración YAML
+
+Es necesaria la versión 6.29 o 7.29 del Agent o una posterior.
+
+En `datadog.yaml`:
+```yaml
+network_devices:
+ metadata:
+ use_http: true
+ additional_endpoints:
+ - api_key: "apiKey2"
+ Host: "ndm-intake.datadoghq.com"
+ Port: 443
+ is_reliable: true
+ snmp_traps:
+ forwarder:
+ use_http: true
+ additional_endpoints:
+ - api_key: "apiKey2"
+ Host: "ndm-intake.datadoghq.com"
+ Port: 443
+ is_reliable: true
+ netflow:
+ forwarder:
+ use_http: true
+ additional_endpoints:
+ - api_key: "apiKey2"
+ Host: "ndm-intake.datadoghq.com"
+ Port: 443
+ is_reliable: true
+```
+
+### Configuración de la variable de entorno
+
+```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}]"
+```
+
+{{% agent-dual-shipping %}}
+
+## Errores en la gestión de la seguridad en la nube
+
+### Configuración YAML
+
+En `datadog.yaml`:
+```yaml
+compliance_config:
+ endpoints:
+ use_http: true
+ additional_endpoints:
+ - api_key: "apiKey2"
+ Host: "https://-app.agent.datadoghq.eu"
+ Port: 443
+ is_reliable: true
+```
+
+### Configuración de la variable de entorno
+
+```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}]"
+```
+
+{{% agent-dual-shipping %}}
+
+## Amenazas para la gestión de la seguridad en la nube
+
+### Configuración YAML
+En `datadog.yaml`:
+```yaml
+runtime_security_config:
+ endpoints:
+ use_http: true
+ additional_endpoints:
+ - api_key: "apiKey2"
+ Host: "https://-app.agent.datadoghq.eu"
+ Port: 443
+ is_reliable: true
+```
+
+### Configuración de la variable de entorno
+
+```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}]"
+```
+
+{{% agent-dual-shipping %}}
+
+## Envío doble en 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`.
+
+```yaml
+# agents.useConfigMap -- Configures a configmap to provide the agent configuration. Use this in combination with the `agents.customAgentConfig` parameter.
+ useConfigMap: true
+
+ # 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
+ ## 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":
+ - apikey2
+ - apikey3
+ "https://app.datadoghq.eu":
+ - apikey4
+
+ logs_config:
+ use_http: true
+ additional_endpoints:
+ - api_key: "apiKey2"
+ Host: "{{< region-param key=agent_http_endpoint >}}"
+ 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].
+
+## Leer más
+
+{{< 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
diff --git a/content/es/agent/faq/_index.md b/content/es/agent/faq/_index.md
index f5bc20ea65f0b..730517da6af3b 100644
--- a/content/es/agent/faq/_index.md
+++ b/content/es/agent/faq/_index.md
@@ -8,20 +8,21 @@ kind: faq
title: FAQ del Agent
---
-{{< whatsnext desc="Lista de preguntas frecuentes:">}}
- {{< nextlink href="agent/faq/host-metrics-with-the-container-agent" >}}Alojar métricas con el Agent del contenedor{{< /nextlink >}}
- {{< nextlink href="agent/faq/agent-downgrade-major" >}}Cambiar a una versión principal anterior del Agent{{< /nextlink >}}
- {{< nextlink href="agent/faq/agent-downgrade-minor" >}}Cambiar a una versión secundaria anterior del Agent{{< /nextlink >}}
- {{< nextlink href="agent/faq/how-datadog-agent-determines-the-hostname" >}}¿Cómo determina Datadog el nombre de host del Agent?{{< /nextlink >}}
- {{< nextlink href="agent/faq/macos-agent-run-as-system-service" >}}¿Cómo configurar el Agent para ejecutarlo como servicio de sistema en macOS?{{< /nextlink >}}
- {{< nextlink href="agent/faq/error-restarting-agent-already-listening-on-a-configured-port" >}}Error al reiniciar el Agent: ya escucha en un puerto configurado{{< /nextlink >}}
- {{< nextlink href="agent/faq/kubernetes-secrets" >}}¿Cómo usar los secretos de Kubernetes para configurar mi clave de API?{{< /nextlink >}}
- {{< nextlink href="agent/faq/kubernetes-state-cluster-check" >}}¿Cómo ejecutar el check de kubernetes_state como un check de clúster?{{< /nextlink >}}
- {{< nextlink href="agent/faq/rpm-gpg-key-rotation-agent-6" >}}Rotación de claves GPG en paquetes RPM{{< /nextlink >}}
- {{< nextlink href="agent/faq/agent-v6-changes" >}}Cambios en el Datadog Agent v6{{< /nextlink >}}
- {{< nextlink href="agent/faq/ec2-use-win-prefix-detection" >}}Nombres de host de EC2 en Windows que empiezan por EC2AMAZ-{{< /nextlink >}}
- {{< nextlink href="agent/guide/auto_conf" >}}Configuración automática de Autodiscovery{{< /nextlink >}}
- {{< nextlink href="agent/guide/template_variables" >}}Variables de plantillas empleadas para Autodiscovery{{< /nextlink >}}
- {{< nextlink href="logs/guide/commonly-used-log-processing-rules" >}}Las reglas para procesar logs más utilizadas{{< /nextlink >}}
- {{< nextlink href="agent/faq/docker-hub" >}}Docker Hub{{< /nextlink >}}
+{{< whatsnext desc="List of Frequently Asked Questions:">}}
+{{< nextlink href="agent/faq/host-metrics-with-the-container-agent" >}}métricas de host con el Container Agent{{< /nextlink >}}
+{{< nextlink href="agent/faq/agent-downgrade-major" >}}Actualizar el Agent a una versión mayor anterior{{< /nextlink >}}
+{{< nextlink href="agent/faq/agent-downgrade-minor" >}}Desactualizar el Agent a una versión menor anterior{{< /nextlink >}}
+{{< nextlink href="agent/faq/how-datadog-agent-determines-the-hostname" >}}¿Cómo determina Datadog el nombre del host de Agent?{{< /nextlink >}}
+{{< nextlink href="agent/faq/macos-agent-run-as-system-service" >}}¿Cómo configuro Agent para que se ejecute como un servicio de sistema en macOS?{{< /nextlink >}}
+{{< nextlink href="agent/faq/error-restarting-agent-already-listening-on-a-configured-port" >}}Error al reiniciar Agent: Ya estás escuchando en un puerto configurado{{< /nextlink >}}
+{{< nextlink href="agent/faq/kubernetes-secrets" >}}¿Cómo utilizo secretos de Kubernetes para configurar mi clave API?{{< /nextlink >}}
+{{< nextlink href="agent/faq/kubernetes-state-cluster-check" >}}¿Cómo ejecuto el kubernetes_state check como check de clúster? {{< /nextlink >}}
+{{< nextlink href="agent/faq/rpm-gpg-key-rotation-agent-6" >}}Rotación de claves GPG de RPM{{< /nextlink >}}
+{{< nextlink href="agent/faq/linux-agent-2022-key-rotation" >}}Rotación de claves Linux Agent 2022{{< /nextlink >}}
+{{< nextlink href="agent/faq/agent-v6-changes" >}}Cambios Datadog Agent v6{{< /nextlink >}}
+{{< nextlink href="agent/faq/ec2-use-win-prefix-detection" >}}Nombres de host de Windows EC2 que comienzan con EC2AMAZ-{{< /nextlink >}}
+{{< nextlink href="agent/guide/auto_conf" >}}Autoconfiguración para Autodiscovery{{< /nextlink >}}
+{{< nextlink href="agent/guide/template_variables" >}}Variables de plantilla utilizadas para Autodiscovery{{< /nextlink >}}
+{{< nextlink href="logs/guide/commonly-used-log-processing-rules" >}}Reglas de procesamiento de log de utilizadas comúnmente{{< /nextlink >}}
+{{< nextlink href="agent/faq/docker-hub" >}}Docker Hub{{< /nextlink >}}
{{< /whatsnext >}}
\ No newline at end of file
diff --git a/content/es/agent/faq/agent-5-process-collection.md b/content/es/agent/faq/agent-5-process-collection.md
new file mode 100644
index 0000000000000..cf39e6db334f5
--- /dev/null
+++ b/content/es/agent/faq/agent-5-process-collection.md
@@ -0,0 +1,67 @@
+---
+kind: preguntas frecuentes
+private: true
+title: Recolección de proceso con Agent v5
+---
+
+## Configuración de Standard Agent
+
+**Live Processes está disponible en Datadog Agent versión 5.16.0 y superiores.**
+Consulta las instrucciones para la [Agent installation (instalación de Agent)][1] para obtener detalles específicos de la plataforma.
+
+**Nota**: Live Processes no está disponible para el método de instalación de origen del Agent.
+
+Una vez instalado Datadog Agent, activa Live Processes editando el [configuration file (archivo configuración)][2] en:
+
+```text
+/etc/dd-agent/datadog.conf
+```
+
+y añadiendo la siguiente línea a la sección `[Main (principal)]`:
+
+```yaml
+ process_agent_enabled: true
+```
+
+Una vez completada la configuración, [restart the Agent (reinicia el Agent)][3].
+**Nota**: Para recopilar información de Contenedor en la instalación estándar, el usuario de `dd-agent` necesita tener permisos para acceder a `docker.sock`.
+
+## Contenedor Docker
+
+Actualiza a la versión 5.16.0 o superior de la imagen Datadog Agent:
+
+ $ docker pull gcr.io/datadoghq/docker-dd-agent
+
+Sigue las instrucciones para [Docker-dd-Agent][4], introduciendo los siguientes atributos, además de cualquier otro ajuste personalizado que resulte apropiado:
+
+```text
+-v /etc/passwd:/etc/passwd:ro
+-e DD_PROCESS_AGENT_ENABLED=true
+```
+
+## Kubernetes DaemonSet
+
+En el manifiesto [dd-Agent.yaml][5] utilizado para crear el DaemonSet, añade las siguientes variables de entorno, montaje de volumen y volumen:
+
+```yaml
+ env:
+ - name: DD_PROCESS_AGENT_ENABLED
+ value: "true"
+ volumeMounts:
+ - name: passwd
+ mountPath: /etc/passwd
+ readOnly: true
+ volumes:
+ - hostPath:
+ path: /etc/passwd
+ name: passwd
+```
+
+Consulta las páginas de información estándar [DaemonSet installation (instalación de DaemonSet)][6] y [Docker-dd-Agent][4] para obtener más documentación.
+
+[1]: https://app.datadoghq.com/account/settings/agent/5?platform=overview
+[2]: /es/agent/faq/where-is-the-configuration-file-for-the-agent/
+[3]: /es/agent/configuration/agent-commands/#start-stop-restart-the-agent
+[4]: https://github.com/DataDog/docker-dd-agent
+[5]: https://github.com/DataDog/docker-dd-agent#configuration-files
+[6]: /es/agent/kubernetes/
\ No newline at end of file
diff --git a/content/es/agent/faq/agent-downgrade-major.md b/content/es/agent/faq/agent-downgrade-major.md
index 46f39bfd0d244..99090fd04bdfb 100644
--- a/content/es/agent/faq/agent-downgrade-major.md
+++ b/content/es/agent/faq/agent-downgrade-major.md
@@ -12,7 +12,7 @@ title: Cambiar a una versión principal anterior del Agent
En primer lugar, [desinstala la v7 del Agent del sistema][1].
-A continuación, si seguiste las instrucciones para [pasar de la v6 a la v7][2], ejecuta el siguiente comando de instalación del Agent para cambiar de la versión 7 a la versión 6 del Agent:
+A continuación, si has seguido las instrucciones para [upgrade from v6 to v7 (actualizar de v6 a v7)][2], ejecuta el siguiente comando de instalación Agent para bajar tu Agent de la versión 7 a la versión 6:
```shell
DD_API_KEY="" bash -c "$(curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script_agent6.sh)"
@@ -36,13 +36,13 @@ El comando funciona en todas las versiones compatibles de Amazon Linux, CentOS,
[1]: /es/agent/guide/how-do-i-uninstall-the-agent/
[2]: https://ddagent-windows-stable.s3.amazonaws.com/datadog-agent-6-latest.amd64.msi
[3]: https://app.datadoghq.com/organization-settings/api-keys
-[4]: https://s3.amazonaws.com/ddagent-windows-stable/installers.json
+[4]: https://ddagent-windows-stable.s3.amazonaws.com/installers_v2.json
{{% /tab %}}
{{% tab "MacOS" %}}
En primer lugar, [desinstala la v7 del Agent del sistema][1].
-A continuación, si seguiste las instrucciones para [pasar de la v6 a la v7][2], ejecuta el comando de instalación del Agent con la variable de entorno `DD_AGENT_MAJOR_VERSION=6` para cambiar de la versión 7 a la versión 6 del Agent:
+A continuación, si has seguido las instrucciones para [upgrade from v6 to v7 (actualizar de v6 a v7)][2], ejecuta el comando de instalación Agent con la variable de entorno `DD_AGENT_MAJOR_VERSION=6` para bajar tu Agent de la versión 7 a la versión 6:
```shell
DD_AGENT_MAJOR_VERSION=6 DD_API_KEY="" bash -c "$(curl -L https://s3.amazonaws.com/dd-agent/scripts/install_mac_os.sh)"
@@ -77,8 +77,9 @@ En esta guía, se asume que actualizaste a la v6 del Agent utilizando la [guía
sudo touch /usr/share/keyrings/datadog-archive-keyring.gpg
curl https://keys.datadoghq.com/DATADOG_APT_KEY_CURRENT.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch
- curl https://keys.datadoghq.com/DATADOG_APT_KEY_382E94DE.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch
+ curl https://keys.datadoghq.com/DATADOG_APT_KEY_C0962C7D.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch
curl https://keys.datadoghq.com/DATADOG_APT_KEY_F14F620E.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch
+ curl https://keys.datadoghq.com/DATADOG_APT_KEY_382E94DE.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch
```
3. Si ejecutas Ubuntu 14 o una versión anterior, o Debian 8 o una versión anterior, copia el conjunto de claves en `/etc/apt/trusted.gpg.d`:
@@ -128,7 +129,7 @@ En esta guía, se asume que actualizaste a la v6 del Agent utilizando la [guía
```shell
rm /etc/yum.repos.d/datadog-beta.repo
- [ ! -f /etc/yum.repos.d/datadog.repo ] && echo -e '[datadog]\nname = Datadog, Inc.\nbaseurl = https://yum.datadoghq.com/rpm/x86_64/ \nenabled=1\ngpgcheck=1\nrepo_gpgcheck=1\npriority=1\ngpgkey=https://keys.datadoghq.com/DATADOG_RPM_KEY_CURRENT.public\n https://keys.datadoghq.com/DATADOG_RPM_KEY_E09422B3.public\n https://keys.datadoghq.com/DATADOG_RPM_KEY_FD4BF915.public' | sudo tee /etc/yum.repos.d/datadog.repo
+ [ ! -f /etc/yum.repos.d/datadog.repo ] && echo -e '[datadog]\nname = Datadog, Inc.\nbaseurl = https://yum.datadoghq.com/rpm/x86_64/ \nenabled=1\ngpgcheck=1\nrepo_gpgcheck=1\npriority=1\ngpgkey=https://keys.datadoghq.com/DATADOG_RPM_KEY_CURRENT.public\n https://keys.datadoghq.com/DATADOG_RPM_KEY_B01082D3.public\n https://keys.datadoghq.com/DATADOG_RPM_KEY_FD4BF915.public\n https://keys.datadoghq.com/DATADOG_RPM_KEY_E09422B3.public' | sudo tee /etc/yum.repos.d/datadog.repo
```
**Nota**: Debido a un [error en dnf][1], utiliza `repo_gpgcheck=0` en lugar de `repo_gpgcheck=1` con RHEL/CentOS 8.1.
@@ -176,7 +177,7 @@ En esta guía, se asume que actualizaste a la v6 del Agent utilizando la [guía
Ejecuta el paquete del instalador del Agent para instalar la última versión 5.x; encontrarás las instrucciones
[en la página de integración del Datadog Agent][1].
-[1]: https://app.datadoghq.com/account/settings#agent/windows
+[1]: https://app.datadoghq.com/account/settings/agent/latest?platform=windows
{{% /tab %}}
{{% tab "MacOS" %}}
diff --git a/content/es/agent/faq/agent_v6_changes.md b/content/es/agent/faq/agent_v6_changes.md
index dae3a717f5568..a9290af375414 100644
--- a/content/es/agent/faq/agent_v6_changes.md
+++ b/content/es/agent/faq/agent_v6_changes.md
@@ -90,9 +90,9 @@ Las siguientes opciones de configuración del Agent han cambiado o han desaparec
| `use_curl_http_client` | |
| `collect_security_groups` | Obsoleta, función disponible con la [integración de AWS][6]. |
-[1]: /es/agent/guide/agent-configuration-files/#agent-main-configuration-file
+[1]: /es/agent/configuration/agent-configuration-files/#agent-main-configuration-file
[2]: /es/agent/guide/upgrade-to-agent-v6/
-[3]: /es/agent/proxy/
+[3]: /es/agent/configuration/proxy/
[4]: /es/integrations/disk/
[5]: /es/logs/
[6]: /es/integrations/amazon_web_services/
@@ -179,7 +179,7 @@ Las versiones anteriores logueaban en varios archivos (`collector.log`, `forward
## Interfaz
-La interfaz de línea de comandos del Agent v6 está basada en subcomandos. Para consultar la lista de subcomandos disponibles, ejecuta:
+La interfaz de línea de comandos de Agent v6 se basa en subcomandos. Para ver la lista de subcomandos disponibles, ejecuta:
```shell
--help
```
@@ -225,9 +225,9 @@ Si el comando del contenedor `service` no está disponible en tu sistema, utiliz
* En sistemas basados en `upstart`: `sudo start/stop/restart/status datadog-agent`
* Para sistemas basados en `systemd`: `sudo systemctl start/stop/restart/status datadog-agent`
-Si no sabes con seguridad qué sistema de inicio utiliza tu distribución de forma predeterminada, consulta la siguiente tabla:
+Si no sabes con seguridad qué sistema de inicialización utiliza tu distribución de forma predeterminada, consulta la siguiente tabla:
-| distribución \ sistema de inicio | upstart | systemd | sysvinit | Notas |
+| distribución \ sistema de inicialización | upstart | systemd | sysvinit | Notas |
|---------------------------------|---------------------------|---------------------------|-------------------------------------------|-------------------------------|
| Amazon Linux (<= 2017.09) | | | | |
| Amazon Linux 2 (>= 2017.12) | | | | |
@@ -378,7 +378,7 @@ Las siguientes opciones y etiquetas (tags) están obsoletas:
* `label_to_tag_prefix` se ha reemplazado por `kubernetes_pod_labels_as_tags`.
* Las etiquetas `container_alias` no se recopilan.
-* `kube_replicate_controller` solo se añade si el pod se crea mediante un controlador de replicación. En lugar de ello, utiliza la etiqueta de creador correspondiente (`kube_deployment`, `kube_daemon_set`, etc.).
+* `kube_replicate_controller` solo se añade si el pod ha sido creado por un controlador de replicación. En su lugar, utiliza una etiqueta (tag) creadora relevante como `kube_deployment`, o `kube_daemon_set`.
[1]: /es/integrations/kubelet/
[2]: /es/integrations/kube_apiserver_metrics/
@@ -561,12 +561,12 @@ Del mismo modo, puede que añadieras un paquete PIP para cumplir un requisito de
{{< partial name="whats-next/whats-next.html" >}}
-[1]: /es/agent/proxy/#using-the-agent-as-a-proxy
+[1]: /es/agent/configuration/proxy/#using-the-agent-as-a-proxy
[2]: https://github.com/DataDog/dd-agent/wiki/Using-custom-emitters
[3]: /es/agent/guide/dogstream/
[4]: /es/integrations/go-metro/
-[5]: /es/agent/guide/agent-log-files/
-[6]: /es/agent/guide/agent-commands/
+[5]: /es/agent/configuration/agent-log-files/
+[6]: /es/agent/configuration/agent-commands/
[7]: /es/getting_started/agent/autodiscovery/
[8]: https://github.com/DataDog/integrations-core/tree/master/datadog_checks_base
[9]: https://github.com/DataDog/datadog-agent/tree/main/docs/dev/checks
\ No newline at end of file
diff --git a/content/es/agent/faq/linux-agent-2022-key-rotation.md b/content/es/agent/faq/linux-agent-2022-key-rotation.md
new file mode 100644
index 0000000000000..eb516c8a04d1a
--- /dev/null
+++ b/content/es/agent/faq/linux-agent-2022-key-rotation.md
@@ -0,0 +1,196 @@
+---
+aliases:
+- /es/agent/guide/linux-agent-2022-key-rotation
+kind: guía
+private: true
+title: Rotación de claves del Agent de Linux de 2022
+---
+
+Como práctica habitual, Datadog rota periódicamente las claves y certificados utilizados para firmar los paquetes Agent de Datadog. Las siguientes claves GPG, utilizadas para firmar los paquetes RPM y DEB de Agent, llegan al final de su vida útil en junio de 2022 y se rotarán en abril de 2022:
+
+- La clave de firma RPM con hash [`A4C0B90D7443CF6E4E8AA341F1068E14E09422B3`][1] será rotada el 11 de abril a las 12:00 UTC de 2022 y será reemplazada por la clave con hash [`C6559B690CA882F023BDF3F63F4D1729FD4BF915`][2]. La primera versión de RPM después de esa fecha (6.36 y 7.36) requerirá la instalación de la nueva clave de confianza.
+- La clave de firma DEB con hash [`A2923DFF56EDA6E76E55E492D3A80E30382E94DE`][3] será rotada el 2 de mayo a las 12:00 UTC de 2022 y será reemplazada por la clave con hash [`D75CEA17048B9ACBF186794B32637D44F14F620E`][4]. APT comprueba la firma de metadatos del repositorio por lo que la nueva clave debe ser de confianza en esta fecha para instalar cualquier versión futura o existente de Agent desde `apt.datadoghq.com`.
+
+Los clientes que utilizan los paquetes RPM o DEB de Datadog podrían necesitar importar manualmente la nueva clave en sus sistemas para instalar o actualizar el Agent luego de que se produzca la rotación.
+
+
+Nota: Esto NO afecta a la funcionalidad de los Agents que se están ejecutando y solo limita la capacidad de instalar o actualizar a una versión más reciente de Agent. Además, esto no afecta a Agents de Linux, Windows o macOS dockerizados.
+
+
+## Instala métodos que confíen automáticamente en la nueva clave GPG
+
+Tu host confía automáticamente en la nueva clave (no se requiere ninguna acción adicional) si estás utilizando uno de los siguientes métodos de instalación:
+
+- [Script de instalación del Agent][5], v1.6.0 y posteriores (lanzado el 26 de julio de 2021)
+- [Cookbook de Chef][6], v4.11.0 y posteriores (lanzado el 10 de agosto de 2021)
+- [Rol de Ansible][7], v4.10.0 y posteriores (lanzado el 25 de mayo de 2021)
+- [Módulo Puppet][8], v3.13.0 y posteriores (lanzado el 11 de agosto de 2021)
+- [Fórmula SaltStack][9], v3.4 y posteriores (lanzada el 12 de agosto de 2021)
+- [Paquete de compilación de Heroku][10], v1.26 y posteriores (lanzado el 26 de mayo de 2021)
+- Plantillas de configuración de [Elastic Beanstalk][11], actualizadas a partir del 29 de marzo de 2021 (deben contener `DATADOG_RPM_KEY_FD4BF915.public` en `gpgkey`)
+- Agents contenedorizados (Docker/Kubernetes), cualquier versión
+- Agents de Windows/MacOS, cualquier versión
+
+Además, al instalar el paquete DEB de Agent versiones 6.35.1, v7.35.1 o posteriores en `apt` desde el repositorio `apt.datadoghq.com` se instala la versión 1.1.0 del [paquete `datadog-signing-keys`](#the-datadog-signing-keys-paquete), lo que garantiza automáticamente que tu host confiará en la nueva clave. Si tienes instalada la versión 1.1.0 o posterior de `datadog-signing-keys`, no es necesario realizar ninguna otra acción. Las versiones de `datadog-signing-keys` anteriores a la [versión 1.1.0](#datadog-signing-keys-version-110) no garantizan la plena preparación para la rotación de claves.
+
+Si estás instalando el paquete DEB de Agent desde un repositorio diferente o si no estás utilizando `apt` (o una herramienta similar para comprobar las firmas de metadatos del repositorio), tu sistema no necesita conocer las claves de firma de Datadog (no es necesaria ninguna acción adicional). Sin embargo, puedes beneficiarte del [paquete`datadog-signing-keys` ](#the-datadog-signing-keys-package).
+
+Si no estás seguro de si un host confía en la nueva clave de firma, puedes [comprobar](#check-if-a-host-trusts-the-new-gpg-key).
+
+Para los hosts que ejecutan versiones anteriores de los métodos de instalación mencionados más arriba o versiones anteriores del paquete DEB, Datadog recomienda actualizar el método de instalación a la última versión. Alternativamente, los usuarios de Debian y Ubuntu pueden actualizar Agent a la versión 7.31.0+. Si no, se puede [actualizar manualmente](#manual-update).
+
+## ¿Qué ocurre si no confío en la nueva clave antes de su rotación?
+
+Al intentar instalar o actualizar paquetes de Agent utilizando `apt`, `yum`, `dnf` o `zypper` desde `apt.datadoghq.com`/`yum.datadoghq.com` sin confiar en la nueva clave se produce un error.
+
+Algunos de los posibles errores son:
+
+```
+E: The repository 'https://apt.datadoghq.com stable Release' is not signed.
+```
+```
+E: Package 'datadog-agent' has no installation candidate
+```
+```
+The following signatures couldn't be verified because the public key is not available: NO_PUBKEY
+```
+```
+The GPG keys listed for the "Datadog, Inc." repository are already installed but they are not correct for this package.
+Check that the correct key URLs are configured for this repository.
+```
+```
+Public key for datadog-agent-7.35.1-1.x86_64.rpm is not installed. Failing package is: datadog-agent-1:7.35.1-1.x86_64
+```
+```
+Error: GPG check FAILED
+```
+
+En el caso de `apt`, esto afecta tanto a las nuevas versiones del Agent como a las ya existentes. En el caso de `yum`, `dnf` o `zypper`, es posible instalar las versiones existentes del Agent siempre que `repo_gpgcheck=0` esté configurado en el archivo `datadog.repo`.
+
+Esta rotación de claves no afecta a las instalaciones realizadas descargando manualmente los paquetes e instalándolos con `dpkg` o `rpm`. Esto puede causar una advertencia para `rpm`.
+
+## Actualización manual
+
+Datadog te incentiva a utilizar uno de los [métodos de instalación](#install-methods-that-automatically-trust-the-new-gpg-key) anteriores, que confían automáticamente en la nueva clave GPG, así como en todas las claves futuras. Si esto no es una opción, utiliza las siguientes instrucciones para descargar manualmente la nueva clave y confiar en ella.
+
+{{< tabs >}}
+{{% tab "Debian/Ubuntu" %}}
+
+Ejecuta los siguientes comandos en el host:
+
+```bash
+$ curl -o /tmp/DATADOG_APT_KEY_F14F620E https://keys.datadoghq.com/DATADOG_APT_KEY_F14F620E.public
+$ sudo apt-key add /tmp/DATADOG_APT_KEY_F14F620E
+$ sudo touch /usr/share/keyrings/datadog-archive-keyring.gpg
+$ cat /tmp/DATADOG_APT_KEY_F14F620E | sudo gpg --import --batch --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg
+$ sudo chmod a+r /usr/share/keyrings/datadog-archive-keyring.gpg
+```
+
+{{% /tab %}}
+{{% tab "RedHat/CentOS/SUSE" %}}
+
+Ejecuta los siguientes comandos en el host:
+
+```
+$ curl -o /tmp/DATADOG_RPM_KEY_FD4BF915 https://keys.datadoghq.com/DATADOG_RPM_KEY_FD4BF915.public
+$ sudo rpm --import /tmp/DATADOG_RPM_KEY_FD4BF915
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+## Comprueba si un host confía en la nueva clave GPG
+
+{{< tabs >}}
+{{% tab "Debian/Ubuntu" %}}
+
+Un host confía correctamente en la nueva clave si se cumple alguna de las siguientes condiciones:
+
+- El archivo `/usr/share/keyrings/datadog-archive-keyring.gpg` existe y el archivo de la lista de orígenes de Datadog (normalmente `/etc/apt/sources.list.d/datadog.list`) contiene la opción `[signed-by=/usr/share/keyrings/datadog-archive-keyring.gpg]`.
+- El archivo de la lista de orígenes de Datadog no contiene la opción `signed-by`, pero la versión 1.1.0 o posteriores de las `datadog-signing-keys` está instalada, por lo que aparecerá un archivo `/etc/apt/trusted.gpg.d/datadog-archive-keyring.gpg`.
+
+Los archivos `/usr/share/keyrings/datadog-archive-keyring.gpg` y, opcionalmente, `/etc/apt/trusted.gpg.d/datadog-archive-keyring.gpg`, se crean mediante un [método de instalación] compatible (#install-methods-that-automatically-trust-the-new-gpg-key) o instalando el [paquete`datadog-signing-keys`](#the-datadog-signing-keys-package). Asegúrate de que`datadog-signing-keys` [versión 1.1.0](#datadog-signing-keys-version-110) o posterior está instalado, a menos que utilices una de las [versiones del método de instalación mencionadas anteriormente](#install-methods-that-automatically-trust-the-new-gpg-key).
+
+{{% /tab %}}
+{{% tab "RedHat/CentOS/SUSE" %}}
+
+Ejecuta el siguiente comando en el host:
+
+```bash
+$ rpm -qa | grep gpg-pubkey-fd4bf915
+```
+
+Si el host confía en la clave, el comando tendrá un código de salida 0 y las siguientes salidas:
+
+```
+gpg-pubkey-fd4bf915-5f573efe
+```
+
+Si no, el comando devuelve un código de salida distinto de 0 sin salida.
+
+Si lo prefieres, comprueba si tu archivo `datadog.repo` contiene `https://keys.datadoghq.com/DATADOG_RPM_KEY_CURRENT.public` como una de las entradas `gpgkey`. Este archivo de claves se actualizará con la nueva clave en cuanto esté en uso.
+
+{{% /tab %}}
+{{< /tabs >}}
+
+## El paquete `datadog-signing-keys`
+
+
Nota: Esta sección solo se aplica a los usuarios del paquete DEB de Agent.
+
+Desde Agent v6.31.0 y v7.31.0, todos los paquetes DEB de Datadog dependen en alguna medida del paquete `datadog-signing-keys`. Desde Agent v6.35.1 y v 7.35.1, todos los paquetes DEB de Datadog dependen del paquete `datadog-signing-keys`, versión `1.1.0` .
+
+Una vez instalado, este paquete:
+
+- Configura las claves APT en el conjunto de claves `/usr/share/keyrings/datadog-archive-keyring.gpg` y, si es necesario, también lo hace en `/etc/apt/trusted.gpg.d/datadog-archive-keyring.gpg`. **Esto garantiza la confianza en la próxima clave de firma del repositorio de APT.** Para asegurarse de que todo está listo para la siguiente rotación de claves, recomendamos utilizar el paquete [`datadog-signing-keys` versión 1.1.0](#datadog-signing-keys-version-110).
+- Establece una [política `debsig-verify`][12] para los paquetes de Datadog. Esto te permite verificar firmas para paquetes DEB individuales localmente.
+
+Por ejemplo, para verificar que un paquete DEB descargado localmente ha sido creado y firmado por Datadog, ejecuta el siguiente comando:
+
+ ```bash
+ $ debsig-verify datadog-dogstatsd_7.34.0-1_amd64.deb
+ ```
+
+Si la verificación tiene éxito, `debsig-verify` sale con el estado `0` e imprime un mensaje: `debsig: Verified package from 'Datadog, Inc.' (Datadog).`. Los paquetes DEB de Datadog se integran a las firmas desde las versiones 6.26.0/7.26.0, por lo que esta verificación no funciona en versiones anteriores.
+
+Debido a que la dependencia del paquete de Agent versiones 6.31.0+/7.31.0 y posteriores de `datadog-signing-keys` es opcional, es posible que no se instale si:
+
+- Descarga manualmente el paquete DEB de Agent e instálalo sin tener el repositorio de Datadog configurado como origen APT.
+- Puedes replicar el paquete DEB del Agent en tu propio repositorio de APT sin replicar también el paquete `datadog-signing-keys`.
+- La configuración de tu APT está definida para no instalar paquetes recomendado. Por ejemplo, ejecutando `apt` con ` --no-install-recommends` or by having `APT::Install-Recommends "0"` in `apt.conf`.
+
+Los dos primeros métodos no requieren la verificación de los metadatos del repositorio de Datadog, por lo que la rotación de claves no tiene ningún impacto. Sin embargo, puede que te resulte útil utilizar los archivos de políticas `debsig-verify` incluidos en el paquete`datadog-signing-keys`.
+
+Con el tercer método, necesitas instalar explícitamente el paquete `datadog-signing-keys` si estás instalando el paquete de Agent de `apt.datadoghq.com` a `apt`. Como alternativa, utiliza uno de los [métodos de instalación](#install-methods-that-automatically-trust-the-new-gpg-key) compatibles.
+
+### Versión 1.1.0 de datadog-signing-keys
+
+
Nota: Esta sección solo se aplica a los usuarios del paquete DEB del Agent.
+
+Las versiones de `datadog-signing-keys` anteriores a la v1.1.0 no gestionan los siguientes casos de esquina:
+
+* En Ubuntu >= 16 y Debian >= 9, solo se creó `/usr/share/keyrings/datadog-archive-keyring.gpg`, pero no se creó `/etc/apt/trusted.gpg.d/datadog-archive-keyring.gpg`.
+* Si el archivo de listas de orígenes de APT (por ejemplo, `/etc/apt/sources.list.d/datadog.list`) no contiene la opción `[signed-by=/usr/share/keyrings/datadog-archive-keyring.gpg]`, APT nunca conocerá la nueva clave. Cualquier operación con el repositorio de Datadog fallará después de la rotación de claves.
+
+`datadog-signing-keys`, v1.1.0 soluciona este problema creando `/etc/apt/trusted.gpg.d/datadog-archive-keyring.gpg` cuando `/etc/apt/sources.list.d/datadog.list` no contiene la opción `signed-by` adecuada. Esto asegura que el caso anterior también está cubierto.
+
+Los usuarios de [métodos de instalación](#install-methods-that-automatically-trust-the-new-gpg-key) actualizados compatibles que utilicen las fuentes predeterminadas de Datadog siempre tienen configurada la opción `signed-by` adecuada, por lo que no se ven afectados por este problema. Datadog recomienda encarecidamente a todos los demás usuarios que actualicen a `datadog-signing-keys` v1.1.0 para asegurarse de estar preparados para la próxima rotación de claves. La instalación de DEB del Agent, versiones 6.35.1, v7.35.1 o posteriores, en `apt` desde el repositorio `apt.datadoghq.com` garantiza la instalación de `datadog-signing-keys` v1.1.0.
+
+## Impacto en usuarios de Agent v5
+
+Los usuarios de Agent v5 en sistemas basados en DEB (Debian/Ubuntu) también deben confiar en la nueva clave de firma para instalar o actualizar el Agent después de la fecha de rotación. Los usuarios de Agent v5 en sistemas basados en RPM (RedHat/CentOS/SUSE) no se ven afectados por esta rotación.
+
+**Nota**: Agent v5 utiliza Python 2, que llegó al final de su vida útil el 1 de enero de 2021. Datadog recomienda [actualizar a la versión 7 de Agent][13].
+
+[1]: https://keys.datadoghq.com/DATADOG_RPM_KEY_E09422B3.public
+[2]: https://keys.datadoghq.com/DATADOG_RPM_KEY_FD4BF915.public
+[3]: https://keys.datadoghq.com/DATADOG_APT_KEY_382E94DE.public
+[4]: https://keys.datadoghq.com/DATADOG_APT_KEY_F14F620E.public
+[5]: https://s3.amazonaws.com/dd-agent/scripts/install_script.sh
+[6]: https://github.com/DataDog/chef-datadog
+[7]: https://github.com/DataDog/ansible-datadog
+[8]: https://github.com/DataDog/puppet-datadog-agent
+[9]: https://github.com/DataDog/datadog-formula
+[10]: https://github.com/DataDog/heroku-buildpack-datadog
+[11]: https://docs.datadoghq.com/es/integrations/amazon_elasticbeanstalk
+[12]: https://manpages.ubuntu.com/manpages/jammy/man1/debsig-verify.1.html
+[13]: https://app.datadoghq.com/account/settings/agent/latest
\ No newline at end of file
diff --git a/content/es/agent/faq/macos-agent-run-as-system-service.md b/content/es/agent/faq/macos-agent-run-as-system-service.md
new file mode 100644
index 0000000000000..f65e205fdeb76
--- /dev/null
+++ b/content/es/agent/faq/macos-agent-run-as-system-service.md
@@ -0,0 +1,68 @@
+---
+further_reading:
+- link: /agent/
+ tag: Documentación
+ text: Más información sobre el Datadog Agent
+kind: faq
+title: ¿Cómo configuro el Agent para que se ejecute como un servicio de sistema en
+ macOS?
+---
+
+En macOS, el Datadog Agent se instala como un servicio para el usuario que ejecuta las instrucciones de instalación. Esto permite que la aplicación de la bandeja del sistema GUI del Datadog Agent funcione, si has iniciado sesión en la GUI de macOS como el usuario que realizó la instalación. El principal inconveniente es que el Agent solo se ejecuta cuando el usuario que realizó la instalación ha iniciado sesión en la GUI de macOS.
+
+Debido a esto, por defecto el Datadog Agent no se ejecuta en los casos en los que no se dispone de acceso GUI al host de macOS. Por lo tanto, se requieren pasos adicionales al instalar y ejecutar Datadog Agent en macOS sin acceso GUI.
+
+## Instalar
+
+1. Conéctate al host y [sigue las instrucciones de instalación del Agent ][1] para instalar el Datadog Agent en macOS.
+
+2. Ejecuta el siguiente script bash, como el usuario que ejecutó la instalación:
+
+ ```sh
+ #!/bin/bash
+
+ echo "Moving the Datadog Agent service for the $USER user to a system service"
+ # Move the per-user service definition installed by the Agent to a system service
+ sudo mv /Users/$USER/Library/LaunchAgents/com.datadoghq.agent.plist /Library/LaunchDaemons/com.datadoghq.agent.plist
+
+ echo "Setting the Datadog Agent service to run as the $USER user"
+ # By default, system services run as root.
+ # This plist file modification is needed to make the Agent not run as root, but as the current user.
+ sudo plutil -insert UserName -string "$USER" /Library/LaunchDaemons/com.datadoghq.agent.plist
+
+ echo "Setting permissions on the Datadog Agent service file"
+ # Put the correct permissions on the plist file.
+ # Otherwise launchctl will refuse running commands for this service.
+ sudo chown root:staff /Library/LaunchDaemons/com.datadoghq.agent.plist
+
+ echo "Enabling the Datadog Agent service"
+ # Enable the service: makes sure it runs on reboot
+ sudo launchctl enable system/com.datadoghq.agent
+
+ echo "Loading & launching the Datadog Agent service"
+ # Load the service: this starts the Agent
+ sudo launchctl load /Library/LaunchDaemons/com.datadoghq.agent.plist
+ ```
+
+Este script reconfigura el servicio del Datadog Agent para que se ejecute como daemon de lanzamiento, con las siguientes propiedades:
+- El servicio se inicia automáticamente al iniciar el host.
+- Los procesos del Agent se ejecutan como el usuario que ejecutó el script anterior (para evitar que se ejecuten como raíz).
+- La aplicación de la bandeja del sistema GUI del Datadog Agent no está disponible.
+
+
+## Operaciones
+
+El servicio del Datadog Agent se gestiona con `launchctl`. Una vez ejecutadas las instrucciones de instalación anteriores, gestiona el servicio del Agent con los siguientes comandos:
+
+| Descripción | Comando |
+|-------------------------------|---------------------------------------------------------------------------------------------------------------------------|
+| Iniciar el servicio del Agent | `sudo launchctl start com.datadoghq.agent` |
+| Detener la ejecución del servicio del Agent | `sudo launchctl stop com.datadoghq.agent` |
+| Estado del servicio del Agent | `sudo launchctl list com.datadoghq.agent` |
+| Desactivar el servicio del Agent | `sudo launchctl disable system/com.datadoghq.agent` |
+| Activar el servicio del Agent | `sudo launchctl enable system/com.datadoghq.agent && sudo launchctl load /Library/LaunchDaemons/com.datadoghq.agent.plist`|
+
+
+Desactivar el Agent impide que funcionen los comandos `list`, `start` y `stop`, y que se inicie el servicio del Agent al reiniciar.
+
+[1]: https://app.datadoghq.com/account/settings/agent/latest?platform=macos
\ No newline at end of file
diff --git a/content/es/agent/faq/rpm-gpg-key-rotation-agent-6.md b/content/es/agent/faq/rpm-gpg-key-rotation-agent-6.md
index 83dc4c457209e..c22dc5ba8f373 100644
--- a/content/es/agent/faq/rpm-gpg-key-rotation-agent-6.md
+++ b/content/es/agent/faq/rpm-gpg-key-rotation-agent-6.md
@@ -4,7 +4,7 @@ title: Rotación de claves GPG en paquetes RPM
---
@@ -19,7 +19,7 @@ La huella digital de la clave pública asociada es: `A4C0B90D7443CF6E4E8AA341F10
Si utilizas la última versión de uno de los siguientes métodos de instalación admitidos de forma oficial, tus hosts confiarán en la clave automáticamente y no tendrás que hacer nada más.
* [Página de instalación del Agent][2]
-* [Guía paso a paso de Chef][3]
+* [Cookbook de Chef][3]
* [Rol de Ansible][4]
* [Módulo de Puppet][5]
* [Fórmula SaltStack][6]
@@ -54,10 +54,12 @@ Ejecuta los siguientes comandos en el host:
```bash
$ curl -o /tmp/DATADOG_RPM_KEY_CURRENT.public https://keys.datadoghq.com/DATADOG_RPM_KEY_CURRENT.public
+$ curl -o /tmp/DATADOG_RPM_KEY_B01082D3.public https://keys.datadoghq.com/DATADOG_RPM_KEY_B01082D3.public
$ curl -o /tmp/DATADOG_RPM_KEY_FD4BF915.public https://keys.datadoghq.com/DATADOG_RPM_KEY_FD4BF915.public
$ curl -o /tmp/DATADOG_RPM_KEY_E09422B3.public https://keys.datadoghq.com/DATADOG_RPM_KEY_E09422B3.public
$ rpm --import /tmp/DATADOG_RPM_KEY_CURRENT.public
+$ rpm --import /tmp/DATADOG_RPM_KEY_B01082D3.public
$ rpm --import /tmp/DATADOG_RPM_KEY_FD4BF915.public
$ rpm --import /tmp/DATADOG_RPM_KEY_E09422B3.public
```
@@ -79,6 +81,7 @@ enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://keys.datadoghq.com/DATADOG_RPM_KEY_CURRENT.public
+ https://keys.datadoghq.com/DATADOG_RPM_KEY_B01082D3.public
https://keys.datadoghq.com/DATADOG_RPM_KEY_FD4BF915.public
https://keys.datadoghq.com/DATADOG_RPM_KEY_E09422B3.public
```
@@ -94,6 +97,7 @@ enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://keys.datadoghq.com/DATADOG_RPM_KEY_CURRENT.public
+ https://keys.datadoghq.com/DATADOG_RPM_KEY_B01082D3.public
https://keys.datadoghq.com/DATADOG_RPM_KEY_FD4BF915.public
https://keys.datadoghq.com/DATADOG_RPM_KEY_E09422B3.public
```
@@ -106,7 +110,7 @@ gpgkey=https://keys.datadoghq.com/DATADOG_RPM_KEY_CURRENT.public
**Nota**: Este método no funciona en sistemas basados en SUSE. En su lugar, utiliza el [comando de importación](#import-command).
[1]: https://yum.datadoghq.com
-[2]: https://app.datadoghq.com/account/settings#agent
+[2]: https://app.datadoghq.com/account/settings/agent/latest
[3]: https://github.com/DataDog/chef-datadog
[4]: https://github.com/DataDog/ansible-datadog
[5]: https://github.com/DataDog/puppet-datadog-agent
diff --git a/content/es/agent/guide/agent-5-autodiscovery.md b/content/es/agent/guide/agent-5-autodiscovery.md
index 5ecf94acd7514..91122fa7db23a 100644
--- a/content/es/agent/guide/agent-5-autodiscovery.md
+++ b/content/es/agent/guide/agent-5-autodiscovery.md
@@ -335,7 +335,7 @@ El Agent gestiona las siguientes variables de plantilla:
- `%%host_%%`: especifica el nombre de red que se utilizará cuando se conecte a varias redes. Por ejemplo, `%%host_bridge%%`, `%%host_swarm%%`, etc. Actúa como `%%host%%` si no se encuentra el nombre de red especificado.
- Puerto del contenedor: `port`
- - `%%port%%`: utiliza el puerto expuesto más alto **clasificado por orden numérico ascendente** (p. ej., 8443 para un contenedor que expone los puertos 80, 443 y 8443).
+ - `%%port%%`Utiliza el puerto expuesto más alto **ordenado numéricamente y en orden ascendente** (por ejemplo, 8443 para un contenedor que expone los puertos 80, 443 y 8443)
- `%%port_0%%`: utiliza el primer puerto **clasificado por orden numérico ascendente** (para el mismo contenedor, `%%port_0%%` se refiere al puerto 80 y `%%port_1%%`, al 443).
- Si tu puerto de destino es constante, Datadog recomienda que lo especifiques directamente, sin usar la variable `port`.
@@ -408,5 +408,5 @@ checks:
[19]: https://github.com/DataDog/integrations-core/blob/master/riak/datadog_checks/riak/data/auto_conf.yaml
[20]: https://github.com/DataDog/docker-dd-agent#configuration-files
[21]: https://github.com/DataDog/integrations-core/blob/master/apache/datadog_checks/apache/data/conf.yaml.example
-[22]: /es/agent/guide/agent-commands/#start-stop-restart-the-agent
+[22]: /es/agent/configuration/agent-commands/#start-stop-restart-the-agent
[23]: https://github.com/DataDog/integrations-core/blob/master/http_check/datadog_checks/http_check/data/conf.yaml.example
\ No newline at end of file
diff --git a/content/es/agent/guide/ansible_standalone_role.md b/content/es/agent/guide/ansible_standalone_role.md
new file mode 100644
index 0000000000000..2217860e54cf4
--- /dev/null
+++ b/content/es/agent/guide/ansible_standalone_role.md
@@ -0,0 +1,679 @@
+---
+dependencies:
+- https://github.com/DataDog/ansible-datadog/blob/main/README.md
+kind: documentation
+title: Configurar Ansible con un rol independiente de Datadog
+---
+El rol Ansible del Datadog Agent instala y configura el Datadog Agent y sus integraciones.
+
+## Rol Ansible frente a colección Ansible
+
+El rol Ansible del Datadog Agent está disponible a través de 2 canales diferentes:
+
+* Como parte de la colección Datadog, accesible bajo el nombre [datadog.dd](https://galaxy.ansible.com/Datadog/dd) en Ansible Galaxy (recomendado).
+* Como rol independiente, accesible bajo el nombre [datadog.datadog](https://galaxy.ansible.com/Datadog/datadog) en Ansible Galaxy (heredado).
+
+La versión `4` del rol y la versión `5` de la colección instalan el Datadog Agent v7 por defecto.
+
+## Python
+
+Ten en cuenta que las instrucciones de instalación de este documento describen la instalación del rol independiente Datadog. Para obtener instrucciones de instalación de la colección Datadog, consulta [el archivo README de la colección](https://github.com/ansible-collections/Datadog/blob/main/README.md). Las variables de configuración son las mismas tanto para el rol independiente como para el rol al que se accede a través de la colección.
+
+### Requisitos
+
+- Requiere Ansible 2.6 o una versión posterior.
+- Es compatible con la mayoría de distribuciones de Linux basadas en Debian y RHEL, con macOS y con Windows.
+- Si se utiliza con Ansible v2.10 o posterior para gestionar hosts de Windows, es necesario tener instalada la colección `ansible.windows`:
+
+ ```shell
+ ansible-galaxy collection install ansible.windows
+ ```
+- Si se utiliza con Ansible v2.10 o posterior para gestionar hosts openSUSE/SLES, es necesario tener instalada la colección `community.general`:
+
+ ```shell
+ ansible-galaxy collection install community.general
+ ```
+
+### Sensitive Data Scanner
+
+Instala el [rol de Datadog][1] desde Ansible Galaxy en tu servidor Ansible:
+
+```shell
+ansible-galaxy install datadog.datadog
+```
+
+Para desplegar el Datadog Agent en hosts, añade el rol de Datadog y tu clave de API a tu cuaderno de estrategias:
+
+```text
+- hosts: servers
+ roles:
+ - { role: datadog.datadog, become: yes }
+ vars:
+ datadog_api_key: ""
+```
+
+La clave de API es necesaria y su ausencia hace que el rol falle. Si deseas proporcionarla de otra forma, fuera del control de Ansible, especifica una clave de marcador de posición y sustitúyela posteriormente.
+
+## Variables del rol
+
+Estas variables proporcionan una configuración adicional durante la instalación del Datadog Agent. Deben especificarse en la sección `vars` de tu playbook.
+
+| Variable | Descripción |
+|---------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `datadog_api_key` | Tu clave de API de Datadog. **Esta variable es obligatoria a partir de la v4.21**.|
+| `datadog_site` | El sitio de ingesta de Datadog al que enviar los datos del Agent. Se establece por defecto como `datadoghq.com`, así que configúralo como `datadoghq.eu` para enviar los datos al sitio de la UE. Esta opción solo está disponible en versiones del Agent posteriores a la 6.6.0.|
+| `datadog_agent_flavor` | Anula el paquete de Debian / RedHat predeterminado en las instalaciones IoT de la RPI. Se establece por defecto como "datadog-agent", así que usa "datadog-iot-agent" en la RPI.|
+| `datadog_agent_version` | La versión fija del Agent a instalar (opcional, pero recomendada), por ejemplo: `7.16.0`. La configuración de `datadog_agent_major_version` no es necesaria si se utiliza `datadog_agent_version`.|
+| `datadog_agent_major_version` | La versión principal del Agent que hay que instalar. Los valores posibles son 5, 6 y 7 (por defecto). Si se define `datadog_agent_version`, tiene prioridad. De lo contrario, se instala la última versión principal especificada. El parámetro `datadog_agent_major_version` no es necesario si se usa `datadog_agent_version`.|
+| `datadog_checks` | Configuración YAML para aplicar los checks del Agent en: - `/etc/datadog-agent/conf.d/.d/conf.yaml` en el Agent v6 y v7, - `/etc/dd-agent/conf.d` en el Agent v5.|
+| `datadog_disable_untracked_checks` | Configúrala como `true` para eliminar todos los checks que no estén presentes en `datadog_checks` y `datadog_additional_checks`.|
+| `datadog_additional_checks` | Lista de checks adicionales que no se eliminan si se configura `datadog_disable_untracked_checks` como `true`.|
+| `datadog_disable_default_checks` | Configúrala como `true` para eliminar todos los checks predeterminados.|
+| `datadog_config` | Define la configuración del Datadog Agent. El rol escribe la configuración en la [ubicación correcta según el sistema operativo](https://docs.datadoghq.com/agent/guide/agent-configuration-files/?tab=agentv6v7#agent-main-configuration-file). Para ver una lista completa de opciones de configuración, consulta la [plantilla `datadog.yaml` en el repositorio de GitHub datadog-agent](https://github.com/DataDog/datadog-agent/blob/main/pkg/config/config_template.yaml).|
+| `datadog_config_ex` | (Opcional) Secciones INI adicionales para `/etc/dd-agent/datadog.conf` (solo para el Agent v5).|
+| `datadog_apt_repo` | Anula el repositorio `apt` predeterminado de Datadog. Asegúrate de usar la opción `signed-by` si los metadatos del repositorio se firman usando las claves de firma de Datadog: `deb [signed-by=/usr/share/keyrings/datadog-archive-keyring.gpg] https://yourrepo`.|
+| `datadog_apt_cache_valid_time` | Anula el tiempo de expiración predeterminado de la caché de APT (1 hora, por defecto).|
+| `datadog_apt_key_url_new` | Anula la localización de la cual obtener la clave `apt` de Datadog (la variable obsoleta `datadog_apt_key_url` se refiere a una clave caducada que ha sido eliminada del rol). Se espera que la URL sea un conjunto de claves GPG que contenga las claves `382E94DE`, `F14F620E` y `C0962C7D`.|
+| `datadog_yum_repo_config_enabled` | Establécelo en `false` para evitar la configuración de un repositorio de Datadog `yum` (por defecto `true`). ATENCIÓN: Se desactivará la actualización automática de las claves GPG.|
+| `datadog_yum_repo` | Anula el repositorio `yum` predeterminado de Datadog.|
+| `datadog_yum_repo_proxy` | Establece una URL proxy para utilizarla en la configuración `yum` del repositorio de Datadog.|
+| `datadog_yum_repo_proxy_username` | Establece un nombre de usuario proxy para utilizarlo en la configuración `yum` del repositorio de Datadog.|
+| `datadog_yum_repo_proxy_password` | Establece una contraseña proxy para utilizarla en la configuración `yum` del repositorio de Datadog.|
+| `datadog_yum_repo_gpgcheck` | Anula el valor `repo_gpgcheck` predeterminado (vacío). Si está vacío, el valor se configura de forma dinámica como `yes` cuando no se usa el valor personalizado `datadog_yum_repo` y el sistema no es RHEL/CentOS 8.1 (debido a [un error](https://bugzilla.redhat.com/show_bug.cgi?id=1792506) en el parámetro dnf); en caso contrario, se configura como `no`. **Nota**: La verificación de la firma de los metadatos del repositorio siempre está desactivada en el Agent v5.|
+| `datadog_yum_gpgcheck` | Anula el valor `gpgcheck` predeterminado (`yes`), así que usa `no` para desactivar la verificación de la firma del paquete GPG.|
+| `datadog_yum_gpgkey` | **Eliminada en la versión 4.18.0** Anula la URL predeterminada por la clave `yum` de Datadog que se usa para verificar los paquetes del Agent v5 y v6 (hasta la versión 6.13). (ID de clave: `4172A230`).|
+| `datadog_yum_gpgkey_e09422b3` | Anula la URL predeterminada por la clave `yum` de Datadog que se usa para verificar los paquetes del Agent v6.14 (y versiones posteriores). (ID de clave: `E09422B3`).|
+| `datadog_yum_gpgkey_e09422b3_sha256sum` | Anula la suma de comprobación predeterminada de la clave `datadog_yum_gpgkey_e09422b3`.|
+| `datadog_zypper_repo` | Anula el repositorio `zypper` predeterminado de Datadog.|
+| `datadog_zypper_repo_gpgcheck` | Anula el valor `repo_gpgcheck` predeterminado (vacío). Si está vacío, el valor se configura de forma dinámica como `yes` cuando no se usa el valor personalizado `datadog_zypper_repo`; en caso contrario, se configura como `no`. **Nota**: La verificación de la firma de los metadatos del repositorio siempre está desactivada en el Agent v5.|
+| `datadog_zypper_gpgcheck` | Anula el valor `gpgcheck` predeterminado (`yes`), así que usa `no` para desactivar la verificación de la firma del paquete GPG.|
+| `datadog_zypper_gpgkey` | **Eliminada en la versión 4.18.0** Anula la URL predeterminada por la clave `zypper` de Datadog que se usa para verificar los paquetes del Agent v5 y v6 (hasta la versión 6.13). (ID de clave: `4172A230`).|
+| `datadog_zypper_gpgkey_sha256sum` | **Eliminada en la versión 4.18.0** Anula la suma de comprobación predeterminada de la clave `datadog_zypper_gpgkey`.|
+| `datadog_zypper_gpgkey_e09422b3` | Anula la URL predeterminada por la clave `zypper` de Datadog que se usa para verificar los paquetes del Agent v6.14 (y versiones posteriores). (ID de clave: `E09422B3`).|
+| `datadog_zypper_gpgkey_e09422b3_sha256sum` | Anula la suma de comprobación predeterminada de la clave `datadog_zypper_gpgkey_e09422b3`.|
+| `datadog_agent_allow_downgrade` | Establécelo en `yes` para permitir una degradación del Agent (utilizar con precaución, ver `defaults/main.yml` para más detalles). **Nota**: Las degradaciones no son compatibles con las plataformas de Windows.|
+| `datadog_enabled` | Configúrala como `false` para evitar que se inicie el servicio `datadog-agent` (se establece por defecto como `true`).|
+| `datadog_additional_groups` | Una lista, o una cadena que contiene una lista de grupos adicionales separados entre sí por comas, para el `datadog_user` (solo en Linux).|
+| `datadog_windows_ddagentuser_name` | El nombre del usuario de Windows que hay que crear/usar, en formato `\` (solo en Windows).|
+| `datadog_windows_ddagentuser_password` | La contraseña usada para crear el usuario o registrar el servicio (solo en Windows).|
+| `datadog_apply_windows_614_fix` | Define si se debe o no descargar y aplicar el archivo mencionado en `datadog_windows_614_fix_script_url` (solo en Windows). Consulta https://dtdg.co/win-614-fix para obtener más información. Puedes configurarla como `false` siempre que tus hosts no estén usando el Datadog Agent 6.14.\*.|
+| `datadog_macos_user` | El nombre del usuario con el que hay que ejecutar el Agent. Tiene que ser un usuario existente, no se creará de forma automática. Se establece por defecto como `ansible_user` (solo en macOS).|
+| `datadog_macos_download_url` | Anula la URL para descargar el instalador DMG (solo en macOS).|
+| `datadog_apm_instrumentation_enabled` | Configura una instrumentación APM. Los valores posibles son: - `host`: Tanto el Agent como su servicios se ejecutan en un host. - `docker`: El Agent y sus servicios se ejecutan en contenedores de Docker separados en el mismo host. - `all`: Es compatible con todos los escenarios anteriores para `host` y `docker` al mismo tiempo.|
+| `datadog_apm_instrumentation_libraries` | Lista de bibliotecas APM a instalar si se activa la inyección de `host` o `docker` (por defecto es `["java", "js", "dotnet", "python", "ruby"]`). Puedes encontrar los valores disponibles en [Inyectar bibliotecas localmente][24].|
+| `datadog_apm_instrumentation_docker_config` | Anula la configuración APM de Docker. Lee [Configurar inyección Docker][23] para obtener más información.|
+
+### Kubernetes
+
+Para descargar una integración (check) de Datadog, añade una entrada en la sección `datadog_checks`. La clave de primer nivel es el nombre del check, mientras que el valor es la carga útil del YAML que hay que escribir en el archivo de configuración. A continuación, te mostramos algunos ejemplos.
+
+Para instalar o retirar un integración, consulta el [párrafo] `datadog_integration`(#integration-installation)
+
+#### Check del proceso
+
+Para definir dos instancias del check `process`, usa la configuración de abajo. Esto creará los archivos de configuración correspondientes:
+
+* Agent v6 y v7: `/etc/datadog-agent/conf.d/process.d/conf.yaml`
+* Agent v5: `/etc/dd-agent/conf.d/process.yaml`
+
+```yml
+ datadog_checks:
+ process:
+ init_config:
+ instances:
+ - name: ssh
+ search_string: ['ssh', 'sshd']
+ - name: syslog
+ search_string: ['rsyslog']
+ cpu_check_interval: 0.2
+ exact_match: true
+ ignore_denied_access: true
+```
+
+#### Check personalizado
+
+Para configurar un check personalizado, usa la configuración de abajo. Esto creará los archivos de configuración correspondientes.
+
+- Agent v6 y v7: `/etc/datadog-agent/conf.d/my_custom_check.d/conf.yaml`
+- Agent v5: `/etc/dd-agent/conf.d/my_custom_check.yaml`
+
+```yml
+ datadog_checks:
+ my_custom_check:
+ init_config:
+ instances:
+ - some_data: true
+```
+
+##### Checks personalizados de Python
+
+Para transferir un check de Python al cuaderno de estrategias, usa la configuración de abajo.
+
+Esta configuración requiere que la [estrategia y el rol][12] de Datadog sean parte de un cuaderno de estrategias más grande, en el que el valor transferido sea la ruta de archivo relativa a la tarea real en [Linux][13] o [Windows][14].
+
+Solo está disponible para Agent v6 o posterior.
+
+La clave debería ser el nombre del archivo creado en el directorio de checks `checks.d/{{ item }}.py`:
+
+```yml
+ datadog_checks:
+ my_custom_check:
+ init_config:
+ instances:
+ - some_data: true
+ datadog_custom_checks:
+ my_custom_check: '../../../custom_checks/my_custom_check.py'
+```
+
+#### Cluster Agent
+
+Cuando se usa Autodiscovery, no se realiza ningún previo o posterior procesamiento en el YAML. Esto quiere decir que todas las secciones del YAML se añaden al archivo de configuración final, incluidos los `autodiscovery identifiers`.
+
+En el siguiente ejemplo, se configura el check de PostgreSQL mediante **Autodiscovery**:
+
+```yml
+ datadog_checks:
+ postgres:
+ ad_identifiers:
+ - db-master
+ - db-slave
+ init_config:
+ instances:
+ - host: %%host%%
+ port: %%port%%
+ username: username
+ password: password
+```
+
+Para más información sobre [Autodiscovery][3], consulta la documentación de Datadog.
+
+### Python
+
+Para activar la recopilación de trazas con el Agent v6 o v7, usa la siguiente configuración:
+
+```yaml
+datadog_config:
+ apm_config:
+ enabled: true
+```
+
+Para activar la recopilación de trazas con el Agent v5, usa la siguiente configuración:
+
+```yaml
+datadog_config:
+ apm_enabled: "true" # has to be a string
+```
+
+### Live Processes
+
+Para activar la recopilación de [Live Processes][6] con el Agent v6 o v7, usa la siguiente configuración:
+
+```yml
+datadog_config:
+ process_config:
+ enabled: "true" # type: string
+```
+
+`enabled` puede ser `"true"`, `"false"` (solo en la recopilación de contenedores) o `"disabled"` (este valor desactiva los Live Processes por completo).
+
+#### Audit Trail (trazas de auditoría)
+
+Estas son las variables disponibles para los Live Processes:
+
+* `scrub_args`: Permite borrar los argumentos sensibles de una línea de comandos del proceso (se establece por defecto como `true`).
+* `custom_sensitive_words`: Expande la lista predeterminada de palabras sensibles que utiliza el limpiador de líneas de comandos.
+
+#### Sondeo del sistema
+
+El sondeo del sistema se configura en la variable `system_probe_config`. Cualquier variable anidada bajo ella se incluye en `system-probe.yaml`, en la sección `system_probe_config`.
+
+La herramienta [Network Performance Monitoring][7] (NPM) se configura en la variable `network_config`. Cualquier variable anidada bajo ella se incluye en `system-probe.yaml`, en la sección `network_config`.
+
+La herramienta [Cloud Workload Security][8] se configura en la variable `runtime_security_config`. Cualquier variable anidada bajo ella se incluye en `system-probe.yaml` y `security-agent.yaml`, en la sección `runtime_security_config`.
+
+La herramienta [Universal Service Monitoring][17] (USM) se configura en la variable `service_monitoring_config`. Cualquier variable anidada bajo ella se incluye en `system-probe.yaml`, en la sección `service_monitoring_config`.
+
+[Cumplimiento][18] se configura bajo la variable `compliance_config`. Cualquier variable anidada debajo se escribe en `security-agent.yaml`, en la sección `compliance_config`.
+
+**Nota para usuarios de Windows**: Windows admite NPM con el Agent v6.27/v7.27 (y posteriores). Esta herramienta se distribuye como un componente opcional que solo se instala si `network_config.enabled` está configurado como true en el momento de instalar o actualizar el Agent. Por este motivo, las instalaciones existentes podrían requerir la desinstalación y reinstalación del Agent para instalar el componente NPM, a no ser que se actualice el Agent al mismo tiempo.
+
+#### Ejemplo de configuración
+
+```yml
+datadog_config:
+ process_config:
+ enabled: "true" # type: string
+ scrub_args: true
+ custom_sensitive_words: ['consul_token','dd_api_key']
+system_probe_config:
+ sysprobe_socket: /opt/datadog-agent/run/sysprobe.sock
+network_config:
+ enabled: true
+service_monitoring_config:
+ enabled: true
+runtime_security_config:
+ enabled: true
+```
+
+**Nota**: Esta configuración funciona con el Agent 6.24.1/v7.24.1 (y posteriores). Si utilizas una versión anterior del Agent, consulta la documentación acerca de [Network Performance Monitoring][9] para descubrir cómo habilitar el sondeo del sistema.
+
+En Linux, una vez que completes esta modificación, sigue los pasos que aparecen a continuación si instalaste una versión del Agent anterior a las versiones 6.18.0 o 7.18.0:
+
+1. Inicia el sondeo del sistema: `sudo service datadog-agent-sysprobe start` **Nota**: Si el contenedor de servicio no está disponible en tu sistema, ejecuta el siguiente comando: `sudo initctl start datadog-agent-sysprobe`.
+2. [Reinicia el Agent][10]: `sudo service datadog-agent restart`.
+3. Habilita el sondeo del sistema para que se inicie durante el arranque: `sudo service enable datadog-agent-sysprobe`.
+
+Para llevar a cabo una configuración manual, consulta la documentación acerca de [NPM][9].
+
+#### Agent v5
+
+Para activar la recopilación de [Live Processes][6] con Agent v5, usa la siguiente configuración:
+
+```yml
+datadog_config:
+ process_agent_enabled: true
+datadog_config_ex:
+ process.config:
+ scrub_args: true
+ custom_sensitive_words: ","
+```
+
+## Solucionar problemas
+
+Por defecto, la versión principal actual del rol de Datadog de Ansible instala el Agent v7. Las variables `datadog_agent_version` y `datadog_agent_major_version` sirven para controlar la versión del Agent instalada.
+
+En las versiones de este rol posteriores a la v4, cuando se usa `datadog_agent_version` para anclar una versión específica del Agent, el rol genera nombres de versiones según el SO para cumplir con las normas de nomenclatura de los sistemas operativos compatibles. Ejemplo:
+
+- `1:7.16.0-1` para sistemas basados en Debian y SUSE
+- `7.16.0-1` para sistemas basados en RedHat
+- `7.16.0-1` para macOS
+- `7.16.0` para Windows
+
+Esto hace posible dirigirse a hosts con distintos sistemas operativos en una sola ejecución de Ansible. Ejemplo:
+
+| Versión del Agent | Instala | Sistema |
+|-------------------------------------|--------------|-----------------------|
+| `datadog_agent_version: 7.16.0` | `1:7.16.0-1` | Basado en Debian y SUSE |
+| `datadog_agent_version: 7.16.0` | `7.16.0-1` | Basado en RedHat |
+| `datadog_agent_version: 7.16.0` | `7.16.0-1` | macOS |
+| `datadog_agent_version: 7.16.0` | `7.16.0` | recopilación de logs |
+| `datadog_agent_version: 1:7.16.0-1` | `1:7.16.0-1` | Basado en Debian y SUSE |
+| `datadog_agent_version: 1:7.16.0-1` | `7.16.0-1` | Basado en RedHat |
+| `datadog_agent_version: 1:7.16.0-1` | `7.16.0` | recopilación de logs |
+
+**Nota**: Si no se proporciona la versión, el rol usa `1` como epoch y `1` como número de versión.
+
+**Agent v5 (versión antigua)**:
+
+El rol de Datadog de Ansible es compatible con el Datadog Agent v5 únicamente en Linux. Para instalar el Agent v5, usa `datadog_agent_major_version: 5` para usar la última versión del Agent v5 o cambia `datadog_agent_version` a una versión específica del Agent v5. **Nota**: La variable `datadog_agent5` está obsoleta y, por tanto, se ha eliminado.
+
+### Repositorios
+
+#### Linux
+
+Cuando las variables `datadog_apt_repo`, `datadog_yum_repo` y `datadog_zypper_repo` no están definidas, se usan los repositorios oficiales de Datadog para la versión principal que se define en `datadog_agent_major_version`:
+
+| # | Repositorio apt predeterminado | Repositorio yum predeterminado | Repositorio zypper predeterminado |
+|---|-------------------------------------------|------------------------------------|-----------------------------------------|
+| 5 | deb https://apt.datadoghq.com stable main | https://yum.datadoghq.com/rpm | https://yum.datadoghq.com/suse/rpm |
+| 6 | deb https://apt.datadoghq.com stable 6 | https://yum.datadoghq.com/stable/6 | https://yum.datadoghq.com/suse/stable/6 |
+| 7 | deb https://apt.datadoghq.com stable 7 | https://yum.datadoghq.com/stable/7 | https://yum.datadoghq.com/suse/stable/7 |
+
+Para anular este comportamiento predeterminado, cambia las variables por algo que no sea una cadena vacía.
+
+Si antes usabas las variables del Agent v5, usa las variables **nuevas** de abajo con el parámetro `datadog_agent_major_version` establecido como `5` o con `datadog_agent_version` anclado a una versión específica del Agent v5.
+
+| Anteriores | Nuevas |
+|------------------------------|-----------------------|
+| `datadog_agent5_apt_repo` | `datadog_apt_repo` |
+| `datadog_agent5_yum_repo` | `datadog_yum_repo` |
+| `datadog_agent5_zypper_repo` | `datadog_zypper_repo` |
+
+Desde la versión 4.9.0, la variable `use_apt_backup_keyserver` ya no existe, ya que las claves APT se obtienen a partir de https://keys.datadoghq.com.
+
+#### recopilación de logs
+
+Cuando la variable `datadog_windows_download_url` no está definida, se usa el paquete MSI oficial de Windows correspondiente a `datadog_agent_major_version`:
+
+| Versión del Agent | URL predeterminada del paquete MSI de Windows |
+|---------------|----------------------------------------------------------------------------------|
+| 6 | https://s3.amazonaws.com/ddagent-windows-stable/datadog-agent-6-latest.amd64.msi |
+| 7 | https://s3.amazonaws.com/ddagent-windows-stable/datadog-agent-7-latest.amd64.msi |
+
+Para anular el comportamiento por defecto, cambia esta variable a un valor distinto de una cadena vacía.
+
+#### macOS
+
+Cuando la variable `datadog_macos_download_url` no está definida, se usa el paquete DMG oficial de macOS correspondiente a `datadog_agent_major_version`:
+
+| Versión del Agent | URL predeterminada del paquete DMG de macOS |
+|---------------|--------------------------------------------------------------|
+| 6 | https://s3.amazonaws.com/dd-agent/datadog-agent-6-latest.dmg |
+| 7 | https://s3.amazonaws.com/dd-agent/datadog-agent-7-latest.dmg |
+
+Para anular el comportamiento por defecto, cambia esta variable a un valor distinto de una cadena vacía.
+
+### Pasar a una versión posterior
+
+Para pasar del Agent v6 al v7, usa `datadog_agent_major_version: 7` para instalar la última versión o configura `datadog_agent_version` como una versión específica del Agent v7. Aplica una lógica parecida para pasar del Agent v5 al v6.
+
+#### Instalación de la integración
+
+**Disponible para el Agent v6.8 (y posteriores)**
+
+Utiliza el recurso `datadog_integration` para instalar una versión específica de una integración de Datadog. Ten en cuenta que el Agent viene con sus [integraciones principales][19] ya instaladas. Este comando es útil para actualizar una integración específica sin actualizar todo el Agent. Para obtener más información, consulta [Gestión de integraciones][4].
+
+Si deseas configurar una integración, consulta el [párrafo](#integrations) `datadog_checks`
+
+Acciones disponibles:
+
+- `install`: Instala una versión específica de la integración.
+- `remove`: Elimina una integración.
+
+##### Integraciones de terceros
+
+Las integraciones de [Datadog community][20] y [Datadog Marketplace][15] pueden instalarse con el recurso `datadog_integration`. **Nota**: Estas integraciones se consideran "de terceros" y, por lo tanto, necesitan que se configure `third_party: true` (consulta el ejemplo siguiente).
+
+##### Sintaxis
+
+```yml
+ datadog_integration:
+ :
+ action:
+ version:
+```
+
+Para instalar integraciones de terceros, establece `third_party` como true:
+
+```yml
+ datadog_integration:
+ :
+ action:
+ version:
+ third_party: true
+```
+
+##### Ejemplo
+
+Este ejemplo instala la versión `1.11.0` de la integración de ElasticSearch y elimina la integración de `postgres`.
+
+```yml
+ datadog_integration:
+ datadog-elastic:
+ action: install
+ version: 1.11.0
+ datadog-postgres:
+ action: remove
+```
+
+Para ver las versiones disponibles de las integraciones de Datadog, consulta el archivo `CHANGELOG.md` en el [repositorio integrations-core][5].
+
+### Pasar a una versión anterior
+
+Para cambiar a una versión anterior del Agent:
+
+1. Define `datadog_agent_version` como una versión específica. Ejemplo: `5.32.5`.
+2. Configura `datadog_agent_allow_downgrade` como `yes`.
+
+**Notas:**
+
+- No es posible cambiar a versiones anteriores en plataformas con Windows.
+
+## Cuadernos de estrategias
+
+A continuación, encontrarás algunos ejemplos de cuadernos de estrategias que pueden ser útiles cuando uses el rol de Datadog de Ansible.
+
+El siguiente ejemplo envía datos al sitio de Datadog de EE. UU. (por defecto), activa logs, NPM y configura algunos checks.
+
+```yml
+- hosts: servers
+ roles:
+ - { role: datadog.datadog, become: yes }
+ vars:
+ datadog_api_key: ""
+ datadog_agent_version: "7.16.0"
+ datadog_config:
+ tags:
+ - ":"
+ - ":"
+ log_level: INFO
+ apm_config:
+ enabled: true
+ logs_enabled: true # available with Agent v6 and v7
+ datadog_checks:
+ process:
+ init_config:
+ instances:
+ - name: ssh
+ search_string: ['ssh', 'sshd' ]
+ - name: syslog
+ search_string: ['rsyslog' ]
+ cpu_check_interval: 0.2
+ exact_match: true
+ ignore_denied_access: true
+ ssh_check:
+ init_config:
+ instances:
+ - host: localhost
+ port: 22
+ username: root
+ password:
+ sftp_check: True
+ private_key_file:
+ add_missing_keys: True
+ nginx:
+ init_config:
+ instances:
+ - nginx_status_url: http://example.com/nginx_status/
+ tags:
+ - "source:nginx"
+ - "instance:foo"
+ - nginx_status_url: http://example2.com:1234/nginx_status/
+ tags:
+ - "source:nginx"
+ - ":"
+
+ #Log collection is available on Agent 6 and 7
+ logs:
+ - type: file
+ path: /var/log/access.log
+ service: myapp
+ source: nginx
+ sourcecategory: http_web_access
+ - type: file
+ path: /var/log/error.log
+ service: nginx
+ source: nginx
+ sourcecategory: http_web_access
+ # datadog_integration is available on Agent 6.8+
+ datadog_integration:
+ datadog-elastic:
+ action: install
+ version: 1.11.0
+ datadog-postgres:
+ action: remove
+ network_config:
+ enabled: true
+```
+
+### Agent v6
+
+Este ejemplo instala el Agent v6 más reciente:
+
+```yml
+- hosts: servers
+ roles:
+ - { role: datadog.datadog, become: yes }
+ vars:
+ datadog_agent_major_version: 6
+ datadog_api_key: ""
+```
+
+### Configurar el sitio
+
+Si usas un sitio distinto al predeterminado, `datadoghq.com`, ajusta la variable `datadog_site` a la URL correcta (p. ej., `datadoghq.eu`, `us3.datadoghq.com`).
+
+Este ejemplo envía datos al sitio de la UE.
+
+```yml
+- hosts: servers
+ roles:
+ - { role: datadog.datadog, become: yes }
+ vars:
+ datadog_site: "datadoghq.eu"
+ datadog_api_key: ""
+```
+
+### recopilación de logs
+
+En Windows, elimina la opción `become: yes` para que el rol no falle. A continuación, se muestran dos métodos para hacer que los cuadernos de estrategias de ejemplo funcionen con hosts que usan Windows:
+
+#### Archivo de inventario
+
+Se recomienda usar el archivo de inventario. Configura la opción `ansible_become` como `no` en el archivo de inventario de cada host que use Windows:
+
+```ini
+[servers]
+linux1 ansible_host=127.0.0.1
+linux2 ansible_host=127.0.0.2
+windows1 ansible_host=127.0.0.3 ansible_become=no
+windows2 ansible_host=127.0.0.4 ansible_become=no
+```
+
+Para evitar repetir la misma configuración en todos los hosts que usen Windows, agrúpalos y configura la variable en nivel de grupo:
+
+```ini
+[linux]
+linux1 ansible_host=127.0.0.1
+linux2 ansible_host=127.0.0.2
+
+[windows]
+windows1 ansible_host=127.0.0.3
+windows2 ansible_host=127.0.0.4
+
+[windows:vars]
+ansible_become=no
+```
+
+#### Archivo del cuaderno de estrategias
+
+Alternativamente, si tu cuaderno de estrategias **solo funciona en hosts con Windows**, usa lo siguiente en el archivo del cuaderno de estrategias:
+
+```yml
+- hosts: servers
+ roles:
+ - { role: datadog.datadog }
+ vars:
+ ...
+```
+
+**Nota**: Esta configuración no funciona en los hosts con Linux. Úsala solo si el cuaderno de estrategias es específico para hosts con Windows. De lo contrario, decántate por el [método del archivo de inventario](#inventory-file).
+
+### Desinstalación
+
+En Windows, es posible desinstalar el Agent usando el siguiente código en tu rol de Ansible:
+
+```yml
+- name: Check If Datadog Agent is installed
+ win_shell: |
+ (@(Get-ChildItem -Path "HKLM:SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" -Recurse) | Where {$_.GetValue("DisplayName") -like "Datadog Agent" }).PSChildName
+ register: agent_installed_result
+- name: Set Datadog Agent installed fact
+ set_fact:
+ agent_installed: "{{ agent_installed_result.stdout | trim }}"
+- name: Uninstall the Datadog Agent
+ win_package:
+ product_id: "{{ agent_installed }}"
+ state: absent
+ when: agent_installed != ""
+```
+
+## Python
+
+### Debian Stretch
+
+**Nota:** Esta información es aplicable a las versiones del rol anteriores a la v4.9.0. El rol dejó de usar el módulo `apt_key`en la v4.9.0.
+
+En Debian Stretch, el módulo `apt_key` que usa el rol requiere una dependencia de sistema adicional para funcionar correctamente. Puesto que el módulo no proporciona la dependencia (`dirmngr`), añade la siguiente configuración a tus cuadernos de estrategia para usar este rol:
+
+```yml
+---
+- hosts: all
+ pre_tasks:
+ - name: Debian Stretch requires the dirmngr package to use apt_key
+ become: yes
+ apt:
+ name: dirmngr
+ state: present
+ roles:
+ - { role: datadog.datadog, become: yes }
+ vars:
+ datadog_api_key: ""
+```
+
+### CentOS 6/7 con el intérprete de Python 3 y Ansible 2.10.x o una versión anterior
+
+El módulo `yum` de Python, que se usa en este rol para instalar el Agent en hosts basados en CentOS, solo está disponible en Python 2 si se usa Ansible 2.10.x o una versión anterior. En estos casos, habría que utilizar el gestor de paquetes `dnf`.
+
+Sin embargo, `dnf` y el módulo `dnf` de Python no se instalan por defecto en hosts basados en CentOS si la versión es anterior a CentOS 8. En ese caso, no es posible instalar el Agent cuando se usa un intérprete de Python 3.
+
+El rol falla prematuramente cuando se detecta esta situación como indicativo de que se necesita Ansible 2.11 (o una versión posterior) o un intérprete de Python 2 para instalar el Agent en una versión de CentOS/RHEL anterior a la 8.
+
+Para evitar esta detección de fallo prematuro (por ejemplo, si `dnf` y el paquete `python3-dnf` están disponibles en tu host), establece la variable `datadog_ignore_old_centos_python3_error` como `true`.
+
+### recopilación de logs
+
+Debido a un error crítico en las versiones del Agent `6.14.0` y `6.14.1` para Windows, la instalación de estas versiones está bloqueada (a partir de la versión `3.3.0` de este rol).
+
+**NOTA:** Ansible falla en Windows si `datadog_agent_version` es `6.14.0` o `6.14.1`. Usa `6.14.2` o una versión posterior.
+
+Si vas a pasar de la versión **6.14.0 a la 6.14.1 en Windows**, sigue estos pasos:
+
+1. Actualiza el rol de Ansible actual `datadog.datadog` a la versión más reciente (`>=3.3.0`).
+2. Define `datadog_agent_version` como `6.14.2` o una versión posterior (por defecto, la más reciente).
+
+Para más detalles, consulta [Critical Bug in Uninstaller for Datadog Agent 6.14.0 and 6.14.1 on Windows][11] (Error crítico en el desinstalador del Datadog Agent 6.14.0 y 6.14.1 para Windows).
+
+### Error en Ubuntu 20.04 debido a service_facts
+
+Ejecutar el módulo `service_facts` en Ubuntu 20.04 produce el siguiente error:
+
+```
+localhost | FAILED! => {
+ "changed": false,
+ "msg": "Malformed output discovered from systemd list-unit-files: accounts-daemon.service enabled enabled "
+}
+```
+
+Para solucionarlo, [actualiza Ansible a `v2.9.8` o a una versión posterior][16].
+
+### Falta la clave de API
+
+A partir del rol `4.21` la clave de API es obligatoria para que el rol proceda.
+
+Si necesitas instalar el Agent a través de Ansible, pero no quieres especificar una clave de API (por ejemplo, si lo estás incorporando a un contenedor/una imagen de MV), puedes:
+* Especificar una clave de API ficticia y sustituirla después
+* Desactivar managed_config (`datadog_manage_config: false`)
+
+[1]: https://galaxy.ansible.com/Datadog/datadog
+[2]: https://github.com/DataDog/ansible-datadog
+[3]: https://docs.datadoghq.com/es/agent/autodiscovery
+[4]: https://docs.datadoghq.com/es/agent/guide/integration-management/
+[5]: https://github.com/DataDog/integrations-core
+[6]: https://docs.datadoghq.com/es/infrastructure/process/
+[7]: https://docs.datadoghq.com/es/network_performance_monitoring/
+[8]: https://docs.datadoghq.com/es/security_platform/cloud_workload_security/getting_started/
+[9]: https://docs.datadoghq.com/es/network_performance_monitoring/installation/?tab=agent#setup
+[10]: https://docs.datadoghq.com/es/agent/guide/agent-commands/#restart-the-agent
+[11]: https://app.datadoghq.com/help/agent_fix
+[12]: https://docs.ansible.com/ansible/latest/reference_appendices/playbooks_keywords.html#playbook-keywords
+[13]: https://github.com/DataDog/ansible-datadog/blob/main/tasks/agent-linux.yml
+[14]: https://github.com/DataDog/ansible-datadog/blob/main/tasks/agent-win.yml
+[15]: https://www.datadoghq.com/blog/datadog-marketplace/
+[16]: https://github.com/ansible/ansible/blob/stable-2.9/changelogs/CHANGELOG-v2.9.rst#id61
+[17]: https://docs.datadoghq.com/es/tracing/universal_service_monitoring/?tab=configurationfiles#enabling-universal-service-monitoring
+[18]: https://docs.datadoghq.com/es/security/cspm/setup/?tab=docker
+[19]: https://github.com/DataDog/integrations-core
+[20]: https://github.com/DataDog/integrations-extras
+[23]: https://docs.datadoghq.com/es/tracing/trace_collection/library_injection_local/?tab=agentandappinseparatecontainers#configure-docker-injection
+[24]: https://docs.datadog.com/tracing/trace_collection/library_injection_local
\ No newline at end of file
diff --git a/content/es/agent/guide/azure-private-link.md b/content/es/agent/guide/azure-private-link.md
new file mode 100644
index 0000000000000..a09a681092b7f
--- /dev/null
+++ b/content/es/agent/guide/azure-private-link.md
@@ -0,0 +1,80 @@
+---
+kind: guía
+title: Conéctate a Datadog a través de Azure Private Link
+---
+
+{{% site-region region="us,us5,eu,gov,ap1" %}}
+
Esta función no es compatible con el sitio de Datadog seleccionado.
+{{% /site-region %}}
+
+{{% site-region region="us3" %}}
+[Azure Private Link][1] te permite enviar telemetría a Datadog sin utilizar la Internet pública.
+
+Datadog expone parte de sus servicios de consumo de datos como [servicios de Azure Private Link][2].
+
+Puedes configurar Azure Private Link para exponer una dirección IP privada por cada servicio de consumo de Datadog; esta dirección IP enruta el tráfico al backend de Datadog. A continuación, puedes configurar una [zona DNS privada][3] de Azure para anular los nombres DNS correspondientes a los productos de cada endpoint consumido.
+
+## Python
+
+### Conectar un endpoint
+
+1. En el portal de Azure, ve a **Private Link**.
+2. En el menú de navegación de la izquierda, selecciona **Private endpoints** (Endpoints privados).
+3. Selecciona **Create** (Crear).
+4. En la página **Create a private endpoint** > **Basics** (Crear un endpoint privado > Aspectos básicos), configura:
+ - En **Project details** (Detalles del proyecto), selecciona la **Subscription** (Suscripción) y el **Resource group** (Grupo de recursos) desde los que los recursos de producción deben acceder a Private Link.
+ - En **Instance details** (Detalles de la instancia), ingresa un **Name** (Nombre) (por ejemplo, `datadog-api-private-link`) y selecciona tu **Region** (Región).
+
+ Selecciona **Next: Resource** (Siguiente: Recurso) para continuar.
+5. En la página **Create a private endpoint** > **Resource** (Crear un endpoint privado > Recurso), configura lo siguiente:
+ - Para **Connection method** (Método de conexión), selecciona **Connect to an Azure resource by resource ID or alias** (Conectarse a un recurso Azure por ID de recurso o alias).
+ - En **Resource ID or alias** (Recurso ID o alias), introduce el nombre del servicio de Private Link que corresponda al servicio de consumo de Datadog que quieres utilizar. Puedes encontrar este nombre de servicio en la [tabla de servicios publicados](#published-servicios).
+ - Opcionalmente, en **Request message** (Mensaje de solicitud), puedes introducir tu dirección de correo electrónico (asociada a una cuenta de Datadog). Esto ayuda a Datadog a identificar tu solicitud y a ponerse en contacto contigo, si es necesario.
+
+ Selecciona **Next: Virtual Network** (Siguiente: Virtual red) para continuar.
+6. En la página **Create a private endpoint** > **Virtual Network** (Crear un endpoint privado > Red virtual), configura lo siguiente:
+ - En **Networking** (Redes), selecciona la **Virtual network** (Red virtual) y la **Subnet** (Subred) donde debe estar alojado el endpoint. Normalmente, se encuentra en la misma red que los recursos informáticos que necesitan acceder al endpoint privado.
+ - En **Private DNS integration** (Integración de DNS privado), selecciona **No**.
+
+ Selecciona **Next: Tags** (Siguiente: Etiquetas (tags) para continuar.
+7. En la página **Create a private endpoint** > **Tags** (Crear un endpoint privado > Etiquetas (tags), puedes configurar opcionalmente etiquetas. Selecciona **Next** (Siguiente).
+8. En la página **Review + create** (Revisar + crear), revisa tus configuraciones. A continuación, selecciona **Create** (Crear).
+9. Una vez creado tu endpoint privado, búscalo en lista. Toma nota de la **IP privada** de este endpoint, ya que se utilizará en la siguiente sección.
+
+### Crear una zona DNS privada
+1. En el portal Azure, ve a **Private DNS zones** (Zonas DNS privadas).
+2. Selecciona **Create** (Crear).
+3. En la página **Create Private DNS zone** > **Basics** (Crear zona DNS privada > Aspectos básicos), configura:
+ - En **Project details** (Detalles del proyecto), selecciona la **Subscription** (Suscripción) y el **Resource group** (Grupo de recursos) desde los que los recursos de producción deben acceder al endpoint privado.
+ - En **Instance details** (Detalles de la instancia), en **Name** (Nombre), introduce el nombre de DNS privado que corresponde al servicio de consumo de Datadog que quieres utilizar. Puedes encontrar este nombre servicio en la [tabla de servicios publicados](#published-servicios).
+
+ Selecciona **Review + create** (Revisar + crear).
+4. Revisa tus configuraciones. A continuación, selecciona **Create** (Crear).
+5. Una vez creada la zona DNS privada, selecciónala en lista.
+6. En el panel que se abre, selecciona **+ Record set** (+ Conjunto de registros).
+7. En el panel **Add record set** (Añadir conjunto de registros), configura lo siguiente:
+ - En **Name** (Nombre), introduce `*`.
+ - En **Type** (Tipo), selecciona **A - Address record** (A - Registro de direcciones).
+ - En **IP address** (Dirección IP), introduce la dirección IP que anotaste al final de la sección anterior.
+
+ Selecciona **OK** (Aceptar) para finalizar.
+
+## Servicios publicados
+
+| Servicio de consumo de Datadog | Nombre de servicio de Private LInk | Nombre de DNS privado |
+| --- | --- | --- |
+| Logs (Agent) | `logs-pl-1.9941bd04-f840-4e6d-9449-368592d2f7da.westus2.azure.privatelinkservice` | `agent-http-intake.logs.us3.datadoghq.com` |
+| Logs (Consumo HTTP del usuario) | `logs-pl-1.9941bd04-f840-4e6d-9449-368592d2f7da.westus2.azure.privatelinkservice` | `http-intake.logs.us3.datadoghq.com` |
+| Python | `api-pl-1.0962d6fc-b0c4-40f5-9f38-4e9b59ea1ba5.westus2.azure.privatelinkservice` | `api.us3.datadoghq.com` |
+| Facturación | `metrics-agent-pl-1.77764c37-633a-4c24-ac9b-0069ce5cd344.westus2.azure.privatelinkservice` | `metrics.agent.us3.datadoghq.com` |
+| Ver una lista con todos los equipos de incidencias | `orchestrator-pl-1.8ca24d19-b403-4c46-8400-14fde6b50565.westus2.azure.privatelinkservice` | `orchestrator.us3.datadoghq.com` |
+| Proceso | `process-pl-1.972de3e9-3b00-4215-8200-e1bfed7f05bd.westus2.azure.privatelinkservice` | `process.us3.datadoghq.com` |
+| Elaboración de perfiles | `profile-pl-1.3302682b-5bc9-4c76-a80a-0f2659e1ffe7.westus2.azure.privatelinkservice` | `intake.profile.us3.datadoghq.com` |
+| Trazas (traces) | `trace-edge-pl-1.d668729c-d53a-419c-b208-9d09a21b0d54.westus2.azure.privatelinkservice` | `trace.agent.us3.datadoghq.com` |
+| Solucionar problemas | `fleet-pl-1.37765ebe-d056-432f-8d43-fa91393eaa07.westus2.azure.privatelinkservice` | `config.us3.datadoghq.com` |
+| Conectar logs y trazas | `dbm-metrics-pl-1.e391d059-0e8f-4bd3-9f21-708e97a708a9.westus2.azure.privatelinkservice` | `dbm-metrics-intake.us3.datadoghq.com` |
+
+[1]: https://azure.microsoft.com/en-us/products/private-link
+[2]: https://learn.microsoft.com/en-us/azure/private-link/private-link-service-overview
+[3]: https://learn.microsoft.com/en-us/azure/dns/private-dns-privatednszone
+{{% /site-region %}}
\ No newline at end of file
diff --git a/content/es/agent/guide/can-i-set-up-the-dd-agent-mysql-check-on-my-google-cloudsql.md b/content/es/agent/guide/can-i-set-up-the-dd-agent-mysql-check-on-my-google-cloudsql.md
new file mode 100644
index 0000000000000..90033ac27e434
--- /dev/null
+++ b/content/es/agent/guide/can-i-set-up-the-dd-agent-mysql-check-on-my-google-cloudsql.md
@@ -0,0 +1,19 @@
+---
+aliases:
+- /es/agent/faq/can-i-set-up-the-dd-agent-mysql-check-on-my-google-cloudsql/
+- /es/integrations/faq/can-i-set-up-the-dd-agent-mysql-check-on-my-google-cloudsql/
+kind: guía
+title: ¿Puedo configurar el check mysql dd-Agent en mi CloudSQL de Google?
+---
+
+Al igual que con la [integración de Amazon RDS][1] "nativa" con MySQL, puedes configurar una integración de MySQL con un Agent de Datadog en una instancia de MySQL que se ejecuta en CloudSQL de Google. Con esta configuración, puedes complementar las métricas que de otro modo obtendrías de la [integración de CloudSQL de Google][2] de Datadog con las métricas disponibles de la [integración de MySQL][3] del Agent de Datadog.
+
+Para configurar este integración "extra" en tu instancia CloudSQL de Google, puedes configurar la integración de MySQL en un Agent de Datadog y [configurarla para conectarse remotamente][4] a tu instancia CloudSQL de Google en lugar de utilizar el host local por defecto. Por lo demás, los pasos de configuración son los mismos que para cualquier otra instancia MySQL alojada localmente.
+
+Con una advertencia: CloudSQL de Google [no es compatible con performance_schemas][5], por lo que no puedes `GRANT SELECT ON performance_schema.*` al usuario del Agent de Datadog. Como resultado, dos de las métricas extra/opcionales de los checks de MySQL no están disponibles para las instancias CloudSQL de Google. Por lo demás, la integración debería funcionar igual que con cualquier instancia MySQL alojada localmente.
+
+[1]: /es/integrations/amazon_rds/
+[2]: /es/integrations/google_cloudsql/
+[3]: /es/integrations/mysql/
+[4]: https://github.com/DataDog/integrations-core/blob/5.12.x/mysql/conf.yaml.example#L4-L7
+[5]: https://cloud.google.com/sql/docs/features#differences
\ No newline at end of file
diff --git a/content/es/agent/guide/datadog-agent-manager-windows.md b/content/es/agent/guide/datadog-agent-manager-windows.md
index ee5a901f9c15b..deb891dc07cfa 100644
--- a/content/es/agent/guide/datadog-agent-manager-windows.md
+++ b/content/es/agent/guide/datadog-agent-manager-windows.md
@@ -2,7 +2,7 @@
further_reading:
- link: /agent/basic_agent_usage/windows/
tag: Documentación
- text: Uso básico del Agent para el Agent de Windows
+ text: Uso básico del Agent para el Windows Agent
kind: guía
title: Datadog Agent Manager para Windows
---
diff --git a/content/es/agent/guide/dogstream.md b/content/es/agent/guide/dogstream.md
index c07c54d8d9cd6..173413a777bca 100644
--- a/content/es/agent/guide/dogstream.md
+++ b/content/es/agent/guide/dogstream.md
@@ -64,7 +64,7 @@ Si el parseador de logs personalizado no funciona, lo primero que hay que compro
* Si todo va bien, deberías ver esto:`dogstream: parsing {filename} with {function name} (requested {config option text})`.
-Para comprobar si los dogstreams funcionan correctamente, añade una línea (sin editar ninguna de las existentes) en cualquier archivo de logs en los que hayas configurado el Agent para que los rastree. El Agent solo supervisa el final de cada archivo de logs, así que no detecta los cambios que realices en otras secciones del archivo.
+Para comprobar que los dogstreams funcionan, añade una línea, y no edites una ya existente, a cualquier archivo de log que hayas configurado para que el Agent vigile. El Agent solo sigue el final de cada archivo de log, por lo que no se da cuenta de los cambios que haces en otras partes del archivo.
### Cómo redactar funciones de parseo
@@ -238,20 +238,20 @@ dogstreams: /Users/Documents/Parser/test.log:/Users/Documents/Parser/myparser.py
## Solucionar problemas
-Los errores ocurren, por lo que es importante poder acceder al rastreo de tus parseadores de logs. Sin embargo, solo podrás hacerlo si el Agent se ejecuta con los [logs del Agent][6] configurados en el nivel "DEBUG" (depuración). Este nivel se puede configurar en `datadog.conf` de la siguiente manera: quita la marca de comentario y edita esta [línea][7]; a continuación, [reinicia el Agent][8]. Tras configurar el nivel, podrás encontrar el rastreo de los errores de tu parseador de logs personalizado en el archivo `collector.log`, que generalmente incluirá la cadena checks.collector(datadog.py:278) | Error while parsing line. Consulta el [código del Agent][9], dado que es probable que el error aparezca allí.
+Los errores ocurren, por lo que es importante poder acceder al rastreo de tus parseadores de logs. Sin embargo, solo podrás hacerlo si el Agent se ejecuta con los [logs del Agent][6] definidos en el nivel "DEBUG" (depuración). Este nivel se puede establecer en `datadog.conf` de la siguiente manera: quita la marca de comentario y edita esta [línea][7]; a continuación, [reinicia el Agent][8]. Tras establecerlo, podrás encontrar el rastreo de los errores de tu parseador de logs personalizado en el archivo `collector.log`, que generalmente incluirá la cadena checks.collector(datadog.py:278) | Error while parsing line. Consulta el [código del Agent][9], dado que es probable que el error aparezca allí.
**Nota**: Cada vez que realices un cambio en tu parseador de logs personalizado, [reinicia el Agent][8] para que se aplique ese cambio.
-Si sospechas de que se está produciendo algún error fuera del contexto de la función de tu parseador de logs personalizado, no dudes en [contactar con el equipo de asistencia][10]. Sin embargo, antes de nada, establece el nivel del log del Agent en "DEBUG", ejecuta el Agent durante unos minutos para asegurarte de que se están añadiendo nuevos logs a tus archivos y, luego, [ejecuta el comando flare][11] desde tu Agent. De este modo, el equipo de asistencia dispondrá de la información necesaria para solucionar el problema como es debido.
+Si sospechas que se está produciendo algún error fuera del contexto de la función de tu parseador de logs personalizado, no dudes en [contactar con el equipo de asistencia][10]. Sin embargo, antes de nada, establece el nivel del log del Agent en "DEBUG", ejecuta el Agent durante unos minutos para asegurarte de que se están añadiendo nuevos logs a tus archivos y, luego, [ejecuta el comando flare][11] desde tu Agent. De este modo, el equipo de asistencia dispondrá de la información necesaria para solucionar el problema como es debido.
[1]: https://app.datadoghq.com/infrastructure#tags
[2]: /es/api/v1/tags/
[3]: https://github.com/DataDog/dd-agent/blob/master/dogstream/cassandra.py
[4]: /es/events/
[5]: https://github.com/DataDog/dd-agent/blob/5.13.x/checks/datadog.py#L210
-[6]: /es/agent/guide/agent-log-files/
+[6]: /es/agent/configuration/agent-log-files/
[7]: https://github.com/DataDog/dd-agent/blob/5.7.x/datadog.conf.example#L211
-[8]: /es/agent/guide/agent-commands/
+[8]: /es/agent/configuration/agent-commands/
[9]: https://github.com/DataDog/dd-agent/blob/5.7.x/checks/datadog.py#L278
[10]: /es/help/
[11]: /es/agent/troubleshooting/send_a_flare/
\ No newline at end of file
diff --git a/content/es/agent/guide/environment-variables.md b/content/es/agent/guide/environment-variables.md
index befab885956a3..d168453a3f053 100644
--- a/content/es/agent/guide/environment-variables.md
+++ b/content/es/agent/guide/environment-variables.md
@@ -9,7 +9,7 @@ further_reading:
- link: /logs/log_collection/#container-log-collection
tag: Documentación
text: Recopilación de logs de contenedores
-- link: /agent/proxy/#environment-variables
+- link: /agent/configuration/proxy/#environment-variables
tag: Documentación
text: Variables de entorno del proxy
kind: guía
@@ -85,20 +85,37 @@ En general, puedes utilizar las siguientes reglas:
```yaml
process_config:
- enabled: true
+ process_collection:
+ enabled: true
process_dd_url: https://process.datadoghq.com
- # DD_PROCESS_AGENT_ENABLED=true
+ # DD_PROCESS_AGENT_PROCESS_COLLECTION_ENABLED=true
# DD_PROCESS_AGENT_URL=https://process.datadoghq.com
```
+## Uso de variables de entorno en unidades systemd
+
+En los sistemas operativos que utilizan systemd para gestionar servicios, las variables de entorno globales (por ejemplo, `/etc/environment`) o basadas en sesiones (por ejemplo, `export VAR=value`) no suelen estar disponibles para servicios, a menos que se configuren para ello. Consulta la [página de ejecución manual de systemd][8] para obtener más información.
+
+A partir de Datadog Agent v7.45, la (unidad`datadog-agent.service` ) de servicio de Datadog Agent puede cargar opcionalmente asignaciones de variables de entorno desde un archivo (`/environment`).
+
+1. Crea `/etc/datadog-agent/environment`, si no existe.
+2. Define asignaciones de variables de entorno separadas por nuevas líneas. Por ejemplo:
+ ```
+ GODEBUG=x509ignoreCN=0,x509sha1=1
+ DD_HOSTNAME=myhost.local
+ DD_TAGS=env:dev service:foo
+ ```
+3. Reinicia el servicio para que los cambios surtan efecto.
+
## Leer más
{{< partial name="whats-next/whats-next.html" >}}
-[1]: /es/agent/guide/agent-configuration-files/#agent-main-configuration-file
+[1]: /es/agent/configuration/agent-configuration-files/#agent-main-configuration-file
[2]: /es/getting_started/tagging/unified_service_tagging
-[3]: /es/agent/proxy/#environment-variables
-[4]: https://github.com/DataDog/datadog-agent/blob/main/pkg/config/config.go
+[3]: /es/agent/configuration/proxy/#environment-variables
+[4]: https://github.com/DataDog/datadog-agent/blob/main/pkg/config/setup/config.go
[5]: https://docs.datadoghq.com/es/agent/docker/apm/#docker-apm-agent-environment-variables
-[6]: https://github.com/DataDog/datadog-agent/blob/main/pkg/config/apm.go
-[7]: https://github.com/DataDog/datadog-agent/blob/main/pkg/config/process.go
\ No newline at end of file
+[6]: https://github.com/DataDog/datadog-agent/blob/main/pkg/config/setup/apm.go
+[7]: https://github.com/DataDog/datadog-agent/blob/main/pkg/config/setup/process.go
+[8]: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Environment
\ No newline at end of file
diff --git a/content/es/agent/guide/heroku-ruby.md b/content/es/agent/guide/heroku-ruby.md
index 4a8accaa0f9df..e023953dbd29b 100644
--- a/content/es/agent/guide/heroku-ruby.md
+++ b/content/es/agent/guide/heroku-ruby.md
@@ -616,10 +616,10 @@ Dirígete a la [sección de trazas de APM][19] para ver tus trazas:
{{< img src="agent/guide/heroku_ruby/traces.png" alt="Trazas de aplicaciones de Ruby en Datadog" >}}
-Accede a la [lista de servicios][20] para ver todos los servicios de tu aplicación y su vista:
+Navega al [catálogo de servicios][20] para ver todos tus servicios de aplicación y una vista de tu servicio de aplicación:
-{{< img src="agent/guide/heroku_ruby/ruby_service.png" alt="Vista de la lista de servicios en Datadog" >}}
-{{< img src="agent/guide/heroku_ruby/service_page.png" alt="Vista de los servicios de la aplicación de Ruby en Datadog" >}}
+{{< img src="agent/guide/heroku_ruby/ruby_service.png" alt="Service Catalog in Datadog" >}}
+{{< img src="agent/guide/heroku_ruby/service_page.png" alt="Ruby application service details page in Datadog" >}}
## Logs
@@ -856,7 +856,7 @@ Agent (v7.27.0)
[17]: https://elements.heroku.com/addons/memcachedcloud
[18]: https://docs.datadoghq.com/es/getting_started/tagging/unified_service_tagging/
[19]: https://app.datadoghq.com/apm/traces
-[20]: https://app.datadoghq.com/apm/services
+[20]: https://app.datadoghq.com/services
[21]: https://devcenter.heroku.com/articles/log-runtime-metrics/
[22]: https://app.datadoghq.com/logs/livetail
[23]: https://devcenter.heroku.com/articles/log-runtime-metrics#cpu-load-averages
diff --git a/content/es/agent/guide/how-do-i-uninstall-the-agent.md b/content/es/agent/guide/how-do-i-uninstall-the-agent.md
index eeaa8f41bcf9e..3a2f0cd46ba2c 100644
--- a/content/es/agent/guide/how-do-i-uninstall-the-agent.md
+++ b/content/es/agent/guide/how-do-i-uninstall-the-agent.md
@@ -1,256 +1,21 @@
---
+algolia:
+ tags:
+ - desinstalar
aliases:
- /es/agent/faq/how-do-i-uninstall-the-agent/
further_reading:
-- link: /agent/
+- link: /agent/basic_agent_usage/
tag: Documentación
- text: Más información sobre el Datadog Agent
+ text: Uso básico del Agent
kind: guía
title: Desinstalar el Agent
---
-Elige tu plataforma para ver las instrucciones específicas para desinstalar el Agent:
+Para obtener información sobre la desinstalación del Agent de tu sistema, consulta la página [uso básico del Agent][1] correspondiente a tu sistema operativo, plataforma o herramienta de configuración.
-## Debian y Ubuntu
+## Leer más
-{{< tabs >}}
-{{% tab "Agent v6 y v7" %}}
-```shell
-sudo apt-get remove datadog-agent -y
-```
+{{< partial name="whats-next/whats-next.html" >}}
-> Este comando elimina el Agent, pero no elimina:
-
-* el archivo de configuración `datadog.yaml`,
-* los archivos creados por el usuario en la carpeta de configuración`/etc/datadog-agent`,
-* los archivos creados por el usuario en la carpeta `/opt/datadog-agent`,
-* el usuario `dd-agent`.
-
-> Si también deseas eliminar estos elementos, utiliza este comando en su lugar:
-
-```shell
-sudo apt-get remove --purge datadog-agent -y
-```
-{{% /tab %}}
-
-{{% tab "Agent v5" %}}
-```shell
-sudo apt-get remove datadog-agent -y
-```
-
-Este comando elimina el Agent, pero no elimina:
-* el archivo de configuración `datadog.yaml`,
-* los archivos creados por el usuario en la carpeta de configuración `/etc/dd-agent`,
-* los archivos creados por el usuario en la carpeta `/opt/datadog-agent`,
-* el usuario `dd-agent`.
-> Si también deseas eliminar estos elementos, utiliza este comando en su lugar:
-
-```shell
-sudo apt-get --purge remove datadog-agent -y
-```
-{{% /tab %}}
-{{< /tabs >}}
-
-## CentOS, RHEL, Fedora y Amazon Linux
-{{< tabs >}}
-{{% tab "Agent v6 y v7" %}}
-
-
-```shell
-sudo yum remove datadog-agent
-```
-
-> Este comando elimina el Agent, pero no elimina:
-* el archivo de configuración `datadog.yaml`,
-* los archivos creados por el usuario en la carpeta de configuración `/etc/datadog-agent`,
-* los archivos creados por el usuario en la carpeta `/opt/datadog-agent`,
-* el usuario `dd-agent`.
-
-> Si también deseas eliminar estos elementos y tus archivos de logs de Datadog, ejecuta este comando después de eliminar el Agent:
-
-```shell
-sudo userdel dd-agent \
-&& sudo rm -rf /opt/datadog-agent/ \
-&& sudo rm -rf /etc/datadog-agent/ \
-&& sudo rm -rf /var/log/datadog/
-```
-{{% /tab %}}
-
-{{% tab "Agent v5" %}}
-```shell
-sudo yum remove datadog-agent
-```
-
-> Este comando elimina el Agent, pero no elimina:
-
-* el archivo de configuración `datadog.yaml`,
-* los archivos creados por el usuario en la carpeta de configuración `/etc/dd-agent`,
-* los archivos creados por el usuario en la carpeta `/opt/datadog-agent`,
-* el usuario `dd-agent`.
-
-> Si también deseas eliminar estos elementos y tus archivos de logs de Datadog, ejecuta este comando después de eliminar el Agent:
-
-```shell
-sudo userdel dd-agent \
-&& sudo rm -rf /opt/datadog-agent/ \
-&& sudo rm -rf /etc/dd-agent/ \
-&& sudo rm -rf /var/log/datadog/
-```
-{{% /tab %}}
-{{< /tabs >}}
-
-## openSUSE y SLES
-{{< tabs >}}
-{{% tab "Agent v6 y v7" %}}
-```shell
-sudo zypper remove datadog-agent
-```
-
-> Este comando elimina el Agent, pero no elimina:
-* el archivo de configuración `datadog.yaml`,
-* los archivos creados por el usuario en la carpeta de configuración `/etc/datadog-agent`,
-* los archivos creados por el usuario en la carpeta `/opt/datadog-agent`,
-* el usuario `dd-agent`.
-
-> Si también deseas eliminar estos elementos y tus archivos de logs de Datadog, ejecuta este comando después de eliminar el Agent:
-
-```shell
-sudo userdel dd-agent \
-&& sudo rm -rf /opt/datadog-agent/ \
-&& sudo rm -rf /etc/datadog-agent/ \
-&& sudo rm -rf /var/log/datadog/
-```
-{{% /tab %}}
-
-{{% tab "Agent v5" %}}
-
-```shell
-sudo zypper remove datadog-agent
-```
-
-Este comando elimina el Agent, pero no elimina:
-* el archivo de configuración `datadog.yaml`,
-* los archivos creados por el usuario en la carpeta de configuración `/etc/dd-agent`,
-* los archivos creados por el usuario en la carpeta `/opt/datadog-agent`,
-* el usuario `dd-agent`.
-
-Si también deseas eliminar estos elementos y tus archivos de logs de Datadog, ejecuta este comando después de eliminar el Agent:
-
-```shell
-sudo userdel dd-agent \
-&& sudo rm -rf /opt/datadog-agent/ \
-&& sudo rm -rf /etc/dd-agent/ \
-&& sudo rm -rf /var/log/datadog/
-```
-{{% /tab %}}
-{{< /tabs >}}
-## macOS
-{{< tabs >}}
-{{% tab "Agent v6 y v7" %}}
-**Instalación por un solo usuario**
-
-Para eliminar el Agent y todos sus archivos de configuración:
-1. Detén y cierra el Datadog Agent con el icono en forma de hueso en la bandeja.
-2. Arrastra la aplicación de Datadog desde el directorio de aplicaciones a la papelera.
-3. Ejecuta los siguientes comandos:
- ```shell
- sudo rm -rf /opt/datadog-agent
- sudo rm -rf /usr/local/bin/datadog-agent
- sudo rm -rf ~/.datadog-agent/** #to remove broken symlinks
- launchctl remove com.datadoghq.agent
- sudo rm -rf /var/log/datadog
- ```
-4. Reinicia el equipo para que se apliquen los cambios.
-
-**Instalación de LaunchDaemon en todo el sistema**
-
-Para eliminar el Agent y todos sus archivos de configuración:
-1. Arrastra la aplicación de Datadog desde el directorio de aplicaciones a la papelera.
-2. Para eliminar los archivos que queden, ejecuta lo siguiente:
- ```shell
- sudo rm -rf /opt/datadog-agent
- sudo rm -rf /usr/local/bin/datadog-agent
- sudo rm -rf ~/.datadog-agent/** #to remove broken symlinks
- sudo launchctl disable system/com.datadoghq.agent && sudo launchctl bootout system/com.datadoghq.agent
- sudo rm /Library/LaunchDaemons/com.datadoghq.agent.plist
- sudo rm -rf /var/log/datadog
- ```
-3. Reinicia el equipo para que se apliquen los cambios.
-{{% /tab %}}
-
-{{% tab "Agent v5" %}}
-1. Detén y cierra el Datadog Agent con el icono en forma de hueso en la bandeja.
-2. Arrastra la aplicación de Datadog desde el directorio de aplicaciones a la papelera.
-3. Ejecuta lo siguiente:
-
-```shell
-sudo rm -rf /opt/datadog-agent
-sudo rm -rf /usr/local/bin/datadog-agent
-sudo rm -rf ~/.datadog-agent/** #to remove broken symlinks
-```
-
-Si has ejecutado los comandos de instalación opcionales para que el Agent se ejecute en el arranque, ejecuta lo siguiente para finalizar la desinstalación:
-
-```shell
-sudo launchctl unload -w /Library/LaunchDaemons/com.datadoghq.agent.plist
-sudo rm /Library/LaunchDaemons/com.datadoghq.agent.plist
-```
-
-> Este método elimina el Agent, así como todos sus archivos de configuración.
-{{% /tab %}}
-{{< /tabs >}}
-
-## Windows
-
-{{< tabs >}}
-{{% tab "Agent v6 y v7" %}}
-
-Existen dos métodos diferentes para desinstalar el Agent en Windows. Ambos eliminan el Agent, pero no eliminan la carpeta de configuración `C:\ProgramData\Datadog` en el host.
-
-### Añadir o eliminar programas
-
-1. Pulsa **CTRL** y **Esc** o utiliza la tecla de Windows para ejecutar Windows Search.
-1. Busca `add` y haz clic en ****Add or remove programs** (Añadir o eliminar programas).
-1. Busca `Datadog Agent` y haz clic en **Uninstall** (Desinstalar).
-
-### PowerShell
-
-**Nota:** Habilita WinRM para usar los comandos que se muestran a continuación.
-
-Utiliza uno de los siguientes comandos de PowerShell para desinstalar el Agent sin tener que reiniciar:
-```powershell
-start-process msiexec -Wait -ArgumentList ('/log', 'C:\uninst.log', '/q', '/x', (Get-CimInstance -ClassName Win32_Product -Filter "Name='Datadog Agent'" -ComputerName .).IdentifyingNumber, 'REBOOT=ReallySuppress')
-```
-
-Para ello, utiliza `/norestart`:
-
-```powershell
-start-process msiexec -Wait -ArgumentList ('/log', 'C:\uninst.log', '/norestart', '/q', '/x', (Get-CimInstance -ClassName Win32_Product -Filter "Name='Datadog Agent'" -ComputerName .).IdentifyingNumber)
-```
-
-{{% /tab %}}
-
-{{% tab "Agent v5" %}}
-
-Existen dos métodos diferentes para desinstalar el Agent en Windows. Ambos eliminan el Agent, pero no eliminan la carpeta de configuración `C:\ProgramData\Datadog` en el host.
-
-> **Nota**: En versiones anteriores a la 5.12.0 del Agent, es importante desinstalarlo a través de la **cuenta original** con la que se instaló, de lo contrario puede que no se elimine correctamente.
-
-### Añadir o eliminar programas
-
-1. Pulsa **CTRL** y **Esc** o utiliza la tecla de Windows para ejecutar Windows Search.
-1. Busca `add` y haz clic en ****Add or remove programs** (Añadir o eliminar programas).
-1. Busca `Datadog Agent` y haz clic en **Uninstall** (Desinstalar).
-
-### PowerShell
-
-**Nota:** Habilita WinRM para usar los comandos que se muestran abajo.
-
-Utiliza el siguiente comando de PowerShell para desinstalar el Agent sin tener que reiniciar:
-
-```powershell
-start-process msiexec -Wait -ArgumentList ('/log', 'C:\uninst.log', '/norestart', '/q', '/x', (Get-CimInstance -ClassName Win32_Product -Filter "Name='Datadog Agent'" -ComputerName .).IdentifyingNumber)
-```
-
-{{% /tab %}}
-{{< /tabs >}}
\ No newline at end of file
+[1]: /es/agent/basic_agent_usage
\ No newline at end of file
diff --git a/content/es/agent/guide/private-link.md b/content/es/agent/guide/private-link.md
index bb053e25255f7..5d923eff4fc6b 100644
--- a/content/es/agent/guide/private-link.md
+++ b/content/es/agent/guide/private-link.md
@@ -1,199 +1,219 @@
---
+further_reading:
+- link: /agent/logs
+ tag: Documentación
+ text: Habilitar la recopilación de logs con el Agent
+- link: /integrations/amazon_web_services/#log-collection
+ tag: Documentación
+ text: Recopilar logs de tus servicios AWS
kind: guía
-title: Conectarse a Datadog a través de AWS PrivateLink
+title: Conectarse a Datadog a través de PrivateLink de AWS
---
-{{% site-region region="us3,us5,eu,gov,ap1" %}}
-
PrivateLink de Datadog no es compatible con el sitio de Datadog seleccionado.
Datadog PrivateLink no admite el sitio Datadog seleccionado.
+{{% /site-region %}}
-{{% site-region region="us" %}}
-En esta guía, te explicaremos cómo configurar [AWS PrivateLink][1] para utilizarlo con Datadog.
+{{% site-region region="us,ap1" %}}
-## Información general
+Esta guía te explica cómo configurar [AWS PrivateLink][1] para su uso con Datadog.
-En general, el proceso consiste en configurar un endpoint interno en tu nube virtual privada (VPC, por siglas en inglés) al que puedan enviar datos los Datadog Agent locales. Después, el endpoint de tu VPC se conecta con el endpoint de la VPC de Datadog.
+## Resumen
-{{< img src="agent/guide/private_link/vpc_diagram_schema.png" alt="Esquema del diagrama de la VPC" >}}
+El proceso general consiste en configurar un endpoint interno en tu VPC al que los Agents de Datadog locales puedan enviar datos. El endpoint de tu VPC se interconecta entonces con el endpoint de la VPC de Datadog.
+
+{{< img src="agent/guide/private_link/vpc_diagram_schema.png" alt="Esquema gráfico de la VPC" >}}
## Configuración
-Datadog expone los endpoints de AWS PrivateLink en **us-east-1**.
+Datadog expone endpoints PrivateLink de AWS en **{{< region-param key="aws_region" >}}**.
-Sin embargo, para dirigir el tráfico al PrivateLink de Datadog disponible en `us-east-1` desde otras regiones, utiliza la [interconexión interregional de la VPC de Amazon][2]. La interconexión interregional de la VPC permite establecer conexiones entre VPC de diferentes regiones de AWS. Esto permite la comunicación entre recursos de VPC de distintas regiones mediante direcciones IP privadas. Para obtener más información, consulta [¿Qué es una interconexión de VPC?][2].
+Sin embargo, para dirigir el tráfico a la oferta PrivateLink de Datadog en {{< region-param key="aws_region" code="true" >}} desde otras regiones, utiliza la [interconexión de VPC de Amazon][2] interregional. La interconexión de VPC interregional te permite establecer conexiones entre VPC de diferentes regiones de AWS. Esto permite que los recursos de VPC de diferentes regiones se comuniquen entre sí utilizando direcciones IP privadas. Para obtener más información, consulta [¿Qué es una interconexión de VPC de Amazon?][2].
{{< tabs >}}
-{{% tab "us-east-1" %}}
+{{% tab "Conectar desde la misma región" %}}
-1. Conecta la consola de AWS a la región **us-east-1** y crea un endpoint de VPC.
+1. Conecta la consola de AWS a la región **{{< region-param key="aws_region" >}}** y crea un endpoint de VPC.
- {{< img src="agent/guide/private_link/create_vpc_endpoint.png" alt="Crear endpoint de VPC" style="width:60%;" >}}
+ {{< img src="agent/guide/private_link/create_vpc_endpoint.png" alt="Crear un endpoint de VPC" style="width:60%;" >}}
2. Selecciona **Find service by name** (Buscar servicio por nombre).
-3. Rellena el campo de texto _Service Name_ (Nombre del servicio) de acuerdo con el servicio para el que deseas configurar AWS PrivateLink:
-
- {{< img src="agent/guide/private_link/vpc_service_name.png" alt="Nombre del servicio de VPC" style="width:70%;" >}}
-
-| Datadog | Nombre del servicio de PrivateLink | Nombre del DNS privado |
-|---------------------------| --------------------------------------------------------- | -------------------------------------------------- |
-| Logs (entrada HTTP del Agent) | `com.amazonaws.vpce.us-east-1.vpce-svc-025a56b9187ac1f63` | `agent-http-intake.logs.datadoghq.com` |
-| Logs (entrada HTTP del usuario) | `com.amazonaws.vpce.us-east-1.vpce-svc-0e36256cb6172439d` | `http-intake.logs.datadoghq.com` |
-| API | `com.amazonaws.vpce.us-east-1.vpce-svc-064ea718f8d0ead77` | `api.datadoghq.com` |
-| Métricas | `com.amazonaws.vpce.us-east-1.vpce-svc-09a8006e245d1e7b8` | `metrics.agent.datadoghq.com` |
-| Contenedores | `com.amazonaws.vpce.us-east-1.vpce-svc-0ad5fb9e71f85fe99` | `orchestrator.datadoghq.com` |
-| Proceso | `com.amazonaws.vpce.us-east-1.vpce-svc-0ed1f789ac6b0bde1` | `process.datadoghq.com` |
-| Elaboración de perfiles | `com.amazonaws.vpce.us-east-1.vpce-svc-022ae36a7b2472029` | `intake.profile.datadoghq.com` |
-| Trazas (traces) | `com.amazonaws.vpce.us-east-1.vpce-svc-0355bb1880dfa09c2` | `trace.agent.datadoghq.com` |
-
-4. Haz clic en **Verify** (Verificar). Si esta acción no devuelve el mensaje _Service name found_ (Nombre de servicio encontrado), contacta con el [equipo de asistencia de Datadog][1].
-5. Selecciona la VPC y las subredes que deben conectarse con el endpoint del servicio de la VPC de Datadog.
-6. En **Enable DNS name** (Habilitar el nombre del DNS), asegúrate de que está marcada la opción _Enable for this endpoint_ (Habilitar para este endpoint):
+3. Rellena el cuadro de texto _Service Name_ (_Nombre del servicio_), según el servicio para el que quieras establecer PrivateLink de AWS:
+
+ {{< img src="Agent/guide/private_link/vpc_service_name.png" alt="Nombre del servicio de VPC" style="width:70%;" >}}
+
+| Datadog | Nombre del servicio PrivateLink | Nombre del DNS privado |
+|---------------------------|----------------------------------------------------------------------------------------|------------------------------------------------------------------------|
+| Logs (Consumo HTTP del Agent) | {{< region-param key="aws_private_link_logs_agent_service_name" code="true" >}} | {{< region-param key="agent_http_endpoint" code="true">}} |
+| Logs (Consumo HTTP del usuario) | {{< region-param key="aws_private_link_logs_user_service_name" code="true" >}} | {{< region-param key="http_endpoint" code="true" >}} |
+| API | {{< region-param key="aws_private_link_api_service_name" code="true" >}} | api.{{< region-param key="dd_site" >}} |
+| Métricas | {{< region-param key="aws_private_link_metrics_service_name" code="true" >}} | metrics.agent.{{< region-param key="dd_site" >}} |
+| Contenedores {{< region-param key="aws_private_link_containers_service_name" code="true" >}} | orchestrator.{{< region-param key="dd_site" >}} |
+| Proceso | {{< region-param key="aws_private_link_process_service_name" code="true" >}} | process.{{< region-param key="dd_site" >}} |
+| Perfiles {{< region-param key="aws_private_link_profiling_service_name" code="true" >}} | intake.profile.{{< region-param key="dd_site" >}} |
+| Trazas (traces) | {{< region-param key="aws_private_link_traces_service_name" code="true" >}} | trace.agent.{{< region-param key="dd_site" >}} |
+| Monitorización de bases de datos | {{< region-param key="aws_private_link_dbm_service_name" code="true" >}} | dbm-metrics -intake .{{< region-param key="dd_site" >}} |
+| Configuración remota | {{< region-param key="aws_private_link_remote_config_service_name" code="true" >}} | config.{{< region-param key="dd_site" >}} |
+
+4. Haz clic en **Verify** (Verificar). Si el resultado no es _Service Name found_ (_Nombre del servicio encontrado_), ponte en contacto con el [servicio de soporte de Datadog][1].
+5. Elige la VPC y las subredes que deben ser interconectadas con el servicio del endpoint de VPC de Datadog.
+6. Asegúrate de que en **Enable DNS Name** (Habilitar nombre del DNS), _Enable this endpoint_ (_Habilitar para este endpoint_) está seleccionado:
{{< img src="agent/guide/private_link/enabled_dns_private.png" alt="Habilitar DNS privado" style="width:80%;" >}}
-7. Selecciona el grupo de seguridad que prefieras para establecer qué puede enviar tráfico a este endpoint de la VPC.
+7. Selecciona el grupo de seguridad que quieres que controle qué instancia puede enviar tráfico a este endpoint de la VPC.
- **Nota**: **El grupo de seguridad debe aceptar tráfico entrante en el puerto TCP `443`**.
+ **Nota**: **El grupo de seguridad debe aceptar tráfico entrante en el puerto TCP `443`**.
-8. Haz clic en **Create endpoint** (Crear endpoint), en la parte inferior de la pantalla. Si el proceso finaliza correctamente, aparecerá lo siguiente:
+8. Haz clic en **Create endpoint** (Crear endpoint), en la parte inferior de la pantalla. Si todo sale bien, se muestra lo siguiente:
- {{< img src="agent/guide/private_link/vpc_endpoint_created.png" alt="Endpoint de la VPC creado" style="width:60%;" >}}
+ {{< img src="agent/guide/private_link/vpc_endpoint_created.png" alt="Se ha creado el endpoint de la VPC" style="width:60%;" >}}
9. Haz clic en el ID del endpoint de la VPC para comprobar su estado.
-10. Espera a que el estado pase de _Pending_ (Pendiente) a _Available_ (Disponible). Esto puede tardar hasta 10 minutos. Cuando indique _Available_, ya podrás utilizar AWS PrivateLink.
+10. Espera a que el estado pase de _Pending_ (Pendiente) a _Available_ (Disponible). Esto puede tardar hasta 10 minutos. Una vez que muestre _Available_, puedes utilizar PrivateLink de AWS.
- {{< img src="agent/guide/private_link/vpc_status.png" alt="Estado de la VPC" style="width:60%;" >}}
+ {{< img src="Agent/guide/private_link/vpc_status.png" alt="Estado de la VPC" style="width:60%;" >}}
-11. Si estás recopilando datos de logs, asegúrate de que tu Agent está configurado para enviar logs a través de HTTPS. Si los datos no están ya ahí, añade lo siguiente en el [archivo de configuración `datadog.yaml` del Agent][2]:
+11. Si estás recopilando datos de logs, asegúrate de que tu Agent está configurado para enviar logs a través de HTTPS. Si los datos ya no están ahí, añade lo siguiente al archivo de [configuración del Agent `datadog.yaml`][2]:
```yaml
- logs_config:
+ logs_config:
use_http: true
```
- Si estás utilizando el Agent del contenedor, define la siguiente variable de entorno:
+ Si estás utilizando un contenedor del Agent, establece la siguiente variable de entorno en su lugar:
```
DD_LOGS_CONFIG_USE_HTTP=true
```
- Esta configuración es obligatoria cuando se envían logs a Datadog con AWS PrivateLink y el Datadog Agent, pero no es necesaria para la extensión Lambda. Para obtener más información, consulta la sección sobre la [recopilación de logs del Agent][3].
+ Esta configuración es necesaria cuando se envían logs a Datadog con PrivateLink de AWS y Datadog Agent, y no es necesaria para la extensión Lambda. Para obtener más información, consulta la [colección de logs del Agent][3].
-12. Si tu extensión Lambda carga la clave de API de Datadog desde AWS Secrets Manager usando el ARN especificado por la variable de entorno `DD_API_KEY_SECRET_ARN`, tendrás que [crear un endpoint de VPC para Secrets Manager][4].
+12. Si tu extensión Lambda carga la clave de API de Datadog desde AWS Secrets Manager utilizando el ARN especificado por la variable de entorno `DD_API_KEY_SECRET_ARN`, necesitas [crear un endpoint de VPC para Secrets Manager][4].
-13. [Reinicia tu Agent][5] para enviar datos a Datadog mediante AWS PrivateLink.
+13. [Reinicia tu Agent][5] para enviar datos a Datadog a través de PrivateLink de AWS.
[1]: /es/help/
-[2]: /es/agent/guide/agent-configuration-files/#agent-main-configuration-file
+[2]: /es/agent/configuration/agent-configuration-files/#agent-main-configuration-file
[3]: /es/agent/logs/?tab=tailexistingfiles#send-logs-over-https
[4]: https://docs.aws.amazon.com/secretsmanager/latest/userguide/vpc-endpoint-overview.html
-[5]: /es/agent/guide/agent-commands/#restart-the-agent
-{{% /tab %}}
+[5]: /es/agent/configuration/agent-commands/#restart-the-agent
+{{% /tab%}}
-{{% tab "Interconexión de la VPC" %}}
+{{% tab "Conectar desde otra región utilizando la interconexión de VPC" %}}
-### Cómo interconectar la VPC de Amazon
+### Interconexión de VPC de Amazon
-1. Conecta la consola de AWS a la región **us-east-1** y crea un endpoint de VPC.
+1. Conecta la consola de AWS a la región **{{< region-param key="aws_region" >}}** y crea un endpoint de VPC.
{{< img src="agent/guide/private_link/create_vpc_endpoint.png" alt="Crear endpoint de VPC" style="width:80%;" >}}
-2. Selecciona **Find service by name** (Buscar servicio por nombre).
-3. Rellena el campo de texto _Service Name_ (Nombre del servicio) de acuerdo con el servicio para el que deseas configurar AWS PrivateLink:
+2. Selecciona **Search Service by Name** (Buscar servicio por nombre).
+3. Rellena el cuadro de texto _Service Name_ (_Nombre del servicio_), según el servicio para el que quieras establecer PrivateLink de AWS:
{{< img src="agent/guide/private_link/vpc_service_name.png" alt="Nombre del servicio de VPC" style="width:90%;" >}}
-| Datadog | Nombre del servicio de PrivateLink |
-|---------------------------| --------------------------------------------------------- |
-| Métricas | `com.amazonaws.vpce.us-east-1.vpce-svc-09a8006e245d1e7b8` |
-| Logs (entrada HTTP del Agent) | `com.amazonaws.vpce.us-east-1.vpce-svc-025a56b9187ac1f63` |
-| Logs (entrada HTTP del usuario) | `com.amazonaws.vpce.us-east-1.vpce-svc-0e36256cb6172439d` |
-| API | `com.amazonaws.vpce.us-east-1.vpce-svc-064ea718f8d0ead77` |
-| Proceso | `com.amazonaws.vpce.us-east-1.vpce-svc-0ed1f789ac6b0bde1` |
-| Elaboración de perfiles | `com.amazonaws.vpce.us-east-1.vpce-svc-022ae36a7b2472029` |
-| Trazas (traces) | `com.amazonaws.vpce.us-east-1.vpce-svc-0355bb1880dfa09c2` |
-| Contenedores | `com.amazonaws.vpce.us-east-1.vpce-svc-0ad5fb9e71f85fe99` |
+| Datadog | Nombre del servicio PrivateLink |
+|---------------------------|----------------------------------------------------------------------------------------|
+| Logs (Consumo HTTP del Agent) | {{< region-param key="aws_private_link_logs_agent_service_name" code="true" >}} |
+| Logs (Consumo HTTP del usuario) | {{< region-param key="aws_private_link_logs_user_service_name" code="true" >}} |
+| API | {{< region-param key="aws_private_link_api_service_name" code="true" >}} |
+| Métricas | {{< region-param key="aws_private_link_metrics_service_name" code="true" >}} |
+| Contenedores {{< region-param key="aws_private_link_containers_service_name" code="true" >}} |
+| Proceso {{< region-param key="aws_private_link_process_service_name" code="true" >}} |
+| Perfiles {{< region-param key="aws_private_link_profiling_service_name" code="true" >}} |
+| Trazas (traces) {{< region-param key="aws_private_link_traces_service_name" code="true" >}} |
+| Monitorización de bases de datos {{< region-param key="aws_private_link_dbm_service_name" code="true" >}} |
+| Configuración remota | {{< region-param key="aws_private_link_remote_config_service_name" code="true" >}} |
-4. Haz clic en **Verify** (Verificar). Si esta acción no devuelve el mensaje _Service name found_ (Nombre de servicio encontrado), contacta con el [equipo de asistencia de Datadog][1].
+4. Haz clic en **Verify** (Verificar). Si no obtienes _Service Name found_ (Nombre del servicio encontrado), ponte en contacto con [el soporte de Datadog][1].
-5. A continuación, selecciona la VPC y las subredes que deben conectarse con el endpoint del servicio de la VPC de Datadog. No selecciones **Enable DNS name** (Habilitar el nombre del DNS), ya que la interconexión de la VPC requiere que el DNS se configure de forma manual.
+5. A continuación, selecciona la VPC y las subredes que se deben interconectar con el servicio del endpoint de VPC de Datadog. No selecciones **Enable DNS Name** (Habilitar nombre del DNS), ya que la interconexión de VPC requiere que el DNS se configure manualmente.
-6. Selecciona el grupo de seguridad que prefieras para establecer qué puede enviar tráfico a este endpoint de la VPC.
+6. Selecciona el grupo de seguridad de tu elección para controlar qué instancia puede enviar tráfico a este endpoint de VPC.
- **Nota**: **El grupo de seguridad debe aceptar tráfico entrante en el puerto TCP `443`**.
+ **Nota **El grupo de seguridad debe aceptar tráfico entrante en el puerto TCP `443`**.
-7. Haz clic en **Create endpoint** (Crear endpoint), en la parte inferior de la pantalla. Si el proceso finaliza correctamente, aparecerá lo siguiente:
+7. Haz clic en **Create endpoint** (Crear endpoint) en la parte inferior de la pantalla. Si todo sale bien, se muestra lo siguiente:
-{{< img src="agent/guide/private_link/vpc_endpoint_created.png" alt="Endpoint de la VPC creado" style="width:80%;" >}}
+{{< img src="agent/guide/private_link/vpc_endpoint_created.png" alt="Se ha creado el endpoint de la VPC" style="width:80%;" >}}
8. Haz clic en el ID del endpoint de la VPC para comprobar su estado.
-9. Espera a que el estado pase de _Pending_ (Pendiente) a _Available_ (Disponible). Esto puede tardar hasta 10 minutos.
-10. Después de crear el endpoint, aprovecha la interconexión de la VPC para permitir que el endpoint de PrivateLink esté disponible en otra región y enviar telemetría a Datadog a través de PrivateLink. Para obtener más información, consulta [Trabaje con interconexiones de VPC][2] en AWS.
+9. Espera a que el estado pase de _Pending_ (Pendiente) a _Available_ (Disponible). Esto puede tardar hasta 10 minutos.
+10. Luego de crear el endpoint, utiliza la interconexión de VPC para que el endpoint de PrivateLink esté disponible en otra región para enviar telemetría a Datadog a través de PrivateLink. Para obtener más información, lee la página [Trabajar con interconexiones de VPC][2] en AWS.
{{< img src="agent/guide/private_link/vpc_status.png" alt="Estado de la VPC" style="width:80%;" >}}
### Amazon Route53
-1. Crea una [zona alojada privada de Route53][3] para cada servicio para el que hayas creado un endpoint de AWS PrivateLink. Añade la zona alojada privada a la VPC en `us-east-1`.
+1. Crea una [zona alojada privada de Route53][3] para cada servicio para el que hayas creado un endpoint PrivateLink de AWS. Adjunta la zona privada alojada a la VPC en {{< region-param key="aws_region" code="true" >}}.
{{< img src="agent/guide/private_link/create-a-route53-private-hosted-zone.png" alt="Crear una zona alojada privada de Route53" style="width:80%;" >}}
-Utiliza la siguiente lista para asignar el servicio y el nombre del DNS a diferentes partes de Datadog:
+Utiliza el siguiente lista para asignar el servicio y el nombre del DNS a diferentes partes de Datadog:
- | Datadog | Nombre del servicio de PrivateLink | Nombre del DNS privado |
- |---------------------------| --------------------------------------------------------- | -------------------------------------------------- |
- | Métricas | `com.amazonaws.vpce.us-east-1.vpce-svc-09a8006e245d1e7b8` | `metrics.agent.datadoghq.com` |
- | Logs (entrada HTTP del Agent) | `com.amazonaws.vpce.us-east-1.vpce-svc-025a56b9187ac1f63` | `agent-http-intake.logs.datadoghq.com` |
- | Logs (entrada HTTP del usuario) | `com.amazonaws.vpce.us-east-1.vpce-svc-0e36256cb6172439d` | `http-intake.logs.datadoghq.com` |
- | API | `com.amazonaws.vpce.us-east-1.vpce-svc-064ea718f8d0ead77` | `api.datadoghq.com` |
- | Proceso | `com.amazonaws.vpce.us-east-1.vpce-svc-0ed1f789ac6b0bde1` | `process.datadoghq.com` |
- | Elaboración de perfiles | `com.amazonaws.vpce.us-east-1.vpce-svc-022ae36a7b2472029` | `intake.profile.datadoghq.com` |
- | Trazas (traces) | `com.amazonaws.vpce.us-east-1.vpce-svc-0355bb1880dfa09c2` | `trace.agent.datadoghq.com` |
- | Contenedores | `com.amazonaws.vpce.us-east-1.vpce-svc-0ad5fb9e71f85fe99` | `orchestrator.datadoghq.com` |
+ | Datadog | Nombre del servicio PrivateLink | Nombre del DNS privado |
+ |---------------------------|----------------------------------------------------------------------------------------|------------------------------------------------------------------------|
+ | Logs (Consumo HTTP del Agent) | {{< region-param key="aws_private_link_logs_agent_service_name" code="true" >}} | agent-http-intake .logs.{{< region-param key="dd_site" >}} |
+ | Logs (Consumo HTTP del usuario) | {{< region-param key="aws_private_link_logs_user_service_name" code="true" >}} | http-intake.logs.{{< region-param key="dd_site" >}} |
+ | API {{< region-param key="aws_private_link_api_service_name" code="true" >}} | api.{{ < region-param key="dd_site" >}} |
+ | metrics {{< region-param key="aws_private_link_metrics_service_name" code="true" >}} | metrics.agent.{{< region-param key="dd_site" >}} |
+ | Contenedores {{< region-param key="aws_private_link_containers_service_name" code="true" >}} | orchestrator.{{< region-param key="dd_site" >}} |
+ | Proceso | {{< region-param key="aws_private_link_process_service_name" code="true" >}} | process.{{< region-param key="dd_site" >}} |
+ | Perfiles {{< region-param key="aws_private_link_profiling_service_name" code="true" >}} | intake.profile.{{< region-param key="dd_site" >}} |
+ | Trazas (traces) | {{< region-param key="aws_private_link_traces_service_name" code="true" >}} | trace.agent.{{< region-param key="dd_site" >}} |
+ | Monitorización de bases de datos | {{< region-param key="aws_private_link_dbm_service_name" code="true" >}} | dbm-metrics-intake.{{< region-param key="dd_site" >}} |
+ | Configuración remota | {{< region-param key="aws_private_link_remote_config_service_name" code="true" >}} | config.{{< region-param key="dd_site" >}} |
- También puedes encontrar esta información si realizas una consulta a la API de AWS, `DescribeVpcEndpointServices`, o si utilizas el siguiente comando de la CLI: `aws ec2 describe-vpc-endpoint-services --service-names `.
-
- Por ejemplo, en el caso del endpoint de métricas de Datadog:
+ También puedes encontrar esta información enviando una consulta a la API de AWS, `DescribeVpcEndpointServices`, o utilizando el siguiente comando:
```bash
- aws ec2 describe-vpc-endpoint-services --service-names com.amazonaws.vpce.us-east-1.vpce-svc-09a8006e245d1e7b8 | jq '.ServiceDetails[0].PrivateDnsName'
+ aws ec2 describe-vpc-endpoint-services --service-names `
```
-Esto devuelve `metrics.agent.datadoghq.com`, que es el nombre de la zona alojada privada que necesitas para asociarla con la VPC en la que se origina el tráfico del Agent. Al anular este registro, se obtienen todos los nombres de host de entrada relacionados con las métricas.
+ Por ejemplo, en el caso de métricas del endpoint de Datadog para {{< region-param key="aws_region" code="true" >}}:
+
+
-2. En cada una de las nuevas zonas alojadas privadas de Route53, crea un registro A con el mismo nombre. Activa la opción **Alias**; luego, en **Route traffic to** (Dirigir tráfico hacia), elige **Alias to VPC endpoint** (Alias al endpoint de la VPC), **us-east-1**, e introduce el nombre del DNS del endpoint de la VPC asociado con el nombre del DNS.
+Esto devuelve metrics.agent.{{< region-param key="dd_site" >}}}}, el nombre de zona alojada privada que necesitas para asociar con la VPC en la que se origina el tráfico del Agent. Al anular este registro, se obtienen todos los nombres de host de consumos relacionados con métricas.
+
+2. Dentro de cada nueva zona alojada privada de Route53, crea un registro A con el mismo nombre. Activa la opción **Alias** y, a continuación, en **Route traffic to** (Enrutar el tráfico a**), selecciona **Alias to VPC endpoint** (Alias para endpoint de VPC), **{{< region-param key="aws_region" >}}**, e introduce el nombre del DNS del endpoint de VPC asociado al nombre del DNS.
**Notas**:
- - Para obtener el nombre de tu DNS, consulta la [documentación dedicada a la configuración del nombre de DNS privado de los servicios de endpoint][4].
- - El Agent envía telemetría a endpoints con versión, como`-app.agent.datadoghq.com`, que cambia el nombre a `metrics.agent.datadoghq.com` mediante un alias CNAME. Por lo tanto, solo es necesario configurar una zona alojada privada para `metrics.agent.datadoghq.com`.
+ - Para obtener el nombre de tu DNS, consulta la [documentación de la configuración del nombre del DNS privado de los servicios de endpoint][4].
+ - El Agent envía telemetría a endpoints versionados, por ejemplo, [version]-app.agent.{{< region-param key="dd_site" >}}, que se resuelven como metrics.agent.{{< region-param key="dd_site" >}} a través de un alias CNAME. Por lo tanto, sólo es necesario configurar una zona alojada privada para metrics.agent.{{< region-param key="dd_site" >}}.
-{{< img src="agent/guide/private_link/create-an-a-record.png" alt="Crear un registro A" style="width:90%;" >}}
+{{< img src="agent/guide/private_link/create-an-a-record.png" alt="Crear un registro A" style="width:90%;" >}}
-3. Configura la interconexión y el enrutamiento de la VPC de `us-east-1` que contiene los endpoints del PrivateLink de Datadog y la VPC en la región donde se ejecutan los Datadog Agents.
+3. Configura la interconexión de VPC y el enrutamiento entre VPC en una {{< region-param key="aws_region" code="true" >}} que contenga endpoints PrivateLink de Datadog y la VPC en la región donde se ejecutan los Agents de Datadog.
-4. Si las VPC se encuentran en diferentes cuentas de AWS, la VPC que contiene el Datadog Agent debe estar autorizada para asociarse con las zonas alojadas privadas de Route53 antes de continuar. Crea una [autorización de asociación para la VPC][5] en cada zona alojada privada de Route53 utilizando la región y el ID de la VPC donde se ejecuta el Datadog Agent. Esta opción no está disponible en la consola de AWS y debe configurarse con la CLI, SDK o API de AWS.
+4. Si las VPC se encuentran en diferentes cuentas de AWS, la VPC que contiene el Datadog Agent debe estar autorizada para asociarse con las zonas alojadas privadas de Route53 antes de continuar. Crea una [autorización de asociación para VPC][5] en cada zona alojada privada de Route53 utilizando la región y el ID de la VPC donde se ejecuta el Datadog Agent. Esta opción no está disponible en la consola de AWS y debe configurarse con la CLI, SDK o API de AWS.
-5. Edita la zona alojada de Route53 para añadir la VPC de non-us-east-1.
+5. Edita la zona alojada de Route53 para añadir VPC para otras regiones.
{{< img src="agent/guide/private_link/edit-route53-hosted-zone.png" alt="Editar una zona alojada privada de Route53" style="width:80%;" >}}
-6. Las VPC que tienen una zona alojada privada (o PHZ, por sus siglas en inglés) adjunta necesitan tener ciertas configuraciones específicas activadas; concretamente, las opciones `enableDnsHostnames` y `enableDnsSupport` de las VPC a las que está asociada la PHZ. Consulta [Consideraciones sobre el uso de una zona alojada privada][5].
+6. Las VPC que tienen una zona alojada privada (PHZ) adjunta necesitan tener ciertas configuraciones específicas activadas; concretamente, las opciones `enableDnsHostnames` y `enableDnsSupport` de las VPC a las que está asociada la PHZ. Consulta [Consideraciones sobre el uso de una zona alojada privada][5].
-7. [Reinicia el Agent][7] para enviar datos a Datadog mediante AWS PrivateLink.
+7. [Reinicia el Agent][7] para enviar datos a Datadog mediante PrivateLink de AWS.
#### Solucionar problemas de resolución y conectividad del DNS
-Los nombres del DNS deberían resolverse en direcciones P contenidas dentro del bloque CIDR de la VPC en `us-east-1`. Además, las conexiones con `port 443` deberían funcionar correctamente.
+Los nombres de DNS deberían resolverse en direcciones IP contenidas dentro del bloque CIDR de la VPC en la {{< region-param key="aws_region" code="true" >}} y las conexiones al `port 443` deberían funcionar correctamente.
{{< img src="agent/guide/private_link/successful-setup.png" alt="La conexión con el puerto 443 debería funcionar correctamente" style="width:80%;" >}}
-Si el DNS se resuelve en direcciones IP públicas, significa que la zona de Route53 **no** se ha asociado con la VPC en la región alternativa o que el registro A no existe.
+Si el DNS se resuelve en direcciones IP públicas, significa que la zona de Route53 **no** se ha asociado con la VPC en la región alternativa o que el registro A no existe.
-Si el DNS se cambia correctamente, pero las conexiones con `port 443` fallan, significa que la interconexión o el enrutamiento de la VPC pueden estar mal configurados o que el puerto 443 quizás no tenga permiso de salida hacia el bloque CIDR de la VPC en `us-east-1`.
+Si el DNS se resuelve correctamente, pero las conexiones al `port 443` fallan, es posible que la interconexión o el enrutamiento de la VPC estén mal configurados o que el puerto 443 no tenga permiso de salida del bloque CIDR de la VPC en la {{< region-param key="aws_region" code="true" >}}.
-Las VPC que tienen asociada una zona alojada privada (o PHZ, por sus siglas en inglés) necesitan tener activados un par de parámetros; concretamente, `enableDnsHostnames` y `enableDnsSupport` deben estar activados en las VPC a las que está asociada la PHZ. Consulta [Consideraciones sobre el uso de una zona alojada privada][6].
+Las VPC que tienen asociada una zona alojada privada (PHZ) necesitan tener ciertas configuraciones específicas activadas; concretamente, las opciones `enableDnsHostnames` y `enableDnsSupport` deben estar activadas en las VPC a las que está asociada la PHZ. Consulta [Consideraciones sobre el uso de una zona alojada privada][6].
### Datadog Agent
@@ -204,13 +224,13 @@ Las VPC que tienen asociada una zona alojada privada (o PHZ, por sus siglas en i
force_use_http: true
```
- Si estás utilizando el Agent del contenedor, define la siguiente variable de entorno:
+ Si estás utilizando el Agent del contenedor, define la siguiente variable de entorno:
```
DD_LOGS_CONFIG_FORCE_USE_HTTP=true
```
- Esta configuración es obligatoria cuando se envían logs a Datadog con AWS PrivateLink y el Datadog Agent, pero no es necesaria para la extensión Lambda. Para obtener más información, consulta la sección sobre la [recopilación de logs del Agent][9].
+ Esta configuración es obligatoria cuando se envían logs a Datadog con PrivateLink de AWS y el Datadog Agent, pero no es necesaria para la extensión Lambda. Para obtener más información, consulta la sección sobre la [recopilación de logs del Agent][9].
2. Si tu extensión Lambda carga la clave de API de Datadog desde AWS Secrets Manager usando el ARN especificado por la variable de entorno `DD_API_KEY_SECRET_ARN`, tendrás que [crear un endpoint de VPC para Secrets Manager][10].
@@ -223,23 +243,18 @@ Las VPC que tienen asociada una zona alojada privada (o PHZ, por sus siglas en i
[4]: https://docs.aws.amazon.com/vpc/latest/privatelink/view-vpc-endpoint-service-dns-name.html
[5]: https://docs.amazonaws.cn/en_us/Route53/latest/DeveloperGuide/hosted-zone-private-associate-vpcs-different-accounts.html
[6]: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zone-private-considerations.html#hosted-zone-private-considerations-vpc-settings
-[7]: /es/agent/guide/agent-commands/?tab=agentv6v7#restart-the-agent
-[8]: /es/agent/guide/agent-configuration-files/?tab=agentv6v7#agent-main-configuration-file
+[7]: /es/agent/configuration/agent-commands/?tab=agentv6v7#restart-the-agent
+[8]: /es/agent/configuration/agent-configuration-files/?tab=agentv6v7#agent-main-configuration-file
[9]: https://docs.datadoghq.com/es/agent/logs/?tab=tailexistingfiles#send-logs-over-https
[10]: https://docs.aws.amazon.com/secretsmanager/latest/userguide/vpc-endpoint-overview.html
{{% /tab %}}
{{< /tabs >}}
-## Leer más
-
-Más enlaces, artículos y documentación útiles:
-
-- [Habilitar la recopilación de logs con el Agent][3]
-- [Recopilar logs desde tus servicios de AWS][4]
-
-{{< /site-region >}}
[1]: https://aws.amazon.com/privatelink/
[2]: https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html
-[3]: /es/agent/logs
-[4]: /es/integrations/amazon_web_services/#log-collection
\ No newline at end of file
+{{% /site-region %}}
+
+## Leer más
+
+{{< partial name="whats-next/whats-next.html" >}}
\ No newline at end of file
diff --git a/content/es/agent/guide/windows-agent-ddagent-user.md b/content/es/agent/guide/windows-agent-ddagent-user.md
index 8fe7dbfad337d..98790c87becd7 100644
--- a/content/es/agent/guide/windows-agent-ddagent-user.md
+++ b/content/es/agent/guide/windows-agent-ddagent-user.md
@@ -1,13 +1,19 @@
---
+algolia:
+ tags:
+ - usuario windows agent
+ - usuario windows
+ - ddagentuser
+ - política de grupo
aliases:
- /es/agent/faq/windows-agent-ddagent-user/
kind: guía
title: Usuario del Datadog Windows Agent
---
-A partir de la versión `6.11.0`, los componentes de base y APM/rastreo del Windows Agent se ejecutan en una cuenta de usuario exclusiva en lugar de la cuenta `LOCAL_SYSTEM`, tal como ocurría en versiones anteriores. Sin embargo, si el componente Live Processes está activado, seguirá ejecutándose en la cuenta `LOCAL_SYSTEM`.
+A partir de la versión `6.11.0`, los componentes de base y APM/rastreo del Windows Agent se ejecutan en una cuenta de usuario exclusiva, en lugar de ejecutarse en la cuenta `LOCAL_SYSTEM`, tal como ocurría en versiones anteriores. Sin embargo, si el componente Live Process está activado, seguirá ejecutándose en la cuenta `LOCAL_SYSTEM`.
-El instalador del Agent crea una nueva cuenta de forma predeterminada (`ddagentuser`), pero también puede utilizar una cuenta que el usuario facilite.
+El instalador del Agent crea una nueva cuenta de forma predeterminada (`ddagentuser`), pero también puede utilizar una cuenta que el usuario proporcione.
Durante la instalación, la cuenta se asigna a los siguientes grupos:
* “Performance Monitor Users” (Usuarios del monitor de rendimiento)
@@ -23,31 +29,31 @@ Además, durante la instalación, se aplican las siguientes políticas de seguri
* Se deniega el inicio de sesión a través de servicios de escritorio remoto
* Se inicia sesión como servicio
-**Importante**: Dado que la cuenta se modifica durante la instalación para restringir sus privilegios, como pueden ser los de inicio de sesión, verifica que no se trata de una cuenta de usuario “real”, sino de una cuenta destinada exclusivamente a ejecutar el Datadog Agent.
+**Importante**: Dado que la cuenta se modifica durante la instalación para restringir sus privilegios, como pueden ser los de inicio de sesión, asegúrate de que no se trata de una cuenta de usuario “real”, sino de una cuenta destinada exclusivamente a ejecutar el Datadog Agent.
-**Nota**: Todos los ejemplos de comandos de esta página utilizan `<>` para indicar las variables que deben sustituirse. Por ejemplo, si la cuenta de usuario es `ddagentuser` y el comando contiene `DDAGENTUSER_NAME=`, habrá que introducir `DDAGENTUSER_NAME=ddagentuser` en la línea de comandos.
+**Nota**: Todos los ejemplos de comandos de esta página utilizan `<>` para indicar la variable que debe sustituirse. Por ejemplo, si la cuenta de usuario es `ddagentuser` y el comando contiene `DDAGENTUSER_NAME=`, habrá que introducir `DDAGENTUSER_NAME=ddagentuser` en la línea de comandos.
-**Nota**: A partir de la versión `7.38.0/6.38.0`, el instalador admite el uso de una **cuenta de servicio administrada de grupo (gMSA)**. Para especificar una cuenta de este tipo, añade **$** al final del nombre de usuario: `\`$. Recuerda que esta cuenta debe existir *antes* de la instalación, ya que el instalador no puede crearla.
+**Nota**: A partir de la versión , el instalador admite el uso de una **cuenta de servicio administrada de grupo (gMSA)**. Para especificar una cuenta de este tipo, añade **$** al final del nombre de usuario `\. Recuerda que la cuenta de servicio administrada de grupo debe existir *antes* de la instalación, ya que el instalador no puede crearla.
## Instalación
-Si no se define ninguna cuenta de usuario en la línea de comandos, el instalador intentará crear una cuenta de usuario local llamada `ddagentuser` con una contraseña generada de forma aleatoria.
+Si no se especifica una cuenta de usuario en la línea de comandos, el instalador intentará crear una cuenta de usuario local llamada `ddagentuser` con una contraseña generada de forma aleatoria.
-Si se especifica una cuenta de usuario en la línea de comandos, pero la cuenta no se encuentra en el sistema, el instalador intentará crearla. Si se ha proporcionado una contraseña, el instalador la utilizará; de lo contrario, generará una contraseña aleatoria.
+Si se especifica una cuenta de usuario en la línea de comandos, pero esta cuenta de usuario no se encuentra en el sistema, el instalador intentará crearla. Si se especificó una contraseña, el instalador utilizará esa contraseña, de lo contrario generará una contraseña aleatoria.
-Para definir el nombre de usuario (USERNAME) y la contraseña (PASSWORD) opcionales en la línea de comandos, se han de introducir las siguientes propiedades en el comando `msiexec` (elimina los corchetes `<>` de los parámetros correspondientes):
+Para definir parámetros USERNAME (Nombre de usuario) y PASSWORD (Contraseña) opcionales en la línea de comandos, debes introducir las siguientes propiedades en el comando `msiexec` (elimina los corchetes `<>` de los parámetros anteriores):
```shell
msiexec /i ddagent.msi DDAGENTUSER_NAME= DDAGENTUSER_PASSWORD=
```
-**Nota**: El `` debe contener 20 caracteres como máximo para cumplir los requisitos del [atributo del nombre de cuenta SAM del esquema de Active Directory (esquema de AD)][1] de Microsoft.
+**Nota**: El `` debe contener 20 caracteres como máximo para cumplir los requisitos del [atributo SAM-Account-Name (esquema de AD) de Active Directory][1] de Microsoft.
**Nota**: Debido a una restricción del instalador MSI, la propiedad `DDAGENTUSER_PASSWORD` no puede contener el carácter del punto y coma: `;`.
-**Nota**: Si después de haber realizado la instalación tienes algún problema de permisos con los checks `system` y `winproc`, asegúrate de que `ddagentuser` es miembro de los grupos “Performance Monitor Users” y “Event Log Readers”.
+**Nota**: Si después de haber realizado la instalación tienes algún problema de permisos con los checks `system` y `winproc`, asegúrate de que `ddagentuser` es miembro de los grupos “Performance Monitor Users” (Usuarios de monitorización del rendimiento) y “Event Log Readers” (Lectores de logs de eventos).
-**Nota**: No es posible definir el usuario en la IU del instalador. Utiliza la línea de comandos para introducir el `DDAGENTUSER_NAME` y otros parámetros. Estos parámetros se tendrán en cuenta incluso para instalar IU.
+**Nota**: No es posible especificar el usuario en la IU del instalador. Utiliza la línea de comandos para introducir el `DDAGENTUSER_NAME` y otros parámetros. Estos parámetros se tendrán en cuenta incluso para instalar IU.
### Instalación con política de grupo
@@ -60,20 +66,20 @@ Si la política de grupo del dominio no lo permite, la configuración de la inst
En las máquinas unidas a un dominio, el instalador del Agent puede utilizar una cuenta proporcionada por el usuario, ya sea de dominio o local, o bien crear una cuenta local.
-Si se define una cuenta de dominio en la línea de comandos, esta debe existir antes de la instalación, ya que solo los controladores de dominio pueden crear cuentas de dominio.
+Si se especifica una cuenta de dominio en la línea de comandos, esta debe existir antes de la instalación, ya que sólo los controladores de dominio pueden crear cuentas de dominio.
-Si se especifica una cuenta de usuario en la línea de comandos, pero la cuenta no se encuentra en el sistema, el instalador intentará crearla. Si se ha proporcionado una contraseña, el instalador la utilizará; de lo contrario, generará una contraseña aleatoria.
+Si se especifica una cuenta de usuario en la línea de comandos, pero esta cuenta de usuario no se encuentra en el sistema, el instalador intentará crearla. Si se especificó una contraseña, el instalador utilizará esa contraseña, de lo contrario generará una contraseña aleatoria.
-Para definir un nombre de usuario de una cuenta de dominio, utiliza el siguiente formulario de la propiedad `DDAGENTUSER_NAME`:
+Para definir un nombre de usuario de una cuenta de dominio, utiliza el siguiente formato de propiedad `DDAGENTUSER_NAME`:
```shell
msiexec /i ddagent.msi DDAGENTUSER_NAME=\ DDAGENTUSER_PASSWORD=
```
-El `` puede ser un nombre de dominio completo (con el formato `mydomain.com`) o el nombre NETBIOS (el nombre anterior a Windows 2000).
+El `` puede ser un nombre de dominio completo (con el formato `mydomain.com`) o el nombre NETBIOS (el nombre anterior a Windows 2000).
Además, debe separarse del `` con una barra inversa: `\`.
-**Nota**: El `` debe contener 20 caracteres como máximo para cumplir los requisitos del [atributo del nombre de cuenta SAM del esquema de Active Directory (esquema de AD)][1] de Microsoft.
+**Nota**: El `` debe contener 20 caracteres como máximo para cumplir los requisitos del [atributo SAM-Account-Name (AD Schema) del esquema de Active Directory)][1] de Microsoft.
**Nota**: Debido a una restricción del instalador MSI, la propiedad `DDAGENTUSER_PASSWORD` no puede contener el carácter del punto y coma: `;`.
@@ -81,35 +87,34 @@ Además, debe separarse del `` con una barra inversa: `\`.
##### Controladores de dominio principal y secundario
-Cuando se instala el Agent en un controlador de dominio, el concepto de cuenta de usuario local no existe. Por tanto, si el instalador crea una cuenta de usuario, se tratará de un usuario de dominio en lugar de un usuario local.
+Cuando se instala el Agent en un controlador de dominio, el concepto de cuenta de usuario local no existe. Por lo tanto, si el instalador crea una cuenta de usuario, se tratará de un usuario de dominio en lugar de un usuario local.
Si se especifica una cuenta de usuario en la línea de comandos, pero la cuenta no se encuentra en el sistema, el instalador intentará crearla. Para que la instalación se realice correctamente, debe especificarse una contraseña.
-Si la cuenta de usuario indicada es de un dominio superior, el instalador utilizará esa cuenta.
-Si la cuenta de usuario no existe, la creará en el dominio secundario (el dominio al que está unido el controlador). El instalador nunca creará una cuenta de usuario en el dominio superior.
+Si la cuenta de usuario especificada es de un dominio principal, el instalador utiliza esa cuenta de usuario. Asegúrate de que existe una cuenta de usuario en el dominio principal antes de la instalación, ya que el instalador nunca crea una cuenta de usuario en el dominio principal.
-##### Controladores de dominio de solo lectura
+##### Controladores de dominio de sólo lectura
-El instalador solo puede utilizar una cuenta de dominio existente cuando instala en un controlador de dominio de solo lectura.
+El instalador sólo puede utilizar una cuenta de dominio existente cuando instala en un controlador de dominio de sólo lectura.
### Instalación con Chef
-Si utilizas Chef y el cookbook oficial de `datadog` para desplegar el Agent en hosts de Windows, **usa la versión 2.18.0 (o una posterior)** del cookbook para asegurarte de que los archivos de configuración del Agent disponen de los permisos adecuados.
+Si utilizas Chef y el cookbook oficial de `datadog` para implementar el Agent en hosts de Windows, **utiliza la versión 2.18.0 o posterior** del cookbook para asegurarte de que los archivos de configuración del Agent disponen de los permisos adecuados.
-## Actualización
+## Actualizar
-En las versiones anteriores al Agent `7.25.0`, cuando se actualice el Datadog Agent en un controlador de dominio o host en los que el usuario haya proporcionado un nombre de usuario para el Agent, habrá que introducir el `DDAGENTUSER_NAME`, pero no la `DDAGENTUSER_PASSWORD`.
+En las versiones del Agent anteriores a `7.25.0`, cuando actualices el Datadog Agent en un controlador de dominio o host en que el usuario haya proporcionado un nombre de usuario para el Agent, deberás introducir el `DDAGENTUSER_NAME`, pero no la `DDAGENTUSER_PASSWORD`.
-A partir de la versión `7.25.0` del Agent, el instalador mantiene el nombre de usuario utilizado para instalar el Agent y lo reutiliza en futuras actualizaciones.
+A partir de la versión `7.25.0` del Agent, el instalador conserva el nombre de usuario utilizado para instalar el Agent y lo reutiliza en futuras actualizaciones.
Aun así, es posible anular el valor guardado con `DDAGENTUSER_NAME`.
## Integraciones del Agent
### Permisos generales
-Se ha hecho todo lo posible para garantizar que la transición de `LOCAL_SYSTEM` a `ddagentuser` se realice sin problemas. Sin embargo, se ha detectado una clase de problemas por los que, una vez instalado el Agent, es necesario realizar una modificación determinada de la configuración. Estos problemas se producen porque, anteriormente, el Windows Agent estaba sujeto a los derechos del administrador. En cambio, la nueva versión del Agent no necesita estos derechos de forma predeterminada.
+Se ha hecho todo lo posible para garantizar que la transición de `LOCAL_SYSTEM` a `ddagentuser` sea fluida. Sin embargo, se ha detectado una clase de problemas que requieren que se realice una modificación determinada de la configuración después de instalar el Agent. Estos problemas se producen porque el Windows Agent anteriormente dependía de derechos de administrador que la nueva versión del Agent no posee de forma predeterminada.
-Por ejemplo, si el check de directorio está monitorizando un directorio con unos derechos de acceso concretos, como puede ser permitir la lectura solo a los miembros del grupo de administradores, el Agent existente puede monitorizar ese directorio adecuadamente, dado que `LOCAL_SYSTEM` tiene derechos de administrador. Tras la actualización, el administrador deberá añadir `ddagentuser` a la lista de control de acceso de ese directorio para que el check de directorio funcione.
+Por ejemplo, si el check de directorios está monitorizando un directorio con derechos de acceso específicos, como por ejemplo permitir la lectura sólo a miembros del grupo de administradores, el Agent existente puede monitorizar ese directorio adecuadamente, ya que `LOCAL_SYSTEM` cuenta con derechos de administrador. Luego de la actualización, el administrador debe añadir `ddagentuser` a la lista de control de acceso de ese directorio para que el check de directorios funcione.
**Nota**: En el caso del sistema operativo Windows Server, la integración de servicios de Windows no puede comprobar el servicio del servidor DHCP debido a la lista de control de acceso especial del servicio `DHCPServer`. En este caso, el check devuelve `UNKNOWN`.
@@ -117,7 +122,7 @@ Por ejemplo, si el check de directorio está monitorizando un directorio con uno
### Integraciones basadas en JMX
-Con el cambio a `ddagentuser`, tus integraciones basadas en JMX se verán afectadas si el JMXFetch del Agent está configurado para conectarse a través de la extensión Attach API a las máquinas JVM monitorizadas. Por ejemplo:
+El cambio a `ddagentuser` afectará tus integraciones basadas en JMX, si el JMXFetch del Agent está configurado para conectarse a través de la extensión Attach API a las máquinas JVM monitorizadas. Por ejemplo:
1. Si utilizas una integración basada en JMX, como:
* [ActiveMQ][2]
@@ -129,35 +134,35 @@ Con el cambio a `ddagentuser`, tus integraciones basadas en JMX se verán afecta
* [Tomcat][8]
* [Kafka][9]
-2. **Y** si has configurado la integración con el parámetro `process_name_regex` en lugar de con los parámetros `host` y `port`.
+2. **Y** si has configurado la integración con el parámetro `process_name_regex`, en lugar de con los parámetros `host` y `port`.
-Si utilizas Attach API, el cambio que se produce respecto al contexto de usuario implica que el JMXFetch del Agent solo podrá conectarse a las máquinas JVM que también se ejecuten en el contexto de usuario `ddagentuser`. En la mayoría de los casos, se recomienda cambiar a JMXFetch para utilizar JMX Remote activando JMX Remote en las máquinas JVM de destino y configurando las integraciones JMX con `host` y `port`. Para obtener más información, consulta la [documentación acerca de JMX][5].
+Si utilizas Attach API, el cambio que se produce en el contexto de usuario implica que el JMXFetch del Agent sólo podrá conectarse a las máquinas JVM que también se ejecuten en el contexto de usuario `ddagentuser`. En la mayoría de los casos, recomendamos cambiar a JMXFetch para utilizar JMX Remote activando JMX Remote en las máquinas JVM de destino y configurando las integraciones JMX con `host` y `port`. Para obtener más información, consulta la [documentación acerca de JMX][5].
### Check del proceso
-En la versión 6.11 y posteriores, el Agent se ejecuta como `ddagentuser` en lugar de `Local System`. Por este motivo, el Agent no tiene acceso a la línea de comandos completa de los procesos que se ejecutan en otros usuarios ni al usuario de los procesos de otros usuarios. Esto provoca que las siguientes opciones del check no funcionen:
+En la versión 6.11 y posteriores, el Agent se ejecuta como `ddagentuser` en lugar de `Local System`. Por este motivo, el Agent no tiene acceso a la totalidad de la línea de comandos de los procesos que se ejecutan en otros usuarios, ni al usuario de los procesos de otros usuarios. Esto provoca que las siguientes opciones del check no funcionen:
-* `exact_match`, cuando se defina como `false`
-* `user`, que permite seleccionar los procesos que pertenecen a un usuario concreto
+* `exact_match`, cuando se define como `false`
+* `user`, que permite seleccionar los procesos que pertenecen a un usuario específico
-Para restablecer el comportamiento anterior y ejecutar el Agent como `Local System` (no recomendado), abre una consola del administrador y ejecuta el siguiente comando: `sc.exe config "datadogagent" obj= LocalSystem`. Otra posibilidad es abrir el administrador de servicios, ir al Datadog Agent > Properties (Propiedades) y definir “Log On” (Iniciar sesión) como `Local System`.
+Para restablecer el comportamiento anterior y ejecutar el Agent como `Local System` (no recomendado), abre una consola de administrador y ejecuta el siguiente comando: `sc.exe config "datadogagent" obj= LocalSystem`. Otra posibilidad es abrir el administrador de servicios, ir a Datadog Agent > Properties (Datadog Agent > Propiedades) y definir “Log On” como `Local System`.
### Integración de Cassandra Nodetool
Para que la integración de Cassandra Nodetool siga funcionando, aplica los siguientes cambios en tu entorno:
* Permite que el directorio de instalación de Nodetool acceda al `ddagentuser`.
-* Configura las variables de entorno del directorio de instalación de Nodetool (`CASSANDRA_HOME` y `DSCINSTALLDIR`) como variables para todo el sistema y no solo para el usuario que realiza la instalación de Nodetool.
+* Configura las variables de entorno del directorio de instalación de Nodetool (`CASSANDRA_HOME` y `DSCINSTALLDIR`) como variables para todo el sistema y no sólo para el usuario que instala Nodetool.
## Canal de logs de seguridad
-Si vas a utilizar la [integración de Win32 Event Log con Datadog][10], debes añadir el usuario `ddagentuser` de Datadog al grupo “Event Log Readers” para recopilar logs del canal de logs de seguridad:
+Si vas a utilizar la [integración de logs de eventos Win32 con Datadog][10], debes añadir el usuario `ddagentuser` de Datadog al grupo “Event Log Readers” (Lectores de logs de eventos) para recopilar logs del canal de logs de seguridad:
-1. Abre la ventana Ejecutar con el atajo *Windows+R* y escribe `compmgmt.msc` en el campo de texto.
-2. Dirígete a *System Tools* (Herramientas del sistema) -> *Local Users and Groups* (Grupos y usuarios locales) -> *Groups* (Grupos).
-3. Haz clic con el botón derecho del ratón en **Event Log Readers** y selecciona *Properties* (Propiedades).
+1. Abre la ventana de ejecución con el atajo *Windows+R* y escribe `compmgmt.msc` en el campo de texto.
+2. Ve a *System Tools* -> *Local Users and Groups* -> *Groups* (Herramientas del sistema -> Grupos y usuarios locales -> Grupos).
+3. Haz clic con el botón derecho del ratón en **Event Log Readers** (Lectores de logs de eventos) y selecciona *Properties* (Propiedades).
4. Haz clic en *Add* (Añadir) e introduce `ddagentuser` -> *Check Names* (Nombres de checks).
-5. Haz clic en *OK* (Aceptar) y *Apply* (Aplicar).
+5. Haz clic en *OK* (Aceptar) y en *Apply* (Aplicar).
[1]: https://docs.microsoft.com/en-us/windows/win32/adschema/a-samaccountname?redirectedfrom=MSDN
[2]: /es/integrations/activemq/
diff --git a/content/es/agent/supported_platforms.md b/content/es/agent/supported_platforms.md
new file mode 100644
index 0000000000000..12071b348c485
--- /dev/null
+++ b/content/es/agent/supported_platforms.md
@@ -0,0 +1,339 @@
+---
+disable_toc: false
+further_reading:
+- link: agent/basic_agent_usage/
+ tag: Documentación
+ text: Uso básico del Agent
+kind: Documentación
+title: Plataformas compatibles
+---
+
+El Datadog Agent es compatible con una amplia gama de sistemas operativos y plataformas. Si tu sistema operativo no aparece en la lista, podría servirte [una instalación de origen][1].
+
+{{< tabs >}}
+{{% tab "Linux" %}}
+
+## X86 de 64 bits
+
+
+
+Una marca de verificación ({{< X >}}) indica compatibilidad con todas las versiones secundarias y de parche.
+
+Para instalar una versión específica del Windows Agent, consulta la [lista de instaladores][8].
+
+[8]: https://ddagent-windows-stable.s3.amazonaws.com/installers_v2.json
+
+{{% /tab %}}
+{{% tab "macOS" %}}
+
+## X86 de 64 bits
+
+| Versión de macOS | Agent 5 | Agent 6 | Agent 7 |
+|---------------|---------|---------|---------|
+| 10.10 - 10.11 | <= 5.11.3 |||
+| 10.12 || <= 6.34.0 | <= 7.34.0 |
+| 10.13 || <= 6.38.2 | <= 7.38.2 |
+| >= 10.14 || | >= 7.39.0 |
+
+## ARM64 de Apple
+
+| Versión de macOS | Agent 7 |
+|----------------|---------|
+| >= 11.0 | >= 7.39.0 |
+
+{{% /tab %}}
+
+{{% tab "Nube y contenedores" %}}
+
+## Compatible con X86 de 64 bits
+
+| Agent | [Docker][5] | [Kubernetes][6] | [Azure Stack HCI OS][7] |
+|-------|-------------|-----------------|--------------------------|
+| 5 | >= 1.14 | 1.3 - 1.8 ||
+| 6 | >= 1.14 | >= 1.3 | Todas las versiones |
+| 7 | >= 1.14 | >= 1.3 | Todas las versiones |
+
+
+## Compatible con ARM V8 de 64 bits
+
+Las versiones 6 y 7 del Agent son compatibles con las siguientes plataformas ARM V8 de 64 bits:
+
+| Plataforma | Versiones compatibles | Compatible con ARM V8 de 64 bits | Compatible con X86 de 64 bits |
+|-------------|--------------------|-----------------------|--------------------|
+| [Docker][5] | >= 1.14 | | |
+| [Kubernetes][6] | >= 1.3 | | |
+
+
+[5]: /es/agent/docker/
+[6]: /es/agent/basic_agent_usage/kubernetes/
+[7]: /es/agent/basic_agent_usage/windows/
+
+{{% /tab %}}
+
+{{% tab "Unix" %}}
+
+Las versiones 6 y 7 del Agent son compatibles con las siguientes versiones de [AIX][1]:
+
+- 6.1 TL9 SP6
+- 7.1 TL5 SP3
+- 7.2 TL3 SP0
+
+
+[1]: /es/agent/basic_agent_usage/aix/
+{{% /tab %}}
+{{< /tabs >}}
+
+## Lectura adicional
+
+{{< partial name="whats-next/whats-next.html" >}}
+
+[1]: /es/agent/basic_agent_usage/source/
\ No newline at end of file
diff --git a/content/es/getting_started/tagging/using_tags.md b/content/es/getting_started/tagging/using_tags.md
index 6c9cf8b92a4e5..56dd880ff0ce8 100644
--- a/content/es/getting_started/tagging/using_tags.md
+++ b/content/es/getting_started/tagging/using_tags.md
@@ -1,46 +1,46 @@
---
aliases:
- /es/tagging/using_tags/
-description: Descubre cómo usar las etiquetas (tags) en los productos de Datadog.
+description: Descubre cómo utilizar etiquetas (tags) en los productos de Datadog.
further_reading:
- link: https://www.datadoghq.com/blog/tagging-best-practices/
tag: Blog
- text: Prácticas recomendadas para el etiquetado de tu infraestructura y aplicaciones
+ text: Prácticas recomendadas para el etiquetado de tu infraestructura y tus aplicaciones
- link: /getting_started/tagging/
tag: Documentación
text: Empezando con las etiquetas (tags)
- link: /getting_started/tagging/assigning_tags/
tag: Documentación
- text: Aprende a asignar etiquetas (tags)
+ text: Aprender a asignar etiquetas
kind: documentación
-title: Usar etiquetas (tags)
+title: Uso de etiquetas (tags)
---
## Información general
-Una vez que hayas [asignado las tags][1], podrás empezar a usarlas para filtrar y agrupar los datos en la plataforma de Datadog. Las tags sirven para incluir o excluir datos.
+Una vez que hayas [asignado las etiquetas][1], podrás empezar a utilizarlas para filtrar y agrupar los datos en tu plataforma de Datadog. Las etiquetas sirven para incluir o excluir datos.
-Cuando se trata de incluir o excluir varias tags:
+Cuándo incluir o excluir varias etiquetas:
-* Para incluir, se emplea la lógica `AND`
-* Para excluir, se emplea la lógica `OR`
+* Para incluirlas, se emplea la lógica `AND`
+* Para excluirlas, se emplea la lógica `OR`
## Eventos
-El [Events Explorer][2] (Navegador de eventos) muestra los eventos de tu entorno que tienen lugar durante un determinado período de tiempo. Utiliza las tags para filtrar la lista de eventos y centrarte en un subconjunto de eventos. Después, escribe `tags:` seguido de una tag para ver todos los eventos procedentes de un host, una [integración][3] o un servicio que tengan esa misma tag. Por ejemplo, puedes usar `tags:service:coffee-house` para buscar la tag `service:coffee-house`.
+El [explorador de eventos][2] muestra los eventos de tu entorno que tienen lugar durante un determinado periodo de tiempo. Utiliza etiquetas para filtrar la lista de eventos y centrarte en un subconjunto de eventos. Introduce `tags:` seguido de una etiqueta para ver todos los eventos procedentes de un host, una [integración][3] o un servicio que tengan esa misma etiqueta. Por ejemplo, puedes utilizar `tags:service:coffee-house` para buscar la etiqueta `service:coffee-house`.
-Para buscar varias tags de forma inclusiva, haz uso de los paréntesis y separa las tags entre sí con OR: `tags:(service:coffee-house OR host:coffeehouseprod)`. Para buscar varias tags de forma exclusiva, sepáralas entre sí con AND: `tags:(service:coffee-house AND host:coffeehouseprod)`.
+Para buscar varias etiquetas de forma inclusiva, haz uso de los paréntesis y separa las etiquetas entre sí con OR: `tags:(service:coffee-house OR host:coffeehouseprod)`. Para buscar varias etiquetas de forma exclusiva, sepáralas entre sí con AND: `tags:(service:coffee-house AND host:coffeehouseprod)`.
## Dashboards
{{< tabs >}}
{{% tab "Asignación" %}}
-Utiliza etiquetas (tags) para filtrar métricas y mostrarlas en un [dashboard gráfico][1], o para crear grupos añadidos de métricas para mostrar. Para filtrar los métricas que se van a mostrar, introduce la etiqueta (tag) en el cuadro de texto **from** (desde). Esta métrica se muestra en todas las fuentes que tienen asignada esa etiqueta (tag) particular (`service:web-store`, en el ejemplo de abajo).
+Utiliza etiquetas para filtrar métricas y mostrarlas en un [dashboard gráfico][1] o para crear grupos añadidos de métricas para mostrar. Para filtrar las métricas que se van a mostrar, introduce la etiqueta en el cuadro de texto **from** (desde). Esta métrica se muestra en todas las fuentes que tienen asignada esa etiqueta particular (`service:web-store`, en el ejemplo de abajo).
-{{< img src="tagging/using_tags/dashboards_tags_example.png" alt="Filtra métricas en dashboards añadiendo una etiqueta (tag) en el campo 'from' (desde). En este ejemplo, la métrica se filtra por 'service:web-store'" style="width:80%;">}}
+{{< img src="tagging/using_tags/dashboards_tags_example.png" alt="Filtra métricas en dashboards añadiendo una etiqueta en el campo 'from'. En este ejemplo, la métrica se filtra por 'service:web-store'" style="width:80%;">}}
-También se pueden filtrar valores de las tags de forma avanzada con los filtros boleanos. Así pues, se admite la siguiente sintaxis boleana:
+También se pueden filtrar valores de etiquetas de forma avanzada con filtros booleanos. Se admite la siguiente sintaxis booleana:
* `NOT`, `!`
* `AND`, `,`
@@ -48,24 +48,24 @@ También se pueden filtrar valores de las tags de forma avanzada con los filtros
* `key IN (tag_value1, tag_value2,...)`
* `key NOT IN (tag_value1, tag_value2,...)`
-Usa `AND` y `ORs` para consultar una métrica en varias tags concretas:
+Utiliza `AND` y `ORs` para consultar una métrica en varias etiquetas concretas:
-{{< img src="tagging/using_tags/dashboard_advanced_tags_AND_OR.png" alt="Filtro booleano con Y/O" style="width:80%;">}}
+{{< img src="tagging/using_tags/dashboard_advanced_tags_AND_OR.png" alt="Filtro booleano con AND/OR" style="width:80%;">}}
-Usa `IN` y `NOT IN` para filtrar rápidamente una métrica en función de varias tags concretas:
+Utiliza `IN` y `NOT IN` para filtrar rápidamente una métrica en función de varias etiquetas concretas:
-{{< img src="tagging/using_tags/dashboard_advanced_tags_NOT_IN.png" alt="Filtro booleano con EN/NO EN" style="width:80%;">}}
+{{< img src="tagging/using_tags/dashboard_advanced_tags_NOT_IN.png" alt="Filtro booleano con IN/NOT IN" style="width:80%;">}}
-Para crear un grupo añadido utilizando etiquetas (tags), introduce la parte clave de la etiqueta (tag) en el cuadro de texto **avg by**. Por ejemplo, si tienes un gráfico de series temporales que muestra una métrica etiquetada con la clave `service`, como `service:web-store`, introduce `service` en el cuadro de texto **avg by** para mostrar una línea por cada valor de etiqueta (tag) `service`. Cada línea representa el valor promedio de métrica en todas las fuentes que comparten ese valor de etiqueta (tag)`service`.
+Para crear un grupo conjunto utilizando etiquetas, introduce la parte clave de la etiqueta en el cuadro de texto **avg by**. Por ejemplo, si tienes un gráfico de series temporales que muestra una métrica etiquetada con la clave `service`, como `service:web-store`, introduce `service` en el cuadro de texto **avg by** para mostrar una línea por cada valor de etiqueta `service`. Cada línea representa el valor promedio de métrica en todas las fuentes que comparten ese valor de etiqueta `service`.
-{{< img src="tagging/using_tags/dashboard_group_by_tags.png" alt="Etiquetas (tags) en cuadros de texto avg by de dashboards" style="width:80%;">}}
+{{< img src="tagging/using_tags/dashboard_group_by_tags.png" alt="Etiquetas en cuadros de texto avg by de dashboards" style="width:80%;">}}
-Las etiquetas (tags) también pueden utilizarse para superponer eventos en el dashboard. Esto funciona de la misma manera que en el [explorador de eventos][2].
+Las etiquetas también pueden utilizarse para superponer eventos en el dashboard. Esto funciona de la misma manera que en el [explorador de eventos][2].
Las coincidencias de eventos se superponen como barras verticales en el gráfico. En el ejemplo siguiente se utiliza `service:web-store`.
-{{< img src="tagging/using_tags/dashboard_event_overlays.png" alt="Utiliza etiquetas (tags) para añadir superposiciones de eventos en dashboards" style="width:80%;">}}
+{{< img src="tagging/using_tags/dashboard_event_overlays.png" alt="Utiliza etiquetas para añadir superposiciones de eventos en dashboards" style="width:80%;">}}
-Utiliza las [variables de plantilla][3] para ahorrar tiempo al cambiar la tag **from** en los gráficos de tu dashboard. En el ejemplo de abajo, se usa `service` para representar la clave de la tag `service`. Para usar la variable de plantilla, añade la variable `$service` en el campo de texto **from** de la consulta del gráfico.
+Utiliza las [variables de plantilla][3] para ahorrar tiempo al cambiar la etiqueta **from** (desde) en los gráficos de tu dashboard. En el ejemplo de abajo, se utiliza `service` para representar la clave de la etiqueta `service`. Para utilizar la variable de plantilla, añade la variable `$service` en el campo de texto **from** de tu consulta del gráfico.
{{< img src="tagging/using_tags/dashboard_dynamic_template_variables.png" alt="Variables de plantillas de dashboards" style="width:80%;">}}
@@ -75,98 +75,98 @@ Utiliza las [variables de plantilla][3] para ahorrar tiempo al cambiar la tag **
{{% /tab %}}
{{% tab "Ejemplos" %}}
-Este es un ejemplo de etiquetas (tags) que utilizan el editor de gráficos de series temporales. En la primera captura de pantalla, no se han aplicado etiquetas (tags) y se muestra el uso promedio de CPU en todos los hosts:
+Este es un ejemplo de etiquetas que utilizan el editor de gráficos de series temporales. En la primera captura de pantalla no se han aplicado etiquetas y se muestra el uso promedio de CPU en todos los hosts:
-{{< img src="tagging/using_tags/dashboard_timeseries_graph_editor_no_tags.png" alt="Editor de gráficos de series temporales sin etiquetas (tags) añadidas" style="width:75%;">}}
+{{< img src="tagging/using_tags/dashboard_timeseries_graph_editor_no_tags.png" alt="Editor de gráficos de series temporales sin etiquetas añadidas" style="width:75%;">}}
-Luego, el editor se actualiza para incluir una etiqueta (tag) (`region:eastus`) en el cuadro de texto **from** (desde), que permite a Datadog ver el uso de CPU en toda la región este de los EE.UU. Aquí, la etiqueta (tag) `region` se utiliza como ejemplo, pero puedes utilizar cualquier etiqueta (tag) arbitraria que se envíe a tu plataforma Datadog, incluyendo `application`, `service` o `environment`.
+Luego, el editor se actualiza para incluir una etiqueta (`region:eastus`) en el cuadro de texto **from** (desde), que permite a Datadog ver el uso de CPU en toda la región este de los EE. UU. Aquí, la etiqueta `region` se utiliza como ejemplo, pero puedes usar cualquier etiqueta arbitraria que se envíe a tu plataforma Datadog, incluyendo `application`, `service` o `environment`.
-{{< img src="tagging/using_tags/dashboard_timeseries_graph_editor_from_tag.png" alt="Editor de gráficos de series temporales filtrado por 'region:us-east-1' tag" style="width:75%;">}}
+{{< img src="tagging/using_tags/dashboard_timeseries_graph_editor_from_tag.png" alt="Editor de gráficos de series temporales filtrado por la etiqueta region:us-east-1 " style="width:75%;">}}
-Por último, se ha usado el segundo campo vacío (el campo de texto **avg by**) para mostrar una línea cronológica independiente por cada `host`. Por tanto, podemos ver la CPU del servidor de todos los hosts activos en el este de Estados Unidos.
+Por último, se utiliza el segundo campo vacío (el campo de texto **avg by**) para mostrar una línea cronológica independiente por cada `host`. Por tanto, podemos ver la CPU del servidor de todos los hosts activos en el este de EE. UU.
-{{< img src="tagging/using_tags/dashboard_timeseries_graph_editor_sumby_tag.png" alt="Editor de gráficos de series temporales filtrado por 'region:us-east-1' and grouped by 'host'" style="width:75%;">}}
+{{< img src="tagging/using_tags/dashboard_timeseries_graph_editor_sumby_tag.png" alt="Editor de gráficos de series temporales filtrado por 'region:us-east-1' y agrupado por 'host'" style="width:75%;">}}
-En caso de necesidad, añade más tags para acotar aún más el contexto; por ejemplo, hosts en `region:eastus` y `env:production`. Las tags pueden usarse en toda la plataforma de Datadog y aplicarse a todos los elementos principales (métricas, trazas y logs).
+Si es necesario, añade más etiquetas para acotar aún más el contexto; por ejemplo, hosts en `region:eastus` y `env:production`. Las etiquetas pueden utilizarse en toda la plataforma de Datadog y aplicarse a todos los elementos principales (métricas, trazas y logs).
{{% /tab %}}
{{< /tabs >}}
## Infraestructura
-Para filtrar el [mapa de hosts][4], la [lista de infraestructuras][5], los [contenedores][6] y los [procesos][7], introduce una tag en el campo de texto **Filter by**, situado en la parte superior de la página. Los hosts y los contenedores se pueden agrupar por clave de tag mediante el campo de texto **Group by**. Si introduces `service` en el campo de grupo, verás cada servicio como un encabezado de grupo.
+Para filtrar el [mapa de hosts][4], la [lista de infraestructuras][5], los [contenedores][6] y los [procesos][7], introduce una etiqueta en el campo de texto **Filter by** (Filtrar por), situado en la parte superior de la página. Los hosts y los contenedores se pueden agrupar por clave de etiqueta mediante el campo de texto **Group by** (Agrupar por). Si introduces `service` en el campo de grupo, verás cada servicio como un encabezado de grupo.
{{< tabs >}}
-{{% tab "Mapa de hosts" %}}
+{{% tab "Mapa de host" %}}
-En esta sección, usa tags para filtrar o agrupar hosts:
+En esta sección, utiliza etiquetas para filtrar o agrupar hosts:
-{{< img src="tagging/using_tags/hostmaptags.png" alt="Tags de Mapa de hosts" style="width:80%;">}}
+{{< img src="tagging/using_tags/hostmaptags.png" alt="Etiquetas de mapa de hosts" style="width:80%;">}}
O contenedores:
-{{< img src="tagging/using_tags/containermaptags.png" alt="Tags de Mapa de contenedores" style="width:80%;">}}
+{{< img src="tagging/using_tags/containermaptags.png" alt="Etiquetas de mapa de contenedores" style="width:80%;">}}
{{% /tab %}}
{{% tab "Lista de infraestructuras" %}}
-Estos son los campos de texto para filtrar o agrupar de la página de Lista de infraestructuras:
+Estos son los campos de texto para filtrar o agrupar de la página de la lista de infraestructuras:
-{{< img src="tagging/using_tags/infrastructuretags.png" alt="Tags en Lista de infraestructuras" style="width:80%;">}}
+{{< img src="tagging/using_tags/infrastructuretags.png" alt="Etiquetas de la lista de infraestructuras" style="width:80%;">}}
{{% /tab %}}
{{% tab "Contenedores" %}}
Estos son los campos de texto para filtrar o agrupar de la página de Live Containers:
-{{< img src="tagging/using_tags/livecontainertags.png" alt="Tags de Live Containers" style="width:80%;">}}
+{{< img src="tagging/using_tags/livecontainertags.png" alt="Etiquetas de Live Containers" style="width:80%;">}}
{{% /tab %}}
{{% tab "Procesos" %}}
Estos son los campos de texto para filtrar o agrupar de la página de Live Processes:
-{{< img src="tagging/using_tags/liveprocessestags.png" alt="Tags de Live Processes" style="width:80%;">}}
+{{< img src="tagging/using_tags/liveprocessestags.png" alt="Etiquetas de Live Processes" style="width:80%;">}}
{{% /tab %}}
{{< /tabs >}}
## Monitores
-Para filtrar monitores y [tiempos de inactividad de monitores][31] por [etiquetas (tags)][32] asignadas, utiliza las casillas de verificación de barra o faceta. El formato de la barra de búsqueda es `tag::`, por ejemplo: `tag:service:coffee-house`. Para excluir de tu búsqueda monitores con etiquetas (tags) específicas, utiliza `-`, for example: `tag:-service:coffee-house`.
+Para filtrar monitores y [tiempos de inactividad de monitores][31] por [etiquetas][32] asignadas, utiliza la barra de búsqueda o las casillas de verificación de facetas. El formato de la barra de búsqueda es `tag::`; por ejemplo: `tag:service:coffee-house`. Para excluir de tu búsqueda monitores con etiquetas específicas, utiliza `-`, for example: `tag:-service:coffee-house`.
-{{< img src="/tagging/using_tags/manage_monitor_tags.png" alt="Filtra monitores en la barra de búsqueda con etiquetas (tags)" style="width:80%;">}}
+{{< img src="/tagging/using_tags/manage_monitor_tags.png" alt="Filtra monitores en la barra de búsqueda con etiquetas" style="width:80%;">}}
-**Nota**: Las etiquetas (tags) de monitores son diferentes y están separadas de las etiquetas (tags) de métricas. Para más información, consulta la documentación sobre [etiquetas (tags) de monitores][30].
+**Nota**: Las etiquetas de monitores son diferentes y están separadas de las etiquetas de métricas. Para más información, consulta la documentación sobre [etiquetas de monitores][30].
-Al crear un nuevo monitor, utiliza *etiquetas (tags) de métricas* en:
-* el campo de texto **from** para limitar el contexto del monitor solo a las métricas que tengan esas tags.
-* el campo de texto **excluding** para eliminar las métricas correspondientes del contexto del monitor.
-* el campo de texto **avg by** para transformar el monitor en un monitor multialerta en cada valor de la tag.
+Al crear un nuevo monitor, utiliza *etiquetas de métricas* en:
+* el campo de texto **from** (desde), para limitar el contexto del monitor solo a las métricas que tengan esas etiquetas.
+* el campo de texto **excluding** (excluido), para eliminar las métricas correspondientes del contexto del monitor.
+* el campo de texto **avg by**, para transformar el monitor en un monitor multi-alerta en cada valor de la etiqueta.
## Métricas
-Utiliza etiquetas (tags) en el [explorador de métricas][8] para filtrar métricas por etiquetas (tags) o para mostrar múltiples gráficos por clave de etiqueta (tag). En el siguiente ejemplo se representa un gráfico de métrica sobre `service:web-store`.
+Utiliza etiquetas en el [explorador de métricas][8] para filtrar métricas por etiquetas o para mostrar múltiples gráficos por clave de etiqueta. En el siguiente ejemplo se representa un gráfico de métrica sobre `service:web-store`.
-{{< img src="tagging/using_tags/metrics_explorer.png" alt="Gráfico de métrica centrado en una etiqueta (tag) individual" style="width:80%;">}}
+{{< img src="tagging/using_tags/metrics_explorer.png" alt="Gráfico de métricas centrado en una etiqueta individual" style="width:80%;">}}
## Integraciones
-Algunas integraciones te ofrecen la opción de limitar las métricas usando tags.
+Algunas integraciones te ofrecen la opción de limitar las métricas utilizando etiquetas.
{{< tabs >}}
{{% tab "AWS" %}}
-El [cuadro de integración de AWS][1] tiene los filtros de tag `to hosts with tag` y `to Lambdas with tag`.
+El [cuadro de integración de AWS][1] tiene los filtros de etiquetas `to hosts with tag` y `to Lambdas with tag`.
-Estos campos aceptan una lista de tags separadas por comas (en formato `:`) que defina un filtro, el cual se usará para recopilar tus recursos de EC2 o Lambda. Puedes usar `:` tanto para incluir como para excluir funciones de monitorización según las tags. Para indicar qué tag debería excluirse, añade un `!` antes de la clave de tag. También puedes usar comodines, como `?` (para caracteres únicos) y `*` (para varios caracteres).
+Estos campos aceptan una lista de etiquetas separadas por comas (en formato `:`), que defina un filtro, el cual se utiliza para recopilar tus recursos de EC2 o Lambda. Puedes utilizar `:`, tanto para incluir como para excluir funciones de monitorización basadas en etiquetas. Para indicar qué etiqueta debe excluirse, añade un signo `!` antes de la clave de etiqueta. También puedes utilizar comodines, como `?` (para caracteres únicos) y `*` (para varios caracteres).
-Los filtros pueden incluir recursos mediante una sentencia `OR` siempre que haya una tag de inclusión presente. El filtro del siguiente ejemplo recopila instancias EC2 que contienen la tag `datadog:monitored` o `env:production`:
+Los filtros pueden incluir recursos mediante una sentencia `OR` siempre que haya una etiqueta de inclusión presente. El filtro del siguiente ejemplo recopila instancias de EC2 que contienen la etiqueta `datadog:monitored` o `env:production`:
```text
datadog:monitored,env:production
```
-Si has definido la exclusión de una tag, esta preferencia tendrá prioridad y dará lugar a una sentencia `AND`. El filtro del siguiente ejemplo recopila instancias EC2 que contienen las tags `datadog:monitored` o `env:production`, o bien una tag `instance-type` con un valor `c1.*`, y que no contengan una tag `region:us-east-1`:
+Si has definido la exclusión de una etiqueta, esta preferencia tendrá prioridad y dará lugar a una sentencia `AND`. El filtro del siguiente ejemplo recopila instancias de EC2 que contienen las etiquetas `datadog:monitored` o `env:production`, o bien una etiqueta `instance-type` con un valor `c1.*`, y no una etiqueta `region:us-east-1`:
```text
datadog:monitored,env:production,instance-type:c1.*,!region:us-east-1
@@ -180,11 +180,11 @@ Obtén más información sobre el etiquetado de AWS en la documentación acerca
{{% /tab %}}
{{% tab "Azure" %}}
-El [cuadro de integración de Azure][1] tiene el filtro de tag `Optionally filter to VMs with tag`.
+El [cuadro de integración de Azure][1] tiene el filtro de etiqueta `Optionally filter to VMs with tag`.
-Este campo acepta una lista de tags separadas por comas (en formato `:`) que defina un filtro, el cual se usará para recopilar métricas de las máquinas virtuales de Azure. También puedes usar comodines, como `?` (para caracteres únicos) y `*` (para varios caracteres). Solo se importarán a Datadog las máquinas virtuales que coincidan con una de las tags definidas, y se ignorarán las demás.
+Este campo acepta una lista de etiquetas separadas por comas (en formato `:`), que defina un filtro, el cual se utiliza para recopilar métricas de las máquinas virtuales de Azure. También puedes utilizar comodines, como `?` (para caracteres únicos) y `*` (para varios caracteres). Solo se importarán a Datadog las máquinas virtuales que coincidan con una de las etiquetas definidas y se ignorarán las demás.
-Asimismo, se podrán excluir las máquinas virtuales que coincidan con una tag determinada siempre que se añada `!` antes de la tag. Ejemplo:
+También se podrán excluir las máquinas virtuales que coincidan con una etiqueta determinada, siempre que se añada `!` antes de la etiqueta. Por ejemplo:
```text
datadog:monitored,env:production,!env:staging,instance-type:c1.*
@@ -194,17 +194,17 @@ datadog:monitored,env:production,!env:staging,instance-type:c1.*
{{% /tab %}}
{{% tab "Google Cloud" %}}
-El [cuadro de integración de Google Cloud][1] tiene el filtro de tag `to hosts with tag`.
+El [cuadro de integración de Google Cloud][1] tiene el filtro de etiqueta `to hosts with tag`.
-Este campo acepta una lista de etiquetas (labels) de GCP separadas por comas (en formato `:`) que defina un filtro, el cual se usará para recopilar métricas de las máquinas virtuales de GCP. También puedes usar comodines, como `?` (para caracteres únicos) y `*` (para varios caracteres). Solo se importarán a Datadog los hosts que coincidan con una de las labels definidas, y se ignorarán los demás.
+Este campo acepta una lista de etiquetas (labels) de GCP separadas por comas (en formato `:`) que defina un filtro, el cual se utiliza para recopilar métricas de las máquinas virtuales de GCP. También puedes utilizar comodines, como `?` (para caracteres únicos) y `*` (para varios caracteres). Solo se importarán a Datadog los hosts que coincidan con una de las etiquetas definidas y se ignorarán los demás.
-Puedes excluir los hosts que coincidan con una label determinada siempre que añadas `!` antes de la tag. Ejemplo:
+Puedes excluir los hosts que coincidan con una etiqueta (label) determinada, siempre que añadas `!` antes de la etiqueta (tag). Ejemplo:
```text
datadog:monitored,env:production,!env:staging,instance-type:c1.*
```
-Obtén más información sobre [cómo crear y gestionar etiquetas (labels)][2] en la documentación acerca de Google Cloud.
+Obtén más información sobre [cómo crear y gestionar etiquetas (labels)][2] en la documentación de Google Cloud.
[1]: https://app.datadoghq.com/account/settings#integrations/google-cloud-platform
[2]: https://cloud.google.com/compute/docs/labeling-resources
@@ -216,18 +216,18 @@ Obtén más información sobre [cómo crear y gestionar etiquetas (labels)][2] e
{{< tabs >}}
{{% tab "Trace Explorer" %}}
-En la herramienta [Trace Explorer][1], puedes filtrar las trazas (traces) con tags usando la barra de búsqueda o las casillas de faceta. El formato de la barra de búsqueda es `:`; por ejemplo, `service:coffee-house`. Si deseas realizar una búsqueda avanzada, consulta la sección [Sintaxis de las consultas][2].
+En [Trace Explorer][1], puedes filtrar las trazas con etiquetas utilizando la barra de búsqueda o las casillas de verificación de facetas. El formato de la barra de búsqueda es `:`; por ejemplo, `service:coffee-house`. Para realizar una búsqueda avanzada, consulta la sección [Sintaxis de las consultas][2].
-{{< img src="tagging/using_tags/trace_explorer.png" alt="Tags de Trace Explorer" style="width:80%;">}}
+{{< img src="tagging/using_tags/trace_explorer.png" alt="Etiquetas del Trace Explorer" style="width:80%;">}}
[1]: /es/tracing/trace_explorer/search/
[2]: /es/tracing/trace_explorer/query_syntax/
{{% /tab %}}
{{% tab "Mapa de servicios" %}}
-Tras [asignar las tags][1], usa el mapa de servicios para dirigirte a distintas partes de la aplicación haciendo clic en un servicio concreto. En el ejemplo de abajo, puedes consultar los [análisis][2], los [monitores][3], los [logs][4] y el [mapa de hosts][5] filtrados en función de la tag `service:coffee-house`.
+Tras [asignar las etiquetas][1], utiliza el mapa de servicios para navegar a distintas partes de la aplicación haciendo clic en un servicio concreto. En el ejemplo de abajo, puedes consultar los [análisis][2], los [monitores][3], los [logs][4] y el [mapa de host][5] filtrados en función de la etiqueta `service:coffee-house`.
-{{< img src="tagging/using_tags/servicemaptags.png" alt="Tags de Mapa de servicios" style="width:80%;">}}
+{{< img src="tagging/using_tags/servicemaptags.png" alt="Etiquetas de mapa de servicios" style="width:80%;">}}
[1]: /es/getting_started/tagging/assigning_tags/
[2]: /es/tracing/app_analytics/search/
@@ -240,75 +240,75 @@ Tras [asignar las tags][1], usa el mapa de servicios para dirigirte a distintas
## Notebooks
-Cuando crees un gráfico del [notebook][9], usa tags en el campo de texto **from** para limitar las métricas. Úsalas también en el campo de texto **avg by** para agrupar las métricas. En el ejemplo de abajo, las métricas están limitadas por `service:coffee-house` y agrupadas por `host`.
+Al crear un gráfico del [notebook][9], utiliza etiquetas en el campo de texto **from** (from) para limitar las métricas. Utilízalas también en el campo de texto **avg by** para agrupar las métricas. En el ejemplo de abajo, las métricas están limitadas por `service:coffee-house` y agrupadas por `host`.
-{{< img src="tagging/using_tags/notebooktags.png" alt="Tags de Notebook" style="width:80%;">}}
+{{< img src="tagging/using_tags/notebooktags.png" alt="Etiquetas de notebooks" style="width:80%;">}}
-Si quieres excluir tags, edita el texto con `` y, a continuación, añade la tag en cuestión en formato `!:`. En el ejemplo de abajo, se usa `!service:coffeehouse` para excluir `service:coffeehouse`.
+Si quieres excluir etiquetas, edita el texto con `` y, a continuación, añade la etiqueta en cuestión en formato `!:`. En el ejemplo de abajo, se utiliza `!service:coffeehouse` para excluir `service:coffeehouse`.
-{{< img src="tagging/using_tags/notebooktagsexclude.mp4" alt="Tags para excluir de notebook" video="true" width="80%">}}
+{{< img src="tagging/using_tags/notebooktagsexclude.mp4" alt="Etiquetas para excluir de notebooks" video="true" width="80%">}}
## Logs
-En los apartados de [búsqueda (Search)][10], [análisis (Analytics)][11], [patrones (Patterns)][12] y [Live Tail][13] de los logs, filtra las trazas (traces) con tags usando la barra de búsqueda o las casillas de facetas. El formato de la barra de búsqueda es `:`; por ejemplo, `service:coffee-house`. Si deseas realizar una búsqueda avanzada, consulta la página de [Buscar logs][10].
+Para la [búsqueda (Search)][10], el [análisis (Analytics)][11], los [patrones (Patterns)][12] y [Live Tail][13] de los logs, filtra las trazas con etiquetas utilizando la barra de búsqueda o las casillas de verificación de facetas. El formato de la barra de búsqueda es `:`; por ejemplo, `service:coffee-house`. Para realizar una búsqueda avanzada, consulta la página [Buscar logs][10].
{{< tabs >}}
{{% tab "Búsqueda" %}}
-{{< img src="tagging/using_tags/logsearchtags.png" alt="Tags de Log Search" style="width:80%;">}}
+{{< img src="tagging/using_tags/logsearchtags.png" alt="Etiquetas de búsqueda de logs" style="width:80%;">}}
{{% /tab %}}
{{% tab "Análisis" %}}
-{{< img src="tagging/using_tags/loganalyticstags.png" alt="Tags de Log Analytics" style="width:80%;">}}
+{{< img src="tagging/using_tags/loganalyticstags.png" alt="Etiquetas de análisis de logs" style="width:80%;">}}
{{% /tab %}}
{{% tab "Patrones" %}}
-{{< img src="tagging/using_tags/logpatternstags.png" alt="Tags de Log Patterns" style="width:80%;">}}
+{{< img src="tagging/using_tags/logpatternstags.png" alt="Etiquetas de patrones de logs" style="width:80%;">}}
{{% /tab %}}
{{% tab "Live Tail" %}}
-{{< img src="tagging/using_tags/livetailtags.mp4" alt="Tags de Live Tail" video="true" width="80%">}}
+{{< img src="tagging/using_tags/livetailtags.mp4" alt="Etiquetas de Live Tail" video="true" width="80%">}}
{{% /tab %}}
{{< /tabs >}}
-Las tags también se pueden usar para filtrar un [pipeline][14] de registros. En el ejemplo de abajo, el pipeline filtra los registros en función de la tag `service:coffee-house`.
+Las etiquetas también se pueden utilizar para filtrar un [pipeline][14] de logs. En el ejemplo de abajo, el pipeline filtra los logs en función de la etiqueta `service:coffee-house`.
-{{< img src="tagging/using_tags/logpipelinetags.png" alt="Tags de Pipeline" style="width:80%;">}}
+{{< img src="tagging/using_tags/logpipelinetags.png" alt="Etiquetas de pipeline" style="width:80%;">}}
## RUM y Session Replay
-El [navegador RUM][15] muestra los eventos de tu entorno que tienen lugar durante un determinado período de tiempo.
+El [navegador RUM][15] muestra los eventos de tu entorno que tienen lugar durante un determinado periodo de tiempo.
-Para filtrar los datos de los eventos de RUM por tags, usa la barra de búsqueda o las casillas de facetas. El formato de la barra de búsqueda es `:`; por ejemplo, `service:shopist`. Si deseas realizar una búsqueda avanzada, consulta la sección [Buscar eventos de RUM][16].
+Para filtrar los datos de los eventos de RUM por etiquetas, utiliza la barra de búsqueda o las casillas de verificación de facetas. El formato de la barra de búsqueda es `:`; por ejemplo, `service:shopist`. Para realizar una búsqueda avanzada, consulta la sección [Buscar eventos de RUM][16].
-{{< img src="tagging/using_tags/rumtags.png" alt="Tags de RUM" style="width:80%;">}}
+{{< img src="tagging/using_tags/rumtags.png" alt="Etiquetas de RUM" style="width:80%;">}}
## Synthetics
{{< tabs >}}
-{{% tab "Tests Synthetic" %}}
+{{% tab "Pruebas de Synthetic" %}}
-Tus tests Synthetic pueden verse en la página de [Tests Synthetic][1].
+Puedes ver tus pruebas de Synthetic en la página [Pruebas de Synthetic][1].
-Para filtrar los tests por tags, usa la barra de búsqueda o las casillas de facetas. El formato de la barra de búsqueda es `:`; por ejemplo, `tag:mini-website`. Si deseas realizar una búsqueda avanzada, consulta la sección [Buscar y gestionar tests de Synthetic][2].
+Para filtrar las pruebas por etiquetas, utiliza la barra de búsqueda o las casillas de verificación de facetas. El formato de la barra de búsqueda es `:`; por ejemplo, `tag:mini-website`. Para realizar una búsqueda avanzada, consulta la sección [Buscar y gestionar pruebas de Synthetic][2].
-{{< img src="tagging/using_tags/syntheticstags.png" alt="Tags de Synthetics" style="width:80%;">}}
+{{< img src="tagging/using_tags/syntheticstags.png" alt="Etiquetas de Synthetics" style="width:80%;">}}
[1]: https://app.datadoghq.com/synthetics/tests
[2]: /es/synthetics/search/
{{% /tab %}}
-{{% tab "Explorer" %}}
+{{% tab "Explorador" %}}
-El [explorador de monitorización y prueba continua de Synthetic][1] muestra tus ejecuciones y lotes de ejecuciones de tests en un [pipeline CI][2].
+El [explorador de monitorización y prueba continua de Synthetic][1] muestra tus ejecuciones y lotes de ejecuciones de pruebas en un [pipeline CI][2].
-Para filtrar los tests por etiquetas (tags), utiliza la barra de búsqueda o las casillas de verificación de faceta. El formato de la barra de búsqueda es `:`. Por ejemplo: `@ci.provider.name:github`. Para realizar búsquedas avanzadas, consulta [Buscar Lotes de pruebas de búsqueda][3].
+Para filtrar las pruebas por etiquetas, utiliza la barra de búsqueda o las casillas de verificación de facetas. El formato de la barra de búsqueda es `:`; por ejemplo: `@ci.provider.name:github`. Para realizar una búsqueda avanzada, consulta [Buscar lotes de pruebas][3].
-{{< img src="tagging/using_tags/syntheticscitags.png" alt="Tags de Synthetics y CI" style="width:80%;">}}
+{{< img src="tagging/using_tags/syntheticscitags.png" alt="Etiquetas de Synthetics y CI" style="width:80%;">}}
[1]: https://app.datadoghq.com/synthetics/explorer/
@@ -322,57 +322,55 @@ Para filtrar los tests por etiquetas (tags), utiliza la barra de búsqueda o las
{{< tabs >}}
{{% tab "Gestionar SLOs" %}}
-Para filtrar los SLOs según sus [tags asignadas][1], puedes usar la barra de búsqueda o las casillas de facetas. El formato de la barra de búsqueda es `:`; por ejemplo, `journey:add_item`. Si deseas excluir de tu búsqueda los SLOs que tengan una tag en concreto, usa `-`, for example: `-journey:add_item`.
+Para filtrar los SLOs según sus [etiquetasasignadas][1], puedes utilizar la barra de búsqueda o las casillas de verificación de facetas. El formato de la barra de búsqueda es `:`; por ejemplo, `journey:add_item`. Para excluir de tu búsqueda los SLOs que tengan una etiqueta específica, utiliza `-`, for example: `-journey:add_item`.
-{{< img src="tagging/using_tags/manage_slo_tags.png" alt="Tags de SLO" style="width:80%;">}}
+{{< img src="tagging/using_tags/manage_slo_tags.png" alt="Etiquetas de SLOs" style="width:80%;">}}
-Las tags de SLO son diferentes e independientes de las tags de métrica y monitor que se emplean en las métricas o monitores subyacentes de un SLO.
+Las etiquetas de SLOs son diferentes e independientes de las etiquetas de métricas y monitores que se emplean en las métricas o monitores subyacentes de un SLO.
[1]: /es/getting_started/tagging/assigning_tags/?tab=servicelevelobjectives#ui
{{% /tab %}}
{{% tab "SLOs basados en métricas" %}}
-Cuando crees un [SLO basado en métricas][1], usa las tags de métrica en las consultas de métrica sobre el porcentaje de éxito del SLO (todas las métricas deben usar el mismo conjunto de tags de métrica):
+Al crear un [SLO basado en métricas][1], utiliza las etiquetas de métricas en las consultas de métricas sobre el porcentaje de éxito del SLO (todas las métricas deben utilizar el mismo conjunto de etiquetas de métricas):
-* en el campo de texto **from** para limitar el contexto de la métrica solo a esas tags.
-* en el campo de texto **sum by** para crear un SLO basado en métricas y agrupado para mostrar un porcentaje de estado, así como el presupuesto restante para subsanar errores del SLO general y de cada valor de tag.
-
-{{< img src="tagging/using_tags/metric_based_slo_tags.png" alt="Tags del SLO basado en métricas" style="width:80%;">}}
+* el campo de texto **from** (desde), para limitar el contexto de la métrica solo a esas etiquetas.
+* el campo de texto **sum by** (sumar por), para crear un SLO basado en métricas y agrupado para mostrar un porcentaje de estado, así como el presupuesto restante para subsanar errores del SLO general y de cada valor de etiqueta.
[1]: /es/service_management/service_level_objectives/metric/
{{% /tab %}}
{{% tab "SLOs basados en monitores" %}}
-Cuando crees un [SLO basado en monitores][1] con un solo [monitor agrupado][2], usa la opción **Calculate on selected groups** (Calcular según los grupos seleccionados) para seleccionar hasta 20 valores de tag de monitores subyacentes. De este modo, será posible mostrar un porcentaje de estado, así como el presupuesto restante para subsanar errores del SLO general y de cada valor de tag:
+Al crear un [SLO basado en monitores][1] con un solo [monitor agrupado][2], utiliza la opción **Calculate on selected groups** (Calcular según los grupos seleccionados) para seleccionar hasta 20 valores de etiquetas de monitores subyacentes y mostrar un porcentaje de estado, así como el presupuesto restante para subsanar errores del SLO general y de cada valor de etiqueta:
-{{< img src="tagging/using_tags/monitor_based_slo_tags.png" alt="Tags del SLO basado en monitores" style="width:80%;">}}
+{{< img src="tagging/using_tags/monitor_based_slo_tags.png" alt="Etiquetas de SLO basadas en monitores" style="width:80%;">}}
[1]: /es/service_management/service_level_objectives/monitor/
[2]: /es/getting_started/tagging/using_tags/?tab=newmonitor#monitors
{{% /tab %}}
{{< /tabs >}}
-## Monitorización de bases de datos
+## CI Visibility
{{< tabs >}}
-{{% tab "Test Runs" %}}
+{{% tab "Ejecuciones de pruebas" %}}
-El [explorador de Visibilidad CI][101] muestra tus pruebas ejecutados en un pipeline CI.
+El [explorador de visibilidad CI][101] muestra tus pruebas ejecutadas en un pipeline CI.
-Para filtrar las pruebas por etiquetas (tags), utiliza la barra de búsqueda o las casillas de verificación de faceta. El formato de la barra de búsqueda es `:`. Por ejemplo: `@test.status:failed`. Para realizar búsquedas avanzadas, consulta [Buscar y gestionar tests de CI][102].
+Para filtrar las pruebas por etiquetas, utiliza la barra de búsqueda o las casillas de verificación de facetas. El formato de la barra de búsqueda es `:`; por ejemplo: `@test.status:failed`. Para realizar una búsqueda avanzada, consulta [Buscar y gestionar pruebas de CI][102].
-{{< img src="/continuous_integration/test_runs.png" alt="Ejecuta tests en el explorador de visibilidad de CI" style="width:80%;">}}
+{{< img src="/continuous_integration/test_runs.png" alt="Ejecuta pruebas en el explorador de visibilidad CI" style="width:80%;">}}
[101]: https://app.datadoghq.com/ci/test-runs
[102]: /es/tests/search/
{{% /tab %}}
-{{% tab "Pipeline Executions" %}}
+{{% tab "Ejecuciones de pipelines" %}}
El [explorador de visibilidad CI][101] muestra las ejecuciones de tu pipeline CI.
-Para filtrar las ejecuciones de pipeline por etiquetas (tags), utiliza la barra de búsqueda o las casillas de verificación de faceta. El formato de la barra de búsqueda es `:`. Por ejemplo: `@ci.provider.name:gitlab`. Para realizar búsquedas avanzadas, consulta [Busca y gestiona pipelines CI][102].
+Para filtrar las ejecuciones de pipeline por etiquetas, utiliza la barra de búsqueda o las casillas de verificación de facetas. El formato de la barra de búsqueda es `:`; por ejemplo: `@ci.provider.name:gitlab`. Para realizar una búsqueda avanzada, consulta [Buscar y gestionar pipelines CI][102].
{{< img src="/continuous_integration/pipeline_executions.png" alt="Ejecuciones de pipelines en el explorador de visibilidad CI" style="width:80%;">}}
@@ -382,30 +380,30 @@ Para filtrar las ejecuciones de pipeline por etiquetas (tags), utiliza la barra
{{% /tab %}}
{{< /tabs >}}
-## Guías
+## Desarrolladores
-Las tags pueden usarse de diferentes formas con la [API][17].
+Las etiquetas pueden utilizarse de diferentes formas con la [API][17].
Consulta esta lista para encontrar los enlaces a cada una de las siguientes secciones:
-* [Programar la caída del sistema de un monitor][18]
+* [Programar el tiempo de inactividad de un monitor][18]
* [Realizar consultas en el navegador de eventos][19]
* [Buscar hosts][20]
-* Integraciones de [AWS][21] y [Google Cloud][22]
-* [Realizar consultas en los puntos de las cronologías][23]
+* Integraciones para [AWS][21] y [Google Cloud][22]
+* [Realizar consultas en puntos de las series temporales][23]
* [Obtener todos los detalles de un monitor][24]
* [Silenciar un monitor][25]
* [Búsqueda de monitores][24]
-* [Búsqueda de un grupo de monitores][24]
+* [Búsqueda de grupos de monitores][24]
* [Crear un screenboard][26]
* [Crear un timeboard][26]
* [Crear un SLO][27]
* [Obtener los detalles de un SLO][28]
* [Actualizar un SLO][29]
-## Leer más
+## Lectura adicional
-{{< partial name="whats-next/whats-next.html" >}}
+{{< nombre parcial="whats-next/whats-next.html" >}}
[1]: /es/getting_started/tagging/assigning_tags/
[2]: /es/service_management/events/explorer
diff --git a/content/fr/logs/log_configuration/_index.md b/content/fr/logs/log_configuration/_index.md
index 96526f320280d..57601e57da228 100644
--- a/content/fr/logs/log_configuration/_index.md
+++ b/content/fr/logs/log_configuration/_index.md
@@ -3,35 +3,43 @@ aliases:
- /fr/logs/processing
description: Traiter, enrichir, contrôler et gérer vos logs depuis la page Logs Configuration
further_reading:
+- link: /data_security/pci_compliance/
+ tag: Documentation
+ text: Configurer une organisation Datadog conforme à la norme PCI
- link: https://www.datadoghq.com/blog/logging-without-limits/
tag: Blog
text: En savoir plus sur Logging without Limits*
+- link: https://www.datadoghq.com/blog/log-pipeline-scanner-datadog/
+ tag: Blog
+ text: Explorer le traitement de vos logs grâce au scanner de pipeline de logs Datadog
- link: /logs/guide/
tag: Guide
text: Guides supplémentaires sur la journalisation avec Datadog
kind: Documentation
-title: Log Configuration
+title: Configuration des logs
---
## Présentation
La solution Logging without Limits* de Datadog dissocie l'ingestion des logs de leur indexation. Elle vous permet de choisir les logs que vous souhaitez indexer et conserver, ou archiver, et de gérer les paramètres et contrôles de façon globale depuis la page de configuration des logs, accessible depuis [**Logs > Configuration**][1].
+**Remarque** : consultez la section [Conformité PCI DSS][2] pour obtenir des informations sur la mise en place d'une organisation Datadog conforme à la norme PCI.
+
{{< img src="logs/log_configuration_overview1.mp4" alt="La section de configuration des logs dans l'application Datadog" video=true >}}
## Options de configuration
-- Contrôlez le traitement de vos logs avec des [pipelines][2] et des [processeurs][3].
-- Définissez [des attributs et des alias][4] pour unifier votre environnement de logs.
-- [Générez des métriques à partir des logs ingérés][5] afin de synthétiser à moindre coût les données des logs d'un flux entier ingéré.
-- Contrôlez de façon extrêmement précise votre budget de gestion des logs grâce aux [index de logs][6].
-- Transférez vos logs ingérés vers votre propre compartiment de stockage dans le cloud pour conserver une [archive][7], afin d'anticiper de futurs dépannages ou audits.
-- [Réintégrez une archive][8] afin d'analyser ou d'étudier des événements de log anciens ou exclus de l'indexation.
-- Restreignez l'[accès aux données des logs][9] grâce à des requêtes de restriction.
+- Contrôlez le traitement de vos logs avec des [pipelines][3] et des [processeurs][4].
+- Définissez [des attributs et des alias][5] pour unifier votre environnement de logs.
+- [Générez des métriques à partir des logs ingérés][6] afin de synthétiser à moindre coût les données des logs d'un flux entier ingéré.
+- Contrôlez de façon extrêmement précise votre budget de gestion des logs grâce aux [index de logs][7].
+- Transférez vos logs ingérés vers votre propre compartiment de stockage dans le cloud pour conserver une [archive][8], afin d'anticiper de futurs dépannages ou audits.
+- [Réintégrez une archive][9] afin d'analyser ou d'étudier des événements de log anciens ou exclus de l'indexation.
+- Restreignez l'[accès aux données des logs][10] grâce à des requêtes de restriction.
-## Log Explorer
+## LogxmExplorer
-Une fois votre configuration terminée, commencez à examiner et à étudier vos logs dans le [Log Explorer][10].
+Une fois votre configuration terminée, commencez à examiner et à étudier vos logs dans le [Log Explorer][11].
## Pour aller plus loin
@@ -41,12 +49,13 @@ Une fois votre configuration terminée, commencez à examiner et à étudier vos
*Logging without Limits est une marque déposée de Datadog, Inc.
[1]: https://app.datadoghq.com/logs/pipelines
-[2]: /fr/logs/log_configuration/pipelines
-[3]: /fr/logs/log_configuration/processors
-[4]: /fr/logs/log_configuration/attributes_naming_convention/
-[5]: /fr/logs/log_configuration/logs_to_metrics/
-[6]: /fr/logs/log_configuration/indexes
-[7]: /fr/logs/log_configuration/archives/
-[8]: /fr/logs/log_configuration/rehydrating
-[9]: /fr/logs/guide/logs-rbac/
-[10]: /fr/logs/explorer/
\ No newline at end of file
+[2]: /fr/data_security/pci_compliance/
+[3]: /fr/logs/log_configuration/pipelines
+[4]: /fr/logs/log_configuration/processors
+[5]: /fr/logs/log_configuration/attributes_naming_convention/
+[6]: /fr/logs/log_configuration/logs_to_metrics/
+[7]: /fr/logs/log_configuration/indexes
+[8]: /fr/logs/log_configuration/archives/
+[9]: /fr/logs/log_configuration/rehydrating
+[10]: /fr/logs/guide/logs-rbac/
+[11]: /fr/logs/explorer/
\ No newline at end of file
diff --git a/content/fr/observability_pipelines/architecture/capacity_planning_scaling.md b/content/fr/observability_pipelines/architecture/capacity_planning_scaling.md
deleted file mode 100644
index ca54890367881..0000000000000
--- a/content/fr/observability_pipelines/architecture/capacity_planning_scaling.md
+++ /dev/null
@@ -1,100 +0,0 @@
----
-kind: Documentation
-title: Planification et dimensionnement des capacités
----
-
-{{< site-region region="gov" >}}
-
Les pipelines d'observabilité ne sont pas disponibles pour le site Datadog US1-FED.
-{{< /site-region >}}
-
-
-Ce guide concerne les déploiements de production à grande échelle.
-
-
-## Unités d'estimation
-
-Les unités suivantes servent de points de départ pour estimer la capacité de vos ressources, mais elles peuvent varier en fonction de votre workload.
-
-| Unité | Taille | Débit du worker de pipelines d'observabilité*|
-| ----------------------| --------- | ----------------------------------------- |
-| Événement de log non structuré| ~512 octets| ~10 MiB/s/vCPU |
-| Événement de log structuré | ~1,5 Ko | ~25 MiB/s/vCPU |
-| Événement de métrique | ~256 octets| ~25 MiB/s/vCPU |
-| Événement de span de trace | ~1,5 Ko | ~25 MiB/s/vCPU |
-
-* Ces chiffres constituent une évaluation prudente. 1 vCPU = 1 CPU physique ARM et un demi CPU physique Intel.
-
-## Dimensionnement
-
-### Dimensionnement horizontal
-
-Le dimensionnement horizontal désigne la distribution du trafic sur plusieurs instances du worker de pipelines d'observabilité. Ce dernier possède une architecture « shared-nothing » (au sein de laquelle aucune ressource n'est partagée) et ne nécessite aucun nœud leader ni aucune coordination similaire qui pourraient compliquer le dimensionnement.
-
-Pour les sources basées sur une méthode push, placez un répartiteur de charge réseau en amont de vos instances du worker de pipelines d'observabilité et dimensionnez-les en fonction des besoins.
-
-{{< img src="observability_pipelines/production_deployment_overview/horizontal_scaling_push.png" alt="Un diagramme affichant une région cloud décomposées en agents, en répartiteurs de charge réseau et en un agrégateur du worker de pipelines d'observabilité. Les données des agents sont envoyées au répartiteur de charge, aux workers de pipelines d'observabilité, puis vers d'autres destinations" style="width:60%;" >}}
-
-Le répartiteur de charge n'est pas requis pour les sources basées sur une méthode pull. Déployez le worker de pipelines d'observabilité et dimensionnez-le en fonction des besoins. Votre système de publication/abonnement coordonne l'accès exclusif aux données lorsque le worker de pipelines d'observabilité demande à les consulter.
-
-{{< img src="observability_pipelines/production_deployment_overview/horizontal_scaling_push.png" alt="Un diagramme affichant une région cloud décomposées en agents, en brokers et en un agrégateur de pipelines d'observabilité. Les données des agents sont envoyées aux brokers, puis envoyées et reçues entre le broker et les workers de pipelines d'observabilité, avant d'être envoyées depuis les workers vers d'autres destinations" style="width:60%;" >}}
-
-Consultez les [configurations avancées][1] pour en savoir plus sur les workloads mixtes (sources basées sur une méthode push et pull).
-
-#### Équilibrage des charges
-
-Un répartiteur de charge est requis uniquement pour les sources basées sur une méthode push, telles que les agents. Vous n'avez pas besoin d'un répartiteur de charge si vous utilisez exclusivement des sources basées sur une méthode pull, telles que Kafka.
-
-##### Équilibrage des charges côté client
-
-L'équilibrage des charges côté client n'est pas recommandé. Ce sont alors les clients qui procèdent à l'équilibrage des charges du trafic sur plusieurs instances du worker de pipelines d'observabilité. Si cette approche semble plus simple, elle peut s'avérer moins fiable et plus complexe pour les raisons suivantes :
-
-- Parvenir à équilibrer les charges avec un failover adéquat est une opération complexe. Les problèmes rencontrés dans ce cas de figure sont délicats, car ils peuvent entraîner une perte de données ou des incidents qui interrompent vos services. Le risque est encore plus grand si vous travaillez avec plusieurs types de clients.
-- L'objectif de l'agrégateur du worker de pipelines d'observabilité consiste à délester vos agents de toute responsabilité, et cela passe notamment par la prise en charge de l'équilibrage des charges.
-
-##### Types de répartiteurs de charge
-
-Datadog recommande l'utilisation de répartiteurs de charge de type L4 (layer 4, ou répartiteurs de charge réseau) étant donné qu'ils prennent en charge les protocoles du worker de pipelines d'observabilité (TCP, UDP et HTTP). Même si vous envoyez exclusivement du trafic HTTP (L7), Datadog recommande les répartiteurs de charge L4 en raison de leurs bonnes performances et de leur simplicité.
-
-| Fournisseur de cloud| Recommandation |
-| ------------- | --------------------------------------------------------------|
-| AWS | Répartiteur de charge réseau AWS (NLB, pour Network Load Balancer) |
-| Azure | Répartiteur de charge interne Azure |
-| Google Cloud | Répartiteur de charge réseau interne TCP/UDP |
-| Private | HAProxy, Nginx ou un autre répartiteur de charge prenant en charge les données layer 4 |
-
-##### Configurations du répartiteur de charge
-
-Lors de la configuration des clients et des répartiteurs de charge, Datadog recommande les paramètres généraux suivants :
-
-- Utilisez une stratégie de répartiteur de charge de type round-robin.
-- N'activez pas la fonctionnalité d'équilibrage de charge entre zones, sauf en cas de déséquilibre du trafic entre plusieurs zones.
-- Configurez les répartiteurs de charge de sorte qu'ils utilisent l'endpoint de l'API de santé du worker de pipelines d'observabilité pour la santé cible.
-- Assurez-vous que les instances de votre worker de pipelines d'observabilité sont enregistrées ou désenregistrées automatiquement lors de leur dimensionnement. Consultez la section [Réseau][2] pour en savoir plus.
-- Appliquez un intervalle de conservation avec un délai d'inactivité d'une minute maximum pour vos clients et répartiteurs de charge.
-- Activez la simultanéité et la mise en pool des connexions sur vos agents si ces fonctionnalités sont prises en charge. Si elles ne sont pas prises en charge, envisagez d'utiliser l'architecture unifiée qui déploie le worker de pipelines d'observabilité en périphérie. La mise en pool des connexions permet de garantir la répartition de grandes quantités de données sur plusieurs connexions pour mieux équilibrer le trafic.
-
-##### Zones sensibles du répartiteur de charge
-
-Des zones sensibles peuvent apparaître sur le répartiteur de charge lorsqu'une ou plusieurs instances du worker de pipelines d'observabilité reçoivent une quantité de trafic disproportionnée. Ce problème peut généralement survenir pour deux raisons différentes :
-
-1. Une grande quantité de trafic est envoyée sur une seule connexion.
-2. Le trafic présent dans une zone de disponibilité est beaucoup plus élevé que dans les autres zones de disponibilité.
-
-Dans ces cas de figure, nous vous recommandons de mettre en œuvre les stratégies respectives suivantes pour atténuer ces zones sensibles :
-
-1. Divisez les connexions volumineuses en plusieurs connexions de plus petite taille. La plupart des clients prennent en charge la simultanéité ainsi que la mise en pool des connexions, qui permettent la répartition des données sur plusieurs connexions. En procédant de la sorte, votre répartiteur de charge est capable de répartir la connexion sur plusieurs instances du worker de pipelines d'observabilité. Si votre client ne prend pas en charge ces fonctionnalités, nous vous conseillons d'utiliser l'architecture unifiée, qui permet le déploiement du worker de pipelines d'observabilité en périphérie.
-2. Activez la fonctionnalité d'équilibrage de charge entre zones sur votre répartiteur de charge. Cette fonctionnalité répartit la totalité du trafic des zones de disponibilité de manière équitable sur l'ensemble des instances du worker de pipelines d'observabilité.
-
-### Dimensionnement vertical
-
-Le modèle de simultanéité du worker de pipelines d'observabilité s'adapte automatiquement pour tirer parti de tous les vCPU. Il n'est pas nécessaire d'ajuster les paramètres de simultanéité ni de modifier la configuration. En cas de dimensionnement vertical, Datadog recommande d'appliquer une limite de taille à une instance de sorte qu'elle ne traite pas plus de la moitié du volume total, et de disposer d'au moins deux instances du worker de pipelines d'observabilité pour garantir une haute disponibilité.
-
-### Autoscaling
-
-L'autoscaling dépend de l'utilisation moyenne du CPU. Pour la plupart des workloads, le worker de pipelines d'observabilité est limité par le CPU. L'activation ou non de l'autoscaling est déterminée avant tout par l'utilisation du CPU, car elle ne produit aucun faux positif. Datadog recommande d'utiliser les paramètres suivants, en les ajustant au besoin :
-
-- CPU moyen avec un objectif d'utilisation de 85 %.
-- Une période de stabilisation de cinq minutes pour le dimensionnement.
-
-[1]: /fr/observability_pipelines/architecture/advanced_configurations
-[2]: /fr/observability_pipelines/architecture/networking
\ No newline at end of file
diff --git a/content/fr/observability_pipelines/guide/_index.md b/content/fr/observability_pipelines/guide/_index.md
deleted file mode 100644
index 195e46c0bb17c..0000000000000
--- a/content/fr/observability_pipelines/guide/_index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-disable_toc: true
-kind: guide
-private: true
-title: Guides sur les pipelines d'observabilité
----
-
-{{< whatsnext desc="Guides généraux :" >}}
- {{< nextlink href="/observability_pipelines/guide/custom-metrics-governance" >}}Gouvernance des métriques custom{{< /nextlink >}}
- {{< nextlink href="/observability_pipelines/guide/control_log_volume_and_size" >}}Contrôler le volume et la taille des logs{{< /nextlink >}}
-{{< /whatsnext >}}
\ No newline at end of file
diff --git a/content/fr/observability_pipelines/guide/control_log_volume_and_size.md b/content/fr/observability_pipelines/guide/control_log_volume_and_size.md
deleted file mode 100644
index 5997fc85de0ee..0000000000000
--- a/content/fr/observability_pipelines/guide/control_log_volume_and_size.md
+++ /dev/null
@@ -1,505 +0,0 @@
----
-aliases:
-- /fr/integrations/observability_pipelines/guide/control_log_volume_and_size/
-further_reading:
-- link: /observability_pipelines/working_with_data/
- tag: Documentation
- text: Transformer des données avec Vector
-- link: /observability_pipelines/vector_configurations/
- tag: Documentation
- text: En savoir plus sur les configurations Vector
-kind: guide
-title: Contrôler le volume et la taille des logs
----
-
-## Présentation
-
-Avec le développement de votre organisation, vos logs deviennent de plus en plus volumineux. Cela a pour effet d'accroître les coûts d'ingestion et d'indexation liés à vos services en aval, comme les solutions de gestion de logs, de SIEM, etc. Ce guide vous explique comment utiliser les transformations Vector pour réduire le volume et la taille de vos logs, afin de contrôler vos coûts *avant* que vos données ne quittent votre infrastructure ou réseau.
-
-## Prérequis
-- Vous avez [installé et configuré Vector][1] de façon à recueillir des données à partir de vos sources et à les acheminer vers vos destinations.
-- Vous maîtrisez la [configuration de base de Vector][2].
-
-## Utiliser les transformations pour gérer le volume des logs
-
-Au sein des pipelines d'observabilité, les **transformations** effectuent des opérations afin de modifier des événements, à savoir des logs, métriques ou traces passant par les pipelines.
-
-### Dédoubler des événements
-
-Utilisez la [transformation dedupe][3] pour supprimer les données en double passant par votre pipeline. Ajoutez le composant suivant à votre configuration pour appliquer la transformation.
-
-{{< tabs >}}
-{{% tab "YAML" %}}
-
-```yaml
-transforms:
- my_transform_id:
- type: dedupe
- inputs:
- - my-source-or-transform-id
- cache: null
- fields: null
-```
-
-{{% /tab %}}
-{{% tab "TOML" %}}
-
-```toml
-[transforms.my_transform_id]
-type = "dedupe"
-inputs = [ "my-source-or-transform-id" ]
-```
-
-{{% /tab %}}
-{{% tab "JSON" %}}
-
-```json
-{
- "transforms": {
- "my_transform_id": {
- "type": "dedupe",
- "inputs": [
- "my-source-or-transform-id"
- ],
- "cache": null,
- "fields": null
- }
- }
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-Vector attribue à chaque événement un identifiant unique permettant de suivre les événements dédupliqués. Grâce à l'option `cache`, vous pouvez mettre en cache les événements récents afin de vérifier ultérieurement si des données ont été dupliquées. Par défaut, le cache contient 5 000 événements. L'option `fields` répertorie les champs utilisés pour déterminer si un événement est un doublon.
-
-### Filtrer des événements
-
-Utilisez la [transformation filter][4] pour autoriser uniquement certains logs répondant à des critères spécifiques à passer par un composant de votre pipeline. Ces critères vous permettent par exemple d'accepter uniquement les logs qui contiennent :
-
-- un tag spécifique, par exemple `env` ;
-- une valeur de champ spécifique, par exemple `400` pour le champ `status`.
-
-Pour filtrer vos logs, insérez un composant contenant une [transformation filter][4] qui repose sur la syntaxe [Vector Remap Language (VRL)][5] ou sur la [syntaxe de recherche de logs Datadog][6] afin de définir vos conditions. Les logs qui ne répondent pas aux conditions sont ignorés.
-
-L'exemple suivant repose sur la transformation filter et sur VRL pour transmettre uniquement les logs dont le `status` est `500`.
-
-{{< tabs >}}
-{{% tab "YAML" %}}
-
-```yaml
-transforms:
- my_transform_id:
- type: filter
- inputs:
- - my-source-or-transform-id
- condition:
- type: "vrl"
- source: ".status == 500"
-```
-
-{{% /tab %}}
-{{% tab "TOML" %}}
-
-```toml
-[transforms.my_transform_id]
-type = "filter"
-inputs = [ "my-source-or-transform-id" ]
-
- [transforms.my_transform_id.condition]
- type = "vrl"
- source = ".status == 500"
-```
-
-{{% /tab %}}
-{{% tab "JSON" %}}
-
-```json
-{
- "transforms": {
- "my_transform_id": {
- "type": "filter",
- "inputs": [
- "my-source-or-transform-id"
- ],
- "condition": {
- "type": "vrl",
- "source": ".status == 500"
- }
- }
- }
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-### Échantillonner des logs
-
-Lorsque vous analysez des volumes importants de données comportant de nombreuses valeurs parasites (par exemple, des logs CDN), il est inutile de transmettre l'ensemble des logs à une destination. Utilisez plutôt la [transformation sample][7] afin d'envoyer uniquement les logs dont vous avez besoin. Vos analyses sont ainsi plus pertinentes d'un point de vue statistique.
-
-Le champ `exclude` permet d'empêcher l'échantillonnage de certains événements. Il prend en charge la syntaxe VRL ainsi que la syntaxe de recherche de logs Datadog. L'exemple de configuration ci-dessous échantillonne chaque lot de 10 événements. Le nombre d'événements est déterminé par l'option `rate`.
-
-{{< tabs >}}
-{{% tab "YAML" %}}
-
-```yaml
-transforms:
- my_transform_id:
- type: sample
- inputs:
- - my-source-or-transform-id
- exclude:
- type: "datadog_search"
- source: "*stack"
- rate: 10
-```
-
-{{% /tab %}}
-{{% tab "TOML" %}}
-
-```toml
-[transforms.my_transform_id]
-type = "sample"
-inputs = [ "my-source-or-transform-id" ]
-rate = 10
-
- [transforms.my_transform_id.exclude]
- type = "datadog_search"
- source = "*stack"
-```
-
-{{% /tab %}}
-{{% tab "JSON" %}}
-
-```json
-{
- "transforms": {
- "my_transform_id": {
- "type": "sample",
- "inputs": [
- "my-source-or-transform-id"
- ],
- "exclude": {
- "type": "datadog_search",
- "source": "*stack"
- },
- "rate": 10
- }
- }
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-### Convertir des logs en métriques
-
-Pour mieux comprendre l'évolution d'une certaine tendance, il est plus intéressant d'étudier les métriques associées aux points de données d'un événement plutôt qu'une série de logs. Utilisez la [transformation log to metric][8] pour réduire le volume de logs passant par votre pipeline en générant des métriques basées sur des tags spécifiques.
-
-Vous pouvez générer quatre types de métriques différents :
-
-- Des métriques counter, qui permettent de compter le nombre de logs contenant un tag spécifique. Vous pouvez incrémenter un compte ou le réinitialiser.
-- Des métriques de distribution, qui représentent la distribution des valeurs échantillonnées. Ces métriques sont particulièrement utiles pour créer des synthèses et des histogrammes.
-- Des métriques gauge, qui représentent une seule valeur numérique qui augmente ou diminue de façon arbitraire. Ces métriques vous permettent de surveiller des valeurs qui évoluent constamment.
-- Des métriques set, qui rassemblent des valeurs uniques au sein d'un tableau. Ces métriques servent par exemple à recueillir des adresses IP uniques.
-
-L'exemple de configuration suivant permet de générer une métrique `counter`. L'option `metrics` définit les paires key/value ajoutées à l'événement.
-
-{{< tabs >}}
-{{% tab "YAML" %}}
-
-```yaml
-transforms:
- my_transform_id:
- type: log_to_metric
- inputs:
- - my-source-or-transform-id
- metrics:
- - type: counter
- field: status
- name: response_total
- namespace: service
- tags:
- status: "{{status}}"
- host: "{{host}}"
-```
-
-{{% /tab %}}
-{{% tab "TOML" %}}
-
-```toml
-[transforms.my_transform_id]
-type = "log_to_metric"
-inputs = [ "my-source-or-transform-id" ]
-
- [[transforms.my_transform_id.metrics]]
- type = "counter"
- field = "status"
- name = "response_total"
- namespace = "service"
-
- [transforms.my_transform_id.metrics.tags]
- status = "{{status}}"
- host = "{{host}}"
-```
-
-{{% /tab %}}
-{{% tab "JSON" %}}
-
-```json
-{
- "transforms": {
- "my_transform_id": {
- "type": "log_to_metric",
- "inputs": [
- "my-source-or-transform-id"
- ],
- "metrics": [
- {
- "type": "counter",
- "field": "status",
- "name": "response_total",
- "namespace": "service",
- "tags": {
- "status": "{{status}}",
- "host": "{{host}}"
- }
- }
- ]
- }
- }
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-Si la configuration ci-dessus est appliquée au log suivant :
-
-```
-{
- "log": {
- "host": "10.22.11.222",
- "message": "Sent 200 in 54.2ms",
- "status": 200
- }
-}
-```
-
-Alors la métrique suivante est générée :
-
-```
-{"metric":{"counter":{"value":1},"kind":"incremental","name":"response_total","namespace":"service","tags":{"host":"10.22.11.222","status":"200"}}}]
-
-```
-
-### Rassembler plusieurs événements au sein d'un seul log
-
-Il est possible de regrouper plusieurs logs au sein d'un log unique. Ainsi, pour réduire votre volume de logs, une solution consiste à fusionner plusieurs logs. Utilisez la [transformation reduce][9] pour réunir plusieurs logs au sein d'un seul log.
-
-L'exemple de configuration ci-dessous utilise une transformation reduce pour fusionner plusieurs événements d'exception liés à des logs Ruby.
-
-{{< tabs >}}
-{{% tab "YAML" %}}
-
-```yaml
-transforms:
- my_transform_id:
- type: reduce
- inputs:
- - my-source-or-transform-id
- group_by:
- - host
- - pid
- - tid
- merge_strategies:
- message: concat_newline
- starts_when: match(string!(.message), r'^[^\\s]')
-```
-
-{{% /tab %}}
-{{% tab "TOML" %}}
-
-```toml
-[transforms.my_transform_id]
-type = "reduce"
-inputs = [ "my-source-or-transform-id" ]
-group_by = [ "host", "pid", "tid" ]
-starts_when = "match(string!(.message), r'^[^\\s]')"
-
-[transforms.my_transform_id.merge_strategies]
- message = "concat_newline"
-```
-
-{{% /tab %}}
-{{% tab "JSON" %}}
-
-```json
-{
- "transforms": {
- "my_transform_id": {
- "type": "reduce",
- "inputs": [
- "my-source-or-transform-id"
- ],
- "group_by": [
- "host",
- "pid",
- "tid"
- ],
- "merge_strategies": {
- "message": "concat_newline"
- },
- "starts_when": "match(string!(.message), r'^[^\\s]')"
- }
- }
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-Dans la transformation reduce, la valeur de `group_by` correspond à la liste triée des champs servant à regrouper les événements. Ici, les événements sont regroupés en fonction des champs `host`, `pid` et `tid`.
-
-L'option `merge_strategies` correspond à une map des noms de champs. Elle permet d'applique une stratégie de fusion personnalisée. Il existe [différentes stratégies de fusion][10], notamment `array`, qui annote chaque valeur dans un tableau, et `sum`, qui additionne toutes les valeurs numériques. Dans l'exemple ci-dessous, la stratégie `concat_newline` permet de concaténer toutes les valeurs de chaîne, puis de les délimiter à l'aide d'un retour à la ligne.
-
-La condition `starts_when` permet d'identifier le premier événement d'une transaction. Si la condition génère le statut `true` pour un événement, l'opération précédente est transmise sans cet événement, et une nouvelle opération est initiée. Dans l'exemple ci-dessus, les événements comportant `.message` et qui ne correspondent pas à l'expression régulière `^[^\\s]` sont rassemblés au sein d'un seul événement.
-
-Si la configuration ci-dessus est appliquée aux logs d'exception Ruby suivants :
-
-```
-[{"log":{
- "host":"host-1.hostname.com",
- "message":"foobar.rb:6:in `/': divided by 0(ZeroDivisionError)",
- "pid":1234,
- "tid":5678,
- "timestamp":"2020-10-07T12:33:21.223543Z"}
-},
-{
-"log":{
- "host":"host-1.hostname.com",
- "message":"from foobar.rb:6:in `bar'",
- "pid":1234,
- "tid":5678,
- "timestamp":"2020-10-07T12:33:21.223543Z"}
-},
-{
-"log":{
- "host":"host-1.hostname.com",
- "message":"from foobar.rb:2:in `foo'",
- "pid":1234,
- "tid":5678,
- "timestamp":"2020-10-07T12:33:21.223543Z"}
-},
-{
-"log":{
- "host":"host-1.hostname.com",
- "message":"from foobar.rb:9:in `\u003cmain\u003e'",
- "pid":1234,"tid":5678,
- "timestamp":"2020-10-07T12:33:21.223543Z"}
-},
-{
-"log":{
- "host":"host-1.hostname.com",
- "message":"Hello world, I am a new log",
- "pid":1234,
- "tid":5678,
- "timestamp":"2020-10-07T12:33:22.123528Z"
-}}]
-```
-
-Alors les logs suivants sont générés :
-
-```
-[{
-"log": {
- "host":"host-1.hostname.com",
- "message":"foobar.rb:6:in `/': divided by 0 (ZeroDivisionError)\n
- from foobar.rb:6:in `bar'\n
- from foobar.rb:2:in `foo'\n
- from foobar.rb:9:in `\u003cmain\u003e'",
- "pid":1234,
- "tid":5678,
- "timestamp":"2020-10-07T12:33:21.223543Z"}
-},
-{
-"log":{
- "host":"host-1.hostname.com",
- "message":"Hello world, I am a new log",
- "pid":1234,
- "tid":5678,
- "timestamp":"2020-10-07T12:33:22.123528Z"
-}}]
-```
-
-## Utiliser des transformations pour gérer la taille des logs
-
-### Supprimer des champs inutiles pour réduire la taille de vos logs
-
-Certains champs de vos logs peuvent n'avoir aucune utilité. Si vous traitez des téraoctets de données chaque jour, la suppression de ces champs superflus peut réduire considérablement le volume total de logs ingérés et indexés par votre destination.
-
-Pour remapper vos données de log et ainsi supprimer vos champs inutiles, utilisez la [syntaxe VRL (Vector Remap Language)][5]. L'exemple suivant permet de supprimer les tags inutiles à l'aide de `del`.
-
-{{< tabs >}}
-{{% tab "YAML" %}}
-
-```yaml
-transforms:
- my_transform_id:
- type: remap
- inputs:
- - my-source-or-transform-id
- source: |-
- del(.unecessary_env_field)
- del(.unecessary_service_field)
- del(.unecessary_tag_field)
-```
-
-{{% /tab %}}
-{{% tab "TOML" %}}
-
-```toml
-[transforms.my_transform_id]
-type = "remap"
-inputs = [ "my-source-or-transform-id" ]
-source = """
-del(.unecessary_env_field)
-del(.unecessary_service_field)
-del(.unecessary_tag_field)"""
-```
-
-{{% /tab %}}
-{{% tab "JSON" %}}
-
-```json
-{
- "transforms": {
- "my_transform_id": {
- "type": "remap",
- "inputs": [
- "my-source-or-transform-id"
- ],
- "source": "del(.unecessary_env_field)\ndel(.unecessary_service_field)\ndel(.unecessary_tag_field)"
- }
- }
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## Pour aller plus loin
-
-{{< partial name="whats-next/whats-next.html" >}}
-
-[1]: /fr/observability_pipelines/setup/
-[2]: /fr/observability_pipelines/vector_configurations/
-[3]: https://vector.dev/docs/reference/configuration/transforms/dedupe/
-[4]: https://vector.dev/docs/reference/configuration/transforms/filter/
-[5]: https://vector.dev/docs/reference/vrl/
-[6]: /fr/logs/explorer/search_syntax/
-[7]: https://vector.dev/docs/reference/configuration/transforms/sample/
-[8]: https://vector.dev/docs/reference/configuration/transforms/log_to_metric/
-[9]: https://vector.dev/docs/reference/configuration/transforms/reduce/
-[10]: https://vector.dev/docs/reference/configuration/transforms/reduce/#merge_strategies
\ No newline at end of file
diff --git a/content/fr/observability_pipelines/guide/route_logs_in_datadog_rehydratable_format_to_Amazon_S3.md b/content/fr/observability_pipelines/guide/route_logs_in_datadog_rehydratable_format_to_Amazon_S3.md
deleted file mode 100644
index 74d5f0ca617b8..0000000000000
--- a/content/fr/observability_pipelines/guide/route_logs_in_datadog_rehydratable_format_to_Amazon_S3.md
+++ /dev/null
@@ -1,280 +0,0 @@
----
-disable_toc: false
-further_reading:
-- link: /observability_pipelines/working_with_data/
- tag: Documentation
- text: Utilisation des données dans les pipelines d'observabilité
-- link: /logs/log_configuration/archives/
- tag: Documentation
- text: En savoir plus sur les archives de logs
-- link: /logs/log_configuration/rehydrating/
- tag: Documentation
- text: En savoir plus sur la réintégration des archives de logs
-kind: documentation
-title: Acheminer des logs dans un format réintégrable à Datadog vers Amazon S3
----
-
-
La destination Archives Datadog des pipelines d'observabilité est en version bêta.
-
-## Présentation
-
-La destination Archives Datadog des pipelines d'observabilité convertit les logs dans un format réintégrable à Datadog avant leur acheminement vers les [archives de logs][1]. Ces logs ne sont pas ingérés dans Datadog mais sont acheminés directement vers l'archive. Vous pouvez ensuite réintégrer cette dernière dans Datadog lorsque vous avez besoin d'analyser et d'étudier les logs. `datadog_archives` est disponible à partir de la version 1.5 du worker de pipelines d'observabilité.
-
-## Configurer une archive de logs
-
-### Créer un compartiment Amazon S3
-
-{{< site-region region="us,us3,us5" >}}
-Consultez la [tarification AWS][1] pour connaître les frais de transfert de données entre régions et déterminer l'impact éventuel sur vos frais de stockage dans le cloud.
-
-[1]: https://aws.amazon.com/s3/pricing/
-{{< /site-region >}}
-
-1. Accédez aux [compartiments Amazon S3][2].
-1. Cliquez sur **Create bucket**.
-1. Saisissez un nom décrivant votre compartiment.
-1. Assurez-vous que votre compartiment n'est pas accessible au public.
-1. Si besoin, ajoutez des tags.
-1. Cliquez sur **Create bucket**.
-
-### Configurer une stratégie IAM permettant aux workers d'écrire dans le compartiment S3
-
-1. Accédez à la [console IAM][3].
-1. Sélectionnez **Policies** dans le menu latéral gauche.
-1. Cliquez sur **Create policy**.
-1. Cliquez sur **JSON** dans la section **Specify permissions**.
-1. Copiez la stratégie ci-dessous et collez-la dans le **Policy editor**. Remplacez `` et `` par les informations du compartiment S3 créé précédemment.
-{{< code-block lang="json">}}
-{
- "Version": "2012-10-17",
- "Statement": [
- {
- "Sid": "DatadogUploadAndRehydrateLogArchives",
- "Effect": "Allow",
- "Action": ["s3:PutObject", "s3:GetObject"],
- "Resource": "arn:aws:s3:::/*"
- },
- {
- "Sid": "DatadogRehydrateLogArchivesListBucket",
- "Effect": "Allow",
- "Action": "s3:ListBucket",
- "Resource": "arn:aws:s3:::"
- }
- ]
-}
-{{< /code-block >}}
-1. Cliquez sur **Next**.
-1. Saisissez un nom décrivant la stratégie.
-1. Si besoin, ajoutez des tags.
-1. Cliquez sur **Create policy**.
-
-{{< tabs >}}
-{{% tab "Docker" %}}
-
-### Créer un utilisateur IAM
-
-Créez un utilisateur IAM et associez-lui la stratégie IAM créée précédemment.
-
-1. Accédez à la [console IAM][1].
-1. Sélectionnez **Users** dans le menu latéral gauche.
-1. Cliquez sur **Create user**.
-1. Saisissez un nom d'utilisateur.
-1. Cliquez sur **Next**.
-1. Sélectionnez **Attach policies directly**.
-1. Choisissez la stratégie IAM créée précédemment à associer au nouvel utilisateur IAM.
-1. Cliquez sur **Next**.
-1. Si besoin, ajoutez des tags.
-1. Cliquez sur **Create user**.
-
-Créez des identifiants d'accès pour le nouvel utilisateur IAM. Enregistrez-les sous `AWS_ACCESS_KEY` et `AWS_SECRET_ACCESS_KEY`.
-
-[1]: https://console.aws.amazon.com/iam/
-
-{{% /tab %}}
-{{% tab "AWS EKS" %}}
-
-### Créer un compte de service
-
-[Créez un compte de service][1] pour utiliser la stratégie créée ci-dessus. Dans la configuration Helm, remplacez `${DD_ARCHIVES_SERVICE_ACCOUNT}` par le nom du compte de service.
-
-
-[1]: https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html
-{{% /tab %}}
-{{% tab "Linux avec APT" %}}
-
-### Créer un utilisateur IAM
-
-Créez un utilisateur IAM et associez-lui la stratégie IAM créée précédemment.
-
-1. Accédez à la [console IAM][1].
-1. Sélectionnez **Users** dans le menu latéral gauche.
-1. Cliquez sur **Create user**.
-1. Saisissez un nom d'utilisateur.
-1. Cliquez sur **Next**.
-1. Sélectionnez **Attach policies directly**.
-1. Choisissez la stratégie IAM créée précédemment à associer au nouvel utilisateur IAM.
-1. Cliquez sur **Next**.
-1. Si besoin, ajoutez des tags.
-1. Cliquez sur **Create user**.
-
-Créez des identifiants d'accès pour le nouvel utilisateur IAM. Enregistrez-les sous `AWS_ACCESS_KEY` et `AWS_SECRET_ACCESS_KEY`.
-
-[1]: https://console.aws.amazon.com/iam/
-
-{{% /tab %}}
-{{% tab "Linux avec RPM" %}}
-
-### Créer un utilisateur IAM
-
-Créez un utilisateur IAM et associez-lui la stratégie IAM créée précédemment.
-
-1. Accédez à la [console IAM][1].
-1. Sélectionnez **Users** dans le menu latéral gauche.
-1. Cliquez sur **Create user**.
-1. Saisissez un nom d'utilisateur.
-1. Cliquez sur **Next**.
-1. Sélectionnez **Attach policies directly**.
-1. Choisissez la stratégie IAM créée précédemment à associer au nouvel utilisateur IAM.
-1. Cliquez sur **Next**.
-1. Si besoin, ajoutez des tags.
-1. Cliquez sur **Create user**.
-
-Créez des identifiants d'accès pour le nouvel utilisateur IAM. Enregistrez-les sous `AWS_ACCESS_KEY` et `AWS_SECRET_ACCESS_KEY`.
-
-[1]: https://console.aws.amazon.com/iam/
-
-{{% /tab %}}
-{{% tab "Terraform (AWS)" %}}
-
-### Associer la stratégie au profil d'instance IAM
-
-Associez la stratégie au profil d'instance IAM créé avec Terraform, qui est indiqué dans la sortie `iam-role-name`.
-
-{{% /tab %}}
-{{< /tabs >}}
-
-### Connecter le compartiment S3 aux archives de logs Datadog
-
-1. Accédez à la page [Log Forwarding][4] de Datadog.
-1. Cliquez sur **Add a new archive**.
-1. Saisissez un nom décrivant l'archive.
-1. Ajoutez une requête excluant tous les logs traités par les pipelines de logs afin qu'ils ne soient pas intégrés à cette archive. Par exemple, ajoutez la requête `observability_pipelines_read_only_archive`, en supposant que ce tag n'ait pas été ajouté aux logs traités par le pipeline.
-1. Sélectionnez **AWS S3**.
-1. Sélectionnez le compte AWS dans lequel se trouve votre compartiment.
-1. Saisissez le nom du compartiment S3.
-1. Si besoin, saisissez un chemin.
-1. Vérifiez la déclaration de confirmation.
-1. Si besoin, ajoutez des tags et définissez la taille d'analyse maximale pour la réintégration. Consultez la rubrique [Paramètres avancés][5] pour en savoir plus.
-1. Cliquez sur **Save**.
-
-Consultez la [documentation relative aux archives de logs][6] pour en savoir plus.
-
-## Configurer la destination Archives Datadog
-
-Vous pouvez configurer la destination `datadog_archives` à l'aide du [fichier de configuration](#fichier-de-configuration) ou à l'aide de l'[interface utilisateur de création de pipeline](#fichier-de-configuration).
-
-
Si des logs qui ne proviennent pas de l'Agent Datadog sont ingérés par le worker et acheminés vers la destination Archives Datadog, ils ne seront pas tagués avec les attributs réservés. Cela signifie que vous perdrez la télémétrie Datadog et les avantages du tagging de service unifié. Supposons, par exemple, que vos logs Syslog soient envoyés à la destination datadog_archives et qu'ils présentent le tag de statut severity au lieu de l'attribut réservé status et le tag de host hostname au lieu de l'attribut réservé hostname. Lors de leur réintégration dans Datadog, l'attribut status de tous ces logs sera défini sur info et aucun d'eux ne possédera de tag de hostname.
-
-### Fichier de configuration
-
-Pour les déploiements manuels, le [fichier d'exemple de configuration de pipelines][7] pour Datadog inclut un récepteur pour l'envoi des logs à Amazon S3 dans un format réintégrable à Datadog.
-
-{{< tabs >}}
-{{% tab "Docker" %}}
-
-Dans le fichier d'exemple de configuration de pipelines, remplacez `AWS_ACCESS_KEY_ID` et `AWS_SECRET_ACCESS_KEY` par les identifiants AWS créés précédemment.
-
-{{% /tab %}}
-{{% tab "AWS EKS" %}}
-
-Dans le fichier d'exemple de configuration de pipelines, remplacez `AWS_ACCESS_KEY_ID` et `AWS_SECRET_ACCESS_KEY` par les identifiants AWS créés précédemment.
-
-{{% /tab %}}
-{{% tab "Linux avec APT" %}}
-
-Dans le fichier d'exemple de configuration de pipelines, remplacez `AWS_ACCESS_KEY_ID` et `AWS_SECRET_ACCESS_KEY` par les identifiants AWS créés précédemment.
-
-{{% /tab %}}
-{{% tab "Linux avec RPM" %}}
-
-Dans le fichier d'exemple de configuration de pipelines, remplacez `AWS_ACCESS_KEY_ID` et `AWS_SECRET_ACCESS_KEY` par les identifiants AWS créés précédemment.
-
-{{% /tab %}}
-{{% tab "Terraform (AWS)" %}}
-
-Remplacez les paramètres `${DD_ARCHIVES_BUCKET}` et $`{DD_ARCHIVES_REGION}` en fonction de la configuration de votre compartiment S3.
-
-{{% /tab %}}
-{{< /tabs >}}
-
-### Interface utilisateur de création de pipeline
-
-1. Accédez à votre [pipeline][8].
-1. (Facultatif) Ajoutez une transformation de remappage pour taguer tous les logs envoyés à la destination `datadog_archives`.
- a. Cliquez sur **Edit** puis sur **Add More** dans le carré **Add Transforms**.
- b. Cliquez sur le carré **Remap**.
- c. Saisissez un nom décrivant le composant.
- d. Dans le champ **Inputs**, sélectionnez la source à connecter à cette destination.
- e. Ajoutez `.sender = "observability_pipelines_worker"` dans la section **Source**.
- f. Cliquez sur **Save**.
- g. Revenez à votre pipeline.
-1. Cliquez sur **Edit**.
-1. Cliquez sur **Add More** dans le carré **Add Destination**.
-1. Cliquez sur le carré **Datadog Archives**.
-1. Saisissez un nom décrivant le composant.
-1. Sélectionnez les sources ou les transformations à connecter à cette destination.
-
-{{< tabs >}}
-{{% tab "AWS S3" %}}
-
-7. Dans le champ **Bucket**, saisissez le nom du compartiment S3 créé précédemment.
-8. Saisissez `aws_s3` dans le champ **Service**.
-9. Activez **AWS S3** pour activer ces options de configuration spécifiques.
-10. Dans le champ **Storage Class**, sélectionnez la classe de stockage dans le menu déroulant.
-11. Définissez les autres options de configuration en fonction de vos besoins.
-12. Cliquez sur **Save**.
-
-{{% /tab %}}
-{{% tab "Blob Azure" %}}
-
-7. Dans le champ **Bucket**, saisissez le nom du compartiment S3 créé précédemment.
-8. Saisissez `azure_blob` dans le champ **Service**.
-9. Activez **Azure Blob** pour activer ces options de configuration spécifiques.
-10. Saisissez la chaîne de connexion au compte Stockage Blob Azure.
-11. Définissez les autres options de configuration en fonction de vos besoins.
-12. Cliquez sur **Save**.
-
-{{% /tab %}}
-{{% tab "GCP Cloud Storage" %}}
-
-7. Dans le champ **Bucket**, saisissez le nom du compartiment S3 créé précédemment.
-8. Saisissez `gcp_cloud_storage` dans le champ **Service**.
-9. Activez **GCP Cloud Storage** pour activer ces options de configuration spécifiques.
-10. Définissez les options de configuration en fonction de vos besoins.
-11. Cliquez sur **Save**.
-
-{{% /tab %}}
-{{< /tabs >}}
-
-Si vous utilisez la configuration à distance, déployez la modification dans votre pipeline par le biais de l'interface utilisateur. Dans le cas d'une configuration manuelle, téléchargez la configuration mise à jour et redémarrez le worker.
-
-Consultez la [documentation de référence relative aux archives Datadog][9] pour en savoir plus sur l'ensemble des options de configuration.
-
-## Réintégrer votre archive
-
-Consultez la rubrique [Réintégration à partir des archives][10] pour savoir comment réintégrer votre archive dans Datadog afin de pouvoir commencer à analyser et étudier ces logs.
-
-## Pour aller plus loin
-
-{{< partial name="whats-next/whats-next.html" >}}
-
-[1]: /fr/logs/log_configuration/archives/
-[2]: https://s3.console.aws.amazon.com/s3/home
-[3]: https://console.aws.amazon.com/iam/
-[4]: https://app.datadoghq.com/logs/pipelines/log-forwarding
-[5]: /fr/logs/log_configuration/archives/#advanced-settings
-[6]: /fr/logs/log_configuration/archives
-[7]: /fr/observability_pipelines/setup/datadog#installing-the-observability-pipelines-worker
-[8]: https://app.datadoghq.com/observability-pipelines/
-[9]: /fr/observability_pipelines/reference/sinks/#datadogarchivessink
-[10]: /fr/logs/log_configuration/rehydrating/
\ No newline at end of file
diff --git a/content/fr/observability_pipelines/monitoring.md b/content/fr/observability_pipelines/monitoring.md
deleted file mode 100644
index 95f7c094c5c4f..0000000000000
--- a/content/fr/observability_pipelines/monitoring.md
+++ /dev/null
@@ -1,66 +0,0 @@
----
-disable_toc: false
-kind: documentation
-title: Surveillance
----
-
-{{< site-region region="gov" >}}
-
Les pipelines d'observabilité ne sont pas disponibles sur le site US1-FED de Datadog.
-{{< /site-region >}}
-
-## Présentation
-
-Vos [pipelines d'observabilité][1] comprennent des composants qui recueillent, traitent et acheminent vos données d'observabilité. L'intégrité de vos pipelines et composants est illustrée par des statuts et des graphiques de santé, ainsi que des graphiques sur l'utilisation des ressources et la transmission des données.
-
-Les statuts de santé sont déterminés par des métriques spécifiques basées sur des seuils et des intervalles de temps par défaut. Voici la liste des statuts disponibles :
-
-- `Healthy` : ce statut indique que le worker n'a pas pris de retard.
-- `Warning` : ce statut indique que le worker ne fonctionne pas de manière optimale et risque de prendre du retard. Le worker peut prendre du retard lorsqu'une destination ou un service en aval génère une certaine contre-pression alors que la quantité de ressources provisionnées pour les workers est insuffisante.
-- `Critical` : ce statut indique que le worker est en train de prendre du retard. Si le worker prend du retard, il risque éventuellement d'ignorer des données. Sachez cependant que tant que vos pipelines sont [architecturés][2] et configurés correctement, le worker ne perd involontairement aucune donnée.
-
-Les métriques internes, qui sont regroupées selon leur type (santé, transmission de données et utilisation de ressources), gouvernent le statut de santé global de votre pipeline et de ses composants.
-
-Les graphiques de santé sont disponibles pour les métriques suivantes :
-- Événements ignorés involontairement
-- Erreurs
-- Temps de latence (uniquement disponible pour les sources)
-- Taux de variation des temps de latence (uniquement disponible pour les sources)
-- Utilisation
-
-Les graphiques sur la transmission des données sont disponibles pour les métriques suivantes :
-- Entrée/sortie d'événements par seconde
-- Entrée/sortie d'octets par seconde
-
-Les graphiques sur l'utilisation des ressources sont disponibles pour les métriques suivantes :
-- Utilisation du CPU
-- Utilisation de la mémoire
-- Utilisation du disque (uniquement disponible pour les destinations)
-
-## Consulter le statut de vos pipelines et composants
-
-1. Accédez à [Observability Pipelines][3].
-1. Cliquez sur un pipeline.
-1. Passez le curseur sur un graphique pour afficher des points de données spécifiques.
-
-## Métriques de santé relatives à l'utilisation des ressources d'un pipeline
-
-| Métrique | OK | Warning | Critical | Description |
-| ------------ | :------: | :--------: | :-------: | --------------------------------- |
-| Utilisation du CPU | <= 0.85 | > 0.85 | S. O. | Surveille la quantité de CPU utilisé par un processus de worker.
La valeur `1` signifie que le processus du worker n'a plus aucune marge en ce qui concerne le host ou les unités de calcul qui l'exécutent. Cela peut mener à d'éventuels problèmes : dépassement des limites de latence de traitement, surcharges de données en amont ou en aval, etc.|
-| Utilisation de la mémoire | >= 0.15 | < 0.15 | S. O. | Surveille la quantité de mémoire utilisée et disponible sur le host. Le worker n'est pas limité en termes de mémoire, mais une utilisation élevée de la mémoire peut indiquer des fuites.
-
-## Métriques de santé des composants
-
-| Métrique | Sources | Transformations| Destinations | OK | Warning | Critical | Description |
-| ------------------------ | :-------: | :-------: | :----------: | :-----: | :------: | :--------:| --------------------------------- |
-| Événements ignorés | {{< X >}} | {{< X >}} |{{< X >}} | ==0 | S. O. | > 0 |La valeur attendue est toujours `0`. Si vous avez configuré le worker de façon à ignorer volontairement des données, par exemple à l'aide de la transformation `filter`, ces données ne sont pas comptabilisées par cette métrique. Par conséquent, il suffit d'une erreur pour indiquer que le worker n'est pas sain.|
-| Erreurs totales |{{< X >}} |{{< X >}} |{{< X >}} | ==0 | >0 | S. O. | Le nombre total d'erreurs rencontrées par le composant. Ces erreurs sont également émises sous forme de [logs de diagnostic][4], qui fournissent plus d'informations sur les logs d'erreurs internes spécifiques. |
-| Utilisation | |{{< X >}} |{{< X >}} | <= 0.95 | > 0.95 | S. O. | Surveille l'activité d'un composant.
La valeur `0` indique que le composant est inactif et en attente de données. La valeur `1` indique que le composant n'est jamais inactif. Une valeur supérieure à `0.95` indique que le composant est occupé et qu'il y a probablement un goulot d'étranglement au niveau de la topologie de traitement. |
-| Temps de latence |{{< X >}} | | | S. O. | S. O. | S. O. | Il s'agit de l'écart de temps brut (en millisecondes) entre le timestamp de l'événement et celui de l'ingestion de l'événement par le worker. Un temps de latence élevé ou une variation de celui-ci (voir ci-dessous) indique si le worker prend ou non du retard en raison d'une contre-pression provenant d'un service en aval, d'un sous-provisionnement de ressources pour le worker ou d'un goulot d'étranglement dans le pipeline. |
-| Taux de variation du temps de latence | {{< X >}} | | | <= 0 | > 0 | > 1 | Indique s'il y a un délai important entre la génération de l'événement et la réception des données par le worker. Un délai signifie que le worker prend du retard dans la réception des données de la source.
La valeur `0` indique qu'il n'y a aucun délai supplémentaire entre le moment où les données d'observabilité sont générées et celui où le worker reçoit les données. Une valeur supérieure ou égale à `1` indique la présence d'une contre-pression et d'un goulot d'étranglement. |
-| Utilisation du disque | | |{{< X >}} | >= 0.20 | > 0.20 | S. O. | Mesure le niveau de remplissage d'un disque donné.
La valeur `1` indique qu'aucune donnée supplémentaire ne peut être stockée sur le disque. La valeur `0` indique que le disque est vide. |
-
-[1]: /fr/observability_pipelines/
-[2]: /fr/observability_pipelines/architecture/
-[3]: https://app.datadoghq.com/observability-pipelines/
-[4]: /fr/observability_pipelines/troubleshooting/#investigate-diagnostic-logs
\ No newline at end of file
diff --git a/content/fr/observability_pipelines/production_deployment_overview.md b/content/fr/observability_pipelines/production_deployment_overview.md
deleted file mode 100644
index 2844122f9f645..0000000000000
--- a/content/fr/observability_pipelines/production_deployment_overview.md
+++ /dev/null
@@ -1,148 +0,0 @@
----
-kind: Documentation
-title: Principes et méthodologie de déploiement
----
-
-{{< site-region region="gov" >}}
-
La fonctionnalité Pipelines d'observabilité n'est pas disponible pour le site Datadog US1-FED.
-{{< /site-region >}}
-
-## Présentation
-
-Dans le cadre du déploiement du worker des pipelines d'observabilité au sein de votre infrastructure, il se peut que vous vous posiez un certain nombre de questions, par exemple :
-
-- À quel endroit du réseau le worker des pipelines d'observabilité doit-il être déployé ?
-- Comment les données doivent-elles être recueillies ?
-- Où les données doivent-elles être traitées ?
-
-Ce guide aborde les différents éléments qui interviennent dans la conception de l'architecture de votre worker de pipelines d'observabilité, et plus particulièrement les points suivants :
-
-- [Réseau](#reseau)
-- [Collecte de données](#collecte-de-donnees)
-- [Traitement des données](#traitement-des-donnees)
-- [Mise en mémoire tampon des données](#mise-en-memoire-tampon-des-donnees)
-- [Acheminement des données](#acheminement-des-donnees)
-
-## Réseau
-
-Dans le cadre de la conception du déploiement de votre worker de pipelines d'observabilité, la première étape consiste à comprendre la place occupée par le worker des pipelines d'observabilité au sein de votre réseau et l'endroit où le déployer.
-
-### Respecter les limites du réseau
-
-Étant donné que le worker des pipelines d'observabilité est déployé en tant qu'agrégateur, il convient de le déployer à l'intérieur des limites du réseau pour limiter les coûts liés au trafic de sortie. Les données réceptionnées par le worker des pipelines d'observabilité ne doivent jamais être transférées par le biais du réseau Internet public. Par souci de facilité, Datadog recommande donc de commencer par un agrégateur par région.
-
-### Utiliser des pare-feu et des proxies
-
-Si vous utilisez des pare-feu, limitez les communications de l'Agent à vos agrégateurs et les communications de l'agrégateur à vos sources et récepteurs configurés.
-
-Si vous préférez utiliser un proxy HTTP, le worker des pipelines d'observabilité offre une option de proxy global permettant d'acheminer l'intégralité du trafic HTTP du worker de pipelines d'observabilité via un proxy.
-
-### Utiliser la découverte du DNS et de services
-
-Utilisez la découverte du DNS ou de services pour détecter les agrégateurs et services de votre worker de pipelines d'observabilité. Cette stratégie facilite l'acheminement ainsi que l'équilibrage de charge de votre trafic ; il s'agit également de la stratégie employée par vos agents et répartiteurs de charge pour découvrir vos agrégateurs. Pour séparer clairement les problèmes, le worker des pipelines d'observabilité ne résout pas les requêtes DNS lui-même, mais délègue cette tâche à un résolveur au niveau du système ([résolution de requêtes Linux][1]), par exemple).
-
-{{< img src="observability_pipelines/production_deployment_overview/dns_service_discovery.png" alt="Un diagramme présentant une région cloud avec un cluster d'agents, un cluster de répartiteurs de charge et plusieurs workers de pipelines d'observabilité ; chaque groupe envoie des requêtes distinctes au registre DNS ou au registre de service" style="width:60%;" >}}
-
-### Choix des protocoles
-
-Lors de l'envoi de données au worker des pipelines d'observabilité, Datadog recommande de choisir un protocole facilitant l'équilibrage de charge et permettant d'obtenir une confirmation de réception au niveau de l'application. Nous recommandons de privilégier les protocoles HTTP et gRPC étant donné qu'ils sont couramment utilisés et que de nombreux outils et documents sont disponibles pour gérer efficacement les services utilisant le protocole HTTP/gRPC.
-
-Choisissez la source qui correspond à votre protocole. Chaque source du worker de pipelines d'observabilité implémente des protocoles distincts. Par exemple, les sources et récepteurs du worker de pipelines d'observabilité se servent du protocole gRPC pour les communications du worker de pipelines d'inter-observabilité, tandis que la source HTTPS vous permet de recevoir des données via HTTPS. Consultez la section [Sources][2] pour découvrir leurs protocoles respectifs.
-
-## Collecte de données
-
-Votre pipeline démarre par la collecte de données. Vos services et systèmes génèrent des données[*](#prise-en-charge) qui peuvent être recueillies et envoyées en aval vers vos destinations. Les données sont recueillies au moyen d'agents, et il est primordial de comprendre lequel utiliser pour bien recueillir les données qui vous intéressent.
-
-### Choix des agents
-
-Vous devez choisir l'agent qui aidera votre équipe d'ingénieurs à surveiller leurs systèmes de façon optimale. Aussi, intégrez le worker des pipelines d'observabilité à l'agent le plus adéquat selon la tâche à accomplir, et déployez le worker des pipelines d'observabilité sur des nœuds distincts en tant qu'agrégateur.
-
-Par exemple, la solution [Network Performance Monitoring][4] de Datadog intègre à l'Agent Datadog des systèmes propres au fournisseur et produit des données uniques pour ce dernier. L'Agent Datadog doit donc recueillir et envoyer directement les données à Datadog, puisque ce type de données n'est pas pris en charge dans le worker des pipelines d'observabilité.
-
-Autre exemple : l'Agent Datadog recueille des métriques de service et les enrichit avec des tags Datadog propres au fournisseur. Dans ce cas précis, l'Agent Datadog doit envoyer les métriques directement à Datadog ou les acheminer via le worker des pipelines d'observabilité. Ce dernier ne doit pas remplacer l'Agent Datadog, car les données produites sont enrichies avec des éléments propres au fournisseur.
-
-Lorsque vous intégrez des éléments à un agent, configurez le worker des pipelines d'observabilité afin qu'il reçoive les données directement à partir de l'agent par le biais du réseau local, en acheminant les données via le worker des pipelines d'observabilité. Utilisez des composants source comme `datadog_agent` ou `open_telemetry` pour recevoir les données de vos agents.
-
-##### Limiter les risques liés à un agent
-
-Lorsque vous intégrez des éléments à un agent, configurez-le de façon à ce qu'il fasse office de simple forwarder de données et acheminez les types de données pris en charge par le biais du worker des pipelines d'observabilité. En procédant de la sorte, vous réduisez les risques de perte de données et d'interruption de service en limitant les responsabilités de l'agent.
-
-## Traitement des données
-
-Pour concevoir un pipeline efficace entre les sources et les récepteurs de votre worker de pipelines d'observabilité, vous devez notamment apprendre à identifier les types de données à traiter et l'endroit où les traiter.
-
-### Choix des données à traiter
-
-Vous pouvez utiliser le worker des pipelines d'observabilité pour traiter vos données[*](#prise-en-charge). Toutefois, les données en temps réel propres au fournisseur, telles que les données de profiling en continu, ne sont pas interopérables et leur traitement ne vous est généralement d'aucune utilité.
-
-#### Traitement à distance
-
-Pour le traitement à distance, le worker des pipelines d'observabilité peut être déployé sur des nœuds distincts en tant qu'agrégateur.
-
-{{< img src="observability_pipelines/production_deployment_overview/aggregator_role.png" alt="Un diagramme présentant un agrégateur du worker de pipelines d'observabilité comportant plusieurs workers qui reçoivent des données du répartiteur d'équilibre du réseau et qui en envoient à différents récepteurs" style="width:100%;" >}}
-
-Le traitement des données ne passe plus par vos nœuds, mais par ceux de l'agrégateur distant. Le traitement à distance est recommandé pour les environnements à haute disponibilité et hautement robustes (autrement dit, la plupart des environnements). En outre, la configuration se veut simplifiée, puisque la restructuration de l'infrastructure indispensable en cas d'ajout d'un agent n'est pas requise avec le traitement à distance.
-
-Consultez la section [Architecture de l'agrégateur][5] pour en savoir plus.
-
-## Mise en mémoire tampon des données
-
-L'efficacité de votre pipeline dépend également de l'endroit où vous mettez vos données en mémoire tampon et de la méthode utilisée.
-
-### Choisir l'endroit où mettre les données en mémoire tampon
-
-Les données doivent être mises en mémoire tampon juste avant d'atteindre vos destinations, et chaque destination doit posséder son propre buffer isolé afin de profiter des avantages suivants :
-
-1. Chaque destination peut configurer son buffer afin qu'il respecte les conditions du récepteur. Consultez la section [Choisir comment mettre les données en mémoire tampon](#choisir-comment-mettre-les-donnees-en-memoire-tampon)
-2. Isoler les buffers pour chaque destination permet d'éviter qu'une destination défectueuse interrompe l'ensemble du pipeline jusqu'à ce que le buffer atteigne la capacité configurée.
-
-Ce sont les raisons pour lesquelles le worker des pipelines d'observabilité associe les buffers à ses récepteurs.
-
-{{< img src="observability_pipelines/production_deployment_overview/where_to_buffer.png" alt="Un diagramme présentant l'agent dans un nœud envoyant des données à un worker des pipelines d'observabilité avec un buffer dans un nœud distinct" style="width:50%;" >}}
-
-### Choisir la manière de mettre les données en mémoire tampon
-
-Les buffers intégrés au worker des pipelines d'observabilité facilitent les opérations en éliminant la nécessité d'avoir recours à des buffers externes complexes.
-
-Au moment de choisir un type de buffer intégré au worker des pipelines d'observabilité, sélectionnez celui qui est le plus adapté en fonction de la nature de la destination. Par exemple, votre système d'enregistrement doit utiliser des buffers de disque afin de garantir une grande durabilité. Votre système d'analyse doit, quant à lui, utiliser des buffers de mémoire pour garantir une faible latence. Par ailleurs, tout excès de données dans un type de buffer peut être transféré vers l'autre type de buffer, ce qui évite de propager la pression à vos clients.
-
-{{< img src="observability_pipelines/production_deployment_overview/how_to_buffer.png" alt="Un diagramme présentant les sources d'un worker de pipelines d'observabilité envoyant des données aux buffers de disque et de mémoire situés à proximité des récepteurs" style="width:100%;" >}}
-
-## Acheminement des données
-
-L'acheminement des données, qui permet à vos agrégateurs d'envoyer les données à la destination adéquate, constitue la dernière étape de la conception de votre pipeline. Utilisez les agrégateurs pour acheminer de manière flexible les données vers le meilleur système, selon les besoins de vos équipes.
-
-### Séparer les systèmes d'enregistrement et d'analyse
-
-Séparez votre système d'enregistrement de votre système d'analyse afin d'optimiser les coûts sans effectuer de compromis susceptibles de nuire à leur fonctionnement. Par exemple, votre système d'enregistrement est capable de regrouper de grandes quantités de données au fil du temps et de les compresser afin de limiter les coûts tout en garantissant une grande durabilité pour l'ensemble des données. Votre système d'analyse, quant à lui, peut échantillonner et nettoyer des données pour réduire les coûts tout en maintenant une faible latence pour les analyses en temps réel.
-
-{{< img src="observability_pipelines/production_deployment_overview/separating_concerns.png" alt="Un diagramme présentant les sources d'un worker de pipelines d'observabilité envoyant des données au buffer de disque, qui transmet ensuite ces données pour qu'elles soient archivées ou les envoie à un disque de stockage en bloc pour qu'elles soient échantillonnées" style="width:100%;" >}}
-
-### Acheminer les données vers vos systèmes d'enregistrement (archivage)
-
-Suivez ces étapes pour renforcer la durabilité de votre système d'enregistrement tout en limitant les coûts :
-
-- Écrivez uniquement sur votre archive à partir du rôle d'agrégateur pour limiter les pertes de données dues au redémarrage du nœud et aux échecs de logiciels.
-- Placez un buffer de disque avant le récepteur.
-- Activez les confirmations de bout en bout sur toutes les sources.
-- Définissez `batch.max_bytes` sur ≥ 5 MiB, `batch.timeout_secs` sur ≥ 5 minutes, puis activez la compression (paramètres par défaut pour l'archivage de récepteurs, comme le récepteur `aws_s3`).
-- Archivez des données brutes non traitées afin de pouvoir les relire et de limiter les risques de corruption accidentelle des données pendant leur traitement.
-
-### Acheminer les données vers votre système d'analyse
-
-Suivez ces étapes pour optimiser les analyses de votre système d'analyse tout en limitant les coûts :
-
-- Placez un buffer de mémoire avant le récepteur.
-- Définissez `batch.timeout_sec` sur ≤ 5 secondes (paramètre par défaut pour les récepteurs analytiques, tels que `datadog_logs`).
-- Utilisez le transform `remap` pour supprimer les attributs non utilisés dans le cadre de l'analyse.
-- Filtrez les événements non utilisés dans le cadre de l'analyse.
-- Envisagez d'échantillonner les logs en définissant le paramètre `level` sur `info` ou un niveau inférieur pour réduire leur volume.
-
-[1]: https://wiki.archlinux.org/title/Domain_name_resolution
-[2]: /fr/observability_pipelines/reference/sources/
-[4]: /fr/network_monitoring/performance/
-[5]: /fr/observability_pipelines/architecture/
-
----
-
- * Les pipelines d'observabilité prennent en charge les logs. La prise en charge des métriques est en version bêta.
\ No newline at end of file
diff --git a/content/fr/observability_pipelines/reference/processing_language/errors.md b/content/fr/observability_pipelines/reference/processing_language/errors.md
deleted file mode 100644
index 6ecc9eb3abba5..0000000000000
--- a/content/fr/observability_pipelines/reference/processing_language/errors.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-title: Erreurs
----
-
-{{< site-region region="gov" >}}
-
Les pipelines d'observabilité ne sont pas disponibles sur le site US1-FED de Datadog.
-{{< /site-region >}}
-
-Datadog Processing Language (DPL), ou Vector Remap Language (VRL), est un langage « fail-safe », ce qui signifie qu'un programme DPL/VRL se compile uniquement si toutes les erreurs potentielles ont été gérées. Vos programmes DPL/VRL peuvent ainsi régler les problèmes de mise en forme de données.
-
-## Erreurs au moment de la compilation
-{{< vrl-errors >}}
\ No newline at end of file
diff --git a/content/fr/observability_pipelines/reference/processing_language/functions.md b/content/fr/observability_pipelines/reference/processing_language/functions.md
deleted file mode 100644
index b0c6a6ff543a6..0000000000000
--- a/content/fr/observability_pipelines/reference/processing_language/functions.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-title: Fonctions
----
-
-{{< site-region region="gov" >}}
-
Les pipelines d'observabilité ne sont pas disponibles sur le site US1-FED de Datadog.
-{{< /site-region >}}
-
-Datadog Processing Language (DPL), ou Vector Remap Language (VRL), intègre des fonctions de transformation de vos données.
-
-{{< whatsnext desc="Les fonctions sont classées en plusieurs catégories :" >}}
- {{< nextlink href="observability_pipelines/reference/processing_language/functions/#tableau" >}}Tableau{{< /nextlink >}}
- {{< nextlink href="observability_pipelines/reference/processing_language/functions/#codec" >}}Codec{{< /nextlink >}}
- {{< nextlink href="observability_pipelines/reference/processing_language/functions/#conversion" >}}Conversion{{< /nextlink >}}
- {{< nextlink href="observability_pipelines/reference/processing_language/functions/#cryptographie" >}}Cryptographie{{< /nextlink >}}
- {{< nextlink href="observability_pipelines/reference/processing_language/functions/#debugging" >}}Debugging{{< /nextlink >}}
- {{< nextlink href="observability_pipelines/reference/processing_language/functions/#enrichissement" >}}Enrichissement{{< /nextlink >}}
- {{< nextlink href="observability_pipelines/reference/processing_language/functions/#ip" >}}IP{{< /nextlink >}}
- {{< nextlink href="observability_pipelines/reference/processing_language/functions/#nombre" >}}Nombre{{< /nextlink >}}
- {{< nextlink href="observability_pipelines/reference/processing_language/functions/#objet" >}}Objet{{< /nextlink >}}
- {{< nextlink href="observability_pipelines/reference/processing_language/functions/#parsing" >}}Parsing{{< /nextlink >}}
- {{< nextlink href="observability_pipelines/reference/processing_language/functions/#chemin" >}}Chemin{{< /nextlink >}}
- {{< nextlink href="observability_pipelines/reference/processing_language/functions/#aleatoire" >}}Aléatoire{{< /nextlink >}}
- {{< nextlink href="observability_pipelines/reference/processing_language/functions/#chaîne" >}}Chaîne{{< /nextlink >}}
- {{< nextlink href="observability_pipelines/reference/processing_language/functions/#systeme" >}}Système{{< /nextlink >}}
- {{< nextlink href="observability_pipelines/reference/processing_language/functions/#timestamp" >}}Timestamp{{< /nextlink >}}
- {{< nextlink href="observability_pipelines/reference/processing_language/functions/#type" >}}Type{{< /nextlink >}}
-{{< /whatsnext >}}
-
-{{< vrl-functions >}}
\ No newline at end of file
diff --git a/content/fr/observability_pipelines/setup/datadog.md b/content/fr/observability_pipelines/setup/datadog.md
deleted file mode 100644
index 448fd29ecb296..0000000000000
--- a/content/fr/observability_pipelines/setup/datadog.md
+++ /dev/null
@@ -1,589 +0,0 @@
----
-aliases:
-- /fr/agent/vector_aggregation/
-- /fr/integrations/observability_pipelines/integrate_vector_with_datadog/
-- /fr/observability_pipelines/integrate_vector_with_datadog/
-- /fr/observability_pipelines/integrations/integrate_vector_with_datadog/
-- /fr/observability_pipelines/production_deployment_overview/integrate_datadog_and_the_observability_pipelines_worker/
-further_reading:
-- link: /observability_pipelines/production_deployment_overview/
- tag: Documentation
- text: Conception et principes de déploiement en production du worker de pipelines
- d'observabilité
-- link: https://dtdg.co/d22op
- tag: Centre d'apprentissage
- text: Traitement en local sécurisé à l'aide de pipelines d'observabilité
-kind: Documentation
-title: Configurer des pipelines d'observabilité dans Datadog
----
-
-{{< site-region region="gov" >}}
-
Les pipelines d'observabilité ne sont pas disponibles sur le site US1-FED de Datadog.
-{{< /site-region >}}
-
-## Présentation
-
-Le [worker de pipelines d'observabilité][1] peut collecter et traiter les logs et les métriques de n'importe quelle source et les acheminer vers n'importe quelle destination. Datadog vous permet de concevoir et de gérer tous vos déploiements de worker de pipelines d'observabilité de façon évolutive.
-
-Ce guide explique comment déployer le worker dans votre cluster d'outils communs et configurer l'Agent Datadog pour qu'il envoie les logs et les métriques au worker.
-
-{{< img src="observability_pipelines/setup/opw-dd-pipeline.png" alt="Diagramme de deux clusters de charge de travail envoyant leurs données via l'agrégateur de pipelines d'observabilité." >}}
-
-## Hypothèses
-* Vous utilisez déjà Datadog et voulez utiliser des pipelines d'observabilité.
-* Vous bénéficiez d'un accès administrateur aux clusters dans lesquels le worker de pipelines d'observabilité va être déployé, ainsi qu'aux charges de travail qui vont être agrégées.
-* Vous disposez dans votre environnement d'un cluster d'outils communs ou de sécurité auquel tous les autres clusters sont connectés.
-
-## Prérequis
-Avant de procéder à l'installation, assurez-vous que vous disposez des éléments suivants :
-
-* Une [clé d'API Datadog][2] valide.
-* Un ID de pipeline.
-
-Vous pouvez générer ces deux éléments dans [Observability Pipelines][3].
-
-### Exigences propres au fournisseur
-{{< tabs >}}
-{{% tab "Docker" %}}
-Assurez-vous que votre machine est configurée pour exécuter Docker.
-{{% /tab %}}
-{{% tab "AWS EKS" %}}
-Pour exécuter le worker sur vos nœuds Kubernetes, vous devez disposer au minimum de deux nœuds avec un processeur et 512 Mo de mémoire RAM disponibles. Datadog vous conseille de créer un pool de nœuds distinct pour les workers, ce qui correspond également à la configuration conseillée pour les déploiements en production.
-
-* Le [pilote EBS CSI][1] est requis. Pour savoir s'il est installé, exécutez la commande suivante et recherchez `ebs-csi-controller` dans la liste :
-
- ```shell
- kubectl get pods -n kube-system
- ```
-
-* Une `StorageClass` est requise pour que les workers provisionnent les disques EBS adéquats. Pour savoir si elle est déjà installée, exécutez la commande suivante et recherchez `io2` dans la liste :
-
- ```shell
- kubectl get storageclass
- ```
-
- Si `io2` ne figure pas dans la liste, téléchargez [le fichier YAML StorageClass][2] et exécutez la commande `kubectl apply` pour l'appliquer.
-
-* Le contrôleur [AWS Load Balancer Controller][3] est requis. Pour savoir s'il est installé, exécutez la commande suivante et recherchez `aws-load-balancer-controller` dans la liste :
-
- ```shell
- helm list -A
- ```
-* Datadog vous conseille d'utiliser la version 1.16 ou supérieure d'Amazon EKS.
-
-Consultez la section [Meilleures pratiques pour l'architecture de l'agrégateur OPW][4] pour connaître les exigences au niveau production.
-
-[1]: https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html
-[2]: /resources/yaml/observability_pipelines/helm/storageclass.yaml
-[3]: https://docs.aws.amazon.com/eks/latest/userguide/aws-load-balancer-controller.html
-[4]: /fr/observability_pipelines/architecture/
-
-{{% /tab %}}
-{{% tab "Azure AKS" %}}
-Pour exécuter le worker sur vos nœuds Kubernetes, vous devez disposer au minimum de deux nœuds avec un processeur et 512 Mo de mémoire RAM disponibles. Datadog vous conseille de créer un pool de nœuds distinct pour les workers, ce qui correspond également à la configuration conseillée pour les déploiements en production.
-
-Consultez la section [Meilleures pratiques pour l'architecture de l'agrégateur OPW][1] pour connaître les exigences au niveau production.
-
-[1]: /fr/observability_pipelines/architecture/
-{{% /tab %}}
-{{% tab "Google GKE" %}}
-Pour exécuter le worker sur vos nœuds Kubernetes, vous devez disposer au minimum de deux nœuds avec un processeur et 512 Mo de mémoire RAM disponibles. Datadog vous conseille de créer un pool de nœuds distinct pour les workers, ce qui correspond également à la configuration conseillée pour les déploiements en production.
-
-Consultez la section [Meilleures pratiques pour l'architecture de l'agrégateur OPW][1] pour connaître les exigences au niveau production.
-
-[1]: /fr/observability_pipelines/architecture/
-{{% /tab %}}
-{{% tab "Linux avec APT" %}}
-Il n'y a aucune exigence propre au fournisseur pour les distributions Linux utilisant APT.
-{{% /tab %}}
-{{% tab "Linux avec RPM" %}}
-Il n'y a aucune exigence propre au fournisseur pour les distributions Linux utilisant RPM.
-{{% /tab %}}
-{{% tab "Terraform (AWS)" %}}
-Pour exécuter le worker dans votre compte AWS, vous devez bénéficier d'un accès administrateur à ce dernier. Recueillez les informations suivantes pour exécuter les instances du worker :
-* L'ID du VPC dans lequel s'exécuteront vos instances.
-* Les ID des sous-réseaux dans lesquels s'exécuteront vos instances.
-* La région AWS dans laquelle se trouve votre VPC.
-{{% /tab %}}
-{{% tab "CloudFormation" %}}
-
-
Les installations CloudFormation ne prennent en charge que la configuration à distance.
-
Les installations CloudFormation ne doivent pas être utilisées pour les charges de travail de production.
-
-Pour exécuter le worker dans votre compte AWS, vous devez bénéficier d'un accès administrateur à ce dernier. Recueillez les informations suivantes pour exécuter les instances du worker :
-* L'ID du VPC dans lequel s'exécuteront vos instances.
-* Les ID des sous-réseaux dans lesquels s'exécuteront vos instances.
-* La région AWS dans laquelle se trouve votre VPC.
-{{% /tab %}}
-{{< /tabs >}}
-
-## Installer le worker de pipelines d'observabilité
-
-{{< tabs >}}
-{{% tab "Docker" %}}
-
-L'image Docker du worker de pipelines d'observabilité est disponible sur Docker Hub [ici][1].
-
-1. Téléchargez le [fichier d'exemple de configuration de pipeline][2].
-
-2. Exécutez la commande suivante pour démarrer le worker de pipelines d'observabilité avec Docker :
- ```
- docker run -i -e DD_API_KEY= \
- -e DD_OP_PIPELINE_ID= \
- -e DD_SITE= \
- -p 8282:8282 \
- -v ./pipeline.yaml:/etc/observability-pipelines-worker/pipeline.yaml:ro \
- datadog/observability-pipelines-worker run
- ```
- Remplacez `` par votre clé d'API Datadog, `` par votre ID de configuration de pipeline d'observabilité, et `` par {{< region-param key="dd_site" code="true" >}}. `./pipeline.yaml` doit correspondre au chemin relatif ou absolu du fichier de configuration que vous avez téléchargé à l'étape 1.
-
-[1]: https://hub.docker.com/r/datadog/observability-pipelines-worker
-[2]: /resources/yaml/observability_pipelines/datadog/pipeline.yaml
-{{% /tab %}}
-{{% tab "AWS EKS" %}}
-1. Téléchargez le [chart Helm][1] pour AWS EKS.
-
-2. Dans le chart Helm, remplacez les valeurs `datadog.apiKey` et `datadog.pipelineId` par celles correspondant à votre pipeline, et utilisez {{< region-param key="dd_site" code="true" >}} pour la valeur `site`. Installez-le ensuite dans votre cluster avec les commandes suivantes :
-
- ```shell
- helm repo add datadog https://helm.datadoghq.com
- ```
- ```shell
- helm repo update
- ```
- ```shell
- helm upgrade --install \
- opw datadog/observability-pipelines-worker \
- -f aws_eks.yaml
- ```
-
-[1]: /resources/yaml/observability_pipelines/datadog/aws_eks.yaml
-{{% /tab %}}
-{{% tab "Azure AKS" %}}
-1. Téléchargez le [chart Helm][1] pour Azure AKS.
-
-2. Dans le chart Helm, remplacez les valeurs `datadog.apiKey` et `datadog.pipelineId` par celles correspondant à votre pipeline, et utilisez {{< region-param key="dd_site" code="true" >}} pour la valeur `site`. Installez-le ensuite dans votre cluster avec les commandes suivantes :
-
- ```shell
- helm repo add datadog https://helm.datadoghq.com
- ```
- ```shell
- helm repo update
- ```
- ```shell
- helm upgrade --install \
- opw datadog/observability-pipelines-worker \
- -f azure_aks.yaml
- ```
-
-[1]: /resources/yaml/observability_pipelines/datadog/azure_aks.yaml
-{{% /tab %}}
-{{% tab "Google GKE" %}}
-1. Téléchargez le [chart Helm][1] pour Google GKE.
-
-2. Dans le chart Helm, remplacez les valeurs `datadog.apiKey` et `datadog.pipelineId` par celles correspondant à votre pipeline, et utilisez {{< region-param key="dd_site" code="true" >}} pour la valeur `site`. Installez-le ensuite dans votre cluster avec les commandes suivantes :
-
- ```shell
- helm repo add datadog https://helm.datadoghq.com
- ```
- ```shell
- helm repo update
- ```
- ```shell
- helm upgrade --install \
- opw datadog/observability-pipelines-worker \
- -f google_gke.yaml
- ```
-
-[1]: /resources/yaml/observability_pipelines/datadog/google_gke.yaml
-{{% /tab %}}
-{{% tab "Linux avec APT" %}}
-1. Exécutez les commandes suivantes pour configurer APT de sorte que les téléchargements se fassent via le protocole HTTPS :
-
- ```
- sudo apt-get update
- sudo apt-get install apt-transport-https curl gnupg
- ```
-
-2. Exécutez les commandes suivantes pour configurer le référentiel `deb` de Datadog sur votre système et créer un keyring d'archive Datadog :
-
- ```
- sudo sh -c "echo 'deb [signed-by=/usr/share/keyrings/datadog-archive-keyring.gpg] https://apt.datadoghq.com/ stable observability-pipelines-worker-1' > /etc/apt/sources.list.d/datadog-observability-pipelines-worker.list"
- sudo touch /usr/share/keyrings/datadog-archive-keyring.gpg
- sudo chmod a+r /usr/share/keyrings/datadog-archive-keyring.gpg
- curl https://keys.datadoghq.com/DATADOG_APT_KEY_CURRENT.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch
- curl https://keys.datadoghq.com/DATADOG_APT_KEY_F14F620E.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch
- curl https://keys.datadoghq.com/DATADOG_APT_KEY_C0962C7D.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch
- ```
-
-3. Exécutez les commandes suivantes pour mettre à jour votre référentiel `apt` local et installer le worker :
-
- ```
- sudo apt-get update
- sudo apt-get install observability-pipelines-worker datadog-signing-keys
- ```
-
-4. Ajoutez vos clés et le site ({{< region-param key="dd_site" code="true" >}}) aux variables d'environnement du worker :
-
- ```
- sudo cat <<-EOF > /etc/default/observability-pipelines-worker
- DD_API_KEY=
- DD_OP_PIPELINE_ID=
- DD_SITE=
- EOF
- ```
-
-5. Téléchargez le [fichier d'exemple de configuration][1] vers `/etc/observability-pipelines-worker/pipeline.yaml` sur le host.
-
-6. Démarrez le worker :
- ```
- sudo systemctl restart observability-pipelines-worker
- ```
-
-[1]: /resources/yaml/observability_pipelines/datadog/pipeline.yaml
-{{% /tab %}}
-{{% tab "Linux avec RPM" %}}
-1. Exécutez les commandes suivantes pour configurer le référentiel `rpm` de Datadog sur votre système :
-
- ```
- cat < /etc/yum.repos.d/datadog-observability-pipelines-worker.repo
- [observability-pipelines-worker]
- name = Observability Pipelines Worker
- baseurl = https://yum.datadoghq.com/stable/observability-pipelines-worker-1/\$basearch/
- enabled=1
- gpgcheck=1
- repo_gpgcheck=1
- gpgkey=https://keys.datadoghq.com/DATADOG_RPM_KEY_CURRENT.public
- https://keys.datadoghq.com/DATADOG_RPM_KEY_B01082D3.public
- https://keys.datadoghq.com/DATADOG_RPM_KEY_FD4BF915.public
- https://keys.datadoghq.com/DATADOG_RPM_KEY_E09422B3.public
- EOF
- ```
-
- **Remarque :** si vous exécutez RHEL 8.1 ou CentOS 8.1, utilisez `repo_gpgcheck=0` au lieu de `repo_gpgcheck=1` dans la configuration ci-dessus.
-
-2. Mettez à jour vos packages et installez le worker :
-
- ```
- sudo yum makecache
- sudo yum install observability-pipelines-worker
- ```
-
-3. Ajoutez vos clés et le site ({{< region-param key="dd_site" code="true" >}}) aux variables d'environnement du worker :
-
- ```
- sudo cat <<-EOF > /etc/default/observability-pipelines-worker
- DD_API_KEY=
- DD_OP_PIPELINE_ID=
- DD_SITE=
- EOF
- ```
-
-4. Téléchargez le [fichier d'exemple de configuration][1] vers `/etc/observability-pipelines-worker/pipeline.yaml` sur le host.
-
-5. Démarrez le worker :
- ```
- sudo systemctl restart observability-pipelines-worker
- ```
-
-[1]: /resources/yaml/observability_pipelines/datadog/pipeline.yaml
-{{% /tab %}}
-{{% tab "Terraform (AWS)" %}}
-Configurez le module du worker dans votre environnement Terraform existant en utilisant cet exemple de configuration. Remplacez les valeurs de `vpc-id`, `subnet-ids` et `region` par celles correspondant à votre déploiement AWS. Remplacez les valeurs de `datadog-api-key` et `pipeline-id` par celles correspondant à votre pipeline.
-
-```
-module "opw" {
- source = "git::https://github.com/DataDog/opw-terraform//aws"
- vpc-id = "{ID VPC}"
- subnet-ids = ["{ID SOUS-RÉSEAU 1}", "{ID SOUS-RÉSEAU 2}"]
- region = "{RÉGION}"
-
- datadog-api-key = "{CLÉ API DATADOG}"
- pipeline-id = "{ID PIPELINE OBSERVABILITÉ}"
- pipeline-config = <Les installations CloudFormation ne doivent pas être utilisées pour les charges de travail de production.
-
-Pour installer le worker dans votre compte AWS, utilisez le modèle CloudFormation pour créer une stack :
-
- 1. Téléchargez [le modèle CloudFormation][1] pour le worker.
-
- 2. Dans la **console CloudFormation**, cliquez sur **Create stack** et sélectionnez l'option **With new resources (standard)**.
-
- 3. Assurez-vous que l'option **Template is ready** est sélectionnée, puis sélectionnez **Upload a template file**. Cliquez sur **Choose file** et ajoutez le fichier du modèle CloudFormation téléchargé précédemment. Cliquez sur **Next**.
-
- 4. Saisissez un nom pour la stack dans **Specify stack details**.
-
- 5. Renseignez les paramètres du modèle CloudFormation. Certains d'entre eux nécessitent une attention particulière :
-
- * Pour `APIKey` et `PipelineID`, indiquez la clé et l'ID recueillis précédemment dans la rubrique Prérequis.
-
- * Pour `VPCID` et `SubnetIDs`, indiquez les sous-réseaux et le VPC choisis précédemment.
-
- * Tous les autres paramètres sont définis sur des valeurs par défaut adaptées à un déploiement de worker, mais vous pouvez les modifier selon vos besoins.
-
- 6. Cliquez sur **Next**.
-
- 7. Vérifiez les paramètres et assurez-vous qu'ils sont corrects. Cochez les cases des autorisations nécessaires pour IAM, puis cliquez sur **Submit** pour créer la stack.
-
-À ce stade, CloudFormation gère l'installation ; les instances du worker se lancent, téléchargent les logiciels nécessaires et s'exécutent automatiquement.
-
-[1]: /resources/yaml/observability_pipelines/cloudformation/datadog.yaml
-{{% /tab %}}
-{{< /tabs >}}
-
-### Équilibrage de charge
-
-{{< tabs >}}
-{{% tab "Docker" %}}
-La configuration en vue de la mise en production n'est pas abordée dans les instructions Docker. Reportez-vous plutôt aux normes de votre entreprise en matière d'équilibrage de charge dans les environnements conteneurisés. Si vous effectuez des tests sur votre machine locale, il n'est pas nécessaire de configurer un équilibreur de charge.
-{{% /tab %}}
-{{% tab "AWS EKS" %}}
-Utilisez les équilibreurs de charge mis à votre disposition par votre fournisseur de cloud. Ils s'ajustent en fonction des événements de mise à l'échelle automatique pour lesquels l'installation Helm par défaut est configurée. Les équilibreurs de charge sont internes et ne sont donc accessibles qu'à l'intérieur de votre réseau.
-
-Utilisez l'URL d'équilibreur de charge fournie par Helm lors de la configuration de l'Agent Datadog.
-
-Des équilibreurs de charge réseau provisionnés par le contrôleur [AWS Load Balancer Controller][1] sont utilisés.
-
-Consultez la rubrique [Planification et dimensionnement des capacités][2] pour obtenir des recommandations quant à l'équilibreur de charge lors du dimensionnement du worker.
-#### Équilibrage de charge entre zones de disponibilité
-La configuration Helm fournie tente de simplifier l'équilibrage de charge, mais vous devez prendre en compte les éventuelles implications financières du trafic entre zones de disponibilité. Dans la mesure du possible, les exemples tentent d'éviter d'engendrer des situations dans lesquelles plusieurs sauts entre zones de disponibilité peuvent se produire.
-
-Les exemples de configuration n'activent pas la fonctionnalité d'équilibrage de charge entre zones de disponibilité offerte par ce contrôleur. Pour l'activer, ajoutez l'annotation suivante au bloc `service` :
-
-```
-service.beta.kubernetes.io/aws-load-balancer-attributes: load_balancing.cross_zone.enabled=true
-```
-
-Consultez la documentation du contrôleur [AWS Load Balancer Controller][3] pour en savoir plus.
-
-[1]: https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/
-[2]: /fr/observability_pipelines/architecture/capacity_planning_scaling/
-[3]: https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/guide/service/annotations/#load-balancer-attributes
-{{% /tab %}}
-{{% tab "Azure AKS" %}}
-Utilisez les équilibreurs de charge mis à votre disposition par votre fournisseur de cloud. Ils s'ajustent en fonction des événements de mise à l'échelle automatique pour lesquels l'installation Helm par défaut est configurée. Les équilibreurs de charge sont internes et ne sont donc accessibles qu'à l'intérieur de votre réseau.
-
-Utilisez l'URL d'équilibreur de charge fournie par Helm lors de la configuration de l'Agent Datadog.
-
-Consultez la rubrique [Planification et dimensionnement des capacités][1] pour obtenir des recommandations quant à l'équilibreur de charge lors du dimensionnement du worker.
-
-#### Équilibrage de charge entre zones de disponibilité
-La configuration Helm fournie tente de simplifier l'équilibrage de charge, mais vous devez prendre en compte les éventuelles implications financières du trafic entre zones de disponibilité. Dans la mesure du possible, les exemples tentent d'éviter d'engendrer des situations dans lesquelles plusieurs sauts entre zones de disponibilité peuvent se produire.
-
-[1]: /fr/observability_pipelines/architecture/capacity_planning_scaling/
-{{% /tab %}}
-{{% tab "Google GKE" %}}
-Utilisez les équilibreurs de charge mis à votre disposition par votre fournisseur de cloud. Ils s'ajustent en fonction des événements de mise à l'échelle automatique pour lesquels l'installation Helm par défaut est configurée. Les équilibreurs de charge sont internes et ne sont donc accessibles qu'à l'intérieur de votre réseau.
-
-Utilisez l'URL d'équilibreur de charge fournie par Helm lors de la configuration de l'Agent Datadog.
-
-Consultez la rubrique [Planification et dimensionnement des capacités][1] pour obtenir des recommandations quant à l'équilibreur de charge lors du dimensionnement du worker.
-
-#### Équilibrage de charge entre zones de disponibilité
-La configuration Helm fournie tente de simplifier l'équilibrage de charge, mais vous devez prendre en compte les éventuelles implications financières du trafic entre zones de disponibilité. Dans la mesure du possible, les exemples tentent d'éviter d'engendrer des situations dans lesquelles plusieurs sauts entre zones de disponibilité peuvent se produire.
-
-L'accès global est activé par défaut dans la mesure où cela est probablement nécessaire pour une utilisation dans un cluster d'outils partagés.
-
-[1]: /fr/observability_pipelines/architecture/capacity_planning_scaling/
-{{% /tab %}}
-{{% tab "Linux avec APT" %}}
-L'équilibrage de charge n'est pas pris en charge par défaut en raison de la nature de l'installation (une seule machine). Il vous faudra provisionner vos propres équilibreurs de charge en suivant les normes de votre entreprise.
-{{% /tab %}}
-{{% tab "Linux avec RPM" %}}
-L'équilibrage de charge n'est pas pris en charge par défaut en raison de la nature de l'installation (une seule machine). Il vous faudra provisionner vos propres équilibreurs de charge en suivant les normes de votre entreprise.
-{{% /tab %}}
-{{% tab "Terraform (AWS)" %}}
-Un équilibreur de charge réseau est provisionné par le module Terraform ; il est configuré pour pointer vers les instances. Son adresse DNS est renvoyée dans la sortie `lb-dns` dans Terraform.
-{{% /tab %}}
-{{% tab "CloudFormation" %}}
-
-
Les installations CloudFormation ne doivent pas être utilisées pour les charges de travail de production.
-
-Un équilibreur de charge réseau est provisionné par le modèle CloudFormation ; il est configuré pour pointer vers le groupe de mise à l'échelle automatique. Son adresse DNS est renvoyée dans la sortie `LoadBalancerDNS` de CloudFormation.
-{{% /tab %}}
-{{< /tabs >}}
-
-### Mise en mémoire tampon
-Les pipelines d'observabilité proposent plusieurs stratégies de mise en mémoire tampon qui vous permettent d'augmenter la résilience de votre cluster aux erreurs en aval. Les exemples de configuration fournis utilisent des buffers disque, dont les capacités sont prévues pour environ 10 minutes de données à 10 Mbit/s/cœur pour les déploiements de pipelines d'observabilité. Cela laisse généralement suffisamment de temps pour que les problèmes transitoires se résolvent d'eux-mêmes, ou pour que les intervenants décident de ce qu'ils souhaitent faire des données d'observabilité.
-
-{{< tabs >}}
-{{% tab "Docker" %}}
-Par défaut, le répertoire de données du worker de pipelines d'observabilité est défini sur `/var/lib/observability-pipelines-worker`. Assurez-vous qu'une capacité de stockage suffisante est allouée au point de montage du conteneur sur la machine du host.
-{{% /tab %}}
-{{% tab "AWS EKS" %}}
-Pour AWS, Datadog conseille d'utiliser des disques EBS `io2`. Il est également possible d'utiliser des disques `gp3`.
-{{% /tab %}}
-{{% tab "Azure AKS" %}}
-Pour Azure AKS, Datadog conseille d'utiliser les disques `default` (également appelés `managed-csi`).
-{{% /tab %}}
-{{% tab "Google GKE" %}}
-Pour Google GKE, Datadog conseille d'utiliser la classe de disque `premium-rwo`, car elle repose sur des SSD. La classe `standard-rwo`, qui repose sur des disques durs mécaniques, risque de ne pas offrir une vitesse d'écriture suffisamment élevée pour garantir l'efficacité des buffers.
-{{% /tab %}}
-{{% tab "Linux avec APT" %}}
-Par défaut, le répertoire de données du worker de pipelines d'observabilité est défini sur `/var/lib/observability-pipelines-worker`. Si vous utilisez l'exemple de configuration, assurez-vous qu'un espace d'au moins 288 Go est disponible pour la mise en mémoire tampon.
-
-Lorsque cela est possible, il est conseillé de monter un SSD dédié à cet emplacement.
-{{% /tab %}}
-{{% tab "Linux avec RPM" %}}
-Par défaut, le répertoire de données du worker de pipelines d'observabilité est défini sur `/var/lib/observability-pipelines-worker`. Si vous utilisez l'exemple de configuration, assurez-vous qu'un espace d'au moins 288 Go est disponible pour la mise en mémoire tampon.
-
-Lorsque cela est possible, il est conseillé de monter un SSD dédié à cet emplacement.
-{{% /tab %}}
-{{% tab "Terraform (AWS)" %}}
-Par défaut, un disque EBS de 288 Go est alloué à chaque instance, et l'exemple de configuration ci-dessus utilise cet espace pour la mise en mémoire tampon.
-{{% /tab %}}
-{{% tab "CloudFormation" %}}
-
-
Le cycle de vie des disques EBS créés par ce modèle CloudFormation est lié à l'instance avec laquelle ils sont créés. Par conséquent, si une instance est fermée, par exemple par le groupe de mise à l'échelle automatique, cela entraîne une perte de données. C'est pourquoi les installations CloudFormation ne doivent pas être utilisées pour les charges de travail de production.
-
-Par défaut, un disque EBS de 288 Go est alloué à chaque instance ; il est monté automatiquement et formaté à l'initialisation de celle-ci.
-{{% /tab %}}
-{{< /tabs >}}
-
-## Connecter l'Agent Datadog au worker de pipelines d'observabilité
-Pour envoyer les logs et les métriques de l'Agent Datadog au worker de pipelines d'observabilité, mettez à jour la configuration de l'Agent comme suit :
-
-```yaml
-observability_pipelines_worker:
- logs:
- enabled: true
- url: "http://:8282"
- metrics:
- enabled: true
- url: "http://:8282"
-
-```
-
-`OPW_HOST` correspond à l'adresse IP de l'équilibreur de charge ou de la machine configurée précédemment. Pour les installations Docker à un seul host, il s'agit de l'adresse IP du host sous-jacent. Pour les installations Kubernetes, vous pouvez la récupérer en exécutant la commande suivante et en copiant la valeur de `EXTERNAL-IP` :
-
-```shell
-kubectl get svc opw-observability-pipelines-worker
-```
-
-Pour les installations Terraform, la sortie `lb-dns` fournit la valeur requise. Pour les installations CloudFormation, l'URL à utiliser est fournie dans la sortie `LoadBalancerDNS`.
-
-À ce stade, vos données d'observabilité devraient être transmises au worker et prêtes à être traitées. La rubrique suivante présente les étapes de traitement incluses par défaut ainsi que les options supplémentaires qui s'offrent à vous.
-
-## Utilisation des données
-L'exemple de configuration fourni intègre des exemples d'étape de configuration qui exploitent les outils des pipelines d'observabilité et garantit que les données sont envoyées à Datadog dans le format approprié.
-
-### Traitement des logs
-L'exemple de configuration des pipelines d'observabilité prévoit les opérations suivantes :
-- Collecte des logs envoyés au worker de pipelines d'observabilité par l'Agent Datadog.
-- Application de tags aux logs traités par le worker de pipelines d'observabilité. Cela permet de déterminer quel trafic doit encore être transmis au worker à mesure que vous mettez à jour vos clusters. Ces tags vous montrent également comment les logs sont acheminés via l'équilibreur de charge, en cas de déséquilibres.
-- Correction du statut des logs traités par le worker. En raison de la façon dont l'Agent Datadog collecte les logs à partir des conteneurs, l'attribut `.status` fourni ne reflète pas correctement le véritable niveau du message. Il convient donc de le supprimer pour éviter tout problème au niveau des règles de parsing dans le backend, où sont reçus les logs envoyés par le worker.
-- Acheminement des logs par transmission multiple des données aux endpoints d'ingestion des métriques et des logs de Datadog.
-
-Les étapes suivantes constituent deux composants importants de l'exemple de configuration :
-- `logs_parse_ddtags` : parse les tags stockés dans une chaîne pour générer un ensemble de données structuré.
-- `logs_finish_ddtags` : réencode les tags de sorte qu'ils soient dans le format qu'utiliserait l'Agent Datadog pour leur envoi.
-
-En interne, l'Agent Datadog représente les tags des logs au format CSV dans une seule et même chaîne. Pour pouvoir manipuler efficacement ces tags, il convient de les parser, de les modifier puis de les réencoder avant leur envoi à l'endpoint d'ingestion. Ces étapes sont conçues pour effectuer automatiquement ces actions pour vous. Toute modification du pipeline, en particulier au niveau de la manipulation des tags, doit être apportée entre ces deux étapes.
-
-### Traitement des métriques
-Le pipeline des métriques fourni ne nécessite pas d'étapes de parsing et de réencodage supplémentaires. À l'instar du pipeline des logs, il applique des tags aux métriques entrantes pour la prise en compte du trafic. Cette cardinalité supplémentaire peut avoir un impact financier pour les métriques personnalisées.
-
-À ce stade, votre environnement est configuré pour les pipelines d'observabilité et les données leur sont transmises. Il est probable que vous deviez adapter la configuration à vos besoins spécifiques, mais les outils fournis ici vous offrent un bon point de départ.
-
-## Pour aller plus loin
-{{< partial name="whats-next/whats-next.html" >}}
-
-
-[1]: /fr/observability_pipelines/#what-is-observability-pipelines-and-the-observability-pipelines-worker
-[2]: /fr/account_management/api-app-keys/#api-keys
-[3]: https://app.datadoghq.com/observability-pipelines/create
\ No newline at end of file
diff --git a/content/fr/observability_pipelines/setup/datadog_with_archiving.md b/content/fr/observability_pipelines/setup/datadog_with_archiving.md
deleted file mode 100644
index f76798a435cd1..0000000000000
--- a/content/fr/observability_pipelines/setup/datadog_with_archiving.md
+++ /dev/null
@@ -1,554 +0,0 @@
----
-further_reading:
-- link: /observability_pipelines/production_deployment_overview/
- tag: Documentation
- text: Conception et principes de déploiement en production du worker de pipelines
- d'observabilité
-- link: https://dtdg.co/d22op
- tag: Centre d'apprentissage
- text: Traitement en local sécurisé à l'aide de pipelines d'observabilité
-kind: Documentation
-title: Configurer des pipelines d'observabilité pour envoyer des logs dans un format
- réintégrable à Datadog vers Amazon S3 et Datadog
----
-
-{{< site-region region="gov" >}}
-
Les pipelines d'observabilité ne sont pas disponibles sur le site US1-FED de Datadog.
-{{< /site-region >}}
-
-## Présentation
-
-Le [worker de pipelines d'observabilité][1] peut collecter et traiter les logs et les métriques de n'importe quelle source et les acheminer vers n'importe quelle destination. Datadog vous permet de concevoir et de gérer tous vos déploiements de worker de pipelines d'observabilité de façon évolutive.
-
-Ce guide explique comment déployer le worker dans votre cluster d'outils communs et le configurer pour qu'il envoie les logs dans un format réintégrable à Datadog vers un service de stockage dans le cloud à des fins d'archivage.
-
-## Hypothèses
-* Vous utilisez déjà Datadog et voulez utiliser des pipelines d'observabilité.
-* Vous bénéficiez d'un accès administrateur aux clusters dans lesquels le worker de pipelines d'observabilité va être déployé, ainsi qu'aux charges de travail qui vont être agrégées.
-* Vous disposez dans votre environnement d'un cluster d'outils communs ou de sécurité auquel tous les autres clusters sont connectés.
-
-## Prérequis
-Avant de procéder à l'installation, assurez-vous que vous disposez des éléments suivants :
-
-* Une [clé d'API Datadog][2] valide.
-* Un ID de pipeline.
-
-Vous pouvez générer ces deux éléments dans [Observability Pipelines][3].
-
-### Exigences propres au fournisseur
-{{< tabs >}}
-{{% tab "Docker" %}}
-Assurez-vous que votre machine est configurée pour exécuter Docker.
-
-{{% /tab %}}
-{{% tab "AWS EKS" %}}
-
-Pour exécuter le worker sur vos nœuds Kubernetes, vous devez disposer au minimum de deux nœuds avec un processeur et 512 Mo de mémoire RAM disponibles. Datadog vous conseille de créer un pool de nœuds distinct pour les workers, ce qui correspond également à la configuration conseillée pour les déploiements en production.
-
-* Le [pilote EBS CSI][1] est requis. Pour savoir s'il est installé, exécutez la commande suivante et recherchez `ebs-csi-controller` dans la liste :
-
- ```shell
- kubectl get pods -n kube-system
- ```
-
-* Une `StorageClass` est requise pour que les workers provisionnent les disques EBS adéquats. Pour savoir si elle est déjà installée, exécutez la commande suivante et recherchez `io2` dans la liste :
-
- ```shell
- kubectl get storageclass
- ```
-
- Si `io2` ne figure pas dans la liste, téléchargez [le fichier YAML StorageClass][2] et exécutez la commande `kubectl apply` pour l'appliquer.
-
-* Le contrôleur [AWS Load Balancer Controller][3] est requis. Pour savoir s'il est installé, exécutez la commande suivante et recherchez `aws-load-balancer-controller` dans la liste :
-
- ```shell
- helm list -A
- ```
-* Datadog vous conseille d'utiliser la version 1.16 ou supérieure d'Amazon EKS.
-
-Consultez la section [Meilleures pratiques pour l'architecture de l'agrégateur OPW][4] pour connaître les exigences au niveau production.
-
-[1]: https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html
-[2]: /resources/yaml/observability_pipelines/helm/storageclass.yaml
-[3]: https://docs.aws.amazon.com/eks/latest/userguide/aws-load-balancer-controller.html
-[6]: /fr/observability_pipelines/architecture/
-
-{{% /tab %}}
-{{% tab "Linux avec APT" %}}
-
-Il n'y a aucune exigence propre au fournisseur pour les distributions Linux utilisant APT.
-
-{{% /tab %}}
-{{% tab "Linux avec RPM" %}}
-
-Il n'y a aucune exigence propre au fournisseur pour les distributions Linux utilisant APT.
-
-{{% /tab %}}
-{{% tab "Terraform (AWS)" %}}
-
-Pour exécuter le worker dans votre compte AWS, vous devez bénéficier d'un accès administrateur à ce dernier et disposer des informations suivantes :
-
-* L'ID du VPC dans lequel s'exécuteront vos instances.
-* Les ID des sous-réseaux dans lesquels s'exécuteront vos instances.
-* La région AWS dans laquelle se trouve votre VPC.
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## Configurer les archives de logs
-
-Lors de l'[installation du worker de pipelines d'observabilité](#installer-le-worker-de-pipelines-d-observabilite), l'exemple de configuration fourni inclut un récepteur pour l'envoi des logs vers Amazon S3 dans un format réintégrable à Datadog. Pour utiliser cette configuration, vous devez créer un compartiment S3 pour vos archives et configurer une stratégie IAM permettant aux workers d'écrire dans ce dernier. Il vous faudra ensuite connecter le compartiment S3 aux archives de logs Datadog.
-
-{{% site-region region="us,us3,us5" %}}
-Consultez la [tarification AWS][1] pour connaître les frais de transfert de données entre régions et déterminer l'impact éventuel sur vos frais de stockage dans le cloud.
-
-[1]: https://aws.amazon.com/s3/pricing/
-{{< /site-region >}}
-
-### Créer un compartiment S3 et configurer une stratégie IAM
-
-{{< tabs >}}
-{{% tab "Docker" %}}
-
-{{% op-datadog-archives-s3-setup %}}
-
-3. Créez un utilisateur IAM et associez-lui la stratégie ci-dessus. Créez des identifiants d'accès pour cet utilisateur IAM. Enregistrez-les sous `AWS_ACCESS_KEY` et `AWS_SECRET_ACCESS_KEY`.
-
-{{% /tab %}}
-{{% tab "AWS EKS" %}}
-
-{{% op-datadog-archives-s3-setup %}}
-
-3. [Créez un compte de service][1] pour utiliser la stratégie créée ci-dessus.
-
-[1]: https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html
-
-{{% /tab %}}
-{{% tab "Linux avec APT" %}}
-
-{{% op-datadog-archives-s3-setup %}}
-
-3. Créez un utilisateur IAM et associez-lui la stratégie ci-dessus. Créez des identifiants d'accès pour cet utilisateur IAM. Enregistrez-les sous `AWS_ACCESS_KEY` et `AWS_SECRET_ACCESS_KEY`.
-
-{{% /tab %}}
-{{% tab "Linux avec RPM" %}}
-
-{{% op-datadog-archives-s3-setup %}}
-
-3. Créez un utilisateur IAM et associez-lui la stratégie ci-dessus. Créez des identifiants d'accès pour cet utilisateur IAM. Enregistrez-les sous `AWS_ACCESS_KEY_ID` et `AWS_SECRET_ACCESS_KEY`.
-
-{{% /tab %}}
-{{% tab "Terraform (AWS)" %}}
-
-{{% op-datadog-archives-s3-setup %}}
-
-3. Associez la stratégie au profil d'instance IAM créé avec Terraform, qui est indiqué dans la sortie `iam-role-name`.
-
-{{% /tab %}}
-{{< /tabs >}}
-
-### Connecter le compartiment S3 aux archives de logs Datadog
-
-Vous devez connecter le compartiment S3 créé précédemment aux archives de logs Datadog afin de pouvoir réintégrer ultérieurement les archives.
-
-1. Accédez à la page [Log Forwarding][5] de Datadog.
-1. Cliquez sur **+ New Archive**.
-1. Saisissez un nom décrivant l'archive.
-1. Ajoutez une requête excluant tous les logs traités par les pipelines de logs afin qu'ils ne soient pas intégrés à cette archive. Par exemple, ajoutez la requête `observability_pipelines_read_only_archive`, en supposant que ce tag n'ait pas été ajouté aux logs traités par le pipeline.
-1. Sélectionnez **AWS S3**.
-1. Sélectionnez le compte AWS dans lequel se trouve votre compartiment.
-1. Saisissez le nom du compartiment S3.
-1. Si besoin, saisissez un chemin.
-1. Vérifiez la déclaration de confirmation.
-1. Si besoin, ajoutez des tags et définissez la taille d'analyse maximale pour la réintégration. Consultez la rubrique [Paramètres avancés][6] pour en savoir plus.
-1. Cliquez sur **Save**.
-
-Consultez la [documentation relative aux archives de logs][7] pour en savoir plus.
-
-## Installer le worker de pipelines d'observabilité
-
-{{< tabs >}}
-{{% tab "Docker" %}}
-
-L'image Docker du worker de pipelines d'observabilité est disponible sur Docker Hub [ici][1].
-
-1. Téléchargez le [fichier d'exemple de configuration de pipeline][2].
-
-2. Exécutez la commande suivante pour démarrer le worker de pipelines d'observabilité avec Docker :
-
- ```shell
- docker run -i -e DD_API_KEY= \
- -e DD_OP_PIPELINE_ID= \
- -e DD_SITE= \
- -e AWS_ACCESS_KEY_ID= \
- -e AWS_SECRET_ACCESS_KEY= \
- -e DD_ARCHIVES_BUCKET= \
- -e DD_ARCHIVES_SERVICE_ACCOUNT= \
- -p 8282:8282 \
- -v ./pipeline.yaml:/etc/observability-pipelines-worker/pipeline.yaml:ro \
- datadog/observability-pipelines-worker run
- ```
-
- Remplacez les paramètres fictifs suivants par les valeurs appropriées :
- - `` par votre clé d'API Datadog.
- - `` par votre ID de configuration de pipeline d'observabilité.
- - `` par {{< region-param key="dd_site" code="true" >}}.
- - `AWS_ACCESS_KEY_ID` et `AWS_SECRET_ACCESS_KEY` par les identifiants AWS créés précédemment.
- - `` par le nom du compartiment S3 utilisé pour le stockage des logs.
- - `` par la [région AWS][3] du service cible.
- - `./pipeline.yaml` doit correspondre au chemin relatif ou absolu du fichier de configuration que vous avez téléchargé à l'étape 1.
-
-[1]: https://hub.docker.com/r/datadog/observability-pipelines-worker
-[2]: /resources/yaml/observability_pipelines/archives/pipeline.yaml
-[3]: https://docs.aws.amazon.com/general/latest/gr/rande.html#regional-endpoints
-{{% /tab %}}
-{{% tab "AWS EKS" %}}
-1. Téléchargez le [chart Helm][1] pour AWS EKS.
-
-2. Dans le chart Helm, remplacez les paramètres fictifs suivants par les valeurs appropriées :
- - `datadog.apiKey` par votre clé d'API Datadog.
- - `datadog.pipelineId` par votre ID de configuration de pipeline d'observabilité.
- - `site` par {{< region-param key="dd_site" code="true" >}}.
- - `${DD_ARCHIVES_SERVICE_ACCOUNT}` dans `serviceAccount.name` par le nom du compte de service.
- - `${DD_ARCHIVES_BUCKET}` dans `pipelineConfig.sinks.datadog_archives` par le nom du compartiment S3 utilisé pour le stockage des logs.
- - `${DD_ARCHIVES_SERVICE_ACCOUNT}` dans `pipelineConfig.sinks.datadog_archives` par la [région AWS][2] du service cible.
-
-3. Installez le chart dans votre cluster en exécutant les commandes suivantes :
-
- ```shell
- helm repo add datadog https://helm.datadoghq.com
- ```
- ```shell
- helm repo update
- ```
- ```shell
- helm upgrade --install \
- opw datadog/observability-pipelines-worker \
- -f aws_eks.yaml
- ```
-
-[1]: /resources/yaml/observability_pipelines/archives/aws_eks.yaml
-[2]: https://docs.aws.amazon.com/general/latest/gr/rande.html#regional-endpoints
-{{% /tab %}}
-
-{{% tab "Linux avec APT" %}}
-1. Exécutez les commandes suivantes pour configurer APT de sorte que les téléchargements se fassent via le protocole HTTPS :
-
- ```
- sudo apt-get update
- sudo apt-get install apt-transport-https curl gnupg
- ```
-
-2. Exécutez les commandes suivantes pour configurer le référentiel `deb` de Datadog sur votre système et créer un keyring d'archive Datadog :
-
- ```
- sudo sh -c "echo 'deb [signed-by=/usr/share/keyrings/datadog-archive-keyring.gpg] https://apt.datadoghq.com/ stable observability-pipelines-worker-1' > /etc/apt/sources.list.d/datadog-observability-pipelines-worker.list"
- sudo touch /usr/share/keyrings/datadog-archive-keyring.gpg
- sudo chmod a+r /usr/share/keyrings/datadog-archive-keyring.gpg
- curl https://keys.datadoghq.com/DATADOG_APT_KEY_CURRENT.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch
- curl https://keys.datadoghq.com/DATADOG_APT_KEY_F14F620E.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch
- curl https://keys.datadoghq.com/DATADOG_APT_KEY_C0962C7D.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch
- ```
-
-3. Exécutez les commandes suivantes pour mettre à jour votre référentiel `apt` local et installer le worker :
-
- ```
- sudo apt-get update
- sudo apt-get install observability-pipelines-worker datadog-signing-keys
- ```
-
-4. Ajoutez vos clés et le site ({{< region-param key="dd_site" code="true" >}}) aux variables d'environnement du worker. Remplacez `` par le nom du compartiment S3 utilisé pour le stockage des logs et `` par la [région AWS][2] du service cible.
-
- ```
- sudo cat <<-EOF > /etc/default/observability-pipelines-worker
- AWS_ACCESS_KEY_ID=
- AWS_SECRET_ACCESS_KEY=
- DD_ARCHIVES_BUCKET=
- DD_ARCHIVES_SERVICE_ACCOUNT=
- EOF
- ```
-
-5. Téléchargez le [fichier d'exemple de configuration][1] vers `/etc/observability-pipelines-worker/pipeline.yaml` sur le host.
-
-6. Démarrez le worker :
- ```
- sudo systemctl restart observability-pipelines-worker
- ```
-
-[1]: /resources/yaml/observability_pipelines/archives/pipeline.yaml
-[2]: https://docs.aws.amazon.com/general/latest/gr/rande.html#regional-endpoints
-{{% /tab %}}
-{{% tab "Linux avec RPM" %}}
-1. Exécutez les commandes suivantes pour configurer le référentiel `rpm` de Datadog sur votre système :
-
- ```
- cat < /etc/yum.repos.d/datadog-observability-pipelines-worker.repo
- [observability-pipelines-worker]
- name = Observability Pipelines Worker
- baseurl = https://yum.datadoghq.com/stable/observability-pipelines-worker-1/\$basearch/
- enabled=1
- gpgcheck=1
- repo_gpgcheck=1
- gpgkey=https://keys.datadoghq.com/DATADOG_RPM_KEY_CURRENT.public
- https://keys.datadoghq.com/DATADOG_RPM_KEY_B01082D3.public
- https://keys.datadoghq.com/DATADOG_RPM_KEY_FD4BF915.public
- https://keys.datadoghq.com/DATADOG_RPM_KEY_E09422B3.public
- EOF
- ```
-
- **Remarque :** si vous exécutez RHEL 8.1 ou CentOS 8.1, utilisez `repo_gpgcheck=0` au lieu de `repo_gpgcheck=1` dans la configuration ci-dessus.
-
-2. Mettez à jour vos packages et installez le worker :
-
- ```
- sudo yum makecache
- sudo yum install observability-pipelines-worker
- ```
-
-3. Ajoutez vos clés et le site ({{< region-param key="dd_site" code="true" >}}) aux variables d'environnement du worker. Remplacez `` par le nom du compartiment S3 utilisé pour le stockage des logs et `` par la [région AWS][2] du service cible.
-
- ```
- sudo cat <<-EOF > /etc/default/observability-pipelines-worker
- AWS_ACCESS_KEY_ID=
- AWS_SECRET_ACCESS_KEY=
- DD_ARCHIVES_BUCKET=
- DD_ARCHIVES_SERVICE_ACCOUNT=
- EOF
- ```
-
-4. Téléchargez le [fichier d'exemple de configuration][1] vers `/etc/observability-pipelines-worker/pipeline.yaml` sur le host.
-
-5. Démarrez le worker :
- ```
- sudo systemctl restart observability-pipelines-worker
- ```
-
-[1]: /resources/yaml/observability_pipelines/archives/pipeline.yaml
-[2]: https://docs.aws.amazon.com/general/latest/gr/rande.html#regional-endpoints
-{{% /tab %}}
-{{% tab "Terraform (AWS)" %}}
-Configurez le module du worker dans votre environnement Terraform existant en utilisant cet exemple de configuration. Remplacez les valeurs de `vpc-id`, `subnet-ids` et `region` par celles correspondant à votre déploiement AWS. Remplacez les valeurs de `datadog-api-key` et `pipeline-id` par celles correspondant à votre pipeline.
-
-```
-module "opw" {
- source = "git::https://github.com/DataDog/opw-terraform//aws"
- vpc-id = "{ID VPC}"
- subnet-ids = ["{ID SOUS-RÉSEAU 1}", "{ID SOUS-RÉSEAU 2}"]
- region = "{RÉGION}"
-
- datadog-api-key = "{CLÉ API DATADOG}"
- pipeline-id = "{ID PIPELINE OBSERVABILITÉ}"
- pipeline-config = <}}
-
-### Équilibrage de charge
-
-{{< tabs >}}
-{{% tab "Docker" %}}
-La configuration en vue de la mise en production n'est pas abordée dans les instructions Docker. Reportez-vous plutôt aux normes de votre entreprise en matière d'équilibrage de charge dans les environnements conteneurisés. Si vous effectuez des tests sur votre machine locale, il n'est pas nécessaire de configurer un équilibreur de charge.
-{{% /tab %}}
-{{% tab "AWS EKS" %}}
-Utilisez les équilibreurs de charge mis à votre disposition par votre fournisseur de cloud. Ils s'ajustent en fonction des événements de mise à l'échelle automatique pour lesquels l'installation Helm par défaut est configurée. Les équilibreurs de charge sont internes et ne sont donc accessibles qu'à l'intérieur de votre réseau.
-
-Utilisez l'URL d'équilibreur de charge fournie par Helm lors de la configuration de l'Agent Datadog.
-
-Des équilibreurs de charge réseau provisionnés par le contrôleur [AWS Load Balancer Controller][1] sont utilisés.
-
-Consultez la rubrique [Planification et dimensionnement des capacités][2] pour obtenir des recommandations quant à l'équilibreur de charge lors du dimensionnement du worker.
-#### Équilibrage de charge entre zones de disponibilité
-La configuration Helm fournie tente de simplifier l'équilibrage de charge, mais vous devez prendre en compte les éventuelles implications financières du trafic entre zones de disponibilité. Dans la mesure du possible, les exemples tentent d'éviter d'engendrer des situations dans lesquelles plusieurs sauts entre zones de disponibilité peuvent se produire.
-
-Les exemples de configuration n'activent pas la fonctionnalité d'équilibrage de charge entre zones de disponibilité offerte par ce contrôleur. Pour l'activer, ajoutez l'annotation suivante au bloc `service` :
-
-```
-service.beta.kubernetes.io/aws-load-balancer-attributes: load_balancing.cross_zone.enabled=true
-```
-
-Consultez la documentation du contrôleur [AWS Load Balancer Controller][3] pour en savoir plus.
-
-[1]: https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/
-[2]: /fr/observability_pipelines/architecture/capacity_planning_scaling/
-[3]: https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/guide/service/annotations/#load-balancer-attributes
-{{% /tab %}}
-
-{{% tab "Linux avec APT" %}}
-En raison de la nature de l'installation (une seule machine), l'équilibrage de charge n'est pas pris en charge par défaut. Vous devez provisionner vos propres équilibreurs de charge en suivant les normes de votre entreprise.
-{{% /tab %}}
-{{% tab "Linux avec RPM" %}}
-En raison de la nature de l'installation (une seule machine), l'équilibrage de charge n'est pas pris en charge par défaut. Vous devez provisionner vos propres équilibreurs de charge en suivant les normes de votre entreprise.
-{{% /tab %}}
-{{% tab "Terraform (AWS)" %}}
-Le module Terraform provisionne un équilibreur de charge réseau configuré pour pointer vers les instances. Son adresse DNS est renvoyée dans la sortie `lb-dns` dans Terraform.
-{{% /tab %}}
-{{< /tabs >}}
-
-### Mise en mémoire tampon
-Les pipelines d'observabilité proposent plusieurs stratégies de mise en mémoire tampon qui vous permettent d'augmenter la résilience de votre cluster aux erreurs en aval. Les exemples de configuration fournis utilisent des buffers disque, dont les capacités sont prévues pour environ 10 minutes de données à 10 Mbit/s/cœur pour les déploiements de pipelines d'observabilité. Cela laisse généralement suffisamment de temps pour que les problèmes transitoires se résolvent d'eux-mêmes, ou pour que les intervenants décident de ce qu'ils souhaitent faire des données d'observabilité.
-
-{{< tabs >}}
-{{% tab "Docker" %}}
-Par défaut, le répertoire de données du worker de pipelines d'observabilité est défini sur `/var/lib/observability-pipelines-worker`. Assurez-vous qu'une capacité de stockage suffisante est allouée au point de montage du conteneur sur la machine du host.
-{{% /tab %}}
-{{% tab "AWS EKS" %}}
-Pour AWS, Datadog conseille d'utiliser des disques EBS `io2`. Il est également possible d'utiliser des disques `gp3`.
-{{% /tab %}}
-{{% tab "Linux avec APT" %}}
-Par défaut, le répertoire de données du worker de pipelines d'observabilité est défini sur `/var/lib/observability-pipelines-worker`. Si vous utilisez l'exemple de configuration, assurez-vous qu'un espace d'au moins 288 Go est disponible pour la mise en mémoire tampon.
-
-Lorsque cela est possible, il est conseillé de monter un SSD dédié à cet emplacement.
-{{% /tab %}}
-{{% tab "Linux avec RPM" %}}
-Par défaut, le répertoire de données du worker de pipelines d'observabilité est défini sur `/var/lib/observability-pipelines-worker`. Si vous utilisez l'exemple de configuration, assurez-vous qu'un espace d'au moins 288 Go est disponible pour la mise en mémoire tampon.
-
-Lorsque cela est possible, il est conseillé de monter un SSD dédié à cet emplacement.
-{{% /tab %}}
-{{% tab "Terraform (AWS)" %}}
-Par défaut, un disque EBS de 288 Go est alloué à chaque instance, et l'exemple de configuration ci-dessus utilise cet espace pour la mise en mémoire tampon.
-{{% /tab %}}
-{{< /tabs >}}
-
-## Connecter l'Agent Datadog au worker de pipelines d'observabilité
-Pour envoyer les logs et les métriques de l'Agent Datadog au worker de pipelines d'observabilité, mettez à jour la configuration de l'Agent comme suit :
-
-```yaml
-observability_pipelines_worker:
- logs:
- enabled: true
- url: "http://:8282"
- metrics:
- enabled: true
- url: "http://:8282"
-
-```
-
-`OPW_HOST` correspond à l'adresse IP de l'équilibreur de charge ou de la machine configurée précédemment. Pour les installations Docker à un seul host, il s'agit de l'adresse IP du host sous-jacent. Pour les installations Kubernetes, vous pouvez la récupérer en exécutant la commande suivante et en copiant la valeur de `EXTERNAL-IP` :
-
-```shell
-kubectl get svc opw-observability-pipelines-worker
-```
-
-Pour les installations Terraform, la sortie `lb-dns` fournit la valeur requise.
-
-À ce stade, vos données d'observabilité devraient être transmises au worker puis envoyées à votre archive S3.
-
-## Réintégrer vos archives
-
-Consultez la rubrique [Réintégration à partir des archives][4] pour savoir comment réintégrer votre archive dans Datadog afin de pouvoir commencer à analyser et étudier ces logs.
-
-## Pour aller plus loin
-{{< partial name="whats-next/whats-next.html" >}}
-
-[1]: /fr/observability_pipelines/#what-is-observability-pipelines-and-the-observability-pipelines-worker
-[2]: /fr/account_management/api-app-keys/#api-keys
-[3]: https://app.datadoghq.com/observability-pipelines/create
-[4]: /fr/logs/log_configuration/rehydrating/
-[5]: https://app.datadoghq.com/logs/pipelines/log-forwarding
-[6]: /fr/logs/log_configuration/archives/#advanced-settings
-[7]: /fr/logs/log_configuration/archives
\ No newline at end of file
diff --git a/content/fr/observability_pipelines/troubleshooting.md b/content/fr/observability_pipelines/troubleshooting.md
deleted file mode 100644
index 6b8a1cd5a111a..0000000000000
--- a/content/fr/observability_pipelines/troubleshooting.md
+++ /dev/null
@@ -1,98 +0,0 @@
----
-disable_toc: false
-further_reading:
-- link: /observability_pipelines/monitoring/
- tag: Documentation
- text: Surveiller l'intégrité de vos pipelines
-kind: documentation
-title: Dépannage
----
-
-{{< site-region region="gov" >}}
-
Les pipelines d'observabilité ne sont pas disponibles sur le site US1-FED de Datadog.
-{{< /site-region >}}
-
-## Présentation
-Si les pipelines d'observabilité Datadog se comportent de manière inattendue, consultez ce guide pour passer en revue les problèmes courants et suivre les solutions proposées. Si vous ne parvenez pas à résoudre votre problème, contactez l'[assistance Datadog][3] pour obtenir de l'aide.
-
-## Analyser les logs de diagnostic
-
-Le worker de pipelines d'observabilité génère des logs internes concernant sa propre santé. Dans l'interface des pipelines d'observabilité, vous pouvez analyser n'importe quel log d'erreur interne généré par le processus du worker pour chacun de ses composants. Pour afficher ces logs de diagnostic, procédez comme suit :
-
-1. Accédez à la page [Observability Pipelines][1].
-1. Cliquez sur le pipeline que vous souhaitez analyser.
-1. Cliquez sur un composant pour afficher le volet latéral correspondant.
-1. Cliquez sur l'onglet **Diagnostic Logs** pour afficher les logs d'erreur générés par le worker. Cliquez sur une entrée de log pour l'analyser dans le Log Explorer. Si aucun log n'est affiché, le composant n'a généré aucun log d'erreur.
-
-### Obtenir des logs plus détaillés
-
-Si vous avez besoin d'informations plus détaillées que celles figurant dans les logs internes générés par le worker des pipelines d'observabilité, vous pouvez augmenter le niveau des logs à l'aide de la variable d'environnement `VECTOR_LOG`. Par défaut, celle-ci est définie sur `INFO`, ce qui signifie que les messages `INFO`, `WARNING` et `ERROR` sont affichés dans la console.
-
-La valeur `DEBUG` vous permet d'obtenir des informations plus détaillées sur les processus internes du worker (notamment les requêtes HTTP envoyées et les réponses reçues). L'assistance Datadog peut vous demander de fournir des logs `DEBUG` afin de faciliter la résolution de vos problèmes. Ces logs figurent également dans le Log Explorer et les [logs de diagnostic](#analyser-les-logs-de-diagnostic).
-
-## Étudier les événements passant par votre pipeline pour identifier les problèmes de configuration
-
-Si vous utilisez la version 1.4.0+ du worker des pipelines d'observabilité, vous pouvez explorer, via la commande `tap`, les données qui passent par vos sources, transformations et récepteurs, afin de visualiser les données brutes qui transitent via chaque composant de votre pipeline.
-
-### Activer l'API du worker des pipelines d'observabilité
-
- L'API du worker des pipelines d'observabilité vous permet d'interagir avec les processus du worker à l'aide de la commande `tap`. Si vous utilisez les charts Helm fournis dans les [guides de configuration][2], l'API est déjà activée. Sinon, vérifiez que la variable d'environnement `DD_OP_API_ENABLED` est définie sur `true`. Cela configure l'API de façon à effectuer une écoute sur `localhost` et le port `8686`, soit le comportement attendu par la CLI pour la commande `tap`.
-
-### Utiliser la commande `tap` pour visualiser vos données
-
-Si vous êtes sur le même host que le worker, exécutez la commande `tap` suivante pour obtenir la sortie :
-
-```
-observability-pipelines-worker tap
-```
-
-Pour un environnement conteneurisé, utilisez la commande `docker exec` ou `kubectl exec`. Cela vous permet d'obtenir un shell dans le conteneur, afin d'exécuter la commande `tap` ci-dessus.
-
-### Exemple d'utilisation de la commande `tap`
-
-Ajoutez l'exemple de configuration suivant, qui permet à la transformation `cleanup` de copier le contenu de `message` dans l'attribut `log` :
-
-```
-sources:
- demo:
- type: demo_logs
- format: json
-
-transforms:
- cleanup:
- type: remap
- inputs:
- - demo
- source: |-
- .log = .message
-
-sinks:
- blackhole:
- type: blackhole
- inputs:
- - cleanup
- print_interval_secs: 0
-```
-
-Utilisez la commande suivante pour exécuter l'exemple de configuration et afficher la sortie de la transformation `cleanup` :
-
-```
-observability-pipelines-worker tap cleanup
-```
-
-La sortie attendue doit être similaire ce qui suit ; l'attribut `log` copie l'attribut `message` :
-
-```
-[tap] Pattern 'cleanup' successfully matched.
-{"log":"{\"host\":\"121.142.241.212\",\"user-identifier\":\"meln1ks\",\"datetime\":\"25/Aug/2023:00:07:53\",\"method\":\"OPTION\",\"request\":\"/observability/metrics/production\",\"protocol\":\"HTTP/1.0\",\"status\":\"550\",\"bytes\":3185,\"referer\":\"https://make.us/wp-admin\"}","message":"{\"host\":\"121.142.241.212\",\"user-identifier\":\"meln1ks\",\"datetime\":\"25/Aug/2023:00:07:53\",\"method\":\"OPTION\",\"request\":\"/observability/metrics/production\",\"protocol\":\"HTTP/1.0\",\"status\":\"550\",\"bytes\":3185,\"referer\":\"https://make.us/wp-admin\"}","service":"vector","source_type":"demo_logs","timestamp":"2023-08-25T00:07:53.429855261Z"}
-{"log":"{\"host\":\"117.214.24.224\",\"user-identifier\":\"Karimmove\",\"datetime\":\"25/Aug/2023:00:07:54\",\"method\":\"HEAD\",\"request\":\"/do-not-access/needs-work\",\"protocol\":\"HTTP/2.0\",\"status\":\"503\",\"bytes\":41730,\"referer\":\"https://some.org/wp-admin\"}","message":"{\"host\":\"117.214.24.224\",\"user-identifier\":\"Karimmove\",\"datetime\":\"25/Aug/2023:00:07:54\",\"method\":\"HEAD\",\"request\":\"/do-not-access/needs-work\",\"protocol\":\"HTTP/2.0\",\"status\":\"503\",\"bytes\":41730,\"referer\":\"https://some.org/wp-admin\"}","service":"vector","source_type":"demo_logs","timestamp":"2023-08-25T00:07:54.430584949Z"}
-{"log":"{\"host\":\"108.145.218.149\",\"user-identifier\":\"shaneIxD\",\"datetime\":\"25/Aug/2023:00:07:55\",\"method\":\"DELETE\",\"request\":\"/this/endpoint/prints/money\",\"protocol\":\"HTTP/2.0\",\"status\":\"403\",\"bytes\":18340,\"referer\":\"https://up.de/wp-admin\"}","message":"{\"host\":\"108.145.218.149\",\"user-identifier\":\"shaneIxD\",\"datetime\":\"25/Aug/2023:00:07:55\",\"method\":\"DELETE\",\"request\":\"/this/endpoint/prints/money\",\"protocol\":\"HTTP/2.0\",\"status\":\"403\",\"bytes\":18340,\"referer\":\"https://up.de/wp-admin\"}","service":"vector","source_type":"demo_logs","timestamp":"2023-08-25T00:07:55.430085107Z"}
-```
-
-## Pour aller plus loin
-
-{{< partial name="whats-next/whats-next.html" >}}
-
-[1]: https://app.datadoghq.com/observability-pipelines/
-[2]: /fr/observability_pipelines/setup/
-[3]: /fr/help
\ No newline at end of file
diff --git a/content/fr/serverless/guide/_index.md b/content/fr/serverless/guide/_index.md
index 2787a6939abc0..8ed015b68a41d 100644
--- a/content/fr/serverless/guide/_index.md
+++ b/content/fr/serverless/guide/_index.md
@@ -17,7 +17,7 @@ title: Guides d'utilisation de la surveillance sans serveur
{{< nextlink href="/serverless/guide/serverless_warnings" >}}Avertissements de la surveillance sans serveur{{< /nextlink >}}
{{< nextlink href="/serverless/guide/serverless_tagging" >}}Tagging de fonctions sans serveur{{< /nextlink >}}
{{< nextlink href="/serverless/guide/agent_configuration" >}}Configuration de l'Agent sans serveur{{< /nextlink >}}
-{{< /whatsnext >}}
+ {{< nextlink href="/serverless/guide/opentelemetry" >}}Surveillance sans serveur et OpenTelemetry{{< /nextlink >}}{{< /whatsnext >}}
## Effectuer l'installation avec le Forwarder Datadog
@@ -37,4 +37,5 @@ title: Guides d'utilisation de la surveillance sans serveur
{{< nextlink href="/serverless/guide/serverless_tracing_and_webpack" >}}Tracing Lambda Node.js et compatibilité de Webpack{{< /nextlink >}}
{{< nextlink href="/serverless/guide/serverless_package_too_large" >}}Correction des erreurs de package sans serveur trop volumineux{{< /nextlink >}}
{{< nextlink href="/serverless/guide/handler_wrapper" >}}Incorporer la fonction Lambda du gestionnaire dans le code{{< /nextlink >}}
+ {{< nextlink href="/serverless/guide/layer_not_authorized" >}}Dépannage des erreurs relatives aux couches non autorisées{{< /nextlink >}}
{{< /whatsnext >}}
\ No newline at end of file
diff --git a/content/fr/watchdog/_index.md b/content/fr/watchdog/_index.md
index 385edfa9f50f8..6542b0b6824c9 100644
--- a/content/fr/watchdog/_index.md
+++ b/content/fr/watchdog/_index.md
@@ -13,12 +13,12 @@ further_reading:
tag: Notes de version
text: Découvrez les dernières versions de la solution Watchdog Datadog (connexion
à l'application requise).
+- link: https://www.datadoghq.com/blog/datadog-bits-generative-ai/
+ tag: Blog
+ text: Présentation de Bits AI, votre nouvel outil d'assistance DevOps
- link: /logs/
tag: Documentation
text: Recueillir vos logs
-- link: /infrastructure/process/
- tag: Documentation
- text: Recueillir vos processus
- link: /tracing/
tag: Documentation
text: Recueillir vos traces
@@ -28,71 +28,61 @@ further_reading:
- link: https://www.datadoghq.com/blog/watchdog-impact-analysis/
tag: Blog
text: Mesurer l'impact utilisateur avec l'analyse de l'impact Watchdog
+- link: https://www.datadoghq.com/blog/watchdog-live-processes/
+ tag: Blog
+ text: Correction des anomalies liées aux performances des workloads avec Watchdog Insights
+ pour les live processes
kind: Documentation
title: Datadog WatchdogTM
---
-
-{{< img src="watchdog/watchdog.png" alt="La page d'alertes de Watchdog, avec une alerte d'anomalie en cours dans des logs d'erreur, une alerte d'anomalie résolue dans des logs d'erreur et une alerte de taux d'erreur résolue via une analyse des causes d'origine" >}}
-
## Présentation
-Watchdog est une fonction à base d'algorithmes qui analyse les métriques d'infrastructure et de performance APM ainsi que les logs afin de détecter les problèmes potentiels au niveau de vos applications et de votre infrastructure. Elle repose sur les mêmes algorithmes saisonniers que ceux utilisés par les dashboards et la fonctionnalité de détection d'anomalies. Watchdog identifie les tendances et les patterns parmi les métriques suivantes :
-
-* Métriques APM :
- * Hits (taux de requête)
- * Taux d'erreur
- * Latence
-
-* Logs
- * Nouveaux logs d'erreur
- * Augmentations du nombre de logs d'erreur existants
+Le moteur IA de Datadog, Watchdog, vous fournit des alertes automatiques, des informations exploitables, ainsi que des analyses des causes à l'origine de vos problèmes. Ces précieuses informations sont obtenues à partir des données d'observabilité provenant de l'ensemble de la plateforme Datadog. Watchdog surveille constamment votre infrastructure et attire votre attention sur les signaux les plus importants. Vous pouvez ainsi détecter, étudier et résoudre plus facilement vos problèmes.
-* Métriques d'infrastructure issues des intégrations :
- * [Système][1], pour l'utilisation de la mémoire (fuites de mémoire) et le taux de retransmissions TCP au niveau du host.
- * [Redis][2]
- * [PostgreSQL][3]
- * [NGINX][4]
- * [Amazon Web Services][5], pour les services Amazon [S3][6], [ELB/ALB/NLB][7], [CloudFront][8] et [DynamoDB][9].
- * [Alertes][10]
+Toutes les fonctionnalités Watchdog sont automatiquement intégrées et ne nécessitent pas la moindre configuration.
-Watchdog recherche des irrégularités dans les métriques, comme une élévation soudaine du taux de hits. Pour chaque irrégularité, une alerte est affichée sur la [page Watchdog][11]. Chaque alerte comprend un graphique illustrant l'irrégularité détectée et offre des informations supplémentaires sur l'intervalle et les endpoints pertinents. Watchdog surveille automatiquement les données envoyées par l'Agent Datadog ou par les intégrations.
+{{< vimeo url="https://player.vimeo.com/progressive_redirect/playback/781921620/rendition/1080p/file.mp4?loc=external&signature=8889419b739e3398d03a72edca4f96909144567e045d30deeb8f9345c43a682d" poster="/images/poster/watchdog.png" >}}
-En cas de nouvelle source de métriques, de logs ou d'autres données, Watchdog a besoin de deux semaines de données pour analyser le comportement normal attendu. Les anomalies détectées par Watchdog alors qu'il existe moins de deux semaines de données sont susceptibles d'être inexactes.
+
-## Watchdog dans la liste des services
+### Alertes proactives
-Lorsque Watchdog détecte une irrégularité dans une métrique APM, l'icône Watchdog rose en forme de jumelles s'affiche à proximité du service affecté dans la [liste des services APM][12]. Le nombre affiché à côté des jumelles indique le nombre de problèmes détectés par Watchdog dans ce service.
+Watchdog détermine de façon proactive le comportement attendu de vos systèmes, applications et déploiements. Ce cadre de référence permet ainsi de détecter tout comportement anormal.
-{{< img src="watchdog/service_list.png" alt="Capture d'écran de la liste des services APM avec 5 services affichés. Une icône rose en forme de jumelles est visible à côté du nom du service web-store." style="width:75%;" >}}
+{{< whatsnext desc="">}}
+ {{< nextlink href="/watchdog/alerts">}}Alertes Watchdog Alerts : découvrez comment visualiser et interpréter des alertes Datadog et familiarisez-vous avec les informations fournies par les alertes, la portée de chaque alerte ainsi que leurs emplacements dans la plateforme Datadog.{{< /nextlink >}}
+ {{< nextlink href="/watchdog/faulty_deployment_detection">}}Détection des déploiements défectueux : découvrez comment Watchdog identifie les déploiements de code défectueux.{{< /nextlink >}}
+{{< /whatsnext >}}
-Accédez à la [page Services][13] pour consulter des informations détaillées sur une anomalie de métrique. Une case Watchdog Insights est visible en haut de la page. Watchdog Insights vous aide à découvrir les valeurs de tag associées à un comportement inattendu, comme un taux d'erreurs ou une latence élevée.
+Pour personnaliser les algorithmes Watchdog, consultez les rubriques suivantes :
+ * [Algorithme pour les anomalies][7]
+ * [Algorithme pour les prévisions][8]
+ * [Algorithmes pour les singularités][9]
-L'icône Watchdog apparaît également sur les graphiques de métriques.
+### Informations facilitant les enquêtes
-{{< img src="watchdog/latency_graph.png" alt="Un graphique illustrant la latence d'un service, en secondes, sur l'axe des ordonnées et l'heure de la journée sur l'axe des abscisses. Le graphique est représenté sur un fond rose et le texte May 2: 13:31 Ongoing apparaît en haut." style="width:75%;" >}}
+Pour que vous puissiez enquêter plus efficacement sur vos problèmes, Watchdog affiche des informations utiles basées sur le contexte dans toutes les vues Explorer, recherche les causes fondamentales et détermine l'impact utilisateur.
-Cliquez sur l'icône en forme de jumelles pour visualiser une [alerte Watchdog][14] dans une carte plus détaillée.
+{{< whatsnext desc="">}}
+ {{< nextlink href="/watchdog/insights">}}Watchdog Insights : Watchdog Insights est un moteur de recommandations vous aidant à identifier et à résoudre vos problèmes.{{< /nextlink >}}
+ {{< nextlink href="/watchdog/rca">}}Root Cause Analysis : découvrez comment la fonctionnalité Root Cause Analysis (RCA) Watchdog identifie la cause fondamentale d'une anomalie et apprenez à exploiter les informations fournies.{{< /nextlink >}}
+ {{< nextlink href="/watchdog/impact_analysis">}}Analyse de l'impact : découvrez comment Watchdog détermine qu'une anomalie a une incidence sur l'expérience des utilisateurs.{{< /nextlink >}}
+{{< /whatsnext >}}
## Dépannage
-Besoin d'aide ? Contactez [l'assistance Datadog][15].
+Besoin d'aide ? Contactez [l'assistance Datadog][1].
## Pour aller plus loin
{{< partial name="whats-next/whats-next.html" >}}
-[1]: /fr/integrations/system/
-[2]: /fr/integrations/redisdb/
-[3]: /fr/integrations/postgres/
-[4]: /fr/integrations/nginx/
-[5]: /fr/integrations/amazon_web_services/
-[6]: /fr/integrations/amazon_s3/
-[7]: /fr/integrations/amazon_elb/
-[8]: /fr/integrations/amazon_cloudfront/
-[9]: /fr/integrations/amazon_dynamodb/
-[10]: /fr/monitors/
-[11]: https://app.datadoghq.com/watchdog
-[12]: /fr/tracing/services/services_list/
-[13]: /fr/tracing/services/service_page/#overview
-[14]: /fr/watchdog/alerts#alert-details
-[15]: /fr/help/
\ No newline at end of file
+[1]: /fr/help/
+[2]: /fr/watchdog/alerts
+[3]: /fr/watchdog/faulty_deployment_detection/
+[4]: /fr/watchdog/insights?tab=logmanagement
+[5]: /fr/watchdog/rca/
+[6]: /fr/watchdog/impact_analysis/
+[7]: /fr/monitors/types/anomaly/#anomaly-detection-algorithms
+[8]: /fr/monitors/types/forecasts/?tab=linear#algorithms
+[9]: /fr/monitors/types/outlier/?tab=dbscan#algorithms
\ No newline at end of file
diff --git a/content/ja/integrations/fiddler.md b/content/ja/integrations/fiddler.md
index 9c6c6b8c74d13..ed896168fddc2 100644
--- a/content/ja/integrations/fiddler.md
+++ b/content/ja/integrations/fiddler.md
@@ -34,7 +34,7 @@ draft: false
git_integration_title: fiddler
integration_id: fiddler
integration_title: Fiddler
-integration_version: 2.0.0
+integration_version: 3.0.0
is_public: true
kind: integration
manifest_version: 2.0.0
@@ -101,7 +101,7 @@ Agent v7.21 / v6.21 以降の場合は、下記の手順に従い Fiddler チェ
1. 以下のコマンドを実行して、Agent インテグレーションをインストールします。
```shell
- datadog-agent integration install -t datadog-fiddler==2.0.0
+ datadog-agent integration install -t datadog-fiddler==3.0.0
```
2. Agent ベースの[インテグレーション][3]と同様にインテグレーションを構成します。
diff --git a/content/ja/integrations/skykit_digital_signage.md b/content/ja/integrations/skykit_digital_signage.md
index be8b6176f1d66..6dc9b885e704d 100644
--- a/content/ja/integrations/skykit_digital_signage.md
+++ b/content/ja/integrations/skykit_digital_signage.md
@@ -33,7 +33,7 @@ pricing:
short_description: 10 画面までのライセンス。ボリュームディスカウントあり。
tag: 画面
unit_label: 画面
- unit_price: 40
+ unit_price: 33
public_title: Skykit Digital Signage
short_description: Skykit で Datadog のダッシュボードをテレビ画面に表示する
supported_os:
@@ -102,6 +102,7 @@ Skykit は、デジタルサイネージとワークプレイスエクスペリ
[1]: https://www.skykit.com/products/dashboards/connections/datadog-trial/
[2]: mailto:sales@skykit.com
[3]: https://www.datadoghq.com/blog/showcase-datadog-dashboards-securely-with-skykit/
-[4]: https://support.skykit.com/en/articles/324-getting-started-with-skykit-beam-and-datadog-dashboards
+[4]: https://support.skykit.com/docs/getting-started-with-skykit-beam-and-datadog-dashboards
+
---
このアプリケーションは Marketplace から入手でき、Datadog テクノロジーパートナーによってサポートされています。このアプリケーションを購入するには、こちらをクリックしてください。
\ No newline at end of file
diff --git a/content/ja/observability_pipelines/architecture/_index.md b/content/ja/observability_pipelines/architecture/_index.md
deleted file mode 100644
index a1090a9d54c41..0000000000000
--- a/content/ja/observability_pipelines/architecture/_index.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-aliases:
-- /ja/observability_pipelines/production_deployment_overview/aggregator_architecture
-kind: Documentation
-title: OPW アグリゲーターアーキテクチャのベストプラクティス
----
-
-## 概要
-
-観測可能性パイプラインワーカー (OPW) のアグリゲーターアーキテクチャは、データの集中処理とルーティングのためのスタンドアローンサービスとして観測可能性パイプラインワーカーをデプロイします。
-
-{{< img src="observability_pipelines/production_deployment_overview/aggregator_role.png" alt="ネットワークロードバランサーが様々なソースからデータを受け取り、観測可能性パイプラインワーカーアグリゲーターにデータを送る様子を示した図。このアグリゲーターは、異なるアベイラビリティゾーンに複数のワーカーを持ち、様々なシンクにデータを送る" style="width:100%;" >}}
-
-観測可能性パイプラインワーカーを他のサービスのようにインフラストラクチャーにデプロイし、データをインターセプトして操作し、宛先に転送することができます。観測可能性パイプラインワーカーインスタンスはそれぞれ独立して動作するため、シンプルなロードバランサーでアーキテクチャを拡張することができます。
-
-このガイドでは、新規の観測可能性パイプラインワーカーユーザーのために、推奨されるアグリゲーターアーキテクチャを説明します。具体的には、以下のトピックが含まれています。
-
-- データの収集、処理、ルーティングを行うための[観測可能性パイプラインワーカーの構成](#configuring-the-observability-pipelines-worker)。
-- [インスタンスの最適化][3]により、観測可能性パイプラインワーカーのアグリゲーターを水平方向にスケールさせることができるようになります。
-- [キャパシティプランニングと観測可能性パイプラインワーカーをスケーリングする][4]ためのリソース容量を見積もるための出発点。
-- 観測可能性パイプラインワーカー用の[ネットワークトポロジと構成][5]の決定。
-- [高耐久性][6]と[高可用性](#high-availability)の実現。
-- 観測可能性パイプラインワーカーを[災害復旧][7]の一環として活用する。
-- 複数のアグリゲーター、パブリッシュサブスクライブシステム、およびグローバル集計をデプロイするための、その他の[高度な構成][8]。
-
-[3]: /ja/observability_pipelines/architecture/optimize
-[4]: /ja/observability_pipelines/architecture/capacity_planning_scaling
-[5]: /ja/observability_pipelines/architecture/networking
-[6]: /ja/observability_pipelines/architecture/preventing_data_loss
-[7]: /ja/observability_pipelines/architecture/availability_disaster_recovery
-[8]: /ja/observability_pipelines/architecture/advanced_configurations
\ No newline at end of file
diff --git a/content/ja/observability_pipelines/architecture/advanced_configurations.md b/content/ja/observability_pipelines/architecture/advanced_configurations.md
deleted file mode 100644
index a03dcd83affb0..0000000000000
--- a/content/ja/observability_pipelines/architecture/advanced_configurations.md
+++ /dev/null
@@ -1,62 +0,0 @@
----
-kind: Documentation
-title: 高度なコンフィギュレーション
----
-
-{{< site-region region="gov" >}}
-
-{{< /site-region >}}
-
-## 개요
-
-인프라스트럭처에 옵저버빌리티 파이프라인 작업자를 배포하기 시작하면 다음과 같은 질문에 직면할 수 있습니다.
-
-- 네트워크 내부 어디에 옵저버빌리티 파이프라인 작업자를 배포해야 하나요?
-- 데이터를 어떻게 수집해야 하나요?
-- 데이터를 어디에서 처리해야 하나요?
-
-이 가이드에서는 옵저버빌리티 파이프라인 작업자 아키텍처를 설계할 때 고려해야 할 사항, 구체적으로 다음 항목에 대해 설명합니다:
-
-- [네트워킹](#networking)
-- [데이터 수집](#collecting-data)
-- [데이터 처리](#processing-data)
-- [데이터 버퍼링](#buffering-data)
-- [데이터 라우팅](#routing-data)
-
-## 네트워킹
-
-옵저버빌리티 파이프라인 작업자 배포 구축을 위한 첫 번째 단계는 옵저버빌리티 파이프라인 작업자가 네트워크 내부 어디에 적합할지, 그리고 어디에 배포할지를 파악하는 것입니다.
-
-### 네트워크 경계 작업
-
-옵저버빌리티 파이프라인 작업자는 애그리게이터(aggregator)로 배포되기 때문에 송신 비용을 최소화하려면 네트워크 경계 내에 배포해야 합니다. 옵저버빌리티 파이프라인 작업자의 인그레스는 공용 인터넷을 통해 이동해서는 안 됩니다. 따라서 Datadog은 이 작업을 간소화하기 위해 리전당 하나의 애그리게이터(aggregator)로 시작할 것을 권장합니다.
-
-### 방화벽 및 프록시 사용
-
-방화벽을 사용하는 경우 에이전트 통신을 애그리게이터(aggregator)로 제한하고 애그리게이터(aggregator) 통신을 설정된 소스 및 싱크로 제한하세요.
-
-HTTP 프록시 사용을 선호하는 경우 옵저버빌리티 파이프라인 작업자는 모든 옵저버빌리티 파이프라인 작업자 HTTP 트래픽을 프록시를 통해 라우팅하는 전역 프록시 옵션을 제공합니다.
-
-### DNS 및 서비스 검색 사용
-
-옵저버빌리티 파이프라인 작업자 애그리게이터 및 서비스를 찾으려면 DNS 또는 서비스 검색을 통해 이루어져야 합니다. 이 전략은 트래픽의 라우팅과 로드밸런싱을 용이하게 하며, 에이전트와 로드 밸런서가 애그리게이터를 발견하는 방법입니다. 적절한 문제 분리를 위해 옵저버빌리티 파이프라인 작업자는 DNS 쿼리를 확인하지 않고 대신 시스템 수준 리졸버(예: [Linux resolving][1])에 위임합니다.
-
-{{< img src="observability_pipelines/production_deployment_overview/dns_service_discovery.png" alt="에이전트 클러스터, 로드 밸런서 클러스터, 옵저버빌리티 파이프라인 작업자 집합이 있는 클라우드 리전을 보여주는 다이어그램으로, 각 그룹이 DNS 또는 서비스 레지스트리에 별도의 쿼리를 전송하고 있습니다." style="width:60%;" >}}
-
-### 프로토콜 선택
-
-옵저버빌리티 파이프라인 작업자로 데이터를 전송할 때는 로드밸런싱과 애플리케이션 수준의 전송 승인을 쉽게 할 수 있는 프로토콜을 선택할 것을 권장합니다. HTTP와 gRPC는 유비쿼터스 특성을 가지고 있고 HTTP/gRPC 기반 서비스를 효과적이고 효율적으로 운영하는 데 도움이 되는 도구와 문서가 많아 선호됩니다.
-
-프로토콜에 맞는 소스를 선택하세요. 각 옵저버빌리티 파이프라인 작업자 소스는 서로 다른 프로토콜을 구현합니다. 예를 들어 옵저버빌리티 파이프라인 작업자 소스 및 싱크는 옵저버빌리티 파이프라인 작업자 간 통신을 위해 gRPC를 사용하며, HTTP 소스를 사용하면 HTTP를 통해 데이터를 수신할 수 있습니다. 해당 프로토콜은 [소스][2]를 참조하세요.
-
-## 데이터 수집하기
-
-파이프라인은 데이터 수집에서 시작됩니다. 귀사의 서비스와 시스템은 수집하여 대상까지 다운스트림으로 전송할 수 있는 데이터[*](#support)를 생성합니다. 데이터 수집은 에이전트를 통해 이루어지며, 어떤 에이전트를 사용할지 이해하면 원하는 데이터를 수집할 수 있습니다.
-
-### 에이전트 선택
-
-엔지니어링 팀의 시스템 모니터링 능력을 최적화하는 에이전트를 선택해야 합니다. 따라서 옵저버빌리티 파이프라인 작업자를 작업에 가장 적합한 에이전트와 통합하고 옵저버빌리티 파이프라인 작업자를 별도의 노드에 애그리게이터(aggregator)로 배포하세요.
-
-예를 들어 Datadog [네트워크 성능 모니터링][4]은 Datadog Agent를 공급업체별 시스템과 통합하고 공급업체별 데이터를 생성합니다. 따라서 옵저버빌리티 파이프라인 작업자에서 지원되는 데이터 유형이 아니기 때문에 Datadog Agent는 데이터를 수집하여 Datadog에 직접 보내야 합니다.
-
-또 다른 예로, Datadog Agent는 서비스 메트릭을 수집하고 이를 공급업체별 Datadog 태그로 강화합니다. 이 경우 Datadog Agent는 메트릭을 Datadog에 직접 보내거나 옵저버빌리티 파이프라인 작업자를 통해 라우팅해야 합니다. 생성되는 데이터가 공급업체별 방식으로 강화되므로 옵저버빌리티 파이프라인 작업자는 Datadog Agent를 대체해서는 안 됩니다.
-
-에이전트와 통합할 때 옵저버빌리티 파이프라인 작업자를 설정하여 로컬 네트워크를 통해 에이전트로부터 직접 데이터를 수신하고 옵저버빌리티 파이프라인 작업자를 통해 데이터를 라우팅합니다. `datadog_agent` 또는 `open_telemetry`와 같은 소스 컴포넌트를 사용하여 에이전트로부터 데이터를 받습니다.
-
-##### 에이전트 리스크 감소
-
-에이전트와 통합할 때는 에이전트를 단순 데이터 포워더로 설정하고 지원되는 데이터 유형을 옵저버빌리티 파이프라인 작업자를 통해 라우팅하세요. 이렇게 하면 에이전트의 책임을 최소화하여 데이터 손실 및 서비스 중단의 위험을 줄일 수 있습니다.
-
-## 데이터 처리
-
-옵저버빌리티 파이프라인 작업자의 소스와 싱크 간에 효율적인 파이프라인을 설계하려는 경우, 처리할 데이터 유형과 처리 위치를 이해하는 데 도움이 됩니다.
-
-### 처리할 데이터 선택
-
-옵저버빌리티 파이프라인 작업자를 사용하여 데이터를 처리할 수 있습니다[*](#support). 그러나 지속적인 프로파일링 데이터와 같은 실시간 공급업체별 데이터는 상호 운용되지 않으며 처리 시에 일반적으로 얻는 이점이 없습니다.
-
-#### 원격 처리
-
-원격 처리의 경우 옵저버빌리티 파이프라인 작업자를 애그리게이터(aggregator)로 별도의 노드에 배포할 수 있습니다.
-
-{{< img src="observability_pipelines/production_deployment_overview/aggregator_role.png" alt="이 다이어그램은 여러 작업자를 포함하는 옵저버빌리티 파이프라인 작업자 애그리게이터를 보여줍니다. 이 작업자들은 네트워크 로드 밸런서에서 데이터를 수신하고 여러 다른 싱크로 데이터를 전송합니다." style="width:100%;" >}}
-
-데이터 처리가 노드에서 원격 애그리게이터(aggregator) 노드로 이동합니다. 원격 처리는 높은 내구성과 고가용성이 필요한 환경(대부분의 환경)에 권장됩니다. 또한 에이전트를 추가할 때 인프라스트럭처 재구성이 반드시 필요하지 않으므로 설정하기가 더 쉽습니다.
-
-자세한 내용은 [애그리게이터(aggregator) 아키텍처][5]를 참조하세요.
-
-## 데이터 버퍼링
-
-데이터를 버퍼링하는 위치와 방법도 파이프라인의 효율성에 영향을 미칠 수 있습니다.
-
-### 데이터를 버퍼링할 위치 선택
-
-버퍼링은 대상과 가까운 곳에서 이루어져야 하며, 각 대상에는 다음과 같은 이점을 제공하는 자체 격리 버퍼가 있어야 합니다:
-
-1. 각 대상은 싱크의 요구 사항에 맞게 버퍼를 설정할 수 있습니다. 자세한 내용은 [데이터 버퍼링 방법 선택](#choosing-how-to-buffer-data)을 참조하세요.
-2. 각 대상에 대한 버퍼를 격리하면 버퍼가 설정된 용량에 도달할 때까지 하나의 오작동 대상 때문에 전체 파이프라인이 중단되는 것을 방지할 수 있습니다.
-
-이러한 이유로 옵저버빌리티 파이프라인 작업자는 버퍼를 싱크와 연결합니다.
-
-{{< img src="observability_pipelines/production_deployment_overview/where_to_buffer.png" alt="노드의 에이전트가 다른 노드의 버퍼를 사용하여 옵저버빌리티 파이프라인 작업자로 데이터를 전송하는 다이어그램입니다." style="width:50%;" >}}
-
-### 데이터를 버퍼링할 방법 선택
-
-옵저버빌리티 파이프라인 작업자의 내장 버퍼는 작업을 간소화하여 복잡한 외부 버퍼가 필요하지 않습니다.
-
-옵저버빌리티 파이프라인 작업자 버퍼 유형을 선택할 때는 대상의 목적에 가장 적합한 유형을 선택하세요. 예를 들어, 기록 시스템에서는 높은 내구성을 위해 디스크 버퍼를 사용해야 하고, 분석 시스템에서는 짧은 지연 시간을 위해 메모리 버퍼를 사용해야 합니다. 또한 두 버퍼 모두 다른 버퍼로 오버플로우되어 클라이언트에 역압이 전파되는 것을 방지할 수 있습니다.
-
-{{< img src="observability_pipelines/production_deployment_overview/how_to_buffer.png" alt="싱크에 가까운 디스크 버퍼와 메모리 버퍼로 데이터를 전송하는 옵저버빌리티 파이프라인 작업자의 소스를 보여주는 다이어그램입니다." style="width:100%;" >}}
-
-## 데이터 라우팅
-
-애그리게이터(aggregator)가 데이터를 적절한 대상으로 보낼 수 있도록 데이터를 라우팅하는 것은 파이프라인 설계의 마지막 요소입니다. 애그리게이터(aggregator)를 사용하여 팀에 가장 적합한 시스템으로 데이터를 유연하게 라우팅하세요.
-
-### 기록 시스템과 분석 시스템의 분리
-
-기록 시스템과 분석 시스템을 분리하여 목적에 영향을 미치는 절충안을 만들지 않고 비용을 최적화하세요. 예를 들어, 기록 시스템은 시간이 지남에 따라 대량의 데이터를 일괄 처리하고 압축하여 비용을 최소화하는 동시에 모든 데이터의 높은 내구성을 보장할 수 있습니다. 또한 분석 시스템은 데이터를 샘플링하고 정리하여 비용을 절감하는 동시에 실시간 분석을 위해 지연 시간을 낮출 수 있습니다.
-
-{{< img src="observability_pipelines/production_deployment_overview/separating_concerns.png" alt="데이터를 디스크 버퍼로 전송한 다음 아카이빙을 위해 데이터를 전송하거나 샘플링을 위해 블록 스토리지 디스크로 전송하는 옵저버빌리티 파이프라인 작업자의 소스를 보여주는 다이어그램입니다." style="width:100%;" >}}
-
-### 기록 시스템으로 라우팅(아카이빙)
-
-다음을 수행하여 비용을 최소화하면서 기록 시스템을 최적화하여 내구성을 높이세요:
-
-- 노드 재시작 및 소프트웨어 오류로 인한 데이터 손실을 줄이려면 애그리게이터 역할에서만 아카이브에 작성하세요.
-- 디스크 버퍼와 함께 싱크를 앞에 위치합니다.
-- 모든 소스에 대해 엔드 투 엔드 승인을 활성화합니다.
-- `batch.max_bytes`는 ≥ 5MiB로, `batch.timeout_secs`는 ≥ 5분으로 설정하고, 압축(`aws_s3` 싱크와 같은 아카이빙 싱크를 위한 기본값)을 활성화합니다.
-- 처리되지 않은 원시 데이터를 보관하여 데이터 재생을 허용하고 처리 중 우발적인 데이터 손상 위험을 줄이세요.
-
-### 분석 시스템으로 라우팅
-
-분석 시스템을 최적화하고 비용을 절감하려면 다음을 수행하세요:
-
-- 메모리 버퍼와 함께 싱크를 앞에 위치합니다.
-- `batch.timeout_sec`를 ≤ 5초로 설정합니다 (`datadog_logs`와 같은 분석 싱크의 기본값).
-- `remap` 변환을 사용하여 분석에 사용되지 않는 속성을 제거합니다.
-- 분석에 사용되지 않는 이벤트 필터링
-- 볼륨을 줄이기 위해 로그를 `level` `info` 또는 그 이하로 샘플링하는 것을 고려하세요.
-
-[1]: https://wiki.archlinux.org/title/Domain_name_resolution
-[2]: /ko/observability_pipelines/reference/sources/
-[4]: /ko/network_monitoring/performance/
-[5]: /ko/observability_pipelines/architecture/
-
----
-
- * 옵저버빌리티 파이프라인은 로그를 지원합니다. 메트릭에 대한 지원은 베타 버전입니다.
\ No newline at end of file
diff --git a/content/ko/observability_pipelines/setup/_index.md b/content/ko/observability_pipelines/setup/_index.md
deleted file mode 100644
index 4310e8f8500a0..0000000000000
--- a/content/ko/observability_pipelines/setup/_index.md
+++ /dev/null
@@ -1,421 +0,0 @@
----
-aliases:
-- /ko/getting_started/observability_pipelines/
-- /ko/observability_pipelines/installation/
-further_reading:
-- link: /observability_pipelines/working_with_data/
- tag: 설명서
- text: 옵저버빌리티 파이프라인에서 데이터 사용
-- link: /observability_pipelines/production_deployment_overview/
- tag: 설명서
- text: 옵저버빌리티 파이프라인 작업자의 배포 설계 및 원칙
-- link: /observability_pipelines/architecture/
- tag: 설명서
- text: 옵저버빌리티 파이프라인 작업자의 프로덕션 배포 설계 및 원칙
-- link: https://dtdg.co/d22op
- tag: 학습 센터
- text: 옵저버빌리티 파이프라인을 통한 안전한 로컬 처리
-kind: documentation
-title: 옵저버빌리티 파이프라인 작업자 설정
-type: multi-code-lang
----
-
-{{< site-region region="gov" >}}
-
옵저버빌리티 파이프라인은 US1-FED Datadog 사이트에서 사용할 수 없습니다.
-{{< /site-region >}}
-
-## 개요
-
-[옵저버빌리티 파이프라인 작업자][1]는 모든 소스에서 모든 대상으로 로그와 메트릭을 수집, 처리 및 라우팅할 수 있습니다. Datadog을 사용하면 모든 옵저버빌리티 파이프라인 작업자 배포를 대규모로 구축하고 관리할 수 있습니다.
-
-옵저버빌리티 파이프라인 작업자를 시작하는 방법에는 여러 가지가 있습니다.
-
-- [빠른 설치](#quickstart): 데모 데이터를 내보내는 간단한 파이프라인으로 작업자를 설치하여 빠르게 시작할 수 있습니다.
-- [Datadog 설정 가이드][2]: Datadog Agents에서 Datadog으로 데이터를 수신하고 라우팅하기 위해 즉시 사용 가능한 파이프라인으로 작업자를 설치합니다.
-- [Datadog 아카이빙 설정 가이드][3]: Datadog Agents에서 Datadog과 S3로 데이터를 수신하고 라우팅하기 위해 즉시 사용 가능한 파이프라인으로 작업자를 설치합니다.
-- [Splunk 설정 가이드][4]: Splunk HEC에서 Splunk 및 Datadog으로 데이터를 수신하고 라우팅하기 위해 즉시 사용 가능한 파이프라인으로 작업자를 설치합니다.
-
-이 문서는 빠른 시작 설치 단계를 안내하고 다음 단계를 위한 리소스를 제공합니다.
-
-## 배포 모드
-
-{{% op-deployment-modes %}}
-
-## 필수 구성 요소
-
-옵저버빌리티 파이프라인 작업자를 설치하려면 다음이 필요합니다:
-
-- 유효한 [Datadog API 키[5].
-- 파이프라인 ID.
-
-새 API 키 및 파이프라인을 생성하려면:
-
-1. [Observability Pipelines][6]로 이동합니다.
-2. **New Pipeline**을 클릭합니다.
-3. 파이프라인의 이름을 입력합니다.
-4. **Next**를 클릭합니다.
-4. 원하는 템플릿을 선택하고 지침을 따릅니다.
-
-## 빠른 시작
-
-다음 지침에 따라 작업자를 설치하고 데모 데이터를 사용하는 샘플 파이프라인 설정을 배포합니다.
-
-### 옵저버빌리티 파이프라인 작업자 설치
-
-{{< tabs >}}
-{{% tab "Docker" %}}
-
-옵저버빌리티 파이프라인 작업자 Docker 이미지는 Docker Hub [여기][1]에 게시됩니다.
-
-1. [샘플 파이프라인 설정 파일][2]을 다운로드합니다. 이 설정은 데모 데이터를 내보내고 데이터를 파싱 및 구조화한 후 콘솔 및 Datadog으로 보냅니다. 샘플 설정에 사용된 소스, 변환, 싱크에 대한 자세한 내용은 [설정][3]을 참조하세요.
-
-2. 다음 명령을 실행하여 Docker와 함께 옵저버빌리티 파이프라인 작업자를 시작합니다:
-
- ```shell
- docker run -i -e DD_API_KEY= \
- -e DD_OP_PIPELINE_ID= \
- -e DD_SITE= \
- -p 8282:8282 \
- -v ./pipeline.yaml:/etc/observability-pipelines-worker/pipeline.yaml:ro \
- datadog/observability-pipelines-worker run
- ```
-
- ``를 Datadog API 키로, ``를 옵저버빌리티 파이프라인 설정 ID로, ``를 {{< region-param key="dd_site" code="true" >}}로 교체합니다. **참고**: `./pipeline.yaml`는 1단계에서 다운로드한 설정의 상대적 또는 절대적 경로여야 합니다.
-
-[1]: https://hub.docker.com/r/datadog/observability-pipelines-worker
-[2]: /resources/yaml/observability_pipelines/quickstart/pipeline.yaml
-[3]: /ko/observability_pipelines/configurations/
-{{% /tab %}}
-{{% tab "AWS EKS" %}}
-1. AWS EKS용 [Helm 차트][1]를 다운로드합니다. 샘플 설정에 사용된 소스, 변환 및 싱크에 대한 자세한 내용은 [설정][2]을 참조하세요.
-
-2. Helm 차트에서 해당 파이프라인과 일치하도록 `datadog.apiKey` 및 `datadog.pipelineId` 값을 변경하고 `site` 값에는 {{< region-param key="dd_site" code="true" >}}를 사용하세요. 그런 다음 아래 명령을 사용하여 클러스터에 설치합니다:
-
- ```shell
- helm repo add datadog https://helm.datadoghq.com
- ```
- ```shell
- helm repo update
- ```
- ```shell
- helm upgrade --install \
- opw datadog/observability-pipelines-worker \
- -f aws_eks.yaml
- ```
-
-[1]: /resources/yaml/observability_pipelines/quickstart/aws_eks.yaml
-[2]: /ko/observability_pipelines/configurations/
-{{% /tab %}}
-{{% tab "Azure AKS" %}}
-1. Azure AKS의 경우 [Helm 차트][1]를 다운로드합니다. 샘플 설정에 사용된 소스, 변환 및 싱크에 대한 자세한 내용은 [설정][2]을 참조하세요.
-
-2. Helm 차트에서 해당 파이프라인과 일치하도록 `datadog.apiKey` 및 `datadog.pipelineId`값을 변경하고 `site`값에 {{< region-param key="dd_site" code="true" >}}를 사용합니다. 그런 다음 아래 명령을 사용하여 클러스터에 설치합니다:
-
- ```shell
- helm repo add datadog https://helm.datadoghq.com
- ```
- ```shell
- helm repo update
- ```
- ```shell
- helm upgrade --install \
- opw datadog/observability-pipelines-worker \
- -f azure_aks.yaml
- ```
-
-[1]: /resources/yaml/observability_pipelines/quickstart/azure_aks.yaml
-[2]: /ko/observability_pipelines/configurations/
-{{% /tab %}}
-{{% tab "Google GKE" %}}
-1. 구글 GKE용 [Helm 차트][1]를 다운로드합니다. 샘플 설정에 사용된 소스, 변환 및 싱크에 대한 자세한 내용은 [설정][2]을 참조하세요.
-
-2. Helm 차트에서 해당 파이프라인과 일치하도록 `datadog.apiKey` 및 `datadog.pipelineId` 값을 변경하고 `site` 값에 {{< region-param key="dd_site" code="true" >}}를 사용합니다. 그런 다음 아래 명령을 사용하여 클러스터에 설치합니다:
-
- ```shell
- helm repo add datadog https://helm.datadoghq.com
- ```
- ```shell
- helm repo update
- ```
- ```shell
- helm upgrade --install \
- opw datadog/observability-pipelines-worker \
- -f google_gke.yaml
- ```
-
-[1]: /resources/yaml/observability_pipelines/quickstart/google_gke.yaml
-[2]: /ko/observability_pipelines/configurations/
-{{% /tab %}}
-{{% tab "APT 기반 Linux" %}}
-
-한 줄 설치 스크립트를 사용하거나 수동으로 작업자를 설치합니다.
-#### 한 줄 설치 스크립트
-
-1. 한 줄 설치 명령을 실행하여 작업자를 설치합니다. ``는 Datadog API 키로, ``는 옵저버빌리티 파이프라인 ID로, ``는 {{< region-param key="dd_site" code="true" >}}로 교체합니다.
-
- ```
- DD_API_KEY= DD_OP_PIPELINE_ID= DD_SITE= bash -c "$(curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script_op_worker1.sh)"
- ```
-
-2. [샘플 설정 파일][1]을 호스트에서 `/etc/observability-pipelines-worker/pipeline.yaml`로 다운로드합니다. 샘플 설정에 사용되는 소스, 변환 및 싱크에 대한 자세한 내용은 [설정][2]를 참조하세요.
-
-3. 작업자 시작:
-
- ```
- sudo systemctl restart observability-pipelines-worker
- ```
-
-#### 수동 설치
-
-1. HTTPS를 통해 다운로드할 APT를 설정하려면 다음 명령을 실행합니다:
-
- ```
- sudo apt-get update
- sudo apt-get install apt-transport-https curl gnupg
- ```
-
-2. 다음 명령을 실행하여 시스템에 Datadog `deb` 리포지토리를 설정하고 Datadog 아카이브 키링을 생성하세요:
-
- ```
- sudo sh -c "echo 'deb [signed-by=/usr/share/keyrings/datadog-archive-keyring.gpg] https://apt.datadoghq.com/ stable observability-pipelines-worker-1' > /etc/apt/sources.list.d/datadog-observability-pipelines-worker.list"
- sudo touch /usr/share/keyrings/datadog-archive-keyring.gpg
- sudo chmod a+r /usr/share/keyrings/datadog-archive-keyring.gpg
- curl https://keys.datadoghq.com/DATADOG_APT_KEY_CURRENT.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch
- curl https://keys.datadoghq.com/DATADOG_APT_KEY_F14F620E.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch
- curl https://keys.datadoghq.com/DATADOG_APT_KEY_C0962C7D.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch
- ```
-
-3. 다음 명령을 실행하여 로컬 `apt` 리포지토리를 업데이트하고 작업자를 설치합니다:
-
- ```
- sudo apt-get update
- sudo apt-get install observability-pipelines-worker datadog-signing-keys
- ```
-
-4. 키와 사이트 ({{< region-param key="dd_site" code="true" >}})를 작업자 환경 변수에 추가합니다:
-
- ```
- sudo cat <<-EOF > /etc/default/observability-pipelines-worker
- DD_API_KEY=
- DD_OP_PIPELINE_ID=
- DD_SITE=
- EOF
- ```
-
-5. 호스트에서 [샘플 설정 파일][1]을 `/etc/observability-pipelines-worker/pipeline.yaml`에 다운로드합니다.
-
-6. 작업자 시작:
-
- ```
- sudo systemctl restart observability-pipelines-worker
- ```
-
-[1]: /resources/yaml/observability_pipelines/datadog/pipeline.yaml
-[2]: /ko/observability_pipelines/configurations/
-{{% /tab %}}
-{{% tab "RPM 기반 Linux" %}}
-
-한 줄 설치 스크립트를 사용하거나 수동으로 작업자를 설치합니다.
-
-#### 한 줄 설치 스크립트
-
-1. 한 줄 설치 명령을 실행하여 작업자를 설치합니다. ``는 Datadog API 키로, ``는 옵저버빌리티 파이프라인 ID로, ``는 {{< region-param key="dd_site" code="true" >}}로 교체합니다.
-
- ```
- DD_API_KEY= DD_OP_PIPELINE_ID= DD_SITE= bash -c "$(curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script_op_worker1.sh)"
- ```
-
-2. [샘플 설정 파일][1]을 호스트에서 `/etc/observability-pipelines-worker/pipeline.yaml`로 다운로드합니다. 샘플 설정에 사용되는 소스, 변환 및 싱크에 대한 자세한 내용은 [설정][2]를 참조하세요.
-
-3. 다음 명령을 실행하여 작업자를 시작합니다:
-
- ```
- sudo systemctl restart observability-pipelines-worker
- ```
-
-#### 수동 설치
-
-1. 다음 명령을 실행하여 시스템에서 Datadog `rpm` 리포지토리를 설정합니다:
-
- ```
- cat < /etc/yum.repos.d/datadog-observability-pipelines-worker.repo
- [observability-pipelines-worker]
- name = Observability Pipelines Worker
- baseurl = https://yum.datadoghq.com/stable/observability-pipelines-worker-1/\$basearch/
- enabled=1
- gpgcheck=1
- repo_gpgcheck=1
- gpgkey=https://keys.datadoghq.com/DATADOG_RPM_KEY_CURRENT.public
- https://keys.datadoghq.com/DATADOG_RPM_KEY_B01082D3.public
- https://keys.datadoghq.com/DATADOG_RPM_KEY_FD4BF915.public
- https://keys.datadoghq.com/DATADOG_RPM_KEY_E09422B3.public
- EOF
- ```
-
- **참고:** RHEL 8.1 또는 CentOS 8.1을 실행 중인 경우 위의 설정에서 `repo_gpgcheck=1` 대신 `repo_gpgcheck=0`를 사용하세요.
-
-2. 패키지를 업데이트하고 작업자를 설치합니다:
-
- ```
- sudo yum makecache
- sudo yum install observability-pipelines-worker
- ```
-
-3. 키와 사이트 ({{< region-param key="dd_site" code="true" >}}) 를 작업자 환경 변수에 추가합니다:
-
- ```
- sudo cat <<-EOF > /etc/default/observability-pipelines-worker
- DD_API_KEY=
- DD_OP_PIPELINE_ID=
- DD_SITE=
- EOF
- ```
-
-4. [샘플 설정 파일][1]을 호스트에서 `/etc/observability-pipelines-worker/pipeline.yaml`로 다운로드합니다. 샘플 설정에 사용되는 소스, 변환 및 싱크에 대한 자세한 내용은 [설정][2]를 참조하세요.
-
-5. 다음 명령을 실행하여 작업자를 시작합니다:
- ```
- sudo systemctl restart observability-pipelines-worker
- ```
-
-[1]: /resources/yaml/observability_pipelines/quickstart/pipeline.yaml
-[2]: /ko/observability_pipelines/configurations/
-{{% /tab %}}
-{{% tab "Terraform (AWS)" %}}
-이 샘플 설정을 사용하여 기존 Terraform에 작업자 모듈을 설정합니다. 해당 AWS 배포와 일치하도록 `vpc-id`, `subnet-ids` 및 `region`의 값을 업데이트합니다. 해당 파이프라인과 일치하도록 `datadog-api-key` 및 `pipeline-id`의 값을 업데이트합니다.
-
-샘플 설정에 사용되는 소스, 변환 및 싱크에 대한 자세한 내용은 [설정][2]을 참조하세요.
-
-```
-module "opw" {
- source = "https://github.com/DataDog/opw-terraform//aws"
- vpc-id = "{VPC ID}"
- subnet-ids = ["{SUBNET ID 1}", "{SUBNET ID 2}"]
- region = "{REGION}"
-
- datadog-api-key = "{DATADOG API KEY}"
- pipeline-id = "{OP PIPELINE ID}"
- pipeline-config = <}}
-
-데이터 변환에 대한 자세한 내용은 [데이터 작업][7]을 참조하세요.
-
-## 배포 모드 업데이트
-
-{{% op-updating-deployment-modes %}}
-
-## 다음 단계
-
-빠른 시작은 작업자 설치와 샘플 파이프라인 설정 배포를 안내합니다. 작업자를 설치하여 Datadog Agents에서 데이터를 수신하여 Datadog으로 라우팅하거나 Splunk HEC에서 데이터를 수신하여 Splunk 및 Datadog으로 라우팅하는 방법에 대한 지침을 보려면 특정 사용 사례를 선택하세요:
-
-{{< partial name="observability_pipelines/use_cases.html" >}}
-
-여러 작업자 배포 및 확장에 대한 권장 사항은 다음을 참조하세요.
-
-- 옵저버빌리티 파이프라인 아키텍처를 설계할 때 고려해야 할 사항은 [배포 설계 및 원칙][8]을 참조하세요.
-- [OP 작업자 애그리게이터 아키텍처 모범 사례][9]를 참조하세요.
-
-## 참고 자료
-
-{{< partial name="whats-next/whats-next.html" >}}
-
-[1]: /ko/observability_pipelines/#what-is-observability-pipelines-and-the-observability-pipelines-worker
-[2]: /ko/observability_pipelines/setup/datadog/
-[3]: /ko/observability_pipelines/setup/datadog_with_archiving/
-[4]: /ko/observability_pipelines/setup/splunk/
-[5]: https://app.datadoghq.com/observability-pipelines
-[6]: /ko/account_management/api-app-keys/#api-keys
-[7]: /ko/observability_pipelines/working_with_data/
-[8]: /ko/observability_pipelines/production_deployment_overview/
-[9]: /ko/observability_pipelines/architecture/
\ No newline at end of file
diff --git a/content/ko/observability_pipelines/troubleshooting.md b/content/ko/observability_pipelines/troubleshooting.md
deleted file mode 100644
index 2271feb96fe63..0000000000000
--- a/content/ko/observability_pipelines/troubleshooting.md
+++ /dev/null
@@ -1,98 +0,0 @@
----
-disable_toc: false
-further_reading:
-- link: /observability_pipelines/monitoring/
- tag: 설명서
- text: 파이프라인 상태 모니터링
-kind: documentation
-title: 트러블슈팅
----
-
-{{< site-region region="gov" >}}
-
옵저버빌리티 파이프라인은 US1-FED Datadog 사이트에서 사용할 수 없습니다.
-{{< /site-region >}}
-
-## 개요
-Datadog 옵저버빌리티 파이프라인(OP)에서 예기치 않은 동작이 발생하는 경우, 이 가이드를 통해 문제를 신속하게 해결할 수 있습니다. 계속해서 문제가 발생하면 [Datadog 지원팀][3]에 문의하여 추가 지원을 받으세요.
-
-## 진단 로그 조사
-
-옵저버빌리티 파이프라인 작업자는 자체 상태에 대한 내부 로그를 내보냅니다. 옵저버빌리티 파이프라인 UI에서 작업자 프로세스가 모든 개별 컴포넌트에 대해 내보내는 내부 오류 로그를 조사할 수 있습니다. 다음 진단 로그를 보려면:
-
-1. [Observability Pipelines][1]로 이동합니다.
-1. 조사하려는 파이프라인을 클릭합니다.
-1. 컴포넌트의 사이드 패널을 보려면 컴포넌트를 클릭합니다.
-1. 작업자가 내보내는 오류 로그를 보려면 **Diagnostic Logs** 탭을 클릭하세요. Log Explorer에서 로그 기록을 클릭하여 조사합니다. 나열된 로그가 없으면 컴포넌트가 오류 로그를 생성하지 않는 것입니다.
-
-### 더 상세한 로그 보기
-
-OP Worker가 수집하는 내부 로그에 대한 자세한 내용이 필요한 경우 `VECTOR_LOG` 환경 변수를 사용하여 로그의 수준을 높일 수 있습니다. 기본적으로 `INFO`로 설정되어 있으며, 이는 콘솔에서 `INFO`, `WARNING` 및 `ERROR` 메시지가 표시됨을 의미합니다.
-
-이 옵션을 `DEBUG`로 설정하면 작업자의 내부 프로세스(HTTP 요청 및 수신된 응답 포함)에 대한 자세한 정보를 얻을 수 있습니다. 또한, Datadog 지원팀은 트러블슈팅에 도움이 되는 `DEBUG` 로그를 요청할 수 있습니다. 이러한 로그는 로그 탐색기 및 [진단 로그](#investigate-diagnostic-logs)에도 나타납니다.
-
-## 파이프라인을 통해 진행되는 이벤트를 검사하여 설정 문제를 파악하세요.
-
-OP Worker v1.4.0+를 사용하면 소스, 변환 및 싱크를 통과하는 데이터에 `tap`할 수 있으므로 파이프라인의 각 컴포넌트를 통해 처리되는 원시 데이터를 볼 수 있습니다.
-
-### 옵저버빌리티 파이프라인 작업자 API 사용
-
-옵저버빌리티 파이프라인 작업자 API를 사용하면 `tap` 명령을 사용하여 작업자 프로세스와 상호 작용할 수 있습니다. [설정 가이드][2]에 제공된 Helm 차트를 사용하는 경우 API가 이미 활성화되어 있으며, 그렇지 않은 경우 환경 변수 `DD_OP_API_ENABLED`가 `true`로 설정되어 있는지 확인하세요. 이렇게 설정하면 CLI가 `tap`에 대해 예상하는 대로 API가 `localhost` 및 포트 `8686`를 수신합니다.
-
-### 데이터를 보기 위해 `tap` 사용
-
-작업자와 동일한 호스트에 있는 경우 `tap` 출력에 다음 명령을 실행하세요:
-
-```
-observability-pipelines-worker tap
-```
-
-컨테이너화된 환경을 사용하는 경우 `docker exec` 또는 `kubectl exec` 명령을 사용하여 컨테이너에 shell을 가져와 위의 `tap` 명령을 실행합니다.
-
-### `tap` 사용 예시
-
-다음 예제 설정을 추가합니다. 여기서 `cleanup` 변환은 `log` 속성을 `message`의 복사본으로 만듭니다:
-
-```
-sources:
- demo:
- type: demo_logs
- format: json
-
-transforms:
- cleanup:
- type: remap
- inputs:
- - demo
- source: |-
- .log = .message
-
-sinks:
- blackhole:
- type: blackhole
- inputs:
- - cleanup
- print_interval_secs: 0
-```
-
-다음 명령을 사용하여 예제 설정을 실행하고 `cleanup` 변환의 출력을 확인합니다:
-
-```
-observability-pipelines-worker tap cleanup
-```
-
-예상 출력은 다음과 유사해야 합니다. 여기서 `log` 속성은 `message` 속성의 복사본입니다:
-
-```
-[tap] Pattern 'cleanup' successfully matched.
-{"log":"{\"host\":\"121.142.241.212\",\"user-identifier\":\"meln1ks\",\"datetime\":\"25/Aug/2023:00:07:53\",\"method\":\"OPTION\",\"request\":\"/observability/metrics/production\",\"protocol\":\"HTTP/1.0\",\"status\":\"550\",\"bytes\":3185,\"referer\":\"https://make.us/wp-admin\"}","message":"{\"host\":\"121.142.241.212\",\"user-identifier\":\"meln1ks\",\"datetime\":\"25/Aug/2023:00:07:53\",\"method\":\"OPTION\",\"request\":\"/observability/metrics/production\",\"protocol\":\"HTTP/1.0\",\"status\":\"550\",\"bytes\":3185,\"referer\":\"https://make.us/wp-admin\"}","service":"vector","source_type":"demo_logs","timestamp":"2023-08-25T00:07:53.429855261Z"}
-{"log":"{\"host\":\"117.214.24.224\",\"user-identifier\":\"Karimmove\",\"datetime\":\"25/Aug/2023:00:07:54\",\"method\":\"HEAD\",\"request\":\"/do-not-access/needs-work\",\"protocol\":\"HTTP/2.0\",\"status\":\"503\",\"bytes\":41730,\"referer\":\"https://some.org/wp-admin\"}","message":"{\"host\":\"117.214.24.224\",\"user-identifier\":\"Karimmove\",\"datetime\":\"25/Aug/2023:00:07:54\",\"method\":\"HEAD\",\"request\":\"/do-not-access/needs-work\",\"protocol\":\"HTTP/2.0\",\"status\":\"503\",\"bytes\":41730,\"referer\":\"https://some.org/wp-admin\"}","service":"vector","source_type":"demo_logs","timestamp":"2023-08-25T00:07:54.430584949Z"}
-{"log":"{\"host\":\"108.145.218.149\",\"user-identifier\":\"shaneIxD\",\"datetime\":\"25/Aug/2023:00:07:55\",\"method\":\"DELETE\",\"request\":\"/this/endpoint/prints/money\",\"protocol\":\"HTTP/2.0\",\"status\":\"403\",\"bytes\":18340,\"referer\":\"https://up.de/wp-admin\"}","message":"{\"host\":\"108.145.218.149\",\"user-identifier\":\"shaneIxD\",\"datetime\":\"25/Aug/2023:00:07:55\",\"method\":\"DELETE\",\"request\":\"/this/endpoint/prints/money\",\"protocol\":\"HTTP/2.0\",\"status\":\"403\",\"bytes\":18340,\"referer\":\"https://up.de/wp-admin\"}","service":"vector","source_type":"demo_logs","timestamp":"2023-08-25T00:07:55.430085107Z"}
-```
-
-## 참고 자료
-
-{{< partial name="whats-next/whats-next.html" >}}
-
-[1]: https://app.datadoghq.com/observability-pipelines/
-[2]: /ko/observability_pipelines/setup/
-[3]: /ko/help
\ No newline at end of file
diff --git a/content/ko/tracing/trace_collection/custom_instrumentation/dd_libraries/ruby.md b/content/ko/tracing/trace_collection/custom_instrumentation/dd_libraries/ruby.md
deleted file mode 100644
index 6e044628ce14b..0000000000000
--- a/content/ko/tracing/trace_collection/custom_instrumentation/dd_libraries/ruby.md
+++ /dev/null
@@ -1,307 +0,0 @@
----
-aliases:
-- /ko/tracing/opentracing/ruby
-- /ko/tracing/manual_instrumentation/ruby
-- /ko/tracing/custom_instrumentation/ruby
-- /ko/tracing/setup_overview/custom_instrumentation/ruby
-- /ko/tracing/trace_collection/custom_instrumentation/ruby
-code_lang: 루비(Ruby)
-code_lang_weight: 20
-description: Datadog에 커스텀 트레이스를 전송하여 루비(Ruby) 애플리케이션을 수동 계측합니다.
-further_reading:
-- link: tracing/other_telemetry/connect_logs_and_traces
- tag: 설명서
- text: 로그 및 트레이스를 서로 연결
-- link: tracing/glossary/
- tag: 설명서
- text: 서비스, 리소스 및 트레이스 탐색
-kind: 설명서
-title: Datadog 라이브러리로 루비(Ruby) 커스텀 계측
-type: multi-code-lang
----
-
-
-본 페이지에서는 Datadog 애플리케이션 성능 모니터링(APM)으로 식별 가능성을 추가 및 커스터마이징하는 예시를 자세히 살펴봅니다.
-
-## 태그 추가
-
-[스팬(span)][2]에 커스텀 [스팬(span) 태그][1]를 추가하여 Datadog 내에서 식별 가능성을 커스터마이징합니다. 스팬(span) 태그는 수신받는 트레이스에 적용되어, 관찰한 동작을 판매자 계층, 결제 금액 또는 사용자 ID 등의 코드 수준 정보와 상호 연관시킵니다.
-
-### 커스텀 스팬(span) 태그 추가
-
-애플리케이션 코드 내의 동적 값(예: `customer.id`)에 해당하는 스팬(span)에 커스텀 태그를 추가합니다.
-
-{{< tabs >}}
-{{% tab "Active Span" %}}
-코드 내 메서드에서 현재 활성 [스팬(span)][1]에 접근합니다.
-
-**참고**: 메서드가 호출되었는데 활성 스팬(span)이 없다면 `active_span`은 `nil`입니다.
-
-```ruby
-require 'ddtrace'
-
-# '/shopping_cart/:customer_id', to: 'shopping_cart#index' 가져오기
-class ShoppingCartController < ApplicationController
- # GET /shopping_cart
- def index
- # 활성 스팬을 가져와 customer_id -> 254889로 설정
- Datadog::Tracing.active_span&.set_tag('customer.id', params.permit([:customer_id]))
-
- # [...]
- end
-
- # POST /shopping_cart
- def create
- # [...]
- end
-end
-```
-
-[1]: /ko/tracing/glossary/#spans
-{{% /tab %}}
-
-{{% tab "수동 계측 스팬" %}}
-
-`#set_tag`을 호출하여 `Datadog::Span` 오브젝트에 직접 [태그][1]를 추가합니다:
-
-```ruby
-# Sinatra 엔드포인트 예시,
-# 요청에 관한 Datadog 트레이싱을 통해.
-get '/posts' do
- Datadog::Tracing.trace('web.request') do |span|
- span.set_tag('http.url', request.path)
- span.set_tag('', '')
- end
-end
-```
-
-
-[1]: /ko/tracing/glossary/#span-tags
-{{% /tab %}}
-{{< /tabs >}}
-
-### 모든 스팬(span)에 글로벌 태그 추가
-
-트레이서를 `tags` 옵션으로 설정하여 모든 [스팬(span)][2]에 [태그][1]를 추가합니다:
-
-```ruby
-Datadog.configure do |c|
- c.tags = { 'team' => 'qa' }
-end
-```
-
-`DD_TAGS` 환경변수를 사용하여 애플리케이션의 모든 스팬(span)에 태그를 설정할 수도 있습니다. 루비(Ruby) 환경변수에 대한 자세한 내용을 확인하려면 [설정 문서][3]를 참조하세요.
-
-### 스팬(span)에 오류 설정
-
-스팬(span)에 오류를 설정하는 방법은 다음 두 가지입니다.
-
-- `span.set_error`을 호출하고 예외 오브젝트를 전달합니다. 해당 작업으로 오류 유형, 메시지, 백트레이스가 자동 추출됩니다.
-
-```ruby
-require 'ddtrace'
-require 'timeout'
-
-def example_method
- span = Datadog::Tracing.trace('example.trace')
- puts 'some work'
- sleep(1)
- raise StandardError, "This is an exception"
-rescue StandardError => error
- Datadog::Tracing.active_span&.set_error(error)
- raise
-ensure
- span.finish
-end
-
-example_method()
-```
-
-- 또는 오류 유형, 메시지 및 백트레이스를 설정하는 `tracer.trace`을 기본값으로 사용합니다. 이 동작을 설정하면 `on_error` 옵션을 사용할 수 있는데, 이는 해당 블록이 `trace`에 제공되어 오류가 발생하면 호출되는 핸들러입니다. Proc는 `span`, `error`을 인수로 제공합니다. `on_error`은 기본값으로 스팬(span)에 오류를 설정합니다.
-
-`on_error` 동작 기본값:
-
-```ruby
-require 'ddtrace'
-require 'timeout'
-
-def example_method
- puts 'some work'
- sleep(1)
- raise StandardError, "This is an exception"
-end
-
-Datadog::Tracing.trace('example.trace') do |span|
- example_method()
-end
-```
-
-`on_error` 동작 커스터마이징:
-
-```ruby
-require 'ddtrace'
-require 'timeout'
-
-def example_method
- puts 'some work'
- sleep(1)
- raise StandardError.new "This is a special exception"
-end
-
-custom_error_handler = proc do |span, error|
- span.set_tag('custom_tag', 'custom_value')
- span.set_error(error) unless error.message.include?("a special exception")
-end
-
-Datadog::Tracing.trace('example.trace', on_error: custom_error_handler) do |span|
- example_method()
-end
-```
-
-## 스팬(span) 추가
-
-지원하는 라이브러리 계측([라이브러리 호환성][4] 참조) 방식을 사용하지 않는다면 코드를 수동 계측할 수도 있습니다. 루비(Ruby) 코드를 래핑하는`Datadog::Tracing.trace` 방식을 사용하여 코드에 트레이싱을 추가할 수 있습니다.
-
-루비(Ruby) 코드를 트레이싱하려면 `Datadog::Tracing.trace` 방식을 사용할 수 있습니다.
-
-```ruby
-Datadog::Tracing.trace(name, resource: resource, **options) do |span|
- # 계측하고 싶은 코드에 해당 블록을 래핑합니다.
- # 여기서 스팬(span)을 수정할 수도 있습니다.
- # 예를 들어, 리소스 이름을 변경하거나 태그를 설정합니다.
-end
-```
-
-여기서 `name`은 수행 중인 일반 작업을 설명하는 `String`입니다(예: `'web.request'`, 또는 `'request.parse'`).
-
-`resource`은 동작 중인 작업의 이름이 표시되는 `String`입니다. 동일한 리소스 값을 가진 트레이스는 메트릭 용도별로 그룹화됩니다. 리소스는 대개 URL, 쿼리, 요청 등과 같이 도메인에 따라 특화됩니다(예: Article#submit', http://example.com/articles/list.).
-
-사용 가능한 모든 `**options`을 보려면 [참조 가이드][5]를 확인하세요.
-
-### 신규 스팬(span) 수동 생성
-
-코드 블록에 프로그래밍 방식으로 스팬(span)을 생성합니다. 이렇게 생성한 스팬(span)은 다른 트레이싱 메커니즘과 자동 통합됩니다. 즉, 트레이싱이 이미 시작된 경우, 수동 스팬(span)은 호출자를 부모 스팬(span)으로 설정합니다. 이와 비슷하게, 래핑한 코드 블록에서 호출한 트레이스 메서드는 수동 스팬(span)을 부모로 설정합니다.
-
-```ruby
-# Sinatra 엔드포인트 예시.
-# 요청, 데이터베이스 트레이싱 및
-# 렌더링 단계를 Datadog 트레이싱함.
-get '/posts' do
- Datadog::Tracing.trace('web.request', service: '', resource: 'GET /posts') do |span|
- # 활성 레코드 호출 트레이싱
- Datadog::Tracing.trace('posts.fetch') do
- @posts = Posts.order(created_at: :desc).limit(10)
- end
-
- # APM 태그 추가
- span.set_tag('http.method', request.request_method)
- span.set_tag('posts.count', @posts.length)
-
- # 템플릿 렌더링 트레이싱
- Datadog::Tracing.trace('template.render') do
- erb :index
- end
- end
-end
-```
-
-### 트레이스 후처리
-
-일부 애플리케이션의 경우 Datadog에 전송하기 전에 트레이스를 변경 또는 필터링해야 할 수도 있습니다. 처리 파이프라인을 사용하면 이러한 작업을 정의하는 *프로세서*를 생성할 수 있습니다.
-
-#### 필터링
-
-블록이 트루이면 다음과 같이 `Datadog::Tracing::Pipeline::SpanFilter` 프로세서를 활용하여 스팬(span)을 제거할 수 있습니다:
-
-```ruby
-Datadog::Tracing.before_flush(
- # 특정 리소스와 매치되는 스팬을 제거합니다.
- Datadog::Tracing::Pipeline::SpanFilter.new { |span| span.resource =~ /PingController/ },
- # 로컬 호스트로 트래픽되는 스팬을 제거합니다.
- Datadog::Tracing::Pipeline::SpanFilter.new { |span| span.get_tag('host') == 'localhost' }
-)
-```
-
-#### 처리
-
-`Datadog::Tracing::Pipeline::SpanProcessor` 프로세서를 사용하여 다음과 같이 스팬(span)을 수정할 수도 있습니다:
-
-```ruby
-Datadog::Tracing.before_flush(
- # 리소스 필드에서 매칭되는 텍스트 제거
- Datadog::Tracing::Pipeline::SpanProcessor.new { |span| span.resource.gsub!(/password=.*/, '') }
-)
-```
-
-#### 커스텀 프로세서
-
-프로세서는 `trace`을 인수(`Datadog::Span`의 `Array`)로 받는 `#call`에 응답하는 어떤 오브젝트든 될 수 있습니다.
-
-예를 들어, 다음과 같은 짧은 블록 구문을 사용합니다:
-
-```ruby
-Datadog::Tracing.before_flush do |trace|
- # 처리 로직...
- trace
-end
-```
-
-다음 예제는 복잡한 사후 처리 로직을 실행하는 프로세서를 구현합니다:
-
-```ruby
-Datadog::Tracing.before_flush do |trace|
- trace.spans.each do |span|
- originalPrice = span.get_tag('order.price'))
- discount = span.get_tag('order.discount'))
-
- # 기타 태그 계산으로 태그 설정
- if (originalPrice != nil && discount != nil)
- span.set_tag('order.value', originalPrice - discount)
- end
- end
- trace
-end
-```
-
-커스텀 프로세서 클래스:
-
-```ruby
-class MyCustomProcessor
- def call(trace)
- # 처리 로직...
- trace
- end
-end
-
-Datadog::Tracing.before_flush(MyCustomProcessor.new)
-```
-
-두 경우 모두 프로세서 메서드는 `trace` 오브젝트를 *반드시* 반환해야 하며, 해당 반환값은 파이프라인의 다음 프로세서에 전달됩니다.
-
-
-## 트레이스 클라이언트 및 에이전트 설정
-
-B3 헤더를 사용하여 컨텍스트를 전파할 용도로 트레이싱 클라이언트와 Datadog 에이전트를 모두 추가 설정할 수 있습니다. 아울러, 서비스 상태 점검과 같이 계산 메트릭에 포함하고 싶지 않은 트레이스가 있다면, Datadog으로 트레이스 전송 시 특정 리소스를 제외할 수도 있습니다.
-
-### 헤더를 추출 및 삽입하여 컨텍스트 전파
-
-헤더를 삽입 및 추출하여 분산 트레이스 컨텍스트 전파를 설정할 수 있습니다. 자세한 내용은 확인하려면 [트레이스 컨텍스트 전파][6]를 참조하세요.
-
-
-### 리소스 필터링
-
-서비스 상태 점검과 같이 Datadog에 트레이스를 전송하는 신서틱 트레픽을 제거할 목적으로 리소스 이름별로 트레이스를 제외할 수 있습니다. 해당 설정과 기타 보안 및 미세 조정 설정은 [보안][7] 페이지에서 확인하세요.
-
-## 참고 자료
-
-{{< partial name="whats-next/whats-next.html" >}}
-
-[1]: /ko/tracing/glossary/#span-tags
-[2]: /ko/tracing/glossary/#spans
-[3]: /ko/tracing/setup/ruby/#environment-and-tags
-[4]: /ko/tracing/compatibility_requirements/ruby/
-[5]: /ko/tracing/trace_collection/dd_libraries/ruby/#manual-instrumentation
-[6]: /ko/tracing/trace_collection/trace_context_propagation/ruby/
-[7]: /ko/tracing/security
\ No newline at end of file