Архив рассылок сообщества снова открыт. Читать письма 2003-2009
Главная/Блог/Эксплуатация
Эксплуатация18 мин чтенияНиколай Ковалёв

Мониторинг Linux-сервера: Prometheus и Grafana для начинающих

node_exporter, Prometheus, Grafana и Alertmanager на одном VPS: установка из пакетов, первые PromQL-запросы, алерты в Telegram, хранение и защита портов.

Серверные стойки с подсветкой и экран с плавными графиками метрик

Коротко: базовый мониторинг Linux-сервера собирается из четырёх свободных компонентов. node_exporter отдаёт метрики системы по HTTP, Prometheus раз в 15 секунд забирает их и хранит, Grafana рисует графики, а Alertmanager присылает уведомления в Telegram или на почту. На Debian и Ubuntu всё ставится из пакетов за полчаса. Главное — сразу закрыть порты 9100 и 9090 от интернета и настроить хотя бы три алерта: сервер недоступен, кончается диск, не хватает памяти.

Мониторинг нужен не для красивых графиков. Он отвечает на два вопроса: «что сломалось прямо сейчас» и «что сломается через неделю, если ничего не делать». Без него о заполненном диске вы узнаёте от пользователей, а о том, что база неделю упиралась в память, — когда она падает. Если сервер достался вам вместе с проектом от подрядчика, например от студии вроде YuSMP Group или от фрилансера, первым делом спросите, какие метрики уже собираются и кому уходят алерты. Если ответ «никаких и никому», эта статья как раз про то, с чего начать.

Дальше соберём рабочую связку на одном VPS, разберём, какие метрики смотреть и на что ставить алерты, а в конце — типичные ошибки и вопросы. Команды проверены на Debian 12 и Ubuntu 24.04 с пакетами из репозиториев дистрибутива.

Как устроен мониторинг на Prometheus?

Prometheus работает по модели pull: не серверы присылают ему данные, а он сам ходит к ним по HTTP и забирает текущие значения. Каждая цель, которую он опрашивает, называется target, а группа однотипных целей — job.

  • node_exporter — маленький агент на каждом сервере. Читает /proc и /sys и отдаёт сотни метрик в текстовом виде на http://сервер:9100/metrics: загрузку CPU, память, диски, сеть, температуру, состояние systemd-юнитов.
  • Prometheus — сервер сбора и хранения. По расписанию опрашивает все targets, складывает значения во встроенную временную базу (TSDB), вычисляет правила алертов и отвечает на запросы на языке PromQL. Веб-интерфейс на порту 9090.
  • Grafana — визуализация. Ходит в Prometheus как в источник данных и строит дашборды. Порт 3000.
  • Alertmanager — доставка уведомлений. Prometheus решает, что алерт сработал, а Alertmanager группирует похожие алерты, подавляет дубли и отправляет их в Telegram, почту, Slack или по вебхуку. Порт 9093.

Поток данных получается такой: node_exporter → Prometheus → Grafana для графиков и Prometheus → Alertmanager → Telegram для уведомлений. Каждый компонент — отдельный бинарник и отдельный systemd-юнит, их можно ставить на разные машины.

КомпонентПортГде ставитьКому открыт
node_exporter9100На каждом сервереТолько IP Prometheus
Prometheus9090Сервер мониторингаlocalhost и Grafana
Alertmanager9093Рядом с Prometheuslocalhost
Grafana3000Рядом с PrometheusЧерез Nginx с HTTPS и паролем

Что подготовить перед установкой?

Для обучения и мониторинга до пяти серверов хватит VPS с 1 vCPU, 2 ГБ памяти и 20 ГБ диска. Если сервер один и некритичный, всё можно поставить прямо на него. Но держите в голове главный недостаток такой схемы: упал сервер — упал и мониторинг, и сообщение о падении отправить некому. Для продакшена Prometheus и Alertmanager выносят на отдельную маленькую машину, а на рабочие серверы ставят только node_exporter.

Перед началом проверьте три вещи:

  1. Часы синхронизированы. Prometheus очень чувствителен к расхождению времени: timedatectl должен показывать System clock synchronized: yes. Если нет — sudo apt install systemd-timesyncd.
  2. Фаервол включён. Все примеры ниже рассчитаны на ufw. Если сервер новый, сначала пройдите чеклист базовой защиты Linux-сервера.
  3. Есть место под данные. Prometheus по умолчанию пишет в /var/lib/prometheus. Один хост — это порядка 10–15 МБ в сутки, подробный расчёт ниже.

Как установить node_exporter?

В Debian и Ubuntu экспортер есть в репозитории, вместе с готовым systemd-юнитом и отдельным системным пользователем:

sudo apt update
sudo apt install prometheus-node-exporter
systemctl status prometheus-node-exporter
curl -s http://localhost:9100/metrics | grep ^node_load

Последняя команда должна вывести три строки вида node_load1 0.12. Если вывод есть, экспортер работает.

Свежая версия с GitHub

Пакет дистрибутива обычно отстаёт от upstream на несколько версий. Для базовых метрик это не страшно, но если нужна новая функция, бинарник можно поставить вручную. Версию возьмите на странице релизов проекта на GitHub:

VER=1.9.1   # подставьте актуальную версию
cd /tmp
wget https://github.com/prometheus/node_exporter/releases/download/v${VER}/node_exporter-${VER}.linux-amd64.tar.gz
tar xzf node_exporter-${VER}.linux-amd64.tar.gz
sudo install -m 0755 node_exporter-${VER}.linux-amd64/node_exporter /usr/local/bin/
sudo useradd --system --no-create-home --shell /usr/sbin/nologin node_exporter

И юнит /etc/systemd/system/node_exporter.service:

[Unit]
Description=Prometheus node_exporter
After=network-online.target
Wants=network-online.target

[Service]
User=node_exporter
Group=node_exporter
ExecStart=/usr/local/bin/node_exporter --collector.systemd
Restart=on-failure

[Install]
WantedBy=multi-user.target
sudo systemctl daemon-reload
sudo systemctl enable --now node_exporter

Флаг --collector.systemd включает метрики состояния юнитов — с ним можно получать алерт, когда упал nginx или postgresql. Если юниты и journalctl пока вызывают вопросы, загляните в нашу статью про systemd без боли.

Сразу закройте порт 9100

По умолчанию node_exporter слушает все интерфейсы. Это значит, что любой в интернете может прочитать список ваших дисков, версии ядра и сетевых интерфейсов. Разрешите доступ только серверу мониторинга:

sudo ufw allow from 203.0.113.10 to any port 9100 proto tcp
sudo ufw deny 9100/tcp

Вместо 203.0.113.10 — IP вашего Prometheus. Если всё стоит на одной машине, проще ограничить экспортер локальным адресом флагом --web.listen-address=127.0.0.1:9100 (для пакета Debian — в переменной ARGS файла /etc/default/prometheus-node-exporter).

Как установить и настроить Prometheus?

sudo apt install prometheus
systemctl status prometheus
promtool --version

Пакет создаёт пользователя prometheus, юнит и конфиг /etc/prometheus/prometheus.yml. Откройте его. Минимальная рабочая конфигурация выглядит так:

global:
  scrape_interval: 15s
  evaluation_interval: 15s

rule_files:
  - /etc/prometheus/rules/*.yml

alerting:
  alertmanagers:
    - static_configs:
        - targets: ['localhost:9093']

scrape_configs:
  - job_name: prometheus
    static_configs:
      - targets: ['localhost:9090']

  - job_name: node
    static_configs:
      - targets: ['localhost:9100']
        labels:
          env: prod

Что здесь важно:

  • scrape_interval: 15s — как часто опрашивать цели. Для серверных метрик 15–30 секунд достаточно; 1 секунда даст в 15 раз больше данных и почти никакой пользы.
  • rule_files — где лежат правила алертов, их напишем ниже.
  • labels — произвольные метки цели. Метка env или role пригодится, когда серверов станет больше: по ней фильтруют дашборды и маршрутизируют алерты.

Перед каждым перезапуском проверяйте конфиг — опечатка в YAML не даст Prometheus стартовать:

promtool check config /etc/prometheus/prometheus.yml
sudo systemctl reload prometheus

Откройте Status → Targets в веб-интерфейсе (через SSH-туннель, см. ниже). Обе цели должны быть в состоянии UP. Если какая-то в DOWN, в колонке Error будет причина — разбор типичных ошибок в конце статьи.

Как долго хранить метрики и сколько это места?

По умолчанию Prometheus хранит данные 15 дней. Для сравнения «как было месяц назад» этого мало, поэтому срок обычно увеличивают. В пакете Debian флаги передаются через /etc/default/prometheus:

ARGS="--storage.tsdb.retention.time=60d --storage.tsdb.retention.size=8GB --web.listen-address=127.0.0.1:9090"

Флаг retention.size страхует от переполнения диска: при достижении лимита старые блоки удаляются раньше срока. Прикинуть объём можно так: один сэмпл в TSDB занимает в среднем 1–2 байта, node_exporter даёт около тысячи временных рядов на хост, при опросе раз в 15 секунд это 5760 значений на ряд в сутки. Итого 1000 × 5760 × 2 ≈ 11,5 МБ в сутки, около 350 МБ в месяц на сервер. Десять серверов за 60 дней поместятся в 7 ГБ.

Флаг --web.listen-address=127.0.0.1:9090 убирает интерфейс Prometheus из интернета: авторизации у него нет, и открытый порт 9090 — частая находка сканеров.

Как установить Grafana и подключить Prometheus?

Grafana в репозиториях Debian нет, её ставят из репозитория Grafana Labs:

sudo apt install -y apt-transport-https wget gnupg
sudo mkdir -p /etc/apt/keyrings
wget -q -O - https://apt.grafana.com/gpg.key | gpg --dearmor | sudo tee /etc/apt/keyrings/grafana.gpg > /dev/null
echo "deb [signed-by=/etc/apt/keyrings/grafana.gpg] https://apt.grafana.com stable main" | sudo tee /etc/apt/sources.list.d/grafana.list
sudo apt update && sudo apt install grafana
sudo systemctl enable --now grafana-server

Из некоторых сетей репозиторий отвечает ошибкой 403. В этом случае проще поднять Grafana в контейнере: docker run -d --name grafana -p 127.0.0.1:3000:3000 -v grafana:/var/lib/grafana grafana/grafana-oss. Если с Docker вы ещё не работали, начните с нашего гида по контейнерам.

Дальше по шагам:

  1. Откройте http://localhost:3000 (через туннель), войдите как admin / admin и сразу смените пароль.
  2. Connections → Data sources → Add data source → Prometheus. URL: http://localhost:9090 (или http://host.docker.internal:9090 для Grafana в контейнере). Нажмите Save & test — должно появиться сообщение об успешном запросе к API.
  3. Dashboards → New → Import, введите ID 1860 — это популярный дашборд «Node Exporter Full» из библиотеки Grafana. Выберите источник данных Prometheus и нажмите Import.

Через минуту на дашборде появятся загрузка CPU, память, диски, сеть, uptime. Готовый дашборд — хорошая отправная точка, но в нём больше сотни панелей. Со временем стоит собрать свой короткий обзорный дашборд из 6–8 графиков, которые вы реально смотрите.

Как безопасно открыть веб-интерфейсы?

Пока вы настраиваете, не открывайте порты вообще — пробросьте их через SSH:

ssh -L 3000:localhost:3000 -L 9090:localhost:9090 user@monitoring-server

Теперь интерфейсы доступны на вашем компьютере по localhost:3000 и localhost:9090. Для постоянного доступа поставьте перед Grafana Nginx с HTTPS — конфиг reverse proxy есть в статье про выбор Nginx или Apache. Prometheus и Alertmanager наружу не публикуйте вовсе: всё, что нужно смотреть, смотрится через Grafana.

Какие метрики сервера смотреть в первую очередь?

У node_exporter сотни метрик, но для ежедневной работы хватает пяти групп. Удобная рамка — метод USE Брендана Грегга: для каждого ресурса смотрим утилизацию (Utilization), насыщение (Saturation) и ошибки (Errors). Ниже — готовые запросы PromQL, их можно вставить в Explore или в панель Grafana.

CPU

100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

Процент загрузки процессора за последние 5 минут. Функция rate() превращает счётчик секунд в скорость, а усреднение идёт по всем ядрам. Отдельно полезно смотреть mode="iowait": высокий iowait при низкой загрузке почти всегда значит, что процессор ждёт диск.

Нагрузка относительно числа ядер

node_load5 / count without (cpu, mode) (node_cpu_seconds_total{mode="idle"})

Load average сам по себе ничего не говорит без числа ядер. Этот запрос делит его на количество CPU: значение около 1 — сервер загружен полностью, устойчиво выше 1 — процессы стоят в очереди.

Память

(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100

Смотрите именно на MemAvailable, а не на MemFree. Linux занимает свободную память под кэш страниц, и «свободно 200 МБ» на сервере с 8 ГБ — норма, а не проблема. Признак реальной нехватки — рост своп-активности: rate(node_vmstat_pswpout[5m]) > 0 на протяжении долгого времени.

Диск: место и прогноз

100 - (node_filesystem_avail_bytes{fstype!~"tmpfs|overlay|squashfs"}
      / node_filesystem_size_bytes{fstype!~"tmpfs|overlay|squashfs"} * 100)

Процент заполнения каждой файловой системы. Фильтр по fstype убирает виртуальные ФС, которые всегда «заполнены». Ещё полезнее прогноз:

predict_linear(node_filesystem_avail_bytes{fstype!~"tmpfs|overlay|squashfs"}[6h], 24 * 3600) < 0

Запрос экстраполирует тренд последних шести часов и показывает файловые системы, которые закончатся в ближайшие сутки. Он ловит ситуацию «логи вдруг начали расти на гигабайт в час», когда до порога в 90 % ещё далеко.

Диск: задержки и сеть

rate(node_disk_io_time_seconds_total[5m])
rate(node_network_receive_bytes_total{device!="lo"}[5m]) * 8

Первый запрос показывает, какую долю времени диск был занят: значения близкие к 1 означают, что диск — узкое место. Второй — входящий трафик в битах в секунду по интерфейсам. Если трафик есть, а сайт тормозит, полезно перейти к ручной диагностике — инструменты разобраны в статье про ip, ss, mtr и dig.

Как настроить алерты в Telegram?

Графики никто не смотрит в три часа ночи, поэтому мониторинг без алертов наполовину бесполезен. Настройка состоит из двух частей: правила в Prometheus решают, когда проблема есть, а Alertmanager — кому и как о ней сказать.

Правила алертов

Создайте каталог /etc/prometheus/rules/ и файл node.yml:

groups:
  - name: node
    rules:
      - alert: HostDown
        expr: up{job="node"} == 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "{{ $labels.instance }} не отвечает"

      - alert: DiskWillFillIn24h
        expr: predict_linear(node_filesystem_avail_bytes{fstype!~"tmpfs|overlay|squashfs"}[6h], 24*3600) < 0
        for: 30m
        labels:
          severity: warning
        annotations:
          summary: "{{ $labels.instance }}: {{ $labels.mountpoint }} заполнится за сутки"

      - alert: DiskAlmostFull
        expr: node_filesystem_avail_bytes{fstype!~"tmpfs|overlay|squashfs"} / node_filesystem_size_bytes < 0.10
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "{{ $labels.instance }}: на {{ $labels.mountpoint }} меньше 10% места"

      - alert: LowMemory
        expr: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes < 0.10
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "{{ $labels.instance }}: доступно меньше 10% памяти"

      - alert: SystemdUnitFailed
        expr: node_systemd_unit_state{state="failed"} == 1
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "{{ $labels.instance }}: юнит {{ $labels.name }} в состоянии failed"

Поле for — главная защита от ложных срабатываний: условие должно держаться указанное время, прежде чем алерт уйдёт. Без него кратковременный всплеск на 30 секунд разбудит дежурного. Последнее правило работает, только если node_exporter запущен с --collector.systemd.

promtool check rules /etc/prometheus/rules/node.yml
sudo systemctl reload prometheus

Правила видны в интерфейсе Prometheus на вкладке Alerts: зелёные — неактивны, жёлтые (pending) — условие выполняется, но время for ещё не прошло, красные (firing) — алерт отправлен.

Alertmanager и бот Telegram

sudo apt install prometheus-alertmanager

Создайте бота через @BotFather, получите токен, добавьте бота в нужный чат и узнайте chat_id (например, через метод getUpdates API Telegram). Токен положите в отдельный файл с правами 600, а не прямо в конфиг, который потом может уехать в git:

echo -n 'ТОКЕН_БОТА' | sudo tee /etc/prometheus/telegram_token > /dev/null
sudo chown prometheus:prometheus /etc/prometheus/telegram_token
sudo chmod 600 /etc/prometheus/telegram_token

Конфиг /etc/prometheus/alertmanager.yml:

route:
  receiver: telegram
  group_by: ['alertname', 'instance']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h

receivers:
  - name: telegram
    telegram_configs:
      - bot_token_file: /etc/prometheus/telegram_token
        chat_id: -1001234567890
        send_resolved: true
amtool check-config /etc/prometheus/alertmanager.yml
sudo systemctl restart prometheus-alertmanager

Поле bot_token_file появилось в Alertmanager 0.26. Если в вашем дистрибутиве пакет старше (проверьте prometheus-alertmanager --version), используйте bot_token со значением прямо в конфиге и закройте сам файл правами 640 для группы prometheus.

Параметры маршрута стоит понимать: group_wait — сколько ждать перед первой отправкой, чтобы собрать похожие алерты в одно сообщение; repeat_interval — как часто напоминать о проблеме, которая не ушла. Четырёх часов достаточно: напоминание каждые пять минут быстро приучает команду выключать звук. Флаг send_resolved присылает сообщение, когда проблема ушла.

Проверить доставку, не роняя сервер, можно тестовым алертом:

amtool alert add TestAlert severity=warning instance=test --annotation=summary="Проверка доставки" --alertmanager.url=http://localhost:9093

Как добавить второй и следующие серверы?

На каждый новый сервер ставится только node_exporter и правило фаервола для IP Prometheus. На стороне Prometheus вместо бесконечного списка в static_configs удобнее держать цели в отдельном файле:

  - job_name: node
    file_sd_configs:
      - files:
          - /etc/prometheus/targets/*.yml

И файл /etc/prometheus/targets/nodes.yml:

- targets: ['10.0.0.11:9100', '10.0.0.12:9100']
  labels:
    env: prod
    role: web
- targets: ['10.0.0.21:9100']
  labels:
    env: prod
    role: db

Prometheus сам перечитывает такие файлы при изменении, перезапуск не нужен. Метки role позволяют потом строить панели «все веб-серверы» и отправлять алерты по базам данных одному человеку, а по фронтам — другому.

Когда серверов больше десятка, руками это становится неудобно. Файлы целей и установку экспортера стоит генерировать из системы управления конфигурацией, а изменения правил прогонять через CI с проверкой promtool check — как устроить такой конвейер, мы показывали в статье про GitLab CI с нуля.

Шифрование между серверами

Если серверы общаются через интернет, а не по частной сети, метрики идут открытым текстом. node_exporter умеет TLS и базовую авторизацию через файл --web.config.file:

tls_server_config:
  cert_file: /etc/node_exporter/node.crt
  key_file: /etc/node_exporter/node.key
basic_auth_users:
  prometheus: $2y$10$...   # bcrypt-хеш пароля, например из htpasswd -nBC 10 ""

В prometheus.yml для такого job добавляются scheme: https, блок basic_auth и tls_config с путём к CA. Для частной сети или WireGuard-туннеля между серверами хватает правил фаервола.

Prometheus, Zabbix или Netdata: что выбрать?

Prometheus — не единственный вариант, и для части задач не лучший. Короткое сравнение популярных свободных систем:

КритерийPrometheus + GrafanaZabbixNetdata
Модель сбораPull по HTTPАгент, активный и пассивный режим, SNMPАгент собирает локально, раз в секунду
ХранениеСвоя TSDBPostgreSQL или MySQLЛокальная база на каждом хосте
Запросы и графикиPromQL, дашборды в GrafanaВстроенный веб-интерфейс, шаблоныГотовые дашборды без настройки
Сильная сторонаКонтейнеры, Kubernetes, метрики приложенийПарк серверов и сетевое оборудованиеБыстро понять, что происходит на одном хосте
Порог входаСредний: YAML и PromQLСредний: много сущностей в интерфейсеНизкий: поставил и смотришь
Конфигурация как кодВсё в текстовых файлахВ основном через интерфейс и APIФайлы, но обычно не нужны

Практический ориентир: для одного сервера «посмотреть, что тормозит» удобен Netdata. Для десятков однотипных серверов, коммутаторов и принтеров в офисе привычнее Zabbix. Если у вас контейнеры, микросервисы или вы хотите собирать метрики самого приложения — количество заказов, время ответа API, длину очереди, — выбирайте Prometheus: под него есть экспортеры почти для всего, от Nginx до PostgreSQL, а многие программы отдают метрики в его формате сами.

Почему target в статусе DOWN и другие частые ошибки

  1. connection refused. Экспортер не запущен или слушает другой адрес. Проверьте systemctl status prometheus-node-exporter и ss -tlnp | grep 9100. Частая причина — экспортер привязан к 127.0.0.1, а Prometheus стучится по внешнему IP.
  2. context deadline exceeded. Пакеты молча отбрасываются фаерволом — на сервере с экспортером или у провайдера. Проверьте с сервера мониторинга: curl -m 5 http://10.0.0.11:9100/metrics | head.
  3. В Grafana «No data». Неверный источник данных в дашборде, слишком узкий диапазон времени или переменная job дашборда не совпадает с именем job в конфиге. Запустите тот же запрос в Explore: если данные там есть, дело в настройках панели.
  4. Предупреждение о расхождении времени. Часы браузера или сервера ушли. Проверьте timedatectl на всех машинах.
  5. Prometheus не стартует после правки. Ошибка в YAML — чаще всего табы вместо пробелов или сбитый отступ. Ответ покажут promtool check config и journalctl -u prometheus -n 50.
  6. Алерт firing, а сообщения нет. Посмотрите вкладку Status в Alertmanager (localhost:9093) и его журнал: обычно это неверный chat_id, бот не добавлен в чат или у файла с токеном не те права.
  7. Диск сервера мониторинга заполнился. Не задан retention.size, или кто-то добавил метрики с высокой кардинальностью — например, с ID пользователя в метке. Проверьте Status → TSDB Status: там видно, какие метрики дают больше всего рядов.

Что делать дальше?

Связка из этой статьи закрывает мониторинг самого сервера. Следующие шаги обычно такие:

  • blackbox_exporter — проверки «снаружи»: отвечает ли сайт кодом 200, сколько занимает ответ, когда истекает TLS-сертификат.
  • Экспортеры сервисов — nginx-prometheus-exporter, postgres_exporter, redis_exporter. Они показывают то, чего не видно на уровне ОС: медленные запросы, число соединений, попадания в кэш.
  • Метрики приложения — клиентские библиотеки Prometheus есть для Go, Python, Java, Node.js и PHP. Счётчик ошибок и гистограмма времени ответа на ключевых эндпоинтах полезнее десятка системных графиков.
  • Логи рядом с метриками — Loki в той же Grafana позволяет с графика всплеска ошибок перейти прямо к строкам журнала за ту же минуту.
  • Долгое хранение — если нужна история за год и больше, к Prometheus подключают VictoriaMetrics, Thanos или Mimir через remote_write.

Подробности по каждому компоненту — в официальной документации Prometheus, разделе про node_exporter и документации Grafana.

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

Сколько ресурсов нужно Prometheus и Grafana для одного сервера?

Для одного-пяти хостов хватает 1 vCPU, 1–2 ГБ памяти и нескольких гигабайт диска. Один хост с node_exporter даёт около тысячи временных рядов, это примерно 10–15 МБ данных в сутки при опросе раз в 15 секунд.

Можно ли ставить Prometheus на тот же сервер, который он мониторит?

Для учёбы и одного некритичного сервера можно. Но если сервер упадёт, вместе с ним упадёт и мониторинг, и алерт о падении никто не отправит. Для продакшена Prometheus выносят на отдельную небольшую машину.

Чем Prometheus отличается от Zabbix?

Prometheus сам опрашивает HTTP-эндпоинты с метриками и хранит их в своей временной базе, запросы пишутся на PromQL, а графики строят в Grafana. Zabbix — комплексная система со своим агентом, SQL-базой, веб-интерфейсом и шаблонами. Prometheus удобнее для контейнеров и динамической инфраструктуры, Zabbix — для парка однотипных серверов и сетевого оборудования.

Почему в Grafana пишет No data?

Чаще всего из-за неверного источника данных в дашборде, слишком узкого диапазона времени или переменной job, которая не совпадает с именем job в prometheus.yml. Проверьте запрос во вкладке Explore: если там данные есть, проблема в настройках панели.

Как долго Prometheus хранит метрики?

По умолчанию 15 дней. Срок меняется флагом --storage.tsdb.retention.time, например 30d или 90d, а объём можно ограничить флагом --storage.tsdb.retention.size. Для хранения на годы используют внешние хранилища вроде VictoriaMetrics, Thanos или Mimir.

Нужен ли Alertmanager, если в Grafana есть свои алерты?

Не обязательно: Grafana Alerting умеет слать уведомления сама. Связка правил Prometheus и Alertmanager удобнее тем, что правила лежат в файлах рядом с конфигом, проверяются promtool и версионируются в git, а алерты продолжают работать, даже если Grafana недоступна.

Как мониторить сайт, а не только сервер?

Добавьте blackbox_exporter: он проверяет HTTP-коды, время ответа и срок действия TLS-сертификата снаружи. Метрики самого приложения отдают его собственные экспортеры, например nginx-prometheus-exporter или postgres_exporter.

Вернуться в блог