Мониторинг как код: правила Prometheus и дашборды Grafana
Мониторинг как код: полное руководство
мониторинг сайтов как код (Monitoring as Code, MaC) применяет принципы инфраструктуры как кода к наблюдаемости. Вместо ручной настройки дашбордов, алертов и записывающих правил через веб-интерфейсы, вся конфигурация мониторинга определяется в версионируемых файлах, проверяется через пулл-реквесты и развёртывается через CI/CD-пайплайны.
Зачем мониторинг как код?
Ручная настройка мониторинга создаёт хрупкие, недокументированные системы наблюдаемости, которые сложно воспроизвести, проверить и поддерживать. Кодификация конфигурации мониторинга решает эти проблемы.
Ключевые преимущества
- Воспроизводимость — настройка мониторинга может быть надёжно воссоздана в различных средах
- Контроль версий — все изменения отслеживаются, проверяются и обратимы
- Единообразие — стандартизированные шаблоны уменьшают расхождение конфигураций между командами
- Автоматизация — мониторинг развёртывается вместе с кодом приложения через CI/CD
- Восстановление после сбоев — весь стек мониторинга может быть восстановлен из кода
- Обмен знаниями — конфигурационные файлы служат живой документацией
Записывающие правила Prometheus
Записывающие правила (recording rules) предварительно вычисляют часто используемые или ресурсоёмкие выражения PromQL и сохраняют результат как новые временные ряды. Это снижает нагрузку на Prometheus и ускоряет отрисовку дашбордов.
Конфигурация записывающих правил
# recording-rules.yml
groups:
- name: http_request_rates
interval: 30s
rules:
- record: job:http_requests:rate5m
expr: sum(rate(http_requests_total[5m])) by (job)
labels:
aggregation: "rate5m"
- record: job:http_request_duration:p99
expr: histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, job))
- record: job:http_errors:ratio5m
expr: |
sum(rate(http_requests_total{status=~"5.."}[5m])) by (job)
/
sum(rate(http_requests_total[5m])) by (job)
Лучшие практики записывающих правил
- Следуйте соглашению об именовании:
level:metric:operations(например,job:http_requests:rate5m) - Создавайте записывающие правила только для выражений, используемых в нескольких дашбордах или алертах
- Устанавливайте подходящие интервалы вычисления, соответствующие интервалам сбора метрик
- Документируйте назначение каждого правила комментариями
- Тестируйте правила в staging-среде перед развёртыванием в продакшен
Правила алертинга Prometheus
Правила алертинга определяют условия, при которых отправляются уведомления, когда метрики превышают пороговые значения. Хорошо спроектированные алерты действенны, правильно ограничены и содержат достаточный контекст для ответственных.
Конфигурация правил алертинга
# alerting-rules.yml
groups:
- name: application_alerts
rules:
- alert: HighErrorRate
expr: job:http_errors:ratio5m > 0.05
for: 5m
labels:
severity: critical
team: backend
annotations:
summary: "Высокий процент ошибок HTTP на {{ $labels.job }}"
description: "Уровень ошибок: {{ $value | humanizePercentage }} для задачи {{ $labels.job }}"
runbook: "https://wiki.internal/runbooks/high-error-rate"
- alert: HighLatency
expr: job:http_request_duration:p99 > 2.0
for: 10m
labels:
severity: warning
team: backend
annotations:
summary: "Высокая задержка p99 на {{ $labels.job }}"
description: "Задержка p99: {{ $value }}с для задачи {{ $labels.job }}"
- alert: PodCrashLooping
expr: rate(kube_pod_container_status_restarts_total[15m]) * 60 * 5 > 0
for: 15m
labels:
severity: warning
team: platform
annotations:
summary: "Под {{ $labels.namespace }}/{{ $labels.pod }} в цикле перезапусков"
Принципы проектирования алертов
- Алерты на симптомы, не на причины — оповещайте о видимом пользователю влиянии (высокая задержка, ошибки), а не о внутренних метриках
- Используйте обоснованные пороги — устанавливайте пороги на основе целей SLO и исторических данных
- Указывайте длительность (for) — требуйте сохранения условия перед срабатыванием для избежания мерцания
- Предоставляйте контекст — аннотации должны содержать ссылки на ранбуки, дашборды и текущие значения
- Устанавливайте правильную критичность — различайте critical (вызов дежурного) и warning (следующий рабочий день)
Дашборды Grafana как код
Дашборды Grafana можно определять как JSON или генерировать программно с помощью инструментов вроде Grafonnet (библиотека Jsonnet) или Terraform-провайдера Grafana. Это обеспечивает единообразие, версионирование и автоматическое развёртывание дашбордов.
Структура JSON дашборда
{
"dashboard": {
"title": "Application Overview",
"uid": "app-overview",
"tags": ["application", "production"],
"timezone": "utc",
"refresh": "30s",
"panels": [
{
"title": "Request Rate",
"type": "timeseries",
"gridPos": { "h": 8, "w": 12, "x": 0, "y": 0 },
"targets": [
{
"expr": "job:http_requests:rate5m",
"legendFormat": "{{ job }}"
}
]
}
]
}
}
Провизионирование дашбордов
# grafana/provisioning/dashboards/default.yml
apiVersion: 1
providers:
- name: default
orgId: 1
folder: "Application"
type: file
disableDeletion: false
updateIntervalSeconds: 30
allowUiUpdates: false
options:
path: /var/lib/grafana/dashboards
foldersFromFilesStructure: true
Интеграция с CI/CD-пайплайном
Конфигурация мониторинга должна проверяться и развёртываться через тот же CI/CD-пайплайн, что и код приложения.
Пайплайн валидации
# .github/workflows/monitoring.yml
name: Monitoring Validation
on: [pull_request]
jobs:
validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Validate Prometheus rules
run: promtool check rules monitoring/rules/*.yml
- name: Validate alerting rules
run: promtool check rules monitoring/alerts/*.yml
- name: Unit test rules
run: promtool test rules monitoring/tests/*.yml
- name: Validate Grafana dashboards
run: |
for f in monitoring/dashboards/*.json; do
python -m json.tool "$f" > /dev/null
done
Тестирование конфигурации мониторинга
Prometheus предоставляет встроенную поддержку тестирования правил алертинга и записи с помощью юнит-тестов, определённых в YAML-файлах.
Юнит-тесты правил
# tests/alert-tests.yml
rule_files:
- ../alerts/application.yml
evaluation_interval: 1m
tests:
- interval: 1m
input_series:
- series: 'http_requests_total{job="api", status="500"}'
values: "0+10x20"
- series: 'http_requests_total{job="api", status="200"}'
values: "0+100x20"
alert_rule_test:
- eval_time: 10m
alertname: HighErrorRate
exp_alerts:
- exp_labels:
severity: critical
team: backend
job: api
Структура директорий
Организуйте конфигурацию мониторинга в понятной, поддерживаемой структуре директорий рядом с кодом приложения.
monitoring/
rules/
recording-http.yml
recording-database.yml
alerts/
application.yml
infrastructure.yml
business.yml
dashboards/
application/
overview.json
api-details.json
infrastructure/
nodes.json
kubernetes.json
tests/
alert-tests.yml
recording-tests.yml
provisioning/
dashboards.yml
datasources.yml
Заключение
Мониторинг как код трансформирует наблюдаемость из хрупкого ручного процесса в надёжную, проверяемую и автоматизированную практику. Определяя правила Prometheus и дашборды Grafana в версионируемых файлах, команды получают единообразие, воспроизводимость и возможность развивать мониторинг параллельно с приложениями. Начните с кодификации наиболее критичных алертов и дашбордов, валидируйте их в CI и постепенно расширяйте покрытие по мере развития практики.
Проверьте ваш сайт прямо сейчас
Проверить →