Enhance the logging rules so that filtering can be performed on log message content

[plkokanov]

How to categorize this issue?

/kind enhancement

What would you like to be added:
Add a field in the rsyslogRelpConfig.loggingRules that allows filtering based on message content. The filters should allow for both excluding or including messages based on their content via regular expressions. This could be done by adding regex and exclude fields which should be pointers to strings and marked as optional. Below is an example of what the new api would look like:

apiVersion: rsyslog-relp.extensions.gardener.cloud/v1alpha1
kind: RsyslogRelpConfig
target: localhost
port: 1520
loggingRules:
- severity: 6
  programNames: ["kubelet"]
  messageContent:
    regex: "some message content"
    exclude: "some other message content"

To implement the regular expression, the following RainerScript functions could be used in the rsyslog config: re_match_i() - case insensitive match or re_match() - case sensitive match.

This would result in the following rsyslog config:

if $programname == ["kubelet"] and $syslogseverity <= 6 and re_match($msg,'some message content') == 1 and re_match(&msg, 'some other message content') == 0 then {
  call relp_action_ruleset
  stop
}

This means that messageContent include and exclude directives are and-ed when they are part of the same loggingRule. A subsequent loggingRule could contain the same programNames and same severity but different messageContent fields resulting in an or operation - this is because loggingRules[] are checked in-order.

Currently the loggingRules[].severity field is always required. However, we could change that and make at least one of severity, programNames or messageContent be required.

Why is this needed:
Currently, the shoot-rsyslog-relp extension only allows for logs to be filtered based on the program name (that generated them) and their severity. However, this is not enough as sometimes users might want to further fine tune the filtering based on the message content of the logs.

[gardener-ci-robot]

The Gardener project currently lacks enough active contributors to adequately respond to all issues.
This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Mark this issue as rotten with /lifecycle rotten
• Close this issue with /close

/lifecycle stale

[gardener-ci-robot]

The Gardener project currently lacks enough active contributors to adequately respond to all issues.
This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close

/lifecycle rotten