Dans cette partie nous allons passer en revue les principaux vecteurs de notification intégrés à PRTG et qui peuvent interagir avec les acteurs de la supervision. Nous partons du principe ici que PRTG est l'outil qui doit avertir l'acteur de la supervision. En effet, nous mettrons de côté les types de notification qui sont plutôt utilisés pour des remontées d'alarmes vers une autre plate-forme technique. Celle-ci gérant l'interface vers l'utilisateur final. Nous n'aborderons pas par exemple: les traps SNMP, les messages Syslog ou encore l'enregistrement d'évènements dans un eventlog.


Chaque méthode présente des avantages qu'il s'agît d'adapter et d'utiliser au mieux des besoins et des habitudes de travail de chaque population d'utilisateur de la plate-forme.



Utilisation de maps

Adapté à un écran dédié pour ce besoin, il est tout a fait possible d'utiliser des maps et en particulier des représentations sous forme de sunburst pour alerter des opérationnels. Le changement d'état d'un device peut aussi s'accompagner d'un son d'alerte.



Recommandé pour: l'exploitant, l'expert



Utilisation du client Windows GUI

Adapté aux opérationnels, ce client présente l'avantage de pouvoir produire plusieurs type de notification sur le PC de l'utilisateur: du son ainsi qu'une notification visuelle plus ou moins envahissante suivant l'option choisie.



En modifiant les options du client, il est possible d'être averti visuellement et/ou par un son. Cette configuration reste cependant locale.



Recommandé pour: l'exploitant, l'expert



Le web client

Egalement adapté aux opérationnels, ce client a le gros avantage de ne pas nécessiter d'installation sur le poste de travail. L'autre avantage conséquent réside dans la transposition de la configuration quelque soit l'endroit où se connecte l'opérateur (ie. son alerting personnalisé le suit quelque soit le poste sur lequel il travaille).

En revanche, la diversité des notifications du client lourd n'est pas reprise et nous ne pourrons utiliser que les alertes sonores.



Recommandé pour: l'exploitant, l'expert



L'envoi de mail

Notification la plus classique. C'est la première méthode à laquelle on pense lorsque l'on met en place des notifications. On peut vite être inondé de mails dans lesquels il devient difficile de ne pas passer à côté d'informations importantes.


Le contenu du mail est entièrement paramétrable. Son contenu doit être adapté aux besoins des acteurs qui les reçoivent.



En mode html, les mails de PRTG permettent d'initier grâce à une série d'hyperliens des actions sur le traitement de l'alarme elle-même.



Recommandé pour: l'exploitant, l'expert, le développeur, le manager



Les notifications PUSH

Encore en bêta, cette fonctionnalité est la plus adaptée pour les opérationnels qui ont d'autres tâches que le pupîtrage classique à effectuer. Moins envahissant que le mail, l'information nous parvient instantanément à condition bien sûr de disposer d'un smartphone Android ou iOS et l'application PRTG installée.




Recommandé pour: l'expert, le développeur, le manager



Envoi de SMS

Encore largement utilisé, cette fonctionnalité présente l'intérêt d'être compatible avec n'importe quel mobile. Il n'est bien sûr pas possible d'interagir avec l’événement à proprement parler depuis le SMS. Cette solution implique également un surcoût puisqu'il faut s'appuyer sur un broker de SMS pour l'envoi des messages. Elle tend à être remplacée par la solution de PUSH.


Recommandé pour: l'expert, le développeur, le manager



L'exécution de programme

A partir de cette fonctionnalité, tout ou presque est possible. Sensor Factory la recommande pour une solution en particulier: le réveil en astreinte. En effet, toutes les autres méthodes que nous avons vu ensemble ne présentent pas de solution technique satisfaisante pour réveiller un opérateur humain en astreinte. Il est donc indispensable de pouvoir jouer à l'aide d'un SVI sortant une alerte qui appellera sur son mobile la personne d'astreinte. Ce SVI doit prévoir un mécanisme d'acquittement.


Le mécanisme typique est basé sur un SVI scrutant une table SQL dans laquelle PRTG va insérer texte à lire par le robot lorsqu'une alarme se produit. Ce texte peut être enrichi de paramètres contextuels liés à l'alarme elle-même.



Recommandé pour: l'exploitant, l'expert