VictoriaLogs vs Loki vs Elasticsearch

Привет, Хабр! Меня зовут Юра Пачковский, я DevOps-инженер платформы контейнеризации dBrain.cloud. Это я рассказывал вам об устройстве нашей системы мониторинга тут, тут и тут. В этой статье мы постараемся разобрать плюсы и минусы VictoriaLogs как решения для логирования в облачной платформе dBrain.cloud.

Структура статьи примерно такая, выбирайте разделы по душе:

• Какие технологии опробовали

• Сравнение ресурсов

• Пример настройки

• Так почему все-таки VictoriaLogs?

• Личный опыт использования

Если нужны факты и мнение, пролистывайте пункт «Размышления» 🙂

Размышления

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

Логгинг необходим в первую очередь для того, чтобы понять, что пошло не по плану, когда приложение «встало» — как в реальном времени, так и после того, как инцидент уже завершился. Наша задача — восстановить полный флоу событий, чтобы выявить первопричину сбоя и разработать механизм его предотвращения. Для примера возьмем вымышленную ситуацию, когда один из подзапросов к базе падает по пермишенам.

Что мы видим без разбора логов в этой ситуации? С одной стороны, в зависимости от реализации бэкенда, фронтенд может получать коды статуса 500 или 400. Это абсолютно не проясняет картину, особенно если инцидент не связан с многочисленными запросами, а RUM (Real User Monitoring) на стороне клиента не реализован. Добиться внятного описания от клиентской части — настоящая боль для любой команды. В такой ситуации мы оказываемся в тупике: остается только вручную перебирать сервисы по цепочке (а их могут быть десятки, если не сотни) и надеяться, что запись нужного лога не потеряется на фоне остальных. Это крайне печально, поскольку мы вылетаем за рамки SLA и портим впечатление клиента о себе.

С другой стороны, при наличии полноценной системы логирования достаточно одного запроса с фильтрами, чтобы оперативно вывести все логи уровней “warn”, “error”, “critical” и “panic” от интересующих нас сервисов в цепочке. Найти подозрительную запись, которая могла привести к такой ситуации, не составит труда.

Какие технологии опробовали

Итак, с необходимостью системы логирования разобрались. Теперь главный вопрос: какие решения существуют, чтобы и работать было удобно, и внедрить у себя несложно. Мы протестировали Elasticsearch, Loki и VictoriaLogs. Сразу скажем: у каждого из них есть свои плюсы и минусы. Вот мнение автора на этот счет:

• Если хостов немного (условно, до 30) — берем Elastic или VictoriaLogs single instance.

• Если нужно горизонтальное масштабирование — однозначно VictoriaLogs.

• Если хочется «пострадать» с оверинжинирингом — выбираем Loki.

Сравнение ресурсов

Приведем несколько сравнений из открытых источников:

VictoriaLogs vs Loki

VictoriaLogs vs Elasticsearch

Если сравнивать с Loki, то VictoriaLogs — безоговорочный победитель. Когда речь идет об Elastic, ситуация сложнее из-за возможной уже существующей аналитики. Но если мы смотрим на чистый перфоманс, то VictoriaLogs с огромным запасом обходит оба решения.

Пример настройки

Теперь что касается настройки. VictoriaLogs может поставляться как в формате single-instance — «всё в одном», так и в микросервисном варианте, рассчитанном на масштабирование и highload-нагрузки.

Мы будем рассматривать именно микросервисный сценарий, поскольку single-instance практически не требует тюнинга или внесения изменений в конфиги — дефолтная поставка из коробки отлично справляется со своими задачами.

После выбора микросервисной архитектуры у нас есть два пути: либо заниматься тонкой настройкой всех необходимых Deployment, StatefulSet, ConfigMap и прав вручную, либо использовать оператор VictoriaMetrics, который на текущий момент уже поддерживает VictoriaLogs. В качестве бонуса оператор также упрощает настройку всего стека VictoriaMetrics.

Сначала устанавливаем сам оператор в кластер, а дальше начинается магия — вся конфигурация описывается через CRD.

Ниже пример CRD, который развернет VLCluster.

apiVersion: v1items:- apiVersion: operator.victoriametrics.com/v1 kind: VLCluster metadata:   annotations:   name: dbrain   namespace: mon spec:   clusterDomainName: cluster.local   managedMetadata:     labels:       component: vlogs   requestsLoadBalancer:     enabled: true     spec:       affinity:         image:           repository: victoria-vmauth           tag: image       replicaCount: 2   vlinsert:     extraArgs:       insert.maxLineSizeBytes: "524288"       memory.allowedPercent: "80"     image:       pullPolicy: IfNotPresent       repository: victoria-logs       tag: version     logLevel: INFO     podMetadata:       labels:         app: vlinsert         stack: logging     replicaCount: 3     revisionHistoryLimitCount: 1   vlselect:     extraArgs:       memory.allowedPercent: "80"     image:       pullPolicy: IfNotPresent       repository: infra/victoria-logs       tag: version     logLevel: INFO     podMetadata:       labels:         app: vlselect         stack: logging     replicaCount: 3     revisionHistoryLimitCount: 1   vlstorage:     extraArgs:       memory.allowedPercent: "80"       retention.maxDiskSpaceUsageBytes: 900GiB     image:       pullPolicy: IfNotPresent       repository: infra/victoria-logs       tag: version     logLevel: INFO     podMetadata:       labels:         app: vlstorage         stack: logging     replicaCount: 2     retentionPeriod: 30d     revisionHistoryLimitCount: 1     storage:       volumeClaimTemplate:         metadata:           name: data-vlogs         spec:           resources:             requests:               storage: 1Ti           storageClassName: csi-cephfs-hdd

Эта CRD через оператора поднимет полностью работоспособный кластер VictoriaLogs. Сразу отмечу, что пример приведен скорее в ознакомительных целях — в реальной эксплуатации стоит детальней описать ресурсы, tolerations и прочие параметры инфраструктуры.

Далее остается разрулить доступы через VMAuth и VMUser — для мультитенантности, разграничения прав и подключения Grafana. После этого можно считать, что система готова к полноценной эксплуатации. Поздравляю — вы восхитительны.

Отдельным видом искусства стоит отметить документацию VictoriaMetrics и то, насколько подробно у них описаны API. Это действительно сильно упрощает жизнь и открывает возможности для весьма интересных интеграций.

Например, для любителей AI — отличный пример интеграции VictoriaLogs с AI-агентом. На текущий момент уже реализованы mcp сервера для метрик, логов, трейсов.

Так почему все-таки VictoriaLogs?

Если после всего написанного выше у вас все еще остался этот вопрос — боюсь, никакие дополнительные аргументы уже не помогут. Мир вам, но все же попробуем.

• Выше производительность.

• Меньше потребление дискового пространства.

• Нормальное горизонтальное масштабирование.

• Простота настройки, сопровождения и поддержки.

Личный опыт эксплуатации

Автор рекомендует. На практике — более 500 серверов, терабайты данных и всё это сопровождается силами одного человека.

Отдельно стоит отметить, что выбор агента для сбора логов — это вообще отдельная философская дискуссия. VL Agent автором пока не тестировался, поскольку уже давно и плотно используется Vector, который полностью закрывает все текущие задачи.

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