设计日志分析系统
需求
设计日志分析系统，支持：
- 每日 TB 级日志数据的采集和存储
- 全文搜索（秒级响应）
- 实时异常告警
- 链路追踪
架构设计
各层技术选型
| 层级 | 组件 | 说明 |
|---|---|---|
| 采集 | Filebeat / Fluentd | 轻量 Agent，低资源消耗 |
| 传输 | Kafka | 削峰、解耦、多消费者 |
| 实时处理 | Flink | 实时异常检测、告警 |
| 离线存储 | Elasticsearch | 全文检索、聚合分析 |
| 可视化 | Kibana / Grafana | 日志搜索、看板 |
日志规范
{
"timestamp": "2024-01-15T10:30:00.123Z",
"level": "ERROR",
"service": "order-service",
"trace_id": "abc123",
"span_id": "def456",
"message": "Payment failed: timeout",
"context": {
"user_id": "u_10001",
"order_id": "o_20001",
"error_code": "PAY_TIMEOUT"
}
}
日志设计原则
- 结构化：JSON 格式，便于解析和检索
- 标准字段：timestamp、level、service、trace_id 必须有
- 上下文丰富：携带 user_id、order_id 等业务字段
- 级别规范：DEBUG/INFO/WARN/ERROR/FATAL 统一使用
实时告警规则
-- Flink SQL：5 分钟内 ERROR 日志超过 100 条则告警
SELECT
service,
TUMBLE_START(event_time, INTERVAL '5' MINUTE) AS window_start,
COUNT(*) AS error_count
FROM log_stream
WHERE level = 'ERROR'
GROUP BY
service,
TUMBLE(event_time, INTERVAL '5' MINUTE)
HAVING COUNT(*) > 100;
常见面试问题
Q1: 如何控制日志存储成本？
答案：
| 策略 | 说明 |
|---|---|
| 分级存储 | 热数据(7天) SSD → 温数据(30天) HDD → 冷数据(90天) 对象存储 |
| 采样 | DEBUG 日志只采集 10%，ERROR 日志 100% 保留 |
| 压缩 | Elasticsearch 开启 best_compression |
| 索引优化 | 只对高频搜索字段建索引，减少 mapping 字段 |
| 自动过期 | ILM（Index Lifecycle Management）自动滚动删除 |
Q2: 日志和指标监控的区别？
答案：
| 维度 | 日志 | 指标 |
|---|---|---|
| 数据形态 | 非结构化/半结构化文本 | 结构化数值 |
| 适用场景 | 问题排查、审计追溯 | 趋势监控、告警 |
| 存储成本 | 高（原始文本） | 低（聚合数值） |
| 查询方式 | 全文搜索 | 时序查询、聚合 |
| 工具 | ELK | Prometheus + Grafana |
相关链接
- Elasticsearch - 搜索引擎
- Flink - 实时处理
- Kafka - 消息队列