Business Central telemetry. Analyze performance using a Power BI report.
Business Central emits telemetry data for various activities and operations
on tenants and extensions.
Monitoring telemetry gives you insight into activities and the health
of your tenants,
so you could diagnose problems and analyze operations that affect
performance.
This video shows how to use a standard Power BI
report to analyze performance with telemetry.
The report is available from the Business Central telemetry samples
GitHub repository.
We'll download the report, get an application ID from Azure
Application Insights,
and then we'll explore the performance report in Power BI Desktop.
Prerequisites for using the report is to have enabled telemetry
on one or more Business Central environments or extensions, and
access to the Azure Applications Insight Resource that stores the
data. We'll also need Power BI desktop.
Let's start by downloading the report.
Will open a browser and type
aka.ms/bctelemetrysamples to open the BC Tech repository.
Now we'll choose the Power BI directory,
then Reports, and then Performance Report.
To download the report we'll choose Download.
We'll open the report to start configuring it.
We need an application ID from the Azure Application Insights
resource that stores the telemetry data.
We need the key so that we can read data
from Azure Application Insights.
On the Application Insights page in the Azure Portal, under
Configure on the Navigation Pane we'll choose API Access,
and then use the Copy to clipboard action to copy
the application ID.
Now we'll open the performance report Power BI file we downloaded.
We'll paste the Azure Application Insights application ID in the
ID field, and then define the period of time we
want to analyze by specifying start and end dates.
We can also add an AAD tenant ID and an
environment name as additional filters.
Especially for extension telemetry, sometimes it's useful to leave these
fields blank if we have enabled Azure Application Insights for
multiple environments.
If we have a lot of data and just want
to experiment,
we might consider using the Top parameter to limit the
number of rows that each data source in the report
will fetch from Azure Application Insights.
When we choose Load, the report will refresh with data.
This could take a few minutes, depending on the amount
of data we have.
Authentication from Power BI to Application Insights only works if
both resources belong to the same AAD tenant ID,
the organizational account.
OK, here's our report. Let's start with the ReadMe tab.
There are two things that are especially important to notice.
First, there's guidance on the difference between the Power BI
report and the Jupyter notebooks for troubleshooting.
The performance report is useful when we don't know exactly
what we're looking for and need to slice and dice
the data to find performance bottlenecks.
Second, depending on our version of Business Central,
we might not have data for every tab in the
report.
There's a link to the Signal Overview page, where we
can find out when different types of signals were added
to Business Central.
Now let's dive into the performance data.
The Sessions and OpenCompany tabs give us an overview
of session creation,
count, and performance. We can identify the type of client
that opens a session by filtering on Client Type.
A typical cause of performance issues is frequent calls to
web service endpoints on the Business Central environment.
For example, if we have thousands of calls per date
on the Sessions tab,
we might want to reduce our web service calls.
While the Sessions tab shows the count of sessions being
created,
the OpenCompany tab shows how well the code running
in the onOpenCompany trigger is performing.
This code runs every time a session is created and
should normally complete in less than a few seconds.
If the graph shows spikes of 10 seconds or more,
we should probably investigate whether extensions are running slow
AL code in the trigger and try to remove the
bottleneck.
The Long Running SQL Queries tab helps us investigate AL
code that results in operations that take a long time
to run on the database.
We can go from an AL call stack to see
which SQL statements took a long time to run,
as well as information about the number of joins in
the SQL statements, and how many SIFT indexes.
We can also sort on expensive SQL statements to identify
AL code that can be optimized.
The former search pattern is great if we already know
that a particular page is slow, while the latter is
useful if we're looking for the top 10 performance bottlenecks
in the Business Central database.
Database locks are often a root cause of performance problems.
While long running SQL queries measure how long it takes
the queries to run in the database,
database lock timeouts identify situations where a user waited too
long for a lock to be released and was shown
an error that indicates that a record in the table
was locked by another user.
Like the Long Running SQL Queries tab,
we can go from the AL call stack to the
SQL statement,
or go from the SQL statement to see the AL
call stack.
The next tab will explore is Long Running AL Methods.
Here we get statistics on time spent running AL inside
the Business Central server,
excluding time spent in the database.
Two good ways to use this part of the report
are either to choose an objects to see the slow
methods, or to filter or sort on methods to find
the top 10 slowest.
When we identify a slow method,
we can go directly to the telemetry to get the
AL call stack to find out where the method is
run in the code.
We talked about web service calls when we explored the
Sessions tab. On the Incoming Web Service Calls tab
we can go deeper into web service endpoint performance.
We can go from an endpoint to the code unit
behind it, or from a code unit to the endpoints
that use it.
An important part of this report is the Category filter,
where we can see which protocols are used.
We should try to use API pages and move away
from Odata v3 and SOAP.
Outgoing web service calls are tracked in telemetry when we
use the HTTP client module in AL to call external
services.
Especially for UI sessions, it's important to check the performance
of these external calls because running AL is blocked in
the server while it waits for an answer from an
external service. The Reports tab shows the performance of reports.
For each report
we can see how many times it was run,
the number of SQL statements,
and how many rows were fetched.
The ratio of these numbers can tell us how "set
based" the code behind the report is.
We can use the Client Type filter at the top
of the report to determine whether users are running reports
from the request page or scheduling them.
Using the request page forces users to wait for the
result,
so scheduling might improve perceived performance.
Finally, the Page Views tab shows the time it takes
to render pages in the modern client.
You can use this to identify the top 10 pages
to improve.
You can also use filters to analyze whether people are
using old browser versions that have known performance issues.
And that's it. To learn more about Power BI reports
based on telemetry in Azure Application Insights, visit
aka.ms/
bctelemetrysamples. You'll find links to sample reports,
an additional information about how to connect Power BI to
telemetry in Azure Application Insights.
If you're interested in learning more about Business
Central and telemetry, there are a few additional videos available
on this playlist.
There's one that shows how to get started with Application
Insights.
One that shows how to triage errors using a standard
Power BI report.
One about writing your own queries in Kusto.
And one about troubleshooting using Jupiter notebook guides.
Thanks for watching.