Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is meant to prompt discussion. Proves out what an
OpenTelemetryAppender
might look like for log4j2. The idea behind this appender is that it delivers log records to a opentelemetryLogSink
, where they can be batched and shipped out of process via an exporter, such as the recently added OTLP grpc and http log exporters.One of the main problems I had to address was that log appenders are instantiated before the opentelemetry log sdk is available. To get around this, each
OpenTelemetryAppender
instance is statically registered after initialization. Once the otel log sdk is available, it is passed to eachOpnTelemetryAppender
instance via a static method, upon which log records start flowing.Learnings so far:
""
values.InMemoryLoggingExporter
for testing. Mocked it out in this code, and will contribute back toopentelemetry-java
.SimpleLogProcessor
for testing. Mocked it out in this code, and will contribute back toopentelemetry-java
.LogSinkSdkProvider.builder()
is not public but needs to be for it to be useful. I'll make it so.LogSinkSdkProvider
should be immutable after its created. Log processors should be registered with the builder, not with the instance. I'll make it so.LogSink
is responsible for creatingLogRecord
s with resource and instrumenation library attached. This means that components like theOpenTelemetryAppender
need to maintain fields for these. ShouldLogSink
acceptLogRecords
without resource and instrumenation library, and let the pipeline attach those?