metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Leet <justinjl...@gmail.com>
Subject Re: Develop some parsers
Date Fri, 07 Apr 2017 12:54:31 GMT
My understanding of Grok vs Java is to provide a tradeoff for ease of
implementation vs performance (plus Java can also handle parsing that would
be too complicated for Grok.

Grok is less performant and handles less complex parsing, but it's easy to
get things going and potentially maintained without writing and compiling
Java.

The Java implementation will be better for performance and can handle more
complicated parsing Grok can't.

I believe the preference has generally been for Grok parsers if
appropriate, otherwise Java parsers.

Justin

On Fri, Apr 7, 2017 at 8:09 AM, Ali Nazemian <alinazemian@gmail.com> wrote:

> Hi Mark,
>
> Yeah, that would be great. Can you please specify which devices you have
> developed so far?
>
> Cheers,
> Ali
>
> On Fri, Apr 7, 2017 at 4:10 PM, Mark De Rijk <me.derijk@gmail.com> wrote:
>
> > Dear all,
> >
> > I am a heavy arcsight user and I have written quite a few parsers over
> > time.
> > I am new to contributing to open source projects however.
> > @Ali, would you like to cooperate on development of some parsers?
> >
> > Kind Regards,
> > Mark de Rijk
> >
> >
> > > On 7 Apr 2017, at 04:30, Ali Nazemian <alinazemian@gmail.com> wrote:
> > >
> > > Hi all,
> > >
> > > We are going to develop some parsers and have some contribution to the
> > > community as a start point. I was wondering what the reason is behind
> > > choosing Grok statements for some of the implementations and Java regex
> > for
> > > other ones? Is there any policy for that? Probably it would be better
> to
> > > have the Java regex implementation due to performance concerns.
> However,
> > I
> > > am sure there is a reason that some of them have been implemented with
> > > using Grok statements.
> > >
> > > Regards,
> > > Ali
> >
>
>
>
> --
> A.Nazemian
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message