Azure Service Bus Monitoring

Le nouveau portail Azure propose des fonctionnalités de monitoring différentes selon le type de ressource que vous utilisez. De plus, ces fonctionnalités ne sont pas toujours activées par défaut.
Dans le cadre d’un projet full PaaS Azure, si vous souhaitez construire un dashboard de monitoring transverse, vous devrez au préalable définir les métriques pertinentes pour chaque ressource.

Prenons l’exemple d’un projet constitué de 3 ressources assez couramment utilisées :

• Créer une ressource Application Insights liée à votre Web App vous permettra d’avoir un monitoring assez détaillé.
• Azure SQL Database remonte par défaut un ensemble de métriques que vous pouvez consultez dans le portail au niveau de votre base.
• Pour les Service Bus, l’ancien portail affichait des courbes sur plusieurs métriques. Néanmoins, il était impossible de récupérer les données collectées. De plus, ces informations ne sont pas (encore ?) portées dans le nouveau portail.

Problématiques

• Comment remonter les métriques liées au service bus ?
• Comment mettre en place un monitoring transverse de notre projet ?

Solutions proposées

Remonter les métriques liées au service bus

Les métriques du Service Bus sont disponibles via les API dédiées. De plus, les API de Application Insights vous permettent de remonter les métriques spécifiques à vos applications.

En utilisant une Azure Function, on va pouvoir appeler ces différentes API et ainsi récupérer les métriques du Service Bus pour les envoyer dans notre Application Insights.

Nous allons voir dans la suite comment remonter le nombre de messages contenus dans une queue.

Création de la Azure Function

Il faut en premier lieu créer une Function App, vous pouvez le faire via le portail Azure (comme expliqué dans l’article Notifier un déploiement Kudu sur Slack avec Azure Functions).

Dans la Function App, nous choisissons ensuite de créer une fonction avec un scénario de type « Timer » en C#.

Code de la fonction

Dans le code ci-dessous, nous faisons référence :

• Au Service Bus dont on veut collecter les métriques à l’aide de sa chaîne de connexion.
  • A la queue concernée en indiquant simplement son nom.
• A la ressource Application Insights dans laquelle on souhaite pousser les métriques, à l’aide de « l’Instrumentation Key »

Nous nous intéressons ici au nombre de messages stockés dans les queues. La propriété « MessageCount » nous donne cette valeur pour chaque queue.

#r "Microsoft.ServiceBus"
#r "Microsoft.ApplicationInsights.dll"

using System;
using Microsoft.ServiceBus;
using Microsoft.ServiceBus.Messaging;
using Microsoft.ApplicationInsights;

public static void Run(TimerInfo myTimer, TraceWriter log)
{
    string connectionString = "Endpoint=sb:// /;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=";

    TelemetryClient telemetry = new TelemetryClient();
    telemetry.InstrumentationKey = "";

    var workflowQueueName = "yuc.workflow.webjob/yuc.workflow.webjob";

    var nsmgr = Microsoft.ServiceBus.NamespaceManager.CreateFromConnectionString(connectionString);
    long workflowCount = nsmgr.GetQueue(workflowQueueName).MessageCount;

    telemetry.TrackMetric("WrokflowQueue", workflowCount);
    
    log.Info($"Messages in Workflow Queue : {workflowCount}");
}

Reférences

La fonction fait référence à 2 assemblys externes :

• ServiceBus: ajouté automatiquement (cf. https://azure.microsoft.com/fr-fr/documentation/articles/functions-reference-csharp/#rfrencement-des-assemblys-externes)
• ApplicationInsights.dll: la dll doit donc être ajoutée dans un répertoire bin lui-même situé à la racine du répertoire de la fonction. Pour cela vous pouvez utiliser le Cloud Explorer de Visual Studio (cf. capture ci-dessous), ou encore Kudu, le FTP de la Function App etc…

La fonction est prête ! Par défaut, elle remontera toutes les minutes les métriques dans Application Insights.

Consultation du graphique

Pour visualiser ces métriques, vous pouvez accéder à la partie Performance de votre Application Insights et ajouter une chart à partir des custom metrics qui ont été déclarées dans la fonction.

Mise en place d’un dashboard transverse

Maintenant que nous avons les métriques souhaitées pour chacune des ressources de notre projet nous allons pouvoir construire un dashboard global pour ce projet.

Pour créer des dashboards dans le portail Azure, vous pouvez naviguer vers chacune de vos ressources et « épingler » les graphiques que vous souhaitez à votre dashboard. Pour faciliter la consultation des métriques, un nouvel outil centralise toutes les données de monitoring de votre portail : « Monitor ».

Dans la partie « Metrics » du portail « Monitor », vous sélectionnez les métriques que vous souhaitez afficher sur votre graphique et ensuite vous pouvez « épingler » (« Pin to dashboard ») la vue sur votre dashboard.

Dashboard

Sur un unique Dashboard vous avez rassemblé les métriques principales pour le monitoring de votre projet.

Conclusion

Cet exemple vous montre comment remonter des métriques qui ne sont pas affichées dans le portail, dans Application Insights. En vous inspirant de cet exemple, vous pourrez remonter les données qui vous intéressent.

De la même façon, en appelant l’API Application Insights au sein de votre application, vous pourrez collecter des données personnalisées. Ici, nous avons choisi de remonter des données liées à la performance, mais l’API de Application Insights contient les méthodes vous permettant de remonter des événements, des exceptions etc…

https://azure.microsoft.com/fr-fr/documentation/articles/app-insights-api-custom-events-metrics/