Netlog: una poderosa herramienta basada en eventos para detectar errores en la carga de una web

En el vertiginoso mundo de la tecnología web, donde la velocidad y la confiabilidad son fundamentales, la detección temprana de errores en la carga de una página web es crucial para brindar a los usuarios una experiencia impecable.

En este contexto, Netlog emerge como una poderosa herramienta basada en eventos que se ha convertido en un aliado esencial para desarrolladores y propietarios de sitios web.

Netlog no solo detecta errores de carga en tiempo real, sino que también proporciona datos detallados que permiten una solución rápida y eficaz.

En este artículo exploraremos esta herramienta desde una perspectiva práctica.

Estaremos hablando del formato de este tipo de logs y cómo extraer información importante para ayudar a desarrolladores a optimizar la calidad de una página web y garantizar así una experiencia fluida para los visitantes.

→ Te puede interesar: Ngrok: cómo compartir tu aplicación local con un simple comando

Primeramente, ¿qué es Netlog y cómo puedes utilizarlo?

NetLog es una herramienta de registro de eventos esencial para desarrolladores de sitios web que puede ser utilizada en navegadores derivados de Chromium.

Permite capturar eventos de red clave durante la navegación web, lo que facilita la depuración de problemas y el análisis de rendimiento.

Los usuarios habilitan el registro de red, reproducen problemas y luego cargan los archivos de registro resultantes en informes de errores.

Los desarrolladores pueden analizar estos registros para comprender lo que sucedió durante la interacción con el sitio web.

Su funcionamiento se basa en la instrumentación de la pila de red de Chrome, lo que proporciona datos detallados para resolver problemas y optimizar el rendimiento del sitio web, asegurando una experiencia de usuario fluida.

Para generar un netlog puedes introducir en la barra de búsqueda de Chrome el siguiente comando:

chrome://net-export/

Obtendrás una pantalla como esta, donde podrás configurar algunos detalles de privacidad y tamaño para la generación del log.

Una vez configurado, puedes hacer clic en el botón Start Logging to Disk y abrir en otra pestaña la web que deseas analizar. Interactúas con la página hasta el punto en que deseas analizar y luego detienes la grabación de eventos en la pestaña inicial.

De este modo obtendrás un archivo en formato JSON con todos los eventos lanzados por tu navegador durante todo el proceso.

Análisis de eventos

Una vez que tienes el archivo JSON con todos los eventos, puedes proceder a analizarlo, pero, si lo abres, te encontrarás con un formato muy difícil de leer a simple vista. Hagamos la prueba abriendo uno:

Y esto es solo el principio, estos archivos suelen ser muy grandes.

Más adelante explicaremos a detalle estos archivos y podrás entenderlo, no es tan complicado como parece inicialmente, pero, por suerte para nosotros, ya existen herramientas con interfaces gráficas detalladas que nos ayudan a identificar los eventos ocurridos y darle seguimiento.

Algunas de estas herramientas son:

• Netlog Viewer: Herramienta oficial para la visualización de Netlog.

Ejemplo:

• Telerik Fiddler: Herramienta de análisis de varios formatos de logs. Por defecto no incluye netlog, pero puede ser agregado como extensión mediante este repositorio.

Ejemplo:

La primera variante se basa en la visualización de eventos y nos da información más completa.

La segunda te muestra la información de una forma más intuitiva con un formato similar a la consola de desarrollador de nuestro navegador en su sección Red.

Puede que con esto sea suficiente para resolver problemas sencillos, pero si buscas algo específico debes profundizar más en el formato de un netlog para aprovechar al máximo su potencial. Veamos varios de sus conceptos básicos.

Claves para entender un netlog

Un netlog se compone de dos partes fundamentales, constantes y eventos.

Las constantes se pueden localizar en las primeras líneas del archivo, y nos dan toda la información que necesitamos para entender lo que ocurre en cada evento.

Si tu objetivo es implementar un parser para este formato, debes prestar especial atención a las constantes porque de aquí podrás extraer las claves que necesitas.

Cada evento de un netlog se compone de varios elementos que aportan información para recrear el evento en su contexto.

Son precisamente las constantes quienes enumeran cada uno de estos elementos con un ID que se utilizará en todo el archivo. Algunos de estos elementos son:

Event Type: Tipo del evento en análisis. Cada tipo de evento nos aporta información diferente y debemos identificarlos para saber dónde encontrar los datos que necesitamos para resolver nuestro problema. El listado de los tipos de eventos puedes encontrarlo dentro del netlog en constants/logEventTypes.

A continuación, te muestro algunos tipos de eventos que se capturan, son muchos más. Puedes ver el tipo de evento con su ID a la derecha:

HTTP_STREAM_JOB 147

HTTP_STREAM_JOB_BOUND_TO_QUIC_STREAM_FACTORY_JOB 154

HTTP_STREAM_JOB_BOUND_TO_REQUEST 155

HTTP_STREAM_JOB_CONTROLLER 160

HTTP_STREAM_JOB_CONTROLLER_ALT_SVC_FOUND 163

HTTP_STREAM_JOB_CONTROLLER_BOUND 161

HTTP_STREAM_JOB_CONTROLLER_PROXY_SERVER_RESOLVED 162

HTTP_STREAM_JOB_DELAYED 158

HTTP_STREAM_JOB_INIT_CONNECTION 152

HTTP_STREAM_JOB_ORPHANED 157’

Source Type: De forma similar a los tipos de eventos tenemos las fuentes. Estas representan las entidades que emiten los eventos. Veamos algunos ejemplos:

PROXY_CLIENT_SOCKET 19

QUIC_CONNECTION_MIGRATION 9

QUIC_SESSION 10

QUIC_STREAM_FACTORY_JOB 25

SERVER_PUSH_LOOKUP_TRANSACTION 24

SOCKET 7

SOCKS_CONNECT_JOB 4

SSL_CONNECT_JOB 5

TRANSPORT_CONNECT_JOB 6

TRIAL_CERT_VERIFIER_JOB 28

UDP_SOCKET 16

URL_REQUEST 1

WEB_TRANSPORT_CLIENT 32

Net Errors: Enumera los posibles errores que pueden ser detectados por netlog. Aquí te van algunos:

ERR_PROXY_AUTH_UNSUPPORTED -115

ERR_PROXY_CERTIFICATE_INVALID -136

ERR_PROXY_CONNECTION_FAILED -130

ERR_PROXY_HTTP_1_1_REQUIRED -366

ERR_QUIC_CERT_ROOT_NOT_KNOWN -380

ERR_QUIC_GOAWAY_REQUEST_CAN_BE_RETRIED -381

ERR_QUIC_HANDSHAKE_FAILED -358

ERR_QUIC_PROTOCOL_ERROR -356

ERR_READ_IF_READY_NOT_IMPLEMENTED -174

ERR_REQUEST_RANGE_NOT_SATISFIABLE -328

ERR_RESPONSE_BODY_TOO_BIG_TO_DRAIN -345

Phases: Algunos eventos tienen un inicio y un fin con diferencia de tiempo. Para esto surgen las fases. Los eventos abren con fase 1 y cierran con fase 2. Existen algunos que no tienen apertura y cierre, su ocurrencia es instantánea, por lo que para ellos aplica la fase 0.

Time tick offsets: El tiempo en Netlog se maneja como un timestamp partiendo de una base de tiempo que viene en este parámetro. Por tanto, para obtener la fecha debes sumarle al tiempo que viene en cada evento este time tick offset y convertir el timestamp resultante.

Con estos conceptos ya estás en condiciones de analizar un netlog. Mi recomendación es que implementes un parser sencillo para unir todas estas constantes sus IDs y así obtener la información completa.

time_tick_offsets = data['constants']['timeTickOffset']
sources = data['constants']['logSourceType']
net_errors = data['constants']['netError']
events_types = data['constants']['logEventTypes']
phases = data['constants']['logEventPhase']
events = data['events']

Resumiendo, el modo de trabajo debería basarse en el análisis de los eventos de un netlog a través de la búsqueda de los identificadores en las constantes.

{'params': {'priority': 'HIGHEST', 'traffic_annotation': 63171670, 'url': 'https://google.com/'}, 'phase': 1, 'source': {'id': 20, 'start_time': '4157806332', 'type': 1}, 'time': '4157806332', 'type': 2}

Por ejemplo, este evento de tipo 2 (REQUEST_ALIVE) tiene como fase 1 (Begin) lo que significa que es su apertura, una fuente de tipo 1 (URL_REQUEST) con un id de fuente 20, lo que significa que pertenece a las request 20.

El time se suma a la constante timeTickOffset para obtener la fecha y hora en que fue registrado.

Agrupar eventos en requests

Para visualizar todos los eventos de una request determinada debes usar el id de la fuente de los eventos.

Todos los eventos con el mismo source_id pertenecen a la misma request.

De este modo puedes localizar la request con problemas (demora en cargar, errores en el netlog, etc) y buscar todos sus eventos para analizar su comportamiento.

Tipos de eventos principales:

Una vez que agrupamos los eventos en requests, podemos inspeccionar que tipos de eventos ocurrieron en una de ellas, para llevarnos una idea de la información que podemos extraer.

Te dejo un ejemplo de eventos en el orden en que fueron registrados y explicaremos algunos

Como ves, la request comienza con un evento de tipo CORS_REQUEST.

Esta petición se hace antes de enviar la petición real para que el sitio nos diga si la admitirá según los datos que se le proporcionan.

Una vez pasada esta comprobación se prepara una request mediante el evento REQUEST_ALIVE y se lanza en el evento URL_REQUEST_START_JOB, que representa la petición del recurso.

De este último evento podemos extraer el protocolo, método HTTP (GET, POST, etc), la URL del recurso al que se intenta acceder, el tipo de request, entre otros datos.

Una vez enviada la petición podemos darle seguimiento a los eventos de red que ocurren que nos pueden dar información sobre problemas a nivel de equipamiento de red y servidores, certificados de seguridad, tiempos de latencia, etc.

Podemos acceder a los headers de la petición mediante el evento HTTP_TRANSACTION_READ_HEADERS y de forma similar obtener información de los headers de la response con el evento HTTP_TRANSACTION_READ_RESPONSE_HEADERS.

El evento HTTP_CACHE_WRITE_INFO nos dice como se maneja la caché en esta request específica.

Por último, URL_REQUEST_JOB_FILTERED_BYTES_READ contiene la información que solicitamos en la request codificada en base64. De esta forma es posible obtener el contenido original de los javascript, css, html o cualquier recurso que se haya pedido en la request en cuestión.

¿Qué problemas puedo detectar con Netlog?

1. Problemas de seguridad en páginas web.
2. Problemas de configuración en equipamiento de red.
3. Errores en DNS.
4. Problemas de resolución de proxies.
5. Análisis de caché
6. Problemas debido a extensiones de Chrome u otros elementos que ralentizan la conexión al recurso solicitado.
7. Fallas en la disponibilidad de recursos de una web determinada.
8. Problemas en el acceso y resolución de las CDN.

Estos son solo algunos ejemplos, con esta información probablemente se te ocurran muchos otros casos que puedes aplicar para resolver tu problema específico.

Hasta aquí el artículo de hoy. Espero que la información brindada te sea de utilidad y comiences a utilizar esta poderosa herramienta para analizar tus páginas webs de manera preventiva o para resolver errores por el equipo de soporte en retroalimentación con los usuarios.