[CSHARP-535] Server type information Created: 23/Jul/12 Updated: 11/Mar/19 Resolved: 06/Apr/15 |
|
| Status: | Closed |
| Project: | C# Driver |
| Component/s: | None |
| Affects Version/s: | 1.6 |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Minor - P4 |
| Reporter: | Aristarkh Zagorodnikov | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Description |
|
Currently, the access to MongoServerInstance.InstanceType is internal. For in-process monitoring purposes, having access to InstanceType (or even better a new property MongoServer.ServerType to distinguish between standalone, RS and mongos) would be very helpful. Examining ReplicaSetName to be non-null is helpful to disgtinguish RS from standalone/mongos, but having a separate property would be better. |
| Comments |
| Comment by Aristarkh Zagorodnikov [ 06/Apr/15 ] |
|
Great news, Craig! We're already testing the 2.0 driver, thank you. |
| Comment by Craig Wilson [ 06/Apr/15 ] |
|
This is information is available from the MongoClient.Cluster.Description.Servers property in the 2.0 driver. |
| Comment by Aristarkh Zagorodnikov [ 24/Jul/12 ] |
|
P.S. The auto-retry framework I told you about is also the primary reason we're so "picky" about exceptions that go out of the driver (see |
| Comment by Aristarkh Zagorodnikov [ 24/Jul/12 ] |
|
A bit more details on the monitoring tool: we use MongoDB.Driver.MongoServer.GetAllServers() to get a list of all servers, then we iterate over each instance of each server and pull their address, kind (by checking the IsArbiter, IsPrimary, IsSecondary and IsPassive properties), connection state and pool stats (current size, active connections, max size). |
| Comment by Aristarkh Zagorodnikov [ 24/Jul/12 ] |
|
We use 1.4 in production, but update from master for internal testing (it would be kinda stupid to ask for new features while looking at old code), sorry for not indicating the real version. To make informed decisions about "safety" of a retry after a certain kind of error we "interrogate" the server object if it's a member of a replica set, or a standalone, or a mongos instance. Having seen that driver now has a sophisticated connection framework (proxies) we would like to use these to be able to have more information to base our decisions to retry or not to retry a piece of code. Also, we have a small in-process (separate thread in the IIS pool) monitoring utility, that iterates over all server we've connected to and builds a human-readable client-side "view" of our cluster and provides access to it via an HTTP handler that is used both by an engineers that diagnoses a certain kind of a problem, along with a monitoring tool (zabbix in our case) that checks the client "version" of MongoDB cluster "health". While logging facility is surely nice to have, realtime introspection and monitoring is very valuable when you debug an immediate problem – it can be done just through a web interface, without sifting through large amount of log records and trying to build a filter that matches your immediate needs. |
| Comment by Craig Wilson [ 24/Jul/12 ] |
|
Are you working off a custom build of master branch? MongoServerInstanceType has not yet been published formally. It will be coming in 1.6. That being said, I'd like to probe a little more about your need for this. 1) Do you not know what type of server setup you are connecting to? In other words, why do you need the driver to tell you whether or not you are connecting to a replica set? 2) What type of monitoring/logging are you doing, and how are you doing it? We have a ticket to build logging into the system and would like to ensure that the information users need is present. 3) When logging gets built-in, then do you still need this feature? |
| Comment by Aristarkh Zagorodnikov [ 23/Jul/12 ] |
|
I also understand that there is a ConnectionMode enumeration, but it is used as an initial value and does not indicate current state (especially if automatic mode is used). |
| Comment by Aristarkh Zagorodnikov [ 23/Jul/12 ] |
|
I understand that there is non-trivial type discovery logic being built via *Proxy classes, so the NotYetKnown/Unknown server type might be used as a default value until discovery does it's job. |