PROJET AUTOBLOG


IT-Connect

Site original : IT-Connect

⇐ retour index

Bien appréhender la Supervision… Partie 2

mardi 17 février 2015 à 14:30

Cet article fait suite à :  Bien appréhender la Supervision… Partie 1

5. La gestion des actions

Une action, c’est quoi ? Et bien c’est tout simplement ce qui va se passer (les actions que vous voulez entreprendre – ben oui, c’est vous qui décidez non?) après une « alarme », c’est-à-dire quand un test échoue et qu’un voyant rouge apparaît, mais pas que… Il faut aussi que l’on puisse faire quelque chose quand le voyant passe du rouge au vert, ne serait-ce que pour prévenir certaines personnes que tout est à nouveau dans un état normal…

Il arrive souvent qu’une seule action ne suffise pas et on doit alors pouvoir grouper les actions dans un groupe d’actions, permettant par exemple d’envoyer un SMS et de redémarrer un service ou un process par exemple…

Les actions nécessaires de base :

Petit truc auquel il faut penser : Une fois l’action (ou les) effectuée, l’outil de supervision a fait son job au regard de cette alarme, si cela repasse au vert, tant mieux, à l’inverse il est peut être intéressant de vouloir rejouer cette action (ou cette liste d’action) jusqu’à temps que le voyant passe au vert ou que quelqu’un désactive (ou acquitte – quoiqu’on en reparlera ensuite des « acquittements »…) cette alarme. Ce peut-être utile pour « réveiller une astreinte » !

Les actions (ou liste d’actions) peuvent être également rattachées à un groupe d’opérateurs (d’utilisateurs) de la solution de supervision afin qu’un utilisateur « standard » ne puisse pas affecter des actions qui ne seraient pas de son ressort (dans le sens « compétences ») sur un moniteur donné.

Enfin, ce ne serait pas plus mal que l’on puisse déclencher une action ou une liste d’action, selon un calendrier (voir paragraphe suivant) et pas seulement suite à une alarme, cela pourrait rendre de grands services quant à la gérance d’un système d’informations…

Bon, avec tout cela, on a déjà de quoi faire non ?

6. Un calendrier…

Un calendrier, associé à la solution de supervision est indispensable ne serait-ce que pour suspendre la supervision d’un « système » pendant une période donnée. Cette période peut être liée à une plage de maintenance programmée d’un système ou tout simplement parce que le système à superviser ne fonctionne pas H24 et 7 jours sur 7 et que par conséquent il ne peut pas être supervisé à des horaires définis. On retiendra alors la possibilité de suspendre un moniteur tous les dimanches par exemple, ou tous les 1ers de chaque mois voire de ne l’activer qu’un seul jour par mois ou que tous les lundis… Lors d’une maintenance programmée, on devra alors pouvoir paramétrer une période comme du 01/01/2015 de 01h00 à 03h15.

Mais le calendrier a une deuxième raison d’être et pas des moindres… A quoi servirait de prévenir un opérateur de supervision (un technicien du support) s’il est en congé ? Vous avez compris, le calendrier doit comporter les périodes de présence de vos techniciens, permettant ainsi à la solution de supervision de ne prévenir que les gens qui sont là et d’éviter à vos techniciens, un torrent de mails ou de SMS pour rien, ce qui est l’ennemi public n° 1 lorsque l’on met en place un tel outil… Trop d’alarmes tuent l’alarme… !

Enfin, on pourra utiliser le calendrier comme un ordonnanceur, afin de lancer une action ou une liste d’actions (voir paragraphe précédent) à un horaire bien défini et indépendamment du système de gestion des alarmes, ce qui pourrait rendre de grands services !

7. Les objets à superviser…

Alors là, tout est permis dans le sens où l’on peut (on doit ?) superviser tout « système » connecté au réseau informatique de l’entreprise ou tout système externe que l’on peut atteindre à partir du réseau local (exemple : un site internet hébergé chez un prestataire). Quelques exemples :

Tout l’art réside dans le fait de bien « organiser » tous ces objets, car on a peut-être envie de grouper ces objets selon différentes catégories, ce qui permet par exemple de rattacher des opérateurs à un groupe donné exemples : seuls les opérateurs du groupe 1 peuvent faire « joujou » avec les objets du groupe A, ou bien encore seuls les opérateurs du groupe 1 « reçoivent » les alarmes concernant les objets du groupe A… C’est un peu prise de tête au début, mais c’est un passage obligé…

De même, on peut très bien créer deux « objets » (ou plus) à partir d’un même système, exemple : vous disposez d’un serveur hébergeant une base de données, alors vous créez un objet, appelé « Serveur X » qui contiendra uniquement les sondes « techniques » (tests CPU, RAM, Disques, IO…etc.) et un deuxième objet qui s’appellera « Base de données Y » et qui contiendra uniquement des sondes permettant de superviser les métriques de cette base de données. Ce peut être une des manières de s’organiser…

A suivre…