EventListener loglevel would be more specific

[chumaltd]

Expected Behavior

I'd like to have tkn eventlistener logs <eventlistener-name> less verbose, only related to something specific.

For the moment, changing loglevel can be ok, but does kubectl patch survives after every upgrading?
If not, solid defaults would be much appreciated.

Actual Behavior

I'm always getting debug-like logs at default info level.

Steps to Reproduce the Problem

I have multiple trigger set with simple CEL filter like following:

apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
spec:
  triggers:
  
  - name: trigger-a
    interceptors:
    - ref:
        name: cel
      params:
      - name: filter
        value: "header.match('X-Tekton-Trigger', 'trigger-a')"
    bindings:
    - ref: trigger-a-binding
    template:
      ref: trigger-a-template

  - name: trigger-b
    interceptors:
    - ref:
        name: cel
      params:
      - name: filter
        value: "header.match('X-Tekton-Trigger', 'trigger-b')"
    bindings:
    - ref: trigger-b-binding
    template:
      ref: trigger-b-template

This causes verbose CEL logs:

{"severity":"info","timestamp":"2023-10-26T02:47:01.396Z","logger":"eventlistener","caller":"sink/sink.go:420","message":"interceptor stopped trigger processing: rpc error: code = FailedPrecondition desc = expression header.match('X-Tekton-Trigger', 'trigger-b') did not return true","commit":"9498e02-dirty","eventlistener":"tekton","namespace":"tekton","/triggers-eventid":"cbe796a2-e75b-41bd-bf9a-dc415e1b6e6a","eventlistenerUID":"488e6bc4-b21f-4e08-9689-f64fdf419b26","/triggers-eventid":"cbe796a2-e75b-41bd-bf9a-dc415e1b6e6a","/trigger":"trigger-b"}

This example puts 1 log from 2 triggers, but actually I get (n-1) logs from n triggers on every request.
I think CEL no match logs would be debug level, as they have little info.

And another case, I got InvalidArgument with curl request, as curl sends form-encoded body by default:

{"severity":"info","timestamp":"2023-10-26T01:47:00.945Z","logger":"eventlistener","caller":"sink/sink.go:420","message":"interceptor stopped trigger processing: rpc error: code = InvalidArgument desc = form parameter encoding not supported, please change the hook to send JSON payloads","commit":"9498e02-dirty","eventlistener":"tekton","namespace":"tekton","/triggers-eventid":"ff6ba8d5-cde3-4807-88f4-979e15bc6deb","eventlistenerUID":"488e6bc4-b21f-4e08-9689-f64fdf419b26","/triggers-eventid":"ff6ba8d5-cde3-4807-88f4-979e15bc6deb","/trigger":"trigger-a"}

Actually this request completed successfully, so info level can be suitable.
But I think InvalidArgument would be higher log level, if they omit request body then cause different params from intended-JSON body.

Additional Info

Client version: 0.32.0 Pipeline version: v0.50.1 Triggers version: v0.25.0

[dibyom]

I think changing the log levels for when an interceptor stops processing a trigger sounds reasonable