Log level of some errors and failures is not sufficient as DEBUG

[ChipWolf]

What Renovate type are you using?

WhiteSource Renovate App

Describe the bug

Currently, many errors and failures do not log at a higher level than DEBUG which makes scrubbing through the logs for issues very tedious.

Did you see anything helpful in debug logs?

#173578276

DEBUG: Failed to look up dependency ...
...
DEBUG: Couldn't get index.yaml file
...
DEBUG: Dependency foo/bar has unsupported value 1.20
...
DEBUG: Unauthorized docker lookup ...
...
DEBUG: Helm Chart not found ...

To Reproduce

Currently known affected repo here.

[rarkins]

It's a classic signal vs noise problem. If we warned for everything that might be a problem then unfortunately it would result in thousands of warnings in the app's logs per hour, making it impossible to sift through. For example there are literally 10s of thousands of dependency not found results per hour already, perhaps even for npm alone.

If you think that Helm lookups should never fail, and nobody should be content with them failing to look up, then we could consider raising the level. But if they are failing lookups which people might have no intention of correcting then we shouldn't have permanently polluted log warnings.

In general, I take this approach:

• Error: something is wrong with Renovate itself and should be fixed
• Warn: something is wrong with an external system, or it's a user error I should know about
• Info: Try to keep this as simple as possible, so that it's actually possible to human-read if you like
• Debug: everything else

[ChipWolf]

Perhaps the unauthorized lookups and failures to fetch an expected file by a datasource should be raised by default. This may become a feature request for enhanced configuration of various failure conditions instead of a bug in that case.
I can imagine a situations where there's a typo in a registry, or dependencies which no longer exist/have been renamed.

[rarkins]

I have considered to eventually have an admin (i.e. bot owner) option to match log messages by patterns and downgrade their severity. In your case though you're still looking to see WARN level in what you see whereas I don't want it showing up in my stats/logs.. so it's a little challenging.

[ChipWolf]

Ah, so this is a service facing log level vs user facing log level issue. Perhaps the json blob for each log line should have different log levels for your monitoring tools and the end users.

[rarkins]

Yeah, so something like:

• Dump logs in original severity for user
• Apply severity downgrades
• Filter out debug
• Send to backend monitoring system