Поддерживает ли ASP.Net Core SignalR контексты трассировки W3C или любую распределенную трассировку?

Я работаю над настройкой распределенной трассировки для своего приложения. Одно из подключений в приложении — это подключение WebSocket с использованием SignalR. Оба конца подключения SignalR являются основными приложениями asp.net. Один из них является службой Windows (клиент), а другой работает под управлением веб-сервера (сервер).

Связь будет исходить из обоих направлений, поэтому у меня будут идентификаторы TraceId, исходящие из запросов с обеих сторон соединения. Есть ли в SignalR средство для передачи этой информации о трассировке туда и обратно? Я искал повсюду, и почти нет информации о том, что SignalR поддерживает контексты трассировки W3C или даже пользовательскую реализованную систему трассировки, такую ​​​​как .net core до 2.0.

Я попытался создать новую активность при выполнении запроса на стороне сервера, но я не думаю, что какая-либо информация о трассировке поступает к клиенту. Возможно, я ищу не в том месте, но когда я проверяю System.Diagnostics.Activity.CurrentActivity на клиенте, я получаю только null, хотя на сервере у меня была следующая активность во время звонка.

System.Diagnostics.Activity.Current
{System.Diagnostics.Activity}
    ActivityTraceFlags: None
    Baggage: {System.Collections.Generic.KeyValuePair<string, string>[0]}
    Context: {System.Diagnostics.ActivityContext}
    DisplayName: "Microsoft.AspNetCore.Hosting.HttpRequestIn"
    Duration: {00:00:00}
    Events: {System.Diagnostics.ActivityEvent[0]}
    Id: "00-eb7a4125a171a6438a44ddda5a637cd0-f7c16b0bb8512443-00"
    IdFormat: W3C
    IsAllDataRequested: true
    Kind: Internal
    Links: {System.Diagnostics.ActivityLink[0]}
    OperationName: "Microsoft.AspNetCore.Hosting.HttpRequestIn"
    Parent: null
    ParentId: null
    ParentSpanId: {0000000000000000}
    Recorded: false
    RootId: "eb7a4125a171a6438a44ddda5a637cd0"
    Source: {System.Diagnostics.ActivitySource}
    SpanId: {f7c16b0bb8512443}
    StartTimeUtc: {7/13/2021 11:26:13 PM}
    TagObjects: {System.Collections.Generic.KeyValuePair<string, object>[0]}
    Tags: {System.Collections.Generic.KeyValuePair<string, string>[0]}
    TraceId: {eb7a4125a171a6438a44ddda5a637cd0}
    TraceStateString: null

Я надеюсь, что кто-то там может пролить свет на это.

Спасибо!

-=-=-=-= Редактировать -=-=-=-=

Похоже, что по крайней мере некоторый уровень трассировки контекста W3C поддерживается SignalR при размещении в приложении Blazor. Не знаю, что с этим делать. https://github.com/dotnet/aspnetcore/issues/29846


asp.net-core asp.net-core-5.0 signalr distributed-tracing
person omatase    schedule 13.07.2021    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Журналирование и отслеживание — это два названия одного и того же метода.

  1. Вы можете использовать систему регистрации для сбора диагностической информации, которая поможет решить проблему.
  2. Ведение журнала и диагностика в ASP.NET Основной сигналR
  3. Журналирование и трассировка .NET Core< /сильный>

Если вы хотите внедрить распределенную трассировку, вы можете включить Application Insights для приложений ASP.NET Core.

  1. Application Insights для ASP.NET Core приложения
  2. Распределенная трассировка .NET
person Yihui Sun    schedule 14.07.2021
comment
спасибо, но я ищу решение для ведения журнала, не зависящее от платформы, потому что я не использую ИИ. Я знаю, что могу выполнить трассировку вручную, но мне интересно узнать, решила ли команда SignalR проблему. Хотя я предполагаю, что нет. Однако я нашел статью, показывающую, что по крайней мере некоторый уровень трассировки контекста W3C происходит в SignalR при размещении внутри Blazor. Я не уверен, что с этим делать. github.com/dotnet/aspnetcore/issues/29846 - person omatase; 14.07.2021

arrow_upward
0
arrow_downward

После долгих исследований SignalR не только практически не имеет возможностей расширения для жизненного цикла вызова сообщений (единственный доступный вариант — HubFilters), но и вообще не поддерживает контексты трассировки W3C. Я взялся за реализацию этого самостоятельно, но это большая задача, поэтому я воздержусь, чтобы посмотреть, начнет ли MS поддерживать это в ближайшие 8–12 месяцев. Вот надеюсь.

Подробнее о моих размышлениях о том, как это должно быть реализовано вручную...

Хаб-фильтры

Они предлагают точку соприкосновения с расширяемостью только тогда, когда сообщение приходит от одного из подключенных клиентов. Перед вызовом метода, запрошенным клиентом, у вас есть возможность проверить сообщение, пришедшее от клиента, и предпринять действия со всеми сообщениями в центральном расположении. Кажется, что нет таких вариантов расширения для сообщений, отправляемых клиенту, получаемых клиентом или отправляемых клиентом. Чтобы внедрить код в эти моменты, вы должны сделать это вручную, обернув все свои вызовы функций в другую функцию.

Поддержка заголовков и строк запроса

SignalR позволяет добавлять заголовки и данные в строку запроса, но, поскольку связь через веб-сокет не происходит по протоколу HTTP, нет способа передать данные, относящиеся к каждому сообщению, с помощью этих заголовков.

Заключение

Если вы хотите поддерживать ту же функциональность, которую вы получаете от реализации W3C Trace Contexts в SignalR с веб-сокетами, вам нужно будет передавать общий объект (я назвал свой SignalRContext) в каждом запросе к клиенту или серверу и от них. Этот объект можно использовать для передачи, как минимум, TraceId, чтобы связать воедино всю трассировку вашего приложения.

person omatase    schedule 28.07.2021