通过可观测性改进运营
 深入了解系统、获取见解并做出数据驱动的决策。 |
|---|
通过监视工作负载并考虑 Azure 架构良好的框架的所有支柱，构建持续提升质量的文化。 通过提供必要的数据、统计信息和趋势，使团队和利益干系人能够跨多个方面做出短期和长期决策。 从数据中学习并推动改进。
为可观测性构建运营是主动维护应用程序、质量和安全保障、容量计划和产品管理的关键。
应用程序监视的一个关键方面是使用运行状况建模来帮助你在问题成为事件并影响客户体验之前预测它们。 高效的监视可减少在事件管理上花费的反应周期。
示例方案
Contoso 开发了一个应用供内部使用，称为 Contoso 地产。 此 Web 应用让新员工或正在调动的现有员工可以搜索和预留短期住房，以帮助他们的调动顺利完成。 Contoso 的人力资源部门也使用该应用来协助调动工作。
该应用在生产环境中，且完全部署在 Azure 中。 它基于使用 Azure 容器应用的微服务构建，还使用 Azure Functions、Azure Database for PostrgreSQL、Azure Blob 存储和 Azure Monitor。
通过遥测观察工作负载
从与执行流的关键点关联的应用程序代码发出遥测，并提供不同粒度级别的端到端视图。
根据严重性级别确定操作的优先级，并根据其详细程度了解上下文。 此信息对于故障排除至关重要。
Contoso 的挑战
- 用户报告称，在最近的 Contoso 地产应用程序更新后，他们会偶尔在 Web 应用的搜索页上看到空白页面或常规错误消息。 这些错误似乎是随机的，如果用户只是刷新页面或重新提交搜索，搜索功能通常有效。
- 在搜索微服务上检查日志后，该团队注意到由于连接到 Azure Database for PostgreSQL 超时而导致的错误数增加，但他们目前无法判断他们在搜索微服务日志中看到的错误是否与用户看到的错误页相对应。
应用方法和成果
- 该开发团队已决定利用他们从 Web 应用和核心微服务中记录的信息来深入了解问题。 对于搜索方案，他们想要确保捕获到搜索词以及其他可用的事务属性，例如时间、客户端 IP 和与搜索关联的用户名。 此额外数据应为他们提供了足够的信息来跨层关联事务。
- 此更改让团队可以确认在应用的最新更新中未正确处理的数据库查询超时是用户遇到的失败的根本原因。 找到根本原因后，团队实施修复就非常简单了。
- 该团队正在设计一种使用 OpenTelemetry 的新方法，以实现更全面的分布式跟踪解决方案，涵盖所有解决方案层。
在仪表板中可视化监视数据
在仪表板中聚合和可视化数据，呈现适合受众并考虑业务上下文的监视数据。 使用情况仪表板显示数据，以推动利益干系人之间的意识。 对操作员活动（如事件响应）使用具有向下钻取功能的操作仪表板和工作簿。 经常刷新仪表板并提供精细数据。
借助可视化效果，你可以分析趋势、跟踪业务目标并管理事件。
针对客户兴趣定制的仪表板会使解读具有相关性，并加快检测和操作的速度。
Contoso 的挑战
- 该工作负载团队将来自所有解决方案层的遥测数据聚合到单个 Log Analytics 工作区中，该工作区可由运营和开发团队以及其他项目利益干系人访问。 但是，与数据交互非常困难和复杂，这让需要从可操作数据中辨别背景噪音的团队成员感到沮丧。
应用方法和成果
- 该团队开始努力使用仪表板聚合和可视化数据。 每个仪表板都将针对特定受众定制：
- 解决方案利益干系人的仪表板将更面向业务，提供解决方案整体运行状况的更高级别概述，以及服务的用户数、搜索数、执行的预留数等业务指标。
- 运营仪表板和工作簿将为运营团队提供更详细、更精细的数据。 这些仪表板将具有向下钻取功能，允许用户在不同粒度级别浏览数据。 用户将能够使用这些仪表板和工作簿来执行故障排除和其他事件响应任务。
- 仪表板使用户能够更有效地分析趋势、跟踪业务目标和管理事件。 每个仪表板上显示的数据将与其预期受众更相关，并受其兴趣和需求驱动。
设计可靠的警报策略
通过通知责任角色标准化说明和严重性级别，使警报可操作。 提供从各种来源整理的信息，并跟踪与业务目标的偏差。
仅针对需要操作的事件触发警报，并争取实现在降级状态变为失败之前启动操作的主动和引发思考的警报。 良好的警报系统可识别操作和严重性，并提供恰好足够的数据来驱动清晰性和目的。 操作员可以在没有延迟的情况下开始修正。
Contoso 的挑战
- Azure Monitor 用于在出现问题时向运营团队发送警报。 但是，团队当前收到了过多不相关、不明确或冗余的警报。 这会导致警报疲劳，并影响团队的工作效率，导致一些重要的警报被忽视。
- 此外，还发生过一些中断情况，如果发出了预测故障的警报，本可以避免或最大限度地减少这些中断。 如果团队在发生中断之前有更好的警报系统，则本可以避免这些情况。 例如，在某些情况下，数据库查询处理时间的减慢导致了中断。 在对中断进行故障排除时，团队注意到查询处理性能会随时间缓慢下降，越来越糟，直到导致完全中断为止。
应用方法和成果
- 运营团队发起了一项计划，清理导致警报疲劳的所有低优先级警报。 仅允许关键警报和可操作警报保持活动状态。 此外，团队会审查（并根据需要增强）那些将保持活动的警报，以确保它们包含足够的上下文，使他们能够采取必要的纠正措施。
- 他们还借此机会定义了新的主动和可操作的警报，使他们能够在发生故障之前采取行动。 例如，他们生成了一个新的警报，它会在数据库查询性能出现一致的减速后立即通知 DBA。
- 下一步，团队将调查对常见警报的自动响应，例如数据库查询性能情况。