Atrapando errores en vuelo: monitoreo y registro de aplicaciones JavaScript

¿Por qué tu código JavaScript pide ayuda a gritos y no lo escuchas?

Imagina: lanzaste una aplicación web genial. Los usuarios entran, hacen clic, todo funciona… ¿o no? En realidad, en algún lugar del navegador, un error cae silenciosamente: Uncaught TypeError: Cannot read property 'length' of undefined. El usuario simplemente cierra la pestaña y se va con la competencia, y tú ni siquiera te enteras de que algo salió mal.

Bienvenido a la realidad del desarrollo frontend. Sin monitoreo y registro de aplicaciones JavaScript, trabajas a ciegas. Pero no te apresures a agarrarte la cabeza — hoy analizaremos cómo convertir el caos de errores en un sistema de alertas ordenado. Aprenderás a registrar eventos correctamente, rastrear el rendimiento y no ahogarte en un mar de datos.

Este artículo es tu chuleta para sobrevivir en producción. ¡Allá vamos!

Console.log — ¿tu amigo o enemigo?

Empecemos por lo básico. console.log() es lo primero que se le viene a la mente a todo desarrollador. Y está bien. Pero si lo usas en código de producción, detente. ¿Por qué? Porque:

\n
• Ensucia la consola del usuario (sí, algunos la abren).
\n
• Afecta el rendimiento con una gran cantidad de llamadas.
\n
• No proporciona información estructurada.
\n

Es mejor usar niveles de registro. Aquí tienes un ejemplo del enfoque correcto:

// Mal\nconsole.log('User clicked button');\n\n// Bien\nconsole.info('User interaction', { \n    action: 'click', \n    element: '#submit-btn', \n    timestamp: Date.now() \n});\n\n// Para errores\nconsole.error('API request failed', { \n    status: 500, \n    endpoint: '/api/users' \n});\n\n// Para advertencias\nconsole.warn('Deprecated method used', { \n    method: 'fetchData_v1' \n});

Pero incluso esto es solo la punta del iceberg. El verdadero monitoreo de aplicaciones JavaScript comienza donde la consola no está disponible.

Registro estructurado: JSON al rescate

Cuando tu aplicación crece, los mensajes caóticos en la consola se convierten en un batiburrillo. La solución es el registro estructurado. Envía los datos en formato JSON para que puedan ser analizados y procesados.

Así es como puedes hacer un logger simple:

class Logger {\n    constructor(context = {}) {\n        this.context = context;\n    }\n\n    log(level, message, data = {}) {\n        const logEntry = {\n            timestamp: new Date().toISOString(),\n            level,\n            message,\n            ...this.context,\n            ...data\n        };\n\n        // En producción, enviamos al servidor\n        if (process.env.NODE_ENV === 'production') {\n            this.sendToServer(logEntry);\n        } else {\n            // En desarrollo, mostramos en consola\n            console[level](`[${level.toUpperCase()}] ${message}`, data);\n        }\n    }\n\n    sendToServer(entry) {\n        // Usamos sendBeacon para envío garantizado\n        navigator.sendBeacon('/api/logs', JSON.stringify(entry));\n    }\n\n    info(message, data) { this.log('info', message, data); }\n    warn(message, data) { this.log('warn', message, data); }\n    error(message, data) { this.log('error', message, data); }\n}\n\n// Uso\nconst logger = new Logger({ appVersion: '1.2.3', userId: getUserId() });\nlogger.info('Page loaded', { url: window.location.href, loadTime: performance.now() });

Observa navigator.sendBeacon() — es la mejor manera de enviar datos antes de que el usuario abandone la página. Las solicitudes fetch normales pueden ser canceladas.

Captura de errores: try/catch es solo el comienzo

Los errores globales son los más traicioneros. Pueden ocurrir en cualquier lugar y es fácil pasarlos por alto. Así es como configuras un monitoreo total de errores JavaScript:

Manejador global de errores

// Interceptamos errores no controlados\nw