En la majoria d’organitzacions sense monitoratge, la manera de detectar una incidència de xarxa és la trucada d’un usuari. Llavors el problema ja té impacte, no hi ha dades del que ha passat abans i el diagnòstic comença de zero. Una xarxa monitorada canvia l’ordre dels esdeveniments: la degradació es detecta abans de convertir-se en caiguda, l’origen es localitza amb dades i, en molts casos, es resol sense que ningú arribi a notar-ho.
Aquesta guia mostra què aporta el monitoratge a través d’escenaris tipus que es repeteixen en xarxes empresarials, què convé monitorar com a mínim i quina diferència hi ha entre tenir una eina de monitoratge i comptar amb un NOC que actua sobre el que aquesta eina detecta.
Contingut
- Sis escenaris habituals, amb monitoratge i sense.
- Què cal monitorar com a mínim.
- Dissenyar alertes útils.
- De l’eina al NOC.
1. Sis escenaris habituals
Els escenaris següents són situacions tipus que trobem sovint en xarxes d’oficina. No descriuen un client concret, però qualsevol responsable de sistemes en reconeixerà algun.
L’enllaç de reserva que no funcionava
L’oficina té una línia principal de fibra i una reserva 4G o 5G configurada per entrar automàticament. Durant mesos ningú no la comprova. El dia que la fibra cau, la reserva no aixeca: la targeta SIM ha caducat, el pla de dades s’ha esgotat o el router de reserva va perdre la configuració després d’un tall elèctric. L’oficina es queda sense servei just quan es comptava amb no quedar-s’hi.
Amb monitoratge: l’enllaç de reserva se supervisa de manera contínua encara que no s’utilitzi, amb comprovacions periòdiques de la seva disponibilitat i latència. Qualsevol fallada genera una alerta en el moment en què es produeix, no el dia que es necessita la reserva.
Els microtalls que ningú no podia demostrar
Els usuaris es queixen de talls breus a les videotrucades i la VPN es desconnecta diverses vegades al dia. L’operador revisa la línia i respon que funciona correctament. Sense dades, la conversa no avança i la incidència s’allarga setmanes.
Amb monitoratge: la latència i la pèrdua de paquets es mesuren de manera contínua cap a la porta d’enllaç de l’operador i cap a destinacions externes. Les gràfiques mostren l’hora exacta, la durada i en quin tram es produeix la pèrdua. Amb aquesta evidència, la incidència amb l’operador s’obre amb dades concretes i se’n fa el seguiment fins a la resolució.
L’uplink que es degradava a poc a poc
Un enllaç entre el switch d’una planta i el nucli comença a acumular errors d’interfície per un latiguillo danyat o un transceptor que es degrada. Durant setmanes només es tradueix en lentitud ocasional difícil d’atribuir. Un dia l’enllaç cau i tota la planta queda desconnectada.
Amb monitoratge: els comptadors d’errors (CRC, descarts) de cada interfície es recullen per SNMP i el seu creixement genera una alerta. L’element se substitueix en una intervenció planificada, abans que falli.
La sala tècnica en cap de setmana
La climatització de la sala tècnica s’avaria un divendres a la tarda. La temperatura puja durant tot el cap de setmana; els equips comencen a reiniciar-se o s’apaguen per protecció tèrmica. Dilluns, l’oficina no arrenca i algun equip no torna a encendre’s.
Amb monitoratge: la temperatura que reporten switches, firewall i servidors se supervisa amb llindars d’avís. L’alerta arriba tan bon punt la temperatura comença a pujar, amb marge per actuar abans que hi hagi danys.
El punt d’accés que es reiniciava
En una zona de l’oficina el wifi es talla de tant en tant durant uns minuts. Després de diverses queixes es revisa el punt d’accés i sembla que funciona bé. La causa real és que el switch és al límit del seu pressupost PoE i, quan augmenta el consum d’altres dispositius, el punt d’accés es queda sense prou alimentació i es reinicia.
Amb monitoratge: el consum PoE davant del pressupost del switch i el temps de funcionament de cada punt d’accés queden registrats. Els reinicis coincideixen amb els pics de consum i la causa s’identifica sense haver de reproduir el problema.
La línia que «s’havia quedat curta»
La percepció general és que internet va lent i la proposta és contractar més cabal. Ningú no sap realment quant s’utilitza la línia ni quan.
Amb monitoratge: l’històric de trànsit mostra si la línia se satura i en quines franges. Sovint la saturació coincideix amb còpies de seguretat o sincronitzacions programades en horari laboral, i es resol reprogramant-les o aplicant QoS. Quan realment cal més capacitat, l’històric permet dimensionar-la amb dades.
2. Què cal monitorar com a mínim
- Disponibilitat d’equips de xarxa, firewall, punts d’accés, servidors i seus.
- Enllaços WAN principal i de reserva, i túnels VPN cap a seus i núvol: estat, latència i pèrdua de paquets.
- Trànsit per interfície, amb històric per veure tendències.
- Estat d’interfícies, velocitat negociada i comptadors d’errors.
- CPU, memòria i temperatura de l’electrònica.
- Consum PoE davant del pressupost de cada switch.
- Registres dels equips centralitzats per syslog, amb l’hora sincronitzada per NTP.
- Si escau, servidors, emmagatzematge i còpies de seguretat: un backup que falla en silenci és un dels riscos més habituals.
La recollida es fa mitjançant SNMP, ICMP, syslog i les API de cada plataforma, segons el que admeti cada fabricant. Una plataforma com LibreNMS permet integrar equips de diferents fabricants en una única consola, amb històrics i alertes.
3. Dissenyar alertes útils
Un monitoratge mal configurat genera tantes alertes que s’acaben ignorant. És el problema de la fatiga d’alertes, i anul·la el valor de l’eina. Les alertes s’han de dissenyar per a la xarxa concreta:
- Llindars adaptats al comportament normal de cada equip i enllaç, no valors genèrics.
- Dependències: si cau l’enllaç d’una seu, una sola alerta de l’enllaç en lloc d’una per cada equip d’aquella seu.
- Persistència: alertar quan una condició es manté durant un temps, no davant de cada pic puntual.
- Finestres de manteniment perquè els canvis planificats no generin falses alarmes.
- Severitat i destinatari: cada alerta ha d’indicar-ne la gravetat i arribar a qui pot actuar.
4. De l’eina al NOC
Una eina de monitoratge detecta; no resol. Si les alertes arriben a la bústia d’una persona que té altres responsabilitats, que és de vacances o que no coneix a fons la xarxa, la detecció primerenca es perd. És la diferència entre tenir monitoratge i tenir un NOC (Network Operations Center): un equip tècnic que rep les alertes, les analitza i actua sobre la infraestructura.
El procés d’un NOC davant d’una incidència segueix una seqüència definida:
- Detecció automàtica per part de la plataforma.
- Anàlisi: s’identifica l’element afectat i se n’avalua l’impacte.
- Diagnosi amb els històrics i els registres del moment.
- Actuació en remot sobre la infraestructura o, si cal, desplaçament d’un tècnic que ja coneix la xarxa.
- Seguiment amb l’operador, el fabricant o el proveïdor extern quan la resolució en depèn.
- Verificació i tancament, amb la incidència documentada.
Aplicat als escenaris anteriors, la diferència és tangible: la reserva caiguda es repara abans de necessitar-la, la incidència amb l’operador l’obre i la segueix el NOC amb les gràfiques, el latiguillo es canvia en una intervenció planificada i l’avís de temperatura del dissabte l’atén algú que sap què cal fer. A més, el NOC acumula coneixement de la xarxa: cada incidència millora la documentació i la configuració de les alertes.
Monitorar és mesurar; operar és actuar
El valor del monitoratge no és al panell, sinó en el que passa quan salta una alerta. Sense un responsable tècnic que actuï, la millor eina només documenta amb precisió com es va produir la caiguda.
Quan cal una intervenció especialitzada
Des del nostre NOC propi supervisem sobre LibreNMS la xarxa dels nostres clients: equips, enllaços WAN, túnels VPN, wifi i, si se’ns encarrega, servidors, emmagatzematge i backup. Configurem les alertes per a cada xarxa, actuem en remot i fem el seguiment amb operadors i fabricants fins a la resolució. Ho detallem al servei de monitoratge i NOC.
Si la seva xarxa depèn d’un únic enllaç o d’equips sense redundància, el monitoratge és també el punt de partida per millorar l’arquitectura de xarxa. I per a una valoració general de la seva infraestructura, pot fer servir el nostre autodiagnòstic de xarxa.