运维排障时，志分最磨人的析工不是服务宕机，而是志分用户报障后你盯着屏幕无从下手。Nginx日志就是析工那本最诚实的账本，可多数人只会在出错时翻两页，志分平时任它堆成垃圾山。析工真正的志分高手早把日志分析玩成了日常巡检，因为那里藏着用户行为的析工矿脉，也埋着攻击者的志分脚印。

我见过最典型的析工案例：某电商平台大促前夜，监控显示API响应突然飙到3秒。志分开发急得查代码、析工调缓存，志分折腾两小时无果。析工最后翻Nginx的志分access.log，发现某个商品详情页的请求量在十分钟内暴涨40倍，清一色来自同一个C段IP。这不是高并发，是爬虫在薅数据。改个Nginx规则限流，响应立刻回到200毫秒。要是早点做日志分析，根本不用惊动整个技术部。

日志分析的入门姿势，先别急着上ELK那套重型武器。命令行三件套就能解决八成问题：awk统计状态码分布，grep抓特定URL，sort加uniq看TOP IP。比如排查502，直接grep ' 502 ' access.log | awk '{ print $1}' | sort | uniq -c | sort -rn | head，哪个IP在疯狂触发错误一目了然。这比开Kibana看半天仪表盘快得多。

真正要留心的不是平均响应时间，而是P99延迟。平均值会骗人——100个请求里99个跑10毫秒，一个卡了3秒，平均值也就40毫秒，表面光鲜。但那个慢请求可能来自你的核心用户。用awk '{ print $NF}' access.log | sort -n | awk 'BEGIN{ i=0} { s[i++]=$1} END{ print s[int(i*0.99)]}'算出P99值，超过500毫秒就得查慢日志了。我习惯把P99阈值写在监控告警里，比单纯盯CPU内存靠谱得多。

日志分析还有个冷门用处：反推业务异常。有次发现某个接口的404突然增多，查了代码没改动，最后看日志发现是用户端App版本太老，请求路径拼错了。这哪是服务器问题，分明是产品没做兼容性提示。Nginx日志这时候成了用户行为调研的替代品，比埋点统计还真实——毕竟埋点可能漏，但每个HTTP请求都逃不过access.log。

别把日志当成事后诸葛亮的工具。我每周五下午会花半小时把本周日志拉下来跑一遍脚本，看哪些URL的流量在涨，哪些错误码出现了新面孔。上周发现某个下载接口的流量涨了20%，点进去看发现是个合作方在盗链。加个referer校验，对方立刻歇菜。这种防御性分析做久了，你会发现大部分事故都有前兆，只是你之前没看日志而已。

工具选型上，单机日志用goaccess生成实时HTML报告最省事，一条命令goaccess access.log -o report.html --real-time-html就能在浏览器里看到动态刷新。日志量上了每日几个GB，再考虑Filebeat加Elasticsearch。但记住，工具越复杂，维护成本越高，别为了炫技把日志分析搞成另一个需要排障的系统。我见过小团队硬上Kafka加Spark的，最后没人会调优，数据全积压在队列里，还不如老老实实写个cron跑awk脚本。

最后提醒一句：日志要定期轮转和压缩，别等磁盘满了再哭。我习惯用logrotate按天切割，保留30天，超过的自动删。但压缩前的原始日志别急着清，至少留三个月——等哪天线上出问题，你可能会需要回溯一个早已遗忘的请求参数。那会儿你会感谢当初多存了这几十GB的“垃圾”。