linux服务器监控运维的核心是日志与性能指标协同分析：日志提供行为上下文，指标反映实时状态，二者联动才能精准预警、定位与复盘问题。
Linux服务器监控运维的核心，是把日志和指标这两类信息拧在一起看——光看CPU飙升但没日志佐证，容易误判；只查错误日志却忽略IO延迟，可能错过根源。真正有效的监控，是让指标变化能触发日志上下文，也让日志关键词能反向验证指标异常。
日志监控：从收集到关键线索提取
日志不是堆在/var/log里就完事，得让它“可查、可筛、可联动”。系统日志（/var/log/messages）、服务日志（如Nginx access/error.log、MySQL slow.log）和应用日志需分类管理。
- 用 rsyslog 或 journald 统一收集系统级日志，避免分散丢失；对关键服务启用 logrotate 防止单个日志文件撑爆磁盘（比如每周轮转+压缩+保留4周）
- 高频排查时别翻大文件，用 grep + awk + sed 快速定位：例如
grep -i "oom\|killed process" /var/log/messages | tail -20查OOM记录；awk '$9 ~ /50[0-9]/ {print $1,$2,$7,$9}' /var/log/nginx/access.log | sort | uniq -c | sort -nr找高频5xx来源 - 把日志关键词和指标挂钩：比如发现
nginx error.log中连续出现 “connect() failed (111: Connection refused)” ，立刻检查对应后端服务的 进程是否存在、端口是否监听、CPU/内存是否耗尽
CPU与负载：不只是百分比数字
CPU使用率高≠一定有问题，得拆开看“谁在用”“怎么用”。top 显示的是瞬时快照，而 load average（/proc/loadavg）反映的是过去1/5/15分钟的平均等待队列长度。
- 用 mpstat -P ALL 1 看每个核心的实时使用，识别是否单核打满而其他空闲（典型线程绑定或亲和性问题）
- 当 %sy（系统态）持续 >25%，重点查内核调用：运行
perf top -g -n 10看 top 函数，常见于频繁 write()/read()、大量软中断（net_rx）或锁竞争 - load 值参考标准：若为4核机器，load 1-min 持续 >4 表示有任务在排队；但若 top 中 %id 很高而 load 却高，大概率是不可中断睡眠态（D状态）进程卡住，用
ps aux | grep " D "定位
内存与交换：available 才是真实水位线
free 命令里的 free 字段常误导人——Linux会把空闲内存用于 cache/buffers，这部分随时可回收。真正该盯的是 available 列（内核估算的可立即分配内存）。
- 当 available swapon --show 查swap使用率，同时
vmstat 1观察 si/so 是否持续非零（换页活跃） - 内存泄漏不总表现为占用增长：用 slabtop 看 dentry/inode 缓存是否异常膨胀（常见于挂载大量小文件目录）；用
cat /proc/meminfo | grep -E "^(SReclaimable|Shmem|AnonPages)"辅助判断共享内存与匿名页占比 - 别轻易执行
echo 3 > /proc/sys/vm/drop_caches——它清缓存但不解决根本问题，且会引发后续读取变慢；生产环境仅用于临时排除缓存干扰
磁盘与网络：IO延迟比吞吐量更致命
iostat 显示的 kB_read/s 可能很高，但若 await（平均IO响应时间）持续 >50ms（SSD）或 >15ms（NVMe），说明设备已成瓶颈，哪怕吞吐未满。
- 用 iostat -x 1 关注三项： %util（设备忙时占比，>90%即饱和）、await（延迟）、r_await/w_await（读写分别延迟）。若 %util 低但 await 高，可能是队列深度不足或存储层问题
- 网络方面，iftop -P 按端口排序，快速识别哪个服务占带宽；ss -tulnp 查监听端口及对应进程，结合
cat /proc/net/snmp看 TCP RetransSegs（重传段数），突增往往意味着丢包或拥塞 - 磁盘空间预警不能只靠 df -h：用
find /var/log -name "*.log" -mtime +30 -size +100M -delete自动清理陈旧大日志；对数据库目录等关键路径，单独监控 inodes 使用率（df -i），避免小文件塞满inode导致写失败
