Ce billet fait suite au précédent, quelque peu similaire puisque je suis en phase d’études pour l’adoption d’un outil de monitoring. Après Cacti, je me suis penché sur l’outil PRTG.
Tout comme Cacti, PRTG utilise SNMP pour récupérer des informations concernant l’état des hôtes qu’il surveille. Cependant, il est également capable d’utiliser par exemple WMI, ce qui est très intéressant dans mon cas puisque je souhaite monitorer uniquement des machines Windows. Par rapport à Cacti, cela m’évite d’avoir à déployer un outil SNMP et à configurer le service. Cet article est donc une introduction à PRTG ; je vais y présenter ma maquette et expliquer les diverses opérations que j’ai réalisé pour surveiller celle-ci.
Sur un serveur Hyper-V 2016, j’ai donc installé les machines suivantes :
- un DC/DNS en 2019
- un Server 2019 avec IIS pour la fonctionnalité FTP
- un Windows 10
- un Server 2019 avec 2 vCPU et 4 Go de RAM pour héberger PRTG
Première note : je ne sais pas si c’est PRTG qui est gourmand ou si ma console Hyper-V était en souffrance mais avec un seul vCPU l’interface web de l’application était très pénible à utiliser. Avec deux vCPU cela fonctionnait un peu mieux mais sans être spécialement fluide. Cela doit mieux fonctionner en utilisant une station de travail et en passant par le web, il est possible que la console Hyper-V ne soit pas le meilleur moyen d’agir sur des interfaces web chargées, le client lourd étant bien plus agréable.
L’éditeur de PRTG met à disposition une version d’essai presque complète (jusqu’à 10000 sensors) pour découvrir leur application. Le setup se télécharge depuis le site directement et pèse environ 180 Mo. Une licence est fournie. Ce setup devra être exécuté sur le serveur PRTG, l’installation se déroulant simplement à base de Next, next, next.
 |
| Il sera nécessaire de copier-coller la clef de licence fournie lors du téléchargement. |
Lorsque l’installation est terminée, le serveur s’exécute et le navigateur web apparaît. Cela peut prendre quelques minutes avec des erreurs répétées de connexion, mais rien d’inquiétant.
 |
| Connexion à l’interface d’administration avec les credentials par défaut |
Le login effectué, il est nécessaire d’activer la licence. Si le serveur n’est pas relié à internet – mon cas pour cette maquette – cela fonctionnera tout de même, il faudra simplement suivre les instructions demandant de se rendre sur le site de l’éditeur pour générer un fichier dont le contenu sera à coller dans le champ correspondant.
 |
L’activation terminée, on arrive sur la page principale.
Quelques sensors sont déjà déployés en fonction de ce que PRTG a trouvé sur le réseau. Ici, on voit qu’il a découvert que la gateway de la carte réseau renvoyait vers un serveur Windows portant les rôles DNS et ADDS. De base, il monitore donc le service DNS et le temps de réponse du serveur. Sur cette capture d’écran, j’ai déjà dégrossi et supprimé pas mal de groupes de base. Comme sur n’importe quel outil de supervision ou de monitoring, les hôtes peuvent bien évidemment être séparés en groupes différents. Je n’ai conservé que ceux qui vont nous intéresser pour la suite.
Afin d’ajouter des hôtes à surveiller, il est nécessaire de valider plusieurs pré-requis : la validité des credentials utilisés par PRTG pour interroger WMI sur les serveurs Windows ainsi que l’activation des règles dans les firewall Windows autorisant l’interrogation de WMI ; les credentials peuvent soit être placés par machine, ou par groupe. Dans cet exemple, j’ai placé ces identifiants à la racine : cela signifie que par défaut, tous les serveurs Windows utiliseront ces derniers pour être interrogés. Bien évidemment, on évitera d’utiliser le compte d’administrateur du domaine pour cette tâche sur un environnement de production 😊
 |
|||
| Ce compte sera celui utilisé pour interroger WMI sur les serveurs placés dans ce groupe, ici Root, donc tous les serveurs Windows (si l’héritage est activé). |
Ensuite, sur les firewall Windows, activer ces règles, sans quoi les sensors ne remonteront aucune information puisque la communication WMI sera bloquée.
Tous les prérequis ayant été validés, je vais donc procéder à l’ajout d’un device dans PRTG et y coupler des sensors. Un device peut être un serveur, mais également un switch ou une imprimante. Un sensor est tout simplement un indicateur. Rien de spécialement sorcier ici.
Différents templates de sensors peuvent être implémentés en même temps que la création du device. Il est possible de procéder à un ajout nu, à une identification automatique (qui semble plutôt bien fonctionner et ajoute une foultitude de capteurs pour un serveur Windows standard : RAM, CPU, disque, I/O réseau, fichier de pagination…) ou à une création sur base d’un template XML reprenant les divers sensors ajoutés dont la création peut se faire une fois qu’un device a été créé. Plusieurs templates sont proposés de base avec l’installation. Par ailleurs, il est possible d’attacher des sensors à des groupes de devices, qui seront automatiquement ajoutés à la création d’un device dans un groupe.
Je suis parti sur un device nu, sans sensor, car je vais les ajouter moi-même pour bien choisir ce qui m’intéresse. Cela se déroule sur la page suivante, où il est possible de rechercher ce que l’on souhaite monitorer ; on dégrossira la recherche avec des critères (dans ce cas : Windows et WMI).
Pour surveiller et obtenir l’état du CPU, il me suffit de choisir Windows CPU Load dans la liste. Je peux ensuite personnaliser ce sensor : nom, rafraîchissement, etc. En répétant cette opération plusieurs fois, j’obtiens un tableau de bord qui commence à ressembler à quelque chose.
Je peux donc désormais consulter l’état global de mon serveur ainsi que du service FTP installé dessus, avec un historique détaillé pour aller jusqu’à un an (les divers historiques disponibles sont paramétrables, le maximum étant de 750 jours). Pour me faciliter la tâche par la suite, je me suis créé un template : un simple clic-droit sur cette machine dans l’interface suivi d’un clic sur Create Template permet sa réalisation. Ensuite, ce template peut être repris pour importer directement les sensors sur d’autres appareils équivalents.
Deuxième note : la gestion des templates pourrait cependant être améliorée ; celle-ci n’apparaît nulle part sur l’interface. Il n’est donc pas possible de modifier facilement un template une fois celui-ci créé. Après avoir recherché dans l’aide de l’application, j’ai appris que les templates sont des fichiers XML au format ODT qui se trouvent dans un sous-répertoire du serveur PRTG et que leur modification ou suppression ne peut se faire que par ce biais… sous-répertoire inaccessible si l’on opte pour la formule SaaS de PRTG ! On peut alors se demander si il n’est pas préférable de procéder à un clonage (grâce la fonction du même nom disponible) du device lorsqu’on souhaite en déployer un nouveau plutôt que de passer par un template ou d’affecter les sondes à un groupe directement.
Si l’interface web fonctionne bien, il existe un client PRTG nommé Enterprise Console qu’il est possible d’installer sur un serveur d’administration par exemple.
PRTG peut fonctionner avec des Remote Probe. Il s’agit d’installations réduites de PRTG déployées qui possèdent leurs propres devices, tout en étant rattachés au serveur PRTG principal. Cela peut permettre de surveiller des sous-réseaux ou des machines isolées. L’installation se fait en quelques minutes, l’unique prérequis étant d’avoir autorisé les connexions en dehors de la boucle local sur l’hôte PRTG principal.
Cette installation de PRTG ne permet pas de réaliser un cluster, elle est toujours dépendante de l’installation principale.
 |
| Les 2 noeuds PRTG sont bien visibles et distincts |
PRTG est un outil très puissant et bien plus accessible que Cacti que j’ai pu manipuler auparavant car tous les modules y sont intégrés et développés par l’éditeur. Sa compatibilité avec WMI est un atout indéniable pour moi. Le coût financier peut porter à réflexion car si PRTG est payant et Cacti gratuit, le temps à consacrer pour développer des templates pour Cacti ainsi que l’obtention d’une couche SNMP décente sur Windows capable de renvoyer les informations désirées ne l’est pas.