Vous l’avez compris, la première chose que j’ai voulu faire c’est compléter les « lacunes » de vnStat.
Je dis lacunes avec des guillemets car elles font aussi sa force : le faite de ne pas historiser les données lui permet d’être léger et rapide.

Pour historiser les données il faut :

• lire régulièrement les informations fournis par vnStat
• Extraire les données de la sortie texte
• Remplir une base de données au fur et à mesure.

Concernant la base de données, moi qui suit très à l’aise avec le language SQL, il était évident qu’il s’agirait d’une base de ce type. Concernant le moteur de la base de données, j’ai une très grosse préférence pour Firebird que j’utilise depuis 20 ans :extrêmement fiable et toujours rétro compatible (ce qui n’est pas du tout le fort de MySQL) mais comme je me suis dit qu’il faudrait aussi que la plus part soit à l’aise, j’ai finalement choisis MySQL

Pour l’installation de MySQL, je vous laisse consulter le site officiel, qui est bien documenté sur le sujet, y compris en Français.

Concernant les données à historiser, au début, j’ai fait très simple, comme vnStat ne propose pas un niveau de détail le plus fin suffisant pour permettre des regroupement donnant les données par jour ou par mois, j’ai choisis de faire une table par statistique (donc 3 tables) et une table contenant la liste des utilisateurs du site (qui servira à l’identification des utilisateurs pour la connexion au site de consultation des données) ainsi qu’une dernière contenant la liste des interfaces à surveiller.

MySQL n’aimant pas du tout les clés primaires composites ou ayant un comportement étrange à ce sujet (alors que Firebird le gère très bien), j’ai choisis volontairement de ne pas exprimer les clés étrangères donc pas de relation entre la table des interfaces et les tables statistiques.

Du coup chaque table a sa propre clé primaire sous la forme d’un ID auto généré. Cependant, je voulais exprimer l’unicité d’une ligne pour ne pas générer de doublons, donc j’ai créé des index uniques composites.

Par la suite, cette base de données s’est etoffée  mais on verra cela plus tard.

 

Utilisateurs	Interfaces
CREATE TABLE TBUSER ( IDUSER int(11) NOT NULL AUTO_INCREMENT, PRENOM varchar(32) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL, NOM varchar(32) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL, EMAIL varchar(256) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL, DCRE datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, COPECRE varchar(32) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL, DMAJ datetime DEFAULT NULL, COPEMAJ varchar(32) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL, PASS varchar(32) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL, LASTCONNECT datetime DEFAULT NULL, ISADMIN char(1) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL DEFAULT ‘N’, PRIMARY KEY (IDUSER) ) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8 COLLATE=utf8_bin;	CREATE TABLE TBIFACE ( IFACE varchar(45) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL, DMAJ datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, ACTIF char(1) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL DEFAULT ‘N’, COPEMAJ varchar(256) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL DEFAULT ‘Admin’, PRIMARY KEY (IFACE) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;
Stats Mensuelles	Stats Quotidiennes
CREATE TABLE TBMONTH ( IDMONTH bigint(20) NOT NULL AUTO_INCREMENT, IFACE varchar(45) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL, LASTDAY datetime NOT NULL, RX decimal(24,6) NOT NULL DEFAULT ‘0’, TX decimal(24,6) NOT NULL DEFAULT ‘0’, DMAJ datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (IDMONTH), UNIQUE KEY IX0TBMONTH (IFACE,LASTDAY) ) ENGINE=InnoDB AUTO_INCREMENT=0 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;	CREATE TABLE TBDAY ( IDDAY bigint(20) NOT NULL AUTO_INCREMENT, IFACE varchar(45) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL, DAY datetime NOT NULL, RX decimal(24,6) NOT NULL DEFAULT ‘0’, TX decimal(24,6) NOT NULL DEFAULT ‘0’, MAJ datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (IDDAY), UNIQUE KEY IX0TBDAY (IFACE,DAY) ) ENGINE=InnoDB AUTO_INCREMENT=0 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;
Stats Horaires	Remarques
CREATE TABLE TBHOUR ( IDHOUR bigint(20) NOT NULL AUTO_INCREMENT, IFACE varchar(45) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL, DAY datetime NOT NULL, HOUR int(11) NOT NULL DEFAULT ‘0’, RX decimal(24,6) NOT NULL DEFAULT ‘0’, TX decimal(24,6) NOT NULL DEFAULT ‘0’, DMAJ datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (IDHOUR), UNIQUE KEY IX0TBHOUR (IFACE,DAY,HOUR) ) ENGINE=InnoDB AUTO_INCREMENT=0 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;	Quelques explications : Si vous utilisez MySQL 5.7, remplacez utf8mb4 par utf8 Tout ce qui commence par ID concerne la clé primaire. RX, TX sont les valeurs des quantité de données reçues (RX) et émises (TX). DMAJ, DCRE sont les dates de dernières mises à jour (update) et de création (insert). IFACE désigne le nom de l’interface surveillée. DAY : le jour, LASTDAY : le dernier jour du mois, et HOUR l’heure. J’aurai pu utiliser des valeurs de type DATE au lieu de DATETIME pour les champs DAY et LASTDAY, mais pour assurer une plus grande compatibilité avec les différentes versions de MySQL, j’ai préférer garder des DATETIME. J’aurai pu aussi intégrer l’heure (HOUR) dans le DATETIME « DAY » mis pour une plus grande faciliter de réalisation des requêtes de consultation au sein du site, j’ai préféré les séparer. Les indexes uniques (UNIQUE KEY), vont me permettre de m’assurer qu’aucun traitement ne fera de doublons. Pour la statistiques mensuelles, j’aurai pu utiliser un numéro de mois au lieu du dernier jour du mois (LASTDAY), mais j’ai choisis cette solution en pensant déjà au développement du site. J’ai toujours pris l’habitude de faire mon code SQL (et seulement lui) en majuscules car ainsi il ressort du reste du code lorsque je me relis. Attention : par défaut, MySQL est sensible à la casse (grrrrr !)