Использование ClickHouse для Наблюдаемости

Введение

Этот гайд предназначен для пользователей, стремящихся создать собственное решение для наблюдаемости на основе 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-летней историей разработки он зарекомендовал себя как де-факто язык для аналитики данных и остается 3-м по популярности языком программирования. Наблюдаемость - это просто еще одна проблема с данными, для которой SQL идеально подходит.
• Аналитические функции - ClickHouse расширяет ANSI SQL аналитическими функциями, предназначенными для упрощения написания SQL-запросов. Они необходимы для пользователей, выполняющих анализ коренных причин, когда данные необходимо сегментировать и обрабатывать.
• Вторичные индексы - ClickHouse поддерживает вторичные индексы, такие как фильтры Блума, для ускорения выполнения конкретных профилей запросов. Их можно настраивать на уровне столбцов, предоставляя пользователю детальный контроль и позволяя оценить соотношение стоимости и производительности.
• С открытым исходным кодом и открытые стандарты - Как база данных с открытым исходным кодом, ClickHouse поддерживает открытые стандарты, такие как Open Telemetry. Возможность вносить вклад и активно участвовать в проектах привлекает внимание, избегая проблем с привязкой к поставщику.

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

Использование ClickHouse для данных наблюдаемости требует от пользователей принятия SQL-основы наблюдаемости. Мы рекомендуем этот блог-пост для ознакомления с историей SQL-основы наблюдаемости, но в кратце:

SQL-основная наблюдаемость подходит для вас, если:

• Вы или ваши команды знакомы с SQL (или хотите его изучить)
• Вы предпочитаете придерживаться открытых стандартов, таких как OpenTelemetry, чтобы избежать привязки к платформе и достичь расширяемости.
• Вы готовы работать в экосистеме, основанной на открытых инновациях, от сбора до хранения и визуализации.
• Вы предполагаете некоторый рост до средних или больших объемов данных наблюдаемости (или даже очень больших объемов)
• Вы хотите контролировать TCO (общую стоимость владения) и избежать роста затрат на наблюдаемость.
• Вы не можете или не хотите застревать с короткими сроками хранения данных наблюдаемости просто для управления расходами.

SQL-основная наблюдаемость может вам не подойти, если:

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

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

Случай использования Наблюдаемости имеет три различных столпа: Журналирование, Трассировка и Метрики. Каждый из них имеет свои типы данных и шаблоны доступа.

В настоящее время мы рекомендуем ClickHouse для хранения двух типов данных наблюдаемости:

• Журналы - Журналы представляют собой временные записи событий, происходящих в системе, фиксируя подробную информацию о различных аспектах операций программного обеспечения. Данные в журналах обычно неструктурированы или полуструктурированы и могут включать сообщения об ошибках, журналы активности пользователей, изменения в системе и другие события. Журналы имеют решающее значение для устранения неполадок, обнаружения аномалий и понимания конкретных событий, предшествующих проблемам в системе.

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

Метрики

Хотя ClickHouse может использоваться для хранения данных метрик, этот аспект менее развит в ClickHouse с ожидаемой поддержкой таких функций, как поддержка формата данных Prometheus и PromQL.

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

Распределенная трассировка является критически важной функцией наблюдаемости. Распределенная трассировка, просто называемая трассировкой, отображает путь запроса через систему. Запрос будет исходить от конечного пользователя или приложения и распространяться через систему, обычно приводя к последовательности действий между микросервисами. Записывая эту последовательность и позволяя коррелировать последующие события, это позволяет пользователю наблюдаемости или SRE диагностировать проблемы в потоке приложений, независимо от того, насколько сложна или безсерверная архитектура.

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

Большинство поставщиков наблюдаемости визуализируют эту информацию в виде водопада, с относительным временем, показанным с помощью горизонтальных полос пропорционального размера. Например, в Grafana:

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