Loggning i mikrotjänstmiljöer .Net i praktiken

Loggning är ett mycket viktigt verktyg för utvecklare, men när man skapar distribuerade system blir det en grundsten som måste läggas direkt i fundamentet av din applikation, annars kommer komplexiteten i utvecklingen av mikrotjänster snabbt att ge sig till känna.

I .Net Core 3 har en utmärkt möjlighet till överföring av korrelationskontext i HTTP-huvuden lagts till, så om dina applikationer använder direkta HTTP-anrop för inter-tjänstkommunikation kan du dra nytta av den här inbyggda funktionen. Men om din backend-arkitektur innebär kommunikation via en meddelandebroker (RabbitMQ, Kafka osv.), måste du fortfarande ta hand om överföringen av korrelationskontext genom dessa meddelanden själv.

I den här artikeln kommer vi att ta en enkel webb-API-applikation och organisera loggning som kommer att

• behålla genomgående korrelation mellan loggar från oberoende tjänster så att man lätt kan se alla aktiviteter som initierats av en specifik begäran från klienten

• ha en enda ingångspunkt med enkel analys så att loggningsverktyget kan användas även av supporten som får frågor som "jag fick ett fel i appen med det här begärnings-ID:t".

Först måste vi bestämma oss för vilken loggningsleverantör vi ska använda i vår applikation. Huvudkravet för modern loggning är struktur, det vill säga att vi måste arbeta med objekt snarare än platta textmeddelanden. Tack vare sådana loggar kan vi enkelt bygga representationer av våra meddelanden i olika perspektiv och utföra analys.

För vår applikation kommer vi att använda paketet Serilog, som har utmärkt stöd för strukturell loggning och ett rikt system av tillägg. Jag kommer att hoppa över de grundläggande stegen för att konfigurera det (du kan hitta många artiklar om detta ämne) och göra antagandet att

• Serilog redan är konfigurerat och är standardloggern för din beroendeinjektionsleverantör

• och i dess konfiguration är berikande av meddelanden med kontextens egenskaper (Enrich.FromLogContext) aktiverat.

Det nästa steget är att välja vilket system för central loggsamling som meddelanden från Serilog ska skickas till. För närvarande är det mest använda alternativet inom öppen programvara ELK-stack (Elasticsearch, Logstash och Kibana), så vi väljer det. För detta ändamål använder vi erbjudandet från Logz.IO — efter registrering på den kostnadsfria planen får vi kraften från sökmotorn Lucene i våra händer.

Vi behöver bara lägga till paketet i vårt projekt Serilog.Sinks.Logzio

Install-Package Serilog.Sinks.Logzio

Och lägga till den motsvarande enrichern i konfigurationen av vår logger, genom att ge den åtkomsttoken.

LoggerConfiguration loggerConfig = new LoggerConfiguration();
loggerConfig.WriteTo.Logzio(secrets.LogzioToken, 10, TimeSpan.FromSeconds(10), null, LogEventLevel.Debug);

När vi startar applikationen kommer vi att kunna se våra meddelanden inte bara i konsolen utan också i Kibana.

Gränssnitt

I en tjänstepplikation kan vi identifiera två huvudsakliga gränssnitt för dess interaktion med omvärlden, som vi benämner vertikalt och horisontellt. Det vertikala gränssnittet är webb-API:t, genom vilket anrop från klientapplikationen kommer in. Det horisontella är meddelandebrokern som används för att utbyta information med andra interna tjänster.

Låt oss gå igenom stegen för att implementera korrelation på vart och ett av dessa gränssnitt.

Korrelation i HTTP-förfrågningar

För att få så mycket information som möjligt behöver vi generera en korrelationsidentifierare så tidigt som möjligt i aktiviteten, dvs. vid gatewayen eller direkt på klienten (mobil eller webb). Eftersom vi idag hanterar en backendapplikation ska vi bara ange kravet på den obligatoriska rubriken „X-Correlation-ID” i alla förfrågningar till webb-API:t.

Vi lägger till paketet CorrelationID, vars funktion är att hämta värdet från den nödvändiga rubriken.

Install-Package CorrelationID

Låt oss lägga till det i begärans bearbetningspipeline.

public class Startup
{
    public void Configure(IApplicationBuilder application)
    {
        application
	    .UseCorrelationId(new CorrelationIdOptions
        {
            Header = "X-Correlation-ID",
            IncludeInResponse = false,
            UpdateTraceIdentifier = false,
            UseGuidForCorrelationId = false
        });
    }
}

Nu ska vi med hjälp av detta skapa ett enkelt action-filter:

public sealed class ApiRequestFilter : ActionFilterAttribute
{
    public ApiRequestFilter(IApiRequestTracker apiRequestTracker, ICorrelationContextAccessor correlationContextAccessor)
    {
        _correlationContextAccessor = correlationContextAccessor ?? throw new ArgumentNullException(nameof(correlationContextAccessor));
    }
    
    private readonly ICorrelationContextAccessor _correlationContextAccessor;
    
    public override async Task OnActionExecutionAsync(ActionExecutingContext context, ActionExecutionDelegate next)
    {
        if (!Guid.TryParse(_correlationContextAccessor.CorrelationContext.CorrelationId, out Guid correlationId))
        {
            context.Result = new BadRequestResult();
            return;
        }
    
        await next.Invoke();
    }
    
    public override async Task OnResultExecutionAsync(ResultExecutingContext context, ResultExecutionDelegate next)
    {
        await next.Invoke();
    }
}

Och vi lägger till den i kontrollern

[Route("[controller]")]
[ApiController]
[ServiceFilter(typeof(ApiRequestFilter))]
public class CarsController : ControllerBase
{

}

Som ett resultat kommer kontrollern att returnera 400 Bad Request för alla förfrågningar utan en header med motsvarande identifierare.

När vi börjar ta emot identifieraren från klienten måste vi lägga till den i loggkontexten, så vi gör en kringliggande mellanlager:

public class CorrelationIdContextLogger
{
    public CorrelationIdContextLogger(RequestDelegate next)
    {
        _next = next ?? throw new ArgumentNullException(nameof(next));
    }
    
    readonly RequestDelegate _next;
    
    public async Task InvokeAsync(HttpContext httpContext, ILogger logger, ICorrelationContextAccessor correlationContextAccessor)
    {
        if (Guid.TryParse(correlationContextAccessor.CorrelationContext.CorrelationId, out Guid correlationId))
        {
            using (logger.BeginScopeWith(("CorrelationId", correlationId)))
            {
                await _next(httpContext);
            }
        }
        else
        {
            await _next(httpContext);
        }
    }
}

I vår applikation använder vi standard ILogger från paketet Microsoft.Extensions.Logging.Abstractions, så värdet kommer att läggas till med hjälp av en enkel förlängning till den.

public static IDisposable BeginScopeWith(this ILogger logger, params (string key, object value)[] keys)
{
    return logger.BeginScope(keys.ToDictionary(x => x.key, x => x.value));
}

Vi lägger till mellanlagret i begärningshanteringskonverteraren och får önskat resultat.

public class Startup
{
    public void Configure(IApplicationBuilder application)
    {
        application.UseMiddleware();
    }
}

Nu innehåller alla aktiviteter som genereras av förfrågningar till vår webb-API det korrelations-ID som gör att de lätt kan kopplas ihop.

Korrelation i meddelanden från mäklaren

Nästa steg är att etablera överföring och mottagning av korrelationsidentifieraren via meddelandebrokern. I vårt exempel kommer vi använda RabbitMQ, och som klient väljer vi ramen MassTransit. Återigen hoppar vi över den initiala konfigurationen av MassTransit och går direkt vidare till inställningen av loggning.

För att börja kan vi aktivera loggorna för MassTransit själv, för detta lägger vi till paketet i vår applikation MassTransit.SerilogIntegration

Install-Package MassTransit.SerilogIntegration

Nu, efter att loggaren har lagts till i inställningarna för MassTransit, kan vi se loggarna för ramen.

services
    .AddSingleton(provider =>
        {
            return Bus.Factory.CreateUsingRabbitMq(cfg =>
            {
                cfg.UseSerilog();
            });
        });

Låt vår applikation som en reaktion på en POST-begäran skicka händelsen SomethingDoneMessage med värdet "done". Kontraktet för ett sådant meddelande kan beskrivas så här:

namespace MbMessages
{
    public interface ISomethingDoneMessageV1
    {
        string Value { get; }
    }
}

Meddelanden från MassTransit är i huvudsak ett kuvert, där meddelanden från brokern är inlagda. Kuvertet ser ungefär ut så här:

{
  "messageId": "59020000-5dba-0015-10b8-08d77ec28593",
  "requestId": "59020000-5dba-0015-5674-08d77ec28592",
  "conversationId": "59020000-5dba-0015-bca8-08d77ec28594",
  "destinationAddress": "rabbitmq://bear.rmq.cloudamqp.com/aelzlsta/ya.servicetemplate.receiveendpoint",
  "headers": {},
  "messageType": [
    "urn:message:MbMessages:ISomethingDoneMessageV1"
  ],
  "message": {
    "value": "done"
  }
}

I meddelandet syns de tjänstefält som krävs för att ramverket ska fungera, men vi kan också lägga till egna ytterligare egenskaper i detta kuvert. Dessutom har MassTransit inbyggda verktyg för att arbeta med vissa valfria fält, av vilka vi främst är intresserade av korrelationsidentifikatorn CorrelationId.

Låt oss lägga till gränssnittet CorrelatedBy i meddelandets kontrakt:

namespace MbMessages
{
    public interface ISomethingDoneMessageV1 : CorrelatedBy
    {
        string Value { get; }
    }
}

Vi implementerar det och tilldelar värdet till egenskapen CorrelationId vid skapandet av meddelandet:

internal class SomethingDoneMessageV1 : ISomethingDoneMessageV1
{
    internal SomethingDoneMessageV1(Guid correlationId, string value)
    {
        CorrelationId = correlationId;
        Value = value;
    }
    
    public Guid CorrelationId { get; private set; }
    public string Value { get; private set; }
}

Om vi tittar på det uppdaterade meddelandet ser vi att korrelations-ID:t blivit en del av vårt meddelande, såväl som av kuvertet – detta ID kommer nu också att användas i alla loggar för MassTransit, vilket gör det betydligt enklare att hantera problem på meddelandebrokernivå.

{
  "messageId": "59020000-5dba-0015-10b8-08d77ec28593",
  "requestId": "59020000-5dba-0015-5674-08d77ec28592",
  "conversationId": "59020000-5dba-0015-bca8-08d77ec28594",
  "correlationId": "c7ff562a-b639-415b-9add-c9e524a727cc",
  "destinationAddress": "rabbitmq://bear.rmq.cloudamqp.com/aelzlsta/ya.servicetemplate.receiveendpoint",
  "headers": {},
  "messageType": [
    "urn:message:MbMessages:ISomethingDoneMessageV1"
  ],
  "message": {
    "correlationId": "c7ff562a-b639-415b-9add-c9e524a727cc",
    "value": "Hello"
  }
}

Vi behöver fortfarande konfigurera loggning av dessa meddelandets egenskaper, för detta lägger vi till paketet Serilog.Enrichers.MassTransitMessage. Paketet lägger till en filter i meddelandehanteringsrörledningen för MassTransit, vilket placerar meddelandets sammanhang i en trådsäker stack. Serilog läser kontexten från stacken och lägger till dessa tilläggsegenskaper i våra loggobjekt.

Install-Package Serilog.Enrichers.MassTransitMessage

I MassTransit lägger vi till filtret

services
    .AddSingleton(provider =>
        {
            return Bus.Factory.CreateUsingRabbitMq(cfg =>
            {
                cfg.UseSerilog();
                cfg.UseSerilogMessagePropertiesEnricher();
            });
        });

Och i Serilog-konfigurationen lägger vi till enrichern

Log.Logger = new LoggerConfiguration()
    .Enrich.FromMassTransitMessage()
    .CreateLogger();

Eftersom applikationen som tar emot meddelanden från RabbitMQ har tillgång till alla egenskaper i MassTransit-kuvertet, kan vi använda det mottagna korrelations-ID:t inuti konsumentapplikationen samt vidarebefordra det genom hela anropskedjan.

Som ett resultat innehåller våra loggar nu CorrelationId inte bara inom en tjänst utan också vid interaktion med andra applikationer.

Så den erhållna loggningssystemet i .Net-applikationer gör det möjligt för oss att utan större problem korrelera loggar från helt olika mikrotjänster – även de som fungerar via meddelandebrokern. Och med hjälp av Elasticsearch kan vi snabbt och enkelt analysera loggar, genom att bygga nödvändiga dashboards i Kibana (exemplet visas på bilden till inlägget).

Självklart kommer loggning i detta format inte att täcka komplexa interaktioner mellan dina tjänster och olika externa system, men att införa en sådan ordning i början av projektutvecklingen är något du kommer att tacka dig själv för flera gånger.

Du kan undersöka källkoden för det resulterande systemet i projektet: github.com/a-postx/YA.ServiceTemplate

Källa: habr.com