Ingeniería de redes y seguridad · Barcelona 93 249 00 01info@wiredbarcelona.comESCAEN

Guías

Monitorización de red y NOC: seis escenarios donde marcan la diferencia

Seis escenarios habituales en redes de empresa, qué monitorizar como mínimo, cómo diseñar alertas útiles y qué aporta un NOC frente a una herramienta.

Antena satelital Starlink instalada en la cubierta como enlace de respaldo

En la mayoría de las organizaciones sin monitorización, la forma de detectar una incidencia de red es la llamada de un usuario. Para entonces el problema ya tiene impacto, no hay datos de qué ha ocurrido antes y el diagnóstico empieza desde cero. Una red monitorizada cambia el orden de los acontecimientos: la degradación se detecta antes de convertirse en caída, el origen se localiza con datos y, en muchos casos, se resuelve sin que nadie llegue a notarlo.

Esta guía muestra qué aporta la monitorización a través de escenarios tipo que se repiten en redes empresariales, qué conviene monitorizar como mínimo y qué diferencia hay entre tener una herramienta de monitorización y contar con un NOC que actúa sobre lo que esa herramienta detecta.

Contenido

  1. Seis escenarios habituales, con y sin monitorización.
  2. Qué monitorizar como mínimo.
  3. Diseñar alertas útiles.
  4. De la herramienta al NOC.

1. Seis escenarios habituales

Los siguientes escenarios son situaciones tipo que encontramos con frecuencia en redes de oficina. No describen a un cliente concreto, pero cualquier responsable de sistemas reconocerá alguno.

El enlace de respaldo que no funcionaba

La oficina tiene una línea principal de fibra y un respaldo 4G o 5G configurado para entrar automáticamente. Durante meses nadie lo comprueba. El día que la fibra cae, el respaldo no levanta: la tarjeta SIM ha caducado, el plan de datos está agotado o el router de respaldo perdió la configuración tras un corte eléctrico. La oficina queda sin servicio justo cuando se contaba con no quedarse.

Con monitorización: el enlace de respaldo se supervisa de forma continua aunque no esté en uso, con comprobaciones periódicas de su disponibilidad y su latencia. Cualquier fallo genera una alerta en el momento en que se produce, no el día que se necesita el respaldo.

Los microcortes que nadie podía demostrar

Los usuarios se quejan de cortes breves en las videollamadas y la VPN se desconecta varias veces al día. El operador revisa la línea y responde que funciona correctamente. Sin datos, la conversación no avanza y la incidencia se alarga semanas.

Con monitorización: la latencia y la pérdida de paquetes se miden de forma continua hacia la puerta de enlace del operador y hacia destinos externos. Las gráficas muestran la hora exacta, la duración y en qué tramo se produce la pérdida. Con esa evidencia, la incidencia con el operador se abre con datos concretos y se sigue hasta su resolución.

El uplink que se degradaba poco a poco

Un enlace entre el switch de una planta y el núcleo empieza a acumular errores de interfaz por un latiguillo dañado o un transceptor que se degrada. Durante semanas solo se traduce en lentitud ocasional difícil de atribuir. Un día el enlace cae y toda la planta queda desconectada.

Con monitorización: los contadores de errores (CRC, descartes) de cada interfaz se recogen por SNMP y su crecimiento genera una alerta. El elemento se sustituye en una intervención planificada, antes de que falle.

La sala técnica en fin de semana

La climatización de la sala técnica se avería un viernes por la tarde. La temperatura sube durante todo el fin de semana; los equipos empiezan a reiniciarse o se apagan por protección térmica. El lunes, la oficina no arranca y algún equipo no vuelve a encender.

Con monitorización: la temperatura que reportan switches, firewall y servidores se supervisa con umbrales de aviso. La alerta llega en cuanto la temperatura empieza a subir, con margen para actuar antes de que haya daños.

El punto de acceso que se reiniciaba

En una zona de la oficina el wifi se corta de vez en cuando durante unos minutos. Tras varias quejas se revisa el punto de acceso y parece funcionar bien. La causa real es que el switch está al límite de su presupuesto PoE y, cuando aumenta el consumo de otros dispositivos, el punto de acceso se queda sin alimentación suficiente y se reinicia.

Con monitorización: el consumo PoE frente al presupuesto del switch y el tiempo de funcionamiento de cada punto de acceso quedan registrados. Los reinicios coinciden con los picos de consumo y la causa se identifica sin necesidad de reproducir el problema.

La línea que «se había quedado corta»

La percepción general es que internet va lento y la propuesta es contratar más caudal. Nadie sabe realmente cuánto se usa la línea ni cuándo.

Con monitorización: el histórico de tráfico muestra si la línea se satura y en qué franjas. Con frecuencia la saturación coincide con copias de seguridad o sincronizaciones programadas en horario laboral, y se resuelve reprogramándolas o aplicando QoS. Cuando realmente hace falta más capacidad, el histórico permite dimensionarla con datos.

2. Qué monitorizar como mínimo

  • Disponibilidad de equipos de red, firewall, puntos de acceso, servidores y sedes.
  • Enlaces WAN principal y de respaldo, y túneles VPN hacia sedes y nube: estado, latencia y pérdida de paquetes.
  • Tráfico por interfaz, con histórico para ver tendencias.
  • Estado de interfaces, velocidad negociada y contadores de errores.
  • CPU, memoria y temperatura del electrónico.
  • Consumo PoE frente al presupuesto de cada switch.
  • Registros de los equipos centralizados por syslog, con la hora sincronizada por NTP.
  • Si procede, servidores, almacenamiento y copias de seguridad: un backup que falla en silencio es uno de los riesgos más habituales.

La recogida se realiza mediante SNMP, ICMP, syslog y las API de cada plataforma, según lo que admita cada fabricante. Una plataforma como LibreNMS permite integrar equipos de distintos fabricantes en una única consola, con históricos y alertas.

3. Diseñar alertas útiles

Una monitorización mal configurada genera tantas alertas que acaban ignorándose. Es el problema de la fatiga de alertas, y anula el valor de la herramienta. Las alertas deben diseñarse para la red concreta:

  • Umbrales adaptados al comportamiento normal de cada equipo y enlace, no valores genéricos.
  • Dependencias: si cae el enlace de una sede, una sola alerta del enlace en lugar de una por cada equipo de esa sede.
  • Persistencia: alertar cuando una condición se mantiene durante un tiempo, no ante cada pico puntual.
  • Ventanas de mantenimiento para que los cambios planificados no generen falsas alarmas.
  • Severidad y destinatario: cada alerta debe indicar su gravedad y llegar a quien puede actuar.

4. De la herramienta al NOC

Una herramienta de monitorización detecta; no resuelve. Si las alertas llegan al buzón de una persona que tiene otras responsabilidades, que está de vacaciones o que no conoce a fondo la red, la detección temprana se pierde. Es la diferencia entre tener monitorización y tener un NOC (Network Operations Center): un equipo técnico que recibe las alertas, las analiza y actúa sobre la infraestructura.

El proceso de un NOC ante una incidencia sigue una secuencia definida:

  1. Detección automática por la plataforma.
  2. Análisis: se identifica el elemento afectado y se evalúa el impacto.
  3. Diagnóstico con los históricos y los registros del momento.
  4. Actuación en remoto sobre la infraestructura o, si hace falta, desplazamiento de un técnico que ya conoce la red.
  5. Seguimiento con el operador, el fabricante o el proveedor externo cuando la resolución depende de ellos.
  6. Verificación y cierre, con la incidencia documentada.

Aplicado a los escenarios anteriores, la diferencia es tangible: el respaldo caído se repara antes de necesitarlo, la incidencia con el operador la abre y la sigue el NOC con las gráficas, el latiguillo se cambia en una intervención planificada y el aviso de temperatura del sábado lo atiende alguien que sabe qué hacer. Además, el NOC acumula conocimiento de la red: cada incidencia mejora la documentación y la configuración de las alertas.

Monitorizar es medir; operar es actuar

El valor de la monitorización no está en el panel, sino en lo que ocurre cuando salta una alerta. Sin un responsable técnico que actúe, la mejor herramienta solo documenta con precisión cómo se produjo la caída.

Cuándo es necesaria una intervención especializada

Desde nuestro NOC propio supervisamos sobre LibreNMS la red de nuestros clientes: equipos, enlaces WAN, túneles VPN, wifi y, si se nos encarga, servidores, almacenamiento y backup. Configuramos las alertas para cada red, actuamos en remoto y hacemos el seguimiento con operadores y fabricantes hasta la resolución. Lo detallamos en el servicio de monitorización y NOC.

Si su red depende de un único enlace o de equipos sin redundancia, la monitorización es también el punto de partida para mejorar la arquitectura de red. Y para una valoración general de su infraestructura, puede utilizar nuestro autodiagnóstico de red.

Firma

Carlos Carulla · Ingeniero de redes

Ingeniería de redes y seguridad en Wired Barcelona. Diseño, despliegue y soporte de infraestructuras de red para empresas desde hace más de 25 años.

¿Necesita un diagnóstico de su red?

Cuéntenos el síntoma. Le responde un ingeniero de redes, no un comercial, con una valoración técnica de si procede intervenir y cómo.

Más guías