Доступно в редакциях:  CE, BE, SE, SE+, EE, CSE Lite (1.64), CSE Pro (1.64)

Модуль разворачивает агенты log-shipper для сборки логов на узлы кластера. Предназначение этих агентов — с минимальными изменениями отправить логи дальше из кластера. Каждый агент — это отдельный vector, конфигурацию для которого сгенерировал Deckhouse.

log-shipper architecture

  1. Deckhouse следит за ресурсами ClusterLoggingConfig, ClusterLogDestination и PodLoggingConfig. Комбинация конфигурации для сбора логов и направления для отправки называется pipeline.
  2. Deckhouse генерирует конфигурационный файл и сохраняет его в Secret в Kubernetes.
  3. Secret монтируется всем подам агентов log-shipper, конфигурация обновляется при ее изменении с помощью sidecar-контейнера reloader.

Топологии отправки

Этот модуль отвечает за агентов на каждом узле. Подразумевается, что логи из кластера отправляются согласно одной из описанных ниже топологий.

Распределенная

Агенты шлют логи напрямую в хранилище, например в Loki или Elasticsearch.

log-shipper distributed

  • Менее сложная схема для использования.
  • Доступна из коробки без лишних зависимостей, кроме хранилища.
  • Сложные трансформации потребляют больше ресурсов на узлах для приложений.

Централизованная

Все логи отсылаются в один из доступных агрегаторов, например, Logstash, Vector. Агенты на узлах стараются отправить логи с узла максимально быстро с минимальным потреблением ресурсов. Сложные преобразования применяются на стороне агрегатора.

log-shipper centralized

  • Меньшеe потребление ресурсов для приложений на узлах.
  • Пользователи могут настроить в агрегаторе любые трансформации и слать логи в гораздо большее количество хранилищ.
  • Количество выделенных узлов под агрегаторы может увеличиваться или уменьшаться в зависимости от нагрузки.

Потоковая

Главная задача этой архитектуры — как можно быстрее отправить логи в очередь сообщений, из которой они в служебном порядке будут переданы в долгосрочное хранилище для дальнейшего анализа.

log-shipper stream

  • Те же плюсы и минусы, что и у централизованной архитектуры, но добавляется еще одно промежуточное хранилище.
  • Повышенная надежность. Подходит тем, для кого доставка логов является наиболее критичной.

Метаданные

При сборе логов сообщения будут обогащены метаданными в зависимости от способа их сбора. Обогащение происходит на этапе Source.

Kubernetes

Следующие поля будут экспортированы:

Label Pod spec path
pod metadata.name
namespace metadata.namespace
pod_labels metadata.labels
pod_ip status.podIP
image spec.containers[].image
container spec.containers[].name
node spec.nodeName
pod_owner metadata.ownerRef[0]
Label Node spec path
node_group metadata.labels[].node.deckhouse.io/group

Для Splunk поля pod_labels не экспортируются, потому что это вложенный объект, который не поддерживается в Splunk.

File

Лейбл host - это единственный лейбл, в котором записан hostname сервера.

Фильтры сообщений

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

log-shipper pipeline

Они запускаются сразу после объединения строк с помощью multiline parser.

  1. label filter — правила запускаются для метаданных сообщения. Поля для метаданных (или лейблов) наполняются на основании источника логов, и для разных источников будет разный набор полей. Эти правила необходимы, например, чтобы отбросить сообщения от определенного контейнера или пода с/без какой-то метки.
  2. log filter — правила запускаются для исходного сообщения. Существует возможность отбрасывать сообщение на основе поля JSON или, если сообщение не имеет формата JSON, использовать регулярное выражение для поиска в строке.

Оба фильтра имеют одинаковую структурированную конфигурацию:

  • field — источник данных для запуска фильтрации (чаще всего это значение лейбла или параметра из JSON-документа).
  • operator — действие для сравнения, доступные варианты — In, NotIn, Regex, NotRegex, Exists, DoesNotExist.
  • values — определяет разные значения для разных операторов:
    • DoesNotExist, Exists — не поддерживается;
    • In, NotIn — значение поля должно равняться или не равняться одному из значений в списке values;
    • Regex, NotRegex — значение должно подходить хотя бы под одно или не подходить ни под одно регулярное выражение из списка values.

Найти больше примеров можно в разделе Примеры документации.

Extra labels добавляются на этапе Destination, поэтому невозможно фильтровать логи на их основании.