[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.

https://github.com/mongodb/mongo/blob/a0058f18bba24e96e81dd0cae0cd13cfc65b145c/src/mongo/logv2/log.h#L278

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:

auto attr = buildSomeExpensiveBsonObject();
LOGV2_DEBUG(123456, <some stuff> attr);

 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.

Generated at Thu Feb 08 06:24:09 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.