Article d’origine publié le mercredi 24 août 2011

Les billets et articles traitant de l’utilisation des diagnostics dans Windows Azure sont légion sur la toile. C’est ce que j’ai pu constater lorsque j’ai dû recenser les différentes sources d’information disponibles sur la question. Problème : les articles que j’ai trouvés portaient sur différentes versions d’Azure. J’ai donc dû faire le tri pour identifier ceux qui seraient concernés par le dernier Kit de développement logiciel (SDK) Azure (1.4). Ce billet vise donc à présenter les principaux arguments pour une utilisation des diagnostics Azure avec la version 1.4 du SDK.

 

Pour commencer, comme vous le savez probablement, Azure intègre un écouteur de suivi chargé d’intercepter vos commandes Trace.* (p.ex., Trace.Write, Trace.WriteLine, Trace.TraceInformation, etc.) et de les stocker dans la mémoire. Toutefois, vous devez faire en sorte que ces informations soient transférées de la mémoire vers un stockage persistant. Vous pouvez pour cela effectuer un transfert manuel des données ou configurer une planification pour que les transferts interviennent automatiquement. En plus de cela, vous pouvez également décider de déplacer les informations des journaux des événements, capturer les compteurs de performance, déplacer les journaux IIS, ainsi que les journaux personnalisés.

 

Outre les outils de journalisation et de débogage classiques tels que ceux cités ci-dessus, vous pouvez également configurer votre déploiement de façon à pouvoir vous connecter au serveur Azure hébergeant votre application via RDP. Vous pouvez également activer IntelliTrace pour un débogage et un dépannage limités dans une application qui a été déployée. Examinons ces différents points.

 

Pour configurer les différentes composantes des diagnostics, tels que la durée de conservation des données dans le stockage, la quantité de stockage à allouer, les compteurs de performance à capturer, etc., le plus simple est d’écrire du code dans le fichier WebRole.cs qui accompagne toute application Azure de rôle Web standard (et je pense que la plupart des fonctionnalités Azure autres que le rôle VM ont quelque chose d’équivalent à une classe WebRole, comme le fichier WorkerRole.cs avec un projet Rôle de travail). Avant de nous pencher sur le code, je vous conseille d’ouvrir votre projet de rôle Azure et de vérifier la zone de l’onglet Configuration intitulée « Spécifier les informations d’identification de compte de stockage pour les résultats de diagnostics : ». Utilisez le bouton de sélection pour sélectionner un compte de stockage que vous possédez dans Azure ; n’utilisez pas de développement local. Cela enregistrera une nouvelle chaîne de connexion dans le projet sous le nom Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString.

 

À présent, intéressons-nous à l’ensemble du code contenu dans la classe de rôle Web. Je reviendrai par la suite sur certains points de détail :

 

public override bool OnStart()

{

   // Pour plus d’informations sur la modification de la configuration,

   // voir la rubrique MSDN à l’adresse http://go.microsoft.com/fwlink/?LinkId=166357.

 

   try

   {

       //initialisation de l’ensemble des paramètres

                Microsoft.WindowsAzure.CloudStorageAccount.SetConfigurationSettingPublisher((configName, configSetter) =>

       {

          configSetter(RoleEnvironment.GetConfigurationSettingValue(configName));

       });

 

       //obtention du compte de stockage par le biais de la chaîne de connexion de diagnostic par défaut

       CloudStorageAccount cs =

          CloudStorageAccount.FromConfigurationSetting(

          "Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString");

 

       //obtention du gestionnaire de diagnostic

       RoleInstanceDiagnosticManager dm = cs.CreateRoleInstanceDiagnosticManager(

          RoleEnvironment.DeploymentId,

          RoleEnvironment.CurrentRoleInstance.Role.Name,

          RoleEnvironment.CurrentRoleInstance.Id);

 

       //obtention de la configuration actuelle

       DiagnosticMonitorConfiguration dc = dm.GetCurrentConfiguration();

 

       //si cette opération échoue, obtention des valeurs à partir du fichier de configuration

       if (dc == null)

          dc = DiagnosticMonitor.GetDefaultInitialConfiguration();

 

       //Journaux Windows Azure

       dc.Logs.BufferQuotaInMB = 10;

       dc.Logs.ScheduledTransferLogLevelFilter = LogLevel.Verbose;

       dc.Logs.ScheduledTransferPeriod = TimeSpan.FromMinutes(5);

 

       //Journaux des événements Windows

       dc.WindowsEventLog.BufferQuotaInMB = 10;

       dc.WindowsEventLog.DataSources.Add("System!*");

       dc.WindowsEventLog.DataSources.Add("Application!*");

       dc.WindowsEventLog.ScheduledTransferPeriod = TimeSpan.FromMinutes(15);

 

       //Compteurs de performance

       dc.PerformanceCounters.BufferQuotaInMB = 10;

       PerformanceCounterConfiguration perfConfig =

          new PerformanceCounterConfiguration();

       perfConfig.CounterSpecifier = @"\Processor(_Total)\% Processor Time";

       perfConfig.SampleRate = System.TimeSpan.FromSeconds(60);

      dc.PerformanceCounters.DataSources.Add(perfConfig);

       dc.PerformanceCounters.ScheduledTransferPeriod = TimeSpan.FromMinutes(10);

 

       //Journaux des demandes ayant échoué

       dc.Directories.BufferQuotaInMB = 10;

       dc.Directories.ScheduledTransferPeriod = TimeSpan.FromMinutes(30);

 

       //Journaux d’infrastructure

       dc.DiagnosticInfrastructureLogs.BufferQuotaInMB = 10;

       dc.DiagnosticInfrastructureLogs.ScheduledTransferLogLevelFilter =

          LogLevel.Verbose;

       dc.DiagnosticInfrastructureLogs.ScheduledTransferPeriod =

          TimeSpan.FromMinutes(60);

 

       //Vidages sur incident

       CrashDumps.EnableCollection(true);

 

       //quota global ; doit être supérieur à la somme de tous les éléments

       dc.OverallQuotaInMB = 5000;

 

       //enregistrement de la configuration

       dm.SetCurrentConfiguration(dc);

   }

   catch (Exception ex)

   {

       System.Diagnostics.Trace.Write(ex.Message);

   }

 

   return base.OnStart();

}

 

À présent, examinons le code de manière un peu plus détaillée. J’ai commencé par me procurer la valeur de la chaîne de connexion utilisée pour les diagnostics dans le but de me connecter au compte de stockage utilisé. J’ai ensuite identifié la classe de configuration du moniteur de diagnostic à partir du compte de stockage. Je peux dès lors passer à la configuration des différentes composantes de journalisation.

 

Les journaux Windows Azure, c’est là où sont enregistrés tous les appels Trace.*. Je les configure pour stocker jusqu’à 10 Mo de données dans la table qu’ils utilisent et pour rendre les écritures persistantes dans la table toutes les 5 minutes, car toutes les écritures détaillées sont plus volumineuses. À propos, pour obtenir la liste des différentes tables et files d’attente dont se sert Windows Azure pour stocker ces données de journalisation, vous pouvez consulter la page http://msdn.microsoft.com/en-us/library/hh180875.aspx et la page http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.diagnostics.diagnosticmonitorconfiguration.aspx. Les journaux d’infrastructure et de diagnostics sont pratiquement identiques.

 

Pour les entrées de l’observateur d’événements, je dois ajouter chaque journal à capturer à la liste des sources de données de la classe WindowsEventLog. Les valeurs que j’ai pu fournir sont Application!*, System!* ou UserData!*. Les autres propriétés sont identiques à celles décrites pour les journaux Windows Azure.

 

Pour les compteurs de performance, il convient de décrire les compteurs à capturer, ainsi que la fréquence à laquelle ils échantillonnent les données. Dans l’exemple ci-dessus, j’ai ajouté un compteur pour le processeur et l’ai configuré pour un échantillonner les données toutes les 60 secondes.

 

Enfin, pour terminer, j’ai activé la capture des vidages sur incident, modifié le quota global pour toutes les données de journalisation à environ 5 Go, puis enregistré les modifications.  Il est très important d’augmenter le quota global, car vous lèverez probablement une exception indiquant que vous ne disposez pas d’un espace de stockage suffisant pour apporter les modifications décrites précédemment. Jusqu’à présent, la valeur 5 Go s’est avérée suffisante, mais il est évident que vos besoins seront peut-être différents.

 

À présent, nous sommes prêts et en mesure de publier l’application. Si vous prévoyez de publier l’application à partir de Visual Studio, il y a d’autres éléments à prendre en compte :

 

 

Dans la boîte de dialogue Paramètres de publication, vous devez activer la case à cocher Activer IntelliTrace ; je vous donnerai davantage d’explications par la suite. Par ailleurs, je vous conseille de cliquer sur le lien Configurer les connexions Bureau à distance… ; parfois, j’ai trouvé que c’était le seul moyen de résoudre un problème. La documentation sur le Bureau à distance n’étant plus tout à fait à jour, permettez-moi de vous suggérer d’utiliser cette boîte de dialogue au lieu de modifier manuellement les fichiers de configuration. La boîte de dialogue qui s’affiche se présente ainsi :

 

 

Les principaux points à noter ici sont les suivants :

  1. Vous pouvez apparemment utiliser n’importe quel certificat associé à l’un de vos fichiers PFX. Notez que vous DEVEZ télécharger ce certificat sur votre service hébergé avant de publier l’application.
  2. Complétez librement le champ Nom d’utilisateur ; un compte local est ensuite créé avec le nom d’utilisateur et le mot de passe que vous avez spécifiés.

 

Il convient à présent de compléter les deux boîtes de dialogue et de publier l’application. Cliquez sur votre application pour la démarrer et assurez-vous que le code de rôle Web s’exécute. Dès lors, vous devriez être en mesure d’examiner les paramètres de diagnostic de l’application et vérifier que vos personnalisations sont implémentées, comme dans l’illustration suivante (Remarque : pour gérer Azure, j’utilise les outils CodePlex téléchargeables gratuitement à l’adresse http://wapmmc.codeplex.com/) :

 

 

Après avoir exécuté le code et attendu la prochaine période de transfert planifiée des journaux Windows Azure, je constate que mes appels Trace.* figurent bien dans la table WADLogsTable, comme dans l’illustration ci-dessous :

 

 

De même, comme j’ai configuré la prise en charge de RDP dans mon application, lorsque je clique sur le rôle Web, je constate que l’option de connexion RDP à l’application est activée dans la barre d’outils du portail des développeurs Azure :

 

 

Ainsi, j’ai désormais accès à l’ensemble des journaux et des suivis de mon application et je peux me connecter aux serveurs via RDP si j’ai besoin d’effectuer des recherches plus approfondies. L’autre fonctionnalité intéressante que j’ai activée est IntelliSense. Je ne la décrirai pas dans ce billet, mais vous pouvez trouver des informations intéressante à la page http://blogs.msdn.com/b/jnak/archive/2010/06/07/using-intellitrace-to-debug-windows-azure-cloud-services.aspx et à la page http://blogs.msdn.com/b/ianhu/archive/2010/03/16/intellitrace-what-we-collect.aspx. Lorsque la fonctionnalité IntelliTrace est activée, cela est indiqué lorsque j’affiche mon service hébergé dans l’Explorateur de serveurs Visual Studio :

 

 

Je peux alors cliquer avec le bouton droit sur une instance dans mon application et sélectionner l’élément de menu Afficher les fichiers journaux IntelliTrace. Les journaux IntelliTrace sont téléchargés depuis Azure et s’ouvrent dans la fenêtre Visual Studio suivante :

 

 

Comme vous pouvez le noter dans l’image, la fenêtre présente les threads qui ont été utilisés, les exceptions qui ont été levées, les informations système, les modules qui ont été chargés, etc. J’ai simulé une exception à titre de test en définissant l’allocation de stockage global pour les informations de diagnostic à 5 Mo. Vous vous souvenez peut-être que j’avais préconisé une toute autre valeur, de l’ordre de 5 Go. Après avoir apporté la modification et publié mon application, j’ai téléchargé les journaux IntelliTrace quelques minutes plus tard. Sans surprise, j’ai trouvé l’erreur mise en évidence ici dans la deuxième page des journaux :

 

 

Somme toute, cette vue d’ensemble complète vous aura permis de découvrir que les fonctionnalités de diagnostic de Windows Azure 1.4 permettent de capturer les événements de suivi, les journaux des événements, les compteurs de performance, les journaux IIS, les vidages sur incident et les fichiers journaux de diagnostic personnalisés. Elles vous permettent éventuellement de vous connecter au serveur pour des besoins de dépannage plus pointu. Enfin, vous pouvez télécharger les journaux IntelliTrace à partir de votre application et procéder à un débogage limité dans l’instance locale de Visual Studio 2010.

Ce billet de blog a été traduit de l’anglais. Vous trouverez la version originale sur Windows Azure 1.4 Diagnostics All Up Overview