设计日志收集分析系统
架构设计
关键设计点
日志分级存储
| 存储层 | 保留时间 | 存储介质 | 用途 |
|---|---|---|---|
| 热存储 | 7 天 | SSD ES | 实时查询 |
| 温存储 | 30 天 | HDD ES | 回溯查询 |
| 冷存储 | 90-365 天 | S3/OSS | 合规审计 |
日志规范
{
"timestamp": "2024-01-15T10:30:00.000Z",
"level": "ERROR",
"service": "order-service",
"trace_id": "abc123",
"message": "Failed to create order",
"error": "Connection refused",
"extra": {
"user_id": "u001",
"order_id": "o123"
}
}
提示
日志必须结构化(JSON),包含 trace_id 以便和链路追踪关联。避免随意拼接字符串日志。
容量规划
日志量估算:
- 单台服务器: ~1GB/天
- 100 台服务器: ~100GB/天
- ES 索引 1 副本: 200GB/天
- 7 天热存储: 1.4TB ES 集群
常见面试问题
Q1: 日志量太大,ES 扛不住怎么办?
答案:
- 采样:非核心服务日志按比例采样(如保留 10%)
- 分级:DEBUG/INFO 日志只在异常时开启
- 缓冲:Kafka 削峰,ES 按自身速度消费
- ILM:Index Lifecycle Management 自动归档冷数据到 S3
- 替代方案:考虑 Loki(只索引标签不索引内容,存储成本低 10 倍)