redpanda-data / redpanda-data/connect

GROK: inconsistencies between in-yaml and pattern_paths

Open
#1,602 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bughancement needs investigation processors ux
Dominant language
Go
Stars
8.8k
Forks
969
Avg merge
1d 13h
Merged PRs (30d)
64

Description

Hi there,
I spent some time debugging a grok issue which worked perfectly when all patterns were defined in the yaml, but failed when the patterns were included via pattern_paths. root cause AFAICT is how underscores are handled differently.
they are allowed in the yaml, but not in the included patterns.

here's my test case:
csv input file

id,log
1,GROK 1 test
2,GROK 2 test
3,KROG 3 test
4,KROG 4 test

yaml without included patterns

pipeline:
  threads: 1
  processors:
    - label: "branch_test"
      branch:
        request_map: |
          root = this.log
        processors:
          - label: "grok_test"
            grok:
              expressions:
                - '%{GROK_1}'
                - '%{GROK1}'
              # pattern_paths:
                 # - "./grok"
              pattern_definitions: 
                PRE_1: '^GROK'
                PRE1: '^KROG'
                GROK_1: '%{PRE_1} %{INT:int} %{GREEDYDATA:test}'
                GROK1: '%{PRE1} %{INT:int} %{GREEDYDATA:test}'                       
        result_map: |
          root.branchresult = this

results in:

{"branchresult":{"int":"1","test":"test"},"id":"1","log":"GROK 1 test"}
{"branchresult":{"int":"2","test":"test"},"id":"2","log":"GROK 2 test"}
{"branchresult":{"int":"3","test":"test"},"id":"3","log":"KROG 3 test"}
{"branchresult":{"int":"4","test":"test"},"id":"4","log":"KROG 4 test"}

Nice!

but moving these patterns out to a patterns.grok file - and (un)commenting the relevant bits in the yaml

# TESTPATS
PRE_1 ^GROK
PRE1  ^KROG

returns:

{"branchresult":{"int":"1","test":"test"},"id":"1","log":"GROK 1 test"}
{"branchresult":{"int":"2","test":"test"},"id":"2","log":"GROK 2 test"}
ERRO Branch error: processors failed: no pattern matches found  @service=benthos label=branch_test path=root.pipeline.processors.0
{"id":"3","log":"KROG 3 test"}
ERRO Branch error: processors failed: no pattern matches found  @service=benthos label=branch_test path=root.pipeline.processors.0
{"id":"4","log":"KROG 4 test"}

I didn't know that _ isn't (usually) allowed in grok so it took me a fair bit of time to pin down.
It's not a bug perse, so just reporting it here for you to decide on whether to (dis)allow _, mention it in the docs, and/or catch it in the linter.

On that note, there's no linting of the included patterns so a bit of gibberish in there causes a hard crash.
(And while I am at it, another one that tripped me up was a trailing space in the PRE pattern in the included file ;-(

finally, there's something off/unexpected with the globbing in pattern_paths.
my file is named ./grok/patterns.grok
"./grok" works , see earlier
"./grok/*.grok" does not work
I know it says pattern_paths but still...

My apologies for dumping all of this in a single issue.
Once I got the underscore and space sorted it was actually smooth sailing all the way. Thanks!

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the grok processor's handling of pattern_definitions and pattern_paths, then reproduce the supplied YAML and patterns.grok examples. Check the underscore, malformed-pattern, trailing-space, and globbing cases; done requires a decided and tested behavior, with documentation or linting changes if those are selected.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
stream-processing
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.