Як Tenium підтверджує збій із кількох регіонів

Найгірше, що може зробити інструмент моніторингу, — збрехати вам о третій ночі. Після другого хибного сповіщення ви починаєте ігнорувати сповіщення, і справжній збій проходить повз. Тому головне рішення в архітектурі чекера Tenium просте: один регіон не може відкрити інцидент. Це може зробити лише кворум незалежних регіонів. Зараз кворум — це 2 з наших 2 діючих регіонів.

У цій статті розповідаємо, як це працює, скільки часу додається до затримки сповіщення і що ви отримуєте в записі про інцидент, коли ми все-таки вас турбуємо.

Як усе влаштовано

У кожному регіоні Tenium запускає один процес чекера. Діють регіони (2): Амстердам та Лондон. Кожен процес — це звичайний воркер Node, який працює з однією й тією самою базою даних Postgres. Черги повідомлень і Redis немає: координує роботу сама база даних.

У кожного монітора є інтервал (30 секунд на тарифі Pro) і набір регіонів. Планувальник у кожному регіоні забирає монітори, яким настав час перевірки, одним запитом:

UPDATE monitors SET next_check_at = now() + interval
WHERE id IN (
  SELECT id FROM monitors
  WHERE next_check_at <= now() AND region = $1
  ORDER BY next_check_at
  LIMIT 50
  FOR UPDATE SKIP LOCKED
) RETURNING *;

FOR UPDATE SKIP LOCKED означає, що кілька процесів можуть виконувати цей запит одночасно й ніколи не візьмуть той самий рядок. Це нудно, і це жодного разу нас не підвело.

Звичайна перевірка

Перевірка — це HTTP-запит із таймаутом 10 секунд, фіксованим заголовком User-Agent: Tenium-Monitor/1.0, усіма власними заголовками, які ви налаштували, і заміром часу на кожному етапі: DNS, TCP-з’єднання, TLS-рукостискання, час до першого байта, завантаження. Ми зберігаємо код відповіді, розмір відповіді, визначену IP-адресу, термін дії сертифіката для https і перші 2 КБ тіла відповіді, якщо перевірка не пройшла.

Результат потрапляє в таблицю checks із кодом регіону. Саме звідси беруться відсотки аптайму та графіки часу відповіді.

Коли перевірка не проходить

Припустімо, Франкфурт отримав 503 від shop.clienta.com. Ось що відбувається, по порядку:

1. Збій записується як результат перевірки, але інцидент не відкривається, і ніхто не отримує сповіщення. Стан монітора в цьому регіоні стає «підозра».
2. Інші регіони одразу просять перевірити. Планувальник додає рядки в таблицю confirmations, по одному на кожен регіон, якого просять, вибраних серед регіонів, які працюють. Ці регіони забирають рядки протягом секунди, бо підтвердження обробляються раніше за заплановані перевірки.
3. Обидва виконують точнісінько той самий запит: ті самі заголовки, той самий таймаут.
4. Якщо кворум погоджується, що сайт не працює, монітор переходить у стан down, відкривається інцидент і розсилаються сповіщення. Кворум — це три регіони, або менше, якщо монітору доступно менше. Тобто початковий збій плюс підтвердження. Правило однакове за будь-якої кількості регіонів, тож більша мережа розширює докази, не змінюючи логіки.
5. Якщо підтвердження успішні, монітор лишається up, початковий збій зберігається в історії як локальний збій у регіоні, а на графіку ви бачите маленьку сіру позначку замість червоної.

Уся послідовність займає 5–15 секунд понад початкову перевірку. Така ціна того, щоб не брехати вам.

Кілька слів чесно про цей підхід. За кворуму з трьох підтвердження суворе: збій, який бачить менше регіонів, ніж потрібно для кворуму, інцидент не відкриває, хоча такі збої залишаються в історії. Ми вважаємо це правильним варіантом за замовчуванням, щоб уникати хибних сповіщень, і саме тому розширюємо мережу, а не послаблюємо правило.

Що вважається збоєм

Перевірка не проходить, якщо виконується будь-що з цього:

• З’єднання відхилено, помилка DNS або таймаут
• Код відповіді поза очікуваним набором (за замовчуванням 2xx і 3xx)
• Немає ключового слова (або воно є, якщо задано «не повинна містити»)
• Не виконується перевірка JSON
• Не вдалося TLS-рукостискання, або сертифікат прострочений чи не відповідає імені хоста

Повільна відповідь не є збоєм. Сповіщення про час відповіді — це окреме правило на основі p95 останніх десяти перевірок, тож один повільний запит з одного регіону нічого не запускає.

Запис про інцидент

Коли ми все-таки сповіщаємо вас, повідомлення та сторінка інциденту містять:

• Які регіони підтвердили збій, із помилкою й часом кожного
• HTTP-код і перші рядки тіла відповіді, щоб «503 від Cloudflare» і «503 від nginx» виглядали по-різному
• IP-адресу, на яку вказало ім’я хоста в кожному регіоні, що одразу виявляє проблеми з DNS
• Термін дії сертифіката, якщо це доречно
• Посилання для підтвердження отримання, яке зупиняє ескалацію

Відновлення підтверджується так само: монітор має успішно пройти перевірку з кворуму регіонів, перш ніж ми закриємо інцидент і надішлемо повідомлення «знову працює, простій 2 хв 10 с». Тому сайт, що «блимає», породжує один інцидент, а не двадцять.

Компроміси

Підтвердження додає до сповіщення до 15 секунд. Для сайтів ми вважаємо це правильним: затримка в 15 секунд ще нікому не коштувала клієнта, а хибне сповіщення о третій ночі коштувало.

Підтвердження також означає, що регіональні збої повідомляються як регіональні. Якщо ваш сайт недоступний лише з Нью-Йорка через проблему з пірингом, ви побачите це на графіку, а сторінка статусу може показати деградацію для цього регіону, але збоєм ми це не назвемо, доки інші регіони не погодяться. Якщо вам потрібне регіональне сповіщення, можна налаштувати монітор на один регіон, і він сповіщатиме лише за цим регіоном, з чітким позначенням компромісу.

Чому не повторити перевірку з того самого регіону?

Бо повторна перевірка з того самого місця проходить тим самим маршрутом, через той самий кеш резолвера й той самий піринг. Більшість хибних сповіщень виникає саме через них. Другий регіон — це справді незалежний спостерігач.

Вихідні IP-адреси кожного діючого регіону наведено на сторінці /checker-ips разом із JSON-фідом, щоб ви могли додати їх до білих списків (allow-list) у файрволах і WAF. Якщо ви користуєтеся Cloudflare, прочитайте посібник про білий список у WAF.

Читайте також

Опис для користувачів є в розділі регіони та підтвердження. Щоб побачити, де підтвердження важить найбільше, прочитайте про перевірки з кількох локацій, моніторинг сайту та моніторинг API або запустіть інструмент «Чи працює сайт» на власному сайті. Якщо ви вибираєте постачальника за цим критерієм, подивіться, як порівнюються UptimeRobot і Better Stack.

Читайте також

Пов’язані сторінки Tenium

• Підтвердження збоїв
• Моніторинг сайту
• Керування інцидентами
• Усі матеріали блогу
• Тарифи