Stages chez Proxience

La mise en place d'Icinga2 est toujours en cours, après avoir corrigé quelques problèmes grâce aux logs qui remontaient, le problème principal demeure toujours puisqu'il est impossible d'accéder à l'interface web d'installation et de configuration d'icinga2. J'obtiens uniquement une page blanche, alors qu'il est possible d'accéder à apache2 ou nginx sans problème et sans conflit de port. Malgré de nombreuses solutions testées sur le net, la problème persiste toujours.
Après de nombreux tests et une analyse des logs, une réponse au problème ne venant pas, il nous a semblé plus judicieux de recommencer du début et d'analyser en détail toutes les étapes afin de bien s'assurer que tout fonctionne correctement, notamment lors de l'installation des paquets et de la mise en place des bases de données via postgresQL.

L'objectif de cette journée et de refaire une installation étape par étape d'icinga2 en s'assurant de ne rien oublier et en listant toutes les commandes et éventuels changements dans les fichiers de configuration, que ça soit ceux d'appache2, d'icinga2… Cela permettra ainsi de pouvoir détecter d'où le problème pourrait venir (oublie d'une commande, passage de 2 commandes qui font conflits entre elles, sélectionner les bonnes options/les bons paramètres lors des configurations). Une fois l'installation terminée, malgré les différents services que ne remontaient pas d'erreurs, le problème subsistait toujours. Après avoir recherché sur plusieurs sites, j'ai eu l'idée d'inspecter le code source de la page qui m'a donné une information très importante, puisque je savais que php était le point bloquant pour pouvoir accéder à l'interface web d'icinga2. Après avoir cherché l'erreur sur internet, j'ai trouvé un point récurrent qui était “php7.0”. Ayant précédemment vérifié grâce à la commande “a2enmod” les différentes modules que l'on pouvait activer, j'avais remarqué que php7.0 ne l'était pas, et que cela pouvait être le problème. Après activation, il est devenu possible d'y accéder, et donc de mettre en place la configuration de celui-ci.

La matinée aura été consacré dans un premier temps à finaliser les recherches à propos d'Icinga2 et du fonctionnement des alertes (comment modifier les valeurs “warning”, “critical”, la possibilité d'envoyer des alertes par mail/SMS, donner un ordre dans lequel les alertes seront envoyées (mail d'abord, puis si le problème n'est pas résolu après un certain temps que l'on peut définir, un SMS est envoyé)…) ainsi qu'à la configuration d'une interface Grafana pour Icinga2. Afin de mettre en place celle-ci, 2 méthodes sont principalement utilisées : InfluxDB et Graphite. J'ai donc cherché à comprendre leur fonctionnement, puis tenté de mettre en place Graphite, mais l'installation ne se fait pas correctement. Beaucoup de problèmes apparaissaient au fur et à mesure que l'installation avançait, que ça soit des commandes qui n'existent plus sous certaines versions, des paquets manquant pour Debian 9… C'est à ce moment que j'ai décidé de m'intéresser à la deuxième solution qui est InfluxDB.

Comme pour Graphite, je suis tout d'abord passé par une phase de recherche afin de bien comprendre le fonctionnement et savoir à l'avance si tout était bien compatible avec ce que je possédais déjà. Il existe de nombreux guides sur internet, dont quelques uns sous Debian 9, et c'est ce que j'avais besoin. Le seul problème était qu'ils utilisaient une version récente de InfluxDB (v1.5) qui n'est pas présent dans les paquets officiels de Debian9. La dernière version ajoutée est la v1.04. J'ai pensé que cela pouvait poser des problèmes au niveau de la compatibilité au début, mais après avoir regardé sur différents sites, la seule différence notable était les commandes lors de la création de bases de données et la facilité d'utilisation. J'ai donc fait mon installation avec la version v1.04. Une fois le tout configuré, je suis passé à la phase de configuration de Grafana, sachant que c'était à cette partie que je me suis retrouvé bloqué sous graphite, étant donné qu'aucun graphique ne s'affichait, uniquement des erreurs. Après avoir lutté afin de bien configurer le dashboard en utilisant celle qui avait déjà été mis en place par Icinga2, les graphiques apparaissaient enfin, un peu de manière désordonné et avec certains panels qui étaient inutiles, et donc prenaient de la place pour rien. Après avoir fait un tri parmi tout ça, et en changeant la couleur sur certains graphiques qui étaient incompréhensible autrement, je me suis intéressé au fonctionnement des graphiques, afin de savoir comment ces derniers fonctionnaient. Après avoir un peu manipulé le tout, il n'est pas si difficile au final de mettre en place un graphique lorsque l'on sait ce que l'on veut mettre avant, il suffit juste de ne pas se tromper de données.

Après avoir réussi à faire fonctionner Grafana et donc l'apparition des différents graphiques liés à ma machine Localhost, je me suis penché sur comment rajouter des nouveaux hosts qui étaient présents sur le réseau afin de pouvoir posséder des données, et donc des graphiques de tout ce qui est présent sur le réseau et que l'on peut superviser. Je me suis donc intéressé aux imprimantes présentes sur le réseau dans le but d'afficher également des graphiques sur l'interface Grafana des points qu'il peut être important de connaître. Après avoir lutté afin que les nouveaux hosts soient bien détectés par Grafana, il a fallu également faire en sorte que cela fonctionne également pour les adresses IPv6 des imprimantes. Le problème ici aura été de comprendre la syntaxe qu'il fallait utiliser dans le fichier hosts.conf afin que Grafana et Icingaweb2 détecte bien que les adresses indiquées étaient au format IPv6 et non pas IPv4. Il fallait donc indiquer dans celui-ci “address6” au lieu de simplement “address” pour que cela fonctionne. Une fois que les 2 nouveaux hosts remontaient bien, il fallait donc rajouter sur l'interface Grafana les graphiques qui correspondaient et qui nous intéresse. J'ai donc tout d'abord fait apparaître un graphique “Host Alive” pour chacun qui permet de rapidement visualiser si notre imprimante est UP ou DOWN. Il fallait ensuite déterminer ce qui pouvait être intéressant à superviser également. La configuration afin de pouvoir récupérer les informations des imprimantes HP grâce à la commande “check_hpjd” a été mise en place, et des groupes ont été créé afin de pouvoir réunir les différents hosts en commun et donc alléger les fichiers de configuration pour icinga2.