I believe that everyone, who installed Sitecore Azure PaaS had their silent question moment: “Where are all my logs, and how I suppose to monitor this?”. While the first question was answered multiple times (e.g. on StackOverflow), the second part is a bit more complex.
You might think about what complexity I’m talking about? Yeah, putting Application insight Key is a no-brainer but it is far from enough to get observability of your system.
Most of you should be familiar with this one green circle. Sol let’s break it down into more manageable parts.
Enable dependencies tracking
To see where your application is going to get data whether is it SQL or HTTP request you need to enable dependencies collection. This can be done in ApplicationInsights.config, which sits next to web.config. The following *XDT *transformation will add DependencyTrackingTelemetryModule to that file.
<?xml version="1.0" encoding="utf-8"?>
<ApplicationInsights xmlns="http://schemas.microsoft.com/ApplicationInsights/2013/Settings" xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<TelemetryModules>
<Add Type="Microsoft.ApplicationInsights.DependencyCollector.DependencyTrackingTelemetryModule, Microsoft.AI.DependencyCollector" xdt:Transform="InsertIfMissing" xdt:Locator="Match(Type)" />
</TelemetryModules>
</ApplicationInsights>
Once the configuration is there, you see that a few satellite bubbles appeared around the original one. They will represent external services Sitecore is connecting to.
*Note: *You won’t see there Redis as it is not possible to instrument driver with AI.
Track individual Sitecore App Services
Next thing that you need to solve is to separate one bubble in the middle into App Service (or roles).
Sitecore doesn’t provide solution for this out of the box, though it has some setting in configuration files that suppose to solve that (see * ApplicationInsights.Role* and *ApplicationInsights.Tag* in */App_Config/Sitecore/Azure/Sitecore.Cloud.ApplicationInsights.config*) and it make sense to utilize them in the following customization:
namespace Foundation.Configuration.Diagnostics
{
using Microsoft.ApplicationInsights.Channel;
using Microsoft.ApplicationInsights.Extensibility;
using Sitecore.Configuration;
public class SitecoreCloudRoleInitializer : ITelemetryInitializer
{
public void Initialize(ITelemetry telemetry)
{
var role = Settings.GetSetting("ApplicationInsights.Role", "") + " " + Settings.GetSetting("ApplicationInsights.Tag", "");
if (telemetry?.Context?.Cloud == null || string.IsNullOrWhiteSpace(role))
{
return;
}
telemetry.Context.Cloud.RoleName = role;
}
}
}
processor that will register it in Sitecore:
namespace Foundation.Configuration.Pipelines.Initialize
{
using Microsoft.ApplicationInsights.Extensibility;
using Sitecore.Pipelines;
public class InjectTelemertyInitializers
{
public virtual void Process(PipelineArgs args)
{
TelemetryConfiguration.Active.TelemetryInitializers.Add(new Diagnostics.SitecoreCloudRoleInitializer());
}
}
}
and, of cause, a configuration patch:
<?xml version="1.0"?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
<sitecore>
<pipelines>
<initialize>
<!--
Set Application Insights CloudRole to ApplicationInsights.Role + ApplicationInsights.Tag
-->
<processor type="Foundation.Configuration.Pipelines.Initialize.InjectTelemertyInitializers, Foundation.Configuration" resolve="true" patch:before="*[1]" />
</initialize>
</pipelines>
</sitecore>
</configuration>
As a result of those changes you should see the following picture: You might notice that only CMS nodes are marked with a green, while xDB nodes are represented with smaller grey circles. Unfortunately, xDB nodes cannot be properly instrumented as of now, which I posted as a bug a while ago. (support reference number #301321).
Bonus: For those who are interested in 127.0.0.1 reference in Azure PaaS. These are NodeJS instances created by SitecoreJSS in integrated mode to generate your markup, which cannot be properly instrumented as you can guess :P
Nevertheless, this should be enough to give you a better level of infrastructure observability and help to drill down into bottlenecks.
As usual, follow me on Twitter @true_shoorik 😉