Короткий ответ: мониторинг нужен, чтобы узнавать о проблеме раньше клиентов. Минимальный набор — доступность сайта снаружи, свободное место на диске, потребление памяти, срок действия SSL-сертификата и код ответа формы заявки. Netdata закрывает серверную часть и ставится одной командой, а внешнюю доступность проверяют отдельным сервисом, потому что мониторинг на самом сервере не заметит, если сервер целиком недоступен.
Тема относится к поддержке и развитию; смежные материалы — резервное копирование и настройка firewall.
Что мониторить обязательно
| Показатель | Почему важен | Типичный порог |
|---|---|---|
| Доступность сайта | Основной показатель; о падении нужно знать первыми | Любой код кроме 2xx и 3xx |
| Свободное место | Заполненный диск останавливает базу и сайт | Меньше 15 % свободно |
| Потребление памяти | Рост указывает на утечку до того, как сработает OOM-killer | Больше 85 % постоянно |
| Нагрузка на процессор | Постоянная высокая нагрузка замедляет отдачу страниц | Load average выше числа ядер |
| Срок SSL-сертификата | Истёкший сертификат закрывает сайт для посетителей | Меньше 21 дня |
| Отправка формы заявки | Сайт работает, а заявки не доходят — потери идут неделями | Любая ошибка отправки |
| Ошибки в журналах | Рост числа ошибок предшествует сбоям | Резкий рост за сутки |
Последние два пункта чаще всего упускают, а именно они связаны с деньгами напрямую.
Установка Netdata
wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh
sh /tmp/netdata-kickstart.sh --non-interactiveПосле установки веб-интерфейс доступен на порту 19999. Открывать этот порт наружу не нужно: правильнее закрыть его firewall и обращаться через SSH-туннель или через nginx с авторизацией.
# доступ через туннель: на своей машине
ssh -L 19999:127.0.0.1:19999 root@сервер
# затем открыть http://127.0.0.1:19999Netdata сам собирает сотни показателей и хранит их в собственной базе, не требуя внешнего сервера. Для одного-двух серверов этого достаточно; для парка машин обычно добавляют центральный сборщик.
Настройка
Правка конфигурации выполняется через утилиту edit-config — она создаёт копию файла в правильном месте, не трогая оригинал:
cd /etc/netdata
./edit-config netdata.confЧто стоит изменить сразу:
[global]
memory mode = dbengine
# ограничить объём базы, иначе она растёт бесконечно
dbengine multihost disk space MB = 1024
[web]
bind to = 127.0.0.1
| Параметр | Смысл |
|---|---|
memory mode = dbengine |
Хранение на диске вместо памяти: данные сохраняются между перезапусками |
dbengine multihost disk space MB |
Потолок объёма базы. Без него она займёт всё свободное место |
bind to = 127.0.0.1 |
Интерфейс слушает только локально — снаружи недоступен |
Оповещения в Telegram
Netdata умеет присылать уведомления при срабатывании проверок. Настраивается через health_alarm_notify.conf:
cd /etc/netdata
./edit-config health_alarm_notify.confSEND_TELEGRAM="YES"
TELEGRAM_BOT_TOKEN="токен вашего бота"
DEFAULT_RECIPIENT_TELEGRAM="идентификатор чата"Токен берётся у бота, созданного через @BotFather, идентификатор чата — у бота вроде @userinfobot. Для группового чата идентификатор отрицательный. После правки проверяется отправка:
/usr/libexec/netdata/plugins.d/alarm-notify.sh testПуть к скрипту может отличаться в зависимости от сборки; найти его можно командой find / -name alarm-notify.sh 2>/dev/null.
Внешняя проверка доступности
Мониторинг, установленный на самом сервере, не сможет сообщить, что сервер целиком недоступен. Внешняя проверка нужна отдельно:
| Вариант | Особенность |
|---|---|
| Внешний сервис проверки доступности | Проверяет с нескольких точек мира, есть история и оповещения |
| Второй сервер с простым скриптом | Полный контроль, но требует поддержки |
| Проверка через поисковые системы | Не подходит: узнаете о проблеме последним |
Проверять нужно не только главную страницу, но и сквозной сценарий: отправку формы заявки и доступность ключевых разделов. Сайт, который отвечает кодом 200, но не принимает заявки, формально «работает».
Что смотреть в первую очередь при инциденте
- Диск. Заполненный раздел — самая частая причина внезапного отказа.
- Память. Посмотреть, не убивал ли ядро процессы:
journalctl -k | grep -i "out of memory". - Процессы. Что потребляет ресурсы:
ps aux --sort=-%mem | head. - Журналы веб-сервера. Ошибки и резкий рост числа запросов.
- Журналы приложения.
journalctl -u имя -p err --since "1 hour ago". - Последние изменения. Обновление, деплой или правка конфигурации перед сбоем.
Порядок важен: диск и память дают быстрый ответ в большинстве случаев, и только потом имеет смысл разбирать приложение.
Типичные ошибки
- Мониторинг только внутри сервера. При полном отказе он молчит вместе с сервером.
- Нет оповещений. Данные собираются, но никто на них не смотрит — эффекта нет.
- Не ограничен объём базы. Netdata без потолка заполняет диск, то есть сам становится причиной сбоя.
- Открытый порт наружу. Интерфейс мониторинга без авторизации доступен всем.
- Оповещения обо всём. Поток уведомлений приводит к тому, что важные перестают читать.
- Нет проверки формы заявки. Технически сайт работает, коммерчески — нет.