Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature]: Support Metrics, BatchProcessor without async runtime #1437

Open
cijothomas opened this issue Dec 12, 2023 · 2 comments
Open

[Feature]: Support Metrics, BatchProcessor without async runtime #1437

cijothomas opened this issue Dec 12, 2023 · 2 comments
Assignees
Labels
A-common Area:common issues that not related to specific pillar A-metrics Area: issues related to metrics enhancement New feature or request

Comments

@cijothomas
Copy link
Member

Related Problems?

No response

Describe the solution you'd like:

Discussed originally here : #1308 (comment)

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

@cijothomas cijothomas added enhancement New feature or request triage:todo Needs to be traiged. A-metrics Area: issues related to metrics A-common Area:common issues that not related to specific pillar labels Dec 12, 2023
@lalitb lalitb self-assigned this Dec 14, 2023
@cijothomas cijothomas removed the triage:todo Needs to be traiged. label Apr 18, 2024
@cijothomas
Copy link
Member Author

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!)

@cijothomas
Copy link
Member Author

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:

  1. Fix OTLP/other Exporters to detect runtime and pick between async and blocking. This should unblock and fix the broken state of SimpleProcessors.
  2. 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.
  3. Decide on the defaults - should dedicated thread be the default? or something else?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-common Area:common issues that not related to specific pillar A-metrics Area: issues related to metrics enhancement New feature or request
Projects
None yet
2 participants