练习 - 定义运行状况状态、指标和阈值
在本练习中，我们继续使用之前创建的运行状况模型结构。 你的任务是量化示例应用程序的各个组件的运行状况状态。
在运行状况模型结构中，首先从用户流的顶部开始评估层，然后转到较低层。
用户流运行状况状态
到目前为止，我们发现了两个用户流：列出目录项和添加注释。 若要确定每个流的运行状况状态，请提出如下问题：
- 何时将用户流视为正常？
- 它可以在降级状态下运行吗？
根据实现和功能要求，确定参与用户流的应用程序组件。 这些组件在示例体系结构组件中描述。
| 用户流 | 组件 |
|---|---|
| 列出目录项 | 前端内部 Web 应用程序，目录 API |
| 添加注释 | 前端内部 Web 应用程序、目录 API、后台处理器 |
如果这些组件中的任何一个变得不正常，则用户流预计会变得不正常。
注意
某些应用程序可以在特殊的“降级”模式下运行。 例如，如果 Contoso Shoes 实现本地浏览器缓存，则使用 Web 应用程序的员工可以创建注释，但无法发送注释，并且在目录 API 恢复正常（浏览器可以持续检查）之前不会更新客户视图。
应用程序组件运行状况状态
确定影响组件运行状况的指标。 在此步骤中，需要了解组件的功能。 提出以下问题：
- API 中的处理时间是可以接受的，以保持良好的用户体验？
- 是否有任何预期错误？ “正常”错误率是多少？
- “正常”处理时间是多少？ 如果处理时间高于正常时间，这意味着什么？
- 如果无法访问 Azure Cosmos DB，写入操作会发生什么情况？
这些问题应会引导你获得关键指标的特定且可度量的阈值。 例如，可以考虑目录 API 组件的这些阈值。
| 指标和阈值 | 运行状况 |
|---|---|
| 响应时间 < 150 毫秒失败请求计数 < 10 | Healthy |
| 响应时间 < 300 毫秒失败请求计数 < 50 | 已降级 |
| 响应时间 > 300 毫秒失败请求计数 > 50 | 不正常 |
可以从应用程序监视解决方案（如 Application Insights）获取值。
Azure 资源运行状况状态
Azure 服务运行状况状态基于特定资源。 例如，Azure Cosmos DB 报告数据库事务单位 (DTU) 利用率，Azure 应用服务提供有关 CPU 利用率的信息。
有关按资源类型划分的指标的信息，请参阅 Azure Monitor 支持的指标。
运行状况状态和阈值
评估应用程序的所有层后，应具有类似于此示例的组件及其运行状况定义的列表。
| 组件 | 指示器/指标 | 正常 | 已降级 | 不正常 |
|---|---|---|---|---|
| “列出目录项”用户流 | 基础运行状况状态 | 前端运行正常，目录 API 运行正常 | ||
| “添加注释”用户流 | 基础运行状况状态 | 前端运行正常、目录 API 运行正常和后台处理器运行正常 | ||
| HTTP 前端 Web 应用程序 | # 非 20x HTTP 响应/分钟 | 0 | 1-10 | > 10 |
| 目录 API | # 异常/秒 | < 10 | 10-50 | > 10 |
| 平均处理时间（毫秒） | < 150 | 150-500 | > 500 | |
| 后台处理器 | 平均排队时间（毫秒） | < 200 | 200-1,000 | > 1,000 |
| 平均处理时间（毫秒） | < 100 | 100-200 | > 200 | |
| 失败计数 | < 3 | 3-10 | > 10 | |
| Azure Cosmos DB | DTU 利用率 | < 70% | 70%-90% | > 90% |
| Azure Key Vault | 失败计数 | < 3 | 3-10 | > 10 |
| Azure 事件中心 | 处理积压工作长度（传出/传入消息） | < 3 | 3-20 | > 20 |
| Azure Blob 存储 | 平均延迟 (ms) | < 100 | 100-200 | > 200 |
在此示例中，前端 Web 应用程序和目录 API 的错误容错能力不同。 此差异与对应用程序的技术理解有关。 所有前端错误都应在客户端处理，因此阈值为零。 但是，在 API 层上，允许 10 个异常来解释用户引起的错误。 例如，“404 - 未找到”等错误并不一定表示存在运行状况问题。