Une fois PRTG déployé sur l'ensemble de son système d'information, se pose la question suivante: comment s'organiser et traiter les informations remontées ?

Afin de répondre complètement à ces questions, nous allons aborder l'ensemble de ces problématiques non seulement sous l'angle technique mais également sous l'angle opérationnel "humain".


A qui est destinée l'information et a quoi va t'elle servir ?

La plate forme de supervision collecte des métriques, des états, des disponibilités sur chacune des couches techniques: réseau, système, stockage, bases de données, applications...

Cette quantité incroyable d'informations doit être triée, filtrée, hiérarchisée et priorisée afin que ceux qui ont la capacité d'agir sur le système d'information pour le maintenir dans son état nominal soient en mesure de prendre les bonnes décisions en temps et en heure.

PRTG permet tout cela à condition d'être configuré conformément aux attentes de votre organisation.


Évacuons tout de suite le cas particulier du traitement des alertes en astreinte. Tel que nous l'entendons dans la plupart des organisations, l'astreinte informatique a pour vocation d'intervenir techniquement en cas d'incident sur un système dont la disponibilité est attendue également en dehors des heures ouvrées de l'entreprise. Ceci implique que la personne d'astreinte soit en capacité de résoudre l'incident soit parce que l'astreinte ne porte que sur son domaine de compétence soit parce que l'astreinte porte sur des domaines non maîtrisés à priori mais dont les référents ont fournis les procédures de diagnostic et de remédiation des incidents potentiels.

Dans tous les cas, il est souhaitable que l'astreinte ne soit sollicitée que pour des incidents avérés. La saturation d'un espace disque ou une surcharge ponctuelle de CPU ne sont sans doute pas des alertes suffisantes prises individuellement pour réveiller systématiquement la personne d'astreinte. Par contre, corrélées avec l'indisponibilité d'un service ces informations se révéleront précieuses dans l'identification des origines de l'incident et sur les actions a effectuer pour y remédier, surtout par un opérationnel dont ce n'est pas le domaine de compétence.


Qui a besoin des informations collectées par PRTG ? Vos clients externes ou internes: l'information de disponibilités et/ou de performance des services que vous rendez peut leur être présentée directement par PRTG. Vos exploitants bien sûr, la plate-forme de supervision est leur outil de travail au quotidien. Vos développeurs, qui trouveront dans PRTG une solution pour suivre dans le temps le comportement de leurs applications et enfin vos décideurs s'appuieront sur des rapports de tendance afin d'anticiper les évolutions nécessaires de votre système d'information.


Comment alerter pertinemment ?

L'ennemi à combattre est l'inondation de messages et de notifications en tout genre. Noyés sous de nombreux mails d'alerte, la plupart des gens renoncent à les consulter voir finissent par créer une règle de messagerie les mettant directement dans leur corbeille.

Afin de ne pas en arriver là, il est essentiel de ne créer des règles de notifications qu'une fois vos process internes de traitement définis.


Le mail est-il toujours le bon moyen de solliciter une personne ? Pas sûr, surtout si nous reprenons notre exemple de l'astreinte. PRTG offre plusieurs alternatives que nous allons étudier ensemble.


Objectif "green"

Un système d'information en parfaite santé ne devrait remonter que du "vert" sur l'ensemble des capteurs. Or plus le système est vaste plus il est illusoire de vouloir y parvenir à chaque instant. Il est néanmoins important de s'organiser pour que le "rouge" soit pris en compte et traité dans les délais les plus bref (ie sous l'heure). Le "orange" doit, lui, être traité avant de passer au "rouge".


Un repère: Il n'est pas "normal" qu'un capteur remonte une erreur même ponctuellement. Par "normal", nous entendons le fait que si cette remontée est possible sans qu'il n'y ait de procédure de remédiation associée c'est que le seuil d'alerte n'est pas correctement configuré ou bien qu'un filtre de pic doit être positionné pour effacer des franchissements de seuils ponctuels mais non significatifs. En respectant ce principe, on élimine à la source les notifications superflues.


Vous l'aurez compris, plus le travail de définition des seuils aura pu être conduit finement, meilleure sera la pertinence des alertes remontées, moins les acteurs de la supervision seront floodés !