Metric Reading Basics


Why This Page Exists#

很多 dashboard 文档里会写：

CPU trend
request trend
1h rolling average
rate
spike
baseline

这些词如果只看字面，容易误解成“就是涨或者跌”。

实际上它们回答的是不同问题：

Term It Answers
Current value 现在这一刻是多少
Trend 最近一段时间是在变好还是变坏
Rate 单位时间内变化多快
Rolling average 去掉短时噪声后的平均水位
Rolling sum 一段时间内累计发生了多少
Spike 是否出现了短时突增
Baseline 正常情况下通常应该在什么范围

1. Current Value#

current value 指“当前这一刻”的值。

例如:

CPUUtilization = 68%
PendingTaskCount = 3
TargetResponseTime p95 = 1.2s

它适合回答：

现在是不是已经高了
现在是不是已经有错误
现在是不是已经出现 pending task

但它不回答：

这是刚刚才高，还是已经高了 1 小时
这是偶发抖动，还是持续恶化

实际例子:

一个 ECS service 当前 memory = 72%

只看 current value：
    72% 不算特别危险

但如果过去 2 小时它一直从 30% 爬升到 72%，
那就说明 workload 正在持续上涨。

2. Trend#

trend 指“最近一段时间里的变化方向和形态”，不只是上升或下降。

它通常包含四层意思：

方向：
    上升、下降、持平

速度：
    缓慢变化，还是快速恶化

持续性：
    只是瞬时 spike，还是持续 30 分钟以上

形态：
    平滑上升，还是剧烈抖动

实际例子:

同样都是 CPU 75%

场景 A:
    过去 1 小时一直在 20% 到 30%
    刚刚突然跳到 75%
    这更像短时 spike

场景 B:
    过去 1 小时从 25% -> 40% -> 55% -> 75%
    这更像持续上升 trend
    常见含义是请求在增长，或者系统正在接近瓶颈

所以 trend 真正回答的是：

系统是在变好、变坏，还是只是瞬时波动

3. Rate#

rate 指“单位时间内变化速度”，最常见于 counter。

典型 PromQL:

rate(http_requests_total[5m])
rate(container_cpu_usage_seconds_total[5m])

它适合回答：

每秒请求数是多少
每秒错误数是多少
CPU 使用在持续消耗多快

实际例子:

http_requests_total 是累计请求总数

如果它从:
    1,000,000 -> 1,006,000
在 60 秒内完成，

那 request rate 大约就是:
    100 rps

为什么不能只看 counter 本身：

counter 只会越来越大
总数变大是正常的

真正有意义的是：
    它增长得有多快

4. Rolling Average#

rolling average 指“在一个滑动时间窗口里持续计算平均值”。

典型 PromQL:

avg_over_time(aws_ecs_cpu_utilization_average[1h])
avg_over_time(aws_ecs_memory_utilization_average[1h])

它适合回答：

过去 1 小时的平均资源水位是多少
系统长期是高负载还是只是偶发抖动

实际例子:

某服务 CPU 原始点值：
    20%, 25%, 90%, 22%, 18%, 24%

如果只看原始值：
    会觉得系统很不稳定

如果看 1h rolling average：
    可能只有 28%

这说明：
    中间那个 90% 更像单次 spike
    长期容量并不紧张

rolling average 的意义是“平滑噪声”，更适合看容量趋势，不适合抓瞬时告警。

5. Rolling Sum#

rolling sum 指“在一个滑动时间窗口内累计发生了多少”。

典型 PromQL:

sum_over_time(aws_applicationelb_request_count_sum[1h])
sum_over_time(errors_total[30m])

它适合回答：

最近 1 小时总共来了多少请求
最近 30 分钟总共发生了多少错误

实际例子:

ALB RequestCount 每 5 分钟上报一次 sum

如果过去 1 小时各点累计后得到 1,200,000，
那它表达的是：
    最近 1 小时总请求量约 120 万

这适合看业务体量和容量规划，
而不是看“当前瞬时 rps”。

6. Spike#

spike 指短时间内突然升高或突然下降。

常见例子:

CPU 突然从 20% 跳到 95%
ALB 5xx 在 2 分钟内突然增多
SQS oldest message age 突然抬升

spike 不一定代表长期问题，但代表“刚刚发生了异常波动”。

实际例子:

某个 batch job 每小时整点启动一次

现象：
    CPU 在整点瞬间拉高到 90%
    5 分钟后恢复到 25%

这说明：
    有 spike
    但不一定有持续容量问题

7. Baseline#

baseline 指“正常情况下这个指标通常落在哪个范围”。

没有 baseline，就很难判断一个值到底算不算异常。

实际例子:

TargetResponseTime p95 = 300ms

如果这个服务平时就是 250ms 到 350ms，
那 300ms 很正常

如果这个服务平时只有 40ms 到 70ms，
那 300ms 已经是明显异常

baseline 常见来源：

过去 7 天 / 30 天的同类时段
工作日白天 vs 夜间
活动日 vs 平常日

8. How They Work Together#

值班时不要只看一个词，要把几个视角一起看。

例子：ECS service 发布后用户反馈变慢

current value:
    p95 latency 现在是 1.8s

trend:
    过去 40 分钟一直在上升

rate:
    request rate 没有明显上涨

rolling average:
    CPU 1h rolling average 仍然不高

pending task:
    从 0 变成 4

这组信号更像：

不是流量自然增长导致的系统变慢
而是 deployment / capacity / scheduling 出问题
导致新 task 没有正常接住流量

再看一个 ALB 例子：

current value:
    target 5xx 当前很高

trend:
    只持续了 3 分钟

rate:
    request rate 突然翻倍

rolling sum:
    最近 1 小时请求总量很高

baseline:
    当前流量已经明显高于平时晚高峰

这组信号更像：

业务流量突增
后端没有及时扩起来
短时出现 target 5xx

9. Practical Reading Order#

值班时可以用这个顺序读图：

  1. 看 current value 先判断现在有没有红线指标已经出问题。
  2. 看 trend 判断是在持续恶化，还是刚刚抖了一下。
  3. 看 rate 判断流量、错误、资源消耗增长速度。
  4. 看 rolling average / rolling sum 判断这是长期趋势还是瞬时异常。
  5. 对照 baseline 判断这到底是不是偏离正常范围。

10. Common Mistakes#

误区 1:
    CPU 当前高，所以一定要扩容
实际：
    可能只是一次短时 spike

误区 2:
    counter 很大，所以系统压力很大
实际：
    counter 本来就会一直累加，应该看 rate

误区 3:
    rolling average 不高，所以系统没问题
实际：
    rolling average 会抹平短时事故，不能替代告警视图

误区 4:
    指标比昨天高，就是异常
实际：
    要先看 baseline，同一业务在不同时间段本来就可能差很多
Backward Dashboard PromQL Reference