RED、USE 与可观测性方法学

共 19 题
#

1. Alertmanager 的 route 配置如何实现告警按标签路由、分组与抑制?

A route 按标签路由,group_by 聚合告警,inhibit 抑制冗余告警,共同降低告警噪音 ✓ 正确答案
B route 只能使用单一 receiver
C group_by 用于抑制告警
D inhibit 用于路由告警
#

2. Google SRE 四大黄金信号(延迟/流量/错误/饱和度)与 RED、USE 的映射关系,三套方法如何互补

A 黄金信号无法映射到 RED/USE
B RED 用于看资源,USE 用于看服务
C 黄金信号是总览,RED 从服务请求视角(Rate/Errors/Duration),USE 从资源视角(Utilization/Saturation/Errors),三者可互补 ✓ 正确答案
D 三套方法互斥,只能选其一
#

3. RED 指标中 Rate、Errors 与 Duration 的服务视角如何应用?

A RED 面向主机视角
B RED 用于看资源利用率
C Duration 用平均值最准确
D RED 从服务请求视角看 Rate、Errors、Duration,衡量服务健康 ✓ 正确答案
#

4. RED 方法中的请求量(Request rate)如何度量与解读,即流量突增或突降分别说明什么?

A 请求量用 rate 度量,突增/突降需结合错误率与延迟判断是正常、攻击、重试还是链路断裂 ✓ 正确答案
B 请求量突增都是正常业务增长
C 请求量突降都是服务故障
D 请求量应直接读计数器原始值
#

5. RED 方法中的错误率(Error rate)如何定义与度量,即哪些错误应计入、阈值如何设定?

A 错误率阈值对所有服务统一
B 4xx 一律计入错误率
C 错误率 = 失败请求/总请求,需明确计入哪些错误(5xx、超时、业务失败),阈值与 SLO 绑定并按服务分层 ✓ 正确答案
D 错误定义无需与告警一致
#

6. Apdex 指数(应用性能指数)的计算与阈值设定,如何把用户感知的响应时间量化成单一分数

A T 的取值不影响 Apdex
B Apdex 用平均响应时间计算
C Apdex 取值范围 0-100
D Apdex = (满意数 + 0.5×可容忍数)/总请求数,T 为满意阈值、4T 为容忍上限,量化用户感知 ✓ 正确答案
#

7. RED/USE 指标在告警阈值设计中的应用中请求错误率阈值与资源饱和度阈值如何联动

A 资源饱和不需要预警
B 资源告警与请求告警无关
C 只需关注错误率即可
D 资源饱和度是根因预警,请求错误率/延迟是结果告警,两者联动实现先预防后响应 ✓ 正确答案
#

8. USE 指标中 Utilization、Saturation 与 Errors 的资源视角如何应用?

A USE 用于看服务请求量
B USE 从资源视角看 Utilization、Saturation、Errors,评估资源占用、过载与故障 ✓ 正确答案
C Utilization 表示资源等待队列
D Errors 表示资源利用率
#

9. 基于 burn rate 的多窗口告警设计中如何用错误预算燃烧速率替代简单静态阈值以减少误报与漏报

A burn rate 是错误率与 SLO 允许错误率的比值,用多窗口阈值可兼顾误报与漏报 ✓ 正确答案
B burn rate 与 SLO 无关
C 单一静态阈值更能减少误报
D 多窗口告警增加漏报
#

10. Alertmanager 如何通过分组(grouping)与抑制(inhibition)实现告警去重?

A 抑制用于发送通知
B 分组用于抑制告警
C 分组按标签合并同类告警,抑制让根因告警压制派生告警,共同收敛告警风暴 ✓ 正确答案
D 去重只靠静默
#

11. RED/USE 与 SLO 的关联中服务错误率/延迟如何转化为 SLI 并纳入错误预算

A SLI 只能由人工评估
B SLO 与错误率无关
C 错误预算 = 实际错误率
D RED 的错误率/延迟转化为 SLI,SLO 设定目标,错误预算控制发布与修复节奏 ✓ 正确答案
#

12. eBPF 自动观测对 RED/USE 方法的影响中无侵入指标如何补充或替代手动埋点

A eBPF 只能补充 USE,不能补充 RED
B eBPF 可完全替代手动埋点
C eBPF 无法观测 HTTP 请求
D eBPF 无侵入采集请求与网络指标补充 RED/USE,但业务语义仍需手动埋点,二者互补 ✓ 正确答案
#

13. 仪表盘的分层设计中服务视图、资源视图与容量视图如何分工以避免一张大盘塞满所有指标

A 服务视图看用户感知、资源视图看底层支撑、容量视图看未来趋势,分层并用下钻避免臃肿 ✓ 正确答案
B 一张盘塞满所有指标最全面
C 各视图应混合所有指标
D 分层设计会影响可读性
#

14. 分层监控的落地中业务层、服务层与资源层的指标如何组织成可下钻的监控体系

A 业务层只用于展示不用于告警
B 各层指标无需关联
C 按业务、服务、资源三层组织,用统一标签联动下钻实现逐层定位 ✓ 正确答案
D 资源层指标是唯一监控对象
#

15. 可观测性的四支柱中指标、日志、追踪与事件如何协同?

A 四支柱是并列无关的
B 指标看状态、日志看细节、追踪看链路、事件看上下文,四者配合形成完整排障闭环 ✓ 正确答案
C 事件与日志完全等价
D 追踪用于看整体状态
#

16. 指标选型的实践中如何为每个服务挑选少量高价值指标以避免指标爆炸与仪表盘臃肿

A 指标越多越全面
B 为每个服务挑选少量高价值指标(如 RED),控制标签基数,分层展示避免爆炸与臃肿 ✓ 正确答案
C 高基数标签便于细分可保留
D 所有服务需用相同指标集
#

17. 指标阈值设定方法中静态阈值、分位数基线与时序异常检测的适用场景与调参要点

A 静态阈值简单直观、分位数基线适应波动、异常检测自动适应,按指标特性与可解释性选择组合 ✓ 正确答案
B 静态阈值适合所有指标
C 异常检测无需调参
D 分位数基线固定不变
#

18. 方法学的适用边界中何时用 RED 看服务、何时用 USE 看资源、何时依赖日志与追踪深挖

A 所有问题都用 RED 解决
B RED 用于看资源,USE 用于看服务
C 日志/追踪用于定性
D RED 看服务请求、USE 看资源、日志/追踪深挖根因,按先定性后定位的顺序 ✓ 正确答案
#

19. 服务指标与资源指标的关联分析中请求延迟升高时如何下钻到 CPU/IO/网络等资源层定位根因

A 只需看服务层即可
B 延迟升高一定是资源不足
C 资源指标与服务指标无关
D 用 RED 确认服务异常,用 USE 看资源瓶颈,用追踪/日志深挖,区分资源不足还是服务逻辑问题 ✓ 正确答案