1. Linux服务器健康监控概述作为运维工程师我们每天都要面对数十甚至上百台Linux服务器的运行状态监控。记得去年我们一个核心业务服务器突然负载飙升到50整个业务几乎瘫痪排查后发现是某个日志文件疯狂增长占满了磁盘空间。这件事让我深刻意识到没有完善的监控体系就像在黑暗中开车——迟早要出事故。服务器健康监控不仅仅是简单的看仪表盘而是要从CPU、内存、磁盘、网络、进程等多个维度建立立体化的监控体系。一个成熟的监控方案应该具备以下核心能力实时性能秒级发现异常比如CPU使用率瞬间冲高全面性覆盖硬件、系统、应用所有层面预警性在问题发生前就能发现趋势异常追溯性可以回放历史数据辅助排查2. 核心监控指标详解2.1 CPU监控的艺术CPU使用率是最容易被误读的指标。很多人看到CPU使用率90%就慌其实要看具体场景# 查看CPU核心数和型号 lscpu # 实时CPU使用率1秒刷新 mpstat -P ALL 1 # 查看CPU运行队列 sar -q 1 3关键指标解读us%用户态CPU时间。如果长期70%说明应用计算密集sy%内核态CPU时间。正常应20%过高可能系统调用频繁id%空闲时间。低于30%就需要警惕wa%IO等待时间。30%说明磁盘IO是瓶颈经验多核CPU要看单核负载使用uptime查看1/5/15分钟平均负载理想值是核心数×0.72.2 内存监控的陷阱free命令的输出经常让人困惑free -h total used free shared buff/cache available Mem: 62G 7.2G 512M 1.3G 54G 53G Swap: 4.0G 1.2G 2.8G重点看available而非freeLinux会主动利用空闲内存做缓存(buff/cache)这部分内存应用需要时可以立即释放。内存泄漏排查技巧# 按内存使用排序进程 ps aux --sort-%mem | head # 监控slab内存 cat /proc/meminfo | grep Slab # 追踪内存分配 valgrind --toolmemcheck --leak-checkfull ./your_app2.3 磁盘IO的隐藏杀手磁盘问题往往最容易被忽视直到出现故障。推荐监控工具# 查看磁盘空间使用 df -Th # 监控磁盘IO每秒刷新 iostat -xmdz 1 # 查找大文件 find / -type f -size 500M -exec ls -lh {} \;关键指标%util设备繁忙百分比。80%说明IO饱和awaitIO平均等待时间(ms)。20ms需要关注svctmIO服务时间。应该5ms血泪教训曾经因为一个开发在/tmp下写日志导致根分区爆满。现在我们的监控必加/和/tmp分区报警3. 网络监控进阶技巧3.1 连接数监控TCP连接数突然暴涨往往是故障前兆# 查看各状态连接数 ss -s # 监控ESTABLISHED连接 watch -n 1 ss -tn state established | wc -l # 按IP统计连接数 netstat -ntu | awk {print $5} | cut -d: -f1 | sort | uniq -c | sort -n3.2 带宽监控iftop是实时带宽监控神器iftop -nNP # -n 不解析主机名 # -P 显示端口 # -N 数字格式显示长期趋势建议用nloadnload -u M eth0 # 以MB为单位显示eth0流量4. 企业级监控方案实战4.1 Prometheus Grafana方案这是我们目前生产环境的主力监控方案部署Prometheus# 下载 wget https://github.com/prometheus/prometheus/releases/download/v2.47.0/prometheus-2.47.0.linux-amd64.tar.gz tar xvfz prometheus-*.tar.gz cd prometheus-* # 配置 vi prometheus.ymlNode Exporter安装每台服务器wget https://github.com/prometheus/node_exporter/releases/download/v1.6.1/node_exporter-1.6.1.linux-amd64.tar.gz tar xvfz node_exporter-*.tar.gz cd node_exporter-* ./node_exporter Grafana仪表盘配置导入ID为1860的Node Exporter仪表盘设置告警规则示例groups: - name: host_stats rules: - alert: HighCPU expr: 100 - (avg by(instance)(irate(node_cpu_seconds_total{modeidle}[5m])) * 100) 80 for: 5m labels: severity: warning annotations: summary: High CPU usage on {{ $labels.instance }}4.2 日志监控ELK方案对于日志集中监控我们使用# Filebeat配置示例 filebeat.inputs: - type: log paths: - /var/log/*.log output.logstash: hosts: [logstash:5044]Logstash处理管道input { beats { port 5044 } } filter { grok { match { message %{TIMESTAMP_ISO8601:timestamp} %{LOGLEVEL:loglevel} %{GREEDYDATA:message} } } } output { elasticsearch { hosts [http://elasticsearch:9200] } }5. 自动化运维技巧5.1 监控脚本示例这个脚本检查关键指标并发送报警#!/bin/bash # 阈值配置 CPU_WARN80 MEM_WARN90 DISK_WARN90 # 检查CPU cpu_usage$(top -bn1 | grep Cpu(s) | sed s/.*, *\([0-9.]*\)%* id.*/\1/ | awk {print 100 - $1}) if (( $(echo $cpu_usage $CPU_WARN | bc -l) )); then echo CPU报警: 使用率 ${cpu_usage}% | mail -s CPU告警 adminexample.com fi # 检查内存 mem_usage$(free | grep Mem | awk {print $3/$2 * 100.0}) if (( $(echo $mem_usage $MEM_WARN | bc -l) )); then echo 内存报警: 使用率 ${mem_usage}% | mail -s 内存告警 adminexample.com fi # 检查磁盘 df -P | grep -v ^Filesystem | awk { print $5 $1 } | while read output; do usage$(echo $output | awk { print $1} | cut -d% -f1 ) partition$(echo $output | awk { print $2 } ) if [ $usage -ge $DISK_WARN ]; then echo 磁盘报警: 分区 $partition 使用率 ${usage}% | mail -s 磁盘告警 adminexample.com fi done5.2 定时任务配置建议将监控脚本加入crontab# 每5分钟运行监控 */5 * * * * /path/to/monitor_script.sh # 每天凌晨清理日志 0 0 * * * find /var/log -type f -name *.log -mtime 7 -delete6. 性能优化实战案例6.1 MySQL性能调优我们某次优化案例-- 慢查询分析 mysqldumpslow -s t /var/log/mysql/mysql-slow.log -- 优化后配置(my.cnf) [mysqld] innodb_buffer_pool_size 12G # 内存的70% innodb_log_file_size 2G innodb_flush_log_at_trx_commit 2 query_cache_type 0 table_open_cache 40006.2 Nginx调优经验高并发场景下的关键参数worker_processes auto; worker_rlimit_nofile 100000; events { worker_connections 4000; use epoll; multi_accept on; } http { open_file_cache max200000 inactive20s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on; sendfile on; tcp_nopush on; tcp_nodelay on; }7. 安全监控要点7.1 登录监控# 查看失败登录 grep Failed password /var/log/auth.log # 监控SSH暴力破解 fail2ban-client status sshd7.2 文件完整性监控使用AIDE建立基线aide --init mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz aide --check8. 容器监控特别篇对于Docker环境# 容器资源使用 docker stats --no-stream # 推荐使用cAdvisor docker run \ --volume/:/rootfs:ro \ --volume/var/run:/var/run:ro \ --volume/sys:/sys:ro \ --volume/var/lib/docker/:/var/lib/docker:ro \ --publish8080:8080 \ --detachtrue \ --namecadvisor \ google/cadvisor:latest9. 报警策略设计合理的报警分级P0电话报警核心业务不可用P1短信报警性能严重下降P2邮件报警潜在风险P3企业微信提示信息报警收敛策略示例def check_alert(metric, threshold, duration): metric: 监控指标 threshold: 阈值 duration: 持续时长(分钟) abnormal_points 0 for _ in range(duration): current_value get_metric(metric) if current_value threshold: abnormal_points 1 else: abnormal_points 0 if abnormal_points 3: # 连续3次超标才报警 send_alert(f{metric} 持续高于 {threshold}) break10. 监控体系演进路线根据业务规模推荐方案初创阶段Shell脚本 crontab 邮件报警成长阶段Prometheus Grafana Alertmanager成熟阶段多集群Thanos 日志中台 智能告警超大规模自研监控平台 AIOps异常检测监控系统建设要遵循够用就好原则避免过度设计。我们曾经花费三个月搭建完美的监控系统结果维护成本比解决的问题还多。现在采用渐进式演进策略每个阶段只解决当前最痛的痛点。