Rule proposal: This should be a span, not a log

[svrnm]

Proposal

Rule ID: LOG-TBD

Description: Log records that clearly should be a span.

Rationale: When a developer writes log statements in their code, they should always consider, if what they are defining is actually a point in time, or the start or end of a time span. If it is the latter, they should use tracing instead, such that an observability backend can visualize the duration better. This increases the quality of the observability data.

Target: Log

Criteria: to be defined, maybe there is a way to identify certain key words or attributes in logs that make it obvious that they should be a span (e.g. "BEGIN" or "END")

Impact: to be defined

Type: to be defined

[danielgblanco]

One example I tend to think about in this case is "access logging". If access logging is for auditing purposes, maybe dump it in cheap storage, and it's for observability purposes (where we care about duration as well as attributes), use a span instead? Not sure how one would codify that.

This makes me think... while OTel can let you fulfil both purposes (auditability and observability) I consider them tangential. If we want to this score to be focused on the observability use case, we could have rules that say "access logging is disabled and spans are used instead". This would be a good example of things where semconv/Weaver should not get into IMO (related to #23)

[svrnm]

There is still an open proposal about auditing logs with OpenTelemetry, open-telemetry/community#2409, I am still curious to see if this comes to life at some point.

Not sure how one would codify that.

I think that's the hard part about this rule, there might be some "low hanging" fruits like check for some patterns like "BEGIN" and "END" in your logs, etc, but all of that is heuristics.

[mmanciop]

Yes and "This span event should be a log in 2025" :-)