Événements de télémétrie pour Microsoft Dataverse

Le flux de données fournit actuellement des données de performance liées aux appels d’API entrants Dataverse, aux appels d’exécution de plug-in Dataverse et aux appels de SDK Dataverse. Il fournit également des données sur les pannes de plug-in et les opérations de SDK Dataverse.

Appels entrants d’API Dataverse

Il s’agit d’appels passés à l’API Dataverse. Ils peuvent provenir de Unified Interface (UCI), du client web hérité, des clients personnalisés qui utilisent le SDK, etc. Ils peuvent être trouvés dans la table requêtes de Application Insights, qui contient les champs suivants.

• Nom : Le type de demande. Ceux-ci se répartissent en deux catégories :

  • Requête d’API Web : une requête adressée à OData v4 point de terminaison qui est couramment utilisée par Unified Interface et les clients modernes. Cette requête se transforme en une opération commune aux deux. L’API Web est un « wrapper » permettant d’activer le modèle de programmation RESTful, mais une fois les données reçues, tout devient le même au sein du serveur. Lorsque la réponse est renvoyée, elle est convertie en JSON si la demande provient de l’API Web.
  • Demande de service d’organisation : une demande adressée à l’API d’organisation point de terminaison utilisée par les clients SDK ou le client Web hérité.

• Durée : Le temps nécessaire au serveur pour répondre à la requête.

• Url : l’URL vers laquelle l’appel a été effectué.

• Dimensions personnalisées :

  • UserAgent : Application Insights remplit automatiquement le champ de l’agent utilisateur avec PC car ces journaux sont transmis depuis un serveur dans un centre de données. Application Insights ne permet pas de remplacer le champ de l’agent utilisateur. Parfois, le champ de l’agent utilisateur ne peut pas être renseigné. L’agent utilisateur à partir duquel l’appel a été effectué peut être consulté à l’aide de la requête suivante :

    requests
    | summarize count() by tostring(customDimensions.userAgent)
    

    

• Operation_Name : le nom lisible de l’opération à afficher dans les vues, telles que la vue de transaction de bout en bout.

Journaux d’exécution de plug-in Dataverse

Ces journaux pour les plug-ins personnalisés exécutés pour une opération donnée se trouvent dans la table dépendance. Voici un exemple de requête :

dependencies
| where type == "Plugin"
| take 100

• Nom/Cible : Le nom de type entièrement qualifié pour le plug-in en cours d’exécution.
• Durée : Le temps nécessaire à l’exécution du plug-in.
• Dimensions personnalisées :
  • Profondeur : la profondeur actuelle de l’exécution dans la pile d’appels.
  • EntityName : le nom de l’entité sur laquelle agit le plug-in.
  • IsolationType : une valeur indiquant si le plug-in est exécuté dans le sandbox :
    • 1 : Aucune
    • 2 : Bac à sable
    • 3 : URL externe
  • PluginName : Le nom convivial du plug-in.
  • PluginType : Le nom du type de plug-in en cours d’exécution.
  • PluginVersion : la version du plug-in publié. L’intention ici est de pouvoir utiliser ces informations pour dépanner les mises à jour de version.
  • Étape : Correspond aux valeurs suivantes :
    • PreValidation = 10
    • PreOperation = 20
    • PreOperationBeforeExternalPlugins = 15
    • PreOperationAfterExternalPlugins = 25
    • MainOperation = 30
    • PostOperationBeforeExternalPlugins = 35
    • PostOperationAfterExternalPlugins = 45
    • PostOperation = 40
    • PostOperationDeprecated = 50
  • StepName : Le nom du traitement des messages SDK étape. Ceci est généralement généré par l’outil Plugin Registration Tool en utilisant des informations sur le PluginName, PluginType, et le nom de l’opération, tel que : ErrorMessageTest.ThrowException: Creation of account.

Données de télémétrie dans votre code de plug-in

Pour comprendre ce qui se passe dans votre code de plug-in, vous pouvez inclure une télémétrie personnalisée à partir de votre plug-in en utilisant l’interface Microsoft.Xrm.Sdk.PluginTelemetry.ILogger dans votre code de plug-in pour écrire les données de télémétrie directement dans votre Application Insights ressource. Plus d’informations : Écrire la télémétrie sur votre ressource Application Insights en utilisant ILogger (version préliminaire)

Journaux SDK Dataverse

Il s’agit des journaux des opérations SDK déclenchées dans le cadre d’une requête entrante. Ceux-ci sont enregistrés dans la table dépendance dans Application Insights, car ils sont suivis en tant que dépendances pour l’exécution de la requête. Ils sont identifiés par le nom du type, commençant par SDK. Voici un exemple de requête :

dependencies
| where type startswith "SDK"
| take 10

• Type : Le type de requête SDK déclenchée. Les exemples incluent Retrieve, RetrieveMultiple, FetchXmlToQueryExpression et WhoAmI.
• Nom/Cible : il s’agit du nom de l’entité ciblée par l’opération SDK.
• Dimensions personnalisées :
  • ClientType : Le type de client d’où provient l’appel. Certaines valeurs possibles sont Web, UCIClient et OutlookFull.
  • EntityId : l’identifiant unique de l’entité utilisée.
  • EntityName : le nom de l’entité utilisée.

Exceptions

Vous verrez les détails des échecs dans les opérations de plug-in et de SDK dans Application Insights. La table exceptions dans Application Insights alimente le volet Défaillances. Ces détails sur les défaillances sont en corrélation avec le reste des événements dans les appels de plug-in et de SDK dans la vue de bout en bout. Toutes les informations disponibles sont ajoutées aux colonnes lorsque cela est possible et à customDimensions lorsqu’il n’y a pas de correspondance exacte de colonne.

Vous remarquerez que certains des champs de la table exceptions ne sont pas renseignés. En effet, ces champs ne peuvent être définis que si le SDK Application Insights est utilisé pour émettre des journaux à partir de la source. Cette fonctionnalité collecte la télémétrie de la plateforme, puis la pousse dans Application Insights conformément au schéma Application Insights.

exceptions
| take 10

Cette requête renverra tous les détails de l’attribut de la table exception.

• problemId/type : Le type d’exception.
• externalMessage : Le message d’exception.
• Dimensions personnalisées :
  • clientType : Le type de client d’où provient l’appel. Certaines valeurs possibles sont Web, UCIClient et OutlookFull.
  • exceptionSource : Le plug-in ou pointer où l’exception a été levée.
  • entityName : Le nom de l’entité utilisée.
  • pluginName : Le nom du plug-in où l’exception a été levée.

Si un utilisateur signale une erreur, vous pouvez utiliser l’ID utilisateur (ID Microsoft Entra ID) pour comprendre les détails de la table exception.

exceptions
| where user_Id == '00aa00aa-bb11-cc22-dd33-44ee44ee44ee'

L’ID et le nom de l’entité sont disponibles dans customDimensions dans la table dependency.

dependencies
| where type == "SDK Retrieve"

des Forums Aux Questions (FAQ) ;

Voici quelques questions fréquemment posées concernant les événements de télémétrie pour Dataverse.

Comment puis-je déterminer si la mise à niveau de mon plug-in a causé une dégradation des performances ?

dependencies
| where ['type'] == "Plugin"
| where name startswith "[InsertYourPluginName]"
| summarize avg(duration) by name

Le nom du plug-in doit également contenir la version des plug-ins personnalisés.

Comment l’API fonctionnait-elle avant un problème signalé, en fonction de l’heure de la journée ou du lieu ? La dégradation de l’API a-t-elle été progressive ou soudaine ?

requests
| where url == "https://<URLHere>"
| summarize avg(duration), count() by bin(timestamp, 1h)
| render timechart 

Dans ce graphique, nous pouvons voir les performances du point de terminaison de l’API sur une période de temps par rapport au nombre de requêtes effectuées.

Vous pouvez aussi configurer une alerte basée sur les performances d’une API particulière ici au sein de Application Insights.

Puis-je explorer en détail les erreurs ou les échecs à des moments spécifiques ou pour des utilisateurs spécifiques afin de permettre de comprendre la pile d’appels ?

Le volet Échecs donne un aperçu des défaillances sur une période de temps donnée. Vous pouvez ensuite filtrer sur un échec spécifique en fonction de l’appel d’API ou du type de dépendance pour obtenir la vue de bout en bout.

Puis-je créer des tableaux de bord personnalisés ?

Oui. Vous pouvez créer des tableaux de bord personnalisés avec Application Insights.

Puis-je déterminer les performances d’utilisation du plug-in (temps de réponse) et les taux d’échec lors des pics d’utilisation ?

Oui. Consultez l’exemple de requête suivant pour comprendre les performances de vos plug-ins.

dependencies
| where ['type'] == "Plugin"
| where name == "[Plugin name here]"
| summarize avg(duration) by bin(timestamp, 1h)
| render timechart

Cette télémétrie aura-t-elle une limitation ?

Oui. Les détails de base de l’erreur 429 sont actuellement fournis.

Puis-je comprendre les chemins d’exécution ? Les appels passés par le plug-in ralentissent-ils le plug-in ?

Oui. Vous pouvez afficher tous les messages et plug-ins exécutés pour toute demande.

La durée d’exécution de tous les messages et plug-ins est consignée. Si un plug-in prend plus de temps, vous pouvez identifier ce plug-in. Si le plug-in effectue un rappel à Dataverse, la durée de cet appel est enregistrée. Plus d’informations sur les plug-ins sont prévues pour un déploiement futur.

Tout appel sortant effectué par le plug-in sera automatiquement enregistré en tant que dépendance.

Puis-je afficher les données de télémétrie pour une demande spécifique ?

Dataverse renvoie x-ms-service-requestId dans la réponse d’en-tête à toutes les demandes. En utilisant ce requestId, vous pouvez interroger toutes les données de télémétrie.

union *
| where operation_ParentId contains <requestId>