Перейти к содержимому
Skip to content
← Все статьи

Мониторинг как код: правила Prometheus и дашборды Grafana

Мониторинг как код: полное руководство

мониторинг сайтов как код (Monitoring as Code, MaC) применяет принципы инфраструктуры как кода к наблюдаемости. Вместо ручной настройки дашбордов, алертов и записывающих правил через веб-интерфейсы, вся конфигурация мониторинга определяется в версионируемых файлах, проверяется через пулл-реквесты и развёртывается через 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)

Лучшие практики записывающих правил

Правила алертинга 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 }} в цикле перезапусков"

Принципы проектирования алертов

  1. Алерты на симптомы, не на причины — оповещайте о видимом пользователю влиянии (высокая задержка, ошибки), а не о внутренних метриках
  2. Используйте обоснованные пороги — устанавливайте пороги на основе целей SLO и исторических данных
  3. Указывайте длительность (for) — требуйте сохранения условия перед срабатыванием для избежания мерцания
  4. Предоставляйте контекст — аннотации должны содержать ссылки на ранбуки, дашборды и текущие значения
  5. Устанавливайте правильную критичность — различайте 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 и постепенно расширяйте покрытие по мере развития практики.

Проверьте ваш сайт прямо сейчас

Проверить →
Другие статьи: DevOps
DevOps
Мониторинг Docker-контейнеров: метрики, инструменты и лучшие практики
16.03.2026 · 19 просм.
DevOps
Стратегии деплоя без простоя
16.03.2026 · 14 просм.
DevOps
Управление логами: лучшие практики для продакшена
16.03.2026 · 10 просм.