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

Использование журналов ресурсов для мониторинга Служба SignalR

  • Статья

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

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

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

  • Дополнительные сведения о мониторинге Служба Azure SignalR см. в разделе "Мониторинг Служба Azure SignalR".
  • Подробный список метрик и журналов, собранных для Служба Azure SignalR, см. в Служба Azure SignalR справочнике по данным мониторинга.

Необходимые компоненты

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

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

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

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

Создание параметров диагностики

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

Запрос журналов ресурсов

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

  1. Выберите журналы в целевой Log Analytics.

    Пункт меню Log Analytics

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

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

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

  1. Выберите журналы в целевой Log Analytics.

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

  3. Выберите тип ресурса для группировки примеров запросов в типе ресурса.

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

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

Примеры запросов для Служба Azure SignalR см. в разделе "Запросы" для таблицы SignalRServiceDiagnosticLogs.

Примечание.

Имена полей запросов для назначений хранилища немного отличаются от имен полей для Log Analytics. Дополнительные сведения о сопоставлении имен полей между таблицами Хранилища и Log Analytics см. в разделе "Сопоставление таблиц журнала ресурсов".

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

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

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

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

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

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

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

В следующей таблице перечислены причины прерывания.

Причина Description
Число подключений достигло предела. Число подключений достигло предельного значения для вашей текущей ценовой категории. Попробуйте вертикально увеличить масштаб модуля службы.
Удаленный сервер закрыл соединение 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 см . здесь , чтобы включить ведение журнала на сервере и клиенте.

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

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

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

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

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

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

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

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

Примечание.

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

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

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

Помечая клиент как диагностический клиент, Служба Azure 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 обрабатывает сообщение службы и доставляется целевому клиенту. После отправки сообщения клиенту в path 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("ReceiveGroupMessage", name, "I'm in group"); // send group message
    }
}

Например, кто-то может выполнять вызовы группы присоединения и отправлять сообщения группы в том же методе концентратора. Проблема в этом заключается AddToGroupAsync в методе async . Так как пока он не await AddToGroupAsync завершится, сообщение группы отправляется до 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, сохраните конфиденциальную информацию (например, идентификатор ресурса, журналы сервера или клиента). Только в частном порядке отправляются участникам в организации Майкрософт.