Un sistema basato su eventi i protocolli di gestione della rete funzionano in modo molto diverso dai sistemi basati su query.
In qualsiasi sistema basato su eventi, il sistema di gestione della rete semplicemente ascolta i possibili annunci
o eventi da inviare via cavo.
In genere i protocolli di gestione della rete che sfruttano questi tipi di eventi sono basati
sul log o su P-trap.
Ora sono controllabili in termini di quantità di dettagli ricevuti dai dispositivi sulla rete.
Quindi, ad esempio su Cisco Rodda, è possibile abilitare il debug che produce una grande quantità di dati.
C'è un sacco di dettagli di basso livello che vengono generati con il debug.
Potrebbe non essere necessariamente necessario che la quantità di dati venga trasferita al sistema di gestione della rete.
Uno dei problemi qui è se si riceve una grande quantità di dati che sta per
setacciare i dati per prendere decisioni significative sui dati ricevuti.
Quindi non vuoi che sia sufficiente abilitare molte informazioni basate sugli eventi per aiutare a guardare oltre
uno dei vantaggi dei sistemi basati su eventi è che possono reagire molto rapidamente.
In altre parole, se un evento si svolge sulla rete, il sistema di gestione della rete può
agire immediatamente su quell'evento piuttosto che attendere la scadenza di un intervallo di polling.
Ad esempio, se si esegue il polling dell'interfaccia di un router per il suo stato ogni cinque minuti,
si saprà che si interfaccia quando viene eseguito il sondaggio o quando viene eseguita una query in un sistema basato su query.
Ma se l'interfaccia si interrompe subito dopo aver eseguito il polling, potrebbero essere necessari altri cinque
minuti per rendersi conto che l'interfaccia si interrompe quando il sistema di gestione della rete tira il router ogni
cinque minuti.
Riceverà una risposta positiva dal Rodda confermando che l'interfaccia è un esempio.
In genere viene fatto utilizzando un protocollo di gestione della rete come Ace e MP.
Quindi sai che l'interfaccia è operativa perché hai interrogato il router se non ricevi una risposta dal router,
quindi sai che c'è un problema.
Ma il lato negativo di un sistema basato su query è che lo si esegue solo ogni cinque minuti.
Se l'interfaccia si interrompesse immediatamente dopo aver tirato il router, potrebbero essere necessari fino a cinque
minuti per capire che c'è un problema sull'interfaccia di quel router dove, come in qualsiasi
sistema basato su eventi, è inviato un messaggio di trapping vuoto immediatamente quando l'interfaccia va giù.
Quindi in questo caso il router sta informando il sistema di gestione della rete che c'è un
problema piuttosto che il sistema di gestione della rete che deve attendere un intervallo di cinque minuti per interrogare
il Rodda per lo stato di un'interfaccia.
Ora c'è un lato negativo dei sistemi basati sugli eventi, i protocolli di gestione della rete non
sono affidabili perché il sistema di gestione della rete è semplicemente passivamente in attesa e in attesa di ricevere gli eventi.
Non saprebbe se c'è stato un problema sulla rete se quell'evento non ha raggiunto il sistema di
gestione della rete.
Pertanto, se si verifica un problema di rete o una necessità di smarrimento che impedisce al messaggio di
registro o a una trap vuota di raggiungere il sistema di gestione della rete, il sistema di gestione della rete
non è a conoscenza del problema senza il polling esplicito del dispositivo di rete.
Quindi, quali sono le best practice che cosa dovresti fare in un ambiente live, come le best practice affermano
che dovresti utilizzare entrambi i protocolli di gestione della rete basati su polling o basati su query come pure quelli basati su
eventi come parte della soluzione di gestione della rete.
Ora non aiuta solo a ricevere una grande quantità di dati.
È necessario prendere decisioni significative su tali dati.
Pertanto, si desidera anche mettere in evidenza e sfruttare gli avvisi e i report in modo che entrambi vengano
avvisati quando si verifica un problema, sia che si tratti di un meccanismo di rilevamento basato sul polling o di un rilevamento basato su eventi.
Inoltre, vorrai una sorta di funzionalità di reporting che ti fornisca dettagli sulle
prestazioni non solo in tempo reale.
A questo punto nel tempo ma per un periodo di tempo.
Quindi vuoi dati storici disponibili in modo che tu possa prendere decisioni significative.
Ad esempio se un'interfaccia su un Rodda ha un utilizzo del 70 percento è così buona.
Che cosa è così male
È difficile sapere se non disponi di dati storici che ti consentano di costruire una base di riferimento
su ciò che tipicamente esegue la tua rete.
Se quell'interfaccia negli ultimi tre mesi è stata utilizzata con un utilizzo del 2% e
ora funziona all'improvviso con il 90% di utilizzo, saprai che qualcosa è accaduto sulla tua rete
che è cambiata in modo drastico nell'utilizzo dell'interfaccia.
Pertanto, vorrai che i rapporti ti forniscano dettagli sulle prestazioni nel tempo e ti informino dei problemi e
della disponibilità dei dispositivi nella tua rete.
Volete a colpo d'occhio essere in grado di vedere se c'è un problema con un dispositivo
di rete come un router o se c'è un problema con una singola interfaccia su uno dei vostri router.
Non dimenticare di impostare la frequenza di polling e la granularità delle notifiche degli eventi.
Questo può variare da un ambiente all'altro e spesso dipende dal tipo di tipologia di
disponibilità della larghezza di banda e dalle risorse che è necessario rilevare e quindi agire sulle informazioni che
si ricevono.
Inoltre, potrebbe essere necessario prendere decisioni su quanto velocemente è necessario reagire a un problema
sulla rete se qualcosa accade sulla rete e si ripercuote su un intero edificio per l'intera organizzazione su
cui si vorrà agire rapidamente.
Ma se succede qualcosa e interessa solo un singolo dispositivo che non è importante, probabilmente
non è così importante che ti svegliano alle 3 del mattino per dirti che la porta sull'interruttore
è diminuita.