Практика применения распределенной лог-системы EFK (1)

Зачем вам нужна распределенная система логирования

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

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

Однако после централизации лог-файлов мы сталкиваемся со статистикой и получением этих лог-файлов, например, какие службы имеют аварийные сигналы и исключения, для которых требуется подробная статистика. Поэтому, когда в прошлом случались онлайн-сбои, разработчики, операционный и обслуживающий персонал часто просматривали журналы службы загрузки, извлекали и подсчитывали их на основе некоторых команд Linux (таких как grep, awk, wc и т. д.). Этот метод не только имеет большую рабочую нагрузку и низкую эффективность, но и неизбежно будет «бессильным» и не сможет хорошо работать для таких операций, как запрос, сортировка и статистика, требующих повышенных требований, а также огромного количества машин.

Метод сбора журнала контейнера

Если журнал размещен внутри контейнера, он будет удален при удалении контейнера. Количество контейнеров велико, и традиционный способ просмотра логов стал непрактичным. Чтобы понять метод сбора журналов контейнера, давайте сначала рассмотрим следующие три вопроса:

В чем разница между сбором логов в K8S и сбором логов в традиционных условиях?
Какие журналы обычно собираются?
После определения типа журналов, которые необходимо собрать, как вы будете их собирать?

Вы можете подумать над приведенными выше вопросами, и мы ответим на них шаг за шагом позже.

Классификация журналов контейнеров

Есть несколько типов логов о контейнерах, а для самого k8s их три:

1. Событие event при запуске ресурса. Например, после создания модуля в кластере k8s вы можете использовать команду kubectl описать модуль для просмотра подробной информации о модуле.

2. Журналы, созданные приложением, работающим в самом контейнере, например, журналы работы tomcat, nginx и php. Например, kubectl регистрирует redis-master-bobr0. Это также часть, представленная официальными и большинством статей в Интернете.

3. Сервисные логи каждого компонента k8s, такие как systemctl status kubelet.

k8s способ

Сам K8s имеет консоль вывода журнала контейнера, а сам Docker предоставляет возможность сбора журнала. Если он попадает в локальные файлы, в настоящее время нет хорошего способа его собрать. Поэтому информация об атрибутах (путь к файлу журнала, источник журнала) недавно расширенного модуля может измениться.Процесс аналогичен процессу традиционной коллекции, как показано на следующем рисунке.

Вообще говоря, мы используем две схемы сбора логов:

Собирать вне контейнера. Смонтируйте каталог узла как каталог журнала контейнера, а затем соберите его на узле.
Собрать в контейнер. Разверните программу сбора журналов на узле, например, разверните в методе daemonset, чтобы собрать каталоги в контейнере этого узла. И смонтируйте каталог в контейнере в каталог хоста. Каталог для сбора логов в двух каталогах /var/log/kubelet/pods и /var/lib/docker/containers/ этого узла.
сетевая коллекция. Приложение в контейнере отправляет журнал непосредственно в центр журналов.Например, программа на Java может использовать log4j 2 для преобразования формата журнала и отправки его на удаленный конец.
Прикрепите к поду специальный контейнер для сбора журналов. Добавьте контейнер для сбора журналов в каждый модуль, на котором запущено приложение, и используйте emtyDir, чтобы предоставить общий доступ к каталогу журналов для чтения сборщиком журналов.

Официальное использование — это последний метод, запускающий ElasticSearch и kibana в кластере k8s, а затем запускающий fluentd с daemonset.

Распределенная система логирования ELKB

ELKB — это полная распределенная система сбора журналов, которая решает вышеупомянутые проблемы сложного сбора, поиска и анализа журналов. ELKB относится к Elasticsearch, Logstash, Kibana и Filebeat соответственно. Полный набор компонентов, предоставляемых elastic, можно рассматривать как модель MVC, logstash соответствует уровню контроллера логического управления, Elasticsearch — уровню модели модели данных, а Kibana — уровню представления. Logstash и Elasticsearch реализованы на Java, а Kibana использует фреймворк node.js.

Kibana: платформа визуализации. Kibana — это веб-страница для поиска, анализа и визуализации данных журнала, хранящихся в метриках Elasticsearch. Kibana использует интерфейс REST Elasticsearch для извлечения данных, вызова сохраненных данных Elasticsearch и их визуализации. Он не только позволяет пользователям настраивать представления, но также поддерживает запросы и фильтрацию данных особым образом.
Elasticsearch: распределенная поисковая система. Он обладает характеристиками высокой масштабируемости, высокой надежности и простоты управления. Его можно использовать для полнотекстового поиска, структурированного поиска и анализа, а также сочетать эти три функции. Elasticsearch разработан на основе Lucene и в настоящее время является одной из наиболее широко используемых поисковых систем с открытым исходным кодом.Wikipedia, StackOverflow, Github и т. д. создают свои собственные поисковые системы на ее основе.
Logstash: механизм обработки сбора данных. Он поддерживает динамический сбор данных из различных источников данных, фильтрацию, анализ, обогащение и объединение данных, а затем их сохранение для последующего использования.
Filebeat: легкий движок для сбора данных. На основе оригинального исходного кода Logstash-fowarder. Другими словами: Filebeat — это новая версия Logstash-fowarder и первый выбор ELK Stack.

В этой архитектуре мы напрямую подключаем экземпляр Logstash к экземпляру Elasticsearch. Экземпляр Logstash напрямую считывает данные источника данных (например, журналы Java, журналы Nginx и т. д.) через подключаемый модуль ввода, фильтрует журналы с помощью подключаемого модуля фильтра и, наконец, записывает данные в экземпляр ElasticSearch с помощью подключаемого модуля вывода.

Filebeat основан на исходном коде оригинального logstash-forwarder, может работать без использования среды Java, а размер установочного пакета составляет менее 10 М.

Если количество журналов велико, Logstash столкнется с проблемой высокого использования ресурсов.Чтобы решить эту проблему, мы представили Filebeat. Filebeat основан на исходном коде logstash-forwarder.Он написан на Go и не требует опоры на среду Java.Он обладает высокой эффективностью и занимает меньше памяти и процессора.Очень подходит для работы на сервере в качестве Агент.

Filebeat потребляет всего 70% ЦП Logstash, но скорость сбора данных в 7 раз выше, чем у Logstash. С точки зрения практики применения, Filebeat действительно решает проблему потребления ресурсов Logstash с более низкой стоимостью и стабильным качеством обслуживания.

резюме

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

В следующей статье будет рассмотрена конкретная практика, как построить систему журналов EFK на K8s и собрать соответствующие журналы микросервисов.