你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Application Insights 是一种可扩展的应用程序性能管理服务，可用于监视实时应用程序并自动检测性能异常。 它包括强大的分析工具，可帮助你诊断问题并了解用户与应用程序交互的方式。 本架构指南依据 Azure Well-Architected Framework 的五大原则，提供对 Application Insights 的最佳实践。
技术范围
本指南重点介绍以下 Azure 资源的相关决策：
- Application Insights
- Log Analytics 工作区
Note
Application Insights 在 Log Analytics 工作区中存储和公开数据。 评估指标时，请将 Log Analytics 保留为 Application Insights 的关键依赖项。 有关详细信息，请参阅 Well-Architected Framework 关于日志分析的观点。
Reliability
可靠性支柱的目的是通过 建立足够的复原能力和从故障快速恢复来提供持续的功能。
可靠性设计原则 为各个组件、系统流和整个系统提供高级设计策略。
工作负荷设计清单
根据可靠性设计评审核对清单开始实施您的设计策略。 确定其与业务需求的相关性，并牢记对 Log Analytics 的依赖关系。 扩展策略以根据需要包含更多方法。
使应用程序监视设计与业务目标保持一致，避免不必要的复杂性。 确定所需的 Application Insights 资源数 以及部署位置。
根据数据的关键性配置采样。 确定工作负荷的用户和系统流，确定要收集的事件，并相应地配置采样。
- 有关手动检测的应用程序，请参阅 Azure Monitor OpenTelemetry 发行版或 Application Insights SDK（经典 API）。
- 对于自动检测，采样在特定于环境的文章中说明。 有关详细信息，请参阅 在 Azure Functions 中配置采样。
创建全面的复原计划。
- 首先执行故障模式与影响分析，以确定 Application Insights 可能出现故障或无法访问的潜在情形。 这些原因可能包括网络问题、身份验证问题或服务中断。
- 根据应用程序监视对你的业务目标的重要性，确定如果 Application Insights 在启动时或运行时不可达，你的工作负荷应如何表现。 定义并记录工作负荷的预期行为。
- 测试复原计划。 例如，可以使用网络安全组规则验证网络故障，并通过更改连接字符串对失败进行身份验证。
通过定义数据收集组件的目标来规划工作区复原和恢复。
- 评估你收集的数据的关键性，并确定它是否需要可恢复。
- 查看 Application Insights 和 Log Analytics 工作区 的服务限制，以了解对数据收集和保留的限制以及服务的其他方面。
- 请考虑迁移到 专用群集 ，以利用工作区复原能力，其中定义的保留期内 Application Insights 遥测的可用性至关重要。
- 使用 诊断设置 将平台日志和指标导出到所选目标（例如存储帐户），以便进行备份和恢复。
实施及时可靠的缩放策略，以规划数据引入增长。 随着流量的增长，监视和调整采样和数据引入的限制，以防止由于采样或超过 每日上限而丢失数据。 这有助于确保数据摄取过程能够随着流量的增加而有效扩展。
确保在发生服务故障时快速恢复应用程序监视解决方案。 采用基础结构即代码并使用 Bicep 模板 在 Application Insights 中创建或重新创建用户体验，包括 警报、 仪表板和 查询。 此方法有助于确保快速还原所有关键组件，从而最大限度地减少停机时间和维护服务可靠性。
配置建议
| Recommendation | Benefit |
|---|---|
| 每个环境的每个工作负荷使用一个 Application Insights 资源，例如一个用于开发、一个用于暂存、一个用于生产。 | 使用多个 Application Insights 资源可防止混合不同应用程序版本的遥测数据，并帮助确保一个资源的配置错误不会影响另一环境的日志记录。 |
| 在基础 Log Analytics 工作区所在的同一区域中部署 Application Insights 资源。 | 由于 Application Insights 要求 Log Analytics 能正常运行，若将这两种资源放在不同的区域，则区域故障导致问题的可能性会增加一倍。 |
| 使用 Azure Monitor 日志的最佳做法实现可复原的工作区设计。 | 最佳做法通过最大程度地减少中断来帮助确保持续且可靠的监视。 |
安全性
安全支柱的目的是为工作负荷提供 保密性、完整性和可用性 保证。
安全设计原则通过向 Application Insights 的技术设计应用方法，为实现这些目标提供了高级设计策略。
工作负荷设计清单
根据 设计评审清单制定针对安全 的设计策略，并确定漏洞和控制，以增强安全防御能力。
查看 Azure Monitor 安全基线。 它提供有关安全最佳做法的指导，可帮助保护 Azure 上的云解决方案，包括 Application Insights。
使 Application Insights 工具保持更新，以帮助确保您的应用监控解决方案的安全性。 请遵循 SDK 更新指南 并至少每年更新 Application Insights SDK（经典 API）一次。 建议遵循 Azure Monitor OpenTelemetry 发行版的类似做法。
定义在 Application Insights 中处理个人数据的策略。 为确保持续合规性，请定期验证数据收集和处理（包括 IP 地址和个人数据） 是否符合 GDPR 等相关法规。
在应用程序监视设计中创建有意的分段。 确定所需的 Application Insights 资源数 。
使用 Azure Monitor 客户管理的密钥。 默认情况下，Azure Monitor 中的数据使用Microsoft管理的密钥进行加密。 可以使用自己的加密密钥来保护工作区中的数据和保存的查询。 借助 Azure Monitor 中的客户管理的密钥，可以更灵活地管理对存储数据的访问控制。
控制网络流量。 考虑专用连接以访问 Azure 服务。 专用连接有效地将流量与公共 Internet 隔离开来。 专用网络的数据流包括数据引入和查询操作，每个操作针对不同的端点。 这些终结点可以独立管理。 此方法允许你在维护公共查询访问时配置专用引入，反之亦然。 为此，可以通过在所有可用的网络边界上创建本地化的网络控件来应用深层防御原则。
通过保护存储系统和限制访问来增强数据保护。 请访问 Log Analytics 服务指南 ，了解如何保护收集的数据。
配置建议
| Recommendation | Benefit |
|---|---|
| 如果业务需求和托管环境不需要手动检测，请考虑使用 自动检测。 | 此方法无需手动 SDK 更新，无需更改代码，并消除维护检测代码的开销。 它还可以通过帮助确保一致的应用程序监视来增强安全性，而无需手动干预。 |
| 对身份验证和授权需求使用 托管标识 和 Microsoft Entra ID 。 | 无需凭据管理，因为 Azure 管理、轮换和保护这些凭据。 |
| 停止收集个人数据或模糊处理、匿名或调整收集的数据。 默认情况下，Application Insights 不会存储 IP 地址。 建议保留此默认设置。 | 排除数据被视为 个人 数据，并防止违反任何合规性要求或本地法规。 |
| 每个环境为每个工作负载使用一个“Application Insights”资源。 例如，使用一个用于开发，一个用于过渡，一个用于生产。 | 使用多个 Application Insights 资源有助于确保数据隔离和安全性，并更轻松地应用特定于环境的配置和访问控制。 |
| 使用 Azure 专用链接 通过专用终结点访问 Azure 服务。 遵循配置和限制。 避免将你的 AMPLS 连接到共享相同 DNS 的多个虚拟网络，因为这会导致错误的专用终结点错误。 | 正确配置的 AMPLS 拓扑通过保持日志流量在完全专用网络上，增强了工作负荷日志的机密性。 |
成本优化
成本优化侧重于 检测支出模式、优先考虑关键领域的投资，以及优化其他 以满足组织预算，同时满足业务需求。
成本优化设计原则提供实现这些目标的高级设计策略，并在与 Application Insights 及其环境相关的技术设计中做出必要的权衡。
有关 Application Insights 资源的基础 Log Analytics 工作区的数据费用计算方式的更多信息，请参阅 Azure Monitor 日志成本计算和选项。
工作负荷设计清单
根据投资的成本优化设计评审核对清单开始实施您的设计策略。 微调设计，使工作负荷与为工作负荷分配的预算保持一致。 设计应使用正确的 Azure 功能，监视投资，并查找随时间推移进行优化的机会。
查看 Azure Monitor 定价 以创建成本模型。 使用 定价计算器估算初始成本、运行率和持续成本。 请注意，Application Insights 通过其日志数据摄入到的 Log Analytics 工作区计费。
调整收集的数据量。
限制工作区的计划外费用。 可以在 Application Insights 和 Log Analytics 中设置每日上限。
定期查看区域定价和可用定价层等成本。 大多数 Azure Monitor 实施的最大费用通常是 Log Analytics 工作区中的数据的提取和保留。 有关详细信息，请参阅 Log Analytics 服务指南中的 Azure Monitor 日志成本计算和选项 或 成本优化部分 。
定期删除或优化应用程序监视解决方案的旧组件、不需要的组件和未充分利用的组件。编辑 ApplicationInsights.config 以关闭不需要的集合模块。 例如，你可能决定不需要性能计数器或依赖项数据。 在代码中使用遥测筛选器或处理器，通过不记录或采样不相关调用来帮助优化组件成本。
优化环境成本。 确定所需的 Application Insights 资源数 以及部署位置。 优化每个环境收集的日志级别和指标，以有效管理成本。 例如，与开发环境相比，生产环境可能需要不同的日志记录级别。
优化流成本。 在代码中使用遥测筛选器或处理器，通过不记录或采样不相关调用来帮助优化组件成本。
优化代码成本。 请确保使用更新后的 Application Insights SDK。 早期版本的 ASP.NET Core SDK 和 Worker Service SDK 默认情况下会收集大量计数器，这些计数器是以自定义指标的形式收集的。 使用更高版本以仅指定所需的计数器。
优化人员时间。 使用 Application Insights 体验（例如 应用程序映射 和性能 视图），并为特定工作负载需求自定义保存的 查询、 仪表板 和 工作簿 。 使用 发布批注跟踪部署和其他事件。
配置建议
| Recommendation | Benefit |
|---|---|
| 在 Application Insights 和 Log Analytics 中设置每日上限，但尽量避免达到上限。 | 达到每日上限可能会导致数据不会写入 Log Analytics 工作区。 设置上限是限制支出的风险但有效的解决方案。 |
| 对于标准可用性测试，测试需求可能会因生产环境和预生产环境而异，需要在不同位置进行测试。 相应地减少位置数量。 | 测试会产生成本，因此只需进行足够的测试以确保你对工作负荷的运行状况有信心。 |
| 在基础 Log Analytics 工作区所在的同一区域中部署 Application Insights 资源。 | 此方法可最大程度地减少延迟，并降低与跨区域遥测相关的成本。 |
| 降低非关键流的采样率，并为具有高关键性的流增加采样率。 将遥测筛选器用于非必要遥测。 | 设计 Application Insights 集成时，数据量是成本驱动因素。 通过采样率和筛选器减少数据量是使数据收集保持控制的潜在解决方案。 |
| 限制可在每个页面视图中报告的 Ajax 调用数，或禁用 Ajax 报告。 如果禁用 Ajax 调用，则还会禁用 JavaScript 关联。 | 为客户端应用程序设计 Application Insights 集成时，数据量是成本驱动因素。 通过减少的客户端页面报告来减少数据量是一种使数据收集成本保持控制的潜在解决方案。 |
| 使用 预聚合指标 更高效地处理大容量遥测数据，并限制自定义指标的使用。 但是， 启用自定义指标维度警报 的 Application Insights 选项也会增加成本。 使用指标来确保获得成本节省。 | 所有自定义指标都存储在日志和指标存储中。 预聚合指标可降低与自定义指标相关的存储成本。 |
| 如果业务需求和托管环境不需要手动检测，请考虑使用 自动检测。 | 这种方法通过消除手动 SDK 更新、与新版本相关的代码更改以及维护检测代码的开销，优化软件工程时间。 |
| 限制不需要的跟踪日志记录： • 删除健康检查。 请参阅使用 Azure Monitor OpenTelemetry 发行版筛选出优化成本中的干扰跟踪。 • 对于 Azure Kubernetes 服务（AKS），请调整 控制平面和数据平面日志。 • 对于 Azure Functions， 调整日志级别和范围 以优化日志数量。 |
限制不需要的跟踪日志记录可减少存储的数据量，从而降低存储成本。 |
卓越运营
卓越运营主要侧重于 开发实践、可观测性和发布管理的各个过程。
卓越运营设计原则 提供了一个高级设计策略，用于实现这些运营需求目标。
工作负荷设计清单
基于运营卓越设计审查清单启动你的设计策略，以定义与 Application Insights 相关的可观测性、测试和部署流程。
将应用程序监控团队成员的专业特长集成到一系列可靠的实践中，以实现和监控您的工作负荷。 根据业务需求和支持 的环境、语言和资源提供程序，选择最适合你的情况的检测方法（例如自动检测或手动检测）。
通过保持 Application Insights 工具的更新，确保应用程序监控解决方案的最佳性能。 请遵循 SDK 更新指南 并至少每年更新 Application Insights SDK（经典 API）一次。 建议遵循 Azure Monitor OpenTelemetry 发行版的类似做法。 使用最新的 SDK 或发行版 可确保访问支持服务 并提供最新的功能和 bug 修复。
正式化理念和规划过程。 使用 工作项集成 在 GitHub 或 Azure DevOps 中轻松创建嵌入相关 Application Insights 数据的工作项。
配置 Application Insights 以监视 Web 应用程序的可用性和响应能力。 根据特定的业务需求使用内置功能，如 查询 和 仪表板 。 部署应用程序后，设置定期测试以监视可用性和响应能力。
制定有效的应急操作实践。 使用 警报 和 工作簿 来识别和响应事件。 明确定义人类的责任。 例如，确定在工作任务失败时由谁负责重启应用程序。
明确定义工作负荷的安全部署做法。 使用 发布批注 作为失败缓解策略的一部分来跟踪部署和其他事件。
配置建议
| Recommendation | Benefit |
|---|---|
| 如果业务需求和托管环境不需要手动检测，请考虑使用 自动检测。 | 这种方法通过消除手动 SDK 更新、与新版本相关的代码更改以及维护检测代码的开销，优化软件工程时间。 |
| 如果业务需求需要手动检测，请采用 Azure Monitor OpenTelemetry 发行版。 | 通过采用基于 OpenTelemetry 的检测方法，避免将来从 Application Insights SDK（经典 API）进行强制迁移。 |
| 使用 连接字符串。 | 使遥测数据采集更加可靠，并去除对全球数据采集端点的依赖。 |
性能效率
性能效率就是通过管理容量来保持用户体验，即使负载增加也不例外。 该策略包括缩放资源、识别和优化潜在瓶颈，以及优化峰值性能。
性能效率设计原则 提供了一个高级设计策略，用于根据预期使用量实现这些容量目标。
工作负荷设计清单
根据性能效率设计审查清单开始策略设计。 定义基于 Application Insights 的关键绩效指标的基线。
定义与应用程序监视要求相关的性能目标。 确定所需的 Application Insights 资源数 。
执行容量计划。 了解使用模式以及传入的数据量，并查看引入和采样率。
为应用程序监视解决方案选择适当的区域。 将 Application Insights 资源部署到基础 Log Analytics 工作区所在的同一区域中，以防止延迟和可靠性问题。 请参阅 “创建资源”。
评估所需的 Application Insights 资源数 。 使用单个 Application Insights 资源监视应用程序或应用程序组件可提供整体视图，但也会影响 应用程序映射 和 使用情况等体验的性能。
优化代码和基础结构。 定期评估自定义 Application Insights 代码以降低复杂性、提高性能并确保代码是最新的。
通过查看摄入和采样率了解使用模式和传入的数据量。 若要优化数据使用情况，请相应地调整它们并减少 自定义指标的数量，例如 ITelemetryProcessor。
配置建议
| Recommendation | Benefit |
|---|---|
| 每个环境为每个工作负荷使用一个 Application Insights 资源（例如一个用于开发，一个用于过渡，一个用于生产）。 | 此方法可防止混合不同应用程序版本的遥测数据。 |
| 适用时，确保适当设置分析频率和持续时间。 | 避免给正在运行的进程增加过多的开销。 |
Azure 策略
Azure 提供了一组与 Application Insights 及其依赖项相关的大量内置策略。 可以通过 Azure Policy 审核上述一些建议。 例如，可以检查以下情况：
- Application Insights 组件应防止从公共网络或 Microsoft Entra ID 未认证的源引入日志。
- 应强制将 Application Insights 组件链接到 Log Analytics 工作区以加密日志。
若要进行全面的治理，请查看 Application Insights 的 Azure Policy 内置定义 ，以及可能影响应用程序性能监视解决方案安全性的其他策略。
Azure 顾问建议
Azure 顾问是一名个性化的云顾问，可帮助你遵循最佳做法来优化 Azure 部署。
有关详细信息，请参阅 Azure 顾问。