Привет, с вами команда разработки dBrain.cloud! Сегодня хотим поделиться историей миграции с Elasticsearch Beats Kibana (EBK) на Grafana Loki. Предпосылок перехода было немало: замена EBK лицензии Apache 2.0 на ограниченную SSPL 1.0, растущее потребление ресурсов, объемы требуемого места в хранилище и др. В предыдущей публикации мы подробно рассказали о стеке для мониторинга (прочитать можно здесь). Сегодня покажем, как из грамотно подобранных и поселенных под одной крышей продуктов получилось собрать единый стек логирования и мониторинга.

Отношения со сложностями

Изначально в платформе dBrain применялся классический Elasticsearch Beats Kibana стек. Мы использовали filebeat для сбора логов контейнеров кластера K8s, логов аудита API-сервера K8s и journalbeat для отправки системных журналов и аудита ОС. Биты вычитывают и преобразуют эти источники логов в формат индексов, чтобы все данные были структурированы внутри самой базы Elasticsearch. Это требует определенных ресурсов на каждом узле кластера.

Индексы могут быть как строго типизированные с определенным маппингом по заранее заданным полям, так и свободно расширяемые. В первом случае нам нужен заранее определенный шаблон (маппинг) полей на каждый индекс. Во втором варианте какое бы событие не было отправлено в индекс, оно сохранится с учетом всех полей, которые в нем есть. При этом размер индекса в Elasticsearch может неконтролируемо увеличиваться.

Когда мы начали внедрять систему мониторинга на базе стека Grafana VictoriaMetrics, то обратили внимание на Grafana Loki. Провели сравнительный анализ и убедились, что Loki Promtail Grafana стек имеет ряд неоспоримых преимуществ, которых не было на Elasticsearch Beats Kibana.

EBK стек был у нас в высоко доступной конфигурации, т.е. на больших кластерах было минимум три ноды Elasticsearch и как минимум две копии каждой шарды индекса данных. А это весьма существенный объем данных. Приходилось постоянно делать оптимизацию индексов, правил аудита и другие манипуляции, чтобы собирать только те логи, которые нам нужны, и индексировать их по минимальному количеству необходимых ключевых полей. Тем не менее, например, в Kubernetes мы использовали механизм crio autodiscovery, который строил индекс по всем лейблам и аннотациям. Таким образом, любой пользователь мог сам определить, какие лейблы добавлять в свое приложение. Все они попадали как ключевые поля в индексы. Это увеличивало объем занимаемого места на диске, а сами "ключи" не всегда использовались.

Любовь с первого взгляда

Под базу данных Elasticsearch приходилось выделять отдельные диски внутри самого Kubernetes-кластера. А это существенный объем зарезервированного места, необходимого для хранения логов в высоко доступной конфигурации (с учетом периода их хранения). С переходом на Loki в качестве бэкенда используется объектное хранилище S3 и фактически отсутствует дублирование логов. Теперь легко решается проблема высокой доступности, потому что мы резервируем только оперативные данные внутри микросервисной архитектуры Loki, а уже отправленные чанки логов в S3 проверяем на дедупликацию.

Loki отлично “заточен” под Kubernetes и контейнеризацию: он разбит на много микросервисов, каждый из которых выполняет свою роль.

Grafana Loki прекрасно интегрируется со стеком мониторинга и алертинга в нашей платформе. Мы можем писать гибкие правила, по которым будем получать алерты, события, отображаемые в логах приложения, и их максимально допустимое количество в заданный промежуток времени. Все логи отображаются в том же UI, что и метрики приложения - на дашборде Grafana. Конечному пользователю не нужен дополнительный инструмент для отображения и анализа логов. Взаимодействие пользователя с кластером Loki намного проще, чем с кластером Elasticsearch.

В Loki не надо хранить целиком сообщения в сыром виде и их полнотекстовые индексы по определенным полям. Мы проанализировали самые частые запросы в Kibana от различных команд пользователей. Таким образом определили по каким лейблам делать отдельные стримы внутри кластера Loki при создании внутреннего индекса объектов S3. Их оказалось значительно меньше, чем мы до этого индексировали внутри Elasticsearch. Это основные лейблы приложений внутри Kubernetes, syslog-идентификатор системных служб (если говорим про системные логи с серверов), шардированный стрим аудита API-сервера самого Kubernetes, а также лейбл ноды источника логов.

В результате, чтобы обеспечить работоспособность стека логирования и сбора логов, мы используем намного меньше оперативной памяти на кластере. Такая схема легко масштабируется горизонтально. Раньше в пиковые моменты мы не могли увеличить количество реплик, чтобы обработать больше запросов. Сейчас это происходит автоматически с помощью горизонтальных автоскейлеров внутри кластера. Специально под стек Loki мы внедрили Predictive Horizontal Pod Autoscaler (PHPA) - HPA с дополнительными встроенными возможностями прогнозирования, позволяющими применять статистические модели к результатам вычислений желаемого количества реплик. Это нужно для принятия упреждающих решений по масштабированию, чтобы наши клиенты не ощущали задержек обработки запросов в пиковые часы нагрузки.

Получилось, что для хранения примерно одинакового объема логов в Loki нужно в 3-4 раза меньше места, чем в Elasticsearch. При этом мы не используем максимальную степень сжатия логов, чтобы увеличить быстродействие. Теперь на кластерах, где место играет существенную роль или нужно хранить логи за длительный период, мы можем перейти к gzip сжатию логов и еще немного сэкономить объем занимаемой памяти - примерно в 8 раз по сравнению с кластерами Elasticsearch. В абсолютных величинах это выглядит так: на нашем develop кластере из 27 нод стек EBK занимает 3*200GB c ретеншн периодом 7 дней, в то время как LPG стек хранит логи за 30 дней в бакете, размер всех объектов в котором составляет около 700GB.

Чтобы увеличить скорость обработки запросов, в Loki (по аналогии с Prometheus) начали использовать TSDB вместо boltdb-shipper индекса. Это ускорило обработку запросов примерно в три раза (т.е. количество ресурсов CPU, которые требуются на обработку одинаковых запросов с тем же количеством логов). С помощью новой технологии мы выиграли в оптимизации ресурсов для обработки одного и того же количества запросов.

Как ужиться под одной крышей

Системы логирования и мониторинга - это сладкая парочка, которая всегда вместе. Поэтому важно подобрать дополняющие друг друга и максимально совместимые системы. Стек Loki легко и без адаптеров интегрируется в систему мониторинга VictoriaMetrics. Все, что происходит внутри кластера Loki, мы видим в системе Grafana, дашборды которой используем для отображения самих логов. Grafana позволяет гибко настраивать дашборды и оптимизировать для команд отображение логов их приложений. Процесс гибко кастомизируется: мы используем общий дашборд, который позволяет выводить логи за определенный период времени.

Promtail при грамотной настройке может перекрывать большую часть функционала битов, которые предоставляет стек ELK. Теперь у нас единый микросервис Promtail, который осуществляет сборку всех логов с каждой ноды. При необходимости мы можем джобами дописывать сборку конкретных логов какого-либо специфического приложения, запущенного на сервере. Данный стек потребляет существенно меньше ресурсов, чем совокупность битов, которые применялись у нас раньше. Кроме того, за счет низкого потребления ресурсов мы можем интегрировать Promtail в сайдкар-контейнер отдельных подов приложения. Это нужно для сбора и отправки их локальных логов непосредственно в Loki, минуя стандартные механизмы сбора самого Kubernetes.

На сегодняшний день мы имеем однородный стек на базе разных продуктов, идеально сочетающихся друг с другом. В Grafana в одном веб-интерфейсе можно переключаться между метриками и логами, делать перекрестные ссылки для удобного анализа инцидентов. Здесь реализован механизм multitenancy для разграничения прав доступа между проектами.

Все запущенные на платформе dBrain приложения автоматически попадают в систему логирования и мониторинга. Наши системы слежения - полноценный комплекс наблюдения за платформой и запущенными на ее базе приложениями. Такой подход минимизирует риски сбоев, потому что любое отклонение в работе приложения сразу же фиксируется. Вы сможете видеть, что, где и когда произошло, а значит будете во всеоружии, чтобы устранить проблему как можно быстрее.

В следующем материале расскажем, каким образом консоль dBrain упрощает путь от разработки до внедрения приложений. Консоль dBrain является преимуществом платформы, она существенно экономит ресурсы DevOps-инженеров, разработчиков, специалистов по информационной безопасности. Экономия времени ключевых сотрудников, в свою очередь, позволяет компаниям сократить расходы на обслуживание микросервисных приложений.

О каких нюансах разработки и использования платформы dBrain вы хотели бы услышать? Задавайте свои вопросы в комментариях, нам важно быть с вами на одной волне и знать, что вас интересует.