Ce billet n'a pas la prétention de passer en revue de manière exhaustive tous les cas possibles d'organisation autour du traitement des alertes de votre système d'information. Il doit cependant aider à se poser toutes les questions afin de porter simplement la définition de vos process dans la configuration de PRTG.



Quels acteurs autour de la plate-forme ?

Nous proposons communément plusieurs catégories d'acteurs autour de la plate-forme de supervision et qui peuvent se décliner naturellement en groupe de traitement dans PRTG:


L'exploitant: technicien en première ligne sur le front du traitement des incidents, cet acteur a besoin d'être alerté rapidement. La plate-forme de supervision doit lui fournir en première lecture la nature et l'importance des impacts afin qu'il adapte la communication auprès des utilisateurs et puissent dérouler les procédures prédéfinies de remédiation sans avoir à analyser finement les causes des dysfonctionnements.


L'expert: lorsque les procédures standard de remédiation prédéfinies ne sont pas efficaces, c'est à l'expert de prendre le relais. Par définition, l'origine de l'incident qui lui est escaladé n'est à priori pas complètement identifiée. Il est donc important que la plate-forme de supervision lui fournisse les métriques nécessaires au diagnostic.


Le développeur/architecte: bien qu'il puisse être associé à la résolution d'incident, les seules données issues de la plate-forme de supervision ne sont que rarement suffisantes pour lui permettre de résoudre un incident. Cet acteur peut par contre trouver dans la plate-forme de supervision les données qui vont lui permettre de suivre la vie de l'architecture et ou de l'application dont il a la charge et d'améliorer ainsi les performances de son code.


Le manager: responsable en charge du capacity planning de la production, la plate-forme de supervision lui permet de compiler dans le temps les données nécessaires à la perception de l'évolution de la charge sur la production. Elle lui permet également, à partir de l'historique des incidents, de dégager les axes d'évolutions nécessaires à l'amélioration de la stabilité de la production.


Il est bien sûr possible de combiner ces fonctions-type et de les adapter à votre propre organisation. Suivant sa taille, les rôles d'exploitant et d'expert peuvent être confondus par exemple. Il reste cependant essentiel que la plate-forme de supervision réponde techniquement à tous les besoins liés aux fonctions définies ci-dessus. Elle doit donc monitorer de manière exhaustive tous les équipements de la production mais également fournir les tableaux de bord incluant les points de contrôle combinant l'état des capteurs clés facilitant la lecture de l'état de chacune de vos applications.


Chaque fonction-type peut se décliner par domaine de compétence (réseau, système, stockage, DBA,..)



Quand notifier ?

Est-ce que tous les groupes de traitement doivent être notifiés tout le temps ? A priori, il n'est pas utile d'inonder les messageries de vos collaborateurs en dehors de leurs heures ouvrées. De retour au bureau, un rapport généré automatiquement sur les incidents survenus en leur absence et sur le périmètre les concernant leur fera gagner beaucoup de temps. Malheureusement PRTG n'offre pas pour le moment une grande souplesse dans la création de rapport. Les données d'historique ne sont, par exemple, pas intégrable dans un template. Paessler, conscient des lacunes de PRTG en la matière a donc ouvert une autre voie. La société fournit un utilitaire, encore en beta, permettant d'extraire les données de PRTG, de les intégrer dans des bases de données relationnelles et ainsi les rendre accessibles à des outils spécialisés dans la génération de rapport. (http://www.paessler.com/tools/dataextractor)


Inutile non plus de leur envoyer des SMS si vos collaborateurs ne sont pas en astreinte. On voit donc qu'il est essentiel de maîtriser les plages horaires d'envoi des notifications afin de ne pas surcharger les acteurs d'informations dont ils n'auront que faire après coup.



Que faire des alertes ?

Si une alerte remonte et "qu'il n'y a rien à faire", elle ne doit logiquement pas donner lieu à une notification. Inutile de prévenir qui que ce soit dans ce cas. L'alerte en tant que tel apparaîtra dans les rapports de trend et pourra être prise en compte dans le cadre de l'amélioration de la stabilité du système d'information.

Mais ce cas devrait être finalement plutôt rare. En effet, même un franchissement de seuil provoquant un warning doit à minima déclencher une procédure de surveillance de l'évolution de la situation dans le cadre d'une exploitation proactive. Autre exemple, une erreur non traitée dans le délai imparti par l'exploitation doit donner lieu à une escalade vers les managers afin que ceux-ci puissent organiser la réponse de leurs collaborateurs.



En résumé

Pour configurer correctement les notifications, on doit donc:


  1. identifier les groupes de traitement (fonction et domaine)
  2. leur appliquer les périodes de notification adaptées
  3. identifier les SLAs de prise en charge d'incident et d'escalade
  4. définir les procédures de remédiation pour incident faisant l'objet d'une notification