Сервер упал в пятницу вечером. Сайт лежит, клиенты пишут в поддержку, телефон не замолкает. Ты узнаёшь об этом через два часа — от злого директора. Знакомая картина? Мониторинг — это то, что позволяет узнать о проблеме раньше, чем о ней узнают клиенты.

Что вообще нужно мониторить

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

CPU. Процессор — первое, на что смотрят. Нагрузка 70–80% — норма при активной работе. Если CPU стабильно выше 90% — что-то не так: утечка в коде, бесконечный цикл, криптомайнер после взлома. Один всплеск до 100% — не катастрофа, постоянно высокий показатель — повод копать.

RAM. Память заканчивается постепенно, и это особенно опасно. Приложение начинает свопировать — использовать диск как замену оперативки. Сервер тормозит, но не падает. Ты думаешь «ну и ладно», а потом получаешь OOM Killer, который без предупреждения убивает процессы. Следи за свободной памятью и за swap-активностью.

Диск. Два параметра: заполненность и скорость I/O. Заполненный диск — это полный стоп для баз данных и веб-серверов. Nginx не может записать лог — молча падает. MySQL не может создать временный файл — запрос обрывается. Порог в 80% — уже сигнал тревоги, не 95%.

Сеть. Трафик, количество соединений, ошибки пакетов. Резкий рост входящего трафика — возможная DDoS-атака или вирусный пост в соцсетях. Рост исходящего без видимых причин — сервер что-то отправляет наружу, и это повод проверить безопасность.

Метрики приложения — не путай с метриками сервера

Мониторинг ОС и мониторинг приложения — разные вещи, и нужны оба.

Для веб-приложений критичны:

  • Время ответа (latency). Если запрос обрабатывается дольше 2–3 секунд — пользователь уходит. Следи за p50, p95 и p99 — медианой и хвостами распределения. Средняя цифра обманывает: среднее может быть 200ms, а 1% запросов висят по 10 секунд.
  • Количество ошибок (error rate). Сколько запросов завершается с кодами 5xx. Норма — близко к нулю. Рост до 1–2% уже критичен для продакшена.
  • RPS (requests per second). Сколько запросов обрабатывает сервер. Помогает понять текущую нагрузку и сравнить с историческими данными.
  • Статус очередей. Если используешь Celery, RabbitMQ или Redis как брокер — следи за длиной очереди. Если задачи накапливаются и не обрабатываются, что-то пошло не так с воркерами.

Инструменты: от простого к серьёзному

Prometheus + Grafana

Де-факто стандарт в индустрии. Prometheus собирает метрики, Grafana строит дашборды.

Как это работает: Prometheus периодически «опрашивает» (scrape) эндпоинты с метриками. Каждый сервис экспортирует метрики в формате text/plain по адресу /metrics. Есть готовые экспортёры для всего — node_exporter для системных метрик Linux, postgres_exporter для PostgreSQL, nginx-prometheus-exporter для Nginx.

Установка node_exporter:

wget https://github.com/prometheus/node_exporter/releases/download/v1.7.0/node_exporter-1.7.0.linux-amd64.tar.gz
tar xvfz node_exporter-1.7.0.linux-amd64.tar.gz
sudo mv node_exporter-1.7.0.linux-amd64/node_exporter /usr/local/bin/

Запускаешь как systemd-сервис, и он начинает отдавать метрики на порту 9100. Prometheus подхватывает их каждые 15 секунд по умолчанию.

Графана даёт красивые дашборды. На сайте Grafana Labs есть готовые дашборды с ID — просто импортируешь. Дашборд 1860 (Node Exporter Full) — хорошее начало, покрывает всё основное.

Минус: требует настройки. Для одного небольшого сервера может быть избыточно. Зато бесплатно и масштабируется до сотен серверов.

Zabbix

Старый добрый монстр. Существует с 2001 года и до сих пор активно используется в корпоративной среде. Умеет почти всё: метрики, алерты, карты сети, отчёты.

Плюс — есть агент для Windows, что важно для гетерогенной инфраструктуры. Минус — интерфейс морально устарел, и настройка через веб-GUI утомляет. Новичку будет тяжело.

Netdata

Если нужно быстро поднять мониторинг с красивым интерфейсом — Netdata. Устанавливается одной командой:

wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh && sh /tmp/netdata-kickstart.sh

Через минуту на порту 19999 появляется веб-интерфейс с сотнями метрик в реальном времени. Нулевая конфигурация для базовых метрик.

Hint: Netdata хорошо работает как первый уровень мониторинга. Потом, когда нужна история и алерты, добавляешь Prometheus сверху.

Uptime Kuma

Отдельный инструмент для мониторинга доступности — проверяет, отвечает ли сайт или API. Не заменяет системный мониторинг, но дополняет.

Запускается в Docker:

docker run -d --restart=always -p 3001:3001 \
  -v uptime-kuma:/app/data \
  --name uptime-kuma louislam/uptime-kuma:1

Добавляешь URL-адреса, которые нужно проверять каждую минуту. Если сайт упал — приходит уведомление в Telegram, Slack или на почту. Просто и бесплатно.

Облачные SaaS-решения

Если не хочешь поднимать инфраструктуру мониторинга самостоятельно — есть Datadog, New Relic, Sentry (для ошибок приложения). Платно, но работает из коробки. Datadog берёт от $15 в месяц за хост — считай сам, оправданно ли это для твоего случая.

Алерты — самое важное

Мониторинг без алертов — это красивые графики, которые никто не смотрит. Алерты — то, ради чего всё затевается.

Правила хорошего алерта:

Алерт должен требовать действия. Если получил уведомление и можешь ничего не делать — это не алерт, это шум. Отключи или переделай.

Порог должен быть осмысленным. CPU > 80% на 5 минут — алерт. CPU > 80% на 30 секунд — норма при старте приложения. Используй функцию for в Prometheus AlertManager:

- alert: HighCPULoad
  expr: 100 - (avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[2m])) * 100) > 80
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "Высокая нагрузка CPU на {{ $labels.instance }}"

Разные уровни серьёзности. Warning — можно посмотреть утром. Critical — буди хоть в три ночи. Смешивать нельзя: если всё critical, ничто не critical.

Минимум каналов уведомлений. Telegram для critical, почта для daily summary — достаточно. Не плоди десять каналов, иначе уведомления начнут игнорироваться.

Логи — отдельная история

Метрики говорят «что» произошло, логи говорят «почему». Без логов диагностика превращается в гадание.

Минимальный стек: Loki + Promtail + Grafana. Promtail читает файлы логов и отправляет в Loki. Grafana показывает логи рядом с метриками — удобно, когда видишь всплеск ошибок на графике и сразу провалюешься в соответствующие строки логов.

Альтернатива — ELK Stack (Elasticsearch + Logstash + Kibana). Мощнее, но требует больше ресурсов. Elasticsearch под нагрузкой ест память охотно. Для небольшого проекта Loki предпочтительнее.

Что логировать обязательно:

  • Все ошибки приложения (уровень ERROR и выше)
  • Медленные запросы к БД (slow query log в MySQL/PostgreSQL)
  • Запросы к Nginx/Apache с кодами 4xx и 5xx
  • Попытки авторизации (особенно неудачные)

Мониторинг баз данных

База данных — чаще всего узкое место. Несколько метрик, которые стоит отслеживать всегда:

Для PostgreSQL:

  • Количество активных соединений vs максимум (max_connections)
  • Время выполнения запросов
  • Размер таблиц и индексов
  • Количество dead tuples — признак того, что autovacuum не справляется

Для MySQL/MariaDB:

  • Innodb buffer pool hit rate — должен быть выше 95%
  • Threads connected
  • Slow queries per second

Для PostgreSQL есть pg_stat_statements — расширение, которое копит статистику по всем запросам. После включения можешь найти самые медленные или самые частые запросы:

SELECT query, calls, mean_exec_time
FROM pg_stat_statements
ORDER BY mean_exec_time DESC
LIMIT 10;

С чего начать прямо сейчас

Если у тебя ещё нет никакого мониторинга — вот минимальный план на один вечер:

  1. Установи Netdata на сервер. Десять минут, нулевая конфигурация.
  2. Подними Uptime Kuma и добавь все критичные URL. Настрой Telegram-уведомления.
  3. Проверь, что логи Nginx пишутся и ты знаешь, где они лежат (/var/log/nginx/error.log).

Этого достаточно, чтобы не проспать полное падение. Потом, когда освоишься, добавляй Prometheus, Grafana, AlertManager — по потребности.

Если хочется делегировать инфраструктурные задачи и сосредоточиться на продукте — такие вопросы часто решаются при разработке и поддержке сайта. Студия REEXY, например, занимается поддержкой сайтов и может взять на себя в том числе технические вещи — от $10 000 в месяц зависит объём задач, а не фиксированный список.

Типичные ошибки

Мониторить только uptime. «Сайт отвечает» — не значит «сайт работает». Можно получать 200 OK на главной странице, но корзина не работает и оформление заказа упало.

Игнорировать тренды. Диск занят на 60% — окей. Но если три месяца назад было 40%, а сейчас 60% — через три месяца будет 80%. Смотри не только на текущее значение, но и на динамику.

Слишком много алертов. Это называется alert fatigue. Когда уведомлений слишком много, люди начинают их игнорировать. Потом пропускают важное. Беспощадно отключай шумные алерты.

Не тестировать алерты. Настроил alertmanager — проверь, что уведомление реально приходит. Остановить node_exporter, дождаться алерта, убедиться, что Telegram-сообщение пришло. Звучит очевидно, но многие этого не делают.

Мониторить только прод. Staging и dev тоже могут преподносить сюрпризы. Хотя бы минимальный uptime-мониторинг для тестовых окружений лишним не будет.

Мониторинг — это не про красивые дашборды. Это про сон по ночам и уверенность, что ты узнаешь о проблеме первым, а не от клиента.