Alternatives auto-hébergées à PRTG et SolarWinds pour la supervision d'un réseau Windows

PRTG facture au capteur, c'est-à-dire une métrique surveillée sur un appareil, et non l'appareil lui-même. Les paliers publiés par Paessler fixent le ratio pratique à environ dix pour un : 500 capteurs couvrent à peu près 50 appareils, 10 000 en couvrent environ 1 000. Ajoutez une pile de commutateurs et commencez à surveiller le débit par port, et le compteur grimpe plus vite que le parc. SolarWinds compte autrement et arrive au même endroit.

Pour un réseau majoritairement Windows, je retiendrais deux alternatives auto-hébergées à PRTG et SolarWinds : Zabbix, ou une pile basée sur Prometheus si votre équipe en exploite déjà une. Le choix entre les deux dépend de ce que chacune peut voir sur un hôte Windows, et de ce dont elle a besoin pour le voir.

Une réserve avant tout le reste. Si personne dans l'équipe n'a d'heures disponibles, PRTG et SolarWinds restent la bonne réponse. Leur facilité d'utilisation est un produit que vous achetez délibérément, et il vaut son prix. Le changement décrit ici dépense des heures à la place de licences, et c'est un échange, pas une mise à niveau.

En bref

• Le choix par défaut est Zabbix. Zabbix réunit l'interrogation SNMP, les agents Windows, les modèles et les alertes dans une seule plateforme de supervision. Vous exploitez toujours le serveur Zabbix, la base de données et l'interface web, mais vous n'assemblez pas des composants de supervision séparés juste pour démarrer.
• L'exception est une équipe qui fait déjà tourner Grafana et Prometheus pour les métriques applicatives et hôtes. Étendre ce que vous maintenez déjà coûte moins cher que monter un second système de supervision.
• Prometheus n'interroge pas les équipements réseau par lui-même. snmp_exporter comble ce manque ; sa configuration par défaut couvre de nombreux commutateurs et routeurs courants, tandis que les objets propres à un constructeur ou une interrogation personnalisée peuvent exiger le générateur et du travail supplémentaire sur les MIB.
• La collecte sans agent ne voit que ce qu'un hôte ou un appareil choisit de publier. Dans Zabbix, les journaux d'événements Windows, l'état des services et les compteurs de performance détaillés sont des clés d'élément de l'agent.
• Dimensionnez le serveur selon les métriques, pas selon les appareils. Zabbix compte une métrique comme un élément plus un déclencheur plus un graphique, et place environ 1 000 métriques sur 2 cœurs CPU et 8 Gio de mémoire, environ 10 000 sur 4 cœurs et 16 Gio.

Ce que PRTG et SolarWinds font payer

Paessler publishes its PRTG tiers publicly, priced by sensor count and billed annually, starting from a few hundred dollars a month as of September 2026. Check the current figures yourself before budgeting. There is no perpetual-licence option in the current lineup. The freeware edition stops at 100 sensors, which Paessler describes as roughly 10 devices.

SolarWinds compte une autre unité, et la règle est facile à manquer jusqu'à l'arrivée du devis de renouvellement. Le modèle de licence NPM de SolarWinds indique que NPM « est licencié selon le plus grand nombre parmi les types suivants d'éléments réseau surveillés : nœuds, interfaces, volumes ». Pas la somme. Le plus grand des trois. Un réseau de 80 nœuds et 900 ports de commutateur surveillés est licencié sur les 900, pas sur les 80, et les paliers vont de SL100 à SLX. Un moteur d'interrogation unique plafonne à 12 000 éléments (la somme des nœuds, interfaces et volumes, et non le plus grand d'entre eux) quel que soit le palier, après quoi vous ajoutez un autre moteur d'interrogation sous licence.

L'effet pratique des deux modèles est le même. Le palier de licence décide de ce qui est surveillé. Pas le réseau. Des interfaces que vous aimeriez suivre restent hors surveillance parce que les suivre franchirait un seuil, et ce coût-là n'apparaît jamais sur la facture.

Les deux voies auto-hébergées qui valent la peine

Zabbix est une plateforme de supervision unique construite autour d'un serveur central, d'une base de données et d'une interface web. Le serveur interroge les équipements SNMP, reçoit les données des agents Windows, et applique les modèles, déclencheurs et alertes au sein du même produit. Par rapport à l'assemblage d'une pile de supervision réseau basée sur Prometheus, il y a moins de composants séparés à intégrer vous-même. Vous l'installez, vous le pointez vers les hôtes et vous attachez des modèles, c'est-à-dire des ensembles réutilisables d'éléments, de déclencheurs et de graphiques couvrant une classe d'appareils.

Commencez par la licence. La page de licence de Zabbix indique que chaque version à partir de 7.0 est publiée sous la GNU Affero General Public License version 3, et que tout ce qui précède jusqu'à 6.4 était en GPLv2. Il n'y a aucun frais de licence pour le logiciel, quelle que soit l'échelle. Zabbix vend le support technique sous forme d'abonnement optionnel séparé, et demande aux utilisateurs commerciaux d'en acheter un certain niveau, mais rien dans le produit n'est verrouillé derrière cet achat.

La seconde voie est Grafana, Prometheus et VictoriaMetrics. C'est le bon choix dans exactement une situation : vous faites déjà tourner cette pile pour les métriques applicatives et hôtes, et quelqu'un la maintient déjà. Si c'est votre cas, le montage complet sur un seul VPS est un problème résolu et vous étendez quelque chose de familier. Personne n'a de nouveau modèle de données à apprendre.

LIRE

Installer une stack de monitoring Grafana + Prometheus sur votre VPS (guide Docker Compose)

Le point faible de cette voie, ce sont les équipements réseau. Prometheus collecte des points de terminaison HTTP ; il ne parle pas SNMP directement. Le matériel réseau passe normalement par snmp_exporter, qui interroge l'appareil et expose les résultats pour que Prometheus les collecte. Sa configuration par défaut inclut des modules tels que if_mib, de sorte que la supervision standard des interfaces sur de nombreux commutateurs et routeurs n'exige pas de générer une configuration personnalisée. Le générateur devient du travail supplémentaire quand vous avez besoin d'objets propres à un constructeur, de parcours personnalisés ou de MIB absentes par défaut. La voie Prometheus a donc plus de pièces à maintenir que Zabbix, mais le générateur n'est pas obligatoire pour chaque appareil.

LibreNMS est le troisième nom de ce domaine, construit autour de la découverte automatique : il parcourt un réseau via SNMP, CDP, LLDP, OSPF, BGP et ARP pour trouver ce qui s'y trouve. C'est une option raisonnable quand la découverte est la priorité. Cela ne change rien à la question de la collecte Windows, et c'est là que cette décision se joue.

Comment chaque voie voit un hôte Windows

La supervision Windows peut passer par SNMP, WMI à distance ou un agent installé. La voie applicable dépend du produit de supervision et de la métrique collectée. Dans Zabbix en particulier, les vérifications WMI intégrées passent par l'agent Windows.

SNMP

Une interrogation SNMP demande à un appareil la valeur actuelle d'un objet numéroté, adressé par un OID, c'est-à-dire une position dans la MIB de l'appareil. Ce qui revient est ce que l'appareil publie et rien d'autre. Sur un commutateur administrable, un pare-feu ou un onduleur, c'est généralement suffisant : compteurs d'interface, état des ports, taux d'erreur, température, santé du châssis.

Sous Windows, le tableau est plus mince. La note d'obsolescence de Microsoft pour SNMP et le fournisseur WMI SNMP confirme que les deux fonctionnalités sont obsolètes, donc je traiterais le SNMP Windows comme une voie de compatibilité héritée plutôt que comme le choix par défaut d'un nouveau déploiement. Zabbix fournit toujours un modèle Windows by SNMP, mais l'agent natif vous donne nettement plus de visibilité sur le système d'exploitation.

WMI

WMI peut être interrogé à distance sans installer d'agent de supervision sur la cible, et c'est pour cela que des produits comme PRTG peuvent l'utiliser comme méthode de collecte Windows sans agent. Zabbix fonctionne autrement. Ses vérifications WMI intégrées, wmi.get et wmi.getall, sont des clés d'élément de l'agent Windows, donc c'est l'agent Zabbix ou l'agent 2 qui exécute ces requêtes sur la machine surveillée.

Le WMI à distance apporte aussi ses propres exigences réseau quand un produit de supervision l'utilise directement. Sur les systèmes Windows actuels, RPC démarre sur le port TCP 135 et négocie normalement les connexions via la plage dynamique de ports TCP élevés, généralement de 49152 à 65535. Le pare-feu et les permissions WMI de la cible doivent autoriser la connexion.

Pour cette comparaison, la distinction compte plus que le protocole lui-même : PRTG peut utiliser le WMI à distance sans agent de supervision installé, tandis que Zabbix obtient sa visibilité WMI propre à Windows par son agent.

L'agent natif

L'agent est là où réside la profondeur propre à Windows. La documentation de Zabbix liste les clés propres à Windows: eventlog pour la supervision du journal d'événements Windows, perf_counter pour n'importe quel compteur de performance Windows, service.discovery et service.info pour l'état des services. Toutes sont des clés d'élément de l'agent.

Le coût, c'est le déploiement. Un agent sur chaque Windows Server et chaque poste de travail qui vous importe, c'est un paquet à pousser, une version à maintenir à jour et une règle de pare-feu à entretenir. C'est un engagement opérationnel permanent, et c'est le contrepoids de l'économie de licence.

La collecte sans agent est limitée à ce que l'hôte ou l'appareil choisit de publier, et dans Zabbix les journaux d'événements et les compteurs de performance détaillés se trouvent derrière des clés d'élément de l'agent.

Côte à côte

La comparaison repose sur quatre points : si l'outil interroge les équipements réseau via SNMP, s'il dispose d'un agent Windows, jusqu'où il peut voir dans un hôte Windows, et combien d'assemblage vous sépare d'un système fonctionnel. La licence figure à côté parce que c'est la raison pour laquelle l'évaluation a commencé.

Si le besoin est « me prévenir dans la minute quand un service cesse de répondre », un moniteur de disponibilité est l'outil de la bonne taille et les deux autres sont surdimensionnés pour cela. Ce qu'il ne fera pas, c'est interroger un commutateur pour le débit d'une interface ou lire un compteur de performance Windows, donc ce n'est pas un remplaçant de PRTG ou SolarWinds. C'est un autre travail, parfois confondu avec le même.

LIRE

Comment installer Uptime Kuma sur un VPS

Lequel choisir

Choisissez Zabbix. Pour un réseau majoritairement Windows sans investissement Prometheus existant, c'est de loin la voie la plus courte. Vous avez toujours un serveur, une base de données et une interface web à exploiter, mais le modèle de supervision, les modèles et les alertes vivent dans un seul produit au lieu d'être assemblés à partir de plusieurs composants de supervision.

Pour un déploiement de supervision destiné à durer, utilisez la branche LTS actuelle de Zabbix plutôt qu'une version standard à courte durée de vie. Le cycle de vie LTS de Zabbix donne à chaque version trois ans de support complet suivis de deux ans de support limité, ce qui compte plus ici que de courir après la dernière version fonctionnelle.

L'exception est étroite et précise. Si votre équipe fait déjà tourner Grafana et Prometheus en production pour les métriques applicatives et hôtes, et que quelqu'un possède déjà cette pile, alors snmp_exporter est un ajout à quelque chose de maintenu plutôt qu'un second système à maintenir. Cette condition est cumulative : les deux moitiés doivent être vraies. Une instance Grafana abandonnée, montée par une personne l'an dernier, ne compte pas.

Et si personne n'a les heures, renouvelez. Ce n'est pas une échappatoire. C'est une situation différente avec une réponse correcte différente. Le changement convertit une facture de licence en facture opérationnelle : déploiements d'agents, travail sur les modèles, mises à niveau, et quelqu'un qui comprend assez bien le système pour le réparer à 2 h du matin. Une équipe déjà à pleine capacité fera ce travail mal ou pas du tout, et une supervision non maintenue est pire qu'une supervision coûteuse, parce qu'elle échoue en silence.

L'hybride existe vraiment : gardez l'outil en place sur un noyau décroissant de systèmes critiques, déplacez tout le reste vers Zabbix, et laissez le palier de licence baisser avec le temps. Ça fonctionne. Cela implique aussi de faire tourner deux systèmes de supervision et de réconcilier leurs alertes, donc traitez-le comme un état de transition avec une date de fin.

Ce qui ne survit pas à la migration

Le propre guide de migration de Zabbix comporte une section intitulée « Ce qui n'est PAS migré », et la liste est plus longue que le mot « migration » ne le laisse penser. Les données historiques et les relevés de capteurs ne passent pas. Les notifications et dépendances PRTG personnalisées non plus. Les cartes et tableaux de bord non plus, parce que les deux produits les modélisent assez différemment pour que reconstruire vaille mieux que traduire. Les capteurs eux-mêmes non plus, puisque Zabbix travaille avec un concept entièrement différent.

Les noms d'appareils, les adresses IP et les types d'interface peuvent être repris. Même cela passe par des scripts d'export et d'import personnalisés contre les deux API. Le guide dit clairement qu'il n'existe aucun outil officiel pour migrer directement entre les deux plateformes.

Une équipe a documenté ce que cela coûte en pratique : environ 500 VM et serveurs physiques, environ sept ans sur PRTG, reconstruits de zéro sur six mois de projet à faible priorité. Leurs 2 500 capteurs PRTG sont devenus 43 000 éléments Zabbix, ce qui illustre clairement à quel point les deux systèmes comptent différemment.

« Repartez de zéro. Il n'existe pas de bouton « Appuyez ici pour migrer » de PRTG vers Zabbix, et même s'il existait, une opération de ce genre est une bonne occasion de ne pas répéter les erreurs de conception précédentes. »

Le compte rendu de migration de Digital Dilemma

C'est l'expérience d'une organisation, pas une référence. Un parc plus petit ne produira pas ces chiffres. Ce qui se transfère, c'est l'hypothèse de planification : budgétez du temps de reconstruction, pas du temps de migration.

Séquencez la reconstruction selon ce dont vous ne pouvez pas vous passer. Si votre souci est la continuité des alertes, reconstruisez d'abord les règles de notification et laissez les tableaux de bord attendre. Si c'est l'historique des rapports, exportez ce dont vous avez besoin avant l'expiration de l'ancienne licence. Il ne vous suivra pas.

Dimensionner le serveur

Les prérequis matériels de Zabbix placent une petite installation d'environ 1 000 métriques surveillées sur 2 cœurs CPU et 8 Gio de mémoire, et une installation moyenne d'environ 10 000 métriques sur 4 cœurs et 16 Gio. Ce sont les chiffres sur lesquels baser votre demande.

L'unité est là où le dimensionnement se trompe. Zabbix définit une métrique surveillée comme un élément plus un déclencheur plus un graphique. Une métrique n'est ni un appareil ni un hôte. Un seul Windows Server apporte autant de métriques que vous configurez d'éléments : CPU, mémoire, chaque système de fichiers, chaque service, chaque compteur que vous échantillonnez. Le nombre d'appareils est un mauvais guide pour la machine dont vous avez besoin. Un parc qui semble petit peut atterrir dans la tranche moyenne sans que personne ne fasse rien d'inhabituel.

Deux choses font monter le nombre plus vite que le nombre d'hôtes. La fréquence d'interrogation d'abord : diviser par deux un intervalle de rafraîchissement double le débit d'écriture pour chaque élément sur cet intervalle. La rétention de l'historique ensuite, puisque la base de données grossit avec la durée de conservation des valeurs brutes. Le nombre d'appareils compte surtout par le nombre d'éléments surveillés que chaque appareil apporte.

Si votre parc reste proche de l'exemple des 1 000 métriques avec des intervalles de rafraîchissement ordinaires et une rétention modeste, la petite tranche est un point de départ raisonnable. Si vous échantillonnez des compteurs de performance toutes les trente secondes et conservez un an d'historique brut, ce n'est pas le cas. Zabbix précise explicitement que ses chiffres publiés sont des « exemples de taille et de configuration matérielle pour démarrer », et recommande de mesurer les performances dans un environnement de préproduction avant d'engager du matériel de production. C'est la réserve de l'éditeur lui-même. Prenez-la au pied de la lettre.

Zabbix ne prend en charge son composant serveur que sous Linux et UNIX ; sous Windows, seul l'agent est pris en charge.

Les métriques ne sont pas des appareils, et le multiplicateur entre les deux est ce qui détermine la taille de la machine.

Développez sur un VPS Linux avec accès root, NVMe et la puissance AMD EPYC.

Voir les plans Linux

Où placer le serveur de supervision

Si vous avez besoin que la supervision survive à une panne de tout un site, gardez le serveur Zabbix central hors du domaine de défaillance du site. La perte de la liaison montante du site peut alors mettre le réseau surveillé hors ligne sans emporter le serveur de supervision avec lui.

Pour un réseau privé, un proxy Zabbix peut se placer à l'intérieur du site et collecter depuis les systèmes qui l'entourent. Le proxy peut gérer localement les vérifications SNMP et agent, renvoyer les données collectées au serveur central, et mettre les données de supervision en tampon pendant que la connectivité entre les deux est indisponible. Cela permet au serveur central de rester hors du site sans exiger que chaque commutateur, pare-feu et hôte Windows privé soit directement joignable depuis Internet.

Un VPS est un endroit pratique pour faire tourner ce serveur central. Cloudzy propose Serveur Zabbix en déploiement en un clic sur Ubuntu Server 24.04 LTS si vous voulez sauter l'installation initiale et passer directement à la configuration des hôtes et des modèles.

Foire aux questions