目录第一部分 原理第二部分 操作 PromQL第三部分 为一类服务设计最小指标集第四部分 告警 23 条第五部分 AI 要点第六部分 延伸对照第七部分 和 Logs / Traces 怎么接日志看「这一条事件」指标看「这一段时间整不整体变差」。告警主要建在指标上因为便宜、稳定、好设阈值。第一部分 原理1. Metric 是什么一条指标是时间序列不是一行日志指标名 标签集 时间戳 一个数字例如http_requests_total{serviceorder, code500} 1284 19:20:00含义到 19:20订单服务累计 HTTP 500 共 1284 次。这个数字本身是从进程启动到现在的累计看趋势要用后面的rate()不要直接当 QPS 画。和另外两柱对比LogsTracesMetrics记什么某次事件某次请求的 span 树聚合后的数字擅长原文、审计、堆栈这一单慢在哪一跳趋势、SLO、告警成本最高中可采样最低、可长期留1 万次请求日志可能 1 万行Trace 可能 1 万条或采样后更少Metric 可能只有「总数、错误数、几个延迟桶」几条序列。所以 看板和告警优先用指标定位某一次失败仍要回日志和链路。必看文档编辑OTel MetricsPrometheus 概念官方编辑Metric typesPromQL 入门编辑Querying basicsOpenObserve编辑Metrics Explorer编辑Metrics JSON 约定记住__name__、__type__、value视频B 站概念 PromQL 入门较短编辑尚硅谷 PrometheusGrafana重点看课程介绍、Prometheus 特点、架构、安装、第 8 集 PromQL、Grafana 数据源。睿象云/Flink 集可跳过。想再细一点的入门编辑2026 Prometheus 入门到精通 前半概述、架构、部署、node_exporter、PromQL。以后做 K8s 再看可暂缓编辑博哥爱运维 · 监控合集第 08 集架构、Prometheus、Alertmanager2. 四类指标这是 Prometheus / OpenTelemetry 的核心模型。1Counter计数器只增不减进程重启归零。适合请求数、错误数、字节数、重启次数。原值会一直爬升看速率必须rate()/increase()。http_requests_total 从启动到现在一共多少次rate(http_requests_total[5m]) 最近 5 分钟平均每秒多少次2Gauge仪表可上可下。适合CPU、内存、队列长度、在线连接、goroutine 数、温度。直接看当前值或avg_over_time()。不要对 Gauge 套rate()那是给 Counter 的。3Histogram直方图把观测值丢进预设桶例如延迟le0.1、0.5、1、Inf。实际存的是三条相关序列后缀含义_bucket{le0.5}延迟 ≤ 0.5s 的次数累计_sum延迟总和_count观测次数P99 是查询时用histogram_quantile(0.99, ...)算出来的不是客户端先算好再上报。桶在采集时就要设好全挤在一个桶里分位数会失真桶太多又费存储。Histogram直方图的预设桶事先规定好几档耗时上限请求结束时往对应的桶里 1。le是 less or equal小于等于单位一般是 秒。标签含义le0.1耗时 ≤ 0.1 秒100ms的请求累计有多少le0.5耗时 ≤ 0.5 秒 的累计有多少le1耗时 ≤ 1 秒 的累计有多少leInf耗时 ≤ 无穷大也就是 全部请求桶是累加的慢的请求会计入更大的le。Inf一定等于总次数。一次请求怎么进桶/save_stock花了 867ms ≈ 0.867 秒不算进le0.10.867 0.1不算进le0.50.867 0.5算进le10.867 ≤ 1算进leInf一定算若只有 50ms四个桶都会 1因为它 ≤ 0.1更 ≤ 0.5、1、Inf。所以le0.5的数字 所有不超过 500ms 的请求不是「正好落在 0.10.5 这一档」的个数。要某一档的个数用相邻桶相减例如le1 - le0.5≈ 0.51 秒之间的次数。为什么要预设桶指标不能把每一次耗时都存下来基数会爆。折中办法事先定几条线100ms、500ms、1s、无穷只记「有多少请求跨过了这条线」用这些累计次数 估算 P50 / P99histogram_quantile桶越密分位数越准序列也越多。桶是部署时定的事后不能改已经采进去的边界改le等于换了一组指标。和 P99 的关系P99 不是去翻每一笔 867ms而是问累计占比到 99% 时落在哪两个le之间。例如绝大部分在le1里、只有 1% 超过 1sP99 就会靠近 1s 附近。桶太粗只有 0.1 / 1 / Inf时P99 只能知道「大概不到 1 秒」细不了。记法预设桶 事先画好的耗时格子0.1s、0.5s、1s、无限lex 耗时 ≤ x 秒的 累计 次数Inf 总请求数用来算比例和兜底一句话不是四种独立计时器而是四道「不超过这么久」的累计门槛用来近似延迟分布和 P99。4Summary客户端自己算好分位数再上报。查询省事但不能事后再按新标签重新聚合不能把各实例的 P99 再平均成全局 P99。现在服务延迟更常用 Histogram。对应记忆问「现在多少」→ Gauge问「刚才多快 / 一共多少」→ Counter rate/increase问「P95/P99 / SLA 延迟」→ HistogramSummary 知道局限即可新埋点优先 Histogram分位数就是把一堆数字从小到大排好看「有百分之多少落在这个值以下」。P99 是第 99 百分位100 次里有 99 次比它快或相等最慢的那 1 次比它更差。接口耗时里说的 P99通常就是几乎所有请求都比这个时间快只有最慢的 1% 更慢。为什么不用平均数假设/save_stock100 次耗时毫秒99 次都在 200400ms1 次卡了 8000ms下游超时平均数会被那 1 次拉高看起来「整体变慢」但说不清有多少人真的慢。中位数P50则几乎看不见那 1 次看起来「一切正常」。分位数把「大部分人」和「最倒霉的那一截」分开看。名字含义谁在用这个体验P50中位数一半请求比它快普通用户P9595% 比它快比较慢的那批P9999% 比它快最慢的 1%P99.9更极端的尾巴大流量时那一小撮超时假设单次大约 867ms。若当天 P99 是 900ms说明最慢的 1% 也在 1 秒内若 P99 突然到 8 秒就是尾巴烂了即使平均值还好看。P99 用来干什么看用户真实体验。 平均值会被大量快请求「稀释」P99 盯的是那批最慢的请求下单/入库卡死往往就在这里。设 SLO / 告警。 例如「/save_stock的 P99 1s」。红了说明不是偶发一笔而是最慢那一档已经普遍变差。和平均值对照排障。 平均还好、P99 飙高 → 少数请求极慢锁等待、偶发超时、某台机器差。平均和 P99 一起涨 → 整体都慢下游挂了、容量不够。它仍然是指标只告诉你「最慢的 1% 有多慢」找不到是哪一单。要定位那 1%还得靠 Trace 里的trace_id。记法分位数 按大小排队后的位置不是平均。P99 去掉最快的 99% 之后剩下那截有多慢。作用 衡量尾部延迟比平均数更接近「有人在卡」。P99 是100 次里最倒霉那一次大概有多慢用来发现体验恶化不能代替把那一次请求找出来。3. 时间序列、标签、基数标签label / attribute 决定这是哪一条线。code200和code500是两条序列不是一条序列里的两个字段。基数cardinality 标签取值组合数。http_requests_total{service, code} 服务数 × 状态码数 → 通常可接受http_requests_total{user_id} 每个用户一条线 → 爆炸高基数后果存储涨、查询慢、看板卡死。前面日志里cht_log_aws出现约 192 列是「字段名混乱」指标这边的对应事故是 把user_id/order_id/trace_id当成标签。这些应留在 Logs/Traces不要进 Metric 标签。安全标签service、code或status_class2xx/5xx、method、env、pod实例数可控时。危险标签用户 ID、订单号、完整 URL、异常消息原文。示例器exemplarHistogram 某个桶上可以挂一条trace_id从 P99 尖峰点进那次 Trace。基数cardinality 一组指标里有多少种不重复的标签组合也就是会拆成多少条独立时间序列。组合越多基数越高。不是数字本身大不大而是「能拆出多少条线」。和刚说的桶怎么连上直方图每个le都是一个标签值{api/save_stock, le0.1}{api/save_stock, le0.5}{api/save_stock, le1}{api/save_stock, leInf}同一个接口已经是 4 条序列。若再乘上服务、实例、状态码序列数 ≈ 服务数 × 接口数 × 实例数 × 桶个数桶越多、标签越多基数越高。所以桶要预设、要克制不能按每次请求的真实耗时或订单号去开桶。高低怎么判低基数适合当指标标签高基数不要当指标标签service、api、le、status200/500ordersn、user_id、trace_id、完整 URLle只有固定几档基数可控采购单号每种请求都不同会把序列打爆。作用监控按一条标签组合 一条时间序列来存。基数过高内存、存储、查询都会爆。所以Metric 只用低基数标签「哪一单」放日志和 Trace。一句话基数是不重复组合的条数直方图的每个le都会加一条序列所以桶能少则少。4. RED 与 USERED—— 给在线服务请求进来、结果出去字母含义典型指标Rate每秒请求rate(http_requests_total[5m])Errors失败比例5xx / 全量Duration耗时Histogram P95/P99或_sum/_count得平均三个都有才能区分「变慢但没报错」「报错但量没变」「量暴涨导致变慢」。USE—— 给主机、磁盘、线程池、连接池有容量上限的资源字母含义例子Utilization忙碌时间占比CPU 45%Saturation排队、等待负载、队列深度、磁盘 awaitErrors资源层错误磁盘 IO error、网卡 drop经验服务看板用 RED机器 / 中间件看板用 USE。CPU 高只是 USE 的 U用户痛不痛还要看服务的 E 和 D。5. 指标从哪来应用 OTEL Meter / Prometheus client→ Pull暴露 /metricsPrometheus 来刮→ PushOTLP 打到 Collector / OpenObserve→ 按时间序列存储→ PromQL 或 SQL 查询、看板、告警采集间隔常见 15s1min。太疏会抹掉短尖峰太密浪费。Counter 在重启时归零rate()能识别 reset自己拿两个点相减会算出负数。第二部分 操作 PromQLOpenObserve 兼容 Prometheus 查询。两类Instant现在一个数告警判断Range一段时间一条线看板要带start、end、step在 Prometheus / PromQLO2 的 Metrics 也是这套里Instant 和 Range 说的是两件叠在一起的事查法这一刻要一个数还是一段时间要一条线数据类型瞬时向量 vs 区间向量表达式里带不带[5m]结论Instant 是「现在拍一张」Range 是「这段时间连成线」。 算速率、P99 趋势必须用 Range。1两种查法Instant 查询Range 查询问的问题此刻或指定的某一个时间点值是多少从 t1 到 t2每隔一步一个值连成图常见用途告警、单值面板、up 0折线图、看 P99 是否在涨HTTP/api/v1/query/api/v1/query_range结果形态每个时间序列 一个点每个时间序列 一串点start、end、step入库接口的例子Instant「现在/save_stock的 P99 是 867ms 吗」→ 一个数字Range「过去 1 小时 P99 怎么走」→ 一条随时间变化的线看板用 Range告警规则每次求值用 Instant每 15s/1min 问一次「现在超没超」。2两种数据瞬时向量 vs 区间向量PromQL 里还有一层名字很像但指的是表达式吐出的数据形状。a. Instant vector瞬时向量选择器不带时间括号表示每个匹配到的序列在求值时刻各有一个最新样本。http_request_duration_seconds{serviceerp-finance, api/save_stock}可以想成财务入库这条线现在的那一个点或告警那一次求值的点。选择、过滤、比较 1都是在这种「每个序列一个值」上做。b. Range vector区间向量选择器后面加[5m]、[1h]表示每个序列带上过去一段时间的一串样本不是一个点。http_requests_total{serviceerp-finance, api/save_stock}[5m]意思是入库请求计数器最近 5 分钟里的所有点。这不能直接画成「当前 QPS」因为还没告诉引擎怎么把这一串点收成一个数。3为什么必须区分rate()只能吃 Range计数器_total是一直往上加的。你要的是「每秒多少次」必须看一段时间的增量rate(http_requests_total{serviceerp-finance, api/save_stock}[5m])[5m]先变成区间向量Range vectorrate()用这 5 分钟的点算出 一个 速率 → 又变回瞬时向量没有[5m]rate()不知道用多长窗口会报错。increase()、irate()、avg_over_time()、直方图算 P99 的histogram_quantile()搭配rate()都是先 Range 取窗口再收成 Instant 上的一个数。对照分位数histogram_quantile(0.99,rate(http_request_duration_seconds_bucket{api/save_stock}[5m]))含义用最近 5 分钟的请求耗时桶算出当前这个时刻的P99。窗口是 Range算出来的 P99 是 Instant 上的一个值。若要画「P99 一小时曲线」外层用 Range 查询对每个 step 都做一次上面的 Instant 计算。4两者怎么叠在一起容易混用一张表分开Range 查询画图过去 1 小时step15s└── 每个时间点做一次 Instant 求值└── 表达式内部可能用了 Range vector[5m]└── rate() 把 5 分钟窗口收成该时刻的一个数所以会出现这种说法Range 查询 Instant 表达式图上每个点是「那一刻的当前值」如upRange 查询 带[5m]的表达式图上每个点是「那一刻往前 5 分钟算出来的速率/P99」[5m]是函数窗口不是图表的 1 小时横轴。横轴 1 小时是查询范围[5m]是每个点回头看多远。5怎么选窗口场景倾向告警「现在挂了没有」Instant 查询 瞬时向量up 0告警「最近 5 分钟错误率」Instant 查询 rate(...[5m])看下午入库是否变慢Range 查询 histogram_quantile(0.99, rate(...[5m]))看原始样本少用表达式用[5m]但不要再套rate结果是区间向量普通图画不了窗口太短点少、曲线抖。窗口太长变化被抹平故障发现晚。经验rate/P99窗口 ≥ 4 倍 scrape 间隔常见[1m]、[5m]。6和前面几个概念的关系选择与过滤Instant / Range 都先选择序列service、api再过滤。Range 只是每个序列多带了一段历史。基数Range 查询会按 step 拉很多点。序列一多高基数一张图就是「序列数 × 点数」比 Instant 更容易把系统打爆。P99单个 P99 是某次 Instant 求值的结果P99 曲线是 Range 查询把多次 Instant 串起来。「哪一单慢」Instant/Range 都还是指标没有trace_id。曲线上 P99 飙高仍要回 Trace 过滤那 1% 请求。7记法Instant 查询 问一个时间点得到每个序列一个值告警、单值。Range 查询 问一个时间段 步长得到线折线图。瞬时向量 选择器无[ ]每个序列一个样本。区间向量 选择器加[5m]每个序列一串样本交给rate()这类函数。一句话看「现在多少」用 Instant看「这段怎么走」用 Range算 QPS/P99 必须在表达式里再加一段时间窗口[5m]。1. 选择与过滤http_requests_total{serviceorder} http_requests_total{code~5..} http_requests_total{service!health}精确~正则!/!~排除。在查监控和日志时选择是先圈定「看哪一批数据」过滤是在这批里再丢掉不符合条件的。顺序几乎总是先选择再过滤。选错了滤得再细也是错的那堆。1选择与过滤的区分干什么例子选择指定数据源和身份哪个流、哪个指标、哪些标签看test_otel或serviceerp-finance的耗时过滤在已选出的结果上加条件时间、级别、阈值、某次请求levelerror、P99 1s、trace_id 某条选择回答「从哪一类里取」过滤回答「其中哪些留下」。2在指标里PromQL 那种选择靠指标名 标签匹配圈出若干条时间序列基数在这里就被限定住http_request_duration_seconds{serviceerp-finance, api/save_stock}这是在说只要财务、只要入库这个接口不要采购、不要健康检查。过滤是对已经选中的序列再按数值砍一刀例如只留「比 1 秒慢」的http_request_duration_seconds{serviceerp-finance, api/save_stock} 1标签匹配是选择哪几条线 1是过滤这些线里哪些点/哪些序列还算数。P99 也是先选择出/save_stock这一组再在这组耗时上算分位数。3在日志 / Trace 里选择组织default流cht_log_aws或test_otel时间最近 1 小时。流和指标名一样是最大的选择选错流后面全空。过滤字段条件相当于 SQL 的WHERESELECT _timestamp, service, content FROM cht_log_aws WHERE service erp-purchase-test AND trace b43240d84b37415b931543f479ecda3eFROM cht_log_aws是选择日志流service、trace是过滤。Trace 里搜span_status ERROR也是过滤先选中test_otel里的 span再只留失败的。4为什么两个都要只选择、不过滤财务所有日志都进来单号对不上也找不到那次 duplicate key。只过滤、选择太大全公司日志里搜error噪音全是 Nacos 404、爬虫超时。和基数的关系选择要用低基数字段service、api把范围收小过滤才能用高基数字段trace_id、单号钉住「这一单」。反过来把单号当指标标签去做选择序列会爆。入库那一单的正确姿势选择Traces 流test_otel时间对齐故障点过滤trace_id b43240d84b37415b931543f479ecda3e或先span_statusERROR再点进业务接口记法选择 圈地盘流 / 指标名 / 服务 / 接口过滤 地盘里再筛时间、错误、阈值、某一个 ID看板和告警选择要稳、标签要少排障选择收窄后用trace_id过滤到单次请求一句话选择决定看哪一类信号过滤决定留下哪几条查「这一单」是过滤不是再做一个高基数指标。2. Counterrate与increaserate(http_requests_total[5m]) # 每秒画曲线用 increase(http_requests_total[1h]) # 这一小时大约增加了多少次[5m]是回看窗口太短曲线抖太长对故障反应慢。看板常用 5m短尖峰可试 1m。平均延迟Histogramrate(http_request_duration_seconds_sum[5m]) / rate(http_request_duration_seconds_count[5m])平均会被长尾拉高SLO 更看 P99不要只用平均值。平均延迟 这段时间里「耗时加总」÷「请求次数」在 Prometheus 直方图里用的是_sum和_count不是le0.1那些桶。桶是给 P99 用的。1计算式一次请求 867ms就往总和里加 0.867 秒次数 1。很多次之后平均延迟 所有请求耗时之和 / 请求次数 _sum / _count看「最近 5 分钟」的平均常用写法sum(rate(http_request_duration_seconds_sum{api/save_stock}[5m]))/sum(rate(http_request_duration_seconds_count{api/save_stock}[5m]))_sum耗时累计和秒_count请求累计次数rate(...[5m])先变成「每秒增加多少」再相除得到 秒/请求也就是平均延迟外层sum()把多实例、多标签的序列先加总避免除错组含义最近 5 分钟入库接口平均每次花了多久。2和桶、P99 的区别平均P99用什么_sum ÷ _count_bucketlehistogram_quantile对一次 8 秒超时会把平均值拉高只影响最慢那 1%99 次 200ms 1 次 8s平均约 278ms看起来还行P99 会靠近 8s 附近所以平均会被大量快请求稀释看不出「有人在卡」。 你们那条 867ms 的入库失败若混在几千次 200ms 成功里平均可能几乎不动P99 才容易跳。3注意两点窗口要一致。_sum和_count必须同一个[5m]、同一组标签否则除出来没意义。平均不能从le精确还原。 桶只知道「有多少 ≤ 0.5s」不知道每次到底是 0.12 还是 0.49。精确平均只来自_sum。平均延迟就是总耗时除以次数直方图里用_sum/_count不要用le桶去估平均。3. 聚合核心操作sum by (service) (rate(http_requests_total[5m])) sum by (service, code) (rate(http_requests_total{code~5..}[5m]))sum by (a) 保留a其余标签丢掉后相加。实例扩成 10 个 pod 时必须先sum否则看板上是 10 条线告警也会重复。常用sum、avg、max、count。Gauge 看「各实例最大内存」用maxQPS 用sum。4. 错误率sum(rate(http_requests_total{code~5..}[5m])) / sum(rate(http_requests_total[5m]))用率不用绝对条数流量低时 5 个错误和高峰 5 个错误意义不同。分母为 0没流量要避免误告见下文告警。5. 分位数histogram_quantile( 0.99, sum by (le) (rate(http_request_duration_seconds_bucket[5m])) )le必须保留否则桶会混在一起P99 算错。若还要按服务拆sum by (le, service) (...)quantile 也按 service 算。6. Gauge 常用process_resident_memory_bytes{serviceorder} avg_over_time(process_resident_memory_bytes{serviceorder}[1h])第三部分 为一类服务设计最小指标集不要一上来采 200 个指标。一个同步 HTTP/gRPC 服务最小 RED 少量 USE 就够了。假设服务叫order面板指标意图查询思路QPSRatesum(rate(http_requests_total{serviceorder}[5m]))错误率Errors5xx / 全量P99 / P95Durationhistogram_quantile平均延迟辅助_sum/_count的 rate 比饱和可选 USE队列长度、线程池、CPUGauge再加 23 个 业务 Gauge/Counter 即可例如下单成功数、支付中状态数。业务指标比「机器 CPU」更能对齐 SLO。不要放进最小看板的 每个 API 路径一条线路径基数高、每个用户、未sum的逐 pod 毛线排障下钻再拆pod。仪表盘说明QPS流量基线解释「是不是被打满」。错误率是否伤用户告警主面板。P99是否变慢平均延迟作对照避免只看平均。可选CPU/内存或队列区分「服务逻辑错误」和「资源打满」。第四部分 告警 23 条原则对准 SLI 变坏带持续时间避免一条毛刺就叫人。规则 1错误率( sum(rate(http_requests_total{serviceorder, code~5..}[5m])) / sum(rate(http_requests_total{serviceorder}[5m])) ) 0.01为何告 超过 1% 的请求失败用户可感知对齐 Errors / SLO。持续for: 2m避免单次刮取抖动。消噪 分母过低时几乎没流量用and sum(rate(...[5m])) 1卡住发布窗口可静默健康检查不要算进 5xx。通知 值班 on-call不要全员群。规则 2P99 延迟histogram_quantile( 0.99, sum by (le) (rate(http_request_duration_seconds_bucket{serviceorder}[5m])) ) 1为何告变慢但未必报错只盯错误率会漏。消噪阈值对照平时 P99例如平时 200ms 就不要用 10s低流量时 Histogram 分位数会跳同样加最小 QPS 条件。规则 3饱和体现 USEorder_queue_length 100或 CPU 0.9持续 10m。为何告 队列堆积是即将超时的前兆比已经 5xx 更早。消噪 短时扩容抖动要持续时长。CPU 高若错误率和 P99 都好可降为 warning避免夜班被机器指标吵醒。对比「ERROR 日志条数 N」日志条数受采样和字段混乱影响错误率告警应尽快迁到指标。日志告警留给「不该出现的审计失败、panic 原文」这类补漏。第五部分 AI 要点做法含义边界静态阈值错误率 1%简单可解释流量季节性时白天 1% 和凌晨 1% 含义不同异常检测相对自身历史/季节性偏离能抓「没破 1% 但突然翻倍」冷启动、发布、节假日易误报自适应阈值按基线自动调适合波动大的 QPS仍要人工封顶例如绝对不超过 5%容量预测用趋势外推磁盘/QPS辅助扩容不能当故障根因自然语言生成 PromQL必须回放。模型常写错对 Gauge 用rate、histogram_quantile丢掉le、标签写成本环境没有的字段。第六部分 延伸对照组件定位Prometheus拉取、存储近期时间序列、执行 PromQL、规则评估Alertmanager告警路由、抑制、静默、分组Prometheus 算出「着火」它负责「通知谁」Grafana看板可接 Prometheus / OpenObserveThanos / Mimir / VictoriaMetrics长期存储与全局查询了解即可OpenObserve你们统一平台有数据后用 PromQL Range Query 或typemetrics的 SQL采集标准仍是 OTEL应用可以 OTLP 推指标不必绑死 Prometheus client。后端长得像 Prometheus便于沿用 PromQL。第七部分 和 Logs / Traces 怎么接标准路径指标告警order错误率 5 分钟 1%同一时间窗在test_otel筛错误/慢 Trace用trace字段回cht_log_aws看原文指标告诉「哪段时间、哪个服务」不能告诉「哪一单、哪行代码」。术语表术语含义Time series名字 标签 时间 值Counter / Gauge / Histogram / Summary四类指标Label维度组合数即基数Cardinality explosion高基数导致序列爆炸rate/increaseCounter 转速率 / 窗口增量histogram_quantile由桶估算分位数sum by按保留标签聚合Scrape / OTLP push拉模型 / 推模型RED / USE服务三项 / 资源三项Instant / Range query瞬时值 / 区间曲线for告警持续多久才触发Alertmanager通知与静默Exemplar指标点上挂的 trace_idRecording rule预计算常用 PromQL降查询成本了解指标是带标签的时间序列适合趋势和告警不能替代某一次请求的日志和 Trace。Counter 看rateGauge 看当前值延迟用 Histogram 再histogram_quantileSummary 不能事后再按新维度聚合。标签基数必须控user_id进指标等于事故。服务看 RED资源看 USE最小看板就是 QPS、错误率、P99。告警用比率 持续时间 最小流量门槛AI 写的 PromQL 必须回放。 Metric 原理补充
目录第一部分 原理第二部分 操作 PromQL第三部分 为一类服务设计最小指标集第四部分 告警 23 条第五部分 AI 要点第六部分 延伸对照第七部分 和 Logs / Traces 怎么接日志看「这一条事件」指标看「这一段时间整不整体变差」。告警主要建在指标上因为便宜、稳定、好设阈值。第一部分 原理1. Metric 是什么一条指标是时间序列不是一行日志指标名 标签集 时间戳 一个数字例如http_requests_total{serviceorder, code500} 1284 19:20:00含义到 19:20订单服务累计 HTTP 500 共 1284 次。这个数字本身是从进程启动到现在的累计看趋势要用后面的rate()不要直接当 QPS 画。和另外两柱对比LogsTracesMetrics记什么某次事件某次请求的 span 树聚合后的数字擅长原文、审计、堆栈这一单慢在哪一跳趋势、SLO、告警成本最高中可采样最低、可长期留1 万次请求日志可能 1 万行Trace 可能 1 万条或采样后更少Metric 可能只有「总数、错误数、几个延迟桶」几条序列。所以 看板和告警优先用指标定位某一次失败仍要回日志和链路。必看文档编辑OTel MetricsPrometheus 概念官方编辑Metric typesPromQL 入门编辑Querying basicsOpenObserve编辑Metrics Explorer编辑Metrics JSON 约定记住__name__、__type__、value视频B 站概念 PromQL 入门较短编辑尚硅谷 PrometheusGrafana重点看课程介绍、Prometheus 特点、架构、安装、第 8 集 PromQL、Grafana 数据源。睿象云/Flink 集可跳过。想再细一点的入门编辑2026 Prometheus 入门到精通 前半概述、架构、部署、node_exporter、PromQL。以后做 K8s 再看可暂缓编辑博哥爱运维 · 监控合集第 08 集架构、Prometheus、Alertmanager2. 四类指标这是 Prometheus / OpenTelemetry 的核心模型。1Counter计数器只增不减进程重启归零。适合请求数、错误数、字节数、重启次数。原值会一直爬升看速率必须rate()/increase()。http_requests_total 从启动到现在一共多少次rate(http_requests_total[5m]) 最近 5 分钟平均每秒多少次2Gauge仪表可上可下。适合CPU、内存、队列长度、在线连接、goroutine 数、温度。直接看当前值或avg_over_time()。不要对 Gauge 套rate()那是给 Counter 的。3Histogram直方图把观测值丢进预设桶例如延迟le0.1、0.5、1、Inf。实际存的是三条相关序列后缀含义_bucket{le0.5}延迟 ≤ 0.5s 的次数累计_sum延迟总和_count观测次数P99 是查询时用histogram_quantile(0.99, ...)算出来的不是客户端先算好再上报。桶在采集时就要设好全挤在一个桶里分位数会失真桶太多又费存储。Histogram直方图的预设桶事先规定好几档耗时上限请求结束时往对应的桶里 1。le是 less or equal小于等于单位一般是 秒。标签含义le0.1耗时 ≤ 0.1 秒100ms的请求累计有多少le0.5耗时 ≤ 0.5 秒 的累计有多少le1耗时 ≤ 1 秒 的累计有多少leInf耗时 ≤ 无穷大也就是 全部请求桶是累加的慢的请求会计入更大的le。Inf一定等于总次数。一次请求怎么进桶/save_stock花了 867ms ≈ 0.867 秒不算进le0.10.867 0.1不算进le0.50.867 0.5算进le10.867 ≤ 1算进leInf一定算若只有 50ms四个桶都会 1因为它 ≤ 0.1更 ≤ 0.5、1、Inf。所以le0.5的数字 所有不超过 500ms 的请求不是「正好落在 0.10.5 这一档」的个数。要某一档的个数用相邻桶相减例如le1 - le0.5≈ 0.51 秒之间的次数。为什么要预设桶指标不能把每一次耗时都存下来基数会爆。折中办法事先定几条线100ms、500ms、1s、无穷只记「有多少请求跨过了这条线」用这些累计次数 估算 P50 / P99histogram_quantile桶越密分位数越准序列也越多。桶是部署时定的事后不能改已经采进去的边界改le等于换了一组指标。和 P99 的关系P99 不是去翻每一笔 867ms而是问累计占比到 99% 时落在哪两个le之间。例如绝大部分在le1里、只有 1% 超过 1sP99 就会靠近 1s 附近。桶太粗只有 0.1 / 1 / Inf时P99 只能知道「大概不到 1 秒」细不了。记法预设桶 事先画好的耗时格子0.1s、0.5s、1s、无限lex 耗时 ≤ x 秒的 累计 次数Inf 总请求数用来算比例和兜底一句话不是四种独立计时器而是四道「不超过这么久」的累计门槛用来近似延迟分布和 P99。4Summary客户端自己算好分位数再上报。查询省事但不能事后再按新标签重新聚合不能把各实例的 P99 再平均成全局 P99。现在服务延迟更常用 Histogram。对应记忆问「现在多少」→ Gauge问「刚才多快 / 一共多少」→ Counter rate/increase问「P95/P99 / SLA 延迟」→ HistogramSummary 知道局限即可新埋点优先 Histogram分位数就是把一堆数字从小到大排好看「有百分之多少落在这个值以下」。P99 是第 99 百分位100 次里有 99 次比它快或相等最慢的那 1 次比它更差。接口耗时里说的 P99通常就是几乎所有请求都比这个时间快只有最慢的 1% 更慢。为什么不用平均数假设/save_stock100 次耗时毫秒99 次都在 200400ms1 次卡了 8000ms下游超时平均数会被那 1 次拉高看起来「整体变慢」但说不清有多少人真的慢。中位数P50则几乎看不见那 1 次看起来「一切正常」。分位数把「大部分人」和「最倒霉的那一截」分开看。名字含义谁在用这个体验P50中位数一半请求比它快普通用户P9595% 比它快比较慢的那批P9999% 比它快最慢的 1%P99.9更极端的尾巴大流量时那一小撮超时假设单次大约 867ms。若当天 P99 是 900ms说明最慢的 1% 也在 1 秒内若 P99 突然到 8 秒就是尾巴烂了即使平均值还好看。P99 用来干什么看用户真实体验。 平均值会被大量快请求「稀释」P99 盯的是那批最慢的请求下单/入库卡死往往就在这里。设 SLO / 告警。 例如「/save_stock的 P99 1s」。红了说明不是偶发一笔而是最慢那一档已经普遍变差。和平均值对照排障。 平均还好、P99 飙高 → 少数请求极慢锁等待、偶发超时、某台机器差。平均和 P99 一起涨 → 整体都慢下游挂了、容量不够。它仍然是指标只告诉你「最慢的 1% 有多慢」找不到是哪一单。要定位那 1%还得靠 Trace 里的trace_id。记法分位数 按大小排队后的位置不是平均。P99 去掉最快的 99% 之后剩下那截有多慢。作用 衡量尾部延迟比平均数更接近「有人在卡」。P99 是100 次里最倒霉那一次大概有多慢用来发现体验恶化不能代替把那一次请求找出来。3. 时间序列、标签、基数标签label / attribute 决定这是哪一条线。code200和code500是两条序列不是一条序列里的两个字段。基数cardinality 标签取值组合数。http_requests_total{service, code} 服务数 × 状态码数 → 通常可接受http_requests_total{user_id} 每个用户一条线 → 爆炸高基数后果存储涨、查询慢、看板卡死。前面日志里cht_log_aws出现约 192 列是「字段名混乱」指标这边的对应事故是 把user_id/order_id/trace_id当成标签。这些应留在 Logs/Traces不要进 Metric 标签。安全标签service、code或status_class2xx/5xx、method、env、pod实例数可控时。危险标签用户 ID、订单号、完整 URL、异常消息原文。示例器exemplarHistogram 某个桶上可以挂一条trace_id从 P99 尖峰点进那次 Trace。基数cardinality 一组指标里有多少种不重复的标签组合也就是会拆成多少条独立时间序列。组合越多基数越高。不是数字本身大不大而是「能拆出多少条线」。和刚说的桶怎么连上直方图每个le都是一个标签值{api/save_stock, le0.1}{api/save_stock, le0.5}{api/save_stock, le1}{api/save_stock, leInf}同一个接口已经是 4 条序列。若再乘上服务、实例、状态码序列数 ≈ 服务数 × 接口数 × 实例数 × 桶个数桶越多、标签越多基数越高。所以桶要预设、要克制不能按每次请求的真实耗时或订单号去开桶。高低怎么判低基数适合当指标标签高基数不要当指标标签service、api、le、status200/500ordersn、user_id、trace_id、完整 URLle只有固定几档基数可控采购单号每种请求都不同会把序列打爆。作用监控按一条标签组合 一条时间序列来存。基数过高内存、存储、查询都会爆。所以Metric 只用低基数标签「哪一单」放日志和 Trace。一句话基数是不重复组合的条数直方图的每个le都会加一条序列所以桶能少则少。4. RED 与 USERED—— 给在线服务请求进来、结果出去字母含义典型指标Rate每秒请求rate(http_requests_total[5m])Errors失败比例5xx / 全量Duration耗时Histogram P95/P99或_sum/_count得平均三个都有才能区分「变慢但没报错」「报错但量没变」「量暴涨导致变慢」。USE—— 给主机、磁盘、线程池、连接池有容量上限的资源字母含义例子Utilization忙碌时间占比CPU 45%Saturation排队、等待负载、队列深度、磁盘 awaitErrors资源层错误磁盘 IO error、网卡 drop经验服务看板用 RED机器 / 中间件看板用 USE。CPU 高只是 USE 的 U用户痛不痛还要看服务的 E 和 D。5. 指标从哪来应用 OTEL Meter / Prometheus client→ Pull暴露 /metricsPrometheus 来刮→ PushOTLP 打到 Collector / OpenObserve→ 按时间序列存储→ PromQL 或 SQL 查询、看板、告警采集间隔常见 15s1min。太疏会抹掉短尖峰太密浪费。Counter 在重启时归零rate()能识别 reset自己拿两个点相减会算出负数。第二部分 操作 PromQLOpenObserve 兼容 Prometheus 查询。两类Instant现在一个数告警判断Range一段时间一条线看板要带start、end、step在 Prometheus / PromQLO2 的 Metrics 也是这套里Instant 和 Range 说的是两件叠在一起的事查法这一刻要一个数还是一段时间要一条线数据类型瞬时向量 vs 区间向量表达式里带不带[5m]结论Instant 是「现在拍一张」Range 是「这段时间连成线」。 算速率、P99 趋势必须用 Range。1两种查法Instant 查询Range 查询问的问题此刻或指定的某一个时间点值是多少从 t1 到 t2每隔一步一个值连成图常见用途告警、单值面板、up 0折线图、看 P99 是否在涨HTTP/api/v1/query/api/v1/query_range结果形态每个时间序列 一个点每个时间序列 一串点start、end、step入库接口的例子Instant「现在/save_stock的 P99 是 867ms 吗」→ 一个数字Range「过去 1 小时 P99 怎么走」→ 一条随时间变化的线看板用 Range告警规则每次求值用 Instant每 15s/1min 问一次「现在超没超」。2两种数据瞬时向量 vs 区间向量PromQL 里还有一层名字很像但指的是表达式吐出的数据形状。a. Instant vector瞬时向量选择器不带时间括号表示每个匹配到的序列在求值时刻各有一个最新样本。http_request_duration_seconds{serviceerp-finance, api/save_stock}可以想成财务入库这条线现在的那一个点或告警那一次求值的点。选择、过滤、比较 1都是在这种「每个序列一个值」上做。b. Range vector区间向量选择器后面加[5m]、[1h]表示每个序列带上过去一段时间的一串样本不是一个点。http_requests_total{serviceerp-finance, api/save_stock}[5m]意思是入库请求计数器最近 5 分钟里的所有点。这不能直接画成「当前 QPS」因为还没告诉引擎怎么把这一串点收成一个数。3为什么必须区分rate()只能吃 Range计数器_total是一直往上加的。你要的是「每秒多少次」必须看一段时间的增量rate(http_requests_total{serviceerp-finance, api/save_stock}[5m])[5m]先变成区间向量Range vectorrate()用这 5 分钟的点算出 一个 速率 → 又变回瞬时向量没有[5m]rate()不知道用多长窗口会报错。increase()、irate()、avg_over_time()、直方图算 P99 的histogram_quantile()搭配rate()都是先 Range 取窗口再收成 Instant 上的一个数。对照分位数histogram_quantile(0.99,rate(http_request_duration_seconds_bucket{api/save_stock}[5m]))含义用最近 5 分钟的请求耗时桶算出当前这个时刻的P99。窗口是 Range算出来的 P99 是 Instant 上的一个值。若要画「P99 一小时曲线」外层用 Range 查询对每个 step 都做一次上面的 Instant 计算。4两者怎么叠在一起容易混用一张表分开Range 查询画图过去 1 小时step15s└── 每个时间点做一次 Instant 求值└── 表达式内部可能用了 Range vector[5m]└── rate() 把 5 分钟窗口收成该时刻的一个数所以会出现这种说法Range 查询 Instant 表达式图上每个点是「那一刻的当前值」如upRange 查询 带[5m]的表达式图上每个点是「那一刻往前 5 分钟算出来的速率/P99」[5m]是函数窗口不是图表的 1 小时横轴。横轴 1 小时是查询范围[5m]是每个点回头看多远。5怎么选窗口场景倾向告警「现在挂了没有」Instant 查询 瞬时向量up 0告警「最近 5 分钟错误率」Instant 查询 rate(...[5m])看下午入库是否变慢Range 查询 histogram_quantile(0.99, rate(...[5m]))看原始样本少用表达式用[5m]但不要再套rate结果是区间向量普通图画不了窗口太短点少、曲线抖。窗口太长变化被抹平故障发现晚。经验rate/P99窗口 ≥ 4 倍 scrape 间隔常见[1m]、[5m]。6和前面几个概念的关系选择与过滤Instant / Range 都先选择序列service、api再过滤。Range 只是每个序列多带了一段历史。基数Range 查询会按 step 拉很多点。序列一多高基数一张图就是「序列数 × 点数」比 Instant 更容易把系统打爆。P99单个 P99 是某次 Instant 求值的结果P99 曲线是 Range 查询把多次 Instant 串起来。「哪一单慢」Instant/Range 都还是指标没有trace_id。曲线上 P99 飙高仍要回 Trace 过滤那 1% 请求。7记法Instant 查询 问一个时间点得到每个序列一个值告警、单值。Range 查询 问一个时间段 步长得到线折线图。瞬时向量 选择器无[ ]每个序列一个样本。区间向量 选择器加[5m]每个序列一串样本交给rate()这类函数。一句话看「现在多少」用 Instant看「这段怎么走」用 Range算 QPS/P99 必须在表达式里再加一段时间窗口[5m]。1. 选择与过滤http_requests_total{serviceorder} http_requests_total{code~5..} http_requests_total{service!health}精确~正则!/!~排除。在查监控和日志时选择是先圈定「看哪一批数据」过滤是在这批里再丢掉不符合条件的。顺序几乎总是先选择再过滤。选错了滤得再细也是错的那堆。1选择与过滤的区分干什么例子选择指定数据源和身份哪个流、哪个指标、哪些标签看test_otel或serviceerp-finance的耗时过滤在已选出的结果上加条件时间、级别、阈值、某次请求levelerror、P99 1s、trace_id 某条选择回答「从哪一类里取」过滤回答「其中哪些留下」。2在指标里PromQL 那种选择靠指标名 标签匹配圈出若干条时间序列基数在这里就被限定住http_request_duration_seconds{serviceerp-finance, api/save_stock}这是在说只要财务、只要入库这个接口不要采购、不要健康检查。过滤是对已经选中的序列再按数值砍一刀例如只留「比 1 秒慢」的http_request_duration_seconds{serviceerp-finance, api/save_stock} 1标签匹配是选择哪几条线 1是过滤这些线里哪些点/哪些序列还算数。P99 也是先选择出/save_stock这一组再在这组耗时上算分位数。3在日志 / Trace 里选择组织default流cht_log_aws或test_otel时间最近 1 小时。流和指标名一样是最大的选择选错流后面全空。过滤字段条件相当于 SQL 的WHERESELECT _timestamp, service, content FROM cht_log_aws WHERE service erp-purchase-test AND trace b43240d84b37415b931543f479ecda3eFROM cht_log_aws是选择日志流service、trace是过滤。Trace 里搜span_status ERROR也是过滤先选中test_otel里的 span再只留失败的。4为什么两个都要只选择、不过滤财务所有日志都进来单号对不上也找不到那次 duplicate key。只过滤、选择太大全公司日志里搜error噪音全是 Nacos 404、爬虫超时。和基数的关系选择要用低基数字段service、api把范围收小过滤才能用高基数字段trace_id、单号钉住「这一单」。反过来把单号当指标标签去做选择序列会爆。入库那一单的正确姿势选择Traces 流test_otel时间对齐故障点过滤trace_id b43240d84b37415b931543f479ecda3e或先span_statusERROR再点进业务接口记法选择 圈地盘流 / 指标名 / 服务 / 接口过滤 地盘里再筛时间、错误、阈值、某一个 ID看板和告警选择要稳、标签要少排障选择收窄后用trace_id过滤到单次请求一句话选择决定看哪一类信号过滤决定留下哪几条查「这一单」是过滤不是再做一个高基数指标。2. Counterrate与increaserate(http_requests_total[5m]) # 每秒画曲线用 increase(http_requests_total[1h]) # 这一小时大约增加了多少次[5m]是回看窗口太短曲线抖太长对故障反应慢。看板常用 5m短尖峰可试 1m。平均延迟Histogramrate(http_request_duration_seconds_sum[5m]) / rate(http_request_duration_seconds_count[5m])平均会被长尾拉高SLO 更看 P99不要只用平均值。平均延迟 这段时间里「耗时加总」÷「请求次数」在 Prometheus 直方图里用的是_sum和_count不是le0.1那些桶。桶是给 P99 用的。1计算式一次请求 867ms就往总和里加 0.867 秒次数 1。很多次之后平均延迟 所有请求耗时之和 / 请求次数 _sum / _count看「最近 5 分钟」的平均常用写法sum(rate(http_request_duration_seconds_sum{api/save_stock}[5m]))/sum(rate(http_request_duration_seconds_count{api/save_stock}[5m]))_sum耗时累计和秒_count请求累计次数rate(...[5m])先变成「每秒增加多少」再相除得到 秒/请求也就是平均延迟外层sum()把多实例、多标签的序列先加总避免除错组含义最近 5 分钟入库接口平均每次花了多久。2和桶、P99 的区别平均P99用什么_sum ÷ _count_bucketlehistogram_quantile对一次 8 秒超时会把平均值拉高只影响最慢那 1%99 次 200ms 1 次 8s平均约 278ms看起来还行P99 会靠近 8s 附近所以平均会被大量快请求稀释看不出「有人在卡」。 你们那条 867ms 的入库失败若混在几千次 200ms 成功里平均可能几乎不动P99 才容易跳。3注意两点窗口要一致。_sum和_count必须同一个[5m]、同一组标签否则除出来没意义。平均不能从le精确还原。 桶只知道「有多少 ≤ 0.5s」不知道每次到底是 0.12 还是 0.49。精确平均只来自_sum。平均延迟就是总耗时除以次数直方图里用_sum/_count不要用le桶去估平均。3. 聚合核心操作sum by (service) (rate(http_requests_total[5m])) sum by (service, code) (rate(http_requests_total{code~5..}[5m]))sum by (a) 保留a其余标签丢掉后相加。实例扩成 10 个 pod 时必须先sum否则看板上是 10 条线告警也会重复。常用sum、avg、max、count。Gauge 看「各实例最大内存」用maxQPS 用sum。4. 错误率sum(rate(http_requests_total{code~5..}[5m])) / sum(rate(http_requests_total[5m]))用率不用绝对条数流量低时 5 个错误和高峰 5 个错误意义不同。分母为 0没流量要避免误告见下文告警。5. 分位数histogram_quantile( 0.99, sum by (le) (rate(http_request_duration_seconds_bucket[5m])) )le必须保留否则桶会混在一起P99 算错。若还要按服务拆sum by (le, service) (...)quantile 也按 service 算。6. Gauge 常用process_resident_memory_bytes{serviceorder} avg_over_time(process_resident_memory_bytes{serviceorder}[1h])第三部分 为一类服务设计最小指标集不要一上来采 200 个指标。一个同步 HTTP/gRPC 服务最小 RED 少量 USE 就够了。假设服务叫order面板指标意图查询思路QPSRatesum(rate(http_requests_total{serviceorder}[5m]))错误率Errors5xx / 全量P99 / P95Durationhistogram_quantile平均延迟辅助_sum/_count的 rate 比饱和可选 USE队列长度、线程池、CPUGauge再加 23 个 业务 Gauge/Counter 即可例如下单成功数、支付中状态数。业务指标比「机器 CPU」更能对齐 SLO。不要放进最小看板的 每个 API 路径一条线路径基数高、每个用户、未sum的逐 pod 毛线排障下钻再拆pod。仪表盘说明QPS流量基线解释「是不是被打满」。错误率是否伤用户告警主面板。P99是否变慢平均延迟作对照避免只看平均。可选CPU/内存或队列区分「服务逻辑错误」和「资源打满」。第四部分 告警 23 条原则对准 SLI 变坏带持续时间避免一条毛刺就叫人。规则 1错误率( sum(rate(http_requests_total{serviceorder, code~5..}[5m])) / sum(rate(http_requests_total{serviceorder}[5m])) ) 0.01为何告 超过 1% 的请求失败用户可感知对齐 Errors / SLO。持续for: 2m避免单次刮取抖动。消噪 分母过低时几乎没流量用and sum(rate(...[5m])) 1卡住发布窗口可静默健康检查不要算进 5xx。通知 值班 on-call不要全员群。规则 2P99 延迟histogram_quantile( 0.99, sum by (le) (rate(http_request_duration_seconds_bucket{serviceorder}[5m])) ) 1为何告变慢但未必报错只盯错误率会漏。消噪阈值对照平时 P99例如平时 200ms 就不要用 10s低流量时 Histogram 分位数会跳同样加最小 QPS 条件。规则 3饱和体现 USEorder_queue_length 100或 CPU 0.9持续 10m。为何告 队列堆积是即将超时的前兆比已经 5xx 更早。消噪 短时扩容抖动要持续时长。CPU 高若错误率和 P99 都好可降为 warning避免夜班被机器指标吵醒。对比「ERROR 日志条数 N」日志条数受采样和字段混乱影响错误率告警应尽快迁到指标。日志告警留给「不该出现的审计失败、panic 原文」这类补漏。第五部分 AI 要点做法含义边界静态阈值错误率 1%简单可解释流量季节性时白天 1% 和凌晨 1% 含义不同异常检测相对自身历史/季节性偏离能抓「没破 1% 但突然翻倍」冷启动、发布、节假日易误报自适应阈值按基线自动调适合波动大的 QPS仍要人工封顶例如绝对不超过 5%容量预测用趋势外推磁盘/QPS辅助扩容不能当故障根因自然语言生成 PromQL必须回放。模型常写错对 Gauge 用rate、histogram_quantile丢掉le、标签写成本环境没有的字段。第六部分 延伸对照组件定位Prometheus拉取、存储近期时间序列、执行 PromQL、规则评估Alertmanager告警路由、抑制、静默、分组Prometheus 算出「着火」它负责「通知谁」Grafana看板可接 Prometheus / OpenObserveThanos / Mimir / VictoriaMetrics长期存储与全局查询了解即可OpenObserve你们统一平台有数据后用 PromQL Range Query 或typemetrics的 SQL采集标准仍是 OTEL应用可以 OTLP 推指标不必绑死 Prometheus client。后端长得像 Prometheus便于沿用 PromQL。第七部分 和 Logs / Traces 怎么接标准路径指标告警order错误率 5 分钟 1%同一时间窗在test_otel筛错误/慢 Trace用trace字段回cht_log_aws看原文指标告诉「哪段时间、哪个服务」不能告诉「哪一单、哪行代码」。术语表术语含义Time series名字 标签 时间 值Counter / Gauge / Histogram / Summary四类指标Label维度组合数即基数Cardinality explosion高基数导致序列爆炸rate/increaseCounter 转速率 / 窗口增量histogram_quantile由桶估算分位数sum by按保留标签聚合Scrape / OTLP push拉模型 / 推模型RED / USE服务三项 / 资源三项Instant / Range query瞬时值 / 区间曲线for告警持续多久才触发Alertmanager通知与静默Exemplar指标点上挂的 trace_idRecording rule预计算常用 PromQL降查询成本了解指标是带标签的时间序列适合趋势和告警不能替代某一次请求的日志和 Trace。Counter 看rateGauge 看当前值延迟用 Histogram 再histogram_quantileSummary 不能事后再按新维度聚合。标签基数必须控user_id进指标等于事故。服务看 RED资源看 USE最小看板就是 QPS、错误率、P99。告警用比率 持续时间 最小流量门槛AI 写的 PromQL 必须回放。