企业官网建设流程全解析

Blackbox Exporter + Prometheus：HTTP、TCP、ICMP 探测配置全解析

前言

曾经排查服务故障时，最让人困惑的情况不是监控显示异常，而是监控图表看起来正常，用户却已经打不开网站。CPU 没跑满，内存还有余量，服务器也没宕机，问题究竟在哪里？后来整理监控体系时，我意识到自己过去主要盯着机器和应用内部的指标，却缺少从访问入口出发的一次真实检查。进程活着，不代表域名能解析；端口开着，也不代表 HTTP 请求能够得到预期响应。

于是我给现有的 Prometheus 增加了 Blackbox Exporter。它不是再采集一份 CPU 或内存数据，而是从部署它的位置主动发起 HTTP、TCP、ICMP 等探测，把能否访问、请求耗时和探测结果转换成指标。这样，内部运行状态和外部可达性就能放在一起判断：究竟是业务接口不可用，还是网络链路出了问题。

这篇以 Ubuntu 环境下的二进制安装为例，先完成 Blackbox Exporter 的 systemd 服务部署，再配置 Prometheus 的 HTTP 与 Ping 探测，接着用规则观察连续探测失败的情况，最后通过 cpolar 远程查看 Prometheus。原文示例里有几处会影响启动或抓取的配置错误，我会保留原命令供对照，并逐项给出修正写法，方便照着复现。需要注意，探测结论始终对应探测器所处的网络位置，内网能访问与公网用户能访问是不同的问题，后续应按实际使用场景选择探测位置。

一、先明确监控链路：谁来探测，谁来采集

把监控拆开看更清楚：Blackbox Exporter 在指定主机上向目标发起探测，Prometheus 再定时抓取 Blackbox 返回的结果。网站的 HTTP 2xx、端口的 TCP 连通和 ICMP 可达是不同的检查方式；它们可以同时使用，却不能互相代替。

本教程沿用原文的 Ubuntu 与blackbox_exporter-0.27.0.linux-arm64安装示例。下载前先在目标设备运行uname -m核对 CPU 架构：aarch64对应 ARM64，x86_64通常应选择 AMD64，不能仅因为系统是 Linux 就照搬 ARM64 安装包。

二、Ubuntu 上安装 Blackbox Exporter

2.1 创建目录、上传并解压安装包

先建立工作目录并切换进去。原稿用的是以下两条命令：

mkdir/app

cd/app

通过 Prometheus 官方下载页 选择与 CPU 架构匹配的 Blackbox Exporter 压缩包，再把文件上传至/app；下面的截图对应原文下载与上传过程。

上传的是原文 ARM64 文件时，可以使用以下解压与重命名命令。名称、版本和架构必须与实际下载文件一致。

tar-zxvfblackbox_exporter-0.27.0.linux-arm64.tar.gz

mvblackbox_exporter-0.27.0.linux-arm64 blackbox_exporter

2.2 注册 systemd 服务：原文启动路径需要修正

接下来要让它随系统启动。原稿先进入系统服务目录，再创建blackbox_exporter.service，这一步的意图没有问题，但服务文件里的ExecStart误指向了 Alertmanager。照原样启动，无法得到预期的 Blackbox 探测服务。

cd/usr/lib/systemd/system

vimblackbox_exporter.service

以下是原文服务文件，仅用于定位错误，不要直接作为最终配置使用：

[Unit]Description=https://prometheus.io[Service]Restart=on-failureExecStart=/app/alertmanager--config.file=/app/alertmanager.yml[Install]WantedBy=multi-user.target

正式部署时，推荐在/etc/systemd/system/blackbox_exporter.service创建专用单元，确保执行文件和配置文件都指向 Blackbox Exporter。以下补充示例假设解压目录为/app/blackbox_exporter，其中有blackbox_exporter和blackbox.yml：

[Unit] Description=Prometheus Blackbox Exporter After=network-online.target Wants=network-online.target [Service] Type=simple User=blackbox_exporter Group=blackbox_exporter WorkingDirectory=/app/blackbox_exporter ExecStart=/app/blackbox_exporter/blackbox_exporter --config.file=/app/blackbox_exporter/blackbox.yml --web.listen-address=:9115 Restart=on-failure RestartSec=5 # ICMP 探测在部分 Linux 配置下需要原始套接字权限 AmbientCapabilities=CAP_NET_RAW CapabilityBoundingSet=CAP_NET_RAW NoNewPrivileges=true [Install] WantedBy=multi-user.target

若使用上面的专用用户方案，还应创建无登录权限的系统账号，并确保该账号能读取二进制与配置文件；命令里的系统用户名称应与服务文件一致。

sudouseradd--system--no-create-home--shell/usr/sbin/nologin blackbox_exportersudochown-Rblackbox_exporter:blackbox_exporter /app/blackbox_exportersudochmod+x /app/blackbox_exporter/blackbox_exportersudosystemctl daemon-reloadsudosystemctlenable--nowblackbox_exportersudosystemctl status blackbox_exporter

原文还给出了如下 systemd 命令，予以完整保留；它们只负责重载及启动，并不能弥补服务文件本身写错的问题。

systemctl daemon-reload systemctl start blackbox_exporter.service systemctlenableblackbox_exporter.service

访问http://服务器IP:9115/可检查 Blackbox 服务页面，http://服务器IP:9115/metrics是 Exporter 自身指标，而真正测试目标地址需要访问/probe。可以先在 Blackbox 主机本地验证：

curl-s'http://127.0.0.1:9115/probe?module=http_2xx&target=https://example.com'|grep-E'^probe_success|^probe_duration_seconds'sudojournalctl-ublackbox_exporter-n50--no-pager

probe_success为 1 表示此次探测满足该模块条件，为 0 表示失败。外部网站的可达性取决于探测机实际网络环境；请把示例地址替换为自己有权测试的服务。

三、配置探测模块并接入 Prometheus

3.1 备份并编辑 blackbox.yml

在改配置前先留一份原文件，排查失败时好回退。原文使用了mv blackbox.yml blackbox.yml，源和目标完全一致，实际上没有完成备份。

下面先保留原始命令与完整模块片段，方便和截图对应：

mvblackbox.yml blackbox.ymlviblackbox.yml

modules: http_2xx: prober: http http_post_2xx: prober: http http: method: POST tcp_connect: prober: tcp pop3s_banner: prober: tcp tcp: query_response: - expect:"^+OK"tls:truetls_config: insecure_skip_verify:falsessh_banner: prober: tcp tcp: query_response: - expect:"^SSH-2.0-"irc_banner: prober: tcp tcp: query_response: - send:"NICK prober"- send:"USER prober prober prober :prober"- expect:"PING :([^ ]+)"send:"PONG${1}"- expect:"^:[^ ]+ 001"icmp: prober: icmp icmp: prober: icmp timeout: 5s icmp: preferred_ip_protocol:"ip4"

**配置问题：**原片段的modules下把icmp写了两次。YAML 同级重复键可能被解析器拒绝，也可能覆盖前一个值；而且原稿前面切换到了/usr/lib/systemd/system，直接运行相对路径vi blackbox.yml可能编辑错位置。文件路径必须和服务单元的--config.file相对应。实际使用时可先采用精简且唯一的模块定义：

cd/app/blackbox_exportercpblackbox.yml blackbox.yml.bakviblackbox.yml

modules:http_2xx:prober:httptimeout:5shttp:preferred_ip_protocol:ip4tcp_connect:prober:tcptimeout:5sicmp:prober:icmptimeout:5sicmp:preferred_ip_protocol:ip4

原文中其他 TCP 模块可以按需要继续保留，前提是整个 YAML 结构有效且模块名称唯一。修改后重启并查看状态、日志，不应只凭首页能打开就判断新模块已加载。

systemctl restart blackbox_exporter.service

sudosystemctl status blackbox_exporter --no-pagersudojournalctl-ublackbox_exporter-n50--no-pagercurl-s'http://127.0.0.1:9115/probe?module=icmp&target=127.0.0.1'|grep'^probe_success'

3.2 Prometheus 同时配置 HTTP 和 ICMP 探测

打开 Prometheus 配置文件。编辑前先确认它实际使用的--config.file路径，不同安装方式可能不在同一个目录。

viprometheus.yml

下面是原文两组抓取配置，原样保留。其 HTTP 任务最后的目标标签少写了结尾双下划线：__address应为__address__。另外，示例中的9100通常是 Node Exporter 端口，用它的根路径做 HTTP 检查不能证明业务网站可用；若意图验证指标端点，应明确写/metrics。

- job_name:"http"metrics_path: /probe scrape_interval: 60s params: module:[http_2xx]static_configs: - targets: - http://192.168.50.134:9100/ relabel_configs: - source_labels:[__address__]target_label: __param_target - source_labels:[__param_target]target_label: instance - target_label: __address replacement:192.168.50.134:9115 - job_name:'ping_monitor'metrics_path: /probe params: module:[icmp]static_configs: - targets: - www.baidu.com - www.google.com relabel_configs: - source_labels:[__address__]target_label: __param_target - source_labels:[__param_target]target_label: instance - target_label: __address__ replacement:192.168.50.134:9115

补充：作为 Prometheus 顶层scrape_configs的修正示例。如果原文件已有scrape_configs，只将其中两个 job 合并到该列表，勿重复创建同名顶层配置。目标地址按实际环境替换；192.168.50.134:9115是 Blackbox 所在地址，不是被探测的业务服务地址：

scrape_configs:-job_name:blackbox_httpmetrics_path:/probescrape_interval:60sparams:module:[http_2xx]static_configs:-targets:-https://example.com/-http://192.168.50.134:9100/metricsrelabel_configs:-source_labels:[__address__]target_label:__param_target-source_labels:[__param_target]target_label:instance-target_label:__address__replacement:192.168.50.134:9115-job_name:ping_monitormetrics_path:/probescrape_interval:60sparams:module:[icmp]static_configs:-targets:-192.168.50.134-www.baidu.comrelabel_configs:-source_labels:[__address__]target_label:__param_target-source_labels:[__param_target]target_label:instance-target_label:__address__replacement:192.168.50.134:9115

这里__param_target保存真实探测目标，instance用于在结果中标识目标，最后的__address__则指向执行探测的 Blackbox 实例。若两个组件在同一台主机，可按网络环境调整为本机地址；跨主机需要确保 Prometheus 能连通9115。

3.3 告警规则：连续探测失败比例与单次 Ping 丢包率要区分

有了采集目标，还可以为探测失败配置规则。原文用过去 5 分钟probe_success的平均值来估计失败占比，这个思路适合观察一段时间里的可用性波动，但不能把它解释为某一次 ping 命令发送的数据包丢了多少。

下面完整保留原始告警规则：

groups: - name: icmp-loss-alerts rules: - alert: HighPingLossRate expr:|1- avg_over_time(probe_success{job="ping_monitor"}[5m])>0.5for: 2m labels: severity: warning annotations: summary:"高 Ping 丢包率 (实例: {{$labels.instance }})"description:"目标 {{$labels.instance }} 在过去 5 分钟内的 Ping 丢包率超过 50%（当前丢包率: {{$value| printf\"%.2f\"}}）"

原规则在过去 5 分钟失败探测占比超过 50%，且告警条件继续满足 2 分钟后进入触发状态。若采集周期为 60 秒，一个 5 分钟窗口仅有少量样本；应根据实际 SLA 调整采集间隔、窗口和阈值。还可以新增 HTTP 失败告警：

groups:-name:blackbox-availabilityrules:-alert:BlackboxHTTPProbeFailedexpr:probe_success{job="blackbox_http"}== 0for:2mlabels:severity:warningannotations:summary:"HTTP 探测失败：{{ $labels.instance }}"description:"从 Blackbox 位置访问目标未满足 http_2xx 模块条件。"

如果要真正发送消息，还需要在 Prometheus 的rule_files中加载对应规则文件，并配置向 Alertmanager 发送告警的alerting路由；规则出现在 Prometheus 页面并不自动等于通知已经发出。编辑之后先用promtool校验再重启：

promtool check config /实际路径/prometheus.yml promtool check rules /实际路径/blackbox-alerts.ymlsudosystemctl restart prometheus

原稿中的重启与结果截图继续保留，作为原文演示流程的记录：

systemctl restart prometheus

可以在 Prometheus 的 Targets 页面确认探测任务正常采集，再查询probe_success{job="blackbox_http"}、probe_success{job="ping_monitor"}。当失败时，结合probe_http_status_code、probe_duration_seconds、DNS 和 TLS 相关指标分析，不要只看一个 0 或 1。

四、使用 cpolar 远程查看 Prometheus 监控面板

前面解决的是“服务能不能被探测”，接下来解决“人不在监控机旁边时怎么看结果”。原文使用 cpolar 将 Prometheus 自身的9090页面映射到公网，这与把 Blackbox 的9115接口公开是两回事。

4.1 安装并打开 cpolar 管理页面

以下是原文 Linux 安装命令。执行任何在线安装脚本前，先确认来源并评估所需权限；且管道里的sudo只作用于curl，不自动赋权给右侧的sh，实际安装应参照对应平台的官方指引：

sudocurlhttps://get.cpolar.sh|sh

完成后查看服务运行状态：

sudosystemctl status cpolar

在监控主机本地浏览器打开http://localhost:9200；从同一局域网其他设备访问，则使用http://监控主机IP:9200，前提是管理界面对该地址可达。使用已注册的 cpolar 账号登录。

4.2 创建随机公网地址

登录 Web UI，选择“隧道管理 → 创建隧道”。按原稿填写：隧道名prometheus、协议http、本地地址9090、域名类型“随机域名”、地区China Top。实际填写前应先确认本机 Prometheus 正在监听 9090。

创建成功后，到“状态 → 在线隧道列表”复制分配的公网地址；以可用的 HTTPS 地址访问测试。随机域名可能随服务或套餐策略变化，客户端书签不要假设它永久固定。

4.3 保留固定二级子域名

长期远程查看时，可按账号当前可用套餐和预留规则申请固定二级子域名。原文从“预留”页面选择China Top区域，并将示例名称设为prometheus；名称须以实际申请结果为准。

随后返回本地管理界面，在“隧道管理 → 隧道列表”中找到prometheus隧道并点击“编辑”。

将域名类型改为“二级子域名”，在Sub Domain填写刚保留成功的名称，并保持区域一致，点击更新。

最后在在线隧道列表里查看新地址，并用浏览器测试；固定域名仍依赖账号、隧道与本地服务持续有效，不代表任何情况下都保证在线。

**公网安全提醒：**Prometheus Web UI 可能展示内部主机、标签、监控目标与运维信息。cpolar 提供的是访问通道，不能替代应用级身份认证。建议为隧道或前置代理设置强认证和访问限制；只需本人查看时，也可优先采用受控的私网访问方式，不必将监控页面完全公开。

五、排错与验证清单

遇到无法抓取时，建议按“进程 → 模块 → 探测机网络 → Prometheus 重标记 → 告警规则”逐层检查。服务是否能打开/metrics、/probe是否返回probe_success、Prometheus Targets 是否UP，分别回答不同问题；Targets 为 UP 不代表被监控网站也 UP，要查看probe_success。若 ICMP 单独失败，再检查系统权限以及探测位置对目标是否允许 Ping。

结尾

真正帮我减少监控盲区的，并不是给仪表盘再加几张漂亮图，而是多问了一句：从部署探测器的位置访问目标，到底能不能通？Blackbox Exporter 把这件事变成持续可查的指标，Prometheus 再结合已有的系统数据，才能更快区分“机器没事”和“服务对外不可用”。本篇保留原教程的安装、探测与远程访问步骤，也把容易踩坑的服务文件和 YAML 配置明确纠正。后续是否需要更接近用户实际体验的探测，还应根据业务入口和部署地点继续扩展。