Kondycja proxy: którą witrynę i którą operację testowałeś?
Oddziel ogólną osiągalność proxy od awarii specyficznych dla miejsca docelowego, utrzymując wielokrotnego użytku pulę proxy.
Proxy pobiera Twoją stronę sprawdzania IP i zawodzi na API, którego potrzebuje Twoja aplikacja. Nazywanie go „zdrowym” lub „martwym” gubi najważniejszy fakt: oba żądania były różne.
Zacznij od rekordu obejmującego cały transport dla punktu końcowego. Czy możesz dotrzeć do jego nasłuchu i zakończyć wymaganą negocjację proxy? Trzymaj obserwacje specyficzne dla miejsca docelowego obok tego rekordu, zamiast go nadpisywać.
| Obserwacja | Zakres do zbadania |
|---|---|
| Nasłuch proxy odrzuca połączenia | Punkt końcowy i trasa do niego |
| Proxy odmawia jednego portu docelowego | Dozwolona operacja dla tego miejsca docelowego |
| Jedna witryna zwraca błąd konta | Aplikacja docelowa i poświadczenia |
| Duże odpowiedzi się zacinają, małe kończą | Obciążenie transferu i polityka limitu czasu |
Odpowiedź HTTP może dowieść, że ścieżka żądania coś zwróciła, a mimo to być bezużyteczna dla aplikacji. Trzymaj sukces transportu, status HTTP i oczekiwaną treść jako osobne wyniki.
Jeśli jedno miejsce docelowe zawodzi wielokrotnie, wstrzymaj lub zbadaj tę parę punktu końcowego i miejsca docelowego. Wyłączanie proxy dla każdego niepowiązanego zadania może marnować użyteczną pojemność. I odwrotnie, globalna awaria połączenia nie powinna pozostawać ukryta za odizolowanym rekordem jednej witryny.
Praktyczny klucz kondycji może obejmować identyfikator proxy, usługę docelową i typ operacji. Unikaj używania całego adresu URL zawierającego poświadczenia lub każdej unikalnej ścieżki zasobu jako stale rosnącego klucza. Grupuj tylko tam, gdzie grupowanie daje sensowną prognozę następnego żądania.
Celem są lepsze dowody routingu, a nie większa kolekcja zielonych odznak. Wynik kondycji powinien mówić, co zostało wypróbowane, kiedy i co faktycznie ustalił.