Skip to main content

Instrumentación vs Recolección

La instrumentación es el proceso de generar los datos de telemetría en tu código. Es como "instalar sensores" en tu aplicación que van a crear los traces, métricas y logs.

Existen dos tipos principales de instrumentación:

  • Automática: Usando bibliotecas que ya instrumentan automáticamente frameworks y bibliotecas comunes. OTel viene creciendo y ganando esta automatización para los lenguajes gradualmente. Hoy solo tenemos disponibles para los lenguajes: .NET, Go, Java, JavaScript, PHP, Python. Consulta https://opentelemetry.io/es/docs/getting-started/ops/ en caso de que quieras iniciar rápido si el lenguaje de tu proyecto ya está automatizado.

  • Manual: Cuando añades código específico para generar telemetría en partes importantes de tu aplicación. En este caso tenemos varias bibliotecas disponibles para varios lenguajes. Consulta https://opentelemetry.io/es/docs/getting-started/dev/ para más información.

La recolección es el proceso de capturar esos datos generados y enviarlos a un destino. Es realizada por el OpenTelemetry Collector que recibirá datos de telemetría de las aplicaciones instrumentadas, procesa esos datos (puede filtrar, transformar, agregar) y exporta a sistemas de observabilidad (como Jaeger, Prometheus, etc).

El Collector funciona como un intermediario central (un Hub) que recibe datos de múltiples fuentes, estandariza el formato y encamina hacia uno o más destinos.

La Instrumentación GENERA los datos (es donde los datos nacen) y la Recolección PROCESA y ENCAMINA esos datos (es cómo los datos viajan).

El Collector es un componente separado de la aplicación. Puede ser un binario independiente, un contenedor que funciona como sidecar, un servicio en el sistema operativo, etc. El Collector fue diseñado para ser un componente independiente y funcionar como un servicio centralizado que puede recibir datos de múltiples aplicaciones en el mismo SO.

Si necesitas algo más ligero e integrado a la aplicación, OTel ofrece el concepto de "exporter" que puede enviar datos directamente a tu sistema de observabilidad. El Exporter no es tan potente como el collector y es mucho más limitado. Lo ideal es siempre apuntar a un collector, pero en algunos casos específicos de arquitectura el uso del exporter puede tener sentido.

Collector como Sidecar vs Collector Centralizado​

Es bueno explicar esto pues probablemente debes estar pensando que debe haber un collector enorme esperando que todo el mundo le mande las señales.

Patrón Sidecar​

Usamos esta arquitectura cuando necesitamos alto rendimiento, seguridad estricta, cada aplicación tiene necesidades específicas de procesamiento y los recursos del cluster no son una limitación.

Pod
├── Contenedor de la Aplicación
└── Contenedor del Collector (sidecar)

Ventajas del Sidecar

  • Aislamiento
    • Cada aplicación tiene su propio collector
    • Los fallos no afectan a otras aplicaciones
    • Más fácil de depurar problemas
  • Rendimiento
    • Comunicación local (dentro del mismo pod)
    • Menor latencia
    • Menos tráfico de red
  • Seguridad
    • Los datos no viajan por la red antes de ser procesados
    • Más fácil de controlar el acceso

Collector Centralizado​

Optamos por esta arquitectura cuando necesitamos:

  • Economizar recursos
  • Aplicaciones similares
  • Configuración estandarizada
  • Simplicidad de mantenimiento y actualización
Cluster Kubernetes
├── Pod Crítico (con sidecar)
├── Pod Normal (sin sidecar)
└── Collector Central

Los cambios afectan a todas las aplicaciones a la vez.

Nada impide que utilicemos las dos cosas y formemos un híbrido. ¿Un collector por nodo? ¿Por namespace? No existe un correcto e incorrecto, depende de muchos factores. Pero si pudiera darte un consejo, ¡sidecar no tiene error!