Сбор и доставка логов

Этот раздел содержит описание работы компонентов системы логирования Deckhouse Virtualization Platform (DVP).

Механизм сбора и доставки логов

Для сбора и доставки логов в DVP используется модуль log-shipper. На каждом узле кластера запускается отдельный экземпляр log-shipper, который настраивается на основе ресурсов Deckhouse. Модуль log-shipper использует Vector в качестве агента логирования. Комбинация настроек для сбора и доставки логов образует pipeline.

1. Deckhouse отслеживает ресурсы ClusterLoggingConfig, ClusterLogDestination и PodLoggingConfig:

   • ClusterLoggingConfig — описывает источник логов на уровне кластера, включая правила сбора, фильтрации и парсинга;
   • PodLoggingConfig — описывает источник логов в рамках заданного пространства имён, включая правила сбора, фильтрации и парсинга;
   • ClusterLogDestination — задаёт параметры хранилища логов.
2. На основе заданных параметров Deckhouse автоматически создаёт конфигурационный файл и сохраняет его в Secret в Kubernetes.
3. Secret монтируется на все поды агентов log-shipper. При изменении конфигурации обновление происходит автоматически с помощью сайдкар-контейнера reloader.

Схемы доставки логов

В DVP поддерживаются различные топологии доставки логов в зависимости от требований к надёжности и потреблению ресурсов.

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

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

Преимущества:

• простая настройка;
• доступна «из коробки» без дополнительных зависимостей, кроме хранилища.

Недостатки:

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

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

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

Преимущества:

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

Недостатки:

• требует выделенных узлов под агрегаторы. Их количество может увеличиваться в зависимости от нагрузки.

Потоковая

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

Преимущества:

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

Недостатки:

• добавляет промежуточное звено (очередь сообщений);
• требует выделенных узлов под агрегаторы. Их количество может увеличиваться в зависимости от нагрузки.

Обработка логов

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

Перед отправкой логов DVP может отфильтровывать ненужные записи, чтобы снизить количество сообщений, отправляемых в хранилище. Для этого задействуются фильтры labelFilter и logFilter модуля log-shipper.

Фильтры запускаются сразу после объединения строк с помощью multiline-парсинга.

• labelFilter:
  • правила применяются к метаданным сообщений;
  • поля для метаданных (или лейблов) наполняются на основании источника логов, поэтому для разных источников будет разный набор полей;
  • правила используются, например, чтобы исключить сообщения из определенного контейнера или пода, соответствующих заданной метке.
• logFilter:
  • правила применяются к исходному сообщению;
  • позволяет исключить сообщение на основании значения JSON-поля;
  • если сообщение не в формате JSON, можно использовать регулярное выражение для поиска по строке.

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

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

Метаданные

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

Kubernetes

При сборе логов из подов и узлов 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

File

При сборе логов из файловых источников доступен только лейбл host, который содержит hostname сервера, с которого поступил лог.