Когда сервер падает в 3 ночи: мониторинг и администрирование

3 часа ночи. Телефон разрывается — клиенты пишут, что сайт лежит. Вы открываете ноутбук, спросонья пытаетесь сообразить, где смотреть логи, что вообще упало: nginx, php-fpm, база, диск кончился? К утру всё чинится, а через неделю история повторяется. Знакомо?

Главная боль не в том, что сервер упал. Сервер упадёт рано или поздно у всех. Боль в том, что вы узнаёте об этом от клиентов, а не от системы. Это значит, что инфраструктура неуправляема: она работает, пока работает, и молчит, пока не сломается окончательно.

Почему так происходит

Чаще всего сервер настраивали «по-быстрому»: поставили nginx, PHP, базу, прикрутили SSL — и забыли. Ни метрик, ни алертов, ни даже простого uptime-чека снаружи. На бумаге всё работает. По факту любой всплеск нагрузки, утечка памяти или забитый /var/log — и здравствуйте, клиенты в личке.

Что собирать

Базовый набор метрик, без которого нет смысла говорить о мониторинге:

• CPU, RAM, swap, load average — хост в принципе живой?
• Диск — место и I/O. 95% забитого диска кладёт практически всё.
• Сеть — входящий/исходящий трафик, ошибки на интерфейсе.
• Сервисы — nginx, php-fpm, mysql/postgres, redis: процесс жив, отвечает на healthcheck.
• HTTP — uptime снаружи, время ответа главных эндпоинтов, доля 5xx.

Этого мало. Дальше — бизнес-метрики: количество заказов в минуту, длина очереди задач, успешность платежей. Когда CPU зелёный, а заказы упали в ноль — это и есть настоящая авария, и без бизнес-метрик вы её не заметите.

Чем собирать

Два рабочих стека:

• Prometheus + Grafana + Alertmanager — индустриальный стандарт. Гибкий язык запросов (PromQL), огромная экосистема экспортеров (node_exporter, nginx_exporter, mysqld_exporter). Подходит, когда серверов больше двух.
• Zabbix — старая школа, но до сих пор отлично работает. Из коробки умеет всё: автодискавери, шаблоны, алерты, графики. Меньше «лего», больше «всё в одной коробке».

Для одного-двух серверов и команды без выделенного devops Zabbix часто проще. Для микросервисов, k8s, динамической инфры — Prometheus.

Простой пример — ручная проверка занятого места, которую полезно завернуть в алерт:

df -h --output=target,pcent | awk 'NR>1 && int($2)>85 {print}'

Алерты, а не графики

Графики никто не смотрит. Работает только то, что само пишет вам в нужный момент. Минимум — Telegram-бот (Alertmanager → telegram-bridge или встроенный media type в Zabbix). Дальше — escalation: первая попытка в Telegram, через 10 минут не ответили — звонок через Voximplant/Twilio, ещё через 10 — звонок второму дежурному.

Настроить базовые алерты на CPU, диск и uptime — дело часа: это можно сделать самому по любому гайду, могу помочь, если разбираться некогда или если хочется сразу нормально, с шаблонами и escalation. Главное — не спамить. Алерт должен быть либо actionable, либо его не должно быть вовсе. Когда в чате 200 жёлтых сообщений в день, на 201-е красное никто не среагирует.

SLA и дежурство

Если бизнес зависит от сайта — нужен SLA. Не для красоты в договоре, а для того, чтобы заранее договориться: реакция за 15 минут, восстановление за 2 часа, 99.9% доступности в месяц. Из этого вытекает дежурство: либо у вас круглосуточная команда, либо вы на аутсорсе с гарантированным временем реакции.

Полезные практики:

• Runbook на каждый частый алерт: «диск > 90% — сначала почистить /var/log/journal, потом docker system prune».
• Postmortem после каждой серьёзной аварии. Без поиска виноватых — только что сломалось, почему, как не допустить.
• Регулярные учения: раз в квартал намеренно положить тестовый сервис и засечь, за сколько команда среагировала.

Запомнить

• Если о падении вы узнаёте от клиентов — мониторинга у вас нет, есть иллюзия.
• Метрики хоста + сервисы + бизнес-показатели. Без последнего слепая зона.
• Алерты должны приходить туда, где вы их увидите ночью. Telegram + escalation.
• SLA и runbook'и превращают героические подвиги в рутину.

Если ночные звонки от клиентов уже надоели — напишите мне. Подключу мониторинг (Prometheus/Grafana или Zabbix), настрою алерты с escalation и возьму сервера на сопровождение по SLA с реакцией до 30 минут. Через неделю первые алерты уже придут не от клиентов, а от системы.