ELK 是 Elasticsearch、Logstash、Kibana 的合称，实际生产中需加入 Filebeat 构成 ELKB；Logstash 因资源消耗大不宜直连业务机，Filebeat 轻量负责采集，其 registry 文件丢失会导致日志重复或遗漏；ES 索引需按日期命名以支持 ILM 和查询优化；跨网段时 Filebeat 与 Logstash 间必须启用 TLS 加密。
ELK 不是一个软件，而是 Elasticsearch、Logstash、Kibana 三个开源组件的合称——它们共同构成一套可落地的日志集中处理流水线：从采集、清洗、存储到可视化，环环相扣。
真正用起来，你会发现光靠这三件套在生产环境往往不够稳，所以实际架构里几乎必加 Filebeat（或其它 Beats），形成 ELKB（E+L+K+Beats） 的事实标准组合。
为什么 Logstash 不直接装在每台业务服务器上？
因为 Logstash 是 JVM 进程，吃内存和 CPU 明显。在高并发日志场景下（比如单机每秒写入 5k 行日志），它容易拖垮宿主机，甚至导致业务响应变慢。
- 真实案例：某电商服务节点部署 Logstash 后，JVM GC 频繁，CPU 持续 >90%，Nginx access 日志延迟堆积超 2 分钟
-
Filebeat是 Go 编写的轻量 Agent，常驻内存仅 10–20MB，吞吐压测可达 50k+ events/sec，适合嵌入业务服务器 - 分工明确：
Filebeat负责“搬运”，Logstash负责“精加工”（如 grok 解析、字段 enrich、多源合并）
Filebeat 的 registry 文件丢了会怎样？
Filebeat 默认把每个日志文件的读取位置（offset）记在 /var/lib/filebeat/registry 中。这个文件一旦被误删或损坏，后果是：
