延迟明明只有300毫秒却一直报警，怎样对齐网关指标与告警单位

先把毫秒指标换算成秒，再与秒阈值比较。300毫秒是0.3秒，低于0.8秒；1000毫秒是一秒，应触发。仅改展示单位不会改变PromQL中参与比较的数值。

把日志字段与时序指标单位分开

检查从指标生产、记录规则到面板和告警的每一层单位。名称里带ms而面板显示s，不代表已经除以一千；告警通常直接执行表达式，完全不读取面板格式。建议新定义指标使用基本单位并在名字体现，迁移期保留明确转换规则，避免同名指标悄悄换单位。

建立输入到标准秒的换算链

实际promtool读取fast=300和slow=1000两条毫秒序列，记录规则除以一千得到seconds。正确阈值只选slow，错误地用毫秒直接与0.8比较则两条都入选。第三项检查单独断言fast转换后为0.3，防止通过调阈值碰巧得到相同告警数量。

单位迁移可以先新增带seconds后缀的记录指标，让告警逐步切换，避免旧面板仍把新值当毫秒。迁移期间要标出哪个名字使用哪种单位，防止同一指标名称在某些实例已换算、另一些实例仍原样输出。阈值说明中写出0.8秒比只写0.8更容易被复核。

核心表达式（完整建表与输入见附件）：

demo_latency_ms / 1000

说明历史序列切换不可仅改名

本文用的是合成gauge，不能把厂商已有直方图、分位数和平均值随意当成同一种指标。若原数据是累计时长与请求数，还需先按正确窗口计算平均；如果是histogram桶，单位也要与桶边界一致。单位修复不代表真实延迟根因已经解决。

适用范围：只处理自定义合成指标，不改写厂商现有指标类型或宣称真实延迟。

配套样本与复核入口

• run.py：独立运行程序，包含合成输入、操作和正反例断言。
• case.json：输入说明、预期任务与适用范围，便于保存和交接。
• observed.json：本次实际执行输出；临时路径、进程号和计时可能随运行变化。

运行后correct_alerts应为1、wrong_alerts应为2，同时fast_seconds应为0.3。该第三项用于证明转换确实发生，防止只是把错误阈值改到碰巧可用。把同样核对方式用于真实指标时，应在交接表里同时记录原单位、换算公式、目标单位和阈值，避免面板维护者与告警维护者各自作不同假设。

Python3.8以上与官方Prometheus3.5.0中的promtool。将工具加入PATH，或把PROMTOOL设为它的绝对路径。程序会在临时目录生成真实规则与测试输入，再调用promtool test rules；断言不符时退出失败，不用自造PromQL求值器替代。

python -B run.py

阅读输出时，先按case.json中的任务逐项核对网关延迟指标秒毫秒告警，再与observed.json比较。非零退出表示依赖或断言需要处理，应保留实际错误。

一手依据1（指标应带基本单位命名；不可把无界用户或请求ID放进高基数标签。）；一手依据2（promtool规则测试支持输入序列、求值时刻、预期告警和表达式值，_与stale分别表示缺样与陈旧。）。

继续阅读：拆成两条记录规则后网关看板慢一拍，怎样核对规则依赖的执行顺序；网关副本重启后请求速率突增，PromQL为何要先rate再sum；聚合层日志与可观测性实践：监控多模型 API 调用。