[Bro] NSQ plugin getting deprecated in 2.5
daniel.guerra69 at gmail.com
Mon Sep 19 08:52:11 PDT 2016
I love kibana as a frontend and elasticsearch. In 2.4.1 it
worked fine with proportional elastic power and nginx.
When elastic is underpowered for the speed you are
creating logs its obvious to have problems (timeout)
The efficiency of elasticsearch is not so well… java.
I think its better to focus on kafka and use an elastic river.
This is how graylog works and that goes pretty well.
It would be handy to have an unique-name/type combination,
it doesn’t matter in what kind of log.
(ssh.log version, string http.log version,integer)
Every collision in this causes lots of logging in elastic.
A script sanity check would be great for this.
Maybe elastic wants to be owner of this plugin ?
Splunk also provides a bro plugin + config.
> On 19 Sep 2016, at 16:55, Azoff, Justin S <jazoff at illinois.edu> wrote:
>> On Sep 16, 2016, at 5:50 PM, Robin Sommer <robin at icir.org> wrote:
>> I'm wondering if there's anybody who'd be interested in taking over
>> ownership of the plugin. We are planing to move bro-plugins/* into
>> separately distributed Bro packages anyways, using the new Bro package
>> manager. If somebody wanted to take ownership of the plugin that way,
>> they could just starting maintaining a package for it. An option could
>> also be turning it into a NSQ-only plugin?
> I was thinking the same thing.
> I think the issues with the elasticsearch plugin was that bro -> remote ES never worked well in practice and users were better off using something else to get logs into ES.
> But bro -> local NSQ was rock solid for the people that used it.
> Also, another thing to keep in mind is that there are only a few lines in the entire plugin that are actually specific to NSQ, with a few strings moved into options it could possibly be turned into a generic http/json log writer.
> - Justin Azoff
> Bro mailing list
> bro at bro-ids.org
More information about the Bro