Application Insights – Następny Poziom

W jednym z moich ostatnich artykułów (Application Insights – Ukryty Skarb Azure) przeszliśmy przez podstawową konfigurację usługi application insights oraz bardzo podstawową integrację. Jako, że obiecałem wam więcej treści z tematu, tak oto powstał ten artykuł.  Zajmiemy się wprowadzeniem integracji z Application Insights na kolejny poziom. Jako, że to kontynuacja, bardzo zachęcam abyś przeczytał wcześniejszy artykuł.

SeriLog

Zacznijmy od rzeczy podstawowej. Jak przy większości moich projektów zaczynam od dogrania i skonfigurowania biblioteki wspomagającej semantyczne logowanie. W moim przypadku jest to SeriLog. Jeżeli korzystasz z np. Log4Net, nie ma czym się przejmować. Dopóki Twoja biblioteka bazuje na interfejsie ILogger wszystko powinno być w porządku.

Oczywiście, jak to w świecie .NET-a, aby zacząć używać gotowej paczki, musimy ją pobrać do projektu za pomocą nuget-a. Paczka nazwy się Serilog.AspNetCore.

Następnie należy, w pliku Program.cs, utworzyć konfigurację logger-a. Ja to robię w następujący sposób:

public class Program
{
    public static void Main(string[] args)
    {
        var configuration = new LoggerConfiguration()
            .MinimumLevel.Debug()
            .MinimumLevel.Override("Microsoft", LogEventLevel.Verbose)
            .MinimumLevel.Override("System", LogEventLevel.Verbose)
            .MinimumLevel.Override("Microsoft.AspNetCore.Authentication", LogEventLevel.Verbose)
            .Enrich.FromLogContext()
            .Enrich.WithProperty("ApplicationName", typeof(Program).Assembly.GetName().Name)
            .WriteTo
            .Console();

        Log.Logger = configuration.CreateLogger();
        
        try
        {
            Log.Information("Starting Up");
            CreateHostBuilder(args).Build().Run();
        }
        catch (Exception e)
        {
            Log.Fatal(e, "Application startup failed");
        }
        finally
        {
            Log.CloseAndFlush();
        }

    }

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureWebHostDefaults(webBuilder => { webBuilder.UseStartup(); })
            .UseSerilog();
}

Pewnie zastanawiasz się dlaczego w liniach 7-10 ustawiłem minimalny poziom logowania na Verbose. Jest to jak najbardziej świadomy i celowy zabieg. Jako, że obecnie dodajemy wszystko na pustym projekcie, wysoki poziom szczegółowości logów pomoże zapełnić usługę application insights. W produkcyjnej aplikacji nie radziłbym go stosować. Czasami zbyt duża liczba logów generuje niepotrzebny szum informacyjny i ciężej znaleźć istotne elementy.

W tym miejscu przydałoby się omówić jeszcze jedną kwestię, mianowicie ulokowanie tego kodu w pliku Program.cs. Wiem, że często spotykaną praktyką jest konfiguracja logger-a w pliku Startup.cs. Mamy tam dostęp do całej konfiguracji znajdującej się w pliku appsettings.json co pozwala nam na uniknięcie problemu typu “kury i jajka”. Na szczęście jest łatwy do rozwiązania za pomocą np. zmiennych środowiskowych, dzięki czemu uzyskamy logi z startu aplikacji. Dlatego podejście zaprezentowane wyżej jest, przynajmniej moim odczuciu, zdecydowanie lepsze.

Integracja logów i Application Insights

Kolejnym krokiem, który musisz wykonać, jest skonfigurowanie sdk Application Insights w taki sposób, aby zapisywało logi w swojej usłudze. Kiedyś zadanie było dużo prostsze, wystarczyła pomoc biblioteki Serilog.Sinks.ApplicationInsights. Czas jednak mija i wiele się zmienia.  Podczas próby wykorzystania kodu znajdującego się w przykładzie tej biblioteki zobaczysz, że TelemetryConfiguration.Active jest już oznaczone jako depracted i nie powinieneś opierać swojej implementacji na tym polu statycznym.

Aby zintegrować logi z Application Insights będziesz musiał dograć jeszcze jedną paczkę nuget-a – Microsoft.Extensions.Logging.ApplicationInsights, która doda swoją implementacje interfejsu ILogger. Następnie będziesz musiał wrócić do pliku Startup.cs i dodać konfigurację przedstawioną poniżej:

public static IHostBuilder CreateHostBuilder(string[] args) =>
            Host.CreateDefaultBuilder(args)
                .ConfigureWebHostDefaults(webBuilder => { webBuilder.UseStartup(); })
                .UseSerilog()
                .ConfigureLogging(builder =>
                {
                    builder.AddApplicationInsights("InstrumentationKey");
                });

Cloud Role i Cloud Instance

Ostatnimi elementami, jakie chce poruszyć, są Cloud Role Name i Cloud Role Instance.

Cloud Role Name to nazwa procesu. Może to być nazwa naszej aplikacji, serwisu etc. Jest wykorzystywany np. w panelu ApplicationMap, aby dokonać wizualizacji przepływu informacji pomiędzy procesami.

Uważam to za szczególnie przydatne,  tym bardziej w momencie, kiedy mamy więcej procesów, jak np. Frontend i Backend czy też środowisko mikroserwisowe. W momencie kiedy ta wartość nie jest ustawiona, Application Insights będzie robiło wszystko co w jego mocy, aby nazwać ten proces (np. może użyć nazwy aplikacji jeżeli aplikacja będzie uruchomiona w Azure App Service).

Natomiast Cloud Role Instance powinno zawierać informację na jakiej instancji procesu Cloud Role Name działa. Jest to bardzo ważne w momencie, kiedy próbujemy skalować naszą aplikację. Np. gdybyś spróbował zwiększyć liczbę instancji swojej aplikacji i wystawił ją na świat za load balancerem prawdopodobnie chciałbyś mieć informacje, na jakiej instancji występują błędy. Dlatego możemy nadać identyfikator naszej instancji np. “My_Api_Prod_1”.

Wymaga to dodania własnej implementacji interfejsu ITelemetryInitializer gdzie w metodzie Initialize możesz ustawić wszystkie wartości.

public class ApiTelemetryInitializer : ITelemetryInitializer
{
    public void Initialize(ITelemetry telemetry)
    {
        if (string.IsNullOrEmpty(telemetry.Context.Cloud.RoleName))
        {
            telemetry.Context.Cloud.RoleName = "My.Api";
            telemetry.Context.Cloud.RoleInstance = "My_Api_Prod_1";
        }
    }
}

Na koniec trzeba powrócić do pliku Startup.cs, aby zarejestrować utworzoną klasę w kontenerze DI.

public void ConfigureServices(IServiceCollection services)
{
    services.AddSingleton<ITelemetryInitializer, ApiTelemetryInitializer>();
    services.AddApplicationInsightsTelemetry();
    // ...
}

Podsumowanie

To by było na tyle, konfiguracja powinna śmigać i wyglądać całkiem składnie. W następnym artykule zagłębimy się w panel usługi Application Insights, aby zobaczyć jakie możliwości oferuje.

Jak zwykle mam nadzieje że artykuł się podobał!

Do Następnego!