[journaldreceiver]: implement golang based reader for journaldreceiver

[sumo-drosiek]

Component(s)

receiver/journald

Is your feature request related to a problem? Please describe.

The problem is, that journald receiver requires journalctl binary. This binary requires some additional libraries, and currently we do not provide container which supports it.

Describe the solution you'd like

Idea is to write journal reader in golang which will cover the functionality of journalctl we are currently using

Describe alternatives you've considered

We can pack the binary into docker image with all dependencies, eventually use remote journald

Additional context

https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/6672 https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/2332 https://github.com/open-telemetry/opentelemetry-collector-releases/issues/462

[sumo-drosiek]

I started working on implementation in the following repository: https://github.com/sumo-drosiek/gournal

[github-actions[bot]]

Pinging code owners for receiver/journald: @sumo-drosiek @djaglowski. See Adding Labels via Comments if you do not have permissions to add labels yourself.

[crobert-1]

Removing needs triage as this was filed by a code owner, though there still may need to be discussion around the best path forward here.

[sumo-drosiek]

I think I can start moving implementation to the repo. As journal is more like set of database files, I don't think that it will be possible to use stanza package. Due to that I have the following plan:

• create new journalreceiver (the name is almost the same like journaldreceiver)
• implement all reasonable features which are supported by journaldreceiver. Review will be easier and it will be easier to design file management and overall flow which taken care by journactl binary
• switch receivers

It should ensure almost seamless implementation and switch between old and new version

@djaglowski WDYT?

[djaglowski]

As journal is more like set of database files, I don't think that it will be possible to use stanza package.

Can you explain this further? Why can't the implementation be written as a new stanza operator? Doing it this way would allow us to toggle the implementation with a feature flag within the existing receiver. Users would not need to change anything.

[sumo-drosiek]

Why can't the implementation be written as a new stanza operator?

It can be, but not much code can be reused. From my perspective it's just separate piece of code. We can put it into stanza, separate package, or just into receiver code

I wanted to create separate receiver more likely to provide clean implementation and replace the original receiver after implementation is ready

[djaglowski]

Putting it into a reusable package makes perfect sense. I just don't think it's worth breaking existing users nor do I want to sponsor yet another component.

[sumo-drosiek]

I can start implementation here and we can eventually move it out. Not sure if growning up the stanza pkg is right direction for the collector, but journald should be easy to eventually move out in the future

[sinkingpoint]

WDYT about using https://pkg.go.dev/github.com/coreos/go-systemd/v22/sdjournal ? It provides wrappers around the underlying C APIs so we could instrument around those without the need to shell out

[sumo-drosiek]

It requires CGO :(

consequently it requires cgo and the journal headers to be available.

https://github.com/coreos/go-systemd?tab=readme-ov-file#reading-from-the-journal