Loki против ClickHouse для долгого хранения логов и скорости запросов

Почему долгое хранение логов превращается в проблему для бюджета

Команды редко выбирают полгода хранения логов с самого начала. Обычно начинают с 7 или 30 дней, а потом понемногу увеличивают срок. Support нужна более старая информация. Security просит более длинное окно. Аудит приходит поздно. Ежедневный ingest почти не меняется, но счёт всё равно постепенно растёт.

Когда люди сравнивают Loki и ClickHouse для долгого хранения, обычно первым делом смотрят на цену хранения. Но это лишь часть затрат. Долгое хранение давит сразу на три вещи: где лежат данные, как быстро их можно искать и сколько работы система создаёт для команды.

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

Ещё одна ошибка — считать логи холодным бэкапом. Логи действительно хранятся, но их ещё и запрашивают под давлением. Во время инцидента поиск, который занимает пять минут, — это не мелкое неудобство. Он замедляет расследование, съедает время инженеров и может дольше держать проблему клиента открытой.

Обычно бюджет распадается на несколько частей: сырой storage, индексы или metadata storage, вычисления для ingest и запросов, а также время инженеров на тюнинг, правила хранения и очистку. Неудачный выбор сжигает деньги даже тогда, когда ежедневный ingest остаётся на одном уровне. Одна команда может по-прежнему отправлять те же 200 GB в день, но расходы всё равно растут, потому что тяжелеют широкие запросы, старые данные ищутся медленнее, а для приемлемого времени ответа добавляют всё больше железа.

Поэтому решение о хранении на 30 дней выглядит нормальным, а на 180 дней — болезненным. Пока данные новые, система кажется доступной. Проблемы начинаются позже, когда старые логи перестают ощущаться как дешёвое хранилище и начинают вести себя как вторая production-система.

Как Loki меняется на 30, 90 и 180 день

Loki — не универсальная база данных. Он хранит сжатые чанки логов и использует labels, чтобы сузить поиск. Это хорошо работает, когда инженеры в основном смотрят свежие логи во время инцидентов, деплоев и поддержки.

На 30 дне Loki обычно работает приятно, если labels спроектированы аккуратно. Команда фильтрует по service, environment, region или tenant и быстро добирается до свежих логов. Узкие запросы — именно та зона, где Loki чувствует себя лучше всего.

На 90 дне мелкие ошибки в labels начинают отражаться и в счёте, и во времени поиска. Слишком общие labels заставляют запросы сканировать слишком много данных. Слишком детальные labels повышают cardinality, увеличивают расход памяти и усложняют работу системы. Команды часто узнают это на практике, когда кто-то запускает широкий поиск по множеству сервисов и большому временному диапазону.

К 180 дню trade-off становится очевидным. Storage всё ещё может выглядеть дешёвым, потому что старые чанки лежат в object storage, а оно значительно дешевле горячих дисков. Проблема появляется, когда люди ищут эти старые данные. Широкие запросы часто начинают тормозить, потому что Loki всё равно должен открыть и просканировать множество чанков, прежде чем найдёт нужные строки.

Общая картина простая:

• 30 дней: обычно комфортно для ежедневной отладки
• 90 дней: дизайн labels и привычки поиска начинают определять стоимость и скорость
• 180 дней: хранение всё ещё может оставаться дешёвым, но широкие поиски по старым данным часто раздражают

Это делает Loki сильным вариантом для команд, которым в основном нужны свежие operational logs. Если разработчики большую часть времени проверяют последние часы или дни, Loki часто — разумный выбор. Если support, security или аналитики задают открытые вопросы по истории за месяцы, Loki может казаться медленным, даже если storage всё ещё стоит недорого.

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

Как ClickHouse меняется на 30, 90 и 180 день

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

На 30 дне ClickHouse часто выглядит впечатляюще. Свежие данные легко искать, дашборды работают быстро, а storage может оказаться ниже ожидаемого, потому что column compression хорошо работает для полей вроде service name, status code, region и log level.

На 90 дне начинают играть роль ранние решения. Если логи попадают в разумные partitions, используют понятную колонку времени и содержат именно те поля, по которым люди ищут, ClickHouse по-прежнему кажется быстрым. Если schema слишком свободная или каждый поиск должен разбирать raw text либо JSON, скорость падает, а расходы растут, потому что база читает больше данных, чем нужно.

Несколько решений влияют на следующие месяцы: как данные partitioned, какие поля вынесены в отдельные колонки, как долго hot data остаётся до переноса в более дешёвое хранилище и кто отвечает за retention и cleanup.

К 180 дню ClickHouse всё ещё может работать отлично, но только если кто-то проектировал и поддерживал его осознанно. Долгое хранение означает, что merges, TTL rules, очистка partitions и tiering storage требуют внимания. Сжатие помогает, но хорошее сжатие не спасает слабую структуру.

Простой пример хорошо показывает разницу. Допустим, команда спрашивает: «Что изменилось для этого клиента за последние 120 дней?» ClickHouse отлично справляется с таким запросом, если customer ID, service name и timestamp лежат в понятных колонках. Тот же запрос намного тяжелее, если эти значения спрятаны внутри raw JSON, который каждый поиск должен разбирать.

Вот что многие команды упускают. ClickHouse часто покупает скорость и более низкий расход storage ценой upfront work. Если один инженер потратит несколько сфокусированных часов на schema, partitions и retention jobs, система может оставаться дешёвой и быстрой даже через полгода. Если никто не владеет этими решениями, и поддержка, и счёт обычно растут одновременно.

Как скорость запросов меняет расследование проблем

Медленные поиски по логам вредят сильнее, чем кажется. Они не просто съедают несколько минут. Они меняют ход мыслей во время инцидента.

Большинство расследований — это не один запрос и готовый ответ. Разработчик начинает с последнего часа, находит подсказку, расширяет диапазон до шести часов, потом до суток, а потом, возможно, до недели. Если каждый шаг тормозит, весь процесс становится вялым. Люди перестают проверять гипотезы и останавливаются на первом объяснении, которое кажется достаточно хорошим.

Типичный workflow инцидента выглядит так:

• проверить ошибки за последний час для одного сервиса
• расширить поиск на все инстансы этого сервиса
• поискать тот же паттерн за сутки
• сравнить его с окном деплоя
• просканировать более старые логи, чтобы понять, когда паттерн появился впервые

Именно здесь разница между Loki и ClickHouse становится практической. Loki обычно чувствует себя нормально, когда временной диапазон короткий, а labels чистые. Если вы знаете service, cluster и time window, можно двигаться быстро. Но повторяющиеся ad hoc поиски становятся болезненными, когда запрос превращается в широкий text scan по старым данным.

ClickHouse обычно сильнее, когда поиск расширяется. Большие сканы, повторные сравнения и агрегированные представления подходят ему лучше, особенно если структура таблицы совпадает с вопросами, которые команда задаёт постоянно. Цена — больше работы заранее над schema, ingest и tuning.

Дашборды и ручной поиск нагружают систему по-разному. Дашборды повторяют одни и те же паттерны. Инженеры делают наоборот. Под давлением они пробуют неаккуратные поиски, меняют фильтры, расширяют диапазон и перезапускают варианты, пока что-то не сработает.

Это важно, потому что медленный поиск влияет на payroll ещё до того, как начинает влиять на cloud bill. Олег Сотников в своей работе по observability и инфраструктуре не раз отмечал тот же принцип: если команда не может без трения перейти от окна в один час к окну в семь дней, реагирование на инциденты быстро замедляется.

Что на самом деле разгоняет стоимость хранения

Счёт за логи редко совпадает с чистым объёмом данных, который вы отправляете. Команда может присылать 500 GB в день и потом удивляться, почему месячный счёт выглядит ближе к 800 GB или даже выше. Разница обычно возникает из-за индексов, реплик, быстрых дисков для свежих данных и трафика, который нужен, чтобы перемещать данные между уровнями или системами.

Loki и ClickHouse берут с вас за разные виды overhead, но картина похожа. Вы храните не только само сообщение. Вы также храните metadata, которая делает поиск возможным, копии для надёжности и данные, размещённые на уровнях storage с очень разной ценой.

Главные драйверы стоимости обычно довольно просты:

• индексы и metadata
• реплики для отказоустойчивости
• горячее хранилище на более быстрых дисках
• расходы на чтение и передачу данных, когда люди делают запросы или перемещают старые данные

Именно горячее хранение чаще всего становится местом перерасхода. Большинство инженеров читают логи за последние часы или дни. Они почти никогда не смотрят логи месячной давности, если нет аудита, спора по биллингу или редкого инцидента. Если держать 7–14 дней на горячем storage и остальное переводить в более дешёвое долгосрочное хранилище, расходы часто снижаются без потери истории.

Шум важнее, чем выбор инструмента. Debug logs, дублирующиеся события, health checks и слишком разговорчивые background jobs могут залить систему данными, которые никто не использует. Сокращение шумных логов на 30% часто экономит больше денег, чем смена backend. Команды, которые убирают шум и сокращают горячее хранение, обычно видят снижение счёта ещё до смены чего-либо ещё.

Здесь же важны архитектурные решения. Более быстрый engine не исправляет расточительство. Если приложение пишет пять строк там, где хватило бы одной, и Loki, и ClickHouse становятся дороже. Начните с того, чтобы хранить меньше мусора, держать меньше данных на дорогих дисках и относиться к долгому хранению как к задаче storage design, а не только database design.

Время оператора — часть счёта за observability

Скрытая стоимость этого выбора часто не в storage. Она во времени, которое кто-то тратит на поддержание системы в здоровом состоянии.

Loki сначала обычно выглядит проще. Многие команды быстро поднимают его и сталкиваются с проблемами только позже, когда labels разрастаются без плана. Пара неудачных решений по labels может поднять cardinality, замедлить запросы и сделать регулярную очистку обязательной рутиной. Привычки поиска тоже важны. Если инженеры постоянно запускают широкие запросы по огромным диапазонам, Loki на бумаге может быть дешёвым, а по времени оператора — дорогим.

У ClickHouse другая картина. Он может эффективно хранить логи и быстро отвечать на сложные запросы, но в начале требует больше внимания. Table design, partitions, retention rules, merges, backups и состояние кластера — всё это требует ухода. Если эти решения слабые, база будет постоянно напоминать о себе.

Перед выбором задайте четыре простых вопроса:

• Кто отвечает за систему после запуска?
• Кто занимается обновлениями и сломанными запросами?
• Кто удаляет старые данные и проверяет правила хранения?
• Кому прилетит alert, если упадёт производительность поиска?

Если честный ответ — «тому же загруженному инженеру, у которого и так ещё пять задач», то время оператора важнее сырой цены хранения.

Один лишний час в неделю кажется мелочью. За год это около 50 часов. При ставке $100 в час это $5,000, потраченные на экономию куда меньшей суммы на storage.

Для lean-команд Loki часто выигрывает, если работа с логами проста, а дисциплина в labels строгая. ClickHouse часто выигрывает, если команда может хорошо спроектировать его и поддерживать порядок. Дешевле обычно тот вариант, который команда может обслуживать без постоянного babysitting.

Как выбрать без гадания

Правильный выбор обычно зависит от привычек команды, а не от benchmark charts. Если инженеры в основном ищут логи за последние несколько дней во время инцидентов, а finance или compliance хотят историю за шесть месяцев, то «быстрое» и «дешёвое» хранение решают разные задачи.

Лучше работает простой способ оценки, а не длинный спор.

Сначала измерьте обычный ежедневный ingest, пиковый ingest и реальный срок хранения. Пики важны, потому что шумный deploy или сломанный сервис могут удвоить объём на несколько часов.

Потом запишите, какие поиски люди реально запускают. Во время инцидентов команды часто ищут по service, time range, тексту ошибки, request ID или customer ID. Для support-задач могут понадобиться более широкие поиски по нескольким полям. Если никто не может назвать реальные запросы, команда просто гадает.

Дальше разделите хранение на уровни. Можно держать 14–30 дней на быстром storage для ежедневной работы, а старые логи переносить в максимально дешёвое решение, которое вы готовы терпеть. Одно это решение часто влияет сильнее, чем выбор движка.

После этого назначьте владельца. Кто-то должен отвечать за обновления, сломанный ingest, тюнинг и очистку. Более быстрый на бумаге system всё равно может оказаться дороже, если каждый месяц съедает часы команды.

И наконец, тестируйте на реальных логах. Не на синтетике. Загрузите одну-две недели production-подобных логов и прогоните те же поиски в обеих системах. Замерьте несколько типовых задач: поиск одной ошибки вокруг деплоя, трассировку запроса по сервисам и проверку проблемы клиента за прошлый месяц. Затем посчитайте и время на настройку. Если один вариант экономит несколько секунд на запрос, но требует целый день тюнинга каждый квартал, сделка может быть невыгодной.

Практическое правило простое: выбирайте ту систему, с которой ваша команда сможет спокойно работать в 2 часа ночи. Обычно это и есть более дешёвый вариант за полный год.

Простой пример: один продукт, шесть месяцев логов

Представьте небольшую SaaS-команду с одним продуктом для клиентов. Они хранят application logs, nginx logs и логи фоновых workers в течение 180 дней. Support каждый день проверяет свежие ошибки. Engineering смотрит на последние несколько часов во время инцидентов. Более старые логи почти не трогают, кроме случаев расследования спора по биллингу, редкой ошибки или security-инцидента.

Такой паттерн использования важнее любой страницы продукта. Если команда постоянно читает свежие данные и почти не трогает логи месячной давности, Loki обычно выглядит разумнее. Можно держать свежие логи простыми для запроса, переносить старые данные на более дешёвое хранение и принимать, что старые поиски будут занимать больше времени. Такой trade часто снижает стоимость хранения без ущерба для ежедневной работы.

Теперь измените одну привычку. Допустим, команда несколько раз в неделю запускает широкие поиски по трём-шести месяцам. Product смотрит тренды. Support сравнивает всплески ошибок между релизами. Инженеры ищут старые сбои workers по user ID, endpoint или service name. В таком случае ClickHouse начинает выглядеть лучше. Он спокойнее переносит широкие сканы и повторяющийся исторический анализ, даже если план хранения и повседневный уход требуют больше усилий.

Здесь хорошо работает простое правило:

• Loki подходит для workflow «свежие данные в горячем доступе, старые — потом в архив».
• ClickHouse подходит для workflow «поиск по месяцам — это обычная работа».

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

Привычки команды важнее лозунгов о tool. Посчитайте, как часто люди ищут старые логи, насколько широкие эти поиски и сколько задержки они готовы терпеть. Это скажет больше, чем любой benchmark chart.

Ошибки, из-за которых счёт растёт

Самые большие скачки расходов обычно происходят из-за привычек, а не из-за самой базы данных.

Одна частая ошибка — хранить debug logs вечно. Debug-строки помогают во время инцидента, но их ценность быстро падает. Если команда хранит месяцы шумных retry, многословного вывода приложения и малополезных traces на том же уровне хранения, что и реальные ошибки, storage растёт почти без пользы.

Другая ошибка начинается с добрых намерений. Инженеры добавляют больше полей, чтобы потом было легче искать, и включают request ID, user ID, session tokens, container hashes и другие значения, которые меняются почти в каждой строке. Это делает индексы тяжелее, запросы медленнее и сжатие хуже.

Некоторые паттерны повторяются снова и снова:

• считать все логи горячими данными
• игнорировать медленные запросы и покупать больше вычислений вместо исправления data model
• копировать setup, сделанный для компании в десять раз больше

Горячее хранилище должно держать только свежие логи, которые люди ищут каждый день. Старые данные часто должны уходить в более дешёвый уровень с более медленным доступом, который всё ещё подходит для аудита, compliance или редкого инцидента. Если не разделять эти уровни, счёт будет продолжать расти.

Медленные запросы вызывают вторую волну лишних расходов. Когда поиск начинает тормозить, команды добавляют RAM, CPU и дополнительные nodes. Это какое-то время помогает, но настоящая проблема часто сидит в labels, partitions или шаблонах запросов.

Ошибка со слишком большим стеком особенно часто встречается у стартапов и небольших SaaS-команд. Они заимствуют настройки у компании, которая в разы крупнее, а потом тратят время на латание и тюнинг системы, которая вообще не соответствовала их масштабу.

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

Что делать дальше

Прежде чем выбрать logging stack, задайте один вопрос: какие поиски ваша команда запускает каждую неделю? Реальные примеры быстро показывают ответ. Вам нужен либо быстрый свежий retention, либо дешёвый archive retention, либо их сочетание.

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

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

Короткая проверка обычно находит главные ошибки:

• перечислите пять самых частых запросов
• отметьте, насколько далеко назад обычно уходит каждый из них
• разделите быстрое хранение и дешёвый архив
• оцените ежемесячные часы команды на поддержку
• протестируйте оба варианта на реальном наборе данных

Пробный запуск с 30–60 днями реальных логов скажет больше, чем список функций. Измерьте рост storage, время типовых запросов и то, сколько babysitting требует система.

Если перед тем как расходы на observability превратятся в привычку, вам нужен второй взгляд, Oleg Sotnikov на oleg.is помогает стартапам и небольшим командам пересматривать архитектуру, инфраструктуру и планы хранения. Короткая консультация часто дешевле, чем месяцы перерасхода и болезненная миграция позже.

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