Surveiller plusieurs serveurs avec Icinga2

Mise à jour suite au passage de la version 2.11.0 de Icinga2

Encore un article sur Icinga2.

Maintenant que j’ai commencé à installer quelques services sur mon Raspberry, ça serait bien de pouvoir le surveiller. Comme Icinga2 tourne déjà sur mon serveur OVH et qu’il gère la surveillance multi serveurs, on va configurer Icinga2 afin qu’il puisse également surveiller mon Raspberry.

Je ne détaillerai pas du tout l’installation d’Icinga2 sur mon serveur OVH sous Debian, je l’ai déjà traité dans un précédent article. De même je ne détaillerai pas l’utilisation des fichiers de configuration ou la modification/création d’un service car, là aussi, ça a déjà été traité ici et ici.
Je vais donc partir du principe que vous avez suivi ces articles et que votre serveur principal a déjà Icinga2 et Icingaweb2 d’installé et configuré.

Le fonctionnement d’Icinga2 en multi serveur est très simple : il y a un serveur maître et un ou plusieurs serveurs clients.
Les serveurs clients vont être synchronisés avec le maître afin que ce dernier puisse leur faire exécuter des vérifications à distance (mais exécutées en local sur le client) et que les clients puissent lui renvoyer les résultats de ces vérifications.
Icingaweb2 n’est installé que sur le serveur maître vu que le résultat de toutes les vérifications vont remonter au maître.
Le serveur maître peut bien évidemment lancer des vérifications en local.

Pour information, j’ai choisi cette configuration vu que je n’ai que deux serveurs à surveiller mais il existe d’autres configurations.
En plus du maître et du/des client(s), il peut y avoir des satellites placés entre le maître et les clients. N’ayant pas besoin d’une telle configuration, je ne me suis pas renseigné sur l’utilité de rajouter un satellite. J’imagine que ça permet de pouvoir lancer des tests sur des serveurs clients accessibles en local depuis le serveur satellite mais pas reliés à Internet.
Vous pouvez également avoir plusieurs serveurs maître, qui sont des répliques, afin d’éviter que votre système de surveillance ne fonctionne plus en cas de panne du serveur maître.

Maintenant que l’explication est terminée, passons à l’installation.

1) Prérequis sur le Raspberry

Tout d’abord, il va vous falloir un serveur de base de donnée SQL. On va installer MariaDB. Tapez la commande

[pastacode lang=”bash” manual=”sudo%20aptitude%20install%20mariadb-server%C2%A0php-mysql” message=”” highlight=”” provider=”manual”/]

. php-mysql sert à ce que PHP puisse le dialoguer avec le serveur MariaDB.

On va commencer par changer le mot de passe de l’utilisateur root avec la commande

[pastacode lang=”bash” manual=”sudo%20mysql_secure_installation” message=”” highlight=”” provider=”manual”/]

Renseignez le mot de passe que vous voulez pour le compte root (évitez 1234 comme mot de passe), puis vous aurez à répondre à une série de questions :

[pastacode lang=”bash” manual=”Remove%20anonymous%20users%3F%20%5BY%2Fn%5D%20-%3E%20r%C3%A9pondre%20Yes%0ADisallow%20root%20login%20remotely%3F%20%5BY%2Fn%5D%20-%3E%20r%C3%A9pondre%20Yes%0ARemove%20test%20database%20and%20access%20to%20it%3F%20%5BY%2Fn%5D%20-%3E%20r%C3%A9pondre%20Yes%0AReload%20privilege%20tables%20now%3F%20%5BY%2Fn%5D%20-%3E%20r%C3%A9pondre%20Yes” message=”” highlight=”” provider=”manual”/]

Si comme moi vous avez du mal avec les requêtes SQL, je vous invite à installer PHPMyAdmin, une interface web permettant de manipuler vos bases de données. Pour ça, tapez la commande

[pastacode lang=”bash” manual=”sudo%20aptitude%20install%20phpmyadmin” message=”” highlight=”” provider=”manual”/]

Vous pourrez y accéder à vous rendant à l’adresse http://ipduserveur/phpmyadmin

Vous risquez d’avoir le message d’erreur suivant en essayant de vous connecter avec le compte root : ERROR 1698 (28000): Access denied for user ‘root’@’localhost’.
La nouvelle politique de sécurité de MariaDB est d’utiliser le socket unix pour se connecter avec le compte root au lieu d’y associer un mot de passe.
Pour remédier à ce problème, il va falloir créer un nouvel utilisateur. Tapez les lignes suivantes dans la console :

[pastacode lang=”bash” manual=”sudo%20mysql%20-u%20root%0Ause%20mysql%3B%0ACREATE%20USER%20’nom_utilisateur’%40’localhost’%20IDENTIFIED%20BY%20’motdepasse’%20WITH%20GRANT%20OPTION%3B%0AGRANT%20ALL%20PRIVILEGES%20ON%20*.*%20TO%20’nom_utilisateur’%40’localhost’%3B%0Aflush%20privileges%3B%0Aexit%3B” message=”” highlight=”” provider=”manual”/]

Vous pouvez maintenant vous connecter avec l’utilisateur que vous venez de créer.

Passons à l’installation d’Icinga2.

2) Installation d’Icinga2 sur le Raspberry

Sur Raspbian, la version d’Icinga2 présente dans les dépôts est un peu ancienne. Heureusement, il existe un dépôt non-officiel qui propose une version plus récente d’Icinga2. Ouvrez le fichier /etc/apt/sources.list et rajoutez les lignes suivantes :

[pastacode lang=”bash” manual=”%23%20d%C3%A9p%C3%B4t%20Icinga%0Adeb%20http%3A%2F%2Fpackages.icinga.com%2Fraspbian%20icinga-stretch%20main” message=”” highlight=”” provider=”manual”/]

On va ensuite importer la clé de ce dépôt avec la commande, à lancer en root,

[pastacode lang=”bash” manual=”wget%20-O%20-%20https%3A%2F%2Fpackages.icinga.com%2Ficinga.key%20%7C%20apt-key%20add%20-” message=”” highlight=”” provider=”manual”/]

Y a plus qu’à mettre à jour les dépôts et installer Icinga2 et les plugins avec la commande

[pastacode lang=”bash” manual=”sudo%20aptitude%20update%20%26%26%20sudo%20aptitude%20install%C2%A0icinga2%20monitoring-plugins” message=”” highlight=”” provider=”manual”/]

On va activer le module api (obligatoire) ainsi que le module debuglog (optionnel) qui nous sera utile si jamais Icinga2 rencontre des problèmes. Pour activer ces deux modules, tapez la commande suivante :

[pastacode lang=”bash” manual=”sudo%20icinga2%20feature%20enable%20api%20debuglog” message=”” highlight=”” provider=”manual”/]

Y a pas plus à faire au niveau de l’installation pour le client. On va donc pouvoir passer à la configuration.

3) Configuration du serveur maître

Sur le serveur maître (mon serveur OVH dans mon cas), lancez la commande

[pastacode lang=”bash” manual=”sudo%20icinga2%20node%20wizard” message=”” highlight=”” provider=”manual”/]

Vous allez avoir une série de question, répondez comme suit :

[pastacode lang=”bash” manual=”Welcome%20to%20the%20Icinga%202%20Setup%20Wizard!%0A%0AWe%20will%20guide%20you%20through%20all%20required%20configuration%20details.%0A%0APlease%20specify%20if%20this%20is%20a%20satellite%2Fclient%20setup%20(‘n’%20installs%20a%20master%20setup)%20%5BY%2Fn%5D%3A%20n%0A%0AStarting%20the%20Master%20setup%20routine…%0A%0APlease%20specify%20the%20common%20name%20(CN)%20%5BFQDNduserveur%5D%3A%20FQDNduserveur%0AReconfiguring%20Icinga…%0AChecking%20for%20existing%20certificates%20for%20common%20name%20’FQDNduserveur’…%0AGenerating%20master%20configuration%20for%20Icinga%202.%0A%0A’api’%20feature%20already%20enabled.%0A%0AMaster%20zone%20name%20%5Bmaster%5D%3A%0A%0ADefault%20global%20zones%3A%20global-templates%20director-global%0ADo%20you%20want%20to%20specify%20additional%20global%20zones%3F%20%5By%2FN%5D%3A%0APlease%20specify%20the%20API%20bind%20host%2Fport%20(optional)%3A%0ABind%20Host%20%5B%5D%3A%0ABind%20Port%20%5B%5D%3A%0A%0ADo%20you%20want%20to%20disable%20the%20inclusion%20of%20the%20conf.d%20directory%20%5BY%2Fn%5D%3A%20n%0A%0ADone.%0A%0ANow%20restart%20your%20Icinga%202%20daemon%20to%20finish%20the%20installation!” message=”” highlight=”” provider=”manual”/]

Pour le common name, par convention, on met le FQDN. Il ne vous reste plus qu’à redémarrer Icinga2 avec la commande

[pastacode lang=”bash” manual=”sudo%20systemctl%20restart%20icinga2″ message=”” highlight=”” provider=”manual”/]

On passe à la configuration du client (mon Raspberry dans mon cas)

4) Configuration du client

On utilise la même commande pour la configuration,

[pastacode lang=”bash” manual=”sudo%20icinga2%20node%20wizard” message=”” highlight=”” provider=”manual”/]

Vous allez de nouveau avoir une série de question auxquelles il faudra répondre un peu différement :

[pastacode lang=”bash” manual=”Welcome%20to%20the%20Icinga%202%20Setup%20Wizard!%0A%0AWe%20will%20guide%20you%20through%20all%20required%20configuration%20details.%0A%0APlease%20specify%20if%20this%20is%20a%20satellite%2Fclient%20setup%20(‘n’%20installs%20a%20master%20setup)%20%5BY%2Fn%5D%3A%20y%0A%0AStarting%20the%20Client%2FSatellite%20setup%20routine…%0A%0APlease%20specify%20the%20common%20name%20(CN)%20%5BFQDNduclient%5D%3A%20FQDNduclient%0APlease%20specify%20the%20parent%20endpoint(s)%20(master%20or%20satellite)%20where%20this%20node%20should%20connect%20to%3A%0AMaster%2FSatellite%20Common%20Name%20(CN%20from%20your%20master%2Fsatellite%20node)%3A%20FQDNduserveurma%C3%AEtre%0ADo%20you%20want%20to%20establish%20a%20connection%20to%20the%20parent%20node%20from%20this%20node%3F%20%5BY%2Fn%5D%3Ay%0APlease%20specify%20the%20master%2Fsatellite%20connection%20information%3A%0AMaster%2FSatellite%20endpoint%20host%20(IP%20address%20or%20FQDN)%3A%20IPduserveurma%C3%AEtre%2FFQDNduserveurma%C3%AEtre%0AMaster%2FSatellite%20endpoint%20port%20%5B5665%5D%3A%205665%0AAdd%20more%20master%2Fsatellite%20endpoints%3F%20%5By%2FN%5D%3An%0AParent%20certificate%20information%3A%0A%0A%20Subject%3A%20%20%20%20%20CN%20%3D%20FQDNduserveurma%C3%AEtre%0A%20Issuer%3A%20%20%20%20%20%20CN%20%3D%20Icinga%20CA%0A%20Valid%20From%3A%20%20Sep%20%207%2013%3A41%3A24%202017%20GMT%0A%20Valid%20Until%3A%20Sep%20%203%2013%3A41%3A24%202032%20GMT%0A%20Fingerprint%3A%20AC%2099%208B%202B%203D%20B0%2001%2000%20E5%2021%20FA%2005%202E%20EC%20D5%20A9%20EF%209E%20AA%20E3%0A%0AIs%20this%20information%20correct%3F%20%5By%2FN%5D%3A%20y%0APlease%20specify%20the%20request%20ticket%20generated%20on%20your%20Icinga%202%20master%20(optional).%0A%20(Hint%3A%20%23%20icinga2%20pki%20ticket%20–cn%20’FQDNduclient’)%3A%0A4f75d2ecd253575fe9180938ebff7cbca262f96e%0APlease%20specify%20the%20API%20bind%20host%2Fport%20(optional)%3A%0ABind%20Host%20%5B%5D%3A%0ABind%20Port%20%5B%5D%3A%0A%0AAccept%20config%20from%20parent%20node%3F%20%5By%2FN%5D%3A%20y%0AAccept%20commands%20from%20parent%20node%3F%20%5By%2FN%5D%3A%20y%0A%0A%0AReconfiguring%20Icinga…%0A%0ADone.%0A%0ANow%20restart%20your%20Icinga%202%20daemon%20to%20finish%20the%20installation!” message=”” highlight=”” provider=”manual”/]

Lorsque vous aurez la phrase “(Hint: # icinga2 pki ticket –cn ‘icinga2-client1.localdomain’):” qui apparaîtra lors de la configuration, il faudra que vous lanciez la commande indiquée sur le serveur maître. Il va communiquer avec le client et vous donner une clé qu’il faudra ensuite rentrer dans la fenêtre de configuration du client.

Il ne vous reste plus qu’à redémarrer Icinga2 sur le client et le maître avec la commande

[pastacode lang=”bash” manual=”sudo%20systemctl%20restart%20icinga2″ message=”” highlight=”” provider=”manual”/]

On va pouvoir passer à la création des services sur le serveur maître et voir comment faire pour qu’ils soient lancés sur le client.

5) Création des services clients

Sur le client, ouvrez le fichier /etc/icinga2/zones.conf et ajoutez les lignes suivantes :

[pastacode lang=”bash” manual=”object%20Endpoint%20%22FQDNduma%C3%AEtre%22%20%7B%0A%20%20%20%20%20%20%20%20host%20%3D%20%22FQDNduma%C3%AEtre%22%0A%20%20%20%20%20%20%20%20port%20%3D%20%225665%22%0A%7D%0A%0Aobject%20Endpoint%20%22FQDNduclient%22%20%7B%0A%20%20%20%20%20%20%20%20host%20%3D%20%22FQDNduclient%22%0A%20%20%20%20%20%20%20%20port%20%3D%20%225665%22%0A%7D%0A%0A%0Aobject%20Zone%20%22master%22%20%7B%0A%20%20%20%20%20%20%20%20endpoints%20%3D%20%5B%20%22FQDNduma%C3%AEtre%22%20%5D%0A%7D%0A%0Aobject%20Zone%20%22FQDNduclient%22%20%7B%0A%20%20%20%20%20%20%20%20endpoints%20%3D%20%5B%20%22FQDNduclient%22%20%5D%0A%20%20%20%20%20%20%20%20parent%20%3D%20%22master%22%0A%7D” message=”” highlight=”” provider=”manual”/]

Petite explication. On commence par créer deux “Endpoint”, un correspondant au serveur maître et un autre correspondant au client. Un “Endpoint” sert à donner à Icinga2 les informations nécessaire pour pouvoir lancer des tests sur une machine distante. On indique le host (adresse ip ou nom de domaine correspondant à la machine) et le port sur lequel se connecter (il faut évidemment que ce port soit accessible).
On crée ensuite deux zones, une zone nommée “master” à laquelle on lie le endpoint du serveur maître, et une zone client qu’on lie au endpoint du client et où on indique également qu’elle est une zone enfant de la zone “master”. Ainsi, on fait comprendre à Icinga2 que la zone “master” ordonnera les tests qui seront effectués sur la zone client.

Il faut faire exactement la même chose sur le serveur maître (ouvrir le même fichier et ajouter les mêmes lignes).

ouvrez le fichier /etc/icinga2/conf.d/hosts.conf et ajoutez les lignes suivantes :

[pastacode lang=”bash” manual=”object%20Host%20%22FQDNduclient%22%20%7B%0A%0A%20%20%2F*%20Import%20the%20default%20host%20template%20defined%20in%20%60templates.conf%60.%20*%2F%0A%20%20import%20%22generic-host%22%0A%0A%20%20%2F*%20Specify%20the%20address%20attributes%20for%20checks%20e.g.%20%60ssh%60%20or%20%60http%60.%20*%2F%0A%20%20address%20%3D%20%22127.0.0.1%22%0A%20%20address6%20%3D%20%22%3A%3A1%22%0A%0A%20%20vars.endpoint%20%3D%20%22FQDNduclient%22%0A%0A%20%20vars.disks%5B%22disk%20%2F%22%5D%20%3D%20%7B%0A%20%20%20%20disk_partitions%20%3D%20%22%2F%22%0A%20%20%20%20disk_units%20%3D%20%22GB%22%0A%20%20%7D%0A%0A%20%20%2F*%20Modify%20ssh%20port%20number%20*%2F%0A%20%20vars.ssh_port%20%3D%20portssh%0A%0A%20%20%2F*%20Set%20custom%20attribute%20%60os%60%20for%20hostgroup%20assignment%20in%20%60groups.conf%60.%20*%2F%0A%20%20vars.os%20%3D%20%22Raspbian%22%0A%0A%20%20%2F*%20Define%20http%20vhost%20attributes%20for%20service%20apply%20rules%20in%20%60services.conf%60.%20*%2F%0A%20%20vars.http_vhosts%5B%22http%22%5D%20%3D%20%7B%0A%20%20%20%20http_uri%20%3D%20%22%2F%22%0A%20%20%7D%0A%0A%20%20%2F*%20Define%20notification%20mail%20attributes%20for%20notification%20apply%20rules%20in%20%60notifications.conf%60.%20*%2F%0A%20%20vars.notification%5B%22mail%22%5D%20%3D%20%7B%0A%20%20%2F*%20The%20UserGroup%20%60icingaadmins%60%20is%20defined%20in%20%60users.conf%60.%20*%2F%0A%20%20groups%20%3D%20%5B%20%22icingaadmins%22%20%5D%0A%20%20%7D%0A%0A%0A%7D” message=”” highlight=”” provider=”manual”/]

Pensez à changer “portssh” par le port que vous utilisez sur votre client.
On a rajouté un host correspondant au client. Attention, la valeur de la variable “vars.endpoint” doit absolument correspondre au nom du endpoint du client que vous avez rentré dans le fichier zones.conf.
Il vous faudra également ajouter la ligne vars.endpoint = “FQDNduserveurmaître” dans le host du serveur maître (toujours dans le fichier hosts.conf). Là aussi, il faut que le nom du endpoint corresponde.

Le fait de rajouter cette ligne dans le host du client et du maître va faire qu’Icinga2 va pouvoir lancer des tests non plus en local sur le maître comme c’était le cas avec la configuration de mes articles précédents, mais va se connecter à distance au client et lui ordonner de lancer X test (selon ce que vous lui demanderez de lancer comme test) en local. Vous vous demandez peut-être comment ça marche en détail et pourquoi les deux hosts ont la même ip (qui représente l’ip locale) ?
Le Icinga2 maître va se connecter au Icinga2 client via le endpoint créé dans le fichier zones.conf, puis il va ordonner au Icinga2 client de lancer un test, la place restante sur le disque dur par exemple, sur l’ip renseignée dans le host client du fichier hosts.conf.
Icinga2 client va donc lancer le test demandé sur l’IP renseignée dans le host, 127.0.0.1, donc en local. Une fois le test effectué, il va envoyer le résultat au Icinga2 maître via le endpoint maître créé dans le fichier zones.conf

Il ne nous reste plus qu’à configurer les services

Ouvrez le fichier /etc/icinga2/conf.d/services.conf. Par défaut vous devez avoir un certain nombre de services déjà actif, comme “ping4″ par exemple. Il doit ressembler à ça :

[pastacode lang=”bash” manual=”apply%20Service%20%22ping%22%20%7B%0A%20%20import%20%22generic-service%22%0A%0A%20%20check_command%20%3D%20%22ping%22%0A%0A%20%20assign%20where%20host.address%0A%7D” message=”” highlight=”” provider=”manual”/]

C’est un service qui lance la commande ping sur tous les host qui ont une adresse ip renseignée. Si on le laisse tel quel, il va lancer le test sur le host maître et sur le host client en utilisant l’IP renseignée (127.0.0.1) pour chaque host, sans utiliser le endpoint. Les deux test vont donc être lancés en local sur le maître. Pour utiliser le endpoint, on va devoir faire une petite modif :

[pastacode lang=”bash” manual=”apply%20Service%20%22ping4%22%20%7B%0A%20%20import%20%22generic-service%22%0A%0A%20%20check_command%20%3D%20%22ping4%22%0A%0A%20%20command_endpoint%20%3D%20host.vars.endpoint%0A%0A%20%20assign%20where%20host.vars.endpoint%0A%7D” message=”” highlight=”” provider=”manual”/]

La ligne assign where host.address a été remplacée par assign where host.vars.endpoint et la ligne command_endpoint = host.vars.endpoint a été ajoutée.
assign where host.vars.endpoint signifie que ce test s’exécutera sur tous les hosts qui ont une variable “vars.endpoint” et command_endpoint = host.vars.endpoint signifie que le test s’effectuera via le endpoint renseigné dans le host.

Si vous n’avez que très peu de service commun entre le maître et le client, vous pouvez créez la variable vars.maitre_endpoint = “FQDNduserveurmaître” pour le host du maître et vars.client_endpoint = “FQDNduclient” pour le host du client et dans le fichier services.conf, puis assigner un service soit au maître soit au client en mettant soit assign where host.vars.client_endpoint et  command_endpoint = host.vars.client_endpoint pour le client, soit assign where host.vars.maitre_endpoint et  command_endpoint = host.vars.maitre_endpoint pour le maître.
Dans mon cas, comme j’ai beaucoup de services communs à mon serveur OVH et mon Raspberry, j’ai préféré créé une variable “endpoint” globale.

Attention, si vous utilisez un service que vous avez créé manuellement, il faut qu’il existe également dans le fichier services.conf sur le client pour qu’il puisse l’exécuter.

Voilà, il ne vous reste plus qu’à redémarrer Icinga2 sur le maître et le client et tout devrait fonctionner.

 

Source : https://www.icinga.com/docs/icinga2/latest/doc/06-distributed-monitoring/

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.