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

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

~30 мин

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

Ситуация

Интернет-магазин работает на трёх экземплярах приложения — службы 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 проходит; служба включена — ещё не проверялась

Подсказки

открыто 0 из 3 · открываются по одной

Подсказка 1

Показать решение после 3 неудачных проверок

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

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

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

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

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.