Page History

L’intérêt d'une supervision secondaire

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: Sup de Sup ( Superviser sa plateforme de supervision )

Mise en place automatisée d'une plateforme de supervision secondaire

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.

Prérequis

Pour mettre en place la plateforme de supervision secondaire, l'inventaire des machines nécessaires est le suivant:

• La plateforme de supervision principale: constituée de potentiellement plusieurs machines
• Une machine supplémentaire pour la supervision secondaire

Dans les sections suivantes, on se réfère à ces machines avec les caracteristiques suivantes:

• Supervision principale: On prend comme référence la machine qui héberge l'Arbiter, puisque c'est celle ci qui va nous intéresser
  • Nom de la machine: Monitoring PROD
  • Adresse: ip_monitoring_prod
• Supervision secondaire
  • Nom de la machine: Sup de Sup (pour supervision de la supervision)
  • Adresse: ip_sup_de_sup

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.

Activation de l'addon "nagvis-shinken-architecture"

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:

• Code Block
  language text theme Emacs title Machine: Monitoring PROD
  $ shinken-addons-enable nagvis-shinken-architecture

• Code Block
  language text theme Emacs title Machine: Sup de Sup
  $ 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

Configuration des modules d'export d'architecture

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

  Code Block
  language js theme Confluence title Machine: Monitoring PROD, Fichier: /etc/shinken/modules/architecture-export.cfg
  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:

  Code Block
  language js theme Confluence title Machine: Sup de Sup, Fichier: /etc/shinken/modules/architecture-export.cfg
  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

Import des hôtes dans les différentes interfaces de Configuration

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 éléments sont en erreur:

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.

Résultat final

La mise en place de la supervision secondaire a été effectuée en 3 étapes:

• Activation de l'addon "nagvis-shinken-architecture" sur les machines concernées
• Modification du nom de l'architecture et de la liste des modules à contacter dans la configuration du module d'export de l'architecture.
• Import des hôtes dans l'interface de Configuration.

Le résultat des ces opérations est la présence de cartes et d'hôtes permettant de visualiser l'architecture de la plateforme secondaire (Sup de Sup) et de la plateforme principale (Monitoring PROD):

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.