Nota. traducir: La autora de este material es Cindy Sridharan, ingeniera de imgix que se especializa en desarrollo de API y, en particular, pruebas de microservicios. En este material comparte su visión detallada de los problemas actuales en el campo del rastreo distribuido, donde, en su opinión, faltan herramientas verdaderamente efectivas para resolver problemas urgentes.
[Ilustración tomada de sobre el rastreo distribuido.]
Se cree que los difícil de implementar y su rentabilidad . Hay muchas razones por las que el rastreo es problemático, a menudo citando el trabajo involucrado en la configuración de cada componente del sistema para transmitir los encabezados apropiados con cada solicitud. Aunque este problema existe, de ninguna manera es insuperable. Por cierto, esto no explica por qué a los desarrolladores no les gusta mucho el rastreo (incluso cuando ya está funcionando).
El principal desafío del rastreo distribuido no es recopilar datos, estandarizar formatos para distribuir y presentar resultados o determinar cuándo, dónde y cómo tomar muestras. no estoy tratando de imaginar trivial Estos "problemas de comprensibilidad" son, de hecho, bastante importantes desde el punto de vista técnico y (si consideramos el código verdaderamente abierto). ) desafíos políticos que deben superarse para que estos problemas se consideren resueltos.
Sin embargo, si imaginamos que todos estos problemas están resueltos, existe una alta probabilidad de que nada cambie significativamente en términos de experiencia del usuario final. Es posible que el rastreo aún no sea de utilidad práctica en los escenarios de depuración más comunes, incluso después de que se haya implementado.
Un rastro tan diferente
El rastreo distribuido incluye varios componentes dispares:
- equipar aplicaciones y middleware con herramientas de control;
- transferencia de contexto distribuido;
- colección de huellas;
- almacenamiento de trazas;
- su extracción y visualización.
Se habla mucho sobre el rastreo distribuido, que tiende a tratarlo como una especie de operación unaria cuyo único propósito es ayudar a diagnosticar completamente el sistema. Esto se debe en gran medida a cómo se han formado históricamente las ideas sobre el rastreo distribuido. EN , realizado cuando se abrieron las fuentes Zipkin, se mencionó que [Zipkin] hace que Twitter sea más rápido. También se promocionaron las primeras ofertas comerciales de rastreo como .
Nota. traducir: Para facilitar la comprensión del texto adicional, definamos dos términos básicos según :
- Lapso — el elemento básico del rastreo distribuido. Es una descripción de un determinado flujo de trabajo (por ejemplo, una consulta de base de datos) con un nombre, horas de inicio y finalización, etiquetas, registros y contexto.
- Los tramos suelen contener enlaces a otros tramos, lo que permite combinar varios tramos en Trace — visualización de la vida de una solicitud a medida que avanza a través de un sistema distribuido.
Los seguimientos contienen datos increíblemente valiosos que pueden ayudar con tareas como pruebas de producción, pruebas de recuperación ante desastres, pruebas de inyección de errores, etc. De hecho, algunas empresas ya utilizan el rastreo con fines similares. Empecemos con Tiene otros usos además de simplemente mover tramos al sistema de almacenamiento:
- Por ejemplo, Uber rastrear resultados para diferenciar entre tráfico de prueba y tráfico de producción.
- Facebook rastrear datos para el análisis de rutas críticas y para el cambio de tráfico durante las pruebas periódicas de recuperación ante desastres.
- También red social Cuadernos Jupyter que permiten a los desarrolladores ejecutar consultas arbitrarias sobre los resultados del seguimiento.
- Adherentes (Inyección de fallas impulsada por linaje) trazas distribuidas para pruebas con inyección de errores.
Ninguna de las opciones enumeradas anteriormente se aplica completamente al escenario. depuración, durante el cual el ingeniero intenta resolver el problema mirando la traza.
Cuando se trata de todavia llega al script de depuración, la interfaz principal sigue siendo el diagrama vista de seguimiento (aunque algunos también lo llaman "Gráfico de gantt" o "diagrama de cascada"). Bajo vista de seguimiento я todos los tramos y los metadatos que los acompañan y que en conjunto conforman el seguimiento. Cada sistema de rastreo de código abierto, así como cada solución de rastreo comercial, ofrece una vista de seguimiento Interfaz de usuario para visualizar, detallar y filtrar trazas.
El problema con todos los sistemas de rastreo que he visto hasta ahora es que el resultado visualización (traceview) Refleja casi por completo las características del proceso de generación de trazas. Incluso cuando se proponen visualizaciones alternativas: mapas de calor, topologías de servicios, histogramas de latencia, en última instancia se reducen a vista de seguimiento.
En el pasado yo que la mayoría de las "innovaciones" en el seguimiento de UI/UX parecen limitarse a Metadatos adicionales en seguimiento, invirtiendo en ellos información con alta cardinalidad. (alta cardinalidad) o proporcionar la capacidad de profundizar en tramos específicos o ejecutar consultas inter e intratraza. En este caso, vista de seguimiento sigue siendo la principal herramienta de visualización. Mientras continúe esta situación, el seguimiento distribuido ocupará (en el mejor de los casos) el cuarto lugar como herramienta de depuración, después de las métricas, los registros y los seguimientos de pila, y en el peor de los casos resultará ser una pérdida de dinero y tiempo.
Problema con la vista de seguimiento
Propósito vista de seguimiento — proporcionar una imagen completa del movimiento de una única solicitud a través de todos los componentes del sistema distribuido con el que está relacionada. Algunos sistemas de seguimiento más avanzados le permiten profundizar en tramos individuales y ver un desglose a lo largo del tiempo. dentro un proceso (cuando los tramos tienen límites funcionales).
La premisa básica de la arquitectura de microservicios es la idea de que la estructura organizativa crece con las necesidades de la empresa. Los defensores de los microservicios argumentan que distribuir diversas tareas comerciales en servicios individuales permite que equipos de desarrollo pequeños y autónomos controlen todo el ciclo de vida de dichos servicios, dándoles la capacidad de construir, probar e implementar esos servicios de forma independiente. Sin embargo, la desventaja de esta distribución es la pérdida de información sobre cómo interactúa cada servicio con los demás. En tales condiciones, el rastreo distribuido pretende ser una herramienta indispensable para depuración interacciones complejas entre servicios.
Si tú realmente , entonces ni una sola persona es capaz de retenerlo en su cabeza. полную imagen. De hecho, desarrollar una herramienta basada en el supuesto de que es incluso posible es una especie de antipatrón (un enfoque ineficaz e improductivo). Idealmente, la depuración requiere una herramienta que ayude limita tu área de búsqueda, de modo que los ingenieros puedan centrarse en un subconjunto de dimensiones (servicios/usuarios/hosts, etc.) relevantes para el escenario del problema que se está considerando. Al determinar la causa de una falla, no se requiere que los ingenieros comprendan lo que sucedió durante la todos los servicios a la vez, ya que tal requisito contradeciría la idea misma de arquitectura de microservicios.
Sin embargo, traceview es exactamente Este. Sí, algunos sistemas de rastreo ofrecen vistas de rastreo comprimidas cuando la cantidad de tramos en el rastreo es tan grande que no se pueden mostrar en una sola visualización. Sin embargo, debido a la gran cantidad de información contenida incluso en una visualización tan simplificada, los ingenieros aún forzado “tamizarlo”, reduciendo manualmente la selección a un conjunto de servicios que son fuentes de problemas. Desafortunadamente, en este campo las máquinas son mucho más rápidas que los humanos, menos propensas a errores y sus resultados son más repetibles.
Otra razón por la que creo que traceview es incorrecto es porque no es bueno para la depuración basada en hipótesis. En esencia, la depuración es iterativo un proceso que comienza con una hipótesis, seguido de la verificación de varias observaciones y hechos obtenidos del sistema a lo largo de diferentes vectores, conclusiones/generalizaciones y una evaluación adicional de la verdad de la hipótesis.
Oportunidad rápido y barato Probar hipótesis y mejorar el modelo mental en consecuencia es piedra angular depuración Cualquier herramienta de depuración debe ser interactivo y reducir el espacio de búsqueda o, en el caso de una pista falsa, permitir al usuario retroceder y centrarse en un área diferente del sistema. La herramienta perfecta hará esto proactivamente, llamando inmediatamente la atención del usuario sobre posibles áreas problemáticas.
Ay vista de seguimiento No se puede llamar una herramienta con una interfaz interactiva. Lo mejor que puede esperar al usarlo es encontrar alguna fuente de mayor latencia y observar todas las posibles etiquetas y registros asociados con ella. Esto no ayuda al ingeniero a identificar patrones en el tráfico, como las características específicas de la distribución de retrasos, o detectar correlaciones entre diferentes mediciones. puede ayudar a solucionar algunos de estos problemas. En realidad, Análisis exitoso que utiliza el aprendizaje automático para identificar tramos anómalos e identificar un subconjunto de etiquetas que pueden estar asociadas con un comportamiento anómalo. Sin embargo, todavía tengo que ver visualizaciones convincentes de hallazgos de aprendizaje automático o minería de datos aplicados a tramos que sean significativamente diferentes de una vista de seguimiento o un DAG (gráfico acíclico dirigido).
Los tramos son de nivel demasiado bajo
El problema fundamental con traceview es que se extiende son primitivas de muy bajo nivel tanto para el análisis de latencia como para el análisis de causa raíz. Es como analizar comandos de procesadores individuales para intentar resolver una excepción, sabiendo que existen herramientas de nivel mucho más alto, como el rastreo, con las que es mucho más conveniente trabajar.
Además, me tomaré la libertad de afirmar lo siguiente: idealmente, no necesitamos imagen completa ocurrió durante el ciclo de vida de la solicitud, que está representado por herramientas de seguimiento modernas. En cambio, se requiere alguna forma de abstracción de nivel superior que contenga información sobre lo que fué mal (similar a backtrace), junto con algo de contexto. En lugar de ver la traza completa, prefiero verla. часть, donde sucede algo interesante o inusual. Actualmente, la búsqueda se realiza manualmente: el ingeniero recibe la traza y analiza de forma independiente los vanos en busca de algo interesante. El enfoque de las personas que miran los tramos en trazas individuales con la esperanza de detectar actividad sospechosa no escala en absoluto (especialmente cuando tienen que entender todos los metadatos codificados en diferentes tramos, como el ID del tramo, el nombre del método RPC, la duración del tramo). 'a, registros, etiquetas, etc.).
Alternativas a traceview
Los resultados del seguimiento son más útiles cuando se pueden visualizar de una manera que proporcione información no trivial sobre lo que está sucediendo en partes interconectadas del sistema. Hasta que esto suceda, el proceso de depuración sigue siendo en gran medida inerte y depende de la capacidad del usuario para notar las correlaciones correctas, verificar las partes correctas del sistema o juntar las piezas del rompecabezas, a diferencia de instrumento, ayudando al usuario a formular estas hipótesis.
No soy diseñador visual ni especialista en UX, pero en la siguiente sección quiero compartir algunas ideas sobre cómo podrían verse estas visualizaciones.
Centrarse en servicios específicos
En un momento en el que la industria se consolida en torno a las ideas , parece razonable que los equipos individuales den prioridad a garantizar que sus servicios estén alineados con estos objetivos. Resulta que orientado al servicio La visualización es la más adecuada para este tipo de equipos.
Los rastros, especialmente sin muestreo, son un tesoro de información sobre cada componente de un sistema distribuido. Esta información puede enviarse a un astuto procesador que proporcionará a los usuarios orientado al servicio Hallazgos que se pueden identificar de antemano, incluso antes de que el usuario mire las huellas:
- Diagramas de distribución de latencia solo para solicitudes muy destacadas (solicitudes atípicas);
- Diagramas de distribución de retrasos para casos en los que no se alcanzan los objetivos de SLO del servicio;
- Las etiquetas más "comunes", "interesantes" y "extrañas" en las consultas que con mayor frecuencia se repiten;
- Desglose de latencia para los casos en los que dependencias los servicios no logran sus objetivos de SLO;
- Desglose de latencia para varios servicios posteriores.
Algunas de estas preguntas simplemente no son respondidas por las métricas integradas, lo que obliga a los usuarios a examinar los tramos. Como resultado, tenemos un mecanismo extremadamente hostil al usuario.
Esto plantea la pregunta: ¿qué pasa con las interacciones complejas entre diversos servicios controlados por diferentes equipos? ¿No es así? vista de seguimiento ¿No se considera la herramienta más adecuada para poner de relieve tal situación?
Los desarrolladores móviles, los propietarios de servicios sin estado, los propietarios de servicios con estado administrados (como bases de datos) y los propietarios de plataformas pueden estar interesados en algo más. presentación Sistema distribuido; vista de seguimiento Es una solución demasiado genérica para estas necesidades fundamentalmente diferentes. Incluso en una arquitectura de microservicios muy compleja, los propietarios de servicios no necesitan un conocimiento profundo de más de dos o tres servicios ascendentes y descendentes. Básicamente, en la mayoría de los escenarios, los usuarios sólo necesitan responder preguntas sobre conjunto limitado de servicios.
Es como mirar un pequeño subconjunto de servicios a través de una lupa con el único fin de escudriñarlos. Esto permitirá al usuario hacer preguntas más urgentes sobre las complejas interacciones entre estos servicios y sus dependencias inmediatas. Esto es similar al backtrace en el mundo de los servicios, donde el ingeniero sabe que mal, y también tiene cierta comprensión de lo que está sucediendo en los servicios circundantes para comprender por qué.
El enfoque que estoy promoviendo es exactamente lo opuesto al enfoque de arriba hacia abajo basado en la vista de seguimiento, donde el análisis comienza con el seguimiento completo y luego avanza gradualmente hasta tramos individuales. Por el contrario, un enfoque ascendente comienza analizando un área pequeña cercana a la causa potencial del incidente y luego expande el espacio de búsqueda según sea necesario (con el potencial de incorporar otros equipos para analizar una gama más amplia de servicios). El segundo enfoque es más adecuado para probar rápidamente las hipótesis iniciales. Una vez que se obtengan resultados concretos, será posible pasar a un análisis más centrado y detallado.
Construyendo una topología
Las vistas específicas del servicio pueden ser increíblemente útiles si el usuario sabe ¿qué un servicio o grupo de servicios es responsable de aumentar la latencia o causar errores. Sin embargo, en un sistema complejo, identificar el servicio infractor puede ser una tarea no trivial durante una falla, especialmente si los servicios no informaron mensajes de error.
Crear una topología de servicio puede ser de gran ayuda para determinar qué servicio está experimentando un aumento en las tasas de error o un aumento en la latencia que está causando que el servicio se degrade notablemente. Cuando hablo de construir una topología, no me refiero mapa de servicios, mostrando todos los servicios disponibles en el sistema y conocidos por su . Esta vista no es mejor que la vista de seguimiento basada en un gráfico acíclico dirigido. En lugar de eso me gustaría ver topología de servicio generada dinámicamente, en función de ciertos atributos como la tasa de error, el tiempo de respuesta o cualquier parámetro definido por el usuario que ayude a aclarar la situación con servicios sospechosos específicos.
Tomemos un ejemplo. Imaginemos un sitio de noticias hipotético. Servicio de página de inicio (página delantera) intercambia datos con Redis, con un servicio de recomendación, con un servicio de publicidad y un servicio de vídeo. El servicio de video toma videos de S3 y metadatos de DynamoDB. El servicio de recomendación recibe metadatos de DynamoDB, carga datos de Redis y MySQL y escribe mensajes en Kafka. El servicio de publicidad recibe datos de MySQL y escribe mensajes en Kafka.
A continuación se muestra una representación esquemática de esta topología (muchos programas de enrutamiento comerciales crean la topología). Puede resultar útil si necesita comprender las dependencias de los servicios. Sin embargo, durante depuración, cuando un determinado servicio (por ejemplo, un servicio de vídeo) muestra un mayor tiempo de respuesta, dicha topología no es muy útil.
Diagrama de servicio de un sitio de noticias hipotético.
El siguiente diagrama sería más adecuado. Hay un problema con el servicio. (video) representado justo en el centro. El usuario lo nota inmediatamente. De esta visualización, queda claro que el servicio de video está funcionando de manera anormal debido a un aumento en el tiempo de respuesta de S3, lo que afecta la velocidad de carga de parte de la página principal.
Topología dinámica que muestra sólo servicios "interesantes"
Las topologías generadas dinámicamente pueden ser más eficientes que los mapas de servicios estáticos, especialmente en infraestructuras elásticas y de escalamiento automático. La capacidad de comparar y contrastar topologías de servicios permite al usuario hacer preguntas más relevantes. Es más probable que preguntas más precisas sobre el sistema conduzcan a una mejor comprensión de cómo funciona el sistema.
Visualización comparativa
Otra visualización útil sería una visualización comparativa. Actualmente, las trazas no son muy adecuadas para comparaciones en paralelo, por lo que las comparaciones suelen ser se extiende. Y la idea principal de este artículo es precisamente que los intervalos son de nivel demasiado bajo para extraer la información más valiosa de los resultados del seguimiento.
Comparar dos trazas no requiere visualizaciones fundamentalmente nuevas. De hecho, algo así como un histograma que represente la misma información que una vista de seguimiento es suficiente. Sorprendentemente, incluso este método simple puede dar muchos más frutos que simplemente estudiar dos trazas por separado. Aún más poderosa sería la posibilidad visualizar comparación de rastros juntos. Sería extremadamente útil ver cómo un cambio en la configuración de la base de datos implementado recientemente para habilitar GC (recolección de basura) afecta el tiempo de respuesta de un servicio descendente en una escala de varias horas. Si lo que estoy describiendo aquí suena como un análisis A/B del impacto de los cambios en la infraestructura en muchos servicios utilizando los resultados del rastreo, entonces no estás muy lejos de la verdad.
Conclusión
No cuestiono la utilidad del rastreo en sí. Sinceramente creo que no existe otro método de recogida de datos tan rico, causal y contextual como el contenido en una traza. Sin embargo, también creo que todas las soluciones de rastreo utilizan estos datos de manera extremadamente ineficiente. Mientras las herramientas de rastreo permanezcan estancadas en la representación de la vista de rastreo, su capacidad para aprovechar al máximo la información valiosa que se puede extraer de los datos contenidos en los rastreos será limitada. Además, existe el riesgo de seguir desarrollando una interfaz visual completamente hostil y poco intuitiva que limitará gravemente la capacidad del usuario para solucionar errores en la aplicación.
Depurar sistemas complejos, incluso con las herramientas más modernas, es increíblemente difícil. Las herramientas deberían ayudar al desarrollador a formular y probar una hipótesis, proporcionando activamente información relevante, identificando valores atípicos y observando características en la distribución de retrasos. Para que el rastreo se convierta en la herramienta elegida por los desarrolladores al solucionar fallas de producción o resolver problemas que abarcan múltiples servicios, se necesitan visualizaciones e interfaces de usuario originales que sean más consistentes con el modelo mental de los desarrolladores que crean y operan esos servicios.
Se necesitará un esfuerzo mental significativo para diseñar un sistema que represente las diversas señales disponibles en los resultados del seguimiento de una manera optimizada para facilitar el análisis y la inferencia. Es necesario pensar en cómo abstraer la topología del sistema durante la depuración de una manera que ayude al usuario a superar los puntos ciegos sin mirar trazas o tramos individuales.
Necesitamos buenas capacidades de abstracción y capas (especialmente en la interfaz de usuario). Unos que encajarían bien en un proceso de depuración basado en hipótesis en el que se pueden hacer preguntas y probar hipótesis de forma iterativa. No resolverán automáticamente todos los problemas de observabilidad, pero ayudarán a los usuarios a agudizar su intuición y formular preguntas más inteligentes. Pido un enfoque más reflexivo e innovador de la visualización. Aquí existe una perspectiva real de ampliar horizontes.
PD del traductor
Lea también en nuestro blog:
- «";
- «";
- «".
Fuente: habr.com