initial commit of logging support extension#1524
initial commit of logging support extension#1524anuraaga merged 27 commits intoopen-telemetry:masterfrom
Conversation
|
Thanks for this contribution. I'm surprised that we would recommend having the SDK itself handle logging exports, rather than using a more robust log forwarder. Logging can be extremely high volume, and generally has very high availability & delivery guarantees. Are we sure that this is the right solution for OpenTelemetry logging, rather than just using a standard log forwarding solution? I haven't followed the logging SIG much at all, but I'm surprised that this would be the recommended solution for OTel logging. Can you point me at a document that recommends this approach? |
|
I think that we are going to have multiple routes for log delivery- one would be to use existing logging appenders/infrastructure, but adding request correlation fields. We also want to be able to support unified collection through the collector, however, as described in 0092-logs-vision.md. My intent for this API is to essentially be a minimal middleman that can take logs from user-centric APIs like Log4j/Logback and pass them to an exporter than can handle forwarding to whatever destination, whether it's the collector/OTLP or an existing log aggregator like Fluentd/Logstash/Flume/Splunk HEC/etc. |
|
Looking forward to this, then I can bring back open-telemetry/opentelemetry-java-instrumentation#803 😄 |
Codecov Report
@@ Coverage Diff @@
## master #1524 +/- ##
=========================================
Coverage 85.36% 85.36%
Complexity 1385 1385
=========================================
Files 164 164
Lines 5445 5445
Branches 562 562
=========================================
Hits 4648 4648
Misses 590 590
Partials 207 207 Continue to review full report at Codecov.
|
…logging/api/LogRecord.java Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>
… into logging_extension_rework
rename Exporter to LogExporter, move to 'export' package rename LogExporter.accept(data) to LogExporter.export(data) decrease flush interval from 5000 to 200ms return CompletableResultCode from LogExporter.shutdown() change traceId and spanId types to String from byte[]
|
To summarize:
|
bogdandrutu
left a comment
There was a problem hiding this comment.
I think this is a good starting point. Maybe add a README with a note that this is in alpha stage.
… into logging_extension
… into logging_extension
… into logging_extension
|
I don't see any unresolved comments. Is there anything else needed before merging this PR? |
|
Sorry for the delay, thanks for the hard work! |
This PR brings a logging delivery API extension. The intent is to allow exporters for existing logging libraries to be built that can then deliver log entries in a way that's consistent with log and tracing support. This PR is infrastructure; if merged, the next PR will be an exporter that uses this infrastructure to deliver logs through the collector via OTLP. The Log4j extension (open-telemetry/opentelemetry-java-instrumentation#735) can then be augmented to optionally deliver logs via this API and export modules for additional libraries can be written.