Наблюдаемость: метрики, алерты, логи / Ступень 5 из 9

Alertmanager: кому и сколько раз

Не запущена Запускается обычно ~20 с

Шаг 5 из 6 · лаба · 30 мин

Алерты не доходят до получателя

Ночью два экземпляра интернет-магазина лежали двадцать минут. Prometheus видел это, алерт горел — а команда, которая отвечает за магазин, не получила ни одного уведомления. Найди, где теряются алерты, и сделай так, чтобы команда узнавала об упавших экземплярах одним сообщением.

Ситуация

Интернет-магазин работает на трёх экземплярах приложения — службы lab-shop@1, lab-shop@2 и lab-shop@3, адреса 127.0.0.1:8001–8003. Prometheus собирает их метрики, и когда экземпляр перестаёт отвечать, правило ShopInstanceDown зажигает алерт с метками team="web" и severity="critical". Алерты Prometheus отдаёт Alertmanager на этой же машине (/etc/prometheus/alertmanager.yml), а тот рассылает уведомления.

Получатели — учебный webhook на 127.0.0.1:5001, путь в адресе различает получателя: /web — канал команды web (получатель web-team), /pager — телефон дежурного, /ops — общий канал администраторов. Каждое уведомление — строка JSON в /var/lib/lab-webhook/notifications.jsonl.

Ночью экземпляры 2 и 3 лежали двадцать минут. Команде web не пришло ничего.

Повторить ночь можно: sudo systemctl stop lab-shop@2 lab-shop@3, подождать секунд сорок и вернуть их — sudo systemctl start lab-shop@2 lab-shop@3. Адрес Alertmanager amtool уже знает. sudo работает без пароля.

Задача

Алерты ShopInstanceDown с метками team="web" и severity="critical" приходят команде web — в /web.
Когда падают два экземпляра сразу, команда web получает их одним уведомлением — одной группой.
Остальные критичные алерты по-прежнему уходят дежурному — получателю pager.
Настройки записаны в /etc/prometheus/alertmanager.yml, Alertmanager перечитал файл после последней правки, а amtool check-config проходит. Служба Alertmanager включена.

Проверка сама останавливает два экземпляра магазина, ждёт уведомления до минуты и запускает их снова. Правило ShopInstanceDown и сами экземпляры чинить не нужно.

Лаба · самостоятельно

Команды в этой лабе не даны: набирай их в терминале сам. Цели проверяются на машине после каждой команды.

Цели

0 из 4

Алерты ShopInstanceDown с метками team="web" и severity="critical" приходят команде web — в /web учебного webhook — ещё не выполнена
Когда падают два экземпляра сразу, команда web получает их одним уведомлением — одной группой — ещё не выполнена
Остальные критичные алерты по-прежнему уходят дежурному — получателю pager — ещё не выполнена
Настройки записаны в /etc/prometheus/alertmanager.yml, Alertmanager перечитал файл после последней правки, amtool check-config проходит; служба включена — ещё не выполнена

Ctrl+Enter

Запустит машину node1 · Ubuntu 24.04

Машина запускается

Подсказки

0 из 3

Сообщить о проблеме

Цели лабы

0 из 4

Алерты ShopInstanceDown с метками team="web" и severity="critical" приходят команде web — в /web учебного webhook — ещё не выполнена
Когда падают два экземпляра сразу, команда web получает их одним уведомлением — одной группой — ещё не выполнена
Остальные критичные алерты по-прежнему уходят дежурному — получателю pager — ещё не выполнена
Настройки записаны в /etc/prometheus/alertmanager.yml, Alertmanager перечитал файл после последней правки, amtool check-config проходит; служба включена — ещё не выполнена

node1 Ubuntu 24.04

Для запуска машины нужен вход

Машина запускается на твой аккаунт, там же хранится прогресс. Читать можно без входа.

После входа вернёшься на эту лабу.

Цели лабы

0 из 4

Алерты ShopInstanceDown с метками team="web" и severity="critical" приходят команде web — в /web учебного webhook — ещё не выполнена
Когда падают два экземпляра сразу, команда web получает их одним уведомлением — одной группой — ещё не выполнена
Остальные критичные алерты по-прежнему уходят дежурному — получателю pager — ещё не выполнена
Настройки записаны в /etc/prometheus/alertmanager.yml, Alertmanager перечитал файл после последней правки, amtool check-config проходит; служба включена — ещё не выполнена

Наблюдаемость · подобрано по лабе

Prometheus: сбор метрик и правила алертов

Шпаргалка

$_ — вставить в терминал

sudo systemctl enable --now prometheus включить
promtool check config /etc/prometheus/prometheus.yml проверить
sudo systemctl reload prometheus перечитать конфиг
curl -s localhost:9090/-/ready готов ли сервер
promtool query instant http://localhost:9090 up кого собирает
curl -s localhost:9090/api/v1/targets | jq .data цели и ошибки
curl -s localhost:9090/api/v1/rules | jq .data правила
curl -s localhost:9090/api/v1/alerts | jq .data алерты
promtool check rules /etc/prometheus/disk.rules.yml файл правил

prometheus.yml

Конфиг пакета на учебной машине, без комментариев:

yaml

global:
  scrape_interval:     15s
  evaluation_interval: 15s
  external_labels:
      monitor: 'example'
alerting:
  alertmanagers:
  - static_configs:
    - targets: ['localhost:9093']
rule_files:
scrape_configs:
  - job_name: 'prometheus'
    scrape_interval: 5s
    scrape_timeout: 5s
    static_configs:
      - targets: ['localhost:9090']
  - job_name: node
    static_configs:
      - targets: ['localhost:9100']

Раздел	Что задаёт
`global`	интервалы сбора и вычисления правил по умолчанию; `external_labels` — метки, которые получит каждый алерт
`alerting`	адрес Alertmanager
`rule_files`	файлы правил; в пакете список пуст — правил нет
`scrape_configs`	что собирать: задания и их цели

Задания и цели

Задание (job) — группа одинаковых целей с общими настройками сбора:

yaml

scrape_configs:
  - job_name: node
    static_configs:
      - targets: ['localhost:9100', 'node2:9100']
  - job_name: app
    scrape_interval: 5s
    metrics_path: /metrics
    static_configs:
      - targets: ['127.0.0.1:8000']
        labels:
          team: web

Каждому ряду цели Prometheus добавляет метки job (имя задания) и instance (адрес из targets); метки из labels — тоже, ко всем рядам целей этого блока: up{instance="127.0.0.1:8000", job="app", team="web"}. metrics_path по умолчанию /metrics, scrape_timeout — 10 секунд. Интервал, заданный в задании, сильнее глобального.

labels пишется внутри элемента static_configs, рядом с targets. На уровне задания такого поля нет: promtool check config ответит field labels not found in type config.ScrapeConfig. Метки из global.external_labels — другое: их получают только данные, которые уходят наружу (алерты в Alertmanager, удалённое хранилище), в запросах к самому Prometheus их нет.

Перечитать конфиг

bash

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

reload посылает службе сигнал HUP, и Prometheus перечитывает конфиг и файлы правил без перезапуска. Способ через HTTP, curl -X POST localhost:9090/-/reload, на учебной машине выключен: ответ — Lifecycle API is not enabled..

Принял ли сервер конфиг:

в журнале journalctl -u prometheus -o cat | tail -3 — строка Completed loading of configuration file или Error reloading config;
метрика prometheus_config_last_reload_successful — 1 или 0 (она обновляется со следующим сбором задания prometheus, через несколько секунд);
/api/v1/status/config и /api/v1/rules показывают то, что загружено на самом деле.

systemctl reload выходит с кодом 0 и при битом файле: сигнал доставлен, а принять конфиг или нет, Prometheus решает уже сам. Плохой конфиг при reload не применяется: сервер работает со старым. При restart с плохим конфигом служба не запустится.

bash

curl -s localhost:9090/metrics | grep '^prometheus_config_last_reload'

Ключи запуска

Ключи службы — переменная ARGS в /etc/default/prometheus, в пакете пустая. Нужные чаще других:

Ключ	Что задаёт
`--storage.tsdb.retention.time=30d`	сколько хранить данные (по умолчанию 15 дней)
`--web.enable-lifecycle`	включает `/-/reload` и `/-/quit` по HTTP
`--web.listen-address=127.0.0.1:9090`	адрес и порт (по умолчанию `0.0.0.0:9090`)

Ключи применяет sudo systemctl restart prometheus. С какими ключами сервер работает сейчас — /api/v1/status/flags.

Добавить цель и убедиться, что её собирают

bash

sudoedit /etc/prometheus/prometheus.yml   # цель в targets
promtool check config /etc/prometheus/prometheus.yml
sudo systemctl reload prometheus
sleep 20
promtool query instant http://localhost:9090 'up{job="app"}'

Ждать нужно хотя бы один интервал сбора. => 1 — цель собирается, => 0 — Prometheus до неё не достучался, причина — в lastError.

Проверить порог до того, как писать правило

bash

promtool query instant http://localhost:9090 \
  'node_filesystem_avail_bytes / node_filesystem_size_bytes < 0.05'

Выражение правила — обычный запрос. Пустой ответ — сейчас алерт бы не загорелся; ряды в ответе — алерты, которые загорелись бы, по одному на ряд.

Сверить загруженное с файлом

bash

curl -s localhost:9090/api/v1/status/config \
  | jq -r .data.yaml | grep -A6 'job_name: app'
curl -s localhost:9090/api/v1/rules \
  | jq -r '.data.groups[].rules[].name'

Загруженный конфиг сервер печатает с подставленными значениями по умолчанию (honor_timestamps, scheme), поэтому сравнивай нужные поля, а не файлы целиком.

Цель down

Причину называет lastError цели, что значит каждая ошибка — в таблице раздела prometheus. Сравни scrapeUrl с тем, что слушает служба: ss -tlnp на машине цели и curl по тому же адресу. Подробнее про экспортёр — node-exporter, node-exporter и node-exporter.

Error reloading config

text

level=error msg="Error reloading config" err="couldn't load
  configuration (--config.file=\"/etc/prometheus/prometheus.yml\"):
  parsing YAML file
  /etc/prometheus/prometheus.yml: yaml: line 44: did not find expected
  ',' or ']'"

reload не применил новый конфиг, сервер работает со старым, prometheus_config_last_reload_successful — 0. Исправь ошибку, проверь promtool check config и сделай reload снова.

error loading rules, previous rule set restored

В файле правил ошибка, и после reload остались прежние правила: /api/v1/rules показывает старый набор. Что не так — promtool check rules <файл>:

text

  FAILED:
/tmp/bad.yml: 5:15: group "demo", rule 1, "DiskAlmostFull": could not
  parse expression: 1:47: parse error: unexpected <op:<>

Служба не запускается после restart

text

level=error msg="Error loading config (--config.file=…)"
  err="parsing YAML file /etc/prometheus/prometheus.yml: …"

С плохим конфигом Prometheus не стартует, systemctl is-active — failed. Исправь, проверь promtool check config, затем sudo systemctl reset-failed prometheus и start.

field … not found in type config.plain

text

  FAILED: parsing YAML file /tmp/p.yml: yaml: unmarshal errors:
  line 26: field scrape_config not found in type config.plain

Неизвестный ключ: здесь scrape_config вместо scrape_configs. Другие частые опечатки — static_config, target, job вместо job_name. Ключ может быть и верным, но не на своём уровне: field labels not found in type config.ScrapeConfig — labels записан в задании, а место ему внутри static_configs (prometheus).

did not find expected ',' or ']'

Ошибка синтаксиса YAML: незакрытая скобка в targets: ['…', кавычка или отступ. Номер строки — в сообщении.

Правило есть в файле, а /api/v1/rules пуст

файла нет в rule_files — в конфиге пакета этот список пуст;
путь не тот: относительный путь считается от каталога prometheus.yml, а promtool check config пишет, сколько файлов правил нашёл (SUCCESS: 1 rule files found);
после правки не было reload или он не удался — см. prometheus.

Алерт не загорается

правило загружено, state — inactive: выполни expr через promtool query instant. Пусто — условие сейчас ложно: перепутан знак (> вместо <), порог в процентах против доли или метка с опечаткой;
алерт застрял в pending: for ещё не прошёл или условие то выполняется, то нет, и отсчёт начинается заново;
алерт firing, а уведомления нет — дальше alertmanager.

Lifecycle API is not enabled

Ответ на curl -X POST localhost:9090/-/reload: Prometheus запущен без --web.enable-lifecycle. Перечитывай sudo systemctl reload prometheus.

query error: connection refused

text

query error: Post "http://localhost:9090/api/v1/query": dial tcp
  127.0.0.1:9090: connect: connection refused

promtool query не достучался до сервера: Prometheus не запущен — systemctl status prometheus.

restart с непроверенным конфигом

reload с ошибкой оставляет старый конфиг, restart с ошибкой оставляет машину без мониторинга: служба не поднимется, метрики не собираются, алерты не вычисляются. Перед любым restart — promtool check config.