Логване в микросервисна среда .Net на практика

Логите е изключително важен инструмент за разработчиците, но когато става въпрос за създаване на разпределени системи, той става основен елемент, който трябва да бъде заложен в основата на вашето приложение, в противен случай сложността на разработката на микросервизи бързо ще се прояви.

В .Net Core 3 беше добавена страхотна възможност за предаване на контекста на корелация в HTTP заглавията, така че ако приложенията ви използват пряки HTTP повиквания за взаимодействие между услугите, можете да се възползвате от тази вградена функционалност. Въпреки това, ако архитектурата на вашия бекенд предвижда взаимодействие чрез брокер на съобщения (RabbitMQ, Kafka и др.), все пак ще трябва сами да се погрижите за предаването на корелационния контекст чрез тези съобщения.

В тази статия ще вземем прост уеб API приложение и ще организираме логването, което

• ще запази последователна корелация между логовете на независимите услуги, така че да можем лесно да проследим всички активности, които са били инициирани от конкретна клиентска заявка.

• да имаме единна точка за вход с удобен анализ, така че инструментът за логиране да бъде полезен дори на Поддръжката, която получава въпроси от типа "в приложението ми се появи грешка с такъв идентификатор на заявката".

Първо, трябва да определим доставчика на логиране в нашето приложение. Основното изискване за съвременно логиране е структурираност, т.е. трябва да работим не с плоски текстови съобщения, а с обекти. С такива логове можем лесно да изграждаме представяния на нашите съобщения от различни перспективи и да провеждаме аналитична работа.

За нашето приложение ще използваме пакета Serilog, който предлага отлична поддръжка за структурно логиране и богата система от разширения. Ще пропусна основните стъпки по неговото конфигуриране (можете да намерите много статии по тази тема) и ще приема, че

• Serilog вече е конфигуриран и е логер по подразбиране в вашия доставчик на инжектиране на зависимости

• в неговата конфигурация е включено обогатяване на съобщенията със свойствата на контекста (Enrich.FromLogContext)

Следващата стъпка е да изберем в коя система за централизирано събиране на логове да изпращаме съобщения от Serilog. Най-разпространеното в момента от отворен софтуер е стека ELK (Elasticsearch, Logstash и Kibana), него и ще използваме. За това ще се възползваме от предложението на Logz.IO — след регистрацията на безплатния тариф получаваме цялата мощ на търсачката Lucene.

Остава да добавим в нашия проект пакета Serilog.Sinks.Logzio

Install-Package Serilog.Sinks.Logzio

и да добавим съответния енричер в конфигурацията на нашия логер, предоставяйки му токена за достъп

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

След стартиране на приложението ще можем да наблюдаваме нашите съобщения не само в конзолата, но и в Kibana.

Интерфейси

В приложението от тип услуга можем да откроим два основни интерфейса за взаимодействие с външния свят, които ще обозначим като вертикален и хоризонтален. Вертикалният интерфейс е уеб API, през което идват извиквания от клиентското приложение. Хоризонталният е брокер на съобщения, който се използва за обмен на данни с други вътрешни услуги.

Нека разгледаме етапите на внедряване на корелация при всеки от тези интерфейси.

Корелация в HTTP заявките

За да получим възможно най-много информация, е необходимо да генерираме идентификатор за корелация възможно най-близо до началото на активността, т.е. на шлюза или директно на клиента (мобилен или уеб). Тъй като днес разглеждаме бекенд приложение, просто ще обозначим изискването за задължителен заглавен етикет „X-Correlation-ID“ във всички заявки към уеб API.

Добавяме пакета CorrelationID, функцията на който е да извлича стойността от необходимия ни заглавен етикет

Install-Package CorrelationID

Нека го добавим в конвейера за обработка на заявката

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

Сега с неговата помощ ще направим прост action-филтър:

публичный запечатанный класс ApiRequestFilter : ActionFilterAttribute
{
    публичный ApiRequestFilter(IApiRequestTracker apiRequestTracker, ICorrelationContextAccessor correlationContextAccessor)
    {
        _correlationContextAccessor = correlationContextAccessor ?? выбросить новое ArgumentNullException(nameof(correlationContextAccessor));
    }
    
    частный readonly ICorrelationContextAccessor _correlationContextAccessor;
    
    публичный переопределяемый async Task OnActionExecutionAsync(ActionExecutingContext context, ActionExecutionDelegate next)
    {
        если (!Guid.TryParse(_correlationContextAccessor.CorrelationContext.CorrelationId, out Guid correlationId))
        {
            context.Result = новая BadRequestResult();
            возврат;
        }
    
        await next.Invoke();
    }
    
    публичный переопределяемый async Task OnResultExecutionAsync(ResultExecutingContext context, ResultExecutionDelegate next)
    {
        await next.Invoke();
    }
}

И добавим его в контролер

[Route("[controller]")]
[ApiController]
[ServiceFilter(typeof(ApiRequestFilter))]
публичный класс CarsController : ControllerBase
{

}

В результате контролер будет возвращать 400 Bad request на все запросы без заголовка с соответствующим идентификатором.

После того, как мы начали получать идентификатор от клиента, мы должны добавить его в контекст журналирования, сделаем для этого обертку:

публичный класс CorrelationIdContextLogger
{
    публичный CorrelationIdContextLogger(RequestDelegate next)
    {
        _next = next ?? выбросить новое ArgumentNullException(nameof(next));
    }
    
    readonly RequestDelegate _next;
    
    публичный async Task InvokeAsync(HttpContext httpContext, ILogger logger, ICorrelationContextAccessor correlationContextAccessor)
    {
        если (Guid.TryParse(correlationContextAccessor.CorrelationContext.CorrelationId, out Guid correlationId))
        {
            используя (logger.BeginScopeWith(("CorrelationId", correlationId)))
            {
                await _next(context);
            }
        }
        еще
        {
            await _next(context);
        }
    }
}

В нашем приложении мы используем стандартный ILogger из пакета Microsoft.Extensions.Logging.Abstractions, поэтому значение будем добавлять с помощью простого расширения к нему.

public static IDisposable BeginScopeWith(this ILogger logger, params (string key, object value)[] keys)
{
    возвращает logger.BeginScope(keys.ToDictionary(x => x.key, x => x.value));
}

Добавляем обертку в конвейер обработки запроса и получаем нужный результат.

публичный класс Startup
{
    публичный void Configure(IApplicationBuilder application)
    {
        application.UseMiddleware();
    }
}

Теперь все активности, которые порождены запросами к нашему веб-API, содержат корреляционный идентификатор, по которому их можно легко связать.

Корреляция в сообщениях брокера

Следващата стъпка е да настройим предаването и получаването на корелационния идентификатор чрез брокер на съобщения. В нашия пример ще използваме RabbitMQ, а клиентът ще бъде фреймворкът MassTransit. Отново, ще пропуснем първоначалната настройка на MassTransit и ще преминем директно към настройката на логването.

За начало можем да активираме логовете на самия MassTransit, за това ще добавим в приложението си пакета MassTransit.SerilogIntegration

Install-Package MassTransit.SerilogIntegration

Сега, след добавянето на логера към настройките на MassTransit, ще можем да виждаме логовете на фреймворка.

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

Нека приложението ни като реакция на POST заявка да изпраща събитие SomethingDoneMessage със стойност „done“. Контрактът на такова съобщение може да се опише така:

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

Съобщенията на MassTransit по същество представляват конверт, в който са вложени съобщения на брокера. Конвертът изглежда приблизително така:

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

В съобщението се виждат служебни полета, които са необходими за функционирането на самия фреймворк, но имаме възможност да добавим и свои допълнителни свойства в този конверт. Освен това, MassTransit има вградени средства за работа с някои опционални полета, от които най-интересен е идентификаторът на корелационност CorrelationId.

Добавяме към контракта на съобщението интерфейса CorrelatedBy:

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

Реализираме го и ще зададем стойността на свойството CorrelationId при създаването на съобщението:

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

Ако разгледаме обновеното съобщение, ще видим, че идентификаторът на корелация не само стана част от нашето съобщение, но и от конверта — този идентификатор сега ще се използва и в логовете на MassTransit, което означава, че ще бъде много по-лесно да се справим с проблемите на ниво съобщителен брокер.

{
  "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": "Здравей"
  }
}

Остава ни да настроим регистрирането на тези служебни свойства на съобщението, за което ще добавим в проекта пакета Serilog.Enrichers.MassTransitMessage. Пакетът добавя филтър в конвейера за обработка на съобщения в MassTransit, който поставя контекста на съобщението в потокобезопасен стек. Serilog чете контекста от стека и добавя тези допълнителни свойства в нашите лог обекти.

Install-Package Serilog.Enrichers.MassTransitMessage

В MassTransit вмъкваме филтър

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

А в конфигурацията на Serilog добавяме енричер

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

Тъй като приложението, което получава съобщение от опашката RabbitMQ, има достъп до всички свойства на конверта на MassTransit, можем да използваме полученото идентификатор на корелация в приложението-потребител, а също и да го предаваме по веригата на извиквания.

В резултат нашите логове започнаха да съдържат CorrelationId не само в рамките на един сервис, но и при взаимодействие с други приложения.

Така получената система за регистрация в .Net приложенията ни позволява без особени проблеми да корелираме логовете от абсолютно различни микросервиси — дори и тези, които работят през съобщителен брокер. А с помощта на Elasticsearch можем бързо и удобно да анализираме логовете, създавайки в Kibana необходимите ни табла (примерът е показан на изображението към публикацията).

Разбира се, в този вид логването няма да покрие сложни варианти на взаимодействие между вашите услуги и различни външни системи, но установяването на такъв ред в самото начало на развитието на проекта е едно от нещата, за които сами ще си благодарите в бъдеще.

Можете да се запознаете с изходния код на получената система в проекта: github.com/a-postx/YA.ServiceTemplate

Източник: habr.com