Использование ClickHouse для мониторинга
Введение
Данное руководство предназначено для пользователей, желающих создать собственное решение для мониторинга на основе SQL, используя ClickHouse, с фокусом на логи и трассировки. Здесь рассматриваются все аспекты создания вашего решения, включая вопросы приема данных, оптимизацию схем для ваших паттернов доступа и извлечение структуры из неструктурированных логов.
ClickHouse сам по себе не является готовым решением для мониторинга. Тем не менее, его можно использовать как высокоэффективный движок хранения данных для данных мониторинга, способный обеспечить непревзойденные уровни сжатия и молниеносное время ответа на запросы. Чтобы пользователи могли использовать ClickHouse в решении для мониторинга, необходимы как пользовательский интерфейс, так и фреймворк для сбора данных. В настоящее время мы рекомендуем использовать Grafana для визуализации сигналов мониторинга и 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 поддерживает открытые стандарты, такие как OpenTelemetry. Возможность вносить вклад и активно участвовать в проектах привлекательна, при этом избегая проблем с зависимостями от поставщиков.
Когда вы должны использовать 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.
