服务器性能监控周期设置：如何拿捏采集频率

公司新上了个电商平台，刚上线那会儿一切正常，结果大促一来，服务器直接卡成幻灯片。事后查日志才发现，监控系统每10分钟才采集一次数据，等告警出来时服务早就崩了。这种事在运维圈里太常见——监控不是没做，而是周期设得太松，等于白搭。

监控周期到底影响什么

简单说，监控周期就是系统每隔多久去“看一眼”CPU、内存、磁盘IO这些关键指标。设成1秒，数据很细但数据库压力大；设成5分钟，资源省了，可万一有个瞬时高峰，比如某个脚本突然把CPU干到95%持续30秒，你根本发现不了。

就像家里的电表，如果只记录每天总用电量，你就没法知道是不是晚上7点开空调导致跳闸。服务器也一样，采样太粗，问题定位就靠猜。

不同场景下的合理周期参考

不是所有服务都得1秒一刷。普通后台管理系统的API接口，平时请求平稳，监控周期设为30秒到1分钟完全够用。但如果是支付网关、订单创建这类核心链路，建议压缩到5秒以内，尤其是大促期间，宁可多存点数据，也不能漏掉异常波动。

数据库服务器更要精细些。MySQL的连接数、慢查询数量这些，建议10秒采集一次。曾经有家公司把这块设成3分钟，结果半夜出现连接池耗尽，等第二天上班才发现，整整丢了两小时的交易数据。

配置示例：Prometheus 中的 job 设置

很多人用 Prometheus 做监控，它的采集周期在 scrape_configs 里控制。比如想让目标服务器每15秒上报一次：

scrape_configs:
  - job_name: 'server-metrics'
    scrape_interval: 15s
    static_configs:
      - targets: ['192.168.1.10:9100']
        labels:
          group: 'web-servers'

这个 scrape_interval 就是关键。如果没单独设，默认会沿用全局 interval。别图省事全用默认值，不同业务节点该分就得分。

别忘了监控本身的负载

一台普通虚拟机跑着几个Java应用，你非要把监控周期压到1秒，采集端和存储端都会吃力。特别是用InfluxDB这类时序库的时候，数据点暴增会让查询变慢，甚至拖垮自身。实测过，从10秒改成1秒，一年下来存储量能差30倍。

所以得权衡。非核心系统可以放宽到30秒，重点服务单独建组，用更短周期。既保住关键路径的可观测性，又不让监控系统自己变成瓶颈。