Live Metrics Stream not working even after updating to latest AI dlls to support live streams about orchard-azure-application-insights

[Piedone]

It seems to me that the only reason Live Metrics Stream is not working with the module currently is that is uses an older version of the SDK and it needs version > 2.1.0 of Microsoft.ApplicationInsights.Web. I just updated the packages and added Microsoft.ApplicationInsights.Web as a test too, however the live stream feature is not working. I suppose this is not a surprise because simply addig the package is not enough, there's something else needed.

On a related note adding Microsoft.ApplicationInsights.Web makes a lot of TelementryInitializers and Modules available, so worth thinking about adding it.

@SergeyKanzhelev you know about the Orchard module that allows easy AI integration into Orchard CMS. Do you have any insights on what should be done to hook up live stream manually?

[SergeyKanzhelev]

1. Install the Microsoft.ApplicationInsights.PerfCounterCollector nugget
2. Add telemetry processor Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.QuickPulse.QuickPulseTelemetryProcessor, Microsoft.AI.PerfCounterCollector
3. Initialize module Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.QuickPulse.QuickPulseTelemetryModule, Microsoft.AI.PerfCounterCollector
   Make sure you initialized those on the same instance of TelemetryConfiguration.

Done.

You'll need to update to 2.1 of Application Insights

[Piedone]

Thank you Sergey. I did this and indeed data is now collected. However not everything: memory and CPU works, however the other graphs remain flat:

It's strange because otherwise those types of data (requests, dependencies) are properly collected and appear under Search in the Portal. Am I missing something else?

[krikke999]

Did you add the app pool user to performance monitor group?

Read something about that issue somewhere...

Met vriendelijke groeten,

Kristof

On 27 Jun 2016, at 20:24, Zoltán Lehóczky [email protected] wrote:

Thank you Sergey. I did this and indeed data is now collected. However not everything: memory and CPU works, however the other graphs remain flat:

It's strange because otherwise those types of data (requests, dependencies) are properly collected and appear under Search in the Portal. Am I missing something else?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[Piedone]

No, didn't do anything special. Note though that this is me running the app locally: collecting server perf data on Azure is not something that would be possible with the module.

[SergeyKanzhelev]

requests and dependencies should be tracked by the same telemetry configuration object so they'll use QuickPulseTelemetryProcessor for aggregations. If you already have it this way - can you please try to reverse initialization order and initialize telemetry module first. It is the only thing I can speculate of...

[Piedone]

Thank you!

Yes, the same TelemetryConfiguration object is used throughout the app. I also tried initializing the modules first but no change.

This is basically what happens in code. BTW this is the right way of adding a processor, right?

var configuration = TelemetryConfiguration.CreateDefault();
configuration.InstrumentationKey = instrumentationKey;

configuration.TelemetryProcessorChainBuilder.Use(next => new QuickPulseTelemetryProcessor(next));
configuration.TelemetryProcessorChainBuilder.Build();

// Note that TelemetryModules are only initialized for the above created TelemetryConfiguration but not for TelemetryConfiguration.Active. Is this an issue? TelemetryConfiguration.Active shouldn't really be used anyway as everything is set up manually.
var telemetryModules = new List<ITelemetryModule>();

telemetryModules.Add(new DependencyTrackingTelemetryModule());
telemetryModules.Add(new PerformanceCollectorModule());
telemetryModules.Add(new QuickPulseTelemetryModule());

foreach (var telemetryModule in telemetryModules)
{
    telemetryModule.Initialize(telemetryConfiguration);
    _telemetryModulesHolder.RegisterTelemetryModule(telemetryModule);
}

TelemetryConfiguration.Active.InstrumentationKey  = instrumentationKey;
TelemetryConfiguration.Active.TelemetryProcessorChainBuilder.Use(next => new QuickPulseTelemetryProcessor(next));
TelemetryConfiguration.Active.TelemetryProcessorChainBuilder.Build();

[SergeyKanzhelev]

Please call Initialize on QuickPulseTelemetryProcessor. Looking into code - it needs to get registered

var qpProcessor = new QuickPulseTelemetryProcessor(next);
qpProcessor.Initialize(configuration);

configuration.TelemetryProcessorChainBuilder.Use(next => qpProcessor);
configuration.TelemetryProcessorChainBuilder.Build();

Our custom DI implementation is not ideal =)

[Piedone]

Since the class's ctor needs an argument I've written this:

            configuration.TelemetryProcessorChainBuilder.Use(next =>
            {
                var processor = new QuickPulseTelemetryProcessor(next);
                processor.Initialize(configuration);
                return processor;
            });
            configuration.TelemetryProcessorChainBuilder.Build();

But still no luck, it's the same. But it also seems to me that this was an unnecessary change, since Register() is also called from the ctor.

[SergeyKanzhelev]

@tokaplan, I'm out of ideas. What am I missing?

[tokaplan]

You don't need to call Initialize on the QuickPulseTelemetryProcessor instance. Instead, call RegisterTelemetryProcessor on the instance of QuickPulseTelemetryModulebefore calling Initialize on it. Pass the QuickPulseTelemetryProcessor instance to the RegisterTelemetryProcessor call.

This is only needed when initializing things in code. Keep in mind that whenever you have more than one TelemetryConfigurations, the QuickPulseTelemetryModule will only receive (and show on Live Metrics charts) telemetry items that pass through the QuickPulseTelemetryProcessor associated with the module through a RegisterTelemetryProcessor call.

[Piedone]

Thanks @tokaplan, that was the issue, now it's working!

[krikke999]

Just updated the module with fix #6, but live metrics stream is not working (using Orchard 1.9.2 @ Azure VM)

Other metrics are working fine

Orchard error log is empty

[Piedone]

No idea... Maybe it needs something I only have locally, didn't yet try on Azure App Services.

[krikke999]

if I use the method of dropping in the Microsoft.ApplicationInsights.Web dll in the bin and register the httpmodule in the web.config => live stream works.

Will this fight with the module? I would think I would see the other data x 2?

[Piedone]

It will work if the assembly's version is the same.

[krikke999]

If I use Application Insights Status Monitor to inject the latest 2.1.0 version, update web.config with httpmodule registration, update applicationinsights.config with correct instrumentationkey it works in combination with your module.

[Piedone]

I can confirm that just by using the module the live stream works even if the app is deployed to an Azure App Service (and no AI site extension is installed).

However I'd have another question @tokaplan : as Sergey also knows, what we develop here is a multi tenancy-supporting Orchard extension, i.e. there can be multiple tenants ("sub-applications") in an Orchard app each using different TelemetryConfiguration objects (even if the instrumentation key is the same, what is not always the case).

This is an issue because in the end a QuickPulseTelemetryModule instance can be only coupled with one TelemetryConfiguration. How should we overcome this? Register a module for each of the tenants? Share the TelemetryConfiguration object among tenants? Neither of these seem ideal.

[krikke999]

OK, I was running from a tenant website with the module activated => NO GO
When I activated the module from the default (master) tenant live streaming start working!

For the tenants there is no live stream data coming, only hitting the default (master) tenant triggers events in live stream

[SergeyKanzhelev]

@Piedone, Would you like to see live stream metrics per tenant? Is other telemetry now split by tenants? Ultimately with the telemetry processors you can build multiplexor processor to split telemetry by tenants or merger that will accumulate requests and dependencies metrics across multiple channels.

[Piedone]

The aim is not to see stream metrics per tenant but rather to collect such metrics from all of the tenants (as opposed to only gathering them from one of the tenants).

Thanks for the tips with the de/multiplexor telemetry processor, but this seems to require to jump through a lot of hoops: QuickPulseTelemetryModule actually requires and IQuickPulseTelemetryProcessor instance, not just any ITelemetryProcessor. However this interface is internal. So the only option would be to inherit from QuickPulseTelemetryProcessor, override its Process method (since it's not virtual this could be only done with explicitly re-implementing ITelemetryProcessor) and from that redirect all calls from the tenants to a singleton QuickPulseTelemetryProcessor's Process.

Instead what I've chose is to have a single QuickPulseTelemetryProcessor object in the app and re-use it everywhere, even if this mean that the processor chaining in this way is broken. See: 8abc644

Does this look like an OK solution? Now telemetry from all tenants appear in the stream (though QP telemetry can't be collected separately per tenant since there is the singleton module that accepts only one processor object).

BTW otherwise telemetry is collected in the following ways:

• either together for all of the tenants but marked with the tenant's identifier (i.e. a single AI account collect the whole app's data but you can filter on tenant);
• or separately for each of the tenants (i.e. each of the tenants get their telemetry in separate AI accounts);
• or the first two options combined (i.e. while the whole app's telemetry is visible, filterable per tenant, in a single AI account additionally each of the tenants have their separate AI accounts as well with just tenant-specific data; this is what we also do on DotNest).

[Piedone]

Argh, not good. Now although requests are visible in the live stream they disappeared from the long-term log.

[Piedone]

Changed the implementation to use a singleton QuickPulseTelemetryProcessor that is registered with the module. All tenant-level QuickPulseTelemetryProcessor instances go their Process calls also dispatched to that.

See referenced commit.