SQL Server chez les clients – Le Monitoring End to End des solutions métiers
Nous recommandons régulièrement à nos clients de mettre en place des tableaux de bord constitués d’indicateurs permettant un suivi régulier de l’état de santé des applications métiers spécifiques développées, et cela sur l’ensemble des briques applicatives qui constituent la solution.
Cette démarche qualité est facilitée par la suite Microsoft SQL Server qui fournit l’ensemble des outils nécessaires pour adapter les solutions applicatives métiers à ces besoins opérationnels IT.
Problématique
- Fournir des outils de diagnostic des applications métiers
- Identifier les points de contention applicative
- Optimiser la capacité de montée en charge de l’application
Bénéfices
- Centralisation des données de monitoring dans une plateforme d’analyse
- Disponibilité des résultats pour les différentes équipes : Développeurs, Exploitation…
- Optimisation des délais de diagnostic sur chaque brique
- Vision de l’application par périmètre fonctionnel
- Evolution et adaptabilité du besoin d’analyse.
La stratégie de capture des évènements
La capture des évènements est adaptée en fonction des sources des données qui alimenteront la plateforme de monitoring. Dans le cas d’une application classique 3 tiers avec client lourd, il est indispensable de surveiller l’intégralité de la chaine applicative :
Les web services: La couche AppFabric Monitoring est utilisée pour instrumenter les web services avec l’implémentation d’évènement personnalisé (Custom Tracking) :
- Exécution de procédures stockées
- Temps de mise en cache
- …
Le développeur s’appuiera sur le Logger pour tracer les exécutions clefs de son code, en permettant l’activation de plusieurs niveaux de trace : Debug, Info, Exceptions, Performance, …
Voici un exemple de mise en place de tracing à partir d’un Logger activé :
using (ExecutionTimeTracer timeTracer = new ExecutionTimeTracer(_appFabricLogger, EventType.StoredProcedure, EventTypeMessageDefinitions.StoredProcedure, storedProcedureName))
{
using (SqlCommand cmd = new SqlCommand(storedProcedureName))
{
cmd.CommandType = CommandType.StoredProcedure;
// 1. Add stored procedure parameter
cmd.Parameters.Add(new SqlParameter();
if (timeTracer.IsLoggingEnabled)
{
string parametersMessage = LoggingHelper.FormatSqlParameters(cmd.Parameters);
timeTracer.Append(parametersMessage);
}
return ExecuteSqlCommand(cmd, crud.ConnectionString);
}
}
La base de données: Les informations provenant des vues de gestion dynamique (DMVs) des instances SQL Server sont extraites.
Voici des exemples d’indicateurs et de données détaillées particulièrement utiles dans un contexte de supervision :
- Statistiques d’exécution des procédures stockées-DMV sys.dm_exec_procedure_stats
- Statistiques et détails sur les deadlocks SQL Server - trace xevents system_health
- Statistiques IO pour chaque base de données : sys.dm_io_virtual_file_stats
Ressources systèmes : La plateforme de supervision système (SCOM) expose des indicateurs systèmes également extraits.
La couche applicative client : Une couche Logger personnalisée (en fonction des besoins) est implémentée afin de consolider les évènements soit par web service ou ETW/Service Bus, afin d’accroitre la performance et la robustesse de l’ensemble.
La liste des évènements tracés est évolutive et peut-être enrichie en fonction des priorités :
Les évènements sont liés entre eux grâce à une clé unique permettant d’identifier la séquence des évènements provenant de plusieurs sources, et de donner ainsi un contexte métier opérationnel aux données (ex : séquence de création et de validation d’une commande).
La consolidation et l'analyse des données
Le schéma ci-dessous montre les différentes briques de la solution de monitoring à travers lesquels transitent les données capturées depuis les composants de l’application métier (Client, Web Service, base de données) :
L’ensemble des données issues des différentes collectes est consolidé dans une base de données analytique SQL Server, dont la fréquence d’alimentation est définie en fonction de la fréquence d’exécution des taches planifiées d’alimentation, permettant ainsi de paramétrer le niveau de fraicheur des données.
La base d'analyse
Le schéma relationnel repose sur une modélisation orientée vers l’analyse de données :
- Une table de type « faits » contenant une agrégation des résultats afin d’optimiser les performances de lecture
- Une version détaillée de ces données pour une plus grande « profondeur » d’analyse
- Une table de type « dimension » permettant de hiérarchiser les évènements applicatifs/métiers
- Une table de type « dimension » utilisée pour référencer les catégories de statistiques systèmes : Exceptions, Temps d’exécution WCF, …
Les rapports et tableaux de bord
Ce magasin de données est exploité à travers des rapports et tableaux de bord SQL Server Reporting Services entièrement intégrés dans un portail dédié au monitoring de l’application, et accessibles aux différentes équipes en fonction des besoins :
- Equipe IT
- Hotline
- Equipe de développement
Ces tableaux de bord transverses qui consolident les différentes natures d’indicateurs de la plateforme (base de données, systèmes, applicatifs, …) répondent à deux grands types de besoins :
- L’aide au diagnostic : identification de la source d’exception par exemple
- L’évaluation de la performance : évolution des temps de réponse
Diagnostic
Les graphes et les indicateurs de performance permettent de cibler rapidement les dysfonctionnements, ainsi que l’équipe en charge du périmètre.
En se focalisant par exemple sur les exceptions SQL (system.Data.SqlClient.SqlException) à travers un drill down dans la structure du tableau de bord, il est aisé d’obtenir la provenance de l’exception ainsi que des détails.
Ce type d’information est particulièrement utile pour connaitre la nature exacte du dysfonctionnement.
Les tableaux de bord permettent également de fournir des détails au niveau d’un web service Get, tels qu’un time out.
Les paramètres d’appel de la procédure stockée sont mentionnés afin de pouvoir facilement reproduire le comportement dans une phase de remédiation du problème de performance.
Performance
Les données sur les performances d’exécution des processus métiers sont aggrégées en fonction d’une période paramétrée dans le rapport.
Le suivi de l’évolution de ces données de performances permet d’identifier des pics de charges et d’éventuelles dégradations :
Afin d’entrer dans le détail de l’analyse, un focus peut être fait sur des composants particuliers, tels qu’une procédure stockée par exemple, afin de suivre l’évolution du nombre d’appels et des temps de réponse.
La mise en œuvre du Monitoring End to End avec MCS
La synergie entre les équipes MCS SQL/BI et .NET a permis de mettre en œuvre et de déployer cette robuste solution de Monitoring End to End sur des applications critiques issues de différents métiers tels que :
- Retail : Système complet de gestion Front Office & Back Office
- Banque d’investissement : Plateforme de production de PnL & Reporting
Une offre de service MCS dédiée à la mise en œuvre de ce type de solution « Monitoring End to End » est maintenant disponible.
Pour plus d’informations sur les offres packagées Microsoft Consulting Services, rendez-vous sur https://www.microsoft.com/france/services
Plus d’informations sur les blogs « SQL Server chez les clients ».
 |
Richard Prade, Consultant BI/SQL, Microsoft Consulting Services Après plusieurs années passées au support technique, j’interviens en mission de conseil auprès des grands comptes sur des projets à haute criticité s’appuyant sur la suite SQL Server. |