Ajustes X-Ray

[milo19980525]

Se requiere ajustar el llamado del canarie establecido para que pueda ser leído desde X-Ray, verificar las mascaras para los servicios y empezar a revisar la implementación de X-Ray en la base de datos.

Especificaciones técnicas

• El último desarrollo relacionado con la implementación de X-Ray se encuentra en release para ambas APIs.
• Las tareas del presente issue continuan con las tareas de #77.

Sub Tareas

• [x] Implementar un canarie de manera correcta, ajustando el servicio de ejecución de X-Ray para que pueda recibir la información de este.
• [x] Desarrollar máscaras de identificación de servicios, inicialmente para el API crud y mid de Cumplidos_DVE, con el proposito que no aparezcan más de una vez los nodos de cada uno de los servicios.
• [x] En el API Crud de Cumplidos_dve, implementar el seguimiento de errores que pueden ser causados por el estado de la base de datos.

Criterios de aceptación

• [x] Se validan los requerimientos del issue y se da solución a la captura del canarie.
• [x] Se implementa una prueba de concepto de cannaries.
• [x] Se desarrollan las máscaras para los servicios requeridos y se evidencian en el issue.
• [x] Se evidencia la fase inicial para identificar errores a nivel de base de datos (persistencia).
• [x] Se documenta el issue con el trabajo realizado.

Requerimientos

• [x] Acceso total a servicio X-Ray y su complemento en CloudWatch en AWS.

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

[a52290451]

Investigación Mapeo de Segmentos en BDs a través de APIs CRUD:

Tras realizar varias pruebas intentando rastrear la conexión y las peticiones que se realizan a la BD desde el APU CRUD, se concluye que no es posible mapear con segmentos o subsegmentos esta actividad, ya que no se realiza directamente en el API CRUD. Actualmente se está utilizando funciones de beego para conectar y consultar la BD, por lo que no es posible capturar ni mapear dicho consumo.

XRAY a través del SDK dispuesto para BEEGO, especifica que se requiere instrumentar las llamadas a la BD a través de:

func main() { db, err := xray.SQLContext("postgres", "postgres://user:password@host:port/db") row, err := db.QueryRowContext(ctx, "SELECT 1") // Use as normal }

Es la única forma de lograr capturar las llamadas a la BD.

Soporte: https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-go-sqlclients.html

[milo19980525]

Respecto al uso de máscaras para verificar servicios que no estén en funcionamiento emplear un cannarie que revise periodicamente el estado de una api

[milo19980525]

@a52290451 Por favor actualizar la issue, desde hace una semana no se hace una semana no se hacen comentarios.

[a52290451]

Actualización de estado X-Ray

La implementación de AWS X-Ray a través de su SDK para GO, se completó en su mayoría, empleando el cliente de XRAY como envoltura para las peticiones http entrantes y salientes de cada API. Esta envoltura crea segmentos de forma automática para cada petición que se haga a cada API y los enlaza al segmento principal. El problema con utilizar el cliente de XRAY como envoltura de las peticiones es que, en caso de que la API a la que se le están haciendo peticiones se encuentre igualmente instrumentada con el SDK de AWS X-Ray, cuando la API no responda, crea un segmento aparte de tipo remoto, que no es posible igualar al segmento creado por la propia API, en este caso, se representa como un nodo aparte en el mapa de servicios, con lo cual se tendría un duplicado de nodos que representan la misma API.

Envoltura:

Tras una ardua investigación, se llegó a la conclusión, que no hay forma de resolver este problema empleando el cliente de AWS X-Ray como envoltura, ya que crea los segmentos de forma automática y no hay forma de acceder a ellos para alterar su flujo y la información que registran.

En consecuencia, se decide optar por la creación de segmentos de forma tradicional, creando el segmento principal asociado a la API a la cual llega la petición original, segmentos hijos que se inicializan antes de que se realicen peticiones a otras APIs al interior de la API principal, y segmentos inferidos que se crean cuando las APIs secundarias se encuentran instrumentadas. Esto se representa en el mapa de servicios como un nodo por cada API, aún cuando alguna de las APIs consultadas falle.

Estado actual

Se encuentra en curso la implementación de X-Ray con el nuevo enfoque, sin embargo, se tiene un problema al momento de enlazar los segmentos secundarios, creados a puertas de realizar las peticiones a otras APIs desde la API principal, al segmento principal. Actualmente, estos segmentos no se envían en la misma traza que el segmento principal, lo cual no permite que se muestren los nodos asociados a APIs que no se encuentran instrumentadas.

[a52290451]

Implementación de Mascaras para APIs

La implementación de mascaras para APIs se realizó, reemplazando el Host del API (nombre por defecto del API en el mapa de servicios) por la variable de entorno "appname" configurada en cada API. De esta forma, se asigna una mascara por defecto a cada API que se encuentre instrumentada con el SDK de AWS X-Ray. En caso de que no se encuentre instrumentada, se asigna por defecto el Host del API como nombre del nodo en el Mapa de Servicios.

[milo19980525]

@a52290451 Perfecto, clara y concisa la explicación.

Por favor actualizar el estado del cannarie y las reuniones llevadas a cabo con el servicio de AWS.

[a52290451]

Actualización de Estado X-Ray:

Se logra enlazar de forma satisfactoria los segmentos secundarios al segmento principal, y actualizar su estado de acuerdo con la respuesta de la solicitud. De esta forma, se completa la implementación del SDK de AWS X-Ray en APIs CRUD y MID:

Ejemplo de traza sin errores:

Ejemplo de traza con error 500 en una de las solicitudes internas:

Trazas:

Mapa de servicios:

Sugerencias de Optimización:

1. Eliminar segmentos duplicados en subconsultas, cuando la subconsulta responde correctamente a la petición.
2. Implementación de AWS X-Ray para captura de conexión a BDs en APIs CRUD.

Desarrollo de mascaras

Tras realizar un gran análisis acerca de su implementación, se llegó a la conclusión de que tomaría gran cantidad de recursos lograr asignar mascaras a los segmentos creados en cada traza que se envía a AWS, sin que se duplicaran nodos. Cuando una solicitud interna de una API instrumentada no responde, no es posible asignar una mascara al segmento designado para tal solicitud ya que no se logra conectar con la otra API para identificarla. Esto genera que se produzcan segmentos sin mascara y con mascara para una misma API, lo cual representa duplicados en el mapa de servicios de X-Ray.

Una POSIBLE SOLUCIÓN es utilizar un diccionario de datos existente, o acceder a las variables de entorno de una API por su HOST y PUERTO, para extraer el valor de la mascara y asignarlo de forma predeterminada a cualquier segmento que se cree para esa API.

Implementación de Canarys

La implementación de Canarys presenta un problema asociado con la configuración del mismo para ejecutarse al interior de una VPC y poder acceder a las direcciones que se encuentran alojadas en la misma sin necesidad de autenticarse. Se han implementado varias soluciones sugeridas por el equipo de soporte de AWS con respecto a la configuración del Canary, sin embargo, no han resuelto el problema.

Actualmente se sigue a la espera del equipo de soporte de AWS para que brinden un solución definitiva al problema señalado.