Determinare in modo automatico la disponibilità di banda internet del computer.
Internet nell’ultimo decennio è diventata sempre più un elemento imprescindibile del quotidiano, la quasi totalità delle azioni che svolgiamo è legata alla disponibilità di un collegamento, che deve essere in grado di sostenere il fabbisogno dei servizi impiegati.
Possiamo immaginare che il sapere che ogni singolo servizio è in grado di funzionare con la capacità di connettività di cui disponiamo è limitativo, dobbiamo pensare che la necessità globale è legata alla somma degli accessi contemporanei di ogni servizio usato sul dispositivo e che deve essere considerata la sommatoria degli assorbimenti contemporanei di ogni singolo dispositivo della nostra rete.
Da questa situazione deriva il fatto che nel corso della giornata possono palesarsi delle situazioni di traffico che portano a considerevoli rallentamenti o peggio al blocco delle comunicazioni verso alcuni servizi.
Per poter valutare in tempo reale, o quasi, se la capacità di banda disponibile è sufficiente per garantire i servizi di navigazione dell’ufficio, abbiamo realizzato una versione di base di uno script Powershell in grado di svolgere una valutazione partendo da diversi computer e di salvare un file in formato CSV con i valori rilevati di upload e download.
Con gli opportuni adattamenti è diventato uno strumento per mandare temporaneamente in pausa i backup BCDR, al fine di garantire la navigazione da/verso internet necessaria per il lavoro.
Tabella dei Contenuti
La determinazione della banda
La realizzazione di una procedura in grado di determinare la capacità di banda disponibile necessita di uno strumento di misurazione, esistono diverse soluzioni, molte fortemente spinte nel mondo dell’automazione, ma che nel corso di diversi test hanno evidenziato delle limitazioni. Alcune appaiono perfette, ma poi si scopre che possono determinare solo la banda sulla rete locale, altre si appoggiano a server esterni che hanno capacità di connettività inferiori a quelle di cui si intende fare il monitoraggio.
Nel nostro caso la scelta è caduta in modo specifico sul componente Speedtest CLI di Ookla, che offre la possibilità di specificare un carrier di destinazione o di lasciare al componente la possibilità di selezionarlo.
Il file eseguibile per Microsoft Windows è completamente autonomo e quindi portabile senza necessità di installazioni specifiche, deve essere solo copiato in un percorso a scelta e quando non serve più basta cancellarlo.
Il contro della scelta, del tutto tollerabile, è che per eseguire la CLI è necessario accettare le condizioni di utilizzo e la policy sul trattamento dei dati, questi due passaggi sono legati al fatto che l’esecuzione del test non deve essere abusato e che i dati di connettività misurati vengono inviati al cloud di Ookla per la generazione di statistiche globali.
Prima di usare questo elemento e di conseguenza la procedura di cui andremo a parlare è importante leggere attentamente le policy di Ookla sull’utilizzo.
La nostra scelta di implementazione
Le procedure che abbiamo realizzato per l’esecuzione via RMM sono tali da verificare la presenza della CLI e di posizionare il file se mancante, in questa fase vengono eseguiti anche i passaggi necessari per la registrazione e l’accettazione delle policy. La distribuzione del file CLI è eseguita da un componente autonomo; pertanto, può essere effettuata preventivamente a mano.
Per non eccedere accidentalmente nell’esecuzione dei test, abbiamo implementato un controllo che inibisce l’esecuzione della CLI ad intervalli inferiori ai 30 minuti. L’esecuzione deve inoltre essere limitata ad uno o due computer per rete, in particolare quelli che necessitano della maggiore disponibilità di connettività o che sono causa della congestione di traffico, così da mettere in pausa i servizi con maggior consumo e che non hanno impatto diretto sulla produttività.
La frequenza di esecuzione non può essere troppo alta, infatti la misurazione determina la generazione di traffico e quindi un impatto sulla banda disponibile, anche per questa ragione abbiamo scelto di non andare oltre una misurazione ogni trenta minuti.
Il monitor di misurazione e allarme
La procedura base che abbiamo realizzato è un monitor, quindi uno script eseguito ad intervalli regolari da un RMM o dallo schedulatore del sistema operativo. Nel caso di esecuzione diretta nel sistema operativo la generazione di allarmi centralizzati non è gestita e comunque da sviluppare in base alle soluzioni locali disponibili.
Un file CSV di raccolta dei dati.
Il nostro sistema RMM è Datto, pertanto lo script è concepito per integrarsi con il suo sistema di gestione di allarmi, ma può essere facilmente adeguato ad altre soluzioni ed implementazioni. Con piccole modifiche può essere trasformato in un componente da far eseguire come job in orari specifici della giornata.
Per tarare il monitor abbiamo pensato di inserire la possibilità di specificare su quale server target indirizzare il test, il valore minimo di banda in upload e download attesi e la scelta se creare il file CSV. Il file CSV è alimentato in append, quindi crea uno storico con i valori a distanze temporali corrispondenti a quelle di esecuzione del monitor e non minori di trenta minuti.
L’esecuzione del monitor richiede due moduli da noi realizzati:
- EPFunctionDRMM – Specifico per la gestione degli allarmi in Datto RMM;
- EPFunctionString – Specifico per l’estrapolazione dei campi di interesse dal output della CLI, in un precedente articolo abbiamo descritto la funzione necessaria per questa analisi.
Il controllo di non superamento della frequenza di esecuzione del test sfrutta un folder come semaforo, all’interno del quale è salvato anche il file CSV, se richiesto. Il monitor controlla la data di creazione del folder, che deve essere minimo più vecchia di trenta minuti, se questo accade viene modificata la data di creazione del folder a quella di esecuzione del test. Il metodo di cambiamento della data di file e cartelle è stato presentato in un precedente articolo.
I parametri e i componenti del monitor
L’esecuzione della procedura necessita dei parametri di configurazione e del loro inserimento nel modo corretto e dell’eseguibile della CLI di SpeedTest. La prima parte della procedura è dedicata a queste operazioni.
$BandThreshold = $ENV:BandThreshold # Download:Upload
$Target = $ENV:Target # Numero identificativo del target
$CreateCsv = $ENV:CreateCSV # true o false
Utilizzando Datto RMM acquisiamo i parametri con questo tipo di sintassi, ogni RMM dispone di una propria sintassi per far recepire agli script le impostazioni inserite nella fase di inserimento. Nel caso di esecuzione diretta dallo schedulatore del sistema operativo possono essere inseriti direttamente i valori nello script o modificata la sezione per recepire i parametri direttamente in riga di comando. I valori inseriti sono da considerarsi stringhe e pertanto se compilati nello script devono essere racchiusi tra doppi apici.
$PathSpeed = "C:\TempAEM\SCRIPT\speedtest.exe"
if (!(Test-Path $PathSpeed)) {
Set-DRMMError -FErrorMessage "WARNING - File speedtest.exe not available." -FDiagnostic "WARNING - File speedtest.exe not available."
}
Per eseguire la procedura di misurazione è necessario l’eseguibile della CLI di SpeedTest, la nostra scelta è stata quella di generare un allarme se il file è assente e di far eseguire lo script di installazione come remediation.
La Riga 1 specifica il percorso dell’eseguibile, noi posizioniamo tutti gli elementi legati alle operazioni del RMM in un percorso specifico, questo nel caso di dismissione totale rende possibile la pulizia del sistema semplicemente cancellando il folder di raccolta. Le Righe 2-4 verificano l’esistenza del file e alla Riga 3 viene richiamata la funzione custom che genera la sezione di script necessaria ad innescare gli allarmi in Datto RMM.
$BandThreshold = $BandThreshold.split(":")
if (!($BandThreshold['0'] -match "^\d+$") -or !($BandThreshold['1'] -match "^\d+$")) {
Set-DRMMError -FErrorMessage "ERROR - The BANDTHRESHOLD parameter is not filled in correctly (es. 10)." -FDiagnostic $BandThreshold
}
if ($Target -notin "7898","3243","46902") {
Set-DRMMError -FErrorMessage "ERROR - The TARGET parameter is not filled in correctly." -FDiagnostic $Target
}
if ($CreateCsv -notin "true","false") {
Set-DRMMError -FErrorMessage "ERROR - The CREATECSV parameter is not filled in correctly." -FDiagnostic $CreateCsv
}
Fondamentale è la correttezza dei parametri inseriti, la sezione di verifica è probabilmente la parte più importante di tutta la procedura.
La Riga 1 disassembla le soglie minime di banda disponibile, i valori per il download e l’upload sono stati inseriti in un’unica stringa e separati da due punti, l’istruzione esegue uno split usando come separatore i due punti e ottenendo un array con in posizione zero la velocità di download ed in posizione uno la velocità di upload.
Elenco dei server target in prossimità dalla fonte del test.
Le Righe 2-4 verificano che i due valori assegnati per le soglie di banda siano dei numeri, in caso contrario attiva un allarme di errore di compilazione del campo.
Le Righe 5-7 controllano che il valore inserito per il Target del test sia presente nella lista specificata, in caso contrario attiva un allarme di errore di compilazione del campo. La lista dei server è determinata su base geografica, è pertanto opportuno configurare i codici relativi alla zona in cui si fa operare la procedura, per determinare i server di zona è sufficiente eseguire da una shell DOS il comando “speedtest.exe -L”.
Le Righe 8-10 verificano che il valore inserito per la creazione del file CSV sia coerente con quanto specificato nella lista.
Controllo dei semafori e dei tempi
È fondamentale che lo script disponga del folder di riferimento per il controllo della frequenza di esecuzione e del salvataggio dell’eventuale file CSV. Questa sezione del codice si occupa di eseguire questi controlli e le relative azioni.
$PathLog = "C:\TempAEM\Bandwidth"
if (Test-Path $PathLog) {
$LastRun = (get-item -path $PathLog).CreationTime
if (((Get-Date) - $LastRun).TotalMinutes -lt 29) {
exit 0
}
(Get-Item $PathLog).CreationTime=(Get-Date)
}
else {
New-Item -Path $PathLog -ItemType "Directory" -Force -Confirm:$false
}
La Riga 1 definisce il percorso utilizzato come semaforo e come contenitore del file CSV generato. La condizione della Riga 2 controlla se il percorso esiste ed in caso contrario lo crea con la condizione delle Righe 9-11.
Quando il file esiste, alla Riga 3 determina la data e ora di creazione del folder, per poi sottrarlo nella condizione della Riga 4 alla data di esecuzione, determinando la differenza in minuti. Se la differenza è minore di 29 la procedura viene conclusa con la exit della Riga 5. La scelta del valore 29 e non 30, come ci si aspetterebbe, è fatta per evitare che per questioni di secondi un monitor con cadenza di trenta minuti possa non dare risultati in quanto il tempo calcolato rispetto alla lettura precedente è più basso.
La Riga 7 forza il cambio della data di creazione della cartella, come specificato in un precedente articolo.
Calcolo della banda disponibile e creazione del output
Superati tutti i controlli e verificato che non sia stato eseguito un controllo nei trena minuti precedenti, è arrivato il momento di eseguire il test per determinare quanta banda di navigazione appare disponibile per il computer su cui è in esecuzione il monitor.
$SpeedTest = (C:\TempAEM\SCRIPT\speedtest.exe -p no -P 0 -s $Target)
$UploadString = (Search-String -FBuffer $SpeedTest -FPattern "Upload:" -FBefore 0 -FAfter 0)['0']
$ValueUpload = $UploadString.Line.Split(":")['1'].split("M")['0'].Trim()
$DownloadString = (Search-String -FBuffer $SpeedTest -FPattern "Download:" -FBefore 0 -FAfter 0)['0']
$ValueDownload = $DownloadString.Line.Split(":")['1'].split("M")['0'].Trim()
La Riga 1 esegue la CLI di speedtest senza la barra di progressione (-p no) e con una precisione a zero decimali (-P 0), raccoglie sono l’intero in mega dei valori misurati in upload e download, utilizzando come target di destinazione quello specificato nei parametri (-s $Target).
La Riga 2 estrae la stringa relativa alle informazioni di upload, utilizzando il cmdlet Search-String descritto in un precedente articolo, e recuperando solo il dato del array relativo al valore trovato. La Riga 3 con un concatenamento di split e trim ricava dalla stringa ottenuta nell’istruzione precedente il valore in mega della velocità di upload.
La Riga 4 estrae la stringa relativa alle informazioni di download, utilizzando il cmdlet Search-String descritto in un precedente articolo, e recuperando solo il dato del array relativo al valore trovato. La Riga 5 con un concatenamento di split e trim ricava dalla stringa ottenuta nell’istruzione precedente il valore in mega della velocità di download.
Creazione del file csv
I due valori richiesti sono ora disponibili ed è quindi possibile procedere con la creazione del file csv nel percorso precedentemente definito. Il file viene creato alla prima richiesta di salvataggio dei dati, nelle successive interazioni è eseguito un append dei nuovi valori ottenuti; pertanto, se si intende azzerare il file è necessario eseguire uno script specifico per la cancellazione di file e directory, oppure aggiungere al monitor una funzione di cancellazione periodica del file.
if ($CreateCsv -eq "true") {
$Output = (Get-Date -Format "dd/MM/yyyy HH:mm") + ";" + $ValueDownload + ";" + $ValueUpload #+ "`r"
$PathLogFile = $PathLog + "\Bandwidth.csv"
Add-Content -path $PathLogFile -Value $Output
}
La Riga 1 verifica che sia stata richiesta la generazione del file csv con i contenuti, in caso contrario l’operazione viene saltata.
La Riga 2 crea la stringa che deve essere scritta nel file e che contiene i seguenti valori separati da punto e virgola:
- data e ora di esecuzione della lettura;
- valore in mega della capacità di download;
- valore in mega della capacità di upload.
La Riga 3 crea una variabile contenete il percorso di salvataggio del file e il nome del file, che è successivamente utilizzata nella Riga 4 per salvare i valori ottenuti utilizzando il cmdlet Add-Content.
Analisi delle misurazioni
La gestione dei dati e il loro trattamento è quanto rende un monitor uno strumento di segnalazione delle anomalie, l’obiettivo voluto da questo monitor è che generi un allarme nel caso in cui i valori di download e/o upload siano inferiori alla soglia indicata nei parametri.
$Upload = $false
$Download = $false
if ([int]$ValueUpload -lt [int]$BandThreshold['1']) {
$Upload = $true
}
if ([int]$ValueDownload -lt [int]$BandThreshold['0']) {
$Download = $True
}
if ($Download -or $Upload) {
Set-DRMMError -FErrorMessage "WARNING - Not enough bandwidth." -FDiagnostic "WARNING Not enough bandwidth (Down: $ValueDownload Mbps - UP: $ValueUpload Mbps)"
}
Le prime due righe forzano due variabili al valore false, questo stato indica alle condizioni successive che non ci sono dei superamenti delle soglie.
La prima condizione alla Riga 3, dopo aver forzato ad un formato di INT la variabile della soglia e del valore rilevato per il download, determina che la misurazione non sia inferiore alla soglia. Se la misurazione è inferiore alla soglia forza il valore della variabile semaforo di download a true. Analogamente la condizione della Riga 6 esegue i medesimi controlli, ma per i valori del upload.
La condizione alla Riga 9 determina se uno dei due semafori ha il valore true e di conseguenza genera lo stato di allarme per Datto RMM inviando un commento con i valori determinati dal test.
Conclusioni
In questa lunga trattazione abbiamo ottenuto un monitor che valuta la banda disponibile per la navigazione, determinata da uno specifico computer, questa misurazione non è in grado di fornire il valore esatto; infatti, la misurazione è influenzata dal funzionamento del computer dove si trova il monitor e dal target verso il quale viene indirizzata la misurazione.
Nonostante i limiti di errore variabili, si dispone di una valutazione in grado di far percepire se sussistono delle situazioni di congestione di traffico in particolari momenti della giornata, magari concomitanti con dei problemi nello svolgimento del lavoro verso portali esterni.
Il monitor opportunamente adattato può essere impiegato per diversi scopi, ad esempio sospendere un’operazione di trasferimento dati, non prioritaria, in attesa di un miglioramento delle condizioni di navigazione, pensando alla realizzazione di interventi di miglioramento delle prestazioni.
Per maggiori informazioni sull’uso e la realizzazione degli script di automazione leggi questo articolo e contattaci senza impegno.
I componenti distribuiti sono forniti senza alcuna garanzia. Non vi sono garanzie che il software soddisfi le vostre esigenze o sia esente da errori. In nessun caso gli sviluppatori saranno responsabili per eventuali danni.
I componenti proposti sono stati collaudati nel modo più esaustivo possibile e sono utilizzati in modo regolare in ambienti di produzione, durante il loro utilizzo non si sono verificate anomalie di funzionamento.
Articoli recenti
- ShellBag – un viaggio allucinante nei ricordi di Windows
- La donazione di sangue nei cani: importanza, modalità e compatibilità
- Il Manto del Cane: Un Viaggio alla Scoperta della Sua Pelle e del Suo Pelo
- Proteggi il tuo cane dal caldo: prevenzione e riconoscimento della disidratazione
- Monitoraggio e Verifica delle Configurazioni di Rete: Una Soluzione Efficace con PowerShell e Datto RMM
Archivi
Prossimi eventi
Iscriviti alla nostra Newsletter
Un progetto parallelo ambientato nella Tuscia Sutrina: piante da giardino locali, tecniche di coltivazione, storia e leggende del territorio, racconti fantasy a tema. Botanica, cultura e tradizioni in un unico spazio.
A volte basta una breve pausa per ritrovare la concentrazione: qualche minuto tra verde e fantasia può aiutare a tornare al lavoro con nuove idee.
Visita il sito