[DRIVERS-719] Client Side Support for OpenTelemetry Created: 19/Aug/19  Updated: 09/Oct/23

Status: Defining Requirements
Project: Drivers
Component/s: None
Fix Version/s: None

Type: Epic Priority: Major - P3
Reporter: Esha Bhargava Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Duplicate
Issue split
split to CSHARP-4709 Implement OpenTelemetry distributed t... Backlog
Related
related to GODRIVER-1243 Execution tracing framework Closed
related to CSHARP-3124 Support Activity and DiagnosticsSource Backlog
is related to NODE-5639 Bind current execution context to com... Backlog
is related to DRIVERS-2455 Diagnostic Data Capture for Drivers Closed
is related to GODRIVER-2938 Move ownership of otelmongo Investigating
Quarter: FY24Q3, FY24Q4
Driver Compliance:
Key Status/Resolution FixVersion
CSHARP-4709 Backlog

 Description   

Summary

What is the problem or use case, what are we trying to achieve?

Motivation

Who is the affected end user?

Who are the stakeholders?

How does this affect the end user?

Are they blocked? Are they annoyed? Are they confused?

How likely is it that this problem or use case will occur?

Main path? Edge case?

If the problem does occur, what are the consequences and how severe are they?

Minor annoyance at a log message? Performance concern? Outage/unavailability? Failover can't complete?

Is this issue urgent?

Does this ticket have a required timeline? What is it?

Is this ticket required by a downstream team?

Needed by e.g. Atlas, Shell, Compass?

Is this ticket only for tests?

Is this ticket have any functional impact, or is it just test improvements?

Cast of Characters

Engineering Lead:
Document Author:
POCers:
Product Owner:
Program Manager:
Stakeholders:

Channels & Docs

Slack Channel

[Scope Document|some.url]

[Technical Design Document|some.url]



 Comments   
Comment by Kaitlin Mahar [ 01/Apr/22 ]

Some info on how this might look in Rust: Rust has a tracing crate, which with a log feature enabled can be used to emit both tracing events and log messages (whichever a user is listening for). The async ecosystem seems to be moving in this direction over traditional logging, so we're likely going to use this for our implementation of the logging spec (DRIVERS-1204) so that any users who would prefer to consume our log messages as tracing events with structured data attached can do so. There is existing support for hooking up tracing events to OpenTelemetry via the tracing-opentelemetry crate. Future work could include defining our own spans within the driver; for now any events we publish will just be associated with whatever spans are defined by users. It would be interesting to consider standardizing on tracing spans for drivers to define.

Comment by PM Bot [ 19/Jan/22 ]

If you are not logged in, you can view the tickets in this epic by following this link.

Comment by Simão Ribeiro [ 23/Nov/21 ]

Hi there,

do you have any news regarding the creation of a supported Open Telemetry extension or the inclusion of telemetry in the official driver? The approach suggested by Jimmy Board in CSHARP-3124 seems like a good first step but I think official support is always preferred.

Thanks

Comment by Jeffrey Yemin [ 28/Oct/21 ]

Looking at https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation, it seems like the .NET implementation leverages existing .NET Profiling APIs, which our driver could support directly. Linking to CSHARP-3124.

Comment by Jeffrey Yemin [ 28/Oct/21 ]

As far as I can tell, this would not involve additions to our own drivers. Rather, it would take the form of contributions to https://github.com/open-telemetry, perhaps things like https://github.com/open-telemetry/opentelemetry-java-instrumentation/pulls?q=author%3Ajyemin+, or perhaps entirely new instrumentations for languages where support has not even begun. It needs more research.

Generated at Thu Feb 08 08:22:12 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.