Info |
---|
Disponible desde versión 5.1.0 de Onesait Platform (Survivor). |
Table of Contents |
---|
...
Objetivo
El objetivo de esta funcionalidad es disponer de Trazas distribuidas en Plataforma, lo que nos permitirá rastrear Con el objetivo de incorporar nuevas capacidades en Onesait Platform en la construcción de MSA (Arquitectura de Microservicios), hemos incorporado la funcionalidad de Tracing distribuido.
Esta funcionalidad permite trazar una petición desde que entra al sistema hasta que se procesa.
La petición traceará desde la entrada, que puede ser un módulo de plataforma (como el Api Manager) o un microservicio gestionado por plataforma incluyendo todos los módulos de plataforma.
Objetivos de la funcionalidad
Con esta nueva funcionalidad añadida a la Onesait Platform, se pretende:
Monitorear transacciones distribuidas.
Poder resolver problemas optimización de rendimiento y latencia.
Análisis para obtener la raíz del problema.
Detección de anomalías.
Análisis de dependencia de servicios.
Propagación de contexto distribuido.
¿Cómo se ha soportado?
...
se genera hasta el final, lo cual es importante en una arquitectura de este tipo en el que una petición puede pasar por varios microservicios y módulos.
...
Además se incluye una UI para poder visualizar de forma sencilla la petición completa, lo que puede ayudar a diagnosticar problemas, ver cuellos de botella, tiempos largos,…
...
¿Cómo se ha soportado en Plataforma?
En la imagen se muestra un ejemplo de Tracing distribuido en el que intervienen dos microservicios y varios componentes de Plataforma.
...
Como se ve en la imagen, la solución incluye:
Open Telemetry Collector para recolectar las trazas de todos los componentes (de forma automática).
Jaeger Collector para convertir a trazar explotables.
DB OpenSearch para almacenar tracing.
Jaeger UI para visualizar tracing.
Tanto para los elementos externos como internos de plataforma, se utiliza el agente o el SDK de Open Telemetry para la instrumentación, y para obtener las trazas y enviarlas al colector Otel.
¿Qué es OTel?
El objetivo de https://opentelemetry.io/ es proporcionar un conjunto de SDK, API y herramientas estandarizadas e independientes del proveedor para ingerir, transformar y enviar datos a un back-end de Observabilidad.
Desde el colector de trazas de OTel se transmiten al colector Jaeger.
...
Conceptos básicos
Spans: Unidad individual de trabajo, son . Son intervalos temporales cerrados por ejemplo una llamada a un servicio, o a una base de datos.
Trazas: Conjunto de spans en una secuencia temporal desencadenadas por una acción inicial.
Scope (alcance): Formaliza donde se inicia y termina cada span.
Tags: Pares clave valor con información que se utilizan para consultas, filtros y trazas .
¿Qué es Jaeger?
Jaeger (Jaeger tracing) se utiliza para monitorear y solucionar problemas de sistemas distribuidos basados en microservicios, que incluyen:
Propagación de contexto distribuida
Monitoreo de transacciones distribuidas
Análisis de raíz de la causa
Análisis de dependencia del servicio
Optimización de rendimiento/latencia
Entre el colector de Jaeger y la base de datos Open Search se puede utilizar Kafka como una cola persistente intermediaria.
...
Open Telemetry
https://opentelemetry.io/ es un estándar en este ámbito y ofrece un conjunto de SDK, API y herramientas estandarizadas e independientes del proveedor para ingerir, transformar y enviar datos a un back-end de Observabilidad.
Jaeger
Jaeger tracing recoge las trazas de Open Telemetry a través de su colector, lo almacena en Open Search y permite exportarlo a través de la UI de Jaeger, integrada en el Control Panel.
Desde la UI, puedes hacer búsquedas en función del servicio que ha iniciado la llamada para ver toda la traza y comprobar porque por qué componentes ha navegado, el tiempo transcurrido e , y ver información de cada uno de estos spans.
...
Ejemplo
Para aclarar un poco estos conceptos se muestra como podrían interactuar 2 microservicios y estos con plataforma y como se verían las trazas simplificándolo un poco.
Uno de los microservicios puede estar configurado automáticamente y el otro manualmente.
Se realiza una solicitud al microservicio A, este a su vez realiza una solicitud al microservicio B.
El microservicio B para confeccionar una respuesta tiene que realizar dos llamadas al API Manager de plataforma y esta también realiza solicitudes al Semantic Inf Broker
Se puede apreciar que la traza es el conjunto de spans involucrados en todo el proceso a través del tiempo y como se pueden identificar cada span con el servicio al que pertenece y en el orden que se han ejecutado.
...
Un ejemplo real
...
Para este ejemplo se ha creado un micro servicio (demoservice) de Java con Spring Boot.
Se ha creado una entidad Customer, que almacena información de clientes y se han insertado unos cuantos registros.
También se ha creado un API Rest en plataforma para poder hacer consultas e inserciones sobre la entidad creada.
se ha levantado el microservicio exponiendo dos servicio rest en el puerto 8080, /getAll e /insert
...
/getAll --> invoca a un servicio de un api Rest de plataforma devolviendo todos los registros de una entidad
/insert -->intenta insertar un registro nuevo en esa entidad invocando a un api rest de plataforma creado para una entidad pero dará un error, para poder comprobar como se ven en las trazas
Se inicia el ejemplo con una herramienta como postman o cualquier otra para invocar el servicio getAll()
Como segundo paso vamos a ver en el control panel la UI de Jeager
...
Es sencillo trabajar con esta interfaz ya que en la parte izquierda tiene un formulario para las búsquedas y en la derecha los resultados.
Además al pulsar sobre los distintos puntos de la gráfica o de la tabla inferior navegamos a la pantalla de detalle de la traza seleccionada.
Se selecciona como servicio el servicio inicial (demoservice). En este selector aparecen todos los servicios o componentes que están enviando trazas al colector Otel.
...
Se pulsa el botón Find Traces para cargar las trazas en la gráfica según la búsqueda indicada en el formulario.
...
Como es un ejemplo y sólo se ha lanzado una vez aparece un solo punto en la gráfica que es la traza de la llamada al servicio también puede apreciarse en la tabla información referente a la traza y los spans generados en cada servicio o componente definido y que intervienen como son el api-manager y el semantic-broker
...
El siguiente paso para ver las trazas en detalle será pulsar sobre el punto en la gráfica, por ejemplo que abrirá la pantalla de detalle
...
Al pulsar en alguno de los span muestra información en detalle
Por ejemplo, este sería el span inicial
...
Puede distinguirse claramente cuando las trazas pasan de un servicio o componente a otro por ejemplo aquí está pasando del microservicio al Api Manager
...
Incluso se muestra el path del API Manager al que se invoca desde el microservicio
http://localhost:19100/api-manager/server/api/v1/customer/
...
También quedan registradas las consultas que se realizan sobre la bbdd relacional. El muestreo de trazas es configurable.
...
Incluso llegando a los span de semantic inf broker se puede apreciar la consulta sobre la bbdd no relacional en este caso sobre una bbdd mongo
...
Puede verse el tiempo que ha tardado en realizarse la consulta
...
Es sencillo diferenciar las trazas en las que se ha producido algún error, por ejemplo si invocamos al otro método del micro servicio e intentamos insertar se observa en la gráfica un punto pero en este caso es de color rojo
...
y si se clica en él para ver el detalle muestra en los span los tags con errores
...
Como se indicaba al principio poder trazar todo el proceso nos va a permitir resolver en entornos distribuidos problemas, consiguiendo encontrar la raíz de estos, como cuellos de botella, anomalías, etc.
...