Record created logs for enabled loggers ignoring filtering

[anuraaga]

Updates to the new spec in open-telemetry/semantic-conventions#3939 (comment)

Fixes #8688

[opentelemetry-pr-dashboard]

Pull request dashboard status

Waiting on the author · refreshed 2026-08-06 23:40 UTC

Respond to 1 review item (e.g. link a commit, explain why not, ask a follow-up):

• Inline threads: 1

Status above doesn't look right?

• Just replied or pushed? Anything around or after the refresh time above may not be picked up yet — give it a few minutes.
• Should this be with reviewers? Comment /dashboard route:reviewers to route it to them.
• Anything wrong — including the routing? Report it with what you expected; it helps us improve the dashboard.

[anuraaga]

Personally the need to introduce this new concept and the different behavior based on the same concept of LoggerConfig show well why this new definition seems problematic. But as I have no interest in influencing the spec I will implement whatever comes out of it ;)

/cc @trask

[jack-berg]

So the idea here is that from a counting of otel.sdk.log.created perspective, we need to differentiate why a logger was disabled? I.e.

• If LoggerConfig.enabled=true but its disabled due to severity/trace-based rules, count.
• If LoggerConfig.enabled=false, don't count.

If that's right, @cijothomas I too don't understand this. From the PR it seems the goal seems to be to abide by the spec language where LoggerConfig.enabled=false behaves equivalently to a noop. But does this actually produce intuitive semantics for a user consuming otel.sdk.log.created?

To me, it seems like the semantics should be one of:

• If Logger.enabled() returns false for any reason, do not increment otel.sdk.log.created.
• OR increment otel.sdk.log.created always, regardless of Logger.enabled(). (This would require changing / re-interpretting the "equivalently to a noop" clause)

[cijothomas]

I put the distinction between Logger being disabled completely vs Logger doing filtering based on some criterion.

i.e

1. LoggerConfig.enabled=false = blanket disabled Logger, must behave NoOp. In other words, this would behave similar to the situation of API only, no SDK scenario.

vs

2. LoggerConfig has other filtering rules. Here, Logger is not completely disabled. Each log record is inspected, and filtered based on trace-based, severity-based (and more in future). This counts.

This is distinct enough - 1 is total disablement of a Logger. It won't look at the LogRecord passed to it as if OTel has never seen the LogRecord.
2 makes decision about filtering by looking at LogRecord. Log has reached a valid Logger, but then dropped.

OR increment otel.sdk.log.created always, regardless of Logger.enabled(). (This would require changing / re-interpretting the "equivalently to a noop" clause)

This is doable. The spec part requiring noop is not marked stable. Are we okay to record internal metric for a completely disabled Logger? The metric reporting cost is non-zero (though with bound/pre-built-attributes, it can be very low)

[cijothomas]

https://github.com/open-telemetry/opentelemetry-specification/pull/5253/changes I opened this in spec to see if this is the preferred direction.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.60%. Comparing base (48b0185) to head (bbfb190).

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #8697      +/-   ##
============================================
- Coverage     91.62%   91.60%   -0.03%     
  Complexity    10328    10328              
============================================
  Files          1003     1003              
  Lines         27140    27142       +2     
  Branches       3188     3189       +1     
============================================
- Hits          24868    24864       -4     
- Misses         1566     1573       +7     
+ Partials        706      705       -1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.