Release Notes NetEye 3.6 e RUE 1.9

NetEye Release Notes 2015 – Versione 3.6
hf
ke
Log
Management
Event
Management
Reporting
End User
Experience
ab c
dg
Application Performance Monitoring
Discovery
Asset
Management
IT Orchestration
ij
lm
Network Performance Monitoring
Service Level
Management
n
Wiki
Real User Experience
System & Storage
Monitoring
Business Service
Monitoring
Questo documento è stato redatto per fornire una panoramica sulle nuove funzionalità e miglioramenti rilasciati con la nuova
versione di NetEye 3.6.
Log Auditing ad un nuovo livello, ottimizzazione dei report
e miglior integrazione dei vari
moduli
La nuova versione di NetEye 3.6 è caratterizzata da una profonda strategia migliorativa. Gli intensi sviluppi hanno portato innovazioni sia per soddisfare le esigenze dei
clienti, sia per affrontare la sfida della crescente complessità del monitoraggio IT.
Le principali modifiche sono state implementate nel modulo di Reporting e nelle statistiche per gli SLA, standardizzando la struttura per l’archiviazione dei dati raccolti in un
unico database.
Grazie al continuo miglioramento e sviluppo
in base ai risultati ottenuti dai questionari annuali dei clienti, all’output degli User Groups
e alle tendenze della Community Open
Source, NetEye è ormai diventata una soluzione di “Unified Monitoring”, che può soddisfare le esigenze dei clienti legate alla gestione di ambienti sempre più complessi e a
supporto del business.
© Würth Phoenix GmbH
1.
Dal dato all’informazione: l’analisi dei log e la correlazione con gli eventi
nel nuovo Log Management
Oggi il Security Auditing sta ricoprendo un ruolo sempre più importante per le aziende. Una gestione dei
Log strutturata diventa quindi un bisogno essenziale sia per soddisfare le politiche sui dati aziendali e i
requisiti di conformità, sia per fornire informazioni significative per quanto riguarda la sicurezza della rete
aziendale.
Il Log Management di NetEye 3.6 consente di estrarre informazioni dettagliate dai log raccolti. Il contenuto
dei dati raccolti infatti viene indicizzato, classificato e archiviato in una struttura adatta per poter compiere
delle ricerche avanzate. In questo modo è possibile eseguire ricerche estremamente efficienti su un numero elevato di dati evidenziando un certo tipo di contenuto in un contesto specifico per poter trovare
facilmente informazioni pertinenti.
Il nuovo Log Management di NetEye 3.6 può quindi diventare il collettore centrale di tutti i dati raccolti,
come ad esempio errori di sistema, accessi, log di autenticazione ed eventi, per poterli poi filtrare, aggregare e quindi rappresentare graficamente. Questi grafici permettono il riconoscimento intuitivo delle relazioni, delle tendenze, delle anomalie e delle possibili vulnerabilità di sicurezza.
Con questo metodo è possibile implementare un Security Audit, da cui poter ottenere in modo evidente il
numero di tentativi di accesso falliti. In una panoramica più ampia, sarà invece possibile visualizzare gli
eventi e gli account di accesso per poter identificare gli utenti collegati agli accessi non andati a buon fine.
Drill Down degli Host, collegati a tentativi di accesso falliti.
Informazioni sugli utenti che hanno
causato i tentativi di accesso falliti.
Un altro esempio di applicazione pratica del Log Management può essere l’individuazione di attività di rete
indesiderate attraverso l’identificazione di picchi di anomalie.
© Würth Phoenix / 2015-12-16
System Integration
Page 2 of 9
Attraverso la rappresentazione di pacchetti difettosi non consegnati si possono invece rilevare problemi
collegati alla trasmissione dei dati.
Gli esempi forniti sopra vi offrono una panoramica di alcune possibilità di utilizzo del Log Management
rilasciato nell’ultima versione di NetEye 3.6.
Grazie all’integrazione di Elastic Stack (composto da Elasticsearch, Logstash e Kibana) l’organizzazione
di elevate moli di dati e la definizione di allarmi personalizzati diventa davvero facile. Le dimensioni dei
dati non rappresentano più alcuna limitazione.
NB: A causa dell’integrazione di Kibana 4, Internet Explorer 9 non è più supportato.
2.
Reporting più dettagliato: gestione dei dati di disponibilità per controllare
gli SLA
Se si vuole garantire un certo livello di qualità dei servizi IT critici per il business, il monitoraggio dei Service
Level Agreement (SLA) diventa inevitabile.
Con NetEye 3.6 vengono offerte nuove possibilità di gestire i dati di disponibilità dei servizi e sistemi. Gli
eventi di monitoraggio registrati, che sono essenziali per la valutazione della conformità con gli SLA predefiniti, possono essere controllati con precisione. Ora è possibile, che i dati rilevati si riferiscano all’effettiva percezione dell’utilizzatore del servizio. Per esempio, i down time pianificati possono essere identificati
all’interno del pannello di configurazione per poterli escludere dai rispettivi report sugli SLA. Questa modifica è utile quando un disservizio non è stato causato dal fornitore e, quindi, non può incidere sul relativo
SLA. Un’ulteriore correzione può essere eseguita anche per il monitoraggio degli eventi per sostenere in
questo modo l’esattezza della conformità con gli SLA.
© Würth Phoenix / 2015-12-16
System Integration
Page 3 of 9
Questa funzionalità è garantita anche nel caso di generazione di report automatici, in cui si può decidere
se le modifiche apportate debbano essere considerate o meno.
3.
Ottimizzazione delle integrazioni: lo scambio dei dati tra i vari moduli
L’integrazione tra i vari moduli e lo scambio dei dati all’interno di NetEye sono particolarmente importanti
per una gestione più affidabile degli asset aziendali.
Dopo gli ultimi miglioramenti introdotti in NetEye 3.6 i dati raccolti attraverso il Network Discovery possono
essere completamente trasferiti all’Asset Management. In questo modo tutti i dispositivi possono essere
collegati con i rispettivi contratti di manutenzione e supporto. Insieme ai dispositivi di rete stessi, potranno
inoltre essere mappati nell’Asset Management anche i vari componenti e lo stato del loro utilizzo.
Le informazioni rilevate dal Network Discovery ed i dati salvati nell’Asset Management potranno essere
utilizzati per la definizione dei controlli. Oltre alla gestione di computer, dispositivi di rete, server e stampanti, si può gestire l’intero ciclo di vita anche di altri dispositivi come ad esempio gli smartphone.
L’Asset Management diventa quindi il punto centrale per la gestione di tutti i dispositivi e dei vari componenti. Il collegamento con gli account degli utenti dell’Active Directory permette inoltre la mappatura di una
struttura organizzativa e la divulgazione di tali informazioni anche al Service Desk.
4.
End User Experience: monitoraggio continuo delle prestazioni delle applicazioni dal punto di vista dell'utente finale
Per facilitare l'individuazione delle prestazioni e garantire l'affidabilità delle applicazioni business-critical
come Citrix, SAP, terminal server terminal, ecc. sono stati apportati i seguenti miglioramenti:
•
•
•
•
•
•
•
•
Creazione intuitiva e guidata di scenari di test direttamente dall'interfaccia utente (nessuna
conoscenza Python è richiesta)
Più sicurezza attraverso la crittazione delle password nei test case
Implementazione in due semplici passaggi
Miglioramento degli algoritmi di visione artificiale per il rilevamento più affidabile degli oggetti applicativi
Creazione automatica di report HTML, tra cui schermate dell'applicazione in fase di test per
supportare le attività di troubleshooting
API per lo sviluppo di nuovi plugin
Minor utilizzo della CPU
Log Retention configurabili singolarmente
© Würth Phoenix / 2015-12-16
System Integration
Page 4 of 9
Alyvix, il motore per il monitoraggio delle prestazioni dal punto di vista dell'utente, simula continuamente
una particolare sequenza di transazioni per testare le applicazioni (come farebbe un utente reale). In questo modo deviazioni dal corretto funzionamento possono essere immediatamente rilevate e corrette.
5.
Real User Experience: rilascio della nuova versione RUE 1.9
L’unione dell’Application Performance Monitoring (APM) e Network Performance Monitoring (NPM)
ad un Application Aware Network Performance Monitoring (ANPM) fornisce una panoramica reale
sulle prestazioni di una rete aziendale. Per l’attualità del tema e l’impatto diretto sul successo aziendale,
nell’ultima versione della Real User Experience di NetEye, RUE 1.9, sono state implementate le seguenti
funzionalità.

Mappatura delle modifiche alla baseline
I cambiamenti dei valori della baseline sono contrassegnati con una linea corrispondente sulla timeline
nella dashboard. Con un tooltip vengono visualizzate a colpo d’occhio le informazioni di modifica più importanti.

Definizione individuale dei periodi a confronto
Per tracciare lo sviluppo delle prestazioni attraverso periodi di tempo più lunghi e per mappare le modifiche
alle prestazioni è necessario che i valori rilevati nei due diversi periodi temporali vengano visualizzati contemporaneamente sullo stesso grafico. Per rendere possibile questo confronto più esteso la RUE 1.9 offre
la possibilità di definire in base alle proprie esigenze due diversi periodi di paragone.
© Würth Phoenix / 2015-12-16
System Integration
Page 5 of 9

Analisi più mirate attraverso la definizione di singoli filtri
Nella RUE gli indicatori prestazionali (KPI) sono calcolati dai dati raccolti. Questi indicatori possono essere
aggregati per ricavare dai dati raccolti delle informazioni significative. L'ulteriore utilizzo di singoli filtri,
consente una classificazione mirata, per poter trovare informazioni reali riguardo le prestazioni di rete e
delle applicazioni.
Nella RUE 1.9 tutti i campi disponibili possono essere usati per creare dei filtri individuali (vedi
RUE_KPI.pdf).

Nuovi KPI
Sono stati aggiunti due nuovi KPI:
- Explicit Congestion Notification
- Inflight Byte

Nuovo pannello di configurazione per la sonda di rete di ntop
Per un’analisi di quei dati, che ad esempio possono essere protetti da un certificato SSL, si deve decifrare
il traffico di rete. Questa attività viene svolta dalla sonda di rete (nBox di ntop) attraverso l’utilizzo delle
chiavi private dei certificati, che possono essere facilmente caricate nel nuovo pannello di configurazione.

Convalida e ripristino delle configurazioni precedenti
Un cambiamento delle configurazioni di monitoraggio influenza le metriche delle prestazioni, perciò le
modifiche a tali configurazioni sono rilevanti per una corretta valutazione delle prestazioni. Ad esempio,
se dal monitoraggio del throughput vengono escluse due sottoreti, anche i valori rilevati sulle prestazioni
di rete cambiano. Nella RUE 1.9 ogni nuova configurazione viene convalidata prima del suo impiego. In
questo modo si possono visualizzare gli errori di configurazione, che possono essere corretti dall’utente.
Attraverso il frontend si può eventualmente ripristinare l’ultima configurazione valida.
© Würth Phoenix / 2015-12-16
System Integration
Page 6 of 9

Prime funzionalità di Machine Learning
Come descritto nel white paper di Würth Phoenix „Statistics and Machine Learning Techniques for Real
User Experience“, la Real User Experience verrà estesa integrando metodi di analisi nel campo di machine
learning (apprendimento automatico) e statistica avanzata. La versione 1.9 contiene già i primi metodi di
visualizzazione, i quali forniscono una panoramica generale ed astratta delle performance della rete o
dell’applicazione. In questo modo è possibile riconoscere eventuali problemi nella fase iniziale. In dettaglio
si tratta della possibilità di generare due grafici completamente nuovi. I primi sono una serie di density
plots, i quali visualizzano la distribuzione della densità media delle richieste nello spazio multidimensionale
(latency vs. throughput), come media del giorno. I secondi, i performance trends, riportano gli andamenti
delle prestazioni con cambiamenti temporanei del traffico.

Density Plots
Nel campo di network e application traffic monitoring, in certe situazioni può risultare svantaggioso caratterizzare i dati esclusivamente tramite il loro valore medio, perché in questo modo le informazioni riguardanti la vera distribuzione dei dati vengono perse.
Density plots di un giorno: 92% è traffico denso standard (grafico sinistro in verde), 8% è traffico sparso (grafico destro in rosso).
È molto probabile trovare request con una application latency di ca. 90 ms ed un throughput di 150 kB/s, alternativamente request
con una application latency di 10 ms ed un thorughput di ca. 400 kB/s sono probabili. La distribuzione di probabilità della application latency ha due massimi. Esistono anche request con valori molto più estremi riguardanti il throughput e la application
latency. Questi valori estremi rappresentano però solo il 8% del traffico totale.
Oltre a baseline per “warnings” e “criticals” che si basano sulla media del traffico registrato, nella RUE 1.9
sono a disposizione anche i density plots. L’intero traffico giornaliero viene anzitutto diviso in traffico standard (verde) e traffico sparso (rosso). Ognuna delle tre latenze (application latency, server latency, client
latency) viene visualizzata rispetto al throughput per entrambi i tipi di traffico (denso, sparso). Da questi
grafici si possono individuare i valori che erano più probabili durante il giorno d’interesse e quale era la
percentuale di traffico standard.
© Würth Phoenix / 2015-12-16
System Integration
Page 7 of 9

Performance Trends
Questo strumento permette la visualizzazione di high-level performance trends (PT), i quali possono essere applicati sia per l’application performance monitoring sia per il network performance monitoring. Il PT
riporta i dati raccolti ad un certo livello di astrazione per ottenere una migliore panoramica sulle prestazioni
e per pianificare drill down mirati.
Affiancando i grafici PT è possibile confrontare le prestazioni di reti o applicazioni diverse dello stesso
periodo.
L’interpretazione dei grafici è intuitiva. Le tonalità verdi corrispondono ad una bassa frequenza di query,
le tonalità gialle invece ad un’elevata qualità di frequenza. Aree larghe e strisce verticali segnalano traffico
costante nel tempo. Se il traffico tende ad interrompersi appaiono aree piccole dello stesso colore, come
anche punti ed aree isolate. Zone scure (grigio) segnalano periodi nei quali non sono a disposizione abbastanza dati.
Performance Trends; Durante il giorno in analisi, il traffico è approssimativamente costante (application latency: 42 ms, server
latency 22 ms, client latency 22ms, thourghput < 25 kB/s). In aggiunta ai valori frequenti, per tutte le latenze si notano valori
prossimi a 0 ms. Nel caso della client latency coesiste traffico di ca. 10 ms. Si tratta però di meno request di quelli che sono
intorno ai 22 ms. Di un breve periodo non esistono dati, questa area è stata sovrapposta con grigio.
© Würth Phoenix / 2015-12-16
System Integration
Page 8 of 9
6.
Aggiornamento di NetEye 3.6 Log Management
Per l’aggiornamento del Log Management di NetEye 3.6 vengono fatte le seguenti considerazioni sui requisiti hardware:

Nei sistemi SBS il registro precedente di archiviazione con il Log Management NetEye e rsyslog sono
ancora supportati. L'estensione di Elasticsearch e Kibana però non può essere garantita.

Per l'installazione di Elasticsearch e Kibana si devono garantire i seguenti requisiti minimi per l’hardware:
 CPU Quad-Core
 RAM 12 GB
 Disk 500 GB
© Würth Phoenix / 2015-12-16
System Integration
Page 9 of 9