Teoría del sistema de monitoreo de enlace completo convencional empresarial

1. Antecedentes del problema

Con la popularidad de la arquitectura de microservicios, los servicios se dividen según diferentes dimensiones y una solicitud a menudo involucra múltiples servicios. Las aplicaciones de Internet se basan en diferentes conjuntos de módulos de software. Estos módulos de software pueden ser desarrollados por diferentes equipos, pueden implementarse utilizando diferentes lenguajes de programación y pueden distribuirse en miles de servidores en múltiples centros de datos diferentes. Por lo tanto, existe la necesidad de herramientas que puedan ayudar a comprender el comportamiento del sistema y analizar los problemas de rendimiento, de modo que cuando ocurra una falla, el problema pueda localizarse y resolverse rápidamente.

全链路监控组件Fue en el contexto de tal problema. El más famoso es Google Dapper, mencionado en el documento público de Google . Para comprender el comportamiento de los sistemas distribuidos en este contexto, es necesario monitorear las acciones relacionadas en diferentes aplicaciones y diferentes servidores.

Por lo tanto, en un sistema de arquitectura de microservicio complejo, casi todas las solicitudes de front-end formarán un enlace de llamada de servicio distribuido complejo. La cadena de llamadas completa de una solicitud puede ser como se muestra en la siguiente figura:

a medida que la escala comercial continúa aumentando, los servicios continúan aumentando y se producen cambios frecuentes, enfrentar enlaces de llamadas complejos traerá una serie de problemas:

• ¿Cómo encontrar problemas rápidamente?
• ¿Cómo determinar el alcance del impacto de la falla?
• ¿Cómo clasificar las dependencias de servicios y la racionalidad de las dependencias?
• ¿Cómo analizar los problemas de rendimiento del enlace y la planificación de capacidad en tiempo real?

Al mismo tiempo, prestaremos atención a varios indicadores de rendimiento de cada llamada durante el procesamiento de la solicitud, como el rendimiento (TPS), el tiempo de respuesta, los registros de errores, etc.

• El rendimiento, el rendimiento en tiempo real de los componentes, plataformas y dispositivos físicos correspondientes se puede calcular en función de la topología.
• Tiempo de respuesta, incluyendo el tiempo de respuesta de la llamada global y el tiempo de respuesta de cada servicio.
• Registro de errores, basado en las estadísticas de devolución del servicio del número de excepciones por unidad de tiempo.

El monitoreo del rendimiento de enlace completo muestra varios indicadores desde la dimensión general hasta la dimensión local y muestra de forma centralizada la información de rendimiento de todas las cadenas de llamadas en todas las aplicaciones. Puede medir fácilmente el rendimiento general y local y encontrar fácilmente la fuente de fallas, lo que puede afectar en gran medida acortar la producción Tiempo de resolución de problemas.

Con herramientas de monitoreo de enlace completo, podemos lograr:

• Solicite seguimiento de enlaces y localización rápida de fallos: la información de error se puede localizar rápidamente a través de la cadena de llamadas combinada con registros comerciales.
• Visualización: cada etapa lleva tiempo y se realiza un análisis de rendimiento.
• Optimización de dependencias: disponibilidad de cada enlace de llamada, clasificación de dependencias de servicios y optimización.
• Análisis de datos, optimización de enlaces: se pueden obtener las rutas de comportamiento de los usuarios y el análisis resumido se aplica en muchos escenarios comerciales.

2. Requisitos objetivo

Como se mencionó anteriormente, ¿cuáles son los requisitos objetivo cuando elegimos el componente de monitoreo de enlace completo? También se menciona en Google Dapper, resumido de la siguiente manera:

1. Consumo de rendimiento de las sondas.

El impacto de los servicios de los componentes APM debería ser lo suficientemente pequeño.

El enterramiento de llamadas de servicio en sí causará una pérdida de rendimiento, lo que requiere una baja pérdida de seguimiento de llamadas. En la práctica, una parte de las solicitudes se seleccionará para analizar la ruta de la solicitud configurando la frecuencia de muestreo. En algunos servicios altamente optimizados, incluso una pequeña pérdida será fácilmente perceptible y puede obligar al equipo de implementación del servicio en línea a cerrar el sistema de seguimiento.

2. Intrusión del código

Es decir, como componente empresarial, debe tener la menor o ninguna intrusión posible en otros sistemas empresariales, ser transparente para los usuarios y reducir la carga para los desarrolladores.

Para los programadores de aplicaciones, no es necesario saber que existe un sistema de seguimiento. Si un sistema de seguimiento quiere ser eficaz, debe depender de la cooperación activa de los desarrolladores de la aplicación. Entonces este sistema de seguimiento es demasiado frágil. Los problemas de las aplicaciones a menudo son causados ​​por errores o negligencia en el código implantado en la aplicación por el sistema de seguimiento. Es por eso que no puede satisfacer 无所不在的部署la necesidad ".

3. Escalabilidad

Un excelente sistema de seguimiento de llamadas debe admitir una implementación distribuida y tener una buena escalabilidad. Cuantos más componentes se puedan admitir, mejor. O proporcione una API de desarrollo de complementos conveniente. Para algunos componentes que no están monitoreados, los desarrolladores de aplicaciones también pueden expandirlos por su cuenta.

4. Análisis de datos

El análisis de datos debe ser rápido y las dimensiones de análisis deben ser tantas como sea posible. El sistema de seguimiento puede proporcionar retroalimentación de información con la suficiente rapidez para responder rápidamente a condiciones anormales en el entorno de producción. El análisis exhaustivo puede evitar el desarrollo secundario.

3. Módulo de funciones

Un sistema general de monitoreo de enlace completo se puede dividir aproximadamente en cuatro módulos funcionales:

1. Puntos enterrados y registros generados.

Los puntos enterrados son la información de contexto del sistema en el nodo actual, que se puede dividir en:

• Punto de entierro del cliente
• Punto de enterramiento del lado del servidor
• Punto de entierro bidireccional entre cliente y servidor

Los troncos enterrados suelen contener el siguiente contenido:

• ID de seguimiento
• ID de intervalo
• La hora de inicio de la llamada.
• tipo de acuerdo
• IP y puerto de la persona que llama
• Nombre del servicio solicitado
• La llamada lleva tiempo.
• Resultado de la llamada
• Información de excepción, etc.

Al mismo tiempo, se reservan campos escalables para prepararse para la próxima expansión;

No puede causar una carga en el desempeño: ¡Es difícil promover algo en la empresa que no ha sido verificado pero que afectará el desempeño!

Debido a que es necesario escribir registros, cuanto mayor sea el QPS empresarial, mayor será el impacto en el rendimiento. Resuelto mediante muestreo y registro asincrónico.

2. Recopilar y almacenar registros

Admite principalmente soluciones de recopilación de registros distribuidos y agrega MQ como búfer:

• Hay un demonio en cada máquina para recopilar registros. El proceso de negocio envía su propio seguimiento al demonio, y el demonio envía el seguimiento recopilado al nivel superior;
• El recopilador multinivel, similar a la arquitectura pub/sub, puede equilibrar la carga;
• Realizar análisis en tiempo real y almacenamiento fuera de línea de datos agregados;
• El análisis fuera de línea requiere resumir los registros de la misma cadena de llamadas.

3. Analizar y recopilar estadísticas sobre los datos y la puntualidad del enlace de llamadas.

• Análisis de seguimiento de la cadena de llamadas: recopile tramos con el mismo TraceID y ordénelos por tiempo para crear una línea de tiempo. Encadenar el ParentID es la pila de llamadas.
  Lanza una excepción o agota el tiempo de espera e imprime TraceID en el registro. Utilice TraceID para consultar la cadena de llamadas y localizar problemas.
• Métricas de dependencia:
  • Fuerte dependencia: no llamar interrumpirá directamente el proceso principal
  • Alta dependencia: La probabilidad de llamar a una determinada dependencia en un enlace es alta
  • Dependencias frecuentes: un enlace llama a la misma dependencia muchas veces
• Análisis sin conexión: resuma por TraceID, restaure la relación de llamada a través de Span ID y ParentID y analice la forma del enlace.
• Análisis en tiempo real: analice directamente un solo registro sin resumirlo ni reorganizarlo. Obtenga el QPS actual, retrase.

4. Presentación y apoyo a las decisiones.

4. Google elegante

1. tramo

unidad básica de trabajo

Una llamada de enlace (puede ser RPC, DB, etc. sin restricciones específicas) crea un intervalo y lo identifica con un ID de 64 bits. Uuid es más conveniente. Hay otros datos en el intervalo, como información de descripción, marca de tiempo, clave. -value Información de etiqueta correcta (anotación), parent_id, etc., donde parent-id puede representar la fuente del enlace de llamada de intervalo.

La imagen de arriba ilustra cómo se ve el tramo durante un trazado grande. Dapper registra el nombre del tramo, así como el ID y el ID principal de cada tramo, para reconstruir la relación entre diferentes tramos durante un seguimiento. Si un intervalo no tiene ID principal, se llama root span. Todos los tramos están vinculados a una traza específica y comparten la misma traza 跟踪id.

Estructura de datos abarcada:

type Span struct {
    
    
    TraceID    int64 // 用于标示一次完整的请求id
    Name       string
    ID         int64 // 当前这次调用span_id
    ParentID   int64 // 上层服务的调用span_id  最上层服务parent_id为null
    Annotation []Annotation // 用于标记的时间戳
    Debug      bool
}

2. rastrear

Una colección Span similar a una estructura de árbol representa un seguimiento completo, comenzando desde la solicitud al servidor y terminando con el servidor devolviendo una respuesta. Realiza un seguimiento del consumo de tiempo de cada llamada rpc y tiene un identificador único trace_id. Por ejemplo: un seguimiento del almacenamiento distribuido de big data que ejecuta consta de una de sus solicitudes.

Cada nota de color está marcada con un intervalo, un enlace se identifica de forma única mediante TraceId y el intervalo identifica la información de la solicitud iniciada. Los nodos del árbol son la unidad básica de toda la arquitectura y cada nodo es una referencia al tramo. La conexión entre nodos representa la relación directa entre el tramo y su tramo principal. Aunque el intervalo en el archivo de registro simplemente representa la hora de inicio y finalización del intervalo, son relativamente independientes en toda la estructura del árbol.

3. Anotación

Las anotaciones se utilizan para registrar información relacionada con la solicitud de eventos específicos (como el tiempo). Habrá varias descripciones de anotaciones en un lapso. Generalmente contiene cuatro información de anotaciones:

• cs: Inicio del cliente, lo que indica que el cliente inicia una solicitud.
• sr: recepción del servidor, lo que indica que el servidor recibió la solicitud.
• ss: Envío del servidor, lo que indica que el servidor completó el procesamiento y envió los resultados al cliente.
• cr: Cliente recibido, indica que el cliente ha recibido la información devuelta por el servidor.

Estructura de datos de anotación:

type Annotation struct {
    
    
    Timestamp int64
    Value     string
    Host      Endpoint
    Duration  int32			#持续时间
}

4. Ejemplo de llamada

1. Ejemplo de llamada de solicitud

• Cuando un usuario inicia una solicitud, primero llega al servicio front-end A y luego realiza llamadas RPC al servicio B y al servicio C respectivamente;
• El servicio B responde a A después del procesamiento, pero el servicio C aún necesita interactuar con los servicios back-end D y E antes de regresar al servicio A. Finalmente, el servicio A responde a la solicitud del usuario;

2. Seguimiento del proceso de llamadas

• Cuando llega una solicitud, se genera un TraceID global . Toda la cadena de llamadas se puede conectar a través de TraceID. Un TraceID representa una solicitud.
• Además de TraceID, también se requiere SpanID para registrar la relación padre-hijo que llama . Cada servicio registrará la identificación principal y la identificación del intervalo, a través de los cuales se puede organizar la relación padre-hijo de una cadena de llamadas completa .
• Un tramo sin identificación principal se convierte en el tramo raíz y puede considerarse como la entrada de la cadena de llamadas.
• Todos estos ID pueden representarse mediante enteros de 64 bits únicos a nivel mundial;
• TraceID y SpanID deben transmitirse de forma transparente para cada solicitud durante todo el proceso de llamada .
• Cada servicio registra el TraceID y el SpanID adjuntos a la solicitud como identificación principal, y también registra el SpanID generado por él mismo.
• Para ver una llamada completa, solo necesita encontrar todos los registros de llamadas según TraceID y luego organizar toda la relación padre-hijo de la llamada a través de la identificación principal y la identificación del intervalo .

3. Trabajo central de la cadena de llamadas

• Genere datos de la cadena de llamadas, entierre todas las aplicaciones en todo el proceso de llamadas y genere registros.
• Llame a la recopilación de datos en cadena para recopilar datos de registro en cada aplicación.
• Llame al almacenamiento y consulta de datos en cadena para almacenar los datos recopilados. Dado que la cantidad de datos de registro es generalmente grande, no solo debe poder almacenarlos, sino también proporcionar consultas rápidas.
• Cálculo, almacenamiento y consulta de indicadores, realice varios cálculos de indicadores en los datos de registro recopilados y guarde los resultados del cálculo.
• La función de alarma proporciona varias funciones de advertencia de umbral.

4. Arquitectura de implementación general
   

• Genere registros de cadena de llamadas a través de AGENTE.
• Recopile registros para kafka a través de logstash.
• Kafka es responsable de proporcionar datos a los consumidores intermedios.
• Storm calcula los resultados del indicador agregado y cae en es.
• Storm extrae datos de seguimiento y los coloca en es para proporcionar consultas más complejas. Por ejemplo, al consultar la cadena de llamadas a través de la dimensión de tiempo, puede consultar rápidamente todos los traceID coincidentes y luego ir a Hbase para verificar los datos basados ​​en estos traceID.
• Logstash extrae datos sin procesar de Kafka a hbase. La clave de fila de hbase es traceID y las consultas basadas en traceID son muy rápidas.

5. Implementación no intrusiva de AGENT
   A través de la implementación no intrusiva del agente AGENT, la medición del rendimiento y la lógica de negocios están completamente separadas, y se puede medir el tiempo de ejecución de cualquier método de cualquier clase, lo que mejora en gran medida la eficiencia de recolección y reduce los costos de operación y mantenimiento. Según la duración del servicio, se divide principalmente en dos categorías de agentes:

• AGENTE en servicio, este método utiliza el mecanismo de agente de Java para recopilar datos sobre la información del nivel de llamada del método dentro del servicio, como el tiempo de llamada al método, los parámetros de entrada, los parámetros de salida y otra información.
• AGENTE de servicios cruzados, esta situación requiere un soporte perfecto para los marcos RPC convencionales en forma de complementos. Y proporcionando especificaciones de datos estándar para adaptarse a marcos RPC personalizados:

(1) soporte Dubbo,
(2) soporte Rest,
(3) soporte RPC personalizado;

6. Beneficios del monitoreo de la cadena de llamadas

• Comprender con precisión el estado de implementación de las aplicaciones de producción de primera línea;
• Desde la perspectiva del rendimiento de todo el proceso de la cadena de llamadas, identifique las cadenas de llamadas clave y optimícelas;
• Proporcionar datos de rendimiento rastreables para cuantificar el valor comercial del departamento de operación y mantenimiento de TI;
• Localice rápidamente problemas de rendimiento del código y ayude a los desarrolladores a optimizarlo continuamente;
• Ayude a los desarrolladores a realizar pruebas de caja blanca y acortar el período de estabilidad en línea del sistema.

5. Comparación de planes

La mayoría de los modelos teóricos de seguimiento de enlace completo del mercado se basan en el documento Google Dapper, un seguimiento distribuido donde florecen cien flores.

• Zipkin es un sistema de seguimiento de código abierto desarrollado originalmente por Twitter y de código abierto en 2012. Zipkin se utiliza ampliamente y ha influido en muchas generaciones posteriores. Su cabezal de transmisión es X-B3.
• Skywalking fue desarrollado por chinos y posteriormente donado a un proyecto de código abierto de la Fundación Apache. Ahora es un proyecto de alto nivel de la Fundación Apache.
• Pinpoint fue desarrollado por Naver en 2012 y de código abierto en 2015. Pinpoint funciona con java, php y python.
• Jaeger fue desarrollado por primera vez por Uber y de código abierto en 2017, y posteriormente fue donado a la Fundación CNCF.
• OpenCensus fue iniciado por Google, originalmente era la plataforma de seguimiento interna de Google y luego de código abierto.
• OpenTracing está alojado en CNCF y tiene una biblioteca de instrumentación relativamente completa.

1. dirección de zipkin
   github: https://github.com/openzipkin/zipkin

   zipkin es un sistema de seguimiento distribuido que puede ayudarlo a recopilar datos sobre el tiempo necesario para resolver problemas en la arquitectura de su servicio. Sus funciones incluyen recopilar y encontrar estos datos. Si hay un ID de seguimiento en el archivo de registro, puede saltar directamente a él. De lo contrario, las consultas pueden basarse en propiedades como el servicio, el nombre de la operación, la etiqueta y la duración. Por ejemplo, el porcentaje de tiempo dedicado al servicio y qué aspectos de la operación fallaron. Se caracteriza por ser liviano y sencillo de utilizar e implementar.
   
   zipkin también proporciona una interfaz de usuario que muestra la cantidad de solicitudes de seguimiento pasadas por cada aplicación. Esto ayuda a identificar comportamientos agregados, incluidas rutas incorrectas o llamadas a servicios obsoletos.
   
   Las aplicaciones requieren "instrumentación" para informar los datos de seguimiento a Zipkin. Por lo general, esto significa configurar una biblioteca para el seguimiento y la detección. Los métodos más populares para reportar datos a Zipkin son a través de http o Kafka, aunque existen muchas otras opciones como Apache, ActiveMQ, gRPC y RabbitMQ. Hay muchas formas de almacenar datos para la interfaz de usuario, como almacenarlos en la memoria o conservarlos utilizando un backend compatible como Apache Cassandra o Elasticsearch.

2. dirección de github de skywalking
   : https://github.com/apache/incubator-skywalking

   Skywalking es un sistema local de seguimiento de cadena de llamadas de código abierto que incluye funciones de monitoreo, seguimiento y diagnóstico. Ahora se ha unido a la incubadora Apache y está especialmente diseñado para arquitecturas de microservicios, locales en la nube y basadas en contenedores (Docker, Kubernetes, Mesos).

   Las funciones principales son las siguientes:

    1）服务、服务实例、端点指标数据分析
    2）根本原因分析，在运行时评测代码
    3）服务拓扑图分析
    4）服务、服务实例和端点依赖性分析
    5）检测到慢速服务和终结点
    6）性能优化
    7）分布式跟踪和上下文传播
    8）数据库访问度量。检测慢速数据库访问语句（包括SQL语句）。
    9）报警
    10）浏览器性能监视
   

   

3. determinar con precisión

   Dirección de Github: https://github.com/naver/pinpoint

   Pinpoint es una herramienta coreana de análisis de cadena de llamadas y monitoreo de aplicaciones de código abierto basada en inyección de código de bytes. Pinpoint proporciona una solución que ayuda a analizar la estructura general de un sistema y cómo sus componentes están conectados entre sí mediante el seguimiento de transacciones en una aplicación distribuida.

   Las funciones son las siguientes:

    1）一目了然地了解应用程序拓扑
    2）实时监视应用程序
    3）获得每个事务的代码级可见性
    4）安装APM代理程序，无需更改一行代码
    5）对性能的影响最小（资源使用量增加约3%）
   

   Interfaz de usuario visual de Pinpoint:
   
   

4. OpenTelemetry
   OpenTelemetry es un conjunto de protocolos estándar para la observabilidad nativa de la nube liderado por CNCF, su nombre completo es: OpenTelemetry Protocol, u OTLP para abreviar, tiene como objetivo estandarizar la generación y recopilación de datos de telemetría. Los datos de telemetría incluyen registros, métricas y seguimientos.

   Es una colección de API, SDK y bibliotecas cliente para generar datos de telemetría a partir del código de la aplicación. Los datos que recopila mediante OpenTelemetry son independientes del proveedor y se pueden exportar en una variedad de formatos.

   La mayor ventaja de utilizar OpenTelemetry es que tienes la libertad de elegir el backend que prefieras. No está vinculado a un proveedor y los equipos de ingeniería pueden utilizar una única tecnología para generar datos de telemetría.

   Para integrar OpenTelemetry con el código de su aplicación, puede utilizar la biblioteca cliente de OpenTelemetry para el lenguaje de programación que desee. OpenTelemetry también proporciona un recopilador llamado recopilador OTel (OpenTelemetry) que se puede utilizar para procesar y exportar datos de telemetría en múltiples formatos.
   

Referencias principales para la solución de monitoreo de enlace completo:

• Rendimiento de la sonda: principalmente el impacto del agente en el rendimiento del servicio, la CPU y la memoria. La escala y la dinámica de los microservicios aumentan considerablemente el costo de la recopilación de datos.
• Escalabilidad del recopilador: capacidad de escalar horizontalmente para admitir clústeres de servidores a gran escala.
• Análisis integral de datos de enlaces de llamadas: proporciona visibilidad a nivel de código para localizar fácilmente puntos de falla y cuellos de botella.
• Transparente para el desarrollo, fácil de cambiar: agregue nuevas funciones sin modificar el código, fácil de habilitar o deshabilitar.
• Topología de aplicación de cadena de llamadas completa: detecte automáticamente la topología de la aplicación para ayudarle a determinar la arquitectura de la aplicación.

1. Rendimiento de la sonda

Conclusión: la sonda Skywalking tiene el menor impacto en el rendimiento, y el rendimiento de Zipkin está en el medio. Las sondas puntuales tienen un mayor impacto en el rendimiento

Preste más atención al rendimiento de la sonda. Después de todo, el posicionamiento APM sigue siendo una herramienta. Si el rendimiento se reduce a más de la mitad después de habilitar el componente de monitoreo de enlace, es inaceptable. Se realizaron pruebas de estrés en skywalking, zipkin y pinpoint, y se compararon con la línea de base (sin utilizar sondas).

Se seleccionó una aplicación común basada en Spring, que incluye Spring Boot, Spring MVC, cliente redis y mysql. Al monitorear esta aplicación, para cada rastro, la sonda capturará 5 tramos (1 Tomcat, 1 SpringMVC, 2 Jedis, 1 Mysql). Esto es básicamente lo mismo que la aplicación de prueba de skywalkingtest.

Se simularon tres tipos de usuarios concurrentes: 500, 750 y 1000. Utilice jmeter para realizar pruebas, cada hilo envía 30 solicitudes y establece el tiempo de pensamiento en 10 ms. La tasa de muestreo utilizada es 1, es decir, 100%, que puede ser diferente a la de producción. La frecuencia de muestreo predeterminada de pinpoint es 20, que es 50%, y se puede cambiar al 100% configurando el archivo de configuración del agente. El valor predeterminado de zipkin también es 1. Combinados, hay 12 tipos en total. Veamos la siguiente tabla de resumen:
Como se puede ver en la tabla anterior, entre los tres componentes de monitoreo de enlaces, la sonda de Skywalking tiene el menor impacto en el rendimiento y el rendimiento de Zipkin está en el medio. El impacto de la sonda puntual en el rendimiento es obvio: cuando hay 500 usuarios simultáneos, el rendimiento del servicio de prueba se reduce de 1385 a 774, lo que tiene un gran impacto. Luego veamos el impacto en la CPU y la memoria. La prueba de estrés realizada en el servidor interno mostró que el impacto en la CPU y la memoria estaba casi dentro del 10%.

2. Escalabilidad del recopilador

Conclusión: la escalabilidad del recopilador se puede expandir horizontalmente
, lo que permite la expansión horizontal para admitir clústeres de servidores a gran escala.

1. zipkin
   desarrolla zipkin-Server (en realidad es un paquete listo para usar), zipkin-agent se comunica con zipkin-Server a través de http o mq. La comunicación http afectará el acceso normal, por lo que se recomienda comunicarse de forma asincrónica según mq. .zipkin-Server consume suscribiéndose a temas específicos. Por supuesto, esto es escalable, con múltiples instancias de zipkin-Server consumiendo información de monitoreo de forma asincrónica en mq.
   
2. skywalking
   El recopilador de Skywalking admite dos métodos de implementación: modo independiente y en clúster. La comunicación entre el recopilador y el agente utiliza gRPC.
3. De manera similar a pinpoint
   , pinpoint también admite implementación en clúster e independiente. El agente de localización envía información de enlace al recopilador a través del marco de comunicación de ahorro.

3. Análisis completo de datos de enlaces de llamadas.

Conclusión: análisis completo de datos de enlaces de llamadas de nivel detallado pinpoint>skywalking>zipkin , que proporciona visibilidad a nivel de código para localizar fácilmente puntos de falla y cuellos de botella.

1. La granularidad de monitoreo de enlaces de zipkin
   zipkin no es relativamente tan buena. En la figura anterior, puede ver que la cadena de llamadas es específica del nivel de interfaz y no hay más información de llamada involucrada.
2. skywalking
   skywalking también admite más de 20 middleware, marcos y bibliotecas de clases, como dubbo convencional, Okhttp, así como DB y middleware de mensajes. El análisis de llamadas de enlaces de Skywalking en la figura anterior es relativamente simple: la puerta de enlace llama al servicio de usuario y, dado que admite muchos middlewares, el análisis de llamadas de enlaces de Skywalking es más completo que zipkin.
3. pinpoint
   pinpoint debería ser el componente de análisis de datos más completo entre estos tres componentes de APM. Proporciona visibilidad a nivel de código para localizar fácilmente puntos de falla y cuellos de botella. Como se puede ver en la figura anterior, se registran todas las declaraciones SQL ejecutadas. También puede configurar reglas de alarma, etc., establecer la persona a cargo de cada aplicación y alarmar de acuerdo con las reglas configuradas. El middleware y el marco admitidos también son relativamente completos.

4. Transparente para el desarrollo y fácil de cambiar.

Conclusión: skywalking≈pinpoint > Zipkin
es transparente para el desarrollo, fácil de activar y desactivar, agregar nuevas funciones sin modificar el código y fácil de habilitar o deshabilitar. Esperamos que las funciones funcionen sin modificar el código y queremos visibilidad a nivel de código.

Para ello, Zipkin utiliza una biblioteca de clases modificada y su propio contenedor (Finagle) para proporcionar capacidades de seguimiento de transacciones distribuidas. Sin embargo, requiere modificaciones de código si es necesario. Tanto el skywalking como el pinpoint se basan en métodos de mejora del código de bytes. Los desarrolladores no necesitan modificar el código y se pueden recopilar datos más precisos porque hay más información en el código de bytes.

5. Topología completa de la aplicación de la cadena de llamadas

Conclusión: pinpoint > skywalking > zipkin
detecta automáticamente la topología de la aplicación y le ayuda a descubrir la arquitectura de la aplicación.

• topología de enlace precisa
  
• Topología del enlace Skywalking
  
• 
  Las tres imágenes anteriores de la topología del enlace zipkin muestran respectivamente la topología de llamada de los componentes APM y pueden realizar la topología completa de la aplicación de la cadena de llamadas. En términos relativos, la interfaz precisa muestra más ricamente, específicamente el nombre de la base de datos llamada, mientras que la topología de zipkin se limita a brindar servicios.

6. Comparación del refinamiento de Pinpoint y Zipkin

1. Diferencias entre Pinpoint y Zipkin

• Pinpoint es una solución completa de monitoreo de rendimiento: tiene un sistema completo desde sondas, recolectores, almacenamiento hasta interfaz Web, mientras que Zipkin solo se enfoca en recolectores y servicios de almacenamiento, aunque también tiene una interfaz de usuario, sus funciones no son las mismas que Pinpoint. . Por el contrario, Zipkin proporciona la interfaz Query, que tiene una interfaz de usuario y capacidades de integración del sistema más potentes, y puede desarrollarse e implementarse en función de esta interfaz.
• Zipkin proporciona oficialmente interfaces basadas en el marco Finagle (lenguaje Scala), mientras que las interfaces de otros marcos son aportadas por la comunidad. Actualmente admite lenguajes y marcos de desarrollo convencionales como Java, Scala, Node, Go, Python, Ruby y C#; sin embargo, Pinpoint actualmente solo se proporciona oficialmente la sonda del Agente Java, y otros están bajo solicitud de soporte de la comunidad (consulte los números 1759 y 1760).
• Pinpoint proporciona sondas de agente Java, que implementan la interceptación de llamadas y la recopilación de datos mediante inyección de código de bytes. Puede lograr la no intrusión de código real. Solo necesita agregar algunos parámetros al iniciar el servidor para completar la implementación de la sonda; implementación de la interfaz Java de Zipkin Brave Solo proporciona API de operación básica. Si necesita integrarse con un marco o proyecto, debe agregar manualmente archivos de configuración o agregar código.
• El almacenamiento backend de Pinpoint se basa en HBase, mientras que Zipkin se basa en Cassandra.

2. Similitud entre Pinpoint y Zipkin
   Pinpoint y Zipkin se basan en el artículo de Google Dapper, por lo que la base teórica es más o menos la misma. Ambos dividen las llamadas de servicio en varios tramos con relaciones en cascada y ponen en cascada las relaciones de llamadas a través de SpanId y ParentSpanId; finalmente, todos los tramos que fluyen a través de toda la cadena de llamadas se reúnen en un Trace y se informan al servicio. El recopilador al final realiza la recopilación y almacenamiento.

   Incluso en este punto, los conceptos adoptados por Pinpoint no son del todo consistentes con ese artículo. Por ejemplo, usa TransactionId para reemplazar TraceId, y el TraceId real es una estructura que contiene TransactionId, SpanId y ParentSpanId. Además, Pinpoint agrega una estructura SpanEvent en Span para registrar los detalles de las llamadas internas de un Span (como llamadas a métodos específicos, etc.), por lo que Pinpoint registrará más datos de seguimiento que Zipkin de forma predeterminada.

   Sin embargo, en teoría, no hay límite para la granularidad de Span, por lo que una llamada de servicio puede ser un Span, y luego la llamada al método en cada servicio también puede ser un Span. En este caso, Brave puede rastrear el nivel de llamada al método. , Pero la implementación específica no es Simplemente no lo hice.

3. Inyección de código de bytes versus llamada API
   Pinpoint implementa una sonda del Agente Java basada en la inyección de código de bytes, mientras que el marco Brave de Zipkin solo proporciona una API a nivel de aplicación, pero el problema está lejos de ser simple cuando lo piensas. La inyección de código de bytes es una solución simple y tosca. En teoría, cualquier llamada a un método puede interceptarse inyectando código. En otras palabras, no hay nada que no se pueda implementar, solo cosas que no se pueden implementar.

   Pero Brave es diferente: la API a nivel de aplicación que proporciona también requiere el soporte del controlador subyacente del marco para lograr la interceptación. Por ejemplo, el controlador JDBC de MySQL proporciona un método para inyectar interceptores, por lo que solo necesita implementar la interfaz StatementInterceptor y configurarla en la cadena de conexión para implementar fácilmente interceptaciones relacionadas. En contraste, la versión inferior de MongoDB El controlador o la implementación de Spring Data MongoDB no tiene dicha interfaz, por lo que es más difícil implementar la función de interceptar declaraciones de consulta.

   Por lo tanto, en este punto, Brave es un defecto. No importa lo difícil que sea usar la inyección de código de bytes, al menos se puede lograr. Sin embargo, Brave tiene la posibilidad de no saber cómo comenzar, si se puede inyectar y a qué. Hasta qué punto se puede inyectar y más Depende de la API del marco que de sus propias capacidades.

4. Dificultad y costo
   Después de leer brevemente los códigos de los complementos Pinpoint y Brave, encontrará que la dificultad de implementación de los dos es muy diferente. Brave es más fácil de usar que Pinpoint sin ningún soporte de documentación de desarrollo. La cantidad de código en Brave es muy pequeña y las funciones principales se concentran en el módulo de núcleo valiente. Un desarrollador de nivel medio puede comprender su contenido en un día y tener una comprensión muy clara de la estructura de la API.

   La encapsulación de código de Pinpoint también es muy buena, especialmente la encapsulación de la API superior para la inyección de código de bytes es muy buena, pero esto aún requiere que los lectores tengan cierta comprensión de la inyección de código de bytes, aunque su API principal para inyectar código no es mucho, pero si Si desea comprenderlo a fondo, probablemente deba profundizar en el código relevante del Agente. Por ejemplo, es difícil comprender claramente la diferencia entre addInterceptor y addScopedInterceptor, y estos dos métodos se encuentran en los tipos relevantes de Agente.

   Debido a que la inyección de Brave depende del marco subyacente para proporcionar interfaces relevantes, no requiere una comprensión integral del marco, solo necesita saber dónde se puede inyectar y qué datos se pueden obtener durante la inyección. Al igual que en el ejemplo anterior, no necesitamos saber cómo se implementa el controlador JDBC de MySQL para lograr la capacidad de interceptar SQL. Pero este no es el caso con Pinpoint, porque Pinpoint puede inyectar cualquier código casi en cualquier lugar, lo que requiere que los desarrolladores tengan un conocimiento muy profundo de la implementación del código de la biblioteca que se debe inyectar. En la implementación de sus complementos MySQL y Http Client, por supuesto, esto también muestra desde otro nivel que las capacidades de Pinpoint pueden ser realmente muy poderosas, y muchos de sus complementos predeterminados ya han logrado una interceptación muy fina.

   Cuando el marco subyacente no tiene una API pública, Brave en realidad no está completamente indefenso. Podemos usar AOP para inyectar interceptaciones relevantes en el código especificado y, obviamente, la aplicación de AOP es mucho más simple que la inyección de código de bytes.

   Lo anterior está directamente relacionado con el costo de implementar un monitoreo, en la documentación técnica oficial de Pinpoint se brinda un dato de referencia. Si se integra un sistema, el costo de desarrollar el complemento Pinpoint es 100 y el costo de integrar el complemento en el sistema es 0; pero para Brave, el costo de desarrollo del complemento es solo 20 y la integración el costo es 10. De este punto se desprende que el dato oficial de referencia de costes es de 5:1. Sin embargo, el funcionario enfatizó que si hay 10 sistemas que deben integrarse, entonces el costo total es 10 * 10 + 20 = 120, lo que excede el costo de desarrollo de Pinpoint de 100, y cuantos más servicios deban integrarse, mayor el hueco.

5. Versatilidad y escalabilidad
   Evidentemente, Pinpoint está completamente en desventaja en este sentido, como se puede comprobar en las interfaces integradas desarrolladas por la comunidad.

   La interfaz de datos de Pinpoint carece de documentación y no es muy estándar (consulte el hilo de discusión del foro). Necesita leer mucho código para implementar su propia sonda (como la de Node o PHP). Además, el equipo utilizó Thrift como protocolo estándar de transmisión de datos por motivos de rendimiento, lo cual es mucho más difícil que HTTP y JSON.

6. Soporte de la comunidad
   No hace falta decir que Zipkin fue desarrollado por Twitter y puede considerarse como un equipo estrella, mientras que el equipo de Naver es simplemente un pequeño equipo desconocido (como se puede ver en la discusión del n.° 1759). Aunque es poco probable que este proyecto desaparezca o deje de actualizarse en el corto plazo, no es tan seguro como el primero. Y sin más complementos desarrollados por la comunidad, es realmente difícil para Pinpoint completar la integración de muchos marcos confiando únicamente en las propias fortalezas del equipo, y su enfoque actual todavía está en mejorar el rendimiento y la estabilidad.

7. Otros
   Pinpoints han tenido en cuenta los problemas de rendimiento al comienzo de su implementación. Algunos servicios de back-end del sitio web www.naver.com manejan más de 20 mil millones de solicitudes todos los días, por lo que elegirán el formato de codificación binaria de longitud variable de Thrift y utilizarán UDP como enlace de transmisión e intente utilizar un diccionario de referencia de datos al pasar constantes, pasar un número en lugar de pasar una cadena directamente, etc. Estas optimizaciones también aumentan la complejidad del sistema: incluida la dificultad de usar la interfaz Thrift, problemas de transmisión de datos UDP y problemas de registro constante del diccionario de datos, etc.

   Por el contrario, Zipkin utiliza la interfaz familiar Restful más JSON, que casi no tiene costos de aprendizaje ni dificultades de integración. Siempre que conozca la estructura de transmisión de datos, puede desarrollar fácilmente la interfaz correspondiente para un nuevo marco.

   Además, Pinpoint carece de la capacidad de muestrear solicitudes. Obviamente, en un entorno de producción de gran tráfico, es imposible registrar todas las solicitudes, lo que requiere un muestreo de solicitudes para determinar qué tipo de solicitudes debo registrar. Tanto Pinpoint como Brave admiten el porcentaje de muestreo, que es el porcentaje de solicitudes que se registrarán. Sin embargo, además, Brave también proporciona una interfaz Sampler, que le permite personalizar la estrategia de muestreo. Especialmente cuando se realizan pruebas A/B, esta función es muy significativa.

8. Resumir

   Desde la perspectiva de los objetivos a corto plazo, Pinpoint tiene ventajas abrumadoras : las sondas se pueden implementar sin ningún cambio en el código del proyecto, los datos de seguimiento son granulares hasta el nivel de llamada del método, una potente interfaz de usuario y un soporte casi completo del marco Java. Pero a largo plazo, aún se desconoce el costo de aprender la interfaz de desarrollo de Pinpoint e implementar interfaces para diferentes marcos en el futuro.

   Por el contrario, es relativamente fácil dominar Brave y la comunidad de Zipkin es más fuerte y es más probable que desarrolle más interfaces en el futuro . En el peor de los casos, también podemos agregar código de monitoreo adecuado para nosotros a través de AOP sin introducir demasiadas tecnologías y conceptos nuevos. Además, cuando el negocio cambie en el futuro, será difícil decir si los informes proporcionados oficialmente por Pinpoint cumplirán con los requisitos. Agregar nuevos informes también traerá dificultades y cargas de trabajo impredecibles.

6. La diferencia entre seguimiento y seguimiento

• El monitor se puede dividir en monitoreo del sistema y monitoreo de aplicaciones. El monitoreo del sistema incluye datos generales de carga del sistema, como CPU, memoria, red, disco, etc., y puede detallarse en los datos relevantes de cada proceso. Este tipo de información se puede obtener directamente del sistema. El monitoreo de aplicaciones requiere soporte de aplicaciones y expone los datos correspondientes. Por ejemplo, el QPS de las solicitudes internas dentro de la aplicación, el retraso en el procesamiento de la solicitud, la cantidad de errores en el procesamiento de la solicitud, la longitud de la cola de mensajes, las situaciones de falla, la información del proceso de recolección de basura, etc. El objetivo principal de Monitor es detectar anomalías y alertar a la policía a tiempo.

• La base y el núcleo de Tracing es la cadena de llamadas. La mayoría de las métricas relevantes se obtienen en torno al análisis de la cadena de llamadas. El objetivo principal de Tracing es el análisis del sistema. Es mejor encontrar los problemas por adelantado que resolverlos después de que surjan.

El seguimiento y la pila de tecnología Monitor a nivel de aplicación tienen mucho en común. Hay recopilación, análisis, almacenamiento y presentación de datos. Lo que pasa es que las dimensiones específicas de los datos recopilados son diferentes y el proceso de análisis es diferente.