Чем собирать логи?

Нужен совет в выборе opensors сборки для сбора и обработки большого объема логов. На данный момент 11 windows серверов с веб-приложениями ASP.NET, 1 сервер в сутки дает порядка 6 гигов логов совокупно (2-3 приложения). Логи пишутся в файлы, файлы ротируются в зависимости от приложения от 100М до 1G на файл.

Система должна легко и прозрачно масштабироваться с минимальным даунаймом или без оного, кол-во серверов будет расти, так же будут добавлены linux сервера.

Логи планируем собирать именно из файлов, прямое перенаправление в систему сбора напрямую планируется, но в неопределенном будущем, поэтому на данный момент не актуально.

Аллерты по логам особо не нужны, заменять систему данной сборкой пытаться не будем. Основное требование, сведение логов по таймингу между машинами и приложениями и последующий отбор по ключам.

Нужен совет по сборке, с обоснованием преимуществ. Например ELK или graylog2, что лучше и почему, какие ускорилки можно использовать, на вроде rabbitrq?

Так же нужен совет по выбору оси и оптимальной конфе с которых можно начать тестирование.
  • Вопрос задан
  • 4409 просмотров
Пригласить эксперта
Ответы на вопрос 2
MaxDukov
@MaxDukov
впишусь в проект как SRE/DevOps.
как человек, сталкивавшийся с ELK
6Г в день - не страшно для ELK. Но готовьтесь к прожорливости по памяти. Всеж Java...
легкость масштабирования - в принципе да. Добавить ноду в кластер - дело минут. Синхронизация, правда, займет время. Но это везде так, данные "по волшебству" с ноды на ноду не перелетят.
собирать из файлов - тоже без особых проблем. есть как Beats, так и Logstash - оба идеологически верные, от самого эластика. Да и альтернатив немало. Вплоть до скрипта на питоне - впихивание в эластик дело не сложное.
сведение и поиск - в полный рост. быстрые диски(а лучше SSD) + обилие памяти и все будет летать.
ускорялки - при Ваших 4-5 мб в минуту ускорялки врядли понадобятся.
а вот о чем стоит подумать заранее - это что с какими полями вы собираетесь делать. А то сохранят размер файла как строку - а потом переживают, что поиск по меньше больше не работает. И про анализировать\не анализировать стоит подумать. Поиск по неанализированному полю ощутимо менне прожорлив - а значит быстрее
Ответ написан
al_gon
@al_gon
Вам без брокера сообщений нельзя. С растущими объемами рано или поздно "упадете на нос".

https://kafka.apache.org/ подходит для Ваших задач, как ничто лучше. И по объемам и по перформасу.

Здесь описан основной сценарий:
https://www.elastic.co/blog/just-enough-kafka-for-...

Если Вы хотите создать, что-то типа архива логов. То в данной схеме это лишь ещё один consumer.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы