P11 如何设计分布式日志存储架构
面试题：微服务/分布式系统里，日志散落在各个机器上，怎么统一收集、存储和查询？
典型架构：ELK / EFK
text
应用日志 → Logback/Log4j2 输出 → Filebeat/Logstash 采集 → Kafka 缓冲 → Logstash 过滤 → ES 存储 → Kibana 展示核心组件
| 组件 | 作用 |
|---|---|
| 采集端（Filebeat/Logstash） | 从各节点读取日志文件/直接推送，轻量采集 |
| 缓冲层（Kafka） | 削峰、解耦，防止日志洪峰打垮 ES |
| 加工层（Logstash） | 解析、过滤、脱敏、格式化 |
| 存储（Elasticsearch） | 分布式全文检索，按天/按索引分片 |
| 展示（Kibana） | 搜索、看板、告警 |
关键设计点
1. 全链路追踪（TraceID）
分布式系统最关键的是把一次请求的日志串起来：
- 网关/入口生成
traceId，通过 RPC 透传（Header）； - 日志格式统一带上 traceId、userId、服务名、时间；
- 在 Kibana 里按 traceId 一键查看整条调用链。
2. 日志规范
- 统一 JSON 格式输出，方便解析；
- 分级（DEBUG/INFO/WARN/ERROR），线上默认 INFO；
- 敏感信息（密码、身份证）脱敏后再落日志。
3. 存储与容量
- ES 索引按天/按月滚动，老索引自动删除或归档冷存储；
- 控制日志保留周期（如 7~30 天）；
- 采集侧限流：单机日志量过大时降级采样。
4. 高可用与性能
- Kafka 缓冲层保证日志不丢、ES 不被冲垮；
- 采集端异常不影响业务（异步、丢日志不阻塞业务线程）；
- 查询性能：按时间范围 + 关键词 + traceId 设计索引。
加分点
- 日志量巨大时可用 Loki（轻量、只索引标签）替代 ES；
- 离线日志（如访问日志分析）可落到 HDFS/对象存储 + Spark 分析；
- 统一打点 + 指标（Metrics）配合日志做故障定位。
一句话总结
Filebeat 采集 → Kafka 削峰 → Logstash 加工 → ES 存储检索 → Kibana 展示，配合全链路 traceId 透传，实现分布式日志的统一收集、关联查询与快速排障。