Un proxy recupera la tua pagina di controllo IP e fallisce sull'API che serve alla tua applicazione. Chiamarlo «sano» o «morto» perde il dato più utile: le due richieste erano diverse.

Inizia con un registro a livello di trasporto per l'endpoint. Riesci a raggiungere il suo listener e a completare la necessaria negoziazione del proxy? Tieni le osservazioni specifiche della destinazione accanto a quel registro invece di sovrascriverlo.

OsservazioneAmbito da indagare
Il listener del proxy rifiuta le connessioniL'endpoint e il percorso verso di esso
Il proxy nega una porta di destinazioneL'operazione consentita per quella destinazione
Un sito web restituisce un errore dell'accountL'applicazione di destinazione e le credenziali
Le risposte grandi si bloccano, le piccole terminanoIl carico di trasferimento e la politica di timeout

Una risposta HTTP può stabilire che un percorso di richiesta ha restituito qualcosa pur restando inutilizzabile per l'applicazione. Tieni il successo del trasporto, lo stato HTTP e il contenuto atteso come esiti separati.

Se una destinazione fallisce ripetutamente, sospendi o indaga quella coppia endpoint-destinazione. Disattivare il proxy per ogni attività non correlata può sprecare capacità utile. Al contrario, un guasto di connessione globale non dovrebbe restare nascosto dietro il registro isolato di un solo sito web.

Una chiave di salute pratica può includere l'identificatore del proxy, il servizio di destinazione e il tipo di operazione. Evita di usare l'intero URL che porta credenziali o ogni percorso di risorsa univoco come chiave che cresce senza sosta. Raggruppa solo dove il raggruppamento fornisce una previsione significativa sulla richiesta successiva.

Lo scopo sono prove di instradamento migliori, non una raccolta più grande di distintivi verdi. Un risultato di salute dovrebbe dire cosa è stato tentato, quando e cosa ha effettivamente stabilito.

Articoli correlati