I am not saying it is faster, just giving some info.
Also, that part of the documentation is not referring to regex v. grok, but
grok verses a custom non-regex parser, at least as I read it.
If you have the ability to build, deploy, test and maintain a custom parser
( unless you will be submitting it to the project? ), then in most cases
is the top issue ( or rather throughput ) you are most likely going to get
better results that way. Accepting that you are ok with the tradeoffs.
If you have 10M mps parsing might night be your bottleneck.
On July 11, 2018 at 11:01:19, Muhammed Irshad ([EMAIL PROTECTED])
Thanks for the reply. I saw it uses same Java regex under the hood. I got
bit sceptic by seeing this open issue
in java-grok which says
grok is much slower when compared with pure regex. The fix is not available
yet in metron as it need few changes in the API and issue to be closed. As
data volume is so huge in my requirement I had to double check and confirm
before I go with one. Also metron documentation
itself says the below statement under Parser Adapter section.
"Grok parser adapters are designed primarly for someone who is not a Java
coder for quickly standing up a parser adapter for lower velocity
topologies. Grok relies on Regex for message parsing, which is much slower
than purpose-built Java parsers, but is more extensible. Grok parsers are
defined via a config file and the topplogy does not need to be recombiled
in order to make changes to them."
On Wed, Jul 11, 2018 at 8:01 PM, Otto Fowler <[EMAIL PROTECTED]>
Muhammed Irshad K T
Senior Software Engineer
Skype : muhammed.irshad.k.t