Re: [DISCUSS] Generic Syslog Parsing capability for parsers

So I've kept my ear to the ground regarding this topic for a while now, and had some conversations a year or so ago about the idea as well. At the very least, I think having the concept of a pre-parser is a good one, if not chaining an arbitrary number of parsers together. I see this as an

Re: [DISCUSS] Time to remove github updates from dev?

How about a link? On March 19, 2018 at 08:16:46, Andre (andre-li...@fucs.org) wrote: Folks, All rejoice. This has been finally implemented. Cheers On 7 Feb 2018 08:33, "Andre" wrote: > All, > > Turns out the process is simpler: > > A PMC member must create the lists

[DISCUSS] Generic Syslog Parsing capability for parsers

I entered METRON–1453 a little while ago while working on the PR#579 . "We have several parsers now, with many imaginable that are based on syslog, where the format is SYSLOG HEADER MESSAGE. With

Re: [DISCUSS] Generic Syslog Parsing capability for parsers

I think the chaining of parsers, or ability to compose parsers is a good idea, but with reference to the pr mentioned, I would have some number of StellarChainLinks as opposed re-implementing stellar in chainlinks. Although it is NiFi-y. But since I write Processors too, that is fine. On March

Re: [DISCUSS] Generic Syslog Parsing capability for parsers

It seems like parser chaining is becomes a hot topic on the repo too with https://github.com/apache/metron/pull/969#partial-pull-merging I would like to discuss the option, and how we might architect, of configuring parsers to