HTTPS
Monitoring de sites web et d'APIs
Une page ou un endpoint, récupéré depuis quatre continents.
Essaie-le maintenant
Un test, depuis un endroit, tout de suite, et rien n'est sauvegardé. Un monitor vérifie depuis chaque emplacement où on est présent et confirme une panne depuis deux autres continents avant de réveiller quelqu'un, ce qu'un simple test ne peut pas te montrer.
À quoi ça sert
Le check par lequel tout le monde commence, et celui où la plupart des produits s'arrêtent. On demande l'URL, on suit ou refuse les redirections comme tu le dis, et on lit le code de statut.
Un code de statut seul est une promesse fragile. Un site peut renvoyer 200 tout en servant une page d'erreur, un écran de connexion, une copie en cache de mardi dernier, ou une coquille vide qui n'a pas pu se rendre. Donc le check peut aussi exiger qu'une phrase soit présente, qu'une redirection arrive à un endroit précis, qu'un champ JSON contienne une valeur particulière, et qu'une réponse arrive dans un délai que tu fixes. Ce sont les échecs qu'un code de statut ne peut pas voir.
Comme chaque vérification ici, elle s'exécute depuis Amsterdam, New York, Sydney and Singapore, et un échec est confirmé depuis deux autres continents avant que quelqu'un soit réveillé. Comment ça marche.
Ce que tu peux configurer
Tout ce qui suit est dans le formulaire quand tu en ajoutes un, sur chaque forfait.
- Méthode
- GET, HEAD, POST, PUT, PATCH ou DELETE. HEAD est le choix par défaut, poli, pour une page dont tu veux juste savoir qu'elle existe.
- Statut attendu
- Quels codes comptent comme sains. Un 401 est correct pour un endpoint qui doit te refuser, et le dire nous empêche de signaler que ton authentification qui marche est une panne.
- Mot-clé
- Une phrase qui doit être là, ou absente. La façon la plus simple de détecter un 200 qui est en fait une page d'erreur.
- Assertions JSON
- Un chemin et la valeur qu'il doit contenir, pour une API qui répond 200 avec un body disant autre chose.
- Redirections
- Suivre la chaîne, ou traiter une redirection comme la réponse. Avec un emplacement attendu, cela détecte un site redirigé discrètement là où il ne devrait pas.
- Lent, c'est un échec
- Un temps de réponse au-delà duquel le check est considéré comme dégradé plutôt qu'en ligne, et combien d'affilée avant qu'on le dise.
- Authentification
- Basic ou Bearer. Stocké chiffré, déchiffré par le control plane, et transmis à la sonde avec la tâche plutôt que de donner à une machine louée la clé de tout.
- Headers et body
- Tout ce dont la requête a besoin. Un header par ligne, et un body pour les méthodes qui en prennent un.
- Timeout
- Combien de temps attendre avant de considérer que c'est un échec.
- Confirmations
- Combien d'autres continents doivent être d'accord avant de réveiller quelqu'un. Zéro est possible et rarement ce que tu veux.
Questions
Que signifient un 502 ou un 503, et vas-tu alerter dessus ?
Un 502, c'est le serveur en façade qui te dit que celui derrière a donné une réponse inutilisable, et un 503, c'est un serveur qui dit qu'il ne prend pas de requêtes, ce que la plupart des frameworks renvoient pendant un redémarrage. Les deux échouent au test par défaut, car le défaut attend des 2xx et 3xx. Si un code est correct pour cet endpoint, mets-le dans la liste des statuts attendus et ce n'est plus une panne.
Vérifies-tu la chaîne de certificats SSL/TLS ?
Oui. Le test se connecte comme un navigateur, en utilisant le trust store public, donc un intermédiaire manquant, un certificat auto-signé, un nom d'hôte incorrect ou expiré fait échouer le test avec une erreur TLS plutôt qu'un code de statut. Ce qu'il ne fait pas, c'est compter les jours restants, ce qui est le rôle du monitor de certificat SSL/TLS. La vérification peut être désactivée par monitor pour un hôte interne que tu connais.
Puis-je monitorer un endpoint API plutôt qu'une page ?
C'est pour ça qu'il y a les options de requête, et c'est pourquoi il n'y a pas de type de monitor API séparé. Choisis POST, PUT, PATCH ou DELETE, ajoute des headers et un body, authentifie-toi avec des credentials basic ou bearer, accepte les codes de statut corrects, et vérifie un chemin dans le JSON qui revient.
Quelle est la différence entre un timeout et une réponse lente ?
Un timeout, c'est un test qui n'a jamais reçu de réponse dans le délai que tu as défini, et c'est signalé comme un échec sans code de statut, sauf si la connexion a été refusée directement. Lent, c'est une réponse qui est arrivée mais a pris trop de temps : définis un temps de réponse au-delà duquel le test est considéré comme dégradé, et combien d'affilée avant que quelqu'un en soit informé.
Suis-tu les redirections ?
Pas sauf si tu le dis, ce qui surprend assez souvent pour mériter une explication. Un site qui commence à répondre 302 vers une page de parking est cassé, et un testeur qui suit ça tranquillement et trouve un 200 le signalerait comme sain. Active le suivi quand la redirection est le but, et indique l'emplacement où tu veux arriver.
Le check exécute-t-il du JavaScript ou rend-il la page ?
Non, et on le dit plutôt que de laisser entendre le contraire. Il récupère le document envoyé par le serveur et le lit, donc un test de mot-clé doit correspondre à quelque chose dans le HTML et pas à ce qu'un framework affiche après. Pour une page rendue dans le navigateur, vérifie le code de statut, le temps de réponse et une phrase qui est vraiment dans la réponse.
Le temps de réponse est-il celui que mes visiteurs expérimentent ?
C'est le temps que notre sonde a attendu, de la requête à la réponse, sur une connexion sans cache froid et sans navigateur devant. C'est un excellent détecteur pour un serveur qui ralentit, mais un mauvais modèle pour une personne sur un téléphone. Le monitoring utilisateur réel et les Core Web Vitals répondent à cette autre question, et ce test ne prétend pas le faire.
Pourquoi ne pas simplement utiliser curl dans un cron job ?
Pour une URL depuis une machine, un cron job fait vraiment la plupart de ça, et quiconque te dit le contraire te vend quelque chose. Ce qu'il ne te donne pas, c'est un endroit pour l'exécuter qui ne peut pas lui-même mourir discrètement : un test sur une machine qui a perdu son réseau ne rapporte rien, ce qui ressemble exactement à tout va bien. Il ne te dit pas non plus si un lien cassé entre toi et le site vient du site lui-même, ce que vérifier depuis deux autres continents permet de savoir, et il te reste à construire la partie qui réveille quelqu'un.
En quoi est-ce différent d'un test synthétique basé sur un navigateur ?
Un test synthétique pilote un vrai navigateur, donc il voit des choses que nous ne pouvons pas : une page qui s'affiche vide parce qu'un script a planté, un bouton qui ne fonctionne plus, une police qui n'a jamais chargé. Ce test fait la requête et lit la réponse, ce qui signifie qu'il ne peut rien voir de tout ça. Ce qu'il te donne à la place, c'est un test assez peu coûteux pour être exécuté toutes les trente secondes depuis trois continents, sur chaque URL que tu as, plutôt qu'une poignée de parcours quelques fois par heure. Ils répondent à des questions différentes et beaucoup de gens veulent les deux.