Surveillance serveur : contrôles CPU, RAM et charge disque
La surveillance de serveur de HostTracker suit la charge CPU, la RAM et le disque dur en temps réel. Elle contrôle la charge CPU, l’utilisation de la mémoire et la charge du disque dur, pour optimiser les performances du serveur et l’expérience utilisateur.
Détectez les problèmes de ressources avant qu’ils ne causent une panne
Suivi de la charge CPU
HostTracker surveille l’utilisation du CPU pour garder vos serveurs efficaces et stables. Il suit l’utilisation du CPU de votre serveur, identifie les problèmes et vous alerte en cas de pics inhabituels. La surveillance de la charge CPU aide les administrateurs à faire fonctionner leurs serveurs sans accroc et à éviter les pannes.
Tendances d’utilisation de la mémoire
HostTracker surveille l’utilisation de la mémoire pour préserver les performances du serveur. Cette fonctionnalité suit l’utilisation de la mémoire et identifie les tendances susceptibles de provoquer des ralentissements ou des plantages. Les rapports et les alertes aident les administrateurs à optimiser l’utilisation de la mémoire. Une bonne surveillance de la RAM garantit que les applications fonctionnent bien et qu’aucune surprise ne survient à cause de problèmes de mémoire.
Alertes d’espace disque
La surveillance du disque dur par HostTracker évite que les problèmes de stockage n’affectent les performances du serveur. Ce service suit l’utilisation de l’espace disque et alerte les administrateurs pour prévenir les problèmes tels qu’un stockage insuffisant ou des pannes de disque. La surveillance et les rapports vous aident à garder le contrôle des problèmes d’espace disque, afin que votre serveur dispose toujours de suffisamment d’espace pour fonctionner sans accroc. Cela contribue à la fiabilité des serveurs et évite les pertes de données dues à des problèmes de stockage.
Comment les chiffres arrivent chez HostTracker - sans aucun agent sur votre serveur
La plupart des produits de surveillance serveur vous demandent d’installer un agent : un processus en arrière-plan disposant d’un accès de niveau système, qui tourne en permanence sur votre machine et envoie des données en continu. HostTracker, délibérément, ne fait pas ça. C’est un service de surveillance externe, et une vérification de charge serveur fonctionne à l’inverse - votre serveur expose un petit point de terminaison en lecture seule qui rapporte un seul nombre, et HostTracker l’interroge selon le calendrier que vous définissez.
Cette inversion est toute la conception. Il n’y a pas de démon à maintenir en vie, pas de logiciel privilégié que vous n’avez pas écrit tournant en production, pas d’identifiants confiés à un tiers, et pas de port d’administration entrant. Ce que vous exposez est une URL qui n’accepte aucune commande, ne change rien et renvoie une seule valeur.
Le collecteur PHP
Un script prêt à l’emploi pour un hôte Linux ou Unix qui exécute déjà PHP. Déposez-le dans un répertoire servi par le web et pointez le moniteur vers cette URL de base. Il lit localement les chiffres de CPU, mémoire et disque de la machine et répond avec le nombre.
Le collecteur ASP.NET
L’équivalent Windows, pour un hôte qui exécute IIS. Même principe, avec en plus l’accès à n’importe quel compteur de performance Windows par catégorie, nom et instance - tout ce que l’Analyseur de performances peut vous montrer localement peut donc être surveillé à distance.
Votre propre point de terminaison
Pointez le moniteur vers l’URL de votre choix et répondez avec un minuscule objet JSON. Dix lignes dans n’importe quel langage, rien sur votre serveur que vous n’ayez écrit vous-même, et vous décidez exactement quels nombres sont exposés. C’est l’option que la plupart des équipes d’ingénierie finissent par préférer.
Rien n’est jamais poussé vers votre machine. Le collecteur est déployé par vous, quand vous le décidez, et HostTracker se contente toujours de lui adresser une requête. Si vous le supprimez, la surveillance s’arrête - il n’a aucun autre moyen d’entrer.
Ce qu’un moniteur serveur peut mesurer
Chaque moniteur surveille une seule valeur, si bien qu’un serveur typique en compte trois ou quatre - chacun avec son propre seuil, son propre historique et sa propre alerte. Les types de valeurs sont :
| Métrique | Rapportée sous forme de | À quoi ça sert |
|---|---|---|
| CPU | Pourcentage d’utilisation | Saturation soutenue, processus emballés, instances sous-dimensionnées, la charge ajoutée par un déploiement |
| RAM | Pourcentage d’utilisation | Fuites mémoire, consommation qui grimpe insidieusement entre deux redémarrages, la pression qui précède un arrêt pour manque de mémoire |
| Disque | Pourcentage d’utilisation pour un chemin ou un lecteur que vous nommez | Journaux, fichiers envoyés et sauvegardes qui remplissent un volume - la panne la plus lente et la plus prévisible qui soit |
| Port TCP | Temps de connexion en millisecondes | Si un service de la machine accepte toujours les connexions, et à quelle vitesse |
| SQL Server | Temps de connexion en millisecondes | Joignabilité et authentification de la base de données du point de vue du serveur lui-même |
| MySQL | Temps de connexion en millisecondes | La même chose, pour MySQL |
| Compteur de performance Windows | Ce que rapporte le compteur | Tout ce qu’expose l’Analyseur de performances, par catégorie, nom de compteur et instance - longueurs de file d’attente, handles, chiffres par processus |
Si ce dont vous avez besoin est la base de données derrière le serveur plutôt que son temps de connexion, il s’agit d’une vérification différente et plus poussée : un moniteur de requêtes de base de données se connecte, s’authentifie, exécute une requête que vous écrivez et compare la valeur renvoyée à un seuil.
Écrire son propre collecteur
Le contrat est volontairement trivial, car l’objectif est que vous puissiez le lire d’une traite et l’implémenter dans n’importe quel langage déjà utilisé par votre équipe. HostTracker interroge votre URL ; votre point de terminaison répond avec un objet JSON contenant la valeur :
{ "v": 42.7 }C’est là toute la surface requise. Deux membres facultatifs rendent le résultat plus utile :
e transporte une chaîne d’erreur lorsque la valeur n’a pas pu être lue cette fois-ci - un
résultat bien meilleur que de rapporter un zéro trompeur - et vs transporte une chaîne de
version de votre choix, qui apparaît dans le résultat afin que vous sachiez quelle version du
collecteur a répondu.
{ "v": 91.4, "e": "", "vs": "collector-2.1" }Comme c’est vous qui écrivez le lecteur, vous n’êtes pas limité à ce qu’un agent générique sait collecter. Profondeur de file d’attente, taux de succès de cache, nombre de tâches en attente, âge du plus ancien enregistrement non traité, inodes libres, taille d’un répertoire qui ne doit jamais grossir - tout ce que vous pouvez exprimer sous forme de nombre devient une valeur surveillée, avec des seuils, un historique et des alertes qui lui sont attachés.
Protégez le point de terminaison. Il doit être joignable par les vérificateurs qui l’appellent, traitez-le donc comme n’importe quelle autre URL publique : placez-le sur un chemin impossible à deviner, gardez-le en lecture seule, et n’exposez que les nombres que vous êtes à l’aise de voir lus. Il n’accepte aucun paramètre qui change quoi que ce soit, ce qui limite l’exposition à exactement une valeur.
Définir un seuil qui a du sens
Un nombre brut, c’est de la donnée ; un seuil, c’est ce qui la transforme en surveillance. Chaque moniteur porte une condition et une ou deux limites, ce qui vous permet d’exprimer la forme de « ce qui ne va pas » plutôt qu’un simple plafond :
- supérieur à ou inférieur à une limite - la forme la plus courante. CPU au-dessus de 90. Disque libre en dessous de 10.
- égal à ou différent de une limite - pour une valeur qui est en réalité un état : un nombre de workers qui doit rester à 4, un indicateur qui doit rester à 0.
- à l’intérieur d’une plage ou à l’extérieur d’une plage, avec deux limites - la forme adaptée à tout ce qui a une bande saine plutôt qu’un maximum sain. Une file d’attente normalement comprise entre 10 et 500 vous dit quelque chose quand elle affiche 0, et autre chose quand elle affiche 5 000.
- aucune condition du tout - collectez et représentez la valeur sans jamais faire échouer la vérification. Utile pour une métrique dont vous voulez l’historique avant de savoir à quoi ressemble « le mauvais ».
L’anti-rebond est le réglage qui coupe le bruit
À côté du seuil se trouve un nombre de vérifications consécutives en surcharge avant que le moniteur ne passe en panne, réglable de zéro à vingt. C’est le réglage le plus précieux de la page, et celui qu’on laisse le plus souvent inchangé. Un serveur à 95 % de CPU pendant un seul relevé lors d’une sauvegarde nocturne n’est pas un incident. Un serveur à 95 % pendant cinq vérifications d’affilée en est un. Ajustez ce nombre à la durée pendant laquelle votre charge de travail a légitimement le droit d’être occupée, et toute une catégorie de fausses alertes à 3 heures du matin disparaît sans que votre seuil ne devienne le moins du monde moins strict.
Cela compte davantage ici que sur une vérification web, parce qu’une métrique serveur est lue depuis une source unique et faisant autorité - votre propre collecteur - plutôt que confirmée par plusieurs points de contrôle indépendants comme le fait une vérification de disponibilité. Il n’y a pas de second avis pour lisser un pic momentané, c’est donc le nombre de vérifications consécutives qui joue ce rôle.
Ce que chaque métrique vous annonce
Les trois métriques principales échouent de façons vraiment différentes, et savoir laquelle vous regardez vous indique de combien de temps vous disposez.
| Métrique | Comment la panne survient | Combien de préavis vous obtenez |
|---|---|---|
| CPU | Rien ne casse. Tout ralentit - chaque requête, chaque question, chaque tâche de fond - et le site se dégrade bien avant de tomber. | Généralement beaucoup, si vous surveillez. Une montée soutenue est visible pendant des heures, voire des jours, avant de devenir visible pour les utilisateurs. |
| RAM | Soudaine et violente. Les applications sont tuées par le système d’exploitation pour récupérer de la mémoire, redémarrent, et sont tuées de nouveau - produisant exactement la panne intermittente et non reproductible la plus difficile à diagnostiquer. | Peu, à la fin. Mais la montée lente d’une fuite mémoire entre deux redémarrages est l’un des signaux les plus lisibles en surveillance, si l’historique existe. |
| Disque | Tout d’un coup. Les journaux cessent de s’écrire, la base de données refuse les écritures, les sessions échouent, les fichiers temporaires ne peuvent plus être créés - et la cause est invisible dans les messages d’erreur de l’application elle-même. | Le préavis le plus long de tous, et le plus souvent manqué. Un volume qui se remplit à un rythme régulier est prévisible plusieurs jours à l’avance. |
| Temps de connexion | Une dépendance dont le serveur a besoin est devenue lente ou injoignable, avant que cela ne se manifeste par une panne complète. | Souvent le tout premier signal indiquant qu’un problème existe en aval. |
Le disque mérite sa réputation de panne classique et évitable. C’est la panne qu’un moniteur avec un seuil et une semaine d’historique détectera toujours en premier, et celle qu’il est le plus gênant d’avoir à expliquer après coup.
Lisez la tendance, pas seulement l’alerte
Chaque relevé est stocké, si bien que chaque moniteur serveur dispose d’un graphique de sa propre valeur dans le temps, avec la moyenne, le minimum et le maximum pour la fenêtre que vous consultez. Les pourcentages sont représentés en pourcentages et les temps de connexion en millisecondes, si bien qu’un moniteur CPU et un moniteur de latence de base de données se lisent chacun comme on s’y attend.
L’alerte vous indique qu’une ligne a été franchie ; le graphique vous indique les deux choses dont vous avez vraiment besoin ensuite. Est-ce nouveau ? - un pic qui paraît alarmant isolément est souvent le même pic qui se produit tous les mardis à 2h du matin depuis un an. Et où cela mène-t-il ? - un chiffre de mémoire qui grimpe régulièrement entre deux redémarrages est une fuite, quelle que soit sa valeur actuelle, et un disque qui grimpe de deux pour cent par semaine a une date qui lui est attachée.
Cette seconde question est l’usage « planification de capacité » de la surveillance serveur, et c’est la raison de commencer à collecter une métrique avant même de savoir quel seuil lui appliquer. Vous pourrez ajouter le seuil dans un mois, une fois que l’historique vous aura dit à quoi ressemble la normale. L’historique que vous n’avez pas collecté est celui que vous ne pourrez jamais récupérer.
La surveillance serveur et la surveillance de disponibilité répondent à des questions différentes
Elles se complètent, elles ne s’excluent pas, et la frontière entre les deux est assez nette pour mériter d’être posée clairement.
| Surveillance de disponibilité | Surveillance serveur | |
|---|---|---|
| La question à laquelle elle répond | Un visiteur peut-il joindre le site en ce moment ? | La machine qui le fait tourner est-elle assez saine pour continuer à répondre ? |
| D’où elle regarde | De l’extérieur - plus de 300 points de contrôle répartis dans 158 villes | De l’intérieur - une valeur lue sur la machine elle-même |
| Moment habituel | Vous prévient au moment de la panne | Vous prévient avant la panne, si vous fixez le seuil avant le point de rupture |
| Contrôle des fausses alertes | Une observation en échec est revérifiée depuis d’autres points de contrôle et confirmée par un quorum | Un relevé unique et faisant autorité, avec un nombre de surcharges consécutives comme anti-rebond |
| Détecte une fuite mémoire | Non - jusqu’à ce qu’elle finisse par faire planter quelque chose | Oui - sous forme de tendance, des semaines plus tôt |
| Détecte une panne de routage réseau entre vos utilisateurs et vous | Oui | Non - la machine se porte parfaitement bien |
N’utiliser que l’une des deux laisse une vraie lacune, dans les deux sens. La combinaison sur laquelle la plupart des comptes se stabilisent est une vérification de disponibilité depuis plusieurs emplacements toutes les minutes, associée à quelques moniteurs serveur sur le CPU, la mémoire et le volume le plus susceptible de se remplir.
SNMP, pour le matériel qui ne fera jamais tourner de collecteur
Les routeurs, commutateurs, pare-feux, onduleurs et imprimantes ne peuvent pas héberger de script, mais presque tous parlent déjà SNMP. Une vérification SNMP distincte lit une valeur numérique directement depuis l’équipement par OID - compteurs d’interface, température, charge, temps de fonctionnement, niveau de batterie - via SNMP v1, v2c ou v3, y compris v3 avec authentification et confidentialité afin que les identifiants ne circulent jamais en clair.
Pour être clair avec vous sur où en est cette fonctionnalité aujourd’hui : une vérification SNMP lit et enregistre la valeur rapportée par l’équipement. Le déclenchement d’alertes basé sur un seuil pour une valeur SNMP n’est pas encore disponible - lorsque vous avez besoin qu’un nombre déclenche réellement un incident, utilisez un moniteur de charge serveur contre un collecteur, qui dispose du modèle complet de condition et d’anti-rebond décrit plus haut.
Configurer la surveillance serveur
- Décidez ce que vous allez exposer. Si votre serveur exécute déjà PHP ou IIS, le collecteur prêt à l’emploi correspondant est le chemin le plus rapide ; sinon, écrivez vous-même le point de terminaison - il renvoie un seul nombre.
- Déployez-le sur le serveur que vous voulez surveiller et vérifiez que vous pouvez l’interroger vous-même. Placez-le sur un chemin impossible à deviner. Si la machine est nouvelle, la vérification gratuite de port TCP et le test ping gratuit sont un moyen rapide de confirmer qu’elle est joignable depuis l’extérieur avant d’aller plus loin - aucune connexion requise.
- Ajoutez un moniteur de type Surveiller CPU, RAM, HDD, choisissez la valeur qu’il doit lire, et indiquez-lui l’URL du collecteur. Pour un moniteur de disque, nommez le chemin ou le lecteur ; pour un moniteur de temps de connexion à une base de données, indiquez les informations de connexion que le collecteur doit composer.
- Définissez la condition et les limites - et réglez délibérément le nombre de surcharges avant panne plutôt que de le laisser à sa valeur par défaut. C’est ce réglage qui décide si le moniteur est utile ou ignoré.
- Choisissez un intervalle, de une minute à 24 heures. Une minute convient à une machine faisant tourner quelque chose de critique pour l’activité ; 5 ou 10 minutes suffisent largement pour une tendance comme l’utilisation du disque.
- Répétez l’opération pour chaque valeur importante sur cet hôte - CPU, mémoire et le volume le plus susceptible de se remplir forment un bon ensemble de départ - puis ajoutez les contacts qui doivent en être informés.
- Laissez passer une semaine avant de régler quoi que ce soit. La première semaine d’historique est ce qui vous dira si votre seuil est le bon, et c’est une bien meilleure preuve qu’une estimation faite le premier jour.
Les limites à connaître
- Le collecteur doit être joignable. Un hôte sans aucun accès entrant ne peut pas être interrogé. Ce qui doit être exposé est une seule URL en lecture seule, pas un port d’administration - mais elle doit tout de même être exposée.
- Un moniteur surveille une seule valeur. CPU, mémoire et disque sont trois moniteurs, chacun avec son propre seuil et son propre historique. C’est ce qui rend l’alerting précis, et cela signifie qu’un serveur chargé consomme plusieurs emplacements de moniteur.
- Les compteurs de performance Windows nécessitent le collecteur ASP.NET. Le triplet catégorie / nom / instance est lu localement par ce collecteur ; un hôte PHP rapporte à la place le CPU, la mémoire, le disque et les temps de connexion.
- Il n’y a pas de confirmation multi-emplacements. Contrairement à une vérification de disponibilité, une métrique serveur provient d’une seule source faisant autorité, si bien qu’un relevé anormal isolé est un relevé bien réel. Le nombre de surcharges consécutives est l’outil prévu pour ça, et il mérite d’être réglé.
- Il rapporte ce que rapporte le collecteur. Si votre point de terminaison personnalisé a un bug, le moniteur alerte fidèlement sur le mauvais nombre - c’est pourquoi le membre d’erreur facultatif dans la réponse compte : signalez une erreur plutôt qu’un zéro.
- Pas de compteur de débit réseau. Les valeurs disponibles sont le CPU, la mémoire, l’utilisation du disque, les temps de connexion et les compteurs de performance Windows ; la bande passante n’en fait pas partie. Pour un équipement qui rapporte son débit via SNMP, une vérification SNMP peut lire et représenter ce compteur.
Questions fréquemment posées
La surveillance de serveur consiste à suivre en continu l’utilisation des ressources essentielles de votre serveur - la charge CPU, l’utilisation de la RAM (mémoire) et la charge du disque dur (HDD) - afin de voir comment votre infrastructure se comporte réellement, et pas seulement si le site web qui tourne dessus répond. La surveillance de serveur de HostTracker contrôle ces trois métriques et signale les tendances et les pics dans le temps, ce qui compte car l’épuisement des ressources est l’une des causes racines les plus fréquentes des lenteurs, des plantages et des pannes pures et simples. Un serveur peut être techniquement « en ligne » tout en étant sur le point de tomber en panne si l’utilisation du CPU est au maximum, si la mémoire est presque épuisée ou si l’espace disque est critique - autant de situations qu’une simple vérification de disponibilité ne révélerait pas nécessairement avant que le problème ne provoque une panne visible.
Un serveur peut rester joignable et techniquement en ligne tout en fonctionnant dangereusement près de ses limites de ressources, ce qui signifie qu’une utilisation élevée du CPU ou de la RAM est souvent un signal d’alerte précoce plutôt que le problème lui-même. Une charge CPU élevée et soutenue ralentit chaque requête traitée par le serveur, dégradant l’expérience de tous les visiteurs même si le site ne tombe jamais complètement en panne. La pression sur la mémoire est encore plus dangereuse : à mesure que l’utilisation de la RAM approche de sa capacité maximale, les applications peuvent commencer à planter, à redémarrer ou être arrêtées par le système d’exploitation pour libérer de la mémoire, ce qui provoque souvent des pannes intermittentes et difficiles à diagnostiquer, qui ressemblent à des bugs aléatoires plutôt qu’à une panne franche. Détecter une utilisation élevée du CPU ou de la RAM grâce à la surveillance de serveur, avant qu’elle ne dégénère en panne, donne aux administrateurs le temps d’enquêter et d’ajouter de la capacité de manière proactive.
Lorsque la surveillance du CPU, de la RAM ou du disque détecte une activité inhabituelle - un pic soutenu, une mémoire qui approche de sa capacité maximale ou un espace disque qui se réduit - HostTracker envoie une notification via l’un des 9 canaux d’alerte que vous avez configurés, notamment l’e-mail, le SMS, l’appel vocal, les webhooks, Slack, et des applications de messagerie comme Telegram, Discord et Viber. Ainsi, la personne responsable de l’infrastructure serveur est informée directement d’un problème de ressources en train de se développer, plutôt que de le découvrir seulement après qu’il a déjà causé un ralentissement ou une panne remarqués par les clients. Comme les rapports et les alertes sont générés automatiquement à partir des données surveillées, les administrateurs disposent d’un historique documenté des tendances de ressources en plus de la notification en temps réel, ce qui aide à distinguer un pic isolé d’un véritable problème de capacité nécessitant une solution à long terme.
La surveillance de disponibilité répond à une question plus restreinte : le site web ou le service est-il joignable et répond-il en ce moment. La surveillance de serveur regarde sous cette surface, au niveau de l’infrastructure qui fait réellement tourner le site - charge CPU, utilisation de la mémoire et espace disque - qui sont souvent la cause racine d’une panne de disponibilité plutôt qu’un problème distinct et sans rapport. Un serveur à court de mémoire ou d’espace disque peut encore réussir un contrôle de disponibilité pendant un certain temps avant de finalement planter ou de ralentir considérablement, donc se fier uniquement à la surveillance de disponibilité signifie que vous ne découvrez le problème qu’une fois qu’il est déjà devenu une panne. Combiner les deux donne une vision plus complète : la surveillance de disponibilité confirme que le site est actuellement joignable, tandis que la surveillance de serveur suit les tendances de ressources sous-jacentes qui prédisent s’il a des chances de le rester.
La fréquence de vérification est configurable pour s’adapter à la rapidité avec laquelle vous devez être informé d’un problème de ressources en développement. Les forfaits payants de HostTracker prennent en charge des intervalles de surveillance aussi rapprochés qu’une fois par minute, ce qui est utile pour les serveurs exécutant des applications critiques où un pic de ressources doit être détecté et traité rapidement. Les serveurs moins critiques ou à faible trafic peuvent utiliser un intervalle plus long, et le forfait gratuit permanent vérifie deux moniteurs toutes les 30 minutes, ce qui suffit souvent à détecter une tendance soutenue comme un espace disque qui se remplit progressivement sur plusieurs jours, même si cela ne détecterait pas un pic de CPU très bref. Un essai gratuit de 30 jours avec toutes les fonctionnalités, sans carte bancaire requise, vous permet de tester des intervalles de vérification plus rapides et de voir le niveau de détail que ces données vous apportent avant de choisir un forfait.
Non - il n’y a pas d’agent HostTracker à installer, pas de démon à maintenir en fonctionnement et aucun identifiant à transmettre. Une vérification de charge serveur fonctionne à l’inverse : votre serveur expose un petit point de terminaison en lecture seule qui rapporte un seul nombre, et HostTracker l’interroge selon le calendrier que vous définissez. Vous disposez de trois façons de le fournir. Deux sont des scripts collecteurs prêts à l’emploi que vous déposez sur un serveur que vous exploitez déjà - l’un pour PHP sous Linux ou Unix, l’autre pour ASP.NET sous IIS - et la troisième consiste à écrire vous-même le point de terminaison, ce qui tient en une dizaine de lignes dans n’importe quel langage : lisez la valeur comme bon vous semble et répondez avec un petit objet JSON qui la contient. Cette troisième option est celle que beaucoup d’équipes préfèrent, car cela signifie que rien qu’elles n’ont pas écrit elles-mêmes ne tourne jamais sur leur machine, et qu’elles décident exactement quels nombres sont exposés. Rien n’est jamais poussé automatiquement vers votre serveur, et HostTracker n’y ouvre jamais de session d’administration.
Le point de terminaison du collecteur doit être joignable par les vérificateurs de HostTracker, donc un serveur derrière un pare-feu sans aucun accès entrant ne peut pas être interrogé directement. En pratique, c’est un obstacle plus modeste qu’il n’y paraît, car ce qui doit être exposé est une simple URL en lecture seule qui renvoie un nombre - pas du SSH, pas un port d’administration, pas un protocole de surveillance. Les approches habituelles consistent à publier le point de terminaison sur un chemin impossible à deviner, à le restreindre aux adresses qui l’appellent, ou à l’héberger sur une machine du même réseau déjà exposée sur Internet et à la faire rapporter pour le compte de l’hôte privé. Quel que soit votre choix, l’exposition est délibérément minime : le point de terminaison n’accepte aucune commande, ne change rien, et renvoie un seul nombre. C’est une conversation de sécurité très différente de celle qu’impliquerait l’installation d’un agent tiers avec un accès de niveau système - c’est précisément pour cela que la vérification est conçue ainsi.
La surveillance de la charge serveur - contrôles CPU, RAM et HDD - est l’un des 13 types de contrôles disponibles dans l’ensemble des produits HostTracker, et le forfait gratuit permanent vous permet de surveiller deux serveurs ou sites sans frais, avec des vérifications toutes les 30 minutes. HostTracker dans son ensemble n’est pas un produit uniquement gratuit - c’est un service de surveillance payant avec un forfait gratuit en complément - le forfait gratuit convient donc bien pour tester la surveillance de serveur sur quelques machines ou comme option légère pour de petits projets, et non comme offre principale. Pour surveiller davantage de serveurs, avec des intervalles de vérification plus courts, ou pour une infrastructure critique où une détection plus rapide compte, les forfaits payants démarrent autour de 5 $ par mois, et un essai gratuit de 30 jours avec toutes les fonctionnalités, sans carte bancaire requise, vous permet de tester les intervalles plus rapides avant de vous décider.
Continuez à explorer la surveillance HostTracker
Surveillez les connexions à la base de données et les résultats des requêtes
Exécutez des vérifications de connexion périodiques et validez les résultats des requêtes sur MySQL, PostgreSQL, SQL Server et plus encore, afin qu’un problème de base de données silencieux ne passe jamais inaperçu.
Parcourez toutes les fonctionnalités de surveillance HostTracker
Comparez les 8 types de surveillance côte à côte et combinez les vérifications adaptées à votre site.
Détectez la surcharge de votre serveur avant qu’elle ne le mette à terre
Démarrez un essai gratuit et soyez alerté dès que la charge CPU, RAM ou disque dépasse vos seuils.
Fait partie du service de surveillance de sites web de HostTracker.