VENTES: 1-800-867-1389

Meilleures pratiques de dépannage pour développer des applications Azure

Mis à jour: avril 2014

Auteur : William Bellamy, ingénieur principal en charge de la remontée d'information, Microsoft

Contributeurs :

  • Bryan Lamos, responsable de programme senior, Qualité des produits, Microsoft

  • Kevin Williamson, ingénieur senior en charge de la remontée d'information, Azure Developer Support, Microsoft

  • Pranay Doshi, responsable de programme senior, Services de production Windows Azure, Microsoft

  • Tom Christian, ingénieur senior en charge de la remontée d'information, Azure Developer Support, Microsoft

Publié : janvier 2012

La principale priorité de Microsoft est d'aider les clients Windows Azure à maintenir l'opérabilité de leurs applications. Les contrats de niveau de service de Windows Azure définissent une disponibilité de 99,95 % de la connectivité externe dans le cadre du déploiement de plusieurs instances de rôle. La connectivité externe garantit que vous pouvez accéder à votre application de l'extérieur des centres de données Microsoft, ce qui recouvre une notion différente de l'opérabilité d'un site. La plupart des services Windows Azure ont plusieurs dépendances : SQL Azure, Caching, réseau de distribution de contenu, ressources internes (via Windows Azure Connect), etc. La défaillance de ces dépendances peut empêcher le fonctionnement normal de votre service Windows Azure.

Cet article porte sur les différents défis qui se posent en matière de résolution des problèmes et les approches recommandées pour élaborer et développer des applications plus facilement prises en charge pour la plateforme Windows Azure de Microsoft. Lorsqu'un problème survient (et non si un problème survient), le facteur temps est vital. Une planification appropriée peut vous aider à déceler et corriger les problèmes sans avoir à contacter le support technique de Microsoft. L'approche recommandée dans cet article permet par ailleurs d'accélérer la résolution des problèmes qui nécessitent l'assistance de Microsoft.

Cet article est destiné aux personnes travaillant dans le domaine de la conception technique et logicielle : concepteurs de logiciels, architectes, informaticiens, intégrateurs de systèmes, développeurs et testeurs qui créent, développent et déploient des solutions Windows Azure.

L'article considère que vous avez une compréhension de base du cycle de vie du développement d'une application Windows Azure, notamment de la terminologie et des divers composants de l'environnement de développement et d'exécution Windows Azure.

Il suppose également le suivi des recommandations de base pour Windows Azure (utilisation de la dernière version du Kit de développement logiciel (SDK) Windows Azure, test des modifications de code avant leur mise en production, etc.).

Il comprend deux sections :

  • Présentation des ressources de diagnostic Windows Azure :

    • ressources Windows Azure ;

    • ressources tierces.

  • Pratiques recommandées pour la prise en charge de la conception, du développement et du déploiement :

    • opérations antérieures au déploiement de votre application ;

    • conception et surveillance intégrant l'interruption immédiate ;

    • mesures à prendre en cas de problème.

Aucun développeur n'envisage la possibilité d'interruption de son application une fois celle-ci mise en production. Nous faisons de notre mieux pour tester le code dans le cadre du développement, de façon à ce qu'il soit suffisamment robuste pour être exécuté sans erreur, tandis que nous passons à un autre projet. Il arrive malheureusement que le code présente des failles. Dans un environnement distribué, des erreurs mineures peuvent s'avérer catastrophiques en raison des complexités inhérentes à la séparation des composants d'application. Pour cette raison, il convient d'intégrer une stratégie de journalisation et de suivi à l'application dès le départ. Dans l'idéal, cette stratégie inclut des dispositions pour l'ajustement dynamique sans nécessité de recréer/redéployer le type et le volume de journalisation au niveau des composants. La présence d'une grande quantité de journaux ne garantit pas une résolution rapide. En effet, il faut du temps pour déchiffrer les volumes importants de données. Par ailleurs, ceux-ci peuvent ralentir les performances de votre application. Des paramètres d'enregistrement ajustables permettent de contrôler la taille et les coûts de stockage des données de journal.

Les applications distribuées telles que celles exécutées sur la plateforme Windows Azure incluent de nombreux composants qui interagissent les uns avec les autres lorsque l'utilisateur interagit avec l'application. En journalisant de façon cohérente et abondante le flux de votre code avec une attention spéciale donnée aux appels effectués auprès de services externes, tout le monde doit pouvoir suivre virtuellement le flux d'exécution de votre application. Ceci peut être extrêmement précieux un ou deux ans plus tard, lorsqu'un problème survient en production. Dans l'idéal, le niveau de journalisation doit être ajustable à partir du fichier ServiceConfiguration.cscfg, de façon à pouvoir être modifié sans qu'un redéploiement soit nécessaire.

Il est pratique d'utiliser un build de débogage dans le cadre de la phase de développement afin d'obtenir un volume maximal d'informations sur les erreurs. Les développeurs ajoutent habituellement des instructions de débogage et parfois une forme de journalisation des erreurs. Les instructions de débogage sont toutefois supprimées dans le build de production, aussi, vous ne pourrez pas les consulter en cas de problème. La plupart des clients ne souhaitent pas effectuer de redéploiement avec un build de débogage pour résoudre un problème de production. Mike Kelly mentionne quatre types de sorties de diagnostic que les développeurs doivent configurer :

  • Sortie de débogage : uniquement dans le build de débogage, inclut les assertions

  • Suivi : suit le flux de contrôle lors de l'exécution

  • Journalisation des événements : événements majeurs

  • Journalisation des erreurs : situation exceptionnelle ou dangereuse

De nombreux messages de débogage doivent probablement être transformés en instructions de suivi pour tirer parti des différents niveaux de suivi. Par ailleurs, les diagnostics Windows Azure vous permettent de configurer les diagnostics et de désactiver les transferts afin de contrôler les modalités d'écriture des informations dans votre stockage persistant.

Les sections suivantes décrivent certaines des ressources de dépannage disponibles pour les développeurs qui créent des applications sur Windows Azure.

Avant d'examiner Windows Azure, commençons par analyser le modèle de dépannage actuel pour les applications Windows Server. Les développeurs consultent généralement les journaux lorsqu'un problème de production survient. Les journaux des événements et IIS sont activés par défaut et sont conservés après les redémarrages (dès lors qu'il n'y a pas de défaillance de disque).

Le même processus s'applique dans une application Windows Azure si le Bureau à distance est activé. Les développeurs peuvent se connecter à chaque instance pour collecter les données de diagnostic. La collecte peut être effectuée en copiant les journaux dans le stockage ou en configurant le protocole RDP afin qu'ils puissent être copiés sur votre ordinateur local. Ce processus prend du temps et échoue si l'instance est réinitialisée, ce qui entraîne le démarrage d'une version propre du rôle web ou de travail. Évidemment, la version propre n'inclut pas les journaux précédents. Une réinitialisation peut survenir si le système d'exploitation de l'hôte ou de la machine virtuelle invitée est mis à niveau. Cette opération est un composant normal de l'architecture Windows Azure.

Le Kit de développement logiciel (SDK) Windows Azure 1.0 original incluait des fonctionnalités de collecte des diagnostics et stockait ceux-ci dans le stockage Windows Azure, appelé collectivement diagnostics Windows Azure. Ce logiciel, basé sur l'infrastructure ETW (suivi d’événements pour Windows), remplit deux exigences de conception introduites par l'architecture de montée en puissance parallèle de Windows Azure :

  1. enregistrements des données de diagnostic qui seraient perdues dans le cadre d'une réinitialisation de l'instance ;

  2. fourniture d'un référentiel central pour les diagnostics de plusieurs instances.

L'espace de noms Microsoft.WindowsAzure.Diagnostic développe l'espace de noms System.Diagnostics pour vous permettre d'utiliser l'infrastructure ETW (suivi d’événements pour Windows) dans une application Windows Azure.

Windows Azure - Diagramme de flux de diagnostics

Une fois les diagnostics Windows Azure inclus dans le rôle (ServiceConfiguration.cscfg et ServiceDefinition.csdef), ils collectent les données de diagnostic auprès des instances de ce rôle particulier. Les données de diagnostic peuvent être utilisées pour le débogage et le dépannage, pour mesurer les performances, pour surveiller l'utilisation des ressources, pour l'analyse et la planification des capacités du trafic, et pour l'audit. Les transferts vers le compte de stockage Windows Azure à des fins de persistance peuvent être planifiés ou effectués à la demande.

Les diagnostics Windows Azure transforment le modèle de serveur de quatre manières :

  1. Les diagnostics doivent être activés lors de la création de l'application.

  2. Des outils/étapes spécifiques sont requis pour visualiser les résultats des diagnostics.

  3. Les blocages entraînent la perte des données de diagnostic sauf si celles-ci sont écrites dans un stockage durable (stockage Windows Azure, et non sur des instances individuelles).

  4. Le stockage des diagnostics dans le stockage Windows Azure est facturé sur une base mensuelle.

Il s'agit d'un aspect important, car la réduction des coûts constitue un des principaux avantages de la plateforme Windows Azure. La seule façon d'éliminer les coûts associés à l'utilisation de diagnostics Windows Azure aujourd'hui est de conserver les données sur la machine virtuelle. Cette solution peut fonctionner dans les déploiements de petite taille, mais n'est pas applicable dans les situations impliquant plusieurs instances. Voici plusieurs façons de minimiser l'impact financier :

  1. Vérifiez que le compte de stockage est inclus dans le même centre de données que votre application. Si, pour une raison quelconque, ils n'apparaissent pas dans le même centre de données, choisissez avec soin l'intervalle entre les transferts planifiés. Si des intervalles de transfert plus courts accroissent la pertinence des données, ceci ne suffit pas forcément à compenser la charge supplémentaire impliquée par l'utilisation accrue de la bande passante et le traitement.

  2. Copiez et effacez régulièrement les données de diagnostic du stockage Windows Azure. Les données de diagnostic sont transmises via le stockage Windows Azure, mais n'y résident pas sans raison. Plusieurs outils permettent d'effectuer ceci : System Center Monitoring Pack for Windows Azure, Azure Diagnostics Manager de Cerebrata et applets de commande Windows Azure PowerShell.

  3. Choisissez uniquement les données de diagnostic dont vous aurez besoin pour dépanner et surveiller votre application. La capture d'un trop grand nombre de données rend les opérations de dépannage plus difficiles et implique des coûts supérieurs.

  4. Contrôlez la collecte et l'étendue des données de diagnostic en implémentant un commutateur à la demande dans votre application.

  5. Définissez le niveau de journalisation approprié (Commentaires, Informations, Avertissement, Erreur) de façon à disposer des informations utiles, puis utilisez la configuration après déploiement des diagnostics Windows Azure pour collecter les données de façon sélective.

Le stockage Windows Azure est la base des applications prises en charge. Idéalement, cette fonctionnalité doit être configurée et active pour chaque application.

Windows Azure Storage Analytics assure la journalisation et fournit des données de métriques pour un compte de stockage. Vous pouvez utiliser ces données pour suivre les demandes de stockage, analyser les tendances d'utilisation et diagnostiquer les problèmes avec votre compte de stockage.

Pour écrire du code SQL Azure plus facilement pris en charge, il convient d'examiner les codes de retour et de vérifier que vous avez un code de tentative solide pour gérer les défaillances.

Ce pack d'analyse vous permet d'utiliser Microsoft System Center Operations Manager pour surveiller la disponibilité et les performances des applications Windows Azure :

  • Il découvre les applications Windows Azure.

  • Il fournit le statut de chaque instance de rôle.

  • Il collecte et surveille les informations de performances.

  • Il collecte et surveille les événements Windows.

  • Il collecte et surveille les messages de trace de .NET Framework auprès de chaque instance de rôle.

  • Il nettoie les données de performances, d'événement et de trace de .NET Framework dans le compte de stockage Windows Azure.

  • Il modifie le nombre d'instances de rôle.

L'utilisation de Microsoft System Center Operations Manager 2007 constitue le meilleur moyen de surveiller l'état de votre application Windows Azure.

Pour le moment, Windows Azure ne fournit pas de solution complète permettant aux clients de surveiller et gérer leur service hébergé. Pour les informations de réseau, speedtest.net fournit un outil qui mesure les temps de réponse, la bande passante et la qualité globale de la connexion. Il est possible de consulter la latence entre les différents centres de données Microsoft à l'aide des statistiques Azure de Matthew Rosoff. Divers outils s'avèrent extrêmement utiles dans le cadre de l'utilisation de Windows Azure. La liste suivante ne promeut ni ne recommande un outil tiers en particulier.

Applets de commande Windows Azure PowerShell

La meilleure façon de gérer les diagnostics à distance consiste à utiliser les applets de commande Windows Azure PowerShell. Les applets de commande sont basées sur les API de gestion et de diagnostic Windows Azure. Le code source complet est disponible via le projet CodePlex pour vous permettre de mieux comprendre les API sous-jacentes. La version 2.0 vous permet de configurer, télécharger et nettoyer tous les aspects des diagnostics Windows Azure. Le blog de Michael Washam fournit des exemples de script intéressants.

Analyse du réseau : AlertBot, Gomez, Keynote, Pingdom

Les solutions Gomez Application Performance Management de Compuware, Keynote, Pingdom et AlertBot permettent de surveiller votre application Windows Azure de l'extérieur, notamment de contrôler la disponibilité de votre application et d'optimiser les performances. Certains services, tels que Pingom, permettent de recevoir des notifications par courrier électronique, SMS ou via un notificateur de bureau de la détection d'une erreur. Ce type de surveillance doit simuler les actions d'un utilisateur final pour assurer une surveillance efficace. En effet, un rôle web peut parfois afficher la page d'accueil sans être entièrement fonctionnel.

AzureCheck

L'outil AzureCheck d'Apica surveille votre application web Windows Azure depuis l'extérieur. Pour utiliser cet outil, vous devez télécharger son code et l'ajouter à votre déploiement comme tâche de démarrage. Vous n'avez pas à enregistrer vos journaux dans votre compte de stockage, ce qui réduit les coûts associés à la surveillance.

Azure Diagnostics Manager

Azure Diagnostic Manager de Cerebrata est un client Windows qui permet de gérer les diagnostics Windows Azure. Il affiche ou télécharge les journaux collectés par les diagnostics Windows Azure. Vous pouvez également gérer la configuration des diagnostics Windows Azure. Un tableau de bord vous permet par ailleurs de surveiller les performances en direct.

Explorateurs de stockage Azure

Vous pouvez explorer le stockage Windows Azure de différentes façons. L'équipe du stockage Windows Azure a établi la liste des explorateurs de stockage. Ceux-ci permettent d'afficher les fichiers des diagnostics Windows Azure et Windows Azure Storage Analytics. Explorer for Azure Blob Storage de Cloudberry Lab fournit une interface utilisateur qui permet d'activer Storage Analytics directement dans l'application en cliquant sur Paramètres de stockage.

IntelliTrace

Microsoft Visual Studio 2010 Ultimate inclut IntelliTrace, qui peut être activé pour déboguer les applications avant leur déploiement en production. IntelliTrace prend en charge les applications ASP.NET et WCF. Intellitrace n'est pas pris en charge lorsqu'il est activé dans un service de production, mais peut être utilisé pour récupérer les exceptions d'une application après le déploiement dans Windows Azure. Le billet de blog de Jim Nakashima décrit l'utilisation d'IntelliTrace pour déboguer Windows Azure Cloud Services.

AVIcode

Microsoft a fait l'acquisition d'AVIcode, qui fait désormais partie de Microsoft System Center. AVIcode inclut des fonctionnalités de surveillance des performances des applications .NET avec une suite complète de fonctionnalités de surveillance des applications.

Fiddler

Fiddler est un proxy de débogage web qui journalise le trafic HTTP(S) entre votre ordinateur et Internet. Fiddler vous permet d'inspecter le trafic, de définir des points d'arrêt et de manipuler les données entrantes ou sortantes. Fiddler est particulièrement utile pour dépanner le stockage Windows Azure.

Pour utiliser Fiddler sur la fabrique de développement locale, vous devez utiliser ipv4.fiddler au lieu de 127.0.0.1 :

  1. Démarrez Fiddler.

  2. Démarrez votre service dans la fabrique de développement.

  3. Accédez à http://ipv4.fiddler:/. Fiddler doit tracer la demande.

Pour utiliser Fiddler sur le stockage de développement local, vous devez modifier le fichier de configuration du service de façon à pointer vers Fiddler :

  1. Ouvrez le fichier ServiceConfiguration.cscfg et définissez la chaîne de connexion sur :

    Value=“UseDevelopmentStorage=true;DevelopmentStorageProxyUri=http://ipv4.fiddler”

  2. Démarrez Fiddler.

  3. Démarrez votre service. Fiddler doit tracer les demandes de stockage.

Profilage des performances

Vous pouvez maintenant profiler votre application Windows Azure lorsqu'elle s'exécute dans Windows Azure pour identifier les problèmes éventuels affectant les performances. Lorsque vous publiez votre application Windows Azure de Visual Studio, vous pouvez choisir de profiler l'application et sélectionner les paramètres de profilage dont vous avez besoin.

Windows Azure VM Assistant

L'outil VM Assistant est un projet CodePlex qui permet de gagner du temps dans le diagnostic des problèmes en collectant les données pertinentes dans un emplacement lorsque vous utilisez le Bureau à distance sur une instance. Le bouton VM Health indique le statut actuel de l'instance.

Lorsqu'il est question des solutions basées sur le cloud, il est plus important pour les concepteurs de logiciels et les développeurs de préparer la résolution des problèmes au moment de la conception que dans le cas des logiciels classiques déployés sur des serveurs dans un centre de données d'entreprise. Cette section décrit certains scénarios spécifiques que les développeurs doivent limiter dans le cloud et décrit la préparation nécessaire à la résolution rapide des problèmes lorsqu'ils surviennent.

La différence fondamentale avec le déploiement classique basé sur un serveur est que vous ne pouvez plus accéder aux serveurs physiques. Le Kit de développement logiciel (SDK) Windows Azure 1.3 a ajouté la possibilité d'utiliser les services Bureau à distance pour accéder aux rôles Windows Azure. L'utilisation du dernier Kit de développement logiciel offre une expérience optimale. L'activation du Bureau à distance est une première étape obligatoire dans la création d'un service Windows Azure pouvant être pris en charge. Cette opération peut seulement être effectuée avant le déploiement.

Une des étapes requises pour activer le Bureau à distance consiste à choisir un nom d'utilisateur, un mot de passe et une date d'expiration du compte. Ces trois éléments peuvent être modifiés dans le Portail de gestion Windows Azure. Cela peut s'avérer utile lorsque vous oubliez le mot de passe que vous avez défini plusieurs mois auparavant lors du premier déploiement du service.

Lorsque vous cliquez sur le bouton Configurer dans le portail pour modifier ces paramètres, vous devez voir la séquence suivante : Mise à jour..., En attente de l'hôte..., Le rôle a été mis à jour. En attente de l'hôte..., Prêt. Cela correspond au rôle recevant, puis gérant l'événement de modification. Les clients peuvent s'abonner aux événements RoleEnvironment. Lorsqu'un événement RoleEnvironment.Changing Event est reçu, ils peuvent : accepter les modifications et maintenir l'exécution (valeur par défaut), ou mettre l'instance hors ligne, appliquer les modifications, puis remettre l'instance en ligne (e.Cancel = true).

Si le code recycle le rôle sur les événements de modification, les instances dans tous les rôles inclus dans ce service hébergé seront recyclées. Les services incluant plusieurs instances par rôle ne sont pas affectés par des temps d'arrêt en raison de l'architecture de mise à jour des domaines, mais les performances peuvent être dégradées à mesure que chaque domaine est recyclé. Par ailleurs, si vous êtes confronté à un problème qui ne se produit qu'une fois par mois, vous ne pourrez pas capturer l'état de l'instance. Par conséquent, il est recommandé d'avoir une connexion Bureau à distance activée avec des informations d'identification connues et sécurisées qui n'ont pas expiré.

Vous devez ensuite effectuer des tests pour vérifier le fonctionnement de la connexion. Pour cela, il suffit de cliquer sur le bouton Connexion du portail. Le plus souvent, vous devez conserver une copie du fichier RDP de façon à modifier la section Ressources locales pour inclure vos disques locaux. Ceci vous permettra de copier aisément les fichiers à partir de votre instance et vers elle. Vous pouvez effectuer ceci en cliquant sur l'onglet Ressources locales, puis sur le bouton Plus. Les paramètres de connexion sous l'onglet Général vous permettront d'enregistrer vos paramètres dans un fichier .RDP.

Windows Azure - Boîtes de dialogue de connexion Bureau à distance

Dépannage sur la machine virtuelle

À présent que vous vous êtes connecté à une instance, que recherchez-vous ? Si vous dépannez un rôle qui ne parvient pas à démarrer, consultez cet article MSDN. Kevin Williamson a publié un billet de blog très intéressant qui décrit comment trouver les fichiers journaux et identifier les processus à déboguer.

Vous pouvez également installer VM Assistant pour examiner les fichiers journaux et accéder à des informations utiles sur votre instance. Vous pouvez également installer les outils, tels que le Moniteur réseau ou Fiddler pour voir ce qui survient sur le réseau. Un des tests les plus simples consiste à exécuter Internet Explorer sur votre instance et à vous connecter à votre site web, car vous pourrez ainsi consulter les détails des exceptions.

Débogage d'une instance principale web hébergée

Si vous exécutez un rôle d'instance principale web hébergée, seule une fenêtre de commande sera disponible dans la machine virtuelle. Vous devez donc ouvrir une nouvelle fenêtre de commande en exécutant Start à partir de l'invite de commandes sans quoi vous accèderez à l'expérience Windows Server complète. Voici la liste des commandes de base :

  • Start : ouvre une nouvelle fenêtre de commande

  • explorer : ouvre l'Explorateur Windows

  • eventvwr : ouvre l'Observateur d'événements

  • taskmgr : ouvre le Gestionnaire des tâches

  • start iexplore : exécute Internet Explorer

  • services.msc : ouvre Service Manager

  • control : ouvre le Panneau de configuration

  • certmgr.msc : ouvre le composant logiciel enfichable Gestionnaire de certificats

  • regedit : ouvre l'Éditeur du Registre

  • shutdown /r /t 0 : redémarre l'instance de machine virtuelle

  • Start Task Manager : utile si vous perdez votre invite de commandes et devez en démarrer une nouvelle (dans le Gestionnaire des tâches, accédez à Fichier -> Exécuter -> Cmd)

Le Bureau à distance est la base d'un service Windows Azure pouvant être pris en charge, mais il connaît certaines limitations lorsque le nombre de rôles et d'instances augmente. Par exemple, comment savez-vous à quelle instance vous devez vous connecter lorsqu'une centaine d'entre elles sont disponibles ? L'utilisation de cette méthode de dépannage peut accroître le délai nécessaire à la sauvegarde de votre site si vous ne savez pas où et quoi rechercher.

Vous devez tenir compte des points suivants :

  • Activez le Bureau à distance sur chaque rôle dans le cadre du déploiement.

  • Définissez un mot de passe connu fort et vérifiez que vos informations d'identification n'expirent pas.

  • Testez votre accès pour vérifier son fonctionnement avant qu'un problème ne survienne.

  • Enregistrez un fichier RDP pour votre connexion.

Il existe quatre tâches principales pour utiliser les diagnostics Windows Azure :

  1. Installation des diagnostics Windows Azure

  2. Configuration de la collecte de données

  3. Instrumentation de votre code

  4. Affichage des données

Installation des diagnostics Windows Azure

L'architecture des diagnostics Windows Azure commence par collecter les données sur l'instance, puis conserve les données dans le stockage Windows Azure. Vous devez donc commencer par accéder au Portail de gestion Windows Azure pour créer un compte de stockage (par exemple, mylogs). Il est recommandé de localiser votre compte de stockage dans le même emplacement géographique que votre application Windows Azure afin d'éviter les coûts externes de bande passante et de réduire la latence.

L'une des fonctionnalités de développement intéressantes incluses dans Windows Azure Tools pour Visual Studio version 1.4 (août 2011) et les versions ultérieures est la possibilité de disposer de différents fichiers de configuration (ServiceConfiguration.cscfg) pour les services locaux et sur le cloud. Nick Harris décrit sur son blog plusieurs utilisations de cette fonctionnalité. Plusieurs configurations de service sont utiles pour le diagnostic, car cela facilite l'utilisation de l'émulateur de stockage pour le test local gratuit tout en conservant un fichier de configuration distinct pour la production. Les problèmes de démarrage des applications suite à leur publication sur Windows Azure sont souvent provoqués par l'omission de la modification d'une chaîne de connexion contenant UseDevelopmentStorage=true en false.

Visual Studio permet d'activer les diagnostics pendant le test en cliquant simplement sur le bouton Utiliser l'émulateur de stockage Windows Azure :

Windows Azure - Boîtes de dialogue de connexion au compte de stockage

Une fois que vous avez testé votre application et êtes prêt à publier celle-ci, vous devez disposer d'un compte de stockage à configurer pour le cloud (ServiceConfiguration.Cloug.cscfg). Sur son blog, David Makogon indique trois raisons pour lesquelles avoir un compte de stockage dédié aux diagnostics, distinct du stockage de vos données d'application :

  1. Le fait de disposer d'une clé d'accès distincte pour les diagnostics permet d'accéder aux journaux sans risque pour les données d'application.

  2. L'utilisation de plusieurs comptes de stockage n'implique aucun frais, car elle est basée sur la taille des données.

  3. Les performances peuvent être améliorées grâce à l'utilisation d'un compte séparé.

Définissez ensuite la chaîne de connexion :

<Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="DefaultEndpointsProtocol=https;AccountName=<name>;AccountKey=<key>" />

Les valeurs AccountName et AccountKey sont disponibles sur le Portail de gestion dans la section relative au compte de stockage. AccountName correspond à la première partie de l'URL pour les points de terminaison du stockage de tables et d'objets blob (partie avant « .table.core.windows.net »). AccountKey est la clé d'accès principale codée en base 64 pour votre compte de stockage.

Par défaut, seuls les journaux Windows Azure sont activés. Ils ne sont toutefois pas persistés, aussi, vous devez ensuite décider de la quantité de données que vous voulez collecter et du moment auquel les journaux doivent être transférés. Ces choix ne sont pas anodins. En effet, ils influencent les performances de votre application et déterminent le montant facturé chaque mois pour le stockage.

Vous devez commencer par déterminer la quantité de stockage nécessaire pour les données collectées par les diagnostics Windows Azure. Cette valeur est contrôlée par la taille du disque pour votre instance/machine virtuelle et par la propriété OverallQuotaInMB de la classe DiagnosticMonitorConfiguration. Par exemple, si vous avez configuré votre modèle de service de façon à utiliser une taille de machine virtuelle ultra-petite, la quantité maximale de stockage local disponible est de 20 Go. Par défaut, la propriété OverallQuotaInMB est définie sur 4 Go. Cela signifie que vous n'auriez que 16 Go de stockage local, ce qui peut être insuffisant pour vos fichiers d'application et temporaires. OverallQuotaInMB définit la taille d'une mémoire tampon ajustable réinscriptible. En revanche, si le trafic sur votre site web est important et que vous avez configuré de nombreux compteurs de performances, il est possible que vos données de diagnostic soient remplacées, notamment si vous ne les transférez pas vers le stockage persistant régulièrement.

Une fois que la taille de votre machine virtuelle est définie, il est possible que vous souhaitiez dépasser les 4 Go. Pour ce faire, il est possible d'ajouter un élément <LocalStorage> pour DiagnosticStore avec l'attribut sizeInMB défini sur la nouvelle taille dans votre fichier ServiceDefinition.csdef et de modifier la valeur OverallQuotaInMB en conséquence :

<LocalResources>
      <LocalStorage name="DiagnosticStore" sizeInMB="8192" cleanOnRoleRecycle="false" />
    </LocalResources>

En affectant la valeur False à l'attribut cleanOnRoleRecycle, vous veillez à ce que le stockage local « DiagnosticStore » ne soit pas supprimé lorsque le rôle est recyclé. Consultez l'Annexe D : ServiceDefinition.csdef pour voir le code complet du fichier ServiceDefinition.csdef. Ce paramètre ne garantit pas que les données seront conservées si l'instance est déplacée (problème matériel, etc.). Les paramètres de diagnostic étant spécifiques à un rôle, vous devez ajouter une valeur DiagnosticStore à chacun de vos rôles individuellement.

Le calcul de la taille d'agrégation des données de diagnostic que vous avez configurée est extrêmement important, car les diagnostics Windows Azure échouent si la somme dépasse la valeur OverallQuotaInMB. La seule façon de détecter cette erreur consiste à attacher un débogueur ou à ajouter une instruction try catch à la méthode OnStart. Voici ce qui apparaît dans le journal des événements des applications si le code catch écrit un événement :

Windows Azure - Journal des événements

Comment pouvez-vous calculer la somme des sous-quotas demandés ? Chaque type de collection d'éléments (journaux des événements, compteurs de performance, etc.) est associé à une mémoire tampon de données, qui est nulle par défaut. La propriété BufferQuotaInMB peut utiliser la valeur par défaut de zéro, inférieure à OverallQuotainMB, ou être définie de façon explicite. OverallQuotaInMB doit être inférieur à la somme de toutes les propriétés BufferQuotaInMB.

Lorsque le quota est atteint, les données les plus anciennes sont supprimées à mesure que de nouvelles données sont ajoutées. Cette stratégie de suppression s'applique également si vous avez configuré un intervalle de transfert pour la mémoire tampon. Une fois le transfert terminé, les données sont conservées dans le stockage local et seront supprimées selon la stratégie ci-dessus.


// Set an overall quota of 8GB.
config.OverallQuotaInMB = 8192;

// Set the sub-quotas and make sure it is less than the OverallQuotaInMB set above
config.Logs.BufferQuotaInMB = 1024;
config.Directories.BufferQuotaInMB = 0; // Use the rest of the storage here
 config.WindowsEventLog.BufferQuotaInMB = 1024;
config.PerformanceCounters.BufferQuotaInMB = 1024;
config.DiagnosticInfrastructureLogs.BufferQuotaInMB = 1024;

Les sous-quotas des répertoires sont définis sur zéro, de telle sorte qu'ils utilisent le reste du quota de stockage disponible. Si vous définissez une valeur spécifique, celle-ci doit être supérieure ou égale aux autres quotas, car il doit être suffisamment grand pour inclure les journaux IIS (rôle web) et les vidages sur incident. Par défaut, Directory.QuotaInMB est défini sur 1024 Mo. Si un vidage sur incident est supérieur à un gigaoctet, il ne sera pas écrit. Les vidages minimaux permettent de réduire la taille des vidages.

Les fichiers des vidages complets contiennent une mémoire de processus (octets virtuels) au moment du vidage. Comme une version 64 bits de Windows est exécutée, la limite supérieure de mémoire correspondra à la mémoire physique de la machine. Vous pouvez trouver cette valeur en consultant la colonne sur la mémoire du tableau de taille des instances/machines virtuelles. Par exemple, un vidage complet sur incident d'une instance ultra-grande peut représenter une taille de 14 Go. Il s'agit évidemment d'un scénario pessimiste dans lequel le processus utilise toute la mémoire disponible, mais n'est-ce pas le cas lorsque vous voulez capturer le fichier de vidage dans la réalité ?

À présent que vous connaissez la quantité de données de diagnostic que vous collecterez, vous devez déterminer une stratégie pour conserver ces données.

Une option peut consister à ne pas commencer la collecte des données tant que vous n'avez pas déterminé qu'un problème est survenu. Cette option présente deux défauts :

  1. comment saurez-vous qu'un problème s'est produit ? S'il est possible de compter sur les clients pour signaler un problème majeur, qu'en est-il des problèmes plus insidieux comme les fuites de mémoire ?

  2. Quel est le niveau de base avant la survenue du problème ? Votre application utilise-t-elle 80 % de l'UC tout le temps ou s'agit-il d'un symptôme du problème ?

Étonnamment, cette option est la plus populaire, car elle n'implique aucun coût, aucune planification ni aucune action. Il s'agit aussi de la pire option.

La deuxième option consiste à configurer tous les compteurs requis, mais à ne pas conserver les données dans le stockage Windows Azure. Lorsqu'un problème survient, les données peuvent être examinées ou un transfert peut être initié manuellement. Cela peut apparaître comme une solution idéale, car aucun coût n'est impliqué jusqu'à ce qu'un problème apparaisse. Malheureusement, les problèmes soulevés par la première option s'appliquent également à la deuxième option et augmentent le délai de récupération.

La troisième option consiste à définir les différentes propriétés ScheduledTransferPeriod sur des valeurs relativement petites pour garantir que les données de diagnostic ne sont pas remplacées sur l'instance, mais suffisamment grandes pour qu'elles ne nuisent pas aux performances de votre application. La plus petite période de transfert que vous pouvez spécifier est d'une minute. Les valeurs inférieures sont arrondies à 1, aussi la persistance n'est pas désactivée. Vérifiez donc que vos données de diagnostic sont transférées avant d'en avoir réellement besoin.

Un problème courant dans de nombreux exemples de code est que la propriété ScheduledTransferPeriod est définie sur une minute, ce qui affecte négativement les performances de votre application en production. Les exemples utilisent les valeurs minimales pour vous permettre de déterminer rapidement s'ils fonctionnent. La plupart des développeurs ne souhaitent pas attendre 30 minutes pour vérifier le transfert des journaux. Il existe deux solutions pour contourner ce problème : modifiez systématiquement la configuration des diagnostics Windows Azure après le déploiement à l'aide d'un des Autres outils utiles, ou ajoutez du code et un paramètre vers le fichier ServiceConfiguration.cscfg pour tirer parti de la fonctionnalité des fichiers de configuration du service multiples mentionnée précédemment dans cette section. Le paramètre est créé comme suit dans le fichier ServiceConfiguration.Local.cscfg :

<ConfigurationSettings>
      <Setting name="ScheduledTransferPeriod" value="1" />

Il ressemble à ce qui suit dans le fichier ServiceConfiguration.Cloud.cscfg :

<ConfigurationSettings>
      <Setting name="ScheduledTransferPeriod" value="30" />

Le code dans la méthode OnStart et l'événement RoleEnvironmentChanging seraient semblables à ce qui suit :

// Get ScheduledTransferPeriod setting from ServiceConfiguration.cscfg and then set it 
var myScheduledTransferPeriod = RoleEnvironment.GetConfigurationSettingValue("ScheduledTransferPeriod");
TimeSpan myTimeSpan = TimeSpan.FromMinutes(Convert.ToDouble(myScheduledTransferPeriod));
config.Logs.ScheduledTransferPeriod = myTimeSpan;
config.Directories.ScheduledTransferPeriod = myTimeSpan;
config.WindowsEventLog.ScheduledTransferPeriod = myTimeSpan;
config.PerformanceCounters.ScheduledTransferPeriod = myTimeSpan;
config.DiagnosticInfrastructureLogs.ScheduledTransferPeriod = myTimeSpan;

L'autre variable qui affecte la quantité de données collectée est le niveau de journalisation. Les journaux des événements des applications sont l'une des sources de données les plus importantes pour la collecte. De même, les journaux des événements système peuvent parfois être utiles. Les journaux des événements de sécurité ne sont pas disponibles via les diagnostics Windows Azure. La taille de ces fichiers peut être atténuée à l'aide des valeurs de filtre suivantes pour spécifier le niveau des entrées de journal :

  • Critique

  • Erreur

  • Avertissement

  • Informations

  • Détaillée

Le niveau de journalisation est cumulatif, aussi si le filtre est défini sur Warning, les événements de type Error et Critical sont également transférés. Vous pouvez utiliser la méthode ci-dessus pour configurer les niveaux LogLevelFilter spécifiques pour les configurations locales et de cloud. Le fichier ServiceConfiguration.Local.cscfg est semblable à ce qui suit :

<Setting name="LogLevelFilter" value="Information" />

Le fichier ServiceConfiguration.Cloud.cscfg est semblable à ce qui suit :

      <Setting name="LogLevelFilter" value="Error" />

Le code dans la méthode OnStart et l'événement RoleEnvironmentChanging sont semblables à ce qui suit :

// Get LogLevelFilter setting from ServiceConfiguration.cscfg and then set it
var LogLevelFilter = RoleEnvironment.GetConfigurationSettingValue("LogLevelFilter");
var myLogLevel = LogLevel.Undefined;
switch (LogLevelFilter)
{
    case ("Information"):
        myLogLevel = LogLevel.Information;
        break;
    case ("Verbose"):
        myLogLevel = LogLevel.Verbose;
        break;
    case ("Warning"):
        myLogLevel = LogLevel.Warning;
        break;
    case ("Critical"):
        myLogLevel = LogLevel.Critical;
        break;
    case ("Error"):
        myLogLevel = LogLevel.Error;
        break;
    default:
        break;
} 

// Filter what will be sent to persistent storage.
config.Logs.ScheduledTransferLogLevelFilter = myLogLevel;
config.DiagnosticInfrastructureLogs.ScheduledTransferLogLevelFilter = myLogLevel;
config.WindowsEventLog.ScheduledTransferLogLevelFilter = myLogLevel;

Il est possible que le code suggéré ne soit pas adapté à vos besoins. Pour ceux qui ne souhaitent pas ajouter de code et préfèrent utiliser la dernière configuration connue plutôt que ce qui est défini dans le code, il existe une autre solution.

Utilisation d'un fichier de configuration

Le Kit de développement logiciel (SDK) Windows Azure 1.3 permet de placer la configuration dans un fichier XML plutôt que d'écrire du code. David Hardin soutient qu'il s'agit de la manière la plus efficace de configurer les diagnostics pour tous les types de rôles Windows Azure. Cette méthode présente de nombreux avantages par rapport à l'écriture d'un code :

  1. Les diagnostics Windows Azure sont démarrés avant que OnStart ne soit exécutée, de telle sorte que les erreurs sont détectées dans les tâches de démarrage.

  2. Toute modification apportée à la configuration au moment de l'exécution est conservée après un redémarrage.

  3. Démarrez automatiquement l'agent de diagnostics avec la configuration définie sans code supplémentaire pouvant générer une exception qui empêchera le démarrage du rôle.

  4. Il s'agit de la seule méthode pour obtenir des diagnostics à partir d'un rôle de machine virtuelle bêta.

  5. Les modifications de configuration ne nécessitent pas la reconstruction du code.

Un exemple de fichier diagnostics.wadcfg est disponible dans l'Annexe F : diagnostics.wadcfg. Le fichier de configuration nommé diagnostics.wadcfg doit être placé à l'emplacement suivant. Veillez à définir le paramètre Copier dans le répertoire de sortie sur Toujours copier :

  • Pour les rôles de travail, le fichier de configuration se trouve dans le répertoire racine du rôle.

  • Pour les rôles web, le fichier de configuration se trouve dans le répertoire bin sous le répertoire racine du rôle.

  • Pour les rôles de machine virtuelle bêta, le fichier de configuration doit être situé dans le dossier %ProgramFiles%\Windows Azure Integration Components\<VersionNumber>\Diagnostics de l'image serveur que vous chargez dans le Portail de gestion Windows Azure. <VersionNumber> correspond à la version du Kit de développement logiciel (SDK) Windows Azure que vous utilisez. Un fichier par défaut est situé dans ce dossier que vous pouvez modifier ou vous pouvez remplacer ce fichier par l'un des vôtres.

Le format de ce fichier est décrit dans le document MSDN suivant. Le fichier .wadcfg est ignoré s'il existe déjà une configuration XML dans le conteneur de stockage d'objets blob wad-control-container. Vous devez également vérifier que le contenu du fichier est correct, sans quoi aucun diagnostic ne sera collecté.

Vous pouvez alors décider quelles informations vous voulez collecter.

Configuring Data Collection

Si vous ne voulez pas utiliser un fichier de configuration, il est recommandé de démarrer les diagnostics dans la méthode OnStart au sein d'un bloc try/catch. Le bloc vérifie qu'en présence d'un problème, vous traitez celui-ci normalement, ce qui empêche votre rôle d'être bloqué dans le cadre du recyclage. Le danger lié à l'insertion de code dans la méthode OnStart est que, si vous ne gérez pas toutes les exceptions, le rôle se retrouve dans une boucle de recyclage difficile à déboguer. Pendant qu'elle se trouve dans cette méthode, l'instance de rôle est définie sur Busy et l'instance n'est pas accessible via l'équilibrage de charge Windows Azure. Si la méthode OnStart renvoie la valeur false ou s'il y a une exception, l'instance de rôle est immédiatement interrompue. Si la méthode renvoie la valeur true, Windows Azure démarre le rôle en appelant la méthode Run.

En insérant le code OnStart dans un bloc try/catch, vous pouvez éviter que votre rôle ne bascule en boucle (le statut sur le Portail de gestion ne passe jamais à Prêt) lorsqu'il y a une exception. Le code catch peut contenir un appel de la méthode Trace.WriteLine (exemple MSDN) ou une erreur peut être consignée dans le journal des événements (billet de blog sur le débogage ASP.NET). En consignant un événement dans le journal des événements, il est plus aisé d'identifier la raison pour laquelle un rôle ne démarre pas. Une légère modification du code (telle que proposée par Tom Christian) consiste à enregistrer l'exception dans le journal des événements des applications comme suit :

catch (Exception e)  
    {
            string sSource;
            string sEvent;
            sSource = "WaAppAgent";
            sEvent = "WorkerRole OnStart Event: " + e.Message;
            EventLog.WriteEntry(sSource, sEvent, EventLogEntryType.Error, 0);
    }

Le code complet figure dans l'Annexe B : exemple de code d'un rôle web. La méthode la plus puissante pour la configuration des diagnostics consiste à utiliser un fichier de configuration et un code qui vous permet de modifier de façon dynamique la configuration à partir du Portail de gestion.

Dès lors que les diagnostics Windows Azure sont configurés, vous pouvez commencer à collecter les données. Cinq types de données peuvent être collectés :

  • Vidages sur incident

  • Journal des événements Windows

  • Compteurs de performance

  • Journaux IIS

  • Journaux FREB

Le tableau suivant donne un aperçu des données collectées localement par défaut, et indique les données qui doivent être explicitement configurées :

 

Source de données Configuration par défaut Description

DiagnosticInfrastructureLogs

Activé. Stocké localement. Aucun transfert vers le stockage persistant défini. Transferts vers la table de stockage WADDiagnosticInfrastructureLogsTable

Journaux spécifiques à l'infrastructure de diagnostics elle-même. Ne sont pas très utiles habituellement.

Logs

Activé. Stocké localement. Aucun transfert vers le stockage persistant défini. Transferts vers la table de stockage WADLogsTable

Journaux System.Diagnostics.Trace placés dans le code d'application.

Directories

Les objets blob wad-iis-failedreqlogfiles, wad-iis-logfiles et wad-crash-dumps sont créés automatiquement par défaut, chacun avec la propriété DirectoryQuotaInMB définie sur 1 024 Mo. Vous pouvez également configurer des annuaires supplémentaires

Les données de journal seront transférées à l'intervalle de transfert ScheduledTransferPeriod.

PerformanceCounters

Désactivé. Lorsqu'ils sont ajoutés, le nom de la table de stockage est WADPerformanceCountersTable

Les compteurs de performance doivent être spécifiés explicitement

WindowsEventLog

Désactivé. Lorsque les compteurs de performance sont ajoutés, le nom de la table de stockage est WADWindowsEventLogsTable

Aucune DataSources n'est spécifiée pour les journaux des événements Windows.

CrashDumps

De mini vidages sur incident sont collectés localement. Les vidages complets peuvent être activés. wad-crash-dumps est le nom créé dans le stockage d'objets blob.

Appelez la méthode EnableCollection(true) pour obtenir des vidages sur incident complets.

Données de suivi des demandes IIS 7.0 ayant échoué

Désactivé. Lorsqu'ils sont ajoutés, le nom du stockage d'objets blob est wad-iis-failedreqlogfiles

Ceux-ci doivent être activés dans le fichier Web.config

  • Vidages sur incident

    Les diagnostics Windows Azure ne collectent pas automatiquement les vidages sur incident. La syntaxe prête à confusion, car vous devez ajouter le code suivant pour collecter les vidages minimaux :

    // Enable crash mini dump collection.
                    CrashDumps.EnableCollection(false);
    
    Le code qui permet de collecter les vidages complets est semblable à ce qui suit :

                    // Enable full crash dump collection.
                    CrashDumps.EnableCollection(true);
    
    Pour la configuration de Directory.QuotaInMB, si vous avez des vidages complets, vous devez allouer suffisamment de stockage local et stockage global pour enregistrer un vidage complet.

  • Journaux d'événements

    Les journaux des événements permettent de rechercher les erreurs affectant les applications. Voici comment vous pouvez ajouter des événements d'application et système :

    // Add in configuration settings for Windows Event logs           config.WindowsEventLog.DataSources.Add("Application!*");
    config.WindowsEventLog.DataSources.Add("System!*");
    
    Seuls les événements qui surviennent après le démarrage des diagnostics Windows Azure seront collectés, ce qui rend les journaux des événements inutiles pour le diagnostic des problèmes de démarrage, sauf si vous utilisez la manière recommandée pour démarrer et configurer les diagnostics.

    Vous pouvez également ne filtrer que certains événements. Le billet de blog de Steve Marx décrit la création d'une requête XPath pour récupérer les seules informations utiles. Par exemple, l'utilisation de la requête XPath suivante avec la méthode Add collecte uniquement les messages WaAppAgent :

    ("Application!*[System[Provider[@Name='WaAppAgent']]]")
    
  • Compteurs de performance

    Les compteurs de performance doivent être ajoutés de manière explicite. La difficulté que présente la configuration de ces compteurs est que si l'un d'entre eux est incorrect, cela entraîne l'échec de tous les compteurs sur ce rôle. L'erreur suivante apparaît dans la fenêtre de sortie de l'émulateur de calcul :

    [MonAgentHost] Error:  PdhExpandWildCardPath(\Process(_Total)) failed
    
    Les rôles web et de travail peuvent utiliser plusieurs langues. Pour tous les types de rôles, il est recommandé d'utiliser les compteurs de performance de base suivants. Il faudrait définir le nom du processus dans l'exemple ci-dessous (WaWorkerHost) sur WaIISHost pour un rôle web. Le code spécifique à un rôle de travail qui n'exécute pas le code .NET est disponible dans l'Annexe C : exemple de code d'un rôle de travail :

    • @"\Processus(WaWorkerHost)\% temps processeur"

    • @"\Processus(WaWorkerHost)\Octets privés"

    • @"\Processus(WaWorkerHost)\Nombre de threads"

    • @"\Processeur(_Total)\% temps processeur"

    • @"\Mémoire\Octets disponibles"

    Pour un rôle web ou de travail exécutant un code en langage .NET, d'autres compteurs doivent être surveillés. Là encore, il faudrait définir le nom du processus dans l'exemple ci-dessous (w3wp) sur WaWorkerHost s'il s'agit d'un rôle de travail, et sur WaIISHost s'il s'agit d'un rôle web en mode IIS complet. Les compteurs recommandés pour un rôle web exécutant un code en langage .NET sont disponibles dans l'Annexe B : exemple de code d'un rôle web :

    • @"\Processus(w3wp)\% temps processeur"

    • @"\Processus(w3wp)\Octets privés"

    • @"\Processus(w3wp)\Nombre de threads"

    • @"\Processeur(_Total)\% temps processeur"

    • @"\Mémoire\Octets disponibles"

    • @"\ASP.NET\Exécution des applications"

    • @"\Interopérabilité CLR .NET(_Global_)\Nombre de marshaling"

    • @"\Jit CLR .NET(_Global_)\% temps en Jit"

    • @"\Chargement CLR .NET(_Global_)\% temps chargement"

    • @"\Verrous et threads CLR .NET(_Global_)\Taux de conflits/s"

    • @"\Mémoire CLR .NET(_Global_)\Nombre d'octets dans tous les tas"

    • @"\Réseau CLR .NET(_Global_)\Connexions établies"

    • @"\Accès distant CLR .NET(_Global_)\Appels distants/s"

    Il faut définir la chaîne WaIISHost sur w3wp si le mode IIS complet n'est pas utilisé. Comme indiqué précédemment, la propriété ScheduledTransferPeriod détermine quand ou si les compteurs sont conservés dans le stockage.

  • journaux IIS

    Les rôles web Windows Azure sont exécutés sous IIS avec la journalisation activée par défaut, et écrits au format W3C encodé en UTF-8 dans le dossier de ressource de votre application (par exemple, C:\Resources\directory\c5c31518818e46569fa68f0809b5a6aa.fm_WebRole.DiagnosticStore\LogFiles\Web) avec la substitution de fichier journal définie sur Toutes les heures. Il y a un fichier journal par site. Si vous accédez à distance à l'une de vos instances et ouvrez le Gestionnaire des services IIS, les paramètres suivants apparaissent :

    Windows Azure - Boîte de dialogue Enregistrement

    Les options de journalisation par défaut peuvent être modifiées pour satisfaire vos exigences particulières. Les modifications doivent toutefois être incorporées à une tâche de démarrage de telle sorte que les paramètres ne soient pas perdus à chaque redémarrage de l'instance. Par exemple, pour consigner les seules erreurs, vous devez utiliser Appcmd.exe, qui fait partie d'IIS7, dans une tâche de démarrage qui contiendrait la commande suivante :

    appcmd set config /section:httpLogging /dontLog:False /selectiveLogging:LogError
    
  • Suivi des demandes ayant échoué

    Si vous avez un rôle web, vous souhaiterez certainement collecter les journaux du suivi des demandes ayant échoué (anciennement mise en mémoire tampon des événements relatifs aux demandes ayant échoué). Pour cela, il suffit d'ajouter les lignes suivantes à la section <system.webServer> du fichier Web.config, comme suit :

    <tracing>
          <traceFailedRequests>
            <add path="*">
              <traceAreas>
                <add provider="ASP" verbosity="Verbose" />
                <add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" />
                <add provider="WWW Server" areas="Authentication, Security, Filter, StaticFile, CGI, Compression, Cache, RequestNotifications,Module" verbosity="Verbose" />
              </traceAreas>
              <failureDefinitions timeTaken="00:00:20" statusCodes="400-599" />
            </add>
          </traceFailedRequests>
        </tracing>
    
    Cela se traduit par un enregistrement dans le journal des échecs pour les demandes supérieures à 15 secondes ou dont le code d'état est compris entre 400 et 599 (élément failureDefinitions). Une fois le journal FREB créé, il est conservé automatiquement dans le stockage.

  • Autres annuaires

    Vous pouvez également collecter d'autres fichiers écrits dans l'instance, en particulier les fichiers d'agent invité. Ces fichiers peuvent vous donner des informations sur ce qui arrive entre l'agent invité et le contrôleur de structure Windows Azure. Pour ce faire, vous devez configurer un répertoire qui sera copié par les diagnostics Windows Azure :

              // Add a custom directory transfer
              DirectoryConfiguration directoryConfiguration = new DirectoryConfiguration();
              directoryConfiguration.Container = "wad-custom-logs";
              directoryConfiguration.DirectoryQuotaInMB = 0;
              directoryConfiguration.Path = @"c:\logs\WaAppAgent.log";
              config.Directories.DataSources.Add(directoryConfiguration);
    
    La même restriction s'applique ici à ce qui peut arriver en cas d'échec de la configuration. Pour effectuer un test sur l'émulateur de calcul, vous devrez créer ce dossier et vérifiez que plusieurs rôles n'exécutent pas ce code, sans quoi il en résulte une violation de partage. Cette erreur ne surviendra pas dans la configuration du cloud, car chaque instance est séparée.

Dépannage des diagnostics Windows Azure

À présent que tous les éléments sont configurés, il est temps de les tester dans l'émulateur de calcul et de les déployer dans Windows Azure. Que se passe-t-il lorsque vos diagnostics n'apparaissent pas ? Voici la liste des éléments à vérifier :

  1. Examinez les objets blob dans le conteneur d'objets blob wad-control-container du compte de stockage de diagnostics. Vous recherchez l'objet blob nommé <deploymentID>/<RoleName>/<RoleInstance> (par exemple, 3981bcff0eb743ddb9b7574a8821e955/WebRole1/WebRole1_IN_0).

    1. Ouvrez le fichier XML et vérifiez qu'il est configuré comme vous le souhaitez. Si vous voyez <ScheduledTransferPeriodInMinutes>0</ScheduledTransferPeriodInMinutes> pour une source de données, cela signifie que les diagnostics ne sont pas configurés pour transférer des données.

    2. Si vous avez plusieurs instances, et que seulement certaines d'entre elles transfèrent des diagnostics, comparez les fichiers XML pour vérifier qu'ils sont correctement configurés.

    3. Si vous configurez les diagnostics après le déploiement, et que ceux-ci ont cessé de fonctionner de manière aléatoire, cela est probablement dû au fait que le rôle a été recyclé ou l'instance redémarrée. Lorsqu'une instance redémarre, les paramètres post-déploiement personnalisés sont perdus et les diagnostics configurés dans le code sont utilisés. Un des avantages principaux que présente l'utilisation du fichier .wadcfg est que cette configuration n'est pas remplacée sur le recyclage des rôles.

  2. Consultez les journaux dans la table WADDiagnosticInfrastructureLogsTable du compte de stockage de diagnostics. Vous pouvez filtrer sur la base du DeploymentId (c'est-à-dire, « bd9e149f76e8413aba8865c77326e449 »). Recherchez les exceptions ou messages d'erreur pouvant indiquer la raison pour laquelle les diagnostics ne sont pas transférés.

  3. Si les informations Diagnostics.Trace ne sont pas collectées, vérifiez que DiagnosticMonitorTraceListener est configuré dans le fichier web.config ou app.config. Si celles-ci sont configurées par défaut dans les projets de cloud, il peut arriver qu'elles soient modifiées, ce qui empêche la collecte des instructions de suivi par les diagnostics.

  4. Souvent, le stockage des diagnostics n'est pas correctement interrogé, aucun résultat n'est renvoyé et il est supposé que les diagnostics ne sont pas capturés. Interrogez les tables de diagnostics en filtrant sur DeploymentID et vérifiez si les diagnostics sont correctement transférés. Parmi les erreurs de requête courantes, il arrive que l'utilisateur ne filtre pas sur DeploymentID ou ne suive pas les jetons de continuation.

  5. Après le déploiement, si votre instance ne démarre pas, vérifiez que le compte de stockage configuré dans le fichier ServiceConfiguration.cscfg n'est pas défini sur « UseDevelopmentStorage=true ». Si vous utilisez une version postérieure à celle d'août 2011 de Windows Azure Tools pour Visual Studio 2011, un avertissement s'affiche. Sinon, vous devez accéder via le Bureau à distance à votre instance et examiner le fichier de configuration de rôle situé dans le dossier C:\Config.

  6. Vous devez également vérifier que DiagnosticsAgent.exe et MonAgentHost.exe sont en cours d'exécution lorsque vous êtes connecté à l'instance. En supposant que c'est le cas, vous pouvez installer et attacher WinDBG pour voir si des exceptions sont générées.

  7. Vous pouvez également vérifier que les diagnostics sont écrits localement.

    • Pour l'environnement de développement, les fichiers .tsf seront écrits dans :

      c:\Users\<Nom_utilisateur>\AppData\Local\dftmp\Resources\<ID_déploiement>\directory\DiagnosticStore\Monitor\Tables

    • Sur une instance en cours d'exécution, les fichiers sont écrits dans :

      c:\Resources\<deploymentID>.<role>\directory\DiagnosticStore\Monitor\Tables

    Pour lire ces fichiers, vous devez créer un incident de support technique et l'envoyer à Microsoft.

  8. Si vous avez plusieurs instances mais que seulement certaines d'entre elles ne transfèrent pas les diagnostics correctement, essayez de réinitialiser le rôle à partir du Portail de gestion. Cette action ne doit être effectuée qu'en dernier recours, car cela empêche de déterminer l'origine du problème.

Instrumentation de votre code

Les données de diagnostic les plus importantes sont les messages de trace que vous ajoutez à votre code en tant que développeur. Les données système peuvent indiquer des exceptions ou stocker des messages d'erreur. Tracez des appels spécifiques aux systèmes dépendants. Il est recommandé d'ajouter un message de trace lorsque vous appelez un système dépendant qui peut échouer ; par exemple, un service d'authentification tiers.

L'infrastructure ETW associe un TraceEventType à chaque événement :

 

TraceEventType Niveau Valeur Signification

Critique

1

0x0001

Erreur irrécupérable ou blocage d'application

Erreur

2

0x0002

Erreur récupérable

Avertissement

3

0x0004

Problème non critique. Peut indiquer l'éventualité de problèmes plus graves à venir

Informations

4

0x0008

Message d'informations

Détaillée

5

0x0010

Trace de débogage (informations détaillées sur le flux d'exécution, paramètres, etc.)

Démarrer

0x0100

Démarrage d'une opération logique

Arrêter

0x0200

Arrêt d'une opération logique

Une fois que vous avez planifié l'instrumentation de votre code, vous pouvez simplement ajouter l'espace de noms System.Diagnostics, puis les messages de trace, lesquels ressemblent à ce qui suit en langage C# :

Trace.WriteLine("LoggingWorkerRole entry point called", "Information");

Comme Windows Azure a commencé à s'exécuter avec IIS complet (SDK 1.3), le code de l'application web est exécuté dans un autre domaine d'application et processus à partir du RoleEntryPoint. Cela signifie que les messages de trace ne s'afficheront pas dans l'émulateur de calcul sauf si vous ajoutez un écouteur de suivi au fichier Web.Config sous Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener :

<add type="Microsoft.ServiceHosting.Tools.DevelopmentFabric.Runtime.DevelopmentFabricTraceListener, Microsoft.ServiceHosting.Tools.DevelopmentFabric.Runtime, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" name="DevFabricListener">
    <filter type=""/>
</add>

Pour les applications plus complexes, la définition d'une méthodologie EventId vous permet de filtrer les journaux de façon plus efficace, ce qui accélère la résolution des problèmes. Si vous utilisez WriteLine (langage C#), EventId sera toujours nul. Pour spécifier un EventId, vous devez utiliser la méthode TraceEvent, pour laquelle traceType est indiqué dans la table ci-dessous :

Trace.TraceEvent(traceType, eventId, message);

Les messages de trace sont conservés dans la table WADLogsTable. Windows Azure associe automatiquement les informations suivantes à chaque événement enregistré : un horodateur, le nombre de cycles (qui fournit une temporisation plus détaillée avec une granularité de 100 nanosecondes), et des informations sur le déploiement, le rôle et l'instance de rôle. Cela vous permet de limiter les journaux à des instances spécifiques. Le message est stocké au format XML comme suit :


<Properties>
 <EventTickCount>634402131502204503</EventTickCount>
 <DeploymentId>deployment(28)</DeploymentId>
 <Role>WebRole1</Role>
 <RoleInstance>deployment(28).Sample.WebRole1.0</RoleInstance>
 <Level>3</Level>
 <EventId>20</EventId>
 <Pid>10796</Pid>
 <Tid>7172</Tid>
 <Message>trace message; TraceSource 'Data' event</Message> 
</Properties>

Le niveau correspond au TraceEventType. Dans la table ci-dessus, vous pouvez voir que le niveau 3 correspond à un avertissement. Si aucun TraceEventType n'est spécifié, ou si vous utilisez Trace.WriteLine, le niveau sera défini sur 5 (Commentaires).

Le plus souvent, le niveau de journalisation standard est suffisant. Pour obtenir des types plus détaillés de journalisation, vous pouvez créer un écouteur de suivi personnalisé :

Azure Table Query est un projet CodePlex de rôles web qui vous permet d'interroger la table WADLogsTable à l'aide d'une requête LINQ.

Affichage de vos données

La collecte des diagnostics permet d'accéder rapidement à ceux-ci lorsqu'un problème survient. Cela signifie que vous devez vérifier que tout fonctionne correctement avant qu'un problème ne survienne, de la même façon que vous devez vérifier qu'une sauvegarde de données fonctionne correctement. Cela implique de consulter vos données de diagnostic dans le cadre du test de votre application, puis d'effectuer des examens réguliers afin de s'assurer que tout fonctionne correctement. Cela implique également de définir une référence afin d'identifier les dégradations des performances.

Les données des diagnostics Windows Azure sont stockées dans le compte de stockage que vous spécifiez au démarrage des diagnostics Windows Azure. Vous pouvez utiliser l'Explorateur de serveurs Visual Studio, ou un des storage explorers disponibles pour visualiser ces données.

Le conteneur de stockage d'objets blob wad-control-container contient l'infrastructure de journalisation des diagnostics elle-même. Vous pouvez voir si vos données sont transférées à partir d'une instance donnée à cet emplacement. L'identité de l'objet blob aura la forme suivante :

0aef2b51ad1d49ef915dd41d3ca01f24/WorkerRole1/WorkerRole1_IN_0

Cette identité se décompose en trois parties :

  1. Le numéro long est l'ID de déploiement : 0aef2b51ad1d49ef915dd41d3ca01f24

  2. Nom du rôle : WorkerRole1

  3. Nom de l'instance : WorkerRole1_IN_0

S'il y a plusieurs instances, le suffixe de base zéro est incrémenté (par exemple, WorkerRole1_IN_1 sera la deuxième instance).

Le tableau suivant indique l'emplacement d'écriture des journaux :

 

Type de journal Format de stockage Windows Azure Remarques

Journaux Windows Azure générés à partir de votre code

Table

L'écouteur de suivi doit être ajouté au fichier web.config ou app.config. Les fichiers sont stockés dans la table WADLogsTable.

Journaux IIS 7.0

Objet Blob

Rôles web uniquement. Stockés dans un conteneur d'objets blob dans le chemin d'accès wad-iis-logfiles\<ID de déploiement>\<nom du rôle web>\<instance du rôle>\W3SVC1.

Journaux d'infrastructure des diagnostics Windows

Table

Informations sur le service de diagnostics. Stockés dans la table WADDiagnosticInfrastructureLogs.

Journaux des demandes ayant échoué

Objet Blob

Rôles web uniquement. Activés via la définition des options de suivi sous les paramètres system.WebServer dans le fichier web.config. Stockés dans un conteneur d'objets blob dans le chemin d'accès wad-iis-failedreqlogfiles\<ID de déploiement>\<nom du rôle web>\<instance du rôle>\W3SVC1.

Journaux des événements Windows

Table

Activés via la modification de DiagnosticMonitor Configuration.WindowsEventLog lors de la configuration initiale. Stockés dans la table WADWindowsEventLogs.

Compteurs de performance

Table

Activés via la modification de DiagnosticMonitor Configuration.PerformanceCounters. Stockés dans la table WADPerformanceCounters. Le rôle de travail de l'exemple de code définit un compteur de performance.

Vidages sur incident

Objet Blob

Activés via l'appel de CrashDumps.EnableCollection. Stockés dans un conteneur d'objets blob dans le chemin d'accès wad-crash-dumps. Étant donné qu'ASP.NET gère la plupart des exceptions, cela s'avère utile uniquement pour un rôle de travail.

Journaux d'erreurs personnalisées

Objet Blob

Pour obtenir un exemple d'utilisation, consultez le blog de Neil Mackenzie.

Lorsque les données de vidage sur incident sont transférées vers le stockage persistant, elles sont stockées dans le conteneur d'objets blob wad-crash-dumps. Les journaux IIS sont transférés dans le conteneur d'objets blob wad-iis-logfiles. Les demandes ayant échoué sont stockées dans le conteneur d'objets blob wad-iis-failedreqlogfiles.

Les journaux des événements sont transférés vers la table WADWindowsEventLogs dans le stockage persistant. Les compteurs de performance sont transférés vers la table WADPerformanceCounters selon l'intervalle spécifié. La table WADDiagnosticInfrastructureLogs contient les journaux relatifs à l'infrastructure de diagnostic. Les écouteurs de suivi sont disponibles dans la table WADLogsTable.

L'utilisation de LINQPad avec l'exemple AzureLogsWithLINQPad de Jason Haley permet d'afficher les données de diagnostic.

Gestion des diagnostics

La conservation de ces fichiers journaux dans le stockage Windows Azure présente un coût en termes de temps et d'argent. La solution idéale consiste à activer le suivi « juste-à-temps » lorsque vous en avez besoin pour résoudre un problème particulier. Lorsque vous modifiez les paramètres de diagnostic de façon dynamique, vous devez veiller à les replacer manuellement dans les paramètres d'origine ou à modifier les paramètres d'origine s'il faut conserver quelque chose à cet emplacement. Cette étape consciente est particulièrement importante si vous n'utilisez pas de fichier .wadcfg. En effet, si l'instance est redémarrée, vos nouveaux paramètres seront remplacés par les paramètres de diagnostic configurés dans votre code.

Les applets de commande Windows Azure PowerShell peuvent gérer de nombreux aspects des services Windows Azure que vous exécutez, notamment les diagnostics. Exécutés à partir de votre ordinateur local, ceux-ci utilisent les API de gestion et de diagnostic Windows Azure pour se connecter via Internet à votre service, en fournissant des informations et en ajustant des paramètres.

Windows PowerShell est installé avec Windows 7. Il s'agit de l'évolution des applets de commande de gestion des services installées avec l'outil de gestion Windows Azure (MMC). Voici certaines des applets de commande les plus utiles :

  • Get-DiagnosticConfiguration : obtient la configuration de la mémoire tampon pour le nom de la mémoire tampon spécifié (Logs, Directories, PerformanceCounters, WindowsEventLogs ou DiagnosticInfrastructureLogs).

  • Pour modifier la configuration d'un rôle, utilisez l'applet de commande Set-DiagnosticConfiguration.

  • Start-OnDemandTransfer : démarre un transfert à la demande de la mémoire tampon de données spécifiée. Cette applet de commande déplace les données vers le stockage Windows Azure (soit une table ou un stockage d'objets blob).

Le blog de David Aiken inclut un script pour le nettoyage de certains fichiers journaux (fichiers journaux IIS et fichiers XML du conteneur wad-control-container). L'applet de commande Clear-Container doit être appelée pour chaque conteneur. Vous devez également vérifier que vos transferts planifiés ne chevauchent pas la suppression. Vous devez aussi définir une stratégie pour les journaux stockés dans des tables (compteurs de performance, journaux des événements, etc.). Certains utilisateurs téléchargent tout auprès du stockage Windows Azure et le placent dans une base de données SQL Server afin qu'ils ne soient plus facturés pour le stockage et puissent exécuter des requêtes complexes sur les données.

En comprenant les ressources de diagnostic Windows Azure, les développeurs peuvent créer des applications prises en charge à l'aide des meilleures pratiques de conception décrites ci-dessous.

L'intégrité d'une application doit être mesurée par rapport à des données de référence. L'affichage correct de votre page d'accueil ne signifie pas nécessairement que votre application est intègre. Il est également nécessaire de comprendre l'intégrité et les performances de votre logique métier pour créer un niveau de référence complet pour l'intégrité.

Vous devez ensuite comprendre les modalités de cumul de l'intégrité. Il convient en premier lieu de payer votre facture Windows Azure à temps. Un abonnement impayé a des conséquences de plus en plus néfastes, avec la suppression de votre application au final.

Pour chaque abonnement, les services hébergés Windows Azure comportent quatre niveaux pouvant affecter l'intégrité de votre application.

Windows Azure - Niveaux d'intégrité

Par exemple, une instance peut échouer suite à une défaillance matérielle ou redémarrer en raison d'une mise à jour logicielle. Ceci n'entraîne pas l'échec du rôle sauf si une seule instance est configurée. De même, chaque service hébergé est situé dans une région particulière (par exemple, Centre-Sud des États-Unis). Ces informations critiques détermineront si votre application est affectée par un événement d'interruption du service (par exemple, une panne). Les défaillances aux niveaux inférieurs peuvent provoquer des défaillances au niveau du service hébergé si la redondance n'est pas intégrée à la conception de l'application.

La plupart des applications Windows Azure nécessitent des architectures plus complexes que celle illustrée dans le diagramme précédent. Il est probable que votre application ressemble davantage à ceci :

Windows Azure - Exemple d'architecture

La nature distribuée introduit plusieurs points d'échec possibles. La documentation de ces chemins d'accès critiques renforce l'efficacité du dépannage. Par exemple, dans le diagramme ci-dessus, comment pouvez-vous déterminer si la défaillance est survenue dans le contrôle d'accès ?

Pour comprendre le problème survenu dans une application, vous devez surveiller et enregistrer l'état de l'application. Vous souhaitez généralement enregistrer des informations relevant de quatre catégories sur votre application :

  • Programmation : exceptions, valeurs des principales variables et informations nécessaires au débogage de l'application.

  • Processus métier : audit requis pour la sécurité, le suivi des modifications et la conformité.

  • Stabilité du système : performances, extensibilité, débit et latences.

  • Validation des hypothèses métier : l'application est-elle utilisée de la façon que vous aviez anticipée ?

La plupart des tempéraments humains ont tendance à se figer en cas de crise. La formation et la pratique vous permettront de dépasser cet instinct. C'est à cela que servent les exercices d'évacuation incendie. De même, certaines compagnies aériennes proposent des formations au crash aérien. Les grandes entreprises consacrent une part importante de leur budget à la planification de la récupération d'urgence. Pour prendre connaissance des pratiques recommandées, vous pouvez lire l'article sur l'implémentation de la récupération d'urgence par Microsoft IT dans le centre de données.

Nous souhaitons simplement mettre en avant quelques techniques qui permettent d'accélérer le dépannage en cas de problème. Le fait de savoir que votre application est conçue de façon à faciliter le dépannage peut réduire le stress en cas de problème et le délai nécessaire au dépannage du site. Une analyse du coût/bénéfice déterminera le niveau de tolérance de panne qui sera intégré à votre système. Par exemple, est-il justifié de payer le coût supplémentaire d'une sauvegarde à chaud fournie par Traffic Manager afin de réduire le temps d'interruption ?

Windows Azure Traffic Manager vous permet de gérer et distribuer le trafic entrant auprès de vos services hébergés Windows Azure, qu'ils soient déployés dans le même centre de données ou dans différents centres internationaux. Il permet de configurer un service de basculement de telle sorte que si votre service principal rencontre une défaillance, le trafic est envoyé au service disponible suivant dans une liste. Les logiciels tiers tels qu'Akamai ou Limelight proposent également des solutions d'équilibrage de charge.

Voici un plan en cinq étapes qui permet d'accélérer la résolution.

La première étape de votre plan doit avoir trait à l'identification des problèmes dès qu'ils se produisent. Plus vous identifiez rapidement un problème, plus vite vous pouvez commencer à implémenter votre plan de récupération d'urgence. C'est pour cette raison que la surveillance est importante.

La deuxième étape consiste à identifier l'origine du problème : la plateforme Windows Azure ou votre application. Il convient d'abord de consulter le Tableau de bord des services Windows Azure. Ce site requiert que vous identifiiez les services utilisés par votre application et le centre de données dans lequel le service est déployé. Une seule dégradation du service peut impacter votre application.

Pour surveiller les événements de service de la plateforme Windows Azure, vous pouvez notamment vous abonner aux flux RSS pour votre application. Par exemple, si votre application était hébergée dans le centre de données Centre-Nord des États-Unis, vous devez vous abonner à ce flux RSS.

Le stockage Windows Azure utilise des domaines de défaillance (rack, commutateur réseau, alimentation) pour limiter l'impact des défaillances matérielles. Une idée fausse couramment véhiculée à propos du stockage Windows Azure est que les réplicas de vos données situées en dehors d'un emplacement (par exemple, Centre-Sud des États-Unis) basculent automatiquement vers un réplica. Si le stockage rencontre un problème dans un emplacement donné, l'accès à vos données sera affecté. Ce billet de blog de l'équipe de stockage fournit des détails sur la nouvelle fonctionnalité de géoréplication.

La troisième étape consiste à localiser le problème. Il s'agit peut-être de l'étape la plus difficile dans une application complexe utilisant plusieurs services Windows Azure. La création d'un service sans état permet d'isoler les différentes parties de votre application. Si tous les services dépendants sont exécutés normalement, vous devez déterminer l'intégrité de vos services de calcul. Pour ce faire, ouvrez la section Services hébergés, Comptes de stockage et CDN du Portail de gestion, puis choisissez votre déploiement. Les informations suivantes apparaissent dans la fenêtre de propriétés :

Windows Azure - Propriétés de déploiement

Dans le cas présent, je peux voir qu'au cours des huit derniers jours, mon déploiement s'est exécuté normalement comme calculé par la différence de durée entre l'heure de fin de la dernière opération et la dernière actualisation. Si vous voyez que votre déploiement a été abandonné ou redémarré récemment, ceci peut vous aider à déterminer l'emplacement dans lequel il convient de commencer à chercher. S'il apparaît qu'il s'agit d'un événement de service affectant tous vos déploiements dans un centre de données spécifique, contactez Microsoft immédiatement : (866) 676-6546.

La quatrième étape consiste à effectuer les étapes de dépannage standard (par exemple, consultation des fichiers journaux et des journaux des événements, attachement d'un débogueur, ou utilisation d'outils tels que Procmon ou le Moniteur réseau) pour voir si vous trouvez quelques indications concernant le problème. Le premier emplacement dans lequel effectuer une recherche sur un déploiement de service hébergé Windows Azure est le journal des événements des applications. Vérifiez qu'aucune exception n'est générée par votre application. Ceci peut vous sembler inutile, car le support technique est accessible gratuitement pour le moment. Le fait est que, souvent, vous pouvez rechercher et résoudre les problèmes plus rapidement qu'un ingénieur de support Microsoft expérimenté, qui n'a pas votre connaissance de la portée entière de l'application. Si l'objectif est de remettre en route le site, un examen personnel constitue la meilleure alternative.

La cinquième étape est de contacter le support Microsoft. Pour accélérer la résolution de votre problème, vous devez fournir l'ID fédéré (Windows Live ID) associé au propriétaire du compte de votre abonnement. Il s'agit de l'adresse de messagerie qui permet de se connecter au Portail Clients de Microsoft Online Services pour gérer votre ou vos abonnements. Vous devez également fournir le résultat de votre analyse de la source du problème et les erreurs détectées dans les différents fichiers journaux. L'ingénieur de support Microsoft peut vous demander de l'ajouter comme co-administrateur de votre abonnement afin qu'il puisse voir le Portail de gestion tel qu'il vous apparaît.

À l'instar de la beauté, les performances sont subjectives. À partir de quel seuil les performances deviennent-elles inacceptables ? À l'expiration d'une page ? Même si vous quantifiez le délai de chargement maximal, cela ne garantit pas que les pages se chargeront pour tous vos clients. L'itinéraire DNS et la fiabilité du réseau sont deux facteurs clés pour déterminer les délais de chargement des pages. Par exemple, le fournisseur de services Internet d'un de nos clients basé à Memphis (Tennessee) envoyait le trafic TX à San Antonio en le faisant transiter par Chicago. Microsoft Online Services fournit un outil de test des performances qui mesure les temps de réponse, la bande passante et la qualité globale de la connexion. Si vous voulez voir la latence entre les différents centres de données Microsoft, vous pouvez utiliser les statistiques Azure de Matthew Rosoff.

Une discussion détaillée des performances dépasse l'objet de ce document. Pour prendre connaissance des pratiques recommandées en lien avec le développement sur Windows Azure, consultez l'article TechNet Guide de l'élasticité et de performances de SQL Azure. La résolution des problèmes de performance commence par la définition d'une référence. Pour cette raison, il est vital de collecter les données de performances sur une longue durée. Une fois que vous avez défini le niveau de référence, vous pouvez identifier les tendances et les anomalies.

La plateforme Windows Azure fournit des contrats de niveau de service qui définissent les niveaux de disponibilité/connectivité des différents services. À quoi servent les contrats de niveau de service ? Mon fournisseur de services Internet m'a informé une fois que je ne devais pas utiliser ma connexion pour mes activités professionnelles, car mon package n'incluait pas de contrat de niveau de service. La fiabilité est semblable aux performances en ce qu'elle dépend fortement de la connexion réseau sous-jacente du client et est réellement subjective. Les liens ci-dessus peuvent vous aider à comprendre les performances de votre connexion réseau.

Une erreur fréquente consiste à supposer que les contrats de niveau de service de la plateforme Windows Azure garantissent les mêmes contrats de niveau de service pour votre application. En premier lieu, certaines personnes ne lisent pas la deuxième phrase :

Pour le calcul, si vous déployez au moins deux instances de rôle dans différents domaines d'erreur et de mise à niveau, nous garantissons que vos rôles accessibles via Internet disposeront d'une connectivité durant au moins 99,95 % du temps

Il manque une précision d'importance à cette phrase : « au moins deux instances de rôle par rôle ». En d'autres termes, en ayant un rôle web et un rôle de travail avec une instance chacun, votre application ne sera pas disponible chaque fois que le système d'exploitation hôte est mis à jour ou que le système est réparé. Le calcul Windows Azure utilise des domaines d'erreur pour garantir le respect du contrat SLA.

Une autre fausse idée est que si vous choisissez une version de système d'exploitation particulière, il n'y aura pas d'interruption en raison des mises à jour du système d'exploitation. Si cela s'applique au système d'exploitation invité exécuté sur votre instance, ce n'est pas le cas du système d'exploitation hôte exécuté sur la machine physique exécutée dans le centre de données.

Pour optimiser la fiabilité, vous devez surveiller votre site en interne à l'aide des données des diagnostics Windows Azure, et en externe à l'aide des programmes AzureCheck d'Apica, Gomez de Compuware ou Pingdom. Vous devez également vérifier que vous disposez des derniers patches de sécurité et avez défini un plan de vérification des modifications de code.

Lorsque vous créez une application avec Visual Studio, le comportement par défaut consiste à définir la version du système d'exploitation invité dans le fichier ServiceConfiguration.cscfg comme suit :

osFamily="1" osVersion="*"

Vous recevrez ainsi les mises à jour automatiques, lesquelles représentent un des principaux avantages de PaaS. Pour autant; ceci est loin d'être optimal, car vous n'utilisez pas la dernière version du système d'exploitation (Windows Server 2008 R2). Pour cela, la configuration doit être définie comme suit :

osFamily="2" osVersion="*"

De nombreux clients décident malheureusement de verrouiller une version particulière du système d'exploitation dans l'espoir d'accroître le temps de disponibilité en évitant les mises à jour du système d'exploitation invité. Il n'existe qu'une stratégie raisonnable pour les clients d'entreprise qui teste chaque mise à jour dans un environnement intermédiaire, puis planifie une permutation d'adresses IP virtuelles vers leur application stratégique exécutée dans un environnement de production. Pour les autres clients qui ne testent pas chaque mise à jour du système d'exploitation invité, le fait de ne pas configurer les mises à jour automatiques met votre application Windows Azure en péril.

Quel est le plan applicable lorsque vous devez mettre à jour votre service, notamment en cas d'urgence ? Cette étape souvent ignorée peut être la différence entre avoir un site à l'arrêt et devoir résoudre un problème mineur dans l'environnement intermédiaire. Si beaucoup de temps et d'efforts sont consacrés à la planification initiale et à la publication d'une application Windows Azure, on part souvent du principe qu'il n'est pas nécessaire d'effectuer des tests approfondis pour les mises à jour, car il est plus facile de corriger une modification que dans un produit physique. Les régressions peuvent être rapidement corrigées. Malheureusement, elles peuvent facilement créer une défaillance irrémédiable.

Chaque modification apportée à une application de production doit être testée avant son déploiement final en production. Le temps supplémentaire nécessaire est bien employé au vu des conséquences possibles d'une défaillance. Pour plus d'informations, consultez Présentation de la mise à jour d'un service Windows Azure.

Nous vous remercions d'avoir pris le temps de prendre connaissance du contenu de cet article. N'hésitez pas à nous faire part de vos commentaires sur les solutions qui vous sont utiles. Les coûts associés à l'interruption de votre service doivent être comparés à ceux liés à la collecte des données de diagnostic. Ce calcul doit être effectué avant le déploiement vers l'environnement de production. Le travail nécessaire au développement d'applications Windows Azure fiables n'est ni nouveau, ni révolutionnaire, ni complexe du point de vue technique. Les concepteurs et développeurs doivent simplement tenir compte des problèmes potentiels pouvant apparaître dans leurs applications et appliquer les pratiques décrites dans cet article.

  • Christian Tom, « Help with Windows Azure role stuck in Initializing/Busy/Stopped state », Blog, 25 février 2011.

  • Cross Andy, « Tracing to Azure Compute Emulator SDK V1.3 », Blog, 22 janvier 2011.

  • Haley Jason, « How To: Query Azure Log Tables with LINQPad », Blog, 28 janvier 2010.

  • Hardin David, « Configuring WAD via the diagnostics.wadcfg Config File », Blog, 29 mars 2011.

  • Kelly Mike, « Take Control of Logging and Tracing in Windows Azure », MSDN Magazine, juin 2010.

  • Mackenzie Neil, « Custom Diagnostics in Windows Azure », Blog, 8 décembre 2009.

  • Makogon David, « Azure Tip of the Day: Separate Diagnostic Storage Account », Blog, 15 août 2010.

  • Marx Steve, « Capturing Filtered Windows Events with Windows Azure Diagnostics », Blog, 21 avril 2010.

  • Mladenov Toddy, « Collecting Event Logs in Windows Azure », Blog, 2 mai 2010.

  • Myers Walter, « Setting Up Performance Counters In Your Azure Web and Worker Roles », Blog, 31 janvier 2011.

  • Nakashima Jim, « Using IntelliTrace to debug Windows Azure Cloud Services », Blog, 7 juin 2010.

  • O’Neil Jim, « 500 and Other Errors in Azure Deployments Blog », Blog, 11 avril 2011.

  • Stiefel Michael, « Why Did My Azure Application Crash? Using the Windows Azure Diagnostics API to Find Code Problems », Blog, 8 septembre 2011.

  • Washam Michael, « Managing Log Files with Windows Azure PowerShell Cmdlets 2.0 », Blog, 20 septembre 2011.

  • Williamson Kevin, « Windows Azure Role Architecture », Blog, 5 mai 2011.

  • Portail de gestion Windows Azure http://manage.windowsazure.com.

  • Cours de formation sur la plateforme Windows Azure - Exercice 3 - Surveillance des applications dans Windows Azure.

  • Portail Windows Azure http://www.microsoft.com/windowsazure/

 

Structure

Clusters logiques de machines qui fournissent un environnement pour l'exécution des rôles dans une machine virtuelle.

Mise en mémoire tampon des événements relatifs aux demandes ayant échoué (FREB, Failed Request Event Buffering)

Suivi des demandes ayant échoué (anciennement FREB)

Portail de gestion

Le portail de gestion Windows Azure est un portail administratif qui permet de gérer, déployer et surveiller les services Windows Azure. Le portail de gestion est accessible à l'adresse http://manage.windowsazure.com.

REST

REpresentational State Transfer. Conception logicielle qui utilise une architecture client-serveur sans état dans laquelle les services web sont affichés comme des ressources et peuvent être identifiés par leur URL.

Contrat SLA

Contrat de niveau de service

Machine virtuelle

Émulation logicielle d'un ordinateur exécuté dans une partition isolée d'un ordinateur réel.

WAD

Diagnostics Windows Azure

Rôle web

Rôle personnalisé pour la programmation d'applications web pris en charge par IIS 7 et ASP.NET.

Rôle de travail

Rôle utile pour le développement généralisé qui peut effectuer des opérations de traitement en arrière-plan pour un rôle web.

Cette annexe se concentre sur le code requis pour configurer les diagnostics Windows Azure. La méthode RoleEntryPoint.OnStart est appelée pour vous donner l'opportunité de personnaliser le démarrage de votre instance de rôle. Vous pouvez fournir votre propre implémentation de OnStart pour exécuter le code requis pour configurer les diagnostics Windows Azure pour votre rôle.

public override bool OnStart()
{
    string sSource = "WaAppAgent";
    string sEvent = null;

    try
    {
        DiagnosticMonitorConfiguration config = DiagnosticMonitor.GetDefaultInitialConfiguration();

        // Set an overall quota of 8GB.
        config.OverallQuotaInMB = 8192;

        // Set the sub-quotas and make sure it is less than the OverallQuotaInMB set above
        config.Logs.BufferQuotaInMB = 1024;
        config.Directories.BufferQuotaInMB = 0; // Use the rest of the storage here
        config.WindowsEventLog.BufferQuotaInMB = 1024;
        config.PerformanceCounters.BufferQuotaInMB = 1024;
        config.DiagnosticInfrastructureLogs.BufferQuotaInMB = 1024;

        // Get ScheduledTransferPeriod setting from ServiceConfiguration.cscfg and then set it 
        var myScheduledTransferPeriod = RoleEnvironment.GetConfigurationSettingValue("ScheduledTransferPeriod");
        TimeSpan myTimeSpan = TimeSpan.FromMinutes(Convert.ToDouble(myScheduledTransferPeriod));
        config.Logs.ScheduledTransferPeriod = myTimeSpan;
        config.Directories.ScheduledTransferPeriod = myTimeSpan;
        config.WindowsEventLog.ScheduledTransferPeriod = myTimeSpan;
        config.PerformanceCounters.ScheduledTransferPeriod = myTimeSpan;
        config.DiagnosticInfrastructureLogs.ScheduledTransferPeriod = myTimeSpan;

        // Get LogLevelFilter setting from ServiceConfiguration.cscfg and then set it
        var LogLevelFilter = RoleEnvironment.GetConfigurationSettingValue("LogLevelFilter");
        var myLogLevel = LogLevel.Undefined;
        switch (LogLevelFilter)
        {
            case ("Information"):
                myLogLevel = LogLevel.Information;
                break;
            case ("Verbose"):
                myLogLevel = LogLevel.Verbose;
                break;
            case ("Warning"):
                myLogLevel = LogLevel.Warning;
                break;
            case ("Critical"):
                myLogLevel = LogLevel.Critical;
                break;
            case ("Error"):
                myLogLevel = LogLevel.Error;
                break;
            default:
                break;
        } 

        // Filter what will be sent to persistent storage.
        config.Logs.ScheduledTransferLogLevelFilter = myLogLevel;
        config.DiagnosticInfrastructureLogs.ScheduledTransferLogLevelFilter = myLogLevel;
        config.WindowsEventLog.ScheduledTransferLogLevelFilter = myLogLevel;

        // Add in configuration settings for Windows Event logs
        config.WindowsEventLog.DataSources.Add("Application!*");
        config.WindowsEventLog.DataSources.Add("System!*");

        // Add a custom directory transfer
        DirectoryConfiguration directoryConfiguration = new DirectoryConfiguration();
        directoryConfiguration.Container = "wad-custom-logs";
        directoryConfiguration.DirectoryQuotaInMB = 0;
        directoryConfiguration.Path = @"c:\logs";
        config.Directories.DataSources.Add(directoryConfiguration);
 

        // Enable full crash dump collection.
        CrashDumps.EnableCollection(true);

        // Use 30 seconds for the perf counter sample rate.
        TimeSpan perfSampleRate = TimeSpan.FromSeconds(30D);

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Memory\Available Bytes",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Processor(_Total)\% Processor Time",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Process(w3wp)\% Processor Time",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Process(w3wp)\Private Bytes",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Process(w3wp)\Thread Count",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\.NET CLR Interop(_Global_)\# of marshalling",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
             CounterSpecifier = @"\.NET CLR Jit(_Global_)\% Time in Jit",
             SampleRate = perfSampleRate
         });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\.NET CLR Loading(_Global_)\% Time Loading",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\.NET CLR LocksAndThreads(_Global_)\Contention Rate / sec",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\.NET CLR Memory(_Global_)\# Bytes in all Heaps",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\.NET CLR Networking(_Global_)\Connections Established",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\.NET CLR Remoting(_Global_)\Remote Calls/sec",
            SampleRate = perfSampleRate
        });

        // Apply the updated configuration to the diagnostic monitor.
        // The first parameter is for the connection string configuration setting.
        DiagnosticMonitor.Start("Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString", config);

        sEvent = "Management OnStart called diagnostics";
        EventLog.WriteEntry(sSource, sEvent, EventLogEntryType. Information, 0);
    }
    catch (Exception e)
    {
        sEvent = "Management OnStart Event: " + e.Message;
        EventLog.WriteEntry(sSource, sEvent, EventLogEntryType.Error, 0);
    }

    return base.OnStart();
}

Cette annexe se concentre sur le code requis pour configurer les diagnostics Windows Azure dans un rôle de travail.

public override bool OnStart()
{
    // Set the maximum number of concurrent connections 
    ServicePointManager.DefaultConnectionLimit = 12;
    string sSource = "WaAppAgent";
    string sEvent = "WorkerRole OnStart Event: ";

    try
    {
        // For information on handling configuration changes
        // see the MSDN topic at http://go.microsoft.com/fwlink/?LinkId=166357.

        DiagnosticMonitorConfiguration config = DiagnosticMonitor.GetDefaultInitialConfiguration();

        // Set an overall quota of 8GB.
        config.OverallQuotaInMB = 8192;
        // Set the sub-quotas and make sure it is less than the OverallQuotaInMB set above
        config.Logs.BufferQuotaInMB = 1024;
        config.Directories.BufferQuotaInMB = 0; // Use the rest of the storage here
        config.WindowsEventLog.BufferQuotaInMB = 1024;
        config.PerformanceCounters.BufferQuotaInMB = 1024;
        config.DiagnosticInfrastructureLogs.BufferQuotaInMB = 1024;

        // Get ScheduledTransferPeriod setting from ServiceConfiguration.cscfg and then set it 
        var myScheduledTransferPeriod = RoleEnvironment.GetConfigurationSettingValue("ScheduledTransferPeriod");
        TimeSpan myTimeSpan = TimeSpan.FromMinutes(Convert.ToDouble(myScheduledTransferPeriod));
        config.Logs.ScheduledTransferPeriod = myTimeSpan;
        config.Directories.ScheduledTransferPeriod = myTimeSpan;
        config.WindowsEventLog.ScheduledTransferPeriod = myTimeSpan;
        config.PerformanceCounters.ScheduledTransferPeriod = myTimeSpan;
        config.DiagnosticInfrastructureLogs.ScheduledTransferPeriod = myTimeSpan;

        // Get LogLevelFilter setting from ServiceConfiguration.cscfg and then set it
        var LogLevelFilter = RoleEnvironment.GetConfigurationSettingValue("LogLevelFilter");
        var myLogLevel = LogLevel.Undefined;
        switch (LogLevelFilter)
        {
            case ("Information"):
                myLogLevel = LogLevel.Information;
                break;
            case ("Verbose"):
                myLogLevel = LogLevel.Verbose;
                break;
            case ("Warning"):
                myLogLevel = LogLevel.Warning;
                break;
            case ("Critical"):
                myLogLevel = LogLevel.Critical;
                break;
            case ("Error"):
                myLogLevel = LogLevel.Error;
                break;
            default:
                break;
        }

        // Filter what will be sent to persistent storage.
        config.Logs.ScheduledTransferLogLevelFilter = myLogLevel;
        config.DiagnosticInfrastructureLogs.ScheduledTransferLogLevelFilter = myLogLevel;
        config.WindowsEventLog.ScheduledTransferLogLevelFilter = myLogLevel;

        // Add in configuration settings for Windows Event logs
        config.WindowsEventLog.DataSources.Add("Application!*");
        config.WindowsEventLog.DataSources.Add("System!*");

        // Add a custom directory transfer
        DirectoryConfiguration directoryConfiguration = new DirectoryConfiguration();
        directoryConfiguration.Container = "wad-custom-logs";
        directoryConfiguration.DirectoryQuotaInMB = 0;
        directoryConfiguration.Path = @"c:\logs";
        config.Directories.DataSources.Add(directoryConfiguration);

        // Enable full crash dump collection.
        CrashDumps.EnableCollection(true);

        // Use 30 seconds for the perf counter sample rate.
        TimeSpan perfSampleRate = TimeSpan.FromSeconds(30D);

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Memory\Available Bytes",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Processor(_Total)\% Processor Time",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Process(WaWorkerHost)\% Processor Time",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Process(WaWorkerHost)\Private Bytes",
            SampleRate = perfSampleRate
        }); 
                
        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Process(WaWorkerHost)\Thread Count",
            SampleRate = perfSampleRate
        });

        // Apply the updated configuration to the diagnostic monitor.
        // The first parameter is for the connection string configuration setting.
        DiagnosticMonitor.Start("Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString", config);

    }
    catch (Exception e)  
        {
                sEvent += e.Message;
                EventLog.WriteEntry(sSource, sEvent, EventLogEntryType.Error, 0);
        } 
            
    return base.OnStart();   
}

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="Windows_Azure_Full_Diagnostics" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WebRole name="WebRole1">
    <Sites>
      <Site name="Web">
        <Bindings>
          <Binding name="Endpoint1" endpointName="Endpoint1" />
        </Bindings>
      </Site>
    </Sites>
    <Endpoints>
      <InputEndpoint name="Endpoint1" protocol="http" port="8080" />
    </Endpoints>
    <Imports>
      <Import moduleName="Diagnostics" />
      <Import moduleName="RemoteAccess" />
      <Import moduleName="RemoteForwarder" />
    </Imports>
    <ConfigurationSettings>
      <Setting name="ScheduledTransferPeriod" />
      <Setting name="LogLevelFilter" />
    </ConfigurationSettings>
    <LocalResources>
      <LocalStorage name="DiagnosticStore" cleanOnRoleRecycle="false" sizeInMB="8192" />
    </LocalResources>
  </WebRole>
  <WorkerRole name="WorkerRole1" vmsize="Small">
    <Imports>
      <Import moduleName="Diagnostics" />
      <Import moduleName="RemoteAccess" />
    </Imports>
    <LocalResources>
      <LocalStorage name="DiagnosticStore" sizeInMB="8192" cleanOnRoleRecycle="false" />
    </LocalResources>
    <ConfigurationSettings>
      <Setting name="ScheduledTransferPeriod" />
      <Setting name="LogLevelFilter" />
    </ConfigurationSettings>
  </WorkerRole>
</ServiceDefinition>

noteRemarque
ce fichier de configuration est utilisé localement, avec l'émulateur de calcul.

<?xml version="1.0" encoding="utf-8"?>
<ServiceConfiguration serviceName="Windows_Azure_Full_Diagnostics" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" osFamily="2" osVersion="*">
  <Role name="WebRole1">
    <Instances count="1" />
    <ConfigurationSettings>
      <Setting name="ScheduledTransferPeriod" value="1" />
      <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />
      <Setting name="LogLevelFilter" value="Verbose" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.Enabled" value="true" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountUsername" value="me" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountEncryptedPassword" value="MIIBnQYJKoZIhvcNAQcDoIIBjjCCAYoCAQAxggFOMIIBSgIBADAyMB4xHDAaBgNVBAMME1dpbmRvd3MgQXp1cmUgVG9vbHMCEDra5x6UQkuIRHdUChkiglEwDQYJKoZIhvcNAQEBBQAEggEAp8ADE0ov0pKTFo6V1AI94NmsUr8YcQ/dl4M63zbBQkrjSvqqzgofMcMwxYVO8gTwmr3eXawTNp2fbPdN68ZynNgRwEHBm67QP3y6lcAFvx8Amxvp8GZ6qxpAYGE8LhpqBNzoel55mot6IZg0I3qfXtl6SHyfLcyGuPv3nDEzhuYGuPSFR+UF82G2ZK0omLzSuI3KQcbFyTxaUYDIu/fSNOkHVOWwgpNND3SIvg+nSHfS38w+nskAA7bo7oN06LnC+3lLNRrpoKsPBaqogqfyhTkivc3+AJoQ6UAHIyyAJU6kfp4iP7gMl0ZU1mLVeqX5oDwmywf9FGRf7vSn2uEfiTAzBgkqhkiG9w0BBwEwFAYIKoZIhvcNAwcECAw305eQdOSogBA6i8i7rTruZOxAadm1g545" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountExpiration" value="2011-12-31T23:59:59.0000000-05:00" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteForwarder.Enabled" value="true" />
    </ConfigurationSettings>
    <Certificates>
      <Certificate name="Microsoft.WindowsAzure.Plugins.RemoteAccess.PasswordEncryption" thumbprint="D91092F38C839BE56787A0528591E49510FCC711" thumbprintAlgorithm="sha1" />
    </Certificates>
  </Role>
  <Role name="WorkerRole1">
    <Instances count="1" />
    <ConfigurationSettings>
      <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />
      <Setting name="ScheduledTransferPeriod" value="1" />
      <Setting name="LogLevelFilter" value="Verbose" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.Enabled" value="true" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountUsername" value="me" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountEncryptedPassword" value="MIIBnQYJKoZIhvcNAQcDoIIBjjCCAYoCAQAxggFOMIIBSgIBADAyMB4xHDAaBgNVBAMME1dpbmRvd3MgQXp1cmUgVG9vbHMCEDra5x6UQkuIRHdUChkiglEwDQYJKoZIhvcNAQEBBQAEggEAp8ADE0ov0pKTFo6V1AI94NmsUr8YcQ/dl4M63zbBQkrjSvqqzgofMcMwxYVO8gTwmr3eXawTNp2fbPdN68ZynNgRwEHBm67QP3y6lcAFvx8Amxvp8GZ6qxpAYGE8LhpqBNzoel55mot6IZg0I3qfXtl6SHyfLcyGuPv3nDEzhuYGuPSFR+UF82G2ZK0omLzSuI3KQcbFyTxaUYDIu/fSNOkHVOWwgpNND3SIvg+nSHfS38w+nskAA7bo7oN06LnC+3lLNRrpoKsPBaqogqfyhTkivc3+AJoQ6UAHIyyAJU6kfp4iP7gMl0ZU1mLVeqX5oDwmywf9FGRf7vSn2uEfiTAzBgkqhkiG9w0BBwEwFAYIKoZIhvcNAwcECAw305eQdOSogBA6i8i7rTruZOxAadm1g545" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountExpiration" value="2011-12-31T23:59:59.0000000-05:00" />
    </ConfigurationSettings>
    <Certificates>
      <Certificate name="Microsoft.WindowsAzure.Plugins.RemoteAccess.PasswordEncryption" thumbprint="D91092F38C839BE56787A0528591E49510FCC711" thumbprintAlgorithm="sha1" />
    </Certificates>
  </Role>
</ServiceConfiguration>

Voici un exemple de fichier diagnostics.wadcfg pour un rôle web.

<?xml version="1.0" encoding="utf-8" ?>
<DiagnosticMonitorConfiguration xmlns="http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration"
      configurationChangePollInterval="PT1M"
      overallQuotaInMB="4096">
  <DiagnosticInfrastructureLogs bufferQuotaInMB="0"
     scheduledTransferLogLevelFilter="Verbose"
     scheduledTransferPeriod="PT1M" />
  <Logs bufferQuotaInMB="0"
     scheduledTransferLogLevelFilter="Verbose"
     scheduledTransferPeriod="PT1M" />
  <Directories bufferQuotaInMB="0"
     scheduledTransferPeriod="PT1M">

    <!-- These three elements specify the special directories 
           that are set up for the log types -->
    <CrashDumps container="wad-crash-dumps" directoryQuotaInMB="0" />
    <FailedRequestLogs container="wad-frq" directoryQuotaInMB="0" />
    <IISLogs container="wad-iis" directoryQuotaInMB="0" />
  </Directories>

  <PerformanceCounters bufferQuotaInMB="0" scheduledTransferPeriod="PT1M">
    <!-- The counter specifier is in the same format as the imperative 
           diagnostics configuration API -->
    <PerformanceCounterConfiguration counterSpecifier="\Memory\Available Bytes" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\Processor(_Total)\% Processor Time" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\Process(w3wp)\% Processor Time" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\Process(w3wp)\Private Bytes" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\Process(w3wp)\Thread Count" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR Interop(_Global_)\# of marshalling" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR Loading(_Global_)\% Time Loading" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR LocksAndThreads(_Global_)\Contention Rate / sec" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR Memory(_Global_)\# Bytes in all Heaps" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR Networking(_Global_)\Connections Established" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR Remoting(_Global_)\Remote Calls/sec" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR Jit(_Global_)\% Time in Jit" sampleRate="PT30S" />
  </PerformanceCounters>
  <WindowsEventLog bufferQuotaInMB="0"
     scheduledTransferLogLevelFilter="Verbose"
     scheduledTransferPeriod="PT1M">
    <!-- The event log name is in the same format as the imperative 
           diagnostics configuration API -->
    <DataSource name="Application!*" />
    <DataSource name="System!*" />
  </WindowsEventLog>
</DiagnosticMonitorConfiguration>

Il s'agit de la configuration par défaut écrite dans le conteneur d'objets blob wad-control-container.

<?xml version="1.0"?>
<ConfigRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <DataSources>
    <OverallQuotaInMB>4080</OverallQuotaInMB>
    <Logs>
      <BufferQuotaInMB>0</BufferQuotaInMB>
      <ScheduledTransferPeriodInMinutes>0</ScheduledTransferPeriodInMinutes>
      <ScheduledTransferLogLevelFilter>Undefined</ScheduledTransferLogLevelFilter>
    </Logs>
    <DiagnosticInfrastructureLogs>
      <BufferQuotaInMB>0</BufferQuotaInMB>
      <ScheduledTransferPeriodInMinutes>0</ScheduledTransferPeriodInMinutes>
      <ScheduledTransferLogLevelFilter>Undefined</ScheduledTransferLogLevelFilter>
    </DiagnosticInfrastructureLogs>
    <PerformanceCounters>
      <BufferQuotaInMB>0</BufferQuotaInMB>
      <ScheduledTransferPeriodInMinutes>0</ScheduledTransferPeriodInMinutes>
      <Subscriptions />
    </PerformanceCounters>
    <WindowsEventLog>
      <BufferQuotaInMB>0</BufferQuotaInMB>
      <ScheduledTransferPeriodInMinutes>0</ScheduledTransferPeriodInMinutes>
      <Subscriptions />
      <ScheduledTransferLogLevelFilter>Undefined</ScheduledTransferLogLevelFilter>
    </WindowsEventLog>
    <Directories>
      <BufferQuotaInMB>0</BufferQuotaInMB>
      <ScheduledTransferPeriodInMinutes>0</ScheduledTransferPeriodInMinutes>
      <Subscriptions>
        <DirectoryConfiguration>
          <Path>C:\Users\me\AppData\Local\dftmp\Resources\c95f5289-7d10-4bff-b105-198904c9ad93\directory\DiagnosticStore\FailedReqLogFiles</Path>
          <Container>wad-iis-failedreqlogfiles</Container>
          <DirectoryQuotaInMB>1024</DirectoryQuotaInMB>
        </DirectoryConfiguration>
        <DirectoryConfiguration>
          <Path>C:\Users\me\AppData\Local\dftmp\Resources\c95f5289-7d10-4bff-b105-198904c9ad93\directory\DiagnosticStore\LogFiles</Path>
          <Container>wad-iis-logfiles</Container>
          <DirectoryQuotaInMB>1024</DirectoryQuotaInMB>
        </DirectoryConfiguration>
        <DirectoryConfiguration>
          <Path>C:\Users\me\AppData\Local\dftmp\Resources\c95f5289-7d10-4bff-b105-198904c9ad93\directory\DiagnosticStore\CrashDumps</Path>
          <Container>wad-crash-dumps</Container>
          <DirectoryQuotaInMB>1024</DirectoryQuotaInMB>
        </DirectoryConfiguration>
      </Subscriptions>
    </Directories>
  </DataSources>
  <IsDefault>true</IsDefault>
</ConfigRequest>

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.
Microsoft réalise une enquête en ligne pour recueillir votre opinion sur le site Web de MSDN. Si vous choisissez d’y participer, cette enquête en ligne vous sera présentée lorsque vous quitterez le site Web de MSDN.

Si vous souhaitez y participer,
Afficher:
© 2014 Microsoft