lidavidm commented on a change in pull request #11925:
URL: https://github.com/apache/arrow/pull/11925#discussion_r769812488
##########
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:
> Not totally understanding why a custom JSON format is less risky than
using an upstream component or just having some documentation showing how to
use the collector
Sorry, I meant just in terms of upstream changing APIs on us or something
like that. The approach taken here does use the upstream generated Protobuf
code and they might hide it from the public headers in the future, for instance.
> Libraries should just instrument ideally, and testing can be done by
constructing exporters in tests.
That is the intent, but I think Arrow occupies a halfway point between
library and application, especially when bindings come into play. You can't
enable C++ exporters from Python or R, for instance.
The exporters are not configured by default, for what it's worth - but they
can be enabled by env var. The intent is that for development or testing, the
env var can be used to easily dump spans somewhere, but an application would
not use the env var and would configure its own exporter/tracer provider.
That said, this would all mostly be moot if Conbench ran a collector
alongside test runs.
--
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]
