Læs telemetri fra Business Central uden KQL

Business Central udsender en stor mængde telemetri, og næsten ingen læser den. Grunden er ikke ligegyldighed. Grunden er, at data kommer som KQL-forespørgsler mod et Application Insights-arbejdsområde, og de fleste, der har brug for svarene, skriver ikke KQL.

Det behøver I ikke. Denne side giver de hændelses-id'er, der bærer historien, hvad hvert enkelt betyder, og de spørgsmål, I kan besvare, når I kender dem.

Hvor havner telemetri fra Business Central?

I den Application Insights-ressource, I kobler til miljøet. Business Central skriver signaler dertil som traces, hver med et hændelses-id og et sæt dimensioner.

Hændelses-id'et er hele navigationssystemet. Microsoft udgiver den fulde liste, og når I kender seks af dem, kan I besvare de fleste driftsspørgsmål.

Hvilke hændelses-id'er bærer historien?

Her er id'erne og beskrivelserne fra Microsofts egen tabel.

To af dem er mere nyttige, end navnet lader ane.

RT0004 er måden at tælle brug på. Der findes ingen hændelse for "session". I tæller vellykkede godkendelser til at åbne et firma, grupperet på bruger og dag. Det giver daglige, ugentlige og månedlige aktive brugere.

RT0030 er måden at finde ud af, hvor det gør ondt. Den registrerer de fejldialoger, brugerne faktisk så. Ikke undtagelserne i en log, men dialogerne foran et menneske. At rangere RT0030 på besked og antal giver den korteste liste over virkelige problemer, et Business Central-miljø kan give jer.

De fem spørgsmål, der er værd at stille

Hvem bruger dette miljø, og ændrer det sig? RT0004 grupperet på bruger og dag. Sammenlign den aktuelle periode med den foregående. Et fald efter en opdatering er det signal, I gerne vil se hurtigt.

Hvad er langsomt, og er det SQL eller AL? RT0005 og RT0018 sammen. Opdelingen betyder noget. En langsom SQL-forespørgsel skyldes som regel et manglende indeks eller et filter, der ikke kan søge. En langsom AL-metode er som regel en løkke, der burde have været en forespørgsel.

Hvad fejler foran folk? RT0030 rangeret på besked. Tag derefter de tre øverste med til den, der ejer processen.

Hvem kalder os, og hvor hårdt? RT0008 for indgående og RT0019 for udgående, grupperet på endepunkt. En integration, der stilfærdigt tredoblede sit antal kald, dukker op her, før den dukker op i en klage.

Virkede den seneste opdatering af udvidelser? LC00xx-parrene. LC0021 og LC0023 er dem, I skal have en alarm på, for en mislykket kompilering eller en mislykket opdatering er en fejl, I vil høre om fra telemetri og ikke fra en bruger.

De KQL-grænser, der overrasker folk

To af dem koster en eftermiddag hver.

Log Analytics har ingen percentileif. I får brug for den med det samme, for det naturlige spørgsmål er "95-percentilen for varigheden af netop denne handling". Masker rækkerne først med iff, og brug derefter percentile på den maskerede kolonne.

Dimensionerne er tekst. Varigheder, antal rækker og alle andre tal kommer som tekst. Konverter, før I sammenligner, ellers sammenligner et filter på en varighed tekststrenge og giver i stilhed de forkerte rækker.

Tilføj én vane til begge dele: se altid på tidsintervallet. Standardindstillinger i Application Insights kan stilfærdigt begrænse det, I forespørger på, og en forespørgsel, der intet giver, er oftere et problem med intervallet end med data.

Hvordan læser I det uden at skrive KQL?

Tre veje med stigende indsats.

Brug Power BI-appen til Business Central-telemetri. Den dækker de almindelige spørgsmål og kræver ingen forespørgsler.

Spørg en assistent, der kører KQL'en for jer. Et værktøj, der læser jeres Application Insights-arbejdsområde, kan svare i almindeligt sprog, hvis det gør to ting: det viser jer den KQL, det kørte, og det forklarer hvert hændelses-id i stedet for at give jer en rå samling af egenskaber. Et hændelses-id uden en forklaring er ikke et svar, det er en opslagsopgave.

Lær seks forespørgsler. Skriver I KQL to gange om året, så lær de fem spørgsmål ovenfor som fem gemte forespørgsler, og stop der. Værdien af den syvende forespørgsel er lav.

Hvad telemetri ikke fortæller jer

Den fortæller ikke hvorfor. RT0005 fortæller, at en forespørgsel overskred grænsen. Den fortæller ikke, at en bruger byggede et filter på et felt uden indeks, fordi siden ikke tilbyder det rigtige.

Den fortæller ikke om det arbejde, der ikke blev udført. En udvidelse, der gør en proces så langsom, at folk holder op med at bruge den, viser sig som mindre telemetri, ikke som mere.

Og den nævner ikke den forretningsmæssige konsekvens. En mislykket bogføring er én række her og et problem ved månedsafslutningen der. Telemetri peger på handlingen. Et menneske skal stadig koble den til processen.

Det er den rigtige arbejdsdeling. Telemetri indsnævrer et spørgsmål fra hele miljøet til én handling, én udvidelse og én time. Resten er konsulentarbejde, og det er meget billigere, når søgningen er slut.