日志系统基础：日志类型、格式、采集、存储
做联邦审计，第一步就是搞懂日志从哪来、长什么样、怎么收、放哪儿。你别看这听起来基础，实际项目里很多人就是在这一步踩了坑，后面整个查询链路全崩。我记得有一次帮客户排查跨组织审计延迟，折腾了两天，最后发现是日志采集端的格式没对齐——唉，白白浪费了两天。
这一章我就把日志系统的四块核心掰开揉碎讲清楚。你理解透了，后续的跨组织查询才立得住。
日志类型
不同系统、不同组件输出的日志，用途差异很大。我一般把日志分成下面几类：
| 类型 | 说明 | 典型来源 |
|---|---|---|
| 应用日志 | 业务代码写出来的，记录业务事件、错误、调用链 | Java应用、Python服务、微服务网关 |
| 系统日志 | 操作系统层面的日志 | /var/log/syslog, Windows Event Log |
| 安全日志 | 认证、授权、异常登录、权限变更 | SSH登录记录、防火墙、WAF |
| 审计日志 | 合规要求，记录谁在什么时间做了什么操作 | 数据库审计、文件访问审计、API操作日志 |
| 网络日志 | 流量、连接、DNS查询 | 路由器、交换机、LB |
我的习惯：在联邦审计场景下，审计日志永远是核心，但应用日志往往能帮上大忙——很多时候业务异常先发生在应用层。
日志格式
日志格式的混乱程度，我估计你想象不到。光JSON就有几十种变体，Syslog还有不同的Facility和Severity。项目里我见过最离谱的是同一个组织内，三个系统用了三种时间格式……解析器的正则写了200行还没完全覆盖。
常见的格式对比：
| 格式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| JSON | 结构化，解析方便，易扩展 | 阅读性一般，长日志体积大 | 微服务、分布式系统 |
| Syslog (RFC 5424) | 标准协议，成熟生态 | 字段有限，非结构 | 网络设备、Linux系统 |
| CSV/TSV | 极简，体积小 | 不支持嵌套，转义麻烦 | 批量导出、传统BI |
| 自定义文本 | 灵活，可读好 | 解析成本高，标准缺失 | 遗留系统、快速开发 |
| Protocol Buffers | 高性能，压缩比高 | 调试困难，Schema管理 | 高性能内部通道 |
我曾经踩过的坑：有一回做跨组织日志合并，A组织用ISO 8601时间，B组织用Unix时间戳，C组织用了YYYYMMDDHHMMSS……最后我不得不用正则把所有格式转成统一的毫秒时间戳。从那以后我定了个规矩：日志格式必须前置协商，时间精确到毫秒，时区统一UTC。
我建议你在联邦审计项目启动时，就要求所有参与方输出一份“日志格式声明”，至少包含：
- 完整字段列表及类型
- 时间戳格式（含时区）
- 敏感字段脱敏规则（如IP、用户ID）
- 必选字段（至少包含
event_id、timestamp、source_org、operation）
日志采集
采集方式决定你能拿到什么粒度的数据。常用的采集方案：
- Agent采集：在服务器上部署采集守护进程（Filebeat、Fluentd、Logstash）。支持文件尾随、元数据添加。
- Syslog转发：网络设备原生支持，通过TCP/UDP发到中央收集器。
- API/Webhook：应用主动推送到日志网关。适合云原生、Serverless。
- 数据库CDC：通过Binlog或WAL捕获变更日志。常用于审计表。
- 消息队列消费：从Kafka、RabbitMQ直接拉取日志流。
关键点：在联邦审计场景下，采集阶段就需要保留来源组织标识。我通常在采集侧就打上 org_id 标签，否则后面根本没法区分日志是谁的。
举个例子，用Filebeat采集应用日志并添加组织标签：
# filebeat.yml 配置片段
filebeat.inputs:
- type: log
enabled: true
paths:
- /var/log/app/*.log
fields:
org_id: "org_a"
env: "production"
fields_under_root: true
output.elasticsearch:
hosts: ["https://es-central:9200"]
index: "audit-logs-%{+yyyy.MM.dd}"
小技巧：采集时尽量保持原始消息不丢字段，避免在Agent侧做复杂的结构化。复杂的解析放到后端的Logstash或Fluentd Pipeline里做，这样出问题时好回退排查。
日志存储
存储选型直接影响查询性能和数据保留策略。我见过太多人一把梭全塞ES，结果索引膨胀到月GB级，查询慢得像蜗牛。
常见的存储对比：
| 方案 | 查询性能 | 存储成本 | 水平扩展 | 适用数据量 |
|---|---|---|---|---|
| Elasticsearch | 全文搜索快，聚合慢 | 中等（副本开销） | 易扩展 | TB级 |
| Loki | 按Label查询快，无索引 | 低 | 容易 | PB级 |
| ClickHouse | 分析聚合极快 | 低（列式压缩） | 需分片 | PB级 |
| HDFS + Hive | 批处理，实时性差 | 极低 | 天然 | EB级 |
| 对象存储 (S3/MinIO) | 不支持实时查询 | 最低 | 天然 | 无限 |
注意：跨组织查询场景下，数据分区策略至关重要。我建议至少按
org_id + 日期 做分区。另外，冷热分层必须做——近30天的日志放热存储，超过30天的自动迁移到对象存储。否则成本控制不住。
讲到这，我把这一章的知识体系画成一张图，你一看就明白：
最后说一点我的体会：日志系统设计得像一个“管道”，每个环节都留好扩展点。日志类型可能新增，格式可能变更，采集方式会演进，存储方案也可能换。你只要把采集管道和存储模式松耦合，后面改起来才不会伤筋动骨。