Introducción a OpenTelemetry
Microsoft está encantado de adoptar OpenTelemetry como futuro de la instrumentación de telemetría. Nuestros clientes han pedido instrumentación neutral del proveedor y estamos encantados de asociarnos con la comunidad de OpenTelemetry para crear API y SDK coherentes en todos los lenguajes.
Microsoft ha colaborado con las partes interesadas del proyecto procedentes de dos proyectos de telemetría de código abierto anteriormente populares, OpenCensus y OpenTracing. Juntos, hemos ayudado a crear un único proyecto, OpenTelemetry. OpenTelemetry incluye contribuciones de todos los principales proveedores de administración del rendimiento de aplicaciones y de la nube (APM) y reside en la base de software de código abierto Cloud Native Computing Foundation (CNCF). Microsoft es miembro Platinum de CNCF.
Conceptos
La telemetría, los datos recopilados para observar la aplicación, se puede dividir en tres tipos o "pilares":
- Seguimiento distribuido
- Métricas
- Registros
Inicialmente, la comunidad de OpenTelemetry se hizo cargo del seguimiento distribuido. Las métricas y los registros siguen en curso. Una historia de observabilidad completa incluye los tres pilares, pero actualmente nuestras ofertas de versión preliminar del exportador basadas en OpenTelemetry de Azure Monitor para .NET, Python y JavaScript solo incluyen el seguimiento distribuido.
Las fuentes siguientes explican los tres pilares:
- Sitio web de la comunidad de OpenTelemetry
- Especificaciones de OpenTelemetry
- Observabilidad de sistemas distribuidos por Cindy Sridharan
En las secciones siguientes, hablaremos de algunos aspectos básicos de la recopilación de telemetría.
Instrumentación de la aplicación
En un nivel básico, la "instrumentación" simplemente permite que una aplicación capture telemetría.
Hay dos métodos para instrumentar la aplicación:
- Instrumentación manual
- Instrumentación automática (autoinstrumentación)
La instrumentación manual consiste en crear código para la API de OpenTelemetry. En el contexto de un usuario, normalmente hace referencia a la instalación de un SDK específico del lenguaje en una aplicación. Los paquetes de instrumentación manual constan de las ofertas en versión preliminar del exportador basado en OpenTelemetry de Azure Monitor para .NET, Python y JavaScript.
Importante
"Manual" no significa que se le pedirá que escriba un código complejo para definir los intervalos de los seguimientos distribuidos (aunque sigue siendo una opción). Un amplio y creciente conjunto de bibliotecas de instrumentación mantenidas por los colaboradores de OpenTelemetry le permitirá capturar sin esfuerzo las señales de telemetría en los marcos y bibliotecas comunes.
Un subconjunto de bibliotecas de instrumentación de OpenTelemetry será compatible con Azure Monitor, con la información proporcionada por los clientes. También estamos trabajando para instrumentar los SDK de servicio de Azure más conocidos mediante OpenTelemetry.
La instrumentación automática permite la recopilación de datos de telemetría mediante configuración sin tocar el código de la aplicación. Aunque es más conveniente, tiende a ser menos configurable. Tampoco está disponible en todos los lenguajes. La oferta de instrumentación automática basada en OpenTelemetry de Azure Monitor consta de la oferta de disponibilidad general basada en OpenTelemetry para Java 3.X. Seguimos invirtiendo en esta oferta con la información proporcionada por los comentarios de los clientes. La comunidad de OpenTelemetry también experimenta con la instrumentación automática de C# y Python, pero Azure Monitor se centra en crear una historia de instrumentación manual sencilla y eficaz a corto plazo.
Envío de datos de telemetría
Hay dos maneras de enviar los datos a Azure Monitor (o a cualquier proveedor):
- Mediante un exportador directo
- Mediante un agente
Un exportador directo envía datos de telemetría en proceso (desde el código de la aplicación) directamente al punto de conexión de ingesta de Azure Monitor. La principal ventaja de este enfoque es la simplicidad de la incorporación.
Todas las ofertas basadas en OpenTelemetry actualmente admitidas de Azure Monitor usan un exportador directo.
Como alternativa, el envío de telemetría a través de un agente proporcionará una ruta para que cualquier lenguaje compatible con OpenTelemetry la envíe a Azure Monitor a través de Open Telemetry Protocol (OTLP). La recepción de OTLP permitirá a los clientes observar las aplicaciones escritas en lenguajes distintos de los lenguajes admitidos.
Nota
Algunos clientes han empezado a usar OpenTelemetry-Collector como alternativa con agente, aunque Microsoft todavía no admite oficialmente un enfoque mediante un agente para la supervisión de aplicaciones. Mientras tanto, la comunidad de código abierto ha contribuido con un exportador de Azure Monitor de OpenTelemetry-Collector que algunos clientes usan para enviar datos a Application Insights de Azure Monitor.
Términos
Para conocer la terminología, consulte el glosario en las especificaciones de OpenTelemetry.
Algunos términos heredados de Application Insights son confusos debido a la convergencia del sector en OpenTelemetry. En la tabla siguiente se destacan estas diferencias. Finalmente, los términos de Application Insights se reemplazarán por términos de OpenTelemetry.
| Application Insights | OpenTelemetry |
|---|---|
| Recopiladores automáticos | Bibliotecas de instrumentación |
| Canal | Exportador |
| Sin código/basado en agente | Instrumentación automática |
| Traces | Registros |
Pasos siguientes
Los siguientes sitios web constan de una guía de cada lenguaje para habilitar y configurar las ofertas basadas en OpenTelemetry de Microsoft. La funcionalidad y las limitaciones disponibles de cada oferta se explican de tal forma que pueda determinar si OpenTelemetry es adecuado para su proyecto.