Як тлумачити стан і коди виходу проксі-монітора
Повідомляйте про виконання команди, результат 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. Передайте його секрет належним механізмом розгортання і повідомте саме той етап, що зазнав невдачі: відмовлений тунель потребує іншого виправлення, ніж неочікуваний стан сайту.