服务器日志分析工具

凌晨两点，服务Nginx的器日access.log里突然冒出一串“POST /api/v1/order 500”，频率从每分钟3次飙到170次。志分运维老张被电话叫醒，析工第一反应是服务翻日志——但500MB的纯文本，grep都得跑十几秒。器日他骂了一句，志分打开GoAccess，析工三分钟定位到问题：某个上游服务超时导致订单接口雪崩。服务这就是器日日志分析工具存在的意义，不是志分锦上添花，是析工救火用的。

很多人以为日志分析就是服务`tail -f`加`grep`。小规模确实够用。器日我见过一个日活两千的志分博客，作者用`awk`统计PV，写了个shell脚本每天凌晨跑一次，输出到邮件里。这没什么不好。但当日志量突破每天10GB，或者你需要关联分析Nginx、MySQL慢查询、应用异常栈三个来源时，裸命令行就开始捉襟见肘了。`grep`本身不慢，慢的是你反复试错的过程——你得先知道要找什么，才能写出正确的正则。

ELK（Elasticsearch + Logstash + Kibana）是绕不开的选项。Logstash啃日志、Elasticsearch建索引、Kibana画图，一套下来能处理TB级数据。但它的重也是真的。我见过一个团队为了查“昨天下午三点哪个IP访问最多”，在Kibana里点了七次筛选，等了二十秒才出结果。后来他们换成了Loki + Grafana，查询快了不少，代价是放弃了全文检索的灵活性。工具选型从来是权衡，没有银弹。

轻量级方案里，GoAccess值得单独提。它直接解析Nginx/Apache日志，终端里就能出实时面板，HTML报告带柱状图和地图。装完跑一条命令：goaccess access.log -o report.html --log-format=COMBINED，浏览器打开就能看到状态码分布、访客地域、请求耗时。我自己的服务器上常备这个，排查“为什么这个接口突然变慢”时，比翻原始日志快一个数量级。缺点是它只做Web日志，应用层异常它管不了。

应用日志是另一回事。Java的logback、Python的logging、Node的winston，格式五花八门。这时候需要的是结构化——把日志写成JSON，每个字段独立。比如{ "time":"2024-01-15T02:13:07Z","level":"ERROR","service":"order","trace_id":"abc123","msg":"timeout"}。一旦结构化，jq就能当查询引擎用：jq 'select(.level=="ERROR") | .trace_id' app.log。再配合trace_id串起全链路，排查效率翻倍。我见过最离谱的日志格式是纯文本里嵌JSON字符串，解析时得先正则抠出来再二次parse——写这代码的人后来被团队要求请全组喝奶茶。

说个具体案例。某电商大促前压测，订单服务QPS上不去。日志里全是“connection pool exhausted”，但连接池配置明明调大了。后来用pt-query-digest分析MySQL慢查询日志，发现一条SELECT * FROM orders WHERE user_id=? AND status=?没走索引，每次查询扫了80万行。连接池不是不够，是被慢查询占满了。如果没有慢查询日志分析工具，这个问题可能要到线上崩了才被发现。

日志分析工具的选择，本质上取决于三个问题：日志量多大、你要查什么、团队里谁用。运维查故障要快，开发调bug要细，安全团队要审计。一个工具很难同时满足。我的习惯是分层：Nginx层用GoAccess看流量，应用层用Loki做聚合，数据库层用pt-query-digest。偶尔需要深度关联时，再上Elasticsearch。别指望一个工具吃所有场景，那只会让每件事都做得别扭。

最后说个容易被忽略的点：日志轮转和保留策略。见过太多服务器因为日志写满磁盘导致服务挂掉。logrotate配置里rotate 7和compress是底线。分析工具再强，日志没了也是白搭。老张那次故障之后，他们团队加了个告警：日志目录使用率超过80%就发钉钉。简单，但管用。