Comments 25
Скопировал урл из первой строки лога, ввёл в поисковую строчку, ничего не нашлось :(
Вы не в курсе, можно ли запилить это так, чтобы люцен проиндексировал содержимое строчки лога? Масштабироваться, на сколько я знаю, он должен действительно неплохо.
«ввёл в поисковую строчку» — это имеется ввиду поисковая строка в Kibana или что-то другое?

Индексация всех данных и так присходит. При использовании grok фильтра (в моём примере), строка разбивается на блоки. Каждый блок имее название поля и данные этого поля. По любым полям можно осеществлять поиск.
Т.е. если в поиск в Kibana вписать @fields.request:*zip*, то должны появиться все строки, где в поле request присутствуют в любом месте буквы zip. По дефолту Kibana ищет в 15 последних минутах логов. Что бы найти отовсюду, в левом дропдауне надо выбрать «All Time».
Ага, туда. ОО, если вводить с модификатором @fields.request: и звёздочками — то работает! Не очень очевидно, но сойдёт. И со слешами какая-то беда. Надо будет попробовать залить в него мноооого логов.
За статью спасибо.

Я вот в свое время тоже был озадачен советом посмотреть на счет «индексатора» логов и вебприложения для их просмотра. Те задачи, которые я решал, когда просматривал логи (с помощью awk и еже с ним), мне казалось невозможным сделать через веб-морду в принципе. Ну т.е. грепнуть лог по какой-то ключевой фразе — это понятно и просто везде, и я еще не уверен где лучше смотреть результаты — в консоле с моноширинными шрифтами или в браузере, который будет еще и тормозить со всем красивостями при строках больше 1000.

А вот грепнуть, и посчитать частоту, или фильтровать и подсчитывать в реальном времени, опять же поискать и аггрегировать, — мне кажется очень проблематичным через вебморду.
Спасибо, за спасибо :)

У меня в тестовой базе ES около миллиона записей апаче логов. Поиск типа @fields.request:*mp3* во всех логах занимает около 3х секунд, это с учётом рисования графика и выдаёт около 6000 совпадений. Из найденных результатов скоринг по IP адресам занимает тоже пару секунд.
Я пока не видел особых тормозов у такой системы при 600-1000 reqs/sec и общем количестве данных почти пол миллиарда. Всё кончено зависит от железа. Много CPU & RAM значительно улучшают скорость.
Cluster Name
elasticcluster

Status green Nodes 3 Docs 3 053 513 952

Но я не использую logstash, он слишком медленный, не успевает за потоком логов. Пришлось кастомный python код писать самому используя pyes.
3 amazon x.large инстанса с 2Тb локального хранилища каждый.
Занято примерно процентов 60-70 дисков, то есть около 5Тб данных.
Никакого дублирования данных, чтобы получить максимальную скорость. Если инстанс умирает, теряем треть индекса, но логи архивируются на s3, так что всегда можно поднять архив, если что.
Хотел уточнить, что именно медленно? Доставка, парсинг или поиск?
Но что-то у Вас не так, размер нашего индекса 3012959708 документов (и это за 2 недели), работает на 2х серверах — поиск в реальном времени прекрасно работает. Возможно дело в EC2 и производительности, конечно.
На всякий случай уточню, какие параметры worker и batch у агента? JVM Heap на агенте / сервере?
Также я не могу поверить что python быстрее чем jruby, на какой реализации писали?
у меня 3 xlarge инстанса на ec2, все упирается в disk-IO к сожалению. я использую striped LVM над 4 дисками ephemeral storage.
Насколько я понял, проблема не в языке jruby или python. Проблема в реализации, так как logstash тратил ресурсы и время на обработку входящих данных по TCP. Когда я тестировал, производительности не хватало. Я использовал rsync для транспорта данных и python+pyes c мультипроцессингом docs.python.org/2/library/multiprocessing.html для закачки логов в elasticsearch.

Я недавно видел в действии реализацию flume+elasticsearch. Мне очень понравилось. Если у меня будет достаточно времени — буду переходить на него.
То есть узкое место при чтении логов на клиенте? Или при обработке на стороне парсера?
Я хочу помочь, так-как возможно что-то упущено. Logstash показал себя как очень умереный к ресурсам продукт, и тем более (по логике) должен быть шустрее решений на python (ничего против не имею, просто имхо).
Какой у Вас Setup? Centrallized? Расскажите побольше о схеме доставки и обработке логов которую Вы пробовали.
Все достаточно прямолинейно.
У меня логи переливаются с серверов на центральный rsync сервер и там парсер на питоне их распарсивает и заливает их в elasticsearch. Парсер стартует по крону каждую минуту и заливает файлы начиная с самых свежих. То есть если логов много, когда активность юзеров выше — теоретически парсер может не успевать. Но это не проблема, так как в более спокойное время он подтягивает старые логи. Получается никакой потери логов даже под высокой нагрузкой.
Я хотел уточнить по поводу конфигурации когда logstash работал медленно, после чего Вы решили использовать свое решение.
Я использую logstash (agent) => redis => logstash (master) => elasticsearch, таким образом redis работает как буфер, и если сравнивать с Вашим решением — сильно минимизирует io (у Вас rsync (read io) => rsync (write io) => python (read io) => elastic search (write io). Выходит в версии с logstash->redis->logstash->elasticsearch disk io уменьшено как минимум на 2 раза.
Я пытался использовать logstash вместе с rsyslog, чтобы syslog сразу пересылать по сети в logstash, так как он на серверах уже есть и мы его используем достаточно тесно с zabbix.
Не хотелось деплоить агентов logstash вместе с java на сервера, где джава совсем не нужна.
Да, деплоить джаву где она не нужна — это резонная причина, полностью согласен (хотя фактически это особенно ничего не меняет, у меня агенты на windows серверах, и ничего — 150Mb памяти — все что нам нужно :)).

Возможно тогда интерес вызовут другие шипперы, например beaver.

Logstash действительно хорош, когда дело доходит до обработки и парсинга данных (которые можно шипить чем угодно).
извиняюсь за оффтопик.
Чем вы деплоите на видновс сервера? Какую автоматизацию используете?
Если речь идет о logstash — то я создал пакет logstash в репозитории chocolatey, и вся автоматизация сводится к установке пакета. Я использую puppet и ресурс package.
Вот статья на тему использования пакетов chocolatey. Там, кстати, рассматривается пакет logstash в качестве примера.
А как деплоить — это уже решать Вам, можно все упростить до:

cinst logstash

Также буду рад ответить на вопросы и выслушать предложения.
Очень похоже на Graylog2, они также на ElasticSearch перевели хранение самих логов.
Да есть немного похожего, правда graylog2 потяжелее будет.
Проблема последних версий GL2 — у них всего один индекс под логи. При больших объёмах это заметно влияет на тормоза системы. Да и по мелочи там ещё много недоделок — например использование regex в стримах в дополнительных полях.
Да уж грейлог оказал весьма прожорлив:( Сейчас как раз подумываю об альтернативе и замене его.
Спасибо за заметку, исправил.

У Logstash есть 2 типа файлов — monolithic и flatjar. Flatjar немного по другому запакован и он значительно быстрее готов к работе после запуска.

По поводу ES. Я всегда использовал сторонний Elasticsearch, так как на нём ещё бегают некоторые мне необходимые вещи.
Надо будет попробовать на досуге встроенную версию ES.

Ещё у разработчиков Logstash есть идея сделать Kibana уже вшитой в код, что бы веб-интерфейс был всё таки поудобнее того, что сейчас есть в Logstash'е.
Eще немного позанудствую. Logstash написан на Ruby и обернут в java. Т.е. используется JRuby. На сайте вроде на нашел прямого упоминания про это, но в видео с презентации на PuppetConf об этом говорится.
Only those users with full accounts are able to leave comments. Log in, please.