Udostępnij za pośrednictwem

Omówienie dzienników wywołań usług Azure Communication Services

  • Artykuł

Usługi Azure Communication Services udostępniają funkcje rejestrowania, których można użyć do monitorowania i debugowania rozwiązania usług Komunikacyjnych. Skonfiguruj te możliwości za pośrednictwem witryny Azure Portal.

Zawartość tego artykułu dotyczy dzienników włączonych za pośrednictwem usługi Azure Monitor (zobacz też często zadawane pytania). Aby włączyć te dzienniki dla usług komunikacyjnych, zobacz Włączanie rejestrowania w ustawieniach diagnostycznych.

Ważne

Jeśli chcesz je analizować, musisz zebrać dzienniki. Aby dowiedzieć się więcej, zobacz: Jak mogę przechowywać dzienniki?

Platforma Azure nie przechowuje danych dziennika połączeń, chyba że włączysz te określone ustawienia diagnostyczne. Dane połączeń nie są dostępne z mocą wsteczną. Dane są gromadzone po utworzeniu ustawień diagnostycznych.

Jak używać dzienników wywołań

Zalecamy zebranie wszystkich dostępnych dzienników wywołań w zasobie analizy dzienników, aby można było monitorować użycie połączeń i poprawić jakość połączeń oraz otrzymywać nowe dzienniki z usług Azure Communication Services podczas ich wydawania.

Istnieją dwa główne narzędzia, których można użyć do monitorowania połączeń i poprawy jakości połączeń.

Zalecamy korzystanie z pulpitów nawigacyjnych pulpitów nawigacyjnych szczegółowych informacji o głosach i wideo, aby rozpocząć badanie jakości i korzystać z diagnostyki połączeń zgodnie z potrzebami, aby eksplorować poszczególne połączenia, gdy potrzebujesz szczegółowych informacji.

Dostępne dzienniki

Usługi Azure Communication Services tworzą osiem dzienników wywołań:

Wywołaj dzienniki aktualizacji podsumowania:

Te dane dziennika docierają do usługi Azure Monitor szybciej niż dzienniki podsumowania wywołań i zalecamy użycie tych dzienników zamiast schematu dziennika podsumowania wywołań. Ten dziennik zawiera podstawowe informacje o wywołaniu, w tym wszystkie odpowiednie identyfikatory, sygnatury czasowe, punkty końcowe i informacje o zestawie SDK.

Aby dowiedzieć się więcej, zobacz: Wywoływanie schematu dziennika aktualizacji podsumowania

Wywołaj dzienniki podsumowania:

Ten dziennik jest podzbiorem schematu dziennika aktualizacji podsumowania wywołań. Zawiera on podstawowe informacje o wywołaniu, w tym wszystkie odpowiednie identyfikatory, sygnatury czasowe, punkty końcowe i informacje o zestawie SDK. Aby uzyskać szybsze opóźnienie dziennika, użyj zamiast tego dzienników aktualizacji podsumowania wywołań.

Aby dowiedzieć się więcej, zobacz: Wywoływanie schematu dziennika podsumowania

Wywołaj dzienniki aktualizacji diagnostyki:

Te dane dzienników docierają do usługi Azure Monitor szybciej niż dzienniki diagnostyki wywołań i zalecamy użycie tych dzienników zamiast schematu dziennika diagnostyki wywołań. Ten dziennik zawiera informacje o strumieniu multimediów wywołań uczestnika wraz z zestawem metryk wskazujących jakość pomiarów środowiska.

Aby dowiedzieć się więcej, zobacz: Wywoływanie schematu dziennika aktualizacji diagnostyki

Wywołaj dzienniki diagnostyczne:

Ten dziennik jest podzbiorem schematu dziennika aktualizacji diagnostyki wywołań. Zawiera on informacje o strumieniu wraz z zestawem metryk wskazujących jakość pomiarów środowiska. Aby uzyskać szybsze opóźnienie dziennika, użyj zamiast tego dzienników aktualizacji podsumowania wywołań.

Aby dowiedzieć się więcej, zobacz: Wywoływanie schematu dziennika diagnostyki

Wywołaj dzienniki operacji klienta:

Zawierają szczegółowe zdarzenia klienta wywołania. Te zdarzenia dziennika są generowane dla każdego EndpointId wywołania, a liczba wygenerowanych dzienników zdarzeń zależy od operacji wykonywanych przez uczestnika podczas wywołania.

Aby dowiedzieć się więcej, zobacz: Wywoływanie schematu dziennika operacji klienta

Wywołaj dzienniki statystyk multimediów klienta:

Zawierają szczegółowe wartości strumienia multimediów. Te dzienniki są generowane dla każdego strumienia multimediów w wywołaniu. Dla każdego EndpointId wywołania (w tym serwera) usługi Azure Communication Services tworzą odrębny dziennik dla każdego strumienia multimediów (na przykład audio lub wideo) między punktami końcowymi. Ilość danych wygenerowanych w każdym dzienniku zależy od czasu wywołania i liczby multimediów w wywołaniu.

W wywołaniu P2P każdy dziennik zawiera dane powiązane z poszczególnymi strumieniami wychodzącymi skojarzonymi z poszczególnymi punktami końcowymi. W wywołaniu grupy każdy strumień skojarzony z endpointType = "Server" tworzy dziennik zawierający dane dla strumieni przychodzących. Wszystkie inne strumienie tworzą dzienniki zawierające dane dla strumieni wychodzących dla wszystkich punktów końcowych nieserwerowych. W wywołaniach grupy użyj participantId wartości jako klucza, aby dołączyć powiązane dzienniki przychodzące i wychodzące do odrębnego połączenia uczestnika.

Aby dowiedzieć się więcej, zobacz: Wywoływanie schematu dziennika dziennika szeregów czasowych statystyk klienta

Koniec dzienników ankiety połączeń:

Te dzienniki są wypełniane, gdy klient wywołujący sieć Web przesyła ankietę na końcu wywołania. Możesz użyć tych dzienników, aby poznać subiektywne postrzeganie jakości połączeń od użytkowników.

Aby dowiedzieć się więcej, zobacz: Omówienie ankiety dotyczącej zakończenia połączeń

Wywoływanie dzienników metryk:

Te dzienniki zawierają zagregowane metryki wywołujące w codziennych pojemnikach na podstawie atrybutów, takich jak wersja zestawu SDK, nazwa systemu operacyjnego i kod podrzędny błędu. Te dzienniki są używane na pulpicie nawigacyjnym szczegółowych informacji głosowych i wideo w celu wizualizacji długoterminowych grafów niezawodności, jakości i wydajności na podstawie liczby pomyślnych i nieudanych wywołań interfejsu API zestawu SDK dla różnych operacji.

Aby dowiedzieć się więcej, zobacz: Wywoływanie schematu dziennika metryk

Pojęcia dotyczące danych

Poniższe ogólne opisy pojęć dotyczących danych są specyficzne dla połączeń głosowych i wideo. Te pojęcia są ważne do przejrzenia, aby zrozumieć znaczenie danych przechwyconych w dziennikach.

Jednostki i identyfikatory

Zapoznaj się z następującymi terminami:

  • Wywołanie: Zgodnie z reprezentacją w danych wywołanie jest abstrakcją przedstawioną przez correlationIdelement . Wartości dla elementu correlationId są unikatowe dla każdego wywołania i są powiązane czasowo na callStartTime podstawie wartości i callDuration.

  • Uczestnik: reprezentuje połączenie między punktem końcowym a serwerem. Uczestnik (participantId) jest obecny tylko wtedy, gdy połączenie jest wywołaniem grupy.

  • Punkt końcowy: najbardziej unikatowa jednostka reprezentowana przez endpointIdelement . Każde wywołanie jest zdarzeniem zawierającym dane z co najmniej dwóch punktów końcowych. Punkty końcowe reprezentują uczestników wywołania.

    EndpointType informuje, czy punkt końcowy jest użytkownikiem ludzkim (PSTN lub VoIP), botem lub serwerem zarządzającym wieloma uczestnikami w ramach wywołania. endpointType Gdy wartość to "Server", punkt końcowy nie ma przypisanego unikatowego identyfikatora. Możesz przeanalizować endpointType i liczbę endpointId wartości, aby określić, ilu użytkowników i innych nieludzkich uczestników (botów i serwerów) dołączy do wywołania.

    Natywne zestawy SDK dla systemów Android i iOS ponownie wykorzystają tę samą endpointId wartość dla użytkownika w wielu wywołaniach, aby uzyskać informacje o środowiskach między sesjami. Ten proces różni się od internetowych punktów końcowych, które zawsze generują nową wartość dla każdego nowego endpointId wywołania.

  • Strumień: najbardziej szczegółowa jednostka. Istnieje jeden strumień dla każdego kierunku (przychodzącego lub wychodzącego) i mediaType wartości (na przykład Audio lub Video).

Wywołania P2P a wywołania grup

Uwaga

W tym artykule wywołania P2P i grupy są domyślnie w tej samej dzierżawie. Wszystkie scenariusze wywołań, które są między dzierżawami, są odpowiednio określane w całym artykule.

Istnieją dwa typy wywołań reprezentowane przez callType:

  • Wywołanie komunikacji równorzędnej z elementem równorzędnym (P2P): połączenie między tylko dwoma punktami końcowymi bez punktu końcowego serwera. Wywołania P2P są inicjowane jako wywołanie między tymi punktami końcowymi i nie są tworzone jako zdarzenie wywołania grupy przed połączeniem.

    Diagram przedstawiający wywołanie P2P między dwoma punktami końcowymi.

  • Wywołanie grupy: każde wywołanie, które ma więcej niż dwa połączone punkty końcowe. Wywołania grup obejmują punkt końcowy serwera i połączenie między poszczególnymi punktami końcowymi i serwerem. Wywołania P2P, które dodają kolejny punkt końcowy podczas wywołania, przestaną być połączeniem P2P i stają się wywołaniem grupy. Oś czasu każdego punktu końcowego przyłączonego do wywołania można określić przy użyciu participantStartTime metryk i participantDuration .

    Diagram przedstawiający wywołanie grupy w wielu punktach końcowych.

Przykłady różnych typów wywołań

Uwaga

W tym artykule wywołania P2P i grupy są domyślnie w tej samej dzierżawie. Wszystkie scenariusze wywołań, które są między dzierżawami, są odpowiednio określane w całym artykule.

Przykład: wywołanie P2P

Na poniższym diagramie przedstawiono dwa punkty końcowe połączone bezpośrednio w wywołaniu P2P. W tym przykładzie usługi Communication Services tworzą dwa dzienniki podsumowania wywołań (po jednym dla każdej participantID wartości) i cztery dzienniki diagnostyki wywołań (po jednym dla każdego strumienia multimediów).

W przypadku uczestników połączeń z klientami usług Azure Communication Services istnieje również seria dzienników operacji klienta wywołań i dzienniki szeregów czasowych statystyk multimediów klienta. Dokładna liczba tych dzienników zależy od rodzaju operacji zestawu SDK i czasu trwania wywołań.

Diagram przedstawiający wywołanie P2P w tej samej dzierżawie.

Przykład: Wywołanie grupy

Na poniższym diagramie przedstawiono przykład wywołania grupy z trzema participantId wartościami (co oznacza trzech uczestników) i punktem końcowym serwera. Wiele wartości dla endpointId elementu może być potencjalnie wyświetlanych w wielu uczestnikach — na przykład podczas ponownego dołączania połączenia z tego samego urządzenia. Usługi komunikacyjne tworzą jeden dziennik podsumowania wywołań dla każdej participantId wartości. Tworzy cztery dzienniki diagnostyki wywołań: jeden dla każdego strumienia multimediów na participantId.

W przypadku uczestników wywołań klienta usług Azure Communication Services dzienniki operacji klienta wywołania są takie same jak wywołania P2P. Dla każdego uczestnika używającego zestawu SDK wywoływania istnieje seria dzienników operacji klienta wywołań.

W przypadku uczestników połączeń z klientami usług Azure Communication Services dzienniki operacji klienta wywołania i dzienniki szeregów czasowych statystyk multimediów klienta są takie same jak wywołania P2P. Dla każdego uczestnika używającego zestawu SDK wywoływania istnieje seria dzienników operacji klienta wywołań i dzienniki szeregów czasowych statystyk multimediów klienta.

Diagram przedstawiający wywołanie grupy w ramach tej samej dzierżawy.

Przykład: wywołanie P2P między dzierżawami

Na poniższym diagramie przedstawiono dwóch uczestników w wielu dzierżawach połączonych bezpośrednio w wywołaniu P2P. W tym przykładzie usługi Communication Services tworzą jeden dziennik podsumowania wywołań (jeden dla każdego uczestnika) z zredagowaną wersją systemu operacyjnego i zestawu SDK. Usługi komunikacyjne tworzą również cztery dzienniki diagnostyki wywołań (po jednym dla każdego strumienia multimediów). Każdy dziennik zawiera dane odnoszące się do strumienia wychodzącego .participantID

Diagram przedstawiający wywołanie P2P między dzierżawami.

Przykład: wywołanie grupy między dzierżawami

Na poniższym diagramie przedstawiono przykład wywołania grupy z trzema participantId wartościami w wielu dzierżawach. Usługi komunikacyjne tworzą jeden dziennik podsumowania wywołań dla każdego uczestnika z zredagowaną wersją systemu operacyjnego i zestawu SDK. Usługi komunikacyjne tworzą również cztery dzienniki diagnostyki wywołań, które odnoszą się do każdej participantId wartości (po jednym dla każdego strumienia multimediów).

Diagram przedstawiający wywołanie grupy między dzierżawami.

Uwaga

Ta wersja obsługuje tylko dzienniki diagnostyczne ruchu wychodzącego. Wersje systemu operacyjnego i zestawu SDK skojarzone z botem i uczestnikiem można zredagować, ponieważ usługi Communication Services traktują tożsamości uczestników i botów w taki sam sposób.

Często zadawane pytania

Jak mogę przechowywać dzienniki?

W poniższej sekcji opisano to wymaganie.

Dzienniki usług Azure Communication Services nie są domyślnie przechowywane na koncie platformy Azure, więc musisz zacząć je przechowywać w celu umożliwienia pracy narzędzi takich jak pulpit nawigacyjny analizy głosowej i wideo oraz wywoływanie diagnostyki . Aby zebrać te dzienniki wywołań, należy włączyć ustawienie diagnostyczne kierujące dane wywołania do obszaru roboczego usługi Log Analytics.

Dane nie są przechowywane wstecznie, więc można rozpocząć przechwytywanie dzienników wywołań dopiero po skonfigurowaniu ustawienia diagnostycznego.

Postępuj zgodnie z instrukcjami, aby dodać ustawienia diagnostyczne zasobu w obszarze Włączanie dzienników za pomocą ustawień diagnostycznych w usłudze Azure Monitor. Zalecamy, aby początkowo zbierać wszystkie dzienniki. Po zapoznaniu się z możliwościami w usłudze Azure Monitor określ, które dzienniki chcesz zachować i jak długo. Po dodaniu ustawienia diagnostycznego zostanie wyświetlony monit o wybranie dzienników. Aby zebrać wszystkie dzienniki, wybierz pozycję wszystkieLogi.

Ilość danych, przechowywanie i użycie w usłudze Log Analytics w usłudze Azure Monitor są rozliczane za pośrednictwem istniejących mierników danych platformy Azure. Zalecamy monitorowanie zasad użycia i przechowywania danych w celu uwzględnienia kosztów zgodnie z potrzebami. Aby uzyskać więcej informacji, zobacz Kontrolowanie kosztów.

Jeśli masz wiele identyfikatorów zasobów usług Azure Communications Services, musisz włączyć te ustawienia dla każdego identyfikatora zasobu.

Następne kroki