Мониторинг и логирование DWH, часть 1: уровни контроля, метрики и типовые проблемы

Архитектура корпоративной платформы данных содержит множество потенциальных точек отказа: проблема может возникнуть при получении данных из источника, во время их обработки и загрузки, на уровне инфраструктуры или BI.

Техническая доступность DWH еще не означает, что все работает корректно. Данные могут загружаться с задержкой или не в полном объеме, процессы выполняться дольше обычного, а производительность системы постепенно снижаться.

Поэтому при эксплуатации DWH используют инструменты мониторинга и логирования, которые позволяют контролировать состояние компонентов платформы, своевременно выявлять сбои и быстро определять их причины.

В первой части материала про мониторинг DWH разберем, что именно необходимо контролировать на каждом уровне DWH и какие сигналы помогают своевременно обнаружить проблемы.

Основные понятия Observability хранилища

Observability (наблюдаемость) — это подход, который позволяет по данным о работе системы понимать ее текущее состояние и находить причины возникающих проблем. 

Для обеспечения наблюдаемости используются три основных типа телеметрии: метрики, логи и трассировки.

Мониторинг — это процесс непрерывного сбора и анализа метрик, которые характеризуют состояние системы. Для DWH мониторинг позволяет обнаруживать проблемы с инфраструктурой и процессами обработки данных до того, как они отразятся на работе аналитиков и бизнес-пользователей.

Логирование — процесс формирования логов — фиксации событий, происходящих внутри приложений, сервисов и компонентов. Существует несколько типов логов:

• Application logs — фиксируют события приложений;

• System logs — содержат события операционной системы и инфраструктуры;

• Audit logs — фиксируют действия пользователей и сервисов и позволяют определить, кто, когда и какие операции выполнял;

• Security logs — содержат события, связанные с безопасностью системы, например попытки авторизации или нарушения политик доступа.

Трассировка (трейсинг) — это метод отслеживания пути запроса через все компоненты и функции системы.

Классическая трассировка ориентирована прежде всего на микросервисные системы. В DWH процессы асинхронные, могут выполняться часами и связываться через ETL/ELT, брокеры сообщений или таблицы.

Поэтому вместо стандартной трассировки в DWH чаще используются механизмы:

• Сквозной run_id – единый идентификатор запуска, который передается в логи, метрики и другие компоненты и позволяет восстановить историю конкретной загрузки.

• Data Lineage – показывает зависимости между источниками, таблицами и витринами и помогает определить, какие объекты затронул сбой. Для сбора lineage-событий может использоваться OpenLineage, а для их анализа – DataHub или OpenMetadata.

Архитектура системы мониторинга DWH

Мониторинг DWH устроен следующим образом:

• Приложения и инфраструктурные сервисы генерируют метрики, логи и трассировки.

• Экспортеры и агенты собирают эту информацию, после чего она передается в централизованные системы хранения и анализа.

• Поверх них работают визуализация, алертинг и инструменты диагностики.

Уровни мониторинга корпоративного хранилища

В DWH нет одной точки отказа, ошибка может возникнуть практически на любом участке data pipeline, поэтому важно контролировать состояние каждого компонента хранилища.

Инфраструктура

На уровне серверной инфраструктуры обычно контролируются:

• CPU — загрузка процессора;

• RAM — использование оперативной памяти;

• Disk — свободное дисковое пространство, скорость операций чтения и записи;

• Network — сетевой трафик, пропускная способность и задержки;

• Latency — время выполнения операций или ответа сервиса;

• доступность серверов и отдельных узлов кластера.

Что алертить: симптом или причину

На одном из DWH-проектов для крупного ритейлера мы столкнулись с ситуацией, когда система мониторинга прислала алерт о заполнении дисков кластера Greenplum на 90%. Объем занятого пространства продолжал расти до 95% и создавал риск остановки кластера. От получения алерта до подключения команды поддержки прошло около 30 минут.

Диагностика показала, что проблема была не в росте объема данных. Во время плановой перезагрузки сети primary и mirror сегменты Greenplum поменялись ролями, после чего один из primary сегментов стал недоступен. Mirror сегменты начали накапливать WAL-логи, которые быстро заполнили дисковое пространство. Таким образом, мониторинг дискового пространства сработал, но обнаружил уже следствие инцидента, а не его первопричину.

После инцидента специалисты Qlever Solutions углубили мониторинг дискового пространства Greenplum и добавили кастомные проверки, позволяющие выявлять подобные сбои раньше. Повторных проблем такого типа с тех пор не наблюдалось.

Этот пример показывает важный принцип проектирования мониторинга: для критичных компонентов недостаточно контролировать только последствия деградации — заполнение дисков, рост очередей или увеличение времени ответа.

Необходимо также отслеживать состояние компонентов, сбой которых может привести к этим последствиям: доступность узлов, состояние репликации и работу ключевых сервисов СУБД.

Так система мониторинга позволяет не только раньше обнаружить инцидент, но и быстрее локализовать его причину.

ETL/ELT и оркестрация

Для ETL/ELT-процессов отслеживаются:

• статус выполнения пайплайнов и отдельных задач;

• продолжительность выполнения;

• количество ошибок и повторных запусков;

• объем обработанных данных;

• время последней успешной загрузки;

• соблюдение расписания и заданных временных окон;

• отклонение продолжительности выполнения от обычных значений.

Отдельно необходимо контролировать состояние оркестратора: работу планировщика (scheduler), исполнителей (workers), очереди задач и доступность его основных компонентов.

Обычно оркестраторы, такие как Apache Airflow, предоставляют встроенные механизмы логирования задач, сбора метрик, проверки состояния компонентов и уведомления об ошибках. 

Кроме Airflow тот же набор задач решают Dagster (встроенное понятие ассета со сроком свежести), Prefect, Windmill, а для трансформаций - dbt, который после каждого запуска пишет артефакты run_results.json и manifest.json.

Как получить метрики оркестратора

Airflow отдает внутренние метрики по протоколу StatsD, чтобы они попали в Prometheus, между ними ставят statsd_exporter. Начиная с версии 2.7 Airflow умеет отправлять метрики через OpenTelemetry, что убирает лишнее звено, если в контуре уже есть OTel Collector.

Группы метрик, которые мы отслеживаем на проектах для контроля работы Airflow:

• Состояние Scheduler — например, airflow_scheduler_heartbeat (жив ли планировщик), airflow_scheduler_scheduler_loop_duration (длительность scheduler loop), airflow_zombies_killed (убитые zombie tasks).

• Executor и очереди — airflow_executor_open_slots (свободные слоты Executor), airflow_executor_queued_tasks (задачи в очереди Executor), airflow_pool_starving_tasks (задачи, ожидающие Pool).

• DAG Run — airflow_dagrun_schedule_delay (задержка запуска относительно расписания), airflow_dagrun_duration_success (длительность успешного DAG Run), airflow_dagrun_duration_failed (длительность неуспешного DAG Run).

• Task Instance — airflow_ti_successes и airflow_ti_failures (успешные и неуспешные Task Instance), airflow_task_duration (длительность выполнения task), airflow_task_queued_duration (время task в очереди).

• Обработка DAG-файлов — airflow_dag_processing_* (метрики процесса обработки DAG-файлов), airflow_dag_file_processor_timeouts (таймауты обработки DAG-файлов), airflow_dagbag_size (размер DAG Bag).

• Ресурсы задач — airflow_task_cpu_usage_percent (использование CPU task в процентах), airflow_task_memory_usage_percent (использование памяти task в процентах).

Качество данных (Data Quality)

Для мониторинга качества данных используются специализированные инструменты Data Quality. В зависимости от требований к конкретному набору данных могут контролироваться:

• полнота (completeness) — наличие всех необходимых данных;

• уникальность (uniqueness) — отсутствие недопустимых дубликатов, в том числе ключей;

• валидность (validity) — соответствие значений установленным форматам, типам и допустимым диапазонам;

• целостность (integrity) — корректность связей между данными, в том числе ссылочная целостность;

• свежесть(freshness) — своевременность обновления данных;

• количество записей и объем поступивших данных;

• доля NULL в критичных полях;

• соответствие установленным бизнес-правилам.

В DWH мониторинг качества данных особенно важен, так как влияет непосредственно на качество аналитику и работу пользователей. Например, если таблица ежедневно получает около 2 млн записей, а при очередной загрузке поступило только 150 тыс., ETL-пайплайн может технически завершиться успешно. Однако резкое изменение объема данных должно быть зафиксировано, отправлено в систему мониторинга и стать поводом для проверки источника и процесса загрузки.

Чем проверять качество данных

1. Проверки внутри пайплайна - срабатывают на каждой загрузке и умеют останавливать ее при провале.

• dbt tests — если трансформации уже написаны на dbt, базовые проверки (unique, not_null, accepted_values, relationships) не требуют нового инструмента; пакеты dbt-utils и dbt-expectations расширяют набор;

• Great Expectations — библиотека на Python с декларативным описанием ожиданий и автогенерацией отчетов, гибкая, но требует отдельной инфраструктуры и времени на освоение;

• Soda Core — проверки описываются на YAML-подобном SodaCL, порог входа ниже.

2. Мониторинг качества и аномалий данных - дополняет проверки, выполняемые непосредственно в пайплайне. Анализирует состояние и изменение наборов данных, позволяет обнаруживать отклонения, которые сложно заранее описать фиксированными правилами.

• Elementary — решение для Data Observability, тесно интегрированное с dbt. Использует результаты dbt-запусков и метаданные хранилища для мониторинга качества данных, freshness, объемов и других характеристик, а также обнаружения аномалий относительно исторического поведения данных.

• Специализированные платформы Data Observability, например Monte Carlo, Datafold и Anomalo, решают более широкий набор задач мониторинга состояния данных и обнаружения аномалий и не требуют использования dbt как основы всего контура наблюдаемости.

3. Каталог и Data Lineage

DataHub и OpenMetadata хранят описания таблиц, владельцев и граф зависимостей. Для качества данных это нужно, чтобы у каждой проверки был ответственный, а у каждого инцидента — список пострадавших витрин.

Результаты проверок качества данных можно передавать в Prometheus и отображать вместе с техническими метриками в Grafana, чтобы у команды был единый интерфейс мониторинга. Для более детального анализа качества данных можно использовать собственный интерфейс Elementary - Observability Report. 

BI и пользовательские запросы

На этом уровне отслеживаются доступность и производительность аналитических приложений:

• время выполнения запросов, загрузки отчетов и дашбордов;

• ошибки выполнения запросов и обновления отчетов;

• нагрузка на BI-серверы;

• доступность подключений к источникам данных;

• частота и успешность обновления наборов данных;

• время последнего успешного обновления;

• использование вычислительных ресурсов BI-платформы;

• количество одновременных пользователей и запросов.

Таким образом, мониторинг DWH охватывает несколько уровней: инфраструктуру, ETL/ELT-процессы, качество данных и взаимодействие с системами-потребителями.

Как собирать метрики и объединить их в единый контур мониторинга?

Во второй части материала о мониторинге DWH рассмотрим конкретные инструменты: Prometheus, Grafana, Zabbix, ELK Stack, OpenSearch, Loki. Расскажем про подходы к выбору стека для мониторинга DWH.