illegalCreed

中文

English

中文

English

Appearance

入门：日志采集流水线与全文检索 ​

基于 ELK Stack 8.x（Elasticsearch + Logstash + Kibana + Beats）· 核于 2026-08

速查 ​

  • 是什么：ELK Stack 是 Elasticsearch（分布式全文检索引擎）+ Logstash（日志解析管道）+ Kibana（可视化）三件套，加上 Beats（轻量采集 agent）合称 Elastic Stack。它用 Beats 采集 → Logstash 解析 → ES 存储 → Kibana 检索，是日志聚合与全文检索的事实标准。
  • 四大组件职责：①Beats（采集，Filebeat/Metricbeat 等）；②Logstash（解析转换，input/filter/output 管道）；③Elasticsearch（存储 + 全文检索，倒排索引）；④Kibana（可视化与检索 UI）。
  • 典型流水线：应用 → 日志文件 → Filebeat（采集）→ Logstash（grok 解析/mutate 改字段）→ Elasticsearch（存+索引）→ Kibana（Discover 检索/Dashboard）。也可 Filebeat 直接发 ES（用 Ingest Node 做轻量解析，省去 Logstash）。
  • Beats 家族：Filebeat（日志文件）、Metricbeat（系统/服务指标）、Heartbeat（可用性探活）、Packetbeat（网络流量）、Auditbeat（审计数据）、Winlogbeat（Windows 事件）、Functionbeat（云函数）。
  • ES 全文检索原理：倒排索引——对文档分词后建「词 → 文档列表」映射，让任意关键词秒级定位。配合分词器（中文用 IK）、相关性评分（BM25）做全文搜索。
  • ES 集群：**分片（shard）**水平拆分数据 + **副本（replica）**高可用；节点分 master/data/coordinating/ingest 角色。
  • Kibana 检索：Discover（Lucene/KQL 查询日志）、Dashboard（多 Visualize 大盘）、Visualize（柱状/饼图/地图）、Alerting（基于 ES 查询告警）。
  • 与 Loki 对比：ELK 全文检索强（倒排索引）但存储贵（每 token 索引）；Loki 只索引 label 不索引内容，省存储约 10 倍但弱全文检索。按场景选：要全文搜索选 ELK，要省钱+定位过滤选 Loki。
  • 与 Prometheus 对比：ELK 做日志与全文检索，Prometheus 做时序指标——指标监控选 Prometheus（PromQL 专精），日志选 ELK。

一、ELK 是什么：日志聚合的事实标准 ​

日志散落在每台机器、每个容器，要查问题就要 SSH 到各机器 grep——低效。ELK Stack 把所有日志集中到 ES，用 Kibana 统一检索。四个组件分工：

┌─ 采集 ─┐   ┌─ 解析 ─┐   ┌─ 存储检索 ─┐   ┌─ 可视化 ─┐
│ Beats  │──>│ Logstash│──>|Elasticsearch│──>| Kibana   │
│(轻量   │   │(grok/   │   │(倒排索引+   │   │(Discover/│
│ agent) │   │ mutate) │   │ 分布式集群) │   │ Dashboard│
└────────┘   └─────────┘   └─────────────┘   └──────────┘
  • 为什么分四个组件：单一职责、可独立替换。Beats 轻（Go 写，资源占用小）适合每台机器跑；Logstash 重（JVM）做复杂解析，可只跑几个实例；ES 做存储与检索（核心）；Kibana 做 UI。
  • 简化版：小规模可省去 Logstash——Filebeat 直接发 ES，用 ES 的 Ingest Node（轻量解析 pipeline）做 grok，减少组件。

二、Beats 家族：轻量采集 agent ​

Beats 是 Elastic 出的轻量采集 agent（Go 语言，资源占用远小于 Logstash 的 JVM）：

Beat采集什么典型用途
Filebeat日志文件应用/系统日志采集（最常用）
Metricbeat系统/服务指标CPU/内存/MySQL/Redis 指标
Heartbeat可用性探活服务的 uptime/延迟监控
Packetbeat网络流量网络层抓包分析（DB/HTTP）
Auditbeat审计数据Linux audit/文件完整性
WinlogbeatWindows 事件Windows 服务器事件日志
Functionbeat云函数Serverless 场景采集
  • Filebeat 的工作方式：注册「input」（日志文件路径）→ tail 跟踪新行 → 打包成「event」（带 file/offset 元信息）→ 发到 Logstash 或 ES → 收到 ACK 后记录进度（registry 文件），崩溃重启能续传。
  • Module：Filebeat 自带常见日志的解析 Module（Nginx/Apache/MySQL/Redis/Kafka），开箱即用预置 grok pattern + Kibana Dashboard。

三、Logstash：解析转换管道 ​

Logstash 是日志的「加工厂」——input 收数据、filter 解析转换、output 发出去：

ruby
input {
  beats { port => 5044 }              # 接 Filebeat
}
filter {
  grok {                              # 正则解析日志行
    match => { "message" => "%{TIMESTAMP_ISO8601:timestamp} %{LOGLEVEL:level} %{GREEDYDATA:msg}" }
  }
  mutate {                            # 改字段
    add_field => { "env" => "prod" }
    remove_field => ["message"]       # 删原始字段省空间
  }
  date {                              # 解析时间字段为 @timestamp
    match => ["timestamp", "ISO8601"]
  }
}
output {
  elasticsearch {                     # 存 ES
    hosts => ["es:9200"]
    index => "app-logs-%{+YYYY.MM.dd}" # 按天建索引
  }
}
  • filter 插件丰富：grok（正则解析）、mutate（改字段）、date（时间解析）、json/json_lines（JSON 解析）、geoip（IP 转地理）、ruby（写 Ruby 脚本）。
  • 代价：Logstash 是 JVM 应用，资源消耗大（CPU/内存），常只跑少数实例做集中解析，而非每台机器跑。

四、Elasticsearch：分布式全文检索引擎 ​

ES 是 ELK 的核心——基于 Apache Lucene 的分布式全文检索引擎：

  • 倒排索引（核心）：对文档分词后建「词 → 包含该词的文档列表」映射。查询 level:error 时，直接查「error」这个词对应的文档列表，秒级返回——这是全文检索的物理基础。
  • 分片（shard）+ 副本（replica）：索引（index）水平拆成多个主分片（primary shard），每个主分片有若干副本（replica）——水平扩展 + 高可用。查询时多个分片并行，写入时按 routing 分发。
  • 节点角色：master（集群管理）、data（存数据）、coordinating（请求路由/结果合并）、ingest（轻量解析，可替代部分 Logstash）。
  • mapping：定义字段类型（text/keyword/long/date）。text 会分词（全文检索），keyword 不分词（精确匹配/聚合）。
  • 聚合（aggregation）：类似 SQL 的 GROUP BY + 聚合函数——按字段分组、求和、求平均、分桶（histogram/date_histogram）。
  • 集群运维：JVM 调优（堆内存建议 ≤32GB 避免指针压缩失效）、分片均衡、避免脑裂（quorum 选举）、版本升级（滚动重启）。

五、Kibana：检索与可视化 UI ​

Kibana 是 ELK 的 UI——连接 ES 做检索与可视化：

  • Discover：日志检索主界面，Lucene/KQL 查询（level:error AND service:order）+ 字段过滤 + 时间轴下钻。
  • Dashboard：多个 Visualize 聚合成大盘（类似 Grafana 的 Dashboard）。
  • Visualize：单种可视化（柱状/饼图/地图/表格/指标）。
  • Alerting：基于 ES 查询的告警（条件满足触发）。
  • KQL（Kibana Query Language）：比 Lucene 语法更友好，level:error and service:"order service"。

六、与 Loki / Prometheus 的边界 ​

ELK 不是万能——它有明确的适用边界：

工具强项弱项
ELK全文检索、复杂聚合、日志即数据存储贵、运维重、不适合时序指标
Loki省存储（约 ES 1/10）、与 Grafana 联动弱全文检索（grep 流式）
Prometheus时序指标、PromQL、告警不做日志/检索
  • 日志选 ELK 还是 Loki：要全文模糊检索、复杂聚合、日志内容是核心 → ELK；查询是按 label 定位 + 关键词过滤、要省钱 → Loki。两者常并存。
  • 指标选 ELK 还是 Prometheus：指标监控一律选 Prometheus（PromQL 专精、Pull 模型），ELK 做 Metricbeat 是补充不是替代。

下一步 ​

理解了 ELK 的流水线与组件职责后，下一步深入两个核心维度——日志流水线（Filebeat + Logstash + ES 实操）与与 Grafana LGTM 对比（ELK vs Loki 选型决策）。