compute,storage: downgrade config update logs #33760
Conversation
This commit downgrades the "Applying configuration update" logs from `info` to `debug`. They have become extremely noisy over time as we have accumulated more config options, and especially with the introduction of the dyncfgs.
There was a problem hiding this comment.
I agree with the sentiment, but just last week this was crucial to me to debug an issue. I think we should do something else here: only print the configuration that has changed. (This was to understand 0dt behavior, so we couldn't even apply a new debug level without restarting envd.)
But how often have you had such a debugging task? And, was the problem related to the mechanism of propagating configuration to clusters or you just wanted to see what was the value of a particular config at a particular time? The latter need can be served by our configuration service (LD) which tracks the history of each variable. In general, I think we need a higher bar for having things be logged at info level, leaning towards things that are:
I don't think the LD configs meet that bar so I'm strongly in favor of merging this PR |
3 participants
This PR downgrades the "Applying configuration update" logs from
infotodebug. They have become extremely noisy over time as we have accumulated more config options, and especially with the introduction of the dyncfgs.Motivation
Fixes https://github.com/MaterializeInc/database-issues/issues/9660
Tips for reviewer
I would prefer to either (a) log only actual config changes or (b) send only actual config changes from envd to clusterd. But I didn't find a good way to implement (a) with our current
{Compute,Storage}Parametersdefinition and (b) requires a refactor of adapter code I'm not very familiar with.Checklist
$T ⇔ Proto$Tmapping (possibly in a backwards-incompatible way), then it is tagged with aT-protolabel.