我们香港机房在上个月的一个深夜突发服务抖动之后，我才真正意识到，主机级资源监控并不是“上线之后才补的事”，而是架构稳定性的第一道防线。那次事故中，CPU负载在数分钟内飙升至 90%+，内存也不断逼近 swap，而我们当时只靠简单的 top 和 sar 临时排查，根本来不及溯源。自此，我着手为香港的服务器集群搭建一套主机级资源监控体系：能快速部署、自动采集、图形化展示，还能设置阈值预警并联动告警。
以下就是我从0到1在生产环境中实战落地的全过程。
一、选型方案：Prometheus + Node Exporter + Grafana 的黄金组合
为了兼顾轻量、开源、扩展性和社区支持，我最终选择了以下组合：
| 组件 | 功能 |
|---|---|
| Node Exporter | 采集主机层资源指标 |
| Prometheus | 指标拉取、存储与查询 |
| Grafana | 可视化监控仪表盘 |
| Alertmanager | 阈值告警+告警路由 |
在香港本地部署全部组件，可以避免跨境指标传输带来的时延影响，并实现离线环境的监控闭环。
二、部署步骤详解：从零构建主机监控体系
1. 部署 Node Exporter（资源采集器）
我将 Node Exporter 安装在所有需监控的裸金属与云主机上，版本为 v1.8.0，支持 systemd 管理。
# 下载并解压
wget https://github.com/prometheus/node_exporter/releases/download/v1.8.0/node_exporter-1.8.0.linux-amd64.tar.gz
tar -xzf node_exporter-1.8.0.linux-amd64.tar.gz
cd node_exporter-1.8.0.linux-amd64/
# 注册为 systemd 服务
sudo cp node_exporter /usr/local/bin/
cat <<EOF | sudo tee /etc/systemd/system/node_exporter.service
[Unit]
Description=Node Exporter
After=network.target
[Service]
ExecStart=/usr/local/bin/node_exporter
Restart=on-failure
[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reexec
sudo systemctl enable --now node_exporter
2. 配置 Prometheus 拉取主机指标
在香港的 Prometheus 主节点（我部署在一台独立管理节点）中修改 prometheus.yml：
scrape_configs:
- job_name: 'node'
static_configs:
- targets:
- '192.168.1.101:9100'
- '192.168.1.102:9100'
# 启动 Prometheus
./prometheus --config.file=prometheus.yml
确保 Node Exporter 能从主节点访问，使用浏览器验证 http://<目标IP>:9100/metrics。
3. 安装与配置 Grafana（监控可视化）
Grafana 我同样部署在香港局域网内，避免跨网络访问瓶颈：
# 以 Debian 系为例
sudo apt-get install -y grafana
sudo systemctl enable --now grafana-server
在 Grafana Web 控制台：
- 添加 Prometheus 数据源（URL 指向 http://localhost:9090）
- 导入官方 Node Exporter Dashboards（ID: 1860，CPU/Mem/IO 一应俱全）
4. 配置 Alertmanager + 告警规则
创建告警规则文件：
groups:
- name: node-alerts
rules:
- alert: HighCPUUsage
expr: avg(rate(node_cpu_seconds_total{mode="user"}[1m])) > 0.85
for: 1m
labels:
severity: warning
annotations:
summary: "CPU使用率过高"
并配置 prometheus.yml 启用告警：
alerting:
alertmanagers:
- static_configs:
- targets:
- "localhost:9093"
Alertmanager 可配置 webhook 推送至飞书、企业微信或邮件：
receivers:
- name: 'ops-team'
webhook_configs:
- url: 'https://your-webhook-url'
三、部署优化建议：适配香港服务器环境的小技巧
内网收集 + 公网反代
在部分混合云架构中，我会使用 Nginx 做反向代理，只将 Prometheus 监控地址开放于公网，其余通信均走内网，提升安全性。
location /grafana/ {
proxy_pass http://127.0.0.1:3000/;
auth_basic "Restricted";
}
标签管理：区分机房/业务线
我为每台服务器配置独立标签，在 prometheus.yml 中这样设置：
- targets: ['192.168.1.101:9100']
labels:
datacenter: 'hk-fo-tel'
role: 'web'
env: 'prod'
Grafana 中即可使用变量筛选具体业务节点。
数据持久化与分片
为防止 Prometheus 单节点因数据膨胀而崩溃，我按以下方式优化：
- 持久化目录挂载高 IOPS NVMe
- 使用 –storage.tsdb.retention.time=15d
- 采用 Thanos 做远程分片备份（支持冷数据归档）
四、运维场景下的典型故障排查
| 场景 | 原因分析 | 排查手段 |
|---|---|---|
| Node Exporter 无数据 | 防火墙未放通 9100 端口 | telnet、iptables 检查 |
| Grafana 图表无指标 | Prometheus 配置错误或数据源失效 | 检查 prometheus.yml 和数据源连接 |
| 告警未触发或频繁误报 | for 参数过短，表达式偏移 |
使用 Prometheus UI 实时调试表达式 |
五、监控是系统韧性的重要支撑
我们通过在香港服务器本地部署这套 Prometheus + Node Exporter + Grafana 的资源监控体系，实现了对 CPU、内存、磁盘、IO、网络、负载等指标的全面可视化，并借助 Alertmanager 实现了快速故障发现与响应。比起之前“看日志猜瓶颈”的方式，如今只需打开仪表盘，我就能快速了解系统健康状态、资源趋势乃至预测容量。
监控不只是展示，更是保障稳定性与成本优化的基础。如果你也在香港机房运维业务，建议立刻搭建这套体系，晚一天都是风险。
