★ FEATURED ARTICLE 说实话第一次看到PLFM_RADAR这个项目名的时候我第一反应是又有人做个雷达信号处理的小工具。等把这个名字拆开看——PLFM 就是 PlatformRADAR 是雷达合起来就是平台的雷达。这个命名很直白给自己的技术平台装一副全天候扫描的雷达盯着线上服务的各项指标在故障还没有变成事故之前就提前发现、提前预警。我做完整个项目之后最大的感受是监控系统本身不难搭难的是怎么让这玩意儿真正有用而不是变成一个只会发告警短信的狼来了机器。这篇就把我从需求拆解、架构设计、规则配置到踩坑修复的完整过程写出来给准备搭建或者正在优化平台监控体系的同学一个可以直接参考的版本。1. 项目概述为什么平台需要一副雷达1.1 从一次线上事故说起事情起因是团队负责的一个业务平台连续出现了两次慢请求拖垮全站的问题。第一次是数据库连接池被一个异常任务占满第二次是缓存雪崩导致回源流量暴增。两次事故的共同点是等监控大屏上出现红色告警的时候用户那边其实已经抱怨很久了故障早就在酝酿只是没有被及时发现。那时候我们手上是有监控的但都是碎片化的——机器层面的 CPU、内存有告警应用层面的接口耗时、错误率有日志却没人把这些数据串起来看。数据库连接池水位、缓存命中率、依赖服务的响应时间这些中间指标基本是盲区。问题发生时最先感知到的是用户其次才是运维最后才是开发。PLFM_RADAR 这个项目就是在这样的背景下立项的。目标很明确做一个平台级的雷达监测体系把分散在各个系统里的指标、日志、链路数据统一采集、统一分析、统一预警在故障还处于苗头阶段就把它揪出来。1.2 PLFM_RADAR 的定位与核心能力这个项目不是什么颠覆性的新技术本质上是一套贴合业务场景的监控预警闭环。它的核心能力可以概括成三个词看得全、判得准、叫得醒。看得全是指监控覆盖范围从基础设施层延伸到应用层、业务层不仅有 CPU、内存、磁盘这些系统指标还有接口 QPS、P99 耗时、错误率、依赖服务状态、消息队列积压量这些应用指标甚至可以定义订单量、支付成功率这样的业务指标。判得准是说规则引擎支持静态阈值、动态基线、多条件组合三种模式减少误报。叫得醒则是告警分级通知P0 走电话P1 走 IMP2 走邮件确保真正要紧的故障一定有人响应。这套体系适合什么样的团队如果你的平台已经有 Prometheus、Grafana、ELK 这类基础组件但告警规则散落各处、误报率高、链路不完整PLFM_RADAR 的思路可以直接套用如果你是从零开始搭监控它也可以作为一份蓝图避免你走弯路。2. 整体设计思路与指标拆解2.1 雷达扫描什么四个黄金信号做监控的第一件事不是选工具而是确定要盯哪些指标。我参考了 Google SRE 书籍里提出的四个黄金信号——延迟、流量、错误、饱和度再根据自身平台的特点做了扩展。延迟指标不只是接口平均耗时更重要的是分位数。我们重点监控 P50、P95、P99 三个分位P50 反映整体体验P99 反映极端情况下的体验。有一次优化之后 QPS 涨了平均耗时看着没变但 P99 从 200ms 涨到了 800ms就是因为一批慢 SQL 拖累了长尾请求。如果只盯平均值这个问题根本发现不了。流量指标是判断容量问题的关键。QPS、TPS、并发连接数这些数据本身不说明好坏但流量突增或突降都值得关注。比如凌晨流量突然翻倍很可能是爬虫或者活动流量异常提前发现就能避免后端被冲垮。错误指标包括 HTTP 5xx 比例、业务异常数、消息重试次数。这里有个细节错误率要用请求总数做分母而不是只看错误数绝对值。一个每秒只被调用 10 次的小接口出错 5 次错误率就是 50%但整体危害远小于一个每秒 10000 次的接口出错 1%。饱和度最容易被忽略也最容易酿成大事故。连接池使用率、内存使用率、磁盘 IO 等待、线程池活跃线程数都属于饱和度指标。我们的教训是数据库连接池使用率持续超过 80% 就应该告警而不是等它 100% 了才报连接不可用。2.2 三层架构采集、存储、感知PLFM_RADAR 的整体架构分成三层每层解决一类问题职责边界非常清晰。采集层负责把散落的指标捞上来。基础设施指标用 node-exporter 采集应用层指标通过 Prometheus 客户端库在代码里埋点暴露日志类数据走 Filebeat 收集后入 Elasticsearch链路追踪数据则用 Jaeger 采集。这一层做得好不好直接决定上层能不能看得全。存储层用的是 Prometheus 加 Thanos 的组合。Prometheus 本身带时序存储但单机有容量上限通过 Thanos 把数据对象存储归档既解决了历史数据查询问题又不增加运维负担。日志类数据放 Elasticsearch提供全文检索能力链路数据单独存因为它的数据结构和指标完全不同。感知层是 PLFM_RADAR 的核心也就是告警规则引擎。Prometheus 自带 Alertmanager 做规则评估和通知分发但这些零散能力需要串起来才能形成完整的雷达效果。我们把所有规则集中管理按业务模块分组通过配置中心下发避免每个人在自己的项目里乱写规则。2.3 为什么不做大而全的可观测平台做设计的时候有同事提出一步到位上完整的可观测性平台把指标、日志、链路、告警全部整合成一个门户。这个想法很好但对当时的团队来说风险太大——改造周期长学习成本高短期内很难见到效果。我的选择是先用最小可用版本跑通闭环再逐步演进。第一版只做三件事统一指标采集、配置核心告警规则、打通告警通知渠道。日志检索和链路追踪继续沿用原有系统等雷达的核心能力稳定后再慢慢整合。这种渐进式思路的好处是风险可控团队可以在使用过程中不断提出真实需求而不是被一个宏大系统绑住手脚。3. 核心实现采集端与规则引擎3.1 埋点与采集方案选型采集端是整个雷达的眼睛选型上直接决定数据质量和接入成本。我们最终定了 Prometheus 体系因为它在云原生领域的生态最成熟客户端库覆盖几乎所有主流语言而且 Pull 模型天然适合微服务架构。应用层埋点需要遵守一条原则只暴露对排查问题有意义的指标。我见过有人把几十个自定义指标全抛出来结果大部分从没人看白白消耗存储。我们的做法是每个服务至少暴露 5 类指标请求总数、请求耗时直方图、错误计数、依赖调用耗时、运行状态如线程池大小、连接池使用率。以 Java 服务为例用 Micrometer 接入 Prometheus 客户端配置极其简单Bean public MeterRegistryCustomizerPrometheusMeterRegistry metricsCommonTags() { return registry - registry.config().commonTags(application, order-service); }这段代码的作用是给所有指标打上应用名标签。没有这个标签多个服务的指标混在一起根本无法区分后面写规则的时候也做不了按服务维度的分组告警。埋点要在代码发版前就想好上线后再补埋点会导致历史数据断层很多趋势分析都做不了。基础设施层的采集相对省力node-exporter 部署完基本不用管MySQL、Redis、Kafka 这些中间件也有官方 exporter 可以直接用。踩过的一个坑是 exporter 版本要和中间件版本匹配更新中间件之后忘了升级 exporter导致新暴露的指标采集不到排查了很久才发现是版本兼容问题。3.2 静态阈值与动态基线的取舍规则引擎里最值得琢磨的是告警阈值的设定逻辑。静态阈值简单直接比如 CPU 使用率超过 90% 就告警但静态阈值很难适配所有场景。一个每天凌晨才有高峰的批量任务服务和白天持续高并发的交易服务它们的流量模式完全不同用同一套阈值必然误报不断。动态基线是更好的方案。它的思路是不设固定阈值而是根据历史数据自动计算一个正常范围当当前值明显偏离这个范围时触发告警。我们用一个轻量级的实现——对每个指标按小时间段聚合取近 14 天同时段数据的均值和标准差当实时值超过均值 3 倍标准差时判定为异常。这个方案实现成本低效果却出奇地好。还有一个容易被忽略的问题时间窗口设置。告警评估周期不宜太短也不宜太长。我们一般用 5 分钟窗口因为 1 分钟窗口对流量抖动太敏感容易误报15 分钟又太长故障发现延迟过高。对于 P0 级别的核心链路可以缩短到 1 分钟但要配合连续触发 N 次才告警的条件过滤瞬时抖动。3.3 告警收敛与分级通知告警如果每一条都推到同样的渠道很快所有人都会麻木真正的故障反而被淹没。我们的做法是先分级、再收敛、后通知。分级标准按影响面定义影响核心业务流程、导致大面积用户不可用的为 P0电话通知影响部分功能、有变通方案的为 P1IM 通知并要求 15 分钟内确认无实际影响但指标异常、需要跟踪的为 P2进入工单池由值班人处理。收敛靠的是 Alertmanager 的 group_by 和 inhibit 规则。group_by 把同一时间窗口内、属于同一告警组的多个告警合并成一条避免MySQL 挂了触发 50 个关联告警的情况。inhibit 规则则实现告警抑制当更高优先级的告警已经触发时相关联的低优先级告警自动静默。比如数据库不可用的 P0 告警触发了那么所有依赖该数据库的接口超时 P1 告警就暂时不推不然值班人会被刷屏。4. 实操过程与关键配置4.1 数据链路搭建整个雷达的数据链路可以概括为一句话节点暴露指标Prometheus 拉取存储规则引擎评估Alertmanager 分发通知。下面按步骤拆解从零搭建的完整过程。第一步部署 Prometheus。配置文件中最重要的是 scrape_configs 部分它决定了采集哪些目标scrape_configs: - job_name: node-exporter static_configs: - targets: [192.168.1.10:9100, 192.168.1.11:9100] - job_name: spring-boot-apps metrics_path: /actuator/prometheus kubernetes_sd_configs: - role: pod relabel_configs: - source_labels: [__meta_kubernetes_pod_label_app] regex: (.) target_label: application replacement: $1注意 relabel_configs 这段它把 Pod 的标签映射为 Prometheus 的 application 标签这样后面写规则时可以用applicationorder-service来圈定告警范围这是规则管理的基础。第二步是部署 Alertmanager配置路由树和通知渠道。一个实用的路由配置是这样route: group_by: [alertname, application] group_wait: 30s group_interval: 5m repeat_interval: 4h routes: - match: severity: P0 receiver: phone-call - match: severity: P1 receiver: team-im - match: severity: P2 receiver: work-ordergroup_wait 设置 30 秒是因为需要给同一批告警留出聚合时间如果设 0每条告警都会单独推送效果很差。repeat_interval 设为 4 小时意味着同一告警不重复推送的窗口是 4 小时避免值班人每 5 分钟就收到一次同样的告警。第三步接入通知渠道。电话告警用 Alertmanager 的 webhook 扩展实现IM 通知走自定义 webhook邮件用内置的 smtp 配置。建议先接 IM 再折腾电话因为大部分告警 IM 足够电话留给真正的 P0。我用 Python Flask 写了一个简单的 webhook 转发服务把 Alertmanager 的 JSON 负载转换为 IM 消息格式部署在内部服务器上稳定运行至今。4.2 告警规则配置实战规则写法直接影响告警准确性。以接口错误率为例正确的规则是groups: - name: order-service rules: - alert: OrderServiceHighErrorRate expr: | sum(rate(http_server_requests_seconds_count{applicationorder-service, status~5..}[5m])) / sum(rate(http_server_requests_seconds_count{applicationorder-service}[5m])) 0.05 for: 5m labels: severity: P1 annotations: summary: 订单服务 5xx 错误率超过 5% description: 当前错误率 {{ $value | humanizePercentage }}持续 5 分钟这里有个关键操作表达式里用两个 sum 分别计算错误请求数和总请求数再相除而不是直接用sum(rate(...)) 5加一个绝对值判断。原因在于错误率是相对概念一个 QPS 很大的服务和一个小流量服务同样的 5 个错误请求含义完全不同。for: 5m是持续 5 分钟才触发告警用来过滤瞬时抖动但也要付出代价——这 5 分钟里故障可能在扩大所以 P0 规则的 for 要改成 1m。动态基线规则我写在独立的规则文件里由一个小型 Python 服务定时生成基线数据并更新到 Prometheus 的 record 规则中。核心思路是对每个指标计算滑动窗口的均值与标准差然后生成类似这样的规则- record: job:http_request_qps:baseline expr: avg_over_time(...[14d]) - record: job:http_request_qps:deviation expr: stddev_over_time(...[14d])告警表达式就变成qps baseline 3 * deviation。这套方法上线第一个月就把误报率降了将近一半缺点是计算量大一些但用 record 规则预计算后评估开销完全可以接受。4.3 从指标异常到告警触达的完整链路我拿一次真实的连接池告警来说明整个链路是怎么运转的。某天下午 14:32订单服务依赖的 MySQL 连接池使用率开始攀升14:37 超过了动态基线的上边界Prometheus 规则引擎首次评估为 Pending 状态。14:42持续 5 分钟的异常仍未被修复告警状态转为 FiringAlertmanager 接收后按 severityP1 路由到团队 IM 群。消息里带着当前值、基线值、持续时间和关联的 Grafana 面板链接。值班开发点开链接发现连接池活跃连接数异常顺着链路追踪查到是某个定时任务在同一时间发起了大量批量查询把连接池占满。他直接停掉定时任务14:50 连接池水位回落告警自动恢复。整个过程从异常出现到恢复不到 20 分钟而在过去这类问题往往要等用户反馈才能被发现。这就是雷达的价值——把发现问题的时间从用户投诉后提前到用户感知前。5. 常见问题与排查技巧实录5.1 误报多到没人看怎么办误报是监控体系最大的敌人。规则上线初期我们的告警群经常半夜响个不停值班人疲于应付到后来看到红色消息直接忽略。切身体会解决误报不能靠降低阈值灵敏度那是拆东墙补西墙。真正有效的手段是给规则加上更多过滤条件。比如告警排除计划内变更的影响——发版和扩容操作会主动触发维护模式期间告警自动静默。再比如按端口、路径做过滤健康检查产生的 404 请求、证书探测的连接数都不应该计入错误率。还有一个操作细节每次有人因为误报被折腾一次就应该记录当时的告警详情每周复盘一次逐条分析是阈值问题、采集问题还是确实出现了瞬时异常。我们这样迭代了一个月告警准确率从 60% 提升到 90% 以上。5.2 监控数据延迟怎么定位有段时间我们发现 Grafana 面板上的数据比真实时间滞后 10 分钟告警也跟着延迟。排查下来是 Prometheus 的 scrape 超时拉长导致的——某些 exporter 响应慢Prometheus 的scrape_timeout默认只有 10 秒每次采集超时都把这轮数据丢了。解决办法是在 scrape_configs 里针对慢速 exporter 单独调大超时并降低采集频率scrape_configs: - job_name: slow-exporter scrape_timeout: 30s scrape_interval: 60s数据延迟还有个大坑Prometheus 默认只保留 15 天原始数据时间序列的retention和待处理队列tsdb的写入延迟都可能导致查询结果异常。用 Thanos 做长期存储后这个限制基本上解除了。5.3 告警风暴与值班体验优化告警风暴通常发生在依赖系统大面积故障时比如数据库主从切换的瞬间几十个服务的上百条告警同时触发。如果不在 Alertmanager 层面处理值班人会被活埋。我们做了两件事。第一认真配置 inhibit 规则把依赖关系变成抑制关系——数据库不可用时所有依赖它的上游服务告警一律抑制。这个需要把服务的依赖清单维护好我们通过链路追踪数据自动生成依赖关系大大减少了人工维护成本。第二在 IM 通知里加上群内有值班机器人机制告警推送到群后机器人自动创建跟进任务值班人只需要一次点击确认接手不需要在群里逐条回复减少沟通噪音。值班体验优化之后团队对监控系统的信任度明显提升不再把告警当成骚扰。我觉得这是整个项目最有价值的隐形收益——工具再好如果团队不信它就是不用的废铁。6. 最后踩过的几个坑按惯例分享几个项目中踩过比较深的坑。第一个是告警表达式里的标签匹配问题。PromQL 里http_requests_total{status500}和http_requests_total{status~5..}是完全不同的写法前者只匹配精确的 500后者才匹配所有 5xx——我因为这个漏掉了 502、503 的大面积故障直到用户反馈才发现。写规则时一定要确认状态码的覆盖范围。第二个是时序数据的对齐问题。两个指标做除法运算时如果它们的采集频率或时间戳偏移不一致结果可能跳动得很厉害。解决方法是在 PromQL 里显式使用offset或者将两个指标放入同一组的 record 规则让对齐计算在上游完成。第三个更隐蔽动态基线在业务发生结构性变化时会误判。比如大促开始后流量是平时的 20 倍基线模型会认为这是严重异常疯狂告警。解决方案是在大促前提前把基线模型切换为大促模式用历史大促的数据做基线而不是用日常数据。这个模式切换我们后来做成了运维平台的定时任务每年的固定节点自动执行。PLFM_RADAR 做到现在已经不只是一个监控项目更像是平台的一种免疫力。它未必能帮你挡住所有故障但能在故障来临时最早感知、最快定位。如果让我说一条最值得分享的经验那就是监控系统的价值取决于使用者的信任而信任来自每一次准确、及时、有用的告警。与其追求监控指标的绝对完备不如先把告警的准确率打磨到极致。
阅读完成 · 觉得有帮助？
