Grafana и Prometheus на сервере: частые ошибки и решения

MAATRIX

Prometheus и Grafana подняты, но в панелях «No data», target горит красным DOWN, а алерты не приходят или, наоборот, сыплются пачками. Всё это типовые ошибки связки, и почти каждая упирается в одну из известных причин: firewall, неверный URL источника, часовой пояс, разросшийся диск. Разберём частые проблемы Grafana и Prometheus на сервере с командами для диагностики и готовыми решениями.

Target DOWN в Prometheus

Первое место, куда смотреть при отсутствии данных, — статус целей. Откройте в браузере http://IP:9090/targets (или Status → Targets в интерфейсе Prometheus). Красный статус DOWN и текст ошибки рядом сразу подсказывают причину.

• connection refused — экспортёр не запущен или слушает другой порт. Проверьте: systemctl status node_exporter и curl localhost:9100/metrics.
• context deadline exceeded — таймаут: экспортёр не успевает ответить или его блокирует firewall. Для удалённого узла откройте порт экспортёра.
• no such host — опечатка в имени цели в prometheus.yml.

Если мониторите удалённый сервер, а не localhost, частая ошибка — забыли открыть порт экспортёра между машинами. Node Exporter слушает 9100; откройте его только для адреса сервера Prometheus, а не наружу для всех:

ufw allow from IP_PROMETHEUS to any port 9100

После правки конфига Prometheus не требует полного перезапуска — достаточно перечитать конфиг сигналом или через curl -X POST http://localhost:9090/-/reload, если включён флаг --web.enable-lifecycle.

Панель Grafana показывает «No data»

Target в Prometheus зелёный, а в Grafana пусто. Причин несколько, идём по порядку.

Первое — неверный источник данных. В Grafana откройте Connections → Data sources → Prometheus и нажмите Save & test: если связь не проходит, проверьте URL. Классическая ошибка — указать http://localhost:9090, когда Grafana в Docker, а Prometheus снаружи: localhost внутри контейнера ведёт в сам контейнер. В таком случае используйте имя сервиса или IP хоста.

Второе — временной диапазон. Grafana по умолчанию показывает последние часы; если данные собираются недавно или сдвинут часовой пояс, панель окажется пустой. Поставьте диапазон «Last 15 minutes» и проверьте. Третье — неверный запрос PromQL в панели: откройте Explore, введите простой запрос вроде up и посмотрите, есть ли вообще данные. Если up возвращает 1 — Prometheus собирает, проблема в конкретном запросе панели.

Ошибки часового пояса и сдвиг графиков

Графики показывают данные со сдвигом или «в будущем» — классика рассинхрона времени. Prometheus хранит метки времени в UTC, и если системное время сервера врёт, всё поедет.

Сначала выставьте время и включите синхронизацию:

timedatectl set-ntp true
timedatectl status

В самой Grafana часовой пояс задаётся на уровне дашборда и профиля пользователя — по умолчанию берётся браузерный, что обычно верно. Если графики всё равно сдвинуты, проверьте, что на всех серверах (и Prometheus, и наблюдаемых) включён NTP и время совпадает. Рассинхрон между узлами — частая причина «дыр» в данных и неверных таймингов алертов.

Диск переполняется базой Prometheus

Prometheus хранит все метрики локально, и на активной инфраструктуре база растёт быстро. Однажды диск заполняется, и Prometheus перестаёт принимать данные, а в логе появляется «no space left on device».

Управляйте хранением через флаги запуска в systemd-юните. Ключевой — период хранения:

--storage.tsdb.retention.time=30d
--storage.tsdb.retention.size=20GB

Первый ограничивает историю по времени (30 дней), второй — по размеру (20 ГБ), что достигается раньше. Добавьте нужные флаги в ExecStart, перезагрузите юнит и перезапустите Prometheus. Следите за размером базы:

du -sh /var/lib/prometheus
df -h

Если нужна долгая история без раздувания локального диска, метрики выносят в удалённое хранилище (remote_write), но для большинства задач достаточно разумного retention и диска с запасом. Важно понимать причину роста: объём базы определяется числом уникальных временных рядов, а не только частотой опроса. Каждая новая метка (label) с высокой кардинальностью — например, идентификатор запроса или путь URL как значение метки — плодит тысячи рядов и раздувает базу лавинообразно. Поэтому если диск растёт подозрительно быстро, ищите не только длинный retention, но и «взрывные» метки в ваших экспортёрах и приложениях.

Алерты не приходят или дублируются

Правило алерта настроено, а уведомлений нет — либо, наоборот, они идут потоком. Сначала проверьте, срабатывает ли само правило: в Grafana это раздел Alerting → Alert rules, где видно состояние (Normal, Pending, Firing). Если правило в Firing, а сообщение не пришло — проблема в канале уведомления (contact point).

Частые причины молчания: неверный токен бота или chat_id для Telegram, заблокированный исходящий трафик к API уведомлений, опечатка в вебхуке. Проверьте канал кнопкой Test в настройках contact point. Обратная проблема — шторм алертов: правило срабатывает на каждое минимальное колебание. Лечится параметром for (алерт срабатывает, только если условие держится N минут) и группировкой в Alertmanager, которая объединяет однотипные уведомления в одно. Хороший алерт срабатывает на реальную проблему, а не на секундный всплеск.

Безопасность и стабильность стека

Отдельная категория проблем — открытые наружу порты и стандартные пароли. Grafana со связкой admin/admin, доступная из интернета, — прямой путь к компрометации, а через неё видно всю вашу инфраструктуру. Порты Prometheus (9090) и экспортёров (9100), открытые для всех, отдают ваши метрики любому.

Минимальная гигиена: смените пароль Grafana сразу, ограничьте доступ к её порту по IP или спрячьте за reverse-proxy с HTTPS, а Prometheus и экспортёры не выставляйте наружу вовсе — они должны общаться по внутренней сети или через firewall-правила «только со своего адреса». Это закрывает большинство рисков.

Чтобы стек мониторинга работал стабильно и без сюрпризов с оплатой, нужен надёжный VPS в правильной локации. У MAATRIX сервер готов за пару минут, с оплатой картой РФ, СБП или криптой — иностранная карта не требуется.

Частые вопросы