Capítulo 1. El estado de la observabilidad moderna
Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com
La Historia no es el pasado, sino un mapa del pasado, trazado desde un punto de vista particular, para que sea útil al viajero moderno.
Henry Glassie, historiador estadounidense1
Éste es un libro sobre los difíciles problemas inherentes a los sistemas informáticos distribuidos a gran escala, y sobre cómo aplicar OpenTelemetry para ayudar a resolver esos problemas.
La ingeniería de software moderna está obsesionada con la experiencia del usuario final, y los usuarios finales exigen un rendimiento rapidísimo. Las encuestas demuestran que los usuarios abandonan los sitios de comercio electrónico que tardan más de dos segundos en cargarse. Probablemente hayas pasado bastante tiempo intentando optimizar y depurar los problemas de rendimiento de las aplicaciones, y si eres como nosotros, te has sentido frustrado por lo poco elegante e ineficaz que puede ser este proceso. O no hay datos suficientes o hay demasiados, y los que hay pueden estar plagados de incoherencias o mediciones poco claras.
Los ingenieros también se enfrentan a estrictos requisitos de tiempo de actividad. Eso significa identificar y mitigar cualquier problema antes de que provoque un colapso, no esperar a que falle el sistema. Y significa pasar rápidamente del triaje a la mitigación. Para ello, necesitas datos.
Pero no necesitas cualquier dato; necesitas datos correlacionados: datosque ya estén organizados, listos para ser analizados por un sistema informático. Como verás, los datos con ese nivel de organización no han estado fácilmente disponibles. De hecho, a medida que los sistemas se han ampliado y se han vuelto más heterogéneos, encontrar los datos que necesitas para analizar un problema se ha vuelto aún más difícil. Si antes era como buscar una aguja en un pajar, ahora es más como buscar una aguja en un montón de agujas.
OpenTelemetry resuelve este problema. Al convertir los registros, métricas y trazas individuales en un gráfico de información coherente y unificado, OpenTelemetry sienta las bases para la próxima generación de herramientas de observabilidad. Y como la industria del software ya está adoptando ampliamente OpenTelemetry, esa próxima generación de herramientas se está construyendo mientras escribimos esto.
Los tiempos están cambiando
La tecnología llega en oleadas. Mientras escribimos esto en 2024, el campo de la observabilidad está viviendo su primer tsunami real en al menos 30 años. ¡Has elegido un buen momento para coger este libro y adquirir una nueva perspectiva!
La llegada de la computación en nube y de los sistemas de aplicaciones nativos de la nube ha provocado cambios sísmicos en la práctica de crear y utilizar sistemas de software complejos. Lo que no ha cambiado, sin embargo, es que el software se ejecuta en ordenadores, y necesitas entender lo que hacen esos ordenadores para entender tu software. Por mucho que la nube haya intentado abstraer las unidades fundamentales de la informática, nuestros unos y ceros siguen utilizando bits y bytes.
Tanto si ejecutas un programa en un clúster Kubernetes multirregión como en un ordenador portátil, te encontrarás haciéndote las mismas preguntas:
- "¿Por qué es lento?"
- "¿Qué está utilizando tanta RAM?"
- "¿Cuándo empezó este problema?"
- "¿Dónde está la causa raíz?"
- "¿Cómo lo arreglo?"
El astrónomo y divulgador científico Carl Sagan dijo: "Hay que conocer el pasado para comprender el presente".2 Sin duda, eso se aplica aquí: para ver por qué es tan importante un nuevo enfoque de la observabilidad, primero tienes que estar familiarizado con la arquitectura tradicional de la observabilidad y sus limitaciones.
¡Esto puede parecer una recapitulación de información rudimentaria! Pero el lío de la observabilidad lleva existiendo tanto tiempo que la mayoría de nosotros hemos desarrollado un buen montón de ideas preconcebidas. Así que, aunque seas un experto -sobre todo si eres un experto-, es importante tener una perspectiva fresca. Empecemos este viaje definiendo varios términos clave que utilizaremos a lo largo de este libro.
Observabilidad: Términos clave que debes conocer
En primer lugar, ¿qué es observar la observabilidad? A efectos de este libro, estamos observando sistemas distribuidos. Unsistema distribuido es un sistema cuyos componentes se encuentran en distintos ordenadores conectados en red que se comunican y coordinan sus acciones pasándose mensajes unos a otros.3 Hay muchos tipos de sistemas informáticos, pero éstos son en los que nos vamos a centrar.
¿Qué se considera distribuido?
Los sistemas distribuidos no son sólo aplicaciones que se ejecutan en la nube, microservicios o aplicaciones Kubernetes. Los macroservicios o "monolitos" que utilizan una arquitectura orientada a servicios, las aplicaciones cliente que se comunican con un backend, y las aplicaciones móviles y web son todas en cierto modo distribuidas y se benefician de la observabilidad.
En el nivel más alto, un sistema distribuido está formado por recursos y transacciones:
- Recursos
-
Se trata de todos los componentes físicos y lógicos que componen un sistema. Los componentes físicos, como servidores, contenedores, procesos, RAM, CPU y tarjetas de red, son todos recursos. Los componentes lógicos, como clientes, aplicaciones, puntos finales de API, bases de datos y equilibradores de carga, también son recursos. En resumen, los recursos son todo aquello a partir de lo cual se construye realmente el sistema.
- Transacciones
-
Son peticiones a que orquestan y utilizan los recursos que el sistema necesita para realizar un trabajo en nombre del usuario. Normalmente, una transacción la inicia un humano real, que está esperando a que se complete la tarea. Reservar un vuelo, pedir un viaje compartido y cargar una página web son ejemplos de transacciones.
¿Cómo observamos estos sistemas distribuidos? No podemos, a menos que emitan telemetría. La telemetría es datos que describen lo que está haciendo tu sistema. Sin telemetría, tu sistema no es más que una gran caja negra llena de misterio.
Muchos desarrolladores encuentran confusa la palabra telemetría. Es un término sobrecargado. La distinción que establecemos en este libro, y en el monitoreo de sistemas en general, es entre telemetría de usuario y telemetría de rendimiento:
- Telemetría de usuario
-
Se refiere a datos sobre cómo un usuario está interactuando con un sistema a través de un cliente: clics en botones, duración de la sesión, información sobre la máquina anfitriona del cliente, etc. Puedes utilizar estos datos para comprender cómo interactúan los usuarios con un sitio de comercio electrónico, o la distribución de las versiones de los navegadores que acceden a una aplicación basada en web.
- Telemetría de rendimiento
-
Esto es no se utiliza principalmente para analizar el comportamiento de los usuarios, sino que proporciona a los operadores información estadística sobre el comportamiento y el rendimiento de los componentes del sistema. Los datos de rendimiento pueden proceder de distintas fuentes en un sistema distribuido y ofrecen a los desarrolladores un "rastro de migas de pan" que seguir, conectando la causa con el efecto.
En términos más sencillos, la telemetría de usuario te dirá cuánto tiempo pasó alguien el cursor del ratón sobre un botón de pago en una aplicación de comercio electrónico. La telemetría de rendimiento te dirá cuánto tardó en cargarse ese botón de pago, y qué programas y recursos utilizó el sistema por el camino.
Por debajo de la telemetría de usuario y de rendimiento hay distintos tipos de señales . Una señal es una forma particular de telemetría. Los registros de eventos son un tipo de señal. Las métricas del sistema son otro tipo de señal. Los perfiles continuos son otro. Cada uno de estos tipos de señal tiene un propósito diferente, y en realidad no son intercambiables. No puedes deducir todos los eventos que componen una interacción de usuario sólo mirando las métricas del sistema, y no puedes deducir la carga del sistema sólo mirando los registros de transacciones. Necesitas múltiples tipos de señales para obtener una comprensión profunda de tu sistema en su conjunto.
Cada señal de consta de dos partes: instrumentación -códigoque emite datos telemétricos- dentro de los propios programas, y un sistema de transmisión para enviar los datos por la red a una herramienta de análisis, donde se produce la observación real.
Esto plantea una distinción importante: es habitual confundir telemetría y análisis, pero es importante comprender que el sistema que emite los datos y el sistema que los analiza son independientes entre sí. La telemetría son los datos en sí. El análisis es lo que haces con los datos.
Por último, telemetría más un análisis es igual a observabilidad. Comprender la mejor manera de combinar estas dos piezas en un sistema de observabilidad útil es de lo que trata este libro .
Breve historia de la telemetría
Dato curioso: se llama telemetría en porque los primeros sistemas de diagnóstico a distancia transmitían datos a través de líneas telegráficas. Aunque la gente suele pensar en cohetes y en la industria aeroespacial de los años 50 cuando oye el término telemetría, si la práctica hubiera empezado por ahí, se habría llamado radiometría. En realidad, la telemetría se desarrolló por primera vez para el monitoreo de centrales eléctricas y redes eléctricas públicas: ¡sistemas distribuidos tempranos pero importantes!
Por supuesto, la telemetría informática vino después. La historia específica de la telemetría de usuario y de rendimiento se corresponde con los cambios en las operaciones de software, y con la potencia de procesamiento y el ancho de banda de red cada vez mayores que han impulsado esas tendencias durante mucho tiempo. Comprender cómo surgieron las señales de telemetría informática y cómo evolucionaron es una parte importante de la comprensión de sus limitaciones actuales.
La primera y más duradera forma de telemetría fue logging. Los registros son mensajes de texto destinados al consumo humano que describen el estado de un sistema o servicio. Con el tiempo, los desarrolladores y operadores mejoraron la forma de almacenar y buscar estos registros creando bases de datos especializadas que eran buenas en la búsqueda de texto completo.
Mientras que el registro te informaba de eventos y momentos individuales dentro de un sistema, comprender cómo cambiaba ese sistema a lo largo del tiempo requería más datos. Un registro podía decirte que no se podía escribir un archivo porque el dispositivo de almacenamiento no tenía espacio, pero ¿no sería estupendo que pudieras hacer un seguimiento de la capacidad de almacenamiento disponible y hacer un cambio antes de quedarte sin espacio?
Las métricas son representaciones estadísticas compactas del estado del sistema y de la utilización de los recursos. Eran perfectas para el trabajo. Añadir métricas hizo posible crear alertas sobre los datos, más allá de los errores y las excepciones.
Con el despegue de la Internet moderna, los sistemas se hicieron más complejos y el rendimiento se volvió más crítico. Se añadió una tercera forma de telemetría : el rastreo distribuido. A medida que las transacciones crecían e incluían cada vez más operaciones y más máquinas, localizar el origen de un problema se hizo más crítico. En lugar de fijarse sólo en los eventos individuales -los registros-, los sistemas de rastreo se fijaron en operaciones enteras y en cómo se combinaban para formar transacciones. Las operaciones tienen una hora de inicio y una hora de finalización. También tienen una ubicación: ¿en qué máquina se produjo una operación concreta? Rastrear esto permitía localizar el origen de la latencia en una operación concreta o en una máquina. Sin embargo, debido a las limitaciones de recursos, los sistemas de rastreo tendían a estar muy muestreados y acababan registrando sólo una pequeña fracción del número total de transacciones, lo que limitaba su utilidad más allá del análisis básico del rendimiento.
Las tres pestañas del navegador de la observabilidad
Aunque hay otras formas útiles de telemetría, la primacía de estos tres sistemas -registros, métricas y seguimiento- dio lugar al concepto conocido hoy como los "tres pilares de la observabilidad".4 Los tres pilares son una forma estupenda de describir cómo practicamos actualmente la observabilidad, ¡pero en realidad son una forma terrible de diseñar un sistema de telemetría!
Tradicionalmente, cada forma de observabilidad -telemetría más análisis- se construía como un sistema completamente separado y aislado, como se describe en la Figura 1-1.
Figura 1-1. Un pilar de la observabilidad
Un sistema de registro consta de una instrumentación de registro, un sistema de transmisión de registros y una herramienta de análisis de registros. Un sistema de métricas consta de instrumentación de métricas, un sistema de transmisión de métricas y una herramienta de análisis de métricas. Lo mismo ocurre con el rastreo, de ahí los tres pilares descritos en la Figura 1-2.
Figura 1-2. Los tres pilares de la observabilidad
Esto es integración vertical básica: cada sistema se construye con un propósito, de extremo a extremo. Tiene sentido que la observabilidad se haya construido así: ha ido evolucionando con el tiempo, añadiendo cada pieza a medida que se necesitaba. En otras palabras, la observabilidad está estructurada de este modo sin mejor razón que el accidente histórico. La forma más sencilla de implantar un sistema de registro o un sistema de métricas es hacerlo de forma aislada, como un sistema independiente.
Así que, aunque el término "tres pilares" explica la forma en que se diseña la observabilidad tradicional, también es problemático: ¡hace que esta arquitectura parezca una buena idea! Y no lo es. Es descarado, pero prefiero un giro diferente de la frase: "las tres pestañas del navegador de la observabilidad". Porque eso es lo que obtienes en realidad.
Complicaciones emergentes
El problema es que nuestros sistemas no se componen de problemas de registro o de métricas. Se componen de transacciones y recursos. Cuando se produce un problema, éstas son las dos únicas cosas que podemos modificar: los desarrolladores pueden cambiar lo que hacen las transacciones, y los operadores pueden cambiar los recursos disponibles. Eso es todo.
Pero el diablo está en los detalles. Es posible que un error simple y aislado se limite a una sola transacción. Pero la mayoría de los problemas de producción surgen de la forma en que interactúan muchas transacciones concurrentes.
Una gran parte de la observación de sistemas reales implica identificar pautas de mal comportamiento y luego extrapolar para averiguar cómo determinadas pautas de transacciones y consumo de recursos causan estas pautas. ¡Eso es realmente difícil de hacer! Es muy difícil predecir cómo acabarán interactuando las transacciones y los recursos en el mundo real. Las pruebas y las implementaciones a pequeña escala no siempre son herramientas útiles para esta tarea, porque los problemas que intentas resolver no aparecen fuera de la producción. Estos problemas son efectos secundarios emergentes, y son específicos de la forma en que la realidad física de tu implementación en producción interactúa con los usuarios reales del sistema.
¡Esto es un lío! Evidentemente, tu capacidad para resolver estos problemas depende de la calidad de la telemetría que emita tu sistema en producción.
Los Tres Pilares fueron un Accidente
Definitivamente, puedes utilizar métricas, registros y trazas para comprender tu sistema. Los registros y las trazas te ayudan a reconstruir los eventos que componen una transacción, mientras que las métricas te ayudan a comprender el uso y la disponibilidad de los recursos.
Pero las observaciones útiles no surgen de observar los datos de forma aislada. No puedes mirar un solo punto de datos, ni siquiera un solo tipo de datos, y comprender nada sobre el comportamiento emergente. Casi nunca encontrarás la causa raíz de un problema con sólo mirar los registros o las métricas. Las pistas que nos llevan a las respuestas provienen de encontrar correlaciones entre estos diferentes flujos de datos. Así que, al investigar un problema, tiendes a ir y venir entre registros y métricas, buscando correlaciones.
Éste es el principal problema del enfoque tradicional de los tres pilares: todas estas señales se guardan en silos de datos separados. Esto hace imposible identificar automáticamente correlaciones entre patrones cambiantes en nuestros registros de transacciones y patrones cambiantes en nuestras métricas. En lugar de eso, acabas con tres pestañas de navegador separadas, y cada una contiene sólo una parte de lo que necesitas.
La integración vertical empeora aún más las cosas: si quieres detectar correlaciones entre métricas, registros y trazas, necesitas que estas conexiones estén presentes en la telemetría que emiten tus sistemas. Sin una telemetría unificada, aunque pudieras almacenar estas señales separadas en la misma base de datos, te seguirían faltando los identificadores clave que hacen que las correlaciones sean fiables y coherentes. ¡Así que los tres pilares son en realidad un mal diseño! Lo que necesitamos es un sistema integrado .
Una sola trenza de datos
¿Cómo clasificas tus sistemas una vez que has detectado un problema? Encontrando correlaciones. ¿Cómo encuentras correlaciones? Hay dos formas: con humanos y con ordenadores:
- Investigación humana
-
Los operadores barren todos los datos disponibles, construyendo un modelo mental del sistema actual. Luego, en sus cabezas, intentan identificar cómo podrían estar conectadas secretamente todas las piezas. Este enfoque no sólo es mentalmente agotador, sino que también está sujeto a las limitaciones de la memoria humana. Piénsalo: están buscando literalmente correlaciones utilizando sus globos oculares para mirar líneas garabateadas. Además, la investigación humana se resiente a medida que las organizaciones crecen y los sistemas se hacen más complejos. Convertir algo que ves en una línea garabateada en una idea procesable se hace más difícil cuando los conocimientos necesarios están distribuidos por todo el mundo.
- Investigación informática
-
La segunda forma de encontrar correlaciones es utilizando ordenadores. Puede que los ordenadores no sean buenos formando hipótesis y encontrando causas profundas, pero son muy buenos identificando correlaciones. Eso no es más que matemática estadística.
-
Pero, de nuevo, hay una trampa: los ordenadores sólo pueden encontrar correlaciones entre fragmentos de datos conectados. Y si tus datos telemétricos están divididos en silos, no están estructurados y son incoherentes, la ayuda que pueden ofrecerte los ordenadores será muy limitada. Por eso los operadores humanos siguen utilizando sus ojos para buscar métricas, al tiempo que intentan memorizar cada línea de cada archivo de configuración.
En lugar de tres pilares separados, utilicemos una nueva metáfora: una única trenza de datos. La Figura 1-3 muestra mi forma favorita de pensar en la telemetría de alta calidad. Seguimos teniendo tres señales separadas -no hay que confundirlas-, pero las señales tienen puntos de contacto que lo conectan todo en una única estructura gráfica de datos.
Figura 1-3. Una trenza de señales, que facilita encontrar correlaciones entre ellas
Con un sistema de telemetría como éste, es posible que los ordenadores recorran el gráfico, encontrando rápidamente conexiones distantes pero importantes. La telemetría unificada significa que por fin es posible tener un análisis unificado, que es fundamental para desarrollar una comprensión profunda de los problemas emergentes inherentes a los sistemas de producción en vivo.
¿Existe ese sistema de telemetría? Existe. Y es llamado OpenTelemetry.
Conclusión
El mundo de la observabilidad está en proceso de cambiar a mejor, y en el centro de ese cambio estará una capacidad recién descubierta de correlacionar todas las formas de telemetría: trazas, métricas, registros, perfiles, todo. La correlación es la clave para desbloquear los flujos de trabajo y la automatización que necesitamos desesperadamente para seguir el ritmo de este mundo de sistemas complejos en constante expansión.
Este cambio ya se está produciendo, pero pasará algún tiempo hasta que la transición sea completa y los productos de observabilidad exploren el tipo de características que estos nuevos datos desbloquean. Estamos sólo al principio. Pero dado que el núcleo de esta transición es un cambio hacia un nuevo tipo de datos, y dado que OpenTelemetry es ahora la fuente ampliamente consensuada de esos datos, comprender OpenTelemetry significa comprender el futuro de la observabilidad en general.
Este libro será tu guía para aprender OpenTelemetry. No pretende sustituir a la documentación de OpenTelemetry, que puedes encontrar en el sitio web del proyecto. En su lugar, este libro explica la filosofía y el diseño de OpenTelemetry y ofrece orientación práctica sobre cómo manejarlo con eficacia.
En el Capítulo 2, explicamos la propuesta de valor que aporta OpenTelemetry, y cómo se beneficia tu organización de sustituir la instrumentación propietaria por instrumentación basada en estándares abiertos.
En el Capítulo 3, profundizamos en el modelo OpenTelemetry y analizamos las principales señales de observabilidad de las trazas, las métricas y los registros, junto con la forma en que se vinculan mediante el contexto.
En el Capítulo 4, nos ponemos manos a la obra con OpenTelemetry en la Demo de OpenTelemetry, ofreciéndote una visión general de sus componentes y de cómo encaja OpenTelemetry en una pila de observabilidad.
En el Capítulo 5, nos sumergimos en la instrumentación de una aplicación y proporcionamos una lista de comprobación para ayudar a garantizar que todo funciona y que la telemetría es de alta calidad.
En el Capítulo 6, hablamos de la instrumentación de las bibliotecas y servicios de OSS y explicamos por qué los responsables de las bibliotecas deben preocuparse por la observabilidad.
En el Capítulo 7, revisamos las opciones para observar la infraestructura de software: proveedores de nube, plataformas y servicios de datos.
En el Capítulo 8, entramos en detalle en cómo y por qué construir distintos tipos de canalizaciones de observabilidad utilizando el Colector OpenTelemetry.
En el capítulo 9, damos consejos sobre cómo implementar OpenTelemetry en tu organización. Dado que la telemetría -especialmente el rastreo- es una cuestión que afecta a varios equipos, existen escollos organizativos a la hora de desplegar un nuevo sistema de observabilidad. Este capítulo proporcionará estrategias y consejos sobre cómo garantizar el éxito de la implantación.
Por último, nuestros apéndices incluyen recursos útiles sobre la estructura del propio proyecto OpenTelemetry, así como enlaces a lecturas adicionales y otros títulos.
Si eres nuevo en OpenTelemetry, te recomendamos encarecidamente que leas primero el Capítulo 4. Después, los capítulos pueden leerse en cualquier orden. Siéntete libre de saltar a la sección que sea más relevante para la tarea que necesites realizar.
1 Henry Glassie, Passing the Time in Ballymenone: Cultura e Historia de una Comunidad del Ulster (Filadelfia: University of Pennsylvania Press, 1982).
2 Carl E. Sagan (autor y presentador), en Cosmos: Un viaje personal, temporada 1, episodio 2, "Una voz en la fuga cósmica", producido por Adrian Malone (Arlington, VA: Public Broadcasting Service, 1980).
3 Andrew S. Tanenbaum y Maarten van Steen, Sistemas distribuidos: Principles and Paradigms (Upper Saddle River, NJ: Prentice Hall, 2002).
4 Cindy Sridharan, Observabilidad de los sistemas distribuidos (Sebastopol, CA: O'Reilly, 2018).
Get Aprender OpenTelemetry now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
