В первой части материала мы разобрали, что необходимо контролировать в корпоративном хранилище данных - от инфраструктуры и ETL/ELT-процессов до Data Quality и выполнения запросов:
Мониторинг и логирование DWH, часть 1: уровни контроля, метрики и типовые проблемы
Во второй части перейдем к конкретным инструментам: Prometheus, Grafana, Zabbix, ELK Stack, OpenSearch, Loki. Разберем, как они устроены, какие задачи решают, чем отличаются друг от друга и на что обратить внимание при выборе стека для мониторинга и логирования DWH.
Если коротко
Наблюдаемость DWH обычно развивается поэтапно: от контроля технического состояния платформы до мониторинга качества данных и выполнения требований к data-продуктам.
Сценарий | Основная задача | Что контролируем | Что добавляем |
1. Базовый мониторинг DWH | Понять, работает ли платформа и выполняются ли процессы загрузки | Инфраструктура, СУБД, состояние сервисов, выполнение пайплайнов, ошибки, длительность загрузок | Prometheus / Zabbix, Grafana, Alertmanager, метрики оркестратора |
2. Мониторинг данных и качества | Понять, поступили ли ожидаемые данные и соответствуют ли они требованиям | Freshness, completeness, uniqueness, NULL, объемы данных, бизнес-правила, результаты DQ-проверок | dbt tests и source freshness, при необходимости специализированные DQ-инструменты |
3. Централизованная наблюдаемость распределенной платформы | Унифицировать сбор и анализ телеметрии большого количества компонентов | Метрики, логи и трассировки сервисов и инфраструктуры, состояние самого observability-контура | OpenTelemetry Collector, централизованное хранение метрик, логов и трассировок |
4. Data Observability и контроль data-продуктов | Контролировать весь путь данных и выполнение требований перед потребителями | SLI/SLO data-продуктов, готовность и актуальность данных, зависимости и влияние сбоев на downstream-объекты | Data lineage, корреляция запусков, мониторинг SLO и impact analysis |
Каждый следующий сценарий не заменяет предыдущий, а дополняет его. В результате контур наблюдаемости постепенно расширяется от технического мониторинга инфраструктуры до контроля всего пути данных, от источника до конечного потребителя.
Инструменты мониторинга
Prometheus
Prometheus — open-source система мониторинга и алертинга, предназначенная для сбора, хранения и анализа метрик.
В DWH-инфраструктуре Prometheus может использоваться для мониторинга серверов, баз данных, ETL/ELT-компонентов, оркестраторов и других сервисов платформы.
Prometheus хранит метрики в виде временных рядов (time series): каждое значение связано с временной меткой и может содержать набор дополнительных меток (labels). Такой подход позволяет анализировать изменение показателей во времени и детализировать их по серверам, сервисам, экземплярам приложений и другим параметрам.
Одна из ключевых особенностей Prometheus — pull-модель сбора метрик - система мониторинга сама периодически опрашивает сервисы и экспортеры метрик, получая от них текущие значения показателей. Такая модель хорошо подходит для динамических инфраструктур, где сервисы могут часто появляться и исчезать (например, в контейнерных средах).
Если приложение не предоставляет метрики в формате Prometheus напрямую, для их получения могут использоваться экспортеры (exporters) и другие инструменты сбора метрик:
node_exporter — собирает метрики операционной системы и оборудования: CPU, память, диски, файловые системы и сеть;
postgres_exporter — используется для получения метрик PostgreSQL: соединения, транзакции, блокировки, состояние БД и другие показатели;
для ClickHouse метрики могут собираться через совместимые экспортеры или встроенные механизмы;
cAdvisor (Container Advisor) — инструмент для мониторинга контейнеров, собирающий данные об использовании CPU, памяти, сети и дисковых ресурсов;
blackbox_exporter — позволяет проверять доступность сервисов извне, например по HTTP/HTTPS, TCP, ICMP и DNS.
Для анализа собранных метрик используется PromQL (Prometheus Query Language). С его помощью можно выполнять выборку и агрегацию временных рядов, рассчитывать производные показатели и формировать условия для обнаружения отклонений.
При выполнении заданных условий Prometheus формирует алерты, которые могут передаваться в Alertmanager. Он отвечает за группировку, маршрутизацию и отправку уведомлений во внешние каналы.
Основные преимущества Prometheus
специализированная модель хранения и обработки временных рядов;
гибкий язык запросов PromQL;
развитая экосистема экспортеров и интеграций;
поддержка service discovery;
удобная интеграция с Kubernetes и другими cloud-native технологиями;
возможность настройки правил алертинга.
Ограничения Prometheus
Локальное хранилище Prometheus подходит для автономной работы и позволяет настраивать срок и объем хранения метрик. Однако при необходимости длительного хранения больших объемов данных, высокой доступности или масштабирования за пределы одного сервера могут потребоваться дополнительные компоненты:
VictoriaMetrics — совместима с протоколом Prometheus, экономнее по диску и памяти, есть одноузловая и кластерная версии;
Thanos — добавляет к Prometheus объектное хранилище, глобальный запрос по нескольким инсталляциям и дедупликацию;
Grafana Mimir — горизонтально масштабируемое хранилище с мультитенантностью.
Выбор между инструментами определяется компетенциями команды: VictoriaMetrics разворачивается и сопровождается заметно проще.
Встроенный интерфейс Prometheus предназначен прежде всего для выполнения запросов и технической работы с метриками. Для построения полноценных мониторинговых дашбордов на практике чаще используется Grafana.
Grafana
Grafana — платформа для визуализации, анализа и мониторинга данных.
Grafana поддерживает множество источников данных, в том числе Prometheus, Elasticsearch, Loki, PostgreSQL, InfluxDB, OpenSearch и ClickHouse – через плагины.
Основные возможности Grafana
создание интерактивных дашбордов;
визуализация метрик с помощью графиков и таблиц;
выполнение запросов к подключенным источникам данных;
настройка правил алертинга и уведомлений;
использование плагинов для подключения дополнительных источников и расширения возможностей платформы.
В контексте DWH Grafana может использоваться для визуализации:
загрузки серверов и кластеров;
выполнения ETL/ELT-пайплайнов;
производительности хранилища данных;
продолжительности выполнения задач и запросов.
Prometheus + Grafana — одна из наиболее распространенных связок для построения системы мониторинга современной ИТ-инфраструктуры и DWH.
Zabbix
Zabbix — open-source платформа мониторинга, которая широко применяется для централизованного контроля инфраструктуры.
В отличие от связки Prometheus + Grafana, где функции сбора метрик, визуализации и обработки уведомлений распределены между несколькими компонентами, Zabbix предоставляет основные возможности мониторинга в рамках одной платформы.
Zabbix осуществляет:
сбор и хранение метрик;
визуализацию данных;
настройку триггеров для обнаружения проблем;
формирование и отправку уведомлений;
централизованное управление объектами мониторинга.
Преимущества Zabbix
основные функции мониторинга доступны в рамках одной платформы;
поддержка множества способов сбора метрик: Zabbix Agent, SNMP, IPMI, JMX, HTTP-проверки и другие;
использование готовых шаблонов мониторинга;
централизованное управление инфраструктурой;
распределенный мониторинг с помощью Zabbix Proxy.
Ограничения Zabbix
Для DWH часто нужны измерения по DAG, task, dbt-модели, источнику, витрине, окружению и статусу. В Zabbix такие сценарии требуют более тщательной настройки items, discovery rules, templates и triggers.
При большом количестве динамически создаваемых пайплайнов, задач и объектов данных становится сложнее поддерживать шаблоны, правила обнаружения и триггеры.
Не является полноценной платформой для централизованной работы с логами, для больших объемов и сложного поиска обычно используются Loki или OpenSearch.
Менее естественен для Data Observability. Freshness, результаты DQ-проверок, состояние data-продуктов, lineage и зависимости между наборами данных можно интегрировать с Zabbix, но это не его основная модель данных и обычно требует дополнительной логики или внешних инструментов.
Сравнение функциональных возможностей инструментов мониторинга
Возможность | Prometheus | Grafana | Zabbix |
Класс инструмента | Сбор и хранение метрик в виде временных рядов | Слой визуализации и алертинга | Цельная платформа мониторинга |
Сбор метрик | ✔ (pull) | ✖ | ✔ (agent, SNMP, JMX, HTTP) |
Визуализация | базовая | ✔ | ✔ |
Алерты | ✔ (через Alertmanager) | ✔ | ✔ |
Долговременное хранение | через remote_write во внешнее хранилище | зависит от источника | ✔ (в СУБД) |
Kubernetes | ✔ (нативно, service discovery) | ✔ | ✔ (шаблоны с 6.0, нативно с 6.4) |
Порог входа | средний, нужен PromQL | низкий | средний, нужны шаблоны и триггеры |
Кто обычно сопровождает | DevOps, платформенная команда | любая команда | служба эксплуатации |
Системы централизованного логирования
В DWH логи генерируются сразу множеством компонентов: оркестраторами, ETL/ELT-процессами, базами данных, операционными системами, API и другими сервисами. Если каждый компонент хранит их только локально, диагностика инцидентов усложняется.
Для решения этой задачи используется централизованное логирование — сбор логов из разных компонентов платформы в единую систему.
ELK Stack (Elasticsearch + Logstash + Kibana)
ELK Stack — один из наиболее известных стеков для централизованного сбора, хранения, поиска и анализа логов.
Название ELK образовано от трех основных компонентов:
Elasticsearch — распределенная система хранения и поиска. В контуре логирования используется для хранения, индексации и быстрого поиска событий по большим объемам логов.
Logstash — инструмент сбора и обработки данных. Он может получать логи из различных источников, преобразовывать и обогащать их, после чего передавать в Elasticsearch.
Kibana — интерфейс для поиска, анализа и визуализации данных из Elasticsearch. С ее помощью можно исследовать логи, строить дашборды и анализировать события.
На практике между источниками и Elasticsearch также могут использоваться легковесные агенты, например Beats, которые собирают логи на серверах и передают их дальше для обработки и хранения.
Основные возможности ELK Stack
централизованный сбор и хранение логов;
полнотекстовый поиск по событиям;
фильтрация и структурирование логов;
анализ ошибок и последовательности событий;
построение дашбордов и визуализаций;
объединение логов из разных компонентов в едином интерфейсе.
Преимущества ELK Stack
развитые возможности поиска и анализа логов;
гибкая обработка и преобразование событий;
возможность работы с большими объемами данных;
централизованный анализ логов распределенной инфраструктуры;
развитые возможности визуализации через Kibana.
Ограничения ELK Stack
Главная особенность ELK Stack одновременно является и его преимуществом, и потенциальным ограничением: Elasticsearch индексирует данные для обеспечения быстрого и гибкого поиска, что может требовать значительных вычислительных ресурсов и дискового пространства при больших объемах логов.
Поэтому при проектировании ELK для крупного DWH важно заранее определить объем генерируемых логов, сроки их хранения, правила индексации и требования к производительности поиска.
OpenSearch
OpenSearch — open-source платформа для поиска и анализа данных.
Платформа появилась как форк Elasticsearch после изменения лицензионной модели Elasticsearch и позволяет:
централизованно хранить логи;
выполнять полнотекстовый поиск;
фильтровать и агрегировать события;
анализировать ошибки и другие события;
создавать визуализации и дашборды с помощью OpenSearch Dashboards;
настраивать механизмы обнаружения и уведомления о событиях.
В типовой архитектуре агенты или коллекторы собирают логи с компонентов платформы и передают их в OpenSearch, а OpenSearch Dashboards используется для поиска и визуального анализа.
Выбор между ELK Stack и OpenSearch зависит от того, какая из платформ уже есть в компании, чьей экосистемой плагинов вы будете пользоваться, есть ли требования к модели поставки и поддержки.
Grafana Loki
Grafana Loki — система агрегации и хранения логов из экосистемы Grafana Labs.
В отличие от Elasticsearch и OpenSearch, Loki использует другой подход к их индексации.
Elasticsearch-подобные системы создают поисковый индекс по содержимому документов. Loki не индексирует полный текст каждой строки лога. Вместо этого он индексирует набор меток (labels), связанных с потоками логов, а сами данные логов хранятся отдельно в сжатом виде.
Это позволяет уменьшить объем индекса и требования к ресурсам, однако влияет и на характер работы с системой: эффективность поиска во многом зависит от правильно спроектированного набора меток.
Основные особенности Loki
отсутствие полнотекстовой индексации каждого сообщения;
использование labels для организации и поиска потоков логов;
эффективное хранение больших объемов логов;
язык запросов LogQL;
тесная интеграция с Grafana;
возможность масштабирования компонентов системы.
Loki особенно удобен в инфраструктуре, где уже используется Grafana. В таком случае метрики из Prometheus и логи из Loki можно анализировать в одном интерфейсе.
Сравнение функциональных возможностей инструментов логирования
Возможность | ELK Stack | OpenSearch | Loki |
Роль в контуре | хранение и анализ | хранение и анализ | хранение и анализ |
Модель индексации | полнотекстовый индекс | полнотекстовый индекс | индекс только по меткам |
Поиск | по любому полю | по любому полю | по меткам + скан потока |
Требования к диску и CPU | высокие | высокие | низкие |
Обработка и обогащение | ✔ (Logstash) | ✔ | ограниченно, на стороне агента |
Визуализация | Kibana | OpenSearch Dashboards | Grafana |
Лицензия | AGPLv3 / SSPL / ELv2 | Apache 2.0 | AGPLv3 |
Когда выбирать | нужен произвольный поиск по большому объему | то же, но требуется Apache 2.0 | уже есть Grafana, важна стоимость хранения |
Агенты и коллекторы телеметрии
Для сбора, обработки и передачи логов и определенных метрик от источника к целевой системе используются специализированные агенты и коллекторы.
Слой агентов за последние годы сдвинулся в сторону универсальных коллекторов, которые работают со всеми тремя типами телеметрии.
Инструмент | Типы данных | Особенность |
Fluent Bit | логи, метрики | Минимальное потребление ресурсов, стандарт для DaemonSet в Kubernetes |
Fluentd | логи | Более тысячи плагинов и сложная маршрутизация; тяжелее Fluent Bit |
Grafana Alloy | логи, метрики, трассировки | Дистрибутив OpenTelemetry Collector, преемник Promtail и Grafana Agent |
OpenTelemetry Collector | логи, метрики, трассировки | Вендоронезависимый стандарт, максимальная гибкость pipeline |
Как выбрать стек мониторинга для DWH
Выбор стека мониторинга зависит от различных критериев:
Архитектура развертывания
Необходимо учитывать, работают ли сервисы непосредственно на серверах или виртуальных машинах, запускаются в Docker-контейнерах либо управляются Kubernetes. От этого зависят способы обнаружения сервисов, сбора метрик и логов, а также размещения агентов и коллекторов телеметрии.
Масштаб и сложность инфраструктуры
Чем больше сервисов, узлов и процессов, тем выше нагрузка на систему мониторинга. При выборе стека важно учитывать количество источников телеметрии, объем метрик, логов и трассировок, а также требования к их хранению и обработке.
Требования к SLA и SLO
Важно определить, какие показатели доступности и производительности должны контролироваться и какие отклонения считаются инцидентами. Для DWH критичны время выполнения ETL/ELT-процессов, доступность витрин к определенному времени, актуальность данных, производительность запросов и время отклика системы.
Отказоустойчивость
Отказ отдельных компонентов мониторинга не должен приводить к полной потере наблюдаемости, а при критичных требованиях – к потере собираемой телеметрии и невозможности доставки оповещений.
Компетенции команды
Чем больше компонентов входит в observability-стек и чем выше требования к его отказоустойчивости и производительности, тем больше компетенций и ресурсов потребуется для его сопровождения.
Интеграция с существующим ИТ-ландшафтом
Стек мониторинга DWH не обязательно строить с нуля. Если в компании уже используются Zabbix, Prometheus, Grafana, OpenSearch или другие корпоративные инструменты, сначала стоит оценить возможность интеграции мониторинга в существующий контур.
Безопасность и разграничение доступа
Для DWH важно учитывать, кто имеет доступ к метрикам, логам и трассировкам: в телеметрии могут встречаться технические идентификаторы, имена объектов, ошибки запросов и другие данные, чувствительные для эксплуатации и безопасности.
Типовые этапы развития мониторинга DWH
1. Базовый мониторинг DWH
Задача: обеспечить наблюдаемость за инфраструктурой и ключевыми компонентами DWH - серверами, СУБД, оркестратором и другими сервисами платформы.
Стек: Prometheus - для сбора метрик, Grafana- для визуализации, Alertmanager - для обработки и маршрутизации алертов. Метрики инфраструктуры собираются через соответствующие exporters или встроенные интерфейсы мониторинга СУБД. Дополнительно подключаются метрики оркестратора, позволяющие контролировать состояние и выполнение пайплайнов (statsd_exporter). Если в компании уже используется Zabbix, Prometheus или другие инструменты, инфраструктурный уровень целесообразно интегрировать в существующий контур.
Что контролируем: доступность компонентов, CPU, память, диски, сеть, состояние СУБД и кластеров, выполнение пайплайнов, ошибки, retries и длительность загрузок.
Ограничения: успешное выполнение пайплайна еще не означает, что данные поступили полностью, своевременно и соответствуют требованиям качества.
2. Мониторинг данных и качества
Задача: контролировать не только выполнение процессов, но и состояние загружаемых данных Data Quality.
Стек: для проектов с dbt часть проверок можно реализовать через dbt tests и source freshness, при необходимости подключив специализированные инструменты Data Quality.
Что контролируем: freshness, completeness, uniqueness, NULL, нарушения бизнес-правил, аномалии объемов данных и результаты DQ-проверок.
3. Централизованная наблюдаемость распределенной платформы
Задача: при росте количества компонентов нужно унифицировать сбор телеметрии, снижая зависимость приложений от конкретного backend наблюдаемости.
Стек: для унификации сбора телеметрии может использоваться OpenTelemetry Collector. Метрики, логи и трассировки передаются в соответствующие системы хранения и анализа: например, Prometheus/VictoriaMetrics/Mimir для метрик, Loki - для логов и Tempo/Jaeger - для трассировок. Grafana выступает единым интерфейсом визуализации. Grafana Alloy или другие агенты применяются для сбора и доставки телеметрии с узлов и приложений.
Что необходимо учитывать: на этом этапе важно мониторить уже и сам observability-контур: collectors, exporters, очереди, ошибки экспорта и потерю телеметрии.
4. Data Observability и контроль data-продуктов
Задача: важно соблюдать требования со стороны бизнеса, например, витрина должна быть готова к определенному времени, данные должны иметь заданную актуальность и проходить установленные проверки качества.
Стек: технический мониторинг дополняется контролем СУБД и хранилищ, ETL/ELT-процессов, качества данных, lineage и состояния систем-потребителей:
Infrastructure → Database / Storage → ETL / ELT → Data Quality → Data Product / SLO → BI
Что контролируем: время готовности данных, freshness, completeness, успешность загрузок, выполнение DQ-проверок, состояние data-продуктов и влияние инцидентов на зависимые объекты.
Для критичных data-продуктов определяются измеримые SLI/SLO: например, готовность витрины к 08:00 или допустимый интервал актуальности данных. Data Lineage помогает определить, какие downstream-объекты затронет конкретный сбой.
В результате мониторинг развивается от контроля отдельных серверов и процессов до понимания состояния данных и влияния технических проблем на конечных потребителей.
