Debug

Este reporte describe el propósito del debug, que es identificar y diagnosticar problemas en el código. También permite monitorear tanto los eventos y errores registrados en los logs como el estado general de la salud de la aplicación, ayudando a detectar problemas de rendimiento, errores críticos y posibles caídas en la disponibilidad de los servicios.

El debug, o depuración, es el proceso de identificar, analizar y corregir errores (también conocidos como bugs) en el código de un software o en el funcionamiento de un sistema. La depuración es una parte esencial del ciclo de desarrollo de software, ya que ayuda a garantizar que el programa funcione de manera correcta y eficiente.

Todos los gráficos que aparecen en el reporte incluyen una leyenda interactiva que permite una exploración más dinámica de los datos. Cada elemento de la leyenda representa un grupo de datos. Al hacer clic en uno de estos elementos, los valores asociados a esa variable desaparecen del gráfico, lo que permite enfocarse en el comportamiento de las demás categorías y mejora la interpretación.

Descripción general de los registros de debug

Esta tabla presenta un resumen de los registros de debug de las sesiones de cada uno de los canales por los que ha existido interacciones.

• Tenant ID: Contiene el identificador del tenant.
• Channel: Canal a través del cual ocurre la interacción con el flujo de autoatención.
• Service: Número del servicio a través del cual ocurre la interacción.
• Criteria: Dato que servirá para identificar al cliente
• Criteria Value: Valor del dato de identificación del servicio del cliente.
• Date: Fecha de inicio de la sesión.

Debug

Este esquema representa un flujo de debug entre diferentes componentes de la aplicación, específicamente en la comunicación entre el Channel Connector y el Lynn Core. El Channel Connector actúa como un intermediario que conecta canales externos (como redes sociales, correo electrónico, SMS, etc.). La comunicación no es directa; en su lugar, se utiliza un Service Bus de Azure. El Channel Connector coloca los mensajes en una cola, y el Core los recoge cuando está listo para procesarlos. Esto permite desacoplar el Channel Connector del Core y gestionar la comunicación de manera asíncrona.

El esquema está organizado en columnas, lo que permite observar cómo se intercambian mensajes o eventos entre los componentes en una secuencia ordenada. Cada columna representa un componente distinto de la aplicación:

Channel Connector:

• ChannelEdge
• ChannelAdapter
• CommunicationInterface

Lynn Core:

• Service Bus
• SessionManager
• ConversationManager
• CognitiveManager
• Edge

En la parte superior, a la izquierda, se incluye información de la sesión, como la fecha y el ID de la sesión. Esta información es útil para identificar el contexto y el entorno en el cual se realizó el proceso de debug.

Los eventos o acciones están representados por cajas en cada columna. La línea de tiempo de vertical permite seguir el orden en que ocurren los eventos en el sistema.

Las flechas conectan los eventos entre diferentes componentes, lo que muestra cómo se comunican entre sí. Estos eventos reflejan operaciones comunes, como validaciones de estado, creación y cierre de sesiones, inicio y fin de interacciones, etc.

Fases Comunes en el Flujo

Inicio con Verificación de Estado: El flujo suele comenzar con una verificación del estado del sistema, representado aquí por un evento de Health o chequeo de salud. Esto asegura que el sistema esté en condiciones de operar antes de continuar con los siguientes pasos.

Intercambio de Mensajes entre Componentes: A medida que el flujo avanza, diferentes módulos del sistema se comunican entre sí mediante eventos. Esto podría incluir la gestión de sesiones, manejo de solicitudes, creación y finalización de interacciones, etc. Esta fase puede variar en complejidad, dependiendo del propósito del flujo.

Creación y Manejo de Sesiones: En muchos sistemas, la creación y gestión de sesiones es fundamental para mantener el contexto y el estado de las interacciones. Esto se refleja aquí en eventos que marcan el inicio, gestión y cierre de sesiones, asegurando que el sistema mantenga la consistencia de la información y libere recursos cuando sea necesario.

Servidor de origen de los registros

Este gráfico de pastel ilustra la distribución de las conexiones según los diferentes servidores de aplicación. Cada segmento del gráfico representa un servidor específico y su proporción con respecto al total de conexiones.

Cada porción del pastel corresponde a un servidor de aplicación. El tamaño de cada segmento refleja la cantidad de conexiones que se originaron desde ese servidor en relación con el total de conexiones.

Actividad de los registros

Este gráfico de curvas ilustra la actividad de los registros a lo largo del tiempo. La curva representa la cantidad de registros en función de diferentes intervalos temporales, lo que permite observar patrones y tendencias en la actividad de los registros.

El eje X representa el tiempo, que está dividido en intervalos de acuerdo al rango de tiempo seleccionado para mostrar. El eje Y representa la cantidad de registros, mostrando cuántos registros se han generado o registrado en cada intervalo de tiempo.

La línea o curvas en el gráfico conectan los puntos de datos y muestran la evolución de la actividad de los registros.