Implement concurrent.futures instrumentation for OpenTelemetry contex…

[fenilfaldu]

📥 Pull Request

📘 Description
While implementing mem0 instrumentation, discovered that multiple isolated traces were being created instead of proper parent-child span relationships within a session. This broke the trace hierarchy and made it difficult to understand the flow of operations.

Root Cause: mem0 (and potentially other LLM libraries) uses ThreadPoolExecutor for concurrent operations, but AgentOps lacked instrumentation for thread pool execution contexts. This caused trace context to be lost when operations moved to background threads, resulting in orphaned spans instead of a cohesive trace tree.

• Added a new module for instrumenting the concurrent.futures.ThreadPoolExecutor to ensure proper OpenTelemetry context propagation across threads.
• Introduced the ConcurrentFuturesInstrumentor class, which wraps the ThreadPoolExecutor's initialization and submission methods to maintain context.
• Enhanced the _should_instrument_package function to include utility instrumentors in the instrumentation decision process.
• Updated the TARGET_PACKAGES set to include utility instrumentors for comprehensive monitoring.
• Added unit tests to validate context propagation behavior in concurrent execution scenarios, ensuring spans share trace IDs correctly across threads.

These changes improve the observability and reliability of concurrent operations within the AgentOps SDK.

🧪 Testing
https://gist.github.com/fenilfaldu/e3d2b8479e8a0eee3c10608878e49a2e

[codecov]

Codecov Report

Attention: Patch coverage is 57.73196% with 41 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...trumentation/concurrent_futures/instrumentation.py	44.59%	41 Missing ⚠️

📢 Thoughts on this report? Let us know!

[tcdent]

Nice!

Can you merge in #1021 before I approve since there will likely be some conflicts.

I do like having the constants at the top of instrumentation/__init__.py

[dot-agi]

My primary concern is this should not be instrumented but rather be a part of the core SDK using proper context management and thread handling.

The SDK is responsible for creating the traces, instrumentation, span management and export so it does not make sense for it to be an instrumentation object. Also, monkey patching is for the external libraries and not for the default internal libraries.

Fundamental design issue here so this must be refactored into the core SDK.

[fenilfaldu]

With this instrumentation, context propagation for concurrent.futures only activates when ThreadPoolExecutor is actually used. If we integrate this into the SDK core, the context management overhead would be present for all applications, even those that never use concurrent.futures threading.

The current approach follows the principle of lazy loading - context propagation is only applied when the specific threading mechanism is utilized. This keeps the core SDK lightweight while ensuring robust context handling only where needed.

[dot-agi]

1. Using the code in the gist, I got only 2 LLM calls for the first 2 prompts. Validate this.
2. with trace context management is now a feature but does not work with this.

[fenilfaldu]

On my end, the code correctly traces all LLM calls across prompt and also with trace context management is working fine might be the dependency issue from your side.
Everything is up and running :)

[dot-agi]

We rolling @fenilfaldu 🔥

We need this again Travis