Журналы ресурсов для Службы Azure SignalR

В этом руководстве рассматриваются журналы ресурсов для Службы Azure SignalR, способы их настройки и устранения неполадок.

Предварительные требования

Чтобы включить журналы ресурсов, вам понадобится место для хранения данных журнала. В этом руководстве используются служба хранилища Azure и Log Analytics.

  • Служба хранилища Azure — обеспечивает хранение журналов ресурсов для аудита политик, статического анализа или резервного копирования.
  • Log Analytics — гибкий инструмент для поиска по журналам и анализа, позволяющий анализировать необработанные журналы, созданные ресурсом Azure.

Настройка журналов ресурсов для Службы Azure SignalR

Вы можете просматривать журналы ресурсов для Службы Azure SignalR. Эти журналы предоставляют более широкие возможности подключения к экземпляру Служба Azure SignalR. Журналы ресурсов предоставляют подробные сведения для каждого подключения. Например, основные сведения (идентификатор пользователя, идентификатор подключения и тип транспорта и т. д.) и сведения о событии (подключение, отключение и прерывание события и т. д.) подключения. Журналы ресурсов можно использовать для поиска проблем, отслеживания и анализа подключений.

Включение журналов ресурсов

По умолчанию журналы ресурсов отключены. Чтобы включить журналы ресурсов, сделайте следующее:

  1. В портал Azure в разделе "Мониторинг" выберите параметры диагностики.

    Панель навигации для параметров диагностики

  2. Затем вы получите полное представление параметров диагностики.

    Полное представление параметров диагностики

  3. Настройте параметры источника журнала.

    1. В разделе " Параметры источника журнала " в таблице показано, как собирать поведения для каждого типа журнала.
    2. Проверьте конкретный тип журнала, который требуется собрать для всех подключений. В противном случае журнал будет собираться только для клиентов диагностики.
  4. Настройте параметры назначения журнала.

    1. В разделе " Параметры назначения журнала " в таблице параметров диагностики отображаются существующие параметры диагностики. Можно выбрать ссылку в таблице, чтобы получить доступ к назначению журнала, чтобы просмотреть собранные журналы ресурсов.
    2. В этом разделе выберите кнопку "Настройка параметров назначения журнала " для добавления, обновления или удаления параметров диагностики.
    3. Выберите "Добавить параметр диагностики ", чтобы добавить новый параметр диагностики, или выберите "Изменить ", чтобы изменить существующий параметр диагностики.
    4. Задайте целевое расположение архивации. В настоящее время служба SignalR поддерживает архивацию в учетную запись хранения и отправку в Log Analytics.
    5. Выберите журналы, которые необходимо архивировать. Доступно только AllLogs для журнала ресурсов. Он определяет, нужно ли архивировать журналы. Чтобы настроить типы журналов, которые необходимо создать в службе SignalR, настройте их в разделе " Параметры источника журнала ".

    Панель параметров диагностики

    1. Сохраните новый параметр диагностики. Новый параметр вступает в силу примерно за 10 минут. После этого журналы будут отправляться в настроенный целевой объект архивации. Дополнительные сведения о настройке параметров назначения журнала см. в обзоре журналов ресурсов Azure.

Категории журналов ресурсов

Azure SignalR поддерживает три типа журналов: журнал подключения и журнал обмена сообщениями.

Журналы подключения

Журналы подключения предоставляют подробные сведения о подключениях концентратора SignalR. Например, основные сведения (идентификатор пользователя, идентификатор подключения и тип транспорта и т. д.) и сведения о событии (подключение, отключение и прерывание событий и т. д.). Поэтому журнал подключения полезен для устранения неполадок, связанных с подключением. Типичное руководство по устранению неполадок, связанных с подключением, см. в разделе о проблеме, связанной с подключением.

Журналы обмена сообщениями

Журналы обмена сообщениями предоставляют сведения трассировки для полученных и отправленных через службу SignalR сообщений концентратора SignalR. Например, идентификатор трассировки и тип сообщения. Идентификатор трассировки и тип сообщения также регистрируются на сервере приложений. Обычно сообщение записывается при поступлении или выходе из службы или сервера. Поэтому журналы обмена сообщениями полезны для устранения неполадок, связанных с сообщениями. Общие сведения об устранении неполадок, связанных с сообщениями, см. в разделе "Проблемы, связанные с сообщениями".

Примечание

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

Журналы http-запросов

Журналы http-запросов предоставляют подробные сведения о http-запросах, полученных Azure SignalR. Например, код состояния и URL-адрес запроса. Журнал http-запросов полезен для устранения неполадок, связанных с запросами.

"Архивировать в учетной записи хранения";

Журналы хранятся в учетной записи хранения, настроенной на панели Журналы диагностики. Для хранения журналов ресурсов автоматически создается контейнер insights-logs-alllogs. Внутри контейнера журналы хранятся в файле resourceId=/SUBSCRIPTIONS/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/RESOURCEGROUPS/XXXX/PROVIDERS/MICROSOFT.SIGNALRSERVICE/SIGNALR/XXX/y=YYYY/m=MM/d=DD/h=HH/m=00/PT1H.json. По сути путь формируется путем объединения resource ID и Date Time. Файлы журнала разделены по часам (hour). Таким образом, минуты всегда будут иметь значение m=00.

Все журналы хранятся в формате JSON (нотация объектов JavaScript). Каждая запись содержит строковые поля, использующие формат, описанный в следующих разделах.

Строки JSON архивных журналов содержат элементы, перечисленные в таблице ниже.

Формат

Имя Описание
time Время события журнала
уровень Уровень события журнала
resourceId Идентификатор ресурса вашей Службы Azure SignalR
location Расположение вашей Службы Azure SignalR
категория Категория события журнала
operationName Имя операции для события
callerIpAddress IP-адрес сервера или клиента
properties Подробные свойства, связанные с этим событием журнала. Дополнительные сведения см. в таблице свойств ниже.

Таблица свойств

Имя Описание
type Тип события журнала. В настоящее время мы предоставляем сведения о подключениях к службе Azure SignalR. Доступен только тип ConnectivityLogs.
коллекция Коллекция событий журнала. Допустимые значения: Connection, Authorization и Throttling.
connectionId Удостоверение соединения.
transportType Тип транспорта соединения. Допустимые значения: Websockets | ServerSentEvents | LongPolling
connectionType Тип подключения. Допустимые значения: Server | Client. Server: подключение со стороны сервера; Client: подключение со стороны клиента.
userId Удостоверение пользователя
message Подробное сообщение о событии журнала.

Ниже приведен пример строки JSON журнала архивирования.

{
    "properties": {
        "message": "Entered Serverless mode.",
        "type": "ConnectivityLogs",
        "collection": "Connection",
        "connectionId": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
        "userId": "User",
        "transportType": "WebSockets",
        "connectionType": "Client"
    },
    "operationName": "ServerlessModeEntered",
    "category": "AllLogs",
    "level": "Informational",
    "callerIpAddress": "xxx.xxx.xxx.xxx",
    "time": "2019-01-01T00:00:00Z",
    "resourceId": "/SUBSCRIPTIONS/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/RESOURCEGROUPS/XXXX/PROVIDERS/MICROSOFT.SIGNALRSERVICE/SIGNALR/XXX",
    "location": "xxxx"
}

Схема архивов журналов для Log Analytics.

Чтобы просмотреть журналы ресурсов, сделайте следующее:

  1. Выберите Logs целевой Log Analytics.

    Пункт меню Log Analytics

  2. Введите SignalRServiceDiagnosticLogs и задайте диапазон времени для запроса журналов ресурсов. Сведения о составлении расширенных запросов см. в статье Начало работы с Log Analytics в Azure Monitor.

    Запрос журналов Log Analytics

Чтобы использовать пример запроса для службы SignalR, выполните следующие действия.

  1. Выберите Logs целевой Log Analytics.

  2. Выберите Queries , чтобы открыть обозреватель запросов.

  3. Выберите Resource type группирование примеров запросов в типе ресурса.

  4. Выберите Run , чтобы запустить скрипт.

    Пример запроса в Log Analytics

Столбцы архивных журналов содержат элементы, перечисленные в таблице ниже.

Имя Описание
TimeGenerated Время события журнала
Коллекция Коллекция событий журнала. Допустимые значения: Connection, Authorization и Throttling.
OperationName Имя операции для события
Расположение Расположение вашей Службы Azure SignalR
Level Уровень события журнала
CallerIpAddress IP-адрес сервера или клиента
Сообщение Подробное сообщение о событии журнала.
UserId Удостоверение пользователя
ConnectionId Удостоверение соединения.
ConnectionType Тип подключения. Допустимые значения: Server | Client. Server: подключение со стороны сервера; Client: подключение со стороны клиента.
TransportType Тип транспорта соединения. Допустимые значения: Websockets | ServerSentEvents | LongPolling

Устранение неполадок с журналами ресурсов

Для устранения неполадок в службе Azure SignalR можно включить журналы на стороне сервера или клиента для записи ошибок. Теперь Служба Azure SignalR предоставляет журналы ресурсов, можно также включить журналы на стороне службы.

В случае непредвиденного увеличения или уменьшения числа подключений вы можете воспользоваться этими журналами для устранения неполадок.

Проблемы часто возникают при непредвиденных изменениях количества подключений, если их число достигает предела и при сбоях авторизации. Сведения об устранении этих неполадок см. в следующих разделах.

При обнаружении непредвиденного увеличения или удаления подключения можно воспользоваться преимуществами журналов подключения для устранения неполадок.

Типичные проблемы часто связаны с непредвиденными изменениями количества подключений, подключения достигают ограничений авторизации и потери сообщений. Сведения об устранении этих неполадок см. в следующих разделах.

Непредвиденное изменение числа подключений
Непредвиденное уменьшение числа подключений

Если число подключений непредвиденно сократилось, сначала включите журналы на стороне службы, сервера и клиента.

Если подключение отключается, журналы ресурсов записывают это событие отключения, вы увидите ConnectionAborted или ConnectionEnded в operationName.

Разница между ConnectionAborted и ConnectionEnded заключается в том, что ConnectionEnded представляет собой ожидаемое отключение, инициируемое на стороне клиента или сервера. А ConnectionAborted обычно означает непредвиденное событие разрыва соединения, а его причина предоставлена значением message.

Возможные причины разрыва перечислены в таблице ниже.

Причина Описание
Число подключений достигло предела. Число подключений достигло предельного значения для вашей текущей ценовой категории. Попробуйте вертикально увеличить масштаб модуля службы.
Удаленный сервер закрыл соединение SQL. Разрыв соединения инициирован сервером приложений. Это может рассматриваться в качестве ожидаемого разрыва.
Истекло время ожидания проверки соединения. Обычно это вызвано проблемой сети. Попробуйте проверить доступность сервера приложений из Интернета.
Перезагрузка службы, попытка повторного подключения Служба Azure SignalR перегружается. Azure SignalR поддерживает автоматическое повторное подключение, вы можете дождаться повторного подключения или повторного подключения вручную к Служба Azure SignalR
Временная внутренняя ошибка сервера. В службе Azure SignalR возникает временная ошибка, которая обычно устраняется автоматически.
Соединение с сервером разорвано. Подключение к серверу разрывается из-за неизвестной ошибки. Сначала рекомендуется попробовать самостоятельно устранить неполадки с помощью журнала на стороне службы, сервера или клиента. Попробуйте исключить основные проблемы (например, проблема с сетью, проблема на стороне сервера приложений и т. д.). Если устранить проблему не удается, обратитесь к нам за помощью. Дополнительные сведения см. в разделе о получении помощи.
Непредвиденный рост числа подключений

Чтобы устранить неполадки, связанные с непредвиденным увеличением подключения, первое, что необходимо сделать, — отфильтровать дополнительные подключения. Вы можете добавить уникальный идентификатор тестового пользователя в тестовое подключение клиента. Проверьте журналы ресурсов. Если несколько клиентских подключений имеют один и тот же идентификатор тестового пользователя или IP-адрес, скорее всего, на стороне клиента создается больше подключений, чем ожидалось. Проверьте клиентскую часть.

Сбой авторизации

Если для клиентских запросов возвращается ошибка 401 "Несанкционированный доступ", проверьте журналы ресурсов. При обнаружении Failed to validate audience. Expected Audiences: <valid audience>. Actual Audiences: <actual audience>это означает, что все аудитории в маркере доступа недопустимы. Попробуйте использовать допустимые аудитории, предложенные в журнале.

Регулирование

Если вы обнаружите, что не удается установить клиентские подключения SignalR к Служба Azure SignalR, проверьте журналы ресурсов. Если в журнале ресурсов вы видите сообщение Connection count reaches limit, это означает, что к службе SignalR устанавливается слишком много подключений и достигается предел. Рассмотрите возможность масштабирования службы SignalR. Если в журнале ресурсов вы видите сообщение Message count reaches limit, это означает, что вы используете бесплатный ценовой уровень и израсходовали квоту сообщений. Если вы хотите отправить больше сообщений, попробуйте изменить Служба SignalR на стандартный уровень, чтобы отправить больше сообщений. Дополнительные сведения см. на странице цен на Службу Azure SignalR.

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

Примечание

Сведения о ASP.NET Core см. здесь, чтобы включить ведение журнала на сервере и клиенте.

Сведения о ASP.NET см. здесь , чтобы включить ведение журнала на сервере и клиенте.

Если вы не возражаете о потенциальных последствиях производительности и не отправляете сообщение о направлении между клиентами и сервером, проверьте его MessagingLog Source Settings/Types , чтобы включить поведение сбора журналов для сбора всех журналов. Дополнительные сведения об этом поведении см. в разделе "Сбор всех данных".

В противном случае снимите флажок Messaging , чтобы включить режим сбора частичного сбора журналов. Для этого требуется настройка на клиенте и сервере, чтобы включить ее. Дополнительные сведения см. в разделе "Сбор частично".

Потеря сообщений

При возникновении проблемы с потерей сообщений ключ — найти место, в котором вы потеряете сообщение. По сути, при использовании службы SignalR есть три компонента: служба SignalR, сервер и клиент. Сервер и клиент подключены к службе SignalR, они не подключаются друг к другу напрямую после завершения согласования. Поэтому необходимо рассмотреть два направления для сообщений, для каждого направления необходимо рассмотреть два пути:

  • От клиента к серверу через службу SignalR
    • Путь 1. Клиент — служба SignalR
    • Путь 2. Служба SignalR на сервер
  • От сервера к клиенту через службу SignalR
    • Путь 3. Сервер к службе SignalR
    • Путь 4. Служба SignalR для клиента

Путь к сообщению

Для сбора всех действий сбора :

Служба SignalR отслеживает только сообщения в направлении от сервера к клиенту через службу SignalR. Идентификатор трассировки будет создан на сервере, сообщение будет содержать идентификатор трассировки в службу SignalR.

Примечание

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

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

Для частичного сбора данных о поведении:

Помечая клиент как диагностический клиент, служба SignalR будет отслеживать сообщения в обоих направлениях.

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

Сведения о потоке сообщений

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

Идентификатор трассировки будет создан в службе SignalR после поступления сообщения в службу SignalR в пути 1. Служба SignalR создаст журнал Received a message <MessageTracingId> from client connection <ConnectionId>. для каждого сообщения в клиенте диагностики. После выхода сообщения из SignalR на сервер служба SignalR создаст сообщение Sent a message <MessageTracingId> to server connection <ConnectionId> successfully.журнала. Если вы видите эти два журнала, вы можете убедиться, что сообщение успешно проходит через службу SignalR.

Примечание

Из-за ограничения ASP.NET Core SignalR сообщение поступает от клиента не содержит идентификатора уровня сообщения. Но ASP.NET SignalR создает идентификатор вызова для каждого сообщения, его можно использовать для сопоставления с идентификатором трассировки.

Затем сообщение содержит сервер идентификатора трассировки в пути 2. Сервер создаст журнал Received message <messagetracingId> from client connection <connectionId> после поступления сообщения.

После вызова метода концентратора на сервере будет создано новое сообщение службы с новым идентификатором трассировки. После создания сообщения службы сервер создаст шаблон Start to broadcast/send message <MessageTracingId> ...входа, фактический журнал будет основываться на вашем сценарии. Затем сообщение будет доставлено в службу SignalR в пути 3, после выхода сообщения службы с сервера будет создан вызов Succeeded to send message <MessageTracingId> журнала.

Примечание

Идентификатор трассировки сообщения от клиента не может сопоставляться с идентификатором трассировки сообщения службы, отправляемого в службу SignalR.

После поступления сообщения службы в службу SignalR будет создан журнал Received a <MessageType> message <MessageTracingId> from server connection <ConnectionId>. . Затем служба SignalR обрабатывает сообщение службы и доставляет их целевым клиентам. После отправки сообщения клиенту в пути 4 будет создан журнал Sent a message <MessageTracingId> to client connection <ConnectionId> successfully. .

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

Ниже приведена типичная проблема с потерей сообщений.

Клиенту не удается получить сообщения в группе

Типичная история в этой проблеме заключается в том, что клиент присоединяется к группе после отправки сообщения группы.

Class Chat : Hub
{
    public void JoinAndSendGroup(string name, string groupName)
    {
        Groups.AddToGroupAsync(Context.ConnectionId, groupName); // join group
        Clients.Group(groupName).SendAsync("ReveiceGroupMessage", name, "I'm in group"); // send group message
    }
}

Например, кто-то может выполнять вызовы группы присоединения и отправлять сообщение группы в том же методе концентратора. Проблема в этом AddToGroupAsync заключается в методе async . Ожидание AddToGroupAsync завершения не выполняетсяawait, сообщение группы, отправленное до AddToGroupAsync завершения. Из-за задержки сети и задержки процесса присоединения клиента к какой-либо группе действие группы присоединения может завершиться позже, чем доставка сообщений группы. В этом случае первое сообщение группы не будет иметь клиента в качестве получателя, так как клиент не присоединился к группе. Таким образом, это приведет к потере сообщения.

Без журналов ресурсов вы не можете узнать, когда клиент присоединяется к группе и когда отправляется сообщение группы. После включения журналов обмена сообщениями вы сможете сравнить время прибытия сообщения в службе SignalR. Чтобы устранить неполадки, выполните следующие действия.

  1. Найдите журналы сообщений на сервере, чтобы найти, когда клиент присоединился к группе и когда отправляется сообщение группы.
  2. Получите идентификатор трассировки сообщений A для присоединения к группе и идентификатора трассировки сообщений B сообщения группы из журналов сообщений.
  3. Отфильтруйте этот идентификатор трассировки сообщений среди журналов в целевом объекте архива журналов, а затем сравните их поступающие метки времени, вы увидите, какое сообщение прибыло в первую очередь в службе SignalR.
  4. Если идентификатор трассировки сообщений— время прибытия позже, чем время прибытия B, перед присоединением клиента к группе необходимо отправить сообщение группы. Затем необходимо убедиться, что клиент находится в группе перед отправкой сообщений группы.

Если сообщение теряется в SignalR или сервере, попробуйте получить журналы предупреждений на основе идентификатора трассировки сообщений, чтобы получить причину. Если вам нужна дополнительная помощь, ознакомьтесь с разделом справки.

Продвинутый уровень

Журналы ресурсов, собирающие поведение

Существует два типичных сценария использования журналов ресурсов, особенно для журналов обмена сообщениями.

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

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

Таким образом, служба SignalR предоставляет два типа поведения сбора

  • сбор всех данных: сбор журналов во всех подключениях
  • сбор частично: сбор журналов в некоторых конкретных подключениях

Примечание

Чтобы различать подключения между этими журналами сбора и не собираемыми журналами, служба SignalR будет рассматривать некоторый клиент как диагностический клиент на основе конфигураций сервера и клиента диагностики, в которых журналы ресурсов всегда собираются, а другие — нет. Дополнительные сведения см. в разделе "Сбор частично".

Сбор всех

Журналы ресурсов собираются всеми подключениями. Например, берите журналы обмена сообщениями. Если это поведение включено, служба SignalR отправит на сервер уведомление, чтобы начать создание идентификатора трассировки для каждого сообщения. Идентификатор трассировки будет перенесен в сообщение в службу, служба также зановит сообщение с идентификатором трассировки.

Примечание

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

Руководство по настройке

Чтобы включить это поведение, установите флажок в разделе "Типы " в параметрах источника журнала.

Такое поведение не требует обновления конфигураций на стороне сервера. Это изменение конфигурации всегда будет отправляться на сервер автоматически.

Частичное сбор данных

Журналы ресурсов собираются толькоклиентами диагностики. Все сообщения регистрируются, включая клиентские сообщения и события подключения в диагностических клиентах.

Примечание

Ограничение числа клиентов диагностики равно 100. Если число диагностических клиентов превышает 100, число аутсайдеров диагностики будет регулироваться службой SignalR. Новые, но нечислемые клиенты не смогут подключиться к службе SignalR и вызвать System.Net.Http.HttpRequestException сообщение Response status code does not indicate success: 429 (Too Many Requests), в то время как уже подключенные клиенты работают без влияния политики регулирования.

Клиент диагностики

Клиент диагностики — это логическая концепция, любой клиент может быть диагностическим клиентом. Сервер управляет клиентом, который может быть клиентом диагностики. После того как клиент помечается как диагностический клиент, все журналы ресурсов будут включены в этом клиенте. Сведения о настройке клиента в качестве клиента диагностики см. в руководстве по настройке ниже.

Руководство по настройке

Чтобы включить это поведение, необходимо настроить службу, сервер, сторону клиента.

Сторона службы

Чтобы включить это поведение, снимите флажок для определенного типа журнала в разделе "Типы " в параметрах источника журнала.

На сервере

Также настроена ServiceOptions.DiagnosticClientFilter настройка для определения фильтра диагностических клиентов на основе контекста HTTP, поступающих от клиентов. Например, сделайте клиент с URL-адресом <HUB_URL>?diag=yesконцентратора, а затем настройте ServiceOptions.DiagnosticClientFilter фильтрацию диагностического клиента. Если он возвращается true, клиент будет помечен как диагностический клиент; в противном случае он сохраняется как обычный клиент. Его ServiceOptions.DiagnosticClientFilter можно задать в классе запуска следующим образом:

// sample: mark a client as diagnostic client when it has query string "?diag=yes" in hub URL
public IServiceProvider ConfigureServices(IServiceCollection services)
{
    services.AddMvc();
    services
        .AddSignalR()
        .AddAzureSignalR(o =>
        {
            o.ConnectionString = "<YOUR_ASRS_CONNECTION_STRING>";
            o.DiagnosticClientFilter = context => context.Request.Query["diag"] == "yes";
        });

    return services.BuildServiceProvider();
}
На стороне клиента

Пометьте клиент как диагностический клиент, настроив контекст HTTP. Например, клиент помечается как диагностический клиент, добавив строку diag=yesзапроса.

var connection = new HubConnectionBuilder()
    .WithUrl("<HUB_URL>?diag=yes")
    .Build();

Получить помощь

Мы рекомендуем сначала попытаться устранить неполадки самостоятельно. Большинство проблем вызваны неполадками сервера приложений или сети. Чтобы найти основную причину, воспользуйтесь инструкциями по устранению неполадок с помощью журнала ресурсов и руководством по решению распространенных проблем. Если проблему по-прежнему не удается устранить, попробуйте открыть проблему в GitHub или создать билет в портал Azure. Сделайте следующее:

  1. Диапазон времени (приблизительно 30 минут) возникновения проблемы
  2. Идентификатор ресурса Службы Azure SignalR
  3. Сведения о проблеме, как это возможно: например, appserver не отправляет сообщения, удаление подключения клиента и т. д.
  4. Журналы со стороны сервера или клиента и другие материалы, которые могут быть полезны для решения
  5. Необязательно: код воспроизведения

Примечание

Если вы открыли проблему в GitHub, оставьте конфиденциальные данные (например, идентификатор ресурса, журналы сервера или клиента) закрытыми, отправляйте участникам организации Майкрософт только в частном порядке.