1. 那些潜伏在Linux系统中的暗坑监控指南作为一枚常年与Linux服务器打交道的运维老兵我见过太多因为忽视系统监控而导致的午夜惊魂。有些问题就像定时炸弹平时风平浪静一旦爆发却能让你彻夜难眠。今天要聊的不是常见的CPU、内存监控而是那些容易被忽略却可能引发雪崩效应的暗坑。2. 文件描述符泄漏看不见的资源黑洞2.1 为什么文件描述符泄漏如此危险每个进程默认的文件描述符限制是1024当应用程序没有正确关闭文件、套接字时这个数字会不断累积。我曾遇到过一个Java应用因为未关闭数据库连接导致整个系统无法创建新进程的案例。查看当前系统限制cat /proc/sys/fs/file-max2.2 监控与排查方案实时监控命令watch -n 5 cat /proc/sys/fs/file-nr输出解析第一个数字已分配文件句柄数第二个数字空闲文件句柄数第三个数字最大文件句柄数当第一个数字接近最大值时系统会开始拒绝新连接。建议设置告警阈值为最大值的80%。经验之谈Nginx这类高并发服务建议单独调整限制在/etc/security/limits.conf中添加www-data hard nofile 65535 www-data soft nofile 655353. inode耗尽磁盘有空间却无法存文件的怪事3.1 inode用尽的典型场景即使磁盘显示还有剩余空间当inode耗尽时系统会报No space left on device错误。常见于小文件极多的场景比如邮件服务器、Docker容器日志等。检查inode使用情况df -i3.2 预防与清理策略查找inode消耗大户find / -xdev -printf %h\n | sort | uniq -c | sort -k 1 -n针对Docker的特别处理# 查看容器日志大小 docker ps -q | xargs docker inspect --format{{.LogPath}} | xargs ls -lh日志轮转配置示例/etc/logrotate.d/docker/var/lib/docker/containers/*/*.log { rotate 7 daily compress delaycompress missingok copytruncate }4. 僵尸进程杀不死的幽灵4.1 识别僵尸进程ps aux | grep Z状态栏显示Z的就是僵尸进程。它们不消耗资源但过多会导致PID耗尽。4.2 处理方案尝试向父进程发送SIGCHLD信号kill -s SIGCHLD [PPID]如果父进程不处理只能杀死父进程kill -9 [PPID]血泪教训曾经有个Crontab脚本因为未正确处理子进程三个月积累了2000僵尸进程导致系统无法创建新任务。5. 内存泄漏的隐蔽形式5.1 Slab内存泄漏cat /proc/meminfo | grep SlabSlab是内核用于缓存数据结构的内存某些驱动或内核模块泄漏时这里会持续增长。5.2 监控方案安装内核调试工具apt-get install linux-tools-common linux-tools-generic监控slab变化watch -n 60 cat /proc/meminfo | grep -E Slab|SReclaimable|SUnreclaim详细分析工具sudo slabtop -o6. 网络连接状态陷阱6.1 TIME_WAIT堆积高并发短连接服务会产生大量TIME_WAIT状态连接占用端口资源netstat -n | awk /^tcp/ {S[$NF]} END {for(a in S) print a, S[a]}优化方案# 修改sysctl.conf net.ipv4.tcp_tw_reuse 1 net.ipv4.tcp_tw_recycle 1 # 在NAT环境下慎用 net.ipv4.tcp_fin_timeout 306.2 孤儿连接监控ss -s关注orphaned计数异常增长可能意味着应用没有正确关闭连接。7. 磁盘I/O性能劣化7.1 容易被忽略的I/O等待iotop -oP%wa超过30%就需要警惕即使CPU使用率看起来正常。7.2 深入分析工具安装perf工具apt-get install linux-tools-common linux-tools-generic跟踪磁盘I/Operf record -e block:block_rq_issue -a sleep 10 perf script8. 系统时钟漂移分布式系统的隐形杀手8.1 监控时钟偏差ntpq -pnoffset列显示时钟偏差超过100ms就需要干预。8.2 最佳实践使用chrony替代ntpdapt-get install chrony配置多个时间源server ntp.aliyun.com iburst server ntp1.tencent.com iburst强制同步命令chronyc makestep9. 内核OOM机制的坑9.1 理解OOM Killer行为查看最近OOM事件dmesg | grep -i killed process调整进程oom_scoreecho -1000 /proc/[pid]/oom_score_adj9.2 内存不足的早期预警grep -i oom /var/log/kern.log建议监控/proc/meminfo中的CommitLimit和Committed_ASvmstat 1输出中的si/so交换区活动10. 完整的监控方案实现10.1 Prometheus监控配置示例- job_name: linux_advanced static_configs: - targets: [localhost:9100] params: collect[]: - diskstats - filefd - netstat - stat - textfile10.2 自定义指标收集创建指标收集脚本/etc/node_exporter/custom_metrics.sh#!/bin/bash echo # HELP inode_usage Inodes usage percentage echo # TYPE inode_usage gauge df -i | awk /\/$/ {print inode_usage 100-$5} /var/lib/node_exporter/inode_usage.prom设置crontab定时任务* * * * * /etc/node_exporter/custom_metrics.sh11. 经验总结与避坑指南文件描述符泄漏排查四部曲lsof -p [PID]查看进程打开的文件/proc/[PID]/fd目录分析strace跟踪文件操作代码审查close()调用inode问题预防措施为/var等可能产生大量小文件的目录单独分区日志系统必须配置轮转定期清理/tmp目录内存监控的黄金指标可用内存 MemFree Cached Buffers关注vmstat中的si/so交换活动定期检查slabtop输出网络连接状态监控要点建立连接数基线监控非常用状态CLOSE_WAIT、FIN_WAIT2结合应用日志分析异常模式磁盘I/O问题排查路线graph TD A[发现性能下降] -- B[iostat -x 1] B -- C{awaitms?} C --|是| D[检查具体进程iotop] C --|否| E[检查文件系统ext4?xfs?]最后分享一个真实案例某电商大促期间数据库突然无法连接。最终发现是某服务文件描述符泄漏而监控只关注了CPU和内存。从此我们建立了全维度监控体系这些暗坑指标都会触发值班电话。记住好的系统监控不仅要看表面指标更要关注那些不常见但致命的细节。
1. 那些潜伏在Linux系统中的暗坑监控指南作为一枚常年与Linux服务器打交道的运维老兵我见过太多因为忽视系统监控而导致的午夜惊魂。有些问题就像定时炸弹平时风平浪静一旦爆发却能让你彻夜难眠。今天要聊的不是常见的CPU、内存监控而是那些容易被忽略却可能引发雪崩效应的暗坑。2. 文件描述符泄漏看不见的资源黑洞2.1 为什么文件描述符泄漏如此危险每个进程默认的文件描述符限制是1024当应用程序没有正确关闭文件、套接字时这个数字会不断累积。我曾遇到过一个Java应用因为未关闭数据库连接导致整个系统无法创建新进程的案例。查看当前系统限制cat /proc/sys/fs/file-max2.2 监控与排查方案实时监控命令watch -n 5 cat /proc/sys/fs/file-nr输出解析第一个数字已分配文件句柄数第二个数字空闲文件句柄数第三个数字最大文件句柄数当第一个数字接近最大值时系统会开始拒绝新连接。建议设置告警阈值为最大值的80%。经验之谈Nginx这类高并发服务建议单独调整限制在/etc/security/limits.conf中添加www-data hard nofile 65535 www-data soft nofile 655353. inode耗尽磁盘有空间却无法存文件的怪事3.1 inode用尽的典型场景即使磁盘显示还有剩余空间当inode耗尽时系统会报No space left on device错误。常见于小文件极多的场景比如邮件服务器、Docker容器日志等。检查inode使用情况df -i3.2 预防与清理策略查找inode消耗大户find / -xdev -printf %h\n | sort | uniq -c | sort -k 1 -n针对Docker的特别处理# 查看容器日志大小 docker ps -q | xargs docker inspect --format{{.LogPath}} | xargs ls -lh日志轮转配置示例/etc/logrotate.d/docker/var/lib/docker/containers/*/*.log { rotate 7 daily compress delaycompress missingok copytruncate }4. 僵尸进程杀不死的幽灵4.1 识别僵尸进程ps aux | grep Z状态栏显示Z的就是僵尸进程。它们不消耗资源但过多会导致PID耗尽。4.2 处理方案尝试向父进程发送SIGCHLD信号kill -s SIGCHLD [PPID]如果父进程不处理只能杀死父进程kill -9 [PPID]血泪教训曾经有个Crontab脚本因为未正确处理子进程三个月积累了2000僵尸进程导致系统无法创建新任务。5. 内存泄漏的隐蔽形式5.1 Slab内存泄漏cat /proc/meminfo | grep SlabSlab是内核用于缓存数据结构的内存某些驱动或内核模块泄漏时这里会持续增长。5.2 监控方案安装内核调试工具apt-get install linux-tools-common linux-tools-generic监控slab变化watch -n 60 cat /proc/meminfo | grep -E Slab|SReclaimable|SUnreclaim详细分析工具sudo slabtop -o6. 网络连接状态陷阱6.1 TIME_WAIT堆积高并发短连接服务会产生大量TIME_WAIT状态连接占用端口资源netstat -n | awk /^tcp/ {S[$NF]} END {for(a in S) print a, S[a]}优化方案# 修改sysctl.conf net.ipv4.tcp_tw_reuse 1 net.ipv4.tcp_tw_recycle 1 # 在NAT环境下慎用 net.ipv4.tcp_fin_timeout 306.2 孤儿连接监控ss -s关注orphaned计数异常增长可能意味着应用没有正确关闭连接。7. 磁盘I/O性能劣化7.1 容易被忽略的I/O等待iotop -oP%wa超过30%就需要警惕即使CPU使用率看起来正常。7.2 深入分析工具安装perf工具apt-get install linux-tools-common linux-tools-generic跟踪磁盘I/Operf record -e block:block_rq_issue -a sleep 10 perf script8. 系统时钟漂移分布式系统的隐形杀手8.1 监控时钟偏差ntpq -pnoffset列显示时钟偏差超过100ms就需要干预。8.2 最佳实践使用chrony替代ntpdapt-get install chrony配置多个时间源server ntp.aliyun.com iburst server ntp1.tencent.com iburst强制同步命令chronyc makestep9. 内核OOM机制的坑9.1 理解OOM Killer行为查看最近OOM事件dmesg | grep -i killed process调整进程oom_scoreecho -1000 /proc/[pid]/oom_score_adj9.2 内存不足的早期预警grep -i oom /var/log/kern.log建议监控/proc/meminfo中的CommitLimit和Committed_ASvmstat 1输出中的si/so交换区活动10. 完整的监控方案实现10.1 Prometheus监控配置示例- job_name: linux_advanced static_configs: - targets: [localhost:9100] params: collect[]: - diskstats - filefd - netstat - stat - textfile10.2 自定义指标收集创建指标收集脚本/etc/node_exporter/custom_metrics.sh#!/bin/bash echo # HELP inode_usage Inodes usage percentage echo # TYPE inode_usage gauge df -i | awk /\/$/ {print inode_usage 100-$5} /var/lib/node_exporter/inode_usage.prom设置crontab定时任务* * * * * /etc/node_exporter/custom_metrics.sh11. 经验总结与避坑指南文件描述符泄漏排查四部曲lsof -p [PID]查看进程打开的文件/proc/[PID]/fd目录分析strace跟踪文件操作代码审查close()调用inode问题预防措施为/var等可能产生大量小文件的目录单独分区日志系统必须配置轮转定期清理/tmp目录内存监控的黄金指标可用内存 MemFree Cached Buffers关注vmstat中的si/so交换活动定期检查slabtop输出网络连接状态监控要点建立连接数基线监控非常用状态CLOSE_WAIT、FIN_WAIT2结合应用日志分析异常模式磁盘I/O问题排查路线graph TD A[发现性能下降] -- B[iostat -x 1] B -- C{awaitms?} C --|是| D[检查具体进程iotop] C --|否| E[检查文件系统ext4?xfs?]最后分享一个真实案例某电商大促期间数据库突然无法连接。最终发现是某服务文件描述符泄漏而监控只关注了CPU和内存。从此我们建立了全维度监控体系这些暗坑指标都会触发值班电话。记住好的系统监控不仅要看表面指标更要关注那些不常见但致命的细节。
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
