Stages chez Proxience

Avec l'avancement de la semaine dernière, l'installation de Grafana grâce au code source commençait à donner des résultats qui correspondaient à ce que l'on était sensé obtenir à la fin. Certaines commandes tels que yarn install ou encore yarn run ne renvoyait plus un simple “commande introuvable” mais quelques problèmes liés au chemin que yarn utilisait afin d'exécuter sa commande par exemple, ou des problèmes de paquets devenus obsolètes et qu'il fallait remplacer en les installant et en modifiant le fichier “package.json” afin d'y indiquer la nouvelle version à jour et opérationnelle.
Certains scripts présents dans le fichier en question ne s'exécutaient pas correctement cela dit, indiquant qu'il manquait une fonctionnalité : “gulp” qui était essentielle afin de pouvoir terminer la configuration.

Dans la continuité de Lundi, il était donc temps de mettre en place gulp et toutes ses extensions (gulp-util, gulp-watch…). De nombreux guides sont présents sur Internet afin de mettre en place une installation basique de gulp, passant par pas mal de points qui en temps normal auraient été bloquant, notamment le fait qu'il est obligatoire de créer un fichier “gulpfile.js”, autrement aucune des commandes présentes dans le fichier “gulp.js” ne fonctionnera, puisqu'un message d'erreur apparaîtra indiquant qu'il manque un fichier.
Il était d'ailleurs essentiel de modifier un fichier afin que yarn puisse communiquer avec gulp sans avoir à indiquer un chemin complet dans un fichier de configuration que l'on risque d'oublier au bout d'un moment. Pour cela, il fallait rajouter une valeur dans le “PATH” par défaut afin que yarn n'aille pas chercher uniquement dans les quelques PATH par défaut (/usr/local par exemple) mais dans gulp qui contenait tous les éléments afin de pouvoir finaliser la configuration.
Une phase de test a été faite avant de lancer les différentes commandes permettant de démarrer Grafana afin de s'assurer que tout marchait correctement, que ça soit yarn ou le script “watch” qui devait exécuter automatiquement la commande “gulp watch”. Il fallait penser également à indiquer de nouvelles variables et une commande à exécuter par “défaut” lorsque l'on lance la commande gulp, autrement l'erreur suivante apparaissait: “Task 'default' is not in your gulpfile”.

Mercredi était donc la journée où je m'assurais que l'interface Grafana était donc bien opérationnelle, et que par la même occasion je pouvais récupérer tout ce que j'avais mis en place dessus avant de refaire une installation via le code source. Après avoir lancé les différents processus qui devaient être démarré pour pouvoir obtenir l'interface Grafana, il fallait que je puisse accéder, grâce à la même adresse IP que celle que j'avais utilisée pour la première installation et les mêmes identifiants, à l'interface graphique.
Tout fonctionnait correctement après le premier accès, les différents hosts et graphiques qui avaient été mis en place précédemment sont toujours là, donc l'installation et la configuration ont été un succès. Afin d'éviter de rencontrer les mêmes problèmes dans le cas d'une installation de Grafana sur une nouvelle machine, de la documentation indiquant toutes les étapes à suivre et tous les « problèmes » qui ont été rencontrés et comment ils ont été corrigés va être mise en place.
La majeure partie de l'après-midi sera donc consacrée à rédiger la documentation d'installation et de configuration. Cela prendra pas mal de temps, puisqu'il y a beaucoup d'informations et de détails à ne pas oublier, autrement la configuration ne voudra pas se faire et indiquera vraisemblablement un message d'erreur que l'on aurait été capable d'éviter si je n'avais pas omis une étape.

Puisque les installations de Grafana et d'Icinga2 + web étaient enfin terminées et opérationnelles, il était temps de passer à un autre outil de supervision sur lequel travailler. Parmi ceux qu'il restait encore (c'est à dire mun, munin, gnocchi et prometheus), nous avons décidé de plutôt s'orienter vers prometheus qui est l'outil de supervision qui fait parler de lui en ce moment et qui est très récent. Cela peut être intéressant de pouvoir comparer les outils qui sont présents depuis longtemps et la nouveauté.
Grâce à la phase de recherche en début de stage, j'ai pu réunir pas mal de liens utiles qui ont évité que j'ai à me renseigner et à chercher partout sur Internet des informations à propos de prometheus. J'ai ainsi gagné du temps sur la documentation qui parlait de l'installation par le code source de prometheus. J'ai ainsi commencé mon installation en suivant les différentes recommandations et en installant tout ce qui était nécessaire au bon fonctionnement de ce dernier, notamment le logiciel de programmation “go”.
Or, j'ai rencontré un problème, et pas des moindres : Afin de pouvoir installer go en version 1.10.x (qui est essentiel pour que prometheus puisse fonctionner correctement), il faut obligatoirement une ancienne version de go d'installée (1.4 par exemple). Cependant, il n'y a pas d'ancienne version de go présente sur la machine et malgré le téléchargement d'un paquet plus récent que la version 1.4 mais moins que la version 1.10 (la 1.7 et 1.8 notamment), l'installation de la version 1.10 ne se faisait pas, seul un message d'erreur apparaissait à chaque fois. Il a donc fallu chercher une autre solution afin de contourner ce problème.

Grâce à l'aide que m'a apporté Frédéric, j'ai effectué des recherches afin de pouvoir résoudre le problème lié à Go et la version qui posait problème. Il a fallu mettre en place un backport afin de pouvoir télécharger la version de Go 1.10 opérationnelle. Cependant, malgré cela, peu importe les modifications qui pouvaient être faites, et après avoir supprimé l'ancienne version de Go qui posait problème (1.7 dans notre cas), lorsque je tapais la commande afin de voir sous quelle version Go fonctionnait, 1.7 restait celle par défaut, et ce même après avoir exécuté la commande apt remove –purge.

Après avoir fait des recherches, et avec l'assistance apportée à nouveau, j'ai été en mesure de supprimer les fichiers présents dans le dossier /usr/… qui étaient encore présent suite à une installation effectuée en tant qu'utilisateur root. Une fois ces derniers supprimés, la version de Go n'était plus en 1.7 désormais, mais il n'arrivait pas à détecter la nouvelle version que je venais d'installer en tant qu'utilisateur dans mon dossier /home/adrien/… Ce qui voulait donc dire qu'il faudra se pencher sur le sujet afin de pouvoir résoudre le problème.