A seguito di una serie di problemi di scarsa connettività a banda larga che stavo riscontrando, ho deciso che volevo monitorare regolarmente la velocità Mbps che stavo ricevendo dal mio provider. Stavo vedendo cifre particolarmente scarse quando cercavo di scaricare file la sera, con velocità molto più elevate raggiunte molto presto al mattino.
Ho un server Debian Linux seduto in un angolo, che è la mia macchina di test e sviluppo per i siti Web ospitati da ISPConfig, così come del codice Let's Encrypt con cui mi piace giocare, quindi ho cercato del software che consentisse il test della larghezza di banda, eseguibile da una riga di comando di Linux, che potrebbe costituire la base di un sistema di script di shell automatizzato per produrre i dati grezzi di cui avevo bisogno. Volevo archiviare i dati in un database SQL per semplificare le query (potrei quindi raccogliere facilmente più dati ed estrarre semplicemente un sottoinsieme più piccolo per i periodi di tempo che mi interessavano) e avere un front-end web in grado di produrre un semplice grafico per visualizzare i dati e aiutare a evidenziare i problemi di connettività.
Il primo risultato della mia ricerca è stato l'utile articolo di Antonio Valencia su:https://www.howtoforge.com/tutorial/check-internet-speed-with-speedtest-cli-on-ubuntu/
Dopo aver seguito le istruzioni per installare speedtest, una rapida riproduzione ha mostrato che potevo usarlo per eseguire test su un'ampia serie di server Internet e anche produrre output in formato CSV, che è abbastanza adatto per essere importato direttamente in una tabella SQL con la quantità minima di impegno nello sviluppo del software.
Per la quantità relativamente piccola di dati che sarebbe stata generata, ho deciso di utilizzare SQLite come archivio di back-end e una rapida ricerca delle librerie grafiche basate su javascript open source mi ha portato a chart.js, che ha un design semplice e pulito con una semplice interfaccia dati ma molte possibilità di modificare le opzioni avanzate se necessario. La conversione dei dati SQL per estrarre solo il sottoinsieme di dati che volevo rappresentare graficamente con l'output tramite JSON tramite un codice PHP diretto era la strada da percorrere.
Quindi, nel complesso, avevo bisogno di progettare un sistema che assomigliasse a questo:
Un server Linux che esegue speedtest come cronjob - forse 1 all'ora - con l'output di speedtest archiviato in un database SQLite - il tutto controllato da un file di script della shell bash. Un front-end web, che è una combinazione di HTML, CSS, javascript e PHP per estrarre dati da SQLite e produrre un grafico a barre che mostra i valori di Mbps raggiunti per le 24 ore precedenti (o qualsiasi altro periodo su cui potrei decidere).
Un piccolo esperimento con l'esecuzione di speedtest una dozzina di volte in modo interattivo mi ha mostrato che c'erano alcuni server disponibili che sembravano fornire risultati strettamente in linea con il tipo di velocità che stavo riscontrando. Ho ritenuto una buona idea eseguire il test su più di un server per comprendere meglio in che modo le mie cifre di Mbps sono state influenzate dalla posizione del server di destinazione e dall'ora del giorno in un fuso orario diverso.
Se desideri seguire e configurare un sistema simile per te stesso, dovrai selezionare uno o più server tra le centinaia disponibili per lo speedtest da utilizzare in base alla tua posizione.
1 Prerequisiti
- un server linux - sto usando Debian 9.1 - stretch
- Accesso tty al server con login di root - Uso PuTTY da un laptop Windows
- ISPConfig installato e un sito web configurato anche con un account FTP - Sto usando 3.1.6 con apache impostato come server web (potresti gestire solo con un server web, con alcune piccole modifiche alle seguenti istruzioni)
- PHP - Sto usando 7.0 ma dovrebbe funzionare anche con la maggior parte delle versioni precedenti
- Client FTP - utilizzo Filezilla - e PureFTPd in esecuzione sul server
- nano - o il tuo editor visivo preferito
Presumo qui che tu sia a tuo agio con l'accesso a un server Linux, come aggirare le directory, il layout di dove il tuo server web si aspetta che i file siano e come inviare i file FTP a quelle directory.
Ecco i passaggi dettagliati per consentirti di impostare tutto questo.
2 Installa speedtest
Accedi al tuo server Linux come root ed esegui il comando:
# pip install speedtest-cli
Vedi https://www.howtoforge.com/tutorial/check-internet-speed-with-speedtest-cli-on-ubuntu/ e https://pypi.python.org/pypi/speedtest-cli per ulteriori informazioni se avere problemi.
Nota:speedtest e speedtest-cli sono identici sulla mia installazione, quindi mi limiterò a fare riferimento a speedtest in seguito.
3 Installa SQLite3
# apt-get install sqlite3
Usa l'equivalente per la tua distribuzione se apt-get non fa per te.
4 Crea larghezza di banda.sh
Inserisci il seguente codice dello script bash in un file e salvalo come /usr/local/etc/bandwidth.sh:lo modificheremo un po' più tardi per renderlo specifico per te.
#!/bin/bash# esegue speedtests su 3 server e salva tutti i risultati di output in un file CSV per l'importazione in sqlite db## eseguito da cronjob una volta all'ora##funzione getCSVString () { # se speedtest non è riuscito (ad es. impossibile accedere a un server) dobbiamo creare una voce zero fittizia per questo intervallo di tempo # ottenere una stringa timestamp nello stesso formato generato da speedtest - e abbiamo bisogno dell'ora UTC locale RIGHTNOW=$(date --utc +%Y- %m-%dT%H:%M:%SZ) # su quale server stiamo testando? if [ $1 ="5443" ] allora echo "5443,Fasthosts Internet,Gloucester,$RIGHTNOW,73.09,0.0,0.0,0.0" fi if [$1 ="1234" ] allora echo "1234,Uno,Milton Keynes,$RIGHTNOW ,168.27,0.0,0.0,0.0" fi if [ $1 ="1783" ] then echo "1783,Comcast,\"San Francisco, CA\",$RIGHTNOW,8420.0,0.0,0.0,0.0" fi # test/debug case only if [ $1 ="199999999" ] then echo "99999,Test,Test,$RIGHTNOW,99.99,0.0,0.0,0.0" fi}function runTest() { # esegue speedtest sul server denominato con output csv salvato nel file tmp /usr/local/bin/speedtest --csv --server $1> /usr/local/etc/speedtest.tmp if [ $? -gt 0 ] quindi # speedtest fallito quindi crea una voce zero al posto di qualsiasi messaggio di errore getCSVString $1> /usr/local/etc/speedtest.tmp fi # salva output pronto per il prossimo test del server cat /usr/local/etc/speedtest .tmp>
> /usr/local/etc/speedtest.csv}# main######## esegue speedtest su 3 server e salva tutti i risultati di output in csv filecd /usr/local/etc# clear csv file - need essere vuoto all'inizio di runrm -f /usr/local/etc/speedtest.csv######################################## ############### caso di test/debug:forza lo speedtest a fallire################################ ###################### runTest "199999999"# dormi 5####### commenta dopo il test ############### ###################################################runTest "5443"sleep 10runTest "1234"sleep 10runTest "1783"sleep 1# ora importa i dati csv in sqlite dbsqlite3 -batch /usr/local/etc/bandwidth.db <<"EOF.separator ",".import /usr/local/etc/speedtest.csv bandwidthEOF# aggiunge il csv di esecuzione corrente a backupcat /usr/local/etc/speedtest.csv>> /usr/local/etc/speedtest.bak
Mi scuso per il mio approccio "cintura e bretelle" di utilizzare percorsi completi per i file ovunque anche quando non necessari. È proprio il modo in cui mi piace farlo. Sentiti libero di migliorarlo se hai dimestichezza con la modifica degli script bash.
Imposta le proprietà del file per rendere eseguibile questo script:
# chmod 0700 larghezza di banda.sh
5 Crea un database SQLite
Crea il database bandwidth.db SQLite in /usr/local/etc :
#sqlite3 larghezza di banda.db
e quindi, al prompt di sqlite>, crea una nuova tabella con il seguente comando (non perdere il punto e virgola finale):
sqlite> CREATE TABLE SE NON ESISTE "larghezza di banda" ("serverid" INTEGER NOT NULL , "sponsor" VARCHAR NOT NULL , "servername" VARCHAR NOT NULL , "times" DATETIME CHIAVE PRIMARIA NOT NULL UNIQUE , "distanza" FLOAT NOT NULL , "ping" FLOAT NOT NULL , "download" FLOAT NOT NULL , "upload" FLOAT NOT NULL ); sqlite> .quit
Questo crea una tabella chiamata larghezza di banda con campi che si associano direttamente all'output in formato CSV di speedtest.
6 Ottieni un elenco di server
Avrai bisogno di un elenco dei server utilizzati da speedtest.
# speedtest --list> server.txt
Ora controlla su server.txt gli ID numerici dei server su cui vuoi eseguire i test.
# nano server.txt
Il file sarà simile a questo:
Recupero della configurazione di speedtest.net... 5833) Hub Network Services Ltd (Newport, Galles) [57.50 km] 5938) Spectrum Internet (Cardiff, Gran Bretagna) [65.89 km] 5443) Fasthosts Internet (Gloucester, Gran Bretagna) [74.31 km] 6504) Secure Web Services Ltd (Shrewsbury, Gran Bretagna) [78.64 km] 7265) Unitron Systems &Development Ltd (Telford, Gran Bretagna) [87.11 km] 8225) Exascale Limited (Wolverhampton, Gran Bretagna) [96.08 km ] 3110) zero.net.uk Ltd (Studley, Gran Bretagna) [96.12 km]12401) Dragon WiFi LTD (Haverfordwest, Regno Unito) [120.78 km] 1153) Warwicknet Ltd. (Coventry, Gran Bretagna) [125.18 km] 1685 ) Vodafone UK (Newbury, Gran Bretagna) [153.25 km] 4384) Iomart (Leicester, Gran Bretagna) [157.40 km] 1234) Uno (Milton Keynes, Gran Bretagna) [170.71 km] 3504) TNP Ltd. (Manchester, Gran Bretagna) ) [170.93 km]11747) Vispa (Manchester, Regno Unito) [170.93 km]
Gli ID del server sono sul lato sinistro. La cifra alla fine di ogni riga è la stima che speedtest ha fatto della distanza, in chilometri, tra la tua posizione e quella del server, anche se non sono sicuro che sia troppo precisa e possa cambiare da una corsa all'altra. I server di prova verranno elencati in ordine di questa distanza a partire dal più vicino. Il test sui server in cima a questo elenco dovrebbe, in teoria, darti i ping più veloci e le migliori velocità di download e upload rispetto ai server più in basso nell'elenco che sono molto più lontani.
7 Seleziona gli ID server e modifica bandwidth.sh
Ora sarebbe il momento di eseguire speedtest manualmente su una selezione dei diversi ID server disponibili e vedere che tipo di risultati ottieni. Ho scelto un paio di server vicino a me nel Regno Unito e uno in California per il confronto. Il formato del comando da utilizzare è:
# speedtest --server 1234
L'output che vedrai sarà simile a:
Recupero della configurazione di speedtest.net...Test da xxxxxxx (n.n.n.n)...Recupero dell'elenco dei server speedtest.net...Selezione del miglior server in base al ping...Ospitato da Uno (Milton Keynes) [187,87 km]:33.243 msTest della velocità di download.............................................. .................................Download:1,60 Mbit/sVelocità di upload in prova.... .................................................. ................................................Carica:0,55 Mbit/s
Dopo aver selezionato i server che desideri utilizzare, inserisci gli ID numerici del server (ho usato 3 server ma puoi variarlo se lo desideri) nelle righe pertinenti in bandwidth.sh
runTest "5443"sleep 10runTest "1234"sleep 10runTest "1783"sleep 1
Dovrai anche modificare il codice nella routine di errore che crea una voce fittizia se speedtest dovesse fallire in una determinata esecuzione.
# su quale server stiamo testando? if [ $1 ="5443" ] allora echo "5443,Fasthosts Internet,Gloucester,$RIGHTNOW,73.09,0.0,0.0,0.0" fi if [$1 ="1234" ] allora echo "1234,Uno,Milton Keynes,$RIGHTNOW ,168.27,0.0,0.0,0.0" fi if [ $1 ="1783" ] then echo "1783,Comcast,\"San Francisco, CA\",$RIGHTNOW,8420.0,0.0,0.0,0.0" fi
I numeri dopo $RIGHTNOW (es. 73.09) sono le distanze in chilometri dalla tua posizione al server in questione. Non li uso da nessuna parte, quindi sono solo un segnaposto e potrebbero essere qualsiasi valore numerico.
Nota con quell'esempio del 1783 che dobbiamo mettere le virgolette sulla posizione e sfuggirle per inserirle nel file CSV che stiamo creando. Le virgolette sono richieste qui perché questa posizione contiene una virgola al suo interno. Senza le virgolette di escape la virgola verrebbe trattata come un delimitatore di campo CSV che causerebbe un problema con l'importazione di SQLite. Se il server selezionato ha un testo di posizione simile con una virgola, dovrai utilizzare le virgolette con escape.
8 Imposta un cronjob
Imposta un cronjob da eseguire una volta all'ora (o tutte le volte che vuoi entro limiti ragionevoli) per eseguire /usr/local/etc/bandwidth.sh. Se stai eseguendo ISPConfig, puoi usarlo per pianificare un cronjob.
In alternativa alla riga di comando di linux puoi inserire:
# crontab -e
Dovresti vedere qualcosa di simile a questo (ricorda che hai effettuato l'accesso come 'root'):
* * * * * /usr/local/ispconfig/server/server.sh 2>&1 | durante la lettura della riga; do echo `/bin/date` "$line">> /var/log/ispconfig/cron.log; fatto* * * * * /usr/local/ispconfig/server/cron.sh 2>&1 | durante la lettura della riga; do echo `/bin/date` "$line">> /var/log/ispconfig/cron.log; done1 * * * * /usr/local/etc/bandwidth.sh 2>&1
Se non stai eseguendo ISPConfig, questo potrebbe essere inizialmente vuoto. Aggiungi l'ultima riga esattamente come mostrato sopra - la spaziatura è importante - per eseguire lo script della shell a partire dalle 00:01 e quindi ripetere ogni ora, ogni giorno. Ovviamente puoi scegliere orari diversi. (La prima volta che lo esegui, crontab ti chiederà quale editor vuoi usare - seleziono nano.)
9 Imposta PHP open_basedir
Aggiungi /usr/local/etc alla voce open_basedir di PHP per il sito web. In ISPConfig si trova nella scheda Opzioni del sito Web.
Ciò consente al codice bandwidth.php di poter accedere al database SQLite, che abbiamo appena creato, in quella directory.
Avremmo potuto saltare questo se avessimo deciso di creare il database in una directory che è già impostata come accessibile, come /var/www/clients/client1/web1/web/, ma sarebbe una scelta sbagliata dal punto di vista della sicurezza .
10 Crea bandwidth.php
Devi copiare questo codice in un file chiamato bandwidth.php sul tuo server nella directory dei documenti web di base. Se stai usando ISPConfig questo sarà qualcosa come /var/www/clients/client1/web1/web/
Monitoraggio larghezza di banda - velocità di download nelle ultime 24 ore Velocità di download - ultime 24 ore
Modifica questo file per utilizzare l'ID server su cui desideri eseguire il rapporto. Sto usando il server 1234 nel mio esempio qui, poiché ho scoperto che, dopo aver esplorato alcuni giorni di dati, questo server produceva cifre Mbps più strettamente allineate con le velocità che sentivo di ottenere. Il serverid si trova nella clausola WHERE dell'istruzione SQL SELECT:
SELECT serverid, strftime("%H:%M", volte) || " " || strftime("%d/%m/%Y", times) AS timestamp, sponsor, servername,
scarica
DA larghezza di banda
WHERE serverid =1234
ORDINA PER volte
/>LIMITE 24 OFFSET (SELECT COUNT(*)/3 DA larghezza di banda)-24;
Che cosa sta facendo esattamente questa istruzione SQL? Se non hai familiarità con SQL, diamo un'occhiata a ciascuna parte.
un. SELECT è il comando per leggere i record da una tabella di un database SQL ed è seguito dai campi da leggere e da altre opzioni.
b. strftime("%H:%M", volte) || " " || strftime("%d/%m/%Y", volte) Come timestamp
consiste nel riformattare la stringa datetime che speedtest ha creato nel suo output CSV in qualcosa di un po' più facile da usare. Voglio date formattate nel Regno Unito, quindi questo richiederà una stringa come "2017-08-31T12:02:51.898186Z" e la trasformerà in "12:02 31/08/2017". È più semplice eseguire questa riformattazione direttamente nell'istruzione SQL piuttosto che elaborarla in seguito. Gli orari qui saranno UTC/GMT, il che per me va bene, ma potresti voler cambiare questo; per esempio. se vuoi date formattate negli Stati Uniti, cambia la seconda parte in strftime("%m/%d/%Y", times).
c. serverid, timestamp, sponsor, servername, download sono i campi che vogliamo leggere dalla tabella SQL e creare nel nostro oggetto JSON.
d. FROM bandwidth è il nome della tabella SQL da cui stiamo leggendo.
e. WHERE serverid =1234 imposta il sottoinsieme della tabella da leggere - cambialo in modo che corrisponda al serverid che hai usato e potresti voler leggere i dati per più di un server - ma questo complicherà il grafico.
f. ORDER BY times imposta l'ordinamento dell'output:vogliamo che sia ordinato in base al timestamp impostato da speedtest per ogni esecuzione.
g. LIMIT 24 limita l'output a 24 record, poiché vogliamo mostrare solo 24 ore di dati e poiché il nostro cronjob è impostato per essere eseguito una volta all'ora. Se eri in esecuzione due volte all'ora, dovresti impostarlo su 48 per ottenere 24 ore di dati.
h. OFFSET (SELEZIONARE COUNT(*)/3 DA larghezza di banda)-24; vogliamo gli ultimi 24 record dalla tabella in quanto sono le voci più recenti a cui siamo interessati, quindi dobbiamo specificare un OFFSET per abbinare il LIMIT. Senza questo otterremmo sempre i primi 24 record nella tabella anziché i 24 più recenti. Per ottenere il giusto offset contiamo tutti i record nella tabella con (SELECT COUNT(*)) quindi dividiamo questo per 3 (dato che eseguiamo speedtest 3 volte all'ora, una volta per ciascuno dei 3 diversi server) e quindi sottraiamo 24 da questo totale per ottenere la giusta posizione di OFFSET in modo che il LIMIT 24 ottenga i record che vogliamo.
Se hai modificato lo script bash per eseguire qualcosa di diverso da 3 diversi test del server all'ora, regola di conseguenza quella parte /3. Se stai testando solo su un server, la divisione non è affatto necessaria.
Potresti anche voler regolare le dimensioni complessive del grafico, dove ho preso la strada più semplice per codificare una dimensione adatta al mio schermo - è impostata in questa riga:
11 Ottieni una copia locale dei file
Preferisco avere versioni locali di tutti i file di libreria css e js (ma non i caratteri Google) necessari in una pagina Web e se sei lo stesso, dovrai ottenerne una copia sul tuo server di Chart.bundle.min. js e mettilo nella directory /var/www/clients/client1/web1/web/scripts sul tuo server (o in qualsiasi directory di base sia giusta per te).
Puoi scaricare il file da:https://cdnjs.cloudflare.com/ajax/libs/Chartajs/2.6.0/Chart.bundle.min.js
Se non si desidera utilizzare una copia locale, modificare bandwidth.php in modo che punti invece alla versione CDN pubblica. Basta cambiare questa riga:
a questo:
12 Abilita PHP in ISPConfig
Non dimenticare di abilitare PHP nelle impostazioni del tuo sito Web, se non è già stato impostato.
13 Carica bandwidth.php nel browser
Abbiamo finalmente finito. Una volta che lo script della shell bandwidth.sh ha avuto il tempo di essere eseguito alcune volte per generare alcuni dati (o potresti eseguirlo manualmente più volte all'inizio), punta il browser sul sito Web del tuo server Linux, carica bandwidth.php e dovresti vedere qualcosa di simile questo:
E sì, la mia banda larga è davvero pessima!
Infine, ecco alcuni punti extra che vale la pena coprire:
14 Output grafico a barre
Dovremmo notare che le cifre di download e upload memorizzate nella tabella SQL sono in bps anziché in Mbps (insieme a un numero sconcertante di cifre decimali - numeri come 1533681.5922415722). Questo è solo il modo in cui speedtest produce i dati quando viene eseguito in modalità CSV. Per mostrare la cifra Mbps, anziché bps, sull'output dell'asse y del grafico a barre ci sono un paio di righe incluse nel codice Javascript in bandwidth.php per eseguire la conversione:
mbps =Math.round(bandwidth_data[i].download/1000).toFixed(3)/1000; bvalue =mbps.toLocaleString(undefined, { MinimumFractionDigits:3 });
L'uso di toLocaleString dovrebbe inserire la corretta punteggiatura decimale (un "." o ",") come impostato dalle impostazioni locali del browser, ma questo dipende dall'implementazione e in qualche modo incoerente. Se tu vedi . invece di , e ti infastidisce, Globalize è il modo per risolvere questo problema. Vedi "18 Ulteriori passaggi e idee" di seguito.
Sono necessarie alcune righe in più per sovrascrivere il trattamento predefinito del codice al passaggio del mouse degli zeri finali, poiché chart.js normalmente visualizzerà "2.000" solo come "2", che non è quello che voglio, specialmente dopo essermi dato il disturbo di assicurandosi che siano lì in primo luogo:
// sovrascriviamo il suggerimento predefinito che elimina gli zeri finali anche se li abbiamo già inseriti suggerimenti comandi:{ callback:{ label:function(tooltipItem, data) { var value =data.datasets[0].data[ tooltipItem.index]; var label ='scarica:'; var retvalue =value.toLocaleString(undefined, { MinimumFractionDigits:3 }); etichetta di ritorno + ' ' + rivalore + 'Mbps'; } } },
Questo è un bell'esempio di come puoi "scoprire" chart.js e cambiare il modo in cui fa le cose.
Inoltre, ho impostato le opzioni del grafico per stampare il timestamp sull'asse x per ogni barra:
xAxes:[{ ticks:{ autoSkip:false, maxTicksLimit:24 }
L'opzione predefinita (con autoSkip impostato su true) ha prodotto un paio di lacune dall'aspetto strano nelle etichette. Dovrai modificare maxTicksLimit se desideri visualizzare qualcosa di diverso da 24 voci.
Se desideri ulteriore assistenza per modificare una qualsiasi delle opzioni di chart.js o non riesci a ottenere ciò che desideri, controlla le pagine specifiche di chart.js Stack Overflow:ci sono molte informazioni utili lì - https://stackoverflow .com/questions/tagged/chart.js - Usa la casella di ricerca per restringere il campo di ciò che stai cercando. Sfortunatamente, la documentazione di chart.js è carente in alcuni degli esempi più avanzati che sarebbero sicuramente di grande aiuto per aggiornarsi utilizzando questo fantastico pezzo di codice open-source.
15 Gestione degli errori
Durante i miei test iniziali, ho notato un paio di volte che speedtest riportava "Impossibile recuperare l'elenco dei server speedtest" nel file CSV. Presumibilmente questo rifletteva i tempi in cui la mia connessione a banda larga era così pessima che speedtest non riusciva affatto a connettersi al server di prova. Questo testo ovviamente non è in un formato che vogliamo importare nel database SQLite, quindi avevo bisogno di una soluzione a questo che eliminasse questo testo indesiderato dal file CSV e includesse anche una voce zero nel database per la fascia oraria specifica, altrimenti qualsiasi voce mancante nella tabella SQL sarebbe semplicemente invisibile e annullerebbe anche l'allineamento che volevo avere 24 voci al giorno durante la creazione del grafico.
Vedrai in bandwidth.sh che lo script verifica il codice di uscita impostato da speedtest utilizzando la variabile di script $? e se è maggiore di zero questo indica che lo speedtest è fallito. Ciò attiverà la funzione per creare una voce CSV fittizia, che verrà quindi utilizzata per sovrascrivere il file CSV per quell'esecuzione.
Ci sono un paio di righe nello script bash che sono commentate ma che verificheranno questa routine di errore per generare una voce fittizia zero se esegui lo script dopo aver tolto il commento a quelle righe.
######################################################## test/ caso di debug:forza lo speedtest a fallire##################################################### ## runTest "199999999"# sleep 5####### commento dopo il test #################################### #############################
Questo utilizza un ID server "nonsense" a cui speedtest non piace, facendo in modo che restituisca un codice di uscita diverso da zero. Lo script quindi dovrebbe creare una voce fittizia che può rimanere felicemente nella tabella SQL ed essere ignorata o eliminarla.
Un altro modo per forzare lo speedtest a fallire, a questo scopo di test, sarebbe rimuovere la connessione di rete del server. Non dimenticare che puoi eseguire lo script bandwidth.sh manualmente in qualsiasi momento, non devi aspettare che il cronjob si spenga, anche se dovresti evitare di eseguirlo manualmente se un cronjob è imminente. Avere due script in esecuzione contemporaneamente potrebbe rovinare i file CSV e quindi la tabella SQL.
Se accade il peggio, c'è un file CSV di backup mantenuto come /usr/local/etc/speedtest.bak che dovrebbe contenere tutto l'output CSV da speedtest dalla prima esecuzione dello script bash in poi. Questo potrebbe essere modificato per rimuovere qualsiasi voce indesiderata, la tabella SQL cancellata e quindi l'intero set di voci CSV reimportato in SQLite.
16 fusi orari
Speedtest riporta l'ora in UTC (fondamentalmente è la stessa dell'ora di Greenwich o GMT). L'utilizzo dell'ora UTC significa che tutti gli orari archiviati nella tabella SQL sono coerenti e l'ora legale non avrà alcun impatto indesiderato.
Ma questo significa che la routine di gestione degli errori in bandwidth.sh deve creare un timestamp per la voce fittizia per riflettere questo. Questo è piuttosto semplice:abbiamo appena incluso il flag --utc:
local RIGHTNOW=$(data --utc +%Y-%m-%dT%H:%M:%SZ)
Se vuoi che le etichette dell'asse x del grafico mostrino gli orari come qualcosa di diverso da UTC/GMT, il posto migliore per apportare tale modifica sarebbe nell'istruzione SQL SELECT, ad esempio:
strftime("%H:%M", time(times, 'localtime')) || " " || strftime("%d/%m/%Y", volte) Come timestamp
Ciò utilizzerà le impostazioni del fuso orario del tuo server Linux per regolare gli orari mostrati nel grafico. Oppure potresti tuffarti per capire come Globalize potrebbe farlo nel front-end.
Per ulteriori informazioni, vedere https://www.timeanddate.com/time/gmt-utc-time.html e http://www.tutorialspoint.com/sqlite/sqlite_date_time.htm.
17 Ulteriori passaggi e idee
Speedtest non ha bisogno di essere la fonte dei tuoi dati grezzi:potrebbe provenire da qualsiasi luogo ed essere per qualsiasi cosa, non solo per la velocità di Internet. Il principio è lo stesso:un processo del server di back-end che può ottenere i dati grezzi in un formato utile e quindi importarli in SQLite da uno script bash con un front-end che estrae il sottoinsieme di dati desiderati e quindi lo traccia.
Uno script bash più complesso potrebbe scrivere i dati direttamente in una tabella SQL (usando il comando SQL INSERT) se la formattazione come CSV non è un'opzione. Quando progetti la tabella SQL, pensa a come potresti voler estrarre i dati in un secondo momento.
Quando apporti modifiche, tieni presente il contesto del codice che stai modificando; cioè abbiamo istruzioni SQL all'interno dello script PHP all'interno di Javascript all'interno dell'HTML. Ricorda il livello in cui ti trovi e codifica di conseguenza. Può essere facile perdere le tracce e finire per scrivere codice PHP in quello che dovrebbe essere Javascript! Posso garantire che non funzionerà.
Ecco alcune idee per ulteriori esplorazioni:
- toLocaleString non è implementato in modo coerente tra i browser. Usa Globalizza e gestisci tutti i formati di numeri, data e fuso orario con esso.
- Checkout httpstat (esiste una versione di script bash) che consente di raccogliere diversi tipi di dati di connessione a Internet. Memorizzare questo in una tabella SQL (separata) e rappresentare graficamente l'output.
- Migliora il front-end di bandwidth.php per dare all'utente la possibilità di scegliere tra diverse opzioni:24, 48, 72 ore; seleziona una data specifica, includi i dati di caricamento e scaricamento, i tempi di ping.
- Convertire l'HTML per utilizzare il codice Bootstrap reattivo in modo che funzioni correttamente su dispositivi o dimensioni dello schermo differenti.
- Esplora alcune delle altre opzioni di chart.js; forse una linea combinata e un grafico a barre; cambia i colori e le dimensioni della barra.
- sostituisci SQLite con MySQL e aggiungi maggiore sicurezza con l'accesso in lettura da PHP tramite utente/password.
- Costruisci un sistema simile ma usando node.js.
18 link
- test di velocità:https://github.com/sivel/speedtest-cli
- SQLite3:https://sqlite.org/
- chart.js:http://www.chartjs.org/
- Globalizzare:https://github.com/globalizejs/globalize
- httpstat:https://github.com/b4b4r07/httpstat
- Bootstrap:http://getbootstrap.com/
- PHP:http://www.php.net/
- Configurazione ISP:http://www.ispconfig.org/
- Debian:http://www.debian.org/