Récemment, David O'Brien a lancé sa propre entreprise Xirus (https://xirus.com.au), en se concentrant sur les produits cloud Microsoft Azure Stack. Ceux-ci sont conçus pour créer et déployer de manière cohérente des applications hybrides dans des centres de données, sur des sites périphériques, dans des bureaux distants et dans le cloud.
David forme des particuliers et des entreprises sur tout ce qui concerne Microsoft Azure et Azure DevOps (anciennement VSTS) et continue à faire du conseil pratique et du codage d'infrastructure. Il est MVP Microsoft depuis 5 ans (Most Valuable Professional Microsoft) et a récemment reçu le prix MVP Azure. En tant que co-organisateur du Melbourne Microsoft Cloud et Datacentre Meetup, O'Brien parle régulièrement lors de conférences internationales, combinant son intérêt pour les voyages à travers le monde avec sa passion pour partager des histoires informatiques avec la communauté. Le blog de David se trouve à , et il publie également ses formations en ligne sur Pluralsight.
La présentation aborde l'importance des mesures pour comprendre ce qui se passe dans votre environnement et comment votre application fonctionne. Microsoft Azure propose un moyen puissant et simple d'afficher les mesures pour tous types de charges de travail, et la conférence explique comment les utiliser toutes.
À 3 heures du matin, dimanche, pendant votre sommeil, vous êtes soudainement réveillé par un signal de message texte : "l'application hyper critique ne répond toujours pas". Que se passe-t-il ? Où est le problème des ralentissements ? Cette présentation vous informera sur les services que Microsoft Azure propose aux clients pour la collecte de journaux et, en particulier, des mesures de vos charges de travail cloud. David expliquera quelles mesures devraient vous intéresser lors de votre travail sur la plateforme cloud et comment y accéder. Vous en apprendrez sur les outils open source et la création de tableaux de bord, et vous acquerrez suffisamment de connaissances pour créer vos propres tableaux de bord.
Et si à 3 heures du matin, vous êtes de nouveau réveillé par un message concernant le plantage d'une application critique, vous pourrez rapidement identifier la cause.
Bonjour, aujourd'hui nous allons parler des métriques. Je m'appelle David O'Brien, je suis le co-fondateur et propriétaire d'une petite société de conseil australienne appelée Xirus. Merci encore d'être venu passer ce moment avec moi. Alors, pourquoi sommes-nous ici ? Pour parler des métriques, plus précisément, je vais vous en parler, et avant de faire quoi que ce soit, commençons par la théorie.
Je vais expliquer ce que sont les métriques, ce qu'on peut en faire, sur quoi il faut faire attention, comment collecter et intégrer la collecte des métriques dans Azure et ce qu'est la visualisation des métriques. Je vais vous montrer à quoi ces choses ressemblent dans le cloud de Microsoft et comment travailler avec ce cloud.
Avant de commencer, je vais demander à ceux qui utilisent Microsoft Azure de lever la main. Et qui travaille avec AWS ? Je vois qu'il y en a peu. Et avec Google ? ALI Cloud ? Une personne ! Super. Alors, qu'est-ce que les métriques ? La définition officielle de l'Institut national des standards et de la technologie des États-Unis est la suivante : « Une métrique est une norme de mesure qui décrit les conditions et les règles d'exécution de la mesure d'une propriété et qui sert à comprendre les résultats de la mesure ». Qu'est-ce que cela signifie ?
Prenons par exemple une métrique pour le changement d'espace libre sur le disque d'une machine virtuelle. Par exemple, nous obtenons le nombre 90, et ce nombre signifie des pourcentages, donc la quantité d'espace libre sur le disque est de 90 %. Je note qu'il n'est pas très intéressant de lire une définition des métriques qui occupe 40 pages en format pdf.
Cependant, la métrique ne dit pas comment le résultat de la mesure a été obtenu, elle montre seulement ce résultat. Que faisons-nous alors avec les métriques ?
Tout d'abord, nous mesurons la valeur de quelque chose, afin d'utiliser ensuite le résultat de la mesure.
Par exemple, nous avons appris le volume d'espace disque libre et nous pouvons maintenant l'utiliser, utiliser cette mémoire, etc. Une fois que nous avons obtenu le résultat de la métrique, nous devons l'interpréter. Par exemple, la métrique a donné un résultat de 90. Nous devons savoir ce que ce chiffre signifie : volume d'espace libre ou volume d'espace utilisé sur le disque en pourcentages ou en gigaoctets, la latence réseau étant de 90 ms, et ainsi de suite, c'est-à-dire que nous devons interpréter le sens de la valeur de la métrique. Pour que les métriques aient un sens, après l'interprétation d'une valeur de métrique, nous devons garantir la collecte de plusieurs valeurs. Cela est très important, car beaucoup de gens ne réalisent pas la nécessité de collecter des métriques. Microsoft a simplifié le processus d'obtention des métriques, mais vous devez vous occuper de leur collecte. Ces métriques sont conservées pendant seulement 41 jours et le 42e jour, elles disparaissent. Par conséquent, en fonction des caractéristiques de votre matériel externe ou interne, vous devez vous préoccuper de la manière de conserver les métriques plus de 41 jours, sous forme de journaux, de logs, etc. Ainsi, après la collecte, vous devez les placer quelque part, permettant, si nécessaire, de récupérer toutes les statistiques des variations des résultats métriques. En les plaçant là, vous pourrez commencer à travailler efficacement avec elles.
Ce n'est qu'après avoir obtenu les valeurs des métriques, les avoir interprétées et collectées, que vous pourrez créer un SLA – un accord de niveau de service. Ce SLA peut ne pas avoir beaucoup d'importance pour vos clients, il est plus important pour vos collègues, les gestionnaires, ceux qui assurent le bon fonctionnement du système et se préoccupent de sa fonctionnalité. La métrique peut mesurer le nombre de tickets — par exemple, vous recevez 5 tickets par jour, et dans ce cas, elle montre la rapidité de la réponse aux demandes des utilisateurs et la rapidité de résolution des problèmes. La métrique ne doit pas simplement indiquer que votre site se charge en 20 ms ou que le temps de réponse est de 20 ms, une métrique, c'est plus qu'un simple indicateur technique.
Ainsi, l'objectif de notre discussion est de vous présenter une image détaillée de la nature des métriques. La métrique sert à ce qu'en y jetant un œil, vous puissiez obtenir une vue d'ensemble du processus.
Dès que nous avons obtenu la métrique, nous pouvons garantir à 99 % que le système fonctionne, car ce n'est pas simplement un regard sur le fichier de log indiquant que le système est opérationnel. Une garantie de 99 % de disponibilité signifie que, par exemple, dans 99 % des cas, l'API répond avec une vitesse normale de 30 ms. C'est précisément ce qui intéresse vos utilisateurs, vos collègues et vos managers. Beaucoup de nos clients suivent les logs des serveurs web et ne remarquent aucune erreur, pensant que tout fonctionne parfaitement. Par exemple, ils voient un taux de vitesse réseau de 200 Mb/s et pensent : « très bien, tout va bien ! ». Mais pour atteindre ces 200, les utilisateurs ont besoin d'un temps de réponse de 30 millisecondes, et c'est précisément cette métrique qui n'est pas mesurée ni collectée dans les fichiers de logs. Dans ce contexte, les utilisateurs sont surpris que le site se charge très lentement, car, n'ayant pas la métrique nécessaire, ils ne connaissent pas la raison d'un tel comportement.
Cependant, étant donné que nous avons un SLA garantissant 100 % de disponibilité, les clients commencent à exprimer leur mécontentement, car en réalité, le site est très difficile à utiliser. Ainsi, pour créer un SLA objectif, il est nécessaire d'avoir une vue d'ensemble du processus, basée sur les métriques collectées. Cela fait l'objet de mon débat constant avec certains fournisseurs qui, lors de l'établissement de SLA, ne comprennent pas ce que signifie le terme « uptime » et, dans la plupart des cas, n'expliquent pas à leurs clients comment fonctionne leur API.
Si vous avez créé un service, par exemple, une API pour un tiers, vous devez comprendre ce que signifie la métrique obtenue de 39,5 – une réponse réussie, une réponse à une vitesse de 20 ms ou à une vitesse de 5 ms. C'est à vous d'adapter leur SLA à votre propre SLA, à vos propres métriques.
Après avoir compris tout cela, vous pouvez commencer à créer un superbe tableau de bord de surveillance. Dites-moi, quelqu'un a-t-il déjà utilisé l'application de visualisation interactive Grafana ? Super ! Je suis un grand fan de cet open source, car c'est gratuit et facile à utiliser.
Si vous n'avez pas encore utilisé Grafana, je vais vous expliquer comment l'utiliser. Ceux qui sont nés dans les années 80-90 se souviennent probablement des adorables teddy bears CareBears ? Je ne sais pas à quel point ces ours étaient populaires en Russie, mais en ce qui concerne les métriques, nous devons être tout aussi « attentionnés » que ces ours. Comme je l'ai dit, vous avez besoin d'une vue d'ensemble du fonctionnement de l'ensemble du système, et cela ne doit pas concerner uniquement votre API, votre site web ou le service exécuté sur une machine virtuelle.
Vous devez organiser la collecte des métriques qui reflètent le plus fidèlement le fonctionnement de l'ensemble du système. La plupart d'entre vous sont des développeurs, donc votre vie change constamment pour s'adapter aux nouvelles exigences du produit, et tout comme vous vous préoccupez des processus de codage, vous devez également vous préoccuper des métriques. Vous devez savoir comment une métrique touche chaque ligne de code que vous écrivez. Par exemple, la semaine prochaine, vous allez lancer une nouvelle campagne marketing et vous vous attendez à ce que votre site soit visité par un grand nombre d'utilisateurs. Pour analyser cet événement, vous aurez besoin de métriques, et il vous faudra peut-être un tableau de bord complet pour suivre l'activité de ces personnes. Les métriques vous aideront à comprendre à quel point votre campagne marketing est réussie et comment elle fonctionne réellement. Elles vous aideront, par exemple, à développer un CRM efficace - un système de gestion des relations client.
Alors, lançons-nous dans notre service cloud Azure. Il est très facile de trouver et d'organiser la collecte des métriques, car Azure Monitor est présent ici. Ce moniteur centralise la gestion de la configuration de votre système. Chacun des éléments d'Azure que vous souhaitez appliquer dans votre système a de nombreuses métriques activées par défaut. C'est une application gratuite qui fonctionne directement « dès la sortie de la boîte » et ne nécessite aucune configuration préalable, vous n'avez rien à écrire ni à « raccorder » à votre système. Nous allons nous en assurer en visionnant la prochaine démo.
En outre, il est possible d'envoyer ces métriques à des applications tierces telles que le système de stockage et d'analyse de journaux Splunk, le service cloud de gestion des journaux SumoLogic, l'outil d'analyse de journaux ELK, ou IBM Radar. Cependant, il existe de petites différences qui dépendent des ressources que vous utilisez – machines virtuelles, services réseau, bases de données Azure SQL, ce qui signifie que l'utilisation des métriques varie en fonction des fonctionnalités de votre environnement de travail. Je ne dirais pas que ces différences sont majeures, mais malheureusement, elles existent et doivent être prises en compte. L'activation et l'envoi des métriques peuvent se faire de plusieurs manières : via le portail, CLI/Power Shell ou à l'aide de modèles ARM.
Avant de commencer la première démonstration, je vais répondre à vos questions. Si vous n'avez pas de questions, nous pouvons commencer. L'écran montre à quoi ressemble la page Azure Monitor. L'un d'entre vous peut-il dire que ce moniteur ne fonctionne pas ?
Alors, maintenant tout est en ordre, vous voyez à quoi ressemblent les services de surveillance. Je peux vous dire que c'est un excellent et très simple outil pour le travail quotidien. Avec cet outil, vous pouvez surveiller les applications, le réseau et l'infrastructure. Récemment, l'interface de surveillance a été améliorée, et alors que les services étaient auparavant dispersés, maintenant toutes les informations sur les services sont consolidées sur la page d'accueil du moniteur.
La table des métriques est un onglet situé sous HomeMonitorMetrics, où vous pouvez accéder pour voir toutes les métriques disponibles et sélectionner celles qui vous intéressent. Mais si vous devez activer la collecte des métriques, vous devez aller à l'onglet HomeMonitorDiagnostic settings et cocher les cases pour les métriques Activées/Désactivées. Par défaut, presque toutes les métriques sont activées, mais si vous devez activer quelque chose de supplémentaire, vous devrez changer le statut de diagnostic de Désactivé à Activé.
Pour ce faire, cliquez sur la ligne de la métrique sélectionnée et, dans l'onglet qui s'ouvre, activez le mode de diagnostic. Si vous prévoyez d'analyser la métrique sélectionnée, après avoir cliqué sur le lien Activer le diagnostic, vous devez cocher la case Envoyer à Log Analytics dans la fenêtre qui apparaît.
Log Analytics est quelque peu similaire à Splunk, mais est moins cher. Ce service vous permet de collecter toutes vos métriques, journaux et tout ce dont vous aurez besoin, et de les placer dans un espace de travail Log Analytics. Le service utilise un langage de requête spécial appelé KQL – Kusto Query Language, dont nous examinerons le fonctionnement lors de la prochaine démo. Pour l'instant, je noterai qu'avec lui, vous pouvez formuler des requêtes concernant des métriques, journaux, termes, tendances, modèles, etc., et créer des tableaux de bord.
Ainsi, nous cochons la case Envoyer à Log Analytics et les cases du tableau LOG : DataPlaneRequests, MongoRequests et QueryRuntimeStatistics, puis en dessous sur le tableau METRIC – case à cocher Requests. Ensuite, nous donnons un nom quelconque et sauvegardons les paramètres. Dans la ligne de commande, cela correspond à deux lignes de code. D'ailleurs, l'interface Azure Cloud à cet égard rappelle Google, qui permet également d'utiliser une ligne de commande dans votre navigateur web. AWS n'a rien de semblable, donc Azure est beaucoup plus pratique dans ce sens.
Par exemple, je peux lancer la démo via l'interface web sans utiliser de code sur mon ordinateur portable. Pour cela, je dois m'authentifier avec mon compte Azure. Ensuite, je peux utiliser, par exemple, Terrafone, si vous l'utilisez déjà, attendre la connexion au service et obtenir un environnement Linux de travail, que Microsoft utilise par défaut.
Ensuite, j'utilise Bash intégré dans Azure Cloud Shell. Une caractéristique très utile est l'IDE intégré dans le navigateur, une version allégée de VS Code. Ensuite, je peux accéder à mon modèle de métriques d'erreurs, le modifier et le configurer selon mes besoins.
Une fois que vous avez configuré la collecte des métriques dans ce modèle, vous pouvez l'appliquer pour créer des métriques pour l'ensemble de votre infrastructure. Après avoir appliqué les métriques, collectées et sauvegardées, nous devrons les visualiser.
Azure Monitor ne s'occupe que des métriques et ne permet pas d'obtenir une vue d'ensemble de l'état de votre système. Vous pouvez avoir d'autres applications qui sont exécutées en dehors de l'environnement Azure. Donc, si vous avez besoin de surveiller tous les processus, en visualisant toutes les métriques collectées à un seul endroit, alors Azure Monitor ne sera pas adapté.
Pour résoudre ce problème, Microsoft propose l'outil Power BI – un logiciel complet pour l'analyse commerciale, incluant la visualisation de données variées. C'est un produit assez coûteux, dont le prix dépend de l'ensemble des fonctionnalités dont vous avez besoin. Par défaut, il vous propose 48 types de données traitées et est lié aux entrepôts de données SQL Azure, Azure Data Lake Storage, aux services d'apprentissage automatique Azure et à Azure Databricks. Grâce à la scalabilité, vous pouvez recevoir de nouvelles données toutes les 30 minutes. Cela peut suffire à vos besoins, ou pas assez si vous avez besoin d'une visualisation de suivi en temps réel. Dans ce cas, il est recommandé d'utiliser des applications telles que Grafana mentionnée. De plus, la documentation de Microsoft décrit la possibilité d'envoyer des métriques, des journaux et des tableaux d'événements via des outils SIEM vers des systèmes de visualisation comme Splunk, SumoLogic, ELK et IBM radar.
23:40 min
La suite arrivera très bientôt…
Un peu de publicité 🙂
Merci de rester avec nous. Aimez-vous nos articles ? Voulez-vous voir plus de contenu intéressant ? Soutenez-nous en passants une commande ou en nous recommandant à des amis, , un équivalent unique des serveurs d'entrée de gamme, conçu pour vous : (options disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go DDR4).
Dell R730xd deux fois moins cher dans le data center Equinix Tier IV à Amsterdam ? Uniquement chez nous aux Pays-Bas ! Dell R420 — 2x E5-2430 2.2GHz 6C 128Go DDR3 2x960Go SSD 1Gbps 100To — à partir de 99 $ ! Lisez sur
Source : habr.com
