分级与检索是一对
日志分级解决的是噪声问题：把不同严重程度的信息混在一起，关键错误会被淹没，也没法按级别配置保留期与告警。分级原则应按「需要多快采取行动」判断——需要人立即处理的是错误与致命，可容忍的降级与重试是警告，过程记录是信息，变量与细节是调试。检索则解决可达性问题：只有结构化字段加上统一的请求或任务标识，才能一次拉出某次执行的全部相关日志。
基本信息
| 级别序列 | 调试、信息、警告、错误、致命 |
|---|---|
| 分级原则 | 按需要采取行动的程度，而非开发者主观感受 |
| 检索键 | 时间范围、主体、任务标识、对象、结果状态 |
| 保留策略 | 级别与保留期挂钩，错误与警告长期留存 |
| 结构要求 | 时间带时区、字段命名统一、来源可辨别 |
典型使用场景
- 定位某次执行：按任务标识一次拉出该任务全部日志，不看无关输出
- 按失败对象排查：以资源或主机为键检索，快速判断是个别还是批量问题
- 时间窗回溯：结合变更时间定位改动前后的日志差异
- 失败率统计：按错误级别聚合，形成周期趋势与排名
- 跨服务追踪：同一请求标识贯穿多个组件，还原完整调用链
级别内容与保留告警
| 级别 | 典型内容 | 保留与告警 |
|---|---|---|
| 调试 | 变量取值、模板渲染、请求细节 | 短期留存，默认不告警 |
| 信息 | 关键步骤、状态变更、开始与结束 | 中期留存，可按需统计 |
| 警告 | 降级运行、重试、部分失败 | 较长期留存，聚合后告警 |
| 错误 | 动作失败、依赖不可用、权限拒绝 | 长期留存，需告警与跟踪闭环 |
| 致命 | 任务无法继续、关键依赖整体不可用 | 立即告警并记录终止原因 |
结构化检索优先于全文匹配
结构化检索优先于全文匹配
# 结构化字段检索：先按任务标识与级别收窄，再看明细
journalctl -u deploy-agent --since '2026-10-17 09:00' --until '2026-10-17 10:00' | grep 'exec_id=EX-88213'
# 按级别聚合看趋势：统计错误量，而不是逐条阅读
jq -r 'select(.level=="error") | .task' app.log | sort | uniq -c | sort -rn | head
# 全文匹配只作兜底，且要限定时间与来源，避免在大文件中盲搜
rg 'EX-88213' /var/log/app/ -g '*.log' --max-count 50 # 命中即停，控制输出量
# 关键前提：时间戳带时区、字段名统一，否则跨系统检索无法对齐检索要能以任务或请求标识一次拉全。缺少统一标识时，跨系统排查只能按时间窗口猜，既慢又容易漏掉真正相关的那条记录。
把全局级别长期设为调试会同时推高存储成本与漏报概率：关键错误淹没在海量细节里，告警阈值也被噪声拉偏。调试级别应临时启用并限定范围。