Доступно в редакциях: CE, BE, SE, SE+, EE, CSE Lite (1.64), CSE Pro (1.64)
Модуль разворачивает агенты log-shipper
для сборки логов на узлы кластера.
Предназначение этих агентов — с минимальными изменениями отправить логи дальше из кластера.
Каждый агент — это отдельный vector, конфигурацию для которого сгенерировал Deckhouse.
- Deckhouse следит за ресурсами ClusterLoggingConfig, ClusterLogDestination и PodLoggingConfig.
Комбинация конфигурации для сбора логов и направления для отправки называется
pipeline
. - Deckhouse генерирует конфигурационный файл и сохраняет его в
Secret
в Kubernetes. Secret
монтируется всем подам агентовlog-shipper
, конфигурация обновляется при ее изменении с помощью sidecar-контейнераreloader
.
Топологии отправки
Этот модуль отвечает за агентов на каждом узле. Подразумевается, что логи из кластера отправляются согласно одной из описанных ниже топологий.
Распределенная
Агенты шлют логи напрямую в хранилище, например в Loki или Elasticsearch.
- Менее сложная схема для использования.
- Доступна из коробки без лишних зависимостей, кроме хранилища.
- Сложные трансформации потребляют больше ресурсов на узлах для приложений.
Централизованная
Все логи отсылаются в один из доступных агрегаторов, например, Logstash, Vector. Агенты на узлах стараются отправить логи с узла максимально быстро с минимальным потреблением ресурсов. Сложные преобразования применяются на стороне агрегатора.
- Меньшеe потребление ресурсов для приложений на узлах.
- Пользователи могут настроить в агрегаторе любые трансформации и слать логи в гораздо большее количество хранилищ.
- Количество выделенных узлов под агрегаторы может увеличиваться или уменьшаться в зависимости от нагрузки.
Потоковая
Главная задача этой архитектуры — как можно быстрее отправить логи в очередь сообщений, из которой они в служебном порядке будут переданы в долгосрочное хранилище для дальнейшего анализа.
- Те же плюсы и минусы, что и у централизованной архитектуры, но добавляется еще одно промежуточное хранилище.
- Повышенная надежность. Подходит тем, для кого доставка логов является наиболее критичной.
Метаданные
При сборе логов сообщения будут обогащены метаданными в зависимости от способа их сбора. Обогащение происходит на этапе 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
.
Они запускаются сразу после объединения строк с помощью multiline parser.
label filter
— правила запускаются для метаданных сообщения. Поля для метаданных (или лейблов) наполняются на основании источника логов, и для разных источников будет разный набор полей. Эти правила необходимы, например, чтобы отбросить сообщения от определенного контейнера или пода с/без какой-то метки.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
, поэтому невозможно фильтровать логи на их основании.