Introduce gauges to track values over time, like open connections, in-flight requests, etc.
We currently expose point-in-time information of the state of the driver, via Session.GetState(), like open connections and in-flight requests and the user has to manually export it to a reporter or sink, if needed. Maybe we could expose them as gauges, even though there is no built-in support for that (similar to ETW for Windows or LTTNG for Linux).
There are several metrics libraries that provide the notion Gauge but none of them are very popular. Also, without an equivalent of JMX, a library can help with reporting but it must be defined in the application explicitly.
In any case, AppMetrics looks promising for Gauges but its too recent (user base seems small). It's based on Metrics.NET, which is a port of Java Dropwizard Metrics library. AppMetrics supports .NET 4.5.2+ and .NET Standard 1.6+ (it doesn't support .NET Standard 1.5 which we support).
Edit: Attached a list of metrics available in java driver 4.x
I'm glad to know that you will continue development on this feature, that's good news! Do note that it will take some time until I can look at the PR and even more time until I can start contributing to this feature myself. As I said before our top priority for this feature at this time is the API design.
1. I don't think this is too early to discuss this because this can potentially influence how you continue developing this feature. Looking at your branch I see that you have a method in the Builder class that allows users to provide a IMetricsRoot implementation. This means that users will have to install App.Metrics on their own application and build code to create a Metrics instance and provide it to the driver. I do agree that this is an advanced use case that should be supported but by default the driver should create the Metrics instance itself and allow users to get it with something like cluster.GetMetrics().
2. If a user is interested in those kind of metrics the best way to look for them is actually the server itself. DSE and Apache Cassandra both have ways to obtain those kind of metrics that you mention per keyspace, per table and per host. If the user is interested in metrics related to specific queries which target a specific keyspace and table then he/she is probably more interested in implementing additional metrics that are specific to that application (by reusing the App.Metrics instance that is being used on the driver for example).
For metrics by host I do agree that these make sense since they are extremely useful to troubleshoot network issues and the driver always knows which host is being used for a specific request. We can look at NodeMetrics implementation of the java driver 4.x for reference.
Also, if the interest in metrics per ks/table is because it would be useful to troubleshoot latency issues related to specific requests then https://datastax-oss.atlassian.net/browse/CSHARP-674 would be the best way to address that.
Sorry for my late response.
I finally create initial PR to the driver - https://github.com/datastax/csharp-driver/pull/447.
Hope you are still interested in our help with this feature and our sketch of the implementation fits good-enough in your code base. We are ready to continue work and fix issues that you can mention.
Thank you for going ahead with an initial PR!
Just a heads up: I don't think I will be able to look at it during this week but I think I can at least start reviewing next week. Since it is a huge PR, I expect that it will take some time to review the whole thing but I will try to leave comments as I go through the changeset.
Unfortunately I won't be able to look at the PR this week and possibly won't be able to in the next week. We have a couple more tickets to go through for the next release of the driver and after that I will definitely start reviewing the PR.