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先确认本篇的两台虚拟机分工。下面是原文演示用的局域网地址不是每位读者都需要照抄的固定参数监控主机Prometheus192.168.42.140。被监控主机Node Exporter192.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]DescriptionNode ExporterDocumentationhttps://github.com/prometheus/node_exporterAfternetwork.target[Service]Usernode_exporterGroupnode_exporterTypesimpleExecStart/opt/node_exporter/node_exporter[Install]WantedBydefault.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 配置。保存配置按原文方式重启 Prometheussystemctl restart prometheus原文截图展示了该监控目标被成功采集的界面。排查时建议进一步在 Prometheus 的 Targets 中检查实际状态并用up{instance192.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{modeidle}[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))*10010for: 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 与规则语法后再重启 Prometheussystemctl 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.ymlviprometheus.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: httpstargets中填写实际域名含非默认端口时也需带端口不要写入https://前缀。以下为单独任务的示意不能与同一目标的旧内网任务重复混淆-job_name:node_exporter_publicscheme: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 展示及更细的告警策略。