Proxy-hälsa: vilken webbplats och vilken operation testade du?
Separera allmän proxy-åtkomst från destinationsspecifika fel när du underhåller en återanvändbar proxy-pool.
En proxy hämtar din IP-kontrollsida och misslyckas på det API som din applikation behöver. Att kalla den “frisk” eller “död” förlorar det mest användbara faktumet: de två förfrågningarna var olika.
Börja med en transportövergripande post för slutpunkten. Kan du nå dess lyssnare och slutföra den nödvändiga proxy-förhandlingen? Håll destinationsspecifika observationer bredvid den posten i stället för att skriva över den.
| Observation | Omfång att undersöka |
|---|---|
| Proxy-lyssnaren avvisar anslutningar | Slutpunkten och vägen dit |
| Proxyn nekar en destinationsport | Den tillåtna operationen för den destinationen |
| En webbplats returnerar ett kontofel | Destinationsapplikationen och inloggningsuppgifterna |
| Stora svar fastnar, små slutförs | Överföringsbelastningen och tidsgränspolicyn |
Ett HTTP-svar kan fastställa att en förfrågningsväg returnerade något men ändå vara oanvändbart för applikationen. Håll transportframgång, HTTP-status och förväntat innehåll som separata utfall.
Om en destination misslyckas upprepade gånger, pausa eller undersök det slutpunkts- och destinationsparet. Att inaktivera proxyn för varje orelaterat jobb kan slänga bort användbar kapacitet. Omvänt bör ett globalt anslutningsfel inte förbli dolt bakom en enda webbplats isolerade post.
En praktisk hälsonyckel kan omfatta proxy-identifieraren, destinationstjänsten och operationstypen. Undvik att använda hela den inloggningsuppgiftsbärande URL:en eller varje unik resurssökväg som en ständigt växande nyckel. Gruppera bara där grupperingen ger en meningsfull förutsägelse om nästa förfrågan.
Syftet är bättre routingbevis, inte en större samling gröna märken. Ett hälsoresultat bör säga vad som försöktes, när och vad det faktiskt fastställde.