Как я logstash с clickhouse дружил. Начало.

Интересная история, как я подружил logstash и clickhouse на нашем проекте, борясь по пути с Docker и GitLab CI.
Данная заметка будет обзорная с постановкой задачи и поверхностном описании её решении. Интересные моменты будут описаны отдельно.

На нашем проекте настроена система журналирования жизненного цикла основных объектов. На данный момент журнал работает на связке ELK (ElasticSearch, Logstash и Kibana). Приложение пишет информацию о жизненном цикле в файлы. Изменения в файлах отслеживаются ещё одним элементом из связки ELK — FileBeat. После чего попадают в Logstash, который фильтрует получаемые события, преобразует данные и раскладывает данные в разные индексы в ElasticSearch. Kibana же используется для визуализации этих данных.

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

Как побочный результат данного журнала, мы можем использовать данный журнал для оценки состояния сервиса. Но для оценки состояния системы надо строить условно аналитические отчёты, которые будут высчитывать нужные метрики. Но ElasticSearch для этого не очень заточен. Плюс индексы занимают очень много места.

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

Первая попытка перенести индексы в БД от Yandex показало хорошие результаты. Построение запроса с группировкой по двум текстовым полям и датам на ~65 миллионах записей формировался всего за 3 секунды. Плюс занимаемый объём данных были примерно в 15 раз меньше 8 GB против 140 в ElasticSearch. По этому было принято решение вывести данное решение в промышленную эксплуатацию.

Первый шаг состоял в том, чтобы поставить Logstash с установленным плагином logstash-output-clickhouse. Но делать всё в ручную не хотелось. К тому же у нас всё крутится в Docker- контейнерах и хотелось получить повторяемое решение. Значит надо сделать сборку образа Logstash с установленным плагином. Но там Ruby. А это не наш профиль. Ставить куда-то ruby, чтобы прогнать одну сборку, как то не красиво. Значит надо настроить сборку Docker-контейнера внутри другого Docker-контейнера. И после сборке не останется следа. И не надо думать, что нужно устанавливать на сервер сборок Ruby.

И вот тут я вступил в другой круг. Я начинаю присматриваться к сборке на базе Gitlab CI, заменив тем самым TeamCity. И я уже пробовал запускать сборку внутри Docker-контейнера именно в Gitlab. Так что план вырисовался таким образом, что надо собрать Docker-контейнер в Gitlab и положить его в наш репозиторий. 

Делов то. И так началась эпопея на неделю. Задач то много, и эта далеко не сама главная. В рамках данной задачи пришлось разбираться с:

• самоподписаным сертификатом для нашего Docker-репозитория. Пришлось собирать отдельный образ Docker-контейнера внутри которого можно запустить сборку docker образа, и иметь возможность выложить результат сборки в наш репозиторий. 
• Явным образом пробрасывать docker процесс в Gitlab Runner. Если использовать стандартный образ для сборки, то всё работает. Если же делаешь свой образ на базе стандартного docker-процесс автоматом не пробрасывается в Gitlab Runner
• Gitlab pipeline. Для расширения кругозора, настройка запуска того или иного шага сборки на основании того, какая папка в исходниках изменилась. Как раз за три дня до этого вышла новая версия Gitlab, поддерживающая данную настройку.
• Из-за разных прав на файлы в разных контейнерах, пришлось пересобирать так же контейнер с FileBeat, чтобы Filebeat запускался от имени того пользователя, у которого есть право читать те файлы, которые надо отслеживать.
• Настройки собственно самого logstash-output-clickhouse

В отдельных статьях я опишу технические моменты, как решал эти задачи.

В итоге всё заработало.
И сейчас у нас параллельно идёт сохранение и в индекс ElasticSearch, чтобы можно было проводить исследование инцидентов. И сохранение этой же информации в Clickhouse для того, чтобы можно было проводить анализ состояния сервиса. 
В дальнейшем есть желание посмотреть

• сможем ли мы полностью заменить ElasticSearch в решении задач расследования инцидентов 
• Настроить Grafana для мониторинга состояния системы

Share this...

Facebook

Twitter

VK

email