Microservicios de monitorización: todo lo que necesita saber [2019]

Este artículo apareció por primera vez en The New Stack .

El monitoreo sigue siendo una parte crítica de la administración de cualquier sistema de TI, mientras que los desafíos asociados con los microservicios de monitoreo son especialmente únicos. Un ejemplo es cómo los sistemas monolíticos tradicionales, implementados como un único ejecutable o biblioteca, tienen diferentes puntos de falla y dependencias que los implementados con una arquitectura de microservicios.

Es importante comprender el monitoreo en general y cómo es diferente para las aplicaciones de microservicios. Las aplicaciones basadas en microservicios tienen requisitos de monitoreo diferentes y más intensivos. La lógica de negocios aplicada a un proceso, como una solicitud de préstamo, por ejemplo, se distribuye entre muchos servicios separados. De esta manera, el seguimiento de una aplicación a través del proceso requiere la correlación de los datos de todos estos servicios diferentes.

Algunos conceptos esenciales relacionados con el cómo y el por qué de los microservicios incluyen:

• ¿Por qué deberían ser monitoreados los sistemas?
• ¿En qué se diferencian los microservicios de monitorización de las aplicaciones monolíticas de monitorización?
• ¿Qué datos deben recopilarse durante el seguimiento?
• ¿Qué herramientas están disponibles para publicar, recopilar y almacenar datos de monitoreo?

¿Por qué monitorear tus microservicios?

Las aplicaciones desarrolladas utilizando la arquitectura de microservicio deben ser monitoreadas por las mismas razones que cualquier otro tipo de sistema distribuido: es decir, todos los sistemas fallan eventualmente.

El fracaso es la razón más obvia por la cual el monitoreo es importante, pero no es el único. El rendimiento del sistema no es binario; Los sistemas no solo están "arriba" o "abajo". Los sistemas complejos, incluso los monolitos, pueden operar en un estado degradado que afecta el rendimiento. Estos estados degradados a menudo anuncian fallos inminentes. El monitoreo del comportamiento de los sistemas puede alertar a los operadores a estados degradados antes de que ocurran fallas totales.

Los servicios provistos internamente, o para clientes externos, a menudo se brindan bajo un Acuerdo de Nivel de Servicio. Sin monitoreo, es imposible saber si el SLA está siendo respetado o violado, por ejemplo.

El monitoreo de los sistemas a lo largo del tiempo produce datos valiosos que pueden utilizarse para mejorar el rendimiento del servicio. Los datos de fallas y rendimiento se pueden analizar para buscar patrones en fallas del sistema, que se pueden correlacionar con eventos. Por ejemplo, considere un caso donde los datos indican que el 25 por ciento de las fallas totales del sistema ocurren dentro de una hora de una nueva implementación. Esto sería, por lo tanto, un indicador sólido de que los procesos de implementación requieren atención y mejora.

Dada la importancia que tiene en las operaciones de TI, el monitoreo del rendimiento de las aplicaciones (APM) es un mercado en sí mismo. Gartner publica un informe de Magic Quadrant (MQ) para herramientas APM, por ejemplo. También hay muchas herramientas de software de código abierto y comerciales disponibles, como la plataforma APM de Raygun . Estas herramientas se utilizan para publicar, recopilar y almacenar datos de métricas.

El nivel de almacenamiento está diseñado específicamente para manejar datos de series de tiempo.

La supervisión de errores es un campo más estrecho de la supervisión del rendimiento. Está orientado principalmente para recopilar datos sobre excepciones manejadas y no manejadas. Con Raygun Error Monitoring , los informes de seguimiento de excepciones y los informes se registran en la misma secuencia de eventos que otros datos de registro.

Estos sistemas son indispensables como recursos para mantener sistemas resistentes y disponibles. Los equipos de desarrollo pueden usar los datos para comprender cómo se ejecutan sus aplicaciones "en la naturaleza". Los equipos de operaciones pueden recopilar grandes cantidades de datos para fines forenses y analíticos. Las características de alerta de las herramientas de monitoreo del rendimiento de la aplicación (APM) pueden analizar esos datos en tiempo real, filtrando todos los eventos, excepto los más importantes. Esos eventos importantes se pueden presentar como alertas a través de paneles de control, correo electrónico, Slack y aplicaciones móviles.

Los microservicios no son lo mismo que los monolitos

La supervisión de una aplicación basada en una arquitectura de microservicio es cualitativamente diferente de la supervisión de una aplicación monolítica. Las aplicaciones monolíticas normalmente se implementan como una única biblioteca ejecutable o binaria.

Arquitectura monolítica de aplicaciones Las aplicaciones de microservicios se implementan como una familia de servicios independientes. Cada servicio tiene una función específica que desempeñar, y debe comunicarse con otros servicios para completar una "unidad de trabajo". En una arquitectura de microservicio, los flujos de trabajo complejos se organizan a través de una serie de microservicios. Cada servicio puede comunicarse con dependencias. Esto puede ser un disco, una base de datos u otros servicios. Cada interacción entre un servicio y un recurso dependiente es un punto potencial de falla.

La falla de una dependencia, o incluso un rendimiento degradado, resultará en efectos ascendentes en el rendimiento general. Es importante detectar estos problemas desde el principio para evitar la degradación o falla sistémica.

Una robusta arquitectura de microservicios toma en cuenta estos hechos y los aborda, tanto en contextos de desarrollo como operativos. Los equipos de desarrollo pueden incorporar la instrumentación en los sistemas en el momento del diseño a medida que escriben aplicaciones que informan su comportamiento a nivel granular. Los equipos de operaciones deben crear y soportar infraestructura para recopilar datos reportados por aplicaciones y plataformas. Los datos recopilados y almacenados por esas plataformas se utilizan para situaciones de emergencia a corto plazo, como las alertas. Los usos a más largo plazo incluyen la minería de datos y el análisis como una forma de buscar patrones. Esos patrones se pueden analizar para encontrar y prevenir modos de falla comunes.

Microservicios de monitorización: Qué medir

El monitoreo es un proceso de información, recopilación y almacenamiento de datos. La primera pregunta que se debe hacer es qué datos son útiles. Los grandes sistemas distribuidos procesan enormes cantidades de datos todos los días, generando potencialmente gigabytes de nuevos metadatos sobre su comportamiento en poco tiempo.

¿Cómo se encuentra la señal en medio del ruido? Cada aplicación tendrá necesidades únicas relacionadas con el monitoreo. Hay algunas métricas comunes que querrás grabar. Incluyen:

Métricas de aplicación

Estas métricas se relacionan específicamente con su aplicación. Si su aplicación acepta registros de usuarios, una métrica estándar podría ser cuántas se completaron con éxito en la última hora. Un sistema de preparación de impuestos puede registrar eventos específicos del contexto, como la validación de formularios. Estos datos de nivel superior son útiles para que los equipos de desarrollo y la organización entiendan el comportamiento funcional del sistema. Si la validación de la forma de volumen máximo suele ocurrir 1.000 veces por hora, y de repente el rendimiento se reduce a 500 en las últimas dos horas, esa anomalía podría ser un indicio de un problema.

Métricas de la plataforma

Estas métricas informan sobre las tuercas y tornillos de su infraestructura. Ejemplos incluyen:

• El tiempo de ejecución promedio general de cada una de las diez consultas de base de datos más frecuentemente ejecutadas
• El tiempo promedio de ejecución del 10 por ciento más rápido.
• El tiempo promedio de ejecución del 10 por ciento más lento.
• La cantidad de solicitudes por minuto que recibe un servicio.
• El tiempo de respuesta promedio para cada punto final de servicio.
• La relación éxito / fracaso para cada servicio.

En conjunto, estas métricas proporcionan un panel de control que se puede utilizar para comprender el rendimiento y el comportamiento del sistema de bajo nivel. Idealmente, estas métricas lo alertarán sobre el rendimiento degradado que probablemente afectará el rendimiento general o dará lugar a una falla en todo el sistema. Es importante usar datos de bajo nivel de esta manera para predecir y prevenir fallas más amplias antes de que ocurran.

La plataforma Raygun APM ofrece un panel que puede visualizar este tipo de métricas y otras relacionadas con el rendimiento general del sistema.

Eventos del sistema

Las fuerzas externas actúan en los sistemas todo el tiempo. Las implementaciones más comunes, y potencialmente las más disruptivas, son las nuevas. El personal de operaciones sabe que existe una fuerte correlación entre las nuevas implementaciones de código y las fallas del sistema. Dada la realidad, tiene sentido incluir un registro de esas implementaciones en los datos de series de tiempo que registran las aplicaciones, junto con el resto de las métricas. Los eventos de escalado, las actualizaciones de configuración y otros cambios operativos también son relevantes y deben registrarse. La grabación de estos eventos también permitirá correlacionarlos con el comportamiento del sistema.

Microservicio de mejores prácticas de monitoreo.

El "cómo" del monitoreo para aplicaciones de microservicios no es muy diferente de cualquier otro sistema distribuido, aunque hay algunos requisitos únicos. Podemos consultar el método de la aplicación Twelve-Factor para obtener alguna orientación.

La metodología de Doce factores implica tratar los registros como flujos de eventos. El patrón arquitectónico recomendado requiere un acoplamiento suelto entre aplicaciones y problemas de registro.

En su descripción de una aplicación de 12 factores, Adam Wiggins escribe :

“Una aplicación de doce factores nunca se preocupa por el enrutamiento o almacenamiento de su flujo de salida. No debe intentar escribir o administrar archivos de registro. En su lugar, cada proceso en ejecución escribe su flujo de eventos, sin buffer, en 'stdout'. Durante el desarrollo local, el desarrollador verá este flujo en el primer plano de su terminal para observar el comportamiento de la aplicación ".

Este patrón desacopla las preocupaciones de producir datos de registro de recopilar y almacenar los datos. Los equipos de operaciones son libres de resolver los problemas de recopilación y almacenamiento independientemente del diseño de la aplicación. Este es un enfoque entre varios; algunos equipos de desarrollo prefieren utilizar técnicas de instrumentación distintas de "stdout", como las bibliotecas de instrumentación, para hacer esto. La elección correcta depende de la arquitectura de la aplicación en cuestión.

Recopilar datos de aplicaciones y plataformas es una forma pasiva de monitoreo. Podemos usar los "controles de salud" como un método proactivo para probar un servicio regularmente.

Una simple comprobación de estado puede devolver solo un valor fijo. Si bien esto no prueba que el servicio sea completamente funcional, es un método rápido y eficiente para confirmar la funcionalidad básica. Si el servicio está mal configurado, probablemente fallará una simple prueba de comprobación de estado. Los controles de estado pueden programarse para probar los servicios de forma regular e informar su estado en un panel de control.

Las comprobaciones de estado pueden ser más sofisticadas que simplemente devolver una cadena fija. Las comprobaciones de extremo a extremo pueden probar la interacción entre un servicio y los servicios dependientes, en sentido descendente. Estos tipos de comprobaciones pueden probarse más a fondo ejecutando parte de la lógica utilizada para procesar el trabajo "real".

Los equipos de operaciones pueden configurar tuberías de integración y despliegue continuo con una o más comprobaciones de estado como el último paso posterior al despliegue. Si la comprobación de estado falla, el sistema de implementación puede generar una alerta y, si lo desea, revertir la implementación. Los controles de estado son especialmente útiles para las aplicaciones de microservicios porque generalmente hay servicios operados de manera más independiente que las aplicaciones monolíticas.

Microservicios de monitorización de herramientas.

La tecnología y las herramientas de monitoreo vienen en dos categorías amplias: bibliotecas y plataformas. Algunas herramientas incluyen ambas, que proporcionan una plataforma para la colección y una biblioteca para instrumentar el código.

Las bibliotecas se incorporan a una aplicación durante su desarrollo. Los marcos de lenguaje más populares, como Java, .NET, Go y otros; Incluye recursos para escribir en flujos de datos a través de una red. Estos recursos se pueden utilizar para el registro y la supervisión. Las bibliotecas de terceros de fuente abierta y pagas también están disponibles para mejorar los informes de métricas. Los ejemplos incluyen bibliotecas de código abierto como AppMetrics para .NET y SPF4J para Java.

Las plataformas de monitoreo se centran principalmente en la recopilación y el análisis de los datos que se recopilan de las aplicaciones y el sistema operativo y las plataformas de red en las que se ejecutan. Aquí hay algunos ejemplos de herramientas que pueden ser parte de una plataforma de monitoreo de microservicios:

• Raygun APM : la plataforma APM de Raygun es otro ejemplo de un sistema completo que proporciona procesos de recopilación y de instrumentación, así como un panel para visualizar datos de métricas. Raygun APM soporta .NET. Java y soporte de Ruby están en desarrollo.
• Zipkin : Zipkin es un sistema de rastreo de código abierto diseñado específicamente para rastrear llamadas entre microservicios. Es especialmente útil para analizar problemas de latencia. Zipkin incluye tanto las bibliotecas de instrumentación como los procesos de recopilación que recopilan y almacenan datos de seguimiento.
• Apache Kafka : Kafka es un sistema de procesamiento de flujos. Utiliza una metodología de "publicación / suscripción" para leer y escribir datos en una "transmisión" lógica, que es similar en concepto a un sistema de mensajería como RabbitMQ. Kafka se puede combinar con otras herramientas como Zipkin para proporcionar una solución robusta para transmitir y almacenar datos de métricas.
• Grafana : Los datos recopilados por todas estas herramientas no son muy útiles a menos que puedan interpretarse y analizarse. Con este fin, Grafana es una herramienta de visualización basada en la web que se utiliza para crear cuadros de mandos visuales.
• Prometheus : Prometheus es una solución de monitoreo de código abierto desarrollada originalmente por SoundCloud. Se utiliza ampliamente para almacenar y consultar "datos de series de tiempo", que son datos que describen acciones a lo largo del tiempo. Prometheus a menudo se combina con otras herramientas, especialmente Grafana, para visualizar los datos de series de tiempo y para proporcionar paneles de control.

Conclusión

Los requisitos de monitoreo deben considerarse desde el principio del ciclo de vida de una aplicación. El monitoreo de sistemas requiere contribuciones tanto de desarrollo como de operaciones. Es una parte crítica del soporte operativo de cualquier sistema distribuido. Las arquitecturas de microservicio están incluso más distribuidas que una aplicación monolítica típica. Requieren más atención en tiempo real y monitoreo proactivo.

Es tan importante recopilar datos relevantes como analizar los datos recopilados. Las aplicaciones deben ser instrumentadas por los desarrolladores para informar eventos específicos de la aplicación.

Los equipos de operaciones deben recopilar datos no solo de las aplicaciones, sino también de las plataformas de soporte y sistemas de implementación. Las soluciones de código abierto y de pago están disponibles para admitir tanto la publicación como el almacenamiento de eventos de monitoreo. Estos datos son fundamentales para admitir un sistema distribuido que sea resistente, confiable y disponible.

Ahí es donde una herramienta APM puede ayudar significativamente. Prueba Raygun gratis por 14 días.