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 initie sa propre fermeture
• 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 de réplique de base de données est modifié

• ID d’événement 19406, rôle réplique disponible 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 sont situés sous le récapitulatif de l’état de disponibilité des bases de données dans la vue du groupe de disponibilité. La liste des moniteurs est la suivante :

• Moniteur d’état de sauvegarde de la base de données de disponibilité
• Moniteur de l'é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 vise la santé de la base de données disponible et vérifie le statut de sauvegarde de la base de données en fonction du seuil de 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 l'option 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 la réplique principale est la seule réplique en ligne, la sauvegarde ne devrait pas avoir lieu.

• 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.

• N'importe quelle réplique

  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éplique de disponibilité, en tenant compte de son état opérationnel et de 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 de l'état de la sauvegarde des journaux de base de données de disponibilité

Ce moniteur vise à surveiller l'intégrité de la base de données de haute disponibilité et vérifie l'état de la sauvegarde du journal selon le seuil de temps défini en minutes.

Le regroupement des 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é représente une entité de base de données qui peut être hébergée sur de nombreux réplicas. Sur cette base, seul l’« État de sauvegarde de la base de données de disponibilité (rollup) » alerte pour vérifier l’état de la base de données de disponibilité entière par rapport à l’état affiché de la base de données sur chaque réplica.

Un rollup 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 de 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éplique 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
• Fichier
• 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
• Les 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 restant
    • Espace libre LOG restant
• Moniteurs désactivés pour Windows
  • Ciblé vers la base de données
    • Modification du pourcentage d’espace de données ROWS
    • Espace libre restant des données OLTP en mémoire
    • 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
• Moniteurs activés pour Linux
  • Ciblé vers le groupe de fichiers
    • Espace libre de fichier de base de données restant
  • Dirigé 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

Les moniteurs suivants prennent en charge la substitution du Mode de santé :

• Espace libre de données FILESTREAM restant
• Espace libre restant des données OLTP en mémoire
• Espace libre de fichier journal de base de données restant
• Espace libre restant des données ROWS

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 de suivre l’état de santé en fonction du paramètre « Seuil » exprimé en pourcentage (%) ou sous forme de 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 alloué à la base de données (Mo) utilisé
  • 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 du journal de transaction (%)
  • 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 l'état ONLINE, entraîneront un état de surveillance non conforme. 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, bien que la phase d'annulation de la récupération puisse ne pas être terminé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.
RESTAURATION	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.
Récupération	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.
RÉCUPÉRATION EN ATTENTE	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.
URGENCE	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 paramètre de substitution « Désactiver si le groupe de disponibilité est hors connexion », destiné aux 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 de sessions qui bloquent est conçu pour interroger chaque base de données pour une session bloquée pendant une longue période. 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 tous les éléments sécurisables SQL Server requis sont accessibles sous le compte d’exécution 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

  • AFFICHER L'ÉTAT DU SERVEUR
  • Voir n'importe quelle définition
  • VOIR TOUTE BASE DE DONNÉES

• 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 vues du catalogue

  • master.sys.dm_os_host_info
  • master.sys.groupes_de_disponibilité
  • 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
  • tables système
  • 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 de santé WMI

Ce moniteur vérifie si le compte Exécuter en tant que configuré a accès aux espaces de noms suivants situés sur le serveur SQL 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 tâches 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 ce niveau de supervision, vous devez réactiver la fonction Génération d'alertes.

  Le moniteur a le seuil du nombre d'échecs, ce qui indique le nombre de fois où un travail SQL Agent peut échouer avant que l'état du moniteur soit changé en 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 tâches longue durée

  Ce moniteur recherche les tâches à exécution longue 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 tâches, mais dans certains cas, les tâches avec le type de planification Démarrer automatiquement lorsque SQL Server Agent démarre peuvent 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 :

  • Régulier

    • 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.

  • Délimité

    • 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 de la durée de l'emploi

  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 remettre la fonctionnalité Générer des alertes en mode activé ou utiliser la règle d’alerte de durée de tâche.

• Règle d'alerte de durée d'emploi

  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 performance de la durée de l'emploi

  Cette règle collecte la durée en minutes d’une de vos tâches 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 le moteur de base de données SQL Server sur Windows et Linux et vérifie la période de validation en jours des certificats et les exigences du 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. Ce remplacement permet de vérifier avec une liste de noms d'hôtes supplémentaires, séparée par des virgules, 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 c'est le cas, le moniteur ignorera que le certificat n’est pas placé dans les Autorités de Certification Racines de Confiance. 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 le paramètre « 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 le fait que la liste de confiance des certificats (CTL) n'est pas valide, par exemple, si la CTL a expiré, lors de la vérification du certificat.
Configurer le paramètre '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 le paramètre « 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 le fait que le certificat présente une politique invalide lors de la vérification du certificat.
Activer l’indicateur « IgnoreNotTimeNested »	Ignorez le fait que le certificat d'autorité de certification et le certificat émis ont des périodes de validité qui ne se chevauchent pas 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'	Si la révocation de la racine est inconnue, ignorez-la lors 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 de l’authentification du serveur pour l’utilisation de clés	Si la valeur est true, le moniteur ignorera l'exigence du certificat concernant la présence de l'extension d'utilisation de 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 vraie, 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 la personnalisation des filtres d'alerte 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 comme *test pour exclure les requêtes qui se terminent par _test, ou Test* pour exclure les requêtes qui commencent par Test, ou la condition *test* pour exclure les requêtes qui contiennent une entrée test 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, un guillemet double (") ou une barre oblique inverse (\), l'élément doit être échappé 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 contournements 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
?	Correspond à n'importe quel caractère seul. Vous pouvez utiliser le point d’interrogation ( ?) n’importe où dans une chaîne de caractères.	Quer? trouve Query, Quer1, Quer_, Quer?, Quer*, mais pas Query1 ou Queries.
*	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* trouve DB1, DB2, DB_prod, mais pas 1DB ou Database. *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. « Requête avec des espaces de début et de fin » trouve une entrée avec tous les espaces inclus dans les 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 quel emplacement dans une chaîne de caractères.	dbname\* recherche dbname*, mais pas dbname1, dbname_prod, dbnames.
\"	Pas un joker. É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é.