[SERVER-43832] Expose readConcern and writeConcern defaults in serverStatus Created: 04/Oct/19  Updated: 29/Oct/23  Resolved: 21/Jan/20

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 4.3.3

Type: Task Priority: Major - P3
Reporter: Sheeri Cabral (Inactive) Assignee: Jack Mulrow
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
is documented by DOCS-13358 Investigate changes in SERVER-43832: ... Closed
Related
Backwards Compatibility: Fully Compatible
Sprint: Sharding 2020-01-27
Participants:

 Description   

Specifically, I'd like the following to be exposed in serverStatus (this is from the design document):

 

getDefaultRWConcern
 defaults:
{ readConcern: \{ ... }, // empty obj if not set
 writeConcern: { ... } // empty obj if not set

This is for metrics, to see how many people are using it once it launches.

My assumptions: If a user does not configure it, there will be no object. If a user does configure it, even to the default value, it will exist. (these are assumptions, not requirements, so if you envision something different let's talk)

Example:

user sets readConcern but not writeConcern:

defaultRWConcern:

{ readConcern: "local" , }

 Comments   
Comment by Sheeri Cabral (Inactive) [ 27/Jan/20 ]

I'm OK - the goal was to have an easy way to find it out, and that's what you've done. Thanks!

Comment by Jack Mulrow [ 21/Jan/20 ]

sheeri.cabral, here's a quick summary of what we ended up implementing. Let me know if there's anything you'd like to see changed!

Regardless of if a user has ever set a default read or write concern, the serverStatus output for a server includes by default a "defaultReadWriteConcern" field that maps to a BSON object with the same format as a response from running getDefaultRWConcern.

The contents of this object will be as follows:

  • If a user has never set a default read or write concern:
    • It will only contain the localSetTime field, which will be the wall clock time when the server's cache discovered that no defaults have been set.
      • e.g.

        { defaultRWConcern: { localSetTime: XXX }}
        

  • If a user has set either a default read or write concern:
    • It will contain the localSetTime field (when the server discovered these defaults), the default read and/or write concern (included whether they match the implicit server defaults or not, but only if a user has explicitly set them), and epoch and setTime fields (indicating when the defaults were set to this configuration).
      • e.g. when both a default read and write concern are set:

        { defaultReadWriteConcern: { localSetTime: XXX, setTime: XXX, epoch: XXX, defaultReadConcern: { level: "local" }, defaultWriteConcern: { w: 1, wtimeout: 0 } } }
        

      • e.g. when only write concern is set:

        { defaultReadWriteConcern: { localSetTime: XXX, setTime: XXX, epoch: XXX, defaultWriteConcern: { w: 1, wtimeout: 0 } } }
        

      • e.g. when only read concern is set:

        { defaultReadWriteConcern: { localSetTime: XXX, setTime: XXX, epoch: XXX, defaultReadConcern: { level: "local" } } }
        

  • If a user has set either a default read or write concern and then unsets both:
    • It will contain only localSetTime, epoch, and setTime, where epoch and setTime indicate when the defaults were unset.
      • e.g.

        { defaultReadWriteConcern: { localSetTime: XXX, setTime: XXX, epoch: XXX } } 

So if we want to see how many users are using this feature, instead of checking for the presence of a defaultRWConcern object, we can do so by checking for the presence of either epoch or setTime in the defaultRWConcern object.

Comment by Githook User [ 21/Jan/20 ]

Author:

{'username': 'jsmulrow', 'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com'}

Message: SERVER-43832 Expose readConcern and writeConcern defaults in serverStatus
Branch: master
https://github.com/mongodb/mongo/commit/9c638e3cb001a4dc9fcf869d2602c504439c2aef

Comment by Bruce Lucas (Inactive) [ 14/Jan/20 ]

That seems like a good strategy, not just because of space concerns, but also since most readConcern and writeConcern values are strings, which would not be captured in the once-per-second samples anyway (although confusingly if the w: and j: numeric values were present they would be captured).

Comment by Kevin Pulo [ 14/Jan/20 ]

kaloian.manassiev and I discussed this the other day. Just to capture the outcome, this should be in a new serverStatus section, which is on by default but disabled when serverStatus is called by FTDC. At the same time, FTDC should collect getDefaultRWConcern on rotate (ie. alongside buildInfo, getCmdLineOpts, and hostInfo). This way, users and regular monitoring will see the defaults (if any) in serverStatus, and FTDC will also get the defaults but only every 5 minutes rather than every second.

Generated at Thu Feb 08 05:04:14 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.