说实话一看到“PLFM_RADAR”这个名字我脑子里蹦出来的就是“Platform Radar”——平台雷达。我自己在维护过几套业务系统之后最大的感受就是你的平台到底健不健康不该靠用户跑来说“你们是不是挂了”而是应该有一套东西像雷达一样24小时扫着它任何风吹草动都能提前感知。这个项目说白了就是给平台装一套“雷达”。PLFM_RADAR 是我最近独立搭出来的一套平台全量观测与预警系统它做的事情不复杂但很关键把平台上的日志、指标、接口调用、发布事件、任务执行记录全部汇总到一起然后用一套可配置的规则去“扫描”一旦发现异常立刻输出预警同时把所有数据沉淀成可视化面板方便复盘和排查。和传统监控大盘最大的区别在于它不止告诉你“现在红了没有”还会把“什么时候开始红的、当时发生了什么、关联到哪个服务哪次变更”一起给你。它特别适合平台/后端研发、SRE、运维同学以及任何手上维护着两套以上服务、经常被半夜告警搞醒的团队。哪怕你现在只有一套业务系统这套思路也完全能迁移过去先搭骨架、再填规则不追求一步到位但把底子铺对。1. 项目初衷与方案选型1.1 为什么要做“平台雷达”而不是“平台监控”市面上监控系统太多了PrometheusGrafana、Zabbix、SkyWalking随便挑一个都能用。但是在我实际维护平台的过程中发现传统监控和雷达式的观测有一个本质区别传统监控是大盘、是曲线、是阈值告警它看的是“指标”而雷达式观测要求的是**“完整画面定向锁定”**——不仅要看到全局的亮灯情况还要在异常出现的时候能够把相关的日志、调用链、版本变化、配置变更全部串起来快速锁定目标。换句话说传统监控解决“挂了没有”PLFM_RADAR 侧重解决“哪里不对、为什么不对、是不是有人在背后动了什么”。我这套理解是从一次实际故障里逼出来的。当时线上某个核心服务报 5xx监控大盘确实亮了红灯但是—然后呢我打开 Grafana 看到错误率曲线拉了一条直线知道它从 10 点开始涨可我不知道是因为数据库慢查询还是因为当时有人发了一个新版本或者是对接方改了接口。那一次我在好几个系统之间来回切换花了将近一个小时才定位到是配置中心的一次错误推送。那次之后我就下决心不能再让“指标异常”和“根因定位”断成两截。1.2 “RADAR”的设计隐喻扫描、锁定、预警、复盘设计这个系统的时候我一直在想如果雷达真的在转它每一步在干嘛。后来我把它拆成了四个动词这四个动词也直接成了整个项目的功能骨架扫描持续接收平台的日志、指标、事件形成“全空域”底图。这一层追求的是“完整”不能有盲区。锁定当一个指标或一组日志同时出现异常特征时把相关的上下文自动绑定。这一层追求的是“关联”把单独看都不起眼的信号拼成完整问题。预警按规则的严重程度分级通知并做消息收敛避免告警轰炸。这一层追求的是“克制”真正让人紧张的告警一天不应该超过 5 条。复盘所有雷达“看到的画面”都留痕事后可以拉出时间轴还原整个故障过程。这一层追求的是“证据”让复盘不再是拍脑袋回忆。这样设计最大的好处是——面对“为什么系统是这套架构”这种灵魂拷问时你可以指着雷达模型说你想要的任何一个功能都能在这个流程里找到一个明确的位置。功能永远不会漫无目的地长出来。1.3 技术选型与组件对比选型时的首要约束是“尽量轻”我不想为了做监控先搭一个需要专职运维的监控系统。技术栈如下职责选型理由指标存储Prometheus TSDB生态最成熟PromQL 基本是事实标准社区资料多日志采集与检索Loki 对象存储轻量、成本低和 Grafana 一条链路打通事件存取ClickHouse适合结构化事件的高吞吐写入和聚合分析告警引擎Alertmanager Webhook规则配置灵活通知渠道扩展简单可视化Grafana支持多数据源联合查询插件生态好上手门槛低链路追踪方面可以用 OpenTelemetry 做自动埋点。如果团队已经上了 SkyWalking 或者 Jaeger就直接复用没必要重复建设。选这套组合的另一个原因是全部组件都是开箱即用的部署门槛不高出问题也好搜到经验。我见过很多团队一上来就上全家桶 APM结果光是维护那套采集器就占了运维一大半精力反而不划算。PLFM_RADAR 的定位从来不是“最全的监控系统”而是“最省心的观测底子”。1.4 项目目录与命名约定既然项目叫 PLFM_RADAR我在工程上也刻意保持了雷达式的分层。目录结构大致是这样的plfm_radar/ ├── collector/ # 采集端逻辑 │ ├── metrics.py │ ├── logs.py │ └── events.py ├── rules/ # 告警规则与检测逻辑 │ ├── threshold.py │ ├── trend.py │ └── composite.py ├── notifier/ # 通知渠道 │ ├── webhook.py │ └── wecom.py ├── analyzer/ # 联动分析器 │ └── context_builder.py ├── dashboard/ # 面板配置与模板 │ └── grafana.json └── deploy/ # 部署编排与配置文件 ├── prometheus.yml ├── alertmanager.yml └── docker-compose.yml命名约定只有一条模块名字必须对应雷达动作看到名字就知道它在链路的哪个位置。这看起来是个小细节但等系统里的模块超过十个之后你会发现清晰命名就是最好的文档。2. 系统整体设计与核心模块拆解2.1 PLFM_RADAR 的整体数据链路PLFM_RADAR 的整体数据链路可以用一句话概括采集器进事件总线转存储层分分析层算通知层出面板层看。所有模块之间通过明确的接口约定模块内部保持高内聚。链路流程是各业务服务的日志、指标、调用链数据由采集器抓取进入统一的事件总线做字段规范化、格式解析分流写入时序库、日志库、事件库规则引擎按周期执行异常判定命中规则后生成告警事件进入 Alertmanager 队列通知渠道发出消息同时数据回写图表和复盘页面。这里有一个细节值得重点说链路里的“字段规范化”非常重要也是最容易被忽略的。日志格式不统一在不同服务里同一个字段叫法都不一样有的是request_id有的是traceId有的是req_id。如果不做规整后面做联动查询时几乎什么都查不动。我在这上面吃了大亏所以现在每个采集配置里都强制带一个field_normalizer把所有别名统一映射到标准字段名。2.2 采集层设计三类数据源我把数据源分成三类每类都有独立的采集配置。如果你要自己抄这套方案重点不是抄代码而是把这三类数据的边界搞清楚。第一类指标数据主要是服务上报的 Prometheus Metrics比如 CPU、内存、QPS、RT响应时间、错误率。这些数据的特点是“数值型、高频率、可聚合”适合放在 Prometheus 里直接拖到 Grafana 看曲线。这里要注意指标采集不能在业务主线程里阻塞上报。一旦把上报逻辑写到请求链路里高性能服务会被拖垮。正确做法是异步协程或线程池上报最粗暴的方案是进程内开一个后台 goroutine 每 15 秒向/metrics端口拉取一次。我用 Python 做采集器时用的是prometheus_client的start_http_server单独起端口业务主逻辑完全不受影响。第二类日志数据从文件或标准输出收集Loki 会把日志存成块并按标签索引。这部分要考虑三个问题日志必须带结构化字段至少要有timestamp、service、level、trace_id。高吞吐场景下不要往日志里写超大对象比如整个 Request Body。一个 2MB 的日志对象会把采集端 CPU 打满而且存储成本翻好几倍。给日志配置合理的保留周期。我一般保留 7 到 30 天超过 30 天的日志基本上没有人会再查。第三类事件数据包括发布记录、配置变更、扩缩容操作、登录鉴权、定时任务执行状态。这类数据有一个特点低频但影响面大。比如你 10 点发布了一个版本10 点 05 分错误率开始上升这种关联如果只靠人肉回忆基本都是查不清的。所以事件类数据要单独存到 ClickHouse并且在分析阶段给它们建立“时间索引”。2.3 存储与分析层三库职责划分三库的分工一定要明确混着用迟早出问题。我先画一张规则表数据类别存储位置查询方式典型用途指标Prometheus按时间标签聚合趋势判别、阈值告警日志Loki 对象存储标签过滤关键字检索错误上下文、调用链还原事件ClickHouseSQL 聚合分析統計发布次数、变更关联Prometheus 存的是可聚合的数值型指标查询是“按时间标签聚合”Loki 存的是非结构化文本日志查询时借助标签缩小范围ClickHouse 存的是结构化事件每一行都对应一条明确记录适合做统计分析。分析层有个核心组件叫“联动分析器”它的逻辑是当某个指标触发了阈值系统自动把最近一段时间该服务相关的日志错误关键字、变更事件、部署时间全部检索出来合并成一个上下文快照写到告警里。逻辑大概是这样def build_context(service, start_time, end_time): logs query_loki_logs(service, start_time, end_time) events query_clickhouse_events(service, start_time, end_time) metrics query_prometheus_metrics(service, start_time, end_time) return { service: service, window: f{start_time} ~ {end_time}, error_keywords: extract_error_keywords(logs), recent_events: events, metric_top: metrics.tail(5), }这一步很关键——它让告警从“指标跳了”变成了“指标在什么时候跳、可能和什么有关”排查速度直接提升一个量级。我实测下来原来需要翻 20 分钟日志的故障现在收到告警消息就等于拿到了 80% 的答案。2.4 联动分析器为什么不能后置可能有同学会说出问题时再手动把事件和日志拉一起不就行了我一开始也是这么想的但实际做过后才发现后置分析有两个致命问题一是出问题时人往往在慌操作动作会变形。看到告警第一时间人会去点最常点的那个面板而不是系统性地拉数据。二是时间窗口经常想不起来。没有人能准确记得“错误率是从几点开始涨的”但告警上下文快照是自动记录的时间窗口精确到秒。所以我坚持把联动分析做成前置动作而不是事后动作。每次规则命中上下文快照就和告警一起生成哪怕这次告警最终确认是误报这个快照也能帮你看清楚问题出现的路径。3. 关键指标设计与异常规则3.1 四类核心指标可用性、性能、容量、质量PLFM_RADAR 的核心指标分四类如果只是刚开始做可以先从可用性和性能做起容量和质量可以后补。每一类指标落地时我都有了明确计算口径。可用性用“探活成功率”和“接口成功率”双维度。探活是定时探测关键接口接口成功率是对真实用户流量做统计。注意探活要覆盖原子能力不要只探“首页能打开”而要去探核心下单链路或者登录链路。我见过很多团队的探活跟没探一样首页是静态缓存页面挂了也显示正常。性能核心是 P99 延迟和均延迟。计算时要排除重试流量否则误差很大。比如某个服务内部重试了 3 次最终成功了如果不区分首报耗时和重试后耗时P99 就被拖高了。我在指标采集时会对每个请求打retry_count标签统计时过滤掉retry_count 0的样本。容量CPU、内存、连接数、队列堆积数。这里我要特别提醒连接数和队列堆积往往比 CPU、内存更早暴露问题你必须单独拉出来看。比如数据库连接池被打满CPU 可能还没到 60%但系统已经卡死了。质量错误日志占比、慢 SQL 占比、未处理异常数。质量指标不直接反映系统挂没挂但反映“系统正在变差”。我在实践里很看重这条质量指标可以让你在用户感知之前就把问题处理掉。指标计算过程里我总结了一句话指标的价值不在于“有多少个”而在于“是否可解释”。你放 80 个指标在上面不如 8 个能解释问题的指标。PLFM_RADAR 初始版本只上线了 12 个核心指标运行稳定后根据实际需要再慢慢加。3.2 异常检测规则的四种典型配置书上教你的异常检测有很多种但在工程里最实用的其实就四种阈值型固定阈值超出触发。适合资源类指标如内存 85%。突增突降型环比上一时段变化超过一定百分比。适合流量类指标比如 QPS 突降 50% 基本说明服务已经拒流量了。持续型连续 N 个周期超过均值主要用于性能退化类场景避免单次抖动误报。组合型多条件同时满足才触发用于降低误报。比如“错误率 1% 且 QPS 正常”。我在实际配置里用的最多的组合是“阈值 持续时间”因为单点抖动其实很常见几分钟自愈没必要告警。而真正要告警的是“持续超过预期”的异常。一个具体例子配置错误率的告警规则大概是这样groups: - name: plfm_radar_alerts rules: - alert: HighErrorRate expr: | sum(rate(http_requests_total{status~5..}[5m])) / sum(rate(http_requests_total[5m])) 0.01 for: 5m labels: severity: warning annotations: summary: 接口错误率超过1% description: 服务 {{ $labels.service }} 最近5分钟错误率超过1%这里最关键的两个地方是expr里的rate(...,[5m])和for: 5m。rate要的是比率的平滑曲线单点瞬时抖动会被过滤掉而for: 5m是“持续 5 分钟”条件进一步降低误报。有个教训是很多人喜欢把阈值压得很低恨不得错误率超过 0.1% 就告警结果一天告警量上百条大家全都疲劳了真出问题时反而没人看。阈值设定要以“这个异常如果没有处理会真实影响用户”为准不然就是噪音。3.3 告警通知与收敛策略告警收敛是我特别想强调的。一个平台如果每个小抖动都发消息运营成本极高。我用了几种收敛策略一是沉默期。同一个规则、同一个服务在一个沉默窗口内只发一次。比如错误率规则设定 30 分钟沉默期也就是说第一次触发后30 分钟内同样的告警不再重复发送。二是依赖聚合。当根因 A 导致服务 B 也报错只告警根因不派生子告警。比如基础设施网络抖动导致三个服务错误率同时上升那我只报“网络抖动”一条下游服务错误的关联信息放到详情里。三是升级策略。严重级别从 P3提示到 P0紧急P3 只写日志P2 才推消息P1/P0 直接拉电话会议或者站内强提醒。不要把 P3 当成 P1 来发否则真正紧急的告警会被淹没在消息海洋里。通知渠道我用的是 Webhook 接企业微信/钉钉/飞书好处是完全可控逻辑上也好处理。如果你要用邮件建议走独立的告警邮箱不要用个人邮箱不然刷屏被忽略的概率很大而且容易被邮箱服务商限流。3.4 告警上下文快照的生成PLFM_RADAR 里每个告警都会附带一个“上下文快照”这是它区别于传统监控的鲜明特征。快照内容包括触发时间窗口、命中指标的实际值、最近 5 分钟日志错误摘要、最近 2 小时内的发布/变更事件、关联 traceId 的 Top 5 样本。{ alert: HighErrorRate, service: plfm-app, severity: P2, window: 2024-06-12 10:00:00 ~ 2024-06-12 10:05:00, metric_value: 0.027, error_log_summary: [ {level: ERROR, msg: connection reset by peer, count: 321}, {msg: timeout waiting for connection from pool, count: 108} ], recent_events: [ {type: deploy, service: plfm-app, time: 2024-06-12 09:58:00, version: v3.2.1} ] }这个快照会塞进 Webhook 的 payload 里和告警消息一起推出去。收到消息的人不用再去翻系统直接就能判断事情的严重程度和大致方向。我后来复盘了多次故障发现 90% 的情况快照里的信息已经足够定位问题起点。4. 实操落地从零搭建一套 PLFM_RADAR4.1 初始化采集端我这套搭建过程不靠复杂镜像直接在一台独立的观测服务器上装核心组件。步骤大致如下先装 Prometheus、Grafana、Loki、Alertmanager以及 ClickHouse。这些都可以用本地安装或容器方式运行。我优先用独立的二进制方式因为排查日志和版本控制更直接如果你只是先试用docker-compose 也完全够用。装完基础组件后第一步不是去 Grafana 拖面板而是先把 Prometheus 的抓取配置写好。这里有个容易踩的坑每个服务要有独立 job并打上统一标签比如service、env不然后面做聚合查询时根本没法按服务过滤。scrape_configs: - job_name: plfm-app metrics_path: /metrics static_configs: - targets: [192.168.10.21:9100, 192.168.10.22:9100] labels: service: plfm-app env: prod如果你用 Docker 跑服务建议给容器单独暴露一个 metrics 端口或者用 exporter 方式。不要图省事全走宿主端口否则后面端口规划会乱成一锅粥。日志采集部分我给每个服务配置了类型为service_log的 Loki 标签并且约定日志 key 必须是ts, level, service, msg。即使现在还没改造完也要强行在日志输出层加一层拦截器把关键字段补上。这一块越早规范后面越省事。等采集链路通了用curl或者浏览器打开 metrics 端口能看到类似http_requests_total 12345这样的输出基本就算成功。这一步没什么捷径就是一遍遍调抓取配置和标签。4.2 配置核心告警规则我落地的最早三条告警规则是服务不可用探活成功率为 0持续 60 秒。接口错误率5xx 占比大于 1%持续 5 分钟。磁盘容量使用率大于 85%持续 10 分钟。这三条规则覆盖了最核心的稳定性问题。规则文件我放在固定目录并且用 git 管理。每次改动规则都走评审流程因为告警规则改错比不加规则带来的问题还大。我见过有人把阈值从 80% 改到 95%结果系统真的出问题时完全无感知因为他觉得“95% 也在合理范围”。配置完规则后再配置 Alertmanager 的 webhook 地址。Webhook 的 payload 需要包含标题、内容、级别、服务名、触发时间、上下文快照。我习惯把规则命中的原始指标值也放进去这样收到消息的人不需要再去翻系统直接能判断事情的严重程度。4.3 搭建可视化大屏大屏不是给机器看的是给人看的所以设计原则就是一眼看出当前状态。我把 PLFM_RADAR 的大屏分成了四个区域顶部服务健康度总览红绿灯式展示左侧实时指标曲线如 QPS、延迟、错误率中间最近告警事件流右侧最近发布与变更事件时间轴。Grafana 配置的主要难点是数据源关联特别是“点击一个服务名下面所有面板都过滤成该服务”的联动效果。这要在每个面板的变量里都使用同一个 template variable比如用$service。具体操作是在 Grafana 的 Settings 里添加一个template variable类型选 Query查询语句从 Prometheus 或 ClickHouse 拉服务列表。然后每个面板的查询里都用$service做过滤。这样点击顶部下拉菜单切换服务所有面板都会联动刷新。这一步很多新手容易漏导致面板只能静态展示无法做下钻。如果出现“为什么我点了服务名下面面板没反应”的情况大概率是变量没有全局复用。我还做了一个“时间轴复盘视图”用 ClickHouse 事件数据渲染服务发布、配置变更和告警时间线。这个视图在故障复盘时非常好用能直接回答“那个时间点到底发生过什么”。复盘事故时拉出这张图往往比翻聊天记录管用得多。4.4 告警消息模板的细节别小看告警消息模板它决定了你收到消息后的第一反应。我的模板长这样[PLFM_RADAR][P2] plfm-app 接口错误率异常 时间2024-06-12 10:00 ~ 10:05 当前值2.7%阈值1% 最近事件10:00 发布 v3.2.1 错误摘要connection reset by peer (321次) 服务实例192.168.10.21:9100 面板直达https://grafana.xxx/d/plfm?serviceplfm-app要点就一个把需要决策的信息放在前两行把用于深入排查的链接放在最后。判断要不要马上处理看前两行就够了确定要处理再点链接进去看细节。我见过有些团队把告警消息做成五百字小作文读一遍要一分钟完全失去了告警的意义。5. 常见问题与排查实录5.1 高频问题速查表现象可能原因排查方向告警风暴沉默期没配 / 阈值过低检查规则 for 字段和 repeat_interval采集数据为空指标端口没暴露 / 标签不一致curl 抓一下 metrics 接口日志检索不到标签配置不对 / 保留周期太短检查 Loki 的 label 配置面板无数据数据源权限 / 时间范围不对检查 Grafana 数据源连接Webhook 没收到URL 或签名校验失败先手动 curl 测试 Webhook延迟超标但其他都正常单个慢查询拖累按 traceId 定位到具体 SQL告警误报率高单点抖动没有持续时间条件加上 for 条件再观察联动分析没输出事件数据缺时间戳检查 ClickHouse 表结构指标存储膨胀高基数标签打进了指标把高基数字段移到日志/事件库这张表我贴在工位旁边新同学上手排查时照着查已经帮他们省了不少冤枉路。如果你是自己搭出问题不要慌先对照这张表排除最基础的配置问题再去想更复杂的业务逻辑。5.2 三个真实踩坑记录第一个坑是时序库标签爆炸。刚开始采集时我把request_id也放到了 Prometheus 标签里结果一个高并发服务直接把时序库撑爆了。这个错误特别典型Prometheus 要求标签基数要低高基数的字段应该放日志而不是放指标。后来我把所有高基数标签全部从指标采集里移除只保留服务名、接口名等少量标签存储压力一下降了 80%。第二个坑是日志采集和日志查询的性能矛盾。一开始为了检索方便给每一行日志都加了很多标签结果是写入变慢、成本变高。后来我改了策略日志只保留几个必选标签需要全文检索的关键字放到请求参数里。这样虽然查询稍慢一点但整体吞吐恢复正常。记住一个原则标签是索引的钥匙不是数据的复制品。第三个坑是告警升级层级的混乱。最开始我所有告警都是同一级别结果是同事逐渐麻木连 P0 告警都有人过了半小时才看。后来我强行按“影响用户范围”和“持续时长”来分等级。现在只有 P1 级别以上才打紧急电话其他走消息告警的响应质量反而好得多。分级不是为了把告警变少而是为了让大家知道哪些告警真的值得放下手头的事来处理。5.3 独家经验与心得做 PLFM_RADAR 这段时间有几条经验是踩过坑之后才真正认可的第一先解决“链路通”再解决“指标准”。很多人一上来就调各种高级算法结果数据根本没采集全没有任何意义。我把采集链路跑通花的时间比搭告警规则多了一倍但这段时间绝对值得。链路通了后面所有分析才有基础。第二规则要有人维护。告警规则不是配一次就完事业务在变指标在变规则就必须跟着变。我每两周会给规则做一次“误报率体检”把一个月没触发过的规则、以及连续误报的规则全部过一遍。该删的删该调阈值的调阈值该加沉默期的加沉默期。别觉得这是工作量这其实是告警质量的生命线。第三一切输出必须可解释。不管是告警消息、大屏面板还是复盘报告都要让一个从没看过你这个系统的人能在 5 分钟内看懂。我有个小练习每个月拉一次一个新的实习生让他只看面板和告警记录描述昨天发生了什么。如果他说不清说明我们的输出还不够直观就该调整了。第四不要太依赖自动化根因分析。PLFM_RADAR 可以把上下文关联好、把时间线拉清楚但“为什么是这个问题”的判断很多时候还是需要人来完成。工具要做的是降低人的分析成本而不是替代人的判断。我在实际使用中还有一个体会想单独说一说告警消息里一定要写“下一步该做什么”。很多告警只告诉“什么坏了”但没有告诉“现在该看哪”。我在每条告警的模板里都留了一个next_step字段比如“先检查 plfm-app 最近发布再查数据库连接池”。这样值班同学收到告警后不用猜直接按步骤走。刚开始加这个字段时觉得麻烦后来发现它让值班效率提升特别明显深夜被吵醒的人大脑本来就不转有个明确的下一步动作比什么都重要。6. 这套系统的后续还能怎么长PLFM_RADAR 现在已经在稳定运行但我很清楚它不是一个“做完”的项目雷达这东西本来就是越转越聪明的。后面我计划加的方向主要有三个一个是接入更多业务语义。现在告警更多看的是技术指标比如错误率、延迟。但业务指标同样关键比如订单失败率、支付成功率。这类指标往往更能直接反映用户体感以后会把它们纳入雷达扫描范围。第二个是把异常检测从“规则”升级到“基线”。现在主要依赖阈值和持续时间后面打算引入简单的历史基线对比让系统根据过去 7 天同时段的数据自动判断“今天这个波动是不是正常的”。这样做的好处是减少人工调参频率坏处是需要更长的历史数据积累。我目前还在观察阈值规则的稳定性不急着上模型因为模型一旦不解释反而更难维护。第三个是更精细的容量预判。现在容量指标只是“到达阈值告警”属于事后反应。后面计划用历史增长曲线做趋势外推做到“未来 72 小时磁盘可能打满”的提前预告。这个功能对设备告警特别有价值因为它有效避免了半夜被磁盘打满的告警叫醒。这些方向我不急着一次全做完雷达的扫描半径是一圈一圈扩大的系统的运维能力也是一层一层往上走的。能保证每天稳定扫描、告警可解释、复盘有依据PLFM_RADAR 作为“平台雷达”的使命就已经完成了大半。如果你也准备给自家平台装一套类似的雷达我的建议很简单先跑通链路再定规则最后才谈面板美观和智能分析。把地基打好雷达转起来之后你会发现“提前感知问题”这件事真的比“快速响应问题”轻松太多了。