[SERVER-44841] Revisit log levels for new migration protocol Created: 26/Nov/19 Updated: 29/Oct/23 Resolved: 02/Mar/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 4.3.4 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Matthew Saltz (Inactive) | Assignee: | Alexander Taskov (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 | ||||||||
| Sprint: | Sharding 2020-03-09 | ||||||||
| Participants: | |||||||||
| Description |
|
It's helpful to have log level 0 for the new components we're adding for a little while to aid in debugging test failures in evergreen but we should more carefully decide which to keep at level 0 and which to decrease. Also, we should decide whether to use the thread name as an identifier for log lines from range deletion code, or whether to introduce a new log component. |
| Comments |
| Comment by Githook User [ 28/Apr/20 ] |
|
Author: {'name': 'Billy Donahue', 'email': 'billy.donahue@mongodb.com', 'username': 'BillyDonahue'}Message: (cherry picked from commit 2638bf93b6af37b1c71dcbd60947f4a1973222a7) |
| Comment by Billy Donahue [ 01/Apr/20 ] |
|
Created I was being lazy and hoping to avoid a separate ticket, but I'll need to track backporting and don't want to keep spamming this larger and closed ticket. |
| Comment by Billy Donahue [ 01/Apr/20 ] |
|
There's still an 8-character limitation, it's just not tested anymore. This is not a technical limitation, but we have opted to pad the first few json fields and having one that's 9 chars harshes the feng shui of the logs. We still have code that uses the v1 API and some converter helpers. Until that's no longer the case we have to keep the v1 and v2 enums in sync. |
| Comment by Githook User [ 01/Apr/20 ] |
|
Author: {'name': 'Billy Donahue', 'email': 'billy.donahue@mongodb.com', 'username': 'BillyDonahue'}Message: |
| Comment by Alexander Taskov (Inactive) [ 01/Apr/20 ] |
|
It's unfortunate that the new component name has to be bound by the limitations of the legacy one. Out of curiosity, why do they have to match? I thought the plan was to remove the legacy component when everything has been migrated to the v2 component. The preferred name is MIGRATION however for the legacy component we had to compromise to MIGRATE because of the 8 character limitation. |
| Comment by Billy Donahue [ 01/Apr/20 ] |
|
LogComponent "MIGRATION" => "MIGRATE" change |
| Comment by Billy Donahue [ 01/Apr/20 ] |
|
A new LogComponent was created by the commit for this ticket, in both the logger (log v1) and logv2 libraries. The logger and the logv2 have to agree on the name of the component. So I'm going to change the logv2 component to appear as "MIGRATE" to match the logger component. |
| Comment by Githook User [ 29/Feb/20 ] |
|
Author: {'name': 'Alex Taskov', 'username': 'alextaskov', 'email': 'alex.taskov@mongodb.com'}Message: |
| Comment by Esha Maharishi (Inactive) [ 24/Feb/20 ] |
|
There are a few things I think we could do to improve logging for the range deleter:
|