Este artículo está basado en la documentación oficial de Dynatrace vigente a marzo de 2026. La plataforma evoluciona con frecuencia — antes de implementar cualquier patrón, conviene revisar la documentación oficial actualizada.
En entornos de producción modernos basados en contenedores y orquestados con Kubernetes, la monitorización integral es un reto creciente. Dynatrace OneAgent se ha consolidado como una solución potente para obtener visibilidad profunda en aplicaciones distribuidas, pero su despliegue en contenedores requiere un enfoque arquitectónico cuidadoso para maximizar valor y minimizar impacto operativo.
Este artículo aborda los patrones recomendados para desplegar Dynatrace OneAgent en contenedores desde la experiencia real en entornos complejos. Se analizarán las decisiones clave, los trade-offs inherentes y los errores comunes que pueden comprometer la calidad de la monitorización o la estabilidad de la plataforma. El objetivo es dotar al SRE o arquitecto de observabilidad de marcos mentales para evaluar cuándo y cómo integrar OneAgent en pipelines de telemetría containerizada, y cuándo buscar alternativas o ajustes.
Al finalizar, el lector dispondrá de criterios claros para diseñar arquitecturas de monitorización basadas en Dynatrace que escalen con la complejidad del entorno, manteniendo la integridad operacional y la calidad de datos para análisis avanzados con Davis AI, Smartscape y demás capacidades clave.
Contexto técnico y estratégico del despliegue de OneAgent en contenedores
Dynatrace OneAgent es un agente de instrumentación automática que captura telemetría detallada a nivel de sistema operativo, procesos, redes y aplicaciones. En entornos tradicionales, se instala directamente en hosts físicos o máquinas virtuales. En arquitecturas cloud-native, la aplicación se ejecuta en contenedores efímeros y dinámicos, lo que impone retos para la instalación y gestión del agente.
El despliegue de OneAgent en contenedores debe garantizar:
- Visibilidad completa: captura de métricas, trazas y logs sin lag ni pérdida, incluso en ciclos cortos de vida de contenedores.
- Minimización del impacto: evitar sobrecarga de CPU, memoria o red que pueda afectar la estabilidad del clúster o la latencia de las aplicaciones.
- Automatización y escalabilidad: adaptación a la creación y destrucción dinámica de contenedores, sin intervención manual.
- Integración con la plataforma: compatibilidad con orquestadores, políticas de seguridad y modelos de despliegue.
Desde un punto de vista estratégico, el objetivo es que OneAgent aporte datos confiables para alimentar las capacidades avanzadas de Dynatrace —como análisis basados en IA, visualización Smartscape y alertas inteligentes— sin convertirse en un punto de fricción operacional.
El Dynatrace Operator: el punto de entrada real
Antes de entrar en los modos de despliegue disponibles, hay que aclarar algo que mucha documentación desactualizada todavía omite: nadie despliega hoy OneAgent directamente como DaemonSet de forma manual. Eso era el procedimiento hasta que Dynatrace lanzó el Operator. El despliegue manual está oficialmente deprecado — la recomendación es usar el Dynatrace Operator para la gestión automatizada del ciclo de vida, actualizaciones coordinadas y enriquecimiento de metadatos.
El Operator es el punto de entrada real. A partir de ahí, defines el modo de despliegue en un DynaKube Custom Resource — el objeto de Kubernetes que describe cómo quieres monitorizar tu clúster. Puedes instalarlo vía Helm o kubectl apply.
Los cuatro modos de despliegue
cloudNativeFullStack — el modo recomendado
Desde el Operator 1.0 (abril 2024), cloudNativeFullStack es el modo por defecto. Combina monitorización de host y de aplicación usando dos mecanismos modernos de Kubernetes: admission webhooks para interceptar pods antes de que arranquen, y CSI Driver para montar los code modules como volúmenes. El resultado es inyección automática sin race conditions y con menores privilegios que el modo clásico.
Cuándo usarlo: la mayoría de entornos Kubernetes productivos con autoscaling, alta rotación de pods o requisitos de seguridad.
classicFullStack — el modo legacy, aún soportado
El OneAgent corre como DaemonSet en cada nodo e inyecta los code modules en los pods que detecta. El problema: si un pod de aplicación arranca antes que el OneAgent del nodo, ese pod queda sin instrumentar y hay que reiniciarlo manualmente. En entornos con autoscaling agresivo esto no es una posibilidad teórica — es algo que ocurre con regularidad.
Cuándo usarlo: entornos estables sin autoscaling frecuente, o como paso intermedio en una migración hacia cloudNativeFullStack.
applicationMonitoring — solo capa de aplicación
Usa los mismos mecanismos que cloudNativeFullStack (webhook + CSI Driver) pero sin recoger métricas de host ni de nodo. Útil cuando la infraestructura ya está cubierta por otra herramienta y solo se necesita observabilidad de aplicación.
Cuándo usarlo: entornos donde la plataforma de infraestructura es gestionada por otro equipo o herramienta, y solo se necesita instrumentar el código.
hostMonitoring — solo infraestructura
El caso opuesto: monitoriza los nodos sin inyectar nada en los pods. Sin visibilidad de aplicación, solo métricas de sistema.
Cuándo usarlo: nodos de sistema, workers dedicados a tareas de infraestructura, o como complemento a otros modos en entornos mixtos.
El problema que resuelve cloudNativeFullStack: la race condition
Este es el detalle técnico que más impacto tiene en producción y que más se subestima al diseñar el despliegue.
En classicFullStack, el OneAgent del nodo es responsable de detectar los pods nuevos e inyectar los code modules. Si el pod de aplicación arranca antes de que el OneAgent esté listo en ese nodo — algo habitual cuando escala un nodo nuevo y los pods se despliegan en los nodos rápidamente — ese pod queda sin instrumentar. La solución es reiniciarlo, lo que en producción tiene un coste operativo y de disponibilidad real.
En cloudNativeFullStack, la inyección la ejecuta el webhook antes de que el pod arranque. El CSI Driver descarga el code module una vez por nodo y lo monta como volumen en el init container del pod. El resultado: el pod arranca ya instrumentado desde el primer segundo, sin necesidad de que ningún agente esté corriendo previamente en el nodo.
Esto también tiene implicaciones de seguridad: cloudNativeFullStack no necesita acceso de escritura al sistema de ficheros del nodo, lo que reduce la superficie de ataque y simplifica el cumplimiento de políticas de seguridad estrictas.
Decisiones clave y trade-offs
Visibilidad vs. impacto operativo
El despliegue de cloudNativeFullStack ofrece la visibilidad más completa con el menor riesgo operativo. Sin embargo, requiere que el CSI Driver y el webhook estén operativos antes de que lleguen workloads al clúster. En migraciones desde classicFullStack, todos los pods existentes necesitan reiniciarse para recibir la inyección por el nuevo mecanismo.
Automatización vs. control granular
El Operator facilita la automatización y escalabilidad. Por defecto, inyecta en todos los namespaces. Si necesitas excluir namespaces específicos o limitar la cobertura a workloads concretos, puedes configurar namespace selectors en el DynaKube — esto da un control granular sin sacrificar la automatización.
Profundidad de telemetría vs. flexibilidad en arquitecturas híbridas
OneAgent ofrece telemetría profunda, incluyendo trazas distribuidas y análisis de dependencias, que no siempre es posible obtener con agentes basados en OpenTelemetry. Sin embargo, en arquitecturas híbridas con múltiples plataformas o servicios serverless, la integración directa puede ser limitada. Para AWS Fargate, Google Cloud Run y entornos AIX/Solaris, Dynatrace soporta inyección universal que funciona sin OneAgent clásico. En estos casos, es aconsejable combinar OneAgent con pipelines de telemetría estándar para mantener flexibilidad y evitar puntos ciegos.
Errores comunes y antipatrones en producción
Seguir desplegando DaemonSets manuales
El error más frecuente en equipos que llevan tiempo con Dynatrace: mantener el despliegue manual heredado sin migrar al Operator. Esto genera deuda operativa, dificulta las actualizaciones y priva al equipo de funcionalidades recientes como el enriquecimiento automático de metadatos Kubernetes o la gestión de versiones coordinada.
No migrar de classicFullStack a cloudNativeFullStack
Muchos entornos siguen en classicFullStack por inercia, asumiendo que la migración es compleja. Lo es, pero el coste de no migrar también es real: reiniciar pods después de cada scale-out de nodos, gestionar manualmente los gaps de cobertura, y exponerse a más privilegios de los necesarios.
Despliegue indiscriminado sin segmentación
Inyectar en todos los namespaces sin criterio genera volumen excesivo de datos, costes elevados y dificultad para identificar alertas relevantes. La recomendación es usar namespace selectors para limitar la monitorización a los workloads que aportan valor real.
Ignorar el impacto en recursos y latencia
Subestimar el consumo de CPU, memoria y red del agente puede derivar en degradación del rendimiento de aplicaciones críticas. Es fundamental dimensionar y probar el impacto en entornos de staging antes de producción, ajustando límites y afinando la configuración.
Falta de integración con pipelines CI/CD
Mantener el despliegue del Operator como un proceso manual o separado del pipeline de infraestructura dificulta las actualizaciones, genera inconsistencias y aumenta el riesgo de fallos en la monitorización. El DynaKube Custom Resource debería vivir en el repositorio de infraestructura como código, igual que cualquier otro recurso de Kubernetes.
Usar Dynatrace solo para ver si el servidor está vivo
En ocasiones, OneAgent se despliega solo para métricas básicas, sin aprovechar Davis AI, correlación automática con Smartscape o alertas basadas en Business Events. Diseña los flujos para alimentar estas funcionalidades desde el principio, incluyendo la correcta etiquetación y configuración de SLOs.
Señales operativas que indican problemas en el despliegue
- Incremento inesperado en la latencia o errores en aplicaciones tras la instalación del agente.
- Alertas recurrentes de saturación de recursos en nodos o pods donde corre OneAgent.
- Pods sin instrumentar después de scale-out de nodos (señal clásica de classicFullStack con race condition).
- Falta de datos o telemetría incompleta en entornos dinámicos con alta rotación de contenedores.
- Dificultad para correlacionar eventos o trazas debido a datos inconsistentes o fragmentados.
- Costes crecientes de licenciamiento o almacenamiento sin un aumento proporcional en el valor operativo.
Cuándo no es recomendable desplegar OneAgent en contenedores
Si el entorno está compuesto principalmente por funciones serverless o contenedores extremadamente efímeros (duración menor a segundos), el modelo tradicional de OneAgent pierde efectividad. En estos casos, es mejor optar por telemetría basada en OpenTelemetry, logs estructurados y métricas exportadas por la aplicación, integrando todo en Dynatrace vía ingestión estándar.
También es desaconsejable en clústeres con recursos muy limitados o donde la aplicación es extremadamente sensible a cualquier sobrecarga, salvo que se realicen pruebas rigurosas y ajustes finos.
Finalmente, si la organización no dispone de procesos maduros de automatización y gestión de configuración, el despliegue puede generar más problemas que beneficios. Conviene invertir primero en plataforma y cultura DevOps, y abordar la instrumentación cuando el suelo esté firme.
Resumen y recomendaciones prácticas para SREs y arquitectos
- Usa cloudNativeFullStack via Dynatrace Operator para la mayoría de entornos Kubernetes productivos. Es el modo por defecto desde Operator 1.0 y resuelve los problemas históricos de race conditions y privilegios excesivos.
- Si vienes de classicFullStack, planifica la migración. Los pods existentes necesitan reiniciarse, así que programa la transición en una ventana de mantenimiento.
- Implementa namespace selectors para controlar el volumen de datos y enfocar la monitorización en lo que aporta valor real.
- El DynaKube Custom Resource debe vivir en tu repositorio de IaC — no lo gestiones manualmente.
- Combina OneAgent con estándares abiertos (OpenTelemetry, logs estructurados) en arquitecturas híbridas o serverless.
- Aprovecha Davis AI, Smartscape y Business Events para maximizar el retorno de la inversión en observabilidad.
En definitiva, el despliegue de Dynatrace OneAgent en contenedores es una pieza clave en la estrategia de observabilidad moderna, pero debe abordarse con criterio arquitectónico y operativo. Comprender los modos actuales, los trade-offs y las señales de alerta permite a los equipos SRE diseñar plataformas robustas, escalables y alineadas con las necesidades reales del negocio.
Referencias y documentación oficial
- Dynatrace Operator — How it works
- cloudNativeFullStack deployment guide
- Migración de classicFullStack a cloudNativeFullStack
- OneAgent platform and capability support matrix
- Calculated service metrics
