Я новичок в ELK и хотел бы создать решение для индексации журналов Microsoft IIS и прикладных .NET с помощью ES.
Знаю о разных подходах:
1) [серверы приложений: файлы журналов ➔ Logstash] ➔ [сервер сбора: Redis ➔ Logstash] ➔ [ES-кластер: ES ➔ Kibana]
Недостатком этого метода является необходимость установки, настройки и обслуживания экземпляра logstash на каждом сервере Windows, создающем журналы.
2) [серверы приложений: файлы журналов ➔ Filebeat] ➔ [сервер сбора: Logstash ➔ Redis ➔ Logstash] ➔ [ES-кластер: ES ➔ Kibana]
Минус этого метода заключается в том, что в настоящее время filebeat не поддерживает многострочные записи журнала, а мои приложения .NET создают многострочные исключения. Я не уверен, как нужно настроить промежуточный logstash + redis + logstash для обработки этого.
Поэтому я подумал, что, возможно, учитывая, что Logstash может собирать данные журнала без filebeat или любого другого перенаправителя (пожалуйста, поправьте меня, если я ошибаюсь), я мог бы попробовать следующее:
[серверы приложений: файлы журналов] ➔ [сервер сбора: сетевые диски с отображением Samba ➔ Logstash ➔ Redis ➔ Logstash] ➔ [ES-кластер: ES ➔ Kibana]
В этой гипотезе мне не нужно устанавливать экземпляр Logstash на каждый сервер приложений. Центральный экземпляр logstash (или несколько экземпляров) будет извлекать файлы (с использованием сетевых дисков, отображаемых Samba) и применять многострочный кодек перед отправкой записей журнала в Redis.
Это технически возможно? Это разумный архитектурный выбор?
При запуске Logstash с file ввод против ваших журналов на общий ресурс CIFS будет работать, я не думаю, что он будет работать очень хорошо. Я напрямую не использовал Logstash таким образом, но, по моему опыту использования Logstash-Forwarder для просмотра файлов журналов через монтирование SSHFS, это не очень хорошо работает с ротацией файлов или перезагрузкой с любой стороны.
Что касается того, что вы не знаете, что делать с многострочными исключениями с помощью Filebeat, я не думаю, что вам нужно об этом беспокоиться. FileBeat просто берет строки из файлов, которые вы хотите отправить, и запускает их по сети. Он добавляет несколько полей, но они не влияют на общую концепцию FileBeat как очень простого отправителя журналов.
Это означает, что вы можете просто запустить свой многострочный фильтр в Logstash на сервере сбора данных, как если бы вы запускали Logstash напрямую на серверах приложений.
Теперь, в зависимости от объема вашего журнала, вы можете обнаружить, что вам нужно увеличить количество воркеров для LS, чтобы эффективно обрабатывать ваши данные.
То, что я делаю для обработки таких вещей, очень похоже на ваш вариант 2, но вместо двух экземпляров LS («Брокер» и «Парсер») у меня есть 3.
+-------------------+
+-------------------+|
+-------------------+||
| App Servers |||
| +----------+ ||+
| | FileBeat | |+
+----+----------+---+
/
/
/
+----------------/----------------------------------------+
| / Collecting Server |
| +----------/-+ +---------------------+ +------------+ |
| | Logstash | | Logstash | | Logstash | |
| | Broker | |Multi-line Pre-Parser| | Parser | |
| +------------+ +---^-----------------+ +-----^---V--+ |
| | | | | | |
| | | Redis | | | |
| V +---------------------V------+ | | |
| +-------> DB0 | DB1 + --->+ | |
| +----------------------------+ / |
+-------------------------------------------------/-------+
/
/
/
+-------------------+ /
+-------------------+|/
+-------------------+||
| ElasticSearch ||+
| Cluster |+
+-------------------+
Все Pre-Parser Экземпляр действительно преобразует многострочные записи журнала в одну строку, чтобы Parser может делать свою работу правильно. И даже тогда я проверяю тип и теги, чтобы увидеть, есть ли вообще вероятность того, что строка (строки) будет многострочной, поэтому накладные расходы минимальны.
Я легко могу протолкнуть через него 1000 событий в секунду (едва достигая 20% ЦП). Кроме того, система представляет собой стек ELK в коробке, поэтому с выделенными узлами для LS и ES это должно быть легко.
Почему бы просто не запустить workers на экземпляре парсера? Ну, это связано с тем, что multiline фильтр в LS не поддерживает несколько рабочих.
многострочный
Этот фильтр сворачивает многострочные сообщения из одного источника в одно событие Logstash.Первоначальная цель этого фильтра состояла в том, чтобы разрешить объединение многострочных сообщений из файлов в одно событие. Например - объединение сообщений об исключениях Java и stacktrace в одно событие.
Примечание: Этот фильтр не будет работать с несколькими рабочими потоками
-w 2в командной строке Logstash.