David O'Brien a récemment lancé sa propre entreprise, Xirus (https://xirus.com.au), en se concentrant sur les produits cloud Microsoft Azure Stack. Ils sont conçus pour créer et exécuter de manière cohérente des applications hybrides dans les centres de données, les emplacements périphériques, les bureaux distants et le cloud.
David forme des particuliers et des entreprises sur tout ce qui concerne Microsoft Azure et Azure DevOps (anciennement VSTS) et continue de faire du conseil pratique et de l'infracodage. Il est lauréat du prix Microsoft MVP (Microsoft Most Valuable Professional) depuis 5 ans et a récemment reçu le prix Azure MVP. En tant que co-organisateur du Melbourne Microsoft Cloud and Datacentre Meetup, O'Brien prend régulièrement la parole lors de conférences internationales, combinant son intérêt pour les voyages à travers le monde avec sa passion pour le partage d'histoires informatiques avec la communauté. Le blog de David est situé à , il publie également sa formation en ligne sur Pluralsight.
L'exposé parle de l'importance des métriques pour comprendre ce qui se passe dans votre environnement et les performances de votre application. Microsoft Azure propose un moyen puissant et simple d'afficher des métriques pour tous types de charges de travail, et la conférence explique comment vous pouvez toutes les utiliser.
Un dimanche à 3 heures du matin, pendant que vous dormez, vous êtes soudainement réveillé par un SMS : « L'application supercritique ne répond plus ». Que se passe-t-il? Où et quelle est la raison des « freins » ? Dans cette présentation, vous découvrirez les services que Microsoft Azure propose aux clients pour collecter des journaux et, en particulier, des métriques de vos charges de travail cloud. David vous expliquera quelles métriques devraient vous intéresser lorsque vous travaillez sur une plateforme cloud et comment y accéder. Vous découvrirez les outils open source et la création de tableaux de bord, et vous disposerez de suffisamment de connaissances pour créer vos propres tableaux de bord.
Et si vous êtes réveillé à nouveau à 3 heures du matin par un message indiquant qu'une application critique est tombée en panne, vous pouvez rapidement en déterminer la cause.
Bonjour, aujourd'hui, nous allons parler de métriques. Je m'appelle David O'Brien, je suis co-fondateur et propriétaire d'une petite société de conseil australienne, Xirus. Merci encore d'être venu ici pour passer votre temps avec moi. Alors pourquoi sommes-nous ici? Pour parler de métriques, ou plutôt, je vais vous en parler, et avant de faire quoi que ce soit, commençons par la théorie.
Je vais vous expliquer ce que sont les métriques, ce que vous pouvez en faire, ce à quoi vous devez prêter attention, comment collecter et activer la collecte de métriques dans Azure et ce qu'est la visualisation des métriques. Je vais vous montrer à quoi ressemblent ces choses dans le cloud Microsoft et comment travailler avec ce cloud.
Avant de commencer, je demanderai à ceux qui utilisent Microsoft Azure de lever la main. Qui travaille avec AWS ? J'en vois peu. Et Google ? ALI-Cloud ? Un homme! Super. Alors, que sont les métriques ? La définition officielle du National Institute of Standards and Technology des États-Unis est la suivante : « Une métrique est une norme de mesure qui décrit les conditions et les règles de mesure d'une propriété et sert à comprendre les résultats de mesure. » Qu'est-ce que ça veut dire?
Prenons un exemple de métrique permettant de modifier l'espace disque libre d'une machine virtuelle. Par exemple, on nous donne le nombre 90, et ce nombre signifie pourcentage, c'est-à-dire que la quantité d'espace disque libre est de 90 %. Je constate qu'il n'est pas très intéressant de lire la description de la définition des métriques, qui prend 40 pages au format pdf.
Cependant, la métrique ne précise pas comment le résultat de la mesure a été obtenu, elle montre uniquement ce résultat. Que faisons-nous des 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 découvert la quantité d'espace disque libre et maintenant nous pouvons l'utiliser, utiliser cette mémoire, etc. Une fois que nous avons reçu le résultat métrique, nous devons l’interpréter. Par exemple, la métrique a renvoyé un résultat de 90. Nous devons savoir ce que signifie ce nombre : la quantité d'espace libre ou la quantité d'espace disque utilisé en pourcentage ou en gigaoctets, la latence du réseau égale à 90 ms, etc., c'est-à-dire , nous devons interpréter la signification de la valeur métrique. Pour que les métriques aient un sens, après avoir interprété une seule valeur de métrique, nous devons nous assurer que plusieurs valeurs sont collectées. Ceci est très important car de nombreuses personnes ne sont pas conscientes de la nécessité de collecter des mesures. Microsoft a rendu très simple la collecte de métriques, mais c'est à vous de vous assurer qu'elles sont collectées. Ces métriques ne sont stockées que 41 jours et disparaissent le 42ème jour. Par conséquent, en fonction des propriétés de votre équipement externe ou interne, vous devez veiller à la manière de sauvegarder les métriques pendant plus de 41 jours - sous forme de journaux, de journaux, etc. Ainsi, après la collecte, vous devez les placer dans un endroit qui vous permet d'extraire toutes les statistiques des changements dans les résultats des métriques si nécessaire. Une fois que vous les avez placés là, vous pouvez commencer à travailler efficacement avec eux.
Ce n'est qu'après avoir obtenu les métriques, les avoir interprétés et les avoir collectés que vous pourrez créer un SLA (accord de niveau de service). Ce SLA n’a peut-être pas beaucoup d’importance pour vos clients ; il est plus important pour vos collègues, managers, ceux qui maintiennent le système et se soucient 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 réponse aux demandes des utilisateurs et la rapidité de dépannage. Une métrique ne doit pas simplement indiquer que votre site se charge en 20 ms ou que votre vitesse de réponse est de 20 ms, une métrique est plus qu'un simple indicateur technique.
Par conséquent, la tâche de notre conversation est de vous présenter une image détaillée de l’essence des métriques. La métrique sert à ce qu'en la regardant, vous puissiez avoir une image complète du processus.
Une fois que nous avons la métrique, nous pouvons garantir à 99 % que le système fonctionne, car il ne suffit pas de consulter un fichier journal qui indique que le système fonctionne. Une garantie de disponibilité de 99 % signifie que, par exemple, 99 % du temps, l'API répond à une vitesse normale de 30 ms. C’est exactement ce qui intéresse vos utilisateurs, vos collègues et managers. Beaucoup de nos clients surveillent les journaux du serveur Web, mais ils n'y remarquent aucune erreur et pensent que tout va bien. Par exemple, ils voient une vitesse de réseau de 200 Mb/s et pensent : « ok, tout va bien ! » Mais pour atteindre ces 200, les utilisateurs ont besoin d'une vitesse de réponse de 30 millisecondes, et c'est précisément l'indicateur qui n'est ni mesuré ni collecté dans les fichiers journaux. Dans le même temps, les utilisateurs sont surpris que le site se charge très lentement, car, ne disposant pas des métriques nécessaires, ils ne connaissent pas les raisons de ce comportement.
Mais comme nous avons un SLA de disponibilité à 100 %, les clients commencent à se plaindre car le site est en réalité très difficile à utiliser. Par conséquent, pour créer un SLA objectif, il est nécessaire d’avoir une vision complète du processus créé par les métriques collectées. Il s'agit d'un problème récurrent que je rencontre avec certains fournisseurs qui, lors de la création de SLA, n'ont aucune idée de ce que signifie le terme « temps de disponibilité » 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 une tierce personne, vous devez comprendre ce que signifie la métrique résultante de 39,5 : réponse, réponse réussie, réponse à une vitesse de 20 ms ou à une vitesse de 5 ms. A vous d'adapter leur SLA à votre propre SLA, à vos propres métriques.
Une fois que vous avez compris tout cela, vous pouvez commencer à créer un superbe tableau de bord. Dites-moi, est-ce que quelqu'un a déjà utilisé l'application de visualisation interactive Grafana ? Super! Je suis un grand fan de cet open source car cette chose est gratuite et facile à utiliser.
Si vous n'avez pas encore utilisé Grafana, je vais vous expliquer comment l'utiliser. Toute personne née dans les années 80 et 90 se souvient probablement de CareBears ? Je ne sais pas à quel point ces ours étaient populaires en Russie, mais en ce qui concerne les mesures, nous devrions être les mêmes « bisounours ». Comme je l'ai dit, vous avez besoin d'une vue d'ensemble du fonctionnement de l'ensemble du système, et il ne devrait pas s'agir uniquement de votre API, de votre site Web ou du service exécuté dans une machine virtuelle.
Vous devez organiser la collecte des métriques qui reflètent le mieux le fonctionnement de l'ensemble du système. La plupart d'entre vous sont des développeurs de logiciels, votre vie change donc constamment, s'adaptant aux nouvelles exigences des produits, et tout comme vous vous préoccupez des processus de codage, vous devriez vous préoccuper des métriques. Vous devez savoir comment la métrique est liée à chaque ligne de code que vous écrivez. Par exemple, la semaine prochaine, vous lancez une nouvelle campagne marketing et vous vous attendez à ce qu’un grand nombre d’utilisateurs visitent votre site. Pour analyser cet événement, vous aurez besoin de métriques, et vous aurez peut-être besoin d'un tableau de bord complet pour suivre l'activité de ces personnes. Vous aurez besoin de mesures pour comprendre le succès de votre campagne marketing et ses performances réelles. Ils vous aideront, par exemple, à développer un CRM – système de gestion de la relation client efficace.
Commençons donc par notre service cloud Azure. Il est très facile de trouver et d’organiser la collecte de métriques car il dispose d’Azure Monitor. Ce moniteur centralise la gestion de la configuration de votre système. Chacun des éléments Azure que vous souhaitez appliquer à votre système possède de nombreuses métriques activées par défaut. Il s'agit d'une application gratuite qui fonctionne immédiatement et ne nécessite aucun réglage préalable ; vous n'avez pas besoin d'écrire ou de « visser » quoi que ce soit sur votre système. Nous vérifierons cela en regardant la démo suivante.
De plus, il est possible d'envoyer ces métriques à des applications tierces, telles que le système de stockage et d'analyse des journaux Splunk, l'application de gestion des journaux basée sur le cloud SumoLogic, l'outil de traitement des journaux ELK et IBM Radar. Certes, il existe de légères différences qui dépendent des ressources que vous utilisez - une machine virtuelle, des services réseau, des bases de données Azure SQL, c'est-à-dire que l'utilisation des métriques diffère selon les fonctions de votre environnement de travail. Je ne dirai pas que ces différences sont graves, mais malheureusement elles sont toujours présentes et il faut en tenir compte. L'activation et l'envoi de métriques sont possibles de plusieurs manières : via le portail, CLI/Power Shell ou à l'aide de modèles ARM.
Avant de commencer ma première démo, je répondrai à toutes vos questions. S'il n'y a pas de questions, commençons. 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 va bien, vous pouvez voir à quoi ressemblent les services de surveillance. Je peux dire que c'est un outil excellent et très simple pour le travail quotidien. Il peut être utilisé pour surveiller les applications, les réseaux et les infrastructures. Récemment, l’interface de surveillance a été améliorée, et si auparavant les services étaient situés à différents endroits, désormais toutes les informations sur les services sont regroupées sur la page d’accueil du moniteur.
Le tableau des métriques est un onglet le long du chemin HomeMonitorMetrics, auquel vous pouvez accéder pour voir toutes les métriques disponibles et sélectionner celles dont vous avez besoin. Mais si vous devez activer la collecte de métriques, vous devez utiliser le chemin du répertoire des paramètres HomeMonitorDiagnostic et cocher les cases 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 modifier l'état du diagnostic de Désactivé à Activé.
Pour cela, cliquez sur la ligne de la métrique sélectionnée et sur l'onglet qui s'ouvre, activez le mode diagnostic. Si vous souhaitez 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 un peu similaire à Splunk, mais coûte moins cher. Ce service vous permet de collecter toutes vos métriques, journaux et tout ce dont vous avez besoin et de les placer dans l'espace de travail Log Analytics. Le service utilise un langage de traitement de requêtes KQL spécial - Kusto Quarry Language, nous examinerons son travail dans la prochaine démo. Pour l'instant, je noterai qu'avec son aide, vous pouvez créer des requêtes concernant des métriques, des journaux, des termes, des tendances, des modèles, etc. et créer des tableaux de bord.
Nous cochons donc la case Envoyer à Log Analytics et les cases du panneau LOG : DataPlaneRequests, MongoRequests et QueryRuntimeStatistics, et ci-dessous sur le panneau METRIC – la case Requêtes. Ensuite, nous attribuons un nom et enregistrons les paramètres. Sur la ligne de commande, cela représente deux lignes de code. À propos, le shell Azure Cloud ressemble en ce sens à Google, qui vous permet également d'utiliser la ligne de commande dans votre navigateur Web. AWS n'a rien de tel, donc Azure est beaucoup plus pratique en ce sens.
Par exemple, je peux exécuter une démo via l’interface Web sans utiliser de code sur mon ordinateur portable. Pour ce faire, je dois m'authentifier avec mon compte Azure. Ensuite, vous pouvez utiliser, par exemple, Terrafone, si vous l'utilisez déjà, attendez la connexion au service et obtenez l'environnement de travail Linux que Microsoft utilise par défaut.
Ensuite, j'utilise Bash, intégré à Azure Cloud Shell. Une chose très utile est l'IDE intégré au navigateur, une version allégée de VS Code. Ensuite, je peux accéder à mon modèle de métriques d'erreur, le modifier et le personnaliser en fonction de mes besoins.
Une fois que vous avez configuré la collecte de métriques dans ce modèle, vous pouvez l'utiliser pour créer des métriques pour l'ensemble de votre infrastructure. Une fois que nous avons appliqué les métriques, les avons collectées et stockées, nous devrons les visualiser.
Azure Monitor ne traite que des métriques et ne fournit pas une image globale de la santé de votre système. Vous pouvez avoir un certain nombre d’autres applications exécutées en dehors de l’environnement Azure. Donc, si vous devez surveiller tous les processus, en visualisant toutes les métriques collectées au même endroit, Azure Monitor ne convient pas pour cela.
Pour résoudre ce problème, Microsoft propose l'outil Power BI, un logiciel complet d'analyse commerciale qui inclut la visualisation d'une grande variété de données. Il s'agit d'un produit assez cher, dont le coût dépend de l'ensemble des fonctions dont vous avez besoin. Par défaut, il vous propose 48 types de données à traiter et est lié à Azure SQL Data Warehouses, Azure Data Lake Storage, Azure Machine Learning Services et Azure Databricks. Grâce à l'évolutivité, vous pouvez recevoir de nouvelles données toutes les 30 minutes. Cela peut ou non être suffisant pour vos besoins si vous avez besoin d'une visualisation de surveillance en temps réel. Dans ce cas, il est recommandé d’utiliser des applications comme le Grafana dont j’ai parlé. De plus, la documentation Microsoft décrit la possibilité d'envoyer des métriques, des journaux et des tables d'événements à l'aide des outils SIEM aux systèmes de visualisation Splunk, SumoLogic, ELK et IBM Radar.
23:40 min
A suivre très prochainement...
Quelques publicités 🙂
Merci de rester avec nous. Vous aimez nos articles ? Vous voulez voir du contenu plus intéressant ? Soutenez-nous en passant une commande ou en recommandant à vos amis, , un analogue unique des serveurs d'entrée de gamme, que nous avons inventé pour vous : (disponible avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).
Dell R730xd 2 fois moins cher dans le centre de données Equinix Tier IV à Amsterdam ? Ici seulement aux Pays-Bas! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - à partir de 99$ ! En savoir plus
Source: habr.com