Стратегії повторної перевірки: як підтвердити новий статус
Повторна перевірка - це друга думка, яку система моніторингу запитує, перш ніж повірити у зміну статусу: вона повторює невдалу чи щойно успішну перевірку з інших локацій, щоб одна невдала точка спостереження не могла сама по собі відкрити інцидент. HostTracker перевіряє сайт за розкладом, заданим у налаштуваннях моніторингу, і щойно виявлений статус UP чи DOWN вважається кандидатом, доки повторна перевірка його не підтвердить.
Чому одна невдала перевірка - ще не збій
Результат перевірки описує один запит, з одного місця, в один момент. Будь-яка з цих трьох складових може помилятися щодо сайту загалом. Мережа між однією контрольною точкою і вашим сервером може бути пошкоджена, тоді як усі інші маршрути в порядку. DNS-запис може ще поширюватися в одному регіоні й уже бути коректним у наступному. Середовище контрольної точки саме по собі може бути несумісним із чимось, що робить ваш сервер.
Якби система моніторингу діяла за кожним першим результатом, вона сповіщала б вас про всі ці випадки, а також псувала б вашу статистику аптайму, бо зафіксований простій насправді не траплявся для ваших користувачів. Тому виявлений статус, UP чи DOWN, тримається як неперевірений, доки його не підтверджено, і лише тоді відбувається щось наступне: іде сповіщення, відкривається епізод, змінюється число аптайму.
Що виявляє повторна перевірка
Саме повторна перевірка з інших локацій відрізняє справжню, загальносайтову зміну від локального артефакту. Найчастіше вона відсіює такі випадки:
- Короткий простій під час нового деплою, коли сайт повертається ще до того, як пройде друга перевірка
- Недоступність DNS, поки поширюється зміна конфігурації, тож одні резолвери відповідають, а інші ні
- Локальне внесення до чорного списку сайту чи адреси контрольної точки, видиме лише з однієї мережі
- Перевірочний агент, чиє середовище несумісне з технологіями, які використовує сервер
- Проблеми з маршрутизацією чи піринг на шляху між однією контрольною точкою і сервером
Підтверджувальні перевірки беруться з геозони, налаштованої для моніторингового завдання, тож друга думка надходить з тієї самої частини світу, де перебувають ваші користувачі, а не звідки завгодно, аби вільно.
Три стратегії повторної перевірки
HostTracker підтримує три способи вирішити, чи новий статус реальний.
1. Голосування більшості. Коли перевірка повертає новий статус, система виділяє до 7 нових локацій із геозони моніторингового завдання, щоб його підтвердити. Отримані результати групуються за статусом, і перемагає більша група. Припустімо, перевірка з Маямі повідомляє DOWN, а повторні перевірки з Нью-Йорка, Бостона і Чикаго повертають UP, DOWN, UP. DOWN лишається непідтвердженим і відкидається, а Маямі отримує штраф: його більше не використовуватимуть для перевірок цього сайту. Проженіть той самий приклад у зворотний бік, коли Маямі повідомляє UP після DOWN, а Нью-Йорк і Чикаго підтверджують UP, і перехід DOWN-UP реєструється.
2. Задана кількість локацій, що підтверджують DOWN. Тут ви налаштовуєте мінімальну кількість повторних перевірок, потрібну для підтвердження DOWN, тоді як для UP усе одно потрібна більшість голосів. Якщо це число встановлено на 1, у тому самому прикладі самого Бостона, який повертає DOWN, досить, щоб підтвердити DOWN Маямі, навіть якщо Нью-Йорк і Чикаго не погодилися.
3. Без повторної перевірки. Новий статус завжди підтверджується одразу, щойно виявлений. Це передбачає повну довіру до сервера і до середовищ моніторингових локацій. Такий варіант підходить для кількох специфічних потреб моніторингу, і обирати його слід обережно, бо кожна тимчасова мережева проблема на одній контрольній точці стає хибним сповіщенням і псує показник аптайму.
Як обрати стратегію
- Почніть із голосування більшості. Це збалансований варіант за замовчуванням: він коштує кількох секунд додаткового часу на підтвердження і прибирає майже весь шум від однієї контрольної точки.
- Знизьте поріг підтвердження DOWN, коли швидке сповіщення важливіше за тиху поштову скриньку. Регіональний збій, який бачать лише дві локації, все одно дійде до вас - ціною більшої кількості хибних спрацювань.
- Тримайте голосування більшості для переходів UP, хоч би як ви налаштували DOWN. Передчасний UP закриває інцидент, який ще триває, і приховує хвіст збою з вашої статистики.
- Залиште режим без повторної перевірки для цілей, які ви контролюєте повністю, де ви радше самі розберетеся з хибним сповіщенням, ніж чекатимете на підтвердження.
Хоч би яку стратегію ви обрали, розбіжність можна відтворити самостійно з двох різних мереж і порівняти, що бачить кожна з них:
curl -sS -o /dev/null -w '%{http_code} %{time_total}s\n' https://example.com/503 з однієї мережі та 200 з іншої - саме та розбіжність, яку і покликана вирішувати повторна перевірка. Якщо невдалий статус - це 5xx, а не тайм-аут, сервер відповів, а це вже інша проблема: див. 503 Service Unavailable.
Що дає підтвердження
Повторні перевірки - це те, що дозволяє системі моніторингу виконувати часті перевірки з багатьох місць, не перетворюючи цю чутливість на шум. HostTracker перевіряє з понад 300 контрольних точок у 158 містах, тож незалежні локації для другої думки завжди є, і лише підтверджений перехід запускає сповіщення електронною поштою, SMS, голосовим дзвінком, у Slack, Telegram та інших каналах. Наведені вище стратегії - не весь можливий набір, і підтримка може розглянути нову для майбутнього релізу, якщо вашому моніторингу потрібне те, що жодна з них не покриває. Дивіться розподілений моніторинг доступності про те, як використовується мережа контрольних точок, і решту розділу про поняття моніторингу про терміни, що стоять за цим.