wiki/HowtoIcinga2.md

Cette page a été importée automatiquement de notre ancien wiki mais n'a pas encore été révisée.

Introduction

Icinga2 est un logiciel de monitoring réseau qui vise à surveiller des services en place sur des serveurs.

Icinga2 se veut un remplacement pour Icinga, un fork bien établit de Nagios. Contrairement à Icinga, qui reprenait une partie du code de Nagios et qui avait un système de configuration compatible, Icinga2 a été complètement réécrit et n'est pas compatible avec Nagios.

Structure

Il existe plusieurs manières de déployer Icinga2 pour surveiller un ensemble de machines. Icinga est assez flexible et permet de contruire des architectures distribuées ou centralisées en fonction des besoins. Pour mieux s'y retrouver, on peut donner des noms au noeuds en fonction de leur fonction :

• Noeud master : Il est en haut de la hierarchie. C'est la machine centrale du cluster.
• Noeud satellite : C'est un fils d'un master ou d'un autre satellite. Il sert à
• Noeud client : Il est en bas de la hierarchie, connecté a un satellite ou un master. Il agit comme un agent.

A noter que cette hierarchie s'applique en premier lieux a des zones, les noeuds étant des éléments d'une zone. Habituellement une zone contient un seul noeud et porte le même nom que celui-ci. Mais pour un master ou des satellites, on peut être amené à placer plusieurs noeuds dans une même zone pour les faire travailler ensemble en mode haute disponibilité et répartition de charge.

Pour configurer le cluster il existe 3 méthodes différentes, toutes les trois s'appuyant sur la présence de l'agent icinga2 sur les machines du cluster.

A noter qu'il est aussi possible de surveiller des services sans la présence de l'agent icinga2. Pour cela on pourra s'appuier sur d'autres protocoles SNMP, SSH, NRPE...

Configuration locale (bottom up config sync)

Attention, cette méthode est dépréciée depuis la sortie de la versions 2.6

Dans ce mode de configuration, les machines locales sont configurées pour se surveiller elles-même et envoyer au serveur central les résultats ponctuellement. La configuration réside sur les machines locales et est synchronisée avec le serveur central.

L'avantage de cette méthode est que les clients locaux peuvent écrire leurs configurations directement sans à avoir à passer par une gestion centralisée des tests et des configurations.

Plus d'infos ici.

Configuration centrale (top down config sync)

Le principe de la configuration en cluster est semblable à celui de la configuration locale. La seule différence est que la configuration des machines locales est faite sur le serveur central. Lorsque l'on redémarre le daemon, le serveur central s'assure que les machines locales ont la bonne configuration. Plutôt d'aller « du bas vers le haut » on va donc « du haut vers le bas ».

Cette méthode est idéale si l'on souhaite centraliser l'ensemble de notre configuration.

Plus d'infos ici.

Pont d'exécution de commandes (top down command endpoint)

Avec la méthode du pont d'exécution de commandes, l'ensemble des configurations sont sur le serveur central et y restent. Il n'y a pas de synchronisation de configuration avec les machines locales. Quand le serveur central souhaite effectuer une test sur une machine locale, il la lance directement sur cette dernière au travers de l'agent local icinga2. Le seul pré-requis est que les objets de type CheckCommand définissant les commandes à exécuter doivent être présent localemement (là où la commande est exécutée).

Cela implique cependant que les machines locales doivent accepter des commandes directement du serveur central

Plus d'infos ici.

Installation du master

Icinga2

L'installation du core d'icinga2 sur le master est relativement simple. Cependant, la documentation disponible en ligne conseille d'utiliser les paquetages officiels disponible sur les dépôts proposés par les développeurs.

# wget -O - http://packages.icinga.com/icinga.key | apt-key add -
# echo 'deb http://packages.icinga.com/debian icinga-jessie main' >/etc/apt/sources.list.d/icinga.list
# apt update
# apt install icinga2

Pour finaliser l'installation d'icinga2 en master, il faut se servir de son assistant de configuration. Il se chargera de créer une CA et activer l'API. La commande qui suit lance un assistant d'installation. Mis à part la première option où il faut répondre n, les autres peuvent être laissées vides pour conserver les valeurs par défaut:

# icinga2 node wizard

On termine par un redémarrage complet du daemon pour activer les changements de la configuration

# service icinga2 restart

WebUI

Pour fonctionner, la WebUI a besoin d'un serveur web avec PHP et d'un serveur de base de donnée. Dans les exemples qui suivent, nous utiliseront /HowtoApache et /HowtoLAMP/MySQL.

Ici, MySQL va servir à 2 choses :

• Sauvegarder les utilisateurs & groupes de l'interface Web
• Contenir les informations de configuration d'icinga2, au status des hôtes et des services... qui sont mis à jour par le module ido-mysql d'icinga2

# apt update
# apt install icingaweb2 icinga2-ido-mysql

Note : Le paquetage icinga2-ido-mysql fournit un assistant d'installation pour configurer une base de donnée et un utilisateur MySQL automatiquement. Si on le souhaite, il est également possible de le faire manuellement. Les paramètres sont alors à écrire dans /etc/icinga2/features-available/ido-mysql.conf

Une fois l'installation terminée, il est nécessaire d'activer le module ido-mysql d'icinga2 :

# icinga2 feature enable ido-mysql
# service icinga2 restart

Il est possible de lancer des commandes (planifier un check, downtimer une machine...) à partir du WebUI directement. Pour cela, il faut ajouter à l'utilisateur du serveur web au groupe nagios.

# addgroup --system www-data nagios
# icinga2 feature enable command
# service icinga2 restart

Pour continuer l'installation du WebUI, on visite le http://example.org/icingaweb2/setup L'installeur va nous demander un token. On peut créer ce token avec la commande suivante :

# icingacli setup token create

La prochaine étape de l'assistant vous demande quelles fonctions activer. Il est recommandé de choisir Doc et Monitoring.

L'assistant lance ensuite une série de tests. Il est important de s'assurer que tous les tests sont OK. Il est normal que les tests PostgreSQL s'affichent en jaune, car on utilise MySQL.

Icingaweb2 offre plusieurs backends d'authentification. Pour une grande organisation, il est préférable d'utiliser le backend LDAP. Pour quelques comptes, il est cependant plus simple d'utiliser le backend basé sur une base de données.

Si l'on choisi un backend base de données, il suffit de renter les informations d'authentification que l'on souhaite avoir. La WebUI va ensuite nous informer que la base de donnée n'existe pas encore et nous demander le mot de passe root pour en créer une pour nous. Encore une fois, il est possible de faire cela directement en ligne de commande avec MySQL.

Après avoir finalisé les informations pour l'authentification, il vous faudra donner au WebUI l'accès à la base de donnée créée précédemment pour icinga2. Si vous avez utilisé l'assitant de configuration du paquetage icinga2-ido-mysql, vous pourrez retrouver directement les informations d'authentification à MySQL utilisé par icinga2 dans /etc/icinga2/features-available/ido-mysql.conf.

Et voilà! Votre WebUI devrait être en place et vous devriez pouvoir vous connecter au http://example.org/icingaweb2/

Installation d'un client

Configuration du lien master-client

Par défaut, quand on installe icinga2 sur une machine, le daemon est lancé et icinga2 se met à surveiller l'hôte local. Pour cette documentation, nous allons monter une architecture de surveillance de type [#Configurationencluster "configuration en cluster"]. Cela va nous permettre de pouvoir centraliser la configuration à un seul endroit et de la gérer à travers Git.

Attention! La seule commande icinga2 node <paramètre> que l'on devrait exécuter avec ce type de configuration est icinga2 node wizard au tout début du processus d'installation.

Malgré les apparences, les commandes icinga2 node update-config ou encore icinga2 node add s'appliquent à une configuration de type locale. De plus, ces commandes sont aussi dépréciées.

On commence donc par installer icinga2 :

# wget -O - http://packages.icinga.com/icinga.key | apt-key add -
# echo 'deb http://packages.icinga.com/debian icinga-jessie main' >/etc/apt/sources.list.d/icinga.list
# apt update
# apt install icinga2

Une fois que cela est fait, on lance l'assistant de configuration :

# icinga2 node wizard

L'assistant nous pose plusieurs questions. On y répond de la manière suivante :

Please specify if this is a satellite setup ('n' installs a master setup) [Y/n]: y
Starting the Node setup routine...
Please specifiy the common name (CN) [icinga2-client1]:
Please specify the master endpoint(s) this node should connect to:
Master Common Name (CN from your master setup): icinga2-master
Do you want to establish a connection to the master from this node? [Y/n]: y
Please fill out the master connection information:
Master endpoint host (Your master's IP address or FQDN): 192.168.4.229
Master endpoint port [5665]:
Add more master endpoints? [y/N]: n
Please specify the master connection for CSR auto-signing (defaults to master endpoint host):
Host [192.168.4.229]:
Port [5665]:
information/base: Writing private key to '/etc/icinga2/pki/icinga2-client1.key'.
information/base: Writing X509 certificate to '/etc/icinga2/pki/icinga2-client1.crt'.
information/cli: Fetching public certificate from master (192.168.4.229, 5665):

Certificate information:

 Subject:     CN = icinga2-master
 Issuer:      CN = Icinga CA
 Valid From:  Aug 15 21:03:54 2016 GMT
 Valid Until: Aug 12 21:03:54 2031 GMT
 Fingerprint: D6 6F 56 55 3B 73 16 45 D5 08 F6 FB CE A6 2A 14 F5 24 05 11

Is this information correct? [y/N]: y
information/cli: Received trusted master certificate.

Please specify the request ticket generated on your Icinga 2 master.
 (Hint: # icinga2 pki ticket --cn 'icinga2-sclient1'): 4891c5c4c132908f2794d0ed347c9fbf204491aa
information/cli: Requesting certificate with ticket '4891c5c4c132908f2794d0ed347c9fbf204491aa'.

information/cli: Writing signed certificate to file '/etc/icinga2/pki/icinga2-client1.crt'.
information/cli: Writing CA certificate to file '/etc/icinga2/pki/ca.crt'.
Please specify the API bind host/port (optional):
Bind Host []:
Bind Port []:
Accept config from master? [y/N]: y
Accept commands from master? [y/N]: n

À noter qu'à l'étape où l'assistant demande le ticket généré sur le master, il faut exécuter la commande suivante sur le master et copier l'output dans l'assistant:

icinga2 pki ticket --cn '<nom du client>'

Si client reconnaît maintenant le master, il est nécessaire de configurer le master pour qu'il reconnaisse le client. On va donc modifier le fichier zones.conf sur le master y ajouter la zone et le endpoint du nouveau client :

[...]

object Endpoint "icinga2-client1" {
  host = "<adresse ip du client>"
}

object Zone "icinga2-client1" {
  endpoints = [ "icinga2-sclient1" ]
  parent = "master"
}

Et voilà! En théorie, le master et le client peuvent se parler! Comme nous n'avons pas encore configuré de test sur le nouveau client, il est normal qu'il n'apparaisse pas dans le WebUI.

Ajout de tests sur le client depuis le master

Avec le type de configuration que l'on a choisi, les fichiers de configuration sont modifiés sur le master, qui les synchronise sur le client.

Nous allons donc ajouter nos tests sur le master dans zones.d, le dossier prévu à cet effet. On commence par y créer un nouveau dossier du nom du client que l'on souhaite configurer:

# mkdir /etc/icinga2/zones.d/icinga2-client1

Dans ce dossier, on crée un fichier nommé hosts.conf qui va nous servir à définir un nouvel objet de type Host. Cet objet va nous permettre par la suite de lier d'autres types d'objets à notre nouveau client :

object Host "icinga2-client1" {
  check_command = "hostalive"
  address = "<adresse ip du client>"
  zone = "master"
}

On peut maintenant ajouter de nouveaux tests dans services.conf, des objets de type Service :

object Service "disk" {
  import "generic-service"

  host_name = "icinga2-sclient1"
  check_command = "disk"
}

object Service "ssh" {
  import "generic-service"

  host_name = "icinga2-sclient1"
  check_command = "ssh"
}

Pour que la synchronisation se fasse entre le master et le client, on redémarre icinga2 sur le master :

# service icinga2 reload

Si tout s'est passé correctement, vous devriez voir apparaître une nouvelle machine dans le WebUI, accompagné de trois nouveaux services, ping4, disk et ssh.

Plomberie

Dossiers par défaut d'icinga2

• /etc/icinga2 Dossier des fichiers de configuration
• /usr/share/icinga2/include Dossier des templates & commandes par défaut
• /var/lib/icinga2 Dossier de "travail" d'icinga2, contient la CA, les logs cluster, la configuration chargée et/ou reçue, un fichier dump de l'état du cluster

Fichiers de configuration

Les fichiers de configuration se trouvent dans /etc/icinga2. Tous les fichiers de configuration utilisent la même syntaxe. Il existe d'ailleurs un plugin vim pour cette dernière:

# apt -t jessie-backports install vim-icinga2

La configuration d'icinga2 se base principalement sur des objets de types différents. Par exemple, l'objet Host définit une machine (indépendament de la présence de l'agent icinga2) alors que l'objet Service sert à définir un service et il est rataché à une machine. On peut retrouver une description détaillée de tous les objets ici.

En général, l'emplacement des objets n'est pas réellement important. Dans l'exemple plus haut, on aurait ainsi pu ajouter l'objet Host dans le fichier /etc/icinga2/zones.d/icinga2-client1/foo_bar.conf au lieu de /etc/icinga2/zones.d/icinga2-client1/hosts.conf. C'est cependant un bonne pratique de séparer clairement ses différents objets en fichiers nommés de manière claire.

init.conf

Le premier fichier à être lu au démarrage du daemon. Il sert à définir sous quel groupe et quel user le daemon est lancé.

Note : Sous Debian 8, icinga2 fonctionne sous l'utilisateur et le groupe nagios

icinga2.conf

Le fichier de configuration principal. Il sert surtout à définir les fichiers de configuration qui seront lus, comme /features-enabled/* par exemple. Ce fichier est le second à être lu au démarrage du daemon.

Note : En configuration en cluster, une bonne pratique est de commenter l'inclusion du dossier conf.d

constants.conf

Ce fichier regroupe les constantes globales d'Icinga2. On y trouve entre autres le Salt pour la génération de tokens et le nom de domaine du master (NodeName).

zones.conf

Ce fichier sert à définir les relations entre le master et les clients, comme démontré dans l'exemple de configuration plus haut.

features-available

Les fichiers dans ce dossier sont des plugins qui peuvent être activés avec les commandes suivantes :

# icinga2 feature enable <nom du plugin>
# service icinga2 reload

Une fois activés, il sont symlinkés dans /features-enabled, un peu comme pour Apache.

pki

Ce dossier regroupe les fichiers du Public Key Infrastructure (PKI), qui servent de base d'authentification entre les clients et le master. Dans le cas du master, certains fichiers sont des duplicatas de fichiers dans /var/lib/icinga2/ca/.

scripts

Ce dossier regroupe les différents scripts qui sont lancés lors d'un événement. Par exemple, c'est ici que l'on ajouterais de nouveaux scripts à être lancé pour des objets de type EventCommand.

conf.d

Ce dossier regroupe les configurations de services sur le master et les configuration plus globales, comme les définitions de users et de groupes, ou encore les différents modes de surveillance (24h/7, 8 à 17h, etc.).

repository.d et zones.d

repository.d regroupe les configurations des clients lors d'une synchronisation de type locale. À l'inverse, pour une configuration de type cluster, les fichiers se retrouveraient plutôt dans le dossier zones.d.

Utilisation de NRPE

Lors de la bascule de nagios vers icinga2, il peut être intéréssant de supporter tout les checks fait par NRPE pour fluidifier la transition vers la nouvelle plateforme.

Pour cela, il faut d'abord récupérer le client NRPE :

# apt install nagios-nrpe-plugin

En suite, il suffit juste de créer les services dans la configuration du master pour paramettrer les checks voulu. L'exemple suivant crée un service swap pour la machine remote-nrpe-host qui exécutera la commande check_swap par NRPE.

object Service "nrpe-swap" {
  import "generic-service"

  host_name = "remote-nrpe-host"

  check_command = "nrpe"
  vars.nrpe_command = "check_swap"
}