Complementos de X-Ray

[milo19980525]

Se requiere revisar algunas características finales para completar el MVP de X-Ray.

Especificaciones técnicas

• El último desarrollo de X-Ray, se encuentra en rama feature/x-ray.
• El desarrollo final de X-Ray se encuentra documentado en: #80.

Sub Tareas

• [x] Subida de proyectos "cumplidos_dve_mid" y "cumplidos_dve_crud" a ambiente de pruebas y testear su funcionamiento.
• [x] Ajuste de métricas de obtención de trazas en X-Ray, lo anterior pensando en la captura de trazas de todas las APIs de la oficina.
• [x] Especificar en el issue el estado de los cannaries y su posible uso.
• [x] Realizar una prueba de concepto de X-Ray con un API de python.

Criterios de aceptación

• [x] Se prueban las funcionalidades de X-ray en ambiente de pruebas.
• [x] Se plantea una métrica correcta para capturar los errores de las APIs, sin que esto represente un alto costo computacional de AWS.
• [x] Se comenta en el issue el estado actual de los cannaries.
• [x] Se evidencia la creación de un API en ambiente local con Python y se implementa X-ray en ella.

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] Criterios de aceptación cumplidos.
• [x] Documentación de issue realizada.
• [x] Aprobada por SM/Líder técnico.

[a52290451]

Actualización de estado de actividades

Prueba de funcionamiento de X-Ray en ambiente de pruebas Para realizar pruebas sobre X-Ray se requiere tener en funcionamiento un Demonio en AWS que capture las trazas enviadas por cada API y las redirecciones a AWS X-Ray. Actualmente, el demonio configurado para tal fin se encuentra con fallas de configuración y no captura todas las trazas que se envían. En conversaciones con el área de infraestructura, se encuentran aún solucionando este inconveniente, por lo que no es posible cargar en ambiente de pruebas la implementación del SDK realizada para "cumplidos_dve_mid" y "cumplidos_dve_crud". Además, se requiere solucionar antes el tema de muestras, para que se ignoren todas las solicitudes realizadas al HealtCheck de cada API.

[a52290451]

Actualización de estado de actividades

Ajuste de métrica para obtención de trazas de X-Ray

El principal problema que se tiene con la captura de trazas por API es que se están capturando todas las solicitudes que se realizan a cada API, incluyendo aquellas que se realizan cada minuto de forma automática para comprobar el estado de la API (solicitudes HealthCheck). Esto causa que se generen sobre costos gracias a la enorme cantidad de trazas que se generan por API.

En este sentido, se presenta la siguiente solución:

En el paquete xray de utils_oas se crea la variable local capturar de tipo booleana. A través de una sentencia de control, se evalúa si la solicitud se encuentra asociada al healthcheck ( / ) o no, y se asigna un valor booleano a dicha variable:

Luego, posterior a la creación del segmento principal de la solicitud, se evalúa si la variable capturar es falsa para deshabilitar el envío del segmento principal:

Con esta solución, se logra enviar a AWS X-Ray solo la captura de solicitudes asociadas a controladores, lo que se traduce en una reducción notable de trazas generadas por API.

[a52290451]

Actualización de estado de actividades

Estado de implementación de Canarios y su posible uso

---

¿Qué son y para que sirven?

Los Canarios son pruebas automatizadas que se ejecutan de forma continua para verificar el rendimiento y la disponibilidad de un servicio o aplicación. Son útiles para detectar problemas antes de que afecten a los usuarios.

Los canarios pueden utilizarse para:

Detectar cambios en el rendimiento o la disponibilidad. Los canarios pueden utilizarse para verificar que un servicio o aplicación sigue funcionando correctamente después de un cambio, como una actualización de software o una modificación de la configuración.

Identificar cuellos de botella. Los canarios pueden utilizarse para identificar las partes de un servicio o aplicación que están causando problemas de rendimiento.

Probar nuevas funciones o cambios. Los canarios pueden utilizarse para probar nuevas funciones o cambios en un servicio o aplicación antes de implementarlos en producción.

También pueden utilizarse para realizar una variedad de tareas, incluyendo:

• Pruebas de carga
• Pruebas de estrés
• Pruebas de rendimiento
• Pruebas de disponibilidad

---

Estado de implementación

La implementación y configuración del servicio de Canarios asociado a CloudWatch en AWS, se encuentra completo, obteniendo como resultado un canario que se ejecuta de forma recurrente cada cierto tiempo, según la configuración que se le de, realizando una serie de peticiones a un conjunto de APIs.

Tras la ejecución del canario, se almacenan los resultados con capturas de pantalla incluidas en un Bucket S3 creado exclusivamente para el canario.

Esto constituye una implementación básica o prueba de concepto de un canario.

Nota: debido a que en fase de pruebas, el canario se dejo activo, ejecutándose cada minuto y generando sobre costos para la organización, actualmente se encuentra desactivado.

[a52290451]

Actualización de estado de actividades

Realizar una prueba de concepto de X-Ray con un API de python

Para la prueba de concepto, se crea un Web Service en Flask, con la siguiente estructura de archivos:

En donde:

1. app.py contiene el código fuente del WS con las rutas y controladores del mismo.
2. products.py simula la BD que consume el WS.
3. xray.py es la implementación del SDK de AWS X-Ray en Python.

La implementación del SDK de X-Ray contiene los siguientes métodos:

Se realiza la configuración de XRAY, y se definen métodos para inicializar el segmento principal del WS y finalizarlo, actualizando sus metadatos y su estado final.

En código fuente del WS se realizan las inclusiones de código para soportar X-Ray:

Se inicia ejecutando xray.iniciar_xray() desde el main del WS. Esto inicializa X-Ray en el WS y luego despliega el WS.

Se configuran los métodos before_request y after_request que se ejecutan antes y despues de la petición que se le hace al WS. En before_request simplemente se inicializa el segmento principal. En after_request se actualizan los metadatos del segmento con el resultado de la petición, se finaliza el segmento y se devuelve la respuesta final del WS.

Adicionalmente, se crea un servicio de prueba en el WS de tipo GET que apunta a cumplidos_dve_mid con la URL quemada, con el objetivo de lograr un enlace entre APIs. En este caso, el resultado fue exitoso, como se muestra a continuación:

127.0.0.1:4000 representa el WS en FLASK que es de donde parte la petición original.

De esta forma se completa la prueba de concepto para la implementación del SDK de AWS X-Ray en Python.

NOTA: esto es solo una prueba inicial, aún hace falta implementar mas funcionalidades para WS en FLASK o DJANGO asociadas a control de errores y optimización de código.

[milo19980525]

@a52290451 por favor comentar con una captura de pantalla el funcionamiento de X-Ray en pruebas

[a52290451]

Funcionamiento de X-Ray en pruebas

Después de realizar varias pruebas y varios ajustes al Demonio de AWS X-Ray en ambiente de pruebas, se logró completar la captura de trazas asociadas a las APIs cumplidos_dve_mid y cumplidos_dve_crud que son las que se encuentran instrumentadas con el SDK de AWS X-Ray.

Además, se aplica correctamente el filtro de muestreo Filtro_V1, con lo que se garantiza el envío del 100% de segmentos creados al interior de las APIs por cada petición realizada.