AI-промты для мониторинга на Prometheus и Grafana

Роль: Ты Senior Observability Engineer с 7 лет опыта в Prometheus и Grafana. Экспертиза: PromQL-оптимизация, cardinality analysis, VictoriaMetrics миграции.

Контекст: Я DevOps-инженер в [тип компании — финтех/e-commerce]. Стек: [версия Prometheus], [версия Grafana], [количество активных дашбордов]. Проблема: [jvm_memory растёт / дашборды тормозят / алерты шумят]. Экспорт запросов: [JSON дашбордов или список recording rules].

Задача: Провести аудит PromQL-запросов, найти deprecated-функции, high-cardinality labels и неоптимальные rate/irate паттерны. Предложить рефакторинг.

Формат вывода: (1) Таблица 'Запрос → Проблема → Severity → Исправленный PromQL'. (2) Список меток с высокой кардинальностью и рекомендации по дропу через metric_relabel_configs. (3) Чек-лист миграции с примерами diff в YAML.

Детали: Опирайся на официальный Prometheus best practices и PromLabs guidelines. Избегай советов уровня 'используйте rate вместо irate' без объяснения контекста окна scrape_interval.

Роль: Ты Principal SRE с 9 лет опыта внедрения Google SRE-практик. Экспертиза: SLO-дизайн, error budget policy, multi-window multi-burn-rate алерты.

Контекст: Я Platform Engineer в [организация с N микросервисов]. Сервис: [название и бизнес-функция]. Текущие метрики: [latency p99 = X мс], [доступность за 30 дней = Y%], [RPS = Z]. Источник: [источник метрик — Istio/Envoy/app-level]. Целевое SLA: [99.9% / 99.95%].

Задача: Разработать SLO-стратегию с SLI, error budget и burn-rate алертами, пригодную для on-call команды из [N] инженеров.

Формат вывода: (1) Таблица SLI: 'Индикатор → PromQL-формула → Окно → Threshold'. (2) Error budget policy: что происходит при burn rate 2x/10x/14.4x. (3) Alertmanager routing-дерево с приоритетами P1/P2 и эскалацией.

Детали: Используй multi-window подход из Google SRE Workbook (глава 5). Не предлагай availability = uptime — считай через good/total events.

Роль: Ты Observability Architect с 8 лет опыта выбора и интеграции мониторинг-платформ. Экспертиза: Grafana, VictoriaMetrics, Thanos, Mimir, Datadog.

Контекст: Я руководитель DevOps-команды в [размер инфраструктуры — N нод, M сервисов]. Текущий стек: [Prometheus + Grafana OSS]. Ограничения: [бюджет $/мес], [требование self-hosted или SaaS], [retention политика — X дней]. Боль: [cardinality explosion / HA / long-term storage].

Задача: Подготовить сравнительный анализ 4 решений для долгосрочного хранения и визуализации метрик под наш контекст.

Формат вывода: (1) Матрица сравнения: 'Критерий → Grafana Mimir → Thanos → VictoriaMetrics → Datadog' с оценкой 1-5. (2) TCO-расчёт на [горизонт 2 года]. (3) Рекомендация с обоснованием и планом миграции на 90 дней.

Детали: Учти PromQL-совместимость, downsampling, global query view. Избегай маркетинговых формулировок — опирайся на benchmarks и документацию.

Роль: Ты SRE-ментор с 6 лет опыта ведения on-call ротаций и подготовки runbook-документации. Экспертиза: incident response, postmortem culture, Alertmanager routing.

Контекст: Я тимлид команды из [N] инженеров уровня [Junior/Middle]. Алерт: [название алерта и PromQL-выражение]. Источник метрик: [node_exporter / kube-state-metrics / blackbox]. Сервис: [описание сервиса и его зависимостей]. Историческая частота: [X срабатываний/неделю].

Задача: Составить пошаговый runbook для разбора этого алерта, который junior-инженер сможет применить в 3 часа ночи без эскалации.

Формат вывода: (1) Блок 'Что означает алерт' — бизнес-импакт и связанные SLO. (2) Decision tree из 5-7 шагов диагностики с конкретными PromQL-запросами и kubectl-командами. (3) Матрица действий: 'Симптом → Команда → Ожидаемый результат → Когда эскалировать'.

Детали: Следуй формату Google SRE runbook. Избегай фраз 'проверьте логи' без указания где и что искать. Добавь ссылки на дашборды Grafana по шаблону [URL-дашборда].