用雷达图统一平台监控：PLFM_RADAR实践复盘-北京尧图网络

一个内部工具项目的复盘PLFM_RADAR把平台监控做成一张雷达图先交代一下背景PLFM_RADAR 是我小团队里维护了大半年的一个内部监控项目PLFM 就是 Platform 的缩写RADAR 取的是“雷达”的语义——不是做无线射频探测而是用雷达扫描的方式去盯平台上的各种服务、接口、数据库、中间件。说白了就是把平时散落在 Prometheus、日志系统、云控制台里的零碎指标收拢到一个统一视图里服务一出问题不用再去十几个页面里翻排查雷达图上直接能看出哪个方向亮红灯。这个项目解决的本质问题很朴素中小团队没有专职的 SRE服务一多告警又散又乱真要出事了你连“先看哪块”都不知道。PLFM_RADAR 把平台状态画成了一圈一层的雷达样式每个方向代表一类服务每个圈层代表指标健康度点进去又能下钻到具体实例、SQL 慢查询、容器资源水位。适合正在从“手工看监控”往“平台化监控”过渡的团队参考也适合那些已经上了 Prometheus 但告警体验很差的同学拿去改造。下面我会从设计思路、指标选型、实际搭建、踩坑记录四个方向完整拆一遍最后附上我对这套东西边界的一些判断。全程不绕弯子能直接抄作业的地方我就把配置放出来。1. 需求拆解为什么用雷达形态收敛平台监控1.1 团队监控的三个真实痛点我们团队属于典型的“业务研发兼运维”——后端、前端、数据、测试加起来三四十人线上环境包括十几个微服务、两套 MySQL 集群、一主两从的 Redis、三个消息队列 Topic、若干定时任务和对象存储桶。监控体系是有的但痛点很具体第一个痛点是指标分散。服务层用 Prometheus Grafana 看数据库有单独的云监控控制台定时任务有自己的日志系统业务埋点在另一个数据平台。每次线上异常第一件事不是修而是先开会定位“去哪看”。这个时间成本非常高哪怕每次只花三五分钟一天出五次问题一个研发半天就没了。第二个痛点是告警与排查脱节。Prometheus 的 Alertmanager 确实能发告警但我们接的是企业微信机器人告警内容就是一串 PromQL 表达式和当前值。阈值超了你只知道“Redis 内存超了”但到底是哪个 key 导致的内存增长、哪个服务在疯狂写入你还是得手动开终端查。告警只说“病了”不说“病灶”。第三个痛点是缺乏整体态势。单块指标再健康不代表平台整体没问题。有一次我们的消息队列消费者全部阻塞但所有 Grafana 面板看过去都是绿的因为每个面板都在分别展示 CPU、内存、QPS没有人把“积压量”和“消费者存活”关联起来看。PLFM_RADAR 最初就是想解决这个“只见树木、不见森林”的问题。1.2 雷达形态的取舍逻辑为什么选择雷达图而不是继续堆叠 Grafana 的 Rows雷达图在数据可视化里是个比较受争议的形式——它不适合精细读数因为人对角度的感知不如对长度敏感。但它有一个不可替代的优势天然适合多维度的“同时比较”。一圈一圈的网格线代表阈值层级一根根轴线代表不同监控域你扫一眼就能看到哪条轴线冲到圈外了哪条轴线塌陷了这就是雷达图的核心价值场景。PLFM_RADAR 的设计是“雷达总览下钻详情”两层结构。第一层只放七个维度覆盖平台最核心的七个方向服务健康度、接口延迟、数据库、缓存、消息队列、定时任务、基础设施。每个维度用一根轴向表示轴向长度的基准是这套系统当前的平均健康状态。第二层点某个维度进去就是该维度对应的详细 Grafana 面板每个指标都配套告警规则。这个方案其实是在性能和深度之间做了一次妥协。性能上雷达总览图每 30 秒刷新一次七根轴的计算量微乎其微。深度上具体的 PromQL 面板、日志检索、Trace 查询完全不碰雷达图只承担“发现问题”的职责“定位问题”交给原有工具链。1.3 技术选型轻量优先拒绝重平台PLFM_RADAR 在选型上有一个明确原则尽量复用现有组件不引入新的重型依赖。服务指标采集我们原本就用的 Prometheus 生态exporter、PushGateway、Alertmanager 都是现成的。存储上没直接上 Thanos、Mimir 这类分布式方案而是先用单机 Prometheus配合本地 SSD 和合理的数据保留周期。原因是团队规模和数据量决定了你根本用不上分布式上了反而徒增运维负担。需要注意的是PLFM_RADAR 用的不是 Grafana 自带的雷达图插件而是我们自己基于 Grafana 的 Panel 插件机制写了一个简单的 Radar Panel直接读 Prometheus 的 instant vector。没有用社区那几个现成雷达图插件主要原因是它们的交互支持太差不能点击轴线跳转。自己写插件其实不大百来行 TypeScript后面会说明实现细节。2. 核心指标拆解与阈值设计2.1 七个监控维度的指标来源雷达图七根轴各自代表的内容不是拍脑袋定的每一个维度都对应一套独立的监控闭环。我先列一张表把维度、指标来源、采样方式讲清楚。维度主要指标数据来源刷新频率服务健康度实例存活数、容器重启次数、注册中心心跳Prometheus kube-state-metrics30s接口延迟p50/p95/p99 延迟、错误率、QPS应用内 Micrometer Prometheus15s数据库连接数、慢查询数、主从延迟、磁盘使用率mysqld_exporter 云监控 API30s缓存Redis 内存使用率、命中率、客户端连接数redis_exporter15s消息队列Topic 积压量、消费速率、生产者速率云 SDK 自研 exporter30s定时任务执行成功率、最长耗时、最近一次运行时间任务调度系统 API60s基础设施CPU 平均使用率、内存水位、磁盘 IO、网络带宽node_exporter30s每个维度不是单指标而是多个原始指标经过 PromQL 聚合后的一个 0-100 的“健康分”。比如数据库维度连接数超过阈值得 80 分慢查询突增扣 10 分主从延迟超过 5 秒直接扣 30 分最低为 0。雷达图每一根轴的长度就是对应的健康分。这样设计的好处是把不同量纲的指标统一成了一张图能画出来的东西。2.2 阈值的计算不是拍脑袋是算出来的阈值是我这个项目里感触最深的部分。PLFM_RADAR 的第一个版本阈值基本靠“感觉”上线不到两周就闹了个大笑话——接口延迟 p95 阈值设成了 500ms结果每天下午都报警因为有个导出报表的接口本来就要跑十几秒。后来我们把阈值全部改成“基于历史基线动态计算”问题的性质就变了。具体做法是用 recording rule 算历史分位数record: job:http_request_duration_p95:baseline expr: quantile_over_time(0.95, http_request_duration_seconds_bucket[7d])这行规则的意思是取出最近 7 天的 p95 延迟作为基线。告警判断的时候不是拿绝对阈值比而是拿当前 p95 和基线比比如“当前 p95 超过基线 3 倍且持续 5 分钟”才告警。有些季节性明显的场景比如每天中午的峰值流量这种相对基线的方式比任何固定阈值都靠谱。这里给一个 p95 的具体计算过程。假设你有一批延迟桶数据http_request_duration_seconds_bucket分别统计了落在 0.1s、0.5s、1s、2s、5s 桶里的请求数五个桶的累计值依次是 500、2000、8000、9500、10000。总请求数 10000p95 位置对应 9500。依次对比累计桶发现 9500 落进了“≤2s”这个桶且比前一个桶“≤1s”的 8000 多了 1500。假设桶内均匀分布p95 大致等于 1s (9500-8000) / (9500-8000) * (2s-1s) 2s。Prometheus 的 histogram_quantile 也是这个逻辑只是桶内还做了插值。expr: histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service))2.3 告警规则里的三大反模式阈值有基线之后告警就解决了一个大问题。但真正让 PLFM_RADAR 变得好用的是后面我们修正的三个告警反模式。第一个反模式是只告警不区分时间段。夜间 3 点的一条 p95 延迟告警和下午 3 点的一条同样告警严重程度完全不同。夜间大概率是无人访问的业务低谷延迟飘一下可能只是 GC 抖动下午 3 点可能是核心业务的正常高峰期。我们后来给规则加了时间窗夜间告警自动降级为 P2不推送企业微信只留记录。第二个反模式是告警响铃过密。刚开始的版本里Redis 内存超过 80% 就每分钟发一次告警群的机器人像个复读机。后来换成“进入告警状态时通知一次持续 30 分钟未恢复再提升一次级别恢复后通知一次”群里终于安静了。这个配置在 Alertmanager 里叫 group_wait 和 repeat_interval用 group_interval: 30m 就能避免刷屏。第三个反模式是监控里塞了太多噪音指标。我们定了“告警有价值”的判断标准收到一条告警后如果 80% 情况下不能直接指导你该去查哪个服务这条规则就该删。PLFM_RADAR 迭代过程中删掉的规则数量比留下的多一倍多。判断依据其实很简单就是看告警生成后处理人是否立即知道下一步操作。3. 实操环节雷达插件的实现与服务搭建3.1 总览面板的 Radar Panel 插件怎么写PLFM_RADAR 里最核心的代码就是那个自定义 Grafana Panel。为什么不直接用现成的社区有几个雷达图插件但大多只能展示静态数据你要实现“点击某根轴线跳转到对应详单面板”这个核心交互只能自己动手。面板插件的骨架用的是 Grafana 的grafana/ui里的PolarChart组件数据源类型选择 Prometheus。实现逻辑不长我贴一下核心思路import { PolarChart, LegendDisplayMode } from grafana/ui; export function RadarPanel(props: PanelPropsRadarOptions) { const { data } props; const frame data?.series data.series[0]; // 从 Prometheus instant query 的结果中提取各维度的健康分 const dimensions frame?.fields.map((field, idx) ({ name: field.name, value: Number(field.values.get(0)), query: props.options.dimensionLinks[idx], })); const onAxisClick (idx: number) { // 通过 locationSrv 跳转到对应数据源和面板 locationService.partial({ panelId: dimensions[idx].query }, true); }; return ( PolarChart values{dimensions} width{300} height{300} onSeriesClick{onAxisClick} legend{{ displayMode: LegendDisplayMode.List, placement: bottom, }} / ); }dimensionLinks 是这个插件自定义的选项用户可以在这里配置每个维度点击后需要跳转的 Grafana Dashboard UID 和 Panel ID。插件的配置界面比较简单有一项数据源、一项刷新间隔、七组维度名称和跳转链接。这套代码在 GitHub 上有很多 Grafana panel 插件模板可以参考核心是熟悉 Grafana React 面板的 data 流转方式。不过需要提醒一点如果你们 Grafana 版本是 8.x 的插件 API 是PanelProps升级到 9.x/10.x 之后官方已经改成了新的 scene 架构代码可能需要适配。3.2 雷达图背后的健康分计算雷达图每个维度的健康分是一个 0-100 的浮点数这个分值由该维度下多个指标的 PromQL 规则联合得出。以数据库维度为例健康分由三部分组成。连接数得分等于 100 减去连接数使用率与阈值的比值100 - (mysql_global_status_threads_connected / 200 * 100)主从延迟项相对粗暴延迟超过 5 秒该维度直接从 100 分扣除 30 分100 - (mysql_slave_status_seconds_behind_master 5 ? 30 : 0)慢查询指标用的是速率模式最近 5 分钟慢查询速率超过每分钟 20 条扣 15 分(... )三个子项相加最终结果是数据库维度得分。比如连接数得分 75、主从延迟扣了 30、慢查询正常不扣最后数据库维度就是 45 分在雷达图上会非常明显地缩进去。其它维度也是同样的分解思路只是子项权重不同。比如服务健康度维度实例存活数和接口错误率占大头消息队列维度积压量占 60% 权重消费速率占 40%。3.3 Prometheus 和 Alertmanager 的配置骨架整个 PLFM_RADAR 在服务端的构成其实就三块Prometheus 负责抓取和告警规则评估Alertmanager 负责告警路由和发送Grafana 负责展示。docker-compose 的编排文件大概是这样的version: 3.8 services: prometheus: image: prom/prometheus:v2.45.0 volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml - ./alert.rules.yml:/etc/prometheus/alert.rules.yml - prom-data:/prometheus command: - --storage.tsdb.retention.time15d - --storage.tsdb.wal-compression ports: - 9090:9090 alertmanager: image: prom/alertmanager:v0.25.0 volumes: - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml ports: - 9093:9093 grafana: image: grafana/grafana:10.1.0 environment: GF_PLUGINS_ALLOW_LOADING_UNSIGNED_PLUGINS: radar-panel volumes: - ./radar-panel:/var/lib/grafana/plugins/radar-panel - grafana-data:/var/lib/grafana ports: - 3000:3000Prometheus 采集配置里要注意抓取频率的设置。我一开始把七类 exporter 全部统一为 15s 抓取结果某天上午突发大批量定时任务Prometheus 的 CPU 直接冲到 90%。后来按需分配node_exporter 和 mysqld_exporter 这类高频变化的指标用 30s定时任务这种更新慢的指标用 60s。不用过度追求高频监控不是实时交易系统30 秒的延迟完全够用。告警规则文件里包含几个核心规则。我贴一个 Redis 内存告警的例子groups: - name: plfm-alerts rules: - alert: RedisMemoryHigh expr: redis_memory_used_bytes / redis_memory_max_bytes 0.85 for: 5m labels: severity: warning dimension: cache annotations: summary: Redis内存超出水位 description: 实例 {{ $labels.instance }} 内存使用率已超过85%当前值 {{ $value | humanizePercentage }}Alertmanager 的路由配置里接入了两个通知渠道企业微信机器人和邮件。路由规则按 severity 分critical 级别的立刻发企业微信并对应服务负责人warning 级别的只发邮件并在第二天早上统一汇总。这个配置很大程度取决于团队工作习惯我们是白天 all-in 企业微信群夜间只响应 critical。3.4 雷达总览面板的搭建顺序面板的搭建顺序会影响后续维护成本。我们是先在 Grafana 里把七个详单面板全部建好再建雷达总览因为雷达图里的跳转链接需要引用详单面板的 UID 和 Panel ID。步骤拆开来说先建服务健康度详单面板面板变量选service可以下拉切换微服务。再建接口延迟面板加两份图——一份是 p50/p95/p99 的分位数趋势一份是错误率趋势。数据库面板和缓存面板都按照指标拆分成 Row每行用一个时间序列图方便拖拽。消息队列、定时任务、基础设施同理把各维度指标独立成面板。最后一个关键步骤在 Grafana 的 Dashboard JSON Model 里查每个详单面板的 ID然后把它们填进雷达图插件的 dimensionLinks 配置里。插件加载后雷达图会出现在总览 Dashboard 的最上方下面是七个详单面板按顺序展开。这样团队打开首页时第一眼看到的永远是雷达总览再往下才是具体指标这个“总览-细节”的层级对排查问题非常友好。4. 故障排查与避坑实录4.1 Prometheus 存储膨胀与 WAL 压缩PLFM_RADAR 上线后大概一个半月我发现 Prometheus 的数据目录比预期膨胀得快很多接近 20GB。时间序列几百个按理说不应该这么大。排查下来发现根因有两个。第一个原因是--storage.tsdb.retention.time没有配置Prometheus 默认保留 15 天这个其实不算问题。真正的元凶是没有做 WAL 压缩而很多 exporter 的指标名是带 tag 变化的比如 redis_exporter 默认的redis_connected_clients带有大量 db 维度标签Prometheus 的 WAL 文件日志每两小时切割一次不压缩的话占用翻倍。解决方案很简单启动参数里加--storage.tsdb.wal-compression同时针对变化频率极高但价值有限的指标做 relabel 过滤丢弃不需要的标签metric_relabel_configs: - source_labels: [__name__] regex: redis_db_keys.* action: drop压缩后数据目录直接降了差不多四成而且对抓取性能几乎没有影响。4.2 告警风暴的源头居然是区间向量还有一次印象深刻的事故。某天下午 Redis 连接数告警疯狂触发一小时内企业微信被刷了两百多条消息。当时第一反应是 Redis 是不是真出问题了连上去看连接数确实高大概 4000 多个但远没有到 maxmemory 限制。后来看 Alertmanager 的日志才发现问题不在 Redis而在我们自己的告警规则。原始规则用的是区间向量expr: avg_over_time(redis_clients_connected[5m]) 400这个写法的缺陷是只要任意一个时间点上连接数超过 400持续 5 分钟的 avg_over_time 都会超过阈值告警就不会消散。而连接的毛刺往往是一瞬间的比如某个服务批量重建连接池。毛刺过了avg_over_time 还要看到下一个 5 分钟窗口。修正后的规则改为瞬时向量加 for 子句expr: redis_clients_connected 400 for: 5mfor: 5m的意思是指标超过阈值持续满 5 分钟才触发告警毛刺直接忽略。这个案例挺典型的暴露的是我们对 Prometheus 查询语义理解不深的问题踩过一次坑之后就记住了。4.3 雷达图上有的维度一直为 0PLFM_RADAR 刚上线时定时任务维度一直是 0拉了很长时间的平线但任务明明都在正常跑。我一度以为是插件解析数据有问题查了半天后来发现是 PromQL 里聚合函数用错了。定时任务的健康分规则用的是task_success_count / task_total_count但每个任务实例只有一条时间序列而且任务是每 5 分钟调度一次不运行的时候没有数据点。Prometheus 对缺失数据点的时间序列返回的默认值不是 0而是空。空值和数值做除法结果就变成了空雷达图自然显示为 0。解决方式是给规则加or on() vector(100)兜底没有数据时默认给 100 分。这里用到了一个 PromQL 的小技巧task_success_count / task_total_count or on() vector(100)这个技巧在处理周期性任务、批处理、后台 job 这类不是持续上报指标的场景里特别管用。以后凡是告警规则里涉及相除的我都会先思考一遍“除数为空”的情况。4.4 插件的点击跳转在 Grafana 10 里失效雷达图插件的跳转在 Grafana 8 里是好的但是 Grafana 升级到 10 之后全部失效。报错信息是locationSrv is not a function查了文档才知道 9.x 开始 Grafana 把旧的位置服务 API 移除了改成locationService。这个兼容问题其实很好解决判断当前环境再选择调用哪个服务只是研发过程中容易忽略版本升级带来的破坏性变更。现在插件里已经加了一行兼容代码const locSrv (window as any).__grafana_locationSrv ?? locationService;如果你也在自研 Grafana 插件升级主版本的时候一定要把插件代码里的 API 调用全部过一遍不能只看官方迁移文档里列举的少数几个破坏性变更实际踩雷往往在文档之外。5. PLFM_RADAR 的适用边界与扩展方向5.1 什么规模的团队适合这套雷达监控PLFM_RADAR 的设计目标是轻量、收敛、易理解但有得必有失。它对团队的适用边界很清楚。如果你是个人开发者只有三五台服务器不太建议整这套。你直接花点时间配好 NodePing、UptimeRobot 这类轻量监控就够用了雷达图的七个维度对个人项目来说太冗余维护成本大于收益。如果团队规模在几十人、上百个服务、三五套中间件PLFM_RADAR 的性价比是最高的。这个阶段你大概率已经上了 Prometheus 和 Grafana雷达总览只是加了一层聚合视图投入产出比非常大。但如果团队已经成长到几百人、几千个容器、需要多集群统一监控的阶段单机 Prometheus 和这个自研插件的架构都会成为瓶颈。这时候你应该考虑的是 Mimir/Thanos 这类分布式存储以及更成熟的商业可观测平台而不是继续在雷达图上加维度。PLFM_RADAR 的核心思想——用聚合视图快速定位平台短板——仍然适用但技术底座需要整体替换。5.2 后续可以扩展的三个方向这套系统后续继续演进的话我个人认为有三个扩展方向价值比较高。第一个方向是把健康分从规则计算升级为回归检测。现在的健康分是基于阈值和基线算出来的规则需要人工维护。如果给每个指标的历史时序做一次简单的趋势回归超出置信区间自动扣分就能覆盖很多“阈值没设对但指标明显异常”的场景。第二个方向是把七根轴的维度做成可配置的。现在维度是写死在插件配置里的改成从 Prometheus label 动态生成轴线会更有弹性。这样新增一个监控域时不需要改代码、重新编译插件只加一组 label 就能自动长出一根新轴。第三个方向是多维度的关联下钻。比如你在雷达图上看到数据库维度缩进去了现在要手动点进去看数据库面板再手动切到服务面板查哪个服务在打数据库。如果能在数据库面板上直接叠加一张“按调用来源聚合的 TOP 服务表”排查链路会从二三十分钟缩短到两三分钟。这个本质上是调用链数据和监控指标的结合做起来有一定工作量但价值极大。PLFM_RADAR 从立项到现在大半年雷达总览已经成为我们团队每天打开最频繁的页面。在监控领域炫技不重要真正能减少排查时间的手段才重要。雷达图的七根轴对我们已经成了日常讨论问题的语言“今天消息队列那根轴塌了”“晚高峰服务健康度掉了一半”……这种表达方式本身就是这套系统最大的价值。最后再说一句实在的任何监控系统都不如业务稳定重要PLFM_RADAR 只是让你在业务不稳的时候更快知道该往哪里扑。

用雷达图统一平台监控：PLFM_RADAR实践复盘

相关推荐

SFP+光模块与交换机搭配全解析：四种方案与选型避坑指南

工业SPI隔离设计：MAX14431BAEE+与STM32F767ZI链路详解

PLFM雷达开源框架：基于10.5GHz相控阵的FMCW信号处理实践

更多资讯

游戏运行库精准诊断与沙盒化修复方案

欠驱动USV编队控制：反步法与神经网络补偿方案

STGCN时空图卷积网络：原理、优化与交通预测实践

从零构建英语口语智能体：架构设计、核心模块与实操避坑指南

OpenStack命令行工具使用指南与实战技巧

Android车机与PAD性能优化：八维指标、adb命令与回归表

今日更新

PLFM_RADAR：从被动告警到主动感知的微服务健康监控系统

SPI隔离设计实战：MAX14431BAEE+与STM32F407工业级应用

数字隔离器如何根治SPI通信地环路干扰：MAX14431与TM4C129实战

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？