[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 CSHARP-534).

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).
Of course all this can be monitored server-side via log analyzer, but having runtime "snapshots" of this kind of data per-backend is very helpful in diagnosing intermittent LAN problems, connection management issues and client-side performance bottlenecks (especially when you graph the per-instance pool stats).

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.
A little backstory: we implemeted a set of wrapper methods that accept a collection/server and an function object, that executes the passed function (which calls into the driver code), catches exceptions and decides if it's safe (or even needed) to auto-retry the operation. The rationale for auto-retrying is that when using driver directly, transient failures (primary just gone down, election not yet completed, one mongos instance of three is gone, etc.) the driver throws an exception. This is perfectly fine, because only the application should know whether it wants (or even can) to retry the operation. Of course, we're not trying to cover all the cases, only the most common ones (socket exception, I/O error, primary gone, etc.). It's a bit more complex than I describe, but I think this explanation is sufficient.

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.

Generated at Wed Feb 07 21:37:07 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.