diff --git a/content/es/account_management/billing/pricing.md b/content/es/account_management/billing/pricing.md
index e9cf1ca110d..b377b71ba0e 100644
--- a/content/es/account_management/billing/pricing.md
+++ b/content/es/account_management/billing/pricing.md
@@ -1,109 +1,108 @@
---
-description: Comprender los modelos de precios de Datadog y los cálculos de facturación
- de varios productos, incluidos Infrastructure Monitoring, APM, Logs y Synthetic
- Monitoring Tests.
+description: Entienda los modelos de precios de Datadog y los cálculos de facturación
+ para varios productos, incluyendo Infrastructure Monitoring, APM, Logs y Synthetic
+ Tests.
further_reading:
- link: https://www.datadoghq.com/pricing
tag: Precios
text: Precios de Datadog
title: Precios
---
+Datadog tiene muchos planes de precios para adaptarse a sus necesidades. Para más información, consulte la página de [Precios][1]. A menos que se indique lo contrario en su pedido, Datadog calcula las tarifas basadas en el uso del producto durante cada mes calendario. Aquí están las unidades de precios más comunes:
-Datadog ofrece varios planes de precios que se adaptan a tus necesidades. Para obtener más información, consulta la página de [precios][1]. Salvo que indiques lo contrario en tu pedido, el precio que te cobra Datadog se calcula en función del uso que haces del producto durante cada mes calendario. Las unidades de tarificación más comunes son:
+## Infrastructure Monitoring {#infrastructure-monitoring}
-## Monitorización de la infraestructura
+* Un **host** es una instancia de sistema operativo físico o virtual. Cada hora, Datadog registra el número de hosts únicos que está monitoreando en el servicio de Infraestructura.
+ * En un plan de alta marca de agua (HWMP), el conteo facturable de hosts se calcula al final del mes utilizando el conteo máximo (marca de agua alta) del 99 por ciento inferior de uso durante esas horas. Datadog excluye el 1 por ciento superior para reducir el impacto de los picos de uso en su factura.
+ * En un plan híbrido mensual/hora (MHP), Datadog cobra su compromiso mensual mínimo, y por cualquier hora de host por encima de ese compromiso, Datadog cobra una tarifa por hora.
+* Un **contenedor** es un entorno operativo autónomo que incluye software de aplicación y bibliotecas y configuraciones limitadas del sistema operativo. Cada cinco minutos, Datadog registra el número de contenedores únicos que está monitoreando en el servicio de Infraestructura de Datadog. Datadog cobra mensualmente basado en las horas fraccionarias de contenedores monitoreados.
+* Una [**métrica personalizada**][2] es una combinación única y singular de un nombre de métrica, ID de host y cualquier etiqueta. Datadog cobra basado en el promedio mensual de métricas personalizadas únicas enviadas por hora al servicio de Infraestructura de Datadog.
+* Un **dispositivo** es un sensor físico que comprende una o más computadoras de placa única en un marco. Datadog registra y cobra por el número de dispositivos y hosts que está monitoreando simultáneamente en el servicio de Infraestructura de Datadog.
+* Una tarea de AWS **Fargate** es una colección de contenedores configurados a través de la plataforma de orquestación de contenedores ECS de AWS. Datadog registra el número de instancias de tarea que está monitoreando en el servicio de Infraestructura (o APM) de Datadog en intervalos de cinco minutos. Datadog agrega las mediciones basadas en intervalos al final del mes y le cobra según el número total de horas que sus aplicaciones estuvieron en funcionamiento y monitoreadas.
-* Un **host** es una instancia de sistema operativo físico o virtual. Cada hora, Datadog registra el número de hosts únicos que estás monitorizando en el servicio de la infraestructura.
- * En un plan de marca de agua alta (HWMP), el recuento facturable de hosts se calcula al final del mes utilizando el recuento máximo (marca de agua alta) del 99% inferior del consumo de esas horas. Datadog excluye el 1% superior para reducir el impacto de los picos de consumo en tu factura.
- * Con un plan híbrido mensual/hora (MHP), Datadog cobra por el compromiso mensual mínimo que seleccionas y aplica una tarifa horaria por cada hora de host que supera ese compromiso.
-* Un **contenedor** es un entorno operativo autónomo que incluye software de aplicación, además de bibliotecas y configuraciones del sistema operativo limitadas. Cada cinco minutos, Datadog registra el número de contenedores únicos que estás monitorizando en el servicio de la infraestructura de Datadog. Cada mes, Datadog te cobra en función del número de horas proporcionales dedicadas a la monitorización de tus contenedores.
-* Una [**métrica personalizada**][2] es una combinación única de un nombre de métrica, un ID de host y cualquier etiqueta (tag). Datadog te cobra en función del promedio mensual de métricas personalizadas únicas, enviadas al servicio de la infraestructura de Datadog por hora.
-* Un **dispositivo** es un sensor físico que incluye uno o más ordenadores monoplaca en un solo gabinete. Datadog registra y cobra en función del número de dispositivos y hosts que estás monitorizando de forma simultánea en el servicio de la infraestructura de Datadog.
-* Una **tarea de Fargate** de AWS es una recopilación de contenedores configurados a través de la plataforma de orquestación de contenedores ECS de AWS. Datadog registra cada cinco minutos el número de instancias de tareas que estás monitorizando en el servicio Infrastructure (o APM) de Datadog. Datadog suma estas mediciones a final de mes y cobra en función del número total de horas que tus aplicaciones se estuvieron ejecutando y monitorizando.
+## APM {#apm}
-## APM
+* Si una aplicación que se ejecuta en un host (definido en [Infrastructure Monitoring](#infrastructure-monitoring)) genera trazas y las envía a la aplicación SaaS de Datadog, Datadog cuenta ese host como un **APM host**.
+ * En un plan de alta marca de agua (HWMP), Datadog mide la cantidad de hosts por hora. El conteo facturable de hosts se calcula al final del mes utilizando el conteo máximo (marca de agua alta) del 99 por ciento inferior de uso durante esas horas. Datadog excluye el 1 por ciento superior para reducir el impacto de los picos de uso en su factura.
+ * En un plan híbrido mensual/hora (MHP), Datadog cobra su compromiso mensual mínimo, y por cualquier hora de host por encima de ese compromiso, Datadog cobra una tarifa por hora.
+* Un **tramo indexado** es una solicitud individual contra un servicio individual en su pila. Datadog cobra según el número total de tramos indexados por [filtros de retención][3] dentro de Datadog APM.
+* Un **tramo ingerido** es una solicitud individual contra un servicio individual en su pila. Datadog cobra según el número total de gigabytes de tramos ingeridos en Datadog APM.
-* Si una aplicación que se ejecuta en un host (definido en la [monitorización de la infraestructura](#infrastructure-monitoring)) genera trazas (traces) y las envía a la aplicación Datadog SaaS, Datadog contabiliza ese host como un **host de APM**.
- * En un plan de marca de agua alta (HWMP), Datadog mide el recuento de hosts cada hora. El recuento facturable de hosts se calcula al final del mes utilizando el recuento máximo (marca de agua alta) del 99% inferior del uso durante esas horas. Datadog excluye el 1% superior para reducir el impacto de los picos de consumo en tu factura.
- * Con un plan híbrido mensual/hora (MHP), Datadog cobra por el compromiso mensual mínimo que seleccionas y aplica una tarifa horaria por cada hora de host que supera ese compromiso.
-* Un **tramo indexado** es una solicitud individual realizada a un servicio individual de tu stack. Datadog cobra en función del número total de tramos indexados con [filtros de retención][3] en el servicio APM de Datadog.
-* Un **tramo ingerido** es una solicitud individual realizada a un servicio individual de tu stack. Datadog cobra en función del número total de gigabytes de tramos ingeridos en APM de Datadog.
+Puede implementar controles tanto para volúmenes de tramos indexados como ingeridos. Para más información, lea la documentación de [Ingesta de traza][4] y [Retención][5].
-Puedes establecer sistemas de control tanto para los volúmenes de tramos indexados como para los de ingeridos. Para obtener más información, consulta la documentación sobre [Ingesta de trazas][4] y [Retención][5].
+## Database Monitoring {#database-monitoring}
-## Database Monitoring
+* Datadog registra el número de hosts de base de datos únicos que está monitoreando con Database Monitoring de Datadog cada hora.
+ * En un plan de alta marca de agua (HWMP), el conteo facturable de hosts se calcula al final del mes utilizando el conteo máximo (marca de agua alta) del 99 por ciento inferior de uso durante esas horas. Datadog excluye el 1 por ciento superior para reducir el impacto de los picos de uso en su factura.
+ * En un plan híbrido mensual/hora (MHP), Datadog cobra su compromiso mensual mínimo, y por cualquier hora de host por encima de ese compromiso, Datadog cobra una tarifa por hora.
+* Datadog cobra según el número total de [consultas normalizadas][6] configuradas que se están siguiendo en cualquier momento.
-* Datadog registra cada hora el número de hosts de bases de datos únicos que estás monitorizando con la herramienta de monitorización de bases de datos de Datadog.
- * En un plan de marca de agua alta (HWMP), el recuento facturable de hosts se calcula al final del mes utilizando el recuento máximo (marca de agua alta) del 99% inferior del consumo de esas horas. Datadog excluye el 1% superior para reducir el impacto de los picos de consumo en tu factura.
- * Con un plan híbrido mensual/hora (MHP), Datadog cobra por el compromiso mensual mínimo que seleccionas y aplica una tarifa horaria por cada hora de host que supera ese compromiso.
-* Datadog cobra en función del número total de [consultas normalizadas][6] configuradas que se rastrean en un momento dado.
+## Log Management {#log-management}
-## Gestión de logs
+* Un **registro** es un registro basado en texto de la actividad generada por un sistema operativo, una aplicación o por otras fuentes. Datadog cobra por los registros ingeridos en función del número total de gigabytes enviados al servicio de Logs de Datadog.
+* Un **evento de registro** es un registro que es indexado por el servicio de Logs de Datadog. Datadog cobra por cada millón de eventos de registro enviados para indexación a la tarifa designada para la política de retención que seleccionó.
-* Un **log** es un registro basado en texto de la actividad generada por un sistema operativo, una aplicación u otra fuente. Datadog cobra por los logs ingeridos en función del número total de gigabytes enviados al servicio de logs de Datadog.
-* Un **evento de log** es un log indexado por el servicio de logs de Datadog. Datadog cobra por cada millón de eventos de logs enviados para su indexación al precio establecido en la política de retención que hayas elegido.
+## Cloud SIEM {#cloud-siem}
-## Cloud SIEM
+* Un **registro analizado** es un registro en texto de la actividad generada por un sistema operativo, una aplicación o por otras fuentes analizadas para detectar posibles amenazas de seguridad. Datadog cobra por los registros analizados en función de los millones de eventos por mes analizados por el servicio Cloud SIEM de Datadog.
-* Un **log analizado** es un registro basado en texto de la actividad generada por un sistema operativo, una aplicación o por otras fuentes analizadas para detectar posibles amenazas a la seguridad. Datadog cobra por los logs analizados en función de los millones de eventos al mes analizados por el servicio Datadog Cloud SIEM.
+## Synthetic Monitoring {#synthetic-monitoring}
-## Monitorización Synthetic
+* Una **prueba de API** es una solicitud HTTP o HTTPS contra una única URL. Datadog cobra por cada diez mil ejecuciones de pruebas de API realizadas en el servicio Synthetic Monitoring de Datadog.
+* Una **prueba de navegador** es una simulación de una secuencia de acciones de usuario guionadas en una aplicación web utilizando un navegador web virtualizado. Datadog cobra por cada mil pruebas de navegador ejecutadas en el Synthetic Monitoring de Datadog.
+ servicio.
-* Un **test de API** es una solicitud HTTP o HTTPS a través de una única URL. Datadog cobra por cada diez mil tests de API ejecutados al servicio de monitorización Synthetic de Datadog.
-* Un **test de navegador** permite simular una secuencia de comandos de acciones de usuario en una aplicación web utilizando un navegador web virtualizado. Datadog cobra por cada mil tests de navegador ejecutados al servicio de monitorización Synthetic
- de Datadog.
+## Cloud Network Monitoring {#cloud-network-monitoring}
-## Monitorización de redes en la nube
+* Datadog registra el número de **hosts de Cloud Network Monitoring** (CNM) que está monitoreando simultáneamente con el servicio CNM de Datadog una vez por hora.
+ * El conteo facturable de hosts se calcula al final del mes utilizando el conteo máximo (marca de agua alta) del 99 por ciento inferior de uso durante esas horas. Datadog excluye el 1 por ciento superior para reducir el impacto de los picos de uso en su factura.
+* Además, Datadog mide el número total de flujos utilizados por todos los hosts de CNM por mes. Un **flujo** es un registro del tráfico enviado y recibido entre una fuente (IP:Puerto) y un destino (IP:Puerto), medido durante un período de cinco minutos.
-* Datadog registra el número de hosts de **Monitorización de red en la nube** (CNM) que estás monitorizando simultáneamente con el servicio de CNM de Datadog una vez por hora.
- * El recuento facturable de hosts se calcula al final del mes utilizando el recuento máximo (marca de agua alta) del 99% inferior del consumo de esas horas. Datadog excluye el 1% superior para reducir el impacto de los picos de consumo en tu factura.
-* Además, Datadog mide el número total de flujos utilizados por todos los hosts de CNM al mes. Un **flujo** es un registro del tráfico enviado y recibido entre un origen (IP:Puerto) y un destino (IP:Puerto), medido en un periodo de tiempo de cinco minutos.
+## Real User Monitoring {#real-user-monitoring}
-## Real User Monitoring
+* Una **sesión** es un recorrido del usuario en su aplicación web. Expira después de 15 minutos de inactividad o 4 horas de actividad continua.
-* Una **sesión** es un recorrido del usuario en tu aplicación web. Expira tras 15 minutos de inactividad o 4 horas de actividad continua.
+* Datadog recopila todas las páginas visitadas por sus usuarios finales junto con la telemetría que importa: carga de recursos (XHRs, imágenes, archivos CSS, scripts JS, etc.), errores en el frontend y tareas largas. Todo esto está incluido en la sesión del usuario. Datadog cobra por cada mil (1,000) sesiones ingeridas en el servicio de RUM (Real User Monitoring) de Datadog con la siguiente distinción:
-* Datadog recopila todas las páginas visitadas por tus usuarios finales junto con la telemetría que importa: carga de recursos (XHRs, imágenes, archivos CSS, scripts JS, etc), errores de frontend y tareas largas. Todo ello se incluye en la sesión de usuario. Datadog cobra por cada mil (1000) sesiones ingestadas en el servicio Datadog Real User Monitoring (RUM) con la siguiente distinción:
+- [RUM Measure][10]: Se le cobra por las sesiones que se rastrean mediante el SDK y enviadas a Datadog.
+- [RUM without Limits][11]: Se le cobra por separado según el volumen de sesiones que fluyen del SDK a Datadog y el volumen de sesiones que mantiene después de los filtros de retención.
-- [Medida RUM][10]: se te cobran las sesiones rastreadas por kit de desarrollo de software (SDK) y enviadas a Datadog.
-- [RUM without Limits][11]: se te cobra por separado en función del volumen de sesiones que fluyen desde el kit de desarrollo de software (SDK) a Datadog, y del volumen de sesiones que mantienes después de los filtros de retención.
+## Continuous Profiler {#continuous-profiler}
-## Continuous Profiler
+* Datadog registra el número de servidores únicos de Continuous Profiler que se están monitoreando simultáneamente con el servicio de Continuous Profiler de Datadog una vez por hora.
+ * El conteo facturable de servidores se calcula al final del mes utilizando el conteo máximo (marca de agua alta) del 99 por ciento inferior de uso durante esas horas. Datadog excluye el 1 por ciento superior para reducir el impacto de los picos de uso en su factura.
+ * Cada servidor puede tener hasta cuatro contenedores perfilados de forma gratuita. Los contenedores adicionales se cobran a $2 por contenedor.
+ **Nota**: Esta asignación se agrega a nivel global en todos los servidores, por lo que, si en promedio tiene cuatro contenedores en total, no se le cobra como si tuviera más en cada servidor.
+* Datadog mide el número total de contenedores que están siendo perfilados. Un contenedor es un entorno operativo autónomo que incluye software de aplicación y bibliotecas y configuraciones limitadas del sistema operativo. Cada cinco minutos, Datadog registra el número de contenedores únicos que se están monitoreando en el servicio Continuous Profiler de Datadog. Datadog cobra mensualmente basado en las horas fraccionarias de contenedores monitoreados. Para Continuous Profiler, Datadog solo cuenta para el total de contenedores monitoreados aquellos que están ejecutando el servicio de Continuous Profiler.
-* Datadog registra una vez por hora el número de hosts únicos de Continuous Profiler que estás monitorizando de forma simultánea con el servicio Continuous Profiler de Datadog.
- * El recuento facturable de hosts se calcula al final del mes utilizando el recuento máximo (marca de agua alta) del 99% inferior del consumo de esas horas. Datadog excluye el 1% superior para reducir el impacto de los picos de consumo en tu factura.
- * Cada host incluye hasta cuatro contenedores perfilados de forma gratuita. Cada contenedor adicional cuesta 2 $.
- **Nota**: Esta cuota se acumula para todos los hosts. Si tienes un promedio de cuatro contenedores en todos tus hosts, no se te cobrará si en algún host tienes contenedores adicionales.
-* Datadog mide el número total de contenedores que están siendo perfilados. Un contenedor es un entorno operativo autónomo que incluye software de aplicación y bibliotecas y configuraciones del sistema operativo limitadas. Una vez cada cinco minutos, Datadog registra el número de contenedores únicos que estás monitorizando en el servicio Continuous Profiler de Datadog. Cada mes, Datadog cobra en función del número de horas que dedica a la monitorización de tus contenedores, calculado de forma proporcional. Para Continuous Profiler, Datadog solo contabiliza aquellos contenedores que ejecutan el servicio Continuous Profiler en el recuento total de contenedores monitorizados.
+## Incident Management {#incident-management}
-## Gestión de incidencias
+* Para organizaciones en un plan basado en asientos, Datadog cobra según el compromiso de asientos de su organización.
+* Para organizaciones en el plan legado basado en uso, Datadog rastrea el número de usuarios activos mensuales de Incident Management.
+ * Datadog cuenta a un usuario como un **usuario activo** si ha utilizado las capacidades de Datadog para contribuir de manera sustantiva a la respuesta a incidentes. Por ejemplo, usted se convierte en un usuario activo durante el mes cuando:
+ * Actualice el estado, la gravedad u otros campos de un incidente
+ * Comente en la línea de tiempo del incidente
+ * Envíe notificaciones de incidentes
+ * Agregue respondedores o asigne tipos de respondedores
+ * Cree, modifique o asigne seguimientos de incidentes
+ * Genere un postmortem
+ * _No se convierte en un usuario activo cuando:_
+ * Declare, visualice o busque incidentes
+ * Únase a canales, reuniones o llamadas de terceros que estén conectados al incidente
+ * Publique mensajes en el canal de Slack del incidente o en el canal de Microsoft Teams (incluso si el mensaje se sincroniza automáticamente con la línea de tiempo del incidente)
-* Para las organizaciones con un plan basado en el número de plazas, Datadog cobra en función del número de plazas comprometidas por la organización.
-* En el caso de las organizaciones con el antiguo plan basado en el uso, Datadog realiza un seguimiento del número de usuarios activos mensuales de Incident Management.
- * Datadog cuenta a un usuario como **usuario activo** si ha utilizado las funciones de Datadog para contribuir sustancialmente a la respuesta ante incidentes. Por ejemplo, te conviertes en un usuario activo para el mes al:
- * Actualizar el estado, la gravedad u otros campos del incidente
- * Comentar la cronología del incidente
- * Enviar notificaciones del incidente
- * Añadir respondedores o asignar tipos de respondedores
- * Crear, modificar o asignar seguimientos del incidente)
- * Generar un informe retrospectivo
- * _No_ te conviertes en usuario activo cuando:
- * Declarar, visualizar o buscar incidentes
- * Unirse a canales, reuniones o llamadas de terceros que estén conectados al incidente
- * Publicar mensajes en el canal de Slack del incidente o en el canal de Microsoft Teams (incluso si el mensaje se sincroniza automáticamente con la cronología del incidente).
+## CI Visibility {#ci-visibility}
-## CI Visibility
+* Datadog rastrea el número de contribuyentes únicos que envían datos de prueba y de pipeline al servicio CI Visibility.
+* Un **contribuyente** se define como un contribuyente activo de git, identificado por su dirección de correo electrónico de autor de git. Un contribuyente se cuenta para la facturación si realiza al menos tres confirmaciones en un mes determinado.
+ * En el caso de que un pipeline no esté asociado con un repositorio de git, o si los metadatos de git no están disponibles, se utiliza el nombre de usuario de la persona que activa la ejecución del pipeline como el contribuyente facturable.
+* Para Pipeline Visibility, cada pipeline, etapa de pipeline y trabajo de pipeline cuenta como un **span de pipeline**. Para Testing Visibility, cada ejecución de prueba individual cuenta como un **span de prueba**.
-* Datadog rastrea el número de responsables de commit únicos que envían datos de tests y pipelines al servicio CI Visibility.
-* Un **responsable de commit** es un desarrollador git activo, identificado por su dirección de correo electrónico git. Un responsable de commit se contabiliza a efectos de facturación si realiza al menos tres commits en un mes determinado.
- * Si un pipeline no está asociado a un repositorio git, o los metadatos git no están disponibles, se utilizará como responsable de commit facturable el nombre de usuario de la persona que activó la ejecución del pipeline.
-* Con respecto a la visibilidad del pipeline, cada pipeline, cada fase del pipeline y cada tarea del pipeline se contabiliza como un **tramo de pipeline**. En lo que respecta a la visibilidad de los tests, cada ejecución de test se contabiliza como un **tramo de test**.
+## Solución de problemas {#troubleshooting}
-## Solucionar problemas
+Para preguntas técnicas, contacte a [Datadog support][7].
-Si tienes alguna pregunta técnica, ponte en contacto con el [equipo de asistencia de Datadog][7].
-
-Contacta con [ventas][8] o con tu gestor de [satisfacción al cliente][9] para informarte sobre los precios por hora o la facturación de tu cuenta.
+Contacte a [Sales][8] o a su [Customer Success][9] Manager para discutir precios por hora o facturación de su cuenta.
[1]: https://www.datadoghq.com/pricing
[2]: /es/metrics/custom_metrics/
diff --git a/content/es/account_management/saml/_index.md b/content/es/account_management/saml/_index.md
index bd5790ae389..45af470a310 100644
--- a/content/es/account_management/saml/_index.md
+++ b/content/es/account_management/saml/_index.md
@@ -4,187 +4,145 @@ algolia:
- saml
aliases:
- /es/guides/saml
-description: Configura la autenticación SAML para Datadog con proveedores de identidad
+description: Configure la autenticación SAML para Datadog con proveedores de identidad
como Active Directory, Auth0, Google, Okta y Microsoft Entra ID para un inicio de
sesión único seguro.
further_reading:
- link: /account_management/multi_organization/
tag: Documentación
- text: Configurar equipos y organizaciones con varias cuentas
-title: Inicio de sesión único con SAML
+ text: Configurando Teams y Organizaciones con Múltiples Cuentas
+title: Inicio de Sesión Único con SAML
---
-{{< site-region region="gov" >}}
-El sitio Datadog for Government solo admite el inicio de sesión SAML.
+{{< site-region region="gov,gov2" >}}
+El sitio de Datadog para Gobierno solo admite inicio de sesión SAML.
{{< /site-region >}}
-## Información general
+## Descripción general {#overview}
-La configuración de [SAML (Security Assertion Markup Language)][1] para tu cuenta Datadog te permite a ti y a todos tus compañeros de equipo iniciar sesión en Datadog utilizando las credenciales almacenadas en Active Directory, LDAP u otro almacén de identidades de tu organización que se haya configurado con un proveedor de identidades SAML.
+Configurar [SAML (Security Assertion Markup Language)][1] para su cuenta de Datadog permite que usted y todos sus compañeros inicien sesión en Datadog utilizando las credenciales almacenadas en el Active Directory de su organización, LDAP u otro almacén de identidad que haya sido configurado con un Proveedor de Identidad SAML.
**Notas**:
{{% site-region region="us,us3,us5,eu,ap1,ap2" %}}
-- Si no tienes SAML activado en tu cuenta de Datadog, ponte en contacto con el [servicio de asistencia][2] para activarlo.
-- Esta documentación asume que ya tienes un proveedor de identidad (IdP) SAML. Si no tienes un IdP SAML, hay varios IdP que tienen integraciones con Datadog como [Active Directory][3], [Auth0][4], [Google][5], [LastPass][6], [Microsoft Entra ID][3], [Okta][7] y [SafeNet][8].
-- La configuración de SAML requiere acceso a [Datadog Administrator][9].
+- Si no tiene SAML habilitado en su cuenta de Datadog, contacte a [soporte][2] para habilitarlo.
{{% /site-region %}}
+- Esta documentación asume que ya tiene un Proveedor de Identidad SAML (IdP). Si no tiene un IdP SAML, hay varios IdPs que tienen integraciones con Datadog, como [Active Directory][3], [Auth0][4], [Google][5], [LastPass][6], [Microsoft Entra ID][3], [Okta][7] y [SafeNet][8].
+- La configuración de SAML requiere acceso de [Datadog Administrator][9].
-{{% site-region region="gov" %}}
-- Esta documentación asume que ya tienes un proveedor de identidad (IdP) SAML. Si no tienes un IdP SAML, hay varios IdP que tienen integraciones con Datadog, como [Active Directory][3], [Auth0][4], [Google][5], [LastPass][6], [Microsoft Entra ID][3], [Okta][7] y [SafeNet][8].
-- La configuración de SAML requiere acceso a [Datadog Administrator][9].
-{{% /site-region %}}
-
-## Configuración de SAML
-
-1. Para comenzar la configuración, consulta la documentación de tu IdP:
-
- * [Active Directory][10]
- * [Auth0][11]
- * [Google][13]
- * [Microsoft Entra ID][12]
- * [NoPassword][14]
- * [Okta][15]
- * [SafeNet][16]
-
-2. En la aplicación Datadog, coloca el cursor sobre tu nombre de usuario en la esquina inferior izquierda y selecciona Organization Settings (Parámetros de la organización). Selecciona [Login Methods (Métodos de inicio de sesión)][17] y haz clic en **Configure** (Configurar) en SAML.
-
-3. Carga los metadatos de IdP de tu proveedor de identidad SAML haciendo clic en el botón **Choose File** (Seleccionar archivo). Después de elegir el archivo, haz clic en **Upload File** (Cargar archivo).
-
-**Nota:** Los metadatos de IdP deben contener únicamente caracteres ASCII.
-
-4. Descarga [metadatos del proveedor de servicios][18] de Datadog para configurar tu IdP de modo que reconozca a Datadog como proveedor de servicios.
-
-5. Después de cargar los metadatos IdP y configurar su IdP, active SAML en Datadog haciendo clic en el botón **Cargar y activar**.
- {{< img src="account_management/saml/saml_enable_cropped.png" alt="Configurar SAML cargando los metadatos de tu IdP" >}}
-
-6. Después de cargar los metadatos de IdP, vuelve a la página Login Methods (Métodos de inicio de sesión) y activa SAML `on` por defecto.
+## Configuración de SAML {#configuring-saml}
-**Nota**: Para configurar SAML para varias organizaciones, consulta [Gestión de cuentas de varias organizaciones][21].
+Consulte [Configurar el inicio de sesión único con SAML][2] para obtener instrucciones.
-## Uso de SAML
+## Uso de SAML {#using-saml}
-Una vez que SAML está configurado en Datadog y tu IdP está configurado para aceptar solicitudes de Datadog, los usuarios pueden acceder a log.
+Después de que SAML esté configurado en Datadog y su IdP esté configurado para aceptar solicitudes de Datadog, los usuarios pueden iniciar sesión.
-### Inicio de sesión por el PS
+### Inicio de sesión iniciado por SP {#sp-initiated-login}
-Iniciado por el PS o por el Proveedor de servicio se refiere a un inicio de sesión iniciado desde Datadog. Los usuarios inician sesión a través de la **URL de inicio de sesión único** mostrada en el cuadro de estado en la parte superior de la [página Configuración de SAML][19]. La **URL de inicio de sesión único** también se muestra en la [página Equipo][20]. Al cargar esta URL se inicia una autenticación SAML con tu IdP. **Nota**: Esta URL solo se muestra si SAML está habilitado para tu cuenta y estás utilizando el inicio de sesión iniciado por el PS.
+SP-initiated, o iniciado por el Proveedor de Servicios, significa que el inicio de sesión se realiza desde Datadog. Los usuarios inician sesión a través del {{< ui >}}Single Sign-on URL{{< /ui >}} que se muestra en el cuadro de estado en la parte superior de la [SAML Configuration page][4]. Cargar esta URL inicia una autenticación SAML contra su IdP. **Nota**: Esta URL solo se muestra si SAML está habilitado para su cuenta y está utilizando inicio de sesión iniciado por SP.
{{< img src="account_management/saml/saml_enabled_cropped.png" alt="Confirmación de que SAML está habilitado" >}}
-Cuando un usuario inicia sesión a través de SAML iniciado por el PS y la organización no tiene un subdominio personalizado, Datadog requiere seguridad adicional. Los usuarios reciben un único código de verificación por correo electrónico que es necesario para iniciar la sesión.
+Cuando un usuario inicia sesión a través de SAML iniciado por SP y la organización no tiene un subdominio personalizado, Datadog requiere seguridad adicional. Los usuarios reciben un código de verificación por correo electrónico de un solo uso que es necesario para iniciar sesión.
-### Inicio de sesión iniciado por el IdP
+### Inicio de sesión iniciado por IdP {#idp-initiated-login}
-Iniciado por el IdP o por el Proveedor de identidad se refiere a un inicio de sesión iniciado desde tu portal de aplicaciones. Los usuarios inician sesión haciendo clic en el icono de la aplicación en tu portal de aplicaciones, por ejemplo, en el cajón de Google App o en el portal de aplicaciones de Okta. Los usuarios con inicio de sesión iniciado por el PS también pueden utilizar el inicio de sesión iniciado por el IdP, dependiendo de la configuración de su proveedor de identidad.
+IdP-initiated, o iniciado por el Proveedor de Identidad, significa que el inicio de sesión se realiza desde el portal de su aplicación. Los usuarios inician sesión haciendo clic en el ícono de la app en su app portal, por ejemplo, en el Google App drawer o en el Okta App Portal. Los usuarios de inicio de sesión iniciado por SP también pueden utilizar el inicio de sesión iniciado por IdP, dependiendo de la configuración de su Proveedor de Identidad.
-## Aserciones y atributos
+## Afirmaciones y Atributos {#assertions-and-attributes}
-Cuando se produce un inicio de sesión, el proveedor de identidad envía a Datadog una aserción SAML que contiene la autorización del usuario.
+Cuando ocurre un inicio de sesión, una Afirmación SAML que contiene la autorización del usuario se envía desde el proveedor de identidad a Datadog.
-### Capacidades
+### Capacidades {#capabilities}
-* Datadog soporta el enlace **HTTP-POST** para **SAML2**:
+* Datadog admite el enlace **HTTP-POST** para **SAML2**:
`urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST`.
-* Datadog especifica `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress` para el formato del **NameIDPolicy** en solicitudes de aserción.
+* Datadog especifica `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress` para el formato de la **NameIDPolicy** en las solicitudes de afirmación.
-### Requisitos
+### Requisitos {#requirements}
-* Las aserciones deben estar firmadas.
-* Las aserciones pueden estar cifradas, pero se aceptan aserciones sin cifrar.
-* Consulta los [metadatos de proveedores de servicios de Datadog][18] para obtener más información. Debes iniciar sesión en Datadog para acceder al archivo.
+* Las Afirmaciones deben estar firmadas.
+* Las Afirmaciones pueden estar encriptadas, pero se aceptan Afirmaciones no encriptadas.
+* Referencia [metadatos del Proveedor de Servicio de Datadog][3] para más información. Debe haber iniciado sesión en Datadog para acceder al archivo.
-### Atributos compatibles
+### Atributos Soportados {#supported-attributes}
-Es posible incluir atributos en una aserción SAML. Datadog busca tres atributos en un `AttributeStatement`:
+Los atributos pueden incluirse en una afirmación SAML. Datadog busca tres atributos en un `AttributeStatement`:
- 1. **eduPersonPrincipalName**: Si se especifica, el eduPersonPrincipalName debe corresponder al nombre de usuario del usuario Datadog. El nombre de usuario suele ser la dirección de correo electrónico del usuario.
- 2. **sn**: Es opcional y debe configurarse con el apellido del usuario.
- 3. **givenName**: Es opcional y debe ser el nombre del usuario.
+ 1. **eduPersonPrincipalName**: Si se especifica, el eduPersonPrincipalName debe corresponder al nombre de usuario de Datadog del usuario. El nombre de usuario es típicamente la dirección de correo electrónico del usuario.
+ 2. **sn**: Esto es opcional y debe establecerse como el apellido del usuario.
+ 3. **givenName**: Esto es opcional y debe establecerse como el nombre de pila del usuario.
-Para el IdP de Microsoft Entra ID, utiliza el atributo `surname` en lugar de `sn` en la aserción.
+Para el IdP de Microsoft Entra ID, utilice el atributo `surname` en lugar de `sn` en la afirmación.
-Datadog espera que los atributos utilicen el URI NameFormat `urn:oasis:names:tc:SAML:2.0:attrname-format:uri` o el NameFormat básico `urn:oasis:names:tc:SAML:2.0:attrname-format:basic`. El nombre utilizado para cada atributo depende del NameFormat que utilice tu IdP.
+Datadog espera que los atributos usen el URI NameFormat `urn:oasis:names:tc:SAML:2.0:attrname-format:uri` o el Basic NameFormat `urn:oasis:names:tc:SAML:2.0:attrname-format:basic`. El nombre utilizado para cada atributo depende del NameFormat que utiliza su IdP.
-Si tu IdP está configurado para utilizar el URI NameFormat `urn:oasis:names:tc:SAML:2.0:attrname-format:uri`:
+Si su IdP está configurado para usar el URI NameFormat `urn:oasis:names:tc:SAML:2.0:attrname-format:uri`:
- 1. **eduPersonPrincipalName**: el IdP debe establecer `urn:oid:1.3.6.1.4.1.5923.1.1.1.6` como nombre del atributo.
- 2. **sn**: el IdP debe establecer `urn:oid:2.5.4.4` como nombre del atributo.
- 3. **givenName**: el IdP debe establecer `urn:oid:2.5.4.42` como nombre del atributo.
+ 1. **eduPersonPrincipalName**: El IdP debe establecer `urn:oid:1.3.6.1.4.1.5923.1.1.1.6` como el nombre del atributo.
+ 2. **sn**: El IdP debe establecer `urn:oid:2.5.4.4` como el nombre del atributo.
+ 3. **givenName**: El IdP debe establecer `urn:oid:2.5.4.42` como el nombre del atributo.
-Si tu IdP está configurado para utilizar el NameFormat básico `urn:oasis:names:tc:SAML:2.0:attrname-format:basic`:
+Si su IdP está configurado para usar el Basic NameFormat `urn:oasis:names:tc:SAML:2.0:attrname-format:basic`:
- 1. **eduPersonPrincipalName**: el IdP debe establecer `urn:mace:dir:attribute-def:eduPersonPrincipalName` como nombre del atributo.
- 2. **sn**: el IdP debe establecer `urn:mace:dir:attribute-def:sn` como nombre del atributo.
- 3. **givenName**: el IdP debe establecer `urn:mace:dir:attribute-def:givenName` como nombre del atributo.
+ 1. **eduPersonPrincipalName**: El IdP debe establecer `urn:mace:dir:attribute-def:eduPersonPrincipalName` como el nombre del atributo.
+ 2. **sn**: El IdP debe establecer `urn:mace:dir:attribute-def:sn` como el nombre del atributo.
+ 3. **givenName**: El IdP debe establecer `urn:mace:dir:attribute-def:givenName` como el nombre del atributo.
-Si **eduPersonPrincipalName** existe en el AttributeStatement, el valor de este atributo se utiliza para el nombre de usuario. Si **eduPersonPrincipalName** no está incluido en el AttributeStatement, el nombre de usuario se toma del NameID en el Subject. El NameID debe utilizar el formato `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress`.
+Si **eduPersonPrincipalName** existe en el AttributeStatement, el valor de este atributo se utiliza para el nombre de usuario. Si **eduPersonPrincipalName** no está incluido en el AttributeStatement, el nombre de usuario se toma del NameID en el Subject. El NameID debe usar el formato `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress`.
-Si se proporcionan **sn** y **givenName**, se utilizan para actualizar el nombre del usuario en su perfil de Datadog.
+Si **sn** y **givenName** son proporcionados, se utilizan para actualizar el nombre del usuario en su perfil de Datadog.
-## Funciones adicionales
+## Características adicionales {#additional-features}
-Para asignar atributos en la respuesta de tu proveedor de identidad a los roles y equipos de Datadog, consulta [asignación de grupo SAML][22].
+Para mapear atributos en la respuesta de su proveedor de identidad a los roles y Teams de Datadog, consulte [mapeo de grupos SAML][5].
-Las siguientes funciones pueden activarse a través del [cuadro de diálogo de configuración de SAML][19]:
+Las siguientes características se pueden habilitar a través del [SAML Configuration dialog][4]:
-**Nota:** Debes tener permisos de administrador para ver el cuadro de diálogo de configuración de SAML.
+**Nota:** Debe tener permisos de administrador para ver el SAML Configuration dialog.
-### Suministro justo a tiempo (JIT)
+### Provisionamiento justo a tiempo (JIT) {#just-in-time-jit-provisioning}
-Con el suministro JIT, un usuario se crea en Datadog la primera vez que intenta iniciar sesión. Esto elimina la necesidad de que los administradores creen manualmente las cuentas de usuario una a la vez. En este caso, no se envía el correo electrónico de invitación.
+Con el provisionamiento JIT, un usuario se crea dentro de Datadog la primera vez que intenta iniciar sesión. Esto elimina la necesidad de que los administradores creen cuentas de usuario manualmente una por una. El correo electrónico de invitación no se envía en este caso.
-Es posible que algunas organizaciones no deseen invitar a todos sus usuarios a Datadog. Si deseas realizar cambios en el funcionamiento de SAML para tu cuenta, ponte en contacto con el [soporte de Datadog][2]. Depende de la organización configurar que su IdP no envíe aserciones a Datadog si no desea que un usuario concreto acceda a Datadog.
+Algunas organizaciones pueden no querer invitar a todos sus usuarios a Datadog. Si desea realizar cambios en cómo funciona SAML para su cuenta, comuníquese con [Datadog support][2]. Corresponde a la organización configurar su IdP para que no envíe afirmaciones a Datadog si no desea que un usuario en particular acceda a Datadog.
-Los administradores pueden establecer la función por defecto de los nuevos usuarios JIT. El rol por defecto es **Standard** (Estándar), pero puedes elegir añadir nuevos usuarios JIT como **Read-Only** (Solo lectura), **Administrators** (Administradores) o cualquier rol personalizado.
+Los administradores pueden establecer el rol predeterminado para nuevos usuarios JIT. El rol predeterminado es {{< ui >}}Standard{{< /ui >}}, pero puede optar por agregar nuevos usuarios JIT como {{< ui >}}Read-Only{{< /ui >}}, {{< ui >}}Administrators{{< /ui >}} o cualquier rol personalizado.
- Importante: Si Role Mapping está activado, tiene prioridad sobre los roles definidos durante el aprovisionamiento de JIT. Sin las sentencias de atributo de grupo adecuadas, los usuarios podrían quedarse sin roles y perder el acceso a Datadog. Para evitar que los usuarios queden bloqueados tras el aprovisionamiento de JIT, asegúrate de revisar las definiciones de asignación y comprobar las aserciones antes de habilitar tanto las asignaciones como JIT.
+ Importante: Si el mapeo de roles está habilitado, tiene prioridad sobre los roles establecidos durante el provisionamiento JIT. Sin las declaraciones de atributo de grupo adecuadas, los usuarios pueden terminar sin roles y perder el acceso a Datadog. Para evitar que los usuarios queden bloqueados después del provisionamiento JIT, asegúrese de revisar sus definiciones de mapeo y verificar sus afirmaciones antes de habilitar tanto los Mapeos como JIT.
-{{< img src="account_management/saml/saml_jit_default.png" alt="saml JIT predeterminado" style="width:50%;" >}}
+{{< img src="account_management/saml/saml_jit_default.png" alt="SAML JIT Predeterminado" style="width:50%;" >}}
-### Inicio de sesión iniciado por IdP
+### Inicio de sesión iniciado por IdP {#idp-initiated-login-1}
-Cuando se carga la URL de Datadog, el navegador es redirigido al IdP del cliente donde el usuario introduce sus credenciales, después el IdP lo redirige de nuevo a Datadog. Algunos IdP tienen la capacidad de enviar una aserción directamente a Datadog sin obtener primero una AuthnRequest (inicio de sesión iniciado por el IdP).
+Cuando se carga la URL de Datadog, el navegador es redirigido al IdP del cliente donde el usuario introduce sus credenciales, luego el IdP redirige de vuelta a Datadog. Algunos IdP tienen la capacidad de enviar una aserción directamente a Datadog sin primero obtener una AuthnRequest (inicio de sesión iniciado por el IdP).
-Tras activar la función de inicio de sesión iniciado por el IdP y guardar tu configuración, puedes descargar la última versión de los metadatos del proveedor de servicio (SP) para tu proveedor de identidades. Tus nuevos metadatos SP contienen un endpoint `AssertionConsumerService` diferente y específico de la organización al que enviar aserciones.
+Después de habilitar la función de inicio de sesión iniciado por el IdP y guardar su configuración, puede descargar la última versión de los metadatos del Proveedor de Servicios (SP) para su Proveedor de Identidad. Sus nuevos metadatos de SP contienen un punto de conexión específico de la organización `AssertionConsumerService` para enviar aserciones.
-Si no utilizas los metadatos del SP actualizados, Datadog no podrá asociar la aserción con tu organización y mostrará una página de error con el mensaje de que a la respuesta SAML le falta el atributo "InResponseTo".
+Si no utiliza los metadatos de SP actualizados, Datadog no podrá asociar la aserción con su organización y mostrará una página de error con un mensaje que indica que a la respuesta SAML le falta el atributo "InResponseTo".
-### SAML estricto
+### SAML estricto {#saml-strict}
-Puedes hacer que tu organización sea SAML Strict deshabilitando otros tipos de métodos de inicio de sesión en la interfaz de usuario **Login Methods** (Métodos de inicio de sesión). Cuando se configura esta opción, todos los usuarios deben, por defecto, iniciar sesión con SAML. Un nombre de usuario/contraseña existente o un inicio de sesión Google OAuth no funcionan. Esto garantiza que todos los usuarios con acceso a Datadog deben tener credenciales válidas en el servicio de proveedor/directorio de identidad de tu empresa para acceder a tu cuenta Datadog. Los administradores de la organización pueden establecer [overrides (anulaciones)][23] por usuario para permitir que determinados usuarios estén exentos de SAML Strict.
+Puede hacer que su organización sea SAML estricto deshabilitando otros tipos de métodos de inicio de sesión en la UI {{< ui >}}Login Methods{{< /ui >}}. Cuando esta opción está configurada, todos los usuarios deben, por defecto, iniciar sesión con SAML. Un nombre de usuario y contraseña existentes, o el inicio de sesión de Google OAuth, no funcionan. Esto asegura que todos los usuarios con acceso a Datadog deben tener credenciales válidas en el proveedor de identidad o servicio de directorio de su empresa para acceder a su cuenta de Datadog. Los administradores de la organización pueden establecer [excepciones][6] por usuario para permitir que ciertos usuarios estén exentos de SAML Estricto.
-### Metadatos del SP de Datadog autoactualizables
+### Metadatos de SP de Datadog autoactualizables {#self-updating-datadog-sp-metadata}
-Algunos proveedores de identidades (como ADFS de Microsoft) pueden configurarse para obtener los últimos metadatos del proveedor de servicio SAML de Datadog. Después de configurar SAML en Datadog, puedes obtener la URL de metadatos para tu organización de la página configuración de SAML y utilizarla con tu Proveedor de identidades para obtener los últimos metadatos del proveedor de servicio cada vez que se publiquen cambios.
+Ciertos Proveedores de Identidad (como ADFS de Microsoft) pueden configurarse para obtener los últimos metadatos del proveedor de servicios SAML de Datadog. Después de configurar SAML en Datadog, puede obtener la URL de metadatos para su organización desde la página de Configuración de SAML y usarla con su Proveedor de Identidad para obtener los últimos metadatos del proveedor de servicios cada vez que se publiquen cambios.
-{{< img src="account_management/saml/saml_metadata_url.png" alt="URL de metadatos de SAML" style="width:50%;" >}}
+{{< img src="account_management/saml/saml_metadata_url.png" alt="URL de Metadatos SAML" style="width:50%;" >}}
-## Referencias adicionales
+## Lectura adicional {#further-reading}
{{< partial name="whats-next/whats-next.html" >}}
[1]: http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language
-[2]: /es/help/
-[3]: https://learn.microsoft.com/en-us/entra/architecture/auth-saml
-[4]: https://auth0.com/docs/protocols/saml-protocol
-[5]: https://cloud.google.com/architecture/identity/single-sign-on
-[6]: https://support.logmeininc.com/lastpass/help/lastpass-admin-toolkit-using-single-sign-on-sso
+[2]: /es/account_management/saml/configuration
+[3]: https://app.datadoghq.com/account/saml/metadata.xml
+[4]: https://app.datadoghq.com/organization-settings/login-methods/saml
+[5]: /es/account_management/saml/mapping/
+[6]: /es/account_management/login_methods/#reviewing-user-overrides
[7]: https://developer.okta.com/docs/concepts/saml/
[8]: https://thalesdocs.com/sta/operator/applications/apps_saml/index.html
-[9]: /es/account_management/users/default_roles/
-[10]: /es/account_management/saml/activedirectory/
-[11]: /es/account_management/saml/auth0/
-[12]: /es/account_management/saml/entra/
-[13]: /es/account_management/saml/google/
-[14]: /es/account_management/saml/nopassword/
-[15]: /es/account_management/saml/okta/
-[16]: /es/account_management/saml/safenet/
-[17]: https://app.datadoghq.com/organization-settings/login-methods
-[18]: https://app.datadoghq.com/account/saml/metadata.xml
-[19]: https://app.datadoghq.com/saml/saml_setup
-[20]: https://app.datadoghq.com/account/team
-[21]: /es/account_management/multi_organization/#setting-up-saml
-[22]: /es/account_management/saml/mapping/
-[23]: /es/account_management/login_methods/#reviewing-user-overrides
\ No newline at end of file
+[9]: /es/account_management/users/default_roles/
\ No newline at end of file
diff --git a/content/es/agent/configuration/proxy.md b/content/es/agent/configuration/proxy.md
index 5d55537620f..43869b71b16 100644
--- a/content/es/agent/configuration/proxy.md
+++ b/content/es/agent/configuration/proxy.md
@@ -1,1305 +1,111 @@
---
algolia:
tags:
- - proxy del Agent
+ - agent proxy
aliases:
- /es/account_management/faq/can-i-use-a-proxy-to-connect-my-servers-to-datadog/
- /es/agent/proxy
+description: Configure el Datadog Agent para enviar tráfico a través de proxies HTTP/HTTPS,
+ con opciones de autenticación y de omisión.
further_reading:
- link: /logs/
tag: Documentación
- text: Recopilar logs
+ text: Recopile sus registros
- link: /infrastructure/process/
tag: Documentación
- text: Recopilar procesos
+ text: Recopile sus procesos
- link: /tracing/
tag: Documentación
- text: Recopilar trazas (traces) y perfiles
-- link: /agent/configuration/agent-fips-proxy
+ text: Recopile sus trazas y perfiles
+- link: /agent/configuration/fips-compliance
tag: Documentación
text: Cumplimiento de FIPS de Datadog
-title: Configuración del proxy del Agent
+title: Configuración del Proxy del Agente de Datadog
---
+Puede configurar el Datadog Agent para enviar tráfico a través de un proxy HTTP/HTTPS. Un proxy se utiliza típicamente para enviar tráfico desde un servidor que no está conectado directamente a la Internet pública.
-## Información general
+## Configure el Datadog Agent {#configure-the-datadog-agent}
-Si tu configuración de red restringe el tráfico de salida, redirige mediante proxy todo el tráfico del Agent a través de uno o varios hosts que tengan políticas de salida más permisivas.
+Hay dos opciones para configurar el Datadog Agent para usar un proxy.
+- Puede usar el archivo de configuración del Datadog Agent.
+- Puede usar variables de entorno. Las variables de entorno anulan la configuración del archivo de configuración.
-En el caso de los hosts que no están directamente conectados a Internet, se puede enviar tráfico a Datadog a través de SSL/TLS de las siguientes maneras:
+### Archivo de configuración {#configuration-file}
-1. Mediante un proxy web, como Squid o Microsoft Web Proxy, que ya se haya desplegado en tu red
-2. Mediante HAProxy (en caso de que quieras redirigir **más de 16 a 20 Agents** a través del mismo proxy)
-3. Mediante el Agent como un proxy (para **un máximo de 16 Agents** por proxy y **solo con el Agent v5**)
-
-## Cumplimiento de FIPS
-
-Para obtener información sobre la configuración de Datadog Agent FIPS Proxy con el Datadog Agent, consulta el [cumplimiento de FIPS de Datadog][1]. El FIPS proxy solo se encuentra disponible en la región US1-FED. El Datadog Agent FIPS Proxy no se puede utilizar junto con un proxy normal.
-
-## Proxy web
-
-Para obtener información específica sobre Squid, consulta la sección [Squid](#squid) de esta página.
-
-El Agent es compatible de forma nativa con los proxies web tradicionales. Si necesitas conectarte a Internet mediante un proxy, edita tu archivo de configuración del Agent.
-
-**Agent v6 y v7**
-
-Configura varios servidores proxy para solicitudes `https` y `http` en tu archivo de configuración `datadog.yaml` del Agent. El Agent utiliza `https` para enviar datos a Datadog, pero es probable que las integraciones utilicen `http` para recopilar métricas. Independientemente de las solicitudes que se redirijan mediante proxy, puedes activar el protocolo SSL en tu servidor proxy. A continuación, te mostramos algunos ejemplos de configuración que pueden servirte para tu archivo `datadog.yaml`.
-
-
-Si se encuentra habilitada la recopilación de logs, asegúrate de
exigir un transporte específico.
-Se recomienda utilizar HTTPS. En ese caso, el
<HOST>:<PORT> que se utiliza para redirigir mediante proxy las métricas también se utilizará para redirigir los logs.
-Si utilizas el transporte TCP, consulta la sección
Proxy TCP para logs.
-
-El
<HOST>:<PORT> que se utiliza para redirigir mediante proxy las métricas NO se utilizará para redirigir los logs. Consulta la página
Proxy para logs.
-
-La gestión remota de Agents no es compatible con cargas de trabajo en contenedores.
+La API de Automatización de Flota no admite todas las capacidades de configuración de los Agentes de Datadog.
+## Controle el acceso a la Automatización de Flota {#control-access-to-fleet-automation}
-## Observar tu flota
-
-Utiliza la página de [**Fleet Automation**][1] para obtener información sobre lagunas de observabilidad en tus hosts, Agents o OTel Collectors obsoletos, y Agents con problemas de integraciones.
-
-Para cada Datadog Agent, puedes ver:
-- La versión del Agent
-- Si el Agent tiene alguna integración no configurada o mal configurada
-- Los servicios que está monitorizando el Agent
-- El estado de configuración remota del Agent
-- Los productos habilitados en el Agent
-- Eventos de Agent de Audit Trail, incluidos cambios de configuración, actualizaciones y flares
-
-Para cada OTel Collector, puedes ver:
-- La versión del Collector
-- La distribución del Collector
-- El YAML de configuración del Collector
-
-### Examinar un Datadog Agent o un OpenTelemetry Collector
-
-Al seleccionar un Datadog Agent o un OTel Collector obtendrás más información sobre ellos, incluida su configuración, las integraciones conectadas, los eventos de auditoría y una pestaña de asistencia que puedes utilizar para enviar un flare remoto.
-
-{{< img src="agent/fleet_automation/fleet-automation-view-config.png" alt="Información de integración de un Agent" style="width:100%;" >}}
-
-### Ver los eventos de Agent de Audit Trail
-
-La pestaña Eventos de auditoría muestra eventos de Audit Trail asociados con el Agent seleccionado.
-Utiliza esta pestaña para:
-- Identificar los cambios de configuración, las actualizaciones de claves de API, las instalaciones, las actualizaciones y los flares de asistencia.
-- Determinar cuándo se hicieron los cambios y desde dónde
-
-La visibilidad de los eventos de Audit Trail depende de tu plan. Cuando Audit Trail está habilitado en tu organización, puedes ver los eventos de Agent durante un máximo de 90 días según la configuración de retención de Audit Trail. Si Audit Trail no está habilitado en tu organización, puedes ver los eventos de las últimas 24 horas.
-
-### Enviar un flare remoto
-
-Puedes enviar un flare desde el Datadog Agent o el DDOT Collector después de activar la configuración remota en el Agent. Para obtener instrucciones sobre cómo enviar un flare, consulta [Enviar un flare desde el sitio Datadog][7].
-
-Cuando te pongas en contacto con el servicio de asistencia de Datadog con la configuración remota activada para el Agent, el equipo podrá iniciar un flare desde tu entorno para poder ayudarte mejor y de forma más rápida. Los flares proporcionan información de solución de problemas al servicio de asistencia de Datadog para ayudarte a resolver tu problema.
-
-{{< img src="agent/fleet_automation/fleet_automation_remote_flare.png" alt="Enviar un flare remoto" style="width:100%;" >}}
-
-## Controlar el acceso a Fleet Automation
-
-Fleet Automation está disponible para todos los usuarios de una organización Datadog. Puedes controlar el acceso a funciones específicas:
+La Automatización de Flota está disponible para todos los usuarios en una organización de Datadog. Puede controlar el acceso a funcionalidades específicas:
| Permiso | Descripción |
|--------------|---------------|
-| `API Keys Read`| Determina qué usuarios pueden visualizar y buscar Agents por clave API. |
+| `API Keys Read`| Restringe qué usuarios pueden ver y buscar Agentes por clave de API. |
| `Agent Flare Collection` | Restringe qué usuarios pueden enviar flares de forma remota desde Fleet Automation. |
-| `Agent Upgrade` | Restringe qué usuarios tienen acceso a la actualización de Agents desde Fleet Automation. |
-| `Agent Configuration Management` | Restringe qué usuarios tienen acceso a configurar Agents desde Fleet Automation. |
+| `Agent Upgrade` | Restringe qué usuarios tienen acceso para actualizar Agentes desde Fleet Automation. |
+| `Agent Configuration Management` | Restringe qué usuarios tienen acceso para configurar Agentes desde Fleet Automation. |
-Para obtener información sobre la configuración de funciones y permisos, consulta [Control de acceso][5].
+Para obtener información sobre cómo configurar roles y permisos, consulte [Access Control][2].
-## Referencias adicionales
+## Lectura adicional {#further-reading}
{{< partial name="whats-next/whats-next.html" >}}
-[1]: https://app.datadoghq.com/fleet
-[2]: /es/agent/configuration/agent-configuration-files/
-[3]: /es/agent/fleet_automation/remote_management/#setup
-[4]: /es/infrastructure/list/#agent-configuration
-[5]: /es/account_management/rbac/
-[6]: /es/agent/fleet_automation/remote_management/
-[7]: /es/agent/troubleshooting/send_a_flare/#send-a-flare-from-the-datadog-site
-[8]: https://docs.datadoghq.com/es/opentelemetry/integrations/datadog_extension/#setup
-[9]: https://docs.datadoghq.com/es/api/latest/fleet-automation/
\ No newline at end of file
+[1]: /es/api/latest/fleet-automation/
+[2]: /es/account_management/rbac/
+[3]: /es/agent/fleet_automation/fleet_view/
+[4]: /es/agent/fleet_automation/configure_agents/
+[5]: /es/agent/fleet_automation/upgrade_agents/
+[6]: /es/agent/troubleshooting/send_a_flare/#send-a-flare-from-the-datadog-site
\ No newline at end of file
diff --git a/content/es/agent/troubleshooting/send_a_flare.md b/content/es/agent/troubleshooting/send_a_flare.md
index a55a4aa455e..c397dbc7f5d 100644
--- a/content/es/agent/troubleshooting/send_a_flare.md
+++ b/content/es/agent/troubleshooting/send_a_flare.md
@@ -1,117 +1,120 @@
---
algolia:
tags:
- - Flare del Agent
+ - agent flare
aliases:
- /es/agent/faq/send-logs-and-configs-to-datadog-via-flare-command
further_reading:
- link: /agent/troubleshooting/debug_mode/
tag: Documentación
- text: Modo de depuración del Agent
+ text: Modo de depuración del agente
- link: /agent/troubleshooting/agent_check_status/
tag: Documentación
- text: Consultar el estado de un check del Agent
-title: Flare del Agent
+ text: Obtener el estado de una verificación de agente
+title: Flare de agente
---
-
-Un flare permite enviar la información necesaria para que el equipo de asistencia de Datadog pueda solucionar tu problema.
+Una señal te permite enviar información necesaria para la solución de problemas al equipo de soporte de Datadog.
Esta página cubre:
-- [Envío de un flare utilizando el comando `flare`](#send-a-flare-using-the-flare-command).
-- [Envío de un flare desde el sitio de Datadog](#send-a-flare-from-the-Datadog-site), utilizando la configuración remota.
+- [Enviando un flare usando el comando `flare`](#send-a-flare-using-the-flare-command).
+- [Enviando un flare desde el sitio de Datadog](#send-a-flare-from-the-datadog-site) usando Remote Configuration.
- [Envío manual](#manual-submission).
-Un flare reúne todos los archivos de configuración y registros del Agent en un archivo de almacenamiento. Elimina información confidencial, incluyendo contraseñas, claves de API, credenciales proxy y cadenas de comunidad SNMP. Si APM está habilitado, el flare incluye [logs de depuración del rastreador][4] cuando están disponibles.
+Un flare reúne todos los archivos de configuración y registros del agente en un archivo. Elimina información sensible, incluyendo contraseñas, claves de API, credenciales de proxy y cadenas de comunidad SNMP. Si APM está habilitado, la señal incluye [registros de depuración de trazadores][4] cuando están disponibles.
-El Datadog Agent funciona en su totalidad con código abierto, lo que permite [comprobar el comportamiento del código][1]. Si es necesario, puedes revisar el flare antes de enviarlo, ya que este solicita una confirmación antes de subirlo.
+El agente de Datadog es completamente de código abierto, lo que te permite [verificar el comportamiento del código][1]. Si es necesario, la señal puede ser revisada antes de enviarla, ya que la señal solicita una confirmación antes de cargarla.
-Cuando te pongas en contacto con el servicio de asistencia de Datadog con la configuración remota activada para el Agent, el equipo podrá iniciar un flare desde tu entorno para poder ayudarte mejor y de forma más rápida. Los flares proporcionan información de solución de problemas al servicio de asistencia de Datadog para ayudarte a resolver tu problema.
+Al contactar al Soporte de Datadog con Remote Configuration habilitado para un agente, el equipo de soporte puede iniciar un flare desde su entorno para ayudarle de manera oportuna. Los flares proporcionan información de solución de problemas al Soporte de Datadog para ayudarle a resolver su problema.
-## Enviar un flare desde el sitio de Datadog
+## Enviar un flare desde el sitio de Datadog {#send-a-flare-from-the-datadog-site}
-{{< site-region region="gov" >}}
-El envío de un Flare del Agent desde Fleet Automation no es compatible con este sitio.
+{{< site-region region="gov,gov2" >}}
+Enviar un flare de agente desde Fleet Automation no es compatible con su sitio de Datadog seleccionado ({{< region-param key="dd_datacenter" >}}). Usa
envío manual de flares en su lugar.
Enviando un flare de agente usando el
flare el subcomando no es compatible con su sitio de Datadog seleccionado ({{< region-param key="dd_datacenter" >}}). Usa
envío manual de flares en su lugar.
-La integración Datadog Google Cloud Platform permite a Cloud Cost monitorizar automáticamente todos los proyectos a los que esta cuenta de servicio tiene acceso.
-Para limitar los hosts de monitorización de infraestructuras a estos proyectos, aplica etiquetas (tags) a los hosts. Luego, decide si las etiquetas deben incluirse o excluirse de la monitorización, en la sección Limitar los filtros para la recopilación de métricas de la página de la integración.
+La integración de Google Cloud Platform de Datadog permite que Cloud Cost realice el seguimiento automático de todos los proyectos a los que esta cuenta de servicio tiene acceso.
+Para limitar los hosts de monitoreo de infraestructura para estos proyectos, aplique etiquetas a los hosts. Luego defina si las etiquetas deben ser incluidas o excluidas del monitoreo en la sección {{< ui >}}Limit Metric Collection Filters{{< /ui >}} de la página de integración.
-{{< img src="cloud_cost/gcp_integration_limit_metric_collection.png" alt="Sección Limitar los filtros para la recopilación de métricas, configurada en la página de la integración Google Cloud Platform" >}}
+{{< img src="cloud_cost/gcp_integration_limit_metric_collection.png" alt="Limite la sección de filtros de colección de métricas configurada en la página de integración de Google Cloud Platform" >}}
-### Habilitar la exportación de costes detallados de uso
+### Habilite la exportación detallada de costos de uso {#enable-detailed-usage-cost-export}
-Los
datos de costes detallados de uso proporcionan toda la información incluida en los datos de costes de uso estándar, junto con campos adicionales que proporcionan datos granulares de costes a nivel de los recursos.
+Los datos de
costos de uso detallados proporcionan toda la información incluida en los datos estándar de costos de uso, junto con campos adicionales que ofrecen datos de costos a nivel de recurso.
+ Esto crea un nuevo agente de servicio que se parece a `service-@gcp-sa-bigquerydatatransfer.iam.gserviceaccount.com`.
-2. Añade el rol de cuenta de servicio de transferencia de datos de BigQuery creado por el activador como elemento principal en tu cuenta de servicio.
-3. Asígnale el rol `roles/iam.serviceAccountTokenCreator`.
-### Configurar Cloud Cost
-Sigue los pasos indicados en [Configuración][3].
+2. Agregue el rol de Cuenta de Servicio del Servicio de Transferencia de Datos de BigQuery creado por el disparador como un principal en su cuenta de servicio
+3. Asigne el rol `roles/iam.serviceAccountTokenCreator`.
-**Nota**: Los datos pueden tardar entre 48 y 72 horas en estabilizarse en Datadog.
+### Configure el Cloud Cost {#configure-cloud-cost}
+Siga los pasos indicados en [Setup & Configuration][3].
-## Tipos de costes
-Puedes visualizar tus datos ingeridos utilizando los siguientes tipos de costes:
+**Nota**: Los datos pueden tardar de 48 a 72 horas después de la configuración para estabilizarse en Datadog.
-| Tipo de coste | Descripción |
+### Obteniendo datos históricos {#getting-historical-data}
+
+Los conjuntos de datos de exportación de facturación de BigQuery recién creados solo contienen los 2 meses más recientes de datos. Puede tardar uno o dos días en que estos datos se rellenen en BigQuery. Datadog ingiere automáticamente hasta 15 meses de datos históricos de costos disponibles una vez que aparecen en la tabla de BigQuery.
+
+Google Cloud no proporciona un proceso para rellenar datos históricos adicionales, más allá de los 2 meses que se incluyen automáticamente cuando se crea por primera vez la exportación de BigQuery.
+
+## Tipos de costo {#cost-types}
+Puede visualizar sus datos ingeridos utilizando los siguientes tipos de costo:
+
+| Tipo de Costo | Descripción |
|-------------------------------------------------| ----------------------------------|
-| `gcp.cost.amortized` | Coste total de los recursos asignados en el momento del uso en un intervalo. Los costes incluyen los créditos de promoción, así como los créditos de descuento por compromiso de uso. |
-| `gcp.cost.amortized.shared.resources.allocated` | Todos tus costes de Google Cloud Platform amortizados, con desgloses e información adicional de las cargas de trabajo de contenedor. Requiere la [asignación de costes de contenedor][14].|
-| `gcp.cost.ondemand` | Coste total público y a la carta de los recursos antes de aplicar los descuentos públicos y privados en un intervalo. |
+| `gcp.cost.amortized` | Costo total de los recursos asignados en el momento de uso durante un intervalo. Los costos incluyen créditos de promoción así como créditos de descuento por uso comprometido. |
+| `gcp.cost.amortized.shared.resources.allocated` | Todos sus costos amortizados de Google Cloud Platform, con desgloses e información adicional para cargas de trabajo en contenedores. Requiere [Asignación de Costos de Contenedores][14].|
+| `gcp.cost.ondemand` | Costo total público y bajo demanda de los recursos antes de que se apliquen los descuentos públicos y privados durante un intervalo. |
-### Etiquetas predefinidas
-Datadog añade etiquetas a los datos de costes ingeridos para ayudarte a desglosar y asignar mejor tus costes. Estas etiquetas provienen de tu [informe de costes detallados de uso][16] y facilitan la detección y la comprensión de los datos de costes.
+### Etiquetas predeterminadas {#out-of-the-box-tags}
-Las siguientes etiquetas predefinidas están disponibles para filtrar y agrupar datos:
+Datadog enriquece automáticamente sus datos de costos de Google Cloud con etiquetas de múltiples fuentes. Para una visión general completa de cómo se aplican las etiquetas a los datos de costos, consulte [Etiquetas][17].
+
+Las siguientes etiquetas predeterminadas se derivan de su [informe detallado de costos de uso][16] y facilitan el descubrimiento y la comprensión de los datos de costos:
| Nombre de la etiqueta | Descripción de la etiqueta |
| ---------------------------- | ----------------- |
-| `google_product` | Servicio Google que se está facturando.|
-| `google_cost_type` | Tipo de cargo cubierto por esta partida (por ejemplo, regular, impuesto, ajuste o error de redondeo).|
-| `google_usage_type` | Detalles de uso de la partida (por ejemplo, Almacenamiento estándar US).|
-| `google_location` | Localización asociada a la partida a nivel de varias regiones, país, región o zona.|
-| `google_region` | Región asociada a la partida.|
-| `google_zone` | Zona de disponibilidad asociada a la partida.|
-| `google_pricing_usage_unit` | Unidad de precio utilizada para calcular el coste de uso (por ejemplo, gibibyte, tebibyte o año).|
-| `google_is_unused_reservation`| Si el uso se reservó pero no se utilizó.|
-| `service_description` | Servicio Google Cloud (como Compute Engine o BigQuery). |
-| `project_id` | ID del proyecto de Google Cloud que generó los datos de facturación de Cloud. |
-| `project_name` | Nombre del proyecto de Google Cloud que generó los datos de facturación de Cloud. |
-| `cost_type` | Tipo de coste que representa esta partida: `regular`, `tax`, `adjustment` o `rounding error`. |
-| `sku_description` | Descripción del tipo de recurso utilizado, que describe los detalles de uso del recurso. |
-| `resource_name` | Nombre que los clientes añaden a los recursos. Puede que no aparezca en todos los recursos. |
-| `global_resource_name` | Identificador de recurso único global generado por Google Cloud. |
-
-#### Correlación entre costes y observabilidad
-
-Visualizar los costes en el contexto de los datos de observabilidad es importante para comprender cómo afectan los cambios de infraestructura a los costes, identificar por qué cambian los costes y optimizar la infraestructura, tanto en los costes como en el rendimiento. Datadog actualiza el recurso identificando etiquetas en los datos de costes de los principales productos Google para simplificar la correlación entre la observabilidad y las métricas de costes.
-
-Por ejemplo, para ver el coste y el uso de cada base de datos Cloud SQL, puedes crear una tabla con `gcp.cost.amortized`, `gcp.cloudsql.database.cpu.utilization` y `gcp.cloudsql.database.memory.utilization` (o cualquier otra métrica de Cloud SQL) y agrupar por `database_id`. O, para ver el uso y los costes de Cloud Function uno al lado del otro, puedes hacer un gráfico con `gcp.cloudfunctions.function.execution_count` y `gcp.cost.amortized` agrupados por `function_name`.
-
-Están disponibles las siguientes etiquetas predefinidas:
-| Producto Google | Etiqueta(s) |
+| `google_product` | El servicio de Google que se está facturando.|
+| `google_cost_type` | El tipo de cargo cubierto por este ítem (por ejemplo, regular, impuesto, ajuste o error de redondeo).|
+| `google_usage_type` | Los detalles de uso del ítem (por ejemplo, Almacenamiento Estándar EE. UU.).|
+| `google_location` | La ubicación asociada con el ítem a nivel de multi-región, país, región o zona.|
+| `google_region` | La región asociada con el ítem.|
+| `google_zone` | La zona de disponibilidad asociada con el ítem.|
+| `google_pricing_usage_unit` | La unidad de precio utilizada para calcular el costo de uso (por ejemplo, gibibyte, tebibyte o año).|
+| `google_is_unused_reservation`| Si el uso fue reservado pero no utilizado.|
+| `service_description` | El servicio de Google Cloud (como Compute Engine o BigQuery). |
+| `project_id` | El ID del proyecto de Google Cloud que generó los datos de facturación en la nube. |
+| `project_name` | El nombre del proyecto de Google Cloud que generó los datos de facturación en la nube. |
+| `cost_type` | El tipo de costo que representa este ítem: `regular`, `tax`, `adjustment` o `rounding error`. |
+| `sku_description` | Una descripción del tipo de recurso utilizado, que detalla el uso del recurso. |
+| `resource_name` | Un nombre que los clientes añaden a los recursos. Esto puede no estar en todos los recursos. |
+| `global_resource_name` | Un identificador de recurso globalmente único generado por Google Cloud. |
+
+#### Correlación de costos y observabilidad {#cost-and-observability-correlation}
+
+Ver los costos en el contexto de los datos de observabilidad es importante para entender cómo los cambios en la infraestructura impactan los costos, identificar por qué cambian los costos y optimizar la infraestructura tanto para costos como para rendimiento. Datadog actualiza las etiquetas identificativas de recursos en los datos de costos para los principales productos de Google para simplificar la correlación entre métricas de observabilidad y costos.
+
+Por ejemplo, para ver el costo y la utilización de cada base de datos de Cloud SQL, puede crear una tabla con `gcp.cost.amortized`, `gcp.cloudsql.database.cpu.utilization` y `gcp.cloudsql.database.memory.utilization` (o cualquier otra métrica de Cloud SQL) y agrupar por `database_id`. O, para ver el uso y los costos de Cloud Functions lado a lado, puede graficar `gcp.cloudfunctions.function.execution_count` y `gcp.cost.amortized` agrupados por `function_name`.
+
+Las siguientes etiquetas listas para usar están disponibles:
+| Producto de Google | Etiqueta(s) |
| -------------------| ----------------------------- |
-| Compute Engine | `instance_id`, `instance-type` |
-| Cloud Functions | `function_name` |
-| Cloud Run | `job_name`, `service_name` |
-| Cloud SQL | `database_id` |
-| Cloud Spanner | `instance_id` |
-| App Engine | `module_id` |
-| BigQuery | `project_id`, `dataset_id` |
-| Kubernetes Engine | `cluster_name` |
-
-### Asignación de contenedor
-Las métricas de **Asignación de contenedor** contienen todos los mismos costes que las métricas de Google Cloud Platform, pero con desgloses e información adicional de las cargas de trabajo de contenedor. Para obtener más información, consulta [Asignación de costes de contenedor][14].
-
-## Referencias adicionales
+| Compute Engine | `instance_id`, `instance-type`|
+| Cloud Functions | `function_name` |
+| Cloud Run | `job_name`, `service_name` |
+| Cloud SQL | `database_id` |
+| Cloud Spanner | `instance_id` |
+| App Engine | `module_id` |
+| BigQuery | `project_id`, `dataset_id` |
+| Kubernetes Engine | `cluster_name` |
+
+### Asignación de contenedores {#container-allocation}
+**Las métricas de asignación de contenedores** contienen todos los mismos costos que las métricas de Google Cloud Platform, pero con desgloses e información adicional para cargas de trabajo de contenedores. Consulte [Asignación de Costos de Contenedores][14] para más detalles.
+
+## Lectura adicional {#further-reading}
{{< partial name="whats-next/whats-next.html" >}}
[1]: https://console.cloud.google.com/billing/export/
[2]: https://cloud.google.com/billing/docs/how-to/export-data-bigquery-setup
-[3]: https://app.datadoghq.com/cost/setup?cloud=gcp
+[3]: https://app.datadoghq.com/cost/setup
[4]: https://app.datadoghq.com/integrations/google-cloud-platform
[5]: https://cloud.google.com/bigquery/docs/enable-transfer-service
-[6]: https://cloud.google.com/storage/docs/access-control/using-iam-permissions#bucket-add
-[7]: https://cloud.google.com/iam/docs/granting-changing-revoking-access#grant-single-role
-[8]: https://cloud.google.com/bigquery/docs/control-access-to-resources-iam#grant_access_to_a_dataset
[9]: https://cloud.google.com/bigquery/docs/exporting-data#data-locations
[10]: https://cloud.google.com/bigquery/docs/enable-transfer-service#cross-project_service_account_authorization
[11]: https://cloud.google.com/iam/docs/create-service-agents#create
@@ -204,3 +250,6 @@ Las métricas de **Asignación de contenedor** contienen todos los mismos costes
[14]: /es/cloud_cost_management/container_cost_allocation/
[15]: /es/cloud_cost_management/setup/google_cloud/#create-or-select-a-google-cloud-storage-bucket
[16]: https://cloud.google.com/billing/docs/how-to/export-data-bigquery-tables/detailed-usage
+[17]: /es/cloud_cost_management/tags
+[18]: /es/api/latest/cloud-cost-management/#create-google-cloud-usage-cost-config
+[19]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/gcp_uc_config
\ No newline at end of file
diff --git a/content/es/containers/autoscaling/_index.md b/content/es/containers/autoscaling/_index.md
new file mode 100644
index 00000000000..2a44410e1fe
--- /dev/null
+++ b/content/es/containers/autoscaling/_index.md
@@ -0,0 +1,657 @@
+---
+aliases:
+- /es/containers/monitoring/autoscaling
+description: Escala automáticamente las cargas de trabajo de Kubernetes utilizando
+ métricas de Datadog y recomendaciones inteligentes de escalado.
+further_reading:
+- link: /infrastructure/containers/kubernetes_resource_utilization
+ tag: Documentación
+ text: Utilización de Recursos de Kubernetes
+- link: /account_management/rbac/permissions
+ tag: Documentación
+ text: Permisos de Rol de Datadog
+- link: /agent/remote_config/
+ tag: Documentación
+ text: Remote Configuration
+- link: https://www.datadoghq.com/blog/autoscaling-custom-metrics
+ tag: Blog
+ text: Escalando cargas de trabajo de Kubernetes con métricas personalizadas
+- link: https://www.datadoghq.com/blog/kubernetes-custom-query-autoscaling
+ tag: Blog
+ text: Optimiza las cargas de trabajo de Kubernetes con Custom Query Scaling.
+- link: https://www.datadoghq.com/blog/ddot-gateway
+ tag: Blog
+ text: Centraliza y gobierna tu canalización de OpenTelemetry con el gateway DDOT.
+- link: https://www.datadoghq.com/blog/datadog-kubernetes-autoscaling/
+ tag: Blog
+ text: Ajusta las cargas de trabajo y reduce costos con el escalado automático de
+ Kubernetes de Datadog
+title: Kubernetes Autoscaling
+---
+{{< site-region region="gov,gov2" >}}
+
+ Esta función no está disponible para Datadog for Government ({{< region-param key="dd_datacenter" >}}) site.
+
+{{< /site-region >}}
+
+Datadog Kubernetes Autoscaling monitorea continuamente sus recursos de Kubernetes para proporcionar recomendaciones de escalado inmediatas y un escalado multidimensional de sus cargas de trabajo de Kubernetes. Puede implementar Datadog Kubernetes Autoscaling a través de la interfaz web de Datadog, o con un recurso personalizado `DatadogPodAutoscaler`.
+
+## Cómo funciona {#how-it-works}
+Datadog utiliza métricas de utilización en tiempo real e históricas y señales de eventos de sus Datadog Agents existentes para hacer recomendaciones. Luego puede examinar estas recomendaciones y elegir implementarlas.
+
+Por defecto, Datadog Kubernetes Autoscaling utiliza valores estimados del costo de CPU y memoria para mostrar oportunidades de ahorro y estimaciones de impacto. También puede usar Datadog Kubernetes Autoscaling junto con [Cloud Cost Management](#idle-cost-and-savings-estimates) para obtener informes basados en los costos exactos de su tipo de instancia.
+
+El escalado automatizado de cargas de trabajo es impulsado por un `DatadogPodAutoscaler` recurso personalizado que define el comportamiento de escalado a nivel de cada carga de trabajo. El Datadog Cluster Agent actúa como el controlador de este recurso personalizado.
+
+**Nota:** Cada clúster puede tener un máximo de 1000 cargas de trabajo optimizadas con Datadog Kubernetes Autoscaling.
+
+### Compatibilidad {#compatibility}
+
+- **Distribuciones**: Esta función es compatible con todas las [distribuciones de Kubernetes soportadas][5] por Datadog.
+- **Autoscaling de cargas de trabajo**: Esta función es una alternativa al Horizontal Pod Autoscaler (HPA) y al Vertical Pod Autoscaler (VPA). Datadog recomienda que elimine cualquier HPA o VPA de una carga de trabajo al habilitar Datadog Kubernetes Autoscaling para optimizarla. Estas cargas de trabajo son identificadas en la aplicación en su nombre.
+**Nota:** Puede experimentar con Datadog Kubernetes Autoscaling mientras mantiene su HPA y/o VPA creando un `DatadogPodAutoscaler` con `mode: Preview` en la sección `applyPolicy`.
+
+### Requisitos {#requirements}
+
+- [Remote Configuration][1] debe estar habilitado tanto a nivel de organización como en los Agentes de su clúster objetivo. Consulte [Enabling Remote Configuration][2] para obtener instrucciones de configuración.
+- [Helm][3], para actualizar su Datadog Agent.
+- (Para usuarios de Datadog Operator) [`kubectl` CLI][4], para actualizar el Datadog Agent.
+- Cuando esté utilizando autoscaling en vivo, Datadog recomienda usar la última versión del Datadog Agent. Esto ayuda a garantizar el acceso a las últimas mejoras y optimizaciones. Las recomendaciones de escalado requieren que la integración [Kubernetes State Core][9] esté habilitada.
+
+ | Función | Versión Mínima del Agente |
+ |---------|----------------------|
+ | Recomendaciones de escalado de carga de trabajo en la aplicación | 7.50+ |
+ | Escalado de carga de trabajo en vivo | 7.66.1+ |
+ | Recomendaciones de Argo Rollout y escalado automático | 7.71+ |
+ | Escalado automático de clúster ([inscripción previa][10]) | 7.72+ |
+ | Redimensionamiento vertical de pod en su lugar (opción activa) | 7.78+ |
+ | Activación del perfil del clúster, etiqueta de carga de trabajo | 7.78+ |
+ | Activación del perfil del clúster, etiqueta de espacio de nombres | 7.79+ |
+
+- Los siguientes permisos de usuario:
+ - Gestión de organización (requerido para configuración remota)
+ - Escritura de clave de API (requerido para configuración remota)
+ - Escritura de escalado de carga de trabajo
+ - Gestión de escalado automático
+- (Recomendado) Núcleo de Linux v5.19+ y cgroup v2
+
+## Configuración {#setup}
+
+{{< tabs >}}
+{{% tab "Datadog Operator" %}}
+
+1. Asegúrese de estar utilizando Datadog Operator v1.16.0+. Para actualizar su Datadog Operator:
+
+```shell
+helm upgrade datadog-operator datadog/datadog-operator
+```
+
+2. Agregue lo siguiente a su archivo de configuración `datadog-agent.yaml`:
+
+```yaml
+spec:
+ features:
+ autoscaling:
+ workload:
+ enabled: true
+ eventCollection:
+ unbundleEvents: true
+ override:
+ clusterAgent:
+ env:
+ - name: DD_AUTOSCALING_FAILOVER_ENABLED
+ value: "true"
+ nodeAgent:
+ env:
+ - name: DD_AUTOSCALING_FAILOVER_ENABLED
+ value: "true"
+```
+
+3. [Admission Controller][1] está habilitado por defecto con Datadog Operator. Si lo deshabilitó, vuelva a habilitarlo agregando las siguientes líneas resaltadas a `datadog-agent.yaml`:
+
+{{< highlight yaml "hl_lines=4-5" >}}
+...
+spec:
+ features:
+ admissionController:
+ enabled: true
+...
+{{< /highlight >}}
+
+4. Aplique la configuración actualizada de `datadog-agent.yaml`:
+
+```shell
+kubectl apply -n $DD_NAMESPACE -f datadog-agent.yaml
+```
+
+[1]: /es/containers/cluster_agent/admission_controller/
+
+{{% /tab %}}
+{{% tab "Helm" %}}
+
+1. Asegúrese de estar utilizando Agent y Cluster Agent v7.66.1+. Agregue lo siguiente a su archivo de configuración `datadog-values.yaml`:
+
+```yaml
+datadog:
+ autoscaling:
+ workload:
+ enabled: true
+ kubernetesEvents:
+ unbundleEvents: true
+```
+
+2. [Admission Controller][1] está habilitado por defecto en el Datadog Helm chart. Si lo deshabilitó, vuelva a habilitarlo agregando las siguientes líneas resaltadas a `datadog-values.yaml`:
+{{< highlight yaml "hl_lines=5-6" >}}
+...
+clusterAgent:
+ admissionController:
+ enabled: true
+...
+{{< /highlight >}}
+
+3. Actualice su versión de Helm:
+
+```shell
+helm repo update
+```
+
+4. Vuelva a desplegar Datadog Agent con su `datadog-values.yaml` actualizado:
+
+```shell
+helm upgrade -f datadog-values.yaml datadog/datadog
+```
+
+[1]: /es/containers/cluster_agent/admission_controller/
+
+{{% /tab %}}
+{{< /tabs >}}
+
+### Estimaciones de costos y ahorros inactivos {#idle-cost-and-savings-estimates}
+
+{{< tabs >}}
+{{% tab "Con Cloud Cost Management" %}}
+Si [Cloud Cost Management][1] está habilitado en una organización, Datadog Kubernetes Autoscaling muestra estimaciones de costos inactivos y ahorros basados en el costo exacto de su factura de las instancias monitoreadas subyacentes.
+
+Consulta las instrucciones de configuración de Cloud Cost para [AWS][2], [Azure][3] o [Google Cloud][4].
+
+Los datos de Cloud Cost Management mejoran Datadog Kubernetes Autoscaling, pero no son obligatorios. Todas las recomendaciones de carga de trabajo y decisiones de autoscaling de Datadog son válidas y funcionales sin Cloud Cost Management.
+
+[1]: /es/cloud_cost_management
+[2]: /es/cloud_cost_management/aws
+[3]: /es/cloud_cost_management/azure
+[4]: /es/cloud_cost_management/google_cloud
+{{% /tab %}}
+
+{{% tab "Predeterminado" %}}
+Si Cloud Cost Management **no** está habilitado, Datadog Kubernetes Autoscaling muestra estimaciones de costos inactivos y ahorros utilizando las siguientes fórmulas y valores fijos:
+
+**Inactividad del clúster**:
+
+```
+ (cpu_capacity - max(cpu_usage, cpu_requests)) * core_rate_per_hour
++ (mem_capacity - max(mem_usage, mem_requests)) * memory_rate_per_hour
+```
+
+**Carga de trabajo inactiva**:
+
+```
+ (max(cpu_usage, cpu_requests) - cpu_usage) * core_rate_per_hour
++ (max(mem_usage, mem_requests) - mem_usage) * memory_rate_per_hour
+```
+
+**Valores fijos**:
+- tasa_núcleo_por_hora = $0.0295 por hora de núcleo de CPU
+- tasa_memoria_por_hora = $0.0053 por hora de GB de memoria
+
+
+_Los valores de costo fijo están sujetos a refinamiento con el tiempo._
+{{% /tab %}}
+{{< /tabs >}}
+
+## Uso {#usage}
+
+### Identificar recursos para ajustar {#identify-resources-to-rightsize}
+
+La [página de Resumen de Escalado Automático][6] proporciona un punto de partida para que los equipos de plataforma comprendan las oportunidades de ahorro total de Recursos de Kubernetes en una organización, y filtren hacia clústeres y espacios de nombres clave.
+
+La [página de Configuración][11] ofrece la opción de seleccionar múltiples cargas de trabajo para escalar y gestionar su optimización en lotes.
+
+La [vista de Escalado de Clúster][7] proporciona información por clúster sobre el total de CPU inactiva, total de memoria inactiva y costos.
+
+Haga clic en un clúster para obtener información detallada y una tabla de las cargas de trabajo del clúster ordenadas por ahorros estimados. Si usted es un propietario de aplicación o servicio individual, también puede filtrar por el nombre de su equipo o servicio directamente desde la [vista de lista de Escalado de Carga de Trabajo][8].
+
+Desde cualquiera de estas vistas, haga clic en {{< ui >}}Optimize{{< /ui >}} en una carga de trabajo para ver su recomendación de escalado, luego proceda a [Habilitar Escalado Automático para una carga de trabajo](#enable-autoscaling-for-a-workload).
+
+### Habilitar Escalado Automático para una carga de trabajo {#enable-autoscaling-for-a-workload}
+
+Después de identificar una carga de trabajo para optimizar, inspeccione su {{< ui >}}Scaling Recommendation{{< /ui >}}. Haga clic en {{< ui >}}Configure Recommendation{{< /ui >}} para agregar restricciones o ajustar los niveles de utilización objetivo antes de habilitar.
+
+Hay tres formas de habilitar el escalado automático para una carga de trabajo. Elija el camino que coincida con la forma en que despliega cargas de trabajo hoy.
+
+| Ruta | Mejor para | Dónde comenzar | Gestión continua |
+|------|----------|-----------------|--------------------|
+| **A. Asistente de configuración de la interfaz de usuario de Datadog** | Comience rápidamente y ajuste la configuración con retroalimentación visual inmediata, o empodere a sus equipos de aplicación para tomar mejores decisiones de configuración de escalado | [Página de configuración][11] en la interfaz de usuario de Datadog | Edite la carga de trabajo `DatadogPodAutoscaler` desde la interfaz o su clúster |
+| **B. Redacte un `DatadogPodAutoscaler` manifiesto** | Flujos de trabajo existentes para enviar manifiestos de Kubernetes (`kubectl`, Helm, ArgoCD, Terraform u otras herramientas de GitOps) | YAML escrito a mano o generado a partir de plantillas aplicado a través de la herramienta que ya utiliza | Edite el manifiesto y reaplique a través de la misma herramienta |
+| **C. Aplicar un [perfil de clúster](#cluster-profiles) etiqueta** | Activar el escalado automático en muchas cargas de trabajo o espacios de nombres con una única política compartida | Etiquete la carga de trabajo o el espacio de nombres con `autoscaling.datadoghq.com/profile` | Edite el perfil para actualizar cada carga de trabajo que gestiona, o mueva cargas de trabajo entre perfiles cambiando la etiqueta |
+
+#### Ruta A: Datadog UI {#path-a-datadog-ui}
+
+La forma más rápida de comenzar es la [Setup page][11] en Datadog UI. El asistente lo guía a través de cinco pasos: seleccionar un clúster, verificar los requisitos del agente y de permisos, elegir un método de instalación, seleccionar una plantilla de escalado y desplegar. Plantillas disponibles en el asistente:
+
+- **Optimizar costo**: objetivo de alta utilización de CPU, reducción agresiva, piso de réplicas más bajo. Mejor para cargas de trabajo sin estado y sensibles al costo.
+- **Optimizar balance**: objetivo de utilización moderada, escalado equilibrado hacia arriba y hacia abajo. Mejor para la mayoría de las cargas de trabajo sin estado.
+- **Optimizar rendimiento**: objetivo de utilización conservadora, reducción lenta, piso de réplicas más alto. Mejor para servicios con estado o críticos.
+- **Personalizar**: comience desde cualquiera de los anteriores y ajuste el objetivo de CPU, réplicas y ventanas de estabilización usted mismo.
+
+El asistente de configuración es mejor para probar el escalado automático en una sola carga de trabajo, interactuar con una recomendación o incorporar un pequeño conjunto de cargas de trabajo. (Requiere `Workload Scaling Write` y `Autoscaling Manage` permisos.)
+
+#### Ruta B: GitOps {#path-b-gitops}
+
+Defina un `DatadogPodAutoscaler` recurso personalizado que apunte a su carga de trabajo y aplíquelo a través de cualquier herramienta que ya use para enviar manifiestos de Kubernetes, ya sea `kubectl apply`, Helm, ArgoCD, Terraform u otra herramienta de GitOps. La redacción del manifiesto es la misma independientemente del mecanismo de entrega. Vea las [configuraciones de ejemplo](#example-datadogpodautoscaler-configurations) a continuación para puntos de partida listos para editar que cubren optimización de costos, escalado equilibrado, redimensionamiento vertical únicamente y escalado horizontal de consulta personalizada.
+
+Para guías específicas de herramientas, consulte:
+
+- [Gestionar DatadogPodAutoscaler con ArgoCD][12]
+- [Gestionar DatadogPodAutoscaler con Terraform][13]
+
+### Ejemplos de configuraciones de DatadogPodAutoscaler {#example-datadogpodautoscaler-configurations}
+
+Los siguientes ejemplos demuestran configuraciones comunes `DatadogPodAutoscaler` para diferentes estrategias de escalado. Úselos como puntos de partida y ajuste los valores para que coincidan con los requisitos de su carga de trabajo. Si prefiere elegir una plantilla en la interfaz de usuario, siga [Ruta A](#path-a-datadog-ui-setup-wizard) arriba.
+
+{{< tabs >}}
+{{% tab "Optimizar Costo" %}}
+
+Elija esta plantilla para una carga de trabajo sin estado, sensible a costos, donde el controlador debe eliminar capacidad rápidamente cuando la carga disminuye. La configuración definitoria es el objetivo de alta utilización de CPU (85%), combinado con una regla de reducción agresiva y un mínimo de una réplica.
+
+```yaml
+apiVersion: datadoghq.com/v1alpha2
+kind: DatadogPodAutoscaler
+metadata:
+ name:
+ namespace:
+spec:
+ targetRef:
+ apiVersion: apps/v1
+ kind: Deployment
+ name:
+ owner: Local
+ applyPolicy:
+ mode: Apply
+ scaleDown:
+ rules:
+ # Aggressive: allow 50% reduction every 2 minutes
+ - periodSeconds: 120
+ type: Percent
+ value: 50
+ stabilizationWindowSeconds: 300
+ scaleUp:
+ rules:
+ - periodSeconds: 120
+ type: Percent
+ value: 50
+ stabilizationWindowSeconds: 300
+ update:
+ strategy: Auto
+ constraints:
+ maxReplicas: 100
+ # Allow scaling down to 1 replica for maximum savings
+ minReplicas: 1
+ objectives:
+ # High utilization target to maximize cost efficiency
+ - type: PodResource
+ podResource:
+ name: cpu
+ value:
+ type: Utilization
+ utilization: 85
+```
+
+{{% /tab %}}
+{{% tab "Optimizar Balance" %}}
+
+Elija esta plantilla cuando desee ahorros sin sacrificar disponibilidad. Es un valor predeterminado sensato para la mayoría de las cargas de trabajo sin estado. La configuración definitoria es el objetivo moderado de utilización de CPU (70%) emparejado con una reducción conservadora (20% cada 20 minutos) y un mínimo de dos réplicas. El controlador agrega capacidad rápidamente pero la elimina lentamente.
+
+```yaml
+apiVersion: datadoghq.com/v1alpha2
+kind: DatadogPodAutoscaler
+metadata:
+ name:
+ namespace:
+spec:
+ targetRef:
+ apiVersion: apps/v1
+ kind: Deployment
+ name:
+ owner: Local
+ applyPolicy:
+ mode: Apply
+ scaleDown:
+ rules:
+ # Conservative: allow only 20% reduction every 20 minutes
+ - periodSeconds: 1200
+ type: Percent
+ value: 20
+ stabilizationWindowSeconds: 600
+ scaleUp:
+ rules:
+ - periodSeconds: 120
+ type: Percent
+ value: 50
+ stabilizationWindowSeconds: 600
+ update:
+ strategy: Auto
+ constraints:
+ maxReplicas: 100
+ # Maintain at least 2 replicas for availability
+ minReplicas: 2
+ objectives:
+ # Moderate utilization target balances cost and performance
+ - type: PodResource
+ podResource:
+ name: cpu
+ value:
+ type: Utilization
+ utilization: 70
+```
+
+{{% /tab %}}
+{{% tab "Vertical: CPU y memoria" %}}
+
+Elija esta plantilla cuando una carga de trabajo no pueda escalarse horizontalmente, o cuando desee un ajuste puro sin cambiar el número de réplicas. Los casos comunes son servicios singleton, cargas de trabajo con estado y componentes elegidos por un líder. La configuración definitoria es `scaleDown.strategy: Disabled` y `scaleUp.strategy: Disabled`, lo que deja solo `update.strategy: Auto` para aplicar recomendaciones de CPU y memoria.
+
+Por defecto, el controlador aplica recomendaciones verticales al activar un despliegue (desalojar y recrear pods). El Cluster Agent **7.78+** también admite **redimensionamiento de pods en su lugar**, lo que actualiza las solicitudes y límites de CPU y memoria de un pod sin reiniciarlo. El redimensionamiento en su lugar es opcional: configure `autoscaling.workload.in_place_vertical_scaling.enabled: true` en el Cluster Agent (o establezca la variable de entorno `DD_AUTOSCALING_WORKLOAD_IN_PLACE_VERTICAL_SCALING_ENABLED=true`).
+
+Su clúster también debe exponer el `pods/resize` subrecurso. Este es el valor predeterminado en Kubernetes 1.33+ donde la puerta de características `InPlacePodVerticalScaling` está en beta. En Kubernetes 1.27 a 1.32, la puerta de características debe estar habilitada en `kube-apiserver` y cada `kubelet`.
+
+Cuando se cumplen ambos requisitos previos:
+
+- **Predeterminado**: Las cargas de trabajo con `applyPolicy.update.strategy: Auto` (el predeterminado) se redimensionan en su lugar.
+- **Reversión**: Si el kubelet informa un redimensionamiento como `Infeasible`, el controlador recurre a un rollout.
+- **Opt-out**: Para forzar a una carga de trabajo a utilizar siempre el escalado vertical basado en rollout independientemente de la configuración del clúster, configure `applyPolicy.update.strategy: TriggerRollout` en su `DatadogPodAutoscaler`.
+
+```yaml
+apiVersion: datadoghq.com/v1alpha2
+kind: DatadogPodAutoscaler
+metadata:
+ name:
+ namespace:
+spec:
+ targetRef:
+ apiVersion: apps/v1
+ kind: Deployment
+ name:
+ owner: Local
+ applyPolicy:
+ mode: Apply
+ # Horizontal scaling disabled; only vertical resizing
+ scaleDown:
+ strategy: Disabled
+ scaleUp:
+ strategy: Disabled
+ update:
+ strategy: Auto
+ constraints:
+ maxReplicas: 100
+```
+
+{{% /tab %}}
+{{% tab "Consulta Personalizada Horizontal" %}}
+
+Elija esta plantilla cuando la CPU y la memoria no sean la señal de escalado adecuada. Los ejemplos incluyen un trabajador de cola que debería escalar según la profundidad de la cola, o un servicio API que debería escalar según la latencia de las solicitudes. La configuración definitoria es el bloque `objectives`, que hace referencia a una consulta de métrica de Datadog y a un `AbsoluteValue` objetivo en lugar de un porcentaje de utilización. Reemplace la consulta de ejemplo con una que coincida con su carga de trabajo.
+
+```yaml
+apiVersion: datadoghq.com/v1alpha2
+kind: DatadogPodAutoscaler
+metadata:
+ name:
+ namespace:
+spec:
+ targetRef:
+ apiVersion: apps/v1
+ kind: Deployment
+ name:
+ owner: Local
+ applyPolicy:
+ mode: Apply
+ scaleDown:
+ rules:
+ - periodSeconds: 1200
+ type: Percent
+ value: 20
+ stabilizationWindowSeconds: 600
+ scaleUp:
+ rules:
+ - periodSeconds: 120
+ type: Percent
+ value: 50
+ stabilizationWindowSeconds: 600
+ # Vertical updates disabled — horizontal only
+ update:
+ strategy: Disabled
+ constraints:
+ maxReplicas: 100
+ minReplicas: 2
+ objectives:
+ - type: CustomQuery
+ customQuery:
+ # Replace with your own Datadog metric query
+ request:
+ formula: usage
+ queries:
+ - name: usage
+ source: Metrics
+ metrics:
+ query: avg:redis.info.latency_ms{kube_cluster_name:,kube_namespace:,kube_deployment:}
+ value:
+ type: AbsoluteValue
+ absoluteValue: 500M
+ window: 5m0s
+ fallback:
+ horizontal:
+ # With custom queries, local fallback is not activated by default
+ enabled: false
+ # Direction can be ScaleUp, ScaleDown or All
+ direction: ScaleUp
+ # When using custom queries, a CPU or Memory fallback objective is required
+ objectives:
+ - type: PodResource
+ podResource:
+ name: cpu
+ value:
+ type: Utilization
+ utilization: 70
+ triggers:
+ staleRecommendationThresholdSeconds: 600
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+### Perfiles de clúster {#cluster-profiles}
+
+Un `DatadogPodAutoscalerClusterProfile` es un recurso de ámbito de clúster que contiene una plantilla `DatadogPodAutoscaler`. El Cluster Agent observa los recursos `Deployment` y `StatefulSet` (y, en 7.79+, los espacios de nombres que los contienen) para la etiqueta `autoscaling.datadoghq.com/profile`, y crea un `DatadogPodAutoscaler` administrado para cada carga de trabajo coincidente. Un perfil se aplica a muchas cargas de trabajo; una carga de trabajo aún se asigna a un `DatadogPodAutoscaler`.
+
+Los perfiles de clúster y la etiqueta a nivel de carga de trabajo requieren Datadog Cluster Agent 7.78.0+. La activación a nivel de espacio de nombres (etiquetando un espacio de nombres para optar por cada carga de trabajo compatible dentro de él en un perfil) requiere Datadog Cluster Agent 7.79.0+. Los Cluster Agents más antiguos ignoran la etiqueta de perfil.
+
+#### Perfiles integrados {#built-in-profiles}
+
+El Cluster Agent envía tres perfiles integrados y los recrea al iniciar, por lo que no necesita comprometer ningún YAML de CRD para usarlos. Los nombres están reservados.
+
+| Perfil | Objetivo de CPU | Mínimo de réplicas | Perfil de comportamiento |
+|---|---|---|---|
+| `datadog-optimize-cost` | 85% | 1 | Cargas de trabajo sin estado, sensibles al costo. Escalado rápido hacia arriba y hacia abajo (ventanas de estabilización de 5 minutos, paso del 50% cada 2 minutos). |
+| `datadog-optimize-balance` | 70% | 2 | Predeterminado para la mayoría de las cargas de trabajo sin estado. Ventanas de estabilización equilibradas de 10 minutos, escalado hacia abajo conservador (paso del 20% cada 20 minutos). |
+| `datadog-optimize-performance` | 60% | 3 | Cargas de trabajo con estado o sensibles a la latencia. Escalado hacia abajo muy conservador (ventanas de estabilización de 15 minutos, paso del 10% cada 30 minutos). |
+
+Para activar un perfil en una sola carga de trabajo, agregue la etiqueta a la `metadata.labels` de la carga de trabajo:
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+ name: web-app
+ namespace: production
+ labels:
+ autoscaling.datadoghq.com/profile: datadog-optimize-balance
+spec:
+ # ...rest of the Deployment spec
+```
+
+Para activar un perfil en cada carga de trabajo soportada en un espacio de nombres, etiquete el espacio de nombres en su lugar (requiere Cluster Agent 7.79.0+):
+
+```yaml
+apiVersion: v1
+kind: Namespace
+metadata:
+ name: production
+ labels:
+ autoscaling.datadoghq.com/profile: datadog-optimize-balance
+```
+
+#### Perfiles personalizados {#custom-profiles}
+
+Cree un `DatadogPodAutoscalerClusterProfile` cuando ningún perfil integrado coincida con su política de escalado. Los perfiles son de ámbito de clúster, así que aplíquelos sin una bandera `--namespace` (o colóquelos en la capa a nivel de clúster de su repositorio de configuración).
+
+```yaml
+apiVersion: datadoghq.com/v1alpha2
+kind: DatadogPodAutoscalerClusterProfile
+metadata:
+ name: cost-optimized-strict-floor
+spec:
+ template:
+ applyPolicy:
+ mode: Apply
+ scaleUp:
+ stabilizationWindowSeconds: 300
+ rules:
+ - type: Percent
+ value: 50
+ periodSeconds: 120
+ scaleDown:
+ stabilizationWindowSeconds: 300
+ rules:
+ - type: Percent
+ value: 50
+ periodSeconds: 120
+ constraints:
+ minReplicas: 1
+ objectives:
+ - type: PodResource
+ podResource:
+ name: cpu
+ value:
+ type: Utilization
+ utilization: 85
+```
+
+Referencie el perfil personalizado desde una carga de trabajo o espacio de nombres usando la misma etiqueta:
+
+```yaml
+metadata:
+ labels:
+ autoscaling.datadoghq.com/profile: cost-optimized-strict-floor
+```
+
+El cuerpo de la plantilla acepta los mismos campos que una especificación `DatadogPodAutoscaler`, menos `targetRef` (el Cluster Agent lo completa para cada carga de trabajo coincidente). Vea las [configuraciones de ejemplo](#example-datadogpodautoscaler-configurations) anteriores para ver el rango completo de campos que puede colocar en `spec.template`.
+
+#### Precedencia de activación {#activation-precedence}
+
+Cluster Agent 7.79.0+ agrega activación a nivel de espacio de nombres, la `excluded` opción de exclusión y la regla de precedencia entre ellos. En Cluster Agent 7.78.0, solo se lee la etiqueta a nivel de carga de trabajo — las reglas que involucran espacios de nombres o el valor `excluded` no se aplican.
+
+- **Las etiquetas de carga de trabajo tienen precedencia sobre las etiquetas de espacio de nombres.** Si un espacio de nombres está etiquetado como `autoscaling.datadoghq.com/profile=ns-profile` y una carga de trabajo dentro de él está etiquetada como `autoscaling.datadoghq.com/profile=workload-profile`, la carga de trabajo utiliza `workload-profile`.
+- **Exclúyase con `excluded`.** Establezca `autoscaling.datadoghq.com/profile: excluded` en una carga de trabajo para eximirla cuando su espacio de nombres esté etiquetado. Esto es útil para cargas de trabajo con estado o críticas en un espacio de nombres que de otro modo está incluido.
+
+ ```yaml
+ apiVersion: apps/v1
+ kind: StatefulSet
+ metadata:
+ name: payments-ledger
+ namespace: production
+ labels:
+ autoscaling.datadoghq.com/profile: excluded
+ ```
+
+- **Los nombres de perfil desconocidos son ignorados.** Si una carga de trabajo o espacio de nombres hace referencia a un perfil que no existe, Cluster Agent no crea un `DatadogPodAutoscaler` administrado y no informa un error. La reconciliación recoge la asignación tan pronto como se crea un perfil con ese nombre.
+- **La reconciliación es automática.** Agregar, cambiar o eliminar la etiqueta se propaga a un `DatadogPodAutoscaler` administrado en segundos.
+
+#### Tipos de carga de trabajo soportados {#supported-workload-kinds}
+
+La activación de perfil soporta `Deployment` y `StatefulSet`. Para otros tipos (por ejemplo, Argo `Rollout`), utilice [Ruta B: GitOps](#path-b-gitops) para crear un `DatadogPodAutoscaler` directamente.
+
+### Despliegue de recomendaciones manualmente {#deploy-recommendations-manually}
+
+Si desea las recomendaciones de Datadog sin habilitar el escalado automático, puede aplicarlas manualmente de forma puntual. Cuando configure recursos para sus implementaciones de Kubernetes, utilice los valores sugeridos en la recomendación de escalado. También puede hacer clic en {{< ui >}}Export Recommendation{{< /ui >}} para ver un comando `kubectl patch` generado. Datadog continúa actualizando la recomendación, pero el clúster solo cambia cuando la reaplica.
+
+## Gestione cargas de trabajo a gran escala {#manage-workloads-at-scale}
+
+Después de que una carga de trabajo se haya escalado automáticamente, las operaciones del día dos se gestionan a través de una combinación del recurso `DatadogPodAutoscaler` y la Datadog UI:
+
+- **Cambie la plantilla de escalado.** Edite la especificación `DatadogPodAutoscaler` de la carga de trabajo (objetivo de CPU, límites de réplicas, reglas de escalado hacia arriba y hacia abajo) directamente, o elija una plantilla diferente de la vista de lista de [Escalado de Cargas de Trabajo][8]. Los cambios entran en efecto en la próxima reconciliación.
+- **Pause el escalado automático sin eliminar el recurso.** Establezca `applyPolicy.mode: Preview` para mantener las recomendaciones visibles en `.status` mientras evita que el controlador las aplique. Esto es útil cuando se ejecuta junto a un HPA o VPA durante la evaluación.
+- **Observe el despliegue.** La vista de lista de Escalado de cargas de trabajo muestra el estado en vivo de la recomendación de cada carga de trabajo, la última acción aplicada y cualquier error de reconciliación.
+- **Elimine el escalado automático de manera limpia.** Elimine el recurso `DatadogPodAutoscaler` para detener el escalado automático. Los recursos de pod existentes permanecen en sus últimos valores aplicados, y la carga de trabajo vuelve a lo que su controlador padre (Deployment, StatefulSet, etc.) especifica en el próximo despliegue.
+
+## Referencia {#reference}
+
+### Cómo se calculan las recomendaciones verticales {#how-vertical-recommendations-are-calculated}
+
+Datadog calcula recomendaciones de escalado vertical para CPU y memoria analizando datos históricos de uso de contenedores durante los últimos 8 días. La metodología utilizada para cada recurso depende de si la solicitud de ese recurso es igual a su límite, reflejando el concepto de [clase de Calidad de Servicio (QoS) de Kubernetes][14]. La CPU y la memoria se evalúan de manera independiente: una carga de trabajo puede utilizar la metodología Burstable para la CPU y la metodología Garantizada para la memoria, o viceversa.
+
+#### Recomendaciones de memoria {#memory-recommendations}
+
+**Burstable** (la solicitud de memoria es menor que el límite de memoria):
+
+| | Cómo se calcula |
+|---|---|
+| **Recomendación de solicitud** | Basada en el **p95** del uso de memoria durante los últimos 8 días, con un peso decreciente aplicado a muestras más antiguas para que los patrones de uso recientes sean priorizados. Se añade un **margen de seguridad del 10%**. |
+| **Recomendación de límite** | Basada en el **máximo pico de uso de memoria** observado durante los últimos 8 días. Se añade un **margen de seguridad del 5%**. |
+
+**Guaranteed** (la solicitud de memoria es igual al límite de memoria):
+
+| | Cómo se calcula |
+|---|---|
+| **Recomendación de solicitud y límite** | Basada en el **máximo pico de uso de memoria** observado durante los últimos 8 días. Se añade un **margen de seguridad del 5%**. Si se detecta un **OOMKill**, se aplica un **aumento adicional del 20%** para ayudar a prevenir futuros eventos de falta de memoria. |
+
+**Nota:** El seguimiento del uso máximo de memoria captura el mayor uso de memoria registrado por cualquier contenedor que haya existido dentro de la ventana de retroceso de 8 días. Esto significa que incluso si un contenedor comenzó antes de esa ventana, su uso máximo (por ejemplo, al inicio) aún se tiene en cuenta en la recomendación.
+
+#### Recomendaciones de CPU {#cpu-recommendations}
+
+**Burstable** (la solicitud de CPU es menor que el límite de CPU):
+
+| | Cómo se calcula |
+|---|---|
+| **Recomendación de solicitud** | Basada en el **p90** del uso de CPU en relación con la solicitud actual durante los últimos 8 días, con un peso decreciente aplicado a muestras más antiguas para que los patrones de uso recientes tengan prioridad. Se añade un **margen de seguridad del 10 %**. |
+| **Recomendación de límite** | Basada en el **p95** del uso de CPU en relación con la solicitud actual durante los últimos 8 días. Se añade un **margen de seguridad del 5 %**. Si la recomendación de solicitud resultante alguna vez excede la recomendación de límite, se utiliza el valor de solicitud para ambos. |
+
+**Guaranteed** (la solicitud de CPU es igual al límite de CPU):
+
+| | Cómo se calcula |
+|---|---|
+| **Recomendación de solicitud y límite** | Basada en el **p95** del uso de CPU en relación con la solicitud actual durante los últimos 8 días. Se añade un **margen de seguridad del 5 %**. |
+
+#### Principios de diseño clave {#key-design-principles}
+
+- **Ventana de retroceso de 8 días**: Todas las recomendaciones consideran datos de uso de los últimos 8 días, proporcionando suficiente historial para capturar patrones de tráfico semanales mientras se mantiene sensible a los cambios.
+- **Pesos en decadencia**: Para recomendaciones de solicitudes de clase Burstable (CPU o memoria), las muestras más antiguas tienen un peso menor, por lo que la recomendación se adapta más rápido a los cambios recientes en el uso.
+- **Márgenes de seguridad**: Cada recomendación incluye un margen por encima del uso observado (5 a 10 %) para proporcionar un colchón contra picos inesperados.
+- **Respuesta OOMKill**: Cuando la memoria es de clase Guaranteed (la solicitud es igual al límite) y ocurre un OOMKill, se aplica un aumento del 20 % para reducir la probabilidad de fallos repetidos por falta de memoria.
+- **Preservación de clase Guaranteed**: Cuando un recurso tiene una solicitud igual al límite, Datadog utiliza el cálculo más conservador (a nivel de límite) para ambos, asegurando que las recomendaciones no introduzcan una brecha entre la solicitud y el límite.
+
+## Lectura adicional {#further-reading}
+
+{{< partial name="whats-next/whats-next.html" >}}
+
+[1]: /es/agent/remote_config
+[2]: /es/agent/remote_config/?tab=configurationyamlfile#enable-remote-configuration
+[3]: https://helm.sh/
+[4]: https://kubernetes.io/docs/tasks/tools/install-kubectl/
+[5]: /es/containers/kubernetes/distributions
+[6]: https://app.datadoghq.com/orchestration/scaling/summary
+[7]: https://app.datadoghq.com/orchestration/scaling/cluster
+[8]: https://app.datadoghq.com/orchestration/scaling/workload
+[9]: /es/integrations/kubernetes_state_core/
+[10]: https://www.datadoghq.com/product-preview/kubernetes-cluster-autoscaling/
+[11]: https://app.datadoghq.com/orchestration/scaling/setup
+[12]: /es/containers/guide/manage-datadogpodautoscaler-with-argocd/
+[13]: /es/containers/guide/manage-datdadogpodautoscaler-with-terraform/
+[14]: https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/
\ No newline at end of file
diff --git a/content/es/containers/datadog_operator/_index.md b/content/es/containers/datadog_operator/_index.md
index dd5e8f17817..17517eb36f3 100644
--- a/content/es/containers/datadog_operator/_index.md
+++ b/content/es/containers/datadog_operator/_index.md
@@ -2,52 +2,53 @@
aliases:
- /es/agent/kubernetes/operator_configuration
- /es/containers/kubernetes/operator_configuration
+description: Despliega y gestiona el Datadog Agent en Kubernetes utilizando el Datadog
+ Operator
further_reading:
- link: /getting_started/containers/datadog_operator
tag: guía
- text: Empezando con el Datadog Operator
+ text: Introducción al Datadog Operator
- link: https://github.com/DataDog/datadog-operator/blob/main/docs/installation.md
tag: Código fuente
- text: 'Datadog Operator: instalación avanzada'
+ text: 'Datadog Operator: Instalación avanzada'
- link: https://github.com/DataDog/datadog-operator/blob/main/docs/configuration.v2alpha1.md
tag: Código fuente
- text: 'Datadog Operator: configuración'
+ text: 'Datadog Operator: Configuración'
- link: https://www.datadoghq.com/architecture/instrument-your-app-using-the-datadog-operator-and-admission-controller/
tag: Centro de arquitectura
- text: Instrumentar tu aplicación utilizando Datadog Operator y Admission Controller
+ text: Instrumente su aplicación utilizando el Datadog Operator y Admission Controller
title: Datadog Operator
---
+[Datadog Operator][1] es un [Kubernetes Operator][2] de código abierto que le permite desplegar y configurar el Datadog Agent en un entorno de Kubernetes.
-El [Datadog Operator][1] es un [operador Kubernetes][2] de código abierto que te permite implementar y configurar el Datadog Agent en un entorno Kubernetes.
+Al utilizar el Operator, puede usar una única Definición de Recurso Personalizado (CRD) para desplegar el Datadog Agent basado en nodos, el [Cluster Agent][3] y el [cluster checks runner][4]. El Operator informa sobre el estado de despliegue, salud y errores en el estado de la CRD del Operator. Debido a que el Operator utiliza opciones de configuración de nivel superior, limita el riesgo de mala configuración.
-Si utilizas el Operator, bastará con que utilices una sola definición de recursos personalizados (CRD) para implementar el Agent basado en nodos, el [Cluster Agent][3] y el [ejecutor de checks del clúster][4]. El Operator ofrece información sobre el estado y los errores de la implementación a través del estado de su CRD. Debido a que el Operator utiliza opciones de configuración de alto nivel, el riesgo de que se produzcan errores de configuración es bajo.
+Una vez que haya desplegado el Datadog Agent, el Datadog Operator proporciona lo siguiente:
-Una vez que hayas implementado el Agent, el Datadog Operator te proporcionará lo siguiente:
+- Validación de sus configuraciones de Datadog Agent
+- Mantener todos los Datadog Agent actualizados con su configuración
+- Orquestación para crear y actualizar recursos de Datadog Agent
+- Informe del estado de configuración de Datadog Agent en el estado de la CRD del Operator
+- Opcionalmente, uso de un despliegue avanzado de DaemonSet utilizando el [ExtendedDaemonSet][5] de Datadog
-- Validación de las configuraciones del Agent
-- Actualización constante de todos los Agents con tu configuración
-- Orquestación para crear y actualizar los recursos del Agent
-- Información sobre el estado de configuración de Agent a través del estado de la CRD del Operator
-- Opcionalmente, uso de una implementación avanzada de un DaemonSet utilizando [ExtendedDaemonSet][5] de Datadog
+### ¿Por qué usar el Datadog Operator en lugar de un gráfico de Helm o DaemonSet? {#why-use-the-datadog-operator-instead-of-a-helm-chart-or-daemonset}
-### ¿Por qué debería usar el Datadog Operator en vez de un Helm chart o un DaemonSet?
+También puede usar un gráfico de Helm o un DaemonSet para instalar el Datadog Agent en Kubernetes. Sin embargo, el uso del Datadog Operator ofrece las siguientes ventajas:
-Si quieres, también puedes usar un Helm chart o un DaemonSet para instalar el Datadog Agent en Kubernetes. Sin embargo, el Datadog Operator te ofrece estas ventajas:
+- El Operator tiene valores predeterminados integrados basados en las mejores prácticas de Datadog.
+- La configuración del Operator es más flexible para futuras mejoras.
+- Como un [Kubernetes Operator][2], el Datadog Operator es tratado como un recurso de primera clase por la API de Kubernetes.
+- A diferencia del gráfico de Helm, el Operator está incluido en el ciclo de reconciliación de Kubernetes.
-- Los valores predeterminados del Operator parten de las prácticas recomendadas de Datadog.
-- La configuración del Operator presenta una mayor flexibilidad de cara a futuras mejoras.
-- Debido a que el Datadog Operator es un [operador Kubernetes][2], la API de Kubernetes lo trata como un recurso de primera clase.
-- Al contrario de lo que ocurre con los Helm charts, el Operator forma parte del bucle de conciliación de Kubernetes.
+Datadog admite completamente el uso de un DaemonSet para desplegar el Datadog Agent, pero la configuración manual del DaemonSet deja un margen significativo para errores. Por lo tanto, no se recomienda encarecidamente el uso de un DaemonSet.
-Datadog admite sin problemas el uso de un DaemonSet para desplegar el Agent. Sin embargo, no es una opción muy recomendada, dado que la configuración manual de un DaemonSet conlleva un significante margen de error
+## Uso {#usage}
-## Utilización
+Consulte la guía de [Introducción al Datadog Operator][6] para aprender cómo usar el Operator para desplegar el Datadog Agent.
-Consulta la guía [Empezando con el Datadog Operator][6] para obtener información sobre cómo utilizar el Operator para implementar el Datadog Agent.
+Para todas las opciones de instalación y configuración, consulte las páginas detalladas de [instalación][7] y de [configuración][8] en el repositorio [`datadog-operator`][1].
-Para conocer todas las opciones de configuración, consulta las páginas detalladas de [instalación][7] y [configuración][8] del repositorio [`datadog-operator`][1].
-
-## Referencias adicionales
+## Lectura adicional {#further-reading}
{{< partial name="whats-next/whats-next.html" >}}
diff --git a/content/es/containers/docker/apm.md b/content/es/containers/docker/apm.md
index 2b1bfbc834b..6091e480c12 100644
--- a/content/es/containers/docker/apm.md
+++ b/content/es/containers/docker/apm.md
@@ -4,43 +4,42 @@ aliases:
- /es/tracing/setup/docker/
- /es/agent/apm/docker
- /es/agent/docker/apm
-description: Configura la recopilación de traces (trazas) de APM para las aplicaciones
- que se ejecutan en los contenedores de Docker mediante el Datadog Agent
+description: Configura la recolección de trazas de APM para aplicaciones que se ejecutan
+ en contenedores Docker utilizando el Agente de Datadog
further_reading:
- link: https://github.com/DataDog/datadog-agent/tree/main/pkg/trace
tag: Código fuente
- text: Código de origen
+ text: Código fuente
- link: /integrations/amazon_ecs/#trace-collection
tag: Documentación
- text: Rastrear tus aplicaciones de ECS
+ text: Traza tus aplicaciones de ECS
- link: /agent/docker/log/
tag: Documentación
- text: Recopilar tus logs de aplicación
+ text: Recoge los registros de tu aplicación
- link: /agent/docker/integrations/
tag: Documentación
- text: Recopila las métricas de tus aplicaciones y logs automáticamente
+ text: Recoge automáticamente las métricas y registros de tus aplicaciones
- link: /agent/guide/autodiscovery-management/
tag: Documentación
- text: Limita la recopilación de datos solo a un subconjunto de contenedores
+ text: Limita la recolección de datos a un subconjunto de contenedores solamente
- link: /agent/docker/tag/
tag: Documentación
- text: Asignar etiquetas a todos los datos emitidos por un contenedor
-title: Rastrear aplicaciones Docker
+ text: Asigna etiquetas a todos los datos emitidos por un contenedor
+title: Trazando aplicaciones Docker
---
+A partir de la versión 6.0.0 del Agente, el Agente de Trazas está habilitado por defecto. Si se ha desactivado, puedes volver a habilitarlo en el contenedor `registry.datadoghq.com/agent` pasando `DD_APM_ENABLED=true` como una variable de entorno.
-A partir de Agent 6.0.0, el Trace Agent se activa por defecto. Si ha sido desactivado, se puede reactivar en el contenedor `gcr.io/datadoghq/agent` al pasar `DD_APM_ENABLED=true` como una variable de entorno.
+Los comandos de CLI en esta página son para el tiempo de ejecución de Docker. Reemplaza `docker` con `nerdctl` para el tiempo de ejecución de containerd, o `podman` para el tiempo de ejecución de Podman.
-Los comandos de CLI en esta página son para el tiempo de ejecución de Docker. Sustituye `docker` por `nerdctl` para el tiempo de ejecución del containerd, o `podman` para el tiempo de ejecución del Podman.
+Si estás recolectando trazas de una aplicación en contenedores (tu Agente y aplicación ejecutándose en contenedores separados), como alternativa a las siguientes instrucciones, puedes inyectar automáticamente el SDK en tu aplicación. Lee
Inyectando bibliotecas para instrucciones.
Si estás recopilando trazas de una aplicación contenedorizada (tu Agent y tu app se están ejecutando en contenedores separados), una alternativa a las siguientes instrucciones es inyectar la biblioteca de trazas automáticamente en tu aplicación. Consulta
Inyectar bibliotecas para ver las instrucciones.
tu [clave API de Datadog][1].
+: requerido - _cadena_
+
Tu [clave API de Datadog][1].
`DD_SITE`
-: opcional; _cadena_
-
Tu [sitio de Datadog][7]. Establécelo en `{{< region-param key="dd_site" >}}`.
-
**Predeterminado**: `datadoghq.com`
+: opcional - _cadena_
+
Tu [sitio de Datadog][7]. Establece esto en `{{< region-param key="dd_site" >}}`.
+
**Default**: `datadoghq.com`
-`DD_APM_ENABLED`
-: opcional; _booleano_ - **por defecto**: `true`
+`DD_APM_ENABLED`
+: opcional - _Booleano_ - **por defecto**: `true`
Cuando se establece en `true` (por defecto), el Datadog Agent acepta trazas y métricas de traza.
-`DD_APM_RECEIVER_PORT`
-: opcional - _entero_ - **por defecto**: `8126`
-
Establece el puerto en el que escucha el receptor de la traza del Datadog Agent. Establece `0` para desactivar el receptor HTTP.
+`DD_APM_RECEIVER_PORT`
+: opcional - _entero_ - **predeterminado**: `8126`
+
Establece el puerto en el que escucha el receptor de trazas del Agente de Datadog. Establezca en `0` para deshabilitar el receptor HTTP.
-`DD_APM_RECEIVER_SOCKET`
-: opcional: _cadena_
-
Para recopilar tus trazas a través de UNIX Domain Sockets, proporciona la ruta al socket UNIX. Si se establece, tiene prioridad sobre el nombre de host y la configuración del puerto, y debe apuntar a un archivo de socket válido.
+`DD_APM_RECEIVER_SOCKET`
+: opcional - _cadena_
+
Para recopilar sus trazas a través de Sockets de Dominio UNIX, proporcione la ruta al socket UNIX. Si se establece, esto tiene prioridad sobre la configuración de nombre de host y puerto, y debe apuntar a un archivo de socket válido.
-`DD_APM_NON_LOCAL_TRAFFIC`
-: opcional - _Booleano_ - **por defecto**: `false`
-
Cuando se establece en `true`, el Datadog Agent escucha el tráfico no local. Si estás [rastreando desde otros contenedores](#tracing-from-other-containers), establece esta variable de entorno en `true`.
+`DD_APM_NON_LOCAL_TRAFFIC`
+: opcional - _Booleano_ - **predeterminado**: `false`
+
Cuando se establece en `true`, el Agente de Datadog escucha tráfico no local. Si está [trazando desde otros contenedores](#tracing-from-other-containers), establezca esta variable de entorno en `true`.
-`DD_APM_DD_URL`
+`DD_APM_DD_URL`
: opcional - _cadena_
-
Para utilizar un proxy para APM, proporciona el endpoint y el puerto como `:`. El proxy debe poder manejar conexiones TCP.
+
Para usar un proxy para APM, proporcione el punto final y el puerto como `:`. El proxy debe ser capaz de manejar conexiones TCP.
-`DD_APM_CONNECTION_LIMIT`
-: obligatorio - _entero_ - **por defecto**: `2000`
-
Establece el máximo de conexiones APM para una ventana temporal de 30 segundos. Consulta [Límites de frecuencia del Agent][6] para obtener más detalles.
+`DD_APM_CONNECTION_LIMIT`
+: requerido - _entero_ - **predeterminado**: `2000`
+
Establece el número máximo de conexiones APM para un intervalo de 30 segundos. Consulte [Límites de Tasa del Agente][6] para más detalles.
-`DD_APM_IGNORE_RESOURCES`
+`DD_APM_IGNORE_RESOURCES`
: opcional - _[cadena]_
-
Proporciona una lista de exclusión de recursos para que Datadog Agent los ignore. Si el nombre de recurso de una traza coincide con una o más de las expresiones regulares de esta lista, la traza no se envía a Datadog.
-
Ejemplo: `"GET /ignore-me","(GET\|POST) and-also-me"`.
+
Proporciona una lista de exclusión de recursos que el Agente de Datadog debe ignorar. Si el nombre del recurso de una traza coincide con una o más de las expresiones regulares en esta lista, la traza no se envía a Datadog.
+
Ejemplo: `"GET /ignore-me","(GET\|POST) and-also-me"`.
-`DD_APM_FILTER_TAGS_REQUIRE`
+`DD_APM_FILTER_TAGS_REQUIRE`
: opcional - _objeto_
-
Define reglas para el filtrado de trazas basadas en etiqueta. Para enviarlas a Datadog, las trazas deben tener estas etiquetas (tags). Consulta [Ignorar recursos no deseados en APM][5].
+
Define reglas para el filtrado de trazas basado en etiquetas. Para ser enviados a Datadog, las trazas deben tener estas etiquetas. Ver [Ignorando Recursos No Deseados en APM][5].
`DD_APM_FILTER_TAGS_REGEX_REQUIRE`
: opcional - _objeto_
-
Compatible con Agent 7.49+. Define reglas para el filtrado de trazas basadas en etiquetas con expresiones regulares. Para enviarlas a Datadog, las trazas deben tener etiquetas que coincidan con estos patrones regex.
+
Compatible en Agente 7.49+. Define reglas para el filtrado de trazas basado en etiquetas con expresiones regulares. Para ser enviados a Datadog, las trazas deben tener etiquetas que coincidan con estos patrones regex.
-`DD_APM_FILTER_TAGS_REJECT`
+`DD_APM_FILTER_TAGS_REJECT`
: opcional - _objeto_
-
Define reglas para el filtrado de trazas basadas en etiquetas. Si una traza tiene estas etiquetas, no se envía a Datadog. Consulta [Ignorar recursos no deseados en APM][5] para obtener más detalles.
+
Define reglas para el filtrado de trazas basado en etiquetas. Si una traza tiene estas etiquetas, no se envía a Datadog. Ver [Ignorando Recursos No Deseados en APM][5] para más detalles.
-`DD_APM_FILTER_TAGS_REGEX_REJECT`
+`DD_APM_FILTER_TAGS_REGEX_REJECT`
: opcional - _objeto_
-
Compatible con Agent 7.49+. Define reglas para el filtrado de trazas basadas en etiquetas con expresiones regulares. Si una traza tiene etiquetas que coinciden con estos patrones regex, la traza no se envía a Datadog.
+
Compatible con Agent 7.49+. Define reglas para el filtrado de trazas basado en etiquetas con expresiones regulares. Si una traza tiene etiquetas que coinciden con estos patrones de expresión regular, la traza no se envía a Datadog.
-`DD_APM_REPLACE_TAGS`
+`DD_APM_REPLACE_TAGS`
: opcional - _[objeto]_
Define un conjunto de reglas para [reemplazar o eliminar etiquetas que contienen información potencialmente sensible][2].
-`DD_HOSTNAME`
-: opcional - _cadena_ - **por defecto**: detectado automáticamente
-
Establece el nombre de host que se utilizará para métricas si falla la detección automática del nombre de host, o cuando se ejecuta el Datadog Cluster Agent.
+`DD_HOSTNAME`
+: opcional - _cadena_ - **predeterminado**: detectado automáticamente
+
Establece el servidor a utilizar para métricas si la detección automática de servidor falla, o al ejecutar el Agent de clúster de Datadog.
-`DD_DOGSTATSD_PORT`
-: opcional - _entero_ - **por defecto**: `8125`
-
Establece el puerto DogStatsD.
+`DD_DOGSTATSD_PORT`
+: opcional - _entero_ - **predeterminado**: `8125`
+
Establece el puerto de DogStatsD.
-`DD_PROXY_HTTPS`
+`DD_PROXY_HTTPS`
: opcional - _cadena_
-
Para utilizar un [proxy][4] para conectarse a Internet, indica la URL.
+
Para usar un [proxy][4] para conectarse a Internet, proporcione la URL.
-`DD_BIND_HOST`
-: opcional - _cadena_ - **por defecto**: `localhost`
-
Establece el host para escuchar en DogStatsD y trazas.
+`DD_BIND_HOST`
+: opcional - _cadena_ - **predeterminado**: `localhost`
+
Establece el servidor para escuchar en DogStatsD y trazas.
-`DD_LOG_LEVEL`
-: opcional - _cadena_ - **por defecto**: `info`
+`DD_LOG_LEVEL`
+: opcional - _cadena_ - **predeterminado**: `info`
Establece el nivel mínimo de registro. Opciones válidas: `trace`, `debug`, `info`, `warn`, `error`, `critical` y `off`.
-## Rastreando desde otros contenedores
+## Trazas desde otros contenedores {#tracing-from-other-containers}
-Al igual que con DogStatsD, se pueden enviar trazas al Agent desde otros contenedores usando [redes de Docker](#docker-network) o [IP de Docker host](#docker-host-ip).
+Al igual que con DogStatsD, las trazas pueden ser enviadas al Agent desde otros contenedores utilizando [redes de Docker](#docker-network) o con la [IP del servidor de Docker](#docker-host-ip).
-### Red de Docker
+### Red de Docker {#docker-network}
-El primer paso es crear una red puente definida por el usuario:
+Como primer paso, crea una red de puente definida por el usuario:
```bash
docker network create
```
-Los comandos de CLI en esta página son para el tiempo de ejecución de Docker. Sustituye `docker` por `nerdctl` para el tiempo de ejecución del containerd, o `podman` para el tiempo de ejecución del Podman.
+Los comandos de CLI en esta página son para el tiempo de ejecución de Docker. Reemplaza `docker` con `nerdctl` para el tiempo de ejecución de containerd, o `podman` para el tiempo de ejecución de Podman.
-Luego, inicia el Agent y el contenedor de la aplicación, conectados a la red que se ha creado previamente:
+Luego inicia el Agente y el contenedor de la aplicación, conectados a la red previamente creada:
{{< tabs >}}
-{{% tab "Estándar" %}}a
+{{% tab "Estándar" %}}
```bash
# Datadog Agent
@@ -188,7 +187,7 @@ docker run -d --name datadog-agent \
-e DD_APM_ENABLED=true \
-e DD_SITE= \
-e DD_APM_NON_LOCAL_TRAFFIC=true \
- gcr.io/datadoghq/agent:latest
+ registry.datadoghq.com/agent:latest
# Application
docker run -d --name app \
--network \
@@ -196,7 +195,7 @@ docker run -d --name app \
company/app:latest
```
-Donde tu `` es {{< region-param key="dd_site" code="true" >}} (por defecto, `datadoghq.com`).
+Donde se encuentra tu `` {{< region-param key="dd_site" code="true" >}} (por defecto es `datadoghq.com`).
{{% /tab %}}
{{% tab "Windows" %}}
@@ -211,30 +210,30 @@ docker run -d --name datadog-agent \
-e DD_APM_ENABLED=true \
-e DD_SITE= \
-e DD_APM_NON_LOCAL_TRAFFIC=true \
- gcr.io/datadoghq/agent:latest
+ registry.datadoghq.com/agent:latest
# Application
docker run -d --name app \
--network "" \
-e DD_AGENT_HOST=datadog-agent \
company/app:latest
```
-Donde tu `` es {{< region-param key="dd_site" code="true" >}} (por defecto, `datadoghq.com`).
+Donde se encuentra tu `` {{< region-param key="dd_site" code="true" >}} (por defecto es `datadoghq.com`).
{{% /tab %}}
{{< /tabs >}}
-Esto expone el nombre del host `datadog-agent` en tu contenedor `app`.
-Si estás usando `docker-compose`, los parámetros `` son los que están definidos en la sección `networks` de tu `docker-compose.yml`.
+Esto expone el servidor `datadog-agent` en tu contenedor `app`.
+Si estás usando `docker-compose`, los parámetros `` son los definidos en la sección `networks` de tu `docker-compose.yml`.
-Las trazas de tu aplicación deben estas configuradas para que puedan enviar trazas a esta dirección. Configura las variables de entorno con el `DD_AGENT_HOST` como el nombre del contenedor del Agent y `DD_TRACE_AGENT_PORT` como el puerto del Agent Trace en tus contenedores de aplicación. Los ejemplos anteriores usan el host `datadog-agent` y el puerto `8126` (el valor por defecto para que no tengas que configurarlo).
+Tus SDKs de aplicación deben estar configurados para enviar trazas a esta dirección. Establece variables de entorno con `DD_AGENT_HOST` como el nombre del contenedor del Agent, y `DD_TRACE_AGENT_PORT` como el puerto de trazas del Agent en tus contenedores de aplicación. El ejemplo anterior utiliza el host `datadog-agent` y el puerto `8126` (el valor predeterminado, por lo que no tienes que configurarlo).
-Opcionalmente, consulta los ejemplos a continuación para configurar el host del Agent manualmente en cada lenguaje compatible.
+Alternativamente, consulta los ejemplos a continuación para establecer manualmente el host del Agente en cada lenguaje soportado:
{{< programming-lang-wrapper langs="java,python,ruby,go,nodeJS,.NET" >}}
{{< programming-lang lang="java" >}}
-Se puede actualizar la configuración del Java Agent con variables de entorno:
+Actualice la configuración del Java Agent mediante variables de entorno:
```bash
DD_AGENT_HOST=datadog-agent \
@@ -242,7 +241,7 @@ DD_TRACE_AGENT_PORT=8126 \
java -javaagent:/path/to/the/dd-java-agent.jar -jar /your/app.jar
```
-o mediante propiedades de sistema:
+o a través de propiedades del sistema:
```bash
java -javaagent:/path/to/the/dd-java-agent.jar \
@@ -296,7 +295,7 @@ func main() {
{{< /programming-lang >}}
-{{< programming-lang lenguaje="nodeJS" >}}
+{{< programming-lang lang="nodeJS" >}}
```javascript
const tracer = require('dd-trace').init({
@@ -309,7 +308,7 @@ const tracer = require('dd-trace').init({
{{< programming-lang lang=".NET" >}}
-Establece las variables de entorno antes de ejecutar tu app instrumentado:
+Establezca las variables de entorno antes de ejecutar su aplicación instrumentada:
```bash
# Environment variables
@@ -326,28 +325,28 @@ export DD_TRACE_AGENT_PORT=8126
dotnet example.dll
```
-El valor de la variable de entorno `CORECLR_PROFILER_PATH` varia, dependiendo del sistema en el se esté ejecutando la aplicación:
+El valor de la variable de entorno `CORECLR_PROFILER_PATH` varía según el sistema donde se está ejecutando la aplicación:
Sistema Operativo y Arquitectura de Proceso | Valor de CORECLR_PROFILER_PATH
------------------------------------------|----------------------------
Alpine Linux x64 | `/datadog/linux-musl-x64/Datadog.Trace.ClrProfiler.Native.so`
- Linux x64 | `/datadog/linux-x64/Datadog.Trace.ClrProfiler.Native.so`
- Linux ARM64 | `/datadog/linux-arm64/Datadog.Trace.ClrProfiler.Native.so`
- Windows x64 | `\datadog\win-x64\Datadog.Trace.ClrProfiler.Native.dll`
- Windows x86 | `\datadog\win-x86\Datadog.Trace.ClrProfiler.Native.dll`
+ Linux x64 | `/datadog/linux-x64/Datadog.Trace.ClrProfiler.Native.so`
+ Linux ARM64 | `/datadog/linux-arm64/Datadog.Trace.ClrProfiler.Native.so`
+ Windows x64 | `\datadog\win-x64\Datadog.Trace.ClrProfiler.Native.dll`
+ Windows x86 | `\datadog\win-x86\Datadog.Trace.ClrProfiler.Native.dll`
-En la tabla de arriba, `` se refiere al directorio que contiene los archivos `.dll` de la aplicación.
+En la tabla anterior, `` se refiere al directorio que contiene los archivos `.dll` de la aplicación.
{{< /programming-lang >}}
{{< /programming-lang-wrapper >}}
-### IP del Docker host
+### IP del host de Docker {#docker-host-ip}
-El puerto del contenedor del Agent `8126` debería estar vinculado al host directamente.
-Configura el rastreador de tu aplicación a la ruta por defecto de este contenedor (usa el comando `ip route` para obtenerlo).
+El puerto del contenedor del Agent `8126` debe estar vinculado directamente al host.
+Configure su application tracer para informar a la ruta predeterminada de este contenedor (determine esto usando el comando `ip route`).
-A continuación hay un ejemplo para el Python Tracer, suponiendo que `172.17.0.1` es la ruta por defecto:
+Lo siguiente es un ejemplo para el Python Tracer, asumiendo que `172.17.0.1` es la ruta predeterminada:
```python
from ddtrace import tracer
@@ -355,8 +354,8 @@ from ddtrace import tracer
tracer.configure(hostname='172.17.0.1', port=8126)
```
-### Unix Domain Socket (UDS)
-Para enviar trazas mediante un socket, éste debe estar montado en el contenedor del Agent y su contenedor de aplicación.
+### Socket de dominio Unix (UDS) {#unix-domain-socket-uds}
+Para enviar trazas a través de socket, el socket debe estar montado en el contenedor del Agent y en el contenedor de su aplicación.
```bash
# Datadog Agent
@@ -373,7 +372,7 @@ docker run -d --name datadog-agent \
-e DD_SITE= \
-e DD_APM_NON_LOCAL_TRAFFIC=true \
-e DD_APM_RECEIVER_SOCKET=/var/run/datadog/apm.socket \
- gcr.io/datadoghq/agent:latest
+ registry.datadoghq.com/agent:latest
# Application
docker run -d --name app \
--network \
@@ -382,9 +381,9 @@ docker run -d --name app \
company/app:latest
```
-Consulta la [documentación específica en tu idioma de la Instrumentación de APM][3] para conocer la configuración del trazador.
+Consulte la [documentación de instrumentación APM específica del lenguaje][3] para la configuración del tracer.
-## Referencias adicionales
+## Lectura Adicional {#further-reading}
{{< partial name="whats-next/whats-next.html" >}}
diff --git a/content/es/containers/guide/container-discovery-management.md b/content/es/containers/guide/container-discovery-management.md
index cfd2c0fb1ec..053dc8e6aa4 100644
--- a/content/es/containers/guide/container-discovery-management.md
+++ b/content/es/containers/guide/container-discovery-management.md
@@ -4,68 +4,67 @@ aliases:
- /es/agent/kubernetes/management
- /es/agent/guide/autodiscovery-management
- /es/containers/guide/autodiscovery-management
-description: Controla qué contenedores monitoriza el Datadog Agent mediante la configuración
- de reglas de detección y patrones de inclusión/exclusión.
+description: Controle qué contenedores el Datadog Agent monitorea configurando reglas
+ de Autodiscovery y patrones de inclusión/exclusión.
further_reading:
- link: /containers/kubernetes/integrations/
tag: Documentación
- text: Configurar integraciones con Autodiscovery en Kubernetes
+ text: Configure integraciones con Autodiscovery en Kubernetes.
- link: /containers/docker/integrations/
tag: Documentación
- text: Configurar integraciones con Autodiscovery en Docker
-title: Gestión de detección de contenedores
+ text: Configure integraciones con Autodiscovery en Docker.
+title: Gestión del Descubrimiento de Contenedores
---
+Por defecto, el Datadog Agent descubre automáticamente todos los contenedores disponibles. Este documento describe cómo restringir el perímetro de descubrimiento del Datadog Agent y limitar la recolección de datos a un subconjunto de contenedores.
-En forma predeterminada, el Datadog Agent detecta automáticamente todos los contenedores disponibles. En este documento se describe cómo restringir el perímetro de detección del Datadog Agent y limitar la recopilación de datos a un subconjunto de contenedores.
+## Patrones de descubrimiento de contenedores {#container-discovery-patterns}
-## Patrones de detección de contenedores
+En un entorno de contenedores, debe desplegar el Datadog Agent una vez por servidor. Cada Datadog Agent desplegado descubre y monitorea automáticamente todos los contenedores en su respectivo servidor. Cuando se habilita la opción de registros [`containerCollectAll` opción][1], el Datadog Agent recolecta registros de todos los contenedores descubiertos.
-En un entorno de contenedores, debes desplegar el Datadog Agent una vez por host. Cada Datadog Agent desplegado detecta y monitoriza en forma automática todos los contenedores en tu respectivo host. Cuando se activa la [opción `containerCollectAll`][1] de logs, el Agent recopila los logs de todos los contenedores detectados.
+Puede ajustar las reglas de descubrimiento para el Datadog Agent y restringir la recolección de métricas y registros. Cualquier contenedor restringido de la recolección de métricas también está restringido para cualquier integración del Datadog Agent basada en [Autodiscovery][2].
-Puedes ajustar las reglas de detección del Agent para restringir la recopilación de métricas y logs. Cualquier contenedor que tenga restringida la recopilación de métricas también está restringido para cualquier integración del Agent basada en [Autodiscovery][2].
+Puede establecer excepciones de dos maneras:
-Puedes establecer excepciones de dos maneras:
+- Proporcione variables de entorno al contenedor del Datadog Agent como una lista de permitidos/bloqueados de contenedores. Recomendado si tiene una lista de nombres de contenedores, imágenes o namespaces para excluir en todo el clúster.
+- Agregue anotaciones a sus pods de Kubernetes para bloquear pods o contenedores individuales. Recomendado si necesita exclusiones más precisas.
-- Proporciona variables de entorno al contenedor del Datadog Agent como una lista de contenedores permitidos/bloqueados. Recomendado si tienes una lista de nombres de contenedores, imágenes o espacios de nombres que excluir para todo el clúster.
-- Añade anotaciones a tus pods de Kubernetes para bloquear pods o contenedores individuales. Recomendado si necesitas exclusiones precisas.
+**Nota**: Las métricas `kubernetes.containers.running`, `kubernetes.pods.running`, `docker.containers.running`, `.stopped`, `.running.total` y `.stopped.total` no se ven afectadas por estas configuraciones y siempre cuentan todos los contenedores.
-**Nota**: Las métricas `kubernetes.containers.running`, `kubernetes.pods.running`, `docker.containers.running`, `.stopped`, `.running.total` y `.stopped.total` no se verán afectadas por estos ajustes y siempre contabilizan todos los contenedores.
+## Coincidencia de patrones simple {#simple-pattern-matching}
-## Concordancia de patrones simple
-
-Utiliza las variables de entorno de la tabla siguiente para configurar el filtrado de contenedores. Cada inclusión o exclusión se define como una lista de cadenas de expresiones regulares separadas por espacios. Puedes incluir o excluir contenedores en función de su:
+Utilice las variables de entorno en la tabla a continuación para configurar el filtrado de contenedores. Cada inclusión o exclusión se define como una lista de cadenas regex separadas por espacios. Puede incluir o excluir contenedores según su:
- nombre del contenedor (`name`)
- nombre de la imagen del contenedor (`image`)
-- Espacio de nombres (`kube_namespace`) de Kubernetes
+- espacio de nombres de Kubernetes (`kube_namespace`)
-El parámetro `name` solo se aplica a los nombres de contenedor, no a los nombres de pod, aunque el contenedor se ejecute en un pod de Kubernetes.
+El parámetro `name` solo se aplica a los nombres de contenedores, no a los nombres de pods, incluso si el contenedor se ejecuta en un pod de Kubernetes.
-### Variables de entorno
+### Variables de entorno {#environment-variables}
-En el **Agent v7.20 o posterior**, utiliza las siguientes variables de entorno para excluir contenedores por nombre de imagen, nombre de contenedor o espacio de nombres de Kubernetes. Los logs y las métricas no se recopilan de los contenedores excluidos.
+En **Datadog Agent v7.20+**, utilice las siguientes variables de entorno para excluir contenedores por nombre de imagen, nombre de contenedor o espacio de nombres de Kubernetes. No se recopilan registros ni métricas de los contenedores excluidos.
| Variable de entorno | Descripción |
| ------------------------------ | --------------------------------------------------- |
-| `DD_CONTAINER_EXCLUDE` | Lista de contenedores a excluir. |
-| `DD_CONTAINER_EXCLUDE_METRICS` | Lista de contenedores cuyas métricas están excluidas. |
-| `DD_CONTAINER_EXCLUDE_LOGS` | Lista de contenedores cuyos logs están excluidos. |
-| `DD_CONTAINER_INCLUDE` | Lista de contenedores a incluir. |
-| `DD_CONTAINER_INCLUDE_METRICS` | Lista de contenedores cuyas métricas están incluidas. |
-| `DD_CONTAINER_INCLUDE_LOGS` | Lista de contenedores cuyos logs están incluidos. |
+| `DD_CONTAINER_EXCLUDE` | Lista de bloqueo de contenedores a excluir. |
+| `DD_CONTAINER_EXCLUDE_METRICS` | Lista de bloqueo de contenedores cuyas métricas están excluidas. |
+| `DD_CONTAINER_EXCLUDE_LOGS` | Lista de bloqueo de contenedores cuyos registros están excluidos. |
+| `DD_CONTAINER_INCLUDE` | Lista de permitidos de contenedores a incluir. |
+| `DD_CONTAINER_INCLUDE_METRICS` | Lista de permitidos de contenedores cuyas métricas están incluidas. |
+| `DD_CONTAINER_INCLUDE_LOGS` | Lista de permitidos de contenedores cuyos registros están incluidos. |
-{{% collapse-content title="Setting environment variables" level="h4" expanded=false id="setting-environment-variables" %}}
+{{% collapse-content title="Configuración de variables de entorno" level="h4" expanded=false id="setting-environment-variables" %}}
{{< tabs >}}
{{% tab "Datadog Operator" %}}
-En Datadog Operator, configura estas variables de entorno en `spec.override.nodeAgent.env`.
+En el Datadog Operator, configure estas variables de entorno bajo `spec.override.nodeAgent.env`.
-##### Ejemplo
+##### Ejemplo {#example}
```yaml
apiVersion: datadoghq.com/v2alpha1
@@ -86,7 +85,7 @@ spec:
{{% /tab %}}
{{% tab "Helm" %}}
-En su gráfico de Helm, suministre una cadena separada por espacios a uno o más de los siguientes:
+En su gráfico de Helm, proporcione una cadena separada por espacios a uno o más de los siguientes:
- `datadog.containerExclude`
- `datadog.containerInclude`
- `datadog.containerExcludeLogs`
@@ -94,7 +93,7 @@ En su gráfico de Helm, suministre una cadena separada por espacios a uno o más
- `datadog.containerExcludeMetrics`
- `datadog.containerIncludeMetrics`
-##### Ejemplo
+##### Ejemplo {#example-1}
```yaml
datadog:
@@ -103,17 +102,17 @@ datadog:
```
{{% /tab %}}
-{{% tab "Agent en contenedores" %}}
+{{% tab "Agente en contenedor" %}}
-En entornos en los que no se utiliza Datadog Operator ni Helm, se pueden pasar las siguientes variables de entorno al contenedor del Agent al inicio.
+En entornos en los que no utiliza el Datadog Operator o Helm, las siguientes variables de entorno pueden pasarse al contenedor del Datadog Agent al inicio.
-##### Ejemplo de Docker
+##### Ejemplo de Docker {#example-docker}
```shell
docker run -e DD_CONTAINER_EXCLUDE=image: ...
```
-##### Ejemplo de ECS
+##### Ejemplo de ECS {#example-ecs}
```json
"environment": [
@@ -132,11 +131,11 @@ docker run -e DD_CONTAINER_EXCLUDE=image: ...
-Los filtros de nombre de imagen (`image`) coinciden en todos los nombres completos de la imagen, incluido el registro y la tag (etiqueta) o resumen de la imagen (por ejemplo, `dockerhub.io/NGINX:1.13.1`).
+Los filtros de nombre de imagen (`image`) se aplican a todo el nombre de la imagen, incluyendo el registro y la etiqueta o digest de la imagen (por ejemplo, `dockerhub.io/nginx:1.13.1`).
-#### Ejemplos
+#### Ejemplos {#examples}
Para excluir el contenedor con el nombre `dd-agent`:
@@ -144,13 +143,13 @@ Para excluir el contenedor con el nombre `dd-agent`:
DD_CONTAINER_EXCLUDE = "name:^dd-agent$"
```
-Para excluir los contenedores que utilizan la imagen `dockercloud/network-daemon`, incluidas todas las tags (etiquetas) y los resúmenes:
+Para excluir contenedores que utilizan la imagen `dockercloud/network-daemon`, incluyendo todas las etiquetas y digests:
```
DD_CONTAINER_EXCLUDE = "image:^dockercloud/network-daemon(@sha256)?:.*
```
-Para excluir contenedores mediante la imagen `dockercloud/network-daemon:1.13.0`:
+Para excluir contenedores que utilizan la imagen `dockercloud/network-daemon:1.13.0`:
```
DD_CONTAINER_EXCLUDE = "image:^dockercloud/network-daemon:1.13.0$"
@@ -162,7 +161,7 @@ Para excluir cualquier contenedor cuya imagen contenga la palabra `agent`:
DD_CONTAINER_EXCLUDE = "image:agent"
```
-Para excluir cualquier contenedor que utilice la imagen `foo` independientemente del registro:
+Para excluir cualquier contenedor que utilice la imagen `foo` sin importar el registro:
```
DD_CONTAINER_EXCLUDE = "image:^.*/foo(@sha256)?:.*"
@@ -174,27 +173,27 @@ Para excluir todos los contenedores:
DD_CONTAINER_EXCLUDE = "name:.*"
```
-También puedes utilizar `image:.*` o `kube_namespace:.*`. La configuración de `.*` sin un prefijo `name:`, `image:` o `kube_namespace:` no funciona.
+Alternativamente, también puede usar `image:.*` o `kube_namespace:.*`. Configurar `.*` sin un prefijo `name:`, `image:` o `kube_namespace:` no funciona.
-### Comportamiento de inclusión y exclusión
+### Comportamiento de inclusión y exclusión {#inclusion-and-exclusion-behavior}
-En general, la inclusión tiene prioridad sobre la exclusión. Por ejemplo, para sólo monitorizar las imágenes `ubuntu` o `debian`, primero excluye todas las demás imágenes y luego especifique qué imágenes incluir:
+Generalmente, la inclusión tiene prioridad sobre la exclusión. Por ejemplo, para monitorear solo imágenes `ubuntu` o `debian`, primero excluya todas las demás imágenes y luego especifique cuáles imágenes incluir:
```
DD_CONTAINER_EXCLUDE = "image:.*"
DD_CONTAINER_INCLUDE = "image:^docker.io/library/ubuntu(@sha256)?:.* image:^docker.io/library/debian(@sha256)?:.*"
```
-La única excepción a esta regla son las anotaciones de exclusión de pods como `ad.datadoghq.com/exclude`. Cuando una aplicación tiene una anotación de exclusión configurada en `true`, esta tiene prioridad y el contenedor queda excluido de ser autodetectado para su monitorización. Por ejemplo, tener una condición que incluya cada contenedor como `DD_CONTAINER_INCLUDE = "image:.*"` no garantiza que un contenedor sea incluido si tiene una anotación de exclusión establecida en él. Consulta [Gestión de detección de contenedores - configuración de exclusión de pods](#pod-exclude-configuration) para obtener más información.
+La única excepción a esta regla son las anotaciones de exclusión de pod como `ad.datadoghq.com/exclude`. Cuando una aplicación tiene una anotación de exclusión establecida en `true`, esto tiene prioridad, y el contenedor es excluido de ser autodetectado para monitoreo. Por ejemplo, tener una condición que incluya todos los contenedores como `DD_CONTAINER_INCLUDE = "image:.*"` no garantiza que un contenedor esté incluido si tiene una anotación de exclusión establecida en él. Consulte [Gestión de Descubrimiento de Contenedores - Configuración de exclusión de Pod](#pod-exclude-configuration) para más información.
-No puedes mezclar reglas de inclusión/exclusión entre categorías. Por ejemplo, si quieres incluir un contenedor con el nombre de imagen `foo` y excluir solo las métricas de un contenedor con el nombre de imagen `bar`, lo siguiente **no es suficiente**:
+No puede mezclar reglas de inclusión/exclusión entre categorías. Por ejemplo, si desea incluir un contenedor con el nombre de imagen `foo` y excluir solo las métricas de un contenedor con el nombre de imagen `bar`, lo siguiente es **no suficiente**:
```
DD_CONTAINER_EXCLUDE_METRICS = "image:^docker.io/library/bar(@sha256)?:.*"
DD_CONTAINER_INCLUDE = "image:^docker.io/library/foo(@sha256)?:.*"
```
-Será mejor que utilices lo siguiente:
+En su lugar, usa:
```
DD_CONTAINER_EXCLUDE_METRICS = "image:^docker.io/library/bar(@sha256)?:.*"
@@ -202,20 +201,20 @@ DD_CONTAINER_INCLUDE_METRICS = "image:^docker.io/library/foo(@sha256)?:.*"
DD_CONTAINER_INCLUDE_LOGS = "image:^docker.io/library/foo(@sha256)?:.*"
```
-No existe una interacción entre las listas globales y las listas selectivas (logs y métricas). En otras palabras, no se puede excluir un contenedor globalmente (`DD_CONTAINER_EXCLUDE`) y luego incluirlo con `DD_CONTAINER_INCLUDE_LOGS` y `DD_CONTAINER_INCLUDE_METRICS`.
+No hay interacción entre las listas globales y las listas selectivas (registros y métricas). En otras palabras, no puedes excluir un contenedor globalmente (`DD_CONTAINER_EXCLUDE`) y luego incluirlo con `DD_CONTAINER_INCLUDE_LOGS` y `DD_CONTAINER_INCLUDE_METRICS`.
-### Contenedores pausados
+### Pausar contenedores {#pause-containers}
-El Datadog Agent excluye los contenedores de Kubernetes y OpenShift pausados en forma predeterminada. Esto impide la recopilación de sus métricas y su recuento como contenedores facturables. De todas maneras, se siguen contabilizando en las métricas de count de contenedores como `kubernetes.containers.running` y `docker.containers.running`.
+El Agente de Datadog excluye los contenedores de pausa de Kubernetes y OpenShift por defecto. Esto impide su recolección de métricas y que se cuenten como contenedores facturables. Aún se cuentan en las métricas de conteo de contenedores como `kubernetes.containers.running` y `docker.containers.running`.
-Para desactivar este comportamiento e incluir la monitorización de los contenedores pausados:
+Para deshabilitar este comportamiento e incluir la monitorización de los contenedores de pausa:
{{< tabs >}}
-{{% tab "Datadog Operator" %}}
+{{% tab "Operador de Datadog" %}}
-En el Datadog Operator, configura estas variables de entorno como `spec.override.nodeAgent.env`.
+En Datadog Operator, establece estas variables de entorno bajo `spec.override.nodeAgent.env`.
-##### Ejemplo
+##### Ejemplo {#example-2}
```yaml
apiVersion: datadoghq.com/v2alpha1
@@ -236,9 +235,9 @@ spec:
{{% /tab %}}
{{% tab "Helm" %}}
-En tu gráfico de Helm, establece `datadog.excludePauseContainer` como `true` o `false`.
+En su chart de Helm, establezca `datadog.excludePauseContainer` en `true` o `false`.
-##### Ejemplo
+##### Ejemplo {#example-3}
```yaml
datadog:
@@ -248,39 +247,39 @@ datadog:
```
{{% /tab %}}
-{{% tab "Agent en contenedores" %}}
+{{% tab "Agente en contenedor" %}}
-En los entornos en los que no utilizas Helm o el Operator, puedes transferir las siguientes variables de entorno al contenedor del Agent en el inicio.
+En entornos en los que no utiliza Helm o el Datadog Operator, las siguientes variables de entorno pueden pasarse al contenedor del Datadog Agent al inicio.
-Establece `DD_EXCLUDE_PAUSE_CONTAINER` como `false`.
+Establezca `DD_EXCLUDE_PAUSE_CONTAINER` en `false`.
{{% /tab %}}
{{< /tabs >}}
-## Exclusión anticipada del CEL
+## Exclusión CEL avanzada {#advanced-cel-exclusion}
-En el **Agent v7.73+**, puedes utilizar la opción de configuración `cel_workload_exclude` para filtrar contenedores de Autodiscovery. Esta función te permite definir reglas [Common Expression Langauge][3] para seleccionar contenedores que deben excluirse de la recopilación de telemetría.
+En **Datadog Agent v7.73+**, puede usar la opción de configuración `cel_workload_exclude` para filtrar contenedores de Autodiscovery. Esta función le permite definir reglas de [Common Expression Language][3] para identificar contenedores que deben ser excluidos de la recolección de telemetría.
-Utiliza los siguientes atributos para representar el objeto de contenedor en tus reglas de filtrado:
+Utilice los siguientes atributos para representar el objeto contenedor en sus reglas de filtrado:
| Atributo | Descripción |
|-----------------------------|-------------------------------------------------------------------------|
| `container.name` | El nombre del contenedor. |
-| `container.image.reference` | La referencia completa de la imagen del contenedor (registro, repositorio, tag/resumen). |
+| `container.image.reference` | La referencia completa de la imagen del contenedor (registro, repositorio, etiqueta/digest). |
| `container.pod.name` | El nombre del pod que ejecuta el contenedor. |
| `container.pod.namespace` | El espacio de nombres de Kubernetes del pod. |
-| `container.pod.annotations` | Las anotaciones aplicadas al pod (mapa clave-valor). |
+| `container.pod.annotations` | Las anotaciones aplicadas al pod (mapa de clave-valor). |
-### Estructura de la configuración
+### Estructura de configuración {#configuration-structure}
-La opción de configuración `cel_workload_exclude` se estructura como una lista de conjuntos de reglas evaluadas como OR lógicos, donde un contenedor se excluye si coincide con alguna regla. Cada conjunto de reglas define los `products` que deben excluirse y el CEL correspondiente `rules` que debe coincidir con los contenedores.
+La opción de configuración `cel_workload_exclude` está estructurada como una lista de conjuntos de reglas evaluadas como OR lógicos, donde un contenedor es excluido si coincide con alguna regla. Cada conjunto de reglas define el `products` a excluir y el correspondiente CEL `rules` para coincidir con los contenedores.
-El campo `products` acepta `metrics`, `logs` y `global` (excluye el contenedor de todos los productos de la lista).
+El campo `products` acepta `metrics`, `logs` y `global` (excluir contenedor de todos los productos listados).
-Si la configuración contiene errores estructurales o problemas de sintaxis de CEL, el Agent sale con un error para evitar la recopilación de telemetría no deseada que podría afectar a la facturación.
+Si la configuración contiene errores estructurales o problemas de sintaxis CEL, el Datadog Agent sale con un error para evitar la recopilación de telemetría no intencionada que podría afectar la facturación.
-En el siguiente ejemplo, las métricas y los logs se excluyen para cualquier contenedor con `NGINX` en su nombre que se ejecute en el espacio de nombres `staging`. Además, se excluyen los logs de cualquier contenedor que ejecute la imagen `redis` O cualquier contenedor dentro de un pod que tenga la anotación `low_priority: "true"`. El [archivo de configuración del Agent][4] se puede actualizar directamente como se ve en este ejemplo.
+En el ejemplo a continuación, se excluyen métricas y registros para cualquier contenedor con `nginx` en su nombre que se ejecute en el espacio de nombres `staging`. Además, se excluyen registros para cualquier contenedor que ejecute la imagen `redis`, o cualquier contenedor dentro de un pod que tenga la anotación `low_priority: "true"`. El [archivo de configuración del Agent][4] se puede actualizar directamente como se ve en este ejemplo.
```yaml
# datadog.yaml
@@ -296,18 +295,18 @@ cel_workload_exclude:
- container.pod.annotations["low_priority"] == "true"
```
-También puedes configurar la exclusión de cargas de trabajo respaldada por CEL utilizando uno de los siguientes métodos:
-- Configura la variable de entorno `DD_CEL_WORKLOAD_EXCLUDE` con una cadena con formato JSON que contenga tus reglas, en cualquier configuración del Agent en contenedores.
-- Para Datadog Operator o Helm Chart, añade tus reglas de CEL a la opción de configuración correspondiente (como se muestra en los ejemplos siguientes).
+También puede configurar la exclusión de carga de trabajo respaldada por CEL utilizando uno de los siguientes métodos:
+- Establezca la variable de entorno `DD_CEL_WORKLOAD_EXCLUDE` con una cadena en formato JSON que contenga sus reglas, en cualquier configuración de Agent en contenedores.
+- Para el Operador de Datadog o Helm Chart, agregue sus reglas CEL a la opción de configuración apropiada (como se muestra en los ejemplos a continuación).
-{{% collapse-content title="Configuring CEL exclusion rules" level="h4" expanded=false id="setting-environment-variables" %}}
+{{% collapse-content title="Configurando reglas de exclusión CEL" level="h4" expanded=false id="setting-environment-variables" %}}
{{< tabs >}}
{{% tab "Datadog Operator" %}}
-En Datadog Operator (>=v1.23.0), utiliza las opciones `spec.override.nodeAgent.celWorkloadExclude` y `spec.override.clusterAgent.celWorkloadExclude`.
+En Datadog Operator (>=v1.23.0), utilice las opciones `spec.override.nodeAgent.celWorkloadExclude` y `spec.override.clusterAgent.celWorkloadExclude`.
-##### Ejemplo
+##### Ejemplo {#example-4}
```yaml
apiVersion: datadoghq.com/v2alpha1
@@ -336,9 +335,9 @@ spec:
{{% /tab %}}
{{% tab "Helm" %}}
-En tu gráfico de Helm, utiliza la opción de configuración `datadog.celWorkloadExclude`.
+En su gráfico de Helm, utilice la opción de configuración `datadog.celWorkloadExclude`.
-##### Ejemplo
+##### Ejemplo {#example-5}
```yaml
datadog:
@@ -350,17 +349,17 @@ datadog:
```
{{% /tab %}}
-{{% tab "Agent en contenedores" %}}
+{{% tab "Agente en contenedor" %}}
-En los entornos en los que no utilizas Helm o el Operator, puedes transferir las siguientes variables de entorno al contenedor del Agent en el inicio.
+En entornos donde no esté utilizando Helm o el Operator, las siguientes variables de entorno pueden pasarse al contenedor del Agent al inicio.
-##### Ejemplo de Docker
+##### Ejemplo de Docker {#example-docker-1}
```shell
docker run -e DD_CEL_WORKLOAD_EXCLUDE= ...
```
-##### Ejemplo de ECS
+##### Ejemplo de ECS {#example-ecs-1}
```json
"environment": [
@@ -377,9 +376,9 @@ docker run -e DD_CEL_WORKLOAD_EXCLUDE= ...
{{% /collapse-content %}}
-{{% collapse-content title="Validating configuration option" level="h4" expanded=false id="validating-configuration-option" %}}
+{{% collapse-content title="Validando la opción de configuración" level="h4" expanded=false id="validating-configuration-option" %}}
-Utiliza el comando `agent workloadfilter verify-cel` para validar la sintaxis de tu configuración antes del despliegue. Acepta entradas de YAML o JSON a través de stdin. El siguiente ejemplo muestra cómo la validación detecta un error de campo no definido:
+Utilice el comando `agent workloadfilter verify-cel` para validar la sintaxis de su configuración antes de la implementación. Acepta entrada en YAML o JSON a través de stdin. El siguiente ejemplo demuestra la validación que captura un error de campo indefinido:
```json
### cel-config.json
@@ -424,7 +423,7 @@ Error: CEL compilation failed
{{% /collapse-content %}}
-#### Ejemplos de normas
+#### Reglas de ejemplo {#example-rules}
Para excluir el contenedor con una anotación de pod específica:
@@ -438,48 +437,54 @@ Para excluir el contenedor en espacios de nombres sin la subcadena `-dev`:
!container.pod.namespace.matches("-dev")
```
-Para excluir el contenedor con el nombre `NGINX-server` solo en el espacio de nombres `prod`:
+Para excluir el contenedor con el nombre `nginx-server` solo en el espacio de nombres `prod`:
```yaml
container.name == "nginx-server" && container.pod.namespace == "prod"
```
-Para excluir el contenedor que ejecuta una imagen con la subcadena `NGINX`:
+Para excluir el contenedor que ejecuta una imagen con la subcadena `nginx`:
```yaml
container.image.reference.matches("nginx")
```
-Para excluir el contenedor utilizando la lógica agrupada (por ejemplo, un nombre de contenedor específico en cualquiera de los dos espacios de nombres):
+Para excluir el contenedor utilizando lógica agrupada (por ejemplo, un nombre de contenedor específico en cualquiera de dos espacios de nombres):
```yaml
container.name == "redis" && (container.pod.namespace == "production" || container.pod.namespace == "staging")
```
-Para excluir contenedores en función del nombre del propietario del pod (por ejemplo, dirigirse a todos los contenedores creados por un Deployment o CronJob llamado `my-app`):
+Para excluir contenedores basados en el nombre del propietario de su pod (por ejemplo, apuntando a todos los contenedores creados por un Deployment o CronJob llamado `my-app`):
```yaml
container.pod.name.startsWith("my-app")
```
-## Configuración de exclusión de pods
+Para **incluir únicamente** contenedores en un conjunto particular de namespaces:
+
+```yaml
+!(container.pod.namespace in ["foo", "bar", "baz"])
+```
+
+## Configuración de exclusión de pod {#pod-exclude-configuration}
-En el **Agent v7.45 o posterior** puedes incluir anotaciones en tus pods de Kubernetes para controlar Autodiscovery. Configura las siguientes anotaciones con el valor `"true"` para añadir reglas de exclusión.
+En **Agent v7.45+** puede establecer anotaciones en sus pods de Kubernetes para controlar Autodiscovery. Establezca las siguientes anotaciones con el valor `"true"` para agregar reglas de exclusión.
| Anotación | Descripción |
| --------------------------------------------------- | -------------------------------------------------------------------------------- |
| `ad.datadoghq.com/exclude` | Excluye todo el pod |
-| `ad.datadoghq.com/logs_exclude` | Excluye la recopilación de logs de todo el pod |
-| `ad.datadoghq.com/metrics_exclude` | Excluye la recopilación de métricas de todo el pod |
-| `ad.datadoghq.com/.exclude` | Excluye el contenedor con `` en el pod |
-| `ad.datadoghq.com/.logs_exclude` | Excluye la recopilación de logs del contenedor con `` en el pod |
-| `ad.datadoghq.com/.metrics_exclude` | Excluye la recopilación de métricas del contenedor con `` en el pod |
+| `ad.datadoghq.com/logs_exclude` | Excluye la recolección de registros de todo el pod |
+| `ad.datadoghq.com/metrics_exclude` | Excluye la recolección de métricas de todo el pod |
+| `ad.datadoghq.com/.exclude` | Excluye el contenedor con `` en el pod |
+| `ad.datadoghq.com/.logs_exclude` | Excluye la recolección de registros del contenedor con `` en el pod |
+| `ad.datadoghq.com/