Best practices: как не наступить на грабли

«Опыт — это имя, которое мы даём своим ошибкам» — Oscar Wilde

#Введение

Вы изучили основы Prometheus, Grafana и Loki. Теперь важно понять, как не построить систему, которая упадёт в production.

В этой теме собраны типичные ошибки и рекомендации из реальной практики.

#Ошибка 1: Высокая кардинальность лейблов

#Проблема

# ПЛОХО: user_id имеет миллионы уникальных значений
Counter('requests', 'Requests', ['user_id', 'request_id'])

Каждая уникальная комбинация лейблов = отдельный временной ряд.

Результат:

Миллионы временных рядов
Потребление ГБ памяти
Медленные запросы
Падение Prometheus

#Решение

# ХОРОШО: низкая кардинальность
Counter('requests', 'Requests', ['method', 'endpoint', 'status'])

Правило: лейблы должны иметь ограниченное количество уникальных значений (< 1000).

Хорошие лейблы:

method (GET, POST, PUT, DELETE)
endpoint (/api/users, /api/orders)
status (200, 404, 500)
env (production, staging)

Плохие лейблы:

user_id (миллионы пользователей)
request_id (уникален для каждого запроса)
timestamp (постоянно растёт)
email (уникален для каждого пользователя)

#Ошибка 2: Отсутствие retention

#Проблема

Prometheus по умолчанию хранит данные бесконечно (пока есть место).

Результат:

Диск заполняется через N дней
Prometheus падает в read-only режиме
Данные не записываются

#Решение

Настройте retention:

command:
  - '--storage.tsdb.retention.time=15d'
  - '--storage.tsdb.retention.size=10GB'

Рекомендации:

retention.time: 15-30 дней для локального хранения
retention.size: ограничьте по месту (10-50GB)

Для долгосрочного хранения:

Thanos
Cortex
Mimir

#Ошибка 3: Слишком частый скрапинг

#Проблема

# ПЛОХО: слишком часто
scrape_interval: 1s

Результат:

Высокая нагрузка на targets
Большой объём данных
Быстрое заполнение диска

#Решение

# ХОРОШО: разумная частота
global:
  scrape_interval: 15s

# Для критичных метрик можно чаще
- job_name: 'critical'
  scrape_interval: 5s

Рекомендации:

По умолчанию: 15-30 секунд
Критичные сервисы: 5 секунд
Инфраструктура: 30-60 секунд

Помните: rate()[5m] требует окно больше scrape_interval (минимум 2x).

#Ошибка 4: Неправильное использование rate()

#Проблема

# ПЛОХО: нет range vector
rate(http_requests_total)

# ПЛОХО: слишком маленькое окно
rate(http_requests_total[10s])  # Если scrape_interval = 15s

#Решение

# ХОРОШО: окно больше scrape_interval
rate(http_requests_total[1m])   # Минимум
rate(http_requests_total[5m])   # Рекомендуется

Правило: окно rate() должно быть минимум в 2-3 раза больше scrape_interval.

#Ошибка 5: Игнорирование alert fatigue

#Проблема

# ПЛОХО: слишком чувствительный алерт
- alert: HighCPU
  expr: node_cpu_usage_percent > 50
  for: 0m

Результат:

Алерты срабатывают постоянно
Команда перестаёт реагировать
Реальные проблемы пропускаются

#Решение

# ХОРОШО: разумные пороги и окна
- alert: HighCPU
  expr: node_cpu_usage_percent > 80
  for: 15m
  labels:
    severity: warning

Рекомендации:

Используйте for для фильтрации скачков
Настройте уровни (warning/critical)
Подавляйте дубликаты в Alertmanager
Ревизуйте алерты раз в квартал

#Ошибка 6: Монотонные дашборды

#Проблема

Дашборд с 50 панелями, на каждой по 10 линий.

Результат:

Невозможно найти нужное
Медленная загрузка
Непонятно, на что смотреть

#Решение

Структура дашборда:

┌─────────────────────────────────────────────────────────┐
│  KPI (4-6 Stat панелей)                                 │
│  - Requests/s, Errors, Latency, Uptime                  │
├─────────────────────────────────────────────────────────┤
│  Основные метрики (3-5 Time series)                     │
│  - Traffic, Performance, Saturation                     │
├─────────────────────────────────────────────────────────┤
│  Детали (2-3 панели)                                    │
│  - По эндпоинтам, по методам                            │
├─────────────────────────────────────────────────────────┤
│  Логи (1 панель Loki)                                   │
│  - Recent errors                                        │
└─────────────────────────────────────────────────────────┘

Рекомендации:

Максимум 10-15 панелей на дашборд
Максимум 5-10 линий на графике
Используйте переменные для фильтрации
Группируйте по смыслу

#Ошибка 7: Логирование без структуры

#Проблема

# ПЛОХО: текст, который сложно парсить
2026-03-18 14:30:00 INFO User John Doe with email john@example.com logged in from 192.168.1.1

Результат:

Сложно фильтровать в Loki
Ложные совпадения
Невозможно агрегировать

#Решение

{
  "timestamp": "2026-03-18T14:30:00Z",
  "level": "INFO",
  "message": "User logged in",
  "user_id": 123,
  "ip": "192.168.1.1"
}

Преимущества:

Фильтрация по полям: {level="ERROR"}
Агрегации: sum by (user_id)
Меньше ложных совпадений

#Ошибка 8: Отсутствие документирования метрик

#Проблема

# ПЛОХО: непонятно, что измеряет метрика
requests = Counter('req', 'Reqs')

#Решение

# ХОРОШО: подробное описание
http_requests_total = Counter(
    'http_requests_total',
    'Total HTTP requests received by the server',
    ['method', 'endpoint', 'status']
)

Добавляйте:

HELP текст в коде
Документацию в README
Единицы измерения (секунды, байты, проценты)

#Ошибка 9: Игнорирование метрик самого Prometheus

#Проблема

Не мониторите Prometheus и Grafana.

Результат:

Не узнаете, что мониторинг упал
Потеря данных
Слепота в production

#Решение

Добавьте self-monitoring:

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']
  
  - job_name: 'grafana'
    static_configs:
      - targets: ['grafana:3000']

Ключевые метрики:

prometheus_tsdb_head_samples_appended_total — записывается ли
prometheus_target_scrape_pool_exceeded_target_limit — проблемы со скрапингом
up — доступен ли

Алерты:

- alert: PrometheusDown
  expr: up{job="prometheus"} == 0
  for: 1m
  severity: critical

- alert: PrometheusTargetMissing
  expr: count(up == 0) > 0
  for: 5m
  severity: warning

#Ошибка 10: Нет плана масштабирования

#Проблема

Prometheus на одном сервере справляется, но:

Данные не помещаются на диск
Запросы выполняются минуты
Один точка отказа

#Решение

Вариант 1: Federation

Несколько Prometheus, каждый собирает свою часть, центральный агрегирует.

Вариант 2: Thanos

Горизонтальное масштабирование
Долгосрочное хранение (S3, GCS)
Глобальные запросы across clusters

Вариант 3: Cortex/Mimir

Полностью распределённая система
Мультитенантность
Бесконечное масштабирование

Когда масштабировать:

1 млн активных временных рядов
100GB данных на диске
Запросы > 30 секунд
500 уникальных лейблов

#Чеклист перед production

#Конфигурация

Retention настроен (время и размер)
Scrape_interval разумный (15-30s)
Service Discovery настроен
Relabeling фильтрует лишнее

#Метрики

Лейблы с низкой кардинальностью
HELP текст для всех метрик
Четыре золотых сигнала покрыты
Бизнес-метрики добавлены

#Алерты

Алерты действенные (есть что делать)
Уровни severity (critical, warning)
For для фильтрации скачков
Notification channels настроены
Silences для плановых работ

#Дашборды

KPI панели сверху
Не больше 15 панелей
Переменные для фильтрации
Thresholds настроены
Описания добавлены

#Инфраструктура

Prometheus и Grafana мониторятся
Бэкап конфигурации
Документация обновлена
Runbooks для алертов

#Ресурсы для дальнейшего изучения

#Официальная документация

#Инструменты

Thanos — долгосрочное хранение, масштабирование
Cortex/Mimir — распределённый Prometheus
Grafana Agent — лёгкий агент для сбора метрик
VictoriaMetrics — альтернатива TSDB

#Сообщество

#Поздравляем!

Вы завершили курс «Prometheus и Grafana для начинающих»!

Теперь вы умеете:

Развернуть полный стек мониторинга в Docker
Собирать метрики с инфраструктуры и приложений
Создавать информативные дашборды в Grafana
Интегрировать логи Loki с метриками
Настраивать алерты и избегать типичных ошибок

Следующий шаг: курс «Prometheus и Grafana для Middle» — углублённое изучение PromQL, Recording Rules, Thanos, и продвинутые паттерны алертинга.