Logs receiver for systemd / journald logs

[jmacd]

Pre-filing checklist

• I searched existing issues and didn't find a duplicate

Component(s)

Rust OTAP dataflow (rust/otap-dataflow/)

Is your feature request related to a problem?

On UNIX hosts, we are interested in a journald logs receiver for otap-dataflow.

Proposed Solution

A low-code way to do this would be to exec the "journald" command, which supports paging through the logs with a cursor, the --after-cursor flag and the __CURSOR attribute on each entry. These logs can be emitted as JSON. This would be inefficient for us.

https://systemd.io/ has the official documentation on this format, which can be accessed directly through existing C libraries with #include <systemd/sd-journal.h>.

Alternatives Considered

We should study how other logs collectors do this more specifically. We will likely encounter a desire to co-locate the receiver with the CPU and NUMA region where the journal disk is attached.

Additional Context

No response

[jmacd]

Probably connected with / overlaps with #2844

[lalitb]

I think this should be treated as separate journald receiver, aligned with #2844 but not implemented as a filelog variant.

The source model is different. Filelog discovers normal files, reads bytes, frames records, handles rotation, and checkpoints by file identity + byte offset. Journald should not watch or tail .journal files directly. It should read structured entries through sd-journal and checkpoint by the opaque journald cursor (__CURSOR).
As #2844 evolves, I think we should keep the reusable contracts source-neutral where practical, so journald can share the same receiver-level model without being forced into file-specific mechanics. The likely shared pieces are bounded backpressure, Ack/Nack-aware progress, checkpoint envelope/storage conventions, lifecycle/drain behavior, and generic partition assignment / placement hints.

The source-specific parts remain different:

• filelog: file discovery, inode/device identity, byte offsets, framing, rotation
• journald: journal source selection, sd-journal iteration, cursor handling, retention/cursor-loss behavior

For journald, discovery is simpler: the initial partition can be a logical source such as journal/system. Later this could extend to user journals or journal namespaces. If #2844 produces a generic assignment extension, journald can use it to assign logical journal partitions to receiver instances, but it should not depend on file-discovery mechanics.

Proposed path:

1. Start with a short Linux-only design doc.
2. Keep the first implementation independent of [Epic]: Add an OTAP-native filelog receiver with discovery extension, Ack-based checkpoints, and processor-based processing #2844, using a static partition like journal/system.
3. Keep the internal structure partition-oriented so it can later plug into generic assignment from [Epic]: Add an OTAP-native filelog receiver with discovery extension, Ack-based checkpoints, and processor-based processing #2844.
4. Use a dedicated blocking worker for sd_journal_* calls and bounded handoff into the df-engine async task.
5. Commit journald cursors only after downstream Ack.
6. Keep semantic parsing/enrichment in processors.

This keeps journald moving without blocking on the broader filelog epic, while still aligning with any common local-log receiver contracts #2844 defines.