如果你手上同时维护着好几套内部业务系统，你大概率体会过这种尴尬：业务方比你先发现问题，你打开监控面板一看，基础设施的指标全是绿的，机器没宕、网络没断、数据库连接正常，但用户就是告诉你"订单状态不对"。

PLFM是我们内部业务中台的代号，承载了用户权限、订单流转、消息推送、对账任务一大堆模块，部署在多个环境里。模块一多，真正的告警盲区根本不在机器层，而在"业务流程层"：队列堵了、回调没到、批处理任务卡死、下游接口变慢，这些事看传统监控是看不出来的。为了治这个问题，我做了PLFM_RADAR——一套借鉴雷达工作方式的平台巡检与异常感知系统。雷达这个名字不是噱头，它提炼了三个关键词：主动探测、周期扫描、锁定异常信号。

这篇文章就聊聊PLFM_RADAR从设计到落地的完整过程：我为什么不用现成监控平台非要自己写、巡检项怎么分级、状态机怎么推、告警怎么降噪，以及上线后踩过的坑和排查实录。适合正在做内部系统建设、SRE、运维平台的读者参考，尤其是那些被"监控很全但然并卵"折磨过的人。

1. 先想清楚PLFM_RADAR到底解决什么问题

1.1 需求拆解：监控盲区到底在哪

启动这个项目之前，我花了三天时间梳理PLFM现有的监控体系，结论是基础设施层面确实不缺东西：CPU、内存、磁盘、网络、中间件都有采集，也有大屏面板。但问题恰恰在基础设施监控覆盖不到的地方，我整理了三个场景：

第一个场景，链路中间某个环节悄悄坏了。比如用户创建订单后，系统要推送消息给下游仓储，推送服务本身没问题，但对应的延迟队列因为配置错误一直没有被消费。从指标上看，消息队列的连接正常、吞吐正常，可业务数据已经堆积了好几个小时，用户端的表现就是"下单后迟迟没人处理"。

第二个场景，批处理任务跑飞了。对账任务每天早上五点跑，某天凌晨数据库一个死锁导致任务中断，后面重试逻辑又没触发。这个任务没有独立的指标监控，要不是业务方中午问起来，根本没人知道对账停了。

第三个场景，次要模块拖累核心链路。一个内部工单系统的附件服务响应很慢，偶尔超时，但它不影响主流程，传统监控按服务维度报警会直接忽略这种"慢而不挂"的问题，可它实实在在影响了下游重试队列的积压。

PLFM_RADAR的核心诉求就是补上这个空白：定期主动去探测业务层的真实状态，而不是被动等着基础指标报警。具体拆成三件事——定时扫、异常分级、通知到人。所谓定时扫，就是周期性对每个注册的巡检目标执行探活；异常分级，就是把故障分成"已经影响核心"和"还在容忍范围"；通知到人，是告警必须精准触达对应的负责人，不能发到一个没人看的群里就算完。

1.2 方案选型：为什么叫"雷达"而不是"日志平台"

刚开始我也想过直接用现成的日志平台或指标平台，但很快发现不对劲。日志平台是"被动等数据"——你先得把日志采集上来、做解析、写查询，业务方没打日志的地方你照样看不见；指标平台是"看趋势"——适合cpu、内存这种连续型数据，但"对账任务是否成功执行"这类布尔型业务状态根本无从采样。

雷达的工作方式给了我很直接的启发。雷达不是等着目标自己暴露，而是主动发射脉冲、监听回波，根据回波的位置和强度判断有没有目标、目标是什么。PLFM_RADAR也一样：不管业务方有没有打日志，我都主动去请求关键接口、检查心跳、验证链路，用返回的结果反推系统是否健康。

选型上我也没有引入重框架，就用Python加Celery做定时调度，探针以注册式插件的方式维护，数据落库用MySQL。这个选择是故意的：PLFM内部的生态就是MySQL和Python，团队维护成本低，不引入独立大数据组件，也不要求业务方做任何埋点改造。整个系统部署为两个服务——调度服务和执行服务，一个负责按策略触发巡检任务，一个负责跑探针、推导状态、发通知。

这套方案最大的好处是轻量和非侵入。业务团队不需要改代码、不需要接SDK，只需要按照约定提供一个健康检查接口或者上报心跳，或者干脆什么都不做，由RADAR主动去探测它依赖的下游服务。对于已经有几十个模块的中台系统来说，这个"谁都别改，我来摸你"的思路，落地阻力是最小的。

2. 系统设计：几个关键决策背后的理由

2.1 巡检项怎么定义，分级为什么重要

巡检项是PLFM_RADAR的基本单位，设计上参考了监控领域的"探针"概念：一个巡检项代表"我要用哪种方式去验证哪个目标"。实际落地中我把它做成了注册表的形式，每一条记录定义四件事：目标ID、目标类型、探测方式、检查参数。

目标类型在PLFM里主要分三类：HTTP服务、内部依赖（Redis、MySQL、MQ）、定时任务。针对HTTP服务，探活方式是请求指定URL并校验状态码和响应体关键字；针对内部依赖，就是做一个轻量级的连通性和读写检查；针对定时任务，靠的是业务方上报的任务执行心跳。这三类基本覆盖了中台系统90%的巡检需求，后面的实现章节会详细说。

分级是我做的最重要的一个决定。如果没有分级，就会陷入经典的告警困境：所有异常同等重要，等于所有异常都不重要。我用P0和P1两个级别来切分。

• P0：直接阻断了核心业务流程的巡检项，比如"订单创建接口可用性""支付回调接收成功率"。P0故障必须立即触发告警，分钟级处理。
• P1：属于次要链路或慢性问题，比如"附件上传接口响应时间""内部报表生成任务是否如期执行"。P1故障先记录、聚合，按严重程度决定是否升级。

为什么要分级？因为不同级别的巡检对频率和容忍度的要求完全不同。核心接口一分钟探测一次都不过分，但一个内部报表任务你五分钟看一次就足够了；核心接口超时一秒可能已经影响体验，次要任务延迟十分钟也还能接受。把级别和参数绑定，整个系统的行为才能自洽。后面讲参数定制的部分，我会给出具体数值和推导过程。

2.2 健康评级与状态机的推导逻辑

定义完巡检项，下一步是把每个目标的状态收敛成对外可读的评级。PLFM_RADAR用四个状态：NORMAL、DEGRADED、FAULT、UNKNOWN。

状态机是整个系统的核心判断逻辑，我把它设计成"基于最近连续N次巡检结果"而不是"基于单次巡检结果"。这个设计是为了消除抖动。举个例子，一个HTTP接口偶尔单次超时，但重试一下就好了，如果单次失败就立刻标记FAULT并告警，那系统每天会被自己的探针误报埋掉。

我用一个"确认窗口"来解决：目标从NORMAL切换到FAULT，必须连续三次巡检都失败才确认；反过来，从FAULT恢复到NORMAL，也要连续两次成功才解除告警。窗口机制的本质是给状态变化加了迟滞，像雷达锁定目标一样，不是看到一次回波就认定目标存在，而是多次回波一致才确认锁定。

随之而来的一个问题是UNKNOWN怎么处理。心跳超时是最容易误判的场景——业务服务可能只是网络分区，或者机器被重启了，探针暂时连不上。PLFM_RADAR的做法是单独维护一个"最后心跳时间"，超过阈值就标记UNKNOWN并触发告警，但UNKNOWN不会清理历史状态记录，等心跳恢复后自动回到正常逻辑。这样避免了服务重启期间一连串的假故障告警。

2.3 告警汇聚与降噪机制

告警本质上是给人看的信息，如果每天推一百条消息，人很快就麻木了。PLFM_RADAR的告警模块做了四层降噪处理，这一块直接决定了系统上线后大家有没有耐心看它。

第一层是冷却窗口。同一个目标、同一个级别、同一个状态，在冷却时间内不重复推送。P0的冷却窗口我设成10分钟，P1设成30分钟，意思是即便目标一直处于FAULT，也不会每分钟刷屏，而是每10分钟确认一次状态没恢复，然后静默。恢复的时候必须推送一条"恢复通知"，让人知道事情结束了。

第二层是连续确认，这个在状态机里已实现，目的是不让单次瞬时失败触发告警。第三层是消息聚合，如果短时间内多个目标同时异常，不单发，而是汇聚成一条"故障概览"，按P0优先排序列出所有受影响的目标和异常摘要。

第四层是升级机制。P1异常如果持续超过一定时间（例如30分钟），会升级成P0告警推送到更高级别的负责人。这解决了"小事没人及时处理，最后变成大事"的经典运维困境。所有告警都会写入告警历史表，支持后续排查问题时间线，这个表也是后面讲可观测性扩展的重要数据来源。

3. 核心实现：从任务调度到消息通知

3.1 数据采集：探针与心跳

PLFM_RADAR的数据采集端有两类探针：主动探针和被动上报。

主动探针最常用的是HTTP探针。代码里维护了一个探针执行器，接收目标ID和URL参数，发起请求后校验三样东西：HTTP状态码是否在200到399之间、响应时间是否超过预设阈值、响应体里是否包含期望的关键字。校验关键字这个点在PLFM里很有用，因为有些网关对下游请求会直接返回200但带着错误码，只看状态码会误判健康。

被动上报对应的是心跳探针。PLFM中有一部分定时任务不方便对外提供HTTP接口，它们的特点是每天/每小时跑一次，跑完就结束。对这种目标，我让定时任务在执行结束时向RADAR上报一个心跳，上报接口就两件事：更新目标ID对应的最新心跳时间，写入一条心跳记录。RADAR侧则定时扫描心跳表，凡是超过心跳阈值没上报的目标，直接判定UNKNOWN。

心跳表结构设计得比较轻，核心字段是target_id、last_seen、created_at，其中last_seen用一个BIGINT存Unix毫秒时间戳。实际建表SQL大致是这个样子：

CREATE TABLE radar_heartbeat ( id BIGINT AUTO_INCREMENT PRIMARY KEY, target_id VARCHAR(64) NOT NULL, last_seen BIGINT NOT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_target_last (target_id, last_seen) );

数据采集还有一个容易忽略的点：探针执行本身要设超时和并发限制。HTTP请求必须有一个上限时间，默认设P0巡检周期三分之一，超时就按失败处理。如果不设超时，探针可能卡在下游服务的连接上，消耗执行线程，导致后面排队任务大量堆积。并发方面用信号量限制同时执行的探针数量，避免巡检高峰把执行服务的CPU打满。

3.2 状态推导与快照存储

每轮巡检结束后，系统会把每个目标的原始检查结果归一化成统一格式，再交给状态机做推导。归一化字段包括：目标ID、检查项名称、级别、是否通过、耗时、异常描述、检查时间。这些检查结果先写入一张检查记录表，然后跑状态推导任务。

状态推导的核心逻辑用Python写并不复杂，关键是先分组再基于组内结果做判定：

def derive_state(target_id, checks): p0_results = [c for c in checks if c['level'] == 'P0'] p1_results = [c for c in checks if c['level'] == 'P1'] if not p0_results and not p1_results: return 'UNKNOWN' if any(c['ok'] is False for c in p0_results): return 'FAULT' if any(c['ok'] is False for c in p1_results): return 'DEGRADED' return 'NORMAL'

实际工程里当然不是每次都从头跑，而是配合上一节说的确认窗口做状态跃迁。我在状态表里维护了每个目标的当前状态、状态副本计数和一个状态副本数组，数组里存最近N次（P0是3次、P1是2次）的推导结果。当前三次结果全是FAULT，才把对外状态从NORMAL切到FAULT，同时记一条状态变更记录，带上"从哪个状态变为哪个状态、触发原因的摘要、首次异常时间、确认异常时间"。

快照存储用的表叫radar_snapshot，存的是每个目标在当前时间点的最终状态，包含目标ID、状态、状态变更时间、最近一次巡检时间、最近一次异常摘要。这个表的作用是给查询方提供"当前所有目标都是什么状态"的全局视图，仪表盘直接查这张表就行，不需要在每次展示时重新算所有巡检结果。快照表每天做一次全量更新，同时在每次状态发生跃迁时实时更新。

存储策略上我做了两个取舍：检查记录表保留最近7天，用于排查细节；快照表保留最近30天，用于看趋势和生成周报；更早的数据通过汇总任务压缩成天级聚合。不控制存储的话，以每分钟一个P0巡检项产出一条记录的速度，三个月后MySQL单表就会膨胀到影响写入性能。

3.3 告警触发与通知模板

告警触发依赖Celery的定时调度。我用了两套周期任务，一套跑P0探针，一套跑P1探针，这样即使P1任务执行时间较长，也不会拖慢P0关键的巡检节奏。

CELERY_BEAT_SCHEDULE = { 'radar-p0-scan': { 'task': 'radar.tasks.p0_scan', 'schedule': crontab(minute='*/1'), }, 'radar-p1-scan': { 'task': 'radar.tasks.p1_scan', 'schedule': crontab(minute='*/5'), }, 'radar-heartbeat-scan': { 'task': 'radar.tasks.heartbeat_scan', 'schedule': crontab(minute='*/1'), }, }

调度任务本身不直接发告警，它只负责执行探针、落检查记录、触发状态推导。告警发送在状态推导完成后统一走一个事件总线：如果状态机判定发生了状态跃迁（正常转故障、故障转恢复、升级），就往告警队列里推一条事件，由notifier消费事件并发送通知。

通知模板我做了格式化，不过度堆砌字段，保证一条告警的信息密度足够高。P0故障通知大概是这样的：

【PLFM_RADAR】P0故障告警 目标：订单服务-创建接口 异常项：HTTP探针连续3次失败，最近一次响应500 首次异常：2025-01-10 10:23:30 持续时间：3分钟 影响范围：用户端下单主流程 建议动作：检查订单服务的数据库连接池并确认最近一次发布

恢复通知长这样：

【PLFM_RADAR】P0故障恢复 目标：订单服务-创建接口 恢复时间：2025-01-10 10:31:15 故障时长：7分45秒

告警事件里有一个关键字段event_key，由目标ID加状态加首次异常时间戳拼成。每次发送前先查告警历史表，存在相同event_key且未恢复的事件就不重复发送。这就保证了即便Celery任务因某些原因重复执行，也不会产生重复告警，属于发送侧的幂等控制。

3.4 关键参数怎么定

参数是PLFM_RADAR上线后调整最频繁的部分，我给出当前在跑的参数和确定它们时的推导思路，方便你直接抄作业或者按自己的场景调整。

这里多说一句确认次数的计算逻辑。确认窗口的长度等于巡检周期乘以确认次数，核心是想清楚一个公式：从故障实际发生到RADAR发出告警，最坏情况是巡检周期乘以确认次数，再加上调度延迟。P0场景下就是1分钟乘以3次，约3分钟告警，这个延迟对核心链路来说是可以接受的。如果把确认次数设成5，延迟就变成5分钟，用户体验可能已经明显受损了；设成1又会被抖动坑死。3是反复调出来的平衡点。

4. 常见问题与排查技巧实录

4.1 误报风暴

上线第一周我收到最多的问题就是误报。最典型的场景是服务发生了一次短暂的GC停顿，接口响应超过3秒，探针判定失败。但服务本身很快就恢复了，业务方吐槽"你们这东西怎么一天到晚狼来了"。

排查后发现两个原因：一是探针的超时设置太敏感，3秒对某些低频批量接口来说本身就偏短；二是当时确认窗口设的是2次，等于最多两分钟就确认故障，抖动很容易穿透。解决办法分两步：把P1接口的探针超时从3秒调到5秒，P0保持3秒不动；确认次数也从2改成3。同时给探针加了重试机制——第一次失败后1秒内重探一次，第二次仍失败才记入失败结果。重试本质上是把网络层偶发S包导致的失败过滤掉，效果立竿见影，误报量下降了大概七成。

4.2 状态抖动

状态抖动和误报不一样，它指的是目标状态在NORMAL和DEGRADED之间来回跳，导致告警和恢复通知交替出现。这个问题的根子在于状态跃迁时只看"当前一次"的结果，而不是看一段窗口内的趋势。

举个例子，一个报表生成任务偶尔运行超过预期时长，心跳还是准时报的，但P1探针连续两次检测到运行时长异常，状态变成DEGRADED；下一次运行又恢复正常，状态立刻变回NORMAL。结果业务方一会儿收到异常、一会儿收到恢复，比不监控还烦。

解决方式是把我前面提到的状态副本数组用起来，真正的对外状态只根据最近N次的稳定结论变更，单次异常只记录不跃迁。具体实现时我维护了一个长度为确认次数的环形队列，队列里全是异常才跃迁。这样做会损失一点告警的实时性，但换来的稳定性值得。

4.3 告警延迟与任务堆积

Celery Beat本身有一个问题：它默认的调度精度依赖节点本地时间，如果执行节点时钟漂移，或者上一批任务还没跑完导致下一批任务排队，告警就会延迟。我在上线后的第二个月遇到过这种情况——P0巡检任务排队堆积到将近10分钟，等于核心故障接近13分钟才被感知。

排查流程是先看任务执行时长和worker并发数。P0和P1共用一组worker时，P1的大量探针会把worker占满，P0任务只能排队。优化方案是给P0开独立队列和独立worker，P1任务再怎么样也不能抢P0的交付SLA。同时给每个探针执行器加了一个最大执行时长限制，超过就杀掉当前协程并记录"探针超时熔断"，防止单次卡死传染整批任务。另外，Celery任务都设计成幂等的，即便调度偶发重复执行，也不会产生重复告警或重复写入状态变更记录。

4.4 通知丢失与数据存储的取舍

告警通知依赖企业IM的Webhook，这个通道本身是不可靠的。我踩过的坑是Webhook因为群人数或频率限制被限流，导致大故障时告警发不出去。处理方案是做了双通道降级：主通道发企业IM机器人，发送失败时降级到邮件通知，同时落一条失败记录到本地文件，方便事后补查。通知服务自身还有一个成功率的自检指标，连续5次发送失败会自动把告警通道切到备用的邮件通道。

数据存储方面，前面说过的检查记录表和快照表如果不做裁剪，磁盘会持续增长。我现在的策略是按级别差异化保留：P0检查记录保留30天，因为核心故障需要较长周期回溯；P1保留7天，超过就清理；快照表保留90天，用于季度趋势分析；心跳记录只保留48小时，因为它的作用就是判断当前是否存活，历史心跳价值有限。另外备份任务每周把检查记录和快照导出一份到冷存储，双重保险。

这里我整理了一张速查表，方便你遇到类似问题时快速定位：

5. 运维自省与后续扩展

5.1 让雷达系统本身可观测

做一个监控系统，最尴尬的是它自己挂了还没人知道。PLFM_RADAR上线稳定后，我开始给系统本身做自监控，思路是"巡检的巡检"。

调度服务每执行一轮任务都会记录三个指标：本轮任务总数、实际完成数、平均执行耗时，数据落在一张自检统计表里。额外用定时任务每分钟检查一下这张表的更新时间，如果超过5分钟没有更新，说明调度服务可能卡死或挂了，会直接触发一个外部拨测通道——用一个独立的轻量脚本从另外一台机器请求RADAR的健康接口，连续失败两次就发备用告警。这一步保证了雷达本身的"心跳"也是被盯着的。

执行服务这边重点监控探针超时熔断的触发次数。熔断次数异常增加往往意味着某个下游服务已经处于半死状态，这时候与其盯着巡检结果，不如直接检查熔断器是不是大范围降级了。我把熔断事件单独建了一张表，每个探针在超时熔断时会把目标ID、耗时和执行现场记录下来，排查问题时会方便很多。

5.2 后续可以怎么扩展

PLFM_RADAR目前在公司内部承担着平台巡检和故障感知的角色，但它的架构上预留了几个明显可以继续长的方向。

第一个方向是自动处置。目前告警推给业务负责人后，恢复动作靠人完成。下一步可以在告警事件上挂"处置动作模板"，比如检测到消息队列积压时自动调用重试接口，检测到定时任务卡死时自动重启任务。这个方向的价值很大，但前提是处置动作要足够保守，我倾向于先做"只读诊断"和信息关联，自动操作留到灰度验证充分后再说。

第二个方向是资产生命周期管理。巡检目标目前靠人工维护，新增模块或者下线服务时，注册表可能忘记同步。可以加一个自动探测的辅助逻辑，定期扫描注册表里的目标是否存在，连续多天无探活结果且无心跳的，自动标记为"废弃"并通知负责人确认。这能避免大量僵尸目标长期占用巡检资源。

第三个方向是告警数据驱动流程优化。快照表和告警历史其实是很好的故障复盘数据源，按目标维度统计P0故障次数、平均恢复时长、告警响应时长，能直接反映平台里哪些模块问题最多、哪些告警渠道最靠谱。把这个数据做成月度报告，本质上就是一份定量的平台稳定性运营报表。

我个人做完PLFM_RADAR最大的感受不是代码量多少，而是把"什么值得告警"这件事想清楚了。雷达扫得再勤，如果报的都是没用的东西，人就会把注意力挪开；真正有用的系统要做的不是把每一丝异常都放大，而是帮你在风暴来临前提前把伞打好。这套系统上线至今，PLFM平台的核心链路故障从发现到触达负责人，平均时间稳定在3到5分钟以内，比过去业务方自己发现再层层反馈小半天起步，已经不是同一个量级。如果你也在折腾内部平台的巡检体系，希望这篇文章里关于分级、状态机、降噪和参数推导的思路，能帮你少踩几个我踩过的坑。