API接口日志收集与分析：ELK方案落地实践

线上接口报了个500错误，用户说“就是打不开“，你打开服务器日志一看，几十万行文本堆在那儿，grep翻半天也没找到那条报错——这场景太常见了。日志有了不会用，等于没有。ELK就是解决“日志有了但找不到“这个问题的一套方案。

日志格式：结构化是第一步

ELK能不能用好，50%取决于日志格式。传统的文本日志可读性差、解析困难。正确做法是输出JSON格式日志，每条日志包含：时间戳、日志级别、接口路径、请求ID、耗时毫秒、客户端IP、错误信息等字段。请求ID是串联一次请求所有日志的关键——在网关层生成唯一request_id，通过HTTP Header传递到下游所有服务，这样在Kibana里搜一个request_id就能看到完整的调用链。Java用Logback加JSON编码器，PHP用Monolog的JsonFormatter，Node.js用winston的json格式，配置都不复杂。

采集链路搭建

ELK的完整链路是：应用产出日志→Filebeat采集→Logstash过滤→Elasticsearch存储→Kibana展示。Filebeat部署在应用服务器上，监控日志文件变化，实时读取并发送到Logstash。Logstash做日志解析和字段清洗，比如把嵌套的JSON字段拍平、过滤掉debug级别日志、添加环境标签。Elasticsearch负责存储和检索，Kibana负责查询和可视化。如果日志量不大（每天1GB以内），Logstash可以省掉，Filebeat直接写Elasticsearch，减少一层依赖。Elasticsearch的索引按天建，命名格式api-log-2024.07.17，方便按时间范围检索和清理过期数据。

Kibana分析实战

日志进了Kibana怎么用？三个高频场景：第一，排查具体错误——在Discover里按日志级别error过滤，加上时间范围和接口路径，几秒就能定位到报错详情。第二，分析接口性能——在Dashboard里建一个按接口路径分组的P95耗时图表，一眼看出哪个接口最慢。第三，发现异常模式——用Kibana的Lens功能看错误率趋势，突然飙升的时间段往往对应某次发布或流量突增。一个实用技巧：把HTTP状态码做成饼图放Dashboard顶部，4xx和5xx的占比一目了然。如果5xx占比突然升高，那就是出事了，直接点进去看明细。

日志成本控制

ELK最大的问题是吃资源，Elasticsearch集群越撑越大。控制成本的三个办法：一是设日志保留期，生产环境保留30天，历史日志归档到对象存储；二是降低存储频率，info级别日志采样存储，只保留error和warn的完整日志；三是用热温冷架构，近期数据放SSD（热节点），7天前的数据迁移到机械硬盘（温节点），查询性能不差但成本省一半。日志不是存了就完事，能查到、能分析才是目的。