При выборе бэкэнда для хранения логов можно купиться на один красивый показатель и не разглядеть за ним остальные характеристики. Высокая скорость записи ещё не означает быстрый поиск, а хорошее сжатие данных — эффективную эксплуатацию.
Команда VictoriaMetrics провела сравнительное тестирование шести решений:
🚀 VictoriaLogs 1.53.0
🚀 Grafana Loki 3.7.8
🚀 Elasticsearch 9.5.5
🚀 OpenSearch 3.9.0
🚀 SigNoz 0.145.0
🚀 ClickStack 2.39.1
В качестве нагрузки использовались структурированные логи Kubernetes: 30–40 полей в каждой записи и 5000 отдельных потоков. Все системы запускались по одной на одинаковых узлах с 8 vCPU и 32 ГБ RAM. Нагрузка постепенно увеличивалась с 10 до 180 тысяч строк в секунду, а основной тест повторялся три раза.
Результаты приема получились следующими:
Loki показал максимальную скорость приёма — 139 тысяч строк в секунду;
VictoriaLogs занял второе место с результатом 120 тысяч строк в секунду;
Elasticsearch, OpenSearch и ClickStack остановились в диапазоне примерно от 28 до 48 тысяч;
SigNoz справился с 10 тысячами строк в секунду, но при дальнейшем увеличении нагрузки его скорость приема начала падать.
Кроме скорости ingest в статье также сравнивается использование CPU и RAM, итоговый размер данных, объём записи на диск и время выполнения нескольких запросов.
И здесь всплывают интересные детали. Loki принимает данные очень быстро, поскольку индексирует в основном метки потоков, а не каждое поле записи. Но за это приходится платить во время чтения: некоторые запросы по тестовому набору выполнялись десятки секунд или несколько минут. Кроме того, потребление памяти Loki заметно росло вместе с количеством потоков.
Elasticsearch выбрал противоположный путь: он строит подробные индексы и поэтому быстро находит отдельные слова и значения. Цена такого подхода — более тяжёлый ingest, высокий расход CPU и памяти, а также почти в пять раз больше дискового пространства по сравнению с VictoriaLogs. У OpenSearch в тестовой конфигурации разница оказалась ещё больше — примерно в десять раз.
VictoriaLogs пытается занять промежуточную позицию: хранит поля структурированных сообщений по колонкам, использует лёгкие индексы и читает только те поля, которые нужны конкретному запросу. По результатам авторов это позволило получить высокую скорость записи, небольшой расход памяти и диска, а также выполнение большинства запросов за секунды.
Отдельно разобраны SigNoz и ClickStack. Оба используют ClickHouse, но перед ним работает OpenTelemetry Collector. В тесте именно коллектор потреблял значительную часть процессорных ресурсов и становился одним из ограничений производительности. При этом авторы (к их чести) отмечают, что это полноценные observability-стеки, объединяющие логи, метрики и трейсы, поэтому оценивать их исключительно по скорости записи логов не совсем корректно.
Кластерный режим, объектное хранилище (которое пока что не завезли в VictoriaLogs) и полноценное тестирование запросов авторы планируют разобрать отдельно.
Статья показывает, почему нельзя выбирать систему хранения логов только по одному показателю: где-то мы экономим ресурсы при записи, но платим при поиске; где-то получаем быстрые запросы ценой больших индексов; а где-то дополнительные возможности observability требуют дополнительных компонентов.
В общем, если вы в поисках бэкэнда — присмотритесь.
Читать статью в блоге VictoriaMetrics
✅ Telegram | ✅ MAX