如何在香港服务器部署Prometheus与Alertmanager，实现系统性能自动化监控

我们团队持续遭遇服务器性能瓶颈的问题，尤其是在夜间备份、爬虫高峰以及CDN回源异常期间，香港节点的CPU使用率飙升、磁盘I/O延迟上升，而我们往往无法第一时间获知告警信息。为了彻底解决这类运维盲区，我决定引入 Prometheus + Alertmanager 构建一套覆盖 CPU、内存、磁盘、网络以及自定义业务指标的自动化性能监控与告警系统。

这篇文章将从实战角度出发，讲述我如何在香港物理服务器上部署 Prometheus 与 Alertmanager，合理分配资源、优化抓取频率，并通过智能告警机制实现系统自愈的第一步。

一、部署前的硬件与网络准备

我选用的是 A5 数据香港机房的 E5 双路服务器，搭配 64GB 内存与 2TB NVMe SSD，保证了 Prometheus 快速写入时序数据库的 I/O 性能。公网带宽为 100Mbps，且内网打通了其它监控目标（如Kubernetes节点、Redis、Nginx服务器等），为后续抓取目标指标打下网络基础。

二、Prometheus 安装配置

1. 创建独立系统用户并准备目录结构

useradd --no-create-home --shell /bin/false prometheus
mkdir -p /etc/prometheus /var/lib/prometheus

2. 下载并安装二进制包

wget https://github.com/prometheus/prometheus/releases/download/v2.51.0/prometheus-2.51.0.linux-amd64.tar.gz
tar -xvf prometheus-2.51.0.linux-amd64.tar.gz
cp prometheus-2.51.0.linux-amd64/{prometheus,promtool} /usr/local/bin/
cp -r prometheus-2.51.0.linux-amd64/{consoles,console_libraries} /etc/prometheus/

3. Prometheus 配置文件（/etc/prometheus/prometheus.yml）

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'linux-server'
    static_configs:
      - targets: ['127.0.0.1:9100']

  - job_name: 'nginx-exporter'
    static_configs:
      - targets: ['127.0.0.1:9113']

我为每类监控目标单独建立一个 job，并严格控制抓取频率，以降低资源占用。

4. 设置 systemd 启动服务

cat <<EOF > /etc/systemd/system/prometheus.service
[Unit]
Description=Prometheus Monitoring
After=network.target

[Service]
User=prometheus
ExecStart=/usr/local/bin/prometheus \
  --config.file=/etc/prometheus/prometheus.yml \
  --storage.tsdb.path=/var/lib/prometheus \
  --web.listen-address=":9090"
Restart=always

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reexec
systemctl enable --now prometheus

三、部署 Alertmanager 并配置告警

1. 安装 Alertmanager

wget https://github.com/prometheus/alertmanager/releases/download/v0.27.0/alertmanager-0.27.0.linux-amd64.tar.gz
tar -xvf alertmanager-0.27.0.linux-amd64.tar.gz
cp alertmanager-0.27.0.linux-amd64/alertmanager /usr/local/bin/

2. Alertmanager 配置（支持邮件与Telegram双通道）

global:
  smtp_smarthost: 'smtp.mailgun.org:587'
  smtp_from: 'monitor@mydomain.com'
  smtp_auth_username: 'monitor@mydomain.com'
  smtp_auth_password: 'app-specific-password'

route:
  group_wait: 10s
  group_interval: 30s
  repeat_interval: 3h
  receiver: 'email-team'

receivers:
  - name: 'email-team'
    email_configs:
      - to: 'ops@mydomain.com'

  - name: 'telegram-notify'
    telegram_configs:
      - bot_token: '123456789:ABCDEF'
        chat_id: -123456789

# 启动服务
cat <<EOF > /etc/systemd/system/alertmanager.service
[Unit]
Description=Alertmanager
After=network.target

[Service]
ExecStart=/usr/local/bin/alertmanager --config.file=/etc/alertmanager/config.yml
Restart=always

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now alertmanager

四、添加告警规则（Prometheus）

在 /etc/prometheus/alerts.yml 中添加以下内容：

groups:
- name: system-alerts
  rules:
  - alert: HighCPULoad
    expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[1m])) * 100) > 85
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "高 CPU 使用率告警"
      description: "服务器 {{ $labels.instance }} CPU 使用率超过 85%"

在 prometheus.yml 中引入告警规则：

rule_files:
  - "alerts.yml"

alerting:
  alertmanagers:
    - static_configs:
        - targets:
            - "localhost:9093"

五、Grafana集成展示

Prometheus + Alertmanager 的组合虽然功能强大，但可视化仍需依赖 Grafana。我部署了独立 Grafana 实例：

docker run -d \
  -p 3000:3000 \
  --name=grafana \
  -e "GF_SECURITY_ADMIN_PASSWORD=securepassword" \
  grafana/grafana

添加数据源指向 http://localhost:9090，并导入如 Node Exporter Full 等成熟模板即可。

六、优化与故障处理经验

• 存储压力控制：将 –storage.tsdb.retention.time=7d 参数加入 Prometheus 启动命令，避免磁盘爆满。
• 网络抓取加速：香港服务器部署专门的内网 exporters 节点，减轻 Prometheus 本身的网络消耗。
• 高可用设计：我最终将 Prometheus 与 Alertmanager 通过 Keepalived 实现 VIP漂移 + 多节点热备。

我通过这次部署，不仅成功实现了对香港服务器资源的全面可视化监控，还实现了自动告警机制，极大减少了因性能瓶颈导致的服务中断时间。这套基于 Prometheus 与 Alertmanager 的方案让我意识到监控系统不仅是工具，更是一套稳定运营的保障。

七、Prometheus 联邦架构：跨节点聚合的关键一招

随着我们业务在多个香港节点和海外节点的扩展，单个 Prometheus 实例已无法满足分布式监控需求——不仅存在抓取压力，还会丢失部分网络受限节点的数据。因此，我采用了 Prometheus 联邦架构，实现数据分层采集与中心聚合。

联邦架构的基本思路：

• 底层节点（如每个业务服务器上运行的 Prometheus 实例）专注于本地 exporter 指标抓取；
• 顶层联邦节点 每隔 30s 聚合底层指标，统一写入持久存储并供 Grafana 查询。

1. 顶层联邦节点配置：

scrape_configs:
  - job_name: 'federate-hk'
    honor_labels: true
    metrics_path: '/federate'
    params:
      'match[]':
        - '{job=~".+"}'   # 精选你需要聚合的指标
    static_configs:
      - targets:
          - '10.10.10.11:9090'
          - '10.10.10.12:9090'

注意：只抓取关键指标，避免 Prometheus 联邦节点本身变得庞大臃肿。

2. 数据查询优化

为了避免联邦节点在 Grafana 查询时的性能瓶颈，我还将其配置为只保留 15 天数据，长期指标则通过 Thanos Bucket 存储后续处理。

八、高可用 Prometheus + Alertmanager 架构设计

当我正式将这套监控系统上线于生产环境时，最大的担忧就是 Prometheus 单点故障。因此，我基于以下三层高可用设计进行强化：

1. Prometheus 双实例 + Keepalived + NFS 共享存储

两台 Prometheus 节点（主 + 备）配置相同，分别监听本地抓取目标；

使用 Keepalived 实现 VIP 漂移；

指标存储路径（如 /var/lib/prometheus）通过 NFS 挂载共享卷，保障节点切换时数据不中断。

# Keepalived 配置片段
vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 150
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1234
    }
    virtual_ipaddress {
        192.168.100.100
    }
}

2. Alertmanager 集群模式

# alertmanager.yml 支持 mesh
cluster:
  peer: alert1.mydomain.com:9094
  peer: alert2.mydomain.com:9094

节点之间自动同步告警状态；

结合 –cluster.listen-address=0.0.0.0:9094，实现 Alertmanager 多节点 HA。

九、实现告警自愈机制（自动执行修复脚本）

单纯的告警并不能缓解压力，我们需要做到“告警即修复”。我通过 webhook 方式，将告警消息发送给一套自定义处理系统，完成 自动重启、资源清理、服务伸缩 等操作。

1. Prometheus 告警 → Alertmanager → Webhook 接口

receivers:
  - name: 'auto-healer'
    webhook_configs:
      - url: 'http://10.10.10.50:8080/alert'

2. Webhook Server 示例（Python Flask）

from flask import Flask, request
import os

app = Flask(__name__)

@app.route('/alert', methods=['POST'])
def handle_alert():
    data = request.json
    alerts = data.get('alerts', [])
    for alert in alerts:
        if alert['labels']['alertname'] == 'HighCPULoad':
            os.system('systemctl restart myapp.service')
    return '', 200

app.run(host='0.0.0.0', port=8080)

我们甚至扩展了 webhook：若连续3次 CPU告警触发，还会执行临时 scale up 脚本，将容器扩容1个副本。

十、最终效果

部署完成后，我将所有核心业务服务器接入 Prometheus 联邦架构中。通过 Grafana 可快速聚合不同区域性能趋势，而 Alertmanager 则通过邮件 + Telegram + 自动执行脚本，及时响应告警并完成部分修复任务。

目前这套系统已经成功支撑了多个节点的连续运行，无需人工介入，平均节省了我 70% 的运维人力。更重要的是，它让我有能力主动发现问题、提前告警、自动修复，实现了系统性能管理的“闭环”。