Dissect vs. GROK + other tweak questions

[kabilan]

I am looking to migrate many of parsers away from grokking and towards dissect when feasible. i had a question pertaining to performance

%{header}-%{timestamp}-%{payload}

-Dissect logs into 3 segments
-Timestamp will be extracted and mutated to target @timestamp
-Conditionals to dissect payload-segment accordingly into sub-segments

filter {

[dissect] (mapping -> head-timestamp-payload)
if [dissect]
else if [dissect]
else [dissect]
[/dissect]
[mutate > tempdate]
[date] [tempdate > @timestamp]
[mutate > remove tempdate]

}

filter {

[dissect] (mapping -> head-timestamp-payload)
if [dissect]
[mutate > tempdate]
[date] [tempdate > @timestamp]
[mutate > remove tempdate]
else if [dissect]
[mutate > tempdate]
[date] [tempdate > @timestamp]
[mutate > remove tempdate]
else [dissect]
[mutate > tempdate]
[date] [tempdate > @timestamp]
[mutate > remove tempdate]
[/dissect]

this may be a dumb question, but which way is optimal?

[yaauie (Ry Biesemeyer)]

I'm not entirely sure I'm grokking your pseudo-configs; if you're asking whether you have to repeat yourself to get more efficiency, the answer is usually "no" (there are some rare cases where filters have constrained resources where adding more instances may mitigate bottlenecks, but most filters are stateless and will not benefit).

When I do a phased dissect, I typically do subsequent phases if the phase before it succeeded:

# ...
filter {
  dissect {
    # pulls out timestamp, others
    # bits that will be further processed should be
    # bound to `@metadata` fields, which by default
    # won't be persisted in outputs
  }
  if "_dissectfailure" not in [tags] {
    # only do this work if the first parse didn't fail
    date {
      # ...
    }
    # further work on the bits we already extracted
  }
}