日志不是垃圾，是宝藏
很多人觉得日志就是系统自动生成的一堆文本，平时没人看，出了问题才翻出来当考古。其实日常巡检时多瞄两眼日志，能提前发现不少隐患。比如某次公司官网突然变慢，排查了半天网络带宽和服务器负载都没事，最后在Nginx的访问日志里发现某个IP在疯狂刷接口，平均每秒30多次，明显是恶意爬虫。封掉IP后网站立马恢复正常。
这种事不是偶然。系统每天产生的日志量动辄几十万行，靠人工一行行翻不现实，但完全不管又容易踩坑。关键是怎么把日志用起来。
先搞清楚有哪些日志在说话
常见的日志来源有几个：操作系统（比如Linux的/var/log/messages）、Web服务器（Apache、Nginx的access.log和error.log）、数据库（MySQL慢查询日志）、防火墙和交换机设备日志。每种日志格式不一样，内容侧重点也不同。
比如Nginx的访问日志默认是这样的：
192.168.1.100 - - [15/Apr/2024:10:23:45 +0800] "GET /api/user?id=123 HTTP/1.1" 200 1024 "-" "Mozilla/5.0"这里面包含了客户端IP、请求时间、接口路径、响应码、返回大小等信息。如果看到大量404或500状态码，说明应用层面可能有问题；某个IP频繁出现且请求路径异常，可能是扫描行为。
用工具把日志串起来看
单台服务器还能手动查，规模一大就得靠工具。ELK（Elasticsearch + Logstash + Kibana）是目前比较主流的方案。Logstash负责收集和解析日志，Elasticsearch做存储和检索，Kibana用来画图看趋势。
举个实际例子：公司有20台应用服务器，每天晚上8点总有几台CPU冲到90%以上。通过Kibana把所有机器的系统日志和应用日志聚合展示，发现那段时间某个定时任务的日志里频繁出现数据库连接超时。顺着这条线索查下去，原来是DB连接池配置太小，高峰期不够用，导致请求堆积。调大连接数后问题消失。
写几个实用的日志分析命令
就算没上ELK，Linux命令行也能快速定位问题。下面这些命令在日常排查中很常用：
tail -f /var/log/nginx/access.log | grep "500"实时查看Nginx错误响应。
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -10统计访问最频繁的IP，找潜在攻击源。
grep "Failed password" /var/log/secure | awk '{print $11}' | sort | uniq -c查看SSH暴力破解尝试最多的IP地址。
别只盯着技术字段，业务逻辑也要懂
有一次收到告警说API错误率上升，查日志发现大量400错误，请求路径都指向一个叫/send-sms的接口。进一步看参数，发现传过来的手机号格式不对，全是11位数字但开头是“00”。后来问了开发才知道，最近上线了国际短信功能，前端没做校验，用户填了带前缀的号码直接发过来了。问题不在运维侧，但在日志里能最早发现。
所以看日志不能光认状态码和IP，得知道每个接口是干啥的，什么样的数据算正常。运维和开发之间得多聊几句，不然容易误判。
建立自己的日志检查清单
建议每周抽半小时做个日志快查：Nginx错误日志有没有突增？数据库慢查询有没有超过1秒的？安全日志里有没有异常登录尝试？把这些检查项列成表格，每次打钩，时间长了能看出变化趋势。别等到出事才翻日志，那时候已经晚了。