Observabilidad con Elastic APM - Informe de análisis técnico

Autor Olivera Lucas.

Introducción

La observabilidad de las aplicaciones es fundamental en la búsqueda de aumentar la calidad, seguridad y performance de estas, siendo un factor clave para detectar errores, conocer puntos de falla o mejora, auditar el trabajo de nuestra aplicación mientras no la estamos observando. Actualmente en la empresa disponemos de la política de centralización de logging con Elastic, esto nos permite auditar los logs que producen las aplicaciones en búsqueda de conocer algún error o validar el funcionamiento. Sin embargo, existen otros indicadores que debemos medir y conocer en pos de mejorar la calidad de nuestro software. Con esto nos referimos al uso de Métricas de aplicación y al Treacing (Seguimiento) de las aplicaciones. Con respecto a las Métricas de aplicación algunos desarrollos se encuentran utilizando Prometheus con Grafana para su visualización, pero se comprobó que la implementación actual de estas herramientas no es viable con una estrategia de orquestación de conteiner. Por lo que, se buscaron alternativas para poder tener métricas de aplicación y surgieron dos posibles candidatos, Elastic APM y OpenTelemetry. Este documento evidencia la PoC que se realizó con ambas tecnologías.

Requisitos técnicos

Se busca con esta PoC que las tecnologías cumplan con los siguientes requisitos técnicos:

1. Debe ser compatible con la estrategia de despliegue en conteiner.
2. Las aplicaciones deben ser auto declarativas.
3. Debe ser aplicable a múltiples lenguajes (C#, Go, Python, Java).
4. Debe disponer de UI para analizar las métricas y permitir crear dashboard.

Elastic APM

¿Qué es?

El servicio Elastic APM entra dentro de la gama de productos de Elastic llamado Observability. Esta gama de productos unifica logs, métricas y trazas de APM en un mismo panel de Kibana.

Entre otras muchas cosas, Elastic APM nos permite monitorizar cosas como:

• Media de latencias
• Rendimiento de la app (transacciones por segundo)
• Transacciones (con su latencia media, tps, ratio de error e impacto)
• Ratios de error
• Lista de errores
• Traza completa de cada transacción (traza de cada request)

También permite generar alertas y reglas, de forma que podamos enterarnos antes ante un comportamiento anómalo de la aplicación.

¿Qué necesitamos para usar Elastic APM?

Para poder monitorizar nuestra aplicación en Elastic APM necesitamos los siguientes servicios:

• Servicio Elastic APM
• Servicio Elasticsearch
• Servicio Kibana

También se necesita el Agente del servicio que se necesita monitorizar.

El Servicio de Elastic APM se encuentra disponible en la versión community de Elastic, pero algunas de sus funcionalidades se encuentran reservadas para los tier pagos de Elastic, sin embargo, la PoC se realizo con la versión community.

¿Cómo trabajamos con Elastic APM?

Para poder integrarnos con Elastic APM debemos utilizar lo que se conoce como “Agent”, el agente es el software que tiene la responsabilidad de llevar las métricas, logs y tracking al servidor de elastic, cada proyecto debe contener el Agente para poder integrarse. Tenemos a disposición el agente en las siguientes tecnologías

• Go
• IOS
• Java
• .NET
• Node.js
• PHP
• Python
• Ruby
• Real User monitoring Javascript

Los agentes por lo generar son librerías, que facilitan la iteración con elastic APM Detalle de la PoC

Se desplego un servidor con el servicio de Elastic APM y sus requerimientos, se implementaron los agentes en desarrollos realizados en Python, .NET y Go. Desarrollo

El esfuerzo de incluir el agente de elastic en los desarrollos es mínimo, en la mayoría de los casos con solo importar la librería correspondiente y configurando el desarrollo para incluir el agente basto para tener una gran observabilidad.

El agente por defecto exporta:

• Media de latencias
• Rendimiento de la app (transacciones por segundo)
• Transacciones (con su latencia media, tps, ratio de error e impacto)
• Ratios de error
• Lista de errores
• Traza completa de cada transacción (traza de cada request)

Pero también permite agregar algunos “Tags” a las operaciones para aumentar la visibilidad. El problema que posee es que no se permite generar métricas custom, por lo que en caso de necesitar mediciones o exportar algún tipo de valor, no esta soportado por los agentes.

Resultados

A continuación, se muestra algunas imágenes con los dashboard que te genera por defecto el agente de elastic.

Listado de APPS

El APM de elastic nos permite ver todas las aplicaciones que tiene registradas, teniendo la posibilidad de realizar búsqueda y filtrado.

Transacciones

Distribuited Treancing

Dependencies

Check de requerimientos

1. Debe ser compatible con la estrategia de despliegue en conteiner: Al disponer de un componente como Agent, cada aplicación es la encargada de “llevar” sus métricas hacia elastic APM por lo que en caso de tener una app con múltiples instancias, cada instancia publicará sus métricas en elastic y tendremos el resumen global de la aplicación.
2. Las aplicaciones deben ser auto declarativas: Cada aplicación declara su nombre y comienza a publicar sus métricas, no es requerido ninguna operación previa.
3. Debe ser aplicable a múltiples lenguajes (C#, Go, Python, Java): Hemos mencionado el listado de apps disponibles de esta tecnología.
4. Debe disponer de UI para analizar las métricas y permitir crear dashboard: Sin ningún tipo de esfuerza disponemos de dashboard que visualizan lo que sucede en nuestra app, sin embargo, existe la posibilidad de generar nuevos dashboard con kibana.

Ventajas y Desventajas

Elastic APM cumple con todos los requerimientos técnicos, pero encontramos las siguientes desventajas de su uso.

1. Dependencia con la tecnología de Elastic.
2. Imposibilidad de crear métricas custom por el momento.
3. Necesidad de adquirir licenciamiento para explotar la herramienta como un APM Ventajas:
4. Implementación simple.
5. Buena documentación.
6. Soporte por parte de Elastic y la comunidad de Elastic.
7. Gran cantidad de indicadores de monitoreo (dashboard) por defecto.
8. Posibilidad de generar gráficos custom con kibana por fuera del APM

OpenTelemetry

¿Qué es?

OpenTelemetry es un conjunto de API, SDK, herramientas e integraciones diseñadas para la creación y gestión de datos de telemetría, como seguimientos, métricas y registros. El proyecto proporciona una implementación independiente del proveedor que se puede configurar para enviar datos de telemetría a los back-end de su elección. Admite una variedad de proyectos populares de código abierto, incluidos Jaeger y Prometheus. OpenTelemetry no es un back-end de observabilidad como Jaeger o Prometheus. En cambio, admite la exportación de datos a una variedad de back-end comerciales y de código abierto. Proporciona una arquitectura conectable para que se puedan agregar fácilmente protocolos y formatos de tecnología adicionales. OpenTelemetry proporciona: • Una única biblioteca de instrumentación independiente del proveedor por idioma con soporte para instrumentación automática y manual. • Un binario de un solo recopilador que se puede implementar de varias maneras, incluso como agente o puerta de enlace. • Una implementación de extremo a extremo para generar, emitir, recopilar, procesar y exportar datos de telemetría. • Control total de sus datos con la capacidad de enviar datos a múltiples destinos en paralelo a través de la configuración. • Convenciones semánticas de estándar abierto para garantizar la recopilación de datos independiente del proveedor • La capacidad de admitir múltiples formatos de propagación de contexto en paralelo para ayudar con la migración a medida que evolucionan los estándares. • Un camino a seguir sin importar dónde se encuentre en su viaje de observabilidad. Con soporte para una variedad de protocolos comerciales y de código abierto, mecanismos de propagación de contexto y formato, además de proporcionar correcciones a los proyectos OpenTracing y OpenCensus, es fácil adoptar OpenTelemetry.

¿Cómo trabajamos con OpenTelemetry?

Como se mencionó previamente, OpenTelemetry dispone de un conjunto de librerías multilenguaje para su implementación. Los lenguajes soportados son: • C++ • .NET • Erlang/Elixir • Go • Java • JavaScript • PHP • Python • Ruby • Rust • Swift

Detalle de la PoC

Se desarrollo una app con .NET y Java para probar la implementación del agente de OpenTelemetry. OpenTelemetry, al ser un estándar donde puede tener varias herramientas para visualizar su información (Jeagger, Prometheus, etc), es soportado nativamente por Elastic APM desde la versión 7.13 por lo tanto obtuvimos los mismos gráficos obtenidos con el Agente de Elastic. Desarrollo

NET

Para implementar el Agente de OpenTelemetry en NET debemos descargar sus librerías y realizar la configuración. Para la configuración hay que tener en cuenta hacia donde exportamos los datos, este caso fue configurar para que publique las métricas en Elastic APM server. Luego se debe especificar que queremos exportar. Por lo que OpenTelemetry nos provee de otras librerías que debemos configurar si queremos exportar tracking de request http, aspnet o base de datos. Ya que esto no viene por defecto en el Core de la biblioteca. Otra de las cosas a tener en cuenta es que nos permite generar métricas y tags custom lo que nos permite generar información adicional a la por defecto, lo que implica realizar un análisis para saber qué es lo que necesitamos mostrar en los gráficos. Sin otro tipo de implementación obtuvimos un gráfico similar al del agente de elastic.

JAVA

Para implementar el Agente de OpenTelemetry en Java realizamos una app en Spring Boot básica y utilizamos la implementación automática del agente. La instrumentación automática con Java utiliza un JAR de agente Java que se puede adjuntar a cualquier aplicación Java 8+. Inyecta dinámicamente código de bytes para capturar la telemetría de muchas bibliotecas y marcos populares. Se puede usar para capturar datos de telemetría en los "bordes" de una aplicación o servicio, como solicitudes entrantes, llamadas HTTP salientes, llamadas a bases de datos, etc. Por supuesto que OpenTelemetry tiene una forma manual para configurar el sdk y disponer de métricas custom, pero no lo hemos probado para realizar esta poc.

Resultados

Check de requerimientos

1. Debe ser compatible con la estrategia de despliegue en conteiner: Al disponer de un componente como Agent, cada aplicación es la encargada de “llevar” sus métricas hacia elastic APM por lo que en caso de tener una app con múltiples instancias, cada instancia publicará sus métricas en elastic y tendremos el resumen global de la aplicación.
2. Las aplicaciones deben ser auto declarativas: Cada aplicación declara su nombre y comienza a publicar sus métricas, no es requerido ninguna operación previa.
3. Debe ser aplicable a múltiples lenguajes (C#, Go, Python, Java): Hemos mencionado el listado de apps disponibles de esta tecnología.
4. Debe disponer de UI para analizar las métricas y permitir crear dashboard: para el caso de la PoC, al utilizar Elastic APM como server de recolección disponemos de la interface de Kibana para visualizar la información, en caso de ser necesario se podría utilizar otra herramienta para ver el treacing y las métricas. Por ejemplo, Jeager, zipkin, Grafana, otros.

Ventajas y Desventajas

El agent de OpenTelemetry cumple con los requerimientos técnicos, sin embargo, se encontraron las siguientes desventajas 1. Se debe configurar la librería y dependemos de librerías extras para tener las métricas y treacing básicos. 2. Se requiere un mayor trabajo (con respecto al agente de elastic) en el código para exportar información. 3. No tenemos los mismos gráficos en Elastic APM que utilizando el agente nativo, por lo que debemos considerar generar nuevos dashboard. Por el contrario, el agente de OpenTelemetry tiene las siguientes ventajas: 1. Es independiente de las tecnologías, ya que dispone de un estándar y se vincula con diferentes herramientas. 2. Permite exportar métricas custom, lo que permitiría que personalicemos nuestros gráficos y/o alertas.

Elastic Agent vs OpenTelemetry Agent

	Elastic Agent	OTLP Agent	Observación
Lenguajes	X		El agente de elastic soporta menos lenguajes, pero tiene la ventaja de soportar aplicaciones de frontend por tanto es merecedor de este punto
Implementación	X		El uso del Agente de Elastic y su configuración para varios lenguajes es más simple que su competidor, además para lograr la cantidad de visibilidad que se logra con el agente hay que hacer un esfuerzo extra con el agente de OpenTelemetry
Versatilidad		X	El agente de elastic solo funciona con el stack de elastic, mientras que el agente de OTLP puede vincular a varias herramientas simultáneamente.
Visibilidad	X		Si bien, el agente OTLP se vincula con el APM de Elastic, este no consigue la misma vinculación que su competidor, lo que provoca que por defecto no tengamos tanto detalle en los registros.

Conclusión

Podemos concluir este análisis argumentando que, por un lado, ambas estrategias de observabilidad tienen a Elastic APM Server como punto en común, lo que nos permite estandarizar el componente de recolección y visualización de métricas / treacing. Por otro lado, el uso de alguno de los dos agentes tiene sus ventajas y desventajas, por lo que se debe tomar una decisión de cuando usar uno otro, dependiendo del contexto y la necesidad del proyecto en cuestión.

La recomendación es que el Agente de Elastic sea el estándar para la observabilidad de las aplicaciones ya que nos provee de una gran cantidad de información a un bajo costo, lo que puede entregar valor rápidamente al negocio, consecuentemente, se debe utilizar el Agente de OpenTelemetry para aquellos proyectos, en donde la visibilidad que nos ofrece el Agente de Elastic, no sea suficiente, por lo que necesitemos generar más mediciones o recabar información extra, asumiendo que debemos generar los gráficos nosotros mismos.

Por último, mencionar que en esta PoC no se profundizo en las virtudes de cada agente en búsqueda de obtener un mejor resultado de gráficos o visibilidad por lo que queda por interiorizarse de las funcionalidades y particularidades que tiene cada agente en los lenguajes estándares de la empresa.

Anexo

Prueba de PoC

Se disponibilizó un repositorio con los desarrollos mencionados en este documento, el repositorio alberga en diferentes Branch cada app que se implementó en esta PoC, junto con este documento en la rama principal. Repo: https://github.com/architecture-it/poc-elastic-observability