OpenTelemetry specs vs tracing crate

[sebastiendan]

Hi there,

Comparing OpenTelemetry official instrumentation lib documentation to the tracing crate, I see that specs don't seem to align perfectly, which would make sense as tracing isn't OpenTelemetry-biased, but I assume tracing-opentelemetry would be.

The main diff I can see is the meaning of the "event" term:

• OpenTelemeytry spec and official instrumentation libs: An event is a custom log line/entry manually attached to a span
• tracing (and so tracing-opentelemetry): An event is equivalent to a span

One practical implication of this: In tracing, there's a log filter we can set on a span so that all application log entries passing through the filter will be added as span events (in the original spec definition), which turn out to be a large volume of logs. In official instrumentation libs, I couldn't find this equivalent feature and since events are custom and manually created throughout the instrumentation, the volume of logs is fully controlled.

Can you confirm this?

[hawkw]

The main diff I can see is the meaning of the "event" term:

• OpenTelemeytry spec and official instrumentation libs: An event is a custom log line/entry manually attached to a span

• tracing (and so tracing-opentelemetry): An event is equivalent to a span

What do you mean exactly by "an event is equivalent to a span"? An "event" in tracing is a collection of data recorded at a moment in time, like a structured log entry. Events occur within the context of a span. This is typically the current span when the event is recorded unless the user explicitly overrides it.

One practical implication of this: In tracing, there's a log filter we can set on a span so that all application log entries passing through the filter will be added as span events (in the original spec definition), which turn out to be a large volume of logs. In official instrumentation libs, I couldn't find this equivalent feature and since events are custom and manually created throughout the instrumentation, the volume of logs is fully controlled.

Can you confirm this?

tracing's filtering mechanisms are used to control which spans and events are recorded. If I understand the question correctly, you want to log events as part of an application's logs, but only want some of those events to be attached to the OpenTelemetry span that corresponds to the current span in the application? Depending on your use case, you may want to use tracing-subscriber's per-Layer filtering features to constrain which events are sent to OpenTelemetry without also removing them from the application's logs.

Does that answer your questions?

[sebastiendan]

What do you mean exactly by "an event is equivalent to a span"?

I think I got confused by a couple occurrences of "span/event" wordings in the doc. So there's no equivalency.

you want to log events as part of an application's logs, but only want some of those events to be attached to the OpenTelemetry span that corresponds to the current span in the application

Roughly yes! (I don't necessarily want to log events as part of the app's logs)
My understanding is that on top of events that one instrumentation dev would manually create throughout the instrumentation, spans get attached with all the application logs (the logs you would get from stdout). This is the latter that I'm interested in controlling/removing.

Let's say for instance that my app, even with INFO log level, produces many logs. I might not be interested in having these logs attached to spans and would only want to define custom events myself.

[davidbarsky]

I might not be interested in having these logs attached to spans and would only want to define custom events myself.

As Eliza said, I'd look at using per-layer filtering alongside filter_fn or dynamic_filter_fn to accomplish this.

[hawkw]

What do you mean exactly by "an event is equivalent to a span"?

I think I got confused by a couple occurrences of "span/event" wordings in the doc. So there's no equivalency.

@sebastiendan the documentation sometimes uses "span/event" when referring to something that applies to both spans or events. Spans and events are separate concepts in tracing, but some concepts apply to both spans and events. For example, both spans and events call the Subscriber::enabled method to determine if they are enabled, so we might say that "enabled returns true if the span/event is enabled".