Telemetría en integraciones distribuídas

En nuestro día a día, en los diferentes proyectos en los que participamos, vemos como el tratamiento de la metainformación generada por las integraciones (que posibilitan la observabilidad del comportamiento de estas) toma mayor peso.

En mi experiencia, las soluciones que se suelen plantear se enfocan a soluciones tácticas, habitualmente basadas en las herramientas que el cliente tiene o toma la decisión de incorporar, de forma que son soluciones a medida con un grado muy alto de acoplamiento. Es por ello que podemos plantearnos dar un paso más e ir a procesos de observabilidad estandarizados, que reduzcan a la mínima expresión el acoplamiento entre el proceso de observabilidad y la herramienta de centralización de dicha información.

Evidentemente plantearse aplicar una determinada estandarización no tiene sentido si dicha estandarización no ha sido o está siendo aceptada en el mercado y los productos la asumen y emplean. Este es el caso del estándar que vamos a explicar en este artículo.

Antes de hablar de la telemetría estandarizada, daremos una introducción al concepto de observabilidad, que podemos definir como la capacidad de analizar el comportamiento de una integración, sin entrar en los detalles internos de la misma. Posibilitando el análisis de las causas del comportamiento que se esté observando.

Para que la observabilidad sea posible las aplicaciones de integración necesitan estar instrumentadas para que el código pueda enviar señales (trazas, métricas y logs), también conocido como telemetría, que posibiliten esta observabilidad, además de requerir de un receptor de dichas señales, que se encargará de tratarlas, dicho receptor puede estar dentro de la propia plataforma de integración, o ser un componente externo (Jaeger, Zipkin, ELK, etc).

La instrumentación de la observabilidad, capacidad cada vez más demandada, está evolucionando de pasar de un escenario en el que cada herramienta de recogida de información de observabilidad, tiene sus propias librería y agentes para enviar la información, lo que implica una falta de estandarización y un alto acoplamiento con la aplicación receptora, de forma que si se cambia el impacto es muy alto, a un escenario con procesos estandarizados donde se reduzca el acoplamiento de forma que se puedan intercambiar datos con diferentes herramientas de observabilidad.

El proceso de estandarización surgió con la aparición de dos grupos de trabajo en la comunidad de la nube, con sendos proyectos open-source: El denominado OpenTracing, proyecto de la CNCF (Cloud Native Computing Foundation) que se centró en establecer un vendor-neutral API para el intercambio de datos de telemetría y OpenCensus, proyecto de la comunidad Google Open Source, que proveía de librerías, en diferentes lenguajes, para la implementación estandarizada de la telemetría. Ambos proyectos han sido unidos en el actual proyecto open-source: OpenTelemetry (OTel) que surgió en mayo del 2019 como proyecto de la CNCF y que tiene por meta el proveernos de un conjunto de SDK’s estandarizados y agnósticos de vendors, así como APIs estandarizadas de intercambio y las herramientas para la ingesta, transformación y envío de telemetría, desde el punto en el que se origina hasta el receptor-gestor de la misma. En definitiva, una arquitectura adaptable para implementar la observabilidad en entornos distribuidos.

Ahora esbozaremos los principales puntos de una Arquitectura de Telemetría basada en OpenTelemetry y empezaremos por introducir ciertos conceptos.

Conceptos básicos sobre Telemetría

Un APM Server, es la aplicación receptora de la telemetría y que aporta las capacidades de visualización y análisis que la observabilidad requiere.

Un Log es un mensaje, con marca de tiempo, emitido por un servicio o componente y que a diferencia de las trazas no está necesariamente asociado a una petición de cliente, no suele contener información contextual. Habitualmente se suelen incluir en el siguiente componente.

Un Span o evento, representa a una unidad de trabajo u operación y habitualmente hace un traceo de las operaciones de una determinada petición, mostrando una imagen de lo acontecido durante su realización. Los Span suelen contener un nombre o identificador, marcas de tiempo, mensajes con estructura y otras informaciones del contexto. Ejemplos de eventos o Span, la recepción de un mensaje de petición de servicio, la publicación de un mensaje en un sistema de colas, etc.

Una Traza o rastreo distribuido, registra las rutas tomadas por las solicitudes a medida que progresan entre los diferentes servicios. Es por ello por lo que es la herramienta ideal para hacer un análisis de lo acontecido durante el tratamiento de una solicitud. Una Traza se compone de uno o más Spans unidos entre sí, organizados jerárquicamente de más generales a más específicos con una relación padre-hijo.

Podemos definir las métricas (Metrics) como un valor o medida de una faceta concreta de una aplicación, por ejemplo; el uso de CPU, el uso de la Memoria o el número de peticiones exitosas.

Retomando la instrumentación, OTel ofrece dos vías para su realización:

La instrumentación automática, que es la forma más sencilla para adaptar las aplicaciones a la generación estandarizada de telemetría basada en Span y trazas.

La instrumentación manual, que suele ser necesaria cuando no se dispone de SDK’s o componentes para su implementación, bien por la plataforma usada para la integración, bien por el lenguaje de programación utilizado. Este es el caso de MuleSoft. Por ello se requerirá de manualmente instrumentar las API App para generar datos telemétricos consistentes y acordes al estándar OpenTelemetry.

Entenderemos por biblioteca instrumentalizada a una biblioteca configurada manual o automáticamente para generar span y trazas. Los cuales deberán ser enviados a alguna herramienta de análisis, para ello se suele emplear los Exporter, que son componentes que obtienen la información de telemetría para ser enviada a las herramientas de análisis.

Se llama Colector (Collector) a una única biblioteca facilitada por el proyecto OpenTelemetry que se emplea para recibir, procesar y exportar datos de telemetría a las herramientas de análisis, si así se necesita. Normalmente se trata de un “agente” que se encarga de dichas tareas.

Es por ello que disponemos de dos vías para el envío de la telemetría, los Exporter o los Collectors, la decisión de usar uno u otro, dependerá de si se desea o no incluir en el código de la API App la capacidad de enviar la telemetría hacia las herramientas de análisis, caso de los Exporters o también conocidos como Appenders, o dejarlo fuera de la API app, caso de los Collectors, como por ejemplo Fluent-Bit, o hacer uso de una mezcla de ambos, incluyendo los exporters para que envíen la información a los Collectors y éstos gestionar el envío a las herramientas de análisis, asumiendo los procesos de encriptación, reintentos, etc.

OpenTelemetry Protocol (OTLP) es el formato estándar para almacenar y transmitir datos, dentro del proyecto que se basa en la comunicación gRPC y HTTP 1.1 para entablar la comunicación y con el protocolo de Buffers (Protobuf), estándar de Google, que se emplea en la estandarización de los payloads de intercambio.

Introducidos estos conceptos básicos sobre Telemetría, veamos ahora cómo se relacionan la Telemetría y MuleSoft. MuleSoft como producto o plataforma utilizada para la realización y gobierno de integraciones, habitualmente distribuidas.

La plataforma dispone de una capa de observabilidad, que varía en base al tipo de licencia, y que posibilita analizar logs y el traceo de ciertos eventos, desde el punto de vista del consumo general, como número de llamadas, correctas y fallidas, y aspectos de esta índole, pero sin el detalle interno de cada una de ellas, así como las métricas de performance habituales (CPU, RAM, etc.…), todo ello con el protocolo propio de Anypoint MuleSoft. Esta capacidad nos posibilita observabilidad de las integraciones en el entorno de la propia plataforma, pero no nos da la capacidad ni de tener la visión E2E ni nos posibilita la externalización de esta a nivel trazas, con un sistema estandarizado.

Es por ello por lo que surge la necesidad de usar este tipo de módulos o componentes que nos provea de la capacidad de externalizar las trazas y centralizar así la gestión de las mismas.

Dado el gap descrito una solución que cubra lo que se conoce como el “Observability Trinity”

Requerirá de la incorporación de algún agente de OTel:

Ejemplo de uso E2E:

Veamos un esquema de cómo quedaría reflejado la externalización de la telemetría en un API Led.

Cómo implementar OTel en un caso de uso:

Para implementarlo en un caso de uso, deberemos implementar un módulo-agente o hacer uso de alguno ya creado que sea compliace con OTel, y a modo muestra explicaremos cómo integrar un agente ya creado que actuará como una extensión MuleSoft desarrollada para instrumentalizar la exportación de datos específicos de telemetría a cualquier collector que acepte el protocolo OpenTelemetry.

Digital Lover

Pasamos a describir los principales pasos para su aplicación:

Proceso general:

Paso 1: Descargar el módulo externo que contiene la lógica para aplicar el traceo en MuleSoft. Disponemos de varios y recientes módulos con esta capacidad, como ejemplo haremos la descarga de otel-mule4-observability-agent-1.0.2-mule-plugin.jar desde el repositorio.

Paso 2: Instalar, con Anypoint Studio, el fichero extensión en nuestro Maven local.

Pulsaremos en “Install Artifact in local repository”

Y pulsaremos Install.

NOTA: Este proceso es común a todos los proyectos en los que posteriormente se incluirán la gestión de trazas OTel y sólo es necesario realizarlo una vez.

Proceso por cada proyecto:

Paso 1: Agregar el módulo al proyecto en el que se desea aplicar la gestión de trazas OTel.

Para ello deberemos agregar el fichero de “global.xml” o similar la siguiente configuración:

Para ello seguiremos los pasos siguientes:

  • Pulsar el botón Create desde la solapa “Global Elements
  • Seleccionar el “Connector Configuration” “OpenTelemetry Mule 4 Observability Agent Config
  • Pulsar OK
  • Cumplimentar los campos siguientes:

Trace Collector Endpoint: End point del APM donde se recogerán y tratarán los mensajes de las trazas. En el ejemplo en una instancia local, como se puede observar, pero que dependerá del vendor o solución de centralización de logs y trazas que el cliente tenga o vaya a implantar.

OTLP Transport Protocol: HTTP_PROTOBUF o HTTP_JSON o GRPC

Así como valores de autorización y valores de entorno que se deberán adaptar a cada caso.

Y los procesadores y operación a los que se le aplicará el proceso de traceo.

Paso 2: En cada uno de los componentes, como en el ejemplo el http establecer en el “Settings” los valores que se requiera enviar, como el ejemplo:

Con este proceso capacitaremos a nuestra API App a enviar información de traceo en tiempo real al APM que tengamos configurado siguiendo el protocolo OTel.

Otras alternativas

Dentro de este mismo contexto, con una estandarización parcial tenemos componentes como ZIPKIN que, basándose en el estándar abierto Dapper de Google, ofrece componentes para la captura, almacenamiento y gestión de la telemetría.

Conclusiones

En este artículo hemos centrado el uso de OpenTelemetry en el contexto de la capa de integración, pero en realidad se podría o debería aplicar al resto de componentes que generen información de trazas y que conformen el sistema de información completo y con ello extender dicha estandarización a todos los puntos emisores de información relevante para la observabilidad. Para facilitar esta tarea, OpenTelemetry nos provee con módulos o bibliotecas en diferentes lenguajes que agilizan su aplicación.

Next

Este artículo introduce los conceptos y los pasos necesarios para estandarizar el envío de información de telemetría. En el próximo, realizaremos una evaluación de los principales APM y sus posibilidades de telemetría estandarizada, con casos de uso. Con ello esperamos aportar información valiosa a la hora de la toma de decisión de la herramienta a utilizar.

Referencias

  • OpenTelemetry 
  • OpenTracing 
  • OpenCensus 
  • Protocolo para OpenTelemetry (OTLP) 
  • gRPC: Es un protocolo del tipo RPC, de código abierto dentro de la CNCF y de altas prestaciones 
  • Splunk Telemetry 
  • AWS Distro for OpenTelemetry 
  • Azure 
  • Elastic 
  • Dynatrace 
  • Dynatrace e-book: "Observability and Beyond for the Enterprise Cloud"
  • Gartner: "Market Guide for Digital Experience Monitoring"
  • Gartner: "Magic Quadrant for Application Performance Monitoring - 2021"
  • GigaOm: "Radar for APM - 2021"
  • Lightstep: "Observability: A complete overview for 2021"
  • MuleSoft: "Anypoint Monitoring Overview"
  • MuleSoft: "Getting Started with Mule SDK for Java"
  • opentelemetry.io
  • Splunk e-book: "A Beginner’s Guide to Observability"
  • wc3.org: "Trace Context Draft Recommendation"
  • wc3.org: "Distributed Traces"

 

 

 

He leído y acepto la política de privacidad
Acepto recibir emails sobre actividades de recruiting NTT DATA