[SERVER-38998] Create serverStatus metrics for readConcern and writeConcern Created: 14/Jan/19 Updated: 29/Oct/23 Resolved: 22/Jan/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 3.6.11, 4.0.6, 4.1.8 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Tess Avitabile (Inactive) | Assignee: | Tess Avitabile (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Backport Requested: |
v4.0, v3.6
|
||||||||||||
| Sprint: | Repl 2019-01-28 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
We will create new serverStatus sections:
The sum of these counters should be opCounters.query (note that this means we will not include getMore commands, since these inherit the readConcern from the originating command).
The sum of the counters for opWriteConcernCounters.insert should be opcounters.insert, and similarly for the other operations. Note that the j value is ignored, so {w: 1, j: true} and {w:1, j:false} are both counted in w1. |
| Comments |
| Comment by Alyson Cabral (Inactive) [ 16/May/19 ] |
|
tess.avitabile I vaguely remember that we flag guarded the write concern metrics, and that Atlas turns this on. Can you remind me how to turn this on or off? jeff.yemin and I were just having a conversation about this. |
| Comment by Githook User [ 01/Feb/19 ] |
|
Author: {'name': 'Tess Avitabile', 'email': 'tess.avitabile@mongodb.com', 'username': 'tessavitabile'}Message: (cherry picked from commit 9de1d61550232f370afa1b4f98bfe6aa7e2cf60f) |
| Comment by Githook User [ 01/Feb/19 ] |
|
Author: {'name': 'Tess Avitabile', 'email': 'tess.avitabile@mongodb.com', 'username': 'tessavitabile'}Message: (cherry picked from commit 5e4dd450fa2e3d2900cc4ac204385ab613c36cc5) |
| Comment by Githook User [ 22/Jan/19 ] |
|
Author: {'username': 'tessavitabile', 'email': 'tess.avitabile@mongodb.com', 'name': 'Tess Avitabile'}Message: (cherry picked from commit 9de1d61550232f370afa1b4f98bfe6aa7e2cf60f) |
| Comment by Githook User [ 22/Jan/19 ] |
|
Author: {'username': 'tessavitabile', 'email': 'tess.avitabile@mongodb.com', 'name': 'Tess Avitabile'}Message: (cherry picked from commit 5e4dd450fa2e3d2900cc4ac204385ab613c36cc5) |
| Comment by Githook User [ 22/Jan/19 ] |
|
Author: {'username': 'tessavitabile', 'email': 'tess.avitabile@mongodb.com', 'name': 'Tess Avitabile'}Message: |
| Comment by Tess Avitabile (Inactive) [ 18/Jan/19 ] |
|
I'm removing the 'command' section from 'opWriteConcernCounters'. I don't think it's very meaningful, since many commands do not take writeConcern, and it is annoying for testing, since running 'serverStatus' itself would record writeConcern stats. |
| Comment by Githook User [ 18/Jan/19 ] |
|
Author: {'username': 'tessavitabile', 'email': 'tess.avitabile@mongodb.com', 'name': 'Tess Avitabile'}Message: |
| Comment by Tess Avitabile (Inactive) [ 15/Jan/19 ] |
|
Thanks, bruce.lucas. I updated the schema per Andy's suggestion. |
| Comment by Bruce Lucas (Inactive) [ 15/Jan/19 ] |
|
Yes, but as Andy hints at, we should avoid designs that generate a high rate of schema changes because it reduces compression efficiency. As long as such tags occasionally show up and don't disappear we should be ok. |
| Comment by Tess Avitabile (Inactive) [ 15/Jan/19 ] |
|
Can FTDC handle dynamically generated fieldnames? |
| Comment by Andy Schwerin [ 15/Jan/19 ] |
|
What if we changed "wtag" to be an object, with one member for each observed tag? Most systems only have a small fixed number of tags, so we won't see tons of ftdc schema changes. If we did this, we could in principle replace w1 and w2 with "wnum" which is also an object, whose fields are keyed off the base-ten string of the w-number. { "wnum": { "1": <num>, "3": <num>}. |
| Comment by William Schultz (Inactive) [ 14/Jan/19 ] |
|
Got it, sounds good to me. |
| Comment by Tess Avitabile (Inactive) [ 14/Jan/19 ] |
|
I added tag, per Aly's request. I wasn't planning to generalize the numeric write concern fields, since I think w:1 and w:2 are most important. Now that we are tracking tag separately, everything in "other" should be w:n for n>2. |
| Comment by William Schultz (Inactive) [ 14/Jan/19 ] |
|
Looks good to me. We could consider including a "tag" write concern counter (presumably that would fall under "other"), but I don't think it's critical to include at first. Also, I assume that we would generalize the numeric write concern fields through to w<N> dynamically? Gathering j:true/false data may be useful down the line but doesn't feel as crucial for supporting our paper's thesis. |
| Comment by Tess Avitabile (Inactive) [ 14/Jan/19 ] |
|
Yes, done. Thanks for looking! |
| Comment by Alyson Cabral (Inactive) [ 14/Jan/19 ] |
|
Would it be possible we add tag to write concern? Otherwise, this looks great. |