DEV Community: Pavan Manjunath

📝Mastering Structured Logging in .NET Core with Serilog, App Insights, and Log Analytics

Pavan Manjunath — Thu, 02 Oct 2025 13:28:17 +0000

Achieving deep observability is non-negotiable for modern applications. This guide details the gold standard pipeline for robust structured logging in .NET Core: integrating Serilog with Azure Application Insights and the underlying Log Analytics Workspace.

The Core Observability Stack: Roles Defined Understanding the relationship between these three services is paramount:

Simply put: Serilog formats the data, App Insights collects the application context, and Log Analytics stores and queries the final dataset.

Why Structured Logging? Structured logging is key to turning log lines into valuable data points. Instead of logging raw text, Serilog uses message templates to capture data properties.

Example Log:

Log.Error("Order {OrderId} failed because of a {Reason} for user {UserId}.", 456, reason, userId);

This creates searchable properties (OrderId, Reason, UserId) in Azure, enabling powerful filtering and aggregation that simple string searching cannot match.

Implementation Steps

Step 3.1: Install Packages
Add the necessary NuGet packages:

dotnet add package Serilog.AspNetCore
dotnet add package Serilog.Sinks.ApplicationInsights
dotnet add package Microsoft.ApplicationInsights.AspNetCore
dotnet add package Serilog.Settings.Configuration

Step 3.2: Configure in Program.cs
Configure Serilog early in your application lifecycle. This setup ensures that your structured logs flow directly into Application Insights while preventing duplicate logs from the default provider.

// 1. Create a bootstrap logger (optional, but good for startup errors)
Log.Logger = new LoggerConfiguration()
    .WriteTo.Console()
    .CreateBootstrapLogger();

var builder = WebApplication.CreateBuilder(args);

// 2. Register App Insights SDK (Crucial!)
// The Serilog Sink needs this service configured.
builder.Services.AddApplicationInsightsTelemetry(builder.Configuration["ApplicationInsights:ConnectionString"]);

// 3. Clear default providers to prevent duplicate logs
builder.Logging.ClearProviders(); 

// 4. Configure Serilog to use the Application Insights Sink
builder.Host.UseSerilog((context, services, configuration) => configuration
    .ReadFrom.Configuration(context.Configuration)
    .ReadFrom.Services(services)
    .Enrich.FromLogContext()
    .WriteTo.Console() 
    .WriteTo.ApplicationInsights(
        services.GetRequiredService<TelemetryConfiguration>(), 
        // This converter ensures logs land in the 'traces' table
        TelemetryConverter.Traces
    ));

// ... rest of builder code

Step 3.3: Configure appsettings.json
Ensure your Application Insights connection string is defined, and set your desired logging levels:

{
  "ApplicationInsights": {
    "ConnectionString": "InstrumentationKey=..." 
  },
  "Serilog": {
    "MinimumLevel": {
      "Default": "Information",
      "Override": {
        "Microsoft": "Warning",
        "System": "Warning"
      }
    }
  }
}

Querying and Diagnostics Once deployed, your structured logs land in the traces table within your Log Analytics Workspace.

Use Kusto Query Language (KQL) to perform diagnostics:

// Find all error logs related to a specific user and project the custom property
traces 
| where customDimensions.UserId == "123" 
| where severityLevel == 3 // Severity 3 is Error
| project timestamp, message, customDimensions.OrderId, customDimensions.Reason
| order by timestamp desc

This integrated approach allows you to correlate your custom application events (traces) with system telemetry (requests, exceptions) using the common operation_Id property, giving you a full, end-to-end view of every transaction.

Mastering this pipeline is key to moving from reactive bug fixing to proactive system health monitoring!

🚀 Azure Functions Deployment Simplified: Mastering Publish Profiles & The Isolated Model

Pavan Manjunath — Wed, 01 Oct 2025 17:01:58 +0000

Azure Function Apps are at the heart of modern serverless architectures, enabling developers to run event-driven code without managing infrastructure. But once your brilliant function is coded, how do you get it from your local machine to the cloud efficiently and reliably? Enter Publish Profiles.

Far more than just a configuration file, an Azure Function App Publish Profile is a powerful tool that streamlines your deployment process, ensuring consistency and control. Let's dive deep!

What Exactly is a Publish Profile?
At its core, a publish profile (.pubxml file) is an XML document containing a blueprint for how your Function App should be deployed. When you download one from the Azure portal, it's pre-populated with crucial information:

Target Azure Resource: The specific Azure Function App instance where your code will live.
Deployment Method: How the code gets transferred (e.g., Web Deploy, Zip Deploy)
Build Configuration: Which project configuration (e.g., Release) to use.
Credentials: Encrypted keys for secure authentication with Azure.

And more... Specific settings for file exclusions, pre/post-build actions, etc.

This single file empowers tools like Visual Studio to automate the complex process of getting your code to Azure with a click.

The .NET Dilemma: In-Process vs. Isolated Process
This is where many .NET developers encounter a significant architectural choice, one that fundamentally impacts your Function App's design and deployment. Publish profiles for .NET functions inherently reflect which model you choose:

-> In-Process Model (Legacy)
Concept: Your function code runs within the same process as the Azure Functions host runtime.

Coupling: Tightly coupled to the Functions host, meaning you share its dependencies and runtime version.
Target Frameworks: Typically .NET Core 3.1 or .NET 6, tied to specific Azure Functions runtime versions.
Considerations: Simpler for historical projects, but prone to dependency conflicts and less control.

-> Isolated Process Model (.NET Isolated / Worker Process - Recommended!)
Concept: Your function code runs in a separate worker process, completely isolated from the Azure Functions host. Communication happens via gRPC.

Decoupling: Gives you full control over your application's dependencies and Program.cs startup.
Target Frameworks: Can target standard .NET versions like .NET 6, .NET 7, .NET 8, and beyond, independently of the Functions host.

Benefits:

Greater Control: Leverage standard .NET features, middleware, and dependency injection.
Fewer Conflicts: Significantly reduces dependency issues.
Future-Proof: Use the latest .NET versions and ecosystem innovations.
Consistent Experience: Closer to a standard ASP.NET Core application development experience.

This distinction is crucial for modern .NET Function development. Choosing the Isolated Process model for new projects provides greater flexibility, stability, and a more standard .NET development experience.

AzureFunctions #Serverless #DotNet #CloudComputing #Azure #Deployment #SoftwareDevelopment #TechTips

Graph Theory in Real Life: How BFS Solves Business Problems You Didn’t Know Existed

Pavan Manjunath — Wed, 09 Jul 2025 18:20:10 +0000

🧠 Introduction

-> Ever wondered how your team organizes tasks, routes delivery packages, or prioritizes bug reports? Beneath the surface, you're living in a graph.

-> Introduce graphs quickly, mention your focus on 1-based indexing, BFS, and how you initially visualized traversal logic.

🧱 How to brick ideas and find in real life.

I work in logistics domain run many warehouses. Each connected node in your graph represents a department: receiving, packaging, quality check, dispatch… and BFS is the method to check each floor in sequence without getting lost

Below is the code just refer and link to your ideas.

how i store graph as .Net developer: C# adjacency list

BFS traversal algorithm:
Simple explaination:

create a function with accepts startNode, adjacency list

take queue put startNode, and make that to true in bool array

now keep on iterating queue until its empty

go through each neighbour and check if its visited or not, if its not then make it true in bool array, enqueue it.

pick enqueue item and start step 4.

💼 Business Use Case Callout

📦 BFS in Action: Real-World Usage
Warehouse routing, customer support escalation paths, or even job interview scheduling — all can be modeled as graphs. And understanding how BFS traverses these structures helps you optimize them.

💡 Final Reflection

I loved building this small C# BFS tool — not just to crack LeetCode, but to see how it mirrors so many real-world workflows.
How do you mentally map your own work or team’s flow? Do you see graphs in your day-to-day challenges — and are you using them to your advantage?

Regards,
Pavan