Модуль log-shipper

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

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

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

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

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

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

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

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

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

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

Потоковая

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

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

Метаданные

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

Kubernetes

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

File

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

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

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

Они запускаются сразу после объединения строк при помощи 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.

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