Привет, Хабр! Меня зовут Максим Юрченко, я руководитель группы DevOps-инженеров в Lenta tech («Группа Лента»). В статье я расскажу о том, как за последние четыре года менялась наша система логирования, какие решения мы принимали по ходу роста инфраструктуры и к какому результату в итоге пришли.
Стартовая точка: инфраструктура и вводные
Когда мы только начинали этот путь, перед нами стояла типичная для растущей IT-инфраструктуры задача. В пиковые периоды у нас работало около 2000 нод, а объем генерируемых логов превышал терабайт в сутки. Это были логи приложений, системные сообщения и данные аудита — всё, без чего невозможно поддерживать сложную распределенную систему.
Самым жестким ограничением при этом оказался бюджет. В ретейле эффективность измеряется не только скоростью и надежностью, но и стоимостью владения: любые инфраструктурные решения должны быть оправданы экономически.
Поэтому с самого начала мы исходили из простого принципа: система должна работать максимально эффективно и с минимальными затратами и эта логика влияла на все наши технические решения.
Сама задача звучала просто: множество наших сервисов пишут логи в стандартный вывод (stdout), а эти данные нужно централизованно собрать, надежно доставить, сохранить и дать командам удобный инструмент для визуализации и анализа.
В качестве визуализации мы сразу выбрали Grafana, и это решение пришлось учитывать при выборе остальных компонентов стека.
Первая версия: Promtail + Loki + Grafana
Наш путь начался с самого очевидного на тот момент стека:
Promtail — агент для сбора логов;
Loki — хранилище и движок запросов;
Grafana — визуализация.
Система была развернута буквально за день, и первое время работала как швейцарские часы. Мы, команда DevOps, были счастливы: логи собираются, запросы выполняются, всё под контролем.
Этот «золотой век» продлился около полугода. Проблемы начались, когда мы открыли доступ к логированию другим командам — разработчикам, аналитикам, специалистам по безопасности. И здесь начали проявляться ограничения первой архитектуры:
потребление ресурсов росло нелинейно;
сложные запросы к Loki начали отваливаться по таймауту;
в Grafana вместо графиков и таблиц всё чаще появлялись ошибки;
система не была отказоустойчивой: сбой одного компонента мог остановить сбор логов целиком.
Каждую такую жалобу приходилось разбирать вручную, отвлекаясь от других задач. В какой-то момент стало очевидно, что эта архитектура не масштабируется под наш реальный размер и количество пользователей.
Вторая версия: Vector + Kafka + ClickHouse
Первая версия была хороша для старта, но оказалась слишком хрупкой. Мы поняли, что дальше так жить нельзя, и сформулировали требования к новой системе:
Горизонтальная масштабируемость: возможность легко добавлять мощности по мере роста нагрузки.
Отказоустойчивость: отказ одного компонента не должен приводить к потере данных или полной недоступности сервиса.
Самообслуживание и снижение операционной нагрузки: система должна требовать как можно меньше ручного вмешательства.
После анализа рынка мы остановились на следующей архитектуре:
Vector заменил Promtail в роли агента для сбора логов. Это был осознанный риск: у проекта нет стабильного релиза 1.0, а обновления нередко меняли конфигурации, поэтому к изменениям приходилось быть готовыми заранее.
В качестве буферного слоя мы добавили Apache Kafka. Она принимала «сырые» логи и хранила их короткое время — несколько дней — на случай, если следующие компоненты пайплайна временно недоступны. Второй инстанс Vector забирал данные из Kafka, парсил и приводил их к нужному виду.
Финальным хранилищем стал ClickHouse. Несмотря на то, что это не специализированное хранилище для логов, его аналитические возможности и скорость работы с большими объемами данных полностью соответствовали требованиям нашей задачи.
Результаты этой миграции были впечатляющими:
достигли высокой отказоустойчивости благодаря буферизации в Kafka;
потребление ресурсов самими коллекторами (агентами) упало в разы при возросшем объеме данных;
первоначальная конфигурация ClickHouse (11 vCPU, 16 ГБ RAM) уверенно справлялась с нагрузкой.
Мы вздохнули с облегчением. Казалось, найден Грааль.
Что пошло не так спустя два года
Примерно через два года эксплуатации начали проявляться новые проблемы, связанные уже не с архитектурой доставки, а с ростом нагрузки:
Чтобы справляться с возросшим объемом вставок, кластер ClickHouse пришлось увеличить до трех инстансов с 16 vCPU и 48 ГБ RAM каждый.
При пиковых нагрузках механизм слияния данных (MergeTree) не успевал обрабатывать входящие записи. В результате росло количество мелких кусков данных на диске, падала скорость чтения и быстро заполнялось дисковое пространство.
В нескольких инцидентах ZooKeeper, выступающий координатором кластера ClickHouse, из-за особенностей алгоритма дедупликации терял часть данных, что приводило к неконсистентности реплик.
Каждый новый сервис или даже новая фича в существующих сервисах приносили собственный формат логов. Это приводило к постоянному появлению новых полей в ClickHouse, усложнению SQL-запросов и кастомным дашбордам в Grafana, которые дополнительно нагружали базу.
Мы осознали важный принцип: в экосистеме из сотен микросервисов бессмысленно жёстко стандартизировать формат логов. Гораздо эффективнее строить систему, способную «переваривать» любой хаос входящих данных — будь то аккуратный JSON, многострочный стектрейс Java-приложения или неструктурированный вывод системного демона.
Специализированное решение Victoria Logs
В этот момент на наш радар попала Victoria Logs — относительно новый продукт от создателей системы мониторинга VictoriaMetrics. Она сразу позиционировалась как база данных, созданная специально для хранения и анализа логов: не универсальный поисковый движок и не аналитическая СУБД общего назначения, а узкоспециализированный инструмент под одну задачу.
На тот момент у Victoria Logs существовала только single-нодовая версия, что было ощутимым риском. Тем не менее нас привлекли активное сообщество вокруг проекта и прямая, отзывчивая поддержка от самих разработчиков в публичных чатах.
Наш «исследовательский процесс» был далек от академического и состоял из нескольких шагов:
изучение сравнительных таблиц, где Victoria Logs заметно опережала Elasticsearch по скорости запросов и коэффициенту сжатия на сопоставимом железе (1);
чтение отзывов в чате сообщества — в том числе кейса с заменой кластера из 27 нод Elasticsearch на одну ноду Victoria Logs с резким снижением затрат и ростом производительности (2);
запуск пилотного внедрения без риска для основной инфраструктуры: мы перенаправили логи с одного Kubernetes-кластера в новую систему, оставив ClickHouse работать в штатном режиме, и увидели многократное сжатие данных (3).
Это позволило оценить работу Victoria Logs в реальных условиях, не затрагивая основную инфраструктуру.
Пилотирование и переход в production
Результаты пилота превзошли все ожидания. Коэффициент сжатия данных превысил 50x, система стабильно работала под нагрузкой, а переход в production занял считанные дни. После этого мы безболезненно переключили на новую систему все логи из Kubernetes, подключили аудит объектного хранилища S3, добавили аудит более чем 50 кластеров PostgreSQL и перевели все дашборды в Grafana на Victoria Logs.
На сегодняшний день:
все логи хранятся в Victoria Logs;
инстанс с конфигурацией 6 vCPU и 8 ГБ RAM работает со средней загрузкой: CPU < 20% и RAM < 50%;
количество инцидентов, связанных с хранилищем логов — 0;
стоимость хранения — примерно 10 000 рублей в месяц в Яндекс Облаке.
Самое главное — система принимает логи в любом формате. Нам больше не нужно заранее парсить JSON или навязывать командам единый стандарт.
Текущие компромиссы и дорожная карта
Конечно, не всё идеально. Мы осознанно приняли несколько ограничений. На момент внедрения столкнулись с ограниченным горизонтальным масштабированием, так как кластерной версии Victoria Logs ещё не существовало. Сейчас она находится в бета-тесте, и мы внимательно следим за её развитием.
Кроме того, на этапе миграции нам пришлось поддерживать сразу две системы, что потребовало дополнительных усилий со стороны команды.
Наши планы по развитию системы логирования теперь выглядят так:
внедрить полноценное резервное копирование в S3, так как текущие снапшоты дисков не покрывают сценарии аварийного восстановления;
разделить политики хранения логов: для продакшн-окружения — около месяца, для разработки и тестирования — около недели, чтобы снизить затраты;
постепенно перейти на кластерную версию Victoria Logs, когда она достигнет достаточной стабильности и обеспечит горизонтальное масштабирование записи и чтения.
Итоги: от Нирваны к здравому смыслу
Подводя итог этого четырехлетнего пути, можно сказать, что мы не нашли одну «серебряную пулю» или идеальную архитектуру. Вместо этого прошли через несколько итераций, каждая из которых дала новые уроки. Ключевым результатом стало снижение затрат на хранение логов примерно в 10 раз по сравнению с первой работоспособной архитектурой на ClickHouse.
Главный вывод звучит парадоксально: стремление к универсальному и максимально отказоустойчивому решению нередко приводит к сложным, дорогим и тяжелым в поддержке системам. В условиях ограниченных ресурсов гораздо больше ценности может принести простое и узкоспециализированное решение, которое блестяще справляется с одной задачей — как Victoria Logs со сбором и хранением логов.
Наш путь логов, который когда-то, возможно, вёл в нирвану идеальной инфраструктуры, в итоге привёл нас к здравому смыслу, прагматизму и пониманию, что лучшая система — это та, которая решает бизнес-задачу с минимальными издержками и максимальной надежностью.
А какой путь в логировании прошли вы и на каком этапе поняли, что текущее решение больше не тянет масштаб?
