Weldon Web

Application Insights: Best Practices & Azure Functions Guide

Updated #appinsights#azure

The Modern Guide to App Insights & Azure Functions

Application Insights is your window into what your live app is actually doing. It’s a core piece of Azure Monitor that tracks performance without slowing your code down, keeping everything non-blocking and batched in the background.

What It Actually Does

It finds anomalies before your users complain. You get the full picture.

  • Requests & Dependencies: How fast are your APIs? Are external services dragging you down?
  • Exceptions: Both server and browser errors, broken down right to the stack trace.
  • Host Stats: CPU, memory, and network usage.
  • Custom Tracking: Log the specific business events that actually matter to you.

Just remember one thing. App Insights relies on sampling to keep performance high and your Azure bill down. It's a monitoring analytics tool. Don't treat it like a perfectly precise audit log.

The Workspace Era

Classic App Insights is dead. Everything today runs on a Workspace-based architecture. Your telemetry flows straight into a centralized Log Analytics workspace. Why does this matter? You get unified billing and the full power of Kusto Query Language (KQL) to hunt down issues across all your Azure Monitor tools.

Doing it Right in Azure Functions

Modern Azure Functions use the Isolated Worker Model. Forget the old ways. Stop manually spinning up a TelemetryClient or messing with the ExecutionContext. Lean entirely on Dependency Injection (DI) and standard .NET practices.

  • The Basics: Stick to the integrated ILogger<T>. The Functions runtime automatically correlates the requests, traces, and exceptions you log through it.
  • Custom Telemetry: Need to track something specific? Inject TelemetryClient via DI to fire off a TrackEvent or TrackMetric.
  • Don't Duplicate: Never manually call TrackRequest. The runtime is already doing this for you.

OpenTelemetry is the Standard

The industry moved on, and Microsoft did too. For tracking custom outgoing dependencies, ignore the old TelemetryClient.StartOperation method. Use the standard .NET System.Diagnostics.Activity. Application Insights will automatically intercept it and log it as a dependency in your workspace.

The Code

Here is a clean implementation for an Isolated Worker function. It uses DI for logging a custom event and OpenTelemetry to track a custom dependency.

using System.Diagnostics;
using Microsoft.ApplicationInsights;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Http;
using Microsoft.Extensions.Logging;
 
namespace InsightsDemo
{
    public class InsightsFunction
    {
        private readonly ILogger<InsightsFunction> _logger;
        private readonly TelemetryClient _telemetryClient;
        private static readonly ActivitySource _activitySource = new("CustomDependencySource");
 
        public InsightsFunction(ILogger<InsightsFunction> logger, TelemetryClient telemetryClient)
        {
            _logger = logger;
            _telemetryClient = telemetryClient;
        }
 
        [Function("InsightsFunction")]
        public async Task<HttpResponseData> Run([HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequestData req)
        {
            _logger.LogInformation("Processing initiated.");
 
            _telemetryClient.TrackEvent("CustomBusinessEventTriggered");
 
            using var activity = _activitySource.StartActivity("ExternalDatabaseCall");
            activity?.SetTag("db.system", "custom-sql");
            
            await Task.Delay(100); 
 
            var response = req.CreateResponse(System.Net.HttpStatusCode.OK);
            return response;
        }
    }
}