elk栈实现日志实时采集与检索的关键在于组件分工明确、数据链路通畅、配置贴合场景：filebeat轻量采集并发送至kafka，logstash结构化解析，es倒排索引支持秒级检索，kibana可视化与告警联动。
ELK 栈实现日志的实时采集与检索，关键不在“装齐三个软件”，而在于各组件分工明确、数据链路通畅、配置贴合实际场景。核心是让日志从源头出发，毫秒级抵达可查可看的终端。
日志实时采集：轻量+精准+可靠
不建议直接用 Logstash 去每台服务器上读文件——资源开销大、易成瓶颈。生产环境普遍采用 Filebeat 作为采集端：
- 部署在每台应用服务器上，监控指定路径（如 /var/log/app/*.log 或 /var/log/nginx/access.log）
- 启用多行合并，尤其对 Java 异常堆栈：用 multiline.pattern: '^[[:space:]]+(at|\.{3})' 把整段异常归为一条日志
- 通过 fields 添加业务标识，比如 service: "order-service" 和 env: "prod"，后续过滤和聚合全靠它
- 输出不直连 Elasticsearch，而是先发到 Kafka —— 提供缓冲、削峰、解耦，避免下游抖动导致日志丢失
日志实时处理：结构化才是检索前提
Logstash 在这里不是“搬运工”，而是“翻译员”：把原始文本日志变成带字段的结构化文档。
- Input 接收 Kafka 中按 topic（如 app-logs）分好的日志流
- Filter 阶段必须做两件事：Grok 解析（例如用 %{NGINXACCESS} 提取 status、response_time、client_ip）和 Date 解析（把日志时间转成 @timestamp 字段，ES 检索才准）
- 可选但推荐：用 Mutate 删除无用字段、重命名、类型转换（如把字符串 response_time 转成数字），减少 ES 存储压力
日志实时存储与检索：ES 不是数据库，是搜索引擎
Elasticsearch 的实时性依赖于其倒排索引机制和默认刷新间隔（1 秒），但要真正“秒级可见”，还需注意：
- 索引按天或按服务建模，例如 nginx-access-%{+YYYY.MM.dd}，便于生命周期管理（ILM）自动删除旧数据
- 确保 @timestamp 字段存在且类型为 date，Kibana 时间筛选器才生效
- 查询时直接用 Kibana 的 Discover 页面，输入 service: "user-service" AND status: 500，毫秒返回结果；不用写复杂 DSL，基础语法足够覆盖 90% 排查场景
可视化与交互：让检索结果“说话”
Kibana 不只是画图工具，它是分析入口：
- 用 Visualize 快速生成响应时间 P95 折线图、错误码分布饼图、地域访问热力图
- Dashboard 上组合多个图表，并绑定全局时间范围和筛选器（如点击某个 service 标签，所有图表联动刷新）
- 设置基于查询的告警（Alerting）：例如 “过去 5 分钟内 5xx 错误数 > 100”，触发邮件或钉钉通知
