Comment utiliser speedtest sur un serveur Linux pour vérifier, stocker et rapporter les vitesses Internet graphiquement

Suite à un ensemble de problèmes de connectivité Internet médiocre que j’ai rencontrés, j’ai décidé que je voulais surveiller la vitesse en Mbps que je recevais de mon fournisseur de manière régulière. Je voyais des chiffres particulièrement mauvais lorsque j’essayais de télécharger des fichiers le soir, avec des vitesses beaucoup plus rapides atteintes très tôt le matin.

J’ai un serveur Linux Debian qui traîne dans un coin, qui est ma machine de test et de développement pour les sites Web hébergés par ISPConfig, ainsi que quelques codes Let’s Encrypt avec lesquels j’aime jouer, donc j’ai cherché un logiciel qui permettrait de tester la bande passante, exécutable depuis une ligne de commande Linux, qui pourrait constituer la base d’un système de script shell automatisé pour produire les données brutes dont j’avais besoin. Je voulais stocker les données dans une base de données SQL pour faciliter les requêtes (je pouvais alors facilement rassembler plus de données et extraire simplement un sous-ensemble plus petit pour les périodes de temps qui m’intéressaient) et avoir une interface web qui pourrait produire un graphique simple pour visualiser les données et aider à mettre en évidence les problèmes de connectivité.

Le premier résultat de ma recherche a été l’article vraiment utile d’Antonio Valencia à : https://www.howtoforge.com/tutorial/check-internet-speed-with-speedtest-cli-on-ubuntu/

Après avoir suivi les instructions pour installer speedtest, un rapide essai a montré que je pouvais l’utiliser pour exécuter des tests contre un large éventail de serveurs Internet et également produire une sortie au format CSV, qui est tout à fait adaptée à une importation directe dans une table SQL avec le minimum d’effort en développement logiciel.

Pour la quantité relativement petite de données qui serait générée, j’ai décidé d’utiliser SQLite comme stockage backend et une recherche rapide des bibliothèques de graphisme basées sur JavaScript disponibles m’a conduit à chart.js, qui a un design simple et épuré avec une interface de données simple mais beaucoup de possibilités de personnalisation avancée si nécessaire. Convertir les données SQL pour extraire juste le sous-ensemble de données que je voulais représenter graphiquement avec une sortie via JSON grâce à un code PHP simple était la voie à suivre.

Donc, dans l’ensemble, j’avais besoin de concevoir un système qui ressemblait à ceci :

Un serveur Linux exécutant speedtest en tant que cronjob - peut-être 1 par heure - avec la sortie de speedtest étant stockée dans une base de données SQLite - le tout contrôlé par un fichier de script shell bash. Une interface web, étant un mélange de HTML, CSS, JavaScript et PHP pour extraire des données de SQLite et produire un graphique à barres montrant les chiffres Mbps atteints pour les 24 heures précédentes (ou toute autre période que je pourrais décider).

Un peu d’expérimentation avec l’exécution de speedtest une douzaine de fois de manière interactive m’a montré qu’il y avait quelques serveurs disponibles qui semblaient donner des résultats qui étaient étroitement alignés avec les vitesses que je rencontrais. J’ai considéré qu’il était judicieux de tester contre plus d’un serveur pour mieux comprendre comment mes chiffres Mbps étaient affectés par l’emplacement du serveur cible et l’heure de la journée dans un fuseau horaire différent.

Si vous souhaitez suivre et configurer un système similaire pour vous-même, vous devrez sélectionner un ou plusieurs serveurs parmi les centaines disponibles pour speedtest qui conviennent à votre emplacement.

1 Prérequis

un serveur linux - j’utilise Debian 9.1 - stretch
accès tty au serveur avec connexion root - j’utilise PuTTY depuis un ordinateur portable Windows
ISPConfig installé et un site Web configuré avec un compte FTP également - j’utilise 3.1.6 avec apache défini comme serveur web (vous pourriez vous en sortir avec juste un serveur web, avec quelques modifications mineures aux instructions suivantes)
PHP - j’utilise 7.0 mais cela devrait fonctionner avec la plupart des versions antérieures également
client FTP - j’utilise Filezilla - et PureFTPd exécuté sur le serveur
nano - ou votre éditeur visuel préféré

Je suppose ici que vous êtes à l’aise avec la connexion à un serveur Linux, comment naviguer dans les répertoires, la disposition de l’endroit où votre serveur web s’attend à ce que les fichiers soient et comment FTP des fichiers dans ces répertoires.

Voici les étapes détaillées pour vous permettre de tout configurer.

2 Installer speedtest

Connectez-vous à votre serveur linux en tant que root et exécutez la commande :

# pip install speedtest-cli

Voir https://www.howtoforge.com/tutorial/check-internet-speed-with-speedtest-cli-on-ubuntu/ et https://pypi.python.org/pypi/speedtest-cli pour plus d’infos si vous avez des problèmes.

Remarque : speedtest et speedtest-cli sont identiques sur mon installation, donc je ferai simplement référence à speedtest dans ce qui suit.

3 Installer SQLite3

# apt-get install sqlite3

Utilisez l’équivalent pour votre distribution si apt-get n’est pas pour vous.

4 Créer bandwidth.sh

Entrez le code de script bash suivant dans un fichier et enregistrez-le sous /usr/local/etc/bandwidth.sh - nous allons le modifier un peu plus tard pour le rendre spécifique pour vous.

#!/bin/bash
# exécuter des tests de vitesse contre 3 serveurs et enregistrer tous les résultats de sortie dans un fichier CSV pour importation dans la base de données sqlite
#
# exécuté par cronjob une fois par heure
#
#
function getCSVString () {
    # si speedtest a échoué (par exemple, il n'a pas pu accéder à un serveur) nous devons créer une entrée nulle pour ce créneau horaire
    
    # obtenir une chaîne de timestamp dans le même format que speedtest génère - et nous avons besoin de l'heure UTC
    local RIGHTNOW=$(date --utc +%Y-%m-%dT%H:%M:%SZ)
    
    # contre quel serveur testons-nous ?
    if [ $1 = "5443" ] 
    then
        echo "5443,Fasthosts Internet,Gloucester,$RIGHTNOW,73.09,0.0,0.0,0.0"
    fi
    if [ $1 = "1234" ] 
    then
        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 () {
    # exécuter speedtest contre le serveur nommé avec sortie csv enregistrée dans un fichier tmp
    /usr/local/bin/speedtest --csv --server $1 > /usr/local/etc/speedtest.tmp
    if [ $? -gt 0 ] 
    then
        # speedtest a échoué donc créez une entrée nulle à la place de tout message d'erreur
        getCSVString $1 > /usr/local/etc/speedtest.tmp
    fi

    # sauvegarder la sortie prête pour le prochain test de serveur
    cat /usr/local/etc/speedtest.tmp >> /usr/local/etc/speedtest.csv
}

# principal
#######
# exécuter speedtest contre 3 serveurs et enregistrer tous les résultats de sortie dans un fichier csv
cd /usr/local/etc

# vider le fichier csv - doit être vide au début de l'exécution
rm -f /usr/local/etc/speedtest.csv

############################################
# test/debug case - force speedtest à échouer
############################################
# runTest "199999999"
# sleep 5
####### commenter après test ##########
############################################

runTest "5443"
sleep 10

runTest "1234"
sleep 10

runTest "1783"
sleep 1

# maintenant importer les données csv dans la base de données sqlite
sqlite3 -batch /usr/local/etc/bandwidth.db <<"EOF"
.separator ","
.import /usr/local/etc/speedtest.csv bandwidth
EOF

# ajouter l'exécution csv actuelle à la sauvegarde
cat /usr/local/etc/speedtest.csv >> /usr/local/etc/speedtest.bak

Je m’excuse pour mon approche “ceinture et bretelles” d’utiliser des chemins complets pour les fichiers partout même lorsque ce n’est pas nécessaire. C’est juste ma façon de faire. N’hésitez pas à améliorer cela si vous êtes à l’aise avec l’édition de scripts bash.

Définissez les propriétés du fichier pour rendre ce script exécutable :

# chmod 0700 bandwidth.sh

5 Créer une base de données SQLite

Créez la base de données SQLite bandwidth.db dans /usr/local/etc :

#sqlite3 bandwidth.db

et ensuite, à l’invite sqlite>, créez une nouvelle table avec la commande suivante (ne manquez pas le point-virgule final) :

sqlite> CREATE TABLE IF NOT EXISTS "bandwidth" ("serverid" INTEGER NOT NULL , "sponsor" VARCHAR NOT NULL , "servername" VARCHAR NOT NULL , "times" DATETIME PRIMARY KEY NOT NULL UNIQUE , "distance" FLOAT NOT NULL , "ping" FLOAT NOT NULL , "download" FLOAT NOT NULL , "upload" FLOAT NOT NULL );

sqlite> .quit

Cela crée une table appelée bandwidth avec des champs qui correspondent directement au format de sortie CSV de speedtest.

6 Obtenir une liste de serveurs

Vous aurez besoin d’une liste des serveurs que speedtest utilise.

# speedtest --list > servers.txt

Maintenant, vérifiez servers.txt pour les identifiants numériques du ou des serveurs contre lesquels vous souhaitez exécuter vos tests.

# nano servers.txt

Le fichier ressemblera à ceci :

Récupération de la configuration speedtest.net...
 5833) Hub Network Services Ltd (Newport, Pays de Galles) [57.50 km]
 5938) Spectrum Internet (Cardiff, Grande-Bretagne) [65.89 km]
 5443) Fasthosts Internet (Gloucester, Grande-Bretagne) [74.31 km]
 6504) Secure Web Services Ltd (Shrewsbury, Grande-Bretagne) [78.64 km]
 7265) Unitron Systems & Development Ltd (Telford, Grande-Bretagne) [87.11 km]
 8225) Exascale Limited (Wolverhampton, Grande-Bretagne) [96.08 km]
 3110) zero.net.uk Ltd (Studley, Grande-Bretagne) [96.12 km]
12401) Dragon WiFi LTD (Haverfordwest, Royaume-Uni) [120.78 km]
 1153) Warwicknet Ltd. (Coventry, Grande-Bretagne) [125.18 km]
 1685) Vodafone UK (Newbury, Grande-Bretagne) [153.25 km]
 4384) Iomart (Leicester, Grande-Bretagne) [157.40 km]
 1234) Uno (Milton Keynes, Grande-Bretagne) [170.71 km]
 3504) TNP Ltd. (Manchester, Grande-Bretagne) [170.93 km]
11747) Vispa (Manchester, Royaume-Uni) [170.93 km]

Les identifiants des serveurs sont sur le côté gauche. Le chiffre à la fin de chaque ligne est l’estimation que speedtest a faite de la distance, en kilomètres, entre votre emplacement et celui du serveur, bien que je ne sois pas sûr que ce soit très précis et cela peut changer d’une exécution à l’autre. Les serveurs de test seront listés par ordre de cette distance, en commençant par le plus proche. Tester contre les serveurs près du haut de cette liste devrait, en théorie, vous donner les pings les plus rapides et les meilleures vitesses de téléchargement et de téléversement par rapport aux serveurs plus bas dans la liste qui sont beaucoup plus éloignés.

7 Sélectionner les identifiants de serveur et éditer bandwidth.sh

Il serait maintenant temps d’exécuter speedtest manuellement contre une sélection des différents identifiants de serveur disponibles et de voir quels résultats vous obtenez. J’ai choisi quelques serveurs proches de moi au Royaume-Uni et un en Californie pour comparaison. Le format de la commande à utiliser est :

# speedtest --server 1234

La sortie que vous voyez sera similaire à :

Récupération de la configuration speedtest.net...
Test de xxxxxxx (n.n.n.n)...
Récupération de la liste des serveurs speedtest.net...
Sélection du meilleur serveur basé sur le ping...
Hébergé par Uno (Milton Keynes) [187.87 km]: 33.243 ms
Test de la vitesse de téléchargement................................................................................
Téléchargement : 1.60 Mbit/s
Test de la vitesse de téléversement...............................................................................................
Téléversement : 0.55 Mbit/s

Une fois que vous avez sélectionné les serveurs que vous souhaitez utiliser, mettez les identifiants numériques des serveurs (j’ai utilisé 3 serveurs mais vous pouvez varier cela si vous le souhaitez) dans les lignes pertinentes de bandwidth.sh

runTest "5443"
sleep 10

runTest "1234"
sleep 10

runTest "1783"
sleep 1

Vous devrez également ajuster le code dans la routine d’erreur qui crée une entrée fictive si speedtest devait échouer lors d’une exécution particulière.

    # contre quel serveur testons-nous ?
    if [ $1 = "5443" ] 
    then
        echo "5443,Fasthosts Internet,Gloucester,$RIGHTNOW,73.09,0.0,0.0,0.0"
    fi
    if [ $1 = "1234" ] 
    then
        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

Les chiffres après $RIGHTNOW là-dedans (par exemple 73.09) sont les distances en kilomètres de votre emplacement au serveur en question. Je n’utilise pas ces valeurs n’importe où, donc ce sont juste des espaces réservés et pourraient être n’importe quelle valeur numérique.

Notez avec cet exemple 1783 que nous devons mettre des guillemets sur l’emplacement, et les échapper pour les faire entrer dans le fichier CSV que nous créons. Les guillemets sont requis ici car cet emplacement a un virgule à l’intérieur. Sans les guillemets échappés, la virgule serait traitée comme un délimiteur de champ CSV, ce qui poserait un problème avec l’importation SQLite. Si le serveur que vous sélectionnez a un texte d’emplacement similaire avec une virgule, vous devrez utiliser les guillemets échappés.

8 Configurer un cronjob

Configurez un cronjob pour s’exécuter une fois par heure (ou aussi souvent que vous le souhaitez dans la limite du raisonnable) pour exécuter /usr/local/etc/bandwidth.sh. Si vous exécutez ISPConfig, vous pouvez l’utiliser pour planifier un cronjob.

Créer un cronjob

Alternativement, à la ligne de commande linux, vous pourriez entrer :

# crontab -e

Vous devriez voir quelque chose de similaire à ceci (rappelez-vous que vous êtes connecté en tant que ‘root’) :

* * * * * /usr/local/ispconfig/server/server.sh 2>&1 | while read line; do echo `/bin/date` "$line" >> /var/log/ispconfig/cron.log; done
* * * * * /usr/local/ispconfig/server/cron.sh 2>&1 | while read line; do echo `/bin/date` "$line" >> /var/log/ispconfig/cron.log; done
1 * * * * /usr/local/etc/bandwidth.sh 2>&1

Si vous n’exécutez pas ISPConfig, cela peut être initialement vide. Ajoutez cette dernière ligne exactement comme indiqué ci-dessus - l’espacement est important - pour exécuter le script shell à partir de 00:01 AM puis le répéter chaque heure, chaque jour. Vous pouvez choisir d’autres heures bien sûr. (La toute première fois que vous exécutez cela, crontab vous demandera quel éditeur vous souhaitez utiliser - je sélectionne nano.)

9 Définir PHP open_basedir

Ajoutez /usr/local/etc à l’entrée open_basedir de PHP pour le site Web. Dans ISPConfig, cela se trouve dans l’onglet Options pour le site Web.

Définir open_basedir

Cela permet au code bandwidth.php d’accéder à la base de données SQLite que nous venons de créer, dans ce répertoire.

Nous aurions pu sauter cela si nous avions décidé de créer la base de données dans un répertoire déjà défini comme accessible, tel que /var/www/clients/client1/web1/web/, mais ce serait un mauvais choix d’un point de vue sécurité.

10 Créer bandwidth.php

Vous devez copier ce code dans un fichier nommé bandwidth.php sur votre serveur dans le répertoire de documents web de base. Si vous utilisez ISPConfig, cela sera quelque chose comme /var/www/clients/client1/web1/web/

 
 
 
Moniteur de bande passante - vitesses de téléchargement des dernières 24 heures





Vitesses de téléchargement - dernières 24 heures

Modifiez ce fichier pour utiliser l’identifiant de serveur sur lequel vous souhaitez faire rapport. J’utilise le serveur 1234 dans mon exemple ici, car j’ai constaté qu’après avoir exploré quelques jours de données, ce serveur produisait des chiffres Mbps les plus alignés avec les vitesses que je pensais obtenir. L’identifiant du serveur est dans la clause WHERE de l’instruction SQL SELECT :

SELECT serverid, strftime("%H:%M", times) || " " || strftime("%d/%m/%Y", times) AS timestamp, sponsor, servername, download
FROM bandwidth
WHERE serverid = 1234
ORDER BY times
LIMIT 24 OFFSET (SELECT COUNT(*)/3 FROM bandwidth)-24;

Que fait exactement cette instruction SQL ? Si vous n’êtes pas familier avec SQL, examinons chaque partie.

a. SELECT est la commande pour lire des enregistrements à partir d’une table de base de données SQL et est suivie des champs à lire et d’autres options.

b. strftime(“%H:%M”, times) || “ “ || strftime(“%d/%m/%Y”, times) AS timestamp

sert à reformater la chaîne datetime que speedtest a créée dans sa sortie CSV en quelque chose d’un peu plus convivial. Je veux des dates au format britannique, donc cela prendra une chaîne telle que “2017-08-31T12:02:51.898186Z” et la transforme en “12:02 31/08/2017”. Il est plus simple de faire ce reformatage directement dans l’instruction SQL plutôt que de devoir le traiter par la suite. Les temps ici vont être en UTC/GMT, ce qui me convient, mais vous voudrez peut-être changer cela ; par exemple, si vous voulez des dates au format américain, changez cette seconde partie en strftime(“%m/%d/%Y”, times).

c. serverid, timestamp, sponsor, servername, download sont les champs que nous voulons lire à partir de la table SQL et créer dans notre objet JSON.

d. FROM bandwidth est le nom de la table SQL à partir de laquelle nous lisons.

e. WHERE serverid = 1234 définit le sous-ensemble de la table à lire - changez cela pour correspondre à l’identifiant du serveur que vous avez utilisé, et vous voudrez peut-être lire des données pour plus d’un serveur - mais cela compliquera le graphique.

f. ORDER BY times définit l’ordre de tri de la sortie - nous voulons qu’elle soit ordonnée par le timestamp que speedtest a défini pour chaque exécution.

g. LIMIT 24 limite la sortie à 24 enregistrements, car nous ne voulons afficher que 24 heures de données et parce que notre cronjob est défini pour s’exécuter une fois par heure. Si vous exécutiez deux fois par heure, vous devriez définir cela à 48 pour obtenir 24 heures de données.

h. OFFSET (SELECT COUNT()/3 FROM bandwidth)-24 ; nous voulons les 24 derniers enregistrements de la table car ce sont les entrées les plus récentes qui nous intéressent, donc nous devons spécifier un OFFSET pour correspondre au LIMIT. Sans cela, nous obtiendrions toujours les 24 premiers enregistrements de la table plutôt que les 24 plus récents. Pour obtenir le bon offset, nous comptons tous les enregistrements dans la table avec (SELECT COUNT()) puis divisons cela par 3 (car nous exécutons speedtest 3 fois par heure, une fois pour chacun des 3 serveurs différents) puis soustrayons 24 de ce total pour obtenir la bonne position OFFSET afin que LIMIT 24 obtienne alors les enregistrements que nous voulons.

Si vous avez modifié le script bash pour exécuter quelque chose d’autre que 3 tests de serveurs différents par heure, ajustez cette partie /3 en conséquence. Si vous ne testez qu’un seul serveur, la division n’est pas nécessaire du tout.

Vous voudrez peut-être également ajuster la taille globale du graphique, où j’ai pris la voie facile de coder une taille adaptée à mon écran - elle est définie dans cette ligne :

11 Obtenir une copie locale des fichiers

Je préfère avoir des versions locales de tous les fichiers css et js de bibliothèque nécessaires dans une page web et si vous êtes pareil, vous devrez obtenir une copie sur votre serveur de Chart.bundle.min.js et la placer dans le répertoire /var/www/clients/client1/web1/web/scripts sur votre serveur (ou quel que soit le répertoire de base qui vous convient).

Vous pouvez télécharger le fichier à partir de : https://cdnjs.cloudflare.com/ajax/libs/Chartajs/2.6.0/Chart.bundle.min.js

Si vous ne souhaitez pas utiliser une copie locale, modifiez bandwidth.php pour pointer vers la version publique CDN à la place. Il suffit de changer cette ligne :

à ceci :

12 Activer PHP dans ISPConfig

N’oubliez pas d’activer PHP dans les paramètres de votre site Web, si cela n’a pas déjà été fait.

Activer PHP dans le site web

13 Charger bandwidth.php dans le navigateur

Nous avons enfin terminé. Une fois que le script shell bandwidth.sh a eu le temps de s’exécuter plusieurs fois pour générer des données (ou vous pourriez l’exécuter manuellement plusieurs fois au début), pointez votre navigateur vers le site Web de votre serveur Linux, chargez bandwidth.php et vous devriez voir quelque chose comme ceci :

Graphique de bande passante

Et oui, ma connexion Internet est vraiment aussi mauvaise !

Enfin, voici quelques points supplémentaires qui méritent d’être abordés :

14 Sortie du graphique à barres

Nous devrions noter que les chiffres de téléchargement et de téléversement stockés dans la table SQL sont en bps plutôt qu’en Mbps (avec un nombre déroutant de chiffres décimaux - des nombres comme 1533681.5922415722). C’est juste la façon dont speedtest produit les données lorsqu’il est exécuté en mode CSV. Pour afficher le chiffre Mbps, plutôt que bps, sur l’axe y de la sortie du graphique à barres, il y a quelques lignes incluses dans le code Javascript dans bandwidth.php pour effectuer la conversion :

    mbps = Math.round(bandwidth_data[i].download/1000).toFixed(3)/1000; 
    bvalue = mbps.toLocaleString(undefined, { minimumFractionDigits: 3 });

L’utilisation de toLocaleString devrait insérer la bonne ponctuation décimale (un “.” ou “,”) selon le paramètre de langue de votre navigateur, mais cela dépend de l’implémentation et est quelque peu incohérent. Si vous voyez . au lieu de , et que cela vous dérange, alors Globalize est la solution pour corriger cela. Voir ‘18 Étapes supplémentaires et idées’ ci-dessous.

Quelques lignes supplémentaires sont nécessaires pour remplacer le traitement par défaut des info-bulles des zéros à la fin, car chart.js affichera normalement “2.000” simplement comme “2”, ce qui n’est pas ce que je veux, surtout après avoir pris la peine de m’assurer qu’ils sont là en premier lieu :

    // nous remplaçons l'info-bulle par défaut qui supprime les zéros à la fin même si nous les avons déjà mis là
    tooltips: {
        callbacks: {
            label: function(tooltipItem, data) {
                var value = data.datasets[0].data[tooltipItem.index];
                var label = 'téléchargement: ';
                var retvalue = value.toLocaleString(undefined, { minimumFractionDigits: 3 });
                return label + ' ' + retvalue + ' Mbps';
            }
        }
    },

C’est un bel exemple de la façon dont vous pouvez “approfondir” dans chart.js et changer la façon dont cela fonctionne.

De plus, j’ai défini les options du graphique pour imprimer le timestamp sur l’axe x pour chaque barre :

    xAxes: [{
        ticks: {
            autoSkip: false,
            maxTicksLimit: 24
        }
    }],

L’option par défaut (avec autoSkip définie sur true) a entraîné quelques lacunes étranges dans les étiquettes. Vous devrez changer maxTicksLimit si vous souhaitez afficher autre chose que 24 entrées.

Si vous souhaitez plus d’aide pour modifier l’une des options de chart.js ou si vous ne parvenez pas à obtenir ce que vous voulez, consultez les pages spécifiques de chart.js sur Stack Overflow - il y a beaucoup d’infos utiles là-bas - https://stackoverflow.com/questions/tagged/chart.js - Utilisez simplement la boîte de recherche pour affiner ce que vous recherchez. Malheureusement, la documentation de chart.js manque de certains des exemples plus avancés qui seraient certainement d’une grande aide pour se familiariser avec ce morceau de code open-source formidable.

15 Gestion des erreurs

Lors de mes premiers tests, j’ai remarqué quelques fois que speedtest a signalé “Impossible de récupérer la liste des serveurs speedtest” dans le fichier CSV. Cela reflétait probablement les moments où ma connexion Internet était si mauvaise que speedtest ne pouvait pas se connecter au serveur de test. Ce texte n’est évidemment pas dans un format que nous voulons importer dans la base de données SQLite, donc j’avais besoin d’une solution à cela qui supprimerait ce texte indésirable du fichier CSV et inclurait également une entrée nulle dans la base de données pour le créneau horaire spécifique, sinon toute entrée manquante dans la table SQL serait simplement invisible et jetterait également le désalignement que je voulais d’avoir 24 entrées par jour lors de la création du graphique.

Vous verrez dans bandwidth.sh que le script teste le code de sortie défini par speedtest en utilisant la variable de script $? et si elle est supérieure à zéro, cela indique que speedtest a échoué. Cela déclenchera la fonction pour créer une entrée CSV fictive - qui est ensuite utilisée pour écraser le fichier CSV pour cette exécution.

Il y a quelques lignes dans le script bash qui sont commentées mais qui testeront cette routine d’erreur pour générer une entrée nulle si vous exécutez le script après avoir décommenté ces lignes.

############################################
# test/debug case - force speedtest à échouer
############################################
# runTest "199999999"
# sleep 5
####### commenter après test ##########
############################################

Cela utilise un identifiant de serveur “absurde” que speedtest n’aime pas, provoquant ainsi un code de sortie non nul. Le script devrait alors créer une entrée fictive qui peut rester tranquillement dans la table SQL et être ignorée ou vous pourriez la supprimer.

Une autre façon de forcer speedtest à échouer, à des fins de test, serait de retirer la connexion réseau du serveur. N’oubliez pas que vous pouvez exécuter le script bandwidth.sh manuellement à tout moment, vous n’avez pas à attendre que le cronjob le déclenche, bien que vous devriez éviter de l’exécuter manuellement si un cronjob est imminent. Avoir deux scripts s’exécutant simultanément risquerait de perturber les fichiers CSV et ensuite la table SQL.

Si le pire arrive, il y a un fichier CSV de sauvegarde conservé sous /usr/local/etc/speedtest.bak qui devrait contenir toute la sortie CSV de speedtest depuis la première exécution du script bash. Cela pourrait être modifié pour supprimer toutes les entrées indésirables, la table SQL vidée, puis l’ensemble des entrées CSV réimportées dans SQLite.

16 Fuseaux horaires

Speedtest signale l’heure en UTC (c’est essentiellement la même chose que l’heure moyenne de Greenwich ou GMT). Utiliser l’UTC signifie que tous les temps stockés dans la table SQL sont cohérents, et que l’heure d’été n’aura pas d’impact indésirable.

Mais cela signifie que la routine de gestion des erreurs dans bandwidth.sh doit créer un timestamp pour l’entrée fictive pour le refléter. C’est assez simple - nous avons juste inclus le drapeau –utc :

local RIGHTNOW=$(date --utc +%Y-%m-%dT%H:%M:%SZ)

Si vous souhaitez que les étiquettes de l’axe x du graphique affichent des heures autres que UTC/GMT, le meilleur endroit pour effectuer un tel changement serait dans l’instruction SQL SELECT, par exemple :

strftime("%H:%M", time(times, 'localtime')) || " " || strftime("%d/%m/%Y", times) AS timestamp

Cela utiliserait les paramètres de fuseau horaire de votre serveur Linux pour ajuster les heures affichées sur le graphique. Ou vous pourriez plonger pour voir comment Globalize pourrait le faire dans le front-end.

Voir https://www.timeanddate.com/time/gmt-utc-time.html et http://www.tutorialspoint.com/sqlite/sqlite_date_time.htm pour plus d’informations.

17 Étapes supplémentaires et idées

Speedtest n’a pas besoin d’être la source de vos données brutes - cela pourrait venir de n’importe où et être pour n’importe quoi, pas seulement la vitesse Internet. Le principe est le même - un processus serveur backend qui peut obtenir les données brutes dans un format utile et ensuite les importer dans SQLite à partir d’un script bash avec un front-end qui extrait le sous-ensemble de données que vous souhaitez et ensuite le représente graphiquement.

Un script bash plus complexe pourrait écrire des données directement dans une table SQL (en utilisant la commande SQL INSERT) si le formatage en CSV n’est pas une option. Lorsque vous concevez la table SQL, pensez à la façon dont vous souhaiterez extraire les données plus tard.

Lorsque vous apportez des modifications, gardez à l’esprit le contexte du code que vous éditez ; c’est-à-dire que nous avons des instructions SQL à l’intérieur d’un script PHP à l’intérieur de Javascript à l’intérieur de HTML. Rappelez-vous le niveau auquel vous êtes et codez en conséquence. Il peut être facile de perdre le fil et de finir par écrire du code PHP dans ce qui devrait être du Javascript ! Je peux garantir que cela ne fonctionnera pas.

Voici quelques idées pour une exploration plus approfondie :

toLocaleString n’est pas implémenté de manière cohérente dans tous les navigateurs. Utilisez Globalize et gérez tous les formats de nombres, de dates et de fuseaux horaires avec lui.
Consultez httpstat (il existe une version de script bash) qui permet de collecter différents types de données de connexion Internet. Stockez cela dans une (autre) table SQL et représentez la sortie.
Améliorez le front-end bandwidth.php pour donner à l’utilisateur le choix entre différentes options : 24, 48, 72 heures ; sélectionner une date spécifique, inclure les données de téléversement et de téléchargement, les temps de ping.
Convertissez le HTML pour utiliser du code Bootstrap réactif afin qu’il fonctionne bien sur différents appareils ou tailles d’écran.
Explorez certaines des autres options de chart.js ; peut-être un graphique combiné en ligne et à barres ; changez les couleurs et la taille des barres.
remplacez SQLite par MySQL et ajoutez plus de sécurité avec un accès en lecture depuis PHP via utilisateur/mot de passe.
Construisez un système similaire mais en utilisant node.js.

18 Liens

speedtest: https://github.com/sivel/speedtest-cli
SQLite3: https://sqlite.org/
chart.js: http://www.chartjs.org/
Globalize: https://github.com/globalizejs/globalize
httpstat: https://github.com/b4b4r07/httpstat
Bootstrap: http://getbootstrap.com/
PHP: http://www.php.net/
ISPConfig: http://www.ispconfig.org/
Debian: http://www.debian.org/