Refinamiento sobre las funciones de X-Ray implementadas

[milo19980525]

Se requiere refinar algunas características.

Especificaciones técnicas

• El último desarrollo de X-Ray, se encuentra en el ambiente de pruebas.
• El desarrollo final de X-Ray se encuentra documentado en: #78.

Sub Tareas

• [x] Optimización de duplicado de segmentos al momento de realizar peticiones (segmento de ida (petición) y vuelta (respuesta)).
• [x] Documentación en código de las funcionalidades desarrolladas y su implementación.
• [x] Revisión de notificaciones personalizadas a nivel de API para que se identifique de manera más rápida el error.

Criterios de aceptación

• [x] Se evidencia el código documentado.
• [x] Solo se crea un segmento cuando se recibe una petición de una API.
• [x] Las notificaciones de alarma se automatizan a nivel informativo del API que se encuentra fallando.
• [x] El issue se encuentra documentado con la solución de las tareas y su respectiva evidencia.

Requerimientos

• [x] Funcionalidad de X-ray funcional con el API de cumplidos_dve_mid y cumplidos_crud.

Dependencias

• No presenta.

Definition of Ready - DoR

• [x] Está refinada y estimada en puntos de historia por el equipo.
• [x] Incluye la descripción y criterios de aceptación, con el detalle funcional y especificaciones técnicas, de forma entendible por cualquier miembro del equipo.
• [x] No tiene bloqueos que impidan su ejecución.
• [x] Las dependencias entán identificadas y resueltas.
• [x] Puede ser probada dentro del Sprint.

Definition of Done - DoD - Desarrollo

• [x] Desarrollo en local.
• [x] Push en Feature.
• [x] Pruebas locales (funcionales).
• [x] PR a Feature.
• [x] Criterios de aceptación cumplidos.
• [x] Documentación de issue realizada.
• [ ] Aprobada por SM/Líder técnico.

[a52290451]

Documentación de Actividades

---

Optimización de Código (Eliminación de segmentos duplicados en APIs instrumentadas)

La solución consistió en transmitir, a través del Header de la petición, la confirmación de la creación de un segmento secundario en una API secundaria. Cuando se detecta esta confirmación desde la API principal, se elimina el segmento secundario creado desde la API principal. Con esto no se generan segmentos duplicados para una misma API.

Todo se implementa y se controla desde el paquete xray en utils_oas.

En esta porción de código de la función BeginSegmentWithContextTP, se detecta si se trata de un segmento secundario creado en una API secundaria y, con esto, se transmite la confirmación del segmento:

En la porción siguiente, asociada a la función UpdateSegmentSec que se encarga de actualizar los segmentos secundarios creados en la API principal, se obtiene la respuesta transmitida a través del Header de la petición, en caso de encontrar un valor marcado con "Resp-X-Amzn-Trace-Id", se elimina el segmento secundario creado desde la API principal.

Prueba de funcionamiento

• Traza con estado 200 asociada a la petición http://localhost:9001/v1/aprobacion_documentos/solicitudes_supervisor/456345 de cumplidos_dve_mid, la cual genera 3 segmentos sin duplicados.

• Traza con estado 500 asociada a la petición http://localhost:9001/v1/aprobacion_documentos/solicitudes_supervisor/456345 de cumplidos_dve_mid, la cual genera 3 segmentos sin duplicados.

• Adicionalmente, se evidencia que de forma constante se transmiten 3 segmentos a través del demonio para la petición:

Nota: anteriormente, cuando esta petición no contaba con el control de duplicados, generaba 4 segmentos con un estado 200. Esto se producía gracias a que se creaba un segmento secundario en la API principal y otro del mismo tipo en la API secundaria.

---

Documentación de Código

Se realiza la documentación en código del paquete xray en utils_oas.

Tanto el Init del paquete, como todas sus funciones se documentan, especificando su funcionamiento, los parámetros de entrada y las devoluciones.

A continuación se muestra una porción del código documentado:

[a52290451]

Documentación de Actividades

Objetivo: Revisión de notificaciones personalizadas a nivel de API para que se identifique de manera más rápida el error.

Después de llevar a cabo una investigación exhaustiva sobre la posibilidad de incluir detalles específicos sobre las trazas que desencadenaban la alarma, hemos llegado a la conclusión de que alcanzar este nivel de detalle no es viable, y ello se debe a la siguiente razón:

Las alarmas están vinculadas a métricas que, a su vez, se relacionan con grupos de trazas de X-Ray predefinidos. Estos grupos de trazas se configuran mediante la aplicación de un filtro diseñado para detectar trazas que presenten errores. En este contexto, no resulta factible adjuntar la traza exacta que causó la activación de la alarma. Para esto sería necesario definir un grupo de trazas de X-Ray para cada API.

No obstante, a través de la alarma es posible identificar el grupo de X-Ray al que pertenecen las trazas que desencadenaron la alarma. Esta información resulta suficiente para reconocer los errores y tomar medidas correctivas de manera oportuna.

[a52290451]

Actualización de implementación de X-Ray en cumplidos_dve_mid: https://github.com/udistrital/cumplidos_dve_mid/tree/feature/X-Ray_v2

Actualización de implementación de X-Ray en utils_oas: https://github.com/udistrital/utils_oas/pull/31

Actualización de implementación de X-Ray en cumplidos_dve_crud: https://github.com/udistrital/cumplidos_dve_crud/tree/feature/xray