Input plugin tail имеет возможность обрабатывать многострочные лог файлы. Достаточно создать PARSER, при помощи которого можно определить первую строку такого сообщения. Все вроде бы работает, но мне захотелось не просто разобрать сообщение по тегам, но и в отдельном теге сохранить всё исходное сообщение.

По идее регулярное выражение, используемое в парсере для лога openfire

2018.04.16 10:48:15 ERROR [pool-2-thread-171]: org.jivesoftware.openfire.filetransfer.proxy.ProxyConnectionManager - Error processing file transfer proxy connection
java.io.IOException: Only SOCKS5 supported
        at org.jivesoftware.openfire.filetransfer.proxy.ProxyConnectionManager.processConnection(ProxyConnectionManager.java:156) ~[xmppserver-4.3.2.jar:4.3.2]
        at org.jivesoftware.openfire.filetransfer.proxy.ProxyConnectionManager.access$200(ProxyConnectionManager.java:53) ~[xmppserver-4.3.2.jar:4.3.2]
        at org.jivesoftware.openfire.filetransfer.proxy.ProxyConnectionManager$1$1.run(ProxyConnectionManager.java:125) [xmppserver-4.3.2.jar:4.3.2]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_202]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_202]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_202]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_202]
        at java.lang.Thread.run(Thread.java:748) [?:1.8.0_202]

должно выглядеть как то так:

^(?<message>(?<time>\d{4}\.\d{2}\.\d{2} \d{2}:\d{2}:\d{2}) (?<loglevel>\w+) {1,2}(?<process>\[[^ ]*\]): .*)

Оказалось, что всё не так просто. Fluent bit находит первую строку, разбирает её, формирует теги. Вроде всё нормально.

Но остальные строки он тупо дописывает к последнему тегу регулярного выражения. И вместо того, что бы поместить их (как я ожидал) в тег message, он добавляет их к тегу process.

Поэтому, после обработки приходится «терять» теги time, loglevel и process используя следующее выражение вместо первого:

^(?<time>\d{4}\.\d{2}\.\d{2} \d{2}:\d{2}:\d{2}) (?<loglevel>\w+) {1,2}(?<process>\[[^ ]*\]): (?<message>.*)

Остальные строки многострочного лога будут добавляться к тегу message, но он не будет содержать время, loglevel и процесс.

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

Fluent bit очень легкий агент по сбору логов и прочей информации для Ealstic Stack. Но, как и у всех программ, у него встречаются баги.

Например, существует проблема по формированию @timestamp различными input плагинами. Плагины tail и syslog считают, что текущее время компьютера находится во временной зоне UTC и добавляют к нему разницу между UTC и текущей тайм зоной. Это происходит даже в том случае, если текущее время системы сконфигурировано с учетом вашей временной зоны. А, например, плагин exec правильно читает текущее время системы.

В результате в индексах эластика записям присваивается не правильный @timestamp. И некоторые логи в индексе попадают в будущее 🙂

Бороться с этим можно только при помощи парсеров. В сообщениях, обрабатываемых fluent bit обязательно должно быть поле, содержащее время когда было сформировано событие. Обычно в лог файлах такое поле присутствует. Если его там нет, постарайтесь настроить программы так, что бы они помещали его в логи.

При определении секции [INPUT] используйте параметр Parser для однострочных логов. Или Parser_Firstline для многосторочных логов.

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

Например, для обработки информации получаемой из syslog используют стандартный парсер syslog-rfc3164. Поскольку input плагин syslog содержит баг, то придется в парсере добавить параметр Time_Offset. В результате конфигурация будет выглядеть как то так:

[INPUT]
    Name syslog
    Tag syslog
    Parser syslog-rfc3164
    Listen 127.0.0.1
    Port 5140
    Mode tcp

[PARSER]
    Name syslog-rfc3164
    Format regex
    Regex /^\<(?<pri>[0-9]+)\>(?<time>[^ ]* {1,2}[^ ]* [^ ]*) (?<host>[^ ]*) (?<ident>[a-zA-Z0-9_\/\.\-]*)(?:\[(?<pid>[0-9]+)\])?(?:[^\:]*\:)? *(?<message>.*)$/
    Time_Key time
    Time_Format %b %d %H:%M:%S
    Time_Format %Y-%m-%dT%H:%M:%S.%L
    Time_Keep On
    Time_Offset +0300

Итого, если вы видите, что события в эластике формируются в будущем, начинайте писать свой PARSER 🙂

Kibana конечно сама хорошо работает с клиентами. Но лучше спрятать её за нормальным http сервером. Там где мне пришлось развертывать ELK пользуются только Apache, поэтому в качеcтве примера используется данный web сервер.

Сначала в конфигурационном файле kibana.yml определим два параметра:

server.basePath: "/kibana"
server.rewriteBasePath: true

Поскольку Apache выступает фронтендом для разных приложений, доступ к Kibana сделаем через путь http://any.body.com/kibana. В конфиге Apache определим Location.

<Location /kibana>
  ProxyPreserveHost On
  ProxyPass  http://any.ip.com:5601/kibana
  ProxyPassReverse  http://any.ip.com:5601/kibana
</Location>

Собственно, все. Дальше можно включать необходимые вам плюшки web сервера.