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

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

Ajout rapide d'un serveur

(aide mémoire)

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

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

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

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
}

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 :

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

TODO

Prévoir une maintenance

TODO

Icingaweb2

TODO

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.

Ressources utiles

Articles liés

TODO (pour le rédacteur)