NET/SYS/APP monitoring in un medio Ateneo Italiano (nel 2019)

Le problematiche tecniche che insorgono nel corso delle normali attività di gestione di una infrastruttura di rete estesa –quale quella di un medio Ateneo Italiano--, non rappresentano una particolare novità: l'analisi near-real-time del regolare funzionamento dell'infrastruttura è ormai resa possibile da una molteplicità di strumenti software in grado anche di supportare agevolmente i successivi processi di gestione degli incidenti (allarmistica e trouble-ticketing). Lo scenario cambia nel momento in cui allarghiamo l'angolo di visuale: se la detection di un fault e del relativo disservizio è banale tanto quanto un PING oppure una richiesta cURL/WGET, misurare la “Qualità” della propria infrastruttura wireless –così come percepita dai propri utenti-- è decisamente più complesso. Ed è altrettanto complesso “osservare” il comportamento delle macro-componenti applicative (Firewalling, Posta Elettronica, Servizi WEB, Traffico Ethernet/IP solo per fare qualche esempio) con il triplice obiettivo di: 1) individuare quelle problematiche che, pur presenti, non generano disservizi; 2) aumentare il livello di security garantito dalla propria infrastruttura; 3) supportare adeguatamente i processi evolutivi dell’infrastruttura, a medio/lungo termine. Nei campi di battaglia degli uffici “Reti e Sistemi” di moltissimi Atenei si combatte quotidianamente fra utenti che lamentano mancata connettività (salvo poi scoprire che il proprio client fa 10 richieste DHCP-DISCOVER al secondo; oppure è (mis)configurato con i DNS non ufficiali), scarse prestazioni wireless (salvo scoprire che stanno utilizzando un SSID non ufficiale), impossibilità di telefonare (salvo poi scoprire che –courtesy del servizio di pulizia-- l’interfaccia dello switch a cui è connesso il telefono è andata DOWN alle 19:30 della sera precedente). Storage, potenza di calcolo e capacità trasmissiva sono ampiamente accessibili e non rappresentano più un problema economico. È quindi certamente possibile ipotizzare l’implementazione di strumenti di telemetria in grado di raccogliere una notevole mole di dati relativi all’”utilizzo” delle varie componenti infrastrutturali (hardware e software) per poi archiviarli e processarli –anche in modo “distribuito”–, adeguatamente. Elemento trasversale e, soprattutto, fondamentale rispetto a tale attività è il software: un PING non è più sufficiente, così come una chiamata SNMP oppure un DB RRD. Servono strumenti “nuovi”. Meglio: serve un nuovo approccio. Un approccio che nella maggior parte dei casi, il singolo Ateneo non è in grado di perseguire autonomamente. Di questi aspetti e dell’effettiva necessità di questo nuovo approccio si discuterà nel corso della presentazione.

NET/SYS/APP monitoring in a Campus Network (on 2019) Biografia IT:

Technical issues encountered during day-by-day operations of a Campus Network are not big news: a wide set of software suites are available, providing an effective "near-real-time" picture of the status as well as supporting related incident management (notifications/alarming and trouble-ticketing) Things gets a bit trickier if we need a larger overview: while checking the availability of simple services can be easily achieved by simple tools (PING, cURL/WGET, etc.), to properly observe the current "Quality level" of complex infrastructures a more complex approach is required. The whole wireless infrastructure, the firewalling service, the whole e-mail infrastructure, web services and, in general, the routing and forwarding of Ethernet/IP network traffic (just to name a few) need to be "monitored" in order to: 1) detect anomalies that might exist, but are not disruptive of the whole service; 2) increase the "security level" offered by the infrastructure; 3) provide key-data to top/middle management to better define an evolution strategy. System and network departments are fighting on a daily basis with end-users complaining about connectivity issues (and discovering, afterwards, that related notebook is firing tens DHCP-DISCOVER requests per second; or that such notebook have been configured to point to unofficial DNS), users complaining about poor performance of wireless connection (and later discovering that they are NOT associated to official SSID), users complaining about VOIP service disruption (and later discovering that someone mistakenly unplugged the ethernet cable from the wall socket --generally, courtesy of the cleaning service--). Nowaday storage, computing power and network bandwidth are widely available and relatively cheap. Thanks to this, the implementation of a telemetry system being able to collect massive amount of data to be further processed searching for "hidden" elements, is definitely feasible. "Software" is a key factor for the succesfullness of such an approach. Employing simple/standard tools is not enough. A new set of software need to be developed, designed and built around the specific needs of each organization. Unfortunately this is a complex task, not being able to be fulfilled by single university, alone. How to step further?