Une plateforme de supervision permet de remonter l'état d'éléments supervisés et de remonter des alertes lorsque certains d'entre eux sont dans un état critique.
Il faut donc que cette plateforme de supervision soit fiable. Lorsqu'elle tombe en panne, il faut pouvoir en être alerté, afin de pouvoir réagir rapidement. C'est le rôle de la plateforme de supervision secondaire.
L'objectif de cette page étant d'abord de se focaliser sur la mise en place de cette plateforme de manière automatisée, les explications plus détaillées sur ce concept sont abordées dans une page dédiée: Superviser sa plateforme de supervision
Depuis la Shinken Entreprise V02.05.00, l'addon "nagvis-shinken-architecture" est présent dans toutes les installations. Les sections suivantes expliquent comment l'utiliser pour mettre en place une plateforme de supervision secondaire en 3 étapes.
Pour mettre en place la plateforme de supervision secondaire, l'inventaire des machines nécessaires est le suivant:
Dans les sections suivantes, on se réfère à ces machines avec les caracteristiques suivantes:
Dans la suite de la procédure, il faut aussi que les machines possèdent la même version de Shinken, pour éviter tout problème d'incompatibilité. Il faut aussi que ces machines possèdent au minimum la version V02.05.00 de Shinken.
Puisque l'addon "nagvis-shinken-architecture" est responsable de l'export de l'architecture, il faut avant tout chose s'assurer qu'il est activé sur nos 2 machines:
$ shinken-addons-enable nagvis-shinken-architecture |
$ shinken-addons-enable nagvis-shinken-architecture |
Si la commande d'activation nous indique que l'Arbiter doit être redémarré, il faudra aussi le redémarrer comme suggéré sur chaque machine:
$ /etc/init.d/shinken-arbiter restart |
Sur la supervision principale, on configure le module d'export de l'architecture pour qu'il envoie son architecture a la supervision secondaire. On profite de l'occasion pour donner un nom plus représentatif à notre architecture.
define module {
...
architecture_name Monitoring PROD
send_my_architecture_to_recipients http://127.0.0.1:7780,http://ip_sup_de_sup:7780
} |
Sur la supervision secondaire, on effectue la même opération: on configure le module d'export de l'architecture pour qu'il envoie son architecture à la supervision principale:
define module {
...
architecture_name Sup de Sup
send_my_architecture_to_recipients http://127.0.0.1:7780,http://ip_monitoring_prod:7780
} |
Pour que les modifications soient prises en compte, on redémarre l'Arbiter sur chaque machine à tour de rôle:
$ /etc/init.d/shinken-arbiter restart |
$ /etc/init.d/shinken-arbiter restart |
La modification de la configuration des modules d'export de l'architecture et le redémarrage de l'Arbiter a généré les différentes visualisations de l'architecture sur les 2 machines. Si on se rend, par exemple, sur l'interface de Visualisation de la Sup de Sup, on verra des nouvelles entrées dans le menu "Architectures":
Lorsqu'on visite ces liens, on se rend compte que tous les élements sont en erreur:
SCREEN NAGVIS ELTS N/A
Dans les interfaces de Configuration de "Monitoring PROD" et de "Sup de Sup", un certain nombre d'hôtes ont été générés par l'addon, mais sont encore en attente d'import. L'import de ces hôtes et la validation de la configuration en Production permettra de voir l'architecture avec les statuts associés:
SCREEN FINAL
A ce stade, la mise en place de la supervision secondaire est terminée.
Il est par la suite possible de configurer davantage les hôtes générés, comme par exemple régler les paramètres de notification.