DEV Community: Peter Bons

Forget MCP, Use OpenAPI for AI Agent tools

Peter Bons — Tue, 30 Sep 2025 11:32:19 +0000

This blog post demonstrates how to build an AI agent using dotnet and a Semantic Kernel plugin that calls web APIs to access external data instead of using an MCP server based on an OpenAPI document.

Introduction

Ok, you got me, it's a clickbait post title. But hear me out. If you are in to Language Models you cannot ignore the widespread enthusiasm that MCP brought. Lots of MCP servers popped up and support is widely available. From your favorite AI infused code editor to one of the many Copilots Microsoft is trying to sell you, everywhere you can plug them in. And it is not a bad thing, they can add great value to your AI agents and workflows. But there is also a dark side to the success story. First of all, a lot of MCP servers are intended to run locally and because of that, they can pose a real security risk. Second, not all of them are maintained and updated well. And what if you already invested in opening up your software by providing web APIs? That is what this post is all about. We will build an agent that can transform an OpenAPI document into a set of tools the model can call using the Semantic Kernel OpenAPI capabilities.

Getting the ingredients right

For this scenario we will build an agent that can help us answering questions about flight status and realtime flight data using te Aviationstack API. You can sign up for a free access key in under a minute. After that, you can grab their OpenAPI document from here:

We also need a model to talk to. You can run one in the cloud, use Hugging Face, Microsoft Foundry Local or something else but I choose* to use the qwen3 model through Ollama:

Ollama is the easiest way to get up and running with large language models such as gpt-oss, Gemma 3, DeepSeek-R1, Qwen3 and more..

Once installed, download and run the model:

ollama pull qwen3
ollama serve

The following should show up, verifying it's running. Time to note the port number, we will need it later.

🟢 Mtime=2025-09-29T18:51:05.926+02:00 level=INFO source=routes.go:1332 msg="server config" env="map[CUDA_VISIBLE_DEVICES: GPU_DEVICE_ORDINAL: HIP_VISIBLE_DEVICES: HSA_OVERRIDE_GFX_VERSION: HTTPS_PROXY: HTTP_PROXY: NO_PROXY: OLLAMA_CONTEXT_LENGTH:4096 OLLAMA_DEBUG:INFO OLLAMA_FLASH_ATTENTION:false OLLAMA_GPU_OVERHEAD:0 OLLAMA_HOST:http://127.0.0.1:11434

Now that we have the prerequisites in place, it is time to move on to some code. By the way, I am using a dotnet 10 single file application for this blogpost.

*Actually I tried different models like phi-4-mini, Llama3.1 and several others but Qwen3 provided the most consistent results and always succeeded to make the proper tool calls. Thing is, you get the best result by trying out the various models as all behave different depending on the use case.

Building the agent

We start by setting up Semantic Kernel.

Semantic Kernel is a lightweight, open-source development kit that lets you easily build AI agents and integrate the latest AI models into your C#, Python, or Java codebase.

#:package Microsoft.SemanticKernel@*
#:package Microsoft.SemanticKernel.Connectors.Ollama@1.65.0-alpha
#:package Microsoft.SemanticKernel.Plugins.OpenApi@*
#:package Microsoft.Extensions.DependencyInjection@10.0.0-rc.1.25451.107
#:package Microsoft.Extensions.Logging.Console@10.0.0-preview.7.25380.108

#:property PublishAot=false

using System.Web;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;
using Microsoft.SemanticKernel;
using Microsoft.SemanticKernel.ChatCompletion;
using Microsoft.SemanticKernel.Connectors.Ollama;
using Microsoft.SemanticKernel.Plugins.OpenApi;

var builder = Kernel.CreateBuilder();

var ollamaEndpoint = new Uri("http://127.0.0.1:11434");
var modelId = "qwen3";
using var loggerFactory = LoggerFactory.Create(builder => builder.SetMinimumLevel(LogLevel.Information).AddConsole());

builder.Services.AddSingleton(loggerFactory);

builder.AddOllamaChatCompletion(modelId, ollamaEndpoint);

var kernel = builder.Build();

With the foundation in place it is time to move on and import the OpenAPI document. Semantic Kernel has the ability to turn the document into a plugin that can be called by the model. The plugin will then call the web API and pass the result back to the model. You can load the OpenAPI document from file or by url. It also provides a callback method that can be used to authenticate against the api by setting the authorization header for example. In our case, the aviationstack api expects an access_key in the request:

await kernel.ImportPluginFromOpenApiAsync("flight_api",
    @"Z:\Sources\dotnet10\ai\openapi-trimmed.yaml",
    executionParameters: new OpenApiFunctionExecutionParameters()
    {
        AuthCallback = AuthenticateRequestAsyncCallback
    });

static Task AuthenticateRequestAsyncCallback(HttpRequestMessage request, CancellationToken cancellationToken = default)
{
    var queryParts = HttpUtility.ParseQueryString(request.RequestUri!.Query);
    queryParts.Set("access_key", "1052d67e5de98f2c58f664e1e5a30a12");
    var uriBuilder = new UriBuilder(request.RequestUri!)
    {
        Query = queryParts.ToString()
    };
    request.RequestUri = uriBuilder.Uri;

    Console.WriteLine($"Requesting: {request.RequestUri}");

    return Task.CompletedTask;
}

(yes, I included a real & valid access key but it is rate limited on the free tier so you're welcome to use it and try if it succeeds)

So lets add a way to prompt the model and ask some questions!

OllamaPromptExecutionSettings executionSettings = new()
{
    FunctionChoiceBehavior = FunctionChoiceBehavior.Auto(),
};

var chatGPT = kernel.GetRequiredService<IChatCompletionService>();

var history = new ChatHistory();
history.AddSystemMessage("Use a made up value for the access_key parameter.");

Console.WriteLine("You can now enter messages to send to the model. Type 'exit' to quit.");
while (Console.ReadLine() is { } line && !line.Equals("exit"))
{
    history.AddUserMessage(line);
    string assistantResponse = string.Empty;
    await foreach (var result in chatGPT.GetStreamingChatMessageContentsAsync(history, executionSettings, kernel))
    {
        assistantResponse += result.Content;
        Console.Write(result.Content);
    }

    history.AddAssistantMessage(assistantResponse);
}

Play Time!

So, let's ask a question: when is the next flight departure from AMS with destination CDG?

The next scheduled flight from Amsterdam (AMS) to Charles de Gaulle (CDG) is:

Flight: Aeromexico AM6192
Departure: September 29, 2025 at 11:35 AM (AMS)
Arrival: September 29, 2025 at 12:55 PM (CDG)

Flight Status: Scheduled
Estimated Arrival Delay: 46 minutes
Departure Delay: 77 minutes

This is the earliest flight found for your route. Let me know if you need further details!

If you take a look at the response from the LLM you will see it reasons about what parameter values to use when calling the tool:

[..]
So the function call would be to flight_api_Flights with access_key, dep_iata=AMS, arr_iata=CDG, flight_status=scheduled, limit=1. That should get the next scheduled flight from AMS to CDG. If there's no scheduled flight, maybe check for active ones. But the user is asking for the next flight, so scheduled is the right status. Let's proceed with that.

info: Microsoft.SemanticKernel.KernelFunction[0]
Function flight_api-Flights invoking.
Requesting: https://api.aviationstack.com/v1/flights?access_key=1052d67e5de98f2c58f664e1e5a30a12&limit=1&flight_status=scheduled&dep_iata=AMS&arr_iata=CDG
info: Microsoft.SemanticKernel.KernelFunction[0]
Function flight_api-Flights succeeded.
info: Microsoft.SemanticKernel.KernelFunction[0]
Function flight_api-Flights completed. Duration: 0.6109388s

Okay, let me process the user's query and the tool response. The user asked for the first next flight from AMS to CDG. The tool call used the Flights endpoint with the parameters access_key, dep_iata=AMS, arr_iata=CDG, flight_status=scheduled, and limit=1. The response from the tool shows a flight scheduled for 2025-09-29, departing AMS at 11:35 and arriving at CDG at 12:55. The airline is Aeromexico, flight number AM6192.
[..]

As instructed, it used a dummy API key which is replaced by Semantic Kernel with the real value when the request is about to be made to demonstrate how you could handle more complex authentication scenarios.

The full model output can be found here.

Trimming large OpenAPI documents

Most times you are calling a subset of the endpoints available. Take the Microsoft Graph API for example, the OpenAPI document is very large resulting in too much functions available for the model to work with. Luckily for us there is tooling for that. I used Microsoft Hidi to transform the document by specifying only the operations I am interested in:

 hidi transform -d .\openapi.yaml -f yaml -o .\openapi-trimmed.yaml -v 3.0
 --op Flights,Routes

The command above creates a new yaml file based on the original, excluding all endpoints except the Flights and Routes operations endpoints.

Wrapping up

We have seen how easy it is to convert an OpenAPI document into a set of tools that a model can call and how to handle authentication. There are still enough points we haven't touched yet like error handling, for example I hit some rate limits that the model couldn't handle.

When you already have a set of well defined APIs it is a very fast and easy way to integrate them into your agents.

Full source can be found here.

Any questions or comments? Drop them below!

Give your AI Agent Vibe Coding Superpowers using .Net 10

Peter Bons — Sun, 22 Jun 2025 10:57:08 +0000

This blog post demonstrates how to build an AI agent using dotnet that is capable of writing and executing C# code to perform complex tasks.

Introduction

It is an exciting time to live in when it comes to generative AI. Long gone are the days when an LLM is merely capable of generating responses based on the data they are trained on. Nowadays they are capable of doing much more by giving them the proper tools for example. Initiatives like the Model Context Protocol (MCP) are driving a new era and MCP servers are popping up everywhere.

Another term you might have heard of is "vibe coding". According to ChatGPT it means:

Vibe coding with AI is like whispering your app dreams to a super-fast coder who never sleeps—you describe what you want (“make the button red,” “add cat purring”), and the AI writes it. You review, tweak, rinse, repeat… no need to grok every line. It’s part brainstorming session, part code genie — fast, fun, and sometimes buggy magic! 😜

And, in other news, Microsoft has already started working on .Net 10. Lots of new goodies and stuff but one thing that stands out is the ability to do something like dotnet run app.cs. Yes, that's right: single file applications are finally coming our way.

With those 3 ingredients, LLMs, tool calling and .Net 10, we can create our own vibe coding agent to accomplish tasks that go beyond answering simple questions based on the data it is trained on. So let's get dive in! For the magic we will use the Microsoft.Extensions.AI libraries.

Setting up the stage

Let's start with importing some required packages and setting up the chat client. I use a model hosted on Azure AI Foundry but it can be any model hosted anywhere as long as it supports tool calling.

#:package Azure.AI.OpenAI
#:package Microsoft.Extensions.AI
#:package Microsoft.Extensions.Logging.Console@10.0.0-preview.5.25277.114
#:package Microsoft.Extensions.AI.OpenAI@9.5.0-preview.1.25265.7

using Azure.AI.OpenAI;
using Microsoft.Extensions.AI;
using Microsoft.Extensions.Logging;
using System.ClientModel;
using System.Diagnostics;

var runId = Guid.NewGuid();

var azureOpenAIEndpoint = "https://<your-endpoint>.cognitiveservices.azure.com/";
var azureOpenAIModelId = "gpt-4.1";

using var loggerFactory = LoggerFactory.Create(builder => builder.SetMinimumLevel(LogLevel.Information).AddConsole());

var client =
    new ChatClientBuilder(
        new AzureOpenAIClient(new Uri(azureOpenAIEndpoint), new ApiKeyCredential("<your-api-key>"))
        .GetChatClient(azureOpenAIModelId).AsIChatClient())
    .UseLogging(loggerFactory)
    .UseFunctionInvocation(loggerFactory)
    .Build();

So now we got the basic stuff, what's next? We already know that LLMs are capable of writing code, so that is covered. However, we need to give the LLM code execution capabilities as well if we want to succeed. Let's write a tool for that. In the code below we have defined a method that takes a string for input, write that string to a file and execute the code using dotnet run. There is some ceremony to be able to track the different executions in there as well so we can see how the code evolves when the model encounters compile time or runtime errors.

var chatOptions = new ChatOptions
{
    Tools = [AIFunctionFactory.Create((string code) =>
    {
        var logger = loggerFactory.CreateLogger("CodeExecution");

        var codeFileName = @$"c:\temp\{DateTime.Now.ToString("HHmmssfff")}-{runId}.cs";
        File.WriteAllText(codeFileName, code);
        var process = new Process
        {
            StartInfo = new ProcessStartInfo
            {
                FileName = "dotnet",
                Arguments = $"run {codeFileName}",
                RedirectStandardOutput = true
            }
        };

        process.Start();
        process.WaitForExit(TimeSpan.FromMinutes(1));

        var output = process.StandardOutput.ReadToEnd();
        logger.LogInformation("Code execution output: {Output}", output);

        return output;
    },
    description: "Execute the provided code.")]
};

The general idea is that we provide the LLM with a tool using ChatOptions, ask the LLM to perform a task using a prompt and have it automatically invoke the tool if it thinks it is needed to generate an answer. We enable this by calling UseFunctionInvocation.

Now all we need is a system prompt that explains the model how to handle a given task. Finally, we need a prompt defining the task at hand:

var history = new List<ChatMessage>
    {
    new(ChatRole.System, """
        Write code to answer the question. 

        If you need to use a NuGet package, specify the package name in the code like this: #:package PackageName. Some examples:
        #:package Humanizer@9.5.0-preview.1.25265.7
        #:package SemanticKernel
        #:package Newtonsoft.Json

        A code block should start with the required NuGet packages, if any, followed by one or more using statements, followed by the code.
        You can directly write code statements without a program class with a main method.

        ### Example 1
        #:package Humanizer@1.2.8
        #:package SomePackage

        using System;

        Console.WriteLine("123".Humanize());

        ### Example 2
        #:package Microsoft.Extensions.Logging.Console

        using System.IO;

        var text = await File.ReadAllTextAsync("c:\\temp\\file.txt");
        Console.WriteLine(text);

        ###

        Write and execute code to answer the question. Do not ask the user for any input, just complete all the steps below
        by writing and executing the code without asking for clarification or consent.

        """),
    new(ChatRole.User,
        """
        1. Fetch the csv file from the url 'https://raw.githubusercontent.com/fgeorges/star-wars-dataset/refs/heads/master/csv/films/films.csv'
        2. Analyze the content and determine the delimiter used in the csv file. Keep in mind that text columns may contain commas as well, e.g. "A New Hope, Episode IV".
        3. Determine which columns are present in the csv file and what data the columns contain.
        4. Order the movies by release date, Newest first.
        5. Write a .docx word document at 'c:\\temp\\star_wars_movie.docx' with one line per page with the following information:
            - release date
            - title
            - description
        """
        )
    };

If we take a closer look at the system prompt you'll see that it has clear instructions on how to reference NuGet packages and how to structure the code, accompanied with some examples. The reason for this is that LLMs are trained on lots of existing C# code that is written before .Net 10 was introduced. Without that it will generate an old school Program class with a Main method and won't be able to reference packages. It took some prompt tweaking to "unlearn the old way" of writing a simple program.

The final step is to feed the model the prompts and wait for it to complete its vibe coding session. 😄

var result = await client.GetResponseAsync(history, chatOptions);
Console.WriteLine($"LLM response: {result}");

Reviewing the performance

The whole code file can be found as a gist here. Save it and then run the code using dotnet run vibecoding_agent.cs

If everything is ok you will see one or more files popping up in C:\Temp. If the LLM is in a good mood it will be just one but more often it needs a few iterations before a correct code file is written. Since the model is fed with the output of the dotnet run command it can detect compile time and runtime errors and rewrite the code to handle that.

The output of dotnet run is the response of the LLM, my last execution resulted in this response:

LLM response: Analysis and Results:

Delimiter: The delimiter used in the CSV is a comma (,).

Columns present:

title

episode_id

opening_crawl

director

producer

release_date

created

edited

url

desc

Data in Columns:

title: The movie title (e.g. "A New Hope").

episode_id: The Star Wars episode number.

opening_crawl: The long Star Wars intro text that appears at the start of the film.

director: Film director name(s).

producer: Producer name(s).

release_date: Release date of the movie (e.g. "1977-05-25").

created, edited: Timestamps (likely for internal dataset management).

url: URL reference for the film.

desc: Another description, but appears redundant with opening_crawl.

Word Document Output:

The movies are ordered by release date, newest first, and written one per page. Each page includes release date, title, and description (using opening_crawl).

File written:

c:/temp/star_wars_movie.docx

Summary of document:

The document contains 7 movies, each on its own page, with release date, title, and description.

Let me know if you want to see the content or need a different format!

The full output, including the final word document and all the iterations can be found here.

Final Thoughts

I've tried different models and the results vary. Some models stop half way, present the code to the user and ask whether to continue or not. Others will write the code but ask you to execute it, they seems to ignore the tools presented even though they are capable of tool calling. It takes some trial and error to craft a good prompt and fix this behavior.

Interesting as it might be, it comes with a strong warning: the code should only ever run in an isolated, sandboxed environment because there is absolutely no guarantee that no malicious code is executed or flawed dependencies are used.

So where does that leave us? What would be the use case for these kind of agents? I don't know. I was inspired by AutoGen for .Net, which has the capability to run code snippets. I think .Net 10 helps lower the barrier to create Agents with coding capabilities.

So, what do you think? Do you see this as a useful feature or .. ? I am really curious about your opinion, so don't hesitate to drop a comment below!

Monitoring non-web apps using Azure Application Insights (Part 2: Basic Instrumentation)

Peter Bons — Thu, 08 Aug 2019 09:54:58 +0000

Welcome to the second post of this series covering the monitoring of non-web apps using Azure Application Insights.

In the previous post we created an Application Insights resource using the Azure Portal and we integrated Application Insights into a simple console application. As a result we got live monitoring of our application as shown below.

Now it is time to add instrumentation to our code. The Application Insights SDK allows these entities to be tracked:

Page Views
Exceptions
Requests
Traces
Dependencies
Metrics
Events

When you add Application Insights to a web application the whole tracking of page views, request, dependencies etc. is done automatically. Unfortunately, when building a Console, WPF or WinForms application we need to manually create telemetry items and send them using the SDK.

To send telemetry to Application Insights we need a TelemetryClient. There are several ways to create a telemetry item but there is one important thing to keep in mind. The real power of Application Insights is the ability to relate telemetry items. You do want to know what requests belong to what page view, what request triggered a dependency call and what was happening when an exception was thrown. We will come back to this later, let us first send some telemetry. We will extend the console application we created in the previous post.

Say we add a method like this to the Program class of the console application:

private static async Task MakeHttpRequestAsync()
{
    try
    {
        using (var httpClient = new HttpClient())
        {
            var result = await httpClient.GetStringAsync("http://www.blank.org");
            Console.WriteLine(result);
        }
    }
    catch (HttpRequestException ex)
    {
        Console.WriteLine("Error getting text.");
    }
}

Given the code above I would like Application Insights to track that the method is called and how long it takes to execute. I would also be very happy to be able to see the HttpRequestException being logged in Application Insights. Finally, I would be thrilled to know how long the call to the external dependency call to http://www.blank.org took. Also, if an exception other than an HttpRequestException occurs, I would like to mark the method call as being failed.

So, lets extend the method and use a TelemetryClient to track the various telemetry items:

private static async Task MakeHttpRequestAsync(T)
{
    var telemetryClient = new TelemetryClient(TelemetryConfiguration.Active);
    using (var operation = 
                 telemetryClient.StartOperation<RequestTelemetry>(nameof(MakeHttpRequestAsync)))
    {
        try
        {
            using (var httpClient = new HttpClient())
            {
                var result = await httpClient.GetStringAsync("http://www.blank.org");
                telemetryClient.TrackTrace($"The http call returned '{result}'");
                Console.WriteLine(result);
            }
        }
        catch (HttpRequestException ex)
        {
            telemetryClient.TrackException(ex);
            Console.WriteLine("Error getting text.");
        }
        catch
        {
            operation.Telemetry.Success = false;
            throw;
        }
    }
}

We then modify the code of the Main method in the Program class created in the previous post to call this method:

static async Task Main(string[] args)
{
    ConsoleKeyInfo keyInfo = new ConsoleKeyInfo();

    while (keyInfo.Key != ConsoleKey.Q)
    {
         await MakeHttpRequest();
         keyInfo = Console.ReadKey();
    }

    Console.WriteLine("Press any key to run again or Q to exit.");
    Console.ReadKey();
}

Let's walk through the code. We first create an instance of TelemetryClient and we initialize it with a TelemetryConfiguration.Active. This will apply the configuration as defined in the file ApplicationInsights.config.

Next, we start an operation to track the method call as a Request telemetry item in Application Insights using TelemetryClient.StartOperation()

using (var operation = 
             telemetryClient.StartOperation<RequestTelemetry>(nameof(MakeHttpRequestAsync)))

When the operation gets disposed at the end of the using block the total duration from start to end is calculated and the Request item is send to Application Insights.

Next, in addition to tracking entities like Exceptions or Requests you can also log some arbitrary text in Application Insights using a Trace telemetry item. This is done using the line telemetryClient.TrackTrace($"The http call returned '{result}'");

In case of an exception we are able to handle we can log the exception in Application Insights. This is done by calling telemetryClient.TrackException(ex);.

Finally, when an exception occurs that we cannot handle we can mark the call to the method as being failed by setting the value of the Success property of the RequestTelemetry to false. To get to the RequestTelemetry of the Operation initiated by calling TelemetryClient.StartOperation() we can use the Telemetry property:

operation.Telemetry.Success = false;

Then we re-throw the exception so the caller can deal with it.

Before launching the application, open a tab in your browser and navigate to the Live Metrics Stream in Application Insights.

Now, if we were to run the application we would see the telemetry appear in Application Insights. Note that it can take a few seconds before the Live Metrics Stream is initialized and a few more moments for telemetry items to appear in the portal:

If we click on the request we get a more detailed view.

As you can notice the telemetry items are grouped together. The portal will show you that the outgoing Http call originated from the request. That is the benefit of using `TelemetryClient.StartOperation() as opposed to doing something like telemetryClient.TrackRequest(...);. Once an operation is started all telemetry items that are sent in the scope of the operation are linked together.

Furthermore we you can see that the outgoing Http call is detected by Application Insights and automatically logged. This is done by the DependencyTrackingTelemetryModule. Application Insights can track more than http calls as seen in the docs:

The cool thing is, the telemetry created by the application is also captured by the Live Metrics Stream!

The bad thing however, is the amount of code involved in instrumenting an application like this. Imagine having to write this code for each and every method you want to instrument. In the next blog post I will show you a way to make life a bit easier when it comes to this so stay tuned. I promise it won't take as long as it took for me to write this second part :-)

Service Fabric Remoting: Interception & Custom Headers

Peter Bons — Wed, 09 Jan 2019 19:46:45 +0000

Service Fabric is a distributed systems platform for packaging, deploying, and managing stateless and stateful distributed applications and containers at large scale. Service Fabric runs on Windows and Linux, on any cloud, any datacenter, across geographic regions, or on your laptop.

Introduction

In this post we will learn two things that can make life easier to support advanced scenarios when using Service Remoting for communication between services and actors. We will do this by making use of a simple library I created. It provides you with the ability to:

Intercept service fabric remoting messages so you can take action when the call is about to be made and after it has been delivered.
Add custom headers to the remoting messages. This can be used to, for example, add a trace identifier for call tracing & logging purposes.

Message Interception

Messages can be intercepted on both the sending side and the receiving side

Client-side message interception

On the receiving side messages can be intercepted using the BeforeHandleRequestResponseAsync and AfterHandleRequestResponseAsync extension points when creating a service listener:

protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
{
    yield return new ServiceInstanceListener(context =>
        new FabricTransportServiceRemotingListener(context,
            new ExtendedServiceRemotingMessageDispatcher(context, this)
            {
                // Optional, log the call before being handled
                BeforeHandleRequestResponseAsync = reqInf =>
                {
                    var sw = new Stopwatch();
                    sw.Start();
                    ServiceEventSource.Log.ServiceMessage(Context, 
                            $"BeforeHandleRequest {reqInf.Service} {reqInf.Method}");
                    return Task.FromResult<object>(sw);
                },
                // Optional, log the call after being handled
                AfterHandleRequestResponseAsync = respInf =>
                {
                    var sw = (Stopwatch) respInf.State;
                    ServiceEventSource.Log.ServiceMessage(Context, 
                            $"AfterHandleRequest {respInf.Method} took {sw.ElapsedMilliseconds}ms");
                    return Task.CompletedTask;
                }
            }));
}

Server-side message interception

On the sending side messages can be intercepted using the BeforeSendRequestResponseAsync and AfterSendRequestResponseAsync extension points when creating the ExtendedServiceRemotingClientFactory on constructor of the ServiceProxyFactory:

var proxyFactory = new ServiceProxyFactory(handler => // or ActorProxyFactory in case of actors
    new ExtendedServiceRemotingClientFactory(
        new FabricTransportServiceRemotingClientFactory(remotingCallbackMessageHandler: handler), 
            customHeadersProvider)
    {
        // Optional, log the call before being handled
        BeforeSendRequestResponseAsync = reqInf =>
        {
            var sw = new Stopwatch();
            sw.Start();
            Console.WriteLine($"BeforeSendRequest {reqInf.Method}");
            return Task.FromResult<object>(sw);
        },
        // Optional, log the call after being handled
        AfterSendRequestResponseAsync = respInf =>
        {
            var sw = (Stopwatch)respInf.State;
            var duration = sw.ElapsedMilliseconds;
            Console.WriteLine($"AfterSendRequest {respInf.Method} took {duration}ms");
            return Task.CompletedTask;
        }
    });

Custom Headers

Custom headers can be used to pass data between the sender and the receiver like tracing information or security context data. Using the BeforeHandleRequestResponseAsync and AfterHandleRequestResponseAsync actions additional logging can be applied monitor the flow between remoting calls.

Prepare the Reliable Service

Modify the service and create a listener that can handle the requests:

protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
{
    yield return new ServiceInstanceListener(context =>
        new FabricTransportServiceRemotingListener(context,
            new ExtendedServiceRemotingMessageDispatcher(context, this)));
}

Adding custom headers (the caller)

var customHeaders = new CustomHeaders
{
    {"Header1", DateTime.Now},
    {"Header2", Guid.NewGuid()}
};

var serviceUri = new Uri("fabric:/ServiceFabric.Remoting.CustomHeaders.DemoApplication/DemoService");
var proxyFactory = new ServiceProxyFactory(handler => 
                    new ExtendedServiceRemotingClientFactory(
                        new FabricTransportServiceRemotingClientFactory(remotingCallbackMessageHandler: handler), 
                            customHeaders));
var proxy = proxyFactory.CreateServiceProxy<IDemoService>(serviceUri);

There is an overload of the Create method that accepts a Func. This is useful in scenarios where the created proxy factory or proxy is reused. Since creating a proxy factory is expensive this is the preferred way if you need dynamic header values. The func is invoked on every request made using the proxy.

Reading custom headers (the callee)

The receiving service or actor can extract the values in the custom headers using the RemotingContext class:


public async Task<string> SayHello()
{
    var remotingContext =
        string.Join(", ", RemotingContext.Keys.Select(k => $"{k}: {RemotingContext.GetData(k)}"));

    ServiceEventSource.Log.ServiceMessage(Context, 
            $"SayHelloToActor got context: {remotingContext}");
    return Task.FromResult($"Got the following message headers: {remotingContext}")
}

What is next?

More documentation and a demo Service Fabric application can be found at this repository:

Expecho / ServiceFabric-Remoting-CustomHeaders

This package allows injecting custom message headers into remoting messages (Actors and Reliable Services, V2 remoting only) at runtime. The headers are available client side to read. It also provides message interception using BeforeHandleRequestResponseAsync and AfterHandleRequestResponseAsync to act on remoting events.

ServiceFabric.Remoting.CustomHeaders

This package allows injecting custom headers into remoting messages (Actors and Reliable Services, V2 remoting only) at runtime. The headers are available client side to read It also provides message interception using BeforeHandleRequestResponseAsync and AfterHandleRequestResponseAsync to act on remoting events.

Common used classes:

NuGet

Download the NuGet package

Examples

This repository includes a Service Fabric application for demonstration purposes. A Console Application is used to access the application and shows the usage of the package.

Usage scenarios

Custom headers can be used to pass data between the sender and the receiver like tracing information or security context data. Using the BeforeHandleRequestResponseAsync and AfterHandleRequestResponseAsync actions additional logging can be applied monitor the flow between remoting calls.

How to use

Prepare Reliable Services

Modify the service and create a listener that can handle the requests

protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
{
    yield return new ServiceInstanceListener

…

View on GitHub

Reporting Metrics Using .Net (Core) EventSource and EventCounter

Peter Bons — Sun, 06 Jan 2019 14:22:54 +0000

Hardly anybody argues the importance of instrumenting your code and there are some built-in log options in the .Net Framework, not to mention countless great 3rd party libraries like Nlog, Serilog and Log4Net. But when it comes to reporting metrics (Think: requests per minute, usage, message rate and things like that) the built-in support is very limited. Of course we have the Performance Counters but they cannot be used cross-platform as they are Windows only. Luckily there is a relative simple way to report metrics using the EventSource class that is cross-platform and a part of the Framework so there is no need for external dependencies.

Introducing EventCounters

ETW (Event Tracing for Windows) and the EventSource class have long been a part of the .Net Framework. EventSources are heavily used by the framework itself, and by a lot of (3rd party) libraries as well. It allows you to use structured logging in your application code with a minimal performance overhead. The data can be collected in-process or out-of-process using tools like PerfView.

In this blogpost we will take a closer look to the not so well-known EventCounter class that lets us define and report metrics using an EventSource. I specifically want to show how you can read those counters in-process using an EventListener as this is not very well documented.

As a starter, let us see what the CoreFx team has to say about EventCounters (taken from their tutorial):

While EventSource is fast, logging too many events for very frequent events is still a performance hit. In this tutorial, we will introduce EventCounter, a mechanism for measuring performance for very frequent events.

For event that happen very frequently (for example, if it happen every few milliseconds), in general, you will want the performance overhead per event to be very low (e.g. less than a millisecond), otherwise it is going to cost a significant performance overhead. Logging an event, at the end of the day, need to write something to the disk. If the disk is not fast enough, you will lost events. We need a solution other than logging the event itself.

When dealing with large number of events, knowing the measure per event is not very useful either. Most of the time all we need is just some statistics out of it. So we could crank the statistics within the process itself and then write an event once in a while to report the statistics, that's what EventCounter will do for us.

Sounds great, doesn't it? It is a matter of defining and reporting metrics and the framework will do the aggregation and calculation in memory. All we need to do is to specify the interval at which the data is outputted.

The Recipe

First, we need to define an EventSource that will contain the EventCounter instances. You can dynamically create EventCounter instances at runtime but, due to a bug I documented here, you will have the create at least one EventCounter instance in the constructor.

[EventSource(Name = "My-CustomMetricsEventSource-Minimal")]
public sealed class CustomMetricsEventSource : EventSource
{
    private EventCounter methodDurationCounter;

    private Dictionary<string, EventCounter> dynamicCounters =
        new Dictionary<string, EventCounter>();

    public static CustomMetricsEventSource Log = new CustomMetricsEventSource();

    public CustomMetricsEventSource()
    {
        methodDurationCounter = new EventCounter(nameof(methodDurationCounter), this);
    }

    public void ReportMethodDurationInMs(long milliseconds)
    {
        methodDurationCounter.WriteMetric(milliseconds);
    }

    public void ReportMetric(string name, float value)
    {
        if (!dynamicCounters.TryGetValue(name, out EventCounter counterInstance))
        {
            counterInstance = new EventCounter(name, this);
            dynamicCounters.Add(name, counterInstance);
        }
        counterInstance.WriteMetric(value);
    }
}

We will use CustomMetricsEventSource to log our metrics in a console application. But we also need a listener that picks up the logged metrics and sends them to a destination. In this example we will write the data to the console using a custom implementation of an EventListener:

internal class CustomMetricsEventListener : EventListener
{
    protected override void OnEventWritten(EventWrittenEventArgs eventData)
    {
        var counterData = eventData.ToEventCounterData();

        // Only write to console if actual data has been reported
        if (counterData?.Count == 0)
            return;

        Console.WriteLine(
            $"Counter {counterData.Name} reported values " +
            $"Min: {counterData.Min}, " +
            $"Max: {counterData.Max}, " +
            $"Count {counterData.Count}, " +
            $"Mean {counterData.Mean}, " +
            $"StandardDeviation: {counterData.StandardDeviation}, " +
            $"IntervalSec: {counterData.IntervalSec}");
    }
}

The code listened above uses the ToEventCounterData method. This is actually an extension method. It returns an EventCounterData instance which makes it easier to work with the reported metric data:

public static class EventWrittenEventArgsExtensions
{
    public static bool IsEventCounter(this EventWrittenEventArgs eventData)
    {
        return eventData.EventName == "EventCounters";
    }

    public static EventCounterData ToEventCounterData(this EventWrittenEventArgs eventData)
    {
        if (!eventData.IsEventCounter())
            return null;

        return new EventCounterData(eventData);
    }
}

public class EventCounterData
{
    public EventCounterData(EventWrittenEventArgs eventData)
    {
        var payload = (IDictionary<string, object>) eventData.Payload[0];

        Name = payload["Name"].ToString();
        Mean = (float)payload["Mean"];
        StandardDeviation = (float)payload["StandardDeviation"];
        Count = (int)payload["Count"];
        IntervalSec = (float)payload["IntervalSec"];
        Min = (float)payload["Min"];
        Max = (float)payload["Max"];
    }

    public string Name { get; }
    public float Mean { get; }
    public float StandardDeviation { get; }
    public int Count { get; }
    public float IntervalSec { get; }
    public float Min { get; }
    public float Max { get; }
}

Finally we can create the console application that will call CustomMetricsEventSource to log metric values. The CustomMetricsEventListener is constructed in such a way that the metrics are outputted once per second.

It is important to understand that it is the configuration of the CustomMetricsEventListener that determines the metric reporting interval. This is done by passing a numeric value specifying the interval in seconds to the EventCounterIntervalSec argument.

class Program
{
    static void Main(string[] args)
    {
        var reader = new CustomMetricsEventListener();
        var arguments = new Dictionary<string, string>
        {
            {"EventCounterIntervalSec", "1"}
        };
        reader.EnableEvents(CustomMetricsEventSource.Log, EventLevel.LogAlways, EventKeywords.All, arguments);

        var random = new Random();
        for (int i = 0; i <= 10; i++)
        {
            SleepingBeauty(random.Next(10, 200));
        }

        Console.ReadKey();
    }

    static void SleepingBeauty(int sleepTimeInMs)
    {
        var stopwatch = Stopwatch.StartNew();

        Thread.Sleep(sleepTimeInMs);

        stopwatch.Stop();

        CustomMetricsEventSource.Log.ReportMethodDurationInMs(stopwatch.ElapsedMilliseconds);
        CustomMetricsEventSource.Log.ReportMetric("someCounter", DateTime.Now.Millisecond);
    }
}

When we run the program we will see the metric values being reported to the console:

Counter methodDurationCounter reported values Min: 23, Max: 215, Count 8, Mean 113,125, StandardDeviation: 64,10429, IntervalSec: 1,026394

Counter someCounter reported values Min: 87, Max: 982, Count 9, Mean 603,1111, StandardDeviation: 269,2832, IntervalSec: 1,026394

Do mind that the metrics will always be reported at the specified interval (using EventCounterIntervalSec) even if no call to the WriteMetric method of an EventCounter instance is made. All numeric values, except IntervalSec, will have the default value 0.

You can find the whole working example in my GitHub repository:

Expecho / Blog

Placeholder for code I blogged about, see

Blog

Placeholder for code I blogged about

Folders in this repository

Metrics: Reporting Metrics Using .Net (Core)

View on GitHub

What is next?

Of course, reporting those values to the console does not add much value, it is up to you to send the data to your own logging backend. You could for example send them as custom metrics to Application Insights using the EventCounterCollectionModule, log to your ELK stack or whatever log system you are using.

I really wish reporting metrics gets a bit more attention since having metrics data available is very important in order to have a detailed insight in how your application is behaving. For example, you can use metrics to scale in or out or get insights in the usage of certain parts of your application. Most logging frameworks I know of do not cater for metrics.

There was a lot of discussion about whether or not the support writing metric using the new ILogger interface of .Net Core but in the end there is no support for it right know. More details about the how and the why can be read in the issue created for this discussion:

Add support for reporting application metrics via logging #708

anurse posted on Sep 19, 2017

Overview

We want to enable applications to emit arbitrary named metrics and have them captured by telemetry/logging systems (App Insights, Elasticsearch/ELK, etc.) as well as other metrics systems (Statsd, InfluxDB, etc.). An abstraction is desired in order to allow applications to emit metrics without being coupled to the destination of the metrics, particularly with features like App Insights auto-lightup where the app doesn't directly depend upon App Insights.

Proposal

We will add support for metrics reporting to ILogger. It will be done via a new companion interface IMetricsLogger, which loggers may optionally implement. Applications can emit metrics through this interface (see API below), and logger providers which support metrics can receive and process those metrics. Metrics are (name, value) tuples, where value is always floating point number. Metrics are expected to be viewed in aggregate, hence it doesn't make sense to use a generic data type like object for the metric, so metric values are always doubles. Supporting arbitrary types of metric values is a non-goal. Reporting metrics should be as efficient as possible, especially in the case where no logger provider is registered to listen for them, or they are filtered out.

Why add to `ILogger`?

Initially, I considered developing a new abstraction for Metrics. However, I encountered a few concerns:

We would need to develop a structure for naming/organizing metrics (likely using type/namespace names as a base)
We would need to develop a structure for filtering metrics (by categories, names, granularities, etc.)
Many telemetry systems provide support for both log and metric collection, and would have to provide a new system
Consumers have to pull in two different diagnostics reporters from DI (ILogger<T>, IMetricReporter<T>, etc.)
This would create Yet Another Diagnostics Abstraction (on top of EventSource, EventCounters, DiagnosticSource, Perf Counters, yada yada yada (see what I did there? ;P))

The fact that 1 and 2 above already exist in the Logging pipeline, and many metric sinks are also logging sinks, led to the idea of integrating metrics into Logging rather than creating a completely new abstraction.

The main reason why we would not want to add this to ILogger would be a risk

The API

`IMetricLogger`

Optional companion interface for ILogger implementations to indicate their support for metrics. The ILogger instances returned by ILoggerProvider are expected to implement this interface if and only if they wish to receive metrics.

namespace Microsoft.Extensions.Logging
{
    public interface IMetricLogger
    {
        /// <summary>
        /// Define a new metric with the provided name and return an <see cref="IMetric"/> that can be used to report values for that metric.
        /// </summary>
        /// <param name="name">The name of the metric to define</param>
        /// <returns>An <see cref="IMetric"/> that can be used to report values for the metric</returns>
        IMetric DefineMetric(string name);
    }
}

`IMetric`

Interface that allows metric data to be reported. Metric values

namespace Microsoft.Extensions.Logging
{
    public interface IMetric
    {
        /// <summary>
        /// Record a new value for this metric.
        /// </summary>
        /// <param name="value">The value to record for this metric</param>
        void RecordValue(double value);
    }
}

`LoggerMetricsExtensions`

Provides an extension method on ILogger to enable consumers to emit metrics, even if the underlying logger provider doesn't support it (of course, the metrics will be ignored in that case).

namespace Microsoft.Extensions.Logging
{
    public static class LoggerMetricsExtensions
    {
        /// <summary>
        /// Define a new metric with the provided name and return an <see cref="IMetric"/> that can be used to report values for that metric.
        /// </summary>
        /// <remarks>
        /// If none of the registered logger providers support metrics, values recorded by this metric will be lost.
        /// </remarks>
        /// <param name="name">The name of the metric to define</param>
        /// <returns>An <see cref="IMetric"/> that can be used to report values for the metric</returns>
        public static IMetric DefineMetric(this ILogger logger, string name)
        {
            if(logger is IMetricLogger metricLogger)
            {
                return metricLogger.DefineMetric(name);
            }
            return NullMetric.Instance;
        }
    }
}

`MetricValueExtensions`

Extension methods for IMetric to support other common metric value types (as mentioned above, the underlying type is still double, so the value must be representable as a double).

Suggestion: We could have a .Time() API that returns an IDisposable which uses a Stopwatch to do the timing for you as well. That would be easy to add later though.

using System;

namespace Microsoft.Extensions.Logging
{
    public static class MetricValueExtensions
    {
        /// <summary>
        /// Record a new value for this metric.
        /// </summary>
        /// <remarks>
        /// This is a convenience method that will convert the <see cref="TimeSpan"/> to a <see cref="double"/> via
        /// the <see cref="TimeSpan.TotalMilliseconds"/> property.
        /// </remarks>
        /// <param name="metric">The metric to record the value on.</param>
        /// <param name="value">The value to record for this metric.</param>
        public static void RecordValue(this IMetric metric, TimeSpan value) => metric.RecordValue(value.TotalMilliseconds);
    }
}

`Logger` updates

The aggregate Logger class we return from LoggerFactory.CreateLogger would be updated to support IMetricsLogger, even if none of the ILoggers it aggregates support it. It would only send metrics to the loggers that are known to support the interface.

`Define`/`Record` pattern

In order to keep the performance cost as low as possible for recording the actual metric value, the API uses a Define/Record pattern. Consumers should expect to call DefineMetric("foo") once for a particular value of "foo" and store the result as globally as possible (in singleton types, etc.). It is DefineMetric that does the bulk of the work to set up the metric recording. After calling DefineMetric, the RecordValue call on the IMetric interface can choose how to store the value based on the providers needs. For example, in a provider that plans to send pre-aggregated metrics, the RecordValue could simply update rolling aggregate values and then drop the actual recording (thus having constant storage requirements for each metric). If a provider needs to report individual metrics, it can use dynamically-allocated buffers or ring buffers, depending upon the configuration and the needs of the provider. As an example of an IMetric implementation based on pre-aggregating data, see https://gist.github.com/anurse/03c6746204317bd3616c372b4df9dbba

Filtering Metrics

Metrics should be filterable, and they should participate in the existing Logger filtering pipeline. My current proposal is that Metrics are treated like LogLevel.Critical messages, in that if the category is enabled at all, the metrics are written. We could consider capturing a LogLevel in .DefineMetric and using that to provide different "levels" of metrics. Since the existing filters only let you filter by Provider, Category, and Level, it is very difficult to filter out specific metrics by name (as that would require a new Filter structure). This may make LogLevel support for metrics more important.

@pakrym and I talked and came up with a specific suggestion

Metrics can be filtered at the provider and category name, but there is no concept of a LogLevel for metrics. However, filters can disable all metrics for a particular provider/category combination. To do this, we'll add an AllowMetrics boolean to LoggerFilterRule which defaults to true. When writing a metric, we'll check the provider and category name against the filter options as well as checking this boolean.

Scopes and Property Bags

FEEDBACK REQUESTED

My initial thought is that Metrics exist outside of scopes, as they are generally aggregated and Scopes imply per-event data. Providers could, in theory, give their IMetric instances access to read active scope data, and attach them to metrics if they choose (for example, systems that report unaggregated metrics may want to). For similar reasons, property bags (i.e. Log Values/Structured Logging, etc.) don't really make sense for metrics in general as they are usually aggregated. Having said that, many providers do support arbitrary properties (InfluxDB, App Insights), so some level of support may be useful. We could easily add an optional parameter to .RecordValue to allow adding arbitrary properties to each metric, and providers could choose to disregard it if it doesn't make sense for that provider.

Impact on existing Providers

There is minimal impact on existing Providers. Because the interface provides an opt-in model for a provider to receive metrics, existing providers are unaffected. I'd imagine providers like Serilog would not participate in this system as they don't have an infrastructure for metrics (/cc @nblumhardt , I may be wrong!). Providers like App Insights may choose to either add metrics support to their existing providers or add new providers that only handle metrics (and ignore log messages) that are co-registered.

View on GitHub

One year of answering Stack Overflow questions. The Good, The Bad and The Ugly.

Peter Bons — Sun, 30 Dec 2018 20:53:48 +0000

I have been a member of Stack Overflow for a long time now, asking the occasional question now and then. But is has not been until the beginning of this year that I started being more involved in the community by answering questions. So far it has been an overall pleasant experience, and given I almost reached 10k rep. in one year tells me that most of my effort actually helped people out.

In this post I like to share my experience of being a contributor to this well-known community.

The Good

There are a couple of things I like about doing this. For one thing, I like sharing knowledge and helping people out by solving some of their problems. It does not take that much time (I do pick my battles though, I will came back to this later) and I love the times I learn something new due to other answers or the question itself. For example, more often than not there are different ways to tackle a problem and I've learned new or other ways of doing things on numerous occasions.

Sometimes I just don't know the answer but if it is about one of those topics I am particularly interested in I might fire up something like LinqPad or Visual Studio (Code) to try and solve it. I see it as a fun way of learning new stuff.

The Bad

If there is one thing that I have learned in this time is that asking a good question is an art. I think Jon Skeet summarizes the main points in this blogpost. For example, I often see questions lacking the proper context that is necessary for me to be able to provide an answer.

People get upset when their question is downvoted or closed but instead of editing their question based on the comments they almost all leave it as it is to never return to the site again. That is a pity, because I am sure most people genuinely want to help and do not close questions just for the sake of it. I wish every participant that has his or hers question closed or downvoted take the time to read this checklist and make another attempt.

I also quickly learned that answers providing a direction of thoughts or hints on how to solve the problem aren't as much appreciated as answers that literally fixes the problem at hand. Is that a bad thing? Not per se, I do understand that when you have a problem you want an answer that can help you out immediately. But there are times I think it would be better to discover the answer yourself using some tips and guidance so it leads to a better understanding of how things work. Asynchronous and parallel computing is one of those topics this really applies to.

The Ugly

It is not until recently that I became aware of the problems this community faces when it comes to being (un)welcoming to new contributors and the attitude of some contributors towards others. Sure, I have seen some ugly comments or unfriendly behavior but it never struck me as such a widespread issue. I know there are efforts made to change this, and it is not the goal of this post to address it but I sincerely hope that Stack Overflow gets back its reputation as the primary source for developers to get help on any programming related question no matter their skillset and knowledge.

Communication is key here. Negative feedback is a widespread issue on the internet nowadays and Stack Overflow is no exception. Sadly, the world of developers isn't always one happy community (The world of Open Source is another example). I rather try to gain a better understanding of the problem by asking questions about the question than to leave some snarky comment about the low quality of the question. We all had to start somewhere when we entered the world of programming so I keep that in mind.

My approach

I soon realized I did not want to spend too much time on checking the website for new and interesting questions. I decided that I wanted to put my effort in answering questions in topics I am interested in, or have detailed knowledge about. Therefore I wrote my own bot that posts questions having specific tags I am interested in to a Slack channel using an Azure Function. You are welcome to check it out:

Expecho / StackOverflow-To-Slack-Tag-Tracker

Azure Function that acts as a bot which creates notifications in a Slack channel about StackOverflow activity based on the question tags

StackOverflow -> Slack Tag Tracker

Azure Function that acts as a bot which creates notifications in a Slack channel about StackOverflow activity based on the question tags.

Getting up & running

Create a new timer based Azure Function (for javascript). For instructions see the docs. I recommend a timer that will fire every 15 minutes, due to the api request limitations of Stack Overflow.
Install the required node.js packages. Instructions can be found here. The package.json file is in this repository.
Replace the default javascript code with the code in this repository. Then change the configuration to your liking*

A Slack token can be generated here. A StackOverflow token can be created here.

Configuration

The configuration is defined using environment variables:

    slackbot_username: "StackOverflow Tag Tracker",
    slackbot_icon_emoji: ':incoming_envelope:',
    slackbot_token: '<token>',
    slackbot_channel: '<channel>',
    slackbot_workspace: '<workspace>',
    so_api_key: '<api key>',
    so_tracked_tags: 'azure;asp.net-web-api|powerbi',

slackbot_username
The bot account name

slackbot_icon_emoji
The Slack…

View on GitHub

Anyway, don't let the bad & the ugly deter you from making Stack Overflow a better place. There are plenty of opportunities to help people out because one thing is for sure, in our ever changing world there will always be a new source of questions.

Monitoring non-web apps using Azure Application Insights (Part 1: Getting Started)

Peter Bons — Fri, 14 Dec 2018 21:25:35 +0000

This is the first post of a serie in which we will take a look at how we can use Application Insights to monitor other applications besides web applications. Most application landscapes are a mixture of cloudbased and on-premises applications. Some are webbased, some are desktop applications. Would it not be great if we can use one tool to monitor them all? Luckely there is Application Insights, a low cost monitoring solution running on Azure.

This post will cover the introduction of Application Insights and the first steps of monitoring a desktop application.

What is Application Insights?

Application Insights is an extensible Application Performance Management (APM) service for web developers on multiple platforms. Use it to monitor your live web application. It will automatically detect performance anomalies. It includes powerful analytics tools to help you diagnose issues and to understand what users actually do with your app. It's designed to help you continuously improve performance and usability. It works for apps on a wide variety of platforms including .NET, Node.js and J2EE, hosted on-premises or in the cloud. It integrates with your DevOps process, and has connection points to a variety of development tools.

There are a couple of things to like about Application Insights:

It is tightly integrated in many Azure Services like Azure Web Apps, Azure Functions, Azure Kubernetes Services and many more.
It is really easy to configure. (Very often it is either automatically done or it need at most one or two clicks)
It has a powerful querying mechanism called Application Insights Analytics.
It has many extension points. For example, you can enrich or filter telemetry and track your own telemetry.
You can create and pin your own visuals.
It has powerful alerting capabilities.
It is not restricted to workloads running in the cloud.
It is Open Source.

Monitoring a simple desktop application

Most documentation and blogposts regarding Application Insights deal with setting up monitoring web applications. This is really straight forward since all that needs to be done is adding some NuGet packages, provide an Instrumentation Key and add some config code. Then you get automatically request, exception and trace telemetry send to Application Insights since it can hook into several extension points provided by the Asp.Net (Core) framework. But unfortunately, when you are stuck developing desktop applications using WPF or WinForms for example, there is no such mechanism as a request pipeline to use. But, as we will explore in this serie, that does not mean we cannot use Application Insights at all.

So, without further ado, this is what will be covered by this serie:

Provisioning an Application Insights resource in Azure and enable the Live Metrics Stream of our little console application.
Add basic instrumentation to our code and have it send to Application Insights.
Enhancing our instrumentation by automatically tracking exceptions, requests and dependencies.

Provisioning an Application Insights resource

The first thing we need to do is obviously creating an Application Insights resource for us to use. Then we need to extract the Instrumentation Key that we need in our application to configure the Application Insights integration.

Go to the Azure Portal and create an Application Insights resource:

Once the resource is created, browse to it and note the instrumentation key. We will use this key in our application.

That is it for now. It is time to create our application.

Enabling Application Insights in our application

I created a .Net 4.7.2 console application using Visual Studio 2017. To use Application Insights we will have to add a reference to the Microsoft.ApplicationInsights.WindowsServer NuGet Package. (This will automatically reference the Microsoft.ApplicationInsights package)

When the NuGet Packages are installed a new file is added to the project, called ApplicationInsights.config. Open that file and add the InstrumentationKey add the top like this:

<?xml version="1.0" encoding="utf-8"?>
<ApplicationInsights xmlns="http://schemas.microsoft.com/ApplicationInsights/2013/Settings">
  <InstrumentationKey>YOUR_KEY_HERE</InstrumentationKey>
  <TelemetryInitializers>
    <Add Type="Microsoft.ApplicationInsights.DependencyCollector.HttpDependenciesParsingTelemetryInitializer, Microsoft.AI.DependencyCollector"/>
    <Add Type="Microsoft.ApplicationInsights.WindowsServer.AzureRoleEnvironmentTelemetryInitializer, Microsoft.AI.WindowsServer"/>
    <Add Type="Microsoft.ApplicationInsights.WindowsServer.AzureWebAppRoleEnvironmentTelemetryInitializer, Microsoft.AI.WindowsServer"/>
    <Add Type="Microsoft.ApplicationInsights.WindowsServer.BuildInfoConfigComponentVersionTelemetryInitializer, Microsoft.AI.WindowsServer"/>
  </TelemetryInitializers>
  <TelemetryModules>
...

Now, we could have chosen to just send some "Hello World" message from our application to Application Insights but let us just make it a bit more juicier than that. Would it not be nice if we have some real-time insights of the cpu and memory usage of our machine running the application? Let us try by modifying our console application to make this happen:

using System;
using Microsoft.ApplicationInsights.Extensibility;

namespace NonWebIntegrationDemo
{
    class Program
    {
        static void Main(string[] args)
        {
            _ = TelemetryConfiguration.Active;

            Console.WriteLine("Press any key to exit.");
            Console.ReadKey();
        }
    }
}

The line _ = TelemetryConfiguration.Active; triggers the SDK to start sending telemetry to Application Insights.

Now, build and execute the application and leave it running. Browse to the Azure Portal and navigate to your Application Insights resource. From there, open the Live Metrics Stream tab and observe the live feed of the application:

It might take a few moments before the live stream shows data, so be patient.

That is it for now! We have created an Application Insights resource and configured it successfully in our console application. This will be our starting point for the next post, stay tuned.

DEV Community: Peter Bons

Forget MCP, Use OpenAPI for AI Agent tools

Introduction

Getting the ingredients right

Building the agent

Play Time!

Trimming large OpenAPI documents

Wrapping up

Give your AI Agent Vibe Coding Superpowers using .Net 10

Introduction

Setting up the stage

Reviewing the performance

Final Thoughts

Monitoring non-web apps using Azure Application Insights (Part 2: Basic Instrumentation)

Service Fabric Remoting: Interception & Custom Headers

Introduction

Message Interception

Client-side message interception

Server-side message interception

Custom Headers

Prepare the Reliable Service

Adding custom headers (the caller)

Reading custom headers (the callee)

What is next?

Expecho / ServiceFabric-Remoting-CustomHeaders

ServiceFabric.Remoting.CustomHeaders

NuGet

Examples

Usage scenarios

How to use

Prepare Reliable Services

Reporting Metrics Using .Net (Core) EventSource and EventCounter

Introducing EventCounters

The Recipe

Expecho / Blog

Placeholder for code I blogged about, see

Blog

Folders in this repository

What is next?

Add support for reporting application metrics via logging #708

Overview

Proposal

Why add to ILogger?

The API

IMetricLogger

IMetric

LoggerMetricsExtensions

MetricValueExtensions

Logger updates

Define/Record pattern

Filtering Metrics

Scopes and Property Bags

Impact on existing Providers

One year of answering Stack Overflow questions. The Good, The Bad and The Ugly.

The Good

The Bad

The Ugly

My approach

Expecho / StackOverflow-To-Slack-Tag-Tracker

Azure Function that acts as a bot which creates notifications in a Slack channel about StackOverflow activity based on the question tags

StackOverflow -> Slack Tag Tracker

Getting up & running

Configuration

Monitoring non-web apps using Azure Application Insights (Part 1: Getting Started)

What is Application Insights?

Monitoring a simple desktop application

Provisioning an Application Insights resource

Enabling Application Insights in our application

Why add to `ILogger`?

`IMetricLogger`

`IMetric`

`LoggerMetricsExtensions`

`MetricValueExtensions`

`Logger` updates

`Define`/`Record` pattern