Наблюдаемость: метрики, алерты, логи / Итоговая лаба

Вторая машина без присмотра

~75 мин

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

Ситуация

Неделю назад вторую машину, node2, поставили под присмотр node1 и закрыли заявку. На node1 работают Prometheus, Alertmanager и сборщик логов rsyslog. Уведомления дежурным Alertmanager шлёт в учебный webhook lab-webhook: каждое полученное уведомление он дописывает строкой в /var/lib/lab-webhook/notifications.jsonl.

Вчера node2 полчаса не отвечал, и дежурным ничего не пришло. Когда стали разбираться, выяснилось больше: Prometheus на node1 метрик node2 не видит, а свежих логов node2 на сборщике нет.

node1 — твой терминал. Команды на node2 выполняй через SSH: ssh node2 'команда' или войди в оболочку — ssh node2, назад — exit. sudo на обеих машинах работает без пароля. Браузера к машинам нет: Prometheus и Alertmanager смотри из терминала — curl -s localhost:9090/api/v1/… | jq, promtool query instant http://localhost:9090 '<выражение>', amtool alert.

Задача

Prometheus на node1 собирает метрики node2: цель node2:9100 в задании node — в состоянии up.
Когда node2 перестаёт отвечать, алерт NodeDown о нём (instance="node2:9100") не позже чем через минуту переходит в firing. Пока node2 работает, NodeDown о нём не горит.
Уведомление о сработавшем NodeDown доходит до дежурных — новой строкой в /var/lib/lab-webhook/notifications.jsonl.
Логи node2 собираются на node1: строка, отправленная на node2 командой logger, появляется в файле в каталоге /var/log/remote/node2/ на node1.

«Проверить» само ненадолго останавливает экспортёр на node2 (prometheus-node-exporter), отправляет с node2 строку logger -t lab-verify … и возвращает всё как было. Проверка ждёт алерт и строку и занимает до полутора минут.

Ограничения

Всё должно пережить перезагрузку обеих машин: службы включены, настройки лежат в файлах, а работающие службы перечитали эти файлы после правки.
Межсетевой экран на node2 не выключай — открой в нём только то, что нужно для наблюдения. SSH с node1 на node2 не закрывай: другого входа на node2 нет.
Учебный webhook lab-webhook и его файл не трогай.

Интернета в лабе нет — только сеть между node1 и node2, всё нужное установлено. Иди по каждой цепочке от начала до конца и после каждой правки смотри на результат тем же способом, каким его видит проверка: цели — curl -s localhost:9090/api/v1/targets | jq, алерты — curl -s localhost:9090/api/v1/alerts | jq и amtool alert, уведомления — tail /var/lib/lab-webhook/notifications.jsonl, логи — logger на node2 и sudo ls -R /var/log/remote/ на node1.

Цели лабы

0 из 4

Prometheus на node1 собирает метрики node2 — цель node2:9100 в задании node в состоянии up; межсетевой экран node2 включён, и всё это переживёт перезагрузку — ещё не проверялась
Когда node2 перестаёт отвечать, алерт NodeDown о нём не позже чем через минуту в firing, а пока node2 работает — не горит; правило загружено из файла — ещё не проверялась
Уведомление о сработавшем NodeDown доходит до дежурных — в учебный webhook на node1; Prometheus и Alertmanager работают с настройками из своих файлов — ещё не проверялась
Строка logger с node2 появляется на node1 в /var/log/remote/node2/; rsyslog на обеих машинах работает с настройками из файлов и запустится сам — ещё не проверялась

Подсказки

открыто 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.