Quelles données sont disponibles pour les applications pilotées par modèle ?

Les données de performances liées aux chargements de page et aux requêtes réseau sortantes Unified Interface (UCI) sont disponibles pour les applications pilotées par modèle.

Quels types de chargements de page sont disponibles ?

Où les données de chargement de page sont-elles disponibles ?

Ces données entrent dans la table pageViews dans Application Insights. Une entrée est enregistrée chaque fois qu’un utilisateur charge une page dans Unified Interface. Les données enregistrées n’incluent que les chargements « propres ». Les chargements dont la durée ne peut pas être mesurée avec précision (navigation rapide, changement de l’application, message d’alerte) ne sont pas inclus. Pour cette raison, nous vous déconseillons d’utiliser ces données pour des chiffres précis liés à l’analyse de l’utilisation.

Il existe d’autres propriétés dans customDimensions qui fournissent plus de détails sur les chargements de la page Unified Interface. Par exemple, cette requête renvoie les valeurs de tous les attributs dans la table pageViews.

pageViews
| take 1

Les attributs de la table pageViews comprennent :

• appModule : le nom du module d’application.
• entityName : cet attribut est présent lorsque cela est pertinent. Il est disponible sur les types de page tels que EditForm, EntityList et Dashboards lorsqu’ils sont liés à une entité. Dans certains scénarios, le formulaire n’est pas lié à une entité et la valeur apparaît comme non définie.
• formId : Le formId identifie de manière unique un formulaire et peut être utilisé pour corréler les problèmes affectant ce formulaire spécifique.
• hostType : Navigateur/Application mobile/Intégrée
• isBoot : Est-ce le premier chargement d’une session ?
• Type de charge
  • 0 : Première visite d’un type de page spécifique (par exemple, la première visite d’un formulaire).
  • 1 : Première visite d’une configuration spécifique (par exemple, la première visite d’un formulaire de compte).
  • 2 : Première visite d’un enregistrement spécifique (par exemple, la première visite d’un enregistrement de compte A2).
  • 3 : cette URL exacte a déjà été visitée.
• navigationOrigin : Le type de page à partir de laquelle l’utilisateur a navigué.
• networkConnectivityState : indique si l’appareil dispose d’une connexion.
• pageName : Le type de chargement de la page.
• serverConnectivityState : indique si l’application est connectée au serveur.
• syncRequestTime : le temps passé à attendre les requêtes synchrones.
• coldLatency : la première estimation de la latence du réseau, qui inclut le temps de négociation SSL.
• warmLatency : l’estimation ultérieure de la latence du réseau, qui est la latence typique attendue pour chaque requête.
• warmThroughput : Le débit estimé du réseau, en Kbps.

Pour les événements Microsoft Dataverse, le champ Identifiantou operation_ParentId dans Application Insights est le x-ms-service-request-id. L’operationId mappe à l’activityId au le backend à des fins de dépannage et de demandes de support.

Quel type de données est disponible pour les demandes de réseau sortant UCI ?

Ce sont des appels à d’autres dépendances effectués par Unified Interface pour restituer une certaine page. Il peut s’agir d’appels sortants vers Dataverse ou vers d’autres intégrations comme Azure DevOps ou Office. Utilisez la requête suivante pour obtenir ces données, qui sont disponibles dans la table de dépendance de la requête UCI :

dependencies
| where type == "UCI REQUEST"

La table de dépendance UCI Request comporte les champs suivants :

• Nom : L’URL invoquée par Unified Interface.

• Cible : actuellement identique à Nom.

• Succès : si l’appel a réussi ou échoué.

• UserId : l’ID utilisateur système de l’utilisateur connecté. Dataverse

• Durée : La durée de l’appel.

• customDimensions : contient les attributs suivants :

  

  • appModule : l’appModule effectuant l’appel.
  • bodySize : La taille du réponse, codée et décodée.
  • mis en cache : si la requête est allée dans le cache local ou a dû aller sur le serveur. Cela ne fonctionne pas comme prévu si l’utilisateur final utilisait le navigateur Internet Explorer.
  • télécharger : Le temps pris pour télécharger le réponse.
  • stall : le temps pendant lequel la requête était en attente dans la file d’attente du navigateur.
  • ttfb : Le temps passé à attendre le réponse initiale, également connu sous le nom de "temps jusqu’au premier octet". Ce temps capture la latence d’un aller-retour vers le serveur en plus du temps passé à attendre que le serveur fournisse le réponse.
  • coldLatency : la première estimation de la latence du réseau, qui inclut le temps de négociation SSL.
  • warmLatency : l’estimation ultérieure de la latence du réseau, qui est la latence typique attendue pour chaque requête.
  • warmThroughput : Le débit estimé du réseau, en Kbps.

Découvrir et analyser des scénarios

Pourquoi certains de mes utilisateurs expérimentent-ils des ralentissements sur Unified Interface ?

Un scénario où la découverte et l’analyse peuvent être utiles est lorsqu’un utilisateur d’une région (par exemple, l’Asie) signale qu’un formulaire s’exécute lentement. Cet utilisateur basé en Asie peut accéder à un environnement ou à une organisation en Amérique du Nord. Les détails affichent le temps de chargement total en plus de la durée liée au réseau. Il se peut bien que ce soit une cause de la lenteur des performances perçue par l’utilisateur.

Vous pouvez utiliser les attributs warmLatence, warmThroughput et coldLatency pour comprendre la répartition du temps passé sur les chargements de page et d’autres requêtes Unified Interface, comme illustré dans l’image suivante.

Dans la requête ci-dessus, la requête Unified Interface prend plus de temps que la requête réelle d’API Dataverse (API Web). La répartition dans ce cas est la durée de l’appel d’API Dataverse (56 ms) plus la valeur de CustomDimensions.warmLatency (89 ms), ce qui équivaut à presque la durée de l’ensemble de l’opération (144 ms). La valeur warmLatence est indicative de la lenteur pour ce client spécifique et peut être un problème que vous pouvez analyser au niveau de l’utilisateur à l’aide de la requête suivante :

dependencies
| where ['type'] == "UCI REQUEST"
| summarize avg(toint(customDimensions.warmLatency)), avg(toint(customDimensions.coldLatency)), avg(toint(customDimensions.warmThroughput)) by user_Id

pageViews
| summarize avg(toint(customDimensions.warmLatency)), avg(toint(customDimensions.coldLatency)), avg(toint(customDimensions.warmThroughput)) by user_Id

Puis-je déterminer comment l’utilisateur accède au système ?

L’attribut userAgent dans le champ customDimensions dans la table des requêtes Application Insights contient ces données. Vous pouvez utiliser la requête suivante pour obtenir un aperçu des différentes sources à partir desquelles les utilisateurs accèdent au système :

pageViews
| summarize count() by tostring(customDimensions.userAgent), user_Id

dependencies
| where ['type'] == "UCI REQUEST"

Comment obtenir le nombre d’utilisateurs accédant à partir d’un navigateur, d’applications mobiles ou intégrées ?

pageViews
| summarize count() by tostring(customDimensions.hostType)

L’image suivante montre un exemple d’ensemble de résultats de cette requête.

Comment puis-je limiter à un utilisateur spécifique ?

pageViews
| where user_Id == "[userid]"
| summarize count() by tostring(customDimensions.hostType)

Comment utiliser Application Insights avec Monitor ?

Azure Monitor aide au dépannage en temps réel sur une session du côté Unified Interface. Les demandes de transaction de bout en bout seront probablement disponibles dans Application Insights. Pour consulter les journaux d’une action donnée, notez l’ID d’activité sur une ligne de la page des détails de l’événement dans Monitor. Vous pouvez trouver les journaux avec la requête suivante :

union *
| where operation_Id contains "[ActivityIdHere]"

Monitor est un outil de débogage en temps réel ; cependant, les données peuvent ne pas y être disponibles pendant quelques heures.

Pourquoi les utilisateurs rencontrent-ils des problèmes avec un formulaire spécifique ?

L’utilisateur peut partager son identifiant de session à partir de la section À propos dans Unified Interface pour l’organisation spécifique.

Vous pouvez ensuite utiliser cet ID pour détecter des problèmes en examinant toutes les activités de cette session. Utilisez la requête suivante :

union *
| where session_Id == '[sessionIdHere]'

Quels formulaires sont utilisés dans différents emplacements et quelles sont les performances de chargement des formulaires dans ces emplacements ?

pageViews
| summarize avg(duration) by name, client_City, client_CountryOrRegion

Une API externe appelle-t-elle l’échec et puis-je explorer en détail dans la pile d’erreurs pour aider au débogage ?

La vue Navigateur sur le volet Échecs contient les requêtes sortantes Unified Interface. Les demandes allant à Dataverse ou l’organisation contient l’URL de l’organisation. Il peut y avoir d’autres demandes dirigées vers d’autres URL (par exemple, dans l’image suivante, l’organisation a une personnalisation appelant dc.services.visualstudio.com). Vous pouvez examiner la transaction de bout en bout pour examiner plus en détail les échecs de ces appels sortants externes.

Puis-je définir une alerte sur le seuil de performance pour certaines actions de formulaire ? Lorsque l’alerte est reçue, cela permettra-t-il à un fabricant de diagnostiquer et de résoudre le problème ?

Oui. Vous pouvez configurer alertes dans Application Insights pour surveiller la santé de votre application.