Logimine mikroteenuste keskkonnas .Net'is praktikas

Logimine on arendaja jaoks väga oluline tööriist, kuid jaotatud süsteemide loomisel muutub see vajalikuks aluseks, mille peate asetama just oma rakenduse fundamenti; vastasel juhul võib mikroteenuste arendamise keerukus kiiresti ilmneda.

.Net Core 3 on lisandunud suurepärane võimalus edastada korrelatsiooni konteksti HTTP-pealkirjades, seega, kui teie rakendused kasutavad otse HTTP-kõnesid teenustevaheliseks suhtlemiseks, võite seda välja pakutud funktsionaalsust kasutada. Kuid kui teie taustaarhitektuur eeldab suhtlemist sõnumite edastamise kaudu (näiteks RabbitMQ, Kafka jne), peate endiselt ise pöörama tähelepanu selle korrelatsiooni konteksti edastamisele läbi nende sõnumite.

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

• salvestab pideva korrelatsiooni sõltumatute teenuste logide vahel, et oleks lihtne vaadata kõiki tegevusi, mis olid seotud konkreetse kliendi päringuga.

• omada ühtne sissepääs mugava analüüsi võimalustega, et logimise tööriista saaks kasutada isegi tugi, kelle poole pöördutakse küsimustega nagu «mul on siin rakenduses sellise päringu ID-ga viga»

Esiteks peame välja valima logimise teenusepakkuja meie rakendusele. Peamine nõue kaasaegsele logimisele on struktuursus, st me ei tohi töötada tasaste tekstisõnumitega, vaid objektidega. Tänu sellistele logidele saame hõlpsasti luua meie sõnumite esitusi erinevates mõõtmetes ja teostada analüütikat.

Meie rakenduses kasutame Serilogi paketti, mis toetab suurepäraselt struktuurset logimist ja omab laia lisandite süsteemi. Jätan vahele selle seadistamise põhietapid (saate leida palju artikleid selle kohta) ja teen eeldusi, et

• Serilog on juba konfigureeritud ja on teie sõltuvuse sisestamise teenusepakkuja vaikimisi logija

• tema konfiguratsioonis on aktiveeritud sõnumite rikastamine konteksti omadustega (Enrich.FromLogContext)

Järgmiseks sammuks on valida, millisesse kesksesse logide kogumise süsteemi edastada sõnumid Serilogist. Tänapäeval on kõige laialdasemalt kasutatav avatud lähtekoodiga lahendus ELK (Elasticsearch, Logstash ja Kibana), ja valimegi selle. Selleks kasutame ettepanekut Logz.IO — pärast tasuta plaaniga registreerimist on meie käsutuses kogu Lucene'i otsimootori jõud.

Peame lihtsalt meie projekti lisama paki Serilog.Sinks.Logzio

Install-Package Serilog.Sinks.Logzio

Ja lisama vastava rikastaja meie logeri konfiguratsiooni, andes talle juurdepääsutokeni

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

Rakenduse käivitamisel saame jälgida meie sõnumeid mitte ainult konsoolis, vaid ka Kibanas.

Liidesed

Teenuse rakenduses võib eristada kaht peamist liidest, mille kaudu see suhtub välismaailmaga, tähistame neid kui vertikaalne ja horisontaalne. Vertikaalne liides on veeb-API, mille kaudu tuleb kliendirakenduselt kutsed. Horisontaalne on sõnumite vahendaja, mida kasutatakse andmete vahetamiseks teiste sisemiste teenustega.

Vaatame korrelatsiooni rakendamise etappe igas nendes liidestes.

Korrelatsioon HTTP-päringutes

Kuna soovime saada võimalikult palju teavet, peame genereerima korrelatsiooni ID nii varakult kui võimalik, st väravas või otse kliendis (mobiilne või veeb). Kuna täna käsitleme tagaplaneerimise rakendust, märkime lihtsalt nõude kohustusliku päise „X-Correlation-ID” olemasolu kõigis veeb-API päringutes.

Lisame paketi CorrelationID, mille funktsioon on võtta vajalik väärtus vajaliku päise seest.

Install-Package CorrelationID

Lisame selle päringu töötlemise torusse

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 tema 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
{

}

Seega hakkab kontroller vastama kõigile päringutele, millel puudub vastava identifikaatoriga päis, 400 Bad Request.

Pärast seda, kui hakkasime klientidelt identifikaatorit saama, peame selle logimis konteksti lisama, selleks loome ümberpärimise vahekihina:

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

Meie rakenduses kasutame Microsoft.Extensions.Logging.Abstractions paketist standardset ILogger'i, seetõttu lisame väärtuse 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 vahendaja päringute töötlemise konveierisse ja saame soovitud tulemuse.

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

Nüüd sisaldavad kõik tegevused, mis on põhjustatud meie veeb API päringutest, korrelatsioonilist identifikaatorit, mille kaudu neid on lihtne omavahel seostada.

Korrelatsioon sõnumites maakleris

Järgmise sammuna peame seadma üles korrelatsioonilise identifikaatori edastamise ja vastuvõtmise sõnumiteenuse kaudu. Meie näites kasutame RabbitMQ-d ja kliendiks on MassTransit raamistik. Jätame vahele MassTransit'i esialgse seadistamise ja liigume kohe logimise seadistamise juurde.

Esimese asjana saame sisse lülitada MassTransit'i logid, selle jaoks lisame oma rakendusse paketi MassTransit.SerilogIntegration

Install-Package MassTransit.SerilogIntegration

Nüüd, pärast logeri lisamist MassTransit'i seadistustesse, näeme raamistikku logisid.

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

Las meie rakendus reageerib POST-päringule, saates sündmuse SomethingDoneMessage väärtusega „done“. Sellise sõnumi lepingut saab kirjeldada järgmiselt:

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

MassTransit'i sõnumid on sisuliselt ümbrikud, kuhu on pakitud sõnumid brokeri poolt. Ümbrik näeb välja umbes nii:

{
  "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 süsteemiväljad, mis on vajalikud raamistiku toimimiseks, kuid meil on võimalik lisada sellesse ümbrikusse ka enda täiendavad omadused. Veelgi enam, MassTransit sisaldab sisseehitatud võimalusi teatud valikuväljade töötlemiseks, millest meid kõige rohkem huvitab CorrelationId koordineerimise identifikaator.

Lisame sõnumi lepingule CorrelatedBy liidese:

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

Rakendame seda ja määrame CorrelationId omadusele väärtuse sõnumi loomisel:

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 värskendatud teadet, siis näeme, et korrelatsioonidentifikaator on saanud mitte ainult meie sõnumi osaks, vaid ka ümbriku osaks — see identifikaator kasutatakse nüüd ka kõigis MassTransit logides, mis teeb probleemide lahendamise sõnumi vahendaja tasemel oluliselt 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"
  }
}

Meil jääb üle vaid seadistada nende teenuslikud omadused sõnumite logimine, selleks lisame projekti paketi Serilog.Enrichers.MassTransitMessage. Paketiga lisatakse MassTransit sõnumite töötlemise torustikku filter, mis kogub sõnumi konteksti lõimeta ohutusse kuhja. Serilog loeb konteksti kuhjast ja lisab meie logiobjektidesse need lisad omadused.

Install-Package Serilog.Enrichers.MassTransitMessage

MassTransit'is lisame filtri

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

Ja Serilogi konfiguratsioonis lisame rikastaja

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

Kuna rakendus, mis saab sõnumi RabbitMQ järjekorrast, pääseb ligi kõigile MassTransit konverteerimise omadustele, saame kasutada saadud korrelatsiooni ID-d ka tarbija rakenduses ning edastada seda edasi kogu kutsehelise ahela jooksul.

Kuna meie logid sisaldavad CorrelationId mitte ainult ühe teenuse piires, vaid ka suheldes teiste rakendustega.

Seega võimaldab saadud logimissüsteem .Net rakendustes meil probleemideta korreleerida logisid täiesti erinevatest mikroteenustest — isegi nendest, mis töötavad sõnumivahendaja kaudu. Ja Elasticsearchi abil saame kiiresti ja mugavalt analüüsida logisid, luues Kibanas vajalikud juhtpaneelid (näide on toodud postituse pildil).

Muidugi ei kata selline logimine keerulisi teie teenuste ja erinevate välistoodete vahelisi interaktsioone, kuid sellise korra kehtestamine projekti arengu alguses on üks neist asjadest, mille eest ütlete endale hiljem tänu.

Saate uurida projekti saadud süsteemi lähtekoodi: github.com/a-postx/YA.ServiceTemplate

Allikas: habr.com