Monitorización

Qué cubre esta categoría

Saber que algo está roto antes de que un cliente se lo explique: comprobaciones de disponibilidad, seguimiento de errores, métricas, registros, trazas y las alertas que despiertan a alguien.

Los productos van desde una única comprobación que hace ping a una URL hasta plataformas que ingieren todo lo que emite una infraestructura. La distancia entre ellos es sobre todo de volumen de datos y de precio.

El análisis del comportamiento de los clientes pertenece a analítica. Dónde se ejecuta la aplicación es alojamiento y nube.

Empezar desde fuera

La primera compra más útil es la más sencilla: una comprobación que carga su sitio desde varios lugares y avisa cuando deja de funcionar.

Las comprobaciones externas detectan los fallos que los paneles internos no ven, entre ellos los certificados caducados, los registros rotos y un cambio de cortafuegos que nadie anunció. Son baratas y, para muchos equipos pequeños, cubren casi todo lo importante.

El seguimiento de errores va en segundo lugar. Saber qué excepciones llegan a usuarios reales, con qué frecuencia y desde qué versión convierte un aviso vago en una corrección. La calidad de la agrupación es lo que separa aquí a los productos, ya que una herramienta que produce cuatro mil alertas casi idénticas produce ruido.

Los tipos de datos

• Comprobaciones de disponibilidad, desde fuera, en las rutas que los clientes usan de verdad.
• Errores, agrupados, con la versión y el contexto del usuario adjuntos.
• Métricas, numéricas y baratas de conservar, para tendencias y umbrales.
• Registros, detallados y caros, para reconstruir lo ocurrido.
• Trazas, que muestran una petición a través de los servicios, para encontrar dónde se va el tiempo.

La mayoría de los equipos necesitan los dos primeros de inmediato, las métricas poco después y el resto cuando un sistema es lo bastante complejo como para que adivinar haya dejado de funcionar.

La retención es la restricción silenciosa. Comparar hoy con el mismo día del mes pasado requiere un mes de datos, y los planes de entrada suelen guardar una semana.

Las alertas son un problema de diseño

Una alerta que nadie atiende enseña a todos a ignorar la siguiente, y ese hábito es lo que alarga las caídas.

Hay que alertar sobre lo que experimentan los usuarios y no sobre cada umbral interno. Una página que carga despacio importa. Un procesador al ochenta por ciento, por sí solo, normalmente no.

Toda alerta necesita tres cosas: un responsable, una acción documentada y una vía que llegue al responsable cuando duerme. Todo lo que no supere esa prueba debería ser una entrada de panel y no una notificación.

Después, revisar con regularidad. Las alertas se acumulan, las condiciones cambian y una poda trimestral es el trabajo de fiabilidad más barato que existe.

El coste y por qué las facturas crecen sin avisar

El precio se calcula por host, por usuario, por volumen ingerido o por eventos, y el modelo por volumen es donde viven las sorpresas.

Un solo servicio que registra de forma prolija puede multiplicar la factura mientras el tráfico se mantiene plano. El muestreo, el filtrado en origen y una retención más corta para los datos detallados son los controles habituales, así que conviene preguntar qué ofrece el producto antes de necesitarlos.

Las métricas personalizadas merecen una pregunta concreta, ya que a menudo se cobran por serie única y una etiqueta mal elegida puede crear miles. Conviene pedir un tope de gasto y no una alerta, y mirar lo que ocultan las páginas de precios para el resto del patrón.

Ponerlo en marcha por cuenta propia

Las implementaciones abiertas son capaces y su licencia es gratuita. El coste operativo es real: almacenamiento, retención, actualizaciones y alguien de guardia para el propio sistema de monitorización.

Este último punto es el que hay que sopesar. Una pila autoalojada tiende a fallar en el mismo incidente que aquello que vigilaba, que es justo cuando más se necesita.

Empezar pequeño sin atarse las manos

Una primera configuración de monitorización debería ser aburrida y estar terminada en una tarde.

Dos comprobaciones externas en las rutas que importan, el seguimiento de errores integrado en la aplicación y una vía de alerta que llegue a una persona. Eso cubre la mayoría de los incidentes que tendrá un producto pequeño en su primer año.

Se añaden métricas cuando se empieza a preguntar por qué algo fue lento y no si estaba roto. Se añaden trazas cuando el sistema tiene suficientes piezas móviles como para que la respuesta ya no sea evidente en un registro.

La decisión que conviene tomar pronto es dónde se recogen los datos y en qué formato. La instrumentación escrita sobre un estándar abierto puede apuntarse más tarde a otro backend, mientras que la escrita sobre la biblioteca de un proveedor se convierte en un argumento contra cambiar jamás.

Conviene llevar un registro escrito de lo que significa cada alerta y de quién responde. Esa página vale más a las tres de la madrugada que cualquier panel.