Dans cette partie nous allons aborder la stratégie de positionnement et de déclenchement des notifications.


Les organisations compactes, centrées autour d'une ou deux équipes peuvent définir les notifications directement sur la vue hiérarchique des devices. Pour des raisons de maintenabilité, il faut être en mesure de positionner suffisamment haut dans la hiérarchie des devices les notifications de façon à ne pas avoir à passer sur chaque device pour les configurer. Ceci implique que la hiérarchie des objets tiennent compte un minimum de cette dimension "groupe de traitement". Si le choix a été fait, notamment pour des problématiques de répartition de charge de dispatcher les devices d'un même groupe de traitement dans plusieurs endroits de la hiérarchie, mieux vaut s'appuyer sur des libraries.


Les notifications sont déclenchées sur la base de triggers que l'on définit à n'importe quel niveau de la hiérarchie des objets, sauf au niveau des channels. Cette fonction fait bien sûr partie des propriétés bénéficiant des mécanismes d'héritage dans PRTG quand elle est utilisée dans la vue hiérarchique. Utilisée dans une librairie, elle ne peut être définie que globalement pour tous les objets de la librairie.


Dans une organisation dont les domaines de compétences sont silotés, notre recommandation est de s'appuyer entièrement sur une gestion des notifications basées sur des libraries. D'autant plus que depuis la version 15.1.15 de PRTG, les notifications des libraries sont devenues complètement indépendantes de celle configurées et héritées de la vue hiérarchique des devices.

Il est donc désormais possible, en reprenant l'exemple développé en Part 2 et qui consiste à vouloir rendre autonome une catégorie de vos utilisateurs dans la gestion de leur notification de s'appuyer sur cette capacité de PRTG.




Il est possible de définir plusieurs triggers pour une même librairie. On peut imaginer un scénario du type: le groupe des exploitants est alerté une première fois quand un capteur passe à l'état down. Si aucun changement n'intervient sur l'état du capteur sous un délai donné, le groupe des experts est alors notifié à son tour...


Il est intéressant de noter que Paessler recommande de croiser les vecteurs de notifications afin de ne pas manquer d'alerte en cas d'incident technique sur un des vecteurs par exemple.


Afin de ne pas être redondant avec la documentation PRTG, vous retrouvez ci-dessous le lien vers la section concernant spécifiquement les notifications:


http://www.paessler.com/manuals/prtg/notifications.htm


Nous identifions au moins une contrainte spécifique liée à la mise en place de notification sur les libraries: celle de déclencher un capteur de seuil uniquement sur le channel primaire ou total d'un capteur. En effet, il est impossible à priori pour PRTG de savoir quel capteur vous allez ajouter à votre library et si ceux-ci ont un ou N channels. La fonctionnalité est donc restreinte à ces deux seuls channels.


Nous conseillons d'une manière globale de réserver les triggers de type "Change" à des besoins très spécifiques. En effet, positionner sans qualification préalable, ce trigger risque de vous submerger de notifications.