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.
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.
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.
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…
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.
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.
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…
We have a customer who is using Sitecore and the SagePay Pi service to take credit card payments. They were using a multi-page Sitecore Forms form, and weirdly their confirmation emails couldn’t use field values from the first pages of the form. Eventually, we found that the problem was due to the the user’s session being lost, but only if the user was using 3D-secure, and a recent browser. Here’s why…
I noticed something strange in Sitecore; for most of my nodes (not the Sitecore node!), the 13th Hex character of the identifying GUID is ‘4’.
I had a list of about 50 of these, and my eye was drawn to the pattern. Now, I thought Guids were entirely random, except that the chance of 50 page template IDs all having a 4 at that character was infinitesimal.
Weird. Except it turns out that they’re not random. I had no idea that there are different versions of guids, or than that character defined the version of the GUID.
This requires a test, so I wrote a program to print Guid.NewGuid() a lot:
All of them are 4s.
So:
GUIDs aren’t entirely random.
They might not be very random at all, looking at some of the other GUID versions.
Which is why they shouldn’t be used as a source of entropy for encryption.