Azure Application Insights – Économisez grâce à cette optimisation simple

Discutons d’Azure Application Insights et de l’optimisation simple que nous pouvons faire pour éviter les factures surprises.

Azure Application Insights peut être utilisé pour surveiller et vérifier la santé de nos applications, analyser les journaux et autres mesures liées à notre application, et afficher d’autres ressources incluses dans notre abonnement Azure. Avec une variété de fonctionnalités, de nombreuses équipes peuvent avoir des objectifs différents lors de l’utilisation d’Application Insights. Bien que nous n’utilisions peut-être pas toutes les fonctionnalités disponibles avec Application Insights, nous les utilisons au minimum pour la journalisation.

Si vous me demandez, « L’exploitation forestière est un art. »

Pour que les équipes d’application comprennent les problèmes qui se produisent en production, quelle quantité d’informations consignées est nécessaire ? Il n’y a pas de formule unique ou de définition concrète, mais au minimum, un journal doit pouvoir indiquer l’opération, l’action, les détails du client consommant l’opération et d’autres informations de demande et de réponse avec des informations critiques masquées. Si nous disposons de ces informations, les équipes d’application devraient être en mesure de reproduire les problèmes dans leurs environnements de test.

Souvent, les journaux permettent de comprendre ce qui se serait passé lorsque l’exécution a échoué. Cela ne sert à rien si nous enregistrons simplement les exceptions avec une énorme trace de pile sans prendre en charge les informations sur ce qui s’est passé avant l’exception.

En général, il est bon d’utiliser différentes stratégies de journalisation en fonction du type de journal.

• Sommes-nous en train de nous connecter pour capturer des états cruciaux de transaction ?
• Sommes-nous en train de nous connecter pour capturer les erreurs transitoires telles que les problèmes de connectivité, les problèmes d’authentification ?
• Consignons-nous des informations pour capturer les étapes du flux de travail de l’application ?

La journalisation est souvent négligée lorsque nous effectuons des migrations d’applications vers le Cloud. La prochaine fois que nous essaierons d’effectuer une migration d’application, il est bon de penser à la stratégie de journalisation qui est en place.

Par exemple, considérez le scénario suivant. Supposons que nous ayons un travail qui traite des informations lorsque des enregistrements apparaissent dans la base de données. En général, le travail interroge la base de données toutes les 5 minutes pour rechercher des données qui satisfont à une condition spécifique. Lorsque de nouveaux enregistrements sont présents, le travail se poursuivra, extraira les nouvelles données et commencera le traitement. Dans ce processus, le travail émettrait des journaux d’informations qui sont stockés dans le système de fichiers sous forme de fichiers texte ou stockés dans une base de données. Lorsque tout le processus est terminé, le travail met à jour le statut des enregistrements dans la base de données afin que ces enregistrements ne soient pas pris en compte lors de la prochaine itération. Si tout se passe bien, cette approche fonctionne bien.

Désormais, lorsque nous transférons cette application vers le cloud et que nous commençons à utiliser Azure Application Insights, ces journaux sont capturés dans Application Insights. Considérons maintenant un scénario dans lequel les travaux ne parviennent pas à traiter les données. Par exemple, supposons qu’il y avait de mauvaises données. Le travail de chaque exécution échouerait et ne serait pas en mesure de mettre à jour le statut des enregistrements à terminer. À chaque exécution, le travail tentera de traiter les mauvaises données. Le travail émettrait des journaux avec le message d’erreur en continu pour chaque exécution.

Nous savons que le travail recherche de nouvelles données toutes les 5 minutes. Ces erreurs finissent par se retrouver dans nos Application Insights. Supposons donc qu’il y ait environ 10 enregistrements avec de mauvaises données et que toutes les 5 minutes, le travail émette des journaux avec des erreurs et d’autres journaux d’informations dans nos Application Insights qui sont capturés à l’aide de l’option de télémétrie du SDK AppInsights.

Selon Tarifs Azure Monitor « Log Analytics et Application Insights facturent les données qu’ils ingèrent. »

Finalement, nos Application Insights ingèreront beaucoup de messages d’exception et il y aura beaucoup de bruit. S’ils ne sont pas remarqués, ces journaux remplissent Application Insights, et nous finirions par payer pour le bruit.

Alors comment éviter de telles situations ?

Afin d’éviter de telles situations, il est toujours bon de mettre en place un Modèle de disjoncteur avec l’option de réessayer. Supposons que nous définissions le seuil du modèle de nouvelle tentative sur 3. Lorsque nos tâches tentent de traiter des enregistrements et qu’elles échouent en continu 3 fois, la tâche marquera les enregistrements comme ayant échoué lors des exécutions suivantes. De cette façon, nous pouvons éviter d’envoyer des données à nos Application Insights et nous pourrions économiser des montants qui refléteraient éventuellement d’énormes économies.

En effectuant de petites optimisations comme celles-ci, nous ne verrons pas l’impact immédiatement, mais dans l’ensemble, nous réaliserons les avantages.

Quelles sont les quelques optimisations que vous avez essayées pour réduire les coûts avec vos applications dans Azure ? N’hésitez pas à commenter.