← вся теориятеория к собесу · Инфраструктура данных

Наблюдаемость дата-пайплайнов

Наблюдаемость: три сигнала

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

Стержень: зелёная джоба - не метрика качества данных; алертят по симптомам для потребителя, а копают по причинам.

// Формулировки: «какие три сигнала наблюдаемости?», «на что заводить алерт?», «что такое кардинальность метрик?».

Метрики, логи, трейсы

Три сигнала под разные вопросы. Метрики - числа во времени: дёшевы, дают тренды и алерты. Логи - события с контекстом: дороги, нужны для разбора. Трейсы - путь запроса через сервисы: показывают, где именно медленно.

Prometheus-модель: сервисы отдают /metrics, сервер собирает их pull'ом, PromQL считает rate и квантили, Grafana рисует. Для батч-джоб - Pushgateway, потому что pull не поймает короткоживущее.

// Логи делают структурированными (JSON) с контекстом - job_id, партиция, счётчики - в центральном сторе (Loki, ELK). Grep по машинам - не стратегия наблюдаемости, а её отсутствие.

metrics / logs / traces: три сигнала: тренды / разбор / путь запроса
Pushgateway: приём метрик короткоживущих батч-джоб
ELK: Elasticsearch, Logstash, Kibana

Метрики данных и алерты

Для пайплайнов данных метрики свои: свежесть (lag от источника), объёмы против истории, длительность стадий, доля ошибок и ретраев. «Джоба зелёная» не отвечает на вопрос качества данных - кластер здоров, а витрина три дня не обновлялась.

Алерт это симптом с действием и runbook'ом. «Данные опаздывают к SLA (service level agreement)» - да, есть что делать. «CPU 80%» без последствий - шум, который команда замьютит вместе со всеми алертами канала.

// Правило разделения: алерты по симптомам для потребителя (свежесть витрины), дашборды по причинам (какая стадия встала). Наоборот - узнаёшь о проблеме от бизнеса, а не от мониторинга.

SLO / error budget: целевой уровень и допустимый запас нарушений
симптом vs причина: алерт по боли потребителя / дашборд по источнику

SLO и кардинальность

SLO (service level objective) и error budget превращают расплывчатую «надёжность» в измеримое: «данные готовы к 8:00 в 99% дней» это цель и допустимый бюджет нарушений, по которому приоритизируют работу.

Кардинальность меток метрик держат под контролем: user_id или query_id в лейблах Prometheus это взрыв временных рядов, который кладёт мониторинг раньше прода.

// Высокую кардинальность отправляют туда, где ей место, в логи и трейсы, а не в метки метрик. Метрики - для агрегатов и трендов, а не для поиска конкретного пользователя.

PromQL rate(): скорость счётчика - основа графиков и алертов
cardinality: число уникальных комбинаций меток метрики

Как отвечать: «Три сигнала наблюдаемости, и на что заводить алерты?»

Три сигнала - метрики, логи, трейсы. Метрики это числа во времени: дёшевы, дают тренды и питают алерты. Логи - события с контекстом, дорогие, но незаменимы для разбора конкретного инцидента, поэтому их делают структурированными с job_id и складывают централизованно. Трейсы показывают путь запроса через сервисы и отвечают, где именно медленно. Для данных добавляю свои метрики: свежесть, объёмы против истории, долю ошибок - потому что «джоба зелёная» не значит «данные свежие». Про алерты у меня жёсткое правило: алерт это симптом с действием и runbook'ом, а не любое отклонение. Алертю по симптомам, которые чувствует потребитель, витрина опаздывает к SLA, а причины, какая стадия встала, смотрю на дашбордах. Если наоборот, узнаю о проблеме от бизнеса. И слежу за кардинальностью: user_id меткой в Prometheus взорвёт число рядов и положит мониторинг, поэтому такое - в логи и трейсы.

Почему это сильный ответ: три сигнала с их ролями, метрики данных поверх инфраструктурных, правило алертов (симптом + runbook, по потребителю) и осознание кардинальности - зрелая наблюдаемость, а не «поставлю Grafana».

На чём валят

−Мониторить только инфраструктуру: кластер здоров, витрина три дня не обновлялась.
−Алерты без runbook и владельца - канал замьючен всей командой.
−user_id меткой в Prometheus - миллионы рядов, мониторинг лёг раньше прода.
−Логи без структуры и request_id - инцидент разбирается грепом по интуиции.
−Дашборд на 60 панелей вместо трёх симптомных алертов - «наблюдаемость» для галочки.

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 10, остальные разбираются в тренажёре.

#observability1 / 5
Как устроен сбор метрик через Prometheus?
A)Push-модель: каждый сервис сам постоянно отправляет свои метрики прямо в базу Prometheus
B)Pull-модель: Prometheus периодически сам опрашивает (scrape) HTTP-эндпоинты сервисов с метриками и хранит их как временные ряды
C)Prometheus хранит метрики как обычные текстовые логи событий без привязки ко времени
D)Prometheus собирает метрики, лишь когда инженер вручную запускает опрос через веб-интерфейс
показать ответ и разбор
+B)Pull-модель: Prometheus периодически сам опрашивает (scrape) HTTP-эндпоинты сервисов с метриками и хранит их как временные ряды
// разбор: Prometheus работает по pull-модели: приложения/экспортеры выставляют HTTP-эндпоинт (обычно /metrics) с текущими значениями метрик, а сервер Prometheus по расписанию сам опрашивает (scrape) эти эндпоинты и складывает значения как временные ряды с метками (labels). Это отличается от push-модели (агент шлёт метрики в коллектор): pull упрощает обнаружение живости целей (не отвечает — значит недоступен) и конфигурацию в динамичной среде (service discovery в K8s). Поверх метрик пишут запросы (PromQL) для графиков и правил алертинга. Для коротких батч-задач, которые не живут до scrape, есть Pushgateway.
#observability2 / 5
Какова роль Grafana в связке с Prometheus?
A)Grafana сама собирает и хранит метрики со всех сервисов, заменяя собой Prometheus
B)Grafana — это база данных временных рядов, куда сервисы пишут свои метрики напрямую
C)Визуализация и алертинг: строит дашборды и графики по метрикам (запросами к Prometheus) и шлёт оповещения по заданным условиям
D)Grafana запускает и оркеструет контейнеры пайплайнов по расписанию вместо Airflow
показать ответ и разбор
+C)Визуализация и алертинг: строит дашборды и графики по метрикам (запросами к Prometheus) и шлёт оповещения по заданным условиям
// разбор: Grafana — слой визуализации и алертинга поверх источников метрик. Она подключается к Prometheus (и другим), выполняет запросы (PromQL) и рисует дашборды: графики нагрузки, длительности пайплайнов, числа ошибок, свежести данных — в реальном времени. Поверх метрик настраивают правила оповещений: превысил порог — ушёл алерт в Slack/почту/PagerDuty. Разделение ролей: Prometheus собирает и хранит метрики, Grafana их показывает и оповещает. Для дата-платформы это единая панель здоровья: видно тренды и аномалии по пайплайнам и инфраструктуре, не заглядывая в сырые метрики.
#observability3 / 5
Что важно мониторить в дата-платформе помимо CPU/памяти серверов?
A)Достаточно мониторить только CPU и память узлов — если железо здорово, данные наверняка верны
B)Мониторить дата-платформу вообще не нужно: пайплайны либо падают с ошибкой, либо всё идеально
C)Основная важная метрика дата-платформы — это скорость сети между узлами кластера
D)Длительность/падения задач, свежесть, объём, лаг, DQ — а не только железо
показать ответ и разбор
+D)Длительность/падения задач, свежесть, объём, лаг, DQ — а не только железо
// разбор: Инфраструктурные метрики (CPU, память, диск) необходимы, но недостаточны для дата-платформы: сервер здоров, а данные при этом «сломаны». Мониторят и уровень данных/пайплайнов: успешность и длительность задач (растёт — деградация), свежесть данных (freshness/SLA: обновилось ли вовремя), объём (внезапно 0 или вдвое меньше строк — тихий сбой источника), лаг стримов, доля ошибок качества, стоимость запросов. Эти сигналы ловят проблемы, невидимые на уровне железа. Идеал — алерт до того, как кривые данные заметит потребитель. По сути это наблюдаемость данных (data observability) поверх обычной инфра-наблюдаемости.
#observability4 / 5
Команду заваливает алертами, и на них перестают реагировать. В чём проблема и что делать?
A)Усталость от шума; алерт только на actionable/нарушение SLO, прочее в дашборды
B)Проблема в том, что алертов слишком мало — нужно добавить оповещение на каждое изменение метрики
C)Решение — просто отключить все алерты полностью, положившись на ручную проверку дашбордов
D)Алерты нужно слать на все метрики без разбора, а инженеры сами разберутся, какие важны
показать ответ и разбор
+A)Усталость от шума; алерт только на actionable/нарушение SLO, прочее в дашборды
// разбор: Если алертов слишком много и часть — ложные или неважные, наступает alert fatigue: важное тонет в шуме, и на оповещения перестают реагировать (пропускают реальный инцидент). Лечение — алертить только на то, что действительно требует немедленного вмешательства человека: нарушение SLO/симптом, влияющий на потребителя (данные не обновились, пайплайн упал совсем), а не на каждое временное колебание. Остальное — в дашборды для разбора, не в пейджер. Плюс: осмысленные пороги (от истории, не жёсткая константа), дедупликация, группировка, приоритеты. Каждый алерт должен быть actionable — иначе его не должно быть.
#observability5 / 5
Почему логи пайплайнов делают структурированными (JSON) с идентификатором прогона (run id)?
A)Структурированные логи нужны чтобы они красивее выглядели для человека при чтении
B)Машинно-парсимые поля + run id связывает события одного прогона
C)Run id замедляет систему, поэтому в логах его добавлять не рекомендуется ради производительности
D)JSON-логи сложно фильтровать по полям, поэтому для поиска они хуже обычного текста
показать ответ и разбор
+B)Машинно-парсимые поля + run id связывает события одного прогона
// разбор: Плоский текстовый лог трудно разбирать машинно и невозможно надёжно фильтровать. Структурированный лог (JSON с полями: время, уровень, сервис, run_id, task, метрики) парсится системой сбора логов, по нему строят фильтры, агрегации и алерты. Ключевое — идентификатор прогона (run/correlation id), проставляемый во все события одного запуска пайплайна: по нему из общего потока логов собираются все шаги именно этого прогона в цепочку, что резко ускоряет разбор инцидента среди тысяч перемешанных строк. В распределённых пайплайнах это связывает события между сервисами и задачами. Без структуры и run id логи — стог сена.

дальше

Теорию прочитали. Навык ставится повторением

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

Открыть тренажёр Вся тема: Инфраструктура данных