La red se degrada semanas antes de que alguien llame

Se entera cuando llama el usuario

Pregunte en su organización cómo se enteran de que algo está mal en la red. La respuesta honesta, en la mayoría de los casos, es que alguien llama. El usuario del sitio sur reporta que la aplicación va lenta, y ahí empieza el trabajo: revisar interfaces, mirar utilización, buscar en registros, comparar con la semana pasada.

Para cuando el equipo de redes confirma que hubo saturación en el enlace, el evento ya pasó. Se puede explicar. No se pudo evitar, y probablemente no se sepa desde cuándo venía degradándose.

El problema de fondo es que la auditoría —incluso una que cubra configuración y estado— es una fotografía. Contesta muy bien qué pasa ahora. No contesta desde cuándo, ni con qué tendencia, ni si esto ya había ocurrido.

Una auditoría le dice cómo está la red. Una serie de tiempo le dice hacia dónde va.

Qué agrega medir en el tiempo

Guardar métricas como serie de tiempo —procesador, memoria, temperatura, utilización y errores por interfaz— cambia el tipo de pregunta que se puede contestar:

• Desde cuándo. El procesador de ese equipo no está alto desde hoy: subió hace once días y no bajó. Eso apunta a un cambio, no a un pico.
• Con qué tendencia. El enlace de área amplia va en setenta por ciento y crece cinco puntos por trimestre. La conversación de presupuesto deja de ser una opinión.
• Si es normal. Ochenta por ciento de utilización un lunes a las nueve puede ser el comportamiento de siempre. Sin historia no hay forma de saberlo, y se persiguen falsas alarmas.
• Qué pasó durante el incidente. La ventana ya cerró, pero los contadores quedaron. Se puede reconstruir en vez de depender de lo que alguien recuerde.

Hay una consecuencia práctica importante: esto tiene un perfil de consumo distinto al resto de la plataforma. Almacenar series de tiempo crece con el número de equipos multiplicado por la frecuencia de muestreo, y eso es una decisión de infraestructura y de costo, no una casilla que se activa.

De medir a reaccionar

Tener la métrica y mirarla en un tablero sigue siendo operación reactiva, sólo que con mejor información. El salto siguiente es que la plataforma reaccione sola ante condiciones definidas.

Una regla de evento es simple de enunciar: una condición y una acción. Lo difícil no es escribirla, es acotar bien las dos partes.

La condición tiene que ser específica para no dispararse de más. «Procesador alto» genera ruido. «Procesador por encima del umbral durante más de diez minutos sostenidos en un equipo de distribución» es accionable. Una regla que se dispara seguido se silencia, y una regla silenciada es peor que no tenerla: da la sensación de cobertura sin darla.

La acción tiene que ser proporcional al riesgo. Recolectar diagnóstico, abrir un registro o notificar es seguro y se puede automatizar sin reparos. Cambiar configuración de forma automática ante un evento es otra categoría: es exactamente el escenario que describimos en el artículo sobre cerrar el ciclo, ahora sin nadie mirando y a las tres de la mañana.

Nuestra postura es que la mayoría de las reglas deben recolectar evidencia y avisar, no modificar. El valor está en que cuando el ingeniero abra el caso, el diagnóstico ya esté hecho.

Qué eventos vale la pena vigilar

Los que indican pérdida de redundancia o degradación progresiva, que son los que el usuario aún no reporta:

• Caída de sesión del protocolo de puerta de enlace. Rara vez es cosmética: casi siempre significa que un camino desapareció.
• Caída de vecino del protocolo interno. La red reconverge y sigue funcionando, y por eso nadie se entera de que se perdió un camino alterno. El próximo incidente ya no tiene por dónde recuperarse.
• Interfaz abajo en un enlace redundante. El servicio no se cae. La redundancia sí.
• Umbrales de procesador, memoria y temperatura. Los tres avisan antes de fallar, si alguien mira.
• Errores crecientes en una interfaz. Un transceptor o un cable degradándose da señales durante semanas.

Todos tienen algo en común: no producen una llamada del usuario. Son justamente los que sólo se detectan si algo los está vigilando.

Cómo lo resuelve Oktavia

La telemetría y la orquestación de eventos se licencian aparte del resto de Oktavia, y la razón es la que explicamos arriba: almacenan series de tiempo y corren un evaluador permanente, así que tienen otro perfil de consumo. No toda red las necesita desde el primer día, y la que las necesita las suma cuando quiere.

Lo que incluyen: métricas en tiempo real de procesador, memoria e interfaces como series de tiempo, con umbrales y tendencias; tableros propios y compatibilidad con Grafana, para que la métrica se consuma también desde las herramientas que la organización ya usa; y el motor de automatización de eventos, con reglas de condición a acción sobre caídas de sesión del protocolo de puerta de enlace, caídas de vecino del protocolo interno, interfaces abajo y umbrales de procesador, memoria, temperatura y errores.

Todo sobre el mismo inventario y la misma fuente de verdad que el resto de la plataforma. Un evento sabe a qué equipo pertenece, en qué sitio está, qué rol cumple y cuál es su configuración deseada, sin que nadie tenga que mantener una segunda lista de equipos para el sistema de monitoreo.

Oktavia: la plataforma completa, en tres minutos.