Сбор и обработка логов (ClusterVectorPipeline)

Пайплайны Vector для сбора и агрегации логов кластера.

ClusterVectorPipeline — кастомный ресурс Kubernetes (API observability.kaasops.io), в котором задаётся пайплайн сбора и обработки логов. В кластере создаются преднастроенные ClusterVectorPipeline вместе с установкой модуля локального сбора логов.

На этой странице — таблица преднастроенных пайплайнов, пример spec и рекомендации для пользовательских конфигураций.

Преднастроенные ClusterVectorPipeline #

В кластере по умолчанию развёрнут набор преднастроенных пайплайнов ClusterVectorPipeline, которые собирают основные типы логов. Пайплайны обеспечивают базовое покрытие:

Эти пайплайны покрывают типовые сценарии: аудит Kubernetes, системные события, события приложений и инфраструктурных сервисов.

Обратите внимание! не изменяйте вручную преднастроенные системные ClusterVectorPipeline — это может нарушить сбор, агрегацию и доставку логов.

Архитектура ClusterVectorPipeline #

Спецификация (spec) ресурса ClusterVectorPipeline содержит три базовых блока:

• sources - определяет источники данных;
• transforms - описывает последовательность преобразований и фильтров;
• sinks - задаёт конечные точки для отправки данных (VictoriaLogs, внешние хранилища, SIEM, syslog и т.д.).

Пример пайплайна для логов Kubernetes #

Фрагмент ниже иллюстрирует структуру spec. Имена узлов в вашем кластере смотрите в манифестах ClusterVectorPipeline.

apiVersion: observability.kaasops.io/v1alpha1
kind: ClusterVectorPipeline
metadata:
  name: k8s-logs
  namespace: monitoring
spec:
  # Источник данных - логи Kubernetes
  sources:
    kubernetes_logs:
      type: kubernetes_logs

  # Цепочка трансформаций
  transforms:
    # Разбор поля .message
    message_parser:
      inputs:
        - kubernetes_logs
      source: |
        .message =
          parse_json(.message) ??
          parse_klog(.message) ??
          .message        
      type: remap

    # Фильтрация системных пространств имён
    filter_system_namespaces:
      type: filter
      inputs: [message_parser]
      condition: |
                exists(.kubernetes.namespace_labels."shturval_tech/system-namespace")

    # Фильтрация пользовательских пространств имён
    filter_user_namespaces:
      type: filter
      inputs: [message_parser]
      condition: |
                !exists(.kubernetes.namespace_labels."shturval_tech/system-namespace")

Ключевые преобразования #

В примере выше используются типовые для платформы преобразования:

• message_parser:

  • выполните его разбор если поле .message имеет структуру json или klog;
  • в противном случае оставьте его как есть.

• filter_system_namespaces и filter_user_namespaces:

  • разделяют логи по типу неймспейса;
  • ориентируются на лейбл shturval_tech/system-namespace, которым помечаются системные неймспейсы.

Рекомендации по проектированию пайплайнов #

При создании собственных ClusterVectorPipeline рекомендуется:

• Использовать понятные имена для пайплайнов, отражающие источник или назначение логов.
• Следовать единому стилю именования компонентов (sources, transforms, sinks), чтобы упростить сопровождение.
• Выстраивать логичную цепочку преобразований:
  • нормализация временных меток и полей;
  • фильтрация ненужных данных;
  • подготовка структуры под целевое хранилище.
• Использовать входы (inputs) для явного описания последовательности (какой transform читает данные от какого компонента).
• Фильтровать ненужные данные как можно раньше, чтобы снизить нагрузку на последующие шаги и хранилище.
• Минимизировать количество трансформаций, оставляя только необходимые для ваших сценариев.
• Избегать дублирования обработки данных в нескольких пайплайнах, если можно выразить логику в одном месте.

Созданные вами объекты ClusterVectorPipeline можно просматривать и редактировать через раздел Администрирование → Кастомные ресурсы, выбрав API-группу observability.kaasops.io.

Режим управления модулем (Авто / Ручной) #

Для штатной установки модуля и добавления получателей логов через ShturvalServicePatch используйте режим Авто. В этом режиме применяется поставляемая с чартом конфигурация, а пользовательские изменения в customvalues накладываются через SSP.

Режим Ручной нужен, если вы создаёте ClusterVectorPipeline вручную и хотите, чтобы эти изменения не перезаписывались базовой конфигурацией. Подробнее — в описании сервиса shturval-log-collector.