Модуль 25. Мониторинг и логирование
Цель: собрать метрики и логи из k8s и стека данных (PG/CH/Trino/Airflow/Ingress и т. д.), построить дашборды SLI/SLO, настроить алерты без шума и выстроить хранение (retention/стоимость).
Результат: kube-prometheus-stack/Alertmanager/Grafana + Loki (или EFK) + бэкенд длительного хранения (VictoriaMetrics/Thanos/Mimir). Есть чек-листы и runbook’и.
Архитектура наблюдаемости: «плоскости» и потоки
Метрики
- Пуллер: Prometheus скрапит /metrics (kube-components, exporters, приложения).
-
Агрегация/долгое хранение:
- Малый/средний масштаб → Prometheus single + remote_write в VictoriaMetrics (single/cluster).
- Крупный/мультикластер → Thanos/Cortex/Mimir (объектное хранилище, федерация).
- Где взять метрики:
- k8s: kube-state-metrics, node_exporter, cAdvisor, control-plane (/metrics).
- BI/DWH: Postgres/pgBouncer, ClickHouse, Trino, Airflow, Kafka/Connect, Ingress (nginx/HAProxy/Traefik), MinIO/S3 (4xx/5xx, латентность).
- Отрисовка: Grafana (дашборды, аннотации релизов).
- Алертинг: Alertmanager (маршрутизация/инхибирование/сайлэнсы).
Логи
- Агент: Promtail (Loki) или Fluent Bit (EFK).
- Бэкенд: Loki (болт+объектное S3, индекс по лейблам; дешёвле ES), либо Elasticsearch/OpenSearch (дороже, но богатый поиск).
- Аудит: лог kube-api audit в тот же бэкенд с отдельной меткой/индексом.
Служебные компоненты k8s
- metrics-server — даёт краткоживущие CPU/Mem для HPA (не для исторических графиков).
- kube-state-metrics — «снимок состояния объектов k8s» (реплики, статусы, версии).
«Золотые сигналы» и SLO для BI/DWH
SRE-оптика (4 Golden Signals): latency, traffic, errors, saturation.
- Пользовательский край (Ingress): p50/p95/p99 latency, RPS, 4xx/5xx rate, saturation воркеров.
- BI: успешность запросов/экспортов, p95 построения дашборда, очередь заданий (воркеры Celery).
- Trino: доля успешных запросов, p95 queued/execution time, количество воркеров/спиллы, task failures.
- ClickHouse: merges backlog, replication queue, parts, read/write latency, диск/ inode, rejected queries.
- Postgres: connections (max, used), locks/waits, replication lag, bgwriter, bloat, WAL.
- Airflow: task_duration p95, task_failed rate, scheduler delay, очередь executora.
- CDC/Kafka: lag по топикам/partition, ретенции, consumer group lag.
-
Платформа k8s:
- apiserver request duration/inflight,
- etcd commit/WAL latency, leader changes,
- scheduler e2e latency/pending pods,
- controller workqueue depth,
- kubelet pod start latency/NotReady nodes,
- kube-proxy sync, conntrack.
Для каждого домена задаём SLO (напр. «Успешность запросов Trino ≥ 99% за 30 дней; p95 latency ≤ 4 с»), строим дашборд SLO + алерты по burn-rate.
Компоненты и их роль
- Prometheus Operator (kube-prometheus-stack): CRD для Prometheus/Alertmanager/Grafana, ServiceMonitor/PodMonitor — меньше «ручного» конфигурирования.
- metrics-server: краткоживущие resource-метрики для HPA (не путать с Prometheus).
- kube-state-metrics: метрики по объектам (replicas, status, age, version).
- VictoriaMetrics: быстрая TSDB (single/cluster), дешёвое длительное хранение, пром-совместимо.
- Loki + Promtail: дешёвое хранение логов; лейблы/LogQL; globs/мультилайн.
- Alertmanager: маршруты по лейблам (team, severity), инхибирование, шаблоны, дежурства.
Кардинальность, ретенции и стоимость
- Кардинальность меток — враг TSDB/лог-индекса. Нельзя метить pod_uid, request_id, sql_hash и т. п. как лейблы — держите их в полях (для логов) или как значения (для метрик с histogram).
-
Ретеншн метрик:
- локально в Prometheus: 7–15 дней,
- длительно (VM/Thanos): 6–18 месяцев.
- Ретеншн логов:
- «горячие» 7–14 дней,
- архив (объектное хранилище) 90–180 дней.
- Скрап-интервалы: 15–30 с для основных; 1–5 м для «тяжёлых» экспортеров.
- Recording rules: вычисляйте p95/p99, rates и агрегаты заранее (меньше нагрузка на запросы и алерты).
Логи: структура и сбор
- Структурируйте логи JSON (уровень, ts, msg, request_id, user, duration_ms, status).
- Многострочные исключения (Java/Go) — настраиваем мультилайн в агенте.
- PII-защита: редактируйте/маскируйте на стороне приложения или на агенте (drop/replace).
- Label-схема в Loki: низкая кардинальность — cluster, namespace, app, container, pod (без uid), level, team. Идентификаторы запросов — только как поля.
- Аудит API: отдельный stream с меткой audit=true, парсинг полей (верб/ресурс/кто/где).
Алертинг без шума (Alertmanager + правила)
Подход: меньше «железа»-алертов, больше симптомов/бизнес-SLO. Склейка похожих алертов, инхибирование «нижних» при «верхнем» инциденте.
- Маршрутизация: по team, service, severity; каждый alert-rule содержит runbook_url, owner=team-X.
-
Иерархия:
- Critical — SLO нарушается (burn-rate), платформа не отвечает, потеря данных.
- Warning — тренд к деградации, «подготовиться».
- Burn-rate (пример): быстрый 5 мин и медленный 1 ч окна. Если оба красные — «срочно».
- Inhibition: при KubeAPIHighErrorRate подавляем «хвост» 5xx у приложений/Ingress (если причина на краю).
- Дежурства/тихие часы: интеграция с PagerDuty/Telegram/Slack, «сайлэнсы» на плановые окна.
Примеры идей правил (без деталей PromQL):
- APIServerHighLatency, EtcdHighCommitLatency, SchedulerHighPending.
- NodeNotReady (>=2 узла) > 5 мин.
- IngressHigh5xx + HighP95Latency.
- TrinoHighQueryFailureRate/LongQueue.
- CHReplicationQueueHigh / MergesBacklogHigh.
- PGReplicationLagHigh / ConnectionsExhausted.
- AirflowTaskFailureRateHigh / SchedulerDelayHigh.
- Bucket4xx/5xxHigh (S3/RGW).
- AuditK8sSuspiciousRBACChange (создан ClusterRole с *).
Практические шаги (лабораторка за 1–2 дня)
- Развернуть kube-prometheus-stack (Prometheus, Alertmanager, Grafana, ksm, node_exporter).
- Подключить экспортеры: Ingress, Postgres, ClickHouse, Trino, Airflow; проверить таргеты UP.
- Включить VictoriaMetrics (remote_write) или Thanos для длительного хранения; настроить ретеншн.
- Собрать SLO-дашборды: BI (p95 latency/5xx), Trino (success/queue), CH (replication/merges), PG (lag/conn). Добавить релиз-аннотации.
- Алерты-гейты: завести минимум 6 правил (APIServer/etcd/Ingress/Trino/CH/PG) с runbook_url и маршрутизацией по командам.
- Развернуть Loki+Promtail, задать схему лейблов, включить мультилайн; прогнать запросы LogQL, завести алерт по level="error" с фильтрами.
- Аудит API: включить политику аудита, слить в Loki, сделать дашборд «RBAC-изменения».
- Проверка шума: нагрузочный тест → оценить объём алертов; включить инхибирование и группировку.
Риски и анти-паттерны
|
Риск |
Проявление |
Что делать |
|---|---|---|
|
Шумные алерты |
Дежурные «глохнут», игнор |
SLO/burn-rate, инхибирование, группировка, дебоунс; ownership и runbook’и |
|
Взрыв кардинальности |
OOM у TSDB/Loki, медленные запросы |
Нормализуйте лейблы, дропайте pod_uid, используйте recording rules |
|
Ретенции без бюджета |
«Лопнул» диск, рост счетов |
План ретеншнов, холодное хранение в S3, компрессия |
|
metrics-server «путают» с мониторингом |
«Нет истории в Grafana» |
Выделить роли: metrics-server только HPA; исторические — Prometheus |
|
Собираем всё подряд |
Нагрузили API, TSDB |
Скрап-частота разумная, таргеты по ServiceMonitor, дропаут лишних метрик |
|
Логи без структуры |
Поиск «на удачу», медленно |
JSON-формат, request_id, уровни; анти-PII фильтры |
|
Нет аудита |
Не видно изменений прав |
Включить audit-лог, дашборды и алерты на RBAC-события |
Мини-фрагменты (ровно сколько нужно)
Алерт по burn-rate (идея, не копируйте без адаптации):
- alert: IngressSLOBurn
expr: (rate(nginx_ingress_controller_requests{status=~"5.."}[5m]) /
rate(nginx_ingress_controller_requests[5m])) > 0.02
for: 5m
labels: { severity: critical, team: bi, service: ingress }
annotations:
summary: "5xx на входе превышает бюджет ошибок"
runbook_url: "https://runbooks/ingress-5xx"
Политика аудита (эскиз):
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata
verbs: ["create","update","patch"]
resources:
- group: "rbac.authorization.k8s.io"
resources: ["clusterroles","clusterrolebindings","roles","rolebindings"]
Чек-лист «готово к продакшену»
- kube-prometheus-stack развёрнут; таргеты UP; ретеншн локальный ≥ 7 дней.
- Длительное хранение: VictoriaMetrics/Thanos; recording rules для p95/p99.
- Grafana: дашборды SLO для BI/Trino/CH/PG/Ingress; релиз-аннотации.
- Alertmanager: маршруты по командам, инхибирование, шаблоны, интеграция с он-коллом; runbook_url в правилах.
- Loki/Promtail: структурные логи, схема лейблов с низкой кардинальностью, мультилайн; ретеншн и архив.
- Аудит API включён, есть дашборд «RBAC-изменения» и алерт на «опасные» операции.
- Документы: SLO-каталог, регламент тюнинга алертов, runbook’и «Ingress 5xx», «Trino queue», «CH replication», «PG connections», «API latency».
Вопрос-ответ
В: Зачем нам VictoriaMetrics/Thanos, если есть Prometheus?
О: Prometheus хорош для «недели-двух». Для месяцев/лет и мультикластера — дешевле и надёжнее хранить в VM/Thanos (объектное S3, шардинг, репликация).
В: Loki или Elasticsearch?
О: Loki дешевле (индекс только по лейблам) и чаще «достаточен» для платформы/BI. Elasticsearch/OpenSearch — мощнее поиск/агрегации, но дороже в эксплуатации.
В: metrics-server не видно в Grafana, это баг?
О: Нет. Он — про HPA, а не историю. Историю собирает Prometheus с node_exporter/kubelet/kube-state-metrics.
В: С чего начать, чтобы не зашуметь алертами?
О: С SLO-дашбордов и 10–15 целевых правил (Ingress, API/etcd, Trino, CH, PG, Airflow). Сразу включите inhibition и burn-rate. Всё остальное — позже, итеративно.
В: Как привязать алерт к команде?
О: Лейблы team, service в правилах + маршруты в Alertmanager. Каждому правилу — runbook_url и владелец.
В: Что такое «взрыв кардинальности» и почему это больно?
О: Слишком много уникальных значений лейбла (например, sql_hash как лейбл). TSDB/индекс «встаёт». Делайте это как поля/значения, а не как лейблы; агрегируйте recording-rules.
В: Как контролировать стоимость логов?
О: Снизу: уровень логов (drop debug), выборочные источники, короткий «горячий» ретеншн, архив в S3, квоты на инжест/группы.
Устойчивая наблюдаемость — это не «поставить Grafana». Это дисциплина: Prometheus + долгое хранение, дашборды SLO, алерты по симптомам с burn-rate, структурные логи в Loki, аудит API, и строгий контроль кардинальности/ретеншна. Тогда алерты не будут шуметь, дежурные — выгорать, а BI/DWH — падать «внезапно».
