Использование 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.