Le Bulletin Azure, épisode de news, passe sous une forme écrite. Les épisodes de témoignages continueront d’exister. L’idée est de permettre de suivre les nouvelles annoncées dans le Cloud Cover Show soit en regardant directement en anglais ces épisodes, soit en lisant l’essentiel de ce qui s’y est dit d’un point de vue technique. Vous pouvez aussi faire les deux, c’est-à-dire lire l’article en français de façon à avoir le contexte en tête pour bien comprendre la vidéo en anglais.
Cette forme vous plaît ? Vous voudriez plutôt revenir à la vidéo ? D’autres commentaires ? Faites-le nous savoir dans les commentaires de ce post ou via twitter.
Voici un résumé par écrit et en Français de l’épisode 111 du Cloud Cover Show.
NB: les copies d’écran incluent souvent le time code de façon à ce que vous puissiez aller directement à tel ou tel endroit dans la vidéo.
L’invité est Boris Scholl, Senior Program Manager dans l’équipe des outils Visual Studio pour Windows Azure, il vient présenter les nouveautés pour le PaaS (Cloud Services) et les Web Sites.
Ces améliorations sont avec le SDK 2.0 (sorti en avril 2013) et au delà (on en est au SDK 2.1 début septembre 2013).
On part d’une solution (un Web Role MVC) dans lequel il y a déjà des traces.
Avant le SDK 2.0, il fallait écrire du code dans le RoleEntryPoint pour pouvoir obtenir des informations de diagnostic (classe DiagnosticMonitor). Il y a eu pas mal de demandes des clients pour simplifier cela et l’idée est de passer d’un mode code vers un mode configuration.
Dans cet exemple, on n’a rien dans le RoleEntryPoint: 
On exécute en local l’application qui affiche un inventaire venant d’une base de données: 
On veut par exemple tester dans le cloud avec une base de données Windows Azure SQL Database. On publie, et rien de spécial à propos des diagnostics n’est précisé lors de cette publication: 
Une fois déployé, on constate dans ce scénario une erreur: 
Dans le “Server Explorer”, on a la possibilité de demander les données de diagnostic: 
qui montre qu’on a eu une erreur dans le dernier quart d’heure: 
Cet écran ressemble volontairement à celui d’Intellitrace. Les 15 minutes correspondent à une période de temps où on a une bonne idée des dernières erreurs qui peuvent avoir lieu. Quand l’application a démarré, et s’il y a des erreurs, on les a en général dans le premier quart d’heure. On peut changer cette valeur (15 minutes).
On obtient cette erreur qui vient des “Trace” qui ont été mises dans le code (voir copie d’écran plus haut): 
Cela se fait via le mécanisme classique de copie des données de diagnostic dans le storage (ce qui permet une centralisation sur les grandes fermes), puis récupération depuis l’outil. Le fait que les données de diagnostic soient copiées est lié à la configuration du Diagnostic Monitor qui est faite par Visual Studio (et ce même avant le SDK 2.0): 
quand on coche “Enable Diagnostics” et qu’on ne fournit pas de compte de stockage, c’est le compte de stockage servant au déploiement du package qui est utilisé. En 2.0, les options de configuration ont été étendues avec ces nouvelles options: 
Errors Only: on logue les erreurs pour l’application, en s’appuyant sur le trace listener qui est indiqué dans le fichier de configuration et les erreurs de l’event log également. C’est l’option par défaut. Le but est de ne pas consommer trop de storage avec cette option mais d’avoir tout de même l’essentiel.
NB: on trouvera la documentation de cela à http://msdn.microsoft.com/en-us/library/windowsazure/dn186185.aspx
Dans l’application, on voit que la procédure stockée n’est pas correctement orthographiée: 
Ce qu’on peut faire pour aller plus loin, est d'e changer les paramètres de collecte des informations de diagnostic: 
L’écran montre ce qui est transféré depuis la VM vers le stockage.
La configuration elle-même des diagnostics est dans un blob. C’est depuis cette configuration que l’outil récupère la configuration qu’on voit sur l’écran ci-dessus. On peut changer par exemple de “Error” vers “Verbose”: 
En effet, dans le code, on a une trace en Verbose qui indique le type de serveur SQL utilisé.
On pourrait aussi changer les informations d’event log Windows qui sont collectées: 
On peut aussi ajouter des compteurs de performances: 
Par défaut, on ne collecte rien, car c’est au développeur de choisir le type de compteur qu’il veut, la fréquence à laquelle on veut récupérer les informations, et cela peut générer beaucoup de volume de données.
Il y a aussi une nouvelle fonctionnalité assez cool sur le Buffer Size. Si on remplace “None” par 512 MB, par exemple, on voit dans la barre d’état en bas un changement. On passe de 
à 
Il faut savoir que sur les 4 Go par défaut, l’agent de diagnostics a besoin d’à peu près 500 Mo pour ses besoins propres (Garbage Collector). La barre d’état montre ce qui reste pour les données.
Après avoir modifié la configuration, on peut la sauvegarder et l’appliquer en cliquant sur le bouton OK
Pour récupérer le détail des informations, il suffit de cliquer sur “View all data” 
Cela amène sur la table où sont stockées les données de diagnostic. Le filtre sur les données de la table est rempli par l’outil et cela donne ici: 
et l’on peut modifier cette requête avec le query builder 
et changer la requête: 
Quand est-ce que la configuration est appliquée et prise en compte ?
Lors du déploiement initial dans un cloud service vide typiquement, le fichier de configuration est packagé avec l’application comme on le voit ici: 
dès que le déploiement est fait le diagnostic agent lit cette configuration et met à jour le conteneur wad-control-container qu’on voit ici:
A noter qu’on peut mettre à jour la configuration d’une instance du déploiement uniquement (ici Instance0, si on imagine qu’on a plus d’une instance): 
Il est également possible de mattre à jour la ocnfiguration sur tout le déploiement (toutes les instances): 
Autre précision. Si on modifie la configuration sur une solution déployée vers Verbose comme il a été montré plus haut: 
et qu’on redéploie par mise à jour (update) la solution qui elle est toujours avec le paramètre Error (et non Verbose): 
alors après update, on aura toujours Verbose car le déploiement en mise à jour n’est pas prioritaire sur les mises à jour au runtime. Pour que les paramètres de la solutions soient pris en compte, il faut refaire un déploiement complet (“full deployment”).
En SDK 2.0, il pour que tout soit configuré par défaut correctement (y compris l’Azure trace listener dans le fichier Web.config), il faut dans Visual Studio créer un projet Cloud Service de type Web Application Project (WAP), et non démarrer un projet WAP auquel on ajoute un projet de déploiement cloud service. Dans les notes du Cloud Cover Show, il est écrit:
Update: In the video Boris mentioned that you have to manually add the Azure diagnostics trace listener to the web.config when you add a Windows Azure Cloud Service project to the WAP project.
He just confirmed that this only applies to SDK 2.0. In SDK 2.1 the trace listener is automatically added to the web.config of the WAP project.
Les diagnostics ont aussi été améliorés pour Azure Web Sites. Voici un exemple de site Web déployé: 
Dans Server Explorer, on peut suivre les logs en temps réel en choisissant cette option: 
On peut aussi voir les paramètres: 
et les modifier: 
Il est déconseillé de tenter de modifier le blob contenant la configuration WAD. Il est préférable de passer par l’outil ou par les API.
Benjamin Guinebertière (@benjguin)