[SERVER-46650] Allow use of string variables in log messages Created: 05/Mar/20  Updated: 27/Oct/23  Resolved: 06/Mar/20

Status: Closed
Project: Core Server
Component/s: Tools
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Xuerui Fa Assignee: Andy Schwerin
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:

 Description   

Currently, it seems we aren't able to use string variables directly in a call to LOGV2. We end up with work-arounds like here, where we build the message using str::stream and then pass that in as an attribute.

Ideally, there would be a way for us to pass in string variables directly.



 Comments   
Comment by Andy Schwerin [ 30/Mar/20 ]

Non-literal message strings are explicitly not supported.

Comment by William Schultz (Inactive) [ 30/Mar/20 ]

I feel that this issue also impacts the ease of writing log statements for printf style debugging. For example, right now, I have to write a diagnostic log message like:

LOGV2(234678, "Initializing with new config",
      "config"_attr = newConfig.toBSON(),
      "term"_attr = newConfig.getConfigTerm());

but ideally I would like to just write:

LOGV2(234678, str::stream() << "Initializing with new config: " << newConfig.toBSON() << "," << newConfig.getConfigTerm());

The latter, though, does not appear to be supported.

Comment by Andy Schwerin [ 06/Mar/20 ]

For the example in the ticket description, I think the improvement in SERVER-46520 is more appropriate. You can use this feature to log a structured message and raise an exception at the same time.

The logging system intentionally prohibits the use of variables in messages. I suppose we could investigate allowing constexpr values and not just string literals, but we want the message to be determined at compile time, and extractable to an external catalog. Variable data is intended to appear in the attribute fields.

Comment by Judah Schvimer [ 06/Mar/20 ]

Another example is here, where 'newlyAdded' could use a string constant (and ideally would), but we inline the string instead.

Comment by Bruce Lucas (Inactive) [ 06/Mar/20 ]

This seems contrary to the goals of structured logging. Shouldn't the strings in the example you cited be provided as attributes, i.e. the output should be something like

msg: "Mismatch between old and new replica set configuration names"
attr: {
    newName: "..."
    oldName: "..."
}

(Not sure of the details of the attribute names because I'm not quite sure exactly what is mismatched in this case, but hopefully this conveys the idea.)

Comment by Judah Schvimer [ 05/Mar/20 ]

This would especially be useful for string constants that we don't want to have to duplicate.

Generated at Thu Feb 08 05:12:03 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.