你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

检测应用程序的建议

适用于此 Azure 精心构建的框架卓越运营清单建议:

OE:07 设计和实施监视系统,以验证设计选择并影响未来的设计和业务决策。 此系统捕获并公开从工作负荷的基础结构和代码发出的操作遥测、指标和日志。

相关指南有关设计和创建监视系统的建议

本指南介绍使用检测启用应用程序的可观测性的建议。 生成可引入并集成到监视系统中的有意义的遥测数据。 通过使用检测,无需登录到远程生产服务器即可收集信息,以手动执行跟踪或调试。 检测数据包括可用于评估性能、诊断问题以及做出工作负荷决策的指标和日志。

关键设计策略

若要优化工作负荷的遥测数据,请检测应用程序以生成以下数据:

  • 日志 是离散事件的时间戳记录。 有三种形式的日志:纯文本、结构化和二进制。

  • 分布式跟踪日志 允许在请求通过不同的服务和组件时查看请求的路径。

  • 指标 是数值,用于描述特定时间点系统的各个方面。

注意

可以使用 Application Insights、Dynatrace 和 Elastic Application 性能监视器 等工具自动检测应用程序。 这些工具可简化检测,但也可以限制检测。 如果使用自动检测工具,则可以根据需要通过手动检测添加更多功能。

使用结构化日志和跟踪

使用结构化日志记录轻松地将日志集成到监视和分析平台中。 检测应用程序,以便可以更改详细程度级别。 常量详细日志记录可能会浪费存储资源,因此应根据需要将其打开和关闭,以便进行故障排除。

如果应用程序使用 Windows 事件跟踪(ETW),跟踪日志包含从跟踪事件创建的文本数据或二进制数据。 系统日志从基础结构中的事件(如 Web 服务器)生成跟踪日志内容。 文本日志内容设计为可由人类读取,但应确保它以自动化系统也可以分析的格式编写。

对日志进行分类,并使用单独的日志记录系统每个操作方面的跟踪输出。 如果对日志进行分类,则可以快速筛选日志消息,而不是处理单个冗长的文件。 切勿将具有不同安全要求的信息(例如审核信息和调试数据)写入同一日志。

注意

日志可能以文件系统中的文件的形式实现,或者可能以某种其他格式保存日志,例如 Blob 存储中的 Blob。 日志信息也可能保存在结构化存储中,例如表中的行。

捕获应用程序指标

指标或 示例是特定时间系统中某些方面或资源的计数,其中包含一个或多个关联的标记或维度。 指标的单个实例在隔离中不起作用,应随着时间的推移捕获指标。 考虑应记录哪些指标以及记录频率。 生成的数据过于频繁可能会给系统带来沉重的负载,但不频繁的数据捕获可能会导致你错过导致重大事件的情况。 捕获数据的适当频率可能因指标而异。 例如,服务器上的 CPU 使用率可能因秒数而异,但如果在数分钟内保持一致,使用率较高只会成为问题。

促进跨组件关联

可以轻松监视单个和系统级性能计数器、捕获资源的指标,以及从各种日志文件获取应用程序跟踪信息。 某些监视需要在监视管道中的分析和诊断阶段进行数据关联。 此数据可以采用多种形式,并且必须提供足够的检测数据来映射这些不同表单的分析过程。 例如,在应用程序框架级别,线程 ID 可能会标识任务。 在应用程序中,相同的工作可能与完成该任务的用户的用户 ID 相关联。

线程和用户请求之间不太可能是 1:1 映射,因为异步操作可能会对多个用户重复使用相同的线程。 为了进一步使问题复杂化,单个请求可以关联到多个线程,因为它流经系统。 如果可能,请将每个请求与通过系统作为请求上下文一部分而传播的唯一活动 ID 相关联。 用于生成活动 ID 并将其加入到跟踪信息的方法取决于用于捕获跟踪数据的技术。

所有监视数据应该以相同的方式标上时间戳。 为了保持一致,请使用协调世界时记录所有日期和时间。

注意

在不同时区和网络中运行的计算机可能无法同步。 请不要仅依赖于时间戳来关联跨多台计算机的检测数据。

捕获相关数据

确定需要收集的检测数据时,请考虑以下几点。

人工可读数据

确保跟踪事件捕获的信息既是计算机,也是可读的。 为此信息采用定义完善的架构,以帮助实现跨系统自动处理日志数据,并为读取日志的操作和工程人员提供一致性。

在数据中包含以下环境信息:

  • 部署环境
  • 处理计算机
  • 进程的详细信息
  • 调用堆栈

投资可追溯性和相关性

提供足够的上下文,例如与请求的特定实例关联的活动 ID,以便开发人员或管理员可以确定每个请求的源。

数据上下文还可能包含用于将活动与所执行计算工作和所用资源关联的信息。 这项工作可能跨越进程和计算机边界。

对于计量,上下文应直接或间接包含对导致请求的客户的引用。 此上下文提供有关捕获监视数据时应用程序状态的有用信息。

捕获所有相关数据

记录发出的所有请求和位置或区域。 可以使用此信息来帮助识别特定于位置的热点。 它们还可以用于帮助确定是否要对应用程序或其使用的数据重新分区。

仔细记录并捕获异常的详细信息。 由于异常处理不佳,严重调试信息经常丢失。 捕获应用程序引发的所有异常详细信息,包括任何内部异常或其他上下文信息,例如调用堆栈(如果可能)。

努力实现数据一致性

一致的数据可以帮助你分析事件并将其与用户请求相关联。 请考虑使用全面的可配置日志记录包来收集信息。 日志记录包有助于避免依赖开发人员在实现系统的不同部分时采用你的方法。

从关键性能计数器收集输入/输出卷、请求数、内存、网络和 CPU 使用率等数据。 某些基础结构服务提供自己的性能计数器,例如:

  • 数据库的连接数。
  • 事务速率。
  • 成功或失败的事务数。

应用程序还可以定义自己的性能计数器。

考虑外部依赖项

记录所有外部服务调用。 外部调用可能会对以下情况进行:

  • 数据库系统。
  • Web 服务。
  • 属于基础结构的其他系统级服务。

记录有关每个调用的持续时间以及调用成功或失败的信息。 如果可能,请捕获所有重试和由于发生任何暂时性错误而失败的相关信息。

确保遥测系统兼容性

在许多情况下,检测信息作为一系列事件生成,并传递到单独的遥测系统进行处理和分析。 遥测系统通常独立于任何特定的应用程序或技术。

遥测系统使用定义的架构分析信息。 架构指定一个协定,用于定义遥测系统可以引入的数据字段和类型。 通用化架构,以允许从各种平台和设备到达的数据。 通用架构应包括与所有检测事件相关的字段,例如:

  • 事件名称。
  • 事件时间。
  • 发送方的 IP 地址。
  • 事件关联所需的详细信息,包括:
    • 用户 ID
    • 设备 ID
    • 应用程序 ID

请记住,许多设备可以引发同一应用程序的事件,因此架构不应依赖于设备类型。 应用程序应支持漫游或跨设备分发。 该架构还可以包括跨应用程序通用的特定方案的相关域字段,例如:

  • 有关异常的信息。
  • 应用程序启动和结束事件。
  • Web 服务 API 调用的成功或失败。

建立生成相同事件集的域字段,以跨应用程序生成一组常见报表和分析。 可能需要配置架构以包含用于捕获应用程序特定事件的详细信息的自定义字段。

OpenTelemetry 是 API、SDK 和其他工具的供应商中立集合。 可以使用 OpenTelemetry 检测应用程序,并跨语言一致地生成有意义的遥测数据。 OpenTelemetry 与工具无关,因此它与许多可观测性平台(包括开源和商业产品/服务)兼容。 Microsoft采用 OpenTelemetry 作为检测标准工具。

优化检测代码

以下列表汇总了有关检测云中运行的分散式应用程序的最佳做法:

  • 使日志易于阅读,且易于分析。 尽可能使用结构化日志。

  • 日志消息简明扼要。

  • 标识日志的源。

  • 在写入每个日志记录时添加时间戳信息。

  • 对所有时间戳使用相同的时区和格式。

  • 在适当的位置对日志进行分类和写入消息。

  • 不要透露有关系统的敏感信息或有关用户的个人信息。 在记录此信息之前清理此信息,但保留任何相关详细信息。

  • 记录所有关键异常,但允许管理员根据需要打开和关闭日志记录,以减少异常和警告。

  • 捕获并记录所有重试逻辑信息。 此数据可用于监视系统的暂时性运行状况。

  • 跟踪进程调用,例如对外部 Web 服务或数据库发出的请求。

  • 不要在同一日志文件中混合具有不同安全要求的日志消息。

  • 确保所有日志记录调用都是 不阻止业务运营进度的触发和忘记 操作。 从此规则中排除审核事件,因为它们对业务至关重要。

  • 确保日志记录是可扩展的,并且对具体目标没有任何直接依赖项。

  • 确保所有日志记录都是故障安全的,并且不会触发级联错误。

  • 将检测视为正在进行的迭代过程,并定期查看日志。

使用应用程序分析

  • 仅在必要时实现分析,因为它可能会给系统带来重大开销。 通过使用检测,每次发生事件时,分析都会记录事件,例如方法调用。 但是,采样仅记录选定的事件。

  • 分析选择可以是基于时间的,例如每 n 秒一次,也可以基于频率,例如每 n 个请求一次。 如果事件频繁发生,分析可能会导致系统负担过多,并影响整体性能。 在这种情况下,采样方法更可取。 但是,如果事件频率太低,则采样可能会遗漏事件。 在这种情况下,分析可能是更好的方法。

Azure 便利化

Autoinstrumentation 适用于使用 Application Insights 监视的许多 Azure 和本地应用程序。 自动结构函数会自动配置应用程序,以便为 Application Insights 提供丰富的遥测数据,并轻松访问应用程序仪表板应用程序映射等体验。 有关支持的托管平台和开发语言,请参阅 支持的环境、语言和资源提供程序

卓越运营清单

请参阅完整的建议集。