Comprensión y solución de problemas de registros HAR para WxCalling

Introducción

Este documento describe la comprensión y solución de problemas de los registros HAR.

Descripción general de características

Un registro HAR (abreviatura de HTTP Archive Logging) es un registro de toda la actividad de red entre su navegador y un sitio web durante una sesión específica.

Cuando visita un sitio web, su navegador envía solicitudes al servidor y recibe respuestas. El archivo HAR captura todas esas solicitudes, respuestas y la información de sincronización.

Son esenciales para diagnosticar problemas de rendimiento web, solucionar errores de red y analizar transacciones de API.

Los registros HAR ayudan a identificar recursos de carga lenta, solicitudes con errores y seguimiento de las interacciones de los usuarios con las aplicaciones web.

Limitaciones

• Los archivos HAR pueden ser grandes y difíciles de analizar manualmente.
• Se pueden registrar datos confidenciales; garantizar el saneamiento de los datos antes de compartirlos.
• Algunas políticas de seguridad pueden bloquear la captura HAR completa.

Precaución: El archivo HAR incluye todo el contenido de las solicitudes y respuestas en texto sin formato (incluidas contraseñas, ID de sesión, cookies, etc.). Por lo tanto, no debe compartir un archivo HAR tomado en una sesión con un servicio disponible públicamente. Si se ha abierto la ficha Red al introducir una contraseña, el texto del archivo HAR será sin cifrar. Desea quitar estas credenciales antes de compartir el archivo HAR. Abra el archivo HAR guardado en un editor de texto, busque la contraseña y sustitúyala por un texto aleatorio como "". No modifique el formato JSON del archivo mientras realiza este cambio, ya que no se analizará correctamente para revisarlo.

Herramienta HAR Sanitizer

Historial

En 2023, Okta sufrió una brecha en la seguridad por el robo de archivos HAR de sus sistemas de gestión de casos de asistencia. Los atacantes usaron el token de acceso y las cookies de esos archivos para acceder a sus cuentas de cliente. En respuesta, Okta implementó una herramienta de saneamiento.

Estado actual

Actualmente hay una automatización en curso que trata de eliminar los materiales sensibles de los rastros, pero deja el resto intacto para preservar la capacidad de resolver problemas y analizar su problema.

Al cargar un archivo HAR, la herramienta automáticamente:

1. Detecta que se ha cargado un archivo HAR
2. Limpia el archivo HAR mediante https://har-sanitize.cisco.com
3. Carga el archivo desinfectado en el caso
4. Cifra el archivo HAR original mediante GPG
5. Carga el archivo HAR cifrado en el caso
6. Elimina el archivo HAR original del caso.
7. Añade una nota al caso que explica lo que se ha hecho y un enlace a esta herramienta

Nota: Si no puede resolver el problema con la versión desinfectada del archivo HAR, puede presentar una excepción como se explica en las siguientes secciones y obtener una copia del archivo HAR original.

Cómo extraer el registro HAR

Generar un archivo HAR en el explorador

Consulte: Genere un archivo HAR en el explorador.

Extraer del documento:

• Cromado:
  Abra Developer Tools (F12) > Network Tab > Preserve Log > Start Recording > Reproduction Issue > Export HAR File.
• Firefox:
  Abra Developer Tools (F12) > Network Tab > Engine Icon > Check "Persist Logs" > Start Recording > Save HAR.

Información útil antes de analizar registros HAR

Métodos HTTP

Los métodos HTTP (también conocidos como verbos HTTP) definen el tipo de operación que un cliente desea realizar en un recurso determinado (como datos o una página Web).

Cada método tiene un propósito y una semántica específicos.

Los métodos HTTP más comunes son: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS, y TRACE.

* PATCH es generalmente ideimpotente, pero depende de la implementación.

Explicación de las columnas

• Seguro: indica si el método HTTP se considera seguro, lo que significa que no modifica los recursos ni el estado del servidor. Los métodos seguros sólo están destinados a la recuperación, no a realizar cambios. Normalmente se utilizan para operaciones de sólo lectura.
• Idempotent: Especifica si repetir la misma solicitud HTTP varias veces tiene el mismo efecto que realizarla una vez. Un método idempotent significa que no importa cuántas veces se repita la solicitud, el resultado permanece sin cambios (después de la primera solicitud correcta)
• Uso Típico: Describe el propósito o escenario común para el que se utiliza el método HTTP. Esto proporciona contexto sobre cuándo y por qué se utilizaría cada método en el desarrollo web o en el diseño de API.
• Cuerpo de la Solicitud: Indica si la solicitud HTTP incluye normalmente un cuerpo (datos enviados al servidor). El cuerpo de la solicitud se utiliza a menudo para enviar datos (como JSON, XML o datos de formulario) al servidor, como al crear o actualizar recursos. 
• Cuerpo de Respuesta: Especifica si la respuesta HTTP suele contener un cuerpo (datos devueltos por el servidor). El cuerpo de respuesta son los datos devueltos desde el servidor al cliente, como el recurso solicitado, los mensajes de estado o la confirmación de una acción.

Anatomía de un registro HAR

Nota: Todas las imágenes de ejemplo de esta sección se tomaron al intentar cargar las ubicaciones del HUB de control para una organización

Encabezados

Captura los metadatos intercambiados entre el cliente (explorador) y el servidor durante las solicitudes y respuestas HTTP.

Los encabezados proporcionan contexto sobre los datos que se envían o reciben, como el tipo de contenido, la información de autenticación, las directivas de almacenamiento en caché, etc.

Los encabezados se incluyen en estas secciones de un registro HAR:

1. Encabezados de solicitud: Se envían desde el explorador (cliente) al servidor como parte de la solicitud HTTP.
2. Encabezados de respuesta: El servidor las devuelve al explorador en respuesta a la solicitud.

Los encabezados se almacenan como matrices de pares clave-valor, donde:

• Clave: El nombre del encabezado.
• Valor: Valor asociado al encabezado.

Encabezados de solicitud comunes

1. Organizador: Especifica el nombre de dominio del servidor (por ejemplo, as example.com) y el número de puerto.

• Ejemplo: Host: www.example.com

2. Agente de usuario: Identifica el explorador o cliente que realiza la solicitud, junto con su versión y sistema operativo.

• Ejemplo: Agente de usuario: Mozilla/5.0 \(Windows NT 10.0; Win64; x64\)

3. Aceptar: Indica los tipos de contenido que el cliente puede gestionar (como HTML, JSON o imágenes).

• Ejemplo: Aceptar: texto/html,aplicación/xhtml+xml

4. Aceptar codificación: Especifica los tipos de codificación (como gzip, deflate) que el cliente puede descodificar.

• Ejemplo: Aceptar codificación: gzip, desinflar

5. Autorización: Contiene credenciales para la autenticación, como tokens o credenciales de autenticación básicas.

• Ejemplo: Autorización: Portador <token>

6. Cookies: Incluye las cookies enviadas por el cliente al servidor.

• Ejemplo: Cookie: sessionId=12345; userPref=modoOscuro

7. Tipo de contenido: Indica el tipo de datos que se envían en el cuerpo de la solicitud (para solicitudes POST/PUT).

• Ejemplo: Content-Type: Aplicación/JSON

8. Remitente: Identifica la dirección URL de la página que hizo referencia al cliente al recurso actual.

• Ejemplo: Referer: https://www.example.com/

Encabezados de respuesta comunes

1.Tipo de contenido: Especifica el tipo MIME del recurso (como text/html, application/json).

• Ejemplo: Content-Type: Aplicación/JSON

2. Longitud del contenido: Indica el tamaño del cuerpo de la respuesta en bytes.

• Ejemplo: Content-Length: 1234

3. Control de caché: Especifica las directivas de almacenamiento en caché para el recurso (como si se puede almacenar en caché y durante cuánto tiempo).

• Ejemplo: Cache-Control: no-cache, no-store, must-revalidate

4. Servidor: Identifica la versión o el software del servidor.

• Ejemplo: Servidor: Apache/2.4.29

5. Set-Cookie Contiene cookies que el servidor desea que almacene el cliente.

• Ejemplo: Set-Cookie: sessionId=67890; Ruta=/; Segura

6. Fecha: La fecha y hora en que el servidor generó la respuesta.

• Ejemplo: Fecha: Mar, 10 de octubre de 2023 12:00:00 GMT

7. Ubicación: Se utiliza en redirecciones, indicando la URL a la que debe navegar el cliente.

• Ejemplo: Ubicación: https://www.example.com/new-page

8. ETag: Identificador único del recurso, que se utiliza a menudo para almacenar en caché y crear versiones.

• Ejemplo: ETag: 12345abcd

9. Codificación del contenido: Indica cómo se codifica el cuerpo de la respuesta (como gzip, deflate).

• Ejemplo: Codificación de contenido: gzip

10. Access-Control-Allow-Origin: Especifica qué orígenes pueden tener acceso a los recursos (utilizados en CORS).

• Ejemplo: Access-Control-Allow-Origin: *

Nota: Lo más relevante para las llamadas de Webex es el encabezado Trackingid, ya que este es el ID que puede buscar en la herramienta LMA.

Carga útil

Datos enviados o recibidos en el cuerpo de una solicitud o respuesta HTTP.

Se suele asociar a solicitudes POST, PUT o PATCH, en las que el cliente envía datos al servidor, como envíos de formularios, cargas de archivos o datos JSON para las API.

La carga también puede existir en las respuestas HTTP, que contienen datos devueltos por el servidor, como HTML, JSON o contenido binario (como imágenes o archivos).

Dónde aparece la carga útil en los registros HAR

La carga útil se encuentra normalmente en dos secciones principales del registro HAR:

1. Carga útil de solicitud: Datos enviados desde el cliente (navegador) al servidor en el cuerpo de una solicitud HTTP.
2. Carga de respuesta: Datos devueltos por el servidor al cliente en el cuerpo de una respuesta HTTP.

Vista previa

Forma parte del objeto response.content y proporciona una representación de los datos devueltos por el servidor en un formato estructurado y legible, si está disponible.

La vista previa se utiliza normalmente para mostrar datos analizados o estructurados del cuerpo de la respuesta de una manera fácil de usar, como JSON, XML u otros formatos.

Esta sección es especialmente útil para depurar API, inspeccionar los datos devueltos o comprender la estructura de la respuesta del servidor.

Respuesta

La respuesta proporciona información detallada sobre la respuesta HTTP enviada por el servidor al cliente (explorador) para una solicitud específica. Esta sección contiene metadatos, encabezados, detalles de contenido y otros datos críticos que pueden ayudarle a comprender el comportamiento del servidor durante el ciclo solicitud-respuesta. Proporciona una instantánea detallada de la respuesta del servidor a una solicitud HTTP.

Iniciador

El iniciador proporciona información sobre qué desencadenó una solicitud HTTP específica durante la carga de una página web. Identifica el origen o la causa de una solicitud de red, lo que ayuda a los desarrolladores a comprender la cadena de eventos que condujeron a la solicitud. El iniciador también ayuda a rastrear el origen de una solicitud y puede señalar a la línea exacta de código o recurso responsable de realizarla.

Sincronización

La temporización proporciona un desglose detallado de las distintas etapas implicadas en el procesamiento de una solicitud y respuesta HTTP. Ayuda a los desarrolladores a comprender cuánto tarda cada paso del ciclo solicitud-respuesta, desde el inicio de la conexión hasta la recepción de la respuesta final. La temporización también realiza un seguimiento de la secuencia y la duración de los eventos que se producen cuando un explorador realiza una solicitud a un servidor y recibe una respuesta. Incluye métricas detalladas para la resolución de DNS, estableciendo la conexión, enviando la solicitud, esperando a que el servidor responda y descargando los datos de respuesta.

Resolución de problemas

Herramienta interna para ver registros HAR

Vaya a EasyLamSearch > Import HAR/Saz file.

Pasos generales de Troubleshooting

1. Abra el archivo HAR en un .
2. Identifique las solicitudes fallidas (como los errores HTTP 4xx/5xx).

3. Compruebe los tiempos de respuesta y los elementos de carga lenta.

4. Analice los encabezados de solicitud/respuesta para problemas de autenticación y CORS.

5. Busque ID de seguimiento en solicitudes de red y .
6. Contrastar los fallos con las respuestas, si es posible.

Ejemplo de Troubleshooting de Tickets

Elementos de carga lenta

Ejemplo:

• El centro de control tarda mucho tiempo en cargar los números de una ubicación

Resolución de problemas:

• Solicitar un vídeo del problema (intentando cargar la página de números de una ubicación)
• Solicitar un registro HAR al intentar cargar los números de una ubicación

1. Abra el archivo HAR en un visor HAR o en un explorador Herramientas de desarrollo.
   
2. Identifique la solicitud en la cascada vista
   
3. Haga clic en la solicitud que tarda mucho en cargarse.
4. Revise la ficha Timing del registro:

5. Compruebe los tiempos de respuesta y los elementos de carga lenta.

6. Recopile el identificador de seguimiento para ese encabezado.

7. Abra EasyLMA y busque con el id. de seguimiento.

Explicación de las fases de desglose de sincronización

A continuación, se proporciona más información sobre cada una de las fases que se pueden ver en la fichaTiempo:

• Cola. El explorador pone en cola las solicitudes antes del inicio de la conexión y cuando:
  • Hay solicitudes de mayor prioridad. La prioridad de la solicitud viene determinada por factores como el tipo de recurso y su ubicación en el documento. Para obtener más información, lea la sección de prioridad de recursos de la guía de prioridad de recuperación.
  • Ya hay seis conexiones TCP abiertas para este origen, que es el límite. (Se aplica sólo a HTTP/1.0 y HTTP/1.1.)
  • El explorador asigna brevemente espacio en la caché de disco.
• Estancada. La solicitud se puede detener después del inicio de la conexión por cualquiera de los motivos descritos en Almacenamiento en cola.
• Búsqueda de DNS. El explorador está resolviendo la dirección IP solicitada.
• Conexión inicial. El explorador está estableciendo una conexión, incluidos los intercambios o reintentos de TCP y la negociación de un SSL.
• Negociación de proxy. El explorador está negociando la solicitud con un servidor proxy.
• Solicitud enviada. Se está enviando la solicitud.
• Preparación de ServiceWorker. El explorador está iniciando el trabajador de servicios.
• Solicitud a ServiceWorker. La solicitud se envía al trabajador de servicio.
• En espera (TTFB). El explorador está esperando el primer byte de una respuesta. TTFB significa Tiempo hasta el primer byte. Este tiempo incluye 1 recorrido de ida y vuelta de latencia y el tiempo que tardó el servidor en preparar la respuesta.
• Descarga de contenido. El navegador recibe la respuesta, ya sea directamente de la red o de un trabajador de servicios. Este valor es la cantidad total de tiempo empleado en leer el cuerpo de la respuesta. Los valores mayores de lo esperado podrían indicar una red lenta o que el explorador está ocupado realizando otro trabajo que retrasa la lectura de la respuesta.

Recurso no disponible

Ejemplo: 

"He habilitado SNR para mi usuario en el hub de control de administración, pero no veo la opción de configurar el número SNR cuando inicio sesión en el portal user.webex.com.
¿Podría comprobar mi organización y mi usuario para saber por qué no puedo verlo en el hub de usuarios?"

Resolución de problemas:

1. Confirme lo que el usuario está viendo solicitando una captura de pantalla de un usuario que trabaja frente a un usuario que no trabaja.

2. Solicite un registro de HAR mientras carga las opciones para el usuario.

Pasos siguientes:

1. Abra el archivo HAR en un visor HAR o en un explorador Herramientas de desarrollo. 
   
2. Identificar solicitudes:

El servicio realiza una solicitud (GET) para conocer los servicios del usuario

Llamar a la plantilla de plantilla de acceso a funciones de usuario final (GET) para solicitar la plantilla de los servicios que se muestran al usuario:

1. Analizar encabezados de solicitud/respuesta.
   
   "Sin acceso" significa que la plantilla oculta esas opciones para el usuario.
2. Debe revisar la plantilla de la organización y activar Single number reach para que el usuario pueda verla en el User Hub.

Ejemplo:

No se puede habilitar una característica

Ejemplo con grabación de llamada:

Al intentar activar la grabación de llamadas para un usuario, recibe un mensaje de error: "Error al cambiar la grabación de llamada".

Para solucionar problemas:

1. Confirme el error solicitando el texto completo del mensaje de error.

2. Solicite una captura de pantalla del error.

3. Solicite un registro HAR mientras intenta habilitar la "Grabación de llamada" en el usuario afectado .

4. Abra el archivo HAR en un visor HAR o en el navegador Herramientas de desarrollo.

5. Identifique las solicitudes fallidas (como los errores HTTP 4xx/5xx).

6. Busque los ID de seguimiento en EasyLMA.


7. Con la excepción cpapi, puede abrir un BEMS:

8. Abra un BEMS con la información recopilada:

• Capturas de pantalla
• Mensaje de error completo
• ID de rastreo
• excepción cpapi
  
  

9. Pida en el espacio Dubber o al equipo BU que revise con el equipo Dubber el error:
"Resumen de respuesta de error: 400: Producto no válido: Error al crear el punto de duplicación en Dubber. Estado HTTP: 502"

Mensajería de FAX

Este es el diagrama que ilustra el flujo de aprovisionamiento a medida que se desplaza por los microservicios:

Cuando se solucionan problemas de aprovisionamiento de mensajería de fax en el centro de control, es fundamental recopilar un seguimiento de HAR para recopilar información detallada sobre la naturaleza del problema y comprender los motivos de los errores de aprovisionamiento. 

Al activar la función de mensajería de fax, el seguimiento HAR captura y muestra la solicitud pertinente de CH a CPAPI. Esta solicitud capturada tiene un formato específico.

Desde el CH → CPAPI:

PARCHE
Solicitar URL:https://cpapi-r.wbx2.com/api/v1/customers/[OrgID]/users/[CHUserID]/voicemail
ID de seguimiento ATLAS_4fd0efd2-f0e4-4ca2-a932-16f4b0884a48_12

Publicar datos {
"activado": verdadero,
"notificaciones": {
"activado": verdadero,
"destino": "lazoclaudiafi+faxmessaging@gmail.com"
},
"sendAllCalls": {
"activado": falso
},
"sendBusyCalls": {
"activado": verdadero,
"saludo": "PREDETERMINADO"
},
"sendUnanswerCalls": {
"activado": verdadero,
"saludo": "PREDETERMINADO",
"maxRings": 3
},
"transferToNumber": {
"activado": falso
},
"emailCopyOfMessage": {
"activado": verdadero,
"emailId": "lazoclaudiafi+faxmessaging@gmail.com"
},
"faxMessage": {
"activado": falso,
"phoneNumber": "+12099193323",
"extension": nulo
},
"messageStorage": {
"mwiEnabled": verdadero,
"storageType": "INTERNO",
"correo electrónico externo": "lazoclaudiafi+faxmessaging@gmail.com"
}

Para realizar un seguimiento eficaz de esta información en EasyLMA, consulte la guía detallada que se proporciona aquí: 

Categoría: ID de seguimiento
Sub categoría: Global
ID de seguimiento de Webex: ATLAS_4fd0efd2-f0e4-4ca2-a932-16f4b0884a48_12

Información de derivación

• Archivo de registro HAR
• Capturas de pantalla de errores
• Pasos para reproducir el problema
• Marca de hora del incidente
• Registros de LMA

Responda a estas preguntas antes de abrir el escalado de BEMS, ya que esto le ayudará con la resolución de problemas adicional:

• ¿Qué error ve?
• ¿Qué ID de rastreo ve?
• ¿Revisaste el ID de seguimiento en LMA?
• ¿Qué ve en LMA?
• ¿Es realmente necesario este BEMS?