cpcloud commented on a change in pull request #11925:
URL: https://github.com/apache/arrow/pull/11925#discussion_r769801773
##########
File path: cpp/src/arrow/util/tracing_internal.cc
##########
@@ -53,6 +60,43 @@ namespace {
namespace sdktrace = opentelemetry::sdk::trace;
+// Custom JSON stdout exporter. Leverages the OTLP HTTP exporter's
+// utilities to log the same format that would be sent to OTLP.
Review comment:
Interesting. Typically, the collector usage is deploying a container
alongside the application, so without knowing anything else I'm not sure why it
would be a lot more work.
@lidavidm and I went back and forth on the original PR about this, but I'm
generally -1 on adding an exporter because exporters force a choice when used
inside of a library. The Otel docs are pretty clear on how to use it within
libraries
(https://opentelemetry.io/docs/concepts/instrumenting-library/#opentelemetry-api)
Libraries should *just* instrument ideally, and testing can be done by
constructing exporters in tests.
Including an exporter inside a library can also easily conflict with an
application's N other exporters.
If these exporters are included I think they should be restricted to only
when tests are being compiled.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
