metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark De Rijk <me.der...@gmail.com>
Subject Re: Develop some parsers
Date Fri, 07 Apr 2017 13:41:19 GMT
I will review them this afternoon. Thanks for that.

Sent from my iPhone

> On 7 Apr 2017, at 14:37, Ali Nazemian <alinazemian@gmail.com> wrote:
> 
> Mark,
> 
> Have you seen the following pages?
> 
> https://cwiki.apache.org/confluence/display/METRON/Development+Guidelines
> https://cwiki.apache.org/confluence/display/METRON/Metron+Development+Environment+Setup+Instructions
> https://cwiki.apache.org/confluence/display/METRON/Community+Resources
> 
> 
>> On Fri, Apr 7, 2017 at 11:20 PM, Mark de Rijk <me.derijk@gmail.com> wrote:
>> 
>> To clarify I have written a lot of parsers for ArcSight over the years and
>> I would like to start contributing by developing parsers for the Metron
>> project.
>> Is there any documentation that will help me get started so I can start
>> cranking them out?
>> This is the first open source project I am looking to contribute to so
>> forgive me If I am asking stupid questions.
>> 
>> 
>> 
>> On Fri, Apr 7, 2017 at 2:13 PM, Otto Fowler <ottobackwards@gmail.com>
>> wrote:
>> 
>>> I also believe that grok parsers can be added through configuration only,
>>> without having to
>>> compile a parser.
>>> 
>>> You can add a parser configuration targeting the basic grok parser and
>> just
>>> provide the grok
>>> parser rules.
>>> 
>>> 
>>> Just as a heads up, I’m currently working on the parsers to allow for
>>> writing and maintaining parsers
>>> outside the metron code tree, including providing a maven archetype.
>> This
>>> will allow you to create parsers
>>> without having to maintain a fork etc.
>>> 
>>> Keep an eye out for METRON-258 as a PR on the list.
>>> 
>>> 
>>> 
>>> On April 7, 2017 at 08:54:35, Justin Leet (justinjleet@gmail.com) wrote:
>>> 
>>> 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
>>>> 
>>> 
>> 
> 
> 
> 
> -- 
> A.Nazemian

Mime
View raw message