Delen via

Overzicht van aanroeplogboeken van Azure Communication Services

  • Artikel

Azure Communication Services biedt logboekregistratiemogelijkheden die u kunt gebruiken om uw Communication Services-oplossing te bewaken en fouten op te sporen. Configureer deze mogelijkheden via Azure Portal.

De inhoud in dit artikel verwijst naar logboeken die zijn ingeschakeld via Azure Monitor (zie ook veelgestelde vragen). Zie Logboekregistratie in diagnostische instellingen inschakelen om deze logboeken in te schakelen voor Communication Services.

Belangrijk

U moet logboeken verzamelen als u ze wilt analyseren. Zie voor meer informatie: Hoe kan ik logboeken opslaan?

Uw oproeplogboekgegevens worden niet opgeslagen in Azure, tenzij u deze specifieke diagnostische instellingen inschakelt. Uw oproepgegevens zijn niet met terugwerkende kracht beschikbaar. U verzamelt gegevens zodra u de diagnostische instellingen hebt gemaakt.

Oproeplogboeken gebruiken

U wordt aangeraden alle beschikbare oproeplogboeken in een Log Analytics-resource te verzamelen, zodat u het gebruik van oproepen kunt bewaken en de gesprekskwaliteit kunt verbeteren en nieuwe logboeken van Azure Communication Services kunt ontvangen wanneer we ze vrijgeven.

Er zijn twee hoofdhulpprogramma's die u kunt gebruiken om uw gesprekken te bewaken en de gesprekskwaliteit te verbeteren.

We raden u aan om dashboards voor spraak- en video-inzichten te gebruiken om kwaliteitsonderzoeken te starten en zo nodig gespreksdiagnose te gebruiken om afzonderlijke gesprekken te verkennen wanneer u gedetailleerde details nodig hebt.

Beschikbare logboeken

Azure Communication Services maakt acht oproeplogboeken:

Logboeken voor het bijwerken van oproepoverzichten:

Deze logboekgegevens komen sneller binnen in Azure Monitor dan in de logboeken van de oproepsamenvatting. We raden u aan deze logboeken te gebruiken in plaats van het schema van het aanroepsamenvattingslogboek. Dit logboek bevat basisinformatie over de aanroep, inclusief alle relevante id's, tijdstempels, eindpunten en SDK-informatie.

Zie voor meer informatie: Logboekschema voor samenvattingsupdates aanroepen

Overzichtslogboeken van oproepen:

Dit logboek is een subset van het logboekschema voor het bijwerken van het gespreksoverzicht. Het bevat basisinformatie over de aanroep, inclusief alle relevante id's, tijdstempels, eindpunten en SDK-informatie. Gebruik in plaats daarvan de logboeken voor het bijwerken van aanroepen voor snellere logboeklatentie.

Zie voor meer informatie: Overzichtslogboekschema aanroepen

Logboeken voor diagnostische updates aanroepen:

Deze logboekgegevens komen sneller binnen in Azure Monitor dan de logboeken met diagnostische aanroepen. We raden u aan deze logboeken te gebruiken in plaats van het schema voor het logboek voor diagnostische aanroepen. Dit logboek bevat informatie over de gespreksmediastroom van een deelnemer, samen met een set metrische gegevens die de kwaliteit van ervaringsmetingen aangeven.

Zie voor meer informatie: Logboekschema voor diagnostische updates aanroepen

Diagnostische logboeken aanroepen:

Dit logboek is een subset van het logboekschema voor het aanroepen van diagnostische gegevens. Het bevat informatie over de stroom, samen met een set metrische gegevens die de kwaliteit van ervaringsmetingen aangeven. Gebruik in plaats daarvan de logboeken voor het bijwerken van aanroepen voor snellere logboeklatentie.

Zie voor meer informatie: Logboekschema voor diagnostische gegevens aanroepen

Logboeken voor clientbewerkingen aanroepen:

Bevat gedetailleerde aanroepclient-gebeurtenissen. Deze logboekevenementen worden gegenereerd voor elk EndpointId in een oproep en het aantal gegenereerde gebeurtenislogboeken is afhankelijk van de bewerkingen die de deelnemer tijdens de oproep heeft uitgevoerd.

Zie voor meer informatie: Logboekschema voor clientbewerkingen aanroepen

Logboeken voor statistieken van clientmedia aanroepen:

Bevat gedetailleerde mediastroomwaarden. Deze logboeken worden gegenereerd voor elke mediastream in een gesprek. Voor elk EndpointId gesprek (inclusief de server) maakt Azure Communication Services een afzonderlijk logboek voor elke mediastream (bijvoorbeeld audio of video) tussen eindpunten. Het volume aan gegevens dat in elk logboek wordt gegenereerd, is afhankelijk van de duur van het gesprek en het aantal media-stoom in het gesprek.

In een P2P-aanroep bevat elk logboek gegevens die betrekking hebben op elk van de uitgaande streams die aan elk eindpunt zijn gekoppeld. In een groepsoproep maakt elke stroom die is endpointType = "Server" gekoppeld aan een logboek dat gegevens voor de binnenkomende streams bevat. Alle andere streams maken logboeken die gegevens bevatten voor de uitgaande streams voor alle niet-servereindpunten. Gebruik in groepsaanroepen de participantId waarde als sleutel om de gerelateerde inkomende en uitgaande logboeken toe te voegen aan een afzonderlijke deelnemerverbinding.

Zie voor meer informatie: Tijdreekslogboekschema voor clientmediastatistieken aanroepen

Einde van de oproepenquêtelogboeken:

Deze logboeken worden ingevuld wanneer de client voor webgesprekken een enquête verzendt aan het einde van de aanroep. U kunt deze logboeken gebruiken om de subjectieve perceptie van uw gesprekskwaliteit van uw gebruikers te leren.

Zie voor meer informatie: Overzicht van enquête einde van gesprek

Metrische logboeken aanroepen:

Deze logboeken bevatten geaggregeerde aanroepende metrische gegevens in dagelijkse opslaglocaties op basis van kenmerken zoals SDK-versie, naam van besturingssysteem en foutsubcode. Deze logboeken worden gebruikt in het dashboard voor spraak- en video-inzichten om grafieken van betrouwbaarheid, kwaliteit en prestaties op lange termijn te visualiseren op basis van het aantal geslaagde en mislukte Aanroepen van SDK-API-aanroepen van verschillende bewerkingen.

Zie voor meer informatie: Logboekschema voor metrische gegevens aanroepen

Gegevensconcepten

De volgende algemene beschrijvingen van gegevensconcepten zijn specifiek voor spraak- en videogesprekken. Deze concepten zijn belangrijk om te controleren, zodat u inzicht krijgt in de betekenis van de gegevens die in de logboeken zijn vastgelegd.

Entiteiten en id's

Raak vertrouwd met de volgende termen:

  • Aanroep: Zoals vertegenwoordigd in de gegevens, is een aanroep een abstractie die wordt weergegeven door correlationId. Waarden voor correlationId zijn uniek voor elke aanroep en zijn tijdsgebonden op callStartTime basis van en callDuration.

  • Deelnemer: Vertegenwoordigt de verbinding tussen een eindpunt en de server. Een deelnemer (participantId) is alleen aanwezig wanneer de oproep een groepsgesprek is.

  • Eindpunt: De meest unieke entiteit, vertegenwoordigd door endpointId. Elke aanroep is een gebeurtenis die gegevens van twee of meer eindpunten bevat. Eindpunten vertegenwoordigen de deelnemers in het gesprek.

    EndpointType geeft aan of het eindpunt een menselijke gebruiker (PSTN of VoIP), een bot of de server is die meerdere deelnemers binnen een gesprek beheert. Wanneer een endpointType waarde is "Server", krijgt het eindpunt geen unieke id toegewezen. U kunt analyseren endpointType en het aantal endpointId waarden om te bepalen hoeveel gebruikers en andere niet-menselijke deelnemers (bots en servers) deelnemen aan een gesprek.

    Systeemeigen SDK's voor Android en iOS gebruiken dezelfde endpointId waarde voor een gebruiker in meerdere aanroepen, zodat u inzicht krijgt in ervaringen in verschillende sessies. Dit proces verschilt van eindpunten op het web, die altijd een nieuwe endpointId waarde genereren voor elke nieuwe aanroep.

  • Stream: De meest gedetailleerde entiteit. Er is één stroom voor elke richting (inkomend of uitgaand) en mediaType waarde (bijvoorbeeldAudio).Video

P2P versus groepsgesprekken

Notitie

In dit artikel bevinden P2P- en groepsoproepen zich standaard binnen dezelfde tenant. Alle gespreksscenario's die meerdere tenants zijn, worden in het hele artikel opgegeven.

Er zijn twee soorten aanroepen, zoals vertegenwoordigd door callType:

  • Peer-to-peeraanroep (P2P): een verbinding tussen slechts twee eindpunten, zonder servereindpunt. P2P-aanroepen worden gestart als een aanroep tussen deze eindpunten en worden niet gemaakt als groepsaanroep vóór de verbinding.

    Diagram met een P2P-aanroep tussen twee eindpunten.

  • Groepsoproep: elke oproep met meer dan twee eindpunten die zijn verbonden. Groepsaanroepen bevatten een servereindpunt en de verbinding tussen elk eindpunt en de server. P2P-aanroepen die een ander eindpunt toevoegen tijdens de aanroep, blijven P2P en worden een groepsoproep. U kunt de tijdlijn bepalen van wanneer elk eindpunt deel uitmaakt van de aanroep met behulp van de participantStartTime en participantDuration metrische gegevens.

    Diagram met een groepsoproep tussen meerdere eindpunten.

Voorbeelden van verschillende oproeptypen

Notitie

In dit artikel bevinden P2P- en groepsoproepen zich standaard binnen dezelfde tenant. Alle gespreksscenario's die meerdere tenants zijn, worden in het hele artikel opgegeven.

Voorbeeld: P2P-aanroep

Het volgende diagram vertegenwoordigt twee eindpunten die rechtstreeks zijn verbonden in een P2P-aanroep. In dit voorbeeld maakt Communication Services twee logboeken voor oproepoverzichten (één voor elke participantID waarde) en vier diagnostische logboeken voor aanroepen (één voor elke mediastream).

Voor clientdeelnemers aanroepen van Azure Communication Services zijn er ook een reeks logboeken voor oproepclientbewerkingen en logboeken voor tijdreeksen voor clientmedia aanroepen. Het exacte aantal van deze logboeken is afhankelijk van het type SDK-bewerkingen dat wordt aangeroepen en de aanroepduur.

Diagram van een P2P-aanroep binnen dezelfde tenant.

Voorbeeld: Groepsoproep

Het volgende diagram vertegenwoordigt een voorbeeld van een groepsoproep met drie participantId waarden (wat drie deelnemers betekent) en een servereindpunt. Meerdere waarden voor endpointId kunnen worden weergegeven in meerdere deelnemers, bijvoorbeeld wanneer ze opnieuw deelnemen aan een oproep vanaf hetzelfde apparaat. Communication Services maakt één aanroepsamenvattingslogboek voor elke participantId waarde. Er worden vier diagnostische logboeken voor aanroepen gemaakt: één voor elke mediastroom per participantId.

Voor clientdeelnemers aanroepen van Azure Communication Services zijn de logboeken voor gespreksclientbewerkingen hetzelfde als P2P-aanroepen. Voor elke deelnemer die de aanroep-SDK gebruikt, zijn er een reeks logboeken voor aanroepclientbewerkingen.

Voor clientdeelnemers aanroepen van Azure Communication Services zijn de logboeken voor oproepclientbewerkingen en tijdreekslogboeken voor clientmedia voor gesprekken hetzelfde als P2P-aanroepen. Voor elke deelnemer die de aanroep-SDK gebruikt, zijn er een reeks logboeken voor oproepclientbewerkingen en het aanroepen van tijdreekslogboeken voor clientmedia.

Diagram van een groepsoproep binnen dezelfde tenant.

Voorbeeld: P2P-aanroep tussen tenants

Het volgende diagram vertegenwoordigt twee deelnemers in meerdere tenants die rechtstreeks zijn verbonden in een P2P-aanroep. In dit voorbeeld maakt Communication Services één aanroepsamenvattingslogboek (één voor elke deelnemer) met redacted OS- en SDK-versies. Communication Services maakt ook vier diagnostische logboeken voor aanroepen (één voor elke mediastream). Elk logboek bevat gegevens die betrekking hebben op de uitgaande stroom van participantID.

Diagram met een P2P-aanroep tussen tenants.

Voorbeeld: Groepsoproep tussen tenants

Het volgende diagram vertegenwoordigt een voorbeeld van een groepsoproep met drie participantId waarden voor meerdere tenants. Communication Services maakt één aanroepsamenvattingslogboek voor elke deelnemer met redacted OS- en SDK-versies. Communication Services maakt ook vier diagnostische logboeken voor aanroepen die betrekking hebben op elke participantId waarde (één voor elke mediastroom).

Diagram met een groepsoproep tussen tenants.

Notitie

Deze release ondersteunt alleen uitgaande diagnostische logboeken. Besturingssysteem- en SDK-versies die zijn gekoppeld aan de bot en de deelnemer kunnen worden bewerkt omdat Communication Services identiteiten van deelnemers en bots op dezelfde manier behandelt.

Veelgestelde vragen

Hoe kan ik logboeken opslaan?

In de volgende sectie wordt deze vereiste uitgelegd.

Azure Communication Services-logboeken worden niet standaard opgeslagen in uw Azure-account, dus u moet ze gaan opslaan om hulpprogramma's zoals dashboard voor spraak- en video-inzichten te kunnen gebruiken en diagnostische gegevens te kunnen bellen. Als u deze oproeplogboeken wilt verzamelen, moet u een diagnostische instelling inschakelen waarmee de oproepgegevens worden omverwijst naar een Log Analytics-werkruimte.

Gegevens worden niet met terugwerkende kracht opgeslagen, dus u begint pas met het vastleggen van oproeplogboeken nadat u de diagnostische instelling hebt geconfigureerd.

Volg de instructies voor het toevoegen van diagnostische instellingen voor uw resource in Logboeken inschakelen via diagnostische instellingen in Azure Monitor. U wordt aangeraden eerst alle logboeken te verzamelen. Nadat u de mogelijkheden in Azure Monitor hebt begrepen, bepaalt u welke logboeken u wilt behouden en hoe lang. Wanneer u uw diagnostische instelling toevoegt, wordt u gevraagd om logboeken te selecteren. Als u alle logboeken wilt verzamelen, selecteert u allLogs.

Uw gegevensvolume, retentie en gebruik in Log Analytics in Azure Monitor worden gefactureerd via bestaande Azure-gegevensmeters. We raden u aan uw gegevensgebruik en bewaarbeleid te controleren op kostenoverwegingen indien nodig. Zie Kosten beheren voor meer informatie.

Als u meerdere Resource-id's van Azure Communications Services hebt, moet u deze instellingen voor elke resource-id inschakelen.

Volgende stappen