Following our previous article regarding D365 Finance & Operations monitoring and Telemetry using application insights, let’s have a quick look at patterns and antipatterns. The guidance would be as follows:
- Design for insights into business process performance. The main goal of application insights should be for you to understand (as a company) how to get insights on business operations flow. It should contribute to providing insights into end-to-end process flow, mainly things like how many invoices are being processed on average during a certain timeframe; whether the number of invoices has been increased over a month; etc.
- Replace any custom login in your applications. Due to the lack of insights from MS products, we often see that organizations build solutions that keep a lot of logging data into their own custom tables. It also contributes to the overall storage consumption (a lot of unnecessary weight on the databases is also included).
- Design for cost efficiency – when teams start using application insights and feeding data into it, they oftentimes don’t think about whether they are having a heavy batch workload with a lot of looping in there. Hence, make sure you use different sampling techniques to be cost-efficient and scalable with telemetry.
Let’s also highlight some of the anti-patterns:
- Do not use Application Insights for purely infrastructure monitoring. The reason is the X++ runtime is not suited or at least not responsible to provide insights into SQL infrastructure. We have different telemetry for that and it would only put additional pressure on the environment in the private preview.
- Don’t use Application Insights for auditing purposes. Application Insights is designed for performance and minimum impact. This means the service might throttle or apply to the sample if the dataset becomes too large.
When using metrics, use aggregation and avoid using variables in the metric name. Application Insights uses different metric for each of the values and this easily hit the maximum number of available metrics. Also, in heavy processes, avoid logging metrics in a high-volume loop and apply aggregation in your logic.