Ubuntu部署Prometheus与Alertmanager：systemd配置、告警对接及cpolar远程访问

前言

在 Prometheus 监控体系中，采集到指标只是第一步。能否把连续异常转成有意义的告警，再将不同级别的消息交给对应人员，才决定了系统有没有形成完整的告警处理链路。若只在监控界面看到曲线，却缺少规则评估和通知路由，服务出问题时仍然需要人工守着页面；若没有等待时间、分组和重复通知控制，短暂波动又可能制造大量噪音。

Prometheus 与 Alertmanager 正好分工处理这些环节。Prometheus 根据 PromQL 告警规则判断指标条件，并在达到 for 设定的持续时间后进入触发状态；Alertmanager 接收告警，按标签进行分组、去重与路由，也支持静默和抑制。两者联通后还要设置有效的接收器，才能把结果交给邮件、Webhook 等实际通知渠道。服务启动、告警规则生效和消息送达，是需要分别检查的三个阶段。

本文以 Ubuntu 二进制部署为基础，保留原教程的 Prometheus、Alertmanager 历史版本及 systemd 操作顺序，逐步配置 9090 监控页面、9093 告警管理接口、alerting.alertmanagers 和基础规则文件，并追加邮件接收器示例与校验命令。最后用 cpolar 映射 Prometheus 页面，解决异地查看问题。原稿中存在压缩包版本混用、可执行路径错误以及只配置对接却没有通知渠道的问题，文中会将原始片段和修正方案明确区分，避免照搬出错。

一、先分清 Prometheus 与 Alertmanager 各做什么

完整的告警链路是"Prometheus 抓取指标 → 规则评估进入 Pending/Firing → 发送给 Alertmanager → 分组与路由 → 接收器交付通知"。在 Prometheus 页面看到 Targets 正常，只证明采集成功；在 Alertmanager 页面看到告警，只证明已接收，不能替代最后的通知送达验证。

本篇的原始环境是 Ubuntu Linux 上的二进制安装，示例端口分别是 Prometheus 9090、Alertmanager 9093。如果两个组件不在同一台主机，下面配置中的 localhost 必须换成实际可达地址。原图按原来的操作顺序保留。

二、在 Ubuntu 安装 Prometheus

2.1 创建目录、下载并上传二进制包

先准备 /app 作为程序目录。原文两条命令如下；如果已有 /app，mkdir /app 会提示目录存在，可以改用 mkdir -p /app，但下面保留原始输入。

shell 复制代码

mkdir /app

shell 复制代码

cd /app

从 Prometheus 官方下载页选择 Linux 与实际 CPU 架构匹配的压缩包，再通过 MobaXterm 等终端工具上传到 /app。版本和文件名以自己实际下载的文件为准，不要把不同版本的命令混用。

2.2 解压和重命名：先核对原文版本差异

原文解压命令使用 3.7.3，对应截图如下：

shell 复制代码

tar -xzvf prometheus-3.7.3.linux-amd64.tar.gz

接下来的重命名和删除命令却突然变成 3.5.0。保留原文片段供对照，不能把它直接接在上面的 3.7.3 解压命令之后执行：

shell 复制代码

mv prometheus-3.5.0.linux-amd64 prometheus
rm -rf prometheus-3.5.0.linux-amd64.tar.gz

如果实际下载的确实是 3.7.3 压缩包，且解压目录也叫 prometheus-3.7.3.linux-amd64，对应修正示例如下。删除安装包属于可选操作，确认程序运行正常后再执行：

shell 复制代码

cd /app
mv prometheus-3.7.3.linux-amd64 prometheus
# 可选：核对文件后再删除压缩包
# rm -f prometheus-3.7.3.linux-amd64.tar.gz

进入重命名后的目录，查看实际二进制版本，确保下载文件、解压目录、执行文件对应的是同一版。

shell 复制代码

cd /app/prometheus
./prometheus --version

2.3 准备 TSDB 目录与 systemd 服务

Prometheus 的时间序列数据库需要可写目录。原文建立 /var/lib/prometheus 并创建系统服务文件，这些操作按顺序保留：

shell 复制代码

mkdir -p /var/lib/prometheus

shell 复制代码

vim /usr/lib/systemd/system/prometheus.service

下面为原文的 systemd 内容，保持原样。它采用 root 运行、开启 --web.enable-lifecycle，属于原示例设置；正式部署建议改用专用账号、最小权限，并限制可修改配置的管理接口对外暴露。

shell 复制代码

[Unit]
Description=Prometheus
Documentation=https://prometheus.io/
After=network.target

[Service]
Type=simple
User=root
ExecStart=/app/prometheus/prometheus --config.file=/app/prometheus/prometheus.yml --storage.tsdb.path=/var/lib/prometheus --web.enable-lifecycle
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure

[Install]
WantedBy=multi-user.target

原文接着执行开机自启、启动和状态检查。创建或修改 unit 文件后，应先运行 systemctl daemon-reload，否则 systemd 不一定读取到刚保存的配置。原始命令继续保留：

shell 复制代码

systemctl enable prometheus 
systemctl start prometheus
systemctl status prometheus

shell 复制代码

# 修正后的常用执行顺序（补充示例）
sudo systemctl daemon-reload
sudo systemctl enable --now prometheus
sudo systemctl status prometheus --no-pager
curl -fsS http://127.0.0.1:9090/-/ready

验证时应同时查看 systemd 状态和 9090 Web 页面。Ubuntu 服务器本地使用 127.0.0.1:9090，同一局域网其他设备使用"服务器 IP:9090"；原稿把地址写作"极空间 IP"只是旧稿串入的称谓，不代表本节在极空间 NAS 上安装。

三、在 Ubuntu 安装 Alertmanager

3.1 下载、上传、解压和重命名

从 Prometheus 官方下载页下载适用于 Linux 架构的 Alertmanager 安装包。原文使用 0.27.0.linux-amd64，以下截图和命令按原顺序呈现；升级版本时文件名应同步修改。

shell 复制代码

tar -vxzf alertmanager-0.27.0.linux-amd64.tar.gz

shell 复制代码

mv alertmanager-0.27.0.linux-amd64 alertmanager

按原文解压并重命名后，目录为 /app/alertmanager。里面的可执行文件通常是 /app/alertmanager/alertmanager，配置文件则是 /app/alertmanager/alertmanager.yml；它们不是同一个路径，也不等于 /app/alertmanager 目录本身。

3.2 注册 systemd：修正 ExecStart 的关键路径

原文先进入系统服务目录再编辑 alertmanager.service，下面原始服务文件与截图完整保留。

shell 复制代码

cd /usr/lib/systemd/system

shell 复制代码

vim alertmanager.service

shell 复制代码

[Unit]
Description=https://prometheus.io

[Service]
Restart=on-failure
ExecStart=/app/alertmanager --config.file=/app/alertmanager.yml

[Install]                      
WantedBy=multi-user.target

不能直接使用上面服务文件的 ExecStart=/app/alertmanager --config.file=/app/alertmanager.yml。 /app/alertmanager 是目录，systemd 应执行其中的二进制文件；原文也没有把配置文件放在 /app/alertmanager.yml。建议把自建服务单元放在 /etc/systemd/system/alertmanager.service，示例如下：

ini 复制代码

[Unit]
Description=Prometheus Alertmanager
Documentation=https://prometheus.io/docs/alerting/latest/alertmanager/
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=alertmanager
Group=alertmanager
WorkingDirectory=/app/alertmanager
ExecStart=/app/alertmanager/alertmanager --config.file=/app/alertmanager/alertmanager.yml --storage.path=/var/lib/alertmanager --web.listen-address=127.0.0.1:9093
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

这是一套用于 Prometheus 和 Alertmanager 安装在同一台主机 的基础示例，所以 9093 只监听本机；跨主机部署时需调整监听地址和网络访问控制。若选用专用用户，先执行以下准备命令，再启动服务。若系统已经存在同名账号，应检查而不是重复创建：

shell 复制代码

sudo useradd --system --no-create-home --shell /usr/sbin/nologin alertmanager
sudo mkdir -p /var/lib/alertmanager
sudo chown -R alertmanager:alertmanager /var/lib/alertmanager /app/alertmanager
sudo chmod +x /app/alertmanager/alertmanager
sudo systemctl daemon-reload
sudo systemctl enable --now alertmanager
sudo systemctl status alertmanager --no-pager

原文重载、启动、设置开机自启的命令及截图继续保留。需要先确保 unit 路径修正完毕，命令本身不会自动纠正错误的服务配置。

shell 复制代码

systemctl daemon-reload
systemctl start alertmanager.service
systemctl enable alertmanager.service

原文还给出 nohup 手动后台启动示例，但其日志路径重复写入 /app/alertmanager/alertmanager，并依赖当前工作目录。与 systemd 二选一即可，不建议同时启动两个进程占用 9093。原命令保留供识别：

shell 复制代码

nohup ./alertmanager --config.file=alertmanager.yml >> /app/alertmanager/alertmanager/alertmanager.out 2>&1 &
cat alertmanager.out

采用前面的本机监听示例时，可在服务器本地验证：

shell 复制代码

curl -fsS http://127.0.0.1:9093/-/healthy
curl -fsS http://127.0.0.1:9093/-/ready
sudo journalctl -u alertmanager -n 50 --no-pager

页面打开或就绪检查成功只代表 Alertmanager 进程已提供服务；不代表任何邮件、Webhook 或消息通知已经配置。

四、将 Prometheus 与 Alertmanager 连通

4.1 分清"抓取自身指标"和"发送告警"

Alertmanager 同时提供自身 /metrics 端点与接收 Prometheus 告警的接口。把它加入 scrape_configs 只会采集自身指标；要发送 Firing 告警，必须配置顶层 alerting.alertmanagers。原稿对两者的解释混在了一起。

首先编辑 Prometheus 主配置文件：

shell 复制代码

vi /app/prometheus/prometheus.yml

以下为原文添加的监控目标片段，应放入已有的 scrape_configs 下、某个 job_name 对应的 static_configs 内，单独复制这一小段到 YAML 顶层不是完整配置：

shell 复制代码

      - targets: ["localhost:9093"]
        labels:
          app: "alertmanager"

它可等价地写成下面的独立抓取任务（若原文件已经有相同 job，不要重复创建）：

yaml 复制代码

# 合并到已有 scrape_configs 列表中
- job_name: alertmanager
  static_configs:
    - targets: ["127.0.0.1:9093"]
      labels:
        app: "alertmanager"

真正的告警发送目标是原文接下来的 alerting 配置。保留原始片段与界面截图：

shell 复制代码

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

alerting: 应位于 prometheus.yml 顶层，与 scrape_configs、rule_files 平级。两个组件同机时，localhost:9093 对应上面的本地监听；若是 Docker 或分离主机环境，localhost 的含义不同，必须写 Prometheus 真正可达的地址。

4.2 原稿尚缺的步骤：写入告警规则并加载

至此仅完成服务部署与告警发送目标配置。接下来需要独立的规则文件，通过 rule_files 加载。以下测试规则是本次新增内容，不是原文已有实测，也不能作为真实业务规则长期保留。

在 /app/prometheus/alerts.yml 中添加临时测试规则 ，用常量向量模拟一个持续存在的测试条件。Prometheus 的 for: 1m 表示条件持续满足约 1 分钟后才进入 Firing；完成联调后应移除或禁用，避免持续产生告警。

yaml 复制代码

groups:
  - name: alertmanager-demo
    rules:
      - alert: DemoAlert
        expr: vector(1)
        for: 1m
        labels:
          severity: warning
        annotations:
          summary: "Prometheus 与 Alertmanager 联调测试"
          description: "用于验证告警路由；完成测试后请删除本规则。"

再在 Prometheus 主配置文件的顶层补充规则文件路径；若原稿已存在 rule_files，请把新路径添加到现有列表，不要重复定义该键：

yaml 复制代码

rule_files:
  - /app/prometheus/alerts.yml

配置编辑后，先校验再重载：

shell 复制代码

/app/prometheus/promtool check rules /app/prometheus/alerts.yml
/app/prometheus/promtool check config /app/prometheus/prometheus.yml
sudo systemctl restart prometheus
curl -fsS http://127.0.0.1:9090/-/ready

在 Prometheus 的 Alerts 页面查看 DemoAlert 从 Pending 到 Firing，再进入 Alertmanager 页面确认已收到同名告警。这里只验证规则评估和告警接收。

4.3 配置接收器：先明确通知去向，再谈降噪

Alertmanager 的配置文件中需要有路由和接收器。下面是只用于本地联调、不发送任何外部通知的最小例子。它可以用来观察告警是否进入 Alertmanager，但不能算邮件已经送达：

yaml 复制代码

route:
  receiver: local-demo
  group_by: ['alertname', 'severity']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
receivers:
  - name: local-demo

若确实需要邮件通知，应将上面的示例替换为实际可用的 SMTP 信息。以下所有邮箱、服务器和密码均为占位符，未配置真实信息前无法发送邮件：

yaml 复制代码

global:
  smtp_smarthost: 'smtp.example.com:587'
  smtp_from: 'alerts@example.com'
  smtp_auth_username: 'alerts@example.com'
  smtp_auth_password: 'REPLACE_WITH_SMTP_APP_PASSWORD'
route:
  receiver: email-oncall
  group_by: ['alertname', 'severity']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
receivers:
  - name: email-oncall
    email_configs:
      - to: 'oncall@example.com'
        send_resolved: true

测试 SMTP 时，应先按邮件服务商要求设置真实主机、端口、发件账号和专用授权凭据，并限制配置文件读取权限。group_wait 是初次等待、group_interval 是同一组新增告警的通知间隔、repeat_interval 是未解决告警的重复提醒间隔；它们影响通知节奏，不能替代合理阈值、持续时间和接收人排班。

shell 复制代码

sudo chmod 600 /app/alertmanager/alertmanager.yml
/app/alertmanager/amtool check-config /app/alertmanager/alertmanager.yml
sudo systemctl restart alertmanager
sudo journalctl -u alertmanager -n 50 --no-pager

完整验证应依次检查：测试规则进入 Firing、Alertmanager 页面收到告警、接收器发送日志无错误，以及目标邮箱确实收到消息。完成后删除 DemoAlert 并再次校验、重载。静默可在 Alertmanager UI 设置；抑制与分级路由可继续在配置文件中扩展，但原稿并没有展示这些功能的实际配置。

五、安装 cpolar：解决异地查看监控页面

原文 cpolar 隧道映射 Prometheus 的 9090 Web UI，不映射 Alertmanager 9093，也不是告警推送服务。公网远程查看与通知接收属于两个不同环节。

5.1 安装并检查 cpolar

以下保留原文安装与状态检查命令。执行网络脚本前应核对可信来源；这里的 sudo 只加在管道左侧的 curl 上，并不自动使右侧的 sh 获得 root 权限，实际安装时应参照 cpolar 对应系统的官方步骤。

shell 复制代码

sudo curl https://get.cpolar.sh | sh

shell 复制代码

sudo systemctl status cpolar

本机浏览器访问 http://127.0.0.1:9200，局域网其他设备可按实际监听情况使用 http://监控主机IP:9200。通过账号登录 Web UI。将管理页面限制在可信网络，避免把隧道管理控制台也直接开放到公网。

5.2 创建随机公网地址

在"隧道管理 → 创建隧道"中按原文填写：隧道名称 prometheus、协议 http、本地地址 9090、域名类型"随机域名"、地区 China Top。这一步之前先确认本地 http://127.0.0.1:9090 能正常打开。

创建成功后进入"状态 → 在线隧道列表"复制生成的地址，优先用 HTTPS 入口测试。随机地址可能会变化，不应当作长期不变的监控书签。

5.3 保留固定二级子域名

如果确实需要长期远程查看，可根据 cpolar 账号的实际套餐和保留规则申请固定二级子域名。原稿把 prometheus 作为自定义名称，是否可申请取决于实际占用情况。

回到本地 Web UI，在"隧道管理 → 隧道列表"找到前面创建的 prometheus 隧道，点击"编辑"。

将域名类型选择为"二级子域名"，填写实际保留的 Sub Domain，地区保持一致，更新配置。

最后从在线隧道列表复制更新后的 HTTPS 公网地址，使用外部网络验证能否打开 Prometheus 页面。固定地址只意味着域名可长期保留，并不保证本地服务或网络永远在线。

**安全提醒：**Prometheus 页面可能暴露内部主机名、监控目标、告警条件等信息；原文服务配置还启用了生命周期接口。隧道的 HTTPS 只保护传输过程，不能代替身份认证与访问控制。请在公开前配置有效的认证、受控网络访问或前置代理，并评估是否需要暴露管理页面。

六、部署完成后如何判断链路真的可用

检查顺序应为"Prometheus 采集状态 → 规则 Pending/Firing → Alertmanager 接收 → 通知接收器真实送达 → cpolar 远程页面可达"。界面可访问、HTTP 健康检查、规则计算与通知送达各自代表不同层级，任何一项都不宜替代其余检查。

结尾

本篇完成了 Ubuntu 上 Prometheus 与 Alertmanager 的二进制部署、systemd 管理和告警对接，并给出测试规则、路由接收器及配置校验的补充示例。原稿的 9090 公网访问部分保留为远程查看场景，不将其误作通知渠道。后续上线时，应使用真实业务指标设计分级规则，检验通知送达，设置静默、抑制和轮值安排，同时对 9090/9093 管理入口实施访问控制。只有采集、判断、接收、通知及人工响应逐环节验证，告警系统才算真正形成闭环。