feat(otellogs/systemd): add support for systemd logs to otellogs

[sumo-drosiek]

Description

Add support for journald receiver. This behaves like fluent-bit with one small exception. Units for filtering are taken from different place.

        ## This is not a full equivalent of fluent-bit filtering as fluent-bit filters by `_SYSTEMD_UNIT`
        ## Here is filtering by `UNIT`

---

Checklist

• Changelog updated

Testing performed

• Redeploy fluentd and fluentd-events pods
• Confirm events, logs, and metrics are coming in

[github-actions]

This pull request contains invalid labels. Please remove all of the following labels: ['do-not-merge/hold']

[sumo-drosiek]

systemd is key value pair, so this option is safe for fluentd. It's necessary for otel, as it sends body as key-value pair. This body would be put inside log key without this option

[kasia-kujawa]

You can now update tag to newer version ;)

[andrzej-stencel]

"I have a dream"... that we have a piece of high-level documentation describing collecting systemd logs, a bit like what we now have for collecting Kubernetes events: https://github.com/SumoLogic/sumologic-kubernetes-collection/blob/main/deploy/docs/collecting-kubernetes-events.md.

[andrzej-stencel]

Does this list mean that if the user wants to customize this list, they just need to overwrite this property in their values.yaml file? 😱 For example, if they want to exclude a specific unit, they need to replicate this whole list with the one unit excluded.
I don't know what the common use cases are (if there are any). Maybe there are no good reasons to customize this list. In that case, do we need to expose it? This question applies to this whole config.

[sumo-drosiek]

Yes, this PR is fluent-bit replacement. There is a lot of improvements we can take, but maybe there should be separate issues, so it will be more organised way to track them?

[sumo-drosiek]

I don't know what the common use cases are (if there are any).

I don't think there are any, but we need to have some plan in case they'll appear

[sumo-drosiek]

"I have a dream"... that we have a piece of high-level documentation describing collecting systemd logs, a bit like what we now have for collecting Kubernetes events: https://github.com/SumoLogic/sumologic-kubernetes-collection/blob/main/deploy/docs/collecting-kubernetes-events.md.

I would love to have this simple option:

sumologic:
  logs:
    systemd:
      enabled: false

but it is not possible now. We need to take it in v3. I think the documentation should be a part of that change too. (For now we do not document any otellogs configuration)

If you think differently I can make some documentation draft as part of this PR :)

[sumo-drosiek]

but it is not possible now

TBH, maybe it is, but we need to have some final consensus about which approach to configuration we take