Aprender OpenTelemetry

Capítulo 4. La arquitectura de OpenTelemetry

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Todo el mundo sabe que depurar es el doble de difícil que escribir un programa en primer lugar. Así que si eres todo lo inteligente que puedes ser cuando lo escribes, ¿cómo vas a depurarlo?

Brian W. Kernighan y P. J. Plauger¹

OpenTelemetry consta de tres tipos de componentes: instrumentación instalada dentro de las aplicaciones, exportadores para infraestructuras como Kubernetes, y componentes de canalización para enviar toda esta telemetría a un sistema de almacenamiento. Puedes ver cómo se conectan estos componentes en la Figura 4-1.

Este capítulo te ofrece una visión general de alto nivel de todos los componentes que forman OpenTelemetry. Después, nos sumergiremos en la aplicación Demo de OpenTelemetry para ver cómo encajan los componentes.

Aplicación Telemetría

La fuente más importante de telemetría son las aplicaciones. Esto significa que OpenTelemetry debe instalarse en todas las aplicaciones para que funcione correctamente. Independientemente de si lo instalas automáticamente utilizando un agente o manualmente escribiendo código, los componentes que instalarás son los mismos. La Figura 4-2 muestra cómo encajan entre sí.

Figura 4-1. La relación entre OpenTelemetry y los componentes de análisis

Figura 4-2. Arquitectura de la aplicación OpenTelemetry

Instrumentación de la Biblioteca

La telemetría más crítica procede de bibliotecas OSS como frameworks, clientes HTTP y RPC, y clientes de bases de datos. Estas bibliotecas realizan el trabajo pesado en la mayoría de las aplicaciones, y a menudo la telemetría de estas bibliotecas es suficiente para cubrir casi todo el trabajo que realiza una aplicación.

Actualmente, la mayoría de las bibliotecas OSS no están instrumentadas de forma nativa con OpenTelemetry. Esto significa que la instrumentación para estas bibliotecas debe instalarse por separado. OpenTelemetry proporciona bibliotecas de instrumentación para muchas bibliotecas OSS populares.

La API OpenTelemetry

Aunque la instrumentación de la biblioteca es muy útil, inevitablemente querrás instrumentar piezas críticas del código de la aplicación y de la lógica empresarial. Para ello, utilizas la API OpenTelemetry. La instrumentación de la biblioteca que instales también se escribe con esta API, así que no hay ninguna diferencia fundamental entre la instrumentación de la aplicación y la instrumentación de la biblioteca.

De hecho, la API de OpenTelemetry tiene una característica especial: es segura de llamar incluso cuando OpenTelemetry no está instalada en una aplicación. Esto significa que las bibliotecas OSS pueden incluir instrumentación de OpenTelemetry que se activará automáticamente cuando se utilice OpenTelemetry, y que actuará como un no-op de coste cero cuando la biblioteca se instale en aplicaciones que no utilicen OpenTelemetry. Para más información sobre cómo instrumentar bibliotecas OSS, consulta el Capítulo 6.

El SDK de OpenTelemetry

En para que se procesen realmente las llamadas a la API de OpenTelemetry enviadas desde bibliotecas y código de aplicación, debes instalar el cliente de OpenTelemetry. Nos referimos a este cliente como el SDK de OpenTelemetry. El SDK es un marco de complementos que consta de algoritmos de muestreo, ganchos de ciclo de vida y exportadores que pueden configurarse mediante variables de entorno o un archivo de configuración YAML.

¡La instrumentación es fundamental!

Cuando piensas en instalar OpenTelemetry en tu aplicación, puede ser fácil pensar únicamente en instalar sólo el SDK. Es importante recordar que también necesitas instrumentación para todas tus bibliotecas importantes. Como parte de la instalación, asegúrate de auditar tu aplicación y confirmar que la instrumentación necesaria de las bibliotecas está disponible y se ha instalado correctamente.

En el Capítulo 5, profundizaremos en las entrañas de estos componentes de la aplicación y te guiaremos a través de una instalación satisfactoria. Por ahora, basta con saber que estos componentes existen.

Infraestructura Telemetría

Las aplicaciones se ejecutan en un entorno. En la computación en nube, ese entorno consiste en el host en el que se ejecuta la aplicación y la plataforma utilizada para gestionar las instancias de la aplicación, junto con otros diversos servicios de red y bases de datos operados por tu proveedor de la nube. La salud de la infraestructura es increíblemente importante, y los grandes sistemas distribuidos tienen mucha infraestructura. La telemetría de alta calidad de estos servicios es fundamental.

OpenTelemetry se está incorporando poco a poco a Kubernetes y otros servicios en la nube. Pero incluso sin OpenTelemetry, la mayoría de los servicios de infraestructura producen algún tipo de telemetría útil. OpenTelemetry viene con una serie de componentes que pueden utilizarse para recopilar estos datos existentes y añadirlos al canal de telemetría procedente de las aplicaciones. (Para más información, consulta el Capítulo 7.)

Tuberías de telemetría

La telemetría recogida de las aplicaciones y la infraestructura debe enviarse a una herramienta de observabilidad para su almacenamiento y análisis. Esto puede convertirse en un problema difícil en sí mismo. La cantidad de telemetría de un gran sistema distribuido sometido a una gran carga puede ser enorme. Como resultado, los problemas de red como la salida, el equilibrio de carga y la contrapresión pueden ser significativos.

Además, los grandes sistemas suelen ser sistemas antiguos. Esto significa que pueden tener un mosaico de herramientas de observabilidad, tener diversos requisitos de tratamiento de datos y, en general, requerir que la telemetría se procese mucho y se desvíe a varios lugares. La topología resultante puede ser muy complicada.

Para gestionar esto, OpenTelemetry tiene dos componentes principales: El Protocolo de Telemetría Abierta (OTLP), del que se habla en el Capítulo 3, y el Colector, que se trata en detalle en el Capítulo 8.

Qué no incluye OpenTelemetry

Lo que OpenTelemetry no incluye es casi tan crítico como lo que sí incluye. El almacenamiento a largo plazo, el análisis, las interfaces gráficas y otros componentes frontales no están incluidos y nunca lo estarán.

¿Por qué? Estandarización. Aunque es posible llegar a un lenguaje estable y universal para describir las operaciones informáticas, la parte de análisis de la observabilidad estará siempre en evolución. El objetivo de OpenTelemetry es trabajar con todas las herramientas de análisis y animar a la gente a construir muchas más herramientas avanzadas y novedosas en el futuro. Como resultado, el proyecto OpenTelemetry nunca se ampliará para incluir algún tipo de backend de observabilidad "oficial" que se trataría como especial o diferente de todos los demás sistemas de observabilidad del mundo. Esta separación de intereses -la telemetría normalizada que alimenta un panorama de herramientas de análisis en constante evolución- es fundamental para la forma en que el proyecto OpenTelemetry ve el mundo.

Demostración práctica de OpenTelemetry

Hasta este punto, nuestra discusión sobre OpenTelemetry ha sido muy teórica. Para entender realmente cómo encajan las cosas en la práctica, tenemos que ver una aplicación real y algo de código real.

En primer lugar, aquí tienes un rápido resumen de lo que has aprendido hasta ahora:

• OpenTelemetry proporciona API, SDK y un ecosistema de herramientas para crear, recopilar, transformar y garantizar la calidad de los datos telemétricos.

• OpenTelemetry garantiza que los datos telemétricos sean portátiles e interoperables.

• A diferencia del antiguo modelo de "tres pilares", OpenTelemetry trenza el rastreo, las métricas, el registro y los recursos en un único modelo de datos. Esto crea datos regularizados que están altamente correlacionados y son de una calidad uniformemente alta.

• Las convenciones semánticas de OpenTelemetry garantizan que la telemetría de distintas bibliotecas sea coherente y de calidad uniforme.

• OpenTelemetry es sólo telemetría. Está diseñado para enviar datos a diversas herramientas de almacenamiento y análisis y permitir la creación de nuevas herramientas de análisis más avanzadas.

Está claro que OpenTelemetry es muchas cosas y tiene muchas partes móviles. El objetivo de este libro no es simplemente enseñarte a crear una métrica o iniciar un span, sino ayudarte a entender OpenTelemetry de forma holística. La mejor forma de hacerlo es verlo en acción en una aplicación real.

Afortunadamente, el proyecto OpenTelemetry mantiene una sólida aplicación de demostración específica para este fin. Durante el resto del capítulo, vamos a recorrer un ejemplo práctico de la arquitectura de OpenTelemetry, tal y como se implementa en esta demo, Astronomy Shop. Cubriremos lo siguiente:

• Instalar y ejecutar la demo

• Explorar la arquitectura de la aplicación y su diseño

• Utilizar los datos de OpenTelemetry para responder a preguntas sobre la demo

Puedes seguir la demostración sólo con el libro, pero te recomendamos encarecidamente que la pongas en marcha tú mismo. Este enfoque práctico aclarará muchas dudas.

Ejecutar la demostración

Para esta sección, necesitarás un ordenador portátil o de sobremesa reciente, idealmente con 16 GB o más de RAM. También necesitarás unos 20 GB de espacio en disco para todas las imágenes contenedoras. Estas instrucciones asumen que tienes Docker y Git disponibles y configurados.

Mantente al día

Estas instrucciones se escribieron a finales de 2023 para la Demo de OpenTelemetry v1.6.0 utilizando un MacBook Pro de 2022 con un Apple Silicon M2 Max y 32 GB de RAM. Busca en la Documentación de la Demo de OpenTelemetry instrucciones de instalación actualizadas para versiones más recientes de la demo o para aprender a instalarla en Kubernetes.

Para instalar:

1. Navega hasta el repositorio GitHub de la demo y clónalo en tu ordenador.

2. En un terminal, navega hasta el directorio raíz del repositorio que acabas de clonar y ejecuta make start.

Si esto se ha realizado correctamente, al cabo de varios minutos deberías ver la siguiente salida en tu terminal:

OpenTelemetry Demo is running.
Go to http://localhost:8080 for the demo UI.
Go to http://localhost:8080/jaeger/ui for the Jaeger UI.
Go to http://localhost:8080/grafana/ for the Grafana UI.
Go to http://localhost:8080/loadgen/ for the Load Generator UI.
Go to http://localhost:8080/feature/ for the Feature Flag UI.

En un navegador web, navega hasta localhost:8080, y deberías ver una página web parecida a la Figura 4-3.

Figura 4-3. Página de inicio de la Demo OpenTelemetry

Si ves esto, ¡estás listo! Si encuentras dificultades, consulta las instrucciones enlazadas en la nota "Mantente al día" para obtener más información y ayuda para solucionar problemas en .

Arquitectura y Diseño

Astronomy Shop es una aplicación de comercio electrónico basada en microservicios y compuesta por 14 servicios independientes, como se muestra en la Figura 4-4.

La Tienda de Astronomía está pensada para permitir a los desarrolladores, operadores y otros usuarios finales la posibilidad de explorar una implementación de "producción-lite" de un proyecto. Para crear una demostración útil con ejemplos de observabilidad interesantes, se incluyeron algunas cosas que no verías necesariamente en una aplicación de producción "real", como código diseñado para simular fallos. La mayoría de las aplicaciones del mundo real, incluso las nativas de la nube, son bastante más homogéneas que la demo en cuanto a lenguaje y tiempo de ejecución, y una aplicación "real" suele trabajar con más capas de datos y motores de almacenamiento que la demo.

Figura 4-4. El servicio OpenTelemetry Demo

Podemos dividir la arquitectura general en dos partes básicas: las cuestiones de observabilidad y las cuestiones de aplicación. Las preocupaciones de aplicación son los servicios que gestionan la lógica empresarial y los requisitos funcionales, como el servicio de correo electrónico (que se encarga de enviar correos electrónicos transaccionales a los clientes) y el servicio de divisas (responsable de convertir entre todos los valores de divisas admitidos en la aplicación).

Las preocupaciones de observabilidad son responsables de alguna parte de la observabilidad general de la aplicación, recogiendo y transformando datos telemétricos, almacenándolos y consultándolos, o visualizando esas consultas. Entre ellos están el generador de carga, el Colector de Telemetría Abierto, Grafana, Prometheus, Jaeger y OpenSearch. El generador de carga es también una preocupación de observabilidad, ya que pone una cantidad constante de carga en la aplicación de demostración para simular cómo sería un entorno del "mundo real".

Aunque la demo está escrita en diversos lenguajes de programación, sus servicios se comunican entre sí utilizando un marco estándar, en este caso gRPC (o JSON Protobuffers sobre HTTP). Esto es intencionado, por dos razones. En primer lugar, muchas organizaciones (incluso las que no tienen entornos políglotas) se estandarizan en torno a un único marco RPC, como gRPC. En segundo lugar, OpenTelemetry es compatible con gRPC e incluye instrumentación útil para sus bibliotecas desde el primer momento. Esto significa que obtienes una gran cantidad de datos de telemetría "gratis" sólo con utilizando OpenTelemetry y gRPC.

Gestionar el rendimiento de las aplicaciones con OpenTelemetry

Para ver lo que puede hacer OpenTelemetry, vamos a crear un problema interesante para que lo descubras. Utiliza tu navegador para ir a la interfaz de usuario de los indicadores de funciones (http://localhost:8080/feature) y activa los indicadores cartServiceFailure y adServiceFailure haciendo clic en Editar junto a cada uno de ellos, marcando la casilla Activado y guardando los cambios. Probablemente querrás dejar que la demostración se ejecute durante unos minutos antes y después de activar estos indicadores de función, para ver cómo es el rendimiento antes y después de activarlos. La Figura 4-5 muestra lo que deberías ver en la interfaz de usuario del indicador de función después de realizar esta tarea.

Figura 4-5. Activación de las banderas de características seleccionadas en la IU de Bandera de Características

Tras esperar unos minutos, puedes empezar a explorar los datos. Grafana (http://localhost:8080/grafana/) dispone de varios paneles preconstruidos; uno de los más interesantes es el Panel de Demostración de Spanmetrics de . Este panel te ofrece una vista "estilo APM" de los servicios, mostrando la latencia, la tasa de error y el rendimiento de cada ruta en todos los servicios de la aplicación. Lo interesante es que este panel no se genera a partir de métricas, sino a partir de datos de rastreo, utilizando el conector spanmetrics del Colector de OpenTelemetry. Si filtras este panel al Servicio de anuncios y al Servicio de carritos(Figura 4-6), verás que tienen una tasa de error ligeramente elevada, pero también verás dónde se encuentra exactamente esa tasa de error.

Figura 4-6. El panel de Spanmetrics en Grafana

Puedes ver en el gráfico de la parte inferior derecha de la Figura 4-6 que el nombre del tramo que muestra la mayor tasa de error es oteldemo.AdService/GetAds. Es un punto de partida útil para una investigación.

¿Cómo averiguarías normalmente cuál es la causa de este problema? Mucha gente recurriría a los registros. Pero como OpenTelemetry proporciona trazas ricas y de alto contexto, puedes tomar los dos datos que tienes -la presencia y la ubicación de los errores- y utilizarlos para buscar trazas que coincidan.

En Grafana, puedes explorar los datos de rastreo yendo al elemento Explorar del menú. Una vez allí, selecciona Jaeger en el menú desplegable de la parte superior (por defecto debería decir Prometheus) y, a continuación, cambia a una consulta de Búsqueda. Introduce la información que conozcas, como se ve en la Figura 4-7, y luego haz clic en Ejecutar consulta. Verás todas las peticiones que incluyen errores para esa ruta concreta. La inspección de estas trazas revela que un pequeño porcentaje de las transacciones están fallando con un error gRPC. Podrías tomar esa información y seguir investigando, comparándola con la utilización de memoria o CPU en el host o en el contenedor .

Figura 4-7. Exploración de los datos de rastreo de Jaeger en Grafana

Aunque este error aleatorio puede no ser terriblemente interesante, lo interesante es que la instrumentación necesaria para obtener este resultado era gratuita, por así decirlo. Este es un ejemplo de instrumentación automática (o instrumentación de código cero), en la que un agente o una biblioteca añade código de instrumentación sin que tengas que escribir nada para habilitarlo. Si miras el archivo Dockerfile del Servicio de anuncios, verás que descarga un agente como parte de la compilación, lo copia en el contenedor y lo ejecuta junto con el servicio. Esto significa que, al iniciarse, se añade la instrumentación necesaria sin ningún trabajo por parte del desarrollador.

Existe un patrón similar en el Servicio de Carro y, de nuevo, no tienes que escribir la instrumentación necesaria para descubrirlo. En .NET, OpenTelemetry está integrado en el propio tiempo de ejecución: todo lo que tienes que hacer es activarlo. Compruébalo tú mismo: abre /src/cartservice/src/Program.cs en un editor y mira la línea 52. Hemos añadido algunas notas al código siguiente para ayudarte a entender lo que ocurre:

builder.Services.AddOpenTelemetry() 
    .ConfigureResource(appResourceBuilder)
    .WithTracing(tracerBuilder => tracerBuilder
        .AddRedisInstrumentation(
            options => options.SetVerboseDatabaseStatements = true)
        .AddAspNetCoreInstrumentation()
        .AddGrpcClientInstrumentation() 
        .AddHttpClientInstrumentation()
        .AddOtlpExporter()) 
    .WithMetrics(meterBuilder => meterBuilder 
        .AddProcessInstrumentation()
        .AddRuntimeInstrumentation()
        .AddAspNetCoreInstrumentation()

Esto añade las bibliotecas de OpenTelemetry al contenedor de inyección de dependencias presente en las aplicaciones .NET.

Esto permite la instrumentación integrada para clientes gRPC.

Aquí, activamos la exportación OTLP para enviar los datos a un Colector OpenTelemetry.

También obtenemos métricas fuera del proceso, como la memoria y la recogida de basura, métricas del servidor HTTP, etc.

En ambos casos, OpenTelemetry proporciona una valiosa telemetría a nivel de framework con muy poco esfuerzo por tu parte. En el Capítulo 5 entraremos en más detalles sobre la disponibilidad de este tipo de instrumentación automática en otros lenguajes: ¡no es sólo para .NET y Java!

Encontrar agujas en pajares

Instrumentación del marco te da mucho, como demostramos en la última sección. Pero puedes conseguir mucho más añadiendo más instrumentación. Los Capítulos 5 y 6 tratan esto con más detalle, pero vamos a darte una idea de la diferencia. La Figura 4-8 muestra la diferencia entre la instrumentación del framework sola y una combinación de framework e instrumentación personalizada en una transacción entre dos servicios de la demo.

Figura 4-8. Dos cascadas de trazas de la misma transacción. La primera traza (arriba) muestra sólo los tramos cliente; la segunda incluye los tramos cliente, servidor y personalizado.

Vamos a investigar un problema que sólo se puede encontrar con instrumentación personalizada. Si vuelves a la interfaz de usuario del indicador de funciones (http://localhost:8080/feature) y activas productCatalogFailure, introducirás un nuevo problema en la demostración. Al cabo de unos minutos, observarás que la tasa de errores de varios servicios empieza a aumentar, especialmente en el frontend(Figura 4-9).

Esto es emblemático de un modo de fallo bastante común en las aplicaciones distribuidas: lo que falla no es necesariamente lo que tiene un problema. Si se tratara de una aplicación real, probablemente estarían llamando a tu equipo de frontend por esa tasa de error relativamente alta. Tu primer puerto de escala podría ser una comprobación básica de la salud del frontend, que está disponible en la demo como métrica httpcheck.status. Sin embargo, si lo consultas en Grafana, verás que todo va bien(Figura 4-10).

Figura 4-9. El panel de Spanmetrics muestra las tasas de error durante un fallo del servicio de catálogo de productos

Figura 4-10. Consulta de la métrica httpcheck.status en Grafana

Esto te indica que el servidor web no tiene problemas. ¿Quizá sea el servicio frontend? Si sólo tuvieras métricas y registros con los que trabajar, tendrías que empezar a buscar en las sentencias de registro, intentando identificar los errores. Sin embargo, como dispones de métricas span, puedes buscar los errores por ruta(Figura 4-11). Filtrando sólo los tramos del frontend y restringiéndolo sólo a errores, puedes sumar esos errores en todas las llamadas que el frontend está haciendo al backend.

Aquí hay algo interesante: ¡el pico de errores procede del servicio de catálogo de productos! Si eres un desarrollador frontend, puedes respirar tranquilo; probablemente no sea culpa tuya.

Figura 4-11. Filtrar métricas span para encontrar errores por ruta

Tu siguiente paso en la resolución de problemas debe ser investigar estos errores concretos. Como antes, puedes buscar tramos que coincidan con el fallo en Grafana o en Jaeger directamente.

Si exploras todas las trazas que llaman a oteldemo.ProductCatalogService/GetProduct, te darás cuenta de que todos los errores tienen algo en común: sólo se producen cuando el atributo app.product.id es un valor específico. Sólo con Jaeger y Grafana, este hecho puede ser algo difícil de descubrir; tienes que comparar muchas trazas entre sí, ya sea manualmente o utilizando comparaciones de trazas individuales. Herramientas de análisis más avanzadas -tanto de código abierto como comerciales- admiten el análisis agregado de tramos y la detección de correlaciones. Utilizándolas, podrías ver más fácilmente el valor específico que provoca el error, reduciendo el tiempo necesario para identificar y remediar el problema.

Ahora bien, la instrumentación automática no puede conocer la lógica y los metadatos específicos del dominio o del negocio que importan a tu servicio. Tienes que añadirlos tú mismo ampliando la instrumentación. En este caso, el catálogo de productos utiliza la instrumentación gRPC. Querrás adjuntar un contexto blando útil a los tramos que genera, como el ID concreto del producto que se solicita. Puedes ver dónde se establece este atributo en las líneas 198 a 202 del código fuente(/src/productcatalogservice/main.go):

func (p *productCatalog) GetProduct(ctx context.Context, req *pb.GetProductRequest) 
          (*pb.Product, error) { 
	span := trace.SpanFromContext(ctx) 
	span.SetAttributes(
		attribute.String("app.product.id", req.Id), 
	)

En Go, el contexto OpenTelemetry se lleva en el Contexto.

Para modificar un tramo existente o iniciar uno nuevo, necesitas obtener el tramo actual del Contexto.

Como OpenTelemetry es semántico, necesitas tipar fuertemente los atributos y sus valores.

Hay más en la demostración de lo que hemos cubierto aquí, incluidas las solicitudes a la base de datos, el trabajo asíncrono a través de Kafka y el monitoreo de la infraestructura. Te convendría leer los servicios en los idiomas con los que estés más familiarizado para hacerte una idea de cómo puedes utilizar OpenTelemetry en la práctica y explorar los datos que emite. En el momento de escribir esto, la compatibilidad con todas las funciones de OpenTelemetry en la demo es algo irregular. El rastreo funciona bien en todas partes, y las métricas funcionan en aproximadamente la mitad de los servicios. El soporte de registro se ofrece en un puñado de servicios ahora mismo, pero para cuando leas esto, debería estar más extendido.

Pipelines de observabilidad en la Demo

La última cosa a destacar de la demo es cómo recopila los datos. Cuando es posible, la demostración prefiere enviar los datos de un proceso a una instancia del Recopilador de Telemetría Abierta. El filtrado, la agrupación por lotes y la creación de vistas métricas se realizan en el Recopilador y no en el propio proceso.

Esto se hace por dos razones. En primer lugar, es una buena idea sacar la telemetría de tu servicio lo antes posible. Crear telemetría no es gratis; hay cierta sobrecarga. Cuanto más procesamiento hagas a nivel de aplicación, más sobrecarga crearás. Esto puede estar bien cuando las cosas funcionan bien, pero los patrones de carga inesperados (como los que ocurren durante un incidente) pueden tener resultados inesperados en el perfil de rendimiento de un servicio. Si tu aplicación se bloquea antes de que puedas exportar (o raspar) los datos, perderás esa información. Dicho esto, también es posible crear tanta telemetría que pueda saturar los enlaces de la red local y causar problemas de rendimiento en una capa diferente de tu sistema. Aquí no hay una regla absoluta: cada uno tendrá circunstancias diferentes. Lo mejor que puedes hacer es asegurarte de que habilitas una buena metamonitorización de tu infraestructura de OpenTelemetry. (Puedes ver un ejemplo de ello en el panel Colector incluido en la demo). Hay un debate mucho más exhaustivo sobre los conductos de observabilidad en Capítulo 8.

El nuevo modelo de observabilidad

Ahora que ya has visto una aplicación que utiliza OpenTelemetry, vamos a repasar cómo encaja todo lo que hemos hablado hasta ahora. El resto de este libro se centrará en aspectos más específicos. Puedes pensar en esta sección como el "final del principio".

En el Capítulo 1 hablamos de las "tres pestañas del navegador de la observabilidad", pero merece la pena revisar el concepto con más detalle. La gente utiliza las herramientas de observabilidad más por necesidad que por otra cosa. Aunque está bien filosofar sobre las estrategias de modelado de datos o la asignación de sistemas a señales de telemetría, normalmente no tienen un gran impacto en tu trabajo diario real. Si lo piensas así, entonces tiene sentido por qué la mayoría de las herramientas están integradas verticalmente. Están integradas porque hacerlo es el conjunto de compensaciones más rentable para las personas que las construyen.

Tomemos un ejemplo concreto en torno a las métricas de . Si estás creando una herramienta de análisis y almacenamiento de métricas, probablemente querrás crear algunas eficiencias en tu sistema, especialmente para las cosas que aparecen con frecuencia. Puedes hacerlo con estrategias de agrupación, desagregación y compactación. Para ello, sin embargo, es necesario que controles la instrumentación y el conducto de recogida: tienes que asegurarte de que añades los atributos adecuados a los datos adecuados. De esto se derivan otras eficiencias: por ejemplo, podrías reducir la sobrecarga del proceso de generación de métricas trasladando la generación de atributos a un proceso externo, formatos de cable sin estado, etc.

Sin embargo, mucho de eso se va por la ventana una vez que estás tratando con un conducto de datos que ya no controlas. Por eso OpenTelemetry es tan importante en el ámbito de la observabilidad: rompe este modelo fundamental. El resultado es un nuevo modelo de herramientas de observabilidad que abre la puerta a una innovación significativa.

En el modelo de la Figura 4-12, la "nueva" forma de hacer las cosas se construye sobre una base de instrumentación unificada y universal a través de OpenTelemetry. Combina la telemetría de todas tus fuentes: código nuevo, código heredado, instrumentación existente y datos empresariales de sistemas de registro y otras fuentes importantes. A continuación, estos datos se envían a (al menos) un almacén de datos a través de OTLP.

OpenTelemetry actúa como un conducto universal para los datos de telemetría, permitiéndote procesar y enviar flujos de telemetría en función de cualquier número de factores, como el valor de los datos para tu negocio o el caso de uso que te gustaría habilitar con ellos. Es un elemento fundamental para lo que pueda venir después.

Figura 4-12. El nuevo modelo de herramientas de observabilidad

Las futuras plataformas de observabilidad ofrecerán funciones como API de consulta universales, que te permitirán obtener sin problemas datos telemétricos de diversos almacenes de datos. En lugar de estar encerrado en un único lenguaje de consulta, podrás utilizar el lenguaje natural -con ayuda de herramientas de IA- para encontrar fácilmente lo que buscas. En lugar de estar restringido a grandes plataformas omnicanal, podrás seleccionar entre una amplia gama de herramientas de análisis específicas diseñadas para resolver problemas concretos, gracias a la portabilidad de datos que ofrece OpenTelemetry.

OpenTelemetry no va a resolver estos problemas por sí sola, pero es una parte fundamental de la solución. En cierto modo, está más diseñado para este futuro de datos altamente contextuales y herramientas capaces de comprenderlos de lo que lo están las herramientas actuales.

Puede que hayas sentido la disonancia entre la "vieja" y la "nueva" forma de hacer las cosas en la sección anterior. Por mucho que hayamos hablado (y seguiremos hablando) de métricas y registros, muchos de los flujos de trabajo de demostración se construyen en torno al rastreo. Esto se debe en parte a que las herramientas que tenemos, como Prometheus y Jaeger, simplemente no admiten el tipo de flujos de trabajo de alta cardinalidad y altamente contextuales que proporciona OpenTelemetry. Todos los componentes de OpenTelemetry están diseñados para trabajar juntos y pueden ampliarse para nivelar tus datos telemétricos existentes sin necesidad de reinstrumentación. Sin embargo, para obtener realmente el máximo valor de esto, tus herramientas también tienen que soportar los conceptos de datos de alta cardinalidad, correlación a través de contextos duros y blandos, y telemetría unificada.

En el momento de escribir esto, hay excelentes indicios de progreso en esa dirección. En los últimos dos años se ha lanzado una serie de nuevas herramientas de observabilidad, muchas de las cuales se basan exclusivamente en OpenTelemetry para la instrumentación. Estas herramientas, construidas sobre almacenes de columnas de código abierto, se adaptan bien al tipo de datos telemétricos altamente contextuales que proporciona OpenTelemetry. Las grandes organizaciones también están adoptando OpenTelemetry, entre ellas Microsoft y Amazon Web Services, que han anunciado recientemente un soporte de primera clase para OpenTelemetry (para Microsoft como parte de Azure Monitor, y para Amazon como una experiencia APM potenciada por OpenTelemetry para aplicaciones EKS). Las herramientas no comerciales también están aumentando su compatibilidad con OpenTelemetry, con proyectos como OpenSearch y ClickHouse, cada vez más populares para , que almacenan datos de OpenTelemetry.

Conclusión

Comprender los componentes básicos de OpenTelemetry y ver cómo encajan en una aplicación real es tu primer paso real en la práctica de OpenTelemetry. Ahora que ya te has mojado los pies, es hora de sumergirse en los detalles.

El resto del libro está dedicado a los detalles de cómo funciona OpenTelemetry y a lo que necesitas saber para instrumentar con éxito tus aplicaciones, bibliotecas e infraestructura para la observabilidad. También daremos consejos prácticos sobre cómo diseñar canalizaciones de telemetría y desplegar la observabilidad en una organización, basándonos en estudios de casos de usuarios existentes. Después de cada inmersión, incluiremos una lista de comprobación que puedes seguir para asegurarte de que tu despliegue de OpenTelemetry sea un éxito.

¹ Brian W. Kernighan y P. J. Plauger, The Elements of Programming Style, 2ª ed. (Nueva York: McGraw-Hill, 1978).