Expertises et services, Solutions
Télémétrie Business Central : paramétrage et bonnes pratiques
08/09/2022
La télémétrie Business Central améliore considérablement l’expérience globale des administrateurs de l’ERP Microsoft Dynamics 365 Business Central. Grâce aux données de télémétrie émises par Business Central, il est possible d’apporter un support technique qui va plus loin que le dépannage traditionnel (que nous connaissons depuis longtemps pour Microsoft Dynamics NAV et Business Central).
Avec la télémétrie Business Central, non seulement la résolution des erreurs se fait de manière plus efficace et plus rapide, mais aussi, et surtout, le traitement de cette télémesure permet de surveiller la sécurité, d’évaluer l’état de santé du progiciel, de monitorer la qualité et de suivre la performance de l’installation.
- Qu’est-ce que la télémétrie ?
- 5 bénéfices de la télémétrie pour Business Central
- Comment utiliser la télémétrie sous Azure ?
- Comment traiter le dataset télémétrique avec le Kusto Query Langage (KQL) ?
- Comment mettre en place l’app Power BI pour analyser la télémétrie ?
- 2 types d’usage de la télémétrie Business Central
- 3 règles d’usage pour Application Insights
Qu’est-ce que la télémétrie ?
La télémétrie ou télémesure est une technique permettant d'obtenir à distance des valeurs de mesures effectuées dans des installations techniques. Par extension, une télémesure désigne l'une de ces mesures à distance. - Wikipédia, Télémesure
Qu’est-ce que la télémétrie Microsoft Dynamics 365 Business Central ?
Business Central émet des données télémétriques pour les diverses activités et opérations réalisées sur les environnements Business Central. Nous allons voir comment centraliser ces données, les traiter puis les afficher sur une interface, afin d’avoir un aperçu de l’état de nos tenants en temps réel.
5 bénéfices de la télémétrie pour Business Central
Si nous rentrons dans les détails techniques, la télémétrie Business Central permet de :
- Récupérer des signaux relatifs aux instances Business Central (SaaS ou On Premise)
- Stocker ces signaux pour les analyser (dans une ressource Azure Application Insight)
- Analyser ces signaux au travers de différents outils (Jupyter Notebook, TroubleShooting Guide, PowerBI, etc.) ou faire des interrogations ad-hoc (en langage KQL).
À la suite de cette étude, il est donc possible d’avoir une vue d’ensemble sur l’état de fonctionnement d’un ou plusieurs environnements Business Central. Dans la suite de cet article, nous verrons qu’il est également possible d’isoler des ralentissements ou des erreurs présentes sur les tenants, et de récupérer des informations essentielles à sa correction.
Suite à la mise en place d’une solution d’analyse de télémétrie chez l’un de nos clients, nous avons pu constater très rapidement les bénéfices de cette approche : des problèmes de performance ont pu être résolus grâce aux signaux remontés (et surtout grâce au niveau de détail de la télémétrie), nous évitant de devoir recourir à de longues et fastidieuses analyses.
Voyons maintenant comment mettre en œuvre la télémétrie Business Central.
Comment utiliser la télémétrie sous Azure ?
La solution Azure Monitor
Pour pouvoir mettre en place la télémétrie sur un ou plusieurs environnements Business Central, nous allons utiliser la suite Azure, et plus précisément, Azure Monitor. Il s’agit d’une solution qui nous permet de collecter, analyser et afficher des données télémétriques. Cette solution englobe un grand nombre de fonctionnalités, mais nous nous focaliserons sur les suivantes :
Paramétrer Application Insights dans l'environnement Business Central
Le paramétrage d’Application Insights sur un environnement Business Central s’effectue rapidement et simplement. Il suffit de suivre les étapes énoncées dans la documentation Microsoft.
Composition d’un signal télémétrique
Il existe différents types de signaux (ou d’évènements) remontés dans la télémétrie Busines Central.
Un signal est composé de plusieurs informations : certaines statiques, d’autres dynamiques comme les "custom dimensions" dont le contenu s’adapte en fonction du type de signal (EventID).
- Verbosity : Les différentes valeurs de sévérité nous permettent de classer les signaux reçus par ordre d’importance. Par exemple, un signal d’authentification réussi d’un utilisateur sur Business Central sera de sévérité "normal" ; alors qu’un signal pour un blocage de la base de données sera "critical".
- DataClassification : Cela nous donne l’origine du signal reçu. Par exemple, "Customer Content" est une donnée émise par un utilisateur depuis Business Central.
- Custom Dimensions : Il s’agit d’un ensemble d’attributs spécifiques au signal télémétrique reçu. On peut y retrouver par exemple le type d’environnement, son nom et la provenance du signal. Nous y trouvons une donnée très intéressante (entre autres) : la StackTrace. Il s’agit de la pile d’appels enregistrée au moment de l’erreur ou du ralentissement constaté (cette information permet de contextualiser rapidement le problème remonté).
Processus de récupération des données télémétriques
Émettre un signal personnalisé depuis une extension Business Central
En plus de la télémétrie standard, les partenaires peuvent ajouter des signaux personnalisés pour monitorer des processus spécifiques et/ou critiques (afin de remonter des temps d’exécution, le nombre d’occurrences, etc.). Ces signaux comportent les mêmes attributs que ceux nativement renvoyés (cf. composition d’un signal télémétrique). Nous pouvons définir la composition des "custom dimensions" renvoyées pour subvenir à tout type de besoin d’analyse.
Comment traiter le dataset télémétrique avec le Kusto Query Langage (KQL) ?
Désormais, nous savons comment est structuré un signal récupéré par notre ressource Azure Application insights. Nous pouvons donc requêter notre base de données distante Microsoft contenant nos signaux télémétriques pour les traiter.
Nous ne rentrerons pas en détail dans la composition des requêtes, ni des fonctionnalités offertes par KQL. Cependant, il faut savoir que ce langage a été développé par Microsoft pour les Data Scientist afin d'explorer des données de forte volumétrie (Data Lake, etc.…), identifier les anomalies et les valeurs hors norme, créer une modélisation statistique, et bien plus encore (à la différence du langage SQL qui permet de lire, mais aussi de modifier des données ou même le schéma de base de données en lui-même).
Ce qu’il faut retenir du KQL : ce langage de requêtage est similaire au SQL dans sa structuration. Grâce aux requêtes réalisées, vous pouvez extraire les informations importantes concernant des soucis de performances ou des erreurs survenues sur les environnements Business Central. Le KQL permet d’interroger les datasets collectés automatiquement. Il est aussi possible d’agréger des requêtes KQL dans des Workbook pour créer des tableaux de bord exposant des indicateurs, des graphiques, etc.
Exemple de requête KQL exécutée depuis une ressource App Insight :
Et voici un exemple de résultat d’une requête obtenue sur un Workbook. Cette dernière répertorie les opérations ayant dépassé le temps d’exécution maximum :
Comment mettre en place l’app Power BI pour analyser la télémétrie ?
Aujourd’hui, la voie royale pour analyser la télémétrie est l’utilisation de Microsoft Power BI avec l’application Power BI Dynamics 365 Business Central Usage Analytics.
Dans ce contexte, Power BI permet d’analyser la télémétrie des environnements Dynamics 365 Business Central, en utilisant des tableaux de bord standard. Une fois déployé, il est possible de :
- Créer un rapport type proposé par Microsoft, cela permet d’avoir un aperçu, monitoré, sur les données télémétriques concernant :
- L’utilisation de l’environnement Business Central (nombre de sessions ouvertes, types de clients, etc.)
- Les changements effectués (ajouts, updates et suppressions d’extensions, de sociétés, etc.)
- Les erreurs (erreurs de login, erreurs système, etc.)
- Les performances (requête SQL trop longue, code AL non optimisé, exécution des job queue, envoi/réception de mails, génération de report, etc.).
- Modifier et personnaliser ce rapport type en fonction de vos besoins
- Créer un nouveau rapport vierge à construire de A à Z sur la base des données collectées.
2 types d’usage de la télémétrie Business Central
En connaissant le principe de la télémétrie Business Central, son fonctionnement ainsi que sa mise en place, nous pouvons en dégager deux types d’usage :
Permanent
Pour le client/partenaire souhaitant avoir une analyse permanente de ses environnements Business Central, afin d’être proactif sur le suivi de sa solution.
Plug & Play
Mise en place occasionnelle pour aider à la correction d’un problème, d’un ralentissement ou d’une erreur, constatés par le client/partenaire.
3 règles d’usage pour Application Insights
Il existe quelques règles d’usage pour la ressource Azure Application Insights :
- Paiement à l’utilisation en fonction du volume de données ingéré par la ressource
- La limite de données à ingérer quotidiennement est fixée initialement à 100 Go. Toutefois, il est possible d’augmenter cette limite jusqu’à 500 Go par jour.
- Il est également possible de gérer la durée de rétention des données collectées par notre ressource Application Insights.
L’exploitation de la télémétrie Business Central apporte une réelle valeur ajoutée aux administrateurs de la solution, leur permettant de faire entrer tous les acteurs dans un cercle vertueux. L’ERP étant une pierre angulaire d’un système d’information de plus en plus intégré et complexe, il était nécessaire de pouvoir le mettre sous écoute… C’est maintenant possible, et surtout indispensable ! Notre équipe d'experts se tient à votre disposition pour échanger sur la télémétrie BC.
Tags
