birschick-bq commented on issue #2210:
URL: https://github.com/apache/arrow-adbc/issues/2210#issuecomment-2830937723
> It somewhat concerns me that we're trying to build that much in terms of
"smarts" directly into the driver, though. Wouldn't the typical approach be to
deploy a collector and let it handle the complex config? Especially if multiple
drivers come into play
Yes. Totally yes - for OTLP.
If the OTel Collector (or other remote OTLP endpoint) is the ONLY means to
export and collect telemetry, then minimally we'd need ...
1. For languages were `OTEL_TRACES_EXPORTER` is not directly supported in
the OTel SDK, we'll have to read that environment variable and implement as
best as possible. Typically `otlp`, `console`, and `none` should be trivial.
2. OTLP Endpoint URI, Header, Protocol, etc. That configuration seems to be
already handled in most OTel SDK runtimes ...
| Feature | Go | Java | JS
| Python | Ruby | Erlang | PHP | Rust | C++ | .NET | Swift |
|----------------------------------------------------------|----|------|----|-------------|------|--------|-----|------|-----|------|-------|
| OTEL_EXPORTER_OTLP_* | + | + |
| + | + | + | + | + | + | + | -
---
> If there's a file based model, though, then we could just add one standard
config option to load a config file?
Unfortunately, it is still in development. I think we run the risk of
creating our own design that would have to be replaced at a later time.
--
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: github-unsubscr...@arrow.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
