Efk стек что это

Сборка логов в kubernetes. Установка EFK стека с LDAP интеграцией. (Bitnami, opendistro)

Постепенно эволюционируя, каждая организация переходит от ручного grep логов к более современным инструментам для сбора, анализа логов. Если вы работаете с kubernetes, где приложение может масштабироваться горизонтально и вертикально, вас просто вынуждают отказаться от старой парадигмы сбора логов. В текущее время существует большое количество вариантов систем централизованного логирования, причем каждый выбирает наиболее приемлемый вариант для себя. В данной статье пойдет речь о наиболее популярном и зарекомендовавшем себя стэке Elasticsearch + Kibana + Fluentd в связке с плагином OpenDistro Security. Данный стэк полностью open source, что придает ему особую популярность.

Проблематика

Нам необходимо было наладить сборку логов с кластера kubernetes.

Требования:

Использование только открытых решений

Сделать очистку логов.

Аутентификация на базе LDAP

Данный материал предполагает:

Имеется установленный kuberenetes 1.18 или выше (ниже версию не проверяли)

Установленный пакетный менеджер helm версии 3

Немного о helm chart

Наиболее популярным способом установки приложения в kubernetes является helm. Helm это пакетный менеджер, с помощью которого можно подготовить набор компонентов для установки и связать их вместe, дополнив необходимыми метриками и конфигурацией.

Преимущества такого решения:

собраны open source продукты.

стандарты по разработке чатов и докер образов

проект живой и активно поддерживается сообществом

Выбор стека

Во многом выбор стека технологий определило время. С большой долей вероятностью два года назад мы бы деплоили ELK стек вместо EFK и не использовали helm chart.

Fluentd часто упоминается в документации, широко распространен, имеет большое количество плагинов, на все случаи жизни. К тому же у нас есть человек, который после обучение в rebrain и очень хотел внедрить fluentd.

Elasticsearch и kibana поставляются под открытой лицензией, однако плагины безопасности и другие «вкусности» идут под иной лицензией. Компания Amazon выпустила набор плагинов Open Distro, которые покрывают оставшийся функционал под открытой лицензией.

Схема выглядит примерно так

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

Минимальный деплой EFK стека (без Security)

Сборка EFK стека была произведена по статье Collect and Analyze Log Data for a Kubernetes Cluster with Bitnami’s Elasticsearch, Fluentd and Kibana Charts. Компоменты упакованы в отдельный чат. Исходники можно взять здесь и произвести командой

Из исходников values-minimal.yaml

Как видим компонент fluentd forwarder не включен. Перед включением парсинга, я рекомендовал бы настроить на определенные логи, иначе еластику может быть послано слишком большое количество логов. Правила для парсинга описаны в файле apache-log-parser.yaml.

Как отправить логи в EFK

Существует много способов, для начала предлагаем либо включить fluentd forwarder, либо воспользоваться простейшим приложением на python. Ниже пример для bare metal. Исправьте FLUENT_HOST FLUENT_PORT на ваши значения.

По ссылке http://$(minikube ip):30011/ Будет выведено «Hello, world!» И лог уйдет в elastic

Включить fluentd forwarder, он создаст daemon set, т.е. запустится на каждой ноде вашего кубернетеса и будет читать логи docker container-ов.

Добавить в ваш докер контейнер драйвер fluentd, тем более можно добавлять более одного драйвера

Добавить в ваше приложение библиотеку, которая будет напрямую логировать. Пример приложения на python. Используйте его, как отладочное средство при установке EFK.

И как показывает практика, логировать напрямую эффективный, но далеко не самый надежный способ. Даже если вы логируете сразу в fluentd и в консоль. В случае потери конекта, во fluentd часть логов просто не смогут попасть и будут потеряны для него навсегда. Поэтому наиболее надежный способ, это считывать логи с диска для отправки в EFK.

Очистка логов

Для очистки логов используется curator. Его можно включить, добавив в values-minimal.yaml :

По умолчанию его конфигурация уже предусматривает удаление индекса старше 90 дней, это можно увидеть в конфигурации внутри подчата efk/charts/elasticsearch-12.6.1.tgz!/elasticsearch/values.yaml

Security

Как обычно security доставляет основную боль при настройке и использовании. Но если ваша организация чуть подросла, это необходимый шаг. Стандартом де факто при настройке безопасности является интеграция с LDAP. Официальные плагины от еластика выходят не под открытой лицензией, поэтому приходится использовать плагин Open Distro. Далее продемонстрируем, как его можно запустить.

Сборка elasticsearch c плагином opendistro

Вот проект в котором собирали docker images.

Для установки плагина, необходимо, чтобы версия elasticsearch соответствовала версии плагина.

В quickstart плагина рекомендуется установить install_demo_configuration.sh с демо сертификатами.

Есть небольшая магия, ввиду, того что плагин дополняет elasticsearch.yml, а контейнеры bitnami только при старте генерируют этот файл. Дополнительные же настройки они просят передавать через my_elasticsearch.yml

В my_elasticsearch.yml мы изменили настройку, это позволит нам обращаться к рестам elasticsearch по http.

Сделано это в демонстрационных целях, для облегчения запуска плагина. Если вы захотите включить Rest Layer tls придется добавлять соответствующие настройки во все компоненты, которые общаются с elasticsearch.

Запуск docker-compose с LDAP интеграцией

Теперь у нас есть вкладка Security

Можно посмотреть настройку LDAP через интерфейс кибаны

Настройки должны совпадать с файлами конфигурации. Стоит обратить внимание, что плагин хранит свои данные в индексе еластика, и файлы конфигурации применяет при инициализации, т.е. если индекс не создан. Если вы измените файлы позже то вам придется воспользоваться утилитой securityadmin.sh

настройка Ldap

Для настройки интеграции с LDAP необходимо заполнить соответствующие секции в elastisearch-opendistro-sec/config.yml, ссылка на официальную документацию по authentication

В случае с Active Directory, необходимо будет изменить конфигурационный файл примерно так:

Не забудьте воспользоваться securityadmin.sh после изменения конфигурации. Процедура была описана в предыдущем параграфе.

Установка EFK + Opendistro в kubernetes

Вернемся к проекту с kubernetes, установим проект командой

Нам необходимо будет

Для настройка OpenDistro Security plugin мы скопировали файл конфигурации, которые поместим в секреты kubernetes, в values.yaml добавился блок:

Чтобы настройки применялись при команде helm upgrade, мы сделали job, который будет запускаться при каждой команде helm upgrade

Итоги

Если вы собираетесь организовать централизованную сборку логов для приложений под управление kubernetes, данный вариант мог бы стать вполне обоснованным решением. Все продукты поставляются под открытыми лицензиями. В статье приведена заготовка из которой можно создать production ready решение. Спасибо за внимание!

Источник

Fluentd: почему важно настроить выходной буфер

В наше время невозможно представить проект на базе Kubernetes без стека ELK, с помощью которого сохраняются логи как приложений, так и системных компонентов кластера. В своей практике мы используем стек EFK с Fluentd вместо Logstash.

Fluentd — это современный универсальный коллектор логов, набирающий всё большую популярность и присоединившийся к Cloud Native Computing Foundation, из-за чего вектор его разработки ориентирован на использование совместно с Kubernetes.

Факт использования Fluentd вместо Logstash не изменяет общую суть программного комплекса, однако, для Fluentd характерны свои специфические нюансы, следующие из его многофункциональности.

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

Проблема дублирования документов

В наших проектах Fluentd развернут как DaemonSet (автоматически запускается в одном экземпляре на каждом узле кластера Kubernetes) и отслеживает stdout логи контейнеров в /var/log/containers. После сбора и обработки логи в виде JSON-документов поступают в ElasticSearch, поднятый в кластерном либо standalone виде, в зависимости от масштабов проекта и требований к производительности и отказоустойчивости. В качестве графического интерфейса используется Kibana.

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

Однако, в ElasticSearch существует несколько документов, содержащих данное сообщение:

Притом, повторов может быть больше двух.

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

Данные предупреждения возникают когда ElasticSearch не может вернуть ответ на запрос за установленное параметром request_timeout время, из-за чего пересылаемый фрагмент буфера не может быть очищен. После этого Fluentd пытается отправить фрагмент буфера в ElasticSearch повторно и через произвольное число попыток операция завершается успешно:

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

В Kibana это выглядит так:

Решение проблемы

Существует несколько вариантов решения данной проблемы. Один из них — встроенный в плагин fluent-plugin-elasticsearch механизм генерации уникального хеша для каждого документа. Если использовать данный механизм, ElasticSearch будет распознавать повторы на стадии пересылки и не допускать дублирования документов. Но нельзя не учитывать, что данный способ решения проблемы борется со следствием и не устраняет ошибку с нехваткой тайм-аута, поэтому мы отказались от его применения.

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

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

На момент фиксации проблемы конфигурация выглядела следующим образом:

В ходе решения проблемы вручную подбирались значения следующих параметров:
chunk_limit_size — размер чанков, на которые разбиваются сообщения в буфере.

Общий размер буфера можно вычислить, перемножив параметры queue_limit_length и chunk_limit_size, что можно толковать как «максимальное количество чанков в очереди, каждый из которых имеет заданный объем». При недостаточном размере буфера в логах будет появляться следующее предупреждение:

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

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

Если установить размер чанка chunk_limit_size более 32 мегабайт, то ElasticSeacrh не примет его, так как входящий пакет получится слишком большим. Поэтому, если необходимо увеличить буфер дополнительно, лучше увеличивать максимальную длину очереди queue_limit_length.

Когда буфер перестанет переполняться и останется только сообщение о нехватке тайм-аута, можно приступить к увеличению параметра request_timeout. Однако, при установке значения больше 20 секунд, в логах Fluentd начнут появляться следующие предупреждения:

Данное сообщение никак не влияет на работу системы и означает, что время очистки буфера заняло больше, чем установлено параметром slow_flush_log_threshold. Это отладочная информация и мы используем её при подборе значения параметра request_timeout.

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

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

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

Стоит дополнительно отметить, что полученные настройки могут потерять свою актуальность в процессе роста проекта и, соответственно, увеличения количества логов. Первичным признаком нехватки установленного тайм-аута является возвращение в лог Fluentd сообщений о долгой очистке буфера, то есть превышение порога slow_flush_log_threshold. С этого момента есть ещё небольшой запас до превышения параметра request_timeout, поэтому необходимо своевременно отреагировать на данные сообщения и повторно выполнить процесс подбора оптимальных настроек, описанный выше.

Заключение

Тонкая настройка выходного буфера Fluentd является одним из главных этапов настройки EFK стека, определяющим стабильность его работы и корректность размещения документов в индексах. Ориентируясь на описанный алгоритм настройки, можно быть уверенным, что все логи будут записаны в индекс ElasticSearch в правильном порядке, без повторений и потерь.

Источник

Логирование в Kubernetes: EFK против PLG

Категории

Свежие записи

Наши услуги

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

Эти же инструменты должны быть эффективными и производительными. В этой статье мы рассмотрим два популярных стека технологий: EFK (Elasticsearch) и PLG (Loki) и разберём их архитектуры и различия.

Стек EFK

Возможно, вы уже слышали о весьма популярном ELK или EFK. Стек состоит из нескольких отдельных частей: Elasticsearch (объектное хранилище), Logstash или FluentD (сбор и агрегация журналов) и Kibana для визуализации.

Типичная схема работы выглядит так:

Elasticsearch — распределенное объектное хранилище с поиском и аналитикой в реальном времени. Превосходное решение для частично структурированных данных, например журналов. Информация сохраняется в виде документов JSON, индексируется в режиме реального времени и распределяется по узлам кластера. Применяется инвертированный индекс, содержащий все уникальные слова и связанные с ними документы для полнотекствого поиска, который в свою очередь основан на поисковом движке Apache Lucene.

Kibana — средство визуализации данных для Elasticsearch с различными дополнительными возможностями, например, анализом временных рядов, графов, машинным обучением и прочим.

Архитектура Elasticsearch

Данные кластера Elasticsearch хранятся размазанными по всем его узлам. Кластер состоит из нескольких узлов для улучшения доступности и устойчивости. Любой узел может выполнять все роли кластера, но в крупных масштабируемых развертываниях узлам обычно назначают отдельные задачи.

Типы узлов кластера:

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

Данные каждой реплики хранятся в инвертированном индексе, схема ниже показывает, как это происходит:

Установка

Стек PLG

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

Promtail — агент для отправки журналов из операционной системы в кластер Loki. Grafana — инструмент визуализации на основе данных из Loki.

Loki построен на тех же принципах, что и Prometheus, поэтому он хорошо подходит для хранения и анализа журналов Kubernetes.

Архитектура Loki

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

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

Давайте посмотрим на архитектуру системы сбора журналов без детализации:

А здесь — описание (микросервисная архитектура):

Promtail — агент, устанавливаемый на узлы (в виде набора сервисов), он снимает журналы из задач и обращается к API Kubernetes для получения метаданных, которыми будут помечены журналы. Затем он отправляет журнал к основному сервису Loki. Для сопоставления метаданных поддерживаются те же правила для маркировки, что и в Prometheus.

Distributor — сервис-распределитель, работающий как буфер. Для обработки миллионов записей он производит упаковку входящих данных, сжимая их блоками по мере их поступления. Одновременно работает несколько приемников данных, но журналы, принадлежащие одному потоку входящих данных должны оказаться только в одном из них для всех его блоков. Это организовано в виде кольца приемников и последовательного хэширования. Для отказоустойчивости и избыточности оно делается n раз (3, если не настраивать).

Ingester — сервис-приемник. Блоки данных приходят сжатыми с добавленными журналами. Как только блок оказывается достаточного размера, производится сброс блока в базу данных. Метаданные идут в индекс, а данные от блока с журналом попадают в Chunks (обычно это объектное хранилище). После сброса приемник создает новый блок, куда будут добавляться новые записи.

Index — база данных, DynamoDB, Cassandra, Google BigTable и прочее.

Chunks — блоки журналов в сжатом виде, обычно хранятся в объектном хранилище, например, S3.

Querier — путь чтения, делающий всю черную работу. Он смотрит диапазон времени и метки, после чего смотрит индекс для поиска совпадений. Далее читает блоки данных и фильтрует их для получения результата.

А теперь давайте посмотрим все в работе.

Установка

Для установки в Kubernetes проще всего воспользоваться helm. Полагаем, что вы уже его поставили и настроили ( и третьей версии! прим. переводчика)

Добавляем репозиторий и ставим стек.

Ниже приведен пример панели инструментов, на которой показаны данные из Prometheus для метрик Etcd и Loki для журналов подов Etcd.

А теперь давайте обсудим архитектуру обеих систем, а также сравним их возможности между собой.

Сравнение

Язык запросов

В Elasticsearch используется Query DSL и Lucene query language, которые обеспечивают возможность полнотекстового поиска. Это устоявшийся мощный поисковой движок с широкой поддержкой операторов. С его помощью можно искать по контексту и сортировать по релевантности.

Поскольку запросы в Loki связаны с метками — их легко соотнести с метриками, в результате с ними проще организовать оперативный мониторинг.

Масштабируемость

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

Мультиарендность

Мультиарендность кластера — общая тема для сокращения OPEX, оба стека обеспечивают мультиарендность. Для Elasticsearch есть несколько способов разделения клиентов: отдельный индекс каждому клиенту, маршрутизация на основе клиента, уникальные поля клиента, поисковые фильтры. В Loki есть поддержка в виде заголовка HTTP X-Scope-OrgID.

Стоимость

Loki весьма эффективен экономически из-за того, что он не делает индексацию данных, а только метаданных. Таким образом достигается экономия на хранилище и памяти (кэше), поскольку объектное хранилище дешевле блочного, которое используется в кластерах Elasticsearch.

Заключение

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

Стек Loki полезен в экосистеме Kubernetes из-за механизма обнаружения метаданных. Можно легко сопоставить данные для мониторинга на основе временных рядов в Grafana и журналах.

Когда речь идет о стоимости и длительном хранении журналов, Loki является отличным выбором для входа в облачные решения.

На рынке есть больше альтернатив — некоторые могут быть лучше для вас. Например, для GKE есть интеграция Stackdriver, которая обеспечивает отличное решение для мониторинга. Мы не включили их в наш анализ в этой статье.

Статья переведена и подготовлена для Хабра сотрудниками обучающего центра Слёрм — интенсивы, видеокурсы и корпоративное обучение от практикующих специалистов (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)

Добавить комментарий Отменить ответ

Для отправки комментария вам необходимо авторизоваться.

Источник