Модуль 5. Наблюдаемость и эксплуатация
Цель — не «собрать все метрики», а поддерживать SLO витрин и BI-сервисов за счет трёх слоёв:
- Метрики (Prometheus → Grafana): измеряем доступность, латентность, нагрузку, очереди и ошибки.
- Логи (EFK или Loki): находим причины, восстанавливаем контекст инцидента.
- Трейсинг (OpenTelemetry): видим «путь» запроса/вычисления сквозь компоненты.
Отсюда — понятия: SLI (что считаем), SLO (насколько должен быть хорош сервис), Error Budget (запас на ошибку) и burn-rate (скорость «сжигания» запаса).
Архитектура наблюдаемости для BI/DWH
Базовые компоненты
- Prometheus (сборщик), Alertmanager (алерты), Grafana (дашборды). В k8s удобно ставить kube-prometheus-stack (Helm), там же node-exporter и kube-state-metrics.
-
Exporters:
- postgres_exporter (Postgres),
- jmx_exporter (Trino/Java-компоненты через JMX),
- statsd_exporter или плагин «prometheus» для Airflow,
- clickhouse-exporter (если используете ClickHouse),
- minio/bucket metrics (для S3-совместимого хранилища).
- Логи:
- Лёгкая связка: Promtail → Loki → Grafana.
- Классика: EFK (FluentBit/Fluentd → Elasticsearch → Kibana).
- OpenTelemetry Collector как концентратор сигналов → Tempo/Jaeger/Zipkin для хранения трейсов.
- Интеграция точечная: Airflow, ваши сервисы, прокси/шлюзы.
- Трейсинг:
Данные длительного хранения
Prometheus как правило хранит 10–30 дней. Для истории (квартал/год) — Thanos/Cortex/Mimir (remote-write/объектное хранилище). Логи — ротация/retention по регламенту (обычно 7–30–90 дней по типам).
SLI/SLO для BI/DWH: договоримся о главном
Референс-набор SLI
- Доступность веб-BI: доля успешных 2xx/3xx ответов Ingress за 1/6/30 дней.
- Латентность BI-UI: p95 времени ответа Ingress по роуту / и /api/… (раздельно для интерактивных и фоновых запросов).
- Успешность запросов к движку: доля запросов Trino/ClickHouse/PG со статусом succeeded (по JMX/экспортерам).
- Латентность запросов: p95/p99 длительности по типам (dashboards, ad-hoc, фоновые отчёты).
- Свежесть данных (freshness): лаг между текущим временем и «временем последней успешной загрузки витрины».
- SLA ETL: доля DAG/джоб, завершившихся до дедлайна (например, до 06:00 местного времени).
- Ошибки коннекторов: скорость ошибок (5xx/timeout/auth) per connector.
- Ресурсы: использование CPU/Mem/IOPS vs requests/limits; падения Pod (restarts); заполнение PVC; очереди задач.
Примеры SLO
- BI-доступность: 99.5% в 30-дневном окне.
- Интерактивная латентность: p95 ≤ 2.5 с на ключевых эндпоинтах.
- Запросы к Trino: success rate ≥ 99%, p95 ≤ 10 с (на интерактивные), на бэч-задания — свой порог.
- Свежесть витрин: 99% витрин обновлены ≤ 60 мин назад в рабочее время.
- ETL до 06:00: 99% DAG на «зелёном».
Алертинг по бюджету ошибок (burn-rate)
Для SLO 99.5% месячного окна:
- Быстрые аварии: «5% бюджета за 1 час» (если error rate > 0.5% × 14.4 ≈ 7.2% в течение часа — page).
-
Тлеющие: «5% бюджета за 6 часов» (если error rate > 1.2% за 6 часов — ticket/уровень ниже).
Идея: две (или три) скользящие выдержки предупреждают и о вспышках, и о хронических проблемах.
Метрики: откуда и какие
Airflow
Два практичных пути:
- Через StatsD: Airflow посылает метрики (длительность задач, SLA, количество ретраев) в statsd_exporter, Prometheus снимает метрики.
- Через плагин Prometheus: прямо /metrics у веб-сервиса/шедулера (удобно в k8s-деплое).
Ключевые метрики: task_duration_seconds, dag_processing_duration, task_retries, dag_sla_miss_total, «время последнего успеха по DAG».
Trino (или Presto)
Trino публикует JMX-метрики; кладём jmx_exporter (Java-agent или sidecar). Важные группы:
- trino.execution (запросы, очереди, завершения, провалы),
- trino.memory (использование pool’ов),
- trino.operator (операторы скана/джойнов),
-
jvm.* (GC, heap).
Метрики по «хвостам» (p95/p99) строим из bucket’ов Histogram (если доступны) или рассчитываем по сводным.
Postgres
postgres_exporter + включённый pg_stat_statements. Смотрим:
- pg_up, pg_connections, xact_commit/rollback, checkpoint/write/flush, лаг репликации, размер WAL,
- показатели по «тяжёлым» запросам (время, частота, I/O),
- long_running_transactions и блокировки.
Инфраструктура
- kube-state-metrics (состояние k8s объектов),
- node-exporter (CPU/Mem/IO/NET),
- cAdvisor (контейнерные ресурсы),
- S3/MinIO: latency операций, коды ошибок (важно для экспорта BI/бэкапов).
Логи: что и где искать
Loki (легковесно) или EFK (шире функционал)
- Loki хорош малым footprint’ом и интеграцией с Grafana.
- EFK мощнее по полнотексту/агрегациям (Elasticsearch), но тяжелее.
Полезные логи в BI/DWH
- Ingress/прокси: статус-коды, время ответа, URI, пользователь/группа (если передаёте через SSO заголовки), размер ответов, upstream-status.
- BI-приложения: auth/SSO, ошибки визуализаций/коннекторов, экспорт/импорт файлов.
- Trino/ClickHouse: query log (id, user, source, время, итог, причина ошибки).
- Airflow: ошибки задач, ретраи, SLA-miss.
- Postgres: ошибки запросов, deadlock’и, autovacuum events.
Рекомендации:
- Редактируйте лог-форматы в сторону structured (JSON) → проще агрегировать.
- Редактируйте/маскируйте PII (лог-редакторы/плагины).
- Введите корреляционные id (например, X-Request-ID) — связывайте логи с трейсом.
Трейсинг: когда он нужен и как включать
- Для «почему именно этот отчёт отрисовался 12 секунд» без трассировки часто не обойтись.
- OpenTelemetry Collector принимают OTLP (HTTP/gRPC) и экспортируют в Tempo/Jaeger.
-
Что реально трассировать:
- Ваши микросервисы/прокси (если есть) — обязательно.
- Airflow — опционально: шаги DAG как спаны, особенно при внешних вызовах.
- BI-фронт — чаще ограничиваемся метриками/логами; полноценный APM — по необходимости.
- Минимум — придумайте и внедрите корелляционный идентификатор и прокидывайте его в запросы к Trino/БД.
Эксплуатационные дашборды (что должно быть «по умолчанию»)
Дашборд «SLO BI»
- Availability: 30-дневная кривая 2xx/3xx, «окно 1ч/6ч burn-rate».
- Latency: p50/p95/p99 по / и /api/*, отдельно по регионам/Ingress.
- Error rate: 4xx/5xx, top-URI по ошибкам, распределение по пользователям/группам.
- Capacity: HPA масштабирования, CPU/Mem BI-подов vs requests.
Дашборд «Trino/Запросы»
- Очередь, активные/завершённые, провалы по причинам; p95 длительности; top-users; расход памяти pool.
- Отдельная секция «тяжёлые операторы» (скан/джойн).
Дашборд «Airflow/ETL-SLA»
- Сколько DAG выполнено до дедлайна, сколько ретраев, средняя/p95 длительность задач, зависания.
- «Время последнего успеха» для ключевых витрин (freshness heatmap).
Дашборд «Postgres/БД»
- Подключения, блокировки, лаг репликации, чекпоинты, рост базы, топ-запросы по времени/IO, autovacuum.
Дашборд «Платформа k8s»
- Ошибки Ingress, рестарты Pod, CrashLoop, заполнение PVC, утилизация нод, throttle по CPU, saturations сети/IO.
Алертинг: практические правила
- SLO-alerts (burn-rate) — главный слой (page on-call).
- Сатурации/исчерпания (квоты/диск/соединения/очереди) — предупреждения до инцидента.
- Сигнал-to-noise: лучше 10 качественных правил с корректной дедупликацией, чем 100 «писем каждую минуту».
- Шаблоны сообщений: включайте «что делать дальше» (ссылка на runbook, Grafana-дашборд, команда rollback).
Практика: собрать метрики Airflow/Trino/Postgres и сделать дашборд SLO
Подготовка (высокоуровнево)
- Установите kube-prometheus-stack (Prometheus, Alertmanager, Grafana).
- Включите ServiceMonitors/PodMonitors в вашем Helm-стеке (или создайте вручную).
-
Деплойте экспортёры:
- Airflow: включите метрики (StatsD → statsd_exporter или плагин Prometheus), убедитесь, что /metrics доступен.
- Trino: добавьте jmx_exporter (Java-agent) и пробросьте HTTP endpoint для скрейпа.
- Postgres: разверните postgres_exporter, дайте доступ к pg_stat_*; включите pg_stat_statements.
- Добавьте MinIO/Ingress метрики (если ещё нет): для Ingress — включите экспорт метрик контроллера.
Что именно собрать
- BI SLI: из метрик Ingress — долю 2xx/3xx, распределение латентности (histogram_bucket).
- Trino: общее число запросов, успешные/ошибки, длительности (если есть гистограммы; если нет — собираем «спаниe времени» по событиям, как суррогат).
- Airflow: dag_sla_miss_total, task_duration_seconds_bucket, «время последнего успеха».
- Postgres: pg_up, лаг репликации, pg_stat_statements по top N.
Дашборд «BI SLO» в Grafana
Секции:
- SLO summary: текущий SLO месяца, использованный бюджет, burn-rate 1ч/6ч.
- Availability: граф ошибки (Ingress 5xx/все), аннотации релизов.
- Latency: p50/p95/p99 по BI-эндпоинтам (раздельно для UI и API).
- ETL SLA: до скольки % DAG успели до 06:00; витрины с «красным» freshness.
- Trino success/latency: success rate, p95 по интерактивным запросам.
- Postgres health: pg_up, лаг репликации, активные соединения.
Быстрые алерты (через Alertmanager)
- BI Availability Burn-rate (две выдержки) → page.
- Freshness витрин (просрочка > X мин) → page владельцу домена данных.
- Trino queue length/координатор down → page.
- Postgres lag > N секунд / connections > 90% → warn → page при эскалации.
Риски и анти-паттерны
-
Взрыв кардинальности метрик (лейблов слишком много: query_id, user_id, sql_text).
Решение: белые списки лейблов, дропаут лишних через relabeling, агрегация на стороне экспорта (сводные по типам/ролям, не по id). -
Завал логами/дорогая индексация.
Решение: уровни логов по средам, ретеншн по классам данных, семплирование шумных потоков, регулярные расходы в TCO. -
Алерт-штормы (десятки писем из одной причины).
Решение: группировка, дедупликация, приоритеты; «супер-алерты» на сервисный SLO, а не на каждую мелочь. -
Метрики без runbook’ов («что делать — непонятно»).
Решение: у каждого критичного алерта — ссылка на шаги диагностики, rollback, контакты владельца. -
Не защищены эндпоинты метрик.
Решение: ограничить сетью (NetworkPolicy), basic-auth/mTLS для внешних, не светить /metrics наружу. -
Нет связи метрик ↔ релизы.
Решение: аннотации релизов в Grafana, принудительная проверка SLI после выката (post-deploy checks).
Операционные практики (day-2)
- Еженедельный обзор SLO с владельцами доменов: где «жжёт» бюджет, какие долгие отчёты, какие DAG системно опаздывают.
- Capacity review раз в месяц: CPU/Mem/IOPS/сеть, рост PVC, «дорогие» запросы.
- Blameless postmortem на P1 инциденты: корневая причина, действия, «SLO-гигиена».
- Хаос-дни (по согласованию): падение ноды/Ingress/MinIO — проверка алертов и runbook’ов.
- Автоматические отчёты (Grafana report) об ошибках коннекторов, просроченных витринах, «тяжёлых» запросах.
Мини-чек-лист перед продом
- kube-prometheus-stack установлен, есть доступ Grafana/Alertmanager.
- Есть экспортеры для Airflow, Trino (JMX), Postgres, Ingress, MinIO.
- Дашборды: BI-SLO, Trino-queries, Airflow-SLA, Postgres-health, k8s-platform.
- SLO сформулированы и подписаны бизнесом; алерты по burn-rate настроены.
- Ретеншн/стоимость логов и метрик зафиксированы; есть план архивирования.
- Логи структурированы, маскировка PII настроена.
- Отдельный runbook на каждую критическую тревогу; «владельцы» указаны.
- Метрики/логи/трейсы не содержат секретов; доступ ограничен RBAC.
Наблюдаемость — это соглашение о качестве (SLO), а не просто Grafana с красивыми графиками. Собираем только те сигналы, которые помогают держать SLO, строим дашборды «по ролям», включаем burn-rate-алерты и держим рядом runbook’и. Тогда BI/DWH в k8s становится управляемым сервисом, а не набором «слегка работающих» компонентов.
