¿Qué es MELT?
M-etrics: es un valor agregado y calculado al observar muchos eventos diferentes durante un periodo de tiempo.
E-vents: es una acción distintiva que ocurre en un momento especifico en el tiempo.
L-ogs: Es división granular de un evento, es útil cuando quieres saber a detalle que es lo que paso dentro de un evento.
T-races: nos permiten rastrear ciertos eventos, para poder visualizar como fueron hechos paso a paso.
Bienvenida al curso
¿Qué aprenderás sobre observabilidad con New Relic?
¿Cómo funciona la web moderna?
¿Cómo pasamos de páginas web a aplicaciones web?
Contenedores y alojamiento en la nube
¿Qué es cloud native?
Quiz: ¿Cómo funciona la web moderna?
Observabilidad y monitoreo
Tipos de herramientas y limitaciones del monitoreo
Monitoreo de un sistema
¿Qué es observabilidad?
Los 3 pilares de la observabilidad
Quiz: Observabilidad y monitoreo
Telemetría y tipos de datos
MELT: una mirada más cercana a Traces
MELT: una mirada más cercana a Metrics
¿Qué es MELT? Una mirada cercana a Events
MELT: una mirada más cercana a Logs
Quiz: Telemetría y tipos de datos
Reto: Monoliths y Microservices
Reto: Monoliths y Microservices
Quiz: Reto: Monoliths y Microservices
Cierre y despedida
Resumen de todo lo que aprendiste
Tu opinión es importante, danos tu feedback
No tienes acceso a esta clase
¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera
Si ya tienes una cuenta,
MELT: una mirada más cercana a Traces
9/15Recursos
Los traces o rastros, son huellas de llamados específicos de registros temporales en el sistema.
Generalizando el concepto, los rastros son muestras causales de eventos, de origen transaccional, entre diferentes componentes de un sistema.
Dichos rastros, nos permiten abordar con exactitud, aquellos contextos donde un sistema transacciona operaciones temporales, abordando casos de uso como de comportamiento en conjunto.
¿Cómo funcionan los traces?
Supongamos que tenemos el siguiente registro de operación:
Sea un proceso de compra de un artículo con tarjeta de crédito, duró un tiempo estimado de 23 segundos en completar la transacción. Pero ... ¿Qué encapsula los 23 segundos? ¿Es demasiado tiempo? ¿Fue nuestro servicio, o un proveedor de terceros?
Preguntas como las anteriores, son lo que los rastros deben abordar.
Qué es span
Un span o cadena, permite encapsular un conjunto de traces o rastros por transacción, logrando que para cada servicio transaccional, sea identificada una correlación o contexto de seguimiento.
De los registros, podemos obtener que el servicio externo a nuestro sistema tarda 18 segundos de 23 totales. Del servicio externo, la respuesta de la compañía de crédito tardo 15 segundos, 3 cuando se lanzó la petición y 12 en procesarla para dar respuesta. Se está tomando 12 de los 23 segundos, ¡eso es más de la mitad del tiempo para todo este seguimiento!
Los contexto de seguimiento, son necesarios cuando se preocupa por las relaciones entre servicios y/o entidades. Si solo tuviéramos eventos sin procesar para cada servicio de forma aislada, no se tendría forma de reconstruir una sola cadena entre servicios para una transacción en particular.
Para garantizar que nuestros rastros sean evidentes, deberán pasar por un contexto de seguimiento para identificar de manera única, una sola transacción a lo largo de una cadena de registros.
Contribución creada por: Emmanuel Rodríguez
Aportes 13
Preguntas 1
Ordenar por:
Los traces nos ayudan a identificar cada paso en una transacción y facilita a encontrar las fallas de forma más granular.
Traces:
Rastros (distribute traces o rastros distribuidos como migajas que vamos dejando en nuestro sistema para poder rastrear un suceso y verlo desglosado dentro del evento)
Seguir pasos hacia atrás para ver donde se produjo un suceso que determinó un resultado particular. Sólo se guardan porque no se sabe cuando van a ser necesarios.
El evento nos da un dato de los que ocurrió durante el proceso de compra de un producto, pero no sabemos dónde está el problema, por ejemplo, de una demora en procesar el pago. Por ello se introduce los Traces con un ID como atributo.
Cada servicio pasa ese ID y esos metadatos, al guardarse como atributo, nos va a ayudar a enlazar las partes de los eventos sin importar que esté en distintos elementos de nuestro sistema. Es una forma de descomponer el evento y ver en qué sección del proceso de la venta se produjo la demora.
Los traces o rastros nos ayudan a generar Observabilidad.
Nos permiten rastrear ciertos eventos, para poder visualizar como fueron hechos paso a paso. 😁
Con los Traces (rastros) podremos conocer la actividad que se ha tenido al realizarse una función específica.
Cuando nos enteramos que está surgiendo un problema al ejecutarse esa función especifica, hay que revisar su actividad (traces).
Creo que esta clase va es al final de esta sección, habla sobre la última letra del sistema MELT
MELT: una mirada más cercana a Traces
Los traces son cadenas de eventos entre componentes, son parecidos a los logs puesto que son discretos e irregulares no se sabe cuando van a ocurrir, por lo que siempre se guardan.
¿Cómo se diferencian de los logs? sencillo tienen un identificador del proceso que se ejecuta. Supongamos que el componente A consulta información al componente B frecuentemente, en los logs podemos ver que información a consultado el componente A en múltiples ocasiones y de igual manera que información a respondido el componente B en múltiples ocasiones, sin embargo, cuando no podemos visualizar de manera secuencial la información consultada y retornada, no podemos tener esa relación entre dicha información. Con los traces, se genera un id_trace cuando el componente A consulta, y con ese mismo id_trace se puede ver la información que el componente B retorno para esta consulta.
Hay una lugar de almacenamiento donde se persiste los eventos de los componentes distribuidos y estan correlacionados por un Id para poder dar seguimiento.
ELK o ELK Stack
\*\*MELT\*\* es un acrónimo que se refiere a \*\*Metrics, Events, Logs y Traces\*\*, los cuatro pilares fundamentales de la observabilidad en sistemas distribuidos y microservicios. Cada uno de estos componentes proporciona una perspectiva única para entender el comportamiento y el rendimiento de las aplicaciones en producción. Cuando hablamos de "una mirada más cercana a Traces", nos centramos específicamente en la capacidad de rastrear solicitudes y transacciones a lo largo de los diferentes servicios que conforman un sistema.
\### ¿Qué son los \*\*Traces\*\*?
Los \*\*traces\*\* (o \*\*rastros\*\*) permiten observar el flujo de una solicitud mientras viaja por los distintos componentes de un sistema distribuido. Cada interacción o paso de una solicitud se denomina \*\*span\*\*. Un conjunto de spans interconectados que representan el viaje completo de la solicitud es lo que constituye un \*\*trace\*\*. Este enfoque ayuda a visualizar cómo una solicitud pasa por los distintos servicios, y es clave para identificar cuellos de botella, problemas de latencia y dependencias entre servicios.
\### Características importantes de los Traces:
1\. \*\*Propagación a través de servicios\*\*: Un trace sigue a una solicitud desde el inicio hasta el final, cruzando varios servicios, bases de datos y sistemas externos.
2\. \*\*Estructura jerárquica\*\*: Un trace puede estar compuesto por múltiples spans que muestran las distintas capas y dependencias del sistema.
3\. \*\*Identificación de problemas de latencia\*\*: Los traces permiten identificar en qué parte del sistema se generan retrasos significativos.
4\. \*\*Visualización del flujo\*\*: Los traces proporcionan una visión clara del flujo de datos, útil para analizar las interacciones entre microservicios.
\### ¿Por qué son importantes los Traces?
\- \*\*Depuración eficiente\*\*: En sistemas distribuidos, es difícil rastrear problemas sin una visión clara del camino de las solicitudes. Los traces permiten a los desarrolladores y equipos de operaciones identificar la fuente de los problemas.
\- \*\*Optimización de rendimiento\*\*: Los traces facilitan la detección de los cuellos de botella, lo que permite optimizar el rendimiento de la aplicación.
\- \*\*Monitoreo proactivo\*\*: Al ver patrones anómalos en los traces, los equipos pueden detectar problemas antes de que afecten a los usuarios.
\### Ejemplo de uso de Traces:
Imagina que un usuario hace una solicitud a una aplicación que involucra múltiples servicios: un front-end, una API gateway, un servicio de autenticación y una base de datos. Un trace documentará cómo esa solicitud viaja entre cada uno de estos servicios, cuánto tiempo pasa en cada uno y si ocurre algún error en el camino.
En resumen, en la observabilidad del ciclo MELT, los \*\*traces\*\* proporcionan visibilidad del flujo de datos y solicitudes a través de un sistema distribuido, ayudando a mejorar el monitoreo, el diagnóstico de errores y la optimización del rendimiento.
Los traces vienen siendo rastros que se dejan en el sistema y permite identificar que componentes están fallando o tardando en ejecutarse para poder tomar acciones si están en nuestras manos.
Traces --> buscar los logs que se hayan registrado, en los componentes de las aplicaciones
Los traces nos ayudan a identificar cada paso en una transacción y facilita a encontrar las fallas de forma más granular.
Sirven para analizar la información y entender el proceso que se llevo acabo.
¡Rock n’ Roll! 🤟
.
No solo es monitorear, es registrar los eventos realizados en nuestros sistemas ✨
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?