Loghouse 0.3 — долгожданное обновление нашей системы работы с логами в Kubernetes

У компании «Флант» есть ряд Open Source-разработок, преимущественно для Kubernetes, и loghouse ^[1] — одна из самых популярных. Это наш инструмент для централизованного логирования в K8s, который был представлен ^[2] более 2 лет назад.

Как мы упоминали в недавней статье про логи ^[3], он требовал доработки, и актуальность её со временем только росла. Сегодня мы рады представить новую версию loghouse — v0.3.0. Подробности о ней — под катом.

Недостатки

Мы используем loghouse во множестве Kubernetes-кластеров всё это время, и в целом такое решение устраивает как нас самих, так и различных клиентов, которым мы тоже предоставляем доступ.

Главные его плюсы — простой и понятный интерфейс, возможность исполнения SQL-запросов, хорошее сжатие и низкое потребление ресурсов при вставке данных в базу, а также низкие накладные ресурсы при хранении.

Самые наболевшие проблемы в loghouse за время эксплуатации:

• использование таблиц-партиций, объединённых merge-таблицей;
• отсутствие буфера, который бы сглаживал всплески логов;
• устаревшие и потенциально уязвимые gem в веб-панели;
• устаревший fluentd (loghouse-fluentd:latest не стартовал из-за проблемного gemset'а).

Кроме того, накопилось значительное количество issues на GitHub ^[4], которые тоже хотелось бы решить.

Главные изменения в loghouse 0.3.0

На самом деле, изменений у нас накопилось достаточное количество, но мы осветим самые важные. Их можно разделить на 3 основные группы:

• улучшение хранения логов и схемы БД;
• улучшение сбора логов;
• появление мониторинга.

1. Улучшения в хранении логов и схеме базы

Ключевые новшества:

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

Сравним производительность старой и новой схем в реальном проекте. Вот пример поиска уникальных URL в логах приложения популярного онлайн-ресурса dtf.ru ^[5]:

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-чарт ^[6], то при обновлении loghouse будет автоматически произведена миграция базы на новый формат. В противном случае — придётся сделать миграцию вручную. Процесс описан в документации ^[7]. Если вкратце, то достаточно запустить:

DO_DB_DEPLOY=true rake create_logs_tables

Кроме того, мы начали использовать TTL для таблиц ClickHouse ^[8]. Это позволяет автоматически удалять из БД данные, которые старше, чем заданный временной интервал:

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, можно найти в документации ^[7].

Улучшение сбора логов

Основные новшества:

• Добавлен буфер, который призван сгладить всплески при появлении большого числа логов.
• Реализована возможность отправлять логи в loghouse напрямую из приложения: по TCP и UDP, в формате JSON.

Аккумулятором логов в loghouse стала новая таблица logs_buffer, добавленная в схему БД. Эта таблица — in-memory, т.е. хранится в RAM (имеет специальный тип Buffer ^[9]); именно она и должна сгладить нагрузку на базу. За совет ^[10] по её добавлению благодарим Sovigod ^[11]!

Реализованная отправка логов напрямую в 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 можно увидеть в документации ^[12].

Панель для ClickHouse сделана на основе уже готового продукта ^[13] — от f1yegor, за что автору большое спасибо.

Как видно, в панели отображается количество подключений к ClickHouse, использование буфера, активность фоновых задач и количество слияний. Этого вполне достаточно для понимания состояния системы:

Панель для fluentd показывает активные экземпляры fluentd. Это особенно критично для тех, кто совсем не хочет/не может терять логи:

Кроме статуса pod'ов, в панели видна нагрузка на очередь отправки логов в ClickHouse. По очередям можно понять, справляется ClickHouse с нагрузкой или уже нет. В случаях, когда лог нельзя терять, этот параметр тоже становится критичным.

Примеры панелей заточены под нашу поставку Prometheus Operator, однако легко модифицируются через переменные в настройках.

Наконец, в рамках работ по мониторингу loghouse мы собрали актуальный Docker-образ с релизом clickhouse_exporter ^[14] 0.1.0 от Percona Labs, так как автор оригинального clickhouse_exporter ^[15] забросил свой репозиторий.

Планы на будущее

• Сделать возможным развертывание кластера ClickHouse в Kubernetes.
• Сделать работу с выборкой логов асинхронной и вынести её из Ruby-части бэкенда.
• В Ruby-приложении есть известные узкие места, над исправлением которых мы работаем.
• Возможно, частично переписать бэкенд на Go.
• Сделать фильтрацию логов.

Вместо заключения

Приятно видеть, что проект loghouse нашёл свою аудиторию, не только завоевав звёздочки в GitHub (600+), но и побудив реальных пользователей рассказывать о своих успехах и проблемах.

Создав loghouse более 2 лет назад, мы не были уверены в его перспективах, ожидая, что рынок и/или Open Source-сообщество предложат лучшие решения. Однако на сегодняшний день видим, что это жизнеспособный путь, который мы сами по-прежнему выбираем и используем на множестве обслуживаемых Kubernetes-кластеров.

Будем рады любому содействию в улучшении и развитии loghouse. Если вам чего-то не хватает в loghouse — пишите в комментариях. Также мы, конечно, будем рады активности на GitHub ^[1].

P.S.

Читайте также в нашем блоге:

• «Логи в Kubernetes (и не только) сегодня: ожидания и реальность ^[3]»;
• «Представляем loghouse — Open Source-систему для работы с логами в Kubernetes ^[2]».

Автор: Николай Богданов

Источник ^[16]