Мониторинг сервера: четыре проверки, на которые стоит ставить алерты

Алерт, который срабатывает часто и ничего не значит, хуже, чем отсутствие алертов, потому что он приучает вас отмахиваться от всей категории. После третьего ложного срабатывания за неделю вы их уже не читаете, а стираете, и единственный важный попадает в ту же папку, что и шум.

Поэтому цель - никогда не больше мониторинга. Цель - короткий список проверок, которые каждый раз говорят правду, которые вы действительно читаете и по каждой из которых вы знаете, что делать. Для одного сервера этот список - четыре проверки и около шести порогов. В этой статье: что это за четыре проверки, как запускать их снаружи машины, чтобы они ловили важные сбои, какие числа ставить в пороги, куда должен приходить алерт и то единственное правило, которое не даёт списку снова превратиться в обои.

Четыре проверки, которые стоит иметь#

Работает ли процесс - вопрос снаружи машины. Агент на самой машине не сообщит, что машины больше нет. Проверка, запущенная в другом месте, ловит целый класс сбоев, которые локальный агент проспит: контейнер остановился, узел лишился питания, сетевой путь сломался, правило файрвола поменялось под вами. Это единственная проверка, которая ловит полный отказ, и её чаще всего пропускают в конфигурациях с одним сервером, потому что панель и так рисует зелёную точку.

Отвечает ли он. Успешное TCP-соединение - не то же самое, что работающий сервис. На хостинге с панелью порт может удерживаться прокси перед вашим контейнером, пока приложение за ним крутится в цикле падений. На игровом сервере игровой порт может принимать пакеты, пока мир завис и у всех игроков истекает таймаут. Говорите на настоящем протоколе: запросите URL и проверьте код статуса или отправьте query-пакет игры и проверьте, что вернулось число игроков.

Заполняется ли диск. Это сбой с самым длинным предупреждением и наименьшим оправданием. Логи, backup, оставленные на том же томе, мир, растущий каждую неделю, node_modules, который переустанавливают, не очистив прежний, - диск ползёт вверх неделями, а потом всё останавливается разом, обычно самым уродливым образом. База данных, которая не может писать, хуже базы данных, которая лежит, потому что на выходе она может повредиться.

Завершился ли последний backup. Не «запланирована ли задача backup», а появился ли файл правдоподобного размера там, где должен, и тогда, когда должен. Задачи backup падают молча чаще любой другой задачи на сервере, потому что ничто ниже по цепочке от них не зависит - до того дня, когда зависит всё. Более широкий довод изложен в статье бэкапы, которые действительно восстанавливаются; проверка здесь - её дешёвая половина.

Вот и весь список. Всё остальное - графики CPU, графики памяти, tick rate, задержка запросов, число игроков - это диагностика, а не алертинг. Держите графики, смотрите на них в ту секунду, когда сработал алерт, и не поднимайте по ним тревогу. Разница между «мне надо знать сейчас» и «я хочу видеть это, когда смотрю» - вся дисциплина.

Проверка снаружи машины#

Внешняя проверка стоит своих затрат по двум причинам: она говорит на настоящем протоколе и не поднимает тревогу из-за собственных сбоев.

# HTTP: status code and total time, failing loudly on anything but 2xx$ curl -fsS --max-time 5 -o /dev/null \    -w '%{http_code} %{time_total}s\n' https://app.example.com/healthz200 0.184s

# Minecraft: the server list ping, which needs the game to be answering$ mcstatus play.example.com:25565 status# Any TCP port, when you have nothing else installed$ nc -z -w 3 203.0.113.10 25565 && echo open

mcstatus устанавливается из одноимённого пакета Python и печатает строку версии и число игроков. Для игр на движке Source эквивалент - запрос A2S на query-порт, который понимают большинство сервисов мониторинга и каждый сайт со списком серверов. Если ваш монитор предлагает только «проверку TCP-порта», пользуйтесь ей, но знайте, о чём она вам не говорит - в статье порты игровых серверов объяснено, почему query-порт и игровой порт отказывают независимо.

Настройки, от которых зависит, можно ли проверке доверять:

• Интервал 60 секунд для большинства сервисов. Тридцать, если сервис клиентский и вы действительно отреагируете быстрее. Всё, что меньше тридцати секунд, - это нагрузка, а не информация.
• Три подряд неудачи перед алертом. При минутном интервале это три минуты до обнаружения, что нормально, и это убирает почти все ложные тревоги, вызванные сетью самого монитора.
• Таймаут 5-10 секунд, а не 30 по умолчанию. Сервер, отвечающий 25 секунд, для любого, кто им пользуется, лежит.
• Две локации, если сервис их предлагает. Один зонд с плохой минутой не должен считаться сбоем.
• Алертите и о восстановлении. Алерт без парной строки «снова работает» заставляет проверять вручную, а от этой привычки вы и хотели избавиться.

Пороги, которые не выдуманы#

Числа ниже - отправные точки, которые верны для одного сервера на фиксированном тарифе. Поправьте их один раз, понаблюдав за графиками две недели, и оставьте в покое.

Две строки требуют пояснения. Память измеряется относительно лимита вашего тарифа, а не машины, и то, что происходит на лимите, зависит от хостера: здесь контейнер останавливается ядром и запускается заново с чистого листа, а не уходит в swap, поэтому алерт по памяти и алерт по перезапуску часто приходят вместе и означают одно и то же. CPU - жёсткое ограничение до купленной доли, так что 100% означает «медленно», а не «сломано»: это никогда не повод для приостановки и не авария, но сервер, живущий там, нуждается либо в настройке, либо в более крупном тарифе. Как отличить здоровый пик от плоского потолка - в статье как читать график нагрузки сервера, а чего покупать больше - в статье CPU или RAM для игровых серверов.

Проверку backup стоит превратить в скрипт, даже если больше вы ничего не мониторите:

# Alert if no backup larger than 1 MB has landed in the last 26 hours$ find /srv/backups -type f -mmin -1560 -size +1M | grep -q . || \    curl -fsS -H 'Content-Type: application/json' \      -d '{"content":"No backup in the last 26 hours"}' "$DISCORD_WEBHOOK"

Инвертированная версия ещё лучше, и именно её продают облачные сервисы «мониторинга cron»: задача backup вызывает URL, когда успешно завершилась, а монитор поднимает тревогу, когда вызовы перестают приходить. Такой dead man's switch ловит то, что find никогда не поймает: задача вообще не запускалась, потому что сломан сам планировщик.

Читаем графики до алерта#

Алерты говорят, что что-то не так сейчас. Графики показывают, как выглядит норма, а это единственный способ вообще узнать, что что-то не так. Консоль здесь рисует память, CPU и диск относительно лимитов вашего тарифа, а не мощности машины; это правильное сравнение, и в большинстве панелей оно сделано неверно.

Три формы стоит узнавать с первого взгляда:

• Пилообразная память, которая сбрасывается при каждом перезапуске и достигает потолка каждый день чуть раньше. Это утечка, а ночной перезапуск - повязка, а не лечение. Когда повязка - правильное решение, объясняется в статье расписания перезапусков, которые помогают.
• Ступенька, которая начинается в определённый час и уже не возвращается вниз. В это время что-то установили, включили или запланировали. Прежде чем смотреть куда-то ещё, сверьтесь с историей своих деплоев или плагинов.
• Плоский потолок CPU только в часы пик. Это значит, что пределом является тариф, а не код, и никакая настройка не сдвинет его так далеко, как ещё одно ядро.

Смотрите на графики в течение пяти минут после каждого своего изменения, а не по расписанию. Мониторинг, о котором надо помнить, чтобы посмотреть, мониторингом не является.

Куда должен приходить алерт#

Алерт, пришедший туда, где никто не смотрит, - это запись в логе с лишними шагами. Для небольшой команды рабочая схема скучна:

1. Один канал, а не пять. Канал Discord или один адрес почты, который получает только алерты. Если туда ещё приходят уведомления о деплоях, чат и ежедневный дайджест, это уже чат, и вы его заглушите.
2. Темы, которые читаются человеком. «app.example.com отвечал 502 в течение 3 минут» лучше, чем «CHECK_HTTP CRITICAL». Читать это вы будете с телефона.
3. Уведомления о восстановлении в том же месте, чтобы канал закрывался сам и по нему было видно с одного взгляда, сломано ли что-нибудь сейчас.
4. Никакой эскалации, о которой вы не договорились. Будить человека ночью из-за любительского сервера Minecraft - вот так люди перестают держать серверы Minecraft.

Вебхуки - самый дешёвый путь: большинство сервисов доступности отправляют напрямую в вебхук Discord или Slack, а всё, что умеет выполнять команду shell, может послать его через curl. Настройка и формат нагрузки - в статье вебхуки Discord для статуса сервера. Относитесь к URL вебхука как к учётным данным - любой, у кого он есть, может писать от вашего имени - и храните его в переменной окружения, а не в скрипте, как в статье переменные окружения и секреты.

Что панель уже отслеживает#

Часть этого делается за вас, и понимание, какая именно, избавит вас от того, чтобы строить всё дважды.

Наблюдатель каждые две минуты опрашивает сервер, который ушёл в офлайн или у которого время работы пошло назад, - это признак падения и перезапуска. Перезапуски, о которых вы просили, не учитываются. Три незапланированных перезапуска за час выводят предупреждение на странице сервера и автоматически открывают тикет; шесть приостанавливают сервер, чтобы он не изматывал узел и чтобы на него кто-нибудь посмотрел. Так закрывается строка «незапланированные перезапуски» в таблице выше без какой-либо настройки с вашей стороны, а статья почему ваш игровой сервер постоянно перезапускается помогает разобраться с причиной.

Графики консоли покрывают память, CPU и диск относительно ваших лимитов. Вкладка Schedules запускает задачу backup по cron-выражению с упорядоченными задачами и задержками, так что «сделать backup, затем перезапустить» - одно расписание, а не две вещи, которые вы надеетесь увидеть выполненными по порядку; см. /guides#schedules. Страница статуса показывает те же данные о доступности, что видим мы, с выборкой каждые пять минут, а не отдельную маркетинговую версию.

Не делается за вас внешняя проверка и проверка возраста backup. Никто вне вашего аккаунта не знает, что должно возвращать ваше приложение, и никто, кроме вас, не знает, что вчерашний backup должен был весить 4 ГБ, а не 40 КБ.

Логи и проверки, которые их читают#

Пятая проверка, когда вы захотите ещё одну, - проверка лога: поднимать тревогу, когда появляется определённая строка. Она полезна, и она же - то место, где списки алертов умирают, поэтому к ней прилагаются правила.

Алертите по строкам, которые означают конкретную вещь, по которой вы бы действовали. OutOfMemoryError, database is locked, Address already in use, permission denied на директории данных, собственная строка плагина «failed to load». Не алертите по слову ERROR, потому что половина софта в мире пишет исправимые ситуации на уровне error, и вы потратите две недели на настройку фильтра, прежде чем выключите его.

# The last hour of a log, only the lines you decided matter$ grep -nE 'OutOfMemory|Address already in use|Can.t connect to' latest.log | tail -20

Живая консоль показывает вывод без фильтров, а шум веб-сервера свёрнут за счётчик, который можно выключить: это делает её читаемой во время инцидента, а не стеной текста. Правильно читать её - отдельный навык: в статье как читать консоль описано, на что смотреть при запуске, а в статье логи, которые стоит хранить - что сохранять потом и как долго. Главное правило здесь: строка лога - это улика, а не сигнал тревоги. Превращайте её в тревогу лишь тогда, когда она подловила вас дважды.

Правило, которое не даёт списку разрастись#

Если алерт сработал, а делать по нему нечего, он не должен был срабатывать. Либо сделайте его действенным, либо удалите.

Правило легко сформулировать и неприятно применять, потому что удаление алерта похоже на принятие риска. Это не так. Алерт, по которому никто не действует, уже неформально удалён всеми, кто отправляет его в папку. Оформить это официально - единственный способ сохранить смысл остальных.

Применяйте раз в месяц, с тремя вопросами на каждый алерт:

1. Срабатывал ли он в этом месяце? Если никогда не срабатывает, проверьте, что он ещё работает: проверка, нацеленная на имя хоста, которым вы перестали пользоваться, больше никогда не сработает. Проверьте, намеренно что-нибудь сломав.
2. Когда он срабатывал, был ли он прав? Всё, у чего доля ложных срабатываний выше примерно одного из десяти, нуждается в смещении порога или увеличении числа повторов - сегодня, пока вы не научились его игнорировать.
3. Что вы сделали? Если ответ «посмотрел и ничего не сделал», алерт - это график. Перенесите его на дашборд.

Четыре проверки, которые вы читаете, стоят больше сорока, которые вы отфильтровываете. Тот же принцип решает, что ещё заслуживает места на сервере: задачи по расписанию, которые стоит иметь применяют его к заданиям cron, а проверка восстановления до того, как оно понадобится - к единственной задаче, чей результат вы всё равно должны проверять руками, потому что backup, который никто не восстанавливал, - это гипотеза.

FAQ#

Как часто должна выполняться проверка доступности?

Каждые 60 секунд для большинства сервисов, с тремя подряд неудачами перед алертом. Это даёт примерно три минуты до обнаружения и убирает почти все ложные тревоги из-за сети самого монитора. Снижение до 30 секунд разумно для клиентского сервиса, где вы действительно отреагируете быстрее; ниже вы порождаете нагрузку, а не информацию.

Что на самом деле должен проверять health endpoint?

Два. Быстрый, возвращающий 200 без какой-либо работы, доказывает, что процесс запущен и слушает, и проверяется каждую минуту. Более медленный, обращающийся к базе данных или очереди и возвращающий 503, когда зависимость сломана, проверяется раз в пять минут. Если их разделить, ваш монитор не нагружает базу, а по сбою видно, какой слой виноват.

Нужны ли Prometheus и Grafana для одного сервера?

Нет. Для одного сервера графики самой панели плюс одна внешняя проверка доступности покрывают то же самое без обслуживания, а стек метрик на той же машине конкурирует за память, которую вы хотели наблюдать. Prometheus окупается, когда серверов несколько, нужна история дольше той, что хранит панель, или правила алертов, написанные по данным, а не по коду статуса.

Почему монитор сообщил, что сервер лежит, хотя всё было в порядке?

Обычно виновата сама проверка: слишком маленький таймаут, единственный зонд с плохим маршрутом или алерт, настроенный на срабатывание после первой неудачи, а не третьей. Проверьте, виден ли сбой из второй локации и совпадает ли он с чем-то в ваших собственных логах. Если в логах ничего не шевельнулось, подозревайте сеть между монитором и сервером, а не сервер.

Стоит ли алертить по высокому CPU?

Не по всплескам. CPU на тарифе с фиксированной долей - жёсткое ограничение, поэтому упор в 100% делает сервер медленным, а не сломанным, а короткие пики во время сохранения мира или перезапуска нормальны. Алертите только на потолок, удерживаемый пятнадцать минут и дольше, и воспринимайте это как «посмотрите сегодня», а не как аварию.

Как узнать, что backup действительно сработал?

Проверяйте появление нового файла правдоподобного размера, а не задачу, отрапортовавшую об успехе. Возраст и размер вместе ловят два типичных сбоя: задачу, которая не запустилась, и задачу, которая отработала над пустой директорией и записала архив в 40 КБ. Раз в квартал восстановите один куда-нибудь безвредно и откройте. Это единственная проверка, доказывающая, что backup - это backup.