In today's fast-paced digital world, having the right insights into application performance and user behavior is crucial for businesses. For this purpose, telemetry tracking is vital to understand user interactions, server load, and overall app performance. In this blog, I'll discuss a solution for a client’s requirement to track requests from both mobile and web platforms and how we implemented telemetry tracking using Azure Application Insights.

Client's Need

Our client, a large-scale enterprise, needed to track how many requests were coming from mobile and web platforms over the past month. The goal was to get insights into user interactions, especially for different platforms, while ensuring minimal impact on system performance.

The client’s core needs were:

• Real-time telemetry to track requests from different platforms (mobile and web).
• Ensuring that tracking data was efficient without overwhelming the system.
• Simplifying the way telemetry data was processed and viewed in Azure Application Insights.

Approaches and Different Solutions

When we were tasked with implementing telemetry tracking for the client, we explored several different approaches. Below, I’ll Walk through the most notable solutions we considered:

1. Tracking Telemetry Using trackEvent
We decided to use Azure Application Insights to track events related to requests. Using the trackEvent API, we could easily log telemetry data without creating excessive records for every individual request, which was a major challenge in our case.

Why we chose trackEvent :

• Single Event Per Request: Unlike other telemetry methods, such as trackRequest, which would create a record for every request and could result in a flood of data, trackEvent allowed us to log a single entry per request. This helped avoid data clutter.
• Efficient Use of Azure Resources: By logging only meaningful events rather than tracking every HTTP request or dependency, we kept the telemetry data efficient and minimized overhead on our Application Insights.
• Custom Properties: We could attach custom properties like requestOrigin (mobile or web) and other request metadata (method, URL, body parameters) to better understand the nature of the traffic. Here's a simplified version of how we implemented the trackEvent:

let clientAppInsights: any = null;
try {

    if (config.appInsightsKey) {
      const appInsights = require('applicationinsights');
        appInsights.setup(config.appInsightsKey)
        .setAutoCollectRequests(true)
        .setAutoCollectPerformance(true)
        .setAutoCollectExceptions(true)
        .setAutoCollectDependencies(true)
        .start();

    clientAppInsights = appInsights.defaultClient;
    }
} catch (error) {
    console.error('Application Insights not configured:', error);
}

clientAppInsights.trackEvent({
  name: 'Track Caller Platform',
  properties: {
    originRequest: requestOrigin,
    method: req.method,
    url: req.originalUrl,
    bodyPara: req.body
  }
});

2. Other Telemetry Solutions Explored

• trackRequest: Initially, I considered using trackRequest, which automatically logs every HTTP request. However, this resulted in multiple entries for each request, which was problematic when trying to track high-traffic periods. The overhead created by too many individual entries was inefficient for our client’s use case.
• trackDependency: This method is generally used to track external dependencies (like database queries or service calls). While it would have captured performance metrics, it wasn’t the best fit for tracking user requests based on platform, as the metadata we needed wasn’t specific to dependencies.
• trackException: While useful for tracking errors, this method wasn’t relevant in this case since we were more interested in tracking request volume, not failures.

Why trackEvent is the Best Fit

After evaluating the alternatives, we found that trackEvent offered the best balance between simplicity, efficiency, and scalability. By using _trackEvent _, we avoided the pitfalls of redundant data entries while ensuring that we could track key request data with custom properties such as request origin (mobile vs. web). Additionally, it helped us minimize resource consumption by logging only essential events and avoiding overuse of telemetry APIs.

Running Queries in Application Insights: Filtering Telemetry Data

To gain insights from the telemetry data logged in Azure Application Insights, we often use Kusto Query Language (KQL) in the Logs section. One common scenario is filtering data based on a custom property, such as identifying requests originating from the web platform.

Here’s how you can execute the following query to filter telemetry events:

customEvents
| where customDimensions.origineRequest == "Web"

customEvents
| where customDimensions.origineRequest == "Mobile"

Key Benefits of trackEvent for This Use Case:

• Custom Event Data: The ability to attach custom properties like originRequest, method, and bodyPara allowed us to track the data that was most important to the client.
• Performance Efficiency: Using a single event log per request meant fewer records in Application Insights, avoiding unnecessary noise and data overload.

Challenges Faced

While the solution worked well, we did encounter some challenges:

• Token Management: Verifying JWT tokens for each request to ensure that telemetry data was linked to the correct user and platform required careful token handling.
• Handling Unauthenticated Requests: Requests without proper tokens had to be rejected to avoid incomplete or inaccurate data being sent to Application Insights.

Conclusion

Implementing telemetry tracking with Azure Application Insights enabled the client to gain a clear understanding of their platform's usage over time, specifically distinguishing between mobile and web requests. After evaluating various methods, we chose trackEvent as the most efficient and scalable solution. This approach allowed us to capture detailed insights without overwhelming the system with excessive data, and it provided the client with an accurate view of request volume and platform usage.

If you are also considering implementing telemetry tracking for your application, consider using trackEvent for scenarios like this, where you need to log specific events without flooding your telemetry system with every single HTTP request.