Prometheus跨主机监控实战：Node Exporter部署、CPU内存告警与cpolar远程采集

Prometheus跨主机监控实战：Node Exporter部署、CPU内存告警与cpolar远程采集

前言

Prometheus 采用定期抓取指标的方式采集目标状态。对 Linux 主机而言，Node Exporter 可以把 CPU、内存、文件系统和网络等指标暴露在 HTTP/metrics端点。实际运维中，Prometheus 和被监控主机往往分开部署；当两台主机处于同一个可路由网络时，直接配置被监控端 IP 与 9100 端口即可。但如果目标设备位于另一处内网，监控中心不能直接到达它，单纯把目标 IP 写进配置文件，并不能解决链路不通的问题。是否采集成功，需要同时检查 Exporter 进程、指标端点、网络连通性和 Prometheus 的抓取任务。尤其是接口能在目标本机打开，却不能从监控端访问时，应该先区分本机服务是否启动、主机防火墙是否放行以及公网隧道是否在线，不要把所有问题都归结为 Prometheus 的配置错误。

本篇以两台 CentOS 7 虚拟机演示完整过程：监控端为 192.168.42.140，被监控端为 192.168.42.145。首先安装 Node Exporter 1.2.0，配置专用运行用户和 systemd 服务，检查/metrics；随后在 Prometheus 的静态目标中添加192.168.42.145:9100，验证 Targets 和up指标。接下来编写 CPU、内存告警规则，并说明规则文件、评估周期与 Alertmanager 通知之间的关系。最后使用 cpolar 提供跨网络入口，演示随机域名与固定二级子域名，并补充 HTTPS 抓取配置。原文命令及截图全部保留；涉及端口、路径、安全和版本差异的地方单独标注，方便读者按实际部署环境检查。

1 CentOS 7 安装 Node Exporter：二进制包与 systemd

先确认本篇的两台虚拟机分工。下面是原文演示用的局域网地址，不是每位读者都需要照抄的固定参数：

• 监控主机（Prometheus）：192.168.42.140。
• 被监控主机（Node Exporter）：192.168.42.145。

监控主机事先准备以下程序：

• Prometheus：负责抓取、保存并查询指标，也负责评估告警规则。
• Alertmanager：在完成相应配置后，负责告警聚合、静默和通知分发；只看指标时并非必需。

被监控主机安装：

• node_exporter：采集并暴露 Linux 主机的系统指标。

Prometheus 和 Alertmanager 的基础安装，原文另有两篇关联教程，本文不重复展开：《监控不再局域网！Cpolar 让 Prometheus 走出内网限制！》、

《告别宕机！零基础搭建服务器监控告警系统！小白也能学会！》。

先登录192.168.42.145，下载原文采用的 Node Exporter1.2.0Linux amd64 二进制包：

curl-LOhttps://github.com/prometheus/node_exporter/releases/download/v1.2.0/node_exporter-1.2.0.linux-amd64.tar.gz

下载后在当前目录解压。后面所有路径操作都以这个压缩包展开得到的目录为基础：

tarxvfz node_exporter-1.2.0.linux-amd64.tar.gz

把解压出来的目录移到/opt，统一命名为node_exporter，便于随后在服务文件里指定可执行文件路径：

mvnode_exporter-1.2.0.linux-amd64 /opt/node_exporter

为了让服务能由 systemd 管理，先创建服务单元文件：

sudovi/etc/systemd/system/node_exporter.service

原文的服务内容如下。User和Group指向专用账号，ExecStart对应刚才移动后的二进制路径；这段内容原样保留：

[Unit]Description=Node ExporterDocumentation=https://github.com/prometheus/node_exporterAfter=network.target[Service]User=node_exporterGroup=node_exporterType=simpleExecStart=/opt/node_exporter/node_exporter[Install]WantedBy=default.target

按服务文件中填写的名称创建专用用户。这里不创建家目录，也不允许该用户交互式登录，避免为采集程序使用个人登录账户：

useradd--no-create-home--shell/bin/false node_exporter

重新加载 systemd 配置，并按照原文设置开机自启：

systemctl daemon-reload systemctlenablenode_exporter

**启动与验证补充：**原文执行了enable，没有展示start。按下面步骤检查本机指标端点，才可确认服务真正运行。

sudosystemctl start node_exportersudosystemctl status node_exportercurlhttp://127.0.0.1:9100/metrics

如果是通过局域网直连，再从监控主机测试http://192.168.42.145:9100/metrics；目标端防火墙应仅放行监控主机需要的访问，不要为测试把 9100 直接开放给整个公网。

这里需要补一步：enable只设置开机自启，并不会立即运行服务。创建用户和单元文件之后，还要执行启动命令，再查看状态、访问 9100 端口。原文截图对应的是 Node Exporter 页面，页面能显示并不等于 Prometheus 已经开始采集。

2 配置 Prometheus scrape_configs 与静态目标

切回监控主机192.168.42.140，进入真实的 Prometheus 配置目录，编辑prometheus.yml。原文用的是相对文件名，操作前先确认当前目录：

viprometheus.yml

在已有scrape_configs的合适任务里增加下面这段静态目标配置。保留原稿的缩进和标签；它是一个配置片段，不是可以单独覆盖整个prometheus.yml的完整文件：

- targets:["192.168.42.145:9100"]labels: app:"node_exporter"

配置位置提示：- targets片段必须放在实际抓取任务的static_configs内，例如原文使用的job_name所对应位置。完整结构应以现有prometheus.yml为准，不要单独把三行粘到文件末尾。在新环境保存后，可以用promtool check config验证 YAML 配置。

保存配置，按原文方式重启 Prometheus：

systemctl restart prometheus

原文截图展示了该监控目标被成功采集的界面。排查时建议进一步在 Prometheus 的 Targets 中检查实际状态，并用up{instance="192.168.42.145:9100"}判断目标是否可达：值为1表示最近一次抓取成功，0表示抓取失败。

原稿还保留了目标未开放或无法连通时的失败截图，说明“配置了目标”与“目标真正可以访问”是两回事。应分别检查进程、监听端口、主机防火墙和两端路由。

如果两台主机可直接通过192.168.42.145:9100通信，到这里就已具备局域网跨主机采集链路。后面的 cpolar 用于监控端无法直接到达另一处内网的目标，而不是所有跨主机监控都必须增加的一层。

3 加载告警规则并接入 Alertmanager

下一步不只是看到一串指标，还要知道指标达到阈值时系统能否识别。需要分清两个组件：Prometheus 定期评估规则，Alertmanager 接收已触发的告警并按配置路由通知。原文截图聚焦的是规则与告警页面，没有完整演示通知渠道的送达过程。

先在监控主机编辑 Prometheus 主配置：

viprometheus.yml

参考原文截图，在配置中确认告警规则文件被rule_files引用，并在确实需要外部通知时填写 Alertmanager 目标：

原文将 CPU、内存阈值规则保存为3.yml，其示例采用超过10%、持续10 秒的演示条件。下面完整保留原始规则。这个阈值适合观察告警是否产生，不宜不经评估就当作生产环境的高负载阈值；而且规则未用instance过滤，若同一任务中有多台主机，可能同时对多台主机评估。

groups: - name: node-alerts rules:# CPU 使用率 > 10% 持续10s- alert: 高CPU使用率 expr:100-(avg by(instance, job)(rate(node_cpu_seconds_total{mode="idle"}[5m]))*100)>10for: 10s labels: severity: warning annotations: summary:"高CPU使用 {{$labels.instance }}"description:"CPU大于10% (current value: {{$value}}%) 超过10s"# 内存使用率 > 10%- alert: 内存使用率 expr:(1-(node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes))*100>10for: 10s labels: severity: warning annotations: summary:"内存使用率过高 {{$labels.instance }}"description:"内存使用率大于10% (current value: {{$value}}%) 超过10s"

**规则加载与范围提醒：**原文3.yml的两条规则没有限定目标实例，且阈值 10% 只是演示。请确认主配置中的rule_files引用了该规则文件，并检查目标过滤条件。rule_files与alerting是 Prometheus 主配置中的不同字段。

# 以下是结构示意，请替换为真实规则文件路径与 Alertmanager 地址rule_files:-/实际目录/3.ymlalerting:alertmanagers:-static_configs:-targets:["127.0.0.1:9093"]

promtool check config prometheus.yml promtool check rules3.yml

如果没有配置接收器和路由，Prometheus 能显示规则与Firing，也不代表邮件或消息通知已经送达。

确认主配置确实加载了3.yml，检查 YAML 与规则语法后，再重启 Prometheus：

systemctl restart prometheus

原文展示的是 Prometheus 中能够看到新增规则的状态。这里要分别确认规则已经加载、指标表达式有结果，以及告警是否进入Pending或Firing；它们不是同一件事。

告警界面截图如下。for: 10s指条件需要保持一定时间，实际状态变化也受规则评估间隔和抓取频率影响。

到这一步，原文所展示的目标采集和规则评估就完成了。若希望收到邮件或其他消息，还需要验证 Prometheus 到 Alertmanager 的连接，以及 Alertmanager 接收器、路由和通知渠道。

4 在目标端安装 cpolar 作为跨网络入口

如果监控中心与被监控主机不在同一个可直接访问的网络中，可以在192.168.42.145被监控主机上安装 cpolar。它负责提供从公网访问本地 9100 服务的网络入口；Node Exporter 仍负责指标采集，Prometheus 仍负责主动抓取。

下列操作应在被监控端进行，不是在 Prometheus 监控端安装一份就自动打通目标：

按原文安装命令部署 cpolar。安装脚本来自在线地址，正式环境使用前应核查来源及脚本内容；原始命令照录，并不代表已在本次改写中重新执行：

sudocurlhttps://get.cpolar.sh|sh

然后查看 cpolar 服务状态，确认客户端进程是否正常运行：

sudosystemctl status cpolar

在同一个局域网内的电脑浏览器中访问被监控主机的9200管理端口，例如http://192.168.42.145:9200。原文该处链接显示的 IP 与实际链接地址不一致，改写正文以被监控端地址说明；不要把localhost当作远程机器的 IP。

用自己的 cpolar 账号登录管理页面，进入隧道配置。9200 是管理界面端口，不是待抓取指标的 9100 端口。

5 将 Node Exporter 9100 端口映射到公网

进入 cpolar Web UI 的隧道管理 → 创建隧道，设置一条专门转发 Node Exporter 的隧道：

• 隧道名称：例如node_exporter，注意避免与已有名称冲突。

• 协议：http。

• 本地地址：9100，即 Node Exporter 监听端口。

• 域名类型：先用随机域名验证。

• 地区：原稿选择China TOP，以实际控制台可选项为准。

创建后到在线隧道列表查看随机生成的公网地址：

原文给出了公网访问页面的截图。建议测试时打开https://实际公网域名/metrics，确认看到指标文本；仅打开根路径，不能代替对/metrics的检查。

6 配置 Prometheus HTTPS 公网抓取目标

回到监控主机，编辑实际生效的prometheus.yml：

viprometheus.yml

原文的随机域名示例是1a0f75b.r2.cpolar.top。下面的配置片段保留原样用于对照，但域名应以你自己的隧道列表为准；尤其要留意Prometheus 默认按 HTTP 抓取，如果采用 cpolar 的 HTTPS 地址，必须在相应scrape_config中明确设置scheme: https。

- targets:["1a0f75b.r2.cpolar.top"]labels: app:"node_exporter"

**HTTPS 抓取补充：**原文代码是targets片段，未展示所选公网 URL 的协议。若在线隧道列表中复制的是 HTTPS 地址，Prometheus 应使用scheme: https，targets中填写实际域名（含非默认端口时也需带端口），不要写入https://前缀。以下为单独任务的示意，不能与同一目标的旧内网任务重复混淆：

-job_name:"node_exporter_public"scheme:httpsmetrics_path:/metricsstatic_configs:-targets:["你的实际公网域名"]labels:app:"node_exporter"

**安全提醒：**Node Exporter 指标可能包含主机信息，HTTPS 仅保护传输，不等于提供应用级访问鉴权。不要将无访问限制的/metrics直接暴露给所有公网访客；优先使用受限网络、鉴权代理或隧道访问控制。

更新配置前先核对当前公网 URL 的协议、域名和端口，再按原文重启服务：

systemctl restart prometheus

原稿截图显示这一阶段的抓取结果。建议同时检查up指标，观察是否持续成功，而不只是某一次浏览器访问通过。跨网部署还应关注隧道断开、域名变化和超时。

7 预留固定二级子域名及长期采集检查

随机公网地址适合验证，长期监控如果频繁变化，就需要同步修改 Prometheus 的静态抓取目标。保留固定二级子域名可以减少这种配置变化，但它不等于主机、cpolar 和网络永远在线。

进入控制台预留 → 保留二级子域名，选择与后续隧道匹配的地区，并填写名称。原文示例使用nodee。注意原稿此处写了China Vip，后面隧道设置却写China TOP，实际配置应以预留域名对应地区为准，不能随意混用。

回到本地 cpolar 管理页面，找到node_exporter隧道并点击编辑：

接下来按原文把预留的域名关联到隧道：

• 域名类型：二级子域名。
• Sub Domain：填写已预留成功的名称。
• 地区：选择与刚才预留时相同的地区。

确认无误后点击更新：

进入在线隧道列表，核对地址已改为预留的固定二级子域名：

原文用固定公网地址打开了 Node Exporter 页面。正式长期监控时，还需把 Prometheus 的目标域名换成当前固定地址，重新验证/metrics、up和防护策略。固定域名只解决地址稳定问题，不会自动增加鉴权。

固定地址配置结束后，如果之前的抓取任务使用随机域名，记得将targets更新为固定域名并检查scheme。若隧道已离线，固定域名也无法保证采集成功。

至此，原稿的局域网和跨网络两种采集路径都有了明确的配置步骤。

结尾

本篇完成了两段连通方式的梳理：局域网采集使用192.168.42.145:9100，跨网采集则需要把公网 URL 正确转化为 Prometheus 的目标、协议及路径配置。只有这条抓取链路持续成功，后续规则评估才有可靠的指标输入。

整套流程可以拆成三层：

• 采集层：Node Exporter 运行在目标 Linux 主机上，提供 CPU、内存、文件系统、网络等指标。

• 监控层：Prometheus 用静态目标抓取指标，通过up、Targets 和 PromQL 检查采集是否正常。

• 跨网访问层：网络可达时直接使用内网地址；不能直接连通时，再考虑 cpolar 等受控连通方式，并保护指标接口。

实际运维还需要针对业务确定阈值、检查告警通知是否送达、限制/metrics的访问范围，并验证持续抓取与故障恢复。原稿中的测试截图提供了操作参照，但不代替新环境的连接和安全检查。

如果后面要增加服务器，也可以沿用“每台主机部署 Exporter，监控中心管理抓取目标”的思路扩展，再考虑 Grafana 展示及更细的告警策略。