Partager via

Schéma des journaux des métriques d’appels

  • Article

Ce document explique les journaux ACSCallingMetrics disponibles via Azure Monitor sous la forme de journaux de ressources.

Les journaux de métriques d’appels sont utilisés dans le tableau de bord des insights vocaux et vidéo pour visualiser des graphiques à long terme de fiabilité, de qualité et de performances en fonction du nombre d’appels réussis et ayant échoué d’API du Kit de développement logiciel (SDK) appelant, appels de diverses opérations. Utilisez ces journaux pour mieux comprendre les métriques d’appel agrégées quotidiennes sur plusieurs dimensions pour vos charges de travail de communication. Les journaux de métriques d’appels contiennent des métriques d’appel agrégées dans des emplacements quotidiens en fonction d’attributs tels que la version du Kit de développement logiciel (SDK), le nom du système d’exploitation et le sous-code d’erreur.

Comment utiliser les journaux des appels

Nous vous recommandons de collecter tous les journaux des appels disponibles dans une ressource d’analytique des journaux d’activité afin de pouvoir surveiller votre utilisation des appels et d’améliorer la qualité des appels, et pour pouvoir recevoir de nouveaux journaux d’Azure Communication Services dès que nous les publions.

Vous pouvez utiliser deux outils principaux pour surveiller vos appels et améliorer leur qualité.

Nous vous recommandons d’utiliser les tableaux de bord des insights vocaux et vidéo pour démarrer des investigations de qualité et d’utiliser les diagnostics d’appels si nécessaire pour explorer des appels individuels quand vous avez besoin de détails précis.

Concepts de données

Important

Vous devez collecter les journaux si vous souhaitez les analyser. Pour plus d’informations, veuillez consulter la rubrique Comment stocker les journaux ?

Azure ne stocke pas les données de vos journaux d’appels, sauf si vous activez ces paramètres de diagnostic spécifiques. Vos données d’appels ne sont pas disponibles rétroactivement. Vous accumulez des données une fois les paramètres de diagnostic créés.

Ces métriques sont visualisées dans le tableau de bord Insights vocaux et vidéo, nous vous recommandons de consulter ces visuels pour comprendre comment vous pouvez utiliser ces données si vous souhaitez créer votre propre tableau de bord ou personnaliser les tableaux de bord existants. Vous pouvez modifier le classeur existant dans le tableau de bord Insights vocaux et vidéo pour afficher les requêtes derrière chaque visuel.

Ce schéma de journal comporte une propriété appelée MetricName qui détaille les différentes métriques envoyées dans ce schéma. Les métriques sont réparties en deux catégories principales : métriques d’API et métriques de diagnostics accessibles à l’utilisateur (UFD). Les métriques UFD sont ensuite divisées en deux groupes qui expliquent le volume des occurrences UFD et la façon dont les UFD se sont remis de ces occurrences pendant les appels.

Puisque ces métriques vous donnent une vue d’ensemble de votre ressource d’appel entière, vous pouvez configurer des alertes automatisées si une métrique tombe. Pour savoir comment configurer des alertes automatisées, veuillez consulter le document : Tutoriel : créer une alerte de recherche de journal pour une ressource Azure

Catégories de métriques

Métriques de l’API

Ces métriques mesurent à la fois les réussites et les défaillances (dcount) des API publiques du Kit de développement logiciel (SDK) appelant, par exemple (désactiver le son, rejoindre, et bien plus encore).

  • reliability/api/CreateView/Local
  • reliability/api/Join
  • reliability/api/StartVideo
  • reliability/api/AcceptIncomingCall
  • reliability/api/CreateView/Remote
  • reliability/api/StopVideo
  • reliability/api/CallAgentInit
  • reliability/api/StartCall

Métriques de diagnostics accessibles à l’utilisateur (UFD)

Métriques de legs de diagnostics accessibles par l’utilisateur (UFD) : (nombre dcount de participants (legs) ayant au moins un UFD incorrect lors d’un appel)

Fournit les nombres de participants affectés par un UFD lors d’un appel.

  • reliability/leg/UFD/NetworkReconnect
  • reliability/leg/UFD/CameraStoppedUnexpectedly
  • reliability/leg/UFD/MicrophoneMuteUnexpectedly
  • reliability/leg/UFD/NetworkReceiveQuality
  • reliability/leg/UFD/MicrophonePermissionDenied
  • reliability/leg/UFD/MicrophonePermissionDenied
  • reliability/leg/UFD/NoMicrophoneDevicesEnumerated
  • reliability/leg/UFD/CameraPermissionDenied
  • reliability/leg/UFD/CameraStartFailed
  • reliability/leg/UFD/CameraStoppedUnexpectedly
  • reliability/leg/UFD/CapturerStartFailed
  • reliability/leg/UFD/CameraStartTimedOut
  • reliability/leg/UFD/NoSpeakerDevicesEnumerated
  • reliability/leg/UFD/CameraFreeze
  • reliability/leg/UFD/NetworkRelaysNotReachable
  • reliability/leg/UFD/SpeakingWhileMicrophoneIsMuted
  • reliability/leg/UFD/NoNetwork
  • reliability/leg/UFD/NetworkSendQuality
  • reliability/leg/UFD/ScreenshareRecordingDisabled

Métriques de récupération de l’API Diagnostics accessibles à l’utilisateur (UFD) : (nombre dcount d’occurrences qui ont eu un problème, mais qui se sont ensuite remises lors d’un appel)

Fournit les nombres d’UFD déclenchés lors d’un appel par le Kit développement logiciel (SDK) appelant, mais qui se sont remis par la suite pendant l’appel. Par exemple, si l’UFD NetworkReconnect a été déclenché une fois dans un appel, mais que le réseau s’est correctement remis pendant l’appel. Dans cet exemple, le nombre d’UFD de récupération d’API correcte est supérieur ou égal au nombre de métriques de legs d’UFD incorrectes. Vous pouvez calculer un taux de récupération d’UFD de 100 %.

  • reliability/api/UFD/recovery/NetworkReceiveQuality
  • reliability/api/UFD/recovery/NetworkReconnect
  • reliability/api/UFD/recovery/CameraStoppedUnexpectedly
  • reliability/api/UFD/recovery/NetworkSendQuality
  • reliability/api/UFD/recovery/MicrophoneMuteUnexpectedly
  • reliability/api/UFD/recovery/MicrophoneNotFunctioning
  • reliability/api/UFD/recovery/CapturerStoppedUnexpectedly
  • reliability/api/UFD/recovery/CameraFreeze
  • reliability/api/UFD/recovery/CameraStartFailed
  • reliability/api/UFD/recovery/NoMicrophoneDevicesEnumerated
  • reliability/api/UFD/recovery/MicrophonePermissionDenied
  • reliability/api/UFD/recovery/CameraPermissionDenied
  • reliability/api/UFD/recovery/NoSpeakerDevicesEnumerated
  • reliability/api/UFD/recovery/CapturerStartFailed
  • reliability/api/UFD/recovery/ScreenshareRecordingDisabled
  • reliability/api/UFD/recovery/NoNetwork
  • reliability/api/UFD/recovery/CameraStartTimedOut
  • reliability/api/UFD/recovery/SpeakingWhileMicrophoneIsMuted
  • reliability/api/UFD/recovery/NetworkRelaysNotReachable

Définitions des données

Schéma des journaux des métriques d’appels

Ce tableau décrit chaque propriété.

Propriété Description
TimeGenerated Horodatage (UTC) de la génération du journal.
OperationName Opération associée à l’enregistrement de journal.
OperationVersion Version de l’API associée à l’opération. Ou version de l’opération s’il n’y a pas de version d’API.
Category Catégorie de journal de l’événement. Les journaux avec la même catégorie de journal et le même type de ressource partagent les mêmes champs de propriétés.
CorrelationId GUID unique qui met en corrélation des événements dans la même dimension.
TimestampMax Horodatage maximal en UTC pour chaque dimension.
TimestampBin Classe d’horodatage quotidien pour chaque dimension.
MetricValueAvg Valeur moyenne de la métrique pour chaque dimension.
Unit Unité de la métrique.
Goal Seuil défini pour qu’un leg réussisse.
FailedLegsDcount Nombre de participants (legs) ayant échoué par dimension.
SuccessLegsDcount Nombre de participants ayant réussi (legs) par dimension.
CallsDcount Nombre total d’appels par dimension.
LegsDcount Nombre total de participants par dimension.
SubCode Dimension indiquant le sous-code.
CallType Dimension indiquant le type d’appel.
Platform Dimension de la plateforme (par exemple, iOS, Android, Windows).
ResultType Dimension de type de résultat (par exemple, catégorie réussite ou défaillance).
DeviceModel Dimension indiquant le modèle de l’appareil.
DeviceBrand Dimension indiquant la marque de l’appareil.
DeviceFamily Dimension indiquant la famille de l’appareil.
DeviceOsVersionMajor Numéro de la version majeure du système d’exploitation de l’appareil.
DeviceOsVersionMinor Numéro de la version mineure du système d’exploitation de l’appareil.
DeviceBrowserVersionMinor Numéro de la version mineure du navigateur de l’appareil.
DeviceBrowserVersionMajor Numéro de la version majeure du navigateur de l’appareil.
DeviceOsName Nom du système d’exploitation de l’appareil.
DeviceBrowser Nom du navigateur de l’appareil.
SdkVersion Version du Kit de développement logiciel (SDK) en cours d’exécution sur le client.
MetricName Nom de la métrique mesurée.

Exemples de données pour différents types d’appel

Journal des métriques d’appels P2P et d’appels de groupe

Pour le journal des métriques d’appels, il n’existe aucune différence entre les scénarios d’appels P2P et d’appels de groupe. Le code suivant est un exemple générique montrant le schéma de ces journaux d’activité.

Journaux des métriques d’appels

Voici deux exemples de lignes du journal des métriques d’appels :

"properties": {
  "TenantId": "4e7403f8-515a-4df5-8e13-59f0e2b76e3a",
  "TimeGenerated": "2025-02-03T05:17:39.1840000Z",
  "OperationName": "CallingMetrics",
  "OperationVersion": "1.0-dev",
  "Category": "CallingMetrics",
  "CorrelationId": "1f27dac9e6d64c82cafdd6da73cdb785",
  "TimestampMax": "2025-02-02T14:35:55.0000000Z",
  "TimestampBin": "2025-02-02T00:00:00.0000000Z",
  "MetricValueAvg": 100,
  "Unit": "percentage",
  "Goal": ">= 100.0",
  "FailedLegsDcount": 0,
  "SuccessLegsDcount": 2,
  "CallsDcount": 1,
  "LegsDcount": 2,
  "SubCode": 0,
  "CallType": "1 to 1",
  "Platform": "Web",
  "ResultType": "Succeeded",
  "DeviceModel": "",
  "DeviceBrand": "",
  "DeviceFamily": "Other",
  "DeviceOsVersionMajor": "",
  "DeviceOsVersionMinor": 10,
  "DeviceBrowserVersionMinor": 0,
  "DeviceBrowserVersionMajor": 132,
  "DeviceOsName": "Windows",
  "DeviceBrowser": "Edge",
  "SdkVersion": "1.32.1.0_stable",
  "MetricName": "reliability/leg/UFD/CameraStoppedUnexpectedly",
  "SourceSystem": "",
  "Type": "ACSCallingMetrics",
  "_ResourceId": "/subscriptions/50ad1522-5c2c-4d9a-a6c8-67c11ecb75b8/resourcegroups/calling-sample-apps/providers/microsoft.communication/communicationservices/corertc-test-apps"
}

"properties": {
  "TenantId": "4e7403f8-515a-4df5-8e13-59f0e2b76e3a",
  "TimeGenerated": "2025-02-03T05:17:39.1840000Z",
  "OperationName": "CallingMetrics",
  "OperationVersion": "1.0-dev",
  "Category": "CallingMetrics",
  "CorrelationId": "1f27dac9e6d64c82cafdd6da73cdb785",
  "TimestampMax": "2025-02-02T14:35:55.0000000Z",
  "TimestampBin": "2025-02-02T00:00:00.0000000Z",
  "MetricValueAvg": 100,
  "Unit": "percentage",
  "Goal": ">= 100.0",
  "FailedLegsDcount": 0,
  "SuccessLegsDcount": 2,
  "CallsDcount": 1,
  "LegsDcount": 2,
  "SubCode": 0,
  "CallType": "1 to 1",
  "Platform": "Web",
  "ResultType": "Succeeded",
  "DeviceModel": "",
  "DeviceBrand": "",
  "DeviceFamily": "Other",
  "DeviceOsVersionMajor": "",
  "DeviceOsVersionMinor": 10,
  "DeviceBrowserVersionMinor": 0,
  "DeviceBrowserVersionMajor": 132,
  "DeviceOsName": "Windows",
  "DeviceBrowser": "Edge",
  "SdkVersion": "1.32.1.0_stable",
  "MetricName": "reliability/leg/UFD/CameraStoppedUnexpectedly",
  "SourceSystem": "",
  "Type": "ACSCallingMetrics",
  "_ResourceId": "/subscriptions/50ad1522-5c2c-4d9a-a6c8-67c11ecb75b8/resourcegroups/calling-sample-apps/providers/microsoft.communication/communicationservices/corertc-test-apps"
}

Forum aux questions

Comment stocker les journaux ?

La section suivante décrit cette exigence.

Les journaux Azure Communication Services ne sont pas stockés dans votre compte Azure par défaut. Vous devez donc commencer à les stocker pour que les outils comme le tableau de bord des insights vocaux et vidéo et les diagnostics d’appels fonctionnent. Pour collecter les journaux des appels, vous devez activer un paramètre de diagnostic qui dirige les données d’appel vers un espace de travail Log Analytics.

Les données ne sont pas stockées rétroactivement, par conséquent vous commencez à capturer les journaux des appels uniquement après avoir configuré le paramètre de diagnostic.

Pour ajouter des paramètres de diagnostic à votre ressource, suivez les instructions de Activer les journaux via des paramètres de diagnostic dans Azure Monitor. Nous vous recommandons de collecter tous les journaux initialement. Une fois que vous avez compris les fonctionnalités d’Azure Monitor, déterminez les journaux que vous voulez conserver et pendant combien de temps. Quand vous ajoutez votre paramètre de diagnostic, vous êtes invité à sélectionner des journaux. Pour collecter tous les journaux, sélectionnez allLogs.

Le volume de vos données, leur conservation et leur utilisation dans Log Analytics au sein d’Azure Monitor sont facturés via les compteurs de données Azure existants. Nous vous recommandons d’analyser vos stratégies d’utilisation et de conservation des données pour des considérations de coût si nécessaire. Pour plus d’informations, consultez Contrôler les coûts.

Si vous avez plusieurs ID de ressource Azure Communications Services, vous devez activer ces paramètres pour chaque ID de ressource.

Étapes suivantes