Loading...

XML

Word

Printable

JSON

Epic Name:
Client Side Tracing
Assigned Teams:

Python Drivers
Documentation Changes:
Needed
Documentation Changes Summary:
Example of usage provided in PYTHON-5052's comments.
Epic Status:
In Progress

Quarter:
- FY27Q1-candidate
Confidence Status:
🔵 Done
Latest Project Update:
None
Detailed Project Statuses:

Hide

2026-01-07 - 🔵 Done
No project update provided

Show
2026-01-07 - 🔵 Done No project update provided
Estimated Weeks:
2

Upstream Changes Summary:
Hide

Summary of necessary driver changes

Commits for syncing spec/prose tests
(and/or refer to an existing language POC if needed)

Context for other referenced/linked tickets
Show
Summary of necessary driver changes Commits for syncing spec/prose tests (and/or refer to an existing language POC if needed) Context for other referenced/linked tickets

This ticket was split from DRIVERS-719, please see that ticket for a detailed description.

Context
This spike is scoped to the following:

Determine if the existing opentelemetry-instrumentation-pymongo package can be used as the underlying implementation for PyMongo's OpenTelemetry support in accordance with the spec.
If opentelemetry-instrumentation-pymongo isn't suitable for implementing the spec, can we contribute to it upstream to make it suitable? Or are we better off creating our own internal solution?
The spec details specific OpenTelemetry span attributes to be recorded for each driver operation. What does that recording look like over the lifecycle of a PyMongo operation?
Can we use our existing debug logging code to guide our OpenTelemetry support?
Does abstracting both debug logging and OpenTelemetry logging into a single, centralized design make sense? Both appear to gather similar information at similar points, reducing duplication would be ideal.

is duplicated by

MOTOR-1425 Client Side Support for OpenTelemetry

split from

DRIVERS-719 Client Side Support for OpenTelemetry