Application Insights FAQ - 常见问题解答

有关检测应用程序以启用 Application Insights 的详细信息，请参阅数据收集基础知识。

通过检测应用程序启用 Application Insights 后，建议先查看实时指标和应用程序映射。

从服务器 Web 应用：

• HTTP 请求。
• SQL、HTTP、Azure Cosmos DB、Azure 表存储、Azure Blob 存储 和 Azure 队列存储 调用等依赖项。
• 异常和堆栈跟踪。
• 来自受支持工具的运行时指标。
• 使用 OpenTelemetry 自定义遥测、 JavaScript SDK 或 Click Analytics 发送的自定义事件和指标。
• 跟踪日志（如果配置相应的收集器）。

从客户端网页：

• 应用中未捕获到的异常，包括以下相关信息

  • 堆栈跟踪
  • 异常详细信息和错误随附的消息
  • 错误的行号与列号
  • 引发错误的 URL
  • 应用发出的网络依赖项请求：XML Http 请求 (XHR) 和 Fetch（默认已禁用提取集合）请求包括以下相关信息：
    • 依赖项源的 URL
    • 用于请求依赖项的命令和方法
    • 请求持续时间
    • 请求的结果代码和成功状态
    • 发出请求的用户的 ID（如果有）
    • 发出请求的关联上下文（如果有）

• 用户信息（例如位置、网络、IP）

• 设备信息（例如，浏览器、OS、版本、语言、型号）

• 会话信息

  注释

  对于某些应用程序（例如单页应用程序（SPA）），持续时间并不总是被记录下来，在这些情况下，默认值为 0。

  有关详细信息，请参阅 Application Insights 中的数据收集、保留和存储。

从其他源（如果配置）：

• Azure诊断
• 导入到 Log Analytics
• Log Analytics
• Logstash

使用 Serilog 等日志记录框架时，Application Insights 会将日志消息作为 Trace 遥测引入，并存储在 traces 表（或 AppTraces Log Analytics中）。 这是按设计进行的，因为类似 requests、dependencies 和 exceptions 这样的表被保留用于其各自的遥测类型。

有关详细信息，请参阅 Application Insights 遥测数据模型。

若要了解需要多少 Application Insights 资源才能涵盖不同环境中的应用程序或组件，请参阅 Application Insights 部署规划指南。

可以使用 Azure 资源监视器来 编写 PowerShell 脚本：

• 创建并更新 Application Insights 资源。
• 设置定价计划。
• 获取连接字符串。
• 添加指标警报。
• 添加可用性测试。

无法设置指标浏览报表或设置连续导出功能。

使用 REST API 运行 Log Analytics 查询。

建议使用 Azure Monitor OpenTelemetry Distro。

引入架构和终结点协议是公开提供的。

大多数 Application Insights 数据的延迟小于 5 分钟。 某些数据可能需要更长的时间，这在较大的日志文件中很常见。 请参阅 Application Insights 服务级别协议。

Application Insights 通过引入其日志数据的Log Analytics工作区计费。 默认按需付费日志分析（Log Analytics）定价层包括每个计费帐户每月 5 GB 的免费数据配额。 详细了解 Azure Monitor 日志定价选项。

• 如果您的 Azure Web应用程序托管在设有 Application Insights 收集端点的数据中心，则不会产生任何费用。
• 如果主机数据中心没有收集终结点，则应用的遥测数据将会产生Azure传出费用。

此答案取决于我们终结点的分布，而非应用程序洞察资源的托管位置。

是的，这可能会产生更多的网络成本，具体取决于遥测数据的来源和目标区域。 有关详细信息，请参阅 Azure 带宽定价。

如果在 Application Insights 中看到意外费用或高成本，本指南将有所帮助。 它涵盖了常见的原因，例如高遥测量、数据引入峰值和配置错误的采样。 如果您正在解决与成本峰值、遥测数据量、采样失效、数据上限、数据摄取量高或意外计费相关的问题，这将特别有用。 如需入门，请参阅 对 Application Insights 中数据引入量过高的问题进行故障排除。

Application Insights 使用传输层安全性 （TLS） 1.2 和 1.3。

有关旧 TLS 问题的任何常规问题，请参阅 解决 TLS 问题和 Azure 资源管理器 TLS 支持。

有关详细信息，请参阅 Application Insights 简介。

上下文

Application Insights 从应用收集遥测数据并将其存储在Log Analytics工作区中。 它适用于托管在任何位置的应用程序，不止在Azure上。

收集的内容以及从何处收集的内容

遥测数据来自：（1）添加到您的应用程序中的 SDK，包括您发送的任何自定义遥测，（2）可选的服务器代理，以及（3）由 Microsoft 运行的可用性测试。 典型数据包括请求、依赖项、异常和崩溃、性能计数器、客户端和服务器上下文、跟踪以及你发送的任何自定义事件或指标。 若要验证正在发送的内容，请在调试模式下运行应用，并检查 IDE 输出或诊断窗口。 对于网页，请打开浏览器开发人员工具并检查“网络”选项卡。可以通过实现遥测处理器在发送遥测数据之前筛选或扩充遥测数据。

保留和存储

原始数据保留期可设置为 30、60、90、120、180、270、365、550 或 730 天。 超过 90 天的保留可能会产生额外的费用。 聚合指标以 1 分钟粒度保留 90 天。 调试快照将保留 15 天。 数据存储在创建资源时选择的区域。 引入后，遥测是不可变的。 无法编辑遥测数据。 清除可用于在需要时删除数据。

访问、安全和加密

数据对你和具有访问权限的团队成员可见，并且可以导出。 Microsoft仅使用数据向服务提供受限人员访问权限，并且可以使用聚合统计信息来改进服务。 遥测通过 HTTPS 发送，数据静态加密，并在数据中心之间移动时进行加密。

隐私和负责任的使用

默认 SDK 模块侧重于性能、使用情况和诊断，通常不包括敏感数据。 不要将敏感数据放入 URL 中。 查看自定义遥测数据，使其不包括个人数据。 客户端 IP 用于地理位置，然后存储的 IP 字段默认为零。 如果需要遮蔽，请添加遥测初始化器。 如果你的应用需要用户选择退出，请在代码中禁用数据收集。 还查看看似无害的字段，例如个人设备上的设备名称。 可以在配置中或通过代码控制或禁用某些集合。 有关详细信息，请参阅地理位置和 IP 地址处理。

TLS

对传输中的数据使用新式 TLS。 不要硬编码较旧的协议版本。 允许该平台在新版本可用时协商及采用较新版本。 有关详细信息，请参阅 保护你的 Azure Monitor 部署。

本地缓冲和中断

如果与Azure的连接丢失或受到限制，则支持的 OpenTelemetry 导出者和当前的 SDK 可以本地缓冲遥测数据，然后重试。 有关当前的 OpenTelemetry 行为，请参阅 脱机存储和自动重试。 有关浏览器缓冲设置，请参阅 JavaScript SDK 配置。

Application Insights 和Azure Monitor不会控制用于 HTTPS 连接的 TLS 版本。 TLS 版本取决于运行应用程序的作系统和运行时环境。

若要确认正在使用的 TLS 版本，

• 查看您的操作系统和运行时或框架的文档。
• 如果需要进一步的帮助，请联系相应的支持团队。 不要使用 Application Insights 打开支持请求。

TLS 1.2+ 的示例语言和运行时支持

以下版本包括对 TLS 1.2 或更高版本的集成支持：

• .NET/ .NET Core：.NET Framework 4.6.2 或更高版本以及所有版本的 .NET Core
• Java：Java 8更新161（8u161）或更高版本
• Python：使用 OpenSSL 1.0.1 或更高版本生成的Python分发版
• Node.js：Node.js 版本 10 或更高版本

操作系统对 TLS 1.2+ 的支持示例

以下作系统包括对 TLS 1.2 或更高版本的集成支持：

• Windows：Windows 8、Windows Server 2012 及更高版本
• Linux：使用 OpenSSL 1.0.1 或更高版本的大多数新式 Linux 分发版

为了避免服务中断，您的资源与之交互的每个远程终结点（包括依赖请求）都需要至少支持之前提到的相同协议版本、密码套件和椭圆曲线中的一个组合。 如果远程终结点不支持所需的 TLS 配置，则需要更新以支持一些已弃用配置之后的新 TLS 配置组合。

受影响的 Application Insights 资源停止引入数据，无法访问所需的应用程序组件。 因此，某些功能停止工作。

本文档中详述的传输层安全性 （TLS） 弃用应仅影响 2025 年 5 月 1 日之后的行为。 有关 CRUD 操作的详细信息，请参阅 Azure 资源管理器 TLS 支持。 此资源提供有关 TLS 支持和弃用时间线的更多详细信息。

有关旧版 TLS 问题的任何常规问题，请参阅解决 TLS 问题。

有关详细信息，请参阅 TLS 支持。

对于当前的监测，请使用 OpenTelemetry API 和特定于语言的日志记录或指标 API。 有关示例，请参阅 “收集自定义遥测”。

对于浏览器自定义事件，请使用 Application Insights JavaScript SDK 或 Click Analytics。 对于服务器端自定义事件，请使用 OpenTelemetry 自定义事件。

ASP.NET Core内置支持用于记录 HTTP 请求和响应信息，包括正文。 这可以公开个人身份信息（PII），并可以显著增加性能和引入成本，因此请在使用之前仔细评估风险。

对于当前的.NET应用程序，请通过 OpenTelemetry 和标准的.NET日志记录配置来收集日志。 使用 Logging:LogLevel 在 appsettings.json 中选择应用程序日志级别，并将 OpenTelemetry 日志导出配置为 Azure Monitor OpenTelemetry 设置的一部分。 请参阅使用 Application Insights 启用 OpenTelemetry和修改遥测。

为应用程序选择一个检测路径。 对于基于代码的当前设置，请使用 Azure Monitor OpenTelemetry。 对于无代码应用服务监视，请使用 无需更改代码的监视方法。 除非您在验证迁移，否则请避免对相同应用程序的重叠监测。

对于新应用程序监控，请使用 Azure Monitor OpenTelemetry 发行版或当前的自动仪器化路径。 请参阅 “使用 Application Insights 启用 OpenTelemetry” 和 “无需更改代码的应用程序监视”。

有关当前 ASP.NET Core 工具化的更多信息，请参阅 在 Application Insights 上启用 OpenTelemetry 。

• Exception rate：“异常率”是系统性能计数器。 CLR 会对所有引发的已处理和未经处理异常进行计数，并将总采样间隔除以间隔长度。 Application Insights SDK 会收集此结果，并将其发送到门户。
• Exceptions：异常指标在图表的采样间隔内统计门户收到的异常遥测信息的数量。 它包括你的检测报告中记录的已处理异常。 它可能不包括每个未经处理的异常。

有关当前指标指南，请参阅 Application Insights 中的指标。

实时指标不显示事件计数器。 使用 Metric Explorer 或 Analytics 来查看遥测数据。

当前，对于 ASP.NET Core，应用服务在无需代码更改的情况下监视，不支持该功能。

有关当前指标指南，请参阅 Application Insights 中的指标。

失败的依赖项调用将 success 字段设置为 false。 依赖项遥测不会为每个失败的依赖项调用自动创建单独的异常项。 Application Insights 遥测数据模型中介绍了依赖项遥测的完整数据模型。

请使用此代码：

dependencies
| extend E2EIngestionLatency = ingestion_time() - timestamp
| extend TimeIngested = ingestion_time()

在Log Analytics查询视图中，timestamp表示启动依赖项遥测操作的时刻，该操作在收到依赖项调用响应后立即发生。 若要计算依赖项调用的发起时间，需要获取 timestamp，然后减去记录的依赖项调用的 duration。

Application Insights 中的依赖项跟踪不包括记录响应体，因为它会为大多数应用程序生成过多的遥测数据量。

有关当前依赖项和自定义范围指南，请参阅 “添加自定义范围”。

可用性测试可在遍布全球的各个接入点上运行。 可运用以下两种解决方案：

• 防火墙门：允许从长且可更改的 Web 测试代理列表中请求自己的服务器。
• 自定义代码：编写自己的代码，以从 Intranet 内部向服务器发送定期请求。 为此，可以运行Visual Studio Web 测试。 针对生成的日志或指标发出内部运行状况信号和警报。

用户代理字符串Mozilla/5.0（兼容;MSIE 9.0;Windows NT 6.1;Trident/5.0;AppInsights）

有关详细信息，请参阅可用性测试。

可用性测试在每个受支持的 Web 测试位置中充当分布式客户端。 每次执行 Web 测试时，可用性测试服务都会尝试联系 Web 测试配置中定义的远程终结点。 它会发送 TLS 客户端 Hello 消息，其中包含当前支持的所有 TLS 配置。 如果远程终结点与可用性测试客户端共享通用 TLS 配置，则 TLS 握手成功。 否则，网络测试会因 TLS 握手失败而失败。

有多种工具可用于测试终结点支持的 TLS 配置。 一种方法是遵循本页面上详述的示例。 如果远程终结点无法通过公共 Internet 访问，则需要确保从有权调用终结点的计算机验证远程终结点上支持的 TLS 配置。

无法用一种异常类型来表示所有受此弃用影响的 TLS 握手失败。 不过，Web 测试开始失败时的最常见异常是 The request was aborted: Couldn't create SSL/TLS secure channel。 还应能够在“TLS 传输”故障排除步骤中看到任何与 TLS 相关的故障，以了解可能会受到影响的 Web 测试结果。

无法查看在 Web 测试执行期间协商的 TLS 配置。 只要远程终结点支持带有可用性测试的常见 TLS 配置，则弃用后不会有任何影响。

本文档中详述的 TLS 弃用应仅影响 2025 年 5 月 1 日之后的可用性测试 Web 测试执行行为。 有关与 CRUD 操作的可用性测试服务交互的详细信息，请参阅 Azure 资源管理器 TLS 支持。 此资源提供有关 TLS 支持和弃用时间线的更多详细信息。

有关旧版 TLS 问题的任何常规问题，请参阅解决 TLS 问题。

有关详细信息，请参阅支持的 TLS 配置。

更改取决于检测路径。 无代码应用服务监视通常使用应用设置和平台配置。 基于代码的监视使用所选语言的 OpenTelemetry 包和启动配置。 有关当前指南，请参阅 在 Azure 应用服务 中启用应用程序监视 和 在 Application Insights 中启用 OpenTelemetry。

Application Insights 为向应用程序发出的请求收集遥测数据。 如果失败发生在 Web 应用 或 Web 服务器中，并且请求未到达用户应用程序，则 Application Insights 没有有关它的遥测数据。

Application Insights 计算的 serverresponsetime 持续时间不一定与 Web 应用 观察到的服务器响应时间匹配。 Application Insights 计算请求到达用户应用程序的持续时间。 如果请求在 Web 服务器中停滞或排队，则等待时间包含在Web 应用指标中，但不包括在 Application Insights 指标中。

详细信息可参阅 在 Azure 应用服务中启用应用程序监视。

我们遵循 Microsoft 风格指南 来编写发布到 Microsoft Learn 平台的产品文档。

一般情况下，在“auto”前缀后面不包含连字符。

有关详细信息，请参阅 什么是 Azure Monitor Application Insights 的自动探测？

新的Azure区域要求使用连接字符串而不是检测密钥。 连接字符串会标识出要与遥测数据相关联的资源。 它还允许您修改资源用于遥测的终结点（endpoint）。 复制连接字符串并将其添加到应用程序的代码或环境变量。

建议使用连接字符串，而不是工具键。

在所有系统未自动提供 APPLICATIONINSIGHTS_CONNECTION_STRING 的场景中，手动设置它。 这些场景包括但不限于：本地开发和使用 ASP.NET Core 集成的 .NET 独立函数。 在这些情况下，环境变量可确保 OpenTelemetry 管道可以将遥测数据发送到 Application Insights。 有关使用环境变量配置连接字符串的详细信息，请参阅 在 Application Insights 中配置 OpenTelemetry。

不严格。 一个 Application Insights 资源可以从 Application Insights JavaScript SDK 接收浏览器遥测数据，并且当本地身份验证保持启用以用于浏览器数据引入时，可以通过经过身份验证的方式接收服务器端遥测数据。 无需因为您的应用程序还会收集浏览器遥测，就避免使用 OpenTelemetry 或 OTLP。

主要例外是在 Application Insights 资源上禁用本地身份验证，要求对所有引入进行Microsoft Entra身份验证。 在该配置中，JavaScript SDK 无法直接从浏览器进行身份验证，浏览器遥测数据传输可能会中断。 对于该方案中的浏览器遥测，请使用启用了本地身份验证的单独浏览器遥测资源，或通过经过身份验证的代理模式路由浏览器遥测。 有关详细信息，请参阅 使用连接字符串进行身份验证的浏览器遥测。

即使单个资源在技术上正常工作，也应考虑将单独的 Application Insights 资源用于浏览器/客户端遥测，作为风险隔离最佳做法。 浏览器检测在不受信任的客户端环境中运行，因此其连接字符串对用户是可见的，不能被视为机密。 暴露的连接字符串可能会被用于将伪造、不相关或大容量的遥测信息发送到关联的资源，从而污染仪表板、警报、故障排除查询，并增加摄取成本。

单独的浏览器遥测资源可帮助你：

• 在不中断服务器端遥测的情况下，轮换或替换浏览器端连接字符串。
• 包含特定于浏览器的资源的欺骗、垃圾邮件或垃圾遥测。
• 保护用于诊断、警报和操作分析的服务器端遥测的质量。
• 根据需要应用不同的访问控制、所有权或治理设置。

将这些优势与多个资源带来的额外管理开销相平衡，这些开销包括增加的连接字符串、RBAC 分配、配置，以及跨资源的调查分析。 用户有权访问相关的资源时，端到端的关联仍然可以在多个 Application Insights 资源中运作。 有关详细信息，请参阅 应用程序映射 和 事务诊断。

专用链接和引入身份验证是单独的控制措施。 专用链接控制对Azure Monitor资源的网络访问；Microsoft Entra身份验证则控制是否已通过标识授权遥测数据的接收。 不要将专用链接用作引入身份验证的替代方法，不要将资源分离视为经过身份验证的服务器端引入的要求。

若要满足区域数据符合性要求，请使用区域 Application Insights 终结点而不是全局终结点。 全局终结点不保证数据保留在特定区域中。 区域终结点有助于确保来自受管制区域中的用户的遥测仅发送到这些区域中的数据中心。

若要为全球web应用程序配置地区合规性，请执行以下步骤：

• 为每个区域创建一个符合性要求严格的 Application Insights 资源，例如中国北部 2 或中国东部 2。
• 为所有其他区域中的用户创建另一个 Application Insights 资源。
• 将应用程序配置为根据每个用户的区域将遥测数据发送到相应的 Application Insights 资源。 使用 IP 地址、帐户元数据或位置设置等信号确定区域。
• 如果需要跨区域提供统一的查询体验，请将所有 Application Insights 资源连接到Log Analytics工作区。

例如：

• 使用区域 A 的连接字符串将数据从区域 A 的用户发送到区域 A 的 Application Insights 资源。
• 使用区域 B 的连接字符串将区域 B 用户的数据发送到区域 B 的 Application Insights 资源。
• 使用不同的连接字符串将所有其他用户数据发送到通用 Application Insights 资源。

下图显示了全局 Web 应用程序的示例设置：

有关详细信息，请参阅连接字符串。

在区域之间传输现有的 Application Insights 资源不受支持，并且你无法将历史数据迁移到新区域。 解决方法包括：

• 在所需区域中创建新的 Application Insights 资源。
• 在新资源中重新创建原始资源中的任何唯一自定义项。
• 使用新区域资源的连接字符串更新您的应用程序。
• 进行测试以确保新的 Application Insights 资源一切都按预期运行。
• 决定保留还是删除原始 Application Insights 资源。 删除经典资源意味着丢失所有历史数据。 如果资源基于工作区，则数据将保留在Log Analytics中，允许访问历史数据，直到保留期到期。

通常需要在新区域中为资源手动重新创建或更新的唯一自定义项包括但不限于：

• 重新创建自定义仪表板和工作簿。
• 重新创建或更新任何自定义日志/指标警报的范围。
• 重新创建可用性警报。
• 重新创建自定义Azure用户访问新资源所需的基于角色的访问控制设置。
• 复制那些涉及引入采样、数据保留、每日上限和自定义指标启用的设置。 可通过“使用情况和预估成本”窗格控制这些设置。
• 依赖 API 密钥（例如版本注释和实时指标安全控制通道）的任何集成。 你需要生成新的 API 密钥并更新关联的集成。
• 必须重新配置经典资源中的连续导出。
• 必须重新配置基于工作区资源中的诊断设置。

不建议使用此方法来填充 API 版本。 最新版本可以支持预览发布，其可能包含重大变更。 即使使用较新的非预览版本，API 版本也并不总是与现有模板向后兼容。 在某些情况下，API 版本可能并不适用于所有订阅。

有关详细信息，请参阅创建和配置 Application Insights 资源。

若要报告数据模型或架构问题和建议，请使用 GitHub 存储库。

PageView 遥测包括 URL，你可以使用 Kusto 中的正则表达式函数分析 UTM 参数。

如果用户或企业禁止在浏览器设置中发送用户代理，则此数据偶尔可能会缺失或不准确。 UA解析器正则表达式可能未包含所有设备信息。 或者 Application Insights 可能未采用最新更新。

如果使用字符串值，可能会发生这种情况。 自定义度量只能使用数值。

有关详细信息，请参阅 Application Insights 遥测数据模型。

OpenTelemetry 日志记录存储在 Application Insights 日志中的 traces 表中。 若要在 Azure 门户中查看它们，请打开 Application Insights 资源，选择 Logs，然后查询 traces 表。

示例查询： traces | where message contains "YourSearchTerm".

对于当前的.NET应用程序，请通过 OpenTelemetry 和标准的.NET日志记录配置来收集日志。 使用 Logging:LogLevel 在 appsettings.json 中选择应用程序日志级别，并将 OpenTelemetry 日志导出配置为 Azure Monitor OpenTelemetry 设置的一部分。 请参阅使用 Application Insights 启用 OpenTelemetry和修改遥测。

在应用程序遥测配置完成之前发出日志时，其扩充属性可能比应用程序生命周期稍后发出的日志少。

对于当前使用的检测工具，请使用 OpenTelemetry API 或 Azure Monitor OpenTelemetry 发行版平台发送自定义遥测。 有关示例，请参阅 “收集自定义遥测”。

有关当前 .NET 监测，请参阅 Application Insights 的 Enable OpenTelemetry。

Java 分析器使用 Java Flight Recorder（JFR）通过使用自定义配置对应用程序进行性能分析。

Java Flight Recorder （JFR） 是一种收集正在运行Java应用程序的分析数据的工具。 JFR 集成到Java虚拟机（JVM）中，用于排查性能问题。 详细了解 Java SE JFR Runtime。

Java 性能分析是 Application Insights 的免费功能。 Azure Monitor Application Insights 定价基于引入成本。

JFR 收集的探查数据包括：方法和执行探查数据、垃圾收集数据和锁定探查。

可以使用首选工具查看和分析 JFR 录制，例如Java任务控制（JMC）。

即将推出的“性能诊断和建议”是一项新功能，将作为 Application Insights Java Diagnostics 提供。 可以在注册后预览此功能。 可以使用Java任务控制（JMC）查看 JFR 录制。

按需分析是实时由用户触发的分析设置，而自动分析是通过预先配置的触发器进行的。

对于按需分析选项，请使用立即分析。 Profile Now 会立即分析附加到 Application Insights 实例的所有代理。

资源达到阈值时，会触发自动化分析。

Application Insights Java 代理当前支持监视 CPU 和内存消耗。 CPU 阈值配置为计算机上所有可用核心的百分比。 内存是当前“老年代内存区域”(OldGen) 对该区域的大小上限的占用率。

查看 先决条件。

是的，可以使用 JFR 来探查运行微服务的 JVM。

有关详细信息，请参阅 Azure Monitor Application Insights Profiler for Java。

否，采样替代现已正式发布（GA），可用于自动检测和手动检测。

如果使用自动检测，请更新 Azure 门户中的 applicationinsights.json 文件。

对于自动检测，无需手动上传代理。 但是，对于手动检测，仍需要在部署包中包含 Application Insights 代理 JAR 文件和配置文件。

本地开发是指正在生成或测试应用的环境，例如开发人员的计算机。 应用程序服务器是指在Azure 应用服务环境中运行应用程序的 Web 服务器，例如 Tomcat 11。 使用手动检测时，必须确保代理 JAR 文件正确放置在应用程序服务器上。

对于自动检测，你可以通过 Azure 门户额外配置采样设置。 如果使用手动检测，则应将 Application Insights 代理 JAR 放在相应的目录中，并将 applicationinsights.json 文件与所需的采样设置一起包含在内。

有关详细信息，请参阅 采样替代 - Azure Monitor Application Insights for Java。

OpenTelemetry 处理器可以处理流经 OpenTelemetry 管道的遥测数据。 除非显式收集这些日志或文件，否则 OpenTelemetry 处理器不会处理在管道外部写入的文件。

有关详细信息，请参阅 Telemetry 处理器（预览版） - Azure Monitor Application Insights for Java。

• JavaScript SDK 在 Web 客户端上设置了用于识别返回用户的用户 cookie，以及用于对活动进行分组的会话 cookie。
• 如果没有客户端脚本，可以在服务器上设置 Cookie。
• 如果某个真实的用户在不同的浏览器中使用站点，或者使用私密/隐身浏览，或使用不同的计算机，则会进行多次计数。
• 若要跨计算机和浏览器标识登录用户，请使用 JavaScript SDK 经过身份验证的用户上下文 或设置 OpenTelemetry enduser.id 属性。

Application Insights JavaScript SDK 对网站的性能影响极小。 该 SDK 经过压缩后只有 36 KB，只需大约 15 毫秒即可完成初始化，在网站中的加载时长可忽略不计。 使用该 SDK 时，系统会快速加载库的极少组件，并在后台下载完整脚本。

此外，在从 CDN 下载脚本期间，页面的所有跟踪都将进行排队，因此你不会在整个页面生命周期中丢失任何遥测数据。 此设置过程可为页面提供一个无缝分析系统，而用户察觉不到该系统。

如需查看可运行的示例，请参阅 Application Insights JavaScript SDK 示例。

我们需要采取必要的措施来确保此 SDK 继续“工作”，并且在由旧版浏览器加载时不会中断 JavaScript 执行。 不支持早期的浏览器是理想做法，但有众多的大客户无法控制其用户选择使用的浏览器。

这样说并不意味着我们仅支持最少量的常用功能集。 我们需要保持 ES3 代码的兼容性。 新功能需要以不会中断 ES3 JavaScript 分析的方式添加，且需作为可选功。

有关 Internet Explorer 8 支持的完整详细信息，请参阅GitHub。

是的，Application Insights JavaScript SDK 开放源代码。 若要查看源代码或参与项目，请参阅官方GitHub存储库。

有关详细信息，请参阅 Enable Azure Monitor Application Insights Real User Monitoring。

服务器端需要能够接受带有这些标头的连接。 根据服务器端的 Access-Control-Allow-Headers 配置，通常需要手动添加 Request-Id、Request-Context 和 traceparent（W3C 分布式标头）来扩展服务器端列表。

Access-Control-Allow-Headers：Request-Id、traceparent、Request-Context、<your header>

可以在配置中禁用分布式跟踪。

否。 “502 错误的网关”和“503 服务不可用”错误并不总是由 Application Insights 捕获。 如果仅将客户端 JavaScript 用于监视，则这是预期的行为，因为错误响应会在包含 HTML 标头且会呈现监视性的 JavaScript 代码片段的页面之前返回。

如果从启用了服务器端监视的服务器发送了 502 或 503 响应，则 Application Insights SDK 会收集这些错误。

即使在应用程序的 Web 服务器上启用了服务器端监视，有时 Application Insights 也不会捕获 502 或 503 错误。 许多新式 Web 服务器不允许客户端直接通信。 相反，它们使用反向代理之类的解决方案在客户端和前端 Web 服务器之间来回传递信息。

在这种情况下，由于反向代理层的一个问题，502 或 503 响应可能会返回给客户端，因此不会被 Application Insights 自动捕获。 为了帮助检测此层的问题，可能需要将日志从反向代理转发到Log Analytics并创建自定义规则来检查 502 或 503 响应。 若要详细了解 502 和 503 错误的常见原因，请参阅 在 Azure 应用服务中排查“502 错误网关”和“503 服务不可用的 HTTP 错误。

有关详细信息，请参阅 Application Insights JavaScript SDK 配置。

浏览器在请求的 HTTP 标头中传递用户代理字符串。 Application Insights 引入服务使用 UA Parser 来生成你在数据表和体验中看到的字段。 因此，Application Insights 用户无法更改这些字段。

如果用户或企业禁止在浏览器设置中发送用户代理，则此数据偶尔可能会缺失或不准确。 UA解析器正则表达式可能未包含所有设备信息。 或者 Application Insights 可能未采用最新更新。

对于 Application Insights，请参阅为 Application Insights JavaScript SDK 启用框架扩展。

否。 现有的 ARM 模板和 API 调用将继续工作。 当您尝试创建经典类型的资源时，系统会改为创建一个包含托管工作区的工作区型资源。

否。 无法获得有关单个资源迁移的通知。 若要控制资源的迁移时间和方式，请使用 手动迁移。

单个迁移通常在不到两分钟内完成。 全覆盖将在几周内在所有地区进行。

迁移后，资源会链接到“概述”页上Log Analytics工作区。 将删除经典停用通知，停用工作簿不再列出资源。

成本通常保持不变。 基于工作区的 Application Insights 支持节省成本的功能，建议查看 定价计划。

如果使用的是旧版计费模型，请查看 定价文档 了解详细信息。

否。 所有警报、仪表板和可用性测试保持不变，在迁移后继续正常运行。

有关详细信息，请参阅 Application Insights 中的托管工作区。

有关当前检测，请查看 分布式跟踪和遥测关联。 有关 JavaScript 浏览器遥测，请参阅 JavaScript SDK 配置。

若要配置 Application Insights 将使用的所需日志级别，请使用 APPLICATIONINSIGHTS_INSTRUMENTATION_LOGGING_LEVEL 环境变量。 支持的值为 NONE、ERROR、WARN、INFO、DEBUG、VERBOSE 和 ALL。 有关详细信息，请参阅 ApplicationInsights-node.js。

有关当前 Node.js 检测，请参阅 使用 Application Insights 启用 OpenTelemetry。

SDK 版本和名称的列表托管在GitHub上。 有关详细信息，请参阅 SDK 版本。

有关详细信息，请参阅在 Application Insights 中使用 OpenTelemetry 收集遥测。

请参阅 从 Application Insights SDK 迁移到 Azure Monitor OpenTelemetry。 在该页面上保留关于迁移的特定指南，这样，当前设置文章可以继续展示推荐的 OpenTelemetry 路径。

使用 OpenTelemetry API 和各语言特定的日志或指标 API。 有关示例，请参阅 “收集自定义遥测”。

Application Insights 自定义采样器在跨度创建之后而不是之前做出采样决策，因此不遵循传统的基于头部的方法。 它会改为在跨度生成结束时（在跨度完成之后，但在导出之前）应用采样决策。

尽管此行为在某些方面类似于基于尾部的采样，但采样器不会等到从同一跟踪收集多个跨度之后再做出决策。 而是使用跟踪 ID 的哈希来帮助确保跟踪完整性。

此方法平衡了跟踪的完整性和效率，并避免了与基于尾部的完整采样关联的较高成本。

若要根据整个跟踪的结果做出采样决策（例如，确定跟踪内的任何跨度是否失败），需要在下游代理或收集器中进行基于尾部的完整采样。 此功能目前不受支持，但可以通过 反馈中心将其请求为新功能。

否，采样器对跟踪中的所有遥测类型应用固定速率。 请求、依赖项和其他跨度遵循相同的采样百分比。 若要按遥测类型应用不同的速率，请考虑使用 OpenTelemetry 范围处理器或（引入时间转换）[app-insights-overview.md#telemetry-routing]。

默认情况下，Application Insights 自定义采样器使用 W3C 跟踪上下文标准传播采样决策。 此标准允许采样决策在服务之间流动。 但是，由于采样器在跨度生成结束时（在调用下游服务后）做出采样决策，传播会传递不完整的采样信息。 此限制符合 W3C 跟踪上下文规范，但下游服务无法可靠地使用此传播的采样决策。

否，即使上游服务使用相同的采样算法，Application Insights 自定义采样器也始终做出独立的采样决策。 来自上游服务的采样决策（包括那些使用 W3C 跟踪上下文标头的决策）不会影响下游服务的决策。 但是，它基于跟踪 ID 的哈希值进行采样，以确保跟踪的完整性。 为了提高一致性并降低跟踪中断的可能性，请将系统中的所有组件配置为使用相同的采样器和采样率。

有几种原因导致跟踪可能不完整：

• 分布式系统中的不同节点使用不同的采样方法，这些方法无法协调决策。 例如，一个节点应用 OpenTelemetry 头部采样，另一个节点通过 Azure Monitor 自定义采样器进行采样。
• 不同的节点设置为不同的采样率，即使它们都使用相同的采样方法也是如此。
• 可以在服务端管道中设置筛选、采样或速率上限，此配置会随机采样范围，而无需考虑跟踪完整性。

如果一个组件应用基于头部的采样而不传播采样决策（通过 W3C 跟踪上下文标头），则下游服务会独立地对跟踪进行采样，这可能会导致丢弃跨度。 因此，在 Application Insights 中查看时，跟踪的某些部分并不总是可用的。

数据摄入采样仅会丢弃到达服务的数据，因此无法影响或替代 Application Insights 自定义采样器的决策。 如果两者都已启用，则有效速率为乘法。 例如，SDK 速率为 20%，引入率为 50%， 导致大约 10% 的数据被存储。 Microsoft建议在源头处使用 Azure Monitor OpenTelemetry 采样器进行采样，以保持追踪完好无损且可预测，仅在必要时使用引入采样作为后备。

有关详细信息，请参阅 Azure Monitor Application Insights 中的 Sampling with OpenTelemetry。

它是可观测性的开源标准。 有关详细信息，请参阅 OpenTelemetry。

Microsoft投资 OpenTelemetry 的原因如下：

• OpenTelemetry 与供应商无关，并提供适用于多种语言的一致 API/SDK。
• 随着时间的推移，我们相信 OpenTelemetry 将使 Azure Monitor 客户能够观察使用我们支持的语言之外的其他语言编写的应用程序。
• 它通过丰富的检测库扩展了你可以收集的数据类型。
• OpenTelemetry 软件开发工具包（SDK）旨在大规模实现高性能、供应商中立的遥测数据。
• OpenTelemetry 符合 Microsoft embrace 开放源代码 的策略。

请参阅 OpenTelemetry 状态。

可以将它视为一个精简包装器，它将所有 OpenTelemetry 组件捆绑在一起，以便在Azure获得一流的体验。 在 OpenTelemetry 中，此包装器也称为分发。

相比社区提供的本机 OpenTelemetry，使用 Azure Monitor OpenTelemetry 发行版有几个优点：

• 减少启用工作量
• Microsoft支持
• 引入特定于Azure的功能，例如：
  • 与经典 Application Insights SDK 兼容的采样
  • 脱机存储和自动重试
  • Application Insights 标准指标
  • 检测资源元数据，以便在各种 Azure 环境中自动填充云角色名称和云角色实例。
  • 实时指标

本着 OpenTelemetry 的精神，我们设计的发行版具有开放性和可扩展性。 例如，你可以添加：

• 一个 OpenTelemetry 协议 (OTLP) 导出程序，同时将数据发送到第二个目标。
• 发行版中未包含的其他工具库

由于 Distro 提供 OpenTelemetry 分发，因此 Distro 支持 OpenTelemetry 所支持的任何功能。 例如，你可以添加更多遥测处理器、导出程序或检测库（如果受 OpenTelemetry 支持）。

对于没有受支持的独立 OpenTelemetry 导出程序的语言，Azure Monitor OpenTelemetry 发行版是当前唯一支持将 OpenTelemetry 与 Azure Monitor 配合使用的方法。 对于具有受支持的独立 OpenTelemetry 导出程序的语言，可以选择使用 Azure Monitor OpenTelemetry 发行版或适当的独立 OpenTelemetry 导出程序，具体取决于遥测方案。 有关详细信息，请参阅 我应何时使用 Azure Monitor OpenTelemetry 导出程序。

是的。 建议对新项目使用 Azure Monitor OpenTelemetry 发行版。

如果要将现有的 .NET 或 Node.js 应用程序从旧版 Application Insights SDK 迁移，请参阅 从 Application Insights SDK 迁移到 Azure Monitor OpenTelemetry。

对于 ASP.NET Core、Java、Node.js和 Python，建议使用 Azure Monitor OpenTelemetry 发行版。 只需一行代码即可开始。

对于所有其他.NET方案，包括经典 ASP.NET、控制台应用、Windows 窗体（WinForms），我们建议使用 .NET Azure Monitor OpenTelemetry 导出程序：Azure.Monitor.OpenTelemetry.Exporter。

对于需要高级配置的更复杂的Python遥测方案，建议使用 Python Azure Monitor OpenTelemetry 导出程序。

Azure Monitor OpenTelemetry 发行版支持当前推荐的 Application Insights 检测路径。

有关代码分析体验的最新详细信息，请参阅 .NET Profiler 和 Snapshot Debugger。

是的，但我们不建议使用它，Azure不支持它。 OpenTelemetry JavaScript 针对 Node.js 进行了深度优化。 相反，我们建议使用 Application Insights JavaScript SDK。

OpenTelemetry Web SDK 没有确定的可用性时间线。 我们可能还需要几年的时间，才能开发出可以替代 Application Insights JavaScript SDK 的浏览器 SDK。

OpenTelemetry Web 沙盒 是一个分支，旨在使 OpenTelemetry 在浏览器中运行。 目前无法将遥测数据发送到 Application Insights。 SDK 不定义常规客户端事件。

发行版允许你将内容同时导出到 OTLP 终结点以及 Azure Monitor，但这种做法并不是我们计划测试或支持的。

但我们不建议这样做。 请参阅 Microsoft Azure 预览版的补充使用条款。

一些客户使用 OpenTelemetry Collector 作为代理替代方法，尽管Microsoft尚未正式支持基于代理的应用程序监视方法。 与此同时，开源社区贡献了一款OpenTelemetry Collector Azure Monitor Exporter，一些客户使用它将数据发送到 Azure Monitor Application Insights。 不受微软支持。

你可能正在尝试可视化原始文本日志而非 OpenTelemetry 跟踪。

在 Application Insights 中，“跟踪”表存储的是用于诊断目的的原始文本日志。 这些日志用于帮助识别和关联与用户请求、其他事件和异常报告关联的跟踪。 不过，在 Grafana 等可视化工具中，“Traces”表不直接用于端到端事务视图（瀑布图）。

随着云原生实践的日益普及，遥测数据收集和术语也在不断演变。 OpenTelemetry 已成为收集和检测遥测数据的标准。 在这种背景下，“痕迹”一词有了新的含义。 在 OpenTelemetry 中，“Traces”不是原始日志，而是一种更丰富、结构化的遥测数据形式，其中包含表示各个工作单元的跨度。 这些范围对于构造详细事务视图至关重要，让你可以更好地监视和诊断云原生应用程序。

若要检测 Blazor 应用，请先标识托管模型。 Blazor Server 支持基于 OpenTelemetry 的完整检测。 Blazor WebAssembly 在浏览器中运行，并支持通过 JavaScript 进行有限的检测。

否，仪表板中显示的数据限制为 30 天。

移动或重命名 Application Insights 实例时，可能会出现“找不到资源”错误。

若要解决此问题，请删除默认仪表板，然后再次选择“应用程序仪表板”以重新创建新仪表板。

有关详细信息，请参阅 Application Insights 概览仪表板。

OpenTelemetry 导出器和 SDK 通常使用尽力交付。 如果应用程序崩溃，进程在导出挂起的遥测数据之前退出，存储不可用，或者网络和服务中断持续超过重试限制，则遥测仍可能会丢失。 有关当前的 OpenTelemetry 行为，请参阅 脱机存储和自动重试。

一些当前的导出工具和 SDK 可以在网络问题或流量控制期间创建临时本地存储。 Application Insights 不会加密本地临时存储，因此保护配置的任何目录。 有关当前的 OpenTelemetry 行为，请参阅 脱机存储和自动重试。

有关当前的 OpenTelemetry 重试和存储行为，请参阅 OpenTelemetry 配置。

请参阅限制摘要。

我们不会自动记录 POST 数据。 如果需要捕获请求正文详细信息，并避免收集敏感数据，请仔细使用应用程序日志记录。

Azure Functions不记录 URL 查询字符串。

有关详细信息，请参阅 搜索和诊断。

可能的原因：

• 是否使用 Application Insights 检测了其他组件？
• 是否使用了最新的稳定 Application Insights SDK？
• 如果这些组件是单独的 Application Insights 资源，验证你是否具有访问权限。 如果确实具有访问权限，并且使用了最新的 Application Insights SDK 来检测组件，请通过右上角的反馈通道告知我们。

当前，出站依赖项调用与入站请求分开显示。 通常情况下，这两种调用大致相同，但持续时间值因网络往返而不同。 可通过前导图标和样式不同的持续时间条来区分它们。 这份数据演示文稿是否包含令人困惑的内容？ 欢迎提供反馈！

在事务图中针对时钟偏差调整了时间线。 可以在详细信息窗格中或使用Log Analytics查看确切的时间戳。

此行为是设计造成的。 所有组件中的所有相关项都已在左侧顶部和底部部分中提供。 在新的体验中，有两个左侧没有覆盖的相关项目：事件发生前后五分钟内的所有遥测数据以及用户活动时间线。

事务诊断体验显示共享操作 ID 的单个操作中的所有遥测数据。 默认情况下，Application Insights SDK for JavaScript 为每个唯一的页面视图创建一个新操作。 在单页应用程序 (SPA) 中，将仅生成一个页面视图事件，并对生成的所有遥测数据使用单个操作 ID。 这会导致许多事件与相同操作相关联。

在这些情况下，可以使用自动路由跟踪来自动创建新操作，以便在 SPA 中进行导航。 必须打开 enableAutoRouteTracking，以便在每次更新 URL 路由（逻辑页面视图出现）时生成页面视图。 如果要手动刷新操作 ID，请调用 appInsights.properties.context.telemetryTrace.traceID = Microsoft.ApplicationInsights.Telemetry.Util.generateW3CId()。 手动触发 PageView 事件还将重置操作 ID。

甘特图中未说明的时间是跟踪的依赖项未涵盖的时间。 此问题可能是由于外部调用未进行自动或手动检测而导致的。 出现这种情况也可能是因为所花费的时间是在处理过程中，而非由于外部调用。

如果所有调用都进行了检测，那么处理过程可能是耗时的根本原因。 用于诊断进程的有用工具是 .NET Profiler。

此错误表示浏览器无法调用所需的 API 或 API 返回了失败响应。 若要解决此问题，请打开浏览器 InPrivate 窗口并禁用正在运行的任何浏览器扩展，然后确定是否仍可以重现门户行为。 如果门户错误仍然发生，请尝试使用其他浏览器或其他计算机进行测试，从 API 调用失败的客户端计算机调查 DNS 或其他与网络相关的问题。 如果门户错误仍然存在且需要进一步调查，请在重现意外门户行为时收集浏览器网络跟踪，然后从 Azure 门户打开支持请求。

有关详细信息，请参阅 使用 Application Insights 调查故障、性能和事务。

可视化上的初始事件仅表示用户在会话期间首次发送该页面视图或自定义事件。 如果用户可以在会话中多次发送初始事件，则“步骤 1”列仅显示用户在初始事件的第一个实例（而不是所有实例）之后的行为。

使用“编辑”菜单上的“拆分依据”选项：

1. 在“事件”菜单上选择要细分的事件。

2. 在“维度”菜单上选择一个维度。 例如，如果已有一个名为“已单击按钮”的事件，请尝试使用一个名为“按钮名称”的自定义属性。

队列与筛选器有所不同。 假设你为英国的用户创建了一个队列（类似于上述示例中的定义），并将结果与设置筛选器 Country or region = United Kingdom 进行比较：

• 队列版本将显示在当前时间范围内从英国发送了一个或多个事件的用户的所有事件。 如果按国家或地区拆分，可能会看到许多国家和地区。

• 筛选器版本只显示来自英国的事件。 如果按国家或地区拆分，你只会看到“英国”。

可以选择“日期粒度”筛选器来更改粒度。 筛选器在所有维度选项卡中都可用。

如果视觉图表无法回答你的所有问题，你可以深入挖掘支持 HEART 工作簿的数据。 若要执行此任务，请在 Application Insights 的 “监视 ”部分下，选择“ 日志”并查询 customEvents 表。 某些点击分析的属性包含在 customDimensions 字段中。

下面显示了一个示例查询：

customEvents
| where isnotnull(customDimensions.actionType)
| extend parentid=tostring(customDimensions.parenId),
pagename=tostring(customDimensions.pageName),
actiontype=tostring(customDimensions.actionType)
| project actiontype,parentid,pagename,
user_AuthenticatedId,user_Id,session_Id,itemType,timestamp

若要详细了解 Azure Monitor 中的日志，请参阅 Azure Monitor 日志概述。

是的。 若要了解如何编辑工作簿模板，请参阅 Azure 工作簿模板。

有关详细信息，请参阅 Application Insights 使用情况分析。

对于当前工作器服务应用程序，请使用 Azure Monitor OpenTelemetry 导出程序或发行版本。 请参阅 如何使用 Application Insights 启用 OpenTelemetry。

对于当前的监测，请使用 OpenTelemetry API 和特定于语言的日志记录或指标 API。 有关示例，请参阅 “收集自定义遥测”。

对于浏览器自定义事件，请使用 Application Insights JavaScript SDK 或 Click Analytics。 对于服务器端自定义事件，请使用 OpenTelemetry 自定义事件。

对于新应用程序监控，请使用 Azure Monitor OpenTelemetry 发行版或当前的自动仪器化路径。 请参阅 “使用 Application Insights 启用 OpenTelemetry” 和 “无需更改代码的应用程序监视”。

功能支持取决于语言、托管环境和检测路径。 要获得当前支持，请从 启用 OpenTelemetry 与 Application Insights 和相关语言特定配置文章开始。

有关当前工作服务的仪表化，请参阅 使用 Application Insights 启用 OpenTelemetry。