feat(sdk-logs): implement log creation sdk metrics

[anuraaga]

Which problem is this PR solving?

I am helping to implement SDK internal metrics

https://opentelemetry.io/docs/specs/semconv/otel/sdk-metrics/

This adds log creation metrics

Very similar to #6213 which was for traces.

/cc @trentm

Short description of the changes

Implements metrics for creation of logs per semconv

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• Unit tests

Checklist:

• Followed the style guidelines of this project
• Unit tests have been added
• Documentation has been updated

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.70%. Comparing base (30c8bf3) to head (1c9cde2).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6433   +/-   ##
=======================================
  Coverage   95.70%   95.70%           
=======================================
  Files         364      366    +2     
  Lines       11774    11790   +16     
  Branches     2747     2750    +3     
=======================================
+ Hits        11268    11284   +16     
  Misses        506      506           

Files with missing lines	Coverage Δ
...imental/packages/opentelemetry-sdk-node/src/sdk.ts	95.93% <100.00%> (+0.02%)	⬆️
experimental/packages/sdk-logs/src/Logger.ts	100.00% <100.00%> (ø)
...xperimental/packages/sdk-logs/src/LoggerMetrics.ts	100.00% <100.00%> (ø)
...perimental/packages/sdk-logs/src/LoggerProvider.ts	100.00% <ø> (ø)
...sdk-logs/src/internal/LoggerProviderSharedState.ts	97.29% <100.00%> (+0.63%)	⬆️
experimental/packages/sdk-logs/src/semconv.ts	100.00% <100.00%> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[trentm]

A possible subtlety that isn't considered by the spec, because of timing: Since the SDK metrics were added to semconv, support for Logger#emit filtering log records based on possible Logger config was added. https://opentelemetry.io/docs/specs/otel/logs/sdk/#emit-a-logrecord

Status: Development Before processing a log record, the implementation MUST apply the filtering rules defined by the LoggerConfig (in case Enabled was not called prior to emitting the record):

1. Minimum severity: If the log record’s SeverityNumber is specified (i.e. not 0) and is less than the configured minimum_severity, the log record MUST be dropped.

2. Trace-based: If trace_based is true, and if the log record has a SpanId and the TraceFlags SAMPLED flag is unset, the log record MUST be dropped.

I think it is worth a follow-up on the spec/semconv whether the intention is that the otel.sdk.log.created metric is counted before or after (as you have it here) that filtering. @anuraaga Is there an implementation of this metric in OTel Java? If so, what is done there?

(Aside: This Logger#emit is currently missing checking loggerConfig.disabled. I'll open an issue for that separately.)

[anuraaga]

Good catch - Java is implemented in the same way, after the enabled check (organically, I didn't decide one way or the other not realizing the caveat at the time)

https://github.com/open-telemetry/opentelemetry-java/blob/main/sdk/logs/src/main/java/io/opentelemetry/sdk/logs/SdkLogRecordBuilder.java#L152

Filed open-telemetry/semantic-conventions#3506 in semconv to follow up.

For now, it seems fine to go with post-filtering because with no way to identify filtered vs not via attribute or separate metric, mixing the two is probably less useful.