sdk/log/xlog: Add FilterProcessor and EnabledParameters

[pellared]

Per #6271 (comment)

This introduces a new go.opentelemetry.io/otel/sdk/log/xlog module.
I created it because of two reasons:

• Add the possibility to filter based on the resource and scope which is available for the SDK. The scope information is the most important as it gives the possibility to e.g. filter out logs emitted for a given logger. Thus e.g. Add min_severity to LoggerConfig opentelemetry-specification#4364 is not necessary. See OTEP: Logger.Enabled opentelemetry-specification#4290 (comment) for more context.
• I think we may want to stabilize the Logs SDK before Add Enabled to LogRecordProcessor opentelemetry-specification#4363 is done and stabilized. Therefore, this feature is added a separate module. go.opentelemetry.io/otel/sdk/log module does not expose these experimental feature in its exported API; it is only available in docs and example test. The user would have to explicitly opt-in by using the go.opentelemetry.io/otel/sdk/log/xlog module which will always have v0.x.y versions. Hopefully at some point of time the features are added to go.opentelemetry.io/otel/sdk/log, deprecated in go.opentelemetry.io/otel/sdk/log/xlog and afterwards removed from go.opentelemetry.io/otel/sdk/log/xlog . I think that for at one release we would need to support both the deprecated go.opentelemetry.io/otel/sdk/xlog.FilterProcessor and new go.opentelemetry.io/otel/sdk/log.FilterProcessor to facilitate the migration process. The module name is inspired by xerrors.xlog is under sdk/log so that it could have access to packages under sdk/log/internal if necessary. The SDK supports xlog using reflect (duck typing) and the sdk/log production code does not depend on xlog so users should never experience build failures because of breaking changes in xlog.
• This is also related to Document strategy to support experimental methods on stable interfaces #5882 (comment)
• This will also help me with working towards Add Enabled to LogRecordProcessor opentelemetry-specification#4363 as I would have a good example how we do support it.

Fixes #6298

[pellared]

I think that we can make it working if we use reflect instead of type assertions.

[pellared]

What is interesting if the dependency is used only used in tests then it does not come up as an indirect dependency for modules using go.opentelemetry.io/otel/sdk/log 🎉

It looks like the Go module graph pruning has been improved at some point.

I think that it means that we could get rid of test modules 😉

[dmathieu]

This is a bit strange. I've just tried that for otelhttp, and the SDK does come as an indirect dependency.

[pellared]

Then I think we cannot rely on the Go modules pruning and I will get rid of this dependency.

[pellared]

Adressed 08ac146

[pellared]

This is a bit strange. I've just tried that for otelhttp, and the SDK does come as an indirect dependency.

@dmathieu , I tried it once more and actually it does NOT come as an indirect dependency.

See: open-telemetry/opentelemetry-go-contrib#6763

I had to run make go-mod-tidy twice. Probably if we used crosslink tidylist then it would not be necessary

We can could consider revert 08ac146. But I am fine with the current approach as well. It looks cleaner. I propose to keep the current way.

[dmathieu]

Ah, it looks like the difference is that you used a different package name. So that'd be the trick.

[pellared]

Ah, it looks like the difference is that you used a different package name. So that'd be the trick.

I do not follow. The SDK is used in tests of both of otelhttp and otelhttp_test packages.

[dmathieu]

Yes, but when I tried it, I kept the otelhttp package name for the tests. I think that's why the dependency still showed up.

[pellared]

Some tests still use it. Can you double check it? Make sure to run make go-mod-tidy more than once 😉

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 81.6%. Comparing base (afbe545) to head (e4d1ebf).

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #6286     +/-   ##
=======================================
- Coverage   81.8%   81.6%   -0.3%     
=======================================
  Files        283     284      +1     
  Lines      24892   24954     +62     
=======================================
- Hits       20379   20370      -9     
- Misses      4109    4179     +70     
- Partials     404     405      +1     

see 4 files with indirect coverage changes

[pellared]

I think that relying on git hashes may be very annoying for the users.
It would be hard for them to keep sdk/log and sdk/log/xlog in sync.

1. We are making commits very frequently so they may even not bump it
2. It would be hard to figure it out which version of xlog is compatible with log with we do any breaking change.

On the other side, we can wait for making a release until people actually complain.

Thoughts?

[dmathieu]

For comparison, the collector keeps x packages within the normal release process.

I have doubts about the idea, but if we want to allow folks to be able to get very fresh code, we could setup auto nightly/weekly releases for the x packages. Then, they wouldn't rely on commits, but would remain on the latest.

[dmathieu]

Would it be possible to add a linter to ensure no stable module uses an x one?

[pellared]

Would it be possible to add a linter to ensure no stable module uses an x one?

I created #6298 to avoid scope creeping.
I added it to Logs GA project to make sure we address it before stabilizing the logs.

[pellared]

Would it be possible to add a linter to ensure no stable module uses an x one?

I created #6298 to avoid scope creeping. I added it to Logs GA project to make sure we address it before stabilizing the logs.

I found some time and I added the rule: 25937e0