linux日志审计核心是让日志“可查、可判、可溯”：filebeat轻量采集与初步清洗，logstash深度解析，es通过ilm治理索引，kibana实现检索、可视化与告警闭环。
Linux集中化日志审计的核心，不在于堆砌组件，而在于让原始日志从“能看”变成“可查、可判、可溯”。Filebeat 负责轻量、稳定地把日志从各台服务器运出来；ELK（Elasticsearch + Logstash + Kibana）则分工协作完成清洗、存储与呈现。关键不是全链路都用上，而是清洗环节落在哪里更合理、更可控。
Filebeat 做基础采集与初步结构化
Filebeat 不只是搬运工，它能完成字段标注、时间标准化、简单过滤等轻量清洗任务，避免把脏数据直接塞给 Logstash。推荐在 filebeat.yml 中启用 processors：
- 用 add_host_metadata 自动添加 host.name、host.ip，便于后续按机器维度归因
- 用 add_fields 注入环境标签，如 env: prod、service: api-gateway
- 用 dissect 或 convert 处理固定分隔符日志（如 | 分隔的业务日志），比 Logstash 的 grok 更快更省资源
- 在 output 前加 timestamp processor，强制统一为 UTC，规避本地时区混乱
Logstash 承担深度清洗与语义解析
当日志格式复杂、需正则提取、字段补全或条件脱敏时，Logstash 是不可替代的清洗中枢。一个典型 pipeline.conf 清洗段应包含：
- date 插件：校准 @timestamp，依据日志内容中的时间字段（如 “2026-08-29T04:15:22+0800”），而非系统接收时间
- grok 插件：复用内置模式（如 %{COMBINEDAPACHELOG}）快速解析 Nginx/HTTP 日志；自定义 pattern 提取 trace_id、error_code 等业务字段
- if 判断：过滤掉 /health、/metrics 等探测请求，或 level=DEBUG 的冗余条目，降低 ES 写入压力
- mutate 插件：重命名、删除敏感字段（如 client_ip → client_anonymized）、类型转换（status 字段转成 integer）
Elasticsearch 配合 ILM 保障清洗成果落地
清洗后的结构化数据必须存得稳、查得快、删得准。这依赖 Elasticsearch 的索引治理能力：
- 索引名按天滚动，如 nginx-access-2026.08.29，配合 index pattern nginx-access-* 在 Kibana 中自动识别
- 配置 ILM 策略：热阶段保留7天（高频查询）、温阶段压缩保留30天（低频归档）、冷阶段自动删除90天前数据
- 启用 ingest pipeline，在写入前做最后补全（如通过 geoip 插件解析 IP 归属地），避免清洗逻辑分散到多个环节
- 设置只读索引别名（如 nginx-access-current），应用侧始终写入别名，解耦索引生命周期与业务写入
Kibana 实现审计闭环：从检索到告警
清洗的价值最终体现在可操作性上。Kibana 不仅是看板，更是审计执行终端：
- 创建 Index Pattern 后，在 Discover 中用 KQL 快速筛选：比如 error_level: "ERROR" and service: "payment"
- 用 Visualize 构建“每分钟 5xx 错误数”折线图，叠加阈值线，异常时视觉突出
- 在 Dashboard 中整合多视图：左侧是错误分布饼图，右侧是 top 10 异常 IP 表格，下方嵌入原始日志上下文（@timestamp ±30s）
- 通过 Alerting 功能配置规则，例如“过去5分钟 error_count > 100”，触发企业微信或邮件通知，并附带跳转链接直达 Kibana 查询页
