Client Side Support for OpenTelemetry

    • Type: Epic
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Client Side Tracing
    • Python Drivers
    • Needed
    • Example of usage provided in PYTHON-5052's comments.
    • In Progress
    • 🔵 Done
    • None
    • Hide

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


      Show
      2026-01-07 - 🔵 Done No project update provided
    • 2
    • 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  
    • None
    • None
    • None
    • None
    • None
    • None
    • None

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

      Questions and answers posed by the spike in PYTHON-5744:

      • 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.
        • Answer: it cannot. The spec requires different functionality than the package supports. Additionally, relying on the existing package would not allow useful consolidation of our telemetry APIs.
      • 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?
        • Answer: We are 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?
        • Answer: Spans are begun when an operation begins, and are completed when that operation finishes either successfully or with an error. Our proposed unified telemetry API would make this tracking simple.
      • Can we use our existing debug logging code to guide our OpenTelemetry support?
        • Answer: Yes. We plan to unify our telemetry APIs so that a single call is used to record for any of the enabled telemetries.
      • 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.
        • Answer: Yes.

            Assignee:
            Noah Stapp
            Reporter:
            TPM Jira Automations Bot
            None
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              None
              None
              None
              None
              None