Linux服务器稳定运行依赖日志与性能监控双轨协同：日志是系统行为“录音笔”，性能指标是实时运转“体检报告”，二者结合实现问题预警、定位与复盘。
Linux 服务器的稳定运行，离不开日志与性能监控的双轨协同。日志是系统行为的“录音笔”，性能指标则是实时运转的“体检报告”。二者结合，才能在问题发生前预警、发生时定位、发生后复盘。
日志管理：从收集到轮转的闭环
关键日志默认集中在 /var/log/ 目录下：系统事件走 /var/log/messages（RHEL/CentOS）或 /var/log/syslog（Debian/Ubuntu），认证日志在 /var/log/secure 或 /var/log/auth.log，服务日志如 Nginx、MySQL 则各自独立存放。
日常排查优先用 journalctl（systemd 系统）：
- journalctl -u nginx.service 查指定服务日志
- journalctl -f 实时追踪最新输出
- journalctl --since "1 hour ago" 快速回溯异常时段
第三方应用日志常被忽略——若其日志路径不在 /var/log/ 下（如 /opt/app/logs/），必须手动添加 logrotate 配置。否则磁盘爆满不是“会不会”，而是“什么时候”。配置中务必启用 compress、rotate 30 和 postrotate 重载信号，避免日志截断后进程继续写入旧文件。
CPU 与内存：看懂核心指标的真实含义
别只盯着 top 的 %CPU 排序。先执行 uptime 看负载均值，再对照 CPU 核心数判断是否超载（例如 8 核机器负载持续 > 12，已存在压力）。接着用 vmstat 1 观察 cs（上下文切换）和 sy（内核态占比）：若 cs 超 5 万/秒且 sy 占比 > 30%，大概率是锁竞争或中断风暴，而非单纯计算密集。
内存方面，free -h 中的 available 才是真实可用量。若该值长期低于总内存的 5%，即使 buff/cache 占比很高，也说明缓存无法有效回收——此时应检查是否有内存泄漏进程，或使用 slabtop 观察 dentry、inode_cache 是否异常增长，这类泄漏不会体现在 top 的 RES 列中。
I/O 与网络：识别隐形瓶颈
磁盘瓶颈常被误判为 CPU 问题。用 iostat -x 1 关注三项：
- await > 100ms：单次 I/O 响应延迟过高，可能是机械盘老化或 RAID 卡缓存关闭
- %util 接近 100% 但 r/s + w/s 很低：存在严重排队，需查是否被其他进程或容器抢占带宽
- avgqu-sz 持续 > 2：请求队列积压，配合 iotop 可定位具体进程
网络异常往往始于连接数激增或丢包。用 iftop -P 直接看到哪个 IP+端口占满带宽；用 ss -s 查当前 socket 总数与状态分布（尤其关注 TIME-WAIT 是否堆积）；若怀疑 DNS 或路由问题，mtr 比 ping 更能定位中间节点延迟。
自动化与告警：让监控真正落地
人工巡检注定遗漏细节。建议组合使用：
- 基础层：sysstat（含 sar）定时采集历史数据，保留 7–30 天供回溯
- 实时层：prometheus + node_exporter 抓取指标，搭配 alertmanager 设置阈值告警（如 swap 使用率 > 20%、load1 > CPU 核数 × 1.5）
- 可视化层：Grafana 集成多数据源，一个面板同时展示 CPU、内存、磁盘延迟与对应服务日志关键词匹配结果
所有告警必须附带可操作指引——例如“内存 available ps aux --sort=-%mem | head -10 并附上进程树，而非仅推送“内存不足”。
