Suite à un ensemble de problèmes de mauvaise connectivité haut débit que je rencontrais, j'ai décidé de surveiller régulièrement la vitesse Mbps que je recevais de mon fournisseur. Je voyais des chiffres particulièrement médiocres 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 assis dans un coin, qui est ma machine de test et de développement pour les sites Web hébergés par ISPConfig, ainsi que du code Let's Encrypt avec lequel j'aime jouer, j'ai donc cherché un logiciel qui permettrait de tester la bande passante, exécutable à partir d'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 simplifier les requêtes (je pourrais alors facilement collecter plus de données et simplement extraire un sous-ensemble plus petit pour les périodes 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 très utile d'Antonio Valencia sur :https://www.howtoforge.com/tutorial/check-internet-speed-with-speedtest-cli-on-ubuntu/
Après avoir suivi les instructions pour installer speedtest, une lecture rapide a montré que je pouvais l'utiliser pour exécuter des tests sur un large ensemble de serveurs Internet et également produire une sortie au format CSV, ce qui convient parfaitement pour être importé directement dans une table SQL avec le minimum d'effort dans le développement de logiciels.
Pour la quantité relativement faible de données qui seraient générées, j'ai décidé d'utiliser SQLite comme magasin principal et une recherche rapide des bibliothèques graphiques open-source basées sur javascript m'a conduit à chart.js, qui a un design simple et propre. avec une interface de données simple mais une grande capacité à modifier les options avancées si nécessaire. Convertir des données SQL pour extraire uniquement le sous-ensemble de données que je voulais représenter graphiquement avec une sortie via JSON via 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 speedtest 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 obtenus en Mbps pour les 24 heures précédentes (ou toute autre période que je pourrais décider).
Une petite expérience 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 correspondaient étroitement au type de vitesse que je connaissais. J'ai considéré que c'était une bonne idée de tester sur 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 le test de vitesse à utiliser 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 pouvez gérer avec juste un serveur Web, avec quelques modifications mineures aux instructions suivantes)
- PHP :j'utilise la version 7.0, mais cela devrait également fonctionner avec la plupart des versions précédentes
- 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 vous déplacer dans les répertoires, la disposition de l'endroit où votre serveur Web s'attend à ce que les fichiers se trouvent et comment envoyer des fichiers FTP vers ces répertoires.
Voici les étapes détaillées pour vous permettre de configurer tout cela.
2 Installer le test de vitesse
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'informations si vous avez des problèmes.
Remarque :speedtest et speedtest-cli sont identiques sur mon installation, je ferai donc 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 une bande passante.sh
Entrez le code de script bash suivant dans un fichier et enregistrez-le sous /usr/local/etc/bandwidth.sh - nous le modifierons un peu plus tard pour le rendre spécifique pour vous.
#!/bin/bash# exécutez des tests de vitesse sur 3 serveurs et enregistrez tous les résultats de sortie dans un fichier CSV pour l'importation dans la base de données sqlite## exécuté par cronjob une fois par heure##function getCSVString () { # si le test de vitesse a échoué (par exemple, il n'a pas pu accéder à un serveur) nous devons créer une entrée factice zéro pour ce créneau horaire # obtenir une chaîne d'horodatage dans le même format que speedtest génère - et nous avons besoin de l'heure UTC locale RIGHTNOW=$(date --utc +%Y- %m-%dT%H:%M:%SZ) # sur 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 le test de vitesse sur le serveur nommé avec la sortie csv enregistrée dans le 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 zéro à la place de tout message d'erreur getCSVString $1> /usr/local/etc/speedtest.tmp fi # enregistrez la sortie prête pour le prochain test de serveur cat /usr/local/etc/speedtest .tmp>
> /usr/local/etc/speedtest.csv}# main######## exécutez le test de vitesse sur 3 serveurs et enregistrez tous les résultats de sortie dans le fichier csvcd /usr/local/etc# clear csv file - needs être vide au démarrage de runrm -f /usr/local/etc/speedtest.csv############################### ############## cas de test/débogage - force l'échec du test de vitesse########################### ################## runTest "199999999"# sleep 5####### commenter après le test ############## #########################################runTest "5443" veille 10runTest "1234" veille 10runTest "1783" sleep 1# importe maintenant les données csv dans sqlite dbsqlite3 -batch /usr/local/etc/bandwidth.db <<"EOF".separator ",".import /usr/local/etc/speedtest.csv bande passanteEOF # ajouter le csv en cours d'exécution à backupcat /usr/local/etc/speedtest.csv>> /usr/local/etc/speedtest.bak
Je m'excuse pour mon approche "ceinture et bretelles" consistant à utiliser des chemins complets pour les fichiers partout, même lorsqu'ils ne sont pas nécessaires. C'est juste la façon dont j'aime le faire. N'hésitez pas à l'améliorer 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 bande passante.sh
5 Créer une base de données SQLite
Créez la base de données SQLite de la bande passante.db dans /usr/local/etc :
#sqlite3 bande passante.db
puis, à l'invite sqlite>, créez une nouvelle table avec la commande suivante (ne manquez pas le dernier point-virgule) :
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> .quitter
Cela crée une table appelée bande passante avec des champs qui correspondent directement à la sortie au format CSV de speedtest.
6 Obtenir une liste de serveurs
Vous aurez besoin d'une liste des serveurs utilisés par speedtest.
# speedtest --list> serveurs.txt
Vérifiez maintenant via servers.txt les identifiants numériques du ou des serveurs sur lesquels vous souhaitez exécuter vos tests.
# nano serveurs.txt
Le fichier ressemblera à ceci :
Récupération de la configuration de 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 de serveur 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 qu'il soit trop précis et qu'il puisse changer d'une course à l'autre. Les serveurs de test seront répertoriés dans l'ordre de cette distance en commençant par le plus proche. Les tests sur les serveurs situés en haut de cette liste devraient, en théorie, vous donner les pings les plus rapides et les meilleures vitesses de téléchargement et de téléchargement par rapport aux serveurs situés en bas de la liste qui sont beaucoup plus éloignés.
7 Sélectionner les identifiants de serveur et modifier la bande passante.sh
Il serait maintenant temps d'exécuter manuellement le test de vitesse sur une sélection des différents identifiants de serveur disponibles et de voir le type de résultats que vous obtenez. J'ai choisi quelques serveurs près de chez moi au Royaume-Uni et un en Californie à titre de comparaison. Le format de la commande à utiliser est :
# speedtest --server 1234
La sortie que vous voyez ressemblera à :
Récupération de la configuration de speedtest.net...Test de xxxxxxx (n.n.n.n)...Récupération de la liste des serveurs de speedtest.net...Sélection du meilleur serveur en fonction du ping...Hébergé par Uno (Milton Keynes) [187,87 km] :33.243 msTest de la vitesse de téléchargement.......................................... ..................................Téléchargement :1,60 Mbit/sTest de vitesse de téléchargement..... .................................................. .....................................Téléchargement :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 les modifier si vous le souhaitez) dans les lignes correspondantes de la bande passante.sh
runTest "5443"dormir 10runTest "1234"dormir 10runTest "1783"dormir 1
Vous devrez également ajuster le code dans la routine d'erreur qui crée une entrée factice si le test de vitesse échoue lors d'une exécution particulière.
# sur 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 nombres après $RIGHTNOW (par exemple 73,09) sont les distances en kilomètres entre votre emplacement et le serveur en question. Je ne les utilise nulle part, ils ne sont donc qu'un espace réservé et peuvent être n'importe quelle valeur numérique.
Notez avec cet exemple 1783 que nous devons mettre des guillemets sur l'emplacement et les échapper afin de les intégrer dans le fichier CSV que nous créons. Les guillemets sont obligatoires ici car cet emplacement contient une virgule. Sans les guillemets échappés, la virgule serait traitée comme un délimiteur de champ CSV, ce qui causerait 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 une tâche cron
Configurez une tâche cron pour qu'elle s'exécute 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 une tâche cron.
Alternativement, sur la ligne de commande Linux, vous pouvez saisir :
# 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 | pendant la lecture de la ligne ; faites echo `/bin/date` "$line">> /var/log/ispconfig/cron.log ; done* * * * * /usr/local/ispconfig/server/cron.sh 2>&1 | pendant la lecture de la ligne ; faites echo `/bin/date` "$line">> /var/log/ispconfig/cron.log ; done1 * * * * /usr/local/etc/bandwidth.sh 2>&1
Si vous n'exécutez pas ISPConfig, il se peut qu'il soit initialement vide. Ajoutez cette dernière ligne exactement comme indiqué ci-dessus - l'espacement est important - pour exécuter le script shell à partir de 00h01, puis répéter toutes les heures, tous les jours. Vous pouvez bien sûr choisir des horaires différents. (La toute première fois que vous exécutez ceci, 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 PHP open_basedir pour le site Web. Dans ISPConfig, cela se trouve dans l'onglet Options du site Web.
Cela permet au code de la bande passante.php d'accéder à la base de données SQLite, que nous venons de créer, dans ce répertoire.
Nous aurions pu ignorer 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 du point de vue de la sécurité .
10 Créer une bande passante.php
Vous devez copier ce code dans un fichier nommé bande passante.php sur votre serveur dans le répertoire du document Web de base. Si vous utilisez ISPConfig, ce sera quelque chose comme /var/www/clients/client1/web1/web/
Moniteur de bande passante - vitesses de téléchargement au cours des dernières 24 heures Vitesse de téléchargement - dernières 24 heures
Modifiez ce fichier pour utiliser l'ID de serveur sur lequel vous souhaitez créer un 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 en Mbps plus étroitement alignés sur les vitesses que je sentais obtenir. L'ID de serveur se trouve dans la clause WHERE de l'instruction SQL SELECT :
SELECT serverid, strftime("%H:%M", fois) || " " || strftime("%d/%m/%Y", fois) Horodatage AS, sponsor, nom de serveur,
téléchargement
Bande passante DEPUIS
WHERE serverid =1234
ORDER BY fois
LIMITER 24 OFFSET (SELECT COUNT(*)/3 FROM bande passante)-24 ;
Que fait exactement cette instruction SQL ? Si vous n'êtes pas familier avec SQL, examinons chaque partie.
un. SELECT est la commande pour lire les enregistrements d'une table de base de données SQL et est suivie des champs à lire et d'autres options.
b. strftime("%H:%M", fois) || " " || strftime("%d/%m/%Y", fois) Horodatage AS
est de 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 transformera 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 heures ici seront UTC/GMT, ce qui me convient, mais vous voudrez peut-être changer cela ; par exemple. si vous voulez des dates au format américain, remplacez cette deuxième partie par 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.
ré. FROM bande passante 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 - modifiez-le pour qu'il corresponde à l'ID de serveur que vous avez utilisé, et vous voudrez peut-être lire les données de plusieurs serveurs - mais cela compliquera le graphique.
F. ORDER BY times définit l'ordre de tri de la sortie - nous voulons qu'il soit trié par l'horodatage défini par speedtest 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 configuré pour s'exécuter une fois par heure. Si vous couriez deux fois par heure, vous devrez le régler sur 48 pour obtenir 24 heures de données.
h. OFFSET (SELECT COUNT(*)/3 FROM bande passante)-24 ; nous voulons les 24 derniers enregistrements de la table car ce sont les entrées les plus récentes qui nous intéressent, nous devons donc spécifier un OFFSET pour correspondre à la LIMITE. Sans cela, nous obtiendrions toujours les 24 premiers enregistrements de la table plutôt que les 24 plus récents. Pour obtenir le bon décalage, nous comptons tous les enregistrements de la table avec (SELECT COUNT (*)) puis divisons par 3 (car nous exécutons speedtest 3 fois par heure, une fois pour chacun des 3 serveurs différents) puis soustrayons 24 à partir de ce total pour obtenir la bonne position OFFSET afin que LIMIT 24 obtienne ensuite les enregistrements que nous voulons.
Si vous avez modifié le script bash pour exécuter autre chose que 3 tests de serveur différents par heure, ajustez cette partie /3 en conséquence. Si vous testez uniquement sur un serveur, la division n'est pas du tout nécessaire.
Vous pouvez également ajuster la taille globale du graphique, où j'ai pris la voie facile de coder en dur 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 de bibliothèque css et js (mais pas des polices Google) qui sont nécessaires dans une page Web et si vous êtes le même, vous devrez obtenir une copie sur votre serveur de Chart.bundle.min. js et placez-le dans le répertoire /var/www/clients/client1/web1/web/scripts sur votre serveur (ou dans 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 bandeau.php pour pointer vers la version CDN publique à la place. Modifiez simplement 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é défini.
13 Charger la bande passante.php dans le navigateur
Nous avons enfin terminé. Une fois que le script shell de la bande passante.sh a eu le temps de s'exécuter plusieurs fois pour générer des données (ou vous pouvez l'exécuter manuellement plusieurs fois au début), pointez votre navigateur sur le site Web de votre serveur Linux, chargez la bande passante.php et vous devriez voir quelque chose comme ceci :
Et oui, mon haut débit est vraiment si mauvais !
Enfin, voici quelques points supplémentaires à couvrir :
Sortie de 14 graphiques à barres
Nous devons noter que les chiffres de téléchargement et de téléchargement stockés dans la table SQL sont en bps plutôt qu'en Mbps (avec un nombre ahurissant 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 la sortie de l'axe des ordonnées du graphique à barres, il y a quelques lignes incluses dans le code Javascript dans la bande passante.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 doit insérer la ponctuation de base décimale correcte (un "." ou ",") telle que définie par les paramètres régionaux de votre navigateur, mais cela dépend de l'implémentation et quelque peu incohérent. Si tu vois . au lieu de , et cela vous ennuie alors Globalize est le moyen de résoudre ce problème. Voir '18 étapes et idées supplémentaires' ci-dessous.
Quelques lignes supplémentaires sont nécessaires pour remplacer le traitement par défaut du code de survol des zéros de fin, car chart.js affichera normalement "2.000" comme juste "2", ce qui n'est pas ce que je veux, surtout après m'être donné la peine de s'assurer qu'ils sont là en premier lieu :
// nous remplaçons l'infobulle par défaut qui supprime les zéros à la fin même si nous les y avons déjà insérés :{ callbacks :{ label:function(tooltipItem, data) { var value =data.datasets[0].data[ tooltipItem.index] ; var label ='télécharger :'; var retvalue =value.toLocaleString(undefined, { minimumFractionDigits :3 }); étiquette de retour + ' ' + retvalue + ' Mbps' ; } } },
Ceci est un bel exemple de la façon dont vous pouvez "explorer" chart.js et changer la façon dont il fait les choses.
De plus, j'ai défini les options du graphique pour imprimer l'horodatage sur l'axe des x pour chaque barre :
xAxes :[{ ticks :{ autoSkip :false, maxTicksLimit :24 }
L'option par défaut (avec autoSkip défini sur true) a entraîné quelques lacunes étranges dans les étiquettes. Vous devrez modifier 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 pouvez pas obtenir ce que vous voulez, veuillez consulter les pages spécifiques de chart.js Stack Overflow - il y a beaucoup d'informations utiles là-bas - https://stackoverflow .com/questions/tagged/chart.js - Utilisez simplement le champ de recherche pour affiner ce que vous recherchez. Malheureusement, la documentation de chart.js manque de certains des exemples les plus avancés qui seraient certainement d'une grande aide pour se familiariser avec l'utilisation de ce formidable morceau de code open source.
15 Gestion des erreurs
Au cours de mes premiers tests, j'ai remarqué à plusieurs reprises que speedtest signalait "Impossible de récupérer la liste des serveurs de speedtest" dans le fichier CSV. Vraisemblablement, cela reflétait les moments où ma connexion haut débit était si mauvaise que speedtest ne pouvait pas du tout 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, j'avais donc besoin d'une solution à cela qui supprimerait à la fois ce texte indésirable du fichier CSV et inclurait également une entrée zéro 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 annulerait également l'alignement que je voulais d'avoir 24 entrées par jour lors de la création du graphique.
Vous verrez dans la bande passante.sh que le script teste le code de sortie défini par speedtest en utilisant la variable de script $? et s'il est supérieur à zéro, cela indique que le test de vitesse a échoué. Cela déclenchera la fonction pour créer une entrée CSV factice - 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 de zéro factice si vous exécutez le script après avoir décommenté ces lignes.
#############################################test/ cas de débogage - force le test de vitesse à échouer########################################## ## runTest "199999999"# sleep 5####### commenter après le test ############################## ########################
Cela utilise un identifiant de serveur `` absurde '' que speedtest n'aime pas, ce qui lui fait renvoyer un code de sortie non nul. Le script devrait alors créer une entrée factice qui peut rester dans la table SQL et être ignorée ou vous pouvez la supprimer.
Une autre façon de forcer l'échec du test de vitesse, à des fins de test, serait de supprimer la connexion réseau du serveur. N'oubliez pas que vous pouvez exécuter le script width.sh manuellement à tout moment, vous n'avez pas besoin d'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 exécutés simultanément risquerait de gâcher les fichiers CSV, puis la table SQL.
Si le pire se produit, il existe un fichier CSV de sauvegarde conservé sous /usr/local/etc/speedtest.bak qui doit contenir toute la sortie CSV de speedtest à partir de la première exécution du script bash. Cela pourrait être modifié pour supprimer l'une des entrées indésirables, la table SQL effacée, puis l'ensemble des entrées CSV réimportées dans SQLite.
16 fuseaux horaires
Speedtest rapporte l'heure en UTC (essentiellement, c'est la même chose que l'heure moyenne de Greenwich ou GMT). L'utilisation de l'UTC signifie que toutes les heures stockées dans la table SQL sont cohérentes et que l'heure d'été n'aura aucun impact indésirable.
Mais cela signifie que la routine de gestion des erreurs dans la bande passante.sh doit créer un horodatage pour que l'entrée factice reflète cela. 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 des abscisses du graphique affichent les heures autrement que UTC/GMT, le meilleur endroit pour effectuer une telle modification serait dans l'instruction SQL SELECT, par exemple :
strftime("%H:%M", time(times, 'localtime')) || " " || strftime("%d/%m/%Y", fois) Horodatage AS
Cela utiliserait les paramètres de fuseau horaire de votre serveur Linux pour ajuster les heures affichées sur le graphique. Ou vous pouvez plonger pour comprendre comment Globalize pourrait faire cela 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 et idées supplémentaires
Speedtest n'a pas besoin d'être la source de vos données brutes - elles peuvent provenir de n'importe où et être pour n'importe quoi, pas seulement la vitesse d'Internet. Le principe est le même - un processus de serveur principal qui peut obtenir les données brutes dans un format utile, puis les importer dans SQLite à partir d'un script bash avec un frontal qui extrait le sous-ensemble de données souhaité, puis le trace.
Un script bash plus complexe pourrait écrire des données directement dans une table SQL (à l'aide de la commande SQL INSERT) si le formatage en CSV n'est pas une option. Lorsque vous concevez la table SQL, réfléchissez à la manière dont vous souhaiterez peut-être extraire les données ultérieurement.
Lorsque vous apportez des modifications, gardez à l'esprit le contexte du code que vous modifiez ; c'est-à-dire que nous avons des instructions SQL dans le script PHP à l'intérieur de Javascript à l'intérieur de HTML. Souvenez-vous du niveau auquel vous vous trouvez 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 nombre, de date et de fuseau horaire avec.
- Checkout httpstat (il existe une version de script bash) qui permet de collecter différents types de données de connexion Internet. Stockez ceci dans une table SQL (séparée) et représentez le résultat sous forme de graphique.
- Améliorer l'interface bandeau.php pour donner à l'utilisateur le choix entre différentes options :24, 48, 72 heures ; sélectionnez une date spécifique, incluez les données de chargement et de téléchargement, les temps de ping.
- Convertissez le code HTML pour utiliser du code Bootstrap réactif afin qu'il s'exécute correctement sur différents appareils ou tailles d'écran.
- Explorez certaines des autres options de chart.js ; peut-être un graphique linéaire et à barres combiné ; modifier 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.
- Créer un système similaire mais en utilisant node.js.
18 liens
- test de vitesse :https://github.com/sivel/speedtest-cli
- SQLite3 :https://sqlite.org/
- chart.js :http://www.chartjs.org/
- Globaliser :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/