How to breakup Sitecore/Index Request in Application Insights [closed]

Question

So if your using Application Insights w/ your Sitecore setup, you've invariably seen the following when perusing the basic reporting. A lot of request going to the cryptic Sitecore/Index.

As you can imagine this is troubling, as I figured out, the Sitecore/Index is referred to as the Page level controller which underlying is an MVC Controller/Action SitecoreController.Index(), which is called for every route that matches an item path, so alot.

Source: https://stackoverflow.com/a/14999263/2446435

It would be more helpful if I could instead log the Item Path or something. But this got me thinking, Why not log the Renderings. Let's refer to my illustration of a typical Sitecore page.

So I was thinking about this in a similar way to how the Sitecore Debugger works. http://www.glass.lu/Blog/Archive/Using%20the%20Sitecore%20Debug%20Tool%20Part%201

If I could hijack the pipeline, I could call TelemetryClient.TrackRequest() or TrackDependency(). However, I don't really think this option is ideal.

First if I used a Dependency object, Dependency objects are relatively primitive. Rendering are more of a Request, Item Paths of their own, potentially dependencies of their own, etc etc, too much detail and complexity to be represented as a dependency. Unless I were to just track the new Request as a Dependency of the Old Request.

So yes, I could call TrackRequest, but I'm not really sure the Framework would attach all the inner dependencies of my Rendering correctly, they would most likely be tied to the OOTB Request Object.

Rather I would like to Hijack the Pipeline in Sitecore where Renderings Begin and Complete their execution. The way I see it is to try and leverage as much of the OOTB Rendering Object where Application Insights attaches more telemetry to the current Operation_ID, taking advantage of correlation.

But for example, I only want Telemetry executed within the confines of the HeaderControllerRendering associated with the corresponding Request. Maybe I allow the Telemetry inside this component to be associated with its corresponding Request object, as well as shared with its Ancestors Request objects (IE Main_Layout.cshtml and so on depending on how far your rendering hierarchy goes). But I certainly don't want, for example, Telemetry of Top Main View Rendering.cshtml or Footer Controller Rendering associated with the Request object of HeaderControllerRendering as they are in this scenario cousin renderings(?)

So If you are not keeping up with this, I understand, it's a little convoluted, let me try and explain it with some pseudo code.

Note: I think I need something like PipelineBasedRequestFilter https://stackoverflow.com/a/52599581/2446435

public class MyHypotheticalRenderingFilter : IActionFilter
{
    public virtual void OnActionExecuting(ActionExecutingContext actionExecutingContext)
    {
        RequestTelemetry parentRequest = HttpContext.GetRequestTelemetry();
        RequestTelemetry request = new Request();
        request.ParentOperationID = parentRequest.OperationID;
        TelemetryRequestBag.SaveRequest(request); 
        parentRequest = request;
    }

    public virtual void OnActionExecuted(ActionExecutedContext actionExecutedContext)
    {
        RequestTelemetry request = HttpContext.GetRequestTelemetry();
        TelemetryClient.TrackRequest(request);
        RequestTelemetry request = TelemetryRequestBag.RetreiveRequest(request.ParentOperationID);    
    }
}

public class TelemetryRequestBag
{
    private Dictionary<string, RequestTelemetry> requestTelemetry;

    public TelemetryRequestBag()
    {
        requestTelemetry = new Dictionary<string,RequestTelemetry>();
    }

    SaveRequest(RequestTelemetry request)
    {
        requestTelemetry.Add(request.OperationID, request);
    }

    RetrieveRequest(string Operation_ID)
    {
        return requestTelemetry.Get(Operation_ID);
    }
}

The goal here would be to go from something like this, where I have 43 results for a Request that starts with Sitecore/Index

To significantly less and including a row like this:

• timestamp: 2018-10-08T01:48:32.114
• itemType: request
• operation_Id: MYNewOperationIDHere
• operation_Name: ControllerRendering: Analytics/FullStory
• operation_ParentId: 40765245d3a270409a420f6735a09dc3

And If I ran the following Query, I'd expect back the preceding row, and any of the dependencies, traces, or subsequent requests that occur as a result of MYNewOperationIDHere.

union *
| where operation_Id == "MYNewOperationIDHere"
    or operation_ParentId == "MYNewOperationIDHere"
| project timestamp, itemType, operation_Id, operation_Name, operation_ParentId

• timestamp: 2018-10-08T01:48:32.114
• itemType: request
• operation_Id: MYNewOperationIDHere
• operation_Name: ControllerRendering: Analytics/FullStory
• operation_ParentId: 40765245d3a270409a420f6735a09dc3

Questions

1. Where in Sitecore can I hook into, to take similar action to do what I do in the pseudo code?
2. Can anyone point out any major flaws/possible bugs in my solution around the Application Insights Schema.
3. Can anyone point out any major flaws/possible bugs in my solution around Sitecore.

Answer 1

While not the answer to breaking down logging each rendering, It's quite possible to change the GET Sitecore/Index to show its correct url.

You need to implement a custom telemetry processor, looking at the request item and updating both the Name properties of the request item as well as for the Operation. Operation Name is what you see Azure Portal.

Full blog post and code is available here: https://medium.com/@osbeck.per/geting-the-fix-for-sitecore-index-318bcfaaa690

Answer 2

I believe that you are misusing request object. While I agree, renaming Sitecore/Index to URL will be helpful, to get details of execution of one request you should use profile traces. https://docs.microsoft.com/en-us/azure/azure-monitor/app/profiler-overview