Application Insights 常见问题解答 - 常见问题解答

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

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

从服务器 Web 应用：

• HTTP 请求。
• 依赖项。 对 SQL 数据库的调用、对外部服务的 HTTP 调用、Azure Cosmos DB、Azure 表存储、Azure Blob 存储和 Azure 队列存储。
• 异常和堆栈跟踪。
• 性能计数器：使用以下功能时可以使用性能计数器：
  • Azure Monitor Application Insights 代理
  • 适用于虚拟机或虚拟机规模集的 Azure 监视
  • Application Insights collectd 写入器。
• 自定义编码的事件和指标。
• 跟踪日志（如果配置相应的收集器）。

从客户端网页：

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

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

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

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

• 会话信息

  注释

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

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

从其他源（如果配置）：

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

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

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

• 创建并更新 Application Insights 资源。
• 设置定价计划。
• 获取仪器密钥。
• 添加指标警报。
• 添加可用性测试。

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

使用 REST API 运行 Log Analytics 查询。

建议使用 Azure Monitor OpenTelemetry 发行版。

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

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

收集

Application Insights 收集有关应用的遥测数据，包括 Web 服务器遥测数据、网页遥测数据和性能计数器。 此数据可用于监视应用的性能、运行状况和使用情况。 创建新的 Application Insights 资源时，可以选择存储位置。

保留和存储

数据发送到 Application Insights Log Analytics 工作区。 可以选择原始数据的保持期（从 30 天到 730 天）。 聚合数据保留 90 天，调试快照保留 15 天。

隐私

Application Insights 默认不处理敏感数据。 建议你不将敏感数据以纯文本形式放在 URL 中，并确保自定义代码不收集个人或其他敏感详细信息。 在开发和测试过程中，检查 IDE 和浏览器调试输出窗口中的已发送数据。

有关已存档信息，请参阅 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 简介。

如果在应用程序关闭之前未刷新，则这两个 TelemetryChannel 都将丢失缓冲的遥测数据。

若要避免数据丢失，请在应用程序关闭时刷新 TelemetryClient。

有关详细信息，请参阅刷新数据。

没有。 不需要将它们包装在 try-catch 子句中。 如果 SDK 遇到问题，它会在调试控制台输出中记录消息，如果消息已传入，可在诊断搜索中查看。

是的，数据访问 API。 提取数据的其他方法包括工作区资源上的Power BI。

Application Insights SDK 与自动检测不兼容。 如果启用了自动仪表化，将忽略对 Track() 和其他自定义事件及指标 API 的调用。

在 Azure 门户的“应用服务”页的“Application Insights”选项卡上禁用自动化检测，或将 ApplicationInsightsAgent_EXTENSION_VERSION 设置为 disabled。

采样减少了从应用发送到门户的遥测项（例如请求和自定义事件）数量。 在搜索中，你可以看到接收的项目数。 在显示事件计数的度量图表中，您可以看到发生的原始事件数量。

传输的每个项都携带一个 itemCount 属性，此属性显示该项表示的原始事件数量。 若要观察操作中的采样，可以在 Log Analytics 中运行此查询：

requests | summarize original_events = sum(itemCount), transmitted_events = count()

Azure 警报仅基于指标。 创建一个每当事件发生时都跨越值阈值的自定义指标。 然后在该指标上设置警报。 每次指标在任一方向超过阈值时，你都将收到通知。 无论初始值高低，都不会收到通知，直到首次越过。 通常存在几分钟的延迟。

有关详细信息，请参阅 用于自定义事件和指标的 Application Insights API。

是的。 可以通过多种方式下载 Application Insights 代理：

• 如果计算机可以访问 Internet，则可以使用 -Proxy 参数登录到 PowerShell 库。
• 还可以手动下载此模块，并将其安装到计算机上或直接使用它。

上述每个选项都在详细说明中进行了说明。

是的。 在 Application Insights Agent 2.0.0 及更高版本中，支持在 IIS 中托管的 ASP.NET Core 应用程序。

• 可以使用 Get-ApplicationInsightsMonitoringStatus cmdlet 来验证启用是否成功。

• 使用实时指标来快速确定应用是否正在发送遥测数据。

• 还可以使用 Log Analytics 列出当前正在发送遥测数据的所有云角色：

  union * | summarize count() by cloud_RoleName, cloud_RoleInstance
  

若要实现代理直通，请配置计算机级代理或应用程序级代理。 请参阅 DefaultProxy。

示例 Web.config：

<system.net>
    <defaultProxy>
    <proxy proxyaddress="http://xx.xx.xx.xx:yyyy" bypassonlocal="true"/>
    </defaultProxy>
</system.net>

有关详细信息，请参阅 为本地服务器部署 Application Insights 代理。

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 支持。

要删除 Application Insights，需要从应用程序中的 API 删除 NuGet 包和引用。 可以使用 Visual Studio 中的 NuGet 包管理器卸载 NuGet 包。

1. 如果启用了跟踪集合，请先使用 NuGet 包管理器卸载 Microsoft.ApplicationInsights.TraceListener 包，但不删除任何依赖项。
2. 卸载 Microsoft.ApplicationInsights.Web 包，并使用nuGet 包管理器选项控件中的 NuGet 包管理器及其卸载选项删除其依赖项。
3. 若要完全删除 Application Insights，请检查并手动删除添加的代码或文件以及在项目中添加的所有 API 调用。 有关详细信息，请参阅添加 Application Insights SDK 时会自动创建哪些内容？。

将 Application Insights 添加到项目时，它会自动创建文件并在某些文件中添加代码。 仅仅卸载 NuGet 包，并不总是会清除掉文件和代码。 若要完全删除 Application Insights，应检查并手动删除添加的代码或文件以及在项目中添加的所有 API 调用。

将 Application Insights 遥测添加到 Visual Studio ASP.NET 项目时，它会添加以下文件：

• ApplicationInsights.config
• AiHandleErrorAttribute.cs

将自动添加以下代码片段：

• [项目名称].csproj

    <ApplicationInsightsResourceId>/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/Default-ApplicationInsights-EastUS/providers/microsoft.insights/components/WebApplication4</ApplicationInsightsResourceId>
  

• Packages.config

  <packages>
  ...
  
     <package id="Microsoft.ApplicationInsights" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.Agent.Intercept" version="2.4.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.DependencyCollector" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.PerfCounterCollector" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.Web" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.WindowsServer" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel" version="2.12.0" targetFramework="net472" />
  
     <package id="Microsoft.AspNet.TelemetryCorrelation" version="1.0.7" targetFramework="net472" />
  
     <package id="System.Buffers" version="4.4.0" targetFramework="net472" />
     <package id="System.Diagnostics.DiagnosticSource" version="4.6.0" targetFramework="net472" />
     <package id="System.Memory" version="4.5.3" targetFramework="net472" />
     <package id="System.Numerics.Vectors" version="4.4.0" targetFramework="net472" />
     <package id="System.Runtime.CompilerServices.Unsafe" version="4.5.2" targetFramework="net472" />
  ...
  </packages>
  

• Layout.cshtml

  如果你的项目包含 Layout.cshtml 文件，则会添加以下代码。

  <head>
  ...
       <script type = 'text/javascript' >
           var appInsights=window.appInsights||function(config)
           {
               function r(config){ t[config] = function(){ var i = arguments; t.queue.push(function(){ t[config].apply(t, i)})} }
               var t = { config:config},u=document,e=window,o='script',s=u.createElement(o),i,f;for(s.src=config.url||'//az416426.vo.msecnd.net/scripts/a/ai.0.js',u.getElementsByTagName(o)[0].parentNode.appendChild(s),t.cookie=u.cookie,t.queue=[],i=['Event','Exception','Metric','PageView','Trace','Ajax'];i.length;)r('track'+i.pop());return r('setAuthenticatedUserContext'),r('clearAuthenticatedUserContext'),config.disableExceptionTracking||(i='onerror',r('_'+i),f=e[i],e[i]=function(config, r, u, e, o) { var s = f && f(config, r, u, e, o); return s !== !0 && t['_' + i](config, r, u, e, o),s}),t
           }({
               instrumentationKey:'00000000-0000-0000-0000-000000000000'
           });
  
           window.appInsights=appInsights;
           appInsights.trackPageView();
       </script>
  ...
  </head>
  

• ConnectedService.json

  {
     "ProviderId": "Microsoft.ApplicationInsights.ConnectedService.ConnectedServiceProvider",
     "Version": "16.0.0.0",
     "GettingStartedDocument": {
       "Uri": "https://go.microsoft.com/fwlink/?LinkID=613413"
    }
  }
  

• FilterConfig.cs

           public static void RegisterGlobalFilters(GlobalFilterCollection filters)
           {
               filters.Add(new ErrorHandler.AiHandleErrorAttribute());// This line was added
           }
  

若要在配置中禁用遥测关联，请参阅<ExcludeComponentCorrelationHttpHeadersOnDomains> 中的 。

有关详细信息，请参阅 为 ASP.NET 网站配置 Application Insights。

Microsoft 不再支持 ASP.NET Core 3.1。

Application Insights SDK for ASP.NET Core 版本 2.8.0 和 Studio 2019 或更高版本可与 ASP.NET Core 3.1 应用程序一起使用。

通过使用构造函数注入获取 TelemetryClient 的实例，然后对其调用所需的 TrackXXX() 方法。 不建议在 ASP.NET Core 应用程序中创建新的 TelemetryClient 或 TelemetryConfiguration 实例。 TelemetryClient 容器中已注册了 DependencyInjection 的单一实例，该实例与剩余的遥测共享 TelemetryConfiguration。 仅在需要与其他遥测不同的配置时创建新 TelemetryClient 实例。

以下示例展示了如何从控制器跟踪更多遥测数据。

using Microsoft.ApplicationInsights;

public class HomeController : Controller
{
    private TelemetryClient telemetry;

    // Use constructor injection to get a TelemetryClient instance.
    public HomeController(TelemetryClient telemetry)
    {
       this.telemetry = telemetry;
    }

    public IActionResult Index()
    {
        // Call the required TrackXXX method.
        this.telemetry.TrackEvent("HomePageRequested");
        return View();
    }
}

有关 Application Insights 中自定义数据报告的详细信息，请参阅 Application Insights 自定义指标 API 参考。 使用 GetMetric API 将自定义指标发送到 Application Insights 时，可使用类似的方法。

ASP.NET Core 提供通过 记录 HTTP 请求/响应信息（包括正文）的ILogger。 建议利用此功能。 这可能会公开遥测中的个人身份信息 (PII)，并可能导致成本（性能成本和 Application Insights 计费）显著增加，因此请在使用此功能之前仔细评估风险。

默认情况下，Application Insights 只会捕获“警告”及更严重的日志。

通过更改 Application Insights 提供程序的日志记录配置，捕获“信息”和不太严重的日志，如下所示。

{
    "Logging": {
        "LogLevel": {
            "Default": "Information"
        },
        "ApplicationInsights": {
            "LogLevel": {
                "Default": "Information"
            }
        }
    },
    "ApplicationInsights": {
        "ConnectionString": "InstrumentationKey=00000000-0000-0000-0000-000000000000"
    }
}

请务必注意，以下示例不会导致 Application Insights 提供程序捕获 Information 日志。 它不会对其进行捕获，因为 SDK 添加了一个默认日志记录筛选器，该筛选器指示 ApplicationInsights 仅捕获 Warning 日志和严重级别更高的日志。 Application Insights 需要显式替代。

{
    "Logging": {
       "LogLevel": {
           "Default": "Information"
       }
    }
}

有关详细信息，请参阅 ILogger 配置。

尽管 UseApplicationInsights() 扩展方法仍受支持，但它在 Application Insights SDK 版本 2.8.0 和更高版本中已标记为弃用。 在下一个 SDK 主要版本中，将会删除它。 要启用 Application Insights 遥测，请使用 AddApplicationInsightsTelemetry()，因为它提供用于控制一些配置的重载。 此外，在 ASP.NET Core 3.X 应用中，services.AddApplicationInsightsTelemetry() 是启用 Application Insights 的唯一方式。

如果在生成时已按本文所示安装了 SDK，则无需从应用服务门户启用 Application Insights 扩展。 如果安装了扩展，则当检测到 SDK 已添加时，该扩展将回退。 如果从扩展启用 Application Insights，则无需安装和更新 SDK。 但是，遵照本文中的说明启用 Application Insights 会更灵活，原因如下：

• Application Insights 遥测功能在以下位置继续正常运行：
  • 所有操作系统，包括 Windows、Linux 和 Mac。
  • 所有发布模式，包括独立发布或依赖框架。
  • 所有目标框架，包括完整的 .NET Framework。
  • 所有托管选项，包括 Web 应用、VM、Linux、容器、AKS和非 Azure 托管。
  • 所有 .NET Core 版本，包括预览版。
• 从 Visual Studio 调试时，可在本地查看遥测数据。
• 可以使用 TrackXXX() API 跟踪更多自定义遥测数据。
• 可以完全控制配置。

是的。 在 Application Insights Agent 2.0.0-beta1 及更高版本中，支持在 IIS 中托管的 ASP.NET Core 应用程序。

是的。 SDK 的功能支持在所有平台中是相同的，不过存在以下例外情况：

• 该 SDK 在 Linux 上收集事件计数器，因为性能计数器仅在 Windows 中受支持。 大多数指标是相同的。

否。 或者，请为辅助角色服务使用适用于辅助角色服务应用程序（非 HTTP 应用）的 Application Insights。

要删除 Application Insights，需要从应用程序中的 API 删除 NuGet 包和引用。 可以使用 Visual Studio 中的 NuGet 包管理器卸载 NuGet 包。

1. 使用 NuGet 包管理器卸载 Microsoft.ApplicationInsights.AspNetCore 包。
2. 若要完全删除 Application Insights，请检查并手动删除添加的代码或文件以及在项目中添加的所有 API 调用。 有关详细信息，请参阅添加 Application Insights SDK 时会创建哪些内容？。

将 Application Insights 添加到项目时，它会创建文件并在某些文件中添加代码。 仅卸载 NuGet 包并不总是能够删除文件和代码。 若要完全删除 Application Insights，应检查并手动删除添加的代码或文件以及在项目中添加的所有 API 调用。

将 Application Insights 遥测添加到 Visual Studio ASP.NET Core 模板项目时，它会添加以下代码：

• [项目名称].csproj

  <PropertyGroup>
       <TargetFramework>netcoreapp3.1</TargetFramework>
       <ApplicationInsightsResourceId>/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/Default-ApplicationInsights-EastUS/providers/microsoft.insights/components/WebApplication4core</ApplicationInsightsResourceId>
  </PropertyGroup>
  
  <ItemGroup>
       <PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.12.0" />
  </ItemGroup>
  
  <ItemGroup>
       <WCFMetadata Include="Connected Services" />
  </ItemGroup>
  

• Appsettings.json

  "ApplicationInsights": {
       "ConnectionString": "InstrumentationKey=00000000-0000-0000-0000-000000000000"
  }
  

• ConnectedService.json

  {    
       "ProviderId": "Microsoft.ApplicationInsights.ConnectedService.ConnectedServiceProvider",
       "Version": "16.0.0.0",
       "GettingStartedDocument": {
           "Uri": "https://go.microsoft.com/fwlink/?LinkID=798432"
       }
  }
  

• Startup.cs

  public void ConfigureServices(IServiceCollection services)
       {
          services.AddRazorPages();
          services.AddApplicationInsightsTelemetry(); // This is added
       }
  

若要在代码中禁用遥测关联，请在<ExcludeComponentCorrelationHttpHeadersOnDomains> 中查看。

有关详细信息，请参阅适用于 ASP.NET Core 的 Application Insights。

• Exception rate：“异常率”是系统性能计数器。 CLR 会对所有引发的已处理和未经处理异常进行计数，并将总采样间隔除以间隔长度。 Application Insights SDK 会收集此结果，并将其发送到门户。
• Exceptions：异常指标根据图表的采样间隔对门户收到的 TrackException 报告进行计数。 它仅包括代码中写入 TrackException 调用的已处理异常。 它不包括所有未经处理的异常。

有关详细信息，请参阅 Application Insights 中的 .NET 计数器。

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

ASP.NET Core 的 Application Insights 扩展尚不支持此功能。

有关详细信息，请参阅 Application Insights 中的 .NET 计数器。

默认情况下，ASP.NET Core 应用启用客户端监视。 如果要禁用它，请使用以下信息在服务器中定义环境变量：

• 名称：APPINSIGHTS_JAVASCRIPT_ENABLED
• 价值：false

有关详细信息，请参阅 适用于 Azure VM 和虚拟机规模集的 Application Insights。

失败依赖项调用将 success 字段设置为 False。 模块 DependencyTrackingTelemetryModule 不报告 ExceptionTelemetry。 Application Insights 遥测数据模型中介绍了依赖项的完整数据模型。

请使用此代码：

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

在 Log Analytics 查询视图中，timestamp 表示启动 TrackDependency() 调用的时刻，即收到依赖项调用响应后的那一刻。 若要计算依赖项调用的开始时间，需要获取 timestamp，然后减去记录的依赖项调用的 duration。

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

有关详细信息，请参阅 依赖项跟踪。

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

• 防火墙门：允许从长且可更改的 Web 测试代理列表中请求自己的服务器。
• 自定义代码：编写自己的代码，以从 Intranet 内部向服务器发送定期请求。 可以为此运行 Visual Studio Web 测试。 测试人员可以使用 TrackAvailability() API 将结果发送到 Application Insights。

用户代理字符串为 Mozilla/5.0 (compatible; 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 配置。

详细信息取决于项目类型。 以下列表是 Web 应用程序的示例。

• 将文件添加到项目：

  • ApplicationInsights.config
  • ai.js

• 安装 NuGet 包：

  • Application Insights API：核心 API
  • 适用于 Web 应用程序的 Application Insights API：用于从服务器发送遥测
  • 适用于 JavaScript 应用程序的 Application Insights API：用于从客户端发送遥测

• 包括包中的程序集：

  • Microsoft.ApplicationInsights
  • Microsoft.ApplicationInsights.Platform

• 将项目插入：

  • Web.config
  • packages.config

• 在客户端和服务器代码中插入代码片段，以使用 Application Insights 资源 ID 初始化它们。 例如，在 MVC 应用中，代码插入到主页 Views/Shared/_Layout.cshtml 中。 仅对于新项目，可手动将 Application Insights 添加到现有项目。

Application Insights 为向应用程序发出的请求收集遥测数据。 如果在 WebApps/WebServer 中发生故障，并且请求未到达用户应用程序，则 Application Insights 不会有任何有关它的遥测数据。

Application Insights 算出的 serverresponsetime 持续时间不一定与 Web 应用观察到的服务器响应时间匹配。 此行为是因为 Application Insights 仅在请求实际到达用户应用程序时计算其持续时间。 如果请求在 WebServer 中停滞或排队，则该等待时间将包含在 Web 应用指标中，但不会包含在 Application Insights 指标中。

有关详细信息，请参阅 在 Azure 应用服务中启用应用程序监视。

对于发布到 Microsoft Learn 平台的产品文档，我们遵循 Microsoft 风格指南。

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

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

如果需要在 Node.js中定制指标，请手动使用 Azure Monitor OpenTelemetry 发行版配置应用程序。

Java 允许通过自动检测实现自定义指标。 可以通过更新代码并启用此功能 来收集自定义指标 。 如果代码已有自定义指标，则在启用自动检测时，这些指标会自动通过。

AKS 自动检测可以中断 OSS OpenTelemetry SDK 发送到第三方的遥测数据。

AKS 自动检测旨在与两种手动检测选项共存：Application Insights 经典 API SDK 和 OpenTelemetry 发行版。

它始终会阻止重复数据，并确保自定义指标正常工作。

请参阅此图表来确定自动检测或手动检测的优先级。

Azure Monitor OpenTelemetry 发行版中检测到的漏洞优先、修复并在下一版本中发布。

每次更改或重启部署时，AKS 自动检测都会将最新版本的 Azure Monitor OpenTelemetry 发行版注入应用程序 Pod。

OpenTelemetry 发行版在长时间内未更改或重启的部署上可能会变得易受攻击。 因此，我们建议每周更新或重启部署，以确保正在使用最新版本的发行版。

此功能通过将 Azure Monitor OpenTelemetry Distro 注入应用程序容器来实现自动检测。

对于 Java，此功能集成了适用于 Java 的独立 Azure Monitor OpenTelemetry 发行版。 请参阅 Java 发行版文档 ，了解有关 Java 检测二进制文件的详细信息。

对于 Node.js，我们将基于适用于 Node.js 的 Azure Monitor OpenTelemetry 发行版注入自动检测二进制文件。 有关详细信息，请参阅 Node.js 发行版文档。 请记住，我们没有针对 Node.js 的独立自动检测，因此我们的发行版文档适用于手动检测。 可以忽略与手动检测相关的基于代码的配置步骤。 但是，我们的发行版文档中的其他所有内容（如默认设置、环境变量配置等）都适用于此功能。

有关详细信息，请参阅 AKS 的自动检测。

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

建议使用连接字符串，而不是检测密钥。

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

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

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

• 为每个区域创建一个 Application Insights 资源，其中包含严格的符合性要求，例如欧盟或美国。
• 为所有其他区域中的用户创建另一个 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 遥测数据模型。

ApplicationInsightsLoggerProvider 捕获 ILogger 日志并从中创建 TraceTelemetry。 如果将 Exception 对象传递给 Log 上的 ILogger 方法，则会创建 ExceptionTelemetry 而不是 TraceTelemetry。

查看 ILogger 遥测

在 Azure 门户中：

1. 转到 Azure 门户并访问 Application Insights 资源。
2. 选择 Application Insights 中的“日志”部分。
3. 使用 Kusto 查询语言 (KQL) 查询 ILogger 消息，存储在 traces 表中。 示例查询：traces | where message contains "YourSearchTerm"。
4. 优化查询，按严重性、时间范围或特定消息内容筛选 ILogger 数据。

在 Visual Studio 中（本地调试程序）：

1. 在 Visual Studio 中以调试模式启动应用程序。
2. 在应用程序运行时打开“诊断工具”窗口。
3. 在“事件”选项卡中，ILogger 日志与其他遥测数据一起显示。
4. 若要查找特定的 ILogger 消息，请使用“诊断工具”窗口中的搜索和筛选功能来查找特定的 ILogger 消息。

若要始终发送 TraceTelemetry，请使用此代码片段：

builder.AddApplicationInsights(
    options => options.TrackExceptionsAsExceptionTelemetry = false);

Application Insights 使用对其他每项遥测功能所用的相同 ILogger 来捕获和发送 TelemetryConfiguration 日志。 但存在一种例外情况。 默认情况下，从 Program.cs 或 Startup.cs 登录时，TelemetryConfiguration 未完全设置。 来自以下位置的日志不具有默认配置，因此它们不会运行所有 TelemetryInitializer 实例和 TelemetryProcessor 实例。

使用独立包时，不会将 TelemetryClient 注入依赖项注入 (DI) 容器。 你需要创建 TelemetryClient 的新实例，并使用记录器提供程序所用的相同配置，如以下代码所示。 此要求可确保对所有自定义遥测和来自 ILogger 的遥测使用相同的配置。

public class MyController : ApiController
{
   // This TelemetryClient instance can be used to track additional telemetry through the TrackXXX() API.
   private readonly TelemetryClient _telemetryClient;
   private readonly ILogger _logger;

   public MyController(IOptions<TelemetryConfiguration> options, ILogger<MyController> logger)
   {
        _telemetryClient = new TelemetryClient(options.Value);
        _logger = logger;
   }  
}

Azure Web 应用中的 Application Insights 扩展使用新提供程序。 可以在应用程序的 appsettings.json 文件中修改筛选规则。

有关详细信息，请参阅 使用 .NET 进行 Application Insights 日志记录。

Java Profiler 使用 Java Flight Recorder (JFR) 并通过自定义配置对应用程序进行分析。

Java 飞行记录器 (JFR) 是一个工具，用于收集正在运行的 Java 应用程序的分析数据。 JFR 集成到 Java 虚拟机 (JVM) 中，用于排查性能问题。 深入了解 Java SE JFR 运行时。

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

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

可以使用首选工具（例如 Java Mission Control (JMC)）查看和分析 JFR 记录内容。

“性能诊断和建议”是一项新功能，即将以 Application Insights Java 诊断的形式提供。 可以在注册后预览此功能。 可以使用 Java Mission Control (JMC) 查看 JFR 记录内容。

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

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

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

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

查看 先决条件。

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

有关详细信息，请参阅 适用于 Java 的 Azure Monitor Application Insights Profiler。

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

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

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

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

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

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

TelemetryClient.trackTrace() 是 Application Insights 经典 SDK 网桥的一部分，日志处理器仅适用于新的基于 OpenTelemetry 的检测。

有关详细信息，请参阅 遥测处理器（预览版） - 适用于 Java 的 Azure Monitor Application Insights。

• JavaScript SDK 在 Web 客户端上设置了用于识别返回用户的用户 cookie，以及用于对活动进行分组的会话 cookie。
• 如果没有客户端脚本，可以在服务器设置 cookie。
• 如果某个真实的用户在不同的浏览器中使用站点，或者使用私密/隐身浏览，或使用不同的计算机，则会进行多次计数。
• 若要识别跨计算机和浏览器登录的用户，请添加对 setAuthenticatedUserContext() 的调用。

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 存储库。

有关详细信息，请参阅 “启用 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 应用服务中出现的 HTTP 错误“502 错误的网关”和“503 服务不可用”。

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

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

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

有关详细信息，请参阅 为 Application Insights JavaScript SDK 启用框架扩展。

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

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

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

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

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

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

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

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

若要禁用遥测关联，请在配置中使用 correlationHeaderExcludedDomains 属性。 有关详细信息，请参阅 ApplicationInsights-node.js。

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

有关详细信息，请参阅 使用 Application Insights 监视 Node.js 服务和应用。

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

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

OpenTelemetry 是供应商中性可观测性框架。 OpenTelemetry SDK 或库中没有 Application Insights API。 在迁移之前，请务必了解一些 OpenTelemetry 的概念。

• 在 Application Insights 中，所有遥测数据都通过单个 TelemetryClient 和 TelemetryConfiguration 管理。 在 OpenTelemetry 中，三个遥测信号（跟踪、指标和日志）都有其自己的配置。 无需外部库即可通过 .NET 运行时手动创建遥测数据。 有关详细信息，请参阅有关分布式跟踪、指标和日志记录的 .NET 指南。

• Application Insights 使用 TelemetryModules 自动收集应用程序的遥测数据。 相反，OpenTelemetry 使用检测库从特定组件（例如用于请求的 AspNetCore 和用于依赖项的 HttpClient）收集遥测数据。

• Application Insights 使用 TelemetryInitializers 通过其他信息丰富遥测数据或重写属性。 可使用 OpenTelemetry 编写处理器，从而自定义特定信号。 此外，许多 OpenTelemetry 自动化工具库提供了 Enrich 方法，以自定义由该特定组件生成的遥测数据。

• Application Insights 使用 TelemetryProcessors 筛选遥测数据。 OpenTelemetry 处理器还可用于对特定信号应用筛选规则。

此表将 Application Insights 数据类型映射到 OpenTelemetry 概念及其 .NET 实现。

以下文档提供了更多信息。

• Azure Monitor Application Insights 的数据收集基础知识
• Application Insights 遥测数据模型
• OpenTelemetry 概念

虽然 Application Insights 提供了多个用于配置采样的选项，但 Azure Monitor 导出程序或 Azure Monitor 发行版仅提供固定速率采样。 只能采样请求和依赖项（OpenTelemetry 跟踪）。

有关如何配置采样的代码示例，请参阅我们的启用采样指南

在 Application Insights .NET SDK 中，使用遥测处理器筛选和修改或放弃遥测数据。 使用遥测初始值设定项添加或修改自定义属性。 有关详细信息，请参阅 Azure Monitor 文档。 OpenTelemetry 将这些概念替换为活动或日志处理器，从而丰富和筛选遥测数据。

筛选跟踪

若要在 OpenTelemetry 中筛选遥测数据，可以采用活动处理器。 此示例等效于 Application Insights 示例，用于筛选遥测数据，如 Azure Monitor 文档中所述。 该示例说明了筛选不成功的依赖项调用的位置。

using System.Diagnostics;
using OpenTelemetry;

internal sealed class SuccessfulDependencyFilterProcessor : BaseProcessor<Activity>
{
    public override void OnEnd(Activity activity)
    {
        if (!OKtoSend(activity))
        {
            activity.ActivityTraceFlags &= ~ActivityTraceFlags.Recorded;
        }
    }

    private bool OKtoSend(Activity activity)
    {
       return activity.Kind == ActivityKind.Client && activity.Status == ActivityStatusCode.Ok;
    }
}

若要使用此处理器，需要在 TracerProvider 之前创建 AddAzureMonitorTraceExporter 并添加处理器。

using OpenTelemetry.Trace;

public static void Main()
{
   var tracerProvider = Sdk.CreateTracerProviderBuilder()
       .AddProcessor(new SuccessfulDependencyFilterProcessor())
       .AddAzureMonitorTraceExporter()
       .Build();
}

筛选日志

ILogger 实现具有内置机制，可应用日志筛选。 通过此筛选，可以控制发送到每个已注册提供程序（包括 OpenTelemetryLoggerProvider）的日志。 “OpenTelemetry”是用于配置筛选规则的 的OpenTelemetryLoggerProvider。

以下示例将“Error”定义为默认 LogLevel，并将“Warning”定义为用户定义的类别的最小 LogLevel。 定义的这些规则仅适用于 OpenTelemetryLoggerProvider。

builder.AddFilter<OpenTelemetryLoggerProvider>("*", LogLevel.Error);
builder.AddFilter<OpenTelemetryLoggerProvider>("MyProduct.MyLibrary.MyClass", LogLevel.Warning);

有关详细信息，请阅读关于日志的 OpenTelemetry .NET 文档。

将自定义属性添加到跟踪

在 OpenTelemetry 中，可以使用活动处理器通过更多属性丰富遥测数据。 这类似于在 Application Insights 中使用遥测初始值设定项，你可在前者中修改遥测属性。

默认情况下，Azure Monitor 导出程序会将响应代码为 400 或更高的任何 HTTP 请求标记为失败。 但是，如果要将 400 视为成功，可以添加一个扩充活动处理器来设置活动的成功，并添加一个标签以包含更多遥测属性。 这类似于在 Application Insights 中使用初始值设定项添加或修改属性，如 Azure Monitor 文档中所述。

以下示例说明如何添加自定义属性并替代特定响应代码的默认行为：

using System.Diagnostics;
using OpenTelemetry;

/// <summary>
/// Custom Processor that overrides the default behavior of treating response codes >= 400 as failed requests.
/// </summary>
internal class MyEnrichingProcessor : BaseProcessor<Activity>
{
    public override void OnEnd(Activity activity)
    {
        if (activity.Kind == ActivityKind.Server)
        {
            int responseCode = GetResponseCode(activity);

            if (responseCode >= 400 && responseCode < 500)
            {
               // If we set the Success property, the SDK won't change it
               activity.SetStatus(ActivityStatusCode.Ok);

               // Allow to filter these requests in the portal
              activity.SetTag("Overridden400s", "true");
            }

            // else leave the SDK to set the Success property
        }
    }

    private int GetResponseCode(Activity activity)
    {
       foreach (ref readonly var tag in activity.EnumerateTagObjects())
       {    
          if (tag.Key == "http.response.status_code" && tag.Value is int value)
          {
           return value;
          }
       }

       return 0;
    }
}

若要使用此处理器，需要在 TracerProvider 之前创建 AddAzureMonitorTraceExporter 并添加处理器。

using OpenTelemetry.Trace;

public static void Main()
{
   var tracerProvider = Sdk.CreateTracerProviderBuilder()
       .AddSource("Company.Product.Name")
       .AddProcessor(new MyEnrichingProcessor())
       .AddAzureMonitorTraceExporter()
       .Build();
}

发送跟踪 - 手动

Application Insights 中的跟踪存储为 RequestTelemetry 和 DependencyTelemetry。 在 OpenTelemetry 中，跟踪通过 Span 类建模为 Activity。

OpenTelemetry .NET 利用跟踪的 ActivitySource 和 Activity 类，这些类是 .NET 运行时的一部分。 此方法很独特，因为 .NET 实现将跟踪 API 直接集成到运行时本身。 System.Diagnostics.DiagnosticSource 包可让开发者用 ActivitySource 创建和管理 Activity 实例。 此方法可让你无需依赖外部库即可无缝将跟踪添加到 .NET 应用程序，从而应用 .NET 生态系统的内置功能。 有关更多详细信息，请参阅分布式跟踪检测演练。

下面介绍如何迁移手动跟踪：

DependencyTelemetry

Application Insights DependencyTelemetry 用于为传出请求建模。 下面介绍如何将其转换为 OpenTelemetry：

Application Insights 示例：

DependencyTelemetry dep = new DependencyTelemetry
{
   Name = "DependencyName",
   Data = "https://www.example.com/",
   Type = "Http",
   Target = "www.example.com",
   Duration = TimeSpan.FromSeconds(10),
   ResultCode = "500",
   Success = false
};

dep.Context.Cloud.RoleName = "MyRole";
dep.Context.Cloud.RoleInstance = "MyRoleInstance";
dep.Properties["customprop1"] = "custom value1";
client.TrackDependency(dep);

OpenTelemetry 示例：

var activitySource = new ActivitySource("Company.Product.Name");
var resourceAttributes = new Dictionary<string, object>
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
  .SetResourceBuilder(resourceBuilder)
  .AddSource(activitySource.Name)
  .AddAzureMonitorTraceExporter()
  .Build();

// Emit traces
using (var activity = activitySource.StartActivity("DependencyName", ActivityKind.Client))
{
  activity?.SetTag("url.full", "https://www.example.com/");
  activity?.SetTag("server.address", "www.example.com");
  activity?.SetTag("http.request.method", "GET");
  activity?.SetTag("http.response.status_code", "500");
  activity?.SetTag("customprop1", "custom value1");
  activity?.SetStatus(ActivityStatusCode.Error);
  activity?.SetEndTime(activity.StartTimeUtc.AddSeconds(10));
}

RequestTelemetry

Application Insights RequestTelemetry 对传入请求建模。 下面介绍如何将其迁移到 OpenTelemetry：

Application Insights 示例：

RequestTelemetry req = new RequestTelemetry
{
   Name = "RequestName",
   Url = new Uri("http://example.com"),
   Duration = TimeSpan.FromSeconds(10),
   ResponseCode = "200",
   Success = true,
   Properties = { ["customprop1"] = "custom value1" }
};

req.Context.Cloud.RoleName = "MyRole";
req.Context.Cloud.RoleInstance = "MyRoleInstance";
client.TrackRequest(req);

OpenTelemetry 示例：

var activitySource = new ActivitySource("Company.Product.Name");
var resourceAttributes = new Dictionary<string, object>
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
  .SetResourceBuilder(resourceBuilder)
  .AddSource(activitySource.Name)
  .AddAzureMonitorTraceExporter()
  .Build();

// Emit traces
using (var activity = activitySource.StartActivity("RequestName", ActivityKind.Server))
{
  activity?.SetTag("url.scheme", "https");
  activity?.SetTag("server.address", "www.example.com");
  activity?.SetTag("url.path", "/");
  activity?.SetTag("http.response.status_code", "200");
  activity?.SetTag("customprop1", "custom value1");
  activity?.SetStatus(ActivityStatusCode.Ok);
}

自定义操作跟踪

在 Application Insights 中，使用 StartOperation 和 StopOperation 方法跟踪自定义操作。 在 OpenTelemetry .NET 中使用 ActivitySource 和 Activity 实现此目的。 对于包含 ActivityKind.Server 和 ActivityKind.Consumer 的操作，Azure Monitor 导出程序将生成 RequestTelemetry。 对于 ActivityKind.Client、ActivityKind.Producer以及 ActivityKind.Internal，它将生成 DependencyTelemetry。 有关自定义操作跟踪的详细信息，请参阅 Azure Monitor 文档。 有关在 .NET 中使用 ActivitySource 和 Activity 的详细信息，请参阅 .NET 分布式跟踪检测演练。

下面是有关如何为自定义操作启动和停止活动的示例：

using System.Diagnostics;
using OpenTelemetry;

var activitySource = new ActivitySource("Company.Product.Name");

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
    .AddSource(activitySource.Name)
    .AddAzureMonitorTraceExporter()
    .Build();

// Start a new activity
using (var activity = activitySource.StartActivity("CustomOperation", ActivityKind.Server))
{
    activity?.SetTag("customTag", "customValue");

    // Perform your custom operation logic here

    // No need to explicitly call Activity.Stop() because the using block automatically disposes the Activity object, which stops it.
}

发送日志

Application Insights 中的日志存储为 TraceTelemetry 和 ExceptionTelemetry。

TraceTelemetry

在 OpenTelemetry 中，日志记录通过 ILogger 接口集成。 下面介绍如何迁移 TraceTelemetry：

Application Insights 示例：

TraceTelemetry traceTelemetry = new TraceTelemetry 
{
   Message = "hello from tomato 2.99",
   SeverityLevel = SeverityLevel.Warning,
};

traceTelemetry.Context.Cloud.RoleName = "MyRole";
traceTelemetry.Context.Cloud.RoleInstance = "MyRoleInstance";
client.TrackTrace(traceTelemetry);

OpenTelemetry 示例：

var resourceAttributes = new Dictionary<string, object>
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var loggerFactory = LoggerFactory.Create(builder => builder
   .AddOpenTelemetry(logging =>
   {
       logging.SetResourceBuilder(resourceBuilder);
       logging.AddAzureMonitorLogExporter();
   }));

// Create a new instance `ILogger` from the above LoggerFactory
var logger = loggerFactory.CreateLogger<Program>();

// Emit log: This uses the logger instance to write a new log
logger.FoodPrice("tomato", 2.99);

internal static partial class LoggerExtensions
{
   [LoggerMessage(LogLevel.Warning, "Hello from `{name}` `{price}`.")]
   public static partial void FoodPrice(this ILogger logger, string name, double price);
}

ExceptionTelemetry

Application Insights 使用 ExceptionTelemetry 记录异常。 下面介绍如何迁移到 OpenTelemetry：

Application Insights 示例：

ExceptionTelemetry exceptionTelemetry = new ExceptionTelemetry(new Exception("Test exception"))
{
    SeverityLevel = SeverityLevel.Error
};

exceptionTelemetry.Context.Cloud.RoleName = "MyRole";
exceptionTelemetry.Context.Cloud.RoleInstance = "MyRoleInstance";
exceptionTelemetry.Properties["customprop1"] = "custom value1";
client.TrackException(exceptionTelemetry);

OpenTelemetry 示例：

var resourceAttributes = new Dictionary<string, object> 
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var loggerFactory = LoggerFactory.Create(builder => builder
   .AddOpenTelemetry(logging =>
   {
       logging.SetResourceBuilder(resourceBuilder);
       logging.AddAzureMonitorLogExporter();
   }));

// Create a new instance `ILogger` from the above LoggerFactory.
var logger = loggerFactory.CreateLogger<Program>();

try
{
    // Simulate exception
    throw new Exception("Test exception");
}
catch (Exception ex)
{
   // Emit exception: This uses the logger instance to write a new exception
   logger?.LogError(ex, "An error occurred");
}

发送指标

Application Insights 中的指标存储为 MetricTelemetry。 在 OpenTelemetry 中，指标从 Meter 包作为 System.Diagnostics.DiagnosticSource 进行建模。

Application Insights 同时具有非预聚合 (TrackMetric()) 和预聚合 (GetMetric().TrackValue()) 指标 API。 与 OpenTelemetry 不同，Application Insights 没有仪表的概念。 对于所有指标情况，Application Insights 具有相同的 API。

另一方面，OpenTelemetry 要求用户首先根据指标的实际语义选择合适的指标检测。 例如，如果打算计算某些内容（例如收到的服务器请求总数等），则应使用 OpenTelemetry Counter。 如果打算计算各种百分位数（如服务器延迟的 P99 值），则应使用 OpenTelemetry 直方图工具。 由于 Application Insights 和 OpenTelemetry 之间的这一基本差异，没有对它们进行直接比较。

与 Application Insights 不同，OpenTelemetry 不提供用于扩充或筛选指标的内置机制。 在 Application Insights 中，遥测处理器和初始值设定项可用于修改或放弃指标，但 OpenTelemetry 中不提供此功能。

此外，OpenTelemetry 不支持直接发送原始指标，因为没有 Application Insights 中发现的 TrackMetric() 功能的等效项。

从 Application Insights 迁移到 OpenTelemetry 涉及将所有使用的 Application Insights 指标 API 替换为 OpenTelemetry API。 你需要了解各种 OpenTelemetry 工具及其语义。

其他遥测数据类型

CustomEvents

OpenTelemetry 中不支持。

Application Insights 示例：

TelemetryClient.TrackEvent()

AvailabilityTelemetry

OpenTelemetry 中不支持。

Application Insights 示例：

TelemetryClient.TrackAvailability()

PageViewTelemetry

OpenTelemetry 中不支持。

Application Insights 示例：

TelemetryClient.TrackPageView()

我们建议对控制台服务应用程序和后台服务应用程序使用 Azure Monitor OpenTelemetry Exporter，它不包含实时指标。

有关详细信息，请参阅 从 .NET Application Insights SDK 迁移到 Azure Monitor OpenTelemetry。

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

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

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

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

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

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

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

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

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

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

有关详细信息，请参阅 使用 OpenTelemetry 的 Azure Monitor Application Insights 中的采样。

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

Microsoft 投资 OpenTelemetry 的原因如下：

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

请参阅 OpenTelemetry 状态。

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

使用 Azure Monitor OpenTelemetry 发行版相比于社区原生的 OpenTelemetry 有几个优势：

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

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

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

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

对于没有受支持独立 OpenTelemetry 导出程序的语言，目前仅支持通过 Azure Monitor OpenTelemetry Distro 方式将 OpenTelemetry 与 Azure Monitor 配合使用。 对于具有受支持独立 OpenTelemetry 导出程序的语言，可以根据遥测方案选择使用 Azure Monitor OpenTelemetry Distro 或相应的独立 OpenTelemetry 导出程序。 有关详细信息，请参阅何时应使用 Azure Monitor OpenTelemetry 导出程序？。

请查看我们的 .NET、Java、JavaScript (Node.js) 和 Python 启用文档。

如果 Azure Monitor OpenTelemetry Distro 的功能符合你的监视需求，我们建议将其用于新项目。 OpenTelemetry 是一种行业标准框架，可增强跨平台可观测性，并提供遥测收集的标准化方法。

但是，Application Insights SDK 仍提供某些尚未在 OpenTelemetry 中完全自动化的功能，包括：

• 自动依赖项跟踪 – OpenTelemetry 支持依赖项跟踪，但与 Application Insights SDK 中提供的自动跟踪相比，某些依赖项需要其他配置。
• 自定义遥测类型（例如 AvailabilityTelemetry 和 PageViewTelemetry – OpenTelemetry）没有直接等效项。 可以通过手动检测实现类似的功能。
• 遥测处理器和初始化程序 – OpenTelemetry 具有处理器和范围处理器，但它们并不能在所有情况下完全取代 Application Insights 遥测处理器和初始化程序。
• 扩展指标集合 – 虽然 OpenTelemetry 具有强大的指标系统，但 Application Insights SDK 中的一些内置指标需要在 OpenTelemetry 中手动设置。

OpenTelemetry 还优于 Application Insights SDK，包括：

• 跨平台实现更好的标准化
• 更广泛的检测库生态系统
• 在数据收集和处理方面具有更大的灵活性
• 改进了供应商中立性，但 Azure Monitor OpenTelemetry 发行版仍针对 Azure 进行了优化。

Azure Monitor 的 OpenTelemetry 集成不断发展，Microsoft继续增强其功能。 如果你正在考虑过渡，请仔细评估 OpenTelemetry 当前是否满足可观测性要求，或者 Application Insights SDK 是否仍然更适合你的需求。

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

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

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

以下图表划分了每种语言的 OpenTelemetry 功能支持。

密钥

• ✅ 此功能适用于享受正式支持的所有客户。
• ⚠ 此功能目前以公共预览版提供。 请参阅 Microsoft Azure 预览版补充使用条款。
• ❌ 此功能不可用或不适用。

可以，但我们不建议使用它，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 概述。

某些客户使用 OpenTelemetry-Collector 作为代理替代方案，尽管 Microsoft 尚不正式支持使用基于代理的方法进行应用程序监视。 与此同时，开源社区贡献了一个 OpenTelemetry-Collector Azure Monitor 导出器，某些客户正在使用它向 Azure Monitor Application Insights 发送数据。 Microsoft 对此不支持。

OpenCensus 是 OpenTelemetry 的前身。 Microsoft 帮助整合 OpenTracing 和 OpenCensus 用于创建 OpenTelemetry，OpenTelemetry 是全球唯一的可观测性标准。 Azure Monitor 当前推荐用于生产环境的 Python SDK 基于 OpenCensus。 Microsoft 致力于基于 OpenTelemetry 创建 Azure Monitor。

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

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

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

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

有关详细信息，请参阅 适用于 Application Insights 的 OpenTelemetry 支持和反馈。

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

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

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

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

简单地讲，在向后端传送遥测数据方面，没有任何内置通道能够提供事务类型保证。 在可靠传送方面，ServerTelemetryChannel 比 InMemoryChannel 更先进，但它也只能是尽最大努力来尝试发送遥测数据。 在多种情况下，遥测数据仍可能会丢失，常见情况包括：

• 当应用程序崩溃时，内存中的项就会丢失。
• 如果网络问题的持续时间很长，遥测数据将会丢失。 出现网络中断或者 Application Insights 后端问题时，遥测数据将存储到本地磁盘。 但是，超过 48 小时的项将被丢弃。
• 在 Windows 中，用于存储遥测数据的默认磁盘位置是 %LOCALAPPDATA% 或 %TEMP%。 这些位置通常位于计算机本地。 如果以物理方式将应用程序从一个位置迁移到另一个位置，在原始位置存储的所有遥测数据将会丢失。
• 在 Windows 上的 Azure Web 应用中，默认的磁盘存储位置是 D:\local\LocalAppData。 此位置不是永久性的。 在应用重启、横向扩展和执行其他此类操作的情况下将被擦除，导致这些位置存储的遥测数据丢失。 您可以覆盖默认设置，并将存储指定到一个持久化位置，例如 D:\home。 但是，此类永久性位置由远程存储提供服务，因此运行速度可能很缓慢。

尽管不太可能，但通道也可能导致重复的遥测项。 当 ServerTelemetryChannel 因网络故障或超时而重试时，如果遥测已传送到后端，但由于网络问题或超时导致响应丢失，则会发生此行为。

尽管该通道的包和命名空间名称包含“WindowsServer”，但非 Windows 系统也支持此通道，不过存在以下例外情况。 在非 Windows 系统中，该通道默认不会创建本地存储文件夹。 必须创建本地存储文件夹，并配置通道以使用该文件夹。 配置本地存储后，该通道在所有系统中的工作方式相同。

出现网络问题或限制时，SDK 会将遥测项存储在本地存储中。 此数据不会在本地加密。

对于 Windows 系统，SDK 会自动在 %TEMP% 或 %LOCALAPPDATA% 目录中创建临时本地文件夹，并仅限管理员和当前用户访问该文件夹。

对于非 Windows 系统，SDK 不会自动创建本地存储，因此默认不会在本地存储数据。

你可以自行创建存储目录，并将通道配置为使用该目录。 在这种情况下，你需负责确保该目录受到保护。 详细了解数据保留和隐私。

有关详细信息，请参阅 Application Insights 中的遥测通道。

请参阅限制摘要。

我们不自动记录 POST 数据，但可以使用 TrackTrace 或日志调用。 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 门户中提交支持案例。

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

可视化上的初始事件仅表示用户在会话期间首次发送该页面视图或自定义事件。 如果用户可以在会话中多次发送初始事件，则“步骤 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 使用情况分析。

是，该配置与 Web 应用程序的其余部分共享。

通过使用构造函数注入获取 TelemetryClient 的实例，然后对其调用所需的 TrackXXX() 方法。 不建议创建新的 TelemetryClient 实例。 TelemetryClient 容器中已注册了 DependencyInjection 的单一实例，该实例与剩余的遥测共享 TelemetryConfiguration。 仅当需要与剩余的遥测功能使用不同的配置时，才建议创建新的 TelemetryClient 实例。

目前只有 ASP.NET/ASP.NET Core 应用程序支持 Visual Studio IDE 加入。 当 Visual Studio 支持加入辅助角色服务应用程序时，本文档将会随之更新。

否。 Azure Monitor Application Insights 代理目前仅支持 .NET。

是的。 此 SDK 的功能支持在所有平台中是相同的，不过存在以下例外情况：

• 性能计数器仅在 Windows 中受支持，但实时指标中所示的进程 CPU/内存除外。

• 尽管默认已启用 ServerTelemetryChannel，但如果应用程序在 Linux 或 macOS 中运行，出现网络问题时，通道不会自动创建本地存储文件夹来暂时保留遥测数据。 由于这种限制，在出现暂时性的网络或服务器问题时，遥测数据将会丢失。 若要解决此问题，请为通道配置一个本地文件夹：

  using Microsoft.ApplicationInsights.Channel;
  using Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel;
  
       public void ConfigureServices(IServiceCollection services)
       {
           // The following will configure the channel to use the given folder to temporarily
           // store telemetry items during network or Application Insights server issues.
           // User should ensure that the given folder already exists
           // and that the application has read/write permissions.
           services.AddSingleton(typeof(ITelemetryChannel),
                                   new ServerTelemetryChannel () {StorageFolder = "/tmp/myfolder"});
           services.AddApplicationInsightsTelemetryWorkerService();
       }
  

有关详细信息，请参阅适用于辅助角色服务应用程序的 Application Insights（非 HTTP 应用程序）。