Business-Central-Telemetrie ohne KQL lesen

Business Central sendet eine große Menge Telemetrie, und fast niemand liest sie. Der Grund ist nicht Gleichgültigkeit. Der Grund ist, dass die Daten als KQL-Abfragen über einen Application-Insights-Arbeitsbereich ankommen, und die meisten Menschen, die die Antworten brauchen, schreiben kein KQL.

Sie müssen es nicht. Diese Seite nennt die Ereignis-IDs, auf die es ankommt, was jede davon bedeutet und die Fragen, die Sie beantworten können, sobald Sie sie kennen.

Wohin geht die Telemetrie von Business Central?

In die Application-Insights-Ressource, die Sie mit der Umgebung verbinden. Business Central schreibt dort Signale als Traces, und jedes hat eine Ereignis-ID und einen Satz eigener Dimensionen.

Die Ereignis-ID ist das ganze Navigationssystem. Microsoft veröffentlicht die vollständige Liste, und sobald Sie sechs davon kennen, können Sie die meisten betrieblichen Fragen beantworten.

Auf welche Ereignis-IDs kommt es an?

Das sind die Bezeichner und die Beschreibungen aus Microsofts eigener Tabelle.

Zwei davon sind nützlicher, als ihre Namen vermuten lassen.

Mit RT0004 zählen Sie die Nutzung. Es gibt kein Ereignis für eine „Sitzung“. Sie zählen erfolgreiche Autorisierungen zum Öffnen eines Mandanten, gruppiert nach Benutzer und Tag. Filtern Sie zuerst auf die Dimension clientType und behalten Sie die interaktiven Clients: WebClient, Phone, Tablet und Desktop. Hintergrundsitzungen, Aufgabenwarteschlangen-Läufe und Webdienstaufrufe öffnen ebenfalls einen Mandanten, und ohne den Filter zählt eine Integration als fleißiger Benutzer. Das ergibt tägliche, wöchentliche und monatliche aktive Benutzer.

Mit RT0030 finden Sie, wo es wehtut. Es hält die Fehlerdialoge fest, die die Benutzer wirklich gesehen haben. Nicht die Ausnahmen in einem Protokoll, sondern die Dialoge vor einem Menschen. RT0030 nach Meldung und Anzahl zu sortieren ergibt die kürzeste Liste echter Probleme, die eine Business-Central-Umgebung Ihnen geben kann.

Die fünf Fragen, die sich lohnen

Wer nutzt diese Umgebung, und ändert sich das? RT0004 für interaktive Clients, gruppiert nach Benutzer und Tag. Vergleichen Sie den aktuellen Zeitraum mit dem davor. Ein Einbruch nach einem Update ist das Signal, das Sie schnell sehen wollen.

Was ist langsam, und ist es SQL oder AL? RT0005 und RT0018 zusammen. Die Aufteilung zählt. Eine langsame SQL-Abfrage ist meist ein fehlender Index oder ein Filter ohne Indexunterstützung. Eine langsame AL-Methode ist meist eine Schleife, die eine Abfrage hätte sein sollen.

Was scheitert vor den Augen von Menschen? RT0030, sortiert nach Meldung. Bringen Sie dann die ersten drei zu der Person, die für den Prozess verantwortlich ist.

Wer ruft uns auf und wie oft? RT0008 für eingehende und RT0019 für ausgehende Aufrufe, gruppiert nach Endpunkt. Eine Integration, die ihre Aufrufrate still verdreifacht hat, erscheint hier, bevor sie in einer Beschwerde erscheint.

Hat das letzte Erweiterungsupdate funktioniert? Die LC00xx-Paare. LC0021 und LC0023 sind die, auf die Sie eine Warnung legen sollten, denn eine fehlgeschlagene Kompilierung oder ein fehlgeschlagenes Update ist ein Fehler, von dem Sie aus der Telemetrie erfahren wollen, nicht von einem Benutzer.

Die KQL-Grenzen, die Menschen überraschen

Zwei davon kosten je einen Nachmittag.

Log Analytics hat kein percentileif. Sie werden es sofort wollen, denn die natürliche Frage ist „das 95. Perzentil der Dauer für diesen einen Vorgang“. Maskieren Sie die Zeilen zuerst mit iff und wenden Sie dann percentile auf die maskierte Spalte an.

Eigene Dimensionen sind Zeichenketten. Dauern, Zeilenanzahlen und jede andere Zahl kommen als Text an. Wandeln Sie um, bevor Sie vergleichen, sonst vergleicht ein Filter auf eine Dauer Zeichenketten und gibt still die falschen Zeilen zurück.

Gewöhnen Sie sich dazu eines an: Prüfen Sie immer den Zeitraum. Die Standardeinstellungen von Application Insights können still einschränken, was Sie abfragen, und eine Abfrage, die nichts zurückgibt, hat häufiger ein Problem mit dem Zeitraum als mit den Daten.

Wie Sie es lesen, ohne KQL zu schreiben

Drei Wege, mit steigendem Aufwand.

Nutzen Sie die Power-BI-App für Business-Central-Telemetrie. Sie deckt die üblichen Fragen ab und Sie müssen keine Abfragen schreiben.

Fragen Sie einen Assistenten, der das KQL für Sie ausführt. Ein Werkzeug, das Ihren Application-Insights-Arbeitsbereich liest, kann in eigenen Worten antworten, sofern es zwei Dinge tut: Es zeigt Ihnen das KQL, das es ausgeführt hat, und es erklärt jede Ereignis-ID, statt Ihnen eine rohe Eigenschaftenliste (Property Bag) zu überreichen. Eine Ereignis-ID ohne Erklärung ist keine Antwort, sie ist eine Nachschlageaufgabe.

Lernen Sie sechs Abfragen. Wenn Sie zweimal im Jahr KQL schreiben, lernen Sie die fünf Fragen von oben als fünf gespeicherte Abfragen und hören Sie dort auf. Der Grenznutzen der siebten Abfrage ist gering.

Was die Telemetrie Ihnen nicht sagt

Sie sagt Ihnen nicht, warum. RT0005 sagt Ihnen, dass eine Abfrage die Schwelle überschritten hat. Es sagt Ihnen nicht, dass ein Benutzer einen Filter auf ein nicht indiziertes Feld gebaut hat, weil die Seite das richtige nicht anbietet.

Sie sagt Ihnen nichts über die Arbeit, die nicht stattgefunden hat. Eine Erweiterung, die einen Prozess so langsam macht, dass Menschen ihn nicht mehr nutzen, erscheint als weniger Telemetrie, nicht als mehr.

Und sie benennt nicht die geschäftliche Wirkung. Eine fehlgeschlagene Buchung ist hier eine Zeile und dort ein Problem im Monatsabschluss. Die Telemetrie zeigt auf den Vorgang. Ein Mensch muss ihn noch mit dem Prozess verbinden.

Das ist die richtige Arbeitsteilung. Telemetrie verengt eine Frage von der ganzen Umgebung auf einen Vorgang, eine Erweiterung und eine Stunde. Der Rest ist Beratung, und die ist viel günstiger, wenn die Suche abgeschlossen ist.