You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We need to implement integration for universal profiling in order to enable trace correlation. Differently than the java agent I'd like to implement most of the code in Python and only pass the data to the C extension to store it in the well known variables.
After playing a bit with implementing a python extension I think the issue is more on sorting out the life cycle of things more than in the coding itself. For the process wide data this is mostly static so just have to do it at startup, we need to add a thread (ThreadManager?) that handles the communication with the profiling agent via the shared socket. For the threading specific one need to sort out where to update the data, maybe there's some hook in the context handling?
Another requirements is to buffer the spans for samples-delay-ms as sent in the profiler registration message, in order to let the profiler send the corresponding traces ids via the messaging socket. That would require a way for the thread reading the socket to send data to its parent process (use a Queue to send data and then implement of a cache that the exporter can use?).
Open issues from the profiler side:
profiler registration message still not implemented
We need to implement integration for universal profiling in order to enable trace correlation. Differently than the java agent I'd like to implement most of the code in Python and only pass the data to the C extension to store it in the well known variables.
After playing a bit with implementing a python extension I think the issue is more on sorting out the life cycle of things more than in the coding itself. For the process wide data this is mostly static so just have to do it at startup, we need to add a thread (ThreadManager?) that handles the communication with the profiling agent via the shared socket. For the threading specific one need to sort out where to update the data, maybe there's some hook in the context handling?
Another requirements is to buffer the spans for
samples-delay-ms
as sent in the profiler registration message, in order to let the profiler send the corresponding traces ids via the messaging socket. That would require a way for the thread reading the socket to send data to its parent process (use a Queue to send data and then implement of a cache that the exporter can use?).Open issues from the profiler side:
Open issues with upstream OTel
Open issues from our side
samples-delay-ms
The text was updated successfully, but these errors were encountered: