Proxy-sundhed: hvilket websted og hvilken handling testede du?
Adskil generel proxy-tilgængelighed fra destinationsspecifikke fejl, når du vedligeholder en genbrugelig proxy-pulje.
En proxy henter din IP-kontrolside og fejler på det API, din applikation har brug for. At kalde den “sund” eller “død” mister den mest nyttige kendsgerning: de to anmodninger var forskellige.
Start med en transportdækkende registrering for endepunktet. Kan du nå dens lytter og gennemføre den krævede proxy-forhandling? Hold destinationsspecifikke observationer ved siden af den registrering i stedet for at overskrive den.
| Observation | Omfang at undersøge |
|---|---|
| Proxy-lytteren afviser forbindelser | Endepunktet og ruten dertil |
| Proxyen afviser én destinationsport | Den tilladte handling for den destination |
| Ét websted returnerer en kontofejl | Destinationsapplikationen og legitimationsoplysningerne |
| Store svar går i stå, små bliver færdige | Overførselsarbejdsbyrden og timeout-politikken |
Et HTTP-svar kan fastslå, at en anmodningssti returnerede noget, mens den stadig er ubrugelig for applikationen. Hold transport succes, HTTP-status og forventet indhold som separate resultater.
Hvis én destination fejler gentagne gange, sæt den endepunkt-og-destination-kombination på pause, eller undersøg den. At deaktivere proxyen for enhver urelateret opgave kan smide nyttig kapacitet væk. Omvendt bør en global forbindelsesfejl ikke forblive skjult bag ét websteds isolerede registrering.
En praktisk sundhedsnøgle kan omfatte proxy-identifikatoren, destinationstjenesten og handlingstypen. Undgå at bruge hele den legitimationsbærende URL eller enhver unik ressource-sti som en stadigt voksende nøgle. Gruppér kun, hvor grupperingen giver en meningsfuld forudsigelse om den næste anmodning.
Formålet er bedre routing-evidens, ikke en større samling af grønne badge:er. Et sundhedsresultat bør sige, hvad der blev forsøgt, hvornår, og hvad det faktisk fastslog.