最近我在整理团队基础设施的可观测性方案时翻到了一个很小的开源仓库——koala73/worldmonitor。名字很直白worldmonitor 的字面意思就是“世界监控”它解决的是一个很实际的问题从分布在不同地域的探针节点发起主动探测持续检查你的网站、接口、TCP 端口、DNS 解析和 SSL 证书是否真的可用再把结果汇总成可用率、延迟、状态码等指标最终落到状态面板和告警通知里。如果你正在找一套能自托管、不绑定商业 SaaS、又具备多区域拨测能力的监控系统这个项目值得花点时间研究。它适合个人站长、小团队运维、SRE也适合那些对监控数据归属有要求、不想把核心业务状态交给第三方平台的团队。把它部署起来认真跑了一遍之后有些体会值得单独写一写。1. 先搞懂 worldmonitor 的项目定位它到底解决什么问题1.1 传统监控覆盖不到的盲区“外部视角”传统监控一般围绕主机和内部网络展开比如 CPU、内存、磁盘、进程状态。这类监控有一个天然盲区它站在“内部”看问题。网站部署在自家服务器上用户从世界各地访问中间会经过大量网络链路、DNS 解析、CDN 节点、运营商出口。任何一个环节出问题都可能让远端的用户打不开页面但你在机房内部的监控面板上看不到任何异常。worldmonitor 这类工具的思路就完全不同它把探针节点分布到多个网络区域每次探测都模拟一个真实用户访问目标服务。这种模式在监控圈里常被称为“主动拨测”或“外部视角监控”。它不是为了替代内部监控而是补上“内网看不见的那一层”。我举个真实例子某个服务的云负载均衡偶尔故障内部主机的 CPU、内存全正常但拨测会发现某个区域探针返回的可用率已经跌破 90%这才找到真正的用户侧故障。1.2 商业拨测平台虽然好用但为什么我还是选择自建市面上像 UptimeRobot、Pingdom 这类服务确实很成熟免费版也能覆盖基本的网站监控。但对有一定定制需求的团队来说商业平台有几个绕不开的问题免费额度少、探针位置固定、告警渠道不够灵活、数据完全放在第三方。如果团队做的是对数据管控严格的业务把每个服务的健康状态都同步到外部平台本身就很难过内部安全审计。自建 worldmonitor 这类方案最大的好处是数据完全在自己手里。你控制探针部署在哪里你想怎么分组就怎么分组告警可以推到内网的 Webhook 上状态页也可以放到自己域名下。成本上一台 2C4G 的云主机跑服务端再准备两三个廉价的探针节点已经能覆盖绝大多数场景。它不追求大而全但胜在灵活、可控这也是我倾向于把它放进运维工具箱而不是依赖商业平台的原因。1.3 我对这个仓库整体设计的第一印象从工程架构上看koala73/worldmonitor 采用的是典型“中心调度 边缘探针”设计。中央服务端负责配置管理、任务下发、结果收集、告警判断探针端只做一件事按指定间隔发起探测然后把结果上报。这种模型的好处是探针端非常轻量几乎不保存状态节点数量可以做得很大也不会把压力集中在探针侧。和最早的“每台机器装一个完整监控栈”相比这种 server-agent 模型的运维成本要低得多。想要增加一个新的拨测区域只是在一个新节点上跑一个容器注册一下就好。探针安全暴露面也被控制得很小它只需要主动访问目标服务并向服务端回传结果不需要对外开放端口。对安全要求高的团队这种设计能少操不少心。当然这个项目本身未必像大型监控平台那样功能全面但作为拨测场景的专用工具架构上的取舍是合理的。2. 五个核心探测项每个都值得抠细节在讲功能之前先用一张表把 worldmonitor 中常见的探测类型理清楚。不同探测类型监控的目标不一样正确组合使用才能把一个服务的真实可用性看清楚。探测类型监控目标关键指标典型使用场景HTTP(S)网站/接口状态码、响应时间、内容匹配核心业务健康检查TCP任意端口连接是否成功、握手耗时MySQL、Redis、内部中间件ICMP网络链路丢包率、往返延迟机房出口、链路稳定性DNS域名解析解析耗时、返回 IP 是否符合预期域名劫持、DNS 故障定位SSL 证书HTTPS 站点剩余天数、证书链、握手耗时证书过期预警2.1 HTTP(S) 探测别只盯着状态码HTTP(S) 探测是使用频率最高的一种类型。它模拟浏览器向目标 URL 发起请求核心要记录三件事返回的状态码、响应耗时、响应内容。这里最容易犯的错是把“状态码等于 200”当成“服务正常”的唯一标准。实际上很多故障是状态码正常但业务错误。比如后端返回了 200响应体里却是一段“系统繁忙请稍后重试”的 JSON或者某个前端页面加载完是空白。所以在配置 HTTP 探测时我强烈建议同时启用内容校验比如要求响应体必须包含某个关键词例如 ok 或 healthy。如果目标接口是 JSON 格式还可以要求包含特定字段。响应耗时也值得设一个阈值避免慢到不可用的服务仍然被判定为“正常”。2.2 TCP、ICMP 与 DNS网络层故障怎么定位TCP 探测适用于数据库端口、Redis、内部中间件这类不提供 HTTP 服务的对象。它做的事情很简单在规定时间内尝试建立 TCP 连接能连上就认为服务在线连不上就是失败。别看逻辑简单把 SSH22、MySQL3306、Redis6379这类端口纳入拨测往往比只看进程状态更能反映真实可用性。ICMP 探测则偏向网络连通性主要记录丢包率和往返时延适合判断某个机房出口、某条链路是否稳定。DNS 探测用来验证某个域名的解析是否正常可以指定期望返回的 IP 或者要求解析耗时小于阈值。当 HTTP 探测失败时我会优先看同一个探针节点的 DNS 结果和 ICMP 结果这样能快速定位问题到底出在域名解析、网络链路还是服务本身。2.3 SSL 证书监控最容易遗漏的隐形炸弹证书过期是线上故障里最尴尬的一种服务没挂、网络正常但用户浏览器直接报安全错误流量瞬间掉光。worldmonitor 如果支持证书检查建议务必给所有 HTTPS 站点加上。证书监控通常要关注三个指标剩余天数、证书链是否完整、TLS 握手耗时。配置项上我一般把“剩余天数少于 30 天”设成 warn“少于 7 天”设成 crit。这样一个多月前就能收到预警完全不用在半夜处理证书过期事故。注意证书监控和 HTTP 拨测要分开设置因为两者的目标不一样HTTP 看的是服务是否可用证书看的是这个可用状态还能维持多久。2.4 成功/失败判定与告警策略如何减少误报一个探测结果被判定为“失败”在不同类型下含义不同。HTTP 失败可能是 DNS 解析失败、TCP 超时、TLS 握手失败、状态码不符合预期、响应体关键词不匹配TCP 失败可能是端口不可达或超时。这些错误类型在告警信息里都应该明确展示否则排障会非常痛苦。真正减少误报的关键在于引入“连续失败次数”和“恢复次数”两个参数。单次探测失败可能只是网络抖动没必要立刻打扰人连续 3 次失败基本可以确认问题不是偶发。同样恢复通知也不要做了第一次成功探测就发连续成功 2~3 次再触发恢复能避免目标服务反复抖动时告警风暴。2.5 可用率与慢速告警不只是“挂了”才通知很多初级监控只做“在线/离线”两类判断但线上很多问题不是直接挂了而是变慢了。可用率和慢速告警就是为了解决这类问题而存在的。worldmonitor 这类项目会把成功探测次数除以总探测次数换算成可用率再按 5 分钟、1 小时、24 小时聚合。你可以设定一条规则如果最近 30 分钟可用率低于 99%就触发一次“性能预警”。这样做的好处是当某个区域的链路开始劣化但还没有完全断掉时你已经收到了信号而不是等到用户投诉才去排查。3. 从零部署把 worldmonitor 跑起来3.1 部署前先想清楚单机模式还是分布式模式部署之前先做两个决定第一个是模式第二个是资源规格。如果你只是监控三五个个人网站跑单机模式就够了服务端和探针在同一台机器如果监控的目标面向多地域用户或者你需要从多个角度验证业务可用性那就要上分布式模式服务端一台机器探针分布在多个区域。资源规格上服务端 2C4G 起步存储建议挂 PostgreSQL探针节点 1C512M 都行。监控项越多、探测间隔越短数据量越大。50 个 HTTP 监控项、1 分钟间隔一天大概会产生 7.2 万条探测记录保留 90 天不是个小数目所以在部署前就要把数据保留策略想清楚否则跑几个月后库会膨胀得非常快。3.2 服务端部署Docker Compose 一把梭我按常见开源项目的部署套路用 Docker Compose 起一个包含服务端和数据库的完整环境配置如下直接保存为 docker-compose.yml 再 docker compose up -d 即可。注意这里镜像是示例占位实际使用以仓库 README 发布为准。version: 3 services: worldmonitor-server: image: ghcr.io/koala73/worldmonitor:latest container_name: worldmonitor-server ports: - 8080:8080 environment: WM_MODE: server WM_DB_DSN: postgres://wm:wmpostgres:5432/wm WM_DATA_RETENTION_DAYS: 90 WM_PUBLIC_URL: https://wm.example.com volumes: - ./config:/etc/worldmonitor depends_on: - postgres postgres: image: postgres:16-alpine environment: POSTGRES_USER: wm POSTGRES_PASSWORD: wm POSTGRES_DB: wm volumes: - pgdata:/var/lib/postgresql/data volumes: pgdata:启动后打开 8080 端口根据提示初始化管理员账号然后在系统设置里找到服务端 token这个 token 后面探针注册要用。环境变量里最关键的是 WM_DB_DSN数据库连接串如果写错服务会在启动阶段反复报错所以先把 PostgreSQL 起来再起服务端顺序反了容易踩连接失败的坑。3.3 添加第一个监控项设计好你的探测任务进入 Web 面板后建议先创建一个分组用分组区分环境或业务线比如 prod-api、prod-web、内部工具。随后在分组下添加监控项以 HTTP 类型为例名称填“核心业务健康检查”URL 填 https://api.example.com/healthz期望状态码填 200超时时间 10 秒探测间隔 60 秒内容校验关键词可以填 ok。添加完成后等一个完整探测周期点进监控项详情就能看到历史记录、响应时间曲线、各探针节点结果。如果第一轮发现异常不要急着怀疑业务先用同一个探针节点在服务器上手动 curl 一下目标地址排除白名单、防火墙、代理等因素。我自己的习惯是第一天先加 3 个已知正常的站点做对照再加快要监控的业务这样一旦出现大面积误报至少能判断是 worldmonitor 本身的问题还是目标服务的真实故障。3.4 探针节点部署与注册探针节点用 Docker 跑最省事。先在服务端生成一个探针注册 token再按下面方式启动容器。注意 WM_PROBE_REGION 建议用云厂商区域代码那一套命名规范比如 cn-east、cn-south、ap-southeast后面看报表时一目了然。version: 3 services: worldmonitor-probe: image: ghcr.io/koala73/worldmonitor:latest container_name: worldmonitor-probe environment: WM_MODE: probe WM_SERVER_URL: https://wm.example.com WM_PROBE_TOKEN: 替换为注册后生成的token WM_PROBE_REGION: cn-east volumes: - /etc/localtime:/etc/localtime:ro restart: unless-stopped探针部署最容易忽略的是时间同步。如果探针机器的时间和真实时间偏差太大上报结果的时间戳会在统计时错位导致可用率出现莫名其妙的误差。所以生产环境一定要保证宿主机启用了 NTP 服务或者至少在容器里挂载 /etc/localtime。3.5 接入通知渠道告警通知建议第一步先接 Webhook因为它的兼容性最好飞书、钉钉、企业微信机器人本质上都是 Webhook内部自研系统也可以直接拿 JSON 解析使用。在告警规则里新建一条规则指定匹配的监控项分组和通知渠道触发条件设为连续失败 3 次保存即可。一个比较实用的 Webhook payload 示意如下建议配置时确认你的接收端能解析这些字段{ event: monitor.failed, monitor_name: api.example.com, region: cn-east, error: http_status:502, latency_ms: 235, consecutive_failures: 3, last_success_at: 2025-04-01T10:23:00Z }Webhook 地址是敏感信息别写死在代码仓库里。我用环境变量注入或者通过配置中心的密钥管理功能下发最大程度避免内部通知入口泄露。4. 落地中常见的坑和排查方法4.1 同一个目标不同探针结果不一致这是分布式拨测最常遇到的问题。同一个 URLA 探针显示正常B 探针显示超时或 5xx第一反应先不要慌这通常不是系统 bug而是网络路径差异。排查思路按这四步走先看失败探针返回的错误类型是 DNS、connect、timeout 还是 http_status然后在失败探针所在机器上手动 curl 一次目标地址验证能否复现接着检查目标服务是否有按来源 IP 做限流、WAF 封禁或地域白名单最后如果是经过 CDN 的服务还要回到源站看回源日志。多数情况下问题会落在“探针 IP 被策略拦截”或“CDN 边缘节点异常”这两类里。4.2 频繁误报网站明明活着探针却说挂了误报是拨测系统落地初期最伤信任感的问题。第一周如果误报率太高运营和开发同事很快会不再看告警之后再真实的告警也会被忽略。误报的常见原因和解决办法比较固定。最常见的来源是探测目标对主动巡检不够友好。比如健康检查路径被强制跳转到登录页探针收到 302 后认为状态码不对判定失败或者目标的 WAF 把高频探测当成了扫描攻击直接 403 拦截。处理办法通常是给探针 IP 加白名单URL 用专门的健康检查接口配置时将状态码校验范围放宽。我还会把“连续失败次数”从 1 改成 3牺牲一点发现速度换取告警质量长期看更划算。我个人的经验是误报的比例决定了告警系统能不能活下来。宁可晚两分钟发现故障也不要半夜被 10 条假告警吵醒。4.3 数据膨胀与存储压力拨测数据是一份“高频时序型”数据增长很快。50 个监控项、1 分钟间隔、保留 90 天存储不规划的话很容易出问题。部署一段时间后如果发现数据库体积已经顶到磁盘优先调整这几个地方延长探测间隔、缩短保留天数、关闭历史原始响应体的保存。如果项目支持把历史明细导出到对象存储可以做冷热分层。热数据保留最近 7 天用于快速排障30 天以上的明细归档只在需要审计时查询。日常聚合用的可用率统计数据保留一年都没问题单条记录很小查询也快。4.4 受限网络下的探针部署有些团队会把探针节点放在办公网或内网段用来监控只允许内网访问的系统。这类环境往往会卡在代理和防火墙。探针要访问两个目标一个是服务端地址一个是监控目标地址。如果探针只对上 443 出方向访问走 HTTP 的服务倒没问题但被监控的中间件端口如 3306、6379 不在白名单里TCP 探测就会失败。解决方法是给探针配置一个特例业务拨测目标的内网端口需要纳入防火墙放行清单若办公网强制 HTTP 代理需要给探针配置代理变量。我的经验是内网拨测最好单独用一批探针不要和外网拨测探针混用否则一个环境策略就会导致整片监控告警失真。4.5 多探针并发探测导致的时间与统计偏差当多个探针同时探测同一个目标调度时间如果没有做随机化会在某一瞬间形成突刺。比如每个探针都固定在每分钟的第 0 秒发起请求目标服务可能在同一秒被打出一堆并发这个压力在业务高峰时会额外放大接口延迟最后监控数据反而干扰真实指标。处理方案是给每个任务分配一个随机偏移量。worldmonitor 这类设计如果支持 jitter就把它打开比如允许每个探针在 0 到 15 秒内随机选择发起时间。统计时则以探测结果的时间戳为准而不是探针上报到服务端的时间这样才能避免跨区域网络延迟导致的数据归错分钟。5. 会玩之后worldmonitor 的三种进阶玩法5.1 把拨测指标接入 Prometheus 与 Grafanaworldmonitor 的默认面板已经能解决日常查看但如果你已经有 Prometheus Grafana 这套监控体系再把拨测指标接进去会更统一。很多这类项目会暴露 /metrics 端点Prometheus 配置一个 scrape 任务就能在 Grafana 里看到按区域聚合的探测成功率和延迟分位数。做到这一步优势很明显告警可以统一走 Alertmanager历史指标可以和业务指标做关联分析。比如某次发版后可用率下降了 0.5%在 Grafana 里把探针可用率曲线和业务日志曲线叠在一起能很快找到关联。5.2 对外搭建一个规范的状态页拨测数据除了给自己看也可以做成对外状态页。客户访问状态页能直接看到各服务的当前状态、过去 90 天可用率、最近事件记录。一个稳定的对外状态页是技术团队专业度的体现也能减少客服重复回答的压力。搭建时注意脱敏对外页面只需要显示服务名、状态颜色、最近可用率不要暴露探针区域、内部告警阈值、源站 IP 这些细节。状态页建议挂在独立域名或子域名下避免主站挂掉时连状态页也打不开那就失去了展示的意义。5.3 接入发布流程把拨测当上线门禁拨测系统最进阶的用法是把它接入发布流水线。发布新版本时自动创建一个指向新版本灰度地址的临时监控项探测频率提高到 15 秒等待 5 分钟后检查可用率和响应时间。如果不达标流水线直接中止触发回滚。这个场景我实际用下来体验很好。它把“上线后用户会不会出问题”这种模糊问题变成了“新版本健康检查是否通过”的明确门禁。发布不再只靠测试用例而是增加了生产环境真实流量的外部验证。运行一段时间后可以沉淀出一份“上线前拨测清单”每次发版都执行一遍团队的整体信心会提升不少。最后说一点我自己的体会。我刚开始用拨测工具时最大的误区是把监控想得太简单以为挂上 URL、配好状态码就完事了。实际上拨测的成败在于对“成功”的定义是否准确状态码只是其中一环。koala73/worldmonitor 这个项目不算大但它把主动拨测的常见环节都覆盖了部署简单、思路清晰很适合作为团队的第一套外部视角监控。如果你也在考虑搭建类似能力我建议从最核心的业务接口开始先跑通一条链路拿到真实数据后再逐步扩充节点和规则别一上来就追求大而全。监控的价值从来不在面板有多漂亮而在于它能不能在用户发现问题之前先帮你发现问题。