日志

原理层

日志的本质

日志是事件（Event）的时间化持久表达。

日志 = 系统在时间维度上，对状态变化、决策行为与异常事实的不可变记录。

其核心在于：

• 事实留存（What happened）
• 上下文还原（Who / When / Where / Why）
• 因果追溯（Before / After / Impact）

日志在可观测性中的位置

可观测性的三大支柱：

• **Logs（事件）**：离散、不可逆、语义最强
• **Metrics（度量）**：聚合、趋势、宏观健康度
• **Traces（链路）**：因果路径、调用拓扑

日志解决的是“发生了什么”。

稳定认知

• 日志是**事件事实源**，不是临时调试输出
• 日志一经写入，应被视为**不可修改的历史**
• 日志的价值随时间衰减，但不会归零

架构层

日志系统的参考抽象模型

事件源（应用）   ↓事件记录（Logger）   ↓采集与缓冲（Agent / MQ）   ↓加工与结构化（Processor）   ↓存储（冷热分层）   ↓查询与分析（Search / Analytics）

该模型在单体与分布式系统中保持稳定，仅实现方式不同。

单体日志架构

特征：

• 同进程写入
• 文件或本地存储
• 人工或简单工具分析

适用阶段：

• 早期系统
• 低并发内部系统

分布式日志架构

核心思想：日志写入与业务执行解耦

关键能力：

• 异步采集
• 流量削峰（缓冲层）
• 结构化处理
• 冷热数据分层

设计层

日志级别的治理语义

日志级别 = 组织对事件严重性的态度声明。

系统日志 vs 操作日志

操作日志必须满足：

• 可读性
• 业务语义完整
• 可追责性

日志上下文设计

稳定上下文字段：

• 时间（发生 / 记录）
• 身份（用户 / 系统）
• 关联（TraceId / BizId）
• 来源（服务 / 模块）

没有上下文的日志，几乎不可用。

工程方法层

日志与业务解耦

• 使用 AOP / 注解
• 使用模板与表达式
• 日志逻辑不侵入业务逻辑

目标：

日志是对业务事实的“旁观式记录”，而非业务流程的一部分。

性能与成本意识

核心原则：

• 日志不是免费的
• IO、序列化、存储都需要成本

工程策略：

• 占位符而非字符串拼接
• 避免大对象与大文本
• 高频场景使用采样

错误日志的严格使用

ERROR 日志必须满足：

• 影响业务或系统正确性
• 需要人工处理
• 能触发告警或工单

否则应使用 WARN 或 INFO。

选型原则层

日志系统选型维度

组织与文化层

日志的三类受众

• 开发：诊断与改进
• 运维：稳定性与响应
• 业务/审计：事实与责任

日志即制度

• 日志定义了什么是“异常”
• 日志决定了谁需要被通知
• 日志影响团队对系统的认知方式

关联内容（自动生成）

• [/软件工程/架构/系统设计/可观测性.html](/软件工程/架构/系统设计/可观测性.html) 日志作为可观测性三支柱之一，与指标(metrics)和链路追踪(tracing)共同构成完整的系统可观测性体系，理解日志在整体可观测性架构中的位置和作用
• [/软件工程/架构/系统设计/监控系统设计.html](/软件工程/架构/系统设计/监控系统设计.html) 监控系统设计涵盖了从数据收集到告警治理的完整体系，日志是监控系统的重要数据源，了解监控系统的架构和设计原则对构建有效的日志体系至关重要
• [/运维/SRE.html](/运维/SRE.html) SRE体系强调通过工程化手段管理系统的稳定性，日志在故障发现、认知和恢复过程中起关键作用，是SLI/SLO实现和错误预算管理的重要数据基础
• [/软件工程/架构/系统设计/前端监控.html](/软件工程/架构/系统设计/前端监控.html) 前端监控涵盖了客户端的性能指标、异常收集等，与后端日志体系共同构成端到端的可观测性，有助于全链路问题排查