Здоров'я проксі: який сайт і яку операцію ви перевірили?
Відокремлюйте загальну доступність проксі від збоїв, специфічних для призначення, коли підтримуєте пул проксі для повторного використання.
Проксі завантажує вашу сторінку перевірки IP, але зазнає невдачі на API, який потрібен вашій програмі. Називати його «здоровим» або «мертвим» — означає втрачати найкорисніший факт: два запити були різними.
Почніть із запису на рівні транспорту для кінцевої точки. Чи можете ви дістатися до її слухача й завершити потрібне узгодження проксі? Тримайте спостереження, специфічні для призначення, поруч із цим записом, а не перезаписуйте його.
| Спостереження | Обсяг для дослідження |
|---|---|
| Слухач проксі відхиляє з'єднання | Кінцева точка та шлях до неї |
| Проксі відхиляє один порт призначення | Дозволена операція для цього призначення |
| Один сайт повертає помилку облікового запису | Програма призначення та облікові дані |
| Великі відповіді застрягають, малі завершуються | Обсяг передавання та політика тайм-ауту |
HTTP-відповідь може підтвердити, що шлях запиту щось повернув, і все ж залишатися непридатним для програми. Тримайте успіх транспорту, статус HTTP і очікуваний вміст як окремі результати.
Якщо одне призначення збоїть багаторазово, призупиніть або дослідіть цю пару «кінцева точка — призначення». Вимкнення проксі для кожного не пов'язаного завдання може викинути корисну ємність. І навпаки, глобальний збій з'єднання не повинен залишатися прихованим за ізольованим записом одного сайту.
Практичний ключ здоров'я може включати ідентифікатор проксі, службу призначення та тип операції. Уникайте використання повної URL-адреси з обліковими даними або кожного унікального шляху ресурсу як постійно зростаючого ключа. Групуйте лише там, де групування дає значущий прогноз щодо наступного запиту.
Мета — кращі докази маршрутизації, а не більша колекція зелених значків. Результат здоров'я має казати, що було спробовано, коли і що він насправді встановив.