4 ms·
Don't use warn, either info or error nothing in between.
by Thaxll 4y ago
Don't use warn, either info or error nothing in between.
- m463 4y agoI disliked the logging levels I really wanted to have an app with a reasonable default level, then allow flags like --debug, --verbose plus --quiet and it never seemed to map like I wanted. maybe it's obvious and I just don't see it.
- LtWorf 4y agoJust try reading logs from journalctl, where you can filter the levels you don't need and see errors and warnings in a different colour. Then you will perhaps re-evaluate the importance of levels.
- 1337shadow 4y agoBy default, use INFO to tell what has been done, use DEBUG to describe what's going to be done and how it's deciding it.
- gregmac 4y agoWarning is actually very useful. One of the biggest logging mistakes I see is people misusing Error. What most developers consider an error -- external service call failed, user gave bad input, or a timeout happened - is often not really a problem. The service call is re-tried. Users are going to user (and provide garbage data and then fix it). None of these require operator intervention. To me, Errors imply action needed, or highlight an unresolved situation. If the service call keeps failing after all retries, and now a feature is impacted (eg a user won't get a report, or there's a gap in data somewhere) then that can be an Error. All the temporary faults are useful as Warn to highlight them and distinguish from other normal operations, but no action is needed. This is most useful when a user reports something like "it seems to be taking much longer than usual to get email notifications" and when an operator looks at the logs, they're full of warnings. It's also useful for monitoring: high number of warnings in the log can cause a non-critical notification to operators (during business hours; not a wake-me-up-at-2am page).