> For the complete documentation index, see [llms.txt](https://atomoh.gitbook.io/kubernetes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://atomoh.gitbook.io/kubernetes/es/ce-yan-ji-he/yun-wei-zhi-nan/07-observability-alerts-quiz.md).
# 可观测性告警测验
> **相关文档**: [可观测性告警](/kubernetes/es/yun-wei-zhi-nan/ops/07-observability-alerts.md)
## 选择题
### 1. 哪个 PromQL 表达式用于检测 container 中的 CPU throttling？
* A) `container_cpu_usage_seconds_total`
* B) `rate(container_cpu_cfs_throttled_seconds_total[5m]) > 0`
* C) `container_memory_usage_bytes`
* D) `kube_pod_status_phase`
显示答案
**答案：B) `rate(container_cpu_cfs_throttled_seconds_total[5m]) > 0`**
**解释：** 当 container 超过其 CPU limit 时，会发生 CPU throttling。`container_cpu_cfs_throttled_seconds_total` metric 会跟踪被 throttled 的时间。正的 rate 表示存在 active throttling，可能会影响应用程序性能。
### 2. Alertmanager 的 `group_by` 配置有什么用途？
* A) 删除告警
* B) 将具有匹配 label 的告警聚合为单个通知
* C) 提高告警 severity
* D) 将告警路由到日志
显示答案
**答案：B) 将具有匹配 label 的告警聚合为单个通知**
**解释：** `group_by` 会将共享指定 label 值的多个 firing alerts 合并为一个通知。这可以减少由许多相似告警触发的 incident 中的告警疲劳（例如，一个 Deployment 中的所有 pods 都失败）。
### 3. 哪个 metric 对检测 EKS Auto Mode node 终止最重要？
* A) `node_cpu_seconds_total`
* B) `kube_node_status_condition` with condition="Ready"
* C) `container_memory_usage_bytes`
* D) `node_filesystem_size_bytes`
显示答案
**答案：B) `kube_node_status_condition` with condition="Ready"**
**解释：** 监控 `kube_node_status_condition` 中的 Ready=false 可以检测 nodes 变为不可用。在 Auto Mode 中，这表示 node 终止或替换。结合 labels，你可以跟踪 node lifecycle 和替换模式。
### 4. Prometheus 告警规则中的 `for` duration 指定了什么？
* A) 告警在历史记录中保留多久
* B) 条件在 firing 前必须保持为 true 的时长
* C) 告警评估 interval
* D) 通知 timeout
显示答案
**答案：B) 条件在 firing 前必须保持为 true 的时长**
**解释：** `for` 子句指定条件必须持续为 true 多久，告警才会从 “pending” 转换为 “firing”。这可以防止短暂尖峰触发告警，并减少误报。
### 5. 应如何定义告警 severity levels？
* A) 所有告警都应为 critical
* B) 基于业务影响和所需响应时间
* C) 随机分配
* D) 基于 metric 名称
显示答案
**答案：B) 基于业务影响和所需响应时间**
**解释：** Severity 应反映影响：critical 用于需要立即响应的面向客户的故障，warning 用于需要在数小时内关注的降级，info 用于无需行动的认知提醒。这可以实现适当的路由和 on-call 升级。
### 6. 哪个 PromQL function 用于计算随时间增长的 rate？
* A) `sum()`
* B) `rate()`
* C) `max()`
* D) `count()`
显示答案
**答案：B) `rate()`**
**解释：** `rate()` 计算某个时间范围内每秒平均增长率。它专为 counters 设计，并会处理 counter resets。例如，`rate(http_requests_total[5m])` 给出 5 分钟内平均的每秒请求数。
### 7. packet drop 告警的推荐做法是什么？
* A) 对任何单个 packet drop 发出告警
* B) 当 drop rate 超过阈值并持续一段时间时发出告警
* C) 永远不要对 packet drops 发出告警
* D) 只记录 packet drops
显示答案
**答案：B) 当 drop rate 超过阈值并持续一段时间时发出告警**
**解释：** 偶发的 packet drops 在网络中是正常的。告警应在持续升高的 drop rates 表明存在实际问题时触发。使用一个窗口（例如 5m）上的 `rate()` 并设置阈值，可以防止瞬时尖峰触发告警。
### 8. 在 Alertmanager routing 中，`continue: true` 有什么作用？
* A) 停止处理后续 routes
* B) 允许告警在当前 route 之后继续匹配其他 routes
* C) 重复告警通知
* D) 静默告警
显示答案
**答案：B) 允许告警在当前 route 之后继续匹配其他 routes**
**解释：** 默认情况下，Alertmanager 会在第一个匹配的 route 处停止。设置 `continue: true` 允许告警匹配多个 routes，从而支持同时将 critical 告警发送到 PagerDuty 和 Slack 等场景。
### 9. 哪个 metric 表示 EKS nodes 上的网络带宽超限？
* A) `container_cpu_usage_seconds_total`
* B) `node_network_transmit_bytes_total` approaching instance network limits
* C) `kube_pod_container_status_running`
* D) `container_fs_writes_bytes_total`
显示答案
**答案：B) `node_network_transmit_bytes_total` approaching instance network limits**
**解释：** `node_network_transmit_bytes_total` 和 `node_network_receive_bytes_total` 跟踪 network I/O。将 rate 与 EC2 instance network bandwidth limits 进行比较，有助于识别 workloads 何时触及网络约束。
### 10. Alertmanager 中 alert inhibition rules 的用途是什么？
* A) 提高告警优先级
* B) 当父级告警正在 firing 时，抑制依赖告警
* C) 将告警路由到不同 receivers
* D) 创建新告警
显示答案
**答案：B) 当父级告警正在 firing 时，抑制依赖告警**
**解释：** Inhibition rules 会在根因告警触发时静默下游告警，以防止告警风暴。例如，当 “NodeDown” 触发时，抑制该 node 上 pods 的所有 “PodNotReady” 告警，因为它们是同一问题的症状。