Русские Блоги
EFK (EFK (Elasticsearse+FileBeat+Kibana) -Установка и развертывание системы сбора распределенных журналов (1)
0 Описание
EFK -распределенные узлы системы сбора журналов расположены следующим образом:
| Название процессора | Хост IP | Развертывание |
|---|---|---|
| chen-1 | 192.168.218.100 | Elasticsearsh Logstash Filebeat Namenode ResourceManager ZK |
| chen-2 | 192.168.218.101 | Elasticsearsh SecondaryNamenode Datanode Nodemanager ZK |
| chen-3 | 192.168.218.102 | Elasticsearsh Datanode Nodemanager ZK |
| chen-4 | 192.168.218.103 | Kibana Datanode Nodemanager |
| chen-5 | 192.168.218.104 | Datanode Nodemanager |
FileBeat и Logstash имеют функцию сбора журналов. Разница в том, что FileBeat легкий. Logstash работает на JVM, но его функция более мощная. В этой статье используется FileBeat+Logstash для сбора журналов.
Каждый компонент более чувствителен к версии. При установке и развертывании необходимо убедиться, что версия всегда была, по крайней мере, большая версия является последовательной. Версия, используемая в этой статье, 6.6.2 версия
1 EFK введение
EFK — это не программное обеспечение, а набор решений, и все это программное обеспечение с открытым исходным кодом. Он сотрудничает друг с другом и идеально подключен для удовлетворения приложений многих раз. В настоящее время он является основной системой журнала. EFK — это аббревиатура трех программного обеспечения с открытым исходным кодом, соответственно: Elasticsearch, FileBeat, Kibana. Среди них Elasticsearch отвечает за сохранение и поиск журнала. FileBeat отвечает за сбор журналов. Конечно FileBeat имеет два преимущества по сравнению с Logstash:
1. Вторжение минимум, нет необходимости изменять текущий код и конфигурацию
2. По сравнению с Logstash, производительность высока, а Logstash занимает большое занятие IO
Конечно, FileBeat не совсем лучше, чем LogStash. В конце концов, LogStash намного лучше, чем форматирование FileBeat журналов. FileBeat только считывает файл журнала из файла журнала. Конечно, но он все еще немного по сравнению с LogStash.
2 Компонент Введение
2.1 Elasticsearch
Elasticsearch — это поисковая система с открытым исходным кодом, которая предоставляет три функции: данные сбора, анализ и хранения. Его характеристики: распределенная, нулевая конфигурация, автоматическое обнаружение, автоматическое отделение индекса, механизм копирования индексации, интерфейс Restful Style, многопрофильный источник, автоматическая загрузка поиска и т. Д.
2.2 FileBeat
FileBeat принадлежит Beats. В настоящее время Beats содержит шесть инструментов:
PacketBeat (собирать данные сетевого трафика)
Метрики
FileBeat (собирать данные файлов)
Winlogbeat (сбор данных журнала событий Windows)
AuditBeat (легкий сборщик журналов аудита)
Сердцебиение (легкий серверный сборщик здоровья)
2.3 Kibana
Kibana может анализировать дружественные веб -интерфейсы, предоставленные Logstash, Beats и Elasticsearch, которые могут помочь суммировать, анализировать и искать важные журналы данных.
3 Архитектурная диаграмма EFK
4 Установка развертывания EFK
1) Установка JDK должна быть версией JDK8 или выше, потому что Elastisearch6.6.2 требует JDK8 или выше.
2) Установить ES
Кластер: 192.168.218.100/101/102
Официальный сайт Скачать адрес: https://www.elastic.co/cn/downloads/
Разанипируйте файл и введите каталог конфигурации
Откройте файл elasticsearch.yml в каталоге конфигурации 
Обратите внимание, что ES не может быть запущена с корневой учетной записи, и новая учетная запись useradd Chen-es
И установите пароль, настройки Passwd Chen-ES разрешены для того, чтобы быть уполномоченным в Chen-Es с корневой учетной записью, чтобы он мог получить доступ к соответствующему каталогу ES. Chown –r Chen-es: Chen-es /root/apps/elastisearch-6.6.2
Переключиться на пользователя Chen-es, запустите ES
./bin/elasticsearch –d –d указывает, что тихий режим запускается
В настоящее время можно увидеть посещение страницы 192.168.218.100:9200 ниже, что означает, что установка ES успешна. 
Скопируйте Elasticsearch-6.6.2 на другие машины, которые необходимо развернуть, изменить файл конфигурации, а файл конфигурации должен только изменить имя узла и IP-адрес 
3) Установите Kibana
Сервер: 192.168.218.103
Официальный веб -сайт: https://www.elastic.co/cn/downloads/kibana Скачать соответствующую версию. Обратите внимание, что версия EFK должна быть последовательной. 6.6.2 версия EFK я использовал
Загрузите и раскапывание в каталог конфигурации, откройте файл конфигурации kibana.yml 
Добавить следующую конфигурацию или комментарий
Среди них Elasticsearch.hosts — это адрес кластера Elasticsearch.
Начни Кибана 
Видя следующий порт монитора, он сказал, что Кибана была успешно установлена 
Посетите страницу 192.168.218.103:5601, вы можете увидеть следующую страницу
Выберите простой пример, чтобы добавить
Нажмите, чтобы просмотреть созданный просмотр 
Вы можете увидеть разные взгляды в соответствии с различными вариантами национальных версий и Windows 
Посмотреть ES Index 
Вы можете использовать инструмент разработки для некоторых связанных запросов 
4) Установить FileBeat
Сервер установки: 192.168.218.100
https://www.elastic.co/cn/downloads/beats/filebeat
Скачать и распахнуть
Введите список основных представлений, измените конфигурацию
Откройте файл конфигурации filebeat.yml и выполните соответствующую модификацию параметров
Конфигурация должна быть выплачена в формате. Он основан на 2 пустых отсеках. Конфигурация внутри находится в файле конфигурации. Перечисленная часть — это только для изменения детали. Включенные по умолчанию по умолчанию. журнал. Среди них /var/xxx/*.log модифицируется на ваш собственный путь журнала, обратите внимание, что позади места позади.
Если добавлено несколько строк, вы должны обратить внимание на 4 пустых пространства перед новой линией. Только несколько конфигураций в начале многослойного могут отменить аннотацию. Адрес настройки ситуации, то же самое в output.lasticsearch, то же самое
Бэкфол: как долго установлен проверка обновления файла.
TAIL_FILES: Если вы установите его как true, FileBeat будет читать новые файлы в конце каждого файла вместо начала.
Когда эта опция используется в сочетании с логотиной, первая запись в журнале в новом файле может быть пропущена.
output.console указывает, что печать выходного контента на панели
Start FileBeat:
Можно найти, что FileBeat прочитал контент в журнале, 
В настоящее время мы посетили веб -страницу в браузере, чтобы добавить содержимое журнала Access.Log, чтобы увидеть, был ли она обновлена в режиме реального времени. 
Вы можете видеть, что данные собираются в режиме реального времени FileBeat 
Сбор и анализ логов Kubernetes кластера с помощью EFK-стека
Mar 15, 2020 10:18 · 648 words · 4 minute read kubernetes fluentbit elasticsearch logs
На дворе уже 2020 год, а стандартного решения для агрегации логов в Kubernetes до сих пор нет. В данной статье рассмотрим особенности сбора и анализа логов в кластере Kubernetes с помощью EFK-стека. Давайте разберемся!
С ростом популярности Kubernetes известная проблема сбора логов стала еще болезненнее: многие старые сервисы начали миграцию на микросервисную инфраструктуру. В контексте логирования это проявилось в растущем числе источников логов, их различном жизненном цикле, и, самое главное, в необходимости отслеживать через логи взаимосвязь всех компонентов системы…
Сейчас, к сожалению, нет стандартизированного варианта логирования для Kubernetes , который бы работал во всех без исключения случаях или имел существенные преимущества. Наиболее популярные варианты на сегодня:
- стек EFK (Elasticsearch, Fluentd, Kibana); или Logging operator;
- собственная разработка (типа loghouse).
В нашем случае было решено использовать стек EFK, во многом из-за простоты развертывания и наличия опыта работы с elasticsearch, однако Fluentd мы заменили на Fluent Bit. Причина такого решения вполне очевидна, если взглянуть на рекомендуемые значения .resources в манифестах для обоих утилит:
Казалось бы, есть вполне пригодная документация и масса примеров установки данного стека, что же может пойти не так и зачем эта статья?
Дело в том, что все доступные материалы и примеры годятся только если ваш Kubernetes кластер использует в качестве исполняемой среды контейнеров (container runtimes) Docker, который долгое время оставался runtime’ом по умолчанию (а у некоторых облачных провайдеров остается и по сей день) и требовался для функционирования кластера. В нашем же случае используется containerd — независимая реализация runtime’а для Kubernetes через (Container Runtime Interface — CRI), и, как оказалось, без “велосипедов” не обойтись.
Задача: необходимо собирать логи из десятков java-приложений (особое внимание уделить стектрейсам) и доставлять их в elasticsearch. Причем, вариант просмотра логов через kubectl logs . также должен остаться.
Fluent Bit с помощью input-плагина tail может читать файлы (например, /var/log/containers/*_default_*.log ), обрабатывать их содержимое и помощью парсеров и фильтров отправлять в output (в нашем случае это кластер elasticsearch).
Проблема первая: формат логов у docker и containerd существенно отличается (первый вообще пишет в json). К счастью, после данного PR в github-репозитории она легко решается через изменение формата парсера.
Проблема вторая: java-стектрейсы попадают в лог-файл ( /var/log/containers/*_default_*.log ) так же, как вы можете их видеть с помощью команды kubectl logs . — при этом каждая отдельная строка становится отдельным лог-сообщением, и попадает в elasticsearch тоже отдельно. Как правило, в java-приложениях для логов используется Logback или Log4j, поэтому вторую проблему можно устранить изменением формата логов — вполне достаточно будет заменить символ переноса строки (LF, \n ) на символ разделителя строк (LS, \u2028 ).
В нашем случае было решено во всех java-приложениях использовать следующий формат логов:
Проблема третья: появилась после решения второй — в elasticsearch теперь логи попадают хоть и одним сообщением, но стектрейсы становятся нечитабельными из-за символов \u2028 . К счастью, это тоже можно решить с помощью elastic pipelines — перед вставкой сообщения в мы выполним обратную замену символов \u2028 на \n (ну и попутно удалим несколько ненужных полей).
Kubernetes манифест со всеми необходимыми объектами (Namespace, ServiceAccount, ConfigMap, …) для тестирования fluent bit будет выглядеть так:
Примечание. Не забудьте изменить Deployment на DaemonSet при использовании в реальном кластере.
Elastic-пайплайн выглядит так:
Данный пайплайн добавляется с помощью следующей команды:
Если у вас нет под рукой подходящего java-приложения для тестирования, можете воспользоваться этим, например с таким манифестом:
По результатам могу сказать, что сбор логов из кластера Kubernetes с первого взгляда выглядит простой задачей, но вовсе таковой не является. Важно помнить, что:
Логирование в Kubernetes: как собирать, хранить, парсить и обрабатывать логи
Разберём основы логирования в Docker и Kubernetes, а затем рассмотрим два инструмента, которые можно смело использовать на продакшене: Grafana Loki и стек EFK: Elasticsearch + Fluent Bit + Kibana.
Логирование в Docker
На уровне Kubernetes приложения запущены в Pod’ах, но на уровне ниже они всё-таки работают обычно в Docker. Поэтому нужно настроить логирование таким образом, чтобы собирать логи с контейнеров. Контейнеры запускает Docker, значит надо разобраться, как логирование устроено на уровне Docker.
Надеюсь, каждый читатель знает: логи приложения надо писать в stdout/stderr, а не внутрь контейнера. Логи агрегирует Docker Daemon, и он работает именно с теми логами, которые отправляются на stdout/stderr. К тому же запись логов внутрь контейнера чревата проблемами: контейнер пухнет от растущего лога (так как никакого Logrotate в контейнере скорее всего нет), а Docker Daemon и не в курсе про этот лог.
У Docker есть несколько лог-драйверов или плагинов для сбора логов контейнеров. В бесплатной версии Docker Community Edition (CE) лог-драйверов меньше, чем в коммерческой Docker Enterprise Edition (EE).
Docker EE я ни разу не использовал на практике: в Southbridge мы стараемся придерживаться Open Source решений, да и клиентам большая часть дополнительных возможностей Docker EE не нужна.
Лог-драйверы в Docker CE:
local — запись логов во внутренние файлы Docker Daemon;
json-file — создание json-log в папке каждого контейнера;
journald — отправка логов в journald.
Настройки логирования в Docker находятся в файле daemon.json. 
В поле “log-driver” указывают плагин, а в поле “log-opts” — его настройки. В примере выше указан плагин “json-file”, ограничение по размеру лога — “max-size”: “10m”; ограничение по количеству файлов (настройки ротации) — “max-file”: “3”; а также значения, которые будут прикручены к логам.
Некоторые настройки лог-драйвера можно задать через командную утилиту; это удобно, если отдельный контейнер нужно запустить с другим лог-драйвером.
Вот как выглядит схема логирования в Docker:
Как схема работает: лог-драйвер, например json-file, создаёт файлы. Сборщики логов (Rsyslog, Fluentd, Logagent и другие) эти файлы собирают и передают на хранение в Elastic, Sematext или другие хранилища.
Особенности логирования в Kubernetes
Упрощённо схема логирования в Kubernetes выглядит так: есть pod, в нём запущен контейнер, контейнер отправляет логи в stdout/stderr. Затем Docker создаёт файл и записывает логи, которые затем может ротировать.
Рассмотрим особенности логирования в Kubernetes.
Сохранять логи между деплоями. Это обязательное условие для корректной настройки логирования. Если не сохранять логи между деплоями, то при выходе новой версии приложения логи предыдущей будут затираться, перезагрузка контейнера также будет чревата потерей логов. У Kubernetes есть ключик —previous, он позволяет посмотреть логи приложения до последнего рестарта Pod’а, но не глубже.
Агрегировать логи со всех инстансов. Если микросервисы хостятся в облаках, то за контроль системы отвечает облачный провайдер. Если микросервисы на своём железе, то помимо логов с контейнеров нужно собирать и логи системы.
Раньше не было удобных инструментов для сбора логов и с системы, и с микросервисов. Обычно один инструмент собирал системные логи (например, Rsyslog), второй — логи с Docker (например, journal-bit с настройкой лог-драйвера Docker на journald). Пробовали использовать journal-bit — собирать логи и с контейнеров (в лог-драйвере Docker указывать, что нужно писать логи в journald), и с системы (в CentOS 7 уже есть systemd и journald). Решение рабочее, но не идеальное. Если логов много, journal-bit начинает лагать, сообщения теряются.
Эксперименты продолжались, и нашёлся другой способ. В CentOS 7 основные системные логи (messages, audit, secure) дублируются в var-лог в виде файлов. В Docker тоже можно настроить сохранение логов в файлы json. Соответственно, эти файлы из CentOS 7 и Docker можно собирать вместе.
Со временем стало популярно решение ELK Stack. Это комбинация нескольких инструментов: Elasticsearch, Logstash и Kibana.
Elasticsearch хранит логи с контейнеров, Logstash собирает логи с инстансов, Kibana позволяет обрабатывать полученные логи, строить по ним графики. Некоторое время ELK Stack активно использовали, но, на мой взгляд, его время проходит. Позже расскажу, почему.
Добавлять метаданные. Pod’ы, приложения, контейнеры могут быть запущены где угодно. Более того, у одного приложения может быть несколько инстансов. Логи записаны в одном формате, а нам надо понять, какая именно это реплика, какой Pod это пишет, в каком namespace он находится. Именно поэтому логам нужно добавлять метаданные.
Парсить логи. Забавно, но расходы на поддержку системы логирования и мониторинга могут превысить затраты на основное приложение. Когда у вас летят десятки и сотни тысяч логов в секунду, это кажется закономерным, но всё же надо знать грань. Один из способов эту грань найти — парсинг логов.
Как правило, не нужно собирать и хранить все логи, надо отправлять на хранение только часть — например, логи со статусом «warning» или «error». Если речь про логи nginx или ingress-контроллеров, то отправлять на хранение можно только те, статус которых отличен от 200. Но это не универсальный совет: если вы строите каким-то образом аналитику по логам Nginx, то их очевидно стоит собирать.
Бездумно фильтровать логи не рекомендуют, потому что отфильтрованных данных может не хватить для нормальной аналитики. С другой стороны, возможно аналитику стоит проводить не на уровне логирования, а на уровне сбора метрик. Тогда не придётся хранить сотни тысяч строк с кодом 200. Один из подходов — получать информацию о трафике и ошибках из метрик ingress-контроллеров.
В общем, здесь надо хорошо подумать: что вы хотите хранить и как долго, потому что иначе возникнет ситуация, когда система логирования будет отнимать ресурсов больше, чем основной проект.
Пока нет стандартного решения для логирования. В отличие от мониторинга, где есть одно, наиболее распространенное решение Prometheus, в логировании стандарта нет. В рамках этой лекции мы рассмотрим два инструмента: один популярный, а второй — набирающий популярность. Помимо них есть и другие, но в этой статье мы их не коснёмся.
Учитывая все рассмотренные выше особенности, логирование в Kubernetes теперь можно представить на такой схеме: 
Остаётся лог контейнера, ротирование, но появляется агент-сборщик, который подбирает логи и отправляет на хранение (на схеме — в Logging Backend). Агент работает на каждой ноде и, как правило, запущен в Kubernetes.
Теперь рассмотрим инструменты для логирования.
Grafana Loki
Grafana Loki появился недавно, но уже стал довольно известным. Его преимущества: лёгко устанавливается, потребляет мало ресурсов, не требует установки Elasticsearch, так как хранит данные в TSDB (time series database). В прошлой статье я писал, что в такой базе хранит данные Prometheus, и это одно из многочисленных сходств двух продуктов. Разработчики даже заявляют, что Loki — это «Prometheus для мира логирования».
Небольшое отступление про TSDB для тех, кто не читал предыдущую статью: TSDB отлично справляется с задачей хранения большого количества данных, временных рядов, но не предназначена для долгого хранения. Если по какой-то причине вам нужно хранить логи дольше двух недель, то лучше настроить их передачу в другую БД.
Ещё одно преимущество Loki — для визуализации данных используется Grafana. Очень удобно: в Grafana мы смотрим данные по мониторингу и там же, подключив Loki, смотрим логи. По логам можно строить графики.
Архитектура Loki выглядит примерно так: ‘ 
С помощью DaemonSet на всех серверах кластера разворачивается агент — Promtail или Fluent Bit. Агент собирает логи. Loki их забирает и хранит у себя в TSDB. К логам сразу добавляются метаданные, что удобно: можно фильтровать по Pod’ам, namespaces, именам контейнеров и даже лейблам.
Loki работает в знакомом интерфейсе Grafana. У Loki даже есть собственный язык запросов, он называется LogQL — по названию и по синтаксису напоминает PromQL в Prometheus. В интерфейсе Loki есть подсказки с запросами, поэтому не обязательно их знать наизусть.
Документация к языку LogQL 
Loki в интерфейсе Grafana
Используя фильтры, в Loki можно найти коды (“400”, “404” и любой другой); посмотреть логи со всей ноды; отфильтровать все логи, где есть слово “error”. Если нажать на лог, раскроется карточка со всей информацией по событию.
В Loki достаточно инструментов, которые позволяют вытаскивать нужные логи, (хотя честно говоря, технически их могло быть и больше). Сейчас Loki активно развивается и набирает популярность.
Elastic + Fluent Bit + Kibana (EFK Stack)
Стек EFK — это более классический, и при этом не менее популярный инструмент логирования.
В начале статьи упоминался ELK (Elasticsearch + Logstash + Kibana), но этот стек устарел из-за не очень производительного и при этом ресурсоёмкого Logstash. Вместо него стали использовать более легковесный и производительный Fluentd, а спустя некоторое время ему в помощь пришёл Fluent Bit — ещё более легковесный, и ещё более производительный агент-сборщик.
Если верить разработчикам, то Fluent Bit более, чем в 100 раз лучше по производительности, чем Fluentd: «там, где Fluentd потребляет 20 Мб ОЗУ, Fluent Bit будет потреблять 150 Кб» — прямая цитата из документации. Глядя на это, Fluent Bit стали использовать чаще.
У Fluent Bit меньше возможностей, чем у Fluentd, но основные потребности он закрывает, поэтому мы в основном пользуемся Fluent Bit.
Схема работы стека EFK: агент собирает логи со всех Pod’ов (как правило, это DaemonSet, запущенный на всех серверах кластера) и отправляет в хранилище (Elasticsearch, PostgreSQL или Kafka). Kibana подключается к хранилищу и достаёт оттуда всю необходимую информацию. 
Kibana представляет информацию в удобном веб-интерфейсе. Есть графики, фильтры и многое другое.
По логам можно создавать целые дашборды. 
Вариант настройки дашборда в Kibana
Возможности Fluent Bit
Так как о Fluent Bit, как правило, слышали меньше, чем о Logstash, рассмотрим его чуть подробнее. Fluent Bit логически можно поделить на 6 модулей, на часть модулей можно навесить плагины, которые расширяют возможности Fluent Bit.
Модуль Input собирает логи из файлов, служб systemd и даже из tcp-socket (надо только указать endpoint, и Fluent Bit начнёт туда ходить). Этих возможностей достаточно, чтобы собирать логи и с системы, и с контейнеров.
В продакшене мы чаще всего используем плагины tail (его можно натравить на папку с логами) и systemd (ему можно сказать, из каких служб собирать логи).
Модуль Parser приводит логи к общему виду. По умолчанию логи Nginx представляют собой строку. С помощью плагина эту строку можно преобразовать в JSON: задать поля и их значения. С JSON намного проще работать, чем со строковым логом, потому что есть более гибкие возможности сортировки.
Модуль Filter. На этом уровне отсеиваются ненужные логи. Например, на хранение отправляются логи только со значением “warning” или с определёнными лейблами. Отобранные логи попадают в буфер.
Модуль Buffer. У Fluent Bit есть два вида буфера: буфер памяти и буфер на диске. Буфер — это временное хранилище логов, нужное на случай ошибок или сбоев. Всем хочется сэкономить на ОЗУ, поэтому обычно выбирают дисковый буфер, но нужно учитывать, что перед уходом на диск логи всё равно выгружаются в память.
Модуль Routing/Output содержит правила и адреса отправки логов. Как уже было сказано, логи можно отправлять в Elasticsearch, PostgreSQL или, например, Kafka.
Интересно, что из Fluent Bit логи можно отправлять во Fluentd. Так как первый более легковесный и менее функциональный, через него можно собирать логи и отправлять во Fluentd, и уже там, с помощью дополнительных плагинов, их дообрабатывать и отправлять в хранилища.
Сборка логов в 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 поставляются с открытой лицензией, однако плагины для security и других вкусностей идут под иной лицензией. Однако компания 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_host:30011/ Будет выведено “Hello, world!” И лог уйдет в elastic
Включить fluentd forwarder, он создаст daemon set, т.е. запустится на каждой ноде вашего кубернетеса и будет читать логи docker container-ов.
Добавить в ваш докер контейнер драйвер fluentd, тем более можно добавлять более одного драйвера
Добавить в ваше приложение библиотеку, которая будет напрямую логировать. Пример приложения на python. Используйте его, как отладочное средство при установке EFK.
И как показывает практика, логировать напрямую эффективный, но далеко не самый надежный способ. Даже если вы логируете сразу в fluentd и в консоль. В случае потери конекта, во fluentd часть логов просто не смогут попасть и будут потеряны для него навсегда. Поэтому наиболее надежный способ, это считывать логи с диска для отправки в EFK.
Очистка логов.
Для очистки логов используется curator. Его можно включить, добавив в 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 интеграцией
Запустим проект с помощью docker-compose up , и залогинимся на http://0:5601 под admin/admin
Теперь у нас есть вкладка Security
Можно посмотреть настройку LDAP через интерфейс кибаны
Настройки должны совпадать с файлами конфигурации. Стоит обратить внимание, что плагин хранит свои данные в индексе еластика, и файлы конфигурации применяет при инициализации, т.е. если индекс не создан. Если вы измените файлы позже то вам придется воспользоваться утилитой securityadmin.sh
настройка Ldap
Для настройки интеграции с LDAP необходимо заполнить соответствующие секции в elastisearch-opendistro-sec/config.yml, ссылка на официальную документацию по authentication
В случае с Active Directory, необходимо будет изменить конфигурационный файл примерно так:
Не забудьте воспользоваться securityadmin.sh после изменения конфигурации. Процедура была описана в предыдущем параграфе.
Установка EFK + Opendistro в kubernetes
Вернемся к проекту с kubernetes, установим проект командой
Нам необходимо будет
Для настройка OpenDistro Security plugin мы скопировали файл конфигурации, которые поместим в секреты kubernetes.
Чтобы настройки применялись при команде helm upgrade, мы сделали job, который будет запускаться при каждой команде helm upgrade
Итоги
Если вы собираетесь организовать централизованную сборку логов для приложений под управление kubernetes, данный вариант мог бы стать вполне обоснованным решением. Все продукты поставляются под открытыми лицензиями. В статье приведена заготовка из которой можно создать production ready решение. Спасибо за внимание!