Azure Monitor

Conseil

Ce contenu est un extrait du livre électronique, Cloud Native .NET apps for Azure (Architecture d’applications .NET natives cloud pour Azure), disponible dans la documentation .NET ou au format PDF à télécharger gratuitement pour le lire hors connexion.

Télécharger le PDF

Aucun autre fournisseur de cloud n’a de solution de surveillance d’applications cloud aussi mature que celle que vous trouvez dans Azure. Azure Monitor abrite une collection d’outils conçus pour vous donner de la visibilité sur l’état de votre système. Il vous aide à comprendre comment fonctionnent vos services natifs cloud et identifie de façon proactive les problèmes qui les affectent. La figure 7-12 présente une vue globale d’Azure Monitor.

Figure 7-12. Vue globale d’Azure Monitor.

Collecte des journaux et des métriques

La première étape de toute solution de surveillance consiste à collecter autant de données que possible. Plus des données sont collectées, plus les insights sont précis. Les systèmes d’instrumentation ont toujours été difficiles. Le protocole SNMP (Simple Network Management Protocol) était le protocole standard par excellence pour collecter des informations au niveau ordinateur, mais il demandait beaucoup de connaissances et de configurations. Heureusement, une grande partie de ce travail compliqué a disparu parce que les métriques les plus courantes sont collectées automatiquement par Azure Monitor.

Les métriques et les événements au niveau application ne peuvent pas être instrumentés automatiquement, car ils sont spécifiques à l’application en cours de déploiement. Pour collecter ces métriques, des kits SDK et des API sont disponibles pour signaler directement ces informations, par exemple quand un client s’inscrit ou passe une commande. Des exceptions peuvent également être capturées et signalées à Azure Monitor via Application Insights. Les kits SDK prennent en charge la plupart des langages que vous trouvez dans les applications natives cloud, notamment Go, Python, JavaScript et les langages .NET.

L’objectif suprême de la collecte d’informations sur l’état de votre application est de s’assurer que vos utilisateurs finaux ont une bonne expérience. Quelle meilleure façon de savoir si les utilisateurs rencontrent des problèmes que de faire des tests web externes, puis internes ? Ces tests peuvent être aussi simples que de faire un ping sur votre site web à partir de différents endroits du monde ou aussi compliqués qu’avoir des agents qui se connectent au site et simulent des actions utilisateur.

Données de rapport

Une fois les données collectées, elles peuvent être manipulées, synthétisées et représentées dans des graphiques, ce qui permet aux utilisateurs de voir instantanément s’il y a des problèmes. Ces graphiques peuvent être rassemblés dans des tableaux de bord ou dans des workbooks, rapports multipages conçus pour raconter une histoire sur certains aspects du système.

Aucune application moderne ne serait complète sans intelligence artificielle ou machine learning. À cette fin, les données peuvent être transmises aux différents outils de machine learning dans Azure pour vous permettre d’extraire des tendances et des informations qui seraient autrement masquées.

Application Insights fournit un langage de requête (de type SQL) puissant appelé Kusto qui peut interroger des enregistrements, les synthétiser et même les représenter dans des graphiques. Par exemple, la requête suivante localise tous les enregistrements du mois de novembre 2007, les regroupe par état et représente les 10 premiers sous la forme d’un graphique en secteurs.

StormEvents
| where StartTime >= datetime(2007-11-01) and StartTime < datetime(2007-12-01)
| summarize count() by State
| top 10 by count_
| render piechart

La figure 7-13 montre les résultats de cette requête Application Insights.

Figure 7-13. Résultats de requête dans Application Insights.

Il existe un terrain de jeu pour expérimenter les requêtes Kusto. La lecture d’exemples de requêtes peut également être instructive.

Tableaux de bord

Il existe plusieurs technologies de tableau de bord différentes qui peuvent être utilisées pour faire ressortir les informations d’Azure Monitor. La plus simple consiste peut-être à exécuter des requêtes dans Application Insights et à représenter les données dans un graphique.

Figure 7-14. Exemple de graphiques Application Insights incorporés dans le tableau de bord Azure principal.

Ces graphiques peuvent ensuite être incorporés dans le portail Azure en utilisant la fonctionnalité de tableau de bord. Pour les utilisateurs avec des besoins plus contraignants, comme la capacité à explorer plusieurs niveaux des données, les données Azure Monitor sont disponibles dans Power BI. Power BI est un outil de décisionnel de classe entreprise leader du secteur, qui peut agréger des données à partir d’un grand nombre de sources de données différentes.

Figure 7-15. Exemple de tableau de bord Power BI.

Alertes

Parfois, avoir des tableaux de bord de données ne suffit pas. Si personne n’est là pour regarder les tableaux de bord, il peut se passer de nombreuses heures avant qu’un problème ne soit résolu, ou même détecté. C’est pourquoi Azure Monitor fournit également une solution d’alerte de premier ordre. Des alertes peuvent être déclenchées par de nombreuses conditions, notamment :

• Valeurs de métrique
• Requêtes de recherche de journal
• Événements du journal d'activité
• Contrôle d’intégrité de la plateforme Azure sous-jacente
• Tests de disponibilité des sites web

Lorsqu’elles sont déclenchées, les alertes peuvent effectuer une grande variété de tâches. Les alertes simples peuvent juste envoyer une notification par e-mail à une liste de diffusion ou un SMS à une personne. Des alertes plus complexes peuvent déclencher un workflow dans un outil comme PagerDuty, qui sait qui se charge d’une application en particulier. Les alertes peuvent déclencher des actions dans Microsoft Flow et laisser libre cours à un nombre quasi-illimité de possibilités de workflow.

Comme les causes courantes d’alertes sont identifiées, les alertes peuvent être améliorées avec des détails sur les causes courantes des alertes et les étapes à suivre pour les résoudre. Les déploiements d’applications natives cloud très matures peuvent choisir de lancer des tâches de « self-healing » qui accomplissent des actions telles que la suppression de nœuds défaillants d’un groupe identique ou le déclenchement d’une activité de mise à l’échelle automatique. Au final, il n’est plus nécessaire de réveiller le personnel en charge à 2 heures du matin pour résoudre un problème de site en direct, car le système sera capable de s’auto-ajuster pour compenser ou au moins de tenir tant bien que mal jusqu’à ce que quelqu’un arrive au travail le lendemain matin.

Azure Monitor tire automatiquement parti du machine learning pour comprendre les paramètres de fonctionnement normaux des applications déployées. Cette approche lui permet de détecter les services qui fonctionnent en dehors de leurs paramètres normaux. Par exemple, le trafic typique sur le site peut être de 10 000 requêtes par minute pendant les jours de la semaine. Et puis, sur une semaine donnée, le nombre de demandes atteint subitement un pic très inhabituel de 20 000 requêtes par minute. La détection intelligente remarquera cet écart par rapport à la norme et déclenchera une alerte. En même temps, l’analyse des tendances est suffisamment intelligente pour éviter de déclencher des faux positifs lorsque la charge du trafic est prévue.

References

• Azure Monitor

PrécédentSuivant