Нужен совет в выборе opensors сборки для сбора и обработки большого объема логов. На данный момент 11 windows серверов с веб-приложениями ASP.NET, 1 сервер в сутки дает порядка 6 гигов логов совокупно (2-3 приложения). Логи пишутся в файлы, файлы ротируются в зависимости от приложения от 100М до 1G на файл.
Система должна легко и прозрачно масштабироваться с минимальным даунаймом или без оного, кол-во серверов будет расти, так же будут добавлены linux сервера.
Логи планируем собирать именно из файлов, прямое перенаправление в систему сбора напрямую планируется, но в неопределенном будущем, поэтому на данный момент не актуально.
Аллерты по логам особо не нужны, заменять систему данной сборкой пытаться не будем. Основное требование, сведение логов по таймингу между машинами и приложениями и последующий отбор по ключам.
Нужен совет по сборке, с обоснованием преимуществ. Например ELK или graylog2, что лучше и почему, какие ускорилки можно использовать, на вроде rabbitrq?
Так же нужен совет по выбору оси и оптимальной конфе с которых можно начать тестирование.
как человек, сталкивавшийся с ELK
6Г в день - не страшно для ELK. Но готовьтесь к прожорливости по памяти. Всеж Java...
легкость масштабирования - в принципе да. Добавить ноду в кластер - дело минут. Синхронизация, правда, займет время. Но это везде так, данные "по волшебству" с ноды на ноду не перелетят.
собирать из файлов - тоже без особых проблем. есть как Beats, так и Logstash - оба идеологически верные, от самого эластика. Да и альтернатив немало. Вплоть до скрипта на питоне - впихивание в эластик дело не сложное.
сведение и поиск - в полный рост. быстрые диски(а лучше SSD) + обилие памяти и все будет летать.
ускорялки - при Ваших 4-5 мб в минуту ускорялки врядли понадобятся.
а вот о чем стоит подумать заранее - это что с какими полями вы собираетесь делать. А то сохранят размер файла как строку - а потом переживают, что поиск по меньше больше не работает. И про анализировать\не анализировать стоит подумать. Поиск по неанализированному полю ощутимо менне прожорлив - а значит быстрее
6 гигов один сервер, а их 11 штук и кол-во будет расти и это только web приложения, к ним еще буду добавляться службы на C++ и логи самих серверов.
От сколки гигов памяти надо начинать, что бы провести тестирование, для 6 гигов в день, что бы понять, как потом масштабировать по железу? И какую ОС использовать? Я склоняюсь к deb образным. Какую ось рекомендуют создатели ELK? Знаю, что greylog рекомендуют ubuntu ltc, не хочется выбрать любимую ось, и потом жрать кактус, колоться, но продолжать жрать.
Скрипты на питоне и прочий самопал не надо, надо best practice и главное побольше обоснования и сравнения.
Сведение и поиск это главное, и хочется это делать через веб морду, и тут вопрос, хороша ли кибана, и какие альтернативы того же уровня готовности, желательно с аргументами.
Может быть по анализированному полю быстрее все же? Или я чего то не понимаю?
Ускорялки, балансировщики и кластеризацию хочется предусмотреть на этапе проектирования тестов, что бы потом не кусать локти, когда будет 600 гигов в день логов.
Кстати, есть какие то решения по долгосрочному хранению истории логов с возможностью может и более длительной выборки, но все же с возможностью?
DizZa: ок, с объемом хранения понятно. емкость дисков можете посчитать сами, для верности умножте на 2 =). и лучше SSD. Что до памяти и количества нод, то тут многое будет зависеть от того что и как будете искать. Если просто поиск "руками" по каким-то полям, без агрегаций/среднего/уникальности и поиска по всему объему разом - то больших проблем не вижу. По моим ощущениям все хорошо пока индекс влезает в HEAP_SIZE. Делайте отдельный индекс по дням, сделайте несколько нод.
что до "аналировать-не анализировать" - то все просто. Это как поиск по LIKE и по =. Если Вас устраивает поиск по "только точному соответствию" - не анализируйте (пример - тип события в логе). Если планируете искать по части строки - анализируйте. Анализаторов, к слову, несколько.
DizZa: вот что не расскажут - то не расскажу. Знаю, что анализаторов несколько (https://www.elastic.co/guide/en/elasticsearch/refe..., а вот использовал я только либо дефолтный, либо никакой. Логсташ тут не причем, он только данные парсит(бьет на поля, может установить тип, модифицировать данные и т.д.) и запихивает в эластик.
Что такое "FULL TEXT INDEX" в MySQL представляете себе? Вот анализатор - аналог.
Макс: похоже вы не про то - Whitespace Analyzer
The whitespace analyzer divides text into terms whenever it encounters any whitespace character. It does not lowercase terms.
Насколько я понимаю, анализатор, это как раз разбивка. Или я вообще не понимаю тогда.
DizZa: ох...
предположим, у Вас есть текстовый лог. к примеру, классика - дата-время-источник-сообщение. разделитель - табуляция. с первыми тремя полями все понятно, это отдельные сущьности, их надо затянуть в отдельные поля. сообщение - штука сложная. там может быть от надписи "ок" до первого тома "Война и мир" (утрирую конечно, но сообщение о ошибке java бывают большими. очень. и многстрочными).
так вот - задача логсташа такую запись (это может быть как 1, так и до-фига-строк) разбить на отдельные дату-время-источник-сообщение и отдать в эластик. Эластик ЭТО возьмет, и в зависимости от настроек как-то сохранит. вот поле "источник", к примеру, логичнее всего хранить как 1 слово, искать по первой букве этого слова вы будете маловероятно. А вот сообщене надо анализировать (считайте - построить индекс по этому полю). и в таком случае Вы потом сможете искать по любой части строки.
подводя итог. совет. Вы планируете ввязаться в непростое дело. у Эластика есть неприятная особенность - если в начале накосячить с индексом (мэппингом, анализаторами), потом исправляется это только переиндексацией. что хлопотно и затратно. Поищите кого-то, кто уже делал подобные вещи и наймите. собрать с вас ваши хотелки и грамотно запустить процесс - дело не самое сложное. сэкономите и время и нервы.
