Vous êtes tombés sur cette so famous carte et – horreur ! – vous n'y figurez pas alors que votre QoQ-CoT est up and running !

Vous voulez, et c'est pleinement légitime, que cesse immédiatement cet injuste anonymat.

Facile : postez un message (“Commencer une nouvelle discussion”) dans le forum « Poulailler » du projet sur SourceSup, en indiquant votre établissement, le nombre de postes concernés et toutes autres infos/cris/cocoricos de joie que vous jugerez utiles. D'une, vous apparaîtrez sur la carte (et ça, c'est la classe à Dallas ! et de deux, ça nous permettra de mieux connaître et de communiquer plus directement avec les utilisateurs de la solution (nouvelles features, évolutions, bugs…). Merci

a. Télécharger la dernière version sur SourceSup : https://sourcesup.renater.fr/projects/qoq-cot/

• pour les versions stables : onglet Fichiers
• pour la version en cours de développement, via git : commande git clone https://git.renater.fr/anonscm/git/qoq-cot/qoq-cot.git. ATTENTION : on le répète, c'est une version en cours de développement sur laquelle nous ne nous engageons pas et qui par définition peut comporter des fonctions non finalisées, voire, ayons le courage de le dire ici, des erreurs ou même des bugs…

b. À partir de la version 3.1 Commandant Poulard, consulter la section consacrée à votre version dans le guide d'install/upgrade
Pour les versions précédentes, décompresser l'archive récupérée et suivre les informations indiquées dans le fichier qoq-cot/ressources/doc/INSTALL/INSTALL.TXT

Sommaire

a. Télécharger la dernière version sur SourceSup : https://sourcesup.renater.fr/projects/qoq-cot/

• pour les versions stables : onglet Fichiers
• pour la version en cours de développement, via git : commande git clone https://git.renater.fr/anonscm/git/qoq-cot/qoq-cot.git. ATTENTION : on le répète, c'est une version en cours de développement sur laquelle nous ne nous engageons pas et qui par définition peut comporter des fonctions non finalisées, voire, ayons le courage de le dire ici, des erreurs ou même des bugs…

b. À partir de la version 3.1 Commandant Poulard, consulter la section consacrée à votre version dans le guide d'install/upgrade
Pour les versions précédentes, décompresser l'archive récupérée et suivre les informations indiquées dans le fichier qoq-cot/ressources/UPGRADE_FROM_PREVIOUS_VERSIONS/UPGRADE_FROM_PREVIOUS_VERSIONS.txt

Sommaire

En premier lieu, si l'on est dans une version inférieure, upgrader en v4.0 Rocky

Alors, posons le problème et les forces en présence.

On a au départ :

• N sites
• pour chacun des sites
  • une interface web (IW) 4.0
  • une base de données (DB) 4.0
  • 1 coq 4.0
  • sur toutes les machines du site, des poussins 4.0 qui remontent leurs infos de connexions au coq 4.0

On veut à la fin :

• N sites
• une seule IW 5.0
• une seule base de données (db) 5.0
• un seul coq 5.0
• sur toutes les machines de tous les sites, des poussins qui remontent leurs infos de connexions au coq 5.0

Trop facile. On y va :

1. Faites une "Fresh install" 5.0 Mac Bec : les sites, les salles et les machines sont déclarés pendant cette phase
2. Modifiez les confs des coqs 4.0 (fichier coq.yml) de façon à ce qu'ils écrivent désormais dans la DB 5.0 et relancez-les
3. Supprimez la colonne idProcesss dans les tables Connexions des DB 4.0
4. Dumpez les connexions de chaque db 4.0 en omettant l'id unique iDConnexion

   • mysqldump -p --insert-ignore --no-create-info -c qoqcot Connexions | grep "^INSERT" | sed 's/
     0073dConnexion
     0044//' | sed "s/([0-9]*,/(/g"

   • À partir de là, les DB 4.0 ne servent plus à rien… mais gardez-les encore un peu, au moins jusqu'à la stabilisation complète de votre nouvelle install.
5. Insérez les connexions dumpées dans la table Connexions de la DB 5.0
6. Installez le coq 5.0
7. Déployez à votre rythme les poussins 5.0 à la place des poussins 4.0
8. Quand vous n'avez plus de poussins 4.0, arrêtez les coqs 4.0 et coupez l'accès aux IW 4.0.

On traite ici à la fois 2 situations possibles :

• un QoQ-CoT 4.0 avec toutes les machines de tous les sites (mais sans possibilité de les visualiser séparément par site dans l'interface, puisqu'elle ne sait pas le faire…) vers un 5.0 avec les mêmes machines, mais réparties par sites
• un QoQ-CoT 4.0 avec toutes les machines d'un site ou de plusieurs sites vers un 5.0 avec toutes les machines du 4.0 PLUS celles d'autres nouveaux sites qu'on va intégrer en profitant de l'upgrade.

À nouveau, posons le problème et les forces en présence.

On a au départ :

• 1 site¹⁾
• une interface web (IW) 4.0
• une base de données (DB) 4.0
• 1 coq 4.0
• sur toutes les machines du site, des poussins 4.0 qui remontent leurs infos de connexions aux coqs 4.0

On veut à la fin :

• N sites
• une IW 5.0 issue de l'upgrade de la 4.0
• une base de données (db) 5.0 issue de l'upgrade de la 4.0
• un coq 5.0
• sur toutes les machines de tous les sites, des poussins 5.0 qui remontent leurs infos de connexions au coq 5.0

So easy, en bien moins que 10 points :

1. Upgradez votre Rocky 4 en Mac Bec 5
2. Modifiez la conf du coq 4.0 (fichier coq.yml) de façon à ce qu'il écrive désormais dans la DB 5.0 et relancez-le
3. Exportez vos salles et vos machines en utilisant export_salles_to_csv.php > /chemin/vers/mon/fichier.csv.
4. Videz les tables Salles et MachinesToSalles
5. Déclarez vos sites dans config.php, constante SITES (voir cette section du guide d'install)
6. Importez vos salles et machines pour chaque site avec la commande : php setup.php /chemin/vers/le/fichier.csv/du/site nom_du_site, où nom_du_site doit être un des noms figurant dans la liste de sites SITES de votre config.php (vous aurez constitué vos différents fichiers de sites à partir de l'export fait plus haut, avec éventuellement l'ajout d'autres machines/salles issus de sites qui n'étaient pas gérés par votre QoQ-CoT 4.0)
7. Installez les poussins 5. sur vos éventuelles nouvelles machines surveillées et migrez à votre rythme les poussins 5.0 à la place des poussins 4.0 sur votre parc déjà surveillé en 4.0
8. Quand vous n'avez plus de poussins 4.0, arrêtez les coqs 4.0 et coupez l'accès aux IW 4.0.

Et voilà, vous pouvez visualiser vos machines et salles par site, aussi bien dans le suivi de connexions que pour chaque graphe !

Sommaire

Il s'est passé suffisamment de choses entre la v2 et la v3 pour mériter une (grosse) entrée de FAQ…

Nous devons l'avouer ici, cette question de forum nous a provoqué une certaine montée d'angoisse quand nous avons compris qu'elle allait poser le même problème à TOUS les QoQ-CoTeurs qui avaient upgradé de v2 vers v3.0…

Le problème, assez simple, est le suivant :

• noms « longs » en QoQ-CoT < v3.0, mode rsyslog+peuplade.php
  • en QoQ-CoT < v3.0, le nom utilisé pour enregistrer les connexions des machines est le nom « long », ou FQDN, soit toto.domaine.org. Plus exactement, c'est le champ NomMachine de la table MachinesToSalles, tel que vous l'avez renseigné dans le fichier .csv donné en entrée à setup.php : pour chaque ligne du fichier définissant une machine, le premier élément de la ligne, dans lequel il vous est demandé de renseigner le nom long (FQDN) de la machine, est utilisé pour remplir le champ NomMachine, tandis que le second, dans lequel il vous est demandé de renseigner le nom NetBios (ou nom court) de la machine nourrit, lui, le champ… NomNetBios
    Que les clients remontent, dans les informations de connexions, le nom long ou le nom court, le script peuplade.php, qui assure l'insertion dans la table Connexions, met à profit l'association nom long/nom court enregistrée dans MachinesToSalles, pour toujours utiliser le nom long, le substituant si besoin au nom court avant insertion. Bref, les seuls noms apparaissant dans la table Connexions sont les noms longs, si bien que les toutes les connexions que QoQ-CoT peut exploiter au travers de l'interface de suivi des connexions ou des graphes sont associées aux noms longs des machines… Pour résumer : dans la table Connexions, NomMachine est renseigné avec le nom long.
• noms courts en QoQ-CoT >= v3.0, mode poussin/coq
  • en mode poussin/coq, c.-à-d. en QoQ-CoT >= v3.0, les poussins utilisent exclusivement les nom courts, soit toto pour la machine toto.domaine.org. Ils envoient les données de connexion avec les noms courts au coq, qui les inscrit sous cette forme dans la base… Pour résumer, dans la table Connexions, NomMachine est renseigné avec le nom court.

Bien me direz-vous, et alors ?

Alors, il y a 2 cas où cette situation ne pose pas de problèmes :

• vous restez en v2.0 sans upgrader : il n'y a que des noms longs dans vos données, ça roule ;
• votre installation de la version 3.x est votre première installation et ne résulte pas d'un upgrade depuis une version <3.0 : il n'y a que des noms courts dans votre base, parfait, ciel bleu sans nuage.

Puis il y le cas à problème : vous avez upgradé une version <3.0 vers une version >3.0 et vous comptez bien garder toutes les données de connexion récoltées à la sueur de votre CPU pendant des années…

Voici ce qui se passe alors :

• Ouf, pas de problème de perte de données : toutes vos connexions sont bien enregistrées dans la table Connexions, les nouvelles issues des poussins, appelons-les C_new, les anciennes issues de votre historique, soit C_old, et enfin les nouvelles issues des clients rsyslog non encore migrés qui viennent nourrir aussi votre base v3.0, soit C_new_but_old ;
• mais un vrai problème de nommage : toutes les connexions C_new sont enregistrées dans la table Connexions avec des noms de machines courts, tandis que C_old et C_new_but_old le sont avec des noms longs.

Bon, et alors quoi à la fin !!!

On y vient. Dans votre base il est indiqué, depuis votre première installation de QoQ-CoT en version < 3.0, que la salle hardgamers contient les machines de noms longs lol.cool.biz, pacman.cool.biz, scramble.cool.biz et existenz.cool.biz. Avec la version 3.0 (ou 3.1), vous êtes passé en mode poussin/coq pour lol.cool.biz, pacman.cool.biz, scramble.cool.biz, tandis que existenz.cool.biz est pour l'instant restée en mode rsyslog+peuplade.php.

Donc, quand vous demandez à QoQ-CoT de vous tracer un graphe quelconque au sujet de la salle hardgamers, il va requêter la tables Connexions pour trouver toutes les connexions existantes pour lesquelles le champ NomMachine est lol.cool.biz, pacman.cool.biz, scramble.cool.biz et existenz.cool.biz.

Et il n'y aura donc aucune trace, dans ce graphe, de toutes les connexions ultérieures au passage en mode poussin/coq de lol.cool.biz, pacman.cool.biz, scramble.cool.biz… En effet, dès le passage en mode poussin/coq, les connexions insérées dans la table Connexions pour ces machines le sont avec les noms lol, pacman, scramble et ne sortiront donc pas avec des requêtes portant sur lol.cool.biz, pacman.cool.biz, scramble.cool.biz²⁾.

Par contre vous verrez les connexions de existenz.cool.biz, qui remonte toujours en nom long puisqu'elle est resté en mode rsyslog+peuplade.php.

Conséquence : le taux d'utilisation pour la salle exhibé par le graphe va sembler très fortement diminuer après l'upgrade puisqu'il ne comptabilisera pour cette salle que les connexions d'existenz.cool.biz !!!

Et vous serez exposé, vous l'aurez compris, à la même erreur de mesure sur tous les graphes concernant la salle hardgamers ou les machines qu'elle contient…

Sommaire

Notons immédiatement que l'idée qui vient à l'esprit immédiatement, soit rejouer le setup en modifiant dans le fichier d'entrée les noms de machines longs en noms courts, est une mauvaise idée. Comme c'est très souvent le cas avec les idées-qui-viennent-immédiatement-à-l'esprit…

En effet, on ne va faire qu'inverser le problème : cette fois, quand vous demanderez à QoQ-CoT de vous tracer un graphe quelconque au sujet de la salle hardgamers, il va requêter la base pour trouver toutes les connexions existantes pour lesquelles le nom de la machine est lol, pacman, scramble ou existenz.

Alors oui, vous allez voir sur le graphe toutes les nouvelles connexions ultérieures à l'upgrade en mode poussin/coq. Super ! Mais vous ne verrez plus celles d'avant (la requête cherche des noms courts et elles sont enregistrées en noms longs) ni celles d'existenz.cool.biz qui sont toutes enregistrées en sous son nom long…

Caramba, encore raté !

Sommaire

La « vraie » solution consiste à ne reposer que sur un seul type de noms. Nous avons choisi pour vous, ça sera les courts³⁾. Pourquoi ? Parce qu'être sûr à 100% de récupérer un nom long en interrogeant la machine depuis le poussin s'est avéré trop dépendant de l'environnement spécifique de la machine et donc dommageable pour la robustesse de la solution…

Dans l'archive de la version 3.1 Commandant Poulard réside un script magique au nom effrayant autant qu'explicite : ressources/UPGRADE_FROM_PREVIOUS_VERSIONS/ModifieDBV2toV3.sh.

Il fait plein de chose, dont entre autres la « raccourcissation » : il va transformer tous les noms longs des tables Connexions et MachinesToSalles en noms courts, rendant aisni votre base homogène.

Pour l'exécuter, le mieux est de suivre la procédure parfaitement documentée dans le guide d'upgrade vers la version 3.1, précisément dans les cas A2 (upgrade de 3.0 à 3.1 quand la 3.0 vient d'un upgrade de 2.0) ou A3 (upgrade direct de 2.0 à 3.1).

Si vous avez suivi, vous aurez compris que le problème n'est pas encore complètement réglé : en effet, les données en base sont OK après exécution du script MAIS si on ne fait rien d'autre, tous les clients encore en mode rsyslog vont continuer d'alimenter la base avec des connexions « noms longs »…

Nous y avons pensé : la procédure d'upgrade (qu'il vous faut absolument suivre avec une application religieuse) indique qu'il ne faut SURTOUT pas oublier de remplacer votre ancien script peuplade.php par sa nouvelle version 3.1, qui, à l'inverse des versions précédentes, utilisera toujours les noms courts pour insérer dans la table Connexions (en raccourcissant à la volée le nom pour toute connexion qui remonte depuis un client rsyslog avec un nom long). On aura ainsi l'assurance de garder une base entièrement cohérente, que les données remontent via les poussins ou les vieux clients rsyslog.

Un QoQ-CoTeur circonspect et assez remonté a tenu ici à s'exprimer dans la FAQ :

« Ouais, ouais, peut-être, mais ne triomphez pas trop vite. Avec votre choix de noms courts, je vois 2 gros problèmes :

• le double boot
  • auparavant, les 2 noms (NomMachine et NomNetBios) étaient associés à une machine (dans la table MachinesToSalles) à partir du fichier donné en entrée au setup.
    Dès lors, QoQ-CoT savait automatiquement unifier dans la base les connexions remontées avec le nom long (champ NomMachine de MachinesToSalles) ou le nom court (champ NomNetBios de MachinesToSalles).
    Ceci était assuré par le script peuplade.php, responsable de l'insertion des connexions dans la table Connexions. Que la connexion remonte avec le nom long ou le nom court, peuplade.php l'insérait dans la table Connexions avec le champ NomMachine renseigné avec le nom long.
    C'était très pratique pour gérer le double boot, où un OS pouvait remonter un nom court et l'autre le nom long : avec l'unification des connexions, le taux d'utilisation de la machine était calculé correctement, c'est-à-dire indépendamment de l'OS utilisé.
    De même, si la machine n'avait pas le même nom DNS sous chaque OS, on pouvait utiliser les 2 champs pour associer les 2 différents noms, un petit bricolage très pratique…
    Avec le seul nom court associé à une machine, comment va-t-on pouvoir gérer l'unification des noms potentiellement différents selon l'OS dans le cas d'un multi boot ??!!!
• le multi-domaines
  • Inversement, si on surveille des machines de plusieurs domaines, comment gère-t-on le cas de machines distinctes mais ayant le même nom court, par exemple toto.chicken.org et toto.fried.chicken.org, qui doivent être vues différemment par QoQ-CoT ???

Alors, les rigolos à l'accent du Sud, maintenant qu'on ne dispose que du nom court, on fait comment, nous !!!??? »

Du calme, on a pensé à vous aussi, chers amis bricolos ou grands propriétaires multi-domaines dans le Kentucky. Dans la configuration du poussin, le fichier poussin.yml, nous avons ajouté le champ hostname, qui peut être renseigné ou non. S'il est renseigné, c'est sa valeur que le poussin va utiliser comme nom de machine. Sinon, c'est le nom court tel qu'il est défini dans le système (« hostname » sous linux, « Nom de l'ordinateur » sous Windows…). Ceci permet donc, en renseignant ce champ sur un des 2 OS du double boot, de pouvoir remonter des connexions au même nom pour cette machine quel que soit l'OS utilisé⁴⁾. Ou inversement de différencier facilement des machines distinctes mais ayant le même nom court. Pour plus de détails, voir cette section de la procédure d'upgrade.

Ça y est, cette fois, c'est bon !!! :-)

Sommaire

Tout d'abord félicitations !!! Si vous avez pu lever ce problème, c'est effectivement que vous êtes un lecteur studieux, membre de ce club si fermé de lecteurs de doc…

Donc oui, c'est vrai, plusieurs choses survivent encore en V3.1 commandant Poulard qui ne devraient plus avoir de raison d'être… C'est essentiellement dû au fait que nombre de QoQ-CoTeurs viennent d'une version 2.0 ou antérieure et ont donc encore une part plus ou moins importante de leur parc qui fonctionne avec des clients rsyslog. Détaillons un peu :

• le script peuplade.php : il ne sert qu'à insérer dans la bonne table les données issues des clients rsyslog. Ne sert donc pas dans une version 3.X non issue d'un upgrade depuis une version < 3.0. Ne sert plus, même dans ce cas d'upgrade, une fois que tous les clients ont été migrés en mode poussin/coq.
• le champ NomNetBios de la table MachineToSalles. En mode poussin/coq, on n'utilise que le nom court qu'on stocke dans le champ NomMachine de la table MachineToSalles. Donc le champ NomNetBios ne sert pas dans les versions 3.1 non issues d'un upgrade depuis une version précédente. Ne sert plus, même dans ce cas d'upgrade, dès lors qu'on a suivi la procédure d'upgrade qui modifie la base de données en mettant le nom court dans le champ NomMachine.
  Néanmoins, nous avons décidé de garder pour l'instant le nom NetBios dans la base – et nous vous conseillons de le renseigner correctement dans votre fichier .csv (notre conseil : la même valeur que le nom machine) – pour se laisser la possibilité d'évoluer sur la gestion des noms dans des versions futures, selon les situations à problème éventuelles que pourraient nous remonter les QoQ-CoTeurs v3.x
• le champ IdProcess de la table Connexions. En effet, en mode poussin/coq, le mode d'insertion des connexions permanent ne nécessite plus la connaissance de l'idProcess système. Cette information était utile en mode rsyslog pour apparier correctement un événement de fermeture de session avec l'événement d'ouverture correspondant. Mais il sert encore pour tous les QoQ-CoTeurs qui ont encore une partie du parc en mode rsyslog.
• le répertoire ressources/rsyslog__OBSOLETE_A_PARTIR_DE_QoQ-CoT_V3.0_Commandant_Poulard qui porte bien son nom. Il ne sert plus depuis l'introduction en v3.0 du mode poussin/coq. Néanmoins on décide de le laisser pour l'instant dans l'archive, d'une part parce qu'il pèse seulement 112Kio et d'autre part parce que certains QoQ-CoTeurs ont encore une partie de parc en mode rsyslog et d'une troisième part car le mode rsyslog, s'il est déconseillé, peut quand même continuer d'être utilisé si on le préfère… et pour peu qu'on ait scrupuleusement suivi la procédure d'upgrade.

Sommaire

L'idée générale est de refaire l'opération d'import à partir du setup (possible depuis la version 2.0 Bernadette). Pour ne pas repartir de zéro, on peut exporter ses salles et machines (terrific feature disponible cette fois depuis la version 3.0 Commandant Poulard). Ci-dessous les procédures d'import et d'export en détail.

Si aucun site défini (c'est-à-dire qu'il n'y a pour QoQ-CoT qu'UN SEUL site, non nommé)

• version >= V3.0 Commandant Poulard:

• php setup.php /chemin/vers/le/fichier.csv

• version <= 2.0 Bernadette
  • php setup.php csv /chemin/vers/le/fichier.csv
  • php setup.php jeddlaj (pour les très vieux QoQ-CoTiens, fidèles parmi les fidèles… )

Si plusieurs sites (donc version >= 5.0 Mac Bec):

• php setup.php /chemin/vers/le/fichier.csv/du/site nom_du_site, où nom_du_site doit être un des noms figurant dans la liste de sites SITES de votre config.php

Si aucun site défini, ou version < 5.0 Mac Bec :

• php export_salles_en_csv.php > fichier_csv

Si plusieurs sites (donc version >= 5.0 Mac Bec):

• php export_salles_en_csv.php nom_du_site > fichier_csv_du_site, où nom_du_site doit être un des noms figurant dans la liste de sites SITES de votre config.php

Sommaire

On ne savait pas le faire… jusqu'à la révolutionnaire version 4.0 Rocky !!

Du coup, on va se faire une grosse grosse entrée de FAQ pour expliquer à quel point cet apport est important pour la qualité et la lecture des stats !

Auparavant, la seule option, non réellement satisfaisante, était de créer une nouvelle salle, tout en laissant l'ancienne et de rejouer le setup. On avait alors la possibilité de consulter les stats d'avant et d'après le renommage selon la salle sélectionnée. Mais 2 salles pour grapher la même salle, c'est s'éloigner bien trop de la réalité du terrain pour être viable, non ?

Alors, dans la version Rocky 4, on l'a fait. Nous avons ajouté deux champs dans la table MachinesToSalles : la date de début de la présence de la machine dans la salle, et la date de disparition de la machine de la salle. Et ces champs sont exploités par tous les graphes…

Ceci permet de gérer aussi bien le changement de nombre de machines dans la salle que le changement de nom des machines.

Comme nous allons le voir, avec l'ancienne méthode, le changement du nombre de machines ou le changement de noms induisaient des biais dans les statistiques produites dans les graphes. En effet, les utilisateurs de QoQ-CoT, dans leur immense majorité, ne créaient pas une nouvelle pseudo-salle à chaque changement de nombre ou de nom de machines.

Les problèmes sont alors multiples. Prenons plusieurs exemples :

• 5 machines sont supprimées dans une salle de 10.
  • Si on ne modifie pas la base de données en reflétant cette mise à jour (rejouer le setup en modifiant le fichier .csv), alors le taux d'utilisation va être calculé par rapport à un temps d'utilisation max. basé sur 10 machines… Donc, quand bien même les 5 machines restantes seraient utilisées au max, le taux affiché serait de 50%. Une donnée qui peut induire des décisions de pilotage inappropriées si l'information de modification du nombre de machines n'est pas connue des décideurs…
  • Si on modifie la base de données, on aura des stats correctes à partir de la date de suppression, mais par contre, elles seront faussées avant cette date. En effet, cette fois, le taux d'utilisation sera calculé par rapport à un temps d'utilisation max. basé sur 5 machines (c'est l'info qui est désormais dans la base), or il y en avait 10 avant la suppression. Donc, si les 10 machines étaient utilisées à 50%, le taux affiché sera de… 100%…
• 5 machines sont ajoutées dans une salle de 5. On a exactement les problèmes inverses du cas précédent.
• une salle est renouvelée entièrement et les noms des machines changés
  • si on ne modifie pas la base de données, le taux d'utilisation de la salle sera correct avant la date de renouvellement mais sera de 0 après. En effet, la requête qui va extraire de la BD les données du graphe cherche les connexions associées aux machines de la salle selon la DB, soit les machines ayant les anciens noms. Aucune connexion…
  • si on modifie la base, alors le taux d'utilisation sera correct après le renouvellement, mais sera à 0 avant pour la même raison : dans la base, les machines associées à cette salle sont celles ayant le nouveau nom. Il n'y aura aucune connexion pour ces machines avant leur introduction à la date du renouvellement.

Avec la version Rocky IV et les dates de début et fin de présence des machines dans les salles connues dans la base, tous ces problèmes disparaissent enfin, sous la seule réserve que le fichier .csv soit correctement renseigné, avec les dates de début et de fin de présence indiquées pour chaque machine (par défaut, les machines sont présentes, les champs de début étant instanciés en 1970 et ceux de fin en 2300, ce qui nous laisse du temps avant de devoir patcher le code pour revoir ces valeurs par défaut).

Voyons ça en images autour de différents graphes s'appuyant tous sur un cas précis et réel : une salle de 14 machines, renouvelée le 31/01/2017 avec changement de nom pour toutes les machines. Nous allons montrer à chaque fois le graphe en version 3.1 Commandant Poulard, dont la base a été mise à jour en associant à la salle les nouveaux noms de machine en lieu et place des anciens ET en version Rocky 4, où anciennes et nouvelles machines sont associées à la salle, avec leurs date d'apparition et de disparition dans la salle dûment renseignées dans la base.

Cliquez sur les images pour les voir en taille originale

• GRAPHE 1 : Nombre d'heures d'utilisation des machines de la salle du 1er janvier 2016 au 1er février 2017, soit le lendemain du renouvellement et du renommage
  • V3.1 : on a 14 machines en abscisses, avec leurs nouveaux noms et une moyenne d'utilisation de 0,2h par machine sur cette période de plus d'un an. On l'aura compris, l'utilisation des machines de la salles avec leurs anciens noms n'a pas été comptabilisée, puisque ces machines ne sont plus associées à la salle dans la base.

• V 4.0 : on a en abscisses les 28 machines présentes sur tout ou partie de la période considérée, avec une moyenne d'utilisation de 143,13h par machine, une valeur qui exprime la continuité d'utilisation de la salle sur la période. Les histogrammes des machines avec leurs anciens noms apparaissent en vert : la couleur verte signifie qu'elles étaient présentes sur la totalité de la période requêtée. Ceux des machines aux nouveaux noms sont oranges, car elles n'étaient présentes que sur une partie de la période requêtée. Le pourcentage de présence sur la période est indiquée en abscisse en regard de chaque nom de machines : ici 0,5%. Si nous avions requêtée une période se terminant ne serait-ce qu'un jour plus tard, les histogrammes des machines aux anciens noms seraient également oranges, puisqu'elles n'auraient plus été présentes sur la totalité de la période…

• GRAPHE 2 : Nombre d'heures d'utilisation des machines de la salle du 1er janvier 2016 au 29 janvier 2017, soit la veille du renouvellement et du renommage
  • V3.1 : seuls les nouveaux noms sont associés à la salle dans la base, noms qui n'étaient reliés à aucune connexion avant le 29 janvier. Résultat : utilisation nulle !!

• V4.0 : moyenne d'utilisation 286h, les anciennes machines sont associées à la salle dans la DB sur cette période. On a parfaitement accès aux stats d'avant le renouvellement (comme d'ailleurs à celles d'après…).

• GRAPHE 3 : Nombre d'heures d'utilisation des machines de la salle du 1er janvier 2017 au 31 juillet 2017, soit une période qui inclut la date de renouvellement
  • V3.1 : moyenne d'utilisation par machine 117h. Seules sont comptées les connexions avec les nouveaux noms de machines, qui n'existent qu'après la date du renouvellement.

• V4.0 : on voit les 28 machines, anciens et nouveaux noms. Tous les histogrammes sont oranges, car aucune machine n'était présente sur la totalité de la période (pourcentage de présence sur la période indiqué en regard des noms de machines en abscisse). La moyenne d'utilisation par machine 103,38h… Elle est plus faible qu'en V3.1 car elle prend en compte AUSSI la période précédent le renouvellement, où les machines ont peu servi. Mais elle est seulement légèrement plus faible car la moyenne est pondérée en fonction du pourcentage de présence de chaque machine : c'est pourquoi « l'après renouvellement » (concerne les 14 machines/histogrammes d'après le renouvellement), soit 86% de la période considérée va compter bien plus que « l'avant » (concerne les 14 machines/histogrammes d'avant le renouvellement) que ne représente que 14% de la période considérée : la faible utilisation des machines durant « l'avant » va être largement « gommée » de par sa pondération plus faible.

• GRAPHE 4 : Taux d'utilisation annuel de la salle de juillet 2016 à 31 juillet 2017, soit une période qui inclut la date de renouvellement
  • V3.1 : Le renouvellement a lieu en janvier 2017, la salle apparaît inutilisée avant cette date… Toujours pour la même raison : les vieux noms de machines ne sont plus associées à la salle dans la DB, l'utilisation associée « disparaît »…

• V4.0 : Le taux reflète l'utilisation réelle de la salle, indépendamment du renouvellement et du changement de noms. Les anciennes comme les nouvelles machines sont associées à la salle dans la DB, avec leurs périodes précises de présence.

• GRAPHE 5 : Pic de connexions simultanées dans la salle du 1er décembre 2017 au 28 février 2017, soit une période qui inclut la date de renouvellement
  • V3.1 : de même que pour le taux vu ci-dessus dans le graphe 4 et toujours pour la même raison (seules les nouvelles machines sont associées à la salle dans la DB), aucune connexion n'apparaît avant la date de renouvellement.

• V4.0 : anciennes comme nouvelles machines sont associées à la salle dans la DB, la totalité des connexions, d'avant comme d'après le renouvellement, est donc visible. On voit que la ligne représentant le nombre de machines de la salle est devenue une courbe avec la version 4.0, puisque ce nombre de machines peut varier dans le temps. En l'occurrence, on voit un pic de 28 machines le jour du renouvellement, car les 14 anciennes machines étaient présentes dans la salle ce jour-là avant qu'on ne les remplace par les 14 nouvelles : les 28 machines sont donc logiquement associées à la salle pour cette date, même si elles n'ont jamais été actives simultanément dans la salle.

Sommaire

Humm, terrain glissant… La contrainte actuelle dans la base de données est qu'il ne peut y avoir qu'un seul Nom machine donné (et également qu'un seul Nom Netbios donné) dans la table « MachinesToSalles » qui associe les machines aux salles, ce qui signifie qu'une machine ne peut pas appartenir à 2 salles distinctes. Mais cette contrainte n'interdit nullement de rassembler dans une salle QoQ-CoT des machines qui sont dans des salles physiquement distinctes (par exemple les machines « prof » de plusieurs salles, ou celles qui font tourner ce fameux logiciel hors de prix, etc.) : par contre, on ne pourra pas les faire figurer aussi dans une autre salle QoQ-CoT (notamment la salle physique où elle se trouve).

Le problème des salles virtuelles est sujet à débat dans l'équipe QoQ-CoT Gérard est pour et pense que c'est un ajout crucial, Fred de son côté y voit plutôt un intérêt mineur… Il reste néanmoins un problème factuel : si une machine appartient à 2 salles distinctes S1 et S2, le calcul du taux d'utilisation pour le groupe de salles qui contient S1 et S2 devient plus délicat, il faut éviter que la machine compte double… Une piste possible est de ne permettre de faire figurer une machines dans plusieurs salles si et seulement si toutes ces salles appartiennent à des groupes de salles différents : ainsi on élimine les cas « compte double » car on ne peut sélectionner plusieurs groupes à la fois. C'est alors au niveau du groupe de salles qu'est remontée l'idée de regroupement thématique et non physique. Mais ceci ne règle le problème que pour les groupes de salles prédéfinis. Pour ceux que l'interface permet de créer dynamiquement par sélection multiple et libre, la possibilité du « compte double » demeure : il faut alors modifier la requête SQL de façon assez fine (suffisamment fine pour qu'on ne puisse affirmer pour l'instant que c'est jouable en termes de complexité et donc de temps d'attente avant génération du graphe…). To be continued, donc…

Sommaire

Vous devez consulter la section GRAPHES du guide utilisateur, pour votre version de QoQ-CoT, où tout est expliqué, de façon concise, agréable et ludique.

Sommaire

J'ai beaucoup de fins de connexions qui ne sont pas détectées, entre autres parce certains de mes $*#@*£^% d'étudiants préfèrent arracher la prise, ou choisir le menu éteindre la machine, plutôt que de se déconnecter correctement. Bref, pour paraphraser un collègue d'Aix-en-Provence (ça reste quand même une drôle de ville vue de Marseille…), QoQ-CoT ne me donne pas d'infos fiables, ça fait semblant de marcher, c'est du vulgaire poulet aux hormones comme ici dans Food, Inc !!!

Vous voulez de la très bonne solution, définitive, qui éradique toute possibilité de perte de fins de connexions ? C'est facile, upgradez simplement (au moins) en V3.0 commandant Poulard. Vous aurez alors la possibilité de confier les remontées des connexions au « poussin », petit programme de notre cru, 100% bio et libre, qui nourrira exclusivement au grain pure origine votre poulette. Il fonctionne selon le principe de la veille automatique ferroviaire, souvent appelé « dispositif de l'homme mort » : la fin de connexion est mise à jour en permanence dans la base tout au long de la durée de connexion, au lieu d'être, comme avant, instanciée une fois pour toutes lors de la déconnexion de l'utilisateur, qu'on pouvait donc parfois rater. Réjouissons-nous, ce temps est révolu, comme celui de la peste ou, c'est plus triste, du minitel rose.

Plus de détails sur le mode poussin/coq dans la section Fonctionnement de la remontée des connexions sur cette même page.

Je viens de me rendre compte que votre logiciel est encore plus performant que vous le clamez : non content de logger les connexions, il va jusqu'à les prévoir !!! En effet, j'ai des dizaines de connexions en cours dont QoQ-CoT me dit qu'elles se finiront dans plusieurs mois… Encore plus fort dans l'esprit Minority Report, certaines sont annoncées qui commenceront et finiront dans plusieurs mois !! Alors, avouez, votre code ne fait rien d'autre que remplir la base au hasard et là, vous êtes pris la main dans le sac… Alors, qu'avez-vous à répondre ???!!!

Ce qui vous dites est vrai. Enfin, le début, pas la fin sur le hasard et le sac… Oui, il peut arriver que des connexions du futur soient insérées dans la base et je dois dire que la première fois que ça nous est arrivé, on a été aussi surpris que vous

Voici l'explication. Soyez prêt à ressentir le même sentiment de légère déception que dans un épisode de Scoubidou, car, contrairement à toutes apparences et comme toujours dans Scoubidou, il n'y a finalement rien d'occulte ni de paranormal…

Le souci n'existe que pour les clients tournant NxLog. Ce dernier, tel qu'il est configuré dans QoQ-CoT jusqu'à la version 2.0 Bernadette, ne renvoie pas l'année dans la date (la fonction to_syslog_bsd() étant conforme au RFC 3164 dont le format date ne contient pas l'année)…

L'année en question est donc ajoutée par rsyslog au moment où il reçoit les connexions des clients. Si le client, pour une raison quelconque (réseau indisponible,…), n'a pas pu renvoyer ses connexions l'année X (extinction des machines pour la fermeture de Noël,…) et n'est rallumé que l'année X+1 (retour de vacances), alors il les renverra à ce moment-là et la connexion sera donc enregistrée… avec un an d'avance : par exemple, une connexion de décembre 2014 qui n'est remontée à rsyslog qu'en janvier 2015 se verra datée de décembre 2015 !!!

Aïe, mais c'est très grave, ma base est corrompue par ces fausses données…

Doucement. Respirez et décontractez-vous, la solution pour la réparer est juste dessous… (notons que nous avions averti la communauté QoQ-CoT du bug et donné la solution dès janvier 2015 dans ce post de forum).

L'option consistant à modifier la conf. de NxLog de façon à ce qu'il utilise le format syslog de la RFC 5424, qui inclut l'année, n'a pas été retenue. En effet, l'ajout de l'année n'est pas du tout la seule modification et le format des messages change suffisamment pour qu'il implique, pour une mise en oeuvre dans QoQ-CoT, des modifications lourdes des configurations du client NxLog (filtres), du serveur rsyslog (filtres rsyslog.conf) et enfin du code PHP (filtres)… Et en plus, nous avions dans l'idée d'abandonner le fonctionnement à base de captation d'évènements syslog (ce qui est finalement arrivé avec la version 3.0 Commandant Poulard et son mode poussin/coq) qui posait des problèmes de fiabilité des données (certaines connexions non comptabilisées car événement de fin de connexion non capté).

Nous avons donc préféré proposer une méthode permettant de corriger les données une fois inscrites en base. Vous trouverez dans le répertoire qoq-cot (initialement src dans l'archive) sur le serveur qui tourne l'interface web un script assez judicieusement nommé bonne_annee.php. Il vous suffit de l'exécuter et votre base sera à nouveau cohérente : les dates concernées dans la table connexions sont modifiées en étant reculées d'un an. La procédure 0 risque est la suivante :

1. Backup de votre table Connexions.
2. Arrêt du cron peuplade.php.
3. Exécution du fichier bonne_annee.php au travers du navigateur : la 1ère exécution peut être longue si vous avez beaucoup de connexions à cheval sur les 2 années. Sera affiché à l'écran le nombre de lignes modifiées.
4. (Facultatif) Re-exécuter bonne_annee.php au travers du navigateur pour vérifier que cette fois, l'affichage indique qu'aucune ligne n'a été modifiée.
5. Remetre en service le cron peuplade.php.

Vous devez le lancer chaque début d'année, une fois certain que les clients ont tous redémarré et déchargé leurs connexions dans rsyslog (pas de souci si vous exécutez bonne_annee.php plusieurs fois dans l'année, il ne fait rien s'il n'y a rien à faire…). Mais si vous attendez plus d'une année, les connexions initialement dans le futur seront devenus des connexions passées (et donc « normales ») et bonne_annee.php ne les repérera plus : elles resteront fausses pour toujours dans votre base… Pour être sûr de corriger toutes les connexions, il vous faut donc exécuter bonne_annee.php chaque année ET ne pas dépasser un an entre deux exécutions… Pas d'angoisse exagérée cependant, on parle ici, normalement, d'un pourcentage très faible des connexions …

Notons enfin que ceci ne vous concernera plus dès que vous ne reposerez plus sur NxLog, que nous vous conseillons fortement de délaisser au profit du mode poussin/coq (disponible à partir de la version 3.0 Commandant Poulard) qui n'est pas sujet à ce problème. Bien sûr, tant que votre parc comportera encore des clients tournant NxLog (tout le parc ne pourra pas forcément migrer en mode poussin/coq d'un seul coup…), il vous faudra lancer bonne_annee.php comme indiqué ci-dessus.

Qu'est-ce que ce mode poussin/coq dont vous parlez sans cesse ?!!

1. Tout d'abord, il faut le dire ici haut et fort, il s'agit tout simplement de la dénomination officielle pour client/serveur, locution qui constitue une impropriété depuis des années dans toute la littérature informatique.
2. Ensuite, ce nouveau fonctionnement, introduit à partir de la version 3.0 commandant Poulard, remplace totalement l'ancien fonctionnement à base de rsyslog, qui n'est plus du tout utilisé, ni sur les clients, ni comme serveur central.
   • L'ancien principe consistait à filtrer les évènements des journaux systèmes et les envoyer à un serveur rsyslog central qui finalement, après filtrage, inscrivait les événements correspondant aux connexions dans la base MySQL. Les machines du parc envoyaient donc la fin de connexion d'un utilisateur une seule fois, quand elle était captée. Si cet évènement était « raté » (extinction pas trop propre de la machine par exemple), alors la durée de connexion était inconnue et donc non renseigné dans la base où seule figurait la date de début de la connexion. Les taux d'utilisation étaient donc potentiellement faux, puisque la durée des connexions dont on avait « raté » la fin n'étaient pas prises en compte…
   • Dans le nouveau principe, les poussins (des petits programmes 100% libres, jaunes, soyeux avec le cœur qui bat vite), installés sur chaque machine du parc surveillé, envoient directement et en permanence (principe de la veille automatique ferroviaire, souvent appelé « dispositif de l'homme mort ») au coq (un autre programme 100% libre, calme, robuste et arborant fièrement sa crête vermillon) l'état des connexions sur le client (c'est-à-dire « qui est connecté sur la machine à l'instant de l'envoi ? ») : chaque envoi, chiffré, est limité à quelques octets, juste de quoi construire la requête MySQL d'update de la date de fin de chaque connexion. Au contraire d'avant, les informations envoyées ne sont jamais inutiles, il n'y a donc rien à filtrer… Ensuite, le coq, seul autorisé à le faire, réactualise en permanence, avec les informations reçues des poussins, les heures de fin de connexions dans la base. Ainsi, impossible de « rater » une fin de connexion car on n'a pas capté l'évènement : si la connexion s'arrête pour une raison quelconque (arrachage de la prise de courant, extinction brutale de la machine, foudre, coup de hache), l'heure de fin arrête simplement d'évoluer.
     • Oui, il y a une différence importante dans l'affichage du suivi des connexions : désormais toute connexion a toujours une date de fin, même si elle n'est pas encore finie… Donc, à partir de tout de suite, mémorisez la nouvelle définition d'une connexion finie : « une connexion finie n'est pas simplement une connexion qui a une date de fin, c'est une connexion qui a une date de fin qui n'évolue plus ».
     • On est certain qu'une date de fin n'évoluera plus si, avec le poussin, le coq, le serveur MySQL (et les liens réseaux qui les relient) opérationnels, on ne constate pas d'évolution dans l'interface de visualisation des connexions pendant plus de « send * scan » secondes, les paramètres send et scan étant définis dans le fichier de configuration poussin.yml (voir cette section pour plus de détails sur la signification, le fonctionnement et le tuning des paramètres send et scan).

Humm, passer en mode poussin/coq en lieu et place de rsyslog ne charge-t-il pas plus le réseau ?

Bonne question, légitime. En fait, d'après nos tests, la charge réseau est globalement inchangée. Les envois sont plus fréquents, certes, mais les données envoyées sont minimales : elles correspondent exactement aux requêtes MySQL permettant de mettre à jour la base. Alors qu'auparavant, surtout sous Linux, malgré le filtrage côté client et serveur, le ratio « données utiles/données qui transitent » était extrêmement faible. Bref, charge un peu à gauche, allège un peu à droite, on est à peu près quitte…

Bon… Mais le poussin ne charge-t-il pas davantage les clients au niveau CPU ?

Décidément, que des questions pertinentes…

En fait, pas vraiment. Le code perl du poussin est extrêmement simple et léger et encore une fois, l'absence du filtrage auparavant nécessaire fait beaucoup gagner.

Je comprends. Mais un truc m'échappe : pourquoi consommer du temps CPU avec un « coq », alors que vous dites que les poussins sont capables de générer et d'envoyer directement les requêtes MySQL ?… Ils n'ont qu'à attaquer directement le serveur MySQL…

Incroyable. Serait-ce vous qui avez codé QoQ-CoT ? Vous vous posez exactement les mêmes questions que nous !!!

Reposer sur un coq a du sens pour 2 raisons au moins :

1. Tout d'abord, en termes de sécurité, seul le coq dispose de l'accès au serveur MySQL. C'est rassurant.
2. Ensuite, passer par cet intermédiaire nous permet, si le futur l'exige, d'opérer un traitement éventuel sur les données reçues avant injection dans la DB. Par exemple, vérification que les données envoyées le sont bien par la machine spécifiée dans lesdites données (non, on ne l'a pas encore fait…).

Bon, bon… Mais quid de la robustesse du mode poussin/coq ? Si le poussin perd le coq au niveau réseau, si le coq se crashe, si le coq perd le serveur MySQL, si le serveur MySQL se crashe ? Vous y avez un peu pensé à tous ces trucs de base ?!!!

Il s'avère que oui, par extraordinaire, ces scénarios nous sont venus à l'esprit, à nous aussi… Le mode poussin/coq est TRÈS robuste.

• Si un poussin perd le coq (ce qui couvre aussi le cas où le coq se crashe), il stocke tout en local jusqu'à récupération du coq. Aucune donnée perdue.
• Si le coq perd le serveur MySQL (ce qui couvre aussi le cas du crash du serveur MySQL), il l'indique aux poussins, qui stockent en local jusqu'au retour en situation normale.

Bon, ok, c'est robuste… Mais est-ce que c'est fiable ? Comment le poussin sait-il que le coq a bien reçu l'exact message qu'il vient de lui envoyer ? Si ça n'est pas le cas, la connexion contenue dans le message est-elle perdue ?

Vous pensez décidément à tout. Bon, sur ce coup, nous aussi. Il y un mécanisme d'acquittement dans la communication poussin/coq : si la transaction est OK, le poussin détruit les données. Sinon, il les stocke et les transmettra à nouveau lors du prochain envoi. Rassuré ?

J'ai vraiment très très peur des pirates. Comment fonctionne le chiffrement des connexions entre les poussins et le coq ? Est-il sûr ?

On va dire « assez sûr »… L'algorithme utilisé est le très répandu TEA (Tiny Encryption Algorithm) qui repose sur une clé de 128 bits…

OK, mais si j'étais vraiment vraiment malin, est-ce que je pourrais réussir à abuser le mode poussin/coq en introduisant anonymement de fausses données dans la base ??

Tout d'abord, il faut néanmoins relativiser la probabilité et les dangers d'un crack éventuel : en dehors du cas où un utilisateur parvient à passer administrateur sur un client (là, on ne peut plus rien, on ne sait de toutes les façons plus qui est connecté…) ou sur le serveur MySQL, la tâche est difficile pour le pirate :

• il n'aura pas la possibilité de détruire une connexion dans la base (le coq ne le peut pas) ;
• il ne pourra pas non plus inscrire dans la base pour une connexion donnée une date de fin antérieure à celle déjà inscrite (le trigger MySQL, installé dans la base par le setup, l'interdit. Si vous avez upgradé depuis une version antérieure à la V3.0, vous avez évidemment relancé le setup comme indiqué dans les notes d'upgrade : sinon, attention, pas de trigger !!) ;
• la seule possibilité qui lui reste est donc de commette son forfait entre 2 remontées du poussin, soit en moins de scan * send secondes (les paramètres définies dans le fichier poussin.yml) et de se déconnecter très très vite ensuite (sachant que le temps d'une déconnexion normale va souvent excéder à lui tout seul scan * send secondes)… C'est beaucoup d'énergie, de rétro-engineering, de compétences et de maîtrise de l'art Ninja furtif pour un forfait qui pourrait sans doute être commis plus facilement d'ailleurs (vous connaissez le principe consistant à garer son vélo à côté d'un autre, mieux, plus cher et moins bien attaché : c'est rarement le vôtre qu'on volera…).

Il reste le cas du poussin pirate qui pourrait forger de faux paquets. Là encore, il ne pourrait détruire une connexion ou inscrire pour une connexion donnée une date de fin antérieure à la dernière déjà inscrite. Et il faudrait forger un paquet chiffré contenant les données au format exact attendu par le coq, ce qui signifie que le pirate dispose des clés de chiffrement. Le risque est ici non pas que le pirate fasse disparaître sa connexion, mais qu'il en ajoute d'autres, factices, afin d'introduire un doute sur qui a commis le forfait. Notons que ceci ne résisterait pas à l'analyse des logs de la machine qui tourne le poussin.

Néanmoins, le risque existe. Notre objectif, dans les futures versions, est de le diminuer encore en vérifiant, via le coq, que les données de connexion envoyées par la machine X proviennent bien de la machine X.

Restera le risque résiduel suivant : le pirate parvient à laisser tourner, sur la machine, des process lui appartenant alors qu'il s'est déconnecté (oui, c'est possible, mais nous n'en dirons pas plus ici sur ce sujet ). Il n'apparaît alors plus connecté pour QoQ-CoT. Si son process, non interactif, est capable de lancer des actions malicieuses, il agira en toute impunité (sous réserve qu'on ne s'aperçoive de rien jusqu'à la mort du process, car sinon, le forfait est signé par le propriétaire du process…). Pour parer à ce risque, la seule option est d'activer, sur toutes les machines, des logiciels de tracking dédiés susceptibles d'archiver en permanence et de façon sécurisé les process en cours d'exécution, ou d'écrire un petit démon qui tue automatiquement les process des utilisateurs (non système) qui ne sont pas connectés. Mais encore une fois, c'est pas mal d'énergie et d'expertise et le forfait sera probablement plus facile dans un autre environnement moins protégé. Notons enfin qu'un tel cas, indiquant que quelqu'un de relativement pointu a décidé de se servir de vos machines, vous occasionnera des problèmes importants, que QoQ-CoT soit installé sur le parc ou non…

Bon. Robuste, sûr, fiable. OK. Mais est-il bien réglé ? N'y a-t-il pas un « tuning » possible pour optimiser les performances ?

Ah, monsieur (ou madame) est perfectionniste… C'est une qualité. Le tuning du coq tel qu'il est livré dans l'archive fonctionne parfaitement pour un parc de 1000 machines, 5000 utilisateurs, associé à un paramètre « max_connections » du serveur MySQL fixé à 100. Pus précisément, notre réglage est le suivant :

• paramètre Listen (dans la déclaration de la variable dans coq.pl ; c'est le nombre de « forks » du coq qu'on autorise, sachant qu'il y a un fork chaque fois qu'un poussin se connecte) fixé à 10 ;
• paramètre max_connections du serveur MySQL (fichier my.cnf ; c'est le nombre maximal de connexions simultanées que le serveur va accepter) fixé à 100.

Il est sans doute possible d'optimiser en augmentant Listen et max_connections. La question intéressante est sans doute : dans quels cas FAUT-IL modifier le réglage indiqué ci-dessus ? Essentiellement dans la configuration où le serveur MySQL est en situation de refuser trop de connexions, occasionnant un délai dans l'inscription des données venues des poussins via le coq. Pour vérifier si vous êtes dans ce cas, un bon moyen est d'utiliser le suivi des connexions et de vérifier que les heures de fin des connexions actives sont mises à jour au rythme que vous avez défini via les paramètres scan et send du fichier poussin.yml, c'est-à-dire toutes les scan * send secondes. Si la mise à jour est plus lente que ce qu'elle devrait, il va sans doute falloir augmenter les paramètres Listen et max_connections. Procédez doucement, par essais/erreurs et prenez soin de ne jamais avoir un Listen supérieur à max_connections, ce qui signifierait plus de coqs forkés attendant d'écrire dans la base que de connexions simultanées possibles sur la serveur hébergeant la base : une bonne situation à problèmes, non ? En résumé, tunez, tunez, oui, mais tunez doucement…

Et ces messages qu'envoient les poussins ? Je veux le réglage IDÉAL des paramètres scan et send dans poussin.yml !!!

Madame (ou monsieur) est exigeant. C'est parfois une qualité…

• Le paramètre scan indique le nombre de secondes entre deux vérifications, par le poussin, de qui est actuellement connecté sur la machine (les résultats de ces vérifications [couples {user connecté, date et heure de la vérification}] sont stockés en mémoire en attendant d'être envoyés au coq qui les transmettra à la DB pour mise à jour des connexions) : notre préconisation est 5.
• Le paramètre send fixe le nombre de scans effectués avant d'envoyer les données au coq : notre préconisation est 2.

Si vous avez suivi, vous comprenez donc que les données sont envoyées toutes les scan*send secondes. Comment jouer sur ces paramètres et quelles en sont les conséquences ?

• scan : plus ce chiffre sera petit, plus la précision sur la date de fin des connexions sera fine, MAIS la CPU locale sera plus sollicitée ;
• combinaison scan*send :
• * si ce produit, qui correspond au temps entre 2 envois, est trop important, on augmente le risque de perdre des informations de connexions… En effet, si la machine reboote ou s'arrête alors que des utilisateurs sont connectés, toutes les vérifications en attente d'envoi seront perdues (car elles étaient en mémoire ; elles ne sont stockées sur disque que si un envoi échoue, ce qui ne se produit pas dans ce cas). Si les envois se font toutes les 10 secondes, ça n'a guère d'importance. S'ils se font toutes les 20 minutes, c'est plus ennuyeux.
• * mais si ce produit est très faible, on sollicite un peu plus le réseau, ainsi que la machine locale, …et donc le coq… et au final en bout de chaîne le serveur MySQL…

Bref, même si ma fibre idéaliste et révolutionnaire est mise à mal par cette déclaration paradoxale et par trop raisonnable, je crois qu'en l'espèce, l'idéal est sans doute dans le compromis. S'il fallait une preuve qu'on vieillit, en voilà une belle

OK, ok je rends les armes, vous m'avez convaincu. Mais j'ai 100 000 machines, je ne vais pas pouvoir migrer d'un coup tout ça en mode poussin/coq… Peut-on fonctionner à la fois en mode poussin/coq pour certains clients et en mode rsyslog pour d'autres ?

Encore une fois, bonne remarque. Nous y avons pensé. Oui, le mode hybride que vous évoquez est tout à fait possible. Il suffit de laisser tourner les anciens clients et le serveur rsyslog tels quels, d'ajouter le coq, puis de migrer les poussins au rythme qui vous convient. Seule contrainte : prenez garde, lors de la migration d'une machine, d'arrêter l'ancien mode avant de la passer en mode poussin. Notez cependant que le mode poussin/coq est plus fiable pour vos données, assurant que les connexions ne seront pas perdues : vos statistiques seront plus sûres et vos décisions de pilotage plus pertinentes. Donc, migrez à votre rythme, oui, mais faites vite

Vous fournissez, à partir de la version 2.0 Bernadette, un script d'update appelé « dédoublonnade » destiné à épurer la base issues des versions précédentes de ses doublons inutiles. N'y a-t-il pas ici un barbarisme, la forme normale étant plutôt « dédoublonnage » ?
Même question pour le terme « raccourcissation » introduit dans le script ModifieDBV2toV3.sh fourni en v3.1 Commandant Poulard ? C'est plutôt « raccourcissement », non ?

Pas à Marseille.

Sommaire