Caso di Studio - Antonio Di Maio · Stratum I diversi server NTP sono organizzati in una struttura...
Transcript of Caso di Studio - Antonio Di Maio · Stratum I diversi server NTP sono organizzati in una struttura...
Website www.antoniodimaio.com | Email [email protected] | Skype dimaio_antonio
Antonio Di Maio è un Ingegnere Elettronico Professionista, registrato presso l’ordine degli Ingegnieri dal 2005 e specializzato in: hardware, networking, software, ingegneria, sistemi informativi e consulenza aziendale.
Note sull’autoreIntroduzione
Con l’obiettivo di estendere la propria area aereoportuale il Qatar ha assegnato alla Selex Sistemi Integrati (oggi Selex Ex), l’implementazione di un nuovo e moderno aereoporto chiamato NDIA. Nella torre principale di controllo è installato un Server per la sincronizzazione temporale della Meinberg monitorato da NetCrunch 24x7.
Desidero ringraziare tutte le persone che hanno partecipato a questa esperienza. In particolar modo Furio Baroncini di Sincron Srl, che ha creduto nelle mie capacità per questo importante progetto.
Antonio Di Maio, 2012
✈ Monitoring Time Server in QatarCASE HISTORY
Caso di Studio✈ Monitoraggio di un Time Server in Qatar
» Supporto Prevendita» Supporto Online» Applicazioni Web» Assistenza e Testing
» Ingegneria» Applicazioni Custom» Technology Consulting» Raccolta Dati
» Website & SEO» SNMP» Sistemi Embedded» Networking
Ringraziamenti
Website www.antoniodimaio.com | Email [email protected] | Skype dimaio_antonio
» IT Training» Analisi pacchetti
» Assistenza Remota» Analisi delle Prestazioni» Windows» Documentazione
» Analisi delle MIB» Analisi dei Cavi» Syslog» Analisi Protocolli
» Analisi Requisiti» SNMP» Configurazione Trap» Server
Aereoporto di Doha
Al termine dei lavori previsiti nel 2015, l’aeroporto porterà ogni anno 50 milioni di passeggeri, 2 milioni di tonnellate di carico merci nonché 320,000 atterraggi e partenze.
L’aeroporto è in fase di costruzione nei pressi della città di Doha e, alla conclusione dei lavori, come dimensioni raggiungerà approssimativamente i 2/3 della città di Doha. L’aeroporto diventerà il perno centrale della manutenzione, localizzato nel centro del campo, avrà la capacità di gestire fino a 8 aerei di grandi dimensioni, inclusi A380s e 11 aerei normali.
Monitoraggio del Traffico Aereo
NDIA sarà connesso ad una sistema dorsale in fibra ottica; le operazioni di archiviazione dei dati dell’aeroporto verranno realizzate tramite un sistema di rete supplementare dedicato. Cuore del sistema è la torre di controllo. In cima a quest’ultima è situata la sala di controllo per il monitoraggio, posta tra le due piste parallele ed i servizi per gli aerei. Il personale predisposto al controllo del traffico aereo monitorerà l’attività grazie ad uno schermo dedicato ad alta risoluzione; di supporto vi sarà una stanza per il training che, in caso di emergenze, potrà diventare una stanza di controllo perfettamente funzionale.
La Sicurezza
Gli E-gates installati ai terminal identificheranno i passeggeri il giorno prima dell’imbarco così da tracciare i passeggeri prima di entrare o uscire dallo Stato. Il sistema per la gestione dei bagagli sarà monitorato attraverso la tecnologia (BHS) che utilizza frequenze radio per l’identificazione di supporti (RFID); sarà anche potenziato il sistema di sicurezza in linea, che incorpora
sistemi CTX di livello 3 per rilevamento degli esplosivi.
La città di Doha
Doha è la capitale dello stato del Qatar.
È situata sulla costa del Golfo Persico, conta una popolazione di 998,651 abitanti (stime del 2008). Doha è la città più grande del paese, dove risiede più del 60% della popolazione.
A Doha hanno sede le principali industrie petrolifere nazionali, infatti l’economia del paese è basata prevalentemente sul petrolio; per questo motivo il governo nazionale sta facendo grandi sforzi per diversificare i vari settori economici. Doha è sede dell’annuale congresso World Innovation Summit for Education.
Website www.antoniodimaio.com | Email [email protected] | Skype dimaio_antonio
Il sistema GPS
Il Sistema di Posizionamento Globale (in inglese: Global Positioning System, abbreviato GPS, a sua volta abbreviazione di NAVSTAR GPS) è un sistema di posizionamento e navigazione satellitare civile che, attraverso una rete dedicata di satelliti artificiali in orbita, fornisce ad un terminale mobile o ricevitore GPS informazioni sulle sue coordinate geografiche e orario, in ogni condizione meteorologica, ovunque sulla terra o nelle sue immediate vicinanze dove vi sia un contatto privo di ostacoli.
La localizzazione di un dispositivo avviene tramite la trasmissione di un segnale radio da parte di ciascun satellite e l’elaborazione dei segnali ricevuti da parte del ricevitore. ll sistema è costituito da tre segmenti: spazio, controllo, utente.
Il segmento controllo è costituito dalla Stazione di Controllo Principale (MCS) localizzata in Colorado e assolve funzioni di comando e controllo dei satelliti, cinque stazioni senza equipaggio di monitoraggi posizionate strategicamente in diversi luoghi della terra e 3 antenne di trasmissione di terra. Le stazioni senza equipaggio tracciano passivamente tutti i satelliti visibili, collezionando dati da ognuno di essi. Questi dati vengono passati in modo sicuro all’MCS dove la posizione del satellite (“ephemeris”) e dati temporali sono stimati e calcolati.
Il segmento spazio definisce la costellazione dei satelliti costituita da circa 30 satelliti mentre, Il segmento utente è costituito semplicemente da tutti gli utenti finali che hanno acquistato uno dei tanti ricevitori che supportano GPS.
La sincronizzazione
Per garantire una perfetta precisione temporale ogni satellite è equipaggiato con quattro orolo-gi atomici, due di rubidio e due di cesio. Questi orologi sono precisi entro due miliardesimi di se-condi per mese e sono in genere economici; per una corretta comunicazione è fondamentale che gli orologi siano sincronizzati e che non vi siano differenze temporali tra gli orologi dei vari satel-liti e l’orologio del dispositivo.
Ogni ricevitore è costituito da una propria me-moria che contiene la banca dati per identificare i satelliti; il ricevitore fa riferimento a queste in-formazioni interamente per generare un’ esatta replica del codice del satellite durante la comu-nicazione ( il codice deve essere generato sia nel ricevitore sia nel satellite nello stesso istante).
L’altra funzione importante del ricevitore è quella di calcolare il delta-t, ovvero il tempo impiegato dal segnale per arrivare dal satellite al ricevitore. Questo metodo di misura (comparazione di ritar-do) tra le due copie di codice è chiamato Metodo a Correlazione Codice.
Supponiamo adesso che il ricevitore GPS sia in grado di determinare le posizione di almeno 4 satelliti in orbita, e che conosca la distanza da uno all’altro satellite dal ricevitore, grazie alla tec-nica della triangolazione il ricevitore sarà in gra-do di determinare la sua posizione. La triangolazione è il calcolo della posizione di un punto fisso tramite la conoscenza della distanza che intercorre tra questo punto fisso e altri tre punti di posizione nota.
» Supporto Prevendita» Supporto Online» Applicazioni Web» Assistenza e Testing
» Ingegneria» Applicazioni Custom» Technology Consulting» Raccolta dati
» Website & SEO» SNMP» Sistemi Embedded» Networking
Website www.antoniodimaio.com | Email [email protected] | Skype dimaio_antonio
Posizione del satellite
La determinazione della distanza tra il ricevitore e i satelliti non è sufficiente poichè fornisce solo la nostra posizione relativa ai satelliti. Ai fini della risoluzione dell’equazione è necessario conoscere anche la posizione assoluta dei satelliti nello spazio.
Per calcolare la posizione del ricevitore è necessario conoscere anche la posizione di ogni satellite nello spazio per risolvere l’equazione matematica. A tale scopo vengono inviati al ricevitore due tipi di dati: l’almanacco e l’emisfero, dati che vengono continuamente trasmessi dal satellite GPS. L’almanacco contiene informazioni sullo stato del satellite e informazioni sulle orbite mentre, l’emisfero contiene una descrizione della relazione tra l’orario del GPS e l’orologio del satellite.
Time Server e protocollo NTP
Un time server è un computer che legge il tempo attuale da una sorgente di riferimento (ad esempio un satellite) e distribuisce questa informazione ai clienti che usano un computer in rete. Il server può essere posizionato nella rete locale o raggiungibile tramite Internet.
Uno dei principali protocolli utilizzati oggi per la trasmissione di queste informazioni è il protocollo NTP. Non è l’unico, ne esistono altri che trasmettono questi dati tramite collegamenti radio e connessioni seriali.
La sorgente di riferimento può essere costituita da un altro time server della rete o da un orologio radio o orologio atomico, e sono in genere costituiti non da un singolo elemento ma organizzati in una vera e propria rete dedicata alla distribuzione dell’orario.
Stratum
I diversi server NTP sono organizzati in una struttura gerarchica di “strati”, dove lo strato 1 è sincronizzato con una fonte temporale
esterna quale un orologio atomico, GPS o un orologio radio controllato; lo strato 2 riceve i dati temporali da server di strato 1, e così via. Un server si sincronizza confrontando il suo orologio con quello di diversi altri server di strato superiore o dello stesso strato. Questo permette di aumentare la precisione e di eliminare eventuali server scorretti. Un server NTP è in grado di stimare e compensare gli errori sistematici dell’orologio hardware di sistema, che normalmente è di scarsa qualità. Esistono diverse implementazioni per diversi sistemi operativi.
NTP Timestamps
Il dato a 64 bit scambiato dal protocollo è suddiviso in 32 bit che definiscono i secondi e altri 32 bit per la parte decimale. Ogni 232 secondi l’intervallo temporale descritto dal protocollo si ripete, per cui è necessario specificare a quale periodo ci si riferisce.
» Supporto Prevendita» Supporto Online» Applicazioni Web» Assistenza e Testing
» Ingegneria» Applicazioni Custom» Technology Consulting» Raccolta dati
» Website & SEO» SNMP» Sistemi Embedded» Networking
Website www.antoniodimaio.com | Email [email protected] | Skype dimaio_antonio
Il Time Server
Il server installato presso la torre di controllo a Doha è un Meinberg LANTIME M300. Il server si occupa di mantenere sincronizzati tutti i clienti NTP della rete e i sistemi di controllo volo della torre. Dal pannello frontale un ampio display mostra lo stato di tutti i sottosistemi NTP. La configurazione può essere effettuata tramite web browser o da terminale (SSH o Telnet).
Sicurezza del Server
I dati trasferiti dal time server possono essere cifrati tramite gli algoritmi a chiave simmetrica (MD5) e tramite le procedure di autokey di NTP nonché autenticati. Questo livello di protezione e di autenticazione protegge i client da possibili tentativi di manipolazione dei pacchetti NTP in una rete internet.
Supporto per la Gestione della Rete
Il Time server supporta il protocollo SNMP v1,v2.c e v3 e il protocollo syslog, entrambi configurabili tramite l’interfaccia web o dal terminale.
L’architettura modulare del Time server dispone di due porte ethernet per la ridondanza, una porta per connessioni in fibra ottica e tre porte Gigabit Ethernet.
Meinbergwww.meinbergglobal.com
Meinberg è stata fondata nel 1979 da Werner e Günter Meinberg, e rappresenta oggi una società di successo. L’azienda è costituita da più di 60 dipendenti coinvolti nello sviluppo e nella produzione di dispositivi e sistemi elettronici per la sincronizzazione di tempo e frequenza.
Meinberg offre una vasta gamma di ricevitori GPS, WWVB, DCF77 (Pzf) e orologi radio MSF, schede di sincronizzazione a livello di bus e relativi accessori. Tutti i prodotti offerti da Meinberg sono sviluppati in Bad Pyrmont, Germania.Uno dei prodotti di punta è rappresentato dai Time Server per la sicronizzazione temporale degli orologi in ambito aziendale.
Per maggiori informazioni contattare [email protected]
» Supporto Prevendita» Supporto Online» Applicazioni Web» Assistenza e Testing
» Ingegneria» Applicazioni Custom» Technology Consulting» Raccolta dati
» Website & SEO» SNMP» Sistemi Embedded» Networking
Website www.antoniodimaio.com | Email [email protected] | Skype dimaio_antonio
Il software di Monitoraggio
NetCrunch è un prodotto per il monitoraggio di una rete internet in grado di controllare ogni applicazione, servizio, server e apparato connesso; è la soluzione implementata per il controllo 24/7 del Time Server LANTIME a Doha.
Include molte opzioni di notifica (via e-mail, pager, ICQ, SMS, SNMP), correzioni automatiche, allarmi, log degli eventi, trend, reportistica e accesso via Web, viste personalizzate della rete e strumenti diagnostici TCP.
Gestione della Rete e delle Applicazioni
NetCrunch è in grado di tracciare le prestazioni dei servizi della rete come Ping, HTTP, SSH, FTP, NTP. Verifica inoltre le connessioni aggiornando in automatico i diagrammi (ad esempio lo stato delle connessioni delle due interfacce NTP del Time Server).
Tutti gli eventi, i fault della rete, i log degli eventi di Windows, i messaggi di syslog dei server e quelli dei device Snmp vengono registrati in un database interno che può essere consultato, filtrato ed esportato in diversi formati. Il prodotto è inotre compatibile con IPFix, NetFlow, sFlow, JFlow, netStream, CFlow, AppFlow e rFlow.
Gli “Open Monitor” consentono di ricevere i dati da una fonte remota (tramite REST, da un sito remoto o da un altro applicativo della rete). Le informazioni, inviate sotto forma di contatori, possono essere trasmesse a NetCrunch tramite uno script (ad esempio, VBScript, PowerShell, Javascript) specificando una chiave REST per garantire l’autenticità e formattando i dati con JSON. Possono essere inviate sia richieste GET che POST.
AdRem Softwarewww.adremsoft.com
Fondata nel 1998, Adrem Software è un’azienda specializzata nello sviluppo e nella ricerca di soluzioni per la gestione, l’amministrazione, la risoluzione dei guasti ed il monitoraggio di una rete Internet. I prodotti AdRem trovano impiego in qualsiasi tipo di infrastuttura, dalle piccole imprese fino alle grandi organizzazioni anche con più di 2000 nodi. Il monitoraggio delle prestazioni, delle disponibilità dei dispositivi e dei servizi della rete riduce il downtime nonché i costi necessari per la loro manutenzione, garantendo così che tutte le diverse tecnologie presenti siano sempre disponibili e funzionali.I software AdRem permettono di gestire il proprio network, in un’unica soluzione ad un unico prezzo.
Per maggiori informazioni contattare [email protected]
Open Monitors e NetFlow
» Supporto Prevendita» Supporto Online» Applicazioni Web» Assistenza e Testing
» Ingegneria» Applicazioni Custom» Technology Consulting» Raccolta dati
» Website & SEO» SNMP» Sistemi Embedded» Networking
Website www.antoniodimaio.com | Email [email protected] | Skype dimaio_antonio
» Definizione Monitor» Definizione Diagrammi
» Installazione NetCrunch» Configurazione» Scansione Rete» Creazione Mappe
» Verifica Rack» Gestione Dati» Verifica Hardware» Definizione Apparato
» Problem Solving » Troubleshooting» Analisi TCP/IP» Analisi Requisiti
Giorno 1
Configurazione della macchina e Verifica della Rete
Giunto all’aereoporto intorno alle 9 di mattina (ora locale), effettuo tutte le procedure di sicurezza prima di recarmi presso la torre di controllo, dislocata a circa 2km dagli uffici. Qui trovo una macchina server 2003 sulla quale, dopo aver verificato i requisiti minini e la compatibilità, procedo con l’installazione dell’applicativo NetCrunch Server da CD. Sì da CD, perchè la sala server, per questioni di sicurezza non è connessa ad internet. Questo ha complicato la comunicazione con i fornitori e con gli ingegneri stessi degli uffici a Doha.
A seguito dell’installazione provvedo alla presa in carico delle interfacce e all’importazione delle MIB, premurosamente caricate su penna usb il giorno prima. Sfortunatamente, dopo alcuni tentativi mi accorgo che NetCrunch non è in grado di comunicare con il time server, sebbene il segmento a noi dedicato fosse di soli tre nodi (nessun firewall installato).
Lo switch, al quale NetCrunch era connesso, mostrava l’interfaccia ethernet in stato (up/up) solo per un breve intervallo di tempo per poi passare nello stato down dopo alcuni secondi. Non avendo accesso come admin ho trascorso diverse ore effettuando la diagnostica della rete a livello fisico e tramite strumenti per l’analisi dei pacchetti. Ho scoperto che la comunicazione era bloccata a causa di restrizioni, come confermato da una verifica effettuata su un piccolo switch, con il quale ho poi completato parte della configurazione in attesa che i responsabili modificassero le impostazioni della porta dello switch dell’armadio.
Attività principali - Giorno 1
Armadio
La Stanza Server
Controlli all’ingresso dell’area NDIA
Website www.antoniodimaio.com | Email [email protected] | Skype dimaio_antonio
» Messaggi Custom» Azioni Correttive
» Definizione Eventi» Definizione Allarmi» Simulazione e Testing» GUI
» Linking delle Mappe» Politiche Dinamiche» Politica NTP» Filtro Eventi
» Mappe e Viste» Definizione Nodi» Icone» Analisi Database
Giorno 2
Diagramma del Sistema e Visualizzazione degli Allarmi
Avere a disposizione un diagramma della rete accurato consente di migliorare la tracciabilità degli elementi chiave e la risoluzione tempestiva dei guasti. Come si può vedere dall’immagine, ho creato una dashboard degli allarmi che ho posizionato nella parte bassa dello schermo, “customizzata” a seguito di colloqui effettuati con gli operatori locali in Qatar.
Lo stato degli allarmi può essere facilmente modificato da menu di contesto (Risolto, Assegnato, In Attesa..); la risoluzione dell’allarme nasconde l’evento dalla vista principale grazie ad una query dinamica che ho configurato sulla vista corrente. Ho scelto questo approccio per fornire agli operatori una sorta di coda dei problemi in attesa di risoluzione; in effetti per il personale gli allarmi vengono meglio rappresentati come “task” ed una volta eseguiti devono sparire dalla coda principale. Nel grafico della “componentistica”, le icone degli elementi assumono colorazioni ed effetti diversi a seconda dell’appartenenza alla classe dei problemi (nodo non risponde - connettività, servizio non risponde - problema a livello applicativo). Questa suddivisione è stata concordata con il personale e documentata dopo una fase di testing/presentazione dei risultati. Anche le icone sono state personalizzate.
Principali Attività - Giorno 2
Vista Globale del Sistema
Grafico della Componentistica
Website www.antoniodimaio.com | Email [email protected] | Skype dimaio_antonio
» Definizione Soglie» Reportistica» Logging Locale» Syslog
»Analisi a lungo Termine» NTP RTT» SNMP RTT» PING RTT
» Pacchetti Persi NTP» Pacchetti Persi SNMP» Pacchetti Persi PING» Statistiche RealTime
» Stato Servizio NTP » Stato Servizio SNMP » Stato Servizio PING» Connettività di Rete
Giorno 3
Monitoraggio dei Servizi della Rete
Il monitoraggio dei servizi di rete TCP in NetCrun-ch avviene tramite le socket. Ogni servizio in ascolto su una porta TCP come NTP, può essere monitorato da NetCrunch, che diventa un client TCP; NetCrunch verifica la disponibilità (con-nessione TCP instaurata) e la correttezza dei pat-tern di risposta inviati dal serivizio in risposta alle stringhe di richiesta da me configurate.
Trovo questa modalità di monitoraggio interes-sante e utile, ad esempio laddove non è pos-sibile accedere al sistema remoto come utente admin o tramite SNMP. Le possibilità di moni-toraggio sono davvero tante perchè è possibile creare cloni e ereditare le proprietà da un servi-zio base.
Di ogni servizio è possibile tracciare e creare eventi, cruscotti e rapporti per (%pacchetti per-si, %errori, media RTT) e confrontare queste statistiche, in un unico grafico, con uno o più servizi di riferimento esistenti. In Qatar sono stati scelti come principali servizi: NTP, PING e SNMP. Ho impostato alcuni controlli sui paramentri dell’antenna tramite SNMP, con-sentendo così al personale di tracciare le stati-stiche del servizio e ricevere segnalazioni trami-te SMS in caso di errori.
Principali Attività - Giorno 3
Allarmi a livello di Servizio
>> OBJECT >> EVENT >> ACTION
NTP NTP service is DOWNWrite to event log
NTP NTP service is UPWrite to event log
SNMP SNMP serviceis UPWrite to event log
SNMP SNMP service is DOWNWrite to event log
NTP / %Packet Lost
NTP packets lost >15%.Write to event log
SNMP / %Packet Lost
SNMP packets lost > 15%.
Write to event log
Connection Reliability
Failure rate > 25%.Write to event log
PING RTT > 1000ms
RTT > 1000 msWrite to event log
Analisi tramite le soglie
La tipologia di allarmi configurata per alcuni eventi è quella “dell’isteresi” - definendo due soglie (positiva/negativa) - dopo aver effettuato uno studio approfondito della grandezza fisica da prendere in carico nel sistema.In questo modo ho eliminato la possibilità di generare falsi allarmi. Ad esempio il numero di pacchetti persi da un servizio in una rete reale è di solito compreso tra 0-15%. Con questo approccio sono state costruite diverse categorie di severità.
Website www.antoniodimaio.com | Email [email protected] | Skype dimaio_antonio
» Prestazione Server» Reportistica » Azioni di Syslog» Azioni Scrivi in File
» RealTime» Monitoraggio GPS» Monitoraggio Antenna» Monitoraggio Satelliti
» Trap Testing» Filtraggio Trap» Soglie SNMP» SNMP Dashboard
» SNMP Tuning» Selezione Oggetti» Verifica MIB» Analisi MIB
Giorno 4
Monitoraggio tramite SNMP
Utilizzando le variabili SNMP e gli oggetti MIB (MIB standard e MIB enterprise fornite dal ven-dor) è possibile configurare un buon numero di allarmi.
Il server LANTIME è compatibile con il protocol-lo SNMP e parte degli oggetti disponibili sono stati utilizzati per l’impostazione passiva di al-cuni controlli per il monitoraggio di parametri vitali quali: la sincronizzazione dell’antenna, lo stato dell’antenna (Antenna Faulty), lo stato della sorgente di riferimento e il numero corren-te di satelliti visibili (vedi descrizione GPS nella parte introduttiva).
Anche per SNMP, è stato effettuato uno studio approfondito sul sistema e sulle problematiche GPS con lo scopo di individuare i principali pa-rametri/metriche da prendere in carico nel siste-ma. Sono stati configurati anche cruscotti che in tempo reale mostrano l’andamento di alcune di queste grandezze, dati che vengono conser-vati da NetCrunch permettendo così la creazio-ne di statistiche per l’analisi a lungo termine.
Principali Attività - Giorno 4
Allarmi SNMP
>> OBJECT >> EVENT >> AC-TION
mbgLtRefGpsSta-teVal
Reference Clock is in a bad state
Write to event log
mbgLtNtpCur-rentStateVal
NTP is not synchro-nized to a reference time source
Write to event log
mbgGPSTrapMa-sterclockSwitcho-ver
Antenna Faulty Write to event log
mbgGPSTrapMa-sterclockSwitcho-ver
Master Clock Switcho-ver
Write to event log
mbgLtTrapN-TPStopped
NTP Daemon is not running
Write to event log
mbgLtRefGpsSa-tellitesGood
Num of satellites in good < 5
Write to event log
Website www.antoniodimaio.com | Email [email protected] | Skype dimaio_antonio
» Gestore Ricevitore Eventi » Politica Syslog» Esporta Eventi» Regression Testing
» Eventi Syslog» Power Supply 1» Power Supply 2» Eventi Antenna
» Messaggio Syslog» Syslog Server» Filtri Syslog» Syslog Testing
Giorno 5
Monitoraggio tramite Syslog
Il Time server è anche compatibile con Syslog. La necessità di implementare alcuni controlli con syslog è scaturita dall’esigenza di distinguere gli eventi generati dalle due antenne e dalle due alimentazioni (le trappole dell’M300/GPS non forniscono questo livello di dettaglio, almeno per il modello a nostra disposizione).
Il Time Server è ovviamente equipaggiato con elementi ridondanti, e le specifiche di monitoraggio fornite dal cliente richiedevano di configurare allarmi opportuni per singolo elemento. Questo è stato possibile grazie alla configurazione di eventi che effettuano il parsing del messaggio di syslog. Ad esempio, si è configurato un evento “PSU2 disconnected” effettuando il parsing sulla sotto-stringa “Supply 2” contenuta nel messaggio di syslog.Nel gruppo di azioni lanciate al verificarsi di un evento è stata prevista la scrittura in un file di log su disco in un formato concordato con il cliente.
Al termine della configurazione è stata effettuata una presentazione/revisione con il personale locale, che ha confermato la correttezza dell’implementazione effettuata.
Principali Attività - Giorno 5
NetCrunch Syslog Alarms
>> OBJECT >> EVENT >> ACTION
PSU 1 Supply 1 disconnected WTL
PSU 1 Supply 1 connected WTL
PSU 1 Power Supply 1 failure WTL
Antenna 2Antenna 2 disconnec-ted
WTL
Antenna 2 Antenna 2 reconnected WTL
Antenna 1 Antenna 1 reconnected WTL
Antenna 1Antenna 1 disconnec-ted
WTL
Antenna 2 Antenna 2 faulty WTL
Antenna 1 Antenna 1 faulty WTL
GPS Receiver GPS sync WTL
GPS Receiver GPS not sync WTL
PSU 2 Power Supply 2 failure WTL
PSU 2 Supply 2 connected WTL
PSU 2 Supply 2 disconnected WTL
WTL = Write to event log + Write To File
Website www.antoniodimaio.com | Email [email protected] | Skype dimaio_antonio
Risorse
1. Wikipedia 2. AdRem Sofware3. Meinberg4. Sito Airport Technology5. Understanding the GPS Gregory T. French