Configuring Hard-to-reach settings in Sitecore Containers

I’ve had a problem with some Containers I’m configuring – how do I set machine/environment specific settings in those containers? I can’t just patch them in with Sitecore patches – the files in the image are supposed to be immutable.

I could use Environment Variables (which is what the Sitecore container images do for App Settings and Connection Strings), and the $(env:variablename) syntax gives a way of doing that – but it could mean editing a lot of places.

Well, there’s a better way, and Vitalii Tylyk describes a nice way to do this – Sitecore environment variables config builder.

That’s pretty nifty, but I wonder if it could be adjusted to set cache sizes too…

Configuring Hard-to-reach settings in Sitecore Containers

Setting your Application Insights Connection String

If you’re adding Application Insights to your solution, you will need to specify a connection string. Usually, this is at the bottom of your applicationinsights.config file:

A nifty alternative is you can specify this connection as an Environment Variable – and App Insights will pick that up and use it…

Continue reading “Setting your Application Insights Connection String”
Setting your Application Insights Connection String

Debugging – Why my Content Editor was so slow

A customer reported to me that their content editor would freeze for 5 minutes if you clicked the root node of their site in Content Editor. I was surprised – bit when I went and did so, it froze for 5 minutes.

Now, this was on a newly upgraded and replatformed system, so I when and tried their existing system – and had the same result. The first click on the root node would take 5 minutes to load. So, it wasn’t our upgrade – but that I could study more easily. As it was the first click only, I figured caching was involved – but what gives? How do I find out what’s going on?

Continue reading “Debugging – Why my Content Editor was so slow”
Debugging – Why my Content Editor was so slow

Sitecore making requests to cts.cloud.sitecore.net

So, in my recent work on Application Insights I noticed that I was seeing quite a lot of failed outbound requests to cts.cloud.sitecore.net .

I know that Sitecore “phones home”, and I suspect that this is being blocked by our firewall (and this is why it is being logged as a failed dependency). However, I couldn’t fine out any information about cts.cloud.sitecore.net, or what information is being send.

Well, I raised this with Sitecore support; it is Sitecore’s “Consumption Tracking” service, and they gave some links:

They also mentioned that you can get a “no-track” license, but we’d have to contact our account manager.

Therefore, I see 3 options:

  1. Get a no-track license.
  2. Reconfigure the firewall.
  3. Filter out the failed dependency so it doesn’t keep logging to App Insights (and then pretend it isn’t there).

I prefer option 2 – letting the traffic out, personally.

Sitecore making requests to cts.cloud.sitecore.net

Filtering App Insights Server-side Trace messages

Previously I posted about using a Log4Net Appender to record Sitecore logs to Application Insights. That code will write Trace Messages to App Insights. I’m already filtering the messages to WARN or above using standard Log4Net <filter>s – but what if I need to filter more particular messages. Well, I wrote a telemetry processor to do this, just like Requests and Dependencies.

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

Writing Sitecore Logs to Azure Application Insights in IAAS/On Prem

Sitecore’s installer for Azure app services installs a neat feature; a Log4Net appender that writes Sitecore log entries to Application Insights as TRACE messages. Nifty! However, for reasons I cannot comprehend, this is not included in the normal installer. That’s a terrible shame, as App Insights is still useful for Sitecore running on actual tin or in a VM.

Continue reading “Writing Sitecore Logs to Azure Application Insights in IAAS/On Prem”
Writing Sitecore Logs to Azure Application Insights in IAAS/On Prem

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