通过可观测性改进操作
- 15 分钟
|
|
|---|
构建团队始终希望通过监视工作负载并考虑 Azure Well-Architected 框架的所有支柱来提高质量的文化。 为团队和利益干系人提供所需的数据,例如统计信息、趋势和见解,以便他们可以做出明智的决策,无论是快速修复还是长期规划。 使用从数据中学到的内容来不断改进。
专为可观测性而设计的作可帮助你保持领先问题、维护质量和安全性、规划增长和管理产品。
监视的一个关键部分是运行状况建模,这有助于你在问题变成影响客户的大事件之前发现问题。 高效的监视意味着对问题做出反应的时间更少,也减少了改进体验的时间。
示例方案
Contoso 构建了一个名为 Contoso Real Estate 的内部 Web 应用,以帮助新员工和正在搬迁的员工。 它让人们在移动期间搜索和预订短期住房。 HR 团队还使用该应用来帮助进行搬迁过程。
应用实时且完全托管在 Azure 中。 它使用 Azure 容器应用基于微服务构建,还使用 Azure Functions、Azure Database for PostgreSQL、Azure Blob 存储和 Azure Monitor。
通过遥测查看工作负荷
从应用程序代码中捕获遥测数据,以连接其运行方式的关键步骤,以便从高级趋势到详细作的完整情况。
根据问题严重程度确定作的优先级,并了解找出上下文的详细信息。 此信息对于故障排除至关重要。
Contoso 的挑战
在最近更新 Contoso 房地产应用后,用户报告搜索页面有时会显示空白屏幕或通用错误消息。 它不会每次发生,通常刷新页面或再次尝试搜索会修复它。
当团队检查搜索微服务的日志时,他们注意到了更多错误,特别是尝试连接到 Azure Database for PostgreSQL 时超时。 但是,他们无法判断这些错误是否相同,导致用户在前端看到的问题。
应用方法和结果
开发团队决定扩展 Web 应用和核心微服务中的日志记录,以确定发生了什么问题。 具体而言,对于搜索功能,他们现在正在记录搜索词、请求时间、客户端 IP 地址和与搜索绑定的用户名。 此额外信息应帮助他们跨系统的不同部分连接点。
此更改帮助团队确认用户问题的根本原因是数据库查询超时未在最新应用更新中正确处理。 他们弄清楚后,修复它非常简单。
该团队现在正在设计一种使用 OpenTelemetry 的新方法,以构建涵盖所有解决方案层的更完整的分布式跟踪解决方案。
在仪表板中可视化监视数据
在仪表板中收集和可视化数据,以显示特定于受众的监视数据,并记住大局。 使用情况仪表板突出显示关键信息,并为利益干系人提供见解。 对操作员活动(如事件响应)使用具有向下钻取功能的作仪表板和工作簿。 经常刷新仪表板并提供精细的详细信息。
可以使用可视化效果分析趋势、跟踪业务目标和管理事件。
客户感兴趣的仪表板更易于理解并帮助团队更快地发现问题并采取行动。
Contoso 的挑战
- 工作负荷团队将来自所有解决方案层的遥测数据收集到单个 Log Analytics 工作区中,每个人都可以访问该工作区,包括开发和运营团队和其他利益干系人。 但实际上,使用这些数据并不容易。 这很复杂,很笨拙,这让试图将背景噪音与可作数据分开的团队成员感到沮丧。
应用方法和结果
团队着手使用仪表板收集和可视化数据。 每个仪表板都是针对特定受众定制的:
对于利益干系人,仪表板更注重大局,例如整体解决方案运行状况、用户数、搜索和预留。 它清楚地说明了解决方案从业务角度的表现。
对于运营团队,仪表板和工作簿更深入,数据更详细,并且能够向下钻取到特定区域。 这些仪表板有助于进行故障排除、事件响应和日常监视。
仪表板使用户能够更有效地分析趋势、跟踪业务目标和管理事件。 每个仪表板都有与其预期受众更相关的数据,并受其兴趣和需求驱动。
设计可靠的警报策略
通过向正确的人员发送警报并明确说明和严重性级别,使警报可作。 包括来自不同来源的信息,使其全部位于一个位置,并跟踪与业务目标不一致的任何内容。
仅针对需要作的事件触发警报,并针对主动警报,帮助你在问题完全失败之前解决问题。 良好的警报系统应该告诉你错误,它有多严重,并给出足够的信息,使事情清晰和可作。 然后,团队可以直接跳到解决问题,而无需浪费时间。
Contoso 的挑战
Contoso 使用 Azure Monitor 向运营团队发送警报(出现问题)。 但是,团队当前收到过多的警报,这些警报不相关、不明确或冗余。 这会导致警报疲劳。 团队缺少重要的警报,工作效率正在放缓。
如果警报给每个人一个头,也出现了一些中断情况,可能会阻止或最小化。 例如,在某些情况下,数据库查询处理时间逐渐减慢导致中断。 如果团队有更智能的警报,这些警报在之前标记了这些慢速,则他们可能能够在系统失败之前介入。
应用方法和结果
作团队启动清理工作,以消除所有只是添加干扰的低优先级警报。 仅允许关键且可操作的警报保持激活状态。 他们还查看剩余的警报,以确保他们提供足够的上下文,以便团队可以解决问题,而无需更多信息。
他们有机会设置新的主动且可作的警报,以便在发生故障之前执行作。 例如,他们添加了一个新的警报,以便在数据库查询性能出现稳定放缓时通知数据库管理员。
接下来,他们正在探索自动响应常见警报的方法,例如数据库速度变慢。