Dela via

Översikt över Azure Communication Services-samtalsloggar

  • Artikel

Azure Communication Services tillhandahåller loggningsfunktioner som du kan använda för att övervaka och felsöka din Communication Services-lösning. Konfigurera dessa funktioner via Azure Portal.

Innehållet i den här artikeln refererar till loggar som aktiverats via Azure Monitor (se även Vanliga frågor och svar). Information om hur du aktiverar loggarna för Communication Services finns i Aktivera loggning i diagnostikinställningar.

Viktigt!

Du måste samla in loggar om du vill analysera dem. Mer information finns i: Hur gör jag för att lagra loggar?

Azure lagrar inte dina samtalsloggdata om du inte aktiverar dessa specifika diagnostikinställningar. Dina samtalsdata är inte retroaktivt tillgängliga. Du ackumulerar data när du har skapat diagnostikinställningarna.

Använda samtalsloggar

Vi rekommenderar att du samlar in alla tillgängliga samtalsloggar i en log analytics-resurs så att du kan övervaka samtalsanvändningen och förbättra samtalskvaliteten och ta emot nya loggar från Azure Communication Services när vi släpper dem.

Det finns två huvudverktyg som du kan använda för att övervaka dina samtal och förbättra samtalskvaliteten.

Vi rekommenderar att du använder instrumentpanelerna för röst- och videoinsikter för att starta kvalitetsundersökningar och använda samtalsdiagnostik efter behov för att utforska enskilda samtal när du behöver detaljerad information.

Tillgängliga loggar

Azure Communication Services skapar åtta samtalsloggar:

Uppdateringsloggar för samtalssammanfattning:

Dessa loggdata kommer till Azure Monitor snabbare än anropssammanfattningsloggarna och vi rekommenderar att du använder dessa loggar i stället för schemat för anropssammanfattningsloggen. Den här loggen innehåller grundläggande information om anropet, inklusive alla relevanta ID:er, tidsstämplar, slutpunkter och SDK-information.

Mer information finns i: Anropa loggschema för sammanfattningsuppdateringar

Samtalssammanfattningsloggar:

Den här loggen är en delmängd av loggschemat för samtalssammanfattningsuppdateringar. Den innehåller grundläggande information om anropet, inklusive alla relevanta ID:er, tidsstämplar, slutpunkter och SDK-information. För snabbare loggfördröjning använder du loggarna för uppdatering av samtalssammanfattning i stället.

Mer information finns i: Schema för samtalssammanfattningslogg

Anropa loggar för diagnostikuppdateringar:

Dessa loggdata kommer till Azure Monitor snabbare än anropsdiagnostikloggarna och vi rekommenderar att du använder loggarna i stället för loggschemat för anropsdiagnostik. Den här loggen innehåller information om en deltagares anropsmediaström, tillsammans med en uppsättning mått som anger kvaliteten på upplevelsemätningar.

Mer information finns i: Anropa loggschema för diagnostikuppdateringar

Anropa diagnostikloggar:

Den här loggen är en delmängd av loggschemat för uppdatering av samtalsdiagnostik. Den innehåller information om strömmen, tillsammans med en uppsättning mått som anger kvaliteten på upplevelsemätningar. För snabbare loggfördröjning använder du loggarna för uppdatering av samtalssammanfattning i stället.

Mer information finns i: Anropa diagnostikloggschema

Anropa klientåtgärdsloggar:

Innehåller detaljerade samtalsklienthändelser. Dessa logghändelser genereras för var EndpointId och en i ett anrop och antalet händelseloggar som genereras beror på de åtgärder som deltagaren utförde under anropet.

Mer information finns i: Anropa loggschema för klientåtgärder

Anropa statistikloggar för klientmedia:

Innehåller detaljerade mediaströmvärden. Dessa loggar genereras för varje medieström i ett anrop. För varje EndpointId samtal (inklusive servern) skapar Azure Communication Services en distinkt logg för varje medieström (till exempel ljud eller video) mellan slutpunkter. Mängden data som genereras i varje logg beror på samtalets varaktighet och antalet medieångor i samtalet.

I ett P2P-anrop innehåller varje logg data som relaterar till var och en av de utgående strömmar som är associerade med varje slutpunkt. I ett gruppanrop skapar varje ström som är associerad med endpointType = "Server" en logg som innehåller data för de inkommande strömmarna. Alla andra strömmar skapar loggar som innehåller data för utgående strömmar för alla icke-serverslutpunkter. I gruppanrop använder du participantId värdet som nyckel för att ansluta relaterade inkommande och utgående loggar till en distinkt deltagaranslutning.

Mer information finns i: Anropa tidsserieloggschema för tidsserie för klientmediastatistik

Slut på undersökningsloggar för samtal:

Dessa loggar fylls i när webbanropsklienten skickar en undersökning i slutet av samtalet. Du kan använda dessa loggar för att lära dig den subjektiva uppfattningen om samtalskvaliteten från dina användare.

Mer information finns i: Översikt över slutpunktsundersökning

Anropa måttloggar:

Dessa loggar innehåller aggregerade anropsmått i dagliga lagerplatser baserat på attribut som SDK-version, OS-namn och felunderkod. Dessa loggar används i instrumentpanelen för röst- och videoinsikter för att visualisera långsiktiga diagram över tillförlitlighet, kvalitet och prestanda baserat på antalet lyckade och misslyckade anrop av SDK-API:et för olika åtgärder.

Mer information finns i: Anropa schema för måttloggar

Databegrepp

Följande beskrivningar av databegrepp på hög nivå är specifika för röst- och videosamtal. Dessa begrepp är viktiga att granska så att du kan förstå innebörden av de data som samlas in i loggarna.

Entiteter och ID:t

Bekanta dig med följande termer:

  • Anrop: Som representeras i data är ett anrop en abstraktion som visas av correlationId. Värden för correlationId är unika för varje anrop och är tidsbundna baserat på callStartTime och callDuration.

  • Deltagare: Representerar anslutningen mellan en slutpunkt och servern. En deltagare (participantId) är bara närvarande när samtalet är ett gruppsamtal.

  • Slutpunkt: Den mest unika entiteten, representerad av endpointId. Varje anrop är en händelse som innehåller data från två eller flera slutpunkter. Slutpunkter representerar deltagarna i samtalet.

    EndpointType anger om slutpunkten är en mänsklig användare (PSTN eller VoIP), en robot eller servern som hanterar flera deltagare i ett samtal. När ett endpointType värde är "Server"tilldelas slutpunkten inte ett unikt ID. Du kan analysera endpointType och antalet endpointId värden för att avgöra hur många användare och andra icke-mänskliga deltagare (robotar och servrar) som ansluter till ett anrop.

    Interna SDK:er för Android och iOS återanvänder samma endpointId värde för en användare i flera anrop, så att du kan få en förståelse för upplevelser mellan sessioner. Den här processen skiljer sig från webbaserade slutpunkter, som alltid genererar ett nytt endpointId värde för varje nytt anrop.

  • Ström: Den mest detaljerade entiteten. Det finns en ström för varje riktning (inkommande eller utgående) och mediaType värde (till exempel Audio eller Video).

P2P jämfört med gruppanrop

Kommentar

I den här artikeln finns P2P- och gruppanrop inom samma klientorganisation som standard. Alla samtalsscenarier som är korsklientorganisationer anges i enlighet med detta i hela artikeln.

Det finns två typer av anrop, som representeras av callType:

  • Peer-to-peer-anrop (P2P): En anslutning mellan endast två slutpunkter utan serverslutpunkt. P2P-anrop initieras som ett anrop mellan dessa slutpunkter och skapas inte som en gruppanropshändelse före anslutningen.

    Diagram som visar ett P2P-anrop över två slutpunkter.

  • Gruppsamtal: Alla samtal som har fler än två anslutna slutpunkter. Gruppanrop inkluderar en serverslutpunkt och anslutningen mellan varje slutpunkt och servern. P2P-anrop som lägger till en annan slutpunkt under anropet upphör att vara P2P och de blir ett gruppanrop. Du kan fastställa tidslinjen för när varje slutpunkt anslöt samtalet med hjälp av måtten participantStartTime och participantDuration .

    Diagram som visar ett gruppanrop över flera slutpunkter.

Exempel på olika samtalstyper

Kommentar

I den här artikeln finns P2P- och gruppanrop inom samma klientorganisation som standard. Alla samtalsscenarier som är korsklientorganisationer anges i enlighet med detta i hela artikeln.

Exempel: P2P-anrop

Följande diagram representerar två slutpunkter som är anslutna direkt i ett P2P-anrop. I det här exemplet skapar Communication Services två anropssammanfattningsloggar (en för varje participantID värde) och fyra anropsdiagnostikloggar (en för varje medieström).

För Azure Communication Services-samtalsklientdeltagare finns det också en serie loggar för anropsklientåtgärder och tidsserieloggar för samtalsmediastatistik för klientmedia. Det exakta antalet loggar beror på vilken typ av SDK-åtgärder som anropas och samtalsvaraktighet.

Diagram som visar ett P2P-anrop i samma klientorganisation.

Exempel: Gruppsamtal

Följande diagram representerar ett gruppanropsexempel med tre participantId värden (vilket innebär tre deltagare) och en serverslutpunkt. Flera värden för endpointId kan potentiellt visas i flera deltagare, till exempel när de återansluter till ett anrop från samma enhet. Communication Services skapar en anropssammanfattningslogg för varje participantId värde. Den skapar fyra anropsdiagnostikloggar: en för varje medieström per participantId.

För Azure Communication Services-samtalsklientdeltagare är anropsklientens driftloggar samma som P2P-anrop. För varje deltagare som använder anropande SDK finns det en serie anropsklientdriftsloggar.

För Azure Communication Services-samtalsklientdeltagare är loggarna för anropsklientåtgärder och tidsserieloggarna för anropsklientens mediestatistik samma som P2P-anrop. För varje deltagare som använder anropande SDK finns det en serie loggar för anropsklientåtgärder och tidsserieloggar för samtalsmediastatistik.

Diagram som visar ett gruppanrop i samma klientorganisation.

Exempel: P2P-anrop mellan klientorganisationer

Följande diagram representerar två deltagare i flera klienter som är direkt anslutna i ett P2P-anrop. I det här exemplet skapar Communication Services en anropssammanfattningslogg (en för varje deltagare) med redacted OS- och SDK-versioner. Communication Services skapar också fyra anropsdiagnostikloggar (en för varje medieström). Varje logg innehåller data som relaterar till den utgående strömmen av participantID.

Diagram som visar ett P2P-anrop mellan klientorganisationer.

Exempel: Gruppanrop mellan klientorganisationer

Följande diagram representerar ett gruppanropsexempel med tre participantId värden i flera klienter. Communication Services skapar en anropssammanfattningslogg för varje deltagare med redacted OS- och SDK-versioner. Communication Services skapar också fyra anropsdiagnostikloggar som relaterar till varje participantId värde (ett för varje medieström).

Diagram som visar ett gruppanrop mellan klientorganisationer.

Kommentar

Den här versionen stöder endast utgående diagnostikloggar. OS- och SDK-versioner som är associerade med roboten och deltagaren kan redigeras eftersom Communication Services behandlar identiteter för deltagare och robotar på samma sätt.

Vanliga frågor och svar

Hur gör jag för att lagra loggar?

I följande avsnitt beskrivs det här kravet.

Azure Communication Services-loggar lagras inte i ditt Azure-konto som standard, så du måste börja lagra dem för att verktyg som instrumentpanelen för röst- och videoinsikter ska fungera och anropa diagnostiken . Om du vill samla in dessa samtalsloggar måste du aktivera en diagnostikinställning som dirigerar samtalsdata till en Log Analytics-arbetsyta.

Data lagras inte retroaktivt, så du börjar samla in samtalsloggar först när du har konfigurerat diagnostikinställningen.

Följ anvisningarna för att lägga till diagnostikinställningar för din resurs i Aktivera loggar via diagnostikinställningar i Azure Monitor. Vi rekommenderar att du först samlar in alla loggar. När du har förstått funktionerna i Azure Monitor kan du avgöra vilka loggar du vill behålla och hur länge. När du lägger till diagnostikinställningen uppmanas du att välja loggar. Om du vill samla in alla loggar väljer du allaLoggar.

Din datavolym, kvarhållning och användning i Log Analytics i Azure Monitor debiteras via befintliga Azure-datamätare. Vi rekommenderar att du övervakar dina dataanvändnings- och kvarhållningsprinciper för kostnadsöverväganden efter behov. Mer information finns i Kontrollera kostnader.

Om du har flera Resurs-ID:t för Azure Communications Services måste du aktivera de här inställningarna för varje resurs-ID.

Nästa steg