ELK日志平台 核心功能：四个组件的职责与关键配置
核心功能：四个组件的职责与关键配置
先把分工讲清楚，排查问题时才容易定位到底卡在哪一段。
| 组件 | 职责 | 典型资源占用 |
|---|---|---|
| Filebeat | 跑在业务机，跟踪日志文件、记录读取偏移、做多行合并，输出到 Logstash 或 ES | 极轻，常驻几十 MB 内存 |
| Logstash | 解析、拆分、富化、改写字段，再批量输出；是整条链路的 CPU 消耗大户 | 重，JVM 应用，需要单独限流 |
| Elasticsearch | 建立倒排索引、存储、执行检索与聚合，管理分片与生命周期 | 最重，磁盘与内存决定容量 |
| Kibana | 查询界面、图表、仪表盘、保存查询，也承载部分管理功能 | 中等，主要吃内存 |
Logstash 的三段结构与常用 filter
Logstash 配置永远由 input、filter、output 三段组成，filter 里按声明顺序依次执行，前一个 filter 产出的字段可以被后一个引用。
| Filter | 作用 | 注意点 |
|---|---|---|
grok | 用模式匹配把非结构化文本拆成字段 | 正则回溯代价高，模式要写得尽量精确，必要时加 timeout_millis |
date | 把日志里的时间字符串解析成 @timestamp | 必须写对 pattern，解析失败会用采集时间，导致时间轴错乱 |
mutate | 改名、删除、类型转换、大小写转换 | 批量 remove_field 能显著降低索引体积 |
dissect | 按分隔符切分，不做正则 | 格式固定时比 grok 快得多，优先选它 |
geoip | 把 IP 解析成国家城市坐标 | 需要数据库文件，会拖慢吞吐，别对全量日志开 |
Mapping 字段类型与 dynamic 策略
| 字段类型 | 用途 | 典型坑 |
|---|---|---|
text | 需要全文分词的正文 | 不能直接聚合与排序 |
keyword | 精确匹配、聚合、排序 | 超长字符串浪费空间，可加 ignore_above |
long / double | 数值范围统计 | 数字被误判成字符串后无法做数值聚合 |
date | 时间轴与区间过滤 | 格式声明错会全量解析失败 |
ip | 网段查询 | 写入非 IP 内容会导致文档被拒 |
boolean | 真假标记 | 字符串 "true" 与布尔 true 行为不同 |
dynamic 决定遇到未知字段怎么办：true 自动推断并加入 mapping（默认，最省事但最容易翻车），false 忽略新字段不建索引，strict 直接拒收。生产日志建议用模板预先声明字段，把 mapping 固定下来，避免「某个服务先输出了一个字符串、后输出了数字，字段被推成 text，后面想按这个字段聚合只能重建索引」。
ILM 生命周期与 rollover
| 阶段 | 典型动作 | 目的 |
|---|---|---|
| hot | 持续写入、rollover、分片数固定 | 保证写入吞吐 |
| warm | 设为只读、段合并、副本数下调 | 降低资源占用、提升查询效率 |
| cold | 迁移到廉价大容量节点、可搜索快照 | 进一步降本 |
| delete | 到期删除整个索引 | 控制总量，满足留存要求 |
rollover 的触发条件通常组合三条：索引达到某个大小、文档数达到某个量级、或者存在时间超过某个时长，任一满足就切新索引。保留天数怎么定，取决于合规要求、排障习惯和预算：核心交易链路留得久一些，调试类日志留短一些，具体阈值以官方文档与自身容量测算为准。
分片规划上不要把索引切得太碎。分片数量过多会让集群元数据膨胀、Master 压力大；单分片过大则恢复慢、迁移费时。经验做法是让单个分片控制在合理大小区间，并把每个索引的分片总数压到较小值，具体数值以官方文档为准，同时结合自己的写入速率做压测验证。
