没有公网 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

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

下载完成后解压:

shell 复制代码
tar xvfz node_exporter-1.2.0.linux-amd64.tar.gz

然后把目录移动到 /opt,并重命名为:

node_exporter

shell 复制代码
 mv node_exporter-1.2.0.linux-amd64 /opt/node_exporter

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

/opt/node_exporter/node_exporter

3. 把 node_exporter 注册成 systemd 服务

先创建或编辑服务文件:

shell 复制代码
sudo vi /etc/systemd/system/node_exporter.service

当前服务配置如下:

shell 复制代码
[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

接着创建对应系统用户:

shell 复制代码
useradd --no-create-home --shell /bin/false node_exporter

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

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

shell 复制代码
 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

shell 复制代码
vi prometheus.yml

加入当前抓取目标:

shell 复制代码
      - targets: ["localhost:9100"]
        labels:
          app: "node_exporter"

这里使用的是:

localhost:9100

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

修改配置以后重启 Prometheus:

shell 复制代码
systemctl restart prometheus

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

5. 端口停掉以后,抓取会发生什么?

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

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

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

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

node_exporter 9100 正常 → Prometheus 抓取成功。

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

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

执行当前安装命令:

shell 复制代码
sudo curl https://get.cpolar.sh | sh

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

shell 复制代码
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 中的抓取目标改成:

shell 复制代码
      - 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 本身的职责。

相关推荐
汽车网络安全爱好者1 小时前
AI应用(四)之 AI 编程全流程
大数据·人工智能·elasticsearch
PPIO派欧云1 小时前
PPIO沙箱支持接入OpenAI Agents API,一键托管Agent Harness
人工智能
阿里云大数据AI技术1 小时前
千问 APP × 阿里云:MaxCompute 向量检索重构 RAG 数据收录评估链路,一条SQL将性能提速 11 倍
人工智能·阿里云·maxcompute·rag·千问
智慧物业老杨6 小时前
物业数字化落地思考:真正的转型,是底层数据秩序的重构
java·大数据·人工智能·微服务·系统架构
7177779 小时前
中小团队 DevOps 平台选哪家:2026 年主流平台对比与 Gitee 本土化方案解析
人工智能·gitee
武子康9 小时前
小智断网后还能做什么?沿一次唤醒看清设备与服务端的分工
人工智能·llm·agent
西安栈上月明软件科技9 小时前
从 Linux 0.01 到 AI 开源:星图邻的开源实践
人工智能·自然语言处理·架构·开源·fastapi
麻雀飞吧9 小时前
先判断工具用来学习、开发还是执行
人工智能·python
甲维斯10 小时前
ZCode:快来领“免费”3亿tokens和“Git打包服务”
人工智能