Аптайм
Раздел «Аптайм» следит за доступностью внешних адресов и сервисов через периодические проверки — мониторы. Открывается по значку с активностью в левой рельсе или через /projects/{id}/monitors.
Кто выполняет проверки
Проверки ставит в очередь планировщик аптайма — он поднимается в режимах --mode=web, --mode=uptime и --mode=all (в --mode=ingest его нет; см. «Режимы процесса»), а выполняет их либо встроенный исполнитель (только --mode=uptime и --mode=all), либо выносная проба в другом регионе.
Если инстанс развёрнут раздельно и ни одной из этих ролей нет — например только --mode=web и --mode=ingest, — мониторы будут показаны включёнными, но никто их не проверит. При старте такой процесс пишет об этом в лог: uptime checks are scheduled here but NOT executed in this mode.
Создание монитора
Список мониторов — /projects/{id}/monitors. Кнопка «Новый монитор» (видна участнику команды проекта — оператору, — а также owner/админу организации; см. Роли и права) открывает форму /projects/{id}/monitors/new.
В форме сначала выбирается тип проверки вкладками — HTTP, TCP, DNS или Heartbeat. У каждого типа свой набор полей:
| Тип | Что проверяет | Поля |
|---|---|---|
| HTTP | HTTP(S)-запрос к URL; успех — код ответа и, опционально, содержимое тела | Метод (GET/POST/HEAD), URL, Заголовки, Тело запроса, Ожидаемые коды ответа (через запятую; пусто = любой 200–299), Тело содержит / Тело НЕ содержит, Следовать редиректам, SSL alert (за сколько дней до истечения сертификата предупреждать) |
| TCP | Устанавливается ли TCP-соединение с хостом и портом | Хост, Порт (1–65535) |
| DNS | Резолвится ли имя и совпадает ли значение с ожидаемым | Имя хоста, Тип записи (A/AAAA/CNAME/MX/TXT), Ожидаемое значение (опционально) |
| Heartbeat | Обратная проверка: не сам Gotcha ходит наружу, а ваше приложение периодически «стучится» по специальному URL. Если стука не было дольше окна ожидания — монитор считается упавшим | Окно ожидания (не меньше 60 секунд) |
При редактировании существующего монитора тип уже зафиксирован — сменить тип нельзя, только его настройки.
Для Heartbeat-монитора персональный URL пинга вида {base_url}/uptime/hb/{token} и готовый пример cron-строки с curl показываются один раз — сразу после создания или регенерации монитора. Токен хранится хешированным и повторно не показывается, поэтому скопируйте его тогда же; если потеряли — на странице монитора есть кнопка Перевыпустить токен для нового URL. Обычный заход на страницу показывает подсказку «перегенерируйте, чтобы получить новый URL», а не сам токен:
*/5 * * * * curl -fsS -X POST https://gotcha.example.com/uptime/hb/6e1f...af92 >/dev/null
Добавьте такую команду в cron/systemd-таймер своего приложения — каждый успешный вызов сбрасывает таймер ожидания. GET тоже поддерживается и продолжит работать — но рекомендуется именно POST: ссылка на пинг регулярно дёргается не только вашим cron’ом (пересланная в чат, она разворачивается ботом предпросмотра ссылок мессенджера или проверяется антивирусным прокси), а такие автоматические заходы всегда идут через GET и явно опознаются заголовками/User-Agent — подобный запрос отклоняется с 204 и не засчитывается как «сервис жив».
Токен в URL — единственный секрет пинга. Эндпойнт /uptime/hb/{token} намеренно без аутентификации и без проверки источника: это не браузерная форма, а вызов извне (cron, systemd-таймер), и ничем, кроме самого адреса, он защищён быть не может. Значит, сигнал «сервис жив» шлёт любой, кто знает URL, — а адрес оседает в журналах доступа вашего прокси, в истории браузера, в выводе crontab -l и в пересланных сообщениях. Обращайтесь с ним как с паролем: не публикуйте, не вставляйте в тикеты и чаты. Ротация — только через «Перевыпустить токен» на странице монитора (действие оператора проекта): старый URL перестаёт работать сразу, новый показывается один раз. Неизвестный токен получает 404, эндпойнт ограничен по частоте как публичный. GET поддерживается сознательно — чтобы сигнал можно было слать из cron простым curl/wget без флагов, — но рекомендация выше про POST остаётся в силе.
Общие настройки: интервал, таймаут, пороги
- Интервал проверки — как часто выполняется проверка, секунды (минимум 30).
- Таймаут — сколько ждать ответа, секунды (1–120, обязательно меньше interval).
- Повторы при сбое — сколько раз повторить одну провалившуюся проверку, прежде чем засчитать её как неуспех (0–10). Гасит кратковременный сбой (потерянный пакет, короткий сбой TLS), чтобы он не переводил монитор в down и не открывал инцидент.
- Порог отказа — сколько проверок подряд должны провалиться, чтобы монитор перешёл в down и открылся инцидент.
- Порог восстановления — сколько успешных проверок подряд нужно, чтобы монитор вернулся в up и инцидент закрылся.
- Повторное уведомление каждые — как часто повторять уведомление по всё ещё открытому инциденту (0 — не напоминать).
Пороги считаются независимо по каждому региону — итоговый статус монитора определяется консенсусом (ниже).
Регионы и консенсус
Монитор можно проверять из нескольких регионов — встроенного локального (запущенного вместе с сервером) и любых удалённых проб, которые организация зарегистрировала. Список доступных регионов и чекбоксы выбора — в той же форме монитора.
Когда регионов больше одного, итоговый статус монитора вычисляется правилом консенсуса:
| Consensus | Правило | Когда использовать |
|---|---|---|
| «Любой регион» | Монитор down, если упал хотя бы один регион | Строгий режим: любая точка недоступности — уже проблема |
| «Большинство регионов» | Монитор down, если down половина или больше определившихся регионов | Компромисс: терпит одиночный региональный сбой |
| «Все регионы» | Монитор down, только если упали все регионы | Терпимый режим: тревога только при полном отказе |
Важно про «Большинство регионов» при чётном числе регионов: если ровно половина регионов down (например, 2 из 4), это тоже засчитывается как down, а не up — намеренный fail-safe, чтобы не оставлять монитор «зелёным», когда половина флота репортит недоступность.
Регион считается «определившимся», только когда он набрал свой fail- или recovery-threshold; до этого он не участвует в подсчёте консенсуса.
Инциденты
Когда согласованный по регионам статус монитора переходит в down, открывается инцидент: фиксируются время начала, причина (текст последней ошибки), список упавших регионов. Пока хотя бы часть регионов остаётся down, инцидент открыт; когда консенсус возвращается в up — инцидент закрывается с зафиксированной длительностью.
Инцидент, открывшийся во время активного окна обслуживания, помечается как «в обслуживании» и не порождает уведомление — так плановые работы не создают ложный шум. Обычные инциденты уведомляют через каналы, привязанные к монитору (см. Оповещения).
Список инцидентов монитора — раздел «Инциденты» на странице /projects/{id}/incidents, а также таймлайн внизу страницы конкретного монитора. Список постранично: при большом числе инцидентов внизу появляется навигация «Назад / N из M / Далее». (Таблица последних проверок на странице монитора не постранична — показывает последние 50 проверок в прокручиваемом блоке.)
Страница монитора
Клик по имени монитора в списке открывает /monitors/{id}: текущий статус, uptime% за 24 часа/7 дней/30 дней, график задержек, таблица последних проверок по регионам, таймлайн инцидентов и — для HTTPS-мониторов — срок действия SSL-сертификата. Оператору проекта (участнику команды), админу и владельцу здесь же доступны Pause/Resume, Edit и Delete монитора.
Что дальше
- Пробы — как поднять проверку из другого региона.
- Публичные статус-страницы — витрина состояния для пользователей.
- Окна обслуживания — подавление шума на время плановых работ.
- Оповещения — куда и как приходят уведомления об инцидентах.