有关检测应用程序的建议

适用于此 Azure Well-Architected 框架卓越运营清单建议：

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

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

关键设计策略

若要优化工作负载的遥测数据，请检测应用程序以生成以下数据：

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

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

• 指标 是描述特定时间点系统方面的数字值。

日志和分布式跟踪日志

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

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

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

指标

指标或 示例是系统中特定时间的某些方面或资源的计数，具有一个或多个关联的标记或维度。 指标的单个实例在隔离中没有用，应随时间推移捕获指标。 请考虑应记录哪些指标以及记录的频率。 过于频繁生成的数据可能会给系统带来沉重的负载，但不经常捕获数据可能会导致你错过导致重大事件的情况。 捕获数据的适当频率可能因指标而异。 例如，服务器上的 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 简化

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

相关链接

• Application Insights 概述
• 什么是 Application Insights 的自动trumentation？
• Azure Monitor 日志概述
• Azure Monitor 指标概述
• 收集 ETW 事件以分析 Azure Monitor 日志
• 有关设计和创建可观测性框架的建议
• 什么是分布式跟踪和遥测关联？

社区链接

• OpenTelemetry

卓越运营清单

请参阅完整的建议集。