Guide de configuration de la surveillance CPU, RAM et disque
Une vérification Counter (nommée Monitor CPU, RAM, HDD dans le panneau Nouveau moniteur) lit une valeur numérique selon un horaire et peut alerter quand cette valeur franchit un seuil que vous définissez. La valeur peut être la charge CPU, l'utilisation mémoire, l'utilisation disque, le temps de connexion d'un port, le temps de connexion d'une base de données, ou un compteur de performance Windows. Elle répond à une question différente d'une vérification de disponibilité : pas « le site répond-il », mais « la machine en dessous manque-t-elle de place ».
Avant de commencer
Il n'existe pas d'agent HostTracker installable pour ce type de vérification, ni de sélecteur d'Emplacements de surveillance par moniteur. L'interrogation s'exécute depuis l'infrastructure de vérification privée propre à HostTracker, pas depuis le réseau public distribué. La vérification fonctionne dans l'autre sens : votre serveur expose un petit endpoint qui répond avec un seul nombre, et HostTracker l'interroge selon l'horaire. Il existe trois façons de fournir cet endpoint, choisies avec le réglage Value provider ci-dessous, et quelle que soit celle que vous choisissiez, elle doit être déployée et joignable avant que vous ne créiez le moniteur :
- Écrivez l'endpoint vous-même (l'option custom). Il répond avec un petit objet JSON, ce que beaucoup d'équipes préfèrent puisque rien qu'elles n'ont pas écrit elles-mêmes ne s'exécute jamais sur leur serveur.
- Déployez le collecteur PHP prêt à l'emploi de HostTracker sur un serveur web Linux/Unix.
- Déployez le gestionnaire ASP.NET 4.0 prêt à l'emploi de HostTracker sur un serveur IIS/Windows.
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 qui renvoie un nombre, pas un port d'administration, mais elle doit quand même être accessible aux vérificateurs de HostTracker.
Source de surveillance
Aucune capture d'écran n'est disponible pour cette section, mais chaque contrôle qu'elle contient a quand même besoin d'être expliqué, puisque c'est ce qui distingue ce type de vérification du reste du panneau.
- Value provider - un menu déroulant avec trois choix. Value provider - your own web service (personnalisé) : votre endpoint répond
{"v": 12.34, "e": "error text", "vs": "version string"}, et au moins une valeur ou une chaîne d'erreur doit être présente, donc un endpoint qui renvoie juste{"v": 42.5}rapporte 42,5 à chaque vérification. HostTracker collector - PHP, for *nix web servers : nécessiteshell_execactivé dansphp.ini(il lance des commandes shell verstop,freeetdf), plus les extensionsmysql/mysqlipour une lecture du temps de connexion MySQL. HostTracker collector - ASP.NET 4.0, for IIS/Windows : l'identité du pool d'applications a besoin des droits de lecture sur les compteurs de performance et le registre, et Network Service suffit généralement. Les deux collecteurs prêts à l'emploi se téléchargent depuis cette section et doivent être déployés manuellement sur le serveur cible ; HostTracker ne pousse jamais rien automatiquement sur votre serveur. - Le champ monitor URL juste en dessous est libellé Full monitor url pour l'option personnalisée (l'adresse exacte de l'endpoint, appelée telle quelle) ou Base monitor url pour un collecteur prêt à l'emploi (la racine du site sous laquelle le script du collecteur a été déployé ; HostTracker y ajoute le propre nom de fichier du collecteur).
- Une fois un collecteur prêt à l'emploi sélectionné, un menu déroulant Counter type apparaît : CPU usage %, RAM usage %, Disk or file system usage %, Port connection time (ms), MySQL connection time (ms), et, ASP.NET uniquement, SQL Server connection time (ms) et Windows performance counter. Chacun apporte son propre champ : une lettre de disque ou un chemin *nix, un hôte et un port, une chaîne de connexion (avec un lien d'exemple de format), ou un triplet catégorie / nom / instance pour un compteur de performance (l'instance peut rester vide pour la valeur par défaut, souvent
_Total).
Paramètres principaux
Les Paramètres principaux pour ce type n'ont pas de capture d'écran dédiée, voici donc chaque contrôle qu'ils contiennent :
- Intervalle - de 1 minute jusqu'à 24 heures, plus une alternative en planification cron. Une minute convient à une machine critique pour l'activité ; 5 ou 10 minutes suffisent amplement pour une tendance plus lente comme l'utilisation disque.
- Étiquettes - libellés en texte libre pour regrouper et filtrer les moniteurs.
- Journal complet - enregistre chaque valeur interrogée individuellement au lieu de seulement des résumés regroupés.
- Statistiques ouvertes - rend la page de statistiques et de journal de ce moniteur partageable, y compris avec des personnes qui ne sont pas connectées.
- Retry on connect fail - un interrupteur, activé par défaut, qui retente une fois avant de marquer un échec de récupération comme une erreur pure et simple.
- Les contrôles Value provider, monitor URL et Counter type décrits sous Source de surveillance ci-dessus vivent aussi dans ce groupe dans le panneau.
Validation de la réponse

C'est ici que vous transformez une lecture brute en alerte, et c'est ce avec quoi les lecteurs ont tendance à avoir du mal. Un seuil réglé trop serré se déclenche à chaque pic ordinaire, et un seuil réglé trop lâche ne se déclenche jamais avant qu'il ne soit trop tard pour compter.
- Error condition - montrée sur la capture à sa valeur par défaut, no condition, ce qui signifie que le moniteur rapporte seulement la valeur sans verdict Down. Choisir equals, not equal to, less than ou greater than révèle un champ numérique pour la limite ; choisir inside range ou outside range en révèle deux, une limite basse et une limite haute.
- Overloads before Down - apparaît dès qu'une condition autre que « no condition » est sélectionnée. C'est un curseur de 0 à 20 : le nombre de vérifications consécutives qui doivent déjà enfreindre la condition avant que le moniteur ne bascule en Down. À 0, une seule lecture en infraction compte immédiatement ; à 3, par exemple, trois vérifications de suite au-dessus de la limite sont nécessaires. HostTracker évalue cela de façon centralisée, pas la machine surveillée, et c'est ce qui décide si le moniteur est utile ou crie constamment au loup. Un serveur dont la charge CPU fait des pics de quelques secondes plusieurs fois par heure a besoin d'un amortissement au-dessus de 0, sinon chaque pic ordinaire devient une alerte.
Choisir le seuil lui-même est un jugement propre à ce que vous surveillez. Il n'existe pas un seul bon chiffre, donc accordez-y une vraie attention plutôt que de laisser la valeur par défaut en place. Une propriété utile de cette vérification : un échec de récupération (le collecteur est injoignable, expire, ou renvoie quelque chose d'inanalysable) est signalé comme une erreur immédiatement et n'est jamais compté dans l'amortissement ci-dessus, de sorte qu'une connexion instable vers le collecteur ne peut pas satisfaire un compte de surcharges consécutives destiné à une vraie pression de ressources.
Abonnements aux alertes

Choisissez quels contacts entendent parler de ce moniteur et pour quels événements : Up, Down, et Repeat (un rappel répété tant que la vérification reste hors service). Un seul interrupteur abonne chaque contact à Up/Down en une fois, ou choisissez des contacts et des événements individuels dans le tableau en dessous.
Abonnements aux rapports

Séparément des alertes, choisissez qui reçoit les rapports périodiques pour ce moniteur, Quotidien, Hebdomadaire ou Mensuel, par e-mail.
Exemple concret
Surveiller l'espace disque sur un serveur Linux qui fait déjà tourner PHP : déballez le collecteur PHP prêt à l'emploi sur le serveur et confirmez qu'il est joignable à sa propre URL. Réglez Value provider sur l'option du collecteur PHP, la monitor URL sur l'adresse de base du site, Counter type sur Disk or file system usage %, et le chemin du système de fichiers sur /dev/sda1. Réglez Error condition sur greater than, avec une limite de 90 (pour cent), et Overloads before Down sur 3, de sorte que trois lectures consécutives au-dessus de 90 % soient nécessaires avant qu'une alerte ne se déclenche. Un bref pic dû à une tâche de sauvegarde n'en déclenchera pas une, mais un remplissage soutenu le fera. L'intervalle est de 10 minutes, et le CPU et la RAM reçoivent leurs propres moniteurs séparés sur le même serveur avec le même collecteur.
Dépannage
- Le collecteur est injoignable. Un hôte sans aucun accès entrant ne peut pas être interrogé. Confirmez que l'endpoint répond depuis l'extérieur de votre propre réseau, sur un chemin difficile à deviner si l'exposition vous inquiète, puisqu'il n'accepte aucune commande et ne change rien.
- Le moniteur alerte sur un nombre manifestement erroné. La vérification rapporte ce que le collecteur rapporte. Corrigez l'endpoint, et envisagez de le faire rapporter la chaîne d'erreur optionnelle plutôt qu'un mauvais nombre quand quelque chose se passe mal de son côté.
- Les alertes se déclenchent à chaque pic mineur. Augmentez Overloads before Down plutôt que le seuil lui-même. Le laisser à 0 fait compter n'importe quel pic isolé.
- Le collecteur PHP rapporte « shell_exec is denied on server ». Les lectures CPU, RAM et disque lancent toutes des commandes système, donc confirmez que
shell_execne figure pas dans la liste des fonctions désactivées dephp.ini. - Une vérification de compteur de performance Windows renvoie une erreur. L'identité du pool d'applications a besoin des droits de lecture sur les compteurs de performance et le registre ; si ce n'est pas déjà Network Service, essayez de le régler ainsi.
Voir aussi
- Tous les guides de surveillance - le centre pour chaque type de vérification HostTracker.
- Qu'est-ce que la surveillance de serveur - à quoi servent ces lectures et comment elles s'articulent avec les vérifications de disponibilité.
- Surveillance de serveur : CPU, RAM et disque - la page produit pour ce type de vérification.
- Guide de la surveillance SNMP - la voie alternative vers les mêmes métriques sur du matériel qui ne peut pas faire tourner un collecteur, comme les routeurs et les commutateurs.
- Surveillance de requêtes de base de données - pour surveiller directement les requêtes et résultats d'une base de données, au-delà d'un simple temps de connexion.
- Guide de la vérification de base de données - une autre vérification qui s'exécute depuis l'infrastructure privée de HostTracker.
- Outil gratuit de vérification de port - un moyen rapide de confirmer qu'un port est joignable avant de câbler un moniteur complet de temps de connexion autour.
- Mode assertion et règles de validation de réponse - le langage de règles de validation de réponse utilisé ailleurs dans HostTracker.