It could be useful for logging messages that don't fit a particular category, i.e. a catch-all category, to identify patterns over time. Edit: You could also use it to turn-off logging for a while. Since unknown is the highest level, no other logs would be recorded.
I was trying to think of a good example, but the following table from RFC 5424 [1] might be a good starting point. I guess unknown could be used for the top 3 conditions.
Numerical Severity
Code
0 Emergency: system is unusable
1 Alert: action must be taken immediately
2 Critical: critical conditions
3 Error: error conditions
4 Warning: warning conditions
5 Notice: normal but significant condition
6 Informational: informational messages
7 Debug: debug-level messages
The code has noticed a condition that may or may not be meaningful—it is not explicitly handled or classified. The correct place the message noting this ought to go could well be unknown. INFO buries it, which may be very bad. Higher severities might be crying wolf. UNKNOWN starts showing up in the logs, that tells you to go take a closer look, and tells you that nobody has encoded the severity of the message into the system.
17 comments
[ 0.19 ms ] story [ 54.3 ms ] threadAt least some log scraping + monitors with graylog, ELK or the like would be the minimum imo…
It was meant to be a beginner-level introduction to logging (especially for those developers who got started in 2023 ;))
And I would not call scraping and monitoring advanced topics.
Advanced topics are multi stage image builds, helm charts + deployments and clean architecture. Just to name a few.
But what if you're just trying to stand up a rails app on a boring linux droplet?
Glad to see one of his posts here on HN.
And frankly stunning to see a Ruby post on the front page!
https://news.ycombinator.com/item?id=36875815