[SERVER-73259] server parameter to control verbosity of individual log statements Created: 24/Jan/23 Updated: 16/Feb/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Billy Donahue | Assignee: | Blake Oler |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Service Arch
|
| Participants: |
| Description |
|
It could be very useful to change log verbosity on a precise granularity. The use of LogComponents currently allows siimlar control but over very large swaths of code. It predates structured logging, so there was no way to do this back when LogComponents were introduced. But now we can. This could be very useful for enabling critical statements in production during an investigation, in cases where verbosity on the relevant component would be a log flood. It could also be a useful emergency shut off valve for runaway log statements that are flooding customer logs, or that have a problematic severity. |
| Comments |
| Comment by Billy Donahue [ 04/Feb/23 ] | ||
|
matt.diener@mongodb.com we have a logv2::shouldLog(component, severity). We'd extend that function to take a log id. | ||
| Comment by Amirsaman Memaripour [ 26/Jan/23 ] | ||
|
It may also be helpful to disable a group of logs (e.g., networking or command) as an option to avoid recording INFO-level logs for the selected components. | ||
| Comment by Matt Diener (Inactive) [ 26/Jan/23 ] | ||
|
I like this idea a lot. I think we often have this pattern where we do:
I'm hoping we can expose via some API that 123456 is disabled so we can early return before calling `buildSomeExpensiveBsonObject`. The LOGV2 macro should definitely do this automatically, but I'd also love to be able to avoid extra work if we have that knowledge. |