[CSHARP-1639] Add method call for .NET profilers to hook to get query Created: 26/Apr/16 Updated: 31/Mar/22 |
|
| Status: | Backlog |
| Project: | C# Driver |
| Component/s: | Diagnostics |
| Affects Version/s: | 2.2.4 |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Minor - P4 |
| Reporter: | Matt Watson | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 2 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Description |
|
I'm trying to figure out the best way to capture the BsonDocument when queries are executed for the purposes of performance profiling. I am specifically trying to show mongodb queries in the Prefix.io profiler, which is a free tool for .NET developers. I played with ClusterBuilder Subscribe() event hooks for CommandStartedEvent and they work great. The problem is this would require someone to change their code every place they create a MongoClient or MongoClientSettings. That is not an idea solution as we want to be transparent and not require any changes. I would like to propose some global events that can be used. All I really need is the ability to set a bool on CommandEventHelper that enables the "Profiler Hook" additional methods and then some private methods would be called that don't actually do anything. Do you mind if I do this and submit a PR? Any other ideas on an easy to globally see the json for all commands sent to mongodb? Pseudo code for what I need is something like this, although I did the example in CommandStartEvent instead of CommandEventHelper for simplicity of the example:
|
| Comments |
| Comment by Vadim Hatsura [ 10/Jul/19 ] |
|
Hey, Craig Wilson! Can we return to this discussion? Using DiagnosticSource is nice to have due to popular tracing solutions uses information from diagnostic sources out-of-the-box. |
| Comment by Craig Wilson [ 27/Apr/16 ] |
|
Hi Matt, So, I looked at it just today to see if I could point you in a direction. We are currently targeting .NET 4.5 and it doesn't seem like DiagnosticSource supports that currently. We are working on .NET Core support and I will come back and look this after we get that finished since we'll have to move up our .NET target (at least for the .NET core part) to this. Craig |
| Comment by Matt Watson [ 26/Apr/16 ] |
|
Recursion due to logging will always be a potential issue if people wants to log mongodb logs... to mongodb. I'm trying to basically get logging our of the client library itself, and I'm definitely not going to be logging or writing data to mongodb. Diagnostics sources sound like a great solution and may work well for what I need. I currently use ETW events for similar type functions and I'm very familiar with it. Do you want some help implementing it? I would be glad to work on it, even if it is just the beginnings of it to help do what I selfishly need it to do. Thanks! |
| Comment by Craig Wilson [ 26/Apr/16 ] |
|
Hi Matt, Before you head off on this endeavor, let us talk about it internally for a little. The reason we don't have global hooks is because this is a generic eventing system which powers statistics (like what you're doing or performance counters) as well as logging. And because people use MongoDB for logging, we could get into a recursive problem if they added a logging hook globally. Separately, we are also considering moving to using the DiagnosticSource package (https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md) to enable certain things we don't currently do (although the above caveat about logging to MongoDB might make this troublesome as well). As a side note: I'd caution you about creating many MongoClient objects pointing at the same cluster. While we attempt to have each MongoClient share connection pools, when you use the ClusterBuilder, all bets are off and each client has its own pool. You should try to use MongoClients in a singleton manner. If this were to happen, then you would only have one place to install your hook. Craig |