Configuration de la supervision dans le pack d’administration pour SQL Server
Cette section explique les configurations de surveillance dans le pack d’administration pour SQL Server.
Règles d’alerte de SQL Server Agent : spécificités de la configuration
Le pack d’administration pour SQL Server fournit les règles d’alerte de l’agent SQL Server suivantes :
- MSSQL sur Windows : Le moteur d’alerte s’est arrêté en raison d’erreurs irrécupérables du journal local des événements
- MSSQL sur Windows : L’exécution d’un travail SQL a échoué
- MSSQL sur Windows : Impossible d’exécuter l’étape de travail en raison de l’échec de chargement du sous-système
- MSSQL sur Windows : L’agent est suspect. Aucune réponse lors des dernières minutes
- MSSQL sur Windows : Impossible de démarrer SQL Server Agent
- MSSQL sur Windows : SQL Server Agent lance son propre arrêt
- MSSQL sur Windows : Une étape d’un travail a causé une exception dans le sous-système
- MSSQL sur Windows : SQL Server Agent ne peut pas se connecter à SQL Server
- MSSQL sur Windows : Impossible de rouvrir le journal local des événements
Par défaut, ces règles sont activées en mode de surveillance de l’agent, mais désactivées en mode de supervision mixte, car Operations Manager n’autorise pas les événements des journaux d’événements à collecter sur des ordinateurs distants. Pour modifier ce problème, vous pouvez remplacer chacune de ces règles en activant l’option AllowProxying .
Remarque
L’activation de l’option AllowProxying peut entraîner l’exécution de code distant. N’activez pas cette option, sauf si vous êtes sûr que votre ordinateur est sécurisé.
Aucune de ces règles ne fonctionne en mode de supervision sans agent et n’est pas disponible pour SQL sur Linux.
Règles d’alerte Always On
Le pack d’administration pour SQL Server comporte deux règles d’événement pour les alertes dans les cas où les événements suivants apparaissent dans le journal des applications Windows :
ID d’événement 1480, le rôle réplica de base de données est modifié
ID d’événement 19406, rôle réplica de disponibilité modifié
Par défaut, SQL Server peut ne pas déclencher ces événements dans le journal des applications. Pour les activer, exécutez les scripts T-SQL suivants :
sp_altermessage 1480, 'with_log', 'true'
sp_altermessage 19406, 'with_log', 'true'
Supervision de la sauvegarde de la base de données de disponibilité
Le pack d’administration pour SQL Server fournit des moniteurs qui vérifient l’existence et l’âge d’une base de données et des sauvegardes de journaux, comme indiqué par Microsoft SQL Server. Cette opération est effectuée en exécutant une requête sur la base de données master de l’instance SQL et en retournant l’âge de la sauvegarde.
Ces moniteurs se trouvent sous le cumul de l’état de disponibilité de la base de données du groupe de disponibilité dans la vue Groupe de disponibilité. La liste des moniteurs est la suivante :
- Moniteur d’état de sauvegarde de la base de données de disponibilité
- Moniteur d’état de sauvegarde des journaux de la base de données de disponibilité
Moniteur d’état de sauvegarde de la base de données de disponibilité
Ce moniteur cible l’intégrité de la base de données de disponibilité et vérifie l’état de sauvegarde de la base de données en fonction du seuil en jours.
Par défaut, le moniteur ne suit pas les préférences de sauvegarde du groupe de disponibilité. Si ce overdrive est activé, le moniteur effectue le suivi de l’emplacement de sauvegarde configuré dans les préférences de sauvegarde du groupe de disponibilité et vérifie si la sauvegarde sur le réplica sélectionné est conforme au paramètre de fréquence de sauvegarde.
Voici les préférences de sauvegarde du groupe de disponibilité sélectionné qui sont possibles :
Préférer secondaire
Spécifie que les sauvegardes doivent se produire sur un réplica secondaire sauf lorsque le réplica principal est le seul réplica en ligne. Dans ce cas, la sauvegarde doit se produire sur le réplica principal. Il s'agit de l'option par défaut.
Secondaire uniquement
Spécifie que les sauvegardes ne doivent jamais être effectuées sur le réplica principal. Si le réplica principal est le seul réplica en ligne, la sauvegarde ne doit pas se produire.
Primaire
Spécifie que les sauvegardes doivent toujours avoir lieu sur le réplica principal. Cette option est utile si vous avez besoin de fonctionnalités de sauvegarde, telles que la création de sauvegardes différentielles qui ne sont pas prises en charge lors de l’exécution de la sauvegarde sur un réplica secondaire.
Tout réplica
Spécifie que vous préférez que les travaux de sauvegarde ignorent le rôle des réplicas de disponibilité lorsque vous choisissez le réplica pour effectuer les sauvegardes.
Remarque
Les travaux de sauvegarde peuvent évaluer d’autres facteurs tels que la priorité de sauvegarde de chaque réplica de disponibilité en combinaison avec son état opérationnel et son état connecté.
Voici des exemples d’activation et de désactivation de l’option des paramètres de suivi dans le cas des préférences de sauvegarde étant le réplica principal pour le groupe de disponibilité, et le fichier de sauvegarde existe uniquement sur un réplica secondaire.
Le paramètre De suivi des préférences de sauvegarde est activé : pour les deux réplicas de base de données, le moniteur d’état de sauvegarde de la base de données de disponibilité est dans un état critique :
Le paramètre De suivi des préférences de sauvegarde est désactivé . seul le réplica de base de données principal du moniteur d’état de sauvegarde de la base de données de disponibilité est dans un état critique :
Moniteur d’état de sauvegarde des journaux de la base de données de disponibilité
Ce moniteur cible l’intégrité de la base de données de disponibilité et vérifie l’état de sauvegarde du journal de base de données en fonction du seuil en minutes.
Le correctif cumulatif de la base de données de disponibilité surveille les alertes
L’état de sauvegarde de la base de données de disponibilité et les moniteurs d’état de sauvegarde des journaux de la base de données de disponibilité sont configurés avec la stratégie de cumul « Meilleur état de n’importe quel membre » et affichent par défaut les alertes critiques sur le cumul pour afficher l’état complet de la base de données dans le groupe de disponibilité.
La base de données de disponibilité est l’entité d’une base de données qui peut être hébergée sur de nombreux réplicas, en fonction de cela, seul le « État de sauvegarde de la base de données de disponibilité (rollup) » a l’alerte, pour vérifier l’état de la base de données de disponibilité entière par rapport à l’affichage de l’état de la base de données sur chaque réplica :
Un correctif cumulatif devient critique et déclenche une alerte uniquement lorsque tous les réplicas de base de données ont un état critique de sauvegarde de base de données ou de sauvegarde des journaux. Si un seul réplica a un état critique de sauvegarde de base de données ou de sauvegarde des journaux, le cumul reste sain en fonction de la stratégie de cumul.
Surveillance des stratégies
Le pack d’administration pour SQL Server collecte les métriques d’intégrité des bases de données et des objets Always On disponibles sur l’instance cible de SQL Server en lisant l’état des stratégies PBM (gestion basée sur des stratégies) pour chacun des objets.
En plus des stratégies système, le pack d’administration permet de surveiller les stratégies d’utilisateur personnalisées pour les objets suivants :
- Base de données
- Groupe de disponibilité
- Réplica de disponibilité
- Réplica de base de données
Pour chacun de ces objets, le pack d’administration contient les moniteurs suivants :
- Moniteur à deux états avec un état d’avertissement . Ce moniteur affiche l’état de la stratégie utilisateur personnalisée qui a l’une des catégories d’avertissement prédéfinies en tant que catégorie de stratégie.
- Moniteur à deux états avec un état d’erreur . Ce moniteur affiche l’état de la stratégie utilisateur personnalisée qui a l’une des catégories d’erreurs prédéfinies en tant que catégorie de stratégie.
Surveillance de l’espace
Le pack d’administration pour SQL Server est capable d’effectuer une surveillance de l’espace en collectant un ensemble de métriques aux niveaux suivants :
- Base de données
- Groupe de fichiers
- File
- Fichier journal
Vous pouvez utiliser des moniteurs d’unités, ainsi que des métriques de performances pour afficher ces informations pour plusieurs bases de données et pour des intervalles de temps longs.
La surveillance de l’espace prend en charge les types de supports suivants :
- Stockage local et points de montage
- Volumes partagés de cluster
- Partages SMB
- Objets blob Azure
Une fois que vous avez importé le pack d’administration pour SQL Server, vous pouvez constater que certains flux de travail d’analyse de l’espace sont activés par défaut, tandis que d’autres sont désactivés. Pour réduire la charge sur l’environnement, l’analyse de l’espace est activée uniquement pour le niveau de base de données et désactivée pour le groupe de fichiers, le fichier journal, le conteneur OLTP en mémoire et les niveaux de groupe de fichiers FILESTREAM. Si votre environnement est sensible à une charge supplémentaire, l’activation de flux de travail rarement utilisés n’est pas recommandée.
Remarque
Lors de l’analyse des groupes de fichiers, une alerte est levée uniquement si tous les fichiers du groupe de fichiers sont complètement défectueux. S’il existe au moins un fichier dans le groupe de fichiers sain, aucune alerte n’est enregistrée.
Voici une liste qui explique l’état par défaut de chacun des flux de travail de surveillance de l’espace :
- Découvertes activées pour Windows et Linux
- Moteurs de base de données
- Bases de données pour un Moteur de base de données
- Découvertes désactivées pour Windows et Linux
- Groupes de fichiers de base de données
- Fichiers de base de données
- Fichier journal des transactions
- Groupes de fichiers FILESTREAM
- Groupe de fichiers de données à mémoire optimisée
- Conteneurs de groupes de fichiers de données à mémoire optimisée
- Moniteurs activés pour Windows
- Ciblé vers la base de données
- Espace libre des données ROWS à gauche
- Espace libre LOG à gauche
- Ciblé vers la base de données
- Moniteurs désactivés pour Windows
- Ciblé vers la base de données
- Modification du pourcentage d’espace de données ROWS
- Espace libre des données OLTP en mémoire gauche
- Espace libre de données FILESTREAM à gauche
- Ciblé vers le groupe de fichiers
- Espace libre de fichier de base de données restant
- Ciblé vers le fichier journal
- Espace libre de fichier journal de base de données restant
- Ciblé sur le conteneur de données OLTP en mémoire
- Espace libre du conteneur du groupe de fichiers de données à mémoire optimisée
- Ciblé vers le groupe de fichiers FILESTREAM
- Espace libre du groupe de fichiers FILESTREAM de la base de données
- Ciblé vers la base de données
- Moniteurs activés pour Linux
- Ciblé vers le groupe de fichiers
- Espace libre de fichier de base de données restant
- Ciblé vers le fichier journal
- Espace libre de fichier journal de base de données restant
- Ciblé sur le conteneur de données OLTP en mémoire
- Espace libre du conteneur du groupe de fichiers de données à mémoire optimisée
- Ciblé vers le groupe de fichiers
Les moniteurs suivants prennent en charge le remplacement du Mode de calcul d’intégrité :
- Espace libre de données FILESTREAM à gauche
- Espace libre des données OLTP en mémoire gauche
- Espace libre de fichier journal de base de données restant
- Espace libre des données ROWS à gauche
Ce remplacement vous permet de définir la façon dont vous souhaitez superviser l’espace libre dans votre environnement. Vous pouvez demander à l’un des moniteurs ci-dessus d’effectuer le suivi de l’état d’intégrité en fonction du paramètre « Seuil » exprimé sous la forme d’un pourcentage (%) ou d’une métrique de capacité (Mo). Pour rendre la supervision encore plus efficace, vous pouvez utiliser les seuils de pourcentage (%) et de métrique de capacité (Mo) simultanément. Dans ce cas, la métrique dont l’état est le plus mauvais est utilisée pour signaler l’état d’intégrité global.
Workflows d’analyse de l’espace désactivés pour SQL sur Linux
Les flux de travail suivants sont désactivés par défaut, car ils ne sont pas fournis avec les données nécessaires par l’SQL Server sur Linux :
- Règlement
- MSSQL sur Linux : Total de l’espace libre (Mo) du groupe de fichiers de données à mémoire optimisée de base de données
- MSSQL sur Linux : Total de l’espace libre (%) du groupe de fichiers de données à mémoire optimisée de base de données
- MSSQL sur Linux : Total de l’espace libre (%) du groupe de fichiers FILESTREAM de base de données
- MSSQL sur Linux : Total de l’espace libre (Mo) du groupe de fichiers FILESTREAM de base de données
- MSSQL sur Linux : Total de l’espace libre (%) du groupe de fichiers de base de données
- MSSQL sur Linux : Total de l’espace libre (Mo) du groupe de fichiers de base de données
- MSSQL sur Linux : Espace libre (%) alloué au groupe de fichiers de base de données
- MSSQL sur Linux : Espace libre (Mo) alloué au groupe de fichiers de base de données
- MSSQL sur Linux : Espace externe libre de la base de données (Mo)
- MSSQL sur Linux : Espace libre (Mo) alloué à la base de données
- MSSQL sur Linux : Total de l’espace libre (%) du journal des transactions de base de données
- MSSQL sur Linux : Espace utilisé alloué à la base de données utilisé (Mo)
- MSSQL sur Linux : Total de l’espace libre de la base de données (%)
- MSSQL sur Linux : Total de l’espace libre de la base de données (Mo)
- MSSQL sur Linux : Espace alloué à la base de données (Mo)
- Moniteurs
- Espace libre de base de données restant
- Changement de pourcentage de l'espace de la base de données
- Espace libre des journaux des transactions (%)
- Espace libre du groupe de fichiers FILESTREAM de la base de données
Surveillance de l’état de la base de données
La surveillance de l’état de la base de données est destinée à vérifier l’état de la base de données comme indiqué par Microsoft SQL Server. La vérification de l’état est effectuée en exécutant une requête sur la base de données master de l’instance SQL Server qui retourne l’état de la base de données. Si vous recevez une alerte de ce moniteur, une action est nécessaire pour ramener la base de données à un état opérationnel.
Tous les états de base de données, à l’exception de ONLINE, entraînent un état d’analyse défectueux. Le tableau ci-dessous définit les états de la base de données.
État | Définition |
---|---|
ONLINE | La base de données est accessible. Le groupe de fichiers primaire est en ligne, mais il est possible que la phase de restauration de la récupération n'ait pas été réalisée. |
OFFLINE | La base de données n'est pas disponible. Une base de données est mise hors connexion par une action explicite de l'utilisateur et reste dans cet état jusqu'à une nouvelle action de l'utilisateur. Par exemple, la base de données peut être mise hors connexion pour déplacer un fichier sur un nouveau disque. La base de données est ensuite ramenée en ligne une fois que le déplacement a eu lieu. |
RESTORING | Un ou plusieurs fichiers du groupe de fichiers primaire sont en cours de restauration ou un ou plusieurs fichiers secondaires sont en cours de restauration hors connexion. La base de données n'est pas disponible. |
RECOVERING | La base de données est en cours de récupération. Le processus de restauration est un état transitoire ; elle sera mise automatiquement en ligne si la récupération réussit. Si la récupération échoue, la base de données devient suspecte. La base de données n'est pas disponible. |
RECOVERY PENDING | SQL Server a rencontré une erreur liée aux ressources pendant la récupération. La base de données n'est pas endommagée, mais des fichiers peuvent être absents ou des restrictions de ressources système peuvent l'empêcher de démarrer. La base de données n'est pas disponible. Une action de l'utilisateur est nécessaire pour résoudre l'erreur et permettre la poursuite du processus de récupération. |
SUSPECT | Le groupe de fichiers primaire au moins est suspect et peut être endommagé. La base de données ne peut pas être récupérée au démarrage de SQL Server. La base de données n'est pas disponible. Une action de l'utilisateur est nécessaire pour résoudre le problème. |
EMERGENCY | L'utilisateur a modifié la base de données et défini son état sur EMERGENCY. La base de données est en mode mono-utilisateur et peut être réparée ou restaurée. La base de données est marquée READ_ONLY, la journalisation est désactivée et l’accès est restreint aux membres du rôle serveur fixe sysadmin . EMERGENCY est principalement utilisé à des fins de dépannage. Par exemple, une base de données marquée SUSPECT peut être définie sur l'état EMERGENCY. Ceci peut permettre à l'administrateur système d'accéder en lecture seule à la base de données. Seuls les membres du rôle serveur fixe sysadmin peuvent définir l’état EMERGENCY pour une base de données. |
Pour plus d'informations, consultez Database States.
Le moniteur prend également en charge le remplacement « Désactiver si le groupe de disponibilité est hors connexion » pour les environnements Windows. Lorsque cette substitution est définie sur true et que le groupe de disponibilité qui héberge la base de données n’est pas disponible, le moniteur cesse de suivre l’état d’une telle base de données. Ce remplacement est utile, car il vous permet d’éviter d’être submergé par des alertes, ce qui peut se produire lors de l’utilisation de SQL Server 2012 en raison des spécificités de son architecture. Pour les versions ultérieures de SQL Server, ce remplacement n’est pas obligatoire.
Plusieurs bases de données sur le même lecteur
L’analyse de l’espace dans le pack d’administration peut être bruyante dans les environnements où de nombreuses bases de données partagent le même média et que le paramètre de croissance automatique est activé. Dans de tels cas, une alerte est générée pour chaque base de données quand la quantité d’espace libre sur le disque dur atteint le seuil.
Pour réduire le bruit, désactivez l’analyse de l’espace pour les fichiers de données et les fichiers journaux des transactions et utilisez le pack d’administration du système d’exploitation pour surveiller l’espace sur le disque dur.
Monitoring de la latence de stockage de base de données
Le pack d’administration pour SQL Server collecte les métriques de performances de latence de lecture du disque de base de données (ms) et de la latence d’écriture de disque de base de données (ms) pour chaque base de données. En outre, le pack d’administration définit deux moniteurs associés qui inscrivent des alertes en cas de dégradation significative des performances. Ces moniteurs et règles de performances sont désactivés par défaut. Activez-les uniquement pour des bases de données spécifiques si nécessaire.
Sessions bloquées
Le moniteur sessions bloquantes est conçu pour interroger chaque base de données pour une session bloquée pendant une période importante. Si le blocage est détecté et dépasse le seuil donné, l’état est modifié et une alerte est déclenchée.
Vous pouvez appliquer une substitution pour modifier le paramètre WaitMinutes utilisé pour déterminer si la session bloquée doit être considérée comme étant longue. La valeur par défaut de ce paramètre est une minute.
Moniteur d’état de configuration des éléments sécurisables
Ce moniteur vérifie si chacun des éléments sécurisables SQL Server requis est accessible sous le compte d’identification configuré.
Voici une liste complète des éléments sécurisables vérifiés par le moniteur ciblé sur le moteur de base de données SQL Server :
Autorisations au niveau du serveur
- VIEW SERVER STATE
- VIEW ANY DEFINITION
- VIEW ANY DATABASE
Autorisation SELECT sur les vues de gestion dynamique
- master.sys.dm_hadr_availability_group_states
- master.sys.dm_hadr_availability_replica_states
- master.sys.dm_hadr_database_replica_cluster_states
- master.sys.dm_os_performance_counters
- master.sys.dm_tran_active_transactions
- master.sys.dm_tran_session_transactions
- master.sys.dm_exec_sessions
- master.sys.dm_exec_requests
- master.sys.dm_exec_connections
- master.sys.dm_os_sys_info
- master.sys.dm_os_ring_buffers
- master.sys.dm_os_volume_stats
- master.sys.dm_os_threads
- master.sys.dm_server_services
- master.sys.dm_db_xtp_checkpoint_files
- master.sys.dm_db_xtp_table_memory_stats
- master.sys.dm_db_xtp_hash_index_stats
- master.sys.dm_resource_governor_resource_pools
- master.sys.dm_db_index_physical_stats
Autorisation SELECT sur les affichages catalogue
- master.sys.dm_os_host_info
- master.sys.availability_groups
- master.sys.databases
- master.sys.database_files
- master.sys.tables
- master.sys.filegroups
- master.sys.syscolumns
- master.sys.sysprocesses
- master.sys.availability_replicas
- master.sys.database_mirroring
- master.sys.configurations
- master.sys.indexes
- msdb.dbo.syspolicy_policies
- msdb.dbo.syspolicy_conditions
- msdb.dbo.syspolicy_policy_execution_history
- msdb.dbo.syspolicy_configuration
- msdb.dbo.syspolicy_system_health_state
- msdb.dbo.syspolicy_object_sets
- msdb.dbo.syspolicy_policy_categories
- msdb.dbo.syspolicy_target_sets
- msdb.dbo.syspolicy_target_set_levels
- msdb.dbo.syspolicy_policy_execution_history_details
- msdb.dbo.sysjobschedules
- msdb.dbo.syscategories
- msdb.dbo.sysjobs_view
- msdb.dbo.sysjobactivity
- msdb.dbo.sysjobhistory
- msdb.dbo.syssessions
- msdb.dbo.log_shipping_primary_databases
- msdb.dbo.log_shipping_secondary_databases
- msdb.dbo.backupset
Autorisation EXECUTE sur les procédures stockées
- master.sys.sp_enumerrorlogs
- master.sys.xp_readerrorlog
- master.sys.xp_instance_regread
- msdb.dbo.sp_help_job
- msdb.dbo.agent_datetime
- msdb.dbo.SQLAGENT_SUSER_SNAME
Voici une liste complète des éléments sécurisables vérifiés par le moniteur ciblé sur les bases de données SQL Server :
- Autorisation SELECT sur les affichages catalogue
- sys.database_files
- sys.tables
- sys.filegroups
- sys.syscolumns
Remarque
Certains moniteurs peuvent avoir des propriétés avec un trait de soulignement double dans leurs noms. Ces propriétés sont utilisées à des fins de pack d’administration interne ; veillez à ne pas les utiliser.
Moniteur d’état d’intégrité WMI
Ce moniteur vérifie si le compte d’identification configuré a accès aux espaces de noms suivants situés sur le serveur SQL Server cible :
- ROOT\CIMV2
- ROOT\Microsoft\SqlServer
- ROOT\Microsoft\SqlServer\ComputerManagement11
- ROOT\Microsoft\SqlServer\ComputerManagement12
- ROOT\Microsoft\SqlServer\ComputerManagement13
- ROOT\Microsoft\SqlServer\ComputerManagement14
- ROOT\Microsoft\SqlServer\ComputerManagement15
- ROOT\Microsoft\SqlServer\ComputerManagement16
Le moniteur génère une alerte dans les cas où il n’y a pas d’accès à l’un des espaces de noms ci-dessus.
Surveillance des travaux de SQL Server Agent
Le pack d’administration pour SQL Server est capable d’effectuer des travaux de l’Agent de disponibilité et de surveillance des performances pour SQL Server avec les flux de travail suivants :
Moniteur d’état des dernières exécutions
Ce moniteur vérifie tous les travaux sur SQL Agent et, si l’un des travaux n’a pas abouti, le moniteur change son état en Avertissement. Cela ne génère pas d’alerte, car il existe un remplacement pour désactiver les alertes pour contrôler le bruit. Si vous souhaitez que ce niveau de supervision soit activé, vous devez remplacer les alertes générées.
Le moniteur a le nombre de remplacements de seuil d’échec, ce qui indique le nombre de fois où un travail SQL Agent peut échouer avant que l’état du moniteur soit remplacé par Avertissement. Le remplacement définit l’état Annulé comme Ayant échoué peut suivre le dernier état d’exécution du travail annulé en tant qu’échec.
Moniteur de travaux longs
Ce moniteur recherche les travaux à long terme de l'Agent SQL. Une alerte d’avertissement ou d’erreur s’affiche si un travail s’exécute depuis plus longtemps que les seuils configurés : seuil d’avertissement (minutes) et seuil critique (minutes) .
Par défaut, ce moniteur ne surveille pas les travaux qui ont le type de planification Démarrer automatiquement lorsque SQL Server Agent démarre , car ces travaux s’exécutent souvent jusqu’à ce que SQL Agent s’arrête (autrement dit, en continu). En règle générale, Réplication SQL Server utilise ces travaux, mais dans certains cas, les travaux avec le démarrage automatiquement lorsque le type de planification de SQL Server Agent démarre peut s’exécuter pendant un intervalle relativement court. Pour surveiller ces travaux, remplacez le paramètre Inclus des travaux exécutés en continu avec une liste délimitée par des virgules des noms de travaux. Le nom du travail dans la liste doit répondre aux exigences de l’une des classes d’identificateur suivantes :
Regular
- Peut contenir n’importe quel caractère à l’exception du signe virgule (,) et du signe de guillemets doubles (").
- Ne doit pas commencer ou se terminer par l’un des espaces blancs.
Delimited
- Peut contenir n’importe quel caractère et doit être délimité par des guillemets doubles.
- Les guillemets doubles doivent être échappés en les doublant.
Tout nom appartenant à l’une des classes ci-dessus doit être compris entre 1 et 128 caractères, à l’exception des caractères délimiteurs.
Moniteur durée du travail
Ce moniteur vérifie tous les travaux sur SQL Agent et si l’un des travaux prend plus de temps que le seuil spécifié. Une alerte d’avertissement ou d’erreur s’affiche si une durée de travail est supérieure aux seuils configurés - Seuil d’avertissement (minutes) et Seuil critique (minutes). Cela ne génère pas d’alerte, car il existe un remplacement pour désactiver les alertes pour contrôler le bruit. Si vous souhaitez ce niveau de surveillance, vous devez remplacer la fonctionnalité Générer des alertes pour l’activer ou utiliser la règle d’alerte Durée du travail.
Règle d’alerte durée du travail
Cette règle vérifie si l’heure d’exécution de l’un de vos travaux SQL Agent a dépassé le seuil spécifié en minutes et lève une alerte si le temps d’exécution a dépassé le seuil.
Règle de performances de durée du travail
Cette règle collecte la durée en minutes de l’un de vos travaux SQL Agent.
Surveillance des certificats de chiffrement de connexion SQL Server
Le pack d’administration pour SQL Server fournit le moniteur capable d’effectuer l’état du certificat de chiffrement de connexion SQL Server.
SQL Server peut utiliser TLS pour chiffrer des données transmises sur un réseau entre une instance de SQL Server et une application cliente. TLS utilise un certificat pour implémenter le chiffrement. L’activation du chiffrement TLS améliore la sécurité des données transmises sur des réseaux entre des instances de SQL Server et des applications. Pour plus d’informations, consultez les articles sur la vue d’ensemble du certificat et les procédures de certificat.
Ce moniteur cible les moteur de base de données SQL Server sur Windows et Linux et vérifie la période de validation des certificats en jours et les exigences de certificat.
Important
SQL Server ne démarre pas si un certificat existe dans le magasin d’ordinateurs, mais répond uniquement à certaines exigences de la liste ci-dessus et s’il est configuré manuellement pour une utilisation par Gestionnaire de configuration SQL Server ou par le biais d’entrées de Registre (pour SQL Server sur Windows uniquement). Sélectionnez un autre certificat qui répond à toutes les exigences ou supprimez le certificat d’être utilisé par SQL Server jusqu’à ce que vous puissiez en provisionner un qui répond aux exigences. Pour plus d’informations, consultez l’article Configurer SQL Server pour le chiffrement .
Le tableau suivant définit les paramètres de remplacement du moniteur et ajuste correctement les exigences de validation de certificat pour SQL Server :
Remplacer le nom | Description |
---|---|
Noms d’hôtes supplémentaires à vérifier | Par défaut, le moniteur vérifie que le certificat contient le nom principal du moteur de base de données cible. Cette substitution permet de vérifier avec une liste séparée par des virgules de noms d’hôtes supplémentaires comme le nom DNS de l’écouteur Always On, l’alias DNS de la machine d’hébergement, le nom virtuel FCI, etc. |
Le certificat doit être configuré (pour SQL Server sur Windows uniquement) | Si la valeur est true, le moniteur passe à un état critique lorsqu’un moteur de base de données n’a pas de certificat configuré explicitement. |
Ignorer la vérification « Racine non approuvée » | Si la valeur est true, le moniteur ignore que le certificat n’est pas placé dans les autorités de certification racines approuvées. S’ils sont placés, ces certificats sont approuvés par le système d’exploitation et peuvent être utilisés par des applications comme référence pour lesquels les hiérarchies d’infrastructure à clé publique (PKI) et les certificats numériques sont fiables. |
Définir l’indicateur « IgnoreCertificateAuthorityRevocationUnknown » | Ignorez que la révocation de l’autorité de certification est inconnue lors de la détermination de la vérification du certificat. |
Définir l’indicateur 'IgnoreCtlNotTimeValid' | Ignorez que la liste de confiance de certificat (CTL) n’est pas valide, pour des raisons telles que la durée de vie du certificat a expiré, lors de la détermination de la vérification du certificat. |
Définir l’indicateur 'IgnoreCtlSignerRevocationUnknown' | Ignorez que la révocation du signataire de la liste d’approbation de certificat (CTL) est inconnue lors de la détermination de la vérification du certificat. |
Définir l’indicateur 'IgnoreEndRevocationUnknown' | Ignorez que la révocation du certificat final (le certificat utilisateur) est inconnue lors de la détermination de la vérification du certificat. |
Définir l’indicateur « IgnoreInvalidBasicConstraints » | Ignorez que les contraintes de base ne sont pas valides lors de la détermination de la vérification du certificat. |
Définir l’indicateur « IgnoreInvalidPolicy » | Ignorez que le certificat a une stratégie non valide lors de la détermination de la vérification du certificat. |
Définir l’indicateur « IgnoreNotTimeNested » | Ignorez que le certificat d’autorité de certification (autorité de certification) et le certificat émis ont des périodes de validité qui ne sont pas imbriquées lors de la vérification du certificat. Par exemple, le certificat d'autorité de certification peut être valide du 1er janvier au 1er décembre et le certificat émis du 2 janvier au 2 décembre, ce qui signifie que les périodes de validité ne sont pas imbriquées. |
Définir l’indicateur « IgnoreNotTimeValid » | Ignorez les certificats de la chaîne qui ne sont pas valides, car ils ont expiré ou ne sont pas encore en vigueur lors de la détermination de la validité du certificat. |
Définir l’indicateur 'IgnoreRootRevocationUnknown' | Ignorez que la révocation racine est inconnue lors de la détermination de la vérification du certificat. |
Définir l’indicateur 'IgnoreWrongUsage' | Ignorez que le certificat n’a pas été émis pour l’utilisation actuelle lors de la détermination de la vérification du certificat. |
Ignorer la vérification « Nom d’hôte » | Si la valeur est true, le moniteur ignore la vérification que le certificat contient des noms d’hôtes particuliers. |
Ignorer la vérification « Authentification du serveur d’utilisation de clé » | Si la valeur est true, le moniteur ignore l’exigence de certificat d’authentification du serveur de la présence de l’extension d’utilisation de la clé « Authentification du serveur ». Certaines implémentations de pilote de connexion peuvent ne pas vérifier l’existence de cette extension et peuvent considérer le certificat valide même sans l’extension. |
Ignorer la vérification de la révocation | Si la valeur est true, le moniteur ignore tous les problèmes liés à la révocation. |
Surveillance de l’état de sauvegarde du certificat TDE (Transparent Data Encryption)
Le pack d’administration pour SQL Server fournit le moniteur capable de vérifier que le certificat utilisé pour chiffrer la clé de chiffrement de base de données n’a pas été sauvegardé.
Transparent Data Encryption (TDE) chiffre le stockage d’une base de données entière à l’aide d’une clé symétrique appelée clé de chiffrement de base de données. La clé de chiffrement de base de données peut aussi être protégée à l’aide d’un certificat qui est lui-même protégé par la clé principale de base de données de la base de données MASTER. TDE assure un chiffrement et un déchiffrement des données et des fichiers journaux en E/S et en temps réel. Le chiffrement utilise une clé de chiffrement de base de données. L’enregistrement de démarrage de la base de données stocke la clé pour la mettre à disposition pendant la récupération. La clé DEK est une clé symétrique et sécurisée par un certificat que la base de données principale du serveur stocke ou par une clé asymétrique qu’un module EKM protège. TDE protège les données au repos, c’est-à-dire les fichiers de données et les fichiers journaux. Il vous permet d’être en conformité avec de nombreuses lois, réglementations et directives établies dans différents secteurs d’activité. Cette possibilité permet aux développeurs de logiciels de chiffrer les données à l’aide des algorithmes de chiffrement AES et 3DES sans modifier les applications existantes. Pour plus d’informations, consultez les meilleures pratiques de sécurité SQL Server et les articles TDE (Transparent Data Encryption).
Remarque
TDE n’est pas disponible pour les bases de données système. Il ne peut pas être utilisé pour chiffrer master, model ou msdb. tempdb est automatiquement chiffré lorsqu’une base de données utilisateur a activé TDE, mais ne peut pas être chiffrée directement.
Surveillance des requêtes longues
Le pack d’administration pour SQL Server fournit la règle capable de déclencher une alerte si le temps d’exécution d’une des requêtes SQL en cours d’exécution a dépassé le seuil spécifié (en secondes).
La règle prend en charge le filtrage de personnalisation des alertes avec les remplacements suivants :
- Liste d’exclusion d’application : pour exclure la requête avec le nom de l’application
- Liste d’exclusion de base de données : pour exclure la requête avec le nom de la base de données
- Liste d’exclusion de requête : pour exclure la requête avec du texte de requête personnalisé
Ces remplacements prennent en charge les caractères génériques et peuvent être utilisés pour exclure les requêtes longues avec le nom de l’application, le nom de la base de données ou le texte de requête lui-même avec des valeurs séparées par des virgules. Par exemple, utilisez des conditions telles que *test
l’exclusion des requêtes qui se terminent _test
par , ou Test*
pour exclure les requêtes qui commencent par Test
, ou *test*
pour exclure les requêtes qui ont une test
entrée dans n’importe quelle partie du texte de la requête.
Si un élément doit contenir un astérisque (*) qui n’est pas un caractère générique, une guillemet double ("), ou une barre oblique inverse (\), l’élément doit être placé en échappement avec une barre oblique \
inverse. Par exemple, utilisez des conditions telles que Query\*3
l’exclusion des requêtes qui se trouvent Query*3
dans le texte de la requête, utilisez des conditions comme \\path\\to\\
pour exclure les requêtes qui se trouvent \path\to\
dans le texte de la requête ou "GO, WITH"
pour exclure les requêtes qui ont une "GO, WITH"
entrée avec une virgule à l’intérieur du texte de la requête. Les remplacements avec des listes d’exclusion peuvent être utilisés simultanément.
Le tableau suivant définit des modèles génériques que vous pouvez utiliser dans les expressions :
Caractère | Description | Exemple |
---|---|---|
? | Représente n'importe quel caractère unique. Vous pouvez utiliser le point d’interrogation ( ?) n’importe où dans une chaîne de caractères. | Quer ? recherche Requête, Quer1, Quer_, Quer ?, Quer*, mais pas Query1 ou Requêtes. |
* | Correspond à n’importe quel nombre de caractères. Vous pouvez utiliser l’astérisque (*) n’importe où dans une chaîne de caractères. | DB* recherche des bases de données, DB1, DB2, DB_prod, mais pas 1DB ou base de données. *DB trouve 1DB, _DB, test-DB, mais pas 1DB_prod ou D_Base. *DB* recherche cloudDB_1, DBtest, 3DB, mais pas prod_D_B ou base de données. |
" | Correspond à n’importe quel nombre de caractères entre guillemets doubles. Vous pouvez utiliser les guillemets doubles ( » « ) n’importe où dans une chaîne de caractères. Si une chaîne de caractères contient une virgule, la chaîne doit être entre guillemets. | « Instance, Base de données » recherche une instance, une chaîne de base de données avec une virgule à l’intérieur, mais pas une chaîne d’instance séparément et une chaîne de base de données séparément. « Interroger avec des espaces de début et de fin » recherche une entrée avec tous les espaces inclus entre guillemets doubles. |
Le tableau suivant définit les modèles d’échappement que vous pouvez utiliser dans les expressions :
Caractère | Description | Exemple |
---|---|---|
\* | Pas un caractère générique. Échappe l’astérisque (*) n’importe où dans une chaîne de caractères. | dbname\* recherche dbname*, mais pas dbname1, dbname_prod, dbnames. |
\" | Pas un caractère générique. Échappe les guillemets doubles (") n’importe où dans une chaîne de caractères. | query \"example\ » recherche la requête « example », mais pas query\, exemple de requête ou « example ». |
\\ | Pas un caractère générique. Échappe la barre oblique inverse (\) n’importe où dans une chaîne de caractères. | C :\\Path\\to\\ recherche C :\Path\to\, mais pas C :\, Path\\to. |
Remarque
Cette règle ne fournit pas les textes d’exécution de requêtes en raison de raisons de sécurité.