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, die die Geschichte tragen, 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 trägt 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.

Welche Ereignis-IDs tragen die Geschichte?

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. Das ergibt tägliche, wöchentliche und monatliche aktive Benutzer.

Mit RT0030 finden Sie den Schmerz. 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 es wert sind

Wer nutzt diese Umgebung, und ändert sich das? RT0004, 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, der nicht suchen kann. 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, der der Prozess gehört.

Wer ruft uns auf und wie stark? 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.

Nehmen Sie sich für beides eine Gewohnheit vor: schauen Sie immer auf den Zeitraum. Die Vorgaben 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 braucht kein Schreiben von Abfragen.

Fragen Sie einen Assistenten, der das KQL für Sie ausführt. Ein Werkzeug, das Ihren Application-Insights-Arbeitsbereich liest, kann in normaler Sprache 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 einen rohen Eigenschaftenbeutel 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 eine Benutzerin 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.