Review logger Implementation for the stable log data model.

[lalitb]

trafficstars

Log Data Model specs are marked as stable - https://github.com/open-telemetry/opentelemetry-specification/pull/2387. It would be a good time to review the logger api and sdk implementation and validate if the existing log structure can be mapped to this data model. Also, how to continue supporting fields/attributes that are not part of this logger model - eg log-name.

[owent]

I have a quick look at opentelemetry-proto to v0.17.0 and the main branch of logging-library-sdk in opentelemetry-specification, and I want to confirm and disscuss the changes.

• InstrumentationLibrary is deprecated and we should use InstrumentationScope now.This will also changes the trace and metrics. Should we add a option to switch between legacy InstrumentationLibrary and new InstrumentationScope?
  • instrumentation_library_spans should be replaced by scope_spans
  • instrumentation_library_metrics should be replaced by scope_metrics
  • instrumentation_library_logs should be replaced by scope_logs
• LogProcessor::OnReceive(LogRecordable) should be renamed to LogProcessor::Emit(LogData)
• Rename LoggerProvider to LogEmitterProvider
• Rename LoggerContext to LogEmitter and move InstrumentationScope from Logger to LogEmitter
• Rename LogRecord to LogData

Am I missed anything?

[esigo]

Hi @owent, thanks for looking into this. I'd vote for not having a switch for supporting legacy.

[owent]

Without supporting legacy,there will be break changes to SDK and the output of OTLP exporters.Especially the trace APIs are already stable, is it acceptable?

[esigo]

Sure we will have breaking changes here. I'd still vote for not supporting legacy. We are already low on resources, and supporting both legacy and new proto will make maintenance more complicated for us. We can discuss this in the next SIG meeting. I'll update you. cc @lalitb @ThomsonTan

[lalitb]

Thanks, @owent for summarising the changes required.

• Have created a separate issue #1381 to support InstrumentationScope. This shouldn't break the API/SDK for Traces at least. We can discuss the approach for this in the issue.
• For the Logger SDK/API changes (which are part of this issue), we don't need to support the old API.

[lalitb]

#1383 closes it.

[owent]

@lalitb This issue has not be finished completely.I'm waiting for #1413 and then continue to implement LogEmitter, there may be more conflicts if I do it now.

[lalitb]

Yes my bad, we still need to implement LogEmitter. Reopening this issue.

[github-actions[bot]]

This issue was marked as stale due to lack of activity.