elk分析nginx日志的核心是构建端到端结构化链路：nginx输出json日志→logstash轻量解析（json codec+geoip/user_agent）→es合理分片与ilm管理→kibana用discover验证、dashboard监控、alerting预警。
用 ELK 堆栈分析 Nginx 日志，核心不是堆组件，而是让每条日志从产生开始就具备可检索、可聚合、可展示的结构化基础。关键在于打通“Nginx 输出 → Logstash 解析 → Elasticsearch 存储 → Kibana 查询”这条链路，而不是单纯安装三个软件。
让 Nginx 日志天生可解析
默认的 Nginx 日志是空格分隔的纯文本，Logstash 靠 grok 匹配容易出错、性能差、字段缺失难排查。最稳妥的做法是直接输出 JSON：
- 在 nginx.conf 的 http 块 中定义 log_format，使用双引号包裹键名和字符串值，时间戳用
$time_iso8601保证时区统一 - 示例字段应覆盖排查高频需求：clientip、url、status、responsetime、useragent、domain、xff（用于真实 IP 追溯）
- 启用时指定日志路径和格式：
access_log /var/log/nginx/access.log json; - 重载配置前务必执行
nginx -t验证语法，避免服务中断
Logstash 只做必要解析，不重复造轮子
既然 Nginx 已输出标准 JSON，Logstash 就不需要用 grok 拆字段，只需做轻量级增强：
- 输入插件用
file+codec => json直接解析，避免正则开销 - 过滤阶段补充实用字段：比如用
geoip插件解析 clientip 地理位置，用user_agent提取浏览器/OS 类型 - 输出到 Elasticsearch 时，指定索引名带日期，例如
nginx-access-%{+YYYY.MM.dd}，便于按天滚动和清理 - 若日志量极大（单机日均 >5GB），建议改用 Filebeat 替代 Logstash 做采集端，更轻量、更低资源占用
Elasticsearch 索引设计影响查询速度
日志写入快不代表查得快。索引配置直接影响海量数据下的响应体验：
- 为 nginx-access-* 类索引设置合理的分片数（如每日 2–5 个主分片），避免单分片过大或过多小分片拖慢协调节点
- 关闭不需要全文检索的字段的
"index": true，比如useragent可设为"index": false，只保留keyword类型用于聚合 - 对高频筛选字段（如 status、domain、clientip）启用
doc_values: true（默认开启），支撑快速聚合与排序 - 配置 ILM（Index Lifecycle Management）策略，自动将 30 天前的索引只读、收缩、删除，防止磁盘爆满
Kibana 不是看图工具，而是问题定位界面
可视化不是为了好看，而是把“查什么”变成“一眼看到”。真正高效的 Kibana 使用方式是：
- 先用 Discover 功能验证原始日志是否已正确解析：搜索
status: 500或responsetime > 5，确认字段可过滤、数值可比较 - 创建可视化时优先选「垂直柱状图」统计状态码分布、「折线图」看每分钟请求数趋势、「饼图」看域名占比、「数据表格」查 TOP10 慢请求 URL
- 所有图表组合进一个 Dashboard，并固定时间范围（如最近 15 分钟），配合自动刷新，实现真正的实时监控
- 对关键指标（如 5xx 错误率突增、平均响应时间翻倍）配置 Alerting，触发邮件或企业微信通知，把被动排查变为主动预警
