Observability vs Monitoring: в чём разница и как внедрить Prometheus + Grafana + Loki

Введение: когда мониторинга уже недостаточно

Представьте: вы запускаете новый сервис, всё работает стабильно, метрики на Grafana1 дашборде зелёные. Вдруг — хлопок, и клиенты начинают жаловаться на медленный отклик. Вы открываете мониторинг: CPU в норме, памяти хватает, диски не забиты. В чём же дело?

Такая ситуация знакома многим DevOps-инженерам и SRE-специалистам. Проблема в том, что традиционный мониторинг показывает что происходит, но не объясняет почему. Именно здесь на сцену выходит observability — способность понимать внутреннее состояние системы по её внешним сигналам.

В этой статье разберём, чем отличаются monitoring и observability, и покажем, как построить полноценный стек наблюдаемости на базе Prometheus, Grafana и Loki. Без воды, только практика, рабочие примеры и реальные кейсы.

Monitoring vs Observability: разбираемся в терминах

Что такое monitoring?

Monitoring — это процесс сбора, анализа и визуализации данных о работе системы. Мы следим за заранее определёнными метриками: загрузка CPU, использование памяти, количество запросов в секунду. Если значение выходит за порог — получаем алерт.

По сути, мониторинг отвечает на вопрос: «Всё ли работает нормально?» Это реактивный подход: мы узнаём о проблеме, когда она уже случилась New Relic2.

Проблема в том, что мониторинг хорошо работает только для известных проблем. Если что-то ломается неожиданным образом — мы остаёмся в неведении. Как говорят в Dynatrace3, мониторинг показывает когда и что случилось, но не даёт контекста.

Что такое observability?

Observability (наблюдаемость) — это способность понимать внутреннее состояние системы, анализируя её выходные данные: логи, метрики и трейсы. Это не просто новое слово — это качественно другой подход к управлению инфраструктурой.

Observability отвечает на вопрос: «Почему это происходит?» Это проактивный подход: мы не просто фиксируем факт проблемы, а понимаем её причины, отслеживаем связи между компонентами и предотвращаем повторение Elastic4.

Ключевое отличие: мониторинг работает с известными проблемами, а observability помогает находить неизвестные проблемы — те, о которых вы даже не подозревали.

Три столпа observability: metrics, logs и traces

Современная observability строится на трёх типах данных. Давайте разберём каждый на простых примерах.

Metrics — метрики

Метрики — это числовые измерения, собранные с течением времени. Они показывают состояние системы в конкретный момент.

Типы метрик в Prometheus:

• Counter — монотонно растущий счётчик (количество запросов, ошибок)
• Gauge — значение, которое может меняться в обе стороны (текущая температура, загрузка памяти)
• Histogram — распределение значений по интервалам (время ответа API)
• Summary — квантили наблюдений (99-й перцентиль latency) Prometheus5

Пример из жизни: вы заходите в машину и смотрите на приборную панель. Тахометр показывает обороты двигателя — это gauge. Одометр считает пройденные километры — это counter.

Logs — логи

Логи — это подробные записи о событиях, произошедших в системе. Они содержат контекст: когда, где и что именно случилось.

В отличие от метрик, логи дают детальное описание каждого события. Если метрика показывает, что API вернуло 500 ошибок за минуту, логи расскажут, какие именно запросы упали и с какой трассировкой.

Traces — трейсы

Трейсы показывают путь запроса через распределённую систему. Они связывают воедино все операции: от входящего запроса к фронтенду, через микросервисы, до запроса в базу данных.

Представьте, что вы заказываете доставку еды. Трейс — это как отслеживание заказа: вы видите, когда заказ принят, когда началась готовка, когда курьер забрал заказ и где он сейчас находится.

Почему Prometheus + Grafana + Loki?

Выбор инструментов для observability — вопрос баланса между функциональностью, стоимостью и сложностью поддержки. Стек Prometheus + Grafana + Loki стал де-факто стандартом для self-hosted решений по нескольким причинам:

1. Открытый исходный код — никаких лицензионных отчислений за метрики
2. Общая экосистема — всё работает вместе из коробки
3. Масштабируемость — от одного сервера до кластера из тысяч нод
4. Зрелость — годы разработки и огромное комьюнити Grafana6

Архитектура стека

Prometheus — система сбора и хранения метрик. Он скрейпит (опрашивает) endpoints ваших сервисов, сохраняет time-series данные и выполняет alerting.

Loki — система агрегации логов. Работает по тому же принципу лейблов, что и Prometheus, что позволяет легко коррелировать метрики и логи.

Grafana — платформа визуализации. Подключается к Prometheus и Loki, создаёт единые дашборды, где можно перейти от спика метрики к соответствующим логам одним кликом.

Promtail (или Alloy) — агент, который собирает логи и отправляет их в Loki.

Пошаговая установка: от нуля до работающего стека

Вариант 1: Docker Compose для тестирования

Самый быстрый способ поднять стек — использовать Docker Compose. Подходит для разработки и небольших инсталляций.

version: '3.8'
services:
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.retention.time=30d'
    restart: always

  loki:
    image: grafana/loki:latest
    container_name: loki
    ports:
      - "3100:3100"
    volumes:
      - ./loki-config.yml:/etc/loki/local-config.yaml
      - loki_data:/loki
    command: -config.file=/etc/loki/local-config.yaml
    restart: always

  promtail:
    image: grafana/promtail:latest
    container_name: promtail
    volumes:
      - ./promtail-config.yml:/etc/promtail/config.yml
      - /var/log:/var/log:ro
      - /var/lib/docker/containers:/var/lib/docker/containers:ro
    command: -config.file=/etc/promtail/config.yml
    restart: always

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    ports:
      - "3000:3000"
    volumes:
      - grafana_data:/var/lib/grafana
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=your-secure-password
      - GF_USERS_ALLOW_SIGN_UP=false
    restart: always

volumes:
  prometheus_data:
  loki_data:
  grafana_data:

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

Создайте файл prometheus.yml:

global:
  scrape_interval: 15s
  evaluation_interval: 15s

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

  - job_name: 'node'
    static_configs:
      - targets: ['node-exporter:9100']

  - job_name: 'your-app'
    static_configs:
      - targets: ['your-app:8080']
    metrics_path: /metrics

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

Файл loki-config.yml:

auth_enabled: false

server:
  http_listen_port: 3100

common:
  ring:
    instance_addr: 127.0.0.1
    kvstore:
      store: inmemory
  replication_factor: 1
  path_prefix: /loki

schema_config:
  configs:
    - from: 2020-10-24
      store: tsdb
      object_store: filesystem
      schema: v13
      index:
        prefix: index_
        period: 24h

storage_config:
  filesystem:
    directory: /loki/chunks

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

Файл promtail-config.yml:

server:
  http_listen_port: 9080

positions:
  filename: /tmp/positions.yaml

clients:
  - url: http://loki:3100/loki/api/v1/push

scrape_configs:
  - job_name: docker
    docker_sd_configs:
      - host: unix:///var/run/docker.sock
        refresh_interval: 5s
    relabel_configs:
      - source_labels: ['__meta_docker_container_name']
        target_label: 'container'
      - source_labels: ['__meta_docker_container_log_stream']
        target_label: 'stream'

Вариант 2: Kubernetes с Helm

Для production-сред рекомендуется использовать Kubernetes с Helm-чартами. Это даёт отказоустойчивость, масштабирование и простое управление Medium7.

# Создаём namespace для мониторинга
kubectl create namespace monitoring

# Добавляем репозитории Helm
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo add grafana https://grafana.github.io/helm-charts
helm repo update

# Устанавливаем kube-prometheus-stack
helm install prometheus prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --set grafana.adminPassword=your-secure-password

# Устанавливаем Loki
helm install loki grafana/loki-stack \
  --namespace monitoring \
  --set loki.persistence.enabled=true \
  --set loki.persistence.size=10Gi

Практические примеры дашбордов

Дашборд инфраструктуры

Это ваш главный экран, который показывает общее состояние системы. Рекомендуется разместить его на большом мониторе в офисе или на дежурном рабочем месте.

Ключевые панели:

• CPU Usage — график загрузки процессоров по нодам
• Memory Usage — использование памяти в процентах
• Disk I/O — операции чтения/записи на диск
• Network Traffic — входящий и исходящий трафик

PromQL-запросы для дашборда:

# Загрузка CPU
100 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

# Использование памяти
(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100

# Дисковое пространство
node_filesystem_avail_bytes / node_filesystem_size_bytes * 100

Дашборд приложений

Показывает бизнес-метрики и состояние сервисов.

Ключевые панели:

• Request Rate — количество запросов в секунду
• Error Rate — процент ошибок
• Latency P95/P99 — время ответа для 95% и 99% запросов
• Active Users — количество активных пользователей

Пример запроса на ошибки:

sum(rate(http_requests_total{status_code=~"5.."}[5m])) / 
sum(rate(http_requests_total[5m])) * 100

Лог-дашборд в Grafana

Создаём дашборд для анализа логов через Loki.

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

1. Переменные для фильтрации:
   • namespace — выбор namespace
   • pod — выбор конкретного пода
   • level — уровень логов (error, warn, info, debug)
   • search — текстовый поиск по логам
2. Панели:
   • Log Volume — график объёма логов со временем
   • Error Rate — количество ошибок за период
   • Top Errors — таблица самых частых ошибок
   • Raw Logs — поток логов с подсветкой

Примеры LogQL-запросов:

# Все ошибки из контейнера
{container="your-app"} |= "error"

# JSON-логи с фильтрацией по уровню
{container="your-app"} | json | level="error"

# Подсчёт ошибок за 5 минут
count_over_time({container="your-app"} |= "error" [5m])

Связка метрик и логов

Самое ценное — возможность перейти от метрики к логам одним кликом. Настройте data links в Grafana:

1. Откройте настройки панели с метрикой
2. Перейдите во вкладку "Field" → "Data links"
3. Добавьте ссылку:

/explore?left=["now-1h","now","Loki",{"expr":"{container=\"your-app\"}"}]

Теперь при клике на спик CPU или spike ошибок вы мгновенно увидите логи за этот период.

Настройка алертов: от сигнала к действию

Мониторинг без алертов — это просто красивая картинка. Давайте настроим реальные оповещения, которые помогут реагировать на проблемы до того, как они затронут пользователей.

Основные правила алертинга в Prometheus

Создайте файл alerts.yml:

groups:
  - name: infrastructure
    rules:
      # Алерт на высокую загрузку CPU
      - alert: HighCPUUtilization
        expr: 100 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Высокая загрузка CPU на {{ $labels.instance }}"
          description: "Загрузка CPU превысила 80% в течение 5 минут"

      # Алерт на нехватку дискового пространства
      - alert: LowDiskSpace
        expr: node_filesystem_avail_bytes / node_filesystem_size_bytes < 0.1
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Мало свободного места на {{ $labels.instance }}"
          description: "Свободного места меньше 10%"

      # Алерт на высокий rate ошибок
      - alert: HighErrorRate
        expr: sum(rate(http_requests_total{status_code=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.05
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Высокий процент ошибок"
          description: "Error rate превысил 5% в течение 5 минут"

      # Алерт на недоступность сервиса
      - alert: ServiceDown
        expr: up == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Сервис {{ $labels.job }} недоступен"

Настройка Alertmanager

Alertmanager принимает алерты от Prometheus и маршрутизирует их в нужные каналы:

# alertmanager.yml
global:
  smtp_smarthost: 'smtp.example.com:587'
  smtp_from: 'alerts@example.com'

route:
  group_by: ['alertname', 'severity']
  group_wait: 10s
  group_interval: 30s
  repeat_interval: 4h
  receiver: 'default'

  routes:
    - match:
        severity: critical
      receiver: 'pagerduty'
      continue: true
    - match:
        severity: warning
      receiver: 'slack'

receivers:
  - name: 'default'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/...'
        channel: '#alerts'
        title: '{{ .GroupLabels.alertname }}'
        text: '{{ .Annotations.summary }}'

  - name: 'pagerduty'
    pagerduty_configs:
      - service_key: 'your-pagerduty-key'
        description: '{{ .Annotations.summary }}'

  - name: 'slack'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/...'
        channel: '#warnings'
        title: '{{ .GroupLabels.alertname }}'
        text: '{{ .Annotations.summary }}'

Best practices: как не утонуть в данных

Observability — это мощный инструмент, но при неправильном подходе вы получите информационный шум вместо полезных инсайтов. Вот проверенные практики Spacelift8:

1. Начните с бизнес-метрик

Не собирайте всё подряд. Определите, какие метрики действительно важны для бизнеса: время отклика API, количество успешных транзакций, доступность сервиса. Остальное — вторично.

2. Используйте уровни severity

Разделяйте алерты на:

• Critical — требует немедленного вмешательства, звонок дежурному
• Warning — требует внимания в рабочее время
• Info — информационное сообщение, не требует действий

3. Боритесь с alert fatigue

Если дежурный получает 50 алертов за ночь, он перестанет на них реагировать. Настройте:

• Группировку похожих алертов
• Таймауты для повторяющихся уведомлений
• Авторазрешение, когда проблема устранена

4. Сохраняйте контекст

Алерт должен содержать:

• Что случилось (summary)
• Где это произошло (labels)
• Почему это важно (description)
• Что делать (runbook или ссылка на документацию)

5. Оптимизируйте запросы

Тяжёлые PromQL-запросы могут перегрузить Prometheus. Используйте recording rules для предварительного вычисления сложных выражений:

groups:
  - name: recording_rules
    rules:
      - record: job:request_latency:rate5m
        expr: histogram_quantile(0.95, 
          sum(rate(http_request_duration_seconds_bucket[5m])) by (job, le))

Распространённые ошибки при внедрении

Ошибка 1: «Нам нужны все метрики!»

Собирая всё подряд, вы получите горы данных, в которых сложно найти что-то полезное. Начните с 10-15 ключевых метрик, добавляйте новые по мере необходимости.

Ошибка 2: Игнорирование логов

Метрики без логов — это как диагностика без анамнеза. Вы видите симптомы, но не знаете причины. Обязательно настраивайте сбор логов и связывайте их с метриками.

Ошибка 3: Отсутствие тегов и лейблов

Без правильной разметки вы не сможете фильтровать и группировать данные. Убедитесь, что все метрики и логи имеют лейблы: environment, service, version, team.

Ошибка 4: «Set and forget»

Observability — это не проект, а процесс. Регулярно пересматривайте дашборды и алерты: удаляйте неиспользуемые, добавляйте новые по мере изменения системы.

Ошибка 5: Отсутствие документации

Каждый алерт должен иметь runbook — инструкцию по устранению проблемы. Иначе дежурный инженер будет тратить драгоценные минуты на разбор проблемы вместо её решения.

Расширение стека: куда двигаться дальше

Когда базовый стек Prometheus + Grafana + Loki работает стабильно, можно добавить дополнительные компоненты:

Tempo — distributed tracing

Добавляет трейсы для полного понимания прохождения запросов через микросервисы. Позволяет отследить, где именно тормозит запрос.

Alertmanager — управление алертами

Продвинутая система маршрутизации, дедупликации и группировки алертов. Интегрируется с Slack, PagerDuty, Opsgenie и другими.

Mimir — масштабируемый Prometheus

Если метрик становится слишком много для одиночного Prometheus, Mimir предоставляет горизонтально масштабируемое хранилище метрик.

Pyroscope — continuous profiling

Профилирование кода в production позволяет находить узкие места в производительности на уровне функций.

Заключение: от мониторинга к observability

Переход от мониторинга к observability — это не просто смена инструментов, а изменение мышления. Вместо того чтобы реагировать на известные проблемы, вы начинаете исследовать систему, находить неизвестные проблемы и предотвращать инциденты до их возникновения.

Стек Prometheus + Grafana + Loki даёт мощный фундамент для этого перехода. Он открыт, масштабируем и не требует лицензионных отчислений за каждую метрику. При правильной настройке вы получаете полную картину работы ваших систем: от высокоуровневых бизнес-метрик до детальных логов конкретного запроса.

Главное — начать. Не ждите идеальной архитектуры и полного покрытия. Поднимите базовый стек, добавьте несколько ключевых метрик и алертов, а затем развивайте observability постепенно, по мере роста ваших потребностей.

И помните: лучший мониторинг — тот, который реально помогает решать проблемы, а не просто красиво выглядит на экране.