2022-02-17
The Linux kernel's message log levels are relatively meaningless
The Linux kernel has an internal system to assign (or let people assign) a log level for all kernel messages, ranging from 'debug' at the bottom up through 'emerg' at the top. You can read about it in syslog(2), and these kernel log levels become syslog(3) log levels, can be reported (and thus manually filtered) by dmesg(1) and so on. Given this, you might wonder if it's useful to do anything different for different log levels, like route some log levels to a special syslog file. Cynical system administrators already know the answer from their experiences with syslog priorities, and it is "not really".
The major reason for this is that it's up to individual kernel developers to decide on what log level they'll give to particular messages, which means that there's no strong consistency to those levels. While there are broad standards, there's no single person or group that carefully makes sure everything is coherent. To the extent that there is developer scrutiny of kernel message priorities, I suspect that it's mostly concentrated at the high priority level, if you're trying to add an 'emerg' or 'alert' or maybe even 'crit' level message. This is especially true for device drivers, which are the most anarchic area of the Linux kernel (and have the most variable quality).
A secondary reason for this is that to some extent, the priority of a message is in the eye of the beholder and depends on the situation. The log levels for messages are chosen by developers and are likely slanted to the developer's view of what the messages mean and are good for, but at one level they're mostly used by system administrators who are trying to figure out what's going on with their Linux systems. On top of that, how important a message is to you depends on how important that area of the kernel is to what you're doing with the system. On some systems, USB oddities are critical; on others, USB oddities are low priority because the system's only use of USB is to sometimes plug in a keyboard in the machine room.
A third practical issue is that there isn't very much use of the very high priorities in the current kernel. The less use there is of high priorities, the more things get pushed into a big lump in the middle where exactly what is an error, a warning, or a notice isn't necessarily something everyone agrees on or is consistent about.
The result is that in practice, unless you've checked the kernel code for the area you care about you can't really use kernel log levels for anything much. Much like syslog, you generally need to push it all into one spot rather than trying to draw distinctions based on log level.