Instrumentación de aplicaciones con OpenTelemetry y ServicePilot

¿Qué es OpenTelemetry?

OpenTelemetry surgió de la fusión de dos proyectos importantes: OpenTracing, centrado en los rastros distribuidos, y OpenCensus, centrado en las métricas. La fusión permitió crear un estándar abierto único, ampliamente adoptado por el sector.

OpenTelemetry (OTel) es un proyecto de código abierto respaldado por la Cloud Native Computing Foundation (CNCF). Proporciona un conjunto de herramientas, API y SDK que permiten recopilar tres tipos de señales esenciales:

• Las métricas son medidas cuantitativas, como el número de solicitudes, la latencia o la tasa de error.
• Las trazas representan el recorrido de una solicitud a través de los servicios. Cada rastro se compone de una sucesión de intervalos, cada uno de los cuales corresponde a una operación o etapa concreta del procesamiento. Por ejemplo, un rastro relacionado con una solicitud web puede incluir intervalos dedicados a la autenticación, a la consulta de la base de datos o a la generación de la respuesta.
• Los logs son eventos textuales que describen lo que ocurre en la aplicación, junto con su contexto temporal e informativo.

La integración de la observabilidad en las aplicaciones ya no es solo una buena práctica, sino un requisito imprescindible para garantizar su mantenimiento, optimización y mejora continua. Ofrece a los desarrolladores los medios para garantizar aplicaciones fiables y de alto rendimiento, al tiempo que proporciona la información necesaria para tomar decisiones fundamentadas.

¿Por qué se ha vuelto tan popular OpenTelemetry?

El objetivo de OpenTelemetry es sencillo: estandarizar la instrumentación de las aplicaciones y enviar los datos de telemetría a un sistema de observabilidad. El framework destaca por su enfoque verdaderamente independiente de proveedores: ofrece API, SDK y herramientas que no están vinculadas a ningún ecosistema propietario. Gracias a esta neutralidad, las organizaciones evitan el riesgo de dependencia de un único proveedor y conservan la libertad de elegir sus soluciones de observabilidad de back-end.

Interoperabilidad
OTel es compatible con todas las principales herramientas del mercado: ServicePilot, Prometheus, Jaeger, Grafana, etc.

Estandarización
Ya no es necesario utilizar un SDK diferente para cada herramienta de monitorización.

Flexibilidad
Las aplicaciones se pueden instrumentar de forma automática o manual, según las necesidades.

Ecosistema rico
OpenTelemetry ofrece implementaciones específicas de la API y del SDK para varios lenguajes de programación:

• .NET
• C++
• Go
• Java
• JavaScript
• Node.js
• Python
• PHP
• Ruby
• Rust, etc.

OpenTelemetry se está integrando cada vez más de forma nativa en el software moderno. Esta evolución se debe a la creciente necesidad de ofrecer observabilidad lista para usar y sin configuraciones complejas. Los marcos web, las plataformas sin servidor, los orquestadores de contenedores o incluso las bases de datos están empezando a exponer trazas, métricas y registros en formato OpenTelemetry desde el momento de su instalación. Esto significa que los equipos ya no necesitan añadir manualmente bibliotecas de instrumentación: la observabilidad se convierte en un componente estándar, integrado desde el diseño. Esta tendencia seguirá acelerándose, convirtiendo a OpenTelemetry en un auténtico lenguaje universal de telemetría y simplificando aún más la integración con plataformas como ServicePilot.

Los componentes clave de OpenTelemetry

La API define las interfaces que permiten instrumentar el código independientemente del backend utilizado.

Los SDK específicos para cada lenguaje permiten utilizar la API de OpenTelemetry para generar datos de telemetría y exportarlos a un backend. Estos SDK también ofrecen la posibilidad de integrar bibliotecas de instrumentación para los frameworks más habituales.

El OpenTelemetry Collector es un proxy independiente del proveedor capaz de recibir, procesar y exportar datos de telemetría. Admite la recepción de datos de telemetría en múltiples formatos y el envío de datos a uno o varios backends. Permite procesar y filtrar los datos de telemetría antes de su exportación. El uso de un Collector mejora la escalabilidad, permite a los servicios descargar datos rápidamente y puede encargarse de tareas adicionales como reintentos, procesamiento por lotes o cifrado.

OTLP (OpenTelemetry Protocol) es el protocolo nativo para el transporte de datos de telemetría. Admite todas las señales (trazas, métricas, registros, perfiles) en un único formato, con dos modos de transporte: gRPC o HTTP/protobuf. OTLP es el formato recomendado para la comunicación SDK → Collector y Collector → backend.

¿Como instrumentar una aplicación?

Para que un sistema sea observable, debe estar instrumentado: en otras palabras, el código de los componentes del sistema debe generar señales, como trazas, métricas y registros. Con OpenTelemetry, es posible instrumentar el código de dos formas principales:

1. Autoinstrumentación (o zero-code), solución que no requiere modificar el código para algunos lenguajes específicos
2. Instrumentación manual, solución basada en la inserción manual en el código a través de las API y los SDK oficiales para la mayoría de los lenguajes

Las buenas prácticas recomiendan combinar ambas opciones, comenzando por la autoinstrumentación para obtener de inmediato los spans de las llamadas HTTP, las consultas SQL y las llamadas gRPC sin modificar el código. A continuación, se añade la instrumentación manual en las operaciones críticas del negocio (pagos, creación de pedidos, autenticación, etc.) con el fin de obtener spans manuales con atributos de negocio relevantes para el diagnóstico.

Además de la instrumentación de las propias aplicaciones, OpenTelemetry ofrece bibliotecas de instrumentación para numerosos componentes de terceros que publican sus datos en formato OpenTelemetry. Por ejemplo, es posible recopilar trazas de comandos de MySQL Enterprise Server, métricas sobre el uso de Claude Code o datos de telemetría de Workflows Argo. El Registry de OpenTelemetry ofrece una base de datos con función de búsqueda que incluye bibliotecas de instrumentación, componentes de recopilación y otros proyectos útiles del ecosistema de OpenTelemetry.

Las Golden Signals y su uso con OTel & ServicePilot

En el ámbito de la observabilidad, no todas las señales son iguales. Para comprender rápidamente el estado de un sistema, los equipos de SRE y DevOps se basan desde hace tiempo en un concepto fundamental: las Golden Signals. Popularizadas por Google en el marco del SRE, estas cuatro señales clave permiten diagnosticar en pocos segundos el estado de un servicio. Gracias a OpenTelemetry y ServicePilot, es posible no solo recopilar estas señales automáticamente, sino también analizarlas, correlacionarlas y llegar a la causa raíz en un tiempo mínimo.

Las Golden Signals: base indispensable para comprender los servicios

Las Golden Signals son cuatro:

• Latencia: el tiempo necesario para procesar una solicitud
• Tráfico: el volumen de solicitudes recibidas por el servicio
• Errores: la tasa de solicitudes fallidas o incorrectas
• Saturación: el nivel de utilización de los recursos (CPU, memoria, subprocesos…)

Estas señales constituyen la base de cualquier estrategia de observabilidad eficaz. Permiten responder de inmediato a preguntas esenciales:

• ¿El servicio es lento?
• ¿El servicio está sobrecargado?
• ¿El servicio devuelve errores?
• ¿El servicio cuenta con los recursos necesarios para funcionar de manera óptima?

Sin estos indicadores, el análisis se vuelve más largo, más complejo y, a menudo, más aproximado.

Golden Signals visibles en 5 segundos en ServicePilot

Gracias a la integración de OpenTelemetry y ServicePilot, las Golden Signals se recopilan automáticamente y se muestran en cuadros de mando listos para usar. En cuanto un servicio empieza a enviar trazas y métricas, ServicePilot genera una vista general que permite comprender el estado del sistema en menos de cinco segundos:

• Un gráfico de latencia media y p95
• Un gráfico de tráfico con el número de solicitudes
• Un gráfico de errores con la tasa de errores
• Fácil acceso a los datos de las infraestructuras subyacentes

Una tabla agrupa las tres métricas (latencia, tráfico, errores) por aplicación, servicio o URL para resumir toda esta información en un único widget. Esta visibilidad inmediata permite saber al instante si un servicio está en buen estado o si requiere una investigación más profunda.

Desglose: de la visión global a los detalles de una solicitud

Una de las grandes ventajas de ServicePilot es la posibilidad de pasar de lo macro a lo micro con un solo clic. A partir de una Golden Signal anómala (por ejemplo, una latencia elevada), puede:

• Hacer clic en el servicio en cuestión
• Abrir la lista de trazas asociadas
• Identificar las solicitudes más lentas
• Explorar su cascada detallada

Este rápido desglose permite comprender no solo que hay un problema, sino también dónde se encuentra: en una llamada externa, una consulta SQL, un microservicio posterior o una función de negocio específica.

RCA: encontrar la causa raíz gracias a la correlación

Identificar un problema es una cosa. Entender por qué se produce es otra muy distinta. ServicePilot destaca por su capacidad de correlacionar automáticamente los tickets, los registros, las métricas y la infraestructura subyacente.

Ejemplo concreto:

• Se detecta una latencia anómala
• Se abre un ticket por lentitud
• La cascada muestra una llamada SQL especialmente larga
• Los registros correlacionados muestran un error de conexión a la base de datos
• Las métricas de infraestructura muestran una saturación de la CPU en el servidor SQL

En unos pocos clics, ha reconstruido toda la cadena causal.

Las Golden Signals no se refieren únicamente a las aplicaciones. Deben ponerse en perspectiva con el estado de los contenedores, el rendimiento del clúster de Kubernetes, el estado de las bases de datos, los recursos de red o los servicios en la nube utilizados. ServicePilot permite visualizar toda esta cadena en una única interfaz, lo que facilita la Root Cause Analysis y la comprensión global del sistema.

OTel + ServicePilot para una observabilidad simplificada

OpenTelemetry recopila los datos sin procesar. ServicePilot se posiciona como un backend de observabilidad unificado para aprovechar esos datos. La combinación de ambos ofrece una solución de observabilidad completa.

Integración nativa: ServicePilot es compatible de forma nativa con OTLP, lo que simplifica la configuración y la exportación automática de datos.

Correlaciones de señales: los datos se unifican y se presentan de forma clara para realizar la correlación entre las señales (trazas distribuidas, métricas, registros).

Interfaces y funcionalidades: cuadros de mando, alertas, informes en PDF, mapas, cuadros de mando de supervisión, planificación de la capacidad, etc.

Escalabilidad: ServicePilot puede procesar un gran volumen de datos sin necesidad de configuraciones complejas.

Ahorro de tiempo: esto permite centrarse en el análisis y la resolución de incidencias en lugar de perder tiempo configurando y manteniendo cuatro programas adicionales.

La instrumentación es un pilar esencial de la observabilidad moderna. OpenTelemetry ofrece un estándar abierto, flexible y potente para recopilar datos. Al combinarlo con ServicePilot, dispondrá de una plataforma completa para visualizar, analizar y optimizar el rendimiento de sus aplicaciones.

Tanto si es desarrollador, DevOps, ingeniero SRE o administrador de sistemas, la integración de OTel + ServicePilot le permitirá mejorar la fiabilidad y el rendimiento de sus servicios, al tiempo que simplifica su día a día.