Rastreo distribuido en la práctica

Introducción: ¿Qué es el Rastreo Distribuido?

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

Si estás leyendo este libro, puede que ya tengas alguna idea de lo que significan las palabras distribuidas en el calco. También puede que no tengas ni idea de lo que significan; por lo que sabemos, simplemente eres un fan de los bandicoots (el animal de la portada). No te juzgaremos, lo prometemos.

En cualquier caso, estás leyendo esto para comprender mejor qué es el trazado distribuido y cómo puedes utilizarlo para entender el rendimiento y el funcionamiento de tus microservicios y otro software. Con esto en mente, empecemos con una definición sencilla.

Rastreo distribuido (también llamado rastreo de peticiones distribuidas) es un tipo de registro correlacionado que te ayuda a obtener visibilidad del funcionamiento de un sistema de software distribuido para casos de uso como la elaboración de perfiles de rendimiento, la depuración en producción y el análisis de la causa raíz de fallos u otros incidentes. Te da la posibilidad de comprender exactamente lo que está haciendo un servicio individual concreto como parte del conjunto, permitiéndote plantear y responder preguntas sobre el rendimiento de tus servicios y de tu sistema distribuido en su conjunto.

Ha sido fácil, ¡hasta el próximo libro!

¿Por qué? ¿Por qué todo el mundo pide un reembolso? Oh...

Nos dicen que necesitas algo más que eso. Bien, demos un paso atrás y hablemos de software, concretamente de software distribuido, para que podamos comprender mejor los problemas que resuelve el rastreo distribuido.

Las arquitecturas distribuidas y tú

El arte y la ciencia del desarrollo, la implementación y el funcionamiento del software están en constante cambio. Los nuevos avances en hardware y software informático han ampliado drásticamente los límites de lo que es una aplicación a lo largo de los años. Aunque aquí hay una interesante digresión sobre cómo "todo lo viejo vuelve a ser nuevo", nos centraremos en los cambios de las dos últimas décadas aproximadamente, en aras de la brevedad.

Antes de los avances en virtualización y contenerización, si necesitabas implementar algún tipo de aplicación basada en web, necesitabas un servidor físico, posiblemente uno dedicado a tu propia aplicación. A medida que aumentaba el tráfico hacia tu aplicación, tendrías que aumentar los recursos físicos de ese servidor (añadiendo RAM, por ejemplo) o necesitarías varios servidores que ejecutaran cada uno su propia copia de tu aplicación.

Con un proceso de servidor monolítico, este escalado horizontal a menudo conducía a compensaciones desfavorables en coste, rendimiento y sobrecarga organizativa. Ejecutar múltiples instancias de tu servidor significaba que estabas duplicando toda la funcionalidad del servidor, en lugar de escalar subcomponentes individuales de forma independiente. Con la infraestructura tradicional, a menudo te veías obligado a tomar una decisión sobre cuántos minutos (¡u horas!) de rendimiento degradado eran aceptables mientras ponías capacidad adicional en línea: el funcionamiento de los servidores no es barato, así que ¿por qué ibas a funcionar al máximo de capacidad si no lo necesitabas? Por último, a medida que aumentaban el tamaño y la complejidad de tu aplicación, junto con la cantidad de desarrolladores que trabajaban en ella, probar y validar los nuevos cambios se hacía más difícil. A medida que tu organización crecía, resultaba poco razonable que los desarrolladores comprendieran una única base de código, por no hablar de la forma de todo el sistema. Los cambios, cada vez más pequeños, aumentaban las probabilidades de que se produjera un efecto dominó que condujera a un fallo total de la aplicación, a medida que su impacto se irradiaba de un componente a otro.

Sin embargo, el tiempo avanzó y se crearon soluciones a estos problemas. Se creó software que abstraía los detalles del hardware físico, como la virtualización, que permitía dividir un único servidor físico en varios servidores lógicos. Docker y otras tecnologías de contenedorización ampliaron este concepto, proporcionando una abstracción ligera y fácil de usar sobre máquinas virtuales más pesadas, trasladando la cuestión de "quién despliega este software" de los operadores a los desarrolladores. La popularización de la computación en nube y su noción de recursos informáticos bajo demanda resolvió el problema del escalado de recursos, ya que se hizo posible aumentar la cantidad de RAM o de núcleos de CPU de un servidor determinado con sólo pulsar un botón. Por último, surgió la idea de las arquitecturas de microservicios para hacer frente a la complejidad impuesta por empresas orientadas al software cada vez más grandes y complicadas, estructurando grandes aplicaciones en torno a servicios independientes débilmente acoplados.

Hoy en día, es discutible que la mayoría de las aplicaciones estén distribuidas de algún modo, aunque no utilicen microservicios. Las propias aplicaciones cliente-servidor sencillas de están distribuidas: considera la clásica pregunta de "Se ha agotado el tiempo de una llamada a mi servidor; ¿se ha perdido la respuesta o no se ha realizado el trabajo?". Además, pueden tener una variedad de dependencias distribuidas, como almacenes de datos que se consumen como un servicio ofrecido por un proveedor de la nube, o toda una serie de API de terceros que proporcionan de todo, desde análisis a notificaciones push y más.

¿Por qué es tan popular el software distribuido? Los argumentos a favor del software distribuido son bastante claros:

Escalabilidad

Una aplicación distribuida puede responder más fácilmente a la demanda, y su escalado puede ser más eficiente. Si mucha gente intenta iniciar sesión en tu aplicación, podrías escalar sólo los servicios de inicio de sesión, por ejemplo.

Fiabilidad

Los fallos en un componente no deberían hacer caer toda la aplicación. Las aplicaciones distribuidas son más resistentes porque dividen las funciones a través de una variedad de procesos de servicio y hosts, asegurando que incluso si un servicio dependiente se desconecta, no debería afectar al resto de la aplicación.

Mantenibilidad

El software distribuido es más fácil de mantener por un par de razones. Dividir los servicios entre sí puede aumentar la mantenibilidad de cada componente, al permitirle centrarse en un conjunto más reducido de responsabilidades. Además, tienes más libertad para añadir funciones y capacidades sin tener que implementarlas (y mantenerlas) tú mismo; por ejemplo, añadir una función de voz a texto en una aplicación confiando en el servicio de voz a texto de algún proveedor en la nube.

Esto es la punta del iceberg, por así decirlo, en cuanto a las ventajas de las arquitecturas distribuidas. Por supuesto, no todo es sol y rosas, y en toda vida debe caer un poco de lluvia...

Sistemas profundos

Una arquitectura distribuida es un excelente ejemplo de lo que los arquitectos de software suelen llamar un sistema profundo.¹ Estos sistemas destacan no por su amplitud, sino por su complejidad. Si piensas en determinados servicios o clases de servicios en una arquitectura distribuida, deberías ser capaz de identificar la diferencia. Un conjunto de nodos de caché se escala ampliamente (es decir, simplemente añades más instancias para gestionar la demanda), pero otros servicios se escalan de forma diferente. Las peticiones pueden dirigirse a través de tres, cuatro, catorce o cuarenta capas diferentes de servicios, y cada una de esas capas puede tener otras dependencias de las que no eres consciente. Incluso si tienes un servicio comparativamente sencillo, tu software probablemente tiene docenas de dependencias de código que no has escrito, o de servicios gestionados a través de un proveedor de la nube, o incluso del software de orquestación subyacente que gestiona su estado.

El problema de los sistemas profundos es, en última instancia, humano. Rápidamente se vuelve poco realista que un solo humano, o incluso un grupo de ellos, comprenda lo suficiente de los servicios que están en la ruta crítica de una sola solicitud y siga manteniéndola. El alcance de lo que tú, como propietario de un servicio, puedes controlar frente a aquello de lo que eres implícitamente responsable se ilustra en la Figura P-1. Este cálculo se convierte en una receta para el estrés y el agotamiento, ya que te ves forzado a un estado reactivo frente a otros propietarios de servicios, apagando fuegos constantemente e intentando averiguar cómo interactúan tus servicios entre sí.

Figura P-1. El servicio que puedes controlar tiene dependencias de las que eres responsable pero sobre las que no tienes control directo.

Las arquitecturas distribuidas requieren un enfoque reimaginado para comprender la salud y el rendimiento del software. No basta con mirar un único rastreo de pila o ver gráficos de utilización de la CPU y la memoria. A medida que el software escala -en profundidad, pero también en amplitud-, los datos telemétricos como los registros y las métricas por sí solos no proporcionan la claridad que necesitas para identificar rápidamente los problemas en producción.

Las dificultades para comprender las arquitecturas distribuidas

Distribuir tu software presenta nuevos y emocionantes retos. De repente, los fallos y las caídas son más difíciles de localizar. El servicio del que eres responsable puede estar recibiendo datos malformados o inesperados de una fuente que no controlas porque ese servicio lo gestiona un equipo al otro lado del mundo (o un equipo remoto). Los fallos en servicios que creías sólidos como una roca de repente provocan fallos y errores en cascada en todos tus servicios. Tomando prestada una frase de Twitter, tienes entre manos un misterio de asesinato de microservicios (ver Figura P-2).

Figura P-2. Es gracioso porque es verdad.

Para ampliar la metáfora, el monitoreo ayuda a determinar dónde está el cadáver, pero no revela por qué se produjo el asesinato. El rastreo distribuido rellena esas lagunas permitiéndote comprender fácilmente todo tu sistema, aportando soluciones a tres grandes puntos conflictivos:

Ofuscación

A medida que tu aplicación se vuelve más distribuida, la coherencia de los fallos empieza a disminuir. Es decir, aumenta la distancia entre causa y efecto. Una interrupción en el almacenamiento de blobs de tu proveedor de la nube podría extenderse y causar una enorme latencia en cascada para todo el mundo, o un único fallo difícil de diagnosticar en un servicio concreto a muchos saltos de distancia que te impida descubrir la causa próxima.

Inconsistencia

Las aplicaciones distribuidas pueden ser fiables en general, pero el estado de los componentes individuales puede ser mucho menos consistente de lo que sería en aplicaciones monolíticas o no distribuidas. Además, como cada componente de una aplicación distribuida está diseñado para ser muy independiente, el estado de esos componentes será incoherente: ¿qué ocurre cuando alguien hace una implementación, por ejemplo? ¿Saben todos los demás componentes qué hacer? ¿Cómo afecta esto a la aplicación en su conjunto?

Descentralizado

Los datos críticos sobre el rendimiento de tus servicios estarán, por definición, descentralizados. ¿Cómo buscas fallos en un servicio cuando puede haber mil copias de ese servicio ejecutándose, en cientos de hosts? ¿Cómo correlacionas esos fallos? ¡La mayor ventaja de distribuir tu aplicación es también el mayor impedimento para comprender cómo funciona realmente!

Te estarás preguntando: "¿Cómo abordamos estas dificultades?". Spoiler: rastreo distribuido.

¿Cómo ayuda el Rastreo Distribuido?

El rastreo distribuido surge como una herramienta crítica para gestionar la explosión de complejidad que conllevan nuestros sistemas profundos. Proporciona un contexto que abarca la vida de una solicitud y puede utilizarse para comprender las interacciones y la forma de tu arquitectura. Sin embargo, estas trazas individuales son sólo el principio -en agregadas, las trazas pueden darte importantes conocimientos sobre lo que está ocurriendo realmente en tu sistema distribuido, permitiéndote no sólo correlacionar datos interesantes sobre tus servicios (por ejemplo, que la mayoría de tus errores están ocurriendo en un host específico o en un clúster de base de datos específico), sino también filtrar y clasificar la importancia de otros tipos de telemetría. Efectivamente, el rastreo distribuido proporciona un contexto que te ayuda a filtrar la resolución de problemas sólo a las cosas que son relevantes para tu investigación, para que no tengas que adivinar y comprobar múltiples registros y cuadros de mando. De este modo, el rastreo distribuido está realmente en el centro de una plataforma de observabilidad moderna, y se convierte en un componente crítico de tu arquitectura distribuida, en lugar de una herramienta aislada.

Entonces, ¿qué es una traza? La forma más fácil de entenderlo es pensar en tu software en términos de peticiones. Cada uno de tus componentes está en el negocio de hacer algún tipo de trabajo en respuesta a una solicitud (también conocida como RPC, de llamada a procedimiento remoto) de otro servicio. Esto podría ser tan prosaico como una página web que solicita algunos datos estructurados de un punto final de servicio para presentarlos a un usuario, o tan complejo como un proceso de búsqueda altamente paralelizado. La naturaleza real del trabajo no importa demasiado, aunque hay ciertos patrones que discutiremos más adelante que se prestan a ciertos estilos de rastreo. Aunque el rastreo distribuido puede funcionar en la mayoría de los sistemas distribuidos, como veremos en el Capítulo 4, sus puntos fuertes se demuestran mejor al modelar las relaciones RPC entre tus servicios.

Además de las relaciones RPC, piensa en el trabajo que realiza cada uno de esos servicios. Quizá estén autenticando y autorizando roles de usuario, realizando cálculos matemáticos o simplemente transformando datos de un formato a otro. Estos servicios se comunican entre sí mediante RPCs, enviando peticiones y recibiendo respuestas. Independientemente de lo que estén haciendo, una cosa que todos estos servicios tienen en común es que el trabajo que realizan lleva cierto tiempo. El patrón básico de servicios y RPCs se ilustra en la Figura P-3.

Figura P-3. Petición de un proceso cliente a un proceso servicio.

Llamamos " lapso" al trabajo que realiza cada servicio, es decir, el lapso de tiempo que tarda en realizarse el trabajo. Estos tramos pueden anotarse con metadatos (conocidos comoatributos o etiquetas ) y eventos (también denominadosregistros ). Las RPC entre servicios se representan medianterelaciones que modelan la naturaleza de la solicitud y el orden en que se producen las solicitudes. Esta relación se propaga a través delcontexto de traza , unos datos que identifican de forma única una traza y cada span individual dentro de ella. Los datos de tramos creados por cada servicio se envían a algún proceso externo, donde pueden agregarse en una traza , analizarse para obtener más información y almacenarse para análisis posteriores. Un ejemplo sencillo de una traza puede verse en la Figura P-4, que muestra una traza entre dos servicios, así como una subtraza dentro del primer servicio.

Figura P-4. Una traza sencilla.

El rastreo distribuido mitiga la ofuscación presente en las arquitecturas distribuidas, garantizando que cada petición lógica a través de tus servicios se presente como eso: una única petición lógica. Garantiza que todos los datos relevantes para una determinada ejecución de tu lógica empresarial permanezcan acoplados en el momento en que se analizan y presentan. Aborda el problema de la incoherencia permitiendo que las consultas se realicen utilizando relaciones entre servicios a lo largo de API específicas u otras rutas, permitiéndote hacer preguntas como "¿Qué le ocurre a mi API cuando este otro servicio está caído?". Por último, aborda el problema de la descentralización proporcionando un método para garantizar que los procesos puedan aportar datos de rastreo de forma independiente a un recopilador que pueda centralizarlos posteriormente, permitiéndote visualizar y comprender solicitudes que puedan estar ejecutándose en múltiples centros de datos, regiones u otras distribuciones.

Teniendo todo esto en cuenta, ¿qué cosas puedes hacer con el rastreo distribuido? ¿Qué hace que sea crucial para comprender los sistemas distribuidos? Hemos recopilado varios ejemplos del mundo real en :

• Una importante empresa de mensajería y correo electrónico transaccional implementó el rastreo distribuido en su plataforma de backend, incluido el rastreo de llamadas a Redis. Estos datos de rastreo mostraron rápidamente que había un bucle innecesario en sus llamadas a Redis, que obtenía datos de la caché más de lo necesario. Al eliminar esta llamada innecesaria, la empresa redujo el tiempo necesario para enviar un correo electrónico entre 100 y 1.000 milisegundos. Esto supuso una reducción aproximada del 85% en el tiempo de envío de cada correo electrónico, ¡y en una plataforma que enviaba más de mil millones de correos electrónicos al día! La empresa no sólo pudo descubrir esta llamada innecesaria, sino que pudo validar el impacto de su eliminación en otros servicios y cuantificar el valor del trabajo.

• Una empresa de datos industriales pudo utilizar datos de rastreo distribuidos para comparar fácilmente las peticiones durante un incidente en el que se sobrecargó una base de datos primaria con una línea de base anterior. La posibilidad de ver datos estadísticos agregados sobre el rendimiento histórico junto con el contexto de las solicitudes individuales durante la regresión redujo drásticamente el tiempo necesario para determinar la causa raíz del incidente.

• Una importante empresa de salud y fitness implantó el rastreo distribuido en todas sus aplicaciones. Al analizar el rendimiento de su base de datos de documentos, los ingenieros pudieron identificar llamadas repetidas que podían consolidarse, lo que redujo la latencia y mejoró la eficiencia del código.

• Una plataforma de distribución de vídeo utilizó el rastreo distribuido para solucionar problemas de latencia de los servicios gestionados de los que dependía su sistema. Fue capaz de identificar positivamente un problema con la canalización Kafka de su proveedor en la nube antes de que lo hiciera el vendedor, lo que permitió responder rápidamente al incidente y restablecer el rendimiento deseado.

Estos son sólo un puñado de ejemplos: el rastreo distribuido también ha demostrado su valor en equipos que intentan comprender mejor sus sistemas de integración continua proporcionando visibilidad en su canal de pruebas, en el funcionamiento de tecnologías de búsqueda a escala global en Google, y como piedra angular de proyectos de código abierto como OpenTelemetry. La verdadera pregunta es: ¿qué es para ti el rastreo distribuido?

Rastreo distribuido y tú

El rastreo distribuido, de nuevo, es un método para comprender el software distribuido. Pero eso es muy parecido a decir que el agua es húmeda: no es muy útil y es muy reductivo. De hecho, la mejor forma de entender el trazado distribuido es verlo en la práctica, ¡y ahí es donde entra este libro!

En los próximos capítulos, trataremos las tres cosas principales que necesitas saber para empezar a implantar el rastreo distribuido en tus aplicaciones y discutiremos las estrategias que puedes aplicar para resolver los problemas causados por las arquitecturas distribuidas. Conocerás las distintas formas de instrumentar tu software para el rastreo distribuido y los estilos de rastreo y monitoreo que tienes a tu disposición. Discutiremos cómo recopilar todos los datos que produce tu instrumentación y las diversas consideraciones de rendimiento y costes en torno a la recopilación y almacenamiento de datos de rastreo. A continuación, veremos cómo generar valor a partir de tus datos de seguimiento y convertirlos en información útil y operativa. Por último, hablaremos del futuro del rastreo distribuido.

Al final de este libro, deberás comprender el apasionante mundo del rastreo distribuido y saber dónde, cómo y cuándo implementarlo en tu software. En última instancia, el objetivo de Rastreo distribuido en la práctica es permitirte construir, manejar y comprender tu software más fácilmente. Esperamos que las lecciones de este texto te ayuden a construir la próxima generación de prácticas de monitoreo y observabilidad en tu organización.

Convenciones utilizadas en este libro

En este libro se utilizan las siguientes convenciones tipográficas :

Cursiva

Indica nuevos términos, URL, direcciones de correo electrónico, nombres de archivo y extensiones de archivo.

Constant width

Se utiliza en los listados de programas, así como dentro de los párrafos para referirse a elementos del programa como nombres de variables o funciones, bases de datos, tipos de datos, variables de entorno, sentencias y palabras clave.

Constant width bold

Muestra comandos u otros textos que deben ser tecleados literalmente por el usuario.

Constant width italic

Muestra el texto que debe sustituirse por valores proporcionados por el usuario o por valores determinados por el contexto.

Nota

Este elemento significa una nota general.

Utilizar ejemplos de código

El material complementario (ejemplos de código, ejercicios, etc.) está disponible para su descarga en en GitHub.

Si tienes una pregunta técnica o un problema al utilizar los ejemplos de código, envía un correo electrónico a [e-mail].

Este libro está aquí para ayudarte a hacer tu trabajo. En general, si se ofrece código de ejemplo con este libro, puedes utilizarlo en tus programas y documentación. No es necesario que te pongas en contacto con nosotros para solicitar permiso a a menos que estés reproduciendo una parte importante del código. Por ejemplo, escribir un programa que utilice varios trozos de código de este libro no requiere permiso. Vender o distribuir ejemplos de libros de O'Reilly sí requiere permiso. Responder a una pregunta citando este libro y el código de ejemplo no requiere permiso. Incorporar una cantidad significativa de código de ejemplo de este libro en la documentación de tu producto sí requiere permiso.

Agradecemos la atribución, pero en general no la exigimos. Una atribución suele incluir el título, el autor, la editorial y el ISBN. Por ejemplo"Rastreo Distribuido en la Práctica " por Austin Parker, Daniel Spoonhower, Jonathan Mace y Rebecca Isaacs con Ben Sigelman (O'Reilly). Copyright 2020 Ben Sigelman, Austin Parker, Daniel Spoonhower, Jonathan Mace y Rebecca Isaacs, 978-1-492-05663-8".

Si crees que el uso que haces de los ejemplos de código no se ajusta al uso legítimo o al permiso concedido anteriormente, no dudes en ponerte en contacto con nosotros en [e-mail].

Aprendizaje en línea O'Reilly

Nota

Durante más de 40 años, O'Reilly Media ha proporcionado formación tecnológica y empresarial, conocimientos y perspectivas para ayudar a las empresas a alcanzar el éxito.

Nuestra red única de expertos e innovadores comparten sus conocimientos y experiencia a través de libros, artículos y nuestra plataforma de aprendizaje online. La plataforma de aprendizaje en línea de O'Reilly te ofrece acceso bajo demanda a cursos de formación en directo, rutas de aprendizaje en profundidad, entornos de codificación interactivos y una amplia colección de textos y vídeos de O'Reilly y de más de 200 editoriales. Visita http://oreilly.com para obtener más información.

Cómo contactar con nosotros

Dirige tus comentarios y preguntas sobre este libro a la editorial:

• O'Reilly Media, Inc.
• 1005 Gravenstein Highway Norte
• Sebastopol, CA 95472
• 800-998-9938 (en Estados Unidos o Canadá)
• 707-829-0515 (internacional o local)
• 707-829-0104 (fax)

Tenemos una página web para este libro, donde se enumeran erratas, ejemplos y cualquier información adicional. Puedes acceder a esta página en https://oreil.ly/distributed-tracing.

Envía un correo electrónico a [e-mail] para comentar o hacer preguntas técnicas sobre este libro.

Para noticias e información sobre nuestros libros y cursos, visita http://oreilly.com.

Encuéntranos en Facebook: http://facebook.com/oreilly

Síguenos en Twitter: http://twitter.com/oreillymedia

Míranos en YouTube: http://www.youtube.com/oreillymedia

Agradecimientos

Austin Parker

Un agradecimiento especial a todas las personas de O'Reilly que han contribuido a hacerlo posible: nuestras editoras, Sarah Grey, Virginia Wilson y Katherine Tozer; el personal de producción, que ha trabajado incansablemente indexando, revisando, redibujando y asegurándose de que todo encaja en la página. Gracias a nuestros revisores técnicos por sus ideas y comentarios; ¡habéis hecho de éste un libro mejor! También me gustaría dar las gracias a Ben Sigelman y al resto del equipo de Lightstep por todo su apoyo; de verdad, sin vosotros, nada de esto habría sucedido.

Me gustaría dar las gracias a mis padres, por tenerme, y a mi padre por ser una inspiración diaria. Os quiero a los dos. A mi mujer: <3.

En solidaridad, Austin.

Daniel Spoonhower

Me gustaría dar las gracias a todos los que trabajan en Lightstep por apoyarnos a Austin y a mí en este trabajo, y especialmente a los que respondieron a mis numerosas preguntas sobre su experiencia en la aplicación y el uso del trazado. Me gustaría dar las gracias a Bob Harper y a Guy Blelloch por ayudarme a comprender el valor de escribir con claridad (y por darme algo de práctica para escribir con un plazo de entrega). También me gustaría dar las gracias a mi familia por ayudarme a encontrar tiempo para trabajar en este libro.

Rebecca Isaacs

Me gustaría agradecer la experiencia, los consejos y las buenas ideas de mis colegas, muchos de los cuales tienen grandes expectativas sobre la utilidad del rastreo distribuido en entornos de producción. También me gustaría dar las gracias a Paul Barham por sus ideas y sabiduría sobre el rastreo y el análisis de sistemas distribuidos.

¹ [Sig19]