Комментарии 41
А что за странный язык? Есть археологи в посте?
Серверная часть на Perl
А красивенько получилось. Докрутить бы еще плавный сдвиг графиков с прорисовочкой линий, чтобы не так дергано было — вот это красотень была бы :)
Топик добра…
Красиво, но вот только при достаточно серьезной нагрузке (количестве логов в секунду) все это дело довольно быстро скукожится.
На данный момент 106 серверов и кушаем не более 30% cpu
ну и плюс вы можете поставить несколько серверов которые будут обрабатывать логи
так вопрос в том — сколько логов в секунду сможет обработать один сервер.
на данный момент нагрузка примерно 2000 логов в секунду (106 серверов) 30% cpu в конфиге 15 толстых регулярок
Т.е. в среднем 20 записей в секунду генерит один сервер. Не так и много. Промышленные решения собирают до 100 000 записей в секунду на одно устройство.
Но для homebrew вполне хорошо.
Но для homebrew вполне хорошо.
Буду еще оптимизировать =)
Если 100 тыс. записей об ошибках в секунду, то это как-то совсем плохо, наверное
Есть реализация от facebook под названием scribe. Поможет легко, быстро, масштабируемо и отказоустойчиво собрать логи на Вашем статс-сервере с имеющихся нод. А сам парсер круто бы переписать на чём-то быстром, типа C — решение будет очень неплохим. Используем подобное в продакшне, отказались от регулярок и сравниваем строки, даже кривой первый ПХПшный парсер делает 3500/сек строк при удачном подборе размера файлов скрайба. На С всё гораздо быстрее, а передачей логов с нод скрайбом вообще можно пренебречь.
оно только собирает? Или же парсит тоже? Самое сложное как раз распарсить логи от разнородного ПО и железа, привести к общему формату, чтобы потом анализировать можно было. Ну, для примера, на одном МСЭ блокирующее действие оставляет запись DROP, на другом — DISCARD, на третьем DENY. И все это еще в разных форматах и по разным каналам (syslog, opsec, nfs, eventlog, etc.) А на лог-сервере все должно быть в общем виде, если мы строим график по заблокированным соединениям, например, то строить надо независимо от того, что именно было написано в логе и как мы его (лог) получили.
Не парсит оно, это отличный прозрачный транспорт, не более того. К тому же есть апи на куче языков для его использования, Вам же нужно придумать свой этот единый формат, и выбрать метод обработки:
1. Обрабатывать на ноде, с учётом специфики, приводя к единой схеме и слать в скрайб, на статс сервере же колбасить этот единый формат и отдавать в следующий слой, например построение графика.
2. Сыпать как есть в скрайб, и решать на стаст-сервере вопросы различного парсинга, форматирования и дальнейшей аггрегации/показа.
1. Обрабатывать на ноде, с учётом специфики, приводя к единой схеме и слать в скрайб, на статс сервере же колбасить этот единый формат и отдавать в следующий слой, например построение графика.
2. Сыпать как есть в скрайб, и решать на стаст-сервере вопросы различного парсинга, форматирования и дальнейшей аггрегации/показа.
ну, тогда скорости не интересны, просто транспорт упрется банально в сеть или диски.
Я же говорил про все вышесказанное, когда сказал про 100 000 в секунду, а не тупо передать.
Я же говорил про все вышесказанное, когда сказал про 100 000 в секунду, а не тупо передать.
Любой транспорт упрётся в сеть, речь ведь не об этом. Я предложил скрайб как хорошую систему передачи данных. Понятное дело, что реализацию обработки конкретных исключительных ситуаций Вам придётся делать самому, Вы не найдёте готовой системы, покрывающей все форматы устройств. Опять же, скрайб однозначно отвечает на вопросы, насколько легко добавить/убрать ноды, сменить ранг или приоритезацию. А также, что произойдёт если нода станет генерировать слишком много логов, успеет это всё отротейтиться? А не потеряете ли Вы важные данные в случае обрыва связи с одной из нод? А при падении статс-сервера? Что делать в исключительных ситуациях, куда бежать? В скрайбе это всё решено и конфигурируемо. Парсинг же — задача конкретного исполнения (не совсем общая задача), и Вам его нужно организовывать, желательно, отдельным слоем, желательно на чём-то быстром.
Меня не интересуют задачи, стоящие перед разработчиками/программистами. Я не программист. Но в деле log-management, особенно в его инкарнации в SIEM, разбираюсь очень даже неплохо (зарабатываю этим на жизнь, можно сказать), не надо мне ничего тут продавать, я сам могу продать готовые решения, которые не придется пилить с IDE и отладчиком )
И все эти «исключительные» ситуации не являются такими уж исключительными и страшными для известных мне готовых решений.
И все эти «исключительные» ситуации не являются такими уж исключительными и страшными для известных мне готовых решений.
какая разница, сколько серверов? Каждый может посылать 10 логов в минуту, так и 1000 можно поставить.
Сколько логов в секунду поступает — вот что интересно.
Сколько логов в секунду поступает — вот что интересно.
Чтоб избегать таких ситуаций нужно научить наш сервер обновлять конфиг на лету, что и сделано выше. Если нам пришла строчка которая начинается на 'reconfig', то, мы перегружаем конфиг. Ну и конечно же не забываем про wrapper который будет поднимать наш frenko_sender.pl во время падения.
Хочется взять и переписать на Erlang.
Но вообще очень круто. Многим симпатична идея реалтайм-отрисовки логов, но немногим приходит в голову просто взять и реализовать.
Нет ли желания еще и websockets прикрутить для большей реалтаймовости?
А, ну у вас же есть серьезный аргумент, затмевающий все плюшки эрланга.
Есть, но после оптимизации серверной части =)
Интересно послушать про аргумент, даже очень.
По факту, у самого антибот на erlang работающий по аналогичной схеме, регулярки там тоже есть с вебморды добавляются, для них мозиловский js прикручен, + полный разбор по кусочкам access логов + разная логика.
Количество логов аналогичное, кушает в 1 — 3 % от cpu на виртуалке с 1 cpu и гигом оперативы.
Хост система аналогична указанной в посте.
И да, при желании можно распараллелить на кластер из нескольких машин.
По факту, у самого антибот на erlang работающий по аналогичной схеме, регулярки там тоже есть с вебморды добавляются, для них мозиловский js прикручен, + полный разбор по кусочкам access логов + разная логика.
Количество логов аналогичное, кушает в 1 — 3 % от cpu на виртуалке с 1 cpu и гигом оперативы.
Хост система аналогична указанной в посте.
И да, при желании можно распараллелить на кластер из нескольких машин.
Тут кстати нужно подумать над тем как оптимизировать пробег =).У меня была похожая задача. Сделал так:
— Есть список регулярок
[re1, re2, re3, re4, re5, ..., reN]— приходит строчка лога и последовательно проверяется регулярками пока не заматчится. Например
re4— подошедшая регулярка перемещается в начало списка
[re4, re1, re2, re3, re5, ..., reN]— так что следующая строчка лога будет проверяться сперва этой регуляркой, потом остальными
Получается что редкие регулярки быстро сползают в конец а частые держатся ближе к началу. Если добавить еще какие-то веса, то можно еще улучшить характеристики.
Не сказал бы, что это сильно что-то ускорило, профайлер показал что это не самое узкое место. В итоге вместо Python запустил PyPi и получил 2x ускорение.
Единственное что — в Python хорошей структуры данных для такой работы не нашел. Хорошо подошел бы связный список…
Можно просто посмотреть все метрики на данный момент времени и отсортировать регулярки, их определяющие, в соответствующем порядке. И пересортировывать, скажем, раз в минуту.
Ещё вариант — в начало списка помещать подстроки (регулярки) для тех выражений лога, для которых нет метрик, но которые часто встречаются в логе — чтобы их отсеять сразу и не гонять регулярки зря (есть вероятность профукать часть статистики — нужно быть осторожным).
Ещё вариант — в начало списка помещать подстроки (регулярки) для тех выражений лога, для которых нет метрик, но которые часто встречаются в логе — чтобы их отсеять сразу и не гонять регулярки зря (есть вероятность профукать часть статистики — нужно быть осторожным).
Есть еще одно предложение по оптимизации. Никак не могу понять почему его никто не упомянул.
НЕ комилировать регулярки при каждом сравнении, а компилировать их лишь при чтении с конфига:
perldoc.perl.org/perlop.html#Regexp-Quote-Like-Operators
НЕ комилировать регулярки при каждом сравнении, а компилировать их лишь при чтении с конфига:
# $$re{$key}{re}=$regexp; - было.
$$re{$key}{re}=qr($regexp); # стало.
perldoc.perl.org/perlop.html#Regexp-Quote-Like-Operators
Спасибо, сделал, пару процентов снизил.
Не в качестве критики, но очень советую посмотреть на Splunk, real-time анализ практически любых логов с графиками, дашбордами, отчетами и п.р.
Не знаю что тут происходит но вот хорошая штука для отображение данных основанных на времени square.github.com/cubism/
Там даже две версии серверной части поддерживается.
Там даже две версии серверной части поддерживается.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Риалтайм дашборд