.NET Core 3.1本地正常部署IIS后Application Insights实时指标无数据问题

第一步：开启Application Insights原生诊断日志，拿到无报错场景下的真实失败原因 #

• 之前调整ASP.NET Core全局日志级别拿不到AI相关日志，是因为2.16版本的Microsoft.ApplicationInsights.AspNetCore原生诊断日志默认不接入应用通用日志管道，不受应用全局日志级别配置的控制，必须单独配置才能输出详细的初始化、上报阶段的故障信息。
• 直接在部署目录的appsettings.json的ApplicationInsights配置节添加以下配置，强制将AI诊断日志输出到本地固定文件：

"ApplicationInsights": {
  "InstrumentationKey": "你的实际Key值",
  "EnableDebugLogger": true,
  "Diagnostics": {
    "LogFileName": "C:\\Logs\\AI_Diag.log",
    "LogLevel": "Verbose"
  }
}

• 必须确保IIS站点对应的应用池身份，对上述日志文件所在的目录有写入权限，否则AI会因为无法写日志静默终止遥测初始化。

第二步：针对IIS环境的高频故障点逐一校验 #

• 出站网络权限校验
  本地开发环境能连通不代表IIS环境能连通：IIS应用池使用独立的ApplicationPoolIdentity身份运行进程，不会继承当前登录用户的系统代理配置，也不会复用本地开发机的网络访问权限。

  注意：不要用本地用户的网络状态判断IIS服务器的连通性，必须在IIS服务器上，模拟应用池身份发起出站请求，验证能否正常访问Application Insights的遥测接收、实时指标服务端点。常见的静默拦截场景包括应用池身份无公网访问权限、内网防火墙拦截AI服务的出站长连接、透明代理拦截AI的TLS握手请求，这些场景都不会给应用抛出任何可捕获的异常。

• 配置有效性校验
  • 检查发布到IIS物理路径下的实际配置文件（包括生产环境专属的appsettings.Production.json、站点级环境变量配置），确认InstrumentationKey或连接字符串没有被发布流程覆盖、清空。
  • 核对Startup中AddApplicationInsightsTelemetry(_configuration)传入的配置对象，确认没有出现本地调试时读得到配置、部署后配置源丢失的问题——如果手动构造了IConfiguration实例，要确保其加载路径指向了IIS部署目录下的实际配置文件。
• 启动流程兼容性校验
  确认Program.cs中构建WebHost时正确调用了UseIISIntegration()方法，避免应用在IIS托管模式下以独立进程启动时，遥测通道因无法获取IIS环境上下文静默初始化失败。

第三步：定位Live Metrics离线的根因 #

• 先在应用内增加最小测试遥测：在任意可访问的接口中手动调用TelemetryClient.TrackTrace("连接测试")，部署到IIS后访问接口触发上报，到AI门户的搜索面板验证能否收到该条测试消息：
  • 如果基础遥测消息都无法收到，说明整个遥测通道初始化失败，查看之前开启的AI诊断日志定位具体原因。
  • 如果基础遥测能正常收到，仅Live Metrics显示离线，说明实时指标服务的长连接被网络策略拦截，可通过为TelemetryClient手动指定可用代理的方式解决（AI遥测通道默认不读取系统代理配置，和本地VS调试时的自动代理注入逻辑有差异）：

  services.AddApplicationInsightsTelemetry(options =>
  {
      options.ConnectionString = "你的实际连接字符串";
      options.Proxy = new WebProxy("IIS服务器可用代理地址", 代理端口);
  });
  

内容的提问来源于stack exchange，提问作者ssougnez