PLFM_RADAR：主动雷达扫描系统，揪出平台隐性故障的服务健康检查实践

做平台运维这几年，我最头疼的一类问题就是：服务明明在跑，业务却告诉你连不上；端口明明是通的，监控大屏却一片飘红。这种“看不见摸不着”的模糊状态，逼着我开始折腾PLFM_RADAR这个项目——一套面向平台视角的雷达扫描系统。它不是传统意义上的 APM 或日志监控，而是把自己当成一台主动雷达，周期性扫描平台内所有服务实例的存活状态、端口可用性、协议响应和资源占用，把平台底层那些“隐性故障”提前揪出来。这篇文章我就把它从选型到落地的完整思路、核心代码，以及踩过的坑一次性写清楚，适合正在做微服务治理、平台运维或者自建监控体系的朋友参考。

这套系统我内部跑了快半年，从最初的临时脚本逐步演进成一个小型平台组件。它解决的核心痛点是：在一个服务实例动辄上百的环境里，配置中心、网关、注册中心、日志平台各自管一段，但没有任何一个视角能回答“此刻平台里到底哪些服务实例是真正健康的”。PLFM_RADAR 要做的就是用最轻量的方式扫描、判定、告警，把服务健康状态变成一张随时可查的“雷达图”。

1. 为什么需要一套“平台雷达”：故障看不清的根源

1.1 传统监控的盲区

大多数团队都有监控体系，但拆开看会发现明显的盲区。以我负责的平台为例，我们有三套监控：APM 追踪调用链、Prometheus 采集指标、ELK 收集日志。这三套系统平时的确能发现问题，但都存在一个共同的死角：它们默认服务“已经在运行”，所以只关心服务质量，不主动验证服务实例本身是否存活。

举一个真实场景：某个老服务没有接入注册中心，运维靠一个ps命令和手工维护的端口表确认状态。有一天服务器重启后，服务进程起来了但监听的 IP 变成了 127.0.0.1，外部流量完全无法访问。APM 没有数据，Prometheus 没有任何指标，日志也没报错。如果不是业务反馈，这个问题可能要漂一整天。这种“服务活着但不可达”的状态，恰恰是传统监控最容易漏掉的。

1.2 PLFM_RADAR 给自己的定位

PLFM_RADAR 的定位可以概括成一句话：主动发现平台中的“幽灵服务”和“僵尸端口”。

它是主动式的，不像日志那样被动接收。它定期对平台内所有设备和服务发起探测，像一个不断旋转的雷达波束。它的探测对象不是业务请求，而是基础设施层面的信号：TCP 端口通不通、HTTP 接口返回码是否正常、关键端口是否被非预期进程占用、节点上的资源水位是否接近极限。

这决定了它在架构中的角色很特殊。它不替代 APM、不替代日志、不替代 Prometheus，而是作为它们前面的第一道防线。APM 告诉你接口慢了，PLFM_RADAR 告诉你这个接口对应的服务实例可能已经连不上了。两者配合，故障定位的效率会高很多。

2. 架构设计与技术选型：不做重系统，做快探针

2.1 整体组成

PLFM_RADAR 的架构我前后调整过几版。最早是用 Shell 脚本加nc命令定时跑，后来发现没法处理大量并发扫描、没法保存历史数据，才重整成现在这个结构。

系统分五个模块：调度器、扫描引擎、存储、告警器、可视化端。调度器负责按周期分发扫描任务；扫描引擎是核心，执行具体的探活探测；存储保留每次扫描的快照和变化记录；告警器根据判定规则触发告警；可视化端提供一张总览视图，让值班人员能一眼看到整片“雷达屏幕”上哪些位置出现异常。

模块之间的通信我特意设计得简单。调度器和扫描引擎不搞独立进程间的消息队列，而是通过数据库任务表和进程内状态协作。刚开始用 Celery 折腾过一阵，后来发现这个场景的任务量根本不需要那么重的基建，反而把自己拖进了维护的泥潭。

2.2 选型理由

语言最终选了 Python 3.11，理由很朴素：团队里大多数人能维护，而且 asyncio 对这种大量短连接探测的场景支持很好。不要为了技术炫技引入 Go 或者 Rust，除非你的扫描规模到了每秒上万个端口，否则 Python 完全够用。

各组件选型如下：

这里有个值得说的点：为什么不用现成的监控系统，比如 Zabbix 或者自建 Prometheus 黑盒探针？我用过一段时间的 Prometheusblackbox_exporter，它做单点探活很专业，但在“平台雷达”这个语义下有短板：一是配置分散在目标列表里，不方便做多条件的动态判定；二是它默认从 exporter 所在节点发起探测，无法模拟多个地域视角；三是我需要把扫描结果和内部 CMDB 实例信息做关联，定制改动成本不小。自己写一套 3000 行以内的主动扫描器更符合实际需要。

3. 雷达扫描引擎的实现：从探测到入库存活

3.1 扫描器核心代码

扫描引擎是整个系统的灵魂。我把它拆成两层：探测层和判定层。探测层只干一件事——拿到目标后，并发发起 TCP 连接、HTTP 请求或 ICMP 探测；判定层结合历史数据判断服务是正常、异常、抖动还是恢复。

import asyncio import time from dataclasses import dataclass @dataclass class ProbeTarget: host: str port: int protocol: str # tcp / http / ping path: str = "/" timeout: float = 3.0 expect_code: int = 200 class ProbeResult: __slots__ = ("target", "ok", "latency_ms", "status_code", "message", "ts") def __init__(self, target, ok, latency_ms, status_code, message, ts): self.target = target self.ok = ok self.latency_ms = latency_ms self.status_code = status_code self.message = message self.ts = ts async def probe_tcp(target: ProbeTarget) -> ProbeResult: start = time.perf_counter() try: reader, writer = await asyncio.wait_for( asyncio.open_connection(target.host, target.port), timeout=target.timeout, ) latency = (time.perf_counter() - start) * 1000 writer.close() await writer.wait_closed() return ProbeResult(target, True, latency, 0, "tcp ok", time.time()) except asyncio.TimeoutError: return ProbeResult(target, False, 0, 0, "timeout", time.time()) except OSError as e: return ProbeResult(target, False, 0, 0, f"conn fail: {e}", time.time()) async def probe_http(target: ProbeTarget) -> ProbeResult: import aiohttp start = time.perf_counter() try: async with aiohttp.ClientSession() as session: async with session.get( f"http://{target.host}:{target.port}{target.path}", timeout=aiohttp.ClientTimeout(total=target.timeout), ) as resp: latency = (time.perf_counter() - start) * 1000 ok = resp.status == target.expect_code return ProbeResult(target, ok, latency, resp.status, f"http {resp.status}", time.time()) except Exception as e: return ProbeResult(target, False, 0, 0, f"http error: {e}", time.time()) def build_prober(protocol: str): if protocol == "http": return probe_http return probe_tcp async def run_scan(targets): sem = asyncio.Semaphore(500) # 全局并发控制，实测500适合百级节点 async def guarded(target): async with sem: prober = build_prober(target.protocol) return await prober(target) results = await asyncio.gather(*(guarded(t) for t in targets)) return results

这段代码看起来简单，但有一个细节我特意做了处理：超时时间统一为 3 秒。太短会把慢业务误判为故障，太长会让扫描队列积压。3 秒是我在自己网络环境里压出来的折中值。真实落地时建议根据机房内网 RTT 统计动态调整，后面踩坑部分会细说。

3.2 健康检查策略的设计

探测层返回的是原始信号，真正判断服务是否健康不能只看单次结果。我把判定策略设计成三阶段：

第一阶段的依据是TCP 连通性。只要端口能建立连接，说明进程大概率存在且 socket 在监听。第二个阶段是协议层验证。比如 HTTP 服务要求返回 200，Redis 要求能执行PING得到PONG，MySQL 则用握手包验证端口确实是 MySQL 而不是某个占用了同一端口的无关进程。第三阶段是连续性验证。单次失败不能立即下结论，连续三次失败才把状态置为“故障”，这是防止偶发网络抖动导致告警轰炸的关键。

每种协议都定义成独立探测器，通过很小的适配接口挂在扫描引擎下。这样做的好处是新增一个中间件类型时不需要改扫描主流程，只要新建一个探测函数并注册到协议映射表里。

3.3 数据库表与历史基线

存储层最初只保存当前状态，后来发现不够用。只有当前状态，无法回答“这个服务是刚刚挂的还是一小时前就挂了”，也就无法判断故障影响时间。于是加了历史表。

CREATE TABLE target_items ( id INTEGER PRIMARY KEY AUTOINCREMENT, host TEXT NOT NULL, port INTEGER NOT NULL, protocol TEXT NOT NULL, path TEXT DEFAULT '/', expect_code INTEGER DEFAULT 200, region TEXT DEFAULT 'default', env TEXT DEFAULT 'prod', service_name TEXT, owner TEXT, enabled INTEGER DEFAULT 1, UNIQUE(host, port, protocol) ); CREATE TABLE scan_history ( id INTEGER PRIMARY KEY AUTOINCREMENT, target_id INTEGER NOT NULL, result INTEGER NOT NULL COMMENT '0=OK, 1=FAIL, 2=UNKNOWN', latency_ms REAL, status_code INTEGER, message TEXT, scanned_at DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_target_time (target_id, scanned_at) );

扫描结果不做全量历史堆积，只保留最近 24 小时的明细数据，更久的数据聚合为小时级统计写入scan_summary表。这个设计是从实际教训来的：一开始保留全量明细，跑了三天就有几百万行，SQLite 查询明显变慢，后来改成“明细 24 小时 + 摘要 30 天”的方案才稳定下来。

4. 调度、并发与告警：让雷达转起来而不是转崩

4.1 调度策略

调度是整个系统最容易出问题的地方。扫描任务不是“越频繁越好”，而是要和目标规模匹配。我按服务的重要性分了三个扫描周期：核心网关和数据库每 30 秒扫一次，普通服务每 2 分钟扫一次，边缘的离线任务类服务每 10 分钟扫一次。

APScheduler 配置里有一点容易忽略：默认的BackgroundScheduler是线程池调度，而我里面调用了 async 函数，必须用AsyncIOScheduler才能在同一个事件循环里执行。

from apscheduler.schedulers.asyncio import AsyncIOScheduler scheduler = AsyncIOScheduler() scheduler.add_job( scan_core_services, trigger="interval", seconds=30, id="core_scan", max_instances=1, coalesce=True, ) scheduler.add_job( scan_common_services, trigger="interval", seconds=120, id="common_scan", max_instances=1, coalesce=True, ) scheduler.start()

max_instances=1和coalesce=True这两个必须设，否则扫描还没跑完下一轮又进来了，会积累一堆冗余任务。我曾经没设置，导致高峰期同时跑了十几个扫描协程组，数据库连接池直接被打满。

4.2 并发控制

扫描目标和扫描器之间的网络链路是有上限的，尤其是跨机房的千兆链路。最开始我用一个裸的gather并发跑所有目标，结果千级目标同时发起连接，把交换机端口打出了丢包，连正常业务都受了影响。

后来统一改成信号量限流。前面代码里的asyncio.Semaphore(500)就是干这个的。具体这个值怎么定？我在实验室用 100、200、500、1000 四档做过压测，发现在我们的网络环境下 500 并发既能把扫描周期压进合理区间，又不会引起丢包。不同团队基数不一样，建议从 200 起步，观察扫描任务整体耗时和节点 CPU，再逐步上调，找到一个“临界点下降”的位置——就是并发继续加但整体耗时几乎不变的那个值，这就是网络链路的真实瓶颈。

4.3 告警与去抖

告警模块原本是最简单的，后来花了我最多时间调优。问题集中在误报。第一次上线第二天早上，告警群里刷了 100 多条“服务不可达”，点进去一看全是同一台交换机故障导致的连带性误报，这个还能理解。另一次更离谱，一个服务毫无规律地每隔十几分钟告一次警，查了半天发现是改配置的时候只改了一个节点，另一节点还在用旧参数导致健康检查路径不一致。

告警逻辑最终采用这套状态机模型：

连续 3 次的限制对快速故障不友好，核心服务如果连续 3 次探测失败，相当于至少延迟 10 秒才告警。针对这种情况我额外加了一条快速通道：核心网关连续 2 次失败，且失败原因是connection refused而非timeout，立即告警。因为refused基本说明端口主动关闭了，几乎不可能误报。

告警通道我们用的是飞书机器人 Webhook，消息里带上服务名、IP、端口、失败原因和最近一次成功时延，值班人员不用登录系统就能做初步判断。这里注意不要把 RAW 的异常堆栈直接抛到群里，要转换成人类能读的语言。

5. 可视化与日常使用：雷达图和拓扑我选了哪种

5.1 大屏展示思路

可视化是所有参观这个系统的人第一眼看到的东西。既然叫 PLFM_RADAR，视觉上就得真的像雷达。我用 ECharts 的 radar 图表做了核心视图：每一条轴线代表一类基础设施维度——端口连通性、HTTP 可用性、时延水位、资源余量、协议正确性。服务实例的打分落在这几个维度上，形成一个多边形。

多边形越接近外圈说明服务越健康，出现凹角就说明某个维度异常。这个设计的好处是异常非常显眼。一个服务时延严重超标的时刻，它的多边形会从饱满的六边形变成一个明显凹陷的图形，值班人员扫一眼大屏就能锁定问题方向。

另一个视图是列表模式，表格展示每个目标的上次扫描时间、状态、时延、失败原因、最近告警时间。列表模式不是为了炫，而是为了快速批量操作：把某个云厂商的实例整体纳入扫描、临时屏蔽某些目标、批量调整周期，都靠表格里的筛选和操作按钮完成。

5.2 从页面到排查动作

做可视化一个很容易犯的错误是“只展示，不联动”。我见过很多大屏，红了就只能干看着。PLFM_RADAR 在页面里加了两个联动按钮：一是“一键跳转跳板机”，拿到目标实例的 IP 直接生成登录指令；二是“查看最近 N 次探测原始输出”，打开后能看到每次探测的 TCP 握手耗时、HTTP 响应头、错误信息全文。这两个动作让值班人员从“知道服务挂了”到“开始动手查”的时间大幅缩短。

页面背后是一个很简单的 FastAPI 接口层，查询数据库返回 JSON。前端用 Vue 3 的 Composition API 写了几个组件，其中雷达图组件逻辑也不复杂：拉取最近一次扫描结果，按服务打分后映射到雷达轴。

@app.get("/api/radar/overview") def get_radar_overview(): rows = db.query( """ SELECT t.service_name, round(AVG(CASE WHEN h.result = 0 THEN 100 ELSE 0 END), 2) AS health_score, round(AVG(h.latency_ms), 2) AS avg_latency, t.host, t.port, t.protocol FROM target_items t JOIN scan_history h ON h.target_id = t.id WHERE h.scanned_at >= datetime('now', '-10 minutes') GROUP BY t.service_name """ ) return jsonify([ { "name": r.service_name, "value": [r.health_score, r.avg_latency, r.port_open_rate, r.health_latest], } for r in rows ])

实际上面这段是简化版，真正在跑的逻辑还加了port_open_rate的计算，权重也不一样，但核心思路就是这样：从数据库拉聚合数据，推给前端渲染，不搞复杂的实时推送。

6. 实测中的数据与踩坑记录

6.1 三类最典型的误报

我在调这个系统的过程中，最有价值的产出是一份“误报排查手册”。其中三类误报踩得最深：

第一类是TIME_WAIT 连接导致的端口误判。系统对 TCP 服务做探测时，如果目标端口是一个短连接服务，会在本地产生大量 TIME_WAIT 状态的 socket。后续探测偶发复用同一个四元组，会出现 SYN 不响应甚至 RST，被判定为故障。解决办法有两个：连接探测用随机源端口，以及把本地tcp_tw_reuse打开。别小看这个，我有一阵子每天定点报错，最后抓包才发现是 TIME_WAIT 在捣乱。

第二类是HTTP 探测跟随重定向。aiohttp 默认allow_redirects=True，一个从 HTTP 跳转到 HTTPS 的接口，最终返回 200 看起来很正常。但这样做有隐患：重定向链路本身增加了响应时间，而且一旦重定向目标失效，探测就会误报。后面统一改为allow_redirects=False，判定逻辑改为“状态码为 200 或 3xx 均视为通过”。

第三类是DNS 解析缓存与节点不一致。扫描机缓存的 DNS 记录和实际节点解析结果不一致，导致探测打到旧 IP。这个加了个启动检查任务，每次扫描前把 DNS 缓存清掉，同时失败时重新解析一次再探测。

6.2 性能踩坑：扫描风暴

系统第一次全量上线那天，把整个内网扫描了一遍。当时我没做“预热”概念，上来就全量并发。结果是：网关设备 CPU 冲到 90%，部分网络设备的 CPU 甚至到了 95%，开始丢包，业务侧明显感知到卡顿。那次我差点把系统下线。

复盘之后做了一个预热机制：新接入的目标先放在 “PREVIEW” 状态，不参与落地扫描，只做三次手工探测，确认目标支持这种探测方式后，再进入正式扫描列表。同时对大批量扫描任务设置分片：每次最多扫描 200 个目标，一个目标列表分批执行，批次间隔 5 秒。这个做法后来成了平台的默认规则，新环境接入再也没出现过“压垮网络”的场面。

6.3 实战调参清单

最后把这段时间调出来的参数清单整理一下，方便直接参考。

按这套参数跑下来，整个扫描系统对网络的影响基本可以忽略，我是在一台 4C8G 的虚拟机上加一个 SQLite 库部署的，整机负载平时不超过 10%，扫描一千个目标一圈下来大概 40 多秒。没用任何额外的中间件，运维成本低到几乎为零。

7. 这套方案还能往哪个方向扩展

PLFM_RADAR 当前做到的是“存活探测 + 连通性监控 + 基础告警”。如果你也想在团队中落地类似方案，有几个方向值得继续做深。

一个是接入流量数据做交叉验证。现在的探测是独立于业务的，但很多时候“探测正常”不等同于“业务可用”。如果把扫描结果同网关的真实请求成功率做关联分析，可以进一步降低盲区。比如某个实例探测 TCP 正常但业务成功率持续走低，说明可能是应用内部出问题，这是纯探活探测无法覆盖的。

另一个是把扫描结果作为容量规划的数据源。扫描历史表里长期积累的时延数据和失败数据，可以用来识别那些“长期脆弱”的服务——它们并不是故障，但反复出现高时延、偶发失败。这类服务往往会在流量高峰时先出问题。告警阈值调低捕捉高延迟，再配合资源数据做预测，比单纯看 CPU 水位准确得多。

我自己接下来想试试的方向，是把 PLFM_RADAR 的判定逻辑做成策略引擎：不同业务方用 DSL 描述自己的健康判定标准，或者干脆给每个服务注入一段探活逻辑，由平台统一调度执行。这样平台不只是一个扫描器，而是一套健康验证框架。

如果你也在为“服务到底健不健康”这个问题发愁，我建议先别急着买各种商业监控产品，用一套轻量探针把基础设施和服务的真实状态摸清楚，很多时候问题远比想象中简单，也远比想象中好解决。