测验：保存、触发与传递的边界

PrometheusRule 创建成功，但 /api/v1/rules에 中不存在组。首先应检查哪组条件？

• 选择规则命名空间和规则标签
• 仅Alertmanager接收器的重传周期
• 仅 Webhook 接收服务器的请求正文大小。
• 通知消息的显示语言和字符数

我应该在ServiceMonitor的endpoints.port中输入什么值？

• 将容器端口的整数值转换为字符串
• 所选服务中声明的端口名称
• Pod 名称后跟容器端口
• 服务的ClusterIP添加协议

指标目标向上，但发行请求是503，最准确的解读是什么？

• 如果起来了，业务失败就是客户端问题。
• 既然是503，那么exporter进程肯定已经结束了。
• 采集路径和业务依赖状态不同
• 至此，规则选择和通知下发已经完成。

Prometheus 正在触发，但 Alertmanager API 中没有任何通知。您调查哪些边界？

• 用户可见的通知标题和翻译
• 仅对已通过的规则进行 YAML 缩进
• 仅接收 webhook 的 send_resolved 选项
• Prometheus 的 Alertmanager 连接/发现/访问

Alertmanager 已收到通知，但默认接收器接收器没有将其发送到的目的地。结果如何？

• 即使收到，也可能没有实际的 webhook 通知
• 假定已自动发送到默认 webhook。
• Prometheus规则自动删除
• 收到的通知立即转化为工作成功。

Webhook 组解决了旧 Pod 并启动了新 Pod。我应该怎么办？

• 既然有一个已解决，那么新的 pod 也被判断为已恢复。
• 将单个通知状态与当前目标标签进行对比
• 现在该小组已抵达，所有 pod 均已宣布健康
• 如果通知名称相同，则省略时间和pod

配置更改后，查询立即为空，控制器仍在运行。正确的下一步行动是什么？

• 由于查询为空，立即重新安装整个环境
• 保存随机的正常JSON以先通过检查
• 通过检查设置和反射日志重新观察相同的环境
• 将 for 值设置为 0 可以解决所有转发问题。

在观察 API 调用失败后，添加了一个空对象来进行诊断。什么是合理回报？

• inactive — 正常状态，无警报
• 已恢复 — 可观察到的故障已消失。
• 已通知 — 假定在转移后已清空
• 未知——没有必要的观察基础的状态