Grafana + Prometheus: как я настроил мониторинг всего и вся
Почему стандартных логов недостаточно
Когда сервер один, проблемы видны сразу: перестал открываться сайт — зашёл по SSH, глянул логи, поправил. Когда сервисов становится 10+, нужен централизованный мониторинг.
Я перепробовал несколько решений: Zabbix — мощный, но конфигурация через веб-морду — ад. Netdata — красиво, но слишком много метрик, глаза разбегаются. InfluxDB + Telegraf — норм, но Telegraf надо настраивать.
Остановился на Prometheus + Grafana. Prometheus собирает метрики, Grafana их рисует.
Что я мониторю
Для начала — базовые метрики сервера через Node Exporter: CPU, RAM, диск, сеть. Prometheus забирает данные с Node Exporter раз в 15 секунд. В Grafana подключил стандартный дашборд Node Exporter Full — сразу видно состояние сервера.
Потом добавил cAdvisor для мониторинга Docker контейнеров: сколько каждый контейнер жрёт памяти, CPU, сколько сетевого трафика генерирует. Очень помогло, когда один контейнер начал течь по памяти.
Blackbox Exporter — проверка доступности сайтов извне. Каждую минуту Prometheus проверяет, отвечает ли mysurik.ru по HTTP. Если не отвечает — Grafana шлёт алерт.
MySQL Exporter — метрики базы данных: количество запросов, медленные запросы, размер таблиц. Заметил, что в определённое время БД тормозит — оказалось, cron запускал бекап таблиц в это же время.
Настройка алертов
Самое полезное — алерты в Telegram. Если CPU зашкаливает за 90% — сообщение в чат. Если диск заполнен на 85% — напоминание. Если сайт не отвечает — срочное уведомление.
Настроил алерты через Alertmanager, который отправляет сообщения через Telegram Bot API. Теперь я узнаю о проблемах быстрее, чем пользователи.
Грабли
Retention данных. По умолчанию Prometheus хранит данные 15 дней. Для моего сценария мало — хочу видеть графики за месяц. Увеличил retention до 30 дней, но пришлось выделить под Prometheus 10 GB диска вместо 2.
Prometheus не умеет шифроваться — все данные идут в открытую. Пришлось повесить всё за nginx с базовой аутентификацией.
Совет
Не пытайтесь мониторить всё сразу. Начните с CPU, RAM, диска и доступности сайта. Добавляйте метрики по мере необходимости. И обязательно настройте алерты в Telegram — иначе смысла в мониторинге нет.
Продолжу рассказ про Prometheus и Grafana, потому что эта связка — моя любимая тема в мониторинге, и за коротким описанием стоит много практических деталей. Расскажу о том, как я пришёл к этому стеку, что мониторю и какие грабли обходил.
Начну с того, как я дорос до полноценного мониторинга. Когда у меня был один сервер, всё было просто: сайт не открылся — зашёл по SSH, посмотрел логи, поправил. Но по мере роста количества сервисов этот подход перестал работать. Десять сервисов — это десять потенциальных проблем, и проверять их вручную нереально. Нужна была система, которая сама собирает метрики, сама показывает их наглядно и сама предупреждает о проблемах. Так я и оказался на распутье: какую систему мониторинга выбрать.
Я перебрал несколько вариантов, и у каждого нашлись свои изъяны. Zabbix — мощный, но конфигурация через его веб-морду — это ад. Всё настраивается через формы и скрипты, и даже простые задачи превращаются в квест. Netdata — красивый и простой, но метрик настолько много, что глаза разбегаются, а нужные теряются в шуме. InfluxDB + Telegraf — нормальная связка, но Telegraf надо настраивать вручную, и у него своя логика. В итоге я остановился на Prometheus + Grafana. Почему? Потому что Prometheus собирает метрики по принципу pull — сам опрашивает экспортеров, — а Grafana умеет рисовать красивые и настраиваемые дашборды. Связка оказалась гибкой и предсказуемой.
Теперь про компоненты, которые я использую, подробнее. Основа — Node Exporter. Это маленький агент, который отдаёт метрики сервера: CPU, память, диск, сеть. Prometheus забирает их раз в пятнадцать секунд. В Grafana я подключил стандартный дашборд Node Exporter Full — и сразу увидел полную картину состояния сервера. Для старта этого достаточно: ты видишь нагрузку, температуру дисков, сетевой трафик. Именно с этого стоит начинать, если ты только знакомишься с мониторингом.
Дальше — cAdvisor. Это экспортер для Docker-контейнеров: сколько каждый контейнер ест памяти, CPU, сколько сетевого трафика генерирует. Он спас меня в одном случае: контейнер начал течь по памяти, и без cAdvisor я бы долго искал виновника. А тут — один взгляд на дашборд, и видно, какой контейнер раздувается. Для всех, кто держит сервисы в Docker, cAdvisor — обязательный элемент стека. Он показывает то, что вручную искать очень муторно.
Ещё один важный компонент — Blackbox Exporter. Это проверка доступности сайтов извне. Каждую минуту Prometheus проверяет, отвечает ли mysurik.ru по HTTP, и если нет — Grafana шлёт алерт. Чем это отличается от пинга? Проверяется именно ответ веб-сервера, а не просто доступность машины. Можно настроить проверку по конкретному пути, по коду ответа, по времени отклика. Для сайта это самый ценный мониторинг: он ловит именно те проблемы, которые видят пользователи.
Про MySQL Exporter тоже расскажу, потому что база данных — это сердце сайта. Он собирает метрики: количество запросов, медленные запросы, размер таблиц. Однажды я заметил по графикам, что база тормозит в одно и то же время каждый день. Стал разбираться — оказалось, в это время крон запускал бекап таблиц, который нагружал базу. Без метрик я бы не увидел эту закономерность — просто думал, что «что-то тормозит иногда». А так — увидел график, понял причину, сдвинул бекап. Маленькая победа, но таких мелочей набирается много.
Теперь про самое полезное — алерты в Telegram. Мониторинг без алертов — это просто красивые графики, которые ты смотришь, когда что-то уже сломалось. Настоящая польза — когда система сама тебя будит. Я настроил через Alertmanager: если CPU зашкаливает за 90% — сообщение в чат. Если диск заполнен на 85% — напоминание. Если сайт не отвечает — срочное уведомление. Всё это уходит через Telegram Bot API. Теперь я узнаю о проблемах быстрее, чем пользователи, и это именно то, ради чего я всё затевал.
Про то, как настраивать алерты, скажу пару слов. В Prometheus алерты описываются в конфиге — правила, когда срабатывать. Alertmanager их обрабатывает и отправляет в каналы: Telegram, email, Slack. У меня всё идёт в Telegram-чат, потому что я почти всегда в телефоне. Важно не перестараться: если алертов слишком много, ты перестаёшь на них реагировать. Я начал с четырёх ключевых правил и добавляю новые только тогда, когда понимаю, что без них не обойтись. Лучше пять важных алертов, чем пятьдесят шумных.
Про грабли с retention расскажу отдельно, потому что это типичная неожиданность. По умолчанию Prometheus хранит данные только пятнадцать дней. Мне этого мало — я хочу видеть графики за месяц. Увеличил retention до тридцати дней, но за это пришлось заплатить диском: под Prometheus выделено десять гигабайт вместо двух. Помни об этом, когда настраиваешь свой стек: retention напрямую влияет на размер хранилища. И решай заранее, какой период истории тебе реально нужен, чтобы не раздувать диск без необходимости.
Ещё одна грабля — безопасность. Prometheus и Grafana по умолчанию не умеют шифровать и не имеют встроенной аутентификации. То есть метрики лежат открыто, и любой, кто знает адрес, может их посмотреть. Я решил это так: повесил всё за nginx с базовой аутентификацией и закрыл доступ извне. Для домашней или внутренней инфраструктуры это минимум. Если бы сервисы были публичными, пришлось бы думать про сертификаты и более серьёзную защиту. Не пренебрегай этим шагом — метрики могут рассказать о твоей инфраструктуре слишком много.
Ещё про то, чего я не стал делать. Я не стал мониторить каждую мелочь с первого дня. Слишком много метрик — это шум, в котором тонут важные сигналы. Мой подход: начать с базового (CPU, RAM, диск, доступность), потом добавлять то, что реально помогает (контейнеры, база, сайт). Каждая новая метрика должна отвечать на вопрос «зачем мне это знать». Если ответа нет — не добавляю. Такой подход держит дашборды чистыми, а алерты — осмысленными.
Отдельно скажу про выбор времени между проверками. Я поставил интервал пятнадцать секунд для Node Exporter и минуту для проверки доступности сайта. Меньше — избыточно, больше — можно пропустить проблему. Пятнадцать секунд — золотая середина: с одной стороны, метрики достаточно свежие, с другой — сервер не перегружен опросом. Для сайта минута между проверками — норм, за эту минуту ничего фатального не случится, а нагрузка на внешний сервис минимальна.
Подведу итог. Prometheus + Grafana — это мощная и гибкая связка, которая решает мою задачу: централизованный мониторинг, наглядные дашборды и своевременные алерты. Да, у неё есть кривая обучения, но она того стоит. Главные советы из моего опыта: начинай с малого, настрой алерты в Telegram сразу, не раздувай метрики без необходимости и не забывай про безопасность. Тогда мониторинг станет не «ещё одним сервисом», а настоящим помощником, который экономит нервы и время.
Добавлю ещё пару практических моментов. Первое — как обновлять стек. Prometheus и Grafana в Docker обновляются тривиально: пересоздал контейнер с новым образом, проверил дашборды — и всё. Конфиги и правила у меня лежат в отдельных файлах, поэтому при пересоздании ничего не теряется. Я не обновляюсь сразу после выхода новой версии — жду неделю, как и с другими критичными сервисами, чтобы не поймать регрессии. Пока за всё время не было ни одной проблемы с обновлением.
Второе — про бэкапы конфигурации. Самый важный файл в моём стеке — это конфиг Prometheus с правилами алертов. Я его бэкаплю вместе с остальными конфигами сервера. Если что-то случится с контейнером, я восстановлю мониторинг за десять минут. А вот сами метрики я не бэкаплю — они не критичны, потеря истории не страшна, главное — восстановить сам механизм сбора.
И третье — про то, что мониторинг нужен не только «для галочки». Я реально каждый день открываю Grafana и смотрю, что происходит. Это вошло в привычку, как проверка погоды утром. Именно регулярный взгляд на графики помогает замечать тенденции до того, как они превратятся в проблемы. Дело не в алертах, а в том, что ты начинаешь понимать свою инфраструктуру — как она дышит, что её нагружает, где запас прочности. Это знание бесценно.