日志工程基础：日志的分类与采集架构
在构建可观测性体系时，日志是最原始、最丰富的数据源。SRE 团队需要理解日志的分类方式与采集架构，才能设计出高可靠、低延迟的日志管道。本节从分类与采集两个维度展开，为后续 Golden Signals 指标提取奠定基础。
2.1 日志的分类
根据用途与合规要求，日志通常分为三类：业务日志、系统日志与审计日志。三类日志在内容、生命周期与访问控制上存在显著差异。
| 分类 | 定义 | 典型内容 | 存储周期 | 访问控制 |
|---|---|---|---|---|
| 业务日志 | 记录用户操作、交易流程、服务调用等业务行为 | 订单创建、支付回调、API 响应码、用户登录 | 7–30 天（热） / 90–180 天（温） | 按角色与业务域隔离 |
| 系统日志 | 记录操作系统、中间件、基础设施的运行状态 | CPU 使用率、磁盘 I/O、OOM 事件、服务重启 | 30–90 天（热） / 1 年（冷） | 运维与 SRE 团队可读 |
| 审计日志 | 记录权限变更、数据访问、配置修改等合规事件 | sudo 执行、IAM 策略变更、数据库 DDL | 1–7 年（不可篡改） | 仅审计与安全团队可写 |
2.2 日志的采集架构
日志采集架构经历了从“推模型”到“拉模型”、从“单点采集”到“边车代理”的演进。当前主流方案包括 Agent、Fluentd 与 Logstash 三种模式。
2.2.1 Agent 模式（轻量级采集器）
Agent 模式在每个节点上部署独立的采集进程，直接读取本地日志文件或标准输出，通过协议（HTTP / gRPC / Kafka）将日志发送到后端。典型实现包括 Filebeat、Vector、Fluent Bit。
- 优点： 资源占用低（通常 < 50MB 内存）、配置简单、支持自动发现日志文件。
- 缺点： 缺乏复杂过滤与转换能力，多行日志（如 Java 异常栈）需额外配置。
- 适用场景： 容器化环境（Kubernetes DaemonSet）、边缘节点、资源受限设备。
2.2.2 Fluentd 模式（统一日志层）
Fluentd 采用插件化架构，通过 Input → Buffer → Output 管道处理日志。它支持丰富的输入源（tail、syslog、HTTP）与输出目标（Elasticsearch、S3、Kafka）。
- 优点： 内置缓冲与重试机制、插件生态丰富（超过 1000 个）、支持标签路由。
- 缺点： 内存占用较高（Ruby 运行时）、高吞吐场景需调优 Buffer 参数。
- 适用场景： 混合架构（物理机 + 虚拟机 + 容器）、需要复杂数据路由的中型集群。
2.2.3 Logstash 模式（全功能管道）
Logstash 是 ELK 栈的核心组件，提供强大的 Grok 解析、过滤与转换能力。它支持从多种输入（Beats、TCP、Kafka）接收数据，并输出到 Elasticsearch 或其他存储。
- 优点： 解析能力最强（Grok 正则、KV、JSON）、内置大量 filter 插件、与 Elasticsearch 深度集成。
- 缺点： 资源消耗大（Java 堆内存 1–4GB）、启动慢、Pipeline 配置复杂。
- 适用场景： 需要复杂日志解析（如 Nginx 日志、数据库慢查询）、数据清洗要求高的企业级部署。
| 维度 | Agent（Filebeat） | Fluentd | Logstash |
|---|---|---|---|
| 内存占用 | ~30 MB | ~200 MB | ~1–4 GB |
| 解析能力 | 基础（JSON / 正则） | 中等（正则 + 插件） | 强大（Grok + 自定义） |
| 吞吐量 | 高（单核 10K+ 行/秒） | 中（单核 5K–8K 行/秒） | 中（单核 3K–6K 行/秒） |
| 部署复杂度 | 低 | 中 | 高 |
2.3 日志采集架构图
下图展示了一个典型的混合采集架构：Agent 负责边缘节点，Fluentd 作为统一路由层，Logstash 承担复杂解析任务，最终汇聚到后端存储。
2.4 采集配置示例
以下是一个 Fluentd 配置片段，展示如何从容器标准输出采集日志，添加标签并路由到 Elasticsearch：
<source>
@type tail
path /var/log/containers/*.log
pos_file /var/log/fluentd-containers.log.pos
tag kubernetes.*
format json
read_from_head true
</source>
<filter kubernetes.**>
@type record_transformer
<record>
hostname "#{Socket.gethostname}"
service_name ${record["kubernetes"]["labels"]["app"]}
</record>
</filter>
<match kubernetes.**>
@type elasticsearch
host elasticsearch-logging
port 9200
logstash_format true
logstash_prefix k8s-logs
flush_interval 5s
</match>pos_file 必须持久化到宿主机磁盘，否则容器重启后会导致重复采集或日志丢失。同时，建议为每个采集管道设置独立的 buffer_chunk_limit 与 flush_interval，避免背压导致 OOM。
2.5 分类与采集的协同策略
在实际工程中，日志分类与采集架构需要协同设计：
- 业务日志： 使用 Agent 采集 + Fluentd 路由，保留 30 天热数据，用于 Golden Signals 的延迟与错误率计算。
- 系统日志： 使用 Agent 采集 + Logstash 解析（Grok 提取 CPU/内存指标），保留 90 天，用于饱和度与容量规划。
- 审计日志： 使用独立 Agent 直写对象存储（S3 / GCS），启用 WORM 策略，保留 7 年，仅通过 API 查询。
通过这种分层策略，SRE 团队既能保证 Golden Signals 指标的实时性，又能满足合规审计的长期存储需求。