Мониторинг 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_exporter | 9100 | На каждом сервере | Только IP Prometheus |
| Prometheus | 9090 | Сервер мониторинга | localhost и Grafana |
| Alertmanager | 9093 | Рядом с Prometheus | localhost |
| Grafana | 3000 | Рядом с Prometheus | Через Nginx с HTTPS и паролем |
Что подготовить перед установкой?
Для обучения и мониторинга до пяти серверов хватит VPS с 1 vCPU, 2 ГБ памяти и 20 ГБ диска. Если сервер один и некритичный, всё можно поставить прямо на него. Но держите в голове главный недостаток такой схемы: упал сервер — упал и мониторинг, и сообщение о падении отправить некому. Для продакшена Prometheus и Alertmanager выносят на отдельную маленькую машину, а на рабочие серверы ставят только node_exporter.
Перед началом проверьте три вещи:
- Часы синхронизированы. Prometheus очень чувствителен к расхождению времени:
timedatectlдолжен показыватьSystem clock synchronized: yes. Если нет —sudo apt install systemd-timesyncd. - Фаервол включён. Все примеры ниже рассчитаны на ufw. Если сервер новый, сначала пройдите чеклист базовой защиты Linux-сервера.
- Есть место под данные. 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 вы ещё не работали, начните с нашего гида по контейнерам.
Дальше по шагам:
- Откройте
http://localhost:3000(через туннель), войдите какadmin/adminи сразу смените пароль. - Connections → Data sources → Add data source → Prometheus. URL:
http://localhost:9090(илиhttp://host.docker.internal:9090для Grafana в контейнере). Нажмите Save & test — должно появиться сообщение об успешном запросе к API. - 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 + Grafana | Zabbix | Netdata |
|---|---|---|---|
| Модель сбора | Pull по HTTP | Агент, активный и пассивный режим, SNMP | Агент собирает локально, раз в секунду |
| Хранение | Своя TSDB | PostgreSQL или MySQL | Локальная база на каждом хосте |
| Запросы и графики | PromQL, дашборды в Grafana | Встроенный веб-интерфейс, шаблоны | Готовые дашборды без настройки |
| Сильная сторона | Контейнеры, Kubernetes, метрики приложений | Парк серверов и сетевое оборудование | Быстро понять, что происходит на одном хосте |
| Порог входа | Средний: YAML и PromQL | Средний: много сущностей в интерфейсе | Низкий: поставил и смотришь |
| Конфигурация как код | Всё в текстовых файлах | В основном через интерфейс и API | Файлы, но обычно не нужны |
Практический ориентир: для одного сервера «посмотреть, что тормозит» удобен Netdata. Для десятков однотипных серверов, коммутаторов и принтеров в офисе привычнее Zabbix. Если у вас контейнеры, микросервисы или вы хотите собирать метрики самого приложения — количество заказов, время ответа API, длину очереди, — выбирайте Prometheus: под него есть экспортеры почти для всего, от Nginx до PostgreSQL, а многие программы отдают метрики в его формате сами.
Почему target в статусе DOWN и другие частые ошибки
- connection refused. Экспортер не запущен или слушает другой адрес. Проверьте
systemctl status prometheus-node-exporterиss -tlnp | grep 9100. Частая причина — экспортер привязан к 127.0.0.1, а Prometheus стучится по внешнему IP. - context deadline exceeded. Пакеты молча отбрасываются фаерволом — на сервере с экспортером или у провайдера. Проверьте с сервера мониторинга:
curl -m 5 http://10.0.0.11:9100/metrics | head. - В Grafana «No data». Неверный источник данных в дашборде, слишком узкий диапазон времени или переменная
jobдашборда не совпадает с именем job в конфиге. Запустите тот же запрос в Explore: если данные там есть, дело в настройках панели. - Предупреждение о расхождении времени. Часы браузера или сервера ушли. Проверьте
timedatectlна всех машинах. - Prometheus не стартует после правки. Ошибка в YAML — чаще всего табы вместо пробелов или сбитый отступ. Ответ покажут
promtool check configиjournalctl -u prometheus -n 50. - Алерт firing, а сообщения нет. Посмотрите вкладку Status в Alertmanager (
localhost:9093) и его журнал: обычно это неверный chat_id, бот не добавлен в чат или у файла с токеном не те права. - Диск сервера мониторинга заполнился. Не задан
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.