Jak czytać status i kody wyjścia monitora proxy
Raportuj wykonanie polecenia, wynik HTTP i walidację certyfikatu osobno w kontroli witryny przez proxy.
Nakładka nie może zamienić zerowego kodu wyjścia pobierającego w zaobserwowane „HTTP 200 OK”. Zapisz, co naprawdę zgłosiła każda warstwa:
| Pole | Odpowiadane pytanie |
|---|---|
| Wyjście narzędzia lub wtyczki | Czy kontrola została wykonana i jaką klasę błędu zgłosiła? |
| Negocjacja z proxy | Czy przekazywanie lub żądany tunel zostały dopuszczone? |
| Status źródła i oczekiwana treść | Czy aplikacja zwróciła zamierzony wynik? |
| Walidacja TLS | Czy skonfigurowane kontrole tożsamości się powiodły? |
curl zwykle może zwrócić zero także po odpowiedzi z błędem HTTP. Jego opcje fail zmieniają zachowanie wyjścia, ale wyjście błędu nadal nie identyfikuje statusu jednoznacznie. Także wartości wyjścia Wget są kategoriami: błąd uwierzytelniania nie jest osobną wartością dla HTTP 401, a kategoria błędu serwera nie identyfikuje każdej odpowiedzi w niej. Kontrola oczekująca 401 musi zaobserwować tę odpowiedź.
Trzymaj punkt końcowy proxy i nazwę witryny osobno. Drugą stroną TCP kontroli przez proxy HTTP jest proxy; CONNECT nazywa cel, którego sesja TLS działa potem wewnątrz tunelu. W przypadku proxy HTTPS zaufanie do zewnętrznego proxy jest kolejną kontrolą certyfikatu.
Sprawdź gwarancję wtyczki, zanim uznasz flagę SSL za weryfikację. Monitoring Plugins wycofuje check_http na rzecz check_curl. Dokumentacja check_http ostrzega, że wybór samego SSL nie weryfikuje nazwy hosta ani zaufania do wystawcy; udokumentowana opcja verify-peer w check_curl obejmuje tę weryfikację.
Użyj także zamierzonej trasy uwierzytelnionej. Sonda portu może pozostać zielona, gdy konto operacyjne otrzymuje 407. Przekaż jej sekret właściwym mechanizmem wdrożenia i zgłoś etap, który naprawdę zawiódł: odrzucony tunel wymaga innej naprawy niż nieoczekiwany status witryny.