Как настроить буферы сбора логов

Буферы агента Vector и отправка в хранилище платформы.

Агент shturval-log-collector на каждом узле перед отправкой логов в платформу записывает их в свой дисковый буфер Vector. Также логи хранятся в каталоге контейнерных логов на диске узла и в VictoriaLogs.

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

• приёмникЭкземпляр VictoriaLogs в кластере управления, которому агент Vector отдаёт логи после буфера на хранение. недоступен и буфер уже заполнен;
• после восстановления VictoriaLogs накопленные логи с нескольких узлов приходят одновременно и перегружают VictoriaLogs;
• нужен буфер больше, чем 256 МиБ на одного получателяОдин из пяти получателей логов платформы (platform sinks): auditd, journald, k8s_audit, k8s_events или k8s_logs. У каждого свой дисковый буфер.. Перед этим на узле ограничьте каталог /var/lib/vector: выделите ему отдельный раздел диска или задайте дисковую квоту, чтобы буфер большего размера не занял весь диск узла.

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

Параметры buffer #

По умолчанию настроены параметры для каждого буфера всех получателей (sinks): auditd, journald, k8s_audit, k8s_events или k8s_logs:

Сумма пяти буферов по умолчанию около 1,25 ГиБ на узел. В /var/lib/vector должно быть свободно не меньше 1,25 ГиБ. Отдельного срока хранения у буфера нет. Агент удаляет фрагмент буфера после того, как полностью отправил его в приёмник. Запись на диск идёт примерно каждые 500 мс. Если записать буфер на диск не удалось, процесс в Vector останавливается.

Увеличивайте buffer.max_size, только когда /var/lib/vector уже вынесен на отдельный раздел или квоту. Иначе больший буфер быстрее занимает диск узла.

Полный список параметров в модели буферизации Vector.

Если буфер заполнен #

По умолчанию источник внутренних метрик (spec.agent.internalMetrics ресурса Vector) выключен. При включении источника можно определить заполненность по метрикам буфера:

Без этих метрик степень заполнения буфера можно определить по диску узла: каталоги /var/lib/vector и /var/log/pods.

Режим when_full можно задать отдельно для каждого получателя. Чтобы изменить режим when_full у одного объекта buffer, выполните:

1. Подготовьте манифест ShturvalServicePatch для shturval-log-collector. Модуль должен быть в режиме Авто. В режиме Ручной SSP может не примениться. Разница режимов — на странице Сбор и обработка логов (ClusterVectorPipeline).
2. Загрузите манифест в кластере, где работает модуль, через импорт манифестов: Администрирование → Действия с кластером.
3. Дождитесь применения. На странице модуля локального сбора логов статус сервиса сменится на Patched, а SSP появится на вкладке Применённые ShturvalServicePatch.

Пример ShturvalServicePatch c режимом block #

По умолчанию установлен режим block. При block sink ждёт место в буфере и передаёт обратное давление в source. Новые события не отбрасываются. Пока буфер полон, цикл чтения kubernetes_logs не доходит до закрытия уже удалённых файлов. kubelet удаляет ротированный файл, а агент всё ещё держит его открытым и не доходит до закрытия. Место на диске узла не освобождается. Если каталог /var/log/pods не ограничен, заполняется диск узла: контейнеры не могут писать файлы, новые поды не запускаются. У четырёх остальных получателей полный буфер тоже останавливает чтение своего источника, но каталог /var/log/pods заполняет именно сбор логов контейнеров.

Чтобы снова сохранять события после drop_newest, верните block. Пример для k8s_logs. Для auditd, journald, k8s_audit и k8s_events задаётся так же, внутри своего platform_logs_sink.

apiVersion: ops.shturval.tech/v1beta2
kind: ShturvalServicePatch
metadata:
  name: shturval-log-collector-buffer-block
spec:
  shturvalServiceConfigName: shturval-log-collector
  customvalues:
    shturval:
      k8s_logs:
        platform_logs_sink:
          buffer:
            when_full: block

Пока буфер в режиме block полон, пауза в 60 секунд не начинается. Агент закроет удалённый файл, только когда в буфере появится место или процесс Vector завершится.

Пример ShturvalServicePatch c режимом drop_newest #

Включайте drop_newest только у тех получателей, для которых потеря новых событий допустима. Пока буфер полностью заполнен, агент отбрасывает новое событие и продолжает читать источник. Для логов контейнеров удалённый файл закрывается после паузы в 60 секунд, и место на диске узла освобождается. Логи, не попавшие в буфер, в хранилище платформы не появятся.

Пример ShturvalServicePatch с drop_newest для всех получателей.

apiVersion: ops.shturval.tech/v1beta2
kind: ShturvalServicePatch
metadata:
  name: shturval-log-collector-buffer-drop-newest
spec:
  shturvalServiceConfigName: shturval-log-collector
  customvalues:
    shturval:
      auditd:
        platform_logs_sink:
          buffer:
            when_full: drop_newest
      journald:
        platform_logs_sink:
          buffer:
            when_full: drop_newest
      k8s_audit:
        platform_logs_sink:
          buffer:
            when_full: drop_newest
      k8s_events:
        platform_logs_sink:
          buffer:
            when_full: drop_newest
      k8s_logs:
        platform_logs_sink:
          buffer:
            when_full: drop_newest

Отброшенные события отображаются в метрике Vector vector_buffer_discarded_events_total, если у агента включены внутренние метрики.

Параллельность запросов #

По умолчанию для всех sinks число одновременных запросов подстраивается под ответы - request.concurrency: adaptive. Когда адаптация конкретному sink не подходит, вы можете ее изменить через применение SSP для shturval-log-collector. Лимит одновременных HTTP-запросов к sink начинается с меньшего значения. При успешных запросах без роста задержки ответов лимит увеличивается. При отказе sink из-за нагрузки, например, HTTP 429, или при заметном росте задержки лимит снижается, но не устанавливается ниже 1.

После восстановления sink сразу же не применяется заранее заданный максимум параллельных запросов. Накопленные события уходят постепенно. При простое sinks диск не освобождается: буфер заполняется до max_size, дальше действует политика режима when_full.

Фиксированное число, например, request.concurrency: 10, отключает адаптацию у этого sink.

По умолчанию request.rate_limit_duration_secs и request.rate_limit_num не заданы. Окно и число запросов в нём задают частоту HTTP-запросов sink, отдельно от числа одновременных запросов. По документации HTTP-sink Vector этот предел действует и при concurrency: adaptive, и при фиксированном числе. Пример из документации: окно 1 секунда и 10 запросов, то есть не больше 10 запросов в секунду.

Как проверить диск узла, включить project quota и согласовать ротацию kubelet, описано в разделе Логи контейнеров заполняют диск узла.