📚 课程目录第1章 ELK生态概览

1、ELK 生态概览：Elasticsearch、Logstash、Kibana 的基本概念与关系，为什么选择 ELK 做审计日志巡检

做审计日志巡检，第一件事就是选对工具。我这些年接触过不少日志方案，有的太重，有的太贵，有的压根儿撑不住海量数据。最后基本都落在了 ELK 上。说它是标配，一点不夸张。

1.1 三条腿的凳子——ELK 三件套

ELK 三个组件各管一摊，缺一不可。我常用一个比喻：Logstash 是搬运工，Elasticsearch 是仓库，Kibana 是展示柜。

组件	核心职责	我眼里它的定位
Elasticsearch	分布式全文搜索、存储、分析引擎	审计日志的“心脏”——所有数据最终落在这
Logstash	数据采集、转换、传输管道	审计日志的“消化道”——从各种源头吃掉数据，消化成标准格式
Kibana	可视化与仪表盘平台	审计日志的“眼睛”——巡检、告警、报表全靠它

小经验：实际项目中，很多人一上来就搭全量 ELK。我个人习惯是先把 Elasticsearch 和 Kibana 跑通，再接入 Logstash。这样能快速验证搜索和可视化，避免后期因 pipeline 配置出问题而排查半天。

1.2 它们仨怎么协作？

举个例子，你的服务器每天产生几十个审计日志文件。Logstash 监听这些文件，读到一条新记录，按规则解析成 JSON，然后推到 Elasticsearch。Elasticsearch 存好并建好索引。你在 Kibana 里配一个“登录失败超 5 次”的图表，Kibana 从 ES 里查数据，画成折线图。

你看，这就是最简路线：采集 → 存储 → 可视化。但实际场景往往更复杂——还要考虑数据过滤、字段映射、性能压测等等。我刚开始做的时候，就踩过 Logstash 内存设太小导致丢数据的坑。后来学会按流量动态调整 pipeline workers，才算稳下来。

1.3 为什么会是 ELK？其他方案不行吗？

你可能听说过 Splunk、Graylog、Loki。各有各的长处。但审计日志巡检这个场景，ELK 有几个硬优势让我坚持用它。

全栈开源：License 友好，不用担心版权锁死。我做过一个政府项目，合规要求必须纯开源方案，ELK 是唯一快速落地的选择。
生态成熟：社区插件、文档、Demo 多到刷不完。遇到任何解析问题，基本都能搜到现成配置。
搜索性能顶级：Elasticsearch 的倒排索引+分片机制，在数十亿审计记录里做聚合查询，秒级出结果。我调过一张运维审计表，一天 3 亿条，按操作用户分组统计，平均响应 1.2 秒。
Kibana 的安全告警：内置规则引擎+Watches，能直接做实时巡检。不用再去搭额外的告警组件。

一句话总结：ELK 让审计日志巡检这件事，从“人工翻文件”变成了“实时仪表盘+自动告警”。

1.4 ELK 在审计日志巡检中的典型位置

下面这张图，是我给团队讲 ELK 时必画的。它展示了数据从产生到巡检闭环的完整流向。

从图中你能看到：数据源 -> Logstash -> Elasticsearch -> Kibana -> 告警。这是一个单向闭环。我实际部署时还会在 Logstash 前加一个 Redis 或者 Kafka 做缓冲层（后面章节会细讲），但核心骨架就是这样。

1.5 为什么说它特别适合审计日志巡检？

审计日志有几个臭脾气：量大、格式乱、需要跨字段关联分析。ELK 恰好每一招都打在点上。

海量写入：Elasticsearch 的批量接口 + 分片并行，我压测过单节点每秒能写入 1 万条以上。加几个节点轻松扛住一天几亿条审计日志。
灵活解析：Logstash 的 grok 插件可以像“正则+命名组”一样处理各种奇葩格式。我处理过某国产数据库的日志，时间戳带中文、字段名带空格，grok 一把梭全部拿下。
实时聚合：Kibana 的 Lens 和 TSVB 能秒级聚合“某用户近 1 小时的操作次数”、“某 IP 触发了多少次敏感指令”。
内置告警：Elastic Alerting 或者 Watcher 可以直接在 ES 上跑定频查询，发现异常就发通知。不需要另搭 Flink 或 Spark。

曾经踩过的坑：一开始我图省事，把所有日志字段都设为 text 类型，结果聚合查询慢得离谱。后来才明白审计日志的 user_id、operate_type 应该用 keyword 类型，时间字段用 date 类型。千万别偷懒。

1.6 一个小案例：从零到出图

假设你有台 Linux 服务器，想巡检 /var/log/secure 里的 SSH 登录失败记录。传统做法是写 shell 脚本 + 发邮件。但用 ELK，你可以这样做：

Logstash 配置一个 file input，监听 secure 文件。
用 grok 正则提取失败时间、用户、来源 IP。
输出到 Elasticsearch 的“ssh-failed”索引。
Kibana 建一个折线图，横轴按小时聚合，纵轴统计失败次数。
再加一条阈值告警：连续 3 个小时失败次数 > 100 则通知。

# 简单的 Logstash 配置示例
input {
  file {
    path => "/var/log/secure"
    start_position => "beginning"
    sincedb_path => "/dev/null"
    codec => plain
  }
}
filter {
  grok {
    match => { "message" => "Failed password for %{DATA:user} from %{IP:src_ip} port %{NUMBER:port}" }
  }
  date {
    match => [ "timestamp", "MMM dd HH:mm:ss" ]
  }
}
output {
  elasticsearch {
    hosts => ["localhost:9200"]
    index => "ssh-failed-%{+YYYY.MM.dd}"
  }
}

配完后跑起来，打开 Kibana 侧边栏的 Discover，搜 ssh-failed* 索引。如果看到数据，恭喜你，第一步搞定了。我每次给新人演示都走这个流程，十分钟就能让他们体会到 ELK 的爽感。

一个提醒：实际生产环境别忘了加 user 字段白名单过滤，否则可能统计到你自己的正常登录。我在某客户现场就因为这个报警太多被运维投诉过……后来加了 if [user] != "admin"。

1.7 小结一下

ELK 不是唯一的选择，但一定是审计日志巡检里上手最快、生态最强、性价比最高的方案。我个人经历里，从几十台服务器的小团队到几千节点的银行，ELK 都能撑住。关键在于理解每个组件的定位，然后根据数据量选择合适的架构。

嗯，这一章我们先停在这里。后面第二章会开始动手——搭建一个最小可用的 ELK 环境，跑通第一条审计日志。到时候我会带上具体的版本参数和踩坑记录。