[SERVER-29290] Report all current configuration options for mongod, including those set dynamically Created: 18/May/17 Updated: 20/Nov/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Diagnostics, Logging |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Mark Brinsmead | Assignee: | Backlog - Security Team |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | SWDI | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Assigned Teams: |
Server Security
|
||||||||||||||||
| Sprint: | Security 2018-12-03 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
Would like a command that reports the current settings for all configuration options – including dynamic settings, hidden parameters, and internal storage-engine options – in the mongod. This could be part of serverStatus() or a new command. The aim is to provide a simple and reliable way to see the current settings for all parameters, including those settable with commands like:
|
| Comments |
| Comment by Matt Lord (Inactive) [ 16/Mar/18 ] |
|
I would like to see this information stored in FTDC to begin with. Then diagnostic data and changes in system behavior can be easily correlated with configuration changes. For example, the diagnostic data you're examining to understand MongoDB behavior (e.g. a big drop in QPS or a big spike in the RSS for mongod) may make much more sense when you see that someone modified some critical server parameter(s). |
| Comment by Mark Brinsmead [ 19/May/17 ] |
|
Yes. The goal here is to have a complete description of all configuration settings in force at this moment in time. Capturing it all in FTDC is great. Ultimately, we'd be happy to have it recorded in the logfile periodically. (But FTDC is better – fewer customers balk at providing that.) Logfiles, however, are more useful to the customer, who may want this data for their own purposes, as most end-users will find FTDC data hard to use. Recording said data is SERVER-29291. |
| Comment by Kevin Pulo [ 19/May/17 ] |
|
So I guess that the emphasis on "current" means that db.serverCmdLineOpt() (aka db.adminCommand("getCmdLineOpts")) is insufficient. But db.adminCommand({ getParameter: "*" }) can be used to list all parameters and their current values. Are these two combined sufficient? If not, can you explain in more detail what else is desired? The thing with getParameter of wiredTigerEngineRuntimeConfig always reporting an empty string is a known issue tracked in FTDC already grabs getCmdLineOpts (and buildInfo and hostInfo) at least once per metrics file (maybe more). Would it be useful if it also grabbed getParameter: "*" |