Date de dernière mise à jour : le 12 septembre 2018 à 20 h 52 min

Surveiller plusieurs serveurs avec 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 sudo aptitude install mariadb-server php-mysql. 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 sudo mysql_secure_installation. 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 :

Remove anonymous users? [Y/n] -> répondre Yes
Disallow root login remotely? [Y/n] -> répondre Yes
Remove test database and access to it? [Y/n] -> répondre Yes
Reload privilege tables now? [Y/n] -> répondre Yes

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 sudo aptitude install phpmyadmin.
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 :

sudo mysql -u root
use mysql;
CREATE USER 'nom_utilisateur'@'localhost' IDENTIFIED BY 'motdepasse' WITH GRANT OPTION;
GRANT ALL PRIVILEGES ON *.* TO 'nom_utilisateur'@'localhost';
flush privileges;
exit;

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 :

# dépôt Icinga
deb http://packages.enda.eu/debian icinga-stretch main

On va ensuite importer la clé de ce dépôt avec la commande, à lancer en root, wget -O - https://packages.enda.eu/enda.key | apt-key add -. Y a plus qu’à mettre à jour les dépôts et installer Icinga2 et les plugins avec la commande sudo aptitude update && sudo aptitude install icinga2 monitoring-plugins.
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 : sudo icinga2 feature enable api debuglog.

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 sudo icinga2 node wizard. Vous allez avoir une série de question, répondez comme suit :

Welcome to the Icinga 2 Setup Wizard!

We will guide you through all required configuration details.

Please specify if this is a satellite/client setup ('n' installs a master setup) [Y/n]: n

Starting the Master setup routine...

Please specify the common name (CN) [FQDNduserveur]: FQDNduserveur
Reconfiguring Icinga...
Checking for existing certificates for common name 'FQDNduserveur'...
Generating master configuration for Icinga 2.

'api' feature already enabled.

Master zone name [master]:

Default global zones: global-templates director-global
Do you want to specify additional global zones? [y/N]:
Please specify the API bind host/port (optional):
Bind Host []:
Bind Port []:

Do you want to disable the inclusion of the conf.d directory [Y/n]: n

Done.

Now restart your Icinga 2 daemon to finish the installation!

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

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

4) Configuration du client

On utilise la même commande pour la configuration, sudo icinga2 node wizard.

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

Welcome to the Icinga 2 Setup Wizard!

We will guide you through all required configuration details.

Please specify if this is a satellite/client setup ('n' installs a master setup) [Y/n]: y

Starting the Client/Satellite setup routine...

Please specify the common name (CN) [FQDNduclient]: FQDNduclient
Please specify the parent endpoint(s) (master or satellite) where this node should connect to:
Master/Satellite Common Name (CN from your master/satellite node): FQDNduserveurmaître
Do you want to establish a connection to the parent node from this node? [Y/n]:y
Please specify the master/satellite connection information:
Master/Satellite endpoint host (IP address or FQDN): IPduserveurmaître/FQDNduserveurmaître
Master/Satellite endpoint port [5665]: 5665
Add more master/satellite endpoints? [y/N]:n
Parent certificate information:

 Subject:     CN = FQDNduserveurmaître
 Issuer:      CN = Icinga CA
 Valid From:  Sep  7 13:41:24 2017 GMT
 Valid Until: Sep  3 13:41:24 2032 GMT
 Fingerprint: AC 99 8B 2B 3D B0 01 00 E5 21 FA 05 2E EC D5 A9 EF 9E AA E3

Is this information correct? [y/N]: y
Please specify the request ticket generated on your Icinga 2 master (optional).
 (Hint: # icinga2 pki ticket --cn 'FQDNduclient'):
4f75d2ecd253575fe9180938ebff7cbca262f96e
Please specify the API bind host/port (optional):
Bind Host []:
Bind Port []:

Accept config from parent node? [y/N]: y
Accept commands from parent node? [y/N]: y


Reconfiguring Icinga...

Done.

Now restart your Icinga 2 daemon to finish the installation!

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 sudo systemctl restart icinga2

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 :

object Endpoint "FQDNdumaître" {
        host = "FQDNdumaître"
        port = "5665"
}

object Endpoint "FQDNduclient" {
        host = "FQDNduclient"
        port = "5665"
}


object Zone "master" {
        endpoints = [ "FQDNdumaître" ]
}

object Zone "FQDNduclient" {
        endpoints = [ "FQDNduclient" ]
        parent = "master"
}

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).

Sur le serveur maître, ouvrez le fichier /etc/icinga2/conf.d/hosts.conf et ajoutez les lignes suivantes :

object Host "FQDNduclient" {

  /* Import the default host template defined in `templates.conf`. */
  import "generic-host"

  /* Specify the address attributes for checks e.g. `ssh` or `http`. */
  address = "127.0.0.1"
  address6 = "::1"

  vars.endpoint = "FQDNduclient"

  vars.disks["disk /"] = {
    disk_partitions = "/"
    disk_units = "GB"
  }

  /* Modify ssh port number */
  vars.ssh_port = portssh

  /* Set custom attribute `os` for hostgroup assignment in `groups.conf`. */
  vars.os = "Raspbian"

  /* Define http vhost attributes for service apply rules in `services.conf`. */
  vars.http_vhosts["http"] = {
    http_uri = "/"
  }

  /* Define notification mail attributes for notification apply rules in `notifications.conf`. */
  vars.notification["mail"] = {
  /* The UserGroup `icingaadmins` is defined in `users.conf`. */
  groups = [ "icingaadmins" ]
  }


}

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 :

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

  check_command = "ping"

  assign where host.address
}

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 :

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

  check_command = "ping4"

  command_endpoint = host.vars.endpoint

  assign where host.vars.endpoint
}

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.