Logimine mikroteenuste keskkonnas .Net praktikas

Logimine on arendaja jaoks väga oluline tööriist, kuid hajussüsteemide loomisel muutub see vundamendikiviks, mis tuleb paika panna kohe rakenduse alusesse, vastasel juhul annab mikroteenuste arenduse keerukus end väga kiiresti tunda.

.Net Core 3-s lisandus suurepärane võimalus edastada korrelatsioonikonteksti HTTP-päistes, seega kui teie rakendused kasutavad teenustevaheliseks suhtluseks otseseid HTTP-kutseid, saate kasutada seda valmislahendust. Kui teie backend’i arhitektuur eeldab aga suhtlust sõnumivahendaja kaudu (RabbitMQ, Kafka jne), peate endiselt ise hoolitsema korrelatsioonikonteksti edastamise eest nende sõnumite kaudu.

Selles artiklis võtame lihtsa Web API rakenduse ja seadistame logimise, mis

• säilitab sõltumatute teenuste logide vahel läbiva korrelatsiooni nii, et oleks lihtne näha kõiki tegevusi, mille konkreetne kliendipäring käivitas

• võimaldab luua ühe keskse sisenemispunkti koos mugava analüüsiga, et logimistööriista saaks kasutada isegi tugi, kellele jõuavad küsimused stiilis „mul viskas rakenduses veateate sellise päringu ID-ga”

Esiteks peame oma rakenduses valima logimislahenduse pakkuja. Kaasaegse logimise peamine nõue on struktureeritus, st me ei tööta lamedate tekstsõnumitega, vaid objektidega. Tänu sellistele logidele saame hõlpsalt luua oma sõnumitest erinevaid vaateid ja teha analüüsi.

Oma rakenduses kasutame paketti Serilog, millel on suurepärane struktureeritud logimise tugi ja rikkalik laienduste ökosüsteem. Jätan selle põhiseadistuse etapid vahele (sellel teemal leiab palju artikleid) ja eeldan, et

• Serilog on juba seadistatud ja on teie sõltuvussüstimise pakkuja vaikimisi logger

• selle konfiguratsioonis on lubatud sõnumite rikastamine konteksti omadustega (Enrich.FromLogContext)

Järgmine samm on valida, millisesse tsentraliseeritud logikogumissüsteemi Serilogi sõnumid saata. Tõenäoliselt on tänapäeval kõige levinum avatud lähtekoodiga lahendus ELK stack (Elasticsearch, Logstash ja Kibana), seega kasutame seda. Selleks võtame appi lahenduse ettevõttelt Logz.IO — pärast tasuta paketi registreerimist on meie käsutuses kogu Lucene'i otsingumootori võimekus.

Meil jääb üle lisada oma projekti pakett Serilog.Sinks.Logzio

Install-Package Serilog.Sinks.Logzio

Ja lisada meie logeri konfiguratsiooni vastav enricher, andes sellele ette juurdepääsutokeni

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

Pärast rakenduse käivitamist näeme oma sõnumeid mitte ainult konsoolis, vaid ka Kibanas.

Liidesed

Teenusetüüpi rakendusel saab eristada kahte peamist liidest välismaailmaga suhtlemiseks, nimetagem neid vertikaalseks ja horisontaalseks. Vertikaalne liides on Web API, mille kaudu saabuvad kliendirakenduse päringud. Horisontaalne liides on sõnumivahendaja, mida kasutatakse andmevahetuseks teiste sisemiste teenustega.

Vaatleme korrelatsiooni juurutamise etappe kummagi liidese puhul.

Korrelatsioon HTTP-päringutes

Et saada võimalikult palju teavet, tuleb korrelatsiooniidentifikaator genereerida võimalikult tegevuse alguse lähedal, s.t. lüüsis või otse kliendi poolel (mobiili- või veebirakenduses). Kuna tegeleme täna backend-rakendusega, siis piirduleme nõudega, et kõigil Web API päringutel peab olema kohustuslik päis „X-Correlation-ID”.

Lisame paketi CorrelationID, mille ülesanne on lugeda väärtus meie jaoks vajalikust päisest

Install-Package CorrelationID

Lisame selle päringutöötluse konveierisse

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

Nüüd teeme selle abil lihtsa action-filtri:

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();
    }
}

Ja lisame selle kontrollerisse

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

}

Selle tulemusel hakkab kontroller tagastama kõigile päringutele ilma vastava identifikaatoriga päiseta vastuse 400 Bad Request.

Pärast seda, kui hakkasime kliendilt identifikaatorit saama, peame selle lisama logimiskonteksti. Selleks teeme eraldi vahekihi:

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(context);
            }
        }
        else
        {
            await _next(context);
        }
    }
}

Meie rakenduses kasutame standardset ILoggerit paketist Microsoft.Extensions.Logging.Abstractions, seega lisame väärtuse selle jaoks loodud lihtsa laienduse abil.

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

Lisame vahekihi päringutöötluse konveierisse ja saame soovitud tulemuse.

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

Nüüd sisaldavad kõik tegevused, mille käivitavad päringud meie Web API-le, korrelatsiooniidentifikaatorit, mille alusel saab need hõlpsasti omavahel siduda.

Korrelatsioon sõnumibrokeri teadetes

Järgmise sammuna peame seadistama korrelatsiooniidentifikaatori edastamise ja vastuvõtmise sõnumivahendaja kaudu. Meie näites kasutame RabbitMQ-d ning kliendina võtame kasutusele MassTransit frameworki. Jätame taas MassTransiti esmase seadistuse vahele ja liigume kohe logimise seadistamise juurde.

Alustuseks võime sisse lülitada MassTransiti enda logid; selleks lisame oma rakendusse paketi MassTransit.SerilogIntegration

Install-Package MassTransit.SerilogIntegration

Pärast loggeri lisamist MassTransiti seadistusse näeme frameworki logisid.

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

Oletame, et meie rakendus saadab POST-päringu tulemusena sündmuse SomethingDoneMessage väärtusega „done“. Sellise sõnumi lepingu saab kirjeldada järgmiselt:

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

MassTransiti sõnumid on sisuliselt ümbris, mille sisse on paigutatud vahendaja sõnumid. See ümbris näeb välja umbes selline:

{
  "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"
  }
}

Sõnumis on näha teenindusvälju, mida framework ise oma tööks vajab, kuid meil on võimalik sellesse ümbrisesse lisada ka oma täiendavaid omadusi. Lisaks on MassTransitis olemas sisseehitatud vahendid mõne valikulise välja kasutamiseks, millest meid huvitab kõige rohkem korrelatsiooniidentifikaator CorrelationId.

Lisame sõnumi lepingule liidese CorrelatedBy:

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

Rakendame selle ja määrame sõnumi loomisel atribuudile CorrelationId väärtuse:

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; }
}

Kui vaatame uuendatud teadet, näeme, et korrelatsiooniidentifikaatorist on saanud mitte ainult meie sõnumi, vaid ka ümbriku osa — seda identifikaatorit kasutatakse nüüd ka kõigis MassTransit'i logides, mis tähendab, et sõnumivahendaja tasemel probleemide analüüsimine muutub meie jaoks märksa lihtsamaks.

{
  "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"
  }
}

Nüüd jääb üle seadistada nende sõnumi teenusatribuutide logimine, selleks lisame projekti paketi Serilog.Enrichers.MassTransitMessage. Pakett lisab MassTransit'i sõnumitöötluse konveierisse filtri, mis paigutab sõnumi konteksti lõimeturvalisse pinu. Serilog loeb konteksti pinust ja lisab need täiendavad omadused meie logiobjektidele.

Install-Package Serilog.Enrichers.MassTransitMessage

MassTransit'is lisame filtri

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

Ja Serilogi konfiguratsiooni lisame enricheri

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

Kuna rakendusel, mis võtab sõnumi RabbitMQ järjekorrast vastu, on juurdepääs kõigile MassTransit'i ümbriku omadustele, saame saadud korrelatsiooniidentifikaatorit kasutada tarbijarakenduse sees ning edastada seda edasi kogu kutsungiahela ulatuses.

Selle tulemusel sisaldavad meie logid nüüd CorrelationId-d mitte ainult ühe teenuse piires, vaid ka suhtluses teiste rakendustega.

Kokkuvõttes võimaldab selline .Net-rakenduste logimissüsteem meil ilma suuremate raskusteta korreleerida logisid täiesti erinevatest mikroteenustest — isegi neist, mis töötavad sõnumivahendaja kaudu. Elasticsearchi abil saame logisid kiiresti ja mugavalt analüüsida, luues Kibanas vajalikud armatuurlauad (näide on toodud postituse pildil).

Muidugi ei kata sellisel kujul logimine teie teenuste ja erinevate väliste süsteemide keerukamaid koostööstsenaariume, kuid sellise korra loomine juba projekti arenduse alguses on üks neist sammudest, mille eest tänate end hiljem korduvalt.

Valmis süsteemi lähtekoodiga saate tutvuda selles projektis: github.com/a-postx/YA.ServiceTemplate

Allikas: habr.com