sdk/log: self-observability: simple processor metrics

[hostejulien]

Fixes #7016

This PR adds support for the experimental otel.sdk.processor.log.processed metric, emitted when a logger is created via the SDK. This metric follows the OpenTelemetry semantic conventions for SDK metrics.

As the feature is experimental, emission is gated behind the OTEL_GO_X_SELF_OBSERVABILITY environment variable. When set to any case-insensitive value of true, metrics will be recorded.

[pellared]

This PR adds support for the experimental otel.sdk.log.created

this is not what this PR is doing 😉

[hostejulien]

@pellared,
Title and description updated, thanks for the catch!

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.9%. Comparing base (84e3f3a) to head (e118397).
⚠️ Report is 74 commits behind head on main.

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #7127   +/-   ##
=====================================
  Coverage   82.9%   82.9%           
=====================================
  Files        265     265           
  Lines      24894   24926   +32     
=====================================
+ Hits       20643   20673   +30     
- Misses      3876    3878    +2     
  Partials     375     375           

Files with missing lines	Coverage Δ
sdk/log/simple.go	100.0% <100.0%> (ø)

... and 2 files with indirect coverage changes

🚀 New features to boost your workflow:

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

[flc1125]

Additionally: Please add a CHANGELOG.

[flc1125]

A few minor tweaks are needed, thank you for your contribution.

[hostejulien]

Really appreciate your quick and helpful feedback!
It made it much easier to get this feature done.

[pellared]

@hostejulien, from https://github.com/open-telemetry/opentelemetry-go/blob/main/CONTRIBUTING.md:

Avoid rebasing and force-pushing to your branch to facilitate reviewing the pull request. Rewriting Git history makes it difficult to keep track of iterations during code review.

[hostejulien]

@pellared, Got it. Thanks for the heads up!

[pellared]

@hostejulien PTAL #7272

[flc1125]

Hi, since this process involves specification adjustments and historical review records (which may contain invalid review suggestions), it’s impossible to tell which items need attention amid the large volume of information.

Could we create a new PR based on the current branch before preparing for the review, so that subsequent reviews can proceed more smoothly?

Thanks~

[MrAlias]

@hostejulien please take a look at #7016. I have updated the issue with a check list of items from our project Observability guidelines that need to be completed in this PR.

As @flc1125 pointed out, you may find it easier to open a new PR. But feel free to update this PR as well. If you plan to update this PR, please mark it as a draft while you are working to address the items listed in #7016 and the Observability guidelines.

[MrAlias]

@hostejulien I just wanted to check in with this PR. Are you still able to update this PR or open a new PR to address the instrumentation requirements?