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 中。这个文件一旦被误删或损坏，后果是：
- 重启后所有日志文件从头重读——造成大量重复数据进 Elasticsearch
- 如果日志轮转频繁（如
app.log.2026-01-26.gz），还可能因路径匹配失效漏采 - 解决办法不是禁用 registry，而是：定期备份该文件；或改用
filebeat.registry_file指向 NFS 或持久化卷路径
注意：registry 不存事件内容，只存 offset + inode + device ID，体积很小，但极其关键。
Elasticsearch 索引命名为什么要带日期？
比如用 filebeat-8.12.0-2026.01.27 而不是固定名 filebeat，核心原因就两个：
- 生命周期管理：方便用 ILM（Index Lifecycle Management）自动删除 30 天前的索引，避免磁盘爆满
- 查询隔离与性能：按天分索引后，Kibana 查询可自动路由到对应日期索引，跳过无关数据，减少 segment 扫描量
- 配置示例：
output.elasticsearch.index: "filebeat-8.12.0-%{+yyyy.MM.dd}"（注意%{+...}是时间格式化语法，不是变量替换）
Filebeat 和 Logstash 之间要不要 TLS 加密？答案是：只要跨网段、非内网可信环境，必须加。否则日志明文走网络，等于把系统行为直播给中间人。这个细节很多团队上线后才补，但漏洞已经存在了。
