[SERVER-57609] Print additional log line during startup showing all non-default parameters and values Created: 10/Jun/21  Updated: 29/Oct/23  Resolved: 24/Feb/22

Status: Closed
Project: Core Server
Component/s: Diagnostics
Affects Version/s: None
Fix Version/s: 6.0.0-rc0

Type: New Feature Priority: Major - P3
Reporter: Dmitry Agranat Assignee: Billy Donahue
Resolution: Fixed Votes: 0
Labels: auto-reverted, needs-triage, servicearch-wfbf-day
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
is related to SERVER-58506 Command to expose settability for Ser... Closed
Backwards Compatibility: Fully Compatible
Sprint: Service Arch 2022-1-10, Service Arch 2022-1-24, Service Arch 2022-2-21, Service Arch 2022-03-07
Participants:
Linked BF Score: 135
Story Points: 4

 Description   

Today, it is very difficult to troubleshoot issues when their cause is related to the use of a non-default server parameter or values.

It would be useful to have an additional log line highlighting everything non-default. Just by looking at this line can give us a hint where the issue might be originating.

Today, it is also not possible to understand if currently-printed values are default or not. One would have to go to documentation and validate each and every value to understand this.

This would also help to avoid issues when some previously used parameter/value is being unintentionally dragged into the newer version.



 Comments   
Comment by Githook User [ 24/Feb/22 ]

Author:

{'name': 'Billy Donahue', 'email': 'billy.donahue@mongodb.com', 'username': 'BillyDonahue'}

Message: SERVER-57609 ServerParameter append opCtx can be null
Branch: master
https://github.com/10gen/mongo-enterprise-modules/commit/1a43a721a151dbf2f4b98238872ea96df2b64bd4

Comment by Billy Donahue [ 24/Feb/22 ]

KeystoreSchemaVersionServerParameter dereferences a null opCtx pointer.
see BF-24374

Comment by Billy Donahue [ 20/Feb/22 ]

A parameter in enterprise, when told to append itself to an obj builder under a certain field name, just didn't do anything at all.
Re-commit deals with this possibility.

Comment by Githook User [ 20/Feb/22 ]

Author:

{'name': 'Billy Donahue', 'email': 'billy.donahue@mongodb.com', 'username': 'BillyDonahue'}

Message: SERVER-57609 log the effects of --setParameter at startup

This reverts commit e54ce1af26d960c085115fa500b43acb64d37542.
Branch: master
https://github.com/mongodb/mongo/commit/125deb74c63c74f46b0c53f49d3b229592b510bb

Comment by xgen-buildbaron-user [ 19/Feb/22 ]

Ticket re-opened due to revert. ese began a consistent failure of src/mongo/db/modules/enterprise/jstests/encryptdb/database_key_upgrade.js

Comment by Githook User [ 19/Feb/22 ]

Author:

{'name': 'auto-revert-processor', 'email': 'dev-prod-dag@mongodb.com'}

Message: Revert "SERVER-57609 log the effects of --setParameter at startup"

This reverts commit 2716c8012c2c21c5e3c9f695d4d6a0751aff01ba.
Branch: master
https://github.com/mongodb/mongo/commit/e54ce1af26d960c085115fa500b43acb64d37542

Comment by Billy Donahue [ 18/Feb/22 ]

It sounds like you will need to write more tickets for the items you're interested in and narrow it down.

I can't really quantify what everything non-default in the process would mean.
I implemented the startup message for ServerParameter which should help.
For ServerOptions, we are actually already logging those with log message 21951.

If you want to set non-default RSConfig options that's probably a Repl team ticket.

Comment by Githook User [ 18/Feb/22 ]

Author:

{'name': 'Billy Donahue', 'email': 'billy.donahue@mongodb.com', 'username': 'BillyDonahue'}

Message: SERVER-57609 log the effects of --setParameter at startup
Branch: master
https://github.com/mongodb/mongo/commit/2716c8012c2c21c5e3c9f695d4d6a0751aff01ba

Comment by Billy Donahue [ 16/Feb/22 ]

For your example, electionTimeoutMillis is a property of a replica set, not a serverParameter. Printing all the non-default serverParameters at startup wouldn't help there. It's not available through getParameter either. Was it just a bad example? I'm not sure what I can do to help with that.

maxBSONDepth is more obviously applicable. That is a ServerParameter only settable at startup.
Its default is not declared in IDL but is rather defined in the BSONDepth class to be 200.
But showing the value only if it changes still doesn't show you want the default is. You'd have to change it and watch the log to see what the default was. So maybe you just want to emit a log of all the default values of all the ServerParameters at startup, just for reference?

If they change after startup, do we need to track that change and report it? Would it be sufficient to ServerParameter setters log something to show the changes as they happen?

I'm trying to figure out whether there is a need to expose these default values through getParameter at any time after startup has completed. It sounds like showing them at startup may be sufficient.

Comment by Dmitry Agranat [ 16/Feb/22 ]

Hi billy.donahue, consider the following:

{"t":{"$date":"2022-02-15T14:16:39.661+00:00"},"s":"I",  "c":"CONTROL",  "id":20722,   "ctx":"conn1088","msg":"Node is a member of a replica set","attr":{"config":{"_id":"myReplicaSet","version":1,"term":16,"members":[{"_id":0,"host":"ip-172-31-51-138.ec2.internal:27017","arbiterOnly":false,"buildIndexes":true,"hidden":false,"priority":1,"tags":{},"secondaryDelaySecs":0,"votes":1},{"_id":1,"host":"ip-172-31-52-192.ec2.internal:27017","arbiterOnly":false,"buildIndexes":true,"hidden":false,"priority":1,"tags":{},"secondaryDelaySecs":0,"votes":1},{"_id":2,"host":"ip-172-31-57-82.ec2.internal:27017","arbiterOnly":false,"buildIndexes":true,"hidden":false,"priority":1,"tags":{},"secondaryDelaySecs":0,"votes":1}],"protocolVersion":1,"writeConcernMajorityJournalDefault":true,"settings":{"chainingAllowed":true,"heartbeatIntervalMillis":2000,"heartbeatTimeoutSecs":10,"electionTimeoutMillis":10000,"catchUpTimeoutMillis":-1,"catchUpTakeoverDelayMillis":30000,"getLastErrorModes":{},"getLastErrorDefaults":{"w":1,"wtimeout":0},"replicaSetId":{"$oid":"6200ffea50a902918e1bc6f5"}}},"memberState":"SECONDARY"}}

How do I know that the electionTimeoutMillis (or other parameters) is set to its default?

{"t":{"$date":"2022-02-15T14:16:39.661+00:00"},"s":"I",  "c":"CONTROL",  "id":21951,   "ctx":"conn1088","msg":"Options set by command line","attr":{"options":{"config":"/data/automation-mongod.conf","net":{"bindIp":"0.0.0.0","port":27017},"processManagement":{"fork":true},"replication":{"replSetName":"myReplicaSet"},"setParameter":{"maxBSONDepth":"250"},"storage":{"dbPath":"/data","engine":"wiredTiger"},"systemLog":{"destination":"file","path":"/data/mongodb.log"}}}}

How do I know that the maxBSONDepth's value is not set to default and what the default is?
I need to manually run getParameter to figure this out. But when working with our customers, this is not an option especially when we need to get something from the past.

Ideally, what I want is an easy way to see something like:

Non-default values used for MongoDB <version>: Param (default: X, current: Y), ... list ...

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