Filebeat+Logstash+ELK日志系统核心是实现日志采集→传输→解析→存储→可视化闭环，关键在配置对齐、字段一致与传输可靠；Filebeat轻量采集并预处理，Logstash深度解析转换，ES合理建模，Kibana配置索引模式与可视化看板。
用 Filebeat + Logstash + ELK（Elasticsearch + Kibana）搭建日志收集分析系统，核心是让日志从源头（服务器、应用）→ 轻量采集（Filebeat）→ 可处理中转（Logstash）→ 存储与检索（Elasticsearch）→ 可视化（Kibana）形成闭环。关键不在于组件堆砌，而在于各环节配置对齐、字段一致、传输可靠。
Filebeat：轻量级日志采集器，专注“拿得准”
Filebeat 不做复杂解析，只负责监控文件变化、读取新行、按定义的路径和编码抓取内容，并转发给 Logstash 或直传 Elasticsearch。适合部署在业务服务器上，资源占用低。
- 配置 filebeat.inputs 指定日志路径，支持通配符（如
/var/log/nginx/*.log），注意权限：确保 filebeat 用户能读取目标文件 - 用 processors 做基础预处理：比如
add_host_metadata自动加主机名，dissect或grok（需 7.10+）做简单结构化（如拆分 Nginx access 日志的 IP、时间、状态码） - 输出推荐走 Logstash（
output.logstash），便于后续统一过滤；若跳过 Logstash，直连 ES 需开启setup.ilm.enabled: false（避免索引生命周期冲突）
Logstash：日志“加工厂”，重点在“理得清”
Logstash 接收 Filebeat 发来的数据后，执行解析、丰富、转换、路由等操作。它灵活但资源消耗大，建议独立部署，不与 Filebeat 同机。
- 输入插件用 beats，监听端口（默认 5044），并校验 SSL（生产环境必须启用）
- 过滤阶段（
filter）是核心：用grok解析非结构化日志（如 Java 异常栈、Syslog 格式）；用date插件将日志中的时间字符串转为 @timestamp 字段；用mutate重命名、删除冗余字段、类型转换（如 status → int） - 输出到 Elasticsearch 时，指定
index名称（如"nginx-access-%{+YYYY.MM.dd}"），配合 ILM 策略自动管理索引生命周期
Elasticsearch + Kibana：存储与呈现，“看得懂”才落地
ES 不是黑盒数据库，需按日志场景合理建模；Kibana 不是点开就用，需提前配置好索引模式和可视化看板。
- ES 中为不同日志类型创建独立索引模板（Index Template），定义 mappings：明确字段类型（如
client_ip设为ip类型，支持范围查询；message设为text+keyword多字段） - Kibana 中先创建 Index Pattern（如
nginx-access-*），确认时间字段选@timestamp；再用 Discover 验证数据是否按时序到达、字段是否可搜索 - 用 Lens 或 Dashboard 快速构建常用视图：QPS 趋势图（X轴时间，Y轴 count）、错误率饼图（筛选 status >= 400）、Top IP 表格（按 client_ip 计数排序）
排障要点：80%问题出在这几个地方
部署后日志“看不见”，别急着重装，先检查这四层链路是否通、字段是否对、权限是否足。
- Filebeat 是否正常运行？查
systemctl status filebeat和日志（/var/log/filebeat/filebeat），确认 output 连接 Logstash 成功（无 connection refused） - Logstash 是否收到数据？在 input 插件后加
stdout { codec => rubydebug }，看控制台是否打印事件；若无输出，可能是 Filebeat 未发、防火墙拦截（5044 端口）、SSL 证书不匹配 - ES 是否写入？用 Kibana Dev Tools 执行
GET /nginx-access-*/_count，或直接查_cat/indices?v看索引是否存在、文档数是否增长 - Kibana 是否识别字段？进入 Index Pattern → “Refresh field list”，确认 grok 解析出的字段（如 response_code）已出现在列表中且类型正确（不是 all）
