linux日志级别共8级（0–7），数值越小优先级越高：0为emerg（系统崩溃），1为alert（需立即处理），2为crit（关键失效），3为err（操作失败），4为warning（潜在问题），5为notice（需关注事件），6为info（常规运行），7为debug（开发调试）。
Linux 日志级别（Severity）不是简单的“数字越大越严重”，而是有明确语义边界和使用场景的分级体系。理解每级的本意，才能避免日志泛滥或关键信息遗漏。
日志级别的标准语义定义
主流实现（rsyslog、systemd-journald、应用框架如 Dify）普遍采用 RFC 5424 和 POSIX 兼容的 8 级模型，从低到高依次为：
- debug：开发阶段用，记录变量值、函数调用栈、内部状态切换等，生产环境通常关闭
- info：确认系统按预期运行，如服务启动完成、配置加载成功、常规请求处理完成
- notice：正常但需关注的事件，例如定期任务执行、配置热重载、资源使用率接近阈值
- warning：潜在问题已发生，当前不影响功能，但可能演变为错误，如证书即将过期、磁盘剩余空间低于20%
- err（或 error）：功能异常，某次操作失败（如数据库查询超时、API 调用返回 5xx），但服务整体仍可用
- crit（critical）：关键组件失效，系统部分能力丧失，如主数据库连接断开、核心队列积压超限
- alert：必须立即人工干预，如认证服务不可用、TLS 密钥泄露风险、内存泄漏持续增长
- emerg（emergency）：系统已无法继续运行，如内核 panic、所有副本节点宕机、磁盘写满导致 journal 停止写入
级别设置的实际影响
日志级别决定“什么能被记录”，而非“什么该被打印”。它作用于两个层面：
PyCharm 2026.2.0.1 Linux版
下载
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
- 应用层：代码中调用
log.debug()或log.error()时，若当前全局级别设为warn，则debug和info消息直接丢弃，不进入输出流 - syslog 层：rsyslog 配置中
auth.* /var/log/auth.log表示 auth 设施所有级别都记录；而auth.warning /var/log/auth_warn.log则只捕获 warning 及更高级别 - 注意：级别是“包含关系”——设定为
err，实际记录的是err、crit、alert、emerg四级，不是仅记录 err
常见服务的日志级别实践
不同组件对同一级别的敏感度不同，需结合上下文判断：
-
BIND DNS 中
info级别会记录每次区域传输，高频但必要；debug则开启查询路径追踪，仅调试时启用 -
内核 printk 使用
KERN_INFO~KERN_EMERG编号（1~8），通过/proc/sys/kernel/printk控制控制台输出阈值，不影响 journald 记录 -
systemd-journald 默认采集所有级别，但
journalctl -p warning可过滤查看 warning 及以上 -
Dify 类结构化服务 强制要求 JSON 中
"level"字段为小写字符串（"warn"而非"WARNING"），便于下游统一解析
配置与验证要点
修改级别后务必验证是否生效，避免“以为开了 debug 实际没输出”：
- rsyslog 修改
/etc/rsyslog.conf后，执行sudo systemctl restart rsyslog并检查sudo journalctl -u rsyslog | tail -10 - 应用级（如 Spring Boot）通过
logging.level.root=warn设置，重启后用curl http://localhost:8080/actuator/loggers查看实时级别 - 快速测试：手动触发一条已知级别的日志，例如
logger -p local0.info "test info message"，再查/var/log/messages是否出现 - 注意权限：写入
/var/log/下文件需目标目录可写，否则日志会静默丢失
