L’integrazione di PRTG con l’API di IP Fabric è un altro ottimo esempio di sintesi funzionale. Gli strumenti di monitoraggio della rete sono fondamentali nella gestione della rete stessa. Per alcuni può significare semplicemente testare le risorse con il protocollo ICMP, o raccogliere statistiche d’interfaccia e CPU tramite SNMP, ma per molti ingegneri di rete questo non è sufficiente.
Per essere in grado di costruire correttamente gli ecosistemi di monitoraggio, bisogna avere una comprensione completa e dettagliata delle tecnologie implementate e dei Vendor, oltre a comprendere i servizi che girano nel sistema.
Qualsiasi statistica di performance o telemetria dipende dalla fonte dei dati, più dati abbiamo a disposizione, più opzioni e approfondimenti possiamo fornire.
In questo articolo esporremo il concetto alla base della condivisione dei dati tra la piattaforma IP Fabric e PRTG Network Monitor (Paessler Router Traffic Grapher fino alla versione 7).
La forza di IP Fabric è che tutti i dati sono disponibili tramite API (sì, anche la simulazione del percorso end-to-end dell’applicazione). E la forza di PRTG è che, oltre a essere un basilare strumento di monitoraggio, può leggere tante tipologie di dati, comprese le risposte API JSON. Questo è esattamente ciò che cercheremo di ottenere.
In PRTG, creeremo una serie di nuovi sensori REST, che leggeranno i dati dall’API di IP Fabric. I sensori includeranno il numero di dispositivi scoperti, il numero di indirizzi IP rilevati tramite il protocollo ARP, o fonti NTP non raggiungibili rilevate da IP Fabric. Tutto in uno snapshot aggiornatissimo.
Creare i nuovi sensori Custom REST su PRTG per iniziare l’integrazione
Prima di iniziare a creare qualsiasi nuovo sensore in PRTG, dobbiamo assicurarci di avere i seguenti requisiti:
- Server IP Fabric attivo con almeno 1 snapshot caricato;
- Utente con EULA confermato in IP Fabric;
- Istanza PRTG con connettività all’API REST di IPF;
La documentazione completa dei sensori PRTG Custom REST comprende tutto ciò di cui abbiamo bisogno per un’implementazione di successo. Ma prima, vediamo cosa vogliamo ottenere.
Sensore nr.1 – Monitoraggio del numero dei dispositivi rinvenuti
Con il primo sensore REST, monitoreremo il numero di dispositivi rilevati dall’ultimo snapshot. Ciò aiuterà a vedere la tendenza dopo ogni nuova discovery. La frequenza di lettura del sensore dovrebbe dipendere da quella dei vostri snapshot. Se state eseguendo uno snapshot completo ogni 12 ore, il sensore potrebbe leggere i dati ogni ora (per coprire eventuali snapshot manuali intermedi).
Vediamo quali parametri includere nel sensore per raccogliere i dati.
- Request method: POST
- Post data:
{
"columns":["id"],
"filters":{},
"pagination":{"limit":1,"start":0},
"snapshot":"$last",
"reports":"/inventory/devices"
}
- Request Protocol: HTTPS
- Authentication Method: Basic Authentication (username/password)
- Use custom HTTP headers:
Content-Type:application/json
- REST Query: /api/v1/tables/inventory/devices
Sensore nr.2 – Monitoraggio del numero di indirizzi IP trovati in tutte le tabelle ARP
Questo è solo un esempio di una raccolta casuale. L’integrazione PRTG con l’API di IP Fabric può realizzare qualsiasi cosa che ci venga in mente. Può essere un numero di indirizzi MAC rilevati per dispositivo e interfaccia selezionati o la quantità di rotte BGP sui route reflector. Lo scopo di IP Fabric, in questo caso, è raccogliere dati e rappresentare l’output in modo standardizzato.
Vediamo quali parametri dobbiamo includere nel sensore per raccogliere i dati ARP.
- Request method: POST
- Post data:
{
"columns":["id"],
"filters":{},
"pagination":{"limit":1,"start":0},
"snapshot":"$last",
"reports":"/technology/addressing/arp-table"
}
- Request Protocol: HTTPS
- Authentication Method: Basic Authentication (username/password)
- Use custom HTTP headers:
Content-Type:application/json
- REST Query: /api/v1/tables/addressing/arp
Il seguente grafico di dati live mostra una tendenza fra due snapshot nel tempo (da circa 7500 a 9399 indirizzi IP rilevati da tutte le tabelle ARP nella rete).
Sensore nr.3 – Monitoraggio della quantità di fonti NTP non raggiungibili e configurate
Per questo particolare sensore, useremo le intent verification rules di IP Fabric. La piattaforma è caricata con circa 100 regole di migliore prassi, immediatamente disponibili dopo la prima discovery. Possono essere personalizzate e altre possono essere progettate e create in GUI o tramite API.
Uno degli esempi è l’’NTP Stratum Level’, che rappresenta la gerarchia dei time server. Il valore “16” di Stratum significa che il dispositivo non è sincronizzato ed è facile rilevare questo problema con IP Fabric.
Vediamo quali parametri dobbiamo includere nel sensore, per raccogliere i risultati di verifica dell’intento NTP Stratum (la parte del filtro è molto importante).
- Request method: POST
- Post data:
{
"columns":["id"],
"filters":{"stratum":["color","eq","30"]},
"pagination":{"limit":1,"start":0},
"snapshot":"$last",
"reports":"/technology/management/ntp/sources"
}
- Request Protocol: HTTPS
- Authentication Method: Basic Authentication (username/password)
- Use custom HTTP headers:
Content-Type:application/json
- REST Query: /api/v1/tables/management/ntp/sources
La seguente tabella di dati live mostra una tendenza fra due snapshot nel tempo (da 53 a 62 fonti NTP non sincronizzate rilevate).
Guardate questo video!
Continuate a visitare ipfabric.io e seguite IP Fabric su LinkedIn per ulteriori informazioni!
