Мониторинг логов на основе Elastiсsearch+Fluentd+Kibana — Часть-2

Это вторая часть по настройке мониторинга логов на основе Elasticsearch+Fluentd+Kibana
Первая и третья  части доступна здесь:
Настройка Elasticsearch+Fluentd+Curator+Cerebro на коллекторе(сервере) – Часть-1
Настройка Elasticsearch+Fluentd+Curator+Cerebro на коллекторе(сервере) – Часть-3

Нумерацию пунктов/разделов продолжим исходя из первой части статьи

6.Установка и настройка на целевом хосте Fluentd-агента, с помощью которого собираем логи(все логии, кроме mysql-логов)

В качестве fluentd-агента будем использоваться td-agent(стабильный fluentd-агент выпускаемый компание Treasure Data, Inc)

Сравнительная характеристика Fluentd и td-agent
https://www.fluentd.org/faqs

Установка td-agent на RPM/DEB-based дистрибутивах
https://docs.fluentd.org/installation/install-by-rpm
https://docs.fluentd.org/installation/install-by-deb

RPM-based дистрибутив ( в нашем случае Centos 7)

Импортируем ключ,которым подписаны пакеты в репозитарии

Добавление репозитарий с fluentd-агентом

Установка fluentd-агент

Изменяем дефолтный systemd-unit файл для fluentd-агента
По умолчанию fluentd запускается под пользователем и группой td-agent, которые не имеет право на чтение для лог файлов контейнеров, системных логов и т.д.
Поэтому изменяем владельца/группу, под которыми запускается fluentd-агент на root

Перечитываем настройки Systemd-демона после изменения systemd-unit-файла

 

Настройка конфигурационного файла fluentd-агента

Файл с настройками буферизации, подключаемый в основном конфигурационном файле td-agent.conf имеет вид

Разберем конфигурационный файл /etc/td-agent/td-agent.conf

– источник, с которого считывать логи

– модуль tail, который используется для чтения файла

– метка этого типа логов(используется в /var/log/td-agent/td-agent.log для удобства отличия различных логов)

– модуль парсинга — используем дефолтный модуль syslog

– файл/файлы с какого/их читать логи

– расположение и имя служебного файла, в который записывается текущая позиция и имя файла лога, с которого эта позиция была прочитана.
Это позволяет fluentd-агенту мониторить, на какой строке и в каком файле он закончил вычитывание логов

– читать ли файп с начало или нет

– навешиваем тег на эти логи, что позволяет в дальнейшем на основании тегов направлять логи на различные модули парсинга, на различные типы выводов, проводить различные манипуляции с таким тегированными логами

– для всех логов(независимо от тегов) добавляем поле hostname со значением полного доменного имени хоста, с которого fluentd считывает логи(это FQDN автоматически определяется fluentd-агентом)

На основе ранее проставленного тега определяем output/вывод куда нужно отправлять логи

– отправляем вывод в Elasticsearch
Параметры подключения к Elasticsearch

Используем для индексов такой же формат, как и формат в logstash

Имя индекса в Elasticsearch

Перед отправкой в Elasticsarch логи собираются во временный буфер, чтобы не отправлять в Elastcisearch каждый event(лог), а выполнять отправку порциями
Тип буфера – файл ( не память, что тоже возможно)
Имя файла определяется параметром path
Параметры буфера подключаем из отдельного файла — @include

Отправляет логи в Elastiсsearch каждые 5 секунд.
При недоступности Elasticsearch Fluentd пытается подключиться к нему с интервалом экспоненциально увеличивающимся до 30 секунд.
Если Elasticsearch не доступен — продолжает читать файл и складывает порции данных до установленного предела, достиг предела, останавливает чтение файла и запоминает позицию. При восстановлении связи с Elasticsearch Fluentd-агент начинает передачу собравшихся данных и возобновляет чтение файла с места остановки

Для сбора логов с Nginx и PHP-FPM контейнеров с этого сервера, необходимо расскомментировать строку

и создать файл web.conf с таким содержанием

Разберем содержимое файла web.yml

Парсим nginx error.log с помощью модуля regexp

 

Fluentd-редактор регулярных выражений
http://fluentular.herokuapp.com

 

Читаем логи ВСЕХ контейнеров,навешиваем на них тег(docker.**)

Добавлям новые поля с идентификатором контейнера(container) и его именем(name)
со значениями этих полей, которые динамически определяются в результате парсинга докер-лог файла config.v2.json для каждого контейнера

Добавляем соответствуюшие теги (docker.nginx.access или tag docker.php-fpm.access) для логов с контейнеров nginx и php-fpm соответственно благодаря ранее установленному полю с именем контейнера. Именно по этому полю и определяем, с какого контейнера поступил лог

Все остальные логи не nginx и не php-fpm контейнеров удаляем(т.к. они имеют теги, которые и попадают под нижеуказанный шаблон)

Парсинг лога php-fpm контейнера(на основе ранее установленного тега docker.php-fpm.access)

Парсинг лога nginx access-лога контейнера nginx на основе ранее установленного тега docker.nginx.access)

Далее все по аналогии с вышеописанным системным логом

 

Формат Nginx-access-логов контейнера имеет вид

Добавлены полезные заголовки при подключении к upstream/backend-части

Проверка синтаксиса конфигурационного файла td-agent.conf

Запуск fluentd-агента

 

Настройка ротации логов fluentd-агента

Просмотр логов fluentd-агента


Установка и настройка fluent-агента на DEB-based дистрибутив ( в нашем случае Ubuntu 18.04)

Содержимое конфигурационного файла fluentd-агента td-agent.conf аналогично указанному выше, за исключением имен системных файлов специфических для DEB-based-дистрибутивов

Проверка синтаксиса конфигурационного файла td-agent.conf

Запуск fluentd-агента

 

Настройка сбора логов выполненных команд – bash history

Настроим перехват выполненных всеми пользователями консольных команд и запись их в отдельный файл ,с которого fluentd-агент будет читать логи и отправлять их в Elasticsearch
Для этого в системном/глобальном /etc/profile.d каталоге создается файл, который будет перехватывать выполненные в консоли команды и отправлять их в rsyslog ( в locale1) с уровнем важности notice
А rsyslog-настроим на отправку этих логов в файл /var/log/bash_history

Для RPM-based-дистрибутивов необходимо выполнить скрипт

Для DEB-based-дистрибутивов необходимо выполнить скрипт


Добавление cron-заданий на хостах

Также на каждом хосте, с которого собираются логи рекомендую добавить следующие cron-задания
— удаление служебных sigdump-файлов с каталога /tmp (их создает fluentd)
— очистка файла с выполненными командами /var/log/bash_history
— рестарт fluentd-агент, если существуют файлы в модификацией больше 2-х минут
(Иногда fluentd-агент не может передать логи на Elastcisearch c ошибкой в своих логах о том, что не может покдлючиться к Elasticsearch, при этом, если вручную проверить доступность Elastcisearch c fluentd-хоста, то поделючение успешно (curl -u fluentd:fluentd_password http://:9200)
Примечательно,что простой перезапуск fluentd-агента тут же приводит к успешному подключению к Elasticsearch и отправки ему всех накопившихся логов)

Комментирование и размещение ссылок запрещено.

Комментарии закрыты.

Яндекс.Метрика