Git Product home page Git Product logo

applicationinsights-servicefabric's Introduction

Microsoft Application Insights for Service Fabric

This repository hosts code for functionality that augments Application Insights telemetry experience for Service Fabric.

Problem Statement

Application Insights is a service that lets you monitor your live application's performance and usage. ApplicationInsight SDKs is a family of nuget packages that lets you collect and send telemetry from your applications. Information about SDKs for different platforms and languages is available at the Application Insights SDK page.

When the above mentioned SDKs collect application telemetry, they do not assume and record an application specific context because the context is environment specific. For microservices running inside service fabric, it is important to be able to recognize what service context the telemetry is generated in. For example request or dependency telemetry would not make sense without context information like service name, service type, instance / replica ids etc.

Solving the context problem

This repo provides code for a telemetry initializer (and some associated utility classes), shipped as nuget packages, specifically designed for Service Fabric. The initializer when used as described in the following sections, automatically augments telemetry collected by the different application insights SDKs that might be added to a service. For general information on Application Insights Telemetry Initializers follow this blog entry.

Nuget Packages

This repository produces the following two nuget packages:

Scope

  • This repository and the associated nuget packages, for now, only deals with .Net Framework and .Net Core applications.
  • The nuget packages does not auto-collect or generate any telemetry. It merely adds-to the telemetry generated by other sources - such as .Net Web SDK etc. or generated by the user directly.

Microsoft.ApplicationInsights.ServiceFabric- For Service Fabric Lift and Shift Scenarios

You can deploy almost any existing application to Service Fabric as either a guest executable or guest container service. These are also sometimes referred to as lift and shift applications. Add the Microsoft.ApplicationInsights.ServiceFabric nuget to your guest executable / container services.

.Net Framework

For.Net applications, applying the nuget package will automatically add the telemetry initializer to the ApplicationInsights.config file. The following sample shows the new entry added in context of other entries added by other AI SDK nugets.

<?xml version="1.0" encoding="utf-8"?>
<ApplicationInsights xmlns="http://schemas.microsoft.com/ApplicationInsights/2013/Settings">
  <InstrumentationKey>...</InstrumentationKey>
  <TelemetryInitializers>
    <Add Type="Microsoft.ApplicationInsights.DependencyCollector.HttpDependenciesParsingTelemetryInitializer, Microsoft.AI.DependencyCollector"/>

<!-- **************************************************************************************************************** -->
    <Add Type="Microsoft.ApplicationInsights.ServiceFabric.FabricTelemetryInitializer, Microsoft.AI.ServiceFabric"/>
<!-- **************************************************************************************************************** -->

  </TelemetryInitializers>
  <TelemetryModules>
    <Add Type="Microsoft.ApplicationInsights.DependencyCollector.DependencyTrackingTelemetryModule, Microsoft.AI.DependencyCollector" />
  </TelemetryModules>
</ApplicationInsights>

OWIN applications: Adding support to requests, dependencies and live stream

In order to have requests and dependencies showing in Application Insights Live Stream in OWIN applications there are a few additional steps required:

  1. Ensure the packages Microsoft.ApplicationInsights.PerfCounterCollector, Microsoft.ApplicationInsights.DependencyCollector and ApplicationInsights.OwinExtensions are installed
  2. Customize the ApplicationInsights.config file to include additional modules and the telemetry processor
<?xml version="1.0" encoding="utf-8"?>
<ApplicationInsights xmlns="http://schemas.microsoft.com/ApplicationInsights/2013/Settings">
  <InstrumentationKey>...</InstrumentationKey>
  <TelemetryInitializers>
    <Add Type="Microsoft.ApplicationInsights.ServiceFabric.FabricTelemetryInitializer, Microsoft.AI.ServiceFabric"/>      
    <Add Type="ApplicationInsights.OwinExtensions.OperationIdTelemetryInitializer, ApplicationInsights.OwinExtensions"/>
    <Add Type="Microsoft.ApplicationInsights.ServiceFabric.CodePackageVersionTelemetryInitializer, Microsoft.AI.ServiceFabric.Native"/>
  
    <!-- In order to collect dependencies include this and the nuget package Microsoft.ApplicationInsights.DependencyCollector -->
    <Add Type="Microsoft.ApplicationInsights.DependencyCollector.HttpDependenciesParsingTelemetryInitializer, Microsoft.AI.DependencyCollector"/>
  </TelemetryInitializers>
  <TelemetryModules>
    <!-- In order to collect dependencies include this and the nuget package Microsoft.ApplicationInsights.DependencyCollector -->
    <Add Type="Microsoft.ApplicationInsights.DependencyCollector.DependencyTrackingTelemetryModule, Microsoft.AI.DependencyCollector"/>    
    
    <!--  In order to collect performance/request information include this and the nuget package Microsoft.ApplicationInsights.PerfCounterCollector -->
    <Add Type="Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.PerformanceCollectorModule, Microsoft.AI.PerfCounterCollector"/>
    <Add Type="Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.QuickPulse.QuickPulseTelemetryModule, Microsoft.AI.PerfCounterCollector"/>    
  </TelemetryModules>
  <TelemetryProcessors>
    <!-- Adds support to live stream -->
    <Add Type="Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.QuickPulse.QuickPulseTelemetryProcessor, Microsoft.AI.PerfCounterCollector"/>
  </TelemetryProcessors>
</ApplicationInsights>

For more information check this post

.Net Core

The AI .Net Core SDK's configuration model is quite different from .Net framework's AI SDK. Almost all configuration for .NET Core is done in code. For example the AI SDK for ASP.net Core provides UseApplicationInsights() utility method that lets you set things up in code. When using the service fabric specific nuget package, simply make sure to register the ServiceFabricTelemetryInitializer through dependency injection before calling UseApplicationInsights() method as shown below:

public static void Main(string[] args)
{
    var host = new WebHostBuilder()
        .UseKestrel()
        
        // Adding Service Fabric Telemetry Initializer
        .ConfigureServices(services => services.AddSingleton<ITelemetryInitializer>((serviceProvider) => new FabricTelemetryInitializer()))
        
        .UseContentRoot(Directory.GetCurrentDirectory())
        .UseIISIntegration()
        .UseStartup<Startup>()

        // Configuring Application Insights
        .UseApplicationInsights()
        
        .Build();

    host.Run();
}

The nuget package reads the context from environment variables provided to the guest executable / guest container. The context added looks like the following:

Context fields for guest containers as shown on application insights portal

Microsoft.ApplicationInsights.ServiceFabric.Native - For Service Fabric Reliable Services

Using reliable services framework can give the user, among other things, super high resources density, where a single process may host multiple microservices or even multiple instances of a single service. This is different from lift and shift scenarios where likely a single container instance is running an instance of a single microservice. Microsoft.ApplciationInsights.ServiceFabric.Native relies on Microsoft.ApplicationInsights.ServiceFabric nuget but provides additional utility methods that let you propagate the context from the ServiceContext object to the telemetry initializer.

.Net Framework

Because Microsoft.ApplicationInsights.ServiceFabric.Native package installs the Microsoft.ApplicationInsights.ServiceFabric package as dependency, the telemetry initializer would already to registered in the ApplicationInsights.config file as described in the section for Microsoft.ApplicationInsights.ServiceFabric package above. In your service entry points, you should use the FabricTelemetryInitializerExtension.SetServiceCallContext(ServiceContext) provided by Microsoft.ApplicationInsights.ServiceFabric.Native package. This will make sure that desired context is retrieved from the ServiceContext object is propagated through all threads spawned from the service entry-point forth and is added to the outgoing telemetry.

protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
{
    FabricTelemetryInitializerExtension.SetServiceCallContext(this.Context);

    return new ServiceInstanceListener[]
    {
        new ServiceInstanceListener(serviceContext => new OwinCommunicationListener(Startup.ConfigureApp, serviceContext, ServiceEventSource.Current, "ServiceEndpoint"))
    };
}

-OR-

protected override Task RunAsync(CancellationToken cancellationToken)
{
    FabricTelemetryInitializerExtension.SetServiceCallContext(this.Context);

    return base.RunAsync(cancellationToken);
}

.Net Core

For .net Core, simply create the telemetry initializer using the FabricTelemetryInitializerExtension.CreateFabricTelemetryInitializer(ServiceContext)and register it as an ITelemetyInitializer for dependency injection before any calls that configure the applciation insights pipeline.

protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
{
    return new ServiceInstanceListener[]
    {
        new ServiceInstanceListener(serviceContext =>
            new WebListenerCommunicationListener(serviceContext, "ServiceEndpoint", url =>
            {
                ServiceEventSource.Current.ServiceMessage(serviceContext, $"Starting WebListener on {url}");

                return new WebHostBuilder().UseWebListener()
                            .ConfigureServices(
                                services => services
                                    .AddSingleton<StatelessServiceContext>(serviceContext)
                                    .AddSingleton<ITelemetryInitializer>((serviceProvider) => FabricTelemetryInitializerExtension.CreateFabricTelemetryInitializer(serviceContext)))
                            .UseContentRoot(Directory.GetCurrentDirectory())
                            .UseStartup<Startup>()
                            .UseApplicationInsights()
                            .UseUrls(url)
                            .Build();
            }))
    };

}

The context added looks like: Context fields for reliable services as shown on application insights portal

Note: Cloud role name and Cloud role instance shown in the screenshot above, represent service and service instance respectively, and are special fields in Application Insights schema that are used as aggregation units to power certain experiences like Application map.

Trace Correlation with Service Remoting

The Nuget package enables correlation of traces produced by Service Fabric services, regardless whether services communicate via HTTP or via Service Remoting protocol. For HttpClient, the correlation is supported implicitly. For Service Remoting, you just need to make some minor changes to your existing code and the correlation will be supported.

There is a difference in initialization depending on whether you are using Remoting V2 stack or not. You can follow this page to upgrade from Remoting V1 to Remoting V2.

Note: The V2 attribute name is different for Reliable Services and Actors. i.e., FabricTransportServiceRemotingProvider and FabricTransportActorRemotingProvider.

Remoting V2

Once you are using Remoting V2, you just need to add two more telemetry modules to your project.

For .Net Framework, the modules will be added automatically to the ApplicationInsights.config when you install the nuget package:

<TelemetryModules>
    <Add Type="Microsoft.ApplicationInsights.ServiceFabric.Module.ServiceRemotingRequestTrackingTelemetryModule, Microsoft.AI.ServiceFabric.Native"/>
    <Add Type="Microsoft.ApplicationInsights.ServiceFabric.Module.ServiceRemotingDependencyTrackingTelemetryModule, Microsoft.AI.ServiceFabric.Native"/>
</TelemetryModules>

For .Net Core, add the modules at the same place where you add the telemetry initializer:

ConfigureServices(services => services
    ...
    .AddSingleton<ITelemetryModule>(new ServiceRemotingDependencyTrackingTelemetryModule())
    .AddSingleton<ITelemetryModule>(new ServiceRemotingRequestTrackingTelemetryModule())
)

Remoting V1

If you want to stick to Remoting V1 stack, you can alternatively change your code to use the correlating proxy and message handler.

  1. For the service invoking the request, change how the proxy is created:
    // IStatelessBackendService proxy = ServiceProxy.Create<IStatelessBackendService>(new Uri(serviceUri));
    var proxyFactory = new CorrelatingServiceProxyFactory(this.serviceContext, callbackClient => new FabricTransportServiceRemotingClientFactory(callbackClient: callbackClient));
    IStatelessBackendService proxy = proxyFactory.CreateServiceProxy<IStatelessBackendService>(new Uri(serviceUri));
    
  2. For the service receiving the request, add a message handler to the service listener:
    protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
    {
        return new ServiceInstanceListener[1]
        {
            new ServiceInstanceListener(context => new FabricTransportServiceRemotingListener(context, new CorrelatingRemotingMessageHandler(context, this)))
        };
    }
    

Enrich telemetry with Component Version

In order to have telemetry enriched with component version based on the code package version of the Service Fabric Reliable Service, add the following xml snippet to the <TelemetryInitializers> section:

<Add Type="Microsoft.ApplicationInsights.ServiceFabric.CodePackageVersionTelemetryInitializer, Microsoft.AI.ServiceFabric.Native"/>

Adding component version to telemetry items makes it possible to track telemetry across different versions of running services.

Customizing Context:

< to be added >

Branches

  • master contains the latest published release located on NuGet.
  • develop contains code for the next release.

Contributing

Report Issues

Please file bugs, discussion or any other interesting topics in issues.

Developing

We strongly encourage contributions.
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

applicationinsights-servicefabric's People

Contributors

brahmnes avatar fbeltrao avatar lurock avatar microsoft-github-policy-service[bot] avatar microsoftopensource avatar mikanyg avatar msftgits avatar nizarq avatar xiaomi7732 avatar yantang-msft avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

applicationinsights-servicefabric's Issues

How to configure on stateless remoting v2 service

Hi,

Even reading the documentation i could not figure out where i have to configure the telemetry client to monitor my stateless project with remoting v2.

It don't have a WebHostBuilder to UseApplicationInsights() and services.AddApplicationInsightsTelemetry(chaveInstrumentacaoApplicationInsights);

please help me!

Thanks.

Exception telemetry on Connection Retries (Service Remoting)

We instrumented an Actor Proxy with CorrelatingActorProxyFactory. Whenever the Proxy Client does a retry (e.g. because the endpoint retrieved from the naming service is no longer valid), the following exception is traced to Application Insights, even though the remoting call was successful:

Error in Connection during ServiceCommunicationException from HRESULT: 0x80071C4C

We feel that moving processes around and doing retries is standard SF business and retries shouldnยดt show up as exception traces in AI. Thoughts ?

Thanks!

Full Stack Trace:

System.Fabric.FabricCannotConnectException:
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089)
at Microsoft.ServiceFabric.FabricTransport.Client.FabricTransportClient+d__9.MoveNext (Microsoft.ServiceFabric.FabricTransport, Version=6.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35)
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089)
at Microsoft.ServiceFabric.Services.Remoting.V1.FabricTransport.Client.FabricTransportServiceRemotingClient+<>c.<Microsoft.ServiceFabric.Services.Remoting.V1.Client.IServiceRemotingClient.RequestResponseAsync>b__29_0 (Microsoft.ServiceFabric.Services.Remoting, Version=6.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35)
at System.Threading.Tasks.ContinuationResultTaskFromResultTask2.InnerInvoke (mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089) at System.Threading.Tasks.Task.Execute (mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089) at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089) at Microsoft.ApplicationInsights.ServiceFabric.Remoting.Activities.CorrelatingServiceRemotingClient+<SendAndTrackRequestAsync>d__20.MoveNext (Microsoft.AI.ServiceFabric.Native, Version=2.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35) Inner exception System.Runtime.InteropServices.COMException handled at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw: at Microsoft.ServiceFabric.FabricTransport.NativeServiceCommunication+IFabricServiceCommunicationClient2.EndRequest (Microsoft.ServiceFabric.FabricTransport, Version=6.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35) at Microsoft.ServiceFabric.FabricTransport.Client.FabricTransportClient.EndRequest (Microsoft.ServiceFabric.FabricTransport, Version=6.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35) at System.Fabric.Interop.AsyncCallOutAdapter21.Finish (Microsoft.ServiceFabric.Internal, Version=6.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35)

Microsoft.ApplicationInsights.EventSourceListener for .net 4.5.1

We are in the process of upgrading some of our services and would like to use the new ServiceFabric ApplicationInsights integration. We are currently running .net framework 4.5.1. Is there any way we can get Microsoft.ApplicationInsights.EventSourceListener to run on .net 4.5.1?

If this is the wrong place to publish this please point me in the right direction.

[Question] Should I call SetServiceCallContext(ServiceContext) in multiple places?

I am using the Native package to enrich my application insights telemetry, but I have noticed that not all telemetry is enriched with details from the ServiceContext, set by the call FabricTelemetryInitializerExtension.SetServiceCallContext(ServiceContext) at startup in the SF Service class.

Many of our SF microservices use Owin based Web Api Contollers, RabbitMq message handlers and HangFire JobServers, all spawning their own threads, which leads me to think that I need to call the .SetServiceCallContext in more places than just the SF service class itself, to ensure that the CallContext for all threads have set the SF ServiceContext details to be picked up by Application Insights.

So should I call FabricTelemetryInitializerExtension.SetServiceCallContext(ServiceContext) multiple times?

Microsoft.ApplicationInsights.ServiceFabric.Native 2.1.1 causes version conflict on Microsoft.ServiceFabric.Diagnostics.Internal

When adding Microsoft.ApplicationInsights.ServiceFabric.Native 2.1.1 to a new Stateless Service I'm getting version conflicts which are listed below.

Note: I'm using the latest Service Fabric SDK 3.2.176

Error	NU1107	Version conflict detected for Microsoft.ServiceFabric.Diagnostics.Internal. Install/reference Microsoft.ServiceFabric.Diagnostics.Internal 3.2.176 directly to project Web1 to resolve this issue. 
 Web1 -> Microsoft.ServiceFabric.AspNetCore.Kestrel 3.2.176 -> Microsoft.ServiceFabric.AspNetCore.Abstractions 3.2.176 -> Microsoft.ServiceFabric.Services 3.2.176 -> Microsoft.ServiceFabric.Diagnostics.Internal (= 3.2.176) 
 Web1 -> Microsoft.ApplicationInsights.ServiceFabric.Native 2.1.1 -> Microsoft.ServiceFabric.Services.Remoting 3.0.467 -> Microsoft.ServiceFabric.Diagnostics.Internal (= 3.0.467).	Web1 C:\[pathtto.csproj] 1

Also getting a smaller dependency constraint as follows:

Warning	NU1608	Detected package version outside of dependency constraint: Microsoft.ServiceFabric.FabricTransport.Internal 3.0.467 requires Microsoft.ServiceFabric (= 6.1.467) but version Microsoft.ServiceFabric 6.3.176 was resolved.	Web1	C:\[pathtto.csproj]	1	

[Proposal] Add support for automatic telemetry (request and dependency) collection for service remoting

Application Insights already has pretty good support for http based service communication. That is, application insights modules can automatically intercept http based communication and generate request and dependency telemetry.

In Service Fabric, however, it is pretty common for services to communicate over Service Remoting. The proposal is to add automatic AI telemetry collection of service remoting stack as well.

FabricElementAlreadyExistsException thrown when calling a stateful service

When using the CorrelatingServiceProxyFactory quite often an FabricElementAlreadyExistsException is thrown.

This has happened during a period of idleness, but can be more easily reproduce by disabling a node and calling the service when it is disabled.

I am not sure exactly which line is throwing the exception but this is an example of us calling one of the services.
var partitionKey = new ServicePartitionKey(partitionId);
var proxyFactory = new CorrelatingServiceProxyFactory(m_context, callbackClient => new FabricTransportServiceRemotingClientFactory(callbackClient: callbackClient));
var userManager = proxyFactory.CreateServiceProxy(new Uri("fabric:/EILicenceServer/EIUserManager"), partitionKey);

Exception thrown is:
System.Fabric.FabricElementAlreadyExistsException: Header with name 'ParentId' already exists
at Microsoft.ServiceFabric.Services.Communication.Client.ServicePartitionClient1.<InvokeWithRetryAsync>d__231.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.ServiceFabric.Services.Remoting.Client.ServiceRemotingPartitionClient.d__2.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.ServiceFabric.Services.Remoting.Builder.ProxyBase.d__2.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.ServiceFabric.Services.Remoting.Builder.ProxyBase.d__31.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at EIAuthentication.Controllers.AuthenticationController.<ProcessConcurrencyDuringTokenRenewal>d__29.MoveNext()>",Edm.String,00000000-0000-0000-0000-000000000000,Edm.String,00000000-0000-0000-0000-000000000000,Edm.String,"serviceName=""fabric:/EILicenceServer/EIAuthentication"" serviceTypeName=""EIAuthenticationType"" replicaOrInstanceId=""131537878261862086"" partitionId=""9b523030-c84b-44c7-ab04-8d615a09a0f7"" applicationName=""fabric:/EILicenceServer"" applicationTypeName=""EILicenceServerType"" nodeName=""_nt1vm_1"" message=""AuthenticationController - ProcessConcurrencyDuringTokenRenewal: user:<sip:[email protected]> exception:<System.Fabric.FabricElementAlreadyExistsException: Header with name 'ParentId' already exists at Microsoft.ServiceFabric.Services.Communication.Client.ServicePartitionClient1.d__231.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.ServiceFabric.Services.Remoting.Client.ServiceRemotingPartitionClient.<InvokeAsync>d__2.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.ServiceFabric.Services.Remoting.Builder.ProxyBase.<InvokeAsync>d__2.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.ServiceFabric.Services.Remoting.Builder.ProxyBase.<ContinueWithResult>d__31.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at EIAuthentication.Controllers.AuthenticationController.d__29.MoveNext()>""",Edm.String,636449114244152530,Edm.Int64,0000008800388303185,Edm.String,2017-10-29T22:00:00.000Z,Edm.DateTime

Service Remoting v2 Support

It seems CorrelatingServiceProxyFactory and CorrelationgActorProxyFactory support only Service Remoting V1. What are the plans to support Service Remoting v2 in addition to Remoting v1 ?

Add Live Stream support to OWIN based Services

In OWIN based web application requests will not show up in the Application Insights Live Stream.
A solution to this problem is to use a QuickPulseTelemetryModule on the application like this post describes

Ideally this should be built-in, or at least have a reference implementation in this repository.

SF Context Variables not applied to dependent service

I am utilizing the Microsoft.ApplicationInsights.ServiceFabric.Native (2.1.1-beta1) package in my Service Fabric application mostly to great success. I have one particular service, however, that does not seem to be populating the SF context properties correctly.

The situation is essentially when Service A is making a remoting (V2) call to Service B which is a StatefulService.

On the Service A side, a dependency telemetry is tracked as expected with all of the service fabric context properties populated correctly.

On the Service B side a request is indeed tracked and is correlated to the same operation as the dependency in Service A, however, all of the additional context properties for Service B are not being populated. In fact, the only one populated is ServiceFabric.NodeName. Additionally, the cloud role name does not display the name of the service, but instead that of the code package. The cloud role instance also displays the hostname of the node rather than the service instance.

In terms of config and initialization, I am setting the call context as instructed:

        protected override IEnumerable<ServiceReplicaListener> CreateServiceReplicaListeners()
        {
            FabricTelemetryInitializerExtension.SetServiceCallContext(Context);
            return this.CreateServiceRemotingReplicaListeners();
        }

The service is using V2 remoting:

[assembly: FabricTransportServiceRemotingProvider(RemotingListener = RemotingListener.V2Listener, RemotingClient = RemotingClient.V2Client)]

And my application insights config looks as such:

<?xml version="1.0" encoding="utf-8"?>
<ApplicationInsights xmlns="http://schemas.microsoft.com/ApplicationInsights/2013/Settings">
  <TelemetryInitializers>
    <Add Type="Microsoft.ApplicationInsights.DependencyCollector.HttpDependenciesParsingTelemetryInitializer, Microsoft.AI.DependencyCollector"/>
    <Add Type="Microsoft.ApplicationInsights.ServiceFabric.FabricTelemetryInitializer, Microsoft.AI.ServiceFabric"/>
    <Add Type="Microsoft.ApplicationInsights.ServiceFabric.CodePackageVersionTelemetryInitializer, Microsoft.AI.ServiceFabric.Native"/>
  </TelemetryInitializers>
  <TelemetryModules>
    <Add Type="Microsoft.ApplicationInsights.DependencyCollector.DependencyTrackingTelemetryModule, Microsoft.AI.DependencyCollector">
      <ExcludeComponentCorrelationHttpHeadersOnDomains>
        <!-- 
        Requests to the following hostnames will not be modified by adding correlation headers. 
        This is only applicable if Profiler is installed via either StatusMonitor or Azure Extension.
        Add entries here to exclude additional hostnames.
        NOTE: this configuration will be lost upon NuGet upgrade.
        -->
        <Add>core.windows.net</Add>
        <Add>core.chinacloudapi.cn</Add>
        <Add>core.cloudapi.de</Add>
        <Add>core.usgovcloudapi.net</Add>
      </ExcludeComponentCorrelationHttpHeadersOnDomains>
    </Add>
    <Add Type="Microsoft.ApplicationInsights.ServiceFabric.Module.ServiceRemotingRequestTrackingTelemetryModule, Microsoft.AI.ServiceFabric.Native"/>
    <Add Type="Microsoft.ApplicationInsights.ServiceFabric.Module.ServiceRemotingDependencyTrackingTelemetryModule, Microsoft.AI.ServiceFabric.Native"/>
  </TelemetryModules>
</ApplicationInsights>

Any thoughts as to why the context fields are not being populated as expected? Am I doing anything wrong?

Service Remoting correlation is not fully working with AppInsights when send to multiple ikeys

I tested this PR #51, and the correlation is not fully working when sending to multiple ikeys.
I'm using this project for testing: https://github.com/yantang-msft/service-fabric-dotnet-getting-started/tree/TestRemoting.
More specifically

  1. the request telemetry of stateless service doesn't have the source component name.
  2. the dependency telemetry from actor services doesn't have the target component appId appended.
    This could be timing issue when the sdk is still fetching the componentIds. But need further investigation.

Service Remoting Trace Correlation using Actors

I am trying to get the service remoting correlation to work using actors.
Following the instructions of the README.md it should be straight forward, but of course there are subtle differences when using Actors instead of stateless services.

On the client side I create a proxy as follows:

string actorUrl = "fabric:/MyApp/MyActor";
Guid id = Guid.NewGuid();
var proxyFactory = new CorrelatingActorProxyFactory(null, callbackClient => new 
FabricTransportServiceRemotingClientFactory(callbackClient: callbackClient));
return proxyFactory.CreateActorProxy<TReadModelBuilder>(new Uri(actorUrl), new ActorId(id));	

On the Actor side I have an "AiActorService" class that overrides CreateServiceReplicatListeners as follows:

protected override IEnumerable<ServiceReplicaListener> CreateServiceReplicaListeners()
{
	var transportSettings = new FabricTransportRemotingListenerSettings
	{
		EndpointResourceName = "MyActorServiceEndpoint",
	};

	var result = new ServiceReplicaListener[1]
	{
		new ServiceReplicaListener(context => new FabricTransportActorServiceRemotingListener(context, new CorrelatingRemotingMessageHandler(context, this), transportSettings))
	};
	return result;
}

However when using the proxy, i get an exception saying "Interface id {id} is not implemented by object {proxy}"

Now looking at the replica listener the {id} does not correspond with the interface Id I find in the exception, so obviously something is wrong. But reverting back to the "default listener" (i.e. removing the AiActorService and just using the plain old ordinary actor service) everything works just fine.

Either there is something I am doing wrong because I don't understand what i am doing, or there is an issue with listener/proxy implementation.

Anyone who have got this working, or otherwise might be able to shed some light on this is appreciated.

[Proposal] TelemetryInitializer to set Component.Version from CodePackageVersion

I suggest to add a TelemetryInitializer that sets the ITelemetry.Context.Component.Version based on the CodePackageVersion.

Very simple version:

public class ServiceFabricComponentVersionTelemetryInitializer : ITelemetryInitializer
{
public void Initialize(ITelemetry telemetry)
{
var activationContext = FabricRuntime.GetActivationContext();
telemetry.Context.Component.Version = activationContext.CodePackageVersion;
}
}

Could you please show project examples?

Could you please show examples for Stateless WebApi and Remoting?
So with this AI Sdk, I don't have to setup ServiceEventSource anymore, and just create TelemetryClient singleton instead, correct?

Accessing the current request telemetry object created via the Service Bus

We have a Service Fabric Stateless Service running .NET Core (not ASP.NET). It's sole purpose is to process data in the background when a Service Bus message is received. We are using the latest SDK of the Service Bus and Application Insights and following the Message Handler Pattern. This works like a charm with Insights as it automagically creates a request when a message is received and correlates all Exceptions, Traces, and Dependency calls with the same request. Kudos to the team for that.

Now we want to be able to change the Success and ResponseCode of the underlying RequestTelemetry object if an Exception is thrown or with our business rules. How do we do that?

Fabric telemetry data is not available in destination service.

Assuming we have two services A and B, both with OwinCommunicationListener and FabricTransportServiceRemotingListener with CorrelatingRemotingMessageHandler in place, when calling service A using REST which in turn calls service B using internal fabric communication then correlation data is propagated correctly but service fabric data (I mean ServiceName, ApplicationName. I know that RoleInstance and RoleName is taken from environment) is missing in telemetry requests created in CorrelatingRemotingMessageHandler in service B, even though FabricTelemetryInitializer is configured correctly and FabricTelemetryInitializerExtension is called in CreateServiceInstanceListeners method in both services. It does work in service A. Is it on purpose or is it an issue?

Timeline for non-preview release

Hi there, just want to know what the roadmap & timeline is for this package. What needs to be done before a non-preview nuget can be released?

Could not load file or assembly 'Microsoft.AI.ServiceFabric.Native, Version=2.1.0.0, Culture=neutral, PublicKeyToken=f23a46de0be5d6f3' or one of its dependencies.

Hey,
I'm getting an error when trying to use Microsoft.AI.ServiceFabric.Native in a .NET Framework service. My .NET Core services are working just fine.

Here is the error:

System.IO.FileLoadException
HResult=0x80131040
Message=Could not load file or assembly 'Microsoft.AI.ServiceFabric.Native, Version=2.1.0.0, Culture=neutral, PublicKeyToken=f23a46de0be5d6f3' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Source=Microsoft.Intentional.Services.Utilities.ServiceFabric
StackTrace:
at Microsoft.Intentional.Services.Utilities.ServiceFabric.Logging.ServiceRemotingDependencyExtensions.AddServiceRemotingTelemetry(IServiceCollection services)
at Microsoft.Intentional.Services.Shared.IntentionalWebHostBuilder.<>c__DisplayClass0_0`1.b__2(IServiceCollection services) in C:\Users\joschm\Intentional\services\src\IntentionalServices.Shared\IntentionalWebHostBuilder.cs:line 47

Here is the FusionLog:

=== Pre-bind state information ===
LOG: DisplayName = Microsoft.AI.ServiceFabric.Native, Version=2.1.0.0, Culture=neutral, PublicKeyToken=f23a46de0be5d6f3
(Fully-specified)
LOG: Appbase = file:///C:/SfDevCluster/Data/_App/_Node_0/IntentionalServicesType_App2/ContentValidationServicePkg.Code.1.0.0/
LOG: Initial PrivatePath = NULL
Calling assembly : Microsoft.Intentional.Services.Utilities.ServiceFabric, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\SfDevCluster\Data_App_Node_0\IntentionalServicesType_App2\ContentValidationServicePkg.Code.1.0.0\ContentValidationService.exe.Config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Post-policy reference: Microsoft.AI.ServiceFabric.Native, Version=2.1.0.0, Culture=neutral, PublicKeyToken=f23a46de0be5d6f3
LOG: Attempting download of new URL file:///C:/SfDevCluster/Data/_App/_Node_0/IntentionalServicesType_App2/ContentValidationServicePkg.Code.1.0.0/Microsoft.AI.ServiceFabric.Native.DLL.
WRN: Comparing the assembly name resulted in the mismatch: PUBLIC KEY TOKEN
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

If I look in the pacakge folder, I see the following AI DLLs:

.NET Framework Service (which is not working):

ProductVersion FileVersion FileName
2.4.0.105563 2.4.0.105563 C:\Users\joschm\Intentional\services\src\IntentionalServices\pkg\Debug\ContentValidationServicePkg\Code\Microsoft.AI.Agent.Intercept.dll
2.5.1.195 2.5.1.195 C:\Users\joschm\Intentional\services\src\IntentionalServices\pkg\Debug\ContentValidationServicePkg\Code\Microsoft.AI.DependencyCollector.dll
2.5.1.195 2.5.1.195 C:\Users\joschm\Intentional\services\src\IntentionalServices\pkg\Debug\ContentValidationServicePkg\Code\Microsoft.AI.PerfCounterCollector.dll
2.5.1.172 2.5.1.172 C:\Users\joschm\Intentional\services\src\IntentionalServices\pkg\Debug\ContentValidationServicePkg\Code\Microsoft.AI.ServerTelemetryChannel.dll
2.1.0.140 2.1.0.140 C:\Users\joschm\Intentional\services\src\IntentionalServices\pkg\Debug\ContentValidationServicePkg\Code\Microsoft.AI.ServiceFabric.dll
2.1.0.140 2.1.0.140 C:\Users\joschm\Intentional\services\src\IntentionalServices\pkg\Debug\ContentValidationServicePkg\Code\Microsoft.AI.ServiceFabric.Native.dll

.NET Core Service (which is working):

ProductVersion FileVersion FileName
2.5.1 2.5.1.195 C:\Users\joschm\Intentional\services\src\IntentionalServices\pkg\Debug\ContentServiceFrontendPkg\Code\Microsoft.AI.DependencyCollector.dll
2.5.1 2.5.1.195 C:\Users\joschm\Intentional\services\src\IntentionalServices\pkg\Debug\ContentServiceFrontendPkg\Code\Microsoft.AI.PerfCounterCollector.dll
2.5.1.172 2.5.1.172 C:\Users\joschm\Intentional\services\src\IntentionalServices\pkg\Debug\ContentServiceFrontendPkg\Code\Microsoft.AI.ServerTelemetryChannel.dll
1.0.0 2.1.0.140 C:\Users\joschm\Intentional\services\src\IntentionalServices\pkg\Debug\ContentServiceFrontendPkg\Code\Microsoft.AI.ServiceFabric.dll
1.0.0 2.1.0.140 C:\Users\joschm\Intentional\services\src\IntentionalServices\pkg\Debug\ContentServiceFrontendPkg\Code\Microsoft.AI.ServiceFabric.Native.dll

So the big different I see here is the ProductVersion - is that wrong?

ExclusiveProcess tracing of remote calls does not pass operationId

Hi
we have a setup with several services that all live in their separate processes (ExclusiveProcess) and they communicate using remoting V1. I have used the setup described but can't get the operationId passed to the service being called. I log the operationId from the caller and then from callee - it comes as some hashed value. Are we going to be happy with this, or exclusive processes are not supported?

I do:
traces | project timestamp, message, operation_Id | top 40 by timestamp desc

and see:

2018-05-16T10:17:08.860	Stateful1 is running: HelloWorld: Param=2018-05-16 12:17:08 - 122	P1TwdX7esgk=	
2018-05-16T10:17:08.854	Stateless1 is running: 122	2018-05-16 12:17:08 - 122	
2018-05-16T10:17:03.845	Stateful1 is running: HelloWorld: Param=2018-05-16 12:17:03 - 121	T3iCzQ4FoAs=	
2018-05-16T10:17:03.840	Stateless1 is running: 121	2018-05-16 12:17:03 - 121	
2018-05-16T10:16:58.825	Stateful1 is running: HelloWorld: Param=2018-05-16 12:16:58 - 120	sFtv6Fsv1No=	
2018-05-16T10:16:58.821	Stateless1 is running: 120	2018-05-16 12:16:58 - 120	
2018-05-16T10:16:53.812	Stateful1 is running: HelloWorld: Param=2018-05-16 12:16:53 - 119	uNxyYsZeLuU=	
2018-05-16T10:16:53.808	Stateless1 is running: 119	2018-05-16 12:16:53 - 119	

every 'hashy' value of operationId should be the one from the Stateless1 that makes the call.
Thanks
Maciej

CorrelationServiceRemotingClient and listener don't resolve method name at all causing telemetry operation name being always 0.

Hi, there is a bug in resolving correct operation name both in client and listener. Operation name should be a calling method name but it's always 0 instead. The reason for that is invalid type name string in ctor in class ServiceRemotingMessageHeadersExtensions. Line 24.

Type actorMessageHeadersType = typeof(ActorMethodDispatcherBase).Assembly.GetType("Microsoft.ServiceFabric.Actors.Remoting.ActorMessageHeaders");

Turns out ActorMessageHeaders class is in different namespace Microsoft.ServiceFabric.Actors.Remoting.V1

https://github.com/Microsoft/service-fabric-services-and-actors-dotnet/blob/97dff2cc2efc022c69363073881d6a92e8c5462c/src/Microsoft.ServiceFabric.Actors/Remoting/V1/ActorMessageHeaders.cs

Adding 'V1' does the trick.

Need documentation on integrating AI config file with SF config API

I am unable to figure out whether the applicationinsights.config should be placed in project root or in the PackageRoot\Config folder, as it should be when using Microsoft.Diagnostics.EventFlow.Outputs.ApplicationInsights

I need to load the content of applicationinsights.config on startup and set it as the default configuration for all TelemetryClient instances used in SF services.

Unable to reproduce sample from documentation

Dear team, I've repeated all steps from "Monitor and diagnose an ASP.NET Core application on Service Fabric" till the paragraph "View telemetry and the App map in Application Insights". As described in documentation at the step I should see events in Azure Application Insight. Unfortunately, I didn't see anything.
Debug output window shows following messages:
Application Insights Telemetry (unconfigured): {"name":"Microsoft.ApplicationInsights.Dev.Request","time":"2017-11-29T08:55:26.8391314Z","tags":{"ai.application.ver":"1.0.0.0","ai.cloud.role":"fabric:/Voting/VotingData","ai.cloud.roleInstance":"131564192630191563","ai.operation.id":"17993589-47f0a8360afffd48","ai.operation.name":"GET VoteData/Get","ai.location.ip":"::1","ai.internal.sdkVersion":"aspnet5f:2.2.0-beta1","ai.internal.nodeName":"XXXXXX.XXXXXX.local"},"data":{"baseType":"RequestData","baseData":{"ver":2,"id":"|17993589-47f0a8360afffd48.","name":"GET VoteData/Get","duration":"00:00:00.1632013","success":true,"responseCode":"200","url":"http://localhost:53576/c27e2db5-828a-4a69-b69d-7ba70c1eacce/131564192630191563/c11387c2-1aee-4ffa-b91b-f2e1c1029541/api/VoteData","properties":{"ServiceFabric.ServiceName":"fabric:/Voting/VotingData","ServiceFabric.ApplicationTypeName":"VotingType","ServiceFabric.ServiceTypeName":"VotingDataType","ServiceFabric.PartitionId":"c27e2db5-828a-4a69-b69d-7ba70c1eacce","httpMethod":"GET","ServiceFabric.ApplicationName":"fabric:/Voting","ServiceFabric.ReplicaId":"131564192630191563","AspNetCoreEnvironment":"Development","DeveloperMode":"true","ServiceFabric.NodeName":"_Node_0"}}}} Microsoft.AspNetCore.Mvc.Formatters.Json.Internal.JsonResultExecutor: Information: Executing JsonResult, writing value System.Collections.Generic.List1[System.Collections.Generic.KeyValuePair2[System.String,System.Int32]]. Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker: Information: Executed action VotingWeb.Controllers.VotesController.Get (VotingWeb) in 262.2165ms Microsoft.AspNetCore.Hosting.Internal.WebHost: Information: Request finished in 288.6173ms 200 application/json; charset=utf-8 Exception thrown: 'System.IO.IOException' in mscorlib.dll 'VotingData.exe' (CLR v4.0.30319: VotingData.exe): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.resources\v4.0_4.0.0.0_ru_b77a5c561934e089\System.resources.dll'. Module was built without symbols. Exception thrown: 'System.InvalidOperationException' in System.dll Exception thrown: 'System.InvalidOperationException' in System.dll Exception thrown: 'System.InvalidOperationException' in Microsoft.AI.PerfCounterCollector.dll Exception thrown: 'System.InvalidOperationException' in Microsoft.AI.PerfCounterCollector.dll Exception thrown: 'System.InvalidOperationException' in System.dll Exception thrown: 'System.NullReferenceException' in Microsoft.AI.PerfCounterCollector.dll Exception thrown: 'System.InvalidOperationException' in Microsoft.AI.PerfCounterCollector.dll Exception thrown: 'System.InvalidOperationException' in System.dll
What am I doing wrong?
Repository with sample you can see here.

P.S. I have to hide pc and domain name with XXXXXX.XXXXXX.local

Disable unnecessary performance counters in default configuration

Moved from https://github.com/Microsoft/ApplicationInsights-Home/issues/166

Originally reported by @Eneuman

We have a project containing 12 Service Fabric applications and 40 services running on 5 servers.
Using the default setup for Application Insights results in 200 services sending the same performance telemetry, like server CPU and server avail mem, to AI witch uses up all of our AI storage.
All services are using .Net Core 2.
We need to reduce the amount of performance data that gets transmitted to AI, but all exceptions (with stacktraces) and requests must be send.
Can this be done and in that case; what is the recommended way of handeling this?
We would like to see the following performance data in AI:

  • CPU load of each server
  • CPU load of each service
  • Avail mem of each server
  • Used mem for each service

Using this with Actors & Service Bus

I'm having trouble getting this to work well with actors and service bus. Is there any guidance as to how we should get this information added to our telemetry when logging events from within an actor instance or a message handler?

Service Remoting emitted performance counters are not easy to collect using WAD2AI

Service Remoting emits performanc counters like below:

Category name Counter name Description
Service Fabric Service # of outstanding requests Number of requests being processed in the service
Service Fabric Service Average milliseconds per request Time taken (in milliseconds) by the service to process a request
Service Fabric Service Average milliseconds for request deserialization Time taken (in milliseconds) to deserialize service request message when it is received at the service
Service Fabric Service Average milliseconds for response serialization Time taken (in milliseconds) to serialize the service response message at the service before the response is sent to the client

The best way to collect these counters using WAD is using wildcards e.g.,

"counterSpecifier": "\\Service Fabric Service(*)\\Average milliseconds per request",

However, counters containing wildcards are not picked up by WAD2AI. As it is unrealistic to expect customers to know in advance all the services that might run on a service fabric node (as opposed to PaaS V1), it is unrealistic to ask them to mitigate the situation by explicitly spelling out all possible values at configuration time. WAD2AI should start supporting performance counters with wildcards.

Service Fabric Version Dependency

Looking to add the Native package to our .Net Core Web API, dependency says >= SF 3.0.467 and our project is using 3.2.176. Got conflict error below, then did as suggested (install Microsoft.ServiceFabric.Diagnostics.Internal 3.2.176 directly) but now have warnings about versions, am I supposed to just ignore the errors?

Initial Error trying to Add..
Version conflict detected for Microsoft.ServiceFabric.Diagnostics.Internal. Install/reference Microsoft.ServiceFabric.Diagnostics.Internal 3.2.176 directly to project WebAPI to resolve this issue.
WebAPI -> Microsoft.ServiceFabric.Services 3.2.176 -> Microsoft.ServiceFabric.Diagnostics.Internal (= 3.2.176)
WebAPI -> Microsoft.ApplicationInsights.ServiceFabric.Native 2.1.1 -> Microsoft.ServiceFabric.Services.Remoting 3.0.467 -> Microsoft.ServiceFabric.Diagnostics.Internal (= 3.0.467).

Now get Warnings...
Detected package version outside of dependency constraint: Microsoft.ServiceFabric.Services.Remoting 3.0.467 requires Microsoft.ServiceFabric.Services (= 3.0.467) but version Microsoft.ServiceFabric.Services 3.2.176 was resolved.

Operation to stop does not match the current operation.

I'm getting an error using the Service Remoting telemetry.
It appears that the operation that is being stopped is invalid:

"message": "AI (Internal): Operation to stop does not match the current operation. Details: Telemetry Id '|1cafaa09-478a33c4492e47c3.a2a37cb4_' does not match current Activity '|1cafaa09-478a33c4492e47c3.a2a37cb4_1.'",

It looks like Application Insights is trying to stop a2a37cb4_ but it's currently running activity a2a37cb4_1. Notice the 1 at the end.

Any ideas why this would be happening?
I'm using 2.1.1-beta1

Support for .Net Core 2?

What is the plan for releasing a nuget package supporting the new .Net 2.0 Core templates in ServiceFabric Tools 2.0 preview?

Using Application Insights with Service Fabric V1 remoting causes request tracking failure

Version: 2.1.0-beta1

Stack Trace:

System.NullReferenceException:

   at Microsoft.ApplicationInsights.ServiceFabric.Module.RequestTrackingUtils.GetBaggageFromActivity (Microsoft.AI.ServiceFabric.Native, Version=2.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35)

   at Microsoft.ApplicationInsights.ServiceFabric.Remoting.Activities.CorrelatingServiceRemotingClient+<SendAndTrackRequestAsync>d__19.MoveNext (Microsoft.AI.ServiceFabric.Native, Version=2.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35)

Repeatability: Every time, consistently when using V1 remoting with instructions provided in readme.md with Full Framework Stateless service.

MessageHandler for Actors?

Brilliant piece of code, thank you. I can't figure out though how to initialise message handler for Actors on server side. The client is passing the headers, however where do I place the code in Actor implementation to pick them up similar to CreateServiceInstanceListeners() in reliable services?

Unable to install Microsoft.ApplicationInsights.ServiceFabric.Native package

I try to install the Microsoft.ApplicationInsights.ServiceFabric.Native package to .NET 4.7.1 Stateless application without any success. I have following error

NU1608: Detected package version outside of dependency constraint: Microsoft.ServiceFabric.Services.Remoting 3.0.467 requires Microsoft.ServiceFabric.Services (= 3.0.467) but version Microsoft.ServiceFabric.Services 3.2.162 was resolved.
NU1608: Detected package version outside of dependency constraint: Microsoft.ServiceFabric.FabricTransport.Internal 3.0.467 requires Microsoft.ServiceFabric (= 6.1.467) but version Microsoft.ServiceFabric 6.3.162 was resolved.
NU1107: Version conflict detected for Microsoft.ServiceFabric.Diagnostics.Internal. Reference the package directly from the project to resolve this issue. 
 Test.Server.Host.ServiceFabric -> Microsoft.ServiceFabric.Services 3.2.162 -> Microsoft.ServiceFabric.Diagnostics.Internal (= 3.2.162) 
 Test.Server.Host.ServiceFabric -> Microsoft.ApplicationInsights.ServiceFabric.Native 2.1.1 -> Microsoft.ServiceFabric.Services.Remoting 3.0.467 -> Microsoft.ServiceFabric.Diagnostics.Internal (= 3.0.467).
Package restore failed. Rolling back package changes for 'Test.Server.Host.ServiceFabric'.

Dependencies not being tracked

We have a stateless service that is running some background process when a service bus message is received. We are referencing Microsoft.ApplicationInsights.ServiceFabric.Native 2.1.1 nuget package.

In the constructor of the StatelessService we are setting the insights key and initializing the telemetry as follows:

var telemetryConfig = TelemetryConfiguration.Active;
telemetryConfig.InstrumentationKey = key;
abricTelemetryInitializerExtension.CreateFabricTelemetryInitializer(context);

We want to track every new message as a request, so when we process the message we create a new RequestTelemetry:

public RequestTelemetry StartRequest(string name)
 {
   var request = new RequestTelemetry { Name = name, Timestamp = DateTime.UtcNow };
   return request;
}

We then Trace the request at the end:

public void TraceRequest(RequestTelemetry request, bool success, string responseCode = null)
{
  request.Duration = DateTime.UtcNow - request.Timestamp;
  request.Success = success;
  request.ResponseCode = responseCode ?? (success ? "200" : "500");
  _client.TrackRequest(request);
 }

In between there are 3 dependecy calls: 1 to SQL Azure, another to Postgres, and the last one to Azure Search Services.

We do see the request on the VS Application Insights tab, but we do not see any dependencies related to the requests or by themselves.

Are we missing any configuration?

[Bug] Service Remoting dependencies displayed differently in App Map between ASP.NET Core and non-ASP.NET Core services

I'm a big fan of using the Application map to identify the dependencies between my Service Fabric microservices, but one of the biggest quirks to it that I've identified is the disconnect between non-ASP.NET Core services and their various dependency calls between ASP.NET Core and non-ASP.NET Core services. Specifically, call from an ASP.NET Core service to another non-ASP.NET Core service will show up as a dependency between App.ServiceA and App.ServiceB, but a similar call between two non-ASP.NET Core services will show up as a call from App.ServiceB to fabric:/App/ServiceC, but App.Service will show up elsewhere on the graph (attached to App.ServiceA since there are other calls made directly to it from A).

To illustrate my point, I've attached a sanitized sample of my application map:

image

In this example, I have three services running:

  • App.ServiceA is an ASP.NET Core application running as a stateless service
  • App.ServiceB is stateless service (notably not running ASP.NET Core, but utilizing Service Fabric Remoting for inter-service communication)
  • App.ServiceC is a stateful service (again, not running ASP.NET Core, but utilizing Service Fabric Remoting for communication)

I have two methods that will come into the API controller in ServiceA. One of them will make a call to App.ServiceB (via remoting) which will, in turn, make a call to ServiceC and return the results. The other method will directly call ServiceC and return those results.

Expected:
Just as App.ServiceA is directly connected to App.ServiceB and App.ServiceC in the above image, I'd expect to see App.ServiceB directly connected to App.ServiceC with a one-way arrow instead of this arbitrary dead-end dependency call to fabric:/App/ServiceC (as though App.ServiceC and fabric:App/ServiceC aren't the same thing, which they are).

Thanks!

Update nuspecs before the next release

Although we can hand editing some of the package info in nuget.org, it will save time in the long run to make the info accurate in nuget spec files. Could you please update the info there?

Microsoft.ApplicationInsights.ServiceFabric.FabricTelemetryInitializer exists in multiple assemblies

Microsoft.ApplicationInsights.ServiceFabric.FabricTelemetryInitializer is available in the following assemblies.
Microsoft.AI.ServiceFabric.Native
Microsoft.AI.ServiceFabric

Since Microsoft.ApplicationInsights.ServiceFabric.Native has dependency to Microsoft.ApplicationInsights.ServiceFabric both the assemblies above are included when Microsoft.ApplicationInsights.ServiceFabric.Native is added to a project.

This results in the following error

The type 'FabricTelemetryInitializer' exists in both 'Microsoft.AI.ServiceFabric.Native, Version=2.1.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' and 'Microsoft.AI.ServiceFabric, Version=2.1.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.