b53482fc9a7087d8e34acec3c83202d8807f5290
Monitoring/Icinga.md
... | ... | @@ -0,0 +1,122 @@ |
1 | +Icinga2 |
|
2 | +======= |
|
3 | + |
|
4 | +## Généralités |
|
5 | + |
|
6 | +Icinga est un outil permettant de faire remonter les alertes venant des serveurs très facilement. Il est accessible à l'adresse suivante : https://icinga.resel.fr |
|
7 | + |
|
8 | +Le service est monté sur le serveur [Eris](Serveurs/Eris) |
|
9 | + |
|
10 | +La configuration se trouve à l'adresse suivante : https://git.resel.fr/confs/icinga2 |
|
11 | + |
|
12 | +## Ajout rapide d'un serveur |
|
13 | +(aide mémoire) |
|
14 | + |
|
15 | +Voici la procédure pour monitorer rapidement un serveur sur icinga : |
|
16 | + |
|
17 | +Se rendre sur eris puis dans le bon dossier : |
|
18 | +``` |
|
19 | +cd /etc/icinga2/zones.d/<Zone> |
|
20 | +``` |
|
21 | + |
|
22 | +où `<Zone>` est soit Brest soit Rennes soit Nantes. |
|
23 | + |
|
24 | +Trouver n'importe quel simple fichier de conf pour un serveur, et le copier en remplaçant noms et adresses IP : |
|
25 | +``` |
|
26 | +cp serveurs/veronica.conf serveur/<nouveau>.conf |
|
27 | +vim <nouveau>.conf |
|
28 | +``` |
|
29 | + |
|
30 | +Relancer Icinga2 : |
|
31 | +``` |
|
32 | +systemctl restart icinga2 |
|
33 | +``` |
|
34 | + |
|
35 | +## Installation et configuration |
|
36 | + |
|
37 | +### Installation |
|
38 | +Pour avoir une version à jour d'Icinga2 et Icingaweb2, ajouter `/etc/apt/sources.list.d/icinga.list` : |
|
39 | +``` |
|
40 | +deb http://packages.icinga.org/debian icinga-jessie main |
|
41 | +deb-src http://packages.icinga.org/debian icinga-jessie main |
|
42 | +``` |
|
43 | + |
|
44 | +Puis installer les packets requis : |
|
45 | +``` |
|
46 | +apt-get install icinga2 icinga2-ido-mysql |
|
47 | +apt-get install monitoring-plugins |
|
48 | +``` |
|
49 | + |
|
50 | +Une fois icinga2 installé et configuré, terminer en installant l'interface web : |
|
51 | +``` |
|
52 | +apt-get install icingaweb2 |
|
53 | +``` |
|
54 | + |
|
55 | +### Architecture |
|
56 | + |
|
57 | +Icinga2 permet très facilement de profiter de fonctionnalités de Haute Disponibilité, de monitoring distribué et de synchronisation des configurations sur plusieurs serveurs, et c'est ce genre d'architecture qui a été mis en place au ResEl pour : décharger Hera, avoir encore du monitoring en cas de perte du I11, ou du lien Brest-Rennes par exemple. |
|
58 | + |
|
59 | +En prenant cela en compte, deux machines font actuellement tourner Icinga : *Cadillac* à Rennes, et *Eris* à Brest. La configuration est automatiquement synchronisée entre ces deux serveurs. |
|
60 | + |
|
61 | +*Toute la configuration se fait sur *Eris*, dans le répertoire `/etc/icinga2/zones.d/`. Il y a plusieurs répertoires importants dedans : |
|
62 | + |
|
63 | +* global-templates : le contenu de ce dossier sera synchronisé sur tous les membres du cluster. Il contient la définition des commandes et des services propres à toutes les machines (ssh, http, mailq par exemple), les users, les définitions et scripts des notifications. |
|
64 | +* brest : les fichiers de configuration des serveurs, switchs, et bornes de la zone de Brest. |
|
65 | +* rennes : les mêmes éléments, pour la zone de Rennes. |
|
66 | + |
|
67 | +Ici, la *zone* correspond à des éléments définis dans le fichier `zones.conf` (et ici, ça correspond à la répartition géographique des machines). La zone Brest a été définie comme parent de la zone Rennes, ainsi Rennes accepte les fichiers de configuration venant des serveurs de Brest. |
|
68 | + |
|
69 | +### Ajouter un serveur |
|
70 | + |
|
71 | +Selon la zone du serveur, rendez-vous dans le répertoire Brest ou Rennes, et créez le fichier `serveur.conf`, sur le modèle des autres fichiers présents. |
|
72 | + |
|
73 | +Décortiquons le fichier de configuration type. Il se compose de la définition d'un objet, et de plusieurs variables en son sein : |
|
74 | +``` |
|
75 | +object Host "idaho" { |
|
76 | + import "generic-host" |
|
77 | + display_name = "Idaho - Hyperviseur Xen" |
|
78 | + address = "idaho.adm.resel.fr" |
|
79 | + |
|
80 | + groups += ["munin-servers", "ssh-servers"] |
|
81 | + vars.os = "Linux" |
|
82 | +} |
|
83 | +``` |
|
84 | +Ici, on définit un *objet* qui porte le nom du serveur, en l’occurrence Idaho. La 1ère importe un contenu générique (un autre objet Host, avec d'autres variables), et après on définit quelques variables : |
|
85 | + |
|
86 | + |
|
87 | +* `address` : pas besoin d'expliquer je pense :p. On peut préférer l'adresse IP au nom DNS. |
|
88 | +* `display_name_` : Son petit nom et une très courte description qui apparaîtra sur l'interface web, dans les notifications.. |
|
89 | +* `check_command_` : Définit la commande à exécuter pour savoir si la machine est UP ou DOWN. |
|
90 | +* `groups` : on définit les groupes auquel la machine appartient. Cela dépend des services lancés dessus; pour d'autres groupes voir le fichier `global-templates/groups.conf`. En principe, toutes les machines font tourner ssh et munin-node et appartiennent donc au moins à ces deux groupes. |
|
91 | +* `vars.os` : une variables custom (précédée par vars.) qui contient l'OS. Cela permet entre autres de distinguer facilement une machine qui utilise apt, ou pkg par exemple. |
|
92 | + |
|
93 | +**Dans la plupart des cas, la configuration peut s'arrêter ici : le monitoring de base peut commencer. En cas d'installation d'Icinga, si de nouveaux services tournent ou pour mieux comprendre le fonctionnement du logiciel, la suite est là.** |
|
94 | + |
|
95 | +À partir de là, comment monitorer la machine et ses services ? Il faut créer ce qu'on appelle un (attention) service. |
|
96 | + |
|
97 | +### Ajouter un service |
|
98 | + |
|
99 | +Les services sont communs à toutes les zones, avec quelques exceptions, et se trouvent donc dans les fichiers de configuration dans le répertoire global-templates. Là encore, les services de bases sont assez simples : on définit un objet de type Service avec un nom, et on lui ajoute quelques variables. |
|
100 | + |
|
101 | +Spécificité des services, on précise sur quels hôtes ils sont à vérifier, dans une syntaxe proche des langages de programmation classiques. |
|
102 | + |
|
103 | +Exemple du service le plus simple, j'ai nommé le ping : |
|
104 | +``` |
|
105 | +apply Service "ping4" { |
|
106 | + import "generic-service" |
|
107 | + |
|
108 | + check_command = "ping4" |
|
109 | + |
|
110 | + assign where host.address |
|
111 | +} |
|
112 | +``` |
|
113 | + |
|
114 | +On retrouve la même structure que plus haut, et une nouvelle variable, `check_command_`. Dans Icinga et les autres forks de Nagios, la commande représente un objet qui fait directement le lien entre un programme, un plugin, une commande Linux.. à exécuter pour connaître l'état d'un hôte et ses services. |
|
115 | +Ici, la commande utilisée, est le ping (version IPv4). Comment savoir sur quel hôte appliquer ce service ? On pourrait rentrer à la main les noms d'hôte, mais au lieu de cela on peut appliquer le service à des hôtes qui respectent certaines expressions : |
|
116 | +* `assign where host.address` : applique le service à tous les hôtes dont l'adresse est donnée. |
|
117 | + |
|
118 | +## Ressources utiles |
|
119 | + |
|
120 | +## Articles liés |
|
121 | + |
|
122 | +## TODO (pour le rédacteur) |