Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 71
Из вариантов попроще — это использование Splunk habrahabr.ru/search/?q=splunk (про mysql тоже писали habrahabr.ru/post/178175/)
P.S. Я работаю в Splunk
P.S. Я работаю в Splunk
Да, но вы не упоянули стоимость Splunk.
У Splunk есть бесплатная версия с ограничением 500 мегабайт в сутки индексируемых данных (ограничений на количество хранимой информации нет) www.splunk.com/view/SP-CAAAE8W Предполагаю, что многим этого может хватить.
Раз работаете, то рост решений на Elasticsearch+Logstash+Kibana сильно вас коснулись?
Лично меня нет :)
А насчет компании, если посмотреть на последний отчет investors.splunk.com/releasedetail.cfm?ReleaseID=809039
Но никаких домыслов по поводу того, зависит ли эта цифра от Logstash, у меня нет.
А насчет компании, если посмотреть на последний отчет investors.splunk.com/releasedetail.cfm?ReleaseID=809039
Signed more than 450 new customers, ending the quarter with more than 6,400 customers worldwide."
Но никаких домыслов по поводу того, зависит ли эта цифра от Logstash, у меня нет.
для Спланка нужен свой клиент и сервер, тут же в качестве клиента выступает обыкновенный rsyslog (который во многих дистрах установлен по дефолту). Плюс Спланк написан на джаве, а она иногда живет «своей жизнью»: не смотрит ни на какие ограничения и тд.
> для Спланка нужен свой клиент и сервер, тут же в качестве клиента выступает обыкновенный rsyslog
Splunk умеет импортировать со всего чего только можно, а так же слушать на tcp (http://docs.splunk.com/Documentation/Splunk/latest/Data/SyslogTCP) или udp (http://docs.splunk.com/Documentation/Splunk/latest/Data/SyslogUDP) портах
> Плюс Спланк написан на джаве
Java? Вы шутите? Откуда это? :) Все что нас связывает с Java — это SDK для Java и плагин для Eclipse. Индексер написан на C++, web морда на python.
Splunk умеет импортировать со всего чего только можно, а так же слушать на tcp (http://docs.splunk.com/Documentation/Splunk/latest/Data/SyslogTCP) или udp (http://docs.splunk.com/Documentation/Splunk/latest/Data/SyslogUDP) портах
> Плюс Спланк написан на джаве
Java? Вы шутите? Откуда это? :) Все что нас связывает с Java — это SDK для Java и плагин для Eclipse. Индексер написан на C++, web морда на python.
Всё это хорошо только в пределах локальной сети.
Если слушать внешний интерфейс — то любой злодей может на порт rsyslog'а который хранит логи что угодно заслать.
Если слушать внешний интерфейс — то любой злодей может на порт rsyslog'а который хранит логи что угодно заслать.
именно потому придуман iptables или можно указать разрешенные хосты в самом конфиге rsyslog.
Если не гора к Магомету… Может, тогда построить VPN любого удобного Вам вида, и гонять данные таки уже внутри вашей сети?
Через паблик слать логи, какие бы брандмауэры не стояли на входе в лог-сервер, не комильфо: перехват трафика от этого не усложнится (усложнится задача насыпать Вам в лог левых данных, да и то, подменить обратный адрес пакетов особо не сложно) а в этом трафике может быть много того, что бы Вы не хотели светить — пароли, хеши, адреса.
Через паблик слать логи, какие бы брандмауэры не стояли на входе в лог-сервер, не комильфо: перехват трафика от этого не усложнится (усложнится задача насыпать Вам в лог левых данных, да и то, подменить обратный адрес пакетов особо не сложно) а в этом трафике может быть много того, что бы Вы не хотели светить — пароли, хеши, адреса.
Суть в том, что прежде чем подменить IP адрес, надо знать адрес получателя, порт и что вообще там есть что-то подобное.
Промолчать о таких вещах в статье на хабре — не комильфо. Разрешить подключения на этот порт только для «избранных» IP-адресов — имхо, необходимый минимум защиты.
Промолчать о таких вещах в статье на хабре — не комильфо. Разрешить подключения на этот порт только для «избранных» IP-адресов — имхо, необходимый минимум защиты.
Ну, если мы с Вами пересылаемый через паблик трафик перехватили (а это делается элементарно на современном-то оборудовании; притом syslog не шифрует сообщения и вообще никак их содержимое не защищает), наверное, и подделать пакеты ничего не стоит.
Но подделка — это не всегда самое актуальное. Куда неприятнее может быть перехват. Представим себе (утрирую схему!!!): Вы, скажем, будете отлаживать свое веб-приложение, и с www-сервера (на хостинге) на свой dev-сервер (который в офисе, рядом, в локалке) возьметесь пересылать логи приложений, а в логах будут логины и пароли пользователей веб-приложения. Я, изобразив злобного хаЦкера, заполучу копию ваших логов, перехватив этот трафик по пути от www-сервера до dev-сервера, и спокойно себе соберу базу паролей.
Потому про VPN и говорю. Сделайте лучше на вашем каналообразующем оборудовании/ПО туннель шифрованный от www до dev, и уже в нем гоните логи. А брандмауэром зажимайте, чтобы «внешний» трафик туннеля приходил на конкретный хост только с «правильных» точек, это точно не помешает. Ну и конечно, уже внутри локалки фильтровать трафик тоже не помешает.
Но подделка — это не всегда самое актуальное. Куда неприятнее может быть перехват. Представим себе (утрирую схему!!!): Вы, скажем, будете отлаживать свое веб-приложение, и с www-сервера (на хостинге) на свой dev-сервер (который в офисе, рядом, в локалке) возьметесь пересылать логи приложений, а в логах будут логины и пароли пользователей веб-приложения. Я, изобразив злобного хаЦкера, заполучу копию ваших логов, перехватив этот трафик по пути от www-сервера до dev-сервера, и спокойно себе соберу базу паролей.
Потому про VPN и говорю. Сделайте лучше на вашем каналообразующем оборудовании/ПО туннель шифрованный от www до dev, и уже в нем гоните логи. А брандмауэром зажимайте, чтобы «внешний» трафик туннеля приходил на конкретный хост только с «правильных» точек, это точно не помешает. Ну и конечно, уже внутри локалки фильтровать трафик тоже не помешает.
[sarcasm]Кому-то надо подтянуть теорию IP-сетей. Расскажите мне, как вы будете собирать трафик с моего сервера, скажем, в германии?[/sarcasm].
Я не понимаю, что Вы ко мне прицепились? :) В статье про безопасность ни слова. Более того, даже не написано, что никакой аутентификации в таком решении нет, и любой желающий может забить левыми логами весь сервер. Собственно на это я намекнул, и сказал, что как минимум должен быть настроен iptables соответствующим образом.
А вообще, при желании, можно выдумать и не только VPN, было бы желание ;)
Я не понимаю, что Вы ко мне прицепились? :) В статье про безопасность ни слова. Более того, даже не написано, что никакой аутентификации в таком решении нет, и любой желающий может забить левыми логами весь сервер. Собственно на это я намекнул, и сказал, что как минимум должен быть настроен iptables соответствующим образом.
А вообще, при желании, можно выдумать и не только VPN, было бы желание ;)
Как в том анекдоте, «ты мне еще скажи, что я ей между страниц заглядываю».
Здесь статья класса howto, о том, как установить пару программ на Ubuntu. Причем ничего суперсложного нет, для того aptitude и есть, и даже вопросы можно просто в диалоговых окнах вписать (по сути, статья не для Хабра, хотя, конечно, это мое мнение). Я написал на ваше мнение про iptables, что файрволл не решит вопрос ни левых вбросов в логи, ни от перехвата (потенциально непубличного) трафика. Как-то так.
Но вообще конечно поставим смайлики, и оставим и howto, и теории заговора )))
Здесь статья класса howto, о том, как установить пару программ на Ubuntu. Причем ничего суперсложного нет, для того aptitude и есть, и даже вопросы можно просто в диалоговых окнах вписать (по сути, статья не для Хабра, хотя, конечно, это мое мнение). Я написал на ваше мнение про iptables, что файрволл не решит вопрос ни левых вбросов в логи, ни от перехвата (потенциально непубличного) трафика. Как-то так.
Но вообще конечно поставим смайлики, и оставим и howto, и теории заговора )))
Хабр — очень популярный ресурс. При поиске, новичок скорее всего наткнётся именно на эту статью, и сделает по ней. Следовательно, сделает дыру в безопасности, а потом будет ломать голову как же так вышло. Новичку, надо сразу сказать обо всех подводных камнях, и способах решения. Иначе никакого смысла в этой статье нет. Не надо думать, что «новичок» сам всё знает, найдёт и сделает.
Никаких теорий заговора. Я знаю людей, которые уже об эти грабли спотыкались.
Небольшой ликбез:
— Правильно настроенный iptables решит эту проблему. Никакого шифрованного туннеля не нужно. Для этой задачи это излишне.
— Чтобы собрать трафик с сервера, надо как минимум оказаться с ним в одном широковещательном домене (читай подключиться в один коммутатор/роутер с ним). Я уже не говорю о том, что если он правильно настроен то это всё равно бесполезно. Если Вы допустили такое, то, простите, Вы сам себе злобный Бурратино. :)
Никаких теорий заговора. Я знаю людей, которые уже об эти грабли спотыкались.
Небольшой ликбез:
— Правильно настроенный iptables решит эту проблему. Никакого шифрованного туннеля не нужно. Для этой задачи это излишне.
— Чтобы собрать трафик с сервера, надо как минимум оказаться с ним в одном широковещательном домене (читай подключиться в один коммутатор/роутер с ним). Я уже не говорю о том, что если он правильно настроен то это всё равно бесполезно. Если Вы допустили такое, то, простите, Вы сам себе злобный Бурратино. :)
Много ли серверов окажется в одном широковещательном домене на каком-нибудь Амазоне, Хетцнере и т. п.? Много ли новичков будут арендовать VDS/DS, а не настраивать своё оборудование в своей стойке?
Даже на очень бюджетных DES1228ME можно настроить защиту от подобного рода атак. Вы серьёзно такое допускаете? Если малоизвестный хостер то, конечно, такое возможно, но тут опять же — «сами себе злобные Бурратины».
Я не хостер и не админ, а разработчик. Так что вопрос про «допускаете» явно не по адресу.
Я вполне допускаю, что у значительной пачки хостеров, как минимум, реально кинуть udp-пакет обернутый ip с некорректным src-адресом.
Я вполне допускаю, что у значительной пачки хостеров, как минимум, реально кинуть udp-пакет обернутый ip с некорректным src-адресом.
Я вполне допускаю, что у значительной пачки хостеров, как минимум, реально кинуть udp-пакет обернутый ip с некорректным src-адресом.
Правильно настроенный firewall решает эту проблему.
Вот о правильной настройке и хочется услышать.
Допустим, rsyslogd/graylogd/whatever слушает 10.0.0.1:514 и принимает данные с 10.0.0.2 и 10.0.0.3. Рассмотрим 2 варианта:
1. Evil host 10.1.0.1, стоящий в той же стойке, отправляет udp пакет с ip.src=10.0.0.2 на 10.0.0.1:514.
2. Evil host 10.1.0.1, стоящий на расстоянии 1 L3-маршрутизатора, отправляет udp пакет с ip.src=10.0.0.2 на 10.0.0.1:514.
Что должно быть настроено на фаейрволе 10.0.0.1, чтобы избежать записи этого нелегитимного пакета в лог?
Допустим, rsyslogd/graylogd/whatever слушает 10.0.0.1:514 и принимает данные с 10.0.0.2 и 10.0.0.3. Рассмотрим 2 варианта:
1. Evil host 10.1.0.1, стоящий в той же стойке, отправляет udp пакет с ip.src=10.0.0.2 на 10.0.0.1:514.
2. Evil host 10.1.0.1, стоящий на расстоянии 1 L3-маршрутизатора, отправляет udp пакет с ip.src=10.0.0.2 на 10.0.0.1:514.
Что должно быть настроено на фаейрволе 10.0.0.1, чтобы избежать записи этого нелегитимного пакета в лог?
Собственно, объясните чего Вы пытаетесь добиться ввергая меня в бессмысленный спор? Если Вы разработчик, занимайтесь своей работой, а администрирование оставьте людям которые в этом что-то понимают.
Правильная настройка — это не пара строк, а большой багаж знаний «зачем и почему нужно делать именно так». Я Вам её рассказывать не буду. Если Вам нужно — ищите, читайте.
Попробую вкратце.
Ответьте себе для начала на вопрос: «почему ПК с linux на борту должен что-то делать с пакетом, который ему не предназначен?».
Далее, даже если предположим, что зачем-то используется такая широкая маска (а при такой маске в широковещательном домене получается ~131072 хоста, и так никто в здравом уме не делает) для одного широковещательного домена и компьютер подконтрольную взломщику находится в одном широковещательном домене, то это уже совершенно другой аспект со своими заморочками (коллизии, баги прошивки, неправильная настройка, косяки при проектирование ASIC и/или CPU в коммутаторах/роутерах). В современных коммутаторах/L3 коммутаторах/роутерах есть средства защиты от подавляющего большинства подобных атак. Если они криво настроенны, то я повторюсь — «Вы сами себе злобный Бурратино», и остаётся надеяться на то, что взломщик по каким-то причинам не заметит, или не знает что с этим делать, но такой вариант маловероятен.
Касательно iptables. Опустим остальное, оставим только необходимое:
Правильная настройка — это не пара строк, а большой багаж знаний «зачем и почему нужно делать именно так». Я Вам её рассказывать не буду. Если Вам нужно — ищите, читайте.
Попробую вкратце.
Ответьте себе для начала на вопрос: «почему ПК с linux на борту должен что-то делать с пакетом, который ему не предназначен?».
Далее, даже если предположим, что зачем-то используется такая широкая маска (а при такой маске в широковещательном домене получается ~131072 хоста, и так никто в здравом уме не делает) для одного широковещательного домена и компьютер подконтрольную взломщику находится в одном широковещательном домене, то это уже совершенно другой аспект со своими заморочками (коллизии, баги прошивки, неправильная настройка, косяки при проектирование ASIC и/или CPU в коммутаторах/роутерах). В современных коммутаторах/L3 коммутаторах/роутерах есть средства защиты от подавляющего большинства подобных атак. Если они криво настроенны, то я повторюсь — «Вы сами себе злобный Бурратино», и остаётся надеяться на то, что взломщик по каким-то причинам не заметит, или не знает что с этим делать, но такой вариант маловероятен.
Касательно iptables. Опустим остальное, оставим только необходимое:
iptables -F
iptables -X
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -i lo -p all -j ACCEPT
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A OUTPUT -m state --state INVALID -j DROP
iptables -A INPUT -s 10.0.0.2 -p tcp -m tcp --dport 514 -j ACCEPT
iptables -A INPUT -s 10.0.0.3 -p tcp -m tcp --dport 514 -j ACCEPT
iptables -A INPUT -j DROP
Я просто замечу, что термин «широковещательный домен» говорит не о сетевом уровне, а о канальном, потому об IP-адресах вообще вести речь некорректно. Злоумышленник отравит ARP-кэш и заставит считать вас роутером/syslog-сервером его, даже не имея IP-адреса вообще и слушая raw-сокет.
Однако, с тем, что тема защиты от подделки и перехвата трафика сильно выходит за рамки статьи, полностью с вами соглассен.
Однако, с тем, что тема защиты от подделки и перехвата трафика сильно выходит за рамки статьи, полностью с вами соглассен.
«Авторитетно» заявлять, что фаейрвола достаточно можно имея на то какие-нибудь основания кроме понтов в стиле «администрирование оставьте людям которые в этом что-то понимают».
Я задал простой вопрос и привел простую конфигурацию в которой ваши настройки файервола идут лесом.
Во-первых, широковещательный домен, как iavael сказал ниже, — понятие L2. IP адреса хостов могут быть любыми, это L3.
В описанной мной конфигурации атакующий хост (10.1.0.1) отправляет пакет с ip.dst = 10.0.0.1, ip.src = 10.0.0.2 и udp.dstport = 514.
И становится невозможно различить два варианта:
— 10.1.0.1 — роутер и просто смаршрутизировал пакет от 10.0.0.2;
— 10.1.0.1 — атакующих хост и сфабриковал пакет.
В данную дискуссию я влез после вашего заявления
Я задал простой вопрос и привел простую конфигурацию в которой ваши настройки файервола идут лесом.
Во-первых, широковещательный домен, как iavael сказал ниже, — понятие L2. IP адреса хостов могут быть любыми, это L3.
В описанной мной конфигурации атакующий хост (10.1.0.1) отправляет пакет с ip.dst = 10.0.0.1, ip.src = 10.0.0.2 и udp.dstport = 514.
И становится невозможно различить два варианта:
— 10.1.0.1 — роутер и просто смаршрутизировал пакет от 10.0.0.2;
— 10.1.0.1 — атакующих хост и сфабриковал пакет.
В данную дискуссию я влез после вашего заявления
Правильно настроенный iptables решит эту проблему. Никакого шифрованного туннеля не нужно. Для этой задачи это излишне.которое выглядит не соответствующим действительности.
Вообще, то, что bosha ошибся с широковещательным доменом, скорее говорит в пользу аргумента «администрирование оставьте людям которые в этом что-то понимают». Тема безопасности действительно не относится к основной теме статьи.
Вообще-то, я не ошибся, а использовал словосочетание «широковещательный домен» совершенно верно. Вам даже русскоязычная википедия подсказывает, что оно применимо к 3-ему уровню модели OSi с некоторыми оговорками.
Более того, я никак в своём комментарии не связывал эти два понятия.
Иными словами — Вы дважды неправы.
Более того, я никак в своём комментарии не связывал эти два понятия.
Иными словами — Вы дважды неправы.
iavael неправ, и крайне невнимателен. Оставьте его в покое.
Вы, к сожалению, так же немного неправы ввиду невнимательности при прочтении: я никак не связывал защиту средствами iptables и случаи, когда у взломщика есть возможность сделать описанное Вами.
По поводу Вашего примера — тут Вы совершенно правы. Я невнимательно его прочитал, и соответственно ответил. Такая атака получится. Извиняюсь за невнимательность. Однако я повторюсь, что никак не связывал защиту средствами iptables и подобные атаки.
Вы, к сожалению, так же немного неправы ввиду невнимательности при прочтении: я никак не связывал защиту средствами iptables и случаи, когда у взломщика есть возможность сделать описанное Вами.
По поводу Вашего примера — тут Вы совершенно правы. Я невнимательно его прочитал, и соответственно ответил. Такая атака получится. Извиняюсь за невнимательность. Однако я повторюсь, что никак не связывал защиту средствами iptables и подобные атаки.
А зачем дополнительное правило DROP, если политика для цепочки INPUT уже в DROP установлена?
>Здесь статья класса howto, о том, как установить пару программ на Ubuntu. Причем ничего суперсложного нет, для того aptitude и есть, и даже вопросы можно просто в диалоговых окнах вписать (по сути, статья не для Хабра, хотя, конечно, это мое мнение)
Если бы я начал компилировать и половину статьи упустил — статья была бы более професиональной, т.к. было бы ничего не понятно?
2bosha: Вопрос защиты и настройки фаервола — это другая статья.
Если бы я начал компилировать и половину статьи упустил — статья была бы более професиональной, т.к. было бы ничего не понятно?
2bosha: Вопрос защиты и настройки фаервола — это другая статья.
Rsyslog умеет TLS
Какое-то непродолжительное время мы тоже использовали связку rsyslog+mysql+LogAnalyzer и в итоге оказались от неё в пользу rsyslog+logstash+elasticsearch+kibana.
Причины собственно две:
1. В LogAnalyzer уууужасный web-интерфейс. Это по-моему что-то даже более доисторическое, чем web 1.0. А ещё очень сильно раздражает popup, который всплывает на каждую строку лога в листинге.
2. MySQL из коробки банально не справляется при большом количестве логов и хитрой выборке данных. То есть банальный листинг и pagination всех имеющихся логов конечно не тормозит, но вот если надо выбрать например только логи nginx-а и только за определённый период времени, и только те, где встречается определенный user-agent, то тут и начинаются проблемы.
Связка rsyslog+logstash+elasticsearch+kibana решила эти две проблемы.
1. Logstash позволяет осуществлять парсинг и нормализацию логов. При помощи фильтров можно выдрать из логов по определенному шаблону конкретные кастомные значения для того, чтобы в дальнейшем добавить их в поисковый индекс.
2. Kibana няшка demo.kibana.org/, даст 100 очков форы LogAnalyzer-у
3. Elasticsearch — поисковый сервер на основе Apache Lucene. Масштабируемый из коробки. Одна из частных задач, которую он решает вкупе с logstash — организация хранения логов
Причины собственно две:
1. В LogAnalyzer уууужасный web-интерфейс. Это по-моему что-то даже более доисторическое, чем web 1.0. А ещё очень сильно раздражает popup, который всплывает на каждую строку лога в листинге.
2. MySQL из коробки банально не справляется при большом количестве логов и хитрой выборке данных. То есть банальный листинг и pagination всех имеющихся логов конечно не тормозит, но вот если надо выбрать например только логи nginx-а и только за определённый период времени, и только те, где встречается определенный user-agent, то тут и начинаются проблемы.
Связка rsyslog+logstash+elasticsearch+kibana решила эти две проблемы.
1. Logstash позволяет осуществлять парсинг и нормализацию логов. При помощи фильтров можно выдрать из логов по определенному шаблону конкретные кастомные значения для того, чтобы в дальнейшем добавить их в поисковый индекс.
2. Kibana няшка demo.kibana.org/, даст 100 очков форы LogAnalyzer-у
3. Elasticsearch — поисковый сервер на основе Apache Lucene. Масштабируемый из коробки. Одна из частных задач, которую он решает вкупе с logstash — организация хранения логов
Недавно настроили связку rsyslog+mysql+LogAnalyzer, вроде бы всё работает, но пункт №1, указанный у вас, уже бесит. Пока завели около 10ка хостов. Судя по вашему опыту нас ждёт и пункт №2.
Вы по какому-то мануалу настраивали связку rsyslog+logstash+elasticsearch+kibana или по наитию? Думаю тоже попробовать сразу хорошее, чтобы не ходить по граблям.
Вы по какому-то мануалу настраивали связку rsyslog+logstash+elasticsearch+kibana или по наитию? Думаю тоже попробовать сразу хорошее, чтобы не ходить по граблям.
Настраивали в основном по официальной документации logstash.net/docs/1.3.3/ и плюс немного по статьям с хабра
Согласен, LogAnalyzer страшненький, но зато работает неплохо. Как хранилище логов можно использовать и MongoDB, где поиск должен работать быстрее. В любом случае если инфраструктура большая — сервер нужно использовать с хорошим, мощным железом.
По поводу mongodb для хранения логов: когда на одном из предыдущих мест работы в одном из проектов перестал устраивать greylog и начали его переписывать, на одном из этапов пришлось перестать хранить данные в монге из-за ее низкой производительности и перейти на постгрес.
Этот пример, конечно, совершенно не обязан что-то значить по отношению ко всем случаям использования системы хранения логов, но, все-таки, рассужения «а давайте вкатим монгу, она быстро работает» далеко не всегда правильны.
Этот пример, конечно, совершенно не обязан что-то значить по отношению ко всем случаям использования системы хранения логов, но, все-таки, рассужения «а давайте вкатим монгу, она быстро работает» далеко не всегда правильны.
На самом деле MongoDB в случае LogAnalyzer позиционируется как альтернативное хранилище данных, а не как хранилище, которое даст improvement производительности. То есть по принципу «Вот у нас в проекте одна монга — зачем нам ещё MySQL? Коль уж используем монгу, то давайте и логи туда складировать.»
Объясняю основную причину, почему нас не устроил ни MySQL, ни MongoDB. Вот у нас есть, скажем, логи от сервера приложений, и разработчики обязуются слать логи в формате JSON, проталкивая при этом параметр user_id в каждом из логов. Благодаря этому мы сможем легко и непринужденно получить информацию об активности пользователя за прошедшее время. А такое зачастую очень даже надо. Например в случае багфикса. Так вот, в принципе в LogAnalyzer можно задавать кастомные поля для выборки логов, но так, как это так реализовано, нам показалось далеко не юзер-френдли. То ли дело в logstash, где данная задача решается на уровне встроенных фильтров. А если искать значение тупо по регулярке по телу message-а, то насколько я понимаю на уровне базы данных делается что-то на подобии Full-Text Search, и база просто настолько долго делает скан, что веб-интерфейс не дождавшись ответа умирает с ошибкой. И тут дело не в MySQL или MongoDB, тут скорее вопрос, идет запрос в индекс или нет.
Объясняю основную причину, почему нас не устроил ни MySQL, ни MongoDB. Вот у нас есть, скажем, логи от сервера приложений, и разработчики обязуются слать логи в формате JSON, проталкивая при этом параметр user_id в каждом из логов. Благодаря этому мы сможем легко и непринужденно получить информацию об активности пользователя за прошедшее время. А такое зачастую очень даже надо. Например в случае багфикса. Так вот, в принципе в LogAnalyzer можно задавать кастомные поля для выборки логов, но так, как это так реализовано, нам показалось далеко не юзер-френдли. То ли дело в logstash, где данная задача решается на уровне встроенных фильтров. А если искать значение тупо по регулярке по телу message-а, то насколько я понимаю на уровне базы данных делается что-то на подобии Full-Text Search, и база просто настолько долго делает скан, что веб-интерфейс не дождавшись ответа умирает с ошибкой. И тут дело не в MySQL или MongoDB, тут скорее вопрос, идет запрос в индекс или нет.
А если искать значение тупо по регулярке по телу message-а, то насколько я понимаю на уровне базы данных делается что-то на подобии Full-Text SearchЭто называет full table scan, а не full text search =)
Я имел ввиду именно что полнотекстовый поиск. Но это лишь предположение — я не копался во внутренностях, поэтому не могу сказать ничего конкретного. Может быть там делается полнотекстовый поиск, а может быть просто что-то на подобии like %...%. В любом случае если не выносить искомые значения в кастомные предопределенные поля, то «сложный» поиск по телу сообщения при больших объемах логов будет работать медленно — у нас по крайне мере так было
Тогда какие регулярки? Префиксный или суффиксный — может по индексу делаться.
Так-то полнотекст работает быстро: по базе в 100М документов по 2-3 кб в среднем — меньше 100 мс на lucene/solr. SQL like работает помедленнее, естественно, и не поддерживает нормализацию и т. п.
Так что проблема только в реализации.
Так-то полнотекст работает быстро: по базе в 100М документов по 2-3 кб в среднем — меньше 100 мс на lucene/solr. SQL like работает помедленнее, естественно, и не поддерживает нормализацию и т. п.
Так что проблема только в реализации.
>А ещё очень сильно раздражает popup, который всплывает на каждую строку лога в листинге.
такое поведение можно отключить в настройках LogAnalyzer-а.
такое поведение можно отключить в настройках LogAnalyzer-а.
Стоит упомянуть, что при большом объеме данных, допустим как у меня
Enable Row Counting чтобы не использовалась функция SQL_CALC_FOUND_ROWS. Иначе у вас интерфейс будет еле ползать, Так же можно добавить индекс на FromHost
mysql> select count(*) from SystemEvents;
+----------+
| count(*) |
+----------+
| 82625385 |
+----------+
Enable Row Counting чтобы не использовалась функция SQL_CALC_FOUND_ROWS. Иначе у вас интерфейс будет еле ползать, Так же можно добавить индекс на FromHost
Интрересно, а разработчики в курсе таких дел? А то получается очивидные вещи отсутсвуют в базовой комплектации ПО.
Думаю да, но нигде у них в документации этого не сказано, когда у меня объемы выросли, мне пришлось искать решение, так как собирать плагин для mongo было неохота, решил поискать решения, честно было несказанное удивление когда увидел, что используется SQL_CALC_FOUND_ROWS. Не хочу сказать что функция ужасная или плохая, ее применения обосновано, при маленьких объемах
К примеру:
Как видно, этот запрос мягко говоря медленный и тяжелый.
К примеру:
mysql> SELECT SQL_CALC_FOUND_ROWS id, devicereportedtime, facility, priority, fromhost, syslogtag, processid, infounitid, message FROM `SystemEvents` ORDER BY id DESC LIMIT 100;
100 rows in set (5 min 49,02 sec)
Как видно, этот запрос мягко говоря медленный и тяжелый.
Вы имеете ввиду опцию «Enable Row Counting» при добавлении источника логов? Ee нужно разрешать? beta.hstor.org/getpro/habr/post_images/a79/bde/dba/a79bdedba68878d9323f23b1e983761d.png
Как улучшилась производительность после этого?
Как улучшилась производительность после этого?
наоборот, ее лучше не выключать, если у вас предполагается большой размер таблицы. Как я и написал если включена опция Enable Row Counting, то начинается проседание по производительности. Запрос выше, как раз генерирует движок с включенной опцией.
Ну мануалы в бложиках говорят что включать не стоит, только не говорят почему.
А та же кверя с выключенной «Enable Row Counting» сколько выполняется?
А та же кверя с выключенной «Enable Row Counting» сколько выполняется?
При выключенной опции запрос имеет вид:
Выполняется за:
И все начинает летать, при больших объемах.
mysql> SELECT id, devicereportedtime, facility, priority, fromhost, syslogtag, processid, infounitid, message FROM `SystemEvents` ORDER BY id DESC LIMIT 100;
Выполняется за:
100 rows in set (0,00 sec)
И все начинает летать, при больших объемах.
я интересуюсь, потому что StraNNikk habrahabr.ru/post/213519/#comment_7342253 вроде как говорит, что при большом к-ве логов все значительно медленней работает.
при моих объемах достаточно шустро бегает, сейчас на тестовом очищу табличку, для чистоты эксперимента.
собственно протестировал при моих настройках генерация и работа стабильная и быстрая у меня уже событий в тбилце много больше чем 82625385 как я писал выше, включил логирование на уровне инфо и у меня инсертов куча, все стабильно и быстро использую perconadb +apache+nginx пока не смотрел как прикрутит кеширование дополнительное
graylog2 — open-source решение, в отличие от splunk
кстати замечание при таком конфиге, если не указать
будет генерироваться много не нужного
:hostname,!contains ,"имя сервера syslog" :ommysql:localhost,Syslog,rsyslog,password
будет генерироваться много не нужного
Если кому-нибудь пригодится русский язык для loganalyzer, то берите: www.transifex.com/adiscon/loganalyzer
Чтобы скачать, к сожалению, придется авторизоваться (можно через соц. сети).
Чтобы скачать, к сожалению, придется авторизоваться (можно через соц. сети).
Кто шлет логи через rsyslog плюсаните
github.com/rsyslog/rsyslog/issues/3340
github.com/rsyslog/rsyslog/issues/3340
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Настройка централизованного логирования с LogAnalyzer и Rsyslog