Un proxy récupère votre page de vérification d'IP et échoue sur l'API dont votre application a besoin. Le qualifier de « sain » ou de « mort » fait perdre le fait le plus utile : les deux requêtes étaient différentes.

Commencez par un enregistrement couvrant tout le transport pour le point de terminaison. Pouvez-vous atteindre son écouteur et mener à bien la négociation de proxy requise ? Conservez les observations propres à la destination à côté de cet enregistrement plutôt que de l'écraser.

ObservationPérimètre à examiner
L'écouteur du proxy refuse les connexionsLe point de terminaison et la route vers celui-ci
Le proxy refuse un port de destinationL'opération autorisée pour cette destination
Un site web renvoie une erreur de compteL'application de destination et les identifiants
Les grandes réponses bloquent, les petites aboutissentLa charge de transfert et la politique de délai

Une réponse HTTP peut établir qu'un chemin de requête a renvoyé quelque chose tout en restant inutilisable pour l'application. Conservez le succès du transport, le statut HTTP et le contenu attendu comme des résultats distincts.

Si une destination échoue de façon répétée, mettez en pause ou examinez ce couple point de terminaison-destination. Désactiver le proxy pour chaque tâche sans rapport peut gaspiller une capacité utile. À l'inverse, une défaillance de connexion globale ne devrait pas rester cachée derrière l'enregistrement isolé d'un seul site web.

Une clé de santé pratique peut inclure l'identifiant du proxy, le service de destination et le type d'opération. Évitez d'utiliser l'URL complète porteuse d'identifiants ou chaque chemin de ressource unique comme une clé qui ne cesse de croître. Ne regroupez que lorsque le regroupement fournit une prédiction significative sur la requête suivante.

Le but est une meilleure preuve de routage, non une plus grande collection de badges verts. Un résultat de santé devrait indiquer ce qui a été tenté, quand, et ce qu'il a réellement établi.

Articles similaires