Поделиться через

Устранение проблем с подключением и доставкой сообщений

  • Статья

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

Сначала вам нужно проверить на портале Azure, какой режим ServiceMode настроен для Службы Azure SignalR (также называемой АСРС).

ServiceMode

Во-вторых, необходимо зарегистрировать трассировки служб для устранения неполадок. Сведения о сборе трассировок см. в разделе Как регистрировать трассировки служб.

Наличие проблем или отзывов об устранении неполадок? Сообщите нам об этом.

Как регистрировать трассировки служб

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

Наличие проблем или отзывов об устранении неполадок? Сообщите нам об этом.

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

Если АСРС работает в режиме по умолчанию, существует три роли: Client, Serverи Service.

  • Client: роль Клиент устанавливается для клиентов, подключенных к ASRS. В этом руководстве постоянные подключения между клиентами и АСРС называются клиентскими подключениями.

  • Server: роль Сервер устанавливается для сервера, который обслуживает согласование клиентов и размещает логику SignalR Hub. В этом руководстве постоянные подключения между сервером и ASRS называются серверными подключениями.

  • Service: роль Служба — это краткое название для АСРС в этом руководстве.

Подробные сведения о всей архитектуре и рабочем процессе см. в разделе Внутренние компоненты Службы Azure SignalR.

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

  • Если проблема возникает постоянно или ее можно воспроизвести, самым простым способом является просмотр текущего трафика.

  • Если проблему трудно воспроизвести, могут помочь трассировки и журналы.

Просмотр трафика и локализация проблемы

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

Клиентские запросы

При постоянном подключении SignalR клиентский запрос сначала выполняет /negotiate с вашим размещенным сервером приложений, а затем перенаправляется в Службу Azure SignalR и устанавливает действительное постоянное подключение к Службе Azure SignalR. Подробные инструкции см. в разделе Внутренние компоненты Службы Azure SignalR.

Имея под рукой трассировку сети на стороне клиента, проверьте, какой запрос завершился ошибкой, с каким кодом состояния и каким ответом, и поищите решения в руководстве по устранению неполадок.

Запросы сервера

Сервер SignalR поддерживает серверное подключение между сервером и службой. При запуске сервер приложений запускает подключение WebSocket к Службе Azure SignalR. Весь клиентский трафик маршрутизируется через Службу Azure SignalR в эти серверные подключения, а затем направляется в Hub. При разрыве серверного подключения будут затронуты клиенты, которые маршрутизируются в это серверное подключение. Пакет SDK Azure SignalR содержит логику Always Retry для повторного подключения подключения к серверу с максимальной задержкой в 1 минуту, чтобы свести к минимуму последствия.

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

Просмотрите трассировку сети на стороне сервера, чтобы найти код состояния и сведения об ошибке, почему подключение к серверу удаляется или отклоняется службой. Найдите первопричину в руководстве по устранению неполадок.

Наличие проблем или отзывов об устранении неполадок? Сообщите нам об этом.

Добавление журналов

Журналы используются для диагностики проблем и мониторинга состояния выполнения.

Как включить журнал на стороне клиента

Процесс ведения журнала на стороне клиента точно такой же, как и при использовании локальной Службы SignalR.

Включение ведения журнала на стороне клиента для ASP.NET Core SignalR
Включение ведения журнала на стороне клиента для ASP.NET SignalR

Как включить журнал на стороне сервера

Включение ведения журнала на стороне сервера для ASP.NET Core SignalR

Ведение журнала на стороне сервера для ASP.NET Core SignalR интегрируется с ведением журнала на основе ILogger, предоставляемым на платформе ASP.NET Core. Включить ведение журналов на стороне сервера можно с помощью ConfigureLogging, как показано в примере ниже:

.ConfigureLogging((hostingContext, logging) =>
        {
            logging.AddConsole();
            logging.AddDebug();
        })

Категории средств ведения журнала для Azure SignalR всегда начинаются с Microsoft.Azure.SignalR. Чтобы включить ведение подробных журналов в Azure SignalR, настройте эти префиксы с уровнем Information в файле appsettings.json, как показано ниже:

{
    "Logging": {
        "LogLevel": {
            ...
            "Microsoft.Azure.SignalR": "Information",
            ...
        }
    }
}

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

Включение трассировок на стороне сервера для ASP.NET SignalR

При использовании версии >ПАКЕТА SDK = 1.0.0можно включить трассировки, добавив в него следующие web.configзначения: (Сведения)

<system.diagnostics>
    <sources>
      <source name="Microsoft.Azure.SignalR" switchName="SignalRSwitch">
        <listeners>
          <add name="ASRS" />
        </listeners>
      </source>
    </sources>
    <!-- Sets the trace verbosity level -->
    <switches>
      <add name="SignalRSwitch" value="Information" />
    </switches>
    <!-- Specifies the trace writer for output -->
    <sharedListeners>
      <add name="ASRS" type="System.Diagnostics.TextWriterTraceListener" initializeData="asrs.log.txt" />
    </sharedListeners>
    <trace autoflush="true" />
  </system.diagnostics>

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

Как включить журналы в Службе Azure SignalR

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

Наличие проблем или отзывов об устранении неполадок? Сообщите нам об этом.

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

Если АСРС работает в бессерверном режиме, только ASP.NET Core SignalR поддерживает режим Serverless. ASP.NET SignalR НЕ поддерживает этот режим.

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

Наличие проблем или отзывов об устранении неполадок? Сообщите нам об этом.

Устранение неполадок классического режима

Classic режим устарел и не рекомендуется использовать. В классическом режиме служба Azure SignalR использует подключенные подключения к серверу, чтобы определить, находится ли текущая служба в default режиме или serverless режиме. Классический режим может привести к проблемам с промежуточным подключением клиента, так как при внезапном падении всех подключенных подключений к серверу сервера, например из-за нестабильности сети, Azure SignalR считает, что он теперь переключился в serverless режим, и клиенты, подключенные в этот период, никогда не будут перенаправлены на размещенный сервер приложений. Включите журналы на стороне службы и проверьте, есть ли какие-либо клиенты, записанные так, как ServerlessModeEntered если бы вы размещали сервер приложений, однако некоторые клиенты никогда не обращаются к серверу приложений. Если вы видите любой из этих клиентов, прервайте подключения клиентов, а затем разрешите клиентам перезапустить.

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

Наличие проблем или отзывов об устранении неполадок? Сообщите нам об этом.

Работоспособность службы

Вы можете проверить работоспособность службы в API работоспособности.

  • Запрос: GET https://{instance_name}.service.signalr.net/api/v1/health

  • Код состояния отклика:

    • 200: служба работоспособна.
    • 503: служба неработоспособна. Вы можете:
      • подождать несколько минут, пока произойдет автовосстановление;
      • Проверьте, что IP-адрес совпадает с IP-адресом на портале.
      • или перезапустить экземпляр.
      • Если все перечисленные выше параметры не работают, обратитесь к нам, добавив новый запрос на поддержку в портал Azure.

Дополнительные сведения об аварийном восстановлении.

Наличие проблем или отзывов об устранении неполадок? Сообщите нам об этом.

Следующие шаги

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

Руководство по устранению неполадок