"add" filters to inject fields in log records

[bprieur]

Environment: openshift 4.16
Operator channel: 6.x

Like prune filter to delete some fields, it should be great having a filter to inject fields in log records.

Or maybe this feature is out of scope of this operator and aggregators are needed between collectors and receivers?

Some example :

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  filters:
    - name: <filter_name>
      type: add
      add:
        # <key>: <value>
        tag: "openshift.app.{.kubernetes.pod_name||default}"

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  filters:
    - name: <filter_name>
      type: add_pattern
      from:
        - key: kubernetes.namespace_name
          ref: myref
          pattern: ^(.+)-(.+)-(.+)$
      add:
        # <key>: <value>
        tag: "openshift.app.$myref[1]"

[jcantrill]

There is an "openshift labels" filter that allows adding custom labels not defined on a pod. This would seem to accomplish the same goal though slightly more opinionated

[bprieur]

I saw this one, but this filter allows us only to add fields through the "openshift.labels" field.

Is there a good practice behind this filter?

[jcantrill]

I saw this one, but this filter allows us only to add fields through the "openshift.labels" field.
Is there a good practice behind this filter?

I'm not certain I understand your question. This is akin to adding a label to a kubernetes workload which AFAIK is the recommended way to provide additional customization. The filter allows you to provide additional labels to logs flowing through a pipeline without needing to update a pod spec. I frankly do not understand the need to move field values from one location in the payload to another when it is possible to craft a query using the existing field locations. Regardless, I do not imagine us taking up a filter to accomplish what you define here unless there is an overwhelming customer need for it. It potentially will require implementing a "field selection" grammer for which we do not desire to create and maintain. The path selection that exists now is a subset of what vector's VRL provides now