Proxy-helse: kva nettstad og kva operasjon testa du?
Skil generell proxy-tilgjenge frå feil som er spesifikke for destinasjonen når du vedlikeheld ein gjenbrukbar proxy-pool.
Ein proxy hentar IP-kontrollsida di og feilar på API-et applikasjonen din treng. Å kalla han «sunn» eller «død» mistar den nyttigaste kjensgjerninga: dei to førespurnadene var ulike.
Start med ei transportomfattande registrering for endepunktet. Kan du nå lyttaren og fullføra den nødvendige proxy-forhandlinga? Hald destinasjonsspesifikke observasjonar ved sida av den registreringa i staden for å skriva ho over.
| Observasjon | Område å undersøkja |
|---|---|
| Proxy-lyttaren avviser tilkoplingar | Endepunktet og ruta dit |
| Proxyen avviser éin destinasjonsport | Den tillatne operasjonen for den destinasjonen |
| Ein nettstad returnerer ein kontofeil | Destinasjonsapplikasjonen og påloggingsinformasjonen |
| Store svar stoppar, små blir fullførte | Overføringsarbeidsmengda og tidsavbrotspolicyen |
Eit HTTP-svar kan fastslå at ein førespurnadssti returnerte noko, men framleis vera ubrukeleg for applikasjonen. Hald transportframgang, HTTP-status og venta innhald som separate utfall.
Viss éin destinasjon feilar gjentekne gonger, pausa eller undersøk det endepunkt-og-destinasjon-paret. Å slå av proxyen for kvar urelatert jobb kan kasta bort nyttig kapasitet. Motsett bør ein global tilkoplingfeil ikkje bli skjult bak den isolerte registreringa til éin nettstad.
Ein praktisk helsenøkkel kan omfatta proxy-identifikatoren, destinasjonstenesta og operasjonstypen. Unngå å bruka heile den påloggingsberande URL-en eller kvar unike ressurssti som ein stadig veksande nøkkel. Grupper berre der grupperinga gjev ei meiningsfull spådom om neste førespurnad.
Føremålet er betre rutingsbevis, ikkje ei større samling grøne merke. Eit helseresultat bør seia kva som vart freista, når, og kva det faktisk fastslo.