Windows服务应用中Application Insights无法检测Service Bus依赖的解决方法及诊断思路咨询

我完全懂你现在的困扰——同样的Application Insights配置，在ASP.NET 4.6.2的API里能好好检测到Service Bus依赖，还能在Azure门户的应用地图里正常显示，结果放到Windows服务（控制台类型的）里就彻底失效了，偏偏其他依赖又能正常追踪，这真的挺闹心的。我结合经验给你整理几个可能的解决方向和诊断思路：

可能的解决方法 #

1. 补全DiagnosticSource的配置项 #

Application Insights的依赖收集模块是靠DiagnosticSource来追踪Service Bus操作的，你当前的配置里只加了Microsoft.Azure.EventHubs，但Service Bus对应了不同的DiagnosticSource名称，得根据你用的SDK版本补上：

• 如果你用的是新版Azure.Messaging.ServiceBus SDK，要在<IncludeDiagnosticSourceActivities>里加：<Add>Azure.Messaging.ServiceBus</Add>
• 如果你用的是旧版Microsoft.Azure.ServiceBus SDK，加：<Add>Microsoft.Azure.ServiceBus</Add>
• 如果你用的是更老的WindowsAzure.ServiceBus（针对.NET Framework的旧包），加：<Add>Microsoft.ServiceBus</Add>
  另外要确认你的Service Bus SDK版本支持DiagnosticSource，比如旧的WindowsAzure.ServiceBus至少要5.1.0以上版本才行。

2. 手动初始化依赖收集模块 #

ASP.NET应用会自动帮你初始化Application Insights的各种模块，但Windows服务/控制台应用是纯控制台程序，没有这套自动初始化机制，所以你得在程序启动时手动初始化DependencyTrackingTelemetryModule。
比如在服务启动的入口（Main方法或者服务的Start方法里）加这段代码：

using Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.DependencyCollector;
using Microsoft.ApplicationInsights.Extensibility;

// 初始化遥测配置
var telemetryConfig = TelemetryConfiguration.Active;
// 手动创建并初始化依赖收集模块
var dependencyModule = new DependencyTrackingTelemetryModule();
dependencyModule.Initialize(telemetryConfig);
// 确保TelemetryClient是全局单例，避免重复创建
var telemetryClient = new TelemetryClient(telemetryConfig);

要是你用了TopShelf这类Windows服务框架，记得把初始化代码放到服务的Start方法里，而不是只在Main里写（毕竟Main可能只是启动服务宿主）。

3. 检查是否有自定义过滤规则 #

排查下你的代码或者配置里有没有自定义的TelemetryProcessor，不小心把Service Bus的依赖遥测给过滤掉了。比如有没有类似这样的处理器：

public class FilterServiceBusProcessor : ITelemetryProcessor
{
    private ITelemetryProcessor _next;
    public FilterServiceBusProcessor(ITelemetryProcessor next) => _next = next;
    public void Process(ITelemetry item)
    {
        if (item is DependencyTelemetry dep && dep.Type == "Azure Service Bus")
        {
            return; // 直接过滤掉了Service Bus依赖
        }
        _next.Process(item);
    }
}

如果有的话，调整下逻辑，别把Service Bus的遥测给拦截了。

诊断排查思路 #

1. 启用AI的详细调试日志 #

你可以给Application Insights开启 verbose 级别的日志，看看依赖收集的具体过程，有没有报错或者遗漏的DiagnosticSource。
在你的App.config或者ApplicationInsights.config里加这段配置：

<system.diagnostics>
    <trace autoflush="true" />
    <sources>
        <source name="Microsoft.ApplicationInsights.DependencyCollector" switchName="aiDependencySwitch" switchType="System.Diagnostics.SourceSwitch">
            <listeners>
                <add name="aiTraceListener" type="System.Diagnostics.DefaultTraceListener" />
            </listeners>
        </source>
    </sources>
    <switches>
        <add name="aiDependencySwitch" value="Verbose" />
    </switches>
</system.diagnostics>

然后运行服务，用DebugView工具或者查看输出日志，搜索和Service Bus、DiagnosticSource相关的关键词，比如有没有看到“Processing event for DiagnosticSource: Azure.Messaging.ServiceBus”这类日志，或者有没有报错说找不到对应的DiagnosticSource。

2. 手动追踪Service Bus操作（临时方案） #

如果上面的方法都没效果，可以先手动用TelemetryClient来追踪Service Bus操作，既能验证AI的基础功能是否正常，也能临时解决依赖追踪的问题：

using (var operation = _telemetryClient.StartOperation<DependencyTelemetry>("Send Message", "Azure Service Bus", "你的队列/主题名称"))
{
    try
    {
        // 这里写你的Service Bus发送/接收代码
        await _sender.SendMessageAsync(message);
        operation.Telemetry.Success = true;
    }
    catch (Exception ex)
    {
        operation.Telemetry.Success = false;
        _telemetryClient.TrackException(ex);
        throw;
    }
    finally
    {
        _telemetryClient.StopOperation(operation);
    }
}

3. 检查AI NuGet包版本一致性 #

确保你Windows服务项目里所有Application Insights相关的NuGet包版本是统一的，比如Microsoft.ApplicationInsights、Microsoft.ApplicationInsights.DependencyCollector、Microsoft.ApplicationInsights.WindowsServer这些包的版本要完全一致，版本不匹配很容易出现兼容性问题，导致部分功能失效。

备注：内容来源于stack exchange，提问作者Andrej B.