У компании «Флант» есть ряд Open Source-разработок, преимущественно для Kubernetes, и loghouse — одна из самых популярных. Это наш инструмент для централизованного логирования в K8s, который был представлен более 2 лет назад.
Как мы упоминали в недавней статье про логи, он требовал доработки, и актуальность её со временем только росла. Сегодня мы рады представить новую версию loghouse — v0.3.0. Подробности о ней — под катом.
Недостатки
Мы используем loghouse во множестве Kubernetes-кластеров всё это время, и в целом такое решение устраивает как нас самих, так и различных клиентов, которым мы тоже предоставляем доступ.
Главные его плюсы — простой и понятный интерфейс, возможность исполнения SQL-запросов, хорошее сжатие и низкое потребление ресурсов при вставке данных в базу, а также низкие накладные ресурсы при хранении.
Самые наболевшие проблемы в loghouse за время эксплуатации:
- использование таблиц-партиций, объединённых merge-таблицей;
- отсутствие буфера, который бы сглаживал всплески логов;
- устаревшие и потенциально уязвимые gem в веб-панели;
- устаревший fluentd (loghouse-fluentd:latest не стартовал из-за проблемного gemset'а).
Кроме того, накопилось значительное количество issues на GitHub, которые тоже хотелось бы решить.
Главные изменения в loghouse 0.3.0
На самом деле, изменений у нас накопилось достаточное количество, но мы осветим самые важные. Их можно разделить на 3 основные группы:
- улучшение хранения логов и схемы БД;
- улучшение сбора логов;
- появление мониторинга.
1. Улучшения в хранении логов и схеме базы
Ключевые новшества:
- Изменились схемы хранения логов, осуществлён переход на работу с единой таблицей и отказ от таблиц-партиций.
- Начал применяться механизм очистки базы, встроенный в ClickHouse последних версий.
- Появилась возможность использования внешней инсталляции ClickHouse, даже в режиме кластера.
Сравним производительность старой и новой схем в реальном проекте. Вот пример поиска уникальных URL в логах приложения популярного онлайн-ресурса dtf.ru:
SELECT
string_fields.values[indexOf(string_fields.names, 'path')] AS path,
count(*) AS count
FROM logs
WHERE (namespace = 'kube-nginx-ingress') AND ((string_fields.values[indexOf(string_fields.names, 'vhost')]) LIKE '%foobar.baz%') AND (date = '2020-02-29')
GROUP BY string_fields.values[indexOf(string_fields.names, 'path')]
ORDER BY count DESC
LIMIT 20Отбор происходит по десяткам миллионов записей. Старая схема отрабатывала за 20 секунд:
Новая — за 14:
Если вы используете наш Helm-чарт, то при обновлении loghouse будет автоматически произведена миграция базы на новый формат. В противном случае — придётся сделать миграцию вручную. Процесс описан в документации. Если вкратце, то достаточно запустить:
DO_DB_DEPLOY=true rake create_logs_tablesКроме того, мы начали использовать TTL для таблиц ClickHouse. Это позволяет автоматически удалять из БД данные, которые старше, чем заданный временной интервал:
CREATE TABLE logs
(
....
)
ENGINE = MergeTree()
PARTITION BY (date, toHour(timestamp))
ORDER BY (timestamp, nsec, namespace, container_name)
TTL date + toIntervalDay(14)
SETTINGS index_granularity = 32768;Примеры схем баз данных и конфигов для ClickHouse, включая пример работы с кластером CH, можно найти в документации.
Улучшение сбора логов
Основные новшества:
- Добавлен буфер, который призван сгладить всплески при появлении большого числа логов.
- Реализована возможность отправлять логи в loghouse напрямую из приложения: по TCP и UDP, в формате JSON.
Аккумулятором логов в loghouse стала новая таблица logs_buffer, добавленная в схему БД. Эта таблица — in-memory, т.е. хранится в RAM (имеет специальный тип Buffer); именно она и должна сгладить нагрузку на базу. За совет по её добавлению благодарим Sovigod!
Реализованная отправка логов напрямую в loghouse из приложения позволяет делать это даже через netcat:
echo '{"log": {"level": "info", "msg": "hello world"}}' | nc fluentd.loghouse 5170
Данные логи можно посмотреть в пространстве имён, куда установлен loghouse, в потоке net:
Требования к отправляемым данным минимальны: сообщение должно быть корректным JSON с полем log. Поле log, в свою очередь, может быть как строкой, так и nested JSON.
Мониторинг работы подсистемы логирования
Важным улучшением стал мониторинг fluentd через Prometheus. Теперь в комплекте к loghouse идёт панель для Grafana, которая отображает все основные метрики, такие как:
- количество работающих fluentd;
- количество отправляемых событий в ClickHouse;
- размер свободного буфера в процентах.
Код панели для Grafana можно увидеть в документации.
Панель для ClickHouse сделана на основе уже готового продукта — от f1yegor, за что автору большое спасибо.
Как видно, в панели отображается количество подключений к ClickHouse, использование буфера, активность фоновых задач и количество слияний. Этого вполне достаточно для понимания состояния системы:
Панель для fluentd показывает активные экземпляры fluentd. Это особенно критично для тех, кто совсем не хочет/не может терять логи:
Кроме статуса pod'ов, в панели видна нагрузка на очередь отправки логов в ClickHouse. По очередям можно понять, справляется ClickHouse с нагрузкой или уже нет. В случаях, когда лог нельзя терять, этот параметр тоже становится критичным.
Примеры панелей заточены под нашу поставку Prometheus Operator, однако легко модифицируются через переменные в настройках.
Наконец, в рамках работ по мониторингу loghouse мы собрали актуальный Docker-образ с релизом clickhouse_exporter 0.1.0 от Percona Labs, так как автор оригинального clickhouse_exporter забросил свой репозиторий.
Планы на будущее
- Сделать возможным развертывание кластера ClickHouse в Kubernetes.
- Сделать работу с выборкой логов асинхронной и вынести её из Ruby-части бэкенда.
- В Ruby-приложении есть известные узкие места, над исправлением которых мы работаем.
- Возможно, частично переписать бэкенд на Go.
- Сделать фильтрацию логов.
Вместо заключения
Приятно видеть, что проект loghouse нашёл свою аудиторию, не только завоевав звёздочки в GitHub (600+), но и побудив реальных пользователей рассказывать о своих успехах и проблемах.
Создав loghouse более 2 лет назад, мы не были уверены в его перспективах, ожидая, что рынок и/или Open Source-сообщество предложат лучшие решения. Однако на сегодняшний день видим, что это жизнеспособный путь, который мы сами по-прежнему выбираем и используем на множестве обслуживаемых Kubernetes-кластеров.
Будем рады любому содействию в улучшении и развитии loghouse. Если вам чего-то не хватает в loghouse — пишите в комментариях. Также мы, конечно, будем рады активности на GitHub.
P.S.
Читайте также в нашем блоге:
- «Логи в Kubernetes (и не только) сегодня: ожидания и реальность»;
- «Представляем loghouse — Open Source-систему для работы с логами в Kubernetes».
Автор: Николай Богданов
