Problema

En entornos híbridos (AWS, Azure y on‑prem) la observabilidad tiende a crecer de forma descoordinada. Cada equipo despliega su propio agente, define sus propias etiquetas y crea monitores aislados. Con el tiempo aparecen versiones de agentes desalineadas, configuraciones de logs duplicadas y una gran cantidad de dashboards que no siguen un estándar. El resultado es una base de código de observabilidad que se vuelve difícil de mantener, actualizar y auditar. Cuando se necesita añadir una nueva regla de alerta o actualizar la versión del SDK de APM, la intervención de varios equipos retrasa la entrega y genera errores de configuración.

Causa

  1. Ausencia de fuente única de verdad – No existe un repositorio central donde se definan versiones de agentes, tags o plantillas de monitores. Cada equipo copia y pega fragmentos en sus pipelines.
  2. Falta de automatización en el ciclo de vida – Las actualizaciones de agentes y librerías de APM se hacen manualmente o mediante scripts ad‑hoc, lo que genera versiones mixtas en producción.
  3. Políticas de tagging y monitorización implícitas – Sin una política clara, los nombres de tags varían (env, environment, env_name) y los umbrales de alertas se calibran de forma subjetiva.
  4. Dependencia de equipos propietarios – Los equipos de aplicación controlan su propia instrumentación, lo que dificulta la aplicación de cambios globales como la migración a una nueva versión de OpenTelemetry.
  5. Procesos de onboarding manuales – La incorporación de un nuevo microservicio requiere crear manualmente agentes, dashboards y alertas, lo que aumenta la carga operativa y la probabilidad de errores.

Solución

Una Observability Foundation basada en Terraform permite describir la infraestructura de observabilidad como código, aplicar versiones controladas y validar la consistencia en cada despliegue. La solución se divide en tres capas:

1. Módulos Terraform reutilizables

  • datadog_agent: despliegue del agente con versión bloqueada, configuración de logs y variables de entorno comunes.
  • standard_tags: mapa de tags obligatorios y opcionales que se inyecta a recursos mediante for_each.
  • monitor_templates: plantillas de monitores parametrizables (latencia, error rate, CPU) que usan variables de entorno y etiquetas estándar.
  • dashboard_factory: genera dashboards a partir de un JSON base y permite sobrescribir panels específicos por aplicación.

Los módulos se versionan en un repositorio Git y se publican como Terraform Registry interno. Cada equipo importa la versión que necesita y la CI valida que no haya drift antes de aplicar.

2. Pipeline de CI/CD con políticas de guardia

  • Planificación automática: terraform plan se ejecuta en PR y se compara con el estado remoto.
  • Validación de tags: un script de lint verifica que todos los recursos incluyan standard_tags.
  • Control de versiones de agentes: un job de GitHub Actions o GitLab CI revisa que la variable agent_version coincida con la última versión aprobada en el repositorio de módulos.
  • Aprobación de cambios críticos: monitores de seguridad y alertas de alta prioridad requieren revisión de un Observability Review Board.

3. Gestión de APM / OpenTelemetry

  • SDK BOM (Bill of Materials): se mantiene un archivo apm_bom.yaml que lista la versión de cada SDK (Java, .NET, Node, Go). Los pipelines de compilación consumen este archivo y añaden la dependencia correspondiente.
  • Instrumentación automática: se usan wrappers de OpenTelemetry que detectan el runtime y aplican la configuración estándar (exporters, samplers).
  • Upgrade orchestrado: cuando se aprueba una nueva versión del SDK, se actualiza el BOM, se dispara un pipeline que recompila los servicios y despliega la nueva imagen. El proceso es transparente para los equipos de aplicación porque la única diferencia es la versión del SDK.

Cuándo aplicar esta solución

  • Entornos con múltiples nubes y on‑prem donde los equipos comparten una única plataforma de observabilidad.
  • Más de 50 microservicios o instancias de infraestructura que generan métricas y logs de forma continua.
  • Necesidad de cumplimiento (por ejemplo, auditorías de tags o de retención de logs).
  • Situaciones donde el tiempo de respuesta a incidentes está limitado y la consistencia de alertas es crítica.

No es recomendable cuando:

  • La organización tiene un único equipo responsable de toda la infraestructura y no hay necesidad de delegar.
  • La plataforma de observabilidad es muy nueva y todavía se está evaluando entre varios proveedores; en ese caso, una capa de abstracción ligera (por ejemplo, solo OpenTelemetry Collector) puede ser suficiente.

Código

# Módulo datadog_agent (variables.tf)
variable "agent_version" {
  type    = string
  default = "7.55.0"
}

variable "tags" {
  type = map(string)
  default = {
    env       = "prod"
    team      = "infra"
    service   = "unknown"
  }
}

resource "aws_instance" "example" {
  # ... instancia existente ...

  user_data = <<-EOF
    #!/bin/bash
    DD_AGENT_MAJOR_VERSION=7 DD_API_KEY=${var.datadog_api_key} \
    DD_TAGS="${join(",", [for k, v in var.tags : "${k}:${v}"])}" \
    DD_AGENT_VERSION=${var.agent_version} bash -c "$(curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script.sh)"
  EOF
}

# Linter de tags (tag_lint.sh)
#!/usr/bin/env bash
REQUIRED_TAGS=("env" "team" "service")
for TAG in "${REQUIRED_TAGS[@]}"; do
  if ! grep -q "\"${TAG}\":" *.tf; then
    echo "Missing required tag: ${TAG}"
    exit 1
  fi
done
exit 0

Verificación

  1. Ejecutar terraform plan y confirmar que no aparecen cambios inesperados en los agentes o tags.
  2. En el pipeline, el job tag_lint debe pasar sin errores; de lo contrario, el PR se bloquea.
  3. Verificar en Datadog que todos los hosts reportan la misma versión de agente (agent.version metric).
  4. Probar una alerta de prueba (por ejemplo, CPU > 90% durante 5 min) y confirmar que dispara el canal configurado.
  5. Revisar que los dashboards generados incluyan los filtros de env y team por defecto.

Notas adicionales

  • Evitar hard‑coding de IDs: usa data sources de Terraform para obtener IDs de recursos (por ejemplo, data.datadog_integration_aws).
  • Control de drift: habilita terraform state replace-provider cuando cambies de Datadog a otro proveedor; la capa de módulos mantiene la misma estructura de recursos, lo que reduce el esfuerzo de migración.
  • Separación de responsabilidades: la capa de foundation gestiona la infraestructura de observabilidad; los equipos de aplicación solo añaden sus métricas personalizadas mediante anotaciones o exportadores OpenTelemetry.
  • Gestión de secretos: almacena la API key de Datadog en un vault (AWS Secrets Manager, Azure Key Vault) y pásala al módulo mediante var.datadog_api_key con sensitive = true.
  • Rollback rápido: si una actualización de agente causa problemas, basta con revertir la versión en el módulo y aplicar el plan; el cambio se propaga automáticamente a todas las instancias.

Con este enfoque, la observabilidad deja de ser una colección de scripts aislados y se convierte en una pieza versionada y auditada del ciclo de vida de la infraestructura. La consistencia de tags, la uniformidad de los monitores y la capacidad de actualizar agentes y SDKs con un solo commit son los principales beneficios que reducen la deuda técnica y facilitan una futura migración a otro proveedor sin tocar el código de aplicación.