Azure Functions App 2.0中ILogger.LogError异常日志记录问题咨询

你的第一种写法其实是符合日志规范的正确用法，按道理应该会把异常的完整堆栈跟踪同步到App Insights里。没看到堆栈大概率不是代码写法的问题，咱们从这几个方向排查：

1. 检查host.json的日志配置是否正确 #

Azure Functions的日志行为由host.json控制，要确保App Insights的日志采集和级别设置没问题。比如你的配置里应该包含这些关键项：

{
  "logging": {
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true,
        "excludedTypes": "Request"
      },
      "enableDependencyTracking": true
    },
    "logLevel": {
      "Default": "Error",
      "Microsoft": "Warning",
      "System": "Warning"
    }
  }
}

• 注意samplingSettings：如果采样率过低或者配置了不合理的过滤规则，可能会导致包含堆栈的异常日志被丢弃。
• logLevel里的Default设为Error才能确保Error级别的日志被采集。

2. 确认你在App Insights里的日志查询方式正确 #

很多时候不是堆栈没被记录，而是你没找对地方：

• 异常的堆栈跟踪通常存在exceptions表，或者traces表的properties.ExceptionDetails字段里，而不是只显示message字段。
• 试试用这个Kusto查询来查看完整的异常信息：

  traces
  | where message contains "Error processing order"
  | project timestamp, message, properties.ExceptionDetails
  

  或者联合exceptions表关联查询：

  traces
  | join kind=inner exceptions on operation_Id
  | where traces.message contains "Error processing order"
  | project timestamp, traces.message, exceptions.details
  

3. 纠正你第二种错误的写法 #

你尝试的log.LogError(ex, $"Error processing order: {order.Id}", ex)是错的，因为LogError的第三个参数是用于格式化message的占位符参数，你的message里没有需要填充的占位符，把ex传进去只会让它被当成格式化参数处理，反而会干扰日志的正常采集，甚至丢失部分信息。所以一定要回到第一种写法：

try { processedOrder = await orderProcessingService.ProcessOrder(order); } 
catch (Exception ex) { log.LogError(ex, $"Error processing order: {order.Id}"); }

4. 检查NuGet包版本兼容性 #

Azure Functions 2.0基于.NET Core 2.x，要确保你引用的日志相关NuGet包版本兼容：

• Microsoft.Extensions.Logging
• Microsoft.Azure.WebJobs.Logging.ApplicationInsights
  建议把这些包升级到2.x系列的最新稳定版，旧版本可能存在日志采集的bug，导致堆栈跟踪丢失。

5. 本地调试验证 #

先在本地运行函数，看控制台输出里有没有显示完整的异常堆栈：

• 如果本地控制台能看到堆栈，说明问题出在App Insights的配置或采样上；
• 如果本地也看不到，那要检查你的异常是否被其他逻辑截断（比如被重新包装成新异常但没保留内部异常），不过从你的代码来看这种可能性不大。

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