Refactor Icinga
This commit is contained in:
parent
e99c9334fc
commit
1d136c531d
203
HowtoIcinga.md
203
HowtoIcinga.md
|
|
@ -52,23 +52,104 @@ Dans la suite, on va détailler la configuration la configuration centrale et la
|
|||
* icinga2-client1 (192.0.2.10) qui va recevoir la configuration du master
|
||||
* icinga2-client2 (192.0.2.20) qui va être juste servir de pont d'éxécution de commandes
|
||||
|
||||
### Installation du master
|
||||
|
||||
#### Icinga2
|
||||
|
||||
L'installation 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.
|
||||
L'installation d'`icinga2` 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
|
||||
|
||||
# icinga2 --version
|
||||
icinga2 - The Icinga 2 network monitoring daemon (version: r2.6.3-1)
|
||||
|
||||
Copyright (c) 2012-2017 Icinga Development Team (https://www.icinga.com/)
|
||||
License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl2.html>
|
||||
This is free software: you are free to change and redistribute it.
|
||||
There is NO WARRANTY, to the extent permitted by law.
|
||||
|
||||
Application information:
|
||||
Installation root: /usr
|
||||
Sysconf directory: /etc
|
||||
Run directory: /run
|
||||
Local state directory: /var
|
||||
Package data directory: /usr/share/icinga2
|
||||
State path: /var/lib/icinga2/icinga2.state
|
||||
Modified attributes path: /var/lib/icinga2/modified-attributes.conf
|
||||
Objects path: /var/cache/icinga2/icinga2.debug
|
||||
Vars path: /var/cache/icinga2/icinga2.vars
|
||||
PID path: /run/icinga2/icinga2.pid
|
||||
|
||||
System information:
|
||||
Platform: Debian GNU/Linux
|
||||
Platform version: 8 (jessie)
|
||||
Kernel: Linux
|
||||
Kernel version: 3.16.0-4-amd64
|
||||
Architecture: x86_64
|
||||
|
||||
Build information:
|
||||
Compiler: GNU 4.9.2
|
||||
Build host: smithers
|
||||
~~~
|
||||
|
||||
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 pour l'authentification avec les autres instances `icinga2` du cluster 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 :
|
||||
## Configuration
|
||||
|
||||
La configuration d'icinga2 réside essentiellement dans `/etc/icinga2`
|
||||
|
||||
~~~
|
||||
/etc/icinga2
|
||||
├── conf.d
|
||||
│ └── *.conf
|
||||
├── constants.conf
|
||||
├── features-available
|
||||
│ └── *.conf
|
||||
├── features-enabled
|
||||
│ └── *.conf
|
||||
├── icinga2.conf
|
||||
├── init.conf
|
||||
├── pki
|
||||
├── repository.d
|
||||
│ └── README
|
||||
├── scripts
|
||||
│ ├── mail-host-notification.sh
|
||||
│ └── mail-service-notification.sh
|
||||
├── zones.conf
|
||||
└── zones.d
|
||||
└── README
|
||||
~~~
|
||||
|
||||
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 surveillée (indépendament de la présence de l'agent icinga2) alors que l'objet `Service` sert à définir un service rataché à une machine. On peut retrouver une description détaillée de tous les objets [ici (en anglais)](http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/object-types).
|
||||
|
||||
En général, le nom des fichiers contenant 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.
|
||||
|
||||
|
||||
### Instance master
|
||||
|
||||
#### Icinga2
|
||||
|
||||
Pour configurer Icinga2 en master, il faut se servir de son assistant de configuration. Il se chargera de créer une CA pour l'authentification avec les autres instances `icinga2` du cluster 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
|
||||
Welcome to the Icinga 2 Setup Wizard!
|
||||
We'll guide you through all required configuration details.
|
||||
|
||||
|
||||
Please specify if this is a satellite setup ('n' installs a master setup) [Y/n]: n
|
||||
Starting the Master setup routine...
|
||||
Please specify the common name (CN) [ivre.evolix.net]:
|
||||
Checking for existing certificates for common name 'ivre.evolix.net'...
|
||||
Certificates not yet generated. Running 'api setup' now.
|
||||
information/cli: Generating new CA.
|
||||
......
|
||||
Done.
|
||||
|
||||
Now restart your Icinga 2 daemon to finish the installation!
|
||||
~~~
|
||||
|
||||
Après l'exécution de l'assistant, notre master est configuré dans une zone ayant le même nom que lui. On termine par un redémarrage complet du daemon pour activer les changements de la configuration.
|
||||
|
|
@ -77,7 +158,7 @@ Après l'exécution de l'assistant, notre master est configuré dans une zone ay
|
|||
# service icinga2 restart
|
||||
~~~
|
||||
|
||||
### Interface web
|
||||
#### Interface web
|
||||
|
||||
Pour fonctionner, l'interface web a besoin d'un serveur web avec PHP et d'un serveur de bases de données (MySQL ou PostgreSQL). Dans la suite de l'exemple, nous utiliseront [/HowtoApache]() et [/HowtoLAMP/MySQL]().
|
||||
|
||||
|
|
@ -87,7 +168,6 @@ Ici, MySQL va servir à 2 choses :
|
|||
* Contenir les informations de configuration d'icinga2, le statut 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
|
||||
~~~
|
||||
|
||||
|
|
@ -128,9 +208,9 @@ Après avoir finalisé les informations pour l'authentification, il vous faudra
|
|||
|
||||
Et voilà! Votre interface web devrait être en place et vous devriez pouvoir vous connecter au <http://example.org/icingaweb2/>
|
||||
|
||||
## Installation d'un client
|
||||
### Configuration d'un client
|
||||
|
||||
### Installation & configuration minimale
|
||||
#### Configuration minimale
|
||||
|
||||
Par défaut, quand on installe icinga2 sur une machine, le daemon est lancé et icinga2 se met à surveiller l'hôte local. Pour cet exemple, le client va être configuré de manière minimale pour juste le ratacher au master du cluster.
|
||||
C'est dans la configuration que l'on fera sur la machine `icinga2-master` que l'on va décider comment on utilise la machine.
|
||||
|
|
@ -139,24 +219,14 @@ C'est dans la configuration que l'on fera sur la machine `icinga2-master` que l'
|
|||
|
||||
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 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 :
|
||||
On lance l'assistant de configuration :
|
||||
|
||||
~~~
|
||||
# icinga2 node wizard
|
||||
~~~
|
||||
Welcome to the Icinga 2 Setup Wizard!
|
||||
We'll guide you through all required configuration details.
|
||||
|
||||
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]:
|
||||
|
|
@ -180,7 +250,7 @@ Certificate information:
|
|||
Issuer: CN = Icinga CA
|
||||
Valid From: Aug 15 21:03:54 2016 GMT
|
||||
Valid Until: Aug 12 21:03:54 2031 GMT
|
||||
Fingerprint: 13 37 FF 42 00 A6 D6 DE DB EE F6 73 16 45 2A 14 F5 24 05 11
|
||||
Fingerprint: 13 37 FF 42 00 13 00 DE DB EE F0 00 16 45 2A 14 F5 00 CA FE
|
||||
|
||||
Is this information correct? [y/N]: y
|
||||
information/cli: Received trusted master certificate.
|
||||
|
|
@ -228,7 +298,7 @@ object Zone "icinga2-client1" {
|
|||
|
||||
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 la WebUI.
|
||||
|
||||
### Cas A - Client avec configuration centrale sur le master
|
||||
#### Cas A - Client avec configuration centrale sur 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(s) client(s).
|
||||
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 correspondant à la zone (donc le client appartenant à celle-ci) que l'on souhaite configurer :
|
||||
|
|
@ -295,7 +365,7 @@ apply Service "ssh" {
|
|||
}
|
||||
~~~
|
||||
|
||||
### Cas B - Configuration en pont d'éxécution de commandes
|
||||
#### Cas B - Configuration en pont d'éxécution de commandes
|
||||
|
||||
Dans ce cas présent, toute la configuration va rester sur la machine `icinga2-master`. (et donc dans le dossier `/etc/icinga2/zone.d/icinga2-master/`).
|
||||
|
||||
|
|
@ -329,7 +399,7 @@ object Service "ssh" {
|
|||
La définition de l'hôte et des services est quasi identique que dans le cas précédent. Cependant, il faut ajouter en plus l'attribut `command_endpoint` aux objets de type `Service` pour definir l'`Endpoint` qui doit être commandé pour exécuter la commande.
|
||||
|
||||
|
||||
### Cas C (bonus) - Monitoring d'une machine distante sans icinga2
|
||||
#### Cas C (bonus) - Monitoring d'une machine distante sans icinga2
|
||||
|
||||
Comme annoncé plus haut, il est aussi possible de surveiller une machine qui n'aurait pas icinga2 par d'autres moyens comme NRPE ou SSH. La commande de l'exécution des checks devra alors être prise en charge par un noeud du cluster icinga2. Idealement, un `master` ou un `satellite`. Ainsi, la configuration proposée doit être entreposée dans le dossier de la zone qui aura la charge de la surveillance de la machine.
|
||||
|
||||
|
|
@ -342,7 +412,7 @@ object Host "no-icinga2-host" {
|
|||
}
|
||||
~~~
|
||||
|
||||
#### Utilisation de NRPE
|
||||
##### Utilisation de NRPE
|
||||
|
||||
Lors d'une migration 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.
|
||||
|
||||
|
|
@ -365,7 +435,7 @@ object Service "swap" {
|
|||
}
|
||||
~~~
|
||||
|
||||
#### Utilisation de SSH
|
||||
##### Utilisation de SSH
|
||||
|
||||
Dans certaines situations, l'utilisation de NRPE, ou icinga2 n'est pas possible (restrictions firewall, NAT...). Dans ces cas là, on peut aussi exécuter des commandes via une connexion SSH.
|
||||
|
||||
|
|
@ -484,79 +554,6 @@ Pour ajouter un nouveau noeud une `zone` master, il suffit de l'installer normal
|
|||
|
||||
## 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 anglais)](http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/object-types).
|
||||
|
||||
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` et de placer la totalité de la configuration dans les zones qui seront déployées.
|
||||
|
||||
#### 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, ils 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, la clé privée de la CA se trouve dans `/var/lib/icinga2/ca/`
|
||||
|
||||
#### scripts/
|
||||
|
||||
Ce dossier regroupe les différents scripts qui sont lancés lors d'événements. 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 de base la configuration standard de l'instance icinga2. Quand on travaille en mode cluster, il est préférable de ne pas prendre appui dessus (en commentant la ligne d'inclusion dans le fichier `icinga2.conf`). A place on va mettre la totalité de la configuration dans les zones à fin qu'elle contrôlable et déployée depuis le master.
|
||||
|
||||
*Note* : On peut néanmoins copier son contenu dans le dossier de la zone du master et s'en servir comme base pour construire sa configuration.
|
||||
|
||||
#### repository.d/
|
||||
|
||||
`repository.d` regroupe les configurations des clients lors d'une synchronisation de type locale.
|
||||
|
||||
#### zones.d/
|
||||
|
||||
Dans une configuration en mode cluster, ce dossier héberge sur le master la totalitée des configurations déployées dans des sous dossier. Chaque sous dossiers contient la configuration de la zone ayant le même nom.
|
||||
|
||||
### Gestion de la PKI - Génération manuelle des certificats
|
||||
|
||||
Dans certains cas, on peut être amené à générer manuellement le certificat TLS pour l'authentification d'un nouveau noeud.
|
||||
|
|
|
|||
Loading…
Reference in a new issue