Comment configurer la surveillance d'API dans HostTracker

Paramètres principaux

Il n'existe pas de capture d'écran pour cette section pour le type API, mais elle utilise les mêmes contrôles partagés que tout autre type de vérification. Surveillance activée est l'interrupteur maître marche/arrêt. Planification par intervalle (1 minute à 24 heures, curseur ou menu déroulant) ou un constructeur de planification cron (toutes les N minutes/heures, quotidien, hebdomadaire, mensuel, ou une expression personnalisée, forfait payant uniquement) contrôle la fréquence d'exécution de la vérification. Le délai d'expiration va de 1 à 100 secondes ; le temps de résolution DNS n'est pas compté. Les étiquettes sont des libellés séparés par des virgules pour regrouper et filtrer. Le journal complet enregistre chaque résultat au lieu de regrouper les résultats identiques consécutifs, et les statistiques ouvertes publient les statistiques et le journal de la tâche sur un lien public. Contrairement à HTTP, le formulaire API n'a pas d'interrupteur DNSBL (DNSBL n'est conservé que pour Http/Ping/Port) ; il porte bien les mêmes cartes Expiration du domaine, Expiration du certificat et Web Risk, chacune s'exécutant toutes les 12 heures : les rappels d'expiration suivent vos abonnements Up ci-dessous, un mauvais résultat suit Down/Repeat.

Configuration de la requête

• Méthode HTTP - GET, HEAD, POST, PUT, DELETE ou PATCH. GET (par défaut) est nécessaire pour lire et analyser un corps de réponse ; HEAD ne récupère que les en-têtes.
• Corps de la requête (POST/PUT/PATCH uniquement) - Corps brut envoie exactement ce que vous tapez (ajoutez votre propre en-tête Content-Type pour décrire json/xml/texte brut) ; Paramètres POST accepte une paire CLÉ=VALEUR par ligne et est envoyé comme un corps form-urlencoded.
• Comportement de redirection - Réponse immédiate juge la première réponse telle quelle ; Suivre les redirections (par défaut) suit la chaîne, avec un curseur Max redirections à suivre (1-20) ; La redirection est une erreur échoue sur toute redirection (indisponible en mode assertion).
• En-têtes HTTP - paires nom/valeur personnalisées, avec des suggestions de saisie pour les noms et valeurs d'en-tête API courants (Content-Type, Authorization, X-API-Key, préfixes Bearer/Basic et plus). Laissé vide, la sonde envoie les en-têtes par défaut (User-Agent, Accept, Accept-Language, un Referer).
• Authentification de la requête - révèle un nom d'utilisateur/mot de passe pour l'authentification par défi HTTP propre au serveur (Basic, Digest, NTLM, Kerberos, Negotiate). Pour un jeton bearer ou une clé API, ajoutez plutôt un en-tête Authorization ci-dessus.
• Sélection du serveur DNS - Serveurs DNS par défaut des emplacements ; Serveurs DNS publics du pays de l'emplacement ; ou Serveurs DNS définis manuellement (vos propres IP de résolveur). Les deux dernières options nécessitent un forfait payant.
• Désactiver le cache DNS - force une résolution DNS fraîche à chaque vérification plutôt que de réutiliser le cache de l'agent.

Validation de la réponse

Par défaut, une vérification réussit quand le DNS se résout, que la connexion et la poignée de main TLS (pour https) se terminent, que le serveur renvoie un statut HTTP Ok, et que la réponse s'analyse selon le format sélectionné ci-dessous.

• Mode assertion - la capture d'écran le montre désactivé, avec une bannière vous invitant à l'activer pour des règles sur le code de statut, le temps de réponse, les en-têtes ou le contenu du corps. API et HTTP sont les deux seuls types de vérification avec un éditeur d'assertions fonctionnel ; voir l'exploration approfondie du mode assertion pour le langage de règles complet. Tant qu'il est désactivé, les champs classiques ci-dessous pilotent le verdict.
• Ignorer les erreurs HTTP - codes de statut qui NE doivent PAS faire échouer la vérification, par exemple 401, 403, 500 ; vide signifie que chaque code 400 et plus est une erreur.
• Erreur sur ces statuts HTTP - l'inverse : des codes qui doivent faire échouer la vérification même s'ils ne le feraient normalement pas.
• Format de la réponse - comment le corps est analysé avant l'exécution du sélecteur : Analyse JSON (sélecteur JSONPath ou de propriété, montré sélectionné sur la capture), Analyse XML (requête XPath), ou Analyse de chaîne (expression régulière avec capture). GET est requis pour lire un corps.
• Sélecteur - extrait une valeur de la réponse analysée ; laissez vide pour utiliser la réponse entière comme valeur.
• Ce qu'il faut vérifier - par défaut, la condition ci-dessous juge la valeur sélectionnée elle-même (Vérifier la valeur obtenue elle-même) ; passez à Vérifier le changement de valeur entre deux vérifications, ou un taux de changement par seconde/par minute, pour juger plutôt de l'ampleur du mouvement de la valeur.
• Condition - compare la valeur : any (aucune validation) (par défaut, montré sur la capture), equal to, not equal to, in set of, out of set, less than, less or equal, greater than, greater or equal, in range, out of range, absent in content, ou json null. Toute condition sauf les deux dernières a besoin d'une valeur de comparaison saisie en dessous.
• Politiques HTTP - les mêmes vérifications optionnelles d'en-têtes/cookies/contenu que le type de vérification HTTP : imposer HTTPS, en-tête HSTS, pas de rétrogradation https vers http, CSP, protection contre le clickjacking, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, pas de divulgation de version, assertions Cache-Control, en-têtes de réponse CORS, sécurité des cookies et contenu mixte. Les préréglages Baseline, Strict et API remplacent toute la sélection ; une violation conclut la vérification en Down comme n'importe quel autre échec.
• Négociation TLS - quatre interrupteurs de rigueur (forfait payant) : exiger une chaîne de certificats SSL valide, exiger TLS 1.2 ou supérieur, bloquer les chiffrements faibles (128 bits ou moins), et vérifier la révocation du certificat.
• Validation des IP attendues - confirme que le DNS résout votre hôte vers l'une des IP que vous listez à chaque vérification, détectant un détournement ou un enregistrement périmé même pendant qu'un serveur répond encore.
• Taille maximale de la réponse - arrête la lecture du corps au-delà de cette taille, de sorte que l'analyseur et le sélecteur ne voient que la partie téléchargée. Par défaut 1 Mo, maximum 10 Mo ; 0 ne lit aucun corps.

Une note sur les captures d'écran ci-dessus : elles ont été prises sur un compte dont le forfait n'inclut pas le type de vérification API, donc le champ de sélection du type y affichait « not in your package ». C'est un artefact du compte de test, pas quelque chose que vous verrez : chaque champ et chaque valeur par défaut décrits ici sont exactement ce que montre le formulaire par ailleurs.

Abonnements aux alertes

Partagé par tous les types de vérification. Down = l'endpoint a échoué à la vérification, Up = il s'est rétabli, Repeat = rappels tant qu'il reste hors service. Abonner tous les contacts aux événements Up/Down est un raccourci ; le tableau donne un contrôle par contact, individuellement ou via des préréglages de groupes de contacts réutilisables. Une tâche sans abonnement aux alertes s'exécute et enregistre quand même les résultats, elle ne notifie simplement jamais personne.

Abonnements aux rapports

Rapports de disponibilité périodiques, e-mail uniquement. Choisissez Quotidien, Hebdomadaire ou Mensuel par contact ; Mensuel inclut aussi des résumés trimestriels et annuels. L'interrupteur d'abonnement global fonctionne comme dans Abonnements aux alertes.

Emplacements de surveillance

• Sélecteur d'emplacements - recherchez ou parcourez l'arbre région/pays et cochez les emplacements depuis lesquels vérifier ; chaque ligne montre les agents disponibles par rapport aux agents sélectionnés. « Copier les emplacements d'une autre tâche » réutilise un ensemble existant.
• Stratégie de revérification - lors d'une transition d'état (par exemple de Up à Down), plusieurs emplacements la revérifient avant que le nouvel état ne soit accepté, se protégeant contre un faux positif venant d'une région. Options : vote majoritaire par défaut ; un nombre spécifié d'emplacements confirmant Down (ajoute un curseur 1-7) ; aucune revérification ; accord complet de chaque emplacement de revérification ; ou accord complet pour Down, vote majoritaire pour Up.
• Si les emplacements sélectionnés sont indisponibles - Emplacements sélectionnés uniquement (par défaut) attend plutôt que de risquer une fausse alerte ; Emplacements les plus proches utilise l'emplacement disponible le plus proche ; N'importe quel emplacement se rabat sur le monde entier.

Exemple concret

Surveiller un endpoint de statut JSON : vérification API, intervalle de 5 minutes, délai d'expiration de 40 s, GET, Suivre les redirections (max 20). Format de la réponse Analyse JSON, Sélecteur $.status, Ce qu'il faut vérifier « la valeur obtenue elle-même », Condition « equal to » avec la valeur de comparaison ok. Ignorer les erreurs HTTP laissé vide. Emplacements de surveillance laissés sur Tout le monde avec la stratégie de revérification par défaut. L'e-mail de l'équipe d'astreinte abonné à Down, Up et Repeat, et aux rapports Hebdomadaire.

Dépannage

• La vérification réussit toujours alors que l'endpoint est clairement cassé - Condition est par défaut sur any (aucune validation), qui ne juge que l'analyse et le transport, pas la valeur elle-même. Choisissez une vraie condition et une valeur de comparaison une fois que vous savez à quoi ressemble une réponse saine.
• Le sélecteur ne renvoie rien - confirmez que le format de la réponse correspond à ce que l'endpoint renvoie (JSON vs XML vs texte brut) ; un sélecteur JSONPath sur un corps XML ne correspond jamais. Laissez d'abord le sélecteur vide pour confirmer que la réponse entière arrive, puis affinez-le.
• Une condition numérique (greater than, in range, etc.) renvoie une erreur - elle a besoin que la valeur sélectionnée se convertisse en nombre. Un sélecteur pointant vers une chaîne, ou un calcul en mode changement sans vérification précédente encore, ne lui donne rien à comparer.
• Est passé en Down juste après l'activation des Politiques HTTP (surtout Strict) - Strict attend des en-têtes que beaucoup d'API n'ont pas configurés. Corrigez les en-têtes, revenez à Baseline, ou exécutez d'abord les politiques comme une tâche séparée.
• Le sélecteur cesse de trouver une valeur sur une grande réponse - la taille maximale de la réponse coupe le corps, de sorte que rien après la coupure n'atteint l'analyseur ou le sélecteur. Augmentez-la.

Voir aussi

• Surveillance et validation d'API - la page produit pour ce type de vérification.
• Vérification HTTP/API instantanée gratuite - lancez une vérification ponctuelle sans compte requis.
• Règles de validation de réponse en mode assertion - le langage de règles complet derrière la Validation de la réponse.
• API HostTracker - automatisez la gestion de vos moniteurs depuis votre propre code.
• Documentation de l'API v2 - la référence complète de l'API utilisée pour construire des intégrations.
• 429 Too Many Requests - le statut qu'une API renvoie quand l'appelant est limité en fréquence, et ce qu'il faut faire.
• Tous les guides de surveillance - le guide de configuration pour chaque autre type de vérification.