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

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

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

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

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

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