[SERVER-39449] Provide an argument to suppress everything by default in serverStatus Created: 08/Feb/19 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Diagnostics |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | David Bartley | Assignee: | Backlog - Query Execution |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Query Execution
|
| Participants: |
| Description |
|
Often times when using serverStatus programmatically, you only want to return a specific section. One reason to do so is to avoid the relatively high amount of load (and locks) placed on the server each time serverStatus is run, or to avoid hanging the command if some particular section takes out a lock that is currently held. It's possible to suppress individual sections in serverStatus by passing <section>: 0, but there's no way to suppress every section by default. It'd be nice to be able to run something like {serverStatus: 1, all: 0, sharding: 1}. |
| Comments |
| Comment by Asya Kamsky [ 16/Feb/19 ] |
|
Some internal discussion has surfaced the fact that we are trying to get away from commands that return a single document and also trying to move towards unified language for all such commands. It's a little unclear which team should take the lead on this, so part of the challenge is to determine if command option input should be part of that language, and if so whether query or platforms team would own it. I'm going to move this back to the query team to consider the language question - once that's agreed upon it might make it obvious which team should own the implementation. |
| Comment by Craig Homa [ 14/Feb/19 ] |
|
Assigning to Platforms to triage since they have expertise on FTDC/serverStatus. |
| Comment by David Bartley [ 08/Feb/19 ] |
|
Works for me; I'd be happy with e.g. {serverStatus: 1, sections: {sharding: 1}} or similar. |
| Comment by Ramon Fernandez Marina [ 08/Feb/19 ] |
|
Thanks for your report bartle. I think it would make sense if the semantics matched those used to project fields in a query, but please feel free to comment here if you think the semantics should be different. |
| Comment by David Bartley [ 08/Feb/19 ] |
|
The specific thing I'm trying to do is determine the config server replset. I'm currently relying on the undocumented getShardMap command, but I'd much rather use the documented sharding section of the serverStatus command. |