服务器监控代码太占资源怎么办？|3行Python脚本实时监控服务器状态

构建系统健康的基石

服务器监控代码是运维工程师和技术团队的眼睛和耳朵,它持续收集关键性能指标，实时洞察系统状态，提前预警潜在风险，保障业务稳定运行，其核心价值在于将无形的服务器负载、资源消耗转化为可量化、可分析、可告警的数据流，为性能优化、容量规划和故障排查提供坚实依据。

加载中

Jmeter监视服务器CPU等资源使用率（PerfMon插件）

乔治的杰克船长

1.1万1413

原视频地址

核心监控项与关键指标

任何有效的监控体系都始于对基础资源状态的持续追踪：

1. CPU 使用率：

   • 监控点： 用户态 (user)、系统态 (sys)、空闲 (idle)、等待 I/O (iowait)、软硬中断 (irq, softirq)、虚拟化开销 (steal)。
   • 关键指标： 整体使用率 (%util)、各核心负载均衡、iowait 过高（可能预示磁盘瓶颈）、steal 过高（云服务器资源争抢）。

2. 内存使用：

   • 监控点： 总内存 (total)、已用内存 (used)、空闲内存 (free)、缓存 (cache)、缓冲区 (buffers)、交换空间 (swap)。
   • 关键指标： 实际可用内存 (free + buffers + cache)、Swap 使用率/换入换出速率 (si/so，过高是严重警告)、OOM Killer 触发记录。

3. 磁盘 I/O：

   • 监控点： 读写吞吐量 (r/s, w/s)、读写带宽 (rkB/s, wkB/s)、平均 I/O 等待时间 (await)、平均队列深度 (aqu-sz)、磁盘利用率 (%util)。
   • 关键指标： %util 接近 100% 表示磁盘饱和，await 过高表示 I/O 响应慢，需结合队列深度分析。

4. 磁盘空间：

   • 监控点： 文件系统挂载点、总容量 (size)、已用空间 (used)、可用空间 (avail)、使用率 (use%)、Inode 使用率 (iused%)。
   • 关键指标： 使用率阈值告警（如 80% 警告，90% 严重）、Inode 耗尽同样导致写入失败。

5. 网络流量：

   

   • 监控点： 网络接口 (eth0, eth1, bond0)、接收/发送字节数 (rx_bytes/s, tx_bytes/s)、接收/发送包数 (rx_packets/s, tx_packets/s)、错误包/丢包 (errs, drop)。
   • 关键指标： 带宽利用率、错误/丢包率（网络故障或过载）、关键端口连接状态。

6. 进程与服务：

   • 监控点： 关键进程存活状态 (Nginx, MySQL, Redis, Tomcat)、进程数量、进程资源占用 (CPU, MEM)、端口监听状态。
   • 关键指标： 进程是否运行、端口是否在监听、资源占用是否异常飙升。

主流开源监控工具：集成与应用

成熟的监控工具提供了数据采集、存储、可视化、告警的一站式解决方案：

1. Prometheus + Grafana + Node Exporter (PGN 黄金组合):

   • Node Exporter: 部署在目标服务器上，暴露标准的系统指标 (/metrics 端点)。
   • Prometheus: 定时拉取 (pull) Node Exporter 和其他 exporter (如 mysqld_exporter, nginx_exporter) 的数据，存储在高效的时间序列数据库中，提供强大的查询语言 PromQL。
   • Grafana: 连接 Prometheus 数据源，创建丰富、直观的仪表盘 (Dashboards)。
   • 优势: 云原生设计、高度灵活、强大的查询和聚合能力、活跃社区。
   • 代码片段 (Prometheus 配置 scrape_configs):

     scrape_configs:
       - job_name: 'node'
         static_configs:
           - targets: ['server1:9100', 'server2:9100'] # Node Exporter 默认端口 9100
       - job_name: 'mysql'
         static_configs:
           - targets: ['dbserver:9104'] # mysqld_exporter 端口示例

2. Zabbix:

   • 全能型选手： 提供 Agent（主动/被动模式）、SNMP、IPMI、JMX 等多种数据采集方式，内置强大的告警引擎、模板机制和 Web 界面。
   • 优势： 开箱即用、功能全面（自动发现、分布式监控）、企业级支持成熟。
   • 代码逻辑 (Zabbix Agent UserParameter 自定义监控项):

     # /etc/zabbix/zabbix_agentd.d/custom_nginx.conf
     UserParameter=nginx.active_connections, curl -s http://localhost/nginx_status | grep 'Active connections' | awk '{print $3}'

3. Telegraf + InfluxDB + Grafana (TIG 组合):

   • Telegraf: 轻量级插件化数据采集器，支持海量输入 (inputs) 和输出 (outputs) 插件。
   • InfluxDB: 高性能时间序列数据库，专为监控数据设计。
   • Grafana: 可视化展示。
   • 优势： 部署轻量、插件生态丰富、写入性能优异。

自定义监控脚本开发：精准满足特定需求

当标准工具无法覆盖特定场景时,编写脚本是必要补充：

1. Shell 脚本示例：监控关键服务端口

   #!/bin/bash
   SERVICE="nginx"
   PORT=80
   # 检查端口监听
   if ! netstat -tuln | grep ":$PORT " > /dev/null; then
       echo "CRITICAL: $SERVICE service on port $PORT is DOWN!" | mail -s "Service Alert: $SERVICE DOWN" admin@example.com
       # 或者调用企业微信/钉钉/Slack Webhook
       # curl -s 'https://qyapi.weixin.qq.com/...' -d '{"msgtype": "text", "text": {"content": "CRITICAL: ..."}}'
       exit 1
   else
       echo "OK: $SERVICE service on port $PORT is UP."
       exit 0
   fi

2. Python 脚本示例：监控 Nginx 活动连接数 (使用 Prometheus Client 库)

   #!/usr/bin/env python3
   from prometheus_client import start_http_server, Gauge
   import requests
   import time
   # 创建 Prometheus Gauge 指标
   NGINX_ACTIVE_CONNECTIONS = Gauge('nginx_active_connections', 'Current active client connections')
   def fetch_nginx_status():
       try:
           response = requests.get('http://localhost/nginx_status')
           if response.status_code == 200:
               for line in response.text.splitlines():
                   if line.startswith('Active connections:'):
                       active_conns = int(line.split(':')[1].strip())
                       NGINX_ACTIVE_CONNECTIONS.set(active_conns)
       except Exception as e:
           print(f"Error fetching Nginx status: {e}")
   if __name__ == '__main__':
       # 在 9101 端口启动 HTTP 服务暴露指标
       start_http_server(9101)
       while True:
           fetch_nginx_status()
           time.sleep(15)  # 每 15 秒采集一次

   • 将此脚本作为服务运行,Prometheus 配置拉取 server:9101/metrics。

监控体系构建的最佳实践

1. 定义清晰的监控目标与 SLO/SLA： 监控服务于业务目标，明确核心服务的可用性、延迟、吞吐量目标（SLO），据此确定关键监控项和告警阈值。
2. 分层监控：
   • 基础设施层： CPU, MEM, Disk, Network。
   • 平台/中间件层： Web 服务器、数据库、缓存、消息队列。
   • 应用层： 应用日志、关键事务链路、API 响应时间/错误率、用户体验（RUM）。
   • 业务层： 核心业务指标（订单量、支付成功率、用户活跃度）。
3. 告警的“三高三低”原则：
   • 高准确性： 告警必须真实反映问题，避免“狼来了”。
   • 高时效性： 问题发生后尽快告警。
   • 高可操作性： 告警信息清晰指出问题位置、原因、影响范围、初步处理建议。
   • 低噪音： 避免无效、重复告警干扰。
   • 低遗漏： 确保关键故障能被捕获。
   • 低延迟： 告警传递渠道畅通无阻。
4. 阈值设定智能化：
   • 避免静态阈值,采用基线告警（如：当前值偏离历史同周期均值 3 个标准差）。
   • 预测告警（基于时序预测模型）。
5. 告警分级与通知路由：
   • 等级划分： 紧急 (P0)、高 (P1)、中 (P2)、低 (P3)/提示。
   • 智能路由： 根据等级、时间段、值班表、业务域，将告警精准路由到对应负责人（邮件、短信、电话、IM 机器人）。
6. 仪表盘聚焦核心 KPI：
   • 为不同角色（运维、开发、产品、管理层）定制仪表盘。
   • 突出显示最关键的健康指标（Golden Signals: 流量、错误、延迟、饱和度）。
   • 关联展示：将基础设施指标与应用性能指标关联展示，便于根因分析。
7. 日志与指标的联动： 当指标告警触发时，能快速关联查询对应时间点的系统日志、应用日志，加速问题定位。
8. 定期评审与优化：
   • 回顾告警历史：哪些告警被静音了？哪些告警没有触发但发生了故障？哪些告警触发了但无实际影响？
   • 调整阈值、优化告警规则、合并重复告警、下线无用监控项。

从监控到可观测性

优秀的服务器监控代码和体系不仅是故障的“消防员”，更是系统健康的“体检医生”和性能优化的“导航仪”，它超越了简单的指标采集（Monitoring），向更高级的可观测性（Observability）演进通过指标（Metrics）、日志（Logs）、链路追踪（Traces）三大支柱，结合强大的上下文关联能力，让工程师能够深入理解复杂分布式系统的内部状态，主动发现问题、快速定位根因、有效验证变更效果，为业务的稳定性和持续创新提供强大支撑。

您当前服务器监控体系最大的痛点是什么？是告警风暴难以管理？是根因定位效率低下？还是监控覆盖不全存在盲区？ 欢迎在评论区分享您的挑战和经验，共同探讨更优的监控实践！