Il existe un nombre croissant d'excellents systèmes de surveillance des performances des bases de données. Récemment, les solutions sur site plus traditionnelles ont été rejointes par des solutions de logiciel en tant que service (SaaS).
Ce blog oppose l'architecture typique d'une solution sur site à celle d'une solution SaaS. Bien sûr, le nom et la structure des composants varieront d'un fournisseur à l'autre, mais les concepts clés abordés ici seront représentés sur un formulaire ou un autre.
Différences entre les solutions sur site et SaaS
Dans l'ensemble, voici quelques-uns des composants clés de chaque solution :
Solution traditionnelle sur site
- Processus de collecte de données.
- Répertoire des performances à court terme [diagnostics].
- Référentiel d'analyse/de création de rapports à long terme
- Client Windows ou navigateur.
- Toute infrastructure de basculement requise pour l'infrastructure de surveillance.
Solution SaaS
- Processus de collecte de données (pour les cibles sur site).
- Client de navigation.
- Application mobile.
- Le fournisseur SaaS gère l'application et le stockage des données back-end.
Notez que les noms des différents composants varient d'une solution à l'autre. Dans certains cas, les fonctionnalités peuvent être réparties sur plusieurs services ou sources de données.
Solutions sur site
Processus de collecte de données
Le collecteur de données est généralement un service sur site sans agent qui collecte des données à partir de n'importe quel point de terminaison surveillé sur site. Ce processus orchestre comment et quand les données sont collectées. Il doit être capable de collecter des données à différentes fréquences pour équilibrer le besoin de plus de détails avec l'impact sur la charge de travail surveillée. Les fréquences de collecte et les seuils d'alerte doivent être préconfigurés pour chaque métrique.
Tout le monde aura une instance "bruyante" qui ne respecte pas les seuils standards. Cela peut entraîner de nombreux faux positifs. Pour faire face à cela, le système doit avoir la capacité de créer des règles au niveau de l'instance pour faire face à des circonstances exceptionnelles. Cela évite la «fatigue des alarmes» due aux faux positifs.
Dans certains cas, ce service orchestre également les alertes et les notifications. Dans les grandes organisations avec des centaines d'instances surveillées, il peut être nécessaire d'équilibrer la charge en « fédérant » un certain nombre de collecteurs de données. La fédération synchronise les collections et la configuration sur un système dispersé.
Référentiel de diagnostics à court terme
C'est là que les données détaillées sont stockées. Cela inclut les données des DMV, des fichiers journaux, des XEvents et d'autres sources de données SQL Server. Les sources qui pourraient exercer une pression sur les instances surveillées doivent être évitées, par exemple, la plupart des traces ne conviennent pas à la surveillance en temps réel.
Étant donné que les fréquences de collecte peuvent être aussi fréquentes que toutes les secondes et que des blocs de données plus volumineux tels que TSQL et des plans sont collectés, ce référentiel peut devenir volumineux rapidement. Par conséquent, la plupart des systèmes limitent généralement l'historique entre une semaine et un mois (ces limitations ne s'appliquent pas à une solution SaaS). Ce référentiel est de nature hautement transactionnelle.
Référentiel de rapports/analyses à long terme
Au bout d'un temps prédéfini, ces données détaillées sont agrégées et stockées dans un référentiel de rapports pour des analyses et des tendances de haut niveau. La quantité de détails conservés aura un impact significatif sur la taille éventuelle de ce référentiel et sur la capacité de calcul que l'on peut raisonnablement s'attendre à ce qu'un utilisateur mette à disposition pour l'analyser. Cela a tendance à varier considérablement d'une solution à l'autre. Les solutions qui prennent en charge des analyses plus approfondies auront des architectures de support et peuvent utiliser des architectures OLAP pour faciliter l'analyse multidimensionnelle.
Mise à l'échelle d'une solution de surveillance sur site
Des solutions plus sophistiquées seront conçues pour faciliter une architecture distribuée des composants clés pour prendre en charge l'échelle. Le service de collecte de données aura un nombre supérieur de connexions surveillées qu'il peut prendre en charge. Une fois cette limite atteinte, un collecteur de données supplémentaire doit être « fédéré » pour coordonner la collecte des données et orchestrer le stockage des données.
Les référentiels de données de performances eux-mêmes peuvent partager une instance ou peuvent être répartis sur plusieurs instances pour prendre en charge l'échelle. Le stockage dont ils ont besoin sera directement proportionnel au nombre de connexions surveillées et au volume de données conservées. La structure et l'architecture du référentiel analytique affecteront également la capacité totale.
Expérience utilisateur
La plupart des outils sur site auront un frontal Windows. Certains ont des interfaces de navigateur basées sur un déploiement hébergé localement. L'accès à distance à ceux-ci peut être compliqué et nécessite généralement un VPN. Ils prennent rarement en charge les applications mobiles.
Haute disponibilité
Les logiciels de surveillance qui surveillent les charges de travail critiques doivent être résilients à part entière. Des dispositions doivent être prises pour gérer les situations de catastrophe pouvant mettre la structure de surveillance hors ligne. Cela doit également être considéré du point de vue de l'architecture et des coûts.
Solutions SaaS
Processus de collecte de données
Bien qu'une offre SaaS soit principalement hébergée, elle conserve souvent un collecteur de données sur site pour les charges de travail sur site. Cela permet de répondre aux contraintes de performance et de sécurité. De cette manière, toutes les connexions au niveau de l'instance sont établies via le collecteur sur site, qui relaie ensuite les données de performances de la base de données surveillées au service d'entrée dans le cloud. Toutes les données doivent être chiffrées en transit.
Référentiels de diagnostic et de rapport/d'analyse
La bonne nouvelle ici est que le fournisseur SaaS gère tout le stockage de vos données. Vous n'avez pas à vous soucier de la mise en place d'instances pour les référentiels de diagnostics, des référentiels de rapports, du vidage du référentiel de diagnostics ou de nombreux autres maux de tête associés à un déploiement sur site.
Les solutions hébergées s'appuieront sur différentes stratégies de stockage dans le back-end pour faciliter une combinaison d'activités transactionnelles et analytiques, le cas échéant. Ils peuvent s'appuyer sur des ressources cloud pour gérer des volumes de données plus importants et le traitement requis pour l'analyse ; par exemple, Spotlight Cloud conserve un an de données détaillées. Ainsi, non seulement vous pouvez faire un rapport d'un an en arrière, mais vous pouvez également revoir votre charge de travail jusqu'à un an dans le passé. C'est une capacité vraiment puissante.
Une solution SaaS pour la surveillance des performances de la base de données peut utiliser une variété de stratégies de stockage back-end non seulement pour s'adapter à la nature plus transactionnelle des diagnostics et de la surveillance, mais également pour faciliter les calculs à haute intensité associés aux analyses à long terme. Le fournisseur SaaS peut s'appuyer sur des économies d'échelle considérables pour utiliser une infrastructure beaucoup plus puissante qui serait à la disposition des organisations individuelles.
Comment faire évoluer une solution SaaS
La mise à l'échelle d'une solution SaaS relève de la responsabilité du fournisseur et non de l'utilisateur. Toute solution SaaS pour la surveillance des performances des bases de données doit être conçue pour évoluer dès le premier jour et, par conséquent, elle a tendance à gérer l'évolution dans sa foulée.
Expérience utilisateur
Les applications SaaS utiliseront par défaut un navigateur Ux et beaucoup auront également des applications mobiles complètes. Cela facilite les équipes dispersées et distantes.
Sécurité et conformité
La plupart des solutions SaaS seront construites sur l'une des principales infrastructures cloud, telles qu'Azure ou Amazon. Bon nombre des principaux fournisseurs ont mis en place des infrastructures de sécurité sophistiquées. Ils sont fortement investis pour répondre aux besoins de conformité de leurs clients.
Haute disponibilité
La bonne nouvelle ici encore est que c'est la responsabilité du vendeur. Il vaut la peine de vérifier auprès de votre fournisseur pour savoir quelle disposition il a prise en termes de basculement et de haute disponibilité. Les applications SaaS doivent être conçues pour être très résilientes. Les différents services qui composent une application SaaS sont généralement conçus pour être résilients individuellement. Des dispositions peuvent également être prises pour les pannes du centre de données où l'application basculerait d'un centre de données à un autre en cas de panne du centre de données.
