Forem: Victor

Observability in Local Development with OpenTelemetry, OTLP, and Aspire Dashboard

Victor — Sat, 20 Dec 2025 10:14:15 +0000

Introduction

Modern applications are increasingly distributed, combining APIs, front-end SPAs, databases, and cloud storage. While observability is critical in production, developers often overlook its importance during local development. Without proper visibility, debugging performance bottlenecks, tracing requests across services, or identifying storage issues becomes guesswork.

There are many ways to observe local systems — logs, metrics dashboards, or tracing tools — but this time I focus on using the standalone Aspire Dashboard with OpenTelemetry (OTLP).

Local observability helps developers catch issues earlier, experiment with instrumentation safely, and build confidence in their system’s resilience.

Prerequisites

Podman (or Docker) for containerized Aspire Dashboard

Here’s how I set things up in my own project, based on my experience.:

1 - Run Aspire Dashboard

Pull and run the Aspire Dashboard container using Podman.

podman run --rm -it -p 18888:18888 -p 4317:18889 --name aspire-dashboard mcr.microsoft.com/dotnet/aspire-dashboard:latest

Expose the necessary ports for local access.

2 - Configure OpenTelemetry in .NET API

Add OpenTelemetry.Extensions.Hosting and OpenTelemetry.Exporter.OTLP packages.

<PackageReference Include="OpenTelemetry.Exporter.OpenTelemetryProtocol" Version="1.14.0" />
<PackageReference Include="OpenTelemetry.Extensions.Hosting" Version="1.14.0" />
<PackageReference Include="OpenTelemetry.Instrumentation.AspNetCore" Version="1.14.0" />
<PackageReference Include="OpenTelemetry.Instrumentation.EntityFrameworkCore" Version="1.14.0-beta.2" />
<PackageReference Include="OpenTelemetry.Instrumentation.Http" Version="1.14.0" />

Configure logs, tracing and metrics in Program.cs.

builder.Logging.AddOpenTelemetry(logging =>
{
    logging.IncludeFormattedMessage = true;
    logging.IncludeScopes = true;
});

// Configure OpenTelemetry
var otel = builder.Services.AddOpenTelemetry()
    .WithMetrics(metrics =>
    {
        metrics.AddAspNetCoreInstrumentation();
        //metrics.AddMeter("Microsoft.AspNetCore.Hosting");
        //metrics.AddMeter("Microsoft.AspNetCore.Server.Kestrel");
    })
    .WithTracing(tracing => tracing
        .AddAspNetCoreInstrumentation()
        .AddHttpClientInstrumentation()
        .AddEntityFrameworkCoreInstrumentation(options =>
        {
            options.EnrichWithIDbCommand = (activity, command) =>
            {
                var stateDisplayName = $"{command.CommandType} operation";
                activity.DisplayName = stateDisplayName;
                activity.SetTag("db.name", stateDisplayName);
            };
        }));

var OtlpEndpoint = builder.Configuration["OTEL_EXPORTER_OTLP_ENDPOINT"];
if (OtlpEndpoint != null)
{
    otel.UseOtlpExporter();
}

Appsetting.json file

 "OTEL_EXPORTER_OTLP_ENDPOINT": "http://localhost:4317",
 "OTEL_SERVICE_NAME": "StorageManagementAPI",
 "OTEL_TRACES_SAMPLER": "always_on"

3 - Run the system locally.
3.1 - Logs

3.2 - Traces

3.2 - Metrics

Conclusion

This approach is lightweight, easy to set up, and highly effective for debugging complex interactions across APIs, SPAs, databases, ...

Whether you’ve already tested it or you’re just thinking about it, local observability is worth exploring.

ASP.NET CORE - How to using IAuthorizationRequirementData

Victor — Sat, 13 Dec 2025 04:58:19 +0000

Scenarios may be useful:

Using an external service to provide policy evaluation.
Using a large range of policies, so it doesn't make sense to add each individual authorization policy with an AuthorizationOptions.AddPolicy call.
Creating policies at runtime based on information in an external data source (like a database) or determining authorization requirements dynamically through another mechanism.

Applied: from ASP.NET Core 8

Step 1: Implement a custom Authorize Attribute
In my case, I implement a UserFeatureAuthorizeAttirbute

using Microsoft.AspNetCore.Authorization;
using System;
using System.Collections.Generic;

namespace PracticalAPI.AuthorizationRequirementData
{
    public enum FeatureOperator
    {
        And = 1,
        Or = 2
    }
    public class UserFeatureAuthorizeAttribute : AuthorizeAttribute
        , IAuthorizationRequirement
        , IAuthorizationRequirementData
    {
        internal const string PolicyPrefix = "UserFeature_";
        public FeatureOperator Operator { get; set; }
        public string[] Features { get; set; }
        public UserFeatureAuthorizeAttribute(FeatureOperator featureOperator, params string[] features)
        { 
            Operator = featureOperator;
            Features = features;
        }
        public UserFeatureAuthorizeAttribute(string feature)
        {
            Operator = FeatureOperator.And;
            Features = new string[] { feature };
        }
        public IEnumerable<IAuthorizationRequirement> GetRequirements()
        {
            yield return this;
        }
    }
}

Step 2: Implement the AuthorizationHandler

using Microsoft.AspNetCore.Authorization;
using Microsoft.Extensions.Logging;
using System.Globalization;
using System.Threading.Tasks;
using System;

namespace PracticalAPI.AuthorizationRequirementData
{
    public class UserFeatureAuthorizationHandler : AuthorizationHandler<UserFeatureAuthorizeAttribute>
    {
        private readonly ILogger<UserFeatureAuthorizationHandler> _logger;
        private static string featureType = "feature";

        public UserFeatureAuthorizationHandler(ILogger<UserFeatureAuthorizationHandler> logger)
        {
            _logger = logger;
        }

        protected override Task HandleRequirementAsync(AuthorizationHandlerContext context,
                                                   UserFeatureAuthorizeAttribute requirement)
        {
            if (requirement.Operator == FeatureOperator.And)
            {
                foreach (var feature in requirement.Features)
                {
                    _logger.LogWarning("Evaluating authorization requirement for feature: {Feature}", feature);
                    if (!context.User.HasClaim(featureType, feature))
                    {
                        context.Fail();
                        return Task.CompletedTask;
                    }
                }

                context.Succeed(requirement);
                return Task.CompletedTask;
            }

            foreach (var feature in requirement.Features)
            {
                _logger.LogWarning("Evaluating authorization requirement for feature: {Feature}", feature);
                if (context.User.HasClaim(featureType, feature))
                {
                    context.Succeed(requirement);
                    return Task.CompletedTask;
                }
            }

            context.Fail();
            return Task.CompletedTask;
        }
    }
}

Step 3: Register the UserFeatureAuthorizationHandler

using AuthRequirementsData.Authorization;
  using Microsoft.AspNetCore.Authorization;

  var builder = WebApplication.CreateBuilder();
  ....
  // Use Custom Authorization
  // builder.Services.AddSingleton<IAuthorizationHandler, UserFeatureAuthorizationHandler>()

  var app = builder.Build();

  app.MapControllers();

  app.Run();

Step 4: Use the custom authorization attribute in controller

[UserFeatureAuthorize("Feature1")]
    public async Task<ActionResult<bool>> MyAction([FromBody] RequestModel model)
    {
       // Logic code go here
    }

Yup, this is one of many options that you can use to implement a good authorization for your application. You have to figure out which option is fit your scenario.

Happy coding!

ASP.NET Core - Fundamentals - Error Handling

Victor — Sat, 13 Dec 2025 04:41:14 +0000

There are some ways to handle exceptions while we working with ASP.NET Core

1. Use try-catch block

Best practice when using "throw"

Throw ex: loose stack trace on downstream layer
For example, an exception has occurred in the Data layer, Business layer catch this exception and use 'Throw Ex', at API layer will lose stack trace
Throw: keep stack trace on downstream layer
For example, an exception has occurred in the Data layer, Business layer catch this exception and use 'Throw', at API layer will get a stack trace in detail
Throw new Exception/ or Custom Exception: it will make downstream layer losing stack trace in detail
Only use at a lower level, the downstream level should use "Throw", we will keep stack trace on the downstream level

2. Use custom middleware to centralize exception handling

    /// <summary>
    /// Step 1: Create a middleware class
    /// </summary>
    public class CustomExceptionHandlerMiddleware
    {
        private readonly RequestDelegate _next;
        ILogger<CustomExceptionHandlerMiddleware> _logger;
        public CustomExceptionHandlerMiddleware(RequestDelegate next
            , ILogger<CustomExceptionHandlerMiddleware> logger)
        {
            _next = next;
            _logger = logger;
        }
        public async Task InvokeAsync(HttpContext context)
        {
            try
            {
                await _next(context);
            }
            catch (Exception ex)
            {
                _logger.LogError(ex, "Error while processing your request");
                await HandleExceptionAsync(context, ex);
            }
        }

        private Task HandleExceptionAsync(HttpContext context, Exception exception)
        {
            context.Response.ContentType = "application/json";
            context.Response.StatusCode = (int)HttpStatusCode.InternalServerError;
            return context.Response.WriteAsync(exception.Message);
        }
    }

    /// <summary>
    /// Step 2: Create a extension method to use our middleware
    /// </summary>

    public static class CustomExceptionHandlerMiddlewareExtensions
    {
        public static IApplicationBuilder UseCustomExceptionHandlers(this IApplicationBuilder app)
        {
            return app.UseMiddleware<CustomExceptionHandlerMiddleware>();
        }
    }

3. Centralize exception handling with IExceptionFilter

Implement an ExceptionFilter class

Add to the configuration method (Sample for ASP.NET Core 3.0)

Throw an exception when needed.

4. [From ASP.NET Core 8] - Use IExceptionHandler

This interface has TryHandleAsync method.
If Exception can handle => return true;
If Not => return false

Implement of IExceptionHandler

public class GlobalExceptionHandler : IExceptionHandler
    {
        private readonly ILogger<GlobalExceptionHandler> logger;

        public GlobalExceptionHandler(ILogger<GlobalExceptionHandler> logger)
        {
            this.logger = logger;
        }

        public async ValueTask<bool> TryHandleAsync(
            HttpContext httpContext,
            Exception exception,
            CancellationToken cancellationToken)
        {
            this.logger.LogError(exception, "Exception occurred: {Message}", exception.Message);

            var problemDetails = new ProblemDetails
            {
                Status = StatusCodes.Status500InternalServerError,
                Title = "Server error -- apply IExceptionHandler for Global"
            };

            httpContext.Response.StatusCode = problemDetails.Status.Value;

            await httpContext.Response
                .WriteAsJsonAsync(problemDetails, cancellationToken);

            return true;
        }
    }

Use the handler in Program file

// User Exception Handler
builder.Services.AddExceptionHandler<GlobalExceptionHandler>();
builder.Services.AddProblemDetails();

var app = builder.Build();

app.UseExceptionHandler();

[Part 2] - Practice Azure services - Enhance security by using Key Vault and App Configuration

Victor — Fri, 12 Dec 2025 15:29:26 +0000

Scenario

In the previous post, we use a shared key to establish a connection to an Azure storage account (including Table storage and Blob storage) and SQL Database. This method can lead security vulnerabilities. To enhance the security of our application, we can leverage App Configuration along with Azure Key Vault. This post will illustrate how to integrate these services to our current application.

Let's started.

Overview architecture

The app now functions similarly to what was described in the earlier post. The difference is that we now save the connection string (shared key) for the storage account and SQL Database in Key Vault, and the configurations are managed in App Configuration instead of relying on the environment variables of Azure App Service. When the API starts up, it will load the configuration from an additional configuration provider, which is App Configuration, with the values sourced from Key Vault.

Set up Azure Service
If you're unsure how to set up Azure App Configuration and Azure Key Vault, you can refer to these Microsoft articles:

Quickstart: Create an Azure App Configuration store | Microsoft Learn

Tutorial for using Azure App Configuration Key Vault references in an ASP.NET Core app | Microsoft Learn

You need to have all below information prior to proceeding to the next step.

Key Vault and new secrets

App configuration

Activate Managed Identity for the API

Remember the Object (principal ID) to use for the next step.

Grant access to your API/ local dev to Key Vault

Azure role-based access control: "Key Vault Secrets User"/"Key Vault Administrator"

Modify code

You can use code sample from previous post.

Add one more extension class to add Azure App Configuration to provided configuration builder.

Modify "Program.cs" file

Run locally

Change value of config key: "appConfig:ConnectionString"
Run API from Visual studio. If It runs successfully, then deploy to Azure App Service

Deploy new changes to Azure App Service

Check API

Environment variables of App service

API swagger - OK: means the APP can interact with App Configuration and Key Vault

Over to you: When to use the App Configuration and Key Vault and what are pros and cons?

[Part 1] - Practice Azure services - Build a small storage management app - Upload document feature

Victor — Fri, 12 Dec 2025 15:20:20 +0000

In this initial part, we concentrate on creating a document upload feature utilizing various Azure services. For the first post, we will employ these services at a fundamental level.

Scenario
The document management feature is required to save various documents (such as import documents, export documents, etc.).

Prerequisites

An Azure subscription.
Visual Studio or Visual Studio Code.
A basic understanding of the Azure services referenced in this article and the ability to create them (using the Azure portal or Bicep, for example) is necessary.

Tech stacks

ASP.NET CORE 8
Vue.js 3, PrimeVue

How we use Azure service for this functionality

Azure blob storage: for uploading document files.
Azure table storage: to store the document types
Azure SQL Database: to save the document information such as document type, document URL...
Azure App Service: to host the storage API
Static Web App: to serve the Vue single-page application (SPA).

To authenticate the SQL Database and Storage account, we will use connection string (shared key) for these services.

Overview architecture

1 - User access document management page, list document is loaded from SQL database and user would like to upload new document
2, 3 - SPA obtains SAS (shared access signature) token via API

4 - SPA uses SAS to upload appropriated document to blob storage

5,6 - SPA save document information to database via API.

Code Example

You can use the upload doc sample or create your own API and front-end using your preferred tech stack.
This sample includes infra code(not complete) and app code (Vue app and API)

Set up Azure services

If you're knowledgeable about Bicep code or interested in learning it, you can use Bicep code found in "infra" folder to deploy Azure services. Of course, there are few aspects you will need to modify or include. :)

The required azure services (sample is below, services name is your choice)

Run locally

Storage API

Open project in folder: "upload-doc\app\api"
Add configuration for table storage, blob storage and SQL database

Run code from your IDE.

Vue App

Open Vue project: ".\upload-doc\app\webapp"
Change API base URL in the "HttpService.ts" file

Run: npm install
Run: npm run dev

Deploy to Azure services

Deploy API to Azure App Service created in previous step.
Check the API

Deploy the Vue app to Static Web App created in previous step.
Check the application

Ultimately, you are aware of how to integrate Azure Storage, Azure App Service, Azure SQL Database, and Static Web App for your own objectives.

Over to you
When should we use these services?