2. 日志基础：日志格式、级别、常见日志系统归纳总结
日志这个东西，说白了就是程序运行时的“黑匣子”。我刚开始做运维的时候，觉得日志就是用来查 bug 的，直到有一次线上告警风暴，几千条错误日志刷屏，我才意识到——日志格式、级别、采集方式，任何一个环节没设计好，后面全得翻车。
这一节我们就把日志的底层逻辑拆开看看。你搞清楚这三个东西，后续的告警阈值设计和巡检优化才有了“原材料”。
2.1 日志格式——别让解析器猜谜
日志的格式决定了你能从日志里提取什么信息。我习惯把格式分为两类：结构化日志和非结构化日志。
| 对比维度 | 结构化日志 | 非结构化日志 |
|---|---|---|
| 典型格式 | JSON / MessagePack / Protocol Buffers | 纯文本 / CSV / 固定分隔 |
| 解析难度 | 低（字段直接索引） | 高（需要正则/模板切割） |
| 存储开销 | 略大（含字段名冗余） | 较小（仅文本） |
| 排查效率 | 高（可精确过滤字段） | 低（全文检索为主） |
| 适配告警阈值 | 直接提取数值字段 | 需额外解析提取 |
我的建议：新项目一律用 JSON 格式日志。我在一次微服务改造中吃过亏——业务方要求保留旧格式，结果日志采集后解析 CPU 飙升 30%。JSON 虽然占点磁盘，但解析成本低太多了。
一个标准的结构化日志示例（JSON）长这样：
{
"timestamp": "2025-02-08T14:23:11.897Z",
"level": "WARN",
"logger": "com.example.payment.PaymentService",
"message": "支付接口响应超时",
"fields": {
"order_id": "ORD20250208142311",
"cost_ms": 3200,
"retry_count": 2
}
}你想想看，如果cost_ms字段能直接拿来算大盘接口耗时 P99，告警阈值直接对字段做规则，多清晰？非结构化文本你得先写正则抠数字，性能又差维护又烦。
2.2 日志级别——学会分级，别什么都打 ERROR
级别是日志的“优先级标签”。我见过最多的坑是：开发同学把所有异常都打 ERROR，结果 ERROR 日志一天几万条，真正需要人工介入的问题反而被淹没了。
常见的级别体系（Java / Log4j2 / SLF4J）如下：
| 级别 | 数值 | 含义 | 告警阈值适用场景 |
|---|---|---|---|
| TRACE | 600 | 最细粒度的追踪信息 | 一般不参与告警，用于调试 |
| DEBUG | 500 | 开发调试信息 | 生产环境应关闭 |
| INFO | 400 | 关键业务节点记录（如订单创建成功） | 可监控业务流量异常（如 INFO 突然降为零） |
| WARN | 300 | 潜在风险但仍可继续运行（如重试、降级触发） | 控制 WARN 的突发频率，防止告警轰炸 |
| ERROR | 200 | 功能不可用或异常，需人工关注 | 最常用的告警级别，设置阈值 + 持续时间 |
| FATAL | 100 | 严重故障，进程可能退出 | 建议直接电话告警，阈值设为>0 |
避坑指南：我曾经遇到一个项目，开发在 catch 块里直接
log.error("发生异常", e);捕获业务校验异常（如参数不合法），导致 ERROR 日志量是真正系统异常的 10 倍。正确的做法是：业务逻辑异常用 WARN 记录，系统级异常再用 ERROR。这样告警阈值才能区分“需要修复”和“只是需要关注”。
2.3 常见日志系统——选型也是告警设计的一部分
日志系统处理“日志产生→采集→传输→存储→查询→告警”全链路。我梳理了几个主流方案的特征：
| 系统/栈 | 典型组件 | 核心优势 | 阈值优化关注点 |
|---|---|---|---|
| ELK Stack | Filebeat + Logstash + Elasticsearch + Kibana | 全文检索强大，Kibana 可视化成熟 | ES 写入压力大时，日志级过滤前置到 Filebeat/Logstash |
| Loki + Promtail + Grafana | Promtail / Grafana Alloy / Loki / Grafana | 低成本，与 Prometheus 生态统一 | 标签（labels）设计直接影响阈值告警效率 |
| EFK（云原生变体） | Fluentd / Fluent Bit + Elasticsearch / OpenSearch | Fluentd 插件丰富，适合容器化场景 | Fluentd 的 buffer/retry 配置影响日志丢失率 |
| 阿里云 SLS / 腾讯云 CLS | 托管版采集 + 存储 + 告警 | 免运维，自带告警规则引擎 | 注意配额和成本，阈值建议设置“触发后冷却时间” |
| SigNoz / Grafana Cloud | 开源 APM + 日志一体化 | 支持 tracing + logs 关联 | 利用 trace_id 将慢调用与错误日志关联，精准降噪 |
你可能会问：这些系统对告警阈值设计有啥直接影响？我举个例子——用 ELK 的 Watcher，你可以写一个查询“按 logger 分组统计 5 分钟内的 ERROR 数量”，如果某组超过 10 次就触发告警。但如果你日志级别没定义好，或者格式里没有 logger 字段，这个规则根本写不出来。
核心结论：日志格式 → 决定了你能“过滤/聚合”什么字段；日志级别 → 决定了你的告警信号是“真问题”还是“假警报”；日志系统 → 决定了你实现阈值规则的成本和灵活性。这三层依次决定告警设计的“原料质量”。
最后看一下我们这一节的知识地图：
嗯，到这里你应该明白了——日志基础不是孤立的知识，它直接决定了你后面设计告警阈值时“有什么可用的”、“能不能自动化”。下一层我们再具体讲如何基于这些基础做巡检优化，但今天先把这三个要素刻进脑子里。