Создание единой системы аналитики Log/Trace/Metrics на Apache Doris

Наблюдаемость — это возможность определять внутреннее состояние системы по её выходным данным. Платформа наблюдаемости собирает, хранит и визуализирует три ключевых типа данных: Logging, Tracing и Metrics. Она помогает командам получить полное представление о работе распределённых систем, оптимизировать ресурсы, получать оповещения о сбоях и анализировать их первопричины, что в конечном счёте повышает надёжность системы и улучшает пользовательский опыт.

Почему наблюдаемость становится всё важнее

Основные сценарии применения

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

Сценарий	Польза	Типичные примеры использования
Поиск неисправностей и анализ первопричин	Сокращение времени восстановления после сбоя и обеспечение непрерывности бизнеса	Мониторинг в реальном времени, обнаружение аномалий, распределённая трассировка, хаос-инжиниринг
Оптимизация производительности и планирование ресурсов	Выявление узких мест производительности и снижение затрат на облачные ресурсы	Анализ использования ресурсов, балансировка нагрузки, автоматическое масштабирование, прогнозирование потребности в ресурсах
Поддержка принятия бизнес-решений	Связь показателей работы ИТ-систем с результатами бизнеса	Анализ метрик пользовательского опыта, оптимизация функций продукта
Мониторинг безопасности и соблюдения нормативных требований	Обнаружение аномального поведения и автоматическое реагирование	Обнаружение атак с использованием уязвимостей нулевого дня, аудит журналов, хранение данных в соответствии с нормативными требованиями
Взаимодействие команд разработки и эксплуатации	Поддержка канареечного развёртывания и оптимизации кода	Маркировка трафика, анализ цепочек вызовов, оценка хода развёртывания

Две основные тенденции, определяющие развитие наблюдаемости

1. Бизнес-системы и ИТ-системы становятся сложнее: с развитием облачных вычислений и микросервисов запрос из приложения GenAI может задействовать десятки сервисов, включая App, сервисный шлюз, сервис аутентификации, сервис биллинга, движок RAG, движок Agent, векторную базу данных, базу данных бизнес-приложения, распределённый кеш, очередь сообщений и API больших моделей. В таких сложных системах подключение к серверам для проверки текущего состояния и анализа сбоев уже неэффективно. Платформа наблюдаемости объединяет сбор и хранение данных Log, Trace и Metrics и предоставляет единые средства визуального анализа, позволяя быстро и эффективно выявлять проблемы.
2. Требования к надёжности бизнеса растут: системные сбои всё сильнее влияют на пользовательский опыт и обходятся всё дороже, поэтому повышаются и требования к скорости локализации неисправностей и восстановления. Благодаря интеграции данных из разных областей и наглядному представлению всей системы наблюдаемость помогает командам быстро находить первопричины проблем и сокращать время простоя бизнеса. Анализ всех данных и прогнозирование позволяют заранее выявлять узкие места в ресурсах, своевременно устранять их и предотвращать сбои.

Как выбрать решение для наблюдаемости

Ключевые особенности данных наблюдаемости

Центральная задача любого решения для наблюдаемости — обеспечить хранение и анализ огромных объёмов данных. Данные наблюдаемости обладают следующими пятью особенностями:

1. Большой объём хранения и чувствительность к затратам: данные Log и Trace обычно имеют очень большой объём и поступают непрерывно, круглосуточно. Средние и крупные предприятия ежедневно генерируют данные наблюдаемости в объёмах порядка TB и даже PB. Для выполнения бизнес-требований или нормативных требований эти данные часто необходимо хранить полгода и дольше. Общий объём хранения нередко достигает PB, что приводит к высоким затратам. Со временем ценность этих данных постепенно снижается, поэтому платформы наблюдаемости особенно чувствительны к стоимости хранения.
2. Высокая пропускная способность записи и требования реального времени: при ежедневном поступлении новых данных в объёмах порядка TB и даже PB платформа должна поддерживать скорость записи 1-10 GB/s и обработку от миллионов до десятков миллионов записей в секунду. При этом для таких сценариев, как поиск неисправностей и расследование инцидентов безопасности, где важна оперативность, задержка записи должна оставаться на уровне секунд, чтобы обеспечивать актуальность и доступность данных.
3. Анализ в реальном времени с полнотекстовым поиском: данные Log и Trace содержат много текста, поэтому быстрый поиск ключевых слов и фраз является одним из основных требований. Из-за огромного объёма данных традиционные подходы с полным сканированием и сопоставлением строк не позволяют получать ответы в реальном времени. Создание инвертированных индексов для текста становится ключевым условием выполнения запросов за секунды.
4. Динамические схемы, требующие частого расширения: данные журналов эволюционировали от неструктурированных исходных журналов в виде произвольного текста до полуструктурированных Logs и Traces, преимущественно в формате JSON. Источники данных динамически изменяют внутренние поля JSON, поэтому схема отличается высокой гибкостью. Традиционным базам данных и хранилищам данных сложно эффективно обрабатывать данные с такими гибкими схемами. Озёра данных обеспечивают гибкость хранения, но не удовлетворяют требованиям к производительности обработки и работе в реальном времени.
5. Необходимость интеграции с разнообразными источниками данных и инструментами анализа: экосистема наблюдаемости включает множество инструментов сбора данных и визуального анализа. Движок хранения и анализа должен интегрироваться с различными инструментами экосистемы, чтобы удовлетворять разнообразные требования к интеграции данных и инструментов.

Четыре ключевых критерия оценки при выборе

Такие решения, как Elasticsearch, ClickHouse, Doris и сервисы журналирования облачных провайдеров, можно оценивать по четырём критериям: производительность, стоимость, открытость и удобство использования.

1. Производительность: запись и выполнение запросов

Наблюдаемость часто применяется в ситуациях, требующих срочного реагирования, например при поиске неисправностей, поэтому высокие требования предъявляются как к скорости ответа на запросы, так и к актуальности данных. С одной стороны, запросы должны выполняться быстро. Особенно это касается текста в данных Log/Trace, для которого необходим полнотекстовый поиск в реальном времени, позволяющий последовательно исследовать данные. С другой стороны, самые свежие данные должны быть доступны для запросов с задержкой на уровне секунд.

Решение	Производительность записи	Полнотекстовый поиск	Анализ с агрегацией
Elasticsearch	При высокой пропускной способности производительность записи относительно низкая; в пиковые периоды часто возникают отказы в записи и большие задержки	Известен сочетанием инвертированного индекса и полнотекстового поиска; обеспечивает поиск в реальном времени с задержкой на уровне секунд	Относительно низкая производительность анализа с агрегацией
Сервис журналирования облачного провайдера	Обеспечивает требуемую производительность за счёт наращивания ресурсов	Соответствует требованиям к производительности	Соответствует требованиям к производительности
ClickHouse	Колоночное хранение + векторизованный движок обеспечивают высокую производительность записи	В несколько или десятки раз медленнее Elasticsearch и Doris; пока находится в экспериментальном статусе	Высокая производительность запросов с агрегацией
Doris	Колоночное хранение + векторизованный движок с инвертированными индексами, оптимизированными для наблюдаемости; примерно в 5 раз быстрее Elasticsearch	Примерно в 2 раза быстрее Elasticsearch	В 6-21 раз быстрее Elasticsearch

2. Стоимость: затраты на хранение и вычисления

Средние и крупные предприятия ежедневно генерируют данные наблюдаемости в объёмах порядка TB и даже PB, а общий объём хранения часто достигает PB и даже EB. По сравнению с бизнес-данными данные наблюдаемости имеют больший объём и меньшую ценность на единицу объёма, которая постепенно снижается со временем. Поэтому они особенно чувствительны к затратам как на хранение, так и на вычисления.

Решение	Коэффициент сжатия	Затраты на хранение / вычисления
Elasticsearch	Около 1.5:1 (строчное хранение + инвертированный индекс + колоночное хранение docvalue)	Высокая стоимость хранения; накладные расходы JVM и построение инвертированных индексов приводят к высокому потреблению CPU
Doris	5:1 ~ 10:1; разделение горячих и холодных данных по уровням хранения дополнительно снижает затраты	Экономия 50%-80% по сравнению с Elasticsearch; запись с одной репликой, компактизация временных рядов и векторизованное построение индексов снижают стоимость записи
ClickHouse	Колоночное хранение с хорошим сжатием	Низкие затраты на хранение и запись
Сервис журналирования облачного провайдера	-	Столь же высокие, как у Elasticsearch

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

При построении платформы наблюдаемости важно избегать привязки к поставщику. Обращайте внимание на то, открыт ли исходный код решения, доступно ли оно в разных облаках и поддерживает ли открытую экосистему.

Решение	Организация, развивающая проект	Поддержка нескольких облаков	Открытость экосистемы
Elasticsearch	Elastic	Доступен в нескольких облаках	Экосистема ELK относительно изолирована, а Kibana поддерживает только Elasticsearch
Doris	Apache Software Foundation	Ведущие облачные провайдеры предлагают SaaS	Поддерживает OpenTelemetry, Grafana, ELK и другие экосистемы с открытым исходным кодом; сохраняет нейтральность
ClickHouse	ClickHouse Inc.	Доступен в нескольких облаках	Поддерживает OpenTelemetry и Grafana; на нейтральность повлияло приобретение коммерческой компании в сфере наблюдаемости
Сервис журналирования облачного провайдера	Соответствующий облачный провайдер	Привязан к собственному облаку	Закрытый исходный код; миграция между облаками затруднена

4. Удобство использования: сопровождение и повседневная работа

Из-за большого объёма данных платформы наблюдаемости обычно используют распределённую архитектуру. Важными критериями становятся удобство развёртывания, масштабирования и обновления, а также понятность интерфейса запросов для разработчиков.

Решение	Интерфейс и эксплуатация
Elasticsearch	Kibana предоставляет удобный интерфейс и хорошие возможности сопровождения; язык запросов DSL сложен и имеет высокий порог освоения
Doris	Предоставляет интерактивный интерфейс поиска и анализа, похожий на Kibana, и интегрируется со штатными интерфейсами Kibana / Grafana; стандартный SQL, совместимый с MySQL; простая архитектура, обновление и масштабирование без остановки, автоматическая балансировка нагрузки и визуальный Cluster Manager
ClickHouse	Собственный диалект SQL; пользователю необходимо учитывать внутреннее разделение на локальные таблицы + распределённые таблицы; автоматическая балансировка при масштабировании отсутствует, и обычно требуется собственная система эксплуатации
Сервис журналирования облачного провайдера	Сервис SaaS не требует самостоятельного сопровождения и удобен в использовании

Итог выбора

Приведённое сравнение показывает, что Doris имеет явные преимущества по всем четырём критериям: производительности, стоимости, открытости и удобству использования. Решение обеспечивает высокую производительность записи и запросов при низких затратах, предоставляет простой и удобный интерфейс SQL, а его простую архитектуру легко сопровождать и расширять. При этом работа с Doris остаётся одинаковой в разных облаках. Это идеальный выбор для построения платформы наблюдаемости.

Решение для наблюдаемости на базе Doris

Архитектура системы

Doris — современное хранилище данных с распределённой архитектурой MPP. Оно сочетает такие передовые технологии, как векторизованный движок выполнения, оптимизатор CBO, широкий набор индексов и материализованные представления, обеспечивая чрезвычайно быстрый аналитический доступ к большим объёмам данных в реальном времени. Doris демонстрирует одни из лучших в мире результатов, включая первые места, в ряде авторитетных тестов производительности аналитических баз данных: ClickBench для одной таблицы, TPC-H для нескольких таблиц и TPC-DS.

С учётом особенностей задач наблюдаемости Doris дополняет эти возможности инвертированными индексами и чрезвычайно быстрым полнотекстовым поиском, максимально оптимизирует производительность записи и использование пространства хранения. Это позволяет строить на Doris высокопроизводительные, экономичные и открытые платформы наблюдаемости.

Платформа наблюдаемости на базе Doris состоит из трёх основных компонентов:

1. Сбор и предварительная обработка данных: поддерживаются различные инструменты сбора данных наблюдаемости, включая открытую экосистему OpenTelemetry, а также Logstash и Filebeat из экосистемы ELK. Они записывают данные Log, Trace и Metrics в Doris через HTTP API.
2. Движок хранения и анализа данных: Doris обеспечивает высокопроизводительное и экономичное единое хранилище данных наблюдаемости и предоставляет широкие возможности поиска и анализа через интерфейс SQL.
3. Выполнение аналитических запросов и визуализация: интеграция с наиболее распространёнными инструментами визуального анализа, включая широко используемую Grafana и Kibana из экосистемы ELK, предоставляет пользователям простые и удобные интерфейсы поиска, анализа и оповещения для мониторинга в реальном времени и быстрого реагирования.

Основные преимущества решения

Высокая производительность

• Высокая пропускная способность записи при низкой задержке: поддерживается непрерывная и стабильная запись данных Log, Trace и Metrics в ежедневных объёмах порядка PB (10 GB/s) с задержкой на уровне секунд или даже в пределах 1s.
• Высокопроизводительные инвертированные индексы и полнотекстовый поиск: типичные запросы, например поиск ключевых слов в журналах, выполняются за секунды, в 3-10 раз быстрее ClickHouse.
• Высокопроизводительный анализ с агрегацией: распределённая архитектура MPP + векторизованный движок выполнения Pipeline позволяют в полной мере использовать распределённые ресурсы кластера и многопоточность CPU. Производительность в тесте ClickBench находится среди лучших в мире и подходит для таких типичных запросов, как анализ тенденций и формирование оповещений мониторинга.

Низкая стоимость

• Высокий коэффициент сжатия и недорогое хранение: поддерживается хранение огромных объёмов данных порядка PB с коэффициентом сжатия 5:1 ~ 10:1 (включая индексы), что снижает затраты на хранение на 50%-80% по сравнению с Elasticsearch. Холодные данные можно хранить в S3/HDFS, дополнительно снижая стоимость хранения на 50%.
• Недорогая запись: при одинаковом объёме записываемых данных потребление ресурсов CPU более чем на 70% ниже по сравнению с Elasticsearch.

Гибкая схема

• Изменение полей верхнего уровня: операции ADD/DROP COLUMN/INDEX через Light Schema Change позволяют изменять схему за секунды. На этапе планирования достаточно определить, для каких полей сейчас нужны индексы.
• Изменение внутренних полей: VARIANT — полуструктурированный тип данных, разработанный для расширяемых данных JSON. Он может автоматически распознавать имена и типы полей JSON и выделять часто встречающиеся поля в колоночное хранение, повышая коэффициент сжатия и производительность анализа. В отличие от Dynamic Mapping в Elasticsearch, VARIANT допускает изменение типов полей.

Удобство использования

• Стандартный интерфейс SQL: совместимость с протоколом и синтаксисом MySQL позволяет инженерам и аналитикам данных напрямую использовать запросы SQL.
• Поддержка экосистемы наблюдаемости: охватывает экосистемы OpenTelemetry и ELK и интегрируется с инструментами визуализации, такими как Grafana и Kibana, упрощая сбор данных и визуальный анализ.
• Удобная эксплуатация: поддерживаются масштабирование без прерывания обслуживания и автоматическая балансировка. Для локального развёртывания предоставляются визуальный Cluster Manager и инструмент K8s Operator, а в облаке доступен полностью управляемый сервис, готовый к использованию.

Открытость

• Открытый исходный код: Doris — проект верхнего уровня Apache Software Foundation с открытым исходным кодом, который используют более 5,000 предприятий по всему миру. Он поддерживает такие экосистемы наблюдаемости, как OpenTelemetry и Grafana.
• Независимость от облачных провайдеров: ведущие облачные провайдеры предлагают Doris SaaS, обеспечивая одинаковый опыт работы в разных облаках.

Демонстрация и снимки экрана

Ниже платформа наблюдаемости на базе Doris показана на примере комплексного демонстрационного проекта сообщества OpenTelemetry.

Наблюдаемая система

Наблюдаемая бизнес-система — это демонстрационный сайт электронной торговли. Он состоит более чем из десяти модулей, включая пользовательские интерфейсы, аутентификацию, корзину, транзакции, логистику, рекламу, рекомендации и контроль рисков. Система в целом отличается высокой сложностью, что создаёт существенные трудности при сборе, хранении и анализе данных наблюдаемости.

Поток данных

Программа имитации нагрузки Load Generator непрерывно отправляет запросы во входной сервис, создавая большой объём данных наблюдаемости (Log, Trace, Metrics) во всей системе электронной торговли. Данные проходят следующие этапы:

1. Собираются с помощью SDK OpenTelemetry для разных языков
2. Отправляются в OpenTelemetry Collector
3. Проходят предварительную обработку в компонентах Processors внутри Collector
4. Записываются в Doris через OpenTelemetry Doris Exporter
5. Doris подключается к инструментам анализа верхнего уровня, таким как Grafana, через интерфейс MySQL и предоставляет возможности визуального выполнения запросов и анализа

Нажмите, чтобы посмотреть

Визуализация

Grafana подключается к Doris через MySQL Datasource и предоставляет единую среду визуального анализа Log, Trace и Metrics с возможностью перехода между связанными данными Log и Trace.

• Log

  

• Trace

  

• Metrics

  

Возможности визуализации и анализа Log в Grafana относительно просты по сравнению с Kibana. Поэтому сторонние поставщики реализовали возможности поиска и анализа, аналогичные Kibana Discover. В будущем они также будут интегрированы в Grafana Doris Datasource, чтобы улучшить единую среду визуального анализа Log/Trace/Metrics. Кроме того, благодаря совместимости с протоколом запросов Elasticsearch штатная Kibana в будущем сможет подключаться непосредственно к Doris. Пользователи ELK смогут заменить Elasticsearch на Doris, снизить затраты и повысить эффективность, сохранив привычные способы сбора журналов и визуального анализа.