Implement journald exporter for OpenTelemetry

[lalitb]

Changes

This adds Journald log exporter for OpenTelemetry, allowing logs to be sent to Journald. Note that this exporter is experimental, and breaking changes are expected. The performance and stability improvements are required, and contributions are welcome.

Features:

• Export OpenTelemetry logs to journald.
• Optionally serialize logs and attributes as JSON.
• Configurable message size limit based on the journald configuration : As of now this is just used to return an error, in future memfd can be used for sending large messages.
• Configurable attribute prefix.

Dependencies:

This implementation relies on the libsystemd library for sending log entries to the journald daemon. It uses sd_journal_sendv API method provided by the library.

Merge requirement checklist

• CONTRIBUTING guidelines followed
• Unit tests added/updated (if applicable)
• Appropriate CHANGELOG.md files updated for non-trivial, user-facing changes
• Changes in public API reviewed (if applicable)

[lalitb]

@TommyCpp had an question on comparing it with the subscriber provided by Tokio tracing library - https://github.com/tokio-rs/tracing/blob/master/tracing-journald/ -

• The key distinction in the implementation is that the tracing journald subscriber writes directly to the Unix-domain socket monitored by the journald daemon. In contrast, this PR leverages the API provided by the libsystemd library (formerly libsystemd-journald) to perform the same operation. @Ralith (apologies for the tag) added the initial tracing implementation, so he might offer some background on the direct socket approach and any concerns related to using libsystemd?
• The tracing subscriber supports writing large logs (beyond limit enforced by journald config) using memfd, which can be added in subsequent implementation.
• I haven't done the benchmarks yet to compare, need to do this.

[Ralith]

background on the direct socket approach and any concerns related to using libsystemd

This was motivated by the improved downstream developer experience from being pure Rust, and the simplicity of the journald client protocol. It's not significantly more complicated than FFIing to libsystemd, and it dramatically reduces the sensitivity of downstream crates to build environment issues like missing pkg-config files, linking during cross-compilation, etc.

[lalitb]

This was motivated by the improved downstream developer experience from being pure Rust, and the simplicity of the journald client protocol. It's not significantly more complicated than FFIing to libsystemd, and it dramatically reduces the sensitivity of downstream crates to build environment issues like missing pkg-config files, linking during cross-compilation, etc.

Thanks, @Ralith, for the background. The concerns regarding build complexities with FFI to C are valid, and we will consider documenting this for the developers. My motivation for using libsystemd is that it internally handles sending large data through memfd, and so abstracting these low-level details. And hopefully being future-proof with any protocol changes :)

[utpilla]

The comment is unclear.

[lalitb]

Good catch, fixed now.

[cijothomas]

@lalitb Are you planning to resurrect this? I think it makes sense to have a working prototype and merge it in, and mark the status as alpha.
Improvements can be done iteratively, so as to not block progress.

[lalitb]

@lalitb Are you planning to resurrect this? I think it makes sense to have a working prototype and merge it in, and mark the status as alpha. Improvements can be done iteratively, so as to not block progress.

Yes, let me fix the CI, and make it ready. This would also help to get community contributions.

[utpilla]

Suggested change

	description = "OpenTelemetry logs exporter for journald"
	description = "OpenTelemetry Logs Exporter for journald"

[utpilla]

Suggested change

	fn get_priority(severity: &Severity) -> i32 {
	const fn get_priority(severity: &Severity) -> i32 {

[utpilla]

I think we could avoid an allocation related to uppercase conversion by mapping the characters to upper case before collecting them into a String.

name.chars()
        .map(|c| if c == '.' { '_' } else { c })
        .skip_while(|&c| c == '_')
        .filter(|&c| c == '_' || c.is_ascii_alphanumeric())
        .map(|c| c.to_ascii_uppercase())
        .collect::<String>()

[utpilla]

Same as #84 (comment)

[utpilla]

Since the default message size limit is zero, does it mean that for a user who did not configure the message size limit explicitly, this method would always return an error?

[cijothomas]

Suggested change

	name = "opentelemetry-journald-logs"
	name = "opentelemetry-journald"

[utpilla]

How about opentelemetry-exporter-journald?

Suggested change

	name = "opentelemetry-journald-logs"
	name = "opentelemetry-exporter-journald"

[cijothomas]

I like specific names, so opentelemetry-exporter-journald sounds good

[utpilla]

Is this needed?