Создание эффективной и масштабируемой системы мониторинга — задача, стоящая перед многими компаниями. Эта статья описывает опыт автора в создании такой системы с использованием ClickHouse как хранилища данных и Grafana для визуализации. Здесь вы найдете анализ различных технологий, описание конечного решения и основные выводы.
Введение
На протяжении последних шести месяцев автор работал над экспериментальным проектом мониторинга для инфраструктуры компании. Работа началась с анализа существующих решений и в итоге остановилась на связке ClickHouse + Grafana. Этот выбор оказался оптимальным для заявленных нужд, хотя и потребовал значительных усилий по настройке и интеграции.
Эта статья охватывает:
- Исходные условия.
- Основные требования.
- Рассмотренные стеки технологий.
- Преимущества и недостатки итогового решения.
Исходная точка
Начальная инфраструктура базировалась на Elastic Stack (EFK), который использовался для сбора логов NGINX и выполнения базового анализа данных. Однако Elastic Stack оказался:
- Ресурсоемким: 14 дней логов занимали около 200 ГБ.
- Медленным: запросы требовали много времени.
- Неудобным в работе: язык запросов (Painless) сложен в использовании, а API основан на JSON.
Несмотря на возражения некоторых членов команды, автор инициировал замену этого стека, так как он не отвечал растущим требованиям компании.
Основные требования
Новая система должна была:
- Быть экономичной и вертикально масштабируемой.
- Обладать мощным языком запросов (желательно SQL).
- Поддерживать интеграцию с различными инструментами.
- Обеспечивать высокую доступность и репликацию.
ClickHouse полностью удовлетворил этим требованиям благодаря своим возможностям и поддержке сообщества.
Рассмотренные стеки технологий
Elasticsearch + Grafana
Попытка интеграции Elastic с Grafana выявила множество ограничений, таких как необходимость группировки данных при выполнении запросов. Кроме того, Elastic оказался сложным в обслуживании и ресурсозатратным.
Loki + Grafana
Документация Loki была недостаточно полной, а установка сложной. Loki лучше всего подходит для поиска событий, но не для сложной обработки данных или метрик.
TimescaleDB и InfluxDB + Grafana
- TimescaleDB: мощное решение для временных рядов, но уступает ClickHouse по популярности и поддержке сообщества.
- InfluxDB: бесплатная версия не поддерживает кластеризацию, что делает ее неподходящей для заявленных требований.
SigNoz
Этот инструмент был ограничен в функциональности на момент тестирования и не подошел автору.
Итоговое решение: ClickHouse + Grafana
Сбор данных
Для сбора и обработки данных использовались:
- Fluent Bit: простой, стабильный инструмент с хорошей документацией.
- Vector: мощный язык обработки данных VRL, вдохновленный Rust, но без его сложности.
Интеграция
Grafana имеет качественный плагин для ClickHouse, который поддерживает все типы данных. SQL-запросы обеспечивают гибкость в анализе данных. Например:
SELECT
toStartOfInterval(timestamp, INTERVAL 5 MINUTE) AS time,
map(status::String, count()) AS codes
FROM nginx.access
WHERE $__timeFilter(time)
GROUP BY time, status
Основные трудности:
- Ad hoc фильтры иногда не работают корректно.
- Большие объемы данных снижают производительность запросов. Для оптимизации используются материализованные представления.
Преимущества ClickHouse
ClickHouse предлагает:
- Различные форматы данных для ввода и вывода.
- Гибкость в настройке хранения и сжатия данных.
- CLI для работы с данными через пайплайны.
Пример работы через CLI:
codeclickhouse-client -q "SELECT * FROM nginx.access WHERE client = '127.0.0.1'"
Настройка дашбордов в Grafana
Процесс создания дашбордов включает:
- Определение целей визуализации.
- Создание схем таблиц в ClickHouse.
- Построение и тестирование визуализаций.
- Постепенное улучшение и поддержание актуальности дашбордов.
Пример настройки динамических визуализаций:
- Цвета HTTP-статусов настроены по диапазонам: 200 (зеленый), 300 (синий).
- Легенда упрощает анализ данных за выбранный временной промежуток.
Основные сложности
TTL
В ранних версиях ClickHouse TTL не работали из-за багов, но проблема была устранена после обновления.
Сломанные запросы
Некоторые запросы перестали работать после обновления до версии 24.3. Решение потребовало модификации SQL-кода.
Производительность
Для оптимизации были использованы материализованные представления и предвычисление метрик.
Дальнейшие улучшения
Проект продолжит развиваться в следующих направлениях:
- Добавление очередей сообщений.
- Реализация репликации и высокой доступности.
- Расширение сбора данных на другие компоненты инфраструктуры.
- Настройка оповещений для критических событий.
- Оптимизация производительности.
Заключение
Выбор технологии мониторинга зависит от требований вашей инфраструктуры. ClickHouse и Grafana стали оптимальным решением для команды автора, предоставив мощные инструменты анализа и визуализации данных. Этот опыт может быть полезен другим командам, стремящимся улучшить свои процессы.
Если у вас остались вопросы или вы хотите узнать больше, не стесняйтесь задавать их!
Оригинал статьи:
https://cmtops.dev/posts/building-observability-with-clickhouse/