Define what's in scope for OpenTelemetry Logs GA (post traces and metrics 1.0 GA) #130
Conversation
tigrannajaryan
changed the title
tigrannajaryan
force-pushed
the
feature/tigran/logscope
branch
from
5f48329
to
e60339f
Compare
Clearly defined scope is important to align all logs contributors and to make sure we know what target we are working towards. Note that some of the listed items are already fully or partially implemented but are still listed for completeness.
tigrannajaryan
force-pushed
the
feature/tigran/logscope
branch
from
e60339f
to
19f58bc
Compare
| - Implement OpenTelemetry logs SDK for Java that support trace context | ||
| extraction from the current execution context. | ||
|
|
||
| - Implement appenders for Log4J using OpenTelemetry SDK that automatically |
There was a problem hiding this comment.
appenders are not part of the slf4j api, they are implementor specific (e.g. ch.qos.logback.core.Appender or org.apache.logging.log4j.core.Appender)
There was a problem hiding this comment.
I have no particular preference for which Java logging library to support. I can change to SFL4J if it is a more popular/preferable library for the community.
The goal here is not to have comprehensive coverage of all Java application needs, but rather to set an example and clearly demonstrate how OpenTelemetry logging SDK can be used with a logging library.
There was a problem hiding this comment.
I would say appenders for at least one of the major logging library?
There was a problem hiding this comment.
That's a good point, let me rephrase to avoid mentioning a specific library. The decision on which library to support and how exactly does not need to happen right now.
There was a problem hiding this comment.
Re-worded, please check again.
There was a problem hiding this comment.
I think that it's important to have a solution that works generally- in the Java world, at least Log4j, Log4j2, Logback, and java.util.logging (though obviously we start with one).
There was a problem hiding this comment.
Sounds good, I think the text now reflects this.
@MrAlias GA here means "whenever we decide to GA logs support", not the upcoming GA where only trace and metrics will be supported. I should probably remove the reference to 1.0 to avoid confusion. |
Ah, gotcha. Thanks for the clarification 👍 |
tigrannajaryan
changed the title
|
@MrAlias I clarified what "GA" means in the doc. |
| FluentBit/FluentD. | ||
|
|
||
| - Add support for log data type to the following processors: `resource`, | ||
| `batch`, `attributes`, `k8s_tagger`, `resourcedetection`. |
There was a problem hiding this comment.
queued_retry is being deprecated and the equivalent functionality is moved to exporters (and support for logs already exists).
There was a problem hiding this comment.
filter is currently a metric-only processor. Not sure if logs support needs to be part of the GA. We probably need to add it for logs, but first it will probably happen for traces.
Clearly defined scope is important to align all logs contributors and to make
sure we know what target we are working towards. Note that some of the listed
items are already fully or partially implemented but are still listed for
completeness.
This OTEP shows the initial scope proposal. Please suggest additions or changes
to the scope and I will include them in this PR.