ELK 简介与审计日志概念
ELK Stack 到底是什么？
很多人一听到 ELK，下意识就觉得——不就是三个开源工具拼一起吗？
其实没有这么简单。我刚开始接触 ELK 的时候，也以为只是日志收集、存储、可视化这三步。做了一两个项目才发现，真正让 ELK 产生价值的，是它们之间那套「数据管道」的配合方式。
ELK 三大组件分别是 Elasticsearch、Logstash 和 Kibana。后来 Beats 加入，变成 ELK Stack，但核心还是这老三样。我们一个一个说。
Elasticsearch —— 存储与搜索的引擎
Elasticsearch 本质上是一个分布式搜索和分析引擎。它把日志数据倒排索引之后，我们就能秒级搜到任意时间范围内的审计记录。我曾经遇到一个客户，每天产生 200GB 的审计日志，用传统数据库查一次要等十几分钟。换了 ES 之后，同样查询降到 1.2 秒。为什么？因为 ES 的倒排索引天然适合文本搜索，而审计日志里大量字段都是文本型的——用户、IP、操作类型、请求详情。
Logstash —— 管道工
Logstash 的作用就是把各路日志收进来，再洗洗干净，送进 ES。它的三大插件（input、filter、output）就像水管上的阀门和过滤器。我在项目里最常用的 filter 是 grok——它对非结构化日志做正则解析，把一行文本拆成字段。举个真实例子：某次需要解析应用服务器的 combined log format，一行日志里有访问时间、客户端 IP、状态码、响应字节、Referer 等十几个字段。我写了个 grok 模式，匹配率只有 82%，排查了一下午，最后发现是某个反向代理额外塞了一条 X-Forwarded-For 的注释。嗯，grok 的调试确实比较磨人，建议先用 Kibana 的 Grok Debugger 测试。
Kibana —— 就是那个好看的 UI
Kibana 负责把 ES 里的数据变成图表、仪表盘、警报。很多运维同事拿到 Kibana 的第一反应是：“这个搜索框怎么跟 Google 一样？” 确实，它的查询语法（Lucene Query Syntax / KQL）很友好。但我要提醒一句：Kibana 的可用性 完全取决于 ES 中的字段映射和索引模板设计。如果你一开始没规划好，后面做审计日志关联分析时，会发现关键字段没做 keyword 类型，聚合查不出来。我建议在搭建初期，先列出审计日志的必选字段（见下文表格），然后用 PUT _template 预先定义映射。
核心要点：ELK 不是三件套的简单堆叠，而是一条数据管道：Beats/Logstash 采集 → Logstash 解析 → ES 存储索引 → Kibana 分析展示。任何一环的配置失误，都会影响最终审计结果。
审计日志是什么？
审计日志就是谁、在什么时间、通过什么方式、对哪个资源做了什么操作、结果如何这件事的完整记录。它跟普通应用日志最大的区别在于：不可篡改 和 可追溯。
举个例子，你在服务器上执行 rm -rf /data，系统日志只会记录一条 command executed。但审计日志会记录：用户（zhao@corp.com）在 2025-01-15 14:32:18 通过 SSH（源 IP 10.0.1.88）在主机 web-03 上执行了命令 /bin/rm -rf /data，退出码 0，父进程 PID 2345。这两者的丰富度差了几个数量级。
我个人习惯把审计日志分成三层：
- 系统层：Linux auditd、Windows Security Event Log、网络设备 syslog
- 应用层：Web 服务器访问日志、数据库 SQL 审计、容器运行时日志
- 用户行为层：SSH 登录、sudo 操作、云 API 调用
你想想看，如果没有审计日志，某个员工半夜删了数据，你拿什么去定责？日志才是安全运维最后的底牌。
审计日志的标准与规范
常见的几种标准：
| 标准/规范 | 来源 | 常见字段 | 适用场景 |
|---|---|---|---|
| CEE (Common Event Expression) | MITRE | event_id、severity、category | 通用安全事件 |
| CEF (Common Event Format) | ArcSight | deviceProduct、signatureId、outcome | SIEM 集成 |
| RFC 5424 (Syslog) | IETF | priority、timestamp、facility | 网络设备日志 |
| EC (Elastic Common Schema) | Elastic | @timestamp、event.action、user.name | ELK 原生推荐 |
| ISO 27001 附录 A.12.4 | ISO | 日志保留周期、访问控制 | 合规要求 |
说实话，很多团队一开始也不在乎标准，直接用 Logstash 的 json 或 kv 解析成什么算什么。但当你需要做跨系统关联查询时——比如把防火墙日志和 Web 服务器日志通过 source IP 关联——如果字段名不统一（一个叫 src_ip，一个叫 client_address），那就得在 filter 里写一堆 mutate rename，维护起来相当头疼。所以我建议：从一开始就拥抱 ECS，至少把核心字段（时间戳、用户、操作、资源、结果）对齐。
业务价值：为什么要花时间搞审计日志？
可能有同学觉得：“我们公司又不做金融，审计日志用得着这么讲究吗？” 我在项目中遇到的真实案例：某中型电商，有次凌晨数据库被删了订单表。他们之前只开了 MySQL general_log，但日志轮转周期只有 7 天，而且没做索引。报警之后想查谁干的，结果 MySQL 日志文件已经被系统清掉了。最后通过服务器上的 auditd 日志和跳板机堡垒机日志交叉比对，才定位到一个外包开发的员工使用的共享账户。但因为日志格式不一致，花了整整 3 天人工排查，这段时间业务一直处于部分瘫痪状态。
你看，审计日志的核心价值有四点：
- 安全威胁发现：异常登录、暴力破解、权限提升
- 事故溯源：精准定位责任人、操作时间线、影响范围
- 合规审计：满足等级保护、ISO 27001、GDPR 等要求
- 运维排障：通过关联日志快速定位故障根因
说白了，ELK 就是实现这些价值的最佳底座之一。它能把海量、异构的审计日志汇聚到一个地方，让你能搜、能看、能报警。
ELK 审计日志巡检的总体逻辑
个人经验：我在做第一个审计日志巡检项目时，犯过一个错误——把所有日志都往 Elasticsearch 里塞，结果集群存储和 CPU 压力直线上升。后来学乖了：只有满足审计价值的日志才需要永久保留，比如登录日志、权限变更、数据删除。而类似 HTTP 200 这种普通成功请求，保留 7 天就够了。一定要先做数据分级。
下面这张图展示了整个巡检自动化的核心流程。你会发现，ELK 在其中扮演了“数据湖 + 搜索引擎 + 可视化”三位一体的角色。
这张图里我把“巡检自动化执行层”单独框出来了。实际上，日常巡检不是每次都要人手动登录 Kibana 点图表，而是通过调用 ES 的 search API 获取预设的审计指标，然后脚本自动对比基线阈值，超阈值就触发告警。
曾经踩过的坑：最开始我直接把 Kibana 的 Dashboard 截图发日报，结果几天后发现有些图表数据不更新，原因是 ES 索引模板滚动后，旧索引被删了，但仪表盘没更新。后来改用 API 定时拉取数据，并检查索引是否存在。记住：巡检自动化不能依赖人工刷新，必须代码化。
接下来我们做什么？
本章我们只打基础。后面的章节会带你一步步：安装 ELK（ES 单机/集群）、配置 Beats 采集 Linux 审计日志、用 Logstash 做字段解析、设计审计索引模板、编写巡检告警规则、最后做成一个能自动出报告的系统。每一节我都会结合自己项目中的真实配置和错误案例来展开。你准备好跟着我动手了吗？