16 KiB
Cette page a été importée automatiquement de notre ancien wiki mais n'a pas encore été révisée.
Icinga2
Introduction
Icinga2 est un logiciel de surveillance 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. Il est important avant de commencer la mise en place d'Icinga2 de bien réfléchir à la manière dont on souhaite monter notre système. Trois architectures différentes sont possibles:
Configuration locale
Dans cette 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 en cluster
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
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.
L'avantage de cette méthode est que les machines locales n'ont pas besoin d'avoir un daemon qui roule constamment pour effectuer les tests. Cela implique cependant que les machines locales doivent accepter des commandes directement du serveur central, ce qui est peut-être un peu moins sécuritaire.
Plus "d'infos ici".
Installation du master
Core
L'installation du core d'icinga2 sur le master est relativement simple. Cependant, la documentation disponible en ligne prends pour acquis que la version utilisée est celle disponible dans jessie-backports. Il faut donc s'assurer d'avoir la version 2.4 ou supérieure.
# apt -t jessie-backports install icinga2 icinga2-ido-mysql
Le package icinga2-ido-mysql fournit un assistant d'installation pour configurer une base de donnée MySQL automatiquement. Si on le souhaite, il est également possible de le faire manuellement.
Une fois l'installation terminée, il est nécessaire d'activer ido-mysql:
# icinga2 feature enable ido-mysql
Pour finaliser l'installation d'icinga2 en master, nous allons créer un 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:
# icinga2 node wizard
On s'assure finalement que l'ensemble des options voulues sont bien activées en redémarrant le daemon:
# service icinga2 restart
WebUI
Pour fonctionner, le WebUI a besoin d'un serveur web et d'un serveur de base de donnée. Dans les exemples qui suivent, nous utiliseront [/HowtoLAMP/Apache Apache] et [/HowtoLAMP/MySQL MySQL].
Malheureusement, la version 2 du WebUI d'icinga2 n'est pas dans Debian jessie à l'heure actuelle. Il est donc nécessaire soit d'utiliser les packages fournis par Icinga, ou alors d'utiliser la version dans Stretch.
Pour Stretch, il suffit de modifier /etc/apt/sources.list et de s'assurer d'avoir un fichier /etc/apt/preferences qui ressemble au suivant:
Explanation: Debian jessie
Package: *
Pin: release o=Debian,n=jessie
Pin-Priority: 990
Explanation: Debian stretch
Package: *
Pin: release o=Debian,n=stretch
Pin-Priority: 2
Une fois que cela est fait, on met à jour ses sources et on installe les packages nécessaires:
# apt update
# apt install icingaweb2
Il est possible de rouler des commande à partir du WebUI directement. Pour cela, il faut ajouter le user qui roule le WebUI dans Apache au groupe nagios. Avec apache2-mpm-itk, cette étape devrait être superflue car le WebUI devrait déjà rouler sous le user nagios:
# addgroup --system www-data nagios
# icinga2 feature enable command
# service icinga2 restart
On ajoute maintenant un VHost apache dans /etc/apache2/sites-available/icinga2.conf:
<VirtualHost *:80>
ServerName fqdn.org
DocumentRoot /usr/share/icingaweb2/public
<Directory "/usr/share/icingaweb2/public">
Options SymLinksIfOwnerMatch
AllowOverride None
<IfModule mod_authz_core.c>
Require all granted
</IfModule>
SetEnv ICINGAWEB_CONFIGDIR "/etc/icingaweb2"
EnableSendfile Off
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ index.php [NC,L]
</IfModule>
<IfModule !mod_rewrite.c>
DirectoryIndex error_norewrite.html
ErrorDocument 404 /error_norewrite.html
</IfModule>
</Directory>
</VirtualHost>
On active ensuite le VHost et on redémarre apache:
# a2ensite icinga2.conf
# service apache2 reload
Pour continuer l'installation du WebUI, on visite le http://fqdn.org/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ée.
Si l'on choisi un backend base de donnée, il suffit de renter les informations d'authentification que l'on souhaite avoir. Le WebUI va ensuite nous aviser 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. Les informations d'authentification se trouvent dans /etc/icinga2/features-available/ido-mysql.conf.
Et voilà! Votre WebUI devrait être en place et vous devriez pouvoir vous connecter au http://fqdn.org.
Installation du 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 le localhost. 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 rouler avec ce type de configuration est icinga2 node wizard au tout début du processus d'installation.
Malgré les apparences, icinga2 node update-config ou encore icinga2 node add s'appliquent à une configuration de type locale. Il ne faut donc pas les utiliser en cluster!
On commence donc par installer icinga2:
# apt -t jessie-backports install icinga2 icinga2-ido-mysql
Une fois que cela est fait, on roule 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-slave1]:
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]:
warning/cli: Backup file '/etc/icinga2/pki/icinga2-slave1.key.orig' already exists. Skipping backup.
warning/cli: Backup file '/etc/icinga2/pki/icinga2-slave1.crt.orig' already exists. Skipping backup.
information/base: Writing private key to '/etc/icinga2/pki/icinga2-slave1.key'.
information/base: Writing X509 certificate to '/etc/icinga2/pki/icinga2-slave1.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-slave1'): 4891c5c4c132908f2794d0ed347c9fbf204491aa
information/cli: Requesting certificate with ticket '4891c5c4c132908f2794d0ed347c9fbf204491aa'.
warning/cli: Backup file '/etc/icinga2/pki/icinga2-slave1.crt.orig' already exists. Skipping backup.
information/cli: Writing signed certificate to file '/etc/icinga2/pki/icinga2-slave1.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 rouler 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-slave1" {
host = "<adresse ip du client>"
}
object Zone "icinga2-slave1" {
endpoints = [ "icinga2-slave1" ]
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
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-slave1
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-slave1" {
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" {
host_name = "icinga2-slave1"
check_command = "disk"
}
object Service "ssh" {
host_name = "icinga2-slave1"
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.
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 Service sert à définir un service à vérifier sur une machine, alors que l'objet Host définit un nouveau client. 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-slave1/mega_foobar.conf au lieu de /etc/icinga2/zones.d/icinga2-slave1/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é.
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.
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.