opentelemetry-rust
opentelemetry-rust copied to clipboard
[Feature]: Support Metrics, BatchProcessor without async runtime
Related Problems?
No response
Describe the solution you'd like:
Discussed originally here : https://github.com/open-telemetry/opentelemetry-rust/pull/1308#issuecomment-1774468050
We need to support metrics aggregation and batchprocessors for user who do not use any async runtimes. We might be able to spin up a dedicated background thread to achieve this.
Considered Alternatives
No response
Additional Context
No response
As tried here, the ticks are coming very unpredictably. It is always off by ~2-5 secs. I'll check if using a dedicated thread will improve accuracy, and enable Metrics to work without any async runtimes. (for those users who prefer that!)
This requires more work than anticipated. While the idea of using dedicated background threads work when the exporters does not need IO/Network calls (like Exporting to ETW), it cannot be used when Exporter needs to do network calls. For examples, none of the gRPC and HttpClient libraries that are used by OTLP Exporter can be used from outside on an async runtime (Its TBD if they work with any runtime or just tokio).
Hence, the exporters should be modified to detect if they are in async-runtimes or not, and then based on that, use the async or blocking variant of the clients.
This issue extends beyond BatchProcessor. SimpleProcessor is currently fundamentally broken when used with OTLP, as shown here and here.
Next steps:
- Fix OTLP/other Exporters to detect runtime and pick between async and blocking. This should unblock and fix the broken state of SimpleProcessors.
- Once 1 is done, modify BatchProcessor/Metrics to use dedicated thread, and continue to offer the existing mechanism of async-runtimes, based on feature flags.
- Decide on the defaults - should dedicated thread be the default? or something else?