Как читать статус и коды выхода прокси-монитора
Сообщайте о выполнении команды, результате HTTP и проверке сертификата по отдельности при проверке сайта через прокси.
Обёртка не может превратить нулевой код выхода загрузчика в наблюдённый «HTTP 200 OK». Фиксируйте, что на самом деле сообщил каждый уровень:
| Поле | Отвечаемый вопрос |
|---|---|
| Выход инструмента или плагина | Выполнилась ли проверка и какой класс отказа она сообщила? |
| Согласование с прокси | Разрешена ли передача или запрошенный туннель? |
| Статус источника и ожидаемое содержимое | Вернуло ли приложение нужный результат? |
| Проверка TLS | Успешны ли настроенные проверки подлинности? |
curl обычно может вернуть ноль и после ответа с ошибкой HTTP. Его параметры fail меняют поведение при выходе, но выход с ошибкой всё равно не определяет статус однозначно. Значения выхода Wget тоже категории: сбой аутентификации — не отдельное значение для HTTP 401, а категория ошибки сервера не определяет каждый ответ внутри неё. Проверка, ожидающая 401, должна наблюдать этот ответ.
Держите конечную точку прокси и имя сайта раздельно. TCP-партнёр проверки через HTTP-прокси — это прокси; CONNECT называет назначение, чья сессия TLS затем идёт внутри туннеля. Для HTTPS-прокси доверие к внешнему прокси — ещё одна проверка сертификата.
Изучите гарантию плагина, прежде чем считать флаг SSL проверкой. Monitoring Plugins выводит check_http из употребления в пользу check_curl. Документация check_http предупреждает, что выбор только SSL не проверяет ни имя хоста, ни доверие к издателю; документированный параметр verify-peer в check_curl включает эту проверку.
Используйте и предусмотренный аутентифицированный маршрут. Проверка порта может оставаться зелёной, пока рабочая учётная запись получает 407. Передайте секрет надлежащим механизмом развёртывания и сообщите именно тот этап, который отказал: отказ в туннеле требует иного исправления, чем неожиданный статус сайта.