BLOG | NGINX

Integración de OpenTelemetry en la arquitectura de referencia de aplicaciones modernas: un informe de progreso

NGINX - Parte de F5 - horizontal, negro, tipo RGB
Miniatura de Elijah Zupancic
Elijah Zupancic
Publicado el 8 de marzo de 2022
Miniatura de Jason Schmidt
Jason Schmidt
Publicado el 8 de marzo de 2022

Cuando presentamos el proyecto NGINX Modern Apps Reference Architecture (MARA) el otoño pasado en Sprint 2.0, enfatizamos nuestra intención de que no sea un "juguete" como algunas arquitecturas, sino más bien una solución "sólida, probada y lista para implementarse en aplicações de producción en vivo que se ejecutan en entornos Kubernetes". Para un proyecto de este tipo, disponer de herramientas de observabilidad es un requisito absoluto. Todos los miembros del equipo MARA han experimentado de primera mano cómo la falta de conocimiento sobre el estado y el rendimiento hace que el desarrollo y la entrega de aplicação sean un ejercicio de frustración. Inmediatamente llegamos al consenso de que MARA debe incluir instrumentación para la depuración y el seguimiento en un entorno de producción.

Otro principio rector del MARA es la preferencia por las soluciones de código abierto. En esta publicación, describimos cómo nuestra búsqueda de una herramienta de observabilidad multifuncional y de código abierto nos llevó a OpenTelemetry y luego detallamos las compensaciones, las decisiones de diseño, las técnicas y las tecnologías que usamos para integrar OpenTelemetry con una aplicação de microservicios creada con Python, Java y NGINX.

Esperamos que conocer nuestras experiencias le ayude a evitar posibles obstáculos y a acelerar su propia adopción de OpenTelemetry. Tenga en cuenta que la publicación es un informe de progreso urgente: anticipamos que las tecnologías que analizamos madurarán dentro de un año. Además, aunque señalamos deficiencias actuales en algunos proyectos, estamos inmensamente agradecidos por todo el trabajo de código abierto que se está realizando y estamos emocionados de ver su progreso.

Nuestra aplicação

Como aplicação para integrar con una solución de observabilidad, elegimos Bank of Sirius , nuestra bifurcación de la aplicación de muestra Bank of Anthos de Google. Es una aplicación web con una arquitectura de microservicios que se puede implementar a través de infraestructura como código . Hay numerosas formas de mejorar esta aplicação en términos de rendimiento y confiabilidad, pero es lo suficientemente madura como para ser considerada razonablemente una aplicaçãobrownfield . Como tal, creemos que es un buen ejemplo para mostrar cómo integrar OpenTelemetry en una aplicação, porque en teoría el seguimiento distribuido proporciona información valiosa sobre las deficiencias de la arquitectura de una aplicação .

Como se muestra en el diagrama, los servicios que respaldan la aplicação son relativamente sencillos.

Imagen cortesía de Google

Cómo elegimos OpenTelemetry

Nuestro camino para seleccionar OpenTelemetry fue bastante tortuoso y tuvo varias etapas.

Creación de una lista de deseos de funciones

Antes de evaluar las herramientas de observabilidad de código abierto disponibles, identificamos qué aspectos de la observabilidad nos interesan. Basándonos en nuestras experiencias pasadas, elaboramos la siguiente lista.

  • Registro : tal como usamos el término, esto significa la generación de conjuntos de mensajes clásicos delimitados por nuevas líneas desde las aplicações; la aplicación Bank of Sirius estructura sus registros en formato Bunyan.
  • Seguimiento distribuido : tiempos y metadatos para cada componente dentro de toda la aplicação, como los que ofrecen los proveedores de gestión del rendimiento de aplicação (APM)
  • Métricas : mediciones capturadas durante un período de tiempo y graficadas como datos de series de tiempo.
  • Agregación y notificación de excepciones/errores : una colección agregada de las excepciones y errores más comunes, que debe poder buscarse para que podamos determinar qué errores de aplicação son los más comunes.
  • Comprobaciones de estado : sondeos periódicos enviados a los servicios para determinar si funcionan correctamente dentro de la aplicação.
  • Introspección del estado de ejecución : un conjunto de API visibles solo para los administradores que devuelven información sobre el estado de ejecución de la aplicação
  • Volcados de núcleo/pila : instantáneas completas del estado de ejecución de un servicio; el factor importante para nuestros propósitos es lo fácil que es obtener estos volcados a pedido o cuando un servicio falla

Comparación de las características de la herramienta con la lista de deseos

Por supuesto, no esperábamos que una única herramienta o enfoque de código abierto incluyera todas estas características, pero al menos nos dio una base aspiracional sobre la cual comparar las herramientas disponibles. Consultamos la documentación de cada herramienta para descubrir cuáles de las siete funciones de nuestra lista de deseos admite. La tabla resume nuestros hallazgos.

Tecnología Explotación florestal Rastreo distribuido Parámetros Agregación de errores Comprobaciones de estado Introspección en tiempo de ejecución Volcados de pila/núcleo
ELK + APM elástico ✅ ✅ ✅ ✅ ✅ ❌ ❌
Grafana ✅ ✅ ✅ ✅ ✅ ❌ ❌
Graylog ✅ ❌ ❌ ❌ ❌ ❌ ❌
Jaeger ❌ ✅ ❌ ✅ ❌ ❌ ❌
Censo abierto ❌ ❌ ✅ ❌ ❌ ❌ ❌
OpenTelemetry Beta ✅ ✅ ✅ ✅ * ❌ ❌
Prometeo ❌ ❌ ✅ ❌ ❌ ❌ ❌
EstadísticasD ❌ ❌ ✅ ❌ ❌ ❌ ❌
Zipkin ❌ ✅ ❌ ✅ ❌ ❌ ❌

* Como extensión

Construir esta mesa fue un duro despertar. Las distintas herramientas difieren tanto en sus capacidades y propósitos previstos que no podíamos considerarlas a todas miembros de la misma categoría: ¡era como comparar manzanas con tostadoras!

Por ejemplo, ELK ( Elasticsearch-Logstash-Kibana , más Filebeat ) y Zipkin hacen cosas tan fundamentalmente diferentes que intentar compararlas es más confuso que cualquier otra cosa. Lamentablemente, la “expansión de la misión” simplemente enturbia aún más las aguas; sin duda, en respuesta a las solicitudes de los usuarios, se han agregado características que son secundarias al propósito principal de la herramienta y crean superposición con otras herramientas. En la superficie, ELK realiza el almacenamiento y visualización de registros, mientras que Zipkin realiza el seguimiento distribuido. Pero cuando profundizas un poco más en la cartera de productos de Elastic, rápidamente te encuentras con Elastic APM , que admite el seguimiento distribuido e incluso tiene compatibilidad con Jaeger .

Más allá del problema de la expansión de la misión, muchas de las herramientas se pueden integrar entre sí, lo que da como resultado diferentes combinaciones de recopiladores, agregadores, paneles de control, etc. Algunas tecnologías son compatibles entre sí y otras no.

Realizar una investigación cualitativa

Por lo tanto, esta tabla comparativa no nos brindó una imagen lo suficientemente precisa como para basar nuestra elección. Necesitábamos hacer una investigación cualitativa sobre los objetivos, los principios rectores y la posible dirección futura de cada proyecto, razonando que cuanto más similares sean los valores de un proyecto a los nuestros, más probabilidades habrá de que sigamos siendo compatibles a lo largo del tiempo. Al visitar las páginas del proyecto, inmediatamente notamos esto en la página de OpenCensus .

OpenCensus y OpenTracing se han fusionado para formar OpenTelemetry, que sirve como la próxima versión principal de OpenCensus y OpenTracing. OpenTelemetry ofrecerá compatibilidad con versiones anteriores de las integraciones de OpenCensus existentes y continuaremos realizando parches de seguridad para las bibliotecas de OpenCensus existentes durante dos años.

Para nosotros ese fue un dato clave. Sabíamos que no podíamos garantizar que nuestra elección fuera a prueba de futuro, pero queríamos saber al menos que contaría con un sólido respaldo de la comunidad en el futuro. Con esta información podríamos tachar a OpenCensus de nuestra lista de candidatos. Probablemente tampoco fue una buena idea utilizar Jaeger, porque es la implementación de referencia para el proyecto OpenTracing , ahora oficialmente obsoleto: la mayor parte de las nuevas contribuciones llegarán a OpenTelemetry.

Luego leemos sobre OpenTelemetry Collector .

OpenTelemetry Collector ofrece una implementación independiente del proveedor sobre cómo recibir, procesar y exportar datos de telemetría. Además, elimina la necesidad de ejecutar, operar y mantener múltiples agentes/recopiladores para soportar formatos de datos de telemetría de código abierto (por ejemplo, Jaeger, Prometheus, etc.) que se envían a múltiples back-ends comerciales o de código abierto.

El recopilador OpenTelemetry actúa como un agregador que nos permite mezclar y combinar diferentes métodos de instrumentación y recopilación de observabilidad con diferentes backends. Básicamente, nuestra aplicação puede recopilar rastros con Zipkin y métricas de Prometheus , que luego podemos enviar a un backend configurable y visualizar con Grafana . Son posibles otras permutaciones de este diseño, por lo que podemos probar diferentes enfoques para ver qué tecnologías se adaptan bien a nuestro caso de uso.

La integración de OpenTelemetry como camino a seguir

Básicamente, nos convencieron de utilizar OpenTelemetry Collector porque, en teoría, nos permite cambiar entre tecnologías de observabilidad. A pesar de la relativa inmadurez del proyecto, decidimos lanzarnos con valentía y utilizar OpenTelemetry solo con integraciones de código abierto porque la única forma de comprender el panorama es utilizar las tecnologías.

Sin embargo, faltan algunas piezas en OpenTelemetry Collector, por lo que debemos confiar en otras tecnologías para esas funciones. Las siguientes secciones resumen nuestras elecciones y el razonamiento detrás de ellas.

Implementación del registro

El registro es una parte engañosamente simple de la observabilidad que rápidamente conduce a decisiones complicadas. Es simple porque simplemente recopilas la salida del registro de tus contenedores, pero es complicado porque luego debes decidir dónde almacenar los datos, cómo transportarlos a ese almacén, cómo indexarlos para que sean útiles y durante cuánto tiempo conservarlos. Para que sean útiles, los archivos de registro deben poder buscarse fácilmente según suficientes criterios diferentes para satisfacer las necesidades de los distintos buscadores.

Analizamos el soporte de registro con OpenTelemetry Collector y, al momento de escribir esto, se encuentra en una fase muy beta. Decidimos utilizar ELK para registrarnos a corto plazo mientras continuamos investigando otras opciones.

A falta de cualquier razón convincente para no hacerlo, optamos por utilizar las herramientas Elasticsearch , que nos permiten dividir la implementación en nodos de ingesta, coordinación, maestros y datos . Para facilitar la implementación, utilizamos un gráfico de Bitnami . Para transportar datos, implementamos Filebeat como parte de un DaemonSet de Kubernetes. Se agregó la funcionalidad de búsqueda implementando Kibana y aprovechando los índices, las búsquedas, las visualizaciones y los paneles precargados.

Rápidamente se hizo evidente que, si bien esta solución funcionaba, la configuración predeterminada consumía muchos recursos, lo que dificultaba su ejecución en un espacio con recursos más reducido, como K3S o Microk8s . Agregar la capacidad de ajustar la cantidad de réplicas para cada componente solucionó este problema, pero provocó algunas fallas que posiblemente se debieron al agotamiento de recursos o a volúmenes excesivos de datos.

Lejos de decepcionarnos por esto, lo vemos como una oportunidad para evaluar nuestro sistema de registro con diferentes configuraciones, así como para investigar otras opciones como Grafana Loki y Graylog . Es posible que descubramos que las soluciones de registro más livianas no brindan el conjunto completo de funciones que algunos usuarios necesitan y pueden obtener de herramientas que consumen más recursos. Dada la naturaleza modular de MARA , es probable que construyamos módulos adicionales para estas opciones para brindarles a los usuarios más opciones.

Implementación del rastreo distribuido

Más allá de determinar qué herramienta proporciona la funcionalidad de rastreo que queremos, necesitábamos considerar cómo implementar la solución y qué tecnologías deben integrarse con ella.

En primer lugar, queríamos asegurarnos de que ninguna instrumentación afectara negativamente la calidad del servicio de la aplicação en sí. Todos habíamos trabajado con sistemas en los que el rendimiento caía previsiblemente una vez por hora a medida que se exportaban los registros, y no teníamos ningún deseo de revivir esa experiencia. La arquitectura del OpenTelemetry Collector fue convincente en este aspecto porque puede ejecutar una instancia por host. Cada recopilador recibe datos de clientes y agentes en todas las diferentes aplicações que se ejecutan en el host (en contenedores o no). El recopilador agrega y potencialmente comprime los datos antes de enviarlos a un servidor de almacenamiento, lo que parecía ideal.

A continuación, evaluamos el soporte para OpenTelemetry en los diferentes lenguajes de programación y marcos que estamos usando en la aplicação. Aquí las cosas se pusieron un poco más complicadas. A pesar de utilizar sólo los dos lenguajes de programación y los marcos asociados que se muestran en la tabla, el nivel de complejidad fue sorprendentemente alto.

Idioma Marco Número de servicios
Java Bota de primavera 3
Python Matraz 3

Para agregar seguimiento a nivel de idioma, primero probamos los agentes de instrumentación automática de OpenTelemetry, pero descubrimos que su salida era desordenada y confusa. Estamos seguros de que esto mejorará a medida que maduren las bibliotecas de instrumentación automática, pero por el momento descartamos los agentes OpenTelemetry y decidimos incorporar el seguimiento en nuestro código.

Antes de saltar a una implementación directa del seguimiento en el código, primero conectamos el recopilador OpenTelemetry para enviar todos los datos de seguimiento a una instancia de Jaeger que se ejecuta localmente donde podemos ver la salida más fácilmente. Esto fue bastante útil, ya que pudimos jugar con la presentación visual de los datos de seguimiento mientras descubríamos cómo integrar completamente OpenTelemetry. Por ejemplo, si descubrimos que una biblioteca de cliente HTTP no incluía datos de seguimiento al realizar llamadas a un servicio dependiente, colocamos el problema en nuestra lista de soluciones de inmediato. Jaeger presenta una bonita vista de todos los diferentes tramos dentro de un único trazo:

Seguimiento distribuido para Python

Agregar seguimiento a nuestro código Python fue relativamente sencillo. Agregamos dos archivos fuente de Python a los que hacen referencia todos nuestros servicios y actualizamos los respectivos archivos requirements.txt para incluir las dependencias opentelemetry-instrumentation-* relevantes. Esto significó que podíamos usar la misma configuración de seguimiento para todos los servicios de Python, así como incluir el ID de seguimiento de cada solicitud en los mensajes de registro e integrar el ID de seguimiento en las solicitudes a los servicios dependientes.

Seguimiento distribuido para Java

A continuación, dirigimos nuestra atención a los servicios Java. Usar las bibliotecas Java de OpenTelemetry directamente en un proyecto nuevo es relativamente sencillo: todo lo que necesita hacer es importar las bibliotecas necesarias y usar la API de seguimiento directamente . Sin embargo, si utiliza Spring como lo hacemos nosotros, tendrá que tomar decisiones adicionales.

Spring ya tiene una API de seguimiento distribuido, Spring Cloud Sleuth . Proporciona una fachada sobre la implementación de seguimiento distribuido subyacente que hace lo siguiente, como se describe en la documentación:

  • Agrega identificadores de seguimiento y de intervalo al MDC de Slf4J, de modo que pueda extraer todos los registros de un seguimiento o intervalo determinado en un agregador de registros.
  • Instrumentos de puntos de entrada y salida comunes de aplicações Spring (filtro de servlet, plantilla de descanso, acciones programadas, canales de mensajes, cliente fingido).
  • Si spring-cloud-sleuth-zipkin está disponible, … [genera e informa] seguimientos compatibles con Zipkin a través de HTTP. De forma predeterminada, los envía a un servicio recopilador Zipkin en localhost (puerto 9411). Configure la ubicación del servicio usando spring.zipkin.baseUrl .

La API también nos permite agregar seguimientos a las tareas anotadas @Scheduled .

En otras palabras, al utilizar solo Spring Cloud Sleuth, obtenemos rastros a nivel de los puntos finales del servicio HTTP de manera inmediata, lo que es un beneficio interesante. Como nuestro proyecto ya utiliza Spring, decidimos mantener todo dentro de ese marco y utilizar las características proporcionadas. Sin embargo, descubrimos algunos problemas mientras conectábamos todo con Maven :

  • El módulo de autoconfiguración de Spring Cloud Sleuth aún se encuentra en un lanzamiento histórico.
  • El módulo de autoconfiguración de Spring Cloud Sleuth depende de una versión alfa obsoleta de opentelemetry-instrumentation-api . Actualmente no existe ninguna versión reciente que no sea alfa 1.x de esta biblioteca.
  • El proyecto debe extraer el modelo de objetos del proyecto principal (POM) spring-cloud-build de los repositorios Spring Snapshot debido a la forma en que Spring Cloud Sleuth codifica sus referencias de dependencia para los lanzamientos importantes.

Esto hizo que la definición de nuestro proyecto Maven fuera un poco más complicada, porque teníamos que hacer que Maven extrajera de los repositorios de Spring así como de Maven Central, una clara indicación de cuán incipiente era el soporte de OpenTelemetry en Spring Cloud. Sin embargo, seguimos adelante y creamos un módulo de telemetría común para configurar el rastreo distribuido utilizando Spring Cloud Sleuth y OpenTelemetry, completo con varias funciones auxiliares y extensiones relacionadas con la telemetría.

En el módulo de telemetría común, ampliamos la funcionalidad de rastreo proporcionada por las bibliotecas Spring Cloud Sleuth y OpenTelemetry al proporcionar:

Además, implementamos un cliente HTTP compatible con Spring que está respaldado por el cliente HTTP Apache, porque queríamos más métricas y personalización al realizar llamadas HTTP entre servicios. En esta implementación, los identificadores de seguimiento y de intervalo se pasan como encabezados cuando se llaman a los servicios dependientes, lo que permite incluirlos en la salida del seguimiento. Además, esta implementación proporciona métricas del grupo de conexiones HTTP que se agregan mediante OpenTelemetry.

En general, fue un esfuerzo conseguir que el rastreo se conectara con Spring Cloud Sleuth y OpenTelemetry, pero creemos que valió la pena. Esperamos que este proyecto y este post ayuden a iluminar el camino para otros que quieran recorrer este camino.

Rastreo distribuido para NGINX

Para obtener trazas que conectan todos los servicios durante todo el ciclo de vida de una solicitud, necesitábamos integrar OpenTelemetry en NGINX. Para ello, utilizamos el módulo OpenTelemetry de NGINX (aún en versión beta). Anticipando que podría ser potencialmente difícil obtener binarios funcionales del módulo que funcionen con todas las versiones de NGINX, creamos un repositorio de GitHub de imágenes de contenedores que incorporan módulos NGINX no compatibles. Ejecutamos compilaciones nocturnas y distribuimos el binario del módulo a través de imágenes Docker que son fáciles de importar.

Todavía no hemos integrado este proceso en el proceso de compilación del controlador de ingreso NGINX en el proyecto MARA , pero planeamos hacerlo pronto.

Implementación de la recopilación de métricas

Después de completar la integración de seguimiento de OpenTelemetry, nos centramos en las métricas. No existían métricas para nuestras aplicações basadas en Python y decidimos posponer su incorporación por ahora. Para las aplicações Java, el código fuente original de Bank of Anthos , que utiliza Micrometer junto con Stackdriver de Google Cloud, admite métricas. Sin embargo, eliminamos ese código de Bank of Sirius después de bifurcar Bank of Anthos, porque no nos permitía configurar un backend de métricas. Sin embargo, el hecho de que los ganchos métricos ya estuvieran presentes hablaba de la necesidad de una integración adecuada de las métricas.

Para llegar a una solución configurable y pragmática, primero analizamos el soporte métrico dentro de las bibliotecas Java de OpenTelemetry y Micrometer. A partir de una búsqueda de comparaciones entre las tecnologías, varios resultados enumeraron las deficiencias de OpenTelemetry utilizado como API de métricas en la JVM, a pesar de que las métricas de OpenTelemetry todavía están en versión alfa al momento de escribir este artículo. Micrometer es una capa de fachada de métricas madura para la JVM, similar a slf4j al proporcionar un contenedor de API común que encierra una implementación de métricas configurables en lugar de una implementación de métricas propia. Curiosamente es la API de métricas predeterminada para Spring.

En este punto estábamos sopesando los siguientes hechos:

  • El recopilador OpenTelemetry puede consumir métricas de prácticamente cualquier fuente, incluidos Prometheus , StatsD y el protocolo nativo OpenTelemetry (OTLP).
  • Micrometer también admite una gran cantidad de backends de métricas, incluidos Prometheus y StatsD
  • El SDK de métricas de OpenTelemetry para JVM admite el envío de métricas a través de OTLP

Después de algunos experimentos, decidimos que el enfoque más pragmático era utilizar la fachada Micrometer con una implementación de respaldo Prometheus y configurar OpenTelemetry Collector para usar la API Prometheus para extraer métricas de la aplicação. Sabíamos por numerosos artículos que la falta de tipos de métricas en OpenTelemetry puede causar problemas, pero nuestros casos de uso no necesitan esos tipos, por lo que el compromiso fue aceptable.

Descubrimos una cosa interesante sobre OpenTelemetry Collector: aunque lo habíamos configurado para recibir seguimientos a través de OTLP y métricas a través de la API de Prometheus, todavía se puede configurar para enviar ambos tipos de datos a un receptor de datos externo mediante OTLP o cualquier otro protocolo compatible. Esto nos permitió probar fácilmente nuestra aplicação con LightStep .

En general, codificar métricas en Java fue bastante simple porque las escribimos para cumplir con la API de Micrometer, que tiene numerosos ejemplos y tutoriales disponibles. Probablemente lo más difícil, tanto para las métricas como para el seguimiento, fue conseguir que el gráfico de dependencia de Maven en el archivo pom.xml para telemetry-common fuera correcto.

Implementación de la agregación de errores

El proyecto OpenTelemetry no incluye la agregación de errores en su misión per se, y no proporciona una implementación de etiquetado de errores tan elegante como soluciones como Sentry o Honeybadger.io . Sin embargo, decidimos utilizar OpenTelemetry para la agregación de errores a corto plazo en lugar de agregar otra herramienta. Con una herramienta como Jaeger, podemos buscar error=true para encontrar todos los rastros con una condición de error. Esto al menos nos da una idea de lo que suele salir mal. En el futuro, podríamos considerar agregar la integración de Sentry .

Implementación de comprobaciones de estado e introspección en tiempo de ejecución

En el contexto de nuestra aplicação, los controles de estado permiten a Kubernetes saber si un servicio está en buen estado o ha completado su fase de inicio. En los casos en que el servicio no funciona correctamente, Kubernetes se puede configurar para finalizar o reiniciar las instancias. En nuestra aplicação, decidimos no utilizar los controles de estado de OpenTelemetry porque consideramos que la documentación era insuficiente.

En cambio, para los servicios JVM utilizamos un proyecto Spring llamado Spring Boot Actuator que proporciona no solo puntos finales de comprobación del estado, sino también puntos finales de introspección en tiempo de ejecución y de volcado de montón. Para los servicios de Python, utilizamos el módulo Flask Management Endpoints que proporciona un subconjunto de las características de Spring Boot Actuator. Actualmente, solo proporciona información de aplicação personalizables y controles de estado.

Spring Boot Actuator se conecta a la JVM y a Spring para proporcionar puntos finales de introspección, monitoreo y verificación del estado. Además, proporciona un marco para agregar información personalizada a los datos predeterminados que presenta en sus puntos finales. Los puntos finales proporcionan introspección en tiempo de ejecución sobre cuestiones como el estado de la caché, el entorno de ejecución, las migraciones de bases de datos, los controles de estado, la información de la aplicação personalizable, las métricas, los trabajos periódicos, el estado de la sesión HTTP y los volcados de subprocesos.

Los puntos finales de verificación de estado tal como los implementa Spring Boot Actuator tienen una configuración modular, de modo que el estado de un servicio puede estar compuesto por múltiples verificaciones individuales que se clasifican como de actividad o preparación. También está disponible un control de salud completo que muestra todos los módulos de verificación y que generalmente se ve así .

Los puntos finales informativos se definen en un documento JSON como un único objeto JSON de alto nivel y una serie de claves y valores jerárquicos. Normalmente, el documento especifica el nombre y la versión del servicio, la arquitectura, el nombre del host, la información del sistema operativo, el ID del proceso, el nombre del ejecutable y detalles sobre el host, como un ID de máquina o un ID de servicio único.

Implementación de volcados de memoria y de núcleo

Es posible que recuerdes de la tabla que aparece en Comparación de características de la herramienta con la lista de deseos que ninguna de las herramientas admite la introspección en tiempo de ejecución o volcados de montón/núcleo. Sin embargo, Spring, nuestro marco subyacente, admite ambos, aunque llevó algo de trabajo integrar las funciones de observabilidad en la aplicação. Como se detalla en la sección anterior, para la introspección en tiempo de ejecución utilizamos un módulo de Python junto con Spring Boot Actuator.

De la misma manera, para los volcados de montón usamos los puntos finales de volcado de subprocesos proporcionados por Spring Boot Actuator para lograr un subconjunto de las características que queríamos. No podemos obtener volcados de núcleo a pedido ni volcados de montón de la JVM con el nivel de granularidad ideal, pero obtenemos parte de la funcionalidad deseada con poco esfuerzo adicional. Lamentablemente, los volcados de núcleo para los servicios de Python requerirán una cantidad considerable de trabajo adicional que hemos pospuesto hasta una fecha posterior.

resumen

Después de mucho llorar y cuestionar nuestras decisiones de vida, hemos convergido en el uso de las siguientes tecnologías para la observabilidad en el MARA (en adelante, OTel significa OpenTelemetry):

  • Registro (para todos los contenedores) – Filebeat → Elasticsearch / Kibana
  • Rastreo distribuido
    • Java – Spring Cloud Sleuth → Exportador Spring Cloud Sleuth para OTel → OTel Collector → Exportadores conectables como Jaeger, Lightstep, Splunk, etc.
    • Python – Bibliotecas de Python de OTel → Colector de OTel → almacén conectable
    • NGINX y NGINX Plus (el controlador de ingreso NGINX aún no es compatible) – Módulo OTel de NGINX → Colector OTel → Exportador conectable
  • Recopilación de métricas
    • Java – Micrómetro vía Spring → Exportador Prometheus → Colector OTel
    • Python – Sin implementación aún
    • Python WSGI – GUnicorn StatsD → Prometheus (a través de StatsD / ServiceMonitor)
    • NGINX – Punto final de Prometheus → Prometheus (a través de ServiceMonitor)
  • Agregación de errores : trazas distribuidas de OTel → exportador conectable → funcionalidad de búsqueda del exportador para encontrar trazas marcadas con error
  • Comprobaciones de estado
    • Java – Actuador Spring Boot → Kubernetes
    • Módulo de puntos finales de gestión de Flask en Python → Kubernetes
  • Introspección en tiempo de ejecución
    • Java – Actuador de arranque Spring
    • Módulo de puntos finales de gestión de Flask de Python
  • Volcados de pila/núcleo
    • Java : compatibilidad del actuador Spring Boot con volcados de subprocesos
    • Python – Sin soporte todavía

Esta implementación es una instantánea en el tiempo. Definitivamente cambiará y evolucionará a medida que continúe el desarrollo. Pronto ejecutaremos la aplicação a través de pruebas de carga exhaustivas. Esperamos aprender mucho sobre las deficiencias de nuestro enfoque de observabilidad y agregar características de observabilidad adicionales.

Pruebe la arquitectura de referencia de aplicaciones modernas y la aplicação de muestra (Bank of Sirius). Si tiene ideas sobre cómo podemos hacerlo mejor, ¡agradecemos sus contribuciones en nuestro repositorio de GitHub !

Publicaciones relacionadas

Esta publicación es parte de una serie. A medida que vayamos añadiendo capacidades a MARA, publicaremos los detalles en el blog:

Leer más publicaciones de blog sobre F5 NGINX ›

"Esta publicación de blog puede hacer referencia a productos que ya no están disponibles o que ya no reciben soporte. Para obtener la información más actualizada sobre los productos y soluciones F5 NGINX disponibles, explore nuestra familia de productos NGINX . NGINX ahora es parte de F5. Todos los enlaces anteriores de NGINX.com redirigirán a contenido similar de NGINX en F5.com.