Azure, Coding, How to

Fixing ASPNET Production Issues by adding custom data to App Insights logs

Debugging issues in production is hard. Things vary – seemingly identical requests to the same URL could be made but one succeed and the other fail.

Without information about the context and configuration it’s hard to isolate issue, here is a quick way to get more of that context.

The key is having the data to understand the cause of the failures. One of the things we do to help that is creating our own ITelemetryInitializer for application insights.

In this we track which environment the request was made in, the cloud instance handling the request, code version, UserId and lots more.

This means, if an issue occurs, we have a wealth of data to understand and debug the issue. It’s embedded in every telemetry event tracked.

Here is an example of a Telemetry Initializer which adds the UserID and Azure WebApps Instance Id to tracked events, if a user is signed in. You’ll find, once you start using this you’ll add more information over time.

To get it setup register it, like this, in your Startup.cs:


Go do it now, seriously you’ll need it later!

Azure, How to

Using App Insights Analytics Query Language to Make Better Decisions

So we’ve been working on an App recently to complement our website. One thing I strongly believe in is data driven design or put simple: “Don’t guess gather evidence”.

In our current site we’re using App Insights to capture usage, performance and general telemetry from the platform. This gives us a wealth of knowledge which we can query when making business decisions.

Let’s jump in, I’m going to be using the new Analytics platform and its query language to understand more about our mobile users, specifically iOS, as an example.

First up I’m going to run a query to get the numbers for each client OS we see on the site.


Now, as you can see in the results, iOS is split over various versions. Let’s narrow down the query to look at just iOS..



Let’s remove the grouping and see if we can find out what we’d lose by just targeting iOS9 upwards.

First up what are the total numbers for all iOS visitors?


What about just iOS9?


In our case this shows that 89% of our usage is from iOS9 and above. We haven’t taken into account time here so all the older iOS usage could be from way in the past. Let’s take a quick look at that.


So no feasible trend to be seen here, 89% stands.

At the moment we’re just looking at requests, so this number could be massively off if one user came and hit the site a lot on a single phone. We’ll use the dcount operator to do a distinct count by sessionID. This will only count each user session once.

This query showed that this wasn’t the case and the numbers we had are valid, so we can rule out a single user doing a lot of browsing and throwing off our stats.

At this point I realised that we’re using some SPA functionality and server requests doesn’t really map to pageviews so I switched to looking at page views to compare the numbers.

Sure enough this made a difference but the rations between the numbers where similar, 1 request generated x number of page views, where x is fairly constant.

Let’s next look at the split between device types, for this we’ll use the reduce function. It groups together similar variables to make things simple. For example, the jumbled list below:


This is great to help understand patterns in data without having to do lots of where/group by’s. But in this case it’s a bit too extreme, I’d like “other” broken down a bit more.

By playing around with the “threshold” value I can make this happen. After tweaking the “threshold” value I found that 0.2 did the trick for me, I now have a breakdown of iPad vs iPhone

Roughly this showed a 50/50 split in iPhone vs iPad traffic for us over the time period.


89% of our iOS users are on iOS 9 or above and we have a 50/50 split of traffic between iPad and iPhone users. Now when making product decisions we can use this data to drive what and how we target the platform.

Obviously this is only a high level overview of the numbers we ran but hopefully it serves to illustrate some of the functions in analytics and how they can be used to inform better development decisions.

Azure, How to

PubSub in Service Fabric with Redis

I’ve been working on a project that uses Fabric and I’m hosting Redis inside the cluster as a simple cache system.

One of things that isn’t baked into Fabric is a pub/sub model for communicating between services  about events that are occuring.

As I’ve got the Redis instance up and running in the cluster I decided to take a look at using the Pub/Sub capabilities in Redis to make this happen. N.B Redis isn’t a guarenteed delivery so use where appropriate, there are lots of discussions around it’s pub/sub model and when/where to use etc.

Turns out it’s nice and easy to get working, I’m a big fan of using RX to make nice reactive programs operating on streams of events and there is already a nice sample combineing Redis and RX in C# here.

In not too long I had just what I wanted and through it might be useful to others so I’ve put together a sample. My sample is here with one “EventPublisher” service pushing out events and an “EventSubscriber” listening to events.

Both services write out what they’re up to as ETW messages so you can view in the diagnostic window.



Lawrence Gripper