Add auto-configure support for logging-otlp #4879
Conversation
|
|
Codecov ReportBase: 91.18% // Head: 91.13% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #4879 +/- ##
============================================
- Coverage 91.18% 91.13% -0.05%
+ Complexity 4835 4826 -9
============================================
Files 548 545 -3
Lines 14361 14339 -22
Branches 1371 1369 -2
============================================
- Hits 13095 13068 -27
- Misses 876 879 +3
- Partials 390 392 +2
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
ben-roling
force-pushed
the
autoconfigure_logging_otlp
branch
from
b8fc7c5 to
918faf7
Compare
|
please include tests to cover the new code |
| "io.opentelemetry.exporter.logging.otlp.OtlpJsonLoggingLogRecordExporter", | ||
| "OTLP JSON Logging Log Exporter", | ||
| "opentelemetry-exporter-logging-otlp"); | ||
| return OtlpJsonLoggingLogRecordExporter.create(); |
There was a problem hiding this comment.
WDYT about providing a ConfigurableLogRecordExporterProvider and letting the autoconfigure discover the exporter automatically?
There was a problem hiding this comment.
I could give a shot if it's desired. Initially I was just following the code pattern used for the "logging" exporter.
There was a problem hiding this comment.
I've been thinking this may be a good idea to do for all the exporters from a separation of concerns perspective. If each exporter artifact contains a Configurable{Signal}ExporterProvider, then the code to interpret ConfigProperties becomes distributed into each artifacts, reducing the complexity of autoconfigure, especially around testing which has become cumbersome.
What do you think @jkwatson?
BTW, for the purposes of this PR I do think we should continue the current pattern. If we agree on implementing providers, we can open a separate issue to track that work.
There was a problem hiding this comment.
then the code to interpret ConfigProperties becomes distributed into each artifacts, reducing the complexity of autoconfigure, especially around testing which has become cumbersome.
this sounds great, and could help guide users into good practices when they are trying to extend autoconfigure with their own items (e.g. exporters)
There was a problem hiding this comment.
BTW, for the purposes of this PR I do think we should continue the current pattern. If we agree on implementing providers, we can open a separate issue to track that work.
👍
|
Added the "NotOnClasspath" tests in a place where it looked like they belonged. Need to see where any other tests would best fit. |
|
I've added a commit that declares |
|
@jkwatson any remaining concerns about merging this? |
* Add autoconfigure support for logging-otlp * Add NotOnClasspath tests * Fix formatting * Declare logging-otlp as experimental, add unit test * Spotless Co-authored-by: Jack Berg <[email protected]>
As I was starting to play around with opentelemetry I'd tried out the "logging" exporter for some testing/debugging and noticed it didn't quite log all the information I was looking for. Then, I noticed there also existed the classes for "logging-oltp", but no means to auto-configure usage. I tried out these changes and it did the trick.
I'm not sure if omission of auto-configure support for this format might have been intentional?
Anyway, I would appreciate any feedback. Thanks!