Cómo rastreamos nuestra salida usando Event-Tracing

El seguimiento de eventos es uno de esos temas de los que somos conscientes de su eficacia, pero siempre lo ponemos en baja prioridad. Agregar seguimiento a sus flujos y arquitectura (principalmente efectivo en el ecosistema de microservicios) es extremadamente crucial para encontrar sus manos y piernas cuando necesite depurar o administrar accidentes de crisis.

Escenario: Tenemos múltiples flujos en nuestro sistema de microservicios. Cada flujo tiene un punto de inicio y múltiples puntos finales que dependen del flujo.

Desafortunadamente, uno de nuestros servicios falla y el flujo no terminó como se esperaba -> Boom -> Alertas surgiendo, se están ejecutando excepciones en todos los registros, ¿dónde comenzamos? ¿Qué causó los problemas o qué solicitud desencadenó este problema? Entonces, ¿qué hacemos primero?

Probablemente esté utilizando el marco del agregador de registros (pila ELK, etc.), clasificamos los registros por servicios y tiempo y ahora comenzamos a descubrir qué sucedió. En este punto todavía luchamos por ver algo de claridad. Cuando tiene múltiples flujos y caminos complejos, no podemos decir realmente cuál fue la cadena de ocasiones que condujo a este problema. Sí, podemos comenzar a usar marcas de tiempo y sí, podemos comenzar a dibujar escenarios de arquitectura (recuerdo esas discusiones: “Oye, ¿recuerdas que teníamos el flujo A activado cuando el flujo B finaliza, pero alternativamente podría activar el flujo C en caso de que se cumplan esas condiciones?”) averiguando para encontrar nuestro camino. Sin prestar atención empiezas a actuar como “Hansel y Gretel” tratando de encontrar sus migajas de pan en el bosque.

El rastreo podría hacer su vida más fácil. Especialmente en tiempos de crisis cuando los momentos están bajo presión. Así que… “Mantén la calma y mira tu rastro”

Si pudiera dibujar el flujo de su ruta (al igual que lo hace el GPS del avión), podría rastrear y abordar los problemas fácilmente

Agregar un sistema de seguimiento a sus componentes no es complicado, pero debe ser consistente y un trabajo metodológico. Cuanto antes aplique su estándar, más fácil será incorporarlo.

El rastreo se vuelve cada vez más popular a medida que los sistemas complejos encuentran su eficiencia. El problema actual es que tenemos diferentes proveedores de marcos de seguimiento y no tenemos un estándar real. Sin embargo, hoy en día, el W3C tiene un candidato en curso para los estándares de seguimiento:

https://www.w3.org/TR/trace-context/

Lo mantendré simple para ti.

El rastreo combina 3 valores clave principales:

ID de correlación:
parámetro que Indica el flujo de seguimiento completo (se pasará de un servicio a otro) – creado una vez que comienza el flujo
Identificación de los padres:
parámetro que indica de dónde ha llegado la solicitud (¿quién me llamó?) – pasado por el proceso anterior
Id. de evento:
parámetro que se usa dentro del alcance del servicio/proceso – creado como sub-solicitud
Esos parámetros deben usarse y/o crearse en cada uno de sus “puntos de entrada” dentro de su servicio/proceso.

Beneficio de reversión:

El seguimiento permite que su arquitectura revierta la operación entre servicios.

Mencioné el parámetro correlación-Id. Dado que la identificación de correlación se pasa entre un proceso y otro, puede usarla como una identificación de agregador única para “transacción”. Si necesita revertir el estado/transacción en todos sus servicios, solo mencione el ID de correlación y sus servicios deberían ser lo suficientemente inteligentes como para revertir la operación (en la próxima publicación, demostraré las posibles formas de hacerlo en detalle)

Beneficio de reintento:

El seguimiento le dará la capacidad de volver a intentar eventos específicos. Supongamos que tiene una transacción en todos sus servicios. Pero, mala suerte, uno de los servicios ha terminado (por algún motivo). Ahora su sistema está en un estado que llamo “Estado medio horneado” donde parte de sus servicios aplicaron la transacción y otros no. Dado que el seguimiento obtuvo eventId (mencionado anteriormente), puede indicarle a un servicio específico que vuelva a intentar (después de recuperar) la transacción fallida y el resultado sea una alineación.

Otros beneficios de rastreo:

Distinción entre diferentes rutas en su flujo (sin usar marcas de tiempo o pensamiento de arquitectura)
Seguimiento de la fuente de datos: si está utilizando una identificación única para el registro de transacciones de la fuente de datos, puede usar la identificación del evento. Esto extenderá su ruta general a los registros de su fuente de datos (más tarde, la correlación Id expondrá todos los Id. de eventos relacionados que eventualmente expondrán todos los registros afectados en diferentes fuentes de datos
Supervisar los componentes como un todo. Dado que tiene correlaciónId, que es el mismo valor utilizado en todos los componentes participantes, puede monitorear y abordar acciones no deseadas
Orientado al cliente. Siempre puede devolverle a su cliente el ID de correlación y usarlo más tarde si surge algún problema comercial o no comercial. Será más fácil rastrear el flujo mirando hacia atrás en busca del ID de correlación asignado.
Como puedes notar los beneficios son tremendos.

Mi consejo: aplique el rastreo lo antes posible. Puede ser un verdadero dolor aplicarlo una vez que su sistema se vuelve complejo y más amplio.

En mi próxima publicación, revisaré un par de proveedores de seguimiento y explicaré cómo aplicamos el seguimiento en nuestros componentes y qué marcos usamos para visualizarlos.

tomado de mi blog en: http://idanfridman.com/2019/08/15/this-is-how-event-tracing-saved-us/

Salud,

Si

Similar Posts

Leave a Reply

Your email address will not be published.