1. 数据服务监控的核心定位与整体思路1.1 为什么监控是数据中台落地成败的关键聊到数据中台很多团队的第一反应是数据模型怎么设计、指标口径怎么统一、数据迁移怎么把异构系统的数据搬过来。这些确实是中台建设的地基和承重墙但我做了这么多年数据平台见到的翻车现场往往不是建不起来而是建起来之后没人能说清楚某个数据服务现在到底跑得好不好。数据中台对外输出的本质是服务是一堆被封装成 API 的数据查询、数据推送、数据加工能力。业务系统不会关心你底层是 Hive 还是 StarRocks也不会关心你的血缘链路有几层他们只关心一个问题这次调用能不能拿到数据结果对不对响应快不快。数据服务监控干的事情就是替中台回答这个三连问。我见过太多团队在立项时把监控列为上线后再补的工作结果上线第一天就被十几个业务群同时说报表数据刷不出来、接口超时、推送任务卡死。这时候再去补监控相当于失火了才开始砌防火墙成本往往高出一个量级。所以我的经验是数据服务监控不是中台的一个可选模块而是和元数据管理、数据质量管理并列的第三根支柱。它解决的是服务可信度的问题——数据迁移再顺、模型设计再优雅如果服务交付环节不可见、不可控中台在业务眼里就是个黑盒。1.2 监控范围界定别把监控做成全家桶很多刚入行的同学容易犯一个毛病一说做监控就觉得什么都得盯着。集群 CPU、磁盘 IO、内存水位、Pod 重启次数、代码异常日志……全都堆在一个大盘上最后的结果是告警一天几百条真正有事的时候反而没人看。数据服务监控的边界应该清晰它监控的是服务本身不是基础设施。我通常把监控范围框在四层服务层对外暴露的 API 的可用性、响应时间、成功率、调用量趋势。数据层服务依赖的表、数据文件、缓存是否就绪数据更新时效是否达标。任务层支撑数据服务的调度任务比如每小时跑一次的指标汇总是否按时成功产出。链路层一个服务从收到请求到返回结果内部经历的完整链路状态。基础设施监控比如机器负载可以交给运维侧原有的 Prometheus Grafana 体系不需要在中台监控里重复建设。中台监控的核心是抓住用户可感知的质量把基础设施指标收敛为服务健康度的输入而不是堆给业务看。1.3 数据服务监控解决的问题清单在动手设计之前先罗列清楚监控要回答的业务问题这样后面选指标、选工具才不会跑偏。我梳理的清单大致如下问题监控给出的答案这个接口现在还通不通可用性探活结果、错误率响应怎么突然变慢了TP99、平均响应时间变化曲线数据为什么是昨天的数据新鲜度指标、任务产出延迟查询结果对不对数据质量校验规则通过率会不会被打爆调用量、并发量、限流触发次数数据迁移后服务是否正常迁移前后响应比对、源和目标数据一致性校验这张清单是后续所有监控指标的来源。别小看这一步很多时候团队的监控做得散就是因为没有先回答我到底要为谁回答什么问题。把清单列出来之后你自然就知道哪些指标该埋、哪些告警该设、哪些大盘该建。2. 监控指标体系设计与告警策略2.1 四类核心指标可用性、性能、数据质量、容量指标设计是整个监控体系的灵魂。指标定多了存储和运维成本翻倍告警噪音也大定少了关键问题发现不了。我比较推荐按四类来收敛每一类只抓最能反映服务质量的几个关键值。可用性指标最核心的是接口成功率和可用性探活结果。成功率不是单纯算 2xx 的比例而是要把 4xx参数错误和 5xx服务错误分开。4xx 是调用方的问题不影响服务健康的判断5xx 和超时才是服务侧需要关注的。我习惯用这个公式来算服务的月度可用性可用性 (总请求数 - 5xx错误数 - 超时请求数) / 总请求数 * 100%注意超时请求也要算是不可用的因为对调用方来说等不到结果就等于失败。这个公式算出来的可用性才是业务真正感受到的可用性。性能指标必监控响应时间分布重点关注 TP99 和 TP50。很多新手只看平均响应时间这是个坑平均 100ms 的背后可能是 90% 的请求 20ms 加上 10% 的请求 820ms大家用起来明显卡顿但平均值看起来还挺漂亮。TP99 才是真实体验的下限。对于数据查询类服务还需要额外监控扫描行数和返回数据量。这两个指标能从侧面暴露接口抖动的原因——很多时候响应变慢不是因为代码问题而是上游业务传入的查询条件导致扫描了平时十倍的数据量。数据质量指标数据服务最怕的不是慢而是返回结果错了还浑然不知。数据质量和监控的关系很多人没想清楚我建议至少建两个层面的校验离线校验和在线校验。离线校验是在数据落库后定时跑数据质量规则比如非空率、主键唯一性、枚举值合法性、同比环比波动幅度。在线校验则是在接口返回前对关键字段做轻量校验比如金额不为负、时间格式正确。我曾在生产环境遇到过客户投诉用户等级接口返回的数据和报表对不上排查了很久才发现是数据仓库夜间迁移时产生了一条重记录导致明细表里用户等级被覆盖成旧值。如果在线校验里加了返回结果与基线表一致的规则这个问题在服务层就能拦住根本不会漏给业务。容量指标容量监控的目标是防患于未然。核心指标包括接口调用量环比增长幅度、当前 QPS 与压测得出的最大 QPS 的比值、数据表存储增长速率、任务处理数据量趋势。容量问题往往是渐进式的今天没暴雷不代表下周不会。比如一个查询接口设计时压测能撑 600 QPS业务接入量每个月增长 30%三个月之后就逼近阈值了。如果监控里有QPS 距离上限还有多远这个指标就可以提前扩容或让业务限流而不是某天下午突然被大量超时告警砸醒。2.2 告警阈值的设定方法与最佳实践阈值设得好不好直接决定监控系统有没有人信。我的经验是阈值必须来自实测不能拍脑袋。第一步先压测。任何一个对外提供的数据服务上线前都应该做过一轮压测拿到两个基准值正常情况下的 TP99 基线、系统濒临崩溃时的 TP99。前者决定了性能告警的注意级别阈值后者决定了严重级别阈值。第二步设定分级。我习惯用 P0/P1/P2 三级级别典型场景响应时效P0核心接口不可用、数据完全缺失立即打电话P1核心接口 TP99 超基线 2 倍、数据延迟超过 1 小时15 分钟内响应P2非核心接口颤抖、容量水位接近 70%工作时间处理第三步设置抑制窗口。告警刚触发的前 5 分钟内先进入 pending状态即预警告级别如果持续超过 5 分钟再真正发出。这样能过滤掉瞬时抖动又不至于漏掉持续故障。我当时给几个核心查询接口设置的规则是成功率低于 99.5% 且持续时间超过 3 分钟触发 P1 告警低于 98% 立即触发 P0。第四步注意阈值要跟着业务演进动态调整。每次版本迭代、数据量翻倍都要重新审视阈值是否需要调整。我见过一个团队把成功率阈值定死在 99.9%结果上了个新业务数据源偶尔会合并全量数据导致查询变慢每天夜里固定触发告警值班同学连续被骚扰了一个星期——后来把阈值改成低于基线 2 个点再告警世界就清净了。3. 监控工具选型开源方案与自研路径3.1 Java 开源数据中台生态下的监控组件选型最近两三年Java 系的开源数据中台项目热度一直不低。很多团队从零开始搭中台会更倾向于基于开源框架来做二次开发。这个思路我认可但监控模块要特别注意复用开源组件时不是越全越好而是越省事越好。主流的选择有这么几类组件定位适用场景Prometheus Grafana指标采集与可视化服务类指标监控社区生态成熟和 Spring Boot 集成最顺Elasticsearch Kibana日志采集与检索链路追踪、错误日志分析适合查询类服务的问题定位SkyWalking分布式链路追踪微服务架构下的全链路监控能自动生成拓扑图Apache Griffin数据质量监控专门做数据质量度量适合离线数据校验Airflow / DolphinScheduler 自带监控任务调度状态监控数据任务是否按时跑完和调度平台天然集成我自己比较常用的组合是服务指标走 Prometheus Grafana任务调度状态和日志走 DolphinScheduler 自带的告警 Elasticsearch 日志检索数据质量单独接 Apache Griffin。这套组合的好处是每个组件都在干自己最擅长的事不需要强行用一个工具解决所有问题。如果你是 Spring Boot 技术栈的 Java 中台项目接入 Prometheus 非常顺加一个 micrometer-registry-prometheus 依赖在启动类上扫一下注解几行代码就能把接口的 QPS、响应时间、JVM 指标暴露到一个/actuator/prometheus端点。Grafana 侧导入 Spring Boot 官方仪表盘模板基本拿来即用。3.2 自研监控的取舍和架构设计考量开源组件虽然省事但有些场景确实得自研。最常见的两种情况第一种是监控诉求非常定制化。比如你们要监控每个业务域的数据服务分别消耗了多少计算资源并且要按部门出账单这是开源组件没法直接给的只能自己采集指标后加工聚合。第二种是开源组件的告警能力太薄弱。Prometheus 自带的 Alertmanager 能配置告警但业务方往往需要告警升级、排班表、告警多级路由、与内部 IM 深度集成这些个性化功能越往深度做越要自己掌握逻辑。自研监控系统的架构我建议遵循一条原则不要让采集、存储、告警全都自己造。自研的范围应该收敛在指标加工和告警编排这两层采集和存储尽量复用基础设施。一个比较合理的分层设计是这样的采集层用 Prometheus 的 Exporter 机制或自研轻量采集器把埋点数据打成标准 Metrics。存储层Prometheus 负责时序存储底层用 TSDB日志类走 Elasticsearch。计算层自研一个轻量计算服务订阅原始指标按服务维度、业务域维度做聚合产出健康分、可用性、趋势等衍生指标。告警层自研一个告警编排引擎负责配置告警规则、去重收敛、分级路由、值班组通知。服务层提供一套 HTTP API 和可视化界面支撑业务方自助查询服务状态。这样设计的好处是每层都能独立演进而且不用在存储和采集上重复造轮子。4. 实操搭建一套数据服务监控的完整步骤4.1 前置准备与埋点设计开始动工之前先梳理清单。我按下面的流程走一遍基本不会漏东西明确监控对象列出要接入监控的数据服务清单包括接口名、所属业务域、服务负责人、SLA 等级。梳理依赖每个服务依赖的下游表和任务整理成一张依赖清单。后面做关联分析时用得上。设计埋点确定每个服务要暴露哪些指标统一命名规范。选定工具根据现有技术栈确定监控组件组合。建立权限确保监控系统的账号权限和告警值班表提前配好。埋点设计是我最想强调的一步。指标命名不规范是后面所有混乱的根源。我做两个硬性要求所有指标名必须包含服务名、接口类型、业务域三个标签。所有指标统一使用短横线命名法禁止大小写混写。举一个实际例子。对于一个用户画像查询服务指标名是这样的data_service_query_total{serviceuser-profile, endpoint/v1/profile, domainmarketing} data_service_query_latency_seconds{serviceuser-profile, endpoint/v1/profile} data_service_query_error_total{serviceuser-profile, endpoint/v1/profile, error_type5xx}这三个指标分别表示了调用量、响应时间、错误量标签里带了服务和域名信息。后面做聚合分析时可以用 PromQL 一句表达式按业务域汇总非常方便。4.2 指标采集与可视化配置埋点逻辑写好后采集这块用 Prometheus 的话配置很简单。核心是在 prometheus.yml 里加上抓取任务scrape_configs: - job_name: data-service metrics_path: /actuator/prometheus scrape_interval: 15s static_configs: - targets: [data-service-a:8080, data-service-b:8080] labels: app: data-middle-platform15 秒的抓取间隔对大多数数据服务都够了。如果你有那种秒级波动的核心接口可以单独把 scrape_interval 调到 5 秒但要注意存储量会增大没必要所有服务都上这个强度。可视化层我用 Grafana 配了几块典型的看板总览板所有数据服务的在线数量、平均可用性、今日调用总量、P0 告警总数。这块是Leader和技术负责人每天扫一眼的。服务明细板单个服务的成功率折线、响应时间分布热力图、调用量曲线、容量水位。给服务负责人看。数据质量板数据校验规则通过率、延迟数据时长、源和目标不一致计数。给数据开发同学看。配置 Grafana 仪表盘时有一个小技巧不要直接从官方社区拷贝一个就完事要把面板里的查询表达式改成自己服务对应的标签。我见过最尴尬的情况是监控大盘搭好了但查的还是 demo 服务的指标一点意义都没有。4.3 告警规则配置与值班联动告警是监控系统最有存在感的部分也是最容易翻车的部分。我在前面已经讲了阈值分级这节重点讲规则配置的写法。Prometheus 的告警规则文件用 YAML 描述。拿核心接口成功率规则举例groups: - name:> 数据中台服务监控实战：从指标体系到告警治理
1. 数据服务监控的核心定位与整体思路1.1 为什么监控是数据中台落地成败的关键聊到数据中台很多团队的第一反应是数据模型怎么设计、指标口径怎么统一、数据迁移怎么把异构系统的数据搬过来。这些确实是中台建设的地基和承重墙但我做了这么多年数据平台见到的翻车现场往往不是建不起来而是建起来之后没人能说清楚某个数据服务现在到底跑得好不好。数据中台对外输出的本质是服务是一堆被封装成 API 的数据查询、数据推送、数据加工能力。业务系统不会关心你底层是 Hive 还是 StarRocks也不会关心你的血缘链路有几层他们只关心一个问题这次调用能不能拿到数据结果对不对响应快不快。数据服务监控干的事情就是替中台回答这个三连问。我见过太多团队在立项时把监控列为上线后再补的工作结果上线第一天就被十几个业务群同时说报表数据刷不出来、接口超时、推送任务卡死。这时候再去补监控相当于失火了才开始砌防火墙成本往往高出一个量级。所以我的经验是数据服务监控不是中台的一个可选模块而是和元数据管理、数据质量管理并列的第三根支柱。它解决的是服务可信度的问题——数据迁移再顺、模型设计再优雅如果服务交付环节不可见、不可控中台在业务眼里就是个黑盒。1.2 监控范围界定别把监控做成全家桶很多刚入行的同学容易犯一个毛病一说做监控就觉得什么都得盯着。集群 CPU、磁盘 IO、内存水位、Pod 重启次数、代码异常日志……全都堆在一个大盘上最后的结果是告警一天几百条真正有事的时候反而没人看。数据服务监控的边界应该清晰它监控的是服务本身不是基础设施。我通常把监控范围框在四层服务层对外暴露的 API 的可用性、响应时间、成功率、调用量趋势。数据层服务依赖的表、数据文件、缓存是否就绪数据更新时效是否达标。任务层支撑数据服务的调度任务比如每小时跑一次的指标汇总是否按时成功产出。链路层一个服务从收到请求到返回结果内部经历的完整链路状态。基础设施监控比如机器负载可以交给运维侧原有的 Prometheus Grafana 体系不需要在中台监控里重复建设。中台监控的核心是抓住用户可感知的质量把基础设施指标收敛为服务健康度的输入而不是堆给业务看。1.3 数据服务监控解决的问题清单在动手设计之前先罗列清楚监控要回答的业务问题这样后面选指标、选工具才不会跑偏。我梳理的清单大致如下问题监控给出的答案这个接口现在还通不通可用性探活结果、错误率响应怎么突然变慢了TP99、平均响应时间变化曲线数据为什么是昨天的数据新鲜度指标、任务产出延迟查询结果对不对数据质量校验规则通过率会不会被打爆调用量、并发量、限流触发次数数据迁移后服务是否正常迁移前后响应比对、源和目标数据一致性校验这张清单是后续所有监控指标的来源。别小看这一步很多时候团队的监控做得散就是因为没有先回答我到底要为谁回答什么问题。把清单列出来之后你自然就知道哪些指标该埋、哪些告警该设、哪些大盘该建。2. 监控指标体系设计与告警策略2.1 四类核心指标可用性、性能、数据质量、容量指标设计是整个监控体系的灵魂。指标定多了存储和运维成本翻倍告警噪音也大定少了关键问题发现不了。我比较推荐按四类来收敛每一类只抓最能反映服务质量的几个关键值。可用性指标最核心的是接口成功率和可用性探活结果。成功率不是单纯算 2xx 的比例而是要把 4xx参数错误和 5xx服务错误分开。4xx 是调用方的问题不影响服务健康的判断5xx 和超时才是服务侧需要关注的。我习惯用这个公式来算服务的月度可用性可用性 (总请求数 - 5xx错误数 - 超时请求数) / 总请求数 * 100%注意超时请求也要算是不可用的因为对调用方来说等不到结果就等于失败。这个公式算出来的可用性才是业务真正感受到的可用性。性能指标必监控响应时间分布重点关注 TP99 和 TP50。很多新手只看平均响应时间这是个坑平均 100ms 的背后可能是 90% 的请求 20ms 加上 10% 的请求 820ms大家用起来明显卡顿但平均值看起来还挺漂亮。TP99 才是真实体验的下限。对于数据查询类服务还需要额外监控扫描行数和返回数据量。这两个指标能从侧面暴露接口抖动的原因——很多时候响应变慢不是因为代码问题而是上游业务传入的查询条件导致扫描了平时十倍的数据量。数据质量指标数据服务最怕的不是慢而是返回结果错了还浑然不知。数据质量和监控的关系很多人没想清楚我建议至少建两个层面的校验离线校验和在线校验。离线校验是在数据落库后定时跑数据质量规则比如非空率、主键唯一性、枚举值合法性、同比环比波动幅度。在线校验则是在接口返回前对关键字段做轻量校验比如金额不为负、时间格式正确。我曾在生产环境遇到过客户投诉用户等级接口返回的数据和报表对不上排查了很久才发现是数据仓库夜间迁移时产生了一条重记录导致明细表里用户等级被覆盖成旧值。如果在线校验里加了返回结果与基线表一致的规则这个问题在服务层就能拦住根本不会漏给业务。容量指标容量监控的目标是防患于未然。核心指标包括接口调用量环比增长幅度、当前 QPS 与压测得出的最大 QPS 的比值、数据表存储增长速率、任务处理数据量趋势。容量问题往往是渐进式的今天没暴雷不代表下周不会。比如一个查询接口设计时压测能撑 600 QPS业务接入量每个月增长 30%三个月之后就逼近阈值了。如果监控里有QPS 距离上限还有多远这个指标就可以提前扩容或让业务限流而不是某天下午突然被大量超时告警砸醒。2.2 告警阈值的设定方法与最佳实践阈值设得好不好直接决定监控系统有没有人信。我的经验是阈值必须来自实测不能拍脑袋。第一步先压测。任何一个对外提供的数据服务上线前都应该做过一轮压测拿到两个基准值正常情况下的 TP99 基线、系统濒临崩溃时的 TP99。前者决定了性能告警的注意级别阈值后者决定了严重级别阈值。第二步设定分级。我习惯用 P0/P1/P2 三级级别典型场景响应时效P0核心接口不可用、数据完全缺失立即打电话P1核心接口 TP99 超基线 2 倍、数据延迟超过 1 小时15 分钟内响应P2非核心接口颤抖、容量水位接近 70%工作时间处理第三步设置抑制窗口。告警刚触发的前 5 分钟内先进入 pending状态即预警告级别如果持续超过 5 分钟再真正发出。这样能过滤掉瞬时抖动又不至于漏掉持续故障。我当时给几个核心查询接口设置的规则是成功率低于 99.5% 且持续时间超过 3 分钟触发 P1 告警低于 98% 立即触发 P0。第四步注意阈值要跟着业务演进动态调整。每次版本迭代、数据量翻倍都要重新审视阈值是否需要调整。我见过一个团队把成功率阈值定死在 99.9%结果上了个新业务数据源偶尔会合并全量数据导致查询变慢每天夜里固定触发告警值班同学连续被骚扰了一个星期——后来把阈值改成低于基线 2 个点再告警世界就清净了。3. 监控工具选型开源方案与自研路径3.1 Java 开源数据中台生态下的监控组件选型最近两三年Java 系的开源数据中台项目热度一直不低。很多团队从零开始搭中台会更倾向于基于开源框架来做二次开发。这个思路我认可但监控模块要特别注意复用开源组件时不是越全越好而是越省事越好。主流的选择有这么几类组件定位适用场景Prometheus Grafana指标采集与可视化服务类指标监控社区生态成熟和 Spring Boot 集成最顺Elasticsearch Kibana日志采集与检索链路追踪、错误日志分析适合查询类服务的问题定位SkyWalking分布式链路追踪微服务架构下的全链路监控能自动生成拓扑图Apache Griffin数据质量监控专门做数据质量度量适合离线数据校验Airflow / DolphinScheduler 自带监控任务调度状态监控数据任务是否按时跑完和调度平台天然集成我自己比较常用的组合是服务指标走 Prometheus Grafana任务调度状态和日志走 DolphinScheduler 自带的告警 Elasticsearch 日志检索数据质量单独接 Apache Griffin。这套组合的好处是每个组件都在干自己最擅长的事不需要强行用一个工具解决所有问题。如果你是 Spring Boot 技术栈的 Java 中台项目接入 Prometheus 非常顺加一个 micrometer-registry-prometheus 依赖在启动类上扫一下注解几行代码就能把接口的 QPS、响应时间、JVM 指标暴露到一个/actuator/prometheus端点。Grafana 侧导入 Spring Boot 官方仪表盘模板基本拿来即用。3.2 自研监控的取舍和架构设计考量开源组件虽然省事但有些场景确实得自研。最常见的两种情况第一种是监控诉求非常定制化。比如你们要监控每个业务域的数据服务分别消耗了多少计算资源并且要按部门出账单这是开源组件没法直接给的只能自己采集指标后加工聚合。第二种是开源组件的告警能力太薄弱。Prometheus 自带的 Alertmanager 能配置告警但业务方往往需要告警升级、排班表、告警多级路由、与内部 IM 深度集成这些个性化功能越往深度做越要自己掌握逻辑。自研监控系统的架构我建议遵循一条原则不要让采集、存储、告警全都自己造。自研的范围应该收敛在指标加工和告警编排这两层采集和存储尽量复用基础设施。一个比较合理的分层设计是这样的采集层用 Prometheus 的 Exporter 机制或自研轻量采集器把埋点数据打成标准 Metrics。存储层Prometheus 负责时序存储底层用 TSDB日志类走 Elasticsearch。计算层自研一个轻量计算服务订阅原始指标按服务维度、业务域维度做聚合产出健康分、可用性、趋势等衍生指标。告警层自研一个告警编排引擎负责配置告警规则、去重收敛、分级路由、值班组通知。服务层提供一套 HTTP API 和可视化界面支撑业务方自助查询服务状态。这样设计的好处是每层都能独立演进而且不用在存储和采集上重复造轮子。4. 实操搭建一套数据服务监控的完整步骤4.1 前置准备与埋点设计开始动工之前先梳理清单。我按下面的流程走一遍基本不会漏东西明确监控对象列出要接入监控的数据服务清单包括接口名、所属业务域、服务负责人、SLA 等级。梳理依赖每个服务依赖的下游表和任务整理成一张依赖清单。后面做关联分析时用得上。设计埋点确定每个服务要暴露哪些指标统一命名规范。选定工具根据现有技术栈确定监控组件组合。建立权限确保监控系统的账号权限和告警值班表提前配好。埋点设计是我最想强调的一步。指标命名不规范是后面所有混乱的根源。我做两个硬性要求所有指标名必须包含服务名、接口类型、业务域三个标签。所有指标统一使用短横线命名法禁止大小写混写。举一个实际例子。对于一个用户画像查询服务指标名是这样的data_service_query_total{serviceuser-profile, endpoint/v1/profile, domainmarketing} data_service_query_latency_seconds{serviceuser-profile, endpoint/v1/profile} data_service_query_error_total{serviceuser-profile, endpoint/v1/profile, error_type5xx}这三个指标分别表示了调用量、响应时间、错误量标签里带了服务和域名信息。后面做聚合分析时可以用 PromQL 一句表达式按业务域汇总非常方便。4.2 指标采集与可视化配置埋点逻辑写好后采集这块用 Prometheus 的话配置很简单。核心是在 prometheus.yml 里加上抓取任务scrape_configs: - job_name: data-service metrics_path: /actuator/prometheus scrape_interval: 15s static_configs: - targets: [data-service-a:8080, data-service-b:8080] labels: app: data-middle-platform15 秒的抓取间隔对大多数数据服务都够了。如果你有那种秒级波动的核心接口可以单独把 scrape_interval 调到 5 秒但要注意存储量会增大没必要所有服务都上这个强度。可视化层我用 Grafana 配了几块典型的看板总览板所有数据服务的在线数量、平均可用性、今日调用总量、P0 告警总数。这块是Leader和技术负责人每天扫一眼的。服务明细板单个服务的成功率折线、响应时间分布热力图、调用量曲线、容量水位。给服务负责人看。数据质量板数据校验规则通过率、延迟数据时长、源和目标不一致计数。给数据开发同学看。配置 Grafana 仪表盘时有一个小技巧不要直接从官方社区拷贝一个就完事要把面板里的查询表达式改成自己服务对应的标签。我见过最尴尬的情况是监控大盘搭好了但查的还是 demo 服务的指标一点意义都没有。4.3 告警规则配置与值班联动告警是监控系统最有存在感的部分也是最容易翻车的部分。我在前面已经讲了阈值分级这节重点讲规则配置的写法。Prometheus 的告警规则文件用 YAML 描述。拿核心接口成功率规则举例groups: - name:>