Модуль 11 — Observability ⭐⭐⭐

Если ты не видишь систему — ты ей не управляешь. Observability ≠ monitoring. Monitoring — известные проблемы. Observability — способность задать любой вопрос системе и получить ответ.

Три столпа

Четвёртый «новый» столп — Profiles (Pyroscope, Parca) — CPU/memory профили в реальном времени.

Стек 2026 года

Open source (рекомендуется)

• Prometheus + Grafana — стандарт metrics
• Loki (Grafana Labs) — логи
• Tempo (Grafana Labs) — traces
• Pyroscope — profiles
• OpenTelemetry ⭐ — единый стандарт сбора

Альтернативы

• VictoriaMetrics — Prometheus-совместимый, эффективнее по памяти/диску для масштаба
• Elastic Stack (ELK) — проверено, тяжёлый
• OpenSearch — Apache 2.0 форк Elasticsearch
• SigNoz — open source альтернатива Datadog

Коммерческие

• Datadog — лидер enterprise. Мощно, но дорого.
• New Relic, Dynatrace, Splunk, Honeycomb
• Grafana Cloud — managed Grafana stack

Prometheus ⭐

Концепции

• Pull model — Prometheus сам ходит к экспортёрам по HTTP
• Service Discovery — авто-обнаружение targets (kubernetes_sd, ec2_sd, file_sd)
• Data model: metric_name{label1="v1",label2="v2"} value
• Типы метрик:
  • Counter — только растёт (количество запросов)
  • Gauge — может расти/падать (память)
  • Histogram — buckets для распределений (latency)
  • Summary — quantiles на клиенте

PromQL — must master

# Скорость HTTP запросов в секунду
rate(http_requests_total[5m])

# Сгруппировать по route
sum by (route) (rate(http_requests_total[5m]))

# 95-й перцентиль latency
histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

# Сколько pod-ов в каждом namespace
count by (namespace) (kube_pod_info)

# Pod restart за последний час
increase(kube_pod_container_status_restarts_total[1h]) > 0

# Error rate (для SLO алертов)
sum(rate(http_requests_total{status=~"5.."}[5m]))
  /
sum(rate(http_requests_total[5m]))

Типичный prod-стек

• Prometheus Operator — стандарт для K8s
• kube-prometheus-stack — Helm chart с Prometheus + Grafana + AlertManager + кучей экспортёров
• node_exporter — host-метрики
• kube-state-metrics — метрики K8s объектов
• blackbox_exporter — синтетический мониторинг (probe URLs)
• Thanos / Cortex / VictoriaMetrics — для long-term и HA

Grafana

• Data sources: Prometheus, Loki, Tempo, MySQL, Postgres, CloudWatch — десятки
• Dashboards: panels, variables, repeating, links
• Alerting (Grafana 9+): unified alerting со state
• Annotations: пометить деплой на графике
• Provisioning через файлы (GitOps-friendly)
• Dashboards as Code: grafonnet, JSON в Git
• Готовые дашборды: grafana.com/dashboards

Loki — логи cloud-native

• Индекс только лейблов (не контента) → дешёво
• LogQL — синтаксис похож на PromQL:

  {app="api"} |= "error" | json | latency > 1s

• Promtail (старый) → Grafana Alloy (новый, OTel-совместимый)
• Multi-tenant из коробки
• Когда: cost-conscious, K8s-стек. Когда нет: нужен серьёзный full-text search

Tempo / Jaeger — traces

• Trace = root span + child spans
• Контекст распространяется через headers (W3C Trace Context, B3)
• traceID связывает с логами и метриками (correlation)
• Sampling: head-based (на старте), tail-based (после)
• OpenTelemetry SDK — инструментирование приложения

OpenTelemetry ⭐⭐ (must для 2026+)

Единый стандарт CNCF для сбора metrics, logs, traces. К 2027 OTel станет стандартом везде.

• OpenTelemetry Collector — receiver → processor → exporter pipeline
• SDKs для всех языков (Python, Go, Java, Node, .NET, ...)
• Auto-instrumentation — без изменений кода для популярных фреймворков
• Vendor-neutral: один SDK → можно слать в Prometheus / Datadog / New Relic / любой backend

Пример: OTel Collector конфиг

receivers:
  otlp:
    protocols:
      grpc: {endpoint: 0.0.0.0:4317}
      http: {endpoint: 0.0.0.0:4318}

processors:
  batch:
  memory_limiter: {check_interval: 1s, limit_percentage: 75}

exporters:
  prometheus:
    endpoint: 0.0.0.0:8889
  loki:
    endpoint: http://loki:3100/loki/api/v1/push
  otlp/tempo:
    endpoint: tempo:4317
    tls: {insecure: true}

service:
  pipelines:
    metrics: {receivers: [otlp], processors: [memory_limiter, batch], exporters: [prometheus]}
    logs:    {receivers: [otlp], processors: [memory_limiter, batch], exporters: [loki]}
    traces:  {receivers: [otlp], processors: [memory_limiter, batch], exporters: [otlp/tempo]}

Alerting

• Alertmanager — routing, grouping, inhibitions, silences
• Receivers: Email, Slack, PagerDuty, OpsGenie, Telegram, custom webhooks
• Alert fatigue — главная проблема. Решение: меньше алертов, на симптомы (SLO), не причины
• On-call rotation: PagerDuty / OpsGenie / FireHydrant

SRE концепции

SLI / SLO / SLA

• SLI (Service Level Indicator) — что измеряем (latency, error rate, availability)
• SLO (Objective) — цель (99.9% запросов < 200ms за 30 дней)
• SLA (Agreement) — контракт с пользователем (юридическое)
• Error Budget = (1 - SLO). Если потратил → стоп новых фич, фокус на надёжности

Методы анализа

• USE (Brendan Gregg) — для resources: Utilization, Saturation, Errors
• RED — для services: Rate, Errors, Duration
• Four Golden Signals (Google SRE): Latency, Traffic, Errors, Saturation

Burn rate alerts

Современный подход — алерты по скорости расхода error budget, а не по threshold-ам.

• Fast burn: 1h окно, 14.4× бюджета — серьёзно, page
• Slow burn: 6h окно, 6× бюджета — проблема, ticket

Incident response

• Runbooks — пошаговые инструкции для типовых инцидентов (в Git)
• Post-mortem — после инцидента. Blameless!
• 5 Whys для root cause
• Status pages: statuspage.io, instatus

Best practices

1. Метрики дешёвые, логи дорогие, трейсы средние — балансируй
2. Структурированные логи — JSON, поля, не текст
3. Один traceID связывает всё: логи, метрики, трейсы
4. SLO, не SLA для алертов
5. Меньше дашбордов лучше — 5 хороших > 50 плохих
6. RED для каждого сервиса — Rate, Errors, Duration минимум
7. USE для нод — Utilization, Saturation, Errors
8. Cardinality monitoring — Prometheus падает на high-cardinality labels (никогда не лей user_id в метрики)
9. Retention — короткое для всего, долгое для агрегатов (через Thanos/VM)
10. Документируй каждый алерт runbook-ом

Чек-лист

Источники

• Книга: «Site Reliability Engineering» — Beyer et al. (Google) — БЕСПЛАТНО
• Книга: «Observability Engineering» — Charity Majors (Honeycomb)
• Курс: PromQL Tutorial
• Документация: prometheus.io, grafana.com/docs, opentelemetry.io