Small cleanup in Logs SDK.

[lalitb]

Changes

• Set LoggerProvider::log_processors() visibility to crate scope.
• Set LoggerProvider::resource() visibility to crate scope.
• Modify Builder::build() to first create the LoggerProvider, and then propagate the resource to the processor, to address below warning after above scope changes:

warning: method `resource` is never used
   --> opentelemetry-sdk/src/logs/log_emitter.rs:94:19
    |
87  | impl LoggerProvider {
    | ------------------- method in this implementation
...
94  |     pub(crate) fn resource(&self) -> &Resource {
    |                   ^^^^^^^^
    |
note: the lint level is defined here
   --> opentelemetry-sdk/src/lib.rs:110:5
    |
110 |     unused
    |     ^^^^^^
    = note: `#[warn(dead_code)]` implied by `#[warn(unused)]`

Merge requirement checklist

• CONTRIBUTING guidelines followed
• Unit tests added/updated (if applicable)
• Appropriate CHANGELOG.md files updated for non-trivial, user-facing changes
• Changes in public API reviewed (if applicable)

[utpilla]

Modify Builder::build() to first create the LoggerProvider, and then propagate the resource to the processor, to address below warning after above scope changes:

Could we just remove those methods instead of force using them just to avoid the "unused" warnings?

[lalitb]

Modify Builder::build() to first create the LoggerProvider, and then propagate the resource to the processor, to address below warning after above scope changes:

Could we just remove those methods instead of force using them just to avoid the "unused" warnings?

Yes, thought of doing that, but just kept it to be consistent with recent traces changes #1755. And open to remove from both signals if we see them bloating the code.

[utpilla]

Yes, thought of doing that, but just kept it to be consistent with recent traces changes #1755. And open to remove from both signals if we see them bloating the code.

I would be in favor of removing unused methods instead of keeping them around.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 74.4%. Comparing base (300f8e5) to head (a1931e4).

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #1850     +/-   ##
=======================================
- Coverage   74.4%   74.4%   -0.1%     
=======================================
  Files        122     122             
  Lines      19800   19802      +2     
=======================================
- Hits       14750   14749      -1     
- Misses      5050    5053      +3     

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

[tisonkun]

I have some code rely on this API:

        for processor in provider.log_processors() {
            let record = record.clone();
            let mut data = opentelemetry_sdk::export::logs::LogData {
                record,
                instrumentation: self.instrumentation_library().clone(),
            };
            processor.emit(&mut data);
        }

It seems no migration is provided?

[tisonkun]

Rewrite with Logger:

        let provider = self.provider.clone();
        let logger = provider.library_logger(self.library.clone());

        let mut record = opentelemetry_sdk::logs::LogRecord::default();
        record.observed_timestamp = Some(SystemTime::now());
        record.severity_number = Some(log_level_to_otel_severity(log_record.level()));
        record.severity_text = Some(log_record.level().as_str().into());
        record.body = Some(AnyValue::from(log_record.args().to_string()));

        logger.emit(record);
        Ok(())

[cijothomas]

@tisonkun OTel Logging Bridge is NOT meant for end users to use. It is only meant for authoring log-bridges(appenders) only. Are you using OTel Logging Bridge to report logs in your application?