Telemetrieereignisse für Microsoft Dataverse
Der Datenstrom liefert derzeit Leistungsdaten zu eingehenden Aufrufen von der Dataverse API, Dataverse Plug-In-Ausführungsaufrufen und Dataverse SDK-Aufrufen. Es liefert auch Daten für Fehler im Plug-In und Dataverse SDK-Vorgänge.
Eingehende Dataverse-API-Aufrufe
Das sind Anrufe an die Dataverse API. Sie können von Einheitliche Oberfläche (UCI), dem Legacy-Webclient, benutzerdefinierten Clients, die das SDK verwenden usw. stammen. Sie finden sie in der Tabelle Anfragen von Application Insights, die die folgenden Felder enthält.
Name: Der Typ der Anfrage. Diese fallen in zwei Kategorien:
- Web-API-Anforderung: Eine Anforderung an OData v4 Endpunkt, die häufig von Einheitliche Oberfläche und modernen Clients verwendet wird. Diese Anforderung wird in einen für beide gemeinsamen Vorgang umgewandelt. Die Web-API ist ein „Wrapper“, um das RESTful-ProgrammierModell zu ermöglichen, aber nachdem die Daten empfangen wurden, wird innerhalb des Servers alles gleich. Wenn die Antwort zurückgegeben wird, wird sie in JSON konvertiert, wenn die Anfrage von der Web-API stammt.
- Organisationsserviceanforderung: Eine Anforderung an die Organisations-API Endpunkt, die von SDK-Clients oder dem älteren Webclient verwendet wird.
Dauer: Die Zeit, die der Server benötigt hat, um auf die Anfrage zu antworten.
URL: Die URL, an die der Aufruf erfolgte.
Benutzerdefinierte Abmessungen:
UserAgent: Application Insights füllt das Benutzeragent-Feld automatisch mit PC , da diese Protokolle von einem Server in einem Rechenzentrum gesendet werden. Application Insights lässt nicht zu, dass das Benutzer-Agent-Feld überschrieben wird. Manchmal kann das Feld für den Benutzer-Agenten nicht ausgefüllt werden. Der Benutzer Agent, von dem aus der Anruf getätigt wurde, kann mit folgender Abfrage eingesehen werden:
requests | summarize count() by tostring(customDimensions.userAgent)
Operation_Name: Der lesbare Name der Operation, der in Ansichten angezeigt werden soll, z. B. der End-to-End-Transaktionsansicht.
Dataverse-Plug-In-Ausführungsprotokolle
Diese Protokolle für benutzerdefinierte Plug-Ins, die für einen bestimmten Vorgang ausgeführt werden, finden Sie in der Tabelle Abhängigkeit. Nachfolgend wird eine Beispielabfrage aufgeführt:
dependencies
| where type == "Plugin"
| take 100
- Name/Ziel: Der vollständig qualifizierte Typname für das ausgeführte Plug-In.
- Dauer: Die Zeit, die für die Ausführung des Plug-Ins benötigt wurde.
- Benutzerdefinierte Abmessungen:
- Tiefe: Die aktuelle Tiefe der Ausführung im Aufrufstapel.
- EntityName: Der Name der Entität, auf die das Plug-In einwirkt.
- IsolationType: Ein Wert , der angibt, ob das Plug-In in der Sandbox ausgeführt wird:
- 1: Keine
- 2: Sandbox
- 3: Extern
- PluginName: Der benutzerfreundliche Name des Plug-Ins.
- PluginType: Der Name des Typs des ausgeführten Plug-Ins.
- PluginVersion: Die Version des veröffentlichten Plug-Ins. Die Absicht hier ist, diese Informationen zur Fehlerbehebung bei Versionsupdates verwenden zu können.
- Stufe: Wird den folgenden Werten zugeordnet:
- Vorabüberprüfung = 10
- PreOperation = 20
- PreOperationBeforeExternalPlugins = 15
- PreOperationAfterExternalPlugins = 25
- MainOperation = 30
- PostOperationBeforeExternalPlugins = 35
- PostOperationAfterExternalPlugins = 45
- PostOperation = 40
- PostOperationDeprecated = 50
- StepName: Der Name der SDK-Nachrichtenverarbeitung Schritt. Dies wird normalerweise vom Plug-In-Registrierungstool unter Verwendung von Informationen über PluginName, PluginType, und den Namen des Vorgangsbeispielsweise ErrorMessageTest.ThrowException: Kontoerstellung.
Telemetrie in Ihrem Plug-In-Code
Um zu verstehen, was innerhalb Ihres Plug-In-Codes geschieht, können Sie benutzerdefinierte Telemetriedaten aus Ihrem Plug-In einbinden. Dazu verwenden Sie die Microsoft.Xrm.Sdk.PluginTelemetry.ILogger-Schnittstelle in Ihrem Plug-In-Code, um Telemetriedaten direkt in Ihre Application Insights Ressource zu schreiben. Weitere Informationen: Telemetrie in Ihre Application Insights-Ressource mit ILogger schreiben (Vorschau)
Dataverse SDK-Protokolle
Dies sind Protokolle für SDK-Vorgänge, die als Teil einer eingehenden Anfrage ausgelöst wurden. Diese werden in der Tabelle Abhängigkeit in Application Insights protokolliert, da sie als Abhängigkeiten für die auszuführende Anforderung verfolgt werden. Sie werden durch den Typnamen identifiziert, beginnend mit SDK. Nachfolgend wird eine Beispielabfrage aufgeführt:
dependencies
| where type startswith "SDK"
| take 10
- Typ: Der Typ der ausgelösten SDK-Anforderung. Beispiele sind Retrieve, RetrieveMultiple, FetchXmlToQueryExpression und WhoAmI.
- Name/Ziel: Dies ist der Name der Entität, auf die der SDK-Vorgang abzielt.
- Benutzerdefinierte Abmessungen:
- ClientType: Der Clienttyp, von dem der Anruf kommt. Einige mögliche Werte sind Web, UCIClient und OutlookFull.
- EntityId: Die eindeutige Kennung der verwendeten Entität.
- EntityName: Der Name der verwendeten Entität.
Ausnahmen
Details zu Fehlern bei Plug-In- und SDK-Vorgängen sehen Sie in Application Insights. Die Tabelle Ausnahmen in Application Insights treibt den Bereich Fehler an. Diese Fehlerdetails korrelieren mit den restlichen Ereignissen im Plug-In und SDK-Aufrufen in der End-to-End-Ansicht. Alle verfügbaren Informationen werden nach Möglichkeit Spalten und customDimensions hinzugefügt, wenn es keine genaue Spaltenübereinstimmung gibt.
Sie werden feststellen, dass einige der Felder in der Tabelle Ausnahmen nicht ausgefüllt sind. Dies liegt daran, dass diese Felder nur gesetzt werden können, wenn die Application Insights SDK verwendet wird, um Protokolle aus der Quelle auszugeben. Diese Funktion sammelt Plattformtelemetrie und überträgt sie dann in Application Insights gemäß dem Application Insights-Schema.
exceptions
| take 10
Diese Abfrage gibt alle Attributdetails aus der Tabelle Ausnahme zurück.
- problemId/type: Der Typ der Ausnahme.
- outerMessage: Die Ausnahmemeldung.
- benutzerdefinierteAbmessungen:
- clientType: Der Clienttyp, von dem der Anruf kommt. Einige mögliche Werte sind Web, UCIClient und OutlookFull.
- exceptionSource: Das Plug-In oder zeigen, wo die Ausnahme ausgelöst wurde.
- entityName: Der Name der verwendeten Entität.
- pluginName: Der Name des Plug-Ins, bei dem die Ausnahme ausgelöst wurde.
Wenn ein Benutzer einen Fehler meldet, können Sie die Benutzer-ID (Microsoft Entra ID ID) verwenden, um Details aus der Tabelle Ausnahme zu verstehen.
exceptions
| where user_Id == '12345678-68cd-4e73-908f-126342b36315'
Die Entitäts-ID und der Entitätsname sind verfügbar in customDimensions in der Tabelle Abhängigkeit.
dependencies
| where type == "SDK Retrieve"
Häufig gestellte Fragen (Frequently Asked Questions, FAQs)
Im Folgenden finden Sie einige häufig gestellte Fragen zu Telemetrieereignissen für Dataverse.
Wie kann ich feststellen, ob mein Plug-In-Upgrade eine Leistungseinbuße verursacht hat?
dependencies
| where ['type'] == "Plugin"
| where name startswith "[InsertYourPluginName]"
| summarize avg(duration) by name
Der Plug-In-Name sollte auch die Version für benutzerdefinierte Plug-Ins enthalten.
Wie war die Leistung der API vor einem gemeldeten Problem, basierend auf Tageszeit oder Standort? War der API-Abbau allmählich oder plötzlich?
requests
| where url == "https://<URLHere>"
| summarize avg(duration), count() by bin(timestamp, 1h)
| render timechart
In diesem Diagramm sehen wir die Leistung der API Endpunkt über einen bestimmten Zeitraum im Vergleich zur Anzahl der gestellten Anfragen.
Sie können auch eine Benachrichtigung einrichten basierend auf der Leistung einer bestimmten API hier innerhalb Application Insights.
Kann ich Drilldown ausführen bei Fehlern oder Ausfällen zu bestimmten Zeiten oder für bestimmte Benutzer, um die Aufrufliste zu verstehen?
Ein Blick auf den Bereich Fehler Panel gibt einen Überblick über die Ausfälle in einem bestimmten Zeitraum. Sie können dann basierend auf dem API-Aufruf oder dem Abhängigkeitstyp auf einen bestimmten Fehler eingrenzen, um die End-to-End-Ansicht anzuzeigen.
Kann ich benutzerdefinierte Dashboards erstellen?
Ja Sie können benutzerdefinierte Dashboards mit Application Insights erstellen.
Kann ich die Plug-In-Nutzungsleistung (Antwortzeit) und die Fehlerraten während der Spitzennutzung bestimmen?
Ja Sehen Sie sich die folgende Beispielabfrage an, um die Leistung Ihrer Plug-Ins zu verstehen.
dependencies
| where ['type'] == "Plugin"
| where name == "[Plugin name here]"
| summarize avg(duration) by bin(timestamp, 1h)
| render timechart
Wird diese Telemetrie Drosselung haben?
Ja Derzeit werden grundlegende 429-Fehlerdetails bereitgestellt.
Kann ich Ausführungspfade verstehen? Verlangsamen Aufrufe des Plug-Ins das Plug-In?
Ja Sie können alle Nachrichten und Plug-Ins anzeigen, die für jede Anforderung ausgeführt werden.
Die Dauer aller Nachrichten- und Plug-In-Ausführungen wird protokolliert. Wenn ein Plug-In mehr Zeit benötigt, können Sie dieses Plug-In identifizieren. Wenn das Plug-In einen Rückruf an Dataverse durchführt, wird die Dauer dieses Anrufs protokolliert. Weitere Informationen zu Plug-Ins sind für die zukünftige Bereitstellung geplant.
Jeder ausgehende Anruf des Plug-Ins wird automatisch als Abhängigkeit protokolliert.
Kann ich Telemetriedaten für eine bestimmte Anfrage anzeigen?
Dataverse gibt x-ms-Service-requestId in der Header-Antwort auf alle Anfragen zurück. Mit dieser requestId können Sie alle Telemetriedaten abfragen.
union *
| where operation_ParentId contains <requestId>