Resolved
Pinned fields
Click on the next to a field label to start pinning.
Details
Details
Assignee
Sergey Auseyau
Sergey AuseyauReporter
Sergey Auseyau
Sergey AuseyauSprint
Add sprint
Story Points
3
Priority
Instabug
Open Instabug
Sentry
Sentry
Zendesk Support
Zendesk Support
Created May 6, 2025 at 5:55 PM
Updated May 27, 2025 at 5:27 PM
Resolved May 27, 2025 at 5:27 PM
So there are still two options that we can go with OpenTelemetry in C++SDK and wrappers:
1) As we already doing with the logs. Cache the log messages while the
operation is on the C++SDK side, and then allow the wrapper to flush/collect
the cached messages once the operation is completed and GVL/GIL lock is
aquired.
This approach also taken by the gRPC project in regard to Observability
https://github.com/grpc/grpc/tree/master/src/python/grpcio_observability#how-grpc-python-observability-works
> gRPC Python is a wrapper layer built upon the gRPC Core (written in C/C++).
> Most of telemetry data is collected at core layer and then exported to Python
> layer. To optimize performance and reduce the overhead of acquiring the GIL too
> frequently, telemetry data is initially cached at the Core layer and then
> exported to the Python layer in batches.
>
> Note that while this approach enhances efficiency, it will introduce a slight
> delay between the time the data is collected and the time it becomes available
> through Python exporters.
Just like they said, we will have the same tradeoffs: efficiency for
realtimeness of metrics/traces.
2) The wrapper might compile some dependencies from opentelemetry-cpp SDK
directly into the core BLOB. This allows to let the core to send its
metrics/traces directly to the collector. While we cannot compile in all the
exporters, we still can do it to the most common one and that come with the
SDK. For example OTLP exporters.
So the next step would be to build the caching collector similar to what gRPC
project has, and also try to provide support for the wrapper to enable direct
support of OTLP exporters.