¿Qué monitorizar en un sitio web y una aplicación? Una lista práctica desde el uptime hasta los errores y el rendimiento

CPU, RAM, load average, contenedores, procesos, solicitudes, errores, logs, colas, bases de datos, DNS, SSL, API, uptime, tiempos de respuesta, Core Web Vitals y muchos otros.

El problema es que monitorizar un mayor número de métricas no significa necesariamente tener una mejor monitorización.

En la práctica, lo más importante es detectar los problemas que realmente afectan a los usuarios o al negocio.

Por eso, en lugar de empezar con la pregunta:

«¿Qué podemos medir?»

es mejor preguntarse:

«¿De qué problemas queremos enterarnos antes de que nos informe un cliente?»

1. ¿El sitio web funciona?

Este es el nivel más básico de monitorización.

Un sistema externo envía regularmente una solicitud al sitio web y comprueba si recibe una respuesta correcta.

Esto permite detectar, entre otros:

• HTTP 500,
• HTTP 502,
• HTTP 503,
• timeouts,
• imposibilidad de establecer una conexión,
• problemas de DNS,
• redirecciones incorrectas.

Esto es el clásico uptime monitoring.

Si el sitio web se comprueba cada minuto, un problema puede detectarse potencialmente en aproximadamente un minuto, en lugar de esperar a que alguien entre por casualidad y reporte la incidencia.

Pero el uptime es solo el principio.

2. ¿El sitio web responde con suficiente rapidez?

Un sitio web puede estar disponible y, al mismo tiempo, ser muy lento.

Por eso, en cada comprobación también conviene registrar el tiempo de respuesta.

Supongamos que una aplicación responde normalmente en:

250-400 ms

De repente empieza a responder en:

1.8-3.5 s

Todavía no tenemos un downtime completo.

Sin embargo, existe un cambio claro en el comportamiento del sistema.

Puede significar:

• sobrecarga del servidor,
• un problema con la base de datos,
• una API externa lenta,
• agotamiento de los workers disponibles,
• un problema con la caché,
• un cambio provocado por el último deployment.

Por tanto, la monitorización del tiempo de respuesta puede detectar un problema antes que una alerta clásica de indisponibilidad.

3. ¿La degradación es temporal o persistente?

Una única solicitud más lenta no tiene por qué significar que exista un problema.

Internet no es un entorno completamente determinista.

Por eso, en lugar de reaccionar ante cada anomalía individual, conviene analizar el comportamiento a lo largo del tiempo.

Por ejemplo:

10:00 - 320 ms
10:01 - 340 ms
10:02 - 310 ms
10:03 - 870 ms
10:04 - 350 ms

Un único valor de 870 ms probablemente no sea motivo de alarma.

Pero:

10:00 - 320 ms
10:01 - 510 ms
10:02 - 840 ms
10:03 - 1.3 s
10:04 - 2.1 s
10:05 - 3.4 s

ya muestra una tendencia clara.

Una buena monitorización debería ayudar a distinguir una desviación temporal de una degradación real del servicio.

4. ¿El certificado SSL es válido?

El certificado SSL es uno de los elementos más sencillos de monitorizar.

Y, al mismo tiempo, uno de los más fáciles de olvidar.

Un problema con el certificado puede hacer que el usuario vea una advertencia de seguridad en lugar del sitio web.

En el caso de una tienda online o una aplicación, esto puede detener prácticamente todo el tráfico.

Por eso, la monitorización debería comprobar:

• si el certificado es válido,
• cuándo caduca,
• si el dominio del certificado es correcto,
• si es posible establecer correctamente una conexión HTTPS.

La principal ventaja de este tipo de monitorización es la posibilidad de reaccionar antes de que se produzca una incidencia.

No es necesario esperar a que el certificado caduque.

La alerta puede llegar con suficiente antelación.

5. ¿La aplicación genera errores?

La monitorización externa muestra la aplicación desde la perspectiva del usuario.

La monitorización de errores la muestra desde dentro.

Si la aplicación genera una excepción:

PaymentException

o:

DatabaseConnectionException

conviene saberlo independientemente de que la página de inicio siga respondiendo con un código 200.

El propio mensaje de error tampoco suele ser suficiente.

El contexto es mucho más útil:

• dónde se ha producido el error,
• cuándo se produjo por primera vez,
• cuándo se produjo por última vez,
• cuántas veces se ha producido,
• qué versión de la aplicación estaba desplegada,
• qué endpoint se estaba ejecutando,
• cuál es el stack trace,
• si está aumentando el número de apariciones.

Esto permite pasar de:

«tenemos un error»

a:

«sabemos por dónde empezar a buscarlo».

6. No todos los errores tienen la misma importancia

Supongamos que el sistema ha registrado dos excepciones.

La primera:

5 apariciones en 30 días

La segunda:

5 000 apariciones en los últimos 20 minutos

Técnicamente, ambas pueden representar exactamente el mismo tipo de excepción.

Sin embargo, desde el punto de vista operativo son situaciones completamente diferentes.

Por eso, en la monitorización de errores no solo importa saber:

«¿qué error se ha producido?»

sino también:

«¿cómo está cambiando la frecuencia con la que se produce?»

Un aumento repentino del número de errores después de desplegar una nueva versión puede ser mucho más importante que el simple hecho de que exista una determinada excepción.

7. ¿El despliegue de una nueva versión ha provocado algún problema?

Uno de los usos más valiosos de la monitorización es observar la aplicación inmediatamente después de un deployment.

Imaginemos:

14:02 - deployment version 2.18.4
14:05 - primeros errores nuevos
14:07 - 120 errores
14:10 - 640 errores

Sin información sobre la versión de la aplicación, solo vemos un aumento del número de errores.

Si la monitorización conoce el release, obtenemos mucho más contexto:

los problemas comenzaron pocos minutos después de desplegar la versión 2.18.4.

Esto no significa automáticamente que el deployment sea la causa.

Pero es una pista de diagnóstico muy importante.

8. ¿El sitio web es rápido para el usuario?

El tiempo de respuesta del servidor y la velocidad del sitio web en el navegador no son lo mismo.

El servidor puede devolver el HTML en 150 ms, pero el sitio web puede seguir cargando:

• imágenes grandes,
• JavaScript,
• fuentes,
• anuncios,
• scripts de analítica,
• widgets externos.

Por eso, también conviene monitorizar el rendimiento del sitio web.

Uno de los puntos de referencia estándar son los Core Web Vitals.

LCP - Largest Contentful Paint

Mide la rapidez con la que aparece el elemento principal del contenido de la página.

INP - Interaction to Next Paint

Mide la capacidad de respuesta del sitio web después de una interacción del usuario.

Hacer clic en un botón, seleccionar una opción o introducir datos puede parecer que «no funciona» si el navegador responde con un retraso considerable.

Se considera que un INP de hasta 200 ms en el percentil 75 es un buen resultado.

CLS - Cumulative Layout Shift

Mide los desplazamientos inesperados de los elementos mientras se utiliza el sitio web.

Por ejemplo, el usuario quiere hacer clic en el botón:

Comprar ahora

pero justo antes del clic se carga un banner encima y el botón se desplaza a otro lugar.

Este es precisamente el tipo de problema que CLS ayuda a medir.

9. ¿Por qué conviene monitorizar el rendimiento regularmente?

Una prueba puntual de PageSpeed es útil.

Pero un sitio web no permanece sin cambios.

Puede aparecer:

• un nuevo banner,
• un nuevo script de marketing,
• una etiqueta de analítica adicional,
• una nueva versión de la aplicación,
• una nueva biblioteca JavaScript,
• imágenes de productos más grandes,
• un cambio de fuentes,
• un nuevo widget de chat.

Cualquiera de estos cambios puede empeorar el rendimiento.

Por eso, una pregunta mucho más interesante que:

«¿Qué puntuación de PageSpeed tenemos hoy?»

es:

«¿Está empeorando el rendimiento de nuestro sitio web con el tiempo?»

La monitorización permite observar la tendencia.

10. ¿Conviene monitorizar únicamente la página de inicio?

Normalmente, no.

La página de inicio suele ser solo uno de los muchos tipos de páginas de un sitio web.

En una tienda online conviene considerar la monitorización de:

/
/product/example
/category/example
/cart
/checkout

En un SaaS:

/
/login
/register
/dashboard

así como de los endpoints más importantes de la API.

No se trata de monitorizar todas las URL de la misma manera.

Se trata de seleccionar puntos críticos representativos.

11. ¿Qué monitorizar en una tienda online?

Un conjunto mínimo razonable puede incluir:

Disponibilidad de la tienda

¿Responde la tienda?

Tiempo de respuesta

¿La tienda ha empezado de repente a funcionar mucho más lentamente?

SSL

¿El certificado es válido y no se acerca su fecha de caducidad?

Errores de la aplicación

¿WooCommerce, PrestaShop o el backend personalizado generan nuevos errores?

Checkout

¿Está disponible la parte clave del proceso de compra?

Rendimiento

¿Han empeorado Core Web Vitals u otros parámetros de rendimiento después de los cambios?

Integraciones críticas

Si las ventas dependen de servicios externos, los problemas también pueden afectar a:

• los pagos,
• el ERP,
• el sistema de gestión de stock,
• los servicios de mensajería,
• los marketplaces,
• las API externas.

Una tienda puede funcionar técnicamente y, al mismo tiempo, no ser capaz de procesar correctamente los pedidos.

12. ¿Qué monitorizar en una aplicación SaaS?

En el caso de un SaaS, las prioridades pueden ser algo diferentes.

Conviene monitorizar:

• el sitio web público,
• el inicio de sesión,
• la API,
• los errores del backend,
• los procesos de negocio más importantes,
• los tiempos de respuesta,
• las tareas en segundo plano,
• las colas,
• las integraciones externas,
• SSL,
• el rendimiento del frontend.

Es especialmente importante monitorizar las funciones por las que el usuario realmente paga.

Si el dashboard funciona, pero la función principal del producto ha dejado de funcionar, desde el punto de vista del negocio la aplicación tiene una incidencia grave.

13. La monitorización debería responder preguntas, no producir datos

Es fácil crear un dashboard que contenga:

47 gráficos
23 métricas
15 estados
8 tablas

y seguir sin saber si la aplicación funciona correctamente.

Una buena monitorización debería permitir responder rápidamente a unas pocas preguntas sencillas:

• ¿Funciona la aplicación?
• ¿Funciona tan rápido como de costumbre?
• ¿Han aparecido nuevos errores?
• ¿Ha aumentado repentinamente el número de errores?
• ¿El certificado es válido y seguro?
• ¿Ha empeorado el rendimiento del sitio web?
• ¿Funcionan las funciones de negocio más importantes?

Si la monitorización no ayuda a responder estas preguntas, disponer de más datos no resolverá necesariamente el problema.

14. ¿Por dónde empezar?

No es necesario crear desde el principio un sistema de observabilidad complejo.

Para muchos sitios web y aplicaciones, un buen punto de partida es monitorizar cuatro áreas:

1. Uptime - ¿está disponible el servicio?
2. Errores - ¿genera excepciones la aplicación y está aumentando su número?
3. SSL - ¿el certificado es válido y no se acerca su fecha de caducidad?
4. Rendimiento - ¿el sitio web sigue funcionando tan rápido como antes?

Más adelante se pueden añadir mecanismos más específicos en función del tipo de aplicación.

La regla más importante de la monitorización

La monitorización no debería existir simplemente para tener un dashboard.

Debería reducir el tiempo entre la aparición de un problema y el momento en que la persona adecuada se entera de él.

Mejor aún si permite detectar que la situación está empeorando antes de que se produzca una caída completa.

El peor escenario no siempre es una aplicación que ha dejado de funcionar.

A veces es mucho peor una aplicación que lleva varias horas sin funcionar correctamente y cuyo propietario todavía no lo sabe.