自建日志平台承担什么
这类组合由采集层、存储层与查询层构成：轻量采集组件负责收集与解析，Elasticsearch 负责存储与检索，Kibana 提供查询与看板。它解决「日志集中、可检索、能出图」三件事。能不能长期用下去，关键不在功能多寡，而在索引与分片规划、生命周期策略和容量预算——这三项没设计好，平台通常在数据量上来半年后开始变慢。
基本信息
| 采集层 | 轻量采集组件负责收集，解析组件负责结构化与富化 |
|---|---|
| 存储层 | Elasticsearch，按天或按周建索引 |
| 查询层 | Kibana 检索、看板与告警 |
| 生命周期 | 使用索引生命周期策略管理热温冷与删除阶段 |
| 容量规划 | 单分片大小与副本数提前规划，避免分片过多 |
| 运维要求 | 集群健康、磁盘水位与写入延迟纳入监控 |
典型使用场景
- 集中检索安全设备与主机的日志
- 按时间范围回溯某次攻击的全部相关记录
- 为规则调优与误报统计提供数据基础
- 按留存周期要求设计存储与归档方案
- 日志量增长后评估拆分集群或引入冷存储
索引策略示例
索引策略示例
索引命名：sec-device-2026.10.12 # 按天索引便于管理
热数据保留 30 天，温数据保留 90 天 # 分级存储
超期数据归档到对象存储或冷节点后再删除 # 归档而非直删
单分片大小控制在几十 GB 量级 # 避免超大分片
副本数按查询压力与存储预算权衡 # 平衡检索与容量常见设计问题与后果
| 设计问题 | 后果 |
|---|---|
| 索引粒度过细 | 分片数量爆炸，集群开销大 |
| 单分片过大 | 查询与恢复变慢，扩容迁移困难 |
| 未定义生命周期 | 磁盘写满后写入被阻断，日志丢失 |
| 解析规则缺失 | 写入全是原始文本，检索体验差 |
安全设备日志字段多，尽量在采集阶段完成结构化，后续查询与统计会高效得多。
索引与分片规划不合理，集群往往在数据量上来半年后才开始变慢，那时再调整代价很高。