Traces en temps réel sur Azure (1/2) | real time traces on Azure (1/2)

Français

English

Quand on déploie et exécute une application sur Windows Azure, comme on n’a pas accès directement à la machine, il est nécessaire d’avoir des traces de ce qui se passe, de façon à pouvoir corriger rapidement d’éventuels bugs.D’une façon générale, instrumenter son application est important, mais cela devient encore plus important pour des applications dans les nuages.De façon à faire cela avec Windows Azure, la façon classique est d’utiliser l’espace de noms Microsoft.WindowsAzure.Diagnostics. Cette API est assez puissante, mais elle envoie les logs dans le stockage Azure et il est donc nécessaire de récupérer ces données pour les lire.Pour des traces ad-hoc en début de développement, recevoir les traces dans une application locale dès qu’elles ont été émises peut être beaucoup plus confortable.Pour cela, il suffit de réutiliser le code fourni par Clemens Vasters dans le billet de son carnet en ligne:  https://blogs.msdn.com/clemensv/archive/2009/11/23/the-rough-setup-script-for-pdc09-svc18-getting-dinnernow-to-run-on-windows-azure.aspxUne fois téléchargé, il vous faut le dossier DinnerNow-SVC18-PDC09\common\diags où se trouve la solution CloudTrace.

When you deploy and run an application on Windows Azure, as you don’t get access to the machine executing your application, you need to get traces about what’s going on, in order to be able to quickly fix the app.Generally speaking instrumenting your app is important, but that becomes even more important with a cloud application.In order to achieve this with a Windows Azure application, the usual way is to use Microsoft.WindowsAzure.Diagnostics namespace. This API is quite powerfull but it sends logs to Azure storage, so you have to retrieve data in order to read it.For initial or ad-hoc tracing, receiving the traces in a local application as they are sent by application may be much more comfortable.For this, one just has to leverage Clemens Vasters code provided with this blog post: https://blogs.msdn.com/clemensv/archive/2009/11/23/the-rough-setup-script-for-pdc09-svc18-getting-dinnernow-to-run-on-windows-azure.aspxOnce downloaded, you need to the DinnerNow-SVC18-PDC09\common\diags folder where you get the CloudTrace solution

Si vous travaillez avec Visual Studio 2010, vous pouvez migrer la solution vers Visual Studio 2010.Vous pouvez aussi adapter le code. J’ai ajouté principalement deux choses: un préfixe configurable pour toutes les traces, et un booléen pour ignorer les erreurs de traces. Quand je n’ai pas d’application qui écoute les traces, l’écriture de traces génère des exceptions. Dans certains scénarios, il est préférables de ne pas avoir de traces du tout que de planter en essayant de les écrire.J’ai aussi ajouté une configuration pour un proxy http, ce qui peut servir dans des cas où les traces sont écrites depuis un endroit où on ne peut accéder à Azure Service Bus que via ce proxy HTTP. Bien sûr, cela n’est pas le cas pour des applications déployées dans Azure.Voici des extraits des changements typiques de code:

If you work with Visual Studio 2010, you can migrate the solution to Visual Studio 2010.You can also adapt the code. I mainly added 2 things: a configurable prefix for all traces, and a boolean to ignore trace errors. When I have no listener at all, the trace throws an exception. In some scenarios, it’s better to have silently no trace than to fail. I also added a configuration for an Http Web proxy which might be usefull in cases where the trace are written from a place that can connect to Azure Service Bus only thru an Http Web Proxy. Of course, this is not the case from an application deployed in Azure.Here are some code excepts of the typical changes:

Avant de pouvoir tester les traces, on doit configurer le service bus d’Azure. On a besoin d’un issuer et d’une clef secrète pour l’envoyeur, ainsi que pour le receveur (cela pourrait être deux fois les mêmes, mais créons-en deux différents).La première étape est de configurer l’outil en ligne de commande acm.exe qui est typiquement installé à C:\Program Files\Windows Azure platform AppFabric SDK\V1.0\Tools.Remplissons le fichier Acm.exe.config. Dans mon cas, le service namespace est benjguin, comme on le voit dans le portail appfabric.azure.com. Depuis ce portail, je peux aussi avoir la clef de gestion.

Before being able to test the trace, we need to configure Azure Service Bus. We need an issuer and a key for the writer, and one for the listener (they could be the same, but let’s create two).First step is to configure acm.exe command line tool, which is typically installed at C:\Program Files\Windows Azure platform AppFabric SDK\V1.0\Tools.Let’s populate information of the Acm.exe.config file. In my case, the service namespace is benjguin, as shown in the appfabric.azure.com portal. From that portal, I can also get the management key.

Il faut ajouter au namespace la chaine “-sb” dans le fichier Acm.exe.config, et la clef de gestion doit être copiée:

The namespace must be appended an “-sb” suffix in the Acm.exe.config file, and the key must be copied:

Maintenant, nous avons renseigné la clef de gestion et le namespace dans l’outil et nous allons pouvoir utiliser acm.exe dans les scripts suivants:

Now, we have registered the management key and the namespace in the tool, and we’ll be able to use the acm.exe tool like in the following script:

set acm="C:\Program Files\Windows Azure platform AppFabric SDK\V1.0\Tools\acm.exe"
%acm% create issuer -name:"AzureTraceReader" -issuername:AzureTraceReader -autogeneratekey -algorithm:Symmetric256BitKey
%acm% create issuer -name:"AzureTraceWriter" -issuername:AzureTraceWriter -autogeneratekey -algorithm:Symmetric256BitKey
%acm% GetAll issuer
@echo ---------------------------------------------------------
%acm% GetAll scope
pause

le script crée 2 issuers et fournit les informations suivantes:- les id des issuers (et les clefs secrètes)- l’id de scope

The script will create 2 issuers, and provide you with the following information:- the issuers ids (and secret keys)- the scope id

Cela nous amène au script suivant qui donne les droits aux issuers AzureTraceReader et AzureTraceWriter (les *** sont à remplacer par vos secrets).

This brings us to the next script that gives rights to the AzureTraceReader and AzureTraceWriter issuers (*** are to be replaced by your secrets)

 

set acm="C:\Program Files\Windows Azure platform AppFabric SDK\V1.0\Tools\acm.exe"

SET scopeid=scp_***

rem SET issuername=AzureTraceReader
rem SET issuerid=iss_***
%acm% create rule -name:%issuername%Listen -scopeid:%scopeid% -inclaimissuerid:%issuerid% -inclaimtype:Issuer -inclaimvalue:%issuername% -outclaimtype:net.windows.servicebus.action -outclaimvalue:Listen
%acm% create rule -name:%issuername%Send   -scopeid:%scopeid% -inclaimissuerid:%issuerid% -inclaimtype:Issuer -inclaimvalue:%issuername% -outclaimtype:net.windows.servicebus.action -outclaimvalue:Send

SET issuername=AzureTraceWriter
SET issuerid=iss_***
%acm% create rule -name:%issuername%Listen -scopeid:%scopeid% -inclaimissuerid:%issuerid% -inclaimtype:Issuer -inclaimvalue:%issuername% -outclaimtype:net.windows.servicebus.action -outclaimvalue:Listen
%acm% create rule -name:%issuername%Send   -scopeid:%scopeid% -inclaimissuerid:%issuerid% -inclaimtype:Issuer -inclaimvalue:%issuername% -outclaimtype:net.windows.servicebus.action -outclaimvalue:Send

A cette étape, on a 2 issuers avec des droits d’envoi et d’écoute sur le service bus. On peut renseigner les fichiers de configuration des envoyeur et receveur de traces:

At this step, we have 2 issuers with rights to Send and Listen to the service bus. We can populate the trace Reader and trace Writer config files:

Maintenant, on peut juste tester and lançant TraceConsole et TraceTest

Now, we can just test, by running TraceConsole and TraceTest

Dans un prochain billet, on verra comment cela peut être utilisé pour suivre l’exécution d’une application Azure.

In a next post, we’ll see how this can be used to monitor an Azure application.

:-)

Benjamin