Перейти к основному содержанию

Введение

Это руководство предназначено для тех, кто хочет построить собственное решение для обсервабилити на базе SQL с использованием ClickHouse, с упором на журналы и трассировки. В нём рассматриваются все аспекты создания такого решения, включая вопросы ингестии, оптимизацию схем под ваши сценарии доступа и извлечение структуры из неструктурированных журналов. Сам по себе ClickHouse не является готовым решением для обсервабилити. Однако его можно использовать как высокоэффективный движок хранения данных обсервабилити, обеспечивающий непревзойдённый уровень сжатия и молниеносный отклик на запросы. Чтобы использовать ClickHouse в составе решения для обсервабилити, необходимы и интерфейс, и система сбора данных. В настоящее время мы рекомендуем использовать Grafana для визуализации сигналов обсервабилити и OpenTelemetry для сбора данных (оба варианта являются официально поддерживаемыми интеграциями).
Не только OpenTelemetryХотя мы рекомендуем использовать проект OpenTelemetry (OTel) для сбора данных, аналогичную архитектуру можно построить и с помощью других фреймворков и инструментов, например Vector и Fluentd (см. пример с Fluent Bit). Есть и альтернативные инструменты визуализации, включая Superset и Metabase.

Зачем использовать ClickHouse?

Самая важная возможность любого централизованного хранилища обсервабилити — быстро агрегировать, анализировать и искать огромные объемы журнальных данных из разных источников. Такая централизация упрощает устранение неполадок и помогает быстрее выявлять первопричины сбоев сервисов. Поскольку пользователи становятся все более чувствительными к цене и считают стоимость таких готовых решений высокой и непредсказуемой относительно их ценности, экономичное и предсказуемое хранение журналов с приемлемой производительностью запросов сегодня важно как никогда. Благодаря высокой производительности и экономической эффективности ClickHouse стал фактическим стандартом среди движков хранения журналов и трассировки в продуктах для обсервабилити. Если точнее, ClickHouse идеально подходит для хранения данных обсервабилити по следующим причинам:
  • Сжатие - Данные обсервабилити обычно содержат поля, значения которых берутся из ограниченного набора, например HTTP-коды или имена сервисов. Колоночно-ориентированное хранилище ClickHouse, в котором значения хранятся в отсортированном виде, обеспечивает очень высокую степень сжатия — особенно в сочетании со специализированными кодеками для данных временных рядов. В отличие от других хранилищ данных, которым обычно требуется столько же места, сколько занимает исходный объем данных, как правило в формате JSON, ClickHouse в среднем сжимает журналы и трассировки до 14 раз. Помимо существенной экономии места для крупных инсталляций обсервабилити, такое сжатие также ускоряет запросы, поскольку с диска нужно считывать меньше данных.
  • Быстрые агрегации - Решения для обсервабилити обычно в значительной степени опираются на визуализацию данных с помощью диаграмм, например линий, показывающих уровень ошибок, или столбчатых диаграмм, показывающих источники трафика. Агрегации, или GROUP BY, лежат в основе таких диаграмм и должны оставаться быстрыми и отзывчивыми при применении фильтров в сценариях диагностики проблем. Колоночно-ориентированный формат ClickHouse в сочетании с векторизованным движком выполнения запросов идеально подходит для быстрых агрегаций, а разреженное индексирование позволяет быстро фильтровать данные в ответ на действия пользователя.
  • Быстрые линейные сканирования - Хотя альтернативные технологии опираются на инвертированные индексы для быстрого выполнения запросов к журналам, это неизменно приводит к высокому потреблению дисковых и других ресурсов. Хотя ClickHouse поддерживает инвертированные индексы как дополнительный необязательный тип индекса, линейные сканирования в нем хорошо распараллеливаются и используют все доступные ядра машины (если не настроено иначе). Это потенциально позволяет сканировать десятки ГБ/с (в сжатом виде) для поиска совпадений с помощью высокооптимизированных операторов сопоставления текста.
  • Знакомый SQL - SQL — повсеместно распространенный язык, знакомый всем инженерам. За более чем 50 лет развития он зарекомендовал себя как фактический стандарт для аналитики данных и по-прежнему остается третьим по популярности языком программирования. Обсервабилити — это еще одна задача работы с данными, для которой SQL подходит идеально.
  • Аналитические функции - ClickHouse расширяет ANSI SQL аналитическими функциями, которые делают SQL-запросы проще и удобнее в написании. Они особенно важны при анализе первопричин, когда данные нужно детально разбирать в разных разрезах.
  • Вторичные индексы - ClickHouse поддерживает вторичные индексы, такие как bloom-фильтры, чтобы ускорять определенные профили запросов. Их можно при необходимости включать на уровне столбца, что дает пользователю детальный контроль и позволяет оценить выигрыш в производительности относительно затрат.
  • Открытый исходный код и открытые стандарты - Как база данных с открытым исходным кодом, ClickHouse поддерживает открытые стандарты, такие как OpenTelemetry. Возможность вносить вклад и активно участвовать в проектах привлекательна сама по себе и при этом помогает избежать проблем, связанных с привязкой к поставщику.

Когда стоит использовать ClickHouse для обсервабилити

Использование ClickHouse для данных обсервабилити требует готовности работать с обсервабилити на основе SQL. Об истории обсервабилити на основе SQL мы рекомендуем прочитать в этой статье блога, но если кратко: Обсервабилити на основе SQL подходит вам, если:
  • Вы или участники вашей команды знакомы с SQL (или хотите его изучить)
  • Вы предпочитаете придерживаться открытых стандартов, таких как OpenTelemetry, чтобы избежать привязки к поставщику и обеспечить расширяемость.
  • Вы готовы использовать экосистему, основанную на инновациях open-source, от сбора до хранения и визуализации.
  • Вы ожидаете роста до средних или больших объёмов данных обсервабилити в управлении (или даже очень больших объёмов)
  • Вы хотите контролировать TCO (совокупную стоимость владения) и избежать стремительного роста затрат на обсервабилити.
  • Вы не можете или не хотите мириться с короткими сроками хранения данных обсервабилити только ради снижения затрат.
Обсервабилити на основе SQL может вам не подойти, если:
  • Изучение SQL (или даже его генерация!) не привлекает вас или участников вашей команды.
  • Вам нужно готовое комплексное решение для обсервабилити.
  • Объёмы ваших данных обсервабилити слишком малы, чтобы это дало заметный эффект (например, <150 GiB), и их рост не ожидается.
  • В вашем сценарии использования основной акцент сделан на метрики и требуется PromQL. В таком случае вы всё равно можете использовать ClickHouse для журналов и трассировки вместе с Prometheus для метрик, объединив всё это на уровне представления с помощью Grafana.
  • Вы предпочитаете подождать, пока экосистема станет более зрелой, а обсервабилити на основе SQL — более готовой к использованию из коробки.

Журналы и трассировки

В обсервабилити есть три основных компонента: Logging, Tracing и Metrics. Для каждого характерны свои типы данных и способы доступа к ним. В настоящее время мы рекомендуем ClickHouse для хранения двух типов данных обсервабилити:
  • Журналы - Журналы — это записи событий, происходящих в системе, с отметками времени, которые содержат подробную информацию о различных аспектах работы программного обеспечения. Данные в журналах обычно бывают неструктурированными или полуструктурированными и могут включать сообщения об ошибках, журналы пользовательской активности, изменения в системе и другие события. Журналы крайне важны для устранения неполадок, выявления аномалий и понимания того, какие именно события привели к проблемам в системе.
  • Трассировки — Трассировки фиксируют путь запросов при их прохождении через различные сервисы в распределенной системе, показывая маршрут этих запросов и их производительность. Данные в трассировках имеют четкую структуру и состоят из спанов и трассировок, которые описывают каждый шаг запроса, включая временные характеристики. Трассировки дают ценную информацию о производительности системы, помогая выявлять узкие места, проблемы с задержками и оптимизировать работу микросервисов.
МетрикиХотя ClickHouse можно использовать для хранения данных метрик, в ClickHouse это направление пока развито слабее: например, еще не поддерживаются такие возможности, как формат данных Prometheus и PromQL.

Распределённая трассировка

Распределённая трассировка — критически важная возможность обсервабилити. Распределённая трассировка, обычно называемая просто трассировкой, показывает путь запроса через систему. Запрос исходит от конечного пользователя или приложения и распространяется по системе, обычно вызывая цепочку действий между микросервисами. Запись этой последовательности и возможность коррелировать последующие события позволяют пользователю средств обсервабилити или SRE диагностировать проблемы в работе приложения независимо от сложности архитектуры и использования бессерверных компонентов. Каждая трассировка состоит из нескольких спанов, при этом начальный спан, связанный с запросом, называется корневым спаном. Этот корневой спан охватывает весь запрос от начала до конца. Последующие спаны под корневым дают детальное представление о различных шагах или операциях, происходящих во время выполнения запроса. Без трассировки диагностика проблем с производительностью в распределённой системе может быть крайне затруднена. Трассировка упрощает отладку и понимание распределённых систем, подробно показывая последовательность событий внутри запроса по мере его прохождения через систему. Большинство поставщиков решений для обсервабилити визуализируют эту информацию в виде водопада, где относительное время показано горизонтальными полосами пропорциональной длины. Например, в Grafana: Пользователям, которым нужно глубже разобраться в концепциях журналов и трассировок, мы настоятельно рекомендуем документацию OpenTelemetry.
Последнее изменение 12 июня 2026 г.