[Feature]: Include fields from spans in logs generated by OpenTelemetryTracingBridge

[lukasfri]

Related Problems?

No response

Describe the solution you'd like:

I'd like the log entries generated by OpenTelemetryTracingBridge (opentelemetry-appender-tracing) to include the fields-data in the spans which the event was emitted inside, similar to tracing-subscriber which does this with its fmt::layer() when used in the Full format (source code).

Considered Alternatives

You can simply repeat all the fields that are attached to the spans manually ofcourse, but this is hugely cumbersome and removes a large part of the nice ergonomics of tracing::instrument.

Additional Context

Given the green light, I could maybe take a stab at it myself and submit a PR.

[cijothomas]

Can you elaborate more on this ask? Given Logs are correlated to Traces, attaching each attribute to every Log is very inefficient/costly.

[lukasfri]

Can you elaborate more on this ask? Given Logs are correlated to Traces, attaching each attribute to every Log is very inefficient/costly.
@cijothomas

I agree, my issue boiled down to the tracing log-events not being respected in instrumented functions (issue #1378 ). I'll close this and simply wait for a solution to that issue instead/the proposal to turn opentelemetry-rust into a system built on tracing. Sorry for wasting your time!

[Yamakaky]

I have another usecase on this subject. The linked issue talks about correlating traces and logs. If we take for example a classic accept loop:

loop {
    let connection = accept();
    let span = info_span!("connection", client_ip = ...);
    span.in_scope(|| {
        info!("handling connection");
        handle(connection);
    });
}

In that case, fmt::layer() will print the client_ip with the log, but the OTEL logs will not include it. It could technically be recovered once trace correlation is working, but that's not very ergonomic (nor performant i assume). If adding all fields is too inefficient, is there a way to whitelist a few fields that would be copied from the trace?

[cijothomas]

@Yamakaky This are a valid ask. I am open to adding support for this, but be aware that we still haven't closed on the tokio-tracing vs otel tracing discussion, and this will be impacted/influenced by that.

It might be possible to achieve this with a LogRecordProcessor which can inspect current context and push additional attributes to the LogRecord. (This will also have challenges as there is no common understanding on "Context" between OpenTelemetry and Tracing)

[cijothomas]

open-telemetry/oteps#207 A related proposal (which got stalled :( ...)

[Yamakaky]

I see. I guess for now having a manual processor would be fine. I assume you mean LogProcessor instead of LogRecordProcessor? Would a Layer work too?

[lalitb]

It might be possible to achieve this with a LogRecordProcessor which can inspect current context and push additional attributes to the LogRecord. (This will also have challenges as there is common understanding on "Context" between OpenTelemetry and Tracing)

Just to add - API to add/update the attributes is part of #2103.