Сравнение VictoriaLogs, Loki и Elasticsearch на приёме логов Kubernetes
VictoriaMetrics опубликовала открытый бенчмарк приёма логов: шесть систем хранения логов — VictoriaLogs, Grafana Loki, Elasticsearch, OpenSearch, SigNoz и ClickStack — принимали один и тот же поток структурированных логов Kubernetes на одинаковом железе. Тест сравнивает скорость записи, расход CPU и памяти, место на диске и время ответа на типовые запросы.
Краткий ответ
В тесте VictoriaMetrics Loki принял больше всего строк в секунду — 139 тысяч, VictoriaLogs занял второе место с 120 тысячами, Elasticsearch, OpenSearch и ClickStack остановились на 28-48 тысячах, а SigNoz упал уже на 20 тысячах. Скорость записи не говорит о скорости поиска: часть запросов к Loki заняла минуты, а Elasticsearch и OpenSearch платят за быстрый поиск диском и CPU на записи.
Что тестировали
Каждая система работала в одиночном режиме на своей ноде n2d-standard-8 в GCP: 8 vCPU, 32 ГБ RAM. Нагрузку поднимали с 10 до 180 тысяч строк в секунду шагами по 10 тысяч каждые 10 минут. Лог — структурированная строка с 30-40 полями, типичная для Kubernetes; сценарий описывает кластер из 125 узлов по 40 подов, что даёт 5000 отдельных потоков логов.
Каждая система получала логи в привычном для неё формате: Loki — protobuf, остальные — в своих обычных протоколах, чтобы тест не измерял заодно скорость конвертации форматов. Для SigNoz и ClickStack, которые хранят логи в ClickHouse, перед базой запускали OpenTelemetry Collector: сама ClickHouse логи напрямую не принимает.
Кто сколько принял логов и какой ценой
При 40 тысячах строк в секунду VictoriaLogs и Loki использовали по 1,6 ядра CPU против 5,2 ядра у Elasticsearch. По памяти VictoriaLogs держался экономнее всех на любой скорости: при 40 тысячах строк в секунду в 14 раз меньше, чем Loki. Elasticsearch и OpenSearch резервируют фиксированную кучу памяти при старте — около 17 ГБ независимо от нагрузки.
По месту на диске VictoriaLogs потребовал меньше всех, Elasticsearch — почти в 5 раз больше, OpenSearch — в 10 раз больше. В пересчёте на 30 дней хранения при 50 тысячах строк в секунду это около 7 ТБ у VictoriaLogs против 12 ТБ у Loki и 33 ТБ у Elasticsearch, по расчётам авторов бенчмарка.
Почему Loki быстрый на записи и медленный на поиске
Loki индексирует только метки потоков, не вникая в содержимое строк, поэтому запись дешёвая по CPU. Цена — поиск: любой запрос по словам или значениям внутри строки требует сканировать весь поток целиком. В тесте подсчёт ошибок по всем приложениям занял у VictoriaLogs 0,59 секунды против 171 секунды у Loki.
Память Loki растёт вместе с числом потоков, потому что он держит свежие строки каждого потока в памяти, чтобы сжать их вместе. При сценарии с 15 тысячами потоков Loki упал по памяти уже на 60 тысячах строк в секунду, тогда как VictoriaLogs при трёхкратном росте числа потоков прибавил в весе всего 0,2 ГБ памяти.
Где теряют время Elasticsearch, OpenSearch и связка SigNoz/ClickStack
Elasticsearch и OpenSearch строят полный инвертированный индекс по каждому слову каждой строки, поэтому находят отдельные значения почти мгновенно. Плата — CPU и диск на записи. SigNoz и ClickStack упираются не в саму ClickHouse, а в OpenTelemetry Collector перед ней: в тесте коллектор потреблял больше ресурсов, чем база, и стал узким местом — у SigNoz он же привёл к падению сервиса уже на 20 тысячах строк в секунду.
Почему это важно
Выбор бэкенда для логов Kubernetes — это баланс между стоимостью записи, объёмом диска и скоростью расследования инцидентов. Бенчмарк даёт платформенным и SRE-командам конкретные цифры для расчёта железа под объём логов и SLA по времени ответа на запросы. Платформенные команды получают воспроизводимый ориентир по ресурсам — методика и данные выложены в открытом репозитории, который можно запустить самостоятельно, но тест готовила сама VictoriaMetrics, чья система тоже участвует в сравнении.
Что дальше
VictoriaMetrics анонсировала продолжение серии: отдельные посты про скорость самих запросов, про кластерный режим и про поддержку объектного хранилища, которую VictoriaLogs пока не реализовала. Командам, которые выбирают бэкенд для логов Kubernetes, стоит прогнать репозиторий бенчмарка на своих объёмах и форматах логов, прежде чем принимать решение по железу.
FAQ
Какую нагрузку использовали в бенчмарке VictoriaMetrics?
Структурированные логи Kubernetes с 30-40 полями в строке, 5000 потоков логов, нагрузка от 10 до 180 тысяч строк в секунду на одной ноде 8 vCPU / 32 ГБ RAM для каждой системы.
Почему Loki принял больше строк в секунду, чем VictoriaLogs?
Loki индексирует только метки потоков, а не поля внутри строк, поэтому запись дешевле по CPU. Цена — медленные запросы, которые требуют сканировать все строки потока целиком.
Почему Elasticsearch и OpenSearch занимают больше места на диске?
Обе системы строят полный индекс по каждому слову для быстрого поиска. По данным бенчмарка, в тесте Elasticsearch использовал компактный режим LogsDB, а у OpenSearch такого режима нет, поэтому он сжимает исходный JSON менее плотно.
Почему SigNoz и ClickStack отстали от скорости ClickHouse?
ClickHouse не умеет принимать логи напрямую в их обычных форматах, поэтому перед базой работает OpenTelemetry Collector. В тесте именно коллектор съедал основную часть CPU и стал ограничением скорости приёма.
Где посмотреть полные результаты и повторить тест?
VictoriaMetrics выложила методику и данные в открытом репозитории бенчмарка, который можно запустить самостоятельно и свериться с результатами на своих логах.