Cuando la aplicación era monolítica y repentinamente, una vez que se distribuía, se agrega otro desconocido a la fórmula de cálculo de disponibilidad: la red. Debido a problemas con las llamadas entre componentes, las aplicaciones a menudo se caen y comienzan a sacudirse las piernas. Y descubrir las razones del trabajo inestable de una aplicación distribuida es otra tarea. Los kubernetes condicionales crean un desorden adicional en la estructura de la aplicación, que, a su propia discreción, puede distribuir arbitrariamente pods condicionales por nodos condicionales. Estoy escribiendo "condicional", porque en lugar de kubernetes puede haber Swarm y OpenShift, y otros y otros.

Quiero decir, sin una visualización normal, descubrir dónde está la temperatura puede ser muy difícil. Debajo del corte, mi idea de las capacidades potenciales de las herramientas que pueden dibujar un mapa de aplicación y resaltar los lugares para aplicar un plátano, así como una lista de estas herramientas con capturas de pantalla.

Comencemos a descubrir qué es deseable ver en el mapa de la aplicación, luego consideraremos los enfoques de monitoreo y luego pasaremos a proveedores específicos.

Lo que quiero ver en el mapa de la aplicación

Lo primero que viene a la mente es la capacidad de agrupar nodos de aplicación según ciertos criterios. Por ejemplo, digo que en este grupo tengo una interfaz, y en este backend o aquí tengo instancias del servicio de Pagos, y aquí Envío. Bueno, y así sucesivamente. Y las personas responsables de esta o aquella parte ven de inmediato la imagen completa de lo que sucede dentro de su área de responsabilidad.

El segundo es diseñar la aplicación por niveles con la capacidad de ver, por ejemplo, en términos de infraestructura, servicio, instancias de servicio, etc. Además del primer caso, ayuda a identificar la capa problemática.

En tercer lugar , las salidas y entradas de estos nodos, incluidas las conexiones entre ellos. En estas cadenas, me gustaría ver las señales doradas que describe Google en la Ingeniería de confiabilidad del sitio 6 en el Capítulo 6 de Monitoreo de sistemas distribuidos. Ya publiqué una traducción de este capítulo en un blog sobre el Medio . Y las señales son las siguientes: latencia, tráfico (rendimiento), errores (tasa de error) y saturación (saturación).

Tal vez no tomé en cuenta algo. Vaya a los comentarios si cree que faltan otras cosas importantes.

¿Cuáles son los diferentes enfoques de monitoreo?

No sé qué más se puede llamar, por lo tanto, llamaré a los enfoques agente y monitoreo sin agente. Ahora explicaré hu de hu.

Monitoreo del agente

La supervisión de agentes significa la necesidad de implementar agentes de supervisión especiales en una aplicación controlada. Los agentes incrustan la identificación de rastreo en los encabezados de los paquetes.

Este tipo incluye soluciones de monitoreo APM y todas aquellas que se integran mediante la inyección de SDK en el código de la aplicación.

Pros: ayuda a encontrar la causa raíz del problema, los encabezados pueden rastrear con precisión la ruta de las transacciones.

Contras: posibles gastos generales debido a una modificación del algoritmo de la aplicación, la incapacidad de incrustar en aplicaciones heredadas, soporte para un conjunto limitado de lenguajes de programación

Monitoreo sin agente

Seguimiento sin modificación de la aplicación. Este tipo incluye registros, rastreo a nivel del sistema operativo y monitoreo del tráfico de red.

Pros: la cobertura de monitoreo de varios marcos y lenguajes de programación puede funcionar donde la inyección de identificación de rastreo no es posible, no hay sobrecarga en una aplicación controlada.

Contras: sin una identificación de seguimiento, puede ser difícil restaurar el contexto de una transacción comercial, la incapacidad de escuchar el tráfico si la encapsulación SSL está configurada y no hay claves,

¿Qué ofrecen los vendedores?

Vendorov se desarmó sobre la base de agente / sin agente, puede solicitar otras características en los comentarios o en un mensaje personal. La mayor experiencia que tuve con Instana, Appdynamics y New Relic, si quieres mirar, puedo ayudar con las licencias de demostración por un período superior a 14 días (como se ofrecen en sus sitios por defecto).

Monitoreo del agente

Instana es una herramienta para monitorear sistemas distribuidos. Una característica clave es un agente único para todas las tecnologías compatibles y la recopilación de métricas una vez por segundo.



Appdynamics es una solución bien conocida para el monitoreo APM. Capaz de construir un mapa de aplicación basado en llamadas entre componentes de la aplicación. Se requiere la supervisión del agente para supervisar las llamadas.



New Relic es un competidor directo de Appdynamics. La diferencia clave es que solo es posible el monitoreo desde la nube (los agentes también se instalan en los servidores de destino). Crea un mapa de aplicaciones basado en llamadas.



Dynatrace es una herramienta de monitoreo APM. Admite el monitoreo de varios lenguajes de programación y puede funcionar tanto desde la nube como en las instalaciones.



AWS X-Ray : supervise las aplicaciones alojadas en AWS. Admite la visualización del mapa de la aplicación, requiere la instalación de su propio SDK.



OpenTracing es una API para instrumentación de aplicaciones distribuidas. Muchas soluciones comerciales y no comerciales se basan en esta API.

Jaeger es una herramienta comercial gratuita de código abierto. Construido sobre la base de OpenTracing.



Datadog APM es una herramienta comercial para monitorear aplicaciones distribuidas. Funciona sobre la base del mencionado OpenTracing.

Monitoreo sin agente

OpenZipkin es una herramienta gratuita para rastrear aplicaciones distribuidas. Una característica de su trabajo es la recopilación de datos sobre llamadas utilizando las bibliotecas de instrumentación y el posterior envío de estos datos al recopilador de OpenZipkin.



Linkerd es una herramienta gratuita para rastrear llamadas dentro de la aplicación. Es un complemento para OpenZipkin, se instala en la infraestructura de kubernetes como un contenedor de sidecar.



Envoy es una herramienta gratuita. Funciona como un proxy al que se envían los datos de la llamada entre los componentes de la aplicación. No hay una interfaz web propia, los datos pueden recibirse a través de solicitudes HTTP GET o enviarse a statsd.

Netsil es una herramienta para monitorear aplicaciones distribuidas basadas en escuchar tráfico. Funciona independientemente del idioma en el que se escribe la aplicación.



Indica quién usó qué y qué impresión quedó.