Диагностика удаленных уведомлений в центрах уведомлений Azure

Распространенный вопрос о центрах уведомлений Azure — устранение неполадок, когда уведомления из приложения не отображаются на клиентских устройствах. Клиенты хотят понять, где и почему уведомления были удалены, а также как устранить проблему. В этой статье мы рассмотрим, почему уведомления удаляются и не доходят до устройств. В ней также объясняется, как определить основную причину.

Для начала очень важно понять, как Центры уведомлений отправляют уведомления на устройство.

В типичном потоке отправки уведомлений сообщение отправляется из серверной части приложения в Центры уведомлений. Центры уведомлений обрабатывают все регистрации. Учитываются настроенные теги и выражения тегов для определения целевых объектов. Целевые объекты — это регистрации, которые должны получать push-уведомление. Эти регистрации могут охватывать любую из поддерживаемых платформ: Android, Baidu (устройства Android в Китае), Fire OS (Amazon) iOS, Windows и Windows Phone.

Определив цели, Центры уведомлений отправляют сообщения в службу push-уведомлений для платформы устройства. В качестве примеров: Cлужба push-уведомлений Apple (APNs) для iOS и macOS, а также Firebase Cloud Messaging (FCM) для устройств на Android. Центры уведомлений отправляют сообщения, разделенные по нескольким пакетам регистраций. Они выполняют проверку подлинности с помощью соответствующей службы push-уведомлений на основе учетных данных, установленных на портале Azure в разделе Настройка центра уведомлений. Затем служба push-уведомлений пересылает уведомления на соответствующие клиентские устройства.

Последняя часть доставки уведомлений — между службой push-уведомлений платформы и устройством. Доставка уведомлений может завершиться сбоем на любом из четырех этапов процесса push-уведомления (клиент, серверная часть приложения, Центры уведомлений и Служба push-уведомлений платформы). Дополнительные сведения об архитектуре Центров уведомлений см. в этой статье.

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

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

Неправильная настройка Центров уведомлений

Чтобы отправлять уведомления в соответствующую службу push-уведомлений, Центры уведомлений должны пройти проверку подлинности в контексте вашего приложения. Необходимо создать учетную запись разработчика с помощью службы уведомлений целевой платформы (Microsoft, Apple, Google и т. д.). Затем необходимо зарегистрировать приложение в операционной системе, где вы получаете маркер или ключ, используемые для работы с целевым PNS.

Учетные данные платформы необходимо добавить на портал Azure. Если ни одно из уведомлений не достигло устройства, сначала необходимо убедиться в том, что в Центрах уведомлений настроены правильные учетные данные. Учетные данные должны соответствовать приложению, созданному в учетной записи разработчика для конкретной платформы.

Пошаговые инструкции для выполнения этого процесса см. в статье Начало работы с Центрами уведомлений для приложений универсальной платформы Windows.

Ниже приведены некоторые распространенные сценарии неправильной настройки, которые следует проверить.

Расположение имени Центра уведомлений

Убедитесь, что имя Центра уведомлений (без опечаток) одинаковое во всех следующих расположениях:

• Где выполняется регистрация из клиента.
• Куда отправляются уведомления из серверной части.
• Где вы настроили учетные данные службы push-уведомлений

Убедитесь, что в клиенте и серверной части приложения используются правильные строки конфигурации общего доступа. Как правило, необходимо использовать DefaultListenSharedAccessSignature на клиенте и DefaultFullSharedAccessSignature в серверной части приложения. Это предоставляет разрешения на отправку уведомлений в Центры уведомлений.

Конфигурация точки доступа

Необходимо поддерживать два разных Центра: один для рабочей среды, а другой — для тестирования. Сертификат, используемый в изолированной среде, необходимо передавать в отдельный Центр, отличный от сертификата или Центра, который будет использоваться в рабочей среде. Не отправляйте разные типы сертификатов в один и тот же центр. Это приведет к сбоям уведомления.

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

Конфигурация FCM

1. Убедитесь, что ключ сервера, полученный из Firebase, совпадает с ключом сервера, зарегистрированным на портале Azure.

   

2. Убедитесь, что на клиенте настроен идентификатор проекта. Значение для идентификатора проекта можно получить на панели мониторинга Firebase.

   

Проблемы с приложением

Теги и выражения тегов

Если вы используете теги или выражения тегов для сегментирования аудитории, возможно, при отправке уведомления целевой объект не будет найден. Эта ошибка основана на указанных тегах или выражениях тегов в вызове Send.

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

Например, предположим, что все регистрации в центрах уведомлений используют тег «Политики». Если отправить уведомление с тегом «Спорт», уведомление не будет отправлено на устройство. Сложный случай может включать выражения тегов, зарегистрированные с помощью тега A или Tag B, но вы нацелились на тег A &&& Tag B. В разделе "Советы по самостоятельной диагностике" далее в статье показано, как просмотреть свои регистрации и их теги.

Проблемы с шаблонами

Если используются шаблоны, убедитесь, что вы следуете рекомендациям, приведенным в статье Шаблоны.

Недопустимые регистрации

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

Центры уведомлений оптимизированы для модели доставки сообщений "не чаще одного раза". Мы пытаемся выполнить дедупликацию так, чтобы уведомления доставлялись на устройство по одному разу. Регистрации проверяются, чтобы убедиться, что перед отсылкой в службу push-уведомлений было отправлено только одно сообщение для каждого идентификатора устройства.

Каждый пакет отправляется в службу push-уведомлений, которая, в свою очередь, принимает и проверяет регистрации. В ходе этого процесса Служба push-уведомлений может обнаружить ошибку с одной или несколькими регистрациями в пакете. Тогда служба push-уведомлений возвращает ошибку в Центр уведомлений, и процесс останавливается. Служба push-уведомлений полностью удаляет такой пакет. Это особенно справедливо для Службы push-уведомлений Apple, в которой используется протокол TCP-потока.

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

Чтобы получить дополнительные сведения об ошибке неудачной попытки доставки для регистрации, можно использовать API-интерфейсы REST Центров уведомлений Для передачи телеметрии сообщений уведомлений и Реакция PNS. Пример кода приведен в репозитории примеров для отправки с помощью REST.

Проблемы службы push-уведомлений

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

Так как службы Notification Services являются надежными, уведомления обычно достигают устройства через несколько секунд. Если служба push-уведомлений регулирует количество запросов, Центры уведомлений применяют стратегию экспоненциального отката. Если служба push-уведомлений остается недоступной в течение 30 минут, существует политика, позволяющая сроку сообщения истечь и удалить его окончательно.

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

Каждое приложение хранит только одно последнее уведомление. При отправке нескольких уведомлений, когда устройство находится вне сетевого доступа, каждое новое уведомление приводит к отмене поступившего до него. Хранение только нового уведомления называется объединением в Службе push-уведомлений Apple и свертыванием в FCM. (FCM использует ключ свертывания). Когда устройство остается вне сетевого доступа в течение длительного времени, уведомления, сохраненные для устройства, сбрасываются. Дополнительные сведения см. в разделе Общие сведения о Cлужбе push-уведомлений Apple и О сообщениях FCM.

С помощью Центров уведомлений можно передать ключ объединения через заголовок HTTP, используя универсальный API SendNotification. Например, для пакета SDK для .NET можете использовать SendNotificationAsync. API SendNotification также принимает заголовки HTTP, которые передаются в неизмененном виде в соответствующую службу push-уведомлений.

Советы по самостоятельной диагностике

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

Проверка учетных данных

Портал разработчика службы push-уведомлений

Проверьте учетные данные на соответствующем портале разработчика службы push-уведомлений (APNs, FCM, служба уведомлений Windows и т. д.). Дополнительные сведения см. в статье Учебник: Отправка уведомлений в приложения универсальной платформы Windows с помощью Центров уведомлений Azure.

Портал Azure

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

Проверка регистраций

Visual Studio

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

Вы можете просматривать все регистрации в Центре и управлять ими. Регистрация может быть отнесена к категории по платформам, встроенной регистрации или шаблону, тегу, идентификатору службы push-уведомлений, идентификатору регистрации и дате окончания срока действия. На этой странице можно также изменить регистрацию. Это особенно удобно для редактирования тегов.

Щелкните правой кнопкой мыши на Центре уведомлений в меню Обозреватель сервера и выберите пункт Диагностика.

Появится следующая страница:

Перейдите на страницу Регистрация устройств.

Можно использовать страницу Тестовая Отправка для отправки тестового сообщения уведомления.

Обозреватель служебной шины

Многие пользователи применяют Обозреватель служебной шины (Service Bus Explorer) для просмотра Центров уведомлений и управления ими, который представляет собой проект с открытым кодом.

Проверка уведомлений о сообщениях

Портал Azure

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

Visual Studio

Тестовые уведомления также можно отправлять с помощью Visual Studio.

Уведомления о сбоях отладки и просмотр результатов уведомлений

Свойство EnableTestSend

При отправке уведомления через Центры уведомлений изначально уведомление помещается в очередь. Центры уведомлений определяют правильные цели, а затем отправляют уведомление в службу push-уведомлений. Если вы используете REST API или любое из клиентских пакетов SDK, возврат вызова Send означает только то, что сообщение помещается в очередь Центров уведомлений. Это не дает понимания, что происходит, когда Центры уведомлений в конечном итоге отправляют уведомление в службу push-уведомлений.

Если уведомление не поступает на клиентское устройство, то, возможно, произошла ошибка при попытке Центров уведомлений доставить уведомление в службу push-уведомлений. Например, размер полезных данных может превышать максимально допустимый размер таких данных в службе push-уведомлений или настроенные в Центрах уведомлений учетные данные могут быть недоступными.

Информацию об ошибках службы push-уведомлений можно получить с помощью свойства EnableTestSend. Оно автоматически включается при отправке тестового сообщения с портала или клиентского приложения Visual Studio Это свойство можно использовать для просмотра подробных сведений при отладке, а также через API. Сейчас его можно использовать в пакете SDK для .NET. В конечном итоге он будет добавлен во все клиентские пакеты SDK.

Чтобы использовать свойство EnableTestSend с вызовом REST, добавьте параметр строки запроса с именем test в конце вызова отправки. Например:

https://mynamespace.servicebus.windows.net/mynotificationhub/messages?api-version=2013-10&test

Пример пакета SDK для .NET

Ниже приведен пример отправки собственного всплывающего уведомления при использовании пакета SDK для .NET:

NotificationHubClient hub = NotificationHubClient.CreateClientFromConnectionString(connString, hubName);
var result = await hub.SendWindowsNativeNotificationAsync(toast);
Console.WriteLine(result.State);

В конце выполнения result.State просто заявляет Enqueued. Результаты не дают возможность понять, что произошло с push-уведомлением.

Далее вы можете использовать логическое свойство EnableTestSend. С помощью свойства EnableTestSend во время инициализации NotificationHubClient можно получить подробные сведения об ошибках службы push-уведомлений, произошедших при отправке уведомления. Для возврата вызова Send требуется дополнительное время, так как сначала Центры уведомлений доставляют уведомления в службу push-уведомлений.

    bool enableTestSend = true;
    NotificationHubClient hub = NotificationHubClient.CreateClientFromConnectionString(connString, hubName, enableTestSend);

    var outcome = await hub.SendWindowsNativeNotificationAsync(toast);
    Console.WriteLine(outcome.State);

    foreach (RegistrationResult result in outcome.Results)
    {
        Console.WriteLine(result.ApplicationPlatform + "\n" + result.RegistrationId + "\n" + result.Outcome);
    }

Пример полученных результатов

DetailedStateAvailable
windows
7619785862101227384-7840974832647865618-3
The Token obtained from the Token Provider is wrong

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

Просмотр телеметрии

Портал Azure

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

1. На вкладке Обзор можно просмотреть объединенное представление регистраций, уведомлений и ошибок каждой платформы.

   

2. На вкладке "Журнал действий" можно добавить другие метрики для конкретной платформы для более глубокого просмотра. Вы можете просмотреть сообщения об ошибках, возвращаемых при попытках Центров уведомлений отправить уведомление в службу push-уведомлений.

   

3. На вкладке "Обзор" начните с просмотра входящих сообщений, операций регистрации и успешных уведомлений. Затем перейдите на вкладку для каждой платформы, чтобы просмотреть ошибки, относящиеся к этой службе push-уведомлений.

4. Если параметры проверки подлинности для Центра уведомлений неверные, будет получена ошибка выполнения проверки подлинности PNS. Это хороший показатель для проверки учетных данных службы push-уведомлений.

Программный доступ

Дополнительные сведения о программном доступе см. в разделе Программный доступ.