Rsyslog + elasticsearch. Настройка rsyslog — удаленного центролизованного хранилища log файлов.

14. октября 2016 Заметки 0

При администритовании парка серверов примерно от 10 и выше, возникает необходимость в централизованном хранении логов.

Целей тут несколько.

  • Во первых безопасность —  все фиксируется, и дублируется не только локально, но и на удаленном сервере. Если взломают сервер и потрут логи, то в частном случае можно будет восстановить что и когда было сделано; кем и откуда.
  • Второй момент — удобная обработка логов. Логи можно быстро затолкать в эластик и через интерфейс kibana легко смотреть что происходит, строить зависимости и тд.
  • Третий, важный  момент — единая с программистами среда разбора логов. Можно сопоставлять время того или иного событиям по определенным критериям с событиями на других серверах, обычно этот критерий является основным для внедрения централизованной хранилки логов.
  • Есть еще один очень важный момент в крупных кампаниях — протокол syslog  очень удобно использовать для доставки сообщений не только от серверов но и от приложений, кронов и прочего в хранилку. Плюс тут в существенном росте производительности — приложению не требуется ни открывать файл на диске, ни тем более соединятсья по сети с elasticsearch — все что нужно это записать данные в syslog сокет. Дальше при правильной настройке доставка произойдет средствами самого сислога, а процесс продолжит свою работу без существенных задержек.

Приступаем. На большинстве серверов в коробке уже стоит rsyslogd, который помимо всего прочего умеет отправлять логи в elasticsearch. Это очень круто, так как не требуется лишнее звено в виде logstash!

Для надежности в эластике мы будем дублировать логи в эластике и на диске.

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

Тут параметр $ActionQueueType Direct подбирался экспериментально, в скупой официальной документации на эту тему сказано ровно следующее:

Экспериментально было выяснено:

  • LinkedList — асинхронный режим, при получении больших сообщений не передает их сразу а некоторое время ожидает, до полуминуты.
  • Direct — синхронный режим, быстро и сразу передает сообщения
  • Disk — сихнронный самый медленный режим, предполагающий все сообщения вместе с передачей писать в очередь на диск
  • FixedArray — не экспериментировл, но по смыслу похоже на LinkedList

 

И далее на принимающем сервере создаем следующий конфиг:

Тут все просто и внимание стоит обратить на две последние строчки — создаем темплейт по которому будут писаться сообщения в файловой системе и в последней строке пишем.

В первых же 4х строках мы открыли на прием стандартные порты на tcp и udp.

В обоих случаях необходимо указывать $MaxMessageSize желательно заметно больше ожидаемой длины пакета.

Теперь самое вкусное — запись логов в elasticsearch. В том же кониге создаем два темплейта. Первый  переведет полученные данные в json и подготовит для загрузки в elasticsearch, второй определяет индекс для отправки логов в самом эластике:

Следующим шагом загружаем модуль вывода данных в эластик и отправляем в него данные по шаблону определенному выше:

 

 

По теме rsyslog на этом месте можно закончить! Не расскрытой осталась тема работы с kibana.

Если у Вас она еще не стоит, то вот простой рецепт.  Создаете файл docker-compose.yml следующего содержимого на этот же сервер:

 

После чего выполняем в папке с этим файлом команду docker-compose up -d, далее происходит скачка, установка  и запуск контейнеров. Сразу же после запуска в эластк начнут поступать данные из сислога, а в кибану мы сможем попасть по порту 5601 (отпубликованному в конфиге выше). Нам остается в кибане создать  индекс syslog- и начать пользоваться фильтрами.

 

 

 


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

Ваш e-mail не будет опубликован. Обязательные поля помечены *