Filtering App Insights Server-side Dependency messages

So, previously I’ve written about filtering out all the successful Dependency messages going to App Insights. What about unsuccessful ones, though?

My Sitecore instance seems have a failing dependency that is clogging up my logs. It’s the same as mentioned in this StackExchange question. It doesn’t seem to cause any issue, though… and it isn’t every environment either. Anyway, I’d like to block it. Telemetry processors to the rescue…

Continue reading “Filtering App Insights Server-side Dependency messages”
Filtering App Insights Server-side Dependency messages

Filtering App Insights server-side Health Check requests

So, again, I’m trying to tame Application Insights. My logs are filling up with various requests for different health-check URLs. These get requested, over and over, day after day, and all are recorded in App Insights as Requests. However, I don’t care about these requests if they’re successful. In fact, I only care about if they fail. Can I exclude them?

Yes, I can. I’ll build a telemetry processor to filter them out.

Continue reading “Filtering App Insights server-side Health Check requests”
Filtering App Insights server-side Health Check requests

Filtering App Insights Successful server-side dependencies

Application Insights can record the performance of your dependencies – so things like requests to SQL server, MongoDB, etc.. That’s great – but it can become VERY verbose. I find frequently that most of my allocation of data is spent tracking every damn SQL statement run – and there could be hundreds in a single page load.

You can just turn on Dependency tracking completely – but that seems a bit of nuclear option. What if there IS a problem? I want to know about it!

Well, you can create your own Telemetry filter instead:

public class SuccessfulDependencyFilter : ITelemetryProcessor
{
	private readonly ITelemetryProcessor _nextProcessor;

	public SuccessfulDependencyFilter(ITelemetryProcessor nextProcessor)
	{
		_nextProcessor = nextProcessor;
	}

	public void Process(ITelemetry telemetry)
	{
		DependencyTelemetry dependencyTelemetry = telemetry as DependencyTelemetry;
		if (dependencyTelemetry != null)
		{
			if (dependencyTelemetry.Success == true )
			{
				return;					
			}
		}

		_nextProcessor.Process(telemetry);
	}
}

This ITelemetryProcessor will check if the telemetry is a successful Dependency, and if it is, end processing (i.e. don’t write anything to App Insights).

To use it, add it to the ApplicationInsights.config in the TelemetryProcessors section:

Obviously, this means that if you have problems like a slow dependency that is still eventually successful then you won’t have any telemetry to show you that – but it VASTLY reduces the data being captured.

Filtering App Insights Successful server-side dependencies

Filtering App Insights Client-Side successful dependencies

So, I found that our client JavaScript was recording quite a lot of successful dependency messages for loading 3rd party scripts:

These are all analytics tools, and to be honest, I don’t care about them. Sure, it can be useful to know how long they take to load, but these are loaded after the page is ready, so even if they are slow they shouldn’t impact performance. And I don’t really think I need to know every time a user loads these analytics tools.

Therefore, I wrote a telemetry filter to block sending them. I could just use sampling – but I’d prefer to have none.

onInit: function (sdk) {
	/*	Once the application insights instance has loaded and initialized this method will be called 
	    This filter will block successful remote dependency requests being logged. */
	sdk.addTelemetryInitializer(function(envelope) {
		if (envelope.baseType === 'RemoteDependencyData')
		{
			if (envelope.baseData.success)
			{
				return false;
			}
		}
	});
},

From my testing, if the user blocks loading of a remote dependency I don’t see any kind of message being returned – even a failure, which is good.

Filtering App Insights Client-Side successful dependencies

Filtering App Insights Client Exceptions from 3rd party JavaScript

So, we are using App Insights, and when we moved the client side script for recording JavaScript errors to our integration test instance we started to get a lot of errors of the form:

Script error: The browser’s same-origin policy prevents us from getting the details of this exception. Consider using the ‘crossorigin’ attribute.

There were a lot of these errors:

… and investigating them showed that the problems came from 3rd party JavaScript. All of these are inserted by Google Tag Manager, and aren’t in the site, or local development.

Well, I’m not going to be able to fix JavaScript written by 2 third-parties, and that isn’t even loaded directly by my page – so instead I’m going to ignore that error…

Continue reading “Filtering App Insights Client Exceptions from 3rd party JavaScript”
Filtering App Insights Client Exceptions from 3rd party JavaScript

New Sitecore Publishing Targets in Containers

We have a Sitecore system running in containers, and we wanted to add a new publishing target. This is another copy of the WEB database; ours is called “preview”, and it is so that editors can check published content before it goes live.

I followed Sitecore’s documentation about how to do this – and do take note of steps 4 and 5. They’re new, and I missed them to begin with:

  • In the App_Data\items\ folder, make a copy of the Web folder.
  • Rename the copy of the folder and the .dat file inside it. Use the database name (for example, web_preview) instead of web for the folder name and the file name (so the filename is similar to items.web_preview.dat).

It turns out that’s important – without it you’ll get an exception on startup.

However, after doing that, we still had problems with our preview database; the CM server kept throwing an exception.

Continue reading “New Sitecore Publishing Targets in Containers”
New Sitecore Publishing Targets in Containers

System.Buffers references in Sitecore Nuget Packages

So, we keep seeing issues on different projects with the error:

Could not load file or assembly ‘System.Buffers, Version=4.0.x.x

The error can sometimes seem intermittent, or just plain baffling. If you then examine the /BIN directory, and look at the properties (right click on the dll, and look at the file properties) of System.Buffers, you’ll find that it’s a wrong version; it’s not what is referenced in web.config (remembering that you may have an Assembly binding redirect in place) at all.

I’m tired of digging out details for myself/my colleagues, so here’s what’s happening…

Continue reading “System.Buffers references in Sitecore Nuget Packages”
System.Buffers references in Sitecore Nuget Packages

Using web.config transforms on assembly binding redirects

Right, I keep having to do this, and keep having to look this up, so here it is.

If you want to do a web transform for an assembly binding redirect it can be a bit tricky. The assembly details are in an <assemblyIdentity /> element, and the <bindingRedirect /> is its sibling. Yeah, I don’t know why it was designed this way; I’m assuming alcohol was involved. Yes, having the oldVersion and newVersion attributes in the same element at the assembly’s identity would be much simpler.

Anyway, it is what it is. An alternative is to replace the entire <dependentAssembly /> element, but the locator becomes a bit more fiddly. Still, it works. See this example – the locator on the parent element is checking the name of the child assemblyIdentity.

<dependentAssembly xdt:Transform="Replace" xdt:Locator="Condition(./_defaultNamespace:assemblyIdentity/@name='System.Runtime')">
    <assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" />
    <bindingRedirect oldVersion="0.0.0.0-4.1.2.0" newVersion="4.1.2.0" />
</dependentAssembly>
Using web.config transforms on assembly binding redirects

Carousels are killing our Core Web Vitals scores

So, we’re all familiar with the Core Web Vitals scores, right? Just in case we’re not, lets recap. These are scores that Google uses to just the speed of your page. It’s more than just “How much data” does the page use, or “When is the DOM ready”, but also includes things like “When is the content painted on the page” and “How much does stuff shift as the page is loaded”.

This is actually really good, as these are much better metrics; people want your page to read, and these metrics focus on that.

So, one of the things I’ve noticed is that a number of our customers are not getting great scores for the Largest Contentful Paint (LCP) – and this seems to be due to a particular bugbear of mine – carousels.

Continue reading “Carousels are killing our Core Web Vitals scores”
Carousels are killing our Core Web Vitals scores

Email Regular Expression

One of my colleagues asked a question that I’ve heard dozens of times over my career…

What’s a good regular expression for validating email addresses.

Sadly, due to poor standards, poor implementation choices, and just the sheer age of Email, this is a surprisingly tough problem.

The best way to validate an email address is to email it, and get the user to do something. That’s not really feasible if it’s someone just filling in a form.

Failing that, I came up with:

^[^@\s]+@[^@\s]+\.[^@\s]+$

This is the same as suggested by Microsoft, which is gratifying. You can see the logic of it here.

Email Regular Expression