Diagnozowanie porzuconych powiadomień w usłudze Azure Notification Hubs

Typowe pytanie dotyczące usługi Azure Notification Hubs polega na rozwiązywaniu problemów, gdy powiadomienia z aplikacji nie są wyświetlane na urządzeniach klienckich. Klienci chcą wiedzieć, gdzie i dlaczego powiadomienia zostały porzucone, oraz jak rozwiązać ten problem. W tym artykule znaleziono, dlaczego powiadomienia mogą zostać porzucone lub nie odebrane przez urządzenia. Wyjaśniono również, jak określić główną przyczynę.

Ważne jest, aby najpierw zrozumieć, jak usługa Notification Hubs wypycha powiadomienia do urządzenia.

W typowym przepływie wysyłania powiadomień, komunikat jest wysyłany z zaplecza aplikacji do usługi Notification Hubs. Usługa Notification Hubs przetwarza wszystkie rejestracje. Uwzględnia skonfigurowane tagi i wyrażenia tagów w celu określenia obiektów docelowych. Docelowe są rejestracje, które muszą otrzymać powiadomienie push. Te rejestracje mogą obejmować dowolne z naszych obsługiwanych platform: Android, Baidu (urządzenia z systemem Android w Chinach), Fire OS (Amazon) iOS, Windows i Windows Phone.

Po ustaleniu celów usługa Notification Hubs wysyła powiadomienia do usługi powiadomień push dla platformy urządzeń. Przykłady obejmują usługę Apple Push Notification Service (APNs) dla systemów iOS i macOS oraz Firebase Cloud Messaging (FCM) dla urządzeń z systemem Android. Powiadomienia wysyłane w usłudze Notification Hubs są dzielone na wiele serii rejestracji. Uwierzytelnia się za pomocą odpowiedniej usługi powiadomień wypychanych na podstawie poświadczeń ustawionych w portalu Azure w obszarze Konfigurowanie Centrum Powiadomień. Następnie usługa powiadomień push przekazuje powiadomienia do odpowiednich urządzeń klienckich.

Ostatni etap dostarczania powiadomień jest między usługą powiadomień wypychanych platformy a urządzeniem. Dostarczanie powiadomień może zakończyć się niepowodzeniem na każdym z czterech etapów procesu powiadomień push (klient, zaplecze serwera aplikacji, usługa Notification Hubs i usługa powiadomień push platformy). Aby uzyskać więcej informacji na temat architektury usługi Notification Hubs, zobacz Notification Hubs overview (Omówienie usługi Notification Hubs).

Niepowodzenie dostarczania powiadomień może wystąpić w początkowej fazie testowania/etapie przygotowawczym. Porzucone powiadomienia na tym etapie mogą wskazywać na problem z konfiguracją. Jeśli w środowisku produkcyjnym wystąpi błąd dostarczania powiadomień, niektóre lub wszystkie powiadomienia mogą zostać porzucone. W tym przypadku wskazuje na głębszy problem z aplikacją lub wzorcem przesyłania komunikatów.

W następnej sekcji omówiono scenariusze, w których powiadomienia mogą zostać porzucone, począwszy od typowych do rzadkich.

Błędna konfiguracja usługi Notification Hubs

Aby wysyłać powiadomienia do odpowiedniej usługi powiadomień wypychanych, usługa Notification Hubs musi uwierzytelniać się w kontekście aplikacji. Musisz utworzyć konto dewelopera z usługą powiadomień platformy docelowej (Microsoft, Apple, Google itp.). Następnie należy zarejestrować aplikację w systemie operacyjnym, w którym uzyskujesz token lub klucz używany do pracy z docelowym systemem powiadomień.

Musisz dodać poświadczenia platformy do witryny Azure Portal. Jeśli żadne powiadomienia nie docierają do urządzenia, pierwszym krokiem jest upewnienie się, że prawidłowe poświadczenia są skonfigurowane w usłudze Notification Hubs. Poświadczenia muszą być zgodne z aplikacją utworzoną w ramach konta dewelopera specyficznego dla platformy.

Aby uzyskać instrukcje krok po kroku dotyczące ukończenia tego procesu, zobacz Wprowadzenie do usługi Azure Notification Hubs.

Poniżej przedstawiono niektóre typowe błędy konfiguracji do sprawdzenia:

Lokalizacja nazwy centrum powiadomień

Upewnij się, że nazwa centrum powiadomień (bez literówek) jest taka sama w każdej z tych lokalizacji:

• Gdzie rejestrujesz się u klienta
• Gdzie wysyłasz powiadomienia z panelu administracyjnego
• Gdzie skonfigurowano poświadczenia usługi powiadomień wypychanych

Upewnij się, że używasz prawidłowych ciągów konfiguracji sygnatury dostępu współdzielonego na kliencie i zapleczu aplikacji. Ogólnie rzecz biorąc, należy użyć DefaultListenSharedAccessSignature na kliencie i DefaultFullSharedAccessSignature w zapleczu aplikacji. Daje to uprawnienia do wysyłania powiadomień do usługi Notification Hubs.

Konfiguracja APN

Należy utrzymywać dwa różne koncentratory: jeden dla środowiska produkcyjnego, a drugi do testowania. Należy przesłać certyfikat używany w środowisku piaskownicy do oddzielnego centrum niż ten certyfikat lub centrum, którego będziesz używać w środowisku produkcyjnym. Nie próbuj przekazywać różnych typów certyfikatów do tego samego centrum. Spowoduje to błędy powiadomień.

Jeśli przypadkowo przekażesz różne typy certyfikatów do tego samego centrum, usuń centrum i zacznij od nowa przy użyciu nowego centrum. Jeśli z jakiegoś powodu nie możesz usunąć huba, musisz przynajmniej usunąć wszystkie istniejące zarejestrowane elementy z huba.

Konfiguracja usługi FCM

Uwaga

Aby uzyskać informacje na temat wycofywania i migracji usługi Firebase Cloud Messaging, zobacz Migracja usługi Google Firebase Cloud Messaging.

1. Upewnij się, że klucz serwera uzyskany z programu Firebase jest zgodny z kluczem serwera zarejestrowanym w witrynie Azure Portal.

   

2. Upewnij się, że skonfigurowano identyfikator projektu na kliencie. Wartość dla identyfikatora projektu można uzyskać w konsoli Firebase.

   

Problemy z aplikacją

Tagi i wyrażenia tagów

Jeśli używasz tagów lub wyrażeń tagów do segmentowania odbiorców, możliwe, że po wysłaniu powiadomienia nie zostanie znaleziena żadna grupa docelowa. Ten błąd wynika z określonych tagów lub wyrażeń tagowych w wywołaniu funkcji wysyłania.

Przejrzyj rejestracje, aby upewnić się, że tagi są zgodne podczas wysyłania powiadomienia. Następnie zweryfikuj otrzymanie powiadomienia tylko od tych klientów, którzy mają takie rejestracje.

Załóżmy na przykład, że wszystkie rejestracje w usłudze Notification Hubs używają tagu "Polityka". Jeśli następnie wyślesz powiadomienie z tagiem "Sport", powiadomienie nie zostanie wysłane do żadnego urządzenia. Złożony przypadek może obejmować wyrażenia tagów, w których zarejestrowano się przy użyciu tagu "Tag A" lub "Tag B", ale celowano w "Tag A i Tag B". Sekcja z poradami dotyczącymi samodzielnej diagnostyki w dalszej części artykułu pokazuje, jak przejrzeć rejestracje i ich tagi.

Problemy z szablonem

Jeśli używasz szablonów, upewnij się, że postępuj zgodnie z wytycznymi opisanymi w temacie Szablony

Nieprawidłowe rejestracje

Jeśli centrum powiadomień zostało poprawnie skonfigurowane, a tagi lub wyrażenia tagów zostały prawidłowo użyte, zostaną zidentyfikowane prawidłowe cele. Powiadomienia powinny być wysyłane do tych obiektów docelowych. Usługa Notification Hubs uruchamia następnie kilka równoległych partii przetwarzania. Każda partia wysyła komunikaty do zarejestrowanych odbiorców.

Uwaga

Ponieważ usługa Notification Hubs przetwarza partie równolegle, kolejność dostarczania powiadomień nie jest gwarantowana.

Usługa Notification Hubs jest zoptymalizowana pod kątem modelu dostarczania komunikatów "co najwyżej raz". Podejmujemy próbę deduplikacji, aby żadne powiadomienia nie były dostarczane więcej niż raz do urządzenia. Rejestracje są sprawdzane, aby upewnić się, że przed wysłaniem do usługi powiadomień wypychanych tylko jeden komunikat jest wysyłany dla każdego identyfikatora urządzenia.

Każda partia jest wysyłana do systemu powiadomień push, który z kolei akceptuje i weryfikuje rejestracje. Podczas tego procesu usługa powiadomień push może wykryć błąd z jedną lub więcej rejestracjami w partii. Następnie usługa powiadomień push zwraca błąd do Notification Hubs, a proces się zatrzymuje. Usługa powiadomień wypychanych całkowicie odrzuca tę partię. Jest to szczególnie istotne w przypadku usługi APNs, która korzysta z protokołu strumienia TCP.

W takim przypadku rejestracja błędów zostanie usunięta z bazy danych. Następnie ponowimy próbę dostarczenia powiadomień dla pozostałych urządzeń w tej partii.

Aby uzyskać więcej informacji o błędach dotyczących nieudanej próby dostarczenia związanej z rejestracją, możesz użyć interfejsów API REST usługi Notification Hubs, takich jak Per Message Telemetry: Get Notification message telemetry i PNS feedback. Przykładowy kod można znaleźć w przykładzie Send REST.

Problemy z usługą powiadomień push

Gdy usługa powiadomień wypychanych odbierze powiadomienie, dostarczy je do urządzenia. W tym momencie usługa Notification Hubs nie ma kontroli nad dostarczaniem powiadomienia do urządzenia.

Ponieważ usługi powiadomień platformy są niezawodne, powiadomienia zwykle docierają do urządzeń w ciągu kilku sekund. Jeśli usługa powiadomień push ogranicza wysyłanie, usługa Notification Hubs stosuje strategię wycofywania wykładniczego. Jeśli usługa powiadomień push pozostaje niedostępna przez 30 minut, istnieje polityka, która przewiduje wygaśnięcie i trwałe usunięcie komunikatów.

Jeśli usługa powiadomień push próbuje dostarczyć powiadomienie, ale urządzenie jest w trybie offline, powiadomienie jest przechowywane przez usługę powiadomień push. Jest on przechowywany tylko przez ograniczony czas. Powiadomienie jest dostarczane do urządzenia, gdy urządzenie stanie się dostępne.

Każda aplikacja przechowuje tylko jedno ostatnie powiadomienie. Jeśli podczas pracy urządzenia w trybie offline jest wysyłanych wiele powiadomień, każde nowe powiadomienie powoduje odrzucenie ostatniego powiadomienia. Utrzymywanie tylko najnowszego powiadomienia jest nazywane łączeniem w usłudze APNs i zwijaniem w usłudze FCM. (FcM używa zwijającego się klucza). Gdy urządzenie pozostaje w trybie offline przez długi czas, powiadomienia, które były przechowywane dla urządzenia, są odrzucane. Aby uzyskać więcej informacji, zobacz Omówienie APNs i Informacje o komunikatach FCM.

Usługa Notification Hubs umożliwia przekazywanie klucza łączenia za pośrednictwem nagłówka HTTP, korzystając z ogólnego interfejsu API SendNotification. Na przykład w przypadku zestawu .NET SDK należy użyć polecenia SendNotificationAsync. Interfejs API SendNotification przyjmuje również nagłówki HTTP, które są przekazywane bez zmian do odpowiedniej usługi push.

Porady dotyczące samodzielnej diagnostyki

Poniżej przedstawiono ścieżki do diagnozowania głównej przyczyny porzuconych powiadomień w usłudze Notification Hubs.

Weryfikowanie poświadczeń

Portal dla programistów usługi powiadomień push

Sprawdź poświadczenia w odpowiednim portalu deweloperskim usługi powiadomień push (APNs, FCM, Usługa powiadomień systemu Windows itd.). Aby uzyskać więcej informacji, zobacz Samouczek: wysyłanie powiadomień do aplikacji platforma uniwersalna systemu Windows przy użyciu usługi Azure Notification Hubs.

Azure Portal

Aby przejrzeć i dopasować poświadczenia do tych, które zostały uzyskane z portalu dla deweloperów usługi powiadomień wypychanych, przejdź do karty Zasady dostępu w witrynie Azure Portal.

Weryfikowanie rejestracji

Visual Studio

W programie Visual Studio możesz nawiązać połączenie z platformą Azure za pośrednictwem Eksploratora serwera, aby wyświetlić wiele usług platformy Azure i zarządzać nimi, w tym z usługą Notification Hubs. Ten skrót jest przydatny przede wszystkim w środowisku projektowym/testowym.

Możesz wyświetlać i zarządzać wszystkimi rejestracjami w swoim centrum. Rejestracje można podzielić na kategorie według platformy, rejestracji natywnej lub szablonu, tagu, identyfikatora usługi powiadomień wypychanych, identyfikatora rejestracji i daty wygaśnięcia. Możesz również edytować rejestrację na tej stronie. Jest to szczególnie przydatne w przypadku edytowania tagów.

Kliknij prawym przyciskiem myszy centrum powiadomień w Eksploratorze serwera, a następnie wybierz pozycję Diagnozuj.

Zostanie wyświetlona następująca strona:

Przejdź do Rejestracji urządzeń strony:

Możesz użyć strony Wysyłanie testu, aby wysłać testową wiadomość powiadomienia:

Uwaga

Użyj programu Visual Studio, aby edytować rejestracje tylko podczas programowania/testowania i z ograniczoną liczbą rejestracji. Jeśli musisz zbiorczo edytować rejestracje, rozważ użycie funkcji eksportowania i importowania rejestracji opisanej w temacie Jak eksportować i modyfikować rejestracje zbiorczo.

Eksplorator usługi Service Bus

Wielu klientów używa Eksploratora usługi Service Bus do wyświetlania centrów powiadomień i zarządzania nimi. Eksplorator usługi Service Bus to projekt typu open source.

Weryfikowanie powiadomień o wiadomościach

Azure Portal

Aby wysłać powiadomienie testowe do klientów bez konieczności tworzenia i uruchamiania zaplecza usługi, w obszarze POMOC TECHNICZNA i ROZWIĄZYWANIE PROBLEMÓW wybierz pozycję Wysyłanie testowe.

Visual Studio

Możesz również wysyłać powiadomienia testowe z programu Visual Studio.

Debugowanie nieudanych powiadomień i przeglądanie wyniku powiadomienia

Właściwość EnableTestSend

Po wysłaniu powiadomienia za pośrednictwem usługi Notification Hubs powiadomienie jest początkowo kolejkowane. Usługa Notification Hubs określa prawidłowe elementy docelowe, a następnie wysyła powiadomienie do usługi powiadomień push. Jeśli używasz interfejsu API REST lub dowolnego zestawu SDK klienta, zwrócenie wywołania wysyłania oznacza tylko, że komunikat jest kolejkowany w usłudze Notification Hubs. Nie zapewnia wglądu w to, co się stało, gdy usługa Notification Hubs ostatecznie wysłała powiadomienie do systemu powiadomień push.

Jeśli powiadomienie nie zostanie wyświetlone na urządzeniu klienckim, może wystąpić błąd, gdy usługa Notification Hubs próbowała dostarczyć ją do usługi powiadomień wypychanych. Na przykład rozmiar ładunku może przekroczyć maksymalny dozwolony przez usługę obsługi powiadomień lub poświadczenia skonfigurowane w centrum powiadomień mogą być nieprawidłowe.

Aby uzyskać wgląd w błędy powiadomień push, możesz użyć właściwości EnableTestSend. Ta właściwość jest automatycznie włączana podczas wysyłania komunikatów testowych z portalu lub klienta programu Visual Studio. Tej właściwości można użyć do wyświetlenia szczegółowych informacji o debugowaniu, a także za pośrednictwem interfejsów API. Obecnie można go używać w zestawie SDK platformy .NET. Zostanie ona ostatecznie dodana do wszystkich zestawów SDK klienta.

Aby użyć EnableTestSend właściwości z wywołaniem REST, dołącz parametr ciągu zapytania o nazwie test na końcu polecenia wysyłania. Na przykład:

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

Przykład zestawu SDK platformy .NET

Oto przykład użycia platformy .NET SDK do wysyłania natywnego powiadomienia wyskakującego typu toast.

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

Na końcu wykonywania result.State po prostu stwierdza wartość Enqueued. Wyniki nie zapewniają wglądu w to, co się stało z powiadomieniem push.

Następnie możesz użyć tego logicznego parametru EnableTestSend. Użyj właściwości EnableTestSend podczas inicjowania NotificationHubClient, aby uzyskać szczegółowy status błędów usługi powiadomień wypychanych występujących w momencie wysyłania powiadomienia. Wywołanie funkcji wysyłania zajmuje dodatkowy czas na powrót, ponieważ najpierw usługa Notification Hubs musi dostarczyć powiadomienie do usługi powiadomień 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);
    }

Przykładowe dane wyjściowe

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

Ten komunikat wskazuje, że poświadczenia skonfigurowane w usłudze Notification Hubs są nieprawidłowe lub że wystąpił problem z rejestracjami w centrum. Usuń tę rejestrację i pozwól klientowi ponownie utworzyć rejestrację przed wysłaniem wiadomości.

Uwaga

Użycie właściwości EnableTestSend jest mocno ograniczane. Użyj tej opcji tylko w środowisku projektowym/testowym i z ograniczonym zestawem rejestracji. Powiadomienia debugowania są wysyłane tylko do 10 urządzeń. Istnieje również limit na wysyłanie danych debugowania, wynoszący do 10 na minutę. Powiadomienia debugowania są również wykluczone z umowy SLA usługi Azure Notification Hubs.

Przeglądanie danych telemetrycznych

Azure Portal

W portalu możesz szybko zapoznać się ze wszystkimi działaniami w centrum powiadomień.

1. Na karcie Przegląd można wyświetlić zagregowany widok rejestracji, powiadomień i błędów według platformy.

   

2. Na karcie Dziennik aktywności możesz dodać inne metryki specyficzne dla platformy, aby uzyskać bardziej szczegółowy wygląd. Możesz przyjrzeć się konkretnie błędom zwracanym, gdy usługa Notification Hubs próbuje wysłać powiadomienie do usługi powiadomień wypychanych.

   

3. Na karcie Przegląd rozpocznij od przejrzenia komunikatów przychodzących, operacji rejestracji i pomyślnych powiadomień. Następnie przejdź do zakładki platformy, aby przejrzeć błędy charakterystyczne dla tej usługi powiadomień push.

4. Jeśli ustawienia uwierzytelniania centrum powiadomień są nieprawidłowe, zostanie wyświetlony komunikat Błąd uwierzytelniania pnS. Warto sprawdzić poświadczenia usługi powiadomień push.

Dostęp programowy

Aby uzyskać więcej informacji na temat programowego dostępu do metryk usługi Azure Notification Hub, zobacz Dostęp programowy.

Uwaga

Kilka funkcji związanych z telemetrią, takich jak eksportowanie i importowanie rejestracji oraz dostęp do danych telemetrycznych za pośrednictwem interfejsów API, są dostępne tylko w warstwie usługi Standardowa. Jeśli spróbujesz użyć tych funkcji z warstwy usługi Bezpłatna lub Podstawowa, otrzymasz komunikat o wyjątku, jeśli używasz zestawu SDK. Jeśli używasz funkcji bezpośrednio z interfejsów API REST, wystąpi błąd HTTP 403 (Zabronione).

Aby korzystać z funkcji związanych z telemetrią, najpierw upewnij się, że w witrynie Azure Portal używasz warstwy usługi Standardowa.