Описание

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

log-shipper architecture

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

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

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

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

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

log-shipper distributed

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

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

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

log-shipper centralized

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

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

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

log-shipper pipeline

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

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

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

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

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

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