Использование ClickHouse для обеспечения наблюдаемости
Введение
Это руководство предназначено для пользователей, которые хотят построить собственное решение для наблюдаемости на основе SQL с использованием ClickHouse, с упором на логи и трейсы. Оно охватывает все аспекты построения такого решения, включая вопросы, связанные с ингестией, оптимизацией схем под ваши паттерны доступа и извлечением структуры из неструктурированных логов.
Один лишь ClickHouse не является готовым решением «из коробки» для наблюдаемости. Однако его можно использовать как высокоэффективный движок хранения данных наблюдаемости, обеспечивающий непревзойдённые показатели сжатия и исключительно быстрое время ответа на запросы. Для использования ClickHouse в составе решения для наблюдаемости необходимы как пользовательский интерфейс, так и фреймворк для сбора данных. В настоящее время мы рекомендуем использовать Grafana для визуализации сигналов наблюдаемости и OpenTelemetry для сбора данных (обе интеграции официально поддерживаются).
Хотя мы и рекомендуем использовать проект OpenTelemetry (OTel) для сбора данных, аналогичные архитектуры могут быть реализованы с использованием других фреймворков и инструментов, например Vector и Fluentd (см. пример с Fluent Bit). Существуют и альтернативные инструменты визуализации, включая Superset и Metabase.
Почему стоит использовать ClickHouse?
Наиболее важная характеристика любого централизованного хранилища Observability — его способность быстро агрегировать, анализировать и выполнять поиск по огромным объёмам логов из разнообразных источников. Такая централизация упрощает устранение неполадок и позволяет быстрее находить корневые причины сбоев сервисов.
По мере того как пользователи становятся всё более чувствительными к цене и считают стоимость готовых решений высокой и непредсказуемой по сравнению с их ценностью, особенно возрастает роль экономичного и предсказуемого хранилища логов с приемлемой производительностью запросов.
Благодаря своей высокой производительности и экономичности ClickHouse стал де-факто стандартом для движков хранения логов и трейсов в продуктах для Observability.
Конкретнее, следующие особенности делают ClickHouse идеальным решением для хранения данных Observability:
- Сжатие — Данные Observability обычно содержат поля, значения которых берутся из ограниченного набора, например HTTP-коды или имена сервисов. Колонко-ориентированное хранение ClickHouse, в котором значения хранятся отсортированными, обеспечивает отличное сжатие таких данных — особенно в сочетании с набором специализированных кодеков для временных рядов. В отличие от других хранилищ данных, которым требуется объём на диске, сопоставимый с исходным размером данных, обычно в формате JSON, ClickHouse в среднем сжимает логи и трейсы до 14 раз. Помимо значительной экономии дискового пространства для крупных инсталляций Observability, это сжатие ускоряет выполнение запросов, поскольку с диска нужно читать меньше данных.
- Быстрые агрегации — Решения Observability, как правило, активно используют визуализацию данных в виде графиков, например линий с показателями ошибок или столбчатых диаграмм с источниками трафика. Агрегации (операции GROUP BY) лежат в основе таких графиков и также должны выполняться быстро и оставаться отзывчивыми при применении фильтров в рабочих процессах диагностики инцидентов. Колонко-ориентированный формат ClickHouse в сочетании с векторизованным движком выполнения запросов идеально подходит для быстрых агрегаций, а разрежённая индексация обеспечивает быстрое фильтрование данных в ответ на действия пользователя.
- Быстрые линейные сканирования — В то время как альтернативные технологии полагаются на инвертированные индексы для быстрого поиска по логам, это неизбежно приводит к высокому расходу дискового пространства и ресурсов. Хотя ClickHouse предоставляет инвертированные индексы как дополнительный тип индекса, линейные сканирования в нём сильно распараллелены и используют все доступные ядра машины (если не сконфигурировано иначе). Это потенциально позволяет сканировать десятки ГБ/с (в сжатом виде) в поиске совпадений с использованием высокопроизводительных операторов поиска по тексту.
- Привычность SQL — SQL — повсеместный язык, с которым знакомы все инженеры. За более чем 50 лет развития он зарекомендовал себя как де-факто язык для аналитики данных и остаётся 3‑м по популярности языком программирования. Observability — это просто ещё одна задача работы с данными, для которой SQL идеально подходит.
- Аналитические функции — ClickHouse расширяет ANSI SQL аналитическими функциями, призванными упростить написание SQL-запросов. Они критически важны для пользователей, выполняющих поиск корневых причин, когда данные нужно гибко «нарезать» и анализировать под разными углами.
- Вторичные индексы — ClickHouse поддерживает вторичные индексы, такие как bloom-фильтры, для ускорения определённых профилей запросов. Их можно опционально включать на уровне отдельных колонок, что даёт пользователю тонкий контроль и позволяет оценивать баланс между стоимостью и производительностью.
- Open-source и открытые стандарты — Как база данных с открытым исходным кодом, ClickHouse поддерживает открытые стандарты, такие как OpenTelemetry. Возможность вносить вклад и активно участвовать в развитии проектов привлекательна, при этом удаётся избежать проблем, связанных с привязкой к конкретному вендору.
Когда стоит использовать ClickHouse для наблюдаемости
Использование ClickHouse для данных наблюдаемости предполагает переход к наблюдаемости на основе SQL. Рекомендуем эту статью в блоге для ознакомления с историей наблюдаемости на основе SQL, но, если коротко:
Обзервабилити на основе SQL подходит вам, если:
- Вы или ваша команда хорошо знакомы с SQL (или хотите его выучить).
- Вы предпочитаете придерживаться открытых стандартов, таких как OpenTelemetry, чтобы избежать привязки к поставщику и обеспечить расширяемость.
- Вы готовы использовать экосистему, развиваемую open-source‑инновациями на всех этапах — от сбора до хранения и визуализации.
- Вы ожидаете рост до средних или больших объемов данных наблюдаемости под управлением (или даже очень больших объемов).
- Вы хотите контролировать TCO (совокупную стоимость владения) и избежать неконтролируемого роста расходов на наблюдаемость.
- Вы не можете или не хотите мириться с короткими периодами хранения данных наблюдаемости только ради сокращения затрат.
Наблюдаемость на основе SQL может быть не для вас, если:
- Изучение (или генерация!) SQL не привлекает вас или вашу команду.
- Вы ищете готовое, сквозное решение для наблюдаемости.
- Объемы ваших данных наблюдаемости слишком малы, чтобы дать существенный эффект (например, <150 ГиБ), и не ожидается, что они будут расти.
- Ваш сценарий сильно ориентирован на метрики и требует PromQL. В этом случае вы все равно можете использовать ClickHouse для логов и трейсов вместе с Prometheus для метрик, объединив их на уровне представления с помощью Grafana.
- Вы предпочитаете подождать, пока экосистема станет более зрелой, а наблюдаемость на основе SQL — более «под ключ».
Логи и трейсы
У сценария наблюдаемости (Observability) есть три основных составляющих: логирование (Logging), трассировка (Tracing) и метрики (Metrics). У каждой из них свои типы данных и характерные способы доступа.
В настоящее время мы рекомендуем использовать ClickHouse для хранения двух типов данных наблюдаемости:
- Логи — логи представляют собой записи событий в системе с временными метками, фиксирующие детальную информацию о различных аспектах работы программного обеспечения. Данные в логах, как правило, неструктурированы или полуструктурированы и могут включать сообщения об ошибках, записи пользовательской активности, системные изменения и другие события. Логи критически важны для устранения неполадок, обнаружения аномалий и понимания конкретных событий, которые привели к проблемам в системе.
- Traces - Трейсы фиксируют путь запросов при их прохождении через различные сервисы в распределённой системе, подробно описывая маршрут и производительность этих запросов. Данные в трейcах строго структурированы и состоят из спанов и трейсов, которые отображают каждый шаг, который проходит запрос, включая временные характеристики. Трейсы дают ценные сведения о производительности системы, помогая выявлять узкие места, проблемы с задержками и оптимизировать эффективность микросервисов.
Хотя ClickHouse может использоваться для хранения данных метрик, это направление в ClickHouse развито менее полно; ожидается поддержка таких возможностей, как формат данных Prometheus и язык запросов PromQL.
Распределённая трассировка
Распределённая трассировка — критически важная составляющая наблюдаемости. Распределённая трассировка, или просто трейс, отображает путь запроса через систему. Запрос может исходить от конечного пользователя или приложения и распространяться по системе, как правило приводя к последовательности действий между микросервисами. Записывая эту последовательность и позволяя коррелировать последующие события, трассировка даёт пользователю системы наблюдаемости или SRE возможность диагностировать проблемы в потоке обработки приложения независимо от того, насколько сложна архитектура или насколько активно используются serverless-компоненты.
Каждый трейс состоит из нескольких спанов, при этом начальный спан, связанный с запросом, называется корневым спаном. Этот корневой спан охватывает весь запрос от начала до конца. Последующие спаны под корневым спаном предоставляют детализированное представление различных шагов или операций, происходящих в ходе обработки запроса. Без трассировки диагностика проблем с производительностью в распределённой системе может быть чрезвычайно сложной. Трассировка упрощает отладку и понимание распределённых систем, детализируя последовательность событий в рамках запроса по мере его прохождения через систему.
Большинство поставщиков решений для наблюдаемости визуализируют эту информацию в виде «водопада», где относительное время отображается горизонтальными полосами пропорционального размера. Например, в Grafana:
Пользователям, которым необходимо глубже разобраться с концепциями логов и трассировок, мы настоятельно рекомендуем документацию OpenTelemetry.
