ELK收集Nginx日志配置实操，步骤梳理与避坑调优技巧

搞ELK那套东西采Nginx日志，身边不少同行都遇到过些奇奇怪怪的报错。整套链路跑起来说白了就三件事：Filebeat去抓本地日志文件，Logstash负责把字段拆开解析，最后Elasticsearch存数据。但进度卡住的地方往往是些细节没对齐，比如Nginx这边得提前把日志输出设成JSON格式，Logstash要老老实实开放5044端口让数据进来，ES的集群地址别手抖填错。现在7.x和8.x版本的ELK组件都能这么用，但不同版本自带的X-Pack权限机制、许可证啥的不一样，最好提前摸清楚，别配到一半被权限挡在外面。

配置时容易踩的三个坑

第一个坑就是端口通不通的问题。云主机安全组要是没放行5044，或者Logstash绑到了127.0.0.1这种本地回环上，Filebeat报上来的数据基本就沉了。碰到怎么都连不上的情况，与其盯着配置文件猜，不如先netstat看看进程到底监听了哪个地址。第二个坑跟JSON日志的格式有关，一旦某一行日志缺了个闭合大括号，Logstash立马给它打上_jsonparsefailure标签，解析出来的字段全乱套了。我的做法是在过滤链里加个判断，遇上带这个标签的日志直接丢掉，省得它把整个解析管道拖慢。最后还有一个容易被忘掉的认证配置，要是ES开了账号密码，Logstash的输出那边没把用户名密码配进去，数据丢得无声无息，连条像样的报错都不给，排查起来很耗时间。

性能优化从过滤器开始

做优化的时候，最先动刀子的就是过滤器那块。grok正则看着灵活，实际上很吃CPU，像Nginx日志这种格式固定的东西，用dissect插件切字段能快几十倍。提前在mapping里把客户端地址、访问用户、请求时间这些位置定死，解析速度就上去了。多余的字段会拖大索引，用prune插件按黑名单清理掉不用的字段，性价比很高。ES那边的分片数也别贪多，单日百GB这种量级，设三五个主分片加一个副本足够用了。把refresh_interval拉到30秒，集群写入压力能直接砍掉一半左右。要是Kibana查数据觉得卡，多半是原始message字段太长占资源，不妨在Filebeat里用exclude_lines去掉没用的日志行，或者在Logstash里用mutate插件把不需要的原始字段移除掉，卡顿会缓解不少。

线上实战调参记录

之前有一条业务线日志延迟飙到十几分钟，翻遍了Logstash的运行日志才发现是flush_size设太大了，数据全积在内存里。把参数调到500以后，延迟立刻落到了秒级。还有一个容易忽略的地方是索引命名，一定得带上日期，用logstash-nginx-%{+YYYY.MM.dd}这样的格式，配合ILM生命周期策略自动删掉过期的冷数据，能省出一大块磁盘。平常得盯紧监控面板上pipeline.events.in和out这两个指标的差值，要是差距一直在变大，就说明数据堵在解析管道里了。我建议把JVM堆内存用到超过80%、ES写入拒绝次数突然增加这些都配上告警，别等到业务被拖慢了、甚至系统崩了才想起去看，那就有点晚了。