opentelemetry-cpp
opentelemetry-cpp copied to clipboard
Add support for event driven framework
This would be eventually required for
- To support async interface between span/log processor and exporters.
- Async IO while exporting the spans.
- Timers to poll for Spans in BatchSpanProcessor, and metrics in PeriodicMetricReader.
- Asynchronously collect metrics for all the instruments across all the meters ( this would be a costly operation sequentially or even using threads).
References:
- #63 - Initial work has been done in this PR.
- hiredis: event adaptor used by Redis database as suggested by @owent
- libwebsockets - Suggested by @owent
This issue was marked as stale due to lack of activity. It will be closed in 7 days if no furthur activity occurs.
Closed as inactive. Feel free to reopen if this is still an issue.
Note: This issue is simular to https://github.com/grpc/grpc/issues/20194 of grpc
We should also support to share our event loop with grpc's in the future.
Quoting https://github.com/grpc/grpc/issues/20194#issue-490393542:
In order for an API to integrate into a foreign event loop, it needs to provide a polling interface as well as a callback function which can be used to signal a mutex condition to wake up, or activate an eventfd, or put an item on a kqueue, etc.
To develop on Zig's Andrew comment, nested quote above:
Say opentelemetry-cpp client (OTC) has its own whatnot event-loop, then to integrate that event-loop to a hosting application (APP) that has also an event-loop; OTC need to provide:
- a way to notify APP that OTC has io work to do [^1]
- a way to wake up OTC's event-loop for one iteration [^2]
[^1]: it may be polling as an OTC function that is regularly called by APP; or nest epoll_create1
fd, or io_uring_setup
fd;
[^2]: see libuv's UV_RUN_ONCE
to actually do the io work;
That should work when there is a dedicated POSIX thread for OTC's whatnot event-loop running the exporter. It is also the best time-to-market way to make OTC work better with async apps.
There is more work if OTC's event-loop need to run in the same POSIX thread as APP's event-loop; and there is even more work if OTC need to re-use APP's event-loop. In the latter case, OTC requires something like an n+1 eventloop library ala hiredis, and libwebsockets adapters.
Next step is too choose what "integration" opentelemetry-cpp need:
- Dedicated POSIX thread => Choose an eventloop library;
- APP, and OTC have different eventloops in one POSIX thread => Choose an eventloop;
- APP, and OTC share the same eventloop;
At some point to achieve the "async dream" exporters will also need to be aware of OTC's event-loop; in the meantime, we call Exporter::ExportResult
, and Exporter::ForceFlush
in one-shot POSIX threads;