Icinga2

Généralités

Icinga est un outil permettant de faire remonter les alertes venant des serveurs très facilement. Il est accessible à l'adresse suivante : https://icinga.resel.fr

Le service est monté sur le serveur Eris à Brest et Cadillac à Rennes.

La configuration se trouve à l'adresse suivante : https://git.resel.fr/confs/icinga2

Ajout rapide d'un serveur

(aide mémoire)

Pensez à utiliser le git-lab pour simplifier la vie de tous les autres admins

Voici la procédure pour monitorer rapidement un serveur sur icinga :

Se rendre sur eris puis dans le bon dossier :

cd /etc/icinga2/zones.d/<Zone>

où <Zone> est soit Brest soit Rennes soit Nantes.

Trouver n'importe quel simple fichier de conf pour un serveur, et le copier en remplaçant noms et adresses IP :

cp serveurs/veronica.conf serveur/<nouveau>.conf
vim <nouveau>.conf

Relancer Icinga2 :

systemctl restart icinga2

Préférer le rechargement :

systemctl reload icinga2

Vérifier que la configuration est valide :

icinga2 daemon --validate

Mise à jour du système

• Icinga2 au ResEl fonctionne en cluster. Il est important de garder des versions identiques à Brest sur eris et à Rennes sur cadillac.
• Pensez à regarder les notes de mise à jour sur le site d'icinga2. Il y a parfois besoin de réaliser des opérations sur la BDD, donc équipez vous au moins de l'user / mot de passe icinga2.

Installation et configuration

Installation

Pour avoir une version à jour d'Icinga2 et Icingaweb2, ajouter /etc/apt/sources.list.d/icinga.list :

deb http://packages.icinga.org/debian icinga-jessie main
deb-src http://packages.icinga.org/debian icinga-jessie main 

Puis installer les packets requis :

apt-get install icinga2 icinga2-ido-mysql
apt-get install monitoring-plugins

Une fois icinga2 installé et configuré, terminer en installant l'interface web :

apt-get install icingaweb2

Pour avoir plus de détails sur la configuration, référez vous à la documentation sur le site officiel d'Icinga2, qui sera à jour.

Architecture

Icinga2 permet très facilement de profiter de fonctionnalités de Haute Disponibilité, de monitoring distribué et de synchronisation des configurations sur plusieurs serveurs, et c'est ce genre d'architecture qui a été mis en place au ResEl pour : décharger Hera, avoir encore du monitoring en cas de perte du I11, ou du lien Brest-Rennes par exemple.

En prenant cela en compte, deux machines font actuellement tourner Icinga : Cadillac à Rennes, et Eris à Brest. La configuration est automatiquement synchronisée entre ces deux serveurs.

Toute la configuration se fait sur *Eris, dans le répertoire /etc/icinga2/zones.d/. Il y a plusieurs répertoires importants dedans :

• global-templates : le contenu de ce dossier sera synchronisé sur tous les membres du cluster. Il contient la définition des commandes et des services propres à toutes les machines (ssh, http, mailq par exemple), les users, les définitions et scripts des notifications.
• brest : les fichiers de configuration des serveurs, switchs, et bornes de la zone de Brest.
• rennes : les mêmes éléments, pour la zone de Rennes.

Ici, la zone correspond à des éléments définis dans le fichier zones.conf (et ici, ça correspond à la répartition géographique des machines). La zone Brest a été définie comme parent de la zone Rennes, ainsi Rennes accepte les fichiers de configuration venant des serveurs de Brest.

Ajouter un serveur

Selon la zone du serveur, rendez-vous dans le répertoire Brest ou Rennes, et créez le fichier serveur.conf, sur le modèle des autres fichiers présents.

Décortiquons le fichier de configuration type. Il se compose de la définition d'un objet, et de plusieurs variables en son sein :

object Host "idaho" {
        import "generic-host" 
        display_name = "Idaho - Hyperviseur Xen" 
        address = "idaho.adm.resel.fr" 

        groups += ["munin-servers", "ssh-servers"]
        vars.os = "Linux" 
}

Ici, on définit un objet qui porte le nom du serveur, en l’occurrence Idaho. La 1ère importe un contenu générique (un autre objet Host, avec d'autres variables), et après on définit quelques variables :

• address : pas besoin d'expliquer je pense :p. On peut préférer l'adresse IP au nom DNS.
• display_name_ : Son petit nom et une très courte description qui apparaîtra sur l'interface web, dans les notifications..
• check_command_ : Définit la commande à exécuter pour savoir si la machine est UP ou DOWN.
• groups : on définit les groupes auquel la machine appartient. Cela dépend des services lancés dessus; pour d'autres groupes voir le fichier global-templates/groups.conf. En principe, toutes les machines font tourner ssh et munin-node et appartiennent donc au moins à ces deux groupes.
• vars.os : une variables custom (précédée par vars.) qui contient l'OS. Cela permet entre autres de distinguer facilement une machine qui utilise apt, ou pkg par exemple.

Dans la plupart des cas, la configuration peut s'arrêter ici : le monitoring de base peut commencer. En cas d'installation d'Icinga, si de nouveaux services tournent ou pour mieux comprendre le fonctionnement du logiciel, la suite est là.

À partir de là, comment monitorer la machine et ses services ? Il faut créer ce qu'on appelle un (attention) service.

Ajouter un service

Les services sont communs à toutes les zones, avec quelques exceptions, et se trouvent donc dans les fichiers de configuration dans le répertoire global-templates. Là encore, les services de bases sont assez simples : on définit un objet de type Service avec un nom, et on lui ajoute quelques variables.

Spécificité des services, on précise sur quels hôtes ils sont à vérifier, dans une syntaxe proche des langages de programmation classiques.

Exemple du service le plus simple, j'ai nommé le ping :

apply Service "ping4" {
  import "generic-service" 

  check_command = "ping4" 

  assign where host.address
}

On retrouve la même structure que plus haut, et une nouvelle variable, check_command_. Dans Icinga et les autres forks de Nagios, la commande représente un objet qui fait directement le lien entre un programme, un plugin, une commande Linux.. à exécuter pour connaître l'état d'un hôte et ses services. Ici, la commande utilisée, est le ping (version IPv4). Comment savoir sur quel hôte appliquer ce service ? On pourrait rentrer à la main les noms d'hôte, mais au lieu de cela on peut appliquer le service à des hôtes qui respectent certaines expressions :

• assign where host.address : applique le service à tous les hôtes dont l'adresse est donnée.

On peut les combiner, la doc donne d'autres exemples :

assign where match("*mysql*", host.name) && match("db-*", host.vars.prod_mysql_db)
  ignore where host.vars.test_server == true
  ignore where match("*internal", host.name)

Les commandes

Les commandes sont ce qui est exécuté dans les services. Une tripotée de plugins existe. En général, la commande consiste en l'exécution d'un plugin nagios avec des arguments particuliers, qui peuvent être précisés dans la définition de la commande ou dans les variables. (liste des commandes : https://www.icinga.com/docs/icinga2/latest/doc/10-icinga-template-library/#check-commands . ) TODO: mettre un ping4 minimal

template CheckCommand "ping-common" {
        import "plugin-check-command" 

        command = [ PluginDir + "/check_ping" ]

        arguments = {
                "-H" = "$ping_address$" 
                "-w" = "$ping_wrta$,$ping_wpl$%" 
                "-c" = "$ping_crta$,$ping_cpl$%" 
                "-p" = "$ping_packets$" 
                "-t" = "$ping_timeout$" 
        }

        vars.ping_wrta = 100
        vars.ping_wpl = 5
        vars.ping_crta = 200
        vars.ping_cpl = 15
}

Il peut arriver que vous souhaitiez faire un test assez spécifique. Dans ce cas, la commande by_ssh peut vous être utile pour exécuter un script distant : https://www.icinga.com/docs/icinga2/latest/doc/10-icinga-template-library/#by_ssh Inspirez vous de ce qui est fait sur zahia à Brest. La valeur de sortie donnant le résultat du test correspond à la valeur de retour de votre programme (le célèbre return 0 en C quand tout va bien). En python, il faut passer passer par sys.exit(returnValue).

Comment tester une nouvelle configuration et la valider

• Pour tester la configuration actuelle (dans /etc/icinga2/icinga2.conf par défaut ):

  icinga2 daemon --validate

• Pour valider la configuration et l'appliquer à icinga2:

  systemctl reload icinga2.service

• Et pour vérifier le status du service et démon après reload (pour les vieux paranos) :

  systemctl status icinga2.service

• TRÈS IMPORTANT : commit et push ses modifications :-)

  • On vérifie la liste des fichiers modifiés depuis le dernier commit (au cas où quelqu'un aurait oublié de commit !) :

    git status

  • Si seuls les fichiers qu'on a modifié soi-même sont différents, vérifier pour chaque fichier que seules nos modifications sont là :

    git diff ./fichier1

  • Si tout va bien on peut commit le tout avec un message:

    git commit -a -m "Ajout de trucmuche, maj de machin pour le service truc"

  • Puis on push:

    git push

Plugins

Les plugins utilisés se trouvent dans /usr/local/nagios/libexec/. Certains plugins-contrib sont utilisés :

• mysql_health : https://labs.consol.de/nagios/check_mysql_health/

Pour compiler, mettre à jour, etc.. les sources se trouvent dans /root/icinga-plugins-contrib/

Monitoring distribué : Faire communiquer deux zones

*TODO : *

• Génération des certificats
• API

Utiliser l'API pour récupérer des informations

Snippet de code Python, pour avoir les identifiants se référer au fichier api-user.conf dans /etc/icinga2/features-available/api-user.conf. Par exemple, pour récupérer des informations de statut assez complètes :

      proxies = {
        "http": None,
        "https": None,
      }
      r = requests.get('https://icinga.resel.fr:5666/v1/status/CIB', auth=('', ''), headers={'Accept': 'application/json'}, proxies=proxies)
      res = r.json()

Prévoir une maintenance

Sur l'interface web, sélectionnez un hôte et sélectionnez le lien Downtime (thanks captain). N'oubliez pas de préciser la raison dans le commentaire, si possible faites un lien vers l'issue Gitlab associée. Dans la plupart des cas, sélectionnez aussi All services.

Vous pouvez aussi être plus sélectif et ne mettre en maintenance qu'un service.

Icingaweb2

• Adresse : https://icinga.resel.fr
• Se connecter avec ses identifiants d'admin ResEl
  • Vous devez posséder le droit icingaweb

F.A.Q

Q : Je me connecte sur https://icinga.resel.fr mais il n'y a rien...

R : Il faut être ajouté dans le groupe administrateurs , par défaut les utilisateurs n'ont aucun droit. La v2.0 finale arrive début octobre et permet de modifier les permissions par défaut.

Q : On peut pas copier la conf de Nagios ?

R : Non, Icinga1 était totalement compatible mais il y a quelques modifications à faire avec Icinga2.

Q : Les notifications ne s'envoient pas !?

R: Pour débugguer les notifications : 1. Commencez par vérifier l'installation. Normalement on doit avoir dans le fichier /etc/icinga2/zones.d/global-templates/commands.conf la définition des commandes que les notifications vont lancer (appel d'un script python qui appelle l'API de Telegram, script pour IRC, ...). Les notifications en elle même sont définies dans le fichier /etc/icinga2/zones.d/brest/notifications.conf, vérifiez bien les règles d'application : les filtres (les types types et états states qui vont être acceptés) ainsi que l'utilisateur qui va envoyer la notification users (définis dans /etc/icinga2/zones.d/global-conf/users.conf qui eux aussi ont des filtres), ainsi que l'assignation assign (qui définit à quoi s'applique la notification).

Si vous êtes vraiment perdu, la commande magique pour débugguer :

tail /var/log/icinga2/debug.log -f|grep --after-context=10 "information/ExternalCommandListener:"

Les informations seront très utiles, n'hésitez pas à augmenter la taille du after-context.

Ressources utiles

• Le site officiel d'icinga : https://www.icinga.org/
• Le monitoring au ResEl

Articles liés

TODO (pour le rédacteur)