Привет, Хабр! Меня зовут Юра Пачковский, я 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: v1
items:
- 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 или вы только присматриваетесь к нему — делитесь своим мнением, кейсами и набитыми шишками в комментариях. Всегда интересно посмотреть, как одни и те же задачи решаются у разных людей и в разных инфраструктурах.