pngr 0.2: алерты, аналитика и Статус Страницы прямо из терминала

Чуть больше года назад мы выпустили pngr — CLI, чтобы управлять мониторингом, не выходя из консоли. Тогда он умел в основном создавать и запускать проверки. В версии 0.2.0 CLI дотянулся до всего, ради чего раньше приходилось открывать браузер: аналитики, алертов и Статус Страниц. А ещё он стал по-настоящему удобным для скриптов и CI/CD.

Обновиться (нужен Python 3.10+):

pip install -U pingera-cli
pngr --version

Посмотрите, как это выглядит

Ниже — настоящий вывод pngr 0.2.0 на демо-данных. Переключайте вкладки, а кнопкой «Копировать команды» можно забрать команды к себе в терминал.

Аналитика проверок без браузера

Четыре новые команды отвечают на вопрос «а как оно работало?»:

• pngr checks uptime — аптайм, среднее время ответа и полоска статусов по часам. С --hourly — ещё и таблица по каждому часу.
• pngr checks status-history — когда проверка падала, деградировала и сколько это длилось.
• pngr checks response-times — среднее, p95 и p99 по регионам. С --buckets — разбивка по интервалам.
• pngr checks stats — сколько результатов было ok/failed/degraded/timeout и success rate по регионам. Работает для одной проверки или для всех сразу, умеет фильтровать по типу, по запускам по требованию (--result-type on_demand) и по наличию алертов.

Периоды задаются как ISO-дата или относительно: --from 30m, --from 24h, --from 7d, --from 2w.

Cron-расписание

Проверку теперь можно запускать не только раз в N секунд, но и по cron-выражению — например, только в рабочие часы:

pngr checks create --name "Отчёты в рабочие часы" --type web \
  --url https://example.com/reports --cron "*/10 9-18 * * 1-5"

# и обратно на обычный интервал
pngr checks update <check-id> --interval 300

Алерты целиком из терминала

Раньше алерты настраивались только в веб-интерфейсе. Теперь в CLI есть всё:

• Каналы — pngr alerts channels: email, webhook, Telegram, MAX, SMS и statuspage — канал, который сам меняет статус компонента на вашей Статус Странице, пока алерт активен. Флаг --test сразу шлёт тестовое уведомление, а pngr alerts channels test проверяет даже несохранённую конфигурацию. Секреты в выводе маскируются.
• Правила — pngr alerts rules: условие срабатывания, сколько регионов должно упасть, важность, пауза между повторными уведомлениями и автозакрытие. При обновлении меняются только переданные поля, а disable ставит правило на паузу без удаления (enable — включает обратно).
• Сработавшие алерты — pngr alerts list/get/ack/resolve, журнал доставки уведомлений по каналам (notifications) и сводка (stats).

CLI проверяет правило так же, как бэкенд, поэтому ошибка в параметрах всплывёт до запроса к API, с понятным сообщением про конкретный флаг. Соберите своё правило:

Статус Страницы: инциденты, постмортемы и плановые работы

Группа pngr pages выросла почти до паритета с веб-интерфейсом:

• группы компонентов, статусы компонентов и отчёты об их аптайме;
• апдейты инцидентов — с изменением статусов компонентов и уведомлением подписчиков;
• постмортемы: черновик из файла (postmortem set --file) и публикация (postmortem publish);
• log-past — задним числом занести инцидент, который уже закончился;
• schedule-maintenance — плановые работы с автостартом, автозавершением и напоминаниями подписчикам;
• пароли страниц, свой домен для писем и шаблоны.

Самый практичный сценарий — объявлять работы прямо из пайплайна деплоя, чтобы никто не забыл:

# .github/workflows/deploy.yml (фрагмент)
- name: Объявляем плановые работы
  env:
    PINGERA_API_KEY: ${{ secrets.PINGERA_API_KEY }}
  run: |
    pip install pingera-cli
    pngr pages incidents schedule-maintenance -p "$PAGE_ID" \
      --name "Обновление базы данных" --start +15m --end +1h \
      --component-id "$DB_COMPONENT_ID" --notify

Компоненты сами перейдут в статус «на обслуживании» в начале окна и вернутся в «работает» в конце.

Удобно для скриптов

Мы прошлись по выводу во всех командах:

• В режиме -o json или -o yaml в stdout попадают только данные, а панели, подсказки и ошибки уходят в stderr. Вывод можно смело отдавать в jq.
• Команды create и update возвращают созданный объект целиком, вместе с id, поэтому шаги легко склеиваются:

CHANNEL_ID=$(pngr -o json alerts channels create --name "On-call" \
  --email oncall@example.com | jq -r '.id')

pngr alerts rules create --name "API down" --check "$CHECK_ID" \
  --count 3 --channel "$CHANNEL_ID"

• Правила и каналы принимают --from-file в JSON или YAML, а флаги поверх файла переопределяют его поля. Вывод get -o json подходит как шаблон, так что настройки алертов можно хранить в репозитории рядом с кодом. Это ещё один шаг к monitoring as code.
• Ошибки в аргументах завершаются с кодом 2, ошибки API — с кодом 1, так что скрипт в CI честно упадёт.

Под капотом

CLI переехал на Python SDK 1.2 — типизированный и сгенерированный из исправленной OpenAPI-спецификации. Заодно мы починили накопившееся: pages update больше не падает, checks assign-group учитывает настроенный base_url, а флаги -o и --verbose больше не записываются в конфиг при каждом запуске.

Попробуйте

Из крупного в CLI пока нет heartbeat-проверок — их можно настроить в веб-интерфейсе или через SDK. Полный список команд есть в документации и в репозитории на GitHub. Если чего-то не хватает или что-то сломалось — заводите issue, мы читаем всё.