Pas de commentaire

Monitoring de serveurs Windows avec PRTG

  de

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.

Pas de commentaire

Monitoring de serveurs Windows sous Cacti

  de

J’ai eu l’opportunité de me pencher sur l’application de monitoring Cacti afin d’y ajouter des serveurs Windows pour qu’il soit possible de consulter sur des plages de temps définies des informations concernant l’état de santé des serveurs (CPU, RAM, disque…). Je ne vais pas aborder toute la cinématique d’installation de Cacti et de configuration de base, mais tout ce qui est nécessaire pour démarrer à surveiller des serveurs Windows, avec ma vision de néophyte sur Cacti.

Dans l’exemple abordé, j’ai utilisé Cacti 0.8.7, il existe également une branche 1.x avec un template officiel développé par les équipes de Cacti. Ici, je vais utiliser des templates développés par un contributeur, dont le thread sur les forums officiels de Cacti est disponible à ce lien. Le template se base sur les informations renvoyés par l’application SNMP Informant Standard, téléchargeable sur le site de l’éditeur.

Résumé des pré-requis pour cet exemple :

  • Cacti 0.8.7
  • Un serveur Windows, ici il sera en version 2012 R2 Standard.
  • Le logiciel SNMP Informant installé sur le serveur.
  • La fonctionnalité SNMP installée sur le serveur.

Vous pouvez télécharger les templates utilisés dans cet exemple à ce lien. Les autres versions sont disponibles sur le forum. Une erreur à propos du hash XML lors de l’importation signifie que votre version de Cacti est trop ancienne par rapport au template.

Si la fonctionnalité SNMP n’est pas déployée sur le serveur, alors il est nécessaire de se rendre dans le gestionnaire de serveur puis d’ajouter la fonctionnalité ; aucun redémarrage n’est nécessaire et cela prend à peine deux minutes. Une fois cette fonctionnalité déployée, il est nécessaire de la paramétrer dans la console des services :

La communauté doit être renseignée telle que définie pour le serveur Cacti, et il est nécessaire d’ajouter l’adresse IP du serveur Cacti qui va venir poller le serveur Windows. Si jamais ces onglets n’apparaissent pas juste après l’installation de la fonctionnalité SNMP, un arrêt-relance du service devrait les faire apparaître.

Maintenant, il va être question d’importer les templates dans Cacti. Le fichier zip récupéré en début d’article (ou sur le forum) devra être extrait et les fichiers XML commençant par snmp_informant_ devront être transférés sur le serveur, dans le répertoire <cacti>/resource/snmp_queries. Évidemment <cacti> devra être remplacé par le répertoire dans lequel il est installé 😉. Les autres fichiers XML cacti_data_query_snmp sont à importer depuis l’interface web.

Il faut désormais créer un host template, qui va regrouper les serveurs Windows.

Une fois le nom donné, on peut donc y ajouter les templates que nous avons importé juste avant. Ceux-ci portent un nom commençant par W32. Il nous sera donc possible d’ajouter ces graph templates à toutes les machines qui seront basés sur le host template fraîchement créé.

Ceci fait, on peut procéder à la création du device dans Cacti, notre serveur à monitorer.

Une description peut être le nom du serveur, le hostname étant le FQDN. Les autres options ne doivent pas être nécessairement modifiées, sauf pour correspondre à une configuration spécifique éventuelle. On retrouve la communauté SNMP qui doit être renseignée à l’identique sur la machine Windows. Une fois le device créé, on peut bien vérifier que nos graph templates ont été ajoutés.

Pour l’instant, ils sont en Not Being Graphed, puisqu’on a pas encore effectivement défini le graphique, simplement lié les modèles. Les Data Queries doivent toutes être en success, il s’agit des requêtes SNMP à la machine Windows contenant les données qui seront ensuite traitées et affichées dans les graphes.

Il ne reste plus qu’à procéder à la création même des graphes, en cliquant sur Create graphs for this host.

On va cocher donc l’affichage des graphes qui nous intéressent. Ensuite, sélectionner les informations que l’on souhaite afficher par data query. C’est ici que l’on va choisir de ne pas monitorer certains disques, ou encore d’afficher l’état du disque en nombre d’I/O et non en espace disque libre. Par exemple :

Sur la page suivante, simplement valider sans modifier les valeurs :

En cliquant sur Create, on ajoute donc véritablement les graphes alimentés par les data query. Il est possible de rajouter des graphes si il en manque par la suite en répétant la procédure.

Il ne reste donc plus qu’à aller sur l’arborescence de Cacti, trouver le serveur Windows et admirer les graphes !

Un Commentaire

Powershell : copie de fichiers considérés comme anciens

  de

Suite à une demande d’un collègue, j’ai réalisé un script Powershell réalisant une copie récursive de fichiers et dossiers si ceux-ci ont été créés, modifiés ou utilisés (au choix de l’utilisateur) depuis un nombre de jours spécifiés.

En reprenant la logique du script d’archivage automatique de fichiers d’événements Windows, il peut être possible de réaliser une mécanique d’archivage automatique de certains fichiers comme des logs par exemple. Les deux scripts (combinés en un seul) pourraient alors réaliser la copie dans un répertoire temporaire où ils seraient compressés avant d’être acheminés sur un répertoire réseau dédié.

function process{
Write-Host "Folders will be displayed in Cyan." -ForegroundColor "Cyan"
Write-Host "Files will be displayed in Green.`r`n" -ForegroundColor "Green"
foreach($item in $items){
if ($item.Attributes -eq "Directory") { Write-Host $item.FullName -ForegroundColor "Cyan" }
else { Write-Host $item.FullName -ForegroundColor "Green" }
$destination = $item.FullName.Substring($origpath.Length,$item.FullName.Length-$origpath.Length)
Copy-Item $item.FullName -Destination "$destpath\$destination" -Force
}
}
Write-Host "Old files archiving script"
Write-Host "=========================="
$origpath = "C:\source\"
$destpath = "C:\dest\"
$today = Get-Date
if (Test-Path -Path $destpath) { Write-Host "Destination directory already exists. Be careful as the script will overwrite any existing files." -ForegroundColor "Red" } else { New-Item -Path $destpath -ItemType "directory" | out-null }
$olderthan = Read-Host "Archive files older than X days"
Write-Host "1: Creation Date"
Write-Host "2: Modification Date"
Write-Host "3: Last Access Date"
$datetype = Read-Host "Kind of timestamp the script should use ? (1, 2 or 3)"
switch($datetype){
"1" { $items = Get-ChildItem $origpath -Recurse | Where-Object { $_.CreationTime -lt $today.AddDays(-$olderthan) } ; process }
"2" { $items = Get-ChildItem $origpath -Recurse | Where-Object { $_.LastWriteTime -lt $today.AddDays(-$olderthan) } ; process }
"3" { $items = Get-ChildItem $origpath -Recurse | Where-Object { $_.LastAccessTime -lt $today.AddDays(-$olderthan) } ; process }
}
Write-Host "Bye."
Télécharger
Pas de commentaire

J’ai testé l’Intel Compute Stick

  de

Naturellement passionné par les nouvelles technologies en général et curieux de nature, j’ai possédé un Raspberry Pi et un Banana Pi pour divers usages, mais je n’ai jamais vraiment été satisfait de ces appareils. En cause, le processeur non-x86 interdisant l’installation d’un OS Windows et les possibilités limitées des premiers modèles. Bien qu’ils aient beaucoup évolué depuis le temps (plus de 6 ans !), je n’étais pas prêt à en racheter un lorsque je cherchais un petit appareil compact pour me servir de media-center portable et de petite console pour du rétro-gaming. Idéalement, un Raspberry Pi fonctionnant sous recalOS aurait pu faire l’affaire mais j’utilise Plex en media center et je voulais tout de même un peu plus de polyvalence.

Je me souvins alors qu’Intel avait sorti des nano-PC fonctionnant directement sur n’importe quel téléviseur ou écran grâce à l’interface HDMI (et évidemment, une alimentation USB). Après un petit temps d’hésitation, je décide donc d’acquérir un Intel Compute Stick de deuxième génération.

Image Wikimedia Commons

Il s’agit donc d’une grosse clef HDMI, un peu plus imposante que la première Chromecast avant qu’elle ne devienne un galet. Elle se branche tout simplement sur le port HDMI d’un téléviseur ou d’un moniteur et est alimentée par un chargeur USB fourni (avec de multiples prises internationales). Une rallonge est fournie avec le stick et elle est bienvenue, offrant
plus de latitude quant au branchement, surtout derrière une TV. Bien que le form factor soit compact et simple, la plupart des composants d’un laptop moderne sont présents : double port USB (2.0 et 3.0), Bluetooth, WiFi, lecteur de carte microSD. Le processeur est un petit Atom à 4 cores et 4 threads, suffisamment performant pour réaliser des tâches simples (j’y reviendrai plus tard), il est épaulé par 2 Go de mémoire vive DDR3 et 32 Go de stockage flash interne. Le tout est refroidi par un tout petit ventilateur audible de près mais relativement silencieux.

Le produit se veut utilisable out of the box, mais ne l’est pas vraiment. Comme tout PC Windows 10 (ici installé en 32 bits !), la phase de configuration finale est à la charge de l’utilisateur. Il faut donc s’armer de clavier et souris Bluetooth, ou bien de brancher un hub USB et de passer par du filaire (ce qui n’est pas vraiment idéal). Une fois cette étape terminée, Windows finit sa configuration et affiche le bureau. Il reste alors environ 17 Go d’espace libre sur la mémoire interne, l’extension par microSD étant alors nécessaire pour être un peu plus serein.

Windows (livré en Home, quel dommage !) fonctionne plutôt bien avec cette configuration légère. Pas de ralentissements dans les applications ni en surf internet ou en usage multimédia. Les applications semblent plus performantes dans leurs versions « Store », peut-être à cause de librairies plus optimisées. Le système démarre en une vingtaine de secondes à peu près ; à noter que le BIOS est facilement accessible pour protéger l’appareil, désactiver des ports ou la communication Bluetooth par exemple… ou encore démarrer sur un périphérique USB et installer un autre OS par exemple.

J’ai procédé à la mise à niveau vers une version Pro de Windows, afin de bénéficier principalement de la prise en main à distance. J’ai également mis à jour Windows vers la version la plus récente proposée pour l’appareil, sans dysfonctionnement majeur, même si cela a pris son temps. Le Bluetooth est devenu quelque peu capricieux cependant depuis la mise à jour, et la mise à jour du driver sur le site d’Intel n’a pas résolu le problème ; j’ai donc installé le driver Realtek correspondant, ce qui a résolu le problème. Il est important de noter que c’est la même puce qui gère le Bluetooth et le Wi-Fi, et que donc en fonction du nombre d’appareils appairés avec la machine, il peut y avoir un débit Wi-Fi plus faible. Je n’ai rien constaté de dramatique ou d’handicapant cependant avec un clavier et une souris sans-fil, un test de synchronisation OneDrive téléchargeant les données à plus de 2 Mo/s.

L’Intel Compute Stick dans cette version de base trouvable à environ 150 euros sur Amazon est un parfait appareil pouvant donner une seconde jeunesse à une TV ou comme petit PC d’appoint. Un usage media center est tout désigné car l’OS Windows permet l’installation de nombreuses applications en rapport, et la puce graphique capable de décoder du 1080p. Pour mon usage, le Stick peut remplacer une Chromecast (moins polyvalente) et un Raspberry Pi (contraignant avec son architecture ARM) ; suffisant pour de la prise en main à distance, de la bureautique légère ou des présentations, ce nano-PC a beaux arguments à faire valoir, pour un prix malheureusement élevé par rapport aux appareils qu’il peut remplacer, mais pas tout à fait dans les clous si on le considère comme un véritable PC… ce qu’il n’est pas non plus à cause de son format et de ses composants.