← Back to notes

Observability в Kubernetes: сигналы,
SLI и доказательства

2026-04-26

#observability#prometheus#metrics#sli#monitoring

← 24: SLA, SLO, RPO, RTO

Observability — не «наличие дашбордов» и не «Prometheus установлен». Это способность доказать состояние системы в любой момент времени. Без observability заявления об SLO, RPO, RTO недоказуемы: число есть, а подтверждения нет. Observability — архитектурное решение, которое нужно проектировать одновременно с кластером, а не добавлять постфактум. kubernetes.io/docs/concepts/cluster-administration/monitoring/

Три столпа и приоритеты

Для Kubernetes-платформы baseline строится на metrics. Logs и traces дополняют картину, но без метрик невозможно построить SLI и, значит, доказать соблюдение SLO.

Почему observability — архитектурная задача

/readyz не доказывает здоровье платформы. API server может отвечать 200 OK, пока etcd теряет данные, scheduler не может разместить Pod'ы, а controller-manager потерял leadership. Один endpoint не покрывает состояние всей системы.

Backup success не доказывает возможность восстановления. Успешный backup-job подтверждает только факт запуска и завершения задачи. Он ничего не говорит о целостности snapshot, читаемости Secret'ов после restore, или о том, укладывается ли время восстановления в RTO.

Сломанный alert path обесценивает весь мониторинг. Если алерты не доходят до дежурного — графики и метрики бесполезны. Heartbeat-проверка (watchdog alert, который должен приходить регулярно) обязательна.

Сигнал → Метрика → Алерт → Доставка → Реакция
                              ↑
                     Если здесь разрыв,
                     всё слева бесполезно

Минимальные сигналы: API Server

API server — единственная точка входа в кластер. Его метрики дают главные SLI доступности и latency.

Пример запроса для SLI доступности (rate over 5 минут):

sum(rate(apiserver_request_total{code=~"2.."}[5m]))
/
sum(rate(apiserver_request_total[5m]))

Пример запроса для P99 latency:

histogram_quantile(0.99,
  sum(rate(apiserver_request_duration_seconds_bucket[5m])) by (le, verb)
)

kubernetes.io/docs/reference/instrumentation/metrics/

API Priority and Fairness (APF)

APF (с k8s 1.20+, стабильно с 1.29) контролирует, как запросы распределяются по приоритетным уровням. Без его метрик непонятно, кто throttling и почему.

Рост rejected_requests_total — сигнал, что какой-то клиент или компонент генерирует слишком много запросов и вытесняется. Нужно проверить FlowSchema и PriorityLevelConfiguration. kubernetes.io/docs/concepts/cluster-administration/flow-control/

Authentication / Authorization / Admission

Медленный OIDC-провайдер или перегруженный admission webhook влияет на латентность всех запросов, даже если сам API server здоров.

fail_open_count > 0 — критичный алерт: это означает, что ValidatingWebhook с failurePolicy: Ignore недоступен и пропускает запросы без проверки. kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/

Scheduler

Рост scheduler_pending_pods — ранний сигнал нехватки ресурсов или проблем с node affinity/taints. При leader_election_master_status == 0 новые Pod'ы не размещаются — кластер фактически неуправляем.

Controller Manager

Controller manager — reconciliation engine. Его задержки означают, что объекты кластера (Deployment'ы, ReplicaSet'ы, Service'ы) обновляются медленнее, чем должны.

etcd

etcd — хранилище всего состояния кластера. Его деградация — самый критичный сценарий после полного отказа.

Пример алерта на fsync latency:

# alertmanager rule
- alert: EtcdHighFsyncDuration
  expr: |
    histogram_quantile(0.99,
      rate(etcd_disk_wal_fsync_duration_seconds_bucket[5m])
    ) > 0.01
  for: 2m
  labels:
    severity: warning
  annotations:
    summary: "etcd WAL fsync P99 > 10ms"

etcd.io/docs/v3.5/op-guide/monitoring/

Recovery-метрики

Эти метрики кастомные — их нужно экспортировать из backup/restore job'ов через PushGateway или встроить в скрипт, который обновляет gauge в Prometheus.

Пример алертов:

# backup stale
(time() - backup_last_success_timestamp) > 900  # > 15 мин (RPO)

# restore не тестировался больше недели
(time() - restore_check_last_success) > 604800  # > 7 дней

# restore не укладывается в RTO
restore_check_duration_seconds > 1800  # > 30 мин (RTO)

SLI Map: от метрик к доказательствам

На основе собранных сигналов формируются SLI для каждого SLO:

┌─────────────────────────────────────────────────────────────┐
│                        SLI Map                              │
├─────────────────────┬───────────────────────────────────────┤
│ Tier-1 availability │ apiserver_request_total               │
│                     │ (success rate за 30d window)          │
├─────────────────────┼───────────────────────────────────────┤
│ Control plane       │ apiserver_request_duration_seconds    │
│                     │ + leader_election_master_status       │
│                     │ + etcd health signals                 │
├─────────────────────┼───────────────────────────────────────┤
│ Observability path  │ up{job="prometheus"} + alertmanager   │
│                     │ + watchdog heartbeat delivery         │
├─────────────────────┼───────────────────────────────────────┤
│ Backup freshness    │ backup_last_success_timestamp         │
│                     │ (now - timestamp < RPO)               │
├─────────────────────┼───────────────────────────────────────┤
│ Restore readiness   │ restore_check_last_success            │
│                     │ + restore_check_duration_seconds      │
│                     │ (duration < RTO)                      │
└─────────────────────┴───────────────────────────────────────┘

Когда использовать

Observability baseline нужна с первого дня production:

  • До первого инцидента — не после. Без предварительно настроенных алертов инцидент будет обнаружен пользователями, а не командой.
  • Перед плановым обновлением — убедиться, что все baseline-метрики собираются и алерты работают. Обновление без observability — это полёт вслепую.
  • При onboarding нового кластера — в managed Kubernetes (EKS, GKE, AKS) часть метрик предоставляет провайдер, но recovery-метрики и APF нужно настраивать отдельно.
  • При ревью SLO — пересматривать SLI-запросы при изменении нагрузки или архитектуры. SLI для 10 RPS и для 10 000 RPS — разные формулы агрегации.

Типичные ошибки

1. Мониторинг только Pod'ов, но не control plane Grafana показывает CPU/Memory приложений, но нет ни одного алерта на leader_election_master_status или etcd_server_proposals_failed_total. При потере quorum etcd проблему обнаруживают через 30 минут по жалобам пользователей.

2. Watchdog alert не настроен Alertmanager работает, алерты настроены, но нет heartbeat-алерта, который приходит каждые N минут. Если Alertmanager упал или webhook-интеграция сломалась — никто не знает. Правило: первый алерт, который нужно настроить — Watchdog (он есть в kube-prometheus-stack по умолчанию).

3. backup_last_success_timestamp не экспортируется Backup job работает, но метрика не пушится в Prometheus. В результате SLI для RPO не существует, и при аварии нельзя доказать, что backup был свежим. Правило: каждый backup-job должен обновлять gauge через PushGateway или аналог.

4. Алерты на симптомы вместо причин Алерт срабатывает на container_cpu_usage_seconds_total > 80%, но не на apiserver_request_total success rate < 99.9%. Пользователи замечают деградацию раньше, чем алерт. Правило: SLI-алерты — первоочередные.

5. Метрики etcd fsync не мониторятся Диск на control plane ноде деградирует (SSD с высоким write amplification), P99 fsync растёт до 50ms, затем до 200ms. Cluster постепенно теряет write throughput, leader elections учащаются. Без etcd_disk_wal_fsync_duration_seconds это видно только в etcd logs, которые никто не читает проактивно.

6. Один инстанс Prometheus без высокой доступности Prometheus — единственный источник правды для SLI. Его падение означает blind spot в observability. Для production: Thanos, Cortex, Victoria Metrics или хотя бы remote_write в S3-совместимое хранилище.

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

kube-prometheus-stack (Prometheus Operator + Grafana + Alertmanager) Де-факто стандарт для self-managed кластеров. Включает готовые ServiceMonitor'ы для всех control plane компонентов, набор алертов (kubernetes-mixin) и дашборды. Рекомендуется как baseline для большинства кластеров. github.com/prometheus-operator/kube-prometheus

Victoria Metrics Drop-in замена Prometheus с лучшей производительностью при высокой cardinality и меньшим потреблением памяти. Совместима с PromQL и Prometheus remote_write. Хороший выбор для кластеров с большим количеством метрик.

Datadog / New Relic / Dynatrace Managed observability. Снимают операционную нагрузку по поддержке monitoring stack. Минусы: cost at scale, vendor lock-in, потенциальные задержки в доставке метрик. Traces и APM — сильная сторона; для Kubernetes control plane метрики нужна дополнительная настройка.

OpenTelemetry Collector Vendor-neutral pipeline для сбора и маршрутизации metrics/logs/traces. Не хранилище, но даёт гибкость: один collector экспортирует в Prometheus, Jaeger, Loki одновременно. Полезен при migration между backends или в multi-tenant окружениях. opentelemetry.io/docs/collector/

Grafana Alloy (бывший Grafana Agent) Lightweight collector с нативной интеграцией в Grafana Cloud. Поддерживает Prometheus scraping, журналы через Loki, traces через Tempo. Хорошая альтернатива полному стеку kube-prometheus-stack при использовании Grafana Cloud.

26: Backup, Restore →

Observability в Kubernetes: сигналы, SLI и доказательства | Aleksandr Suprun