Как 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

• Подтверждение сбоев
• Мониторинг сайта
• Управление инцидентами
• Все материалы блога
• Тарифы