Логирование в Kubernetes: сбор, хранение, обработка и парсинг логов

Логирование – это процесс сбора, записи и хранения данных о различных событиях, действиях и состоянии системы или приложения в определенном формате. Данный процесс относится к такому свойству распределенных систем, как наблюдаемость или observability.

^{Источник изображения: thealgorists.com}

Данные, которые собираются в процессе логирования, могут включать в себя:

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

В Kubernetes логирование – это процесс сбора, управления и анализа логов, сгенерированных контейнерами приложения и компонентами Kubernetes для выполнения мониторинга, отладки и обнаружения проблем в среде кластера.

В данной инструкции мы рассмотрим процесс логирования в среде Kubernetes, начиная от ее архитектуры и заканчивая инструментами для обработки логов.

Архитектура логирования в Kubernetes

В данном разделе инструкции мы рассмотрим архитектуру сбора логов в Kubernetes.

Ниже будут приведены основные уровни сбора логов:

• Сбор логов на уровне подов.

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

^{Источник изображения: kubernetes.io}

На картинке выше изображен процесс логирования на уровне контейнеров пода. Здесь некоторый контейнер app-container пода my-pod отправляет логи в стандартные потоки stdout и stderr контейнеризированного приложения, где stdout – это поток вывода, а stderr – ошибок. Агент kubelet, подключенный к среде выполнения контейнера с помощью CRI, отвечает за обработку и контроль логов, собранных контейнером. 

Чтобы посмотреть логи пода в Kubernetes, необходимо воспользоваться следующей командой:

kubectl logs название_пода

Кроме того, вы можете столкнуться с ситуацией, когда внутри вашего пода развернуто несколько контейнеров, а логи нужны только от одного из них. Для этого к предыдущей команде необходимо добавить специальный флаг и имя контейнера:

kubectl logs название_пода -c название_контейнера

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

Если на рабочих узлах установлена systemd, то kubelet записывает системные логи в journald, а для их чтения используется команда:

journalctl -u kubelet

Если на узле отсутствует systemd, то запись логов будет осуществляться в log-файлы в каталог /var/log.

• Сбор логов на уровне кластера.

В K8s отсутствует встроенная возможность ведения журнала на уровне кластера. Для ее реализации пользователи используют разные подходы. Ниже приведем два самых распространенных способа обработки логов:

• • Использование агента ведения журналов (logging-agent) на уровне узла.

^{Источник изображения: kubernetes.io}

Один из способов сбора и обработки логов в Kubernetes на уровне кластера — это использование агента ведения журналов на уровне узла. Этот агент (например, Fluentd или Logstash) является компонентом, работающим на каждом узле кластера. Он отвечает за сбор, обработку и отправку логов агрегатору. Его интеграция происходит за счет объекта DaemonSet, который добавляет копию агента на каждый рабочий узел кластера.

• • Использование дополнительного контейнера sidecar на уровне пода или узла.

Sidecar — это дополнительный контейнер, который работает вместе с основным контейнером в одном поде или на одном узле. Правильно настроенный sidecar-контейнер собирает логи из файла, сокета или journald, а затем передает их в собственные потоки stdout или stderr.

^{Источник изображения: kubernetes.io}

Для сбора логов разных форматов рекомендуется настраивать несколько sidecar-контейнеров. В таком случае каждый из них будет перенаправлять логи из общего тома в свой поток stdout.

Чтобы посмотреть на собранные логи, можно воспользоваться уже знакомой командой:

kubectl logs название_пода  название_sidecar-контейнера

Инструменты логирования Kubernetes

В данном разделе инструкции мы рассмотрим некоторые популярные инструменты с открытым исходным кодом, которые подойдут для сбора логов в Kubernetes.

Fluentd, Fluent Bit и Fluent Operator

Fluentd и Fluent Bit – это два агента ведения логов, которые предназначены для сбора, фильтрации, агрегации и передачи логов в различных средах, в том числе и в Kubernetes. Fluentd больше подойдет для обработки собранных логов из-за наличия различных плагинов. Fluent Bit, в свою очередь, подойдет для сбора логов и их отправки конечным адресатам.

Fluent Operator – это инструмент, разработанный для управления и автоматического развертывания агентов Fluentd и Fluent Bit в среде Kubernetes. Он упрощает процесс их установки, настройки и масштабирования в кластере с помощью ресурсов Custom Resource Definitions (CRD). С помощью Fluent Operator пользователь может развернуть каждый из агентов по отдельности, либо Fluent Bit в сочетании с Fluentd.

Процесс работы с Fluent Operator изображен на следующей картинке:

^{Источник изображения: github.com}

Ниже перечислены пользовательские ресурсы Fluent Operator:

• Системные ресурсы:
• FluentBit – используется для создания демонов Fluent Bit и его конфига; 
• FluentBitConfig – используется для определения набора подключаемых модулей (ввод, вывод, фильтрация), которым будет управлять FluentBit, и генерации финальной конфигурации в виде секрета;
• Input – модуль конфигурации для сбора логов;
• Parser – модуль конфигурации для анализа логов;
• Filter – модуль конфигурации для фильтрации логов;
• OutPut – модуль конфигурации для отправки логов на указанный носитель.

Взаимосвязь и работа ресурсов представлены на следующей картинке:

^{Источник изображения: github.com}

Elasticsearch, Logstash и Beats, Kibana (ELK Stack/Elastic Stack)

ELK Stack – это комбинация трех популярных инструментов для сбора, агрегации, обработки и визуализации данных логов: Elasticsearch, Logstash и Kibana. C 2015 года к ним был добавлен Beats для повышения производительности, а весь стек был переименован в Elastic Stack.

• Elasticsearch – это поисковый и аналитический движок, который используется для хранения и индексации структурированных и неструктурированных данных, включая логи.
• Logstash – это агент для сбора, обработки и доставки логов. Иногда вместо него пользователи ставят агент Fluentd, который считается более стандартным решением для среды K8s. В таком случае получается не ELK-стек, а EFK.
• Beats – это облегченные агенты, которые устанавливаются на периферийных хостах для сбора различных типов данных и последующей их пересылки в стек. Например, это может быть Filebeat, Metricbeat, Packetbeat, Winlogbeat и другие.
• Kibana – это инструмент для визуализации и анализа данных, интегрированный с Elasticsearch.

Рабочий процесс ELK Stack представлен на картинке ниже:

^{Источник изображения: medium.com}

Здесь Beats и Logstash совместно выполняют сбор и обработку логов, Elasticsearch хранит их, а Kibana создает визуализацию.

Заключение

В среде Kubernetes существует множество источников логов, которые, в целях улучшения системы, необходимо собирать и обрабатывать. В настоящей инструкции мы рассмотрели архитектуру логирования в Kubernetes, а также изучили процесс ведения логов на разных уровнях. Кроме того, были продемонстрированы инструменты для сбора и агрегирования логов, такие как Fluent Operator (Fluentd и Fluent Bit) и Elastic Stack.