没有公网 IP 怎么远程抓取服务器指标？node_exporter + Prometheus + cpolar 实战

没有公网 IP 怎么远程抓取服务器指标？node_exporter + Prometheus + cpolar 实战

前言

做服务器监控时，我最怕的一种情况不是“完全没数据”，而是每一层看起来都像正常：node_exporter 进程在跑、Prometheus 也启动了、公网地址还能打开，可指标就是抓不到。CPU、内存、磁盘和网络这些数据本身并不难采集，真正容易把人绕进去的是采集端、Prometheus 和网络入口混在一起排查。我的习惯是先把本地链路跑通，再去处理远程访问，这样一旦失败，至少知道问题在哪一层。尤其当服务器没有公网 IP 时，很容易把“外面访问不到”直接归因到网络，其实也可能只是 node_exporter 根本没启动，或者 Prometheus 的抓取目标没有配置对。

这次我在 CentOS 7 上部署 node_exporter 1.2.0，注册成 systemd 服务，再把 localhost:9100 加进 Prometheus，并实际验证“端口正常时能抓取、端口没启动时抓不到”这两种状态。确认本地采集没有问题以后，再安装 cpolar，把 9100 通过 HTTP 隧道提供到公网，让另一侧 Prometheus 改用公网地址抓取，最后继续配置固定二级子域名 node1。我更看重的是这套顺序：先证明本地采集成立，再证明跨网络抓取成立。 这样以后真遇到抓取失败，不需要同时怀疑三四个组件，也不会因为公网地址能打开就误以为监控已经完全正常。

1. 先明确这套监控链路

这次真正需要打通的是：

服务器 → node_exporter → Prometheus → 公网访问入口

其中 node_exporter 负责暴露主机指标，Prometheus 负责抓取这些指标，cpolar 只处理网络入口。

这几个角色最好不要混在一起。node_exporter 的 9100 接口能打开，只能说明采集端有响应；Prometheus 能成功抓取，才说明监控链路真正接上了。

当前流程也明确要求：在配置 node_exporter 之前，Prometheus 已经提前部署完成。

2. 在 CentOS 7 上安装 node_exporter

先下载当前使用的 node_exporter 1.2.0：

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

下载完成后解压：

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

然后把目录移动到 /opt，并重命名为：

node_exporter

mv node_exporter-1.2.0.linux-amd64 /opt/node_exporter

这样后面的 systemd 配置就可以固定指向：

/opt/node_exporter/node_exporter

3. 把 node_exporter 注册成 systemd 服务

先创建或编辑服务文件：

sudo vi /etc/systemd/system/node_exporter.service

当前服务配置如下：

[Unit]
Description=Node Exporter
Documentation=https://github.com/prometheus/node_exporter
After=network.target

[Service]
User=node_exporter
Group=node_exporter
Type=simple
ExecStart=/opt/node_exporter/node_exporter

[Install]
WantedBy=default.target

这里使用专用的：

• 用户：node_exporter
• 用户组：node_exporter
• 启动程序：/opt/node_exporter/node_exporter

接着创建对应系统用户：

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

这个用户不创建家目录，也不允许登录，只用于运行 node_exporter。

然后让 systemd 重新加载服务配置，并启用 node_exporter：

systemctl daemon-reload
systemctl enable node_exporter

当前操作记录里没有单独给出 systemctl start node_exporter 的命令，只写到“启动后”通过 IP + 9100 访问，因此这里不额外补写没有出现的启动命令。

随后使用：

IP:9100

访问 node_exporter。

页面能够打开以后，说明 9100 服务已经可以访问。

4. 让 Prometheus 先在本地抓取 node_exporter

进入 Prometheus 安装目录，编辑：

prometheus.yml

vi prometheus.yml

加入当前抓取目标：

– targets: ["localhost:9100"]
labels:
app: "node_exporter"

这里使用的是：

localhost:9100

也就是说，这一步先不碰公网，只验证 Prometheus 能不能从本机抓到 node_exporter。

修改配置以后重启 Prometheus：

systemctl restart prometheus

随后可以看到 Prometheus 已经成功抓取 node_exporter 指标。

5. 端口停掉以后，抓取会发生什么？

当前实操还专门做了一次反向验证：当 node_exporter 对应端口没有启动时，Prometheus 无法成功抓取。

我觉得这一张图反而很重要。

它说明后面如果公网监控失败，不能第一反应就去改 cpolar。先回到本地确认 9100 是否正常、Prometheus 本地能不能抓到，排查会更快。

到这里，本地链路已经有了一个很清楚的基线：

node_exporter 9100 正常 → Prometheus 抓取成功。

6. 本地抓取正常以后，再安装 cpolar

接下来才处理跨网络访问。

执行当前安装命令：

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

安装完成后检查服务状态：

sudo systemctl status cpolar

服务正常以后，通过主机 IP + 9200 进入 cpolar Web 管理页面。

当前示例地址是：

http://192.168.42.101:9200

页面链接目标同时写成：

http://localhost:9200/

实际访问时，以当前设备真正可以打开的地址为准。

7. 给 node_exporter 的 9100 创建随机公网地址

进入【隧道管理 → 创建隧道】，当前配置为：

• 隧道名称：node_exporter
• 协议：http
• 本地地址：9100
• 域名类型：随机域名
• 地区：China VIP

创建成功以后，进入在线隧道列表查看公网地址。

使用生成的公网地址访问。

页面能够打开，说明：

node_exporter 9100 → cpolar HTTP 隧道 → 公网地址

这一层已经打通。

8. 让另一侧 Prometheus 改用公网地址抓取

当前随机公网地址记录为：

6d00d2bf.r8.vip.cpolar.cn

把 Prometheus 中的抓取目标改成：

– targets: ["6d00d2bf.r8.vip.cpolar.cn"]
labels:
app: "node_exporter"

随后当前测试显示抓取成功。

这一步才真正验证了远程链路：

Prometheus → 6d00d2bf.r8.vip.cpolar.cn → cpolar → node_exporter 9100

能够工作。

也正因为前面已经做过 localhost:9100 的本地抓取验证，所以这里如果失败，就更容易把排查重点放到公网地址和网络链路上。

9. 随机域名适合测试，长期抓取更适合固定地址

随机地址适合先确认“跨网络能不能抓到”。

但 Prometheus 的 targets 是写在配置文件里的。如果公网地址不断变化，就需要跟着修改抓取目标。

所以当前流程继续配置固定二级子域名。

进入预留页面。

选择保留二级子域名。

当前记录为：

• 地区：china Vip
• 二级子域名：node1

然后回到 cpolar Web UI，进入【隧道管理 → 隧道列表】，找到：

node_exporter

并点击编辑。

修改为：

• 域名类型：二级子域名
• Sub Domain：填写已经保留的二级子域名
• 地区：China Vip

点击更新。

更新完成以后，在线隧道列表中的地址会变成固定二级子域名形式。

最后继续通过固定地址访问。

当前文字说明把这里描述成“访问本地部署的 prometheus 页面”，但前面的隧道实际映射的是 node_exporter 的 9100。这里不替现有记录改成另一个服务，只保留这个差异，并按整篇实际链路理解为 node_exporter 公网入口的固定化。

总结

这次最值得保留的不是“没有公网 IP 也能监控服务器”这句结论，而是整个排查顺序。

实际链路是：

CentOS 7 → node_exporter 1.2.0 → systemd → 9100 → Prometheus 本地抓取 → 停端口验证失败 → cpolar → 随机公网 → Prometheus 远程抓取成功 → 固定二级子域名 node1。

如果以后远程抓取失败，我会按这个顺序查：

先看 node_exporter 是否运行 → 再看 9100 是否可访问 → 再看本地 Prometheus 是否能抓取 → 最后检查 cpolar 公网地址。

这样比一上来同时改 Prometheus、node_exporter 和公网配置要清楚得多。

另外也要分清：node_exporter 提供的是主机指标入口，真正的采集和后续监控分析仍由 Prometheus 负责；cpolar 只补跨网络访问这一层，不改变 node_exporter 和 Prometheus 本身的职责。