-
Notifications
You must be signed in to change notification settings - Fork 341
Add diagnostics support #493
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
8000 Already on GitHub? Sign in to your account
Add diagnostics support #493
Conversation
See similar npgsql PR: npgsql/npgsql#1910 |
/// </summary> | ||
internal static class DiagnosticListenerExtensions | ||
{ | ||
public const string DiagnosticListenerName = "MySqlClientDiagnosticListener"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Per the guide:
DO NOT - name the listener after the Listener (thus something like System.Net.HttpDiagnosticListener is bad).
MySqlConnector
seems like the right name for the diagnostic listener.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As @roji wrote on his PR, separate DiagnosticListeners for Connection, Transaction, and Command seem to fit the guidelines better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
{ | ||
public const string DiagnosticListenerName = "MySqlClientDiagnosticListener"; | ||
|
||
private const string MySqlClientPrefix = "System.Data.MySqlClient."; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Drop this prefix.
DO - keep the names reasonably short (< 16 characters). Keep in mind that event names are already qualified by the Listener so the name only needs to be unique within a listener.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
private const string MySqlClientPrefix = "System.Data.MySqlClient."; | ||
|
||
public const string SqlBeforeExecuteCommand = MySqlClientPrefix + nameof(WriteCommandBefore); | ||
public const string SqlAfterExecuteCommand = MySqlClientPrefix + nameof(WriteCommandAfter); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The guide recommends "Start" and "Stop", not "Before" and "After".
DO - use the 'Start' and 'Stop' suffixes for events that define an interval of time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
Before I review this PR too much further, I added a comment about the general approach here: npgsql/npgsql#1910 (comment) |
Benchmark Report: OS : Windows 10 Concurrency Testing
Add Diagnostics Before:
Add Diagnostics After(Disable Listener):
Add Diagnostics After(Enabled Listener):
|
Thanks for the benchmarks; that's looking good. I feel strongly that this implementation should be aligned with npgsql, so will just wait for some questions on that PR (npgsql/npgsql#1910 (comment)) to be answered. |
How is it going? We need this feature to support tracing. |
I'd like to have some consensus from @roji et al around supporting/implementing this consistently in the ADO.NET ecosystem. |
Looks like this has been sat for a while? @bgrainger are you happy with the responses are does there need to be more work? I'd be happy to put some effort in if there's a desire to get this out. |
The main blocking issue for me is that we still don't have a clear understanding of how this should be implemented (consistently) across the ADO.NET ecosystem (or at least M.D.SqlClient, npgsql, and MySqlConnector). It still seems that .NET tracing/diagnostics is a WIP, e.g., see the discussion about Is ADO.NET tracing going to use An issue tracking this is dotnet/runtime#26085 but it seems to have stalled out. So: help is need 8000 ed/wanted but I think the next step is writing, circulating, and getting approval for a proposal, not writing C# code. |
I really agree with this - we should try to avoid every provider doing its own thing here. We should definitely try to get a good, consistent ADO.NET diagnostics story in for .NET 6.0 (which providers such as MySqlConnector/Npgsql could implement early as long as consensus is reached). |
Hey all - I'm a maintainer on the C# .NET OpenTelemetry project, which after working with Microsoft engineers, we have settled on using the newer Activity based diagnostics API. There are examples of tooling and frameworks being instrumented in both the main and contrib repositories. If you have any questions regarding this, let me know and I can try to answer. |
Those repositories are https://github.com/open-telemetry/opentelemetry-dotnet/tree/master/examples and https://github.com/open-telemetry/opentelemetry-dotnet-contrib, is that correct? |
Any thoughts on this @bgrainger? I'm going to need to look at a workaround is all. |
I'm not going to merge this PR as (aside from the merge conflicts) I expect that the final solution will use the new @martinjt For now, you will probably need to use a workaround if you need something before then :( One way to work around it is to write your own |
Add diagnostics support for
MySqlConnection
,MySqlCommand
,MySqlTransaction